From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5561.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc5561.txt (limited to 'doc/rfc/rfc5561.txt') diff --git a/doc/rfc/rfc5561.txt b/doc/rfc/rfc5561.txt new file mode 100644 index 0000000..daa3b1f --- /dev/null +++ b/doc/rfc/rfc5561.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group B. Thomas +Request for Comments: 5561 K. Raza +Updates: 5036 Cisco Systems, Inc. +Category: Standards Track S. Aggarwal + R. Aggarwal + Juniper Networks + JL. Le Roux + France Telecom + July 2009 + + + LDP Capabilities + +Abstract + + A number of enhancements to the Label Distribution Protocol (LDP) + have been proposed. Some have been implemented, and some are + advancing toward standardization. It is likely that additional + enhancements will be proposed in the future. This document defines a + mechanism for advertising LDP enhancements at session initialization + time, as well as a mechanism to enable and disable enhancements after + LDP session establishment. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + + + +Thomas, et al. Standards Track [Page 1] + +RFC 5561 LDP Capabilities July 2009 + + + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Conventions Used in This Document ..........................3 + 2. The LDP Capability Mechanism ....................................3 + 2.1. Capability Document ........................................4 + 3. Specifying Capabilities in LDP Messages .........................4 + 3.1. Backward Compatibility TLVs ................................6 + 4. Capability Message ..............................................6 + 5. Note on Terminology .............................................7 + 6. Procedures for Capability Parameters in Initialization + Messages ........................................................7 + 7. Procedures for Capability Parameters in Capability Messages .....8 + 8. Extensions to Error Handling ....................................9 + 9. Dynamic Capability Announcement TLV .............................9 + 10. Backward Compatibility ........................................10 + 11. Security Considerations .......................................10 + 12. IANA Considerations ...........................................11 + 13. Acknowledgments ...............................................11 + 14. References ....................................................11 + 14.1. Normative References .....................................11 + 14.2. Informative References ...................................11 + +1. Introduction + + A number of enhancements to LDP as specified in [RFC5036] have been + proposed. These include LDP Graceful Restart [RFC3478], Fault + Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for + Layer 2 circuits [RFC4447], a method for learning labels advertised + by next-next-hop routers in support of fast reroute node protection + [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for + signaling inter-area Label Switched Paths (LSPs) [RFC5283]. Some + have been implemented, and some are advancing toward standardization. + It is also likely that additional enhancements will be implemented + and deployed in the future. + + This document proposes and defines a mechanism for advertising LDP + enhancements at session initialization time. It also defines a + mechanism to enable and disable these enhancements after LDP session + establishment. + + + + + +Thomas, et al. Standards Track [Page 2] + +RFC 5561 LDP Capabilities July 2009 + + + LDP capability advertisement provides means for an LDP speaker to + announce what it can receive and process. It also provides means for + a speaker to inform peers of deviations from behavior specified by + [RFC5036]. An example of such a deviation is LDP Graceful Restart, + where a speaker retains MPLS forwarding state for LDP-signaled LSPs + when its LDP control plane goes down. It is important to point out + that not all LDP enhancements require capability advertisement. For + example, upstream label allocation requires capability advertisement, + but inbound label filtering, where a speaker installs forwarding + state for only certain Forwarding Equivalence Classes (FECs), does + not. + +1.1. 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 [RFC2119]. + + This document uses the terms "LDP speaker" and "speaker" + interchangeably. + +2. The LDP Capability Mechanism + + Enhancements are likely to be announced during LDP session + establishment as each LDP speaker advertises capabilities + corresponding to the enhancements it desires. + + Beyond that, capability advertisements may be used to dynamically + modify the characteristics of the session to suit the changing + conditions. For example, an LSR capable of a particular enhancement + in support of some "feature" may not have advertised the + corresponding capability to its peers at session establishment time + because the feature was disabled at that time. Later, an operator + may enable the feature, at which time the LSR would react by + advertising the corresponding capability to its peers. Similarly, + when an operator disables a feature associated with a capability, the + LSR reacts by withdrawing the capability advertisement from its + peers. + + The LDP capability advertisement mechanism operates as follows: + + - Each LDP speaker is assumed to implement a set of enhancements, + each of which has an associated capability. At any time, a speaker + may have none, one, or more of those enhancements "enabled". When + an enhancement is enabled, the speaker advertises the associated + capability to its peers. By advertising the capability to a peer, + the speaker asserts that it shall perform the protocol actions + specified for the associated enhancement. For example, the actions + + + +Thomas, et al. Standards Track [Page 3] + +RFC 5561 LDP Capabilities July 2009 + + + may require the LDP speaker to receive and process enhancement- + specific messages from its peer. Unless the capability has been + advertised, the speaker will not perform protocol actions specified + for the corresponding enhancement. + + - At session establishment time, an LDP speaker MAY advertise a + particular capability by including an optional parameter associated + with the capability in its Initialization message. + + - There is a well-known capability called Dynamic Capability + Announcement that an LDP speaker MAY advertise in its + Initialization message to indicate that it is capable of processing + capability announcements following a session establishment. + + If a peer had advertised the Dynamic Capability Announcement + capability in its Initialization message, then at any time + following session establishment, an LDP speaker MAY announce + changes in its advertised capabilities to that peer. To do this, + the LDP speaker sends the peer a Capability message that specifies + the capabilities being advertised or withdrawn. + +2.1. Capability Document + + When the capability advertisement mechanism is in place, an LDP + enhancement requiring LDP capability advertisement will be specified + by a document that: + + - Describes the motivation for the enhancement; + + - Specifies the behavior of LDP when the enhancement is enabled. + This includes the procedures, parameters, messages, and TLVs + required by the enhancement; + + - Includes an IANA considerations section that requests IANA + assignment of a code point (from TLV Type namespace) for the + optional capability parameter corresponding to the enhancement. + + The capability document MUST also describe the interpretation + and processing of associated capability data, if present. + +3. Specifying Capabilities in LDP Messages + + This document uses the term "Capability Parameter" to refer to an + optional parameter that may be included in Initialization and + Capability messages to advertise a capability. + + + + + + +Thomas, et al. Standards Track [Page 4] + +RFC 5561 LDP Capabilities July 2009 + + + The format of a "Capability Parameter" TLV is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F| TLV Code Point | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| Reserved | | + +-+-+-+-+-+-+-+-+ Capability Data | + | +-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where: + + U-bit: + Unknown TLV bit, as described in [RFC5036]. The value could be + either 0 or 1 as specified in the Capability document associated + with the given capability. + + F-bit: + Forward unknown TLV bit, as described in [RFC5036]. The value + of this bit MUST be 0 since a Capability Parameter TLV is sent + only in Initialization and Capability messages, which are not + forwarded. + + TLV Code Point: + The TLV type that identifies a specific capability. This is an + IANA-assigned code point (from TLV Type namespace) for a given + capability as requested in the associated capability document. + + S-bit: + The State Bit. It indicates whether the sender is advertising + or withdrawing the capability corresponding to the TLV code + point. The State Bit value is used as follows: + + 1 - The TLV is advertising the capability specified by the TLV + code point. + + 0 - The TLV is withdrawing the capability specified by the TLV + code point. + + Capability Data: + Information, if any, about the capability in addition to the TLV + code point required to fully specify the capability. + + + + + + +Thomas, et al. Standards Track [Page 5] + +RFC 5561 LDP Capabilities July 2009 + + + The method for interpreting and processing this data is specific + to the TLV code point and MUST be described in the document + specifying the capability. + + An LDP speaker MUST NOT include more than one instance of a + Capability Parameter (as identified by the same TLV code point) in an + Initialization or Capability message. If an LDP speaker receives + more than one instance of the same Capability Parameter type in a + message, it SHOULD send a Notification message to the peer before + terminating the session with the peer. The Status Code in the Status + TLV of the Notification message MUST be Malformed TLV value, and the + message SHOULD contain the second Capability Parameter TLV of the + same type (code point) that is received in the message. + +3.1. Backward Compatibility TLVs + + LDP extensions that require advertisement or negotiation of some + capability at session establishment time typically use TLVs that are + included in an Initialization message. To ensure backward + compatibility with existing implementations, such TLVs continue to be + supported in an Initialization message and are known in this document + as "Backward Compatibility TLVs". A Backward Compatibility TLV plays + the role of a "Capability Parameter" TLV; that is, the presence of a + Backward Compatibility TLV has the same meaning as a Capability + Parameter TLV with the S-bit set for the same capability. + + One example of a Backward Capability TLV is the "FT Session TLV" that + is exchanged in an Initialization message between peers to announce + LDP Fault Tolerance [RFC3479] capability. + +4. Capability Message + + The LDP Capability message is used by an LDP speaker to announce + changes in the state of one or more of its capabilities subsequent to + session establishment. + + + + + + + + + + + + + + + + +Thomas, et al. Standards Track [Page 6] + +RFC 5561 LDP Capabilities July 2009 + + + The format of the Capability message is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0| Capability (0x0202) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TLV_1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | . . . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TLV_N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where TLV_1 through TLV_N are Capability Parameter TLVs. The S-bit + of each of the TLVs specifies the new state for the corresponding + capability. + + Note that Backward Compatibility TLVs (see Section 3.1) MUST NOT be + included in Capability messages. An LDP speaker that receives a + Capability message from a peer that includes Backward Compatibility + TLVs SHOULD silently ignore these Backward Compatibility TLVs and + continue processing the rest of the message. + +5. Note on Terminology + + The following sections in this document talk about enabling and + disabling capabilities. The terminology "enabling (or disabling) a + capability" is short hand for "advertising (or withdrawing) a + capability associated with an enhancement". Bear in mind that it is + an LDP enhancement that is being enabled or disabled, and that it is + the corresponding capability that is being advertised or withdrawn. + +6. Procedures for Capability Parameters in Initialization Messages + + The S-bit of a Capability Parameter in an Initialization message MUST + be 1 and SHOULD be ignored on receipt. This ensures that any + Capability Parameter in an Initialization message enables the + corresponding capability. + + An LDP speaker determines the capabilities of a peer by examining the + set of Capability Parameters present in the Initialization message + received from the peer. + + An LDP speaker MAY use a particular capability with its peer after + the speaker determines that the peer has enabled that capability. + + + +Thomas, et al. Standards Track [Page 7] + +RFC 5561 LDP Capabilities July 2009 + + + These procedures enable an LDP speaker S1, that advertises a specific + LDP capability C, to establish an LDP session with speaker S2 that + does not advertise C. In this situation, whether or not capability C + may be used for the session depends on the semantics of the + enhancement associated with C. If the semantics do not require both + S1 and S2, advertise C to one another, then S2 could use it; i.e., + S1's advertisement of C permits S2 to send messages to S1 used by the + enhancement. + + It is the responsibility of the capability designer to specify the + behavior of an LDP speaker that has enabled a certain enhancement, + advertised its capability and determines that its peer has not + advertised the corresponding capability. The document specifying + procedures for the capability MUST describe the behavior in this + situation. If the specified procedure is to terminate the session, + then the LDP speaker SHOULD send a Notification message to the peer + before terminating the session. The Status Code in the Status TLV of + the Notification message MUST be Unsupported Capability, and the + message SHOULD contain the unsupported capability (see Section 8 for + more details). + + An LDP speaker that supports capability advertisement and includes a + Capability Parameter in its Initialization message MUST set the TLV + U-bit to 0 or 1, as specified by Capability document. The LDP + speaker should set the U-bit to 1 if the capability document allows + it to continue with a peer that does not understand the enhancement, + and set the U-bit to 0 otherwise. If a speaker receives a message + containing unsupported capability, it responds according to the U-bit + setting in the TLV. If the U-bit is 1, then the speaker MUST + silently ignore the Capability Parameter and allow the session to be + established. However, if the U-bit is 0, then speaker SHOULD send a + Notification message to the peer before terminating the session. The + Status Code in the Status TLV of the Notification message MUST be + Unsupported Capability, and the message SHOULD contain the + unsupported capability (see Section 8 for more details). + +7. Procedures for Capability Parameters in Capability Messages + + An LDP speaker MUST NOT send a Capability message to a peer unless + its peer advertised the Dynamic Capability Announcement capability in + its session Initialization message. An LDP speaker MAY send a + Capability message to a peer if its peer advertised the Dynamic + Capability Announcement capability in its session Initialization + message (see Section 9). + + + + + + + +Thomas, et al. Standards Track [Page 8] + +RFC 5561 LDP Capabilities July 2009 + + + An LDP speaker determines the capabilities enabled by a peer by + determining the set of capabilities enabled at session initialization + (as specified in Section 6) and tracking changes to that set made by + Capability messages from the peer. + + An LDP speaker that has enabled a particular capability MAY use the + enhancement corresponding to the capability with a peer after the + speaker determines that the peer has enabled the capability. + +8. Extensions to Error Handling + + This document defines a new LDP status code named Unsupported + Capability. The E-bit of the Status TLV carried in a Notification + message that includes this status code MUST be set to 0. + + In addition, this document defines a new LDP TLV, named Returned + TLVs, that MAY be carried in a Notification message as an Optional + Parameter. The U-bit setting for a Returned TLVs TLV in a + Notification message SHOULD be 1, and the F-bit setting SHOULD be 0. + + When the Status Code in a Notification message is Unsupported + Capability, the message SHOULD specify the capabilities that are + unsupported. When the Notification message specifies the unsupported + capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs + TLV MUST include only the Capability Parameters for unsupported + capabilities, and the Capability Parameter for each such capability + SHOULD be encoded as received from the peer. + + When the Status Code in a Notification Message is Unknown TLV, the + message SHOULD specify the TLV that was unknown. When the + Notification message specifies the TLV that was unknown, it MUST + include the unknown TLV in a Returned TLVs TLV. + +9. Dynamic Capability Announcement TLV + + The Dynamic Capability Announcement TLV is a Capability Parameter + defined by this document with following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|0| DynCap Ann. (0x0506) | Length (1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1| Reserved | + +-+-+-+-+-+-+-+-+ + + + + + + +Thomas, et al. Standards Track [Page 9] + +RFC 5561 LDP Capabilities July 2009 + + + The value of the U-bit for the Dynamic Capability Announcement + Parameter TLV MUST be set to 1 so that a receiver MUST silently + ignore this TLV if unknown to it, and continue processing the rest of + the message. There is no "Capability Data" associated with this TLV + and hence the TLV length MUST be set to 1. + + The Dynamic Capability Announcement Parameter MAY be included by an + LDP speaker in an Initialization message to signal its peer that the + speaker is capable of processing Capability messages. + + An LDP speaker MUST NOT include the Dynamic Capability Announcement + Parameter in Capability messages sent to its peers. Once enabled + during session initialization, the Dynamic Capability Announcement + capability cannot be disabled. This implies that the S-bit is always + 1 for the Dynamic Capability Announcement. + + An LDP speaker that receives a Capability message from a peer that + includes the Dynamic Capability Announcement Parameter SHOULD + silently ignore the parameter and process any other Capability + Parameters in the message. + +10. Backward Compatibility + + From the point of view of the LDP capability advertisement mechanism, + an [RFC5036]-compliant peer has label distribution for IPv4 enabled + by default. To ensure compatibility with an [RFC5036]-compliant + peer, LDP implementations that support capability advertisement have + label distribution for IPv4 enabled until it is explicitly disabled + and MUST assume that their peers do as well. + + Section 3.1 introduces the concept of Backward Compatibility TLVs + that may appear in an Initialization message in the role of a + Capability Parameter. This permits existing LDP enhancements that + use an ad hoc mechanism for enabling capabilities at session + initialization time to continue to do so. + +11. Security Considerations + + [MPLS_SEC] describes the security framework for MPLS networks, + whereas [RFC5036] describes the security considerations that apply to + the base LDP specification. The same security framework and + considerations apply to the capability mechanism described in this + document. + + + + + + + + +Thomas, et al. Standards Track [Page 10] + +RFC 5561 LDP Capabilities July 2009 + + +12. IANA Considerations + + This document specifies the following code points assigned by IANA: + + - LDP message code point for the Capability message (0x0202). + + - LDP TLV code point for the Dynamic Capability Announcement TLV + (0x0506). + + - LDP TLV code point for the Returned TLVs TLV (0x0304). + + - LDP Status Code code point for the Unsupported Capability Status + Code (0x0000002E). + +13. Acknowledgments + + The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, + Yakov Rekhter, and Eric Rosen for their comments. + +14. References + +14.1. Normative References + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, + Ed., "LDP Specification", RFC 5036, October 2007. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label + Distribution Protocol (LDP)", RFC 3479, February 2003. + +14.2. Informative References + + [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP + Extension for Inter-Area Label Switched Paths (LSPs)", + RFC 5283, July 2008. + + [MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and + B. Thomas, "Label Distribution Protocol Extensions for + Point-to-Multipoint and Multipoint-to-Multipoint Label + Switched Paths", Work in Progress, April 2009. + + [NNHOP] Shen, N., Chen, E., and A. Tian, "Discovery LDP Next- + Nexthop Labels", Work in Progress, May 2005. + + + + + + +Thomas, et al. Standards Track [Page 11] + +RFC 5561 LDP Capabilities July 2009 + + + [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., + and G. Heron, "Pseudowire Setup and Maintenance Using + the Label Distribution Protocol (LDP)", RFC 4447, + April 2006. + + [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, + "Graceful Restart Mechanism for Label Distribution + Protocol", RFC 3478, February 2003. + + [UPSTREAM_LDP] Aggarwal R., and J.L. Le Roux, "MPLS Upstream Label + Assignment for LDP" Work in Progress, July 2008. + + [MPLS_SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", Work in Progress, March 2009. + +Authors' Addresses + + Bob Thomas + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + EMail: bobthomas@alum.mit.edu + + Shivani Aggarwal + Juniper Networks + 1194 North Mathilda Ave. + Sunnyvale, CA 94089 + EMail: shivani@juniper.net + + Rahul Aggarwal + Juniper Networks + 1194 North Mathilda Ave. + Sunnyvale, CA 94089 + EMail: rahul@juniper.net + + Jean-Louis Le Roux + France Telecom + 2, Avenue Pierre-Marzin + 22307 Lannion Cedex, France + EMail: jeanlouis.leroux@orange-ftgroup.com + + Kamran Raza + Cisco Systems, Inc. + 2000 Innovation Dr. + Kanata, ON K2K 3E8, Canada + EMail: skraza@cisco.com + + + + + +Thomas, et al. Standards Track [Page 12] + -- cgit v1.2.3