Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7178 Huawei
Category: Standards Track V. Manral
ISSN: 2070-1721 Ionos Corp.
Y. Li
S. Aldrin
Huawei
D. Ward
Cisco
May 2014
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7178 Huawei
Category: Standards Track V. Manral
ISSN: 2070-1721 Ionos Corp.
Y. Li
S. Aldrin
Huawei
D. Ward
Cisco
May 2014
Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support
大量链路的透明互连（TRILL）：RBridge通道支持
Abstract
摘要
This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.
本文件规定了通过扩展大量链路透明互连（TRILL）协议，在路由桥（RBridges）之间以及RBridges与RBridge园区内的终端站之间发送消息（如双向转发检测（BFD）消息）的通用信道机制。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7178.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7178.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. RBridge Channel Requirements ...............................3
1.2. Relation to the MPLS Generic Associated Channel ............4
1.3. Terminology ................................................4
2. Inter-RBridge Channel Messages ..................................4
2.1. RBridge Channel Message Inner Frame ........................6
2.1.1. RBridge Channel Header ..............................6
2.1.2. Inner Ethernet Header ...............................8
2.1.3. Inner.VLAN Tag ......................................8
2.2. TRILL Header for RBridge Channel Messages ..................9
2.3. Ethernet Link Header and Trailer ..........................10
2.4. Special Transmission and Rate Considerations ..............10
3. Processing RBridge Channel TRILL Data Messages .................11
3.1. Processing the RBridge Channel Header .....................12
3.2. RBridge Channel Errors ....................................13
4. Native RBridge Channel Frames ..................................14
5. Indicating Support for RBridge Channel Protocols ...............16
6. Congestion Considerations ......................................16
7. Allocation Considerations ......................................17
7.1. IANA Considerations .......................................17
7.2. IEEE Registration Authority Considerations ................18
8. Security Considerations ........................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
10. Acknowledgments ...............................................20
1. Introduction ....................................................3
1.1. RBridge Channel Requirements ...............................3
1.2. Relation to the MPLS Generic Associated Channel ............4
1.3. Terminology ................................................4
2. Inter-RBridge Channel Messages ..................................4
2.1. RBridge Channel Message Inner Frame ........................6
2.1.1. RBridge Channel Header ..............................6
2.1.2. Inner Ethernet Header ...............................8
2.1.3. Inner.VLAN Tag ......................................8
2.2. TRILL Header for RBridge Channel Messages ..................9
2.3. Ethernet Link Header and Trailer ..........................10
2.4. Special Transmission and Rate Considerations ..............10
3. Processing RBridge Channel TRILL Data Messages .................11
3.1. Processing the RBridge Channel Header .....................12
3.2. RBridge Channel Errors ....................................13
4. Native RBridge Channel Frames ..................................14
5. Indicating Support for RBridge Channel Protocols ...............16
6. Congestion Considerations ......................................16
7. Allocation Considerations ......................................17
7.1. IANA Considerations .......................................17
7.2. IEEE Registration Authority Considerations ................18
8. Security Considerations ........................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
10. Acknowledgments ...............................................20
RBridge campuses provide transparent least-cost forwarding using the Transparent Interconnection of Lots of Links (TRILL) protocol that builds on Intermediate System to Intermediate System (IS-IS) routing [IS-IS] [RFC1195] [RFC7176]. Devices that implement TRILL are called Routing Bridges (RBridges) or TRILL Switches. However, the TRILL base protocol standard [RFC6325] provides only for TRILL Data messages and TRILL IS-IS messages.
RBridge校园使用基于中间系统到中间系统（IS-IS）路由[IS-IS-IS][RFC1195][RFC7176]的大量链路透明互连（TRILL）协议提供透明的最低成本转发。实现TRILL的设备称为路由桥（RBridges）或TRILL交换机。然而，TRILL基本协议标准[RFC6325]仅提供TRILL数据消息和TRILL IS-IS消息。
This document specifies a general channel mechanism for the transmission of other messages within an RBridge campus, such as BFD [RFC5880] messages, (1) between RBridges and end stations that are directly connected on the same link and (2) between RBridges. This mechanism supports a requirement to be able to operate with minimal configuration.
本文件规定了在RBridge园区内传输其他消息的通用信道机制，例如BFD[RFC5880]消息，（1）在RBridge和直接连接在同一链路上的终端站之间，以及（2）在RBridge之间。该机制支持能够以最小配置运行的要求。
It is anticipated that various protocols operating at the TRILL layer will be desired in RBridge campuses. For example, there is a need for rapid-response continuity checking with a protocol such as BFD [RFC5880] [RFC5882] and for a variety of optional reporting.
预计RBridge校区需要在TRILL层运行各种协议。例如，需要使用BFD[RFC5880][RFC5882]等协议进行快速响应连续性检查，并需要各种可选报告。
To avoid the requirement to design and specify a way to carry each such protocol, this document specifies a general channel for sending messages between RBridges in a campus at the TRILL level by extending the TRILL protocol. To accommodate a wide variety of protocols, this RBridge Channel facility accommodates all the regular modes of TRILL Data transmission including single- and multiple-hop unicast as well as VLAN-scoped multi-destination distribution.
为了避免设计和指定承载每个此类协议的方式的要求，本文件通过扩展TRILL协议，指定了一个通用通道，用于在TRILL级别的校园RBridge之间发送消息。为了适应各种各样的协议，这个RBridge通道设施可以适应所有常规的TRILL数据传输模式，包括单跳和多跳单播以及VLAN范围的多目的地分发。
To minimize any unnecessary burden on transit RBridges and to provide a more realistic test of network continuity and the like, RBridge Channel messages are designed to look like TRILL Data frames and, in the case of multi-hop messages, can normally be handled by transit RBridges as if they were TRILL Data frames; however, to enable processing at transit RBridges when required by particular messages, they may optionally use the RBridge Channel Alert TRILL extended header flags [RFC7179] that causes a transit RBridge implementing the flag to more closely examine a flagged frame.
为了最大限度地减少传输RBridge上的任何不必要负担，并提供更真实的网络连续性测试等，RBridge信道消息被设计为类似于颤音数据帧，并且在多跳消息的情况下，通常可以由传输RBridge处理，就好像它们是颤音数据帧一样；然而，为了在特定消息需要时在传输RBridge上启用处理，它们可以选择性地使用RBridge信道警报TRILL扩展报头标志[RFC7179]，该标志使实现该标志的传输RBridge更仔细地检查标记的帧。
This document also specifies a format for sending RBridge Channel messages between RBridges and end stations that are directly connected over a link, in either direction, when provided for by the protocol involved. For the most part, this format is the same as the format that is encapsulated by TRILL Data for inter-RBridge Channel messages.
本文件还规定了一种格式，用于在相关协议规定的情况下，在RBridge和通过链路直接连接的终端站之间向任一方向发送RBridge信道消息。在大多数情况下，此格式与由TRILL数据封装的RBridge通道间消息格式相同。
Each particular protocol using the RBridge Channel facility will likely use only a subset of the facilities specified herein.
使用RBridge信道设施的每个特定协议很可能仅使用本文指定的设施的子集。
The RBridge Channel is similar to the MPLS Generic Associated Channel specified in [RFC5586]. Instead of using a special MPLS label to indicate a special channel message, an RBridge Channel message is indicated by a special multicast Inner.MacDA and inner Ethertype (see Section 2.1).
RBridge信道类似于[RFC5586]中指定的MPLS通用关联信道。RBridge通道消息不是使用特殊的MPLS标签来表示特殊的通道消息，而是由特殊的多播Inner.MacDA和Inner Ethertype来表示（参见第2.1节）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terminology and acronyms of [RFC6325] are used in this document with the additions listed below.
本文件使用了[RFC6325]的术语和首字母缩略词，并添加了以下内容。
BFD - Bidirectional Forwarding Detection
双向转发检测
CHV - Channel Header Version
频道头版本
MH - Multi-Hop
MH-多跳
NA - Native
土生土长的
SL - Silent
SL-静音
Channel messages between RBridges are transmitted as TRILL Data frames. (For information on channel messages that can be transmitted between RBridges and end stations that are directly connected by a link, see Section 4.) Inter-RBridge Channel messages are identified as such by their Inner.MacDA, which is the All-Egress-RBridges multicast address, together with their inner Ethertype, which is the RBridge-Channel Ethertype. This Ethertype is part of and starts the RBridge Channel Header.
RBridge之间的信道消息作为颤音数据帧传输。（有关可在RBridge和通过链路直接连接的终端站之间传输的信道消息的信息，请参见第4节。）RBridge间信道消息通过其内部.MacDA（即所有出口RBridge多播地址）及其内部Ethertype进行识别，这是RBridge通道以太类型。此Ethertype是RBridge通道头的一部分，并启动RBridge通道头。
The diagram below shows the overall structure of an RBridge Channel Message frame on a link between two RBridges:
下图显示了两个RBridge之间链路上RBridge通道消息帧的总体结构：
Frame Structure Section of This Document
------------------------
+--------------------------------+
| Link Header | Section 2.3 if Ethernet link
+--------------------------------+
| TRILL Header | Section 2.2
+--------------------------------+
| Inner Ethernet Header | Section 2.1.2
+--------------------------------+
| RBridge Channel Header | Section 2.1.1
+--------------------------------+
| Protocol-Specific Payload | See specific channel protocol
+--------------------------------+
| Link Trailer (FCS if Ethernet) |
+--------------------------------+
Frame Structure Section of This Document
------------------------
+--------------------------------+
| Link Header | Section 2.3 if Ethernet link
+--------------------------------+
| TRILL Header | Section 2.2
+--------------------------------+
| Inner Ethernet Header | Section 2.1.2
+--------------------------------+
| RBridge Channel Header | Section 2.1.1
+--------------------------------+
| Protocol-Specific Payload | See specific channel protocol
+--------------------------------+
| Link Trailer (FCS if Ethernet) |
+--------------------------------+
Figure 1: RBridge Channel Frame Structure
图1:RBridge信道帧结构
Optionally, some channel messages may require examination of the frame by transit RBridges that support the RBridge Channel feature, to determine if they need to take any action. To indicate this, such messages use an RBridge Channel Alert extended TRILL Header flag as further described in Section 3 below.
可选地，一些信道消息可能需要通过支持RBridge信道特性的传输RBridge检查帧，以确定它们是否需要采取任何操作。为了表明这一点，此类消息使用RBridge Channel Alert extended TRILL Header标志，如下文第3节所述。
Sections 2.1 and 2.2 describe the inner frame and the TRILL Header for frames sent in an RBridge Channel. As always, the outer Link Header and Link Trailer are whatever is needed to get a TRILL Data frame to the next-hop RBridge, depending on the technology of the link, and can change with each hop for multi-hop messages. Section 2.3 describes the outer Link Header for Ethernet links, and Section 2.4 discusses some special considerations for the first hop transmission of RBridge Channel messages.
第2.1节和第2.2节描述了在RBridge信道中发送的帧的内部帧和颤音报头。与往常一样，根据链路的技术，外部链路头和链路尾是将颤音数据帧发送到下一跳RBridge所需的任何东西，并且可以随多跳消息的每一跳而改变。第2.3节描述了以太网链路的外部链路头，第2.4节讨论了RBridge信道消息第一跳传输的一些特殊注意事项。
Section 3 describes some details of RBridge Channel message processing. Section 4 provides the specifications for native RBridge Channel frames between RBridges and end stations that are directly connected over a link. Section 5 describes how support for RBridge Channel protocols is indicated. And Sections 6, 7, and 8 give congestion, allocation (IANA and IEEE), and security considerations respectively.
第3节描述了RBridge通道消息处理的一些细节。第4节提供了RBridge和通过链路直接连接的终端站之间的本机RBridge信道帧的规范。第5节描述了如何表示对RBridge信道协议的支持。第6、7和8节分别给出了拥塞、分配（IANA和IEEE）和安全考虑。
The encapsulated inner frame within an RBridge Channel message frame is as shown below.
RBridge通道消息帧内的封装内部帧如下所示。
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
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA cont. | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype | Priority, DEI, VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel Ethertype | CHV | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the RBridge Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Channel-Protocol-Specific Data
| ...
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
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA cont. | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype | Priority, DEI, VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel Ethertype | CHV | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the RBridge Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Channel-Protocol-Specific Data
| ...
Figure 2: RBridge Channel Inner Frame Header Fields
图2:RBridge通道内部帧头字段
The Channel-Protocol-Specific Data contains the information related to the specific channel protocol used in the channel message. Details of that data are outside the scope of this document, except in the case of the RBridge Channel Error protocol specified in Section 3.2.
信道协议特定数据包含与信道消息中使用的特定信道协议相关的信息。该数据的详细信息不在本文件范围内，但第3.2节规定的RBridge信道错误协议除外。
As shown in Figure 2, the RBridge Channel Header starts with the RBridge-Channel Ethertype (see Section 7.2). Following that is a four-byte quantity with four sub-fields as follows:
如图2所示，RBridge Channel Header以RBridge Channel Ethertype开始（参见第7.2节）。下面是一个四字节数量，包含四个子字段，如下所示：
CHV: A 4-bit field that gives the RBridge Channel Header Version. This document specifies version zero.
CHV：一个4位字段，提供RBridge通道头版本。此文档指定版本0。
Channel Protocol: A 12-bit unsigned integer that specifies the particular RBridge Channel protocol to which the message applies.
通道协议：一个12位无符号整数，指定消息应用的特定RBridge通道协议。
Flags: Provides 12 bits of flags as described below.
标志：提供12位标志，如下所述。
ERR: A 4-bit unsigned integer used in connection with error reporting at the RBridge Channel level as described in Section 3.
ERR：一个4位无符号整数，与第3节所述的RBridge通道级别的错误报告结合使用。
The flag bits are numbered from 0 to 11 as shown below.
标志位从0到11进行编号，如下所示。
| 0 1 2 3 4 5 6 7 8 9 10 11|
+--+--+--+--+--+--+--+--+--+--+--+--+
|SL|MH|NA| Reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+
| 0 1 2 3 4 5 6 7 8 9 10 11|
+--+--+--+--+--+--+--+--+--+--+--+--+
|SL|MH|NA| Reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: Channel Header Flag Bits
图3：通道头标志位
Bit 0: The SL or Silent bit, the high-order bit in network order. If it is a one, it suppresses RBridge Channel Error messages (see Section 3).
位0：SL或静默位，网络顺序中的高阶位。如果为1，则会抑制RBridge通道错误消息（参见第3节）。
Bit 1: The MH or Multi-Hop bit. It is used to inform the destination RBridge protocol that the message may be multi-hop (MH=1) or was intended to be one-hop only (MH=0).
位1：MH或多跳位。它用于通知目的地RBridge协议消息可以是多跳（MH＝1）或打算仅为一跳（MH＝0）。
Bit 2: The NA or Native bit. It is used as described in Section 4.
位2：NA或本机位。如第4节所述使用。
Reserved: Bits reserved for future specification that MUST be sent as zero and ignored on receipt.
保留：为将来的规范保留的位，必须作为零发送，并在接收时忽略。
The RBridge Channel Protocol field specifies the protocol that the channel message relates to. The initial defined value is listed below.
RBridge Channel Protocol字段指定与通道消息相关的协议。下面列出了初始定义值。
Protocol Name - Section of This Document
-------- -------------------------------
0x001 RBridge Channel Error - Section 3
Protocol Name - Section of This Document
-------- -------------------------------
0x001 RBridge Channel Error - Section 3
IANA Considerations for RBridge Channel protocol numbers are provided in Section 7. These include provisions for Private Use protocol numbers. Because different uses of Private Use RBridge Channel protocol numbers may conflict, such use MUST be within a private network. It is the responsibility of the private network manager to avoid conflicting use of these code points and unacceptable burdens within the private network from their use.
第7节提供了RBridge信道协议编号的IANA注意事项。其中包括关于私人使用协议编号的规定。由于专用RBridge信道协议编号的不同使用可能会冲突，因此此类使用必须在专用网络内进行。专用网络管理器有责任避免冲突使用这些代码点，并避免因使用这些代码点而在专用网络内造成不可接受的负担。
The special Inner.MacDA is the All-Egress-RBridges multicast Media Access Control (MAC) address to signal that the frame is intended for the egress (decapsulating) RBridge itself (or the egress RBridges themselves if the frame is multi-destination). (This address is called the All-ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype indicates that the frame is an RBridge Channel message. The only other Ethertype currently specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI frame [RFC6325]. In the future, additional Ethertypes may be specified for use with the All-Egress-RBridges multicast address.
特殊的internal.MacDA是所有出口RBridges多播媒体访问控制（MAC）地址，表示该帧用于出口（去封装）RBridges本身（或出口RBridges本身，如果该帧是多目的地）。（此地址在[RFC6325]中称为所有ESADI RBridges地址。）RBridge通道以太类型表示帧是RBridge通道消息。当前指定用于所有出口RBridges Inner.MacDA的唯一其他以太网类型是L2-is-is，用于指示ESADI帧[RFC6325]。将来，可以指定附加的以太类型用于所有出口RBridges多播地址。
The RBridge originating the channel message selects the Inner.MacSA. The Inner.MacSA MUST be set by the originating RBridge to a MAC address unique within the campus owned by the originating RBridge. This MAC address can be considered, in effect, the MAC address of a virtual internal end station that handles the RBridge Channel frames originated by or destined for that RBridge. It MAY be the same as the Inner.MacSA used by the RBridge when it originates ESADI frames [RFC6325].
发出通道消息的RBridge选择Inner.MacSA。Inner.MacSA必须由发起RBridge设置为发起RBridge拥有的校园内唯一的MAC地址。实际上，该MAC地址可以被视为处理由该RBridge发起或目的地为该RBridge的RBridge信道帧的虚拟内部终端站的MAC地址。它可能与RBridge在发起ESADI帧时使用的Inner.MacSA相同[RFC6325]。
As with all frames formatted to be processed as a TRILL Data frame, an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 0x8100 or stacked tags is beyond the scope of this document but is an obvious extension.
与所有格式化为TRILL数据帧的帧一样，存在一个Inner.VLAN标记。使用除0x8100或堆叠标记以外的VLAN标记Ethertype超出了本文档的范围，但这是一个明显的扩展。
Multi-destination RBridge Channel messages are, like all multi-destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID MUST be set to the VLAN of interest. To the extent that distribution tree pruning is in effect in the campus, such channel messages may only reach RBridges advertising that they have connectivity to that VLAN.
与所有多目标TRILL数据消息一样，多目标RBridge通道消息的作用域为VLAN，因此必须将Inner.VLAN ID设置为感兴趣的VLAN。由于分发树修剪在校园中有效，此类通道消息可能仅到达RBridges，表明它们与该VLAN具有连接。
For channel messages sent as known unicast TRILL Data frames, the default value for the Inner.VLAN ID is VLAN 1, but particular RBridge Channel protocols MAY specify other values.
对于作为已知单播TRILL数据帧发送的通道消息，Inner.VLAN ID的默认值为VLAN 1，但特定的RBridge通道协议可能会指定其他值。
The Inner.VLAN also specifies a three-bit frame priority for which the following recommendations apply:
VLAN还指定了三位帧优先级，以下建议适用于该优先级：
1. For one-hop channel messages critical to network connectivity, such as one-hop BFD for rapid link-failure detection in support of TRILL IS-IS, the RECOMMENDED priority is 7.
1. 对于对网络连接至关重要的单跳通道消息，如支持TRILL IS-IS的用于快速链路故障检测的单跳BFD，建议的优先级为7。
2. For single and multi-hop unicast channel messages important to network operation but not critical for connectivity, the RECOMMENDED priority is 6.
2. 对于对网络运行重要但对连接不重要的单跳和多跳单播信道消息，建议的优先级为6。
3. For other unicast channel messages and all multi-destination channel messages, it is RECOMMENDED that the default priority zero be used. In any case, priorities higher than 5 SHOULD NOT be used for such frames.
3. 对于其他单播信道消息和所有多目标信道消息，建议使用默认优先级零。在任何情况下，此类帧都不应使用高于5的优先级。
There is one additional bit in a VLAN tag value between the 12-bit VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI) [RFC7180]. It is RECOMMENDED that this bit be zero for the first two categories of channel messages listed immediately above. The setting of this bit for channel messages in the third category may be dependent on the channel protocol and no general recommendation is made for that case.
在12位VLAN ID和3位优先级之间的VLAN标记值中有一个附加位，即丢弃合格性指示符（DEI）[RFC7180]。对于上面列出的前两类通道消息，建议将该位设为零。第三类信道消息的该位的设置可能取决于信道协议，对于这种情况没有一般性建议。
After the outer Link Header (that, for an Ethernet link, ends with the TRILL Ethertype) and before the encapsulated frame, the channel message's TRILL Header initially appears as follows:
在外部链路头（对于以太网链路，以TRILL Ethertype结尾）之后和封装帧之前，通道消息的TRILL头最初显示如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0| R |M| Op-Len | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0| R |M| Op-Len | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RBridge Channel TRILL Header Fields
图4:RBridge通道颤音报头字段
The TRILL Header version (V) MUST be zero; the R bits are reserved; the M bit is set appropriately as the channel message is to be forwarded as known destination unicast (M=0) or multi-destination (M=1), regardless of the fact that the Inner.MacDA is always the All-Egress-RBridges multicast address; and Op-Len is set appropriately for the length of the TRILL Header extensions area, if any, all as specified in [RFC6325].
颤音标题版本（V）必须为零；R位被保留；M位被适当地设置为信道消息将被转发为已知目的地单播（M＝0）或多目的地（M＝1），而不管internal.MacDA始终是所有出口RBridges多播地址这一事实；如果有颤音标题扩展区域，则根据[RFC6325]中的规定适当设置Op Len。
When an RBridge Channel message is originated, the Hop Count field defaults to the maximum value, 0x3F, but particular RBridge Channel protocols MAY specify other values. For messages sent a known number of hops, such as one-hop messages or a two-hop self-addressed message intended to loop back through an immediate neighbor RBridge, setting the Hop Count field in the TRILL Header to the maximum value and checking its value on receipt provides an additional validity check
当发起RBridge信道消息时，跃点计数字段默认为最大值0x3F，但特定RBridge信道协议可能指定其他值。对于发送了已知跳数的消息，例如一跳消息或两跳自寻址消息，打算通过直接相邻的RBridge回环，将TRILL报头中的跳数字段设置为最大值，并在收到时检查其值，可提供额外的有效性检查
as discussed in [RFC5082], where this type of field is referred to as "TTL" or "Hop Limit".
如[RFC5082]中所述，这种类型的字段称为“TTL”或“跃点限制”。
The RBridge originating a channel message places a nickname that it holds in the Ingress Nickname field.
发起信道消息的RBridge在入口昵称字段中放置其持有的昵称。
There are several cases for the Egress Nickname field. If the channel message is multi-destination, then the Egress Nickname designates the distribution tree to use. If the channel message is a multi-hop unicast message, then the Egress Nickname is a nickname of the target RBridge; this includes the special case of a message intended to loop back from an immediate neighbor where the originator places one of its own nicknames in both the Ingress Nickname and Egress Nickname fields. If the channel message is a one-hop unicast message, there are two possibilities for the Egress Nickname.
出口昵称字段有几种情况。如果通道消息是多目的地，则出口昵称指定要使用的分发树。如果信道消息是多跳单播消息，则出口昵称是目标RBridge的昵称；这包括一个消息的特殊情况，该消息打算从一个直接邻居回环，其中发起者在入口昵称和出口昵称字段中放置自己的一个昵称。如果信道消息是单跳单播消息，则出口昵称有两种可能。
o The Egress Nickname can be set to a nickname of the target neighbor RBridge.
o 出口昵称可以设置为目标邻居RBridge的昵称。
o The special nickname Any-RBridge may be used. RBridges supporting the RBridge Channel facility MUST recognize the Any-RBridge special nickname and accept TRILL Data frames having that value in the Egress Nickname field as being sent to them as the egress. Thus, for such RBridges, using this egress nickname guarantees processing by an immediate neighbor regardless of the state of nicknames.
o 可以使用特殊的昵称Any RBridge。支持RBridge信道设施的RBridge必须识别任何RBridge特殊昵称，并接受在出口昵称字段中具有该值的TRILL数据帧作为出口发送给它们。因此，对于这样的rbridge，使用这个出口昵称可以保证由直接邻居进行处理，而不管昵称的状态如何。
An RBridge Channel frame has the usual Link Header and Link Trailer for a TRILL Data frame depending on the type of link on which it is sent.
RBridge信道帧具有TRILL数据帧的常用链路头和链路尾，具体取决于发送它的链路类型。
For an Ethernet link [RFC6325], the Outer.MacSA is the MAC address of the port from which the frame is sent. The Outer.MacDA is the MAC address of the next-hop RBridge port for unicast RBridge Channel messages or the All-RBridges multicast address for multi-destination RBridge Channel messages. The Outer.VLAN tag specifies the designated VLAN for that hop, and the priority should be the same as in the Inner.VLAN tag; however, the output port may have been configured to strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. And the Link Trailer is the Ethernet FCS.
对于以太网链路[RFC6325]，Outer.MacSA是发送帧的端口的MAC地址。Outer.MacDA是单播RBridge信道消息的下一跳RBridge端口的MAC地址，或多目标RBridge信道消息的所有RBridge多播地址。Outer.VLAN标记指定该跃点的指定VLAN，优先级应与Inner.VLAN标记中的优先级相同；但是，输出端口可能已配置为剥离VLAN标记，在这种情况下，导线上不会显示Outer.VLAN标记。链路拖车是以太网FCS。
If a multi-hop RBridge Channel message is received by an RBridge, the criteria and method of forwarding it are the same as for any TRILL Data frame. If it is so forwarded, it will be on a link that was
如果RBridge接收到多跳RBridge信道消息，则转发该消息的标准和方法与任何TRILL数据帧相同。如果它是这样转发的，那么它将位于一个
included in the routing topology because it was in the Report state as specified in [RFC7177].
包含在路由拓扑中，因为它处于[RFC7177]中指定的报告状态。
However, special considerations apply to single-hop messages because, for some RBridge Channel protocols, it may be desirable to send RBridge Channel messages over a link that is not yet fully up. In particular, it is permissible, if specified by the particular channel protocol, for the source RBridge that has created an RBridge Channel message to attempt to transmit it to a next-hop RBridge when the link is in the Detect or 2-Way state, as specified in [RFC7177], as well as when it is in the Report state. Such messages can also be sent on point-to-point links that are not in the Up state.
然而，特殊注意事项适用于单跳消息，因为对于某些RBridge信道协议，可能希望通过尚未完全接通的链路发送RBridge信道消息。特别是，如果由特定信道协议指定，则当链路处于[RFC7177]中指定的检测或双向状态以及处于报告状态时，允许已创建RBridge信道消息的源RBridge尝试将其传输到下一跳RBridge。这样的消息也可以在不处于Up状态的点到点链路上发送。
RBridge Channel messages represent a burden on the RBridges, and links in a campus and should be rate limited, especially if they are sent as high priority, multi-destination, or multi-hop frames or have an RBridge Channel Alert extended header flag set. See Section 6, "Congestion Considerations".
RBridge通道消息代表了校园中RBridge和链路的负担，应限制速率，尤其是当它们作为高优先级、多目的地或多跳帧发送或设置了RBridge通道警报扩展报头标志时。见第6节“拥挤考虑”。
RBridge Channel TRILL Data messages are designed to look like and, to the extent practical, be forwarded as regular TRILL Data frames. On receiving a channel message, an RBridge performs the usual initial tests on the frame and makes the same forwarding and/or decapsulation decisions as for a regular TRILL Data frame [RFC6325] with the following exceptions for RBridges implementing the RBridge Channel facility:
RBridge Channel TRILL数据消息的设计与常规TRILL数据帧类似，并且在实际范围内可以作为常规TRILL数据帧转发。在接收到信道消息时，RBridge对帧执行通常的初始测试，并作出与常规TRILL数据帧相同的转发和/或解除封装决定[RFC6325]，但对于实现RBridge信道设施的RBridge，以下情况除外：
1. An RBridge implementing the RBridge Channel facility MUST recognize the Any-RBridge egress nickname in TRILL Data frames, decapsulating such frames if they meet other checks. (Such a frame cannot be a valid multi-destination frame because the Any-RBridge nickname is not a valid distribution tree root.)
1. 实现RBridge通道设施的RBridge必须识别TRILL数据帧中的任何RBridge出口昵称，如果这些帧满足其他检查，则对其进行解封装。（这样的帧不能是有效的多目标帧，因为Any RBridge昵称不是有效的分发树根。）
2. If an RBridge Channel Alert extended header flag is set, then the RBridge MUST process the RBridge Channel message as described below even if it is not egressing the frame. If it is egressing the frame, then no additional processing beyond egress processing is needed even if an RBridge Channel Alert flag is set.
2. 如果设置了RBridge Channel Alert extended header标志，则RBridge必须如下所述处理RBridge Channel消息，即使它没有退出帧。如果正在退出帧，则即使设置了RBridge信道警报标志，也不需要除退出处理之外的额外处理。
3. On decapsulation, the special Inner.MacDA value of All-Egress-RBridges MUST be recognized to trigger checking the Inner.Ethertype and processing as an RBridge Channel message if that Ethertype is RBridge-Channel.
3. 在解除封装时，必须识别所有出口RBridge的特殊Inner.MacDA值，以触发检查Inner.Ethertype并将其作为RBridge通道消息处理（如果该Ethertype是RBridge通道）。
RBridge Channel messages SHOULD only be sent to RBridges that advertise support for the channel protocol involved as described in Section 5.
RBridge信道消息应仅发送给通告支持第5节所述信道协议的RBridge。
All RBridges supporting the RBridge Channel facility MUST recognize the RBridge-Channel inner Ethertype.
支持RBridge通道设施的所有RBridge必须识别RBridge通道内部以太网类型。
Knowing that it has an RBridge Channel message, the egress RBridge, and any transit RBridge if an RBridge Channel Alert bit is set in the TRILL Header, looks at the CHV (RBridge Channel Header Version) and Channel Protocol fields.
如果TRILL报头中设置了RBridge信道警报位，则知道其具有RBridge信道消息、出口RBridge和任何传输RBridge，查看CHV（RBridge信道报头版本）和信道协议字段。
If any of the following conditions occur at an egress RBridge, the frame is not processed, an error may be generated as specified in Section 3.2, and the frame is discarded. The behavior is the same if the frame is being processed at a transit RBridge because the RBridge Critical Channel Alert flag is set [RFC7179]. However, if these conditions are detected at a transit RBridge examining the message because the RBridge Non-critical Channel Alert flag is set [RFC7179] but the RBridge Critical Channel Alert flag is not set, no error is generated, and the frame is still forwarded normally.
如果出口RBridge处出现以下任何情况，则不处理帧，可能会产生第3.2节规定的错误，并丢弃帧。如果帧在传输RBridge处处理，则行为相同，因为RBridge临界信道警报标志已设置[RFC7179]。但是，如果由于设置了RBridge非关键信道警报标志[RFC7179]，但未设置RBridge关键信道警报标志，因此在传输RBridge检查消息时检测到这些条件，则不会生成错误，并且帧仍正常转发。
Error Conditions:
错误条件：
1. The Ethertype is not RBridge-Channel and not any other Ethertype known to the RBridge as usable with the All-Egress-RBridges Inner.MacDA, or the frame is so short that the Ethertype is truncated.
1. Ethertype不是RBridge Channel，也不是RBridge已知的可用于所有出口RBridges Inner.MacDA的任何其他Ethertype，或者帧太短，以至于Ethertype被截断。
2. The CHV field is non-zero, or the frame is so short that the version zero Channel Header is truncated.
2. CHV字段为非零，或者帧太短，以至于版本为零的通道标头被截断。
3. The Channel Protocol field is a reserved value or a value unknown to the processing RBridge.
3. 通道协议字段是保留值或处理RBridge未知的值。
4. The ERR field is non-zero, and Channel Protocol is a value other than 0x001.
4. ERR字段为非零，通道协议为0x001以外的值。
5. The RBridge Channel Header NA flag is set to one, indicating that the frame should have been received as a native frame rather than a TRILL Data frame.
5. RBridge Channel Header NA标志设置为1，表示该帧应作为本机帧而不是TRILL数据帧接收。
If the CHV field and NA flag are zero and the processing RBridge recognizes the Channel Protocol value, it processes the message in accordance with that channel protocol. The processing model is as if the received frame starting with and including the TRILL Header is
如果CHV字段和NA标志为零，且处理RBridge识别信道协议值，则它将根据该信道协议处理消息。处理模型就好像接收到的帧以TRILL报头开始并包括TRILL报头一样
delivered to the Channel protocol along with a flag indicating whether this is (a) transit RBridge processing due to an RBridge Channel Alert flag being set or (b) egress processing.
与一个标志一起交付到信道协议，该标志指示这是（a）由于设置了RBridge信道警报标志而进行的传输RBridge处理还是（b）出口处理。
Errors within a recognized Channel Protocol are handled by that channel protocol itself and do not produce RBridge Channel Error frames.
识别的信道协议中的错误由该信道协议本身处理，并且不会产生RBridge信道错误帧。
A variety of problems at the RBridge Channel level cause the return of an RBridge Channel Error frame unless one of the following apply: (a) the "SL" (Silent) flag is a one in the channel message for which the problem was detected, (b) the processing is due to the RBridge Non-critical Channel Alert flag being set, (c) the frame in error appears, itself, to be an RBridge Channel Error frame (has a non-zero ERR field or a Channel Protocol of 0x001), or (d) the error is suppressed due to rate limiting.
RBridge信道级别的各种问题会导致返回RBridge信道错误帧，除非以下情况之一适用：（A）“SL”（静默）标志是检测到问题的信道消息中的标志，（b）处理是由于设置了RBridge非关键信道警报标志，（c）出现错误帧，本身，作为RBridge信道错误帧（具有非零错误字段或0x001信道协议），或（d）由于速率限制，错误被抑制。
An RBridge Channel Error frame is a multi-hop unicast RBridge Channel message with the Ingress Nickname set to a nickname of the RBridge detecting the error and the Egress Nickname set to the value of the Ingress Nickname in the channel message for which the error was detected. No per-hop transit processing is specified for such error frames, so the RBridge Channel Alert extended header flags SHOULD, if an extension is present, be set to zero. The SL and MH flags SHOULD be set to one; the NA flag MUST be zero; and the ERR field MUST be non-zero as described below. For the protocol-specific data area, an RBridge Channel Message Error frame has at least the first 256 bytes (or less if less are available) of the erroneous decapsulated channel message starting with the TRILL Header. (Note: The TRILL Header does not include the TRILL Ethertype that is part of the Link Header on Ethernet links.)
RBridge信道错误帧是多跳单播RBridge信道消息，入口昵称设置为检测到错误的RBridge的昵称，出口昵称设置为检测到错误的信道消息中入口昵称的值。没有为此类错误帧指定每跳传输处理，因此如果存在扩展，则RBridge Channel Alert extended header标志应设置为零。SL和MH标志应设置为一个；NA标志必须为零；并且ERR字段必须为非零，如下所述。对于特定于协议的数据区域，RBridge信道消息错误帧至少具有从TRILL报头开始的错误解封装信道消息的前256个字节（如果可用的字节更少，则更少）。（注意：TRILL标头不包括作为以太网链路上链路标头一部分的TRILL Ethertype。）
The following values for ERR are specified:
指定了以下ERR值：
ERR RBridge Channel Error Code Meaning
--- ----------------------------------
0 No error
1 Frame too short (truncated Ethertype or Channel Header)
2 Unrecognized Ethertype
3 Unimplemented value of CHV
4 Wrong value of NA flag
5 Channel Protocol is reserved or unimplemented
6-14 Unassigned (see Section 7)
15 Reserved (see Note)
ERR RBridge Channel Error Code Meaning
--- ----------------------------------
0 No error
1 Frame too short (truncated Ethertype or Channel Header)
2 Unrecognized Ethertype
3 Unimplemented value of CHV
4 Wrong value of NA flag
5 Channel Protocol is reserved or unimplemented
6-14 Unassigned (see Section 7)
15 Reserved (see Note)
Note: Intended to be allocated by Standards Action for an error code expansion feature when it appears likely that all other available error codes are being allocated.
注：当所有其他可用的错误代码可能正在分配时，由标准操作为错误代码扩展功能分配。
All RBridges implementing the RBridge Channel feature MUST recognize the RBridge Channel Error protocol value (0x001). They MUST NOT generate an RBridge Channel Error message in response to an RBridge Channel Error message, that is, a channel message with a protocol value of 0x001 or with a non-zero ERR field.
所有实现RBridge通道功能的RBridge必须识别RBridge通道错误协议值（0x001）。它们不得生成响应RBridge通道错误消息的RBridge通道错误消息，即协议值为0x001或错误字段非零的通道消息。
Other sections of this document specify non-native RBridge Channel messages and their processing, that is, RBridge Channel messages formatted as TRILL Data frames and sent between RBridges. This section specifies the differences for native RBridge Channel messages.
本文档的其他章节规定了非本机RBridge通道消息及其处理，即格式化为TRILL数据帧并在RBridge之间发送的RBridge通道消息。本节指定本机RBridge通道消息的差异。
If provided for by the channel protocol involved, native RBridge Channel messages may be sent between end stations and RBridges that are directly connected over a link, in either direction. On an Ethernet link, such native frames have the RBridge-Channel Ethertype and are like the encapsulated frame inside an RBridge Channel message except as follows:
如果由所涉及的信道协议提供，则本机RBridge信道消息可以在终端站和通过链路直接连接的RBridge之间以任意方向发送。在以太网链路上，此类本机帧具有RBridge Channel Ethertype，与RBridge Channel消息中的封装帧类似，但以下情况除外：
1. TRILL does not require the presence of a VLAN tag on such native RBridge Channel frames. However, port configuration, link characteristics, or the channel protocol involved may require such tagging.
1. TRILL不要求在此类本机RBridge通道帧上存在VLAN标记。然而，端口配置、链路特性或涉及的信道协议可能需要此类标记。
2. If the frame is unicast, the destination MAC address is the unicast MAC address of the RBridge or end-station port that is its intended destination. If the frame is multicast by an end station to all the RBridges on a link that support an RBridge Channel protocol using this transport, the destination MAC address is the All-Edge-RBridges multicast address (see Section 7). A native RBridge Channel frame received at an ingress RBridge is discarded if its destination MAC address is neither the unicast address of the port nor the multicast address All-Edge-RBridges. If the frame is multicast by an RBridge to all the devices that TRILL considers to be end stations on a link and that support an RBridge Channel protocol using this transport, the destination MAC address is the TRILL-End-Stations multicast address (see Section 7). A native RBridge Channel frame received at an end station is discarded if its destination MAC address is neither the unicast address of the port nor the multicast address TRILL-End-Stations.
2. 如果帧是单播的，则目标MAC地址是作为其预期目的地的RBridge或终端站端口的单播MAC地址。如果该帧由终端站通过该传输多播到支持RBridge信道协议的链路上的所有RBridge，则目标MAC地址为所有边缘RBridge多播地址（参见第7节）。如果在入口RBridge接收的本机RBridge信道帧的目标MAC地址既不是端口的单播地址，也不是所有边缘RBridge的多播地址，则丢弃该本机RBridge信道帧。如果帧由RBridge多播到TRILL认为是链路上的终端站并且支持使用此传输的RBridge信道协议的所有设备，则目标MAC地址是TRILL终端站多播地址（参见第7节）。如果在终端站接收的本机RBridge信道帧的目标MAC地址既不是端口的单播地址，也不是TRILL终端站的多播地址，则丢弃该帧。
3. The RBridge-Channel outer Ethertype must be present. In the future, there may be other protocols using the All-Edge-RBridges and/or TRILL-End-Stations multicast addresses on native frames distinguished by different Ethertypes.
3. RBridge通道外部以太网类型必须存在。将来，可能有其他协议使用由不同以太类型区分的本机帧上的所有边缘rbridge和/或TRILL终端站多播地址。
4. The NA or Native bit in the RBridge Channel Header flags MUST be a one.
4. RBridge通道头标志中的NA或本机位必须为1。
5. There might be additional tags present between the Outer.MacDA, Outer.MacSA pair, and the RBridge-Channel Ethertype.
5. 在Outer.MacDA、Outer.MacSA对和RBridge通道类型之间可能存在其他标记。
The RBridge Channel protocol number space for native RBridge Channel messages and TRILL Data formatted RBridge Channel messages is the same. If provided for by the channel protocol involved, the receipt of a native RBridge Channel frame MAY lead to the generation and transmission of one or more Inter-RBridge Channel frames. The decapsulation and processing of a TRILL Data RBridge Channel frame MAY, if provided for by the channel protocol involved, result in the sending of one or more native RBridge Channel frames to one or more end stations. Thus, there could be an RBridge Channel protocol that involved an RBridge Channel message sent (1) from an origin RBridge where the message is created, (2) through one or more transit RBridges, and (3) from a final RBridge as a native RBridge Channel message to an end station (or the reverse of such a three-part path); however, to do this, the RBridge Channel protocol involved must be implemented at the RBridge where the channel message is changed between a native frame and a TRILL Data format frame, and that RBridge must change the channel message itself, at a minimum complementing the NA flag in the Channel Header and making appropriate MAC address changes.
本机RBridge通道消息和TRILL数据格式的RBridge通道消息的RBridge通道协议编号空间相同。如果由所涉及的信道协议提供，则本机RBridge信道帧的接收可导致一个或多个RBridge间信道帧的生成和传输。如果由所涉及的信道协议提供，TRILL数据RBridge信道帧的解封装和处理可导致向一个或多个终端站发送一个或多个本机RBridge信道帧。因此，可能存在一种RBridge信道协议，该协议涉及（1）从创建消息的原始RBridge发送的RBridge信道消息，（2）通过一个或多个传输RBridge，以及（3）从作为本地RBridge信道消息的最终RBridge发送到终端站（或这样的三部分路径的相反）；然而，要做到这一点，所涉及的RBridge信道协议必须在RBridge实现，其中信道消息在本机帧和TRILL数据格式帧之间改变，并且RBridge必须改变信道消息本身，至少补充信道报头中的NA标志并进行适当的MAC地址改变。
An erroneous native channel message results in a native RBridge Channel Error message under the same conditions for which a TRILL Data RBridge Channel message would result in a TRILL Data RBridge Channel Error message. However, in a native RBridge Channel Error message, the NA flag MUST be one. Also, since there is no TRILL Header in native RBridge Channel protocol frames, the beginning part of the frame in which the error was detected that is included in native RBridge Channel Error frames starts with the RBridge Channel Header (including the RBridge-Channel Ethertype). The destination MAC address of such error messages is set to the source MAC address of the native RBridge Channel message that was in error.
错误的本机通道消息会导致本机RBridge通道错误消息，条件与TRILL数据RBridge通道消息会导致TRILL数据RBridge通道错误消息的条件相同。但是，在本机RBridge通道错误消息中，NA标志必须为1。此外，由于本机RBridge信道协议帧中没有TRILL报头，因此本机RBridge信道错误帧中包含的检测到错误的帧的开始部分以RBridge信道报头（包括RBridge信道以太网类型）开始。此类错误消息的目标MAC地址设置为出错的本机RBridge通道消息的源MAC地址。
There is no mechanism to stop end stations from directly exchanging native RBridge Channel messages, but such usage is beyond the scope of this document.
没有阻止终端站直接交换本机RBridge通道消息的机制，但这种使用超出了本文档的范围。
Support for RBridge Channel protocols is indicated by the presence of one or more TLVs and/or sub-TLVs in an RBridge's Link State PDU (LSP) as documented in [RFC7176].
如[RFC7176]中所述，RBridge的链路状态PDU（LSP）中存在一个或多个TLV和/或子TLV，表明对RBridge信道协议的支持。
RBridge Channel protocols 0 and 0xFFF are reserved, and protocol 1, the RBridge Channel Error protocol, MUST be implemented as part of the RBridge Channel feature. Thus, if an RBridge supports the RBridge Channel feature, it should be advertising support for protocol 1 and not advertising support for protocols 0 or 0xFFF in its LSP. However, indication of support or non-support for RBridge Channel protocol 1 is ignored on receipt, and support for it is always assumed if support for any RBridge Channel is indicated in the RBridge's LSP.
保留RBridge通道协议0和0xFFF，协议1（RBridge通道错误协议）必须作为RBridge通道功能的一部分实现。因此，如果RBridge支持RBridge信道功能，那么它应该是对协议1的广告支持，而不是对其LSP中的协议0或0xFFF的广告支持。然而，在接收时忽略对RBridge信道协议1的支持或不支持的指示，并且如果在RBridge的LSP中指示对任何RBridge信道的支持，则始终假定对它的支持。
The bandwidth resources used by RBridge Channel protocols are recommended to be small compared to the total bandwidth of the links they traverse. When doing network planning, the bandwidth requirements for TRILL Data, TRILL IS-IS, TRILL ESADI, RBridge Channel protocol traffic, and any other link-local traffic need to be taken into account.
建议RBridge信道协议使用的带宽资源与它们所穿越的链路的总带宽相比要小。在进行网络规划时，需要考虑TRILL数据、TRILL IS-IS、TRILL ESADI、RBridge信道协议流量和任何其他链路本地流量的带宽要求。
Specifications for particular RBridge Channel protocols MUST consider congestion and bandwidth usage implications and provide guidance on bandwidth or packet-frequency management. RBridge Channel protocols can have built-in bandwidth management in their protocols. Outgoing channel messages SHOULD be rate-limited, by configuring the underlying protocols or otherwise, to prevent aggressive connectivity verification or other applications consuming excessive bandwidth, causing congestion, or becoming denial-of-service attacks.
特定的R桥桥信道协议的规范必须考虑拥塞和带宽使用的影响，并为带宽或分组频率管理提供指导。RBridge信道协议可以在其协议中内置带宽管理。传出通道消息应通过配置底层协议或其他方式进行速率限制，以防止主动连接验证或其他应用程序占用过多带宽，造成拥塞或成为拒绝服务攻击。
If these conditions cannot be followed, an adaptive loss-based scheme SHOULD be applied to congestion-control outgoing RBridge Channel traffic, so that it competes fairly, taking into account packet priorities and drop eligibility as indicated in the Inner.VLAN, with TCP or similar traffic within an order of magnitude. One method of determining an acceptable bandwidth for RBridge Channel traffic is described in [RFC5348]; other methods exist. For example, bandwidth or packet-frequency management can include any of the following: a negotiation of transmission interval/rate such as that provided in BFD [RFC5880], a throttled transmission rate on "congestion detected" situations, a gradual ramp-up after shutdown due to congestion and until basic connectivity is verified, and other mechanisms.
如果无法满足这些条件，则应将基于自适应丢失的方案应用于拥塞控制传出RBridge通道流量，以便它公平竞争，同时考虑到Inner.VLAN中指示的数据包优先级和丢弃资格，与TCP或类似流量在一个数量级内竞争。[RFC5348]中描述了确定RBridge信道业务的可接受带宽的一种方法；还有其他方法。例如，带宽或分组频率管理可以包括以下任何一项：传输间隔/速率的协商，如BFD[RFC5880]中提供的，在“检测到拥塞”情况下的节流传输速率，由于拥塞而关机后的逐渐爬升，直到基本连接得到验证，以及其他机制。
Connectivity-checking applications such as BFD [RFC5880] SHOULD be rate-limited to below 5% of the bitrate of the associated link or links. For this purpose, the mean or sustained bitrate of the link or links is used.
诸如BFD[RFC5880]之类的连接检查应用程序的速率应限制在相关链路比特率的5%以下。为此，使用一个或多个链路的平均或持续比特率。
Incoming RBridge Channel messages MAY be rate-limited as a protection against denial-of-service attacks. This throttling of incoming messages SHOULD honor packet priorities and drop eligibility indications as indicated in the Inner.VLAN, preferentially discarding drop-eligible and lower-priority packets.
传入的RBridge通道消息可能会受到速率限制，以防止拒绝服务攻击。此传入消息的限制应遵守Inner.VLAN中指示的数据包优先级和丢弃合格指示，优先丢弃丢弃合格和较低优先级的数据包。
The following subsections give IANA and IEEE allocation considerations. In this document, the allocation procedure specifications are as defined in [RFC5226].
以下小节给出了IANA和IEEE分配注意事项。在本文件中，分配程序规范如[RFC5226]所述。
IANA has allocated a previously unassigned TRILL Nickname as follows:
IANA分配了一个以前未分配的颤音昵称，如下所示：
Any-RBridge 0xFFC0
任何RBridge 0xFFC0
IANA has added "All-Egress-RBridges" to the TRILL Parameter Registry as an alternative name for the "All-ESADI-RBridges" multicast address.
IANA已将“所有出口RBridges”添加到TRILL参数注册表中，作为“所有ESADI RBridges”多播地址的替代名称。
IANA has allocated two previously unassigned TRILL multicast addresses as follows:
IANA分配了两个以前未分配的TRILL多播地址，如下所示：
TRILL-End-Stations 01-80-C2-00-00-45 All-Edge-RBridges 01-80-C2-00-00-46
颤音终端站01-80-C2-00-00-45所有边缘RBridges 01-80-C2-00-00-46
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Protocols, with initial contents as follows:
IANA在TRILL参数注册表中为RBridge通道协议创建了一个附加子注册表，初始内容如下：
Protocol Description Reference
-------- ----------- ---------
Protocol Description Reference
-------- ----------- ---------
0x000 Reserved; not to be allocated (This document) 0x001 RBridge Channel Error (This document) 0x002-0x0FF Unassigned (1) 0x100-0xFF7 Unassigned (2) 0xFF8-0xFFE Reserved for Private Use 0xFFF Reserved; not to be allocated (This document)
0x000预留；未分配（本文件）0x001 RBridge通道错误（本文件）0x002-0x0FF未分配（1）0x100-0xFF7未分配（2）0xFF8-0xFFE保留供私人使用0xFFF保留；不分配（本文件）
(1) RBridge Channel protocol code points from 0x002 to 0x0FF require a Standards Action, as modified by [RFC7120], for allocation.
(1) 从0x002到0x0FF的RBridge通道协议代码点需要标准操作（由[RFC7120]修改）进行分配。
(2) RBridge Channel protocol code points from 0x100 to 0xFF7 are RFC Required to allocate a single value or IESG Approval to allocate multiple values.
(2) 从0x100到0xFF7的RBridge通道协议代码点是分配单个值所需的RFC或分配多个值所需的IESG批准。
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Header Flags with initial contents as follows:
IANA已在TRILL参数注册表中为RBridge Channel Header Flags创建了额外的子注册表，初始内容如下：
Flag Bit Mnemonic Allocation
-------- -------- ----------
Flag Bit Mnemonic Allocation
-------- -------- ----------
0 SL Silent 1 MH Multi-hop 2 NA Native 3-11 - Unassigned
0 SL静默1 MH多跳2 NA本机3-11-未分配
Allocation of an RBridge Channel Header Flag is based on IETF Review.
RBridge信道头标志的分配基于IETF审查。
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Error Codes with initial contents as listed in Section 3.2 above and with available values allocated by Standards Action as modified by [RFC7120].
IANA已在TRILL参数注册表中为RBridge通道错误代码创建了额外的子注册表，初始内容如上文第3.2节所列，可用值由[RFC7120]修改的标准行动分配。
The IEEE Registration Authority has assigned the Ethertype 0x8946 for TRILL RBridge Channel.
IEEE注册机构已为TRILL RBridge信道分配Ethertype 0x8946。
No general integrity, authentication, or encryption mechanisms are provided herein for RBridge Channel messages. If these services are required for a particular RBridge Channel protocol, they MUST be supplied by that channel protocol. See, for example, the BFD Authentication mechanism [RFC5880].
本文没有为RBridge信道消息提供一般完整性、认证或加密机制。如果特定RBridge通道协议需要这些服务，则必须由该通道协议提供。例如，请参见BFD身份验证机制[RFC5880]。
See [RFC6325] for general TRILL security considerations. As stated therein, no protection is provided by TRILL against forging of the Ingress Nickname in a TRILL Data formatted channel message or the Outer.MacSA in a native RBridge Channel frame on an Ethernet link. This may result in misdirected return responses or error messages. However, link-level security protocols may be used to authenticate the origin station on a link and protect against attacks on links. See also Section 6 concerning congestion.
参见[RFC6325]了解一般TRILL安全注意事项。如本文所述，TRILL不提供任何保护，以防止在TRILL数据格式的通道消息中伪造入口昵称，或在以太网链路上的本机RBridge通道帧中伪造Outer.MacSA。这可能会导致错误的返回响应或错误消息。然而，链路级安全协议可用于认证链路上的源站并防止链路上的攻击。另见第6节关于拥挤的内容。
If indications of RBridge Channel Protocol support are improperly absent from an RBridge's LSP, it could deny all RBridge Channel services, for example, some BFD services, for the RBridge in question. If a particular RBridge Channel protocol is incorrectly not advertised as supported, it could deny the service of that channel protocol to the RBridge in question.
如果RBridge的LSP中不正确地缺少对RBridge信道协议支持的指示，则它可能会拒绝所有RBridge信道服务，例如，某些BFD服务，用于所讨论的RBridge。如果某个特定的RBridge通道协议未被错误地公布为受支持，则它可能会拒绝该通道协议对相关RBridge的服务。
Incorrect indication of RBridge Channel Protocol support or incorrect assertion of support for a channel protocol could encourage RBridge Channel messages to be sent to an RBridge that does not support the channel feature or the particular channel protocol used. The inner frame of such messages could be decapsulated and that inner frame could be sent out all ports that are Appointed Forwarders for the frame's Inner.VLAN. However, this is unlikely to cause much harm; in particular, there are two possibilities as follows: (a) if end stations do not recognize the RBridge-Channel Ethertype of the frame, they will drop it, and (b) if end stations do recognize the RBridge-Channel Ethertype and the channel protocol indicated in the frame, they should refuse to process the frame due to an incorrect value of the RBridge Channel Header NA flag.
对RBridge通道协议支持的错误指示或对通道协议支持的错误断言可能会鼓励将RBridge通道消息发送到不支持通道功能或所用特定通道协议的RBridge。此类消息的内部帧可以被解除封装，并且该内部帧可以被发送到为帧的inner.VLAN指定转发器的所有端口。然而，这不太可能造成多大伤害；具体而言，有以下两种可能性：（a）如果终端站不识别帧的RBridge信道以太类型，它们将丢弃它；（b）如果终端站识别帧中指示的RBridge信道以太类型和信道协议，由于RBridge Channel Header NA标志的值不正确，他们应该拒绝处理帧。
[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", Second Edition, November 2002.
[IS-IS]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，第二版，2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，2011年7月。
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，2014年1月。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，2014年5月。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（TRILL）：邻接”，RFC 7177，2014年5月。
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014.
[RFC7179]Eastlake 3rd，D.，Ghanwani，A.，Manral，V.，Li，Y.，和C.Bestler，“大量链路的透明互连（TRILL）：报头扩展”，RFC 7179，2014年5月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[RFC5882]Katz，D.和D.Ward，“双向转发检测（BFD）的一般应用”，RFC 5882，2010年6月。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
[RFC7180]Eastlake 3rd，D.，Zhang，M.，Ghanwani，A.，Manral，V.，和A.Banerjee，“大量链路的透明互连（TRILL）：澄清、更正和更新”，RFC 7180，2014年5月。
The authors gratefully acknowledge the comments and contributions of the follows, listed is alphabetic order: Stewart Bryant, Somnath Chatterjee, Adrian Farrel, Stephen Farrell, Miguel A. Garcia, Anoop Ghanwani, Brian Haberman, Rakesh Kumar, Barry Leiba, and Tissa Senevirathne.
作者感谢以下作者的评论和贡献，按字母顺序排列：Stewart Bryant、Somnath Chatterjee、Adrian Farrell、Stephen Farrell、Miguel A.Garcia、Anoop Ghanwani、Brian Haberman、Rakesh Kumar、Barry Leiba和Tissa Senevirathne。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com
Donald Eastlake 3rd华为研发美国马萨诸塞州米尔福德海狸街155号01757美国电话：+1-508-333-2270电子邮件：d3e3e3@gmail.com
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA EMail: vishwas@ionosnetworks.com
Vishwas Manral Ionios Corp.地址：美国加利福尼亚州圣何塞摩尔帕克大道4100号，邮编：95117电子邮件：vishwas@ionosnetworks.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56622310 EMail: liyizhou@huawei.com
宜州利华为技术有限公司南京软件大道101号210012中国电话：+86-25-56622310电子邮件：liyizhou@huawei.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1-408-330-5000 EMail: sam.aldrin@huawei.com
Sam Aldrin华为科技2330美国加利福尼亚州圣克拉拉中央高速公路95050电话：+1-408-330-5000电子邮件：Sam。aldrin@huawei.com
Dave Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
EMail: dward@cisco.com
EMail: dward@cisco.com