<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-trill-ecn-support-07" number="9600" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" prepTime="2024-08-30T19:43:38" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9600" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="TRILL ECN Support">TRansparent Interconnection of Lots of Links (TRILL): Explicit Congestion Notification (ECN) Support</title>
    <seriesInfo name="RFC" value="9600" stream="IETF"/>
    <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake, 3rd">
      <organization showOnFrontPage="true">Independent</organization>
      <address>
        <postal>
          <street>2386 Panoramic Circle</street>
          <city>Apopka</city>
          <region>FL</region>
          <code>32703</code>
          <country>United States of America</country>
        </postal>
        <phone>+1-508-333-2270</phone>
        <email>d3e3e3@gmail.com</email>
      </address>
    </author>
    <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
      <organization showOnFrontPage="true">Independent</organization>
      <address>
        <postal>
          <country>United Kingdom</country>
        </postal>
        <email>ietf@bobbriscoe.net</email>
        <uri>http://bobbriscoe.net/</uri>
      </address>
    </author>
    <date month="08" year="2024"/>
    <area>RTG</area>
    <workgroup>TRILL</workgroup>
    <keyword>example</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
   Explicit Congestion Notification (ECN) allows a forwarding element to
   notify downstream devices, including the destination, of the onset of
   congestion without having to drop packets. This can improve network
   efficiency through better congestion control without packet drops.
   This document extends ECN to TRansparent Interconnection of
   Lots of Links (TRILL) switches, including integration with IP ECN, and
   provides for ECN marking in the TRILL header extension flags word
   (RFC 7179).</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 is an Internet Standards Track document.
        </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 Internet Standards 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/rfc9600" 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-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" 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-the-ecn-specific-extended-h">The ECN-Specific Extended Header Flags</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-ecn-support">ECN Support</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-ingress-ecn-support">Ingress ECN Support</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-transit-ecn-support">Transit ECN Support</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-egress-ecn-support">Egress ECN Support</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-non-ecn-egress-rbridges">Non-ECN Egress RBridges</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ecn-egress-rbridges">ECN Egress RBridges</xref></t>
                  </li>
                </ul>
              </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-trill-support-for-ecn-varia">TRILL Support for ECN Variants</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-pre-congestion-notification">Pre-Congestion Notification (PCN)</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-low-latency-low-loss-and-sc">Low Latency, Low Loss, and Scalable Throughput (L4S)</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-iana-considerations">IANA Considerations</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-security-considerations">Security Considerations</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-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trill-transit-rbridge-behav">TRILL Transit RBridge Behavior to Support L4S</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.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="sect-1" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
   Explicit Congestion Notification (ECN) <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/> allows a
   forwarding element (such as a router) to
   notify downstream devices, including the destination, of the onset of
   congestion without having to drop packets. This can improve network
   efficiency through better congestion control without packet drops. The
   forwarding element can explicitly mark a proportion of packets in an ECN
   field instead of dropping packets. For example, a 2-bit field is
   available for ECN marking in IP headers.</t>
      <figure anchor="fig-1" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-example-path-forwarding-nod">Example Path-Forwarding Nodes</name>
        <artwork name="" type="" align="left" alt="" pn="section-1-2.1">
                  .............................
                  .                           .
              +---------+                     .
 +------+     | Ingress |                     .
 |Source|  +-&gt;| RBridge |                     .   +----------+
 +---+--+  |  |   RB1   |                     .   |Forwarding|
     |     |  +------+--+  +----------+       .   | Element  |
     v     |      .  |     | Transit  |       .   |    Y     |
   +-------+--+   .  +----&gt;| RBridges |       .   +--------+-+
   |Forwarding|   .        |   RBn    |       .      ^     |
   | Element  |   .        +-------+--+  +---------+ |     v
   |    X     |   .                |     | Egress  | |  +-----------+
   +----------+   .                +----&gt;| RBridge +-+  |Destination|
                  .                      |   RB9   |    +-----------+
                  .  TRILL               +---------+
                  .  campus                   .
                  .............................
