MPLS Upstream Label Assignment for LDP
Extracted elements (24)
RFC 6388 uses ingress replication for P2MP LSPs on a LAN, requiring a branch LSR to send a separate copy to each downstream LSR. Upstream label assignment allows the branch LSR to send a single copy on the LAN, with all downstream LSRs using the same upstream-assigned label to identify the P2MP LSP, eliminating redundant traffic replication.
When multiple equal-cost next hops exist on a LAN, downstream LSRs MAY use a deterministic hash H = (Sum Opaque value) modulo N over numbered candidate upstream LSRs to select a single upstream LSR. This enables load balancing across LSPs while ensuring a single upstream LSR per LAN interface per LSP.
LDP P2MP on a LAN procedures can coexist with LSRs that do not support upstream label assignment. Ingress replication and downstream label assignment continue to be used for those LSRs that do not advertise the Upstream Label Assignment Capability.
An LDP LSR MUST NOT distribute the Upstream-Assigned Label TLV to a neighboring LSR, and MUST NOT send the Upstream-Assigned Label Request TLV to a neighboring LSR, if that neighbor has not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages.
An LSR that generates an upstream-assigned label request to a neighbor for a given FEC MUST NOT send a downstream label mapping to that neighbor for that FEC unless it first withdraws the upstream-assigned label binding, and vice versa.
For LDP P2MP on a LAN, if Ru receives a Label Request for an upstream-assigned label for the same P2MP FEC from multiple downstream LSRs <Rd1...Rdn>, it MUST send the same upstream-assigned label to each of them.
The Context Label TLV MUST NOT be used for any purpose other than LDP P2MP LSPs on a LAN as specified in Section 6.
The Upstream Label Assignment Capability Parameter MUST be carried only in LDP Initialization messages and MUST be ignored if received in LDP Capability messages.
When the label in a Label Mapping message is upstream-assigned, the Upstream-Assigned Label TLV MUST be included. If a receiver does not recognize the TLV, it MUST generate a Notification with status 'Unknown TLV'; if it recognizes but cannot process it, it MUST generate a Notification with status 'No Label Resources'.
For LDP P2MP LSPs on a LAN, the MPLS packet transmitted by Ru carries a two-label stack: the top label is the context label assigned by Ru on LAN interface Li; the bottom label is the upstream-assigned label for the LDP P2MP LSP. The top label is looked up in the context of Li to determine the context-specific label space for the inner label.
Four new Interface ID sub-TLVs are defined: RSVP-TE P2MP LSP TLV (type 28), LDP P2MP LSP TLV (type 29), IP Multicast Tunnel TLV (type 30), and MPLS Context Label TLV (type 31). Each sub-TLV value serves as a tunnel identifier to associate upstream-assigned labels with a specific tunnel.
The Interface ID TLV (RFC 3472) is used for signaling the Tunnel Identifier when LDP is used for upstream label assignment. If Ru uses an IP or MPLS tunnel to transmit MPLS packets with upstream-assigned labels to Rd, Ru MUST include the Interface ID TLV along with the Upstream-Assigned Label TLV in Label Mapping messages.
The LDP Upstream Label Assignment Capability Parameter (type 0x0507, length 1) is a new Capability Parameter that allows an LDP peer to advertise support for both distributing and receiving upstream-assigned label bindings. It follows the format and procedures of RFC 5561.
The MPLS Context Label TLV (type 31) carries a <Source Address, MPLS Context Label> tuple, where the context label is upstream-assigned by Ru. When downstream LSRs look up this label combined with the incoming interface, this MUST be sufficient to uniquely determine Ru's context-specific label space.
The Upstream-Assigned Label Request TLV (type 0x0205) is an optional LDP TLV included in a Label Request message to request an upstream-assigned label. It has a 4-octet Reserved field.
The Upstream-Assigned Label TLV (type 0x0204) signals an upstream-assigned label and is carried in Label Mapping, Label Withdraw, and Label Release messages. It contains a 4-octet Reserved field followed by a 20-bit label value in a 4-octet field.
IANA assigned four new Interface ID Types in the GMPLS 'Interface_ID Types' registry: RSVP-TE P2MP LSP TLV (28), LDP P2MP LSP TLV (29), IP Multicast Tunnel TLV (30), and MPLS Context Label TLV (31).
IANA assigned three new values in the LDP 'TLV Type Name Space' registry: Upstream Label Assignment Capability TLV (0x0507), Upstream-Assigned Label TLV (0x0204), and Upstream-Assigned Label Request TLV (0x0205).
The security considerations from RFC 5036 (LDP Specification), RFC 5331 (MPLS Upstream Label Assignment), and RFC 5332 (MPLS Multicast Encapsulations) all apply. More detailed discussion of MPLS and GMPLS security threats, defensive techniques, and detection/reporting mechanisms is provided in RFC 5920.
The IPv4 Interface ID TLV (type 0x082d) carries: 16-bit type, 16-bit Length, 4-octet IPv4 Next/Previous Hop Address (set to 0), 4-octet Logical Interface ID (set to 0), followed by Sub-TLVs. Value fields not a multiple of four MUST be zero-padded for 4-octet alignment.
The IPv6 Interface ID TLV (type 0x082e) has the same structure as the IPv4 version but with a 16-octet IPv6 Next/Previous Hop Address field set to 0, followed by Logical Interface ID and Sub-TLVs.
The LDP Upstream Label Assignment Capability Parameter is a 5-octet structure: 16-bit type (0x0507) with U=1 F=0, 16-bit Length=1, and 1 octet containing the S bit and 7 reserved bits. Reserved bits MUST be zero on transmission and ignored on receipt.
The RSVP-TE P2MP LSP TLV (type 28) carries the RSVP-TE P2MP LSP SESSION Object. In IPv4, the value is 16 octets: P2MP ID (4 octets), 2 reserved octets, Tunnel ID (2 octets), Extended Tunnel ID (4 octets). In IPv6, the value is 28 octets with a 16-octet Extended Tunnel ID.
The Upstream-Assigned Label TLV Label field is a 20-bit label value encoded as a 20-bit number in a 4-octet field as specified in Section 3.4.2.1 of RFC 5036.