SR-TE Path Based on Quality-Aware Dynamic Adaptive Adjustment

Introduction Segment Routing Traffic Engineering (SR-TE) allows for the steering of traffic through an ordered list of segments, defined as a Segment List within an SR-Policy . An SR-Policy may contain multiple Candidate Paths, each with its own priority. A single active Candidate Path can, in turn, contain multiple Segment Lists for load balancing, with each list assigned a static forwarding weight. Current implementations rely on these statically configured weights to distribute traffic among the Segment Lists. This static assignment is oblivious to real-time changes in the quality of the network paths each Segment List traverses, such as increased latency, packet loss, or link congestion. Consequently, traffic may continue to be pushed along a degraded path while better alternatives exist within the same Candidate Path. In AI-computing scenarios, large and small flows coexist for large-model training and inference. Large-model training depends on collective communication (AllReduce, AllGather, ReduceScatter): single flows sustain high throughput with long packets and heavy bulk parameter synchronization across GPUs—characterized by long duration, high bandwidth usage, and sensitivity to throughput. Inference requests and control (Ctl) signaling are small packets sensitive to initial and long-tail latency, with low per-flow bandwidth demand. Consequently, traffic composition (the ratio of large to small flows) changes dynamically; fixed weighting cannot match real-time traffic characteristics, preventing optimal global throughput. This document proposes a framework to address this limitation. It defines a Quality-Aware Dynamic Adaptive Adjustment system specifically for the Segment Lists within a single Candidate Path. The framework introduces mechanisms to monitor end-to-end path quality, dynamically recalculate Segment List weights based on real-time quality assessment, and apply the updated weights at the policy head-end. Additionally, it provides a mechanism to redirect traffic from congested segment lists to less congested ones for forwarding. This enables the SR-Policy to autonomously optimize traffic distribution in response to network dynamics, improving application performance and resource utilization while maintaining the existing SR-Policy structure and semantics.

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.

Problem Statement The current load-balancing model within a Candidate Path is static. Once weights are assigned to Segment Lists, the traffic distribution ratio remains constant unless manually reconfigured. This model suffers from two key issues:

Lack of Adaptivity: Network conditions are dynamic. A Segment List's path may experience temporary degradation (e.g., congestion, high latency). The head-end device, lacking a feedback mechanism, cannot reduce the traffic share sent over this degraded path, leading to suboptimal application performance.
Inefficient Resource Utilization: Even if some Segment Lists traverse paths with ample available bandwidth or superior quality, the fixed weights prevent traffic from being automatically shifted to better utilize these resources.

illustrates a classic scenario:

A Candidate Path with Three Segment Lists In , the active Candidate Path at the Head node contains three Segment Lists. Assuming equal static weights, traffic is evenly distributed. If the path for Segment List 1 (R11->R12->R13) experiences degradation (e.g., high loss on R12-R13), the Head continues to send one-third of the traffic onto this poor-quality path. Local rerouting by R12 does not solve the end-to-end problem and wastes capacity on the other two high-quality paths.

Solution

Quality-Aware Dynamic Weight Adjustment The proposed solution dynamically adjusts the operational forwarding weights of the Segment Lists within a Candidate Path based on their real-time, end-to-end path quality.

Core Mechanism The mechanism establishes a closed-loop control system:

Monitor: Network nodes measure quality metrics (e.g., delay, loss, utilization) for links associated with specific Segment Lists.
Report & Aggregate: These per-hop metrics are reported and aggregated to form a composite quality score for each Segment List's path.
Calculate: A decision entity (Controller or Head-end) employs a function F to compute a new set of operational forwarding weights based on the monitored quality scores of all Segment Lists. The core principle governing this calculation is that the weight for each path is directly proportional to its respective quality score.
Apply: The head-end applies the new weights, shifting traffic proportionally towards higher-quality Segment Lists.

An example of Quality-Aware Dynamic Weight Adjustment is shown in . when R12 detects degradation on the R12->R13 link, R12 sends the quality information to the Controller or Head via the control plane. The Head then dynamically adjusts the forwarding weights of each Segment List path based on the quality status, lowering the forwarding weight of the degraded Segment List path, thus reducing traffic on that path and relieving its load. When the degradation is cleared, R12 also sends the quality information to the Controller or Head via the control plane, and the Head restores the original forwarding weights of the Segment List path. The SR-Policy forwarding table for Quality-Aware Dynamic Weight Adjustment is shown in .

SR-Policy Forwarding Table for Quality-Aware Dynamic Weight Adjustment |Seglist 1: Weight w1|<----------------+ +------+ | +--------------------+ | | | +-------------------+ +--------+ | +--->|Path: R11->R12->R13|-->|Quality1| | +-------------------+ +--------+ | +---------------------+ +-->|Seglist 2: Weight w2|<----------------+ +---------------------+ | | +-------------------+ +--------+ +--->|Path: R21->R22->R23|-->|Quality2| +-------------------+ +--------+ ]]>

