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

Versions: 00 01 02 03

TRILL Working Group                                  Donald Eastlake 3rd
INTERNET-DRAFT                                                    Huawei
Expires: April 16, 2011                                 October 17, 2011


              RBridges: More Proposed TRILL Header Options
           <draft-eastlake-trill-rbridge-more-options-03.txt>


Abstract

   The TRILL base protocol standard, RFC 6325, specifies minimal hooks
   for options and draft-ietf-trill-rbridge-options specifies the format
   for options and a proposed initial set of options. This draft is a
   holding location for additional proposed options. It is not intended
   that this draft will ever progress to be an RFC.


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

INTERNET-DRAFT                             Proposed TRILL Header Options


Table of Contents

      1. Introduction............................................3
      1.1 Terminology............................................3

      2. Extended Flag Options...................................4

      3. TLV Options.............................................5
      3.1 Additional Flags TLV Option............................5
      3.2 Port ID TLV Option.....................................5
      3.3 Extended Options TLV...................................6
      3.3.1 Extended Options IANA Considerations.................7
      3.4 Vendor Options TLV.....................................8
      3.5 Authentication TLV Option..............................8
      3.5.1 Authentication Option Computations...................9
      3.5.2 Authentication Option Fields and Flags...............9

      4. Acknowledgement........................................10
      5. Security Considerations................................10
      6. IANA Considerations....................................10
      7. Normative References...................................11
      8. Informative References.................................11






























D. Eastlake                                                     [Page 2]

INTERNET-DRAFT                             Proposed TRILL Header Options


1. Introduction

   The IETF has standardized the TRILL protocol [RFC6325] a solution for
   transparent shortest-path frame routing in multi-hop Ethernet
   networks with arbitrary topologies, using an existing link-state
   routing protocol and encapsulation with a hop count. That standard
   specifies minimal hooks for options and [RFCopt] specifies the format
   for options and a proposed initial set of options.

   This draft is a holding location for other proposed TRILL header
   options. The options described here may or may not ever be adopted as
   extensions to the TRILL protocol specification. Most of the
   descriptions herein need at least some further work, may be missing
   IANA or Security Considerations, or have other problems. It is not
   intended that this draft will ever progress to be an RFC.



1.1 Terminology

   The terminology and acronyms of [RFC6325] are 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].



























D. Eastlake                                                     [Page 3]

INTERNET-DRAFT                             Proposed TRILL Header Options


2. Extended Flag Options

   Options that appear bit encoded in the TRILL Header options area
   (extended header flag options) are specified in Section 2.3.1 of
   [RFCopt] and a specific bit option is specified in Section 3 of
   [RFCopt].

   No additional extended flag options are specified in this version of
   this document.











































D. Eastlake                                                     [Page 4]

INTERNET-DRAFT                             Proposed TRILL Header Options


3. TLV Options

   Options that are Type, Length, Value (TLV) encoded in the TRILL
   Header options area (TLV options) are specified in Section 2.3.2 and
   2.3.3 of [RFCopt]. Two specific TLV options are specified in Section
   4 of [RFCopt].

   A number of potential additional TRILL Header TLV options are
   specified below.



3.1 Additional Flags TLV Option

   This option provides a means of adding a variety of additional flags
   to the TRILL Header beyond the extended header flag options available
   in the first four octets of the options area.

   The value of a flags option consists of additional flags, eight per
   octet, numbered from the high-order to the low-order bit. Thus flag 1
   is the 0x80 bit of the first octet, flag 8 is the 0x01 bit of that
   octet, flag 9 is the 0x80 bit of the second octet, etc. The number of
   additional flags that can be defined is bounded only by the options
   space that can be available. All flags not present, because they
   would be in value octets beyond those specified by the option Length,
   are considered zero.

   This option can appear once in a frame for each possible combination
   of the ingress-to-egress, hop-by-hop, non-critical, critical, mutable
   and immutable flags (all combinations except for mutable critical
   hop-by-hop, which is a meaningless). To simplify canonicalization for
   security, this option MUST NOT be included if all of the flag bits
   would be zero and the value MUST NOT have any trailing zero octets.
   Thus its Length MUST be at least 1 and at least the last octet of the
   value present MUST be non-zero.

   The option fields and flags are as follows:

      o  Type is 0xTBD.
      o  Length is variable with a minimum value of 1.
      o  IE, NC, MT can be any valid combination producing several
         variations of this option.