</artwork>
      </figure>
      <t indent="0" pn="section-1-3">
   In <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>, it was recognized that tunnels and lower-layer
   protocols would need to support ECN, and ECN markings would need to
   be propagated, as headers were encapsulated and decapsulated.
   <xref target="RFC9599" format="default" sectionFormat="of" derivedContent="RFC9599"/> gives guidelines on the addition of ECN to protocols
   like TRILL that often
   encapsulate IP packets, including propagation of ECN from and to IP.</t>
      <t indent="0" pn="section-1-4">
   In <xref target="fig-1" format="default" sectionFormat="of" derivedContent="Figure 1"/>, assuming IP traffic, RB1 is an encapsulator and
   RB9 is a decapsulator. Traffic from Source to RB1 might or might not get
   marked as having experienced congestion in forwarding elements, such
   as X, before being encapsulated at ingress RB1. Any such ECN marking
   is encapsulated with a TRILL header <xref target="RFC6325" format="default" sectionFormat="of" derivedContent="RFC6325"/>.</t>
      <t indent="0" pn="section-1-5">
   This document specifies how ECN marking in traffic at the ingress is
   copied into the TRILL extension header flags word and requires such
   copying for IP traffic. It also enables congestion marking by a
   congested RBridge (such as RBn or RB1 above) in the TRILL header
   extension flags word <xref target="RFC7179" format="default" sectionFormat="of" derivedContent="RFC7179"/>.</t>
      <t indent="0" pn="section-1-6">
   At RB9, the TRILL egress, it specifies how any ECN markings in the
   TRILL header flags word and in the encapsulated traffic are combined
   so that subsequent forwarding elements, such as Y and the
   Destination, can see if congestion was experienced at any previous
   point in the path from the Source.</t>
      <t indent="0" pn="section-1-7">
   A large part of the guidelines for adding ECN to lower-layer
   protocols <xref target="RFC9599" format="default" sectionFormat="of" derivedContent="RFC9599"/> concerns safe propagation of congestion
   notifications in scenarios where some of the nodes do not support or
   understand ECN. Such ECN ignorance is not a major problem with
   RBridges using this specification, because the method specified
   assures that, if an egress RBridge is ECN ignorant (so it cannot
   further propagate ECN) and congestion has been encountered, the
   egress RBridge will at least drop the packet, and this drop will
   itself indicate congestion to end stations.</t>
      <section anchor="sect-1.1" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
        <t indent="0" pn="section-1.1-1">
   The terminology and acronyms defined in <xref target="RFC6325" format="default" sectionFormat="of" derivedContent="RFC6325"/> are used herein with the same meaning.</t>
        <t indent="0" pn="section-1.1-2">
   In this documents, "IP" refers to both IPv4 and IPv6.</t>
        <t indent="0" pn="section-1.1-3">
    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-1.1-4">Abbreviations:</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-1.1-5">
          <dt pn="section-1.1-5.1">AQM:</dt>
          <dd pn="section-1.1-5.2">Active Queue Management</dd>
          <dt pn="section-1.1-5.3">CCE:</dt>
          <dd pn="section-1.1-5.4">Critical Congestion Experienced</dd>
          <dt pn="section-1.1-5.5">CE:</dt>
          <dd pn="section-1.1-5.6">Congestion Experienced</dd>
          <dt pn="section-1.1-5.7">CItE:</dt>
          <dd pn="section-1.1-5.8">Critical Ingress-to-Egress</dd>
          <dt pn="section-1.1-5.9">ECN:</dt>
          <dd pn="section-1.1-5.10">Explicit Congestion Notification</dd>
          <dt pn="section-1.1-5.11">ECT:</dt>
          <dd pn="section-1.1-5.12">ECN-Capable Transport</dd>
          <dt pn="section-1.1-5.13">L4S:</dt>
          <dd pn="section-1.1-5.14">Low Latency, Low Loss, and Scalable throughput</dd>
          <dt pn="section-1.1-5.15">NCHbH:</dt>
          <dd pn="section-1.1-5.16">Non-Critical Hop-by-Hop</dd>
          <dt pn="section-1.1-5.17">NCCE:</dt>
          <dd pn="section-1.1-5.18">Non-Critical Congestion Experienced</dd>
          <dt pn="section-1.1-5.19">Not-ECT:</dt>
          <dd pn="section-1.1-5.20">Not ECN-Capable Transport</dd>
          <dt pn="section-1.1-5.21">PCN:</dt>
          <dd pn="section-1.1-5.22">Pre-Congestion Notification</dd>
        </dl>
      </section>
    </section>
    <section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-the-ecn-specific-extended-h">The ECN-Specific Extended Header Flags</name>
      <t indent="0" pn="section-2-1">
   The extension header fields for ECN in TRILL are defined as a 2-bit TRILL-ECN field and a one-bit CCE field in the 32-bit TRILL
   header extension flags word <xref target="RFC7780" format="default" sectionFormat="of" derivedContent="RFC7780"/>.</t>
      <t indent="0" pn="section-2-2">
   These fields are shown in <xref target="fig-2" format="default" sectionFormat="of" derivedContent="Figure 2"/> as "ECN" and "CCE". The
   TRILL-ECN field consists of bits 12 and 13, which are in the range reserved
   for NCHbH bits. The CCE field consists of bit 26,
   which is in the range reserved for CItE bits. The CRItE bit is the critical
   Ingress-to-Egress summary bit and will be one if, and only if, any of the
   bits in the CItE range (21-26) are one or there is a critical feature
   invoked in some further extension of the TRILL header after the extension
   flags word.  The other bits and fields shown in <xref target="fig-2" format="default" sectionFormat="of" derivedContent="Figure 2"/> are
   not relevant to ECN.  See <xref target="RFC7780" format="default" sectionFormat="of" derivedContent="RFC7780"/>, <xref target="RFC7179" format="default" sectionFormat="of" derivedContent="RFC7179"/>, and <xref target="IANAthFlags" format="default" sectionFormat="of" derivedContent="IANAthFlags"/> for the meaning of these other bits and fields.</t>
      <figure anchor="fig-2" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-the-trill-ecn-and-cce-trill">The TRILL-ECN and CCE TRILL Header Extension Flags Word Fields</name>
        <artwork name="" type="" align="left" alt="" pn="section-2-3.1">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.|  CHbH   |   NCHbH   |CRSV | NCRSV |   CItE    |  NCItE  |
