rfc9599.original.xml   rfc9599.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY ouml "&#246;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
<!ENTITY ndash "&#8211;">
<!ENTITY mdash "&#8212;">
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='https://xml.resource.org/authoring/rfc262
9.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" consensus="true"
<!-- Alterations to I-D/RFC boilerplate --> docName="draft-ietf-tsvwg-ecn-encap-guidelines-22" number="9599" ipr="trust20090
<?rfc private="" ?> 2" updates="3819" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="t
<!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RF rue" symRefs="true" sortRefs="true" version="3">
C -->
<?rfc rfcprocack="yes" ?>
<!-- Default rfcprocack="no" add a short sentence acknowledging xml2rfc -->
<?rfc strict="no" ?>
<!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="yes" ?>
<!-- Default rfcedstyle="yes" attempt to closely follow finer details from the l
atest observable RFC-Editor style -->
<!-- IETF process -->
<?rfc iprnotified="no" ?>
<!-- Default iprnotified="no" I haven't disclosed existence of IPR to IETF -->
<!-- ToC format -->
<?rfc toc="yes" ?>
<!-- Default toc="no" No Table of Contents -->
<!-- Cross referencing, footnotes, comments -->
<?rfc symrefs="yes"?>
<!-- Default symrefs="no" Don't use anchors, but use numbers for refs -->
<?rfc sortrefs="yes"?>
<!-- Default sortrefs="no" Don't sort references into order -->
<?rfc comments="yes" ?>
<!-- Default comments="no" Don't render comments -->
<?rfc inline="no" ?>
<!-- Default inline="no" if comments is "yes", then render comments inline; othe
rwise render them in an `Editorial Comments' section -->
<!-- Pagination control -->
<?rfc compact="yes"?>
<!-- Default compact="no" Start sections on new pages -->
<?rfc subcompact="no"?>
<!-- Default subcompact="(as compact setting)" yes/no is not quite as compact as
yes/yes -->
<!-- HTML formatting control -->
<?rfc emoticonic="yes" ?>
<!-- Default emoticonic="no" Doesn't prettify HTML format -->
<rfc xmlns:xi="https://www.w3.org/2001/XInclude" category="bcp" consensus="true"
docName="draft-ietf-tsvwg-ecn-encap-guidelines-22" ipr="pre5378Trust200902" upd
ates="3819" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" s
ymRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.18.0 -->
<front> <front>
<title abbrev="ECN Encapsulation Guidelines">Guidelines for Adding <!-- [rfced] We note that the short title of this document is "ECN
Congestion Notification to Protocols that Encapsulate IP</title> Encapsulation Guidelines". To match the short title, should we update the
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-guidelin title of the document as follows to include "ECN"?
es-22"/>
Original:
Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP
Perhaps:
Guidelines for Adding Explicit Congestion Notification (ECN) to
Protocols That Encapsulate IP
-->
<title abbrev="ECN Encapsulation Guidelines">Guidelines for Adding
Congestion Notification to Protocols That Encapsulate IP</title>
<seriesInfo name="RFC" value="9599"/>
<seriesInfo name="BCP" value="89"/> <seriesInfo name="BCP" value="89"/>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<postal> <postal>
<street/> <country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>ietf@bobbriscoe.net</email> <email>ietf@bobbriscoe.net</email>
<uri>https://bobbriscoe.net/</uri> <uri>https://bobbriscoe.net/</uri>
</address> </address>
</author> </author>
<author fullname="John Kaippallimalil" initials="J." surname="Kaippallimalil "> <author fullname="John Kaippallimalil" initials="J." surname="Kaippallimalil ">
<organization>Futurewei</organization> <organization>Futurewei</organization>
<address> <address>
<postal> <postal>
<street>5700 Tennyson Parkway, Suite 600</street> <street>5700 Tennyson Parkway, Suite 600</street>
<city>Plano</city> <city>Plano</city>
<region>Texas</region> <region>Texas</region>
<code>75024</code> <code>75024</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>kjohn@futurewei.com</email> <email>kjohn@futurewei.com</email>
</address> </address>
</author> </author>
<date year=""/>
<area>Transport</area> <date month="June" year="2024"/>
<workgroup>Transport Area Working Group</workgroup>
<area>WIT</area>
<workgroup>tsvwg</workgroup>
<keyword>Congestion Control and Management</keyword> <keyword>Congestion Control and Management</keyword>
<keyword>Congestion Notification</keyword> <keyword>Congestion Notification</keyword>
<keyword>Information Security</keyword> <keyword>Information Security</keyword>
<keyword>Tunnelling</keyword> <keyword>Tunnelling</keyword>
<keyword>Encapsulation &amp; Decapsulation</keyword> <keyword>Encapsulation</keyword>
<keyword>ECNDecapsulation</keyword>
<keyword>Protocol</keyword> <keyword>Protocol</keyword>
<keyword>ECN</keyword> <keyword>ECN</keyword>
<keyword>Layering</keyword> <keyword>Layering</keyword>
<abstract> <abstract>
<!-- [rfced] May we rephrase the following sentence to match what appears in
the short title and proposed document title?
Original:
The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that
encapsulates IP.
Perhaps:
The purpose of this document is to guide the design of Explicit
Congestion Notification (ECN) in any lower-layer or tunneling protocol
that encapsulates IP.
-->
<t>The purpose of this document is to guide the design of congestion <t>The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that encapsulates notification in any lower-layer or tunnelling protocol that encapsulates
IP. The aim is for explicit congestion signals to propagate consistently IP. The aim is for explicit congestion signals to propagate consistently
from lower layer protocols into IP. Then the IP internetwork layer can from lower-layer protocols into IP.
act as a portability layer to carry congestion notification from
non-IP-aware congested nodes up to the transport layer (L4). Following <!-- [rfced] FYI, "congestion notification" has been made plural in
these guidelines should assure interworking among IP layer and lower instances where it seems to refer to notifications rather than the
layer congestion notification mechanisms, whether specified by the IETF mechanism; here is an example. Please review. (We note there were
or other standards bodies. This document is included in BCP 89 and updates 4 instances of plural in the original.)
the single paragraph of advice to subnetwork designers about ECN in
Section 13 of RFC 3819, by replacing it with a reference to the whole of Original:
this document.</t> Then the
IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the
transport layer (L4)
Current:
Then, the IP internetwork layer can act as a portability layer to
carry congestion notifications from non-IP-aware congested nodes up to the
transport layer (L4).
-->
Then, the IP internetwork layer can act as a portability layer to carry
congestion notifications from non-IP-aware congested nodes up to the transport
layer (L4). Following these guidelines should assure interworking among IP
layer and lower-layer congestion notification mechanisms specified by the IETF
or other standards bodies. This document is included in BCP 89 and updates the
single paragraph of advice to subnetwork designers about Explicit Congestion
Notification (ECN) in Section 13 of RFC 3819 by replacing it with a reference
to this document.</t>
</abstract> </abstract>
</front> </front>
<!-- ================================================================ -->
<middle> <middle>
<!-- ================================================================ -->
<section anchor="ecnencap_Introduction" numbered="true" toc="default"> <section anchor="ecnencap_Introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The benefits of Explicit Congestion Notification (ECN) described in <t>The benefits of Explicit Congestion Notification (ECN) described in
<xref target="RFC8087" format="default"/> and summarized below can only be fully realized <xref target="RFC8087" format="default"/> and summarized below can only be fully realized
if support for ECN is added to the relevant subnetwork technology, as if support for ECN is added to the relevant subnetwork technology, as
well as to IP. When a lower layer buffer drops a packet obviously it well as to IP. When a lower-layer buffer drops a packet, it obviously
does not just drop at that layer; the packet disappears from all layers. does not just drop at that layer; the packet disappears from all layers.
In contrast, when active queue management (AQM) at a lower layer marks a In contrast, when active queue management (AQM) at a lower layer marks a
packet with ECN, the marking needs to be explicitly propagated up the packet with ECN, the marking needs to be explicitly propagated up the
layers. The same is true if AQM marks the outer header of a packet that layers. The same is true if AQM marks the outer header of a packet that
encapsulates inner tunnelled headers. Forwarding ECN is not as encapsulates inner tunnelled headers. Forwarding ECN is not as
straightforward as other headers because it has to be assumed ECN may be straightforward as other headers because it has to be assumed ECN may be
only partially deployed. If a lower layer header that contains ECN only partially deployed. If a lower-layer header that contains ECN
congestion indications is stripped off by a subnet egress that is not congestion indications is stripped off by a subnet egress that is not
ECN-aware, or if the ultimate receiver or sender is not ECN-aware, ECN-aware, or if the ultimate receiver or sender is not ECN-aware,
congestion needs to be indicated by dropping the packet, not marking congestion needs to be indicated by dropping the packet, not marking
it.</t> it.</t>
<t>The purpose of this document is to guide the addition of congestion <!-- [rfced] How may this sentence be rephrased for clarity?
notification to any subnet technology or tunnelling protocol, so that Specifically, what does "it" refer to in "it will propagate"?
lower layer AQM algorithms can signal congestion explicitly and it will
propagate consistently into encapsulated (higher layer) headers, Original:
otherwise the signals will not reach their ultimate destination.</t> The purpose of this document is to guide the addition of congestion
notification to any subnet technology or tunnelling protocol, so that
lower layer AQM algorithms can signal congestion explicitly and it
will propagate consistently into encapsulated (higher layer) headers,
otherwise the signals will not reach their ultimate destination.
Perhaps:
The purpose of this document is to guide the addition of congestion
notifications to any subnet technology or tunnelling protocol so that
lower-layer AQM algorithms can signal congestion explicitly and that signal
can be propagated consistently into encapsulated (higher-layer)
headers. Otherwise, the signals will not reach their ultimate destination.
-->
<t>The purpose of this document is to guide the addition of congestion
notifications to any subnet technology or tunnelling protocol so that
lower-layer AQM algorithms can signal congestion explicitly and it will
propagate consistently into encapsulated (higher-layer) headers;
otherwise, the signals will not reach their ultimate destination.</t>
<t>ECN is defined in the IP header (IPv4 and IPv6) <xref target="RFC3168" format="default"/> <t>ECN is defined in the IP header (IPv4 and IPv6) <xref target="RFC3168" format="default"/>
to allow a resource to notify the onset of queue build-up without having to allow a resource to notify the onset of queue buildup without having
to drop packets, by explicitly marking a proportion of packets with the to drop packets by explicitly marking a proportion of packets with the
congestion experienced (CE) codepoint.<!--In the layered model of communic congestion experienced (CE) codepoint.
ation, each layer accepts requests to forward PDUs and eventually returns <!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
<!--In the layered model of communication, each layer accepts requests to forwar
d PDUs and eventually returns
a status code to the higher layer. Without ECN, each layer returns either a 'del ivered' status code or an a status code to the higher layer. Without ECN, each layer returns either a 'del ivered' status code or an
implicit 'not delivered'. Explicit notification of congestion adds a useful 'del ivered but congestion implicit 'not delivered'. Explicit notification of congestion adds a useful 'del ivered but congestion
experienced' status code to each layer interface.--> experienced' status code to each layer interface.-->
</t> </t>
<t>Given a suitable marking scheme, ECN removes nearly all congestion <t>Given a suitable marking scheme, ECN removes nearly all congestion
loss and it cuts delays for two main reasons: </t> loss and it cuts delays for two main reasons: </t>
<ul spacing="normal"> <ul spacing="normal">
<li>It avoids the delay when recovering from congestion losses, which <li>It avoids the delay when recovering from congestion losses, which
particularly benefits small flows or real-time flows, making their particularly benefits small flows or real-time flows, making their
delivery time predictably short <xref target="RFC2884" format="default delivery time predictably short <xref target="RFC2884" format="default
"/>;</li> "/>.</li>
<li>As ECN is used more widely by end-systems, it will gradually <li>As ECN is used more widely by end systems, it will gradually
remove the need to configure a degree of delay into buffers before remove the need to configure a degree of delay into buffers before
they start to notify congestion (the cause of bufferbloat). This is they start to notify congestion (the cause of bufferbloat).
This is
because drop involves a trade-off between sending a timely signal because drop involves a trade-off between sending a timely signal
and trying to avoid impairment, whereas ECN is solely a signal not and trying to avoid impairment, whereas ECN is solely a signal and not
an impairment, so there is no harm triggering it earlier.</li> an impairment, so there is no harm triggering it earlier.</li>
</ul> </ul>
<t>Some lower layer technologies (e.g. MPLS, Ethernet) are used to form <t>Some lower-layer technologies (e.g., MPLS, Ethernet) are used to form
subnetworks with IP-aware nodes only at the edges. These networks are subnetworks with IP-aware nodes only at the edges. These networks are
often sized so that it is rare for interior queues to overflow. However, often sized so that it is rare for interior queues to overflow. However,
until recently this was more due to the inability of TCP to saturate the until recently, this was more due to the inability of TCP to saturate the
links. For many years, fixes such as window scaling <xref target="RFC7323" links. For many years, fixes such as window scaling <xref target="RFC7323"
format="default"/> proved hard to deploy. And the Reno variant of TCP format="default"/> proved hard to deploy. The Reno variant of TCP
has remained in widespread use despite its inability to scale to high has remained in widespread use despite its inability to scale to high
flow rates. However, now that modern operating systems are finally flow rates. However, now that modern operating systems are finally
capable of saturating interior links, even the buffers of capable of saturating interior links, even the buffers of
well-provisioned interior switches will need to signal episodes of well-provisioned interior switches will need to signal episodes of
queuing.</t> queuing.</t>
<t>Propagation of ECN is defined for MPLS <xref target="RFC5129" format="d <t>Propagation of ECN is defined for MPLS <xref target="RFC5129" format="d
efault"/>, and efault"/> and TRILL <xref target="RFC7780" format="default"/> <xref target="RFC9
has been defined for TRILL <xref target="RFC7780" format="default"/>, <xre 600" format="default"/>, but it has yet to be defined for
f target="I-D.ietf-trill-ecn-support" format="default"/>, but it remains to be d
efined for
a number of other subnetwork technologies.</t> a number of other subnetwork technologies.</t>
<t>Similarly, ECN propagation is yet to be defined for many tunnelling <t>Similarly, ECN propagation is yet to be defined for many tunnelling
protocols. <xref target="RFC6040" format="default"/> defines how ECN shoul d be propagated protocols. <xref target="RFC6040" format="default"/> defines how ECN shoul d be propagated
for IP-in-IPv4 <xref target="RFC2003" format="default"/>, IP-in-IPv6 <xref for IP-in-IPv4 <xref target="RFC2003" format="default"/>, IP-in-IPv6 <xref
target="RFC2473" format="default"/> and IPsec <xref target="RFC4301" format="de target="RFC2473" format="default"/>, and IPsec <xref target="RFC4301" format="d
fault"/> tunnels, but there efault"/> tunnels, but there
are numerous other tunnelling protocols with a shim and/or a layer 2 are numerous other tunnelling protocols with a shim and/or a Layer 2 (L2)
header between two IP headers (IPv4 or IPv6). Some address ECN propagation header between two IP headers (IPv4 or IPv6). Some address ECN propagation
between the IP headers, but many do not. This document gives guidance on between the IP headers, but many do not.
<!--[rfced] Please clarify "IP-shim-(L2)-IP protocols".
How may it be written out? Based on the preceding text,
perhaps L2 is in parentheses to indicate that it is an option.
Current:
This document gives guidance on how to address ECN propagation for
future tunnelling protocols, and a companion Standards Track
specification [RFC9601] updates existing IP-shim-(L2)-IP protocols
that are under IETF change control and still widely used.
We note that RFC-to-be 9601 only used the term "IP-shim-(L2)-IP"
in the abbreviated title. Perhaps this shorthand means
"IP-shim-IP or IP-L2-IP" or "IP-in-IP tunnels that rely on
shim headers or L2 protocols" or otherwise.
-->
This document gives guidance on
how to address ECN propagation for future tunnelling protocols, and a how to address ECN propagation for future tunnelling protocols, and a
companion standards track specification <xref target="I-D.ietf-tsvwg-rfc60 40update-shim" format="default"/> updates those existing companion Standards Track specification <xref target="RFC9601" format="def ault"/> updates existing
IP-shim-(L2)-IP protocols that are under IETF change control and still IP-shim-(L2)-IP protocols that are under IETF change control and still
widely used.</t> widely used.</t>
<t>Incremental deployment is the most delicate aspect when adding <t>Incremental deployment is the most delicate aspect when adding
support for ECN. The original ECN protocol in IP <xref target="RFC3168" fo rmat="default"/> was carefully designed so that a congested buffer support for ECN. The original ECN protocol in IP <xref target="RFC3168" fo rmat="default"/> was carefully designed so that a congested buffer
would not mark a packet (rather than drop it) unless both source and would not mark a packet (rather than drop it) unless both source and
destination hosts were ECN-capable. Otherwise, its congestion markings destination hosts were ECN-capable. Otherwise, its congestion markings
would never be detected and congestion would just build up further. would never be detected and congestion would just build up further.
However, to support congestion marking below the IP layer or within However, to support congestion marking below the IP layer or within
tunnels, it is not sufficient to only check that the two layer 4 tunnels, it is not sufficient to only check that the two layer 4
transport end-points support ECN; correct operation also depends on the transport endpoints support ECN; correct operation also depends on the
decapsulator at each subnet or tunnel egress faithfully propagating decapsulator at each subnet or tunnel egress faithfully propagating
congestion notifications to the higher layer. Otherwise, a legacy congestion notifications to the higher layer.
decapsulator might silently fail to propagate any ECN signals from the <!-- [rfced] Should "outer" read as "outer header" here for clarity?
outer to the forwarded header. Then the lost signals would never be
detected and again congestion would build up further. The guidelines Original:
given later require protocol designers to carefully consider incremental Otherwise, a legacy decapsulator might silently fail to propagate
deployment, and suggest various safe approaches for different any ECN signals from the outer to the forwarded header.
circumstances.</t>
<t>Of course, the IETF does not have standards authority over every link Perhaps:
layer protocol. So this document gives guidelines for designing Otherwise, a legacy decapsulator might silently fail to propagate any
propagation of congestion notification across the interface between IP ECN signals from the outer header to the forwarded header.
and protocols that may encapsulate IP (i.e. that can be layered beneath -->
IP). Each lower layer technology will exhibit different issues and Otherwise, a legacy decapsulator might silently fail to propagate any ECN
compromises, so the IETF or the relevant standards body must be free to signals from the outer to the forwarded header. Then, the lost signals would
define the specifics of each lower layer congestion notification scheme. never be detected and congestion would build up further. The guidelines given
Nonetheless, if the guidelines are followed, congestion notification later require protocol designers to carefully consider incremental deployment
should interwork between different technologies, using IP in its role as and suggest various safe approaches for different circumstances.</t>
a 'portability layer'.</t> <t>Of
<t>Therefore, the capitalized terms 'SHOULD' or 'SHOULD NOT' are often course, the IETF does not have standards authority over every link-layer
used in preference to 'MUST' or 'MUST NOT', because it is difficult to protocol; thus, this document gives guidelines for designing propagation of
congestion notifications across the interface between IP and protocols that may
encapsulate IP (i.e., that can be layered beneath IP). Each lower-layer
technology will exhibit different issues and compromises, so the IETF or the
relevant standards body must be free to define the specifics of each lower-layer
congestion notification scheme. Nonetheless, if the guidelines are
followed, congestion notifications should interwork between different
technologies using IP in its role as a 'portability layer'.</t>
<t>Therefore, the capitalized terms '<bcp14>SHOULD</bcp14>' or '<bcp14>SHO
ULD NOT</bcp14>' are often
used in preference to '<bcp14>MUST</bcp14>' or '<bcp14>MUST NOT</bcp14>' b
ecause it is difficult to
know the compromises that will be necessary in each protocol design. If know the compromises that will be necessary in each protocol design. If
a particular protocol design chooses not to follow a 'SHOULD (NOT)' a particular protocol design chooses not to follow a '<bcp14>SHOULD</bcp14
given in the advice below, it MUST include a sound justification.</t> >' or '<bcp14>SHOULD NOT</bcp14>'
<t>It has not been possible to give common guidelines for all lower given in the advice below, it <bcp14>MUST</bcp14> include a sound justific
layer technologies, because they do not all fit a common pattern. ation.</t>
Instead, they have been divided into a few distinct modes of operation: <t>It has not been possible to give common guidelines for all
feed-forward-and-upward; feed-upward-and-forward; feed-backward; and lower-layer technologies because they do not all fit a common pattern.
null mode. These modes are described in <xref target="ecnencap_Modes" form
at="default"/>, <!-- [rfced] We note that the "feed-forward-and-upward" and
then in the subsequent sections separate guidelines are given for each "feed-upward-and-forward" modes of operation in this sentence are
mode.</t> otherwise consistently referred to as "feed-forward-and-up" and
"feed-up-and-forward" in the document. FYI, we have updated this sentence
for consistency. Please let us know if that is not accurate.
Original:
Instead, they have been divided into a few distinct modes of
operation: feed-forward-and-upward; feed-upward-and-forward; feed-backward;
and null mode.
Current:
Instead, they have been divided into a few distinct modes of
operation: feed-forward-and-up, feed-up-and-forward, feed-backward, and null
mode.
-->
Instead, they have been divided into a few distinct modes of
operation: feed-forward-and-up, feed-up-and-forward,
feed-backward, and null mode. These modes are described in <xref
target="ecnencap_Modes" format="default"/>, and separate guidelines are
given for each mode in subsequent sections.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Update to RFC 3819</name> <name>Update to RFC 3819</name>
<t>This document updates the brief advice to subnetwork designers <t>This document updates the brief advice to subnetwork designers
about ECN in <xref section="13" target="RFC3819" format="default"/>, by replacing the about ECN in <xref section="13" target="RFC3819" format="default"/> by a dding this document (RFC 9599) as an informative reference and replacing the
last two paragraphs with the following sentence:</t> last two paragraphs with the following sentence:</t>
<ul empty="true" spacing="normal"> <blockquote>
<li>By following the guidelines in [this document], subnetwork By following the guidelines in [RFC9599], subnetwork
designers can enable a layer-2 protocol to participate in designers can enable a layer-2 protocol to participate in
congestion control without dropping packets via propagation of congestion control without dropping packets via propagation of
explicit congestion notification (ECN <xref target="RFC3168" format= Explicit Congestion Notification (ECN) <xref target="RFC3168" format
"default"/>) to ="default"/> to
receivers.</li> receivers.</blockquote>
</ul>
<t>and adding [this document] as an informative reference. {RFC
Editor: Please replace both instances of [this document] above with
the number of the present RFC when published.}</t>
</section> </section>
<section anchor="ecnencap_Scope" numbered="true" toc="default"> <section anchor="ecnencap_Scope" numbered="true" toc="default">
<name>Scope</name> <name>Scope</name>
<!-- [rfced] May we rephrase "explicit notification of congestion" as follows?
Original:
This document only concerns wire protocol processing of explicit
notification of congestion.
Perhaps:
This document only concerns wire protocol processing of ECN.
-->
<t>This document only concerns wire protocol processing of explicit <t>This document only concerns wire protocol processing of explicit
notification of congestion. It makes no changes or recommendations notification of congestion. It makes no changes or recommendations
concerning algorithms for congestion marking or for congestion concerning algorithms for congestion marking or congestion
response, because algorithm issues should be independent of the layer response because algorithm issues should be independent of the layer
the algorithm operates in.</t> that the algorithm operates in.</t>
<t>The default ECN semantics are described in <xref target="RFC3168" for mat="default"/> <t>The default ECN semantics are described in <xref target="RFC3168" for mat="default"/>
and updated by <xref target="RFC8311" format="default"/>. Also, the guid elines for AQM and updated by <xref target="RFC8311" format="default"/>. Also, the guid elines for Active Queue Management (AQM)
designers <xref target="RFC7567" format="default"/> clarify the semantic s of both drop designers <xref target="RFC7567" format="default"/> clarify the semantic s of both drop
and ECN signals from AQM algorithms. <xref target="RFC4774" format="defa ult"/> is the and ECN signals from AQM algorithms. <xref target="RFC4774" format="defa ult"/> is the
appropriate best current practice specification of how algorithms with appropriate best current practice specification of how algorithms with
alternative semantics for the ECN field can be partitioned from alternative semantics for the ECN field can be partitioned from
Internet traffic that uses the default ECN semantics. There are two Internet traffic that uses the default ECN semantics. There are two
main examples for how alternative ECN semantics have been defined in main examples for how alternative ECN semantics have been defined in
practice:</t> practice:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>RFC 4774 suggests using the ECN field in combination with a <li><xref target="RFC4774"/> suggests using the ECN field in combinati
Diffserv codepoint such as in PCN <xref target="RFC6660" format="def on with a
ault"/>, Voice Diffserv codepoint, such as in Pre-Congestion Notification (PCN) <xr
over 3G <xref target="UTRAN" format="default"/> or Voice over LTE (V ef target="RFC6660" format="default"/>, Voice
oLTE) <xref target="LTE-RA" format="default"/>;</li> over 3G <xref target="UTRAN" format="default"/>, or Voice over LTE (
<li>RFC 8311 suggests using the ECT(1) codepoint of the ECN field VoLTE) <xref target="LTE-RA" format="default"/>.</li>
to indicate alternative semantics such as for the experimental Low <li><xref target="RFC8311"/> suggests using the ECT(1) codepoint of th
Latency Low Loss Scalable throughput (L4S) service <xref target="RFC e ECN field
9331" format="default"/>).</li> to indicate alternative semantics, such as for the experimental Low
Latency, Low Loss, and Scalable throughput (L4S) service <xref targe
t="RFC9331" format="default"/>).</li>
</ul> </ul>
<t>The aim is that the default rules for encapsulating and <t>The aim is that the default rules for encapsulating and
decapsulating the ECN field are sufficiently generic that tunnels and decapsulating the ECN field are sufficiently generic that tunnels and
subnets will encapsulate and decapsulate packets without regard to how subnets will encapsulate and decapsulate packets without regard to how
algorithms elsewhere are setting or interpreting the semantics of the algorithms elsewhere are setting or interpreting the semantics of the
ECN field. <xref target="RFC6040" format="default"/> updates RFC 4774 to ECN field. <xref target="RFC6040" format="default"/> updates <xref targe
allow t="RFC4774"/> to allow
alternative encapsulation and decapsulation behaviours to be defined alternative encapsulation and decapsulation behaviors to be defined
for alternative ECN semantics. However, it reinforces the same point - for alternative ECN semantics. However, it reinforces the same point --
that it is far preferable to try to fit within the common ECN it is far preferable to try to fit within the common ECN
encapsulation and decapsulation behaviours, because expecting all encapsulation and decapsulation behaviors because expecting all
lower layer technologies and tunnels to be updated is likely to be lower-layer technologies and tunnels to be updated is likely to be
completely impractical.</t> completely impractical.</t>
<t>Alternative semantics for the ECN field can be defined to depend on <t>Alternative semantics for the ECN field can be defined to depend on
the traffic class indicated by the DSCP. Therefore, correct propagation the traffic class indicated by the Differentiated Services Code Point (D SCP). Therefore, correct propagation
of congestion signals could depend on correct propagation of the DSCP of congestion signals could depend on correct propagation of the DSCP
between the layers and along the path. For instance, if the meaning of between the layers and along the path. For instance, if the meaning of
the ECN field depends on the DSCP (as in PCN or VoLTE) and if the the ECN field depends on the DSCP (as in PCN or VoLTE) and the
outer DSCP is stripped on descapsulation, as in the pipe model of outer DSCP is stripped on descapsulation, as in the pipe model of
<xref target="RFC2983" format="default"/>, the special semantics of the ECN field would <xref target="RFC2983" format="default"/>, the special semantics of the ECN field would
be lost. Similarly, if the DSCP is changed at the boundary between be lost. Similarly, if the DSCP is changed at the boundary between
Diffserv domains, the special ECN semantics would also be lost. This Diffserv domains, the special ECN semantics would also be lost. This
is an important implication of the localized scope of most Diffserv is an important implication of the localized scope of most Diffserv
arrangements. In this document, correct propagation of traffic class arrangements. In this document, correct propagation of traffic class
information is assumed, while what 'correct' means and how it is information is assumed while the meaning of 'correct' and how it is
achieved is covered elsewhere (e.g. RFC 2983) and is outside the scope achieved is covered elsewhere (e.g., <xref target="RFC2983"/>) and is ou
of the present document.</t> tside the scope
of this document.</t>
<t>The guidelines in this document do ensure that common encapsulation <t>The guidelines in this document do ensure that common encapsulation
and decapsulation rules are sufficiently generic to cover cases where and decapsulation rules are sufficiently generic to cover cases where
ECT(1) is used instead of ECT(0) to identify alternative ECN semantics ECT(1) is used instead of ECT(0) to identify alternative ECN semantics
(as in L4S <xref target="RFC9331" format="default"/>) and where ECN mark (as in L4S <xref target="RFC9331" format="default"/>) and where ECN-mark
ing algorithms ing algorithms
use ECT(1) to encode 3 severity levels into the ECN field (e.g. PCN use ECT(1) to encode three severity levels into the ECN field (e.g., PCN
<xref target="RFC6660" format="default"/>) rather than the default of 2. <xref target="RFC6660" format="default"/>) rather than the default of tw
All these o. All these
different semantics for the ECN field work because it has been different semantics for the ECN field work because it has been
possible to define common default decapsulation rules that allow for possible to define common default decapsulation rules that allow for
all cases.</t> all cases.</t>
<t>Note that the guidelines in this document do not necessarily <t>Note that the guidelines in this document do not necessarily
require the subnet wire protocol to be changed to add support for require the subnet wire protocol to be changed to add support for
congestion notification. For instance, the Feed-Up-and-Forward Mode congestion notifications. For instance, the feed-up-and-forward mode
(<xref target="ecnencap_Up" format="default"/>) and the Null Mode (<xref (<xref target="ecnencap_Up" format="default"/>) and the null mode (<xref
target="ecnencap_Null" format="default"/>) do not. Another way to add congestio target="ecnencap_Null" format="default"/>) do not. Another way to add congestio
n n
notification without consuming header space in the subnet protocol notifications without consuming header space in the subnet protocol
might be to use a parallel control plane protocol.</t> might be to use a parallel control plane protocol.</t>
<t>This document focuses on the congestion notification interface <t>This document focuses on the congestion notification interface
between IP and lower layer or tunnel protocols that can encapsulate between IP and lower-layer or tunnel protocols that can encapsulate
IP, where the term 'IP' includes IPv4 or IPv6, unicast, multicast or IP, where the term 'IP' includes IPv4 or IPv6, unicast, multicast, or
anycast. However, it is likely that the guidelines will also be useful anycast.
when a lower layer protocol or tunnel encapsulates itself, e.g. <!-- [rfced] We note that "previously 802.1ah", "previously 802.1p", and
Ethernet MAC in MAC (<xref target="IEEE802.1Q" format="default"/>; previ "previously known as 802.1Qau" is written in instances where [IEEE802.1Q]
ously 802.1ah) is cited throughout the document (see below for an example). Is the added
context necessary for readers to understand the text? If not, we suggest
referencing the most up-to-date material and removing "previously X" from
each citation of [IEEE802.1Q]. See below for an example.
Original (Section 1.2):
However, it is likely that the guidelines will also be
useful when a lower layer protocol or tunnel encapsulates itself, e.g.
Ethernet MAC in MAC ([IEEE802.1Q]; previously 802.1ah) or when it encapsulates
other protocols.
Perhaps:
However, it is likely that the guidelines will also be useful when a
lower-layer protocol or tunnel encapsulates itself, e.g., Ethernet Media
Access Control (MAC) in MAC [IEEE802.1Q], or when it encapsulates other
protocols.
-->
However, it is likely that the guidelines will also be useful
when a lower-layer protocol or tunnel encapsulates itself, e.g.,
Ethernet Media Access Control (MAC) in MAC (<xref target="IEEE802.1Q" fo
rmat="default"/>; previously 802.1ah),
or when it encapsulates other protocols. In the feed-backward mode, or when it encapsulates other protocols. In the feed-backward mode,
propagation of congestion signals for multicast and anycast packets is propagation of congestion signals for multicast and anycast packets is
out-of-scope (because the complexity would make it unlikely to be out of scope (because the complexity would make it unlikely to be
attempted).</t> attempted).</t>
</section> </section>
</section> </section>
<!-- ================================================================ -->
<section anchor="ecnencap_Reqs_Language" numbered="true" toc="default"> <section anchor="ecnencap_Reqs_Language" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
/bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
bed in
BCP&nbsp;14 <xref target="RFC2119" format="default"/> BCP&nbsp;14 <xref target="RFC2119" format="default"/>
<xref target="RFC8174" format="default"/> when, and only when, they <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t>Further terminology used within this document:</t> <t>Further terminology used within this document:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Protocol data unit (PDU):</dt> <dt>Protocol data unit (PDU):</dt>
<dd>Information that is <dd>Information that is
delivered as a unit among peer entities of a layered network delivered as a unit among peer entities of a layered network
consisting of protocol control information (typically a header) and consisting of protocol control information (typically a header) and
possibly user data (payload) of that layer. The scope of this possibly user data (payload) of that layer. The scope of this
document includes layer 2 and layer 3 networks, where the PDU is document includes Layer 2 and Layer 3 networks, where the PDU is
respectively termed a frame or a packet (or a cell in ATM). PDU is a respectively termed a frame or a packet (or a cell in ATM). PDU is a
general term for any of these. This definition also includes a general term for any of these. This definition also includes a
payload with a shim header lying somewhere between layer 2 and payload with a shim header lying somewhere between layer 2 and
3.</dd> 3.</dd>
<dt>Transport:</dt> <dt>Transport:</dt>
<dd>The end-to-end transmission control <dd>The end-to-end transmission control function, conventionally
function, conventionally considered at layer-4 in the OSI reference considered at layer 4 in the OSI reference model. Given the audience
model. Given the audience for this document will often use the word for this document will often use the word transport to mean low-level
transport to mean low level bit carriage, whenever the term is used bit carriage, the term will be qualified whenever it is used,
it will be qualified, e.g. 'L4 transport'.</dd> e.g., 'L4 transport'.</dd>
<dt>Encapsulator:</dt> <dt>Encapsulator:</dt>
<dd>The link or tunnel endpoint function <dd>The link or tunnel endpoint function
that adds an outer header to a PDU (also termed the 'link ingress', that adds an outer header to a PDU (also termed the 'link ingress',
the 'subnet ingress', the 'ingress tunnel endpoint' or just the the 'subnet ingress', the 'ingress tunnel endpoint', or just the
'ingress' where the context is clear).</dd> 'ingress' where the context is clear).</dd>
<dt>Decapsulator:</dt> <dt>Decapsulator:</dt>
<dd>The link or tunnel endpoint function <dd>The link or tunnel endpoint function
that removes an outer header from a PDU (also termed the 'link that removes an outer header from a PDU (also termed the 'link
egress', the 'subnet egress', the 'egress tunnel endpoint' or just egress', the 'subnet egress', the 'egress tunnel endpoint', or just
the 'egress' where the context is clear).</dd> the 'egress' where the context is clear).</dd>
<dt>Incoming header:</dt> <dt>Incoming header:</dt>
<dd>The header of an arriving PDU before <dd>The header of an arriving PDU before
encapsulation.</dd> encapsulation.</dd>
<dt>Outer header:</dt> <dt>Outer header:</dt>
<dd>The header added to encapsulate a <dd>The header added to encapsulate a
PDU.</dd> PDU.</dd>
<dt>Inner header:</dt> <dt>Inner header:</dt>
<dd>The header encapsulated by the outer <dd>The header encapsulated by the outer
header.</dd> header.</dd>
<dt>Outgoing header:</dt> <dt>Outgoing header:</dt>
<dd>The header forwarded by the <dd>The header forwarded by the
decapsulator.</dd> decapsulator.</dd>
<dt>CE:</dt> <dt>CE:</dt>
<dd>Congestion Experienced <xref target="RFC3168" format="default"/></dd > <dd>Congestion Experienced <xref target="RFC3168" format="default"/></dd >
<dt>ECT:</dt> <dt>ECT:</dt>
<dd>ECN-Capable (L4) Transport <xref target="RFC3168" format="default"/> </dd> <dd>ECN-Capable (L4) Transport <xref target="RFC3168" format="default"/> </dd>
<dt>Not-ECT:</dt> <dt>Not-ECT:</dt>
<dd>Not ECN-Capable (L4) Transport <xref target="RFC3168" format="defaul t"/></dd> <dd>Not ECN-Capable (L4) Transport <xref target="RFC3168" format="defaul t"/></dd>
<dt>Load Regulator:</dt> <dt>Load Regulator:</dt>
<dd>For each flow of PDUs, the transport <!-- [rfced] Does the proposed text improve readability of the definition for
function that is capable of controlling the data rate. Typically "Load Regulator" without changing the intended meaning?
located at the data source, but in-path nodes can regulate load in
some congestion control arrangements (e.g. admission control, Original:
policing nodes or transport circuit-breakers <xref target="RFC8084" fo Load Regulator: For each flow of PDUs, the transport function that
rmat="default"/>). Note the term "a function capable of is capable of controlling the data rate.
controlling the load" deliberately includes a transport that does
not actually control the load responsively but ideally it ought to Perhaps:
(e.g. a sending application without congestion control that uses Load Regulator: The transport function that is capable of controlling
UDP).</dd> the data rate for each flow of PDUs.
-->
<dd>For each flow of PDUs, the transport function that is capable of
controlling the data rate. Typically located at the data source, but
in-path nodes can regulate load in some congestion control
arrangements (e.g., admission control, policing nodes, or transport
circuit-breakers <xref target="RFC8084" format="default"/>). Note that
"a function capable of controlling the load" deliberately
includes a transport that does not actually control the load
responsively, but ideally it ought to (e.g., a sending application
without congestion control that uses UDP).</dd>
<dt>ECN-PDU:</dt> <dt>ECN-PDU:</dt>
<dd>A PDU at the IP layer or below with a <dd>A PDU at the IP layer or below with a
capacity to signal congestion that is part of a congestion control capacity to signal congestion that is part of a congestion control
feedback loop within which all the nodes necessary to propagate the feedback loop within which all the nodes necessary to propagate the
signal back to the Load Regulator are capable of doing that signal back to the Load Regulator are capable of doing that
propagation. An IP packet with a non-zero ECN field implies that the propagation. An IP packet with a non-zero ECN field implies that the
endpoints are ECN-capable, so this would be an ECN-PDU. However, endpoints are ECN-capable, so this would be an ECN-PDU. However,
ECN-PDU is intended to be a general term for a PDU at lower layers, ECN-PDU is intended to be a general term for a PDU at lower layers,
as well as at the IP layer.</dd> as well as at the IP layer.</dd>
<dt>Not-ECN-PDU:</dt> <dt>Not-ECN-PDU:</dt>
<dd>A PDU at the IP layer or below that is <dd>A PDU at the IP layer or below that is
part of a congestion control feedback loop that is not capable of part of a congestion control feedback loop that is not capable of
propagating explicit congestion notification signals back to the Load propagating ECN signals back to the Load
Regulator, because at least one of the nodes necessary to propagate Regulator because at least one of the nodes necessary to propagate
the signals is incapable of doing that propagation. Note that this the signals is incapable of doing that propagation. Note that this
definition is a property of the feedback-loop, not necessarily of the definition is a property of the feedback loop, not necessarily of the
PDU itself, because in some protocols the PDU will self-describe the PDU itself; the PDU will self-describe the
property, but in others the property might be carried in a separate property in some protocols, but in others, the property might be carri
control-plane context that is somehow bound to the PDU.</dd> ed in a separate
control plane context that is somehow bound to the PDU.</dd>
</dl> </dl>
</section> </section>
<section anchor="ecnencap_Modes" numbered="true" toc="default"> <section anchor="ecnencap_Modes" numbered="true" toc="default">
<name>Modes of Operation</name> <name>Modes of Operation</name>
<t>This section sets down the different modes by which congestion <t>This section sets down the different modes by which congestion
information is passed between the lower layer and the higher one. It information is passed between the lower layer and the higher one. It
acts as a reference framework for the following sections, which give acts as a reference framework for the following sections that give
normative guidelines for designers of explicit congestion notification normative guidelines for designers of ECN protocols, taking each mode in
protocols, taking each mode in turn:</t> turn:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Feed-Forward-and-Up:</dt> <dt>Feed-Forward-and-Up:</dt>
<dd> <dd>
<t>Nodes feed forward congestion <t>Nodes feed forward congestion
notification towards the egress within the lower layer then up and notifications towards the egress within the lower layer, then up and
along the layers towards the end-to-end destination at the transport along the layers towards the end-to-end destination at the transport
layer. The following local optimisation is possible:</t> layer. The following local optimization is possible:</t>
<dl newline="false" spacing="normal"> <!--[rfced] This original document contained a mix of British and American
spelling (e.g., optimisation and minimize, behaviour and behavior).
FYI, this has been updated to the latter per the RFC Style Guide, with
the following exception.
Instances of 'tunnelling' will be changed to 'tunneling' except
where they appear in the titles of documents. We have not yet made this
update as it will make the diff file more noisy for review.
-->
<dl newline="false" spacing="normal">
<dt>Feed-Up-and-Forward:</dt> <dt>Feed-Up-and-Forward:</dt>
<dd>A lower layer switch feeds-up <dd>A lower-layer switch feeds up
congestion notification directly into the higher layer (e.g. congestion notifications directly into the higher layer (e.g.,
into the ECN field in the IP header), irrespective of whether into the ECN field in the IP header), irrespective of whether
the node is at the egress of a subnet.</dd> the node is at the egress of a subnet.</dd>
</dl> </dl>
</dd> </dd>
<dt>Feed-Backward:</dt> <dt>Feed-Backward:</dt>
<dd>Nodes feed back congestion signals <dd>Nodes feed back congestion signals
towards the ingress of the lower layer and (optionally) attempt to towards the ingress of the lower layer and (optionally) attempt to
control congestion within their own layer.</dd> control congestion within their own layer.</dd>
<dt>Null:</dt> <dt>Null:</dt>
<dd>Nodes cannot experience congestion at the lower <dd>Nodes cannot experience congestion at the lower
layer except at ingress nodes (which are IP-aware or equivalently layer except at ingress nodes (which are IP-aware or equivalently
higher-layer-aware).</dd> higher-layer-aware).</dd>
</dl> </dl>
<section anchor="ecnencap_Forward" numbered="true" toc="default"> <section anchor="ecnencap_Forward" numbered="true" toc="default">
<name>Feed-Forward-and-Up Mode</name> <name>Feed-Forward-and-Up Mode</name>
<t>Like IP and MPLS, many subnet technologies are based on <t>Like IP and MPLS, many subnet technologies are based on
self-contained protocol data units (PDUs) or frames sent unreliably. self-contained PDUs or frames sent unreliably.
They provide no feedback channel at the subnetwork layer, instead They provide no feedback channel at the subnetwork layer, instead
relying on higher layers (e.g. TCP) to feed back loss signals.</t> relying on higher layers (e.g., TCP) to feed back loss signals.</t>
<t>In these cases, ECN may best be supported by standardising explicit <t>In these cases, ECN may best be supported by standardising explicit
notification of congestion into the lower layer protocol that carries notification of congestion into the lower-layer protocol that carries
the data forwards. Then a specification is needed for how the egress the data forwards. Then, a specification is needed for how the egress
of the lower layer subnet propagates this explicit signal into the of the lower-layer subnet propagates this explicit signal into the
forwarded upper layer (IP) header. This signal continues forwards forwarded upper-layer (IP) header. This signal continues forwards
until it finally reaches the destination transport (at L4). Then until it finally reaches the destination transport (at L4).
typically the destination will feed this congestion notification back Typically, the destination will feed this congestion notification back
to the source transport using an end-to-end protocol (e.g. TCP). This to the source transport using an end-to-end protocol (e.g., TCP). This
is the arrangement that has already been used to add ECN to IP-in-IP is the arrangement that has already been used to add ECN to IP-in-IP
tunnels <xref target="RFC6040" format="default"/>, IP-in-MPLS and MPLS-i n-MPLS <xref target="RFC5129" format="default"/>.</t> tunnels <xref target="RFC6040" format="default"/>, IP-in-MPLS, and MPLS- in-MPLS <xref target="RFC5129" format="default"/>.</t>
<t>This mode is illustrated in <xref target="ecnencap_Fig_Feed-Forward-a nd-Up" format="default"/>. Along the middle of the <t>This mode is illustrated in <xref target="ecnencap_Fig_Feed-Forward-a nd-Up" format="default"/>. Along the middle of the
figure, layers 2, 3 and 4 of the protocol stack are shown, and one figure, layers 2, 3, and 4 of the protocol stack are shown. One
packet is shown along the bottom as it progresses across the network packet is shown along the bottom as it progresses across the network
from source to destination, crossing two subnets connected by a from source to destination, crossing two subnets connected by a
router, and crossing two switches on the path across each subnet. router and crossing two switches on the path across each subnet.
Congestion at the output of the first switch (shown as *) leads to a Congestion at the output of the first switch (shown as *) leads to a
congestion marking in the L2 header (shown as C in the illustration of congestion marking in the L2 header (shown as C in the illustration of
the packet). The chevrons show the progress of the resulting the packet). The chevrons show the progress of the resulting
congestion indication. It is propagated from link to link across the congestion indication. It is propagated from link to link across the
subnet in the L2 header, then when the router removes the marked L2 subnet in the L2 header. Then, when the router removes the marked L2
header, it propagates the marking up into the L3 (IP) header. The header, it propagates the marking up into the L3 (IP) header. The
router forwards the marked L3 header into subnet B. The L2 protocol used router forwards the marked L3 header into subnet B. The L2 protocol used
in subnet B does not support ECN, but the signal proceeds across it in in subnet B does not support ECN, but the signal proceeds across it in
the L3 header.</t> the L3 header.</t>
<t>Note that there is no implication that each 'C' marking is encoded <t>Note that there is no implication that each 'C' marking is encoded
the same; a different encoding might be used for the 'C' marking in the same; a different encoding might be used for the 'C' marking in
each protocol.</t> each protocol.</t>
<t>Finally, for completeness, we show the L3 marking arriving at the <t>Finally, for completeness, we show the L3 marking arriving at the
destination, where the host transport protocol (e.g. TCP) feeds it destination, where the host transport protocol (e.g., TCP) feeds it
back to the source in the L4 acknowledgement (the 'C' at L4 in the back to the source in the L4 acknowledgement (the 'C' at L4 in the
packet at the top of the diagram).</t> packet at the top of the diagram).</t>
<figure anchor="ecnencap_Fig_Feed-Forward-and-Up"> <figure anchor="ecnencap_Fig_Feed-Forward-and-Up">
<name>Feed-Forward-and-Up Mode</name> <name>Feed-Forward-and-Up Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
_ _ _ _ _ _
/_______ | | |C| ACK Packet (V) /_______ | | |C| ACK Packet (V)
\ |_|_|_| \ |_|_|_|
+---+ layer: 2 3 4 header +---+ +---+ layer: 2 3 4 header +---+
| <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4 | <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4
| | +---+ | ^ | | | +---+ | ^ |
| | . . . . . . Packet U. . | >>|>>> Packet U >>>>>>>>>>>>|>^ |L3 | | . . . . . . Packet U. . | >>|>>> Packet U >>>>>>>>>>>>|>^ |L3
| | +---+ +---+ | ^ | +---+ +---+ | | | | +---+ +---+ | ^ | +---+ +---+ | |
| | | *|>>>>>|>>>|>>>>>|>^ | | | | | | |L2 | | | *|>>>>>|>>>|>>>>>|>^ | | | | | | |L2
|___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___| |___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___|
source subnet A router subnet B dest source subnet A router subnet B dest
__ _ _ _| __ _ _ _| __ _ _| __ _ _ _| __ _ _ _| __ _ _ _| __ _ _| __ _ _ _|
| | | | | | | | |C| | | |C| | | |C| | Data________\ | | | | | | | | |C| | | |C| | | |C| | Data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) / |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) /
layer:4 3 2A 4 3 2A 4 3 4 3 2B layer:4 3 2A 4 3 2A 4 3 4 3 2B
header]]></artwork> header
]]></artwork>
</figure> </figure>
<t>Of course, modern networks are rarely as simple as this text-book <t>Of course, modern networks are rarely as simple as this textbook
example, often involving multiple nested layers. For example, a 3GPP example, often involving multiple nested layers. For example, a Third
mobile network may have two IP-in-IP (GTP <xref target="GTPv1" format="d Generation Partnership Project (3GPP) mobile network may have two
efault"/>) IP-in-IP (GTP) <xref target="GTPv1" format="default"/> tunnels in
tunnels in series and an MPLS backhaul between the base station and series and an MPLS backhaul between the base station and the first
the first router. Nonetheless, the example illustrates the general router. Nonetheless, the example illustrates the general idea of
idea of feeding congestion notification forward then upward whenever a feeding congestion notifications forward then upward whenever a header
header is removed at the egress of a subnet.</t> is removed at the egress of a subnet.</t>
<t>Note that the FECN (forward ECN ) bit in Frame Relay <xref target="Bu <t>Note that the Forward Explicit Congestion Notification (FECN) bit in
ck00" format="default"/> and the explicit forward congestion indication (EFCI Frame Relay <xref target="Buck00" format="default"/> and the Explicit Forward Co
<xref target="ITU-T.I.371" format="default"/>) bit in ATM user data cell ngestion Indication (EFCI)
s follow a <xref target="ITU-T.I.371" format="default"/> bit in ATM user data cells
feed-forward pattern. However, in ATM, this arrangement is only part follow a
feed-forward pattern.
<!-- [rfced] May we change "to interface to" to "to interface with" here?
Original:
However, in ATM,
this arrangement is only part of a feed-forward-and-backward pattern
at the lower layer, not feed-forward-and-up out of the lower layer -
the intention was never to interface to IP ECN at the subnet egress.
Perhaps:
However, in ATM,
this arrangement is only part of a feed-forward-and-backward pattern
at the lower layer, not feed-forward-and-up out of the lower layer -
the intention was never to interface with IP ECN at the subnet egress.
-->
However, in ATM, this arrangement is only part
of a feed-forward-and-backward pattern at the lower layer, not of a feed-forward-and-backward pattern at the lower layer, not
feed-forward-and-up out of the lower layer &mdash; the intention was feed-forward-and-up out of the lower layer -- the intention was
never to interface to IP ECN at the subnet egress. To our knowledge, never to interface to IP ECN at the subnet egress.
<!-- [rfced] The first sentence of paragraph 6 in Section 3.1 refers to "FECN"
as a bit in Frame Relay. Should the following sentence be updated to
reflect this?
Original (Section 3.1):
Note that the FECN (forward ECN ) bit in Frame Relay [Buck00] and the
explicit forward congestion indication (EFCI [ITU-T.I.371]) bit in
ATM user data cells follow a feed-forward pattern.
Original:
To our knowledge, Frame Relay FECN is solely used to detect where
more capacity should be provisioned.
Perhaps:
To our knowledge, the FECN bit in Frame Relay is solely used to detect
where more capacity should be provisioned.
-->
To our knowledge,
Frame Relay FECN is solely used to detect where more capacity should Frame Relay FECN is solely used to detect where more capacity should
be provisioned.</t> be provisioned.</t>
</section> </section>
<section anchor="ecnencap_Up" numbered="true" toc="default"> <section anchor="ecnencap_Up" numbered="true" toc="default">
<name>Feed-Up-and-Forward Mode</name> <name>Feed-Up-and-Forward Mode</name>
<t>Ethernet is particularly difficult to extend incrementally to <t>Ethernet is particularly difficult to extend incrementally to
support explicit congestion notification. One way to support ECN in support ECN. One way to support ECN in such cases is to use so-called
such cases has been to use so called 'layer-3 switches'. These are 'Layer 3 switches'. These are Ethernet switches that dig into the
Ethernet switches that dig into the Ethernet payload to find an IP Ethernet payload to find an IP header and manipulate or act on certain
header and manipulate or act on certain IP fields (specifically IP fields (specifically Diffserv and ECN). For instance, in Data
Diffserv &amp; ECN). For instance, in Data Center TCP <xref target="RFC8 Center TCP <xref target="RFC8257" format="default"/>, Layer 3 switches
257" format="default"/>, layer-3 switches are configured to mark the ECN are configured to mark the ECN field of the IP header within the
field of the IP header within the Ethernet payload when their output Ethernet payload when their output buffer becomes congested. With
buffer becomes congested. With respect to switching, a layer-3 switch respect to switching, a Layer 3 switch acts solely on the addresses in
acts solely on the addresses in the Ethernet header; it does not use the Ethernet header; it does not use IP addresses and it does not
IP addresses, and it does not decrement the TTL field in the IP decrement the TTL field in the IP header.</t>
header.</t>
<figure anchor="ecnencap_Fig_Feed-Up"> <figure anchor="ecnencap_Fig_Feed-Up">
<name>Feed-Up-and-Forward Mode</name> <name>Feed-Up-and-Forward Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
_ _ _ _ _ _
/_______ | | |C| ACK packet (V) /_______ | | |C| ACK packet (V)
\ |_|_|_| \ |_|_|_|
+---+ layer: 2 3 4 header +---+ +---+ layer: 2 3 4 header +---+
| <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4 | <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4
| | +---+ | ^ | | | +---+ | ^ |
| | . . . >>>> Packet U >>>|>>>|>>> Packet U >>>>>>>>>>>>|>^ |L3 | | . . . >>>> Packet U >>>|>>>|>>> Packet U >>>>>>>>>>>>|>^ |L3
| | +--^+ +---+ | v| +---+ +---+ | ^ | | | +--^+ +---+ | v| +---+ +---+ | ^ |
| | | *| | | | >|>>>>>|>>>|>>>>>|>>>|>>>>>|>^ |L2 | | | *| | | | >|>>>>>|>>>|>>>>>|>>>|>>>>>|>^ |L2
|___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___| |___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___|
source subnet E router subnet F dest source subnet E router subnet F dest
__ _ _ _| __ _ _ _| __ _ _| __ _ _ _| __ _ _ _| __ _ _ _| __ _ _| __ _ _ _|
| | | | | | | |C| | | | |C| | | |C|C| Data________\ | | | | | | | |C| | | | |C| | | |C|C| Data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) / |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) /
layer:4 3 2 4 3 2 4 3 4 3 2 layer:4 3 2 4 3 2 4 3 4 3 2
header]]></artwork> header
]]></artwork>
</figure> </figure>
<t>By comparing <xref target="ecnencap_Fig_Feed-Up" format="default"/> w <t>By comparing <xref target="ecnencap_Fig_Feed-Up" format="default"/>
ith <xref target="ecnencap_Fig_Feed-Forward-and-Up" format="default"/>, it can b with <xref target="ecnencap_Fig_Feed-Forward-and-Up"
e seen that format="default"/>, it can be seen that subnet E (perhaps a subnet of
subnet E (perhaps a subnet of layer-3 Ethernet switches) works in Layer 3 Ethernet switches) works in feed-up-and-forward mode by
feed-up-and-forward mode by notifying congestion directly into L3 at notifying congestion directly into L3 at the point of congestion, even
the point of congestion, even though the congested switch does not though the congested switch does not otherwise act at L3.
otherwise act at L3. In this example, the technology in subnet F (e.g. <!-- [rfced] For clarity, may we split this sentence into two?
MPLS) does support ECN natively, so when the router adds the layer-2 Also, perhaps changing from 'natively' to 'innately'; see the final
header it copies the ECN marking from L3 to L2 as well, as shown by the question regarding inclusive language.
'C's in both layers.</t>
Original:
In this example, the technology in subnet F (e.g. MPLS) does
support ECN natively, so when the router adds the layer-2 header it
copies the ECN marking from L3 to L2 as well, as shown by the 'C's in
both layers.
Perhaps:
In this example, the technology in subnet F (e.g., MPLS) innately
supports ECN. When the router adds the Layer 2 header, it
copies the ECN marking from L3 to L2 as well, as shown by the 'C's in
both layers.
-->
In this example, the technology in subnet F (e.g., MPLS) does support ECN
natively, so when the router adds the Layer 2 header it copies the ECN marking
from L3 to L2 as well, as shown by the 'C's in both layers.</t>
</section> </section>
<section anchor="ecnencap_Backward" numbered="true" toc="default"> <section anchor="ecnencap_Backward" numbered="true" toc="default">
<name>Feed-Backward Mode</name> <name>Feed-Backward Mode</name>
<t>In some layer 2 technologies, explicit congestion notification has <t>In some Layer 2 technologies, ECN has
been defined for use internally within the subnet with its own been defined for use internally within the subnet with its own
feedback and load regulation, but typically the interface with IP for feedback and load regulation; typically, the interface with IP for
ECN has not been defined.</t> ECN has not been defined.</t>
<t>For instance, for the available bit-rate (ABR) service in ATM, the <!-- [rfced] To improve readability, may we rephrase this
sentence as follows and update "tending" to past tense (to match "was")?
Original:
For instance, for the available bit-rate (ABR) service in ATM, the
relative rate mechanism was one of the more popular mechanisms for
managing traffic, tending to supersede earlier designs.
Perhaps:
For instance, the relative rate mechanism was one of the more popular
ways to manage traffic for the Available Bit Rate (ABR) service in ATM,
and it tended to supersede earlier designs.
-->
<t>For instance, for the Available Bit Rate (ABR) service in ATM, the
relative rate mechanism was one of the more popular mechanisms for relative rate mechanism was one of the more popular mechanisms for
managing traffic, tending to supersede earlier designs. In this managing traffic, tending to supersede earlier designs. In this
approach ATM switches send special resource management (RM) cells in approach, ATM switches send special resource management (RM) cells in
both the forward and backward directions to control the ingress rate both the forward and backward directions to control the ingress rate
of user data into a virtual circuit. If a switch buffer is approaching of user data into a virtual circuit. If a switch buffer is approaching
congestion or is congested it sends an RM cell back towards the congestion or is congested, it sends an RM cell back towards the
ingress with respectively the No Increase (NI) or Congestion ingress with the No Increase (NI) or Congestion
Indication (CI) bit set in its message type field <xref target="ATM-TM-A Indication (CI) bit set in its message type field <xref target="ATM-TM-A
BR" format="default"/>. The ingress then holds or decreases its sending BR" format="default"/>, respectively. The ingress then holds or decreases its se
nding
bit-rate accordingly.</t> bit-rate accordingly.</t>
<figure anchor="ecnencap_Fig_Feed-Backward"> <figure anchor="ecnencap_Fig_Feed-Backward">
<name>Feed-Backward Mode</name> <name>Feed-Backward Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
_ _ _ _ _ _
/_______ | | |C| ACK packet (X) /_______ | | |C| ACK packet (X)
\ |_|_|_| \ |_|_|_|
+---+ layer: 2 3 4 header +---+ +---+ layer: 2 3 4 header +---+
| <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet X <<<<<<<<<<<<<|<< |L4 | <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet X <<<<<<<<<<<<<|<< |L4
| | +---+ | ^ | | | +---+ | ^ |
| | | *|>>> Packet W >>>>>>>>>>>>|>^ |L3 | | | *|>>> Packet W >>>>>>>>>>>>|>^ |L3
| | +---+ +---+ | | +---+ +---+ | | | | +---+ +---+ | | +---+ +---+ | |
| | | | | | | <|<<<<<|<<<|<(V)<|<<<| | |L2 | | | | | | | <|<<<<<|<<<|<(V)<|<<<| | |L2
| | . . | . |Packet U | . . | . | . . | . | . . | .*| . . | |L2 | | . . | . |Packet U | . . | . | . . | . | . . | .*| . . | |L2
|___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___| |___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___|
skipping to change at line 580 skipping to change at line 767
\ |_| cell/frame (V) \ |_| cell/frame (V)
2 2
__ _ _ _ __ _ _ _ __ _ _ __ _ _ _ earlier __ _ _ _ __ _ _ _ __ _ _ __ _ _ _ earlier
| | | | | | | | | | | | | | | | | | | data________\ | | | | | | | | | | | | | | | | | | | data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (U) / |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (U) /
layer: 4 3 2 4 3 2 4 3 4 3 2 layer: 4 3 2 4 3 2 4 3 4 3 2
header header
]]></artwork> ]]></artwork>
</figure> </figure>
<t>ATM's feed-backward approach does not fit well when layered beneath <t>ATM's feed-backward approach does not fit well when layered beneath
IP's feed-forward approach &mdash; unless the initial data source is IP's feed-forward approach unless the initial data source is
the same node as the ATM ingress. <!--(which would be the case if ATM ha d achieved its aspiration of becoming the global internetwork standard, the same node as the ATM ingress. <!--(which would be the case if ATM ha d achieved its aspiration of becoming the global internetwork standard,
rather than just a subnetwork technology)--> rather than just a subnetwork technology)-->
<xref target="ecnencap_Fig_Feed-Backward" format="default"/> shows the feed-backward approach <xref target="ecnencap_Fig_Feed-Backward" format="default"/> shows the feed-backward approach
being used in subnet H. If the final switch on the path is congested being used in subnet H.
(*), it does not feed-forward any congestion indications on packet If the final switch on the path is congested
(U). Instead it sends a control cell (V) back to the router at the ATM (*), it does not feed forward any congestion indications on the packet
(U). Instead, it sends a control cell (V) back to the router at the ATM
ingress.</t> ingress.</t>
<t>However, the backward feedback does not reach the original data <t>However, the backward feedback does not reach the original data
source directly because IP does not support backward feedback (and source directly because IP does not support backward feedback (and
subnet G is independent of subnet H). Instead, the router in the subnet G is independent of subnet H). Instead, the router in the
middle throttles down its sending rate but the original data sources middle throttles down its sending rate, but the original data sources
don't reduce their rates. The resulting rate mismatch causes the don't reduce their rates.
The resulting rate mismatch causes the
middle router's buffer at layer 3 to back up until it becomes middle router's buffer at layer 3 to back up until it becomes
congested, which it signals forwards on later data packets at layer 3 congested, which it signals forwards on later data packets at layer 3
(e.g. packet W). Note that the forward signal from the middle router (e.g., packet W). Note that the forward signal from the middle router
is not triggered directly by the backward signal. Rather, it is is not triggered directly by the backward signal. Rather, it is
triggered by congestion resulting from the middle router's mismatched triggered by congestion resulting from the middle router's mismatched
rate response to the backward signal.</t> rate response to the backward signal.</t>
<t>In response to this later forward signalling, end-to-end feedback <t>In response to this later forward signalling, end-to-end feedback
at layer-4 finally completes the tortuous path of congestion at layer 4 finally completes the tortuous path of congestion
indications back to the origin data source, as before.</t> indications back to the origin data source as before.</t>
<t>Quantized congestion notification (QCN <xref target="IEEE802.1Q" form <t>Quantized Congestion Notification (QCN) <xref target="IEEE802.1Q" for
at="default"/>) mat="default"/>
would suffer from similar problems if extended to multiple subnets. would suffer from similar problems if extended to multiple subnets.
However, from the start QCN was clearly characterized as solely However, QCN was clearly characterized as solely
applicable to a single subnet (see <xref target="ecnencap_Guidelines_Bac applicable to a single subnet from the start (see <xref target="ecnencap
kward" format="default"/>).</t> _Guidelines_Backward" format="default"/>).</t>
<!--To summarise so far, feeding congestion notification backwards can r each the source faster, but only <!--To summarise so far, feeding congestion notification backwards can r each the source faster, but only
if the congested subnet is directly connected to the original data source. In a more general case, if the congested subnet is directly connected to the original data source. In a more general case,
feedback takes a tortuous path part-way backwards, which can lead to queuing at the higher layer in feedback takes a tortuous path part-way backwards, which can lead to queuing at the higher layer in
the middle of the network, which can in turn trigger a much-delayed feed-forward signal, which then the middle of the network, which can in turn trigger a much-delayed feed-forward signal, which then
has to be fed back from destination to source.--> has to be fed back from destination to source.-->
</section> </section>
<section anchor="ecnencap_Null" numbered="true" toc="default"> <section anchor="ecnencap_Null" numbered="true" toc="default">
<name>Null Mode</name> <name>Null Mode</name>
<t>Often link and physical layer resources are 'non-blocking' by <t>Link and physical-layer resources are often 'non-blocking' by
design. In these cases congestion notification may be implemented but design. Congestion notifications may be implemented in these cases, but
it does not need to be deployed at the lower layer; ECN in IP would be it does not need to be deployed at the lower layer; ECN in IP would be
sufficient.</t> sufficient.</t>
<t>A degenerate example is a point-to-point Ethernet link. Excess <t>A degenerate example is a point-to-point Ethernet link. Excess
loading of the link merely causes the queue from the higher layer to loading of the link merely causes the queue from the higher layer to
back up, while the lower layer remains immune to congestion. Even a back up, while the lower layer remains immune to congestion. Even a
whole meshed subnetwork can be made immune to interior congestion by whole meshed subnetwork can be made immune to interior congestion by
limiting ingress capacity and sufficient sizing of interior links, limiting ingress capacity and sufficient sizing of interior links,
e.g. a non-blocking fat-tree network <xref target="Leiserson85" format=" default"/>. An e.g., a non-blocking fat-tree network <xref target="Leiserson85" format= "default"/>. An
alternative to fat links near the root is numerous thin links with alternative to fat links near the root is numerous thin links with
multi-path routing to ensure even worst-case patterns of load cannot multi-path routing to ensure even worst-case patterns of load cannot
congest any link, e.g. a Clos network <xref target="Clos53" format="defa ult"/>.</t> congest any link, e.g., a Clos network <xref target="Clos53" format="def ault"/>.</t>
</section> </section>
</section> </section>
<!-- [rfced] Should these section titles be updated as follows
to use "ECN"?
Original (Section 4):
Feed-Forward-and-Up Mode: Guidelines for Adding Congestion Notification
Perhaps:
Feed-Forward-and-Up Mode: Guidelines for Adding ECN
Original (Section 5):
Feed-Up-and-Forward Mode: Guidelines for Adding Congestion Notification
Perhaps:
Feed-Up-and-Forward Mode: Guidelines for Adding ECN
Original (Section 6):
Feed-Backward Mode: Guidelines for Adding Congestion Notification
Perhaps:
Feed-Backward Mode: Guidelines for Adding ECN
-->
<section anchor="ecnencap_Guidelines_Forward" numbered="true" toc="default"> <section anchor="ecnencap_Guidelines_Forward" numbered="true" toc="default">
<name>Feed-Forward-and-Up Mode: Guidelines for Adding Congestion Notificat ion</name> <name>Feed-Forward-and-Up Mode: Guidelines for Adding Congestion Notificat ion</name>
<t>Feed-forward-and-up is the mode already used for signalling ECN up <t>Feed-forward-and-up is the mode already used for signalling ECN up
the layers through MPLS into IP <xref target="RFC5129" format="default"/> and through the layers through MPLS into IP <xref target="RFC5129" format="default"/> and through
IP-in-IP tunnels <xref target="RFC6040" format="default"/>, whether encaps ulating with IP-in-IP tunnels <xref target="RFC6040" format="default"/>, whether encaps ulating with
IPv4 <xref target="RFC2003" format="default"/>, IPv6 <xref target="RFC2473 " format="default"/> or IPsec IPv4 <xref target="RFC2003" format="default"/>, IPv6 <xref target="RFC2473 " format="default"/>, or IPsec
<xref target="RFC4301" format="default"/>. These RFCs take a consistent ap proach and the <xref target="RFC4301" format="default"/>. These RFCs take a consistent ap proach and the
following guidelines are designed to ensure this consistency continues following guidelines are designed to ensure this consistency continues
as ECN support is added to other protocols that encapsulate IP. The as ECN support is added to other protocols that encapsulate IP. The
guidelines are also designed to ensure compliance with the more general guidelines are also designed to ensure compliance with the more general
best current practice for the design of alternate ECN schemes given in best current practice for the design of alternate ECN schemes given in
<xref target="RFC4774" format="default"/> and extended by <xref target="RF C8311" format="default"/>.</t> <xref target="RFC4774" format="default"/> and extended by <xref target="RF C8311" format="default"/>.</t>
<t>The rest of this section is structured as follows:</t> <t>The rest of this section is structured as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<xref target="ecnencap_IP-IP_Coupled_Shim_Tunnels" format="default"/> addresses <xref target="ecnencap_IP-IP_Coupled_Shim_Tunnels" format="default"/> addresses
the most straightforward cases, where <xref target="RFC6040" format="d efault"/> can the most straightforward cases, where <xref target="RFC6040" format="d efault"/> can
be applied directly to add ECN to tunnels that are effectively be applied directly to add ECN to tunnels that are effectively
IP-in-IP tunnels, but with shim header(s) between the IP IP-in-IP tunnels, but with a shim header(s) between the IP
headers.</li> headers.</li>
<li> <li>
<t>The subsequent sections give guidelines for adding ECN to a <t>The subsequent sections give guidelines for adding ECN to a
subnet technology that uses feed-forward-and-up mode like IP, but it subnet technology that uses feed-forward-and-up mode like IP, but it
is not so similar to IP that <xref target="RFC6040" format="default"/> rules can be is not so similar to IP that <xref target="RFC6040" format="default"/> rules can be
applied directly. Specifically:</t> applied directly. Specifically:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Sections <xref format="counter" target="ecnencap_WireProtocolECN <li>Sections <xref format="counter"
Support"/>, <xref format="counter" target="ecnencap_EncapGuidelines"/> and <xref target="ecnencap_WireProtocolECNSupport"/>, <xref format="counter"
format="counter" target="ecnencap_DecapGuidelines"/> target="ecnencap_EncapGuidelines"/>, and <xref format="counter"
respectively address how to add ECN support to the wire protocol target="ecnencap_DecapGuidelines"/> address how to add ECN support
and to the encapsulators and decapsulators at the ingress and to the wire protocol and to the encapsulators and decapsulators at
egress of the subnet.</li> the ingress and egress of the subnet, respectively.</li>
<li> <li>
<xref target="ecnencap_Sequences" format="default"/> deals with th <xref target="ecnencap_Sequences" format="default"/> deals with th
e special, e special
but common, case of sequences of tunnels or subnets that all use but common case of sequences of tunnels or subnets that all use
the same technology</li> the same technology.</li>
<li> <li>
<xref target="ecnencap_Reframing" format="default"/> deals with th e question <xref target="ecnencap_Reframing" format="default"/> deals with th e question
of reframing when IP packets do not map 1:1 into lower layer of reframing when IP packets do not map 1:1 into lower-layer
frames.</li> frames.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<section anchor="ecnencap_IP-IP_Coupled_Shim_Tunnels" numbered="true" toc= "default"> <section anchor="ecnencap_IP-IP_Coupled_Shim_Tunnels" numbered="true" toc= "default">
<name>IP-in-IP Tunnels with Shim Headers</name> <name>IP-in-IP Tunnels with Shim Headers</name>
<t>A common pattern for many tunnelling protocols is to encapsulate an <t>A common pattern for many tunnelling protocols is to encapsulate an
inner IP header with shim header(s) then an outer IP header. A shim inner IP header with a shim header(s) then an outer IP header. A shim
header is defined as one that is not sufficient alone to forward the header is defined as one that is not sufficient alone to forward the
packet as an outer header. Another common pattern is for a shim to packet as an outer header. Another common pattern is for a shim to
encapsulate a layer 2 (L2) header, which in turn encapsulates (or encapsulate an L2 header, which in turn encapsulates (or
might encapsulate) an IP header. <xref target="I-D.ietf-tsvwg-rfc6040upd might encapsulate) an IP header. <xref target="RFC9601" format="default"
ate-shim" format="default"/> clarifies that RFC 6040 /> clarifies that <xref target="RFC6040"/>
is just as applicable when there are shim(s) and possibly a L2 header is just as applicable when there is a shim(s) and possibly an L2 header
between two IP headers.</t> between two IP headers.</t>
<t>However, it is not always feasible or necessary to propagate ECN <t>However, it is not always feasible or necessary to propagate ECN
between IP headers when separated by a shim. For instance, it might be between IP headers when separated by a shim. For instance, it might be
too costly to dig to arbitrary depths to find an inner IP header, too costly to dig to arbitrary depths to find an inner IP header,
there may be little or no congestion within the tunnel by design (see there may be little or no congestion within the tunnel by design (see
null mode in <xref target="ecnencap_Null" format="default"/> above), or a legacy null mode in <xref target="ecnencap_Null" format="default"/> above), or a legacy
implementation might not support ECN. In cases where a tunnel does not implementation might not support ECN. In cases where a tunnel does not
support ECN, it is important that the ingress does not copy the ECN support ECN, it is important that the ingress does not copy the ECN
field from an inner IP header to an outer. Therefore <xref section="4" t arget="I-D.ietf-tsvwg-rfc6040update-shim" format="default"/> requires network field from an inner IP header to an outer. Therefore <xref section="4" t arget="RFC9601" format="default"/> requires network
operators to configure the ingress of a tunnel that does not support operators to configure the ingress of a tunnel that does not support
ECN so that it zeros the ECN field in the outer IP header.</t> ECN so that it zeros the ECN field in the outer IP header.</t>
<t>Nonetheless, in many cases it is feasible to propagate the ECN <t>Nonetheless, in many cases it is feasible to propagate the ECN
field between IP headers separated by shim header(s) and/or a L2 field between IP headers separated by a shim header(s) and/or an L2
header. Particularly in the typical case when the outer IP header and header. Particularly in the typical case when the outer IP header and
the shim(s) are added (or removed) as part of the same procedure. Even the shim(s) is added (or removed) as part of the same procedure. Even
if the shim(s) encapsulate a L2 header, it is often possible to find if the shim(s) encapsulates an L2 header, it is often possible to find
an inner IP header within the L2 PDU and propagate ECN between that an inner IP header within the L2 PDU and propagate ECN between that
and the outer IP header. This can be thought of as a special case of and the outer IP header. This can be thought of as a special case of
the feed-up-and-forward mode (<xref target="ecnencap_Up" format="default "/>), so the the feed-up-and-forward mode (<xref target="ecnencap_Up" format="default "/>), so the
guidelines for this mode apply (<xref target="ecnencap_Guidelines_Up" fo rmat="default"/>).</t> guidelines for this mode apply (<xref target="ecnencap_Guidelines_Up" fo rmat="default"/>).</t>
<t>Numerous shim protocols have been defined for IP tunnelling. More <t>Numerous shim protocols have been defined for IP tunnelling. More
recent ones e.g. Geneve <xref target="RFC8926" format="default"/> and Ge neric UDP recent ones, e.g., Geneve <xref target="RFC8926" format="default"/> and Generic UDP
Encapsulation (GUE) <xref target="I-D.ietf-intarea-gue" format="default" /> cite and Encapsulation (GUE) <xref target="I-D.ietf-intarea-gue" format="default" /> cite and
follow RFC 6040. And some earlier ones, e.g. CAPWAP <xref target="RFC541 follow <xref target="RFC6040"/>. Some earlier ones, e.g., CAPWAP <xref t
5" format="default"/> and LISP <xref target="RFC9300" format="default"/>, cite R arget="RFC5415" format="default"/> and LISP <xref target="RFC9300" format="defau
FC 3168, lt"/>, cite <xref target="RFC3168"/>,
which is compatible with RFC 6040.</t> which is compatible with <xref target="RFC6040"/>.</t>
<t>However, as <xref section="9.3" target="RFC3168" format="default"/> p ointed out, ECN <t>However, as <xref section="9.3" target="RFC3168" format="default"/> p ointed out, ECN
support needs to be defined for many earlier shim-based tunnelling support needs to be defined for many earlier shim-based tunnelling
protocols, e.g. L2TPv2 <xref target="RFC2661" format="default"/>, L2TPv3 <xref target="RFC3931" format="default"/>, GRE <xref target="RFC2784" format="d efault"/>, PPTP <xref target="RFC2637" format="default"/>, GTP <xref target="GTP v1" format="default"/>, <xref target="GTPv1-U" format="default"/>, <xref target= "GTPv2-C" format="default"/> and Teredo <xref target="RFC4380" format="default"/ > as well as some recent ones, e.g. VXLAN <xref target="RFC7348" format="default "/>, NVGRE <xref target="RFC7637" format="default"/> and NSH <xref target="RFC83 00" format="default"/>.</t> protocols, e.g., L2TPv2 <xref target="RFC2661" format="default"/>, L2TPv 3 <xref target="RFC3931" format="default"/>, GRE <xref target="RFC2784" format=" default"/>, PPTP <xref target="RFC2637" format="default"/>, GTP <xref target="GT Pv1" format="default"/> <xref target="GTPv1-U" format="default"/>, <xref target= "GTPv2-C" format="default"/>, and Teredo <xref target="RFC4380" format="default" />, as well as some recent ones, e.g., VXLAN <xref target="RFC7348" format="defa ult"/>, NVGRE <xref target="RFC7637" format="default"/>, and NSH <xref target="R FC8300" format="default"/>.</t>
<t>All these IP-based encapsulations can be updated in one shot by <t>All these IP-based encapsulations can be updated in one shot by
simple reference to RFC 6040. However, it would not be appropriate to simple reference to <xref target="RFC6040"/>. However, it would not be a ppropriate to
update all these protocols from within the present guidance document. update all these protocols from within the present guidance document.
Instead a companion specification <xref target="I-D.ietf-tsvwg-rfc6040up Instead, a companion specification <xref target="RFC9601" format="defaul
date-shim" format="default"/> has been prepared that t"/>
has the appropriate standards track status to update standards track has the appropriate Standards Track status to update Standards Track
protocols. For those that are not under IETF change control <xref target protocols. For those that are not under IETF change control <xref target
="I-D.ietf-tsvwg-rfc6040update-shim" format="default"/> can only recommend that ="RFC9601" format="default"/> can only recommend that
the relevant body updates them.</t> the relevant body updates them.</t>
</section> </section>
<section anchor="ecnencap_WireProtocolECNSupport" numbered="true" toc="def ault"> <section anchor="ecnencap_WireProtocolECNSupport" numbered="true" toc="def ault">
<name>Wire Protocol Design: Indication of ECN Support</name> <name>Wire Protocol Design: Indication of ECN Support</name>
<t>This section is intended to guide the redesign of any lower layer <t>This section is intended to guide the redesign of any lower-layer
protocol that encapsulate IP to add native ECN support at the lower protocol that encapsulates IP to add native ECN support at the lower
layer. It reflects the approaches used in <xref target="RFC6040" format= "default"/> and layer. It reflects the approaches used in <xref target="RFC6040" format= "default"/> and
in <xref target="RFC5129" format="default"/>. Therefore IP-in-IP tunnels or IP-in-MPLS in <xref target="RFC5129" format="default"/>. Therefore, IP-in-IP tunnel s or IP-in-MPLS
or MPLS-in-MPLS encapsulations that already comply with <xref target="RF C6040" format="default"/> or <xref target="RFC5129" format="default"/> will alre ady satisfy or MPLS-in-MPLS encapsulations that already comply with <xref target="RF C6040" format="default"/> or <xref target="RFC5129" format="default"/> will alre ady satisfy
this guidance.</t> this guidance.</t>
<t>A lower layer (or subnet) congestion notification system:</t> <t>A lower-layer (or subnet) congestion notification system:</t>
<ol spacing="normal" type="1"><li>SHOULD NOT apply explicit congestion n <ol spacing="normal" type="1"><li><bcp14>SHOULD NOT</bcp14> apply ECNs t
otifications to PDUs that o PDUs that
are destined for legacy layer-4 transport implementations that are destined for legacy layer-4 transport implementations that
will not understand ECN, and</li> will not understand ECN; and</li>
<li anchor="ecnencap_Egress_Check"> <li anchor="ecnencap_Egress_Check">
<t>SHOULD NOT apply explicit <t><bcp14>SHOULD NOT</bcp14> apply ECNs to PDUs if the egress of the
congestion notifications to PDUs if the egress of the subnet might subnet might
not propagate congestion notifications onward into the higher not propagate congestion notifications onward into the higher
layer.</t> layer.</t>
<t>We use the term ECN-PDUs for a PDU <t>We use the term ECN-PDUs for a PDU
on a feedback loop that will propagate congestion notification on a feedback loop that will propagate congestion notifications
properly because it meets both the above criteria. And a properly because it meets both the above criteria. Additionally, a
Not-ECN-PDU is a PDU on a feedback loop that does not meet at Not-ECN-PDU is a PDU on a feedback loop that does not meet at
least one of the criteria, and will therefore not propagate least one of the criteria, and therefore will not propagate
congestion notification properly. A corollary of the above is that congestion notifications properly. A corollary of the above is that
a lower layer congestion notification protocol:</t> a lower-layer congestion notification protocol:</t>
</li> </li>
<li>SHOULD be able to distinguish ECN-PDUs from Not-ECN-PDUs.</li> <li><bcp14>SHOULD</bcp14> be able to distinguish ECN-PDUs from Not-ECN -PDUs.</li>
</ol> </ol>
<t>Note that there is no need for all interior nodes within a subnet <t>Note that there is no need for all interior nodes within a subnet
to be able to mark congestion explicitly. A mix of ECN and drop to be able to mark congestion explicitly. A mix of ECN and drop
signals from different nodes is fine. However, if <em>any</em> signals from different nodes is fine. However, if <em>any</em>
interior nodes might generate ECN markings, guideline <xref format="coun interior nodes might generate ECN markings, Guideline <xref format="coun
ter" target="ecnencap_Egress_Check"/> above says that all ter" target="ecnencap_Egress_Check"/> above says that all
relevant egress node(s) SHOULD be able to propagate those markings up relevant egress nodes <bcp14>SHOULD</bcp14> be able to propagate those m
arkings up
to the higher layer.</t> to the higher layer.</t>
<t>In IP, if the ECN field in each PDU is cleared to the Not-ECT (not <t>In IP, if the ECN field in each PDU is cleared to the Not ECN-Capable
ECN-capable transport) codepoint, it indicates that the L4 transport Transport (Not-ECT) codepoint, it indicates that the L4 transport
will not understand congestion markings. A congested buffer must not will not understand congestion markings. A congested buffer must not
mark these Not-ECT PDUs, and therefore has to signal congestion by mark these Not-ECT PDUs; therefore, it has to signal congestion by
increasingly applying drop instead.</t> increasingly applying drop instead.</t>
<t>The mechanism a lower layer uses to distinguish the ECN-capability <t>The mechanism a lower layer uses to distinguish the ECN capability
of PDUs need not mimic that of IP. The above guidelines merely say of PDUs need not mimic that of IP. The above guidelines merely say
that the lower layer system, as a whole, should achieve the same that the lower-layer system as a whole should achieve the same
outcome. For instance, ECN-capable feedback loops might use PDUs that outcome. For instance, ECN-capable feedback loops might use PDUs that
are identified by a particular set of labels or tags. Alternatively, are identified by a particular set of labels or tags. Alternatively,
logical link protocols that use flow state might determine whether a logical-link protocols that use flow state might determine whether a
PDU can be congestion marked by checking for ECN-support in the flow PDU can be congestion marked by checking for ECN-support in the flow
state. Other protocols might depend on out-of-band control state. Other protocols might depend on out-of-band control
signals.</t> signals.</t>
<t>The per-domain checking of ECN support in MPLS <xref target="RFC5129" format="default"/> is a good example of a way to avoid sending <t>The per-domain checking of ECN support in MPLS <xref target="RFC5129" format="default"/> is a good example of a way to avoid sending
congestion markings to L4 transports that will not understand them, congestion markings to L4 transports that will not understand them
without using any header space in the subnet protocol.</t> without using any header space in the subnet protocol.</t>
<t>In MPLS, header space is extremely limited, therefore RFC5129 does <t>In MPLS, header space is extremely limited; therefore, <xref target=" RFC5129"/> does
not provide a field in the MPLS header to indicate whether the PDU is not provide a field in the MPLS header to indicate whether the PDU is
an ECN-PDU or a Not-ECN-PDU. Instead, interior nodes in a domain are an ECN-PDU or a Not-ECN-PDU. Instead, interior nodes in a domain are
allowed to set explicit congestion indications without checking allowed to set explicit congestion indications without checking
whether the PDU is destined for a L4 transport that will understand whether the PDU is destined for a L4 transport that will understand
them. Nonetheless, this is made safe by requiring that the network them. Nonetheless, this is made safe by requiring that the network
operator upgrades all decapsulating edges of a whole domain at once, operator upgrades all decapsulating edges of a whole domain at once
as soon as even one switch within the domain is configured to mark as soon as even one switch within the domain is configured to mark
rather than drop some PDUs during congestion. Therefore, any edge node t hat rather than drop some PDUs during congestion. Therefore, any edge node t hat
might decapsulate a packet will be capable of checking whether the might decapsulate a packet will be capable of checking whether the
higher layer transport is ECN-capable. When decapsulating a CE-marked higher-layer transport is ECN-capable.
<!-- May we rephrase the following sentence for a better flow of the text?
Original:
When decapsulating a CE-marked packet, if the decapsulator discovers
that the higher layer (inner header) indicates the transport is not ECN-
capable, it drops the packet — effectively on behalf of the earlier congested
node (see Decapsulation Guideline 1 in Section 4.4).
Perhaps:
If the decapsulator discovers that the higher layer (inner header)
indicates the transport is not ECN-capable when decapsulating a CE-marked
packet, it effectively drops the packet on behalf of the earlier congested
node (see Decapsulation Guideline 1 in Section 4.4).
-->
When decapsulating a CE-marked
packet, if the decapsulator discovers that the higher layer (inner packet, if the decapsulator discovers that the higher layer (inner
header) indicates the transport is not ECN-capable, it drops the header) indicates the transport is not ECN-capable, it drops the
packet &mdash; effectively on behalf of the earlier congested node packet -- effectively on behalf of the earlier congested node
(see Decapsulation Guideline <xref format="counter" target="ecnencap_dro pNot-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuidelines" format="defau lt"/>).</t> (see Decapsulation Guideline <xref format="counter" target="ecnencap_dro pNot-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuidelines" format="defau lt"/>).</t>
<t>It was only appropriate to define such an incremental deployment <t>It was only appropriate to define such an incremental deployment
strategy because MPLS is targeted solely at professional operators, strategy because MPLS is targeted solely at professional operators
who can be expected to ensure that a whole subnetwork is consistently who can be expected to ensure that a whole subnetwork is consistently
configured. This strategy might not be appropriate for other link configured. This strategy might not be appropriate for other link
technologies targeted at zero-configuration deployment or deployment technologies targeted at zero-configuration deployment or deployment
by the general public (e.g. Ethernet). For such 'plug-and-play' by the general public (e.g., Ethernet). For such 'plug-and-play'
environments it will be necessary to invent a failsafe approach that environments, it will be necessary to invent a fail-safe approach that
ensures congestion markings will never fall into black holes, no ensures congestion markings will never fall into black holes, no
matter how inconsistently a system is put together. Alternatively, matter how inconsistently a system is put together.
congestion notification relying on correct system configuration could
Alternatively,
congestion notifications relying on correct system configuration could
be confined to flavours of Ethernet intended only for professional be confined to flavours of Ethernet intended only for professional
network operators, such as Provider Backbone Bridges (PBB <xref target=" network operators, such as Provider Backbone Bridges (PBB) (<xref target
IEEE802.1Q" format="default"/>; previously 802.1ah).</t> ="IEEE802.1Q" format="default"/>; previously 802.1ah).</t>
<t>ECN support in TRILL <xref target="I-D.ietf-trill-ecn-support" format <t>ECN support in TRansparent Interconnection of Lots of Links (TRILL) <
="default"/> xref target="RFC9600" format="default"/>
provides a good example of how to add ECN to a lower layer protocol provides a good example of how to add ECN to a lower-layer protocol
without relying on careful and consistent operator configuration. without relying on careful and consistent operator configuration.
TRILL provides an extension header word with space for flags of TRILL provides an extension header word with space for flags of
different categories depending on whether logic to understand the different categories depending on whether logic to understand the
extension is critical. The congestion experienced marking has been extension is critical. The congestion-experienced marking has been
defined as a 'critical ingress-to-egress' flag. So if a transit defined as a 'critical ingress-to-egress' flag.
<!-- [rfced] May we rephrase the following sentence for clarity?
Specifically, "it" in the phrase "... does not have any logic to
process it, it will drop it..." seems unclear and repetitive.
Original:
So if a transit RBridge sets this flag on a frame and an egress
RBridge does not have any logic to process it, it will drop it; which is the
desired default action anyway.
Perhaps:
If a transit RBridge sets this flag on 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 default action anyway.
-->
So if a transit
RBridge sets this flag on a frame and an egress RBridge does not have an y logic RBridge sets this flag on a frame and an egress RBridge does not have an y logic
to process it, it will drop it; which is the desired default action to process it, it will drop it; which is the desired default action
anyway. Therefore TRILL RBridges can be updated with support for ECN anyway. Therefore, TRILL RBridges can be updated with support for ECN
in no particular order and, at the egress of the TRILL campus, in no particular order and, at the egress of the TRILL campus,
congestion notification will be propagated to IP as ECN whenever ECN congestion notifications will be propagated to IP as ECN whenever ECN
logic has been implemented at the egress, or as drop otherwise.</t> logic has been implemented at the egress, or as drop otherwise.</t>
<t>QCN <xref target="IEEE802.1Q" format="default"/> is not intended to e xtend beyond a <t>QCN <xref target="IEEE802.1Q" format="default"/> is not intended to e xtend beyond a
single subnet, or to interoperate with ECN. Nonetheless, the way QCN single subnet or interoperate with ECN. Nonetheless, the way QCN
indicates to lower layer devices that the end-points will not indicates to lower-layer devices that the endpoints will not
understand QCN provides another example that a lower layer protocol understand QCN provides another example that a lower-layer protocol
designer might be able to mimic for their scenario. An operator can designer might be able to mimic for their scenario.
define certain Priority Code Points (PCPs <xref target="IEEE802.1Q" form <!-- [rfced] Please clarify this sentence. Is it indicating that both non-QCN
at="default"/>; frames AND an ingress bridge are required to map arriving not-QCN-capable
IP packets? Also, does each packet get mapped to a PCP?
Original:
An operator can define certain
Priority Code Points (PCPs [IEEE802.1Q]; previously 802.1p) to
indicate non-QCN frames and an ingress bridge is required to map
arriving not-QCN-capable IP packets to one of these non-QCN PCPs.
Perhaps:
An operator can define certain
Priority Code Points (PCPs) [IEEE802.1Q] to indicate that non-QCN
frames and an ingress bridge are required to map arriving not-QCN-
capable IP packets to one of these non-QCN PCPs.
Or (two independent clauses; added "each"):
An operator can define certain
Priority Code Points (PCPs [IEEE802.1Q]; previously 802.1p) to
indicate non-QCN frames, and an ingress bridge is required to map
each arriving not-QCN-capable IP packet to one of these non-QCN PCPs.
-->
An operator can
define certain Priority Code Points (PCPs) (<xref target="IEEE802.1Q" fo
rmat="default"/>;
previously 802.1p) to indicate non-QCN frames and an ingress bridge is previously 802.1p) to indicate non-QCN frames and an ingress bridge is
required to map arriving not-QCN-capable IP packets to one of these required to map arriving not-QCN-capable IP packets to one of these
non-QCN PCPs.</t> non-QCN PCPs.</t>
<t>When drop for non-ECN traffic is deferred to the egress of a subnet, <t>When drop for non-ECN traffic is deferred to the egress of a subnet,
it cannot necessarily be assumed that one ECN mark is equivalent to one it cannot necessarily be assumed that one ECN mark is equivalent to one
drop, as was originally required by <xref target="RFC3168" format="defau lt"/>. drop, as was originally required by <xref target="RFC3168" format="defau lt"/>.
<xref target="RFC8311" format="default"/> updated RFC&nbsp;3168, to allo w <xref target="RFC8311" format="default"/> updated <xref target="RFC3168" /> to allow
experimentation with congestion markings that are not equivalent to drop , experimentation with congestion markings that are not equivalent to drop ,
in particular for L4S <xref target="RFC9331" format="default"/>. ECN particularly for L4S <xref target="RFC9331" format="default"/>. ECN
support in TRILL <xref target="I-D.ietf-trill-ecn-support" format="defau support in TRILL <xref target="RFC9600" format="default"/>
lt"/>
is a good example of a way to defer drop to the egress of a subnet both is a good example of a way to defer drop to the egress of a subnet both
when marks are equivalent to drops (as in RFC&nbsp;3168) and when they when marks are equivalent to drops (as in <xref target="RFC3168"/>) and when they
are not (as in L4S). The ECN scheme for MPLS <xref target="RFC5129" form at="default"/> are not (as in L4S). The ECN scheme for MPLS <xref target="RFC5129" form at="default"/>
was defined before L4S, so it only currently supports deferred drop that was defined before L4S, so it only currently supports deferred drop that
is equivalent to ECN-marking. Nonetheless, in principle, MPLS is equivalent to ECN marking. Nonetheless, in principle, MPLS
(and potentially future L2 protocols) could support L4S marking and copy TRILL's approach for determining the (and potentially future L2 protocols) could support L4S marking and copy TRILL's approach for determining the
drop level of any non-ECN traffic at the subnet egress.</t> drop level of any non-ECN traffic at the subnet egress.</t>
</section> </section>
<section anchor="ecnencap_EncapGuidelines" numbered="true" toc="default"> <section anchor="ecnencap_EncapGuidelines" numbered="true" toc="default">
<name>Encapsulation Guidelines</name> <name>Encapsulation Guidelines</name>
<t>This section is intended to guide the redesign of any node that <t>This section is intended to guide the redesign of any node that
encapsulates IP with a lower layer header when adding native ECN encapsulates IP with a lower-layer header when adding native ECN
support to the lower layer protocol. It reflects the approaches used support to the lower-layer protocol. It reflects the approaches used
in <xref target="RFC6040" format="default"/> and in <xref target="RFC512 in <xref target="RFC6040" format="default"/> and <xref target="RFC5129"
9" format="default"/>. Therefore format="default"/>. Therefore,
IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that
already comply with <xref target="RFC6040" format="default"/> or <xref t arget="RFC5129" format="default"/> will already satisfy this guidance.</t> already comply with <xref target="RFC6040" format="default"/> or <xref t arget="RFC5129" format="default"/> will already satisfy this guidance.</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Egress Capability Check: A subnet ingress needs to be sure that <t>Egress Capability Check: A subnet ingress needs to be sure that
the corresponding egress of a subnet will propagate any congestion the corresponding egress of a subnet will propagate any congestion
notification added to the outer header across the subnet. This is notifications added to the outer header across the subnet. This is
necessary in addition to checking that an incoming PDU indicates necessary in addition to checking that an incoming PDU indicates
an ECN-capable (L4) transport. Examples of how this guarantee an ECN-capable (L4) transport. Examples of how this guarantee
might be provided include:</t> might be provided include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>by configuration (e.g. if any label switches in a domain <li>by configuration (e.g., if any label switches in a domain
support ECN marking, <xref target="RFC5129" format="default"/> r supports ECN marking, <xref target="RFC5129" format="default"/>
equires all requires all
egress nodes to have been configured to propagate ECN)</li> egress nodes to have been configured to propagate ECN).</li>
<li>by the ingress explicitly checking that the egress <li>by the ingress explicitly checking that the egress
propagates ECN (e.g. an early attempt to add ECN support to propagates ECN (e.g., an early attempt to add ECN support to
TRILL used IS-IS to check path capabilities before adding ECN TRILL used IS-IS to check path capabilities before adding ECN
extension flags to each frame <xref target="RFC7780" format="def ault"/>).</li> extension flags to each frame <xref target="RFC7780" format="def ault"/>).</li>
<li>by inherent design of the protocol (e.g. by encoding ECN <li>by inherent design of the protocol (e.g., by encoding ECN
marking on the outer header in such a way that a legacy egress marking on the outer header in such a way that a legacy egress
that does not understand ECN will consider the PDU corrupt or that does not understand ECN will consider the PDU corrupt or
invalid and discard it, thus at least propagating a form of invalid and discard it; thus, at least propagating a form of
congestion signal).</li> congestion signal).</li>
</ul> </ul>
</li> </li>
<li>Egress Fails Capability Check: If the ingress cannot guarantee <li>Egress Fails Capability Check: If the ingress cannot guarantee
that the egress will propagate congestion notification, the that the egress will propagate congestion notifications, the
ingress SHOULD disable ECN at the lower layer when it forwards the ingress <bcp14>SHOULD</bcp14> disable ECN at the lower layer when it
forwards the
PDU. An example of how the ingress might disable ECN at the lower PDU. An example of how the ingress might disable ECN at the lower
layer would be by setting the outer header of the PDU to identify layer would be by setting the outer header of the PDU to identify
it as a Not-ECN-PDU, assuming the subnet technology supports such it as a Not-ECN-PDU, assuming the subnet technology supports such
a concept.</li> a concept.</li>
<li anchor="ecnencap_Encap_Copy"> <li anchor="ecnencap_Encap_Copy">
<t>Standard Congestion Monitoring <t>Standard Congestion Monitoring
Baseline: Once the ingress to a subnet has established that the Baseline: Once the ingress to a subnet has established that the
egress will correctly propagate ECN, on encapsulation it SHOULD egress will correctly propagate ECN, it <bcp14>SHOULD</bcp14>
encode the same level of congestion in outer headers as is encode the same level of congestion in outer headers as is
arriving in incoming headers. For example, it might copy any arriving in incoming headers on encapsulation. For example, it might
incoming congestion notification into the outer header of the copy any
lower layer protocol.</t> incoming congestion notifications into the outer header of the
lower-layer protocol.</t>
<t>This ensures that <t>This ensures that
bulk congestion monitoring of outer headers (e.g. by a network bulk congestion monitoring of outer headers (e.g., by a network
management node monitoring ECN in passing frames) will measure management node monitoring ECN in passing frames) will measure
congestion accumulated along the whole upstream path &mdash; startin congestion accumulated along the whole upstream path, starting from
g from the the
Load Regulator not just starting from the ingress of the subnet. A n Load Regulator and not just starting from the ingress of the subnet.
ode A node
that is not the Load Regulator SHOULD NOT re-initialize the level that is not the Load Regulator <bcp14>SHOULD NOT</bcp14> re-initiali
of CE markings in the outer to zero. </t> ze the level
of CE markings in the outer header to zero. </t>
<t>It <t>It
would still also be possible to measure congestion introduced would still also be possible to measure congestion introduced
across one subnet (or tunnel) by subtracting the level of CE across one subnet (or tunnel) by subtracting the level of CE
markings on inner headers from that on outer headers (see Appendix markings on inner headers from that on outer headers (see <xref targ
C of <xref target="RFC6040" format="default"/>). For example:</t> et="RFC6040" sectionFormat="of" section="C"/>). For example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If this guideline has been followed and if the level of CE <li>If this guideline has been followed and if the level of CE
markings is 0.4% on the outer and 0.1% on the inner, 0.4% markings is 0.4% on the outer header and 0.1% on the inner heade r, 0.4%
congestion has been introduced across all the networks since congestion has been introduced across all the networks since
the load regulator, and 0.3% (= 0.4% - 0.1%) has been the Load Regulator, and 0.3% (= 0.4% - 0.1%) has been
introduced since the ingress to the current subnet (or introduced since the ingress to the current subnet (or
tunnel);</li> tunnel).</li>
<li>Without this guideline, if the subnet ingress had <li>Without this guideline, if the subnet ingress had
re-initialized the outer congestion level to zero, the outer re-initialized the outer congestion level to zero, the outer
and inner would measure 0.1% and 0.3%. It would still be and inner headers would measure 0.1% and 0.3%. It would still be
possible to infer that the congestion introduced since the possible to infer that the congestion introduced since the
Load Regulator was 0.4% (= 0.1% + 0.3%). But only if the Load Regulator was 0.4% (= 0.1% + 0.3%), but only if the
monitoring system somehow knows whether the subnet ingress monitoring system somehow knows whether the subnet ingress
re-initialized the congestion level.</li> re-initialized the congestion level.</li>
</ul> </ul>
<t>As long as subnet and tunnel technologies use the <t>As long as subnet and tunnel technologies use the
standard congestion monitoring baseline in this guideline, standard congestion monitoring baseline in this guideline,
monitoring systems will know to use the former approach, rather monitoring systems will know to use the former approach rather
than having to "somehow know" which approach to use.<!--{If required than having to "somehow know" which approach to use.<!--{If required
, an example can be given of where it would be appropriate to contradict this SH , an example can be given of where it would be appropriate to contradict this SH
OULD. OULD
It may be safe to assume a subnetwork technology will not span a trust boundary. It may be safe to assume a subnetwork technology will not span a trust boundary.
Especially if copy on encap is not desirable, e.g. if using Floyd's 1-bit MPLS s cheme.} Especially if copy on encap is not desirable, e.g. if using Floyd's 1-bit MPLS s cheme.}
--> -->
</t> </t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="ecnencap_DecapGuidelines" numbered="true" toc="default"> <section anchor="ecnencap_DecapGuidelines" numbered="true" toc="default">
<name>Decapsulation Guidelines</name> <name>Decapsulation Guidelines</name>
<t>This section is intended to guide the redesign of any node that <t>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 native
ECN support to the lower layer protocol. It reflects the approaches ECN support to the lower-layer protocol. It reflects the approaches
used in <xref target="RFC6040" format="default"/> and in <xref target="R FC5129" format="default"/>. used in <xref target="RFC6040" format="default"/> and in <xref target="R FC5129" format="default"/>.
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 <xref target="RFC6040" format="d efault"/> or encapsulations that already comply with <xref target="RFC6040" format="d efault"/> or
<xref target="RFC5129" format="default"/> will already satisfy this guid ance.</t> <xref target="RFC5129" format="default"/> will already satisfy this guid ance.</t>
<t>A subnet egress SHOULD NOT simply copy congestion notification from <t>A subnet egress <bcp14>SHOULD NOT</bcp14> simply copy congestion noti
outer headers to the forwarded header. It SHOULD calculate the fications from
outer headers to the forwarded header. It <bcp14>SHOULD</bcp14> calculat
e 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,
rules earlier in the list take precedence over rules later in the rules earlier in the list take precedence over rules later in the
list:</t> list.</t>
<ol spacing="normal" type="1"><li anchor="ecnencap_dropNot-ECTinnerCEout er"> <ol spacing="normal" type="1"><li anchor="ecnencap_dropNot-ECTinnerCEout er">
<t>If the arriving inner <t>If the arriving inner
header is a Not-ECN-PDU it implies the L4 transport will not header is a Not-ECN-PDU, it implies the L4 transport will not
understand explicit congestion markings. Then:</t> understand explicit congestion markings. Then:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the outer header carries an explicit congestion marking, <li>If the outer header carries an explicit congestion marking,
it is likely that a protocol error has occurred, so drop is the only indication of congestion that the L4 it is likely that a protocol error has occurred, so drop is the only indication of congestion that the L4
transport will understand. If the congestion marking is the transport will understand.
most severe possible, the packet MUST be dropped. However, if If the congestion marking is the
congestion can be marked with multiple levels of severity and most severe possible, the packet <bcp14>MUST</bcp14> be dropped.
the packet's marking is not the most severe, this requirement
can be relaxed to: the packet SHOULD be dropped.</li> However, if congestion can be marked with multiple levels of severity and the
packet's marking is not the most severe, this requirement can be relaxed to:
the packet <bcp14>SHOULD</bcp14> be dropped.</li>
<li>If the outer is an ECN-PDU that carries no indication of <li>If the outer is an ECN-PDU that carries no indication of
congestion or a Not-ECN-PDU the PDU SHOULD be forwarded, but congestion or a Not-ECN-PDU the PDU <bcp14>SHOULD</bcp14> be for warded, but
still as a Not-ECN-PDU.</li> still as a Not-ECN-PDU.</li>
</ul> </ul>
</li> </li>
<li>If the outer header does not support explicit congestion <li>If the outer header does not support ENC (a Not-ECN-PDU), but the
notification (a Not-ECN-PDU), but the inner header does (an inner header does (an
ECN-PDU), the inner header SHOULD be forwarded unchanged.</li> ECN-PDU), the inner header <bcp14>SHOULD</bcp14> be forwarded unchan
<li>In some lower layer protocols congestion may be signalled as a ged.</li>
numerical level, such as in the control frames of quantized <li>In some lower-layer protocols, congestion may be signalled as a
congestion notification (QCN <xref target="IEEE802.1Q" format="defau numerical level, such as in the control frames of QCN <xref target="
lt"/>). If such IEEE802.1Q" format="default"/>. If such
a multi-bit encoding encapsulates an ECN-capable IP data packet, a a multi-bit encoding encapsulates an ECN-capable IP data packet, a
function will be needed to convert the quantized congestion level function will be needed to convert the quantized congestion level
into the frequency of congestion markings in outgoing IP into the frequency of congestion markings in outgoing IP
packets.</li> packets.</li>
<li> <li>
<t>Congestion indications might be encoded by a severity level. <t>Congestion indications might be encoded by a severity level.
For instance increasing levels of congestion might be encoded by For instance, increasing levels of congestion might be encoded by
numerically increasing indications, e.g. pre-congestion numerically increasing indications, e.g., PCN can be encoded in each
notification (PCN) can be encoded in each PDU at three severity PDU at three severity
levels in IP or MPLS <xref target="RFC6660" format="default"/> and t he default levels in IP or MPLS <xref target="RFC6660" format="default"/> and t he default
encapsulation and decapsulation rules <xref target="RFC6040" format= "default"/> are encapsulation and decapsulation rules <xref target="RFC6040" format= "default"/> are
compatible with this interpretation of the ECN field. </t> compatible with this interpretation of the ECN field. </t>
<t>If the arriving inner header is an ECN-PDU, where <t>If the arriving inner header is an ECN-PDU, where
the inner and outer headers carry indications of congestion of the inner and outer headers carry indications of congestion of
different severity, the more severe indication SHOULD be forwarded different severity, the more severe indication <bcp14>SHOULD</bcp14> be forwarded
in preference to the less severe.</t> in preference to the less severe.</t>
</li> </li>
<li> <li>
<t>The inner and outer headers might carry a combination of <t>The inner and outer headers might carry a combination of
congestion notification fields that should not be possible given congestion notification fields that should not be possible given
any currently used protocol transitions. For instance, if any currently used protocol transitions. For instance, if
Encapsulation Guideline <xref format="counter" target="ecnencap_Enca p_Copy"/> in <xref target="ecnencap_EncapGuidelines" format="default"/> had been followed, it should Encapsulation Guideline <xref format="counter" target="ecnencap_Enca p_Copy"/> in <xref target="ecnencap_EncapGuidelines" format="default"/> had been followed, it should
not be possible to have a less severe indication of congestion in not be possible to have a less severe indication of congestion in
the outer than in the inner. It MAY be appropriate to log the outer header than in the inner header. It <bcp14>MAY</bcp14> be appropriate to log
unexpected combinations of headers and possibly raise an alarm. unexpected combinations of headers and possibly raise an alarm.
</t> </t>
<t>If a safe outgoing codepoint can be <t>If a safe outgoing codepoint can be
defined for such a PDU, the PDU SHOULD be forwarded rather than defined for such a PDU, the PDU <bcp14>SHOULD</bcp14> be forwarded r ather than
dropped. Some implementers discard PDUs with currently unused dropped. Some implementers discard PDUs with currently unused
combinations of headers just in case they represent an attack. combinations of headers just in case they represent an attack.
However, an approach using alarms and policy-mediated drop is However, an approach using alarms and policy-mediated drop is
preferable to hard-coded drop, so that operators can keep track of preferable to hard-coded drop so that operators can keep track of
possible attacks but currently unused combinations are not possible attacks, but currently unused combinations are not
precluded from future use through new standards actions.</t> precluded from future use through new standards actions.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="ecnencap_Sequences" numbered="true" toc="default"> <section anchor="ecnencap_Sequences" numbered="true" toc="default">
<name>Sequences of Similar Tunnels or Subnets</name> <name>Sequences of Similar Tunnels or Subnets</name>
<t>In some deployments, particularly in 3GPP networks, an IP packet <t>In some deployments, particularly in 3GPP networks, an IP packet
may traverse two or more IP-in-IP tunnels in sequence that all use may traverse (in sequence) two or more IP-in-IP tunnels that all use
identical technology (e.g. GTP).</t> identical technology (e.g., GTP).</t>
<t>In such cases, it would be sufficient for every encapsulation and <t>In such cases, it would be sufficient for every encapsulation and
decapsulation in the chain to comply with RFC 6040. Alternatively, as decapsulation in the chain to comply with <xref
an optimisation, a node that decapsulates a packet and immediately target="RFC6040"/>.
re-encapsulates it for the next tunnel MAY copy the incoming outer ECN <!-- [rfced] Should "outer" and "inner" be specified as "outer header" and
field directly to the outgoing outer and the incoming inner ECN field "inner header" in this sentence for clarity?
directly to the outgoing inner. Then the overall behavior across the
sequence of tunnel segments would still be consistent with RFC Original:
6040.</t> Alternatively,
<t>Appendix C of RFC6040 describes how a tunnel egress can monitor how as an optimisation, a node that decapsulates a packet and immediately
re-encapsulates it for the next tunnel MAY copy the incoming outer
ECN field directly to the outgoing outer and the incoming inner ECN
field directly to the outgoing inner.
Perhaps:
Alternatively,
as an optimization, a node that decapsulates a packet and immediately
re-encapsulates it for the next tunnel MAY copy the incoming
outer ECN field directly to the outgoing outer header and the incoming
inner ECN field directly to the outgoing inner header.
-->
Alternatively, as an optimization, a node that
decapsulates a packet and immediately re-encapsulates it for the next
tunnel <bcp14>MAY</bcp14> copy the incoming outer ECN field directly
to the outgoing outer and the incoming inner ECN field directly to the
outgoing inner. Then, the overall behavior across the sequence of
tunnel segments would still be consistent with <xref target="RFC6040"/>.
</t>
<t><xref target="RFC6040" sectionFormat="of" section="C"/> describes how
a tunnel egress can monitor how
much congestion has been introduced within a tunnel. A network much congestion has been introduced within a tunnel. A network
operator might want to monitor how much congestion had been introduced operator might want to monitor how much congestion had been introduced
within a whole sequence of tunnels. Using the technique in Appendix C within a whole sequence of tunnels. Using the technique in
of RFC6040 at the final egress, the operator could monitor the whole <xref target="RFC6040" sectionFormat="of" section="C"/> at the final egr
sequence of tunnels, but only if the above optimisation were used ess, the operator could monitor the whole
sequence of tunnels, but only if the above optimization were used
consistently along the sequence of tunnels, in order to make it appear consistently along the sequence of tunnels, in order to make it appear
as a single tunnel. Therefore, tunnel endpoint implementations SHOULD as a single tunnel. Therefore, tunnel endpoint implementations <bcp14>SH
allow the operator to configure whether this optimisation is OULD</bcp14>
allow the operator to configure whether this optimization is
enabled.</t> enabled.</t>
<t>When ECN support is added to a subnet technology, consideration <t>When ECN support is added to a subnet technology, consideration
SHOULD be given to a similar optimisation between subnets in sequence <bcp14>SHOULD</bcp14> be given to a similar optimization between subnets in sequence
if they all use the same technology.</t> if they all use the same technology.</t>
</section> </section>
<section anchor="ecnencap_Reframing" numbered="true" toc="default"> <section anchor="ecnencap_Reframing" numbered="true" toc="default">
<name>Reframing and Congestion Markings</name> <name>Reframing and Congestion Markings</name>
<t>The guidance in this section is worded in terms of framing <t>The guidance in this section is worded in terms of framing
boundaries, but it applies equally whether the protocol data units are boundaries, but it applies equally whether the PDUs are
frames, cells or packets.</t> frames, cells, or packets.</t>
<t>Where an AQM marks the ECN field of IP packets as they queue into a <t>Where an AQM marks the ECN field of IP packets as they queue into a
layer-2 link, there will be no problem with framing boundaries, Layer 2 link, there will be no problem with framing boundaries
because the ECN markings would be applied directly to IP packets. The because the ECN markings would be applied directly to IP packets. The
guidance in this section is only applicable where an ECN capability is guidance in this section is only applicable where an ECN capability is
being added to a layer-2 protocol so that layer-2 frames can be being added to a Layer 2 protocol so that Layer 2 frames can be
ECN-marked by an AQM at layer-2. This would only be necessary where ECN-marked by an AQM at layer 2. This would only be necessary where
AQM will be applied at pure layer-2 nodes (without IP-awareness).</t> AQM will be applied at pure Layer 2 nodes (without IP awareness).</t>
<t>Where ECN marking has had to be applied at non-IP-aware nodes and <t>Where ECN marking has had to be applied at non-IP-aware nodes and
framing boundaries do not necessarily align with packet boundaries, framing boundaries do not necessarily align with packet boundaries,
the decapsulating IP forwarding node SHOULD propagate ECN markings the decapsulating IP forwarding node <bcp14>SHOULD</bcp14> propagate ECN
from layer-2 frame headers to IP packets that may have different markings
from Layer 2 frame headers to IP packets that may have different
boundaries as a consequence of reframing.</t> boundaries as a consequence of reframing.</t>
<!-- [rfced] For the design goals below, may we rephrase and format the list
as follows for clarity? We note that this section later refers to these
goals as "goal 1" and "goal 2", but the list originally notes these goals
as 1a and 1b.
Original:
Two possible design goals for propagating congestion indications,
described in Section 5.3 of [RFC3168] and Section 2.4 of [RFC7141],
are:
1. approximate preservation of the presence (and therefore timing)
of congestion marks on the L2 frames used to construct an IP
packet;
a. at high frequency of congestion marking, approximate
preservation of the proportion of congestion marks arriving
and departing;
b. at low frequency of congestion marking, approximate
preservation of the timing of congestion marks arriving and
departing.
Perhaps:
Two possible design goals for propagating congestion indications,
described in Section 5.3 of [RFC3168] and Section 2.4 of [RFC7141], are:
1. approximate preservation of the presence (and therefore timing) of
congestion marks on the L2 frames used to construct an IP packet; and
2. approximate preservation of the proportion and timing at a high
and low frequency of congestion, respectively, of congestion marks
arriving and departing.
-->
<t>Two possible design goals for propagating congestion indications, <t>Two possible design goals for propagating congestion indications,
described in <xref section="5.3" target="RFC3168" format="default"/> and <xref section="2.4" target="RFC7141" format="default"/>, are:</t> described in <xref section="5.3" target="RFC3168" format="default"/> and <xref section="2.4" target="RFC7141" format="default"/>, are:</t>
<ol spacing="normal" type="1"><li anchor="ecnencap_reframing_goal_presen ce">approximate <ol spacing="normal" type="1"><li anchor="ecnencap_reframing_goal_presen ce">approximate
preservation of the presence (and therefore timing) of congestion preservation of the presence (and therefore timing) of congestion
marks on the L2 frames used to construct an IP packet;</li> marks on the L2 frames used to construct an IP packet;</li>
<li anchor="ecnencap_reframing_goal_proportion"> <li anchor="ecnencap_reframing_goal_proportion">
<ol spacing="normal" type="a"><li>at high frequency of congestion ma rking, approximate <ol spacing="normal" type="a"><li>at high frequency of congestion ma rking, approximate
preservation of the proportion of congestion marks arriving preservation of the proportion of congestion marks arriving
and departing;</li> and departing;</li>
<li>at low frequency of congestion marking, approximate <li>at low frequency of congestion marking, approximate
preservation of the timing of congestion marks arriving and preservation of the timing of congestion marks arriving and
departing.</li> departing.</li>
</ol> </ol>
</li> </li>
</ol> </ol>
<t>In either case, an implementation SHOULD ensure that any new <t>In either case, an implementation <bcp14>SHOULD</bcp14> ensure that a
incoming congestion indication is propagated immediately, not held ny new
incoming congestion indication is propagated immediately and not held
awaiting the possibility of further congestion indications to be awaiting the possibility of further congestion indications to be
sufficient to indicate congestion on an outgoing PDU <xref target="RFC71 41" format="default"/>. Nonetheless, to facilitate pipelined sufficient to indicate congestion on an outgoing PDU <xref target="RFC71 41" format="default"/>. Nonetheless, to facilitate pipelined
implementation, it would be acceptable for congestion marks to implementation, it would be acceptable for congestion marks to
propagate to a slightly later IP packet.</t> propagate to a slightly later IP packet.</t>
<t>At decapsulation in either case:</t> <t>
<ul spacing="normal"> At decapsulation in either case, ECN-marking propagation logically occurs
<li>ECN marking propagation logically occurs before application of before application of Decapsulation Guideline <xref format="counter"
Decapsulation Guideline <xref format="counter" target="ecnencap_drop target="ecnencap_dropNot-ECTinnerCEouter"/> in <xref
Not-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuidelines" format="defaul target="ecnencap_DecapGuidelines" format="default"/>.
t"/>. For instance, if ECN marking <!-- [rfced] For the following unordered list, we have reformatted the list
items below for readability (as it seems the last two list items were
intended to be sub-points of the first list item). Please review and let
us know any any further changes.
Original:
At decapsulation in either case:
* ECN marking propagation logically occurs before application of
Decapsulation Guideline 1 in Section 4.4. For instance, if ECN
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
is dropped in accordance with Guideline 1;
* where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the
same IP packet, the decapsulation spec SHOULD require that packet
to be discarded.
* 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
ECT(1) IP packets, the decapsulation spec might consider 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 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 far
allowed ECT(0) and ECT(1) to be considered equivalent [RFC3168],
or ECT(1) can provide a less severe congestion marking than CE
[RFC6040], or ECT(1) can indicate an unmarked but ECN-capable
packet that is subject to a different marking algorithm to ECT(0)
packets, for example L4S [RFC8311] [RFC9331].
Current:
At decapsulation in either case, ECN-marking propagation logically
occurs before application of Decapsulation Guideline 1 in
Section 4.4. For instance, if ECN 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 is dropped in accordance with
Guideline 1:
* where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the
same IP packet, the decapsulation spec SHOULD require that packet
to be discarded.
* 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
ECT(1) IP packets, the decapsulation specification might consider 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 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 far
allowed ECT(0) and ECT(1) to be considered equivalent [RFC3168];
otherwise, ECT(1) can provide a less severe congestion marking
than CE [RFC6040] or ECT(1) can indicate an unmarked but ECN-
capable packet that is subject to a different marking algorithm to
ECT(0) packets, e.g., L4S [RFC8311] [RFC9331].
-->
For instance, if ECN-marking
propagation would cause an ECN congestion indication to be applied propagation would cause an ECN congestion indication to be applied
to an IP packet that is a Not-ECN-PDU, then that IP packet is to an IP packet that is a Not-ECN-PDU, then that IP packet is
dropped in accordance with Guideline <xref format="counter" target=" dropped in accordance with Guideline <xref format="counter" target="
ecnencap_dropNot-ECTinnerCEouter"/>;</li> ecnencap_dropNot-ECTinnerCEouter"/>:</t>
<ul>
<li>where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the same <li>where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the same
IP packet, the decapsulation spec SHOULD require that packet to IP packet, the decapsulation specification <bcp14>SHOULD</bcp14> req uire that packet to
be discarded.</li> be discarded.</li>
<li>where a mix of different types of ECN-PDUs arrives to construct th e <li>where a mix of different types of ECN-PDUs arrives to construct th e
same IP packet, e.g.&nbsp;a mix of frames that map to ECT(0) and ECT same IP packet, e.g., a mix of frames that map to ECT(0) and ECT(1)
(1) IP packets, IP packets,
the decapsulation spec might consider this a protocol error. But, if the decapsulation specification might consider this a protocol error
the lower layer protocol has defined such a mix of types of ECN-PDU . But, if
as valid, it SHOULD the lower-layer protocol has defined such a mix of types of ECN-PDU
as valid, it <bcp14>SHOULD</bcp14>
require the resulting IP packet to be set to either ECT(0) or ECT(1) . require 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 In this case, it <bcp14>SHOULD</bcp14> take into account that the RF C Series has so
far allowed ECT(0) and ECT(1) to be considered far allowed ECT(0) and ECT(1) to be considered
equivalent <xref target="RFC3168" format="default"/>, or ECT(1) can equivalent <xref target="RFC3168" format="default"/>; otherwise, ECT (1) can
provide a less severe congestion marking provide a less severe congestion marking
than CE <xref target="RFC6040" format="default"/>, or ECT(1) can than CE <xref target="RFC6040" format="default"/> or ECT(1) can
indicate an unmarked but ECN-capable packet that is subject to a indicate an unmarked but ECN-capable packet that is subject to a
different marking algorithm to ECT(0) packets, for example L4S different marking algorithm to ECT(0) packets, e.g., L4S
<xref target="RFC8311" format="default"/> <xref target="RFC9331" for <xref target="RFC8311" format="default"/> <xref target="RFC9331" for
mat="default"/>.</li> mat="default"/>.</li></ul>
</ul>
<t>The following are two ways that goal <xref format="counter" target="e cnencap_reframing_goal_presence"/> might be achieved, but <t>The following are two ways that goal <xref format="counter" target="e cnencap_reframing_goal_presence"/> might be achieved, but
they are not intended to be the only ways:</t> they are not intended to be the only ways:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Every IP PDU that is constructed, in whole or in part, from an <li>Every IP PDU that is constructed, in whole or in part, from an
L2 frame that is marked with a congestion signal, has that signal L2 frame that is marked with a congestion signal has that signal
propagated to it;</li> propagated to it.</li>
<li>Every L2 frame that is marked with a congestion signal, <li>Every L2 frame that is marked with a congestion signal
propagates that signal to one IP PDU which is constructed, in propagates that signal to one IP PDU that is constructed from it in
whole or in part, from it. If multiple IP PDUs meet this whole or in part. If multiple IP PDUs meet this
description, the choice can be made arbitrarily but ought to be description, the choice can be made arbitrarily but ought to be
consistent.</li> consistent.</li>
</ul> </ul>
<t>The following gives one way that goal <xref format="counter" target=" ecnencap_reframing_goal_proportion"/> might be achieved, but <t>The following gives one way that goal <xref format="counter" target=" ecnencap_reframing_goal_proportion"/> might be achieved, but
it is not intended to be the only way:</t> it is not intended to be the only way:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For each of the streams of frames that encapsulate the IP packets of <li>For each of the streams of frames that encapsulate the IP packets of
each IP-ECN codepoint and follow the same path through the subnet, each IP-ECN codepoint and follow the same path through the subnet,
a counter ('in') tracks octets arriving a counter ('in') tracks octets arriving
within the payload of marked L2 frames and another ('out') tracks within the payload of marked L2 frames and another ('out') tracks
octets departing in marked IP packets. While 'in' exceeds 'out', octets departing in marked IP packets. While 'in' exceeds 'out',
forwarded IP packets are ECN-marked. If 'out' exceeds 'in' for forwarded IP packets are ECN-marked. If 'out' exceeds 'in' for
longer than a timeout, both counters are zeroed, to ensure that longer than a timeout, both counters are zeroed to ensure that
the start of the next congestion episode propagates immediately. the start of the next congestion episode propagates immediately.
The 'out' counter includes octets in reconstructed IP packets that The 'out' counter includes octets in reconstructed IP packets that
would have been marked, but had to be dropped because they were would have been marked, but had to be dropped because they were
Not-ECN-PDUs (by Decapsulation Guideline <xref format="counter" targ et="ecnencap_dropNot-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuideline s" format="default"/>).</li> Not-ECN-PDUs (by Decapsulation Guideline <xref format="counter" targ et="ecnencap_dropNot-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuideline s" format="default"/>).</li>
</ul> </ul>
<t>Generally, the number of L2 frames may be higher (e.g. ATM), <t>Generally, the number of L2 frames may be higher (e.g., ATM) than,
similar to, or lower (e.g. 802.11 aggregation at a L2-only station) similar to, or lower (e.g., 802.11 aggregation at an L2-only station)
than the number of IP PDUs, and this distinction may influence the than the number of IP PDUs; this distinction may influence the
choice of mechanism.</t> choice of mechanism.</t>
</section> </section>
</section> </section>
<section anchor="ecnencap_Guidelines_Up" numbered="true" toc="default"> <section anchor="ecnencap_Guidelines_Up" numbered="true" toc="default">
<name>Feed-Up-and-Forward Mode: Guidelines for Adding Congestion Notificat ion</name> <name>Feed-Up-and-Forward Mode: Guidelines for Adding Congestion Notificat ion</name>
<t>The guidance in this section is applicable, for example, when IP <t>The guidance in this section is applicable, for example, when IP
packets:</t> packets:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>are encapsulated in Ethernet headers, which have no support for <li>are encapsulated in Ethernet headers, which have no support for
ECN;</li> ECN;</li>
<li>are forwarded by the eNode-B (base station) of a 3GPP radio <li>are forwarded by the eNode-B (base station) of a 3GPP radio access
access network, which is required to apply ECN marking during network, which is required to apply ECN marking during congestion
congestion, <xref target="LTE-RA" format="default"/>, <xref target="UT <xref target="LTE-RA" format="default"/> <xref target="UTRAN"
RAN" format="default"/>, but the format="default"/>, but the Packet Data Convergence Protocol (PDCP)
Packet Data Convergence Protocol (PDCP) that encapsulates the IP that encapsulates the IP header over the radio access has no support
header over the radio access has no support for ECN.</li> for ECN.</li> </ul> <t>This guidance also generalizes to encapsulation
</ul> by other subnet technologies with no native support for ECN at the
<t>This guidance also generalizes to encapsulation by other subnet lower layer, but with support for finding and processing an IP
technologies with no native support for explicit congestion notification header. It is unlikely to be applicable or necessary for IP-in-IP
at the lower layer, but with support for finding and processing an IP encapsulation, where feed-forward-and-up mode based on <xref
header. It is unlikely to be applicable or necessary for IP-in-IP target="RFC6040" format="default"/> would be more appropriate.</t>
encapsulation, where feed-forward-and-up mode based on <xref target="RFC60 <t>Marking the IP header while switching at layer 2 (by using a Layer 3
40" format="default"/> would be more appropriate.</t>
<t>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 represent switch) or while forwarding in a radio access network seems to represent
a layering violation. However, it can be considered as a benign a layering violation. However, it can be considered as a benign
optimisation if the guidelines below are followed. Feed-up-and-forward optimization if the guidelines below are followed. Feed-up-and-forward
is certainly not a general alternative to implementing feed-forward is certainly not a general alternative to implementing feed-forward
congestion notification in the lower layer, because:</t> congestion notification in the lower layer, because:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>IPv4 and IPv6 are not the only layer-3 protocols that might be <li>IPv4 and IPv6 are not the only Layer 3 protocols that might be
encapsulated by lower layer protocols</li> encapsulated by lower-layer protocols.</li>
<li>Link-layer encryption might be in use, making the layer-2 payload <li>Link-layer encryption might be in use, making the Layer 2 payload
inaccessible</li> inaccessible.</li>
<li>Many Ethernet switches do not have 'layer-3 switch' capabilities <li>Many Ethernet switches do not have 'Layer 3 switch' capabilities,
so they cannot read or modify an IP payload</li> so they cannot read or modify an IP payload.</li>
<li>It might be costly to find an IP header (IPv4 or IPv6) when it may b e <li>It might be costly to find an IP header (IPv4 or IPv6) when it may b e
encapsulated by more than one lower layer header, e.g. Ethernet MAC encapsulated by more than one lower-layer header, e.g., Ethernet MAC
in MAC (<xref target="IEEE802.1Q" format="default"/>; previously 802.1 ah).</li> in MAC (<xref target="IEEE802.1Q" format="default"/>; previously 802.1 ah).</li>
</ul> </ul>
<t>Nonetheless, configuring lower layer equipment to look for an ECN <t>Nonetheless, configuring lower-layer equipment to look for an ECN
field in an encapsulated IP header is a useful optimisation. If the field in an encapsulated IP header is a useful optimization. If the
implementation follows the guidelines below, this optimisation does not implementation follows the guidelines below, this optimization does not
have to be confined to a controlled environment such as within a data have to be confined to a controlled environment, e.g., within a data
centre; it could usefully be applied on any network &mdash; even if the centre; it could usefully be applied on any network -- even if the
operator is not sure whether the above issues will never apply:</t> operator is not sure whether the above issues will never apply:</t>
<ol spacing="normal" type="1"><li>If a native lower-layer congestion notif ication mechanism exists <ol spacing="normal" type="1"><li>If a native lower-layer congestion notif ication mechanism exists
for a subnet technology, it is safe to mix feed-up-and-forward with for a subnet technology, it is safe to mix feed-up-and-forward with
feed-forward-and-up on other switches in the same subnet. However, feed-forward-and-up on other switches in the same subnet. However,
it will generally be more efficient to use the native mechanism.</li> it will generally be more efficient to use the native mechanism.</li>
<li>The depth of the search for an IP header SHOULD be limited. If an <li>The depth of the search for an IP header <bcp14>SHOULD</bcp14> be li mited. If an
IP header is not found soon enough, or an unrecognized or unreadable IP header is not found soon enough, or an unrecognized or unreadable
header is encountered, the switch SHOULD resort to an alternative header is encountered, the switch <bcp14>SHOULD</bcp14> resort to an a
means of signalling congestion (e.g. drop, or the native lower layer lternative
means of signalling congestion (e.g., drop or the native lower-layer
mechanism if available).</li> mechanism if available).</li>
<li>It is sufficient to use the first IP header found in the stack; <li>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.</li> later.</li>
</ol> </ol>
</section> </section>
<section anchor="ecnencap_Guidelines_Backward" numbered="true" toc="default" > <section anchor="ecnencap_Guidelines_Backward" numbered="true" toc="default" >
<name>Feed-Backward Mode: Guidelines for Adding Congestion Notification</n ame> <name>Feed-Backward Mode: Guidelines for Adding Congestion Notification</n ame>
<t>It can be seen from <xref target="ecnencap_Backward" format="default"/> that <t>It can be seen from <xref target="ecnencap_Backward" format="default"/> that
congestion notification in a subnet using feed-backward mode has congestion notifications in a subnet using feed-backward mode have
generally not been designed to be directly coupled with IP layer generally not been designed to be directly coupled with IP-layer
congestion notification. The subnet attempts to minimize congestion congestion notifications. The subnet attempts to minimize congestion
internally, and if the incoming load at the ingress exceeds the capacity internally, and if the incoming load at the ingress exceeds the capacity
somewhere through the subnet, the layer 3 buffer into the ingress backs somewhere through the subnet, the Layer 3 buffer into the ingress backs
up. Thus, a feed-backward mode subnet is in some sense similar to a null up. Thus, a feed-backward mode subnet is in some sense similar to a null
mode subnet, in that there is no need for any direct interaction between mode subnet, in that there is no need for any direct interaction between
the subnet and higher layer congestion notification. Therefore no the subnet and higher-layer congestion notifications. Therefore, no
detailed protocol design guidelines are appropriate. Nonetheless, a more detailed protocol design guidelines are appropriate. Nonetheless, a more
general guideline is appropriate: </t> general guideline is appropriate: </t>
<ul empty="true" spacing="normal"> <blockquote>A subnetwork technology intended to eventually interface
<li>A subnetwork technology intended to eventually interface to IP to IP <bcp14>SHOULD NOT</bcp14> be designed using only the
SHOULD NOT be designed using only the feed-backward mode, which is feed-backward mode, which is certainly best for a stand-alone subnet,
certainly best for a stand-alone subnet, but would need to be but would need to be modified to work efficiently as part of the wider
modified to work efficiently as part of the wider Internet, because Internet because IP uses feed-forward-and-up mode.</blockquote>
IP uses feed-forward-and-up mode.</li>
</ul>
<t>The feed-backward approach at least works beneath IP, where the term <t>The feed-backward approach at least works beneath IP, where the term
'works' is used only in a narrow functional sense because feed-backward 'works' is used only in a narrow functional sense because feed-backward
can result in very inefficient and sluggish congestion control &mdash; can result in very inefficient and sluggish congestion control --
except if it is confined to the subnet directly connected to the except if it is confined to the subnet directly connected to the
original data source, when it is faster than feed-forward. It would be original data source when it is faster than feed-forward. It would be
valid to design a protocol that could work in feed-backward mode for valid to design a protocol that could work in feed-backward mode for
paths that only cross one subnet, and in feed-forward-and-up mode for paths that only cross one subnet, and in feed-forward-and-up mode for
paths that cross subnets.</t> paths that cross subnets.</t>
<t>In the early days of TCP/IP, a similar feed-backward approach was <t>In the early days of TCP/IP, a similar feed-backward approach was
tried for explicit congestion signalling, using source-quench (SQ) ICMP tried for explicit congestion signalling using source-quench (SQ) ICMP
control packets. However, SQ fell out of favour and is now formally control packets. However, SQ fell out of favour and is now formally
deprecated <xref target="RFC6633" format="default"/>. The main problem was that it is deprecated <xref target="RFC6633" format="default"/>. The main problem was that it is
hard for a data source to tell the difference between a spoofed SQ hard for a data source to tell the difference between a spoofed SQ
message and a quench request from a genuine buffer on the path. It is message and a quench request from a genuine buffer on the path. It is
also hard for a lower layer buffer to address an SQ message to the also hard for a lower-layer buffer to address an SQ message to the
original source port number, which may be buried within many layers of original source port number, which may be buried within many layers of
headers, and possibly encrypted.</t> headers and possibly encrypted.</t>
<t>QCN (also known as backward congestion notification, BCN; see <t>QCN (also known as Backward Congestion Notification (BCN); see
Sections 30&ndash;33 of <xref target="IEEE802.1Q" format="default"/>; prev Sections 30-33 of <xref target="IEEE802.1Q" format="default"/>, previously
iously known as known as
802.1Qau) uses a feed-backward mode structurally similar to ATM's 802.1Qau) uses a feed-backward mode that is structurally similar to ATM's
relative rate mechanism. However, QCN confines its applicability to relative rate mechanism. However, QCN confines its applicability to
scenarios such as some data centres where all endpoints are directly scenarios such as some data centres where all endpoints are directly
attached by the same Ethernet technology. If a QCN subnet were later attached by the same Ethernet technology. If a QCN subnet were later
connected into a wider IP-based internetwork (e.g. when attempting to connected into a wider IP-based internetwork (e.g., when attempting to
interconnect multiple data centres) it would suffer the inefficiency interconnect multiple data centres) it would suffer the inefficiency
shown in <xref target="ecnencap_Fig_Feed-Backward" format="default"/>.</t> shown in <xref target="ecnencap_Fig_Feed-Backward" format="default"/>.</t>
<!--{ToDo - either make this a separate case, move it to modes, or delete it} <!--{ToDo - either make this a separate case, move it to modes, or delete it}
In some circumstances (e.g. pseudowire emulations with link-local flow control), the whole In some circumstances (e.g. pseudowire emulations with link-local flow control), the whole
path is divided into segments, each with its own congestion notification and fee dback loop. path is divided into segments, each with its own congestion notification and fee dback loop.
In these cases, the function that regulates load at the start of each segment wi ll need to In these cases, the function that regulates load at the start of each segment wi ll need to
reset congestion notification (i.e. clear any accumulated congestion notificatio ns) at the reset congestion notification (i.e. clear any accumulated congestion notificatio ns) at the
start of its segment.--> start of its segment.-->
</section> </section>
<!-- ================================================================ --> <section anchor="ecnencap_IANA_Considerations" numbered="true" toc="default"
>
<section anchor="ecnencap_IANA_Considerations" removeInRFC="true" numbered="
true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo includes no request to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<!-- ================================================================ -->
<section anchor="ecnencap_Security_Considerations" numbered="true" toc="defa ult"> <section anchor="ecnencap_Security_Considerations" numbered="true" toc="defa ult">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>If a lower layer wire protocol is redesigned to include explicit <t>If a lower-layer wire protocol is redesigned to include explicit
congestion signalling in-band in the protocol header, care SHOULD be congestion signalling in-band in the protocol header, care <bcp14>SHOULD</
bcp14> be
taken to ensure that the field used is specified as mutable during taken to ensure that the field used is specified as mutable during
transit. Otherwise interior nodes signalling congestion would invalidate transit. Otherwise, interior nodes signalling congestion would invalidate
any authentication protocol applied to the lower layer header &mdash; by any authentication protocol applied to the lower-layer header -- by
altering a header field that had been assumed as immutable.</t> altering a header field that had been assumed as immutable.</t>
<t>The redesign of protocols that encapsulate IP in order to propagate <t>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, e.g.:</t> end-to-end integrity of in-band congestion signals, such as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Congestion exposure (ConEx) for networks to audit that their <li>Congestion exposure (ConEx) for networks to audit that their
congestion signals are not being suppressed by other networks or by congestion signals are not being suppressed by other networks or by
receivers, and for networks to police that senders are responding receivers, and to police that senders are responding
sufficiently to the signals, irrespective of the L4 transport sufficiently to the signals, irrespective of the L4 transport
protocol used <xref target="RFC7713" format="default"/>.</li> protocol used <xref target="RFC7713" format="default"/>.</li>
<li>A test for a sender to detect whether a network or the receiver <li>A test for a sender to detect whether a network or the receiver
is suppressing congestion signals (for example see 2nd para of <xref s ection="20.2" target="RFC3168" format="default"/>).</li> is suppressing congestion signals (for example, see the second paragra ph of <xref section="20.2" target="RFC3168" format="default"/>).</li>
</ul> </ul>
<t>Given these end-to-end approaches are already being specified, <t>Given these end-to-end approaches are already being specified,
it would make little sense to attempt to design hop-by-hop congestion it would make little sense to attempt to design hop-by-hop congestion
signal integrity into a new lower layer protocol, because end-to-end signal integrity into a new lower-layer protocol because end-to-end
integrity inherently achieves hop-by-hop integrity.</t> integrity inherently achieves hop-by-hop integrity.</t>
<t><xref target="ecnencap_Guidelines_Backward" format="default"/> gives vu lnerability to <t><xref target="ecnencap_Guidelines_Backward" format="default"/> gives vu lnerability to
spoofing as one of the reasons for deprecating feed-backward mode.</t> spoofing as one of the reasons for deprecating feed-backward mode.</t>
</section> </section>
<!-- ================================================================ -->
<section anchor="ecnencap_Conclusions" numbered="true" toc="default"> <section anchor="ecnencap_Conclusions" numbered="true" toc="default">
<name>Conclusions</name> <name>Conclusions</name>
<t>Following the guidance in this document enables ECN support to be <t>Following the guidance in this document enables ECN support to be
extended consistently to numerous protocols that encapsulate IP (IPv4 and extended consistently to numerous protocols that encapsulate IP (IPv4 and
IPv6), so that IP continues to fulfil its role as an end-to-end IPv6) so that IP continues to fulfil its role as an end-to-end
interoperability layer. This includes:</t> interoperability layer. This includes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A wide range of tunnelling protocols including those with various <li>A wide range of tunnelling protocols, including those with various
forms of shim header between two IP headers, possibly also separated forms of a shim header between two IP headers, possibly also separated
by a L2 header;</li> by an L2 header;</li>
<li>A wide range of subnet technologies, particularly those that work <li>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.</li> in IP and MPLS.</li>
</ul> </ul>
<t>Guidelines have been defined for supporting propagation of ECN <t>Guidelines have been defined for supporting propagation of ECN
between Ethernet and IP on so-called Layer-3 Ethernet switches, using a between Ethernet and IP on so-called Layer 3 Ethernet switches using a
'feed-up-and-forward' mode. This approach could enable other subnet 'feed-up-and-forward' mode. This approach could enable other subnet
technologies to pass ECN signals into the IP layer, even if they do not technologies to pass ECN signals into the IP layer, even if they do not
support ECN natively.</t> support ECN natively.</t>
<t>Finally, attempting to add ECN to a subnet technology in <t>Finally, attempting to add ECN to a subnet technology in
feed-backward mode is deprecated except in special cases, due to its feed-backward mode is deprecated except in special cases due to its
likely sluggish response to congestion.</t> likely sluggish response to congestion.</t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- ================================================================ -->
<displayreference target="I-D.ietf-intarea-gue" to="INTAREA-GUE"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.31
le> 68.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.38
<date month="March" year="1997"/> 19.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.47
<t>In many standards track documents several words are used to sig 74.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.51
his document defines these words as they should be interpreted in IETF documents 29.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
mmunity, and requests discussion and suggestions for improvements.</t> 40.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.71
</front> 41.xml"/>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/> <!-- [I-D.ietf-trill-ecn-support] REF state as of 04/29/2024; companion doc RFC9
<seriesInfo name="DOI" value="10.17487/RFC2119"/> 600 -->
</reference> <reference anchor="RFC9600" target="https://www.rfc-editor.org/info/rfc9600">
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3 <front>
168" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"> <title>
<front> TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion N
<title>The Addition of Explicit Congestion Notification (ECN) to IP< otification) Support
/title> </title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishn <author initials="D." surname="Eastlake" fullname="Donald E. Eastlake 3rd">
an"/> <organization>Huawei</organization>
<author fullname="S. Floyd" initials="S." surname="Floyd"/> </author>
<author fullname="D. Black" initials="D." surname="Black"/> <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
<date month="September" year="2001"/> <organization>CableLabs</organization>
<abstract> </author>
<t>This memo specifies the incorporation of ECN (Explicit Congesti <date month="June" year="2024"/>
on Notification) to TCP and IP, including ECN's use of two bits in the IP header </front>
. [STANDARDS-TRACK]</t> <seriesInfo name="RFC" value="9600"/>
</abstract> <seriesInfo name="DOI" value="10.17487/RFC9600"/>
</front> </reference>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC3819" target="https://www.rfc-editor.org/info/rfc3
819" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3819.xml">
<front>
<title>Advice for Internet Subnetwork Designers</title>
<author fullname="P. Karn" initials="P." role="editor" surname="Karn
"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="D. Grossman" initials="D." surname="Grossman"/>
<author fullname="R. Ludwig" initials="R." surname="Ludwig"/>
<author fullname="J. Mahdavi" initials="J." surname="Mahdavi"/>
<author fullname="G. Montenegro" initials="G." surname="Montenegro"/
>
<author fullname="J. Touch" initials="J." surname="Touch"/>
<author fullname="L. Wood" initials="L." surname="Wood"/>
<date month="July" year="2004"/>
<abstract>
<t>This document provides advice to the designers of digital commu
nication equipment, link-layer protocols, and packet-switched local networks (co
llectively referred to as subnetworks), who wish to support the Internet protoco
ls but may be unfamiliar with the Internet architecture and the implications of
their design choices on the performance and efficiency of the Internet. This doc
ument specifies an Internet Best Current Practices for the Internet Community, a
nd requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="89"/>
<seriesInfo name="RFC" value="3819"/>
<seriesInfo name="DOI" value="10.17487/RFC3819"/>
</reference>
<reference anchor="RFC4774" target="https://www.rfc-editor.org/info/rfc4
774" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml">
<front>
<title>Specifying Alternate Semantics for the Explicit Congestion No
tification (ECN) Field</title>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<date month="November" year="2006"/>
<abstract>
<t>There have been a number of proposals for alternate semantics f
or the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. T
his document discusses some of the issues in defining alternate semantics for th
e ECN field, and specifies requirements for a safe coexistence in an Internet th
at could include routers that do not understand the defined alternate semantics.
This document evolved as a result of discussions with the authors of one recent
proposal for such alternate semantics. This document specifies an Internet Best
Current Practices for the Internet Community, and requests discussion and sugge
stions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="124"/>
<seriesInfo name="RFC" value="4774"/>
<seriesInfo name="DOI" value="10.17487/RFC4774"/>
</reference>
<reference anchor="RFC5129" target="https://www.rfc-editor.org/info/rfc5
129" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml">
<front>
<title>Explicit Congestion Marking in MPLS</title>
<author fullname="B. Davie" initials="B." surname="Davie"/>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<author fullname="J. Tay" initials="J." surname="Tay"/>
<date month="January" year="2008"/>
<abstract>
<t>RFC 3270 defines how to support the Diffserv architecture in MP
LS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS hea
der. DSCPs may be encoded in the EXP field, while other uses of that field are n
ot precluded. RFC 3270 makes no statement about how Explicit Congestion Notifica
tion (ECN) marking might be encoded in the MPLS header. This document defines ho
w an operator might define some of the EXP codepoints for explicit congestion no
tification, without precluding other uses. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5129"/>
<seriesInfo name="DOI" value="10.17487/RFC5129"/>
</reference>
<reference anchor="RFC6040" target="https://www.rfc-editor.org/info/rfc6
040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<front>
<title>Tunnelling of Explicit Congestion Notification</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<date month="November" year="2010"/>
<abstract>
<t>This document redefines how the explicit congestion notificatio
n (ECN) field of the IP header should be constructed on entry to and exit from a
ny IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP
tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulatio
n, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously un
used combinations of inner and outer headers. The new rules ensure the ECN field
is correctly propagated across a tunnel whether it is used to signal one or two
severity levels of congestion; whereas before, only one severity level was supp
orted. Tunnel endpoints can be updated in any order without affecting pre-existi
ng uses of the ECN field, thus ensuring backward compatibility. Nonetheless, ope
rators wanting to support two severity levels (e.g., for pre-congestion notifica
tion -- PCN) can require compliance with this new specification. A thorough anal
ysis of the reasoning for these changes and the implications is included. In the
unlikely event that the new rules do not meet a specific need, RFC 4774 gives g
uidance on designing alternate ECN semantics, and this document extends that to
include tunnelling issues. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6040"/>
<seriesInfo name="DOI" value="10.17487/RFC6040"/>
</reference>
<reference anchor="RFC7141" target="https://www.rfc-editor.org/info/rfc7
141" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7141.xml">
<front>
<title>Byte and Packet Congestion Notification</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<author fullname="J. Manner" initials="J." surname="Manner"/>
<date month="February" year="2014"/>
<abstract>
<t>This document provides recommendations of best current practice
for dropping or marking packets using any active queue management (AQM) algorit
hm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (
PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional I
ntegral controller Enhanced). We give three strong recommendations: (1) packet s
ize should be taken into account when transports detect and respond to congestio
n indications, (2) packet size should not be taken into account when network equ
ipment creates congestion signals (marking, dropping), and therefore (3) in the
specific case of RED, the byte- mode packet drop variant that drops fewer small
packets should not be used. This memo updates RFC 2309 to deprecate deliberate p
referential treatment of small packets in AQM algorithms.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="41"/>
<seriesInfo name="RFC" value="7141"/>
<seriesInfo name="DOI" value="10.17487/RFC7141"/>
</reference>
<reference anchor="I-D.ietf-trill-ecn-support" target="https://datatrack
er.ietf.org/doc/html/draft-ietf-trill-ecn-support-07" xml:base="https://bib.ietf
.org/public/rfc/bibxml-ids/reference.I-D.ietf-trill-ecn-support.xml">
<front>
<title>TRILL (TRansparent Interconnection of Lots of Links): ECN (Ex
plicit Congestion Notification) Support</title>
<author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="
Eastlake">
<organization>Huawei</organization>
</author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>CableLabs</organization>
</author>
<date day="25" month="February" year="2018"/>
<abstract>
<t>Explicit congestion notification (ECN) allows a forwarding elem
ent to notify downstream devices, including the destination, of the onset of con
gestion without having to drop packets. This can improve network efficiency thro
ugh better congestion control without packet drops. This document extends ECN to
TRILL (TRansparent Interconnection of Lots of Links) switches, including integr
ation with IP ECN, and provides for ECN marking in the TRILL Header Extension Fl
ags Word (see RFC 7179).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-trill-ecn-support-
07"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC2003" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.20
003" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"> 03.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.24
<title>IP Encapsulation within IP</title> 73.xml"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.26
<date month="October" year="1996"/> 37.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.26
<t>This document specifies a method by which an IP datagram may be 61.xml"/>
encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.27
</abstract> 84.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.28
<seriesInfo name="RFC" value="2003"/> 84.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2003"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.29
</reference> 83.xml"/>
<reference anchor="RFC2473" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
473" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2473.xml"> 31.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
<title>Generic Packet Tunneling in IPv6 Specification</title> 01.xml"/>
<author fullname="A. Conta" initials="A." surname="Conta"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
<author fullname="S. Deering" initials="S." surname="Deering"/> 80.xml"/>
<date month="December" year="1998"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
<abstract> 15.xml"/>
<t>This document defines the model and generic mechanisms for IPv6 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.66
encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]</t> 33.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.66
</front> 60.xml"/>
<seriesInfo name="RFC" value="2473"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.73
<seriesInfo name="DOI" value="10.17487/RFC2473"/> 23.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.73
<reference anchor="RFC2637" target="https://www.rfc-editor.org/info/rfc2 48.xml"/>
637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2637.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
<front> 80.xml"/>
<title>Point-to-Point Tunneling Protocol (PPTP)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
<author fullname="K. Hamzeh" initials="K." surname="Hamzeh"/> 67.xml"/>
<author fullname="G. Pall" initials="G." surname="Pall"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76
<author fullname="W. Verthein" initials="W." surname="Verthein"/> 37.xml"/>
<author fullname="J. Taarud" initials="J." surname="Taarud"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
<author fullname="W. Little" initials="W." surname="Little"/> 13.xml"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<date month="July" year="1999"/> 84.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<t>This document specifies a protocol which allows the Point to Po 87.xml"/>
int Protocol (PPP) to be tunneled through an IP network. This memo provides info <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
rmation for the Internet community.</t> 74.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
</front> 57.xml"/>
<seriesInfo name="RFC" value="2637"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<seriesInfo name="DOI" value="10.17487/RFC2637"/> 00.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<reference anchor="RFC2661" target="https://www.rfc-editor.org/info/rfc2 11.xml"/>
661" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
<front> 26.xml"/>
<title>Layer Two Tunneling Protocol "L2TP"</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<author fullname="W. Townsley" initials="W." surname="Townsley"/> 00.xml"/>
<author fullname="A. Valencia" initials="A." surname="Valencia"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<author fullname="A. Rubens" initials="A." surname="Rubens"/> 31.xml"/>
<author fullname="G. Pall" initials="G." surname="Pall"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/> <!-- [I-D.ietf-intarea-gue] IESG State: Expired (IESG: Dead) as of 02/12/2024-->
<author fullname="B. Palter" initials="B." surname="Palter"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-in
<date month="August" year="1999"/> tarea-gue.xml"/>
<abstract>
<t>This document describes the Layer Two Tunneling Protocol (L2TP) <!-- [I-D.ietf-tsvwg-rfc6040update-shim] REF state as of 04/29/2024; companion d
. [STANDARDS-TRACK]</t> oc RFC9601-->
</abstract> <reference anchor="RFC9601" target="https://www.rfc-editor.org/info/rfc9601">
</front> <front>
<seriesInfo name="RFC" value="2661"/> <title>
<seriesInfo name="DOI" value="10.17487/RFC2661"/> Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated
</reference> by a Shim
<reference anchor="RFC2784" target="https://www.rfc-editor.org/info/rfc2 </title>
784" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"> <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
<front> <organization>Independent</organization>
<title>Generic Routing Encapsulation (GRE)</title> </author>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/> <date month="June" year="2024"/>
<author fullname="T. Li" initials="T." surname="Li"/> </front>
<author fullname="S. Hanks" initials="S." surname="Hanks"/> <seriesInfo name="RFC" value="9601"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/> <seriesInfo name="DOI" value="10.17487/RFC9601"/>
<author fullname="P. Traina" initials="P." surname="Traina"/> </reference>
<date month="March" year="2000"/>
<abstract> <reference anchor="IEEE802.1Q">
<t>This document specifies a protocol for encapsulation of an arbi
trary network layer protocol over another arbitrary network layer protocol. [STA
NDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2784"/>
<seriesInfo name="DOI" value="10.17487/RFC2784"/>
</reference>
<reference anchor="RFC2884" target="https://www.rfc-editor.org/info/rfc2
884" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2884.xml">
<front>
<title>Performance Evaluation of Explicit Congestion Notification (E
CN) in IP Networks</title>
<author fullname="J. Hadi Salim" initials="J." surname="Hadi Salim"/
>
<author fullname="U. Ahmed" initials="U." surname="Ahmed"/>
<date month="July" year="2000"/>
<abstract>
<t>This memo presents a performance study of the Explicit Congesti
on Notification (ECN) mechanism in the TCP/IP protocol using our implementation
on the Linux Operating System. This memo provides information for the Internet c
ommunity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2884"/>
<seriesInfo name="DOI" value="10.17487/RFC2884"/>
</reference>
<reference anchor="RFC2983" target="https://www.rfc-editor.org/info/rfc2
983" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml">
<front>
<title>Differentiated Services and Tunnels</title>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="October" year="2000"/>
<abstract>
<t>This document considers the interaction of Differentiated Servi
ces (diffserv) with IP tunnels of various forms. This memo provides information
for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2983"/>
<seriesInfo name="DOI" value="10.17487/RFC2983"/>
</reference>
<reference anchor="RFC3931" target="https://www.rfc-editor.org/info/rfc3
931" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml">
<front>
<title>Layer Two Tunneling Protocol - Version 3 (L2TPv3)</title>
<author fullname="J. Lau" initials="J." role="editor" surname="Lau"/
>
<author fullname="M. Townsley" initials="M." role="editor" surname="
Townsley"/>
<author fullname="I. Goyret" initials="I." role="editor" surname="Go
yret"/>
<date month="March" year="2005"/>
<abstract>
<t>This document describes "version 3" of the Layer Two Tunneling
Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation fo
r tunneling multiple Layer 2 connections between two IP nodes. Additional docume
nts detail the specifics for each data link type being emulated. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3931"/>
<seriesInfo name="DOI" value="10.17487/RFC3931"/>
</reference>
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
301" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<author fullname="K. Seo" initials="K." surname="Seo"/>
<date month="December" year="2005"/>
<abstract>
<t>This document describes an updated version of the "Security Arc
hitecture for IP", which is designed to provide security services for traffic at
the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="RFC4380" target="https://www.rfc-editor.org/info/rfc4
380" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml">
<front>
<title>Teredo: Tunneling IPv6 over UDP through Network Address Trans
lations (NATs)</title>
<author fullname="C. Huitema" initials="C." surname="Huitema"/>
<date month="February" year="2006"/>
<abstract>
<t>We propose here a service that enables nodes located behind one
or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by
tunneling packets over UDP; we call this the Teredo service. Running the servic
e requires the help of "Teredo servers" and "Teredo relays". The Teredo servers
are stateless, and only have to manage a small fraction of the traffic between T
eredo clients; the Teredo relays act as IPv6 routers between the Teredo service
and the "native" IPv6 Internet. The relays can also provide interoperability wit
h hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4380"/>
<seriesInfo name="DOI" value="10.17487/RFC4380"/>
</reference>
<reference anchor="RFC5415" target="https://www.rfc-editor.org/info/rfc5
415" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml">
<front>
<title>Control And Provisioning of Wireless Access Points (CAPWAP) P
rotocol Specification</title>
<author fullname="P. Calhoun" initials="P." role="editor" surname="C
alhoun"/>
<author fullname="M. Montemurro" initials="M." role="editor" surname
="Montemurro"/>
<author fullname="D. Stanley" initials="D." role="editor" surname="S
tanley"/>
<date month="March" year="2009"/>
<abstract>
<t>This specification defines the Control And Provisioning of Wire
less Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPW
AP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, al
lowing it to be used for a variety of wireless technologies. This document descr
ibes the base CAPWAP protocol, while separate binding extensions will enable its
use with additional wireless technologies. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5415"/>
<seriesInfo name="DOI" value="10.17487/RFC5415"/>
</reference>
<reference anchor="RFC6633" target="https://www.rfc-editor.org/info/rfc6
633" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6633.xml">
<front>
<title>Deprecation of ICMP Source Quench Messages</title>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<date month="May" year="2012"/>
<abstract>
<t>This document formally deprecates the use of ICMP Source Quench
messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1
812. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6633"/>
<seriesInfo name="DOI" value="10.17487/RFC6633"/>
</reference>
<reference anchor="RFC6660" target="https://www.rfc-editor.org/info/rfc6
660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
<front>
<title>Encoding Three Pre-Congestion Notification (PCN) States in th
e IP Header Using a Single Diffserv Codepoint (DSCP)</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<author fullname="T. Moncaster" initials="T." surname="Moncaster"/>
<author fullname="M. Menth" initials="M." surname="Menth"/>
<date month="July" year="2012"/>
<abstract>
<t>The objective of Pre-Congestion Notification (PCN) is to protec
t the quality of service (QoS) of inelastic flows within a Diffserv domain. The
overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN
-packets are appropriately marked when certain configured rates are exceeded. Eg
ress nodes pass information about these PCN-marks to Decision Points that then d
ecide whether to admit or block new flow requests or to terminate some already a
dmitted flows during serious pre-congestion.</t>
<t>This document specifies how PCN-marks are to be encoded into th
e IP header by reusing the Explicit Congestion Notification (ECN) codepoints wit
hin a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to
be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for
MPLS in an informational appendix. The encoding for IP provides for up to three
different PCN marking states using a single Diffserv codepoint (DSCP): not-mark
ed (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is c
alled the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6660"/>
<seriesInfo name="DOI" value="10.17487/RFC6660"/>
</reference>
<reference anchor="RFC7323" target="https://www.rfc-editor.org/info/rfc7
323" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml">
<front>
<title>TCP Extensions for High Performance</title>
<author fullname="D. Borman" initials="D." surname="Borman"/>
<author fullname="B. Braden" initials="B." surname="Braden"/>
<author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
<author fullname="R. Scheffenegger" initials="R." role="editor" surn
ame="Scheffenegger"/>
<date month="September" year="2014"/>
<abstract>
<t>This document specifies a set of TCP extensions to improve perf
ormance over paths with a large bandwidth * delay product and to provide reliabl
e operation over very high-speed paths. It defines the TCP Window Scale (WS) opt
ion and the TCP Timestamps (TS) option and their semantics. The Window Scale opt
ion is used to support larger receive windows, while the Timestamps option can b
e used for at least two distinct mechanisms, Protection Against Wrapped Sequence
s (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.
</t>
<t>This document obsoletes RFC 1323 and describes changes from it.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7323"/>
<seriesInfo name="DOI" value="10.17487/RFC7323"/>
</reference>
<reference anchor="RFC7348" target="https://www.rfc-editor.org/info/rfc7
348" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml">
<front>
<title>Virtual eXtensible Local Area Network (VXLAN): A Framework fo
r Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
<author fullname="M. Mahalingam" initials="M." surname="Mahalingam"/
>
<author fullname="D. Dutt" initials="D." surname="Dutt"/>
<author fullname="K. Duda" initials="K." surname="Duda"/>
<author fullname="P. Agarwal" initials="P." surname="Agarwal"/>
<author fullname="L. Kreeger" initials="L." surname="Kreeger"/>
<author fullname="T. Sridhar" initials="T." surname="Sridhar"/>
<author fullname="M. Bursell" initials="M." surname="Bursell"/>
<author fullname="C. Wright" initials="C." surname="Wright"/>
<date month="August" year="2014"/>
<abstract>
<t>This document describes Virtual eXtensible Local Area Network (
VXLAN), which is used to address the need for overlay networks within virtualize
d data centers accommodating multiple tenants. The scheme and the related protoc
ols can be used in networks for cloud service providers and enterprise data cent
ers. This memo documents the deployed VXLAN protocol for the benefit of the Inte
rnet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7348"/>
<seriesInfo name="DOI" value="10.17487/RFC7348"/>
</reference>
<reference anchor="RFC7780" target="https://www.rfc-editor.org/info/rfc7
780" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7780.xml">
<front>
<title>Transparent Interconnection of Lots of Links (TRILL): Clarifi
cations, Corrections, and Updates</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="M. Zhang" initials="M." surname="Zhang"/>
<author fullname="R. Perlman" initials="R." surname="Perlman"/>
<author fullname="A. Banerjee" initials="A." surname="Banerjee"/>
<author fullname="A. Ghanwani" initials="A." surname="Ghanwani"/>
<author fullname="S. Gupta" initials="S." surname="Gupta"/>
<date month="February" year="2016"/>
<abstract>
<t>Since the publication of the TRILL (Transparent Interconnection
of Lots of Links) base protocol in 2011, active development and deployment of T
RILL have revealed errata in RFC 6325 and areas that could use clarifications or
updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide cl
arifications and updates with respect to adjacency, the TRILL ESADI (End Station
Address Distribution Information) protocol, and Appointed Forwarders, respectiv
ely. This document provides other known clarifications, corrections, and updates
. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and up
dates" RFC), and it updates RFCs 6325, 7177, and 7179.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7780"/>
<seriesInfo name="DOI" value="10.17487/RFC7780"/>
</reference>
<reference anchor="RFC7567" target="https://www.rfc-editor.org/info/rfc7
567" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml">
<front>
<title>IETF Recommendations Regarding Active Queue Management</title
>
<author fullname="F. Baker" initials="F." role="editor" surname="Bak
er"/>
<author fullname="G. Fairhurst" initials="G." role="editor" surname=
"Fairhurst"/>
<date month="July" year="2015"/>
<abstract>
<t>This memo presents recommendations to the Internet community co
ncerning measures to improve and preserve Internet performance. It presents a st
rong recommendation for testing, standardization, and widespread deployment of a
ctive queue management (AQM) in network devices to improve the performance of to
day's Internet. It also urges a concerted effort of research, measurement, and u
ltimate deployment of AQM mechanisms to protect the Internet from flows that are
not sufficiently responsive to congestion notification.</t>
<t>Based on 15 years of experience and new research, this document
replaces the recommendations of RFC 2309.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="197"/>
<seriesInfo name="RFC" value="7567"/>
<seriesInfo name="DOI" value="10.17487/RFC7567"/>
</reference>
<reference anchor="RFC7637" target="https://www.rfc-editor.org/info/rfc7
637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml">
<front>
<title>NVGRE: Network Virtualization Using Generic Routing Encapsula
tion</title>
<author fullname="P. Garg" initials="P." role="editor" surname="Garg
"/>
<author fullname="Y. Wang" initials="Y." role="editor" surname="Wang
"/>
<date month="September" year="2015"/>
<abstract>
<t>This document describes the usage of the Generic Routing Encaps
ulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data cen
ters. Network Virtualization decouples virtual networks and addresses from physi
cal network infrastructure, providing isolation and concurrency between multiple
virtual networks on the same physical network infrastructure. This document als
o introduces a Network Virtualization framework to illustrate the use cases, but
the focus is on specifying the data-plane aspect of NVGRE.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7637"/>
<seriesInfo name="DOI" value="10.17487/RFC7637"/>
</reference>
<reference anchor="RFC7713" target="https://www.rfc-editor.org/info/rfc7
713" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml">
<front>
<title>Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and
Requirements</title>
<author fullname="M. Mathis" initials="M." surname="Mathis"/>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<date month="December" year="2015"/>
<abstract>
<t>This document describes an abstract mechanism by which senders
inform the network about the congestion recently encountered by packets in the s
ame flow. Today, network elements at any layer may signal congestion to the rece
iver by dropping packets or by Explicit Congestion Notification (ECN) markings,
and the receiver passes this information back to the sender in transport-layer f
eedback. The mechanism described here enables the sender to also relay this cong
estion information back into the network in-band at the IP layer, such that the
total amount of congestion from all elements on the path is revealed to all IP e
lements along the path, where it could, for example, be used to provide input to
traffic management. This mechanism is called Congestion Exposure, or ConEx. The
companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6
789), provides the entry point to the set of ConEx documentation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7713"/>
<seriesInfo name="DOI" value="10.17487/RFC7713"/>
</reference>
<reference anchor="RFC8084" target="https://www.rfc-editor.org/info/rfc8
084" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8084.xml">
<front>
<title>Network Transport Circuit Breakers</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<date month="March" year="2017"/>
<abstract>
<t>This document explains what is meant by the term "network trans
port Circuit Breaker". It describes the need for Circuit Breakers (CBs) for netw
ork tunnels and applications when using non-congestion- controlled traffic and e
xplains where CBs are, and are not, needed. It also defines requirements for bui
lding a CB and the expected outcomes of using a CB within the Internet.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="208"/>
<seriesInfo name="RFC" value="8084"/>
<seriesInfo name="DOI" value="10.17487/RFC8084"/>
</reference>
<reference anchor="RFC8087" target="https://www.rfc-editor.org/info/rfc8
087" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml">
<front>
<title>The Benefits of Using Explicit Congestion Notification (ECN)<
/title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<date month="March" year="2017"/>
<abstract>
<t>The goal of this document is to describe the potential benefits
of applications using a transport that enables Explicit Congestion Notification
(ECN). The document outlines the principal gains in terms of increased throughp
ut, reduced delay, and other benefits when ECN is used over a network path that
includes equipment that supports Congestion Experienced (CE) marking. It also di
scusses challenges for successful deployment of ECN. It does not propose new alg
orithms to use ECN nor does it describe the details of implementation of ECN in
endpoint devices (Internet hosts), routers, or other network devices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8087"/>
<seriesInfo name="DOI" value="10.17487/RFC8087"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8257" target="https://www.rfc-editor.org/info/rfc8
257" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8257.xml">
<front>
<title>Data Center TCP (DCTCP): TCP Congestion Control for Data Cent
ers</title>
<author fullname="S. Bensley" initials="S." surname="Bensley"/>
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
<author fullname="P. Balasubramanian" initials="P." surname="Balasub
ramanian"/>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Judd" initials="G." surname="Judd"/>
<date month="October" year="2017"/>
<abstract>
<t>This Informational RFC describes Data Center TCP (DCTCP): a TCP
congestion control scheme for data-center traffic. DCTCP extends the Explicit C
ongestion Notification (ECN) processing to estimate the fraction of bytes that e
ncounter congestion rather than simply detecting that some congestion has occurr
ed. DCTCP then scales the TCP congestion window based on this estimate. This met
hod achieves high-burst tolerance, low latency, and high throughput with shallow
- buffered switches. This memo also discusses deployment issues related to the c
oexistence of DCTCP and conventional TCP, discusses the lack of a negotiating me
chanism between sender and receiver, and presents some possible mitigations. Thi
s memo documents DCTCP as currently implemented by several major operating syste
ms. DCTCP, as described in this specification, is applicable to deployments in c
ontrolled environments like data centers, but it must not be deployed over the p
ublic Internet without additional measures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8257"/>
<seriesInfo name="DOI" value="10.17487/RFC8257"/>
</reference>
<reference anchor="RFC8300" target="https://www.rfc-editor.org/info/rfc8
300" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml">
<front>
<title>Network Service Header (NSH)</title>
<author fullname="P. Quinn" initials="P." role="editor" surname="Qui
nn"/>
<author fullname="U. Elzur" initials="U." role="editor" surname="Elz
ur"/>
<author fullname="C. Pignataro" initials="C." role="editor" surname=
"Pignataro"/>
<date month="January" year="2018"/>
<abstract>
<t>This document describes a Network Service Header (NSH) imposed
on packets or frames to realize Service Function Paths (SFPs). The NSH also prov
ides a mechanism for metadata exchange along the instantiated service paths. The
NSH is the Service Function Chaining (SFC) encapsulation required to support th
e SFC architecture (defined in RFC 7665).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8300"/>
<seriesInfo name="DOI" value="10.17487/RFC8300"/>
</reference>
<reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8
311" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml">
<front>
<title>Relaxing Restrictions on Explicit Congestion Notification (EC
N) Experimentation</title>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="January" year="2018"/>
<abstract>
<t>This memo updates RFC 3168, which specifies Explicit Congestion
Notification (ECN) as an alternative to packet drops for indicating network con
gestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experiment
ation towards benefits beyond just removal of loss. This memo summarizes the ant
icipated areas of experimentation and updates RFC 3168 to enable experimentation
in these areas. An Experimental RFC in the IETF document stream is required to
take advantage of any of these enabling updates. In addition, this memo makes re
lated updates to the ECN specifications for RTP in RFC 6679 and for the Datagram
Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also
records the conclusion of the ECN nonce experiment in RFC 3540 and provides the
rationale for reclassification of RFC 3540 from Experimental to Historic; this
reclassification enables new experimental use of the ECT(1) codepoint.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8311"/>
<seriesInfo name="DOI" value="10.17487/RFC8311"/>
</reference>
<reference anchor="RFC8926" target="https://www.rfc-editor.org/info/rfc8
926" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml">
<front>
<title>Geneve: Generic Network Virtualization Encapsulation</title>
<author fullname="J. Gross" initials="J." role="editor" surname="Gro
ss"/>
<author fullname="I. Ganga" initials="I." role="editor" surname="Gan
ga"/>
<author fullname="T. Sridhar" initials="T." role="editor" surname="S
ridhar"/>
<date month="November" year="2020"/>
<abstract>
<t>Network virtualization involves the cooperation of devices with
a wide variety of capabilities such as software and hardware tunnel endpoints,
transit fabrics, and centralized control clusters. As a result of their role in
tying together different elements of the system, the requirements on tunnels are
influenced by all of these components. Therefore, flexibility is the most impor
tant aspect of a tunneling protocol if it is to keep pace with the evolution of
technology. This document describes Geneve, an encapsulation protocol designed t
o recognize and accommodate these changing capabilities and needs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8926"/>
<seriesInfo name="DOI" value="10.17487/RFC8926"/>
</reference>
<reference anchor="RFC9300" target="https://www.rfc-editor.org/info/rfc9
300" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="D. Lewis" initials="D." surname="Lewis"/>
<author fullname="A. Cabellos" initials="A." role="editor" surname="
Cabellos"/>
<date month="October" year="2022"/>
<abstract>
<t>This document describes the data plane protocol for the Locator
/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifier
s (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify
network attachment points. With this, LISP effectively separates control from d
ata and allows routers to create overlay networks. LISP-capable routers exchange
encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Ca
che.</t>
<t>LISP requires no change to either host protocol stacks or under
lay routers and offers Traffic Engineering (TE), multihoming, and mobility, amon
g other features.</t>
<t>This document obsoletes RFC 6830.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9300"/>
<seriesInfo name="DOI" value="10.17487/RFC9300"/>
</reference>
<reference anchor="RFC9331" target="https://www.rfc-editor.org/info/rfc9
331" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml">
<front>
<title>The Explicit Congestion Notification (ECN) Protocol for Low L
atency, Low Loss, and Scalable Throughput (L4S)</title>
<author fullname="K. De Schepper" initials="K." surname="De Schepper
"/>
<author fullname="B. Briscoe" initials="B." role="editor" surname="B
riscoe"/>
<date month="January" year="2023"/>
<abstract>
<t>This specification defines the protocol to be used for a new ne
twork service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S u
ses an Explicit Congestion Notification (ECN) scheme at the IP layer that is sim
ilar to the original (or 'Classic') ECN approach, except as specified within. L4
S uses 'Scalable' congestion control, which induces much more frequent control s
ignals from the network, and it responds to them with much more fine-grained adj
ustments so that very low (typically sub-millisecond on average) and consistentl
y low queuing delay becomes possible for L4S traffic without compromising link u
tilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwid
th and very low delay at the same time, even during periods of high traffic load
.</t>
<t>The L4S identifier defined in this document distinguishes L4S f
rom 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can b
e incrementally modified to distinguish and isolate existing traffic that still
follows the Classic behaviour, to prevent it from degrading the low queuing dela
y and low loss of L4S traffic. This Experimental specification defines the rules
that L4S transports and network elements need to follow, with the intention tha
t L4S flows neither harm each other's performance nor that of Classic traffic. I
t also suggests open questions to be investigated during experimentation. Exampl
es of new Active Queue Management (AQM) marking algorithms and new transports (w
hether TCP-like or real time) are specified separately.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9331"/>
<seriesInfo name="DOI" value="10.17487/RFC9331"/>
</reference>
<reference anchor="I-D.ietf-intarea-gue" target="https://datatracker.iet
f.org/doc/html/draft-ietf-intarea-gue-09" xml:base="https://bib.ietf.org/public/
rfc/bibxml-ids/reference.I-D.ietf-intarea-gue.xml">
<front>
<title>Generic UDP Encapsulation</title>
<author fullname="Tom Herbert" initials="T." surname="Herbert">
<organization>Quantonium</organization>
</author>
<author fullname="Lucy Yong" initials="L." surname="Yong">
<organization>Independent</organization>
</author>
<author fullname="Osama Zia" initials="O." surname="Zia">
<organization>Microsoft</organization>
</author>
<date day="26" month="October" year="2019"/>
<abstract>
<t>This specification describes Generic UDP Encapsulation (GUE), w
hich is a scheme for using UDP to encapsulate packets of different IP protocols
for transport across layer 3 networks. By encapsulating packets in UDP, speciali
zed capabilities in networking hardware for efficient handling of UDP packets ca
n be leveraged. GUE specifies basic encapsulation methods upon which higher leve
l constructs, such as tunnels and overlay networks for network virtualization, c
an be constructed. GUE is extensible by allowing optional data fields as part of
the encapsulation, and is generic in that it can encapsulate packets of various
IP protocols.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-intarea-gue-09"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-rfc6040update-shim" target="https://da
tatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-22" xml:base="ht
tps://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-rfc6040update-
shim.xml">
<front>
<title>Propagating Explicit Congestion Notification Across IP Tunnel
Headers Separated by a Shim</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization>
</author>
<date day="29" month="October" year="2023"/>
<abstract>
<t>RFC 6040 on "Tunnelling of Explicit Congestion Notification" ma
de the rules for propagation of ECN consistent for all forms of IP in IP tunnel.
This specification updates RFC 6040 to clarify that its scope includes tunnels
where two IP headers are separated by at least one shim header that is not suffi
cient on its own for wide area packet forwarding. It surveys widely deployed IP
tunnelling protocols that use such shim header(s) and updates the specifications
of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2
784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Tere
do and AMT). This specification also updates RFC 6040 with configuration require
ments needed to make any legacy tunnel ingress safe.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-rfc6040updat
e-shim-22"/>
</reference>
<reference anchor="IEEE802.1Q" target="https://ieeexplore.ieee.org/docum
ent/8403927">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area <title>IEEE Standard for Local and Metropolitan Area Network--Bridge
Networks&mdash;Virtual Bridged Local Area Networks&mdash;Amendment s and Bridged Networks</title>
6: Provider Backbone Bridges</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date month="July" year="2018"/> <date month="July" year="2018"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1Q-2018"/> <seriesInfo name="IEEE Std" value="802.1Q-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
</reference> </reference>
<!-- <reference anchor="IEEE802.1ah" <!-- <reference anchor="IEEE802.1ah"
target="https://www.ieee802.org/1/pages/802.1ah.html"> target="https://www.ieee802.org/1/pages/802.1ah.html">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area <title>IEEE Standard for Local and Metropolitan Area
Networks&mdash;Virtual Bridged Local Area Networks &mdash; Amendment Networks&mdash;Virtual Bridged Local Area Networks &mdash; Amendment
6: Provider Backbone Bridges</title> 6: Provider Backbone Bridges</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
skipping to change at line 1898 skipping to change at line 1790
</front> </front>
<seriesInfo name="IEEE Std" value="802.1Qau-2010"/> <seriesInfo name="IEEE Std" value="802.1Qau-2010"/>
<format target="https://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punu mber=5454061" <format target="https://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punu mber=5454061"
type="PDF"/> type="PDF"/>
<annotation>(Access Controlled link within page)</annotation> <annotation>(Access Controlled link within page)</annotation>
</reference> --> </reference> -->
<reference anchor="ITU-T.I.371" target="https://www.itu.int/rec/T-REC-I.37 1"> <reference anchor="ITU-T.I.371" target="https://www.itu.int/rec/T-REC-I.37 1-200403-I/en">
<front> <front>
<title>Traffic Control and Congestion Control in B-ISDN</title> <title>Traffic control and congestion control in B-ISDN</title>
<author fullname="" initials="" surname=""> <author fullname="" initials="" surname="">
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date month="March" year="2004"/> <date month="March" year="2004"/>
</front> </front>
<seriesInfo name="ITU-T Rec." value="I.371 (03/04)"/> <seriesInfo name="ITU-T Recommendation" value="I.371"/>
<format target="https://www.itu.int/rec/T-REC-I.371" type="PDF"/>
</reference> </reference>
<reference anchor="Buck00"> <reference anchor="Buck00">
<front> <front>
<title>Frame Relay: Technology and Practice</title> <title>Frame Relay: Technology and Practice</title>
<author fullname="Jeff T. Buckwalter" initials="J.T." surname="Buckw alter"> <author fullname="Jeff T. Buckwalter" initials="J.T." surname="Buckw alter">
<organization/> <organization/>
</author> </author>
<date day="" month="" year="2000"/> <date year="2000"/>
</front> </front>
<seriesInfo name="Pub. Addison Wesley" value="ISBN-13: 978-0201485240" <seriesInfo name="ISBN-13" value="978-0201485240"/>
/> <refcontent>Addison-Wesley Professional</refcontent>
</reference> </reference>
<reference anchor="GTPv1"> <reference anchor="GTPv1">
<front> <front>
<title>GPRS Tunnelling Protocol (GTP) across the Gn and Gp <title>General Packet Radio Service (GPRS); GPRS Tunnelling
interface</title> Protocol (GTP) across the Gn and Gp interface</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date/> <date/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 29.060"/> <seriesInfo name="Technical Specification" value="29.060"/>
</reference> </reference>
<reference anchor="GTPv1-U"> <reference anchor="GTPv1-U">
<front> <front>
<title>General Packet Radio System (GPRS) Tunnelling Protocol User <title>General Packet Radio System (GPRS) Tunnelling Protocol User
Plane (GTPv1-U)</title> Plane (GTPv1-U)</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 29.281"/> <seriesInfo name="Technical Specification" value="29.281"/>
</reference> </reference>
<reference anchor="LTE-RA"> <reference anchor="LTE-RA">
<front> <front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA) and <title>Evolved Universal Terrestrial Radio Access (E-UTRA) and
Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Overall description; Stage 2</title> Overall description; Stage 2</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date/> <date/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 36.300"/> <seriesInfo name="Technical Specification" value="36.300"/>
</reference> </reference>
<reference anchor="UTRAN"> <reference anchor="UTRAN">
<front> <front>
<title>UTRAN Overall Description</title> <title>UTRAN overall description</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 25.401"/> <seriesInfo name="Technical Specification" value="25.401"/>
</reference> </reference>
<reference anchor="GTPv2-C"> <reference anchor="GTPv2-C">
<front> <front>
<title>Evolved General Packet Radio Service (GPRS) Tunnelling <title>3GPP Evolved Packet System (EPS); Evolved General Packet
Protocol for Control plane (GTPv2-C)</title> Radio Service (GPRS) Tunnelling Protocol for Control plane
(GTPv2-C); Stage 3</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date year=""/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 29.274"/> <seriesInfo name="Technical Specification" value="29.274"/>
</reference> </reference>
<reference anchor="ATM-TM-ABR" target="https://www.cisco.com/c/en/us/sup port/docs/asynchronous-transfer-mode-atm/atm-traffic-management/10415-atmabr.htm l"> <reference anchor="ATM-TM-ABR" target="https://www.cisco.com/c/en/us/sup port/docs/asynchronous-transfer-mode-atm/atm-traffic-management/10415-atmabr.htm l">
<front> <front>
<title>Understanding the Available Bit Rate (ABR) Service Category <title>Understanding the Available Bit Rate (ABR) Service Category
for ATM VCs</title> for ATM VCs</title>
<author> <author>
<organization>Cisco</organization> <organization>Cisco</organization>
</author> </author>
<date day="5" month="June" year="2005"/> <date month="June" year="2005"/>
</front> </front>
<seriesInfo name="Design Technote" value="10415"/> <seriesInfo name="Design Technote" value="10415"/>
</reference> </reference>
<reference anchor="Leiserson85"> <reference anchor="Leiserson85">
<front> <front>
<title>Fat-trees: universal networks for hardware-efficient <title>Fat-trees: Universal networks for hardware-efficient
supercomputing</title> supercomputing</title>
<author fullname="Charles E. Leiserson" initials="C.E." surname="Lei serson"> <author fullname="Charles E. Leiserson" initials="C.E." surname="Lei serson">
<organization/> <organization/>
</author> </author>
<date day="" month="October" year="1985"/> <date month="October" year="1985"/>
</front> </front>
<seriesInfo name="IEEE Transactions on Computers" value="34(10):892&nd <seriesInfo name="DOI" value="10.1109/TC.1985.6312192"/>
ash;901"/> <refcontent>IEEE Transactions on Computers, Vol. C-34, Issue 10</refcon
tent>
</reference> </reference>
<reference anchor="Clos53"> <reference anchor="Clos53">
<front> <front>
<title>A Study of Non-Blocking Switching Networks</title> <title>A Study of Non-Blocking Switching Networks</title>
<author fullname="Charles Clos" initials="C." surname="Clos"> <author fullname="Charles Clos" initials="C." surname="Clos">
<organization/>
</author> </author>
<date day="" month="March" year="1953"/> <date month="March" year="1953"/>
</front> </front>
<seriesInfo name="Bell Systems Technical Journal" value="32(2):406&nda <seriesInfo name="DOI" value="10.1002/j.1538-7305.1953.tb01433.x"/>
sh;424"/> <refcontent>The Bell System Technical Journal, Vol. 32, Issue 2</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<!-- ================================================================ -->
<section anchor="ecnencap_Comments_Solicited" numbered="false" removeInRFC="
true" toc="default">
<name>Comments Solicited</name>
<t>Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list
&lt;tsvwg@ietf.org&gt;, and/or to the authors.</t>
</section>
<section anchor="ecnencap_Acknowledgements" numbered="false" toc="default"> <section anchor="ecnencap_Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Thanks to Gorry Fairhurst and David Black for extensive reviews. <t>Thanks to <contact fullname="Gorry Fairhurst"/> and <contact
Thanks also to the following reviewers: Joe Touch, Andrew McGregor, fullname="David Black"/> for extensive reviews. Thanks also to the
Richard Scheffenegger, Ingemar Johansson, Piers O'Hanlon, Donald following reviewers: <contact fullname="Joe Touch"/>, <contact
Eastlake, Jonathan Morton, Markku Kojo, Sebastian M&ouml;ller, Martin Duke fullname="Andrew McGregor"/>, <contact fullname="Richard
and Scheffenegger"/>, <contact fullname="Ingemar Johansson"/>, <contact
Michael Welzl, who pointed out that lower layer congestion notification fullname="Piers O'Hanlon"/>, <contact fullname="Donald Eastlake 3rd"/>,
signals may have different semantics to those in IP. Thanks are also due <contact fullname="Jonathan Morton"/>, <contact fullname="Markku
to the tsvwg chairs, TSV ADs and IETF liaison people such as Eric Gray, Kojo"/>, <contact fullname="Sebastian Möller"/>, <contact
Dan Romascanu and Gonzalo Camarillo for helping with the liaisons with fullname="Martin Duke"/>, and <contact fullname="Michael Welzl"/>, who
the IEEE and 3GPP. And thanks to Georg Mayer and particularly to Erik pointed out that lower-layer congestion notification signals may have
Guttman for the extensive search and categorisation of any 3GPP different semantics to those in IP. Thanks are also due to the Transport a
specifications that cite ECN specifications. Thanks also to the Area nd Services Working Group (tsvwg)
Reviewers Dan Harkins, Paul Kyzivat, Sue Hares and Dale Worley.</t> chairs, TSV ADs and IETF liaison people such as <contact fullname="Eric
<t>Bob Briscoe was part-funded by the European Community under its Gray"/>, <contact fullname="Dan Romascanu"/> and <contact
Seventh Framework Programme through the Trilogy project (ICT-216372) for fullname="Gonzalo Camarillo"/> for helping with the liaisons with the
initial drafts then through the Reducing Internet Transport Latency IEEE and 3GPP. And thanks to <contact fullname="Georg Mayer"/> and
(RITE) project (ICT-317700), and for final drafts (from -18) he was funded particularly to <contact fullname="Erik Guttman"/> for the extensive
by Apple Inc. The views expressed here are search and categorisation of any 3GPP specifications that cite ECN
solely those of the authors.</t> specifications. Thanks also to the Area Reviewers <contact fullname="Dan
Harkins"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Sue
Hares"/>, and <contact fullname="Dale Worley"/>.</t>
<t><contact fullname="Bob Briscoe"/> was part-funded by the European
Community under its Seventh Framework Programme through the Trilogy
project (ICT-216372) and the Reducing Internet Transport Latency (RITE)
project (ICT-317700) for earlier draft versions of this document. For
later draft versions of this document, he was funded by Apple Inc. The
views expressed here are solely those of the authors.</t>
</section> </section>
<section numbered="false" toc="default"> <section numbered="false" toc="default">
<name>Contributors</name> <name>Contributors</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ Pat Thaler <contact fullname="Pat Thaler">
Broadcom Corporation (retired) <organization>Broadcom Corporation (retired)</organization>
CA <address>
USA]]></artwork> <postal>
<t>Pat was a co-author of this draft, but retired before its <region>CA</region>
<country>United States of America</country></postal>
</address>
</contact>
<t>Pat was a coauthor of this draft, but retired before its
publication.</t> publication.</t>
</section> </section>
</back> </back>
<!-- [rfced] FYI, we have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. For example, please consider
whether the term "native" should be updated.
-->
</rfc> </rfc>
 End of changes. 267 change blocks. 
1574 lines changed or deleted 1207 lines changed or added

This html diff was produced by rfcdiff 1.48.