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

Versions: (draft-eastlake-trill-rbridge-options) 00 01 02 03 04 05 06 07

TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                                    Huawei
Intended status: Proposed Standard                        Anoop Ghanwani
                                                          Vishwas Manral
                                                             IP Infusion
                                                         Caitlin Bestler
Expires: Jaqnuary 9, 2012                                  July 10, 2011

                   RBridges: TRILL Header Extensions


   The TRILL base protocol standard specifies minimal hooks to safely
   support TRILL Header extensions. This draft specifies the format for
   such extensions and specifies some initial extensions.

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 <rbridge@postel.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

   The list of Internet-Draft Shadow Directories can be accessed at

D. Eastlake, et al                                              [Page 1]

INTERNET-DRAFT                                   TRILL Header Extensions

Table of Contents

      1. Introduction............................................3
      1.1 Conventions used in this document......................3

      2. TRILL Header Options....................................4
      2.1 RBridge Extension Handling Requirements................5
      2.2 No Critical Surprises..................................6
      2.3 Extensions Format......................................6
      2.3.1 Extended Header Flags Area...........................7 Critical Summary Bits..............................8 MEF, More Extended Flags...........................8 Specific Initial Bit Extended Flags................9 TLV Summary Bits...................................9 Flow ID............................................9
      2.3.2 TLV Extension Format................................10
      2.3.3 Marshaling of Extensions............................11
      2.4 Conflict of Extensions................................11

      3. Specific Extended Header Flag..........................13
      3.1 The Alert Extended Flag...............................13
      3.2 The ECN Extension.....................................13

      4. Specific TLV Extension.................................16
      4.1 Test/Pad Extension....................................16

      5. Additions to IS-IS.....................................17

      6. IANA Considerations....................................18
      7. Security Considerations................................18
      8. Acknowledgements.......................................18

      9. References.............................................19
      9.1 Normative References..................................19
      9.2 Informative References................................19

      Change History............................................20

D. Eastlake, et al                                              [Page 2]

INTERNET-DRAFT                                   TRILL Header Extensions

1. Introduction

   The base TRILL protocol standard [RFCtrill] provides a TRILL Header
   extensions feature, called "options" in [RFCtrill], and describes
   minimal hooks to safely support header extensions. But, except for
   the first two bits, it does not specify the structure of the
   extension to the TRILL Header nor the details of any particular
   extension. This draft specifies that format and some initial
   extensions: a special Flow ID field, ECN (Explicit Congestion
   Notification) extended header flags, an Alert extended header flag,
   and a test/pad extension.

   Section 2 below describes the general principles, format, and
   ordering of TRILL Header Extensions. Other than the special Flow ID
   extension, TRILL Header extensions are of two kinds: extended header
   flags and TLV (Type, Length, Value) encoded extensions.

   Section 3 describes two specific extended flag extensions while
   Section 4 describes a specific TLV encoded extension.

1.1 Conventions used in this document

   The terminology and acronyms defined in [RFCtrill] 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].

D. Eastlake, et al                                              [Page 3]

INTERNET-DRAFT                                   TRILL Header Extensions

