rtgwg Q. Xiong Internet-Draft X. Zhu Intended status: Standards Track ZTE Corporation Expires: 25 December 2026 23 June 2026 SRv6-based Rate Notification draft-xz-rtgwg-srv6-rate-notification-00 Abstract This document specifies a rate notification mechanism for Segment Routing over IPv6 (SRv6) networks. It enables a transit or egress node to dynamically notify the ingress (headend) node about a recommended rate range (MinRate and MaxRate) when localized congestion is detected or when underutilized bandwidth is identified, allowing the headend to perform proactive traffic shaping and rate enforcement. This mechanism enhances transmission efficiency in SRv6 networks by enabling fine-grained, congestion-aware rate control. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Xiong & Zhu Expires 25 December 2026 [Page 1] Internet-Draft SRv6-based Rate Notification June 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. SRv6 Rate Notification Mechanism . . . . . . . . . . . . . . 3 3.1. Overview and Operation . . . . . . . . . . . . . . . . . 3 3.2. Notification Trigger and Rate Calculation . . . . . . . . 4 4. Message Formats {#message formats} . . . . . . . . . . . . . 5 4.1. ICMPv6 message format . . . . . . . . . . . . . . . . . . 5 4.2. UDP Packet Format . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. 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 [RFC8754]. 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. Xiong & Zhu Expires 25 December 2026 [Page 2] Internet-Draft SRv6-based Rate Notification June 2026 1.1. 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. 2. Conventions Used in This Document 2.1. Abbreviations CIR: Committed Information Rate PIR: Peak Information Rate SID: Segment Identifier SRv6: Segment Routing over IPv6 2.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. SRv6 Rate Notification Mechanism 3.1. Overview and Operation Xiong & Zhu Expires 25 December 2026 [Page 3] Internet-Draft SRv6-based Rate Notification June 2026 +----------+ +----------+ | Data | | Data | | center A | | center B | +----------+ +----------+ | Buffer Accumulation ^ | | | v v | +----+ +----+ +----+ +----+ +----+ | R1 | <--> | 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: 1. 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). 2. 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. 3. 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). 4. 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. 5. 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. 3.2. 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: Xiong & Zhu Expires 25 December 2026 [Page 4] Internet-Draft SRv6-based Rate Notification June 2026 * 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. 4. Message Formats {#message formats} The rate notification message can be encapsulated in either ICMPv6 [RFC4443] or UDP [RFC768] messages as described in the followings sections. 4.1. ICMPv6 message format A new ICMPv6 message format for the SRv6 rate notification is as following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD1 | Code | Checksum | +---------------+---------------+-------------------------------+ |R| Flags | Priority | Reserved | +---------------+---------------+-------------------------------+ | MinRate | +---------------------------------------------------------------+ | MaxRate | ----------------------------------------------------------------+ | Slice ID | +---------------------------------------------------------------+ Where: Xiong & Zhu Expires 25 December 2026 [Page 5] Internet-Draft SRv6-based Rate Notification June 2026 * 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. 4.2. UDP Packet Format A new UDP packet format for the SRv6 rate notification is as following: Xiong & Zhu Expires 25 December 2026 [Page 6] Internet-Draft SRv6-based Rate Notification June 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP source port | UDP destination port=TBD2 | +-------------------------------+-------------------------------+ | UDP length | UDP checksum | +---------------+---------------+-------------------------------+ | Flags | Priority | Reserved | +---------------+---------------+-------------------------------+ | MinRate | +---------------------------------------------------------------+ | MaxRate | ----------------------------------------------------------------+ | Slice ID | +---------------------------------------------------------------+ 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 [RFC768]. * Flags, Priority, Reserved, MinRate, MaxRate, Slice ID: Semantics identical to the fields defined in Section 4.1. 5. Security Considerations To be discussed in future versions of this document. 6. IANA Considerations This document requests IANA to allocate a new ICMP message type and UDP port. 7. References 7.1. Normative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . Xiong & Zhu Expires 25 December 2026 [Page 7] Internet-Draft SRv6-based Rate Notification June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . Authors' Addresses Quan Xiong ZTE Corporation Email: xiong.quan@zte.com.cn Xiangyang Zhu ZTE Corporation Email: zhu.xiangyang@zte.com.cn Xiong & Zhu Expires 25 December 2026 [Page 8]