INTERNET-DRAFT T. Otani Intended status: Informational K. Ogaki Expires:May, 2008 S. Okamoto KDDI R&D Labs November 14, 2007 GMPLS Inter-Domain Routing in support of inter-domain links Document: draft-otani-ccamp-gmpls-routing-interlink-01.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 incoming inter-domain links. In order to solve this issue, we describe the GMPLS inter-domain routing requirement in support of exchanging of inter-domain TE link information. Table of Contents Status of this Memo................................................ 1 T. Otani et al. Informational - Expires May 2007 [Page 1] Internet Drafts Nov. 2007 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. References...................................................... 5 Author's Addresses................................................. 6 Document expiration................................................ 7 Copyright statement................................................ 7 T. Otani et al. Informational - Expires May 2008 [Page 2] Internet Drafts Nov. 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, INTER- AS-OSPF]. Those mainly focus on MPLS inter-domain networks while toughing upon the applicability to GMPLS. However, since LSP directionality is differing between MPLS and GMPLS, this would be a stringent constrain in the case of inter-domain GMPLS LSP creation. Therefore, this document states the problem of the current generalized multi-protocol label switching (GMPLS) routing in order to deal with inter-domain TE links in the case of GMPLS inter-domain path creation. Since the GMPLS signaling protocol enables bi- directional label switched path (LSP) creation, an ingress node (or a path computation element) searches for the bidirectional route in the traffic engineering database (TED). In the case of the GMPLS inter- domain path creation, the ingress node searches the bi-directional route according to [ID-PD-PATHCOMP]. The TED contains only outgoing TE information of inter-domain links originating from the own domain border node, which might be statically and locally configured, and the ingress node cannot confirm the validity of incoming inter-domain TE links from the domain boarder node in the adjacent domain. Thus, an appropriate mechanism is required to support the information exchange of inter-domain links with TE extensions. 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 T. Otani et al. Informational - Expires May 2008 [Page 3] Internet Drafts Nov. 2007 Figure 1: GMPLS inter-domain network model 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 (domain 1 and domain 2). 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 or static route configuration 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 can also distribute the routing information of IDL-out within GMPLS domain 1 by [INTER-AS-OSPF, INTER-AS-ISIS], but not to GMPLS domain 2 because of the domain boundary. This IDL-out is statistically and locally configured. Furthermore, GMPLS attributes are additionally to be supported to the OSPF-TE object in [INTER-AS-OSPF]. Even if the domain border node 2 may notify only reachability information of GMPLS domain 2 including itself to the domain border node 1 by a dynamic way, the TED of the Ingress node in GMPLS domain 1 does not contain the TE information of the IDL-in Link. This is because currently defined protocol mechanisms do not support dynamic way to exchange inter-domain TE links between domain border nodes. In the case of MPLS path creation, since the path is uni-directional, the TE information of the IDL-out link in the TED is sufficient for the ingress node. On the contrary, in the case of GMPLS, 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 is also statically and manually configured. Moreover, if a failure occurs over the IDL-in link, the Ingress node may not know it because of the luck of the mechanism. Therefore, GMPLS routing mechanism is desired to be in support of exchanging of inter-domain TE link information for GMPLS inter-domain path establishment. 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. In addition to outgoing inter-domain links with MPLS TE information [INTER-AS-OSPF], incoming inter-domain links with TE information should be distributed to the own domain in support of appropriate GMPLS attributes such as a switching capability and an encoding type. T. Otani et al. Informational - Expires May 2008 [Page 4] Internet Drafts Nov. 2007 Consequently, the TED in each domain should be appropriately created so as to contain inter-domain TE links. The TED may be synchronized with the database in the PCE. The incoming inter-domain link, as the same with outgoing inter- domain TE links, can be statistically and locally configured. However, ideally speaking, dynamically exchanging mechanism would be preferred reflecting aliveness of adjacent inter-domain border nodes. 5. Security consideration GMPLS inter-domain routing to advertise additionally incoming inter- domain links with TE information will not change the underlying security issues of GMPLS networks. 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 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. References 8.1 Informative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. T. Otani et al. Informational - Expires May 2008 [Page 5] Internet Drafts Nov. 2007 [RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS traffic engineering", draft-ietf-ccamp-inter-domain- framework-01.txt, February 2005. [RFC4655] Farrel, et al, "A Path Computation Element (PCE)- Based Architecture", RFC 4655, August 2006. [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. 8.2 Informative references [ID-RSVP-TE] A. Farrel, et al, "Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions", draft- ietf-ccamp-inter-domain-rsvp-te-07.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. [INTER-AS-OSPF] M. Chen, et al, "OSPF Traffic Engineering (OSPF-TE) extensions in support of inter-AS multiprotocol label switching (MPLS) and generalized MPLS (GMPLS) traffic engineering", draft-ietf-ccamp-ospf-interas-te- extension-01.txt, Sept. 6, 2007. Author's Addresses Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama, 356-8502. Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp Kenichi Ogaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama, 356-8502. Japan Phone: +81-49-278-7897 Email: ogaki@kddilabs.jp Shuichi Okamoto KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama, 356-8502. Japan Phone: +81-49-278-7837 Email: okamoto@kddilabs.jp T. Otani et al. Informational - Expires May 2008 [Page 6] Internet Drafts Nov. 2007 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 May 2008 [Page 7]