Fast Congestion Notification Packet (CNP) with Proxy
draft-xiao-fann-fast-cnp-with-proxy-02
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 , Zehua Hu | ||
| Last updated | 2026-08-07 | ||
| Replaces | draft-xiao-rtgwg-proxy-congestion-notification | ||
| 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-fann-fast-cnp-with-proxy-02
FANN Working Group X. Min
Internet-Draft ZTE Corp.
Intended status: Standards Track K. Zhang
Expires: 8 February 2027 China Mobile
Z. Hu
China Telecom
7 August 2026
Fast Congestion Notification Packet (CNP) with Proxy
draft-xiao-fann-fast-cnp-with-proxy-02
Abstract
This document describes the necessity and feasibility to introduce a
proxy network node between the congested network node and the traffic
sender. The proxy network node is used to translate the congestion
notification. The congested network node sends the congestion
notification to the proxy network node in a format defined in this
document, and then the proxy network node translates the received
congestion notification to a format known by the traffic sender and
resends the translated congestion notification to the traffic sender.
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 8 February 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.
Min, et al. Expires 8 February 2027 [Page 1]
Internet-Draft Fast CNP with Proxy August 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 . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Congestion Notification Mechanisms . . . . . . . . . . . . . 5
4. Congestion Notification to Proxy Network Node . . . . . . . . 8
4.1. Packet Format Option 1 . . . . . . . . . . . . . . . . . 8
4.2. Packet Format Option 2 . . . . . . . . . . . . . . . . . 9
5. Advertising Proxy Node Capability Using IGP/BGP . . . . . . . 11
5.1. Advertising Proxy Node Capability Using IS-IS . . . . . . 11
5.2. Advertising Proxy Node Capability Using OSPFv2 . . . . . 12
5.3. Advertising Proxy Node Capability Using OSPFv3 . . . . . 12
5.4. Advertising Proxy Node Capability Using BGP . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
[I-D.xiao-fann-fast-cnp] defines a congestion notification message
used in Remote Direct Memory Access (RDMA) over Converged Ethernet
version 2 (RoCEv2) networks. This kind of congestion notification
message is called RoCEv2 Fast Congestion Notification Packet (Fast
CNP), which can be sent by a congested network node to the traffic
sender directly. The RoCEv2 Fast CNP extends the standard RoCEv2 CNP
([IBTA-SPEC]) consumed by the traffic sender supporting RoCEv2.
RoCEv2 has already been widely deployed, and it runs the InfiniBand
transport layer over UDP and IP protocols on an Ethernet network,
bringing many of the advantages of InfiniBand to Ethernet networks.
For a traffic sender supporting RoCEv2, congestion control is
important, so while detecting congestion the RoCEv2 CNP or RoCEv2
Fast CNP must be used to alert the traffic sender slowing down the
sending rate. For a traffic sender not supporting RoCEv2, congestion
control is still important, so while detecting congestion the
Min, et al. Expires 8 February 2027 [Page 2]
Internet-Draft Fast CNP with Proxy August 2026
corresponding congestion notification message supported by the sender
must be used to alert the traffic sender slowing down the sending
rate.
Considering there are multiple different congestion notification
messages existing for the traffic sender, if a congested network node
would send a congestion notification message to the traffic sender
directly, there is a prerequisite for the congested network node to
know what kind of congestion notification message is supported by
each specific traffic sender. Except for that precondition, there
are two more problems as follows:
* When the congested network node is a VPN Provider (P) router, it's
difficult for the congested network node to send a congestion
notification message to the traffic sender directly, because there
are different routing domains for the VPN P router and VPN
Customer Edge (CE) router.
* When the traffic sender supports only standard RoCEv2 CNP, it's
difficult for the congested network node to construct a standard
RoCEv2 CNP (for details please refer to Section 3 of
[I-D.xiao-fann-fast-cnp]).
A proxy network node between the congested network node and the
traffic sender can help to resolve the problems described above,
being independent of the extensions proposed in
[I-D.xiao-fann-fast-cnp]. While detecting congestion, the congested
network node sends a congestion notification message to a proxy
network node first, and then based on the received congestion
notification message, the proxy network node notifies the traffic
sender about the congestion using a congestion notification message
(e.g., the standard RoCEv2 CNP) known by the traffic sender. For the
selection of the proxy network node, generally speaking the proxy
network node should be positioned as close to the traffic sender as
possible (e.g., the leaf switch within a data center), and there are
at least three rules as follows:
* The selected proxy network node must know what kind of congestion
notification message is supported by the traffic sender.
* The selected proxy network node and the congested network node
must be within the same routing domain.
Min, et al. Expires 8 February 2027 [Page 3]
Internet-Draft Fast CNP with Proxy August 2026
* For RoCEv2 networks where the traffic sender supports only
standard RoCEv2 CNP, the selected proxy network node must be able
to learn the mapping table between the Source Queue Pair and the
Destination Queue Pair through data traffic, which means the
selected proxy network node must be located where both the forward
and the reverse data traffic traverse.
How to select a proxy network node for a specific traffic sender is
deployment specific and beyond the scope of this document.
This document describes the necessity and feasibility to introduce a
proxy network node between the congested network node and the traffic
sender. Specifically, the problem statement is described in Sections
1 and 3, and the formats of the congestion notification message sent
from the congested network node to the proxy network node are defined
in Section 4, and the solution on how the congested network node
knows the address mapping relationship between the proxy network node
and the traffic sender is defined in Section 5.
2. Conventions Used in This Document
2.1. Abbreviations
ABR: Area Border Router
BTS: Back To Sender
CNP: Congestion Notification Packet
DoS: Denial-of-Service
ECN: Explicit Congestion Notification
ELC: Entropy Label Capability
ELCv3: Entropy Label Characteristic
IBTA: InfiniBand Trade Association
NRP: Network Resource Partition
PNC: Proxy Node Capability
QP: Queue Pair
RDMA: Remote Direct Memory Access
RoCEv2: RDMA over Converged Ethernet version 2
Min, et al. Expires 8 February 2027 [Page 4]
Internet-Draft Fast CNP with Proxy August 2026
TC: Traffic Class
ToS: Type of Service
UEC: Ultra Ethernet Consortium
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
In the field of congestion control, there are already at least three
kinds of referenced congestion notification mechanisms. This
document introduces the fourth congestion notification mechanism
called "Fast CNP with Proxy".
The first congestion notification mechanism is referred to as
Classical Congestion Notification without Dedicated Packet, as shown
in Figure 1.
Congestion Notification by TCP Marking
|<-------------------------------------------------------+
| |
| Congestion Notification by ECN Marking
| |------------>|
+--------+ +-------+ +-------+ +-------+ +--------+
|Traffic |====>|Network|====>|Network|====>|Network|====>|Traffic |
|Sender | |Node 1 | |Node 2 | |Node 3 | |Receiver|
+--------+ +-------+ +-------+ +-------+ +--------+
Congestion
Point
Figure 1: Classical Congestion Notification without Dedicated Packet
Min, et al. Expires 8 February 2027 [Page 5]
Internet-Draft Fast CNP with Proxy August 2026
With this congestion notification mechanism, the traffic sender
indicates that it supports the congestion notification from the
traffic receiver by a specific Explicit Congestion Notification (ECN)
marking within the IP header of the data packet, and the congested
network node (Netwok Node 3 in Figure 1) notifies the traffic
receiver about the congestion by a specific ECN marking. After
receiving a data packet with the specific ECN marking, the traffic
receiver would notify congestion to the traffic sender by a specific
TCP marking within the TCP header of the data packet. [RFC3168]
details how this kind of congestion notification mechanism works.
The second congestion notification mechanism is referred to as
Classical Congestion Notification with Dedicated Packet, as shown in
Figure 2.
Congestion Notification Packet Type 1
|<-------------------------------------------------------+
| |
| Congestion Notification by ECN Marking
| |------------>|
+--------+ +-------+ +-------+ +-------+ +--------+
|Traffic |====>|Network|====>|Network|====>|Network|====>|Traffic |
|Sender | |Node 1 | |Node 2 | |Node 3 | |Receiver|
+--------+ +-------+ +-------+ +-------+ +--------+
Congestion
Point
Figure 2: Classical Congestion Notification with Dedicated Packet
With this congestion notification mechanism, the traffic sender
indicates that it supports the congestion notification from the
traffic receiver by a specific ECN marking within the IP header of
the data packet, and the congested network node (Netwok Node 3 in
Figure 2) notifies the traffic receiver about the congestion by a
specific ECN marking. After receiving a data packet with the
specific ECN marking, the traffic receiver would notify congestion to
the traffic sender by a dedicated congestion notification packet.
[IBTA-SPEC] details an example on how this kind of congestion
notification mechanism works.
The third congestion notification mechanism is referred to as Fast
CNP without Proxy, as shown in Figure 3.
Min, et al. Expires 8 February 2027 [Page 6]
Internet-Draft Fast CNP with Proxy August 2026
Congestion Notification Packet Type 2
|<-----------------------------------------+
| |
+--------+ +-------+ +-------+ +-------+ +--------+
|Traffic |====>|Network|====>|Network|====>|Network|====>|Traffic |
|Sender | |Node 1 | |Node 2 | |Node 3 | |Receiver|
+--------+ +-------+ +-------+ +-------+ +--------+
Congestion
Point
Figure 3: Fast CNP without Proxy
With this congestion notification mechanism, the congested network
node (Netwok Node 3 in Figure 3) notifies the traffic sender about
the congestion directly by a dedicated congestion notification
packet. [I-D.xiao-fann-fast-cnp] details an example on how this kind
of congestion notification mechanism works.
The fourth congestion notification mechanism is referred to as Fast
CNP with Proxy, as shown in Figure 4.
Congestion Notification Packet Type 3
|<--------------------------+
| |
Congestion Notification Packet Type 4 |
|<-------------+ |
| | |
+--------+ +-------+ +-------+ +-------+ +--------+
|Traffic |====>|Network|====>|Network|====>|Network|====>|Traffic |
|Sender | |Node 1 | |Node 2 | |Node 3 | |Receiver|
+--------+ +-------+ +-------+ +-------+ +--------+
Congestion Congestion
Notification Point
Proxy
Figure 4: Fast CNP with Proxy
With this congestion notification mechanism, the congested network
node (Netwok Node 3 in Figure 4) notifies the proxy network node
about the congestion by a dedicated congestion notification packet,
and then based on the received congestion notification packet, the
proxy network node notifies the traffic sender about the congestion
by a congestion notification message supported by the traffic sender.
This document details how this kind of congestion notification
mechanism works.
Min, et al. Expires 8 February 2027 [Page 7]
Internet-Draft Fast CNP with Proxy August 2026
4. Congestion Notification to Proxy Network Node
This document specifies two packet formats for congestion
notification from the congested network node to the proxy network
node. The reason to have two packet formats is that in some scenario
(e.g., VPN WAN) it may be difficult for the congested network node to
do deep packet inspection. With respect to which format of packet is
used by the congested network node, it can be determined by
configuration or by the type of the congested network node (e.g.,
when the congested network node is a spine switch within a data
center, packet format option 1 is used; when the congested network
node is a P router within a VPN WAN, packet format option 2 is used).
4.1. Packet Format Option 1
For packet format option 1, the congestion notification message sent
from the congested network node to the proxy network node is a UDP
message formatted as follows:
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 Five-Tuple ~
| |
+---------------+-----------------------------------------------+
| TC/ToS | Destination Queue Pair |
+---------------+-----------------------------------------------+
Figure 5: Congestion Notification 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 Five-Tuple: The IP five-tuple as described in [RFC6438] includes
the source IP address, destination IP address, protocol number,
source port number, and destination port number. The IP five-tuple
is a data flow information copied from the data packets causing
congestion. The source IP address within the IP five-tuple is the IP
address of the traffic sender, so it can be used by the receiving
node (i.e., the proxy network node) to identify the traffic sender,
Min, et al. Expires 8 February 2027 [Page 8]
Internet-Draft Fast CNP with Proxy August 2026
to which the proxy network node would send a second congestion
notification message based on the received congestion notification
message. To be specific, each time the proxy network node receives a
congestion notification from the congested network node, the proxy
network node would send a second congestion notification to the
traffic sender. The second congestion notification SHOULD be a
standard RoCEv2 CNP or a standard Ultra Ethernet Consortium (UEC)
Back To Sender (BTS) packet. Except for the source IP address, the
destination IP address within the IP five-tuple can be copied to the
source IP address by the receiving node while sending the second
congestion notification to the traffic sender; the protocol number
and/or the destination port number can be used by the receiving node
to determine which type of the second congestion notification to use.
TC/ToS: The Traffic Class (TC) for IPv6 [RFC8200] or the Type of
Service (ToS) for IPv4 [RFC791]. In the UEC networks, the TC/ToS
combined with the source IP address and destination IP address within
the IP Five-Tuple are used to identify a congested traffic flow for
which the sending rate needs to be reduced by the traffic sender.
The TC/ToS is copied from the UEC data packets causing congestion.
The TC/ToS is used by the receiving node (i.e., the proxy network
node) to construct the standard UEC BTS packet sent to the traffic
sender.
Destination Queue Pair: In the RoCEv2 networks there is a more fine-
grained data flow infomation called Queue Pair (QP), which is a
24-bit field used to identify a congested traffic flow for which the
sending rate needs to be reduced by the traffic sender. The
Destination QP is copied from the RoCEv2 data packets causing
congestion. The Destination QP is used by the receiving node (i.e.,
the proxy network node) to identify the Source QP of the traffic
sender. That is to say, the proxy network node needs to maintain a
mapping table between the Source QP and the Destination QP in the
context of source IP address and destination IP address when it's a
RoCEv2 traffic.
4.2. Packet Format Option 2
For packet format option 2, the congestion notification message sent
from the congested network node to the proxy network node is a UDP
message formatted as follows:
Min, et al. Expires 8 February 2027 [Page 9]
Internet-Draft Fast CNP with Proxy August 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 |
+-------------------------------+-------------------------------+
| |
~ IP Five-Tuple ~
| |
+---------------+-----------------------------------------------+
| TC/ToS | Reserved |
+---------------+-----------------------------------------------+
| |
~ NRP Selector ID ~
| |
+---------------------------------------------------------------+
Figure 6: Congestion Notification 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 (TBD2) needs to be allocated for this
Congestion Notification Message.
IP Five-Tuple: Same as Section 4.1. Note that when the congested
network node is a VPN P router, the IP five-tuple is carried below
the VPN encapsulation.
TC/ToS: Same as Section 4.1. Note that when the congested network
node is a VPN P router, the TC/ToS is carried below the VPN
encapsulation.
NRP Selector ID: The Network Resource Partition (NRP) Selector ID as
defined in [I-D.ietf-teas-ns-ip-mpls]. The NRP Selector ID is copied
from the data packets causing congestion. The NRP Selector ID is
used by the receiving node (i.e., the proxy network node) to identify
the Source QP of the traffic sender when it's a RoCEv2 traffic, as
well as the VPN ID when the congested network node is a VPN P router.
That is to say, the proxy network node needs to maintain a mapping
table between the Source QP and the NRP Selector ID when it's a
RoCEv2 traffic, and a mapping table between the VPN ID and the NRP
Selector ID when the proxy network node is a VPN PE router.
Min, et al. Expires 8 February 2027 [Page 10]
Internet-Draft Fast CNP with Proxy August 2026
5. Advertising Proxy Node Capability Using IGP/BGP
Before the congested network node can send the congestion
notification message to the proxy network node, the congested network
node has to know about the IP address of the proxy network node and
the IP addresses of the traffic senders behind the proxy network
node.
The proxy network node notifies the congested network node of its IP
address by advertising its proxy node capability in advance. Even
though the Proxy Node Capability (PNC) is a property of the node, it
is necessary to advertise the PNC with some prefixes attached to the
traffic senders behind the proxy network node. That means the proxy
network node would advertise the mapping relationship between the IP
address of the proxy network node and the IP addresses of the traffic
senders, which enables the congested network node to establish the
address mapping table between the traffic senders and the proxy
network node. On the basis of the established address mapping table,
when a congestion of the data traffic is detected, the congested
network node would look up the source IP address of the data packet
causing congestion, and send the congestion notification message to
the proxy network node but not the traffic sender identified by the
source IP address.
5.1. Advertising Proxy Node Capability Using IS-IS
Analogous to the Entropy Label Capability (ELC) Flag (E-flag) defined
in Section 3 of [RFC9088], a new bit PNC Flag (P-flag) is defined,
which is Bit 7 in the Prefix Attribute Flags [RFC7794], as shown in
Figure 7.
0 1 2 3 4 5 6 7...
+-+-+-+-+-+-+-+-+...
|X|R|N|E|A|U|U|P|...
| | | | | | |P| |...
+-+-+-+-+-+-+-+-+...
Figure 7: IS-IS Prefix Attribute Flags
P-Flag: PNC Flag (Bit 7)
Set for the local host prefix of the originating node if it's used
as a congestion notification proxy node for the prefix.
The PNC signaling MUST be preserved when a router propagates a prefix
between ISIS levels [RFC5302].
Min, et al. Expires 8 February 2027 [Page 11]
Internet-Draft Fast CNP with Proxy August 2026
5.2. Advertising Proxy Node Capability Using OSPFv2
Analogous to the ELC Flag (E-flag) defined in Section 3.1 of
[RFC9089], a new bit PNC Flag (P-flag) is defined, which is Bit 2 in
OSPFv2 Prefix Attribute Flags field [RFC9792], as shown in Figure 8.
0 1 2 3 4...
+-+-+-+-+-+...
|U|U|P| | |...
| |P| | | |...
+-+-+-+-+-+...
Figure 8: OSPFv2 Prefix Attribute Flags
P-Flag: PNC Flag (Bit 2)
Set for the local host prefix of the originating node if it's used
as a congestion notification proxy node for the prefix.
The PNC signaling MUST be preserved when an OSPFv2 Area Border Router
(ABR) distributes information between areas. To do so, an ABR MUST
originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including
the received PNC setting.
5.3. Advertising Proxy Node Capability Using OSPFv3
Analogous to the ELC Flag (E-flag) defined in Section 3.2 of
[RFC9089], a new bit PNC Flag (P-flag) is defined, which is Bit 2 in
OSPFv3 Prefix Attribute Flags field [RFC9792], as shown in Figure 9.
0 1 2 3 4...
+-+-+-+-+-+...
|U|U|P| | |...
| |P| | | |...
+-+-+-+-+-+...
Figure 9: OSPFv3 Prefix Attribute Flags
P-Flag: PNC Flag (Bit 2)
Set for the local host prefix of the originating node if it's used
as a congestion notification proxy node for the prefix.
Min, et al. Expires 8 February 2027 [Page 12]
Internet-Draft Fast CNP with Proxy August 2026
The PNC signaling MUST be preserved when an OSPFv3 Area Border Router
(ABR) distributes information between areas. The setting of the PNC
Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the Inter-Area-
Prefix TLV [RFC8362], generated by an ABR, MUST be the same as the
value the PNC Flag associated with the prefix in the source area.
5.4. Advertising Proxy Node Capability Using BGP
Analogous to the Entropy Label Characteristic (ELCv3) TLV defined in
Section 2.1 of [I-D.ietf-idr-elc], a new PNC characteristic TLV is
defined, which uses code value TBD3 in "BGP Next Hop Dependent
Characteristic Codes" registry requested by [I-D.ietf-idr-nhc], as
shown in Figure 10.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Characteristic Code = TBD3 | Characteristic Length = 4/16 |
+-------------------------------+-------------------------------+
~ IP address of the Proxy Network Node ~
+---------------------------------------------------------------+
Figure 10: BGP Next Hop Dependent Characteristic PNC TLV Format
PNC TLV: code TBD3, length 4 or 16, and carries the IP address (4
octets for IPv4 or 16 octets for IPv6) of the proxy network node.
Carried for the local host prefix of the originating node if it's
used as a congestion notification proxy node for the prefix.
6. Security Considerations
The congestion notification from congested network node to the proxy
network node 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 messages.
A deployment MUST ensure that border-filtering drops inbound
congestion notification message from outside of the domain and that
drops outbound congestion notification message leaving the domain.
Min, et al. Expires 8 February 2027 [Page 13]
Internet-Draft Fast CNP with Proxy August 2026
A deployment MUST support the configuration option to enable or
disable the congestion notification proxy feature defined in this
document. By default, the congestion notification proxy feature MUST
be disabled.
7. IANA Considerations
This document requests the following allocations from IANA:
- Two well-known UDP port numbers TBD1 and TBD2 from the System
Ports range of the "Service Name and Transport Protocol Port
Number" registry [RFC6335] are requested to be assigned to the
Congestion Notification to Proxy Messages. Specifically, IANA is
requested to assign two UDP ports as shown below for which the
Assignee and Contact is the IESG and the IETF Chair, respectively.
+==============+========+===========+=============+===============+
| Service Name | Port | Transport | Description | Reference |
| | Number | Protocol | | |
+==============+========+===========+=============+===============+
| Congestion | TBD1 | udp | Receiver | Section 4 of |
| Notification | and | | Ports for | THIS_DOCUMENT |
| to Proxy | TBD2 | | Fast CNP to | |
| | | | Proxy | |
+--------------+--------+-----------+-------------+---------------+
Table 1: Service Name and Transport Protocol Port Number Registry
- Bit 7 (suggested) in the "IS-IS Bit Values for Prefix Attribute
Flags Sub-TLV" registry is requested to be assigned to the PNC
Flag (P-Flag).
- Bit 2 (suggested) in the "OSPFv2 Prefix Extended Flags" registry
is requested to be assigned to the PNC Flag (P-Flag).
- Bit 2 (suggested) in the "OSPFv3 Prefix Extended Flags" registry
is requested to be assigned to the PNC Flag (P-Flag).
- Code value TBD3 in the "BGP Next Hop Dependent Characteristic
Codes" registry (to be created based on the request from
[I-D.ietf-idr-nhc]) is requested to be assigned to the PNC
characteristic TLV.
8. Contributors
Jeffrey Haas
HPE
Email: jeffrey.haas@hpe.com
Min, et al. Expires 8 February 2027 [Page 14]
Internet-Draft Fast CNP with Proxy August 2026
9. Acknowledgements
The authors would like to acknowledge Jinghai Yu, Shaofu Peng, Liming
Wu, Jin Yang, Zheng Zhang, Jun Feng, Yao Liu, Xiangyang Zhu for the
very helpful discussions.
10. References
10.1. Normative References
[I-D.ietf-idr-nhc]
Decraene, B., Kompella, K., Krier, S., Satya, M. R.,
Scudder, J., Wang, K., and B. Wen, "BGP Next Hop Dependent
Characteristics Attribute", Work in Progress, Internet-
Draft, draft-ietf-idr-nhc-07, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-nhc-
07>.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
Distribution with Two-Level IS-IS", RFC 5302,
DOI 10.17487/RFC5302, October 2008,
<https://www.rfc-editor.org/info/rfc5302>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[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>.
Min, et al. Expires 8 February 2027 [Page 15]
Internet-Draft Fast CNP with Proxy August 2026
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC9792] Chen, R., Zhao, D., Psenak, P., Talaulikar, K., and L.
Gong, "Prefix Flag Extension for OSPFv2 and OSPFv3",
RFC 9792, DOI 10.17487/RFC9792, June 2025,
<https://www.rfc-editor.org/info/rfc9792>.
10.2. Informative References
[I-D.ietf-idr-elc]
Wen, B., Wang, K., Scudder, J., Satya, M. R., Krier, S.,
Kompella, K., and B. Decraene, "BGP Entropy Label
Characteristic", Work in Progress, Internet-Draft, draft-
ietf-idr-elc-01, 22 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-elc-
01>.
[I-D.ietf-teas-ns-ip-mpls]
Saad, T., Beeram, V. P., Dong, J., Halpern, J. M., and S.
Peng, "Realizing Network Slices in IP/MPLS Networks", Work
in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-
09, 19 July 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-ns-ip-mpls-09>.
Min, et al. Expires 8 February 2027 [Page 16]
Internet-Draft Fast CNP with Proxy August 2026
[I-D.xiao-fann-fast-cnp]
Min, X., lihesong, Zhang, K., Cheng, W., Yang, J., and X.
hexiaoming, "Fast Congestion Notification Packet (CNP) in
RoCEv2 Networks", Work in Progress, Internet-Draft, draft-
xiao-fann-fast-cnp-00, 26 July 2026,
<https://datatracker.ietf.org/doc/html/draft-xiao-fann-
fast-cnp-00>.
[IBTA-SPEC]
InfiniBand Trade Association, "InfiniBand Architecture
Specification Volume 1, Release 1.8", July 2024,
<https://www.infinibandta.org/ibta-specification>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using IS-IS", RFC 9088,
DOI 10.17487/RFC9088, August 2021,
<https://www.rfc-editor.org/info/rfc9088>.
[RFC9089] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using OSPF", RFC 9089,
DOI 10.17487/RFC9089, August 2021,
<https://www.rfc-editor.org/info/rfc9089>.
Authors' Addresses
Xiao Min
ZTE Corp.
Nanjing
China
Phone: +86 18061680168
Email: xiao.min2@zte.com.cn
Min, et al. Expires 8 February 2027 [Page 17]
Internet-Draft Fast CNP with Proxy August 2026
Kan Zhang
China Mobile
Beijing
China
Email: zhangkan@chinamobile.com
Zehua Hu
China Telecom
Guangzhou
China
Email: huzh2@chinatelecom.cn
Min, et al. Expires 8 February 2027 [Page 18]