<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" consensus="true" docName="draft-ietf-tsvwg-ecn-encap-guidelines-22" number="9599" ipr="trust200902" updates="3819" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2024-08-30T19:31:28" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines-22" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9599" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ECN Encapsulation Guidelines">Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP</title>
    <seriesInfo name="RFC" value="9599" stream="IETF"/>
    <seriesInfo name="BCP" value="89" stream="IETF"/>
    <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
      <organization showOnFrontPage="true">Independent</organization>
      <address>
        <postal>
          <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 showOnFrontPage="true">Futurewei</organization>
      <address>
        <postal>
          <street>5700 Tennyson Parkway, Suite 600</street>
          <city>Plano</city>
          <region>Texas</region>
          <code>75024</code>
          <country>United States of America</country>
        </postal>
        <email>kjohn@futurewei.com</email>
      </address>
    </author>
    <date month="08" 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</keyword>
    <keyword>Decapsulation</keyword>
    <keyword>Protocol</keyword>
    <keyword>ECN</keyword>
    <keyword>Layering</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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
      from lower-layer protocols into IP. 
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). Specifications that follow these guidelines, whether produced by the
IETF or other standards bodies,  should assure interworking among IP-layer
and lower-layer congestion notification mechanisms.
This document is included in BCP 89 and updates the
single paragraph of advice to subnetwork designers about Explicit Congestion
Notification (ECN) in Section 13 of RFC 3819 by replacing it with a reference
to this document.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9599" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-3819">Update to RFC 3819</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scope">Scope</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-modes-of-operation">Modes of Operation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feed-forward-and-up-mode">Feed-Forward-and-Up Mode</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feed-up-and-forward-mode">Feed-Up-and-Forward Mode</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feed-backward-mode">Feed-Backward Mode</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-null-mode">Null Mode</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feed-forward-and-up-mode-gu">Feed-Forward-and-Up Mode: Guidelines for Adding Congestion Notification</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-in-ip-tunnels-with-shim-">IP-in-IP Tunnels with Shim Headers</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wire-protocol-design-indica">Wire Protocol Design: Indication of ECN Support</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encapsulation-guidelines">Encapsulation Guidelines</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-decapsulation-guidelines">Decapsulation Guidelines</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sequences-of-similar-tunnel">Sequences of Similar Tunnels or Subnets</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reframing-and-congestion-ma">Reframing and Congestion Markings</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feed-up-and-forward-mode-gu">Feed-Up-and-Forward Mode: Guidelines for Adding Congestion Notification</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feed-backward-mode-guidelin">Feed-Backward Mode: Guidelines for Adding Congestion Notification</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conclusions">Conclusions</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="ecnencap_Introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">In certain networks, it might be possible for traffic to congest non-IP-aware nodes.
      In such networks, the benefits of Explicit Congestion Notification (ECN) described in
      <xref target="RFC8087" format="default" sectionFormat="of" derivedContent="RFC8087"/> and summarized below can only be fully realized
      if support for congestion notification is added to the relevant subnetwork technology, as
      well as to IP. When a lower-layer buffer implicitly notifies congestion by dropping a packet, 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 buffer explicitly notifies congestion
      by marking a frame header, 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 a lower-layer header that contains
      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 indent="0" pn="section-1-2">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 that signal will
      propagate consistently into encapsulated (higher-layer) headers.
      Otherwise, the signals will not reach their ultimate destination.</t>
      <t indent="0" pn="section-1-3">ECN is defined in the IP header (IPv4 and IPv6) <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>
      to allow a resource to notify the onset of queue buildup without having
      to drop packets by explicitly marking a proportion of packets with the
      congestion experienced (CE) codepoint.
      </t>
      <t indent="0" pn="section-1-4">Given a suitable marking scheme, ECN removes nearly all congestion
      loss and it cuts delays for two main reasons: </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-5">
        <li pn="section-1-5.1">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" sectionFormat="of" derivedContent="RFC2884"/>.</li>
        <li pn="section-1-5.2">As ECN is used more widely by 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 indent="0" pn="section-1-6">Some lower-layer technologies (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,
      until recently, this was more due to the inability of TCP to saturate the
      links. For many years, fixes such as window scaling <xref target="RFC7323" format="default" sectionFormat="of" derivedContent="RFC7323"/> proved hard to deploy and the Reno variant of TCP
      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 indent="0" pn="section-1-7">Propagation of ECN is defined for MPLS <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/> and TRILL <xref target="RFC7780" format="default" sectionFormat="of" derivedContent="RFC7780"/> <xref target="RFC9600" format="default" sectionFormat="of" derivedContent="RFC9600"/>, but it has yet to be defined for
      a number of other subnetwork technologies.</t>
      <t indent="0" pn="section-1-8">Similarly, ECN propagation is yet to be defined for many tunnelling
      protocols. <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> defines how ECN
      should be propagated for IP-in-IPv4 <xref target="RFC2003" format="default" sectionFormat="of" derivedContent="RFC2003"/>, IP-in-IPv6 <xref target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"/>, and IPsec <xref target="RFC4301" format="default" sectionFormat="of" derivedContent="RFC4301"/>
      tunnels, but there are numerous other tunnelling protocols with a shim
      and/or a Layer 2 (L2) header between two IP headers (IPv4 or IPv6). Some
      address ECN propagation between the IP headers, but many do not. This
      document gives guidance on how to address ECN propagation for future
      tunnelling protocols, and a companion Standards Track specification
      <xref target="RFC9601" format="default" sectionFormat="of" derivedContent="RFC9601"/> updates existing tunnelling
      protocols with a shim between IP headers that are under IETF change
      control and still widely used.</t>
      <t indent="0" pn="section-1-9">Incremental deployment is the most delicate aspect when adding
      support for ECN. The original ECN protocol in IP <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> 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 
      transport endpoints support ECN; correct operation also depends on the
      decapsulator at each subnet or tunnel egress faithfully propagating
      congestion notification to the higher layer. 
Otherwise, a legacy decapsulator might silently fail to propagate any congestion
signals from the outer header to the forwarded header. Then, the lost signals would
never be detected and congestion would build up further. The guidelines given
later require protocol designers to carefully consider incremental deployment
and suggest various safe approaches for different circumstances.</t>
      <t indent="0" pn="section-1-10">Of
course, the IETF does not have standards authority over every link-layer
protocol; thus, this document gives guidelines for designing propagation of
congestion notification across the interface between IP and protocols that may
encapsulate IP (i.e., that can be layered beneath IP). Each lower-layer
technology will exhibit different issues and compromises, so the IETF or the
relevant standards body must be free to define the specifics of each lower-layer congestion notification scheme.  Nonetheless, if the guidelines are
followed, congestion notification should interwork between different
technologies using IP in its role as a 'portability layer'.</t>
      <t indent="0" pn="section-1-11">Therefore, the capitalized terms '<bcp14>SHOULD</bcp14>' or '<bcp14>SHOULD NOT</bcp14>' are often
      used in preference to '<bcp14>MUST</bcp14>' or '<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 '<bcp14>SHOULD</bcp14>' or '<bcp14>SHOULD NOT</bcp14>'
      given in the advice below, it <bcp14>MUST</bcp14> include a sound justification.</t>
      <t indent="0" pn="section-1-12">It has not been possible to give common guidelines for all
      lower-layer technologies because they do not all fit a common pattern.
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" sectionFormat="of" derivedContent="Section 3"/>, and separate guidelines are
      given for each mode in subsequent sections.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-update-to-rfc-3819">Update to RFC 3819</name>
        <t indent="0" pn="section-1.1-1">This document updates the brief advice to subnetwork designers
        about ECN in <xref section="13" target="RFC3819" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc3819#section-13" derivedContent="RFC3819"/> by adding this document (RFC 9599) as an informative reference and replacing the
        last two paragraphs with the following sentence:</t>
        <blockquote pn="section-1.1-2">
            By following the guidelines in [RFC9599], subnetwork
            designers can enable a layer-2 protocol to participate in
            congestion control without dropping packets via propagation of
            Explicit Congestion Notification (ECN) <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> to
            receivers.</blockquote>
      </section>
      <section anchor="ecnencap_Scope" numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-scope">Scope</name>
        <t indent="0" pn="section-1.2-1">This document only concerns wire protocol processing of explicit
        notification of congestion. It makes no changes or recommendations
        concerning algorithms for congestion marking or congestion
        response because algorithm issues should be independent of the layer
        that the algorithm operates in.</t>
        <t indent="0" pn="section-1.2-2">The default ECN semantics are described in <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>
        and updated by <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/>. Also, the guidelines for AQM
        designers <xref target="RFC7567" format="default" sectionFormat="of" derivedContent="RFC7567"/> clarify the semantics of both drop
        and ECN signals from AQM algorithms. <xref target="RFC4774" format="default" sectionFormat="of" derivedContent="RFC4774"/> 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" bare="false" empty="false" indent="3" pn="section-1.2-3">
          <li pn="section-1.2-3.1">
            <xref target="RFC4774" format="default" sectionFormat="of" derivedContent="RFC4774"/> suggests using the ECN field in combination with a
            Diffserv codepoint, such as in Pre-Congestion Notification (PCN) <xref target="RFC6660" format="default" sectionFormat="of" derivedContent="RFC6660"/>, Voice
            over 3G <xref target="UTRAN" format="default" sectionFormat="of" derivedContent="UTRAN"/>, or Voice over LTE (VoLTE) <xref target="LTE-RA" format="default" sectionFormat="of" derivedContent="LTE-RA"/>.</li>
          <li pn="section-1.2-3.2">
            <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/> suggests using the ECT(1) codepoint of the ECN field
            to indicate alternative semantics, such as for the experimental Low
            Latency, Low Loss, and Scalable throughput (L4S) service <xref target="RFC9331" format="default" sectionFormat="of" derivedContent="RFC9331"/>.</li>
        </ul>
        <t indent="0" pn="section-1.2-4">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" sectionFormat="of" derivedContent="RFC6040"/> updates <xref target="RFC4774" format="default" sectionFormat="of" derivedContent="RFC4774"/> to allow
        alternative encapsulation and decapsulation behaviours to be defined
        for alternative ECN semantics. However, it reinforces the same point --
        it is far preferable to try to fit within the common ECN
        encapsulation and decapsulation behaviours because expecting all
        lower-layer technologies and tunnels to be updated is likely to be
        completely impractical.</t>
        <t indent="0" pn="section-1.2-5">Alternative semantics for the ECN field can be defined to depend on
        the traffic class indicated by the 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) and the
        outer DSCP is stripped on descapsulation, as in the pipe model of
        <xref target="RFC2983" format="default" sectionFormat="of" derivedContent="RFC2983"/>, 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 is assumed while the meaning of 'correct' and how it is
        achieved is covered elsewhere (e.g., <xref target="RFC2983" format="default" sectionFormat="of" derivedContent="RFC2983"/>) and is outside the scope
        of this document.</t>
        <t indent="0" pn="section-1.2-6">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" sectionFormat="of" derivedContent="RFC9331"/>) and where ECN-marking algorithms
        use ECT(1) to encode three severity levels into the ECN field (e.g., PCN
        <xref target="RFC6660" format="default" sectionFormat="of" derivedContent="RFC6660"/>) rather than the default of 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 <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>.</t>
        <t indent="0" pn="section-1.2-7">Note that the guidelines in this document do not necessarily
        require the subnet wire protocol to be changed to add support for
        congestion notification. For instance, the feed-up-and-forward mode
        (<xref target="ecnencap_Up" format="default" sectionFormat="of" derivedContent="Section 3.2"/>) and the null mode (<xref target="ecnencap_Null" format="default" sectionFormat="of" derivedContent="Section 3.4"/>) do not. Another way to add congestion
        notification without consuming header space in the subnet protocol
        might be to use a parallel control plane protocol.</t>
        <t indent="0" pn="section-1.2-8">This document focuses on the congestion notification interface
        between IP and lower-layer or tunnel protocols that can encapsulate
        IP, where the term 'IP' includes IPv4 or IPv6, unicast, multicast, or
        anycast. 
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" sectionFormat="of" derivedContent="IEEE802.1Q"/>; previously 802.1ah),
        or when it encapsulates other protocols. In the feed-backward mode,
        propagation of congestion signals for multicast and anycast packets is
        out of scope (because the complexity would make it unlikely to be
        attempted).</t>
      </section>
    </section>
    <section anchor="ecnencap_Reqs_Language" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">The key words "<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
      "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
      BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
      appear in all capitals, as shown here.</t>
      <t indent="0" pn="section-2-2">Further terminology used within this document:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-3">
        <dt pn="section-2-3.1">Protocol data unit (PDU):</dt>
        <dd pn="section-2-3.2">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 includes Layer 2 and Layer 3 networks, where the PDU is
          respectively termed a frame or a packet (or a cell in ATM). PDU is a
          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 pn="section-2-3.3">Transport:</dt>
        <dd pn="section-2-3.4">The end-to-end transmission control function, conventionally
        considered at layer 4 in the OSI reference model. Given the audience
        for this document will often use the word transport to mean low-level
        bit carriage, the term will be qualified whenever it is used,
        e.g., 'L4 transport'.</dd>
        <dt pn="section-2-3.5">Encapsulator:</dt>
        <dd pn="section-2-3.6">The link or tunnel endpoint function
          that adds an outer header to a PDU (also termed the 'link ingress',
          the 'subnet ingress', the 'ingress tunnel endpoint', or just the
          'ingress' where the context is clear).</dd>
        <dt pn="section-2-3.7">Decapsulator:</dt>
        <dd pn="section-2-3.8">The link or tunnel endpoint function
          that removes an outer header from a PDU (also termed the 'link
          egress', the 'subnet egress', the 'egress tunnel endpoint', or just
          the 'egress' where the context is clear).</dd>
        <dt pn="section-2-3.9">Incoming header:</dt>
        <dd pn="section-2-3.10">The header of an arriving PDU before
          encapsulation.</dd>
        <dt pn="section-2-3.11">Outer header:</dt>
        <dd pn="section-2-3.12">The header added to encapsulate a
          PDU.</dd>
        <dt pn="section-2-3.13">Inner header:</dt>
        <dd pn="section-2-3.14">The header encapsulated by the outer
          header.</dd>
        <dt pn="section-2-3.15">Outgoing header:</dt>
        <dd pn="section-2-3.16">The header forwarded by the
          decapsulator.</dd>
        <dt pn="section-2-3.17">CE:</dt>
        <dd pn="section-2-3.18">Congestion Experienced <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/></dd>
        <dt pn="section-2-3.19">ECT:</dt>
        <dd pn="section-2-3.20">ECN-Capable (L4) Transport <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/></dd>
        <dt pn="section-2-3.21">Not-ECT:</dt>
        <dd pn="section-2-3.22">Not ECN-Capable (L4) Transport <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/></dd>
        <dt pn="section-2-3.23">Load Regulator:</dt>
        <dd pn="section-2-3.24">For each flow of PDUs, the transport function that is capable of
        controlling the data rate. Typically located at the data source, but
        in-path nodes can regulate load in some congestion control
        arrangements (e.g., admission control, policing nodes, or transport
        circuit-breakers <xref target="RFC8084" format="default" sectionFormat="of" derivedContent="RFC8084"/>). Note that
        "a function capable of controlling the load" deliberately
        includes a transport that does not actually control the load
        responsively, but ideally it ought to (e.g., a sending application
        without congestion control that uses UDP).</dd>
        <dt pn="section-2-3.25">ECN-PDU:</dt>
        <dd pn="section-2-3.26">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 pn="section-2-3.27">Not-ECN-PDU:</dt>
        <dd pn="section-2-3.28">A PDU at the IP layer or below that is
          part of a congestion control feedback loop that is not capable of
          propagating ECN signals back to the Load
          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 the feedback loop, not necessarily of the
          PDU itself; certainly the PDU will self-describe the
          property in some protocols, but in others, the property might be carried in a separate
          control plane context (which is somehow bound to the PDU).</dd>
      </dl>
    </section>
    <section anchor="ecnencap_Modes" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-modes-of-operation">Modes of Operation</name>
      <t indent="0" pn="section-3-1">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 subsequent sections that give
      normative guidelines for designers of congestion notification protocols, taking each mode in
      turn:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1">Feed-Forward-and-Up:</dt>
        <dd pn="section-3-2.2">
          <t indent="0" pn="section-3-2.2.1">Nodes feed forward congestion
          notification towards the egress within the lower layer, then up and
          along the layers towards the end-to-end destination at the transport
          layer. The following local optimization is possible:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-3-2.2.2">
            <dt pn="section-3-2.2.2.1">Feed-Up-and-Forward:</dt>
            <dd pn="section-3-2.2.2.2">A lower-layer switch feeds up
              congestion notification directly into the higher layer (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 pn="section-3-2.3">Feed-Backward:</dt>
        <dd pn="section-3-2.4">Nodes feed back congestion signals
          towards the ingress of the lower layer and (optionally) attempt to
          control congestion within their own layer.</dd>
        <dt pn="section-3-2.5">Null:</dt>
        <dd pn="section-3-2.6">Nodes cannot experience congestion at the lower
          layer except at the ingress nodes of the subnet (which are IP-aware or equivalently
          higher-layer-aware).</dd>
      </dl>
      <section anchor="ecnencap_Forward" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-feed-forward-and-up-mode">Feed-Forward-and-Up Mode</name>
        <t indent="0" pn="section-3.1-1">Like IP and MPLS, many subnet technologies are based on
        self-contained PDUs or frames sent unreliably.
        They provide no feedback channel at the subnetwork layer, instead
        relying on higher layers (e.g., TCP) to feed back loss signals.</t>
        <t indent="0" pn="section-3.1-2">In these cases, ECN may best be supported by standardising explicit
        notification of congestion into the lower-layer protocol that carries
        the data forwards. Then, a specification is needed for how the egress
        of the lower-layer subnet propagates this explicit signal into the
        forwarded upper-layer (IP) header. This signal continues forwards
        until it finally reaches the destination transport (at L4). 
        Typically, the destination will feed this congestion notification back
        to the source transport using an end-to-end protocol (e.g., TCP). This
        is the arrangement that has already been used to add ECN to IP-in-IP
        tunnels <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>, IP-in-MPLS, and MPLS-in-MPLS <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/>.</t>
        <t indent="0" pn="section-3.1-3">This mode is illustrated in <xref target="ecnencap_Fig_Feed-Forward-and-Up" format="default" sectionFormat="of" derivedContent="Figure 1"/>. Along the middle of the
        figure, layers 2, 3, and 4 of the protocol stack are shown. One
        packet is shown along the bottom as it progresses across the network
        from source to destination, crossing two subnets connected by a
        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 L2 header. 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 congestion notification, but the signal proceeds across it in
        the L3 header.</t>
        <t indent="0" pn="section-3.1-4">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 indent="0" pn="section-3.1-5">Finally, for completeness, we show the L3 marking arriving at the
        destination, where the host transport protocol (e.g., TCP) feeds it
        back to the source in the L4 acknowledgement (the 'C' at L4 in the
        packet at the top of the diagram).</t>
        <figure anchor="ecnencap_Fig_Feed-Forward-and-Up" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-feed-forward-and-up-mode-2">Feed-Forward-and-Up Mode</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.1-6.1">
                    _ _ _ 
         /_______  | | |C|  ACK Packet (V)
         \         |_|_|_|
+---+        layer: 2 3 4 header                            +---+
|  &lt;|&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; Packet V &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;|&lt;&lt; |L4
|   |                         +---+                         | ^ |
|   | . . . . . . Packet U. . | &gt;&gt;|&gt;&gt;&gt; Packet U &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;|&gt;^ |L3
|   |     +---+     +---+     | ^ |     +---+     +---+     |   |
|   |     |  *|&gt;&gt;&gt;&gt;&gt;|&gt;&gt;&gt;|&gt;&gt;&gt;&gt;&gt;|&gt;^ |     |   |     |   |     |   |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 2B
header
</artwork>
        </figure>
        <t indent="0" pn="section-3.1-7">Of course, modern networks are rarely as simple as this textbook
        example, often involving multiple nested layers. For example, a Third
        Generation Partnership Project (3GPP) mobile network may have two
        IP-in-IP GTP <xref target="GTPv1" format="default" sectionFormat="of" derivedContent="GTPv1"/> tunnels in
        series and an MPLS backhaul between the base station and the first
        router. Nonetheless, the example illustrates the general idea of
        feeding congestion notification forward then upward whenever a header
        is removed at the egress of a subnet.</t>
        <t indent="0" pn="section-3.1-8">Note that the Forward Explicit Congestion Notification (FECN) bit in Frame Relay <xref target="Buck00" format="default" sectionFormat="of" derivedContent="Buck00"/> and the Explicit Forward Congestion Indication (EFCI)
        <xref target="ITU-T.I.371" format="default" sectionFormat="of" derivedContent="ITU-T.I.371"/> bit in ATM user data cells follow a
        feed-forward pattern. 
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.
To our knowledge,
        Frame Relay FECN is solely used by network operators to detect where they 
        should provision more capacity.</t>
      </section>
      <section anchor="ecnencap_Up" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-feed-up-and-forward-mode">Feed-Up-and-Forward Mode</name>
        <t indent="0" pn="section-3.2-1">Ethernet is particularly difficult to extend incrementally to
        support congestion notification. One way is to use so-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" sectionFormat="of" derivedContent="RFC8257"/>, Layer 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, a Layer 3 switch acts solely on the addresses in
        the Ethernet header; it does not use IP addresses and it does not
        decrement the TTL field in the IP header.</t>
        <figure anchor="ecnencap_Fig_Feed-Up" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-feed-up-and-forward-mode-2">Feed-Up-and-Forward Mode</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.2-2.1">
                    _ _ _ 
         /_______  | | |C|  ACK packet (V)
         \         |_|_|_|
+---+        layer: 2 3 4 header                            +---+
|  &lt;|&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; Packet V &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;|&lt;&lt; |L4
|   |                         +---+                         | ^ |
|   | . . .  &gt;&gt;&gt;&gt; Packet U &gt;&gt;&gt;|&gt;&gt;&gt;|&gt;&gt;&gt; Packet U &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;|&gt;^ |L3
|   |     +--^+     +---+     |  v|     +---+     +---+     | ^ |
|   |     |  *|     |   |     |  &gt;|&gt;&gt;&gt;&gt;&gt;|&gt;&gt;&gt;|&gt;&gt;&gt;&gt;&gt;|&gt;&gt;&gt;|&gt;&gt;&gt;&gt;&gt;|&gt;^ |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 2
header
</artwork>
        </figure>
        <t indent="0" pn="section-3.2-3">By comparing <xref target="ecnencap_Fig_Feed-Up" format="default" sectionFormat="of" derivedContent="Figure 2"/>
        with <xref target="ecnencap_Fig_Feed-Forward-and-Up" format="default" sectionFormat="of" derivedContent="Figure 1"/>, it can be seen that subnet E (perhaps a subnet of
        Layer 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. 
In this example, the technology in subnet F (e.g., MPLS) does support ECN.
   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="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-feed-backward-mode">Feed-Backward Mode</name>
        <t indent="0" pn="section-3.3-1">In some Layer 2 technologies, congestion notification has
        been defined for use internally within the subnet with its own
        feedback and load regulation but the interface with IP for
        ECN has not been defined.</t>
        <t indent="0" pn="section-3.3-2">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. In this approach, 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 is congested, it sends an RM cell
back towards the ingress with respectively the No Increase (NI) or Congestion
Indication (CI) bit set in its message type field <xref target="ATM-TM-ABR" format="default" sectionFormat="of" derivedContent="ATM-TM-ABR"/>.  The ingress then holds or decreases its sending bit rate
accordingly.</t>
        <figure anchor="ecnencap_Fig_Feed-Backward" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-feed-backward-mode-2">Feed-Backward Mode</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.3-3.1">
                     _ _ _ 
          /_______  | | |C|  ACK packet (X)
          \         |_|_|_|
 +---+        layer: 2 3 4 header                            +---+
 |  &lt;|&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; Packet X &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;|&lt;&lt; |L4
 |   |                         +---+                         | ^ |
 |   |                         |  *|&gt;&gt;&gt; Packet W &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;|&gt;^ |L3
 |   |     +---+     +---+     |   |     +---+     +---+     |   |
 |   |     |   |     |   |     |  &lt;|&lt;&lt;&lt;&lt;&lt;|&lt;&lt;&lt;|&lt;(V)&lt;|&lt;&lt;&lt;|     |   |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 indent="0" pn="section-3.3-4">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.
          <xref target="ecnencap_Fig_Feed-Backward" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows the feed-backward approach
        being used in subnet H. 
If the final switch on the path is congested
        (*), it does not feed forward any congestion indications on the packet
        (U). Instead, it sends a control cell (V) back to the router at the ATM
        ingress.</t>
        <t indent="0" pn="section-3.3-5">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 sending rate, 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., 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 indent="0" pn="section-3.3-6">In response to this later forward signalling, end-to-end feedback
        at layer 4 finally completes the tortuous path of congestion
        indications back to the origin data source as before.</t>
        <t indent="0" pn="section-3.3-7">Quantized Congestion Notification (QCN) <xref target="IEEE802.1Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>
        would suffer from similar problems if extended to multiple subnets.
        However, QCN was clearly characterized as solely
        applicable to a single subnet from the start (see <xref target="ecnencap_Guidelines_Backward" format="default" sectionFormat="of" derivedContent="Section 6"/>).</t>
      </section>
      <section anchor="ecnencap_Null" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-null-mode">Null Mode</name>
        <t indent="0" pn="section-3.4-1">Link- and physical-layer resources are often 'non-blocking' by
        design. Congestion notification 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 indent="0" pn="section-3.4-2">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., a non-blocking fat-tree network <xref target="Leiserson85" format="default" sectionFormat="of" derivedContent="Leiserson85"/>. 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., a Clos network <xref target="Clos53" format="default" sectionFormat="of" derivedContent="Clos53"/>.</t>
      </section>
    </section>
    <section anchor="ecnencap_Guidelines_Forward" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-feed-forward-and-up-mode-gu">Feed-Forward-and-Up Mode: Guidelines for Adding Congestion Notification</name>
      <t indent="0" pn="section-4-1">Feed-forward-and-up is the mode already used for signalling ECN up
      the layers through MPLS into IP <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/> and through
      IP-in-IP tunnels <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>, whether encapsulating with
      IPv4 <xref target="RFC2003" format="default" sectionFormat="of" derivedContent="RFC2003"/>, IPv6 <xref target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"/>, or IPsec
      <xref target="RFC4301" format="default" sectionFormat="of" derivedContent="RFC4301"/>. 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" sectionFormat="of" derivedContent="RFC4774"/> and extended by <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/>.</t>
      <t indent="0" pn="section-4-2">The rest of this section is structured as follows:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3">
        <li pn="section-4-3.1">
          <xref target="ecnencap_IP-IP_Coupled_Shim_Tunnels" format="default" sectionFormat="of" derivedContent="Section 4.1"/> addresses
          the most straightforward cases, where <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> 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 pn="section-4-3.2">
          <t indent="0" pn="section-4-3.2.1">The subsequent sections give guidelines for adding congestion notification 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" sectionFormat="of" derivedContent="RFC6040"/> rules can be
          applied directly. Specifically:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3.2.2">
            <li pn="section-4-3.2.2.1">Sections <xref format="counter" target="ecnencap_WireProtocolECNSupport" sectionFormat="of" derivedContent="4.2"/>, <xref format="counter" target="ecnencap_EncapGuidelines" sectionFormat="of" derivedContent="4.3"/>, and <xref format="counter" target="ecnencap_DecapGuidelines" sectionFormat="of" derivedContent="4.4"/> address how to add ECN support
            to the wire protocol and to the encapsulators and decapsulators at
            the ingress and egress of the subnet, respectively.</li>
            <li pn="section-4-3.2.2.2">
              <xref target="ecnencap_Sequences" format="default" sectionFormat="of" derivedContent="Section 4.5"/> deals with the special
              but common case of sequences of tunnels or subnets that all use
              the same technology.</li>
            <li pn="section-4-3.2.2.3">
              <xref target="ecnencap_Reframing" format="default" sectionFormat="of" derivedContent="Section 4.6"/> deals with the question
              of reframing when IP packets do not map 1:1 into lower-layer
              frames.</li>
          </ul>
        </li>
      </ul>
      <section anchor="ecnencap_IP-IP_Coupled_Shim_Tunnels" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-ip-in-ip-tunnels-with-shim-">IP-in-IP Tunnels with Shim Headers</name>
        <t indent="0" pn="section-4.1-1">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
        encapsulate an L2 header, which in turn encapsulates (or
        might encapsulate) an IP header. <xref target="RFC9601" format="default" sectionFormat="of" derivedContent="RFC9601"/> clarifies that <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>
        is just as applicable when there are shims and even an L2 header
        between two IP headers.</t>
        <t indent="0" pn="section-4.1-2">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" sectionFormat="of" derivedContent="Section 3.4"/> 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="RFC9601" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9601#section-4" derivedContent="RFC9601"/> 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 indent="0" pn="section-4.1-3">Nonetheless, in many cases it is feasible to propagate the ECN
        field between IP headers separated by shim headers and/or an L2
        header. Particularly in the typical case when the outer IP header and
        the shim(s) are added (or removed) as part of the same procedure. Even
        if a shim encapsulates 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" sectionFormat="of" derivedContent="Section 3.2"/>), so the
        guidelines for this mode apply (<xref target="ecnencap_Guidelines_Up" format="default" sectionFormat="of" derivedContent="Section 5"/>).</t>
        <t indent="0" pn="section-4.1-4">Numerous shim protocols have been defined for IP tunnelling. More
        recent ones, e.g., Geneve <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/> and Generic UDP
        Encapsulation (GUE) <xref target="I-D.ietf-intarea-gue" format="default" sectionFormat="of" derivedContent="INTAREA-GUE"/> cite and
        follow <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>. Some earlier ones, e.g., CAPWAP <xref target="RFC5415" format="default" sectionFormat="of" derivedContent="RFC5415"/> and LISP <xref target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/>, cite <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>,
        which is compatible with <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>.</t>
        <t indent="0" pn="section-4.1-5">However, as <xref section="9.3" target="RFC3168" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc3168#section-9.3" derivedContent="RFC3168"/> pointed out, ECN
        support needs to be defined for many earlier shim-based tunnelling
        protocols, e.g., L2TPv2 <xref target="RFC2661" format="default" sectionFormat="of" derivedContent="RFC2661"/>, L2TPv3 <xref target="RFC3931" format="default" sectionFormat="of" derivedContent="RFC3931"/>, GRE <xref target="RFC2784" format="default" sectionFormat="of" derivedContent="RFC2784"/>, PPTP <xref target="RFC2637" format="default" sectionFormat="of" derivedContent="RFC2637"/>, GTP <xref target="GTPv1" format="default" sectionFormat="of" derivedContent="GTPv1"/> <xref target="GTPv1-U" format="default" sectionFormat="of" derivedContent="GTPv1-U"/> <xref target="GTPv2-C" format="default" sectionFormat="of" derivedContent="GTPv2-C"/>, and Teredo <xref target="RFC4380" format="default" sectionFormat="of" derivedContent="RFC4380"/>, as well as some recent ones, e.g., VXLAN <xref target="RFC7348" format="default" sectionFormat="of" derivedContent="RFC7348"/>, NVGRE <xref target="RFC7637" format="default" sectionFormat="of" derivedContent="RFC7637"/>, and NSH <xref target="RFC8300" format="default" sectionFormat="of" derivedContent="RFC8300"/>.</t>
        <t indent="0" pn="section-4.1-6">All these IP-based encapsulations can be updated in one shot by
        simple reference to <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>. However, it would not be appropriate to
        update all these protocols from within the present guidance document.
        Instead, a companion specification <xref target="RFC9601" format="default" sectionFormat="of" derivedContent="RFC9601"/> 
        has the appropriate Standards Track status to update Standards Track
        protocols. For those that are not under IETF change control <xref target="RFC9601" format="default" sectionFormat="of" derivedContent="RFC9601"/> can only recommend that
        the relevant body updates them.</t>
      </section>
      <section anchor="ecnencap_WireProtocolECNSupport" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-wire-protocol-design-indica">Wire Protocol Design: Indication of ECN Support</name>
        <t indent="0" pn="section-4.2-1">This section is intended to guide the redesign of any lower-layer
        protocol that encapsulates IP to add built-in congestion notification support at the lower
        layer using feed-forward-and-up mode. It reflects the approaches used in <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> and
        in <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/>. Therefore, IP-in-IP tunnels or IP-in-MPLS
        or MPLS-in-MPLS encapsulations that already comply with <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> or <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/> will already satisfy
        this guidance.</t>
        <t indent="0" pn="section-4.2-2">A lower-layer (or subnet) congestion notification system:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.2-3"><li pn="section-4.2-3.1" derivedCounter="1.">
            <bcp14>SHOULD NOT</bcp14> apply explicit congestion notifications to PDUs that
            are destined for legacy layer-4 transport implementations that
            will not understand ECN; and</li>
          <li anchor="ecnencap_Egress_Check" pn="section-4.2-3.2" derivedCounter="2.">
            <t indent="0" pn="section-4.2-3.2.1"><bcp14>SHOULD NOT</bcp14> apply explicit congestion notifications to PDUs if the egress of the subnet might
            not propagate congestion notification onward into the higher
            layer.</t>
            <t indent="0" pn="section-4.2-3.2.2">We use the term ECN-PDU for a PDU
            on a feedback loop that will propagate congestion notification
            properly because it meets both the above criteria. Additionally, a
            Not-ECN-PDU is a PDU on a feedback loop that does not meet at
            least one of the criteria, and therefore will not propagate
            congestion notification properly. A corollary of the above is that
            a lower-layer congestion notification protocol:</t>
          </li>
          <li pn="section-4.2-3.3" derivedCounter="3.">
            <bcp14>SHOULD</bcp14> be able to distinguish ECN-PDUs from Not-ECN-PDUs.</li>
        </ol>
        <t indent="0" pn="section-4.2-4">Note that there is no need for all interior nodes within a subnet
        to be able to mark congestion explicitly. A mix of drop and explicit congestion
        signals from different nodes is fine. However, if <em>any</em>
        interior nodes might generate congestion markings, Guideline <xref format="counter" target="ecnencap_Egress_Check" sectionFormat="of" derivedContent="2"/> above says that all
        relevant egress nodes <bcp14>SHOULD</bcp14> be able to propagate those markings up
        to the higher layer.</t>
        <t indent="0" pn="section-4.2-5">In IP, if the ECN field in each PDU is cleared to the 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-ECT PDUs; therefore, it has to signal congestion by
        increasingly applying drop instead.</t>
        <t indent="0" pn="section-4.2-6">The mechanism a lower layer uses to distinguish the ECN capability
        of PDUs need not mimic that of IP. The above guidelines merely say
        that the lower-layer system as a whole should achieve the same
        outcome. For instance, ECN-capable feedback loops might use PDUs that
        are identified by a particular set of labels or tags. Alternatively,
        logical-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 indent="0" pn="section-4.2-7">The per-domain checking of ECN support in MPLS <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/> is a good example of a way to avoid sending
        congestion markings to L4 transports that will not understand them
        without using any header space in the subnet protocol.</t>
        <t indent="0" pn="section-4.2-8">In MPLS, header space is extremely limited; therefore, <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="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 at 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. 

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" sectionFormat="of" derivedContent="1"/> in <xref target="ecnencap_DecapGuidelines" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).</t>
        <t indent="0" pn="section-4.2-9">It was only appropriate to define such an incremental deployment
        strategy because MPLS is targeted solely at professional 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., Ethernet). For such 'plug-and-play'
        environments, it will be necessary to invent a fail-safe approach that
        ensures congestion markings will never fall into black holes, no
        matter how inconsistently a system is put together. 

Alternatively,
        congestion notification 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 target="IEEE802.1Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>; previously 802.1ah).</t>
        <t indent="0" pn="section-4.2-10">ECN support in TRansparent Interconnection of Lots of Links (TRILL) <xref target="RFC9600" format="default" sectionFormat="of" derivedContent="RFC9600"/>
        provides a good example of how to add congestion notification to a lower-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. The congestion-experienced marking has been
        defined as a 'critical ingress-to-egress' flag. So, if a transit
        RBridge sets this flag on a frame and an egress RBridge does not have any logic
        to process it, the egress RBridge will drop the frame, which is the desired default action
        anyway. Therefore, TRILL RBridges can be updated with support for congestion notification
        in no particular order and, at the egress of the TRILL campus,
        congestion notification will be propagated to IP as ECN whenever ECN
        logic has been implemented at the egress, or as drop otherwise.</t>
        <t indent="0" pn="section-4.2-11">QCN <xref target="IEEE802.1Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/> is not intended to
        extend beyond a single subnet or interoperate with
        IP-ECN. Nonetheless, the way QCN indicates to lower-layer devices that
        the endpoints will not understand QCN provides another example that a
        lower-layer protocol designer might be able to mimic for their
        scenario. An operator can define certain Priority Code Points (PCPs
        <xref target="IEEE802.1Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>; previously 802.1p) to
        indicate non-QCN frames. Then an ingress bridge has to map each
        arriving not-QCN-capable IP packet to one of these non-QCN PCPs.</t>
        <t indent="0" pn="section-4.2-12">When drop for non-ECN traffic is deferred to the egress of a subnet,
        it cannot necessarily be assumed that one congestion mark is equivalent to one
        drop, as was originally required by <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>.
        <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/> updated <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> to allow
        experimentation with congestion markings that are not equivalent to drop,
        particularly for L4S <xref target="RFC9331" format="default" sectionFormat="of" derivedContent="RFC9331"/>. ECN
        support in TRILL <xref target="RFC9600" format="default" sectionFormat="of" derivedContent="RFC9600"/>
        is a good example of a way to defer drop to the egress of a subnet both
        when marks are equivalent to drops (as in <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>) and when they
        are not (as in L4S). The ECN scheme for MPLS <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/>
        was defined before L4S, so it only currently supports deferred drop that
        is equivalent to ECN marking. Nonetheless, in principle, MPLS
        (and potentially future L2 protocols) could support L4S marking by copying 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="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-encapsulation-guidelines">Encapsulation Guidelines</name>
        <t indent="0" pn="section-4.3-1">This section is intended to guide the redesign of any node that
        encapsulates IP with a lower-layer header when adding built-in congestion notification
        support to the lower-layer protocol using feed-forward-and-up mode. It reflects the approaches used
        in <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> and <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/>. Therefore,
        IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS encapsulations that
        already comply with <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> or <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/> will already satisfy this guidance.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.3-2"><li pn="section-4.3-2.1" derivedCounter="1.">
            <t indent="0" pn="section-4.3-2.1.1">Egress Capability Check: A subnet ingress needs to be sure that
            the corresponding egress of a subnet will propagate any congestion
            notification 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" bare="false" empty="false" indent="3" pn="section-4.3-2.1.2">
              <li pn="section-4.3-2.1.2.1">by configuration (e.g., if any label switch in a domain
                supports congestion marking, <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/> requires all
                egress nodes to have been configured to propagate ECN).</li>
              <li pn="section-4.3-2.1.2.2">by the ingress explicitly checking that the egress
                propagates ECN (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" sectionFormat="of" derivedContent="RFC7780"/>).</li>
              <li pn="section-4.3-2.1.2.3">by inherent design of the protocol (e.g., by encoding congestion
                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 discard it; thus, at least propagating a form of
                congestion signal).</li>
            </ul>
          </li>
          <li pn="section-4.3-2.2" derivedCounter="2.">Egress Fails Capability Check: If the ingress cannot guarantee
            that the egress will propagate congestion notification, the
            ingress <bcp14>SHOULD</bcp14> disable congestion notification at the lower layer when it forwards the
            PDU. An example of how the ingress might disable congestion notification 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" pn="section-4.3-2.3" derivedCounter="3.">
            <t indent="0" pn="section-4.3-2.3.1">Standard Congestion Monitoring
            Baseline: Once the ingress to a subnet has established that the
            egress will correctly propagate ECN, on encapsulation, it <bcp14>SHOULD</bcp14>
            encode the same level of congestion in outer headers as is
            arriving in incoming headers. For example, it might copy any
            incoming congestion notifications into the outer header of the
            lower-layer protocol.</t>
            <t indent="0" pn="section-4.3-2.3.2">This ensures that
            bulk congestion monitoring of outer headers (e.g., by a network
            management node monitoring congestion markings in passing frames) will measure
            congestion accumulated along the whole upstream path, starting from the
            Load Regulator and not just starting from the ingress of the subnet. 
A node
            that is not the Load Regulator <bcp14>SHOULD NOT</bcp14> re-initialize the level
            of CE markings in the outer header to zero. </t>
            <t indent="0" pn="section-4.3-2.3.3">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 (see <xref target="RFC6040" sectionFormat="of" section="C" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6040#appendix-C" derivedContent="RFC6040"/>). For example:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-2.3.4">
              <li pn="section-4.3-2.3.4.1">If this guideline has been followed and if the level of CE
                markings is 0.4% on the outer header and 0.1% on the inner header, 0.4%
                congestion has been introduced across all the networks since
                the Load Regulator, and 0.3% (= 0.4% - 0.1%) has been
                introduced since the ingress to the current subnet (or
                tunnel).</li>
              <li pn="section-4.3-2.3.4.2">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%), but only if the
                monitoring system somehow knows whether the subnet ingress
                re-initialized the congestion level.</li>
            </ul>
            <t indent="0" pn="section-4.3-2.3.5">As long as subnet and tunnel technologies use the
            standard congestion monitoring baseline in this guideline,
            monitoring systems will know to use the former approach rather
            than having to 'somehow know' which approach to use.
            </t>
          </li>
        </ol>
      </section>
      <section anchor="ecnencap_DecapGuidelines" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-decapsulation-guidelines">Decapsulation Guidelines</name>
        <t indent="0" pn="section-4.4-1">This section is intended to guide the redesign of any node that
        decapsulates IP from within a lower-layer header when adding built-in
        congestion notification support to the lower-layer protocol using feed-forward-and-up mode. It reflects the approaches
        used in <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> and in <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/>.
        Therefore, IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS
        encapsulations that already comply with <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> or
        <xref target="RFC5129" format="default" sectionFormat="of" derivedContent="RFC5129"/> will already satisfy this guidance.</t>
        <t indent="0" pn="section-4.4-2">A subnet egress <bcp14>SHOULD NOT</bcp14> simply copy congestion notifications from
        outer headers to the forwarded header. It <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 the
        list.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.4-3"><li anchor="ecnencap_dropNot-ECTinnerCEouter" pn="section-4.4-3.1" derivedCounter="1.">
            <t indent="0" pn="section-4.4-3.1.1">If the arriving inner
            header is a Not-ECN-PDU, it implies the L4 transport will not
            understand explicit congestion markings. Then:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4-3.1.2">
              <li pn="section-4.4-3.1.2.1">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 outer congestion marking is the
                most severe possible, the packet <bcp14>MUST</bcp14> be dropped. 

However, if congestion can be marked with multiple levels of severity and the
packet's outer marking is not the most severe, this requirement can be relaxed to:
the packet <bcp14>SHOULD</bcp14> be dropped.</li>
              <li pn="section-4.4-3.1.2.2">If the outer is an ECN-PDU that carries no indication of
                congestion or a Not-ECN-PDU the PDU <bcp14>SHOULD</bcp14> be forwarded, but
                still as a Not-ECN-PDU.</li>
            </ul>
          </li>
          <li pn="section-4.4-3.2" derivedCounter="2.">If the outer header does not support congestion notification (a Not-ECN-PDU), but the inner header does (an
            ECN-PDU), the inner header <bcp14>SHOULD</bcp14> be forwarded unchanged.</li>
          <li pn="section-4.4-3.3" derivedCounter="3.">In some lower-layer protocols, congestion may be signalled as a
            numerical level, such as in the control frames of QCN <xref target="IEEE802.1Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>. 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 pn="section-4.4-3.4" derivedCounter="4.">
            <t indent="0" pn="section-4.4-3.4.1">Congestion indications might be encoded by a severity level.
            For instance, increasing levels of congestion might be encoded by
            numerically increasing indications, e.g., PCN can be encoded in each PDU at three severity
            levels in IP or MPLS <xref target="RFC6660" format="default" sectionFormat="of" derivedContent="RFC6660"/> and the default
            encapsulation and decapsulation rules <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> are
            compatible with this interpretation of the ECN field. </t>
            <t indent="0" pn="section-4.4-3.4.2">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 indication <bcp14>SHOULD</bcp14> be forwarded
            in preference to the less severe.</t>
          </li>
          <li pn="section-4.4-3.5" derivedCounter="5.">
            <t indent="0" pn="section-4.4-3.5.1">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" sectionFormat="of" derivedContent="3"/> in <xref target="ecnencap_EncapGuidelines" format="default" sectionFormat="of" derivedContent="Section 4.3"/> had been followed, it should
            not be possible to have a less severe indication of congestion in
            the outer header than in the inner header. It <bcp14>MAY</bcp14> be appropriate to log
            unexpected combinations of headers and possibly raise an alarm.
            </t>
            <t indent="0" pn="section-4.4-3.5.2">If a safe outgoing codepoint can be
            defined for such a PDU, the PDU <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-coded drop so that operators can keep track of
            possible attacks, 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="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-sequences-of-similar-tunnel">Sequences of Similar Tunnels or Subnets</name>
        <t indent="0" pn="section-4.5-1">In some deployments, particularly in 3GPP networks, an IP packet
        may traverse two or more IP-in-IP tunnels in sequence that all use
        identical technology (e.g., GTP).</t>
        <t indent="0" pn="section-4.5-2">In such cases, it would be sufficient for every encapsulation and
        decapsulation in the chain to comply with <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>. 
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 header and the incoming inner ECN field directly to the
        outgoing inner header. Then, the overall behaviour across the sequence of
        tunnel segments would still be consistent with <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>.</t>
        <t indent="0" pn="section-4.5-3"><xref target="RFC6040" sectionFormat="of" section="C" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6040#appendix-C" derivedContent="RFC6040"/> 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 in 
        <xref target="RFC6040" sectionFormat="of" section="C" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6040#appendix-C" derivedContent="RFC6040"/> at the final egress, the operator could monitor the whole
        sequence of tunnels, but only if the above optimization were used
        consistently along the sequence of tunnels, in order to make it appear
        as a single tunnel. Therefore, tunnel endpoint implementations <bcp14>SHOULD</bcp14>
        allow the operator to configure whether this optimization is
        enabled.</t>
        <t indent="0" pn="section-4.5-4">When congestion notification support is added to a subnet technology, consideration
        <bcp14>SHOULD</bcp14> be given to a similar optimization between subnets in sequence
        if they all use the same technology.</t>
      </section>
      <section anchor="ecnencap_Reframing" numbered="true" toc="include" removeInRFC="false" pn="section-4.6">
        <name slugifiedName="name-reframing-and-congestion-ma">Reframing and Congestion Markings</name>
        <t indent="0" pn="section-4.6-1">The guidance in this section is worded in terms of framing
        boundaries, but it applies equally whether the PDUs are
        frames, cells, or packets.</t>
        <t indent="0" pn="section-4.6-2">Where an AQM marks the ECN field of IP packets as they queue into a
        Layer 2 link, there will be no problem with framing boundaries
        because the ECN markings would be applied directly to IP packets. The
        guidance in this section is only applicable where a congestion notification capability is
        being added to a Layer 2 protocol so that Layer 2 frames can be
        marked by an AQM at layer 2. This would only be necessary where
        AQM will be applied at pure Layer 2 nodes (without IP awareness).</t>
        <t indent="0" pn="section-4.6-3">Where congestion 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 node <bcp14>SHOULD</bcp14> propagate congestion markings
        from Layer 2 frame headers to IP packets that may have different
        boundaries as a consequence of reframing.</t>
        <t indent="0" pn="section-4.6-4">Two possible design goals for propagating congestion indications,
        described in <xref section="5.3" target="RFC3168" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc3168#section-5.3" derivedContent="RFC3168"/>
        and <xref section="2.4" target="RFC7141" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7141#section-2.4" derivedContent="RFC7141"/>, are:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.6-5"><li anchor="ecnencap_reframing_goal_presence" pn="section-4.6-5.1" derivedCounter="1.">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" pn="section-4.6-5.2" derivedCounter="2.">
            <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-4.6-5.2.1"><li pn="section-4.6-5.2.1.1" derivedCounter="a.">
                <t indent="0" pn="section-4.6-5.2.1.1.1">at high frequency of congestion
            marking, approximate preservation of the proportion of congestion
            marks arriving and departing;</t>
              </li>
              <li pn="section-4.6-5.2.1.2" derivedCounter="b.">
                <t indent="0" pn="section-4.6-5.2.1.2.1">at low frequency of congestion
              marking, approximate preservation of the timing of congestion
              marks arriving and departing.</t>
              </li>
            </ol>
          </li>
        </ol>
        <t indent="0" pn="section-4.6-6">In either case, an implementation <bcp14>SHOULD</bcp14> ensure that
        any new incoming congestion indication is propagated immediately; not
        held awaiting the possibility of further congestion indications to be
        sufficient to indicate congestion on an outgoing PDU <xref target="RFC7141" format="default" sectionFormat="of" derivedContent="RFC7141"/>. Nonetheless, to facilitate
        pipelined implementation, it would be acceptable for congestion marks
        to propagate to a slightly later IP packet.</t>
        <t indent="0" pn="section-4.6-7">
   At decapsulation in either case:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.6-8">
          <li pn="section-4.6-8.1">ECN-marking propagation logically occurs
   before application of Decapsulation Guideline <xref format="counter" target="ecnencap_dropNot-ECTinnerCEouter" sectionFormat="of" derivedContent="1"/> in <xref target="ecnencap_DecapGuidelines" format="default" sectionFormat="of" derivedContent="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" sectionFormat="of" derivedContent="1"/>.</li>
          <li pn="section-4.6-8.2">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 pn="section-4.6-8.3">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" sectionFormat="of" derivedContent="RFC3168"/>; or ECT(1) can
            provide a less severe congestion marking
            than CE <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="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
            <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/> <xref target="RFC9331" format="default" sectionFormat="of" derivedContent="RFC9331"/>.</li>
        </ul>
        <t indent="0" pn="section-4.6-9">The following are two ways that goal <xref format="counter" target="ecnencap_reframing_goal_presence" sectionFormat="of" derivedContent="1"/> might be achieved, but
        they are not intended to be the only ways:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.6-10">
          <li pn="section-4.6-10.1">Every IP PDU that is constructed, in whole or in part, from an
            L2 frame that is marked with a congestion signal has that signal
            propagated to it.</li>
          <li pn="section-4.6-10.2">Every L2 frame that is marked with a congestion signal
            propagates that signal to one IP PDU that is constructed from it in
            whole or in part. If multiple IP PDUs meet this
            description, the choice can be made arbitrarily but ought to be
            consistent.</li>
        </ul>
        <t indent="0" pn="section-4.6-11">The following gives one way that goal <xref format="counter" target="ecnencap_reframing_goal_proportion" sectionFormat="of" derivedContent="2"/> might be achieved, but
        it is not intended to be the only way:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.6-12">
          <li pn="section-4.6-12.1">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 are 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" sectionFormat="of" derivedContent="1"/> in <xref target="ecnencap_DecapGuidelines" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).</li>
        </ul>
        <t indent="0" pn="section-4.6-13">Generally, relative to the number of IP PDUs, the number of L2 frames may be higher (e.g., ATM),
        roughly the same, or lower (e.g., 802.11 aggregation at an L2-only station).
        This distinction may influence the choice of mechanism.</t>
      </section>
    </section>
    <section anchor="ecnencap_Guidelines_Up" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-feed-up-and-forward-mode-gu">Feed-Up-and-Forward Mode: Guidelines for Adding Congestion Notification</name>
      <t indent="0" pn="section-5-1">The guidance in this section is applicable, for example, when IP
      packets:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-2">
        <li pn="section-5-2.1">are encapsulated in Ethernet headers, which have no support for
          congestion notification;</li>
        <li pn="section-5-2.2">are forwarded by the eNode-B (base station) of a 3GPP radio access
        network, which is required to apply ECN marking during congestion
        <xref target="LTE-RA" format="default" sectionFormat="of" derivedContent="LTE-RA"/> <xref target="UTRAN" format="default" sectionFormat="of" derivedContent="UTRAN"/>, but the Packet Data Convergence Protocol (PDCP)
        that encapsulates the IP header over the radio access has no support
        for ECN.</li>
      </ul>
      <t indent="0" pn="section-5-3">This guidance also generalizes to encapsulation
        by other subnet technologies with no built-in support for congestion notification 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" sectionFormat="of" derivedContent="RFC6040"/> would be more appropriate.</t>
      <t indent="0" pn="section-5-4">Marking the IP header while switching at layer 2 (by using a Layer 3
      switch) or while forwarding in a radio access network seems to represent
      a layering violation. However, it can be considered as a benign
      optimization 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" bare="false" empty="false" indent="3" pn="section-5-5">
        <li pn="section-5-5.1">IPv4 and IPv6 are not the only Layer 3 protocols that might be
          encapsulated by lower-layer protocols.</li>
        <li pn="section-5-5.2">Link-layer encryption might be in use, making the Layer 2 payload
          inaccessible.</li>
        <li pn="section-5-5.3">Many Ethernet switches do not have 'Layer 3 switch' capabilities,
          so the ability to read or modify an IP payload cannot be assumed.</li>
        <li pn="section-5-5.4">It might be costly to find an IP header (IPv4 or IPv6) when it may be
          encapsulated by more than one lower-layer header, e.g., Ethernet MAC
          in MAC (<xref target="IEEE802.1Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>; previously 802.1ah).</li>
      </ul>
      <t indent="0" pn="section-5-6">Nonetheless, configuring lower-layer equipment to look for an ECN
      field in an encapsulated IP header is a useful optimization. If the
      implementation follows the guidelines below, this optimization does not
      have to be confined to a controlled environment, e.g., within a data
      centre; it could usefully be applied in any network -- even if the
      operator is not sure whether the above issues will never apply:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-7"><li pn="section-5-7.1" derivedCounter="1.">If a built-in 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 built-in mechanism.</li>
        <li pn="section-5-7.2" derivedCounter="2.">The depth of the search for an IP header <bcp14>SHOULD</bcp14> be limited. If an
          IP header is not found soon enough, or an unrecognized or unreadable
          header is encountered, the switch <bcp14>SHOULD</bcp14> resort to an alternative
          means of signalling congestion (e.g., drop or the built-in lower-layer
          mechanism if available).</li>
        <li pn="section-5-7.3" derivedCounter="3.">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="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-feed-backward-mode-guidelin">Feed-Backward Mode: Guidelines for Adding Congestion Notification</name>
      <t indent="0" pn="section-6-1">It can be seen from <xref target="ecnencap_Backward" format="default" sectionFormat="of" derivedContent="Section 3.3"/> that
      congestion notification in a subnet using feed-backward mode has
      generally not been designed to be directly coupled with IP-layer
      congestion notification. The subnet attempts to minimize congestion
      internally, and if the incoming load at the ingress exceeds the capacity
      somewhere through the subnet, the Layer 3 buffer into the ingress backs
      up. Thus, a feed-backward mode subnet is in some sense similar to a null
      mode subnet, in that there is no need for any direct interaction between
      the subnet and higher-layer congestion notification. Therefore, no
      detailed protocol design guidelines are appropriate. Nonetheless, a more
      general guideline is appropriate: </t>
      <blockquote pn="section-6-2">A subnetwork technology intended to eventually interface
        to IP <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 wider
        Internet because IP uses feed-forward-and-up mode.</blockquote>
      <t indent="0" pn="section-6-3">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 data source when it is faster than feed-forward. It would be
      valid to design a protocol that could work in feed-backward mode for
      paths that only cross one subnet, and in feed-forward-and-up mode for
      paths that cross subnets.</t>
      <t indent="0" pn="section-6-4">In the early days of TCP/IP, a similar feed-backward approach was
      tried for explicit congestion signalling using source-quench (SQ) ICMP
      control packets. However, SQ fell out of favour and is now formally
      deprecated <xref target="RFC6633" format="default" sectionFormat="of" derivedContent="RFC6633"/>. 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 a lower-layer buffer to address an SQ message to the
      original source port number, which may be buried within many layers of
      headers and possibly encrypted.</t>
      <t indent="0" pn="section-6-5">QCN (also known as Backward Congestion Notification (BCN); see
      Sections 30-33 of <xref target="IEEE802.1Q" format="default" sectionFormat="of" derivedContent="IEEE802.1Q"/>, 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., when attempting to
      interconnect multiple data centres) it would suffer the inefficiency
      shown in <xref target="ecnencap_Fig_Feed-Backward" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
    </section>
    <section anchor="ecnencap_IANA_Considerations" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
    </section>
    <section anchor="ecnencap_Security_Considerations" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">If a lower-layer wire protocol is redesigned to include explicit
      congestion signalling in-band in the protocol header, care <bcp14>SHOULD</bcp14> be
      taken to ensure that the field used is specified as mutable during
      transit. Otherwise, interior nodes signalling congestion would invalidate
      any authentication protocol applied to the lower-layer header -- by
      altering a header field that had been assumed as immutable.</t>
      <t indent="0" pn="section-8-2">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, such as:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-3">
        <li pn="section-8-3.1">
          <t indent="0" pn="section-8-3.1.1">Congestion Exposure (ConEx) for networks:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8-3.1.2">
            <li pn="section-8-3.1.2.1">to audit that their
          congestion signals are not being suppressed by other networks or by
          receivers; and</li>
            <li pn="section-8-3.1.2.2">to police that senders are responding
          sufficiently to the signals, irrespective of the L4 transport
          protocol used <xref target="RFC7713" format="default" sectionFormat="of" derivedContent="RFC7713"/>.</li>
          </ul>
        </li>
        <li pn="section-8-3.2">A test for a sender to detect whether a network or the receiver
          is suppressing congestion signals (for example, see the second paragraph of <xref section="20.2" target="RFC3168" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc3168#section-20.2" derivedContent="RFC3168"/>).</li>
      </ul>
      <t indent="0" pn="section-8-4">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 new lower-layer protocol because end-to-end
      integrity inherently achieves hop-by-hop integrity.</t>
      <t indent="0" pn="section-8-5"><xref target="ecnencap_Guidelines_Backward" format="default" sectionFormat="of" derivedContent="Section 6"/> gives vulnerability to
      spoofing as one of the reasons for deprecating feed-backward mode.</t>
    </section>
    <section anchor="ecnencap_Conclusions" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-conclusions">Conclusions</name>
      <t indent="0" pn="section-9-1">Following the guidance in this document enables ECN support to be
      extended consistently to numerous protocols that encapsulate IP (IPv4 and
      IPv6) so that IP continues to fulfil its role as an end-to-end
      interoperability layer. This includes:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-2">
        <li pn="section-9-2.1">A wide range of tunnelling protocols, including those with various
          forms of shim header between two IP headers, possibly also separated
          by an L2 header;</li>
        <li pn="section-9-2.2">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 indent="0" pn="section-9-3">Guidelines have been defined for supporting propagation of ECN
      between Ethernet and IP on so-called Layer 3 Ethernet 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 the
      lower-layer protocol does not support ECN.</t>
      <t indent="0" pn="section-9-4">Finally, attempting to add congestion notification to a subnet technology in
      feed-backward mode is deprecated except in special cases due to its
      likely sluggish response to congestion.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-intarea-gue" to="INTAREA-GUE"/>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC3168">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC3819">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC4774">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC5129">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC6040">
          <front>
            <title>Tunnelling of Explicit Congestion Notification</title>
            <author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
            <date month="November" year="2010"/>
            <abstract>
              <t indent="0">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" quoteTitle="true" derivedAnchor="RFC7141">
          <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 indent="0">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 as CoDel (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 treatment of small packets in AQM algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="41"/>
          <seriesInfo name="RFC" value="7141"/>
          <seriesInfo name="DOI" value="10.17487/RFC7141"/>
        </reference>
        <reference anchor="RFC9600" target="https://www.rfc-editor.org/info/rfc9600" quoteTitle="true" derivedAnchor="RFC9600">
          <front>
            <title>TRansparent Interconnection of Lots of Links (TRILL): Explicit Congestion Notification (ECN) Support</title>
            <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake 3rd">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
              <organization showOnFrontPage="true">CableLabs</organization>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="RFC" value="9600"/>
          <seriesInfo name="DOI" value="10.17487/RFC9600"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <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" quoteTitle="true" derivedAnchor="ATM-TM-ABR">
          <front>
            <title>Understanding the Available Bit Rate (ABR) Service Category for ATM VCs</title>
            <author>
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <date month="June" year="2005"/>
          </front>
          <seriesInfo name="Design Technote" value="10415"/>
        </reference>
        <reference anchor="Buck00" quoteTitle="true" derivedAnchor="Buck00">
          <front>
            <title>Frame Relay: Technology and Practice</title>
            <author fullname="Jeff T. Buckwalter" initials="J.T." surname="Buckwalter">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000"/>
          </front>
          <seriesInfo name="ISBN-13" value="978-0201485240"/>
          <refcontent>Addison-Wesley Professional</refcontent>
        </reference>
        <reference anchor="Clos53" quoteTitle="true" target="https://doi.org/10.1002/j.1538-7305.1953.tb01433.x" derivedAnchor="Clos53">
          <front>
            <title>A Study of Non-Blocking Switching Networks</title>
            <author fullname="Charles Clos" initials="C." surname="Clos">
            </author>
            <date month="March" year="1953"/>
          </front>
          <seriesInfo name="DOI" value="10.1002/j.1538-7305.1953.tb01433.x"/>
          <refcontent>The Bell System Technical Journal, Vol. 32, Issue 2</refcontent>
        </reference>
        <reference anchor="GTPv1" quoteTitle="true" derivedAnchor="GTPv1">
          <front>
            <title>General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="Technical Specification" value="29.060"/>
        </reference>
        <reference anchor="GTPv1-U" quoteTitle="true" derivedAnchor="GTPv1-U">
          <front>
            <title>General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
          </front>
          <seriesInfo name="Technical Specification" value="29.281"/>
        </reference>
        <reference anchor="GTPv2-C" quoteTitle="true" derivedAnchor="GTPv2-C">
          <front>
            <title>3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
          </front>
          <seriesInfo name="Technical Specification" value="29.274"/>
        </reference>
        <reference anchor="IEEE802.1Q" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2022.10004498" derivedAnchor="IEEE802.1Q">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="December" year="2022"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1Q-2022"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.10004498"/>
        </reference>
        <reference anchor="I-D.ietf-intarea-gue" target="https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-09" quoteTitle="true" derivedAnchor="INTAREA-GUE">
          <front>
            <title>Generic UDP Encapsulation</title>
            <author initials="T." surname="Herbert" fullname="Tom Herbert">
              <organization showOnFrontPage="true">Quantonium</organization>
            </author>
            <author initials="L." surname="Yong" fullname="Lucy Yong">
              <organization showOnFrontPage="true">Independent</organization>
            </author>
            <author initials="O." surname="Zia" fullname="Osama Zia">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <date month="October" day="26" year="2019"/>
            <abstract>
              <t indent="0">   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"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="ITU-T.I.371" target="https://www.itu.int/rec/T-REC-I.371-200403-I/en" quoteTitle="true" derivedAnchor="ITU-T.I.371">
          <front>
            <title>Traffic control and congestion control in B-ISDN</title>
            <author fullname="" initials="" surname="">
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="March" year="2004"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="I.371"/>
        </reference>
        <reference anchor="Leiserson85" quoteTitle="true" target="https://doi.org/10.1109/TC.1985.6312192" derivedAnchor="Leiserson85">
          <front>
            <title>Fat-trees: Universal networks for hardware-efficient supercomputing</title>
            <author fullname="Charles E. Leiserson" initials="C.E." surname="Leiserson">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="October" year="1985"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/TC.1985.6312192"/>
          <refcontent>IEEE Transactions on Computers, Vol. C-34, Issue 10</refcontent>
        </reference>
        <reference anchor="LTE-RA" quoteTitle="true" derivedAnchor="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 showOnFrontPage="true">3GPP</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="Technical Specification" value="36.300"/>
        </reference>
        <reference anchor="RFC2003" target="https://www.rfc-editor.org/info/rfc2003" quoteTitle="true" derivedAnchor="RFC2003">
          <front>
            <title>IP Encapsulation within IP</title>
            <author fullname="C. Perkins" initials="C." surname="Perkins"/>
            <date month="October" year="1996"/>
            <abstract>
              <t indent="0">This document specifies a method by which an IP datagram may be encapsulated (carried as payload) 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" quoteTitle="true" derivedAnchor="RFC2473">
          <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 indent="0">This document defines the model and generic mechanisms for IPv6 encapsulation of Internet 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" quoteTitle="true" derivedAnchor="RFC2637">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC2661">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC2784">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC2884">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC2983">
          <front>
            <title>Differentiated Services and Tunnels</title>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="October" year="2000"/>
            <abstract>
              <t indent="0">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" quoteTitle="true" derivedAnchor="RFC3931">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC4301">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC4380">
          <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 indent="0">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 such as "6to4". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4380"/>
          <seriesInfo name="DOI" value="10.17487/RFC4380"/>
        </reference>
        <reference anchor="RFC5415" target="https://www.rfc-editor.org/info/rfc5415" quoteTitle="true" derivedAnchor="RFC5415">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC6633">
          <front>
            <title>Deprecation of ICMP Source Quench Messages</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="May" year="2012"/>
            <abstract>
              <t indent="0">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" quoteTitle="true" derivedAnchor="RFC6660">
          <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 indent="0">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 indent="0">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" quoteTitle="true" derivedAnchor="RFC7323">
          <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 indent="0">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 indent="0">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" quoteTitle="true" derivedAnchor="RFC7348">
          <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 indent="0">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="RFC7567" target="https://www.rfc-editor.org/info/rfc7567" quoteTitle="true" derivedAnchor="RFC7567">
          <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 indent="0">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 indent="0">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" quoteTitle="true" derivedAnchor="RFC7637">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC7713">
          <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 indent="0">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. The companion document, "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="RFC7780" target="https://www.rfc-editor.org/info/rfc7780" quoteTitle="true" derivedAnchor="RFC7780">
          <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 indent="0">Since the publication of the TRILL (Transparent Interconnection of Lots 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="RFC8084" target="https://www.rfc-editor.org/info/rfc8084" quoteTitle="true" derivedAnchor="RFC8084">
          <front>
            <title>Network Transport Circuit Breakers</title>
            <author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
            <date month="March" year="2017"/>
            <abstract>
              <t indent="0">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>
        <reference anchor="RFC8087" target="https://www.rfc-editor.org/info/rfc8087" quoteTitle="true" derivedAnchor="RFC8087">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC8174">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC8257">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC8300">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC8311">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC8926">
          <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 indent="0">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" quoteTitle="true" derivedAnchor="RFC9300">
          <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 indent="0">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 indent="0">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 indent="0">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" quoteTitle="true" derivedAnchor="RFC9331">
          <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 indent="0">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 indent="0">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="RFC9601" target="https://www.rfc-editor.org/info/rfc9601" quoteTitle="true" derivedAnchor="RFC9601">
          <front>
            <title>Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim</title>
            <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
              <organization showOnFrontPage="true">Independent</organization>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="RFC" value="9601"/>
          <seriesInfo name="DOI" value="10.17487/RFC9601"/>
        </reference>
        <reference anchor="UTRAN" quoteTitle="true" derivedAnchor="UTRAN">
          <front>
            <title>UTRAN overall description</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
          </front>
          <seriesInfo name="Technical Specification" value="25.401"/>
        </reference>
      </references>
    </references>
    <section anchor="ecnencap_Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to <contact fullname="Gorry Fairhurst"/> and <contact fullname="David Black"/> for extensive reviews.  Thanks also to the
      following reviewers: <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 that lower-layer congestion notification signals may have
      different semantics to those in IP. Thanks are also due to the Transport and Services Working Group (tsvwg)
      chairs, TSV ADs and IETF liaison people such as <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 to <contact fullname="Georg Mayer"/> and
      particularly to <contact fullname="Erik Guttman"/> for the extensive
      search and categorization of any 3GPP specifications that cite ECN
      specifications. Thanks also to the Area Reviewers <contact fullname="Dan       Harkins"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Sue       Hares"/>, and <contact fullname="Dale Worley"/>.</t>
      <t indent="0" pn="section-appendix.a-2"><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 through the Reducing Internet Transport Latency (RITE)
      project (ICT-317700), and for final drafts (from -18) he was funded by Apple Inc. The
      views expressed here are solely those of the authors.</t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Pat Thaler">
        <organization showOnFrontPage="true">Broadcom Corporation (retired)</organization>
        <address>
          <postal>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
        </address>
      </contact>
      <t indent="0" pn="section-appendix.b-1">Pat was a coauthor of this document, but retired before its
      publication.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
        <organization showOnFrontPage="true">Independent</organization>
        <address>
          <postal>
            <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 showOnFrontPage="true">Futurewei</organization>
        <address>
          <postal>
            <street>5700 Tennyson Parkway, Suite 600</street>
            <city>Plano</city>
            <region>Texas</region>
            <code>75024</code>
            <country>United States of America</country>
          </postal>
          <email>kjohn@futurewei.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
