Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
updated by
- rfc-7358 — Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)
Extracted elements (30)
mLDP builds P2MP and MP2MP LSPs in a receiver-initiated manner without interacting with any multicast tree construction protocol. The leaf nodes initiate setup toward the root by sending Label Mapping messages upstream hop-by-hop following unicast routing, making the solution self-contained within LDP.
Ordered mode for MP2MP upstream path installation is preferred over hop-by-hop method because it guarantees the upstream path to the root is complete before a leaf starts sending, preventing packet drops due to an incomplete LSP. Hop-by-hop method (Method 1) cannot provide this guarantee.
Root node redundancy for MP2MP LSPs is achieved by building separate MP2MP LSPs (same opaque value, different root addresses) to each candidate root. Sending leaves select a single active root based on unicast routing metric; all leaves MUST join all available roots. This provides fast failover without additional signaling because root selection is a local leaf policy.
When changing upstream LSR from L to L', if L' is added before L is removed there is risk of packet duplication and/or transient forwarding loops; if L is removed before L' is added, packet loss may result. The RECOMMENDED default is to remove L before adding L' to avoid duplication, accepting the risk of brief packet loss.
Micro-loops involving exactly 2 directly connected routers are prevented by mLDP's rule that an upstream LDP neighbor cannot be added as a downstream neighbor in the LFT for the same FEC. Micro-loops involving more than 2 LSRs are not prevented and are transient, resolving when unicast routing converges.
On a LAN with multiple receivers, upstream label allocation (RFC 5331/6389) SHOULD be used to optimize bandwidth and reduce replication overhead. Packets use a two-label stack: the upstream LSR's context label as the top label and the LSP label as the second label.
A packet received from a downstream node on an MP2MP LSP MUST never be forwarded back out to that same node. This is enforced in the forwarding state by omitting the swap on the interface toward the originating downstream node.
A transit node receiving a P2MP Label Mapping from LSR T MUST NOT use that mapping to update the label forwarding table as long as LSR T equals the upstream LSR U. If LSR T equals the installed upstream LSR, the Label Mapping MUST be retained but MUST NOT update the label forwarding table.
All leaf nodes participating in an MP2MP LSP MUST join all available root nodes for a given opaque value. A sending leaf MUST only forward a packet on one MP2MP LSP at a given point in time.
All new fields shown as 'reserved' MUST be set to zero on transmission and MUST be ignored on receipt.
An implementation supporting P2MP procedures MUST implement Capability Parameters in Initialization messages. The P2MP Capability TLV MUST be advertised in the LDP Initialization message.
An LSR can have two accepting elements for a specific MBB LSP, but only one MUST be active at a time. If multiple successive routing changes occur while awaiting MBB notification, older inactive accepting elements MUST be replaced with newer ones, and a Label Withdraw MUST be sent to the replaced neighbor.
For setting up the upstream path of an MP2MP LSP, ordered mode SHOULD be used. In ordered mode, the upstream path is installed at the leaf node only after the downstream path to the root has completed, ensuring upstream packets can reach the root without being dropped.
If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST be the only FEC Element in the FEC TLV. The same constraint applies to MP2MP FEC Elements.
If an LSR receives a Label Mapping with an MBB parameter from downstream LSR-D but its upstream LSR-U has not advertised MBB capability, the LSR MUST immediately send an MBB notification to LSR-D. The result is a normal MP LSP, not an MBB MP LSP.
If the Address Family is IPv4, the Address Length MUST be 4; if IPv6, the Address Length MUST be 16. If the Address Length doesn't match the defined length for the Address Family, the receiver SHOULD abort processing and send an 'Unknown FEC' Notification to its LDP peer.
Labels used in P2MP and MP2MP Label Mapping messages MUST be allocated from the per-platform label space of the LSR sending the Label Mapping message.
When selecting an upstream LSR over a LAN interface, a CRC32-based hash SHOULD be applied to ensure a single forwarder is elected: H = CRC32(Opaque Value) modulo N, where N is the number of candidate upstream LSRs sorted from lower to higher IP address; the selected upstream is LSR number H.
The LDP MP MBB Capability Parameter (type 0x050A) is advertised to indicate an LSR can handle MBB LSPs. If an LSR has not advertised MBB capability, its LDP peers MUST NOT send messages including MBB parameters.
The LDP MP Status TLV (type 0x096F) carries additional status for an MP LSP to remote peers. It may appear in a Label Mapping message or an LDP Notification message and contains one or more LDP MP Status Value Elements, each with a 1-octet type, 2-octet length, and variable value.
The MP2MP Capability Parameter TLV (type 0x0509) advertises support for MP2MP LSP setup. MP2MP uses two FEC element types: MP2MP upstream (0x07) and MP2MP downstream (0x08). Structure and error handling are identical to the P2MP FEC Element.
The P2MP Capability Parameter TLV (type 0x0508) is a new LDP Capability Parameter used to advertise support for P2MP LSP setup. It consists of a 16-bit type, 16-bit length (=1), and an 8-bit field containing the S bit as specified in RFC 5561.
IANA allocated FEC type codes: P2MP FEC type 0x06, MP2MP-up FEC type 0x07, MP2MP-down FEC type 0x08. Three new LDP TLV Capability codes were assigned: P2MP Capability 0x0508, MP2MP Capability 0x0509, MBB Capability 0x050A. LDP Status Code for MP status 0x00000040, and LDP MP Status TLV Type 0x096F.
IANA created three new registries: 'LDP MP Opaque Value Element basic type' (range 0-255; 0=Reserved, 1=Generic LSP identifier, 255=Extended Type present; Standards Action with Early Allocation), 'LDP MP Opaque Value Element extended type' (range 0-65535; 0-32767 Standards Action, 32768-65535 FCFS), and 'LDP MP Status Value Element type' (range 0-255; 0=Reserved, 1=MBB Status; Standards Action with Early Allocation).
mLDP inherits the base LDP security considerations from RFC 5036. The protocol provides no authorization mechanism for controlling which LSRs may join a given MP LSP; if such authorization is desirable, additional mechanisms outside the scope of this document are needed. Authorization policies cannot be implemented solely at the root node because the root does not learn the identities of all leaf nodes.
MBB LSP at a given upstream LSR exists in one of three states: (1) no state for the FEC, (2) state exists but waiting for MBB notification that the path from root to this LSR exists, (3) state exists and MBB notification received or node is root. An upstream LSR MUST NOT send an MBB notification to a downstream LSR until it reaches state 3.
The LDP MP Opaque Value Element has two encodings: a basic type (1-octet type < 255, 2-octet length, variable value) and an extended type (type = 255, 2-octet extended type, 2-octet length split across two fields, variable value). The Generic LSP Identifier is basic type 1, length 4, carrying a 32-bit integer unique within the root's context.
The MBB Status Value Element is encoded as: MBB Type = 1 (1 octet), Length = 1 (2 octets), Status Code (1 octet). Status Code 1 = MBB request (sent in Label Mapping); Status Code 2 = MBB ack (sent in Notification).
The mLDP Typed Wildcard FEC element consists of: 1-octet Typed Wcard, 1-octet FEC Element Type (P2MP 0x06, MP2MP-up 0x07, or MP2MP-down 0x08), 1-octet Len = 2, and 2-octet AFI from IANA Address Family Numbers registry.
The P2MP FEC Element (type 0x06) encodes: 1-octet type, 2-octet Address Family, 1-octet Address Length, variable-length Root Node Address, 2-octet Opaque Length, and variable-length Opaque Value. The combination of (Root Node Address type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP.