srv6ops Y. Liu Internet-Draft China Mobile Intended status: Informational Q. Xiong Expires: 3 May 2027 X. Zhu ZTE Corporation 30 October 2026 SRv6-based Rate Control draft-lx-srv6ops-srv6-rate-control-00 Abstract This document describes a deployment model and operational considerations for rate control in Segment Routing over IPv6 (SRv6) network slices. It leverages a token-bucket scheduler to differentiate Committed Information Rate (CIR) and Peak Information Rate (PIR) traffic, and describes how a headend may enforce a rate profile on an SR Policy and adjust the PIR based on network conditions. It addresses the operational trade-off between resource utilization and congestion avoidance in over-committed slice deployments. 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 3 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Liu, et al. Expires 3 May 2027 [Page 1] Internet-Draft SRv6-based Rate Control October 2026 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 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. SRv6-based Rate Control . . . . . . . . . . . . . . . . . . . 3 3.1. Token-Bucket Scheduler for SRv6 Queuing Model . . . . . . 4 3.2. Rate Enforcement in SRv6 Networks . . . . . . . . . . . . 5 4. Operational Considerations . . . . . . . . . . . . . . . . . 5 4.1. Initial Rate Setting . . . . . . . . . . . . . . . . . . 5 4.2. Dynamic Rate Adjusting . . . . . . . . . . . . . . . . . 6 4.3. Rate Update Trigger . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction In Segment Routing over IPv6 (SRv6) networks, traffic engineering is primarily achieved by encoding explicit paths in the SRv6 Segment Identifier (SID) list, as specified in [RFC8754]. To meet Service Level Agreements (SLAs), slice resources are typically reserved for SRv6 SID according to user subscription requirements, ensuring the Committed Information Rate (CIR). The conventional approach involves allocating dedicated queues to each slice and enforcing bandwidth guarantees through token bucket mechanisms, often implemented using exclusive modes (e.g., via flex-channel) to provide isolated queue and bandwidth access, thereby protecting the CIR. However, strictly enforcing such SLA-based slice configurations can result in low resource utilization, particularly when reserved bandwidth for critical services remains underutilized, leading to idle network resources and increased operational costs. Therefore, in SRv6 network slice deployments, traffic is often over- committed. In addition to set the CIR, a Peak Information Rate (PIR) is also defined to specify the maximum bandwidth a slice is allowed to use, accommodating burst traffic and balancing resource utilization with network stability. In this scenario, queues and Liu, et al. Expires 3 May 2027 [Page 2] Internet-Draft SRv6-based Rate Control October 2026 bandwidth for slices operate in shared mode, allowing traffic assigned to a specific slice to exceed its reserved or committed resources (e.g., bandwidth, queues). If the PIR is set too low, bandwidth utilization remains suboptimal. Conversely, if the PIR is set too high, simultaneous bursts from multiple intelligent computing slices may cause total traffic to exceed physical link capacity. Without timely rate adjustments and throttling, this can trigger chain-reaction congestion across the network, failing to meet the latency and packet loss requirements essential for intelligent computing interconnectivity. To ensure the efficient transmission in SRv6 network slicing, this document proposes a rate control mechanism for SRv6-based networks. It is applicable to scenarios where traffic in SRv6 network slices is over-committed. By collecting congestion information and rate control parameters along the path, the method enables the dynamic rate control for traffic across the network. The dynamic rate adjustment are triggered by localized congestion or underutilization, enabling proactive rate control and efficient bandwidth sharing among slices sharing common physical links. This mechanism not only guarantees the committed rate of the slice but also improves overall link utilization while aiming to ensure high-throughput transmission. 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-based Rate Control Liu, et al. Expires 3 May 2027 [Page 3] Internet-Draft SRv6-based Rate Control October 2026 3.1. Token-Bucket Scheduler for SRv6 Queuing Model The following figure illustrates this two-priority queuing model for SRv6-based slices: Token Bucket Scheduler CIR+PIR +--------------------+ +----------------+ --------> | Queue 1 for Slice 1|---------->| High Priority +----+----------+ +--------------------+*** +----->+----------------+ | SP +-----> * | | Scheduler| CIR+PIR +--------------------+--*-+ +----------------+----+----------+ --------> |Queue 2 for Slice 2 | ********>| Low Priority | +--------------------+**********>+----------------+ --------> traffic <= CIR (High Priority) ********> CIR< traffic <= PIR (low Priority) Figure 1 Rate-based Queuing Scheuler for SRv6 Networks In the described model, when a network node processes SRv6 slice traffic, queues utilize a token bucket scheduler to manage the scheduling of multiple traffic classes. The scheduling strategy is as follows: * The token bucket scheduler assigns high-priority tokens to traffic up to the CIR and low-priority tokens to traffic between CIR and PIR. In operational deployments, high-priority (CIR) traffic is scheduled first so that the committed rate is served before burst (PIR) traffic. * Queue resources (bandwidth) is typically shared across slices. If the CIR tokens of a specific queue are not fully consumed, operators commonly allow that spare capacity to be used by PIR traffic from other slices after the scheduled traffic for the current slice is served. When aggregate link utilization gets high, operators lower the PIR of one or more slices to protect the link. * When CIR traffic in a queue requires scheduling, high-priority CIR traffic MUST be processed first. Low-priority PIR traffic is temporarily buffered. If PIR traffic buffering accumulates significantly (e.g., exceeds a high watermark), the headend is usually signaled to reduce the sending rate or shrink the PIR to prevent buffer overflow and packet loss. Liu, et al. Expires 3 May 2027 [Page 4] Internet-Draft SRv6-based Rate Control October 2026 3.2. Rate Enforcement in SRv6 Networks In the deployment model described in this document, rate enforcement is applied at the SR Policy headend. The headend steers traffic into an SR Policy according to a rate profile (CIR, PIR) bound to the policy, candidate path, or steering class (Color, Slice ID, NRP ID, etc.). Packets steered into the SR Policy are shaped or policed at the headend before being placed on the segment list. The rate profile may be: * statically configured, or * provisioned by a controller via BGP SR Policy, PCEP, NETCONF or YANG (e.g.,[I-D.xl-idr-bgp-sr-policy-pathrate] and [I-D.xl-pce-pcep-pathrate]), or * adjusted dynamically based on rate notification feedback (e.g., [I-D.xzl-fann-srv6-rate-notification]) or rate update along the forward path (e.g., [I-D.xz-6man-rate-option]). The headend classifies traffic against the rate profile as follows: * Within CIR: admitted as high priority. * Above CIR and within PIR: admitted as low priority, subject to scheduler availability. * Above PIR: dropped, buffered in a low-priority queue, or counted for congestion notification, per local policy. 4. Operational Considerations 4.1. Initial Rate Setting When establishing an SRv6 slice, an initial minimum rate (e.g.,CIR) and maximum rate (e.g.,PIR) are configured. The CIR is the committed, guaranteed rate per the service contract. The initial PIR can be calculated based on several factors to allow for efficient burst accommodation without causing congestion. An operational formula for calculating the initial PIR for a slice could be: Initial PIR = CIR + ((maxBufferSize / RTT) + maxLinkBw - sumCIR) * p. (1) Where: * CIR: The Committed Information Rate for the slice. Liu, et al. Expires 3 May 2027 [Page 5] Internet-Draft SRv6-based Rate Control October 2026 * maxBufferSize: The maximum buffer size allocated to the slice's queue at bottleneck nodes. * RTT: The round-trip time of the slice's SRv6 path. * maxLinkBw: The maximum available bandwidth of the bottleneck link shared by the slices. * sumCIR: The sum of the CIRs of all slices sharing the bottleneck path. * p: An allocation coefficient (0 <= p <= 1) for the specific slice, calculated based on empirical values related to its traffic characteristics (e.g., burstiness). The sum of 'p' for all slices on the path equals 1. 4.2. Dynamic Rate Adjusting A statically configured PIR is inefficient; it may not meet peak demand during busy periods or may waste bandwidth during idle times. Networks are dynamic, and in wide-area SRv6 networks where multiple slices share physical links, dynamic PIR adjustment is necessary. * When other slices experience bursts and consume extra resources, dynamically reducing the current slice's PIR can prevent the total link capacity from being exceeded, avoiding network-wide congestion. * When link resources are underutilized, dynamically increasing a slice's PIR allows its traffic to utilize the spare bandwidth, enhancing overall transmission efficiency and resource utilization. This dynamic adjustment enables coordinated resource allocation across the network, helping to prevent localized congestion from spreading. The PIR at a given node 'h' can be adjusted operationally based on the PIR from the previous hop and local conditions: PIR(h) = CIR + (PIR(h-1) - CIR) * a. (2) Where: * PIR(h): The maximum rate limit at the current node h. * PIR(h-1): The maximum rate limit at the previous hop (node h-1). Liu, et al. Expires 3 May 2027 [Page 6] Internet-Draft SRv6-based Rate Control October 2026 * a: An empirical allocation ratio coefficient (0 <= a <= 1) determined by the current node based on local state such as bandwidth utilization, traffic policy, and traffic priority. The end-to-end PIR for a flow traversing N nodes is the minimum PIR value encountered along the path: End-to-end PIR = Min{ PIR(h), h = 1, 2, ... N}. (3) Where: * N is the nodes' number along the path. 4.3. Rate Update Trigger In deployments that use rate notifications to trigger a PIR update (e.g., I-D.xzl-fann-srv6-rate-notification), a transit or egress node commonly generate a notification when one of the following conditions is met: * Impending Congestion: Conditions indicate impending congestion for a specific slice or queue. This could be: - Buffer occupancy exceeding a configured high watermark (e.g., 75% of queue depth) for a sustained period. - Sustained high queuing delay for a particular traffic priority. * Congestion Mitigation / Underutilization: Conditions indicate that congestion has subsided or bandwidth is underutilized. This could be: - Queue buffer occupancy is consistently low (e.g., below 50%) AND the link utilization for the traffic class is lower than a configured watermark (e.g., 75%) for a sustained period. Alternatively, an egress node may track the minimum PIR value discovered along the forward path (e.g., Destination Options and Hop- by-Hop option described in [I-D.xz-6man-rate-option]) and report it to the headend. 5. Security Considerations To be discussed in future versions of this document. Liu, et al. Expires 3 May 2027 [Page 7] Internet-Draft SRv6-based Rate Control October 2026 6. IANA Considerations This document does not currently require any IANA actions. 7. References 7.1. Normative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [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, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . 7.2. Informative References [I-D.xl-idr-bgp-sr-policy-pathrate] Xiong, Q. and J. Li, "BGP SR Policy for Path Rate", Work in Progress, Internet-Draft, draft-xl-idr-bgp-sr-policy- pathrate-00, 29 October 2026, . [I-D.xl-pce-pcep-pathrate] Xiong, Q. and J. Li, "PCEP Extension for Path Rate", Work in Progress, Internet-Draft, draft-xl-pce-pcep-pathrate- 00, 29 October 2026, . Liu, et al. Expires 3 May 2027 [Page 8] Internet-Draft SRv6-based Rate Control October 2026 [I-D.xz-6man-rate-option] Xiong, Q., Zhu, X., and J. Li, "IPv6 Rate Hop-by-Hop Option", Work in Progress, Internet-Draft, draft-xz-6man- rate-option-01, 2 July 2026, . [I-D.xzl-fann-srv6-rate-notification] Xiong, Q., Zhu, X., and J. Li, "SRv6-based Fast Rate Notification", Work in Progress, Internet-Draft, draft- xzl-fann-srv6-rate-notification-00, 29 October 2026, . [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 Yisong Liu China Mobile Email: liuyisong@chinamobile.com Quan Xiong ZTE Corporation Email: xiong.quan@zte.com.cn Xiangyang Zhu ZTE Corporation Email: zhu.xiangyang@zte.com.cn Liu, et al. Expires 3 May 2027 [Page 9]