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