SRv6-based Rate Notification

Introduction In Segment Routing over IPv6 (SRv6) networks, traffic engineering is primarily achieved through the explicit path encoded in the SRv6 Segment Identifier (SID) list as per . However, dynamic network conditions, such as transient congestion on a specific link or node, can degrade the Quality of Service (QoS) for engineered flows. Static provisioning of rate limits (e.g., Committed and Peak Information Rates - CIR/PIR) at the ingress may be insufficient to respond to such localized, real-time events. This document defines an SRv6 Rate Notification mechanism. It allows a transit or egress node experiencing or anticipating congestion, or conversely, detecting underutilized bandwidth, to compute an appropriate rate range and send a notification back to the ingress (headend) node. The headend can then adapt its traffic shaping policy and perform rate enforcement accordingly, providing dynamic, network-assisted rate control and congestion mitigation.

Motivation Existing QoS and congestion control mechanisms often operate at the device level or rely on end-to-end transport-layer feedback, which may be too slow or coarse-grained for fine-tuning SRv6 flows within a network domain. A network-based notification mechanism offers the following advantages:

Proactive Congestion Mitigation: Allows the headend to proactively throttle traffic before severe congestion causes packet loss or excessive queueing delay, improving flow completion times.
Improve Bandwidth Utilization: Enables flows to safely increase their rate when underutilized bandwidth is detected along the path, improving overall network efficiency.
Flow-Aware Control: Notifications can be associated with specific SRv6 policies, network slices, or queues, enabling precise control that aligns with the intended traffic engineering objectives.
Simplified Operation: Leverages the existing SRv6 architecture for in-band notification, avoiding dependency on complex out-of-band control protocols.

Conventions Used in This Document

Abbreviations CIR: Committed Information Rate PIR: Peak Information Rate SID: Segment Identifier SRv6: Segment Routing over IPv6

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.

SRv6 Rate Notification Mechanism

Overview and Operation | R2 | <--> | R3 | <--> | R4 | <--> | R5 | +----+ +----+ +----+ +----+ +----+ Rate ^ | Enforcement| | +-------------------------------------+ Rate Notification Figure 1: Rate Notification in SRv6 Network ]]> As shown in Figure 1, two data centers, A and B, connected via an SRv6 path defined as R1 -> R2 -> R3 -> R4 -> R5, as shown in Figure 1. The process follows these steps:

The headend node (R1) forwards traffic for a specific flow or slice along a predetermined SRv6 path (e.g., R1->R2->R3->R4->R5), applying initial rate shaping (e.g., based on CIR/PIR).
Transit nodes (R2, R3, R4) forward data according to the SID list, with each node checking its local SID table for forwarding and slice-related information.
A transit node (e.g., R4) monitors its queues for that slice. Upon detecting a congestion condition (see Section 3.2), it calculates a new recommended rate range (MinRate, MaxRate).
Node R4 generates a Rate Notification message containing the calculated MinRate, MaxRate, a Slice/Flow identifier (Slice ID), and a queue Priority identifier. It sends this message (e.g.,ICMPv6 or UDP) towards the headend node R1.
Upon receiving and validating the notification, R1 may apply the new rate range and perform the rate enforcement, thereby alleviating the incipient congestion at R4.

Notification Trigger and Rate Calculation A transit node SHOULD generate a Rate-Down Notification when conditions indicative of impending congestion are met for a specific slice or queue, suggesting the rate should be lowered. Example trigger conditions include:

Buffer accumulation exceeding a configured high watermark (e.g., 80% of queue depth) for a sustained period.
Sustained high queueing delay for a particular traffic priority.

A node (transit or egress) SHOULD generate a Rate-Up Notification when conditions indicate that bandwidth is underutilized along the SRv6 path, suggesting the rate could be safely increased. Example trigger conditions include:

Queue buffer is not occupied and the link utilization for the traffic class is lower than a configured watermark (e.g., 80%) for a sustained period.

The method for calculating the MinRate and MaxRate values is implementation-specific. For Rate-Down notifications, MaxRate might be derived from the available buffer and queue depth. For Rate-Up notifications, MaxRate might be increased based on the detected spare capacity. MinRate could be set to guarantee a minimum service rate or derived from the original CIR. The notification is advisory; the final decision to enforce resides at the headend node.

Message Formats {#message formats} The rate notification message can be encapsulated in either ICMPv6 or UDP messages as described in the followings sections.

ICMPv6 message format A new ICMPv6 message format for the SRv6 rate notification is as following: Where:

Type and Code: TBD1, 16bits, indicate the rate notification type and its sub-type.
Checksum: 16bits, it is used for error-checking the packet.
R (Rate Control Flag): 1 bit, it set to 0 indicates a Rate-Down notification, 1 indicates a Rate-Up notification. Other bits in the Flags octet are for future use.
Priority: 8bits, the queue priority identifier. It identifies the queue or traffic class priority within the slice. Enables head node to map the notification to a specific queue.
MinRate: 32bits, the recommended minimum data rate in bits per second (bps) for the head node to shape the flows within the slice or queue, typically corresponding to the CIR of the slice to guarantee minimum service rate. The headend node should ensure traffic shaping is not below this rate.
MaxRate: 32bits, the recommended maximal rate in bps for the head node to shape the flows within the slice or queue, typically corresponding to the PIR of the slice. The headend node should dynamically adjust this rate based on network conditions.
Slice ID: 32bits, the slice identifier for the network slice or flows to which this rate adjustment applies. It could map to an SRv6 SID or a local policy identifier known to both head and transit nodes.

UDP Packet Format A new UDP packet format for the SRv6 rate notification is as following: Where:

Source Port: (16 bits) UDP source port of the notification sender.
Destination Port: (16 bits) TBD2 (To Be Assigned by IANA). A new well-known port for SRv6 Rate Notification.
UDP Length & Checksum: As defined in .
Flags, Priority, Reserved, MinRate, MaxRate, Slice ID: Semantics identical to the fields defined in Section 4.1.

Security Considerations To be discussed in future versions of this document.

IANA Considerations This document requests IANA to allocate a new ICMP message type and UDP port.