2. TRILL Header Options

   The base TRILL Protocol includes a feature for extension of the TRILL
   Header (see [RFCtrill] Sections 3.5 and 3.8).  The 5-bit Op-Length
   header field gives the length of the extension to the TRILL Header in
   units of 4 octets, which allows up to 124 octets of header extension.
   If Op-Length is zero there is no header extension present; else, this
   area follows immediately after the Ingress Rbridge Nickname field of
   the TRILL Header. The optional extensions area consists of an
   extended flags area possibly followed by TLV extensions. Each TLV
   extension present is 32-bit aligned. There is a special Flow ID
   extension that may also occur in the extended flags area.

   As described below, provision is made for both hop-by-hop extensions,
   which might affect any RBridge that receives a TRILL Data frame
   containing such an extension, and ingress-to-egress extensions, which
   would only necessarily affect the RBridge(s) where a TRILL frame is
   decapsulated. Provision is also made for both "critical" and "non-
   critical" extensions. Any RBridge receiving a frame with a critical
   hop-by-hop extension that it does not implement MUST discard the
   frame because it is unsafe to process the frame without understanding
   the critical extension. Any egress RBridge receiving a frame with a
   critical ingress-to-egress extension it does not implement MUST drop
   the frame if it is a known unicast frame; if it is a multi-
   destination TRILL Data frame with a critical ingress-to-egress
   extension that the RBridge does not implement, then it MUST NOT be
   egressed at that RBridge but it is still forwarded on the
   distribution tree. Non-critical extensions can be safely ignored.

   Any extension indicating a significant change in the structure or
   interpretation of later parts of the frame which, if the extension
   were ignored, could reasonably cause a failure of service or
   violation of security policy MUST be a critical extension. If such an
   extension affects any fields that transit RBridges will examine, it
   MUST be a hop-by-hop critical extension.

   TLV extensions also have a "mutability" flag that has a different
   meaning for ingress-to-egress and for hop-by-hop.

   For an ingress-to-egress extension, the mutability flag indicates
   whether the value associated with the extension can change at a
   transit RBridge (mutable extensions) or cannot so change (immutable
   extensions). For example, an ingress-to-egress security extension
   could protect the value of an immutable ingress-to-egress extension.
   But such a security extension generally could not protect a mutable
   value as a transit RBridge could change that value but might not have
   the keys to recompute a signature or authentication code to take a
   changed value into account.

   For a non-critical hop-by-hop extension, the mutability flag

D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                                   TRILL Header Extensions

   indicates whether a transit RBridge that does not implement the
   extension is permitted (mutable) or not permitted (immutable) to
   remove the extension. A transit RBridge is not required to remove a
   hop-by-hop extension that it does not implement.

   For critical hop-by-hop extensions, the mutability flag is
   meaningless. If the RBridge does not implement the critical hop-by-
   hop extension, it MUST drop the frame. If it does implement the
   critical hop-by-hop extension, it will know whether or not it
   may/should/must remove it.  For critical hop-by-hop extensions, the
   mutability flag is set to zero ("immutable") on transmission and
   ignored on receipt.

      Note: Most RBridges implementations are expected to be optimized
      for simple and common cases of frame forwarding and processing.
      Although the hard limit on the header extensions area length, the
      32-bit alignment of TLV extensions, and the presence of critical
      extension summary bits, as described below, are intended to assist
      in the efficient hardware based processing of frames with a TRILL
      header extensions area, nevertheless the inclusion of extensions,
      particularly TLV extensions, may cause frame processing using a
      "slow path" with inferior performance to "fast path" processing.
      Limited slow path throughput of such frames could cause them to be

