idnits 2.17.1 draft-eastlake-trill-ecn-support-00.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 (March 21, 2016) is 2929 days in the past. Is this intentional? 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 (==), 1 comment (--). 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 Simula Research Lab 5 Expires: September 20, 2016 March 21, 2016 7 TRILL: ECN (Explicit Congestion Notification) Support 8 10 Abstract 12 Explicit congestion notification (ECN) allows a forwarding element to 13 notify downstream devices, including the destination, of the onset of 14 congestion without having to drop packets. This document extends this 15 capability to TRILL switches, including integration with IP ECN. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Distribution of this document is unlimited. Comments should be sent 23 to the TRILL working group mailing list . 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Conventions used in this document......................4 45 2. The ECN Specific Extended Header Flags..................5 47 3. ECN Support.............................................6 48 3.1 Ingress ECN Support....................................6 49 3.2 Transit ECN Support....................................6 50 3.3 Egress ECN Support.....................................7 52 4. IANA Considerations.....................................9 53 4.1 Flags Word Bits........................................9 54 4.2 Extended RBridge Capability Bit........................9 56 5. Security Considerations................................10 57 6. Acknowledgements.......................................10 59 Normative References......................................11 60 Informative References....................................11 62 Authors' Addresses........................................12 64 1. Introduction 66 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 67 element, such as a router, to notify downstream devices, including 68 the destination, of the onset of congestion without having to drop 69 packets. Instead, the forwarding element can explicitly mark a 70 proportion of packets in a two-bit ECN field. For example, a two-bit 71 field in IP headers is available for ECN marking. 73 The transit of user data through a TRILL campus is similar to 74 transport through a tunnel with the ingress and egress RBridges 75 equivalent to the ends of the tunnel. Thus, existing ECN tunneling 76 recommendatons, particularly [RFC6040], apply. 78 ............................. 79 . . 80 +---------+ . 81 +------+ | Ingress | . 82 |Source| +->| RBridge | . +----------+ 83 +---+--+ | | RB1 | . |Forwarding| 84 | | +------+--+ +----------+ . | Element | 85 v | . | | Transit | . | Y | 86 +-------+--+ . +---->| RBridges | . +--------+-+ 87 |Forwarding| . | RBn | . ^ | 88 | Element | . +-------+--+ +---------+ | v 89 | X | . | | Egress | | +-----------+ 90 +----------+ . +---->| RBridge +-+ |Destination| 91 . | RB9 | +-----------+ 92 . TRILL +---------+ 93 . campus . 94 ............................. 96 In the figure above, if ECN is implemented and assuming IP traffic, 97 RB1 is effectivley a tunnel entrance and RB9 a tunnel exit. Traffic 98 from Source to RB1 might or might not get marked as having 99 experienced congestion in forwarding elements, such as X, before 100 being encapsulated at ingress RB1. Any such ECN marking is 101 encapsulated with a TRILL Header and provision is made in the TRILL 102 Header extension Flags Word for ECN marking by the RBridges through 103 which this traffic passes. 105 Any ECN marking in the traffic at the ingress is copied out to the 106 TRILL Header Flags Word. At RB9, the TRILL egress, any ECN markings 107 in the TRILL Header Flags Word and in the encapsulated traffic are 108 combined so that subsequent forwarding elements, such as Y and the 109 Destination, can see if congestion was experienced at any previous 110 point in the path from Source if the forwarding elements are ECN 111 capable and the Source marked packets as ECT (ECN Capabile 112 Transport). 114 1.1 Conventions used in this document 116 The terminology and acronyms defined in [RFC6325] are used herein 117 with the same meaning. 119 In this documents, "IP" refers to both IPv4 and IPv6. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 Acronyms: 127 CE - Congestion Experienced 129 ECN - Explicit Congestion Notification 131 ECT - ECN Capabile Transport 133 2. The ECN Specific Extended Header Flags 135 RBridges MAY implement ECN (Explicit Congestion Notification) 136 [RFC3168] through a two-bit field in the TRILL Header extension Flags 137 Word [RFC7780]. If implemented, it SHOULD be enabled by default but 138 can be disable on a per RBridge basis by configuration. 140 This field is show below as "ECN" and consists of bits 12 and 13 141 which are in the range reserved for non-critical hop-by-hop bits. See 142 [RFC7780] and [RFC7179] for the meaining of the other bits. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 148 |.....|.........|...........|.....|.......|...........|.........| 149 |C|C|C| |C|N| | | | | | | | 150 |R|R|R| |R|C| |ECN| Ext | | |Ext| | 151 |H|I|R| |C|C| | | Hop | | |Clr| | 152 |b|t|s| |A|A| | | Cnt | | | | | 153 |H|E|v| |F|F| | | | | | | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 The following table is modified from [RFC3168] and shows the meaning 157 of bit values in TRILL Header extended flags 12 and 13. These are 158 also the meanings of bits 6 and 7 of the DS field in the IPv4 and 159 IPv6 heders as defined in [RFC3168]: 161 Binary Meaning 162 ------ ------- 163 00 Not-ECT (Not ECN-Capable Transport) 164 01 ECT(1) (ECN-Capable Transport(1)) 165 10 ECT(0) (ECN-Capable Transport(0)) 166 11 CE (Congestion Experienced) 168 Table 1. ECN Field Bit Combinations 170 3. ECN Support 172 An RBridge that has ECN support as specified herein advertises this 173 through bit TBD in the Extended RBridge Capabilities APPsub-TLV 174 [RFC7782] (see Section 4.2). On encapsulation, transit, and 175 decapsulation it behaves as described in the subsections below, which 176 correspond to the recommended provisions of [RFC6040]. 178 3.1 Ingress ECN Support 180 Behavior at the ingress depends on whether the egress RBridge 181 supports ECN. If it does, then the behavior is as follows (called 182 "normal mode" in [RFC6040]): 184 o When encapsulating an IP frame that is ECN enabled (non-zero ECN 185 field), the ingress RBridge MUST create a flags word as part of 186 the TRILL Header, setting the F flag, and copy the two ECN bits 187 from the IP header into flag word bits 12 and 13. 189 o When encapsulating a frame for a non-IP protocol, where that 190 protocol has a means of indicating ECN that is understood by the 191 ingress RBridge, it MAY add a flags word to the TRILL Header with 192 the ECN bits set from the encapsulated native frame. 194 If the egress RBridge does not support ECN, the behavior is as 195 follows (called "compatibility mode" in [RFC6040]): 197 o A TRILL Header Flags Word need not be created unless there is some 198 reason other than ECN to do so. 200 o If a Flags Word is created, the ECN bits are set to zero (the Non- 201 ECT value). 203 3.2 Transit ECN Support 205 When forwarding a TRILL Data packet encountering congestion at an 206 RBridge, if the TRILL Header flags word is present, bits 12 and 13 207 are updated in the usual ECN manner [RFC3168]. An RBridge detects 208 congestion either by monitoring its own queue depths or from 209 participation in a link-specific protocol. 211 If, for reasons other than ECN, conditions at a transit RBridge 212 require the insertion of a TRLL Header Flags Word into a TRILL Data 213 packet, this implies that the egress RBridge is not ECN capable -- if 214 it was, the Flags Word would have been included in the TRILL Data 215 packet at the ingress. Thus, when a transit RBridge creates such a 216 Flags Word, it sets bits 12 and 13 to zero. 218 3.3 Egress ECN Support 220 Egress RBridge support of ECN is determined by looking at the 221 Extended Capabilities APPsub-TLV that RBridge advertises. If bit TBD 222 is zero, or the APPsub-TLV is absent, that RBridge does not support 223 ECN. If the APPsub-TLV is present and bit TBD is one, then it does 224 support ECN. If there are inconsistent APPsub-TLVs, the egress 225 RBridge is assumed to support ECN if any of those APPsub-TLVs 226 indicate that it does. 228 If the egress RBridge does not support ECN, it will ignore bits 12 229 and 13 of any Flags Word that is present, because it does not contain 230 any special ECN logic. 232 If the egress RBridge supports ECN, it does the following: 234 o When decapsulating an IP frame, the RBridge MUST set the outgoing 235 native IP frame ECN field to the code point at the intersection of 236 the values for that field in the encapsulated IP frame (row) and 237 the TRILL Header flags word ECN field (column) in Table 2 below or 238 drop the frame in the case where the TRILL header indicates 239 congestion experienced but the encapsulated native IP frame 240 indicates a not ECN-capable transport. (Such frame dropping is 241 necessary because IP transport that is not ECN-capable requires 242 dropped frames to sense congestion.) 244 o When decapsulating a non-IP protocol frame with a means of 245 indicating ECN that is understood by the RBridge, it MAY set the 246 ECN information in the decapsulated native frame by combining that 247 information in the TRILL Header flags word and the encapsulated 248 non-IP native frame as specified in Table 2. 250 Table 2 below (adapted from [RFC6040]) shows how, at the egress, to 251 combine the ECN information in the extended TRILL Header ECN field 252 with the ECN information in an encapsulated frame to produce the ECN 253 information to be carried in the resulting native frame. 255 +---------+-----------------------------------------------+ 256 | Inner | Arriving TRILL Header Flag Word ECN Field | 257 | Native +---------+------------+------------+-----------+ 258 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 259 +---------+---------+------------+------------+-----------+ 260 | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | (*) | 261 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 262 | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | 263 | CE | CE | CE | CE(*) | CE | 264 +---------+---------+------------+------------+-----------+ 266 Table 2: Egress ECN Behavior 268 An asterisk in the above table indicates a probably erroneous 269 condition that SHOULD be logged. 271 4. IANA Considerations 273 This section summarizes IANA actions required. 275 4.1 Flags Word Bits 277 IANA is requested to assign bits 12 and 13 in the TRILL Header Flags 278 Word for ECN and update the TRILL Extended Header Flags registry by 279 replacing the line for bits 9-13 with the following" 281 Bits Purpose Reference 282 ----- ------- --------- 283 9-11 available non-critical hop-by-hop flags 284 12-13 ECN (Explicit Congestion Notification) [this document] 286 4.2 Extended RBridge Capability Bit 288 IANA is requested to assign bit TBD in the Extended RBridge 289 Capabilities to indicate ECN support. The Extended RBridge 290 Capabilities registry on the TRILL Parameters page is updated by 291 adding the folloing line and updating any "Unassigned" line that is 292 affected. 294 Bit Mnemonic Description Reference 295 --- -------- ----------- ------------- 296 TBD ECN ECN Support [this document] 298 5. Security Considerations 300 TBD 302 For ECN tunneling security considerations, see [RFC6040]. 304 For general TRILL protocol security considerations, see [RFC6325]. 306 6. Acknowledgements 308 This document was prepared with basic NROFF. All macros used were 309 defined in the source file. 311 Normative References 313 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 315 March 1997, . 317 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 318 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 319 10.17487/RFC3168, September 2001, . 322 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 323 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 324 . 326 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 327 Ghanwani, "Routing Bridges (RBridges): Base Protocol 328 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 329 . 331 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 332 C. Bestler, "Transparent Interconnection of Lots of Links 333 (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 334 2014, . 336 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 337 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 338 Lots of Links (TRILL): Clarifications, Corrections, and 339 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 340 . 342 [RFC7782] - Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S. 343 Gupta, "Transparent Interconnection of Lots of Links (TRILL) 344 Active-Active Edge Using Multiple MAC Attachments", RFC 7782, 345 DOI 10.17487/RFC7782, February 2016, . 348 Informative References 350 [none] 352 Authors' Addresses 354 Donald E. Eastlake, 3rd 355 Huawei Technologies 356 155 Beaver Street 357 Milford, MA 01757 USA 359 Tel: +1-508-333-2270 360 Email: d3e3e3@gmail.com 362 Bob Briscoe (editor) 363 Simula Research Lab 365 Email: ietf@bobbriscoe.net 366 URI: http://bobbriscoe.net/ 368 Copyright and IPR Provisions 370 Copyright (c) 2016 IETF Trust and the persons identified as the 371 document authors. All rights reserved. 373 This document is subject to BCP 78 and the IETF Trust's Legal 374 Provisions Relating to IETF Documents 375 (http://trustee.ietf.org/license-info) in effect on the date of 376 publication of this document. Please review these documents 377 carefully, as they describe your rights and restrictions with respect 378 to this document. Code Components extracted from this document must 379 include Simplified BSD License text as described in Section 4.e of 380 the Trust Legal Provisions and are provided without warranty as 381 described in the Simplified BSD License. The definitive version of 382 an IETF Document is that published by, or under the auspices of, the 383 IETF. Versions of IETF Documents that are published by third parties, 384 including those that are translated into other languages, should not 385 be considered to be definitive versions of IETF Documents. The 386 definitive version of these Legal Provisions is that published by, or 387 under the auspices of, the IETF. Versions of these Legal Provisions 388 that are published by third parties, including those that are 389 translated into other languages, should not be considered to be 390 definitive versions of these Legal Provisions. For the avoidance of 391 doubt, each Contributor to the IETF Standards Process licenses each 392 Contribution that he or she makes as part of the IETF Standards 393 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 394 language to the contrary, or terms, conditions or rights that differ 395 from or are inconsistent with the rights and licenses granted under 396 RFC 5378, shall have any effect and shall be null and void, whether 397 published or posted by such Contributor, or included with or in such 398 Contribution.