Skip to main content

TRILL: Vendor Specific TRILL Channel Protocol
draft-eastlake-trill-vendor-channel-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Donald E. Eastlake 3rd , Yizhou Li , Hao Weiguo , Ayan Banerjee
Last updated 2013-02-17
Replaced by draft-ietf-trill-vendor-channel, draft-ietf-trill-vendor-channel
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-eastlake-trill-vendor-channel-00
TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                                 Yizhou Li
Intended status: Proposed Standard                            Weiguo Hao
                                                                  Huawei
                                                           Ayan Banerjee
                                                                 Insieme
Expires: August 15, 2013                               February 16, 2013

             TRILL: Vendor Specific TRILL Channel Protocol
              <draft-eastlake-trill-vendor-channel-00.txt>

Abstract

   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol is implemented by devices called TRILL switches or RBridges
   (Routing Bridges). TRILL includes a general mechanism, called RBridge
   Channel, for the transmission of typed messages between RBridges in
   the same campus and between RBridges and end stations on the same
   link. This document specifies how to send vendor specific messages
   over the RBridge Channel facility.

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.

   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: Vendor Channel

Table of Contents

      1. Introduction............................................3
      1.1 Terminology and Acronyms...............................3

      2. Vendor Channel Packet Format............................4

      3. Vendor Channel Errors...................................6
      3.1 Sending an Error Response..............................6

      4. IANA Considerations.....................................8
      5. Security Considerations.................................9

      Normative References......................................10
      Informative References....................................10
      Acknowledgements..........................................10

      Authors' Addresses........................................11

D. Eastlake, et al                                              [Page 2]
INTERNET-DRAFT                                     TRILL: Vendor Channel

1. Introduction

   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol [RFC6325] is implemented by devices called TRILL switches or
   RBridges. It provides efficient least cost transparent frame routing
   in multi-hop networks with arbitrary topologies and link
   technologies, using link-state routing and a hop count. Links between
   TRILL switches can be arbitrary technology and, in general, the TRILL
   way to address or specify a TRILL switch (RBridge) in the interior of
   a TRILL campus is by its TRILL provided nickname [RFC6325]
   [ClearCorrect].

   The TRILL protocol includes an RBridge Channel facility [RFCchannel]
   to support typed message transmission between RBridges in the same
   campus and between RBridges and end stations on the same link. This
   document specifies a method of sending messages specific to a
   particular organization, indicated by OUI (Organizationally Unique
   Identifier [RFC5342]), over the RBridge Channel facility.

   Such organization specific messages can be used for vendor specific
   diagnotic or experimental messages.

1.1 Terminology and Acronyms

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

   This document uses the acronyms defined in [RFC6325] supplemented by
   the following additional acronym:

      OUI - Organizationally Unique Identifier [RFC5342]

TRILL switch - An alternative term for an RBridge

D. Eastlake, et al                                              [Page 3]
INTERNET-DRAFT                                     TRILL: Vendor Channel

2. Vendor Channel Packet Format

   The general structure of an RBridge Channel packet on a link between
   RBridges (TRILL switches) is shown in Figure 1 below. When an RBridge
   Channel message is sent between an RBridge and an end station on the
   same link, in either direction, the TRILL Header is omitted. The type
   of RBridge Channel packet is given by a Protocol field in the RBridge
   Channel Header which indicates how to interpret the Channel Protocol
   Specific Payload. See [RFCchannel].

                                  Frame Structure

                   +-----------------------------------+
                   |           Link Header             |
                   +-----------------------------------+
                   |           TRILL Header            |
                   +--------------------------------+  |
                   |     Inner Ethernet Addresses   |  |
                   +--------------------------------+  |
                   |     Data Label (VLAN or FGL)   |  |
                   +--------------------------------+--+
                   |      RBridge Channel Header       |
                   +-----------------------------------+
                   | Channel Protocol Specific Payload |
                   +-----------------------------------+
                   |    Link Trailer (FCS if Ethernet) |
                   +-----------------------------------+

                Figure 1. RBridge Channel Packet Structure

   Figure 2 below expands the RBridge Channel Header and Channel
   Protocol Specific Payload above for the case of the Vendor Specific
   RBridge Channel Tunnel Protocol.

