Network Working Group Internet Draft Kenji Kumaki Category: Informational KDDI Corporation Expires: December 27, 2006 Tomohiro Otani KDDI R&D Labs Shuichi Okamoto NICT Kazuhiro Fujihara Yuichi Ikejiri NTT Communications June 26, 2006 Requirements for MPLS-TE/GMPLS interworking draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-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. This Internet-Draft will expire on December 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract K.Kumaki et al. Expires - December 2006 [Page 1] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 This document describes Service Provider requirements for MPLS- TE/GMPLS interworking. The main objective is to allow the operation of an MPLS-TE network as a client network over a GMPLS network. The GMPLS network may be a packet or non-packet network. Specification of solutions is out of scope for 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...................................................2 2. Terminology....................................................3 3. Problem Statement..............................................3 4. Reference model................................................4 5. Detailed Requirements..........................................4 5.1 Use of GMPLS optical network resources in MPLS-TE networks.5 5.2 Mapping signaling information between MPLS-TE and GMPLS....5 5.3 Establishment of GMPLS LSPs triggered by end-to-end MPLS-TE LSPs signaling.................................................5 5.4 Establishment of end-to-end MPLS-TE LSPs having diverse paths over GMPLS optical network.....................................5 5.5 Advertisement of TE information via GMPLS optical domain...5 5.6 Selective advertisement of TE information via a border node6 5.7 Interworking of MPLS-TE and GMPLS protection...............6 5.8 Failure recovery...........................................6 5.9 Complexity and Risks.......................................6 5.10 Scalability consideration.................................6 5.11 Performance consideration.................................7 5.12 Management consideration..................................7 6. Security Considerations........................................7 7. IANA Considerations............................................7 8. Normative References...........................................7 9 .Acknowledgments................................................8 10.Author's Addresses.............................................8 11.Intellectual Property Statement................................8 1. Introduction Recently, the deployment of a GMPLS network is planned or under investigation among many service providers, and some of very advanced K.Kumaki, et al. Expires December 27, 2006 [Page 2] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 research networks have already been operated based on GMPLS technology. GMPLS is developed as an extension of MPLS-TE and allows control a transport network consisting of TDM cross-connect, optical/lambda switches, and fibers. By introducing GMPLS technology, some service providers expect that MPLS-TE network connectivity is effectively and reliably established over the GMPLS network. If MPLS- TE 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 MPLS-TE networks. Currently, there is no clear definition and standardization work to interwork between MPLS-TE routers and GMPLS routers or switches, i.e. , between MPLS-TE networks and GMPLS networks. In order to accelerate the deployment of GMPLS technology, MPLS-TE/GMPLS interworking is a key. In order to create the definition of MPLS-TE/GMPLS interworking technology, the concrete requirement is preferably defined from the point of operational experience of MPLS-TE/GMPLS networks and future view on these technologies by collecting the input and requirements from various service providers. Considering such environment, this document focuses on the requirement of MPLS-TE/GMPLS interworking especially in support of GMPLS deployment. 2. Terminology LSP: Label Switched Path MPLS-TE LSP: Multi Protocol Label Switching Traffic Engineering LSP PSC: Packet Switch Capable LSC: Lambda Switch Capable Head-end LSR: ingress LSR Tail-end LSR: egress LSR LSR: Label Switching Router 3. Problem Statement GMPLS technology is deployed or will be deployed in various forms to provide a highly efficient transport for existing MPLS-TE networks, depending on the deployment choices of each service provider. A GMPLS K.Kumaki, et al. Expires December 27, 2006 [Page 3] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 network may provide connectivity in terms of LSPs that are used as TE links by the MPLS-TE network to support MPLS-TE LSPs. In terms of MPLS-TE/GMPLS signaling, although GMPLS LSPs may be set up triggered by the signaling of MPLS-TE LSPs, the clear mechanism of how to interwork has not yet been defined. Feature richness of MPLS- TE and GMPLS technology allows service providers to use a set of options on how GMPLS services can be used by MPLS-TE networks. In this document, the requirement for MPLS-TE/GMPLS interworking is presented with some operations considerations associated with use of GMPLS services by MPLS-TE 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 MPLS-TE routers. Interworking point Interworking point ^ ^ | | GMPLS LSPs |MPLS-TE LSPs |------------------------------|MPLS-TE LSPs | |-----------------|------------------------------|-----------------| | |------------------------------| | MPLS-TE network | Optical Transport |MPLS-TE network | (GMPLS) Network | +---------+ +--------+ +------+ +------+ +--------+ +---------+ | | | | | | | | | | | | | MPLS-TE +--+ GMPLS +--+ +--+ +--+ GMPLS +--+ MPLS-TE | | Service | |Enabled | | OXC1 | | OXC2 | |Enabled | | Service | | Network +--+ router | | +--+ | | router +--+ Network | | | | | | | | | | | | | +---------+ +--------+ +------+ +------+ +--------+ +---------+ Figure 1. Reference model of MPLS-TE/GMPLS interworking MPLS-TE network connectivity is provided through a GMPLS LSP which is created between GMPLS routers. This document defines the requirements for how the MPLS-TE network and the GMPLS network are interworked in order to effectively operate the entire network and smoothly deploy the GMPLS network. 5. Detailed Requirements This section describes detailed requirements for MPLS-TE/GMPLS interworking in support of GMPLS deployment. K.Kumaki, et al. Expires December 27, 2006 [Page 4] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 5.1 Use of GMPLS optical network resources in MPLS-TE networks The solution SHOULD provide the ability to make effective use of GMPLS optical network resources (e.g. bandwidth, protection & recovery) by the MPLS-TE service networks. The GMPLS network MUST be able to support more than one MPLS-TE network. 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. 5.2 Mapping signaling information between MPLS-TE and GMPLS The solution SHOULD provide the ability to map signaling information between MPLS-TE and GMPLS. From an MPLS-TE signaling point of view, the routers in MPLS-TE domain should be able to signal over GMPLS optical domain. In this case, an interworking between MPLS-TE and GMPLS protocol is required. 5.3 Establishment of GMPLS LSPs triggered by end-to-end MPLS-TE LSPs signaling The solution SHOULD provide the ability to establish end-to-end MPLS- TE LSPs over a GMPLS optical network. GMPLS LSPs SHOULD be set up triggered by the signaling of MPLS-TE LSP. 5.4 Establishment of end-to-end MPLS-TE LSPs having diverse paths over GMPLS optical network The solution SHOULD provide the ability to establish end-to-end MPLS-TE LSPs having diverse paths including diverse GMPLS LSPs corresponding to the request of the head-end MPLS LSR for protection of MPLS-TE LSPs. The GMPLS optical network SHOULD assure the diversity of GMPLS LSPs, even if their ingress nodes in GMPLS optical network are different. 5.5 Advertisement of TE information via GMPLS optical domain The solution SHOULD provide the ability to control advertisements of TE information belonging to MPLS-TE service networks across the GMPLS optical network. The TE information within the same MPLS-TE service networks needs to be exchanged in order that a head end LSR of the MPLS-TE network can compute an LSP to a tail end LSR that is reached over the GMPLS optical network. On the other hand, the TE information belonging to one MPLS-TE service network MUST NOT be advertised to other MPLS-TE service K.Kumaki, et al. Expires December 27, 2006 [Page 5] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 networks to preserve confidentiality and security, and in order to avoid establishing undesirable LSPs. 5.6 Selective advertisement of TE information via a border node The solution SHOULD provide the ability to distribute TE reachability information from the GMPLS optical network to MPLS-TE networks selectively, which are useful for the head-end MPLS routers to compute MPLS-TE LSPs. 5.7 Interworking of MPLS-TE and GMPLS protection The solution SHOULD provide the ability to select GMPLS protection types for the GMPLS LSPs according to protection options defined for the protected MPLS-TE LSPs. If MPLS-TE LSPs are protected using MPLS FRR [RFC4090], then when an FRR protected packet LSP is signaled, we SHOULD be able to select protected GMPLS LSPs in the GMPLS optical network. In terms of MPLS protection, the MPLS-TE Path message can include some flags in the FAST REROUTE object and SESSION_ATTRIBUTE object. In terms of GMPLS protection, there are both signaling aspects [RFC3471] [RFC3473] and routing aspects [RFC4202]. 5.8 Failure recovery The solution SHOULD provide failure recovery in the GMPLS optical domain without impacting MPLS-TE domain and vice versa. In case that failure in the GMPLS optical domain associates with MPLS-TE domain, some kind of notification of the failure may be transmitted to MPLS-TE domain and vice versa. 5.9 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. 5.10 Scalability consideration The solution MUST have a minimum impact on network scalability for deploying GMPLS technology in the existing MPLS-TE networks. Scalability of GMPLS deployment in the existing MPLS-TE networks MUST address the following consideration. - the number of GMPLS capable nodes (e.g. the number of non-PSC GMPLS capable nodes) - the number of MPLS-TE capable nodes - the number of GMPLS LSPs K.Kumaki, et al. Expires December 27, 2006 [Page 6] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 - the number of MPLS-TE LSPs 5.11 Performance consideration The solution SHOULD be evaluated with regard to the following criteria. - 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 5.12 Management consideration Manageability of MPLS-TE/GMPLS interworking MUST addresses the following consideration. - need for a MIB module for control plane and monitoring - need for diagnostic tools MIB for an interworking between MPLS-TE and GMPLS protocol SHOULD be implemented. In case that an interworking between MPLS-TE and GMPLS protocol is done, a failure between them MUST be detected. 6. Security Considerations We will write security considerations in next version. 7. IANA Considerations This requirement document makes no requests for IANA action. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. K.Kumaki, et al. Expires December 27, 2006 [Page 7] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 [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. 9 .Acknowledgments The author would like to express the thanks to Raymond Zhang, Adrian Farrel for their helpful and useful comments and feedback. 10.Author's Addresses Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN 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 11.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 K.Kumaki, et al. Expires December 27, 2006 [Page 8] draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-01 December 2006 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. 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 December 27, 2006 [Page 9]