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