3.2 Port ID TLV Option

   The primary purpose of the Port ID option is to normally avoid the
   unicast Inner.MacDA address lookup at the egress RBridge to find the
   port on which to send a decapsulated native frame.


D. Eastlake                                                     [Page 5]

INTERNET-DRAFT                             Proposed TRILL Header Options


   This option provides a 2-octet logical destination port and a 2-octet
   logical source port that, in some ways, could be considered
   extensions to the 6-octet inner destination and source MAC addresses
   in a frame.  These logical port designators are local to the
   destination and source RBridges respectively. They may be any values
   that those RBridges find convenient to efficiently map to their
   physical ports except that the value 0x0000 is used to indicate that
   a logical port designator is unknown and the value 0xFFFF is reserved
   and MUST NOT appear in a port ID option. Should an RBridge
   implementing this option receive a frame with a destination port ID
   of 0xFFFF it handles it as if the destination port ID was 0x0000.

   RBridges that implement this option learn the Port ID for a remote
   MAC address from the source Port ID field in the Port ID option, if
   present, in frames they decapsulate in the same way they can learn
   the ingress RBridge and VLAN. This information is timed out or
   replaced in the same manner as remote MAC address information learned
   from the data plane. Such RBridges include their local Port ID in the
   source field of a Port ID option when encapsulating a frame when
   inclusion of this option is indicated by their local policy.

   For known unicast TRILL data frames, one would expect ingress
   RBridges implementing this option to include the option if they are
   sending to egress RBridges that also implement the option. For multi-
   destination TRILL data frames, inclusion of a Port ID option with a
   source port ID may make sense but the destination port ID is
   meaningless and ignored by egress RBridges.

   The option fields and flags are as follows:

      o  Type is 0xTBD.
      o  Length MUST be 6. The data is the 2-octet destination port ID
         followed by the 2-octet source port IS followed by two reserved
         octets. The reserved octets MUST be set to zero when this
         option is inserted by an ingress RBridge, be copied without
         change but otherwise ignored by transit RBridges, and be
         ignored by egress RBridges.
      o  IE and NC MUST be one. This is an ingress-to-egress non-
         critical option.
      o  MT MUST be zero. This is an immutable option.



3.3 Extended Options TLV

   This option provides an extension mechanism for shorter options to
   avoid using up top-level Types in TLV option encoding. These extended
   options could be referred to as sub-TLV encoded.

   The value part of an Extended Options TLV consists of extended


D. Eastlake                                                     [Page 6]

INTERNET-DRAFT                             Proposed TRILL Header Options


   options each of which is sub-TLV encoded as follows:

   | 0  1  2  3  4  5  6  7  8| 9 10 11 12 13 14 15|
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---
   |          Extended Type            |  Length   | Value...
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---
   |                          |                    |

   The Extended Type is an unsigned 12-bit number whose high order part
   is the first octet and whose low order part is the high order four
   bits of the second octet.

   The Length field is the low order four bits of the second octet. It
   gives the length of the extended option value, that is, the number of
   additional octets after the extended type and length.

   There is no need for IE, NC, or MT flags in an extended option sub-
   TLV because each particular extended option inherits its IE, NC, and
   MT status from the enclosing Extended Options TLV.

   The length specified in an Extended Options TLV MUST be exactly the
   sum of the total lengths of the Extended Options that its value area
   contains, that is, the sum of the enclosed Extended Option sub-TLV
   lengths plus two times the number of Extended Option sub-TLVs for
   their initial two octets.

   If multiple Extended Options are present in an Extended Options TLV,
   there is no space between them. Thus, while an Extended Option is an
   integer number of octets, it has no other special alignment. Transit
   RBridges MUST NOT re-order the extended options within an ingress-to-
   egress Extended Options TLV.

   The option fields and flags are as follows:

      o  Type is 0xTBD.
      o  Length minimum 2.
      o  IE, NC, and MT can be any valid combination producing several
         variations of this option.



3.3.1 Extended Options IANA Considerations

   The Extended Types 0x000 and 0xFFF are reserved and require IETF
   standards action for allocation. The values 0x001 through 0xFFE are
   available for assignment based on RFC publication. The assigning RFC
   MUST specify, for each extended option type, the allowed values of
   the IE, NC, and MT bits in the Extended Options TLV that will enclose
   occurrences of that specific Extended Option.



D. Eastlake                                                     [Page 7]

INTERNET-DRAFT                             Proposed TRILL Header Options


