Entropy Label

An entropy label is used only to improve load balancing performance. It is not assigned through protocol negotiation and is not used to forward packets. Entropy labels are generated using IP information on ingresses. The entropy label value cannot be set to a reserved label value in the range of 0 to 15. The entropy label technique extends the RSVP protocol and uses a set of mechanisms to improve load balancing in traffic forwarding.

Background

As user networks and the scope of network services continue to expand, load-balancing techniques are used to improve bandwidth between nodes. If tunnels are used for load balancing, transit nodes (P) obtain IP content carried in MPLS packets as a hash key. If a transit node cannot obtain the IP content from MPLS packets, the transit node can only use the top label in the MPLS label stack as a hash key. The top label in the MPLS label stack cannot differentiate underlying protocols in detail. As a result, the top MPLS labels are not distinguished when being used as hash keys, resulting in load imbalance. Per-packet load balancing can be used to prevent load imbalance but results in packets being delivered out of sequence. This drawback adversely affects service experience. To address the problems, the entropy label feature can be configured to improve load balancing performance.

Implementation

An entropy label is generated on an ingress LSR, and it is only used to enhance the ability to load-balance traffic. To help the egress LSR distinguish the entropy label generated by the ingress from application labels, an identifier label of 7 is added before an entropy label in the MPLS label stack.

Figure 1 Load balancing performed on transit nodes

The ingress LSR generates an entropy label and encapsulates it into the MPLS label stack. Before the ingress LSR encapsulates packets with MPLS labels, it can easily obtain IP or Layer 2 protocol data for use as a hash key. If the ingress LSR identifies the entropy label capability, it uses IP information carried in packets to compute an entropy label, adds it to the MPLS label stack, and advertises it to the transit node (P). The P uses the entropy label as a hash key to load-balance traffic and does not need to parse IP data inside MPLS packets.

The entropy label is negotiated using RSVP for improved load balancing. The entropy label is pushed into packets by the ingress and removed by the egress. Therefore, the egress needs to notify the ingress of the support for the entropy label capability.

On the network shown in Figure 1, the nodes process the entropy label from PE1 to PE2 as follows:

Egress (PE2): If the egress can parse an entropy label, the egress extends a Resv message by adding an entropy label capability TLV into the message. The egress sends the message to notify upstream nodes, including the ingress, of the local entropy label capability.
Transit node (P): sends a Resv message to upstream nodes to transparently transmit the downstream node's entropy label capability. If load balancing is enabled, the Resv messages sent by the transit node carry the entropy label capability TLV only if all downstream nodes have the capability. If a transit node does not identify the entropy label capability TLV, the transit node transparently transmits the TLV by undergoing the unknown TLV process.
Ingress (PE1): determines whether to add an entropy label into packets to improve load balancing based on the entropy label capability advertised by the egress.

Application Scenarios

Entropy labels can be used in the following scenarios:

On the network shown in Figure 1, entropy labels are used when load balancing is performed among transit nodes.
On the network shown in Figure 2, the entire tunnel has the entropy label capability only when both the primary and backup paths of the tunnel have the entropy label capability. An RSVP-TE session is established between each pair of directly connected devices (P1 through P4). On P1, for the tunnel to P3, the primary LSP is P1–>P3, and the backup LSP is P1–>P2–>P4–>P3. On P2, for the tunnel to P3, the primary LSP is P2–>P4–>P3, and the backup LSP is P2–>P1–>P3. In Figure 2, P1 and P2 are the downstream nodes of each other's backup path. Assume that the entropy label capability is enabled on P3 and this device sends a Resv message carrying the entropy label capability to P1 and P4. After receiving the message, P1 checks whether the entire LSP to P3 has the entropy label capability. Because the path P1–>P2 does not have the entropy label capability, P1 considers that the LSP to P3 does not have the entropy label capability. As a result, P1 does not send a Resv message carrying the entropy label capability to P2. P2 performs the same check after receiving a Resv message carrying the entropy label capability from P4. If the path P2–>P1 does not have the entropy label capability, P2 also considers that the LSP to P3 does not have the entropy label capability.
Figure 2 Special scenario
The entropy label feature applies to public network MPLS tunnels in service scenarios such as IPv4/IPv6 over MPLS, L3VPNv4/v6 over MPLS, VPLS/VPWS over MPLS, and EVPN over MPLS.

Benefits

Entropy labels help achieve more even load balancing.