]> China Mobile

32 Xuanwumen West Street Beijing 100053 China lizhiqiangyjy@chinamobile.com

China Mobile

32 Xuanwumen West Street Beijing 100053 China duzongpeng@chinamobile.com

Centec Networks

Suzhou 215000 China chengw@centec.com

Centec Networks

Suzhou 215000 China wangjj@centec.com

Centec Networks

Suzhou 215000 China zhanggy@centec.com

Routing RTGWG ECMP LAG load balancing hash tunnel This document specifies a combined hash mechanism for load balancing in Equal-Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) environments. When processing tunneled traffic, traditional hash methods that operate on either outer or inner packet fields may result in uneven traffic distribution (polarization). This specification defines a method to extend effective hash entropy by combining multiple independently computed hash values, enabling network devices to consider multi-layer packet information for path selection, thereby improving traffic distribution uniformity. This mechanism is compatible with existing hash computation architectures and does not require packet format modifications or new protocol field definitions.

Introduction Equal-Cost Multi-Path (ECMP) routing and Link Aggregation Groups (LAGs) are widely deployed technologies in modern networks for bandwidth scaling and redundancy. As described in and , these technologies improve network performance and reliability by distributing traffic across multiple equal-cost paths. In ECMP/LAG environments, routers typically employ hash-based methods to select forwarding paths. As analyzed in , hash algorithms extract key information from packet header fields to compute hash values used for path selection. Typical hash inputs include the 5-tuple (source/destination IP addresses, source/destination ports, protocol type) or subsets thereof. However, identifies that in tunnel scenarios, when multiple distinct user flows are encapsulated within the same tunnel, hashing based solely on outer headers causes all encapsulated flows to be mapped to the same path, resulting in polarization. While RFC 6438 addresses this by setting the flow label in the outer IPv6 header, this requires tunnel endpoint cooperation and only applies to IPv6 outer encapsulation scenarios. This document defines a complementary combined hash mechanism that extends available hash entropy by combining multiple independently computed hash values within the forwarding device, thereby improving load distribution for tunneled traffic without modifying packet formats. This mechanism can be used in conjunction with and , or deployed independently.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This section defines terms used in this document. Some terms are inherited from , , , and .

Equal-Cost Multi-Path (ECMP):

A routing strategy that allows packet forwarding to a single destination over multiple paths with equal routing cost. See .

Link Aggregation Group (LAG):

A technology that bundles multiple physical links into a single logical link, providing bandwidth aggregation and link redundancy. See .

Hash Entropy:

The amount of variability in the input to a hash function. Higher entropy typically leads to more uniform hash output distribution.

Polarization:

In ECMP/LAG environments, the phenomenon where traffic concentrates on a subset of paths due to insufficient variability in hash inputs. See .

Base Hash Value:

A hash value computed by a single hash computation unit based on a specific set of packet fields.

Combined Hash Value:

A new hash value derived by applying a combination operation to two or more base hash values.

Hash Field Set:

The set of packet fields used as hash input. This document defines standard field sets including L2 (source MAC, destination MAC, VLAN tag, EtherType), L3 (source IP, destination IP, protocol), L4 (source port, destination port), OUTER (outer header fields), and INNER (inner/payload header fields).

Problem Statement

Tunnel Traffic Polarization As described in Section 1.1 of , in tunnel scenarios, when traffic from multiple sources is aggregated into a single tunnel, all encapsulated packets have the same outer source and destination addresses. If ECMP/LAG paths exist between intermediate routers, and path selection is based solely on hashing the outer 5-tuple (or its subset), all tunnel traffic will be mapped to the same path, preventing effective load sharing.

Tunnel Scenario with ECMP/LAG

Limitations of Existing Solutions Existing solutions each have their applicable scenarios and limitations:

• IPv6 Flow Label Approach [RFC6438]: Requires IPv6 outer encapsulation and cooperation from the ingress tunnel endpoint (TEP) to set the flow label.
• MPLS Entropy Label Approach [RFC6790]: Only applicable to MPLS networks and requires all LSRs along the path to support entropy labels.
• Deep Packet Inspection (DPI): While some devices support inspecting inner packet fields for hashing, this increases processing complexity and latency, and is unavailable when packets are encrypted.

