Congestion Notification for Pause
draft-xiao-rtgwg-congestion-notification-for-pause-01
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 | Xiao Min , Kan Zhang | ||
| Last updated | 2026-02-27 | ||
| 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-xiao-rtgwg-congestion-notification-for-pause-01
RTGWG Working Group X. Min
Internet-Draft ZTE Corp.
Intended status: Standards Track K. Zhang
Expires: 31 August 2026 China Mobile
27 February 2026
Congestion Notification for Pause
draft-xiao-rtgwg-congestion-notification-for-pause-01
Abstract
This document describes the necessity and feasibility to introduce a
mechanism of congestion notification for pause. After receiving the
L2 pause frames from the destination data center gateway, the egress
provider edge node sends the congestion notifications to the upstream
provider nodes and the ingress provider edge node in a format defined
in this document. The upstream provider nodes and the ingress
provider edge node must pause the forwarding of IP flows identified
by the congestion notifications. And then the ingress provider edge
node may send the L2 pause frames to the source data center gateway.
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 31 August 2026.
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.
Please review these documents carefully, as they describe your rights
Min & Zhang Expires 31 August 2026 [Page 1]
Internet-Draft Congestion Notification for Pause February 2026
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. Congestion Notification Mechanisms . . . . . . . . . . . . . 3
4. Congestion Notification for Pause Packet Format . . . . . . . 5
5. Advertising IP Pause Capability Using IGP . . . . . . . . . . 6
5.1. Advertising IP Pause Capability Using IS-IS . . . . . . . 6
5.2. Advertising IP Pause Capability Using OSPF . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. A well-known UDP Port . . . . . . . . . . . . . . . . . . 9
7.2. IS-IS IP Pause Capability Sub-TLV . . . . . . . . . . . . 10
7.3. IS-IS Sub-Sub-TLVs for the IP Pause Capability Sub-TLV
Registry . . . . . . . . . . . . . . . . . . . . . . . . 10
7.4. OSPF IP Pause Capability TLV . . . . . . . . . . . . . . 11
7.5. OSPF IP Pause Parameter Sub-TLVs Registry . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
IP based VPN [RFC2764] is often used to interconnect Data Center
Networks (DCN), in which case the IP based VPN is also referred to as
IP WAN. In the DCN, Priority-based Flow Control (PFC)
[IEEE8021Q-2022] is a widely deployed mechanism for congestion
control. However, the PFC as an L2 pause mechanism is not suitable
to be deployed in IP WAN, so an L3 pause mechanism is needed for use
in IP WAN.
This document describes the necessity and feasibility to introduce a
mechanism of congestion notification for pause. Specifically, the
problem statement is described in Sections 1 and 3, and the format of
the congestion notification message sent from the Provider Edge (PE)
node to the Provider (P) and/or PE node is defined in Section 4, and
the solution on how the PE node knows the addresses of the destined P
and/or PE node is defined in Section 4 and 5.
Min & Zhang Expires 31 August 2026 [Page 2]
Internet-Draft Congestion Notification for Pause February 2026
2. Conventions Used in This Document
2.1. Abbreviations
CE: Customer Edge
DC: Data Center
DCN: Data Center Networks
DoS: Denial-of-Service
IPC: IP Pause Capability
LSA: Link State Advertisement
P: Provider
PE: Provider Edge
PFC: Priority-based Flow Control
RI: Router Information
SRH: Segment Routing Header
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. Congestion Notification Mechanisms
As a congestion notification for pause mechanism used in DCN, the PFC
is referred to as classical stepwise back pressure with dedicated
Ethernet pause frame, as shown in Figure 1.
Min & Zhang Expires 31 August 2026 [Page 3]
Internet-Draft Congestion Notification for Pause February 2026
PFC Frame PFC Frame PFC Frame
|<------------+|<-----------+|<------------+
| || || |
+--------+ +-------+ +-------+ +-------+ +--------+
|Traffic |====>|Network|====>|Network|====>|Network|====>|Traffic |
|Sender | |Node 1 | |Node 2 | |Node 3 | |Receiver|
+--------+ +-------+ +-------+ +-------+ +--------+
Congestion
Point
Figure 1: Classical Stepwise Back Pressure with Dedicated
Ethernet Pause Frame within DC
With this congestion notification mechanism, the congested network
node (Netwok Node 3 in Figure 1) asks the directly connected upstream
network node (Network Node 2 in Figure 1) to pause the data traffic
by a dedicated Ethernet pause frame called PFC frame, and then the
upstream network node may stepwise ask its directly connected
upstream network node to pause the data traffic by a PFC frame, until
the most upstream network node (Network Node 1 in Figure 1) may ask
the directly connected traffic sender to pause the data traffic by a
PFC frame. [IEEE8021Q-2022] details how this kind of congestion
notification mechanism works.
In the IP WAN for DC interconnect, the congestion notification
mechanism triggered by the PFC frames from the destination DC gateway
is referred to as back pressure with dedicated IP pause packet, as
shown in Figure 2.
Congestion Notification
|<--------------------------+
| Congestion Notification |
PFC Frame | |<-----------+| PFC Frame
|<-----------+| | |||<-----------+
| || | ||| |
+--------+ +-------+ +-------+ +-------+ +--------+
|DC1 |====>| PE1 |====>| P1 |====>| PE2 |====>|DC2 |
|Gateway | | | | | | | |Gateway |
+--------+ +-------+ +-------+ +-------+ +--------+
Congestion
Point
Figure 2: Back Pressure with Dedicated IP Pause Packet within WAN
With this congestion notification mechanism, while detecting
congestion the congested egress Customer Edge (CE) node (DC2 gateway
in Figure 2) asks the directly connected upstream egress PE node (PE2
Min & Zhang Expires 31 August 2026 [Page 4]
Internet-Draft Congestion Notification for Pause February 2026
in Figure 2) to pause the data traffic by sending PFC frames, and in
response to receiving the PFC frames from DC2 which is in congestion,
the egress PE generates IP flow pause packets corresponding to the IP
flows which cause the congestion in DC2, and then the egress PE asks
the upstream P node (P1 in Figure 2) and/or the upstream ingress PE
node (PE1 in Figure 2) to pause (buffer) the data traffic of IP flows
by sending the IP flow pause packets, until the ingress PE node may
ask the directly connected upstream ingress CE node (DC1 gateway in
Figure 2) to pause the data traffic by sending PFC pause frames.
Note that the upstream P node and/or the upstream ingress PE node
receiving the IP flow pause packets must be on the forwarding path of
the IP flows and must have the buffering capability for the IP flows
causing congestion. This document details how this kind of
congestion notification mechanism works.
4. Congestion Notification for Pause Packet Format
Once receiving the L2 pause frames from the destination DC gateway,
the egress PE node needs to determine which IP flows cause the
congestion. How the egress PE node figure out the IP flows causing
congestion is implementation specific and outside the scope of this
document. For each IP flow causing congestion, the egress PE node
needs to identify the ingress PE node and the P nodes traversed by
the IP flow and send congestion notification for pause message to
each identified P/PE node. With respect to different WAN
technologies, there are different ways for the egress PE node to
identify the on-path PE and P nodes. When Segment Routing over IPv6
(SRv6) [RFC8754] is deployed in the WAN, the egress PE node can use
Segment Routing Header (SRH) to identify the on-path PE and P nodes;
When native IPv6 is deployed in the WAN, the egress PE node can only
use the source IP address to identify the ingress PE node.
The congestion notification for pause message sent from the egress PE
node to the identified on-path PE and P nodes can be a UDP message or
an ICMP message, if a UDP message it's formatted as follows:
Min & Zhang Expires 31 August 2026 [Page 5]
Internet-Draft Congestion Notification for Pause February 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 = TBD1 |
+-------------------------------+-------------------------------+
| UDP Length | UDP Checksum |
+-------------------------------+-------------------------------+
| |
~ IP Flow Identifier + Pause Time ~
| |
+---------------------------------------------------------------+
| As much of the invoking packet as possible |
+ without the UDP packet exceeding 576 bytes +
| in IPv4 or 1280 bytes in IPv6 |
Figure 3: Congestion Notification for Pause Message Format
UDP Header: The UDP header as specified in [RFC768] includes the UDP
source port, UDP destination port, UDP length, and UDP checksum. A
well-known UDP destination port (TBD1) needs to be allocated for this
Congestion Notification Message.
IP Flow Identifier: When SRv6 is deployed in the WAN, the IP Flow
Identifier includes the source IP address and the SRH; When native
IPv6 is deployed in the WAN, the IP Flow Identifier includes the
source IP address, destination IP address, and protocol number.
Pause Time: This field can be either copied from the PFC Pause frames
receiving from the DC gateway, or calculated based on the buffer size
of the destined node advertised by IGP.
5. Advertising IP Pause Capability Using IGP
Considering that not all WAN routers support buffering IP flows,
before the egress PE node can send the congestion notification for
pause message to the on-path PE and P nodes, the egress PE node has
to know which on-path P/PE nodes support buffering IP flows. The on-
path P/PE nodes can notify the egress PE node of its support of
buffering IP flows by advertising its IP Pause Capability (IPC) in
advance.
5.1. Advertising IP Pause Capability Using IS-IS
The PE and P nodes advertise their support of buffering IP flows by
inserting a new IPC sub-TLV into the IS-IS Router Capability
[RFC7981]. This sub-TLV SHOULD only be advertised once in the Router
Capability TLV. This sub-TLV SHOULD be advertised WAN domain wide.
The IP Pause Capability sub-TLV is structured as shown in Figure 4.
Min & Zhang Expires 31 August 2026 [Page 6]
Internet-Draft Congestion Notification for Pause February 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Sub-TLVs (variable) |
+- -+
| |
+ +
Figure 4: IP Pause Capability Sub-TLV
where:
Type: TBD2.
Length: Variable, in octets, depending on the sub-sub-TLVs.
The only supported sub-sub-TLV is the Buffer Size Sub-Sub-TLV. The
Buffer Size advertised in the Buffer Size Sub-Sub-TLV represents the
supported maximum IP flows' buffering space. Only a single Buffer
Size Sub-Sub-TLV MAY be advertised in the IP Pause Capability Sub-
TLV. If more than one Buffer Size Sub-Sub-TLV is present, all the
Buffer Size Sub-Sub-TLVs MUST be ignored. The Buffer Size Sub-Sub-
TLV is structured as shown in Figure 5.
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 = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Buffer Size Sub-Sub-TLV
where:
Type: 1.
Length: This field MUST be set to 4.
Buffer Size: This field indicates the maximum IP flows' buffering
space supported by the advertising node. The unit for this field
is KB (Kilo Bytes).
Min & Zhang Expires 31 August 2026 [Page 7]
Internet-Draft Congestion Notification for Pause February 2026
5.2. Advertising IP Pause Capability Using OSPF
The PE and P nodes advertise their support of buffering IP flows by
advertising a new IPC TLV of the OSPF Router Information (RI) Opaque
Link State Advertisement (LSA) [RFC7770]. This TLV is applicable to
both OSPFv2 and OSPFv3. This TLV SHOULD only be advertised once in
the RI Opaque LSA. This TLV SHOULD be advertised WAN domain wide.
The IP Pause Capability TLV is structured as shown in Figure 6.
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 = TBD3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
+ +
Figure 6: IP Pause Capability TLV
where:
Type: TBD3.
Length: Variable, in octets, depending on the sub-TLVs.
The only supported sub-TLV is the Buffer Size Sub-TLV. The Buffer
Size advertised in the Buffer Size Sub-TLV represents the supported
maximum IP flows' buffering space. Only a single Buffer Size Sub-TLV
MAY be advertised in the IP Pause Capability TLV. If more than one
Buffer Size Sub-TLV is present, all the Buffer Size Sub-TLVs MUST be
ignored. The Buffer Size Sub-TLV is structured as shown in Figure 7.
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 = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Buffer Size Sub-TLV
where:
Min & Zhang Expires 31 August 2026 [Page 8]
Internet-Draft Congestion Notification for Pause February 2026
Type: 1.
Length: This field MUST be set to 4.
Buffer Size: This field indicates the maximum IP flows' buffering
space supported by the advertising node. The unit for this field
is KB (Kilo Bytes).
6. Security Considerations
The congestion notification for pause from PE node receiving PFC
frames to P/PE nodes MUST be applied in a specific controlled domain.
A limited administrative domain provides the network administrator
with the means to select, monitor, and control the access to the
network, making it a trusted domain.
To avoid potential Denial-of-Service (DoS) attacks, it is RECOMMENDED
that implementations apply rate-limiting policies when generating and
receiving congestion notification for pause messages.
A deployment MUST ensure that border-filtering drops inbound
congestion notification for pause message from outside of the domain
and that drops outbound congestion notification for pause message
leaving the domain.
A deployment MUST support the configuration option to enable or
disable the congestion notification for pause feature defined in this
document. By default, the congestion notification for pause feature
MUST be disabled.
7. IANA Considerations
7.1. A well-known UDP Port
This document requests the following allocations from IANA:
A well-known UDP port number TBD1 from the System Ports range of the
"Service Name and Transport Protocol Port Number" registry [RFC6335]
is requested to be assigned to the Congestion Notification for Pause
Message. Specifically, IANA is requested to assign a UDP port as
shown below for which the Assignee and Contact is the IESG and the
IETF Chair, respectively.
Min & Zhang Expires 31 August 2026 [Page 9]
Internet-Draft Congestion Notification for Pause February 2026
+==============+========+===========+==============+===============+
| Service Name | Port | Transport | Description | Reference |
| | Number | Protocol | | |
+==============+========+===========+==============+===============+
| Congestion | TBD1 | udp | Receiver | Section 4 of |
| Notification | | | Port for | THIS_DOCUMENT |
| for Pause | | | Congestion | |
| | | | Notification | |
| | | | for Pause | |
+--------------+--------+-----------+--------------+---------------+
Table 1: Service Name and Transport Protocol Port Number Registry
7.2. IS-IS IP Pause Capability Sub-TLV
This document requests IANA to make the following registration in the
"IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry:
+=======+=====================+===============+
| Value | Description | Reference |
+=======+=====================+===============+
| TBD2 | IP Pause Capability | This document |
+-------+---------------------+---------------+
Table 2: New Sub-TLV in IS-IS Sub-TLVs for
IS-IS Router CAPABILITY TLV Registry
7.3. IS-IS Sub-Sub-TLVs for the IP Pause Capability Sub-TLV Registry
IANA is requested to create the "IS-IS Sub-Sub-TLVs for IP Pause
Capability Sub-TLV" registry under the "IS-IS TLV Codepoints"
grouping for the assignment of sub-TLV types for the IP Pause
Capability sub-TLV specified in this document. This registry defines
sub-sub-TLVs for the IP Pause Capability sub-TLV (TBD2) advertised in
the IS-IS Router CAPABILITY TLV (242).
The registration procedure is "Expert Review", as defined in
[RFC8126]. Guidance for the designated experts is provided in
[RFC7370]. The Buffer Size sub-sub-TLV is defined by this document,
and the initial contents of the registry are as follows:
Min & Zhang Expires 31 August 2026 [Page 10]
Internet-Draft Congestion Notification for Pause February 2026
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| 0 | Reserved | This document |
+-------+-------------+---------------+
| 1 | Buffer Size | This document |
+-------+-------------+---------------+
| 2-255 | Unassigned | |
+-------+-------------+---------------+
Table 3: IS-IS Sub-Sub-TLVs for IP
Pause Capability Sub-TLV Registry
7.4. OSPF IP Pause Capability TLV
This document requests IANA to make the following registration in the
"OSPF Router Information (RI) TLVs" registry:
+=======+=====================+===============+
| Value | Description | Reference |
+=======+=====================+===============+
| TBD3 | IP Pause Capability | This document |
+-------+---------------------+---------------+
Table 4: New TLV in OSPF Router Information
(RI) TLVs Registry
7.5. OSPF IP Pause Parameter Sub-TLVs Registry
IANA is requested to create the "OSPF IP Pause Parameter Sub-TLVs"
registry under the "Open Shortest Path First (OSPF) Parameters"
grouping. This registry defines sub-TLVs for the IP Pause Capability
TLV (TBD3).
The registration procedures are that the values in the range 1-34999
are to be allocated using the "Standards Action" registration
procedure defined in [RFC8126], and the values in the range
35000-65499 are to be allocated using the "First Come First Served"
registration procedure. The Buffer Size sub-TLV is defined by this
document, and the initial contents of the registry are as follows:
Min & Zhang Expires 31 August 2026 [Page 11]
Internet-Draft Congestion Notification for Pause February 2026
+=============+==============+===============+
| Value | Description | Reference |
+=============+==============+===============+
| 0 | Reserved | This document |
+-------------+--------------+---------------+
| 1 | Buffer Size | This document |
+-------------+--------------+---------------+
| 2-65499 | Unassigned | |
+-------------+--------------+---------------+
| 65500-65534 | Experimental | This document |
+-------------+--------------+---------------+
| 65535 | Reserved | This document |
+-------------+--------------+---------------+
Table 5: OSPF IP Pause Parameter Sub-TLVs
Registry
8. Acknowledgements
The authors would like to acknowledge Xiangyang Zhu and Yao Liu for
the very helpful discussion.
9. References
9.1. Normative References
[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/info/rfc2119>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints
Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014,
<https://www.rfc-editor.org/info/rfc7370>.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
Min & Zhang Expires 31 August 2026 [Page 12]
Internet-Draft Congestion Notification for Pause February 2026
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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/info/rfc8174>.
9.2. Informative References
[IEEE8021Q-2022]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks",
DOI 10.1109/IEEESTD.2022.10004498, IEEE Std 802.1Q-2022,
December 2022,
<https://ieeexplore.ieee.org/document/10004498>.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000,
<https://www.rfc-editor.org/info/rfc2764>.
[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/info/rfc8754>.
Authors' Addresses
Xiao Min
ZTE Corp.
Nanjing
China
Phone: +86 18061680168
Email: xiao.min2@zte.com.cn
Min & Zhang Expires 31 August 2026 [Page 13]
Internet-Draft Congestion Notification for Pause February 2026
Kan Zhang
China Mobile
Beijing
China
Email: zhangkan@chinamobile.com
Min & Zhang Expires 31 August 2026 [Page 14]