TRILL Working Group Donald Eastlake INTERNET-DRAFT Huawei Intended status: Proposed Standard Bob Briscoe Simula Research Lab Expires: September 20, 2016 March 21, 2016 TRILL: ECN (Explicit Congestion Notification) Support Abstract Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This document extends this capability to TRILL switches, including integration with IP ECN. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. D. Eastlake & B.Briscoe [Page 1] INTERNET-DRAFT TRILL ECN Support Table of Contents 1. Introduction............................................3 1.1 Conventions used in this document......................4 2. The ECN Specific Extended Header Flags..................5 3. ECN Support.............................................6 3.1 Ingress ECN Support....................................6 3.2 Transit ECN Support....................................6 3.3 Egress ECN Support.....................................7 4. IANA Considerations.....................................9 4.1 Flags Word Bits........................................9 4.2 Extended RBridge Capability Bit........................9 5. Security Considerations................................10 6. Acknowledgements.......................................10 Normative References......................................11 Informative References....................................11 Authors' Addresses........................................12 D. Eastlake & B.Briscoe [Page 2] INTERNET-DRAFT TRILL ECN Support 1. Introduction Explicit congestion notification (ECN [RFC3168]) 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. Instead, the forwarding element can explicitly mark a proportion of packets in a two-bit ECN field. For example, a two-bit field in IP headers is available for ECN marking. The transit of user data through a TRILL campus is similar to transport through a tunnel with the ingress and egress RBridges equivalent to the ends of the tunnel. Thus, existing ECN tunneling recommendatons, particularly [RFC6040], apply. ............................. . . +---------+ . +------+ | Ingress | . |Source| +->| RBridge | . +----------+ +---+--+ | | RB1 | . |Forwarding| | | +------+--+ +----------+ . | Element | v | . | | Transit | . | Y | +-------+--+ . +---->| RBridges | . +--------+-+ |Forwarding| . | RBn | . ^ | | Element | . +-------+--+ +---------+ | v | X | . | | Egress | | +-----------+ +----------+ . +---->| RBridge +-+ |Destination| . | RB9 | +-----------+ . TRILL +---------+ . campus . ............................. In the figure above, if ECN is implemented and assuming IP traffic, RB1 is effectivley a tunnel entrance and RB9 a tunnel exit. 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 and provision is made in the TRILL Header extension Flags Word for ECN marking by the RBridges through which this traffic passes. Any ECN marking in the traffic at the ingress is copied out to the TRILL Header Flags Word. At RB9, the TRILL egress, 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 if the forwarding elements are ECN capable and the Source marked packets as ECT (ECN Capabile Transport). D. Eastlake & B.Briscoe [Page 3] INTERNET-DRAFT TRILL ECN Support 1.1 Conventions used in this document The terminology and acronyms defined in [RFC6325] are used herein with the same meaning. In this documents, "IP" refers to both IPv4 and IPv6. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Acronyms: CE - Congestion Experienced ECN - Explicit Congestion Notification ECT - ECN Capabile Transport D. Eastlake & B.Briscoe [Page 4] INTERNET-DRAFT TRILL ECN Support 2. The ECN Specific Extended Header Flags RBridges MAY implement ECN (Explicit Congestion Notification) [RFC3168] through a two-bit field in the TRILL Header extension Flags Word [RFC7780]. If implemented, it SHOULD be enabled by default but can be disable on a per RBridge basis by configuration. This field is show below as "ECN" and consists of bits 12 and 13 which are in the range reserved for non-critical hop-by-hop bits. See [RFC7780] and [RFC7179] for the meaining of the other bits. 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 | | |Ext| | |H|I|R| |C|C| | | Hop | | |Clr| | |b|t|s| |A|A| | | Cnt | | | | | |H|E|v| |F|F| | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following table is modified from [RFC3168] and shows the meaning of bit values in TRILL Header extended flags 12 and 13. These are also the meanings of bits 6 and 7 of the DS field in the IPv4 and IPv6 heders as defined in [RFC3168]: Binary Meaning ------ ------- 00 Not-ECT (Not ECN-Capable Transport) 01 ECT(1) (ECN-Capable Transport(1)) 10 ECT(0) (ECN-Capable Transport(0)) 11 CE (Congestion Experienced) Table 1. ECN Field Bit Combinations D. Eastlake & B.Briscoe [Page 5] INTERNET-DRAFT TRILL ECN Support 3. ECN Support An RBridge that has ECN support as specified herein advertises this through bit TBD in the Extended RBridge Capabilities APPsub-TLV [RFC7782] (see Section 4.2). On encapsulation, transit, and decapsulation it behaves as described in the subsections below, which correspond to the recommended provisions of [RFC6040]. 3.1 Ingress ECN Support Behavior at the ingress depends on whether the egress RBridge supports ECN. If it does, then the behavior is as follows (called "normal mode" in [RFC6040]): o When encapsulating an IP frame that is ECN enabled (non-zero ECN field), the ingress RBridge MUST create a flags word as part of the TRILL Header, setting the F flag, and copy the two ECN bits from the IP header into flag word bits 12 and 13. o When encapsulating a frame for a non-IP protocol, where that protocol has a means of indicating ECN that is understood by the ingress RBridge, it MAY add a flags word to the TRILL Header with the ECN bits set from the encapsulated native frame. If the egress RBridge does not support ECN, the behavior is as follows (called "compatibility mode" in [RFC6040]): o A TRILL Header Flags Word need not be created unless there is some reason other than ECN to do so. o If a Flags Word is created, the ECN bits are set to zero (the Non- ECT value). 3.2 Transit ECN Support When forwarding a TRILL Data packet encountering congestion at an RBridge, if the TRILL Header flags word is present, bits 12 and 13 are updated in the usual ECN manner [RFC3168]. An RBridge detects congestion either by monitoring its own queue depths or from participation in a link-specific protocol. If, for reasons other than ECN, conditions at a transit RBridge require the insertion of a TRLL Header Flags Word into a TRILL Data packet, this implies that the egress RBridge is not ECN capable -- if it was, the Flags Word would have been included in the TRILL Data packet at the ingress. Thus, when a transit RBridge creates such a D. Eastlake & B.Briscoe [Page 6] INTERNET-DRAFT TRILL ECN Support Flags Word, it sets bits 12 and 13 to zero. 3.3 Egress ECN Support Egress RBridge support of ECN is determined by looking at the Extended Capabilities APPsub-TLV that RBridge advertises. If bit TBD is zero, or the APPsub-TLV is absent, that RBridge does not support ECN. If the APPsub-TLV is present and bit TBD is one, then it does support ECN. If there are inconsistent APPsub-TLVs, the egress RBridge is assumed to support ECN if any of those APPsub-TLVs indicate that it does. If the egress RBridge does not support ECN, it will ignore bits 12 and 13 of any Flags Word that is present, because it does not contain any special ECN logic. If the egress RBridge supports ECN, it does the following: o When decapsulating an IP frame, the RBridge MUST set the outgoing native IP frame ECN field to the code point at the intersection of the values for that field in the encapsulated IP frame (row) and the TRILL Header flags word ECN field (column) in Table 2 below or drop the frame in the case where the TRILL header indicates congestion experienced but the encapsulated native IP frame indicates a not ECN-capable transport. (Such frame dropping is necessary because IP transport that is not ECN-capable requires dropped frames to sense congestion.) o When decapsulating a non-IP protocol frame with a means of indicating ECN that is understood by the RBridge, it MAY set the ECN information in the decapsulated native frame by combining that information in the TRILL Header flags word and the encapsulated non-IP native frame as specified in Table 2. Table 2 below (adapted from [RFC6040]) shows how, at the egress, to combine the ECN information in the extended TRILL Header ECN field with the ECN information in an encapsulated frame to produce the ECN information to be carried in the resulting native frame. D. Eastlake & B.Briscoe [Page 7] INTERNET-DRAFT TRILL ECN Support +---------+-----------------------------------------------+ | Inner | Arriving TRILL Header Flag Word ECN Field | | Native +---------+------------+------------+-----------+ | Header | Not-ECT | ECT(0) | ECT(1) | CE | +---------+---------+------------+------------+-----------+ | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | (*) | | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | | CE | CE | CE | CE(*) | CE | +---------+---------+------------+------------+-----------+ Table 2: Egress ECN Behavior An asterisk in the above table indicates a probably erroneous condition that SHOULD be logged. D. Eastlake & B.Briscoe [Page 8] INTERNET-DRAFT TRILL ECN Support 4. IANA Considerations This section summarizes IANA actions required. 4.1 Flags Word Bits IANA is requested to assign bits 12 and 13 in the TRILL Header Flags Word for ECN and update the TRILL Extended Header Flags registry by replacing the line for bits 9-13 with the following" Bits Purpose Reference ----- ------- --------- 9-11 available non-critical hop-by-hop flags 12-13 ECN (Explicit Congestion Notification) [this document] 4.2 Extended RBridge Capability Bit IANA is requested to assign bit TBD in the Extended RBridge Capabilities to indicate ECN support. The Extended RBridge Capabilities registry on the TRILL Parameters page is updated by adding the folloing line and updating any "Unassigned" line that is affected. Bit Mnemonic Description Reference --- -------- ----------- ------------- TBD ECN ECN Support [this document] D. Eastlake & B.Briscoe [Page 9] INTERNET-DRAFT TRILL ECN Support 5. Security Considerations TBD For ECN tunneling security considerations, see [RFC6040]. For general TRILL protocol security considerations, see [RFC6325]. 6. Acknowledgements This document was prepared with basic NROFF. All macros used were defined in the source file. D. Eastlake & B.Briscoe [Page 10] INTERNET-DRAFT TRILL ECN Support Normative References [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, . [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, . [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, . [RFC7782] - Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments", RFC 7782, DOI 10.17487/RFC7782, February 2016, . Informative References [none] D. Eastlake & B.Briscoe [Page 11] INTERNET-DRAFT TRILL ECN Support Authors' Addresses Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Tel: +1-508-333-2270 Email: d3e3e3@gmail.com Bob Briscoe (editor) Simula Research Lab Email: ietf@bobbriscoe.net URI: http://bobbriscoe.net/ D. Eastlake & B.Briscoe [Page 12] INTERNET-DRAFT TRILL ECN Support Copyright and IPR Provisions Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake & B.Briscoe [Page 13]