FAT and Entropy Labels
FAT and Entropy Labels
First, a special thanks to John E Drake and Stewart Bryant for helping me understand these concepts.
Two new types of labels are introduced to improve load-balancing in the MPLS network for equal-cost multipaths (ECMP) between two Label Switching Routers (LSRs). FAT (Flow Aware Transport for Psuedowires) label is defined in RFC 6391 and focuses on improvement of load-balancing of traffic flows in Pseudowires across MPLS network. Entropy label is still in the draft phase (Update: This is now RFC 6790) which focuses on improvement of load-balancing of traffic flows in IP Forwarding, L2 VPN and L3 VPN across MPLS network.
Definition of ECMP: ECMP means multiple equal-cost shortest paths between two LSRs, separated by one or more hops, that can be used for load-balancing traffic.
The Drivers
It is very important that packets belonging to a particular traffic flow (eg. packets from the same source-destination pair for a TCP connection) be mapped to the same "links" along the path towards egress node to avoid latency and jitter. In normal cases, the routers use Source and Destination IP addresses, protocol type and TCP/UDP port numbers as "keys" in a load-balancing algorithm to find the appropriate outgoing interface. (In Cisco IOS, CEF uses Source and Destination IP address as keys for IPv4/6 packets, and for non-IPv4/6 packets, it uses the last label in the label stack).
With MPLS encapsulations, it can be difficult for LSRs to identify the keys in MPLS networks and may require deep packet inspection. To avoid this deep packet inspection, the above mentioned documents propose inserting FAT/Entropy label at the bottom of the label stack which basically is the result of the load-balancing algorithm at the ingress LSR. The ingress LSR has the complete knowledge of the type of packet before it "pushes" the label stack. The transit LSRs can use the entire label stack as keys for the load-balancing algorithm.
FAT Label
It is quite common to have a pseudowire carry multiple traffic flows between customer edge routers. As mentioned above, it is very important that the packets for a particular flow travel the same path across the MPLS network in case of equal-cost paths. The RFC document introduces a new Label Stack Entry (LSE) at the bottom of the stack (S bit set to 1). The label in this LSE is called the flow label. The ingress PE maps individual flows within a pseudowire to the same flow label which causes all the packets of the flow to travel the same path. At the egress PE, the flow label is discarded without any processing.
Figure 1 shows the insertion of flow label.
The FAT label value is a not a reserved value (reserved range: 0 - 15). In order to avoid any processing of flow label at the egress LSR, the TTL value of the flow label is set to 0. Please note that the flow label is never signalled between PE routers. The flow label is generated locally and pushed at the bottom of the stack.
Signalling the Flow Label Capability
As per the RFC, the flow label capable PE router must signal the capability using a new Pseudowire Interface Parameter TLV called the Flow Label sub-TLV (FL sub-TLV) in the LDP (more specifically targeted-LDP). Figure 2 shows the structure of FL sub-TLV.
Type is set to 0x17 for FL sub-TLV as assigned by IANA.
Length is set to 4 bytes for FL sub-TLV.
T is set to 1 if a PE router wishes to send the flow label, otherwise, it is set to 0.
R is set to 1 if a PE router is willing to receive the flow label, otherwise, it is set to 0.
Reserved is set to 0.
It is recommended that both ingress and egress PE must agree on the support of flow label, hence ideally, both T and R should be set to 1.
Use case scenario
Figure 3 shows a use case scenario for FAT label.
Ingress PE router initiates the pseudowire setup and also includes the capability to transmit and receive flow label using the new Interface Parameter TLV. Similarly, the egress PE router signals the flow label handling capability. When PE1 receives traffic from the customer edge router, it identifies the keys and uses it in a hash algorithm to generate a flow label. It then pushes the label stack onto the traffic with the bottom label being the flow label (S=1, TTL=0) and forwards the packet to P2 router. P2 router MUST use the bottom label from the stack (i.e. the flow label in this case) in the hash algorithm to achieve a consistent result. PE4 router receives the packet with two labels with the top label being the PW label which is used to identify the pseudowire, and the flow label which is discarded without processing.
FAT label is supported in Cisco IOS on 7600 routers. The configuration template is as below-
Enabling Flow Label in Cisco IOS
pseudowire-class EoMPLS
encapsulation mpls
flow-label enable ! Enables flow-label support on Pseudowire
load-balance flow ! Enables load balancing on ECMPs
!
Entropy Label
Like FAT label, an Entropy label is not signalled and not used for forwarding. The Entropy label is also not a reserved label and the TTL is set to 0. Since Entropy label is a generalized extension to FAT label, it can be applied to IP forwarding, L2VPN or L3VPN. Hence, the egress LSR should be able to identify the presence of Entropy label in the label stack.
For L2VPN and L3VPN, there are less chances of ambiguity due to the presence of application label in the label stack. However, for IP forwarding, there is no application label in the stack, so there is a possibility that the egress LSR can be ambiguous of the presence of entropy label. To avoid this ambiguity, Entropy Label Indicator ELI (non-reserved, >15) (updated by RFC: reserved value 7) value is introduced. The egress LSR signals the ELI which indicates that the following label is the Entropy label. The ingress LSR includes the ELI in the label stack along with the Entropy label. The S bit for ELI is set to 0, and the TTL value is set to the same TTL value of above label.
The insertion of Entropy label (and ELI, if any) is shown in figure 4.
Signalling the Entropy Label Capability
The signalling of ELI value is application-specific. For most applications, the egress LSR may not advertise the ELI to use. As per the draft document, the egress LSR may advertise the same ELI value for all applications.
LDP Signalling
A new Entropy sub-TLV is introduced to signal the support for Entropy label and advertise the ELI. Figure 5 shows the structure of Entropy sub-TLV.
U is Unknown bit which is set to 1. If the LSR does not understand the Entropy sub-TLV, then it must ignore it. If U bit is set to 0, a notification is sent to the message originator and the entire message is ignored.
F is Forward bit which must be set to 1 which means the TLV is forwarded with the containing message.
Type value is not assigned by IANA yet.
Length is set to 8 bytes.
Value field contains the ELI label value. If ELI is not used, it is set to 0 by the egress LSR which means it does not need an ELI for the signalled application.
BGP Signalling
The draft document proposes signalling of ELI in a BGP UPDATE message. This indicates that the BGP speaker can process Entropy label for the NLRIs in the update message. The BGP speaker must advertise the ELI only if it can process Entropy label and it sets the next-hop to itself for the NLRIs advertised.
RSVP-TE Signalling
The Entropy label support and ELI value are advertised using new TLVs in RSVP PATH and RESV messages. The TLV structure is shown in figure 6.
The Type value depends on the LSR sending the TLV. The egress LSR includes the ELI attribute TLV in RESV message towards the ingress LSR. While the ingress LSR includes the attribute in PATH message. If the ELI value is set to 0 then it means the LSR does not need the ELI for that application. The Length of the TLV is set to 4 bytes. The ELI value is set from the non-reserved label space.
Example scenario
Figure 7 shows control and data plane for IP and L2/L3VPN forwarding.
In the control plane, for IP forwarding, the egress LSR (PE4) signals the support of Entropy label and ELI in BGP as it is the next-hop for the IPv4 prefixes it advertises to ingress LSR (PE1). With RSVP-TE, it is signalled in the new object in PATH and RESV messages depending on the direction (downstream or upstream). For L2 and L3 VPN forwarding, the edge routers signal the Entropy label support via BGP or T-LDP.
In the data plane, PE1 router identifies the application to which the packet belongs and the egress LSR as PE4 router. It is also aware that PE4 supports Entropy label. PE1 identifies the keys for the hash function and generates a result which is used as the Entropy label. PE1 pushes the label stack where the bottom label is the Entropy label. If PE4 requires an ELI, PE1 also pushes the ELI (advertised by PE4) above the Entropy label. P2 router MUST use the entire label stack as keys for the load-balancing algorithm. At PE4 router, it identifies the ELI (if any) and Entropy label which is discarded. Normally, it checks for the application label e.g. L2 or L3 VPN. But for IP forwarding, there is no application label. To handle this, the ELI is used; effectively acting as an application label.
The Entropy label is supported in Alcatel-Lucent devices for Epipe (VLL) and VPLS. A sample configuration template is shown below-
Enabling Entropy Label support in ALU TiMOS
configure service epipe <id>
spoke-sdp sdp-id:vc-id
hash-label
exit all
configure service vpls <id>
mesh-sdp sdp-id:vc-id
hash-label
exit all
The following packet capture shows the presence of Entropy label at the bottom of the stack.
Summary
Although both labels have same purpose, there are some stark differences-
1. For FAT label, there is no ELI advertised. This makes sense as the egress LSR can easily identify the FAT label since it is only used for Pseudowires.
2. For FAT label, the RFC suggests that the transit LSRs must use the bottom label (FAT label) in the label stack as keys for load-balancing algorithm. However, the Entropy label draft document suggests the transit LSR must use the entire label stack as keys.
Since Entropy label is a generalization of FAT label, it should see more acceptance by vendors.