Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 6327 Huawei
Updates: 6325 R. Perlman
Category: Standards Track Intel Labs
ISSN: 2070-1721 A. Ghanwani
Brocade
D. Dutt
Cisco Systems
V. Manral
Hewlett Packard Co.
July 2011
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 6327 Huawei
Updates: 6325 R. Perlman
Category: Standards Track Intel Labs
ISSN: 2070-1721 A. Ghanwani
Brocade
D. Dutt
Cisco Systems
V. Manral
Hewlett Packard Co.
July 2011
Routing Bridges (RBridges): Adjacency
路由桥（RBridges）：邻接
Abstract
摘要
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).
IETF TRILL（大量链路的透明互连）协议提供无需配置的最佳成对数据转发、即使在临时循环期间也能安全转发，并支持单播和多播流量的多路径传输。TRILL通过使用IS-IS（中间系统到中间系统）链路状态路由和使用包含跃点计数的报头封装流量来实现这一点。实现TRILL的设备称为路由桥（RBridges）。
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL.
TRILL支持可以连接多个终端站和RBridge的多址LAN（局域网）链路。本文档描述了在此类链路上使用的TRILL LAN Hello协议的四个方面，特别是邻接、指定RBridge选择、MTU（最大传输单元）和伪节点过程，以及状态机。在TRILL中配置为点到点的链接上使用的is-is点到点Hellos没有变化。
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/rfc6327.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6327.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 .....................................4
1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................5
2.1. Incrementally Replacing 802.1Q-2005 Bridges ................5
2.2. Handling Native Frames .....................................6
2.3. Zero or Minimal Configuration ..............................7
2.4. MTU Robustness .............................................7
2.5. Purposes of the TRILL Hello Protocol .......................8
3. Adjacency State Machinery .......................................9
3.1. TRILL LAN Hellos, MTU Test, and VLANs ......................9
3.2. Adjacency Table Entries and States ........................10
3.3. Adjacency and Hello Events ................................11
3.4. Adjacency State Diagram and Table .........................13
3.5. Multiple Parallel Links ...................................14
3.6. Insufficient Space in Adjacency Table .....................15
4. RBridge LAN Ports and DRB State ................................15
4.1. Port Table Entries and DRB Election State .................16
4.2. DRB Election Events .......................................16
4.2.1. DRB Election Details ...............................17
4.2.2. Change in DRB ......................................18
4.2.3. Change in Designated VLAN ..........................18
4.3. State Table and Diagram ...................................18
5. MTU Matching ...................................................20
6. Pseudonodes ....................................................21
7. TRILL Hello Reception and Transmission .........................21
7.1. Transmitting TRILL Hellos .................................22
7.2. Receiving TRILL Hellos ....................................23
8. Multiple Ports on the Same Link ................................24
9. Security Considerations ........................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................25
11. Acknowledgements ..............................................25
1. Introduction ....................................................4
1.1. Content and Precedence .....................................4
1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................5
2.1. Incrementally Replacing 802.1Q-2005 Bridges ................5
2.2. Handling Native Frames .....................................6
2.3. Zero or Minimal Configuration ..............................7
2.4. MTU Robustness .............................................7
2.5. Purposes of the TRILL Hello Protocol .......................8
3. Adjacency State Machinery .......................................9
3.1. TRILL LAN Hellos, MTU Test, and VLANs ......................9
3.2. Adjacency Table Entries and States ........................10
3.3. Adjacency and Hello Events ................................11
3.4. Adjacency State Diagram and Table .........................13
3.5. Multiple Parallel Links ...................................14
3.6. Insufficient Space in Adjacency Table .....................15
4. RBridge LAN Ports and DRB State ................................15
4.1. Port Table Entries and DRB Election State .................16
4.2. DRB Election Events .......................................16
4.2.1. DRB Election Details ...............................17
4.2.2. Change in DRB ......................................18
4.2.3. Change in Designated VLAN ..........................18
4.3. State Table and Diagram ...................................18
5. MTU Matching ...................................................20
6. Pseudonodes ....................................................21
7. TRILL Hello Reception and Transmission .........................21
7.1. Transmitting TRILL Hellos .................................22
7.2. Receiving TRILL Hellos ....................................23
8. Multiple Ports on the Same Link ................................24
9. Security Considerations ........................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................25
11. Acknowledgements ..............................................25
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using [IS-IS] (Intermediate System to Intermediate System) link state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs (Virtual Local Area Networks) and optimization of the distribution of multi-destination frames based on VLANs and IP-derived multicast groups. Devices that implement TRILL are called RBridges (Routing Bridges).
IETF TRILL（大量链路的透明互连）协议[RFC6325]提供无需配置的最佳成对数据帧转发，即使在临时循环期间也能安全转发，并支持单播和多播流量的多路径传输。TRILL通过使用[IS-IS]（中间系统到中间系统）链路状态路由和使用包含跳数的报头封装流量来实现这一点。该设计支持VLAN（虚拟局域网）和基于VLAN和IP派生多播组的多目标帧分布优化。实现TRILL的设备称为RBridges（路由桥）。
The purpose of this document is to improve the quality of the description of four aspects of the TRILL LAN (Local Area Network) Hello protocol that RBridges use on broadcast (LAN) links. It includes reference implementation details. Alternative implementations that interoperate on the wire are permitted. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL.
本文档旨在提高RBridges在广播（LAN）链路上使用的TRILL LAN（局域网）Hello协议四个方面的描述质量。它包括参考实现细节。允许在线路上进行互操作的替代实现。在TRILL中配置为点到点的链接上使用的is-is点到点Hellos没有变化。
The scope of this document is limited to the following aspects of the TRILL LAN Hello protocol:
本文件的范围仅限于TRILL LAN Hello协议的以下方面：
- Adjacency formation
- 邻接形成
- DRB (Designated RBridge aka DIS (Designated Intermediate System)) election
- DRB（指定中间系统）选举
- Rules for 2-way and MTU (Maximum Transmission Unit) matching for advertisements
- 广告的双向和MTU（最大传输单元）匹配规则
- Creation and use of pseudonodes
- 伪节点的创建和使用
For other aspects of the TRILL base protocol, see [RFC6325].
有关TRILL基本协议的其他方面，请参见[RFC6325]。
Section 2 below explains the rationale for the differences between the TRILL LAN Hello protocol and the Layer 3 IS-IS LAN Hello protocol [IS-IS] [RFC1195] in light of the environment for which the TRILL protocol is designed. It also describes the purposes of the TRILL LAN Hello protocol.
下面的第2节解释了TRILL LAN Hello协议与第3层IS-IS LAN Hello协议[IS-IS][RFC1195]之间的差异的基本原理，该差异与TRILL协议的设计环境有关。它还描述了TRILL LAN Hello协议的用途。
Section 3 describes the adjacency state machine and its states and relevant events.
第3节描述了邻接状态机及其状态和相关事件。
Section 4 describes the Designated RBridge (DRB) election state machine for RBridge ports and its states and relevant events.
第4节描述了RBridge端口的指定RBridge（DRB）选择状态机及其状态和相关事件。
Section 5 describes MTU testing and matching on a TRILL link.
第5节描述了TRILL链路上的MTU测试和匹配。
Section 6 discusses pseudonode creation and use.
第6节讨论伪节点的创建和使用。
Section 7 provides more details on the reception and transmission of TRILL LAN Hellos.
第7节提供了有关TRILL LAN Hello的接收和传输的更多详细信息。
Section 8 discusses multiple ports from one RBridge on the same link.
第8节讨论同一链路上一个RBridge的多个端口。
In case of conflict between this document and [RFC6325], this document prevails.
如果本文件与[RFC6325]之间存在冲突，则以本文件为准。
This document uses the acronyms defined in [RFC6325] supplemented by the following additional acronym:
本文件使用[RFC6325]中定义的首字母缩略词，并辅以以下附加首字母缩略词：
SNPA - Subnetwork Point of Attachment
SNPA-子网连接点
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 broadcast (LAN) subnetwork-dependent functions encountered at Layer 3, which are specified in [IS-IS] Section 8.4, the TRILL protocol uses modified subnetwork-dependent functions for a LAN subnetwork. The environmental differences are described in Sections 2.1 through 2.4, followed by a summation, in Section 2.5, of the purposes of the TRILL LAN Hello protocol.
[IS-IS]具有子网独立功能和子网相关功能。目前，IS-IS的第3层使用支持两种类型的子网：（1）路由器之间的点到点链路子网和（2）通用广播（LAN）子网。由于第3层路由器环境与TRILL RBridges环境之间的差异，TRILL协议对LAN子网使用修改后的子网相关功能，而不是[IS-IS]第8.4节中规定的在第3层遇到的广播（LAN）子网相关功能。第2.1节至第2.4节描述了环境差异，随后第2.5节总结了TRILL LAN Hello协议的目的。
RBridges can incrementally replace IEEE [802.1Q-2005] bridges. Thus, RBridges need to provide similar services, including delivery of frames only to links in the frame's VLAN and priority queuing of frames, to the extent that multiple queues are implemented at any particular RBridge port.
RBridges可以逐渐取代IEEE[802.1Q-2005]网桥。因此，RBridge需要提供类似的服务，包括仅向帧的VLAN中的链路交付帧和帧的优先级队列，以在任何特定RBridge端口实现多个队列。
RBridge ports are IEEE [802.1Q-2005] ports in terms of their frame VLAN and priority configuration and processing as described in Section 2.6 of [RFC6325]. When a frame is received through an RBridge port, like a frame received through any [802.1Q-2005] port, it has an associated VLAN ID and frame priority. When a frame is presented to an [802.1Q-2005] port for queuing and transmission, it must be accompanied by a VLAN ID and frame priority. However, whether the frame, if actually transmitted, will be VLAN tagged is determined by whether or not the port is configured to "strip VLAN tags". Furthermore, in the general case, a broadcast (LAN) link between RBridges can be a VLAN-capable bridged LAN that may be configured to partition VLANs.
根据[RFC6325]第2.6节所述的帧VLAN、优先级配置和处理，RBridge端口为IEEE[802.1Q-2005]端口。当通过RBridge端口接收帧时，与通过任何[802.1Q-2005]端口接收的帧一样，它具有相关的VLAN ID和帧优先级。当一个帧出现在[802.1Q-2005]端口进行排队和传输时，它必须附带VLAN ID和帧优先级。但是，如果实际传输，帧是否将被VLAN标记取决于端口是否配置为“剥离VLAN标记”。此外，在一般情况下，rbridge之间的广播（LAN）链路可以是可配置为划分VLAN的支持VLAN的桥接LAN。
Because devices that restrict VLAN connectivity, such as bridged LANs or provider bridging equipment, can be part of the link between RBridges, TRILL Data and TRILL IS-IS frames between RBridges use the link's Designated VLAN. The Designated VLAN is dictated for a link by the elected Designated RBridge (equivalent to the Designated Intermediate System at Layer 3). Because TRILL Data frames flow between RBridges on a link only in the link's Designated VLAN, adjacency for routing calculations is based only on connectivity characteristics in that VLAN.
由于限制VLAN连接的设备（如桥接LAN或提供商桥接设备）可以是RBridge之间链路的一部分，因此RBridge之间的TRILL数据和TRILL IS-IS帧使用链路的指定VLAN。指定的VLAN由选定的指定RBridge（相当于第3层的指定中间系统）为链路指定。由于TRILL数据帧仅在链路的指定VLAN中的链路上的RBridge之间流动，因此路由计算的邻接度仅基于该VLAN中的连接特征。
Ordinary Layer 3 data 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 their outer Layer 2 addressing and, at least if the packets are unicast, they are addressed to their first hop router. In contrast, RBridges running TRILL must accept, transport, and deliver untamed "native" frames (as defined in Section 1.4 of [RFC6325]). Native frames lack a TRILL hop count field. Native frames also have Layer 2 addresses that indicate their source and are used as the basis for their forwarding. 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 (Media Access Control) address mode, while Layer 3 router ports typically receive in a regularly selective MAC address mode.
普通的第3层数据包在由终端站发起时已经被“驯服”：它们包括跳数和第3层源地址和目的地址字段。此外，对于普通数据分组，不需要保留其外层2寻址，并且至少如果分组是单播的，则将其寻址到其第一跳路由器。相反，运行TRILL的RBridges必须接受、传输和交付未经驯服的“本机”帧（如[RFC6325]第1.4节所定义）。本机帧缺少颤音跳数字段。本机帧还具有第2层地址，指示其源，并用作其转发的基础。必须保留这些第2层地址，以便传递到本机帧的第2层目标。由此产生的一个差异是，提供本机帧服务的RBridge端口必须以混杂MAC（媒体访问控制）地址模式接收，而第3层路由器端口通常以定期选择的MAC地址模式接收。
TRILL handles this by having, on the link where an end station originated 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 frame. This augmented frame is then routed to one RBridge on the link having the destination end station for the frame (or one RBridge on each such
TRILL通过在终端站发起本机帧的链路上，通过添加包含跳数的TRILL报头，使一个RBridge“进入”这样一个本地发起的本机帧，从而将其转换为TRILL数据帧来处理此问题。然后，该增强帧被路由到链路上具有该帧的目的端站的一个RBridge（或每个这样的链路上的一个RBridge）
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.)
链接（如果是多目标帧）。这样的最终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. Such a loop could 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 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 on each link that is in charge of ingressing and egressing native frames from and to that link. This is the Designated RBridge that is elected using TRILL LAN Hellos as further described in Sections 2.5 and 4 below.
针对此类环路的主要颤音防御机制是强制性的，其目的是尽可能确保每个链路上只有一个单独的RBridge负责从该链路进出本机帧。如下文第2.5节和第4节所述，这是使用TRILL LAN Hellos选择的指定RBridge。
Because bridged LANs between RBridges can be configured in complex ways (e.g., so that some VLANs pass frames unidirectionally) and loop safety is important, there are additional TRILL defenses against loops that are beyond the scope of this document. Specifically, these defend against the occurrence of looping traffic that is in native format for part of the loop. These additional defenses have no effect on adjacency states or the receipt or forwarding of TRILL Data frames; they only affect native frame ingress and egress.
由于RBridges之间的桥接LAN可以以复杂的方式进行配置（例如，某些VLAN单向传递帧），并且环路安全性很重要，因此，对于超出本文档范围的环路，还有其他TRILL防御措施。具体地说，它们可以防止部分循环以本机格式出现循环流量。这些额外的防御对邻接状态或TRILL数据帧的接收或转发没有影响；它们只影响本机帧的进出。
RBridges are expected to provide service with zero configuration, except for services such as non-default VLAN or priority that require configuration when offered by [802.1Q-2005] bridges. 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.
RBridge预计将提供零配置的服务，但[802.1Q-2005]网桥提供时需要配置的非默认VLAN或优先级等服务除外。这与第3层路由不同，在第3层路由中，路由器通常需要配置为连接到每个端口等的子网，以提供服务。
TRILL IS-IS needs to be robust against links with reasonably restricted MTUs, including links that accommodate only classic Ethernet frames, despite the addition of reasonable headers such as VLAN tags. This is particularly true for TRILL LAN Hellos so as to assure that a unique DRB is elected.
TRILL IS-IS需要对具有合理限制的MTU的链路具有鲁棒性，包括仅容纳经典以太网帧的链路，尽管添加了合理的报头，如VLAN标记。这对于TRILL LAN Hellos尤其如此，以确保选出唯一的DRB。
TRILL will also be used inside data centers where it is not uncommon for all or most of the links and switches to support frames substantially larger than the classic Ethernet maximum. For example,
TRILL还将在数据中心内使用，在这些数据中心中，所有或大多数链路和交换机都支持比经典以太网最大值大得多的帧。例如
they may have an MTU adequate to comfortably handle Fiber Channel over Ethernet frames, for which T11 recommends a 2,500-byte MTU [FCoE]. It would be beneficial for an RBridge campus with such a large MTU to be able to safely make use of it.
它们可能有一个MTU，足以舒适地处理以太网帧上的光纤通道，T11建议使用2500字节的MTU[FCoE]。对于拥有如此大MTU的RBridge校园来说，能够安全地使用它将是有益的。
These needs are met by limiting the size of TRILL LAN Hellos and by the use of MTU testing as described below.
通过限制TRILL LAN Hello的大小和使用如下所述的MTU测试来满足这些需求。
There are three purposes for the TRILL-Hello protocol as listed below along with a reference to the section of this document in which each is discussed:
TRILL Hello协议有三个目的，如下所示，并参考了本文档中讨论的每一部分：
a) To determine which RBridge neighbors have acceptable connectivity to be reported as part of the topology (Section 3)
a) 确定哪些RBridge邻居具有可接受的连接，作为拓扑的一部分进行报告（第3节）
b) To elect a unique Designated RBridge on the link (Section 4)
b) 在链路上选择唯一的指定RBridge（第4节）
c) To determine the MTU with which it is possible to communicate with each RBridge neighbor (Section 5)
c) 确定可以与每个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 even discovered if it is impossible to communicate with it using maximum-sized 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 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, it does not disrupt Layer 3 IS-IS.
在第3层IS-IS中，这三种功能都是组合的。可以将Hellos填充到最大长度（参见[RFC3719]，第6节），以便在无法使用最大大小的数据包与其通信时，甚至不会发现路由器邻居。此外，即使R1接收来自邻居R2的Help，如果到R2的连接不是2路（即R2不在R2的Hello中列出R1），则R1不考虑R2作为指定的路由器候选。由于这种逻辑，在第3层，可以在LAN上选择多个指定路由器，每个路由器将LAN表示为伪节点。在拓扑结构上，似乎LAN现在是两个或多个独立的LAN。尽管这令人惊讶，但它并没有破坏第3层is-is。
In contrast, this behavior is not acceptable for TRILL, since in TRILL it is important that all RBridges on the link know about each other, and choose a single RBridge to be the DRB and to control the native frame ingress and egress on that link. Otherwise, multiple RBridges might encapsulate/decapsulate the same native frame, forming loops that are not protected by the hop count in the TRILL header as discussed above.
相反，这种行为对于TRILL是不可接受的，因为在TRILL中，链路上的所有RBridge必须相互了解，并选择一个RBridge作为DRB，并控制该链路上的本机帧进出。否则，多个RBridge可能会封装/解除封装相同的本机帧，从而形成不受TRILL报头中跳数保护的循环，如上所述。
So, the TRILL-Hello protocol is best understood by focusing on each of these functions separately.
因此，对TRILL Hello协议最好的理解是分别关注这些函数中的每一个。
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). TRILL-Hello frames, 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 that backbone to be a single link with hundreds of neighbors. Thus, the TRILL Hello uses a different Neighbor TLV [RFC6326] that lists neighbors seen for a range of MAC (SNPA) addresses.
TRILL LAN Hellos的另一个问题是，按照is-is链路状态PDU（LSP）和完整序列号PDU（CSNPs）的精神，确保信息子集可以出现在任何单个消息中，并且是可处理的。颤音Hello帧，即使没有填充，也会变得非常大。一个可能出现这种情况的例子是，当某种主干网技术将数百个TRILL站点互连在一个看似巨大的以太网上时，连接到该云的RBridge将认为主干网是一条与数百个邻居相连的单一链路。因此，TRILL Hello使用不同的邻居TLV[RFC6326]，该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 as discussed in this section. The states such adjacencies can have, the events that cause state changes, the actions associated with those state changes, and a state table and diagram are given below.
每个RBridge端口都关联一个端口状态（如第4节所述），以及一个包含零个或多个邻接的表（如本节所述）。下面给出了这种邻接可能具有的状态、导致状态更改的事件、与这些状态更改相关联的操作以及状态表和图表。
The determination of LSP-reported adjacencies on links that are not configured as point-to-point is made using TRILL LAN Hellos (see also Section 7) and an optional MTU test. Appropriate TRILL LAN Hello exchange and the satisfaction of the MTU test, if the MTU test is enabled (see Section 5), is required for there to be an adjacency that will be reported in an LSP of the RBridge in question.
使用TRILL LAN Hellos（另见第7节）和可选MTU测试确定未配置为点对点的链路上的LSP报告邻接。如果启用了MTU测试（见第5节），则需要适当的TRILL LAN Hello交换和MTU测试的满意度，以便在相关RBridge的LSP中报告相邻性。
Because bridges acting as glue on the LAN might be configured in such a way that some VLANs are partitioned, it is necessary for RBridges to transmit Hellos with multiple VLAN tags. The conceptually simplest solution may have been to have all 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, and only an RBridge that believes itself to be the DRB on a port "sprays" its TRILL Hellos on all of its enabled VLANs at a port (with the ability to configure to send on only a subset of those). The details are given in [RFC6325], Section 4.4.3.
由于在LAN上充当粘合剂的网桥的配置方式可能会导致某些VLAN被分区，因此RBridges有必要使用多个VLAN标记来传输Hellos。概念上最简单的解决方案可能是让所有RBridge传输高达4094倍的hello，每个端口启用一个合法的VLAN ID，但这显然会对性能产生有害影响。因此，TRILL协议规定，如果RB1知道它不是DRB，它只在有限的一组VLAN上传输它的Hello，并且只有认为自己是端口上的DRB的RBridge在端口上的所有启用VLAN上“喷洒”它的TRILL Hello（能够配置为只发送其中的一个子集）。详情见[RFC6325]第4.4.3节。
If the MAC (SNPA) address of more than one RBridge port on a 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.
如果链路上多个RBridge端口的MAC（SNPA）地址相同，则除一个端口外，所有此类端口都处于挂起状态（参见第4节），并且不参与链路，除非监视它们是否应保持挂起状态。
All TRILL LAN Hellos issued by an RBridge on a particular port MUST have the same source MAC address, priority, desired Designated VLAN, and Port ID, regardless of the VLAN in which the Hello is sent. Of course, the priority and desired Designated VLAN can change on occasion, but then the new value must similarly be used in all TRILL Hellos on the port, regardless of VLAN.
由特定端口上的RBridge发出的所有TRILL LAN Hello必须具有相同的源MAC地址、优先级、所需的指定VLAN和端口ID，而不考虑发送Hello的VLAN。当然，优先级和所需的指定VLAN有时会发生变化，但新值必须同样用于端口上的所有TRILL Hello，而不管VLAN如何。
Each adjacency is in one of the following four states:
每个邻接都处于以下四种状态之一：
Down: This is a virtual state for convenience in creating state diagrams and tables. It indicates that the adjacency is non-existent, and there is no entry in the adjacency table for it.
向下：这是一个虚拟状态，便于创建状态图和表。它表示邻接不存在，并且邻接表中没有它的条目。
Detect: An adjacent neighbor has been detected either (1) not on the Designated VLAN or (2) on the Designated VLAN, but neither 2-way connectivity nor the MTU of such connectivity has been confirmed.
检测：已检测到相邻邻居（1）不在指定VLAN上或（2）在指定VLAN上，但未确认双向连接或此类连接的MTU。
2-Way: 2-way connectivity to the neighbor has been found on the Designated VLAN but MTU testing is enabled and has not yet confirmed that the connectivity meets the campus minimum MTU requirement.
双向：已在指定VLAN上找到与邻居的双向连接，但MTU测试已启用，尚未确认连接是否满足校园最低MTU要求。
Report: There is 2-way connectivity to the neighbor on the Designated VLAN and either MTU testing has confirmed that the connectivity meets the campus minimum MTU requirement or MTU testing is not enabled. This connectivity will be reported in an LSP (with appropriate provision for the link pseudonode, if any, as described in Section 6).
报告：指定VLAN上存在与邻居的双向连接，MTU测试已确认连接满足校园最低MTU要求，或者MTU测试未启用。这种连接将在LSP中报告（如第6节所述，为链路伪节点（如有）提供适当的规定）。
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 of the neighbor (that is, its SNPA address, usually a 48-bit MAC address), and the Port ID and the System ID in the received Hellos. Together, these three quantities uniquely identify the adjacency.
o 邻居的地址（即其SNPA地址，通常为48位MAC地址），以及接收到的Hellos中的端口ID和系统ID。这三个量共同唯一地标识了邻接关系。
o Exactly two Hello holding timers, each consisting of a 16-bit unsigned integer number of seconds: a Designated VLAN holding timer and a non-Designated VLAN holding timer.
o 正好有两个Hello保持计时器，每个计时器由16位无符号整数秒组成：一个指定的VLAN保持计时器和一个非指定的VLAN保持计时器。
o The 7-bit unsigned priority of the neighbor to be the DRB.
o 要作为DRB的邻居的7位无符号优先级。
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。
The following events can change the state of an adjacency:
以下事件可以更改邻接的状态：
A0. Receive a TRILL Hello whose source MAC address (SNPA) is equal to that of the port on which it is received. This is a special event that is handled as described immediately after this list of events. It does not appear in the state transition table or diagram.
A0。接收一个TRILL Hello，其源MAC地址（SNPA）等于接收它的端口的地址。这是一个特殊事件，在事件列表之后立即按照所述进行处理。它不会出现在状态转换表或图表中。
A1. Receive a TRILL Hello (other than an A0 event) on the Designated VLAN with a TRILL Neighbor TLV that explicitly lists the receiver's (SNPA) address.
A1。在指定VLAN上接收TRILL Hello（A0事件除外），该VLAN具有明确列出接收器（SNPA）地址的TRILL邻居TLV。
A2. Receive a TRILL Hello (other than an A0 event) that either (1) is not on the Designated VLAN (any TRILL Neighbor TLV in such a Hello is ignored) or (2) is on the Designated VLAN but does not contain a TRILL Neighbor TLV covering an address range that includes the receiver's (SNPA) address.
A2。接收（1）不在指定VLAN上（忽略此Hello中的任何TRILL邻居TLV）或（2）在指定VLAN上但不包含覆盖包括接收器（SNPA）地址的地址范围的TRILL邻居TLV的TRILL Hello（A0事件除外）。
A3. Receive a TRILL Hello (other than an A0 event) on the Designated VLAN with one or more TRILL Neighbor TLVs covering an address range that includes the receiver's (SNPA) address -- and none of which lists the receiver.
A3。在指定的VLAN上接收TRILL Hello（A0事件除外），其中一个或多个TRILL邻居TLV覆盖的地址范围包括接收器（SNPA）地址，但没有一个列出接收器。
A4. The expiration of one or both Hello holding timers results in them both being expired.
A4。一个或两个Hello保持计时器的过期将导致它们都过期。
A5. The Designated VLAN Hello holding timer expires, but the non-Designated VLAN Hello holding timer still has time left until it expires.
A5。指定的VLAN Hello保持计时器过期，但非指定的VLAN Hello保持计时器在过期之前仍有剩余时间。
A6. MTU test successful.
A6。MTU测试成功。
A7. MTU test was successful but now fails.
A7。MTU测试成功，但现在失败。
A8. The RBridge port goes operationally down.
A8。RBridge端口在运行中关闭。
For the special A0 event, the Hello is examined to determine if it is higher priority to be the DRB than the port on which it is received 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 that port are discarded (transitioned to the Down state), and the port is suspended as described in Section 4.2.
对于特殊A0事件，按照第4.2.1节所述，检查Hello以确定作为DRB的优先级是否高于接收该事件的端口。如果Hello的优先级低于接收端口，则将丢弃它，无需进一步操作。如果其优先级高于接收端口，则丢弃该端口的任何邻接（转换为关闭状态），并按照第4.2节所述暂停该端口。
The receipt of a TRILL LAN Hello with a source MAC (SNPA) address different from that of the receiving port (that is, the occurrence of events A1, A2, or A3), causes the following actions (except where the Hello would create a new adjacency table entry, the table is full, or the Hello is too low priority to displace an existing entry as described in Section 3.6). The Designated VLAN used in these actions is the Designated VLAN dictated by the DRB determined without taking the received TRILL LAN Hello into account (see Section 4).
接收到源MAC（SNPA）地址不同于接收端口地址的TRILL LAN Hello（即，事件A1、A2或A3的发生），会导致以下操作（除非Hello将创建一个新的邻接表条目，否则该表已满，或者Hello的优先级太低，无法替换第3.6节中描述的现有条目）。这些操作中使用的指定VLAN是DRB指定的VLAN，该VLAN是在不考虑收到的TRILL LAN Hello的情况下确定的（参见第4节）。
o If the receipt of the Hellos creates a new adjacency table entry, the neighbor RBridge MAC (SNPA) address, Port ID, and System ID are set from the Hello.
o 如果Hellos的接收创建了一个新的邻接表条目，那么将从Hello设置邻居RBridge MAC（SNPA）地址、端口ID和系统ID。
o The appropriate Hello holding timer for the adjacency, depending on whether or not the Hello was received on the Designated VLAN, is set to the Holding Time field of the Hello. If the receipt of the Hello is creating a new adjacency table entry, the other timer is set to expired.
o 根据是否在指定的VLAN上接收到Hello，将邻接的相应Hello保持计时器设置为Hello的保持时间字段。如果Hello的接收正在创建新的邻接表条目，则另一个计时器将设置为过期。
o The priority of the neighbor RBridge to be the DRB is set to the priority field of the Hello.
o 要作为DRB的相邻RBridge的优先级设置为Hello的优先级字段。
o 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 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选择的结果，则在上述操作之后，会发生相应的RBridge端口事件（D2或D3），如第4.2节所述。
o 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，并且从DRB接收的前一个Hello中更改了指定VLAN，则结果是第4.2.3节中规定的链路的指定VLAN发生变化。
An event A4 resulting in both Hello Holding timers for an adjacency being expired and the adjacency going Down may also result in an event D3 as described in Section 4.2.
如第4.2节所述，导致邻接的Hello保持计时器过期和邻接下降的事件A4也可能导致事件D3。
Concerning events A6 and A7, if MTU testing is not enabled, A6 is considered to occur immediately upon the adjacency entering the 2-Way state, and A7 cannot occur.
关于事件A6和A7，如果未启用MTU测试，则认为A6会在邻接处进入双向状态时立即发生，而A7不会发生。
See further TRILL LAN Hello receipt details in Section 7.
详见第7节中的TRILL LAN 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 |
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 above.
N/A表示左侧事件在列顶部的状态下不适用。这些事件仅影响一个相邻关系。特殊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 |
+---------+
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 could be established.)
颤音可见的相邻RBridge之间可能存在多个平行邻接。（通过链路聚合[802.1AX]等技术连接在一起的多个低级别链路看起来像是一个只能建立单个颤音邻接的单个链路。）
Any such links that have pseudonodes (see Section 6) are distinguished in the topology; such adjacencies, if they are in the Report state, appear in LSPs as per Section 6. However, there can be
具有伪节点的任何此类链路（见第6节）在拓扑中都是可区分的；根据第6节，如果这些邻接处于报告状态，则会出现在LSP中。然而，也有可能
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) and Appendix C of [RFC6325].
没有伪节点的多个并行邻接，因为它们是点对点邻接或LAN邻接，没有为其创建伪节点。报告状态中的此类并行非伪节点邻接在LSP中显示为单个邻接。这种邻接的成本可以向下调整，以考虑平行路径。如[RFC6325]第4.5.2节（第3点）和附录C中所述，对于单播TRILL数据流量，可以在每个流的基础上自由地跨此类并行连接进行多路径传输，但对于多目的地流量，则受到限制。
If the receipt of a TRILL LAN 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. In that case, the DRB election priority (see Section 4.2.1) of the new entry that would be created is compared with that 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.
如果收到TRILL LAN Hello将创建一个新的邻接表条目（即，将邻接转换为关闭状态），则可能没有空间容纳新条目。在这种情况下，将创建的新条目的DRB选择优先级（见第4.2.1节）与现有条目的优先级进行比较。如果新条目的优先级高于最低优先级的现有条目，则它将替换转换为关闭状态的最低优先级的现有条目。
The information at an RBridge associated with each of its LAN ports includes the following:
RBridge上与其每个LAN端口关联的信息包括：
o Enablement bit, which defaults to enabled.
o 启用位，默认为启用。
o SNPA address (usually 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 Hellos sent on the port.
o 优先级为DRB，用于在端口上发送的颤音Hello。
o The DRB status 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 this port, used in TRILL Hellos sent on the port.
o 所需的指定VLAN。此RBridge想要的VLAN是此端口的链接的指定VLAN，用于端口上发送的TRILL Hellos。
o A table of zero or more adjacencies (see Section 3).
o 包含零个或多个邻接的表格（见第3节）。
The TRILL equivalent of the DIS (Designated Intermediate System) on a link is the DRB or Designated RBridge. The DRB election state machinery is described below.
链路上DIS（指定的中间系统）的颤音等效物是DRB或指定的RBridge。DRB选举国家机构描述如下。
Each RBridge port 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 adjacency table entries for the port, and no TRILL Hellos or other IS-IS PDUs or TRILL Data frames are accepted or transmitted.
停机：端口处于操作停机状态。它可能在链接层被管理禁用或关闭。在此状态下，端口将没有邻接表条目，并且不会接受或传输TRILL Hellos或其他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 Hellos are accepted for the sole purpose of determining whether to change the value of the Suspension timer for the port as described below.
挂起：由于链路上有一个优先级较高的端口具有相同的MAC（SNPA）地址，因此该端口的操作被挂起。这与关闭状态相同，但接受TRILL Hellos的唯一目的是确定是否更改端口的暂停计时器值，如下所述。
DRB: The port is the DRB and can receive and transmit TRILL Data frames.
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 frames.
非DRB：该端口延迟到链路上的另一个端口，它认为该端口是DRB，但仍然可以接收和发送TRILL数据帧。
The following events can change the DRB state of a port:
以下事件可能会更改端口的DRB状态：
D1. Expiration of the suspension timer while the port is in the Suspended state or the enablement of the port.
D1。当端口处于挂起状态或启用端口时，挂起计时器过期。
D2. 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端口的条目似乎比本地端口的DRB优先级更高。
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. Receipt of a TRILL Hello with the same MAC address (SNPA) as the receiving port and higher priority to be the DRB as described for event A0.
D4。接收TRILL 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 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在港口上的邻接状态不是Down状态。获胜者是具有最高优先级的RBridge作为DRB，根据该RBridge的HELOS中的7位优先级字段确定，本地端口的优先级作为DRB字段，MAC（SNPA）地址作为分界线，端口ID作为第二分界线，系统ID作为第三分界线。将这些字段作为无符号整数进行比较，大小越大，优先级越高。
Resort 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, that 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, 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）地址，并且其中一些端口尚未挂起时，才有必要使用二级和三级断开连接。例如，作为链路上的DRB的优先级较低的RB1可以从链路上具有相同MAC地址且作为DRB的优先级较高的两个其他端口接收HELLO。具有相同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 the 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 Designated RBridge and not being the Designated RBridge at a port, this will generally change the VLANs on which Hellos are sent by that RBridge on that port as specified in Section 4.4.3 of [RFC6325].
如果某个RBridge在某个端口的指定RBridge和非指定RBridge之间的任意方向发生变化，这通常会改变该RBridge在该端口上发送Hello的VLAN，如[RFC6325]第4.4.3节所述。
Unnecessary changes in the Designated VLAN on a link should be avoided because a change in the Designated VLAN can cause a transient interruption 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, in case the winner of the DRB election changes, for any reason, the Designated VLAN will remain the same.
应避免在链路上的指定VLAN中进行不必要的更改，因为指定VLAN中的更改可能会导致链路上TRILL数据转发的暂时中断。实际情况下，链路上的所有RBridge端口应配置相同的指定VLAN，以便在DRB选举的获胜者因任何原因发生变化的情况下，指定的VLAN将保持不变。
If an RBridge detects a change in Designated VLAN on a 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 | Suspend | 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 | Suspend | Suspend | Suspend |
| D5 | Down | Down | Down | Down |
| Event | Down | Suspend | 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 | Suspend | Suspend | Suspend |
| D5 | Down | Down | Down | Down |
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 |
+----+
The purpose of MTU testing is to ensure that the links used in the campus topology can pass TRILL IS-IS and Data frames at the RBridge campus MTU.
MTU测试的目的是确保校园拓扑中使用的链路能够通过RBridge校园MTU上的TRILL is-is和数据帧。
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.
RBridge RB1通过计算其起始L1LSPBufferSize和校园中其他RBridge的起始L1LSPBufferSize的最小值（如链路状态数据库中公布的）来确定所需的校园链路MTU，但不小于1470字节。虽然第3层[IS-IS]中的原始L1LSPBUFFERSIZE限制在512到1492字节（含）的范围内，但在颤音中，它限制在1470到65535字节（含）的范围内。
Although MTU testing is optional, it is mandatory for an RBridge to respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] [RFC6326]. 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 multicasting MTU-probes when a response from all other RBridges on the link is desired, such as when initializing or re-confirming MTU, unicasting MTU-probes when a response from a single RBridge is desired, such as one that has just been detected on the link, and unicasting all MTU-ack frames.
尽管MTU测试是可选的，但RBridge必须使用MTU ack PDU[RFC6325][RFC6326]响应MTU探针PDU。对MTU探测和MTU确认使用多播或单播是一种实现选择。然而，当需要来自链路上的所有其他RBridge的响应时，例如当初始化或重新确认MTU时，通常通过多播MTU探测来最小化链路上的负担，当需要来自单个RBridge的响应时，例如刚刚在链路上检测到的响应时，单播MTU探测，以及单播所有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 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 MTU failure is noticed by the RBridge at either end of the adjacency, it will not be so used.
如[RFC6325]第4.3.2节所述，RB1可将MTU尺寸测试为RB2。为此，MTU测试仅在指定的VLAN中进行。未通过校园MTU MTU测试的邻接将不会进入报告状态，或者，如果邻接处于该状态，它将离开该状态。因此，执行测试的RBridge不会报告未通过MTU测试的邻接。由于包含在最小成本路由计算中要求两端报告相邻，只要相邻两端的RBridge注意到MTU故障，就不会使用MTU。
If it tests MTU, RB1 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.
如果测试MTU，RB1将报告MTU测试成功的最大大小，或在校园MTU上显示失败的标志。此报告始终与RB1的颤音邻居TLV中的邻居一起显示。RB1还可以报告RB1的LSP中扩展可达性TLV中的邻接情况。RB1可以选择测试大于所需校园MTU以及所需校园MTU的MTU大小。
Most types of TRILL IS-IS frames, 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（其大小必须针对正在执行的测试进行适当调整）。
The Designated RBridge (DRB), determined as described above, controls whether a pseudonode will be used on a link.
如上所述确定的指定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, 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 DRB, then if RB1 creates a pseudonode that is used, there are 3 LSPs: for, say, RB1.25 (the pseudonode), 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. Whereas 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创建了一个使用的伪节点，则有3个LSP：例如，RB1.25（伪节点）、RB1和RB2，其中RB1.25向RB1和RB2报告连接，而RB1和RB2仅表示它们连接到RB1.25。然而，如果DRB RB1在其hello中设置了旁路伪节点位，那么将只有2个LSP：RB1和RB2各自报告彼此的连接。
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 and transmission of TRILL LAN Hellos.
本节提供有关TRILL LAN Hellos接收和传输的更多详细信息。
TRILL LAN Hellos, like all TRILL IS-IS frames, are primarily distinguished from Layer 3 IS-IS frames by being sent to the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41). TRILL IS-IS frames also have the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded.
TRILL LAN 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 use of Level 2 IS-IS, [RFC6325] specifies TRILL using a single Level 1 Area with Area Address zero (see Section 4.2 of [RFC6326]).
尽管TRILL的未来扩展可能包括使用2级IS-IS，但[RFC6325]使用区域地址为零的单个1级区域指定TRILL（见[RFC6326]第4.2节）。
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 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 receive TRILL LAN Hellos on every port that is not disabled or configured as point-to-point.
IS-IS第3层路由器经常连接到属于不同路由域的其他第3层路由器。在这种情况下，externalDomain标志（请参见[IS-IS]）通常是为进行这种连接的端口设置的。将此标志设置为“true”会导致不向端口发送IS-IS PDU，并且丢弃接收到的任何IS-IS PDU，包括Hellos。RBridges在不同的环境中运行，所有相邻RBridges合并到一个校园中。为了循环安全，RBridges不实现externalDomain标志或使用固定值“false”实现它。它们在每个未禁用或未配置为点对点的端口上发送和接收TRILL LAN Hello。
TRILL LAN Hellos are sent with the same timing as Layer 3 IS-IS LAN Hellos [IS-IS]; however, no Hellos are sent if a port is in the Suspended or Down states.
TRILL LAN Hello的发送时间与第3层IS-IS LAN Hello[IS-IS]的发送时间相同；但是，如果端口处于挂起或关闭状态，则不会发送Hello。
TRILL-Hello PDUs SHOULD NOT be padded and MUST NOT be sent exceeding 1,470 octets; however, a received TRILL Hello longer than 1,470 octets 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。
Each TRILL Hello MUST contain an Area Addresses TLV listing only the single Area zero, and an MT Port Capabilities TLV containing a VLAN-FLAGS sub-TLV [RFC6326]. If a Protocols Supported TLV is present, it MUST list the TRILL NLPID (0xC0).
每个TRILL Hello必须包含一个仅列出单个区域零的区域地址TLV，以及一个包含VLAN-FLAGS子TLV[RFC6326]的MT端口功能TLV。如果存在协议支持的TLV，则必须列出颤音NLPID（0xC0）。
The TRILL Neighbor TLV sent in a Hello 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 Hellos on the Designated VLAN.
在Hello中发送的TRILL Neighbor TLV必须显示发送Hello的VLAN的邻居信息，如传输RBridge所感测到的。由于符合本文档要求的实现仅为指定的VLAN在每个VLAN的基础上维护此类信息，因此此类实现仅在指定VLAN上以TRILL 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 TLV's covering sub-ranges of MAC addresses should be sent so that the entire range is covered reasonably promptly. Delays in sending TRILL
如[RFC6325]第4.4.2.1节所述，如果有足够的空间，建议使用TRILL邻居TLV或TLV，覆盖整个MAC地址范围，并列出指定VLAN Hello保持时间为非零的所有邻接，如果没有此类邻接，则列出空邻接列表，在指定的VLAN上发送颤音问候。如果这是不可能的，则应发送TRILL邻居TLV的MAC地址覆盖子范围，以便合理及时地覆盖整个范围。发送颤音的延迟
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 Bidirectional Forwarding Detection (BFD) [RFC5880], use of which with TRILL will be specified in a separate document.
相邻TLV将延迟报告状态邻接的进展和某些链路故障的发现。链路或节点故障的快速（例如，亚秒）检测最好使用为此目的设计的协议来解决，例如双向转发检测（BFD）[RFC5880]，将在单独的文档中指定与TRILL一起使用。
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, never appears in any list.
为了确保任何RBridge RB2都能确定RB1是否能听到RB2，RB1的邻居列表最终必须覆盖所有可能的ID范围，即，在一段时间内（取决于RB1的策略），而不一定是在任何特定的时间内（如等待时间）。换句话说，如果X1是RB1的一个邻居列表中报告的最小ID，并且没有设置“最小”标志，那么X1也必须出现在不同的邻居列表中，以及该片段中报告的最大ID。或列表可能重叠，只要没有间隙，这样的范围，例如席和XJ之间，永远不会出现在任何列表中。
A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS Hello. TLVs that are unsupported/unknown are ignored.
颤音Hello还可以包含第3层IS-IS Hello中允许的任何TLV。不受支持/未知的TLV将被忽略。
Assuming a frame has the All-IS-IS-RBridges multicast address and L2-IS-IS Ethertype, it will be examined to see if it appears to be an IS-IS PDU. If so, and it appears to be a LAN Hello PDU, the following tests are performed.
假设一个帧具有All IS RBRIGES多播地址和L2-IS-IS以太类型，将对其进行检查，以确定它是否是IS-IS PDU。如果是，并且它似乎是LAN Hello PDU，则执行以下测试。
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 [RFC6326], it is discarded.
o 如果Hello不包含包含VLAN-FLAGS子TLV[RFC6326]的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 the PDU either has no Authentication TLV or validation of that Authentication TLV fails, it is discarded.
o 如果链路上正在使用IS-IS身份验证，并且PDU没有身份验证TLV或该身份验证TLV的验证失败，则将放弃该身份验证。
If none of the rules in the list above has been satisfied, and the frame 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.
如果上面列表中的任何规则都没有得到满足，并且帧是可解析的，则假定它是在链接上接收到的格式良好的颤音Hello。根据第3.3节列出的标准，将其视为事件A0、A1、A2或A3。
It is possible for an RBridge RB1 to have multiple ports on the same 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 LAN Hello messages with the same LAN ID on multiple ports.
RBridge RB1可能在同一链路上有多个未处于挂起状态的端口。RB1必须识别其哪些端口位于同一链路上。RB1可以通过在多个端口上接收具有相同LAN ID的TRILL LAN 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 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 and it is safe to do so as described in Section 4.4.4 of [RFC6325].
DRB选择是基于端口的（参见第4节），并且只有来自所选端口的HELLO可以执行某些功能，例如指令指定的VLAN或是否将使用伪节点；然而，选举还将带有该端口的RBridge指定为链路的DRB。如果RBridge有多个端口，并且按照[RFC6325]第4.4.4节中的描述，可以安全地选择在链路上的端口之间加载拆分任务。
This memo provides improved documentation of some aspects of the TRILL base protocol standard, particularly four aspects of the TRILL LAN Hello protocol. It does not change the security considerations of the TRILL base protocol. See Section 6 of [RFC6325].
本备忘录提供了TRILL基本协议标准某些方面的改进文档，特别是TRILL LAN Hello协议的四个方面。它不会改变TRILL基本协议的安全考虑。见[RFC6325]第6节。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing 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月。
[RFC6325] Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]Perlman，R.，D.Eastlake，D.Dutt，S.Gai和A.Ghanwani，“RBridges:基本协议规范”，RFC 63252011年7月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011.
[RFC6326]伊斯特莱克、班纳吉、杜特、帕尔曼和加瓦尼，“IS-IS的颤音使用”，RFC6326，2011年7月。
[802.1AX] "IEEE Standard for Local and metropolitan area networks / Link Aggregation", 802.1AX-2008, 1 January 2008.
[802.1AX]“局域网和城域网/链路聚合的IEEE标准”，802.1AX-2008，2008年1月1日。
[802.1Q-2005] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.
[802.1Q-2005]“局域网和城域网/虚拟桥接局域网的IEEE标准”，802.1Q-2005，2006年5月19日。
[FCoE] From www.t11.org discussion of "FCoE Max Size" generated from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU".
[FCoE]来源于www.t11.org关于t11/09-251v2009年4月27日“FCoE框架或FCoE PDU”产生的“FCoE最大尺寸”的讨论。
[RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", February 2004.
[RFC3719]Parker，J.，Ed.“使用中间系统到中间系统（IS-IS）的互操作网络的建议”，2004年2月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
The authors of [RFC6325], those listed in the Acknowledgements section of [RFC6325], and the contributions of Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay Gupta, David Harrington, Pete McCann, Erik Nordmark, and Mike Shand, to this document, are hereby acknowledged.
特此确认[RFC6325]的作者、[RFC6325]致谢部分列出的作者以及Jari Arkko、Ayan Banerjee、Les Ginsberg、Sujay Gupta、David Harrington、Pete McCann、Erik Nordmark和Mike Shand对本文件的贡献。
Authors' Addresses
作者地址
Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
美国马萨诸塞州米尔福德市海狸街155号华为技术第三公司Donald E.Eastlake邮编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-1549 USA
Radia Perlman英特尔实验室使命学院大道2200号。美国加利福尼亚州圣克拉拉95054-1549
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Anoop Ghanwani Brocade 130 Holger Way San Jose, CA 95134 USA
美国加利福尼亚州圣何塞霍尔格大道130号Anoop Ghanwani Brocade，邮编95134
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu
Dinesh G. Dutt Cisco Systems 170 Tasman Drive San Jose, CA 95134-1706 USA
美国加利福尼亚州圣何塞塔斯曼大道170号，邮编95134-1706
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Vishwas Manral Hewlett Packard Co. 19111 Pruneridge Ave, Cupertino, CA 95014 USA
维斯沃斯·曼拉尔·惠普公司，地址：美国加利福尼亚州库比蒂诺市普鲁尼里奇大道19111号，邮编：95014
Phone: +1-408-447-1497
EMail: vishwas.manral@hp.com
Phone: +1-408-447-1497
EMail: vishwas.manral@hp.com