rfc9599v2.txt   rfc9599.txt 
skipping to change at line 803 skipping to change at line 803
network operators, such as Provider Backbone Bridges (PBB) network operators, such as Provider Backbone Bridges (PBB)
([IEEE802.1Q]; previously 802.1ah). ([IEEE802.1Q]; previously 802.1ah).
ECN support in TRansparent Interconnection of Lots of Links (TRILL) ECN support in TRansparent Interconnection of Lots of Links (TRILL)
[RFC9600] provides a good example of how to add congestion [RFC9600] provides a good example of how to add congestion
notification to a lower-layer protocol without relying on careful and notification to a lower-layer protocol without relying on careful and
consistent operator configuration. TRILL provides an extension consistent operator configuration. TRILL provides an extension
header word with space for flags of different categories depending on header word with space for flags of different categories depending on
whether logic to understand the extension is critical. The whether logic to understand the extension is critical. The
congestion-experienced marking has been defined as a 'critical congestion-experienced marking has been defined as a 'critical
ingress-to-egress' flag. If a transit RBridge sets this flag on a ingress-to-egress' flag. So, if a transit RBridge sets this flag on
frame and an egress RBridge does not have any logic to process it, a frame and an egress RBridge does not have any logic to process it,
then the egress RBridge will drop the frame, which is the desired the egress RBridge will drop the frame, which is the desired default
default action anyway. Therefore, TRILL RBridges can be updated with action anyway. Therefore, TRILL RBridges can be updated with support
support for congestion notification in no particular order and, at for congestion notification in no particular order and, at the egress
the egress of the TRILL campus, congestion notification will be of the TRILL campus, congestion notification will be propagated to IP
propagated to IP as ECN whenever ECN logic has been implemented at as ECN whenever ECN logic has been implemented at the egress, or as
the egress, or as drop otherwise. drop otherwise.
QCN [IEEE802.1Q] is not intended to extend beyond a single subnet or QCN [IEEE802.1Q] is not intended to extend beyond a single subnet or
interoperate with IP-ECN. Nonetheless, the way QCN indicates to interoperate with IP-ECN. Nonetheless, the way QCN indicates to
lower-layer devices that the endpoints will not understand QCN lower-layer devices that the endpoints will not understand QCN
provides another example that a lower-layer protocol designer might provides another example that a lower-layer protocol designer might
be able to mimic for their scenario. An operator can define certain be able to mimic for their scenario. An operator can define certain
Priority Code Points (PCPs [IEEE802.1Q]; previously 802.1p) to Priority Code Points (PCPs [IEEE802.1Q]; previously 802.1p) to
indicate non-QCN frames. Then an ingress bridge has to map each indicate non-QCN frames. Then an ingress bridge has to map each
arriving not-QCN-capable IP packet to one of these non-QCN PCPs. arriving not-QCN-capable IP packet to one of these non-QCN PCPs.
skipping to change at line 1071 skipping to change at line 1071
indicate congestion on an outgoing PDU [RFC7141]. Nonetheless, to indicate congestion on an outgoing PDU [RFC7141]. Nonetheless, to
facilitate pipelined implementation, it would be acceptable for facilitate pipelined implementation, it would be acceptable for
congestion marks to propagate to a slightly later IP packet. congestion marks to propagate to a slightly later IP packet.
At decapsulation in either case: At decapsulation in either case:
* ECN-marking propagation logically occurs before application of * ECN-marking propagation logically occurs before application of
Decapsulation Guideline 1 in Section 4.4. For instance, if ECN- Decapsulation Guideline 1 in Section 4.4. For instance, if ECN-
marking propagation would cause an ECN congestion indication to be marking propagation would cause an ECN congestion indication to be
applied to an IP packet that is a Not-ECN-PDU, then that IP packet applied to an IP packet that is a Not-ECN-PDU, then that IP packet
is dropped in accordance with Guideline 1; is dropped in accordance with Guideline 1.
* where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the * Where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the
same IP packet, the decapsulation specification SHOULD require same IP packet, the decapsulation specification SHOULD require
that packet to be discarded. that packet to be discarded.
* where a mix of different types of ECN-PDUs arrives to construct * Where a mix of different types of ECN-PDUs arrives to construct
the same IP packet, e.g., a mix of frames that map to ECT(0) and the same IP packet, e.g., a mix of frames that map to ECT(0) and
ECT(1) IP packets, the decapsulation specification might consider ECT(1) IP packets, the decapsulation specification might consider
this a protocol error. But, if the lower-layer protocol has this a protocol error. But, if the lower-layer protocol has
defined such a mix of types of ECN-PDU as valid, it SHOULD require defined such a mix of types of ECN-PDU as valid, it SHOULD require
the resulting IP packet to be set to either ECT(0) or ECT(1). In the resulting IP packet to be set to either ECT(0) or ECT(1). In
this case, it SHOULD take into account that the RFC Series has so this case, it SHOULD take into account that the RFC Series has so
far allowed ECT(0) and ECT(1) to be considered equivalent far allowed ECT(0) and ECT(1) to be considered equivalent
[RFC3168]; or ECT(1) can provide a less severe congestion marking [RFC3168]; or ECT(1) can provide a less severe congestion marking
than CE [RFC6040]; or ECT(1) can indicate an unmarked but ECN- than CE [RFC6040]; or ECT(1) can indicate an unmarked but ECN-
capable packet that is subject to a different marking algorithm to capable packet that is subject to a different marking algorithm to
skipping to change at line 1191 skipping to change at line 1191
native lower-layer mechanism if available). native lower-layer mechanism if available).
3. It is sufficient to use the first IP header found in the stack; 3. It is sufficient to use the first IP header found in the stack;
the egress of the relevant tunnel can propagate congestion the egress of the relevant tunnel can propagate congestion
notification upwards to any more deeply encapsulated IP headers notification upwards to any more deeply encapsulated IP headers
later. later.
6. Feed-Backward Mode: Guidelines for Adding Congestion Notification 6. Feed-Backward Mode: Guidelines for Adding Congestion Notification
It can be seen from Section 3.3 that congestion notification in a It can be seen from Section 3.3 that congestion notification in a
subnet using feed-backward mode have generally not been designed to subnet using feed-backward mode has generally not been designed to be
be directly coupled with IP-layer congestion notification. The directly coupled with IP-layer congestion notification. The subnet
subnet attempts to minimize congestion internally, and if the attempts to minimize congestion internally, and if the incoming load
incoming load at the ingress exceeds the capacity somewhere through at the ingress exceeds the capacity somewhere through the subnet, the
the subnet, the Layer 3 buffer into the ingress backs up. Thus, a Layer 3 buffer into the ingress backs up. Thus, a feed-backward mode
feed-backward mode subnet is in some sense similar to a null mode subnet is in some sense similar to a null mode subnet, in that there
subnet, in that there is no need for any direct interaction between is no need for any direct interaction between the subnet and higher-
the subnet and higher-layer congestion notification. Therefore, no layer congestion notification. Therefore, no detailed protocol
detailed protocol design guidelines are appropriate. Nonetheless, a design guidelines are appropriate. Nonetheless, a more general
more general guideline is appropriate: guideline is appropriate:
| A subnetwork technology intended to eventually interface to IP | A subnetwork technology intended to eventually interface to IP
| SHOULD NOT be designed using only the feed-backward mode, which is | SHOULD NOT be designed using only the feed-backward mode, which is
| certainly best for a stand-alone subnet, but would need to be | certainly best for a stand-alone subnet, but would need to be
| modified to work efficiently as part of the wider Internet because | modified to work efficiently as part of the wider Internet because
| IP uses feed-forward-and-up mode. | IP uses feed-forward-and-up mode.
The feed-backward approach at least works beneath IP, where the term The feed-backward approach at least works beneath IP, where the term
'works' is used only in a narrow functional sense because feed- 'works' is used only in a narrow functional sense because feed-
backward can result in very inefficient and sluggish congestion backward can result in very inefficient and sluggish congestion
skipping to change at line 1256 skipping to change at line 1256
transit. Otherwise, interior nodes signalling congestion would transit. Otherwise, interior nodes signalling congestion would
invalidate any authentication protocol applied to the lower-layer invalidate any authentication protocol applied to the lower-layer
header -- by altering a header field that had been assumed as header -- by altering a header field that had been assumed as
immutable. immutable.
The redesign of protocols that encapsulate IP in order to propagate The redesign of protocols that encapsulate IP in order to propagate
congestion signals between layers raises potential signal integrity congestion signals between layers raises potential signal integrity
concerns. Experimental or proposed approaches exist for assuring the concerns. Experimental or proposed approaches exist for assuring the
end-to-end integrity of in-band congestion signals, such as: end-to-end integrity of in-band congestion signals, such as:
* Congestion exposure (ConEx) for networks: * Congestion Exposure (ConEx) for networks:
- to audit that their congestion signals are not being suppressed - to audit that their congestion signals are not being suppressed
by other networks or by receivers; and by other networks or by receivers; and
- to police that senders are responding sufficiently to the - to police that senders are responding sufficiently to the
signals, irrespective of the L4 transport protocol used signals, irrespective of the L4 transport protocol used
[RFC7713]. [RFC7713].
* A test for a sender to detect whether a network or the receiver is * A test for a sender to detect whether a network or the receiver is
suppressing congestion signals (for example, see the second suppressing congestion signals (for example, see the second
 End of changes. 6 change blocks. 
22 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.48.