Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7978 Huawei
Updates: 7178 M. Umair
Category: Standards Track IPinfusion
ISSN: 2070-1721 Y. Li
Huawei
September 2016
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7978 Huawei
Updates: 7178 M. Umair
Category: Standards Track IPinfusion
ISSN: 2070-1721 Y. Li
Huawei
September 2016
Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension
大量链路的透明互连（TRILL）：RBridge信道头扩展
Abstract
摘要
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link. This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178.
IETF TRILL（大量链路的透明互连）协议包括一个称为RBRIGE通道的可选机制（在RFC 7178中指定），用于在同一校园内的TRILL交换机之间传输类型化消息，以及在同一链路上的TRILL交换机和终端站之间传输此类消息。本文档指定了对RBridge Channel protocol header的扩展，以支持以下两个功能：（1）通过在RBridge Channel消息中封装，通过Ethertype指示类型的隧道有效负载的标准方法；以及（2）支持用于RBridge信道消息的安全设施的方法。本文档更新了RFC 7178。
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 http://www.rfc-editor.org/info/rfc7978.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7978.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................4
1.1. Terminology and Acronyms ...................................4
2. RBridge Channel Header Extension Format .........................5
3. Extended RBridge Channel Payload Types ..........................8
3.1. Null Payload ...............................................8
3.2. Ethertyped Payload .........................................9
3.2.1. RBridge Channel Message as the Payload ..............9
3.2.2. TRILL Data Packet as the Payload ...................10
3.2.3. TRILL IS-IS Packet as the Payload ..................10
3.3. Ethernet Frame ............................................11
4. Extended RBridge Channel Security ..............................13
4.1. Derived Keying Material ...................................14
4.2. SType None ................................................14
4.3. IS-IS CRYPTO_AUTH-Based Authentication ....................15
4.4. DTLS Pairwise Security ....................................17
4.5. Composite Security ........................................18
5. Extended RBridge Channel Errors ................................18
5.1. SubERRs ...................................................19
5.2. Secure Nested RBridge Channel Errors ......................19
6. IANA Considerations ............................................19
6.1. Extended RBridge Channel Protocol Number ..................19
6.2. RBridge Channel Protocol Subregistries ....................20
6.2.1. RBridge Channel Error Codes ........................20
6.2.2. RBridge Channel SubError Codes .....................20
6.2.3. Extended RBridge Channel Payload Types
Subregistry ........................................20
6.2.4. Extended RBridge Channel Security Types
Subregistry ........................................21
7. Security Considerations ........................................21
8. Normative References ...........................................22
9. Informative References .........................................23
Acknowledgements ..................................................25
Authors' Addresses ................................................25
1. Introduction ....................................................4
1.1. Terminology and Acronyms ...................................4
2. RBridge Channel Header Extension Format .........................5
3. Extended RBridge Channel Payload Types ..........................8
3.1. Null Payload ...............................................8
3.2. Ethertyped Payload .........................................9
3.2.1. RBridge Channel Message as the Payload ..............9
3.2.2. TRILL Data Packet as the Payload ...................10
3.2.3. TRILL IS-IS Packet as the Payload ..................10
3.3. Ethernet Frame ............................................11
4. Extended RBridge Channel Security ..............................13
4.1. Derived Keying Material ...................................14
4.2. SType None ................................................14
4.3. IS-IS CRYPTO_AUTH-Based Authentication ....................15
4.4. DTLS Pairwise Security ....................................17
4.5. Composite Security ........................................18
5. Extended RBridge Channel Errors ................................18
5.1. SubERRs ...................................................19
5.2. Secure Nested RBridge Channel Errors ......................19
6. IANA Considerations ............................................19
6.1. Extended RBridge Channel Protocol Number ..................19
6.2. RBridge Channel Protocol Subregistries ....................20
6.2.1. RBridge Channel Error Codes ........................20
6.2.2. RBridge Channel SubError Codes .....................20
6.2.3. Extended RBridge Channel Payload Types
Subregistry ........................................20
6.2.4. Extended RBridge Channel Security Types
Subregistry ........................................21
7. Security Considerations ........................................21
8. Normative References ...........................................22
9. Informative References .........................................23
Acknowledgements ..................................................25
Authors' Addresses ................................................25
The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended with the RBridge Channel [RFC7178] facility to support transmission of typed messages (for example, Bidirectional Forwarding Detection (BFD) [RFC7175]) between two TRILL switches (RBridges) in the same campus and the transmission of such messages between RBridges and end stations on the same link. When sent between RBridges in the same campus, a TRILL Data packet with a TRILL Header is used, and the destination RBridge is indicated by nickname. When sent between a RBridge and an end station on the same link in either direction, a native RBridge Channel message [RFC7178] is used with no TRILL Header, and the destination port or ports are indicated by a Media Access Control (MAC) address. (There is no mechanism to stop end stations on the same link from sending native RBridge Channel messages to each other; however, such use is outside the scope of this document.)
IETF TRILL基本协议[RFC6325][RFC7780]已通过RBridge通道[RFC7178]功能进行扩展，以支持两个TRILL交换机（RBridge）之间类型化消息的传输（例如，双向转发检测（BFD）[RFC7175]）在同一校园内，以及在同一链路上的RBridge和终端站之间传输此类消息。当在同一校园内的RBridge之间发送时，使用带有TRILL报头的TRILL数据包，并且目标RBridge由昵称表示。当在同一链路上的RBridge和终端站之间沿任一方向发送时，使用本机RBridge信道消息[RFC7178]，不带TRILL报头，并且目标端口由媒体访问控制（MAC）地址指示。（没有阻止同一链路上的终端站相互发送本机RBridge信道消息的机制；但是，这种使用不在本文档的范围内。）
This document updates [RFC7178] and specifies extensions to the RBridge Channel header that provide two additional facilities as follows:
本文档更新了[RFC7178]并指定了对RBridge Channel header的扩展，该扩展提供了以下两种附加功能：
(1) A standard method to tunnel payloads, whose type may be indicated by Ethertype, through encapsulation in RBridge Channel messages.
(1) 通过在RBridge通道消息中封装来隧道有效负载的标准方法，其类型可以由Ethertype指示。
(2) A method to provide security facilities for RBridge Channel messages. Example uses requiring such facilities are the security of Pull Directory messages [RFC7067], address flush messages [AddrFlush], and port shutdown messages [TRILL-AF].
(2) 为RBridge通道消息提供安全设施的方法。需要此类功能的示例使用包括请求目录消息[RFC7067]、地址刷新消息[AddrFlush]和端口关闭消息[TRILL-AF]的安全性。
Use of each of these facilities is optional, except that, as specified below, if this header extension is implemented, there are two payload types that MUST be implemented. Both of the above facilities can be used in the same packet. In case of conflict between this document and [RFC7178], this document takes precedence.
使用这些设施中的每一个都是可选的，除非如下所述，如果实现了此标头扩展，则必须实现两种有效负载类型。上述两种设施可以在同一数据包中使用。如果本文件与[RFC7178]之间存在冲突，则以本文件为准。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document uses terminology and abbreviations defined in [RFC6325] and [RFC7178]. Some of these are listed below for convenience along with new terms and abbreviations.
本文件使用[RFC6325]和[RFC7178]中定义的术语和缩写。为了方便起见，下面列出了其中一些术语和缩写。
application_data - A DTLS [RFC6347] message type.
应用程序数据-DTLS[RFC6347]消息类型。
Data Label - VLAN or FGL.
数据标签-VLAN或FGL。
DTLS - Datagram Transport Layer Security [RFC6347].
DTLS-数据报传输层安全性[RFC6347]。
FCS - Frame Check Sequence.
FCS-帧检查序列。
FGL - Fine-Grained Label [RFC7172].
FGL-细粒度标签[RFC7172]。
HKDF - HMAC-based Key Derivation Function [RFC5869].
HKDF-基于HMAC的密钥派生函数[RFC5869]。
IS-IS - Intermediate System to Intermediate System [IS-IS].
IS-IS-中间系统到中间系统[IS-IS]。
PDU - Protocol Data Unit.
协议数据单元。
MTU - Maximum Transmission Unit.
MTU-最大传输单位。
RBridge - An alternative term for a TRILL switch.
RBridge-颤音开关的替代术语。
SHA - Secure Hash Algorithm [RFC6234].
SHA-安全哈希算法[RFC6234]。
Sz - Campus-wide minimum link MTU [RFC6325] [RFC7780].
Sz-校园范围最小链路MTU[RFC6325][RFC7780]。
TRILL - Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
TRILL-链路层中大量链路的透明互连或隧道路由。
TRILL switch - A device that implements the TRILL protocol [RFC6325] [RFC7780], sometimes referred to as an RBridge.
颤音开关-实现颤音协议[RFC6325][RFC7780]的设备，有时称为RBridge。
The general structure of an RBridge Channel message between two TRILL switches (RBridges) in the same campus is shown in Figure 1 below. The structure of a native RBridge Channel message sent between an RBridge and an end station on the same link, in either direction, is shown in Figure 2 and, compared with the first case, omits the TRILL Header, inner Ethernet addresses, and Data Label. A Protocol field in the RBridge Channel Header gives the type of RBridge Channel message and indicates how to interpret the Channel-Protocol-Specific Payload [RFC7178].
同一校园中两个TRILL交换机（RBridges）之间的RBridge通道消息的一般结构如下图1所示。图2显示了在同一链路上的RBridge和终端站之间沿任意方向发送的本机RBridge信道消息的结构，与第一种情况相比，省略了TRILL报头、内部以太网地址和数据标签。RBridge Channel Header中的协议字段提供RBridge Channel消息的类型，并指示如何解释特定于通道协议的有效负载[RFC7178]。
+-----------------------------------+
| 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信道分组结构
+-----------------------------------+
| Ethernet Link Header |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| FCS |
+-----------------------------------+
+-----------------------------------+
| Ethernet Link Header |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| FCS |
+-----------------------------------+
Figure 2: Native RBridge Channel Frame
图2：本机RBridge通道帧
The RBridge Channel Header looks like this:
RBridge通道标头如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Channel-Protocol-Specific Data /
/-+-+-+-+-+- /
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Channel-Protocol-Specific Data /
/-+-+-+-+-+- /
Figure 3: RBridge Channel Header
图3:RBridge信道头
where 0x8946 is the RBridge-Channel Ethertype and CHV is the Channel Header Version. This document is based on RBridge Channel version zero.
其中0x8946是RBridge通道类型，CHV是通道头版本。本文档基于RBridge Channel版本0。
The header extensions specified herein are in the form of an RBridge Channel protocol, the Extended RBridge Channel Protocol. Figure 4 below expands the RBridge Channel Header and Protocol-Specific Payload above for the case where the header extension is present.
本文中指定的报头扩展采用RBridge信道协议的形式，即扩展RBridge信道协议。下面的图4针对存在报头扩展的情况扩展了上述RBridge通道报头和协议特定的有效负载。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Specific: | SubERR| RESV4 | SType | PType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Tunneled Data, variable length
| ...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Specific: | SubERR| RESV4 | SType | PType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Tunneled Data, variable length
| ...
Figure 4: RBridge Channel Header Extension Structure
图4:RBridge信道头扩展结构
The RBridge Channel Header Protocol field is used to indicate that the header extension is present. Its contents MUST be the value allocated for this purpose (see Section 6). The use of an RBridge Channel protocol to indicate extensions makes it easy to determine if a remote RBridge in the campus supports extensions since RBridges advertise in their LSP which such protocols they support.
RBridge Channel Header Protocol字段用于指示存在报头扩展。其内容必须是为此目的分配的值（见第6节）。使用RBridge通道协议来指示扩展可以很容易地确定校园中的远程RBridge是否支持扩展，因为RBridge在其LSP中公布了它们支持的此类协议。
The Extended RBridge Channel-Protocol-Specific Data fields are as follows:
扩展RBridge通道协议特定数据字段如下所示：
SubERR: This field provides further details when an error is indicated in the RBridge Channel ERR field. If ERR is zero, then SubERR MUST be sent as zero and ignored on receipt. See Section 5.
子错误：当RBridge Channel ERR字段中指示错误时，此字段提供进一步的详细信息。如果ERR为零，则子ERR必须作为零发送，并在收到时忽略。见第5节。
RESV4: This field MUST be sent as zero. If non-zero when received, this is an error condition. See Section 5.
RESV4:此字段必须作为零发送。如果接收到非零，则这是一种错误情况。见第5节。
SType: This field describes the type of security information and features, including keying material, being used or provided by the extended RBridge Channel message. See Section 4.
SType：此字段描述扩展RBridge通道消息正在使用或提供的安全信息和功能的类型，包括键控材料。见第4节。
PType: Payload Type. This describes the tunneled data. See Section 3.
p类型：有效负载类型。这描述了隧道数据。见第3节。
Security Information: Variable-length information. Length is zero if SType is zero. See Section 4.
安全信息：可变长度信息。如果SType为零，则长度为零。见第4节。
The RBridge Channel Header Extension is integrated with the RBridge Channel facility. Extension errors are reported as if they were RBridge Channel errors, using newly allocated code points in the ERR field of the RBridge Channel Header supplemented by the SubERR field.
RBridge信道头扩展与RBridge信道设施集成。使用RBridge通道头的ERR字段中新分配的代码点（由SubERR字段补充）报告扩展错误，就像报告RBridge通道错误一样。
The Extended RBridge Channel Protocol can carry a variety of payloads as indicated by the PType (Payload Type) field. Values are shown in the table below with further explanation below the table (see also Section 6.2.2).
扩展RBridge信道协议可以承载PType（有效负载类型）字段所指示的各种有效负载。数值如下表所示，并在下表中作了进一步解释（另见第6.2.2节）。
PType Description Reference
----- ----------- ---------
0 Reserved
1 Null Section 3.1 of RFC 7978
2 Ethertyped Payload Section 3.2 of RFC 7978
3 Ethernet Frame Section 3.3 of RFC 7978
4-14 Unassigned
15 Reserved
PType Description Reference
----- ----------- ---------
0 Reserved
1 Null Section 3.1 of RFC 7978
2 Ethertyped Payload Section 3.2 of RFC 7978
3 Ethernet Frame Section 3.3 of RFC 7978
4-14 Unassigned
15 Reserved
Table 1: Payload Type Values
表1：有效载荷类型值
While implementation of the RBridge Channel Header Extension is optional, if it is implemented, PType 1 (Null) MUST be implemented and PType 2 (Ethertyped Payload) with the RBridge-Channel Ethertype MUST be implemented. PType 2 for any Ethertypes other than the RBridge-Channel Ethertype MAY be implemented. PType 3 MAY be implemented.
虽然RBridge通道头扩展的实现是可选的，但如果实现了它，则必须实现带有RBridge通道Ethertype的PType 1（Null）和PType 2（Ethertype有效负载）。可以实现除RBridge通道以太类型之外的任何以太类型的PType 2。可以实现PType 3。
The processing of any particular extended header RBridge Channel message and its payload depends on meeting local security and other policy at the destination TRILL switch or end station.
任何特定扩展头RBridge信道消息及其有效载荷的处理取决于在目的地TRILL交换机或终端站满足本地安全和其他策略。
The Null payload type (PType = 1) is intended to be used for testing or for messages such as key negotiation or the like where only security information is present. It indicates that there is no user data payload. Any tunneled user data after the Security Information field is ignored. If the RBridge Channel Header Extension is implemented, the Null Payload MUST be supported in the sense that an "Unsupported PType" error is not returned (see Section 5). Any particular use of the Null Payload should specify what VLAN or FGL
空有效负载类型（PType＝1）旨在用于测试或用于仅存在安全信息的消息，例如密钥协商等。它表示没有用户数据有效负载。忽略安全信息字段之后的任何隧道用户数据。如果实现了RBridge通道头扩展，则必须支持空有效负载，因为不会返回“不支持的PType”错误（请参阅第5节）。空负载的任何特定使用都应该指定VLAN或FGL
and what priority should be used in the inner Data Label of the RBridge Channel message (or in an outer VLAN tag for the native RBridge Channel message case) when those values are relevant.
以及当这些值相关时，RBridge通道消息的内部数据标签（或本机RBridge通道消息的外部VLAN标记）中应使用的优先级。
A PType of 2 indicates that the payload (tunneled data) of the extended RBridge Channel message begins with an Ethertype. A TRILL switch supporting the RBridge Channel Header Extension MUST support a PType of 2 with a payload beginning with the RBridge-Channel Ethertype as described in Section 3.2.1. Other Ethertypes, including the TRILL and L2-IS-IS Ethertypes as described in Sections 3.2.2 and 3.2.3, MAY be supported.
PType为2表示扩展RBridge通道消息的有效负载（隧道数据）以Ethertype开始。如第3.2.1节所述，支持RBridge Channel Header Extension的TRILL switch必须支持PType为2，有效负载以RBridge Channel Ethertype开始。可能支持第3.2.2节和第3.2.3节所述的其他以太网类型，包括TRILL和L2-IS-IS以太网类型。
A PType of 2 whose payload has an initial RBridge-Channel Ethertype indicates an encapsulated RBridge Channel message. A typical reason for sending an RBridge Channel message inside an extended RBridge Channel message is to provide security services, such as authentication or encryption, for the encapsulated message.
PType为2，其有效负载具有初始RBridge通道Ethertype表示封装的RBridge通道消息。在扩展的RBridge通道消息内发送RBridge通道消息的典型原因是为封装的消息提供安全服务，例如身份验证或加密。
This RBridge Channel message type looks like the following:
此RBridge通道消息类型如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Nested Channel-Protocol-Specific Data ... /
/ /
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Nested Channel-Protocol-Specific Data ... /
/ /
Figure 5: Message Structure with RBridge Channel Payload
图5：具有RBridge信道有效负载的消息结构
A PType of 2 whose payload has an initial TRILL Ethertype indicates an encapsulated TRILL Data packet as shown in Figure 6. If this Ethertype is supported for PType = 2 and the message meets local policy for acceptance, the TRILL Data packet is handled as if it had been received by the destination TRILL switch on the port where the Extended RBridge Channel message was received.
PType为2，其有效负载具有初始颤音Ethertype，表示封装的颤音数据包，如图6所示。如果PType=2支持此Ethertype，且消息符合本地接受策略，则TRILL数据包的处理方式与接收扩展RBridge通道消息的端口上的目标TRILL交换机接收到的数据包相同。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Optional Flags Word /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA continued | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Data Label (2 or 4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| TRILL Data Packet payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Optional Flags Word /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA continued | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Data Label (2 or 4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| TRILL Data Packet payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 6: Message Structure with TRILL Data Packet Payload
图6：带有TRILL数据包有效负载的消息结构
The optional flags word is only present if the F bit in the TRILL Header is one [RFC7780].
仅当TRILL标头中的F位为1[RFC7780]时，才出现可选标志字。
A PType of 2 and an initial L2-IS-IS Ethertype indicate that the payload of the Extended RBridge Channel protocol message is an encapsulated TRILL IS-IS PDU as shown in Figure 7. If this Ethertype is supported for PType = 2, the tunneled TRILL IS-IS packet is processed by the destination RBridge if it meets local policy. One possible use is to expedite the receipt of a link state PDU (LSP) by
PType为2和初始L2-IS-IS以太类型表示扩展RBridge通道协议消息的有效负载是封装的TRILL IS-IS PDU，如图7所示。如果PType=2支持此Ethertype，则目标RBridge将处理隧道颤音is-is数据包（如果它符合本地策略）。一种可能的用途是通过以下方式加快链路状态PDU（LSP）的接收：
some TRILL switch or switches with an immediate requirement for the link state information. A link local IS-IS PDU would not normally be sent via this Extended RBridge Channel method except possibly to encrypt the PDU since such PDUs can just be transmitted on the link and do not normally need RBridge Channel handling. (Link local IS-IS PDUs are (1) Hello, CSNP, PSNP [IS-IS]; (2) MTU-probe, MTU-ack [RFC7176]; and (3) circuit scoped FS-LSP, FS-CSNP, and FS-PSNP [RFC7356].)
一些颤音开关或对链路状态信息有即时要求的开关。链路本地IS-IS PDU通常不会通过此扩展RBridge信道方法发送，除非可能用于加密PDU，因为此类PDU只能在链路上传输，并且通常不需要RBridge信道处理。（链路本地IS-IS PDU为（1）你好，CSNP，PSNP[IS-IS]；（2）MTU探头，MTU确认[RFC7176]；（3）电路范围FS-LSP，FS-CSNP和FS-PSNP[RFC7356]。）
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| L2-IS-IS (0x22F4) | 0x83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rest of IS-IS PDU
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| L2-IS-IS (0x22F4) | 0x83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rest of IS-IS PDU
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 7: Message Structure with TRILL IS-IS Packet Payload
图7:TRILL IS-IS数据包有效负载的消息结构
If PType is 3, the extended RBridge Channel payload is an Ethernet frame as might be received from or sent to an end station except that the encapsulated Ethernet frame's FCS is omitted, as shown in Figure 8. (There is still an overall final FCS if the RBridge Channel message is being sent on an Ethernet link.) If this PType is implemented and the message meets local policy, the encapsulated frame is handled as if it had been received on the port on which the Extended RBridge Channel message was received.
如果PType为3，则扩展RBridge信道有效载荷是一个以太网帧，可以从终端站接收或发送到终端站，但省略了封装的以太网帧的FCS，如图8所示。（如果通过以太网链路发送RBridge通道消息，则仍有一个完整的最终FCS。）如果实现了此类型且消息符合本地策略，则封装帧的处理方式与接收扩展RBridge通道消息的端口相同。
The priority of the RBridge Channel message can be copied from the Ethernet frame VLAN tag, if one is present, except that priority 7 SHOULD only be used for messages critical to establishing or maintaining adjacency and priority 6 SHOULD only be used for other important control messages.
如果存在以太网帧VLAN标记，则可以从以太网帧VLAN标记复制RBridge通道消息的优先级，但优先级7应仅用于对建立或维护相邻关系至关重要的消息，优先级6应仅用于其他重要控制消息。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | 0x0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA (cont.) | MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any Ethernet frame tagging...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Ethernet frame payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 (0x8946) | 0x0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA (cont.) | MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any Ethernet frame tagging...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Ethernet frame payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 8: Message Structure with Ethernet Frame Payload
图8：具有以太网帧有效负载的消息结构
In the case of a non-Ethernet link, such as a PPP (Point-to-Point Protocol) link [RFC6361], the ports on the link are considered to have link-local synthetic 48-bit MAC addresses constructed as described below. Such a constructed address MAY be used as a MacSA. If the RBridge Channel message is individually addressed to a link-local port, the source TRILL switch will have the information to construct such a MAC address for the destination TRILL switch port, and that MAC address MAY be used as the MacDA. By the use of such a MacSA and either such a unicast MacDA or a group-addressed MacDA, an Ethernet frame can be sent between two TRILL switch ports connected by a non-Ethernet link.
在非以太网链路的情况下，例如PPP（点对点协议）链路[RFC6361]，链路上的端口被认为具有如下所述构造的链路本地合成48位MAC地址。这种构造的地址可以用作MacSA。如果RBridge信道消息被单独寻址到链路本地端口，则源TRILL交换机将具有为目的地TRILL交换机端口构造这样的MAC地址的信息，并且该MAC地址可被用作MacDA。通过使用这样的MacSA和这样的单播MacDA或组寻址MacDA，可以在通过非以太网链路连接的两个TRILL交换机端口之间发送以太网帧。
These synthetic TRILL switch port MAC addresses for non-Ethernet ports are constructed as follows (and as shown in Figure 9): 0xFEFF, the nickname of the TRILL switch used in TRILL Hellos sent on that port, and the Port ID that the TRILL switch has assigned to that port. (Both the Port ID of the port on which a TRILL Hello is sent and the nickname of the sending TRILL switch appear in the Special VLANs and Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC address has the Local bit on and the Group bit off [RFC7042]. However, since there will be no Ethernet end stations on a non-Ethernet link in a TRILL campus, such synthetic MAC addresses cannot conflict on the link with a real Ethernet port address regardless of their values.
非以太网端口的这些合成TRILL交换机端口MAC地址构造如下（如图9所示）：0xFEFF，在该端口上发送的TRILL Hellos中使用的TRILL交换机的昵称，以及TRILL交换机分配给该端口的端口ID。（发送TRILL Hello的端口的端口ID和发送TRILL交换机的昵称都出现在特殊VLAN和TRILL is-is Hellos中的标志sub TLV[RFC7176]）生成的MAC地址具有本地位on和组位off[RFC7042]。然而，由于TRILL校园中的非以太网链路上没有以太网终端站，因此此类合成MAC地址在链路上不能与实际以太网端口地址冲突，无论其值如何。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFEFF | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFEFF | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Synthetic MAC Address
图9：合成MAC地址
Table 2 below gives the assigned values of the SType (Security Type) field and their meaning. Use of DTLS Pairwise Security (SType = 2) or Composite Security (SType = 3) is RECOMMENDED.
下表2给出了SType（安全类型）字段的赋值及其含义。建议使用DTLS成对安全性（SType=2）或复合安全性（SType=3）。
While IS-IS CRYPTO_AUTH-based authentication is also specified and can be used for both pairwise and multi-destination traffic, it provides only authentication and is not considered to meet current security standards. For example, it does not provide for key negotiation; thus, its use is NOT RECOMMENDED.
虽然还指定了基于IS-IS CRYPTO_AUTH的身份验证，并且可以用于成对和多目标流量，但它仅提供身份验证，不被认为符合当前的安全标准。例如，它没有提供关键协商；因此，不建议使用它。
The Extended RBridge Channel DTLS-based security specified in Section 4.4 and the Composite Security specified in Section 4.5 are intended for pairwise (known unicast) use. That is, the case where the M bit in the TRILL Header is zero and any Outer.MacDA is individually addressed.
第4.4节规定的基于扩展RBridge信道DTL的安全性和第4.5节规定的复合安全性旨在成对（已知单播）使用。也就是说，TRILL报头中的M位为零，任何Outer.MacDA都单独寻址。
Multi-destination Extended RBridge Channel packets would be those with the M bit in the TRILL Header set to one or, in the native RBridge Channel case, the Outer.MacDA would be group addressed. The DTLS Pairwise Security and Composite Security STypes can also be used in the multi-destination case by serially unicasting the messages to all data-accessible RBridges (or stations in the native RBridge Channel case) in the recipient group. For TRILL Data packets, that group is specified by the Data Label; for native frames, the group is specified by the groupcast destination MAC address. It is intended to specify a true group keyed SType to secure multi-destination packets in a separate document [GroupKey].
多目的地扩展RBridge信道数据包将是TRILL报头中的M位设置为1的数据包，或者在本机RBridge信道情况下，Outer.MacDA将被分组寻址。DTLS成对安全和复合安全模式也可在多目的地情况下使用，方法是将消息连续单播到接收方组中所有数据可访问的RBridge（或本机RBridge信道情况下的站点）。对于TRILL数据包，该组由数据标签指定；对于本机帧，组由groupcast目标MAC地址指定。它旨在指定一个真正的组密钥类型，以保护单独文档[GroupKey]中的多目标数据包。
SType Description Reference
----- ----------- ---------
0 None Section 4.2 of RFC 7978
1 IS-IS CRYPTO_AUTH-Based Section 4.3 of RFC 7978
Authentication
2 DTLS Pairwise Security Section 4.4 of RFC 7978
3 Composite Security Section 4.5 of RFC 7978
4-14 Unassigned
15 Reserved
SType Description Reference
----- ----------- ---------
0 None Section 4.2 of RFC 7978
1 IS-IS CRYPTO_AUTH-Based Section 4.3 of RFC 7978
Authentication
2 DTLS Pairwise Security Section 4.4 of RFC 7978
3 Composite Security Section 4.5 of RFC 7978
4-14 Unassigned
15 Reserved
Table 2: SType Values
表2：SType值
In some cases, it is possible to use material derived from IS-IS CRYPTO_AUTH keying material [RFC5310] as an element of Extended RBridge Channel security. It is assumed that the IS-IS keying material is of high quality. The material actually used is derived from the IS-IS keying material as follows:
在某些情况下，可以使用源自is-is加密认证密钥材料[RFC5310]的材料作为扩展RBridge信道安全性的元素。假设is-is键控材料具有高质量。实际使用的材质源自is-is键控材质，如下所示：
Derived Material = HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L )
衍生材料=HKDF-Expand-SHA256（IS为键，“扩展通道”| 0x0S，L）
where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is as in [RFC6234], IS-IS-key is the input IS-IS keying material, "Extended Channel" is the 16-character ASCII [RFC20] string indicated without any leading length byte or trailing zero byte, 0x0S is a single byte where S is the SType for which this key derivation is being used and the upper nibble is zero, and L is the length of the output-derived material needed.
其中“|”表示串联，HKDF如[RFC5869]所示，SHA256如[RFC6234]所示，is-is键是输入is-is键控材料，“扩展通道”是指示的16字符ASCII[RFC20]字符串，无任何前导长度字节或尾随零字节，0x0S是一个单字节，其中S是使用此键派生的SType，上半字节为零，L是所需输出派生材料的长度。
Whenever IS-IS keying material is being used as above, the underlying IS-IS CRYPTO_AUTH keying material [RFC5310] might expire or be invalidated. At the time of or before such expiration or invalidation, the use of the Derived Material from the IS-IS keying material MUST cease. Continued security MAY use new derived material from currently valid IS-IS CRYPTO_AUTH keying material.
每当如上所述使用IS-IS密钥材料时，基础IS-IS加密验证密钥材料[RFC5310]可能会过期或失效。在到期或失效时或之前，必须停止使用IS-IS键控材料衍生的材料。持续安全性可使用当前有效IS-IS加密认证密钥材料中的新衍生材料。
No security services are being invoked. The length of the Security Information field (see Figure 4) is zero.
未调用任何安全服务。安全信息字段的长度（见图4）为零。
This SType provides security for Extended RBridge Channel messages similar to that provided for [IS-IS] PDUs by the [IS-IS] Authentication TLV. The Security Information (see Figure 4) is as shown in Figure 10.
此SType为扩展RBridge通道消息提供安全性，类似于[IS-IS]认证TLV为[IS-IS]PDU提供的安全性。安全信息（见图4）如图10所示。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+
| Authentication Data (Variable)
+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-...
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+
| Authentication Data (Variable)
+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 10: SType 1 Security Information
图10:SType 1安全信息
o RESV: Four bits that MUST be sent as zero and ignored on receipt.
o RESV：四位，必须作为零发送，并在接收时忽略。
o Size: Set to 2 + the size of Authentication Data in bytes.
o 大小：设置为2+身份验证数据的大小（字节）。
o Key ID: specifies the keying value and authentication algorithm that the Key ID specifies for TRILL IS-IS LSP [RFC5310] Authentication TLVs. The keying material actually used is always derived as shown in Section 4.1.
o 密钥ID：指定密钥ID为TRILL IS-IS LSP[RFC5310]身份验证TLV指定的密钥值和身份验证算法。实际使用的键控材料始终如第4.1节所示。
o Authentication Data: The authentication data produced by the derived key and algorithm associated with the Key ID acting on the part of the TRILL Data packet shown. Length of the authentication data depends on the algorithm. The authentication value is included in the security information field and is treated as zero when authentication is calculated.
o 身份验证数据：由派生密钥和算法生成的身份验证数据，该算法与作用于所示TRILL数据包部分的密钥ID相关。身份验证数据的长度取决于算法。身份验证值包含在安全信息字段中，并在计算身份验证时被视为零。
As show in Figure 11, the area covered by this authentication starts with the byte immediately after the TRILL Header optional Flag Word if it is present. If the Flag Word is not present, it starts after the TRILL Header Ingress Nickname. In either case, it extends to just before the TRILL Data packet link trailer. For example, for an Ethernet packet it would extend to just before the FCS.
如图11所示，此身份验证覆盖的区域从TRILL头可选标志字（如果存在）后面的字节开始。如果标志词不存在，则在颤音头入口昵称之后开始。在任何一种情况下，它都会延伸到TRILL数据包链接尾部之前。例如，对于以太网数据包，它将扩展到FCS之前。
+-----------------------------+
| Link Header |
+-----------------------------+
| TRILL Header |
| (plus optional Flag Word) |
+-----------------------------+ ^
| Inner Ethernet Addresses | |
+-----------------------------+ .
| Data Label (VLAN or FGL) | |
+-----------------------------+ .
| RBridge Channel Header | | <-authentication
+-----------------------------+ .
| Extended Channel Header | |
| (plus Security Information)| .
+-----------------------------+ |
| Payload | .
+-----------------------------+ v
| Link Trailer |
+-----------------------------+
+-----------------------------+
| Link Header |
+-----------------------------+
| TRILL Header |
| (plus optional Flag Word) |
+-----------------------------+ ^
| Inner Ethernet Addresses | |
+-----------------------------+ .
| Data Label (VLAN or FGL) | |
+-----------------------------+ .
| RBridge Channel Header | | <-authentication
+-----------------------------+ .
| Extended Channel Header | |
| (plus Security Information)| .
+-----------------------------+ |
| Payload | .
+-----------------------------+ v
| Link Trailer |
+-----------------------------+
Figure 11: SType 1 Authentication Coverage
图11:SType 1身份验证覆盖率
In the native RBridge Channel case, this authentication coverage is as specified in the above paragraph except that it starts with the RBridge-Channel Ethertype, since there is no TRILL Header, inner Ethernet addresses, or inner Data Label (see Figure 12).
在本机RBridge通道的情况下，此身份验证覆盖范围如上文所述，但它以RBridge通道Ethertype开始，因为没有TRILL标头、内部以太网地址或内部数据标签（见图12）。
+-----------------------------+
| Ethernet Header |
+-----------------------------+ ^
| RBridge Channel Header | |
+-----------------------------+ .
| Extended Channel Header | | <-authentication
| (plus Security Information)| .
+-----------------------------+ |
| Payload | .
+-----------------------------+ v
| Ethernet Trailer |
+-----------------------------+
+-----------------------------+
| Ethernet Header |
+-----------------------------+ ^
| RBridge Channel Header | |
+-----------------------------+ .
| Extended Channel Header | | <-authentication
| (plus Security Information)| .
+-----------------------------+ |
| Payload | .
+-----------------------------+ v
| Ethernet Trailer |
+-----------------------------+
Figure 12: Native SType 1 Authentication Coverage
图12：本机SType 1身份验证覆盖率
RBridges, which are IS-IS routers, can reasonably be expected to hold IS-IS CRYPTO_AUTH keying material [RFC5310] so that this SType can be used for RBridge Channel messages, which go between RBridges. How end stations might come to hold IS-IS CRYPTO_AUTH keying material is
RBridge是IS-IS路由器，可以合理地预期它会持有IS-IS加密认证密钥材料[RFC5310]，因此这种样式可以用于RBridge之间的RBridge信道消息。终端站如何持有IS-IS加密认证密钥材料
beyond the scope of this document. Thus, this SType might not be applicable to native RBridge Channel messages, which are between an RBridge and an end station.
超出本文件的范围。因此，此SType可能不适用于本机RBridge信道消息，它们位于RBridge和终端站之间。
DTLS [RFC6347] supports key negotiation and provides both encryption and authentication. The RBridge Channel Extended Header DTLS Pairwise SType uses a negotiated DTLS version that MUST NOT be less than 1.2.
DTLS[RFC6347]支持密钥协商，并提供加密和身份验证。RBridge Channel Extended Header DTLS成对SType使用的协商DTLS版本不得小于1.2。
When DTLS pairwise security is used, the entire payload of the Extended RBridge Channel packet, starting just after the null Security Information and ending just before the link trailer, is one or more DTLS records [RFC6347]. As specified in [RFC6347], DTLS records MUST be limited by the path MTU, in this case so that each record fits entirely within a single Extended RBridge Channel message. A minimum path MTU can be determined from the TRILL campus minimum MTU Sz, which will not be less than 1470 bytes, by allowing for the TRILL Data packet, extended RBridge Channel, and DTLS framing overhead. With this SType, the security information between the extended RBridge Channel header and the payload is null because all the security information is in the payload area.
当使用DTLS成对安全性时，扩展RBridge通道数据包的整个有效载荷（在空安全信息之后开始，在链路尾部之前结束）是一个或多个DTLS记录[RFC6347]。如[RFC6347]中所述，DTLS记录必须受到路径MTU的限制，在这种情况下，每个记录必须完全符合单个扩展RBridge通道消息。通过允许TRILL数据分组、扩展RBridge信道和DTLS帧开销，可以从TRILL校园最小MTU Sz确定最小路径MTU，该最小路径MTU Sz将不小于1470字节。使用此SType，扩展RBridge信道报头和有效负载之间的安全信息为空，因为所有安全信息都在有效负载区域中。
The DTLS Pairwise keying is set up between a pair of RBridges, independent of Data Label, using messages of a priority configurable at the RBridge level, which defaults to priority 6. DTLS message types other than application_data can be the payload of an extended RBridge Channel message with a TRILL Header using any Data Label, and, for such DTLS message types, the PType in the RBridge Channel Header Extension is ignored.
DTLS成对键控在一对RBridge之间设置，独立于数据标签，使用RBridge级别可配置优先级的消息（默认为优先级6）。应用程序_数据以外的DTLS消息类型可以是扩展RBridge通道消息的有效载荷，该消息具有使用任何数据标签的TRILL头，并且对于此类DTLS消息类型，RBridge通道头扩展中的PType被忽略。
Actual application_data sent within such a message using this SType SHOULD use the Data Label and priority as specified for that application_data. In this case, the PType value in the RBridge Channel Header Extension applies to the decrypted application_data.
使用此样式在此类消息中发送的实际应用程序数据应使用为该应用程序数据指定的数据标签和优先级。在这种情况下，RBridge通道头扩展中的PType值应用于解密的应用程序_数据。
TRILL switches that implement the extended RBridge Channel DTLS Pairwise SType SHOULD support the use of certificates for DTLS, but certificate size may be limited by the DTLS requirement that each record fit within a single message. Appropriate certificate contents are out of scope for this document.
实现扩展RBridge通道DTLS成对SType的TRILL交换机应支持对DTL使用证书，但证书大小可能会受到DTLS要求的限制，即每个记录适合单个消息。适当的证书内容超出了本文档的范围。
TRILL switches that support the extended RBridge Channel DTLS Pairwise SType MUST support the use of pre-shared keys. If the psk_identity (see [RFC4279]) is two bytes, it is interpreted as a Key ID as defined in [RFC5310], and the value derived as shown in Section 4.1 from that key is used as a pre-shared key for DTLS
支持扩展RBridge通道DTLS成对SType的颤音开关必须支持使用预共享键。如果psk_标识（参见[RFC4279]）为两个字节，则它被解释为[RFC5310]中定义的密钥ID，并且从该密钥导出的值（如第4.1节所示）被用作DTL的预共享密钥
negotiation. A psk_identity with a length other than two bytes MAY be used to indicate other implementation-dependent pre-shared keys. Pre-shared keys used for DTLS negotiation SHOULD be shared only by the pair of endpoints; otherwise, security could be attacked by diverting messages to another endpoint holding that pre-shared key.
谈判长度不超过两个字节的psk_标识可用于指示其他依赖于实现的预共享密钥。用于DTLS协商的预共享密钥应仅由该对端点共享；否则，将消息转移到另一个持有该预共享密钥的端点可能会攻击安全性。
Composite Security (SType = 3) is the combination of DTLS Pairwise Security and IS-IS CRYPTO_AUTH-Based Authentication. On transmission, the DTLS record or records to be sent are secured as specified in Section 4.4 then used as the payload for the application of Authentication as specified in Section 4.3. On reception, the IS-IS CRYPTO_AUTH-based authentication is verified first and an error is returned if it fails. If the IS-IS CRYPTO_AUTH-based authentication succeeds, then the DTLS record or records are processed.
复合安全性（SType=3）是DTLS成对安全性和基于is-is加密的身份验证的组合。在传输时，根据第4.4节的规定对DTLS记录进行保护，然后根据第4.3节的规定将其用作认证应用的有效载荷。接收时，首先验证基于IS-IS CRYPTO_AUTH的身份验证，如果失败，则返回错误。如果基于IS-IS CRYPTO_AUTH的身份验证成功，则会处理DTLS记录。
An advantage of Composite Security is that the payload is authenticated and encrypted with a modern security protocol; in addition, the RBridge Channel Header and (except in the native case) preceding the MAC addresses and Data Label are provided with some authentication.
复合安全性的一个优点是有效载荷通过现代安全协议进行身份验证和加密；此外，在MAC地址和数据标签之前的RBridge信道头和（在本机情况下除外）提供了一些身份验证。
RBridge Channel Header Extension errors are reported like RBridge Channel errors. The ERR field is set to one of the following error codes:
RBridge通道头扩展错误与RBridge通道错误一样报告。ERR字段设置为以下错误代码之一：
Value RBridge Channel Error Code Meaning
----- ------------------------------------
6 Unknown or unsupported field value
7 Authentication failure
8 Error in nested RBridge Channel message
Value RBridge Channel Error Code Meaning
----- ------------------------------------
6 Unknown or unsupported field value
7 Authentication failure
8 Error in nested RBridge Channel message
Table 3: Additional ERR Values
表3：附加ERR值
If the ERR field is 6, the SubERR field indicates the problematic field or value as shown in the table below. At this time no suberrror codes are assigned under any other ERR field value.
如果ERR字段为6，则SubERR字段表示问题字段或值，如下表所示。此时，在任何其他错误字段值下均未分配子错误代码。
Err SubERR Meaning (for ERR = 6)
--- ------ -----------------------
0 No Error; suberrors not allowed
1-5 (no suberrors assigned)
6 0 Reserved
6 1 Non-zero RESV4 nibble
6 2 Unsupported SType
6 3 Unsupported PType
6 4 Unknown Key ID
6 5 Unsupported Ethertype with PType = 2
6 6 Unsupported authentication algorithm for SType = 1
6 7 Non-zero SubERR with zero ERR field
7-14 (no suberrors assigned)
15 Reserved
Err SubERR Meaning (for ERR = 6)
--- ------ -----------------------
0 No Error; suberrors not allowed
1-5 (no suberrors assigned)
6 0 Reserved
6 1 Non-zero RESV4 nibble
6 2 Unsupported SType
6 3 Unsupported PType
6 4 Unknown Key ID
6 5 Unsupported Ethertype with PType = 2
6 6 Unsupported authentication algorithm for SType = 1
6 7 Non-zero SubERR with zero ERR field
7-14 (no suberrors assigned)
15 Reserved
Table 4: SubERR Values
表4：子错误值
If o an extended RBridge Channel message is sent with security and with a payload type (PType) indicating an Ethertyped payload and the Ethertype indicates a nested RBridge Channel message and o there is an error in the processing of that nested message that results in a return RBridge Channel message with a non-zero ERR field, then that returned message SHOULD also be nested in an extended RBridge Channel message using the same type of security. In this case, the ERR field in the Extended RBridge Channel envelope is set to 8 indicating that there is a nested error in the message being tunneled back.
如果o发送的扩展RBridge通道消息具有安全性，且有效负载类型（PType）指示以太类型的有效负载，以太类型指示嵌套RBridge通道消息，并且o处理该嵌套消息时出错，导致返回带有非零ERR字段的RBridge通道消息，然后，返回的消息也应该使用相同类型的安全性嵌套在扩展RBridge通道消息中。在这种情况下，扩展RBridge通道封套中的ERR字段设置为8，表示正在通过隧道传回的消息中存在嵌套错误。
IANA has assigned 0x004 from the range assigned by Standards Action [RFC5226] as the RBridge Channel protocol number to indicate RBridge Channel Header Extension.
IANA已从标准行动[RFC5226]指定的范围中指定0x004作为RBridge信道协议号，以指示RBridge信道头扩展。
The added "RBridge Channel Protocols" registry in the TRILL Parameters registry is as follows:
TRILL参数注册表中添加的“RBridge通道协议”注册表如下所示：
Protocol Description Reference
-------- -------------------------- ----------------
0x004 RBridge Channel Extension RFC 7978
Protocol Description Reference
-------- -------------------------- ----------------
0x004 RBridge Channel Extension RFC 7978
IANA has created three subregistries under the "RBridge Channel Protocols" registry as detailed in the subsections below.
IANA已在“RBridge Channel Protocols”（RBridge通道协议）登记册下创建了三个子区，详情见下文小节。
IANA has assigned three additional code points in the "RBridge Channel Error Codes" subregistry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The additional entries are as shown in Table 3 in Section 5 and the "Reference" column value is "RFC 7978" for those rows.
IANA在“大量链路透明互连（TRILL）参数”注册表中的“RBridge通道错误代码”子区域中分配了三个额外的代码点。附加条目如第5节表3所示，这些行的“参考”列值为“RFC 7978”。
IANA has created a subregistry indented under the "RBridge Channel Error Codes" registry, for RBridge Channel SubError Codes. The initial contents of this subregistry are shown in Table 4 in Section 5.1 and the fourth column "Reference" includes value "RFC 7978" for all rows. The header information is as follows:
IANA已经为RBridge Channel子错误代码创建了一个缩进在“RBridge Channel Error Codes”注册表下的子区域。本次区域的初始内容见第5.1节表4，第四列“参考”包括所有行的“RFC 7978”值。标题信息如下所示：
Registry Name: RBridge Channel SubError Codes Registration Procedures: IETF Review Reference: RFC 7978
注册表名称：RBridge通道子错误代码注册程序：IETF审查参考：RFC 7978
IANA has created an "Extended RBridge Channel Payload Types" subregistry after the "RBridge Channel Protocols" registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The header information is as follows:
IANA在“大量链路透明互连（TRILL）参数”注册表中的“RBridge信道协议”注册表之后创建了一个“扩展RBridge信道有效负载类型”分区。标题信息如下所示：
Registration Procedures: IETF Review Reference: RFC 7978
注册程序：IETF审查参考：RFC 7978
The initial registry content is in Table 1 in Section 3 of this document.
初始注册表内容见本文件第3节表1。
IANA has created an "Extended RBridge Channel Security Types" subregistry after the "Extended RBridge Channel Payload Types" registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The header information is as follows:
IANA在“大量链路透明互连（TRILL）参数”注册表中的“扩展RBridge信道有效负载类型”注册表之后，创建了一个“扩展RBridge信道安全类型”分区。标题信息如下所示：
Registration Procedures: IETF Review Reference: RFC 7978
注册程序：IETF审查参考：RFC 7978
The initial registry content is in Table 2 in Section 4 of this document.
初始注册表内容见本文件第4节表2。
The RBridge Channel Header Extension has potentially positive and negative effects on security.
RBridge通道头扩展对安全性有潜在的积极和消极影响。
On the positive side, it provides optional security that can be used to authenticate and/or encrypt RBridge Channel messages. Some RBridge Channel message payloads, such as BFD [RFC7175], provide their own security but where this is not true, consideration should be given, when specifying an RBridge Channel protocol, to recommending or requiring use of the security features of the RBridge Channel Header Extension.
从积极的一面看，它提供了可选的安全性，可用于对RBridge通道消息进行身份验证和/或加密。一些RBridge通道消息有效载荷，如BFD[RFC7175]，提供了它们自己的安全性，但如果不是这样，则在指定RBridge通道协议时，应考虑推荐或要求使用RBridge通道头扩展的安全功能。
On the negative side, the optional ability to tunnel more payload types, and to tunnel them between TRILL switches and to and from end stations, can increase risk unless precautions are taken. The processing of decapsulated extended RBridge Channel payloads is a place where you SHOULD NOT be liberal in what you accept. This is because the tunneling facility makes it easier for unexpected messages to pop up in unexpected places in a TRILL campus due to accidents or the actions of an adversary. Local policies SHOULD generally be strict and only accept payload types required and then only with adequate security for the particular circumstances.
从消极的一面来看，如果不采取预防措施，选择隧道传输更多的有效负载类型，以及在TRILL交换机之间以及在终端站之间进行隧道传输，可能会增加风险。处理未封装的扩展RBridge通道有效载荷时，您不应随意接受。这是因为隧道设施使意外消息更容易在TRILL校园中意外的地方由于意外事件或对手的行动而弹出。当地政策通常应严格，只接受所需的有效负载类型，然后仅在特定情况下具有足够的安全性。
See the first paragraph of Section 4 for recommendations on SType usage.
有关SType使用的建议，请参见第4节第一段。
See [RFC7457] for security considerations of DTLS.
有关DTL的安全注意事项，请参见[RFC7457]。
If IS-IS authentication is not being used, then IS-IS CRYPTO_AUTH keying material [RFC5310] would not normally be available but that presumably represents a judgment by the TRILL campus operator that no security is needed.
如果未使用IS-IS认证，则IS-IS加密认证密钥材料[RFC5310]通常不可用，但这可能表示TRILL校园运营商判断不需要安全性。
See [RFC7178] for general RBridge Channel security considerations and [RFC6325] for general TRILL security considerations.
请参阅[RFC7178]了解一般RBridge通道安全注意事项，并参阅[RFC6325]了解一般TRILL安全注意事项。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- 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)", ISO/IEC 10589:2002, Second Edition, 2002.
[IS-IS]国际标准化组织，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，ISO/IEC 10589:2002，第二版，2002年。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4279]Eronen，P.，Ed.，和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，DOI 10.17487/RFC4279，2005年12月<http://www.rfc-editor.org/info/rfc4279>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310,v February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用加密身份验证”，RFC 5310，DOI 10.17487/RFC5310，V，2009年2月<http://www.rfc-editor.org/info/rfc5310>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<http://www.rfc-editor.org/info/rfc5869>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc6325>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[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, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7178>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<http://www.rfc-editor.org/info/rfc7356>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7780>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 6361，DOI 10.17487/RFC6361，2011年8月<http://www.rfc-editor.org/info/rfc6361>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7042>.
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.
[RFC7067]Dunbar，L.，Eastlake 3rd，D.，Perlman，R.，和I.Gashinsky，“目录协助问题和高层设计方案”，RFC 7067，DOI 10.17487/RFC7067，2013年11月<http://www.rfc-editor.org/info/rfc7067>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7175>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457]Sheffer，Y.，Holz，R.，和P.Saint Andre，“总结对传输层安全（TLS）和数据报TLS（DTLS）的已知攻击”，RFC 7457，DOI 10.17487/RFC7457，2015年2月<http://www.rfc-editor.org/info/rfc7457>.
[AddrFlush] Hao, W., Eastlake, D., and Y. Li, "TRILL: Address Flush Message", Work in Progress, draft-ietf-trill-address-flush-00, May 2016.
[AddrFlush]郝，W.，伊斯特莱克，D.，和Y.李，“颤音：地址刷新消息”，正在进行的工作，草稿-ietf-颤音-Address-Flush-00，2016年5月。
[GroupKey] Eastlake, D., "TRILL: Group Keying", Work in Progress, draft-eastlake-trill-group-keying-00, July 2016.
[GroupKey]Eastlake，D.，“颤音：组键控”，正在进行的工作，草稿-Eastlake-TRILL-Group-Keying-00，2016年7月。
[TRILL-AF] Eastlake, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "TRILL: Appointed Forwarders", Work in Progress, draft-ietf-trill-rfc6439bis-03, August 2016.
[TRILL-AF]伊斯特莱克，D.，李，Y.，乌迈尔，M.，班纳吉，A.，和F.胡，“TRILL：指定货运代理”，正在进行的工作，草案-ietf-TRILL-rfc6439bis-032016年8月。
Acknowledgements
致谢
The contributions of the following are hereby gratefully acknowledged:
特此感谢以下人员的贡献：
Stephen Farrell, Jonathan Hardwick, Susan Hares, Gayle Noble, Alvaro Retana, Yaron Sheffer, and Peter Yee.
斯蒂芬·法雷尔、乔纳森·哈德威克、苏珊·哈尔斯、盖尔·诺布尔、阿尔瓦罗·雷塔纳、亚龙·谢弗和彼得·叶。
Authors' Addresses
作者地址
Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
美国马萨诸塞州米尔福德市海狸街155号华为技术第三公司唐纳德E.伊斯特莱克01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mohammed Umair IPinfusion
穆罕默德·乌迈尔
Email: mohammed.umair2@gmail.com
Email: mohammed.umair2@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