D. Eastlake, et al                                              [Page 4]
INTERNET-DRAFT                                     TRILL: Vendor Channel

       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
    RBridge Channel Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    RBridge-Channel (0x8946)   |  0x0  |   Channel Protocol    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Flags        |  ERR  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Vendor RBridge Channel Protocol Specific:
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |              OUI              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OUI (cont.)  |     VERR      | Sub-Protocol  | Sub-Version   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Vendor Protocol Specific Data
      |
      |  ...

                Figure 2. Channel Tunnel Message Structure

   The fields in Figure 2 related to the Vendor RBridge Channel Protocol
   are as follows:

      Channel Protocol:  The RBridge Channel Protocol value allocated
         for Vendor Channel (see Section 4).

      OUI:  The field indicates the vendor specifying the particular use
         or uses of the Vendor Channel. The vendor to whom the OUI in
         this field has been allocated is in charge of specifying Vendor
         Channel messages using their OUI.

      VERR:  Vendor Channel Error. See Section 3.

      Sub-Protocol: Actually, the vendor specifying their use of the
         Vendor Channel can do whatever they want with the bits after
         the VERR field. But it is strongly recommended that they use
         the sub-protocol / sub-version fields so that multiple and
         evolving uses can be specified based on a single OUI.

      Sub-Version: See explanation above of the Sub-Protocol field. This
         field is provided to indicate the version of the particuar
         vendor's Sub-Protocol.

D. Eastlake, et al                                              [Page 5]
INTERNET-DRAFT                                     TRILL: Vendor Channel

3. Vendor Channel Errors

   The VERR field values from 0x0 through 0xF inclusive are reserved for
   specification by the IETF. See Section 4.  All other non-zero values
   of VERR are available for whatever use the vendor specifies except
   that a Vendor Channel implementation MUST NOT send a Vendor Channel
   Error in response to a Vendor Channel message with a non-zero VERR
   field.

   The IETF specified VERR values thus far are as follows:

   0. The VERR field is zero in Vendor Channel messages unless the the
      Vendor Channel packet is reporting an error.

   1. The value one indicate that the OUI field value is unknown. If an
      RBridge implements the Vendor Channel facility and receives a
      Vendor Channel packet with a zero VERR field and an OUI field it
      does not recognize and the SL flag is zero in the RBridge Channel
      Header, it MUST set the VERR field to the value one and returns
      the packet as described in Section 3.1.

   2. The value two indicates that the Sub-Protocol field value is
      unknown. If an RBridge implements the Vendor Channel facility and
      receives a Vendor Channel packet with a zero VERR field and zero
      SL flag in the RBridge Channel Header, an OUI that it implements,
      but a Sub-Protocol fields value it does not recongize, it SHOULD
      set the VERR field to the value two and returns the packet as
      described in Section 3.1.

   3. The value three indicates that the Sub-Version field value is
      unknown. If an RBridge implements the Vendor RBridge Channel
      facility and receives a Vendor Channel packet with a zero VERR
      field and zero SL flag in the RBridge Channel Header, an OUI and
      Sub-Protocol that it implements, but a Sub-Version fields value it
      does not recongize, it SHOULD set the VERR field to the value
      three and returns the packet as described in Section 3.1.

3.1 Sending an Error Response

   The IETF specified Vendor Channel error response are sent in response
   to a received RBridge Channel packet by setting the VERR field as
   specified above and modifying the packet as specified below.

      The RBridge Channel Header is modified by setting the SL flag.
      (The ERR field will be zero because, if it was non-zero, the
      packet would have been handled at the RBridge Channel rather than
      being passed down to the Vendor Channel level.)