Key Properties

Scope-Limited: Operates only on the Segment Lists of the active Candidate Path. Does not change Candidate Path priority or Segment List composition.
Policy-Driven: The definition of "quality" (metrics, aggregation method) is configurable.
Dampened: Includes algorithms to prevent weight oscillation from transient quality fluctuations.

Quality-Aware Dynamic Flow Adjustment When congestion occurs and nearby devices detect congestion in a specific flow, they send the congestion information to the controller or Head via the control plane (CP). The Head then recalculates load balancing for the congested flow and selects a less-loaded Seglist path to forward the flow. The advantage of the flow redirection mode is that it can specifically adjust the congested flow, thereby quickly alleviating congestion. An example of the flow redirection mode is as follows: Example 1: As shown in Figure 3, when congestion of a specific flow S is detected on the R12->R13 link, R12 sends the congestion information of flow S to the controller (CTL) or Head via the control plane (CP). The Head subsequently selects a less-loaded Seglist path and redirects the forwarding of flow S.

SR-Policy Adaptive Flow table |Seglist 1: Load l1 | +------+ +--------------------+ | +-------------------+ +--->|Path: R11->R12->R13| +-------------------+ ]]>

Framework

Functional Roles A high-level view of the SR-TE Quality-Aware Dynamic Weight Routing framework, without expanding the functional entities in the network, is illustrated in . And the functional role of each functional entity also is shown in .

SR-TE Dynamic Adaptive Routing Framework Overview

Quality Monitor: Resides on Middle/End nodes. Measures local link-quality metrics and reports them for specific Segment Lists.
Candidate Path Quality Agent (CPQA): The logical entity responsible for a specific Candidate Path. Its functions (Collect, Aggregate, Calculate) can be centralized on a Controller or distributed on the Head.
Policy Head-End (Enforcer): When operating in Dynamic Weight Adjustment mode, the system installs and applies the updated weight set to its forwarding plane for the Candidate Path. When operating in Dynamic Flow Adjustment mode, it redirects congested flows from a congested segment list to a non-congested segment list for forwarding.

Operational Modes

Centralized Mode: The Controller acts as the CPQA. It collects all reports, calculates new weights, and pushes them to the Head.
Distributed Mode: The Head node acts as the CPQA for its local Candidate Paths. It receives direct quality reports from monitors and performs calculation locally.

Workflow

Centralized Mode Workflow

Subscription & Baseline: The Controller subscribes to quality metrics for all links constituting the Segment Lists of a Candidate Path. The Head reports the initial Segment List-weight binding.
Continuous Monitoring & Reporting: Middle and End nodes (Monitors) measure metrics and stream reports to the Controller.
Aggregation & Decision: The Controller aggregates reports into per-Segment-List quality scores. Upon significant quality change, it triggers the weight calculation function.
Update Enforcement: When operating in Dynamic Weight Adjustment mode, the Controller sends the new weight tuple for the Segment Lists to the Head via a southbound interface (e.g., PCEP). The Head updates its forwarding entries. When operating in Dynamic Flow Adjustment mode, the Controller redirects congested flows from a congested segment list to a non-congested segment list for forwarding.

Distributed Mode Workflow

Path Quality Association: The Head, for its Candidate Path, instructs relevant nodes (e.g., End nodes of each Segment List) to act as Quality Monitors and report back.
Direct Reporting: Monitors send quality reports directly to the Head (e.g., via extended IGP/BGP-LS, in-band telemetry).
Local Calculation & Update: When operating in Dynamic Weight Adjustment mode, the Head aggregates the data, calculates new weights, and immediately applies them to its local forwarding table for that Candidate Path. When operating in Dynamic Flow Adjustment mode, the Head extracts the first N congested flows and their sizes from the congested segment list, then selects a non-congested segment list and redirects part of the traffic to the non-congested segment list for forwarding.

Security Considerations The framework introduces some key information flows (quality reports, weight updates) that MUST be secured. All messages between Monitors, CPQA (Controller/Head), and Enforcer MUST be authenticated to prevent forgery. Protocols like TLS or TCP-AO SHOULD be used. Quality reports MAY reveal network internal state. Encryption SHOULD be considered where privacy is a concern. The system SHOULD be resilient against malicious nodes flooding false quality reports to trigger unnecessary re-calculations or traffic shifts (Denial-of-Service). Rate-limiting and validation of report sources are recommended.

IANA Considerations This document makes no requests for IANA action. Future documents specifying protocol extensions MAY require the creation of new code points or registries.