MPLS WG Loa Andersson Internet Draft Bilel Jamoussi Expiration Date: February 2000 Nortel Networks Corp. Muckai Girish SBC Technology Resources Inc. Tom Worster Nokia October 1999 MPLS Capability Set draft-loa-mpls-cap-set-01.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 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 Several protocols might be used for Label Distribution in an MPLS network, e.g. Label Distribution Protocol (LDP), including the part of LDP described in Constraint-Based LSP Setup using LDP, the BGP-4 and RSVP. The functionality defined in those protocols are to some extent overlapping, but also complementary. This document specifies a number of MPLS Capability sets that can be used to define what is needed from an MPLS implementation in order to interwork with other implementations. The number of Capability sets might change in the future. Andersson, et. al. [Page 1] Internet Draft MPlS Capability Set October, 1999 Table of Contents Abstract ..........................................................1 Table of Contents .................................................2 1. Introduction ...................................................2 2. Overview .......................................................2 3. MPLS Capability set ............................................3 4. Protocol and functional components .............................3 5. Defined MPLS Capability set ....................................3 5.1 MPLS Capability set #1 ........................................4 5.2 MPLS Capability set #2 ........................................4 5.3 MPLS Capability set #3 ........................................4 5.4 MPLS Capability set #4 ........................................5 5.5 MPLS Capability set #5 ........................................5 5.6 MPLS Capability set #6 ........................................5 5.7 MPLS Capability set #7 ........................................5 5.8 MPLS Capability set #8 ........................................5 5.9 MPLS Capability set #9 ........................................5 5.10 MPLS Capability set #42 ......................................6 5.11 Future extensibility .........................................6 6. Security .......................................................6 7. Acknowledgements ...............................................6 8. References .....................................................6 1. Introduction The set of documents that constitute the MPLS standard, as it is being specified by the MPLS Working Group of IETF, offers several ways of setting up Label Switched Paths (LSP) for a number of applications, including support for traffic engineering and Virtual Private Networks. The Label Distribution Protocol (LDP) has been developed by the MPLS WG for the explicit task of doing Label Distribution. Other protocols, already in existence and originally developed for other purposes, have been adapted or extended to support Label Distribution. This draft addresses unicast functionality only, multicast is for further study. 2. Overview It has been frequently noted that the functionality supported by the most of the specifications of how you do Label Distribution, for most applications, are richer than necessary. MPLS implementations implementing parts of one specification or a mix of parts from several specifications will be viable. Andersson, et. al. February 2000 [Page 2] Internet Draft MPlS Capability Set October, 1999 As all implementations won't support all of the specified mechanisms for Label distribution specified in the MPLS standard. This introduces the requirement of a tool for describing the compliance between MPLS implementations. 3. MPLS Capability set This draft introduces the MPLS Capability set as a method of specifying the compliance of an implementation to the set of MPLS specifications and to other implementations. This draft gives an overview of what is needed, in terms of protocols and mechanism, to support the MPLS capability sets. 4. Protocol and functional components The following functional and protocol component are available in the protocols developed for and/or extended to do label distribution, [1], [2], [3] and [4]. All the specification listed below are worked on by the MPLS WG, and is still work in progress. Carrying Label Information in BGP-4 [1] Defines mechanisms for: - assigning labels to BGP routes Constraint based routing with LDP (CR-LDP) [2] Defines mechanisms for: - explicit routed LSPs - LSP set up with defined QoS Label Distribution Protocol (LDP) [4] Defines mechanisms for: - basic LDP mechanisms - LDP neighbor detection - LDP session initiation, maintenance and termination - loop detection - modes of label distribution defined in [5] - Downstream Unsolicited Independent Control - Downstream Unsolicited Ordered Control - Downstream On Demand Independent Control - Downstream On Demand Ordered Control Extensions to RSVP for LSP Tunnels [3] Defines mechanisms for: - explicit routed LSPs - dynamic distribution of labels (hop-by-hop mechanism) 5. Defined MPLS Capability set Andersson, et. al. February 2000 [Page 3] Internet Draft MPlS Capability Set October, 1999 An MPLS Capability set defines the set of components that has to be supported by an implementation claiming compatibility with the capability set. Currently there are 10 Capability sets defined. Although there sometimes/frequently is an obviously a relationship between the Capability set and an intended use, this draft doesn't state the intended use of or the application possible to support by the capability set. The intention is instead to give a reference framework that offers a possibility to classify compatibility of MPLS implementations. The Capability sets is atomic, i.e. it is not possible for an application to be compliant to part of a capability set. However it is possible for an application to be compliant with one or more capability sets. 5.1 MPLS Capability set #1 MPLS Capability set #1 includes the following components: - LDP basic mechanisms - LDP neighbor detection - LDP session initiation, maintenance and termination - CR-LDP strict explicit routed LSPs This Capability set supports explicit routed LSP set up, but does not allow loosely routed segments on an explicit route. Note that this capability set do not require the loop detection mechanism. 5.2 MPLS Capability set #2 MPLS Capability set #2 includes the following components: - LDP basic mechanisms - CR-LDP explicit routed LSPs - modes of label distribution defined in [5] - Downstream On Demand Ordered Control This Capability set supports explicit routing and allows loosely routed segments of an explicit route. 5.3 MPLS Capability set #3 MPLS Capability set #3 includes the following components: - LDP basic mechanisms - CR-LDP explicit routed LSPs - CR-LDP LSP set up with QoS - modes of label distribution defined in [5] - Downstream On Demand Ordered Control This Capability set supports explicit routing and allows loosely routed segments of an explicit route. Andersson, et. al. February 2000 [Page 4] Internet Draft MPlS Capability Set October, 1999 5.4 MPLS Capability set #4 MPLS Capability set #4 includes the following components: - LDP basic mechanisms - All the modes of label distribution defined in [5] This Capability set is label distribution as defined in [4]. 5.5 MPLS Capability set #5 MPLS Capability set #5 includes the following components: - LDP basic mechanisms - All the modes of label distribution defined in [5] - CR-LDP explicit routed LSPs - CR-LDP LSP set up with QoS This Capability set is label distribution as defined in [4] and [2] combined. 5.6 MPLS Capability set #6 MPLS Capability set #6 includes the following components: - LDP basic mechanisms - Downstream unsolicited independent control This Capability set emulates the behavior of a legacy best effort IP network. 5.7 MPLS Capability set #7 MPLS Capability set #7 includes the following components: - RSVP explicit routed LSPs - RSVP based dynamic distribution of labels This Capability set is label distribution as defined in [3]. 5.8 MPLS Capability set #8 MPLS Capability set #8 includes the following components: - RSVP explicit routed LSPs - LDP basic mechanisms - All the modes of label distribution defined in [5] This Capability set gives explicit routed LSPs and a hop-by-hop mechanism. 5.9 MPLS Capability set #9 MPLS Capability set #9 includes the following components: - Assigning label to BGP routes as defined in [1]. Andersson, et. al. February 2000 [Page 5] Internet Draft MPlS Capability Set October, 1999 This Capability set could be used with any of capability set 1 through 7, and will in that case give a possibility to support network hierarchy. It could also be used alone. 5.10 MPLS Capability set #42 MPLS Capability set #42 includes all of the components listed in section 4 of this draft. An LSR claiming 42 compliance should, with proper configuration, be able to inter work with any other LSR compliant with any of the capability sets. 5.11 Future extensibility The number or capability sets are not static, but might be increased or reduced as required, e.g. if the number of protocols specification that defines label distribution changes. If there is a need for any Capability set that has not been specified here it will be added. Likewise, if any of the defined Capabilities sets fall out of use it will be removed. 6. Security This draft does not introduce any new security issues to the various label distribution protocols. 7. Acknowledgements We would like to thank the members of the MPLS working group of the IETF, whose input and scrutiny of this document has been invaluable. 8. References 1 Y. Rehkter and E. Rosen, "Carrying Label Information in BGP-4" , work in progress, August 1998. 2 B. Jamoussi et. al., "Constraint-Based LSP Setup using LDP" work in progress, October 1999. 3 D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V Srinivasan, "Extensions to RSVP for LSP Tunnels", < draft-ietf- mpls-rsvp-lsp-tunnel>, work in progress, October 1999. 4 L. Andersson et al., "LDP specification", , work in progress, October 1999. 5 E. Rosen, A. Viswanathan, R. Callon,"Multiprotocol Label Switching Architecture", < draft-ietf-mpls-arch>, work in progress, September 1999. Andersson, et. al. February 2000 [Page 6] Internet Draft MPlS Capability Set October, 1999 9. Author's Addresses Loa Andersson Muckai K Girish Nortel Networks Corp. SBC Technology Resources, S:t Eriksgatan 115 4698 Willow Road PO Box 6701 Pleasanton, CA 94588 113 85 Stockholm Phone: (925) 598-1263 Tel: +46 8 508 835 00 Fax: (925) 598-1321 Fax: +46 8 508 835 01 Mgirish@tri.sbc.com Loa_andersson@nortelnetworks.com Tom Worster Bilel Jamoussi Nokia Nortel Networks Corp. 3 Burlington Woods Dr. 600 Technology Park Drive Suite 250 Billerica, MA 01821 Burlington MA 01803 USA USA +1 617 247 2624 phone: +1 978-288-4506 Tom.worster@nokia.com Jamoussi@nortelnetworks.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Andersson, et. al. February 2000 [Page 7]