LDP Capabilities
Extracted elements (22)
Not all LDP enhancements require capability advertisement. For example, upstream label allocation requires it, but inbound label filtering (where a speaker installs forwarding state for only certain FECs) does not, because no behavioral deviation from RFC 5036 need be signaled.
The capability mechanism supports both static advertisement at session initialization and dynamic advertisement/withdrawal after session establishment. This allows an operator to enable or disable features at runtime without tearing down LDP sessions.
The Dynamic Capability Announcement capability is a gating mechanism: only if a peer advertises it during initialization can the local speaker send post-establishment Capability messages. This prevents speakers from receiving unexpected capability updates from peers that have not opted in to dynamic capability negotiation.
An RFC 5036-compliant peer is treated as having IPv4 label distribution enabled by default. LDP implementations supporting capability advertisement MUST assume that peers also have IPv4 label distribution enabled until explicitly disabled, ensuring compatibility with legacy RFC 5036 peers.
Backward Compatibility TLVs are existing TLVs carried in Initialization messages by prior LDP extensions (e.g., the FT Session TLV from RFC 3479). Their presence is semantically equivalent to a Capability Parameter TLV with S-bit=1, allowing existing ad hoc capability signaling to coexist with this mechanism.
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. If duplicates are received, the speaker SHOULD send a Notification with Status Code Malformed TLV value before terminating the session.
An LDP speaker MUST NOT include the Dynamic Capability Announcement Parameter in Capability messages sent to peers. Once enabled during session initialization, the Dynamic Capability Announcement capability cannot be disabled; the S-bit is always 1 for this TLV.
An LDP speaker MUST NOT send a Capability message to a peer unless that peer advertised the Dynamic Capability Announcement capability in its Initialization message.
Backward Compatibility TLVs MUST NOT be included in Capability messages. An LDP speaker that receives a Capability message containing Backward Compatibility TLVs SHOULD silently ignore those TLVs and continue processing the remainder of the message.
If a received Capability Parameter TLV has U-bit=1 and is unsupported, the receiver MUST silently ignore the TLV and allow session establishment. If U-bit=0 and the capability is unsupported, the receiver SHOULD send a Notification with Status Code Unsupported Capability before terminating the session.
The F-bit of a Capability Parameter TLV MUST be 0, because Capability Parameters are sent only in Initialization and Capability messages, which are not forwarded.
The S-bit of a Capability Parameter in an Initialization message MUST be 1 and SHOULD be ignored on receipt, ensuring that any Capability Parameter in an Initialization message enables (rather than withdraws) the corresponding capability.
The U-bit of the Dynamic Capability Announcement Parameter TLV MUST be set to 1 so that a receiver that does not recognize it MUST silently ignore it and continue processing the rest of the Initialization message.
When an LDP speaker advertises a capability but its peer has not advertised the corresponding capability, the behavior is the responsibility of the capability designer. If the specified procedure is to terminate the session, the speaker SHOULD send a Notification with Status Code Unsupported Capability before terminating.
A new LDP status code named 'Unsupported Capability' is defined (value 0x0000002E). The E-bit of the Status TLV in a Notification message carrying this code MUST be 0, meaning it is an advisory notification rather than a fatal error requiring session teardown at the LDP layer.
A new 'Returned TLVs' TLV (code point 0x0304) is defined and MAY be carried as an Optional Parameter in a Notification message. When the Status Code is Unsupported Capability, the Notification MUST include a Returned TLVs TLV containing only the Capability Parameters for unsupported capabilities.
The S-bit (State Bit) within a Capability Parameter TLV indicates whether the sender is advertising (S=1) or withdrawing (S=0) the capability corresponding to the TLV code point.
This document assigns four IANA code points: LDP message code 0x0202 (Capability message), TLV code 0x0506 (Dynamic Capability Announcement TLV), TLV code 0x0304 (Returned TLVs TLV), and LDP Status Code 0x0000002E (Unsupported Capability).
The security framework for MPLS networks (MPLS_SEC) and the security considerations of RFC 5036 apply equally to the capability mechanism defined in this document. No additional security considerations specific to capability advertisement are introduced beyond those already applicable to the base LDP specification.
A Capability Parameter TLV consists of a 2-octet header with U-bit, F-bit, and TLV Code Point, followed by a 2-octet Length field, then a 1-octet field containing the S-bit and 7 Reserved bits, followed by optional variable-length Capability Data.
The Capability message (code point 0x0202) contains a 2-octet type field with U-bit=0, a 2-octet Length, a 4-octet Message ID, followed by one or more Capability Parameter TLVs (TLV_1 through TLV_N) whose S-bits indicate the new state for each capability.
The Dynamic Capability Announcement TLV (code point 0x0506) has a fixed format: U-bit=1, F-bit=0, type=0x0506, Length=1, and a single octet with S-bit=1 and 7 reserved bits. It carries no Capability Data, hence Length MUST be 1.