2.1 RBridge Extension Handling Requirements

   The requirements given in this section are in addition to the
   extension handling requirements in [RFCtrill] (where they are called

   All RBridges MUST be able to check whether there are any critical
   extensions present that are necessarily applicable to their
   processing of the frame as detailed below.  If they do not implement
   all such critical extensions present, they MUST discard the frame or,
   in some circumstances as described above for certain multi-
   destination frames, continue to forward the frame but MUST NOT egress
   the frame.

   Transit RBridges MUST transparently forward all immutable ingress-to-
   egress header extensions in frames that they forward. Any changes
   made by a transit RBridge to a mutable ingress-to-egress extension
   value MUST be a change permitted by the specification of that

   In addition, a transit RBridge:

   o  MAY add, if space is available, or remove hop-by-hop extensions as

D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                                   TRILL Header Extensions

      specified for such extensions;
   o  MAY change the value and/or length of a mutable ingress-to-egress
      TLV extension as permitted by that extension's specification and
      provided there is enough room if lengthening it;
   o  MUST adjust the length of the extensions area, including changing
      Op-Length in the TRILL header, as appropriate for any changes it
      has made;
   o  MUST NOT add, remove, or re-order ingress-to-egress extensions.
   o  with regard to any non-critical hop-by-hop extensions that the
      transit RBridge does not implement, it MAY remove them if they are
      mutable but MUST transparently copy them when forwarding a frame
      if they are immutable.

2.2 No Critical Surprises

   RBridges advertise the ingress-to-egress extensions they support in
   their IS-IS LSP and advertise the hop-by-hop extensions they support
   at a port on the link connected to that port.  An RBridge is not
   required to support any extensions.

   Unless an RBridge advertises support for a critical extension, it
   will not normally receive frames with that extension.

   An RBridge SHOULD NOT add a critical extension to a frame unless,
   -  for a critical hop-by-hop extension, it has determined that the
      next hop RBridge or RBridges that will accept the frame support
      that extension, or
   -  for a critical ingress-to-egress extension, it has determined that
      the RBridge or RBridges that will egress the frame support that

   "SHOULD NOT" is specified since there may be cases where it is
   acceptable for those frames, particularly for the multi-destination
   case, to be discarded by any RBridges that do not implement the

2.3 Extensions Format

   If any extensions are present in a TRILL Header, as indicated by a
   non-zero Op-Length field, the first 32 or 64 bits of the extensions
   area consist of extended header flags and the Flow ID, as described
   below. The remainder of the extensions area, if any, after this
   initial 32 or 64 bits, consists of TLV (Type Length Value) extensions
   aligned on 32-bit boundaries. Section 2.3.2 specifies the format of a
   TLV extension. Section 2.3.3 describes the marshaling of TLV

D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                                   TRILL Header Extensions

2.3.1 Extended Header Flags Area

   The first 32 bits of the Extensions Area are organized as follows:

      |  0    1   2   3-4  5-7  8-10 11-12  13   14   15 | 16 - 31 |

                 Figure 1: Extensions Area Initial 32 Bits

   Any RBridge adding an extensions area to a TRILL Header must set
   these 32 bits to zero except when permitted or required to set one or
   more of them as specified. The meanings of these bits are listed in
   the table below and then further described.

   Bit(s)   Description
     0    CHbH: Critical Hop-by-Hop extension(s) are present.
     1    CItE: Critical Ingress-to-Egress extension(s) are present.
     2    MEF: More Extended Flags, indicates that an additional 32-bit
          extended flags area is present as described below.
    3-4   CHHF: Critcial Hob-by-Hop extended Flag bits.
    5-7   NHHF: Non-critical Hop-by-Hop extended Flag bits.
    8-10  CIEF: Critical Ingress-to-Egress extended Flag bits.
   11-12  NIEF: Non-critical Ingress-to-Egress extended Flag bits.
    13    NHHT: Non-critical Hop-by-Hop TLV extension(s) are present.
    14    CIET: Critical Ingress-to-Egress TLV extension(s) are present.
    15    NIET: Non-critical Ingress-to-Egress TLV extension(s) are
   16-31   Flow ID if non-zero.

   All extended flags are considered mutable except the critical hop-by-
   hop extended flags.

   For TRILL Data frames with extensions present, any transit RBridge
   MUST transparently copy bits 8 through 12, except as permitted by an
   extension implemented by that RBridge, but MAY either copy or clear
   any of the bits 5 through 7. Even if a transit RBridge removes all
   TLV extensions from a TRILL Header when allowed to do so, it MUST NOT
   eliminate the extensions area in a forwarded frame if any of bits 3,
   4, or 8 through 12 remain non-zero; however, if there are no TLV
   extensions and all of bits 2 through 31 are zero, then the summary
   bits will also be zero and the transit RBridge MAY eliminate the
   Extensions area in the frame, setting Op-Length to zero.

D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                                   TRILL Header Extensions Critical Summary Bits

   The top two bits of the extensions area, bits 0 and 1 above, are
   called the critical summary bits. They summarize the presence of
   critical extensions as follows:

   CHbH: If the CHbH (Critical Hop by Hop) bit is one, one or more
      critical hop-by-hop extensions are present in the extensions area.
      Transit RBridges that do not support all of the critical hop-by-
      hop extensions present, for example an RBridge that supported no
      hop-by-hop extensions, MUST drop the frame. If the CHbH bit is
      zero, the frame is safe, from the point of view of extensions
      processing, for a transit RBridge to forward, regardless of what
      extensions that RBridge does or does not support. A transit
      RBridge that supports none of the extensions present MUST
      transparently forward the extensions area when it forwards a
      frame, except that it MAY remove mutable hop-by-hop extensions.

   CItE: If the CItE (Critical Ingress to Egress) bit is a one, one or
      more critical ingress-to-egress extensions are present in the
      extensions area. If it is zero, no such extensions are present.
      If either CHbH or CItE is non-zero, egress RBridges that do not
      support all critical extensions present, for example an RBridge
      that supports no extensions, MUST drop the frame.  If both CHbH
      and CItE are zero, the frame is safe, from the point of view of
      extensions, for any egress RBridge to process, regardless of what
      extensions that RBridge does or does not support.

   The critical summary bits enable efficient processing of TRILL Data
   frames by RBridges that support no critical extensions and by transit
   RBridges that support no critical hop-by-hop extensions. Such
   RBridges need only check whether Op-Length is non-zero and, if it is,
   the top one or two bits just after the fixed portion of the TRILL
   Header. MEF, More Extended Flags

   Bit 2, if set, indicates there are an additional 32 bits of extended
   flags. They are organized as shown below. The start of the TLV
   extensions, if any, is moved to after these additional bit

     |    32 - 39    |    40 - 47    |    48 - 55    |    56 - 63    |
     | Critical HbH  |NonCritical HbH| Critical ItE  |NonCritical ItE|

                   Figure 2: Extended Flag Bits 32 to 63

D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                                   TRILL Header Extensions Specific Initial Bit Extended Flags

   CHHB, bits 3 and 4, are Critical Hob-by-Hop Bits.

   NHHB, bits 5 through 7, are Non-critical Hop-by-Hop Bits.

   CIEB, bits 8 through 10, are Critical Ingress-to-Egress Bits.

   NIEB, bits 11 and 12, are Non-critical Ingress-to-Egress Bits.

   The bits above are available for indicating extended header flags,
   except for the bits allocated by Section 3 below. TLV Summary Bits

   It is anticipated that in most cases the interpretation of TLV
   encoded extensions in TRILL data frames will be handled by slow path
   software. To minimize unnecessary resort to the slow path, the TLV
   summary bits, plus a special check for critical hop-by-hop TLV
   extensions, enable an RBridge to quickly determine if any TLV encoded
   extensions of the category or categories it implements are present.

   Bits 13-15, the NHHT, CIET, and NIET bits, indicate the presence
   later in the TRILL Header of TLV encoded Non-critical Hop-by-Hop,
   Critical Ingress-to-Egress, and Non-critical Ingress-to-Egress TLV
   extensions respectively.

   There is no Critical Hop-by-Hop TLV flag bit because the presence of
   one or more such TLV extensions can be determined by examining Op-
   Length and, if Op-Length and the MEF bit indicate that there are TLV
   extensions beyond the extended flags area, examining the top two bits
   of the first extensions area byte after the extended flags area. The
   ordering restrictions on TLV extensions require that, if any Critical
   Hop-by-Hop TLV extensions are present, the appear first in the TLV
   extensions area. Thus it is adequate to check only if the first TLV
   extension present is a Critical Hop-by-Hop extension, which can be
   determined from the top two bits of its first byte. Flow ID

   In connection with the multi-pathing of frames, frames that are part
   of the same order-dependent flow need to follow the same path.
   Methods to determine flows are beyond the scope of the this document;
   however, it may be useful, once the flow of a unicast frame has been
   determined, to preserve and transmit that information for use by
   subsequent RBridges.

D. Eastlake, et al                                              [Page 9]

INTERNET-DRAFT                                   TRILL Header Extensions

   The Flow ID extension is a specially encoded non-critical hop-by-hop
   extension that appears in bits 16 through 31 of the initial bit
   encoded extensions area. Its presence is indicated by a non-zero
   value in that field.

   It is considered hop-by-hop because it can be added or changed by a
   transit RBridge and transit RBridges can use it to make forwarding
   decisions. Because the ingress RBridge may know the most about a
   frame, it is expected that this extension would most commonly be
   added at the ingress RBridge. Once set non-zero in a frame, the
   extension SHOULD NOT be removed, set to zero, or changed unless, for
   example, a campus is divided into regions such that different Flow
   IDs would make sense in different regions.

2.3.2 TLV Extension Format

   TRILL Header extensions, other than the extended header flags and
   Flow ID described above, are TLV encoded, with some flag bits in the
   Type and Length octets, in the format show in Figure 3.

      | 0  1  2  3  4  5  6  7  8  9|10|    11-15     |
      |IE|NC|      Type             |MU|   Length     | value...

                     Figure 3. Extension TLV Structure

   The highest order bit of the first octet (IE) is zero for hop-by-hop
   extensions and one for ingress-to-egress extensions.  Hop-by-hop
   extensions are potentially applicable to every RBridge that receives
   the frame. Ingress-to-egress extensions are only inserted at the
   ingress RBridge and are applicable at egress RBridges. Ingress-to-
   egress extensions MAY also be examined and acted upon by transit
   RBridges as specified in the particular extension.

   The second highest order bit of the first octet (NC) is zero for
   critical extensions and one for non-critical extensions.

   Bit 10 in the second octet (MU) is zero for immutable extensions and
   one for mutable extensions. The IE, NC, Type, and MU fields
   themselves MUST NOT be changed even for a mutable extension.

   The eight-bit Type code extends from bit 2 through bit 9. The
   extension Type may constrain the values of the IE, NC, and MU bits.
   For example, a certain Type might require that the extension be
   marked as a hop-by-hop, non-critical, mutable extension. If the IE,
   NC, or MU bits have a value not permitted by the extension Type
   specification for an extension that an RBridge must act on (any

D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                                   TRILL Header Extensions

   critical ingress-to-egress extension at an egress RBridge and any
   critical hop-by-hop extension), the RBridge MUST discard the frame.
   If these bits have a value not permitted by for the Type for an
   extension that an RBridge may ignore (any ingress-to-egress extension
   at a transit RBridge and any non-critical extension), the RBridge MAY
   discard the frame. "MAY" is chosen in this case to minimize the
   checking burden.

   The Length field is an unsigned quantity giving the length of the
   extension value in units of four octets.  It gives the size of the
   extension including the initial two Type and Length octets.  The
   Length field MUST NOT be such that the extension value extends beyond
   the end of the total extensions area as specified by the TRILL Header
   Op-Length. Thus, the value 31 is reserved and, when such a value is
   noticed in a frame, the frame MUST be discarded.

2.3.3 Marshaling of Extensions

   In a TRILL Header with extensions, those extensions start immediately
   after the Ingress RBridge Nickname and fill the extensions area. TLV
   extensions are 32-bit aligned.

   TLV extensions start immediately after the initial four or eight
   octets of extended flags area and MUST appear in ascending order by
   the value of the eleven high order bits (bits 0 through 10) of the
   Type and Length octets considered as an unsigned integer in network
   byte order. There MUST NOT be more than one extension in a frame with
   any particular value of this eleven high order bits. Thus the TLV
   extensions MUST be ordered as follows: (1) critical hop-by-hop
   extensions, (2) non-critical hop-by-hop extensions, (3) critical
   ingress-to-egress extensions, and (4) non-critical ingress-to-egress
   extensions. Frames that violate this paragraph are erroneous, will
   produce unspecified results, and MAY be discarded. "MAY" is chosen to
   minimize the format-checking burden on transit RBridges.

   If any extensions are present, those extensions, both flag and TLV,
   MUST be correctly summarized into the CHbH, CItE, and TLV summary

2.4 Conflict of Extensions

   It is possible for extensions to conflict. Two or more extensions can
   be present in a frame that direct an RBridge processing the frame to
   do conflicting things or to change its interpretation of later parts
   of the frame in conflicting ways. Such conflicts are resolved by
   applying the following rules in the order given:

D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                                   TRILL Header Extensions

   1. Any frame containing extensions that require mutually incompatible
      changes in way later parts of the frame, after the extensions
      area, are interpreted or structured MUST be discarded. (Such
      extensions will be critical extensions, normally hop-by-hop
      critical extensions.)

   2. Critical extensions override non-critical extensions.

   2. Within each of the two categories of critical and non-critical
      extensions, the extension appearing first in lexical order in the
      frame always overrides an extension appearing later in the frame.
      Thus a conflict between an extended flag and a TLV extension is
      always resolved in favor of the extended flag. Extended flags with
      lower bit numbers are considered to have occurred before extended
      flags with higher bit numbers.

D. Eastlake, et al                                             [Page 12]

INTERNET-DRAFT                                   TRILL Header Extensions

3. Specific Extended Header Flag

   The table below shows the state of TRILL Header extended flag
   assignments and the location of the special Flow ID field. See
   Section 6 for IANA Considerations.

       Bits    Purpose               Section
        0-1    Critical Summary Bits    2.3
        2      More extended flags      2.
        3-4    available for critical hop-by-hop flasg
        5      Alert Extended Flag      3.1
        6-7    ECN                      3.2
        8-10   available for critical ingress-to-egress flags
       11-12   available for non-critical ingress-to-egress flags
       13-15   TLV Summary Bits
       16-31   Flow ID
       32-39   available for critical hop-by-hop flags
       40-47   available for non-critical hop-by-hop flags
       48-55   available for critical ingress-to-egress flags
       56-63   available for non-critical ingress-to-egress flags

                     Table 1. Extended Flag Extensions

3.1 The Alert Extended Flag

   The Alert Extended Flag indicates that the frame should be examined
   by the slow path at each hop. This is intended to alert transit
   RBridges that implement this extension and to assist in the
   implemention of features such as a record route message.

3.2 The ECN Extension

   RBridges MAY implement an ECN (Explicit Congestion Notification)
   extension [RFC3168]. If implemented, it SHOULD be enabled by default
   but can be disable on a per RBridge basis by configuration.

   RBridges that do not implement this extension or on which it is
   disabled simply (1) set bits 6 and 7 of the extended flags area to
   zero when they add an extensions area to a TRILL Header and (2)
   transparently copy those bits, if an extensions area is present, when
   they forward a frame with a TRILL Header.

   An RBridge that implements the ECN extension does the following,
   which correspond to the recommended provisions of [RFC6040], when
   that extension is enabled:

D. Eastlake, et al                                             [Page 13]

INTERNET-DRAFT                                   TRILL Header Extensions

   o  When ingressing an IP frame that is ECN enabled (non-zero ECN
      field), it MUST add an extensions area to the TRILL Header and
      copy the two ECN bits from the IP header into extended header
      flags 6 and 7.
   o  When ingressing a frame for a non-IP protocol, where that protocol
      has a means of indicating ECN that is understood by the RBridge,
      it MAY add an extensions area to the TRILL Header with the ECN
      bits set from the ingressed frame.
   o  When forwarding a frame encountering congestion at an RBridge, if
      an extensions area is present with extended flags 6 and 7
      indicating ECN-capable transport, the RBridge MUST modify them to
      the congestion experienced value.
   o  When egressing an IP frame, the RBridge MUST set the outgoing
      native IP frame ECN field to the codepoint at the intersection of
      the values for that field in the encapsulated IP frame (row) and
      the TRILL extended Header ECN field (column) in Table 3 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 egressing 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 egressed native frame by combining that
      information in the TRILL extended header and the encapsulated non-
      IP native frame as specified in Table 3.

   The following table is modified from [RFC3168] and shows the meaning
   of bit values in TRILL Header extended flags 6 and 7, bits 6 and 7 in
   the IPv4 TOS Byte, and bits 6 and 7 in the IPv6 Traffic Class Octet:

      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 2. ECN Field Bit Combinations

   Table 3 below (adapted from [RFC6040]) shows how, at 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, et al                                             [Page 14]

INTERNET-DRAFT                                   TRILL Header Extensions

        | Inner   |       Arriving TRILL Header 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 3: Egress ECN Behavior

   An RBridge detects congestion either by monitoring its own queue
   depths or from participation in a link-specific protocol. An RBridge
   implementing the ECN extension MAY be configured to add congestion
   experienced marking using ECN to any frame with a TRILL Header that
   encounters congestion even if the frame was not previously marked as
   ECN-capable or did not have an extensions area.

D. Eastlake, et al                                             [Page 15]

INTERNET-DRAFT                                   TRILL Header Extensions

4. Specific TLV Extension

   The table below shows the state of TRILL Header TLV extension Type
   assignment. See Section 6 for IANA Considerations.

          Type        Purpose           Section
          0x00       reserved
          0x00-0x7F  available
          0x80       Test/Pad            4.1
          0x81-0xFE  available
          0xFF       reserved

                       Table 4. TLV Extension Types

   The following subsection specifies a particular TRILL TLV extension.

4.1 Test/Pad Extension

   This extension is intended for testing and padding.

   A specific meaning for this extension with the critical flag set will
   not be defined so, in that form, it MUST always be treated as an
   unknown critical extension. If the critical flag is not set, the
   extension does nothing. In either case, it may be any length that
   will fit. Thus, for example, in the non-critical form, it can be used
   to cause the encapsulated frame staring right after the extensions
   area to be 64-bit aligned or for testing purposes.

      o  Type is 0x80.
      o  Length is variable. The value is ignored.
      o  IE may be zero or one.  This extension has both hop-by-hop and
         ingress-to-egress versions.
      o  NC is zero for the pad extension and one for the test
         +  The non-critical version of this extension does nothing.
         +  The critical version of this extension MUST always be
            treated as an unknown critical extension.
      o  MU may be zero or one except that it must be zero if the other
         flags indicate the extensions is a critical hop-by-hop
         extension. This extension may be flagged as mutable or

D. Eastlake, et al                                             [Page 16]

INTERNET-DRAFT                                   TRILL Header Extensions

5. Additions to IS-IS

   RBridges use IS-IS PDUs to inform other RBridges which extensions
   they support. The specific IS-IS PDUs, TLVs, or sub-TLVs used to
   encode and advertise this information are specified in a separate
   document. Support for critical extensions MUST be advertised. Support
   for non-critical extensions MAY be advertised unless the
   specification of a particular non-critical extension imposes a
   requirement higher than "MAY" for the advertising of that extension
   by RBridges that implement it.

D. Eastlake, et al                                             [Page 17]

INTERNET-DRAFT                                   TRILL Header Extensions

6. IANA Considerations

   IANA will create two subregistries within the TRILL registry. A
   "TRILL Extended Header Flags" subregistry that is initially populated
   as specified in Table 1 in Section 3.  And a "TRILL TLV Extension
   Types" subregistry that is initially populated as specified in Table
   4 in Section 4. References in both of those tables to sections of
   this document are to be replaced in the IANA subregistries by
   references to this document as an RFC.

   New TRILL bit extensions and TLV extension types are allocated by
   IETF Review [RFC5226].

7. Security Considerations

   For general TRILL protocol security considerations, see [RFCtrill].

   In order to facilitate authentication, extensions SHOULD be specified
   so they do not have alternative equivalent forms. Authentication of
   anything with alternative equivalent forms almost always requires
   canonicalization that an authenticating RBridge ignorant of the
   extension would be unable to do and that may be complex and error
   prone even for an RBridge knowledgeable of the extension. It is best
   for any extension to have a unique encoding.

8. Acknowledgements

   The following are thanked for their contributions: Bob Briscoe.

D. Eastlake, et al                                             [Page 18]

INTERNET-DRAFT                                   TRILL Header Extensions

9. References

   Normative and informative references for this document are given

9.1 Normative References

   [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3168] -  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
         of Explicit Congestion Notification (ECN) to IP", RFC 3168,
         September 2001.

   [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
         IANA Considerations Section in RFCs", BCP 26, RFC 5226, May

   [RFC6040] - Briscoe, B., "Tunneling of Explicit Congestion
         Notification", RFC 6040, November 2010

   [RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
         Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
         trill-rbridge-protocol-16.txt, in RFC Editor's queue.

9.2 Informative References


D. Eastlake, et al                                             [Page 19]

INTERNET-DRAFT                                   TRILL Header Extensions

Change History

   The sections below summarize changes between successive versions of
   this draft. RFC Editor: Please delete this section before

Version 00 to 02

   Change the requirement for TLV option ordering to be strictly ordered
   by the value of the top nine bits of their first two bytes so that
   the MU bit is included.

   Specify meaning of mutability bit for hop-by-hop options.

   Fix length of Flow ID Value at 2.

   Require that options that may significantly affect the interpretation
   or format of subsequent parts of the frame be critical options.

Version 02 to 03

   Move Test/Pad extension into this document from the More Options
   draft and move the More Flags option from this document into the More
   Options draft.

   Prohibit multiple occurrences of a TLV option in a frame.

Version 03 to 04

   Restructure the bit encoded options area so that the initial 32 bits
   include a 16 bit Flow ID, various TLV-option-present bits, and a more
   extended flags bit that means another 32 bits of extended flags are

   Change the Length of TLV encoded options so that it is in units of 4
   bytes, not 1, resulting in a bigger Type field.

   Update Explicit Congestion Notification to follow RFC 6040.

   Rename "bit encoded options" to be "extended header flags" or
   "extended flags".

D. Eastlake, et al                                             [Page 20]

INTERNET-DRAFT                                   TRILL Header Extensions

Version 04 to 05

   Generally replace "option" with "extension".

   Add the Alert critial hop-by-hop flag extension.

   Replace MT with MU to avooid possible confusion with multiple

D. Eastlake, et al                                             [Page 21]

INTERNET-DRAFT                                   TRILL Header Extensions

Authors' Addresses

   Donald Eastlake
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757

   Phone: +1-508-333-2270
   email: d3e3e3@gmail.com

   Anoop Ghanwani
   Brocade Communications Systems
   130 Holger Way
   San Jose, CA 95134 USA

   Phone: +1-408-333-7149
   Email: anoop@brocade.com

   Vishwas Manral
   IP Infusion Inc.
   1188 E. Arques Ave.
   Sunnyvale, CA 94089 USA

   Tel:   +1-408-400-1900
   email: vishwas@ipinfusion.com

   Caitlin Bestler
   1650 Technology Drive , Suite 700
   San Jose, CA 95110

   Phone: +1-408-944-4000
   email: cait@asomi.com

D. Eastlake, et al                                             [Page 22]

INTERNET-DRAFT                                   TRILL Header Extensions

Copyright and IPR Provisions

   Copyright (c) 2011 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, et al                                             [Page 23]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/