|.....|.........|...........|.....|.......|...........|.........|
|C|C|C|       |C|N|     |   |     |       |         | |   |     |
|R|R|R|       |R|C|     |ECN| Ext |       |         |C|Ext|     |
|H|I|R|       |C|C|     |   | Hop |       |         |C|Clr|     |
|b|t|s|       |A|A|     |   | Cnt |       |         |E|   |     |
|H|E|v|       |F|F|     |   |     |       |         | |   |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>
      <t indent="0" pn="section-2-4">
   <xref target="codepoints" format="default" sectionFormat="of" derivedContent="Table 1"/> shows the meaning of the codepoints in the
   TRILL-ECN field.  The first three have the same meaning as the
   corresponding ECN field codepoints in the IP header, as defined in <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>. However, codepoint 0b11 is called NCEE to distinguish
   it from CE in IP.</t>
      <table anchor="codepoints" align="center" pn="table-1">
        <name slugifiedName="name-trill-ecn-field-codepoints">TRILL-ECN Field Codepoints</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Binary</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Meaning</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">00</td>
            <td align="left" colspan="1" rowspan="1">Not-ECT</td>
            <td align="left" colspan="1" rowspan="1">Not ECN-Capable Transport </td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">01</td>
            <td align="left" colspan="1" rowspan="1">ECT(1)</td>
            <td align="left" colspan="1" rowspan="1">ECN-Capable Transport (1)</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">10</td>
            <td align="left" colspan="1" rowspan="1">ECT(0)</td>
            <td align="left" colspan="1" rowspan="1">ECN-Capable Transport (0)</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">11</td>
            <td align="left" colspan="1" rowspan="1">NCCE</td>
            <td align="left" colspan="1" rowspan="1">Non-Critical Congestion Experienced</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-ecn-support">ECN Support</name>
      <t indent="0" pn="section-3-1">
   This section specifies interworking between TRILL and the original
   standardized form of ECN in IP <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>.</t>
      <t indent="0" pn="section-3-2">
   The subsections below describe the required behavior to support ECN
   at TRILL ingress, transit, and egress. The ingress behavior occurs as
   a native frame is encapsulated with a TRILL header to produce a TRILL
   Data packet. The transit behavior occurs in all RBridges where TRILL
   Data packets are queued, usually at the output port (including the output port of the TRILL ingress).  The egress
   behavior occurs where a TRILL Data packet is decapsulated and output
   as a native frame through an RBridge port.</t>
      <t indent="0" pn="section-3-3">
   An RBridge that supports ECN <bcp14>MUST</bcp14> behave as described in the relevant
   subsections below, which correspond to the recommended provisions in
   <xref target="sect-3" format="default" sectionFormat="of" derivedContent="Section 3"/> of this document and Sections <xref target="RFC9599" sectionFormat="bare" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9599#section-4.2" derivedContent="RFC9599"/> through <xref target="RFC9599" sectionFormat="bare" section="4.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9599#section-4.4" derivedContent="RFC9599"/> of <xref target="RFC9599" format="default" sectionFormat="of" derivedContent="RFC9599"/>. Nonetheless, the
   scheme is designed to safely propagate some form of congestion
   notification even if some RBridges in the path followed by a TRILL
   Data packet support ECN and others do not.</t>
      <section anchor="sect-3.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-ingress-ecn-support">Ingress ECN Support</name>
        <t indent="0" pn="section-3.1-1">
   The behavior at an ingress RBridge is as follows:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2">
          <li pn="section-3.1-2.1">
            <t indent="0" pn="section-3.1-2.1.1">When encapsulating an IP frame, the ingress RBridge <bcp14>MUST</bcp14>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2.1.2">
              <li pn="section-3.1-2.1.2.1">set the F flag in the main TRILL header <xref target="RFC7780" format="default" sectionFormat="of" derivedContent="RFC7780"/>;</li>
              <li pn="section-3.1-2.1.2.2">create a flags word as part of the TRILL header;</li>
              <li pn="section-3.1-2.1.2.3">copy the two ECN bits from the IP header into the TRILL-ECN
         field (flags word bits 12 and 13); and</li>
              <li pn="section-3.1-2.1.2.4">ensure the CCE flag is set to zero (flags word bit 26).</li>
            </ul>
          </li>
          <li pn="section-3.1-2.2">When encapsulating a frame for a non-IP protocol (where that
          protocol has a means of indicating that ECN is understood by the
          ingress RBridge), the ingress RBridge <bcp14>MUST</bcp14> follow the guidelines in
          <xref target="RFC9599" sectionFormat="of" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9599#section-4.3" derivedContent="RFC9599"/> to add a
          flags word to the TRILL header. For a non-IP protocol with an ECN
          field similar to IP, this would be achieved by copying into the
          TRILL-ECN field from the encapsulated native frame.</li>
        </ul>
      </section>
      <section anchor="sect-3.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-transit-ecn-support">Transit ECN Support</name>
        <t indent="0" pn="section-3.2-1">
   The transit behavior, shown below, is required at all RBridges where
   TRILL Data packets are queued, usually at the output port.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-2">
          <li pn="section-3.2-2.1">An RBridge that supports ECN <bcp14>MUST</bcp14> implement some form of AQM according to the guidelines of <xref target="RFC7567" format="default" sectionFormat="of" derivedContent="RFC7567"/>.
      The RBridge detects congestion either by monitoring its own queue
      depth or by participating in a link-specific protocol.</li>
          <li pn="section-3.2-2.2">If the TRILL header flags word is present, whenever the AQM
      algorithm decides to indicate critical congestion on a TRILL Data packet, it
      <bcp14>MUST</bcp14> set the CCE flag (flags word bit 26). Note that Classic ECN marking <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> only uses critical congestion indications, but the two variants in <xref target="sect-4.1" format="default" sectionFormat="of" derivedContent="Section 4.1"/> use a combination of critical and non-critical congestion indications.</li>
          <li pn="section-3.2-2.3">
            <t indent="0" pn="section-3.2-2.3.1">If the TRILL header flags word is not present, the RBridge will
            either drop the packet or it <bcp14>MAY</bcp14> do all of the
            following instead to indicate congestion:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-2.3.2">
              <li pn="section-3.2-2.3.2.1">set the F flag in the main TRILL header;</li>
              <li pn="section-3.2-2.3.2.2">add a flags word to the TRILL header;</li>
              <li pn="section-3.2-2.3.2.3">set the TRILL-ECN field to Not-ECT (00); and</li>
              <li pn="section-3.2-2.3.2.4">set the CCE flag and the critical Ingress-to-Egress summary bit (CRItE).</li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-3.2-3">
   Note that a transit RBridge that supports ECN does not refer to the
   TRILL-ECN field before signaling CCE in a packet. It signals CCE
   irrespective of whether the packet indicates that the transport is ECN
   capable. The egress/decapsulation behavior ensures that a CCE indication is
   converted to a drop if the transport is not ECN capable.</t>
      </section>
      <section anchor="sect-3.3" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-egress-ecn-support">Egress ECN Support</name>
        <section anchor="sect-3.3.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-non-ecn-egress-rbridges">Non-ECN Egress RBridges</name>
          <t indent="0" pn="section-3.3.1-1">
   If the egress RBridge does not support ECN, that RBridge will ignore
   bits 12 and 13 of any flags word that is present because it does not
   contain any special ECN logic. Nonetheless, if a transit RBridge has
   set the CCE flag, the egress will drop the packet. This is because
   drop is the default behavior for an RBridge decapsulating a CItE flag when it has no specific logic to understand
   it. 
