doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc8381.txt b/doc/rfc/rfc8381.txt
new file mode 100644
index 0000000..8dc076e
--- /dev/null
+++ b/doc/rfc/rfc8381.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
+Request for Comments: 8381                                         Y. Li
+Category: Standards Track                                         W. Hao
+ISSN: 2070-1721                                                   Huawei
+                                                             A. Banerjee
+                                                                   Cisco
+                                                                May 2018
+
+
+         Transparent Interconnection of Lots of Links (TRILL):
+                Vendor-Specific RBridge Channel Protocol
+
+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 an
+   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 a method to send vendor-
+   specific messages over the RBridge Channel facility.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8381.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 1]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 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
+   (https://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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology and Acronyms ...................................3
+   2. Vendor Channel Packet Format ....................................3
+   3. Vendor Channel Errors ...........................................6
+      3.1. Sending an Error Response ..................................7
+   4. IANA Considerations .............................................9
+   5. Security Considerations .........................................9
+   6. References .....................................................10
+      6.1. Normative References ......................................10
+      6.2. Informative References ....................................10
+   Authors' Addresses ................................................11
+
+1.  Introduction
+
+   The IETF TRILL (Transparent Interconnection of Lots of Links)
+   protocol [RFC6325] [RFC7780] is implemented by devices called TRILL
+   switches or RBridges (Routing Bridges).  It provides efficient least-
+   cost transparent routing in multi-hop networks with arbitrary
+   topologies and link technologies, using link-state routing and a hop
+   count.
+
+   The TRILL protocol includes an RBridge Channel facility [RFC7178] 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 specified by a
+   particular organization, indicated by OUI (Organizationally Unique
+   Identifier) [RFC7042] or CID (Company Identifier) [802], over the
+   RBridge Channel facility.  Such organization-specific messages could,
+   for example, be used for vendor-specific diagnostic or control
+   messages.
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 2]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+   However, note that a range of RBridge Channel protocol numbers are
+   available based on RFC publication.  Those intending to use the
+   RBridge Channel facility are encouraged to document their use in an
+   RFC and to use RBridge Channel protocol numbers based on such RFC
+   publication.
+
+1.1.  Terminology and Acronyms
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document uses the acronyms defined in [RFC6325] supplemented by
+   the following additional acronyms:
+
+   CID - Company Identifier [802]
+
+   FGL - Fine-Grained Labeling
+
+   OUI - Organizationally Unique Identifier [RFC7042]
+
+   TRILL switch - An alternative term for an RBridge
+
+2.  Vendor Channel Packet Format
+
+   The general structure of an RBridge Channel packet on a link between
+   TRILL switches (RBridges) 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, it is called a Native RBridge
+   Channel message and the TRILL Header (including the Inner Ethernet
+   Addresses and Data Label area) is omitted as shown in Figure 2.  The
+   type of RBridge Channel packet is given by a Protocol field in the
+   RBridge Channel Header that indicates how to interpret the Channel-
+   Protocol-Specific Payload.  See [RFC7178].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 3]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+                             Packet 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
+
+
+                             Message Structure
+
+                   +-----------------------------------+
+                   |           Link Header             |
+                   +-----------------------------------+
+                   |      RBridge Channel Header       |
+                   +-----------------------------------+
+                   | Channel Protocol Specific Payload |
+                   +-----------------------------------+
+                   |    Link Trailer (FCS if Ethernet) |
+                   +-----------------------------------+
+
+            Figure 2: Native RBridge Channel Message Structure
+
+   Figure 3 below expands the RBridge Channel Header and Channel
+   Protocol Specific Payload above for the case of the Vendor-Specific
+   RBridge Channel Tunnel Protocol.  0x8946 is the Ethertype [RFC7042]
+   assigned by the IEEE for the RBridge Channel protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 4]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+                           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=0x008|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          Flags        |  ERR  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    RBridge Channel Protocol Specific:
+                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                      |     Vendor ID = OUI/CID       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |OUI/CID (cont.)|     VERR      | Sub-Protocol  | Sub-Version   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Vendor-Protocol-Specific Data
+      |
+      |  ...
+
+                Figure 3: Channel Tunnel Message Structure
+
+   The fields in Figure 3 related to the Vendor RBridge Channel Protocol
+   are as follows:
+
+      Channel Protocol:  The RBridge Channel Protocol value allocated
+         for the Vendor Channel (see Section 4).
+
+      Vendor ID: This field indicates the vendor specifying the
+         particular use or uses of the Vendor Channel.  The vendor to
+         whom the OUI or CID in this field has been allocated is in
+         charge of specifying Vendor Channel messages using their
+         identifier.  Depending on the first byte of this field as
+         follows:
+
+         OUI: When the bottom two bits of the first byte of the Vendor
+            ID are zero (that is, the first byte is 0bXXXXXX00), the
+            Vendor ID is an OUI.
+
+         CID: When the bottom two bits of the first byte are a one
+            followed by a zero (that is, the first byte is 0bXXXXXX10),
+            the Vendor ID is a CID.
+
+         Other: Other values of the bottom two bits of the first byte of
+            the Vendor ID are invalid, and a VERR of 2 MUST be returned,
+            subject to possible rate limiting (see Section 3).
+
+      VERR:  Vendor Channel Error.  See Section 3.
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 5]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+      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 indicated 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
+         particular vendor's Sub-Protocol.
+
+3.  Vendor Channel Errors
+
+   The VERR field values from 0x0 through 0x0F (inclusive) and the value
+   0xFF are reserved for specification by the IETF.  See Section 4.  All
+   other 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
+   nonzero VERR.
+
+   The VERR values thus far specified by the IETF are as follows:
+
+   0.  The VERR field is zero in Vendor Channel messages unless the
+       Vendor Channel packet is reporting an error.
+
+   1.  The value one indicates that the length of the RBridge-Channel-
+       Specific Data is less than 4 bytes.  This means that at least the
+       VERR byte and possibly part or all of the OUI is truncated.  If
+       an RBridge that implements the Vendor Channel facility receives
+       such a Vendor Channel message, it MUST expand it to extend
+       through the VERR field, set that field to one, and return the
+       packet as described in Section 3.1.
+
+   2.  The OUI/CID 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/CID 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 two and return the packet as
+       described in Section 3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 6]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+   3.  The value 3 indicates that the Sub-Protocol field value is
+       unknown.  An RBridge SHOULD set the VERR field to 3 and return
+       the packet as described in Section 3.1 if it implements the
+       Vendor Channel facility and it receives a Vendor Channel packet
+       meeting the following conditions:
+       (a) a zero VERR field in the RBridge Channel Header,
+       (b) a zero SL flag in the RBridge Channel Header,
+       (c) an OUI/CID that it implements, and
+       (d) a Sub-Protocol field value it does not recognize even though
+           it implements and uses the Sub-Protocol field.
+
+   4.  The value 4 indicates that the Sub-Version field value is
+       unknown.  An RBridge SHOULD set the VERR field to 4 and return
+       the packet as described in Section 3.1 if it implements the
+       Vendor RBridge Channel facility and it receives a Vendor Channel
+       packet meeting the following conditions:
+       (a) a zero VERR field  in the RBridge Channel Header,
+       (b) a zero SL flag in the RBridge Channel Header,
+       (c) an OUI/CID and Sub-Protocol that it implements, and
+       (d) a Sub-Version field value it does not recognize even though
+           it implements and uses the Sub-Version field.
+
+   Uniform error handling is generally advisable for the sake of
+   maintenance and understandability; however, "SHOULD" is chosen for
+   errors 3 and 4 above because, as long as each message is
+   distinguished by a vendor's OUI/CID, it is up to that vendor to
+   decide between standard and nonstandard error handling.
+
+3.1.  Sending an Error Response
+
+   The IETF-specified Vendor Channel errors 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
+   ERR field will be zero because, if it were nonzero, the packet would
+   have been handled at the general RBridge Channel level rather than
+   being passed down to the Vendor Channel level.)
+
+   The RBridge Channel Header is modified by setting the SL flag.  (The
+   flags in the Channel Header and the semantics of the SL flag are
+   specified in [RFC7178].)
+
+   o  If an error 1 is being generated because of truncation, the
+      RBridge-Channel-Specific Data area is extended to include the VERR
+      byte.
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 7]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+   o  If a Vendor Channel message was sent between RBridges, the TRILL
+      Header is modified by (1) clearing the M bit, (2) setting the
+      egress nickname to the ingress nickname as received, (3) setting
+      the ingress nickname to a nickname held by the TRILL switch
+      sending the error packet, and (4) setting the hop count to the
+      usual value on TRILL Data packets used by the TRILL switch sending
+      the error packet.
+
+   o  If a Vendor Channel message was sent between an RBridge and an end
+      station in either direction, the outer MAC addresses are modified
+      by (1) setting the Outer.MacDA to the Outer.MacSA as received and
+      (2) setting the Outer.MacSA 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 message causing the error, unless it
+      was already minimum priority, and the Drop Eligibility Indicator
+      bit MAY be set in an error response.  (See Section 4.1.1 of
+      [RFC6325].)
+
+   o  Vendor Channel error responses MAY be rate-limited.
+
+   It is generally anticipated that the entire packet in which an error
+   was detected would be sent back, modified as above, as the protocol
+   specific payload, so that, for example, error responses could more
+   easily be matched with messages sent; however, except for errors 1
+   and 2, this is up to the vendor specifying how their Vendor RBridge
+   Channel messages are to be used.
+
+   Note that if you receive a Vendor Channel error message with error 1,
+   indicating a truncation error, you cannot trust the apparent
+   "OUI/CID" in that Vendor Channel error message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 8]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+4.  IANA Considerations
+
+   IANA has allocated 0x008 for the Vendor-Specific RBridge Channel
+   Protocol from the range of RBridge Channel protocols allocated by
+   Standards Action.
+
+   IANA has established a subregistry as follows in the TRILL Parameters
+   registry (indented under "RBridge Channel Error Codes" after "RBridge
+   Channel SubError Codes"):
+
+   Registry: Vendor RBridge Channel Error Codes
+   Registration Procedures: Standards Action
+   Reference: RFC 8381
+
+          Code      Description                     Reference
+          ----      -----------                     ---------
+          0x00      No error                        RFC 8381
+          0x01      Message too short               RFC 8381
+          0x02      Unknown OUI/CID                 RFC 8381
+          0x03      Unknown Sub-Protocol            RFC 8381
+          0x04      Unknown Sub-Version             RFC 8381
+         0x05-0x0F  Unassigned                      -
+         0x10-0xFE  Reserved for vendor use         RFC 8381
+          0xFF      Reserved                        RFC 8381
+
+5.  Security Considerations
+
+   See [RFC6325] for general TRILL Security Considerations.
+
+   See [RFC7178] for general RBridge Channel Security Considerations.
+
+   Neither the Vendor-Specific RBridge Channel Protocol nor the basic
+   RBridge Channel Protocol [RFC7178] provide any security assurances or
+   features.  (The basic RBridge Channel Protocol's first use was as an
+   envelope for Bidirectional Forwarding Detection (BFD) messages
+   [RFC7175], which provide their own security.)  Any needed security
+   can be provided by fields or processing within the Vendor-Protocol-
+   Specific Data, which is outside the scope of this document.
+   Alternatively or in addition, use of a Vendor Channel MAY be nested
+   inside the RBridge Channel Header Extension Protocol [RFC7978]; this
+   can provide some security services.
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 9]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+6.  References
+
+6.1.  Normative References
+
+   [802]      IEEE 802, "IEEE Standard for Local and Metropolitan Area
+              Networks: Overview and Architecture",
+              DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802-2014.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
+              Ghanwani, "Routing Bridges (RBridges): Base Protocol
+              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
+              <https://www.rfc-editor.org/info/rfc6325>.
+
+   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
+              IETF Protocol and Documentation Usage for IEEE 802
+              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
+              October 2013, <https://www.rfc-editor.org/info/rfc7042>.
+
+   [RFC7178]  Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
+              Ward, "Transparent Interconnection of Lots of Links
+              (TRILL): RBridge Channel Support", RFC 7178,
+              DOI 10.17487/RFC7178, May 2014,
+              <https://www.rfc-editor.org/info/rfc7178>.
+
+   [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
+              Ghanwani, A., and S. Gupta, "Transparent Interconnection
+              of Lots of Links (TRILL): Clarifications, Corrections, and
+              Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
+              <https://www.rfc-editor.org/info/rfc7780>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+6.2.  Informative References
+
+   [RFC7175]  Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
+              "Transparent Interconnection of Lots of Links (TRILL):
+              Bidirectional Forwarding Detection (BFD) Support", RFC
+              7175, DOI 10.17487/RFC7175, May 2014,
+              <https://www.rfc-editor.org/info/rfc7175>.
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 10]
+
+RFC 8381                  TRILL: Vendor Channel                 May 2018
+
+
+   [RFC7978]  Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent
+              Interconnection of Lots of Links (TRILL): RBridge Channel
+              Header Extension", RFC 7978, DOI 10.17487/RFC7978,
+              September 2016, <https://www.rfc-editor.org/info/rfc7978>.
+
+Authors' Addresses
+
+   Donald Eastlake 3rd
+   Huawei Technologies
+   155 Beaver Street
+   Milford, MA  01757
+   United States of America
+
+   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
+   Cisco
+
+   Email: ayabaner@cisco.com
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 11]
+