LDP Specification
obsoleted by
- rfc-5036 — LDP Specification
Extracted elements (28)
LDP uses TCP for session, advertisement, and notification messages to guarantee reliable, in-order delivery, while using UDP multicast for discovery Hellos so that peers can be discovered without pre-configuration. These two transports serve fundamentally different roles and cannot be unified.
Liberal label retention mode retains all received label mappings regardless of whether the peer is the current next hop, enabling fast reaction to routing changes at the cost of maintaining unneeded mappings. Conservative retention saves label space (critical for ATM switches) but requires obtaining a new label from the new next hop after a route change.
Loop detection (Path Vector and Hop Count TLVs) is a configurable option rather than mandatory because it adds per-message overhead and complexity. If configured, it must be enabled on ALL LSRs in the MPLS domain; partial deployment risks undetected or falsely detected loops.
The active/passive role in TCP session establishment is determined by comparing the two transport addresses as unsigned integers: the LSR with the numerically larger address plays the active role and initiates the TCP connection. This deterministic tie-breaking prevents both LSRs from simultaneously attempting to connect or both waiting.
ATM and Frame Relay interfaces use per-interface label spaces (VCI/VPI and DLCI respectively), while interfaces that can share labels use a platform-wide label space. Per-interface label spaces are only meaningful when LDP peers are directly connected over that interface.
An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency.
The TCP MD5 Signature Option mechanism for authenticating LDP TCP sessions MUST be supported as a configurable option. An LSR configured for MD5 is given a shared-secret password per peer; segments failing MD5 validation are silently dropped.
Upon receipt of an error Notification message, an LSR MUST terminate the LDP session by closing the TCP transport connection and discarding all label mappings learned via that session.
When an LSR detects a loop via Path Vector or Hop Count TLV in a Label Mapping message, it MUST stop using the label for forwarding, drop the Label Mapping message, and signal Loop Detected status to the source of the message.
When an LSR detects a looping Label Request (Path Vector contains its own LSR Id, or Hop Count exceeds maximum), it MUST send a Loop Detected Notification to the source and drop the Label Request message.
When Initialization messages are repeatedly NAK'd, an LSR must throttle session setup retry attempts with exponential backoff. The first retry must be delayed no less than 15 seconds, and subsequent delays must grow to a maximum of no less than 2 minutes.
When using ordered label distribution control, an LSR MUST wait until a label from a downstream LSR is received before mapping a FEC and passing corresponding labels to upstream LSRs, unless the LSR is itself the egress for the FEC.
An LDP Identifier is a 6-octet quantity identifying an LSR label space: the first 4 octets are a globally unique LSR Id (typically the 32-bit router ID), and the last 2 octets identify a specific label space within the LSR. Platform-wide label spaces always have the last two octets set to zero.
An LDP PDU consists of an LDP header followed by one or more LDP messages. The header contains a 2-octet Version field, a 2-octet PDU Length (excluding Version and PDU Length fields), and a 6-octet LDP Identifier. Maximum PDU length defaults to 4096 bytes prior to session negotiation.
Basic LDP Discovery uses periodic LDP Link Hello messages sent as UDP packets to the well-known LDP discovery port at the 'all routers on this subnet' multicast address. Receipt of a Link Hello on an interface establishes a Hello adjacency identifying a potential LDP peer and its intended label space.
LDP Extended Discovery supports sessions between non-directly connected LSRs using LDP Targeted Hellos sent as UDP unicast packets to a specific address. Extended Discovery is asymmetric: the initiating LSR sends Targeted Hellos and the targeted LSR decides whether to respond.
LDP KeepAlive session maintenance requires that an LSR ensure its peer receives at least one LDP PDU every KeepAlive period. If no other message is due, a KeepAlive message is sent. A KeepAlive timer expiry without receiving any PDU causes the LSR to terminate the session.
Loop detection uses a Path Vector TLV (containing the list of LSR Ids the message has traversed) and a Hop Count TLV (a count of LSRs traversed). An LSR detecting its own Id in the Path Vector, or a Hop Count or Path Vector length exceeding the configured maximum, treats the message as having looped.
RFC 3036 defines five IANA name spaces for LDP: Message Type Name Space (section 4.1), TLV Type Name Space (section 4.2), FEC Type Name Space (section 4.3), Status Code Name Space (section 4.4), and Experiment ID Name Space (section 4.5). Each specifies allocation policies for standard, vendor-private, and experimental ranges.
LDP is vulnerable to denial of service via spoofed UDP Hello messages that cause LSRs to attempt TCP session establishment with non-existent peers, or via excessive session connection requests exhausting resources. The TCP MD5 option and Hello filtering (ignoring Hellos from peers with no configured password) partially mitigate these attacks.
LDP messages carry routing topology information (address prefixes and label bindings). An eavesdropper on an LDP session can learn the network topology. LDP provides no confidentiality mechanism; operators requiring privacy must use external means such as link-layer encryption.
LDP sessions are vulnerable to spoofed TCP segments (including resets) that could disrupt label switching. The TCP MD5 Signature Option (RFC 2385) is specified as a configurable protection mechanism; an attacker would need both correct TCP sequence numbers and the shared password to inject valid segments.
LDP session initialization has five states: NON EXISTENT, INITIALIZED, OPENSENT (active role sent Init), OPENREC (passive role received acceptable Init and sent Init+KeepAlive), and OPERATIONAL. A TCP connection established event triggers NON EXISTENT→INITIALIZED; receiving a KeepAlive in OPENREC triggers OPENREC→OPERATIONAL; receiving a Shutdown or timeout in OPERATIONAL triggers OPERATIONAL→NON EXISTENT.
LDP uses a Type-Length-Value (TLV) encoding: a 2-octet field containing a 1-bit U (unknown) flag, 1-bit F (forward) flag, and 14-bit Type, followed by a 2-octet Length field, followed by a variable-length Value field. TLVs may be nested.
The ATM Label TLV (type 0x0201) encodes an ATM label in 4 octets: 2 reserved bits, 2-bit V-bits switching indicator (00=VPI+VCI significant, 01=VPI only, 10=VCI only), 12-bit VPI, and 16-bit VCI.
The FEC TLV (type 0x0100) encodes one or more FEC elements. Each FEC element has a 1-octet type: Wildcard (0x01, no value), Prefix (0x02, with 2-octet Address Family, 1-octet prefix length, and variable prefix field), or Host Address (0x03, with Address Family, 1-octet length, and full host address).
The Frame Relay Label TLV (type 0x0202) encodes a Frame Relay label in 4 octets: reserved bits, a 2-bit Len field specifying DLCI width (0=10 bits, 2=23 bits), and the DLCI value.
The Generic Label TLV (type 0x0200) encodes a 20-bit MPLS label value as a 20-bit number in a 4-octet field, used for links where label values are independent of link technology (e.g., PPP, Ethernet).