MPLS Upstream Label Assignment and Context-Specific Label Space
updated by
- rfc-7274 — Allocating and Retiring Special-Purpose MPLS Labels
Extracted elements (25)
RFC 3031 restricts MPLS to downstream-assigned labels, where the downstream LSR decides the label binding and informs the upstream LSR. This document extends the architecture to allow upstream-assigned labels, where the upstream LSR makes the binding decision and advertises it downstream.
Two methods are provided for choosing a context label on a LAN: manual provisioning of a 20-bit value (universally applicable), or auto-generation from the low-order bits of the interface's primary IPv4 address (only when all LSRs on the LAN have IPv4 addresses). The auto-generation method derives uniqueness from IP address uniqueness on the LAN.
Upstream-assigned labels are motivated primarily by MPLS multicast, where an upstream LSR adjacent to multiple downstream LSRs via a multi-access medium or tunnel can distribute a single upstream-assigned label to all downstream LSRs and transmit one copy of an MPLS packet, rather than requiring per-receiver label stacks.
Whether a given tunnel type can carry MPLS packets with downstream-assigned labels, upstream-assigned labels, or both is determined by the tunnel type and described in RFC 5332. On multi-access data links, RFC 5332 uses a different ether type to distinguish upstream-assigned from downstream-assigned labels.
An upstream-assigned label MUST always be looked up in a context-specific label space, because when it is at the top of the label stack it must be looked up by an LSR that is not the one that assigned it.
An upstream LSR that is the headend of multiple tunnels SHOULD, by default, assign upstream-assigned labels for all LSPs carried over those tunnels from a single label space common to all tunnels, and SHOULD use the same IP address as the head identifier of those tunnels.
If Ru is the root of two tunnels A and B, both identified by the same IP address X, and both carry upstream-assigned labels, then Ru MUST use the same label space when upstream-assigning labels for packets on both tunnels.
If the tunnel carrying upstream-assigned labels is an MPLS tunnel, penultimate-hop-popping (PHP) MUST be disabled for the tunnel, so that the downstream LSR can determine the tunnel on which the packet was received.
In the MPLS multicast use case, all downstream LSRs <Rd1..Rdn> MUST be able to support an Upstream Neighbor Label Space for Ru, and Ru MUST be able to determine this before distributing upstream-assigned labels to them.
Labels MUST be looked up in the per-platform label space unless something about the context determines that a label be looked up in a particular context-specific label space.
The ability to use upstream-assigned labels is an OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless it is known that the downstream LSR supports them.
The context label assigned by an LSR for use on a particular LAN interface MUST be unique across all context labels assigned by other LSRs for use on the same LAN. When a labeled packet is received from the LAN, the context label MUST be looked up in the context of the LAN interface on which the packet is received.
The protocol used for distributing upstream-assigned labels over a particular tunnel MUST identify the assigner using the same IP address used by the tunnel setup protocol to identify the root node of the tunnel.
Upstream-assigned label bindings MUST NOT be used unless it is known that the downstream LSR supports them. How this is known is outside the scope of this document.
When Lr receives an MPLS packet on LSP1 with an upstream-assigned label L, it MUST be able to determine the context of this packet.
When Ru transmits MPLS packets with upstream-assigned top labels over IP or MPLS tunnels, Rd MUST be able to determine the root of those tunnels and MUST use a separate label space for each unique root, identified by the tunnel head-end IP address.
When two LSRs Ru and Rd are adjacent on an LSP for FEC F, either Ru distributes an upstream-assigned label binding for F to Rd, or Rd distributes a downstream-assigned label binding to Ru, but NOT both. Any application requiring upstream-assigned labels MUST specify that explicitly.
A context label is a label that identifies a label table (context-specific label space) in which the label immediately below the context label should be looked up. A context label carried as an outermost label over a particular multi-access subnet/tunnel MUST be unique within the scope of that subnet/tunnel.
A Context-Specific Label Space is a label space that an LSR maintains in addition to the per-platform label space. Labels are looked up in a context-specific label space when the context of a received packet determines this is required; upstream-assigned labels are always looked up in a context-specific label space.
An upstream-assigned label binding is one where the binding between label L and FEC F is made by the upstream LSR Ru (or a third party R3) and advertised to the downstream LSR Rd, as opposed to downstream-assigned labels where Rd makes the binding.
An upstream LSR that assigns upstream-assigned labels creates a Next Hop Label Forwarding Entry (NHLFE) for each assigned label rather than an Incoming Label Map (ILM) entry, since upstream-assigned labels are outgoing labels from the perspective of the assigning LSR.
An Upstream Neighbor Label Space is a context-specific label space that a downstream LSR Rd maintains for each upstream LSR Ru, used to look up upstream-assigned labels assigned by Ru. A separate space is maintained for each unique tunnel root IP address.
For auto-generated context labels using IPv4 addresses, if the IPv4 network mask is greater than 12 bits, the remaining 20-bit host part is mapped to a context label value. To avoid the reserved label space range, the host part is offset with 0x10 if its value is not greater than 0xFFFEF; values greater than 0xFFFEF are not allowed as context labels.
On a multi-access LAN, when a labeled packet has an ether type of 'upstream label assignment', the top label is used as a context label identifying the upstream LSR's label space. The second label in the stack is the upstream-assigned label L to be looked up in that context.
The security considerations for upstream-assigned and context labels are no different in kind from those for downstream-assigned labels. The auto-generated context label procedure (Section 8) assumes IP address uniqueness in the low-order 20 bits on a LAN; if two LSRs share those bits, other LSRs may misroute packets from either of them.