rfc9599v3.txt   rfc9599.txt 
skipping to change at line 712 skipping to change at line 712
simple reference to [RFC6040]. However, it would not be appropriate simple reference to [RFC6040]. However, it would not be appropriate
to update all these protocols from within the present guidance to update all these protocols from within the present guidance
document. Instead, a companion specification [RFC9601] has the document. Instead, a companion specification [RFC9601] has the
appropriate Standards Track status to update Standards Track appropriate Standards Track status to update Standards Track
protocols. For those that are not under IETF change control protocols. For those that are not under IETF change control
[RFC9601] can only recommend that the relevant body updates them. [RFC9601] can only recommend that the relevant body updates them.
4.2. Wire Protocol Design: Indication of ECN Support 4.2. Wire Protocol Design: Indication of ECN Support
This section is intended to guide the redesign of any lower-layer This section is intended to guide the redesign of any lower-layer
protocol that encapsulates IP to add native congestion notification protocol that encapsulates IP to add built-in congestion notification
support at the lower layer using feed-forward-and-up mode. It support at the lower layer using feed-forward-and-up mode. It
reflects the approaches used in [RFC6040] and in [RFC5129]. reflects the approaches used in [RFC6040] and in [RFC5129].
Therefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS Therefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS
encapsulations that already comply with [RFC6040] or [RFC5129] will encapsulations that already comply with [RFC6040] or [RFC5129] will
already satisfy this guidance. already satisfy this guidance.
A lower-layer (or subnet) congestion notification system: A lower-layer (or subnet) congestion notification system:
1. SHOULD NOT apply explicit congestion notifications to PDUs that 1. SHOULD NOT apply explicit congestion notifications to PDUs that
are destined for legacy layer-4 transport implementations that are destined for legacy layer-4 transport implementations that
skipping to change at line 839 skipping to change at line 839
L4S). The ECN scheme for MPLS [RFC5129] was defined before L4S, so L4S). The ECN scheme for MPLS [RFC5129] was defined before L4S, so
it only currently supports deferred drop that is equivalent to ECN it only currently supports deferred drop that is equivalent to ECN
marking. Nonetheless, in principle, MPLS (and potentially future L2 marking. Nonetheless, in principle, MPLS (and potentially future L2
protocols) could support L4S marking by copying TRILL's approach for protocols) could support L4S marking by copying TRILL's approach for
determining the drop level of any non-ECN traffic at the subnet determining the drop level of any non-ECN traffic at the subnet
egress. egress.
4.3. Encapsulation Guidelines 4.3. Encapsulation Guidelines
This section is intended to guide the redesign of any node that This section is intended to guide the redesign of any node that
encapsulates IP with a lower-layer header when adding native encapsulates IP with a lower-layer header when adding built-in
congestion notification support to the lower-layer protocol using congestion notification support to the lower-layer protocol using
feed-forward-and-up mode. It reflects the approaches used in feed-forward-and-up mode. It reflects the approaches used in
[RFC6040] and [RFC5129]. Therefore, IP-in-IP tunnels or IP-in-MPLS [RFC6040] and [RFC5129]. Therefore, IP-in-IP tunnels or IP-in-MPLS
or MPLS-in-MPLS encapsulations that already comply with [RFC6040] or or MPLS-in-MPLS encapsulations that already comply with [RFC6040] or
[RFC5129] will already satisfy this guidance. [RFC5129] will already satisfy this guidance.
1. Egress Capability Check: A subnet ingress needs to be sure that 1. Egress Capability Check: A subnet ingress needs to be sure that
the corresponding egress of a subnet will propagate any the corresponding egress of a subnet will propagate any
congestion notification added to the outer header across the congestion notification added to the outer header across the
subnet. This is necessary in addition to checking that an subnet. This is necessary in addition to checking that an
skipping to change at line 919 skipping to change at line 919
initialized the congestion level. initialized the congestion level.
As long as subnet and tunnel technologies use the standard As long as subnet and tunnel technologies use the standard
congestion monitoring baseline in this guideline, monitoring congestion monitoring baseline in this guideline, monitoring
systems will know to use the former approach rather than having systems will know to use the former approach rather than having
to 'somehow know' which approach to use. to 'somehow know' which approach to use.
4.4. Decapsulation Guidelines 4.4. Decapsulation Guidelines
This section is intended to guide the redesign of any node that This section is intended to guide the redesign of any node that
decapsulates IP from within a lower-layer header when adding native decapsulates IP from within a lower-layer header when adding built-in
congestion notification support to the lower-layer protocol using congestion notification support to the lower-layer protocol using
feed-forward-and-up mode. It reflects the approaches used in feed-forward-and-up mode. It reflects the approaches used in
[RFC6040] and in [RFC5129]. Therefore, IP-in-IP tunnels or IP-in- [RFC6040] and in [RFC5129]. Therefore, IP-in-IP tunnels or IP-in-
MPLS or MPLS-in-MPLS encapsulations that already comply with MPLS or MPLS-in-MPLS encapsulations that already comply with
[RFC6040] or [RFC5129] will already satisfy this guidance. [RFC6040] or [RFC5129] will already satisfy this guidance.
A subnet egress SHOULD NOT simply copy congestion notifications from A subnet egress SHOULD NOT simply copy congestion notifications from
outer headers to the forwarded header. It SHOULD calculate the outer headers to the forwarded header. It SHOULD calculate the
outgoing congestion notification field from the inner and outer outgoing congestion notification field from the inner and outer
headers using the following guidelines. If there is any conflict, headers using the following guidelines. If there is any conflict,
skipping to change at line 1138 skipping to change at line 1138
* are encapsulated in Ethernet headers, which have no support for * are encapsulated in Ethernet headers, which have no support for
congestion notification; congestion notification;
* are forwarded by the eNode-B (base station) of a 3GPP radio access * are forwarded by the eNode-B (base station) of a 3GPP radio access
network, which is required to apply ECN marking during congestion network, which is required to apply ECN marking during congestion
[LTE-RA] [UTRAN], but the Packet Data Convergence Protocol (PDCP) [LTE-RA] [UTRAN], but the Packet Data Convergence Protocol (PDCP)
that encapsulates the IP header over the radio access has no that encapsulates the IP header over the radio access has no
support for ECN. support for ECN.
This guidance also generalizes to encapsulation by other subnet This guidance also generalizes to encapsulation by other subnet
technologies with no native support for congestion notification at technologies with no built-in support for congestion notification at
the lower layer, but with support for finding and processing an IP the lower layer, but with support for finding and processing an IP
header. It is unlikely to be applicable or necessary for IP-in-IP header. It is unlikely to be applicable or necessary for IP-in-IP
encapsulation, where feed-forward-and-up mode based on [RFC6040] encapsulation, where feed-forward-and-up mode based on [RFC6040]
would be more appropriate. would be more appropriate.
Marking the IP header while switching at layer 2 (by using a Layer 3 Marking the IP header while switching at layer 2 (by using a Layer 3
switch) or while forwarding in a radio access network seems to switch) or while forwarding in a radio access network seems to
represent a layering violation. However, it can be considered as a represent a layering violation. However, it can be considered as a
benign optimization if the guidelines below are followed. Feed-up- benign optimization if the guidelines below are followed. Feed-up-
and-forward is certainly not a general alternative to implementing and-forward is certainly not a general alternative to implementing
skipping to change at line 1171 skipping to change at line 1171
be encapsulated by more than one lower-layer header, e.g., be encapsulated by more than one lower-layer header, e.g.,
Ethernet MAC in MAC ([IEEE802.1Q]; previously 802.1ah). Ethernet MAC in MAC ([IEEE802.1Q]; previously 802.1ah).
Nonetheless, configuring lower-layer equipment to look for an ECN Nonetheless, configuring lower-layer equipment to look for an ECN
field in an encapsulated IP header is a useful optimization. If the field in an encapsulated IP header is a useful optimization. If the
implementation follows the guidelines below, this optimization does implementation follows the guidelines below, this optimization does
not have to be confined to a controlled environment, e.g., within a not have to be confined to a controlled environment, e.g., within a
data centre; it could usefully be applied in any network -- even if data centre; it could usefully be applied in any network -- even if
the operator is not sure whether the above issues will never apply: the operator is not sure whether the above issues will never apply:
1. If a native lower-layer congestion notification mechanism exists 1. If a built-in lower-layer congestion notification mechanism
for a subnet technology, it is safe to mix feed-up-and-forward exists for a subnet technology, it is safe to mix feed-up-and-
with feed-forward-and-up on other switches in the same subnet. forward with feed-forward-and-up on other switches in the same
However, it will generally be more efficient to use the native subnet. However, it will generally be more efficient to use the
mechanism. built-in mechanism.
2. The depth of the search for an IP header SHOULD be limited. If 2. The depth of the search for an IP header SHOULD be limited. If
an IP header is not found soon enough, or an unrecognized or an IP header is not found soon enough, or an unrecognized or
unreadable header is encountered, the switch SHOULD resort to an unreadable header is encountered, the switch SHOULD resort to an
alternative means of signalling congestion (e.g., drop or the alternative means of signalling congestion (e.g., drop or the
native lower-layer mechanism if available). built-in 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 has generally not been designed to be subnet using feed-backward mode has generally not been designed to be
skipping to change at line 1296 skipping to change at line 1296
separated by an L2 header; separated by an L2 header;
* A wide range of subnet technologies, particularly those that work * A wide range of subnet technologies, particularly those that work
in the same 'feed-forward-and-up' mode that is used to support ECN in the same 'feed-forward-and-up' mode that is used to support ECN
in IP and MPLS. in IP and MPLS.
Guidelines have been defined for supporting propagation of ECN Guidelines have been defined for supporting propagation of ECN
between Ethernet and IP on so-called Layer 3 Ethernet switches using between Ethernet and IP on so-called Layer 3 Ethernet switches using
a 'feed-up-and-forward' mode. This approach could enable other a 'feed-up-and-forward' mode. This approach could enable other
subnet technologies to pass ECN signals into the IP layer, even if subnet technologies to pass ECN signals into the IP layer, even if
they do not support ECN natively. they do not support ECN.
Finally, attempting to add congestion notification to a subnet Finally, attempting to add congestion notification to a subnet
technology in feed-backward mode is deprecated except in special technology in feed-backward mode is deprecated except in special
cases due to its likely sluggish response to congestion. cases due to its likely sluggish response to congestion.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 7 change blocks. 
11 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.48.