MPLS Label Stack Encoding
updated by
- rfc-3270 — Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
- rfc-3443 — Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
- rfc-4182 — Removing a Restriction on the use of MPLS Explicit NULL
- rfc-5129 — Explicit Congestion Marking in MPLS
- rfc-5332 — MPLS Multicast Encapsulations
- rfc-5462 — Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field
- rfc-5586 — MPLS Generic Associated Channel
- rfc-7274 — Allocating and Retiring Special-Purpose MPLS Labels
- rfc-9017 — Special-Purpose Label Terminology
Extracted elements (27)
The Implicit NULL Label (value 3) never appears in the encapsulation but is signaled via the Label Distribution Protocol to implement penultimate-hop popping: instead of replacing the top label with a new label, the LSR pops the stack. This eliminates a label lookup at the egress LSR.
The label stack contains no explicit field identifying the network layer protocol. Instead, the identity must be inferable from the value of the label popped from the bottom of the stack, possibly combined with inspection of the network layer header. This places a constraint: a label used at the bottom of the stack must be specific to a particular network layer protocol or a distinguishable set of them.
The 'Maximum Initially Labeled IP Datagram Size' configuration parameter allows operators to fragment unlabeled IP datagrams before labeling them. Setting this to a non-zero value eliminates all fragmentation of Previously Labeled IP Datagrams, at the cost of possibly fragmenting Initially Labeled ones. Hosts using Path MTU Discovery are unaffected since this parameter does not apply to DF-set datagrams.
The Router Alert Label (value 1) is designed to be analogous to the IP Router Alert Option: it causes a packet to be examined by the local LSR rather than being forwarded purely based on the label. It cannot appear at the bottom of the stack because the bottom label must be associated with a specific network layer protocol.
LSRs implemented on ATM switches or other switching devices may use different encoding for the top one or two label stack entries (e.g., using ATM VPI/VCI as a label). The encoding specified in this document MUST be used for any further entries below those top entries.
When copying a label stack onto an ICMP error message (to route the ICMP through an MPLS tunnel back toward the source), label values must be copied exactly, but TTL values in the copied label stack should be set to the TTL placed in the ICMP IP header, not the original TTL values.
A labeled IP datagram whose size exceeds the True Maximum Frame Payload Size of the output data link MUST be considered 'too big'. A labeled IP datagram that is not too big MUST be transmitted without fragmentation.
If a packet cannot be forwarded and either its network layer protocol cannot be identified or there are no protocol-dependent rules for handling the error, the packet MUST be silently discarded.
If ICMP messages cannot be forwarded from within an MPLS tunnel to a packet's source, the LSR at the transmitting end of the tunnel MUST be able to determine the tunnel MTU. When it needs to send a DF-set packet exceeding the tunnel MTU, it MUST send the appropriate ICMP Destination Unreachable message to the source.
If the outgoing TTL of a labeled packet is 0, the packet MUST NOT be further forwarded, and the label stack MUST NOT be stripped to forward it as an unlabeled packet; the packet's lifetime is considered expired.
LSRs implemented on ATM switches or other devices that use different encoding for the top one or two label stack entries MUST use the encoding specified in this document for any additional (non-top) label stack entries.
MPLSCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase; packets received before this phase SHOULD be silently discarded. An implementation should be prepared to wait for Authentication and Link Quality Determination to complete before timing out.
To process a labeled IPv6 datagram that is too big, an LSR MUST strip the label stack, compute N, and if the datagram exceeds 1280 bytes or lacks a fragment header, send an ICMPv6 Packet Too Big with Next-Hop MTU set to Effective Maximum Frame Payload Size minus N, then discard the datagram.
When a labeled IPv4 datagram is too big and has the DF bit set, the LSR MUST strip the label stack, compute N (bytes in the label stack), and send an ICMP Destination Unreachable with code 'Fragmentation Required and DF Set' with the Next-Hop MTU field set to the Effective Maximum Frame Payload Size minus N. The datagram MUST NOT be forwarded.
When a labeled packet is forwarded, the TTL field of the top label stack entry MUST be set to the outgoing TTL value (max(incoming_TTL - 1, 0)). The TTL value in any non-top label stack entry has no significance.
When an IP packet is first labeled, the TTL field of the label stack entry MUST BE set to the value of the IP TTL field (IPv4 TTL or IPv6 Hop Limit). When the last label is popped, the IP TTL field SHOULD BE replaced with the outgoing TTL value.
Label value 0 is the IPv4 Explicit NULL Label, legal only at the bottom of the stack; it signals that the label stack must be popped and forwarding based on the IPv4 header.
Label value 1 is the Router Alert Label, legal anywhere in the stack except the bottom. A packet with this label at the top is delivered to local software for processing; if forwarded, the Router Alert Label must be pushed back before forwarding. It is analogous to the IP Router Alert Option.
Label value 2 is the IPv6 Explicit NULL Label, legal only at the bottom of the stack; it signals that the label stack must be popped and forwarding based on the IPv6 header. Label value 3 is the Implicit NULL Label, which never appears in the encapsulation but is used in the Label Distribution Protocol to signal a pop operation instead of a label replacement.
The label stack is a sequence of 4-octet entries. The top of the stack appears earliest in the packet; the entry with S=1 is the bottom. The network layer packet immediately follows the bottom-of-stack entry.
The MPLS Control Protocol (MPLSCP) is a PPP NCP responsible for enabling and disabling label switching on a PPP link. It uses the same packet exchange mechanism as LCP, but with PPP Protocol field value hex 8281 and supports only Codes 1-7. Labeled packets may only be sent after MPLSCP reaches the Opened state.
When sending labeled packets over PPP, the PPP Protocol field is set to hex 0281 for MPLS Unicast or hex 0283 for MPLS Multicast. Exactly one labeled packet is encapsulated in the PPP Information field.
When transporting labeled packets over LAN media, ethertype 0x8847 indicates an MPLS unicast packet and ethertype 0x8848 indicates an MPLS multicast packet. These ethertypes work with both the ethernet encapsulation and 802.3 LLC/SNAP encapsulation.
Label values 0-15 inclusive have special meaning. Values 0-3 are defined in this document (IPv4 Explicit NULL, Router Alert, IPv6 Explicit NULL, Implicit NULL). Values 4-15 are reserved and may be assigned by IANA based on IETF Consensus.
An MPLS label has meaning only by agreement between the label writer (the LSR that pushes the label) and the label reader (the LSR that interprets it). The label stack provides no means to authenticate the identity of the label writer. If labeled packets are accepted from untrusted sources, packets may be routed in an illegitimate manner.
Some routers implement security procedures that depend on the network layer header being at a fixed offset from the data link layer header. These procedures will not work with MPLS encapsulation because the label stack is variable in size.
Each label stack entry is 4 octets containing: Label Value (20 bits), Experimental Use (3 bits), Bottom of Stack S bit (1 bit), and TTL (8 bits). The label stack entries appear after data link layer headers but before any network layer headers.