A RoCEv2 Flow-Level Load Balancing Method Based on the IPv6 Flow Label

Abstract

This document proposes a method for achieving flow-level load balancing in RoCEv2 (RDMA over Converged Ethernet version 2) networks. Traditional per-flow load balancing based on the 5-tuple cannot distinguish between different RDMA sessions that share the same 5-tuple. This causes "elephant flows" to be hashed to the same path, leading to network congestion. This method resolves this issue by having the ingress network device (e.g., a top-of-rack switch or router) parse the QP (Queue Pair) information from the IB BTH (Base Transport Header) and IB DETH (Datagram Extended Transport Header) headers of the RoCEv2 packet. By combining this with portions of the IPv6 source and destination addresses as an entropy source, a CRC32 hash algorithm generates a 20-bit value, which is then written into the Flow Label field of the IPv6 header. Network devices can subsequently use the updated "5-tuple + Flow Label" for more granular flow-level load balancing, thereby effectively improving transmission efficiency in high-performance networks such as AI computing.¶

1. Introduction

The rapid advancement of Artificial Intelligence (AI) and High-Performance Computing (HPC) has driven the widespread adoption of Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCEv2) in data center and intelligent computing networks. RoCEv2 enables high-throughput, low-latency data transfers that are critical for distributed training and storage workloads. However, the effective operation of these networks is challenged by the inherent characteristics of RDMA traffic, particularly the "elephant flow" problem.¶

Traditional load balancing mechanisms in IP networks typically rely on a 5-tuple (source/destination IP address, source/destination port, and protocol number) to identify and distribute traffic flows. In RoCEv2 networks, a significant limitation arises: multiple distinct RDMA sessions or flows generated by the same upper-layer application may share an identical 5-tuple. This is because the RDMA Queue Pair (QP) information, which uniquely identifies a session, is encapsulated within the InfiniBand Base Transport Header (IB BTH) and Datagram Extended Transport Header (IB DETH) of the RoCEv2 packet. Consequently, conventional 5-tuple-based hashing treats these distinct RDMA flows as a single entity and forwards them to the same network path, leading to severe congestion, packet loss, and a significant degradation in overall network throughput and performance.¶

To address this problem, this document introduces a novel method for flow-level load balancing that leverages a standard IPv6 extension mechanism. The core idea is to enable an ingress network device (e.g., a top-of-rack switch or router at the edge of the network) to extract the QP pair information (source QP and destination QP) from the RoCEv2 packets. This extracted QP pair information is then used as input to a CRC32-based hash function to generate a unique per-flow identifier. This identifier is subsequently mapped into the Flow Label field of the IPv6 header. The sending host is not required to set the Flow Label; it may send packets with the Flow Label set to zero, as permitted by [RFC6437].¶

By combining the traditional 5-tuple with this dynamically generated Flow Label, the proposed method creates a fine-grained "5-tuple + Flow Label" flow identification key. This allows network devices to effectively distinguish between different RDMA sessions that were previously indistinguishable, thereby achieving true flow-level load balancing. This approach minimizes path collisions, reduces congestion, and enhances the utilization of multi-path network topologies within RoCEv2 environments.¶

This document outlines the concept, details the packet processing method, and describes the mapping of the QP pair to the IPv6 Flow Label field. The subsequent sections will cover the mechanism in detail, discuss its advantages over existing solutions, and present use cases for its implementation in intelligent computing and data center networks.¶

2. Conventions Used in This Document

3. Relation to Existing Standards and the Need for QP-based Entropy

This method extends the principles established in [RFC6437] and [RFC6438] for using the IPv6 Flow Label. [RFC6437] recommends source hosts set the Flow Label using a PRNG to provide entropy for load balancing. [RFC6438] further specifies that this Flow Label can be used by intermediate routers for ECMP hashing.¶

[RFC7098] describes using the IPv6 Flow Label for layer 3/4 load balancing in large server farms, suggesting that {source address, flow label} can serve as a session key when the Flow Label is non-zero. The present document complements [RFC7098] in two key aspects: 1. [RFC7098] targets general HTTP/TCP traffic where the 5-tuple is sufficient to distinguish sessions, whereas this document addresses RoCEv2 networks where multiple RDMA flows share an identical 5-tuple; 2. [RFC7098] assumes the source host sets the Flow Label per [RFC6437], while this document specifies that the ingress network device writes the Flow Label based on QP information from the RoCEv2 payload, with the host setting it to zero as a signal for relabeling.¶

However, the above existing standards [RFC6437][RFC6438][RFC7098] all rely on a fundamental assumption: that different transport layer flows are distinguishable by their 5-tuple (Source/Dest IP, Source/Dest Port, Protocol). In a RoCEv2 network, this assumption breaks down. A single host process (e.g., a GPU communicator library) often creates multiple parallel RDMA sessions, all of which share the same source and destination IPs (typically the host interface IPs) and port numbers (the standard UDP port for RoCEv2). Therefore, the 5-tuple is identical for all these concurrent flows.¶

In this scenario, a standard PRNG, which has no knowledge of the internal RDMA session structure, would assign the same Flow Label to all packets, or a random value that cannot be correlated with the actual sessions. This would not solve the "elephant flow" problem.¶

To overcome this, the proposed method extracts the actual source of session differentiation: the Queue Pair (QP) number. The QP number is the unique identifier for an RDMA connection and is present within the IB BTH header of the RoCEv2 packet. By hashing this information, the Flow Label becomes a direct function of the session itself, not just the network 5-tuple.¶

Moreover, To ensure compatibility with the expectations of [RFC6437], particularly Section 2, the following operational rule is established for this scheme:¶

1. As specified in [RFC6437], a Flow Label of zero is used to indicate packets that have not been explicitly labeled. Hosts participating in this scheme SHOULD either set the Flow Label to zero or not set it at all (which results in a default value of zero). This zero value serves as a signal to the network that the packet is eligible for relabeling by the ingress network device.¶

2. If the arriving packet already carries a non-zero Flow Label value (e.g., set by the sending host or by another upstream device), the ingress network device MUST NOT overwrite it. This rule aligns with the core principle of [RFC6437] that "once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s)."¶

4. Flow-Level Load Balancing Based on the IPv6 Flow Label

+---------+---------+---------+---------+---------+---------+---------+
| Version | Traffic Class     |          Flow Label (20 bits)         |
+---------+---------+---------+---------+---------+---------+---------+
|         Payload Length      |     Next Header   |     Hop Limit     |
+---------+---------+---------+---------+---------+---------+---------+
|                                                                     |
+                       IPv6 Source Address                           +
|                                                                     |
+---------+---------+---------+---------+---------+---------+---------+
|                                                                     |
+                       IPv6 Destination Address                      +
|                                                                     |
+---------+---------+---------+---------+---------+---------+---------+
|   ...   |      UDP Header   |   ...   | IB BTH  |   ...   | IB DETH |
+---------+---------+---------+---------+---------+---------+---------+

7. References