<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITYouml "ö"> <!ENTITYzwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"><!ENTITY ndash "–"> <!ENTITY mdash "—">]><?xml-stylesheet type='text/xsl' href='https://xml.resource.org/authoring/rfc2629.xslt' ?> <!-- Alterations to I-D/RFC boilerplate --> <?rfc private="" ?> <!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RFC --> <?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 latest 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; otherwise 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 --><rfcxmlns:xi="https://www.w3.org/2001/XInclude"xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" consensus="true" docName="draft-ietf-tsvwg-ecn-encap-guidelines-22"ipr="pre5378Trust200902"number="9599" ipr="trust200902" updates="3819" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <front> <!--xml2rfc v2v3 conversion 3.18.0[rfced] We note that the short title of this document is "ECN Encapsulation Guidelines". To match the short title, should we update the title of the document as follows to include "ECN"? Original: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP Perhaps: Guidelines for Adding Explicit Congestion Notification (ECN) to Protocols That Encapsulate IP --><front><title abbrev="ECN Encapsulation Guidelines">Guidelines for Adding Congestion Notification to ProtocolsthatThat Encapsulate IP</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-guidelines-22"/>name="RFC" value="9599"/> <seriesInfo name="BCP" value="89"/> <author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <organization>Independent</organization> <address> <postal><street/> <country>UK</country><country>United Kingdom</country> </postal> <email>ietf@bobbriscoe.net</email> <uri>https://bobbriscoe.net/</uri> </address> </author> <author fullname="John Kaippallimalil" initials="J." surname="Kaippallimalil"> <organization>Futurewei</organization> <address> <postal> <street>5700 Tennyson Parkway, Suite 600</street> <city>Plano</city> <region>Texas</region> <code>75024</code><country>USA</country><country>United States of America</country> </postal> <email>kjohn@futurewei.com</email> </address> </author> <dateyear=""/> <area>Transport</area> <workgroup>Transport Area Working Group</workgroup>month="June" year="2024"/> <area>WIT</area> <workgroup>tsvwg</workgroup> <keyword>Congestion Control and Management</keyword> <keyword>Congestion Notification</keyword> <keyword>Information Security</keyword> <keyword>Tunnelling</keyword><keyword>Encapsulation & Decapsulation</keyword><keyword>Encapsulation</keyword> <keyword>ECNDecapsulation</keyword> <keyword>Protocol</keyword> <keyword>ECN</keyword> <keyword>Layering</keyword> <abstract><t>The<!-- [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 notification in any lower-layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently fromlower layerlower-layer protocols into IP. <!-- [rfced] FYI, "congestion notification" has been made plural in instances where it seems to refer to notifications rather than the mechanism; here is an example. Please review. (We note there were 4 instances of plural in the original.) Original: 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 andlower layerlower-layer congestion notificationmechanisms, whethermechanisms 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 aboutECNExplicit Congestion Notification (ECN) in Section 13 of RFC3819,3819 by replacing it with a reference tothe whole ofthis document.</t> </abstract> </front><!-- ================================================================ --><middle><!-- ================================================================ --><section anchor="ecnencap_Introduction" numbered="true" toc="default"> <name>Introduction</name> <t>The benefits of Explicit Congestion Notification (ECN) described in <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 well as to IP. When alower layerlower-layer buffer drops apacket obviouslypacket, it obviously 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 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 encapsulates inner tunnelled headers. Forwarding ECN is not as straightforward as other headers because it has to be assumed ECN may be only partially deployed. If alower layerlower-layer header that contains ECN 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, congestion needs to be indicated by dropping the packet, not marking it.</t><t>The<!-- [rfced] How may this sentence be rephrased for clarity? Specifically, what does "it" refer to in "it will propagate"? Original: 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"/> to allow a resource to notify the onset of queuebuild-upbuildup without having to droppackets,packets by explicitly marking a proportion of packets with the congestion experienced (CE)codepoint.<!--Incodepoint. <!-- [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 forward PDUs and eventually returns a status code to the higher layer. Without ECN, each layer returns either a 'delivered' status code or an implicit 'not delivered'. Explicit notification of congestion adds a useful 'delivered but congestion experienced' status code to each layer interface.--> </t> <t>Given a suitable marking scheme, ECN removes nearly all congestion loss and it cuts delays for two main reasons: </t> <ul spacing="normal"> <li>It avoids the delay when recovering from congestion losses, which particularly benefits small flows or real-time flows, making their delivery time predictably short <xref target="RFC2884"format="default"/>;</li>format="default"/>.</li> <li>As ECN is used more widely byend-systems,end systems, it will gradually remove the need to configure a degree of delay into buffers before they start to notify congestion (the cause of bufferbloat). This is because drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal and not an impairment, so there is no harm triggering it earlier.</li> </ul> <t>Somelower layerlower-layer technologies(e.g.(e.g., MPLS, Ethernet) are used to form 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, untilrecentlyrecently, this was more due to the inability of TCP to saturate the links. For many years, fixes such as window scaling <xref target="RFC7323" format="default"/> proved hard to deploy.And theThe Reno variant of TCP has remained in widespread use despite its inability to scale to high flow rates. However, now that modern operating systems are finally capable of saturating interior links, even the buffers of well-provisioned interior switches will need to signal episodes of queuing.</t> <t>Propagation of ECN is defined for MPLS <xref target="RFC5129"format="default"/>,format="default"/> andhas been defined forTRILL <xref target="RFC7780"format="default"/>,format="default"/> <xreftarget="I-D.ietf-trill-ecn-support"target="RFC9600" format="default"/>, but itremainshas yet to be defined for a number of other subnetwork technologies.</t> <t>Similarly, ECN propagation is yet to be defined for many tunnelling protocols. <xref target="RFC6040" format="default"/> defines how ECN should be propagated for IP-in-IPv4 <xref target="RFC2003" format="default"/>, IP-in-IPv6 <xref target="RFC2473"format="default"/>format="default"/>, and IPsec <xref target="RFC4301" format="default"/> tunnels, but there are numerous other tunnelling protocols with a shim and/or alayerLayer 2 (L2) header between two IP headers (IPv4 or IPv6). Some address ECN propagation 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 companionstandards trackStandards 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 companion Standards Track specification <xreftarget="I-D.ietf-tsvwg-rfc6040update-shim"target="RFC9601" format="default"/> updatesthoseexisting IP-shim-(L2)-IP protocols that are under IETF change control and still widely used.</t> <t>Incremental deployment is the most delicate aspect when adding support for ECN. The original ECN protocol in IP <xref target="RFC3168" format="default"/> was carefully designed so that a congested buffer would not mark a packet (rather than drop it) unless both source and destination hosts were ECN-capable. Otherwise, its congestion markings would never be detected and congestion would just build up further. However, to support congestion marking below the IP layer or within tunnels, it is not sufficient to only check that the two layer 4 transportend-pointsendpoints support ECN; correct operation also depends on the decapsulator at each subnet or tunnel egress faithfully propagating congestion notifications to the higher layer. <!-- [rfced] Should "outer" read as "outer header" here for clarity? Original: Otherwise, a legacy decapsulator might silently fail to propagate any ECN signals from the outer to the forwarded header.ThenPerhaps: Otherwise, a legacy decapsulator might silently fail to propagate any ECN signals from the outer header to the forwarded header. --> Otherwise, a legacy decapsulator might silently fail to propagate any ECN signals from the outer to the forwarded header. Then, the lost signals would never be detected andagaincongestion would build up further. The guidelines given later require protocol designers to carefully consider incrementaldeployment,deployment and suggest various safe approaches for different circumstances.</t> <t>Of course, the IETF does not have standards authority over everylink layer protocol. Solink-layer protocol; thus, this document gives guidelines for designing propagation of congestionnotificationnotifications across the interface between IP and protocols that may encapsulate IP(i.e.(i.e., that can be layered beneath IP). Eachlower layerlower-layer technology will exhibit different issues and compromises, so the IETF or the relevant standards body must be free to define the specifics of eachlower layerlower-layer congestion notification scheme. Nonetheless, if the guidelines are followed, congestionnotificationnotifications should interwork between differenttechnologies,technologies using IP in its role as a 'portability layer'.</t> <t>Therefore, the capitalized terms'SHOULD''<bcp14>SHOULD</bcp14>' or'SHOULD NOT''<bcp14>SHOULD NOT</bcp14>' are often used in preference to'MUST''<bcp14>MUST</bcp14>' or'MUST NOT','<bcp14>MUST NOT</bcp14>' because it is difficult to know the compromises that will be necessary in each protocol design. If a particular protocol design chooses not to follow a'SHOULD (NOT)''<bcp14>SHOULD</bcp14>' or '<bcp14>SHOULD NOT</bcp14>' given in the advice below, itMUST<bcp14>MUST</bcp14> include a sound justification.</t> <t>It has not been possible to give common guidelines for alllower layer technologies,lower-layer technologies because they do not all fit a common pattern. <!-- [rfced] We note that the "feed-forward-and-upward" and "feed-upward-and-forward" modes of operation in this sentence are 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"/>,then in the subsequent sectionsand separate guidelines are given for eachmode.</t>mode in subsequent sections.</t> <section numbered="true" toc="default"> <name>Update to RFC 3819</name> <t>This document updates the brief advice to subnetwork designers about ECN in <xref section="13" target="RFC3819"format="default"/>,format="default"/> by adding this document (RFC 9599) as an informative reference and replacing the last two paragraphs with the following sentence:</t><ul empty="true" spacing="normal"> <li>By<blockquote> By following the guidelines in[this document],[RFC9599], subnetwork designers can enable a layer-2 protocol to participate in congestion control without dropping packets via propagation ofexplicit congestion notification (ECNExplicit Congestion Notification (ECN) <xref target="RFC3168"format="default"/>)format="default"/> toreceivers.</li> </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>receivers.</blockquote> </section> <section anchor="ecnencap_Scope" numbered="true" toc="default"> <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 notification of congestion. It makes no changes or recommendations concerning algorithms for congestion marking orforcongestionresponse,response because algorithm issues should be independent of the layer that the algorithm operates in.</t> <t>The default ECN semantics are described in <xref target="RFC3168" format="default"/> and updated by <xref target="RFC8311" format="default"/>. Also, the guidelines forAQMActive Queue Management (AQM) designers <xref target="RFC7567" format="default"/> clarify the semantics of both drop and ECN signals from AQM algorithms. <xref target="RFC4774" format="default"/> is the appropriate best current practice specification of how algorithms with alternative semantics for the ECN field can be partitioned from Internet traffic that uses the default ECN semantics. There are two main examples for how alternative ECN semantics have been defined in practice:</t> <ul spacing="normal"><li>RFC 4774<li><xref target="RFC4774"/> suggests using the ECN field in combination with a Diffservcodepointcodepoint, such as inPCNPre-Congestion Notification (PCN) <xref target="RFC6660" format="default"/>, Voice over 3G <xref target="UTRAN"format="default"/>format="default"/>, or Voice over LTE (VoLTE) <xref target="LTE-RA"format="default"/>;</li> <li>RFC 8311format="default"/>.</li> <li><xref target="RFC8311"/> suggests using the ECT(1) codepoint of the ECN field to indicate alternativesemanticssemantics, such as for the experimental LowLatencyLatency, LowLossLoss, and Scalable throughput (L4S) service <xref target="RFC9331" format="default"/>).</li> </ul> <t>The aim is that the default rules for encapsulating and decapsulating the ECN field are sufficiently generic that tunnels and subnets will encapsulate and decapsulate packets without regard to how algorithms elsewhere are setting or interpreting the semantics of the ECN field. <xref target="RFC6040" format="default"/> updatesRFC 4774<xref target="RFC4774"/> to allow alternative encapsulation and decapsulationbehavioursbehaviors to be defined for alternative ECN semantics. However, it reinforces the same point- that-- it is far preferable to try to fit within the common ECN encapsulation and decapsulationbehaviours,behaviors because expecting alllower layerlower-layer technologies and tunnels to be updated is likely to be completely impractical.</t> <t>Alternative semantics for the ECN field can be defined to depend on the traffic class indicated by theDSCP.Differentiated Services Code Point (DSCP). Therefore, correct propagation of congestion signals could depend on correct propagation of the DSCP 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) andifthe 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 be lost. Similarly, if the DSCP is changed at the boundary between Diffserv domains, the special ECN semantics would also be lost. This is an important implication of the localized scope of most Diffserv arrangements. In this document, correct propagation of traffic class information isassumed,assumed whilewhatthe meaning of 'correct'meansand how it is achieved is covered elsewhere(e.g. RFC 2983)(e.g., <xref target="RFC2983"/>) and is outside the scope ofthe presentthis document.</t> <t>The guidelines in this document do ensure that common encapsulation and decapsulation rules are sufficiently generic to cover cases where ECT(1) is used instead of ECT(0) to identify alternative ECN semantics (as in L4S <xref target="RFC9331" format="default"/>) and whereECN markingECN-marking algorithms use ECT(1) to encode3three severity levels into the ECN field(e.g.(e.g., PCN <xref target="RFC6660" format="default"/>) rather than the default of2.two. All these different semantics for the ECN field work because it has been possible to define common default decapsulation rules that allow for all cases.</t> <t>Note that the guidelines in this document do not necessarily require the subnet wire protocol to be changed to add support for congestionnotification.notifications. For instance, theFeed-Up-and-Forward Modefeed-up-and-forward mode (<xref target="ecnencap_Up" format="default"/>) and theNull Modenull mode (<xref target="ecnencap_Null" format="default"/>) do not. Another way to add congestionnotificationnotifications without consuming header space in the subnet protocol might be to use a parallel control plane protocol.</t> <t>This document focuses on the congestion notification interface between IP andlower layerlower-layer or tunnel protocols that can encapsulate IP, where the term 'IP' includes IPv4 or IPv6, unicast,multicastmulticast, or anycast. <!-- [rfced] We note that "previously 802.1ah", "previously 802.1p", and "previously known as 802.1Qau" is written in instances where [IEEE802.1Q] 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" format="default"/>; previously802.1ah)802.1ah), or when it encapsulates other protocols. In the feed-backward mode, propagation of congestion signals for multicast and anycast packets isout-of-scopeout of scope (because the complexity would make it unlikely to be attempted).</t> </section> </section><!-- ================================================================ --><section anchor="ecnencap_Reqs_Language" numbered="true" toc="default"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t> <t>Further terminology used within this document:</t> <dl newline="false" spacing="normal"> <dt>Protocol data unit (PDU):</dt> <dd>Information that is delivered as a unit among peer entities of a layered network consisting of protocol control information (typically a header) and possibly user data (payload) of that layer. The scope of this document includeslayerLayer 2 andlayerLayer 3 networks, where the PDU is 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 payload with a shim header lying somewhere between layer 2 and 3.</dd> <dt>Transport:</dt> <dd>The end-to-end transmission control function, conventionally considered atlayer-4layer 4 in the OSI reference model. Given the audience for this document will often use the word transport to meanlow levellow-level bit carriage,wheneverthe termis used itwill bequalified, e.g.qualified whenever it is used, e.g., 'L4 transport'.</dd> <dt>Encapsulator:</dt> <dd>The link or tunnel endpoint function that adds an outer header to a PDU (also termed the 'link ingress', the 'subnet ingress', the 'ingress tunnelendpoint'endpoint', or just the 'ingress' where the context is clear).</dd> <dt>Decapsulator:</dt> <dd>The link or tunnel endpoint function that removes an outer header from a PDU (also termed the 'link egress', the 'subnet egress', the 'egress tunnelendpoint'endpoint', or just the 'egress' where the context is clear).</dd> <dt>Incoming header:</dt> <dd>The header of an arriving PDU before encapsulation.</dd> <dt>Outer header:</dt> <dd>The header added to encapsulate a PDU.</dd> <dt>Inner header:</dt> <dd>The header encapsulated by the outer header.</dd> <dt>Outgoing header:</dt> <dd>The header forwarded by the decapsulator.</dd> <dt>CE:</dt> <dd>Congestion Experienced <xref target="RFC3168" format="default"/></dd> <dt>ECT:</dt> <dd>ECN-Capable (L4) Transport <xref target="RFC3168" format="default"/></dd> <dt>Not-ECT:</dt> <dd>Not ECN-Capable (L4) Transport <xref target="RFC3168" format="default"/></dd> <dt>Load Regulator:</dt> <!-- [rfced] Does the proposed text improve readability of the definition for "Load Regulator" without changing the intended meaning? Original: Load Regulator: For each flow of PDUs, the transport function that is capable of controlling the data rate. Perhaps: Load Regulator: The transport function that is capable of controlling 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.(e.g., admission control, policingnodesnodes, or transport circuit-breakers <xref target="RFC8084" format="default"/>). Notethe termthat "a function capable of controlling the load" deliberately includes a transport that does not actually control the loadresponsivelyresponsively, but ideally it ought to(e.g.(e.g., a sending application without congestion control that uses UDP).</dd> <dt>ECN-PDU:</dt> <dd>A PDU at the IP layer or below with a capacity to signal congestion that is part of a congestion control feedback loop within which all the nodes necessary to propagate the signal back to the Load Regulator are capable of doing that 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, ECN-PDU is intended to be a general term for a PDU at lower layers, as well as at the IP layer.</dd> <dt>Not-ECN-PDU:</dt> <dd>A PDU at the IP layer or below that is part of a congestion control feedback loop that is not capable of propagatingexplicit congestion notificationECN signals back to the LoadRegulator,Regulator because at least one of the nodes necessary to propagate the signals is incapable of doing that propagation. Note that this definition is a property of thefeedback-loop,feedback loop, not necessarily of the PDUitself, because in some protocolsitself; the PDU will self-describe theproperty,property in some protocols, but inothersothers, the property might be carried in a separatecontrol-planecontrol plane context that is somehow bound to the PDU.</dd> </dl> </section> <section anchor="ecnencap_Modes" numbered="true" toc="default"> <name>Modes of Operation</name> <t>This section sets down the different modes by which congestion information is passed between the lower layer and the higher one. It acts as a reference framework for the followingsections, whichsections that give normative guidelines for designers ofexplicit congestion notificationECN protocols, taking each mode in turn:</t> <dl newline="false" spacing="normal"> <dt>Feed-Forward-and-Up:</dt> <dd> <t>Nodes feed forward congestionnotificationnotifications towards the egress within the lowerlayerlayer, then up and along the layers towards the end-to-end destination at the transport layer. The following localoptimisationoptimization is possible:</t> <!--[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> <dd>Alower layerlower-layer switchfeeds-upfeeds up congestionnotificationnotifications directly into the higher layer(e.g.(e.g., into the ECN field in the IP header), irrespective of whether the node is at the egress of a subnet.</dd> </dl> </dd> <dt>Feed-Backward:</dt> <dd>Nodes feed back congestion signals towards the ingress of the lower layer and (optionally) attempt to control congestion within their own layer.</dd> <dt>Null:</dt> <dd>Nodes cannot experience congestion at the lower layer except at ingress nodes (which are IP-aware or equivalently higher-layer-aware).</dd> </dl> <section anchor="ecnencap_Forward" numbered="true" toc="default"> <name>Feed-Forward-and-Up Mode</name> <t>Like IP and MPLS, many subnet technologies are based on self-containedprotocol data units (PDUs)PDUs or frames sent unreliably. They provide no feedback channel at the subnetwork layer, instead relying on higher layers(e.g.(e.g., TCP) to feed back loss signals.</t> <t>In these cases, ECN may best be supported by standardising explicit notification of congestion into thelower layerlower-layer protocol that carries the data forwards.ThenThen, a specification is needed for how the egress of thelower layerlower-layer subnet propagates this explicit signal into the forwardedupper layerupper-layer (IP) header. This signal continues forwards until it finally reaches the destination transport (at L4).Then typicallyTypically, the destination will feed this congestion notification back to the source transport using an end-to-end protocol(e.g.(e.g., TCP). This is the arrangement that has already been used to add ECN to IP-in-IP tunnels <xref target="RFC6040" format="default"/>,IP-in-MPLSIP-in-MPLS, and MPLS-in-MPLS <xref target="RFC5129" format="default"/>.</t> <t>This mode is illustrated in <xref target="ecnencap_Fig_Feed-Forward-and-Up" format="default"/>. Along the middle of the figure, layers 2,33, and 4 of the protocol stack areshown, and oneshown. One packet is shown along the bottom as it progresses across the network from source to destination, crossing two subnets connected by arouter,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 marking in the L2 header (shown as C in the illustration of the packet). The chevrons show the progress of the resulting congestion indication. It is propagated from link to link across the subnet in the L2header, thenheader. Then, when the router removes the marked L2 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 in subnet B does not support ECN, but the signal proceeds across it in the L3 header.</t> <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 each protocol.</t> <t>Finally, for completeness, we show the L3 marking arriving at the destination, where the host transport protocol(e.g.(e.g., TCP) feeds it back to the source in the L4 acknowledgement (the 'C' at L4 in the packet at the top of the diagram).</t> <figure anchor="ecnencap_Fig_Feed-Forward-and-Up"> <name>Feed-Forward-and-Up Mode</name> <artwork name="" type="" align="left" alt=""><![CDATA[ _ _ _ /_______ | | |C| ACK Packet (V) \ |_|_|_| +---+ layer: 2 3 4 header +---+ | <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4 | | +---+ | ^ | | | . . . . . . Packet U. . | >>|>>> Packet U >>>>>>>>>>>>|>^ |L3 | | +---+ +---+ | ^ | +---+ +---+ | | | | | *|>>>>>|>>>|>>>>>|>^ | | | | | | |L2 |___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___| source subnet A router subnet B dest __ _ _ _| __ _ _ _| __ _ _| __ _ _ _| | | | | | | | | |C| | | |C| | | |C| | Data________\ |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) / layer:4 3 2A 4 3 2A 4 3 4 3 2Bheader]]></artwork>header ]]></artwork> </figure> <t>Of course, modern networks are rarely as simple as thistext-booktextbook example, often involving multiple nested layers. For example, a3GPPThird Generation Partnership Project (3GPP) mobile network may have two IP-in-IP(GTP(GTP) <xref target="GTPv1"format="default"/>)format="default"/> tunnels in series and an MPLS backhaul between the base station and the first router. Nonetheless, the example illustrates the general idea of feeding congestionnotificationnotifications forward then upward whenever a header is removed at the egress of a subnet.</t> <t>Note that theFECN (forward ECN )Forward Explicit Congestion Notification (FECN) bit in Frame Relay <xref target="Buck00" format="default"/> and theexplicit forward congestion indication (EFCIExplicit Forward Congestion Indication (EFCI) <xref target="ITU-T.I.371"format="default"/>)format="default"/> bit in ATM user data cells 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 feed-forward-and-up out of the lower layer -- the intention was 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 be provisioned.</t> </section> <section anchor="ecnencap_Up" numbered="true" toc="default"> <name>Feed-Up-and-Forward Mode</name> <t>Ethernet is particularly difficult to extend incrementally to supportexplicit congestion notification.ECN. One way to support ECN in such caseshas beenis to useso called 'layer-3so-called 'Layer 3 switches'. These are Ethernet switches that dig into the Ethernet payload to find an IP header and manipulate or act on certain IP fields (specifically Diffserv&and ECN). For instance, in Data Center TCP <xref target="RFC8257" format="default"/>,layer-3Layer 3 switches are configured to mark the ECN field of the IP header within the Ethernet payload when their output buffer becomes congested. With respect to switching, alayer-3Layer 3 switch acts solely on the addresses in the Ethernet header; it does not use IPaddresses,addresses and it does not decrement the TTL field in the IP header.</t> <figure anchor="ecnencap_Fig_Feed-Up"> <name>Feed-Up-and-Forward Mode</name> <artwork name="" type="" align="left" alt=""><![CDATA[ _ _ _ /_______ | | |C| ACK packet (V) \ |_|_|_| +---+ layer: 2 3 4 header +---+ | <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4 | | +---+ | ^ | | | . . . >>>> Packet U >>>|>>>|>>> Packet U >>>>>>>>>>>>|>^ |L3 | | +--^+ +---+ | v| +---+ +---+ | ^ | | | | *| | | | >|>>>>>|>>>|>>>>>|>>>|>>>>>|>^ |L2 |___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___| source subnet E router subnet F dest __ _ _ _| __ _ _ _| __ _ _| __ _ _ _| | | | | | | | |C| | | | |C| | | |C|C| Data________\ |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) / layer:4 3 2 4 3 2 4 3 4 3 2header]]></artwork>header ]]></artwork> </figure> <t>By comparing <xref target="ecnencap_Fig_Feed-Up" format="default"/> with <xref target="ecnencap_Fig_Feed-Forward-and-Up" format="default"/>, it can be seen that subnet E (perhaps a subnet oflayer-3Layer 3 Ethernet switches) works in feed-up-and-forward mode by notifying congestion directly into L3 at the point of congestion, even though the congested switch does not otherwise act at L3. <!-- [rfced] For clarity, may we split this sentence into two? Also, perhaps changing from 'natively' to 'innately'; see the final question regarding inclusive language. 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 anchor="ecnencap_Backward" numbered="true" toc="default"> <name>Feed-Backward Mode</name> <t>In somelayerLayer 2 technologies,explicit congestion notificationECN has been defined for use internally within the subnet with its own feedback and loadregulation, but typicallyregulation; typically, the interface with IP for ECN has not been defined.</t><t>For<!-- [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 managing traffic, tending to supersede earlier designs. In thisapproachapproach, ATM switches send special resource management (RM) cells in both the forward and backward directions to control the ingress rate of user data into a virtual circuit. If a switch buffer is approaching congestion or iscongestedcongested, it sends an RM cell back towards the ingress withrespectivelythe No Increase (NI) or Congestion Indication (CI) bit set in its message type field <xref target="ATM-TM-ABR"format="default"/>.format="default"/>, respectively. The ingress then holds or decreases its sending bit-rate accordingly.</t> <figure anchor="ecnencap_Fig_Feed-Backward"> <name>Feed-Backward Mode</name> <artwork name="" type="" align="left" alt=""><![CDATA[ _ _ _ /_______ | | |C| ACK packet (X) \ |_|_|_| +---+ layer: 2 3 4 header +---+ | <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet X <<<<<<<<<<<<<|<< |L4 | | +---+ | ^ | | | | *|>>> Packet W >>>>>>>>>>>>|>^ |L3 | | +---+ +---+ | | +---+ +---+ | | | | | | | | | <|<<<<<|<<<|<(V)<|<<<| | |L2 | | . . | . |Packet U | . . | . | . . | . | . . | .*| . . | |L2 |___|_____|___|_____|___|_____|___|_____|___|_____|___|_____|___| source subnet G router subnet H dest __ _ _ _ __ _ _ _ __ _ _ __ _ _ _ later | | | | | | | | | | | | | | | | |C| | data________\ |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (W) / 4 3 2 4 3 2 4 3 4 3 2 _ /__ |C| Feedback control \ |_| cell/frame (V) 2 __ _ _ _ __ _ _ _ __ _ _ __ _ _ _ earlier | | | | | | | | | | | | | | | | | | | data________\ |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (U) / layer: 4 3 2 4 3 2 4 3 4 3 2 header ]]></artwork> </figure> <t>ATM's feed-backward approach does not fit well when layered beneath 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 had achieved its aspiration of becoming the global internetwork standard, rather than just a subnetwork technology)--> <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 (*), it does notfeed-forwardfeed forward any congestion indications on the packet (U).InsteadInstead, it sends a control cell (V) back to the router at the ATM ingress.</t> <t>However, the backward feedback does not reach the original data source directly because IP does not support backward feedback (and subnet G is independent of subnet H). Instead, the router in the middle throttles down its sendingraterate, but the original data sources don't reduce their rates. The resulting rate mismatch causes the 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(e.g.(e.g., packet W). Note that the forward signal from the middle router is not triggered directly by the backward signal. Rather, it is triggered by congestion resulting from the middle router's mismatched rate response to the backward signal.</t> <t>In response to this later forward signalling, end-to-end feedback atlayer-4layer 4 finally completes the tortuous path of congestion indications back to the origin datasource,source as before.</t> <t>Quantizedcongestion notification (QCNCongestion Notification (QCN) <xref target="IEEE802.1Q"format="default"/>)format="default"/> would suffer from similar problems if extended to multiple subnets. However,from the startQCN was clearly characterized as solely applicable to a single subnet from the start (see <xref target="ecnencap_Guidelines_Backward" format="default"/>).</t> <!--To summarise so far, feeding congestion notification backwards can reach the source faster, but only 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 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.--> </section> <section anchor="ecnencap_Null" numbered="true" toc="default"> <name>Null Mode</name><t>Often link<t>Link andphysical layerphysical-layer resources are often 'non-blocking' by design.In these cases congestion notificationCongestion notifications may be implemented in these cases, but it does not need to be deployed at the lower layer; ECN in IP would be sufficient.</t> <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 back up, while the lower layer remains immune to congestion. Even a whole meshed subnetwork can be made immune to interior congestion by limiting ingress capacity and sufficient sizing of interior links,e.g.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 multi-path routing to ensure even worst-case patterns of load cannot congest any link,e.g.e.g., a Clos network <xref target="Clos53" format="default"/>.</t> </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"> <name>Feed-Forward-and-Up Mode: Guidelines for Adding Congestion Notification</name> <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 IP-in-IP tunnels <xref target="RFC6040" format="default"/>, whether encapsulating with IPv4 <xref target="RFC2003" format="default"/>, IPv6 <xref target="RFC2473"format="default"/>format="default"/>, or IPsec <xref target="RFC4301" format="default"/>. These RFCs take a consistent approach and the following guidelines are designed to ensure this consistency continues as ECN support is added to other protocols that encapsulate IP. The guidelines are also designed to ensure compliance with the more general best current practice for the design of alternate ECN schemes given in <xref target="RFC4774" format="default"/> and extended by <xref target="RFC8311" format="default"/>.</t> <t>The rest of this section is structured as follows:</t> <ul spacing="normal"> <li> <xref target="ecnencap_IP-IP_Coupled_Shim_Tunnels" format="default"/> addresses the most straightforward cases, where <xref target="RFC6040" format="default"/> can be applied directly to add ECN to tunnels that are effectively IP-in-IP tunnels, but with a shim header(s) between the IP headers.</li> <li> <t>The subsequent sections give guidelines for adding ECN to a 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 applied directly. Specifically:</t> <ul spacing="normal"> <li>Sections <xref format="counter" target="ecnencap_WireProtocolECNSupport"/>, <xref format="counter"target="ecnencap_EncapGuidelines"/>target="ecnencap_EncapGuidelines"/>, and <xref format="counter" target="ecnencap_DecapGuidelines"/>respectivelyaddress how to add ECN support to the wire protocol and to the encapsulators and decapsulators at the ingress and egress of thesubnet.</li>subnet, respectively.</li> <li> <xref target="ecnencap_Sequences" format="default"/> deals with thespecial,special butcommon,common case of sequences of tunnels or subnets that all use the sametechnology</li>technology.</li> <li> <xref target="ecnencap_Reframing" format="default"/> deals with the question of reframing when IP packets do not map 1:1 intolower layerlower-layer frames.</li> </ul> </li> </ul> <section anchor="ecnencap_IP-IP_Coupled_Shim_Tunnels" numbered="true" toc="default"> <name>IP-in-IP Tunnels with Shim Headers</name> <t>A common pattern for many tunnelling protocols is to encapsulate an 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 packet as an outer header. Another common pattern is for a shim to encapsulatea layer 2 (L2)an L2 header, which in turn encapsulates (or might encapsulate) an IP header. <xreftarget="I-D.ietf-tsvwg-rfc6040update-shim"target="RFC9601" format="default"/> clarifies thatRFC 6040<xref target="RFC6040"/> is just as applicable when thereareis a shim(s) and possiblyaan L2 header between two IP headers.</t> <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 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 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 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"target="I-D.ietf-tsvwg-rfc6040update-shim"target="RFC9601" format="default"/> requires network 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> <t>Nonetheless, in many cases it is feasible to propagate the ECN field between IP headers separated by a shim header(s) and/oraan L2 header. Particularly in the typical case when the outer IP header and the shim(s)areis added (or removed) as part of the same procedure. Even if the shim(s)encapsulate aencapsulates an L2 header, it is often possible to find 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 the feed-up-and-forward mode (<xref target="ecnencap_Up" format="default"/>), so the guidelines for this mode apply (<xref target="ecnencap_Guidelines_Up" format="default"/>).</t> <t>Numerous shim protocols have been defined for IP tunnelling. More recentones e.g.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 followRFC 6040. And some<xref target="RFC6040"/>. Some earlier ones,e.g.e.g., CAPWAP <xref target="RFC5415" format="default"/> and LISP <xref target="RFC9300" format="default"/>, citeRFC 3168,<xref target="RFC3168"/>, which is compatible withRFC 6040.</t><xref target="RFC6040"/>.</t> <t>However, as <xref section="9.3" target="RFC3168" format="default"/> pointed out, ECN support needs to be defined for many earlier shim-based tunnelling protocols,e.g.e.g., L2TPv2 <xref target="RFC2661" format="default"/>, L2TPv3 <xref target="RFC3931" format="default"/>, GRE <xref target="RFC2784" format="default"/>, PPTP <xref target="RFC2637" format="default"/>, GTP <xref target="GTPv1"format="default"/>,format="default"/> <xref target="GTPv1-U" format="default"/>, <xref target="GTPv2-C"format="default"/>format="default"/>, and Teredo <xref target="RFC4380"format="default"/>format="default"/>, as well as some recent ones,e.g.e.g., VXLAN <xref target="RFC7348" format="default"/>, NVGRE <xref target="RFC7637"format="default"/>format="default"/>, and NSH <xref target="RFC8300" format="default"/>.</t> <t>All these IP-based encapsulations can be updated in one shot by simple reference toRFC 6040.<xref target="RFC6040"/>. However, it would not be appropriate to update all these protocols from within the present guidance document.InsteadInstead, a companion specification <xreftarget="I-D.ietf-tsvwg-rfc6040update-shim"target="RFC9601" format="default"/> hasbeen prepared that hasthe appropriatestandards trackStandards Track status to updatestandards trackStandards Track protocols. For those that are not under IETF change control <xreftarget="I-D.ietf-tsvwg-rfc6040update-shim"target="RFC9601" format="default"/> can only recommend that the relevant body updates them.</t> </section> <section anchor="ecnencap_WireProtocolECNSupport" numbered="true" toc="default"> <name>Wire Protocol Design: Indication of ECN Support</name> <t>This section is intended to guide the redesign of anylower layerlower-layer protocol thatencapsulateencapsulates IP to add native ECN support at the lower layer. It reflects the approaches used in <xref target="RFC6040" format="default"/> and in <xref target="RFC5129" format="default"/>.ThereforeTherefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with <xref target="RFC6040" format="default"/> or <xref target="RFC5129" format="default"/> will already satisfy this guidance.</t> <t>Alower layerlower-layer (or subnet) congestion notification system:</t> <ol spacing="normal"type="1"><li>SHOULD NOTtype="1"><li><bcp14>SHOULD NOT</bcp14> applyexplicit congestion notificationsECNs to PDUs that are destined for legacy layer-4 transport implementations that will not understandECN,ECN; and</li> <li anchor="ecnencap_Egress_Check"><t>SHOULD NOT<t><bcp14>SHOULD NOT</bcp14> applyexplicit congestion notificationsECNs to PDUs if the egress of the subnet might not propagate congestion notifications onward into the higher layer.</t> <t>We use the term ECN-PDUs for a PDU on a feedback loop that will propagate congestionnotificationnotifications properly because it meets both the above criteria.AndAdditionally, a Not-ECN-PDU is a PDU on a feedback loop that does not meet at least one of the criteria, andwilltherefore will not propagate congestionnotificationnotifications properly. A corollary of the above is that alower layerlower-layer congestion notification protocol:</t> </li><li>SHOULD<li><bcp14>SHOULD</bcp14> be able to distinguish ECN-PDUs from Not-ECN-PDUs.</li> </ol> <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 signals from different nodes is fine. However, if <em>any</em> interior nodes might generate ECN markings,guidelineGuideline <xref format="counter" target="ecnencap_Egress_Check"/> above says that all relevant egressnode(s) SHOULDnodes <bcp14>SHOULD</bcp14> be able to propagate those markings up to the higher layer.</t> <t>In IP, if the ECN field in each PDU is cleared to theNot-ECT (not ECN-capable transport)Not ECN-Capable Transport (Not-ECT) codepoint, it indicates that the L4 transport will not understand congestion markings. A congested buffer must not mark these Not-ECTPDUs, and thereforePDUs; therefore, it has to signal congestion by increasingly applying drop instead.</t> <t>The mechanism a lower layer uses to distinguish theECN-capabilityECN capability of PDUs need not mimic that of IP. The above guidelines merely say that thelower layer system,lower-layer system as awhole,whole should achieve the same outcome. For instance, ECN-capable feedback loops might use PDUs that are identified by a particular set of labels or tags. Alternatively,logical linklogical-link protocols that use flow state might determine whether a PDU can be congestion marked by checking for ECN-support in the flow state. Other protocols might depend on out-of-band control 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 congestion markings to L4 transports that will not understandthem,them without using any header space in the subnet protocol.</t> <t>In MPLS, header space is extremelylimited, therefore RFC5129limited; therefore, <xref target="RFC5129"/> does 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 allowed to set explicit congestion indications without checking whether the PDU is destined for a L4 transport that will understand them. Nonetheless, this is made safe by requiring that the network operator upgrades all decapsulating edges of a whole domain atonce,once as soon as even one switch within the domain is configured to mark rather than drop some PDUs during congestion. Therefore, any edge node that might decapsulate a packet will be capable of checking whether the 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 isECN-capable.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 header) indicates the transport is not ECN-capable, it drops the packet—-- effectively on behalf of the earlier congested node (see Decapsulation Guideline <xref format="counter" target="ecnencap_dropNot-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuidelines" format="default"/>).</t> <t>It was only appropriate to define such an incremental deployment strategy because MPLS is targeted solely at professionaloperators,operators who can be expected to ensure that a whole subnetwork is consistently configured. This strategy might not be appropriate for other link technologies targeted at zero-configuration deployment or deployment by the general public(e.g.(e.g., Ethernet). For such 'plug-and-play'environmentsenvironments, it will be necessary to invent afailsafefail-safe approach that ensures congestion markings will never fall into black holes, no matter how inconsistently a system is put together. Alternatively, congestionnotificationnotifications relying on correct system configuration could be confined to flavours of Ethernet intended only for professional network operators, such as Provider Backbone Bridges(PBB <xref(PBB) (<xref target="IEEE802.1Q" format="default"/>; previously 802.1ah).</t> <t>ECN support inTRILLTRansparent Interconnection of Lots of Links (TRILL) <xreftarget="I-D.ietf-trill-ecn-support"target="RFC9600" format="default"/> provides a good example of how to add ECN to alower layerlower-layer protocol without relying on careful and consistent operator configuration. TRILL provides an extension header word with space for flags of different categories depending on whether logic to understand the extension is critical. Thecongestion experiencedcongestion-experienced marking has been 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.ThereforePerhaps: 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 any logic to process it, it will drop it; which is the desired default action anyway. Therefore, TRILL RBridges can be updated with support for ECN in no particular order and, at the egress of the TRILL campus, congestionnotificationnotifications will be propagated to IP as ECN whenever ECN logic has been implemented at the egress, or as drop otherwise.</t> <t>QCN <xref target="IEEE802.1Q" format="default"/> is not intended to extend beyond a singlesubnet,subnet ortointeroperate with ECN. Nonetheless, the way QCN indicates tolower layerlower-layer devices that theend-pointsendpoints will not understand QCN provides another example that alower layerlower-layer protocol designer might be able to mimic for their scenario. <!-- [rfced] Please clarify this sentence. Is it indicating that both non-QCN 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<xref[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" format="default"/>; 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.</t> <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 drop, as was originally required by <xref target="RFC3168" format="default"/>. <xref target="RFC8311" format="default"/> updatedRFC 3168,<xref target="RFC3168"/> to allow experimentation with congestion markings that are not equivalent to drop,in particularparticularly for L4S <xref target="RFC9331" format="default"/>. ECN support in TRILL <xreftarget="I-D.ietf-trill-ecn-support"target="RFC9600" format="default"/> is a good example of a way to defer drop to the egress of a subnet both when marks are equivalent to drops (as inRFC 3168)<xref target="RFC3168"/>) and when they are not (as in L4S). The ECN scheme for MPLS <xref target="RFC5129" format="default"/> was defined before L4S, so it only currently supports deferred drop that is equivalent toECN-marking.ECN marking. Nonetheless, in principle, MPLS (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> </section> <section anchor="ecnencap_EncapGuidelines" numbered="true" toc="default"> <name>Encapsulation Guidelines</name> <t>This section is intended to guide the redesign of any node that encapsulates IP with alower layerlower-layer header when adding native ECN support to thelower layerlower-layer protocol. It reflects the approaches used in <xref target="RFC6040" format="default"/> andin<xref target="RFC5129" format="default"/>.ThereforeTherefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with <xref target="RFC6040" format="default"/> or <xref target="RFC5129" format="default"/> will already satisfy this guidance.</t> <ol spacing="normal" type="1"><li> <t>Egress Capability Check: A subnet ingress needs to be sure that the corresponding egress of a subnet will propagate any congestionnotificationnotifications added to the outer header across the subnet. This is necessary in addition to checking that an incoming PDU indicates an ECN-capable (L4) transport. Examples of how this guarantee might be provided include:</t> <ul spacing="normal"> <li>by configuration(e.g.(e.g., if any label switches in a domainsupportsupports ECN marking, <xref target="RFC5129" format="default"/> requires all egress nodes to have been configured to propagateECN)</li>ECN).</li> <li>by the ingress explicitly checking that the egress propagates ECN(e.g.(e.g., an early attempt to add ECN support to TRILL used IS-IS to check path capabilities before adding ECN extension flags to each frame <xref target="RFC7780" format="default"/>).</li> <li>by inherent design of the protocol(e.g.(e.g., by encoding ECN marking on the outer header in such a way that a legacy egress that does not understand ECN will consider the PDU corrupt or invalid and discardit, thusit; thus, at least propagating a form of congestion signal).</li> </ul> </li> <li>Egress Fails Capability Check: If the ingress cannot guarantee that the egress will propagate congestionnotification,notifications, the ingressSHOULD<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 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 a concept.</li> <li anchor="ecnencap_Encap_Copy"> <t>Standard Congestion Monitoring Baseline: Once the ingress to a subnet has established that the egress will correctly propagate ECN,on encapsulationitSHOULD<bcp14>SHOULD</bcp14> encode the same level of congestion in outer headers as is arriving in incomingheaders.headers on encapsulation. For example, it might copy any incoming congestionnotificationnotifications into the outer header of thelower layerlower-layer protocol.</t> <t>This ensures that bulk congestion monitoring of outer headers(e.g.(e.g., by a network management node monitoring ECN in passing frames) will measure congestion accumulated along the whole upstreampath —path, starting from the Load Regulator and not just starting from the ingress of the subnet. A node that is not the Load RegulatorSHOULD NOT<bcp14>SHOULD NOT</bcp14> re-initialize the level of CE markings in the outer header to zero. </t> <t>It would still also be possible to measure congestion introduced across one subnet (or tunnel) by subtracting the level of CE markings on inner headers from that on outer headers (seeAppendix C of<xref target="RFC6040"format="default"/>).sectionFormat="of" section="C"/>). For example:</t> <ul spacing="normal"> <li>If this guideline has been followed and if the level of CE markings is 0.4% on the outer header and 0.1% on theinner,inner header, 0.4% congestion has been introduced across all the networks since theload regulator,Load Regulator, and 0.3% (= 0.4% - 0.1%) has been introduced since the ingress to the current subnet (ortunnel);</li>tunnel).</li> <li>Without this guideline, if the subnet ingress had re-initialized the outer congestion level to zero, the outer and inner headers would measure 0.1% and 0.3%. It would still be possible to infer that the congestion introduced since the Load Regulator was 0.4% (= 0.1% +0.3%). But0.3%), but only if the monitoring system somehow knows whether the subnet ingress re-initialized the congestion level.</li> </ul> <t>As long as subnet and tunnel technologies use the standard congestion monitoring baseline in this guideline, monitoring systems will know to use the formerapproach,approach rather than having to "somehow know" which approach to use.<!--{If required, an example can be given of where it would be appropriate to contradict thisSHOULD.SHOULD 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 scheme.} --> </t> </li> </ol> </section> <section anchor="ecnencap_DecapGuidelines" numbered="true" toc="default"> <name>Decapsulation Guidelines</name> <t>This section is intended to guide the redesign of any node that decapsulates IP from within alower layerlower-layer header when adding native ECN support to thelower layerlower-layer protocol. It reflects the approaches used in <xref target="RFC6040" format="default"/> and in <xref target="RFC5129" format="default"/>.ThereforeTherefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with <xref target="RFC6040" format="default"/> or <xref target="RFC5129" format="default"/> will already satisfy this guidance.</t> <t>A subnet egressSHOULD NOT<bcp14>SHOULD NOT</bcp14> simply copy congestionnotificationnotifications from outer headers to the forwarded header. ItSHOULD<bcp14>SHOULD</bcp14> calculate the outgoing congestion notification field from the inner and outer headers using the following guidelines. If there is any conflict, rules earlier in the list take precedence over rules later in thelist:</t>list.</t> <ol spacing="normal" type="1"><li anchor="ecnencap_dropNot-ECTinnerCEouter"> <t>If the arriving inner header is aNot-ECN-PDUNot-ECN-PDU, it implies the L4 transport will not understand explicit congestion markings. Then:</t> <ul spacing="normal"> <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 transport will understand. If the congestion marking is the most severe possible, the packetMUST<bcp14>MUST</bcp14> be dropped. 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 packetSHOULD<bcp14>SHOULD</bcp14> be dropped.</li> <li>If the outer is an ECN-PDU that carries no indication of congestion or a Not-ECN-PDU the PDUSHOULD<bcp14>SHOULD</bcp14> be forwarded, but still as a Not-ECN-PDU.</li> </ul> </li> <li>If the outer header does not supportexplicit congestion notificationENC (a Not-ECN-PDU), but the inner header does (an ECN-PDU), the inner headerSHOULD<bcp14>SHOULD</bcp14> be forwarded unchanged.</li> <li>In somelower layer protocolslower-layer protocols, congestion may be signalled as a numerical level, such as in the control frames ofquantized congestion notification (QCNQCN <xref target="IEEE802.1Q"format="default"/>).format="default"/>. If such a multi-bit encoding encapsulates an ECN-capable IP data packet, a function will be needed to convert the quantized congestion level into the frequency of congestion markings in outgoing IP packets.</li> <li> <t>Congestion indications might be encoded by a severity level. Forinstanceinstance, increasing levels of congestion might be encoded by numerically increasing indications,e.g. pre-congestion notification (PCN)e.g., PCN can be encoded in each PDU at three severity levels in IP or MPLS <xref target="RFC6660" format="default"/> and the default encapsulation and decapsulation rules <xref target="RFC6040" format="default"/> are compatible with this interpretation of the ECN field. </t> <t>If the arriving inner header is an ECN-PDU, where the inner and outer headers carry indications of congestion of different severity, the more severe indicationSHOULD<bcp14>SHOULD</bcp14> be forwarded in preference to the less severe.</t> </li> <li> <t>The inner and outer headers might carry a combination of congestion notification fields that should not be possible given any currently used protocol transitions. For instance, if Encapsulation Guideline <xref format="counter" target="ecnencap_Encap_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 the outer header than in theinner.inner header. ItMAY<bcp14>MAY</bcp14> be appropriate to log unexpected combinations of headers and possibly raise an alarm. </t> <t>If a safe outgoing codepoint can be defined for such a PDU, the PDUSHOULD<bcp14>SHOULD</bcp14> be forwarded rather than dropped. Some implementers discard PDUs with currently unused combinations of headers just in case they represent an attack. However, an approach using alarms and policy-mediated drop is preferable to hard-codeddrop,drop so that operators can keep track of possibleattacksattacks, but currently unused combinations are not precluded from future use through new standards actions.</t> </li> </ol> </section> <section anchor="ecnencap_Sequences" numbered="true" toc="default"> <name>Sequences of Similar Tunnels or Subnets</name> <t>In some deployments, particularly in 3GPP networks, an IP packet may traverse (in sequence) two or more IP-in-IP tunnelsin sequencethat all use identical technology(e.g.(e.g., GTP).</t> <t>In such cases, it would be sufficient for every encapsulation and decapsulation in the chain to comply withRFC 6040.<xref target="RFC6040"/>. <!-- [rfced] Should "outer" and "inner" be specified as "outer header" and "inner header" in this sentence for clarity? Original: Alternatively, 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.ThenPerhaps: 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 withRFC 6040.</t> <t>Appendix C of RFC6040<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 operator might want to monitor how much congestion had been introduced within a whole sequence of tunnels. Using the technique inAppendix C of RFC6040<xref target="RFC6040" sectionFormat="of" section="C"/> at the final egress, the operator could monitor the whole sequence of tunnels, but only if the aboveoptimisationoptimization were used consistently along the sequence of tunnels, in order to make it appear as a single tunnel. Therefore, tunnel endpoint implementationsSHOULD<bcp14>SHOULD</bcp14> allow the operator to configure whether thisoptimisationoptimization is enabled.</t> <t>When ECN support is added to a subnet technology, considerationSHOULD<bcp14>SHOULD</bcp14> be given to a similaroptimisationoptimization between subnets in sequence if they all use the same technology.</t> </section> <section anchor="ecnencap_Reframing" numbered="true" toc="default"> <name>Reframing and Congestion Markings</name> <t>The guidance in this section is worded in terms of framing boundaries, but it applies equally whether theprotocol data unitsPDUs are frames,cellscells, or packets.</t> <t>Where an AQM marks the ECN field of IP packets as they queue into alayer-2Layer 2 link, there will be no problem with framingboundaries,boundaries because the ECN markings would be applied directly to IP packets. The guidance in this section is only applicable where an ECN capability is being added to alayer-2Layer 2 protocol so thatlayer-2Layer 2 frames can be ECN-marked by an AQM atlayer-2.layer 2. This would only be necessary where AQM will be applied at purelayer-2Layer 2 nodes (withoutIP-awareness).</t>IP awareness).</t> <t>Where ECN marking has had to be applied at non-IP-aware nodes and framing boundaries do not necessarily align with packet boundaries, the decapsulating IP forwarding nodeSHOULD<bcp14>SHOULD</bcp14> propagate ECN markings fromlayer-2Layer 2 frame headers to IP packets that may have different 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, 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_presence">approximate preservation of the presence (and therefore timing) of congestion marks on the L2 frames used to construct an IP packet;</li> <li anchor="ecnencap_reframing_goal_proportion"> <ol spacing="normal" type="a"><li>at high frequency of congestion marking, approximate preservation of the proportion of congestion marks arriving and departing;</li> <li>at low frequency of congestion marking, approximate preservation of the timing of congestion marks arriving and departing.</li> </ol> </li> </ol> <t>In either case, an implementationSHOULD<bcp14>SHOULD</bcp14> ensure that any new incoming congestion indication is propagatedimmediately,immediately and not held awaiting the possibility of further congestion indications to be sufficient to indicate congestion on an outgoing PDU <xref target="RFC7141" format="default"/>. Nonetheless, to facilitate pipelined implementation, it would be acceptable for congestion marks to propagate to a slightly later IP packet.</t><t>At<t> At decapsulation in eithercase:</t> <ul spacing="normal"> <li>ECN markingcase, ECN-marking propagation logically occurs before application of Decapsulation Guideline <xref format="counter" target="ecnencap_dropNot-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuidelines" format="default"/>. <!-- [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<xref format="counter" target="ecnencap_dropNot-ECTinnerCEouter"/>;</li> <li>where1; * 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 bediscarded.</li> <li>wherediscarded. * where a mix of different types of ECN-PDUs arrives to construct the same IP packet,e.g. ae.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 to an IP packet that is a Not-ECN-PDU, then that IP packet is dropped in accordance with Guideline <xreftarget="RFC3168" format="default"/>,format="counter" target="ecnencap_dropNot-ECTinnerCEouter"/>:</t> <ul> <li>where a mix of ECN-PDUs and non-ECN-PDUs arrives to construct the same IP packet, the decapsulation specification <bcp14>SHOULD</bcp14> require that packet to be discarded.</li> <li>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 <bcp14>SHOULD</bcp14> require the resulting IP packet to be set to either ECT(0) or ECT(1). In this case, it <bcp14>SHOULD</bcp14> take into account that the RFC Series has so far allowed ECT(0) and ECT(1) to be considered equivalent <xref target="RFC3168" format="default"/>; otherwise, ECT(1) can provide a less severe congestion marking than CE <xref target="RFC6040"format="default"/>,format="default"/> or ECT(1) can indicate an unmarked but ECN-capable packet that is subject to a different marking algorithm to ECT(0) packets,for examplee.g., L4S <xref target="RFC8311" format="default"/> <xref target="RFC9331"format="default"/>.</li> </ul>format="default"/>.</li></ul> <t>The following are two ways that goal <xref format="counter" target="ecnencap_reframing_goal_presence"/> might be achieved, but they are not intended to be the only ways:</t> <ul spacing="normal"> <li>Every IP PDU that is constructed, in whole or in part, from an L2 frame that is marked with a congestionsignal,signal has that signal propagated toit;</li>it.</li> <li>Every L2 frame that is marked with a congestionsignal,signal propagates that signal to one IP PDUwhichthat isconstructed,constructed from it in whole or inpart, from it.part. If multiple IP PDUs meet this description, the choice can be made arbitrarily but ought to be consistent.</li> </ul> <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> <ul spacing="normal"> <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, a counter ('in') tracks octets arriving within the payload of marked L2 frames and another ('out') tracks octets departing in marked IP packets. While 'in' exceeds 'out', forwarded IP packets are ECN-marked. If 'out' exceeds 'in' for longer than a timeout, both counters arezeroed,zeroed to ensure that the start of the next congestion episode propagates immediately. The 'out' counter includes octets in reconstructed IP packets that would have been marked, but had to be dropped because they were Not-ECN-PDUs (by Decapsulation Guideline <xref format="counter" target="ecnencap_dropNot-ECTinnerCEouter"/> in <xref target="ecnencap_DecapGuidelines" format="default"/>).</li> </ul> <t>Generally, the number of L2 frames may be higher(e.g. ATM),(e.g., ATM) than, similar to, or lower(e.g.(e.g., 802.11 aggregation ataan L2-only station) than the number of IPPDUs, andPDUs; this distinction may influence the choice of mechanism.</t> </section> </section> <section anchor="ecnencap_Guidelines_Up" numbered="true" toc="default"> <name>Feed-Up-and-Forward Mode: Guidelines for Adding Congestion Notification</name> <t>The guidance in this section is applicable, for example, when IP packets:</t> <ul spacing="normal"> <li>are encapsulated in Ethernet headers, which have no support for ECN;</li> <li>are forwarded by the eNode-B (base station) of a 3GPP radio access network, which is required to apply ECN marking duringcongestion,congestion <xref target="LTE-RA"format="default"/>,format="default"/> <xref target="UTRAN" format="default"/>, but the Packet Data Convergence Protocol (PDCP) that encapsulates the IP header over the radio access has no support for ECN.</li> </ul> <t>This guidance also generalizes to encapsulation by other subnet technologies with no native support forexplicit congestion notificationECN at the lower layer, but with support for finding and processing an IP header. It is unlikely to be applicable or necessary for IP-in-IP encapsulation, where feed-forward-and-up mode based on <xref target="RFC6040" format="default"/> would be more appropriate.</t> <t>Marking the IP header while switching atlayer-2layer 2 (by using alayer-3Layer 3 switch) or while forwarding in a radio access network seems to represent a layering violation. However, it can be considered as a benignoptimisationoptimization if the guidelines below are followed. Feed-up-and-forward is certainly not a general alternative to implementing feed-forward congestion notification in the lower layer, because:</t> <ul spacing="normal"> <li>IPv4 and IPv6 are not the onlylayer-3Layer 3 protocols that might be encapsulated bylower layer protocols</li>lower-layer protocols.</li> <li>Link-layer encryption might be in use, making thelayer-2Layer 2 payloadinaccessible</li>inaccessible.</li> <li>Many Ethernet switches do not have'layer-3'Layer 3 switch'capabilitiescapabilities, so they cannot read or modify an IPpayload</li>payload.</li> <li>It might be costly to find an IP header (IPv4 or IPv6) when it may be encapsulated by more than onelower layerlower-layer header,e.g.e.g., Ethernet MAC in MAC (<xref target="IEEE802.1Q" format="default"/>; previously 802.1ah).</li> </ul> <t>Nonetheless, configuringlower layerlower-layer equipment to look for an ECN field in an encapsulated IP header is a usefuloptimisation.optimization. If the implementation follows the guidelines below, thisoptimisationoptimization does not have to be confined to a controlledenvironment such asenvironment, e.g., within a data centre; it could usefully be applied on any network—-- even if the operator is not sure whether the above issues will never apply:</t> <ol spacing="normal" type="1"><li>If a native lower-layer congestion notification mechanism exists 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, it will generally be more efficient to use the native mechanism.</li> <li>The depth of the search for an IP headerSHOULD<bcp14>SHOULD</bcp14> be limited. If an IP header is not found soon enough, or an unrecognized or unreadable header is encountered, the switchSHOULD<bcp14>SHOULD</bcp14> resort to an alternative means of signalling congestion(e.g. drop,(e.g., drop or the nativelower layerlower-layer mechanism if available).</li> <li>It is sufficient to use the first IP header found in the stack; the egress of the relevant tunnel can propagate congestion notification upwards to any more deeply encapsulated IP headers later.</li> </ol> </section> <section anchor="ecnencap_Guidelines_Backward" numbered="true" toc="default"> <name>Feed-Backward Mode: Guidelines for Adding Congestion Notification</name> <t>It can be seen from <xref target="ecnencap_Backward" format="default"/> that congestionnotificationnotifications in a subnet using feed-backward modehashave generally not been designed to be directly coupled withIP layerIP-layer congestionnotification.notifications. The subnet attempts to minimize congestion internally, and if the incoming load at the ingress exceeds the capacity somewhere through the subnet, thelayerLayer 3 buffer into the ingress backs 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 the subnet andhigher layerhigher-layer congestionnotification. Thereforenotifications. Therefore, no detailed protocol design guidelines are appropriate. Nonetheless, a more general guideline is appropriate: </t><ul empty="true" spacing="normal"> <li>A<blockquote>A subnetwork technology intended to eventually interface to IPSHOULD NOT<bcp14>SHOULD NOT</bcp14> be designed using only the feed-backward mode, which is certainly best for a stand-alone subnet, but would need to be modified to work efficiently as part of the widerInternet,Internet because IP uses feed-forward-and-upmode.</li> </ul>mode.</blockquote> <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 can result in very inefficient and sluggish congestion control—-- except if it is confined to the subnet directly connected to the original datasource,source when it is faster than feed-forward. It would be 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 cross subnets.</t> <t>In the early days of TCP/IP, a similar feed-backward approach was tried for explicit congestionsignalling,signalling using source-quench (SQ) ICMP 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 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 also hard for alower layerlower-layer buffer to address an SQ message to the original source port number, which may be buried within many layers ofheaders,headers and possibly encrypted.</t> <t>QCN (also known asbackward congestion notification, BCN;Backward Congestion Notification (BCN); see Sections30–3330-33 of <xref target="IEEE802.1Q"format="default"/>;format="default"/>, previously known as 802.1Qau) uses a feed-backward mode that is structurally similar to ATM's relative rate mechanism. However, QCN confines its applicability to scenarios such as some data centres where all endpoints are directly attached by the same Ethernet technology. If a QCN subnet were later connected into a wider IP-based internetwork(e.g.(e.g., when attempting to interconnect multiple data centres) it would suffer the inefficiency 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} 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 feedback loop. In these cases, the function that regulates load at the start of each segment will need to reset congestion notification (i.e. clear any accumulated congestion notifications) at the start of its segment.--> </section><!-- ================================================================ --><section anchor="ecnencap_IANA_Considerations"removeInRFC="true"numbered="true" toc="default"> <name>IANA Considerations</name> <t>Thismemo includesdocument has norequest to IANA.</t>IANA actions.</t> </section><!-- ================================================================ --><section anchor="ecnencap_Security_Considerations" numbered="true" toc="default"> <name>Security Considerations</name> <t>If alower layerlower-layer wire protocol is redesigned to include explicit congestion signalling in-band in the protocol header, careSHOULD<bcp14>SHOULD</bcp14> be taken to ensure that the field used is specified as mutable during transit.OtherwiseOtherwise, interior nodes signalling congestion would invalidate any authentication protocol applied to thelower layerlower-layer header—-- by altering a header field that had been assumed as immutable.</t> <t>The redesign of protocols that encapsulate IP in order to propagate congestion signals between layers raises potential signal integrity concerns. Experimental or proposed approaches exist for assuring the end-to-end integrity of in-band congestion signals,e.g.:</t>such as:</t> <ul spacing="normal"> <li>Congestion exposure (ConEx) for networks to audit that their congestion signals are not being suppressed by other networks or by receivers, andfor networksto police that senders are responding sufficiently to the signals, irrespective of the L4 transport protocol used <xref target="RFC7713" format="default"/>.</li> <li>A test for a sender to detect whether a network or the receiver is suppressing congestion signals (forexampleexample, see2nd parathe second paragraph of <xref section="20.2" target="RFC3168" format="default"/>).</li> </ul> <t>Given these end-to-end approaches are already being specified, it would make little sense to attempt to design hop-by-hop congestion signal integrity into a newlower layer protocol,lower-layer protocol because end-to-end integrity inherently achieves hop-by-hop integrity.</t> <t><xref target="ecnencap_Guidelines_Backward" format="default"/> gives vulnerability to spoofing as one of the reasons for deprecating feed-backward mode.</t> </section><!-- ================================================================ --><section anchor="ecnencap_Conclusions" numbered="true" toc="default"> <name>Conclusions</name> <t>Following the guidance in this document enables ECN support to be extended consistently to numerous protocols that encapsulate IP (IPv4 andIPv6),IPv6) so that IP continues to fulfil its role as an end-to-end interoperability layer. This includes:</t> <ul spacing="normal"> <li>A wide range of tunnellingprotocolsprotocols, including those with various forms of a shim header between two IP headers, possibly also separated byaan L2 header;</li> <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 IP and MPLS.</li> </ul> <t>Guidelines have been defined for supporting propagation of ECN between Ethernet and IP on so-calledLayer-3Layer 3 Ethernetswitches,switches using a '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 support ECN natively.</t> <t>Finally, attempting to add ECN to a subnet technology in feed-backward mode is deprecated except in specialcases,cases due to its likely sluggish response to congestion.</t> </section> </middle> <back><!-- ================================================================ --><displayreference target="I-D.ietf-intarea-gue" to="INTAREA-GUE"/> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"> <front> <title>The Addition of Explicit Congestion Notification (ECN) to IP</title> <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/> <author fullname="S. Floyd" initials="S." surname="Floyd"/> <author fullname="D. Black" initials="D." surname="Black"/> <date month="September" year="2001"/> <abstract> <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3168"/> <seriesInfo name="DOI" value="10.17487/RFC3168"/> </reference> <reference anchor="RFC3819" target="https://www.rfc-editor.org/info/rfc3819" 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 communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document specifies an Internet Best Current Practices for the Internet Community, and 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/rfc4774" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml"> <front> <title>Specifying Alternate Semantics for the Explicit Congestion Notification (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 for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that 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 suggestions 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/rfc5129" 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 MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, 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/rfc6040" 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 notification (ECN) field of the IP header should be constructed on entry to and exit from any 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 decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused 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 supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis 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 guidance 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/rfc7141" 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) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3819.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7141.xml"/> <!-- [I-D.ietf-trill-ecn-support] REF state asCoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment 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 preferential treatmentofsmall 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>04/29/2024; companion doc RFC9600 --> <referenceanchor="I-D.ietf-trill-ecn-support" target="https://datatracker.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">anchor="RFC9600" target="https://www.rfc-editor.org/info/rfc9600"> <front><title>TRILL<title> TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification)Support</title>Support </title> <author initials="D." surname="Eastlake" fullname="Donald E. Eastlake3rd" initials="D. E." surname="Eastlake">3rd"> <organization>Huawei</organization> </author> <authorfullname="Bob Briscoe"initials="B."surname="Briscoe">surname="Briscoe" fullname="Bob Briscoe"> <organization>CableLabs</organization> </author> <dateday="25" month="February" year="2018"/> <abstract> <t>Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document extends ECN to TRILL (TRansparent Interconnection of Lots of Links) switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179).</t> </abstract>month="June" year="2024"/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-trill-ecn-support-07"/>name="RFC" value="9600"/> <seriesInfo name="DOI" value="10.17487/RFC9600"/> </reference> </references> <references> <name>Informative References</name><reference anchor="RFC2003" target="https://www.rfc-editor.org/info/rfc2003" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"> <front> <title>IP Encapsulation within IP</title> <author fullname="C. Perkins" initials="C." surname="Perkins"/> <date month="October" year="1996"/> <abstract> <t>This document specifies a method by which an IP datagram may be encapsulated (carried<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2473.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2637.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2884.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6633.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7780.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8084.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8257.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml"/> <!-- [I-D.ietf-intarea-gue] IESG State: Expired (IESG: Dead) aspayload) within an IP datagram. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2003"/> <seriesInfo name="DOI" value="10.17487/RFC2003"/> </reference> <reference anchor="RFC2473" target="https://www.rfc-editor.org/info/rfc2473" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2473.xml"> <front> <title>Generic Packet Tunneling in IPv6 Specification</title> <author fullname="A. Conta" initials="A." surname="Conta"/> <author fullname="S. Deering" initials="S." surname="Deering"/> <date month="December" year="1998"/> <abstract> <t>This document defines the model and generic mechanisms for IPv6 encapsulationofInternet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2473"/> <seriesInfo name="DOI" value="10.17487/RFC2473"/> </reference> <reference anchor="RFC2637" target="https://www.rfc-editor.org/info/rfc2637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2637.xml"> <front> <title>Point-to-Point Tunneling Protocol (PPTP)</title> <author fullname="K. Hamzeh" initials="K." surname="Hamzeh"/> <author fullname="G. Pall" initials="G." surname="Pall"/> <author fullname="W. Verthein" initials="W." surname="Verthein"/> <author fullname="J. Taarud" initials="J." surname="Taarud"/> <author fullname="W. Little" initials="W." surname="Little"/> <author fullname="G. Zorn" initials="G." surname="Zorn"/> <date month="July" year="1999"/> <abstract> <t>This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="2637"/> <seriesInfo name="DOI" value="10.17487/RFC2637"/> </reference> <reference anchor="RFC2661" target="https://www.rfc-editor.org/info/rfc2661" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml"> <front> <title>Layer Two Tunneling Protocol "L2TP"</title> <author fullname="W. Townsley" initials="W." surname="Townsley"/> <author fullname="A. Valencia" initials="A." surname="Valencia"/> <author fullname="A. Rubens" initials="A." surname="Rubens"/> <author fullname="G. Pall" initials="G." surname="Pall"/> <author fullname="G. Zorn" initials="G." surname="Zorn"/> <author fullname="B. Palter" initials="B." surname="Palter"/> <date month="August" year="1999"/> <abstract> <t>This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2661"/> <seriesInfo name="DOI" value="10.17487/RFC2661"/> </reference> <reference anchor="RFC2784" target="https://www.rfc-editor.org/info/rfc2784" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"> <front> <title>Generic Routing Encapsulation (GRE)</title> <author fullname="D. Farinacci" initials="D." surname="Farinacci"/> <author fullname="T. Li" initials="T." surname="Li"/> <author fullname="S. Hanks" initials="S." surname="Hanks"/> <author fullname="D. Meyer" initials="D." surname="Meyer"/> <author fullname="P. Traina" initials="P." surname="Traina"/> <date month="March" year="2000"/> <abstract> <t>This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-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/rfc2884" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2884.xml"> <front> <title>Performance Evaluation of Explicit Congestion Notification (ECN) 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 Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community.</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/rfc2983" 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 Services (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/rfc3931" 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="Goyret"/> <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 for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]</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/rfc4301" 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 Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</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/rfc4380" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml"> <front> <title>Teredo: Tunneling IPv6 over UDP through Network Address Translations (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 service 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 Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such02/12/2024--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-intarea-gue.xml"/> <!-- [I-D.ietf-tsvwg-rfc6040update-shim] REF state 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/rfc5415" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml"> <front> <title>Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification</title> <author fullname="P. Calhoun" initials="P." role="editor" surname="Calhoun"/> <author fullname="M. Montemurro" initials="M." role="editor" surname="Montemurro"/> <author fullname="D. Stanley" initials="D." role="editor" surname="Stanley"/> <date month="March" year="2009"/> <abstract> <t>This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes 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/rfc6633" 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 1812. [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/rfc6660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml"> <front> <title>Encoding Three Pre-Congestion Notification (PCN) States in the 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 protect 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. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.</t> <t>This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within 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-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]</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/rfc7323" 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" surname="Scheffenegger"/> <date month="September" year="2014"/> <abstract> <t>This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (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/rfc7348" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"> <front> <title>Virtual eXtensible Local Area Network (VXLAN): A Framework for 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 virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet 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/rfc7780" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7780.xml"> <front> <title>Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <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 InterconnectionofLots of Links) base protocol in 2011, active development and deployment of TRILL 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 clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" 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/rfc7567" 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="Baker"/> <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 concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate 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/rfc7637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"> <front> <title>NVGRE: Network Virtualization Using Generic Routing Encapsulation</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 Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also 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/rfc7713" 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 same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion 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 elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The04/29/2024; companiondocument, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), 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/rfc8084" 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 transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building 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>doc RFC9601--> <referenceanchor="RFC8087" target="https://www.rfc-editor.org/info/rfc8087" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml">anchor="RFC9601" target="https://www.rfc-editor.org/info/rfc9601"> <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 throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms 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/rfc8174" 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</title> <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 protocol 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/rfc8257" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8257.xml"> <front> <title>Data Center TCP (DCTCP): TCP Congestion Control for Data Centers</title> <author fullname="S. Bensley" initials="S." surname="Bensley"/> <author fullname="D. Thaler" initials="D." surname="Thaler"/> <author fullname="P. Balasubramanian" initials="P." surname="Balasubramanian"/> <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 Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public 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/rfc8300" 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="Quinn"/> <author fullname="U. Elzur" initials="U." role="editor" surname="Elzur"/> <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 provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the 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/rfc8311" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"> <front> <title>Relaxing Restrictions on Explicit Congestion Notification (ECN) 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 congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated 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 related 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/rfc8926" 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="Gross"/> <author fullname="I. Ganga" initials="I." role="editor" surname="Ganga"/> <author fullname="T. Sridhar" initials="T." role="editor" surname="Sridhar"/> <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 important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to 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/rfc9300" 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 Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.</t> <t>LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among 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/rfc9331" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml"> <front> <title>The Explicit Congestion Notification (ECN) Protocol for Low Latency, 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="Briscoe"/> <date month="January" year="2023"/> <abstract> <t>This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth 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 from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether 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.ietf.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), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can 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://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-22" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-rfc6040update-shim.xml"> <front> <title>Propagating<title> Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by aShim</title>Shim </title> <authorfullname="Bob Briscoe"initials="B."surname="Briscoe">surname="Briscoe" fullname="Bob Briscoe"> <organization>Independent</organization> </author> <dateday="29" month="October" year="2023"/> <abstract> <t>RFC 6040 on "Tunnelling of Explicit Congestion Notification" made 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 sufficient 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 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe.</t> </abstract>month="June" year="2024"/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-tsvwg-rfc6040update-shim-22"/>name="RFC" value="9601"/> <seriesInfo name="DOI" value="10.17487/RFC9601"/> </reference> <referenceanchor="IEEE802.1Q" target="https://ieeexplore.ieee.org/document/8403927">anchor="IEEE802.1Q"> <front> <title>IEEE Standard for Local and Metropolitan AreaNetworks—VirtualNetwork--Bridges and BridgedLocal Area Networks—Amendment 6: Provider Backbone Bridges</title>Networks</title> <author> <organization>IEEE</organization> </author> <date month="July" year="2018"/> </front> <seriesInfo name="IEEE Std" value="802.1Q-2018"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/> </reference> <!-- <reference anchor="IEEE802.1ah" target="https://www.ieee802.org/1/pages/802.1ah.html"> <front> <title>IEEE Standard for Local and Metropolitan Area Networks—Virtual Bridged Local Area Networks — Amendment 6: Provider Backbone Bridges</title> <author> <organization>IEEE</organization> </author> <date month="August" year="2008"/> </front> <seriesInfo name="IEEE Std" value="802.1ah-2008"/> <format target="https://www.ieee802.org/1/pages/802.1ah.html" type="HTML"/> <annotation>(Access Controlled link within page)</annotation> </reference> <reference anchor="IEEE802.1Qau" target="https://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=5454061"> <front> <title>IEEE Standard for Local and Metropolitan Area Networks—Virtual Bridged Local Area Networks—Amendment 13: Congestion Notification</title> <author fullname="Norm Finn" initials="N" role="editor" surname="Finn"> <organization>Cisco</organization> </author> <date month="March" year="2010"/> </front> <seriesInfo name="IEEE Std" value="802.1Qau-2010"/> <format target="https://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=5454061" type="PDF"/> <annotation>(Access Controlled link within page)</annotation> </reference> --> <reference anchor="ITU-T.I.371"target="https://www.itu.int/rec/T-REC-I.371">target="https://www.itu.int/rec/T-REC-I.371-200403-I/en"> <front> <title>TrafficControlcontrol andCongestion Controlcongestion control in B-ISDN</title> <author fullname="" initials="" surname=""> <organization>ITU-T</organization> </author> <date month="March" year="2004"/> </front> <seriesInfo name="ITU-TRec." value="I.371 (03/04)"/> <format target="https://www.itu.int/rec/T-REC-I.371" type="PDF"/>Recommendation" value="I.371"/> </reference> <reference anchor="Buck00"> <front> <title>Frame Relay: Technology and Practice</title> <author fullname="Jeff T. Buckwalter" initials="J.T." surname="Buckwalter"> <organization/> </author> <dateday="" month=""year="2000"/> </front> <seriesInfoname="Pub. Addison Wesley" value="ISBN-13: 978-0201485240"/>name="ISBN-13" value="978-0201485240"/> <refcontent>Addison-Wesley Professional</refcontent> </reference> <reference anchor="GTPv1"> <front><title>GPRS<title>General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface</title> <author> <organization>3GPP</organization> </author> <date/> </front> <seriesInfo name="Technical Specification"value="TS 29.060"/>value="29.060"/> </reference> <reference anchor="GTPv1-U"> <front> <title>General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)</title> <author> <organization>3GPP</organization> </author><date/></front> <seriesInfo name="Technical Specification"value="TS 29.281"/>value="29.281"/> </reference> <reference anchor="LTE-RA"> <front> <title>Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2</title> <author> <organization>3GPP</organization> </author> <date/> </front> <seriesInfo name="Technical Specification"value="TS 36.300"/>value="36.300"/> </reference> <reference anchor="UTRAN"> <front> <title>UTRANOverall Description</title>overall description</title> <author> <organization>3GPP</organization> </author><date/></front> <seriesInfo name="Technical Specification"value="TS 25.401"/>value="25.401"/> </reference> <reference anchor="GTPv2-C"> <front><title>Evolved<title>3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane(GTPv2-C)</title>(GTPv2-C); Stage 3</title> <author> <organization>3GPP</organization> </author><date year=""/></front> <seriesInfo name="Technical Specification"value="TS 29.274"/>value="29.274"/> </reference> <reference anchor="ATM-TM-ABR" target="https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/10415-atmabr.html"> <front> <title>Understanding the Available Bit Rate (ABR) Service Category for ATM VCs</title> <author> <organization>Cisco</organization> </author> <dateday="5"month="June" year="2005"/> </front> <seriesInfo name="Design Technote" value="10415"/> </reference> <reference anchor="Leiserson85"> <front> <title>Fat-trees:universalUniversal networks for hardware-efficient supercomputing</title> <author fullname="Charles E. Leiserson" initials="C.E." surname="Leiserson"> <organization/> </author> <dateday=""month="October" year="1985"/> </front> <seriesInfoname="IEEEname="DOI" value="10.1109/TC.1985.6312192"/> <refcontent>IEEE Transactions onComputers" value="34(10):892–901"/>Computers, Vol. C-34, Issue 10</refcontent> </reference> <reference anchor="Clos53"> <front> <title>A Study of Non-Blocking Switching Networks</title> <author fullname="Charles Clos" initials="C." surname="Clos"><organization/></author> <dateday=""month="March" year="1953"/> </front> <seriesInfoname="Bell Systemsname="DOI" value="10.1002/j.1538-7305.1953.tb01433.x"/> <refcontent>The Bell System TechnicalJournal" value="32(2):406–424"/>Journal, Vol. 32, Issue 2</refcontent> </reference> </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 <tsvwg@ietf.org>, and/or to the authors.</t> </section><section anchor="ecnencap_Acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t>Thanks toGorry Fairhurst and David Black<contact fullname="Gorry Fairhurst"/> and <contact fullname="David Black"/> for extensive reviews. Thanks also to the following reviewers:Joe Touch, Andrew McGregor, Richard Scheffenegger, Ingemar Johansson, Piers O'Hanlon, Donald Eastlake, Jonathan Morton, Markku Kojo, Sebastian Möller, Martin Duke and Michael Welzl,<contact fullname="Joe Touch"/>, <contact fullname="Andrew McGregor"/>, <contact fullname="Richard Scheffenegger"/>, <contact fullname="Ingemar Johansson"/>, <contact fullname="Piers O'Hanlon"/>, <contact fullname="Donald Eastlake 3rd"/>, <contact fullname="Jonathan Morton"/>, <contact fullname="Markku Kojo"/>, <contact fullname="Sebastian Möller"/>, <contact fullname="Martin Duke"/>, and <contact fullname="Michael Welzl"/>, who pointed out thatlower layerlower-layer congestion notification signals may have different semantics to those in IP. Thanks are also due to thetsvwgTransport and Services Working Group (tsvwg) chairs, TSV ADs and IETF liaison people such asEric Gray, Dan Romascanu and Gonzalo Camarillo<contact fullname="Eric Gray"/>, <contact fullname="Dan Romascanu"/> and <contact fullname="Gonzalo Camarillo"/> for helping with the liaisons with the IEEE and 3GPP. And thanks toGeorg Mayer<contact fullname="Georg Mayer"/> and particularly toErik Guttman<contact fullname="Erik Guttman"/> for the extensive search and categorisation of any 3GPP specifications that cite ECN specifications. Thanks also to the Area ReviewersDan Harkins, Paul Kyzivat, Sue Hares and Dale Worley.</t> <t>Bob Briscoe<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)for initial drafts then throughand the Reducing Internet Transport Latency (RITE) project(ICT-317700), and(ICT-317700) forfinal drafts (from -18)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 numbered="false" toc="default"> <name>Contributors</name><artwork name="" type="" align="left" alt=""><![CDATA[ Pat Thaler Broadcom<contact fullname="Pat Thaler"> <organization>Broadcom Corporation(retired) CA USA]]></artwork>(retired)</organization> <address> <postal> <region>CA</region> <country>United States of America</country></postal> </address> </contact> <t>Pat was aco-authorcoauthor of this draft, but retired before its publication.</t> </section> </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>