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

Versions: 00 01 02 03 04 05 RFC 7179

TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                                    Huawei
Intended status: Proposed Standard                        Anoop Ghanwani
                                                                 Brocade
                                                          Vishwas Manral
                                                           HP Networking
                                                         Caitlin Bestler
                                                                 Quantum
Expires: April 23, 2012                                 October 24, 2011


                   RBridges: TRILL Header Extensions
              <draft-ietf-trill-rbridge-extension-00.txt>


Abstract

   The TRILL base protocol standard specifies minimal hooks to safely
   support TRILL Header extensions. This document specifies an initial
   extension providing additional flag bits and specifies one of those
   bits.


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-
   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, et al                                              [Page 1]

INTERNET-DRAFT                                    TRILL Header Extension


Table of Contents

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

      2. TRILL Header Extensions.................................4
      2.1 RBridge Extended Flag Handling Requirements............5
      2.2 No Critical Surprises..................................5
      2.3 Extension Header Flags.................................6
      2.3.1 Critical Summary Bits................................7
      2.3.2 Extended Header Flags................................8
      2.4 Conflict of Extensions.................................8

      3. Specific Extended Header Flag...........................9
      3.1 The RBridge Channel Alert Extended Flag................9

      4. Additions to IS-IS.....................................10

      5. IANA Considerations....................................10
      6. Security Considerations................................10
      7. Acknowledgements.......................................10
      8. Normative References...................................11
      9. Informative References.................................11





























D. Eastlake, et al                                              [Page 2]

INTERNET-DRAFT                                    TRILL Header Extension


1. Introduction

   The base TRILL protocol standard [RFC6325] provides a TRILL Header
   extension feature, called "options" in Section 3.8 of [RFC6325], and
   describes minimal hooks to safely support header extension. 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 document specifies an initial extension providing
   additional flag bits and specifies one of those bits. Additional
   extensions, including TLV (Type, Length, Value) encoded options, may
   be specified in later documents.

   Section 2 below describes some general principles of TRILL Header
   Extensions and an initial extension.  Section 3 describes a specific
   flag in this initial extension.



1.1 Conventions used in this document

   The terminology and acronyms defined in [RFC6325] are used herein
   with the same meaning.

   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].


























D. Eastlake, et al                                              [Page 3]

INTERNET-DRAFT                                    TRILL Header Extension


