Network Working Group Eric C. Rosen Internet Draft Bob Thomas Expiration Date: September 2000 Lance Levine Carol Iturralde George Swallow Cisco Systems, Inc. March 2000 MPLS Profiles draft-rosen-mpls-profiles-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 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 The MPLS protocol specifications provide a large number of options, and it can be difficult to know exactly which protocol messages, objects, and procedures must be supported in order to provide some particular application of MPLS, or in order to interoperate with some other implementation. This document specifies a number of MPLS "Profiles". Each Profile is a subset of the full MPLS functionality, specified in enough detail to ensure that two implementations of a given Profile will interoperate. This document also specifies which Profiles may be used for which purposes. In the future, it is hoped that specifications for the applications of MPLS will specify the Rosen, et al. [Page 1] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 Profiles that must be implemented in order to support the application. Table of Contents 1 Introduction ........................................... 2 2 Profile HH: Intra-Domain Hop-by-Hop LSP Setup .......... 3 2.1 Part 1: LDP: Discovery, Session Estab. & Maintenance ... 3 2.2 Part 2: Frame-Based LSRs ............................... 4 2.3 Part 3: ATM-LSRs ....................................... 4 3 Profile TE/RSVP: Explicit Path Setup ................... 5 3.1 Part 1: RSVP signalling and reliability extensions ..... 6 3.2 Part 2: IGP extensions for constraint-based routing .... 7 3.3 Part 3: RSVP Refresh Reduction ......................... 7 4 Profile BGP: BGP Label Distribution .................... 7 5 References ............................................. 8 6 Authors' Addresses ..................................... 8 1. Introduction The MPLS protocol specifications provide a large number of options, and it can be difficult to know exactly which protocol messages, objects, and procedures must be supported in order to provide some particular application of MPLS, or in order to interoperate with some other implementation. This document specifies a number of MPLS "Profiles". Each Profile is a subset of the full MPLS functionality, specified in enough detail to ensure that two implementations of a given Profile will interoperate. This document also specifies which Profiles may be used for which purposes. In the future, it is hoped that specifications for the applications of MPLS will specify the Profiles that must be implemented in order to support the application. This document specifies three Profiles: a Hop-by-Hop Profile ("Profile HH"), a Traffic Engineering Profile ("Profile TE/RSVP"), and a BGP label distribution Profile ("Profile BGP"). Some of these Profiles have variants, which are also described. Rosen, et al. [Page 2] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 2. Profile HH: Intra-Domain Hop-by-Hop LSP Setup This Profile supports the basic LDP mechanisms that are needed for setting up LSPs in a hop-by-hop manner [MPLS-LDP] within a single routing domain. This Profile consists of three parts: - Part 1 consists of the basic LDP mechanisms for discovery, session establishment, and session maintenance. - Part 2 consists of messages and procedures which are to be used by Frame-based LSRs. - Part 3 consists of messages and procedures which are to be used by ATM-LSRs. Every implementation of this Profile will support Part 1. Every implementation on a Frame-based LSR will support Part 2. Every implementation on an ATM-LSR will support Part 3. When it is stated that a particular implementation supports Profile HH, it must be stated whether it supports Part 2, Part 3, or both. 2.1. Part 1: LDP: Discovery, Session Estab. & Maintenance Part 1 of Profile 1 consists of the following: - LDP Hello Message with: * Common Hello Parameters TLV, including + T-bit, targeted Hello + R-bit, Request Send Targeted Hello * Optional Parameters: Transport Address TLV - LDP Initialization Message with: * Common Session Parameters TLV, with support for all fields * Optional Parameters: ATM Session Parameters TLV, with support for all fields and support for all settings EXCEPT the following settings of the M field: + VP Merge + VP & VC Merge Rosen, et al. [Page 3] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 - LDP Keep Alive Message - LDP Notification Message with Status TLV - LDP Backoff Mechanism for session setup failures - TCP MD5 Signature Option 2.2. Part 2: Frame-Based LSRs A Frame-based LSR which supports Profile 1 will support Part 1 and Part 2. Part 2 consists of the following. - Unsolicited Downstream label distribution - Independent Control - Liberal Label Retention Mode - LDP Address Message with Address List TLV - LDP Address Withdraw Message with Address List TLV - Label Mapping Message with: * Prefix FEC for FEC TLV, address family IPv4 * Generic Label TLV - Label Request Message with Prefix FEC for FEC TLV, address family IPv4 - Label Withdraw Message with: * Prefix FEC for FEC TLV, address family IPv4 * Generic Label TLV - Label Release Message with: * Prefix FEC for FEC TLV, address family IPv4 * Generic Label TLV 2.3. Part 3: ATM-LSRs An ATM-LSR which supports Profile 1 will support Part 1 and Part 3. Part 3 consists of the following. Rosen, et al. [Page 4] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 - Downstream on Demand label distribution - Ordered Control - Conservative Label Retention - Label Request Message with: * Prefix FEC type for FEC TLV, address family IPv4 * HopCount TLV * PathVector TLV (used only if Loop Detection is configured) - Label Mapping Message with: * Prefix FEC for FEC TLV, address family IPv4 * ATM Label TLV * Label Request Message ID TLV * HopCount TLV * PathVector TLV (used only if Loop Detection is configured) - Label Abort Request Message with: * Prefix FEC for FEC TLV, address family IPv4 * Label Request Message ID TLV - Label Withdraw Message with: * Prefix FEC for FEC TLV, address family IPv4 * ATM Label TLV - Label Release Message with: * Prefix FEC for FEC TLV, address family IPv4 * ATM Label TLV 3. Profile TE/RSVP: Explicit Path Setup This Profile is supported by systems which need to participate in LSP setup for the purpose of traffic engineering. Note that a system may support both Profile HH and Profile TE/RSVP if some of its LSPs are traffic engineered, and some are set up hop-by- hop. This Profile has three Parts: - Part 1 consists of RSVP extensions which are used to enable RSVP to signal the LSP setup along an explicitly specified path. - Part 2 consists of IGP extensions which are used to distribute the information needed in order to support constraint-based routing for OSPF [TE-OSPF] and/or the information needed in order to support constraint-based routing for ISIS [TE-ISIS]. Rosen, et al. [Page 5] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 - Part 3 consists of RSVP extensions to reduce the "refresh overhead" of RSVP. Every implementation of Profile TE/RSVP will support Part 1. If an implementation is to support constraint-based routing, then it must implement Part 2; otherwise it need not. Part 3 is optional, but recommended. When stating that a particular implementation supports Profile TE/RSVP, it must be stated whether it supports Parts 2 and/or 3. If it supports Part 2, it must be stated whether it supports Part 2(OSPF) and/or Part 2(IS-IS). 3.1. Part 1: RSVP signalling and reliability extensions The RSVP signalling extensions are defined in [MPLS-RSVP]. The following RSVP signalling extensions are supported: - Shared Explicit (SE) Style reservations - Processing received Fixed Filter (FF) Style reservations - Handling Label objects in Resv messages - Handling Label Request object: * in Frame LSRs, without label range * in ATM-LSRs, with ATM label range - Explicit Route Object, with Strict and Loose IPv4 Prefix Subobjects (Other subobjects propagated only.) - Need not be able to add subobjects to ERO - RRO - Loop Detection - Sender Template Object - Filter Specification Object Rosen, et al. [Page 6] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 - Reroute Procedure - Session Attribute Object This Part also includes the RSVP reliability extensions from [RSVP- RFSH]. It does NOT, however, include the use of Bundle message or the procedures for refresh reduction. This Part also includes support for the Controlled Load Service [CLOAD]. This Part also includes support for the Hello Protocol. 3.2. Part 2: IGP extensions for constraint-based routing Part 2 has two variants: OSPF extensions and IS-IS extensions. Part 2(OSPF) is described in [TE-OSPF]. Part 2(IS-IS) is described in [TE-ISIS]. A system may support either or both of these. Of course, a system which supports only Part 2(IS-IS) will not be very useful in an environment where OSPF is the routing algorithm. 3.3. Part 3: RSVP Refresh Reduction An implementation which supports Part 3 supports [RSVP-RFSH] in its entirety, with the exception that bundle messages are never generated. 4. Profile BGP: BGP Label Distribution The procedures for BGP label distribution are described in [MPLS- BGP]. Profile BGP is really a family of profiles, one for each pair. LSRs are not expected to support any of these profiles unless they are intended to support an application which requires it. When it is stated that a particular implementation supports Profile BGP, AFI/SAFI pairs for which BGP label distribution is supported must be specified. As an example, systems which support the BGP/MPLS style of VPN described in RFC 2745 should support Profile BGP with AFI=1 and SAFI=128. This Profile should generally be supported along with either Profile Rosen, et al. [Page 7] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 HH or Profile TE/RSVP or both. If a system supports only Profile BGP, it will only be able to distribute labels to BGP peers that are directly adjacent to it, and this has very little utility. 5. References [CLOAD] "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [MPLS-BGP] "Carrying Label Information in BGP-4", draft-ietf-mpls- bgp4-mpls-04.txt, 1/00 [MPLS-LDP] "LDP Specification", draft-ietf-mpls-ldp-06.txt, 10/99 [MPLS-RSVP], "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinivasan, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, 9/99 [RSVP-RFSH], "RSVP Refresh Overhead Reduction Extensions", Berger, Gan, Swallow, Pan, Tommasi, Molendini, draft-ietf-rsvp-refresh- reduct-02.txt, 1/00 [TE-OSPF] "Traffic Engineering Extensions to OSPF", Katz, Yeung draft-katz-yeung-ospf-traffic-01.txt, 10/99 [TE-ISIS] "IS-IS Extensions for Traffic Engineering",Smit, Li draft- ietf-isis-traffic-01.txt, 6/99 6. Authors' Addresses Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Bob Thomas Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: rhthomas@cisco.com Rosen, et al. [Page 8] Internet Draft draft-rosen-mpls-profiles-00.txt March 2000 Lance Levine Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: llevine@cisco.com Carol Iturralde Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: cei@cisco.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: swallow@cisco.com Rosen, et al. [Page 9]