Status of This Memo

This is an Internet Standards Track document.¶

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.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9600.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.¶

Table of Contents

1. Introduction

Explicit Congestion Notification (ECN) [RFC3168] [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 the packet. For example, a 2-bit field is available for ECN marking in IP headers.¶

                  .............................
                  .                           .
              +---------+                     .
 +------+     | Ingress |                     .
 |Source|  +->| RBridge |                     .   +----------+
 +---+--+  |  |   RB1   |                     .   |Forwarding|
     |     |  +------+--+  +----------+       .   | Element  |
     v     |      .  |     | Transit  |       .   |    Y     |
   +-------+--+   .  +---->| RBridges |       .   +--------+-+
   |Forwarding|   .        |   RBn    |       .      ^     |
   | Element  |   .        +-------+--+  +---------+ |     v
   |    X     |   .                |     | Egress  | |  +-----------+
   +----------+   .                +---->| RBridge +-+  |Destination|
                  .                      |   RB9   |    +-----------+
                  .  TRILL               +---------+
                  .  campus                   .
                  .............................

In [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. [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.¶

In 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 [RFC6325].¶

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 [RFC7179].¶

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 Source.¶

A large part of the guidelines for adding ECN to lower-layer protocols [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.¶

2. The ECN-Specific Extended Header Flags

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 [RFC7780].¶

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 NCHbH bits. The CCE field consists of bit 26, which is in the range reserved for CItE bits. The CItE 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 [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these other bits and fields.¶

 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|     |   |     |       |         | |   |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 [RFC3168]. However, codepoint 0b11 is called NCEE to distinguish it from CE in IP.¶

3. ECN Support

This section specifies interworking between TRILL and the original standardized form of ECN in IP [RFC3168].¶

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. The egress behavior occurs where a TRILL Data packet is decapsulated and output as a native frame through an RBridge port.¶

An RBridge that supports ECN MUST behave as described in the relevant subsections below, which correspond to the recommended provisions in Section 3 of this document and Sections 5.1 through 5.4 of [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.¶

4. TRILL Support for ECN Variants

This section is informative, not normative; it discusses interworking between TRILL and variants of the standardized form of ECN in IP [RFC3168]. See also [RFC8311].¶

The ECN wire protocol for TRILL (Section 2) and the ingress (Section 3.1) and egress (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 [RFC4774]. It is expected that the TRILL ECN wire protocol is generic enough to support such potential future variants.¶

5. IANA Considerations

IANA has updated the "TRILL Extended Header Flags" registry by replacing the lines for bits 9-13 and 21-26 with the following:¶

6. Security Considerations

TRILL support of ECN is a straightforward combination of previously specified ECN and TRILL with no significant new security considerations.¶

For ECN tunneling security considerations, see [RFC6040].¶

For general TRILL protocol security considerations, see [RFC6325].¶

Appendix A. TRILL Transit RBridge Behavior to Support L4S

The specification of the Low Latency, Low Loss, and Scalable throughput (L4S) wire protocol for IP is given in [RFC9331]. L4S is one example of the ways TRILL ECN handling may evolve [RFC8311]. It is similar to the original ECN wire protocol for IP [RFC3168], except:¶

• 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.¶
• 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 [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%).¶

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 Section 3.3 for Classic ECN [RFC3168] will produce the desired outcome.¶

   /* 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 > max(random(), random()) )
            mark(CCE)                         % likelihood: p^2

   } else {
         % L4S Queue
         if (p > random() ) {
            if (p > random() )
               mark(CCE)                      % likelihood: p^2
            else
               mark(NCCE)                     % likelihood: p - p^2
         }
   }

With the above transit behavior, an egress that supports ECN (Section 3.3) will drop packets or propagate their ECN markings depending on whether the arriving inner header is from a non-ECN-capable or ECN-capable transport.¶

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:¶

• Egress with ECN support:¶

  • L4S: Propagates both the Critical and Non-Critical CE marks (CCE and NCCE) as a CE mark.¶

    Likelihood: p² + p - p² = p¶

  • Classic: Propagates CCE marks as CE or drop, depending on the inner header.¶

    Likelihood: p²¶

• Egress without ECN support:¶

  • L4S: Does not propagate NCCE as a CE mark, but drops CCE marks.¶

    Likelihood: p²¶

  • Classic: Drops CCE marks.¶

    Likelihood: p²¶

Acknowledgements

The helpful comments of Loa Andersson and Adam Roach are hereby acknowledged.¶

This document was originally produced with basic NROFF. All macros used were defined in the source file.¶

Authors' Addresses