summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8381.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8381.txt')
-rw-r--r--doc/rfc/rfc8381.txt619
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]
+