[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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
              <draft-eastlake-sfc-nsh-ecn-support-00.txt>


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 <sfc@ietf.org>.

   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    |  <drop>   |
         |  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, <http://www.rfc-editor.org/info/rfc2119>.

   [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, <http://www.rfc-
         editor.org/info/rfc3168>.

   [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion
         Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010,
         <http://www.rfc-editor.org/info/rfc6040>.

   [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF
         Recommendations Regarding Active Queue Management", BCP 197,
         RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-
         editor.org/info/rfc7567>.

   [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
         2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
         2017, <http://www.rfc-editor.org/info/rfc8174>

   [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
         "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300,
         January 2018, <https://www.rfc-editor.org/info/rfc8300>.



Informative References

   [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service
         Function Chaining (SFC) Architecture", RFC 7665, DOI
         10.17487/RFC7665, October 2015, <https://www.rfc-
         editor.org/info/rfc7665>.
















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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/