Drop is the intended behavior for such a packet, as required by
   <xref target="RFC9599" sectionFormat="of" section="4.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9599#section-4.4" derivedContent="RFC9599"/>.</t>
        </section>
        <section anchor="sect-3.3.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.2">
          <name slugifiedName="name-ecn-egress-rbridges">ECN Egress RBridges</name>
          <t indent="0" pn="section-3.3.2-1">
   If an RBridge supports ECN, for the two cases of an IP and a non-IP
   inner packet, the egress behavior is as follows:

          </t>
          <dl newline="false" spacing="normal" indent="3" pn="section-3.3.2-2">
            <dt pn="section-3.3.2-2.1">Decapsulating an inner IP packet:</dt>
            <dd pn="section-3.3.2-2.2">
              <t indent="0" pn="section-3.3.2-2.2.1">The RBridge sets the
      ECN field of the outgoing native IP packet using <xref target="egress-ecn" format="default" sectionFormat="of" derivedContent="Table 3"/>. It <bcp14>MUST</bcp14> set
      the ECN field of the outgoing IP packet to the codepoint at the
      intersection of the row for the arriving encapsulated IP packet and the
      column for 3-bit ECN codepoint in the arriving outer TRILL Data packet
      TRILL header. If no TRILL header extension flags word is present, the
      3-bit ECN codepoint is assumed to be all zero bits.</t>
              <t indent="0" pn="section-3.3.2-2.2.2">The name of the TRILL 3-bit ECN codepoint used in <xref target="egress-ecn" format="default" sectionFormat="of" derivedContent="Table 3"/> is defined using the
      combination of the TRILL-ECN and CCE fields in <xref target="mapping" format="default" sectionFormat="of" derivedContent="Table 2"/>.  Specifically,
      the TRILL 3-bit ECN codepoint is called CE if either NCCE or CCE is set
      in the TRILL header extension flags word. Otherwise, it has the same name
      as the 2-bit TRILL-ECN codepoint.</t>
              <t indent="0" pn="section-3.3.2-2.2.3">
            In the case where the TRILL 3-bit ECN codepoint indicates CE but
            the encapsulated native IP frame indicates a Not-ECT, it can be
            seen that the RBridge <bcp14>MUST</bcp14> drop the packet.  Such
            packet dropping is necessary because a transport above the IP
            layer that is not ECN capable will have no ECN logic, so it will
            only understand dropped packets as an indication of
            congestion.</t>
            </dd>
          </dl>
          <dl newline="false" spacing="normal" indent="3" pn="section-3.3.2-3">
            <dt pn="section-3.3.2-3.1">Decapsulating a non-IP protocol frame:</dt>
            <dd pn="section-3.3.2-3.2">If the frame has
	a means of indicating ECN that is understood by the RBridge, it <bcp14>MUST</bcp14>
	follow the guidelines in <xref target="RFC9599" sectionFormat="of" section="4.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9599#section-4.4" derivedContent="RFC9599"/> when
	setting the ECN
	information in the decapsulated native frame.  For a non-IP protocol
	with an ECN field similar to IP, this would be achieved by combining
	the information in the TRILL header flags word with the encapsulated
	non-IP native frame, as specified in <xref target="egress-ecn" format="default" sectionFormat="of" derivedContent="Table 3"/>.</dd>
          </dl>
          <table anchor="mapping" align="center" pn="table-2">
            <name slugifiedName="name-mapping-of-trill-ecn-and-cc">Mapping of TRILL-ECN and CCE Fields to the TRILL 3-Bit ECN Codepoint Name</name>
            <thead>
              <tr>
                <th rowspan="1" colspan="2" align="left">TRILL-ECN</th>
                <th rowspan="2" align="left" colspan="1">CCE</th>
                <th rowspan="2" align="left" colspan="1">Arriving TRILL 3-Bit ECN Codepoint Name</th>
              </tr>
              <tr>
                <th align="left" colspan="1" rowspan="1">Name</th>
                <th align="left" colspan="1" rowspan="1">Bits</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">Not-ECT</td>
                <td align="center" colspan="1" rowspan="1">00</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="left" colspan="1" rowspan="1">Not-ECT</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">ECT(1)</td>
                <td align="center" colspan="1" rowspan="1">01</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="left" colspan="1" rowspan="1">ECT(1)</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">ECT(0)</td>
                <td align="center" colspan="1" rowspan="1">10</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="left" colspan="1" rowspan="1">ECT(0)</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">NCCE</td>
                <td align="center" colspan="1" rowspan="1">11</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="left" colspan="1" rowspan="1">CE</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">Not-ECT</td>
                <td align="center" colspan="1" rowspan="1">00</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="left" colspan="1" rowspan="1">CE</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">ECT(1)</td>
                <td align="center" colspan="1" rowspan="1">01</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="left" colspan="1" rowspan="1">CE</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">ECT(0)</td>
                <td align="center" colspan="1" rowspan="1">10</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="left" colspan="1" rowspan="1">CE</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">NCCE</td>
                <td align="center" colspan="1" rowspan="1"> 11</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="left" colspan="1" rowspan="1">CE</td>
              </tr>
            </tbody>
          </table>
          <table anchor="egress-ecn" align="center" pn="table-3">
            <name slugifiedName="name-egress-ecn-behavior">Egress ECN Behavior</name>
            <thead>
              <tr>
                <th rowspan="2" align="center" colspan="1">Inner Native Header</th>
                <th colspan="4" align="center" rowspan="1">Arriving TRILL 3-Bit ECN Codepoint Name</th>
              </tr>
              <tr>
                <th align="center" colspan="1" rowspan="1">Not-ECT</th>
                <th align="center" colspan="1" rowspan="1">ECT(0)</th>
                <th align="center" colspan="1" rowspan="1">ECT(1)</th>
                <th align="center" colspan="1" rowspan="1">CE</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center" colspan="1" rowspan="1">Not-ECT</td>
                <td align="center" colspan="1" rowspan="1">Not-ECT</td>
                <td align="center" colspan="1" rowspan="1">Not-ECT(*)</td>
                <td align="center" colspan="1" rowspan="1">Not-ECT(*)</td>
                <td align="center" colspan="1" rowspan="1">&lt;drop&gt;</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">ECT(0)</td>
                <td align="center" colspan="1" rowspan="1">ECT(0)</td>
                <td align="center" colspan="1" rowspan="1">ECT(0)</td>
                <td align="center" colspan="1" rowspan="1">ECT(1)</td>
                <td align="center" colspan="1" rowspan="1">CE</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">ECT(1)</td>
                <td align="center" colspan="1" rowspan="1">ECT(1)</td>
                <td align="center" colspan="1" rowspan="1">ECT(1)(*)</td>
                <td align="center" colspan="1" rowspan="1">ECT(1)</td>
                <td align="center" colspan="1" rowspan="1">CE</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">CE</td>
                <td align="center" colspan="1" rowspan="1">CE</td>
                <td align="center" colspan="1" rowspan="1">CE</td>
                <td align="center" colspan="1" rowspan="1">CE(*)</td>
                <td align="center" colspan="1" rowspan="1">CE</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-3.3.2-6">
   An asterisk in <xref target="egress-ecn" format="default" sectionFormat="of" derivedContent="Table 3"/> indicates a combination that is
   currently unused in all variants of ECN marking (see <xref target="sect-4" format="default" sectionFormat="of" derivedContent="Section 4"/>) and
   therefore <bcp14>SHOULD</bcp14> be logged.</t>
          <t indent="0" pn="section-3.3.2-7">
   With one exception, the mappings in <xref target="egress-ecn" format="default" sectionFormat="of" derivedContent="Table 3"/> are consistent with those for
   IP-in-IP tunnels <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>, which ensures backward
   compatibility with all current and past variants of ECN marking (see <xref target="sect-4" format="default" sectionFormat="of" derivedContent="Section 4"/>). It also ensures forward compatibility with any future
   form of ECN marking that complies with the guidelines in <xref target="RFC9599" format="default" sectionFormat="of" derivedContent="RFC9599"/>, including cases where
   ECT(1) represents a second level of marking severity below CE.</t>
          <t indent="0" pn="section-3.3.2-8">
   The one exception is that the drop condition in <xref target="egress-ecn" format="default" sectionFormat="of" derivedContent="Table 3"/> need not be
   logged because, with TRILL, it is the result of a valid combination
   of events.</t>
        </section>
      </section>
    </section>
    <section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-trill-support-for-ecn-varia">TRILL Support for ECN Variants</name>
      <t indent="0" pn="section-4-1">
   This section is informative, not normative; it discusses interworking
   between TRILL and variants of the standardized form of ECN in IP
   <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>. See also <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/>.</t>
      <t indent="0" pn="section-4-2">
   The ECN wire protocol for TRILL (<xref target="sect-2" format="default" sectionFormat="of" derivedContent="Section 2"/>)
   and the ingress (<xref target="sect-3.1" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) and egress
   (<xref target="sect-3.3" format="default" sectionFormat="of" derivedContent="Section 3.3"/>) ECN behaviors have been
   designed to
   support the other known variants of ECN as detailed below. New
   variants of ECN will have to comply with the guidelines for defining
   alternative ECN semantics <xref target="RFC4774" format="default" sectionFormat="of" derivedContent="RFC4774"/>. It is expected that the TRILL
   ECN wire protocol is generic enough to support such potential future
   variants.</t>
      <section anchor="sect-4.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-pre-congestion-notification">Pre-Congestion Notification (PCN)</name>
        <t indent="0" pn="section-4.1-1">
   The PCN wire protocol <xref target="RFC6660" format="default" sectionFormat="of" derivedContent="RFC6660"/> is
   recognized by the use of a
   PCN-compatible Diffserv codepoint in the IP header and a nonzero IP-ECN
   field. For TRILL or any lower-layer protocol, equivalent
   traffic-classification codepoints would have to be defined, but that is
   outside the
   scope of this document.</t>
        <t indent="0" pn="section-4.1-2">
   The PCN wire protocol is similar to ECN, except it indicates
   congestion with two levels of severity. It uses:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-3">
          <li pn="section-4.1-3.1">11 (CE) as the most severe, termed the Excess-Traffic-Marked (ETM)
     codepoint</li>
          <li pn="section-4.1-3.2">01 ECT(1) as a lesser severity level, termed the Threshold-Marked
     (ThM) codepoint. This difference between ECT(1) and ECT(0) only
     applies to PCN, not to the classic ECN support specified for TRILL
     in this document before <xref target="sect-4" format="default" sectionFormat="of" derivedContent="Section 4"/>.</li>
        </ul>
        <t indent="0" pn="section-4.1-4">
   To implement PCN on a transit RBridge would require a detailed
   specification. In brief:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-5">
          <li pn="section-4.1-5.1">the TRILL CCE flag would be used
     for the Excess-Traffic-Marked (ETM) codepoint;</li>
          <li pn="section-4.1-5.2">ECT(1) in the TRILL-ECN field would be used for the Threshold-Marked
     codepoint.</li>
        </ul>
        <t indent="0" pn="section-4.1-6">
   Then, the ingress and egress behaviors defined in <xref target="sect-3" format="default" sectionFormat="of" derivedContent="Section 3"/> would not
   need to be altered to ensure support for PCN as well as ECN.</t>
      </section>
      <section anchor="sect-4.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-low-latency-low-loss-and-sc">Low Latency, Low Loss, and Scalable Throughput (L4S)</name>
        <t indent="0" pn="section-4.2-1">
   L4S is currently on the IETF's experimental track. An outline of how
   a transit TRILL RBridge would support L4S <xref target="RFC9331" format="default" sectionFormat="of" derivedContent="RFC9331"/> is given in
   <xref target="sect-a" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
      </section>
    </section>
    <section anchor="sect-5" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">
   IANA has updated the "TRILL Extended Header Flags" registry
   by replacing the lines for bits 9-13 and 21-26 with the
   following:</t>
      <table anchor="iana" align="center" pn="table-4">
        <name slugifiedName="name-updated-trill-extended-head">Updated "TRILL Extended Header Flags" Registry</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Bits</th>
            <th align="left" colspan="1" rowspan="1">Purpose</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">9-11</td>
            <td align="left" colspan="1" rowspan="1">available non-critical hop-by-hop flags</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7179" format="default" sectionFormat="of" derivedContent="RFC7179"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">12-13</td>
            <td align="left" colspan="1" rowspan="1">TRILL-ECN (Explicit Congestion Notification)</td>
            <td align="left" colspan="1" rowspan="1">RFC 9600</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">21-25</td>
            <td align="left" colspan="1" rowspan="1">available critical ingress-to-egress flags</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7179" format="default" sectionFormat="of" derivedContent="RFC7179"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">26</td>
            <td align="left" colspan="1" rowspan="1">Critical Congestion Experienced (CCE)</td>
            <td align="left" colspan="1" rowspan="1">RFC 9600</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="sect-6" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">
   TRILL support of ECN is a straightforward combination of previously
   specified ECN and TRILL with no significant new security
   considerations.</t>
      <t indent="0" pn="section-6-2">
