RFC 6790
The Use of Entropy Labels in MPLS Forwarding
The Use of Entropy Labels in MPLS Forwarding 🎀
okay bestie, this one is RFC 6790 and it's a Standards Track doc 💅. That means it's an official IETF spec and not just vibes. It was published in November 2012 🌸 by an IETF working group, and the IESG approved it after public review. It's written by K. Kompella and J. Drake from Juniper Networks, S. Amante from Level 3 Communications, Inc., W. Henderickx from Alcatel-Lucent, and L. Yong from Huawei USA. Its ISSN is 2070-1721 🦋. It updates RFCs 3031, 3107, 3209, and 5036, and the header doesn't list anything it obsoletes.
Abstract ✨
Load balancing is a powerful way to engineer traffic across a network 🔥. This memo suggests ways to make load balancing better across MPLS networks by using the concept of "entropy labels". It defines the concept, explains why entropy labels are useful, lists the properties that give the most benefit 👑, and shows how they can be signaled and used for different applications. This document updates RFCs 3031, 3107, 3209, and 5036.
Status of This Memo 🧚
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🌈.
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6790 💜.
Copyright Notice 🫶
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Conventions Used ...........................................4
1.2. Motivation .................................................6
2. Approaches ......................................................7
3. Entropy Labels and Their Structure ..............................8
4. Data Plane Processing of Entropy Labels .........................9
4.1. Egress LSR .................................................9
4.2. Ingress LSR ...............................................10
4.3. Transit LSR ...............................................11
4.4. Penultimate Hop LSR .......................................12
5. Signaling for Entropy Labels ...................................12
5.1. LDP Signaling .............................................12
5.1.1. Processing the ELC TLV .............................13
5.2. BGP Signaling .............................................13
5.3. RSVP-TE Signaling .........................................14
5.4. Multicast LSPs and Entropy Labels .........................15
6. Operations, Administration, and Maintenance (OAM) and
Entropy Labels .................................................15
7. MPLS-TP and Entropy Labels .....................................16
8. Entropy Labels in Various Scenarios ............................16
8.1. LDP Tunnel ................................................17
8.2. LDP over RSVP-TE ..........................................20
8.3. MPLS Applications .........................................20
9. Security Considerations ........................................20
10. IANA Considerations ...........................................21
10.1. Reserved Label for ELI ...................................21
10.2. LDP Entropy Label Capability TLV .........................21
10.3. BGP Entropy Label Capability Attribute ...................21
10.4. RSVP-TE Entropy Label Capability Flag ....................22
11. Acknowledgments ...............................................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
Appendix A. Applicability of LDP Entropy Label Capability TLV .....241. Introduction 💖
Load balancing, also called multi-pathing, tries to spread traffic across a network by letting it use multiple paths 🦋. It has a bunch of perks: it makes capacity planning easier, it can soak up traffic surges by spreading them out over several paths, and it gives you better resilience because there are alternate paths if a link or node dies 💅.
As providers scale up, they use a few techniques to get more bandwidth between nodes. Two of the big ones are Link Aggregation Group (LAG) and Equal Cost Multi-Path (ECMP) 🔥. LAG bonds several physical circuits between two adjacent nodes so that higher-layer protocols see them as one single, higher-bandwidth "virtual" pipe. ECMP is for two nodes separated by one or more hops, and it load balances over several shortest paths in the network. This usually happens by setting IGP metrics so there are several equal cost paths between source-destination pairs ✨. Both of these can, and often do, show up together in different parts of a provider's network, depending on the choices that provider makes 🌸.
A really important requirement for load balancing is that packets belonging to a given "flow" must be mapped to the same path, meaning the exact same sequence of links across the network 🎀. This stops jitter, latency, and reordering problems for the flow 😭. What counts as a flow varies a lot. A common example is a TCP session. Other examples are a Layer 2 Tunneling Protocol (L2TP) session for a particular broadband user, or traffic inside an ATM virtual circuit 🧚.
To hit that requirement, a node looks at certain fields, called "keys", in a packet's header and feeds them into a load-balancing function (usually a hash function). That function picks the path for every packet in the flow 👑. Which keys get used depends on the packet type. For IP packets, a typical set is the IP source and destination addresses, the protocol type, and, for TCP and UDP traffic, the source and destination port numbers 🍓. Be too conservative with your fields and lots of flows end up on the same hash value, which means worse load balancing 🙈. Be too aggressive and one flow can map to multiple values, which can break the requirement above 💀.
MPLS networks follow most of the same principles and get most of the same benefits 💜. The catch is that finding useful keys for load balancing is harder. With MPLS encapsulation, transit Label Switching Routers (LSRs) may need to do fairly deep packet inspection just to find those keys 😭.
One way to skip that deep inspection is for the ingress LSR of a Label Switched Path to pull the right keys out of a packet, feed them into its load-balancing function, and put the result in an extra label called the "entropy label". It does this as part of the MPLS label stack it pushes onto the packet 🦋.
Transit LSRs can then load balance using the whole MPLS label stack, because the entropy label brings in the right amount of "entropy" 🌈.
There are five key reasons why this is useful:
- At the ingress LSR, MPLS encapsulation hasn't happened yet, so deep inspection isn't needed 🫶.
- The ingress LSR has more context and information about incoming packets than transit LSRs do 👑.
- Ingress LSRs usually run at lower bandwidths than transit LSRs, so they can do more work per packet ✨.
- Transit LSRs don't have to do deep packet inspection and can still load balance well using only a packet's MPLS label stack 💅.
- Transit LSRs don't have the full context an ingress LSR has, so they're stuck choosing between misreading packet fields as valid load-balancing keys (which causes packet-ordering problems) or playing it safe (which gives sub-optimal load balancing). Entropy labels take that choice off their plate 🔥.
This memo explains why entropy labels are needed and defines their properties. That includes how they're generated and received, and how transit LSRs are expected to behave 🌸. It also describes in general how signaling works and what needs to be signaled, plus the specifics for signaling entropy labels with LDP [RFC5036], BGP [RFC4271], and RSVP - Traffic Engineering (RSVP-TE) [RFC3209] 🎀.
1.1. Conventions Used 🍓
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🧚.
These acronyms and initialisms are used in the document:
- BoS: Bottom of Stack
- CE: Customer Edge
- ECMP: Equal Cost Multi-Path
- EL: Entropy Label
- ELC: Entropy Label Capability
- ELI: Entropy Label Indicator
- FEC: Forwarding Equivalence Class
- LAG: Link Aggregation Group
- LER: Label Edge Router
- LSP: Label Switched Path
- LSR: Label Switching Router
- PE: Provider Edge
- PW: Pseudowire
- PHP: Penultimate Hop Popping
- TC: Traffic Class
- TTL: Time to Live
- UHP: Ultimate Hop Popping
- VPLS: Virtual Private LAN (Local Area Network) Service
- VPN: Virtual Private Network
The term "ingress LSR" (or "egress LSR") is used interchangeably with "ingress LER" (or "egress LER"). The term "application" throughout the text refers to an MPLS application (such as a VPN or VPLS) 💜.
A label stack (say of three labels) is denoted by <L1, L2, L3>, where L1 is the "outermost" label and L3 the "innermost" (closest to the payload). Packet flows are depicted left to right, and signaling is shown right to left (unless otherwise indicated) 🦋.
The term "label" is used both for the entire 32-bit label stack entry and for the 20-bit label field within a label stack entry. It should be clear from the context which is meant 🌈.
1.2. Motivation 🌸
okay bestie, MPLS is literally the MVP of forwarding 💅 It transports several dozen types of protocols, most notably: IP, PWs, VPLS, and IP VPNs. Inside each type there are usually several variants, each with its own set of load-balancing keys 🦋 Think IPv4, IPv6, IPv6 in IPv4, etc. for IP and Ethernet, and ATM, Frame-Relay, etc. for PWs. There are also different flavours of Ethernet over PW encapsulation, ATM over PW encapsulation, etc. And given how popular MPLS is, it's likely to keep getting extended to carry new protocols 🌈
Right now, every transit LSR along the path of a given LSP has to try to infer the underlying protocol inside an MPLS packet so it can pull out keys for load balancing 😭 If the transit LSR can't infer the packet's protocol (which is often the case 💀), it'll typically use the topmost (or all) MPLS labels in the label stack as its keys. That can lead to an extremely inequitable distribution of traffic across the equal cost paths exiting that LSR 🙈 The reason? MPLS labels are generally pretty coarse-grained forwarding labels. They typically describe a next hop, or provide some demultiplexing and/or forwarding function, and they don't describe the packet's underlying protocol.
Now, an ingress LSR (like a PE router) has detailed knowledge of a packet's contents 🧚 Usually that's because of a priori configuration of the encapsulations expected at a given PE-CE interface (e.g., IPv4, IPv6, VPLS, etc.). They may also have more flexible forwarding hardware, depending on implementation details. PE routers need this information and these capabilities to:
- apply the required services for the CE;
- discern the packet's Class of Service (CoS) forwarding treatment;
- apply filters to forward or block traffic to/from the CE;
- forward routing/control traffic to an onboard management processor; and,
- load balance the traffic on its uplinks to transit LSRs (e.g., P routers).
By knowing the expected encapsulation types, an ingress LSR can apply a more specific set of payload parsing routines to extract the keys appropriate for a given protocol. That gives a significantly improved accuracy in working out the right load-balancing behaviour for each protocol ✨
Here's the big idea 👑 If the ingress LSR captures the flow information it gathered in a convenient form for downstream transit LSRs, those transit LSRs can stay completely oblivious to the contents of each MPLS packet. They'd only use the captured flow information to load balance. There's no reason to duplicate an ingress LSR's complex packet/payload parsing functionality in a transit LSR! That means simpler transit LSRs that can more easily scale to higher forwarding rates, larger port density, lower power consumption, etc. 🎀 The idea in this memo is to capture this flow information as a label, the so-called "entropy label".
Ingress LSRs can also adapt more readily to new protocols, and extract the right keys for load-balancing packets of those protocols 💖 So deploying new protocols or services in edge devices needs fewer concomitant changes in the core. The result is higher edge-service velocity and, at the same time, more stable core networks 🫶
2. Approaches 🦋
There are two main approaches to encoding load-balancing information in the label stack 💅 The first allocates multiple labels for a particular Forwarding Equivalence Class (FEC). These labels are equivalent in terms of forwarding semantics, but having multiple labels gives flexibility in assigning labels to flows belonging to the same FEC. This approach has the advantage that the label stack has the same depth whether or not you use label-based load balancing. So there's no change to forwarding operations on transit and egress LSRs. BUT it has a major drawback: there's a significant increase in both signaling and forwarding state 😭
The other approach encodes the load-balancing information as an additional label in the label stack, which increases the depth of the label stack by one 🌈 With this approach there's minimal change to signaling state for a FEC. There's also no change in forwarding operations in transit LSRs, and no increase of forwarding state in any LSR ✨ The only purpose of the additional label is to increase the entropy in the label stack, so it's called an "entropy label". This memo focuses solely on this approach 🧚
This latter approach uses upstream-generated entropy labels, which may conflict with downstream-allocated application labels. There are a few ways to deal with that: 1) allocate a pair of labels for each FEC, one that must have an entropy label below it and one that must not; 2) use a label (the "Entropy Label Indicator") to indicate that the next label is an entropy label; and 3) allow entropy labels only where there is no possible confusion. The first doubles control and data plane state in the network, and the last is too restrictive. The approach taken here is the second 💜 In making both of the above choices, the trade-off is to increase label stack depth rather than control and data plane state in the network.
Finally, one may choose to associate ELs with MPLS tunnels (LSPs) or with MPLS applications (e.g., VPNs). (What this entails is described in later sections.) We take the former approach, for the following reasons 🍓
- There are a small number of tunneling protocols for MPLS, but a large and growing number of applications. Defining ELs on a tunnel basis means simpler standards, lower development, interoperability, and testing efforts.
- As a consequence, there will be much less churn in the network as new applications (services) are defined and deployed.
- Processing application labels in the data plane is more complex than processing tunnel labels. Thus, it is preferable to burden the latter rather than the former with EL processing.
- Associating ELs with tunnels makes it simpler to deal with hierarchy, be it LDP-over-RSVP-TE or Carrier's Carrier VPNs. Each layer in the hierarchy can choose independently whether or not it wants ELs.
The cost of this approach is that ELIs will be mandatory. Again, the trade-off is the size of the label stack 🙈 To summarize, the net increase in the label stack to use entropy labels is two: one reserved label for the ELI and the entropy label itself. 💀
3. Entropy Labels and Their Structure 🎀
An entropy label (as used here) is a label:
- that is not used for forwarding;
- that is not signaled; and
- whose only purpose in the label stack is to provide "entropy" to improve load balancing.
Entropy labels are generated by an ingress LSR, based entirely on load-balancing information. However, they MUST NOT have values in the reserved label space (0-15) [RFC3032].
Since entropy labels are generated by an ingress LSR, an egress LSR MUST be able to distinguish unambiguously between entropy labels and application labels. To accomplish this, it is REQUIRED that the label immediately preceding an Entropy Label (EL) in the MPLS label stack be an Entropy Label Indicator (ELI), where "preceding" means closer to the top of the label stack (farther from the bottom of stack indication). The ELI is a reserved label with value 7. How to set values of the TTL, TC, and "Bottom of Stack" (BoS) fields [RFC3032] for the ELI and for ELs is discussed in Section 4.2 ✨
Entropy labels are useful for pseudowires [RFC4447]. [RFC6391] explains how entropy labels can be used for pseudowires that are of the RFC 4447 style, and is therefore complementary to this memo. This memo focuses on how entropy labels can be used for tunnels and thus for all other MPLS applications 🧚
4. Data Plane Processing of Entropy Labels 👑
4.1. Egress LSR 💖
Suppose egress LSR Y is capable of processing entropy labels for a tunnel. Y indicates this to all ingresses via signaling (see Section 5). Y MUST be prepared to deal both with packets with an imposed EL and those without, and the ELI will distinguish these cases. If a particular ingress chooses not to impose an EL, Y's processing of the received label stack (which might be empty) is as if Y chose not to accept ELs.
If an ingress LSR X chooses to impose an EL, then Y will receive a tunnel termination packet with label stack <TL, ELI, EL> <remaining packet header>. Y recognizes TL as the label it distributed to its upstreams for the tunnel, and pops it. (Note that TL may be the implicit null label, in which case it doesn't appear in the label stack.) Y then recognizes the ELI and pops two labels: the ELI and the EL. Y then processes the remaining packet header as normal. This may require further processing of tunnel termination, perhaps with further ELI+EL pairs. When processing the final tunnel termination, Y MAY enqueue the packet based on that tunnel TL's or ELI's TC value, and MAY use the tunnel TL's or ELI's TTL to compute the TTL of the remaining packet header. The EL's TTL MUST be ignored 🌸
If any ELI processed by Y has the BoS bit set, Y MUST discard the packet and MAY log an error. The EL's BoS bit will indicate whether or not there are more labels in the stack 🙈
4.2. Ingress LSR 💅
okay so, if egress LSR Y tells the network (through signaling) that it can process ELs on a particular tunnel, then ingress LSR X gets to decide whether it actually inserts ELs for packets going into that tunnel 🎀. Y MUST handle both cases, so Y has to be ready for either choice ✨
Here's how X inserts ELs, step by step 🧚:
- On an incoming packet, figure out which application it belongs to 💖. Based on that, pick the right fields to feed into the load-balancing function, run the function on those fields, and call the output LB.
- Work out the application label AL (if there is one). Push
<AL>onto the packet. - Based on the application, the LB output, and other factors, decide the egress LSR Y, the tunnel to Y, the specific interface to the next hop, and therefore the tunnel label TL. Use LB to generate the entropy label EL.
- If Y hasn't indicated that it can process ELs for the chosen tunnel, push
<TL>onto the packet. If Y has indicated that it can process ELs for that tunnel, push<TL, ELI, EL>onto the packet. X SHOULD put the same TTL and TC fields for the ELI as it does for TL. X MAY choose different values for the TTL and TC fields if it is known that the ELI will not be exposed as the top label at any point along the LSP (as may happen in cases where PHP is used and the ELI and EL are not stripped at the penultimate hop (see Section 4.4). The BoS bit for the ELI MUST be zero (i.e., BoS is not set). The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding. The TC for the EL may be any value. The BoS bit for the EL depends on whether or not there are more labels in the label stack. It's giving precision 🙈 - X then checks whether further tunnel hierarchy is needed. If so, X goes back to step 3, possibly with a new egress Y for the new tunnel. Otherwise, X is done and sends out the packet 🦋.
Some notes you need to know, bestie 📝:
- a. X computes load-balancing information and generates the EL based on the incoming application packet, even though the signaling of EL capability is associated with tunnels.
- b. X MAY insert several entropy labels in the stack (each, of course, preceded by an ELI), potentially one for each hierarchical tunnel, provided that the egress for that tunnel has indicated that it can process ELs for that tunnel.
- c. X MUST NOT include an entropy label for a given tunnel unless the egress LSR Y has indicated that it can process entropy labels for that tunnel. Hard rule, no exceptions 🙅♀️
- d. The signaling and use of entropy labels in one direction (signaling from Y to X and data path from X to Y) is completely independent of the signaling and use of entropy labels in the reverse direction (signaling from X to Y and data path from Y to X). Two separate lanes, zero drama 🌈
4.3. Transit LSR 🦋
Transit LSRs MAY operate with no change in forwarding behavior. The stuff below is just suggestions for optimizations that improve load balancing, reduce the amount of packet data processed, and/or enhance backward compatibility ✨.
If a transit LSR recognizes the ELI, it MAY choose to load balance solely on the following label (the EL). Otherwise, it SHOULD use as much of the whole label stack as feasible as keys for the load-balancing function. In any case, reserved labels MUST NOT be used as keys for the load-balancing function. Reserved labels are a no-go for hashing, periodt 🙅♀️
Some transit LSRs look beyond the label stack for better load-balancing information. This is a simple, backward-compatible approach in networks where some ingress LSRs impose ELs and others don't. However, this is of limited incremental value if an EL is indeed present and requires more packet processing from the LSR. A transit LSR MAY choose to parse the label stack for the presence of the ELI and look beyond the label stack only if it does not find it, thus retaining the old behavior when needed, yet avoiding unnecessary work if not needed. Smart, efficient, and iconic 👑.
As stated in Sections 4.1 and 5, an egress LSR that signals both ELC and implicit null MUST pop the ELI and the next label (which should be the EL), if it encounters a packet with the ELI as the topmost label. Any other LSR (including PHP LSRs) MUST drop such packets, as per Section 3.18 of [RFC3031]. Yikes, no mercy for stray packets 💀
4.4. Penultimate Hop LSR 🍓
No change is needed at penultimate hop LSRs. However, a PHP LSR that recognizes the ELI MAY choose to pop the ELI and following label (which should be an entropy label) in addition to popping the tunnel label, provided that doing so doesn't diminish its ability to load balance on the next hop. Optional bonus, but only if it doesn't hurt the load balancing 💅
5. Signaling for Entropy Labels 🌈
An egress LSR Y can signal to ingress LSR(s) its ability to process entropy labels (henceforth called "Entropy Label Capability" or ELC) on a given tunnel. In particular, even if Y signals an implicit null label, indicating that PHP is to be performed, Y MUST be prepared to pop the ELI and EL. Even when PHP is happening, Y still has to be ready 🫶
Note that Entropy Label Capability may be asymmetric. If LSRs X and Y are at opposite ends of a tunnel, X may be able to process entropy labels, whereas Y may not. The signaling extensions below allow for this asymmetry. Not everyone is the same, and that's totally fine 🌸
For an illustration of signaling and forwarding with entropy labels, see Section 8. Go peek at that one, it's a vibe ✨
5.1. LDP Signaling 🎀
A new LDP TLV [RFC5036] is defined to signal an egress's ability to process entropy labels. This is called the ELC TLV and may appear as an Optional Parameter of the Label Mapping Message TLV.
The presence of the ELC TLV in a Label Mapping Message indicates to ingress LSRs that the egress LSR can process entropy labels for the associated LDP tunnel. The ELC TLV has Type 0x0206 and Length 0.
The structure of the ELC TLV is shown below 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type 0x0206 | Length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Entropy Label Capability TLV
Where:
- U: Unknown bit. This bit MUST be set to 1. If the ELC TLV is not understood by the receiver, then it MUST be ignored.
- F: Forward bit. This bit MUST be set to 1. Since the ELC TLV is going to be propagated hop-by-hop, it should be forwarded even by nodes that may not understand it.
- Type: Type field (
0x0206) - Length: Length field. This field specifies the total length in octets of the ELC TLV and is currently defined to be
0.
5.1.1. Processing the ELC TLV 💖
An LSR that receives a Label Mapping with the ELC TLV but does not understand it MUST propagate it intact to its neighbors and MUST NOT send a notification to the sender (following the meaning of the U- and F-bits). Pass it along, don't tattle 🙈
An LSR X may receive multiple Label Mappings for a given FEC F from its neighbors. In its turn, X may advertise a Label Mapping for F to its neighbors. If X understands the ELC TLV, and if any of the advertisements it received for FEC F does not include the ELC TLV, X MUST NOT include the ELC TLV in its own advertisements of F. If all the advertised Mappings for F include the ELC TLV, then X MUST advertise its Mapping for F with the ELC TLV. If any of X's neighbors resends its Mapping, sends a new Mapping or sends a Label Withdraw for a previously advertised Mapping for F, X MUST re-evaluate the status of ELC for FEC F, and, if there is a change, X MUST re-advertise its Mapping for F with the updated status of ELC. Keep checking the vibes and update when things change 🔄
5.2. BGP Signaling 🌸
When BGP [RFC4271] is used for distributing Network Layer Reachability Information (NLRI) as described in, for example, [RFC3107], the BGP UPDATE message may include the ELC attribute as part of the Path Attributes. This is an optional, transitive BGP attribute of value 28. The inclusion of this attribute with an NLRI indicates that the advertising BGP router can process entropy labels as an egress LSR for all routes in that NLRI.
A BGP speaker S that originates an UPDATE should include the ELC attribute only if both of the following are true:
- A1: S sets the BGP
NEXT_HOPattribute to itself AND - A2: S can process entropy labels.
Suppose a BGP speaker T receives an UPDATE U with the ELC attribute. T has two choices. T can simply re-advertise U with the ELC attribute if either of the following is true:
- B1: T does not change the
NEXT_HOPattribute OR - B2: T simply swaps labels without popping the entire label stack and processing the payload below.
An example of the use of B1 is Route Reflectors 🪞.
However, if T changes the NEXT_HOP attribute for U and in the data plane pops the entire label stack to process the payload, T MAY include an ELC attribute for UPDATE U' if both of the following are true:
- C1: T sets the
NEXT_HOPattribute of U' to itself AND - C2: T can process entropy labels.
Otherwise, T MUST remove the ELC attribute. No ELC attribute, no exceptions 🙅♀️
5.3. RSVP-TE Signaling ✨
Entropy label support is signaled in RSVP-TE [RFC3209] using the Entropy Label Capability (ELC) flag in the Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420]. The presence of the ELC flag in a Path message indicates that the ingress can process entropy labels in the upstream direction. This only makes sense for a bidirectional LSP and MUST be ignored otherwise. The presence of the ELC flag in a Resv message indicates that the egress can process entropy labels in the downstream direction.
The bit number for the ELC flag is 9. Bit 9, remember it 🦋
5.4. Multicast LSPs and Entropy Labels 👑
Multicast LSPs [RFC4875] [RFC6388] typically do not use ECMP for load balancing, as the combination of replication and multi-pathing can lead to duplicate traffic delivery. However, these LSPs can traverse bundled links [RFC4201] and LAGs. In both these cases, load balancing is useful, and hence entropy labels can be of value for multicast LSPs.
The methodology defined for entropy labels here will be used for multicast LSPs. However, the details of signaling and processing ELs for multicast LSPs will be specified in a future document. Stay tuned for that plot twist 🌈✨
6. Operations, Administration, and Maintenance (OAM) and Entropy Labels ✨
Okay so, OAM is basically a set of data plane tools that let a network operator keep an eye on their network 👀 and then level up how it behaves and performs 🔥. Think efficient and automatic detection, localization, diagnosis, and handling of defects. Literally the network's health check, bestie 🫶.
Right now, the MPLS OAM mechanisms that are defined are LSP ping/traceroute [RFC4379] and Bidirectional Forwarding Detection (BFD) for MPLS [RFC5884]. BFD is the one that checks connectivity between the endpoints of an LSP, and it recommends setting up a separate BFD session for every path between those endpoints 💜.
Now the LSP traceroute procedures in [RFC4379] are how an ingress LSR can find label ranges that let it send packets down every path to the egress LSR 🦋. Here's the vibe: the ingress LSR asks each transit LSR along a given path to the egress, one at a time, to hand back a label range. Any label from that range, when put in a packet, makes the replying transit LSR push the packet out the egress interface for that path 🍓. The ingress passes the range that transit LSR N sent back over to transit LSR N + 1, and that one replies with a range that's less than or equal in span to the one it got. This keeps going until the penultimate transit LSR replies with a range that the ingress is happy with, and that every LSR before it on the path is also happy with 💅.
BUT (lowkey a big but 😭), the LSP traceroute procedures don't say where in the label stack the value from the label range should go. They also don't say whether deep packet inspection is allowed, and if it is, which keys and key values to use 💀.
So this memo updates LSP traceroute by saying the value from the label range goes in the entropy label 🌈. That means deep packet inspection isn't necessary, although an LSR is allowed to use it, as long as it does so consistently. In other words, if the label range going to a given downstream LSR was computed with deep packet inspection, the data path should use the same approach and the same keys 🎀.
Also, to get a BFD session on a given path, a value from that path's label range should be used as the EL value for the BFD packets sent on that path 🧚.
7. MPLS-TP and Entropy Labels 🌸
Since the MPLS Transport Profile (MPLS-TP) doesn't use ECMP, entropy labels just aren't applicable to an MPLS-TP deployment 🙈. Not a thing there, periodt.
8. Entropy Labels in Various Scenarios 🦋
This section walks through how entropy labels show up in different scenarios 🍓. Heads up though: the material here is illustrative and gives implementations some guidance, but it is not a normative part of this specification ✨.
Here's how the figures work: the conventions below show what happens between X and Y. Control plane signaling goes right to left, and data plane processing goes left to right 💜.
Protocols
Y: <--- [L, E] Y signals L to X
X ------------- Y
Data Plane:
X-Y: <L, ELI, EL> Label Stack from X -> Y
Label Stack Operations:
X: +<L, ELI, EL> X pushes <L, ELI, EL>
Y: -<L, ELI, EL> Y pops <L, ELI, EL>So this means Y signals L to X for an LDP tunnel 🫶. E can be one of two things:
- 0: meaning egress is NOT entropy label capable, or
- 1: meaning egress is entropy label capable
The line with LS: shows the label stack on the wire. Underneath it is what each LSR does in the data plane: + means push the label stack that follows, - means pop the label stack that follows, and L~L' means swap L with L' 🔥.
8.1. LDP Tunnel 🎀
These figures show a few simple intra-AS LDP tunnels 💖. The first one is ultimate hop popping (UHP) with the ingress inserting an EL, the second is UHP with no ELs, the third is PHP with ELs, and the last is PHP with no ELs but with an application label AL (which could be a VPN label, for example) ✨.
Also, in all of these cases the MPLS application doesn't matter. X might push more labels (maybe for a VPN or VPLS) below the ones shown, and Y pops them 🧚.
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [TL0, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, ELI, EL>
A-B: <TL3,ELI,EL>
B-W: <TL2,ELI,EL>
W-Y: <TL0,ELI,EL>
Label Stack Operations:
X: +<TL4, ELI, EL>
A: TL4~TL3
B: TL3~TL2
W: TL2~TL0
Y: -<TL0, ELI, EL>
Figure 2: LDP with UHP; Ingress Inserts ELsA: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [TL0, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4>
A-B: <TL3>
B-W: <TL2>
W-Y: <TL0>
Label Stack Operations:
X: +<TL4>
A: TL4~TL3
B: TL3~TL2
W: TL2~TL0
Y: -<TL0>
Figure 3: LDP with UHP; Ingress Does Not Insert ELsQuick note on Figure 3 🌈: the Egress Y is signaling that it's EL-capable, but the Ingress X has decided not to insert ELs. Its call 💅.
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, ELI, EL>
A-B: <TL3,ELI,EL>
B-W: <TL2,ELI,EL>
W-Y: <ELI,EL>
Label Stack Operations:
X: +<TL4, ELI, EL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<ELI, EL>
Figure 4: LDP with PHP; Ingress Inserts ELsA: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
VPN: <------------------------------------------ [AL]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, AL>
A-B: <TL3, AL>
B-W: <TL2, AL>
W-Y: <AL>
Label Stack Operations:
X: +<TL4, AL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<AL>
Figure 5: LDP with PHP + VPN; Ingress Does Not Insert ELsSame deal in Figure 5 🍓: the Egress Y is EL-capable, but the Ingress X chose not to insert ELs.
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
VPN: <--------------------------------------------- [AL]
X --------------- A ------------ B --- W ---------- Y
Data Plane:
X-A: <TL4,ELI,EL,AL>
A-B: <TL3,ELI,EL,AL>
B-W: <TL2,ELI,EL,AL>
W-Y: <ELI,EL,AL>
Label Stack Operations:
X: +<TL4,ELI,EL,AL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<ELI,EL,AL>
Figure 6: LDP with PHP + VPN; Ingress Inserts ELs8.2. LDP over RSVP-TE 🧚
Figure 7 shows "LDP over RSVP-TE" tunnels 💜. X and Y are the ingress and egress (in that order) of the LDP tunnel, and A and W are the ingress and egress of the RSVP-TE tunnel. Both the LDP and RSVP-TE tunnels are assumed to have PHP 🌈.
LDP: <--- [L4, 1] <------- [L3, 1] <--- [3, 1]
RSVP-TE: <-- [Rn, 0]
<-- [3, 0]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <L4, ELI, EL>
A-B: <Rn,L3,ELI,EL>
B-W: <L3,ELI,EL>
W-Y: <ELI,EL>
Label Stack Operations:
X: +<L4, ELI, EL>
A: <L4~L3>+Rn
B: -Rn
W: -L3
Y: -<ELI, EL>
Figure 7: LDP with ELs over RSVP-TE Tunnels without ELs8.3. MPLS Applications 💖
For each unicast tunnel starting at an ingress LSR X, X has to remember whether the egress for that tunnel can process entropy labels 🫶. X doesn't need to keep state for each application running over that tunnel. That said, an ingress PE can decide on a per-application basis whether or not to insert ELs ✨. For example, X might have an application it doesn't want to use ECMP with (like circuit emulation), or one where it doesn't know which keys to use for load balancing (like Appletalk over a pseudowire) 🙈. In either of those cases, X may choose not to insert entropy labels, but it may still choose to insert them for an IP VPN over that same tunnel 🦋.
9. Security Considerations 🔒✨
Okay bestie, this part is the security stuff, so we're being serious but still iconic 💅. This doc is about an egress PE telling an ingress PE that it can handle entropy labels 🎀. Those labels help transit LSRs balance load better across LAG and ECMP paths 🦋.
This doc does not add new security holes to LDP, BGP, or RSVP-TE 🙅♀️. For the security mechanisms of each protocol, check their own Security Considerations sections ([RFC5036], [RFC4271], and [RFC3209]).
Since nobody at the end-user level controls the entropy label values, forging them is pretty unlikely 🙈. Forgery could cause uneven load balancing, so that's the main thing to avoid. Here's the catch 👀: if the EL value is calculated only from packet headers, a relatively efficient wiretapping interface could be added, depending on the function used to generate the EL value. An implementation can protect against this by adding some other input to the EL value generation. That makes it harder to build a table of EL values to tap, even if you know the keys from the packet. For example, the ingress LSR could generate a random input to the EL generation process 🧚. Honestly, many ECMP hashing algorithms already have a random factor to avoid polarization issues, so it's not all bad 💜.
If Entropy Label Capability isn't signaled from an egress PE to an ingress PE, say because of malicious configuration activity on the egress PE 💀, then the PE falls back to not using entropy labels for load balancing over LAG or ECMP paths. Generally, that's no worse than what current production networks do, so it's not the end of the world 🌸. Still, it's recommended that operators keep an eye on changes to PE configurations and, even more importantly, on how fair the load distribution is across LAG or ECMP paths 👑. If that fairness changes, it could point to a misconfiguration, a bug, or some other non-optimal behavior on their PEs, and they should take corrective action 🔥.
10. IANA Considerations 📋🌈
10.1. Reserved Label for ELI
IANA has allocated a reserved label for the Entropy Label Indicator (ELI) from the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry 🏷️.
10.2. LDP Entropy Label Capability TLV
IANA has allocated the value 0x0206 from the IETF Consensus range (0x0001-0x07FF) in the "TLV Type Name Space" registry as the "Entropy Label Capability TLV" ✨.
10.3. BGP Entropy Label Capability Attribute
IANA has allocated the Path Attribute Type Code 28 from the "BGP Path Attributes" registry as the "BGP Entropy Label Capability Attribute" 🦋.
10.4. RSVP-TE Entropy Label Capability Flag
IANA has allocated a new bit from the "Attribute Flags" sub-registry of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry 💖.
Bit | Name | Attribute | Attribute | RRO
No | | Flags Path | Flags Resv |
----+--------------------------+------------+------------+-----
9 Entropy Label Capability Yes Yes No11. Acknowledgments 🫶
We wish to thank Ulrich Drafz for his contributions 🙌, as well as the entire "hash label" team for their valuable comments and discussion 🍓.
Sincere thanks to Nischal Sheth for his many suggestions and comments, and for his careful reading of the document, especially with regard to data plane processing of entropy labels 💜.
Most of the work Kireeti Kompella did on this document was done while he was at Juniper Networks. He has since moved to Contrail Systems 🧚.
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.12.2. Informative References
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391,
November 2011.Appendix A. Applicability of LDP Entropy Label Capability TLV 🧠
In the case of unlabeled IPv4 (Internet) traffic, the best practice is for an egress LSR to propagate eBGP learned routes within a Service Provider's Autonomous System after resetting the BGP next-hop attribute to one of its loopback IP addresses 🌐. That loopback IP address is injected into the Service Provider's IGP and, at the same time, a label is assigned to it via LDP. So when an ingress LSR does a forwarding lookup for a BGP destination, it recursively resolves the associated next hop to a loopback IP address and the associated LDP label of the egress LSR 🔁.
So, for unlabeled IPv4 traffic, the LDP Entropy Label Capability TLV will typically be applied only to the FEC for the loopback IP address of the egress LSR 💅. The egress LSR doesn't need to announce an Entropy Label Capability for the eBGP learned route 🙌.
Authors' Addresses 📮
Kireeti Kompella
Contrail Systems
2350 Mission College Blvd.
Santa Clara, CA 95054
US
EMail: kireeti.kompella@gmail.com
John Drake
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: jdrake@juniper.net
Shane Amante
Level 3 Communications, Inc.
1025 Eldorado Blvd
Broomfield, CO 80021
US
EMail: shane@level3.net
Wim Henderickx
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp
Belgium
EMail: wim.henderickx@alcatel-lucent.com
Lucy Yong
Huawei USA
5340 Legacy Dr.
Plano, TX 75024
US
EMail: lucy.yong@huawei.com📦 where this page comes from
- ietf: rfc6790 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms