Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS)

Introduction Computing-Aware Traffic Steering (CATS) directs traffic between service clients and providers based on real-time computing and network status. While CATS operates as an overlay system for selecting optimal service instances, the framework does not assume specific data plane or control plane solutions. This document defines a flow-level load balancing mechanism addressing two operational challenges: control plane scalability limitations caused by reactive path computation, and resource utilization imbalances resulting from coarse-grained status reporting. The mechanism enables the control plane to pre-compute multiple viable forwarding alternatives while allowing the data plane to autonomously distribute traffic across these alternatives using flow-based affinity.

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 document makes use of the terms defined in .

CATS Routing Table: Control plane structure containing service identifiers, network paths, service instances, and load sharing weights.
CATS Forwarding Table: Data plane structure derived from CATS Routing Table via UCMP-to-ECMP expansion.
Flow Affinity Table: Data plane table maintaining flow-to-forwarding-entry bindings.

Problem Statement Current CATS implementations rely on periodic or threshold-triggered resource status reports to optimize service instance and path selection. This approach creates uneven computing resource utilization when status updates lag behind actual load changes, potentially directing multiple requests to already overloaded instances. Additionally, frequent metric fluctuations trigger repeated control plane path recalculation and policy updates, creating scalability constraints that incremental calculation alone cannot resolve.

Architectural Model The Flow-Level Load Balancing of Computing-Aware Traffic Steering is constructed based on the framework established in the CATS architecture (Figure 1 for a visual representation).

CATS-Functional-Components The mechanism operates through three functional entities: the Path Selector (C-PS) situated in the control plane collecting metrics via Metric Agents (C-SMA and C-NMA) and computing forwarding alternatives; the Forwarder operating in the data plane performing flow identification, affinity maintenance and packet forwarding; and the Metric Agents reporting service instance and network status to enable path computation. The Path Selector maintains the CATS Routing Table containing for each CS-ID a set of Forwarding Alternatives comprising network path identifiers, service instance identifiers, and load sharing weights representing desired traffic distribution proportions. The Forwarder generates the CATS Forwarding Table through UCMP-to-ECMP expansion, creating a uniform lookup structure where each Forwarding Alternative appears in proportion to its weight, and maintains the Flow Affinity Table binding flow identifiers to specific forwarding entries.

Control plane Operation The Path Selector identifies for each CS-ID the Service Instance Set containing all Forwarding Alternatives satisfying SLA requirements, computing load sharing weights based on service instance metrics, network path characteristics and policy objectives. The resulting CATS Routing Table is translated into a CATS Forwarding Table and distributed to Forwarders.. Figure 2 shows an example of a representation of multi-next-hop CATS routing table designed for a specific CS-ID1.

An example of CATS routing table Figure 3 shows an example of the CATS forwarding table following the changes.

An example of CATS forwarding table To minimize control plane load, the Path Selector regenerates the CATS Routing Table only when metric changes cross predefined thresholds rather than reacting to every fluctuation, optionally employing hysteresis mechanisms to prevent rapid oscillation between configurations.

Data Plane Operation Upon receiving a packet the Forwarder extracts the CS-ID and computes the flow identifier, typically derived from the five-tuple. The Forwarder queries the Flow Affinity Table and if an existing binding is found forwards the packet using the bound entry. For unbound flows the Forwarder computes a hash over the flow identifier, selects the CATS Forwarding Table entry at the resulting index, creates a Flow Affinity Entry binding the flow to this entry, and forwards the packet. The CATS Forwarding Table remains stable during flow affinity establishment ensuring consistent forwarding for all packets of a flow. Table updates received from the Path Selector apply only to new flows while existing bindings remain valid until flow termination or timeout.

Security Considerations The mechanism introduces potential denial of service vulnerabilities through Flow Affinity Table exhaustion if an attacker generates excessive new flows, mitigated by implementing binding creation rate limits. Predictable flow identifiers could enable binding hijacking requiring cryptographically robust hash functions. CATS Forwarding Tables distributed from Path Selector to Forwarder may expose topology information warranting protection during transmission.

Acknowledgements To be added upon contributions, comments and suggestions.

IANA Considerations TBA