Network Working Group Internet Draft Kenji Kumaki Category: Informational KDDI Corporation Expires: August 2006 Tomohiro Otani KDDI R&D Labs Shuichi Okamoto NICT Kazuhiro Fujihara Yuichi Ikejiri NTT Communications February 2006 Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract K.Kumaki et al. Expires - August 2006 [Page 1] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 This document describes Service Provider requirements for IP/MPLS- GMPLS interworking in support of GMPLS deployment. The main objective is to present a set of requirements and scenarios which result in general guidelines for the definition, selection and specification of a technical solution addressing these requirements and supporting the scenarios. Specification for this solution itself is out of scope in this document. 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. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................4 3. Problem Statement..............................................4 4. Reference model................................................5 5. Application Scenario...........................................5 5.1 Overlay model..............................................6 5.2 Integrated model...........................................6 5.3 Augmented model............................................6 6. Detailed Requirements..........................................7 6.1 Software Upgrade Requirement...............................8 6.2 Use of GMPLS network resources in IP/MPLS networks.........8 6.3 Routing adjacency for IP/MPLS networks over GMPLS networks.8 6.4 Mapping routing information between IP/MPLS and GMPLS......8 6.5 Mapping signaling information between MPLS and GMPLS.......9 6.6 Establishment of GMPLS LSPs triggered by end-to-end MPLS LSPs signaling......................................................9 6.7 Establishment of end-to-end MPLS LSPs having diverse paths over GMPLS network.............................................9 6.8 Advertisement of TE / IP reachability information via GMPLS domain.........................................................9 6.9 Selective advertisement of TE/IP reachability information via a border node..................................................9 6.10 Interworking of MPLS and GMPLS protection................10 6.11 Separation of IP/MPLS domain and GMPLS domain............10 6.12 Failure recovery.........................................10 6.13 Complexity and Risks.....................................10 6.14 Scalability consideration................................10 6.15 Performance consideration................................11 6.16 Management consideration.................................11 7. Security Considerations.......................................11 K.Kumaki et al. Expires - August 2006 [Page 2] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 8. IANA Considerations...........................................12 9. Normative References..........................................12 10. Informative References.......................................12 11. Acknowledgments..............................................12 12. Author's Addresses...........................................12 13. Intellectual Property Statement..............................13 1. Introduction Recently, the deployment of a GMPLS network is planned or under investigation among many service providers and some of very advanced research networks have been already operated based on GMPLS technology. GMPLS is developed as an extension of MPLS in order to mainly control a transport network consisting of TDM cross-connect, optical/lambda switches, and fibers. By introducing GMPLS technology, some service providers expect that IP/MPLS network connectivity is effectively and reliably established over the GMPLS network. If MPLS and GMPLS protocols can interwork with each other, the introduction of GMPLS would be more beneficial for service providers, because this is expected to improve the resource utilization, network resiliency and manageability all over the network, less impacting the existing IP/MPLS networks. On the other hand, GMPLS protocols additionally define the packet switch capable mechanism, although existing MPLS networks already achieve the almost same functionalities and are being well-operated. Some service providers are considering to gradually replace all the IP/MPLS routers with GMPLS routers or upgrade the software so as to support GMPLS in conjunction with the introduction of GMPLS controlled optical networks. In both cases, there is no clear definition and standardization work so far to interwork between IP/MPLS routers as well as GMPLS routers, i.e. IP/MPLS networks and GMPLS networks. In order to accelerate the deployment of GMPLS technology, MPLS/GMPLS interworking is a key to gain more benefit than without any interworking. These types of network architecture to investigated, however, are much varied among service providers, and as a result, the requirements in support of those may be different from each other. In order to create the definition of MPLS/GMPLS interworking technology, the concrete requirement is preferably defined from the point of operational experience of MPLS/GMPLS networks and future view on these technologies by collecting the input and requirements from various service providers. K.Kumaki et al. Expires - August 2006 [Page 3] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 Considering such environment, this document focuses on the requirement of IP/MPLS-GMPLS interworking especially in support of GMPLS deployment. 2. Terminology IP/MPLS network: Service Provider Network where MPLS switching capabilities and signaling control (e.g., ones described in [RFC3031]) are activated in addition to IP routing protocols. LSP: Label Switched Path PSC: Packet Switch Capable LSC: Lambda Switch Capable FA-LSP: Forwarding Adjacency Label Switched Path Head-end LSR: ingress LSR Tail-end LSR: egress LSR LSR: Label Switched Router MPLS LSP: Multi Protocol Label Switching LSP 3. Problem Statement GMPLS technology is deployed or will be deployed in various forms to provide a highly efficient transport for existing IP/MPLS network, depending on the deployment model of each service provider. Some service providers may allow the hybrid architecture of IP/MPLS and GMPLS so that the introduction of GMPLS technology has less impact on an existing IP/MPLS network with regard to routing instance, addressing and the running software. On the other hand, some service providers may need to control almost all devices by a single control plane of GMPLS, which may require the running software upgrade. In order to operate such a hybrid network appropriately and effectively, clear definition should be formulated so as to cover each service provider's strategy. In terms of MPLS/GMPLS signaling, although the created GMPLS LSP over optical networks will be utilized by the IP/MPLS network, the clear mechanism of how to use it has not yet been defined. On the other hand, if the routing mechanism is considered, the method to transport routing information has not yet been also defined between IP/MPLS K.Kumaki et al. Expires - August 2006 [Page 4] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 networks and GMPLS networks. Feature richness of MPLS and GMPLS technology allows service providers to use a set of options on how GMPLS services can be used by IP/MPLS networks. In this document, the requirement for IP/MPLS-GMPLS interworking is presented with some operations considerations associated with use of GMPLS services by IP/MPLS networks. Note that an IP/MPLS-GMPLS interworking to deploy GMPLS technology is not only tentatively required for a migration from MPLS RSVP-TE to GMPLS RSVP-TE but also permanently required for the use of LDP and IGP (e.g. OSPF and IS-IS) instead of MPLS RSVP-TE in IP/MPLS networks. 4. Reference model The reference model used in this document is shown in Figure 1. As indicated in [RFC3945], the optical transport network consists of, for example, GMPLS controlled OXCs and GMPLS-enabled IP/MPLS routers. | | | | |IP/MPLS network |------------------------------|IP/MPLS network | | | | | | Optical Transport | | (GMPLS) Network | +---------+ +--------+ +------+ +------+ +--------+ +---------+ | | | | | | | | | | | | | IP/MPLS +--+ GMPLS +--+ +--+ +--+ GMPLS +--+ IP/MPLS | | Service | |Enabled | | OXC1 | | OXC2 | |Enabled | | Service | | Network +--+ router | | +--+ | | router +--+ Network | | | | | | | | | | | | | +---------+ +--------+ +------+ +------+ +--------+ +---------+ Figure 1. Reference model of MPLS/GMPLS interworking IP/MPLS network connectivity is provided through GMPLS LSP which is created between GMPLS routers. In this document, the requirement how the IP/MPLS network and the GMPLS network are interworked is described in order to effectively operate the entire network and smoothly deployed the GMPLS network. 5. Application Scenario This section describes three different scenarios to deploy GMPLS technology. From the deployment point of view, GMPLS architecture document lists [RFC3945] three different scenarios in which GMPLS technology can be K.Kumaki et al. Expires - August 2006 [Page 5] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 deployed: overlay, integrated and augmented. The key difference among these models is how much and what kind of network information can be shared between packet (e.g. PSC) and optical (e.g. LSC) domains. In this section, in case that GMPLS technology is deployed in existing IP/MPLS networks, pros and cons of each model are discussed. 5.1 Overlay model In overlay model, all the devices in optical domains have no visibility into others topology and/or routing information such as packet network (e.g. IP/MPLS service network) and vice versa. But IP/MPLS domain and optical domain can interact with signaling operation. Overlay model is suitable for such scenario, however it does not offer the benefits of integrated model approach for efficient resource utilization, optimal routing, and protection and restoration between IP/MPLS and optical networks. Note that some service providers need a way to make effective use of GMPLS network resources (e.g. bandwidth, protection and recovery) for the IP/MPLS service networks. 5.2 Integrated model In integrated model, since all the devices in optical domains and IP/MPLS domains share the same topology and routing information with the same IGP instance, it requires all the devices within peer model to be MPLS/GMPLS aware. This model is also suitable, where optical transport and IP/MPLS service networks are operated by a single entity. Currently, many service providers have traditionally built their networks, where optical transport and IP/MPLS service networks belong to different operation, management and ownership. The most important thing is that service providers want to operate and manage their networks independently, and deploy them without changing existing IP/MPLS network topologies, protocols and scalability. But in this model, in case that a lot of devices exist in a network, there are scalability issues. Note that most of real service providers have thousands or tens of thousands of devices in real networks. 5.3 Augmented model Augmented model is suitable in the scenario, where optical transport and IP/MPLS service networks are administrated by different entities and the service provider would like to maintain a separation between K.Kumaki et al. Expires - August 2006 [Page 6] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 IP/MPLS and Optical layers while getting the benefits of integrated model approach. In augmented model, as shown in figure 2, devices within optical domains have no visibility into others topology and/or routing information, except the border nodes. This will help augmented model to accommodate both MPLS based or non-MPLS based service networks connected to border nodes, as long as the border node in augmented model can support GMPLS control plane. Only the border node can share optical domains and IP/MPLS domains. Once IP/MPLS nodes signal to border nodes, the border nodes make effective use of GMPLS network resources (e.g. bandwidth, protection and recovery) for the IP/MPLS service networks. Note that an IP/MPLS routing instance and GMPLS routing instance have different routing instances at a border node. One of the main advantages of the augmented model in the context of GMPLS deployment is that it does not require existing IP/MPLS networks to be GMPLS aware. Only border nodes need to be upgraded with the GMPLS functionality. In this fashion, the augmented model renders itself for incremental deployment of the optical regions, without requiring reconfiguration of existing areas/ASes, changing operation of IGP and EGP or software upgrade of the existing IP/MPLS service networks. Furthermore, to deploy GMPLS technology without changing the existing IP/MPLS networks as much as possible is desirable by simply establishing a routing adjacency at IP/MPLS instance between border nodes. | | | | |IP/MPLS network |------------------------------|IP/MPLS network | | | | | | Optical Transport | | (GMPLS) Network | +---------+ +--------+ +------+ +------+ +--------+ +---------+ | | | | | | | | | | | | | IP/MPLS +--+ Border +--+ +--+ +--+ Border +--+ IP/MPLS | | Service | | node | | OXC1 | | OXC2 | | node | | Service | | Network +--+ | | +--+ | | +--+ Network | | | | | | | | | | | | | +---------+ +--------+ +------+ +------+ +--------+ +---------+ Figure 2. Augmented Model 6. Detailed Requirements This section describes detailed requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment. K.Kumaki et al. Expires - August 2006 [Page 7] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 6.1 Software Upgrade Requirement The solution SHOULD provide the way not to upgrade all IP/MPLS routers to GMPLS capable routers. Generally speaking, it is not practical to upgrade all IP/MPLS routers to GMPLS capable routers in real service provider networks due to a number of reasons. Especially, in case of accommodating enterprise customers, it is difficult for service providers to upgrade from IP/MPLS capable routers to GMPLS capable routers. This means that some routers would not be upgraded to support GMPLS and some routers would support it in the IP/MPLS production networks. 6.2 Use of GMPLS network resources in IP/MPLS networks The solution SHOULD provide the ability to make effective use of GMPLS network resources (e.g. bandwidth, protection & recovery) by the IP/MPLS service networks. Most of service providers have different networks for various services; their GMPLS deployment plans are to have these service networks use a common GMPLS controlled optical network as a core network of various services. 6.3 Routing adjacency for IP/MPLS networks over GMPLS networks The solution SHOULD provide the ability to establish a routing adjacency at IP/MPLS instance between border nodes. Most of service providers expect to deploy GMPLS technology without changing the existing IP/MPLS networks as much as possible. In case that GMPLS technology is deployed at a border node, the routing adjacency at IP/MPLS instance between the border nodes is required. Note that the routing adjacency is not established between IP/MPLS routers in case of using FA-LSPs. 6.4 Mapping routing information between IP/MPLS and GMPLS The solution SHOULD provide the ability to map routing information between IP/MPLS and GMPLS. From an IP/MPLS routing domain point of view, the routers in the IP/MPLS domain should be able to see a GMPLS LSP as a link or TE link. Furthermore, they should be able to choose an appropriate GMPLS LSP in GMPLS optical domain as a link or TE link. In this case, routers in the IP/MPLS domain can choose a link or TE link based on some policy such as optimality, diversity, protected or QoS inferred. It would enable an IP/MPLS network operating LDP/IGP (e.g. OSPF and IS-IS) as well as RSVP-TE to use GMPLS as an effective transport network. K.Kumaki et al. Expires - August 2006 [Page 8] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 6.5 Mapping signaling information between MPLS and GMPLS The solution SHOULD provide the ability to map signaling information between MPLS and GMPLS. From an IP/MPLS signaling domain point of view, the routers in IP/MPLS domain should be able to signal over GMPLS optical domain. In this case, an interworking between MPLS and GMPLS protocol is needed. Note that it is supposed that MPLS signaling here is RSVP based signaling. 6.6 Establishment of GMPLS LSPs triggered by end-to-end MPLS LSPs signaling The solution SHOULD provide the ability to establish end-to-end MPLS LSPs over GMPLS network regardless of existence of FA-LSPs in GMPLS network. When there are no FA-LSPs in it, they should be set up triggered by the signaling of MPLS LSP. 6.7 Establishment of end-to-end MPLS LSPs having diverse paths over GMPLS network The solution SHOULD provide the ability to establish end-to-end LSPs having diverse paths including diverse GMPLS FA-LSPs corresponding to the request of the head-end MPLS LSR for protection of MPLS LSPs. The GMPLS network SHOULD assure the diversity of GMPLS FA-LSPs, even if their ingress nodes in GMPLS network are different. 6.8 Advertisement of TE / IP reachability information via GMPLS domain The solution SHOULD provide the ability to control advertisements of TE information and/or IP reachability information of IP/MPLS service networks via GMPLS network regardless of existence of FA-LSPs. The TE / IP reachability information within the same MPLS service networks should be exchanged in order for a head end LSR of the MPLS network to compute an LSP to a tail end LSR over the GMPLS network. On the other hand, the TE / IP reachabality information SHOULD NOT be advertised to the other IP/MPLS service networks in order to avoid establishing undesirable connections. 6.9 Selective advertisement of TE/IP reachability information via a border node The solution SHOULD provide the ability to distribute TE/IP reachability information from the GMPLS network to IP/MPLS networks selectively, which are useful for the head-end MPLS routers to compute MPLS LSPs. K.Kumaki et al. Expires - August 2006 [Page 9] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 6.10 Interworking of MPLS and GMPLS protection The solution SHOULD provide the ability to select GMPLS protection type with the option by protected MPLS LSPs. If MPLS LSPs are protected using MPLS FRR [RFC4090], when an FRR protected packet LSP is signaled, we should be able to select protected FA-LSPs from GMPLS network. In terms of MPLS protection, MPLS path message can include some flags in FAST REROUTE object and SESSION_ATTRIBUTE object. In terms of GMPLS protection, there are both signaling aspects [RFC3471] [RFC3473] and routing aspects [RFC4202]. 6.11 Separation of IP/MPLS domain and GMPLS domain The solution SHOULD provide the ability to separate IP/MPLS domain and GMPLS domain. Most of service providers have had different networks for every service, where optical networks and IP/MPLS networks belong to different operation, management and ownership. The most important thing is that service providers want to operate and manage their networks independently, and deploy them without changing existing IP/MPLS network topologies and protocols and without affecting scalability. 6.12 Failure recovery The solution SHOULD provide failure recovery in optical domain without impacting IP/MPLS domain and vice versa. Failure in optical routing domain SHOULD NOT affect services in IP/MPLS routing domain and failure can be restored/repaired in optical domain without impacting IP/MPLS domain and vice versa. But in case that failure in optical domain associates with IP/MPLS domain, some kind of notification of the failure may be transmitted to IP/MPLS domain and vice versa. 6.13 Complexity and Risks The solution SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over service provider networks. 6.14 Scalability consideration The solution MUST have a minimum impact on network scalability for deploying GMPLS technology in the existing IP/MPLS networks. Scalability of GMPLS deployment in the existing IP/MPLS networks MUST address the following consideration. K.Kumaki et al. Expires - August 2006 [Page 10] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 - the number of GMPLS capable node (e.g. the number of non-PSC GMPLS capable node) - the number of MPLS capable node - the number of IP capable node - the number of OSPF capable node - the number of OSPF non-backbone area - the number of BGP capable node 6.15 Performance consideration The solution SHOULD be evaluated with regard to the following criteria. - the number of routing instance - Failure and restoration time - Impact and scalability of the control plane due to added overheads and so on - Impact and scalability of the data/forwarding plane due to added overheads and so on 6.16 Management consideration Manageability of GMPLS deployment in the existing IP/MPLS networks MUST addresses the following consideration for section 6. - need for a MIB module for control plane and monitoring - need for diagnostic tools Basically MIB module should be implemented per routing instance. Today, diagnostic tools can detect failures of control plane and data plane for general MPLS TE LSPs [LSP-PING]. The diagnostic tools must detect failures of control and data plane for general GMPLS TE LSPs. Especially, in case that an interworking between MPLS and GMPLS protocol is done, a failure between them MUST be detected. Furthermore, many service providers have traditionally built their networks, where optical transport and IP/MPLS service networks belong to different operation, management and ownership. The most important thing is that service providers want to operate and manage their networks independently. 7. Security Considerations Many service providers have traditionally built their networks, where optical transport and IP/MPLS service networks belong to different K.Kumaki et al. Expires - August 2006 [Page 11] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 operation, management and ownership. The most important thing is that service providers want to operate and manage their networks independently. In that sense, operators SHOULD limit to access their service nodes. Especially, in case that a border node is deployed, operators SHOULD limit to access a specific instance. Furthermore, operators SHOULD limit to be able to issue some commands. 8. IANA Considerations This requirement document makes no requests for IANA action. 9. Normative References [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC3945, October 2004. [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. [RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC4202, October 2005. 10.Informative References [LSP-PING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane Failures", Work in Progress, January 2006. 11.Acknowledgments The author would like to express the thanks to Raymond Zhang for his helpful and useful comments and feedbacks. 12.Author's Addresses Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN K.Kumaki et al. Expires - August 2006 [Page 12] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 Email: ke-kumaki@kddi.com Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 Saitama, 356-8502. Japan Email: otani@kddilabs.jp Shuichi Okamoto NICT JGN II Tsukuba Reserach Center 1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117 Tokyo, 100-0004, Japan E-mail :okamot-s@nict.go.jp Kazuhiro Fujihara NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan EMail: kazuhiro.fujihara@ntt.com Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan EMail: y.ikejiri@ntt.com 13.Intellectual Property Statement 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. K.Kumaki et al. Expires - August 2006 [Page 13] Requirements for IP/MPLS-GMPLS interworking in support of GMPLS deployment February 2006 Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. K.Kumaki et al. Expires - August 2006 [Page 14]