Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7177 Huawei
Obsoletes: 6327 R. Perlman
Updates: 6325 Intel Labs
Category: Standards Track A. Ghanwani
ISSN: 2070-1721 Dell
H. Yang
Cisco
V. Manral
Ionos Corp.
May 2014
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7177 Huawei
Obsoletes: 6327 R. Perlman
Updates: 6325 Intel Labs
Category: Standards Track A. Ghanwani
ISSN: 2070-1721 Dell
H. Yang
Cisco
V. Manral
Ionos Corp.
May 2014
Transparent Interconnection of Lots of Links (TRILL): Adjacency
大量链接的透明互连（TRILL）：邻接
Abstract
摘要
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System (IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325.
IETF多链路透明互连（TRILL）协议支持TRILL交换机之间的任意链路技术，包括可以连接多个TRILL交换机和终端站的点到点链路和多址局域网（LAN）链路。TRILL使用中间系统到中间系统（IS-IS）路由。本文件规定了TRILL交换机之间IS-IS邻接的建立、报告和终止，也称为RBridges（路由桥）。它还涉及TRILL的其他四个链路本地方面：指定RBridge（DRB）选择、MTU（最大传输单元）测试、伪节点创建和与邻接相关的BFD（双向转发检测）会话引导。适当时包括状态图。本文件淘汰RFC 6327并更新RFC 6325。
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/rfc7177.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7177.
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 ....................................................4
1.1. Content and Precedence .....................................5
1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................6
2.1. RBridge Interconnection by Ethernet ........................6
2.2. Handling Native Frames .....................................7
2.3. Zero or Minimal Configuration ..............................8
2.4. MTU Robustness .............................................8
2.5. Purposes of the TRILL Hello Protocol .......................9
3. Adjacency State Machinery ......................................10
3.1. TRILL Hellos, Ports, and VLANs ............................10
3.2. Adjacency Table Entries and States ........................11
3.3. Adjacency and Hello Events ................................12
3.4. Adjacency State Diagram and Table .........................15
3.5. Multiple Parallel Links ...................................17
3.6. Insufficient Space in Adjacency Table .....................17
4. LAN Ports and DRB State ........................................17
4.1. Port Table Entries and DRB Election State .................18
4.2. DRB Election Events .......................................19
4.2.1. DRB Election Details ...............................20
4.2.2. Change in DRB ......................................20
4.2.3. Change in Designated VLAN ..........................21
4.3. Port State Table and Diagram ..............................21
5. MTU Matching ...................................................22
6. BFD-Enabled TLV and BFD Session Bootstrapping ..................24
7. Pseudonodes ....................................................25
8. More TRILL Hello Details .......................................26
8.1. Contents of TRILL Hellos ..................................27
8.2. Transmitting TRILL Hellos .................................27
8.2.1. TRILL Neighbor TLVs ................................28
8.3. Receiving TRILL Hellos ....................................29
9. Multiple Ports on the Same Broadcast Link ......................29
10. IANA Considerations ...........................................30
11. Security Considerations .......................................30
Appendix A. Changes from RFC 6327 .................................31
Appendix B. Changes to RFC 6325 ...................................31
Normative References...............................................32
Informative References.............................................33
Acknowledgements...................................................34
1. Introduction ....................................................4
1.1. Content and Precedence .....................................5
1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................6
2.1. RBridge Interconnection by Ethernet ........................6
2.2. Handling Native Frames .....................................7
2.3. Zero or Minimal Configuration ..............................8
2.4. MTU Robustness .............................................8
2.5. Purposes of the TRILL Hello Protocol .......................9
3. Adjacency State Machinery ......................................10
3.1. TRILL Hellos, Ports, and VLANs ............................10
3.2. Adjacency Table Entries and States ........................11
3.3. Adjacency and Hello Events ................................12
3.4. Adjacency State Diagram and Table .........................15
3.5. Multiple Parallel Links ...................................17
3.6. Insufficient Space in Adjacency Table .....................17
4. LAN Ports and DRB State ........................................17
4.1. Port Table Entries and DRB Election State .................18
4.2. DRB Election Events .......................................19
4.2.1. DRB Election Details ...............................20
4.2.2. Change in DRB ......................................20
4.2.3. Change in Designated VLAN ..........................21
4.3. Port State Table and Diagram ..............................21
5. MTU Matching ...................................................22
6. BFD-Enabled TLV and BFD Session Bootstrapping ..................24
7. Pseudonodes ....................................................25
8. More TRILL Hello Details .......................................26
8.1. Contents of TRILL Hellos ..................................27
8.2. Transmitting TRILL Hellos .................................27
8.2.1. TRILL Neighbor TLVs ................................28
8.3. Receiving TRILL Hellos ....................................29
9. Multiple Ports on the Same Broadcast Link ......................29
10. IANA Considerations ...........................................30
11. Security Considerations .......................................30
Appendix A. Changes from RFC 6327 .................................31
Appendix B. Changes to RFC 6325 ...................................31
Normative References...............................................32
Informative References.............................................33
Acknowledgements...................................................34
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during transient loops, and support for transmission of both unicast and multicast traffic taking advantage of multiple paths in multi-hop networks with arbitrary topology. End stations are connected to TRILL switches with Ethernet, but TRILL switches can be interconnected with arbitrary link technology. TRILL accomplishes this by using [IS-IS] (Intermediate System to Intermediate System) link-state routing [RFC1195] [RFC7176] and a header in TRILL Data packets that includes a hop count. The design supports data labeling by Virtual Local Area Networks (VLANs) and fine-grained labels [RFC7172] as well as optimization of the distribution of multi-destination frames based on data label and multicast groups. Devices that implement TRILL are called TRILL switches or RBridges (Routing Bridges).
IETF多链路透明互连（TRILL）协议[RFC6325]提供无需配置的最佳成对数据帧转发，即使在瞬态循环期间也能安全转发，并支持利用具有任意拓扑结构的多跳网络中的多条路径传输单播和多播通信量。终端站通过以太网连接到TRILL交换机，但TRILL交换机可以通过任意链路技术互连。TRILL通过使用[IS-IS]（中间系统到中间系统）链路状态路由[RFC1195][RFC7176]和TRILL数据包中包含跳数的报头来实现这一点。该设计支持通过虚拟局域网（VLAN）和细粒度标签[RFC7172]进行数据标记，以及基于数据标签和多播组优化多目标帧的分布。实现TRILL的设备称为TRILL交换机或RBridge（路由桥）。
This document provides detailed specifications for five of the link-local aspects of the TRILL protocol used on broadcast links (also called LAN or multi-access links) and for the three of these aspects that are also used on point-to-point (P2P) links. It includes state diagrams and implementation details where appropriate. Alternative implementations that interoperate on the wire are permitted.
本文档提供了广播链路（也称为LAN或多址链路）上使用的TRILL协议的五个链路本地方面的详细规范，以及也用于点对点（P2P）链路的这三个方面的详细规范。它包括适当的状态图和实现细节。允许在线路上进行互操作的替代实现。
The scope of this document is limited to the following aspects of the TRILL protocol; their applicability, along with the most relevant section of this document, are as shown here:
本文件的范围仅限于TRILL协议的以下方面：；其适用性以及本文件最相关的部分如下所示：
LAN P2P Section Link-Local Aspect
--- --- ------- ----------------------------------------------
LAN P2P Section Link-Local Aspect
--- --- ------- ----------------------------------------------
X X 3 Adjacency formation and dissolution X 4 DRB (Designated RBridge) election X X 5 MTU (Maximum Transmission Unit) matching X X 6 1-hop BFD (Bidirectional Forwarding Detection) for adjacency X 7 Creation and use of pseudonodes [IS-IS]
X X 3邻接形成和分解X 4 DRB（指定RBridge）选择X X 5 MTU（最大传输单元）匹配X X 6 1跳BFD（双向转发检测）用于邻接X 7伪节点的创建和使用[IS-IS]
Table 1: LAN/P2P Applicability
表1:LAN/P2P适用性
There is no DRB (also known as DIS (Designated Intermediate System)) election and no pseudonode creation on links configured as point-to-point.
在配置为点到点的链路上，没有DRB（也称为DIS（指定中间系统））选择和伪节点创建。
For other aspects of the TRILL base protocol, see [RFC6325], [RFC6439], [RFC7180], and [ESADI].
有关TRILL基本协议的其他方面，请参见[RFC6325]、[RFC6439]、[RFC7180]和[ESADI]。
This document obsoletes [RFC6327]. See Appendix A for a summary of changes from [RFC6327]. This document updates [RFC6325] as described in Appendix B.
本文件废除了[RFC6327]。[RFC6327]的变更汇总见附录A。本文件更新了附录B中所述的[RFC6325]。
In cases of conflict between this document and [RFC6325], this document prevails.
如果本文件与[RFC6325]之间存在冲突，则以本文件为准。
Section 2 below explains the rationale for the differences between the TRILL Hello protocol and the Layer 3 IS-IS Hello protocol in light of the environment for which the TRILL protocol is designed. It also describes the purposes of the TRILL Hello protocol.
下面的第2节解释了TRILL Hello协议与第3层IS-IS Hello协议之间的区别的基本原理，并结合TRILL协议的设计环境进行了说明。它还描述了TRILL Hello协议的用途。
Section 3 describes the adjacency state machine, its states, and its relevant events.
第3节描述了邻接状态机及其状态和相关事件。
Section 4 describes the Designated RBridge (DRB) election state machine for RBridge LAN ports, its states, and its relevant events.
第4节描述了RBridge LAN端口的指定RBridge（DRB）选择状态机、其状态及其相关事件。
Section 5 describes MTU testing and matching on a TRILL link.
第5节描述了TRILL链路上的MTU测试和匹配。
Section 6 discusses one-hop BFD session bootstrapping in connection with adjacency.
第6节讨论与邻接相关的单跳BFD会话引导。
Section 7 discusses pseudonode creation and use on LAN links.
第7节讨论在LAN链路上创建和使用伪节点。
Section 8 provides more details on the reception and transmission of TRILL Hellos.
第8节提供了关于颤音Hello的接收和传输的更多细节。
Section 9 discusses the case of multiple ports from one RBridge on the same link.
第9节讨论了同一链路上来自一个RBridge的多个端口的情况。
This document uses the acronyms defined in [RFC6325], supplemented by the following additional acronyms:
本文件使用[RFC6325]中定义的首字母缩略词，并辅以以下附加首字母缩略词：
BFD - Bidirectional Forwarding Detection [RFC7175].
BFD-双向转发检测[RFC7175]。
SNPA - Subnetwork Point of Attachment [IS-IS].
SNPA-子网连接点[IS-IS]。
TRILL switch - an alternative name for an RBridge.
颤音开关-RBridge的另一个名称。
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]中所述进行解释。
[IS-IS] has subnetwork-independent functions and subnetwork-dependent functions. Currently, Layer 3 use of IS-IS supports two types of subnetworks: (1) point-to-point link subnetworks between routers and (2) general broadcast (LAN) subnetworks. Because of the differences between the environment of Layer 3 routers and the environment of TRILL RBridges, instead of the subnetwork-dependent functions used at Layer 3, which are specified in Sections 8.2 and 8.4 of [IS-IS], the TRILL protocol uses modified subnetwork-dependent functions for point-to-point subnetworks and broadcast (LAN) subnetworks. The differences between the TRILL and Layer 3 environments are described in Sections 2.1 through 2.4 followed by a summation, in Section 2.5, of the purposes of the TRILL Hello protocol.
[IS-IS]具有子网独立功能和子网相关功能。目前，IS-IS的第3层使用支持两种类型的子网：（1）路由器之间的点到点链路子网和（2）通用广播（LAN）子网。由于第3层路由器环境与TRILL RBridges环境之间的差异，TRILL协议对点到点子网和广播（LAN）使用修改后的子网相关功能，而不是第3层使用的子网相关功能（见[IS-IS]第8.2节和第8.4节）子网。第2.1节至第2.4节描述了TRILL和第3层环境之间的差异，第2.5节总结了TRILL Hello协议的目的。
TRILL supports the interconnection of RBridges by multi-access LAN links such as Ethernet. Because this includes general bridged LANs [802.1Q], the links between RBridges may contain devices or services that can restrict VLAN connectivity, such as [802.1Q] bridges or carrier Ethernet services. In addition, RBridge Ethernet ports, like [802.1Q] ports, can be configured to restrict input/output on a VLAN basis.
TRILL支持通过多址LAN链路（如以太网）互连RBridge。由于这包括通用桥接LAN[802.1Q]，RBridge之间的链路可能包含可限制VLAN连接的设备或服务，例如[802.1Q]网桥或运营商以太网服务。此外，RBridge以太网端口（如[802.1Q]端口）可以配置为基于VLAN限制输入/输出。
For this reason, TRILL Data and TRILL IS-IS packets are sent on Ethernet links in a Designated VLAN that is assumed to provide connectivity between all RBridges on the link. The Designated VLAN is dictated for a LAN link by the elected Designated RBridge on that link (DRB, equivalent to the Designated Intermediate System at Layer 3). On an RBridge Ethernet port configured as point-to-point, TRILL Data and IS-IS packets are sent in that port's Desired Designated VLAN, regardless of the state of any other ports on the link. Connectivity on an Ethernet link configured as point-to-point generally depends on both ends being configured with the same Desired Designated VLAN. Because TRILL Data packets flow between RBridges on an Ethernet link only in the link's Designated VLAN, adjacency for routing calculations is based only on connectivity characteristics in that VLAN.
因此，TRILL数据和TRILL IS-IS数据包在指定VLAN中的以太网链路上发送，该VLAN假定提供链路上所有RBridge之间的连接。指定的VLAN由该链路上选定的指定RBridge（DRB，相当于第3层的指定中间系统）为LAN链路指定。在配置为点对点的RBridge以太网端口上，TRILL数据和IS-IS数据包在该端口所需的指定VLAN中发送，而不管链路上任何其他端口的状态如何。配置为点到点的以太网链路上的连接性通常取决于两端配置了相同的期望指定VLAN。由于TRILL数据包仅在以太网链路的指定VLAN中的RBridge之间流动，因此路由计算的邻接度仅基于该VLAN中的连接特征。
(Non-Ethernet links, such as PPP [RFC6361] generally do not have any Outer.VLAN labeling, so the Designated VLAN for such links has no effect.)
（非以太网链路，如PPP[RFC6361]通常没有任何Outer.VLAN标签，因此为此类链路指定的VLAN无效。）
This section discusses the handling of "native" frames as defined in Section 1.4 of [RFC6325]. As such, this section is not applicable to point-to-point links between TRILL switches or any link where all the TRILL switch ports on the link have been configured as "trunk ports" by setting the end-station service disable bit for the port (see Section 4.9.1 of [RFC6325]).
本节讨论[RFC6325]第1.4节中定义的“本机”帧的处理。因此，本节不适用于TRILL交换机之间的点对点链路，或通过设置端口的终端站服务禁用位将链路上的所有TRILL交换机端口配置为“中继端口”的任何链路（见[RFC6325]第4.9.1节）。
Layer 3 data packets, such as IP packets, are already "tamed" when they are originated by an end station: they include a hop count and Layer 3 source and destination address fields. Furthermore, for ordinary data packets, there is no requirement to preserve any outer Layer 2 addressing, and, if the packets are unicast, they are explicitly addressed to their first-hop router.
第3层数据包（如IP包）在由终端站发起时已被“驯服”：它们包括跳数和第3层源地址和目标地址字段。此外，对于普通数据分组，不需要保留任何外层2寻址，并且，如果分组是单播的，则它们被显式地寻址到它们的第一跳路由器。
In contrast, TRILL switches must accept, transport, and deliver "untamed" native frames: native frames that lack a hop count field usable by TRILL and have Layer 2 MAC (Media Access Control) addresses that indicate their source and destination. These Layer 2 addresses must be preserved for delivery to the native frame's Layer 2 destination. One resulting difference is that RBridge ports providing native frame service must receive in promiscuous MAC address mode, while Layer 3 router ports typically receive in a selective MAC address mode.
相反，TRILL交换机必须接受、传输和交付“未经驯服”的本机帧：本机帧缺少TRILL可用的跃点计数字段，并且具有指示其源和目标的第2层MAC（媒体访问控制）地址。必须保留这些第2层地址，以便传递到本机帧的第2层目标。由此产生的一个差异是，提供本机帧服务的RBridge端口必须以混杂MAC地址模式接收，而第3层路由器端口通常以选择性MAC地址模式接收。
TRILL handles these requirements by having, on the link where an end station originates a native frame, one RBridge "ingress" such a locally originated native frame by adding a TRILL Header that includes a hop count, thus converting it to a TRILL Data packet. This augmented packet is then routed to one RBridge on the link having the destination end station for the frame (or one RBridge on each such link if it is a multi-destination frame). Such final RBridges perform an "egress" function, removing the TRILL Header and delivering the original frame to its destination(s). (For the purposes of TRILL, a Layer 3 router is an end station.)
TRILL通过在终端站发起本机帧的链路上，通过添加包含跳数的TRILL报头，使一个RBridge“进入”这样一个本地发起的本机帧，从而将其转换为TRILL数据包来处理这些要求。然后，该增强分组被路由到具有该帧的目的地端站的链路上的一个RBridge（或者如果是多目的地帧，则在每个这样的链路上的一个RBridge）。这样的最终RBridges执行“出口”功能，移除颤音报头并将原始帧传送到其目的地。（就TRILL而言，第3层路由器是终端站。）
Care must be taken to avoid a loop that would involve egressing a native frame and then re-ingressing it because, while it is in native form, it would not be protected by a hop count and could loop forever. Such a loop could, for multi-destination frames, even involve multiplication of the number of frames each time around and would likely saturate all links involved within milliseconds. For TRILL, safety against such loops for a link is more important than transient loss of data connectivity on that link.
必须注意避免出现循环，该循环将涉及先退出本机帧，然后再重新进入本机帧，因为虽然它是本机格式的，但它不会受到跃点计数的保护，并且可能永远循环。对于多目的帧，这样的循环甚至可能涉及每次帧数的乘法，并且可能在毫秒内使所有相关链路饱和。对于TRILL来说，针对链路的此类环路的安全性比该链路上数据连接的瞬时丢失更为重要。
The primary TRILL defense mechanism against such loops, which is mandatory, is to assure that, as far as practically possible, there is only a single RBridge that is in charge of ingressing and egressing native frames from and to a link where TRILL is offering end-station service. This is the Designated RBridge and Appointed Forwarder mechanism initially specified in the TRILL base protocol [RFC6325], discussed in Section 2.5 below, and further specified in both Section 4 below and [RFC6439].
针对此类环路的主要TRILL防御机制是强制性的，其目的是确保在实际可行的情况下，只有一个RBridge负责从TRILL提供端站服务的链路进出本机帧。这是TRILL基本协议[RFC6325]中最初规定的指定RBridge和指定转发器机制，在下文第2.5节中讨论，并在下文第4节和[RFC6439]中进一步规定。
TRILL provides connectivity and least-cost paths with zero configuration. For additional services, it strives to require only minimal configuration; however, services that require configuration when offered by [802.1Q] bridges, such as non-default VLANs or priority, will require configuration. This differs from Layer 3 routing where routers typically need to be configured as to the subnetworks connected to each port, etc., to provide service.
TRILL以零配置提供连接和成本最低的路径。对于附加服务，它力求只需要最少的配置；但是，[802.1Q]网桥提供的服务（如非默认VLAN或优先级）需要配置。这与第3层路由不同，在第3层路由中，路由器通常需要配置为连接到每个端口等的子网，以提供服务。
TRILL IS-IS needs to be robust against links with reasonably restricted MTUs, including links that accommodate only the classic Ethernet frame size, despite the addition of reasonable headers such as VLAN tags. Such robustness is particularly required for TRILL Hellos to assure correct adjacency and the election of a unique DRB on LAN links.
TRILL IS-IS需要对具有合理限制的MTU的链路具有鲁棒性，包括仅容纳经典以太网帧大小的链路，尽管添加了合理的报头，如VLAN标记。TRILL Hellos特别需要这种健壮性，以确保正确的邻接和在LAN链路上选择唯一的DRB。
TRILL will also be used inside data centers where it is common for all or most of the links and switches to support frames substantially larger than the classic Ethernet maximum size. For example, they may have an MTU adequate to comfortably handle Fiber Channel over Ethernet frames, for which T11 recommends a 2,500-byte MTU [FCoE], or even 9K byte jumbo frames. It would be beneficial for a TRILL campus with such a large MTU to be able to safely make use of it.
TRILL还将在数据中心内使用，在数据中心内，所有或大多数链路和交换机都使用TRILL来支持大大大于传统以太网最大尺寸的帧。例如，它们可能有一个MTU，足以舒适地处理以太网帧上的光纤通道，T11建议使用2500字节的MTU[FCoE]，甚至9K字节的巨型帧。拥有如此大的MTU的TRILL校园能够安全地使用它将是有益的。
These needs are met by a mandatory maximum on the size of TRILL Hellos and by the optional use of MTU testing as described below.
这些需求通过TRILL Hellos大小的强制最大值和如下所述的可选MTU测试来满足。
There are three purposes for the TRILL Hello protocol. They are listed below, along with a reference to the section of this document in which each is discussed:
TRILL Hello协议有三个用途。下面列出了它们，并参考了本文件中讨论每一部分的章节：
1. To determine which RBridge neighbors have acceptable connectivity to be reported as part of the topology (Section 3)
1. 确定哪些RBridge邻居具有可接受的连接，作为拓扑的一部分进行报告（第3节）
2. To elect a unique Designated RBridge on broadcast (LAN) links (Section 4)
2. 在广播（LAN）链路上选择唯一的指定RBridge（第4节）
3. To determine the MTU with which it is possible to safely communicate with each RBridge neighbor (Section 5)
3. 确定能够与每个RBridge邻居安全通信的MTU（第5节）
In Layer 3 IS-IS, all three of these functions are combined. Hellos may be padded to the maximum length (see [RFC3719], Section 6) so that a router neighbor is not discovered if it is impossible to communicate with it using maximum-sized Layer 3 IS-IS packets. Also, even if Hellos from a neighbor R2 are received by R1, if connectivity to R2 is not 2-way (i.e., R2 does not list R1 in R2's Hello), then R1 does not consider R2 as a Designated Intermediate System (Designated Router) candidate. Because of this logic, it is possible at Layer 3 for multiple Designated Routers to be elected on a LAN, with each representing the LAN as a pseudonode. It appears to the topology as if the LAN is now two or more separate LANs. Although this is surprising, this does not cause problems for Layer 3.
在第3层IS-IS中，这三种功能都是组合的。Hellos可以填充到最大长度（参见[RFC3719]，第6节），以便在无法使用最大大小的第3层is-is数据包与其通信时，不会发现路由器邻居。此外，即使R1接收来自邻居R2的Help，如果到R2的连接不是2路（即R2不在R2的Hello中列出R1），则R1不考虑R2作为指定的中间系统（指定路由器）候选。由于这种逻辑，在第3层，可以在LAN上选择多个指定路由器，每个路由器将LAN表示为伪节点。在拓扑结构上，似乎LAN现在是两个或多个独立的LAN。尽管这令人惊讶，但这不会给第3层带来问题。
In contrast, this behavior is not acceptable for TRILL, since in TRILL it is important that all RBridges on a link know about each other, and on broadcast (LAN) links that they choose a single RBridge to be the DRB to control the native frame ingress and egress. Otherwise, multiple RBridges might ingress/egress the same native frame, forming loops that are not protected by the hop count in the TRILL Header as discussed above.
相反，这种行为对于TRILL是不可接受的，因为在TRILL中，链路上的所有RBridge必须相互了解，而在广播（LAN）链路上，它们必须选择单个RBridge作为DRB来控制本机帧的进出。否则，多个rbridge可能进入/离开同一本机帧，形成不受TRILL报头中跳数保护的循环，如上所述。
The TRILL Hello protocol is best understood by focusing separately on each of these three functions listed above, which we do in Sections 3, 4, and 5.
TRILL Hello协议最好通过分别关注上面列出的这三个函数中的每一个来理解，这是我们在第3、4和5节中所做的。
One other issue with TRILL LAN Hellos is to ensure that subsets of the information can appear in any single message, and be processable, in the spirit of IS-IS Link State PDUs (LSPs) and Complete Sequence Number PDUs (CSNPs). LAN TRILL Hello packets, even though they are not padded, can become very large. An example where this might be the case is when some sort of backbone technology interconnects hundreds of TRILL sites over what would appear to TRILL to be a giant Ethernet, where the RBridges connected to that cloud will perceive
TRILL LAN Hellos的另一个问题是，按照is-is链路状态PDU（LSP）和完整序列号PDU（CSNPs）的精神，确保信息子集可以出现在任何单个消息中，并且是可处理的。LAN颤音Hello数据包，即使没有填充，也会变得非常大。一个可能出现这种情况的例子是，当某种主干技术将数百个TRILL站点互连在一个巨大的以太网上时，连接到该云的RBridge将感知到
that backbone to be a single link with hundreds of neighbors. Thus, the TRILL LAN Hello uses a different Neighbor TLV [RFC7176] that lists neighbors seen for a range of MAC (SNPA) addresses.
该主干网是一条连接数百个邻居的单一链路。因此，TRILL LAN Hello使用不同的邻居TLV[RFC7176]，该TLV列出了一系列MAC（SNPA）地址的邻居。
Each RBridge port has associated with it a port state, as discussed in Section 4, and a table of zero or more adjacencies (if the port is configured as point-to-point, zero, or one) as discussed in this section. The states such adjacencies can have, the events that cause adjacency state changes, the actions associated with those state changes, a state table, and a state diagram are given below.
如第4节所述，每个RBridge端口都与其关联一个端口状态，以及一个包含零个或多个邻接的表（如果端口配置为点对点、零或一个），如本节所述。下面给出了此类邻接可能具有的状态、导致邻接状态更改的事件、与这些状态更改相关联的操作、状态表和状态图。
The determination of adjacencies on links is made using TRILL Hellos (see Section 8), an optional MTU test (see Section 5), and, optionally, BFD (see Section 6) and/or other connectivity tests. If the MAC (SNPA) addresses of more than one RBridge port on a broadcast link are the same, all but one of such ports are put in the Suspended state (see Section 4) and do not participate in the link, except to monitor whether they should stay suspended. If the two ports on a point-to-point link have MAC (SNPA) addresses, it does not affect TRILL operation if they are the same. (PPP ports, for example, do not have MAC addresses [RFC6361].)
使用TRILL Hellos（见第8节）、可选MTU测试（见第5节）、可选BFD（见第6节）和/或其他连通性测试确定链路上的邻接。如果广播链路上多个RBridge端口的MAC（SNPA）地址相同，则除一个端口外，所有此类端口都处于挂起状态（参见第4节），并且不参与链路，除非用于监视它们是否应保持挂起状态。如果点到点链路上的两个端口具有MAC（SNPA）地址，则如果它们相同，则不会影响TRILL操作。（例如，PPP端口没有MAC地址[RFC6361]。）
The following items MUST be the same for all TRILL Hellos issued by an RBridge on a particular Ethernet port, regardless of the VLAN in which the Hello is sent:
对于特定以太网端口上由RBridge发出的所有TRILL Hello，无论发送Hello的VLAN如何，以下项目必须相同：
- Source MAC address,
- 源MAC地址，
- Priority to be the DRB,
- 优先成为DRB，
- Desired Designated VLAN,
- 所需的指定VLAN，
- Port ID, and,
- 端口ID，以及，
- if included, BFD-Enabled TLV [RFC6213] and PORT-TRILL-VER sub-TLV [RFC7176].
- 如果包括，BFD启用TLV[RFC6213]和端口颤音版本子TLV[RFC7176]。
Of course, the priority, Desired Designated VLAN, and possibly the inclusion or value of the PORT-TRILL-VER sub-TLV, and/or BFD-Enabled TLV can change on occasion, but then the new value(s) must similarly be used in all TRILL Hellos on the LAN port, regardless of VLAN.
当然，优先级、所需的指定VLAN，以及可能的PORT-TRILL-VER子TLV和/或启用BFD的TLV的包含或值有时会发生变化，但新值必须类似地用于LAN端口上的所有TRILL Hello，而不管VLAN如何。
On broadcast links:
关于广播链接：
Because bridges acting as glue on an Ethernet broadcast link might be configured in such a way that some VLANs are partitioned, it is necessary for RBridges to transmit Hellos on Ethernet links with multiple VLAN tags. The conceptually simplest solution may have been to have RBridges transmit up to 4,094 times as many Hellos, one with each legal VLAN ID enabled at each port, but this would obviously have deleterious performance implications. So, the TRILL protocol specifies that if RB1 knows it is not the DRB, it transmits its Hellos on only a limited set of VLANs. Only an RBridge that believes itself to be the DRB on a broadcast Ethernet link "sprays" its TRILL Hellos on all of its enabled VLANs at the port. And in both cases, an RBridge can be configured to send Hellos on only a subset of those VLANs. The details are given in [RFC6325], Section 4.4.3.
由于在以太网广播链路上充当粘合剂的网桥可能以某些VLAN被分区的方式进行配置，因此RBridges有必要在具有多个VLAN标记的以太网链路上传输HELOS。概念上最简单的解决方案可能是让RBridges传输高达4094倍的hello，每个端口启用一个合法的VLAN ID，但这显然会对性能产生有害影响。因此，TRILL协议规定，如果RB1知道它不是DRB，它将只在有限的一组VLAN上传输Hello。只有认为自己是广播以太网链路上的DRB的RBridge在端口上的所有启用的VLAN上“喷射”它的颤音。在这两种情况下，RBridge可以配置为仅在这些VLAN的子集上发送Hello。详情见[RFC6325]第4.4.3节。
On point-to-point links:
在点到点链接上：
If the link technology is VLAN sensitive, such as Ethernet, an RBridge sends TRILL Hellos only in the Desired Designated VLAN for which it is configured.
如果链路技术对VLAN敏感，例如以太网，则RBridge仅在为其配置的所需指定VLAN中发送TRILL Hello。
Every adjacency is in one of four states, whether it is one of the adjacencies on a broadcast link or the one possible adjacency on a point-to-point link. An RBridge participates in LSP synchronization at a port as long as it has one or more adjacencies out of that port that are in the 2-Way or Report state.
每个邻接都处于四种状态之一，无论是广播链路上的一种邻接还是点到点链路上的一种可能邻接。只要RBridge在某个端口上有一个或多个相邻端口处于双向或报告状态，RBridge就会参与该端口的LSP同步。
Down: This is a virtual state for convenience in creating state diagrams and tables. It indicates that the adjacency is nonexistent, and there is no entry in the adjacency table for it.
向下：这是一个虚拟状态，便于创建状态图和表。它表示邻接不存在，并且邻接表中没有它的条目。
Detect: A neighbor RBridge has been detected through receipt of a TRILL Hello, but either 2-way connectivity has not been confirmed or the detection was on an Ethernet link in a VLAN other than the Designated VLAN.
检测：通过接收TRILL Hello检测到邻居RBridge，但双向连接尚未确认，或者检测是在指定VLAN以外的VLAN中的以太网链路上进行的。
2-Way: 2-way connectivity to the neighbor has been found and, if the link is Ethernet, it was found on the Designated VLAN, but some enabled test, such as the link MTU meeting the minimum campus requirement or BFD confirming link connectivity, has not yet succeeded.
双向：已找到与邻居的双向连接，如果链路是以太网，则在指定的VLAN上找到该连接，但某些已启用的测试（如满足最低校园要求的链路MTU或确认链路连接的BFD）尚未成功。
Report: There is 2-way connectivity to the neighbor (on the Designated VLAN if an Ethernet link); all enabled tests have succeeded, including, if enabled, MTU and/or BFD testing. This state will cause adjacency to be reported in an LSP (with appropriate provision for a pseudonode, if any, as described in Section 7).
报告：与邻居有双向连接（如果是以太网链路，则在指定的VLAN上）；所有启用的测试均已成功，包括MTU和/或BFD测试（如果启用）。该状态将导致在LSP中报告邻接（如第7节所述，对伪节点（如有）有适当的规定）。
For an adjacency in any of the three non-Down states (Detect, 2-Way, or Report), there will be an adjacency table entry. That entry will give the state of the adjacency and will also include the information listed below.
对于处于三种非关闭状态（检测、双向或报告）中的任何一种的邻接，将有一个邻接表条目。该条目将给出邻接状态，还将包括下面列出的信息。
o The address, if any, of the neighbor, the Port ID, and the System ID in the received Hellos. Together, these three quantities uniquely identify the adjacency on a broadcast link.
o 邻居的地址（如果有）、端口ID和接收到的Hello中的系统ID。这三个量共同唯一地标识广播链路上的邻接。
o One or more Hello holding timers. For a point-to-point adjacency, there is a single Hello holding timer. For a broadcast LAN adjacency, there are exactly two Hello holding timers: a Designated VLAN holding timer and a non-Designated VLAN holding timer. Each timer consists of a 16-bit unsigned integer number of seconds.
o 一个或多个Hello holding计时器。对于点对点邻接，有一个Hello保持计时器。对于广播LAN邻接，正好有两个Hello保持计时器：一个指定的VLAN保持计时器和一个非指定的VLAN保持计时器。每个计时器由16位无符号整数秒组成。
o If the adjacency is on a broadcast link, the 7-bit unsigned priority of the neighbor to be the DRB.
o 如果相邻在广播链路上，则相邻的7位无符号优先级为DRB。
o The 5 bytes of data from the PORT-TRILL-VER received in the most recent TRILL Hello from the neighbor RBridge.
o 在最近的TRILL Hello中从邻居RBridge接收到的来自PORT-TRILL-VER的5字节数据。
o The VLAN that the neighbor RBridge wants to be the Designated VLAN on the link, called the Desired Designated VLAN.
o 邻居RBridge希望成为链路上指定VLAN的VLAN，称为所需的指定VLAN。
o For an adjacency table at an RBridge that supports BFD, a flag indicating whether the last received TRILL Hello from the neighbor RBridge contained a BFD-Enabled TLV (see Section 6).
o 对于支持BFD的RBridge处的邻接表，一个标志指示最近从相邻RBridge接收到的TRILL Hello是否包含启用BFD的TLV（参见第6节）。
The following events can change the state of an adjacency:
以下事件可以更改邻接的状态：
A0. Receive a TRILL Hello for a broadcast LAN adjacency whose source MAC address (SNPA) is equal to that of the port on which it is received. This is a special event that cannot occur on a port configured as point-to-point and is handled as described immediately after this list of events. It does not appear in the state transition table or diagram.
A0。接收广播LAN邻接的颤音Hello，其源MAC地址（SNPA）等于接收它的端口的MAC地址。这是一个特殊事件，不能在配置为点到点的端口上发生，并在事件列表之后立即按说明进行处理。它不会出现在状态转换表或图表中。
A1. Receive a TRILL Hello (other than an A0 event) such that:
A1。接收颤音Hello（A0事件除外），以便：
- If received on an Ethernet port, it was received in the Designated VLAN.
- 如果在以太网端口上接收，则在指定的VLAN中接收。
- If received for a broadcast LAN adjacency, it contains a TRILL Neighbor TLV that explicitly lists the receiving port's (SNPA) address.
- 如果接收到广播LAN邻接，则它包含一个明确列出接收端口（SNPA）地址的TRILL Neighbor TLV。
- If received for a point-to-point adjacency, it contains a Three-Way Handshake TLV with the receiver's System ID and Extended Circuit ID.
- 如果接收到的是点对点邻接，则它包含一个带有接收器系统ID和扩展电路ID的三向握手TLV。
A2. Event A2 is not possible for a port configured as point-to-point. Receive a TRILL Hello (other than an A0 event) such that either
A2。对于配置为点对点的端口，不可能发生事件A2。接收颤音Hello（A0事件除外），以便
- The port is Ethernet and the Hello was not on the Designated VLAN (any TRILL Neighbor TLV in such a Hello is ignored), or
- 端口是以太网，Hello不在指定的VLAN上（忽略此类Hello中的任何TRILL邻居TLV），或
- The Hello does not contain a TRILL Neighbor TLV covering an address range that includes the receiver's (SNPA) address.
- Hello不包含覆盖包括接收器（SNPA）地址的地址范围的颤音邻居TLV。
A3. Receive a TRILL Hello (other than an A0 event) such that:
A3。接收颤音Hello（A0事件除外），以便：
- If received on an Ethernet port, it was received in the Designated VLAN.
- 如果在以太网端口上接收，则在指定的VLAN中接收。
- If received for a broadcast LAN adjacency, it contains one or more TRILL Neighbor TLVs covering an address range that includes the receiver's (SNPA) address and none of which list the receiver.
- 如果接收到广播LAN邻接，则它包含一个或多个TRILL Neighbor TLV，覆盖的地址范围包括接收机（SNPA）地址，并且没有一个列出接收机。
- If received for a point-to-point adjacency, it contains a Three-Way Handshake TLV with either the System ID or Extended Circuit ID or both not equal to that of the receiver.
- 如果接收的是点对点邻接，则它包含一个三向握手TLV，系统ID或扩展电路ID或两者都不等于接收器的ID。
A4. Either
A4。任何一个
(1) the Hello holding timer expires on a point-to-point adjacency, or
(1) Hello保持计时器在点对点邻接处过期，或
(2) on a broadcast LAN adjacency,
(2) 在广播局域网邻接处，
(2a) both Hello timers expire simultaneously or
（2a）两个Hello定时器同时到期，或
(2b) one Hello timer expires when the other Hello timer is already in the expired state.
（2b）当另一个Hello定时器已经处于过期状态时，一个Hello定时器过期。
A5. For a broadcast LAN adjacency, the Designated VLAN Hello holding timer expires, but the non-Designated VLAN Hello holding timer still has time left until it expires. This event cannot occur for a point-to-point adjacency.
A5。对于广播LAN邻接，指定的VLAN Hello保持计时器将过期，但非指定的VLAN Hello保持计时器在过期之前仍有剩余时间。对于点对点邻接，无法发生此事件。
A6. MTU if enabled, BFD if enabled, and all other enabled connectivity tests successful.
A6。MTU（如果启用）、BFD（如果启用）和所有其他启用的连接测试成功。
A7. MTU if enabled, BFD if enabled, and all other enabled connectivity tests were successful but one or more now fail.
A7。MTU（如果启用）、BFD（如果启用）和所有其他已启用的连接测试均成功，但现在有一个或多个连接测试失败。
A8. The RBridge port goes operationally down.
A8。RBridge端口在运行中关闭。
For the special A0 event, the Hello is examined to determine if it has a higher priority than the port on which it is received such that the sending port should be the DRB as described in Section 4.2.1. If the Hello is of lower priority than the receiving port, it is discarded with no further action. If it is of higher priority than the receiving port, then any adjacencies for the receiving port are discarded (transitioned to the Down state), and the port is suspended as described in Section 4.2.
对于特殊A0事件，检查Hello以确定其优先级是否高于接收它的端口，以便发送端口应为第4.2.1节所述的DRB。如果Hello的优先级低于接收端口，则将丢弃它，无需进一步操作。如果其优先级高于接收端口，则丢弃接收端口的任何邻接（转换为关闭状态），并按照第4.2节所述暂停该端口。
The receipt of a TRILL Hello that is not an event A0 causes the following actions (except where the Hello would have created a new adjacency table entry but both the adjacency table is full and the Hello is too low priority to displace an existing entry as described in Section 3.6). The Designated VLAN referred to is the Designated VLAN dictated by the DRB determined without taking the received TRILL LAN Hello into account (see Section 4) for a broadcast LAN and the local Desired Designated VLAN for a port configured as point-to-point.
接收到非事件A0的颤音Hello会导致以下操作（除非Hello会创建一个新的邻接表条目，但邻接表已满，且Hello的优先级过低，无法替换第3.6节所述的现有条目）。所指的指定VLAN是由DRB指定的指定VLAN，该指定VLAN的确定不考虑广播LAN接收到的TRILL LAN Hello（参见第4节）和配置为点到点的端口的本地所需指定VLAN。
o If the receipt of a Hello creates a new adjacency table entry, the neighbor RBridge MAC (SNPA) address (if any), Port ID, and System ID are set from the Hello.
o 如果Hello的接收创建了一个新的邻接表条目，则从Hello设置邻居RBridge MAC（SNPA）地址（如果有）、端口ID和系统ID。
o For a point-to-point adjacency, the Hello holding timer is set from the Holding Time field of the Hello. For a broadcast link adjacency, the appropriate Hello holding timer for that adjacency, depending on whether or not the Hello was received in the Designated VLAN, is set to the Holding Time field of the Hello and if the receipt of the LAN Hello is creating a new adjacency table entry, the other timer is set to expired.
o 对于点对点邻接，Hello保持计时器是从Hello的保持时间字段设置的。对于广播链路邻接，根据是否在指定的VLAN中接收到Hello，该邻接的相应Hello保持计时器被设置为Hello的保持时间字段，并且如果LAN Hello的接收正在创建新的邻接表条目，则另一个计时器被设置为过期。
o For a broadcast link adjacency, the priority of the neighbor RBridge to be the DRB is set to the priority field of the LAN Hello.
o 对于广播链路邻接，要作为DRB的相邻RBridge的优先级设置为LAN Hello的优先级字段。
o For a broadcast link adjacency, the VLAN that the neighbor RBridge wants to be the Designated VLAN on the link is set from the Hello.
o 对于广播链路邻接，邻居RBridge希望成为链路上指定VLAN的VLAN是从Hello设置的。
o The 5 bytes of PORT-TRILL-VER data are set from that sub-TLV in the Hello or set to zero if that sub-TLV does not occur in the Hello.
o PORT-TRILL-VER数据的5字节从Hello中的该子TLV设置，或者如果该子TLV未在Hello中出现，则设置为零。
o For a broadcast link, if the creation of a new adjacency table entry or the priority update above changes the results of the DRB election on the link, the appropriate RBridge port event (D2 or D3) occurs, after the above actions, as described in Section 4.2.
o 对于广播链路，如果创建新的邻接表条目或上述优先级更新更改了链路上DRB选择的结果，则在上述操作后，如第4.2节所述，会发生相应的RBridge端口事件（D2或D3）。
o For a broadcast link adjacency, if there is no change in the DRB, but the neighbor Hello is from the DRB and has a changed Designated VLAN from the previous Hello received from the DRB, the result is a change in Designated VLAN for the link as specified in Section 4.2.3.
o 对于广播链路邻接，如果DRB中没有变化，但邻居Hello来自DRB，并且其指定VLAN与从DRB接收到的前一个Hello不同，则结果是第4.2.3节中规定的链路指定VLAN的变化。
An event A4 resulting in the adjacency transitioning to the Down state may also result in an event D3 as described in Section 4.2.
导致邻接过渡到关闭状态的事件A4也可能导致第4.2节所述的事件D3。
Concerning events A6 and A7, if none of MTU, BFD, or other testing is enabled, A6 is considered to occur immediately upon the adjacency entering the 2-Way state, and A7 cannot occur.
关于事件A6和A7，如果MTU、BFD或其他测试均未启用，则认为A6会在邻接处进入双向状态时立即发生，且A7不会发生。
See further TRILL Hello receipt details in Section 8.
详见第8节中的TRILL Hello收据详情。
The table below shows the transitions between the states defined above, based on the events defined above:
下表根据上面定义的事件显示了上面定义的状态之间的转换：
| Event | Down | Detect | 2-Way | Report |
+-------+--------+--------+--------+--------+
| A1 | 2-Way | 2-Way | 2-Way | Report |
| A2 | Detect | Detect | 2-Way | Report |
| A3 | Detect | Detect | Detect | Detect |
| A4 | N/A | Down | Down | Down |
| A5 | N/A | Detect | Detect | Detect |
| A6 | N/A | N/A | Report | Report |
| A7 | N/A | N/A | 2-Way | 2-Way |
| A8 | Down | Down | Down | Down |
| Event | Down | Detect | 2-Way | Report |
+-------+--------+--------+--------+--------+
| A1 | 2-Way | 2-Way | 2-Way | Report |
| A2 | Detect | Detect | 2-Way | Report |
| A3 | Detect | Detect | Detect | Detect |
| A4 | N/A | Down | Down | Down |
| A5 | N/A | Detect | Detect | Detect |
| A6 | N/A | N/A | Report | Report |
| A7 | N/A | N/A | 2-Way | 2-Way |
| A8 | Down | Down | Down | Down |
Table 2: Adjacency State Table
表2：邻接状态表
"N/A" indicates that the event to the left is not applicable in the state at the top of the column. These events affect only a single adjacency. The special A0 event transitions all adjacencies to Down, as explained immediately after the list of adjacency events in Section 3.3.
“N/A”表示左侧事件在列顶部的状态下不适用。这些事件仅影响一个相邻关系。如第3.3节中邻接事件列表后立即解释的，特殊A0事件将所有邻接转换为向下。
The diagram below presents the same information as that in the state table:
下图显示的信息与状态表中的信息相同：
+---------------+
| Down |<--------+
+---------------+ |
| | ^ | |
A2,A3| |A8| |A1 |
| +--+ | |
| +-----------|---+
V | |
+----------------+ A4,A8 | |
+----->| Detect |------->| |
| +----------------+ | |
| | | ^ | |
| A1| |A2,A3,A5 | | |
| | +---------+ | |
| | | |
| | +------------|---+
| | | |
| V V |
|A3,A5 +----------------+ A4,A8 |
|<-----| 2-Way |------->|
| +----------------+ |
| | ^ | ^ |
| A6| | |A1,A2,A7| |
| | | +--------+ |
| | | |
| | |A7 |
| V | |
|A3,A5 +-------------+ A4,A8 |
|<-----| Report |---------->|
+-------------+
| ^
|A1,A2,A6 |
+---------+
+---------------+
| Down |<--------+
+---------------+ |
| | ^ | |
A2,A3| |A8| |A1 |
| +--+ | |
| +-----------|---+
V | |
+----------------+ A4,A8 | |
+----->| Detect |------->| |
| +----------------+ | |
| | | ^ | |
| A1| |A2,A3,A5 | | |
| | +---------+ | |
| | | |
| | +------------|---+
| | | |
| V V |
|A3,A5 +----------------+ A4,A8 |
|<-----| 2-Way |------->|
| +----------------+ |
| | ^ | ^ |
| A6| | |A1,A2,A7| |
| | | +--------+ |
| | | |
| | |A7 |
| V | |
|A3,A5 +-------------+ A4,A8 |
|<-----| Report |---------->|
+-------------+
| ^
|A1,A2,A6 |
+---------+
Figure 1: Adjacency State Diagram
图1：邻接状态图
There can be multiple parallel adjacencies between neighbor RBridges that are visible to TRILL. (Multiple low-level links that have been bonded together by technologies such as link aggregation [802.1AX] appear to TRILL as a single link over which only a single TRILL adjacency can be established.)
颤音可见的相邻RBridge之间可能存在多个平行邻接。（通过链路聚合[802.1AX]等技术连接在一起的多个低级链路看起来像是一个只能建立单个颤音邻接的单个链路。）
Any such links that have pseudonodes (see Section 7) are distinguished in the topology; such adjacencies, if they are in the Report state, appear in LSPs as per Section 7. However, there can be multiple parallel adjacencies without pseudonodes because they are point-to-point adjacencies or LAN adjacencies for which a pseudonode is not being created. Such parallel, non-pseudonode adjacencies in the Report state appear in LSPs as a single adjacency. The cost of such an adjacency MAY be adjusted downwards to account for the parallel paths. Multipathing across such parallel connections can be freely done for unicast TRILL Data traffic on a per-flow basis but is restricted for multi-destination traffic, as described in Section 4.5.2 (point 3) of [RFC6325] and Appendix C of [RFC6325].
具有伪节点的任何此类链路（见第7节）在拓扑中都是可区分的；根据第7节，如果这些邻接处于报告状态，则会出现在LSP中。但是，可以有多个没有伪节点的并行邻接，因为它们是点对点邻接或LAN邻接，没有为其创建伪节点。报告状态中的此类并行非伪节点邻接在LSP中显示为单个邻接。这种邻接的成本可以向下调整，以考虑平行路径。如[RFC6325]第4.5.2节（第3点）和[RFC6325]附录C中所述，可以在每个流的基础上自由地对单播TRILL数据流量进行跨此类并行连接的多路径传输，但对多目的地流量进行限制。
If the receipt of a TRILL Hello would create a new adjacency table entry (that is, would transition an adjacency out of the Down state), there may be no space for the new entry. For ports that are configured as point-to-point and can thus only have zero or one adjacency not in the Down state, it is RECOMMENDED that space be reserved for one adjacency so that this condition cannot occur.
如果TRILL Hello的接收将创建一个新的邻接表条目（即，将邻接转换为关闭状态），则可能没有空间容纳新条目。对于配置为点对点且因此只能有零个或一个邻接而不处于关闭状态的端口，建议为一个邻接保留空间，以避免出现这种情况。
When there is adjacency table space exhaustion, the DRB election priority (see Section 4.2.1) of the new entry that would be created is compared with the DRB election priority for the existing entries. If the new entry is higher priority than the lowest priority existing entry, it replaces the lowest priority existing entry, which is transitioned to the Down state.
当邻接表空间耗尽时，将创建的新条目的DRB选择优先级（见第4.2.1节）与现有条目的DRB选择优先级进行比较。如果新条目的优先级高于最低优先级的现有条目，则它将替换转换为关闭状态的最低优先级的现有条目。
This section specifies the DRB election process in TRILL at a broadcast (LAN) link port. Since there is no such election when a port is configured as point-to-point, this section does not apply in that case.
本节规定了广播（LAN）链路端口上以颤音表示的DRB选择过程。由于将端口配置为点对点时没有这种选择，因此本节不适用于这种情况。
The information at an RBridge associated with each of its broadcast LAN ports includes the following:
RBridge上与其每个广播LAN端口相关联的信息包括：
o Enablement bit, which defaults to enabled.
o 启用位，默认为启用。
o The 5 bytes of PORT-TRILL-VER sub-TLV data used in TRILL Hellos sent on the port.
o 在端口上发送的TRILL Hello中使用的5字节PORT-TRILL-VER子TLV数据。
o SNPA address (commonly a 48-bit MAC address) of the port.
o 端口的SNPA地址（通常为48位MAC地址）。
o Port ID, used in TRILL Hellos sent on the port.
o 端口ID，用于在端口上发送的颤音Hello。
o The Holding Time, used in TRILL Hellos sent on the port.
o 等待时间，用于在端口上发送的颤音Hello。
o The priority to be the DRB, used in TRILL LAN Hellos sent on the port.
o 优先级为DRB，用于在端口上发送的TRILL LAN Hello。
o BFD support. If the port supports BFD, a BFD Enabled flag that controls whether or not a BFD-Enabled TLV is included in TRILL Hellos sent on the port.
o BFD支持。如果端口支持BFD，则为BFD Enabled标志，用于控制端口上发送的TRILL Hello中是否包含启用BFD的TLV。
o The DRB state of the port, determined as specified below.
o 端口的DRB状态，如下所述确定。
o A 16-bit unsigned Suspension Timer, measured in seconds.
o 16位无符号暂停计时器，以秒为单位。
o The Desired Designated VLAN. The VLAN this RBridge wants to be the Designated VLAN for the link out of this port, used in TRILL Hellos sent on the port if the link is Ethernet.
o 所需的指定VLAN。此RBridge想要成为此端口外链路的指定VLAN，如果链路是以太网，则在端口上发送的TRILL Hello中使用。
o A table of zero or more adjacencies (see Section 3).
o 包含零个或多个邻接的表格（见第3节）。
The TRILL equivalent of the DIS (Designated Intermediate System) on a broadcast link is the DRB or Designated RBridge. The DRB election state machinery is described below.
广播链路上DIS（指定的中间系统）的颤音等效物是DRB或指定的RBridge。DRB选举国家机构描述如下。
Each RBridge port that is not configured as point-to-point is in one of the following four DRB states:
未配置为点对点的每个RBridge端口都处于以下四种DRB状态之一：
Down: The port is operationally down. It might be administratively disabled or down at the link layer. In this state, there will be no adjacencies for the port, and no TRILL Hellos or other TRILL IS-IS PDUs or TRILL Data packets are accepted or transmitted.
停机：端口处于操作停机状态。它可能在链接层被管理禁用或关闭。在此状态下，端口将没有邻接，并且不会接受或传输TRILL Hellos或其他TRILL IS-IS PDU或TRILL数据包。
Suspended: Operation of the port is suspended because there is a higher priority port on the link with the same MAC (SNPA) address. This is the same as the Down state, with the exception that TRILL
挂起：由于链路上有一个优先级较高的端口具有相同的MAC（SNPA）地址，因此该端口的操作被挂起。这与关闭状态相同，但颤音除外
Hellos are accepted for the sole purpose of determining whether to change the value of the Suspension Timer for the port as described below.
接受Hellos的唯一目的是确定是否更改端口的暂停计时器值，如下所述。
DRB: The port is the DRB and can receive and transmit TRILL Data packets.
DRB：端口是DRB，可以接收和发送TRILL数据包。
Not DRB: The port is deferring to another port on the link, which it believes is the DRB, but can still receive and transmit TRILL Data packets.
非DRB：该端口延迟到链路上的另一个端口，它认为该端口是DRB，但仍然可以接收和发送TRILL数据包。
The following events can change the DRB state of a port. Note that this is only applicable to broadcast links. There is no DRB state or election at a port configured to be point-to-point.
以下事件可能会更改端口的DRB状态。请注意，这仅适用于广播链接。配置为点对点的端口没有DRB状态或选择。
D1. The port becomes enabled or the Suspension Timer expires while the port is in the Suspended state.
D1。当端口处于挂起状态时，端口将启用或挂起计时器过期。
D2. The adjacency table for the port changes, and there are now entries for one or more other RBridge ports on the link that appear to be higher priority to be the DRB than the local port.
D2。端口的邻接表发生变化，现在链路上的一个或多个其他RBridge端口的条目似乎比本地端口的优先级更高。
D3. The port is not Down or Suspended, and the adjacency table for the port changes, so there are now no entries for other RBridge ports on the link that appear to be higher priority to be the DRB than the local port.
D3。端口未关闭或挂起，并且端口的邻接表发生了更改，因此链路上的其他RBridge端口现在没有比本地端口优先级更高的条目。
D4. A TRILL LAN Hello is received that has the same MAC address (SNPA) as the receiving port and higher priority to be the DRB as described for event A0.
D4。接收到TRILL LAN Hello，该LAN Hello具有与接收端口相同的MAC地址（SNPA）和更高的优先级作为DRB，如事件A0所述。
D5. The port becomes operationally down.
D5。港口开始关闭。
Event D1 is considered to occur on RBridge boot if the port is administratively and link-layer enabled.
如果端口处于管理状态且链路层处于启用状态，则认为事件D1发生在RBridge引导时。
Event D4 causes the port to enter the Suspended state and all adjacencies for the port to be discarded (transitioned to the Down state). If the port was in some state other than Suspended, the Suspension Timer is set to the Holding Time in the Hello that causes event D4. If it was in the Suspended state, the Suspension Timer is set to the maximum of its current value and the Holding Time in the Hello that causes event D4.
事件D4导致端口进入挂起状态，并丢弃端口的所有邻接（转换为关闭状态）。如果端口处于非挂起状态，则挂起计时器将设置为导致事件D4的Hello中的保持时间。如果处于暂停状态，暂停计时器将设置为其当前值和导致事件D4的Hello中保持时间的最大值。
Events D2 and D3 constitute losing and winning the DRB election at the port, respectively.
事件D2和D3分别构成港口DRB选举的输赢。
The candidates for election are the local RBridge and all RBridges with which there is an adjacency on the port in an adjacency state other than the Down state. The winner is the RBridge with highest priority to be the DRB, as determined from the 7-bit priority field in that RBridge's Hellos received and the local port's priority to be the DRB field, with MAC (SNPA) address as a tiebreaker, Port ID as a secondary tiebreaker, and System ID as a tertiary tiebreaker. These fields are compared as unsigned integers, with the larger magnitude being considered higher priority.
选举的候选人是本地RBridge和所有RBridge，这些RBridge在港口上的邻接状态不是关闭状态。获胜者是具有最高优先级的RBridge作为DRB，根据该RBridge的HELOS中的7位优先级字段确定，本地端口的优先级作为DRB字段，MAC（SNPA）地址作为分界线，端口ID作为第二分界线，系统ID作为第三分界线。这些字段作为无符号整数进行比较，较大的大小被认为具有较高的优先级。
Resorting to the secondary and tertiary tiebreakers should only be necessary in rare circumstances when multiple ports have the same priority and MAC (SNPA) address and some of them are not yet suspended. For example, RB1, which has low priority to be the DRB on the link, could receive Hellos from two other ports on the link that have the same MAC address as each other and are higher priority to be the DRB. One of these two ports with the same MAC address will be suspended and cease sending Hellos, and the Hello from it received by RB1 will eventually time out. But, in the meantime, RB1 can use the tiebreakers to determine which port is the DRB and thus which port's Hello to believe for such purposes as setting the Designated VLAN on the link.
只有在少数情况下，当多个端口具有相同的优先级和MAC（SNPA）地址且其中一些端口尚未挂起时，才有必要求助于第二和第三级断开连接。例如，RB1作为链路上的DRB的优先级较低，它可以从链路上的两个其他端口接收Hello，这两个端口彼此具有相同的MAC地址，并且作为DRB的优先级较高。这两个具有相同MAC地址的端口中的一个将被挂起并停止发送Hello，RB1接收到的Hello最终将超时。但是，与此同时，RB1可以使用断链器来确定哪个端口是DRB，从而确定应该相信哪个端口的Hello，以便在链路上设置指定的VLAN。
Events D2 and D3 result from a change in the apparent DRB on the link. Unnecessary DRB changes should be avoided, especially on links offering native frame service, as a DRB change will generally cause a transient interruption to native frame service.
事件D2和D3由链路上的明显DRB变化引起。应避免不必要的DRB更改，尤其是在提供本机帧服务的链路上，因为DRB更改通常会导致本机帧服务暂时中断。
If a change in the DRB on the link changes the Designated VLAN on an Ethernet link, the actions specified in Section 4.2.3 are taken.
如果链路上DRB的变化改变了以太网链路上指定的VLAN，则采取第4.2.3节中规定的措施。
If an RBridge changes in either direction between being the DRB and not being the DRB at a port, this will generally change the VLANs on which that RBridge sends Hellos through that port, as specified in Section 4.4.3 of [RFC6325].
如[RFC6325]第4.4.3节所述，如果RBridge在某个端口上作为DRB和不作为DRB之间的任意方向发生变化，则通常会改变RBridge通过该端口发送HELOS的VLAN。
Unnecessary changes in the Designated VLAN on an Ethernet link should be avoided because a change in the Designated VLAN can cause a transient interruption to adjacency and thus to TRILL Data forwarding on the link. When practical, all RBridge ports on a link should be configured with the same Desired Designated VLAN so that if the winner of the DRB election changes for any reason, the Designated VLAN will remain the same.
应避免对以太网链路上的指定VLAN进行不必要的更改，因为指定VLAN中的更改可能会导致邻接的暂时中断，从而导致链路上的数据转发抖动。在实际情况下，链路上的所有RBridge端口都应配置相同的指定VLAN，这样，如果DRB选举的获胜者因任何原因发生变化，指定的VLAN将保持不变。
If an RBridge detects a change in Designated VLAN on an Ethernet link, then, for all adjacency table entries for a port to that link, the RBridge takes the following steps, in the order given.
如果RBridge检测到以太网链路上指定VLAN的变化，则对于该链路端口的所有邻接表条目，RBridge将按照给定的顺序执行以下步骤。
o The non-Designated VLAN Hello holding timer is set to the maximum of its time to expiration and the current time to expiration of the Designated VLAN Hello holding timer.
o 非指定VLAN Hello保持计时器设置为其到期时间和指定VLAN Hello保持计时器的当前到期时间的最大值。
o The Designated VLAN Hello holding timer is then set to expired (if necessary), and an event A5 occurs for the adjacency (see Section 3.3).
o 然后，将指定的VLAN Hello保持计时器设置为过期（如有必要），并且邻接发生事件A5（参见第3.3节）。
If the Designated VLAN for a link changes, this will generally change the VLANs on which Hellos are sent by an RBridge port on that link as specified in Section 4.4.3 of [RFC6325].
如果链路的指定VLAN发生变化，这通常会改变[RFC6325]第4.4.3节中规定的由该链路上的RBridge端口发送HELOS的VLAN。
The table below shows the transitions between the DRB states defined above, based on the events defined above:
下表根据上面定义的事件显示了上面定义的DRB状态之间的转换：
| Event | Down | Suspended | DRB | Not DRB |
+-------+--------+-----------+-----------+-----------+
| D1 | DRB | DRB | N/A | N/A |
| D2 | N/A | N/A | Not DRB | Not DRB |
| D3 | N/A | N/A | DRB | DRB |
| D4 | N/A | Suspended | Suspended | Suspended |
| D5 | Down | Down | Down | Down |
| Event | Down | Suspended | DRB | Not DRB |
+-------+--------+-----------+-----------+-----------+
| D1 | DRB | DRB | N/A | N/A |
| D2 | N/A | N/A | Not DRB | Not DRB |
| D3 | N/A | N/A | DRB | DRB |
| D4 | N/A | Suspended | Suspended | Suspended |
| D5 | Down | Down | Down | Down |
Table 3: Port State Table
表3：港口国表
"N/A" indicates that the event to the left is not applicable in the state at the top of the column.
“N/A”表示左侧事件在列顶部的状态下不适用。
The diagram below presents the same information as in the state table:
下图显示的信息与状态表中的信息相同：
+-------------+
| Down |<--------------+
+-+---+-------+ ^ |
| | ^ | |
D1| |D5 | | |
| +---+ |D5 |
| | |
| +--------+----+ |
| | Suspended |<---|---+
| +-+-----+-----+ | |
| D1| ^ | ^ | |
| | | |D4 | | |
| | | +---+ | |
| | | | |
| | |D4 | |
V V | | |
+---------------+-+ D5 | |
| DRB |---------->| |
+--------+--+-----+ | |
^ | | ^ | |
| D2| |D3| | |
| | +--+ | |
| | D4 | |
|D3 | +-----------------|---+
| V | |
+----+-------+-+ D5 |
| Not DRB |-------------->|
+----+---------+
| ^
|D2 |
+----+
+-------------+
| Down |<--------------+
+-+---+-------+ ^ |
| | ^ | |
D1| |D5 | | |
| +---+ |D5 |
| | |
| +--------+----+ |
| | Suspended |<---|---+
| +-+-----+-----+ | |
| D1| ^ | ^ | |
| | | |D4 | | |
| | | +---+ | |
| | | | |
| | |D4 | |
V V | | |
+---------------+-+ D5 | |
| DRB |---------->| |
+--------+--+-----+ | |
^ | | ^ | |
| D2| |D3| | |
| | +--+ | |
| | D4 | |
|D3 | +-----------------|---+
| V | |
+----+-------+-+ D5 |
| Not DRB |-------------->|
+----+---------+
| ^
|D2 |
+----+
Figure 2: Port State Diagram
图2：端口状态图
The purpose of MTU testing is to ensure that the links used in the campus topology can pass TRILL IS-IS packets, particularly LSP PDUs, at the TRILL campus MTU. The LSP PDUs generated at a TRILL switch could, as part of the flooding process, be sent over any adjacency in the campus. To assure correct operation of IS-IS, an LSP PDU must be able to reach every RBridge in the IS-IS reachable campus; this might be impossible if the PDU exceeded the MTU of an adjacency that was part of the campus topology.
MTU测试的目的是确保校园拓扑中使用的链路能够在TRILL校园MTU上传递TRILL is-is数据包，特别是LSP PDU。作为泛洪过程的一部分，在TRILL交换机上生成的LSP PDU可以发送到校园中的任何相邻位置。为确保IS-IS的正确运行，LSP PDU必须能够到达IS-IS可达校园内的每个RBridge；如果PDU超过作为校园拓扑一部分的邻接的MTU，这可能是不可能的。
An RBridge, RB1, determines the desired campus link MTU by calculating the minimum of its originatingL1LSPBufferSize and the originatingL1LSPBufferSize of other RBridges in the campus, as advertised in the link-state database, but not less than 1,470 bytes. Although originatingL1LSPBufferSize in Layer 3 [IS-IS] is limited to the range 512 to 1,492 bytes inclusive, in TRILL it is limited to the range 1,470 to 65,535 bytes inclusive. (See Section 5 of [RFC7180].)
RBridge RB1通过计算其起始L1LSPBufferSize和校园中其他RBridge的起始L1LSPBufferSize的最小值（如链路状态数据库中公布的）来确定所需的校园链路MTU，但不小于1470字节。虽然第3层[IS-IS]中的原始L1LSPBUFFERSIZE限制在512到1492字节（含）的范围内，但在颤音中，它限制在1470到65535字节（含）的范围内。（见[RFC7180]第5节）
Although MTU testing is optional, it is mandatory for an RBridge to respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] [RFC7176]. The use of multicast or unicast for MTU-probe and MTU-ack is an implementation choice. However, the burden on the link is generally minimized by the following: (1) multicasting MTU-probes when a response from all other RBridges on the link is desired, such as when initializing or reconfirming MTU, (2) unicasting MTU-probes when a response from a single RBridge is desired, such as one that has just been detected on the link, and (3) unicasting all MTU-ack packets.
尽管MTU测试是可选的，但RBridge必须使用MTU ack PDU[RFC6325][RFC7176]响应MTU探针PDU。对MTU探测和MTU确认使用多播或单播是一种实现选择。然而，链路上的负担通常通过以下方式最小化：（1）当需要来自链路上的所有其他RBridge的响应时，例如当初始化或重新确认MTU时，多播MTU探测；（2）当需要来自单个RBridge的响应时，例如刚刚在链路上检测到的响应时，单播MTU探测；（3）单播所有MTU ack数据包。
RB1 can test the MTU size to RB2 as described in Section 4.3.2 of [RFC6325]. For this purpose, MTU testing is only done in the Designated VLAN. An adjacency that fails the MTU test at the campus MTU will not enter the Report state, or, if the adjacency is in that state, it leaves that state. Thus, an adjacency failing the MTU test at the campus minimum MTU will not be reported by the RBridge performing the test. Since inclusion in least-cost route computation requires the adjacency to be reported by both ends, as long as the RBridge at either end of the adjacency notices the MTU failure, it will not be so used.
如[RFC6325]第4.3.2节所述，RB1可将MTU尺寸测试为RB2。为此，MTU测试仅在指定的VLAN中进行。未通过校园MTU MTU测试的邻接将不会进入报告状态，或者，如果邻接处于该状态，它将离开该状态。因此，执行测试的RBridge不会报告在校园最低MTU未通过MTU测试的邻接情况。由于包含在最小成本路由计算中要求两端报告相邻，只要相邻两端的RBridge注意到MTU故障，就不会使用它。
If RB1 tests MTU size, it reports the largest size for which the MTU test succeeds or a flag indicating that it fails at the campus MTU. This report always appears with the neighbor in RB1's TRILL Neighbor TLV. RB1 MAY also report this with the adjacency in an Extended Reachability TLV in RB1's LSP. RB1 MAY choose to test MTU sizes greater than the desired campus MTU as well as the desired campus MTU.
如果RB1测试MTU大小，它会报告MTU测试成功的最大大小，或者报告一个标志，表明它在校园MTU失败。此报告始终与RB1的颤音邻居TLV中的邻居一起显示。RB1还可以报告RB1的LSP中扩展可达性TLV中的邻接情况。RB1可以选择测试大于所需校园MTU以及所需校园MTU的MTU大小。
Most types of TRILL IS-IS packets, such as LSPs, can make use of the campus MTU. The exceptions are TRILL Hellos, which must be kept small for loop safety, and the MTU PDUs, whose size must be adjusted appropriately for the tests being performed.
大多数类型的TRILL IS-IS数据包（如LSP）都可以使用校园MTU。例外情况是TRILL Hellos（为了环路安全必须保持较小）和MTU PDU（其大小必须针对正在执行的测试进行适当调整）。
When the adjacency between RBridges reaches the 2-Way state, TRILL Hellos will already have been exchanged. If an RBridge supports BFD [RFC7175], it will have learned whether the other RBridge has BFD enabled by whether or not a BFD-Enabled TLV [RFC6213] was included in its Hellos. In addition, TRILL Hellos include a nickname of the sending RBridge [RFC7176] so that information will be available to the receiving RBridge.
当RBridges之间的邻接达到双向状态时，TRILL Hello将已经交换。如果一个RBridge支持BFD[RFC7175]，它将通过其hello中是否包含启用BFD的TLV[RFC6213]来了解另一个RBridge是否启用了BFD。此外，TRILL Hello还包括发送RBridge的昵称[RFC7176]，以便接收RBridge可以获得信息。
The BFD-Enabled TLVs in TRILL Hellos will look like the following:
TRILL Hellos中启用BFD的TLV如下所示：
+-+-+-+-+-+-+-+-+
| Type=148 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length=3*n | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | MT ID=0 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLPID=0xC0 | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-...
| possible additional (3*(n-1) bytes)
| topology/NLPID pairs
+-+-+-+-+-+-+-...
+-+-+-+-+-+-+-+-+
| Type=148 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length=3*n | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | MT ID=0 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLPID=0xC0 | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-...
| possible additional (3*(n-1) bytes)
| topology/NLPID pairs
+-+-+-+-+-+-+-...
Figure 3: BFD-Enabled TLV Example/Format
图3：启用BFD的TLV示例/格式
Type = 148 for BFD Enabled [RFC6213].
类型=148，用于启用BFD[RFC6213]。
Length will be 3 times the number of topology and protocol pairs in the TLV.
长度将是TLV中拓扑和协议对数的3倍。
MT ID is a topology ID [RFC5120] that will be zero unless multi-topology is being supported [MT].
MT ID是拓扑ID[RFC5120]，除非支持多拓扑[MT]，否则该拓扑ID将为零。
NLPID is a Network Layer Protocol ID [RFC6328] and will be 0xC0 for TRILL, but additional topology and protocol pairs could conceivably be listed.
NLPID是一个网络层协议ID[RFC6328]，对于TRILL，它将是0xC0，但是可以想象，可以列出额外的拓扑和协议对。
An RBridge port initiates a one-hop BFD session with another RBridge if the following conditions are met: (1) it has BFD enabled, (2) it has an adjacency to another RBridge in the 2-Way or Report state, and (3) the Hellos it receives indicate that the other RBridge also has BFD enabled. Either (a) BFD was enabled on both RBridge ports when the adjacency changed to the 2-Way or Report state, (b) the adjacency was already in the 2-Way or Report state and BFD was enabled on one RBridge port when BFD had been enabled on the other, or (c) BFD was simultaneously enabled on both RBridge ports.
如果满足以下条件，RBridge端口将启动与另一个RBridge的单跳BFD会话：（1）它已启用BFD；（2）它在双向或报告状态下与另一个RBridge相邻；（3）它收到的Hello指示另一个RBridge也已启用BFD。（a）当邻接更改为双向或报告状态时，两个RBridge端口上都启用了BFD；（b）邻接已处于双向或报告状态，并且当一个RBridge端口上启用了BFD时，另一个RBridge端口上也启用了BFD；或者（c）两个RBridge端口上同时启用了BFD。
In such a BFD session, BFD is encapsulated as specified in [RFC7175]. The egress nickname to be used will have been learned from received Hellos. On a point-to-point link, the Any-RBridge nickname [RFC7180] can also be used as egress, since support of that nickname is required by support of RBridge Channel [RFC7178] and support of RBridge Channel is required for support of BFD over TRILL.
在这种BFD会话中，BFD按照[RFC7175]中的规定进行封装。要使用的出口昵称将从收到的问候中学习。在点到点链路上，任意RBridge昵称[RFC7180]也可用作出口，因为支持RBridge信道[RFC7178]需要支持该昵称，而支持TRILL上的BFD则需要支持RBridge信道。
The rare case of transient nickname conflict (due to the network operator configuring a conflict, new connectivity to a previously isolated RBridge, or the like) can cause transient failure of an ongoing BFD session. This can be avoided in the one-hop point-to-point case by using the Any-RBridge egress nickname. In cases where Any-RBridge cannot be used as the egress nickname and a transient nickname conflict is detected for the intended destination of a BFD session, initiation of the session SHOULD be delayed until the conflict is resolved.
暂时性昵称冲突的罕见情况（由于网络运营商配置冲突、到先前隔离的RBridge的新连接等）可导致正在进行的BFD会话暂时失败。在单跳点对点的情况下，可以通过使用Any RBridge出口昵称来避免这种情况。如果任何RBridge不能用作出口昵称，并且检测到BFD会话的预期目的地存在暂时性昵称冲突，则应延迟会话的启动，直到冲突得到解决。
If a one-hop BFD session is initiated when the adjacency is in the 2-Way state, the adjacency MUST NOT advance to the Report state until BFD and any other enabled connectivity tests (including MTU, if enabled) have succeeded, as specified in Section 3.
如果一跳BFD会话在邻接处于双向状态时启动，则在BFD和任何其他启用的连接测试（包括MTU，如果启用）成功之前，邻接不得进入报告状态，如第3节所述。
If a one-hop BFD session is established when the adjacency is in the Report state, due to enablement at the RBridges, then, to minimize unnecessary topology changes, the adjacency MUST remain in the Report state unless and until the BFD session (or some other enabled connectivity test) fails.
如果由于RBridges上的启用，在邻接处于报告状态时建立了单跳BFD会话，则为了最大限度地减少不必要的拓扑更改，除非BFD会话（或某些其他启用的连接测试）失败，否则邻接必须保持在报告状态。
This section only applies to broadcast links, as there is no DRB and there cannot be a pseudonode [IS-IS] for a link configured as point-to-point. The Designated RBridge (DRB), determined as described above, controls whether a pseudonode will be used on a link.
本节仅适用于广播链路，因为对于配置为点到点的链路，不存在DRB，也不存在伪节点[is-is]。如上所述确定的指定RBridge（DRB）控制是否将在链路上使用伪节点。
If the DRB sets the bypass pseudonode bit in its TRILL LAN Hellos, the RBridges on the link (including the DRB) just directly report all their adjacencies on the LAN that are in the Report state. If the DRB does not set the bypass pseudonode bit in its TRILL Hellos, then (1) the DRB reports in its LSP its adjacency to the pseudonode, (2) the DRB sends LSPs on behalf of the pseudonode in which it reports adjacency to all other RBridges on the link where it sees that adjacency in the Report state, and (3) all other RBridges on the link report their adjacency to the pseudonode if they see their adjacency to the DRB as being in the Report state and do not report any other adjacencies on the link. Setting the bypass pseudonode bit has no effect on how LSPs are flooded on a link. It only affects what LSPs are generated.
如果DRB在其TRILL LAN Hello中设置旁路伪节点位，则链路上的RBridge（包括DRB）直接报告其在LAN上处于报告状态的所有邻接。如果DRB未在其TRILL Hello中设置旁路伪节点位，则（1）DRB在其LSP中报告其与伪节点的邻接，（2）DRB代表伪节点发送LSP，在该伪节点中，DRB向其在报告状态中看到该邻接的链路上的所有其他RBridge报告邻接，以及（3）如果链接上的所有其他RBridge看到其与DRB的邻接处于报告状态，并且不报告链接上的任何其他邻接，则会将其邻接报告给伪节点。设置旁路伪节点位对链路上LSP的泛洪方式没有影响。它只影响生成的LSP。
It is anticipated that many links between RBridges will actually be point-to-point even in cases where the link technology supports operation as a multi-access broadcast link, in which case using a pseudonode merely adds to the complexity. For example, if RB1 and RB2 are the only RBridges on the link, and RB1 is the DRB, then if RB1 creates a pseudonode -- for example, RB1.25 -- that is used, there are then 3 LSPs: RB1.25, RB1, and RB2, where RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they are connected to RB1.25. However, if DRB RB1 sets the bypass pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and RB2, each reporting connectivity to each other.
可以预期，即使在链路技术支持作为多址广播链路的操作的情况下，rbridge之间的许多链路实际上也将是点对点的，在这种情况下，使用伪节点仅仅增加了复杂性。例如，如果RB1和RB2是链路上唯一的RBridge，而RB1是DRB，那么如果RB1创建了一个使用的伪节点（例如RB1.25），那么就有3个LSP:RB1.25、RB1和RB2，其中RB1.25报告到RB1和RB2的连接，RB1和RB2都只是说它们连接到了RB1.25。但是，如果DRB RB1在其hello中设置了旁路伪节点位，则只有两个LSP：RB1和RB2，每个LSP都报告彼此的连接。
A DRB SHOULD set the bypass pseudonode bit in its Hellos if it has not seen at least two simultaneous adjacencies in the Report state since it last rebooted or was reset by network management.
如果DRB自上次重新启动或由网络管理重置后，在报告状态中未发现至少两个同时相邻的位置，则应在其hello中设置旁路伪节点位。
This section provides further details on the receipt, transmission, and content of TRILL Hellos. Unless otherwise stated, it applies to both LAN and point-to-point Hellos.
本节提供有关TRILL Hellos的接收、传输和内容的更多详细信息。除非另有说明，否则它适用于LAN和点对点Hello。
TRILL Hellos, like all TRILL IS-IS packets, are primarily distinguished from Layer 3 IS-IS packets on Ethernet by being sent to the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41). TRILL IS-IS packets on Ethernet also have the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded.
TRILL Hello与所有TRILL IS-IS数据包一样，通过发送到所有IS RBridges多播地址（01-80-C2-00-00-41），主要区别于以太网上的第3层IS-IS数据包。以太网上的TRILL IS-IS数据包也具有L2-IS-IS以太类型（0x22F4）并进行以太类型编码。
Although future extensions to TRILL may include the use of Level 2 IS-IS, [RFC6325] specifies TRILL using a single Level 1 Area using the fixed Area Address zero (see Section 4.2 of [RFC7176]).
尽管TRILL的未来扩展可能包括使用2级IS-IS，[RFC6325]使用固定区域地址零（见[RFC7176]第4.2节）指定使用单个1级区域的TRILL。
IS-IS Layer 3 routers are frequently connected to other Layer 3 routers that are part of a different routing domain. In that case, the externalDomain flag (see [IS-IS]) is normally set for the port through which such a connection is made. The setting of this flag to "true" causes no IS-IS PDUs to be sent out of the port and any IS-IS PDUs received to be discarded, including Hellos. RBridges operate in a different environment where all neighbor RBridges merge into a single campus. For loop safety, RBridges do not implement the externalDomain flag or implement it with the fixed value "false". They send and can receive TRILL Hellos on every port that is not disabled.
IS-IS第3层路由器经常连接到属于不同路由域的其他第3层路由器。在这种情况下，externalDomain标志（请参见[IS-IS]）通常是为进行这种连接的端口设置的。将此标志设置为“true”会导致没有IS-IS PDU从端口发送出去，并且会丢弃接收到的任何IS-IS PDU，包括Hellos。RBridges在不同的环境中运行，所有相邻RBridges合并到一个校园中。为了循环安全，RBridges不实现externalDomain标志或使用固定值“false”实现它。它们在每个未禁用的端口上发送和接收颤音Hello。
The table below lists mandatory (M) and optional (O) content TLVs for TRILL Hellos that are particularly relevant to this document, distinguishing between TRILL LAN Hellos and TRILL P2P Hellos. A "-" indicates that an occurrence would be ignored. There are additional TLVs and sub-TLVs that can occur in TRILL Hellos [RFC7176].
下表列出了与本文档特别相关的TRILL Hello的强制（M）和可选（O）内容TLV，区分了TRILL LAN Hello和TRILL P2P Hello。“-”表示将忽略某个事件。在TRILL Hello[RFC7176]中还可以出现其他TLV和子TLV。
LAN P2P Number Content Item
--- --- ------ ----------------------------------------------
LAN P2P Number Content Item
--- --- ------ ----------------------------------------------
M M 1 Area Addresses TLV with Area Address zero only M M 1 MT Port Capabilities TLV containing a VLAN-FLAGs sub-TLV O O 0-n Other MT Port Capability TLVs M - 0-n TRILL Neighbor TLV (see Section 8.2.1) - M 1 Three-Way Handshake TLV O O 0-n Protocols Supported TLV -- MUST list the TRILL NLPID (0xC0) [RFC6328] O O 0-1 BFD-Enabled TLV O O 0-1 Authentication TLV - - 0-n Padding TLV -- SHOULD NOT be included
M M 1区域地址TLV，区域地址为零仅M M 1 MT端口功能TLV包含VLAN标志子TLV O 0-n其他MT端口功能TLV M-0-n颤音邻居TLV（参见第8.2.1节）-M 1三向握手TLV O 0-n协议支持TLV-必须列出颤音NLPID（0xC0）[RFC6328]O 0-1启用BFD的TLV O 0-1身份验证TLV--0-n填充TLV--不应包括在内
Table 4: TRILL Hello Contents
表4：颤音Hello内容
A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS Hello. As with all IS-IS PDUs, TLVs that are unsupported/unknown in TRILL Hellos are ignored.
颤音Hello还可以包含第3层IS-IS Hello中允许的任何TLV。与所有IS-IS PDU一样，TRILL Hello中不受支持/未知的TLV将被忽略。
TRILL Hellos are sent with the same timing as Layer 3 IS-IS Hellos [IS-IS]; however, no Hellos are sent if a port is in the Suspended or Down state or if the port is disabled.
颤音hello的发送时间与第3层IS-IS hello[IS-IS]的发送时间相同；但是，如果某个端口处于挂起或关闭状态，或者该端口被禁用，则不会发送Hello。
TRILL Hello PDUs SHOULD NOT be padded and MUST NOT be sent if they exceed 1,470 bytes; however, a received TRILL Hello longer than 1,470 bytes is processed normally.
TRILL Hello PDU不应填充，如果超过1470字节，则不得发送；但是，通常会处理超过1470字节的接收到的颤音Hello。
TRILL Hello PDU headers MUST conform to the following:
TRILL Hello PDU标头必须符合以下要求：
o Maximum Area Addresses equal to 1.
o 最大区域地址等于1。
o Circuit Type equal to 1.
o 电路类型等于1。
See Section 8.1 for mandatory Hello TLV contents and some optional Hello TLV contents.
有关强制性Hello TLV内容和一些可选Hello TLV内容，请参见第8.1节。
A TRILL Neighbor TLV SHOULD NOT be included in TRILL point-to-point Hellos, as it MUST be ignored in that context and wastes space.
颤音邻域TLV不应包含在颤音点对点Hello中，因为在该上下文中必须忽略它并浪费空间。
TRILL Neighbor TLVs sent in a LAN Hello on an Ethernet link MUST show the neighbor information, as sensed by the transmitting RBridge, for the VLAN on which the Hello is sent. Since implementations conformant to this document maintain such information on a per-VLAN basis only for the Designated VLAN, such implementations only send the TRILL Neighbor TLV in TRILL LAN Hellos in the Designated VLAN.
在以太网链路的LAN Hello中发送的TRILL Neighbor TLV必须显示发送Hello的VLAN的邻居信息，如传输RBridge所感测到的。由于符合本文档要求的实现仅为指定的VLAN在每个VLAN的基础上维护此类信息，因此此类实现仅在指定VLAN的TRILL LAN Hello中发送TRILL邻居TLV。
It is RECOMMENDED that, if there is sufficient room, a TRILL Neighbor TLV or TLVs, as described in Section 4.4.2.1 of [RFC6325], covering the entire range of MAC addresses and listing all adjacencies with a non-zero Designated VLAN Hello Holding Time, or an empty list of neighbors if there are no such adjacencies, be in TRILL Hellos sent on the Designated VLAN. If this is not possible, then TRILL Neighbor TLVs covering sub-ranges of MAC addresses should be sent so that the entire range is covered reasonably promptly. Delays in sending TRILL Neighbor TLVs will delay the advancement of adjacencies to the Report state and the discovery of some link failures. Rapid (for example, sub-second) detection of link or node failures is best addressed with a protocol designed for that purpose, such as BFD (see Section 6).
如[RFC6325]第4.4.2.1节所述，如果有足够的空间，建议使用TRILL邻居TLV或TLV，覆盖整个MAC地址范围，并列出指定VLAN Hello保持时间为非零的所有邻接，如果没有此类邻接，则列出空邻接列表，在指定的VLAN上发送颤音问候。如果这是不可能的，那么应该发送覆盖MAC地址子范围的TRILL邻居TLV，以便合理地及时覆盖整个范围。发送TRILL Neighbor TLV的延迟将延迟报告状态邻接的进展和某些链路故障的发现。链路或节点故障的快速（例如，亚秒）检测最好使用为此目的设计的协议，如BFD（见第6节）。
To ensure that any RBridge RB2 can definitively determine whether RB1 can hear RB2, RB1's neighbor list MUST eventually cover every possible range of IDs, that is, within a period that depends on RB1's policy and not necessarily within any specific period such as its Holding Time. In other words, if X1 is the smallest ID reported in one of RB1's neighbor lists, and the "smallest" flag is not set, then X1 MUST appear in a different neighbor list as well, as the largest ID reported in that fragment. Or lists may overlap, as long as there is no gap, such that some range, say, between Xi and Xj, would never appear in any list.
为了确保任何RBridge RB2都能确定RB1是否能听到RB2，RB1的邻居列表最终必须覆盖所有可能的ID范围，即，在一段时间内（取决于RB1的策略），而不一定是在任何特定的时间内（如等待时间）。换句话说，如果X1是RB1的一个邻居列表中报告的最小ID，并且没有设置“最小”标志，那么X1也必须出现在不同的邻居列表中，以及该片段中报告的最大ID。或列表可能重叠，只要没有间隙，这样的范围，例如，席和XJ之间，将永远不会出现在任何列表中。
Assuming that a packet is labeled as TRILL IS-IS -- for example, on Ethernet it has the L2-IS-IS Ethertype and the All-IS-IS-RBridges destination multicast address or is so marked by the appropriate code point on other link types such as PPP [RFC6361] or a pseudowire [RFC7173] -- it will be examined to see if it appears to be an IS-IS PDU. If so, and it appears to be a TRILL Hello PDU, the following tests are performed:
假设一个数据包被标记为TRILL is-is——例如，在以太网上，它具有L2-is-is以太类型和All is RBridges目标多播地址，或者由其他链路类型（如PPP[RFC6361]或伪线[RFC7173]）上的适当代码点标记——将检查它是否是is-is PDU。如果是，并且它看起来是颤音Hello PDU，则执行以下测试：
o The type of Hello PDU (LAN or P2P) is compared with the port configuration. If a LAN Hello is received on a port configured to be point-to-point or a P2P Hello is received on a port not configured to be point-to-point, it is discarded.
o 将Hello PDU（LAN或P2P）的类型与端口配置进行比较。如果在配置为点对点的端口上接收到LAN Hello，或者在未配置为点对点的端口上接收到P2P Hello，则会丢弃该Hello。
o If the Circuit Type field is not 1, the PDU is discarded.
o 如果电路类型字段不是1，则PDU将被丢弃。
o If the PDU does not contain an Area Address TLV or it contains an Area Address TLV that is not the single Area Address zero, it is discarded.
o 如果PDU不包含区域地址TLV，或者它包含的区域地址TLV不是单个区域地址零，则会将其丢弃。
o If the Hello includes a Protocols Supported TLV that does not list the TRILL NLPID (0xC0), it is discarded. It is acceptable if there is no Protocols Supported TLV present.
o 如果Hello包含不列出TRILL NLPID（0xC0）的受协议支持的TLV，则会将其丢弃。如果不存在受TLV支持的协议，则可以接受。
o If the Hello does not contain an MT Port Capabilities TLV containing a VLAN-FLAGS sub-TLV [RFC7176], it is discarded.
o 如果Hello不包含包含VLAN-FLAGS子TLV[RFC7176]的MT端口功能TLV，则丢弃该TLV。
o If the maximumAreaAddresses field of the PDU is not 1, it is discarded.
o 如果PDU的maximumAreaAddresses字段不是1，则该字段将被丢弃。
o If IS-IS authentication is in use on the link and either the PDU has no Authentication TLV or validation of the PDU's Authentication TLV fails, it is discarded.
o 如果链路上正在使用IS-IS身份验证，并且PDU没有身份验证TLV，或者PDU的身份验证TLV验证失败，则会将其丢弃。
If none of the rules in the list above cause the packet to be discarded and the packet is parseable, it is assumed to be a well-formed TRILL Hello received on the link. It is treated as an event A0, A1, A2, or A3, based on the criteria listed in Section 3.3.
如果上面列表中的任何规则都不会导致数据包被丢弃，并且数据包是可解析的，则假定它是在链路上接收到的格式良好的TRILL Hello。根据第3.3节列出的标准，将其视为事件A0、A1、A2或A3。
It is possible for an RBridge RB1 to have multiple ports on the same broadcast (LAN) link that are not in the Suspended state. It is important for RB1 to recognize which of its ports are on the same link. RB1 can detect this condition based on receiving TRILL Hello messages with the same LAN ID on multiple ports.
RBridge RB1可能在同一广播（LAN）链路上有多个未处于挂起状态的端口。RB1必须识别其哪些端口位于同一链路上。RB1可以通过在多个端口上接收具有相同LAN ID的TRILL Hello消息来检测这种情况。
The DRB election is port-based (see Section 4), and only the Hellos from the elected port can perform certain functions such as dictating the Designated VLAN or whether a pseudonode will be used; however, the election also designates the RBridge with that port as the DRB for the link. An RBridge may choose to load split some tasks among its ports on the link if it has more than one. Section 4.4.4 of [RFC6325] describes when it is safe to do so.
DRB选择是基于端口的（参见第4节），并且只有来自所选端口的HELLO可以执行某些功能，例如指令指定的VLAN或是否将使用伪节点；然而，选举还指定带有该端口的RBridge作为链路的DRB。如果RBridge有多个端口，则RBridge可以选择在链路上的端口之间加载拆分任务。[RFC6325]的第4.4.4节描述了何时这样做是安全的。
This document serves as a reference for 'Fail' (Failed MTU test), value 0, in the "TRILL Neighbor TLV NEIGHBOR RECORD Flags" registry. IANA has updated that reference to point to this RFC.
本文档作为“TRILL Neighbor TLV Neighbor RECORD Flags”注册表中“Fail”（MTU测试失败）值0的参考。IANA已更新该参考，以指向该RFC。
This memo provides improved documentation of some aspects of the TRILL base protocol standard, particularly five aspects of the TRILL adjacency establishment and Hello protocol as listed in Section 1. It does not change the security considerations of the TRILL base protocol as detailed in Section 6 of [RFC6325].
本备忘录提供了TRILL基本协议标准某些方面的改进文档，特别是第1节中列出的TRILL邻接建立和Hello协议的五个方面。它不会改变[RFC6325]第6节详述的TRILL基本协议的安全注意事项。
See [RFC7175] for security considerations for BFD, whose use in connection with TRILL adjacency is discussed in this document, particularly Section 6.
有关BFD的安全注意事项，请参见[RFC7175]，本文件特别是第6节讨论了BFD在颤音邻接中的使用。
This document has the following changes from [RFC6327]. It obsoletes [RFC6327].
本文件对[RFC6327]作了以下更改。它淘汰了[RFC6327]。
1. This document extends the TRILL Hello size limit, MTU testing, and state machine to point-to-point links.
1. 本文档扩展了TRILL Hello大小限制、MTU测试和状态机到点的链接。
2. This document incorporates the updates to [RFC6327] from [RFC7180].
2. 本文档包含[RFC7180]对[RFC6327]的更新。
3. The bulk of [RFC6327] was written from the point of view that links between TRILL switches would only be Ethernet. In fact, they could be any technology, such as PPP [RFC6361], pseudowire [RFC7173], or IP [TrillIP]. This replacement document generalizes [RFC6327] to cover such link types.
3. [RFC6327]的大部分内容是从TRILL交换机之间的链路只能是以太网的角度编写的。事实上，它们可以是任何技术，如PPP[RFC6361]、伪线[RFC7173]或IP[TrillIP]。本替换文件概括了[RFC6327]以涵盖此类链接类型。
4. This document includes a specification of one-hop BFD session establishment in connection with adjacency.
4. 本文件包括与邻接相关的单跳BFD会话建立规范。
5. Numerous editorial changes were incorporated.
5. 合并了许多编辑上的修改。
Section 2 of this document replaces Section 4.4.1 of [RFC6325]. Section 8 of this document replaces Section 4.4.2 of [RFC6325], except for Section 4.4.2.1. The changes in [RFC6325] made by this document include
本文件第2节取代[RFC6325]第4.4.1节。本文件第8节取代[RFC6325]第4.4.2节，但第4.4.2.1节除外。本文件对[RFC6325]所做的更改包括
- Prohibiting the sending of TRILL Hellos out of a port while it is in the Suspended state, and the specification of the Suspended state. ([RFC6325] specifies that Hellos be sent with the same timing as [IS-IS].)
- 禁止在处于挂起状态时从端口发送颤音Hello，以及挂起状态的规范。（[RFC6325]指定以与[IS-IS]相同的时间发送Hello。）
- Permitting the inclusion of the Three-Way-Handshake TLV, BFD-Enabled TLV, and other TLVs in TRILL Hellos when these were omitted in TRILL Hello contents lists in Section 4.4.2 of [RFC6325].
- 允许在[RFC6325]第4.4.2节的TRILL Hello内容列表中省略三向握手TLV、启用BFD的TLV和TRILL Hello中的其他TLV。
- Extending the TRILL Hello protocol to support point-to-point and non-Ethernet links.
- 扩展TRILL Hello协议以支持点到点和非以太网链路。
Normative References
规范性引用文件
[IS-IS] ISO/IEC 10589:2002, Second Edition, "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)", 2002.
[IS-IS]ISO/IEC 10589:2002，第二版，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，2002年。
[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月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，2008年2月。
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, April 2011.
[RFC6213]Hopps，C.和L.Ginsberg，“IS-IS BFD启用的TLV”，RFC 6213，2011年4月。
[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月。
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 2011.
[RFC6328]Eastlake 3rd，D.，“网络层协议标识符的IANA考虑”，BCP 164，RFC 63282011年7月。
[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, May 2014.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，2014年5月。
[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月。
[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, May 2014.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge信道支持”，RFC 7178，2014年5月。
[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月。
Informative References
资料性引用
[802.1AX] "IEEE Standard for Local and metropolitan area networks-- Link Aggregation", 802.1AX-2008, January 2008.
[802.1AX]“局域网和城域网的IEEE标准——链路聚合”，802.1AX-2008，2008年1月。
[802.1Q] "IEEE Standard for Local and metropolitan area networks-- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", 802.1Q-2011, August 2011.
[802.1Q]“局域网和城域网IEEE标准——媒体访问控制（MAC）网桥和虚拟桥接局域网”，802.1Q-2011，2011年8月。
[ESADI] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "TRILL: ESADI (End Station Address Distribution Information) Protocol", Work in Progress, April 2014.
[ESADI]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“TRILL:ESADI（端站地址分配信息）协议”，正在进行的工作，2014年4月。
[FCoE] Excerpt of discussion of "FCoE Max Size" generated from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU", <www.t11.org>.
[FCoE]摘自2009年4月27日T11/09-251v1“FCoE框架或FCoE PDU”产生的“FCoE最大尺寸”讨论，<www.T11.org>。
[MT] Eastlake, D., Zhang, M., Banerjee, A., and V. Manral, "TRILL: Multi-Topology", Work in Progress, September 2013.
[MT]Eastlake，D.，Zhang，M.，Banerjee，A.，和V.Manral，“颤音：多拓扑”，正在进行的工作，2013年9月。
[RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, February 2004.
[RFC3719]Parker，J.，Ed.“使用中间系统到中间系统（IS-IS）的互操作网络的建议”，RFC 3719，2004年2月。
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011.
[RFC6327]东湖第三大道、佩尔曼大道、加瓦尼大道、杜特大道和V.曼拉尔大道，“路由桥（RBridges）：邻近”，RFC 6327，2011年7月。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 63612011年8月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 64392011年11月。
[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, May 2014.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链路的透明互连（TRILL）：细粒度标记”，RFC 7172，2014年5月。
[RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, "Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires", RFC 7173, May 2014.
[RFC7173]Yong，L.，Eastlake 3rd，D.，Aldrin，S.，和J.Hudson，“使用伪线的大量链路（TRILL）传输的透明互连”，RFC 7173，2014年5月。
[TrillIP] Wasserman, M., Eastlake, D., and D. Zhang, "Transparent Interconnection of Lots of Links (TRILL) over IP", Work in Progress, March 2014.
[TrillIP]Wasserman，M.，Eastlake，D.，和D.Zhang，“IP上大量链路的透明互连（TRILL）”，正在进行的工作，2014年3月。
Acknowledgements
致谢
The suggestions and comments of the following are gratefully acknowledged:
感谢以下人员的建议和意见：
Stewart Bryant, Elwyn Davies, Adrian Farrel, Brian Haberman, Jon Hudson, Arnel Lim, and Gayle Noble.
Stewart Bryant、Elwyn Davies、Adrian Farrel、Brian Haberman、Jon Hudson、Arnel Lim和Gayle Noble。
The authors of [RFC6327] included Dinesh Dutt. The acknowledgements section of [RFC6327] includes the following, listed in alphabetic order: Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay Gupta, David Harrington, Pete McCann, Erik Nordmark, and Mike Shand.
[RFC6327]的作者包括Dinesh Dutt。[RFC6327]的确认部分包括以下内容，按字母顺序列出：贾里·阿尔科、阿扬·班纳吉、莱斯·金斯伯格、苏杰·古普塔、大卫·哈林顿、皮特·麦肯、埃里克·诺德马克和迈克·尚德。
Authors' Addresses
作者地址
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald E.Eastlake第三华为技术有限公司美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054 USA
Radia Perlman英特尔实验室使命学院大道2200号。美国加利福尼亚州圣克拉拉95054
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450美国加利福尼亚州圣克拉拉大美洲公园路95054
EMail: anoop@alumni.duke.edu
EMail: anoop@alumni.duke.edu
Howard Yang Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: howardy@cisco.com
EMail: howardy@cisco.com
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
Vishwas Manral Ionios公司，美国加利福尼亚州圣何塞摩尔帕克大道4100号，邮编95117
EMail: vishwas@ionosnetworks.com
EMail: vishwas@ionosnetworks.com