The Use of Entropy Labels in MPLS Forwarding
updated by
- rfc-7274 — Allocating and Retiring Special-Purpose MPLS Labels
- rfc-7447 — Deprecation of BGP Entropy Label Capability Attribute
- rfc-8012 — Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)
updates
Extracted elements (30)
Entropy labels are associated with MPLS tunnels rather than MPLS applications because there are few tunneling protocols but many and growing applications, reducing churn; tunnel label processing is simpler than application label processing; and per-tunnel association simplifies hierarchy handling such as LDP-over-RSVP-TE and Carrier's Carrier VPNs.
Five key reasons justify entropy labels: (1) at ingress, MPLS encapsulation hasn't occurred so deep inspection is unnecessary; (2) ingress LSRs have more context about packet contents; (3) ingress LSRs operate at lower bandwidths, allowing more per-packet work; (4) transit LSRs can load balance using only the label stack; and (5) transit LSRs are relieved of the risky choice between misinterpreting packet fields or adopting conservative (suboptimal) load balancing.
The Entropy Label Indicator (ELI) approach was chosen over (1) allocating label pairs per FEC (which doubles control and data plane state) and (2) restricting EL placement to unambiguous positions (too restrictive). The trade-off is increasing label stack depth by two entries (ELI + EL) per tunnel rather than multiplying forwarding state.
An ingress PE may selectively insert or omit entropy labels on a per-application basis over the same tunnel—for example, omitting ELs for circuit emulation (which should not use ECMP) while inserting ELs for an IP VPN. Egress ELC capability is tracked per tunnel, not per application.
MPLS-TP does not use ECMP, so entropy labels are not applicable to MPLS-TP deployments. Multicast LSPs do not use ECMP either but may traverse LAGs and bundled links where ELs provide benefit; signaling and processing details for multicast ELs are deferred to a future document.
This document updates LSP traceroute (RFC 4379) to specify that the label range value for path verification is placed in the entropy label. For BFD (RFC 5884), a value from the label range for a given path should be used as the EL value for BFD packets on that path, enabling per-path session tracking.
A BGP speaker that changes the NEXT_HOP attribute and pops the entire label stack in the data plane MUST remove the ELC attribute unless it can itself process entropy labels and sets NEXT_HOP to itself. Route Reflectors that do not change NEXT_HOP may re-advertise ELC unchanged.
An egress LSR that signals both ELC and implicit null (PHP) MUST pop the ELI and the EL when it encounters a packet with the ELI as the topmost label. Any other LSR, including PHP LSRs, MUST drop such packets per Section 3.18 of RFC 3031.
An egress LSR that signals Entropy Label Capability MUST be prepared to handle both packets with an imposed EL (identified by ELI) and those without. Upon receiving <TL, ELI, EL>, it pops TL, recognizes ELI, pops both ELI and EL, and processes the remaining header normally.
An ingress LSR MUST NOT include an entropy label for a given tunnel unless the egress LSR has explicitly indicated via signaling that it can process entropy labels for that tunnel. Signaling and EL usage are completely independent per direction.
An LSR X that understands the ELC TLV MUST NOT include it in its own Label Mapping for FEC F if any received mapping for F lacks ELC. If all received mappings include ELC, X MUST advertise its mapping with ELC. If any neighbor's mapping changes, X MUST re-evaluate and re-advertise the updated ELC status.
Entropy labels MUST NOT have values in the reserved label space (0–15) as defined in RFC 3032.
Even if an egress LSR signals an implicit null label (requesting PHP), it MUST still be prepared to pop the ELI and EL upon receiving a packet with those labels from an ingress that chose to insert them. Entropy Label Capability may be asymmetric between the two directions of a tunnel.
If any ELI processed by an egress LSR has the Bottom-of-Stack (BoS) bit set, the LSR MUST discard the packet and MAY log an error, because a BoS-set ELI indicates a malformed label stack.
It is REQUIRED that the label immediately preceding an Entropy Label in the MPLS label stack be an Entropy Label Indicator (ELI), where 'preceding' means closer to the top of stack (farther from the BoS bit). This is the mechanism by which egress LSRs unambiguously identify entropy labels.
Transit LSRs MUST NOT use reserved labels (values 0–15) as keys for the load-balancing function. If a transit LSR recognizes the ELI, it MAY load balance solely on the following label (the EL); otherwise it SHOULD use as much of the whole label stack as feasible.
When pushing ELI and EL, the ingress LSR MUST set the EL's TTL to zero (preventing inadvertent forwarding use) and MUST set the ELI's BoS bit to zero. The EL's BoS bit reflects whether more labels follow it in the stack.
An Entropy Label (EL) is an MPLS label that is not used for forwarding, is not signaled, and whose sole purpose is to add entropy to the label stack to improve load balancing. It is generated by the ingress LSR based on a load-balancing hash of the incoming packet's application-layer fields.
RSVP-TE signals Entropy Label Capability using bit 9 of the Attribute Flags TLV in the LSP_ATTRIBUTES object. The ELC flag in a Path message indicates the ingress can process ELs in the upstream direction (bidirectional LSPs only); in a Resv message it indicates the egress can process ELs downstream.
The BGP Entropy Label Capability (ELC) attribute is an optional, transitive BGP path attribute with type code 28. Its presence in a BGP UPDATE indicates that the advertising speaker can process entropy labels as egress LSR for all routes in that NLRI.
The canonical label stack for a tunnel with an entropy label is <TL, ELI, EL> followed by the remaining packet header. This increases label stack depth by two relative to a plain tunnel; transit LSRs swap only TL and leave ELI and EL intact, while the egress pops all three.
The Entropy Label Indicator (ELI) is a reserved MPLS label with value 7. It must immediately precede an Entropy Label in the label stack (closer to the top of stack) and allows egress LSRs to unambiguously distinguish entropy labels from application labels.
IANA allocated BGP Path Attribute Type Code 28 from the 'BGP Path Attributes' registry for the 'BGP Entropy Label Capability Attribute'.
IANA allocated bit 9 of the 'Attribute Flags' sub-registry of the RSVP-TE Parameters registry for the 'Entropy Label Capability' flag, applicable to both Attribute Flags Path and Attribute Flags Resv fields; it is not applicable to the RRO.
IANA allocated reserved label value 7 for the Entropy Label Indicator (ELI) from the 'Multiprotocol Label Switching Architecture (MPLS) Label Values' registry.
IANA allocated value 0x0206 from the IETF Consensus range (0x0001–0x07FF) of the LDP 'TLV Type Name Space' registry for the 'Entropy Label Capability TLV'.
If Entropy Label Capability is suppressed due to misconfiguration or malicious activity on an egress PE, the network falls back to load balancing without entropy labels, which is no worse than current production behavior. Operators should monitor PE configuration changes and the fairness of load distribution over LAG or ECMP paths.
There is little risk of entropy label forgery since end-users have no control over EL values. However, if EL values are computed solely from packet headers, a wiretapping side-channel becomes possible. Implementations should add a random or secret input to EL generation; many ECMP hashing algorithms already include a random factor to avoid polarization.
Ingress LSR EL insertion has five steps: (1) identify application, select fields, compute load-balancing hash LB; (2) push application label AL; (3) determine egress, tunnel, next-hop interface, and generate EL from LB; (4) push <TL, ELI, EL> if egress signaled ELC, else push <TL> only; (5) repeat from step 3 for additional tunnel hierarchy layers.
The LDP Entropy Label Capability (ELC) TLV has a 4-byte header: U-bit=1 (ignore if unknown), F-bit=1 (forward even if unknown), Type=0x0206 (16 bits), and Length=0 (16 bits, no value field). It appears as an Optional Parameter of the LDP Label Mapping Message TLV.