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
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
大量链路的透明互连（TRILL）：特定于供应商的RBridge信道协议
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.
IETF TRILL（大量链路的透明互连）协议由称为TRILL交换机或RBridge（路由桥）的设备实现。TRILL包括一种称为RBridge通道的通用机制，用于在同一校园内的RBridge之间以及在同一链路上的RBridge和终端站之间传输类型化消息。本文件规定了通过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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8381.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
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.
IETF TRILL（大量链路的透明互连）协议[RFC6325][RFC7780]由称为TRILL交换机或RBridge（路由桥）的设备实现。它使用链路状态路由和跳数，在具有任意拓扑和链路技术的多跳网络中提供高效、成本最低的透明路由。
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.
TRILL协议包括一个RBridge信道设施[RFC7178]，用于支持同一校园内RBridge之间以及同一链路上RBridge和终端站之间的类型化消息传输。本文件规定了通过RBridge信道设施发送由特定组织指定的消息的方法，该方法由OUI（组织唯一标识符）[RFC7042]或CID（公司标识符）[802]表示。例如，此类特定于组织的消息可用于特定于供应商的诊断或控制消息。
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.
但是，请注意，基于RFC发布，可以获得一系列RBRIGE信道协议编号。鼓励打算使用RBridge信道设施的用户在RFC中记录其使用情况，并根据RFC出版物使用RBridge信道协议编号。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document uses the acronyms defined in [RFC6325] supplemented by the following additional acronyms:
本文件使用[RFC6325]中定义的首字母缩略词，并辅以以下附加首字母缩略词：
CID - Company Identifier [802]
CID-公司标识符[802]
FGL - Fine-Grained Labeling
FGL-细粒度标记
OUI - Organizationally Unique Identifier [RFC7042]
OUI-组织唯一标识符[RFC7042]
TRILL switch - An alternative term for an RBridge
颤音开关-RBridge的替代术语
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].
TRILL交换机（RBridges）之间链路上RBridge信道数据包的一般结构如下图1所示。当在同一链路上的RBridge和终端站之间发送RBridge信道消息时，无论是在哪个方向，它都被称为本机RBridge信道消息，并且如图2所示省略TRILL报头（包括内部以太网地址和数据标签区域）。RBridge信道分组的类型由RBridge信道报头中的协议字段给出，该字段指示如何解释特定于信道协议的有效负载。见[RFC7178]。
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) |
+-----------------------------------+
+-----------------------------------+
| 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
图1:RBridge信道分组结构
Message Structure
消息结构
+-----------------------------------+
| Link Header |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel Protocol Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
+-----------------------------------+
| Link Header |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel Protocol Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
Figure 2: Native RBridge Channel Message Structure
图2：本机RBridge通道消息结构
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.
下面的图3针对特定于供应商的RBridge通道隧道协议扩展了上述RBridge通道头和特定于通道协议的有效负载。0x8946是IEEE为RBridge信道协议分配的以太网类型[RFC7042]。
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
|
| ...
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
图3：通道隧道消息结构
The fields in Figure 3 related to the Vendor RBridge Channel Protocol are as follows:
图3中与供应商RBridge通道协议相关的字段如下所示：
Channel Protocol: The RBridge Channel Protocol value allocated for the Vendor Channel (see Section 4).
信道协议：为供应商信道分配的RBridge信道协议值（见第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:
供应商ID：此字段表示指定供应商渠道特定用途的供应商。此字段中的OUI或CID分配给的供应商负责使用其标识符指定供应商通道消息。根据此字段的第一个字节，如下所示：
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.
OUI：当供应商ID的第一个字节的底部两位为零（即，第一个字节为0bXXXXXX00）时，供应商ID为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.
CID：当第一个字节的底部两位为1后接零（即，第一个字节为0BXXXXXX）时，供应商ID为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).
其他：供应商ID第一个字节底部两位的其他值无效，必须返回2的VERR，但可能会受到速率限制（见第3节）。
VERR: Vendor Channel Error. See Section 3.
VERR:供应商通道错误。见第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 indicated so that multiple and evolving uses can be specified based on a single OUI.
子协议：实际上，指定供应商通道使用情况的供应商可以对VERR字段后的位执行任何操作。但强烈建议他们使用指定的子协议/子版本字段，以便可以基于单个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.
子版本：请参见上面的子协议字段说明。此字段用于指示特定供应商子协议的版本。
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.
从0x0到0x0F（含0x0F）的VERR字段值和值0xFF由IETF保留以供规范使用。见第4节。VERR的所有其他值可用于供应商指定的任何用途，但供应商通道实现不得发送供应商通道错误，以响应具有非零VERR的供应商通道消息。
The VERR values thus far specified by the IETF are as follows:
IETF迄今规定的VERR值如下：
0. The VERR field is zero in Vendor Channel messages unless the Vendor Channel packet is reporting an error.
0. 供应商通道消息中的VERR字段为零，除非供应商通道数据包报告错误。
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.
1. 值1表示RBridge通道特定数据的长度小于4字节。这意味着至少VERR字节以及可能的部分或全部OUI被截断。如果实现供应商通道设施的RBridge接收到这样的供应商通道消息，它必须将其扩展到VERR字段，将该字段设置为1，并按照第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.
2. OUI/CID字段值未知。如果RBridge实现供应商通道设施，并接收到具有零VERR字段和OUI/CID字段的供应商通道数据包，但RBridge通道报头中的SL标志为零，则必须将VERR字段设置为值2，并按照第3.1节所述返回数据包。
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.
3. 值3表示子协议字段值未知。如果RBridge实现了供应商通道设施，并且接收到满足以下条件的供应商通道数据包，则RBridge应将VERR字段设置为3，并返回第3.1节中所述的数据包：（a）RBridge通道报头中的零VERR字段，（b）RBridge通道报头中的零SL标志，（c）其实现的OUI/CID，以及（d）即使它实现并使用子协议字段，它也不识别子协议字段值。
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.
4. 值4表示子版本字段值未知。如果RBridge实现了供应商RBridge通道设施，并且接收到满足以下条件的供应商通道数据包，则RBridge应将VERR字段设置为4，并返回第3.1节中所述的数据包：（a）RBridge通道报头中的零VERR字段，（b）RBridge通道报头中的零SL标志，（c）它实现的OUI/CID和子协议，以及（d）它不识别的子版本字段值，即使它实现并使用子版本字段。
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和错误4，选择“应该”，因为只要每个消息由供应商的OUI/CID区分，就由该供应商决定标准和非标准错误处理。
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.)
IETF指定的供应商通道错误通过如上所述设置VERR字段并如下所述修改数据包来响应接收到的RBridge通道数据包。（ERR字段将为零，因为如果它非零，则数据包将在常规RBridge通道级别处理，而不是传递到供应商通道级别。）
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].)
通过设置SL标志修改RBridge信道头。（信道头中的标志和SL标志的语义在[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.
o 如果由于截断而生成错误1，则RBridge通道特定数据区域将扩展以包括VERR字节。
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 如果在RBridges之间发送供应商通道消息，则通过（1）清除M位，（2）将出口昵称设置为接收到的入口昵称，（3）将入口昵称设置为发送错误包的TRILL交换机持有的昵称，以及（4）修改TRILL报头将跳数设置为发送错误数据包的TRILL交换机使用的TRILL数据包上的常规值。
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 如果在RBridge和终端站之间沿任一方向发送了供应商通道消息，则通过（1）将outer.MacDA设置为接收时的outer.MacSA和（2）将outer.MacSA设置为发送错误包的TRILL交换机或终端站端口的MAC地址来修改外部MAC地址。
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 错误响应消息的优先级可以从导致错误的供应商香奈儿消息的优先级降低，除非它已经是最低优先级，并且可以在错误响应中设置丢弃合格性指示符位。（见[RFC6325]第4.1.1节）
o Vendor Channel error responses MAY be rate-limited.
o 供应商通道错误响应可能有速率限制。
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.
通常预期，检测到错误的整个分组将被发回，如上所述修改，作为特定于协议的有效载荷，以便，例如，错误响应可以更容易地与发送的消息匹配；但是，除错误1和2外，这取决于供应商指定如何使用其供应商RBridge通道消息。
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.
请注意，如果收到供应商通道错误消息，其中包含错误1，表示截断错误，则不能信任该供应商通道错误消息中明显的“OUI/CID”。
IANA has allocated 0x008 for the Vendor-Specific RBridge Channel Protocol from the range of RBridge Channel protocols allocated by Standards Action.
IANA已从标准行动分配的RBridge通道协议范围中为特定于供应商的RBridge通道协议分配0x008。
IANA has established a subregistry as follows in the TRILL Parameters registry (indented under "RBridge Channel Error Codes" after "RBridge Channel SubError Codes"):
IANA在TRILL参数注册表中建立了一个子区，如下所示（缩进在“RBridge Channel Error Codes”之后的“RBridge Channel Error Codes”下）：
Registry: Vendor RBridge Channel Error Codes Registration Procedures: Standards Action Reference: RFC 8381
注册表：供应商RBridge通道错误代码注册程序：标准操作参考：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
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
See [RFC6325] for general TRILL Security Considerations.
参见[RFC6325]了解一般TRILL安全注意事项。
See [RFC7178] for general RBridge Channel Security Considerations.
请参阅[RFC7178]了解一般RBridge通道安全注意事项。
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.
特定于供应商的RBridge通道协议和基本RBridge通道协议[RFC7178]均未提供任何安全保证或功能。（基本RBridge通道协议的第一个用途是作为双向转发检测（BFD）消息[RFC7175]的信封，它提供了自身的安全性。）任何需要的安全性都可以通过供应商协议特定数据中的字段或处理来提供，这不在本文档的范围之内。或者，或者另外，供应商通道的使用可以嵌套在RBridge通道头扩展协议[RFC7978]中；这可以提供一些安全服务。
[802] IEEE 802, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802-2014.
[802]IEEE 802，“局域网和城域网的IEEE标准：概述和体系结构”，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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<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>.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，DOI 10.17487/RFC7042，2013年10月<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>.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge通道支持”，RFC 7178，DOI 10.17487/RFC7178，2014年5月<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>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，DOI 10.17487/RFC7175，2014年5月<https://www.rfc-editor.org/info/rfc7175>.
[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>.
[RFC7978]Eastlake 3rd，D.，Umair，M.，和Y.Li，“大量链路的透明互连（TRILL）：RBridge信道头扩展”，RFC 7978，DOI 10.17487/RFC7978，2016年9月<https://www.rfc-editor.org/info/rfc7978>.
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为技术有限公司01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
中国南京软件大道101号宜州利华为技术有限公司210012
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China
中国南京软件大道101号华为技术有限公司，邮编：210012
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Ayan Banerjee Cisco
阿扬·班纳吉·思科
Email: ayabaner@cisco.com
Email: ayabaner@cisco.com