IETF Internet Draft T. Otani Proposed status: Informational KDDI R&D Labs Expires:April 2006 S. Okamoto NTT October 2005 GMPLS Inter-domain routing problem statement and requirements Document: draft-otani-ccamp-inter-domain-routing-req-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 provides problem statement and requirements of inter- domain routing in a generalized multi-protocol label switching (GMPLS) network. The reachability information exchange must be supported for appropriate signaling operation in a GMPLS network, as the same with the IP/MPLS inter-domain case. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 2. Conventions used in this document...............................3 3. Problems statement of GMPLS inter-domain networks...............3 4. Requirement of GMPLS inter-domain routing.......................4 6. Security consideration..........................................6 7. Acknowledgement.................................................6 T. Otani et al. Informational - Expires April 2006 1 draft-otani-ccamp-inter-domain-routing-req-00.txt October 2005 8. Intellectual property considerations............................6 9. Informative references..........................................6 Author's Addresses.................................................7 Document expiration................................................7 Copyright statement................................................7 T. Otani et al. Informational - Expires April 2006 2 draft-otani-ccamp-inter-domain-routing-req-00.txt October 2005 1. Introduction Initial efforts of GMPLS functions were focused on solving the problem within an Autonomous System (AS) or area (hereinafter domain). Service Providers (SPs) are getting to come up with difficulties to design future GMPLS networks considering multi-domain extensions due to no definition of inter-domain routing. Although documents of inter-domain framework [Inter-domain] as well as inter-domain TE requirements [Interas-te] touch upon the GMPLS inter-domain routing architecture, there is no clear definition of GMPLS inter-domain routing. Moreover, GMPLS inter-domain signaling is specifically defined [Inter-signaling] assuming that the reachability information is ensured between domains. On the other hand, standard organization (SDOs) such as ITU-T and OIF have already define the same functionality of iter-domain routing as E-NNI functional specifications [ASON routing, OIF-ENNI]. At this moment, SPs who want to utilize IETF GMPLS network can not imagine inter-domain GMPLS networks for inter-SPs as well as intra-SP but only intra-domain GMPLS networks, while other SDOs support such specifications. If the MPLS world is looked at, the inter-domain requirements [RFC4105] are assumed under the condition of routing information exchange by BGP-4 between inter-domains. [Interas-te] describes the requirements for extending TE mechanisms across the GMPLS network domains. However, before considering such requirements, the basic inter-domain routing requirement must be discussed and assessed among the working group members in order to assist appropriate GMPLS inter-domain signaling functionalities. This document provides the problem statement in order to achieve GMPLS inter-domain networks especially in inter-SP operational environment. It also proposes to specify the functional requirements to support of GMPLS inter-domain routing functions. 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. Problems statement of GMPLS inter-domain networks Figure 1 depicts a typical network, consisting of several GMPLS domains, assumed in this document. D1, D2, D3 and D4 have multiple GMPLS inter-domain connections, and D5 has only one GMPLS inter- domain connection. These domains follow the definition in [inter- domain]. T. Otani et al. Informational - Expires April 2006 3 draft-otani-ccamp-inter-domain-routing-req-00.txt October 2005 +---------+ +---------|GMPLS D2|----------+ | +----+----+ | +----+----+ | +----+----+ +---------+ |GMPLS D1| | |GMPLS D4|---|GMPLS D5| +----+----+ | +----+----+ +---------+ | +----+----+ | +---------|GMPLS D3|----------+ +---------+ Figure 1: GMPLS Inter-domain network model Each domain is configured using various switching and link technologies defined in [Arch] and an end-to-end route needs to respect TE link attributes like multiplexing type, encoding type, etc., making the problem a bit different from the case of classical (packet) MPLS. In order to route from one GMPLS domain to another GMPLS domain appropriately, each domain should advertise at least reachability information, while concealing its internal topology information through GMPLS exterior routing protocol, which has not yet been defined. Additional TE information may be required in the future, in order to improve the network control and management. A signaling mechanism is required to specify a route consisting of multiple domains. [ID-sig] defines the signaling mechanisms over multiple domains, for example, to use loose hop expansion at the domain border routers. It is quite difficult and less efficient from the point of operation to set up the route without knowing reachability information. In such a case, the operator must specify the static route to the border node as well as appropriate border node, although the crank back mechanism may solve this issue (if we accept the possibility of multiple signaling tries). In the IP/MPLS network, network nodes are only a packet switched device. On the other hand, since the GMPLS network consists of various devices such as optical cross-connect equipment, IP/MPLS router, SDH-XC, and so forth, LSP end-point information may be useful in order to use a forwarding adjacency as inter-domain routing information. Therefore, without sacrificing the operational efficiency as the same with MPLS inter-domain network, the clear definition of GMPLS inter- domain routing must be defined for SPs who think about adopting the GMPLS technology to control their optical networks. 4. Requirement of GMPLS inter-domain routing In this section, we describe the requirements of GMPLS inter-domain routing for the computation of GMPLS paths over multiple domains. In IP/MPLS networks, inter-AS routing is assumed to reuse the existing EGP of BGP-4 and such architecture is widely established. T. Otani et al. Informational - Expires April 2006 4 draft-otani-ccamp-inter-domain-routing-req-00.txt October 2005 However, such inter-domain routing has not been clearly defined so far for GMPLS inter-domain networks, even if it may be a straight forward to reuse the same protocol as IP/MPLS networks. Therefore, inter-domain routing is required to support multiple GMPLS domains. 5.2.1 Reachability information exchange GMPLS inter-domain routing mechanism must support the exchange of reachability information over each domain. Reachability information includes: (1) Reachable IP address (Node ID or Interface IP address) (2) Interface ID (unnumbered link) The reachability information must be advertised in accordance with their belonging domain information in order to calculate the GMPLS LSP over multiple domains [id-sig]. The reachability information may be aggregated depending on the domain’s policy. The scalability of inter-domain routing should be considered in designing future GMPLS extensions to allow exchange of TE information in addition to the above reachability information. Furthermore, the GMPLS inter-domain routing should be designed to achieve such operation that defects in one domain do not affect the scalability of an intra-domain routing of IGPs in other domains, although the GMPLS inter-domain routing should promptly advertise the failure within the domain, ensuring the GMPLS inter-domain connection establishment. The GMPLS network, in general, consists of various devices such as optical cross-connect equipment, IP/MPLS router, SDH-XC, and so forth, and LSP end-point information should be useful in order to use a forwarding adjacency as inter-domain routing information. GMPLS inter-domain routing must basically follow the GMPLS architecture [Arch], including the support of its exchange over out of band control channel. 5.2.2 Reachability information redistribution requirement GMPLS inter-domain routing must provide redistribution mechanisms within the domain in a scalable manner. These information redistribution mechanisms must be designed to achieve such operation that a defect in a domain does not affect the scalability of intra- domain routing in a different domain, although the GMPLS inter-domain routing must promptly advertise the failure within the domain, ensuring the GMPLS inter-domain connection establishment. Mechanisms for redistributing GMPLS reachability information within the GMPLS domain can be I-BGP session, or re-injection to IGP. Especially, it is useful to adopt GMPLS end-to-end basis path calculation. T. Otani et al. Informational - Expires April 2006 5 draft-otani-ccamp-inter-domain-routing-req-00.txt October 2005 GMPLS inter-domain routing must have the functionality to consider any policies for controlling reachability information to be flooded, which will be defined between domains on a business or operational strategy basis. GMPLS inter-domain routing policy should be able to be changed and configured on a per domain basis. This policy control especially in terms of switching capability may be applicable to the extensions of hierarchical routing. Each domain should control the advertisement of the switching capability or re-advertisement of received switching capability. 6. Security consideration GMPLS inter-domain routing should be implemented under a certain security consideration of the control plane as well as the data plane itself. Indeed, this will not change the underlying security issues. 7. Acknowledgement The authors would like to express the thanks to Naoaki Yamanaka for his support. 8. 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. 9. 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 April 2006 6 draft-otani-ccamp-inter-domain-routing-req-00.txt October 2005 [Inter-domain] A. Farrel, et al, "A framework for inter-domain MPLS traffic engineering", draft-ietf-ccamp-inter-fomain- framework-01.txt, February 2005. [Interas-te] T. Otani, et al, “GMPLS Inter-domain Traffic Engineering Requirements”, draft-otani-ccamp-interas- gmpls-te-03.txt, July 2005. [ASON routing] G.8080 [OIF-ENNI] DDPR [RFC 4105] R. Zhan, et al, "Requirements for Inter-Area MPLS Traffic Engineering”, RFC4105, June 2005. [Arch] E. Mannie, et al, "Generalized Multi-Protocol Label Switching Architecture", RFC3945, October, 2004. [ID-sig] A. Ayyangar, “Inter domain GMPLS Traffic Engineering - RSVP-TE extensions”, draft-ietf-ccamp-inter-domain- rsvp-te-02.txt, Oct. 2005. Author's Addresses Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino-shi Phone: +81-49-278-7357 Saitama, 356-8502. Japan Email: otani@kddilabs.jp Satoru Okamoto NTT Network Service System Laboratories 3-9-11 Midori-cho, Musashino-shi, Phone: +81-422-59-4353 Tokyo, 180-8585. Japan Email: okamoto.satoru@lab.ntt.co.jp Document expiration This document will be expired in April 30, 2006, unless it is updated. Copyright statement Copyright (C) The Internet Society (2005). 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 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 April 2006 7