For general security considerations regarding adding ECN to lower layer protocols, see <xref target="RFC9599" format="default" sectionFormat="of" derivedContent="RFC9599"/> and <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/>.</t>
      <t indent="0" pn="section-6-3">
For general TRILL protocol security considerations, see <xref target="RFC6325" format="default" sectionFormat="of" derivedContent="RFC6325"/>.</t>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.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="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="RFC6325" target="https://www.rfc-editor.org/info/rfc6325" quoteTitle="true" derivedAnchor="RFC6325">
          <front>
            <title>Routing Bridges (RBridges): Base Protocol Specification</title>
            <author fullname="R. Perlman" initials="R." surname="Perlman"/>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="D. Dutt" initials="D." surname="Dutt"/>
            <author fullname="S. Gai" initials="S." surname="Gai"/>
            <author fullname="A. Ghanwani" initials="A." surname="Ghanwani"/>
            <date month="July" year="2011"/>
            <abstract>
              <t indent="0">Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.</t>
              <t indent="0">RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.</t>
              <t indent="0">The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6325"/>
          <seriesInfo name="DOI" value="10.17487/RFC6325"/>
        </reference>
        <reference anchor="RFC7179" target="https://www.rfc-editor.org/info/rfc7179" quoteTitle="true" derivedAnchor="RFC7179">
          <front>
            <title>Transparent Interconnection of Lots of Links (TRILL): Header Extension</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="A. Ghanwani" initials="A." surname="Ghanwani"/>
            <author fullname="V. Manral" initials="V." surname="Manral"/>
            <author fullname="Y. Li" initials="Y." surname="Li"/>
            <author fullname="C. Bestler" initials="C." surname="Bestler"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7179"/>
          <seriesInfo name="DOI" value="10.17487/RFC7179"/>
        </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="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="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="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="RFC9599" target="https://www.rfc-editor.org/info/rfc9599" quoteTitle="true" derivedAnchor="RFC9599">
          <front>
            <title>Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP</title>
            <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
              <organization showOnFrontPage="true">Independent</organization>
            </author>
            <author initials="J." surname="Kaippallimalil" fullname="John Kaippallimalil">
              <organization showOnFrontPage="true">Futurewei</organization>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="RFC" value="9599"/>
          <seriesInfo name="DOI" value="10.17487/RFC9599"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="IANAthFlags" target="http://www.iana.org/assignments/trill-parameters/" quoteTitle="true" derivedAnchor="IANAthFlags">
          <front>
            <title>TRILL Extended Header Flags</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </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="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="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>
      </references>
    </references>
    <section anchor="sect-a" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-trill-transit-rbridge-behav">TRILL Transit RBridge Behavior to Support L4S</name>
      <t indent="0" pn="section-appendix.a-1">
   The specification of the Low Latency, Low Loss, and Scalable throughput (L4S) wire protocol for IP is given in <xref target="RFC9331" format="default" sectionFormat="of" derivedContent="RFC9331"/>. L4S is one example
   of the ways TRILL ECN handling may evolve <xref target="RFC8311" format="default" sectionFormat="of" derivedContent="RFC8311"/>. It is similar to
   the original ECN wire protocol for IP <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>, except:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a-2">
        <li pn="section-appendix.a-2.1">An AQM that supports L4S classifies packets with ECT(1) or CE in
     the IP header into an L4S queue and a "Classic" queue otherwise.</li>
        <li pn="section-appendix.a-2.2">The meaning of CE markings applied by an L4S queue is not the same
     as the meaning of a drop by a "Classic" queue (contrary to the
     original requirement for ECN <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/>). Instead, the likelihood
     that the Classic queue drops packets is defined as the square of
     the likelihood that the L4S queue marks packets -- e.g., when there
     is a drop probability of 0.0009 (0.09%), the L4S marking
     probability will be 0.03 (3%).</li>
      </ul>
      <t indent="0" pn="section-appendix.a-3">
   This seems to present a problem for the way that a transit TRILL RBridge
   defers the choice between marking and dropping to the egress.  Nonetheless,
   the following pseudocode outlines how a transit TRILL RBridge can implement
   L4S marking in such a way that the egress behavior already described in
   <xref target="sect-3.3" format="default" sectionFormat="of" derivedContent="Section 3.3"/> for Classic ECN <xref target="RFC3168" format="default" sectionFormat="of" derivedContent="RFC3168"/> will
   produce the desired outcome.</t>
      <sourcecode type="pseudocode" markers="false" pn="section-appendix.a-4">
   /* p is an internal variable calculated by any L4S AQM
    *  dependent on the delay being experienced in the Classic queue.
    * bit13 is the least significant bit of the TRILL-ECN field
    */

   % On TRILL transit
   if (bit13 == 0 ) {
         % Classic Queue
         if (p &gt; max(random(), random()) )
            mark(CCE)                         % likelihood: p^2

   } else {
         % L4S Queue
         if (p &gt; random() ) {
            if (p &gt; random() )
               mark(CCE)                      % likelihood: p^2
            else
               mark(NCCE)                     % likelihood: p - p^2
         }
   }