Motivation for Combined Hashing In practical network devices, a common implementation approach is to configure multiple parallel hash computation units, each independently configurable with its hash field set. However, final path selection typically can only use one of these hash values. The combined hash mechanism defined in this document allows combining multiple base hash values to produce a combined hash value that considers multi-layer information for final path selection.

Combined Hash Mechanism Overview

Basic Principle The core idea of the combined hash mechanism is to apply combination operations to multiple independently computed base hash values, producing a new combined hash value. Through this approach:

1. Each base hash value can be independently computed from different packet field sets (e.g., outer L3, inner L3, L2 fields).
2. The combination operation merges the entropy of multiple base hash values, producing a combined hash value containing more information.
3. Final path selection can be based on the combined hash value, thus indirectly achieving comprehensive consideration of multiple field sets.

Architecture

Combined Hash Mechanism Architecture H0 | | +-----------+ +--------------------+ | | |-->| Field Set |---->| Hash Function | | | | | A | +--------------------+ | | | +-----------+ | | | +--------------------+ | | Packet | +-----------+ | Hash Compute Unit 1|-----> H1 | |-->| Field Set |---->+--------------------+ | | | | B | | | | +-----------+ v | | +--------------------+ | | +-----------+ | Hash Compute Unit 2|-----> H2 --+ | |-->| Field Set |---->+--------------------+ | | | | C | | | | +-----------+ +--------------------+ | | | +-----------+ | Hash Compute Unit 3|-----> H3 --+ | |-->| Field Set |---->+--------------------+ | +--------+ | D | | +-----------+ v +---------------+ | Combination | | H_c = H2 ^ H3 | +---------------+ | v +---------------+ | Path Selection| | from {H0..H3, | | H_c} | +---------------+ | v Forwarding Path ]]>

Relationship with Existing Mechanisms This mechanism complements and . When the outer layer uses IPv6 and TEPs support RFC 6438, the flow label approach can be preferred. When MPLS networks are deployed with RFC 6790 support, the entropy label approach can be preferred. When the above conditions are not met, the combined hash mechanism provides a purely local implementation alternative. These approaches can be used together for optimal results.

Protocol Specification

Base Hash Computation Devices implementing this specification MUST support at least two independent base hash computation units. Each computation unit SHOULD support independent configuration of its hash field set. RECOMMENDED hash field set configuration options include: Hash Field Set Options

Field Set ID	Included Fields	Typical Use Case
L2	Source MAC, Dest MAC, VLAN, EtherType	Ethernet switching
L3	Source IP, Dest IP, Protocol	IP routing
L4	Source Port, Dest Port	Transport layer differentiation
OUTER	Outer packet L2/L3/L4 fields	Tunneled traffic
INNER	Inner packet L2/L3/L4 fields	Tunneled traffic

Base hash value bit-width SHOULD be at least 16 bits. Implementations MAY support larger bit-widths for better distribution characteristics.

Combination Operations Implementations MUST support XOR combination operation on two base hash values: where H_x and H_y are any two selected base hash values. Implementations MAY additionally support the following combination operations: Addition combination: where n is the hash value bit-width. Concatenation hash: where || denotes bit-level concatenation and Hash() is the configured hash function. When using XOR operation, implementations MUST detect whether H_x and H_y might be identical (computed from the same field set). If configured to XOR identical hash values, implementations SHOULD generate a warning, as this will result in a combined value of zero.

Path Selection Implementations MUST support selecting the final hash value for path selection from any base hash value (H0, H1, H2, H3, ...) or the combined hash value (H_combined). Final hash value selection SHOULD be configurable. For ECMP path selection, the hash-threshold algorithm described in or a similar deterministic algorithm SHOULD be used to ensure all packets of the same flow are forwarded to the same path.

Configuration Model This section defines parameters required for configuring the combined hash mechanism. Specific configuration interfaces (CLI, NETCONF/YANG, etc.) are outside the scope of this document.

Configuration Parameters Configuration Parameters

Parameter	Type	Range	Default
hash-unit-count	int	2-8	4
hash-unit[i].field-set	enum	L2,L3,L4,OUTER,INNER	-
combination.enabled	bool	true/false	false
combination.input-1	int	0 to (count-1)	-
combination.input-2	int	0 to (count-1)	-
combination.operation	enum	XOR,ADD,CONCAT-HASH	XOR
final-hash-select	int	0 to count	0