3.4 Vendor Options TLV

   This option is provided to supply a standard method for the
   specification of vendor specific options in a TRILL Header. Vendor
   identity and specific options are encoded into the value associated
   with the option.  Since vendor specific options could require any
   valid combination of the IE, NC, and MT bits, they inherit they
   inherit these from enclosing Vendor Options TLV.

   Each vendor specific option starts with three bytes of OUI followed
   by a forth byte that has, in the bottom four bits, the length of the
   additional value of the vendor specific option in bytes. The top four
   bits of this fourth byte are available for vendor use, for example,
   to distinguish different options.

   Transit RBridges MUST NOT re-order the vendor specific options within
   an ingress-to-egress Vendor Options TLV. The Vendor Options fields
   and flags are as follows:

   o  Type is 0xTBD.
   o  Length is variable with a minimum of 4.
   o  IE, NC, and MT can be any valid combination producing several
      variations of this option.



3.5 Authentication TLV Option

   [The write-up of this option is not complete.]

   TRILL provides an authentication option that builds on the IS-IS
   security keying [RFC5304] [RFC5310] and can be applied to frames with
   a TRILL Header.

   The first octet of the option value is the same algorithm selection
   code as for the IS-IS Authentication TLV (IS-IS TLV #). The value
   length for the option is variable and depends on the algorithm in the
   same way as the value in the IS-IS security TLV. Algorithm zero
   indicates a plain text password which must be configured in code
   which generates and checks this TLV and is NOT RECOMMENDED. Thus far,
   other algorithms have indicated HMAC signing of a canonical form of
   the message using a shared secret that must likewise be configured.

   This option can appear up to twice in a frame, once for ingress-to-
   egress authentication and once for hop-by-hop authentication.







D. Eastlake                                                     [Page 8]

INTERNET-DRAFT                             Proposed TRILL Header Options


3.5.1 Authentication Option Computations

   For algorithms which depend on the value of the frame (i.e., all
   strong authentication algorithms), the frame must be canonicalized
   before the authentication code is computed or verified. This
   canonicalization is logically done by copying the frame starting with
   the TRILL Header and modifying the copy as follows:

   1. Set the TRILL Header Hop Count to zero.

   2. Clear the octets of the Security Option after the algorithm
      selection code.

   3. For all mutable options, setting the option Length to zero and
      remove any value octets.

   4. If an ingress-to-egress authentication code is being computed,
      since hop-by-hop options can be added or deleted in transit, all
      hop-by-hop options must be removed from the frame copy. When a
      critical hop-by-hop option is removed, any required adjustments
      must be made in the remainder of the frame, as if it was about to
      be forwarded to an RBridge that did not support that hop-by-hop
      critical option.

   5. Adjust the TRILL Header Op-Length downward as necessary to make it
      correct for the other adjustments made in the frame copy.

   The authentication code is then calculated using this copy and either
   inserted into the authentication option in the real frame for
   transmission or compared against the authentication code in the real
   frame for verification.



3.5.2 Authentication Option Fields and Flags

   The security option fields and flags are as follows:

      o  Type is 0xTBD.
      o  Length MUST be at least 1.
      o  IE is variable. There may be an ingress-to-egress or hop-by-hop
         security option in a frame or both.
      o  NC and MT MUST be zero. This is a critical, immutable option.









D. Eastlake                                                     [Page 9]

INTERNET-DRAFT                             Proposed TRILL Header Options


4. Acknowledgement

   The Port ID option was suggested as part of the TRILL Header by
   Silvano Gai.



5. Security Considerations

   -- TBD --



6. IANA Considerations

   -- See IANA Considerations sub-sections above. --




































D. Eastlake                                                    [Page 10]

INTERNET-DRAFT                             Proposed TRILL Header Options


7. Normative References

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

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

   [RFCopt] - D. Eastlake, A. Ghanwani, V. Manral, and C. Bestler,
         "RBridges: TRILL Header Options", draft-ietf-trill-rbridge-
         options, work in progress, June 2010.



8. Informative References

   [RFC5304] - Li, T. and R. Atkinson, "Intermediate System to
         Intermediate System (IS-IS) Cryptographic Authentication", RFC
         5304, October 2008.

   [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
         and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
         5310, February 2009.




























D. Eastlake                                                    [Page 11]

INTERNET-DRAFT                             Proposed TRILL Header Options


Authors' Addresses

   Donald E. Eastlake 3rd
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757

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











































D. Eastlake                                                    [Page 12]

INTERNET-DRAFT                             Proposed TRILL Header Options


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                                                    [Page 13]


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