idnits 2.17.1 draft-ietf-trill-ecn-support-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2018) is 2250 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Bob Briscoe 4 CableLabs 5 Expires: August 24, 2018 February 25, 2018 7 TRILL (TRansparent Interconnection of Lots of Links): 8 ECN (Explicit Congestion Notification) Support 9 11 Abstract 13 Explicit congestion notification (ECN) allows a forwarding element to 14 notify downstream devices, including the destination, of the onset of 15 congestion without having to drop packets. This can improve network 16 efficiency through better congestion control without packet drops. 17 This document extends ECN to TRILL (TRansparent Interconnection of 18 Lots of Links) switches, including integration with IP ECN, and 19 provides for ECN marking in the TRILL Header Extension Flags Word 20 (see RFC 7179). 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the TRILL working group mailing list . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 1.1 Conventions used in this document......................4 50 2. The ECN Specific Extended Header Flags..................6 52 3. ECN Support.............................................7 53 3.1 Ingress ECN Support....................................7 54 3.2 Transit ECN Support....................................7 55 3.3 Egress ECN Support.....................................8 56 3.3.1 Non-ECN Egress RBridges..............................8 57 3.3.2 ECN Egress RBridges..................................8 59 4. TRILL Support for ECN Variants.........................11 60 4.1 Pre-Congestion Notification (PCN).....................11 61 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......12 63 5. IANA Considerations....................................13 64 6. Security Considerations................................14 66 7. Acknowledgements.......................................14 68 Normative References......................................15 69 Informative References....................................16 71 Appendix A. TRILL Transit RBridge Behavior to Support L4S.17 73 Authors' Addresses........................................19 75 1. Introduction 77 Explicit congestion notification (ECN [RFC3168] [RFC8311]) allows a 78 forwarding element (such as a router) to notify downstream devices, 79 including the destination, of the onset of congestion without having 80 to drop packets. This can improve network efficiency through better 81 congestion control without packet drops. The forwarding element can 82 explicitly mark a proportion of packets in an ECN field instead of 83 dropping the packet. For example, a two-bit field is available for 84 ECN marking in IP headers. 86 ............................. 87 . . 88 +---------+ . 89 +------+ | Ingress | . 90 |Source| +->| RBridge | . +----------+ 91 +---+--+ | | RB1 | . |Forwarding| 92 | | +------+--+ +----------+ . | Element | 93 v | . | | Transit | . | Y | 94 +-------+--+ . +---->| RBridges | . +--------+-+ 95 |Forwarding| . | RBn | . ^ | 96 | Element | . +-------+--+ +---------+ | v 97 | X | . | | Egress | | +-----------+ 98 +----------+ . +---->| RBridge +-+ |Destination| 99 . | RB9 | +-----------+ 100 . TRILL +---------+ 101 . campus . 102 ............................. 104 Figure 1. Example Path Forwarding Nodes 106 In [RFC3168], it was recognized that tunnels and lower layer 107 protocols would need to support ECN, and ECN markings would need to 108 be propagated, as headers were encapsulated and decapsulated. 109 [ECNencapGuide] gives guidelines on the addition of ECN to protocols 110 like TRILL (TRansparent Interconnection of Lots of Links) that often 111 encapsulate IP packets, including propagation of ECN from and to IP. 113 In the figure above, assuming IP traffic, RB1 is an encapsulator and 114 RB9 a decapsulator. Traffic from Source to RB1 might or might not get 115 marked as having experienced congestion in forwarding elements, such 116 as X, before being encapsulated at ingress RB1. Any such ECN marking 117 is encapsulated with a TRILL Header [RFC6325]. 119 This document specifies how ECN marking in traffic at the ingress is 120 copied into the TRILL Extension Header Flags Word and requires such 121 copying for IP traffic. It also enables congestion marking by a 122 congested RBridge such as RBn or RB1 above in the TRILL Header 123 Extension Flags Word [RFC7179]. 125 At RB9, the TRILL egress, it specifies how any ECN markings in the 126 TRILL Header Flags Word and in the encapsulated traffic are combined 127 so that subsequent forwarding elements, such as Y and the 128 Destination, can see if congestion was experienced at any previous 129 point in the path from Source. 131 A large part of the guidelines for adding ECN to lower layer 132 protocols [ECNencapGuide] concerns safe propagation of congestion 133 notifications in scenarios where some of the nodes do not support or 134 understand ECN. Such ECN ignorance is not a major problem with 135 RBridges using this specification because the method specified 136 assures that, if an egress RBridge is ECN ignorant (so it cannot 137 further propagate ECN) and congestion has been encountered, the 138 egress RBridge will at least drop the packet and this drop will 139 itself indicate congestion to end stations. 141 1.1 Conventions used in this document 143 The terminology and acronyms defined in [RFC6325] are used herein 144 with the same meaning. 146 In this documents, "IP" refers to both IPv4 and IPv6. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119] [RFC8174] 151 when, and only when, they appear in all capitals, as shown here. 153 Acronyms: 155 AQM - Active Queue Management 157 CCE - Critical Congestion Experienced 159 CE - Congestion Experienced 161 CItE - Critical Ingress-to-Egress 163 ECN - Explicit Congestion Notification 165 ECT - ECN Capable Transport 167 L4S - Low Latency, Low Loss, Scalable throughput 169 NCHbH - Non-Critical Hop-by-Hop 171 NCCE - Non-Critical Congestion Experienced 172 Not-ECT - Not ECN-Capable Transport 174 PCN - Pre-Congestion Notification 176 2. The ECN Specific Extended Header Flags 178 The extension header fields for explicit congestion notification 179 (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit 180 Critical Congestion Experienced (CCE) field in the 32-bit TRILL 181 Header Extension Flags Word [RFC7780]. 183 These fields are shown in Figure 2 as "ECN" and "CCE". The TRILL-ECN 184 field consists of bits 12 and 13, which are in the range reserved for 185 non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 186 26, which is in the range reserved for Critical Ingress-to-Egress 187 (CItE) bits. The CRItE bit is the critical Ingress-to-Egress summary 188 bit and will be one if and only if any of the bits in the CItE range 189 (21-26) are one or there is a critical feature invoked in some 190 further extension of the TRILL Header after the Extension Flags Word. 191 The other bits and fields shown in Figure 2 are not relevant to ECN. 192 See [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these 193 other bits and fields. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 199 |.....|.........|...........|.....|.......|...........|.........| 200 |C|C|C| |C|N| | | | | | | | | 201 |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | 202 |H|I|R| |C|C| | | Hop | | |C|Clr| | 203 |b|t|s| |A|A| | | Cnt | | |E| | | 204 |H|E|v| |F|F| | | | | | | | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2. The TRILL-ECN and CCE 208 TRILL Header Extension Flags Word Fields 210 Table 1 shows the meaning of the codepoints in the TRILL-ECN field. 211 The first three have the same meaning as the corresponding ECN field 212 codepoints in the IP header as defined in [RFC3168]. However, 213 codepoint 0b11 is called Non-Critical Congestion Experienced (NCCE) 214 to distinguish it from Congestion Experienced in IP. 216 Binary Name Meaning 217 ------ ------- ----------------------------------- 218 00 Not-ECT Not ECN-Capable Transport 219 01 ECT(1) ECN-Capable Transport (1) 220 10 ECT(0) ECN-Capable Transport (0) 221 11 NCCE Non-Critical Congestion Experienced 223 Table 1. TRILL-ECN Field Codepoints 225 3. ECN Support 227 This section specifies interworking between TRILL and the original 228 standardized form of ECN in IP [RFC3168]. 230 The subsections below describe the required behavior to support ECN 231 at TRILL ingress, transit, and egress. The ingress behavior occurs as 232 a native frame is encapsulated with a TRILL Header to produce a TRILL 233 Data packet. The transit behavior occurs in all RBridges where TRILL 234 Data packets are queued, usually at the output port. The egress 235 behavior occurs where a TRILL Data packet is decapsulated and output 236 as a native frame through an RBridge port. 238 An RBridge that supports ECN MUST behave as described in the relevant 239 subsections below, which correspond to the recommended provisions in 240 Section 3 and Sections 5.1-5.4 of [ECNencapGuide]. Nonetheless, the 241 scheme is designed to safely propagate some form of congestion 242 notification even if some RBridges in the path followed by a TRILL 243 Data packet support ECN and others do not. 245 3.1 Ingress ECN Support 247 The behavior at an ingress RBridge is as follows: 249 o When encapsulating an IP frame, the ingress RBridge MUST: 251 + set the F flag in the main TRILL header [RFC7780]; 252 + create a Flags Word as part of the TRILL Header; 253 + copy the two ECN bits from the IP header into the TRILL-ECN 254 field (Flags Word bits 12 and 13) 255 + ensure the CCE flag is set to zero (Flags Word bit 26). 257 o When encapsulating a frame for a non-IP protocol, where that 258 protocol has a means of indicating ECN that is understood by the 259 ingress RBridge, it MUST follow the guidelines in Section 5.3 of 260 [ECNencapGuide] to add a Flags Word to the TRILL Header. For a 261 non-IP protocol with a similar ECN field to IP, this would be 262 achieved by copying into the TRILL-ECN field from the encapsulated 263 native frame. 265 3.2 Transit ECN Support 267 The transit behavior, shown below, is required at all RBridges where 268 TRILL Data packets are queued, usually at the output port. 270 o An RBridge that supports ECN MUST implement some form of active 271 queue management (AQM) according to the guidelines of [RFC7567]. 272 The RBridge detects congestion either by monitoring its own queue 273 depth or by participating in a link-specific protocol. 275 o If the TRILL Header Flags Word is present, whenever the AQM 276 algorithm decides to indicate congestion on a TRILL Data packet it 277 MUST set the CCE flag (Flags Word bit 26). 279 o If the TRILL header Flags Word is not present, to indicate 280 congestion the RBridge will either drop the packet or it MAY do 281 all of the following instead: 283 + set the F flag in the main TRILL header; 284 + add a Flags Word to the TRILL Header; 285 + set the TRILL-ECN field to Not-ECT (00); 286 + and set the CCE flag and the Ingress-to-Egress critical summary 287 bit (CRIbE). 289 Note that a transit RBridge that supports ECN does not refer to the 290 TRILL-ECN field before signaling CCE in a packet. It signals CCE 291 irrespective of whether the packet indicates that the transport is 292 ECN-capable. The egress/decapsulation behavior (described next) 293 ensures that a CCE indication is converted to a drop if the transport 294 is not ECN-capable. 296 3.3 Egress ECN Support 298 3.3.1 Non-ECN Egress RBridges 300 If the egress RBridge does not support ECN, that RBridge will ignore 301 bits 12 and 13 of any Flags Word that is present, because it does not 302 contain any special ECN logic. Nonetheless, if a transit RBridge has 303 set the CCE flag, the egress will drop the packet. This is because 304 drop is the default behavior for an RBridge decapsulating a Critical 305 Ingress-to-Egress flag when it has no specific logic to understand 306 it. Drop is the intended behavior for such a packet, as required by 307 Section 5.4 of [ECNencapGuide]. 309 3.3.2 ECN Egress RBridges 311 If an RBridge supports ECN, for the two cases of an IP and a non-IP 312 inner packet, the egress behavior is as follows: 314 Decapsulating an inner IP packet: The RBridge sets the ECN field 315 of the outgoing native IP packet using Table 3. It MUST set the 316 ECN field of the outgoing IP packet to the codepoint at the 317 intersection of the row for the arriving encapsulated IP packet 318 and the column for 3-bit ECN codepoint in the arriving outer 319 TRILL Data packet TRILL Header. If no TRILL Header Extension 320 Flags Word is present, the 3-bit ECN codepoint is assumed to be 321 all zero bits. 323 The name of the TRILL 3-bit ECN codepoint is defined using the 324 combination of the TRILL-ECN and CCE fields in Table 2. 325 Specifically, the TRILL 3-bit ECN codepoint is called CE if 326 either NCCE or CCE is set in the TRILL Header Extension Flags 327 Word. Otherwise it has the same name as the 2-bit TRILL-ECN 328 codepoint. 330 In the case where the TRILL 3-bit ECN codepoint indicates 331 congestion experienced (CE) but the encapsulated native IP 332 frame indicates a not ECN-capable transport (Not-ECT), it can 333 be seen that the RBridge MUST drop the packet. Such packet 334 dropping is necessary because a transport above the IP layer 335 that is not ECN-capable will have no ECN logic, so it will only 336 understand dropped packets as an indication of congestion. 338 Decapsulating a non-IP protocol frame: If the frame has a means of 339 indicating ECN that is understood by the RBridge, it MUST 340 follow the guidelines in Section 5.4 of [ECNencapGuide] when 341 setting the ECN information in the decapsulated native frame. 342 For a non-IP protocol with a similar ECN field to IP, this 343 would be achieved by combining the information in the TRILL 344 Header Flags Word with the encapsulated non-IP native frame, as 345 specified in Table 3. 347 +------------+-----+---------------------+ 348 | TRILL-ECN | CCE | Arriving TRILL 3-bit| 349 | | | ECN codepoint name | 350 +------------+-----+---------------------+ 351 | Not-ECT 00 | 0 | Not-ECT | 352 | ECT(1) 01 | 0 | ECT(1) | 353 | ECT(0) 10 | 0 | ECT(0) | 354 | NCCE 11 | 0 | CE | 355 | Not-ECT 00 | 1 | CE | 356 | ECT(1) 01 | 1 | CE | 357 | ECT(0) 10 | 1 | CE | 358 | NCCE 11 | 1 | CE | 359 +------------+-----+---------------------+ 361 Table 2. Mapping of TRILL-ECN and CCE Fields to 362 the TRILL 3-bit ECN Codepoint Name 364 +---------+----------------------------------------------+ 365 | Inner | Arriving TRILL 3-bit ECN Codepoint Name | 366 | Native +---------+------------+------------+----------+ 367 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 368 +---------+---------+------------+------------+----------+ 369 | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | 370 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 371 | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | 372 | CE | CE | CE | CE(*) | CE | 373 +---------+---------+------------+------------+----------+ 375 Table 3. Egress ECN Behavior 377 An asterisk in the above table indicates a combination that is 378 currently unused in all variants of ECN marking (see Section 4) and 379 therefore SHOULD be logged. 381 With one exception, the mappings in Table 3 are consistent with those 382 for IP-in-IP tunnels [RFC6040], which ensures backward compatibility 383 with all current and past variants of ECN marking (see Section 4). It 384 also ensures forward compatibility with any future form of ECN 385 marking that complies with the guidelines in [ECNencapGuide], 386 including cases where ECT(1) represents a second level of marking 387 severity below CE. 389 The one exception is that the drop condition in Table 3 need not be 390 logged because, with TRILL, it is the result of a valid combination 391 of events. 393 4. TRILL Support for ECN Variants 395 This section is informative, not normative; it discusses interworking 396 between TRILL and variants of the standardized form of ECN in IP 397 [RFC3168]. See also [RFC8311]. 399 The ECN wire protocol for TRILL (Section 2) and the ingress (Section 400 3.1) and egress (Section 3.3) ECN behaviors have been designed to 401 support the other known variants of ECN, as detailed below. New 402 variants of ECN will have to comply with the guidelines for defining 403 alternative ECN semantics [RFC4774]. It is expected that the TRILL 404 ECN wire protocol is generic enough to support such potential future 405 variants. 407 4.1 Pre-Congestion Notification (PCN) 409 The PCN wire protocol [RFC6660] is recognized by the use of a PCN- 410 compatible Diffserv codepoint in the IP header and a non-zero IP-ECN 411 field. For TRILL or any lower layer protocol, equivalent traffic 412 classification codepoints would have to be defined, but that is 413 outside the scope of the current document. 415 The PCN wire protocol is similar to ECN, except it indicates 416 congestion with two levels of severity. It uses: 418 o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) 419 codepoint 421 o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked 422 (ThM) codepoint. (This difference between ECT(1) and ECT(0) only 423 applies to PCN, not to the classic ECN support specified for TRILL 424 in this document before Section 4.) 426 To implement PCN on a transit RBridge would require a detailed 427 specification. But in brief: 429 o the TRILL Critical Congestion Experienced (CCE) flag would be used 430 for the Excess-Traffic-Marked (ETM) codepoint; 432 o ECT(1) in the TRILL-ECN field would be used for the Threshold- 433 Marked codepoint. 435 Then the ingress and egress behaviors defined in Section 3 would not 436 need to be altered to ensure support for PCN as well as ECN. 438 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) 440 L4S is currently on the IETF's experimental track. An outline of how 441 a transit TRILL RBridge would support L4S [ECNL4S] is given in 442 Appendix A. 444 5. IANA Considerations 446 IANA is requested to update the TRILL Extended Header Flags registry 447 by replacing the lines for bits 9-13 and for bits 21-26 with the 448 following: 450 Bits Purpose Reference 451 ----- ------- --------- 452 9-11 available non-critical hop-by-hop flags 453 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 455 21-25 available critical ingress-to-egress flags 456 26 Critical Congestion Experienced (CCE) [this doc] 458 6. Security Considerations 460 TRILL support of ECN is a straightforward combination of previously 461 specified ECN and TRILL with no significant new security 462 considerations. 464 For ECN tunneling security considerations, see [RFC6040]. 466 For general TRILL protocol security considerations, see [RFC6325]. 468 7. Acknowledgements 470 The helpful comments of Loa Andersson and Adam Roach are hereby 471 acknowledged. 473 This document was prepared with basic NROFF. All macros used were 474 defined in the source file. 476 Normative References 478 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 480 March 1997, . 482 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 483 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 484 10.17487/RFC3168, September 2001, . 487 [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the 488 Explicit Congestion Notification (ECN) Field", BCP 124, RFC 489 4774, DOI 10.17487/RFC4774, November 2006, . 492 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 493 Ghanwani, "Routing Bridges (RBridges): Base Protocol 494 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 495 . 497 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 498 C. Bestler, "Transparent Interconnection of Lots of Links 499 (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 500 2014, . 502 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 503 Recommendations Regarding Active Queue Management", BCP 197, 504 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 507 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 508 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 509 Lots of Links (TRILL): Clarifications, Corrections, and 510 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 511 . 513 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 514 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 515 2017, 517 [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion 518 Notification (ECN) Experimentation", RFC 8311, DOI 519 10.17487/RFC8311, January 2018, . 522 [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, 523 "Guidelines for Adding Congestion Notification to Protocols 524 that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, 525 work in progress. 527 Informative References 529 [ECNL4S] - K. De Schepper, B. Briscoe, "Identifying Modified Explicit 530 Congestion Notification (ECN) Semantics for Ultra-Low Queueing 531 Delay", draft-ietf-tsvwg-ecn-l4s-id, work in progress. 533 [IANAthFlags] - IANA TRILL Extended Header word flags: 534 http://www.iana.org/assignments/trill-parameters/trill- 535 parameters.xhtml#extended-header-flags 537 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 538 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 539 . 541 [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 542 Pre-Congestion Notification (PCN) States in the IP Header Using 543 a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 544 10.17487/RFC6660, July 2012, . 547 Appendix A. TRILL Transit RBridge Behavior to Support L4S 549 The specification of the Low Latency, Low Loss, Scalable throughput 550 (L4S) wire protocol for IP is given in [ECNL4S]. L4S is one example 551 of the ways TRILL ECN handling may evolve [RFC8311]. It is similar to 552 the original ECN wire protocol for IP [RFC3168], except: 554 o An AQM that supports L4S classifies packets with ECT(1) or CE in 555 the IP header into an L4S queue and a "Classic" queue otherwise. 557 o The meaning of CE markings applied by an L4S queue is not the same 558 as the meaning of a drop by a "Classic" queue (contrary to the 559 original requirement for ECN [RFC3168]). Instead, the likelihood 560 that the Classic queue drops packets is defined as the square of 561 the likelihood that the L4S queue marks packets (e.g., when there 562 is a drop probability of 0.0009 (0.09%) the L4S marking 563 probability will be 0.03 (3%)). 565 This seems to present a problem for the way that a transit TRILL 566 RBridge defers the choice between marking and dropping to the egress. 567 Nonetheless, the following pseudocode outlines how a transit TRILL 568 RBridge can implement L4S marking in such a way that the egress 569 behavior already described in Section 3.3 for Classic ECN [RFC3168] 570 will produce the desired outcome. 572 /* p is an internal variable calculated by any L4S AQM 573 * dependent on the delay being experienced in the Classic queue. 574 * bit13 is the least significant bit of the TRILL-ECN field 575 */ 577 % On TRILL transit 578 if (bit13 == 0 ) { 579 % Classic Queue 580 if (p > max(random(), random()) ) 581 mark(CCE) % likelihood: p^2 583 } else { 584 % L4S Queue 585 if (p > random() ) { 586 if (p > random() ) 587 mark(CCE) % likelihood: p^2 588 else 589 mark(NCCE) % likelihood: p - p^2 590 } 591 } 593 With the above transit behavior, an egress that supports ECN (Section 594 3.3) will drop packets or propagate their ECN markings depending on 595 whether the arriving inner header is from a non-ECN-capable or ECN- 596 capable transport. 598 Even if an egress has no L4S-specific logic of its own, it will drop 599 packets with the square of the probability that an egress would if it 600 did support ECN, for the following reasons: 602 o Egress with ECN support: 604 + L4S: propagates both the Critical and Non-Critical CE marks 605 (CCE & NCCE) as a CE mark. 607 Likelihood: p^2 + p - p^2 = p 609 + Classic: Propagates CCE marks as CE or drop, depending on 610 inner. 612 Likelihood: p^2 614 o Egress without ECN support: 616 + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. 618 Likelihood: p^2 620 + Classic: drops CCE marks. 622 Likelihood: p^2 624 Authors' Addresses 626 Donald E. Eastlake, 3rd 627 Huawei Technologies 628 155 Beaver Street 629 Milford, MA 01757 USA 631 Tel: +1-508-333-2270 632 Email: d3e3e3@gmail.com 634 Bob Briscoe 635 CableLabs 636 UK 638 Email: ietf@bobbriscoe.net 639 URI: http://bobbriscoe.net/ 641 Copyright and IPR Provisions 643 Copyright (c) 2018 IETF Trust and the persons identified as the 644 document authors. All rights reserved. 646 This document is subject to BCP 78 and the IETF Trust's Legal 647 Provisions Relating to IETF Documents 648 (http://trustee.ietf.org/license-info) in effect on the date of 649 publication of this document. Please review these documents 650 carefully, as they describe your rights and restrictions with respect 651 to this document. Code Components extracted from this document must 652 include Simplified BSD License text as described in Section 4.e of 653 the Trust Legal Provisions and are provided without warranty as 654 described in the Simplified BSD License. The definitive version of 655 an IETF Document is that published by, or under the auspices of, the 656 IETF. Versions of IETF Documents that are published by third parties, 657 including those that are translated into other languages, should not 658 be considered to be definitive versions of IETF Documents. The 659 definitive version of these Legal Provisions is that published by, or 660 under the auspices of, the IETF. Versions of these Legal Provisions 661 that are published by third parties, including those that are 662 translated into other languages, should not be considered to be 663 definitive versions of these Legal Provisions. For the avoidance of 664 doubt, each Contributor to the IETF Standards Process licenses each 665 Contribution that he or she makes as part of the IETF Standards 666 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 667 language to the contrary, or terms, conditions or rights that differ 668 from or are inconsistent with the rights and licenses granted under 669 RFC 5378, shall have any effect and shall be null and void, whether 670 published or posted by such Contributor, or included with or in such 671 Contribution.