2. TRILL Header Extensions

   The base TRILL Protocol includes a feature for extension of the TRILL
   Header (see [RFC6325] 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 first 32-bit word of the optional extensions
   area consists of an extended flags area specified in this document.

   As described below, provision is made for hop-by-hop flags, which
   might affect any RBridge that receives a TRILL Data frame with such a
   flag set, ingress-to-egress flags, which would only necessarily
   affect the RBridge(s) where a TRILL frame is decapsulated, and a
   third type of intermediate flag affecting an as yet unspecified class
   of RBridges, for example border RBridges in a TRILL campus extended
   to support multi-level IS-IS. Provision is also made for both
   "critical" and "non-critical" flags.

   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 such a critical
   extension. Any egress RBridge receiving a frame with a critical
   ingress-to-egress or hop-by-hop 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, 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 extended flag indicating a significant change in the structure or
   interpretation of later parts of the frame which, if the extended
   flag were ignored, could cause a failure of service or violation of
   security policy MUST be a critical extension. If such an extended
   flag affects any fields that transit RBridges will examine, it MUST
   be a hop-by-hop critical extended flag.

      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 the extension area, and the presence of
      critical extension summary bits, as described below, are intended
      to assist in the efficient hardware processing of frames with a
      TRILL header extensions area, nevertheless the inclusion of
      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 some such frames them to be
      discarded.




D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                                    TRILL Header Extension


2.1 RBridge Extended Flag Handling Requirements

   All RBridges MUST check whether there are any critical flags set that
   are necessarily applicable to their processing of the frame. To
   assist in this task, critical summary bits are provided that cover
   not only the extended flags specified herein but will cover any
   further extensions specified in future documents [Options]. If an
   RBridge does not implement all critical flags in a TRILL Data frame,
   it 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.

   In addition, a transit RBridge:

   o  MAY set or clear hop-by-hop flags as specified for such flags;
   o  MUST adjust the length of the extensions area, including changing
      Op-Length in the TRILL header, as appropriate if it adds or
      removes the word of extended header flags;
   o  MUST, if it adds the word of extended header flags or changes any
      critical flags, correctly set the critical summary bits in the
      extended header flags word;
   o  MUST NOT remove the extended header flags word unless it is all
      zero (either on arrival or after permitted modifications);
   o  MUST NOT set or clear ingress-to-egress or reserved extended
      header flags except as specifically permitted in the specification
      of the flag.



2.2 No Critical Surprises

   RBridges advertise the extended header flags they support in IS-IS
   PDUs.  Unless an RBridge advertises support for a critical extended
   header flag, it will not normally receive frames with that flag set.
   An RBridge is not required to support any extensions.

   An RBridge SHOULD NOT set a critical extended flag in a frame unless,

   -  for a critical hop-by-hop extended header flag, it has determined
      that the next hop RBridge or RBridges that will accept the frame
      support that flag,
   -  for a critical ingress-to-egress extended header flag, it has
      determined that the RBridge or RBridges that will egress the frame
      support that flag, or
   -  for a critical reserved extended header flag, it may set such a
      flag only if it understands which RBridges it is applicable to and
      has determined that those RBridges that will accept the frame
      support that flag.

   "SHOULD NOT" is specified since there may be cases where it is


D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                                    TRILL Header Extension


   acceptable for those frames, particularly for the multi-destination
   case, to be discarded by any RBridges that do not implement the
   extended flag.



2.3 Extension Header Flags

   If any extensions are present in a TRILL Header, as indicated by a
   non-zero Op-Length field, the first 32 bits of the extensions area
   consist of extended header flags, as described below. The remainder
   of the extensions area, if any, after this initial 32 bits, will be
   specified in later documents [Options].

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

   Bit(s)   Description
   ---------------------

     0-3  Crit.: Critical summary bits.
         0 CHbHS: Critical Hop-by-Hop extension(s) are present.
         1 CItES: Critical Ingress-to-Egress extension(s) are present.
         2 CRSVS: Critical reserved extension(s) are present.

    3-7   CHbH: Critical Hob-by-Hop extended Flag bits.
    8-13  NCHbH: Non-critical Hop-by-Hop extended Flag bits.

    14-16 CRSV: Critical Reserved extended Flag bits.
    17-20 NCRSV: Non-critical Reserved extended Flag bits.

    21-26 CItE: Critical Ingress-to-Egress extended Flag bits.
    27-31 NCItE: Non-critical Ingress-to-Egress extended Flag bits.

   These are illustrated below:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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  |

   For TRILL Data frames with extensions present, any transit RBridge
   MUST transparently copy the extended flags word, except as permitted
   by an extension implemented by that RBridge.






D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                                    TRILL Header Extension


2.3.1 Critical Summary Bits

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

   CHbHS: If the CHbHS (Critical Hop by Hop Summary) bit is one, one or
      more critical hop-by-hop extensions are present. These might be
      critical hop-by-hop extended header flags or critical hop-by-hop
      extensions after the first word 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.

   CItES: If the CItE (Critical Ingress to Egress Summary) bit is a one,
      one or more critical ingress-to-egress extensions are present.
      These might be critical ingress-to-egress extended header flags or
      critical ingress-to-egress extensions after the first word in the
      extensions area.  If the CItE bit 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 an egress RBridge to process, regardless of
      what extensions that RBridge does or does not support.

   CRSVS: If the CRSVS (Critical Reserved Summary) bit is a one, one or
      more critical extensions are present that are reserved to apply to
      a class of RBridges to be specified in the future, for example
      border RBridges in a TRILL campus extended to support multi-level
      IS-IS. This class will be a subset of transit RBridges. RBridges
      in this class MUST drop frames with the CRSVS bit set unless they
      implement all critical hop-by-hop and all critical reserved
      extensions present in the frame.

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







D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                                    TRILL Header Extension


2.3.2 Extended Header Flags

   CHbH, bits 3 to 7, are Critical Hob-by-Hop extended Flag bits.

   NCHbH bits 8 to 13, are Non-critical Hop-by-Hop extended Flag bits.

   CRSV, bits 14 to 16, are Critical Reserved extended Flag bits.

   NCRSV, bits 17 to 20, are Non-critical Reserved extended Flag bits.

   CItE, bits 21 to 26, are Critical Ingress-to-Egress extended Flag
   bits.

   NCItE, bits 27 to 31, are Non-critical Ingress-to-Egress extended
   Flag bits.

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



2.4 Conflict of Extensions

   It would be possible for TRILL Header extension flags to conflict.
   Two or more extension flags could 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 and stopping with the first one that applies:

   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.

   3. 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.
      Extended flags with lower bit numbers are considered to have
      occurred before extended flags with higher bit numbers. Thus a
      conflict between a hop-by-hop extended flag and an ingress-to-
      egress extended flag is resolved in favor of the hop-by-hop
      extended flag.






D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                                    TRILL Header Extension


3. Specific Extended Header Flag

   The table below shows the state of TRILL Header extended flag
   assignments. See Section 6 for IANA Considerations.

       Bits    Purpose                   Section
      -------------------------------------------
        0-2    Critical Summary Bits       2.3.1
        3-7    available for critical hop-by-hop flags
        8      RBridge Channel Alert Flag  3.1
        9-13   available for non-critical hop-by-hop flags
       14-16   available for critical reserved flags
       17-20   available for non-critical reserved flags
       21-26   available for critical ingress-to-egress flags
       27-31   available for non-critical ingress-to-egress flags

                    Table 1. Extended Header Flags Area



3.1 The RBridge Channel Alert Extended Flag

   The RBridge Channel Alert Extended Flag indicates that the frame is
   an RBridge Channel frame [Channel] that requests processing at each
   hop. This is a non-critical hop-by-hop flag. It is intended to alert
   transit RBridges that implement this extension and to assist in the
   implementation of features such as a record route message.

























D. Eastlake, et al                                              [Page 9]

INTERNET-DRAFT                                    TRILL Header Extension


4. Additions to IS-IS

   RBridges use IS-IS LSP PDUs to inform other RBridges which extensions
   they support. The IS-IS PDU(s), TLV(s), or sub-TLV(s) used to encode
   and advertise this information are specified in a separate document
   [RFC6326bis].



5. IANA Considerations

   IANA is requested to create a subregistry within the TRILL Parameters
   registry: The "TRILL Extended Header Flags" subregistry, that is
   initially populated as specified in Table 1 in Section 3. References
   in that table to sections of this document are to be replaced in the
   IANA subregistry by references to this document as an RFC.

   New TRILL Extended Header Flags are allocated by Standards Action
   [RFC5226] as modified by [RFC4020].



6. Security Considerations

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

   For security considerations related to extended header flags, see the
   document where the flag is specified.

   It is important that the critical summary bits in the extended header
   flags word be set properly. If set when critical extensions of the
   appropriate category are not present, frames may be unnecessarily
   discarded. If not set when critical extensions are present, frames
   may be mishandled or corrupted and intended security policies, such
   as VLAN separation, may be violated.

   The RBridge Channel Alert extended flag specified herein has no
   special security considerations. Implementations should keep in mind
   that it might be erroneously set in a frame. If found set in a frame
   that is not an RBridge Channel message [Channel], this flag MAY be
   cleared and should have no effect except, possibly, delaying
   processing of the frame. If erroneously omitted from a frame, desired
   per hop processing for the frame may not occur.



7. Acknowledgements

   The following are thanked for their contributions: Thomas Narten.



D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                                    TRILL Header Extension


8. Normative References

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

   [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
         Standards Track Code Points", BCP 100, RFC 4020, February 2005.

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

   [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
         Ghanwani, "Routing Bridges (RBridges): Base Protocol
         Specification", July 2011.

   [Channel] - draft-ietf-trill-rbridge-channel, work in progress.

   [RFC6326bis] - draft-eastlake-isis-rfc6326bis, work in progress.



9. Informative References

   [Options] - draft-ietf-trill-rbridge-options, work in progress.
         - draft-eastlake-trill-rbridge-more-options, work in progress.


























D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                                    TRILL Header Extension


Change History

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

   Version 00 of this draft is an extract and simplification of draft-
   ietf-trill-rbridge-options-05.txt as discussed at the TRILL WG
   meeting at IETF 81 and on the TRILL WG mailing list.











































D. Eastlake, et al                                             [Page 12]

INTERNET-DRAFT                                    TRILL Header Extension


Authors' Addresses

   Donald Eastlake
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

   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
   HP Networking
   19111 Pruneridge Avenue
   Cupertino, CA 95014 USA

   Tel:   +1-408-477-0000
   EMail: vishwas.manral@hp.com


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

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
















D. Eastlake, et al                                             [Page 13]

INTERNET-DRAFT                                    TRILL Header Extension


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
   Contribution.





















D. Eastlake, et al                                             [Page 14]


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