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

Versions: 00 01 draft-ietf-trill-ecn-support

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


   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 <trill@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-

   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

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

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",
   document are to be interpreted as described in [RFC2119].


      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(*) | <drop>(*) |
        |  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

      Bit   Mnemonic   Description   Reference
      ---   --------   -----------   -------------
      TBD      ECN     ECN Support   [this document]

D. Eastlake & B.Briscoe                                         [Page 9]

INTERNET-DRAFT                                         TRILL ECN Support

5. Security Considerations


   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, <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-

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

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

Informative References


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

D. Eastlake & B.Briscoe                                        [Page 13]

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