rfc9600xml2.original.xml   rfc9600.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!DOCTYPE rfc [
C.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC3168 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY zwsp "&#8203;">
C.3168.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC4774 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY wj "&#8288;">
C.4774.xml">
<!ENTITY RFC6325 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6325.xml">
<!ENTITY RFC7179 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7179.xml">
<!ENTITY RFC7567 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7567.xml">
<!ENTITY RFC7780 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7780.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8311 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8311.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-encap-guidelines SYSTEM "https://xml2rfc.ietf.org/pu
blic/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-encap-guidelines SYSTEM "https://xml2rfc.ietf.org/pu
blic/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-l4s-id SYSTEM "https://xml2rfc.ietf.org/public/rfc/b
ibxml3/reference.I-D.ietf-tsvwg-ecn-l4s-id.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-l4s-id SYSTEM "https://xml2rfc.ietf.org/public/rfc/b
ibxml3/reference.I-D.ietf-tsvwg-ecn-l4s-id.xml">
<!ENTITY RFC6040 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6040.xml">
<!ENTITY RFC6660 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6660.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-trill-ecn-support-07" category="s
td" ipr="trust200902"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<!-- Generated by id2xml 1.5.0 on 2020-06-08T19:55:39Z --> category="std" consensus="true" docName="draft-ietf-trill-ecn-support-07"
<?rfc strict="yes"?> number="9600" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
<?rfc compact="yes"?> symRefs="true" sortRefs="true" tocInclude="true" version="3">
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc text-list-symbols="o+*-"?>
<?rfc toc="yes"?>
<front> <front>
<title abbrev="TRILL ECN Support">TRILL (TRansparent Interconnection of L <title abbrev="TRILL ECN Support">TRansparent Interconnection of Lots of Lin
ots of Links): ECN (Explicit Congestion Notification) Support</title> ks (TRILL): Explicit Congestion Notification (ECN) Support</title>
<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake, 3r <seriesInfo name="RFC" value="9600"/>
d"> <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake, 3
<organization abbrev="Huawei">Huawei Technologies</organization> rd">
<address><postal><street>155 Beaver Street</street> <organization>Independent</organization>
<city>Milford</city><region>MA</region><code>01757</code><country>USA</co <address>
untry> <postal>
</postal> <street>2386 Panoramic Circle</street>
<phone>+1-508-333-2270</phone> <city>Apopka</city>
<email>d3e3e3@gmail.com</email> <region>FL</region>
</address> <code>32703</code>
</author> <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>Independent</organization>
<address>
<postal>
<country>United Kingdom</country>
</postal>
<email>ietf@bobbriscoe.net</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<date year="2024" month="August"/>
<area>RTG</area>
<workgroup>TRILL</workgroup>
<author initials="B." surname="Briscoe" fullname="Bob Briscoe"> <keyword>example</keyword>
<organization>CableLabs</organization>
<address><postal>
<street></street><city></city> <region></region><code></code>
<country>UK</country>
</postal>
<email>ietf@bobbriscoe.net</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<date year="2020" month="June"/> <abstract>
<workgroup>TRILL Working Group</workgroup> <t>
<abstract><t> Explicit Congestion Notification (ECN) allows a forwarding element to
Explicit congestion notification (ECN) allows a forwarding element to
notify downstream devices, including the destination, of the onset of notify downstream devices, including the destination, of the onset of
congestion without having to drop packets. This can improve network congestion without having to drop packets. This can improve network
efficiency through better congestion control without packet drops. efficiency through better congestion control without packet drops.
This document extends ECN to TRILL (TRansparent Interconnection of This document extends ECN to TRansparent Interconnection of
Lots of Links) switches, including integration with IP ECN, and Lots of Links (TRILL) switches, including integration with IP ECN, and
provides for ECN marking in the TRILL Header Extension Flags Word provides for ECN marking in the TRILL header extension flags word
(see RFC 7179).</t> (RFC 7179).</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
Explicit congestion notification (ECN <xref target="RFC3168"/> <xref Explicit Congestion Notification (ECN) <xref target="RFC3168"
target="RFC8311"/>) allows a forwarding element (such as a router) to format="default"/> <xref target="RFC8311" format="default"/> allows a
forwarding element (such as a router) to
notify downstream devices, including the destination, of the onset of notify downstream devices, including the destination, of the onset of
congestion without having to drop packets. This can improve network congestion without having to drop packets. This can improve network
efficiency through better congestion control without packet drops. The efficiency through better congestion control without packet drops. The
forwarding element can explicitly mark a proportion of packets in an ECN forwarding element can explicitly mark a proportion of packets in an ECN
field instead of dropping the packet. For example, a two-bit field is field instead of dropping packets. For example, a 2-bit field is
available for ECN marking in IP headers.</t> available for ECN marking in IP headers.</t>
<figure anchor="fig-1">
<figure title="Example Path Forwarding Nodes" anchor="fig-1"> <name>Example Path-Forwarding Nodes</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
............................. .............................
. . . .
+---------+ . +---------+ .
+------+ | Ingress | . +------+ | Ingress | .
|Source| +->| RBridge | . +----------+ |Source| +->| RBridge | . +----------+
+---+--+ | | RB1 | . |Forwarding| +---+--+ | | RB1 | . |Forwarding|
| | +------+--+ +----------+ . | Element | | | +------+--+ +----------+ . | Element |
v | . | | Transit | . | Y | v | . | | Transit | . | Y |
+-------+--+ . +---->| RBridges | . +--------+-+ +-------+--+ . +---->| RBridges | . +--------+-+
|Forwarding| . | RBn | . ^ | |Forwarding| . | RBn | . ^ |
| Element | . +-------+--+ +---------+ | v | Element | . +-------+--+ +---------+ | v
| X | . | | Egress | | +-----------+ | X | . | | Egress | | +-----------+
+----------+ . +---->| RBridge +-+ |Destination| +----------+ . +---->| RBridge +-+ |Destination|
. | RB9 | +-----------+ . | RB9 | +-----------+
. TRILL +---------+ . TRILL +---------+
. campus . . campus .
............................. .............................
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In <xref target="RFC3168"/>, it was recognized that tunnels and lower layer In <xref target="RFC3168" format="default"/>, it was recognized that tunnels
and lower-layer
protocols would need to support ECN, and ECN markings would need to protocols would need to support ECN, and ECN markings would need to
be propagated, as headers were encapsulated and decapsulated. be propagated, as headers were encapsulated and decapsulated.
<xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/> gives guidelines on the <xref target="RFC9599" format="default"/> gives guidelines on the addition of
addition of ECN to protocols ECN to protocols
like TRILL (TRansparent Interconnection of Lots of Links) that often like TRILL that often
encapsulate IP packets, including propagation of ECN from and to IP.</t> encapsulate IP packets, including propagation of ECN from and to IP.</t>
<t>
<t> In <xref target="fig-1"/>, assuming IP traffic, RB1 is an encapsulator and
In the figure above, assuming IP traffic, RB1 is an encapsulator and RB9 is a decapsulator. Traffic from Source to RB1 might or might not get
RB9 a decapsulator. Traffic from Source to RB1 might or might not get
marked as having experienced congestion in forwarding elements, such marked as having experienced congestion in forwarding elements, such
as X, before being encapsulated at ingress RB1. Any such ECN marking as X, before being encapsulated at ingress RB1. Any such ECN marking
is encapsulated with a TRILL Header <xref target="RFC6325"/>.</t> is encapsulated with a TRILL header <xref target="RFC6325" format="default"/>
.</t>
<t> <t>
This document specifies how ECN marking in traffic at the ingress is This document specifies how ECN marking in traffic at the ingress is
copied into the TRILL Extension Header Flags Word and requires such copied into the TRILL extension header flags word and requires such
copying for IP traffic. It also enables congestion marking by a copying for IP traffic. It also enables congestion marking by a
congested RBridge such as RBn or RB1 above in the TRILL Header congested RBridge (such as RBn or RB1 above) in the TRILL header
Extension Flags Word <xref target="RFC7179"/>.</t> extension flags word <xref target="RFC7179" format="default"/>.</t>
<t>
<t>
At RB9, the TRILL egress, it specifies how any ECN markings in the At RB9, the TRILL egress, it specifies how any ECN markings in the
TRILL Header Flags Word and in the encapsulated traffic are combined TRILL header flags word and in the encapsulated traffic are combined
so that subsequent forwarding elements, such as Y and the so that subsequent forwarding elements, such as Y and the
Destination, can see if congestion was experienced at any previous Destination, can see if congestion was experienced at any previous
point in the path from Source.</t> point in the path from the Source.</t>
<t>
<t> A large part of the guidelines for adding ECN to lower-layer
A large part of the guidelines for adding ECN to lower layer protocols <xref target="RFC9599" format="default"/> concerns safe propagation
protocols <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/> concerns safe of congestion
propagation of congestion
notifications in scenarios where some of the nodes do not support or notifications in scenarios where some of the nodes do not support or
understand ECN. Such ECN ignorance is not a major problem with understand ECN. Such ECN ignorance is not a major problem with
RBridges using this specification because the method specified RBridges using this specification, because the method specified
assures that, if an egress RBridge is ECN ignorant (so it cannot assures that, if an egress RBridge is ECN ignorant (so it cannot
further propagate ECN) and congestion has been encountered, the further propagate ECN) and congestion has been encountered, the
egress RBridge will at least drop the packet and this drop will egress RBridge will at least drop the packet, and this drop will
itself indicate congestion to end stations.</t> itself indicate congestion to end stations.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<section title="Conventions used in this document" anchor="sect-1.1"><t> <name>Conventions Used in This Document</name>
The terminology and acronyms defined in <xref target="RFC6325"/> are used her <t>
ein The terminology and acronyms defined in <xref target="RFC6325"
with the same meaning.</t> format="default"/> are used herein with the same meaning.</t>
<t>
<t>
In this documents, "IP" refers to both IPv4 and IPv6.</t> In this documents, "IP" refers to both IPv4 and IPv6.</t>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in <xref target="RFC2119"/> <xref NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
target="RFC8174"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
<t>Acronyms: described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<list> when, and only when, they appear in all capitals, as shown here.
<t>AQM - Active Queue Management</t> </t>
<t>CCE - Critical Congestion Experienced</t>
<t>CE - Congestion Experienced</t>
<t>CItE - Critical Ingress-to-Egress</t>
<t>ECN - Explicit Congestion Notification</t>
<t>ECT - ECN Capable Transport</t>
<t>L4S - Low Latency, Low Loss, Scalable throughput</t>
<t>NCHbH - Non-Critical Hop-by-Hop</t>
<t>NCCE - Non-Critical Congestion Experienced</t>
<t>Not-ECT - Not ECN-Capable Transport</t>
<t>PCN - Pre-Congestion Notification</t>
</list>
</t>
</section>
</section>
<section title="The ECN Specific Extended Header Flags" anchor="sect-2"><
t>
The extension header fields for explicit congestion notification
(ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit
Critical Congestion Experienced (CCE) field in the 32-bit TRILL
Header Extension Flags Word <xref target="RFC7780"/>.</t>
<t>
These fields are shown in Figure 2 as "ECN" and "CCE". The TRILL-ECN field
consists of bits 12 and 13, which are in the range reserved for
non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 26,
which is in the range reserved for Critical Ingress-to-Egress (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
Figure 2 are not relevant to ECN. See <xref target="RFC7780"/>, <xref
target="RFC7179"/>, and <xref target="IANAthFlags"/> for the meaning of
these other bits and fields.</t>
<figure title="The TRILL-ECN and CCE TRILL Header Extension Flags Word Fi
elds"
anchor="fig-2">
<artwork><![CDATA[
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| | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Abbreviations:</t>
<dl>
<dt>AQM:</dt><dd>Active Queue Management</dd>
<dt>CCE:</dt><dd>Critical Congestion Experienced</dd>
<dt>CE:</dt><dd>Congestion Experienced</dd>
<dt>CItE:</dt><dd>Critical Ingress-to-Egress</dd>
<dt>ECN:</dt><dd>Explicit Congestion Notification</dd>
<dt>ECT:</dt><dd>ECN-Capable Transport</dd>
<dt>L4S:</dt><dd>Low Latency, Low Loss, and Scalable throughput</dd>
<dt>NCHbH:</dt><dd>Non-Critical Hop-by-Hop</dd>
<dt>NCCE:</dt><dd>Non-Critical Congestion Experienced</dd>
<dt>Not-ECT:</dt><dd>Not ECN-Capable Transport</dd>
<dt>PCN:</dt><dd>Pre-Congestion Notification</dd>
</dl>
</section>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>The ECN-Specific Extended Header Flags</name>
<t>
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"/>.</t>
<t>
These fields are shown in <xref target="fig-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"/> are
not relevant to ECN. See <xref target="RFC7780" format="default"/>, <xref
target="RFC7179" format="default"/>, and <xref target="IANAthFlags"
format="default"/> for the meaning of these other bits and fields.</t>
<figure anchor="fig-2">
<name>The TRILL-ECN and CCE TRILL Header Extension Flags Word Fields</na
me>
<artwork name="" type="" align="left" alt=""><![CDATA[
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> ]]></artwork>
</figure> </figure>
<t>
<t> <xref target="codepoints"/> shows the meaning of the codepoints in the
Table 1 shows the meaning of the codepoints in the TRILL-ECN field. TRILL-ECN field. The first three have the same meaning as the
The first three have the same meaning as the corresponding ECN field corresponding ECN field codepoints in the IP header, as defined in <xref
codepoints in the IP header as defined in [RFC3168]. However, target="RFC3168"/>. However, codepoint 0b11 is called NCEE to distinguish
codepoint 0b11 is called Non-Critical Congestion Experienced (NCCE) it from CE in IP.</t>
to distinguish it from Congestion Experienced in IP.</t>
<!-- [rfced] Please review the figure below. It is a table in the original draft
-->
<figure title="TRILL-ECN Field Codepoints" anchor="fig-3"> <table anchor="codepoints">
<name>TRILL-ECN Field Codepoints</name>
<thead>
<tr>
<th>Binary</th>
<th>Name</th>
<th>Meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">00</td>
<td>Not-ECT</td>
<td>Not ECN-Capable Transport </td>
</tr>
<tr>
<td align="center">01</td>
<td>ECT(1)</td>
<td>ECN-Capable Transport (1)</td>
</tr>
<tr>
<td align="center">10</td>
<td>ECT(0)</td>
<td>ECN-Capable Transport (0)</td>
</tr>
<tr>
<td align="center">11</td>
<td>NCCE</td>
<td>Non-Critical Congestion Experienced</td>
</tr>
<artwork><![CDATA[ </tbody>
Binary Name Meaning </table>
------ ------- -----------------------------------
00 Not-ECT Not ECN-Capable Transport
01 ECT(1) ECN-Capable Transport (1)
10 ECT(0) ECN-Capable Transport (0)
11 NCCE Non-Critical Congestion Experienced
]]></artwork>
</figure>
</section>
<section title="ECN Support" anchor="sect-3"><t> </section>
<section anchor="sect-3" numbered="true" toc="default">
<name>ECN Support</name>
<t>
This section specifies interworking between TRILL and the original This section specifies interworking between TRILL and the original
standardized form of ECN in IP <xref target="RFC3168"/>.</t> standardized form of ECN in IP <xref target="RFC3168" format="default"/>.</t>
<t>
<t>
The subsections below describe the required behavior to support ECN The subsections below describe the required behavior to support ECN
at TRILL ingress, transit, and egress. The ingress behavior occurs as at TRILL ingress, transit, and egress. The ingress behavior occurs as
a native frame is encapsulated with a TRILL Header to produce a TRILL 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 packet. The transit behavior occurs in all RBridges where TRILL
Data packets are queued, usually at the output port. The egress Data packets are queued, usually at the output port (including the output por t of the TRILL ingress). The egress
behavior occurs where a TRILL Data packet is decapsulated and output behavior occurs where a TRILL Data packet is decapsulated and output
as a native frame through an RBridge port.</t> as a native frame through an RBridge port.</t>
<t>
<t> An RBridge that supports ECN <bcp14>MUST</bcp14> behave as described in the r
An RBridge that supports ECN MUST behave as described in the relevant elevant
subsections below, which correspond to the recommended provisions in subsections below, which correspond to the recommended provisions in
<xref target="sect-3"/> and Sections 5.1-5.4 of <xref target="I-D.ietf-tsvwg- <xref target="sect-3" format="default"/> of this document and Sections <xref
ecn-encap-guidelines"/>. Nonetheless, the target="RFC9599" sectionFormat="bare"
section="4.2"/> through <xref target="RFC9599"
sectionFormat="bare" section="4.4"/> of <xref
target="RFC9599"/>. Nonetheless, the
scheme is designed to safely propagate some form of congestion scheme is designed to safely propagate some form of congestion
notification even if some RBridges in the path followed by a TRILL notification even if some RBridges in the path followed by a TRILL
Data packet support ECN and others do not.</t> Data packet support ECN and others do not.</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<section title="Ingress ECN Support" anchor="sect-3.1"><t> <name>Ingress ECN Support</name>
<t>
The behavior at an ingress RBridge is as follows:</t> The behavior at an ingress RBridge is as follows:</t>
<ul spacing="normal">
<t><list style="symbols"><t>When encapsulating an IP frame, the ingress R <li>
Bridge MUST:<list style="symbols"><?rfc subcompact="yes"?> <t>When encapsulating an IP frame, the ingress RBridge <bcp14>MUST</
<t>set the F flag in the main TRILL header <xref target="RFC7780"/>;</t> bcp14>:</t>
<ul spacing="normal">
<t>create a Flags Word as part of the TRILL Header;</t> <li>set the F flag in the main TRILL header <xref target="RFC7780"
format="default"/>;</li>
<t>copy the two ECN bits from the IP header into the TRILL-ECN <li>create a flags word as part of the TRILL header;</li>
field (Flags Word bits 12 and 13)</t> <li>copy the two ECN bits from the IP header into the TRILL-ECN
field (flags word bits 12 and 13); and</li>
<t>ensure the CCE flag is set to zero (Flags Word bit 26).</t> <li>ensure the CCE flag is set to zero (flags word bit 26).</li>
</ul>
<?rfc subcompact="no"?> </li>
</list> <li>When encapsulating a frame for a non-IP protocol (where that
</t> protocol has a means of indicating that ECN is understood by the
ingress RBridge), the ingress RBridge <bcp14>MUST</bcp14> follow the g
<t>When encapsulating a frame for a non-IP protocol, where that uidelines in
protocol has a means of indicating ECN that is understood by the <xref target="RFC9599" sectionFormat="of" section="4.3"/> to add a
ingress RBridge, it MUST follow the guidelines in Section 5.3 of flags word to the TRILL header. For a non-IP protocol with an ECN
<xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/> to add a Flags Word t field similar to IP, this would be achieved by copying into the
o the TRILL Header. For a TRILL-ECN field from the encapsulated native frame.</li>
non-IP protocol with a similar ECN field to IP, this would be </ul>
achieved by copying into the TRILL-ECN field from the encapsulated </section>
native frame.</t> <section anchor="sect-3.2" numbered="true" toc="default">
<name>Transit ECN Support</name>
</list> <t>
</t>
</section>
<section title="Transit ECN Support" anchor="sect-3.2"><t>
The transit behavior, shown below, is required at all RBridges where The transit behavior, shown below, is required at all RBridges where
TRILL Data packets are queued, usually at the output port.</t> TRILL Data packets are queued, usually at the output port.</t>
<ul spacing="normal">
<t><list style="symbols"><t>An RBridge that supports ECN MUST implement s <li>An RBridge that supports ECN <bcp14>MUST</bcp14> implement some fo
ome form of active rm of AQM according to the guidelines of <xref target="RFC7567" format="default"
queue management (AQM) according to the guidelines of <xref target="RFC756 />.
7"/>.
The RBridge detects congestion either by monitoring its own queue The RBridge detects congestion either by monitoring its own queue
depth or by participating in a link-specific protocol.</t> depth or by participating in a link-specific protocol.</li>
<li>If the TRILL header flags word is present, whenever the AQM
<t>If the TRILL Header Flags Word is present, whenever the AQM algorithm decides to indicate critical congestion on a TRILL Data packet,
algorithm decides to indicate congestion on a TRILL Data packet it it
MUST set the CCE flag (Flags Word bit 26).</t> <bcp14>MUST</bcp14> set the CCE flag (flags word bit 26). Note that Classi
c ECN marking <xref target="RFC3168"/> only uses critical congestion indications
<t>If the TRILL header Flags Word is not present, to indicate , but the two variants in <xref target="sect-4.1"/> use a combination of critica
congestion the RBridge will either drop the packet or it MAY do l and non-critical congestion indications.</li>
all of the following instead:<list style="symbols"><t>set the F flag in th <li>
e main TRILL header;</t> <t>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
<t>add a Flags Word to the TRILL Header;</t> following instead to indicate congestion:</t>
<ul spacing="normal">
<t>set the TRILL-ECN field to Not-ECT (00);</t> <li>set the F flag in the main TRILL header;</li>
<li>add a flags word to the TRILL header;</li>
<t>and set the CCE flag and the Ingress-to-Egress critical summary <li>set the TRILL-ECN field to Not-ECT (00); and</li>
bit (CRIbE).</t> <li>set the CCE flag and the critical Ingress-to-Egress summary bi
t (CRItE).</li>
</list> </ul>
</t> </li>
</ul>
</list> <t>
</t>
<t>
Note that a transit RBridge that supports ECN does not refer to the 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 TRILL-ECN field before signaling CCE in a packet. It signals CCE
irrespective of whether the packet indicates that the transport is irrespective of whether the packet indicates that the transport is ECN
ECN-capable. The egress/decapsulation behavior (described next) capable. The egress/decapsulation behavior ensures that a CCE indication is
ensures that a CCE indication is converted to a drop if the transport converted to a drop if the transport is not ECN capable.</t>
is not ECN-capable.</t> </section>
<section anchor="sect-3.3" numbered="true" toc="default">
</section> <name>Egress ECN Support</name>
<section anchor="sect-3.3.1" numbered="true" toc="default">
<section title="Egress ECN Support" anchor="sect-3.3"><section title="Non <name>Non-ECN Egress RBridges</name>
-ECN Egress RBridges" anchor="sect-3.3.1"><t> <t>
If the egress RBridge does not support ECN, that RBridge will ignore 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 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 contain any special ECN logic. Nonetheless, if a transit RBridge has
set the CCE flag, the egress will drop the packet. This is because set the CCE flag, the egress will drop the packet. This is because
drop is the default behavior for an RBridge decapsulating a Critical drop is the default behavior for an RBridge decapsulating a CItE flag when it
Ingress-to-Egress flag when it has no specific logic to understand has no specific logic to understand
it. Drop is the intended behavior for such a packet, as required by it.
Section 5.4 of <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>.</t> Drop is the intended behavior for such a packet, as required by
<xref target="RFC9599"
</section> sectionFormat="of" section="4.4"/>.</t>
</section>
<section title="ECN Egress RBridges" anchor="sect-3.3.2"><t> <section anchor="sect-3.3.2" numbered="true" toc="default">
<name>ECN Egress RBridges</name>
<t>
If an RBridge supports ECN, for the two cases of an IP and a non-IP If an RBridge supports ECN, for the two cases of an IP and a non-IP
inner packet, the egress behavior is as follows: inner packet, the egress behavior is as follows:
<list style="hanging" hangIndent="3"> </t>
<t hangText="Decapsulating an inner IP packet:"> The RBridge sets the <dl newline="false" spacing="normal" indent="3">
ECN field of the outgoing native IP packet using Table 3. It MUST set <dt>Decapsulating an inner IP packet:</dt>
<dd><t>The RBridge sets the
ECN field of the outgoing native IP packet using <xref
target="egress-ecn"/>. It <bcp14>MUST</bcp14> set
the ECN field of the outgoing IP packet to the codepoint at the 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 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 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 TRILL header. If no TRILL header extension flags word is present, the
3-bit ECN codepoint is assumed to be all zero bits.</t> 3-bit ECN codepoint is assumed to be all zero bits.</t>
<t>The name of the TRILL 3-bit ECN codepoint used in <xref target="e
<t>The name of the TRILL 3-bit ECN codepoint is defined using the gress-ecn"/> is defined using the
combination of the TRILL-ECN and CCE fields in Table 2. Specifically, combination of the TRILL-ECN and CCE fields in <xref target="mapping"/>.
Specifically,
the TRILL 3-bit ECN codepoint is called CE if either NCCE or CCE is set 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 in the TRILL header extension flags word. Otherwise, it has the same name
as the 2-bit TRILL-ECN codepoint.</t> as the 2-bit TRILL-ECN codepoint.</t>
<t>
<t>In the case where the TRILL 3-bit ECN codepoint indicates congestion In the case where the TRILL 3-bit ECN codepoint indicates CE but
experienced (CE) but the encapsulated native IP frame indicates a not the encapsulated native IP frame indicates a Not-ECT, it can be
ECN-capable transport (Not-ECT), it can be seen that the RBridge MUST seen that the RBridge <bcp14>MUST</bcp14> drop the packet. Such
drop the packet. Such packet dropping is necessary because a transport packet dropping is necessary because a transport above the IP
above the IP layer that is not ECN-capable will have no ECN logic, so it layer that is not ECN capable will have no ECN logic, so it will
will only understand dropped packets as an indication of congestion.</t> only understand dropped packets as an indication of
congestion.</t></dd>
</list> </dl>
<dl newline="false" spacing="normal" indent="3">
<list style="hanging" hangIndent="3"> <dt>Decapsulating a non-IP protocol frame:</dt>
<t hangText="Decapsulating a non-IP protocol frame:"> If the frame has <dd>If the frame has
a means of indicating ECN that is understood by the RBridge, it MUST a means of indicating ECN that is understood by the RBridge, it <bcp14>MU
follow the guidelines in Section 5.4 of <xref ST</bcp14>
target="I-D.ietf-tsvwg-ecn-encap-guidelines"/> when setting the ECN follow the guidelines in <xref
target="RFC9599" sectionFormat="of" section="4.4"/> when
setting the ECN
information in the decapsulated native frame. For a non-IP protocol information in the decapsulated native frame. For a non-IP protocol
with a similar ECN field to IP, this would be achieved by combining with an ECN field similar to IP, this would be achieved by combining
the information in the TRILL Header Flags Word with the encapsulated the information in the TRILL header flags word with the encapsulated
non-IP native frame, as specified in Table 3.</t> non-IP native frame, as specified in <xref target="egress-ecn"/>.</dd>
</dl>
</list> <table anchor="mapping" align="center">
</t> <name>Mapping of TRILL-ECN and CCE Fields to the TRILL 3-Bit ECN Cod
epoint Name</name>
<texttable anchor="tab-2" title="Mapping of TRILL-ECN and CCE Fields to t <thead>
he TRILL 3-bit ECN Codepoint Name" style="full"> <tr>
<ttcol> TRILL-ECN </ttcol> <th rowspan ="1" colspan="2">TRILL-ECN</th>
<ttcol> CCE </ttcol> <th rowspan="2">CCE</th>
<ttcol> Arriving TRILL 3-bit ECN codepoint name</ttcol> <th rowspan="2">Arriving TRILL 3-Bit ECN Codepoint Name</th>
<c>Not-ECT 00</c> </tr>
<c>0</c> <tr>
<c>Not-ECT</c> <th>Name</th>
<c>ECT(1) 01</c> <th>Bits</th>
<c>0</c> </tr>
<c>ECT(1)</c> </thead>
<c>ECT(0) 10</c> <tbody>
<c>0</c> <tr>
<c>ECT(0)</c> <td>Not-ECT</td>
<c>NCCE 11</c> <td align="center">00</td>
<c>0</c> <td align="center">0</td>
<c>CE</c> <td>Not-ECT</td>
<c>Not-ECT 00</c> </tr>
<c>1</c> <tr>
<c>CE</c> <td>ECT(1)</td>
<c>ECT(1) 01</c> <td align="center">01</td>
<c>1</c> <td align="center">0</td>
<c>CE</c> <td>ECT(1)</td>
<c>ECT(0) 10</c> </tr>
<c>1</c> <tr>
<c>CE</c> <td>ECT(0)</td>
<c>NCCE 11</c> <td align="center">10</td>
<c>1</c> <td align="center">0</td>
<c>CE</c> <td>ECT(0)</td>
</texttable> </tr>
<tr>
<!-- [rfced] Please review the figure below. It is a table in the original draft <td>NCCE</td>
--> <td align="center">11</td>
<td align="center">0</td>
<td>CE</td>
</tr>
<tr>
<td>Not-ECT</td>
<td align="center">00</td>
<td align="center">1</td>
<td>CE</td>
</tr>
<tr>
<td>ECT(1)</td>
<td align="center">01</td>
<td align="center">1</td>
<td>CE</td>
</tr>
<tr>
<td>ECT(0)</td>
<td align="center">10</td>
<td align="center">1</td>
<td>CE</td>
</tr>
<tr>
<td>NCCE</td>
<td align="center"> 11</td>
<td align="center">1</td>
<td>CE</td>
</tr>
</tbody>
</table>
<figure title="Egress ECN Behavior" anchor="fig-4"> <table anchor="egress-ecn">
<artwork><![CDATA[ <name>Egress ECN Behavior</name>
+---------+----------------------------------------------+ <thead>
| Inner | Arriving TRILL 3-bit ECN Codepoint Name | <tr>
| Native +---------+------------+------------+----------+ <th rowspan="2" align="center">Inner Native Header</th>
| Header | Not-ECT | ECT(0) | ECT(1) | CE | <th colspan="4" align="center">Arriving TRILL 3-Bit ECN Codepoint Name</th
+---------+---------+------------+------------+----------+ >
| Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | <drop> | </tr>
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | <tr>
| ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | <th align="center">Not-ECT</th>
| CE | CE | CE | CE(*) | CE | <th align="center">ECT(0)</th>
+---------+---------+------------+------------+----------+ <th align="center">ECT(1)</th>
]]></artwork> <th align="center">CE</th>
</figure> </tr>
<t> </thead>
An asterisk in the above table indicates a combination that is <tbody>
currently unused in all variants of ECN marking (see <xref target="sect-4"/>) <tr>
and <td align="center">Not-ECT</td>
therefore SHOULD be logged.</t> <td align="center">Not-ECT</td>
<td align="center">Not-ECT(*)</td>
<td align="center">Not-ECT(*)</td>
<td align="center">&lt;drop&gt;</td>
</tr>
<tr>
<td align="center">ECT(0)</td>
<td align="center">ECT(0)</td>
<td align="center">ECT(0)</td>
<td align="center">ECT(1)</td>
<td align="center">CE</td>
</tr>
<tr>
<td align="center">ECT(1)</td>
<td align="center">ECT(1)</td>
<td align="center">ECT(1)(*)</td>
<td align="center">ECT(1)</td>
<td align="center">CE</td>
</tr>
<tr>
<td align="center">CE</td>
<td align="center">CE</td>
<td align="center">CE</td>
<td align="center">CE(*)</td>
<td align="center">CE</td>
</tr>
</tbody>
</table>
<t> <t>
With one exception, the mappings in Table 3 are consistent with those for An asterisk in <xref target="egress-ecn"/> indicates a combination that is
IP-in-IP tunnels <xref target="RFC6040"/>, which ensures backward currently unused in all variants of ECN marking (see <xref target="sect-4" fo
compatibility with all current and past variants of ECN marking (see <xref rmat="default"/>) and
target="sect-4"/>). It also ensures forward compatibility with any future therefore <bcp14>SHOULD</bcp14> be logged.</t>
form of ECN marking that complies with the guidelines in <xref <t>
target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>, including cases where With one exception, the mappings in <xref target="egress-ecn"/> are consisten
t with those for
IP-in-IP tunnels <xref target="RFC6040" format="default"/>, which ensures bac
kward
compatibility with all current and past variants of ECN marking (see <xref ta
rget="sect-4" format="default"/>). It also ensures forward compatibility with an
y future
form of ECN marking that complies with the guidelines in <xref target="RFC959
9" format="default"/>, including cases where
ECT(1) represents a second level of marking severity below CE.</t> ECT(1) represents a second level of marking severity below CE.</t>
<t>
<t> The one exception is that the drop condition in <xref target="egress-ecn"/> n
The one exception is that the drop condition in Table 3 need not be eed not be
logged because, with TRILL, it is the result of a valid combination logged because, with TRILL, it is the result of a valid combination
of events.</t> of events.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-4" numbered="true" toc="default">
<name>TRILL Support for ECN Variants</name>
</section> <t>
<section title="TRILL Support for ECN Variants" anchor="sect-4"><t>
This section is informative, not normative; it discusses interworking This section is informative, not normative; it discusses interworking
between TRILL and variants of the standardized form of ECN in IP between TRILL and variants of the standardized form of ECN in IP
<xref target="RFC3168"/>. See also <xref target="RFC8311"/>.</t> <xref target="RFC3168" format="default"/>. See also <xref target="RFC8311" fo
rmat="default"/>.</t>
<t> <t>
The ECN wire protocol for TRILL (<xref target="sect-2"/>) and the ingress (<x The ECN wire protocol for TRILL (<xref target="sect-2" format="default"/>)
ref target="sect-3.1"/>) and egress (<xref target="sect-3.3"/>) ECN behaviors ha and the ingress (<xref target="sect-3.1" format="default"/>) and egress
ve been designed to (<xref target="sect-3.3" format="default"/>) ECN behaviors have been
support the other known variants of ECN, as detailed below. New 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 variants of ECN will have to comply with the guidelines for defining
alternative ECN semantics <xref target="RFC4774"/>. It is expected that the T RILL alternative ECN semantics <xref target="RFC4774" format="default"/>. It is ex pected that the TRILL
ECN wire protocol is generic enough to support such potential future ECN wire protocol is generic enough to support such potential future
variants.</t> variants.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<section title="Pre-Congestion Notification (PCN)" anchor="sect-4.1"><t> <name>Pre-Congestion Notification (PCN)</name>
The PCN wire protocol <xref target="RFC6660"/> is recognized by the use of a <t>
PCN-compatible Diffserv codepoint in the IP header and a non-zero IP-ECN The PCN wire protocol <xref target="RFC6660" format="default"/> is
field. For TRILL or any lower layer protocol, equivalent traffic recognized by the use of a
classification codepoints would have to be defined, but that is outside the PCN-compatible Diffserv codepoint in the IP header and a nonzero IP-ECN
scope of the current document.</t> field. For TRILL or any lower-layer protocol, equivalent
traffic-classification codepoints would have to be defined, but that is
<t> outside the
scope of this document.</t>
<t>
The PCN wire protocol is similar to ECN, except it indicates The PCN wire protocol is similar to ECN, except it indicates
congestion with two levels of severity. It uses:</t> congestion with two levels of severity. It uses:</t>
<ul spacing="normal">
<t><list style="symbols"><t>11 (CE) as the most severe, termed the Excess <li>11 (CE) as the most severe, termed the Excess-Traffic-Marked (ETM)
-traffic-marked (ETM) codepoint</li>
codepoint</t> <li>01 ECT(1) as a lesser severity level, termed the Threshold-Marked
(ThM) codepoint. This difference between ECT(1) and ECT(0) only
<t>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 applies to PCN, not to the classic ECN support specified for TRILL
in this document before <xref target="sect-4"/>.)</t> in this document before <xref target="sect-4" format="default"/>.</li>
</ul>
</list> <t>
</t>
<t>
To implement PCN on a transit RBridge would require a detailed To implement PCN on a transit RBridge would require a detailed
specification. But in brief:</t> specification. In brief:</t>
<ul spacing="normal">
<t><list style="symbols"><t>the TRILL Critical Congestion Experienced (CC <li>the TRILL CCE flag would be used
E) flag would be used for the Excess-Traffic-Marked (ETM) codepoint;</li>
for the Excess-Traffic-Marked (ETM) codepoint;</t> <li>ECT(1) in the TRILL-ECN field would be used for the Threshold-Mark
ed
<t>ECT(1) in the TRILL-ECN field would be used for the Threshold-Marked codepoint.</li>
codepoint.</t> </ul>
<t>
</list> Then, the ingress and egress behaviors defined in <xref target="sect-3" forma
</t> t="default"/> would not
<t>
Then the ingress and egress behaviors defined in <xref target="sect-3"/> woul
d not
need to be altered to ensure support for PCN as well as ECN.</t> need to be altered to ensure support for PCN as well as ECN.</t>
</section>
</section> <section anchor="sect-4.2" numbered="true" toc="default">
<name>Low Latency, Low Loss, and Scalable Throughput (L4S)</name>
<section title="Low Latency, Low Loss, Scalable Throughput (L4S)" anchor= <t>
"sect-4.2"><t>
L4S is currently on the IETF's experimental track. An outline of how L4S is currently on the IETF's experimental track. An outline of how
a transit TRILL RBridge would support L4S <xref target="I-D.ietf-tsvwg-ecn-l4 a transit TRILL RBridge would support L4S <xref target="RFC9331" format="defa
s-id"/> is given in ult"/> is given in
Appendix A.</t> <xref target="sect-a"/>.</t>
</section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<t>
<section title="IANA Considerations" anchor="sect-5"><t> IANA has updated the "TRILL Extended Header Flags" registry
IANA is requested to update the TRILL Extended Header Flags registry by replacing the lines for bits 9-13 and 21-26 with the
by replacing the lines for bits 9-13 and for bits 21-26 with the
following:</t> following:</t>
<figure><artwork><![CDATA[ <table anchor="iana">
Bits Purpose Reference <name>Updated "TRILL Extended Header Flags" Registry</name>
----- ------- --------- <thead>
9-11 available non-critical hop-by-hop flags <tr>
12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] <th>Bits</th>
<th>Purpose</th>
21-25 available critical ingress-to-egress flags <th>Reference</th>
26 Critical Congestion Experienced (CCE) [this doc] </tr>
]]></artwork> </thead>
</figure> <tbody>
<tr>
</section> <td>9-11</td>
<td>available non-critical hop-by-hop flags</td>
<td><xref target="RFC7179"/></td>
</tr>
<tr>
<td>12-13</td>
<td>TRILL-ECN (Explicit Congestion Notification)</td>
<td>RFC 9600</td>
</tr>
<tr>
<td>21-25</td>
<td>available critical ingress-to-egress flags</td>
<td><xref target="RFC7179"/></td>
</tr>
<tr>
<td>26</td>
<td>Critical Congestion Experienced (CCE)</td>
<td>RFC 9600</td>
</tr>
</tbody>
</table>
</section>
<section title="Security Considerations" anchor="sect-6"><t> <section anchor="sect-6" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
TRILL support of ECN is a straightforward combination of previously TRILL support of ECN is a straightforward combination of previously
specified ECN and TRILL with no significant new security specified ECN and TRILL with no significant new security
considerations.</t> considerations.</t>
<t>
For general security considerations regarding adding ECN to lower layer protocol
s, see <xref target="RFC9599"/> and <xref target="RFC6040"/>.</t>
<t>
For general TRILL protocol security considerations, see <xref target="RFC6325"/>
.</t>
</section>
</middle>
<back>
<t> <references>
For ECN tunneling security considerations, see <xref target="RFC6040"/>.</t> <name>References</name>
<references>
<t> <name>Normative References</name>
For general TRILL protocol security considerations, see <xref target="RFC6325 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
"/>.</t> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</section> FC.3168.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<section title="Acknowledgements" anchor="sect-7"><t> FC.4774.xml"/>
The helpful comments of Loa Andersson and Adam Roach are hereby <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
acknowledged.</t> FC.6325.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t> FC.7179.xml"/>
This document was prepared with basic NROFF. All macros used were <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
defined in the source file.</t> FC.7567.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</section> FC.7780.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</middle> FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8311.xml"/>
<back> <reference anchor="RFC9599" target="https://www.rfc-editor.org/info/rfc9599">
<references title="Normative References"> <front>
&RFC2119; <title>Guidelines for Adding Congestion Notification to Protocols that
&RFC3168; Encapsulate IP</title>
&RFC4774; <author initials='B.' surname='Briscoe' fullname='Bob Briscoe'>
&RFC6325; <organization>Independent</organization>
&RFC7179; </author>
&RFC7567; <author initials='J.' surname='Kaippallimalil' fullname='John Kaippallimalil'>
&RFC7780; <organization>Futurewei</organization>
&RFC8174; </author>
&RFC8311; <date month='August' year='2024'/>
&I-D.ietf-tsvwg-ecn-encap-guidelines; </front>
</references> <seriesInfo name="RFC" value="9599"/>
<references title="Informative References"> <seriesInfo name="DOI" value="10.17487/RFC9599"/>
&I-D.ietf-tsvwg-ecn-l4s-id; </reference>
<reference anchor="IANAthFlags" target="http://www.iana.org/assignments/t
rill-parameters/trill-parameters.xhtml#extended-header-flags"><front>
<title>TRILL Extended Header word flags</title>
<author>
<organization>IANA</organization>
</author>
<date/> </references>
</front> <references>
<name>Informative References</name>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9331.
&RFC6040; xml"/>
&RFC6660;
</references>
<section title="TRILL Transit RBridge Behavior to Support L4S" anchor="se
ct-a"><t>
The specification of the Low Latency, Low Loss, Scalable throughput
(L4S) wire protocol for IP is given in <xref target="I-D.ietf-tsvwg-ecn-l4s-i
d"/>. L4S is one example
of the ways TRILL ECN handling may evolve <xref target="RFC8311"/>. It is sim
ilar to
the original ECN wire protocol for IP <xref target="RFC3168"/>, except:</t>
<t><list style="symbols"><t>An AQM that supports L4S classifies packets w <reference anchor="IANAthFlags" target="http://www.iana.org/assignments/
ith ECT(1) or CE in trill-parameters/">
the IP header into an L4S queue and a "Classic" queue otherwise.</t> <front>
<title>TRILL Extended Header Flags</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<t>The meaning of CE markings applied by an L4S queue is not the same <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6660.xml"/>
</references>
</references>
<section anchor="sect-a" numbered="true" toc="default">
<name>TRILL Transit RBridge Behavior to Support L4S</name>
<t>
The specification of the Low Latency, Low Loss, and Scalable throughput (L4S)
wire protocol for IP is given in <xref target="RFC9331" format="default"/>. L4S
is one example
of the ways TRILL ECN handling may evolve <xref target="RFC8311" format="defa
ult"/>. It is similar to
the original ECN wire protocol for IP <xref target="RFC3168" format="default"
/>, except:</t>
<ul spacing="normal">
<li>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>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 as the meaning of a drop by a "Classic" queue (contrary to the
original requirement for ECN <xref target="RFC3168"/>). Instead, the likeli hood original requirement for ECN <xref target="RFC3168" format="default"/>). In stead, the likelihood
that the Classic queue drops packets is defined as the square of that the Classic queue drops packets is defined as the square of
the likelihood that the L4S queue marks packets (e.g., when there the likelihood that the L4S queue marks packets -- e.g., when there
is a drop probability of 0.0009 (0.09%) the L4S marking is a drop probability of 0.0009 (0.09%), the L4S marking
probability will be 0.03 (3%)).</t> probability will be 0.03 (3%).</li>
</ul>
</list> <t>
</t>
<t>
This seems to present a problem for the way that a transit TRILL RBridge 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, defers the choice between marking and dropping to the egress. Nonetheless,
the following pseudocode outlines how a transit TRILL RBridge can implement the following pseudocode outlines how a transit TRILL RBridge can implement
L4S marking in such a way that the egress behavior already described in L4S marking in such a way that the egress behavior already described in
<xref target="sect-3.3"/> for Classic ECN <xref target="RFC3168"/> will <xref target="sect-3.3" format="default"/> for Classic ECN <xref target="RFC3 168" format="default"/> will
produce the desired outcome.</t> produce the desired outcome.</t>
<sourcecode type="pseudocode">
<figure><artwork><![CDATA[
/* p is an internal variable calculated by any L4S AQM /* p is an internal variable calculated by any L4S AQM
* dependent on the delay being experienced in the Classic queue. * dependent on the delay being experienced in the Classic queue.
* bit13 is the least significant bit of the TRILL-ECN field * bit13 is the least significant bit of the TRILL-ECN field
*/ */
% On TRILL transit % On TRILL transit
if (bit13 == 0 ) { if (bit13 == 0 ) {
% Classic Queue % Classic Queue
if (p > max(random(), random()) ) if (p > max(random(), random()) )
mark(CCE) % likelihood: p^2 mark(CCE) % likelihood: p^2
} else { } else {
% L4S Queue % L4S Queue
if (p > random() ) { if (p > random() ) {
if (p > random() ) if (p > random() )
mark(CCE) % likelihood: p^2 mark(CCE) % likelihood: p^2
else else
mark(NCCE) % likelihood: p - p^2 mark(NCCE) % likelihood: p - p^2
} }
} }
]]></artwork> </sourcecode>
</figure> <t>
<t> With the above transit behavior, an egress that supports ECN (<xref target="s
With the above transit behavior, an egress that supports ECN (<xref ect-3.3" format="default"/>) will drop packets or propagate their ECN markings
target="sect-3.3"/>) will drop packets or propagate their ECN markings depending on whether the arriving inner header is from an ECN-capable or not
depending on whether the arriving inner header is from a non-ECN-capable or ECN-capable transport.</t>
ECN-capable transport.</t> <t>
<t>
Even if an egress has no L4S-specific logic of its own, it will drop 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 packets with the square of the probability that an egress would if it
did support ECN, for the following reasons:</t> did support ECN, for the following reasons:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Egress with ECN support:<list style="symbols" <li>
><t>L4S: propagates both the Critical and Non-Critical CE marks <t>Egress with ECN support:</t>
(CCE &amp; NCCE) as a CE mark.<vspace blankLines="1"/> <ul spacing="normal">
Likelihood: p^2 + p - p^2 = p <li>
</t> <t>L4S: Propagates both the Critical and Non-Critical CE marks
(CCE and NCCE) as a CE mark.</t>
<t>Classic: Propagates CCE marks as CE or drop, depending on <t>
inner.<vspace blankLines="1"/> Likelihood: p<sup>2</sup> + p - p<sup>2</sup> = p
Likelihood: p^2 </t>
</t> </li>
<li>
</list> <t>Classic: Propagates CCE marks as CE or drop, depending on
</t> the inner header.</t>
<t>
<t>Egress without ECN support:<list style="symbols"><t>L4S: does not prop Likelihood: p<sup>2</sup>
agate NCCE as a CE mark, but drops CCE marks.<vspace blankLines="1"/> </t>
Likelihood: p^2 </li>
</t> </ul>
</li>
<t>Classic: drops CCE marks.<vspace blankLines="1"/> <li>
Likelihood: p^2 <t>Egress without ECN support:</t>
</t> <ul spacing="normal">
<li>
</list> <t>L4S: Does not propagate NCCE as a CE mark, but drops CCE marks.
</t> </t>
<t>
</list> Likelihood: p<sup>2</sup>
</t> </t>
</li>
</section> <li>
<t>Classic: Drops CCE marks.</t>
</back> <t>
Likelihood: p<sup>2</sup>
</rfc> </t>
</li>
</ul>
</li>
</ul>
</section>
<section anchor="sect-7" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The helpful comments of <contact fullname="Loa Andersson"/> and <contact full
name="Adam Roach"/> are hereby
acknowledged.</t>
</section>
</back>
</rfc>
 End of changes. 70 change blocks. 
551 lines changed or deleted 637 lines changed or added

This html diff was produced by rfcdiff 1.48.