Information About MPLS LDP Entropy Label Support
Overview of MPLS LDP Entropy Label
Prior to the MPLS LDP Entropy Label Support feature, at each MPLS hop, a deep packet inspection (DPI) is performed to determine the load balancing. With the introduction of MPLS LDP Entropy Label Support feature, at the ingress interface where MPLS is encapsulated, a DPI is performed to generate an entropy label. At the transit node, there is no need for DPI. The load balancing is done on the entropy label.
The entropy label provides ways of improving load balancing by eliminating the need for DPI at transit Label Switching Routers (LSRs). To eliminate DPI, the ingress LSR of an MPLS label switched path extracts the appropriate keys from a given packet, inputs them to the load balancing function, places the result in an additional label termed entropy label, and as a part of the MPLS label stack, the LSR pushes onto that packet. The transit LSRs use the label stack of the MPLS packet to perform load balancing.
If the transit LSR does not support LDP Entropy Label Capability (ELC), the transit LSR will propagate the label mapping message with the ELC flag so that the ingress LSR will add the entropy label. Any transit LSRs that do not support entropy label will ignore the entropy label and will load balance based on traditional DPI techniques.
Benefits of MPLS LDP Entropy Label Support
Each transit LSR along the path of a given LSP has to try to infer the underlying protocol within an MPLS packet to extract appropriate keys for load balancing. If the transit LSR is unable to infer the MPLS packet’s protocol, it will use the topmost (or all) MPLS labels in the label stack as keys for the load-balancing function. The result may be an extremely inequitable distribution of traffic across equal cost paths exiting a LSR. This is because MPLS labels are fairly coarse-grained forwarding labels that describe a next hop, or provide some demultiplexing or forwarding function, and do not describe the packet’s underlying protocol.
For example, an ingress LSR, a Provider Edge (PE) device has detailed knowledge of a packet’s contents, typically through a priority configuration of the encapsulations that are expected at a given Provider Edge-Customer Edge interface (IPv4, IPv6, VPLS, etc.), thus ensuring a more even distribution of load balancing for a given flow instead of overloading any particular path. The entropy label is protocol independent, it provides a unified way of load balancing without looking into the protocol header.
LDP Entropy Label Capability Signaling
Entropy Label Capability (ELC) is signaled from egress provider-edge (PE) device to ingress PE device. The egress LSR for a FEC initiates ELC by adding ELC Type Length Value (TLV), if configured, in the label mapping message that it sends to the peers. 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.
If the entire downstream peers have signaled entropy capability, ELC is propagated, else, it is not added in the label mapping message, and regular load balancing is used.
By configuring entropy labels, ingress LSR enables pushing of Entropy Label Indicator (ELI)/Entropy Label (EL). The ELI/EL value is pushed onto the label stack, if EL is enabled and downstream LSP is EL capable. The LDP processes the ELC TLV and sets EL capability flag accordingly for each LSP.
At the transit and egress LSR, LDP signals ELC, which indicates the ability to process entropy labels to upstream peers if ELC is received from downstream peers for all the next hops in a route.