</sourcecode>
      <t indent="0" pn="section-appendix.a-5">
   With the above transit behavior, an egress that supports ECN (<xref target="sect-3.3" format="default" sectionFormat="of" derivedContent="Section 3.3"/>) will drop packets or propagate their ECN markings
   depending on whether the arriving inner header is from an ECN-capable or not ECN-capable transport.</t>
      <t indent="0" pn="section-appendix.a-6">
   Even if an egress has no L4S-specific logic of its own, it will drop
   packets with the square of the probability that an egress would if it
   did support ECN, for the following reasons:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a-7">
        <li pn="section-appendix.a-7.1">
          <t indent="0" pn="section-appendix.a-7.1.1">Egress with ECN support:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a-7.1.2">
            <li pn="section-appendix.a-7.1.2.1">
              <t indent="0" pn="section-appendix.a-7.1.2.1.1">L4S: Propagates both the Critical and Non-Critical CE marks
        (CCE and NCCE) as a CE mark.</t>
              <t indent="0" pn="section-appendix.a-7.1.2.1.2">
	Likelihood: p<sup>2</sup> + p - p<sup>2</sup> = p
              </t>
            </li>
            <li pn="section-appendix.a-7.1.2.2">
              <t indent="0" pn="section-appendix.a-7.1.2.2.1">Classic: Propagates CCE marks as CE or drop, depending on
        the inner header.</t>
              <t indent="0" pn="section-appendix.a-7.1.2.2.2">
	Likelihood: p<sup>2</sup>
              </t>
            </li>
          </ul>
        </li>
        <li pn="section-appendix.a-7.2">
          <t indent="0" pn="section-appendix.a-7.2.1">Egress without ECN support:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a-7.2.2">
            <li pn="section-appendix.a-7.2.2.1">
              <t indent="0" pn="section-appendix.a-7.2.2.1.1">L4S: Does not propagate NCCE as a CE mark, but drops CCE marks.</t>
              <t indent="0" pn="section-appendix.a-7.2.2.1.2">
	Likelihood: p<sup>2</sup>
              </t>
            </li>
            <li pn="section-appendix.a-7.2.2.2">
              <t indent="0" pn="section-appendix.a-7.2.2.2.1">Classic: Drops CCE marks.</t>
              <t indent="0" pn="section-appendix.a-7.2.2.2.2">
	Likelihood: p<sup>2</sup>
              </t>
            </li>
          </ul>
        </li>
      </ul>
    </section>
    <section anchor="sect-7" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">
   The helpful comments of <contact fullname="Loa Andersson"/> and <contact fullname="Adam Roach"/> are hereby
   acknowledged.</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 initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake, 3rd">
        <organization showOnFrontPage="true">Independent</organization>
        <address>
          <postal>
            <street>2386 Panoramic Circle</street>
            <city>Apopka</city>
            <region>FL</region>
            <code>32703</code>
            <country>United States of America</country>
          </postal>
          <phone>+1-508-333-2270</phone>
          <email>d3e3e3@gmail.com</email>
        </address>
      </author>
      <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
        <organization showOnFrontPage="true">Independent</organization>
        <address>
          <postal>
            <country>United Kingdom</country>
          </postal>
          <email>ietf@bobbriscoe.net</email>
          <uri>http://bobbriscoe.net/</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
