Multiprotocol Label Switching Architecture
updated by
Extracted elements (30)
Aggregation (binding one label to a union of FECs that is itself a FEC within a domain) is supported to reduce label table size and label distribution control traffic. When ordered control is used, each LSR should adopt the granularity of its next hop; for independent control, consistent configuration of all LSRs is recommended for best results.
Explicit routing via MPLS labels is far more efficient than IP source routing because the explicit route need only be specified once at label assignment time rather than carried in every packet header. This makes traffic engineering and policy routing practical at scale.
Implicit peering avoids an O(n²) peering mesh for distributing higher-level labels to many remote peers by piggybacking the information through the local label distribution adjacency. However, it requires intermediate nodes to store information they do not directly use, whereas explicit peering is preferred when the number of remote peers is small or the number of higher-level bindings is large.
MPLS assigns a packet to a Forwarding Equivalence Class (FEC) exactly once at network ingress and encodes the FEC as a short fixed-length label. Subsequent routers forward based solely on the label without re-analyzing the network layer header, enabling hardware-based switching, ingress-policy-driven routing, and explicit path control without per-packet route encoding.
Penultimate Hop Popping was adopted to reduce the egress LSR's lookup burden from two lookups (top label then inner label or IP header) to one. This simplifies fastpath implementation by allowing the forwarding engine to assume a single lookup per packet and size its time budget accordingly.
The MPLS architecture explicitly does not assume a single label distribution protocol. Both extensions to existing protocols (BGP, RSVP) and new dedicated protocols (LDP, CR-LDP) are accommodated, because different traffic engineering, topology, and signaling requirements call for different distribution mechanisms.
ATM switches participating in MPLS may perform VC merge (buffer cells until AAL5 EOF), VP merge (using SVP Multipoint Encoding to distinguish cell sources by VCI within a VP), or no merge. Adjacent ATM-LSRs on the same level-m LSP segment MUST use the same encoding technique because ATM switches cannot translate between encoding schemes.
Non-merging LSRs (e.g., ATM switches with SVC/SVP encoding) require multiple downstream labels per FEC — one per upstream source — and must explicitly request additional labels from downstream peers. Without label merging, the number of labels per FEC can grow as large as the total number of upstream nodes forwarding that FEC to a given LSR.
A packet traversing an LSP SHOULD emerge with the same TTL value it would have had if routed conventionally hop-by-hop. An MPLS shim header MUST include a TTL field that SHOULD be loaded from the network layer TTL at ingress, decremented at each LSR hop, and copied back into the network layer TTL field on egress.
An LSR Rd MUST NOT distribute the same label value L to two different upstream peers for two different FECs (F1 ≠ F2) unless Rd can always determine which upstream peer placed that label on a received packet. This uniqueness constraint ensures unambiguous label interpretation at each hop.
An LSR that is capable of popping the label stack MUST perform penultimate hop popping when explicitly requested by its downstream label distribution peer. Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighbors are capable of popping the label stack, and an LSR MUST NOT request PHP from a peer that cannot do it.
Label distribution information MUST be transmitted reliably. The label distribution protocol transport must ensure correct ordering and delivery of label binding messages between peers.
Labels are downstream-assigned: the decision to bind a label L to FEC F is made by the downstream LSR (Rd), which then informs the upstream LSR (Ru). Label bindings are therefore distributed in the downstream-to-upstream direction.
When a labeled packet is received with an invalid (unbound) incoming label, it MUST be discarded unless it can be determined by some external means that forwarding it unlabeled cannot cause harm (e.g., a loop or incorrect routing due to insufficient network layer header information).
When a labeled packet traveling along an LSP reaches an LSR whose ILM does not map the incoming label to an NHLFE (even though the label is valid), the only safe default action is to discard the packet rather than stripping the label stack and forwarding as an unlabeled IP packet, because doing so could create a forwarding loop or fail for explicitly routed LSPs.
A label is a short, fixed-length, locally significant identifier used to identify a FEC. A label binding between label L and FEC F is local to the upstream/downstream LSR pair (Ru, Rd) and has no significance beyond that hop; the label is never an encoding of the network layer destination address.
A non-TTL LSP segment is a sequence of LSRs (typically ATM switches) that cannot decrement a packet's TTL at each hop because the data link layer encoding (e.g., VPI/VCI) has no TTL field. Ingress to a non-TTL segment must propagate LSP length to allow pre-decrementation, and packets whose TTL would expire within the segment must not be label-switched.
Label distribution peers may be local (IGP neighbors, communicate via direct label distribution protocol messages) or remote (non-IGP-neighbors). Remote peers are reached via Explicit Peering (direct labeled protocol messages) or Implicit Peering (higher-level label encoded as attribute of a lower-level label binding and propagated hop-by-hop through local peers).
Label merging allows an LSR to receive packets from multiple incoming interfaces or with different incoming labels for the same FEC and forward all of them with a single outgoing label. ATM-LSRs using SVC or SVP encoding cannot perform label merging due to cell-interleaving at the AAL5 reassembly layer.
Label Retention Mode is either Liberal (bindings from non-next-hop LSRs are retained for faster rerouting on topology change) or Conservative (such bindings are discarded, requiring fewer labels). Liberal mode adapts faster to routing changes; conservative mode minimizes label table size.
Label scope may be per-platform (globally unique within an LSR) or per-interface (unique only on a given point-to-point interface). Per-interface label spaces are valid only when an LSR can reliably determine from the incoming interface which upstream peer placed a given label on a packet.
Loop control for non-TTL LSP segments (where TTL cannot protect against forwarding loops) requires all LSRs that may attach to such segments to support a common loop detection technique, though use is optional. The loop detection technique is specified in [MPLS-ATM] and [MPLS-LDP], not in this architecture document.
LSP Control may be Independent (each LSR independently binds a label to a FEC as soon as it recognizes it) or Ordered (an LSR binds a label only if it is the LSP egress or has already received a label binding from its next hop). Ordered control is required when traffic must follow a path with guaranteed properties; both modes are interoperable but a network with mixed modes behaves largely as independent control.
LSP Tunnels implement tunneling via MPLS label stacking rather than network layer encapsulation. The label stack supports arbitrary nesting depth, allowing Level 2 LSPs to carry Level 1 LSPs transparently. At each hierarchy boundary the outer label is pushed at the tunnel ingress and popped (via PHP) at the penultimate hop of the inner tunnel.
Penultimate Hop Popping (PHP) allows the penultimate LSR in an LSP to pop the top label before forwarding, so the LSP egress receives the packet with the label it actually needs for its own forwarding decision (or as a plain network layer packet), requiring only one lookup instead of two.
The Incoming Label Map (ILM) maps each incoming label to a set of NHLFEs used when forwarding labeled packets. The FEC-to-NHLFE map (FTN) maps each FEC to a set of NHLFEs used when forwarding unlabeled packets that are to be labeled before forwarding. Either map may return multiple NHLFEs to support load balancing.
The label stack is an ordered, last-in-first-out set of labels carried by a labeled packet. Processing is always based on the top label regardless of stack depth, and an unlabeled packet is treated as having a label stack of depth 0. The stack supports MPLS hierarchy via LSP tunneling.
The Next Hop Label Forwarding Entry (NHLFE) contains: (1) the packet's next hop, (2) the label stack operation to perform (replace top label, pop stack, or replace and push one or more new labels), and optionally the data link encapsulation and label encoding method. If the next hop is the current LSR, the stack operation MUST be to pop the stack.
RFC 3031 Section 6 contains the security considerations for the MPLS architecture. The architecture document notes that MPLS forwarding based on labels rather than IP headers creates risks if label bindings are spoofed or if invalid labels are forwarded rather than discarded; the requirement to discard packets with invalid incoming labels (section 3.18) and loop-control mechanisms (section 3.24) are the primary defenses defined in the architecture.
The generic MPLS encapsulation (shim header) sits between the data link and network layer headers and encodes the label stack for MPLS-specific hardware/software forwarding. It must include a TTL field and is specified in [MPLS-SHIM]. ATM-based encodings place the top-of-stack label in the VPI/VCI field (SVC), the VPI field (SVP), or split across VPI and partial VCI (SVP Multipoint).