One document matched: draft-otani-ccamp-gmpls-routing-interlink-00.txt
IETF Internet Draft T. Otani
Proposed status: Informational K. Ogaki
Expires:Sep. 2007 S. Okamoto
H. Guo
KDDI R&D Labs
Feb. 2007
GMPLS Inter-Domain Routing in support of inter-domain links
Document: draft-otani-ccamp-gmpls-routing-interlink-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft states the problem of the current generalized multi-
protocol label switching (GMPLS) routing in order to deal with inter-
domain TE links for GMPLS inter-domain signaling. Since the GMPLS
signaling protocol introduces bi-directional label switched path
(LSP) creation mechanism, an ingress node (or a path computation
element) searches for the bidirectional route in the traffic
engineering database (TED). Considering the GMPLS inter-domain path
creation, the TED contains only outgoing TE information of inter-
domain links and will not be able to confirm the validity of the
route. In order to solve this issue, we describe the GMPLS inter-
domain routing requirement and mechanism in support of exchanging of
inter-domain TE link information.
Table of Contents
T. Otani et al. Informational - Expires January 2006 1
Internet Drafts Feb. 2007
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................3
2. Conventions used in this document...............................3
3. GMPLS inter-domain path establishment...........................3
4. GMPLS inter-domain routing requirements in support of inter-domain
TE link information................................................4
5. Security consideration..........................................5
6. Acknowledgement.................................................5
7. Intellectual property considerations............................5
8. Informative references..........................................6
Author's Addresses.................................................6
Document expiration................................................7
Copyright statement................................................7
T. Otani et al. Informational - Expires Sept. 2007 2
Internet Drafts Feb. 2007
1. Introduction
A framework for establishing and controlling Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE)
Label Switched Paths (LSPs) in multi-domain networks has been defined
so far [RFC4726], and enabling protocols and mechanisms are
intensively investigated [ID-RSVP-TE, ID-PD-PATHCOMP, RFC4655].
However, those mainly focus on MPLS inter-domain networks while
toughing upon the applicability to GMPLS. Since there are some
difference between MPLS and GMPLS, the specific requirements
especially for inter-domain LSP creation in GMPLS networks are being
proposed [GMPLS-AS].
This document states the problem of the current generalized multi-
protocol label switching (GMPLS) routing in order to deal with inter-
domain TE links for GMPLS inter-domain signaling. Since the GMPLS
signaling protocol introduces bi-directional label switched path
(LSP) creation mechanism, an ingress node (or a path computation
element) searches for the bidirectional route in the traffic
engineering database (TED). Considering the GMPLS inter-domain path
creation, the TED contains only outgoing TE information of inter-
domain links and cannot confirm the validity of the route to the
domain boarder node in the adjacent domain. The GMPLS inter-domain
routing mechanism must support the information exchange of the
routing information with TE extensions of inter-domain links.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. GMPLS inter-domain path establishment
3.1 Assumed network model
|
|
+-------+ +-------+ | +-------+ +-------+
| | | | IDL-out | | | |
| |----//--->|Domain |---------->|Domain |----//----| |
|Ingress| |Border | |Border | |Egress |
| | |Node 1 | IDL-in |Node 2 | | |
| |<---//----| |<----------| |<---//----| |
| | | | | | | | |
+-------+ +-------+ | +-------+ +-------+
|
GMPLS domain 1 | GMPLS domain 2
Figure 1: GMPLS inter-domain network model
T. Otani et al. Informational - Expires Sept. 2007 3
Internet Drafts Feb. 2007
Figure 1 indicates the assumed GMPLS inter-domain network model. Here,
we assume a very simple GMPLS inter-domain network model consisting
of two GMPLS domains. Each domain border node is connected by an
inter-domain link (IDL). An interior gateway protocol (IGP) with TE
extensions such as OSPF-TE or ISIS-TE [RFC4202, RFC4203, RFC4205] is
responsible for distributing the routing information with TE. Between
domains, an exterior gateway protocol (EGP) such as BGP-4 may be
applied to exchange the reachability information and domain-to-domain
routes. The ingress node either calculates the path in its own domain
or asks the route to a PCE for GMPLS inter-domain signaling.
3.2 Path computation
Nodes in each GMPLS domain exchange the routing information with TE
extensions by the IGP. The IGP will also distribute the routing
information of IDL-out within GMPLS domain 1, but not to GMPLS domain
2 because of the domain boundary. The domain border node 2 will
notify the reachability information of GMPLS domain 2 including
itself to the domain border node 1 by GMPLS EGP. Since GMPLS EGP is
currently under investigation in support of TE extensions [GMPLS-AS],
the TED of the Ingress node in GMPLS domain 1 does not contain the TE
information of the IDL-in Link.
Consequently, the Ingress node will not calculate the bi-directional
route to the domain border node 2 by using the TED, unless the TE
information of the IDL-in link are statically and manually configured.
Moreover, if a failure occurs over the IDL-in link, the Ingress node
may not know it. Therefore, GMPLS routing mechanism is desired to be
in support of exchanging of inter-domain TE link information for
GMPLS inter-domain path establishment.
In the case of MPLS path creation, since the path is uni-directional,
the TE information of the IDL-in link will not be required.
4. GMPLS inter-domain routing requirements in support of inter-domain TE
link information
In order to solve the abovementioned issue, we describe the GMPLS
inter-domain routing requirements and a possible mechanism.
4.1 Inter-domain TE information exchange
GMPLS inter-domain routing should support to exchange TE information
of inter-domain links between domain border nodes in a scalable
manner. IGPs with TE extensions do not currently support this
function.
4.2 Inter-domain link TE information distribution
The exchanged TE information of inter-domain TE links should be
redistributed into each domain by using IGP or other methods, and as
a result, the TED should be appropriately created so as to contain
T. Otani et al. Informational - Expires Sept. 2007 4
Internet Drafts Feb. 2007
those of inter-domain TE links. The TED may be synchronized with the
database in the PCE.
4.3 BGP-4 with GMPLS extension
One of solutions is BGP-4 with GMPLS TE extensions. An early
definition of the additional attribute is proposed in [GMPLS-BGP] to
support GMPLS TE information, which may be applicable to the
mechanism to exchange the TE information of inter-domain links. The
exchanged inter-domain link information should be appropriately
transferred to the IGP and be redistributed to the domain to create
the TED including inter-domain links; otherwise the establishment of
interior-BGP sessions may help redistribution of the inter-domain TE
link information.
4.4 Link Management Protocol
To maintain TE links in GMPLS networks, Link Management Protocol
(LMP) has been defined [RFC4204] and applicable to inter-domain TE
links as well. LMP provide the functionality to verify the link
aliveness and may indirectly assist GMPLS inter-domain routing in
support of inter-domain TE links.
5. Security consideration
GMPLS inter-domain routing should be implemented under a certain
security consideration such as authentication of signaling and
routing on the control plane as well as a data plane itself. Indeed,
this will not change the underlying security issues.
6. Acknowledgement
The author would like to express the thanks to Adrian Farrel for the
discussion.
7. Intellectual property considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
T. Otani et al. Informational - Expires Sept. 2007 5
Internet Drafts Feb. 2007
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
8. Informative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS
traffic engineering", draft-ietf-ccamp-inter-domain-
framework-01.txt, February 2005.
[ID-RSVP-TE] A. Farrel, et al, "Inter domain MPLS and GMPLS
Traffic Engineering - RSVP-TE extensions", draft-
ietf-ccamp-inter-domain-rsvp-te-04.txt, January 2007.
[ID-PD-PATHCOMP]J. P. Vasseur, et al, "A Per-domain path computation
method for establishing Inter-domain Traffic
Engineering (TE) Label Switched Paths(LSPs)", draft-
ietf-ccamp-inter-domain-pd-path-comp-04, Jan 2007.
[RFC4655] Farrel, et al, "A Path Computation Element (PCE)-
Based Architecture", RFC 4655, August 2006.
[GMPLS-AS] T. Otani, et al, "GMPLS Inter-domain Traffic
Engineering Requirements", draft-otani-ccamp-interas-
gmpls-te-06.txt, Feb. 2007.
[RFC4202] K. Kompella, et al, "Routing Extensions in Support of
Generalized Multi-Protocol Label Switching", RFC4202,
October 2005.
[RFC4203] K. Kompella, et al, "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC4203, October 2005.
[RFC4205] K. Kompella, et al, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC4205, October 2005.
[GMPLS-BGP] Hamid Ould-Brahim, et al, "Traffic Engineering
Attribute", draft-fedyk-bgp-te-attribute-02.txt, Oct.
2006.
[RFC4204] J. P. Lang, "Link Management Protocol(LMP)", RFC4204,
Oct. 2005.
Author's Addresses
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino Phone: +81-49-278-7357
Saitama, 356-8502. Japan Email: otani@kddilabs.jp
Kenichi Ogaki
KDDI R&D Laboratories, Inc.
T. Otani et al. Informational - Expires Sept. 2007 6
Internet Drafts Feb. 2007
2-1-15 Ohara Fujimino Phone: +81-49-278-7897
Saitama, 356-8502. Japan Email: ogaki@kddilabs.jp
Shuichi Okamoto
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino Phone: +81-49-278-7837
Saitama, 356-8502. Japan Email: okamoto@kddilabs.jp
Hongxiang Guo
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino Phone: +81-49-278-7864
Saitama, 356-8502. Japan Email: ho-guo@kddilabs.jp
Document expiration
This document will be expired in Sept. 30, 2007, unless it is updated.
Copyright statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
T. Otani et al. Informational - Expires Sept. 2007 7 | PAFTECH AB 2003-2026 | 2026-04-23 17:15:17 |