Configuration Constraints The following configuration constraints MUST be enforced:

1. combination.input-1 and combination.input-2 SHOULD NOT be configured to the same value. If configured to the same value, implementations MUST generate a warning.
2. When combination.enabled is false, the valid range for final-hash-select is 0 to (hash-unit-count - 1).
3. When combination.enabled is true, final-hash-select MAY additionally select the combined hash value.

Operational Procedures

Initialization Upon device startup, the following initialization procedure MUST be executed:

1. Read and validate configuration parameter validity.
2. Configure each hash computation unit with its corresponding field set.
3. If combined hashing is enabled, initialize the combination operation module.
4. Configure path selection logic to use the specified final hash value.

Packet Processing For each received packet, the processing procedure is as follows: Step 1: Base Hash Computation

• Each hash computation unit extracts configured fields from the packet in parallel.
• Execute hash function computation on extracted fields.
• Produce base hash values H0, H1, ..., Hn.

Step 2: Combined Hash Computation (if enabled)

• Select two base hash values according to configuration.
• Execute the configured combination operation.
• Produce combined hash value H_combined.

Step 3: Path Selection

• Select final hash value according to final-hash-select configuration.
• Execute path selection algorithm using final hash value (e.g., hash-threshold algorithm from ).
• Determine forwarding path and forward packet.

Configuration Change Handling When configuration changes occur:

• Implementations SHOULD support online configuration changes without device restart.
• Configuration changes MUST take effect immediately for subsequent packets.
• Implementations SHOULD log configuration change events for audit purposes.

Relationship with Existing Mechanisms

Relationship with RFC 6438 defines a method for using the flow label in IPv6 tunnel scenarios for ECMP/LAG load balancing. That method requires the ingress tunnel endpoint to set a flow label value in the outer IPv6 header based on information computed from the inner packet. The combined hash mechanism defined in this document complements : RFC 6438 executes at tunnel endpoints and affects all intermediate nodes along the tunnel path, while the combined hash mechanism executes locally at a single forwarding node and does not affect other nodes. When both mechanisms are used together, their effects can accumulate.

Relationship with RFC 6790 defines the MPLS entropy label mechanism, allowing entropy information for load balancing to be carried in the MPLS label stack. The mechanism defined in this document complements : RFC 6790 requires nodes along the path to support entropy label parsing, while the combined hash mechanism does not require support from other nodes. In MPLS networks, both mechanisms can be used simultaneously.

Relationship with RFC 2992 analyzes the hash-threshold algorithm for ECMP. The final hash value produced by the combined hash mechanism defined in this document can be used as input to the RFC 2992 algorithm. This document does not modify or replace the path selection algorithm defined in .

Security Considerations

Configuration Security The combined hash mechanism is a local device behavior and does not introduce new attack surfaces beyond those inherent in hash-based load balancing. However, operators should be aware that hash configuration details, if exposed, could allow traffic engineering attacks. Implementations MUST enforce access control for hash configuration parameters. Implementations SHOULD log configuration changes for audit purposes.

IANA Considerations This document does not require IANA to allocate any protocol parameters or create new registries. The combined hash mechanism is purely a local implementation optimization and does not involve protocol interactions. If future working group consensus determines that configuration parameter namespaces need to be standardized (e.g., for YANG models), IANA action may be requested at that time.

References Normative References Informative References IEEE

Deployment Scenario Examples

Data Center Overlay Networks In overlay networks such as VXLAN/NVGRE, large amounts of tenant traffic traverse shared underlay tunnels. Example configuration:

• Hash unit 0: OUTER field set (outer IP addresses)
• Hash unit 1: INNER field set (inner IP addresses)
• Combination operation: H0 XOR H1
• Final selection: Combined hash value

This configuration enables path selection to consider both outer tunnel information and inner tenant flow information.

Service Provider Core Networks In MPLS backbone networks, entropy labels may not be fully deployed. Example configuration:

• Hash unit 0: L3 field set (IP 5-tuple)
• Hash unit 1: MPLS label stack
• Combination operation: H0 XOR H1
• Final selection: Combined hash value

This configuration provides improved load distribution without relying on entropy labels.