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