SRv6-based Rate Notification
draft-xz-rtgwg-srv6-rate-notification-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Quan Xiong , Xiangyang Zhu | ||
| Last updated | 2026-06-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xz-rtgwg-srv6-rate-notification-00
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,
<https://www.rfc-editor.org/rfc/rfc768>.
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,
<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>.
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,
<https://www.rfc-editor.org/rfc/rfc8754>.
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]