CCAMP Working Group Kenji Kumaki KDDI Corporation Cisco Systems Zafar Ali Cisco Systems Tomohiro Otani KDDI R&D Laboratories, Inc. Mallik Tatipamula Cisco Systems Internet Draft Category: Standard Track Expires: August 2005 February 2005 MPLS/ GMPLS Interworking draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 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. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. K. Kumaki, et al. Page 1 2/14/2005 [Page 1] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 Abstract In order to deploy GMPLS technology in the existing IP/ MPLS networks, some interworking aspect of GMPLS/ MPLS needs to be addressed. One of the important aspects of MPLS/ GMPLS interworking is ability to effectively use GMPLS services in IP/ MPLS networks. This includes ability to specify GMPLS LSPs in signaling requests based on the type of the setup desired, as well as considerations for the operation aspects of using GMPLS LSPs. In this draft, we highlight some MPLS/ GMPLS interworking requirements and propose solutions to address them. We also highlight some operation aspects of the possible solution and provide applicability statement for the available options. 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]. Routing Area ID Summary (This section to be removed before publication.) SUMMARY This document addresses some MPLS/ GMPLS Interworking aspects. WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? This work fits in the context of MPLS/ GMPLS interworking. WHY IS IT TARGETED AT THIS WG? This document is targeted at ccamp as it addresses some MPLS/ GMPLS Interworking aspects. RELATED REFERENCES Please refer to the reference section. Table of Contents 1. Introduction...................................................3 K. Kumaki, et al. Page 2 2/14/2005 [Page 2] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 2. Static vs. signaling triggered dynamic FA-LSPs..............3 3. MPLS/ GMPLS LSP Priority Mapping............................4 3.1 OSPF extensions for Link Priority Identification...........5 3.2 ISIS extensions for Link Priority Identification...........6 4. Signaling Protected MPLS LSPs..................................7 5. Applicability...............................................7 5.1 Applicability of the Priority Management Options...........7 5.2 Applicability of the Signaling Triggered Dynamic FA-LSP....8 6. Backward Compatibility Note....................................8 7. Security Considerations........................................8 8. IANA Considerations............................................9 9. Full Copyright Statement.......................................9 10. Intellectual Property.........................................9 11. IPR Disclosure Acknowledgement................................9 12. Reference....................................................10 12.1 Normative Reference......................................10 12.2 Informative Reference....................................10 13. Author's Addresses...........................................10 1. Introduction Introduction of GMPLS technology in existing IP/ MPLS networks and migration of IP/ MPLS services to GMPLS core poses some new requirements that does not exists while using point to point physical links in the core network. Specifically, GMPLS technology is equipped with features like priority management and protection and restoration. These features have some implications on how IP/ MPLS networks can utilize forwarding and/ or routing adjacencies established on top of GMPLS networks. In this draft, we highlight these implications/ requirements and propose solutions to address them. In this fashion this draft complements [GMPLS-migration] draft, which formalizes the MPLS/ GMPLS interworking problem. Using the terminology used in [GMPLS-migration], this draft addresses only MPLS-GMPLS-MPLS case. 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. However, there are some operational considerations and pros and cons associated with the individual options. This draft also highlights some operations considerations associated with use of GMPLS services by IP/ MPLS networks. 2. Static vs. signaling triggered dynamic FA-LSPs From signaling prospective, clearly there are two alternatives in which setup for GMPLS tunnel can be triggered: Static (pre- K. Kumaki, et al. Page 3 2/14/2005 [Page 3] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 configured) and Dynamic (on-demand based on signaling setup request for MPLS LSP). Decision to establish new Static GMPLS LSPs are made either by the operator or automatically (e.g., using features like TE auto-mesh). In either case, Static FA-LSP are established and advertised prior to setup of MPLS LSPs using them in the ERO. In case of static FA-LSP, if MPLS LSP setup request (MPLS RSVP Path message) cannot be satisfied by existing Static FA-LSPs, it is rejected. Dynamic FA-LSP is triggered by RSVP Path message for setting up an MPLS LSP. Please note that dynamic FA-LSPs can be virtual FAs from routing prospective. In either case, LSP creation from signaling prospective is triggered by the MPLS RSVP Path message received at a MPLS/ GMPLS border router. In the case of Static or Virtual FA-LSPs, the FA may be specified in an ERO encoded as strict ERO. In the case where FA-LSPs are dynamic and are not advertised as virtual links in the MPLS TE topology, MPLS signaling request (MPLS RSVP Path message) contains a loose ERO, and GMPLS LSP selection is a local decision at the border router. In the case of Static or Virtual FA-LSPs, a signaling request may also be encoded as loose ERO. When the border router receives the signaling setup request and determines that in order for it to extend the loose ERO content, it needs to create GMPLS FA-LSP. Consequently, it signals a GMPLS LSP respecting MPLS/ GMPLS signaling interworking aspects discussed in sections 4.1 and 4.2. Once the GMPLS FA-LSP is fully established, the ERO contents for the MPLS signaling setup request are extended to use the GMPLS LSP and signaling setup for the FA-LSP are carried in-band of the GMPLS LSP. The GMPLS LSP can then also be advertised as an FA- LSP in MPLS TE topology or an IGP adjacency can be brought up on the GMPLS LSP. 3. MPLS/ GMPLS LSP Priority Mapping Both MPLS and GMPLS LSPs are signaled for specific setup and hold priority, based on the importance of traffic carried over them. For proper operation of the network, it is desirable to create/ use GMPLS LSPs of specified setup and hold priority, based on the setup and hold priority of the MPLS LSPs using them. In the following, we discuss several approaches possible for mapping setup and hold priority of MPLS LSPs to GMPLS FA-LSPs. K. Kumaki, et al. Page 4 2/14/2005 [Page 4] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 1) Exact Match: In this case setup and hold priority of the GMPLS FA- LSP is same as setup and hold priority of MPLS LSP using it. In other words, GMPLS LSP Priority set = MPLS LSP Priority set. 2) Better Priority: In this case GMPLS FA-LSP can be of setup and hold priority equal better than the MPLS LSP using it. In other words, GMPLS LSP Priority set <= MPLS LSP Priority set. 3) Dynamic Priority for GMPLS LSP: In this case priority of GMPLS LSP is dynamically changed based on priority of the MPLS LSPs using it. In other words, GMPLS LSP Priority set = min (MPLS LSP Priority set). 4) Any to Any Mapping Matrix: Based on some policies, it is possible to have any-to-any mapping for MPLS/ GMPLS priority mapping at the MPLS/ GMPLS border router. 5) No Priority Management in GMPLS core: In this simple minded approach all GMPLS LSPs can be establish with setup and hold priority of "0", i.e., the GMPLS LSPs are already set as better match. In this case, priority management is handled purely at MPLS layer, with GMPLS network providing L1 connectivity without priority management. In the case of a strict ERO, a remote MPLS node can only select an FA-LSP during its SPF calculation if it knows the setup and hold priority of the GMPLS FA-LSP. In the following, we propose some routing extension that can be used by the border routers to advertise setup and hold priorities of the FA-LSPs or ability/ wiliness to dynamically change setup and hold priority of the FA-LSP. 3.1 OSPF extensions for Link Priority Identification This section we define the enhancements to the TE properties of GMPLS TE links that can be announced in OSPF TE LSAs [OSPF-TE] to carry link state information regarding setup and hold priority of the FA- LSP. Specifically, we add the following sub-TLV to the Link TLV: Sub-TLV Type Length Name TBD 4 Link Priority Identifiers Link Priority Identifiers A Link Priority Identifiers is a sub-TLV of the Link TLV. This identifier carries the setup and hold priority for the FA-LSP links. The type of this sub-TLV is TBD, and length is four octets. The following Figure illustrates encoding of the link priority Identifiers sub-TLV. K. Kumaki, et al. Page 5 2/14/2005 [Page 5] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio |D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value field of this sub-TLV contains one octet of setup priority of the FA-LSP, followed by one octet of hold priority of the FA-LSP. Based on a local policy, advertising LSR may be able to dynamically adjust priority of the FA-LSP, in which case it sets ôDö bit in the following octet (as shown above). The remaining bits SHOULD be set to zero by the sender, and SHOULD be ignored by the receiver. This setup and hold priority parameters are copied from the values carried in the RSVP Session Attribute Object when the FA-LSP is signaled. Please refer to [RFC3209] for details on the setup and hold priorities parameters and how they are encoded. Inclusion of this sub-TLV is not needed for the physical links, however one may carry it with setup and hold priorities set to 0. 3.2 ISIS extensions for Link Priority Identification This section we define the enhancements to the extended IS reachability TLV (see [ISIS-TE]). Specifically, we add the following sub-TLVs: Sub-TLV Type Length Name TBD 4 Link Priority Identifiers Link Priority Identifiers A Link Priority Identifiers is a sub-TLV of the extended IS reachability TLV. This identifier carries the setup and hold priority for the FA-LSP links. The type of this sub-TLV is TBD, and length is four octets. The following Figure illustrates encoding of the Link Priority Identifiers sub-TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio |D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K. Kumaki, et al. Page 6 2/14/2005 [Page 6] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 The value field of this sub-TLV contains one octet of setup priority of the FA-LSP, followed by one octet of hold priority of the FA-LSP. Based on a local policy, advertising LSR may be able to dynamically adjust priority of the FA-LSP, in which case it sets ôDö bit in the following octet (as shown above). The remaining bits SHOULD be set to zero by the sender, and SHOULD be ignored by the receiver. The setup and hold priority parameters are copied from the values carried in the RSVP Session Attribute Object when the FA-LSP is signaled. Please refer to [RFC3209] for details on the setup and hold priorities parameters and how they are encoded. Inclusion of this sub-TLV is not needed for the physical links, however one may carry it with setup and hold priorities set to 0. 4. Signaling Protected MPLS LSPs When MPLS LSPs are protected using MPLS-FRR mechanism [TE-FRR] and it may be desired to signal MPLS LSP such that it uses protected GMPLS tunnel FA-LSPs. In this section we discuss MPLS/ GMPLS interworking aspect for protected MPLS LSPs. In the case of loose ERO, where selection of GMPLS FA-LSP is a left for the border nodes and ôLocal protection desiredö flag of the SESSION_ATTRIBUTE object is set, the border router SHOULD try to map the signaling setup request to a GMPLS LSP which is protected within GMPLS domain. However, in the case of strict ERO, the selection of GMPLS FA-LSP is based on the contents of the ERO and ôLocal protection desiredö flag is ignored. 5. Applicability In this section we discuss some operational considerations and pros and cons associated with the individual options listed in Section 3. 5.1 Applicability of the Priority Management Options In section 4.1, various options from exact match to no priority management in GMPLS network are discussed. This section provides an applicability of these options. The benefit of Priority Management in GMPLS Core comes at the cost of bandwidth fragmentation. E.g., in simplest approach of exact match, we need at least as many GMPLS LSPs, as there are priority combination in the network, while the other extreme of no priority management in GMPLS network does allow full aggregation of MPLS traffic on GMPLS FAs, i.e. avoids bandwidth fragmentation. If IGP adjacency is to be established over the GMPLS LSPs, having more GMPLS K. Kumaki, et al. Page 7 2/14/2005 [Page 7] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 LSP leads to more links in the IGP/ IP topology. The same is true of MPLS TE topology with the exception that FA-LSPs can be bundled to avoid flooding of multiple TE links. With priority management within GMPLS network, there is a danger of creating oscillations in the IP/MPLS network using GMPLS. This is because when a new FA-LSP is established based on a local routing decision made at the border router; we can have undesirable preemption affecting MPLS LSPs carried over the GMPLS LSP that is being preempted. This can have cascading affect leading to oscillations on the operation of MPLS traffic. 5.2 Applicability of the Signaling Triggered Dynamic FA-LSP In this section, we discussed applicability of static vs. dynamic FA- LSPs. It is important to realize that we can have FA-LSPs that are created dynamically based on triggers like configuration, link utilization level, etc. However, in the context of this document, such FA-LSPs are considered as static FAs. In this document, the term dynamic FA-LSPs are used for FA-LSPs that are triggered by RSVP Path message for MPLS LSP. Signaling triggered dynamic FA-LSPs are addressing a problem space where traffic pattern cannot be predicted or objective is to optimize operations of the network based on actually signaled request rather than predicted use of the network resource (i.e., off-line traffic engineering). The problem with the use of signaling triggered dynamic FA-LSPs is that we loose ability to better aggregate the traffic request at the border routers. This leads to potential cases of bandwidth fragmentation inside GMPLS core, which has disadvantages discussed in Section 4.2. Furthermore, signaling triggered dynamic FA-LSPs coupled with preemption can lead to oscillations in the operation of the network. This is because when a new FA-LSP is dynamically established based on a local routing decision made at the border router; we can have undesirable preemption affecting MPLS LSPs carried over the GMPLS LSP that is being preempted. This can have cascading affect leading to oscillations on the operation of MPLS traffic. 6. Backward Compatibility Note The procedure presented in this document is backward compatible with [RFC3630], [RFC3784], [RFC3209] and [RFC3473]. 7. Security Considerations K. Kumaki, et al. Page 8 2/14/2005 [Page 8] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 This document does not introduce new security issues. 8. IANA Considerations Sub-TLV type for Link Priority Identifiers is to be assigned. 9. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 10. Intellectual Property 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. 11. IPR Disclosure Acknowledgement K. Kumaki, et al. Page 9 2/14/2005 [Page 9] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 12. Reference 12.1 Normative Reference [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, RFC 3209, December 2001. [OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, S. Bradner, March 1997. [GMPLS-mig] IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration, draft-oki-ccamp-gmpls-ip-interworking-04.txt, D. Brungard, et al. 12.2 Informative Reference [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, Braden, et al, September 1997. [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, L. Berger, et al, January 2003. [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, L. Berger, et al, January 2003. [TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, August 2004 (Work in Progress). 13. Author's Addresses Kenji Kumaki KDDI Corporation K. Kumaki, et al. Page 10 2/14/2005 [Page 10] draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt Feb. 2005 Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN E-mail : ke-kumaki@kddi.com Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Phone: 613 254 3498 Kanata, Ontario Email: zali@cisco.com Canada K2K 3E8 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 Mallik Tatipamula Cisco systems, Inc., 170 W. Tasman Drive San Jose, CA 95134 Phone: 408 525 4568 USA. Email: mallikt@cisco.com K. Kumaki, et al. Page 11 2/14/2005 [Page 11]