RFC 5561

LDP Capabilities

📅 published July 2009, from ietf

Part 1 of 3 🎀

RFC 5561: LDP Capabilities ✨

okay bestie, the title block is the tea 🫖 This is a Standards Track doc from the Network Working Group, it's RFC 5561, and it was published in July 2009. It updates [RFC5036]. The authors are B. Thomas and K. Raza (Cisco Systems, Inc.), S. Aggarwal and R. Aggarwal (Juniper Networks), and JL. Le Roux (France Telecom). Iconic team 👑

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

Abstract 📖

so LDP (the Label Distribution Protocol) has a bunch of upgrades floating around 🦋 Some are already built, some are on the road to becoming official standards, and honestly more are probably coming later too. This doc defines a way to advertise these enhancements when a session first starts up, plus a way to turn them on and off after the session is already established. Main character energy 💅

Status of This Memo 📝

this doc specifies an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🌸 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖

okay the legal stuff, but make it cute 🎀 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, as they stand on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this doc 🙈

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without getting an adequate license from those copyright holders, 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. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

1. Introduction ✨

so LDP as specified in [RFC5036] has a whole bunch of enhancements people have proposed 🧚 Some of the big ones: 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 to support fast reroute node protection [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for signaling inter-area Label Switched Paths (LSPs) [RFC5283]. Some are implemented, some are heading toward standardization, and it's very likely more enhancements will get implemented and deployed later 🔥

this doc proposes and defines a way to advertise LDP enhancements when a session initializes 💜 It also defines a way to enable and disable those enhancements after the LDP session is up.

LDP capability advertisement is how an LDP speaker says what it can receive and process 🫶 It also lets a speaker tell its peers about any ways it deviates from the behavior [RFC5036] describes. Graceful Restart is a perfect example of a deviation: a speaker keeps its MPLS forwarding state for LDP-signaled LSPs even when its LDP control plane goes down 💀 Not every enhancement needs capability advertisement though. Upstream label allocation does need it, but inbound label filtering, where a speaker only installs forwarding state for 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 most likely to get announced during LDP session establishment, since each LDP speaker advertises the capabilities for the enhancements it wants 🦋

but wait, it gets better ✨ capability advertisements can also change the session on the fly to match changing conditions. Like, an LSR might be fully capable of some enhancement for a "feature," but if that feature was disabled at session setup time, it wouldn't have advertised the matching capability to peers. Later, an operator flips the feature on, and the LSR reacts by advertising that capability to its peers. Same deal in reverse: when an operator disables a feature tied to a capability, the LSR withdraws that capability advertisement from its peers 🙈

the LDP capability advertisement mechanism works like this:

  • Each LDP speaker is assumed to implement a set of enhancements, and each one 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, those actions 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 that needs LDP capability advertisement gets 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 ✨

okay so this doc uses the term "Capability Parameter" 🎀 for an optional parameter that can be tucked into Initialization and Capability messages to advertise a capability. that's the whole vibe.

the format of a "Capability Parameter" TLV looks like this 💅

    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                         |
   |                                               +-+-+-+-+-+-+-+-+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

so here's the breakdown, bestie 🫶

  • U-bit: the Unknown TLV bit, as described in [RFC5036]. its value can be 0 or 1, depending on what the Capability document for that capability says ✨
  • F-bit: the Forward unknown TLV bit, as described in [RFC5036]. this one MUST be 0 🙅‍♀️ because a Capability Parameter TLV only gets sent in Initialization and Capability messages, and those aren't forwarded anyway 💀
  • TLV Code Point: the TLV type that identifies one specific capability. it's an IANA-assigned code point (from the TLV Type namespace) for a given capability, requested in that capability's document 🌸
  • S-bit: the State Bit 🔥. it tells you whether the sender is advertising or withdrawing the capability that matches the TLV code point. the value works like this:
    • 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: any extra info about the capability, beyond the TLV code point, that's needed to fully specify it. how you interpret and process this data is specific to the TLV code point, and the document specifying the capability MUST describe it 🧚

an LDP speaker MUST NOT include more than one instance of a Capability Parameter (identified by the same TLV code point) in an Initialization or Capability message 🙅‍♀️. and if a speaker gets more than one instance of the same Capability Parameter type in a message, it SHOULD send a Notification message to the peer before it terminates the session 💅. the Status Code in the Status TLV of that Notification message MUST be Malformed TLV value, and the message SHOULD contain the second Capability Parameter TLV of the same type (code point) that was received in the message 😭🫶

3.1. Backward Compatibility TLVs

okay so LDP extensions that need to advertise or negotiate some capability at session establishment usually use TLVs that go in an Initialization message 🌈. to keep things working with existing implementations, those TLVs still get supported in an Initialization message, and this document calls them "Backward Compatibility TLVs" 🍓. a Backward Compatibility TLV plays the role of a "Capability Parameter" TLV. so if you see one, it means the same thing as a Capability Parameter TLV with the S-bit set for the same capability 🦋

one example is the "FT Session TLV", which gets exchanged in an Initialization message between peers to announce LDP Fault Tolerance [RFC3479] capability 💜

4. Capability Message ✨

the LDP Capability message is how an LDP speaker announces changes to the state of one or more of its capabilities after the session is already set up 🎀

here's what the Capability message looks like 👑

    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 one tells you the new state for its matching capability ✨

heads up though 🙈: Backward Compatibility TLVs (see Section 3.1) MUST NOT be included in Capability messages 🛑. if an LDP speaker gets a Capability message from a peer that has Backward Compatibility TLVs in it, it SHOULD silently ignore those and keep on processing the rest of the message 💅

5. Note on Terminology 💖

the next sections talk about enabling and disabling capabilities 🦋. "enabling (or disabling) a capability" is just shorthand for "advertising (or withdrawing) a capability associated with an enhancement" 🌸. so keep in mind that it's the LDP enhancement that's actually being enabled or disabled, and it's the matching capability that's 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 it SHOULD be ignored on receipt 🙈. that way, any Capability Parameter in an Initialization message enables the matching capability, no confusion 💅

an LDP speaker figures out what capabilities its peer has by looking at the set of Capability Parameters in the Initialization message it got from that peer 🧚

an LDP speaker MAY use a particular capability with its peer once it's figured out that the peer has enabled that capability ✨

these procedures let an LDP speaker S1, which advertises a specific LDP capability C, set up an LDP session with a speaker S2 that does NOT advertise C 😭. (quick correction, that should be read as: S2 does not advertise C.) in this case, whether capability C can be used on the session depends on what the enhancement tied to C actually means. if the semantics don't require both S1 and S2 to advertise C to each other, then S2 could still use it. basically, S1's advertisement of C lets S2 send messages to S1 that the enhancement uses 🫶

it's the capability designer's job to spell out what an LDP speaker should do when it has enabled an enhancement, advertised its capability, and found out that its peer hasn't advertised the matching capability 🎀. the document that specifies the procedures for the capability MUST describe the behavior in this situation 📜. if the specified procedure is to terminate the session, the LDP speaker SHOULD send a Notification message to the peer before it terminates the session 💀. the Status Code in the Status TLV of that 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 puts a Capability Parameter in its Initialization message MUST set the TLV U-bit to 0 or 1, as the Capability document specifies 🍓. the speaker SHOULD set the U-bit to 1 if the capability document lets it carry on with a peer that doesn't understand the enhancement, and set it to 0 otherwise 🧚. if a speaker gets a message with an unsupported capability, it responds based on the U-bit setting in the TLV 🔥. if the U-bit is 1, the speaker MUST silently ignore the Capability Parameter and allow the session to be established ✨. but if the U-bit is 0, the speaker SHOULD send a Notification message to the peer before terminating the session 😭. the Status Code in the Status TLV of that 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 that peer advertised the Dynamic Capability Announcement capability in its session Initialization message 🛑. an LDP speaker MAY send a Capability message to a peer if that peer advertised the Dynamic Capability Announcement capability in its session Initialization message (see Section 9) 🌸

an LDP speaker figures out which capabilities are enabled by a peer by working out the set of capabilities enabled at session initialization (as specified in Section 6) and then tracking the changes to that set made by Capability messages from the peer 👑

an LDP speaker that has enabled a particular capability MAY use the enhancement that goes with the capability with a peer, once it's figured out that the peer has enabled the capability 💖

8. Extensions to Error Handling 💅

this document defines a new LDP status code called Unsupported Capability 🎀. the E-bit of the Status TLV in a Notification message carrying this status code MUST be set to 0 🙅‍♀️

also, this document defines a new LDP TLV called Returned TLVs 🧚. it 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 ✨. that Returned TLVs TLV MUST include only the Capability Parameters for the unsupported capabilities, and the Capability Parameter for each of those capabilities SHOULD be encoded as it was 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 that unknown TLV, it MUST include the unknown TLV in a Returned TLVs TLV 🍓

9. Dynamic Capability Announcement TLV ✨

okay bestie, the Dynamic Capability Announcement TLV is a Capability Parameter that this document defines 💅 here's its exact shape:

       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    |
      +-+-+-+-+-+-+-+-+

the U-bit for this TLV MUST be set to 1 🔥 so that a receiver MUST silently ignore it if it doesn't recognise it, and then just keeps processing the rest of the message 🫶. there's no "Capability Data" attached to this TLV, so the TLV length MUST be set to 1. 🎀

the Dynamic Capability Announcement Parameter MAY be included by an LDP speaker in an Initialization message 🌸 that's how the speaker tells its peer "hey, I can handle Capability messages" 💜

an LDP speaker MUST NOT include the Dynamic Capability Announcement Parameter in Capability messages sent to its peers. no sneaking it in there, bestie 🙅‍♀️ and once it's switched on during session initialization, it cannot be switched off. the S-bit is therefore always 1 for this capability 💀

when an LDP speaker gets a Capability message from a peer that includes the Dynamic Capability Announcement Parameter, it SHOULD silently ignore that parameter and process any other Capability Parameters in the message. ✨ it's giving "not my problem, I'll handle the rest" energy 💅

10. Backward Compatibility 🦋

okay so from the point of view of the LDP capability advertisement mechanism, an [RFC5036]-compliant peer has label distribution for IPv4 enabled by default 🌈 to keep things compatible with that kind of peer, LDP implementations that support capability advertisement keep label distribution for IPv4 enabled until it's explicitly disabled, and they MUST assume their peers do the same. main character compatibility energy 👑

Section 3.1 introduces the idea of Backward Compatibility TLVs, which can show up in an Initialization message in the role of a Capability Parameter. this lets existing LDP enhancements that use an ad hoc mechanism for turning on capabilities at session initialization keep doing exactly that 🧚 no rewrites needed, periodt 💖

11. Security Considerations 🚨

bestie, this section is SERIOUS 😭 [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. read those references, fr fr 🔐

12. IANA Considerations 📋

this document asks IANA to take note of the following code points 🍓

  • 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 want to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, Yakov Rekhter, and Eric Rosen for their comments 💜 literally the best squad 👑

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.
  • [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
📦 where this page comes from