D. Eastlake, et al                                              [Page 6]
INTERNET-DRAFT                                     TRILL: Vendor Channel

      o  If Vendor Channel message was sent between RBridges, the TRILL
         Header is modified by clearing the M bit, setting the egress
         nickname to the ingress nickname as received, and setting the
         ingress nickname to a nickname held by the TRILL switch sending
         the error packet.

      o If Vendor Channel message was sent between an RBridge and an end
         station in either direction, the outer MAC addresses are
         modified by setting the Outer.MacDA to the Outer.MacSA as
         received, and the Outer.MacSA is set to the MAC address of the
         port of the TRILL switch or end station sending the error
         packet.

      o  The priority of the error response message MAY be reduced from
         the priority of the Vendor Chanel messge causing the error,
         unless it was already minimum priority, and MAY set the Drop
         Eligibility Indicator bit in an error response. (Priorities are
         ordered from highest to lowest as 7, 6, 5, 4, 3, 2, 0, and 1.
         See Section 4.1.1, [RFC6325].)

   It is generally anticipated that the entire packet in which an error
   was detected would be sent back, modified as above, so that, for
   example, error responses could more easily be matched with messages
   sent; however, this is really up to the vendor specifying how their
   Vendor RBridge Channel messages are to be used.

D. Eastlake, et al                                              [Page 7]
INTERNET-DRAFT                                     TRILL: Vendor Channel

4. IANA Considerations

   IANA is requested to allocate TBD for Vendor Specific RBridge Channel
   Protocol from the range of RBridge Channel protocols allocated by
   Standards Action.

   IANA is requested to establish a "Vendor RBridge Channel Error Codes"
   registry with initial entries as follows:

          Code      Description                      Reference
          ----      -----------                      ---------
            0       No error                         This document
            1       Unknown OUI                      This document
            2       Unknown Sub-Protocol             This document
            3       Unknown Sub-Version              This document
         0x04-0x0F  Allocated by Standards Action    -
         0x10-0xFF  Reserved for vendor use          This document

D. Eastlake, et al                                              [Page 8]
INTERNET-DRAFT                                     TRILL: Vendor Channel

5. Security Considerations

   See [RFC6325] for general TRILL Secuirty Considerations.

   See [RFCchannel] for general RBridge Channel Security Considerations.

   The Vendor Specific RBridge Channel Protocol provides no security
   assurances or features. Any needed security could be provided by
   fields or processing within the Vendor Protocol Specific Data, which
   is outside the scope of this document. Alternatively, use of Vendor
   Channel could be nested inside the RBridge Channel Tunnel Protocol
   [RFCtunnel] which can provide some security services.

D. Eastlake, et al                                              [Page 9]
INTERNET-DRAFT                                     TRILL: Vendor Channel

Normative References

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

   [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol
         Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September
         2008.

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

   [RFCchannel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward,
         "TRILL: RBridge Channel Support", draft-ietf-trill-rbridge-
         channel-08.txt, in RFC Edtior's queue.

   [ClearCorrect] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, A.
         Banerjee, "TRILL: Clarifications, Corrections, and Updates",
         draft-ietf-trill-clear-correct, work in progress.

Informative References

   [RFCtunnel] - Eastlake, D., ... "TRILL: Channel Tunnel", draft-
         eastlake-trill-channel-tunnel, work in progress.

Acknowledgements

   The document was prepared in raw nroff. All macros used were defined
   within the source file.

D. Eastlake, et al                                             [Page 10]
INTERNET-DRAFT                                     TRILL: Vendor Channel

Authors' Addresses

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

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

      Yizhou Li
      Huawei Technologies
      101 Software Avenue,
      Nanjing 210012, China

      Phone: +86-25-56622310
      Email: liyizhou@huawei.com

      Weiguo Hao
      Huawei Technologies
      101 Software Avenue,
      Nanjing 210012, China

      Phone: +86-25-56623144
      Email: haoweiguo@huawei.com

      Ayan Banerjee
      Insieme Networks
      210 West Tasman Drive
      San Jose, CA 95134 USA

      Email: ayabaner@gmail.com

D. Eastlake, et al                                             [Page 11]
INTERNET-DRAFT                                     TRILL: Vendor Channel

Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2013 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 12]