SRv6-based Rate Control
draft-lx-spring-srv6-rate-control-00

spring                                                            Y. Liu
Internet-Draft                                              China Mobile
Intended status: Standards Track                                Q. Xiong
Expires: 4 January 2027                                           X. Zhu
                                                         ZTE Corporation
                                                             3 July 2026

                        SRv6-based Rate Control
                  draft-lx-spring-srv6-rate-control-00

Abstract

   This document describes a rate control mechanism for Segment Routing
   over IPv6 (SRv6) network slices.  It addresses the challenge of
   balancing resource utilization and congestion avoidance in over-
   committed slice deployments.  The mechanism leverages a token-based
   scheduler to differentiate between Committed Information Rate (CIR)
   and Peak Information Rate (PIR) traffic, and defines procedures for
   calculating initial PIR values and dynamically adjusting them based
   on network conditions.
   Dynamic rate adjustments are triggered by localized congestion or
   underutilization, enabling proactive rate control and efficient
   bandwidth sharing among slices sharing common physical links.

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 4 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Liu, et al.              Expires 4 January 2027                 [Page 1]
Internet-Draft           SRv6-based Rate Control               July 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
   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-Based Queue Scheduling  . . . . . . . . . . . . . .   4
     3.2.  Initial Rate Setting  . . . . . . . . . . . . . . . . . .   5
     3.3.  Dynamic Rate Adjusting  . . . . . . . . . . . . . . . . .   5
     3.4.  Rate Update Trigger . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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

Liu, et al.              Expires 4 January 2027                 [Page 2]
Internet-Draft           SRv6-based Rate Control               July 2026

   utilization with network stability.  In this scenario, queues and
   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 4 January 2027                 [Page 3]
Internet-Draft           SRv6-based Rate Control               July 2026

3.1.  Token-Based Queue Scheduling

   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 exceeding the CIR
      (up to the PIR).  The scheduler MUST prioritize servicing high-
      priority tokens to guarantee the CIR before processing low-
      priority tokens.

   *  Queue resources (bandwidth) can be shared.  If CIR tokens for a
      specific queue are not fully consumed, the unused capacity MAY be
      utilized by low-priority traffic (PIR traffic) from other slices
      after the scheduled traffic for the current slice is served.
      However, if overall network bandwidth utilization becomes
      excessively high, the PIR value for one or more slices MAY be
      adjusted downward.

   *  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), upstream or
      headend nodes SHOULD be promptly notified to reduce the sending
      rate or adjust the PIR to prevent buffer overflow and packet loss.

Liu, et al.              Expires 4 January 2027                 [Page 4]
Internet-Draft           SRv6-based Rate Control               July 2026

3.2.  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.  A typical 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.

   *  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.

3.3.  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.

Liu, et al.              Expires 4 January 2027                 [Page 5]
Internet-Draft           SRv6-based Rate Control               July 2026

   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 iteratively
   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).

   *  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.

3.4.  Rate Update Trigger

   A transit or egress node SHOULD generate a rate notification to
   trigger a PIR update (e.g., using a mechanism as described in
   [I-D.xz-rtgwg-srv6-rate-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.

Liu, et al.              Expires 4 January 2027                 [Page 6]
Internet-Draft           SRv6-based Rate Control               July 2026

   Alternatively, an egress node MAY track the minimum PIR value
   discovered along the forward path (e.g., using a mechanism such as
   Destination Options and Hop-by-Hop option described in
   [I-D.xz-6man-rate-option]) and use this value to update or inform the
   source about the effective bottleneck PIR.

4.  Security Considerations

   To be discussed in future versions of this document.

5.  IANA Considerations

   This document does not currently require any IANA actions.

6.  References

6.1.  Normative References

   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/rfc/rfc768>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc4443>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2.  Informative References

   [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,
              <https://datatracker.ietf.org/doc/html/draft-xz-6man-rate-
              option-01>.

Liu, et al.              Expires 4 January 2027                 [Page 7]
Internet-Draft           SRv6-based Rate Control               July 2026

   [I-D.xz-rtgwg-srv6-rate-notification]
              Xiong, Q., Zhu, X., and J. Li, "SRv6-based Rate
              Notification", Work in Progress, Internet-Draft, draft-xz-
              rtgwg-srv6-rate-notification-01, 2 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-xz-rtgwg-
              srv6-rate-notification-01>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8754>.

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 4 January 2027                 [Page 8]