INTERNET-DRAFT Donald Eastlake Intended status: Proposed Standard Huawei Bob Briscoe Independent Expires: September 4, 2018 March 5, 2018 Network Service Header (NSH) Explicit Congestion Notification (ECN) Support Abstract Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document specifies ECN support within Service Function Chaining (SFC) domains through use of the Network Service Header (NSH). 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 SFC 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 NSH ECN Support Table of Contents 1. Introduction............................................3 1.1 Conventions used in this document......................4 2. The NSH ECN Field.......................................5 3. ECN Support.............................................7 3.1 At Classifier..........................................7 3.2 At SFFs and SFs........................................7 3.3 At Exit................................................7 4. IANA Considerations.....................................8 5. Security Considerations.................................9 6. Acknowledgements........................................9 Normative References......................................10 Informative References....................................10 Authors' Addresses........................................11 D. Eastlake & B. Briscoe [Page 2] INTERNET-DRAFT NSH ECN Support 1. Introduction The Network Service Header (NSH [RFC8300]) is used to control the propagation of packets through a Service Function Chaining (SFC [RFC7665]) domain as discussed below. The SFC architecture calls for the encapsulation of traffic inside a service function chaining domain with an NSH being added by the "Classifier" on entry to the domain and the NSH being removed on exit from the domain. Thus the NSH is a natural place to note congestion within the SFC domain, avoiding possible confusion due, for example, to changes in the outer transport header in different parts of the SFC domain. | v +----------+ . .|Classifier|. . . . . . . . . . . . . . . +----------+ . . | +----+ . . | --+ SF | Service . . | / +----+ Function . . v --- Chaining . . +-----+/ +----+ domain . . | SFF |--------+ SF | . . +-----+\ +----+ . . | --- . . | \ +----+ . . | --+ SF | . . v +----+ . . +-----+ +----+ . . | SFF |-----------------+ SF | . . +-----+ +----+ . . | +----+ . . | --+ SF | . . | / +----+ . . v --- . . +-----+/ +----+ . . | SFF |--------+ SF | . . +-----+\ +----+ . . | --- . . | \ +----+ . . | --+ SF | . . v +----+ . . +------+ . . . .| Exit |. . . . . . . . . . . . . . . +------+ | v Figure 1. Example Path Forwarding Nodes D. Eastlake & B. Briscoe [Page 3] INTERNET-DRAFT NSH ECN Support Figure 1 shows an SFC domain. Traffic passes through a sequence of Service Function Forwarders (SFFs) each of which sends the traffic to one or more Service Functions (SFs). Each SF performs some operation on the traffic, for example firewall or Network Address Translation (NAT), and returns it to the SFF from which it was received. Explicit congestion notification (ECN [RFC3168]) allows a forwarding element (such as a router or an SFC Service Function Forwarder (SFF) or Service Function (SF)) to notify downstream devices of the onset of congestion without having to drop packets. This can be used as an element in active queue management or the like [RFC7567] to improve network efficiency through better flow 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 two-bit field is available for ECN marking in IP headers [RFC3168]. The availability of congestion information is a building block for various congestion mitigation methods. 1.1 Conventions used in this document 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] [RFC8174] when, and only when, they appear in all capitals, as shown here. Acronyms: CE - Congestion Experienced ECN - Explicit Congestion Notification ECT - ECN Capable Transport Not-ECT - Not ECN-Capable Transport SFC - Service Function Chaining [RFC7665] D. Eastlake & B. Briscoe [Page 4] INTERNET-DRAFT NSH ECN Support 2. The NSH ECN Field Traffic within an SFC domain is encapsulated within an NSH header (see Section 2 of [RFC8300]) as shown in Figure 1. +-----------------------------------+ | Transport Encapsulation | +-----------------------------------+ | Network Service Header (NSH) | | +------------------------------+ | | | Base Header | | | +------------------------------+ | | | Service Path Header | | | +------------------------------+ | | | Metadata (Context Header(s)) | | | +------------------------------+ | +-----------------------------------+ | Original Packet / Frame | +-----------------------------------+ Figure 1. Data Encapsulation in an SFC Domain Two currently unused bits (indicated by "U") in the NSH Base Header (Section 2.2 of [RFC8300]) are allocated for ECN within the SFC domain as shown in Figure 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ | | +-------+ |NSH ECN| | field | +-------+ Figure 2: NSH Base Header Note to RFC Editor: The above figure should be adjusted based on the bits assigned in Section 4 and this note deleted. Table 1 shows the meaning of the codepoints in the SFC ECN field. These have the same meaning as the ECN field codepoints in the IPv4 or IPv6 header as defined in [RFC3168]. D. Eastlake & B. Briscoe [Page 5] INTERNET-DRAFT NSH ECN Support Binary Name Meaning ------ ------- ----------------------------------- 00 Not-ECT Not ECN-Capable Transport 01 ECT(1) ECN-Capable Transport 10 ECT(0) ECN-Capable Transport 11 CE Congestion Experienced Table 1. ECN Field Codepoints D. Eastlake & B. Briscoe [Page 6] INTERNET-DRAFT NSH ECN Support 3. ECN Support This section describes the required behavior to support ECN covering the SFC domain. 3.1 At Classifier When the NSH is added to incoming traffic, the NSH ECN field MUST be set to the ECN-Capable Transport field. 3.2 At SFFs and SFs Any SFFs and SFs that provides NSH ECN support, if it detects congestion and the NSH ECN field indicates that ECN is supported, MUST set the NSH EC field to the Congestion Experienced value. 3.3 At Exit In addition to whatever other actions are taken based on Congestion Experienced, if the original packet being carried inside the NSH is IP, the NSH ECN field MUST be combined with IP ECN field as specified in Table 2 that was extracted from [RFC6040].. +---------+---------------------------------------------+ |Arriving | Arriving Outer Header | | Inner +---------+-----------+-----------+-----------+ | Header | Not-ECT | ECT(0) | ECT(1) | CE | +---------+---------+-----------+-----------+-----------+ | Not-ECT | Not-ECT |Not-ECT |Not-ECT | | | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | | CE | CE | CE | CE | CE | +---------+---------+-----------+-----------+-----------+ Table 2. Exit ECN Fields Merger D. Eastlake & B. Briscoe [Page 7] INTERNET-DRAFT NSH ECN Support 4. IANA Considerations IANA is requested to assign two contiguous bits in the NSH Base Header Bits registry for ECN (bits 16 and 17 suggested) and note this assignment as follows: Bit Description Reference ---------- ----------- --------------- tbd(16-17) NSH ECN [this document] D. Eastlake & B. Briscoe [Page 8] INTERNET-DRAFT NSH ECN Support 5. Security Considerations TBD For general SFC Security Considerations, see [RFC7665]. 6. Acknowledgements TBD D. Eastlake & B. Briscoe [Page 9] INTERNET-DRAFT NSH 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, . [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . Informative References [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . D. Eastlake & B. Briscoe [Page 10] INTERNET-DRAFT NSH 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 Independent UK Email: ietf@bobbriscoe.net URI: http://bobbriscoe.net/ D. Eastlake & B. Briscoe [Page 11] INTERNET-DRAFT NSH ECN Support Copyright and IPR Provisions Copyright (c) 2018 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 12]