Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 6325 Intel Labs
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei
D. Dutt
S. Gai
Cisco Systems
A. Ghanwani
Brocade
July 2011
Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 6325 Intel Labs
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei
D. Dutt
S. Gai
Cisco Systems
A. Ghanwani
Brocade
July 2011
Routing Bridges (RBridges): Base Protocol Specification
路由桥（RBridges）：基本协议规范
Abstract
摘要
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.
路由桥（RBridges）提供无需配置的最佳成对转发，即使在临时循环期间也能安全转发，并支持单播和多播流量的多路径传输。它们使用IS-IS路由和包含跃点计数的报头对流量进行封装来实现这些目标。
RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.
RBridges与以前的IEEE 802.1客户网桥以及IPv4和IPv6路由器和终端节点兼容。它们对当前的IP路由器就像网桥一样不可见，并且像路由器一样，它们终止网桥生成树协议。
The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges.
该设计支持VLAN以及基于VLAN ID和基于IP派生的多播组的多目标帧分布的优化。它还允许根据RBridge的数量（而不是终端节点的数量）调整transit RBridge处的单播转发表的大小，这使得它们的转发表大大小于传统客户网桥中的转发表。
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/rfc6325.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6325.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................6
1.1. Algorhyme V2, by Ray Perlner ...............................7
1.2. Normative Content and Precedence ...........................7
1.3. Terminology and Notation in This Document ..................7
1.4. Categories of Layer 2 Frames ...............................8
1.5. Acronyms ...................................................9
2. RBridges .......................................................11
2.1. General Overview ..........................................11
2.2. End-Station Addresses .....................................12
2.3. RBridge Encapsulation Architecture ........................13
2.4. Forwarding Overview .......................................15
2.4.1. Known-Unicast ......................................16
2.4.2. Multi-Destination ..................................16
2.5. RBridges and VLANs ........................................17
2.5.1. Link VLAN Assumptions ..............................17
2.6. RBridges and IEEE 802.1 Bridges ...........................18
2.6.1. RBridge Ports and 802.1 Layering ...................18
2.6.2. Incremental Deployment .............................20
3. Details of the TRILL Header ....................................20
3.1. TRILL Header Format .......................................20
3.2. Version (V) ...............................................21
3.3. Reserved (R) ..............................................21
3.4. Multi-destination (M) .....................................22
3.5. Op-Length .................................................22
3.6. Hop Count .................................................22
3.7. RBridge Nicknames .........................................23
3.7.1. Egress RBridge Nickname ............................23
3.7.2. Ingress RBridge Nickname ...........................24
3.7.3. RBridge Nickname Selection .........................24
3.8. TRILL Header Options ......................................26
4. Other RBridge Design Details ...................................27
4.1. Ethernet Data Encapsulation ...............................27
4.1.1. VLAN Tag Information ...............................30
4.1.2. Inner VLAN Tag .....................................31
4.1.3. Outer VLAN Tag .....................................31
4.1.4. Frame Check Sequence (FCS) .........................32
4.2. Link State Protocol (IS-IS) ...............................32
4.2.1. IS-IS RBridge Identity .............................32
4.2.2. IS-IS Instances ....................................33
4.2.3. TRILL IS-IS Frames .................................33
4.2.4. TRILL Link Hellos, DRBs, and Appointed Forwarders ..34
4.2.4.1. P2P Hello Links ...........................35
4.2.4.2. Designated RBridge ........................35
4.2.4.3. Appointed VLAN-x Forwarder ................36
4.2.4.4. TRILL LSP Information .....................37
4.2.5. The TRILL ESADI Protocol ...........................40
1. Introduction ....................................................6
1.1. Algorhyme V2, by Ray Perlner ...............................7
1.2. Normative Content and Precedence ...........................7
1.3. Terminology and Notation in This Document ..................7
1.4. Categories of Layer 2 Frames ...............................8
1.5. Acronyms ...................................................9
2. RBridges .......................................................11
2.1. General Overview ..........................................11
2.2. End-Station Addresses .....................................12
2.3. RBridge Encapsulation Architecture ........................13
2.4. Forwarding Overview .......................................15
2.4.1. Known-Unicast ......................................16
2.4.2. Multi-Destination ..................................16
2.5. RBridges and VLANs ........................................17
2.5.1. Link VLAN Assumptions ..............................17
2.6. RBridges and IEEE 802.1 Bridges ...........................18
2.6.1. RBridge Ports and 802.1 Layering ...................18
2.6.2. Incremental Deployment .............................20
3. Details of the TRILL Header ....................................20
3.1. TRILL Header Format .......................................20
3.2. Version (V) ...............................................21
3.3. Reserved (R) ..............................................21
3.4. Multi-destination (M) .....................................22
3.5. Op-Length .................................................22
3.6. Hop Count .................................................22
3.7. RBridge Nicknames .........................................23
3.7.1. Egress RBridge Nickname ............................23
3.7.2. Ingress RBridge Nickname ...........................24
3.7.3. RBridge Nickname Selection .........................24
3.8. TRILL Header Options ......................................26
4. Other RBridge Design Details ...................................27
4.1. Ethernet Data Encapsulation ...............................27
4.1.1. VLAN Tag Information ...............................30
4.1.2. Inner VLAN Tag .....................................31
4.1.3. Outer VLAN Tag .....................................31
4.1.4. Frame Check Sequence (FCS) .........................32
4.2. Link State Protocol (IS-IS) ...............................32
4.2.1. IS-IS RBridge Identity .............................32
4.2.2. IS-IS Instances ....................................33
4.2.3. TRILL IS-IS Frames .................................33
4.2.4. TRILL Link Hellos, DRBs, and Appointed Forwarders ..34
4.2.4.1. P2P Hello Links ...........................35
4.2.4.2. Designated RBridge ........................35
4.2.4.3. Appointed VLAN-x Forwarder ................36
4.2.4.4. TRILL LSP Information .....................37
4.2.5. The TRILL ESADI Protocol ...........................40
4.2.5.1. TRILL ESADI Participation .................42
4.2.5.2. TRILL ESADI Information ...................42
4.2.6. SPF, Forwarding, and Ambiguous Destinations ........43
4.3. Inter-RBridge Link MTU Size ...............................43
4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size .......44
4.3.2. Testing Link MTU Size ..............................44
4.4. TRILL-Hello Protocol ......................................45
4.4.1. TRILL-Hello Rationale ..............................45
4.4.2. TRILL-Hello Contents and Timing ....................46
4.4.2.1. TRILL Neighbor List .......................48
4.4.3. TRILL MTU-Probe and TRILL Hello VLAN Tagging .......49
4.4.4. Multiple Ports on the Same Link ....................50
4.4.5. VLAN Mapping within a Link .........................51
4.5. Distribution Trees ........................................52
4.5.1. Distribution Tree Calculation ......................54
4.5.2. Multi-Destination Frame Checks .....................55
4.5.3. Pruning the Distribution Tree ......................57
4.5.4. Tree Distribution Optimization .....................58
4.5.5. Forwarding Using a Distribution Tree ...............59
4.6. Frame Processing Behavior .................................60
4.6.1. Receipt of a Native Frame ..........................60
4.6.1.1. Native Unicast Case .......................60
4.6.1.2. Native Multicast and Broadcast Frames .....61
4.6.2. Receipt of a TRILL Frame ...........................62
4.6.2.1. TRILL Control Frames ......................63
4.6.2.2. TRILL ESADI Frames ........................63
4.6.2.3. TRILL Data Frames .........................63
4.6.2.4. Known Unicast TRILL Data Frames ...........63
4.6.2.5. Multi-Destination TRILL Data Frames .......64
4.6.3. Receipt of a Layer 2 Control Frame .................65
4.7. IGMP, MLD, and MRD Learning ...............................66
4.8. End-Station Address Details ...............................66
4.8.1. Learning End-Station Addresses .....................67
4.8.2. Learning Confidence Level Rationale ................68
4.8.3. Forgetting End-Station Addresses ...................69
4.8.4. Shared VLAN Learning ...............................70
4.9. RBridge Ports .............................................71
4.9.1. RBridge Port Configuration .........................71
4.9.2. RBridge Port Structure .............................73
4.9.3. BPDU Handling ......................................76
4.9.3.1. Receipt of BPDUs ..........................76
4.9.3.2. Root Bridge Changes .......................76
4.9.3.3. Transmission of BPDUs .....................77
4.9.4. Dynamic VLAN Registration ..........................77
5. RBridge Parameters .............................................77
5.1. Per RBridge ...............................................78
5.2. Per Nickname Per RBridge ..................................79
5.3. Per Port Per RBridge ......................................79
4.2.5.1. TRILL ESADI Participation .................42
4.2.5.2. TRILL ESADI Information ...................42
4.2.6. SPF, Forwarding, and Ambiguous Destinations ........43
4.3. Inter-RBridge Link MTU Size ...............................43
4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size .......44
4.3.2. Testing Link MTU Size ..............................44
4.4. TRILL-Hello Protocol ......................................45
4.4.1. TRILL-Hello Rationale ..............................45
4.4.2. TRILL-Hello Contents and Timing ....................46
4.4.2.1. TRILL Neighbor List .......................48
4.4.3. TRILL MTU-Probe and TRILL Hello VLAN Tagging .......49
4.4.4. Multiple Ports on the Same Link ....................50
4.4.5. VLAN Mapping within a Link .........................51
4.5. Distribution Trees ........................................52
4.5.1. Distribution Tree Calculation ......................54
4.5.2. Multi-Destination Frame Checks .....................55
4.5.3. Pruning the Distribution Tree ......................57
4.5.4. Tree Distribution Optimization .....................58
4.5.5. Forwarding Using a Distribution Tree ...............59
4.6. Frame Processing Behavior .................................60
4.6.1. Receipt of a Native Frame ..........................60
4.6.1.1. Native Unicast Case .......................60
4.6.1.2. Native Multicast and Broadcast Frames .....61
4.6.2. Receipt of a TRILL Frame ...........................62
4.6.2.1. TRILL Control Frames ......................63
4.6.2.2. TRILL ESADI Frames ........................63
4.6.2.3. TRILL Data Frames .........................63
4.6.2.4. Known Unicast TRILL Data Frames ...........63
4.6.2.5. Multi-Destination TRILL Data Frames .......64
4.6.3. Receipt of a Layer 2 Control Frame .................65
4.7. IGMP, MLD, and MRD Learning ...............................66
4.8. End-Station Address Details ...............................66
4.8.1. Learning End-Station Addresses .....................67
4.8.2. Learning Confidence Level Rationale ................68
4.8.3. Forgetting End-Station Addresses ...................69
4.8.4. Shared VLAN Learning ...............................70
4.9. RBridge Ports .............................................71
4.9.1. RBridge Port Configuration .........................71
4.9.2. RBridge Port Structure .............................73
4.9.3. BPDU Handling ......................................76
4.9.3.1. Receipt of BPDUs ..........................76
4.9.3.2. Root Bridge Changes .......................76
4.9.3.3. Transmission of BPDUs .....................77
4.9.4. Dynamic VLAN Registration ..........................77
5. RBridge Parameters .............................................77
5.1. Per RBridge ...............................................78
5.2. Per Nickname Per RBridge ..................................79
5.3. Per Port Per RBridge ......................................79
5.4. Per VLAN Per RBridge ......................................80
6. Security Considerations ........................................80
6.1. VLAN Security Considerations ..............................81
5.4. Per VLAN Per RBridge ......................................80
6. Security Considerations ........................................80
6.1. VLAN Security Considerations ..............................81
6.2. BPDU/Hello Denial-of-Service Considerations ...............82
7. Assignment Considerations ......................................82
7.1. IANA Considerations .......................................83
7.2. IEEE Registration Authority Considerations ................83
8. Normative References ...........................................83
9. Informative References .........................................85
Appendix A. Incremental Deployment Considerations .................87
A.1. Link Cost Determination ...................................87
A.2. Appointed Forwarders and Bridged LANs .....................87
A.3. Wiring Closet Topology ....................................89
A.3.1. The RBridge Solution ...............................90
A.3.2. The VLAN Solution ..................................90
A.3.3. The Spanning Tree Solution .........................90
A.3.4. Comparison of Solutions ............................91
Appendix B. Trunk and Access Port Configuration ...................92
Appendix C. Multipathing ..........................................92
Appendix D. Determination of VLAN and Priority ....................95
Appendix E. Support of IEEE 802.1Q-2005 Amendments ................95
E.1. Completed Amendments ......................................96
E.2. In-Process Amendments .....................................97
Appendix F. Acknowledgements ......................................98
6.2. BPDU/Hello Denial-of-Service Considerations ...............82
7. Assignment Considerations ......................................82
7.1. IANA Considerations .......................................83
7.2. IEEE Registration Authority Considerations ................83
8. Normative References ...........................................83
9. Informative References .........................................85
Appendix A. Incremental Deployment Considerations .................87
A.1. Link Cost Determination ...................................87
A.2. Appointed Forwarders and Bridged LANs .....................87
A.3. Wiring Closet Topology ....................................89
A.3.1. The RBridge Solution ...............................90
A.3.2. The VLAN Solution ..................................90
A.3.3. The Spanning Tree Solution .........................90
A.3.4. Comparison of Solutions ............................91
Appendix B. Trunk and Access Port Configuration ...................92
Appendix C. Multipathing ..........................................92
Appendix D. Determination of VLAN and Priority ....................95
Appendix E. Support of IEEE 802.1Q-2005 Amendments ................95
E.1. Completed Amendments ......................................96
E.2. In-Process Amendments .....................................97
Appendix F. Acknowledgements ......................................98
Table of Figures
图表
Figure 1: Interconnected RBridges .................................14
Figure 2: An Ethernet Encapsulated TRILL Frame ....................14
Figure 3: A PPP Encapsulated TRILL Frame ..........................14
Figure 4: RBridge Port Model ......................................19
Figure 5: TRILL Header ............................................21
Figure 6: Options Area Initial Flags Octet ........................26
Figure 7: TRILL Data Encapsulation over Ethernet ..................29
Figure 8: VLAN Tag Information ....................................30
Figure 9: TRILL IS-IS Frame Format ................................34
Figure 10: TRILL ESADI Frame Format ...............................41
Figure 11: Detailed RBridge Port Model ............................74
Figure 12: Link Cost of a Bridged Link ............................87
Figure 13: Wiring Closet Topology .................................89
Figure 14: Multi-Destination Multipath ............................93
Figure 15: Known Unicast Multipath ................................94
Figure 1: Interconnected RBridges .................................14
Figure 2: An Ethernet Encapsulated TRILL Frame ....................14
Figure 3: A PPP Encapsulated TRILL Frame ..........................14
Figure 4: RBridge Port Model ......................................19
Figure 5: TRILL Header ............................................21
Figure 6: Options Area Initial Flags Octet ........................26
Figure 7: TRILL Data Encapsulation over Ethernet ..................29
Figure 8: VLAN Tag Information ....................................30
Figure 9: TRILL IS-IS Frame Format ................................34
Figure 10: TRILL ESADI Frame Format ...............................41
Figure 11: Detailed RBridge Port Model ............................74
Figure 12: Link Cost of a Bridged Link ............................87
Figure 13: Wiring Closet Topology .................................89
Figure 14: Multi-Destination Multipath ............................93
Figure 15: Known Unicast Multipath ................................94
In traditional IPv4 and IPv6 networks, each subnet has a unique prefix. Therefore, a node in multiple subnets has multiple IP addresses, typically one per interface. This also means that when an interface moves from one subnet to another, it changes its IP address. Administration of IP networks is complicated because IP routers require per-port subnet address configuration. Careful IP address management is required to avoid creating subnets that are sparsely populated, wasting addresses.
在传统的IPv4和IPv6网络中，每个子网都有一个唯一的前缀。因此，多个子网中的节点具有多个IP地址，通常每个接口一个。这也意味着当接口从一个子网移动到另一个子网时，它会更改其IP地址。IP网络的管理很复杂，因为IP路由器需要每个端口的子网地址配置。需要仔细管理IP地址，以避免创建人口稀少的子网，从而浪费地址。
IEEE 802.1 bridges avoid these problems by transparently gluing many physical links into what appears to IP to be a single LAN [802.1D]. However, 802.1 bridge forwarding using the spanning tree protocol has some disadvantages:
IEEE 802.1网桥通过透明地将许多物理链路粘合到IP看来是单个LAN[802.1D]来避免这些问题。然而，使用生成树协议的802.1网桥转发有一些缺点：
o The spanning tree protocol works by blocking ports, limiting the number of forwarding links, and therefore creates bottlenecks by concentrating traffic onto selected links.
o 生成树协议的工作原理是阻塞端口，限制转发链路的数量，因此通过将流量集中到选定的链路上而产生瓶颈。
o Forwarding is not pair-wise shortest path, but is instead whatever path remains after the spanning tree eliminates redundant paths.
o 转发不是成对的最短路径，而是生成树消除冗余路径后剩余的任何路径。
o The Ethernet header does not contain a hop count (or Time to Live (TTL)) field. This is dangerous when there are temporary loops such as when spanning tree messages are lost or components such as repeaters are added.
o 以太网标头不包含跃点计数（或生存时间（TTL））字段。当存在临时循环时，如生成树消息丢失或添加了中继器等组件时，这是危险的。
o VLANs can partition when the spanning tree reconfigures.
o VLAN可以在生成树重新配置时进行分区。
This document presents the design for RBridges (Routing Bridges [RBridges]) that implement the TRILL protocol and are poetically summarized below. Rbridges combine the advantages of bridges and routers and, as specified in this document, are the application of link state routing to the VLAN-aware customer bridging problem. With the exceptions discussed in this document, RBridges can incrementally replace IEEE [802.1Q-2005] or [802.1D] customer bridges.
本文档介绍了实现TRILL协议的RBridges（路由桥[RBridges]）的设计，并在下文进行了诗意总结。Rbridges结合了网桥和路由器的优点，如本文所述，是链路状态路由在VLAN感知客户桥接问题中的应用。除本文件中讨论的例外情况外，RBridges可逐步取代IEEE[802.1Q-2005]或[802.1D]客户网桥。
While RBridges can be applied to a variety of link protocols, this specification focuses on IEEE [802.3] links. Use with other link types is expected to be covered in other documents.
虽然RBridges可以应用于各种链路协议，但本规范侧重于IEEE[802.3]链路。与其他链接类型一起使用预计将在其他文档中介绍。
The TRILL protocol, as specified herein, is designed to be a Local Area Network protocol and not designed with the goal of scaling beyond the size of existing bridged LANs. For further discussion of the problem domain addressed by RBridges, see [RFC5556].
如本文所述，TRILL协议被设计为局域网协议，而不是为了扩展到现有桥接lan的规模之外。有关RBridges解决的问题域的进一步讨论，请参阅[RFC5556]。
I hope that we shall one day see A graph more lovely than a tree.
我希望有一天我们能看到一幅比一棵树更可爱的图画。
A graph to boost efficiency While still configuration-free.
在无需配置的情况下提高效率的图表。
A network where RBridges can Route packets to their target LAN.
RBridge可以将数据包路由到其目标LAN的网络。
The paths they find, to our elation, Are least cost paths to destination!
令我们高兴的是，他们找到的道路是通往目的地的最省钱的道路！
With packet hop counts we now see, The network need not be loop-free!
根据我们现在看到的数据包跳数，网络不需要无环！
RBridges work transparently, Without a common spanning tree.
RBridges工作透明，没有公共生成树。
The bulk of the normative material in this specification appears in Sections 1 through 4. In case of conflict between provisions in these four sections, the provision in the higher numbered section prevails.
本规范中的大部分标准材料见第1节至第4节。如果这四节中的规定之间存在冲突，则以编号较高的一节中的规定为准。
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]中所述进行解释。
"TRILL" is the protocol specified herein while an "RBridge" is a device that implements that protocol. The second letter in Rbridge is case insensitive. Both Rbridge and RBridge are correct.
“TRILL”是此处指定的协议，“RBridge”是实现该协议的设备。Rbridge中的第二个字母不区分大小写。Rbridge和Rbridge都是正确的。
In this document, the term "link", unless otherwise qualified, means "bridged LAN", that is to say, the combination of one or more [802.3] links with zero or more bridges, hubs, repeaters, or the like. The term "simple link" or the like is used indicate a point-to-point or multi-access link with no included bridges or RBridges.
在本文件中，除非另有限定，否则术语“链路”指“桥接LAN”，即一个或多个[802.3]链路与零个或多个网桥、集线器、中继器等的组合。术语“简单链路”等用于表示不包括网桥或rbridge的点到点或多址链路。
In this document, the term "port", unless otherwise qualified, includes physical, virtual [802.1AE], and pseudo [802.1X] ports. The term "physical port" or the like is used to indicate the physical point of connection between an RBridge and a link.
在本文档中，除非另有限定，否则术语“端口”包括物理、虚拟[802.1AE]和伪[802.1X]端口。术语“物理端口”等用于指示RBridge和链路之间的物理连接点。
A "campus" is to RBridges as a "bridged LAN" is to bridges. An RBridge campus consists of a network of RBridges, bridges, hubs, repeaters, simple links, and the like and it is bounded by end stations and routers.
“校园”之于桥，“桥接LAN”之于桥。RBridge园区由RBridge、网桥、集线器、中继器、简单链路等组成的网络组成，由终端站和路由器限定。
The term "spanning tree" in this document includes both classic spanning tree and rapid spanning tree (as in the Rapid Spanning Tree Protocol).
本文档中的术语“生成树”包括经典生成树和快速生成树（如快速生成树协议）。
This document uses hexadecimal notation for MAC addresses. Two hexadecimal digits represent each octet (that is, 8-bit byte), giving the value of the octet as an unsigned integer. A hyphen separates successive octets. This document consistently uses IETF bit ordering, although the physical order of bit transmission within an octet on an IEEE [802.3] link is from the lowest order bit to the highest order bit, the reverse of IETF ordering.
本文档对MAC地址使用十六进制表示法。两个十六进制数字表示每个八位字节（即8位字节），将八位字节的值表示为无符号整数。连字符分隔连续的八位字节。本文件始终使用IETF位顺序，尽管IEEE[802.3]链路上八位字节内的位传输的物理顺序是从最低阶位到最高阶位，与IETF顺序相反。
In this document, Layer 2 frames are divided into five categories:
在本文档中，第2层框架分为五类：
o Layer 2 control frames (such as Bridge PDUs (BPDUs)) o native frames (non-TRILL-encapsulated data frames) o TRILL Data frames (TRILL-encapsulated data frames) o TRILL control frames o TRILL other frames
o 第2层控制帧（例如桥接PDU（BPDU））o本机帧（非颤音封装数据帧）o颤音数据帧（颤音封装数据帧）o颤音控制帧o颤音其他帧
The way these five types of frames are distinguished is as follows:
这五种框架的区别方式如下：
o Layer 2 control frames are those with a multicast destination address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or equal to 01-80-C2-00-00-21. RBridges MUST NOT encapsulate and forward such frames, though they MAY, unless otherwise specified in this document, perform the Layer 2 function (such as MAC-level security) of the control frame. Frames with a destination address of 01-80-C2-00-00-00 (BPDU) or 01-80-C2-00-00-21 (VLAN Registration Protocol) are called "high-level control frames" in this document. All other Layer 2 control frames are called "low-level control frames".
o 第2层控制帧是指多播目标地址范围在01-80-C2-00-00至01-80-C2-00-00-0F或等于01-80-C2-00-00-21的控制帧。RBridges不得封装和转发此类帧，但除非本文件另有规定，否则RBridges可执行控制帧的第2层功能（如MAC级安全性）。目标地址为01-80-C2-00-00（BPDU）或01-80-C2-00-00-21（VLAN注册协议）的帧在本文件中称为“高级控制帧”。所有其他第2层控制帧称为“低级控制帧”。
o Native frames are those that are not control frames and have an Ethertype other than "TRILL" or "L2-IS-IS" and have a destination MAC address that is not one of the 16 multicast addresses reserved for TRILL.
o 本机帧是指那些不是控制帧且具有除“TRILL”或“L2-IS-IS”以外的以太类型且具有不是为TRILL保留的16个多播地址之一的目标MAC地址的帧。
o TRILL Data frames have the Ethertype "TRILL". In addition, TRILL data frames, if multicast, have the multicast destination MAC address "All-RBridges".
o 颤音数据帧具有以太类型“颤音”。此外，如果是多播，TRILL数据帧具有多播目的地MAC地址“All rbridge”。
o TRILL control frames have the Ethertype "L2-IS-IS". In addition, TRILL control frames, if multicast, have the multicast destination MAC addresses of "All-IS-IS-RBridges". (Note that ESADI frames look on the outside like TRILL data and are so handled but, when decapsulated, have the L2-IS-IS Ethertype.)
o 颤音控制帧具有以太网类型“L2-IS-IS”。此外，如果是多播，TRILL控制帧的多播目标MAC地址为“All IS RBridges”。（请注意，ESADI帧在外观上类似于颤音数据，并且经过处理，但在解除封装后，具有L2-IS-IS以太网类型。）
o TRILL other frames are those with any of the 16 multicast destination addresses reserved for TRILL other than All-RBridges and All-IS-IS-RBridges. RBridges conformant to this specification MUST discard TRILL other frames.
o TRILL other帧是指那些具有为TRILL保留的16个多播目的地地址中的任意一个的帧，而不是所有RBridges和All IS RBridges。符合本规范的RBridges必须丢弃颤音其他帧。
AllL1ISs - All Level 1 Intermediate Systems
AllL1ISs-所有1级中间系统
AllL2ISs - All Level 2 Intermediate Systems
所有L2IS-所有2级中间系统
BPDU - Bridge PDU
桥PDU
CHbH - Critical Hop-by-Hop
CHbH-逐跳临界值
CItE - Critical Ingress-to-Egress
引用-从临界入口到出口
CSNP - Complete Sequence Number PDU
CSNP-完整序列号PDU
DA - Destination Address
DA-目的地址
DR - Designated Router
DR指定路由器
DRB - Designated RBridge
DRB-指定的RBridge
EAP - Extensible Authentication Protocol
可扩展认证协议
ECMP - Equal Cost Multipath
ECMP-等成本多路径
EISS - Extended Internal Sublayer Service
EISS-扩展内部子层服务
ESADI - End-Station Address Distribution Information
ESADI-端站地址分布信息
FCS - Frame Check Sequence
FCS-帧检查序列
GARP - Generic Attribute Registration Protocol
通用属性注册协议
GVRP - GARP VLAN Registration Protocol
GVRP-GARP VLAN注册协议
IEEE - Institute of Electrical and Electronics Engineers
IEEE-电气和电子工程师学会
IGMP - Internet Group Management Protocol
因特网组管理协议
IP - Internet Protocol
IP-Internet协议
IS-IS - Intermediate System to Intermediate System
IS-IS-中间系统至中间系统
ISS - Internal Sublayer Service
ISS-内部子层服务
LAN - Local Area Network
局域网
LSP - Link State PDU
LSP-链路状态PDU
MAC - Media Access Control
媒体访问控制
MLD - Multicast Listener Discovery
多播侦听器发现
MRD - Multicast Router Discovery
多播路由器发现
MTU - Maximum Transmission Unit
最大传输单位
MVRP - Multiple VLAN Registration Protocol
MVRP-多VLAN注册协议
NSAP - Network Service Access Point
NSAP-网络服务接入点
P2P - Point-to-point
点对点
PDU - Protocol Data Unit
协议数据单元
PPP - Point-to-Point Protocol
点对点协议
RBridge - Routing Bridge
RBridge-路由桥
RPF - Reverse Path Forwarding
反向路径转发
SA - Source Address
SA-源地址
SNMP - Simple Network Management Protocol
简单网络管理协议
SPF - Shortest Path First
SPF-最短路径优先
TLV - Type, Length, Value
TLV-类型、长度、值
TRILL - TRansparent Interconnection of Lots of Links
TRILL-大量链路的透明互连
VLAN - Virtual Local Area Network
虚拟局域网
VRP - VLAN Registration Protocol
VRP-VLAN注册协议
This section provides a high-level overview of RBridges, which implement the TRILL protocol, omitting some details. Sections 3 and 4 below provide more detailed specifications.
本节提供了RBridges的高级概述，RBridges实现了TRILL协议，省略了一些细节。下文第3节和第4节提供了更详细的规范。
TRILL, as described in this document and with the exceptions discussed herein, provides [802.1Q-2005] VLAN-aware customer bridging service. As described below, TRILL is layered above the ports of an RBridge.
如本文档所述，除本文讨论的例外情况外，TRILL提供[802.1Q-2005]支持VLAN的客户桥接服务。如下所述，TRILL在RBridge的端口上方分层。
The RBridges specified by this document do not supply provider [802.1ad] or provider backbone [802.1ah] bridging or the like. The extension of TRILL to provide such provider services is left for future work that will be separately documented. However, provider or provider backbone bridges may be used to interconnect parts of an RBridge campus.
本文件规定的RBridge不提供提供商[802.1ad]或提供商主干[802.1ah]桥接等。TRILL提供此类提供商服务的扩展将留待将来的工作，这些工作将另行记录。然而，提供者或提供者主干网桥可用于互连RBridge园区的部分。
RBridges run a link state protocol amongst themselves. This gives them enough information to compute pair-wise optimal paths for unicast, and calculate distribution trees for delivery of frames either to destinations whose location is unknown or to multicast/broadcast groups [RBridges] [RP1999].
RBridge在它们之间运行链路状态协议。这为他们提供了足够的信息来计算单播的成对最优路径，并计算分发树，以便将帧传送到位置未知的目的地或多播/广播组[RBridges][RP1999]。
To mitigate temporary loop issues, RBridges forward based on a header with a hop count. RBridges also specify the next hop RBridge as the frame destination when forwarding unicast frames across a shared-media link, which avoids spawning additional copies of frames during a temporary loop. A Reverse Path Forwarding Check and other checks are performed on multi-destination frames to further control potentially looping traffic (see Section 4.5.2).
为了缓解临时循环问题，RBridges基于具有跳数的报头进行转发。在通过共享媒体链路转发单播帧时，RBridge还将下一跳RBridge指定为帧目标，这样可以避免在临时循环期间产生额外的帧副本。对多目标帧执行反向路径转发检查和其他检查，以进一步控制潜在的循环流量（见第4.5.2节）。
The first RBridge that a unicast frame encounters in a campus, RB1, encapsulates the received frame with a TRILL header that specifies the last RBridge, RB2, where the frame is decapsulated. RB1 is known as the "ingress RBridge" and RB2 is known as the "egress RBridge". To save room in the TRILL header and simplify forwarding lookups, a dynamic nickname acquisition protocol is run among the RBridges to select 2-octet nicknames for RBridges, unique within the campus, which are an abbreviation for the IS-IS ID of the RBridge. The 2-octet nicknames are used to specify the ingress and egress RBridges in the TRILL header.
单播帧在校园中遇到的第一个RBridge RB1用TRILL报头封装接收到的帧，TRILL报头指定最后一个RBridge RB2，其中该帧被解除封装。RB1被称为“入口RBridge”，RB2被称为“出口RBridge”。为了在TRILL报头中节省空间并简化转发查找，在RBridge之间运行动态昵称获取协议，为RBridge选择2个八位组昵称，在校园内是唯一的，是RBridge的is-is ID的缩写。2-octet昵称用于指定TRILL报头中的入口和出口RBridges。
Multipathing of multi-destination frames through alternative distribution trees and ECMP (Equal Cost Multipath) of unicast frames are supported (see Appendix C).
支持通过备用分布树和单播帧的ECMP（等成本多路径）实现多目标帧的多路径传输（见附录C）。
Networks with a more mesh-like structure will benefit to a greater extent from the multipathing and optimal paths provided by TRILL than will more tree-like networks.
与更多树状网络相比，具有更网状结构的网络将在更大程度上受益于TRILL提供的多路径和最佳路径。
RBridges run a protocol on a link to elect a "Designated RBridge" (DRB). The TRILL-IS-IS election protocol on a link is a little different from the Layer 3 IS-IS [ISO10589] election protocol, because in TRILL it is essential that only one RBridge be elected DRB, whereas in Layer 3 IS-IS it is possible for multiple routers to be elected Designated Router (also known as Designated Intermediate System). As with an IS-IS router, the DRB may give a pseudonode name to the link, issue an LSP (Link State PDU) on behalf of the pseudonode, and issues CSNPs (Complete Sequence Number PDUs) on the link. Additionally, the DRB has some TRILL-specific duties, including specifying which VLAN will be the Designated VLAN used for communication between RBridges on that link (see Section 4.2.4.2).
RBridge在链路上运行协议以选择“指定RBridge”（DRB）。链路上的TRILL-IS-IS选举协议与第3层IS-IS[ISO10589]选举协议略有不同，因为在TRILL中，只有一个RBridge被选为DRB是至关重要的，而在第3层IS-IS中，多个路由器可以被选为指定路由器（也称为指定中间系统）。与IS-IS路由器一样，DRB可以向链路提供伪节点名称，代表伪节点发出LSP（链路状态PDU），并在链路上发出CSNPs（完整序列号PDU）。此外，DRB有一些特定于TRILL的职责，包括指定哪个VLAN将是用于该链路上RBridge之间通信的指定VLAN（参见第4.2.4.2节）。
The DRB either encapsulates/decapsulates all data traffic to/from the link, or, for load splitting, delegates this responsibility, for one or more VLANs, to other RBridges on the link. There must at all times be at most one RBridge on the link that encapsulates/decapsulates traffic for a particular VLAN. We will refer to the RBridge appointed to forward VLAN-x traffic on behalf of the link as the "appointed VLAN-x forwarder" (see Section 4.2.4.3). (Section 2.5 discusses VLANs further.)
DRB封装/解除封装所有进出链路的数据通信，或者，对于负载拆分，将一个或多个VLAN的此职责委托给链路上的其他RBridge。链路上必须始终最多有一个RBridge，用于封装/解除封装特定VLAN的流量。我们将指定代表链路转发VLAN-x流量的RBridge称为“指定VLAN-x转发器”（见第4.2.4.3节）。（第2.5节将进一步讨论VLAN。）
Rbridges SHOULD support SNMPv3 [RFC3411]. The Rbridge MIB will be specified in a separate document. If IP service is available to an RBridge, it SHOULD support SNMPv3 over UDP over IPv4 [RFC3417] and IPv6 [RFC3419]; however, management can be used, within a campus, even for an RBridge that lacks an IP or other Layer 3 transport stack or which does not have a Layer 3 address, by transporting SNMP with Ethernet [RFC4789].
Rbridges应支持SNMPv3[RFC3411]。Rbridge MIB将在单独的文件中指定。如果RBridge可以使用IP服务，它应该支持通过IPv4[RFC3417]和IPv6[RFC3419]通过UDP的SNMPv3；但是，通过使用以太网传输SNMP，即使对于缺少IP或其他第3层传输堆栈或没有第3层地址的RBridge，也可以在校园内使用管理[RFC4789]。
An RBridge, RB1, that is the VLAN-x forwarder on any of its links MUST learn the location of VLAN-x end nodes, both on the links for which it is VLAN-x forwarder and on other links in the campus. RB1 learns the port, VLAN, and Layer 2 (MAC) addresses of end nodes on links for which it is VLAN-x forwarder from the source address of frames received, as bridges do (for example, see Section 8.7 of [802.1Q-2005]), or through configuration or a Layer 2 explicit registration protocol such as IEEE 802.11 association and authentication. RB1 learns the VLAN and Layer 2 address of distant VLAN-x end nodes, and the corresponding RBridge to which they are
RBridge，RB1，即其任何链路上的VLAN-x转发器，必须了解VLAN-x端节点的位置，无论是在其作为VLAN-x转发器的链路上还是在校园中的其他链路上。RB1从接收到的帧的源地址（例如，请参见[802.1Q-2005]第8.7节）或通过配置或第2层显式注册协议（如IEEE 802.11关联和身份验证）学习作为VLAN-x转发器的链路上终端节点的端口、VLAN和第2层（MAC）地址。RB1学习远程VLAN-x端节点的VLAN和第2层地址，以及它们所在的相应RBridge
attached, by looking at the ingress RBridge nickname in the TRILL header and the VLAN and source MAC address of the inner frame of TRILL Data frames that it decapsulates.
附件，通过查看TRILL标头中的入口RBridge昵称以及它解除封装的TRILL数据帧内部帧的VLAN和源MAC地址。
Additionally, an RBridge that is the appointed VLAN-x forwarder on one or more links MAY use the End-Station Address Distribution Information (ESADI) protocol to announce some or all of the attached VLAN-x end nodes on those links.
此外，作为一个或多个链路上的指定VLAN-x转发器的RBridge可以使用端站地址分布信息（ESADI）协议来宣布这些链路上的一些或所有连接的VLAN-x端节点。
The ESADI protocol could be used to announce end nodes that have been explicitly enrolled. Such information might be more authoritative than that learned from data frames being decapsulated onto the link. Also, the addresses enrolled and distributed in this way can be more secure for two reasons: (1) the enrollment might be authenticated (for example, by cryptographically based EAP methods via [802.1X]), and (2) the ESADI protocol also supports cryptographic authentication of its messages [RFC5304] [RFC5310] for more secure transmission.
ESADI协议可用于宣布已显式注册的终端节点。这样的信息可能比从被解封到链路上的数据帧中获得的信息更具权威性。此外，以这种方式注册和分发的地址可以更安全，原因有两个：（1）注册可以进行身份验证（例如，通过基于密码的EAP方法通过[802.1X]），以及（2）ESADI协议还支持对其消息[RFC5304][RFC5310]进行密码验证，以实现更安全的传输。
If an end station is unplugged from one RBridge and plugged into another, then, depending on circumstances, frames addressed to that end station can be black-holed. That is, they can be sent just to the older RBridge that the end station used to be connected to until cached address information at some remote RBridge(s) times out, possibly for a number of minutes or longer. With the ESADI protocol, the link interruption from the unplugging can cause an immediate update to be sent.
如果一个终端站从一个RBridge上拔下并插入另一个RBridge，那么，根据具体情况，寻址到该终端站的帧可以是黑孔。也就是说，在某些远程RBridge的缓存地址信息超时之前，它们可以只发送到终端站曾经连接到的旧RBridge，可能会持续几分钟或更长时间。使用ESADI协议，由于拔出导致的链路中断可导致立即发送更新。
Even if the ESADI protocol is used to announce or learn attached end nodes, RBridges MUST still learn from received native frames and decapsulated TRILL Data frames unless configured not to do so. Advertising end nodes using ESADI is optional, as is learning from these announcements.
即使ESADI协议用于宣布或学习连接的终端节点，RBridge仍必须从接收的本机帧和解除封装的TRILL数据帧中学习，除非配置为不这样做。使用ESADI发布终端节点广告是可选的，从这些公告中可以了解到这一点。
(See Section 4.8 for further end-station address details.)
（更多端站地址详情，请参见第4.8节。）
The Layer 2 technology used to connect Rbridges may be either IEEE [802.3] or some other link technology such as PPP [RFC1661]. This is possible since the RBridge relay function is layered on top of the Layer 2 technologies. However, this document specifies only an IEEE 802.3 encapsulation.
用于连接RBridge的第2层技术可以是IEEE[802.3]或一些其他链路技术，例如PPP[RFC1661]。这是可能的，因为RBridge中继功能是在第2层技术之上分层的。但是，本文件仅规定了IEEE 802.3封装。
Figure 1 shows two RBridges, RB1 and RB2, interconnected through an Ethernet cloud. The Ethernet cloud may include hubs, point-to-point or shared media, IEEE 802.1D bridges, or 802.1Q bridges.
图1显示了两个RBridge，RB1和RB2，通过以太网云互连。以太网云可能包括集线器、点对点或共享媒体、IEEE 802.1D网桥或802.1Q网桥。
------------
/ \
+-----+ / Ethernet \ +-----+
| RB1 |----< >---| RB2 |
+-----+ \ Cloud / +-----+
\ /
------------
------------
/ \
+-----+ / Ethernet \ +-----+
| RB1 |----< >---| RB2 |
+-----+ \ Cloud / +-----+
\ /
------------
Figure 1: Interconnected RBridges
图1：互连的RBR桥
Figure 2 shows the format of a TRILL data or ESADI frame traveling through the Ethernet cloud between RB1 and RB2.
图2显示了在RB1和RB2之间通过以太网云传输的TRILL数据或ESADI帧的格式。
+--------------------------------+
| Outer Ethernet Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
+--------------------------------+
| Outer Ethernet Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
Figure 2: An Ethernet Encapsulated TRILL Frame
图2：以太网封装的颤音帧
In the case of media different from Ethernet, the header specific to that media replaces the outer Ethernet header. For example, Figure 3 shows a TRILL encapsulation over PPP.
如果介质不同于以太网，则特定于该介质的报头将替换外部以太网报头。例如，图3显示了PPP上的TRILL封装。
+--------------------------------+
| PPP Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| PPP FCS |
+--------------------------------+
+--------------------------------+
| PPP Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| PPP FCS |
+--------------------------------+
Figure 3: A PPP Encapsulated TRILL Frame
图3:PPP封装的颤音帧
The outer header is link-specific and, although this document specifies only [802.3] links, other links are allowed.
外部标头是特定于链路的，尽管本文档仅指定了[802.3]链路，但允许使用其他链路。
In both cases, the inner Ethernet header and the Ethernet Payload come from the original frame and are encapsulated with a TRILL header as they travel between RBridges. Use of a TRILL header offers the following benefits:
在这两种情况下，内部以太网报头和以太网有效负载来自原始帧，并在它们在RBridge之间移动时用颤音报头封装。使用颤音标题有以下好处：
1. loop mitigation through use of a hop count field;
1. 通过使用跃点计数字段来缓解循环；
2. elimination of the need for end-station VLAN and MAC address learning in transit RBridges;
2. 无需在传输过程中学习终端站VLAN和MAC地址；
3. direction of unicast frames towards the egress RBridge (this enables unicast forwarding tables of transit RBridges to be sized with the number of RBridges rather than the total number of end nodes); and
3. 单播帧朝向出口RBridge的方向（这使得使用RBridge的数量而不是终端节点的总数来调整中转RBridge的单播转发表的大小）；和
4. provision of a separate VLAN tag for forwarding traffic between RBridges, independent of the VLAN of the native frame.
4. 提供一个单独的VLAN标签，用于在RBridge之间转发流量，独立于本机帧的VLAN。
When forwarding unicast frames between RBridges, the outer header has the MAC destination address of the next hop Rbridge, to avoid frame duplication if the inter-RBridge link is multi-access. This also enables multipathing of unicast, since the transmitting RBridge can specify the next hop. Having the outer header specify the transmitting RBridge as the source address ensures that any bridges inside the Ethernet cloud will not get confused, as they might be if multipathing is in use and they were to see the original source or ingress RBridge in the outer header.
当在Rbridge之间转发单播帧时，外部报头具有下一跳Rbridge的MAC目的地地址，以避免在Rbridge间链路为多址时出现帧重复。这也支持单播的多路径传输，因为传输RBridge可以指定下一跳。让外部报头将传输RBridge指定为源地址可确保以太网云中的任何网桥都不会混淆，因为如果使用多路径，并且它们将在外部报头中看到原始源或入口RBridge，则可能会混淆。
RBridges are true routers in the sense that, in the forwarding of a frame by a transit RBridge, the outer Layer 2 header is replaced at each hop with an appropriate Layer 2 header for the next hop, and a hop count is decreased. Despite these modifications of the outer Layer 2 header and the hop count in the TRILL header, the original encapsulated frame is preserved, including the original frame's VLAN tag. See Section 4.6 for more details.
RBridge是真正的路由器，因为在通过transit RBridge转发帧的过程中，外层2报头在每个跃点处被替换为下一跳的适当层2报头，并且跳数减少。尽管对外层2报头和TRILL报头中的跃点计数进行了这些修改，原始封装帧仍被保留，包括原始帧的VLAN标记。详见第4.6节。
From a forwarding standpoint, transit frames may be classified into two categories: known-unicast and multi-destination. Layer 2 control frames and TRILL control and TRILL other frames are not transit frames, are not forwarded by RBridges, and are not included in these categories.
从转发的角度来看，传输帧可分为两类：已知单播和多目的地。第2层控制帧和颤音控制以及颤音其他帧不是传输帧，不由RBridges转发，不包括在这些类别中。
These frames have a unicast inner MAC destination address (Inner.MacDA) and are those for which the ingress RBridge knows the egress RBridge for the destination MAC address in the frame's VLAN.
这些帧具有单播内部MAC目标地址（inner.MacDA），并且是入口RBridge知道帧VLAN中目标MAC地址的出口RBridge的帧。
Such frames are forwarded Rbridge hop by Rbridge hop to their egress Rbridge.
这样的帧被Rbridge-hop逐Rbridge-hop转发到它们的出口Rbridge。
These are frames that must be delivered to multiple destinations.
这些帧必须传送到多个目的地。
Multi-destination frames include the following:
多目标帧包括以下内容：
1. unicast frames for which the location of the destination is unknown: the Inner.MacDA is unicast, but the ingress RBridge does not know its location in the frame's VLAN.
1. 目标位置未知的单播帧：Inner.MacDA是单播的，但入口RBridge不知道其在帧的VLAN中的位置。
2. multicast frames for which the Layer 2 destination address is derived from an IP multicast address: the Inner.MacDA is multicast, from the set of Layer 2 multicast addresses derived from IPv4 [RFC1112] or IPv6 [RFC2464] multicast addresses. These frames are handled somewhat differently in different subcases:
2. 层2目标地址从IP多播地址派生的多播帧：Inner.MacDA是多播，来自从IPv4[RFC1112]或IPv6[RFC2464]多播地址派生的层2多播地址集。这些帧在不同子类别中的处理方式有所不同：
2.1. IGMP [RFC3376] and MLD [RFC2710] multicast group membership reports
2.1. IGMP[RFC3376]和MLD[RFC2710]多播组成员资格报告
2.2. IGMP [RFC3376] and MLD [RFC2710] queries and MRD [RFC4286] announcement messages
2.2. IGMP[RFC3376]和MLD[RFC2710]查询和MRD[RFC4286]公告消息
2.3. other IP-derived Layer 2 multicast frames
2.3. 其他IP派生的第2层多播帧
3. multicast frames for which the Layer 2 destination address is not derived from an IP multicast address: the Inner.MacDA is multicast, and not from the set of Layer 2 multicast addresses derived from IPv4 or IPv6 multicast addresses.
3. 第2层目标地址不是从IP多播地址派生的多播帧：Inner.MacDA是多播，而不是从IPv4或IPv6多播地址派生的第2层多播地址集。
4. broadcast frames: the Inner.MacDA is broadcast (FF-FF-FF-FF-FF-FF).
4. 广播帧：内部.MacDA被广播（FF-FF-FF-FF-FF-FF）。
RBridges build distribution trees (see Section 4.5) and use these trees for forwarding multi-destination frames. Each distribution tree reaches all RBridges in the campus, is shared across all VLANs, and may be used for the distribution of a native frame that is in any VLAN. However, the distribution of any particular frame on a distribution tree is pruned in different ways for different cases to avoid unnecessary propagation of the frame.
RBridges构建分发树（见第4.5节），并使用这些树转发多目标帧。每个分发树到达校园中的所有RBridge，在所有VLAN中共享，并可用于分发任何VLAN中的本机帧。然而，分布树上任何特定帧的分布在不同的情况下以不同的方式进行修剪，以避免不必要的帧传播。
A VLAN is a way to partition end nodes in a campus into different Layer 2 communities [802.1Q-2005]. Use of VLANs requires configuration. By default, the port of receipt determines the VLAN of a frame sent by an end station. End stations can also explicitly insert this information in a frame.
VLAN是将校园中的终端节点划分为不同的第2层社区的一种方法[802.1Q-2005]。VLAN的使用需要配置。默认情况下，接收端口确定终端站发送的帧的VLAN。端点桩号还可以在帧中显式插入此信息。
IEEE [802.1Q-2005] bridges can be configured to support multiple customer VLANs over a single simple link by inserting/removing a VLAN tag in the frame. VLAN tags used by TRILL have the same format as VLAN tags defined in IEEE [802.1Q-2005]. As shown in Figure 2, there are two places where such tags may be present in a TRILL-encapsulated frame sent over an IEEE [802.3] link: one in the outer header (Outer.VLAN) and one in the inner header (Inner.VLAN). Inner and outer VLANs are further discussed in Section 4.1.
IEEE[802.1Q-2005]网桥可通过在帧中插入/移除VLAN标记，配置为通过单个简单链路支持多个客户VLAN。TRILL使用的VLAN标记的格式与IEEE[802.1Q-2005]中定义的VLAN标记的格式相同。如图2所示，在通过IEEE[802.3]链路发送的TRILL封装帧中，有两个位置可能存在这样的标记：一个在外部报头（outer.VLAN）中，另一个在内部报头（inner.VLAN）中。第4.1节将进一步讨论内部和外部VLAN。
RBridges enforce delivery of a native frame originating in a particular VLAN only to other links in the same VLAN; however, there are a few differences in the handling of VLANs between an RBridge campus and an 802.1 bridged LAN as described below.
RBridges强制将源自特定VLAN的本机帧仅传送到同一VLAN中的其他链路；然而，如下文所述，RBridge园区和802.1桥接LAN之间的VLAN处理存在一些差异。
(See Section 4.2.4 for further discussion of TRILL IS-IS operation on a link.)
（有关链接上颤音IS-IS操作的进一步讨论，请参见第4.2.4节。）
Certain configurations of bridges may cause partitions of a VLAN on a link. For such configurations, a frame sent by one RBridge to a neighbor on that link might not arrive, if tagged with a VLAN that is partitioned due to bridge configuration.
网桥的某些配置可能导致链路上VLAN的分区。对于这种配置，如果使用由于网桥配置而分区的VLAN进行标记，则由一个RBridge发送给该链路上的邻居的帧可能不会到达。
TRILL requires at least one VLAN per link that gives full connectivity to all the RBridges on that link. The default VLAN is 1, though RBridges may be configured to use a different VLAN. The DRB dictates to the other RBridges which VLAN to use.
TRILL要求每条链路至少有一个VLAN，以提供与该链路上所有RBridge的完全连接。默认VLAN为1，但RBridges可以配置为使用不同的VLAN。DRB向其他RBB指示要使用哪个VLAN。
Since there will be only one appointed forwarder for any VLAN, say, VLAN-x, on a link, if bridges are configured to cause VLAN-x to be partitioned on a link, some VLAN-x end nodes on that link may be orphaned (unable to communicate with the rest of the campus).
由于链路上的任何VLAN（例如VLAN-x）只有一个指定的转发器，如果网桥配置为在链路上对VLAN-x进行分区，则该链路上的一些VLAN-x端节点可能会成为孤立节点（无法与校园的其余部分通信）。
It is possible for bridge and port configuration to cause VLAN mapping on a link (where a VLAN-x frame turns into a VLAN-y frame). TRILL detects this by inserting a copy of the outer VLAN into TRILL-Hello messages and checking it on receipt. If detected, it takes
网桥和端口配置可能导致链路上的VLAN映射（其中VLAN-x帧转换为VLAN-y帧）。TRILL通过在TRILL Hello消息中插入外部VLAN的副本并在收到时检查来检测这一点。如果检测到，则需要
steps to ensure that there is at most a single appointed forwarder on the link, to avoid possible frame duplication or loops (see Section 4.4.5).
确保链路上最多有一个指定转发器的步骤，以避免可能的帧复制或循环（见第4.4.5节）。
TRILL behaves as conservatively as possible, avoiding loops rather than avoiding partial connectivity. As a result, lack of connectivity may result from bridge or port misconfiguration.
TRILL的行为尽可能保守，避免循环，而不是避免部分连接。因此，网桥或端口配置错误可能导致连接不足。
RBridge ports are, except as described below, layered on top of IEEE [802.1Q-2005] port facilities.
RBridge端口（如下所述除外）分层在IEEE[802.1Q-2005]端口设施之上。
RBridge ports make use of [802.1Q-2005] port VLAN and priority processing. In addition, they MAY implement other lower-level 802.1 protocols as well as protocols for the link in use, such as PAUSE (Annex 31B of [802.3]), port-based access control [802.1X], MAC security [802.1AE], or link aggregation [802.1AX].
RBridge端口利用[802.1Q-2005]端口VLAN和优先级处理。此外，它们可以实现其他较低级别的802.1协议以及用于正在使用的链路的协议，例如暂停（802.3的附录31B）、基于端口的访问控制[802.1X]、MAC安全[802.1AE]或链路聚合[802.1AX]。
However, RBridges do not use spanning tree and do not block ports as spanning tree does. Figure 4 shows a high-level diagram of an RBridge with one port connected to an IEEE 802.3 link. Single lines represent the flow of control information, double lines the flow of both frames and control information.
但是，RBridges不使用生成树，也不像生成树那样阻塞端口。图4显示了一个RBridge的高级图，其中一个端口连接到IEEE 802.3链路。单线表示控制信息流，双线表示帧和控制信息流。
+-----------------------------------------
| RBridge
|
| Forwarding Engine, IS-IS, etc.
| Processing of native and TRILL frames
|
+----+---+--------++----------------------
| | || other ports...
+-------------+ | ||
| | ||
+------------+-------------+ | ||
| RBridge | | +----++-------+ <- EISS
| | | | |
| High-Level Control Frame | | | 802.1Q-2005 |
| Processing (BPDU, VRP) | | | Port VLAN |
| | | | & Priority |
+-----------++-------------+ | | Processing |
|| | | |
+---------++-----------------+---+-------------+ <-- ISS
| |
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
| |
+-----------++---------------------------------+
||
|| +------------+
|| | 802.3 PHY |
|+--------+ (Physical +--------- 802.3
+---------+ Interface) +--------- Link
| |
+------------+
+-----------------------------------------
| RBridge
|
| Forwarding Engine, IS-IS, etc.
| Processing of native and TRILL frames
|
+----+---+--------++----------------------
| | || other ports...
+-------------+ | ||
| | ||
+------------+-------------+ | ||
| RBridge | | +----++-------+ <- EISS
| | | | |
| High-Level Control Frame | | | 802.1Q-2005 |
| Processing (BPDU, VRP) | | | Port VLAN |
| | | | & Priority |
+-----------++-------------+ | | Processing |
|| | | |
+---------++-----------------+---+-------------+ <-- ISS
| |
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
| |
+-----------++---------------------------------+
||
|| +------------+
|| | 802.3 PHY |
|+--------+ (Physical +--------- 802.3
+---------+ Interface) +--------- Link
| |
+------------+
Figure 4: RBridge Port Model
图4:RBridge端口模型
The upper interface to the low-level port/link control logic corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005]. In RBridges, high-level control frames are processed above the ISS interface.
低级端口/链路控制逻辑的上层接口对应于[802.1Q-2005]中的内部子层服务（ISS）。在RBridges中，高级控制帧在ISS接口上方处理。
The upper interface to the port VLAN and priority processing corresponds to the Extended Internal Sublayer Service (EISS) in [802.1Q-2005]. In RBridges, native and TRILL frames are processed above the EISS interface and are subject to port VLAN and priority processing.
端口VLAN和优先级处理的上层接口对应于[802.1Q-2005]中的扩展内部子层服务（EISS）。在RBridges中，本机帧和TRILL帧在EIS接口上进行处理，并接受端口VLAN和优先级处理。
Because RBridges are compatible with IEEE [802.1Q-2005] customer bridges, except as discussed in this document, a bridged LAN can be upgraded by incrementally replacing such bridges with RBridges. Bridges that have not yet been replaced are transparent to RBridge traffic. The physical links directly interconnected by such bridges, together with the bridges themselves, constitute bridged LANs. These bridged LANs appear to RBridges to be multi-access links.
由于RBridges与IEEE[802.1Q-2005]客户网桥兼容，因此，除了本文档中讨论的以外，可以通过使用RBridges增量替换此类网桥来升级桥接LAN。尚未更换的桥梁对RBridge交通是透明的。由这些网桥直接互连的物理链路与网桥本身一起构成桥接LAN。这些桥接LAN看起来是多址链路。
If the bridges replaced by RBridges were default configuration bridges, then their RBridge replacements will not require configuration.
如果由RBridge替换的网桥是默认配置网桥，那么它们的RBridge替换将不需要配置。
Because RBridges, as described in this document, only provide customer services, they cannot replace provider bridges or provider backbone bridges, just as a customer bridge can't replace a provider bridge. However, such provider devices can be part of the bridged LAN between RBridges. Extension of TRILL to support provider services is left for future work and will be separately documented.
由于本文档中所述的RBridge仅提供客户服务，因此它们不能取代提供商网桥或提供商主干网桥，正如客户网桥不能取代提供商网桥一样。但是，此类提供商设备可以是RBridge之间桥接LAN的一部分。TRILL对支持提供商服务的扩展留待将来的工作进行，并将单独记录。
Of course, if the bridges replaced had any port level protocols enabled, such as port-based access control [802.1X] or MAC security [802.1AE], replacement RBridges would need the same port level protocols enabled and similarly configured. In addition, the replacement RBridges would have to support the same link type and link level protocols as the replaced bridges.
当然，如果更换的网桥启用了任何端口级协议，例如基于端口的访问控制[802.1X]或MAC安全[802.1AE]，则更换的网桥将需要启用相同的端口级协议并进行类似配置。此外，替换RBridge必须支持与替换网桥相同的链路类型和链路级协议。
An RBridge campus will work best if all IEEE [802.1D] and [802.1Q-2005] bridges are replaced with RBridges, assuming the RBridges have the same speed and capacity as the bridges. However, there may be intermediate states, where only some bridges have been replaced by RBridges, with inferior performance.
如果将所有IEEE[802.1D]和[802.1Q-2005]网桥替换为RBridges，则RBridge校园将运行得最好，前提是RBridges的速度和容量与网桥相同。然而，可能存在中间状态，其中只有一些桥梁被RBridges取代，性能较差。
See Appendix A for further discussion of incremental deployment.
有关增量部署的进一步讨论，请参见附录A。
This section specifies the TRILL header. Section 4 below provides other RBridge design details.
本节指定颤音标题。下文第4节提供了RBridge的其他设计细节。
The TRILL header is shown in Figure 5 and is independent of the data link layer used. When that layer is IEEE [802.3], it is prefixed with the 16-bit TRILL Ethertype [RFC5342], making it 64-bit aligned. If Op-Length is a multiple of 64 bits, then 64-bit alignment is normally maintained for the content of an encapsulated frame.
TRILL报头如图5所示，与所使用的数据链路层无关。当该层为IEEE[802.3]时，它的前缀为16位TRILL Ethertype[RFC5342]，使其与64位对齐。如果Op Length是64位的倍数，则封装帧的内容通常保持64位对齐。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: TRILL Header
图5：颤音标题
The header contains the following fields that are described in the sections referenced:
标题包含参考章节中描述的以下字段：
o V (Version): 2-bit unsigned integer. See Section 3.2.
o V（版本）：2位无符号整数。见第3.2节。
o R (Reserved): 2 bits. See Section 3.3.
o R（保留）：2位。见第3.3节。
o M (Multi-destination): 1 bit. See Section 3.4.
o M（多目标）：1位。见第3.4节。
o Op-Length (Options Length): 5-bit unsigned integer. See Section 3.5.
o 运算长度（选项长度）：5位无符号整数。见第3.5节。
o Hop Count: 6-bit unsigned integer. See Section 3.6.
o 跃点计数：6位无符号整数。见第3.6节。
o Egress RBridge Nickname: 16-bit identifier. See Section 3.7.1.
o 出口RBridge昵称：16位标识符。见第3.7.1节。
o Ingress RBridge Nickname: 16-bit identifier. See Section 3.7.2.
o 入口RBridge昵称：16位标识符。见第3.7.2节。
o Options: present if Op-Length is non-zero. See Section 3.8.
o 选项：如果Op长度非零，则显示。见第3.8节。
Version (V) is a 2-bit field. Version zero of TRILL is specified in this document. An RBridge RB1 MUST check the V field in a received TRILL-encapsulated frame. If the V field has a value not recognized by RB1, then RB1 MUST silently discard the frame. The allocation of new TRILL Version numbers requires an IETF Standards Action.
版本（V）是一个2位字段。本文件中规定了TRILL的零版本。RBridge RB1必须检查接收到的颤音封装帧中的V字段。如果V字段具有RB1无法识别的值，则RB1必须以静默方式放弃该帧。新TRILL版本号的分配需要IETF标准行动。
The two R bits are reserved for future use in extensions to this version zero of the TRILL protocol. They MUST be set to zero when the TRILL header is added by an ingress RBridge, transparently copied but otherwise ignored by transit RBridges, and ignored by egress RBridges. The allocation of reserved TRILL header bits requires an IETF Standards Action.
这两个R位保留供将来在TRILL协议零版本的扩展中使用。当TRILL标头由入口RBridge添加时，它们必须设置为零，透明复制，但被传输RBridges忽略，并被出口RBridges忽略。保留TRILL头比特的分配需要IETF标准操作。
The Multi-destination bit (see Section 2.4.2) indicates that the frame is to be delivered to a class of destination end stations via a distribution tree and that the egress RBridge nickname field specifies this tree. In particular:
多目的地比特（见第2.4.2节）表示帧将通过分发树传送到一类目的地终端站，并且出口RBridge昵称字段指定了该树。特别地：
o M = 0 (FALSE) - The egress RBridge nickname contains a nickname of the egress Rbridge for a known unicast MAC address.
o M=0（FALSE）-出口RBridge昵称包含已知单播MAC地址的出口RBridge昵称。
o M = 1 (TRUE) - The egress RBridge nickname field contains a nickname that specifies a distribution tree. This nickname is selected by the ingress RBridge for a TRILL Data frame or by the source RBridge for a TRILL ESADI frame.
o M=1（TRUE）-出口RBridge昵称字段包含指定分发树的昵称。该昵称由入口RBridge为TRILL数据帧选择，或由源RBridge为TRILL ESADI帧选择。
There are provisions to express in the TRILL header that a frame is using an optional capability and to encode information into the header in connection with that capability.
有一些规定可以在颤音报头中表示帧正在使用可选功能，并将信息编码到与该功能相关的报头中。
The Op-Length header field gives the length of the TRILL header options in units of 4 octets, which allows up to 124 octets of options area. If Op-Length is zero, there are no options present. If options are present, they follow immediately after the Ingress Rbridge Nickname field.
Op Length header（操作长度标题）字段以4个八位字节为单位给出颤音标题选项的长度，允许最多124个八位字节的选项区域。如果Op Length为零，则不存在任何选项。如果存在选项，它们紧跟在Ingress Rbridge昵称字段之后。
See Section 3.8 for more information on TRILL header options.
有关颤音标题选项的更多信息，请参见第3.8节。
The Hop Count field is a 6-bit unsigned integer. An Rbridge drops frames received with a hop count of zero, otherwise it decrements the hop count. (This behavior is different from IPv4 and IPv6 in order to support the later addition of a traceroute-like facility that would be able to get a hop count exceeded from an egress RBridge.)
跃点计数字段是一个6位无符号整数。Rbridge丢弃跳数为零的接收帧，否则会减少跳数。（此行为不同于IPv4和IPv6，以支持稍后添加的类似跟踪路由的设施，该设施将能够从出口RBridge获取超过的跃点计数。）
For known unicast frames, the ingress RBridge SHOULD set the Hop Count in excess of the number of RBridge hops it expects to the egress RBridge to allow for alternate routing later in the path.
对于已知的单播帧，入口RBridge应将跳数设置为超出其期望到出口RBridge的RBridge跳数，以允许稍后在路径中进行备用路由。
For multi-destination frames, the Hop Count SHOULD be set by the ingress RBridge (or source RBridge for a TRILL ESADI frame) to at least the expected number of hops to the most distant RBridge. To accomplish this, RBridge RBn calculates, for each branch from RBn of the specified distribution tree rooted at RBi, the maximum number of hops in that branch.
对于多目标帧，应通过入口RBridge（或TRILL ESADI帧的源RBridge）将跳数设置为至少到最远RBridge的预期跳数。为了实现这一点，RBridge RBn计算指定分布树的RBn中以RBi为根的每个分支在该分支中的最大跳数。
Multi-destination frames are of particular danger because a loop involving one or more distribution tree forks could result in the rapid generation of multiple copies of the frame, even with the normal hop count mechanism. It is for this reason that multi-destination frames are subject to a stringent Reverse Path Forwarding Check and other checks as described in Section 4.5.2. As an optional additional traffic control measure, when forwarding a multi-destination frame onto a distribution tree branch, transit RBridge RBm MAY decrease the hop count by more than 1, unless decreasing the hop count by more than 1 would result in a hop count insufficient to reach all destinations in that branch of the tree rooted at RBi. Using a hop count close or equal to the minimum needed on multi-destination frames provides additional protection against problems with temporary loops when forwarding.
多目标帧尤其危险，因为涉及一个或多个分发树分叉的循环可能导致快速生成帧的多个副本，即使使用正常的跃点计数机制也是如此。正是由于这个原因，多目标帧受到严格的反向路径转发检查和第4.5.2节所述的其他检查。作为可选的附加流量控制措施，当将多目的地帧转发到分发树分支上时，transit RBridge RBm可将跳数减少1以上，除非将跳数减少1以上将导致跳数不足以到达以RBi为根的树分支中的所有目的地。在多目标帧上使用接近或等于所需最小值的跃点计数可提供额外的保护，以防止转发时出现临时循环问题。
Although the RBridge MAY decrease the hop count of multi-destination frames by more than 1, under the circumstances described above, the RBridge forwarding a frame MUST decrease the hop count by at least 1, and discards the frame if it cannot do so because the hop count is 0. The option to decrease the hop count by more than 1 under the circumstances described above applies only to multi-destination frames, not to known unicast frames.
尽管RBridge可以将多目的地帧的跳数减少1以上，但是在上述情况下，转发帧的RBridge必须将跳数减少至少1，并且如果由于跳数为0而不能这样做，则丢弃帧。在上述情况下，将跳数减少1以上的选项仅适用于多目的地帧，而不适用于已知的单播帧。
Nicknames are 16-bit dynamically assigned quantities that act as abbreviations for RBridges' IS-IS IDs to achieve a more compact encoding and can be used to specify potentially different trees with the same root. This assignment allows specifying up to 2**16 RBridges; however, the value 0x0000 is reserved to indicate that a nickname is not specified, the values 0xFFC0 through 0xFFFE are reserved for future specification, and the value 0xFFFF is permanently reserved. RBridges piggyback a nickname acquisition protocol on the link state protocol (see Section 3.7.3) to acquire one or more nicknames unique within the campus.
昵称是16位动态分配的数量，用作RBridges IS-IS ID的缩写，以实现更紧凑的编码，并可用于指定具有相同根的可能不同的树。此分配允许指定最多2**16个脊线；但是，保留值0x0000表示未指定昵称，保留值0xFFC0到0xFFFE以供将来指定，并且永久保留值0xFFFF。RBridges在链路状态协议（见第3.7.3节）上搭载昵称获取协议，以获取校园内唯一的一个或多个昵称。
There are two cases for the contents of the egress RBridge nickname field, depending on the M bit (see Section 3.4). The nickname is filled in by the ingress RBridge for TRILL Data frames and by the source RBridge for TRILL ESADI frames.
出口RBridge昵称字段的内容有两种情况，具体取决于M位（见第3.4节）。该昵称由TRILL数据帧的入口RBridge和TRILL ESADI帧的源RBridge填充。
o For known unicast TRILL Data frames, M == 0 and the egress RBridge nickname field specifies the egress RBridge; that is, it specifies the RBridge that needs to remove the TRILL encapsulation and forward the native frame. Once the egress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge.
o 对于已知的单播TRILL数据帧，M==0，出口RBridge昵称字段指定出口RBridge；也就是说，它指定需要删除TRILL封装并转发本机帧的RBridge。一旦设置了出口昵称字段，任何后续的运输RBridge都不得更改该字段。
o For multi-destination TRILL Data frames and for TRILL ESADI frames, M == 1. The egress RBridge nickname field contains a nickname specifying the distribution tree selected to be used to forward the frame. This root nickname MUST NOT be changed by transit RBridges.
o 对于多目标TRILL数据帧和TRILL ESADI帧，M==1。出口RBridge昵称字段包含一个昵称，用于指定选择用于转发帧的分发树。此根昵称不能由用户更改。
The ingress RBridge nickname is set to a nickname of the ingress RBridge for TRILL Data frames and to a nickname of the source RBridge for TRILL ESADI frames. If the RBridge setting the ingress nickname has multiple nicknames, it SHOULD use the same nickname in the ingress field whenever it encapsulates a frame with any particular Inner.MacSA and Inner.VLAN value. This simplifies end node learning.
入口RBridge昵称设置为TRILL数据帧的入口RBridge昵称，以及TRILL ESADI帧的源RBridge昵称。如果设置入口昵称的RBridge具有多个昵称，则无论何时使用任何特定的Inner.MacSA和Inner.VLAN值封装帧，它都应在入口字段中使用相同的昵称。这简化了终端节点学习。
Once the ingress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge.
一旦设置了入口昵称字段，任何后续传输都不得更改该字段。
The nickname selection protocol is piggybacked on TRILL IS-IS as follows:
昵称选择协议基于TRILL is-is，如下所示：
o The nickname or nicknames being used by an RBridge are carried in an IS-IS TLV (type-length-value data element) along with a priority of use value [RFC6326]. Each RBridge chooses its own nickname or nicknames.
o RBridge使用的一个或多个昵称与使用优先级值[RFC6326]一起携带在IS-IS TLV（类型长度值数据元素）中。每个RBridge都选择自己的一个或多个昵称。
o Nickname values MAY be configured. An RBridge that has been configured with one or more nickname values will have priority for those nickname values over all Rbridges with non-configured nicknames.
o 可以配置昵称值。配置了一个或多个昵称值的RBridge将优先于所有未配置昵称的RBridge。
o The nickname value 0x0000 and the values from 0xFFC0 through 0xFFFF are reserved and MUST NOT be selected by or configured for an RBridge. The value 0x0000 is used to indicate that a nickname is not known.
o 昵称值0x0000和0xFFC0到0xFFFF之间的值是保留的，不能由RBridge选择或配置。值0x0000用于指示昵称未知。
o The priority of use field reported with a nickname is an unsigned 8-bit value, where the most significant bit (0x80) indicates that the nickname value was configured. The bottom 7 bits have the default value 0x40, but MAY be configured to be some other value. Additionally, an RBridge MAY increase its priority after holding a nickname for some amount of time. However, the most significant bit of the priority MUST NOT be set unless the nickname value was configured.
o 使用昵称报告的使用优先级字段是无符号8位值，其中最高有效位（0x80）表示已配置昵称值。底部7位具有默认值0x40，但可以配置为其他值。此外，RBridge在保留昵称一段时间后可能会增加其优先级。但是，除非配置了昵称值，否则不能设置优先级的最高有效位。
o Once an RBridge has successfully acquired a nickname, it SHOULD attempt to reuse it in the case of a reboot.
o 一旦RBridge成功获得昵称，它应该尝试在重新启动时重用它。
o Each RBridge is responsible for ensuring that its nickname or each of its nicknames is unique. If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, then the RBridge or pseudonode with the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if there is a tie in priority, the RBridge with the numerically higher IS-IS System ID keeps the nickname, and the other RBridge MUST select a new nickname. This can require an RBridge with a configured nickname to select a replacement nickname.
o 每个RBridge负责确保其昵称或其每个昵称是唯一的。如果RB1选择昵称x，并且RB1在以后任何时候通过接收RB2的LSP发现RB2也选择了x，则具有数字较高的IS-IS ID（LAN ID）的RBridge或伪节点保留昵称，或者如果优先级相同，则具有数字较高的IS-IS系统ID的RBridge保留昵称，另一个RBridge必须选择一个新的昵称。这可能需要配置了昵称的RBridge来选择替换昵称。
o To minimize the probability of nickname collisions, an RBridge selects a nickname randomly from the apparently available nicknames, based on its copy of the link state. This random selection can be by the RBridge hashing some of its parameters, e.g., SystemID, time and date, and other entropy sources, such as those given in [RFC4086], each time or by the RBridge using such hashing to create a seed and making any selections based on pseudo-random numbers generated from that seed [RFC4086]. The random numbers or seed and the algorithm used SHOULD make uniformly distributed selections over the available nicknames. Convergence to a nickname-collision-free campus is accelerated by selecting new nicknames only from those that appear to be available and by having the highest priority nickname involved in a nickname conflict retain its value. There is no reason for all Rbridges to use the same algorithm for selecting nicknames.
o 为了最小化昵称冲突的概率，RBridge基于其链接状态的副本从明显可用的昵称中随机选择昵称。该随机选择可通过RBridge每次对其某些参数（例如SystemID、时间和日期）和其他熵源（如[RFC4086]中给出的熵源）进行散列，或通过RBridge使用此类散列创建种子并基于该种子生成的伪随机数进行任何选择[RFC4086]。随机数或种子以及使用的算法应在可用昵称上进行均匀分布的选择。通过仅从看似可用的昵称中选择新昵称，并使昵称冲突中涉及的最高优先级昵称保留其值，可以加速到昵称无冲突校园的收敛。没有理由让所有RBridge都使用相同的算法来选择昵称。
o If two RBridge campuses merge, then transient nickname collisions are possible. As soon as each RBridge receives the LSPs from the other RBridges, the RBridges that need to change nicknames select new nicknames that do not, to the best of their knowledge, collide with any existing nicknames. Some RBridges may need to change nicknames more than once before the situation is resolved.
o 如果两个RBridge校区合并，那么短暂的昵称冲突是可能的。一旦每个RBridge从其他RBridge接收到LSP，需要更改昵称的RBridge就会选择新的昵称，尽其所知，这些昵称不会与任何现有昵称发生冲突。某些RBridge可能需要多次更改昵称才能解决此问题。
o To minimize the probability of a new RBridge usurping a nickname already in use, an RBridge SHOULD wait to acquire the link state database from a neighbor before it announces any nicknames that were not configured.
o 为了最大限度地降低新RBridge篡夺已在使用的昵称的可能性，RBridge应该等待从邻居处获取链路状态数据库，然后再宣布任何未配置的昵称。
o An RBridge by default has only a single nickname but MAY be configured to request multiple nicknames. Each such nickname would specify a shortest path tree with the RBridge as root but, since the tree number is used in tiebreaking when there are multiple equal cost paths (see Section 4.5.1), the trees for the different nicknames will likely utilize different links. Because of the potential tree computation load it imposes, this capability
o 默认情况下，RBridge只有一个昵称，但可以配置为请求多个昵称。每个这样的昵称将指定一个以RBridge作为根的最短路径树，但是，由于当存在多个等成本路径时（参见第4.5.1节），在分段时使用树编号，因此不同昵称的树可能会使用不同的链接。由于潜在的树计算负载，这种能力
to request multiple nicknames for an RBridge should be used sparingly. For example, it should be used at a few RBridges that, because of campus topology, are particularly good places from which to calculate multiple different shortest path distribution trees. Such trees need separate nicknames so traffic can be multipathed across them.
要为RBridge请求多个昵称，应谨慎使用。例如，由于校园拓扑结构的原因，它应该用于一些RBridge，这些RBridge是计算多个不同最短路径分布树的特别好的地方。这样的树需要单独的昵称，以便流量可以通过它们进行多路径传输。
o If it is desired for a pseudonode to be a tree root, the DRB MAY request one or more nicknames in the pseudonode LSP.
o 如果期望伪节点是树根，则DRB可以请求伪节点LSP中的一个或多个昵称。
Every nickname in use in a campus identifies an RBridge (or pseudonode) and every nickname designates a distribution tree rooted at the RBridge (or pseudonode) it identifies. However, only a limited number of these potential distribution trees are actually computed by all the RBridges in a campus as discussed in Section 4.5.
校园中使用的每个昵称都标识一个RBridge（或伪节点），每个昵称都指定一个以其标识的RBridge（或伪节点）为根的分发树。然而，如第4.5节所述，校园内所有RBridge实际计算的潜在分布树数量有限。
All Rbridges MUST be able to skip the number of 4-octet chunks indicated by the Op-Length field (see Section 3.5) in order to find the inner frame, since RBridges must be able to find the destination MAC address and VLAN tag in the inner frame. (Transit RBridges need such information to filter VLANs, IP multicast, and the like. Egress Rbridges need to find the inner header to correctly decapsulate and handle the inner frame.)
由于Rbridges必须能够在内部帧中找到目标MAC地址和VLAN标记，因此所有Rbridges必须能够跳过Op Length字段（见第3.5节）指示的4个八位组块的数量，以便找到内部帧。（Transit RBridges需要这些信息来过滤VLAN、IP多播等。Exit RBridges需要找到内部报头以正确解封装和处理内部帧。）
To ensure backward-compatible safe operation, when Op-Length is non-zero indicating that options are present, the top two bits of the first octet of the options area are specified as follows:
为确保向后兼容的安全操作，当Op Length为非零表示存在选项时，选项区域第一个八位组的前两位指定如下：
+------+------+----+----+----+----+----+----+
| CHbH | CItE | Reserved |
+------+------+----+----+----+----+----+----+
+------+------+----+----+----+----+----+----+
| CHbH | CItE | Reserved |
+------+------+----+----+----+----+----+----+
Figure 6: Options Area Initial Flags Octet
图6：选项区初始标志八位字节
If the CHbH (Critical Hop-by-Hop) bit is one, one or more critical hop-by-hop options are present. Transit RBridges that do not support all of the critical hop-by-hop options present, for example, an RBridge that supported no options, MUST drop the frame. If the CHbH bit is zero, the frame is safe, from the point of view of options processing, for a transit RBridge to forward, regardless of what options that RBridge does or does not support. A transit RBridge that supports none of the options present MUST transparently forward the options area when it forwards a frame.
如果CHbH（关键逐跳）位为1，则存在一个或多个关键逐跳选项。不支持所有关键逐跳选项的传输RBridge（例如，不支持任何选项的RBridge）必须删除帧。如果CHbH位为零，则从选项处理的角度来看，无论RBridge支持或不支持哪些选项，帧对于中转RBridge向前都是安全的。不支持任何选项的transit RBridge在转发帧时必须透明地转发选项区域。
If the CItE (Critical Ingress-to-Egress) bit is one, one or more critical ingress-to-egress options are present. If it is zero, no
如果CItE（临界入口到出口）位为1，则存在一个或多个临界入口到出口选项。如果为零，则为否
such options are present. If either CHbH or CItE is non-zero, egress RBridges that don't support all critical options present, for example, an RBridge that supports no options, MUST drop the frame. If both CHbH and CItE are zero, the frame is safe, from the point of view of options, for any egress RBridge to process, regardless of what options that RBridge does or does not support.
这种选择是存在的。如果CHbH或CItE为非零，则不支持所有关键选项的出口RBridge（例如，不支持任何选项的RBridge）必须丢弃帧。如果CHbH和CItE均为零，则从选项的角度来看，无论RBridge支持或不支持什么选项，任何出口RBridge处理的帧都是安全的。
Options, including the meaning of the bits labeled as Reserved in Figure 6, will be further specified in other documents and are expected to include provisions for hop-by-hop and ingress-to-egress options as well as critical and non-critical options.
选项，包括图6中标记为保留的位的含义，将在其他文件中进一步规定，并预计包括逐跳和进出选项以及关键和非关键选项的规定。
Note: Most RBridge implementations are expected to be optimized for the simplest and most common cases of frame forwarding and processing. The inclusion of options may, and the inclusion of complex or lengthy options likely will, cause frame processing using a "slow path" with inferior performance to "fast path" processing. Limited slow path throughput may cause such frames to be discarded.
注意：大多数RBridge实现预计将针对最简单和最常见的帧转发和处理情况进行优化。包含选项可能，并且包含复杂或冗长的选项可能会导致使用“慢路径”的帧处理，其性能不如“快路径”处理。有限的慢路径吞吐量可能导致丢弃此类帧。
Section 3 above specifies the TRILL header, while this section specifies other RBridge design details.
上面第3节指定了颤音标题，而本节指定了其他RBridge设计细节。
TRILL data and ESADI frames in transit on Ethernet links are encapsulated with an outer Ethernet header (see Figure 2). This outer header looks, to a bridge on the path between two RBridges, like the header of a regular Ethernet frame; therefore, bridges forward the frame as they normally would. To enable RBridges to distinguish such TRILL Data frames, a new TRILL Ethertype (see Section 7.2) is used in the outer header.
以太网链路上传输的TRILL数据和ESADI帧用外部以太网报头封装（见图2）。这个外部报头看起来像两个RBridge之间路径上的桥接器，就像普通以太网帧的报头一样；因此，桥梁会像通常一样向前移动框架。为了使RBridges能够区分此类颤音数据帧，在外部报头中使用了新的颤音以太类型（见第7.2节）。
Figure 7 details a TRILL Data frame with an outer VLAN tag traveling on an Ethernet link as shown at the top of the figure, that is, between transit RBridges RB3 and RB4. The native frame originated at end station ESa, was encapsulated by ingress RBridge RB1, and will ultimately be decapsulated by egress RBridge RB2 and delivered to destination end station ESb. The encapsulation shown has the advantage, if TRILL options are absent or the length of such options is a multiple of 64 bits, of aligning the original Ethernet frame at a 64-bit boundary.
图7详细描述了一个TRILL数据帧，该帧带有一个外部VLAN标记，该标记在以太网链路上移动，如图顶部所示，即在传输RB3和RB4之间。源于端站ESa的本机帧由入口RBridge RB1封装，最终将由出口RBridge RB2解封并传送到目的端站ESb。如果没有TRILL选项或此类选项的长度是64位的倍数，则所示封装具有在64位边界处对齐原始以太网帧的优点。
When a TRILL Data frame is carried over an Ethernet cloud, it has three pairs of addresses:
当TRILL数据帧通过以太网云传输时，它有三对地址：
o Outer Ethernet Header: Outer Destination MAC Address (Outer.MacDA) and Outer Source MAC Address (Outer.MacSA): These addresses are used to specify the next hop RBridge and the transmitting RBridge, respectively.
o 外部以太网报头：外部目标MAC地址（Outer.MacDA）和外部源MAC地址（Outer.MacSA）：这些地址分别用于指定下一跳RBridge和传输RBridge。
o TRILL Header: Egress Nickname and Ingress Nickname. These specify nicknames of the egress and ingress RBridges, respectively, unless the frame is multi-destination, in which case the Egress Nickname specifies the distribution tree on which the frame is being sent.
o 颤音头：出口昵称和入口昵称。这些分别指定出口和入口rbridge的昵称，除非帧是多目的地，在这种情况下，出口昵称指定发送帧的分发树。
o Inner Ethernet Header: Inner Destination MAC Address (Inner.MacDA) and Inner Source MAC Address (Inner.MacSA): These addresses are as transmitted by the original end station, specifying, respectively, the destination and source of the inner frame.
o 内部以太网报头：内部目标MAC地址（Inner.MacDA）和内部源MAC地址（Inner.MacSA）：这些地址由原始终端站传输，分别指定内部帧的目标和源。
A TRILL Data frame also potentially has two VLAN tags, as discussed in Sections 4.1.2 and 4.1.3 below, that can carry two different VLAN Identifiers and specify priority.
TRILL数据帧还可能具有两个VLAN标记，如下文第4.1.2节和第4.1.3节所述，可以携带两个不同的VLAN标识符并指定优先级。
Flow:
+-----+ +-------+ +-------+ +-------+ +-------+ +----+
| ESa +--+ RB1 +---+ RB3 +-------+ RB4 +---+ RB2 +--+ESb |
+-----+ |ingress| |transit| ^ |transit| |egress | +----+
+-------+ +-------+ | +-------+ +-------+
|
Outer Ethernet Header: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address (RB4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address (RB3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (RB2) Nickname | Ingress (RB1) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address (ESb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address (ESa) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow:
+-----+ +-------+ +-------+ +-------+ +-------+ +----+
| ESa +--+ RB1 +---+ RB3 +-------+ RB4 +---+ RB2 +--+ESb |
+-----+ |ingress| |transit| ^ |transit| |egress | +----+
+-------+ +-------+ | +-------+ +-------+
|
Outer Ethernet Header: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address (RB4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address (RB3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (RB2) Nickname | Ingress (RB1) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address (ESb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address (ESa) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TRILL Data Encapsulation over Ethernet
图7：以太网上的TRILL数据封装
A "VLAN Tag" (formerly known as a Q-tag), also known as a "C-tag" for customer tag, includes a VLAN ID and a priority field as shown in Figure 8. The "VLAN ID" may be zero, indicating that no VLAN is specified, just a priority, although such frames are called "priority tagged" rather than "VLAN tagged" [802.1Q-2005].
“VLAN标签”（以前称为Q标签），也称为客户标签的“C标签”，包括VLAN ID和优先级字段，如图8所示。“VLAN ID”可能为零，表示未指定VLAN，仅指定优先级，尽管此类帧称为“优先级标记”而不是“VLAN标记”[802.1Q-2005]。
Use of [802.1ad] S-tags, also known as service tags, and use of stacked tags, are beyond the scope of this document.
[802.1ad]S标签（也称为服务标签）的使用和堆叠标签的使用超出了本文档的范围。
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Priority | C | VLAN ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Priority | C | VLAN ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 8: VLAN Tag Information
图8:VLAN标记信息
As recommended in [802.1Q-2005], Rbridges SHOULD be implemented so as to allow use of the full range of VLAN IDs from 0x001 through 0xFFE. Rbridges MAY support a smaller number of simultaneously active VLAN IDs. VLAN ID zero is the null VLAN identifier and indicates that no VLAN is specified while VLAN ID 0xFFF is reserved.
按照[802.1Q-2005]中的建议，应实施Rbridges，以允许使用从0x001到0xFFE的全范围VLAN ID。Rbridges可以支持较少数量的同时活动的VLAN ID。VLAN ID零是空VLAN标识符，表示保留VLAN ID 0xFFF时未指定VLAN。
The VLAN ID 0xFFF MUST NOT be used. Rbridges MUST discard any frame they receive with an Outer.VLAN ID of 0xFFF. Rbridges MUST discard any frame for which they examine the Inner.VLAN ID and find it to be 0xFFF; such examination is required at all egress Rbridges that decapsulate a frame.
不得使用VLAN ID 0xFFF。Rbridges必须丢弃接收到的任何Outer.VLAN ID为0xFFF的帧。Rbridges必须丢弃其检查Inner.VLAN ID并发现其为0xFFF的任何帧；要求在所有拆封框架的出口处进行此类检查。
The "C" bit shown in Figure 8 is not used in the Inner.VLAN in TRILL. It MUST be set to zero there by ingress RBridges, transparently forwarded by transit RBridges, and is ignored by egress RBridges.
图8所示的“C”位未在TRILL中的internal.VLAN中使用。必须通过入口RBridges将其设置为零，通过过境RBridges透明转发，并被出口RBridges忽略。
As specified in [802.1Q-2005], the priority field contains an unsigned value from 0 through 7 where 1 indicates the lowest priority, 7 the highest priority, and the default priority zero is considered to be higher than priority 1 but lower than priority 2. The [802.1ad] amendment to [802.1Q-2005] permits mapping some adjacent pairs of priority levels into a single priority level with and without drop eligibility. Ongoing work in IEEE 802.1 (802.1az, Appendix E) suggests the ability to configure "priority groups" that have a certain guaranteed bandwidth. RBridges ports MAY also implement such options. RBridges are not required to implement any particular number of distinct priority levels but may treat one or more adjacent priority levels in the same fashion.
如[802.1Q-2005]所述，优先级字段包含从0到7的无符号值，其中1表示最低优先级，7表示最高优先级，默认优先级0被视为高于优先级1但低于优先级2。[802.1Q-2005]的[802.1ad]修正案允许将一些相邻的优先级对映射到一个具有或不具有删除资格的单个优先级。IEEE 802.1（802.1az，附录E）中正在进行的工作表明，可以配置具有一定保证带宽的“优先级组”。RBridges端口也可以实现此类选项。RBridge不需要实现任何特定数量的不同优先级，但可以以相同的方式处理一个或多个相邻优先级。
Frames with the same source address, destination address, VLAN, and priority that are received on the same port as each other and are transmitted on the same port MUST be transmitted in the order received unless the RBridge classifies the frames into more fine-grained flows, in which case this ordering requirement applies to each such flow. Frames in the same VLAN with the same priority and received on the same port may be sent out different ports if multipathing is in effect. (See Appendix C.)
在同一端口上接收并在同一端口上传输的具有相同源地址、目标地址、VLAN和优先级的帧必须按照接收的顺序传输，除非RBridge将帧划分为更细粒度的流，在这种情况下，此排序要求适用于每个这样的流。如果多路径有效，同一VLAN中具有相同优先级且在同一端口上接收的帧可能会发送到不同的端口。（见附录C）
The C-Tag Ethertype [RFC5342] is 0x8100.
C标签以太类型[RFC5342]为0x8100。
The "Inner VLAN Tag Information" (Inner.VLAN) field contains the VLAN tag information associated with the native frame when it was ingressed or the VLAN tag information associated with a TRILL ESADI frame when that frame was created. When a TRILL frame passes through a transit RBridge, the Inner.VLAN MUST NOT be changed except when VLAN mapping is being intentionally performed within that RBridge.
“内部VLAN标记信息”（Inner.VLAN）字段包含进入本机帧时与本机帧关联的VLAN标记信息，或创建该帧时与TRILL ESADI帧关联的VLAN标记信息。当颤音帧通过传输RBridge时，不得更改internal.VLAN，除非在该RBridge内有意执行VLAN映射。
When a native frame arrives at an RBridge, the associated VLAN ID and priority are determined as specified in [802.1Q-2005] (see Appendix D and [802.1Q-2005], Section 6.7). If the RBridge is an appointed forwarder for that VLAN and the delivery of the frame requires transmission to one or more other links, this ingress RBridge forms a TRILL Data frame with the associated VLAN ID and priority placed in the Inner.VLAN information.
当本机帧到达RBridge时，按照[802.1Q-2005]中的规定确定相关的VLAN ID和优先级（参见附录D和[802.1Q-2005]第6.7节）。如果RBridge是该VLAN的指定转发器，并且帧的交付需要传输到一个或多个其他链路，则该入口RBridge形成一个TRILL数据帧，其相关VLAN ID和优先级放在Inner.VLAN信息中。
The VLAN ID is required at the ingress Rbridge as one element in determining the appropriate egress Rbridge for a known unicast frame and is needed at the ingress and every transit Rbridge for multi-destination frames to correctly prune the distribution tree.
VLAN ID在入口Rbridge处需要，作为确定已知单播帧的适当出口Rbridge时的一个元素，并且在入口和多目的地帧的每个中转Rbridge处需要VLAN ID以正确修剪分发树。
TRILL frames sent by an RBridge, except for some TRILL-Hello frames, use an Outer.VLAN ID specified by the Designated RBridge (DRB) for the link onto which they are being sent, referred to as the Designated VLAN. For TRILL data and ESADI frames, the priority in the Outer.VLAN tag SHOULD be set to the priority in the Inner.VLAN tag.
由RBridge发送的TRILL帧，除了一些TRILL Hello帧外，使用指定RBridge（DRB）为其发送到的链路指定的Outer.VLAN ID，称为指定VLAN。对于TRILL数据和ESADI帧，Outer.VLAN标记中的优先级应设置为Inner.VLAN标记中的优先级。
TRILL frames forwarded by a transit RBridge use the priority present in the Inner.VLAN of the frame as received. TRILL Data frames are sent with the priority associated with the corresponding native frame when received (see Appendix D). TRILL IS-IS frames SHOULD be sent with priority 7.
传输RBridge转发的TRILL帧使用接收到的帧的Inner.VLAN中存在的优先级。TRILL数据帧在接收时以与相应本机帧相关联的优先级发送（见附录D）。颤音IS-IS帧应以优先级7发送。
Whether an Outer.VLAN tag actually appears on the wire when a TRILL frame is sent depends on the configuration of the RBridge port through which it is sent in the same way as the appearance of a VLAN tag on a frame sent by an [802.1Q-2005] bridge depends on the configuration of the bridge port (see Section 4.9.2).
发送TRILL帧时，Outer.VLAN标记是否实际出现在导线上取决于RBridge端口的配置，通过RBridge端口发送该标记的方式与[802.1Q-2005]网桥发送的帧上VLAN标记的外观相同，取决于网桥端口的配置（见第4.9.2节）。
Each Ethernet frame has a single Frame Check Sequence (FCS) that is computed to cover the entire frame, for detecting frame corruption due to bit errors on a link. Thus, when a frame is encapsulated, the original FCS is not included but is discarded. Any received frame for which the FCS check fails SHOULD be discarded (this may not be possible in the case of cut through forwarding). The FCS normally changes on encapsulation, decapsulation, and every TRILL hop due to changes in the outer destination and source addresses, the decrementing of the hop count, etc.
每个以太网帧都有一个计算覆盖整个帧的单帧检查序列（FCS），用于检测由于链路上的位错误而导致的帧损坏。因此，当封装帧时，不包括原始FCS，而是丢弃。应丢弃FCS检查失败的任何接收帧（在直通转发的情况下，这可能不可能）。由于外部目的地和源地址的变化、跃点计数的减少等，FCS通常会在封装、解封装和每个TRILL跃点上发生变化。
Although the FCS is normally calculated just before transmission, it is desirable, when practical, for an FCS to accompany a frame within an RBridge after receipt. That FCS could then be dynamically updated to account for changes to the frame during Rbridge processing and used for transmission or checked against the FCS calculated for frame transmission. This optional, more continuous use of an FCS would be helpful in detecting some internal RBridge failures such as memory errors.
虽然FCS通常是在传输前计算的，但在实际情况下，FCS在接收后伴随RBridge内的帧是可取的。然后，该FCS可以动态更新，以考虑Rbridge处理期间的帧变化，并用于传输或对照为帧传输计算的FCS进行检查。这种可选的、更连续地使用FCS将有助于检测某些内部RBridge故障，如内存错误。
TRILL uses an extension of IS-IS [ISO10589] [RFC1195] as its routing protocol. IS-IS has the following advantages:
TRILL使用IS-IS[ISO10589][RFC1195]的扩展作为其路由协议。IS-IS具有以下优点：
o It runs directly over Layer 2, so therefore it may be run without configuration (no IP addresses need to be assigned).
o 它直接在第2层上运行，因此可以在不进行配置的情况下运行（无需分配IP地址）。
o It is easy to extend by defining new TLV (type-length-value) data elements and sub-elements for carrying TRILL information.
o 通过定义新的TLV（类型长度值）数据元素和用于承载颤音信息的子元素，可以很容易地进行扩展。
This section describes TRILL use of IS-IS, except for the TRILL-Hello protocol, which is described in Section 4.4, and the MTU-probe and MTU-ack messages that are described in Section 4.3.
本节介绍IS-IS的TRILL使用，第4.4节中描述的TRILL Hello协议以及第4.3节中描述的MTU探测和MTU确认消息除外。
Each RBridge has a unique 48-bit (6-octet) IS-IS System ID. This ID may be derived from any of the RBridge's unique MAC addresses.
每个RBridge都有一个唯一的48位（6个八位组）IS-IS系统ID。该ID可以从RBridge的任何唯一MAC地址派生。
A pseudonode is assigned a 7-octet ID by the DRB that created it, by taking a 6-octet ID owned by the DRB, and appending another octet. The 6-octet ID used to form a pseudonode ID SHOULD be the DRB's ID unless the DRB has to create IDs for pseudonodes for more than 255 links. The only constraint for correct operation is that the 7-octet ID be unique within the campus, and that the 7th octet be nonzero. An RBridge has a 7-octet ID consisting of its 6-octet system ID concatenated with a zero octet.
创建伪节点的DRB通过获取DRB拥有的6个八位字节ID并附加另一个八位字节，为伪节点分配7个八位字节ID。用于形成伪节点ID的6个八位组ID应该是DRB的ID，除非DRB必须为超过255个链接的伪节点创建ID。正确操作的唯一限制是7个八位字节ID在校园内是唯一的，并且第7个八位字节不为零。RBridge具有7个八位字节的ID，由其6个八位字节的系统ID与零个八位字节连接而成。
In this document, we use the term "IS-IS ID" to refer to the 7-octet quantity that can be either the ID of an RBridge or a pseudonode.
在本文档中，我们使用术语“IS-IS-ID”来表示7个八位组的数量，该数量可以是RBridge或伪节点的ID。
TRILL implements a separate IS-IS instance from any used by Layer 3, that is, different from the one used by routers. Layer 3 IS-IS frames must be distinguished from TRILL IS-IS frames even when those Layer 3 IS-IS frames are transiting an RBridge campus.
TRILL实现了一个独立于第3层使用的任何IS-IS实例的IS-IS实例，也就是说，它不同于路由器使用的IS-IS实例。第3层IS-IS帧必须与颤音IS-IS帧区分开来，即使这些第3层IS-IS帧正在穿过RBridge校园。
Layer 3 IS-IS native frames have special multicast destination addresses specified for that purpose, such as AllL1ISs or AllL2ISs. When they are TRILL encapsulated, these multicast addresses appear as the Inner.MacDA and the Outer.MacDA will be the All-RBridges multicast address.
第3层IS-IS本机帧具有为此目的指定的特殊多播目标地址，如AllL1ISs或AllL2ISs。当它们被TRILL封装时，这些多播地址显示为Inner.MacDA，Outer.MacDA将是所有RBridges多播地址。
Within TRILL, there is an IS-IS instance across all Rbridges in the campus as described in Section 4.2.3. This instance uses TRILL IS-IS frames that are distinguished by having a different Ethertype "L2-IS-IS". Additionally, for TRILL IS-IS frames that are multicast, there is a distinct multicast destination address of All-IS-IS-RBridges. TRILL IS-IS frames do not have a TRILL header.
在TRILL中，如第4.2.3节所述，校园内所有RBridge都有一个is-is实例。此实例使用TRILL IS-IS帧，通过使用不同的以太网类型“L2-IS-IS”进行区分。此外，对于多播的TRILL IS-IS帧，所有IS RBridge都有一个不同的多播目的地地址。颤音IS-IS帧没有颤音标头。
ESADI is a separate protocol from the IS-IS instance implemented by all the RBridges. There is a separate ESADI instance for each VLAN, and ESADI frames are encapsulated just like TRILL Data frames. After the TRILL header, the ESADI frame has an inner Ethernet header with the Inner.MacDA of "All-ESADI-RBridges" and the "L2-IS-IS" Ethertype followed by the ESADI frame.
ESADI是一个独立于由所有RBridge实现的is-is实例的协议。每个VLAN都有一个单独的ESADI实例，ESADI帧与TRILL数据帧一样被封装。在TRILL报头之后，ESADI帧具有一个内部以太网报头，其内部.MacDA为“所有ESADI RBridges”，且“L2-IS-IS”以太类型后跟ESADI帧。
All Rbridges MUST participate in the TRILL IS-IS instance, which constitutes a single Level 1 IS-IS area using the fixed area address zero. TRILL IS-IS frames are never forwarded by an RBridge but are locally processed on receipt. (Such processing may cause the RBridge to send additional TRILL IS-IS frames.)
所有RBridge都必须参与TRILL IS-IS实例，该实例使用固定区域地址0构成单个级别1 IS-IS区域。TRILL IS-IS帧从不由RBridge转发，而是在接收时进行本地处理。（这种处理可能导致RBridge发送额外的颤音IS-IS帧。）
A TRILL IS-IS frame on an 802.3 link is structured as shown below. All such frames are Ethertype encoded. The RBridge port out of which such a frame is sent will strip the outer VLAN tag if configured to do so.
802.3链路上的颤音IS-IS帧结构如下所示。所有这些帧都是以太类型编码的。从中发送这样一个帧的RBridge端口将剥离外部VLAN标记（如果配置为这样做）。
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges continued | Source RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-IS-IS Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IS-IS Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges continued | Source RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-IS-IS Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IS-IS Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: TRILL IS-IS Frame Format
图9:TRILL IS-IS帧格式
The VLAN specified in the Outer.VLAN information will be the Designated VLAN for the link on which the frame is sent, except in the case of some TRILL Hellos.
在Outer.VLAN信息中指定的VLAN将是发送帧的链路的指定VLAN，某些TRILL Hello的情况除外。
RBridges default to using TRILL Hellos unless, on a per-port basis, they are configured to use P2P Hellos. TRILL-Hello frames are specified in Section 4.4.
RBridges默认使用TRILL Hello，除非在每个端口的基础上配置为使用P2P Hello。颤音Hello帧在第4.4节中有规定。
RBridges are normally configured to use P2P Hellos only when there are exactly two of them on a link. However, it can occur that RBridges are misconfigured as to which type of hello to use. This is safe but may cause lack of RBridge-to-RBridge connectivity. An RBridge port configured to use P2P Hellos ignores TRILL Hellos, and an RBridge port configured to use TRILL Hellos ignores P2P Hellos.
RBridges通常配置为仅当一条链路上正好有两个对等Hello时才使用对等Hello。但是，RBridges可能会被错误配置为使用哪种类型的hello。这是安全的，但可能会导致缺少RBridge到RBridge的连接。配置为使用P2P Hellos的RBridge端口忽略TRILL Hellos，配置为使用TRILL Hellos的RBridge端口忽略P2P Hellos。
If any of the RBridge ports on a link is configured to use TRILL Hellos, one of such RBridge ports using TRILL Hellos is elected DRB (Designated RBridge) for the link. This election is based on
如果链路上的任何RBridge端口配置为使用TRILL Hellos，则使用TRILL Hellos的其中一个RBridge端口被选为链路的DRB（指定RBridge）。这次选举是基于
configured priority (most significant field), and source MAC address, as communicated by TRILL-Hello frames. The DRB, as described in Section 4.2.4.2, designates the VLAN to be used on the link for inter-RBridge communication by the non-P2P RBridge ports and appoints itself or other RBridges on the link as appointed forwarder (see Section 4.2.4.3) for VLANs on the link.
配置的优先级（最高有效字段）和源MAC地址，由TRILL Hello帧传送。如第4.2.4.2节所述，DRB指定非P2P RBridge端口在链路上用于RBridge间通信的VLAN，并将自身或链路上的其他RBridge指定为链路上VLAN的指定转发器（见第4.2.4.3节）。
RBridge ports can be configured to use IS-IS P2P Hellos. This implies that the port is a point-to-point link to another RBridge. An RBridge MUST NOT provide any end-station (native frame) service on a port configured to use P2P Hellos.
RBridge端口可以配置为使用IS-IS P2P Hellos。这意味着该端口是指向另一个RBridge的点对点链路。RBridge不得在配置为使用P2P Hellos的端口上提供任何终端站（本机帧）服务。
As with Layer 3 IS-IS, such P2P ports do not participate in a DRB election. They send all frames VLAN tagged as being in the Desired Designated VLAN configured for the port, although this tag may be stripped if the port is so configured. Since all traffic through the port should be TRILL frames or Layer 2 control frames, such a port cannot be an appointed forwarder. RBridge P2P ports MUST use the IS-IS three-way handshake [RFC5303] so that extended circuit IDs are associated with the link for tie breaking purposes (see Section 4.5.2).
与第3层IS-IS一样，此类P2P端口不参与DRB选择。它们将标记为在为端口配置的所需指定VLAN中的所有VLAN帧发送到VLAN，但如果端口是这样配置的，则该标记可能会被剥离。由于通过端口的所有流量都应该是颤音帧或第2层控制帧，因此此类端口不能是指定的转发器。RBridge P2P端口必须使用IS-IS三向握手[RFC5303]，以便扩展电路ID与链路相关联，以便断开连接（参见第4.5.2节）。
Even if all simple links in a network are physically point-to-point, if some of the nodes are bridges, the bridged LANs that include those bridges appear to be multi-access links to attached RBridges. This would necessitate using TRILL Hellos for proper operation in many cases.
即使网络中的所有简单链路在物理上都是点对点的，但如果某些节点是网桥，则包含这些网桥的桥接LAN似乎是连接到RBridge的多址链路。在许多情况下，这就需要使用颤音Hellos进行正确的操作。
While it is safe to erroneously configure ports as P2P, this may result in lack of connectivity.
虽然将端口错误地配置为P2P是安全的，但这可能会导致连接不足。
TRILL IS-IS elects one RBridge for each LAN link to be the Designated RBridge (DRB), that is, to have special duties. The Designated RBridge:
TRILL IS-IS为每个LAN链路选择一个RBridge作为指定RBridge（DRB），即具有特殊职责。指定的RBridge：
o Chooses, for the link, and announces in its TRILL Hellos, the Designated VLAN ID to be used for inter-RBridge communication. This VLAN is used for all TRILL-encapsulated data and ESADI frames and TRILL IS-IS frames except some TRILL-Hello frames.
o 为链接选择指定的VLAN ID，并在其颤音Hellos中宣布用于RBridge间通信的VLAN ID。此VLAN用于所有TRILL封装数据和ESADI帧以及TRILL is-is帧，但某些TRILL Hello帧除外。
o If the link is represented in the IS-IS topology as a pseudonode, chooses a pseudonode ID and announces that in its TRILL Hellos and issues an LSP on behalf of the pseudonode.
o 如果链路在is-is拓扑中表示为伪节点，则选择一个伪节点ID，并在其颤音中宣布该ID，并代表该伪节点发出LSP。
o Issues CSNPs.
o 发布CSNP。
o For each VLAN-x appearing on the link, chooses an RBridge on the link to be the appointed VLAN-x forwarder (the DRB MAY choose itself to be the appointed VLAN-x forwarder for all or some of the VLANs).
o 对于链路上出现的每个VLAN-x，选择链路上的RBridge作为指定的VLAN-x转发器（DRB可以选择自己作为所有或部分VLAN的指定VLAN-x转发器）。
o Before appointing a VLAN-x forwarder (including appointing itself), wait at least its Holding Time (to ensure it is the DRB).
o 在指定VLAN-x转发器（包括指定自身）之前，至少等待其等待时间（以确保它是DRB）。
o If configured to send TRILL-Hello frames, continues to send them on all its enabled VLANs that have been configured in the Announcing VLANs set of the DRB, which defaults to all enabled VLANs.
o 如果配置为发送TRILL Hello帧，则继续在其所有启用的VLAN上发送这些帧，这些VLAN已在DRB的公布VLAN集中配置，默认为所有启用的VLAN。
The appointed VLAN-x forwarder for a link is responsible for the following points. In connection with the loop avoidance points, when an appointed forwarder for a port is "inhibited", it drops any native frames it receives and does not transmit but instead drops any native frames it decapsulates, in the VLAN for which it is appointed.
指定的链路VLAN-x转发器负责以下几点。关于环路避免点，当端口的指定转发器被“禁止”时，它会丢弃它接收到的任何本机帧，而不是发送，而是丢弃它为其指定的VLAN中的任何被解除封装的本机帧。
o Loop avoidance:
o 循环避免：
- Inhibiting itself for a time, configurable per port from zero to 30 seconds, which defaults to 30 seconds, after it sees a root bridge change on the link (see Section 4.9.3.2).
- 抑制自身一段时间，每个端口可配置为0到30秒，默认为30秒，在它看到链路上的根网桥更改后（见第4.9.3.2节）。
- Inhibiting itself for VLAN-x, if it has received a Hello in which the sender asserts that it is appointed forwarder and that is either + received on VLAN-x (has VLAN-x as its Outer.VLAN) or + was originally sent on VLAN-x as indicated inside the body of the Hello.
- 为VLAN-x抑制自身，如果它已收到一个Hello，其中发送方声明它是指定的转发器，并且该Hello在VLAN-x上被+接收（将VLAN-x作为其外部.VLAN），或者最初在VLAN-x上被+发送，如Hello正文中所示。
- Optionally, not decapsulating a frame from ingress RBridge RBm unless it has RBm's LSP, and the root bridge on the link it is about to forward onto is not listed in RBm's list of root bridges for VLAN-x. This is known as the "decapsulation check" or "root bridge collision check".
- 或者，除非具有RBm的LSP，否则不从入口RBm解除对帧的封装，并且该帧将转发到的链路上的根网桥未列在RBm的VLAN-x根网桥列表中。这称为“去封装检查”或“根桥碰撞检查”。
o Unless inhibited (see above), receiving VLAN-x native traffic from the link and forwarding it as appropriate.
o 除非被禁止（见上文），否则从链路接收VLAN-x本机流量并酌情转发。
o Receiving VLAN-x traffic for the link and, unless inhibited, transmitting it in native form after decapsulating it as appropriate.
o 接收链路的VLAN-x通信量，除非被禁止，否则在适当地解除封装后以本机形式传输。
o Learning the MAC address of local VLAN-x nodes by looking at the source address of VLAN-x frames from the link.
o 通过从链路查看VLAN-x帧的源地址，学习本地VLAN-x节点的MAC地址。
o Optionally learning the port of local VLAN-x nodes based on any sort of Layer 2 registration protocols, such as IEEE 802.11 association and authentication.
o 根据任何种类的第2层注册协议（如IEEE 802.11关联和认证），可选地学习本地VLAN-x节点的端口。
o Keeping track of the { egress RBridge, VLAN, MAC address } of distant VLAN-x end nodes, learned by looking at the fields { ingress RBridge, Inner.VLAN ID, Inner.MacSA } from VLAN-x frames being received for decapsulation onto the link.
o 跟踪远程VLAN-x终端节点的{出口RBridge，VLAN，MAC地址}，通过查看正在接收的VLAN-x帧中的{入口RBridge，Inner.VLAN ID，Inner.MacSA}字段来了解，以便在链路上解封装。
o Optionally observe native IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] frames to learn the presence of local multicast listeners and multicast routers.
o 可选地观察本机IGMP[RFC3376]、MLD[RFC2710]和MRD[RFC4286]帧，以了解本地多播侦听器和多播路由器的存在。
o Optionally listening to TRILL ESADI messages for VLAN-x to learn { egress RBridge, VLAN-x, MAC address } triplets and the confidence level of such explicitly advertised end nodes.
o 可选地侦听VLAN-x的TRILL ESADI消息，以了解{出口RBridge，VLAN-x，MAC地址}三元组以及此类显式公布的终端节点的置信水平。
o Optionally advertising VLAN-x end nodes, on links for which it is appointed VLAN-x forwarder, in ESADI messages.
o 在ESADI消息中，在其被指定为VLAN-x转发器的链路上选择性地公布VLAN-x端节点。
o Sending TRILL-Hello frames on VLAN-x unless the Announcing VLANs set for the port has been configured to disable them.
o 在VLAN-x上发送TRILL Hello帧，除非为端口设置的VLAN已配置为禁用它们。
o Listening to BPDUs on the common spanning tree to learn the root bridge, if any, for that link and to report in its LSP the complete set of root bridges seen on any of its links for which it is appointed forwarder for VLAN-x.
o 收听公共生成树上的BPDU，以了解该链路的根网桥（如果有），并在其LSP中报告其被指定为VLAN-x转发器的任何链路上看到的根网桥的完整集合。
When an appointed forwarder observes that the DRB on a link has changed, it no longer considers itself appointed for that link until appointed by the new DRB.
当指定的货运代理发现某一链路上的DRB已发生变化时，在新的DRB指定之前，其不再认为自己已被指定用于该链路。
The information items in the TRILL IS-IS LSP that are mentioned elsewhere in this document are listed below. Unless an item is stated in the list below to be optional, it MUST be included. Other items MAY be included unless their inclusion is prohibited elsewhere in this document. The actual encoding of this information and the IS-IS Type or sub-Type values for any new IS-IS TLV or sub-TLV data elements are specified in separate documents [RFC6165] [RFC6326].
本文件其他地方提到的TRILL IS-IS LSP中的信息项如下所示。除非以下列表中规定某项为可选项，否则必须将其包括在内。除非本文件其他地方禁止包含其他项目，否则可包含其他项目。此信息的实际编码以及任何新IS-IS TLV或子TLV数据元素的IS-IS类型或子类型值在单独的文档[RFC6165][RFC6326]中指定。
1. The IS-IS IDs of neighbors (pseudonodes as well as RBridges) of RBridge RBn, and the cost of the link to each of those neighbors. RBridges MUST use the Extended IS Reachability TLV (#22, also
1. RBridge RBn的邻居（伪节点和RBridges）的IS-IS ID，以及到每个邻居的链路成本。RBridges必须使用扩展IS可达性TLV（#22
known as "wide metric" [RFC5305]) and MUST NOT use the IS Reachability TLV (#2, also known as "narrow metric"). To facilitate efficient operation without configuration and consistent with [802.1D], RBridges SHOULD, by default, set the cost of a link to the integer part of twenty trillion (20,000,000,000,000) divided by the RBridge port's bit rate but not more than 2**24-2 (16,777,214); for example, the cost for a link accessed by a 1Gbps port would default to 20,000. (Note that 2**24-1 has a special meaning in IS-IS and would exclude the link from SPF routes.) However, the link cost MAY, by default, be decreased for aggregated links and/or increased to not more than 2**24-2 if the link appears to be a bridged LAN. The tested MTU for the link (see Section 4.3) MAY be included via a sub-TLV.
称为“宽度量”[RFC5305]），且不得使用IS可达性TLV（#2，也称为“窄度量”）。为便于在无需配置的情况下高效运行并与[802.1D]保持一致，RBridge在默认情况下应将链路成本设置为20万亿（2000000000）除以RBridge端口比特率的整数部分，但不超过2**24-2（16777214）；例如，1Gbps端口访问链路的成本默认为20000。（请注意，2**24-1在IS-IS中具有特殊含义，将从SPF路由中排除该链路。）但是，默认情况下，聚合链路的链路成本可能会降低，并且/或者，如果链路看起来是桥接LAN，则链路成本可能会增加到不超过2**24-2。链路的测试MTU（见第4.3节）可通过子TLV包括在内。
2. The following information in connection with the nickname or each of the nicknames of RBridge RBn:
2. 以下信息与RBRIGE RBn的昵称或每个昵称有关：
2.1. The nickname value (2 octets).
2.1. 昵称值（2个八位字节）。
2.2. The unsigned 8-bit priority for RBn to have that nickname (see Section 3.7.3).
2.2. RBn具有该昵称的无符号8位优先级（见第3.7.3节）。
2.3. The 16-bit unsigned priority of that nickname to becoming a distribution tree root.
2.3. 该昵称成为分发树根的16位无符号优先级。
3. The maximum TRILL Header Version supported by RBridge RBn.
3. RBRIGE RBn支持的最大颤音标头版本。
4. The following information, in addition to the per-nickname tree root priority, in connection with distribution tree determination and announcement. (See Section 4.5 for further details on how this information is used.)
4. 以下信息，除了每个昵称树根优先级外，还与分发树确定和公告有关。（有关如何使用此信息的更多详细信息，请参见第4.5节。）
4.1. An unsigned 16-bit number that is the number of trees all RBridges in the campus calculate if RBn has the highest priority tree root.
4.1. 一个无符号的16位数字，即如果RBn具有最高优先级的树根，则计算校园中所有RBR桥的树数。
4.2. A second unsigned 16-bit number that is the number of trees RBn would like to use.
4.2. 第二个无符号16位数字是RBn希望使用的树数。
4.3. A third unsigned 16-bit number that is the maximum number of distribution trees that RBn is able to calculate.
4.3. 第三个无符号16位数字，是RBn能够计算的最大分布树数。
4.4. A first list of nicknames that are intended distribution trees for all RBridges in the campus to calculate.
4.4. 第一个昵称列表，用于计算校园中所有RBridge的分布树。
4.5. A second list of nicknames that are distribution trees RBn would like to use when ingressing multi-destination frames.
4.5. 第二个昵称列表是RBn在进入多目标帧时希望使用的分发树。
5. The list of VLAN IDs of VLANs directly connected to RBn for links on which RBn is the appointed forwarder for that VLAN. (Note: An RBridge may advertise that it is connected to additional VLANs in order to receive additional frames to support certain VLAN-based features beyond the scope of this specification as mentioned in Section 4.8.4 and in a separate document concerning VLAN mapping inside RBridges.) RBridges may associate advertised connectivity to different groups of VLANs with specific nicknames they hold. In addition, the LSP contains the following information on a per-VLAN basis:
5. 对于RBn是该VLAN指定转发器的链路，直接连接到RBn的VLAN的VLAN ID列表。（注：如第4.8.4节和关于RBridge内部VLAN映射的单独文件所述，RBridge可能会公布其已连接到其他VLAN，以便接收其他帧，以支持本规范范围以外的某些基于VLAN的功能。）RBridge可能会将广告连接与不同的VLAN组关联起来，并使用它们所拥有的特定昵称。此外，LSP在每个VLAN的基础上包含以下信息：
5.1. Per-VLAN Multicast Router attached flags: This is two bits of information that indicate whether there is an IPv4 and/or IPv6 multicast router attached to the Rbridge on that VLAN. An RBridge that does not do IP multicast control snooping MUST set both of these bits (see Section 4.5.4). This information is used because IGMP [RFC3376] and MLD [RFC2710] Membership Reports MUST be transmitted to all links with IP multicast routers, and SHOULD NOT be transmitted to links without such routers. Also, all frames for IP-derived multicast addresses MUST be transmitted to all links with IP multicast routers (within a VLAN), in addition to links from which an IP node has explicitly asked to join the group the frame is for, except for some IP multicast addresses that MUST be treated as broadcast.
5.1. 每VLAN多播路由器连接标志：这是两位信息，指示是否有IPv4和/或IPv6多播路由器连接到该VLAN上的Rbridge。不进行IP多播控制监听的RBridge必须设置这两个位（参见第4.5.4节）。之所以使用此信息，是因为IGMP[RFC3376]和MLD[RFC2710]成员资格报告必须传输到具有IP多播路由器的所有链路，并且不应传输到没有此类路由器的链路。此外，IP派生多播地址的所有帧必须传输到具有IP多播路由器（在VLAN内）的所有链路，除了IP节点明确要求加入帧所在组的链路之外，某些IP多播地址必须视为广播。
5.2. Per-VLAN mandatory announcement of the set of IDs of Root bridges for any of RBn's links on which RBn is appointed forwarder for that VLAN. Where MSTP (Multiple Spanning Tree Protocol) is running on a link, this is the root bridge of the CIST (Common and Internal Spanning Tree). This is to quickly detect cases where two Layer 2 clouds accidentally get merged, and where there might otherwise temporarily be two DRBs for the same VLAN on the same link. (See Section 4.2.4.3.)
5.2. 每个VLAN强制宣布RBn被指定为该VLAN转发器的任何RBn链路的根网桥ID集。当MSTP（多生成树协议）在链路上运行时，这是CIST（公共和内部生成树）的根网桥。这是为了快速检测两个第2层云意外合并的情况，以及在同一链路上可能暂时有两个DRB用于同一VLAN的情况。（见第4.2.4.3节。）
5.3. Optionally, per-VLAN Layer 2 multicast addresses derived from IPv4 IGMP and IPv6 MLD notification messages received from attached end nodes on that VLAN, indicating the location of listeners for these multicast addresses (see Section 4.5.5).
5.3. 可选地，每个VLAN第2层多播地址源自从该VLAN上连接的终端节点接收的IPv4 IGMP和IPv6 MLD通知消息，指示这些多播地址的侦听器的位置（参见第4.5.5节）。
5.4. Per-VLAN ESADI protocol participation flag, priority, and holding time. If this flag is one, it indicates that the RBridge wishes to receive such TRILL ESADI frames (see Section 4.2.5.1).
5.4. 每VLAN ESADI协议参与标志、优先级和保持时间。如果该标志为1，则表示RBridge希望接收此类颤音ESADI帧（见第4.2.5.1节）。
5.5. Per-VLAN appointed forwarder status lost counter (see Section 4.8.3).
5.5. 根据VLAN指定的转发器状态丢失计数器（见第4.8.3节）。
6. Optionally, the largest TRILL IS-IS frame that the RBridge can handle using the originatingLSPBufferSize TLV #14 (see Section 4.3).
6. 或者，RBridge可以使用原始LSPBufferSize TLV#14处理的最大颤音IS-IS帧（参见第4.3节）。
7. Optionally, a list of VLAN groups where address learning is shared across that VLAN group (see Section 4.8.4). Each VLAN group is a list of VLAN IDs, where the first VLAN ID listed in a group, if present, is the "primary" and the others are "secondary". This is to detect misconfiguration of features outside the scope of this document. RBridges that do not support features such as "shared VLAN learning" ignore this field.
7. （可选）VLAN组列表，其中地址学习在该VLAN组中共享（见第4.8.4节）。每个VLAN组都是一个VLAN ID列表，其中组中列出的第一个VLAN ID（如果存在）是“主要”的，而其他VLAN ID是“次要”的。这是为了检测本文档范围之外的功能配置错误。不支持“共享VLAN学习”等功能的RBridge忽略此字段。
8. Optionally, the Authentication TLV #10 (see Section 6).
8. 或者，验证TLV#10（参见第6节）。
RBridges that are the appointed VLAN-x forwarder for a link MAY participate in the TRILL ESADI protocol for that VLAN. But all transit RBridges MUST properly forward TRILL ESADI frames as if they were multicast TRILL Data frames. TRILL ESADI frames are structured like IS-IS frames but are always TRILL encapsulated on the wire as if they were TRILL Data frames.
作为链路指定VLAN-x转发器的RBridge可以参与该VLAN的TRILL ESADI协议。但是，所有传输桥必须正确地转发TRILL ESADI帧，就像它们是多播TRILL数据帧一样。TRILL ESADI帧的结构类似于IS-IS帧，但始终将TRILL封装在导线上，就像它们是TRILL数据帧一样。
Because of this forwarding, it appears to the ESADI protocol at an RBridge that it is directly connected by a shared virtual link to all other RBridges in the campus running ESADI for that VLAN. RBridges that do not implement the ESADI protocol or are not appointed forwarder for that VLAN do not decapsulate or locally process any TRILL ESADI frames they receive for that VLAN. In other words, these frames are transparently tunneled through transit RBridges. Such transit RBridges treat them exactly as multicast TRILL Data frames and no special processing is invoked due to such forwarding.
由于这种转发，在RBridge上的ESADI协议看来，它通过共享虚拟链路直接连接到校园中为该VLAN运行ESADI的所有其他RBridge。未实施ESADI协议或未被指定为该VLAN转发器的RBridge不会对其为该VLAN接收的任何TRILL ESADI帧进行解封装或本地处理。换句话说，这些帧是透明地通过传输桥传输的。这种传输RBridge将它们完全视为多播颤音数据帧，并且由于这种转发，不会调用任何特殊处理。
TRILL ESADI frames sent on an IEEE 802.3 link are structured as shown below. The outer VLAN tag will not be present if it was stripped by the port out of which the frame was sent.
在IEEE 802.3链路上发送的TRILL ESADI帧的结构如下所示。如果外部VLAN标记被发送帧的端口剥离，则它将不存在。
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address | Sending RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending RBridge Port MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (Dist. Tree) Nickname | Ingress (Origin) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges continued | Origin RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = L2-IS-IS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESADI Payload (formatted as IS-IS):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address | Sending RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending RBridge Port MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (Dist. Tree) Nickname | Ingress (Origin) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges continued | Origin RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = L2-IS-IS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESADI Payload (formatted as IS-IS):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRILL ESADI Frame Format
图10:TRILL ESADI帧格式
The Next Hop Destination Address or Outer.MacDA is the All-RBridges multicast address. The VLAN specified in the Outer.VLAN information will always be the Designated VLAN for the link on which the frame is sent. The V and R fields will be zero while the M field will be one. The VLAN specified in the Inner.VLAN information will be the VLAN to which the ESADI frame applies. The Origin RBridge MAC Address or Inner.MacSA MUST be a globally unique MAC address owned by the
下一跳目标地址或Outer.MacDA是所有RBridges多播地址。Outer.VLAN信息中指定的VLAN将始终是发送帧的链路的指定VLAN。V和R字段将为零，而M字段将为一。在Inner.VLAN信息中指定的VLAN将是ESADI帧应用到的VLAN。源RBridge MAC地址或Inner.MacSA必须是由拥有的全局唯一MAC地址
RBridge originating the ESADI frame, for example, any of its port MAC addresses, and each RBridge MUST use the same Inner.MacSA for all of the ESADI frames that RBridge originates.
发起ESADI帧的RBridge，例如，其任何端口MAC地址，并且每个RBridge必须对RBridge发起的所有ESADI帧使用相同的Inner.MacSA。
An RBridge does not send any Hellos because of participation in the ESADI protocol. The information available in the TRILL IS-IS link state database is sufficient to determine the ESADI DRB on the virtual link for the ESADI protocol for each VLAN. In particular, the link state database information for each RBridge includes the VLANs, if any, for which that RBridge is participating in the ESADI protocol, its priority for being selected as DRB for the ESADI protocol for each of those VLANs, its holding time, and its IS-IS system ID for breaking ties in priority.
RBridge不会因为参与ESADI协议而发送任何问候。TRILL IS-IS链路状态数据库中的可用信息足以确定每个VLAN的ESADI协议的虚拟链路上的ESADI DRB。具体地，每个RBridge的链路状态数据库信息包括该RBridge参与ESADI协议的vlan（如果有）、其被选择为这些vlan中的每个的ESADI协议的DRB的优先级、其保持时间以及其用于优先断开连接的is-is系统ID。
An RBridge need not perform any routing calculation because of participation in the ESADI protocol. Since all RBridges participating in ESADI for a particular VLAN appear to be connected to the same single virtual link, there are no routing decisions to be made. A participating RBridge merely transmits the ESADI frames it originates on this virtual link.
由于参与ESADI协议，RBridge无需执行任何路由计算。由于参与特定VLAN的ESADI的所有RBridge似乎都连接到同一个虚拟链路，因此不需要做出路由决策。参与的RBridge仅传输它在该虚拟链路上发起的ESADI帧。
The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual link. For robustness, a participating RBridge that determines that some other RBridge should be ESADI DRB on such a virtual link but has not received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB holding time MAY also send a TRILL-ESADI-CSNP on the virtual link. A participating RBridge that determines that no other RBridges are participating in the ESADI protocol for a particular VLAN SHOULD NOT send ESADI information or TRILL-ESADI-CSNPs on the virtual link for that VLAN.
ESADI DRB在ESADI虚拟链路上发送TRILL-ESADI-CSNP帧。为了稳健性，确定某个其他RBridge应为此类虚拟链路上的ESADI DRB，但至少在ESADI DRB保持时间内未接收或发送TRILL-ESADI-CSNP的参与RBridge也可在虚拟链路上发送TRILL-ESADI-CSNP。确定没有其他RBridge参与特定VLAN的ESADI协议的参与RBridge不应在该VLAN的虚拟链路上发送ESADI信息或TRILL ESADI CSNP。
The information distributed with the ESADI protocol is the list of local end-station MAC addresses known to the originating RBridge and, for each such address, a one-octet unsigned "confidence" rating in the range 0-254 (see Section 4.8).
与ESADI协议一起分发的信息是原始RBridge已知的本地终端站MAC地址列表，对于每个此类地址，0-254范围内的一个八位组无符号“置信度”评级（见第4.8节）。
It is intended to optionally provide for VLAN ID translation within RBridges, as specified in [VLAN-MAPPING]. This includes translating TRILL ESADI frames. If TRILL ESADI frames could contain VLAN IDs in arbitrary internal locations, such translation would be impractical. Thus, TRILL ESADI frames MUST NOT contain the VLAN ID of the VLAN to which they apply in the body of the frame after the Inner.VLAN tag.
按照[VLAN-MAPPING]中的规定，它旨在选择性地在RBridges中提供VLAN ID转换。这包括翻译颤音ESADI帧。如果TRILL ESADI帧可以在任意内部位置包含VLAN ID，那么这种转换将不切实际。因此，TRILL ESADI帧不得在帧体的Inner.VLAN标记后包含它们应用到的VLAN的VLAN ID。
This section describes the logical result desired. Alternative implementation methods may be used as long as they produce the same forwarding behavior.
本节描述了所需的逻辑结果。可以使用替代实现方法，只要它们产生相同的转发行为。
When building a forwarding table, an RBridge RB1 calculates shortest paths from itself as described in Appendix C.1 of [RFC1195]. Nicknames are added into the shortest path calculation as a final step, just as with an end node. If multiple RBridges, say, RBa and RBb, claim the same nickname, this is a transitory condition and one of RBa or RBb will defer and choose a new nickname. However, RB1 simply adds that nickname as if it were attached to both RBa and RBb, and uses its standard shortest path calculation to choose the next hop.
当建立转发表时，RBridge RB1根据[RFC1195]附录C.1中的描述，从自身计算最短路径。昵称作为最后一步添加到最短路径计算中，就像结束节点一样。如果多个RBridge（例如RBa和RBb）声明相同的昵称，这是暂时的情况，RBa或RBb中的一个将延迟并选择一个新昵称。然而，RB1只是简单地添加了这个昵称，就好像它同时附加到RBa和RBb一样，并使用其标准的最短路径计算来选择下一跳。
An ingress RBridge RB2 maps a native frame's known unicast destination MAC address and VLAN into an egress RBridge nickname. If RB2 learns addresses only from the observation of received and decapsulated frames, then such MAC addresses cannot be duplicated within a VLAN in RB2 tables because more recent learned information, if of a higher or equal confidence, overwrites previous information and, if of a lower confidence, is ignored. However, duplicates of the same MAC within a VLAN can appear in ESADI data and between ESADI data and addresses learned from the observation of received and decapsulated frames, entered by manual configuration, or learned through Layer 2 registration protocols. If duplicate MAC addresses occur within a VLAN, RB2 sends frames to the MAC with the highest confidence. If confidences are also tied between the duplicates, for consistency it is suggested that RB2 direct all such frames (or all such frames in the same ECMP flow) toward the same egress RBridge; however, the use of other policies will not cause a network problem since transit RBridges do not examine the Inner.MacDA for known unicast frames.
入口RBridge RB2将本机帧的已知单播目标MAC地址和VLAN映射到出口RBridge昵称。如果RB2仅通过观察接收到的和解除封装的帧来学习地址，则此类MAC地址不能在RB2表中的VLAN内复制，因为最近学习的信息（如果具有较高或相等的置信度）会覆盖以前的信息，如果具有较低的置信度，则会被忽略。但是，VLAN内同一MAC的副本可能出现在ESADI数据中，以及ESADI数据和通过观察接收到的和解封的帧、通过手动配置输入或通过第2层注册协议学习到的地址之间。如果VLAN中出现重复的MAC地址，RB2将以最高置信度向MAC发送帧。如果副本之间也存在信任关系，为了一致性，建议RB2将所有此类帧（或同一ECMP流中的所有此类帧）指向同一出口RBridge；但是，使用其他策略不会导致网络问题，因为transit RBridges不会检查Inner.MacDA中的已知单播帧。
There are two reasons why it is important to know what size of frame each inter-RBridge link in the campus can support:
了解校园中每个RBridge间链路可以支持的帧大小非常重要，原因有两个：
1. RBridge RB1 must know the size of link state information messages it can generate that will be guaranteed to be forwardable across all inter-RBridge links in the campus.
1. RBridge RB1必须知道它可以生成的链路状态信息消息的大小，这些消息将保证可在校园内的所有RBridge间链路上转发。
2. If traffic engineering tools know which links support larger than minimally acceptable data packet sizes, paths can be computed that can support large data packets.
2. 如果流量工程工具知道哪些链路支持大于最小可接受的数据包大小，则可以计算出支持大数据包的路径。
In a stable campus, there must ultimately be agreement among all RBridges on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for the proper operation of TRILL IS-IS. All RBridges MUST format their link state information messages to be in chunks of size no larger than what they believe Sz to be. Also, every RBridge RB1 SHOULD test each of its RBridge adjacencies, say, to RB2, to ensure that the RB1-RB2 link can forward packets of at least size Sz.
在一个稳定的校园内，所有RBridge之间必须最终就“Sz”的值达成一致，该值是校园可接受的最小RBridge间链路大小，以确保TRILL IS-IS的正常运行。所有RBridge都必须将其链路状态信息消息格式化为大小不超过其认为的Sz的块。此外，每个RBridge RB1应该测试其RBridge邻接的每个，例如到RB2，以确保RB1-RB2链路可以转发至少大小Sz的分组。
Sz has no direct effect on end stations and is not directly related to any end-station-to-end-station "path MTU". Methods of using Sz or any link MTU information gathered by TRILL IS-IS in the traffic engineering of routes or the determination of any path MTU is beyond the scope of this document. Native frames that, after TRILL encapsulation, exceed the MTU of a link on which they are sent will generally be discarded.
Sz对终端站没有直接影响，也与任何终端站到终端站的“路径MTU”没有直接关系。TRILL IS-IS在路线交通工程中收集的Sz或任何链路MTU信息的使用方法或任何路径MTU的确定超出了本文件的范围。在TRILL封装之后，超过发送它们的链接的MTU的本机帧通常将被丢弃。
Sz is determined by having each RBridge (optionally) advertise, in its LSP, its assumption of the value of the campus-wide Sz. This LSP element is known in IS-IS as the originatingLSPBufferSize, TLV #14. The default and minimum value for Sz, and the implicitly advertised value of Sz if the TLV is absent, is 1470 octets. This length (which is also the maximum size of a TRILL-Hello) was chosen to make it extremely unlikely that a TRILL control frame, even with reasonable additional headers, tags, and/or encapsulation, would encounter MTU problems on an inter-RBridge link.
Sz由每个RBridge（可选）在其LSP中公布其对校园Sz值的假设来确定。该LSP元素在is-is中称为原始LSPBufferSize，TLV#14。Sz的默认值和最小值，以及如果没有TLV，则Sz的隐式公布值为1470个八位字节。选择此长度（也是TRILL Hello的最大大小）是为了使TRILL控制帧（即使具有合理的附加头、标记和/或封装）在RBridge间链路上也极不可能遇到MTU问题。
The campus-wide value of Sz is the smallest value of Sz advertised by any RBridge.
校园范围内的Sz值是任何RBridge广告中Sz的最小值。
There are two new TRILL IS-IS message types for use between pairs of RBridge neighbors to test the bidirectional packet size capacity of their connection. These messages are:
有两种新的TRILL IS-IS消息类型可在成对的RBridge邻居之间使用，以测试其连接的双向数据包大小容量。这些信息是：
-- MTU-probe
-- MTU-ack
-- MTU-probe
-- MTU-ack
Both the MTU-probe and the MTU-ack are padded to the size being tested.
MTU探头和MTU ack均填充至被测尺寸。
Sending of MTU-probes is optional; however, an RBridge RB2 that receives an MTU-probe from RB1 MUST respond with an MTU-ack padded to the same size as the MTU-probe. The MTU-probe MAY be multicast to
发送MTU探头是可选的；但是，从RB1接收MTU探测的RBridge RB2必须使用与MTU探测大小相同的MTU ack进行响应。MTU探测可以多播到
All-RBridges, or unicast to a specific RBridge. The MTU-ack is normally unicast to the source of the MTU-probe to which it responds but MAY be multicast to All-RBridges.
所有RBridge，或单播到特定RBridge。MTU ack通常单播到其响应的MTU探测的源，但可以多播到所有RBRIGE。
If RB1 fails to receive an MTU-ack to a probe of size X from RB2 after k tries (where k is a configurable parameter whose default is 3), then RB1 assumes the RB1-RB2 link cannot support size X. If X is not greater than Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X > Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
如果RB1在k次尝试后未能从RB2接收到大小为X的探测器的MTU确认（其中k是一个可配置参数，默认值为3），则RB1假设RB1-RB2链路无法支持大小X。如果X不大于Sz，则RB1在RB1的Hello中为RB2设置“最小MTU测试失败”标志。如果大小X成功，且X>Sz，则RB1在该链接上发送的颤音Hellos中为每个邻接播发最大的测试X，并且RB1可以在RB1的LSP中将X作为链接的属性播发给RB2。
The TRILL-Hello protocol is a little different from the Layer 3 IS-IS LAN Hello protocol and uses a new type of IS-IS message known as a TRILL-Hello.
TRILL Hello协议与第3层is-is LAN Hello协议略有不同，它使用了一种称为TRILL Hello的新型is-is消息。
The reason for defining this new type of link in TRILL is that in Layer 3 IS-IS, the LAN Hello protocol may elect multiple Designated Routers (DRs) since, when choosing a DR, routers ignore other routers with whom they do not have 2-way connectivity. Also, Layer 3 IS-IS LAN Hellos are padded, to avoid forming adjacencies between neighbors that can't speak the maximum-sized packet to each other. This means, in Layer 3 IS-IS, that neighbors that have connectivity to each other, but with an MTU on that connection less than what they perceive as maximum sized packets, will not see each other's Hellos. The result is that routers might form cliques, resulting in the link turning into multiple pseudonodes.
在TRILL中定义这种新型链路的原因是，在第3层is-is中，LAN Hello协议可能会选择多个指定路由器（DRs），因为在选择DR时，路由器会忽略与其没有双向连接的其他路由器。此外，第3层IS-IS LAN hello被填充，以避免邻居之间形成邻接，从而无法相互说出最大大小的数据包。这意味着，在第3层IS-IS中，相互连接但MTU小于其认为的最大大小数据包的邻居将看不到彼此的问候。结果是路由器可能会形成集团，导致链路变成多个伪节点。
This behavior is fine for Layer 3, but not for Layer 2, where loops may form if there are multiple DRBs. Therefore, the TRILL-Hello protocol is a little different from Layer 3 IS-IS's LAN Hello protocol.
这种行为对于第3层很好，但对于第2层则不行，在第2层中，如果有多个DRB，可能会形成循环。因此，TRILL Hello协议与第3层is-is的LAN Hello协议略有不同。
One other issue with TRILL-Hellos is to ensure that subsets of the information can appear in any single message, and be processable, in the spirit of IS-IS LSPs and 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.
TRILL Hellos的另一个问题是，按照is-is LSP和CSNPs的精神，确保信息子集可以出现在任何单个消息中，并且是可处理的。颤音Hello帧，即使没有填充，也会变得非常大。一个可能出现这种情况的例子是，当某种主干网技术将数百个TRILL站点互连在一个看似巨大的以太网上时，连接到该云的RBridge将认为主干网是一条与数百个邻居相连的单一链路。
In TRILL (unlike in Layer 3 IS-IS), the DRB is selected based solely on priority and MAC address. In other words, if RB2 receives a TRILL-Hello from RB1 with higher (priority, MAC), RB2 defers to RB1 as DRB, regardless of whether RB1 lists RB2 in RB1's TRILL-Hello.
在TRILL中（与第3层IS-IS不同），DRB仅基于优先级和MAC地址进行选择。换句话说，如果RB2从RB1接收到具有更高优先级（MAC）的颤音Hello，RB2将以DRB的形式服从RB1，无论RB1是否在RB1的颤音Hello中列出RB2。
Although the neighbor list in a TRILL-Hello does not influence the DRB election, it does determine what is announced in LSPs. RB1 only reports links to RBridges with which it has two-way connectivity. If RB1 is the DRB on a link, and for whatever reason (MTU mismatch, or one-way connectivity) RB1 and RB2 do not have two-way connectivity, then RB2 does not report a link to RB1 (or the pseudonode), and RB1 (or RB1 on behalf of the pseudonode) does not report a link to RB2.
尽管TRILL Hello中的邻居列表不会影响DRB选举，但它确实决定了LSP中宣布的内容。RB1仅报告与具有双向连接的RBridge的链接。如果RB1是链路上的DRB，并且由于任何原因（MTU不匹配或单向连接），RB1和RB2没有双向连接，则RB2不会向RB1（或伪节点）报告链路，RB1（或代表伪节点的RB1）也不会向RB2报告链路。
The TRILL-Hello has a new IS-IS message type. It starts with the same fixed header as an IS-IS LAN Hello, which includes the 7-bit priority for the issuing RBridge to be DRB on that link. TRILL-Hellos are sent with the same timing as IS-IS LAN Hellos.
TRILL Hello有一个新的IS-IS消息类型。它以与IS-IS LAN Hello相同的固定报头开始，其中包括发出RBridge作为该链路上的DRB的7位优先级。TRILL Hello的发送时间与IS-IS LAN Hello的发送时间相同。
TRILL-Hello messages, including their Outer.MacDA and Outer.MacSA, but excluding any Outer.VLAN or other tags, MUST NOT exceed 1470 octets in length and SHOULD NOT be padded. The following information MUST appear in every TRILL-Hello. References to "TLV" may actually be a "sub-TLV" as specified in separate documents [RFC6165] [RFC6326].
TRILL Hello消息，包括它们的Outer.MacDA和Outer.MacSA，但不包括任何Outer.VLAN或其他标记，其长度不得超过1470个八位字节，并且不应填充。以下信息必须出现在每个颤音Hello中。参考“TLV”实际上可能是单独文件[RFC6165][RFC6326]中规定的“子TLV”。
1. The VLAN ID of the Designated VLAN for the link.
1. 链接的指定VLAN的VLAN ID。
2. A copy of the Outer.VLAN ID with which the Hello was tagged on sending.
2. 发送时标记Hello的Outer.VLAN ID的副本。
3. A 16-bit port ID assigned by the sending RBridge to the port the TRILL-Hello is sent on such that no two ports of that RBridge have the same port ID.
3. 由发送RBridge分配给TRILL Hello发送端口的16位端口ID，使得该RBridge的两个端口没有相同的端口ID。
4. A nickname of the sending RBridge.
4. 一个寄信人的昵称。
5. Two flags as follows:
5. 两面旗帜如下：
5.a. A flag that, if set, indicates that the sender has detected VLAN mapping on the link, within the past 2 of its Holding Times.
5.a。一种标志，如果设置了该标志，则表明发送方在其保持时间的过去2个时间内已在链路上检测到VLAN映射。
5.b. A flag that, if set, indicates that the sender believes it is appointed forwarder for the VLAN and port on which the TRILL-Hello was sent.
5.b。一个标志，如果设置，则表示发送方认为它是VLAN和发送TRILL Hello的端口的指定转发器。
The following information MAY appear:
可能会出现以下信息：
1. The set of VLANs for which end-station service is enabled on the port.
1. 端口上为其启用端站服务的VLAN集。
2. Several flags as follows:
2. 几面旗帜如下：
2.a. A flag that, if set, indicates that the sender's port was configured as an access port.
2.a。一种标志，如果设置，则表示发送方的端口已配置为访问端口。
2.b. A flag that, if set, indicates that the sender's port was configured as a trunk port.
2.b。一种标志，如果设置，则表示发送方的端口已配置为中继端口。
2.c. A bypass pseudonode flag, as described below in this section.
2.c。旁路伪节点标志，如本节下文所述。
3. If the sender is the DRB, the Rbridges (excluding itself) that it appoints as forwarders for that link and the VLANs for which it appoints them. As described below, this TLV is designed so that not all the appointment information need be included in each Hello. Its absence means that appointed forwarders should continue as previously assigned.
3. 如果发送方是DRB，则为该链路指定作为转发器的RBridge（不包括其自身）以及为其指定的VLAN。如下所述，此TLV的设计目的是使每个Hello中不需要包含所有约会信息。其缺位意味着指定的货运代理应继续按照先前指定的方式进行。
4. The TRILL neighbor list. This is a new TLV, not the same as the IS-IS Neighbor TLV, in order to accommodate fragmentation and reporting MTU on the link (see Section 4.4.2.1).
4. 颤音邻居列表。这是一个新的TLV，与is-is相邻TLV不同，以适应链路上的碎片和报告MTU（见第4.4.2.1节）。
The Appointed Forwarders TLV specifies a range of VLANs and, within that range, specifies which Rbridge, if any, other than the DRB, is appointed forwarder for the VLANs in that range [RFC6326]. Appointing an RBridge as forwarder on a port for a VLAN that is not enabled on that port has no effect.
指定的转发器TLV指定VLAN的范围，并在该范围内指定除DRB之外的哪个Rbridge（如果有）是该范围内VLAN的指定转发器[RFC6326]。将RBridge指定为该端口上未启用的VLAN的端口上的转发器无效。
It is anticipated that many links between RBridges will be point-to-point, in which case using a pseudonode merely adds to the complexity. If the DRB specifies the bypass pseudonode bit in its TRILL-Hellos, the RBridges on the link just report their adjacencies as point-to-point. This has no effect on how LSPs are flooded on a link. It only affects what LSPs are generated.
预计RBridge之间的许多链路将是点对点的，在这种情况下，使用伪节点只会增加复杂性。如果DRB在TRILL Hellos中指定了旁路伪节点位，则链路上的RBridge只报告它们的邻接为点对点。这对LSP在链路上被淹没的方式没有影响。它只影响生成的LSP。
For example, if RB1 and RB2 are the only RBridges on the link and RB1 is the 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.
例如，如果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 for its links unless, for a particular link, it has seen at least two simultaneous adjacencies on the link at some point since it last rebooted.
DRB应该为其链路设置旁路伪节点位，除非对于特定链路，自上次重新启动以来，它在某个点上至少看到两个同时相邻的链路。
The new TRILL Neighbor TLV includes the following information for each neighbor it lists:
新的TRILL Neighbor TLV包括其列出的每个邻居的以下信息：
1. The neighbor's MAC address.
1. 邻居的MAC地址。
2. MTU size to this neighbor as a 2-octet unsigned integer in units of 4-octet chunks. The value zero indicates that the MTU is untested.
2. 此邻居的MTU大小为以4个八位字节块为单位的2个八位无符号整数。值为零表示MTU未经测试。
3. A flag for "failed minimum MTU test".
3. “最低MTU测试失败”的标志。
To allow partial reporting of neighbors, the neighbor IDs MUST be sorted by ID. If a set of neighbors { X1, X2, X3, ... Xn } is reported in RB1's Hello, then X1 < X2 < X3, ... < Xn. If RBridge RB2's ID is between X1 and Xn, and does not appear in RB1's Hello, then RB2 knows that RB1 has not heard RB2's Hello.
为了允许邻居的部分报告，邻居ID必须按ID排序。如果在RB1的Hello中报告了一组邻居{X1，X2，X3，…Xn}，那么X1<X2<X3，…<Xn。如果RBridge RB2的ID在X1和Xn之间，并且没有出现在RB1的Hello中，那么RB2知道RB1没有听到RB2的Hello。
Additionally there are two overall TRILL Neighbor List TLV flags: "the smallest ID I reported in this Hello is the smallest ID of any neighbor", and "the largest ID I reported in this Hello is the largest ID of any neighbor". If all the neighbors fit in RB1's TRILL-Hello, both flags will be set.
此外，还有两个完整的颤音邻居列表TLV标志：“我在这个Hello中报告的最小ID是任何邻居的最小ID”，以及“我在这个Hello中报告的最大ID是任何邻居的最大ID”。如果所有的邻居都适合RB1的颤音Hello，则将设置两个标志。
If RB1 reports { X1, ... Xn } in its Hello, with the "smallest" flag set, and RB2's ID is smaller than X1, then RB2 knows that RB1 has not heard RB2's Hello. Similarly, if RB2's ID is larger than Xn and the "largest" flag is set, then RB2 knows that RB1 has not heard RB2's Hello.
如果RB1在其Hello中报告{X1，…Xn}，并设置了“最小”标志，并且RB2的ID小于X1，那么RB2知道RB1没有听到RB2的Hello。类似地，如果RB2的ID大于Xn并且设置了“最大”标志，那么RB2知道RB1没有听到RB2的Hello。
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 the 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 also appear as the largest ID reported in a different TRILL-Hello neighbor list. Or, fragments may overlap, as long as there is no gap, such that some range, say, between Xi and Xj, never appears in any fragment.
为确保任何RBridge RB2都能确定RB1是否能听到RB2，RB1的邻居列表最终必须覆盖所有可能的ID范围，也就是说，在取决于RB1的策略的时间段内，而不一定在任何特定的时间段内，如等待时间。换句话说，如果X1是RB1的一个邻居列表中报告的最小ID，并且未设置“最小”标志，那么X1也必须显示为不同TRILL Hello邻居列表中报告的最大ID。或者，碎片可能重叠，只要没有间隙，这样的范围，例如，在席和XJ之间，永远不会出现在任何片段中。
The MTU-probe mechanism is designed to determine the MTU for transmissions between RBridges. MTU-probes and probe acknowledgements are only sent on the Designated VLAN.
MTU探测机构设计用于确定RBridge之间传输的MTU。MTU探测和探测确认仅在指定的VLAN上发送。
An RBridge RBn maintains for each port the same VLAN information as a customer IEEE [802.1Q-2005] bridge, including the set of VLANs enabled for output through that port (see Section 4.9.2). In addition, RBn maintains the following TRILL-specific VLAN parameters per port:
RBridge RBn为每个端口维护与客户IEEE[802.1Q-2005]网桥相同的VLAN信息，包括通过该端口输出的VLAN集（见第4.9.2节）。此外，RBn为每个端口维护以下特定于TRILL的VLAN参数：
a) Desired Designated VLAN: the VLAN that RBn, if it is the DRB, will specify in its TRILL-Hellos as the VLAN to be used by all RBridges on the link to communicate all TRILL frames, except some TRILL-Hellos. This MUST be a VLAN enabled on RBn's port. It defaults to the numerically lowest enabled VLAN ID, which is VLAN 1 for a default configuration RBridge.
a) 所需指定VLAN：RBn（如果它是DRB）将在其TRILL Hello中指定为VLAN的VLAN，该VLAN将由链路上的所有RBridge用于通信所有TRILL帧，某些TRILL Hello除外。这必须是RBn端口上启用的VLAN。它默认为数字上最低的启用VLAN ID，即默认配置RBridge的VLAN 1。
b) Designated VLAN: the VLAN being used on the link for all TRILL frames except some TRILL Hellos. This is RBn's Desired Designated VLAN if RBn believes it is the DRB or the Designated VLAN in the DRB's Hellos if RBn is not the DRB.
b) 指定VLAN：除一些TRILL Hello外，所有TRILL帧在链路上使用的VLAN。如果RBn认为这是DRB，则这是RBn所需的指定VLAN；如果RBn不是DRB，则这是DRB的Hellos中的指定VLAN。
c) Announcing VLANs set. This defaults to the enabled VLANs set on the port but may be configured to be a subset of the enabled VLANs.
c) 宣布VLAN设置。这默认为端口上设置的已启用VLAN，但可以配置为已启用VLAN的子集。
d) Forwarding VLANs set: the set of VLANs for which an RBridge port is appointed VLAN forwarder on the port. This MUST contain only enabled VLANs for the port, possibly all enabled VLANs.
d) 转发VLAN集：将RBridge端口指定为端口上的VLAN转发器的VLAN集。这必须只包含端口的已启用VLAN，可能包含所有已启用VLAN。
On each of its ports that is not configured to use P2P Hellos, an RBridge sends TRILL-Hellos Outer.VLAN tagged with each VLAN in a set of VLANs. This set depends on the RBridge's DRB status and the above VLAN parameters. RBridges send TRILL Hellos Outer.VLAN tagged with the Designated VLAN, unless that VLAN is not enabled on the port. In addition, the DRB sends TRILL Hellos Outer.VLAN tagged with each enabled VLAN in its Announcing VLANs set. All non-DRB RBridges send TRILL-Hellos Outer.VLAN tagged with all enabled VLANs that are in the intersection of their Forwarding VLANs set and their Announcing VLANs set. More symbolically, TRILL-Hello frames, when sent, are sent as follows:
在其未配置为使用P2P Hellos的每个端口上，RBridge发送TRILL Hellos Outer.VLAN，并在一组VLAN中标记每个VLAN。此设置取决于RBridge的DRB状态和上述VLAN参数。RBridges发送带有指定VLAN标记的TRILL Hellos Outer.VLAN，除非端口上未启用该VLAN。此外，DRB发送TRILL Hellos Outer.VLAN，并在其公布的VLAN集中标记每个启用的VLAN。所有非DRB RBridges发送TRILL Hellos Outer.VLAN，标记所有已启用的VLAN，这些VLAN位于其转发VLAN集和宣布VLAN集的交叉点。更具象征意义的是，TRILL Hello帧在发送时按如下方式发送：
If sender is DRB intersection ( Enabled VLANs, union ( Designated VLAN, Announcing VLANs ) )
如果发送方是DRB交叉点（启用的VLAN、联合（指定的VLAN、宣布的VLAN））
If sender is not DRB intersection ( Enabled VLANs, union ( Designated VLAN, intersection ( Forwarding VLANs, Announcing VLANs ) ) )
如果发送方不是DRB交叉点（已启用VLAN、联合（指定VLAN、交叉点（转发VLAN、宣布VLAN）））
Configuring the Announcing VLANs set to be null minimizes the number of TRILL-Hellos. In that case, TRILL-Hellos are only tagged with the Designated VLAN. Great care should be taken in configuring an RBridge to not send TRILL Hellos on any VLAN where that RBridge is appointed forwarder as, under some circumstances, failure to send such Hellos can lead to loops.
将公布VLAN设置为null可最大限度地减少TRILL Hello的数量。在这种情况下，TRILL Hello只使用指定的VLAN进行标记。在将RBridge配置为不在任何VLAN上发送TRILL Hello时应特别小心，因为在某些情况下，如果RBridge被指定为转发器，发送此类Hello的失败可能会导致循环。
The number of TRILL-Hellos is maximized, within this specification, by configuring the Announcing VLANs set to be the set of all enabled VLAN IDs, which is the default. In that case, the DRB will send TRILL-Hello frames tagged with all its Enabled VLAN tags; in addition, any non-DRB RBridge RBn will send TRILL-Hello frames tagged with the Designated VLAN, if enabled, and tagged with all VLANs for which RBn is an appointed forwarder. (It is possible to send even more TRILL-Hellos. In particular, non-DRB RBridges could send TRILL-Hellos on enabled VLANs for which they are not an appointed forwarder and which are not the Designated VLAN. This would cause no harm other than a further communications and processing burden.)
在本规范中，通过将公布的VLAN集配置为所有启用的VLAN ID集（这是默认设置），TRILL Hello的数量最大化。在这种情况下，DRB将发送带有所有已启用VLAN标记的TRILL Hello帧；此外，任何非DRB RBridge RBn将发送带有指定VLAN标记的TRILL Hello帧（如果启用），并带有RBn作为指定转发器的所有VLAN标记。（可以发送更多的TRILL Hello。特别是，非DRB RBridges可以在启用的VLAN上发送TRILL Hello，这些VLAN不是指定的转发器，也不是指定的VLAN。这不会造成任何伤害，只会增加通信和处理负担。）
When an RBridge port comes up, until it has heard a TRILL-Hello from a higher priority RBridge, it considers itself to be DRB on that port and sends TRILL-Hellos on that basis. Similarly, even if it has at some time recognized some other RBridge on the link as DRB, if it receives no TRILL-Hellos on that port from an RBridge with higher priority as DRB for a long enough time, as specified by IS-IS, it will revert to believing itself DRB.
当RBridge端口出现时，直到它听到来自更高优先级RBridge的颤音Hello，它认为自己是该端口上的DRB，并在此基础上发送颤音Hello。类似地，即使它在某个时间已将链路上的某个其他RBridge识别为DRB，如果它在该端口上没有从具有较高优先级的RBridge接收到作为DRB的颤音hello足够长的时间（如IS-IS所规定），它将恢复相信自己是DRB。
It is possible for an RBridge RB1 to have multiple ports to the same link. It is important for RB1 to recognize which of its ports are on the same link, so, for instance, if RB1 is appointed forwarder for VLAN A, RB1 knows that only one of its ports acts as appointed forwarder for VLAN A on that link.
RBridge RB1可能有多个端口连接到同一链路。RB1必须识别其端口中的哪些位于同一链路上，因此，例如，如果RB1是VLAN A的指定转发器，RB1知道只有一个端口充当该链路上VLAN A的指定转发器。
RB1 detects this condition based on receiving TRILL-Hello messages with the same IS-IS pseudonode ID on multiple ports. RB1 might have one set of ports, say, { p1, p2, p3 } on one link, and another set of ports { p4, p5 } on a second link, and yet other ports, say, p6, p7, p8, that are each on distinct links. Let us call a set of ports on the same link a "port group".
RB1基于在多个端口上接收具有相同IS-IS伪节点ID的TRILL Hello消息来检测此情况。RB1可能在一条链路上有一组端口，比如说，{p1，p2，p3}，在第二条链路上有另一组端口{p4，p5}，还有其他端口，比如说，p6，p7，p8，它们各自位于不同的链路上。让我们将同一链路上的一组端口称为“端口组”。
If RB1 detects that a set of ports, say, { p1, p2, p3 }, is a port group on a link, then RB1 MUST ensure that it does not cause loops when it encapsulates and decapsulates traffic from/to that link. If RB1 is appointed forwarder for VLAN A on that Ethernet link, RB1 MUST encapsulate/decapsulate VLAN A on only one of the ports. However, if RB1 is appointed forwarder for more than one VLAN, RB1 MAY choose to load split among its ports, using one port for some set of VLANs, and another port for a disjoint set of VLANs.
如果RB1检测到一组端口（例如，{p1，p2，p3}）是链路上的端口组，则RB1必须确保在封装和解除封装来自/到该链路的流量时不会导致循环。如果RB1被指定为该以太网链路上VLAN A的转发器，则RB1必须仅在其中一个端口上封装/解除封装VLAN A。但是，如果RB1被指定为多个VLAN的转发器，RB1可以选择在其端口之间进行负载拆分，将一个端口用于某些VLAN集，另一个端口用于不相交的VLAN集。
If RB1 detects VLAN mapping occurring (see Section 4.4.5), then RB1 MUST NOT load split as appointed forwarder, and instead MUST act as appointed VLAN forwarder on that link on only one of its ports in the port group.
如果RB1检测到发生VLAN映射（请参见第4.4.5节），则RB1不得作为指定转发器加载拆分，而必须在该链路上仅在端口组中的一个端口上作为指定VLAN转发器。
When forwarding TRILL-encapsulated multi-destination frames to/from a link on which RB1 has a port group, RB1 MAY choose to load split among its ports, provided that it does not duplicate frames, and provided that it keeps frames for the same flow on the same port. If RB1's neighbor on that link, RB2, accepts multi-destination frames on that tree on that link from RB1, RB2 MUST accept the frame from any of RB2's adjacencies to RB1 on that link.
当向RB1具有端口组的链路转发TRILL封装的多目标帧时，RB1可以选择在其端口之间加载拆分，前提是它不复制帧，并且在同一端口上保留相同流的帧。如果该链路上RB1的邻居RB2从RB1接受该链路上该树上的多目标帧，则RB2必须从该链路上RB2与RB1的任何相邻处接受该帧。
If an RBridge has more than one port connected to a link and those ports have the same MAC address, they can be distinguished by the port ID contained in TRILL-Hellos.
如果RBridge有多个端口连接到链路，并且这些端口具有相同的MAC地址，则可以通过TRILL Hellos中包含的端口ID来区分这些端口。
IEEE [802.1Q-2005] does not provide for bridges changing the C-tag VLAN ID for a tagged frame they receive, that is, mapping VLANs. Nevertheless, some bridge products provide this capability and, in any case, bridged LANs can be configured to display this behavior. For example, a bridge port can be configured to strip VLAN tags on output and send the resulting untagged frames onto a link leading to another bridge's port configured to tag these frames with a different VLAN. Although each port's configuration is legal under [802.1Q-2005], in the aggregate they perform manipulations not permitted on a single customer [802.1Q-2005] bridge. Since RBridge ports have the same VLAN capabilities as customer [802.1Q-2005] bridges, this can occur even in the absence of bridges. (VLAN mapping is referred to in IEEE 802.1 as "VLAN ID translation".)
IEEE[802.1Q-2005]未规定网桥更改其接收的标记帧的C标记VLAN ID，即映射VLAN。然而，一些网桥产品提供了这种功能，并且在任何情况下，网桥LAN都可以配置为显示这种行为。例如，可以将网桥端口配置为在输出上剥离VLAN标记，并将生成的未标记帧发送到指向另一个网桥端口的链路上，该网桥端口配置为使用不同的VLAN标记这些帧。尽管每个端口的配置在[802.1Q-2005]下都是合法的，但总体而言，它们在单个客户[802.1Q-2005]网桥上执行不允许的操作。由于RBridge端口具有与客户[802.1Q-2005]网桥相同的VLAN功能，因此即使在没有网桥的情况下也可能发生这种情况。（在IEEE 802.1中，VLAN映射称为“VLAN ID转换”。）
RBridges include the Outer.VLAN ID inside every TRILL-Hello message. When a TRILL-Hello is received, RBridges compare this saved copy with the Outer.VLAN ID information associated with the received frame. If these differ and the VLAN ID inside the Hello is X and the Outer.VLAN is Y, it can be assumed that VLAN ID X is being mapped into VLAN ID Y.
RBridges在每个TRILL Hello消息中包含Outer.VLAN ID。当接收到颤音Hello时，RBridges会将此保存的副本与接收到的帧关联的Outer.VLAN ID信息进行比较。如果这些不同，并且Hello内的VLAN ID为X，Outer.VLAN为Y，则可以假定VLAN ID X映射到VLAN ID Y。
When non-DRB RB2 detects VLAN mapping, based on receiving a TRILL-Hello where the VLAN tag in the body of the Hello differs from the one in the outer header, it sets a flag in all of its TRILL-Hellos for a period of two of its Holding Times since the last time RB2 detected VLAN mapping. When DRB RB1 is informed of VLAN mapping, either because of receiving a TRILL-Hello that has been VLAN-mapped, or because of seeing the "VLAN mapping detected" flag in a neighbor's TRILL-Hello on the link, RB1 re-assigns VLAN forwarders to ensure there is only a single forwarder on the link for all VLANs.
当非DRB RB2检测到VLAN映射时，基于接收到TRILL Hello，其中Hello正文中的VLAN标记与外部报头中的VLAN标记不同，它会在其所有TRILL Hello中设置一个标志，自RB2上次检测到VLAN映射以来保持两次。当DRB RB1收到VLAN映射通知时，无论是因为接收到已映射VLAN的TRILL Hello，还是因为在链路上的邻居TRILL Hello中看到“检测到VLAN映射”标志，RB1都会重新分配VLAN转发器，以确保所有VLAN的链路上只有一个转发器。
RBridges use distribution trees to forward multi-destination frames (see Section 2.4.2). Distribution trees are bidirectional. Although a single tree is logically sufficient for the entire campus, the computation of additional distribution trees is warranted for the following reasons: it enables multipathing of multi-destination frames and enables the choice of a tree root closer to or, in the limit, identical with the ingress RBridge. Such a closer tree root improves the efficiency of the delivery of multi-destination frames that are being delivered to a subset of the links in the campus and reduces out-of-order delivery when a unicast address transitions between unknown and known. If applications are in use where occasional out-of-order unicast frames due to such transitions are a problem, the RBridge campus should be engineered to make sure they are of extremely low probability, such as by using the ESADI protocol, configuring addresses to eliminate unknown destination unicast frames, or using keep alive frames.
RBridge使用分布树转发多目标帧（见第2.4.2节）。分布树是双向的。尽管一棵树在逻辑上足以用于整个校园，但由于以下原因，额外分布树的计算是有保证的：它支持多目标帧的多路径传输，并支持选择更接近或在限制范围内与入口RBridge相同的树根。这种更紧密的树根提高了多目标帧的传递效率，这些多目标帧正被传递到校园中的链路子集，并在单播地址在未知和已知地址之间转换时减少无序传递。如果应用程序在使用过程中，由于此类转换导致偶尔出现无序单播帧是一个问题，则应对RBridge园区进行设计，以确保其概率极低，例如通过使用ESADI协议、配置地址以消除未知目标单播帧，或使用保持活动帧。
An additional level of flexibility is the ability of an RBridge to acquire multiple nicknames, and therefore have multiple trees rooted at the same RBridge. Since the tree number is used as a tiebreaker for equal cost paths, the different trees, even if rooted at the same RBridge, will likely utilize different equal cost paths.
另一个灵活性级别是RBridge获取多个昵称的能力，因此在同一RBridge上有多棵树。由于树编号用作等成本路径的分界线，因此不同的树，即使根在同一个RBridge，也可能使用不同的等成本路径。
How an ingress RBridge chooses the distribution tree or trees that it uses for multi-destination frames is beyond the scope of this document. However, for the reasons stated above, in the absence of other factors, a good choice is the tree whose root is least cost from the ingress RBridge and that is the default for an ingress RBridge that uses a single tree to distribute multi-destination frames.
入口RBridge如何选择用于多目标帧的分发树超出了本文档的范围。然而，出于上述原因，在没有其他因素的情况下，一个好的选择是根是入口RBridge的最小成本的树，这是使用单个树来分发多个目的地帧的入口RBridge的默认树。
RBridges will precompute all the trees that might be used, and keep state for Reverse Path Forwarding Check filters (see Section 4.5.2). Also, since the tree number is used as a tiebreaker, it is important for all RBridges to know:
RBridges将预计算所有可能使用的树，并保持反向路径转发检查过滤器的状态（见第4.5.2节）。此外，由于树编号用作分条线，因此所有RBridge都必须了解：
o how many trees to compute o which trees to compute o what the tree number for each tree is o which trees each ingress RBridge might choose (for building Reverse Path Forwarding Check filters)
o 要计算多少棵树o要计算哪些树o每个树的树数是多少o每个入口RBridge可以选择哪些树（用于构建反向路径转发检查过滤器）
Each RBridge advertises in its LSP a "tree root" priority for its nickname or for each of its nicknames if it has been configured to have more than one. This is a 16-bit unsigned integer that defaults, for an unconfigured RBridge, to 0x8000. Tree roots are ordered with highest numerical priority being highest priority, then with system ID of the RBridge (numerically higher = higher priority) as tiebreaker, and if that is equal, by the numerically higher nickname value, as an unsigned integer, having priority.
每个RBridge在其LSP中为其昵称或其每个昵称（如果已配置为具有多个昵称）发布“树根”优先级。这是一个16位无符号整数，对于未配置的RBridge，默认为0x8000。树根以最高数字优先级为最高优先级进行排序，然后以RBridge的系统ID（数字更高=更高优先级）作为分界符，如果相等，则以数字更高的昵称值作为无符号整数，具有优先级。
Each RBridge advertises in its LSP the maximum number of distribution trees that it can compute and the number of trees that it wants all RBridges in the campus to compute. The number of trees, k, that are computed for the campus is the number wanted by the RBridge RB1, which has the nickname with the highest "tree root" priority, but no more than the number of trees supported by the RBridge in the campus that supports the fewest trees. If RB1 does not specify the specific distribution tree roots as described below, then the k highest priority trees are the trees that will be computed by all RBridges. Note that some of these k highest priority trees might be rooted at the same RBridge, if that RBridge has multiple nicknames.
每个RBridge在其LSP中公布其可以计算的分发树的最大数量以及它希望校园中所有RBridge计算的树的数量。为校园计算的树的数量k是RBridge RB1想要的数量，它的昵称具有最高的“树根”优先级，但不超过校园中支持最少树的RBridge支持的树的数量。如果RB1没有指定如下所述的特定分布树根，那么k个最高优先级的树就是将由所有rbridge计算的树。请注意，如果RBridge有多个昵称，那么这些k个最高优先级的树中的一些可能根在同一个RBridge上。
If an RBridge specifies the number of trees it can compute, or the number of trees it wants computed for the campus, as 0, it is treated as specifying them as 1. Thus, k defaults to 1.
如果RBridge指定它可以计算的树的数量，或者它希望为校园计算的树的数量为0，则视为将它们指定为1。因此，k默认为1。
In addition, the RBridge RB1 having the highest root priority nickname might explicitly advertise a set of s trees by providing a list of s nicknames. In that case, the first k of those s trees will be computed. If s is less than k, or if any of the s nicknames associated with the trees RB1 is advertising does not exist within the LSP database, then the RBridges still compute k trees, but the remaining trees they select are the highest priority trees, such that k trees are computed.
此外，具有最高根优先级昵称的RBridge RB1可以通过提供s昵称列表来显式地通告一组s树。在这种情况下，将计算这些s树中的前k个。如果s小于k，或者如果与树RB1相关联的s昵称中的任何一个在LSP数据库中不存在，则rbridge仍然计算k棵树，但是它们选择的其余树是最高优先级的树，从而计算k棵树。
There are two exceptions to the above, which can cause fewer distribution trees to be computed, as follows:
上述情况有两个例外，这可能导致计算的分布树更少，如下所示：
o A nickname whose tree root priority is zero is not selected as a tree root based on priority, although it may be selected by being listed by the RBridge holding the highest priority tree root nickname. The one exception to this is that if all nicknames have priority zero, then the highest priority among them as determined
o 树根优先级为零的昵称不会根据优先级选择为树根，尽管它可以通过由拥有最高优先级树根昵称的RBridge列出来选择。唯一的例外是，如果所有昵称的优先级都为零，那么它们中的最高优先级将被确定
by the tiebreakers is used as a tree root so that there is always guaranteed to be at least one distribution tree.
由tiebreakers作为树根使用，因此始终保证至少有一个分发树。
o As a transient condition, two or more identical nicknames can appear in the list of roots for trees to be computed. In such a case, it is useless to compute a tree for the nickname(s) that are about to be lost by the RBridges holding them. So a distribution tree is only computed for the instance of the nickname where the priority to hold that nickname value is highest, reducing the total number of trees computed. (It would also be of little use to go further down the priority ordered list of possible tree root nicknames to maintain the number of trees as the additional tree roots found this way would only be valid for a very brief nickname transition period.)
o 作为一种暂时情况，两个或多个相同的昵称可能会出现在要计算的树的根列表中。在这种情况下，为昵称计算一棵树是没有用的，因为持有昵称的RBridges将丢失这些昵称。因此，仅针对昵称实例计算分布树，其中保持该昵称值的优先级最高，从而减少计算的树总数。（进一步深入可能的树根昵称的优先级排序列表以保持树的数量也没有多大用处，因为通过这种方式找到的附加树根仅在非常短的昵称过渡期内有效。）
The k trees calculated for a campus are ordered and numbered from 1 to k. In addition to advertising the number k, RB1 might explicitly advertise a set of s trees by providing a list of s nicknames as described above.
为一个校园计算的k棵树按顺序排列，并从1到k编号。除了宣传数字k之外，RB1还可以通过提供如上所述的昵称列表来明确宣传一组s树。
- If s == k, then the trees are numbered in the order that RB1 advertises them.
- 如果s==k，则按照RB1播发树的顺序对树进行编号。
- If s == 0, then the trees are numbered in order of decreasing priority. For example, if RB1 advertises only that k=2, then the highest priority tree is number 1 and the 2nd highest priority tree is number 2.
- 如果s==0，则按优先级递减的顺序对树进行编号。例如，如果RB1仅播发k=2，则最高优先级树是数字1，第二高优先级树是数字2。
- If s < k, then those advertised by RB1 are numbered from 1 in the order advertised. Then the remainder are chosen by priority order from among the remaining possible trees with the numbering continuing. For example, if RB1 advertises k=4, advertises { Tx, Ty } as the nicknames of the root of the trees, and the campus-wide priority ordering of trees in decreasing order is Ty > Ta > Tc > Tb > Tx, the numbering will be as follows: Tx is 1 and Ty is 2 since that is the order they are advertised in by RB1. Then Ta is 3 and Tc is 4 because they are the highest priority trees that have not already been numbered.
- 如果s<k，则RB1所公布的内容按公布的顺序从1开始编号。然后，按照优先级顺序从剩余可能的树中选择剩余的树，并继续编号。例如，如果RB1播发k=4，播发{Tx，Ty}作为树的根的昵称，并且校园范围内树的优先级顺序按降序为Ty>Ta>Tc>Tb>Tx，则编号如下：Tx为1，Ty为2，因为这是RB1播发树的顺序。然后Ta是3，Tc是4，因为它们是尚未编号的最高优先级树。
RBridges do not use spanning tree to calculate distribution trees. Instead, distribution trees are calculated based on the link state information, selecting a particular RBridge nickname as the root. Each RBridge RBn independently calculates a tree rooted at RBi by performing the SPF (Shortest Path First) calculation with RBi as the root without requiring any additional exchange of information.
RBridges不使用生成树来计算分布树。相反，根据链路状态信息计算分布树，选择特定的RBridge昵称作为根。每个RBridge RBn通过执行以RBi为根的SPF（最短路径优先）计算来独立计算以RBi为根的树，而不需要任何额外的信息交换。
It is important, when building a distribution tree, that all RBridges choose the same links for that tree. Therefore, when there are equal cost paths for a particular tree, all RBridges need to use the same tiebreakers. It is also desirable to allow splitting of traffic on as many links as possible. For this reason, a simple tiebreaker such as "always choose the parent with lower ID" would not be desirable. Instead, TRILL uses the tree number as a parameter in the tiebreaking algorithm.
在构建分发树时，所有RBridge都必须为该树选择相同的链接，这一点很重要。因此，当某棵树的成本路径相等时，所有RBridge都需要使用相同的分接器。还希望允许在尽可能多的链路上拆分流量。出于这个原因，不需要像“始终选择ID较低的父项”这样的简单分界线。相反，TRILL使用树编号作为分层算法中的参数。
When building the tree number j, remember all possible equal cost parents for node N. After calculating the entire "tree" (actually, directed graph), for each node N, if N has "p" parents, then order the parents in ascending order according to the 7-octet IS-IS ID considered as an unsigned integer, and number them starting at zero. For tree j, choose N's parent as choice j mod p.
在构建树编号j时，记住节点N的所有可能的等成本父节点。在计算整个“树”（实际上是有向图）之后，对于每个节点N，如果N有“p”父节点，则根据7个八位组的IS-IS-ID（视为无符号整数）按升序排列父节点，并从零开始对它们进行编号。对于树j，选择N的父项作为选项j mod p。
Note that there might be multiple equal cost links between N and potential parent P that have no pseudonodes, because they are either point-to-point links or pseudonode-suppressed links. Such links will be treated as a single link for the purpose of tree building, because they all have the same parent P, whose IS-IS ID is "P.0".
请注意，N和潜在父节点P之间可能存在多个没有伪节点的等成本链路，因为它们是点到点链路或伪节点抑制链路。为了构建树，这些链接将被视为单个链接，因为它们都具有相同的父级P，其IS-IS ID为“P.0”。
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from N to R and that have distinct IS-IS IDs, based on what is reported in LSPs.
换言之，对于根在R的树，N的潜在父级集合由那些提供从N到R的相同最小代价路径的父级集合组成，并且基于lsp中报告的内容，这些父级集合具有不同的IS-IS id。
When a multi-destination TRILL-encapsulated frame is received by an RBridge, there are four checks performed, each of which may cause the frame to be discarded:
当RBridge接收到多目的地颤音封装帧时，执行四个检查，每个检查都可能导致丢弃该帧：
1. Tree Adjacency Check: Each RBridge RBn keeps a set of adjacencies ( { port, neighbor } pairs ) for each distribution tree it is calculating. One of these adjacencies is toward the tree root RBi, and the others are toward the leaves. Once the adjacencies are chosen, it is irrelevant which ones are towards the root RBi and which are away from RBi. RBridges MUST drop a multi-destination frame that arrives at a port from an RBridge that is not an adjacency for the tree on which the frame is being distributed. Let's suppose that RBn has calculated that adjacencies a, c, and f are in the RBi tree. A multi-destination frame for the distribution tree RBi is received only from one of the adjacencies a, c, or f (otherwise it is discarded) and forwarded to the other two adjacencies. Should RBn have multiple
1. 树邻接检查：每个RBridge RBn为其计算的每个分发树保留一组邻接（{port，neighbor}对）。其中一个邻接点朝向树根RBi，其他邻接点朝向树叶。一旦选择了邻接关系，哪些邻接关系朝向根RBi，哪些邻接关系远离RBi就无关紧要了。RBridge必须删除从RBridge到达端口的多目标帧，该RBridge不是正在分发帧的树的邻接。假设RBn已经计算出RBi树中的邻接a、c和f。分发树RBi的多目标帧仅从邻接A、c或f中的一个接收（否则将被丢弃），并转发到其他两个邻接。RBn应该有多个
ports on a link, a multi-destination frame it sends on one of these ports will be received by the others but will be discarded as an RBridge is not adjacent to itself.
链路上的端口，它在其中一个端口上发送的多目标帧将被其他端口接收，但将被丢弃，因为RBridge不与其相邻。
2. RPF Check: Another technique used by RBridges for avoiding temporary multicast loops during topology changes is the Reverse Path Forwarding Check. It involves checking that a multi-destination frame, based on the tree and the ingress RBridge, arrives from the expected link. RBridges MUST drop multi-destination frames that fail the RPF check.
2. RPF检查：RBridges用于避免拓扑更改期间临时多播循环的另一种技术是反向路径转发检查。它涉及检查基于树和入口RBridge的多目标帧是否从预期链路到达。RBridges必须丢弃未通过RPF检查的多目标帧。
To limit the amount of state necessary to perform the RPF check, each RBridge RB2 MUST announce which trees RB2 may choose when RB2 ingresses a multi-destination packet. When any RBridge, say, RB3, is computing the tree from nickname X, RB3 computes, for each RBridge RB2 that might act as ingress for tree X, the link on which RB3 should receive a packet from ingress RB2 on tree X, and note for that link that RB2 is a legal ingress RBridge for tree X.
为了限制执行RPF检查所需的状态量，每个RBridge RB2必须宣布当RB2进入多目的地分组时RB2可以选择哪些树。当任何RBridge（例如RB3）从昵称X计算树时，RB3为可能充当树X入口的每个RBridge RB2计算RB3应在其上接收来自树X入口RB2的数据包的链路，并注意该链路RB2是树X的合法入口RBridge。
The information to determine which trees RB2 might choose is included in RB2's LSP. Similarly to how the highest priority RBridge RB1 specifies the k trees that will be computed by all RBridges, RB2 specifies a number j, which is the total number of different trees RB2 might specify, and the specific trees RB2 might specify are a combination of specified trees and trees selected from highest priority trees. If RB2 specifies any trees that are not in the k trees as specified by RB1, they are ignored.
确定RB2可以选择哪些树的信息包含在RB2的LSP中。与最高优先级RBridge RB1如何指定将由所有RBridge计算的k棵树类似，RB2指定数字j，这是RB2可能指定的不同树的总数，并且RB2可能指定的特定树是指定树和从最高优先级树中选择的树的组合。如果RB2指定了任何不在RB1指定的k树中的树，则忽略它们。
The j potential ingress trees for RB2 are the ones with nicknames that RB2 has explicitly specified in "specified ingress tree nicknames" (and that are included in the k campus-wide trees selected by highest priority RBridge RB1), with the remainder (up to the maximum of {j,k}) being the highest priority of the k campus-wide trees.
RB2的j个潜在入口树是具有RB2在“指定入口树昵称”中明确指定的昵称的树（包括在由最高优先级RBridge RB1选择的k个校园范围的树中），其余的（最大{j，k}）是k个校园范围的树的最高优先级。
The default value for j is 1. The value 0 for j is special and means that RB2 can pick any of the k trees being computed for the campus.
j的默认值为1。j的值0是特殊的，这意味着RB2可以选择为校园计算的k棵树中的任意一棵。
3. Parallel Links Check: If the tree-building and tiebreaking for a particular multi-destination frame distribution tree selects a non-pseudonode link between RB1 and RB2, that "RB1-RB2 link" might actually consist of multiple links. These parallel links would be visible to RB1 and RB2, but not to the rest of the campus (because the links are not represented by pseudonodes). If this bundle of parallel links is included in a tree, it is important for RB1 and RB2 to decide which link to use, but is irrelevant to other RBridges, and therefore, the tiebreaking algorithm need not be
3. 并行链路检查：如果特定多目标帧分布树的树构建和分接选择RB1和RB2之间的非伪节点链路，“RB1-RB2链路”实际上可能包含多个链路。这些并行链路对RB1和RB2是可见的，但对校园的其余部分是不可见的（因为这些链路不是由伪节点表示的）。如果此并行链路束包含在树中，则RB1和RB2决定使用哪个链路很重要，但与其他RBridge无关，因此，不需要使用分段算法
visible to any RBridges other than RB1 and RB2. In this case, RB1-RB2 adjacencies are ordered as follows, with the one "most preferred" adjacency being the one on which RB1 and RB2 transmit to and receive multi-destination frames from each other.
对除RB1和RB2以外的任何RB桥可见。在这种情况下，RB1-RB2邻接顺序如下，其中一个“最优选”邻接是RB1和RB2彼此发送和接收多目的地帧的邻接。
a) Most preferred are those established by P2P Hellos. Tiebreaking among those is based on preferring the one with the numerically highest Extended Circuit ID as associated with the adjacency by the RBridge with the highest System ID.
a) 最受欢迎的是由P2P Hellos建立的。其中的分层是基于优先选择具有数字上最高的扩展电路ID的一个，该扩展电路ID与具有最高系统ID的RBridge的邻接相关联。
b) Next considered are those established through TRILL-Hello frames, with suppressed pseudonodes. Note that the pseudonode is suppressed in LSPs, but still appears in the TRILL-Hello, and therefore is available for this tiebreaking. Among these links, the one with the numerically largest pseudonode ID is preferred.
b) 接下来考虑的是通过颤音Hello帧建立的，带有抑制的伪节点。请注意，伪节点在LSP中被抑制，但仍显示在TRILL Hello中，因此可用于此分段。在这些链路中，具有数字上最大的伪节点ID的链路是优选的。
4. Port Group Check: If an RBridge has multiple ports attached to the same link, a multi-destination frame it is receiving will arrive on all of them. All but one received copy of such a frame MUST be discarded to avoid duplication. All such frames that are part of the same flow must be accepted on the same port to avoid re-ordering.
4. 端口组检查：如果RBridge有多个端口连接到同一链路，则它接收的多目标帧将到达所有端口。为避免重复，必须丢弃除一个外的所有接收到的该帧副本。属于同一流的所有此类帧必须在同一端口上接受，以避免重新订购。
When a topology change occurs (including apparent changes during start up), an RBridge MUST adjust its input distribution tree filters no later than it adjusts its output forwarding.
当拓扑发生变化（包括启动期间的明显变化）时，RBridge必须在调整其输出转发之前调整其输入分发树过滤器。
Each distribution tree SHOULD be pruned per VLAN, eliminating branches that have no potential receivers downstream. Multi-destination TRILL Data frames SHOULD only be forwarded on branches that are not pruned.
每个VLAN应该修剪每个分发树，消除下游没有潜在接收器的分支。多目标TRILL数据帧应仅在未修剪的分支上转发。
Further pruning SHOULD be done in two cases: (1) IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] messages, where these are to be delivered only to links with IP multicast routers; and (2) other multicast frames derived from an IP multicast address that should be delivered only to links that have registered listeners, plus links that have IP multicast routers, except for IP multicast addresses that must be broadcast. Each of these cases is scoped per VLAN.
在两种情况下应进行进一步的修剪：（1）IGMP[RFC3376]、MLD[RFC2710]和MRD[RFC4286]消息，其中这些消息仅发送到与IP多播路由器的链路；和（2）从IP多播地址派生的其他多播帧，该IP多播地址应仅传送到具有注册侦听器的链路，加上具有IP多播路由器的链路，但必须广播的IP多播地址除外。每种情况的作用域都是每个VLAN。
Let's assume that RBridge RBn knows that adjacencies (a, c, and f) are in the nickname1 distribution tree. RBn marks pruning information for each of the adjacencies in the nickname1-tree. For each adjacency and for each tree, RBn marks:
让我们假设RBridge RBn知道邻接（a、c和f）在昵称1分布树中。RBn标记昵称1树中每个邻接的修剪信息。对于每个邻接和每个树，RBn标记：
o the set of VLANs reachable downstream,
o 可在下游访问的VLAN集，
o for each one of those VLANs, flags indicating whether there are IPv4 or IPv6 multicast routers downstream, and
o 对于这些VLAN中的每一个，指示下游是否存在IPv4或IPv6多播路由器的标志，以及
o the set of Layer 2 multicast addresses derived from IP multicast groups for which there are receivers downstream.
o 从IP多播组派生的一组第2层多播地址，其下游有接收器。
RBridges MUST determine the VLAN associated with all native frames they ingress and properly enforce VLAN rules on the emission of native frames at egress RBridge ports according to how those ports are configured and designated as appointed forwarders. RBridges SHOULD also prune the distribution tree of multi-destination frames according to VLAN. But, since they are not required to do such pruning, they may receive TRILL data or ESADI frames that should have been VLAN pruned earlier in the tree distribution. They silently discard such frames. A campus may contain some Rbridges that prune distribution trees on VLAN and some that do not.
RBridge必须确定与它们进入的所有本机帧相关联的VLAN，并根据这些端口如何配置和指定为指定转发器，在出口RBridge端口发射本机帧时正确实施VLAN规则。RBridges还应根据VLAN修剪多目标帧的分发树。但是，由于它们不需要进行这种修剪，因此它们可能会收到TRILL数据或ESADI帧，这些数据或帧本应在树分布的早期进行VLAN修剪。他们默默地丢弃了这样的框架。校园可能包含一些修剪VLAN上分布树的RBridge和一些不修剪的RBridge。
The situation is more complex for multicast. RBridges SHOULD analyze IP-derived native multicast frames, and learn and announce listeners and IP multicast routers for such frames as discussed in Section 4.7 below. And they SHOULD prune the distribution of IP-derived multicast frames based on such learning and announcements. But, they are not required to prune based on IP multicast listener and router attachment state. And, unlike VLANs, where VLAN attachment state of ports MUST be maintained and honored, RBridges are not required to maintain IP multicast listener and router attachment state.
对于多播而言，情况更为复杂。RBridges应分析IP派生的本机多播帧，并学习和宣布侦听器和IP多播路由器，如下文第4.7节所述。并且他们应该根据这些学习和通知来修剪IP派生的多播帧的分布。但是，它们不需要根据IP多播侦听器和路由器连接状态进行修剪。而且，与VLAN不同，在VLAN中必须维护和遵守端口的VLAN连接状态，RBridge不需要维护IP多播侦听器和路由器连接状态。
An RBridge that does not examine native IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286] frames that it ingresses MUST advertise that it has IPv4 and IPv6 IP multicast routers attached for all the VLANs for which it is an appointed forwarder. It need not advertise any IP-derived multicast listeners. This will cause all IP-derived multicast traffic to be sent to this RBridge for those VLANs. It then egresses that traffic onto the links for which it is appointed forwarder where the VLAN of the traffic matches the VLAN for which it is appointed forwarder on that link. (This may cause the suppression of certain IGMP membership report messages from end stations, but that is not significant because any multicast traffic that such reports would be requesting will be sent to such end stations under these circumstances.)
不检查其进入的本机IGMP[RFC3376]、MLD[RFC2710]或MRD[RFC4286]帧的RBridge必须声明其已为其作为指定转发器的所有VLAN连接IPv4和IPv6 IP多播路由器。它不需要公布任何IP派生的多播侦听器。这将导致所有IP派生的多播流量被发送到这些VLAN的RBridge。然后，它将该流量导出到它被指定为转发器的链路上，其中该流量的VLAN与它在该链路上被指定为转发器的VLAN匹配。（这可能会导致抑制来自终端站的某些IGMP成员报告消息，但这并不重要，因为在这些情况下，此类报告将请求的任何多播流量都将发送到此类终端站。）
A campus may contain a mixture of Rbridges with different levels of IP-derived multicast optimization. An RBridge may receive IP-derived multicast frames that should have been pruned earlier in the tree distribution. It silently discards such frames.
校园可能包含具有不同IP派生多播优化级别的混合RBridge。RBridge可能会接收IP派生的多播帧，这些帧应该在树分布的早期进行修剪。它会悄悄地丢弃这样的帧。
See also "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" [RFC4541].
另请参阅“Internet组管理协议（IGMP）和多播侦听器发现（MLD）侦听交换机的注意事项”[RFC4541]。
With full optimization, forwarding a multi-destination data frame is done as follows. References to adjacencies below do not include the adjacency on which a frame was received.
通过充分优化，转发多目标数据帧的操作如下所示。下面对邻接的引用不包括接收帧的邻接。
o The RBridge RBn receives a multi-destination TRILL Data frame with inner VLAN-x and a TRILL header indicating that the selected tree is the nickname1 tree;
o RBridge RBn接收具有内部VLAN-x和指示所选树是昵称1树的TRILL报头的多目的地TRILL数据帧；
o if the source from which the frame was received is not one of the adjacencies in the nickname1 tree for the specified ingress RBridge, the frame is dropped (see Section 4.5.1);
o 如果接收帧的源不是指定入口RBridge的昵称1树中的邻接之一，则丢弃该帧（见第4.5.1节）；
o else, if the frame is an IGMP or MLD announcement message or an MRD query message, then the encapsulated frame is forwarded onto adjacencies in the nickname1 tree that indicate there are downstream VLAN-x IPv4 or IPv6 multicast routers as appropriate;
o 否则，如果帧是IGMP或MLD公告消息或MRD查询消息，则封装的帧被转发到昵称1树中的邻接处，指示存在下游VLAN-x IPv4或IPv6多播路由器（视情况而定）；
o else, if the frame is for a Layer 2 multicast address derived from an IP multicast group, but its IP address is not the range of IP multicast addresses that must be treated as broadcast, the frame is forwarded onto adjacencies in the nickname1 tree that indicate there are downstream VLAN-x IP multicast routers of the corresponding type (IPv4 or IPv6), as well as adjacencies that indicate there are downstream VLAN-x receivers for that group address;
o 否则，如果帧用于从IP多播组派生的第2层多播地址，但其IP地址不是必须视为广播的IP多播地址范围，则该帧被转发到昵称1树中的邻接处，该邻接处指示存在对应类型的下游VLAN-x IP多播路由器（IPv4或IPv6），以及表示该组地址存在下游VLAN-x接收器的邻接；
o else (the inner frame is for a Layer 2 multicast address not derived from an IP multicast group or an unknown destination or broadcast or an IP multicast address that is required to be treated as broadcast), the frame is forwarded onto an adjacency if and only if that adjacency is in the nickname1 tree, and marked as reaching VLAN-x links.
o else（内部帧用于第2层多播地址，该地址不是来自IP多播组或未知目的地或广播或需要被视为广播的IP多播地址），当且仅当该相邻位于昵称1树中时，该帧被转发到该相邻上，并标记为到达VLAN-x链路。
For each link for which RBn is appointed forwarder, RBn additionally checks to see if it should decapsulate the frame and send it to the link in native form, or process the frame locally.
对于RBn被指定为转发器的每个链路，RBn还将检查是否应解除帧的封装并以本机形式发送到链路，或在本地处理帧。
TRILL ESADI frames will be delivered only to RBridges that are appointed forwarders for their VLAN. Such frames will be multicast throughout the campus, like other non-IP-derived multicast data frames, on the distribution tree chosen by the RBridge that created the TRILL ESADI frame, and pruned according to the Inner.VLAN ID. Thus, all the RBridges that are appointed forwarders for a link in that VLAN receive them.
TRILL ESADI帧将仅交付给为其VLAN指定转发器的RBridge。与其他非IP派生的多播数据帧一样，这些帧将在校园内的分布树上进行多播，该分布树由创建TRILL ESADI帧的RBridge选择，并根据Inner.VLAN ID进行修剪。因此，为该VLAN中的链路指定转发器的所有RBridge都将接收这些帧。
This section describes RBridge behavior for all varieties of received frames, including how they are forwarded when appropriate. Section 4.6.1 covers native frames, Section 4.6.2 covers TRILL frames, and Section 4.6.3 covers Layer 2 control frames. Processing may be organized or sequenced in a different way than described here as long as the result is the same. See Section 1.4 for frame type definitions.
本节描述所有接收帧的RBridge行为，包括在适当时如何转发这些帧。第4.6.1节涵盖本机帧，第4.6.2节涵盖颤音帧，第4.6.3节涵盖第2层控制帧。只要结果相同，处理可以以不同于此处描述的方式进行组织或排序。框架类型定义见第1.4节。
Corrupt frames, for example, frames that are not a multiple of 8 bits, are too short or long for the link protocol/hardware in use, or have a bad FCS are discarded on receipt by an RBridge port as they are discarded on receipt at an IEEE 802.1 bridge port.
损坏的帧，例如，对于正在使用的链路协议/硬件而言，不是8位倍数的帧太短或太长，或者具有坏FCS的帧在RBridge端口接收时被丢弃，因为它们在IEEE 802.1网桥端口接收时被丢弃。
Source address information ( { VLAN, Outer.MacSA, port } ) is learned by default from any frame with a unicast source address (see Section 4.8).
源地址信息（{VLAN，Outer.MacSA，port}）默认情况下从具有单播源地址的任何帧中学习（参见第4.8节）。
If the port is configured as disabled or if end-station service is disabled on the port by configuring it as a trunk port or configuring it to use P2P Hellos, the frame is discarded.
如果端口配置为禁用，或者通过将端口配置为中继端口或将其配置为使用P2P Hellos来禁用端口上的端站服务，则丢弃帧。
The ingress Rbridge RB1 determines the VLAN ID for a native frame according to the same rules as IEEE [802.1Q-2005] bridges do (see Appendix D and Section 4.9.2). Once the VLAN is determined, if RB1 is not the appointed forwarder for that VLAN on the port where the frame was received or is inhibited, the frame is discarded. If it is appointed forwarder for that VLAN and is not inhibited (see Section 4.2.4.3), then the native frame is forwarded according to Section 4.6.1.1 if it is unicast and according to Section 4.6.1.2 if it is multicast or broadcast.
入口Rbridge RB1根据与IEEE[802.1Q-2005]网桥相同的规则确定本机帧的VLAN ID（参见附录D和第4.9.2节）。一旦确定VLAN，如果RB1不是接收或禁止帧的端口上该VLAN的指定转发器，则丢弃该帧。如果它被指定为该VLAN的转发器且未被禁止（参见第4.2.4.3节），则本机帧根据第4.6.1.1节（如果是单播）和第4.6.1.2节（如果是多播或广播）进行转发。
If the destination MAC address of the native frame is a unicast address, the following steps are performed.
如果本机帧的目标MAC地址是单播地址，则执行以下步骤。
The Layer 2 destination address and VLAN are looked up in the ingress RBridge's database of MAC addresses and VLANs to find the egress RBridge RBm or the local egress port or to discover that the destination is the receiving RBridge or is unknown. One of the following four cases will apply:
在入口RBridge的MAC地址和VLAN数据库中查找第2层目标地址和VLAN，以查找出口RBridge RBm或本地出口端口，或发现目标是接收RBridge或未知。以下四种情况之一适用：
1. If the destination is the receiving RBridge, the frame is locally processed.
1. 如果目的地是接收RBridge，则本地处理该帧。
2. If the destination is known to be on the same link from which the native frame was received but is not the receiving RBridge, the RBridge silently discards the frame, since the destination should already have received it.
2. 如果已知目标位于接收本机帧的同一链路上，但不是接收RBridge，则RBridge会自动丢弃该帧，因为目标应该已经接收到该帧。
3. If the destination is known to be on a different local link for which RBm is the appointed forwarder, then RB1 converts the native frame to a TRILL Data frame with an Outer.MacDA of the next hop RBridge towards RBm, a TRILL header with M = 0, an ingress nickname for RB1, and the egress nickname for RBm. If ingress RB1 has multiple nicknames, it SHOULD use the same nickname in the ingress nickname field whenever it encapsulates a native frame from any particular source MAC address and VLAN. This simplifies end node learning. If RBm is RB1, processing then proceeds as in Section 4.6.2.4; otherwise, the Outer.MacSA is set to the MAC address of the RB1 port on the path to the next hop RBridge towards RBm and the frame is queued for transmission out of that port.
3. 如果已知目的地位于RBm为其指定转发器的不同本地链路上，则RB1将本机帧转换为TRILL数据帧，其中下一跳RBridge的Outer.MacDA朝向RBm，TRILL报头具有M=0、RB1的入口昵称和RBm的出口昵称。如果ingress RB1有多个昵称，则每当它封装来自任何特定源MAC地址和VLAN的本机帧时，应在ingress昵称字段中使用相同的昵称。这简化了终端节点学习。如果RBm为RB1，则按照第4.6.2.4节进行处理；否则，Outer.MacSA设置为通向RBm的下一跳RBridge路径上RB1端口的MAC地址，帧排队等待从该端口传输出去。
4. If a unicast destination MAC is unknown in the frame's VLAN, RB1 handles the frame as described in Section 4.6.1.2 for a broadcast frame except that the Inner.MacDA is the original native frame's unicast destination address.
4. 如果帧VLAN中的单播目的地MAC未知，RB1将按照第4.6.1.2节所述处理广播帧的帧，但Inner.MacDA是原始本机帧的单播目的地地址除外。
If the RBridge has multiple ports attached to the same link, all but one received copy of a native multicast or broadcast frame is discarded to avoid duplication. All such frames that are part of the same flow must be accepted on the same port to avoid re-ordering.
如果RBridge具有多个连接到同一链路的端口，则除了一个本地多播或广播帧的接收副本之外，其他所有端口都将被丢弃，以避免重复。属于同一流的所有此类帧必须在同一端口上接受，以避免重新订购。
If the frame is a native IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286] frame, then RB1 SHOULD analyze it, learn any group membership or IP multicast router presence indicated, and announce that information for the appropriate VLAN in its LSP (see Section 4.7).
如果该帧是本机IGMP[RFC3376]、MLD[RFC2710]或MRD[RFC4286]帧，则RB1应分析该帧，了解指示的任何组成员资格或IP多播路由器存在，并在其LSP中宣布相应VLAN的信息（参见第4.7节）。
For all multi-destination native frames, RB1 forwards the frame in native form to its links where it is appointed forwarder for the
对于所有多目的地本机帧，RB1将本机格式的帧转发到其链接，在该链接中，RB1被指定为本机的转发器
frame's VLAN, subject to further pruning and inhibition. In addition, it converts the native frame to a TRILL Data frame with the All-RBridges multicast address as Outer.MacDA, a TRILL header with the multi-destination bit M = 1, the ingress nickname for RB1, and the egress nickname for the distribution tree it decides to use. It then forwards the frame on the pruned distribution tree (see Section 4.5) setting the Outer.MacSA of each copy sent to the MAC address of the RB1 port on which it is sent.
帧的VLAN，需要进一步修剪和抑制。此外，它将本机帧转换为TRILL数据帧，其中所有RBridges多播地址为Outer.MacDA，TRILL报头的多目标位为M=1，RB1的入口昵称，以及它决定使用的分发树的出口昵称。然后，它在经过修剪的分发树（参见第4.5节）上转发帧，设置发送到RB1端口的MAC地址的每个副本的Outer.MacSA。
The default is for RB1 to write into the egress nickname field the nickname for a distribution tree, from the set of distribution trees RB1 has announced it might use, whose root is least cost from RB1. RB1 MAY choose different distribution trees for different frames if RB1 has been configured to path-split multicast. In that case, RB1 MUST select a tree by specifying a nickname that is a distribution tree root (see Section 4.5). Also, RB1 MUST select a nickname that RB1 has announced (in RB1's own LSP) to be one of those that RB1 might use. The strategy RB1 uses to select distribution trees in multipathing multi-destination frames is beyond the scope of this document.
默认情况下，RB1会在出口昵称字段中写入分发树的昵称，该分发树来自RB1宣布可能使用的分发树集合，其根是RB1的最小成本。如果RB1已配置为路径分割多播，则RB1可以为不同的帧选择不同的分发树。在这种情况下，RB1必须通过指定作为分发树根的昵称来选择一棵树（参见第4.5节）。此外，RB1必须选择RB1已经宣布的昵称（在RB1自己的LSP中）作为RB1可能使用的昵称之一。RB1用于在多路径多目标帧中选择分发树的策略超出了本文档的范围。
A TRILL frame either has the TRILL or L2-IS-IS Ethertype or has a multicast Outer.MacDA allocated to TRILL (see Section 7.2). The following tests are performed sequentially, and the first that matches controls the handling of the frame:
TRILL帧具有TRILL或L2-IS-IS Ethertype，或者具有分配给TRILL的multicast Outer.MacDA（参见第7.2节）。以下测试按顺序执行，第一个匹配的测试控制帧的处理：
1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS, the frame is handled as described in Section 4.6.2.1.
1. 如果Outer.MacDA为All is RBridges，Ethertype为L2-is-is，则按照第4.6.2.1节所述处理帧。
2. If the Outer.MacDA is a multicast address allocated to TRILL other than All-RBridges, the frame is discarded.
2. 如果Outer.MacDA是分配给TRILL而不是所有RBridge的多播地址，则丢弃该帧。
3. If the Outer.MacDA is a unicast address other than the receiving Rbridge port MAC address, the frame is discarded. (Such discarded frames are most likely addressed to another RBridge on a multi-access link and that other Rbridge will handle them.)
3. 如果Outer.MacDA是接收Rbridge端口MAC地址以外的单播地址，则丢弃该帧。（这种丢弃的帧最有可能发往多址链路上的另一个RBridge，而另一个RBridge将处理它们。）
4. If the Ethertype is not TRILL, the frame is discarded.
4. 如果Ethertype不是颤音，帧将被丢弃。
5. If the Version field in the TRILL header is greater than 0, the frame is discarded.
5. 如果颤音标题中的版本字段大于0，则该帧将被丢弃。
6. If the hop count is 0, the frame is discarded.
6. 如果跃点计数为0，则丢弃帧。
7. If the Outer.MacDA is multicast and the M bit is zero or if the Outer.MacDA is unicast and M bit is one, the frame is discarded.
7. 如果Outer.MacDA为多播且M位为零，或者Outer.MacDA为单播且M位为一，则丢弃该帧。
8. By default, an RBridge MUST NOT forward TRILL-encapsulated frames from a neighbor with which it does not have a TRILL IS-IS adjacency. RBridges MAY be configured per port to accept these frames for forwarding in cases where it is known that a non-peering device (such as an end station) is configured to originate TRILL-encapsulated frames that can be safely forwarded.
8. 默认情况下，RBridge不能转发来自其没有颤音IS-IS邻接的邻居的颤音封装帧。在已知非对等设备（例如终端站）被配置为发起可安全转发的TRILL封装帧的情况下，rbridge可被配置为每个端口接受这些帧以进行转发。
9. The Inner.MacDA is then tested. If it is the All-ESADI-RBridges multicast address and RBn implements the ESADI protocol, processing proceeds as in Section 4.6.2.2 below. If it is any other address or RBn does not implement ESADI, processing proceeds as in Section 4.6.2.3.
9. 然后对Inner.MacDA进行测试。如果它是所有ESADI RBridges多播地址，并且RBn实施ESADI协议，则处理将按照下面第4.6.2.2节进行。如果是任何其他地址或RBn未实施ESADI，则按照第4.6.2.3节进行处理。
The frame is processed by the TRILL IS-IS instance on RBn and is not forwarded.
帧由RBn上的TRILL is-is实例处理，不转发。
If M == 0, the frame is silently discarded.
如果M==0，则该帧将自动丢弃。
The egress nickname designates the distribution tree. The frame is forwarded as described in Section 4.6.2.5. In addition, if the forwarding Rbridge is an appointed forwarder for a link in the specified VLAN and implements the TRILL ESADI protocol and ESADI is enabled at the forwarding Rbridge for that VLAN, the inner frame is decapsulated and provided to that local ESADI protocol.
出口昵称指定分发树。按照第4.6.2.5节所述转发帧。此外，如果转发Rbridge是指定VLAN中链路的指定转发器，并且实现了TRILL ESADI协议，并且在该VLAN的转发Rbridge上启用了ESADI，则内部帧被解除封装并提供给该本地ESADI协议。
The M flag is then checked. If it is zero, processing continues as described in Section 4.6.2.4, if it is one, processing continues as described in Section 4.6.2.5.
然后检查M标志。如果为零，则按照第4.6.2.4节所述继续处理；如果为一，则按照第4.6.2.5节所述继续处理。
The egress nickname in the TRILL header is examined, and if it is unknown or reserved, the frame is discarded.
检查TRILL报头中的出口昵称，如果它未知或保留，则丢弃该帧。
If RBn is a transit RBridge, the hop count is decremented by one and the frame is forwarded to the next hop RBridge towards the egress RBridge. (The provision permitting RBridges to decrease the hop count by more than one under some circumstances (see Section 3.6) applies only to multi-destination frames, not to the known unicast frames considered in this subsection.) The Inner.VLAN is not examined by a transit RBridge when it forwards a known unicast TRILL Data frame. For the forwarded frame, the Outer.MacSA is the MAC
如果RBn是传输RBridge，则跳数减少1，并且帧被转发到朝向出口RBridge的下一跳RBridge。（允许RBridge在某些情况下将跳数减少一个以上的规定（见第3.6节）仅适用于多目标帧，而不适用于本小节中考虑的已知单播帧。）当传输RBridge转发已知单播TRILL数据帧时，不检查internal.VLAN。对于转发的帧，Outer.MacSA是MAC
address of the transmitting port, the Outer.MacDA is the unicast address of the next hop RBridge, and the VLAN is the Designated VLAN on the link onto which the frame is being transmitted.
传输端口的地址，Outer.MacDA是下一跳RBridge的单播地址，VLAN是帧传输到的链路上的指定VLAN。
If RBn is not a transit RBridge, that is, if the egress RBridge indicated is the RBridge performing the processing, the Inner.MacSA and Inner.VLAN ID are, by default, learned as associated with the ingress nickname unless that nickname is unknown or reserved or the Inner.MacSA is not unicast. Then the frame being forwarded is decapsulated to native form, and the following checks are performed:
如果RBn不是传输RBridge，也就是说，如果指示的出口RBridge是执行处理的RBridge，则默认情况下，会将Inner.MacSA和Inner.VLAN ID作为与入口昵称相关联的ID进行学习，除非该昵称未知或保留，或者Inner.MacSA不是单播的。然后将转发的帧解压缩为本机格式，并执行以下检查：
o The Inner.MacDA is checked. If it is not unicast, the frame is discarded.
o 已检查内部的.MacDA文件。如果不是单播，则丢弃该帧。
o If the Inner.MacDA corresponds to the RBridge doing the processing, the frame is locally delivered.
o 如果Inner.MacDA对应于进行处理的RBridge，则帧将在本地传递。
o The Inner.VLAN ID is checked. If it is 0x0 or 0xFFF, the frame is discarded.
o 已检查internal.VLAN ID。如果是0x0或0xFFF，则丢弃该帧。
o The Inner.MacDA and Inner.VLAN ID are looked up in RBn's local address cache and the frame is then either sent onto the link containing the destination, if the RBridge is appointed forwarder for that link for the frame's VLAN and is not inhibited (or discarded if it is inhibited), or processed as in one of the following two paragraphs.
o 在RBn的本地地址缓存中查找Inner.MacDA和Inner.VLAN ID，然后将帧发送到包含目的地的链路上，如果RBridge被指定为帧VLAN的该链路的转发器，并且未被禁止（如果被禁止，则丢弃），或者按照以下两段之一进行处理。
A known unicast TRILL Data frame can arrive at the egress Rbridge only to find that the combination of Inner.MacDA and Inner.VLAN is not actually known by that RBridge. One way this can happen is that the address information may have timed out in the egress RBridge MAC address cache. In this case, the egress RBridge sends the native frame out on all links that are in the frame's VLAN for which the RBridge is appointed forwarder and has not been inhibited, except that it MAY refrain from sending the frame on links where it knows there cannot be an end station with the destination MAC address, for example, the link port is configured as a trunk (see Section 4.9.1).
已知的单播TRILL数据帧可以到达出口Rbridge，但却发现该Rbridge实际上不知道Inner.MacDA和Inner.VLAN的组合。发生这种情况的一种方式是，出口RBridge MAC地址缓存中的地址信息可能已超时。在这种情况下，出口RBridge在帧的VLAN中的所有链路上发送本机帧，RBridge被指定为该VLAN的转发器并且未被禁止，但其可以在知道不可能存在具有目的地MAC地址的终端站的链路上避免发送帧，例如，链路端口配置为中继（见第4.9.1节）。
If, due to manual configuration or learning from Layer 2 registration, the destination MAC and VLAN appear in RBn's local address cache for two or more links for which RBn is an uninhibited appointed forwarder for the frame's VLAN, RBn sends the native frame on all such links.
如果由于手动配置或从第2层注册学习，目标MAC和VLAN出现在RBn的本地地址缓存中，用于RBn是帧VLAN的不受限制的指定转发器的两个或多个链路，RBn将在所有此类链路上发送本机帧。
The egress and ingress nicknames in the TRILL header are examined and, if either is unknown or reserved, the frame is discarded.
检查TRILL报头中的进出昵称，如果未知或保留，则丢弃帧。
The Outer.MacSA is checked and the frame discarded if it is not a tree adjacency for the tree indicated by the egress RBridge nickname on the port where the frame was received. The Reverse Path Forwarding Check is performed on the ingress and egress nicknames and the frame discarded if it fails. If there are multiple TRILL-Hello pseudonode suppressed parallel links to the previous hop RBridge, the frame is discarded if it has been received on the wrong one. If the RBridge has multiple ports connected to the link, the frame is discarded unless it was received on the right one. For more information on the checks in this paragraph, see Section 4.5.2.
如果帧不是接收帧的端口上的出口RBridge昵称所指示的树的树邻接，则选中Outer.MacSA并丢弃该帧。对入口和出口昵称执行反向路径转发检查，如果失败，则丢弃帧。如果有多个TRILL Hello伪节点抑制的平行链接到上一跳RBridge，则如果在错误的一个上接收到帧，则丢弃该帧。如果RBridge有多个端口连接到链路，则帧将被丢弃，除非它是在右侧接收到的。有关本段检查的更多信息，请参见第4.5.2节。
If the Inner.VLAN ID of the frame is 0x0 or 0xFFF, the frame is discarded.
如果帧的Inner.VLAN ID为0x0或0xFFF，则丢弃该帧。
If the RBridge is an appointed forwarder for the Inner.VLAN ID of the frame, the Inner.MacSA and Inner.VLAN ID are, by default, learned as associated with the ingress nickname unless that nickname is unknown or reserved or the Inner.MacSA is not unicast. A copy of the frame is then decapsulated, sent in native form on those links in its VLAN for which the RBridge is appointed forwarder subject to additional pruning and inhibition as described in Section 4.2.4.3, and/or locally processed as appropriate.
如果RBridge是帧的Inner.VLAN ID的指定转发器，则默认情况下，Inner.MacSA和Inner.VLAN ID与入口昵称关联，除非该昵称未知或保留，或者Inner.MacSA不是单播的。然后对帧的副本进行解封，在其VLAN中的链路上以本机形式发送，RBridge被指定为转发器，并按照第4.2.4.3节所述进行额外的修剪和抑制，和/或根据需要进行本地处理。
The hop count is decreased (possibly by more than one; see Section 3.6), and the frame is forwarded down the tree specified by the egress RBridge nickname pruned as described in Section 4.5.
跳数减少（可能减少一个以上；参见第3.6节），帧向下转发到由第4.5节所述修剪的出口RBridge昵称指定的树。
For the forwarded frame, the Outer.MacSA is set to that of the port on which the frame is being transmitted, the Outer.MacDA is the All-RBridges multicast address, and the VLAN is the Designated VLAN of the link on which the frame is being transmitted.
对于转发的帧，Outer.MacSA设置为传输帧的端口的地址，Outer.MacDA是所有RBridges多播地址，VLAN是传输帧的链路的指定VLAN。
Low-level control frames received by an RBridge are handled within the port where they are received as described in Section 4.9.
RBridge接收的低电平控制帧在接收端口内进行处理，如第4.9节所述。
There are two types of high-level control frames, distinguished by their destination address, which are handled as described in the sections referenced below.
有两种类型的高级控制帧，通过它们的目标地址来区分，它们按照下面引用的章节中的描述进行处理。
Name Section Destination Address
名称段目的地址
BPDU 4.9.3 01-80-C2-00-00-00 VRP 4.9.4 01-80-C2-00-00-21
BPDU 4.9.3 01-80-C2-00-00 VRP 4.9.4 01-80-C2-00-00-21
Ingress RBridges SHOULD learn, based on native IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] frames they receive in VLANs for which they are an uninhibited appointed forwarder, which IP-derived multicast messages should be forwarded onto which links. Such frames are also, in general, encapsulated as TRILL Data frames and distributed as described below and in Section 4.5.
入口RBridges应该基于它们在VLAN中接收的本机IGMP[RFC3376]、MLD[RFC2710]和MRD[RFC4286]帧来了解哪些IP派生的多播消息应该转发到哪些链路。通常，此类帧也封装为颤音数据帧，并按照下文和第4.5节所述进行分发。
An IGMP or MLD membership report received in native form from a link indicates a multicast group listener for that group on that link. An IGMP or MLD query or an MRD advertisement received in native form from a link indicates the presence of an IP multicast router on that link.
从链路以本机形式接收的IGMP或MLD成员资格报告表示该链路上该组的多播组侦听器。从链路以本机形式接收的IGMP或MLD查询或MRD播发指示该链路上存在IP多播路由器。
IP multicast group membership reports have to be sent throughout the campus and delivered to all IP multicast routers, distinguishing IPv4 and IPv6. All IP-derived multicast traffic must also be sent to all IP multicast routers for the same version of IP.
IP多播组成员报告必须发送到整个校园，并发送到所有IP多播路由器，区分IPv4和IPv6。所有IP派生的多播流量也必须发送到同一版本IP的所有IP多播路由器。
IP multicast data SHOULD only be sent on links where there is either an IP multicast router for that IP type (IPv4 or IPv6) or an IP multicast group listener for that IP-derived multicast MAC address, unless the IP multicast address is in the range required to be treated as broadcast.
IP多播数据应仅在存在该IP类型（IPv4或IPv6）的IP多播路由器或该IP派生多播MAC地址的IP多播组侦听器的链路上发送，除非该IP多播地址在需要视为广播的范围内。
RBridges do not need to announce themselves as listeners to the IPv4 All-Snoopers multicast group (the group used for MRD reports [RFC4286]), because the IPv4 multicast address for that group is in the range where all frames sent to that IP multicast address must be broadcast (see [RFC4541], Section 2.1.2). However, RBridges that are performing IPv6-derived multicast optimization MUST announce themselves as listeners to the IPv6 All-Snoopers multicast group.
RBridge不需要宣布自己为IPv4 All Snoopers多播组（用于MRD报告[RFC4286]的组）的侦听器，因为该组的IPv4多播地址在发送到该IP多播地址的所有帧必须广播的范围内（请参见[RFC4541]，第2.1.2节）。但是，执行IPv6派生的多播优化的RBridge必须宣布自己是IPv6 All Snoopers多播组的侦听器。
See also "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" [RFC4541].
另请参阅“Internet组管理协议（IGMP）和多播侦听器发现（MLD）侦听交换机的注意事项”[RFC4541]。
RBridges have to learn the MAC addresses and VLANs of their locally attached end stations for link/VLAN pairs for which they are the appointed forwarder. Learning this enables them to do the following:
RBridge必须了解其作为指定转发器的链路/VLAN对的本地连接终端站的MAC地址和VLAN。了解这一点使他们能够执行以下操作：
o Forward the native form of incoming known unicast TRILL Data frames onto the correct link.
o 将传入的已知单播颤音数据帧的本机形式转发到正确的链接上。
o Decide, for an incoming native unicast frame from a link, where the RBridge is the appointed forwarder for the frame's VLAN, whether the frame is
o 对于来自链路的传入本机单播帧，确定RBridge是帧VLAN的指定转发器的位置，该帧是否为
- known to have been destined for another end station on the same link, so the RBridge need do nothing, or
- 已知已发送到同一链路上的另一个终端站，因此RBridge无需执行任何操作，或
- has to be converted to a TRILL Data frame and forwarded.
- 必须转换为颤音数据帧并转发。
RBridges need to learn the MAC addresses, VLANs, and remote RBridges of remotely attached end stations for VLANs for which they and the remote RBridge are an appointed forwarder, so they can efficiently direct native frames they receive that are unicast to those addresses and VLANs.
RBridge需要了解其和远程RBridge是指定转发器的VLAN的远程连接终端站的MAC地址、VLAN和远程RBridge，以便能够有效地将其接收的单播本机帧定向到这些地址和VLAN。
There are five independent ways an RBridge can learn end-station addresses as follows:
RBridge可以通过以下五种独立的方式学习端站地址：
1. From the observation of VLAN-x frames received on ports where it is appointed VLAN-x forwarder, learning the { source MAC, VLAN, port } triplet of received frames.
1. 通过观察指定为VLAN-x转发器的端口上接收的VLAN-x帧，了解接收帧的{source MAC，VLAN，port}三元组。
2. The { source MAC, VLAN, ingress RBridge nickname } triplet of any native frames that it decapsulates.
2. 它解除封装的任何本机帧的{源MAC、VLAN、入口RBridge昵称}三元组。
3. By Layer 2 registration protocols learning the { source MAC, VLAN, port } of end stations registering at a local port.
3. 通过第2层注册协议学习在本地端口注册的终端站的{源MAC、VLAN、端口}。
4. By running the TRILL ESADI protocol for one or more VLANs and thereby receiving remote address information and/or transmitting local address information.
4. 通过为一个或多个VLAN运行TRILL ESADI协议，从而接收远程地址信息和/或传输本地地址信息。
5. By management configuration.
5. 通过管理配置。
RBridges MUST implement capabilities 1 and 2 above. RBridges use these capabilities unless configured, for one or more particular VLANs and/or ports, not to learn from either received frames or from decapsulating native frames to be transmitted or both.
RBridge必须实现上述功能1和2。RBridge使用这些功能，除非针对一个或多个特定VLAN和/或端口进行了配置，否则不会从接收到的帧或要传输的解除封装的本机帧或两者中学习。
RBridges MAY implement capabilities 3 and 4 above. If capability 4 is implemented, the ESADI protocol is run only when the RBridge is configured to do so on a per-VLAN basis.
RBridges可以实现上述功能3和4。如果实现了功能4，则仅当RBridge配置为基于每个VLAN运行ESADI协议时，才会运行ESADI协议。
RBridges SHOULD implement capability 5.
RBridges应实现能力5。
Entries in the table of learned MAC and VLAN addresses and associated information also have a one-octet unsigned confidence level associated with each entry whose rationale is given below. Such information learned from the observation of data has a confidence of 0x20 unless configured to have a different confidence. This confidence level can be configured on a per-RBridge basis separately for information learned from local native frames and that learned from remotely originated encapsulated frames. Such information received via the TRILL ESADI protocol is accompanied by a confidence level in the range 0 to 254. Such information configured by management defaults to a confidence level of 255 but may be configured to have another value.
已学习MAC和VLAN地址表中的条目以及相关信息也有一个与每个条目相关联的八位字节无符号置信水平，其基本原理如下所示。除非配置为具有不同的置信度，否则从数据观察中获得的此类信息的置信度为0x20。对于从本地本地帧学习到的信息和从远程发起的封装帧学习到的信息，可以在每个RBridge的基础上分别配置该置信水平。通过TRILL ESADI协议接收的此类信息伴随着0到254范围内的置信水平。由管理层配置的此类信息默认为255的置信水平，但可以配置为具有另一个值。
The table of learned MAC addresses includes (1) { confidence, VLAN, MAC address, local port } for addresses learned from local native frames and local registration protocols, (2) { confidence, VLAN, MAC address, egress RBridge nickname } for addresses learned from remote encapsulated frames and ESADI link state databases, and (3) additional information to implement timeout of learned addresses, statically configured addresses, and the like.
学习的MAC地址表包括（1）{置信度，VLAN，MAC地址，本地端口}用于从本地本地帧和本地注册协议学习的地址，（2）{置信度，VLAN，MAC地址，出口RBridge昵称}用于从远程封装帧和ESADI链路状态数据库学习的地址，以及（3）用于实现读入地址、静态配置地址等超时的附加信息。
When a new address and related information learned from observing data frames are to be entered into the local database, there are three possibilities:
当从观测数据帧中获得的新地址和相关信息输入本地数据库时，有三种可能性：
A. If this is a new { address, VLAN } pair, the information is entered accompanied by the confidence level.
A.如果这是一个新的{地址，VLAN}对，则输入信息时附带置信度。
B. If there is already an entry for this { address, VLAN } pair with the same accompanying delivery information, the confidence level in the local database is set to the maximum of its existing confidence level and the confidence level with which it is being learned. In addition, if the information is being learned with the same or a higher confidence level than its existing confidence level, timer information is reset.
B.如果此{address，VLAN}对已经有一个条目具有相同的附带传递信息，则本地数据库中的置信水平设置为其现有置信水平和正在学习的置信水平的最大值。此外，如果正在以与其现有置信水平相同或更高的置信水平学习信息，则重置计时器信息。
C. If there is already an entry for this { address, VLAN } pair with different information, the learned information replaces the older information only if it is being learned with higher or equal confidence than that in the database entry. If it replaces older information, timer information is also reset.
C.如果此{address，VLAN}对已有一个具有不同信息的条目，则只有以高于或等于数据库条目中的置信度的方式学习时，学习信息才会替换旧信息。如果它替换旧的信息，计时器信息也会重置。
The confidence level mechanism allows an RBridge campus manager to cause certain address learning sources to prevail over others. In a default configuration, without the optional ESADI protocol, addresses are only learned from observing local native frames and the
置信水平机制允许RBridge校园管理者使某些地址学习来源优于其他来源。在默认配置中，没有可选的ESADI协议，只能通过观察本地本机帧和
decapsulation of received TRILL Data frames. Both of these sources default to confidence level 0x20 so, since learning at an equal or high confidence overrides previous learning, the learning in such a default case mimics default 802.1 bridge learning.
对接收到的颤音数据帧进行去封装。这两个源都默认为置信水平0x20，因此，由于以相同或高置信度进行的学习会覆盖以前的学习，因此在这种默认情况下的学习会模拟默认的802.1网桥学习。
While RBridge campus management policies are beyond the scope of this document, here are some example types of policies that can be implemented with the confidence mechanism and the rationale for each:
虽然RBridge校园管理政策超出了本文件的范围，但以下是一些可通过信任机制实施的政策示例类型，以及每种政策的基本原理：
o Locally received native frames might be considered more reliable than decapsulated frames received from remote parts of the campus. To stop MAC addresses learned from such local frames from being usurped by remotely received forged frames, the confidence in locally learned addresses could be increased or that in addresses learned from remotely sourced decapsulated frames decreased.
o 本地接收的本机帧可能被认为比从校园远程部分接收的未封装帧更可靠。为了阻止从这样的本地帧学习的MAC地址被远程接收的伪造帧篡夺，可以提高本地学习地址的置信度，或者降低从远程来源的去封装帧学习的地址的置信度。
o MAC address information learned through a cryptographically authenticated Layer 2 registration protocol, such as 802.1X with a cryptographically based EAP method, might be considered more reliable than information learned through the mere observation of data frames. When such authenticated learned address information is transmitted via the ESADI protocol, the use of authentication in the TRILL ESADI LSP frames could make tampering with it in transit very difficult. As a result, it might be reasonable to announce such authenticated information via the ESADI protocol with a high confidence, so it would override any alternative learning from data observation.
o 通过加密认证的第2层注册协议（例如802.1X和基于加密的EAP方法）获取的MAC地址信息可能被认为比仅仅通过观察数据帧获取的信息更可靠。当通过ESADI协议传输此类经认证的学习地址信息时，在TRILL ESADI LSP帧中使用认证可能会使在传输过程中对其进行篡改变得非常困难。因此，通过ESADI协议以高置信度公布此类认证信息可能是合理的，因此它将覆盖从数据观察中获得的任何替代学习。
Manually configured address information is generally considered static and so defaults to a confidence of 0xFF while no other source of such information can be configured to a confidence any higher than 0xFE. However, for other cases, such as where the manual configuration is just a starting point that the Rbridge campus manager wishes to be dynamically overridable, the confidence of such manually configured information may be configured to a lower value.
手动配置的地址信息通常被认为是静态的，因此默认为0xFF的置信度，而此类信息的任何其他来源都不能配置为高于0xFE的置信度。然而，对于其他情况，例如，在手动配置只是Rbridge校园管理器希望动态覆盖的起点的情况下，可以将此类手动配置信息的置信度配置为较低的值。
While RBridges need to learn end-station addresses as described above, it is equally important that they be able to forget such information. Otherwise, frames for end stations that have moved to a different part of the campus could be indefinitely black-holed by RBridges with stale information as to the link to which the end station is attached.
尽管RBridge需要学习如上所述的终端站地址，但同样重要的是，它们能够忘记这些信息。否则，移动到校园不同部分的终端站的帧可能会被RBridges无限期地用关于终端站所连接的链路的陈旧信息进行黑洞。
For end-station address information locally learned from frames received, the time out from the last time a native frame was received or decapsulated with the information conforms to the recommendations
对于从接收到的帧本地学习的端站地址信息，自上次接收到本机帧或使用该信息解除封装时起的超时符合建议
of [802.1D]. It is referred to as the "Ageing Time" and is configurable per RBridge with a range of from 10 seconds to 1,000,000 seconds and a default value of 300 seconds.
属于[802.1D]。它被称为“老化时间”，可根据RBridge配置，范围为10秒到1000000秒，默认值为300秒。
The situation is different for end-station address information acquired via the TRILL ESADI protocol. It is up to the originating RBridge to decide when to remove such information from its ESADI LSPs (or up to ESADI protocol timeouts if the originating RBridge becomes inaccessible).
对于通过TRILL ESADI协议获取的端站地址信息，情况有所不同。由发起RBridge决定何时从其ESADI LSP中删除此类信息（或如果发起RBridge变得不可访问，则直至ESADI协议超时）。
When an RBridge ceases to be appointed forwarder for VLAN-x on a port, it forgets all end-station address information learned from the observation of VLAN-x native frames received on that port. It also increments a per-VLAN counter of the number of times it lost appointed forwarder status on one of its ports for that VLAN.
当RBridge不再被指定为端口上VLAN-x的转发器时，它会忘记从该端口上接收的VLAN-x本机帧的观察中获得的所有端站地址信息。它还增加每个VLAN计数器，表示它在该VLAN的一个端口上丢失指定转发器状态的次数。
When, for all of its ports, RBridge RBn is no longer appointed forwarder for VLAN-x, it forgets all end-station address information learned from decapsulating VLAN-x native frames. Also, if RBn is participating in the TRILL ESADI protocol for VLAN-x, it ceases to so participate after sending a final LSP nulling out the end-station address information for the VLAN that it had been originating. In addition, all other RBridges that are VLAN-x forwarder on at least one of their ports notice that the link state data for RBn has changed to show that it no longer has a link on VLAN-x. In response, they forget all end-station address information they have learned from decapsulating VLAN-x frames that show RBn as the ingress RBridge.
对于其所有端口，当RBridge RBn不再被指定为VLAN-x的转发器时，它会忘记从解封装VLAN-x本机帧中获取的所有端站地址信息。此外，如果RBn正在参与VLAN-x的TRILL ESADI协议，则在发送最终LSP使其发起的VLAN的端站地址信息为空后，RBn将停止参与。此外，在至少一个端口上作为VLAN-x转发器的所有其他RBridge都会注意到RBn的链路状态数据已更改，表明它在VLAN-x上不再有链路。作为响应，他们忘记了从将RBn显示为入口RBridge的解封装VLAN-x帧中学到的所有端站地址信息。
When the appointed forwarder lost counter for RBridge RBn for VLAN-x is observed to increase via the TRILL IS-IS link state database but RBn continues to be an appointed forwarder for VLAN-x on at least one of its ports, every other RBridge that is an appointed forwarder for VLAN-x modifies the aging of all the addresses it has learned by decapsulating native frames in VLAN-x from ingress RBridge RBn as follows: the time remaining for each entry is adjusted to be no larger than a per-RBridge configuration parameter called (to correspond to [802.1D]) "Forward Delay". This parameter is in the range of 4 to 30 seconds with a default value of 15 seconds.
当通过TRILL is-is链路状态数据库观察到用于VLAN-x的RBridge RBn的指定转发器丢失计数器增加，但RBn在其至少一个端口上仍然是VLAN-x的指定转发器时，作为VLAN-x指定转发器的每一个其他RBridge都会通过从入口RBridge RBn中解封装VLAN-x中的本机帧来修改它所了解到的所有地址的老化，如下所示：每个条目的剩余时间被调整为不大于一个调用的每个RBridge配置参数（对应于[802.1D]）“向前延迟”。此参数的范围为4到30秒，默认值为15秒。
RBridges can map VLAN IDs into a smaller number of identifiers for purposes of address learning, as [802.1Q-2005] bridges can. Then, when a lookup is done in learned address information, this identifier is used for matching in place of the VLAN ID. If the ID of the VLAN on which the address was learned is not retained, then there are the following consequences:
RBridges可以像[802.1Q-2005]网桥一样，将VLAN ID映射到数量较少的标识符中，以便进行地址学习。然后，当在读入的地址信息中进行查找时，此标识符用于匹配而不是VLAN ID。如果读入地址的VLAN的ID未保留，则会产生以下后果：
o The RBridge no longer has the information needed to participate in the TRILL ESADI protocol for the VLANs whose ID is not being retained.
o 对于ID未被保留的VLAN，RBridge不再具有参与TRILL ESADI协议所需的信息。
o In cases where Section 4.8.3 above requires the discarding of learned address information based on a particular VLAN, when the VLAN ID is not available for entries under a shared VLAN identifier, instead the time remaining for each entry under that shared VLAN identifier is adjusted to be no longer than the RBridge's "Forward Delay".
o 如果上述第4.8.3节要求丢弃基于特定VLAN的学习地址信息，则当共享VLAN标识符下的条目无法使用VLAN ID时，该共享VLAN标识符下每个条目的剩余时间将调整为不超过RBridge的“前向延迟”。
Although outside the scope of this specification, there are some Layer 2 features in which a set of VLANs has shared learning, where one of the VLANs is the "primary" and the other VLANs in the group are "secondaries". An example of this is where traffic from different communities is separated using VLAN tags, and yet some resource (such as an IP router or DHCP server) is to be shared by all the communities. A method of implementing this feature is to give a VLAN tag, say, Z, to a link containing the shared resource, and have the other VLANs, say, A, C, and D, be part of the group { primary = Z, secondaries = A, C, D }. An RBridge, aware of this grouping, attached to one of the secondary VLANs in the group also claims to be attached to the primary VLAN. So an RBridge attached to A would claim to also be attached to Z. An RBridge attached to the primary would claim to be attached to all the VLANs in the group.
尽管不在本规范的范围内，但仍存在一些第2层功能，其中一组VLAN具有共享学习功能，其中一个VLAN为“主要”，组中的其他VLAN为“次要”。这方面的一个例子是，使用VLAN标记分隔来自不同社区的流量，但一些资源（如IP路由器或DHCP服务器）将由所有社区共享。实现此功能的一种方法是为包含共享资源的链接提供一个VLAN标记，例如Z，并使其他VLAN，例如A、C和D，成为组{primary=Z，secondaries=A、C、D}的一部分。连接到组中一个辅助VLAN的RBridge（知道此分组）也声称连接到主VLAN。因此，连接到A的RBridge将声明也连接到Z。连接到主节点的RBridge将声明连接到组中的所有VLAN。
This document does not specify how VLAN groups might be used. Only RBridges that participate in a VLAN group will be configured to know about the VLAN group. However, to detect misconfiguration, an RBridge configured to know about a VLAN group SHOULD report the VLAN group in its LSP.
本文档未指定如何使用VLAN组。只有参与VLAN组的RBridge才会配置为了解VLAN组。但是，为了检测错误配置，配置为了解VLAN组的RBridge应在其LSP中报告VLAN组。
Section 4.9.1 below describes the several RBridge port configuration bits, Section 4.9.2 gives a logical port structure in terms of frame processing, and Sections 4.9.3 and 4.9.4 describe the handling of high-level control frames.
下面第4.9.1节描述了几个RBridge端口配置位，第4.9.2节给出了帧处理方面的逻辑端口结构，第4.9.3节和第4.9.4节描述了高级控制帧的处理。
There are four per-port configuration bits as follows:
每个端口有四个配置位，如下所示：
o Disable port bit. When this bit is set, all frames received or to be transmitted are discarded, with the possible exception of some Layer 2 control frames (see Section 1.4) that may be generated and transmitted or received and processed within the port. By default, ports are enabled.
o 禁用端口位。当设置该位时，所有已接收或将要发送的帧都被丢弃，但可能在端口内生成和发送或接收和处理的某些第2层控制帧（见第1.4节）除外。默认情况下，端口处于启用状态。
o End-station service disable (trunk port) bit. When this bit is set, all native frames received on the port and all native frames that would have been sent on the port are discarded. (See Appendix B.) (Note that, for this document, "native frames" does not include Layer 2 control frames.) By default, ports are not restricted to being trunk ports.
o 终端站服务禁用（中继端口）位。设置此位时，端口上接收到的所有本机帧和端口上发送的所有本机帧都将被丢弃。（参见附录B）（注意，对于本文档，“本机帧”不包括第2层控制帧。）默认情况下，端口不限于中继端口。
If a port with end-station service disabled reports, in a TRILL-Hello frame it sends out that port, which VLANs it provides end-station support for, it reports that there are none.
如果禁用了端站服务的端口报告，则在TRILL Hello帧中，它会发送该端口（为其提供端站支持的VLAN），并报告没有。
o TRILL traffic disable (access port) bit. If this bit is set, the goal is to avoid sending any TRILL frames, except TRILL-Hello frames, on the port since it is intended only for native end-station traffic. By default, ports are not restricted to being access ports. This bit is reported in TRILL-Hello frames. If RB1 is the DRB and has this bit set in its TRILL-Hello, the DRB still appoints VLAN forwarders. However, usually no pseudonode is reported, and none of the inter-RBridge links associated with that link are reported in LSPs.
o 颤音通信禁用（访问端口）位。如果设置了此位，则目标是避免在端口上发送除TRILL Hello帧之外的任何TRILL帧，因为它仅用于本机终端站通信。默认情况下，端口不限于访问端口。此位在颤音Hello帧中报告。如果RB1是DRB，并且在其TRILL Hello中设置了该位，DRB仍然指定VLAN转发器。然而，通常不报告伪节点，并且在lsp中不报告与该链路相关联的RBridge间链路。
If the DRB RB1 does not have this bit set, but neighbor RB2 on the link does have the bit set, then RB1 does not appoint RB2 as appointed forwarder for any VLAN, and none of the RBridges (including the pseudonode) report RB2 as a neighbor in LSPs.
如果DRB RB1没有该位集，但链路上的邻居RB2有该位集，则RB1不会将RB2指定为任何VLAN的指定转发器，并且没有任何RBridge（包括伪节点）将RB2报告为LSP中的邻居。
In some cases even though the DRB has the "access port" flag set, the DRB MAY choose to create a pseudonode for the access port. In this case, the other RBridges report connectivity to the pseudonode in their LSP, but the DRB sets the "overload" flag in the pseudonode LSP.
在某些情况下，即使DRB设置了“访问端口”标志，DRB也可以选择为访问端口创建伪节点。在这种情况下，其他rbridge在其LSP中报告到伪节点的连接，但DRB在伪节点LSP中设置“过载”标志。
o Use P2P Hellos bit. If this bit is set, Hellos sent on this port are IS-IS P2P Hellos. By default TRILL-Hellos are used. See Section 4.2.4.1 for more information on P2P links.
o 使用P2P Hellos位。如果设置了此位，则此端口上发送的Hello为is-is P2P Hello。默认情况下，使用颤音Hello。有关P2P链接的更多信息，请参见第4.2.4.1节。
The dominance relationship of these four configuration bits is as follows, where configuration bits to the left dominate those to the right. That is to say, when any pair of bits is asserted, inconsistencies in behavior they mandate are resolved in favor of behavior mandated by the bit to the left of the other bit in this list.
这四个配置位的支配关系如下所示，其中左侧的配置位支配右侧的配置位。也就是说，当断言任何一对位时，它们所要求的行为的不一致性都会得到解决，从而有利于此列表中另一位左侧的位所要求的行为。
Disable > P2P > Access > Trunk
Disable > P2P > Access > Trunk
An RBridge port can be modeled as having a lower-level structure similar to that of an [802.1Q-2005] bridge port as shown in Figure 11. In this figure, the double lines represent the general flow of the frames and information while single lines represent information flow only. The dashed lines in connection with VRP (GVRP/MVRP) are to show that VRP support is optional. An actual RBridge port implementation may be structured in any way that provides the correct behavior.
RBridge端口可以建模为具有与图11所示的[802.1Q-2005]网桥端口类似的较低级别结构。在该图中，双线表示帧和信息的一般流，而单线仅表示信息流。与VRP（GVRP/MVRP）相关的虚线表示VRP支持是可选的。实际的RBridge端口实现可以以提供正确行为的任何方式构造。
+----------------------------------------------
| RBridge
|
| Interport Forwarding, IS-IS. Management, ...
|
+----++----------------------+-------------++--
|| | ||
TRILL || Data | ||
|| +--+---------+ ||
+-------------++-----+ | TRILL | ||
| Encapsulation | +------+ IS-IS Hello| ||
| Decapsulation | | | Processing | ||
| Processing | | +-----++-----+ ||
+--------------------+ | || ||
| RBridge Appointed +------+ || ||
+---+ Forwarder and | || ||
| | Inhibition Logic +==============\\ || //====++
| +---------+--------+-+ Native \\ ++ //
| | | Frames \++/
| | | ||
+----+-----+ +- - + - - + | ||
| RBridge | | RBridge | | || All TRILL and
| BPDU | | VRP | | || Native Frames
|Processing| |Processing| | ||
+-----++---+ + - - -+- -+ | +--------++--+ <- EISS
|| | | | 802.1Q |
|| | | | Port VLAN |
|| | | |and Priority|
|| | | | Processing |
+---++------------++------+------------+------------+ <-- ISS
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
+------------++-------------------------------------+
||
|| +------------+
|| | 802.3 PHY |
++========+ (Physical +======== 802.3
| Interface) | Link
+------------+
+----------------------------------------------
| RBridge
|
| Interport Forwarding, IS-IS. Management, ...
|
+----++----------------------+-------------++--
|| | ||
TRILL || Data | ||
|| +--+---------+ ||
+-------------++-----+ | TRILL | ||
| Encapsulation | +------+ IS-IS Hello| ||
| Decapsulation | | | Processing | ||
| Processing | | +-----++-----+ ||
+--------------------+ | || ||
| RBridge Appointed +------+ || ||
+---+ Forwarder and | || ||
| | Inhibition Logic +==============\\ || //====++
| +---------+--------+-+ Native \\ ++ //
| | | Frames \++/
| | | ||
+----+-----+ +- - + - - + | ||
| RBridge | | RBridge | | || All TRILL and
| BPDU | | VRP | | || Native Frames
|Processing| |Processing| | ||
+-----++---+ + - - -+- -+ | +--------++--+ <- EISS
|| | | | 802.1Q |
|| | | | Port VLAN |
|| | | |and Priority|
|| | | | Processing |
+---++------------++------+------------+------------+ <-- ISS
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
+------------++-------------------------------------+
||
|| +------------+
|| | 802.3 PHY |
++========+ (Physical +======== 802.3
| Interface) | Link
+------------+
Figure 11: Detailed RBridge Port Model
图11：详细的RBridge端口模型
Low-level control frames are handled in the lower-level port/link control logic in the same way as in an [802.1Q-2005] bridge port. This can optionally include a variety of 802.1 or link specific protocols such as PAUSE (Annex 31B of [802.3]), link layer discovery [802.1AB], link aggregation [802.1AX], MAC security [802.1AE], or port-based access control [802.1X]. While handled at a low level,
低级控制帧在低级端口/链路控制逻辑中以与[802.1Q-2005]网桥端口相同的方式进行处理。这可以可选地包括各种802.1或链路特定协议，例如暂停（802.3的附录31B）、链路层发现[802.1AB]、链路聚合[802.1AX]、MAC安全[802.1AE]或基于端口的访问控制[802.1X]。虽然处理水平较低，
these frames may affect higher-level processing. For example, a Layer 2 registration protocol may affect the confidence in learned addresses. The upper interface to this lower-level port control logic corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005].
这些帧可能会影响更高级别的处理。例如，第2层注册协议可能会影响学习地址的可信度。此下层端口控制逻辑的上层接口对应于[802.1Q-2005]中的内部子层服务（ISS）。
High-level control frames (BPDUs and, if supported, VRP frames) are not VLAN tagged. Although they extend through the ISS interface, they are not subject to port VLAN processing. Behavior on receipt of a VLAN tagged BPDU or VLAN tagged VRP frame is unspecified. If a VRP is not implemented, then all VRP frames are discarded. Handling of BPDUs is described in Section 4.9.3. Handling of VRP frames is described in Section 4.9.4.
高级控制帧（BPDU和VRP帧（如果支持）没有VLAN标记。尽管它们通过ISS接口扩展，但它们不受端口VLAN处理的约束。未指定收到VLAN标记的BPDU或VLAN标记的VRP帧时的行为。如果未实现VRP，则丢弃所有VRP帧。第4.9.3节描述了BPDU的处理。第4.9.4节描述了VRP框架的处理。
Frames other than Layer 2 control frames, that is, all TRILL and native frames, are subject to port VLAN and priority processing that is the same as for an [802.1Q-2005] bridge. The upper interface to the port VLAN and priority processing corresponds to the Extended Internal Sublayer Service (EISS) in [802.1Q-2005].
除第2层控制帧以外的帧，即所有TRILL和本机帧，都要接受端口VLAN和优先级处理，这与[802.1Q-2005]网桥相同。端口VLAN和优先级处理的上层接口对应于[802.1Q-2005]中的扩展内部子层服务（EISS）。
In this model, RBridge port processing below the EISS layer is identical to an [802.1Q-2005] bridge except for (1) the handling of high-level control frames and (2) that the discard of frames that have exceeded the Maximum Transit Delay is not mandatory but MAY be done.
在此模型中，EISS层下的RBridge端口处理与[802.1Q-2005]网桥相同，除了（1）处理高级控制帧和（2）丢弃超过最大传输延迟的帧不是强制性的，但可以这样做。
As described in more detail elsewhere in this document, incoming native frames are only accepted if the RBridge is an uninhibited appointed forwarder for the frame's VLAN, after which they are normally encapsulated and forwarded; outgoing native frames are usually obtained by decapsulation and are only output if the RBridge is an uninhibited appointed forwarder for the frame's VLAN.
如本文档其他地方更详细地描述的，只有当RBridge是帧的VLAN的不受限制的指定转发器时，才接受传入的本机帧，在此之后，它们通常被封装和转发；传出本机帧通常通过解除封装获得，并且仅当RBridge是帧VLAN的不受限制的指定转发器时才输出。
TRILL-Hellos, MTU-probes, and MTU-acks are handled per port and, like all TRILL IS-IS frames, are never forwarded. They can affect the appointed forwarder and inhibition logic as well as the RBridge's LSP.
TRILL Hellos、MTU探测器和MTU ACK按端口处理，与所有TRILL IS-IS帧一样，从不转发。它们会影响指定的转发器和抑制逻辑以及RBridge的LSP。
Except TRILL-Hellos, MTU-probes, and MTU-acks, all TRILL control as well as TRILL data and ESADI frames are passed up to higher-level RBridge processing on receipt and passed down for transmission on creation or forwarding. Note that these frames are never blocked due to the appointed forwarder and inhibition logic, which affects only native frames, but there are additional filters on some of them such as the Reverse Path Forwarding Check.
除TRILL Hellos、MTU Probe和MTU Ack外，所有TRILL控制以及TRILL数据和ESADI帧在接收时都会传递给更高级别的RBridge处理，并在创建或转发时传递给传输。请注意，由于指定的转发器和抑制逻辑（仅影响本机帧），这些帧从未被阻止，但其中一些帧上还有其他筛选器，如反向路径转发检查。
If RBridge campus topology were static, RBridges would simply be end stations from a bridging perspective, terminating but not otherwise interacting with spanning tree. However, there are reasons for RBridges to listen to and sometimes to transmit BPDUs as described below. Even when RBridges listen to and transmit BPDUs, this is a local RBridge port activity. The ports of a particular RBridge never interact so as to make the RBridge as a whole a spanning tree node.
若RBridge校园拓扑是静态的，则从桥接的角度来看，RBridge将只是终端站，终止，但不与生成树交互。然而，如下所述，rbridge需要监听，有时需要传输bpdu，这是有原因的。即使在RBridge侦听和传输BPDU时，这也是本地RBridge端口活动。特定RBridge的端口从不交互，从而使RBridge作为一个整体成为生成树节点。
Rbridges MUST listen to spanning tree configuration BPDUs received on a port and keep track of the root bridge, if any, on that link. If MSTP is running on the link, this is the CIST root. This information is reported per VLAN by the RBridge in its LSP and may be used as described in Section 4.2.4.3. In addition, the receipt of spanning tree configuration BPDUs is used as an indication that a link is a bridged LAN, which can affect the RBridge transmission of BPDUs.
Rbridges必须侦听端口上接收的生成树配置BPDU，并跟踪该链路上的根网桥（如果有）。如果MSTP正在链接上运行，则这是CIST根目录。该信息由RBridge在其LSP中按VLAN报告，并可按第4.2.4.3节所述使用。此外，生成树配置BPDU的接收被用作指示链路是桥接LAN，这可能会影响BPDU的RBridge传输。
An RBridge MUST NOT encapsulate or forward any BPDU frame it receives.
RBridge不能封装或转发它接收的任何BPDU帧。
RBridges discard any topology change BPDUs they receive, but note Section 4.9.3.3.
RBridges放弃接收到的任何拓扑更改BPDU，但请注意第4.9.3.3节。
A change in the root bridge seen in the spanning tree BPDUs received at an RBridge port may indicate a change in bridged LAN topology, including the possibility of the merger of two bridged LANs or the like, without any physical indication at the port. During topology transients, bridges may go into pre-forwarding states that block TRILL-Hello frames. For these reasons, when an RBridge sees a root bridge change on a port for which it is appointed forwarder for one or more VLANs, it is inhibited for a period of time between zero and 30 seconds. (An inhibited appointed forwarder discards all native frames received from or that it would otherwise have sent to the link.) This time period is configurable per port and defaults to 30 seconds.
在RBridge端口处接收的生成树bpdu中看到的根网桥的变化可指示桥接LAN拓扑的变化，包括两个桥接LAN等合并的可能性，而不在端口处进行任何物理指示。在拓扑过渡期间，网桥可能会进入阻止TRILL Hello帧的转发前状态。由于这些原因，当RBridge在其被指定为一个或多个VLAN的转发器的端口上看到根网桥更改时，它将被禁止0到30秒之间的一段时间。（被禁止的指定转发器丢弃从链路接收的或本来会发送到链路的所有本机帧。）此时间段可配置为每个端口，默认为30秒。
For example, consider two bridged LANs carrying multiple VLANs, each with various RBridge appointed forwarders. Should they become merged, due to a cable being plugged in or the like, those RBridges attached to the original bridged LAN with the lower priority root will see a root bridge change while those attached to the other original bridged LAN will not. Thus, all appointed forwarders in the
例如，考虑两个桥接LAN承载多个VLAN，每个局域网具有各种R桥桥联的转发服务器。如果由于插入电缆等原因，它们合并，则连接到具有较低优先级根的原始桥接LAN的那些RBridge将看到根网桥更改，而连接到其他原始桥接LAN的RBridge将不会更改。因此，所有指定的货运代理
lower priority set will be inhibited for a time period while things are sorted out by BPDUs within the merged bridged LAN and TRILL-Hello frames between the RBridges involved.
较低优先级设置将在一段时间内被禁止，同时BPDU将在合并的桥接LAN内和所涉及的RBridge之间的TRILL Hello帧中进行排序。
When an RBridge ceases to be appointed forwarder for one or more VLANs out a particular port, it SHOULD, as long as it continues to receive spanning tree BPDUs on that port, send topology change BPDUs until it sees the topology change acknowledged in a spanning tree configuration BPDU.
当RBridge不再被指定为特定端口的一个或多个VLAN的转发器时，只要它继续在该端口上接收生成树BPDU，就应该发送拓扑更改BPDU，直到它在生成树配置BPDU中看到已确认的拓扑更改。
RBridges MAY support a capability for sending spanning tree BPDUs for the purpose of attempting to force a bridged LAN to partition as discussed in Appendix A.3.3.
RBridges可支持发送生成树BPDU的功能，以尝试强制桥接LAN分区，如附录a.3.3所述。
Dynamic VLAN registration provides a means for bridges (and less commonly end stations) to request that VLANs be enabled or disabled on ports leading to the requestor. This is done by VLAN registration protocol (VRP) frames: GVRP or MVRP. RBridges MAY implement GVRP and/or MVRP as described below.
动态VLAN注册为网桥（以及不太常见的终端站）提供了一种方法，用于请求在通向请求者的端口上启用或禁用VLAN。这是通过VLAN注册协议（VRP）帧完成的：GVRP或MVRP。RBridges可实施如下所述的GVRP和/或MVRP。
VRP frames are never encapsulated as TRILL frames between RBridges or forwarded in native form by an RBridge. If an RBridge does not implement a VRP, it discards any VRP frames received and sends none.
VRP帧从不封装为RBridge之间的颤音帧，也不会由RBridge以本机形式转发。如果RBridge没有实现VRP，它将丢弃接收到的所有VRP帧，并且不发送任何帧。
RBridge ports may have dynamically enabled VLANs. If an RBridge supports a VRP, the actual enablement of dynamic VLANs is determined by GVRP/MVRP frames received at the port as it would be for an [802.1Q-2005] / [802.1ak] bridge.
RBridge端口可能具有动态启用的VLAN。如果RBridge支持VRP，则动态VLAN的实际启用取决于在端口接收到的GVRP/MVRP帧，就像对[802.1Q-2005]/[802.1ak]网桥一样。
An RBridge that supports a VRP sends GVRP/MVRP frames as an [802.1Q-2005] / [802.1ak] bridge would send on each port that is not configured as an RBridge trunk port or P2P port. For this purpose, it sends VRP frames to request traffic in the VLANs for which it is appointed forwarder and in the Designated VLAN, unless the Designated VLAN is disabled on the port, and to not request traffic in any other VLAN.
支持VRP的RBridge将GVRP/MVRP帧作为[802.1Q-2005]/[802.1ak]网桥发送到未配置为RBridge中继端口或P2P端口的每个端口。为此，它发送VRP帧以请求指定转发器所在VLAN和指定VLAN中的流量，除非指定VLAN在端口上被禁用，并且不请求任何其他VLAN中的流量。
This section lists parameters for RBridges. It is expected that the TRILL MIB will include many of the items listed in this section plus additional Rbridge status and data including traffic and error counts.
本节列出了RBridges的参数。预计TRILL MIB将包括本节中列出的许多项目，以及额外的Rbridge状态和数据，包括流量和错误计数。
The default value and range are given for parameters added by TRILL. Where a parameter is defined as a 16-bit unsigned integer and an explicit maximum is not given, that maximum is 2**16-1. For parameters imported from [802.1Q-2005], [802.1D], or IS-IS [ISO10589] [RFC1195], see those standards for default and range if not given here.
对于TRILL添加的参数，会给出默认值和范围。如果参数定义为16位无符号整数且未给出显式最大值，则最大值为2**16-1。对于从[802.1Q-2005]、[802.1D]或IS-IS[ISO10589][RFC1195]导入的参数，如果此处未给出默认值和范围，请参阅这些标准。
The following parameters occur per RBridge:
每个RBridge都会出现以下参数：
o Number of nicknames, which defaults to 1 and may be configured in the range of 1 to 256.
o 昵称数，默认为1，可在1到256之间配置。
o The desired number of distribution trees to be calculated by every RBridge in the campus and a desired number of distribution trees for the advertising RBridge to use, both of which are unsigned 16-bit integers that default to 1 (see Section 4.5).
o 校园中每个RBridge要计算的期望分布树数和广告RBridge要使用的期望分布树数，两者都是默认为1的无符号16位整数（见第4.5节）。
o The maximum number of distribution trees the RBridge can compute. This is a 16-bit unsigned integer that is implementation and environment dependent and not subject to management configuration.
o RBridge可以计算的最大分布树数。这是一个16位无符号整数，它依赖于实现和环境，不受管理配置的约束。
o Two lists of nicknames, one designating the distribution trees to be computed and one designating distribution trees to be used as discussed in Section 4.5. By default, these lists are empty.
o 两个昵称列表，一个指定要计算的分布树，一个指定要使用的分布树，如第4.5节所述。默认情况下，这些列表为空。
o The parameters Ageing Timer and Forward Delay with the default and range specified in [802.1Q-2005].
o 参数包括[802.1Q-2005]中规定的默认值和范围的老化定时器和前向延迟。
o Two unsigned octets that are, respectively, the confidence in { MAC, VLAN, local port } triples learned from locally received native frames and the confidence in { MAC, VLAN, remote RBridge } triples learned from decapsulating frames. These each default to 0x20 and may each be configured to values from 0x00 to 0xFE.
o 两个无符号八位字节，分别是从本地接收的本机帧中学习的{MAC，VLAN，本地端口}三元组的置信度和从解封装帧中学习的{MAC，VLAN，远程RBridge}三元组的置信度。这些值都默认为0x20，并且可以配置为0x00到0xFE之间的值。
o The desired minimum acceptable inter-RBridge link MTU for the campus, that is, originatingLSPBufferSize. This is a 16-bit unsigned integer number of octets that defaults to 1470 bytes, which is the minimum valid value. Any lower value being advertised by an RBridge is ignored.
o 校园所需的最小可接受RBridge间链路MTU，即原始LSPBufferSize。这是一个16位无符号整数八位字节数，默认为1470字节，这是最小有效值。RBridge发布的任何较低的值都将被忽略。
o The number of failed MTU-probes before the RBridge concludes that a particular MTU is not supported, which defaults to 3 and may be configured between 1 and 255.
o RBridge得出不支持特定MTU的结论之前失败的MTU探测数，默认为3，可配置为1到255之间。
Static end-station address information and confidence in such end station information statically configured can also be configured with a default confidence of 0xFF and range of 0x00 to 0xFF. By default, there is no such static address information. The quantity of such information that can be configured is implementation dependent.
静态端站地址信息和静态配置的此类端站信息的置信度也可以配置为默认置信度0xFF和范围0x00到0xFF。默认情况下，没有此类静态地址信息。可以配置的此类信息的数量取决于实现。
The following is configuration information per nickname at each RBridge:
以下是每个RBridge上每个昵称的配置信息：
o Priority to hold the nickname, which defaults to 0x40 if no specific value has been configured or 0xC0 if it is configured (see Section 3.7.3).
o 保留昵称的优先级，如果未配置特定值，则默认为0x40；如果已配置，则默认为0xC0（参见第3.7.3节）。
o Nickname priority to be selected as a distribution tree root, a 16-bit unsigned integer that defaults to 0x8000.
o 要选择作为分发树根的昵称优先级，一个默认为0x8000的16位无符号整数。
o Nickname value, an unsigned 16-bit quantity that defaults to the configured value if configured, else to the last value held if the RBridge coming up after a reboot and that value is remembered, else to a random value; however, in all cases the reserved values 0x0000 and 0xFFC0 through 0xFFFF are excluded (see Section 3.7.3).
o 昵称值，一个无符号的16位数量，如果配置，默认为配置值，否则为RBridge在重新启动后出现并记住该值时保留的最后一个值，否则为随机值；但是，在所有情况下，保留值0x0000和0xFFC0至0xFFFF均被排除在外（见第3.7.3节）。
An RBridge has the following per-port configuration parameters:
RBridge具有以下每端口配置参数：
o The same parameters as an [802.1Q-2005] port in terms of C-VLAN IDs. In addition, there is an Announcing VLANs set that defaults to the enabled VLANs on the port (see Section 4.4.3) and ranges from the null set to the set of all legal VLAN IDs.
o 与[802.1Q-2005]端口在C-VLAN ID方面的参数相同。此外，还有一个公布的VLAN集，默认为端口上启用的VLAN（参见第4.4.3节），范围从空集到所有合法VLAN ID集。
o The same parameters as an [802.1Q-2005] port in terms of frame priority code point mapping (see [802.1Q-2005]).
o 与[802.1Q-2005]端口在帧优先级码点映射方面的参数相同（参见[802.1Q-2005]）。
o The inhibition time for the port when it observed a change in the root bridge of an attached bridged LAN. This is in units of seconds, defaults to 30, and can be configured to any value from 0 to 30.
o 端口观察到连接的桥接LAN的根网桥发生变化时的抑制时间。这是以秒为单位的，默认为30，可以配置为0到30之间的任何值。
o The Desired Designated VLAN that the RBridge will advertise in its TRILL Hellos if it is the DRB for the link via that port. This defaults to the lowest VLAN ID enabled on the port and may be configured to any valid VLAN ID that is enabled on the port (0x001 through 0xFFE).
o 如果RBridge是通过该端口的链路的DRB，则RBridge将在其TRILL Hello中公布的所需指定VLAN。这默认为端口上启用的最低VLAN ID，并且可以配置为端口上启用的任何有效VLAN ID（0x001到0xFFE）。
o Four per-port configuration bits: disable port (default 0 == enabled), disable end-station service (trunk, default 0 == enabled), access port (default 0 == not restricted to being an access port), and use P2P Hellos (default 0 == use TRILL Hellos). (See Section 4.9.1.)
o 每端口四个配置位：禁用端口（默认0==已启用）、禁用终端站服务（中继，默认0==已启用）、访问端口（默认0==不限于作为访问端口）和使用P2P Hellos（默认0==使用TRILL Hellos）。（见第4.9.1节。）
o One bit per port such that, if the bit is set, it disables learning { MAC address, VLAN, port } triples from locally received native frames on the port. Default value is 0 == learning enabled.
o 每个端口一位，这样，如果设置了该位，它将禁用从端口上本地接收的本机帧学习{MAC地址、VLAN、端口}三倍。默认值为0==已启用学习。
o The priority of the RBridge to be DRB and its Holding Time via that port with defaults and range as specified in IS-IS [ISO10589] [RFC1195].
o RBridge的优先级为DRB，其通过该端口的保持时间具有IS-IS[ISO10589][RFC1195]中规定的默认值和范围。
o A bit that, when set, enables the receipt of TRILL-encapsulated frames from an Outer.MacSA with which the RBridges does not have an IS-IS adjacency. Default value is 0 == disabled.
o 一种位，设置后，可从RBridges没有IS-IS邻接的Outer.MacSA接收颤音封装帧。默认值为0==已禁用。
o Configuration for the optional send-BPDUs solution to the wiring closet topology problem as described in Appendix A.3.3. Default Bridge Address is the System ID of the RBridge with the lowest System ID. If RB1 and RB2 are part of a wiring closet topology, both need to be configured to know about this, and know the ID that should be used in the spanning tree protocol on the specified port.
o 附件A.3.3中描述的接线柜拓扑问题的可选发送BPDUs解决方案的配置。默认网桥地址是具有最低系统ID的RBridge的系统ID。如果RB1和RB2是布线机柜拓扑的一部分，则需要对两者进行配置，以了解这一点，并了解应在指定端口上的生成树协议中使用的ID。
An RBridge has the following per-VLAN configuration parameters:
RBridge具有以下每VLAN配置参数：
o Per-VLAN ESADI protocol participation flag, 7-bit priority, and Holding Time. Default participation flag is 0 == not participating. Default and range of priority and Holding Time as specified in IS-IS [ISO10589] [RFC1195].
o 每VLAN ESADI协议参与标志、7位优先级和保持时间。默认参与标志为0==不参与。IS-IS[ISO10589][RFC1195]中规定的优先级和保持时间的默认值和范围。
o One bit per VLAN that, if set, disables learning { MAC address, VLAN, remote RBridge } triples from frames decapsulated in the VLAN. Defaults to 0 == learning enabled.
o 每个VLAN一位，如果设置，则禁用从VLAN中解封的帧学习{MAC地址，VLAN，远程RBridge}三倍。默认值为0==已启用学习。
Layer 2 bridging is not inherently secure. It is, for example, subject to spoofing of source addresses and bridging control messages. A goal for TRILL is that RBridges do not add new issues beyond those existing in current bridging technology.
第2层桥接本身并不安全。例如，它会受到源地址欺骗和桥接控制消息的影响。TRILL的一个目标是，RBridges不会在现有桥接技术之外增加新的问题。
Countermeasures are available such as to configure the TRILL IS-IS and ESADI protocols to use IS-IS security [RFC5304] [RFC5310] and ignore unauthenticated TRILL control and ESADI frames received. RBridges using IS-IS security will need configuration.
对策是可用的，例如配置TRILL IS-IS和ESADI协议以使用IS-IS安全[RFC5304][RFC5310]，并忽略未经验证的TRILL控制和接收到的ESADI帧。使用IS-IS安全性的RBridge将需要配置。
IEEE 802.1 port admission and link security mechanisms, such as [802.1X] and [802.1AE], can also be used. These are best thought of as being implemented below TRILL (see Section 4.9.2) and are outside the scope of TRILL (just as they are generally out of scope for bridging standards [802.1D] and 802.1Q); however, TRILL can make use of secure registration through the confidence level communicated in the optional TRILL ESADI protocol (see Section 4.8).
也可以使用IEEE 802.1端口许可和链路安全机制，如[802.1X]和[802.1AE]。最好将其视为在TRILL下实施（见第4.9.2节），并且不在TRILL的范围内（正如它们通常不在桥接标准[802.1D]和802.1Q的范围内）；但是，TRILL可以通过可选的TRILL ESADI协议（见第4.8节）中传达的置信水平使用安全注册。
TRILL encapsulates native frames inside the RBridge campus while they are in transit between ingress RBridge and egress RBridge(s) as described in Sections 2.3 and 4.1. Thus, TRILL ignorant devices with firewall features that cannot be detected by RBridges as end stations will generally not be able to inspect the content of such frames for security checking purposes. This may render them ineffective. Layer 3 routers and hosts appear to RBridges to be end stations, and native frames will be decapsulated before being sent to such devices. Thus, they will not see the TRILL Ethertype. Firewall devices that do not appear to an RBridge to be an end station, for example, bridges with co-located firewalls, should be modified to understand TRILL encapsulation.
TRILL封装了RBridge园区内的本机帧，当它们在入口RBridge和出口RBridge之间传输时，如第2.3节和第4.1节所述。因此，具有防火墙功能的TRILL-Known设备不能被RBridge作为终端站检测到，通常无法出于安全检查目的检查此类帧的内容。这可能使它们无效。第3层路由器和主机似乎是终端站，本机帧在发送到此类设备之前将被解除封装。因此，他们不会看到颤音以太类型。对于RBridge看来不是终端站的防火墙设备，例如，带有同一位置防火墙的网桥，应该进行修改以理解TRILL封装。
RBridges do not prevent nodes from impersonating other nodes, for instance, by issuing bogus ARP/ND replies. However, RBridges do not interfere with any schemes that would secure neighbor discovery.
RBridges不会阻止节点模仿其他节点，例如，通过发出虚假的ARP/ND回复。但是，RBridges不会干扰任何保护邻居发现的方案。
TRILL supports VLANs. These provide logical separation of traffic, but care should be taken in using VLANs for security purposes. To have reasonable assurance of such separation, all the RBridges and links (including bridged LANs) in a campus must be secured and configured so as to prohibit end stations from using dynamic VLAN registration frames or otherwise gaining access to any VLAN carrying traffic for which they are not authorized to read and/or inject.
TRILL支持VLAN。这些提供了流量的逻辑分离，但出于安全目的使用VLAN时应小心。为了合理地保证这种分离，必须对校园中的所有RBridge和链路（包括桥接LAN）进行安全保护和配置，以禁止终端站使用动态VLAN注册帧或以其他方式访问任何VLAN，这些VLAN承载着未经授权读取和/或注入的流量。
Furthermore, if VLANs were used to keep some information off links where it might be observed in a bridged LAN, this will no longer work, in general, when bridges are replaced with RBridges; with encapsulation and a different outer VLAN tag, the data will travel the least cost transit path regardless of VLAN. Appropriate counter measures are to use end-to-end encryption or an appropriate TRILL security option should one be specified.
此外，如果VLAN被用于将某些信息从桥接LAN中可能观察到的链路上保留下来，一般来说，当网桥被RBridges替换时，这将不再起作用；使用封装和不同的外部VLAN标记，无论VLAN如何，数据都将以最低成本的传输路径传输。适当的应对措施是使用端到端加密或指定适当的TRILL安全选项。
The TRILL protocol requires that an appointed forwarder at an RBridge port be temporarily inhibited if it sees a TRILL-Hello from another RBridge claiming to be the appointed forwarder for the same VLAN or sees a root bridge change out that port. Thus, it would seem that forged BPDUs showing repeated root bridge changes and forged TRILL-Hello frames with the Appointed Forwarder flag set could represent a significant denial-of-service attack. However, the situation is not as bad as it seems.
TRILL协议要求，如果RBridge端口上的指定转发器看到另一个RBridge声称是同一VLAN的指定转发器的TRILL Hello，或看到根网桥从该端口更改，则该端口上的指定转发器将被临时禁止。因此，显示重复根网桥更改的伪造BPDU和带有指定转发器标志集的伪造TRILL Hello帧似乎可能代表严重的拒绝服务攻击。然而，情况并不像看上去那么糟糕。
The best defense against forged TRILL-Hello frames or other IS-IS messages is the use of IS-IS security [RFC5304] [RFC5310]. Rogue end stations would not normally have access to the required IS-IS keying material needed to forge authenticatible messages.
针对伪造TRILL Hello帧或其他IS-IS消息的最佳防御措施是使用IS-IS安全[RFC5304][RFC5310]。流氓终端站通常无法访问伪造可验证消息所需的IS-IS密钥材料。
Authentication similar to IS-IS security is usually unavailable for BPDUs. However, it is also the case that in typical modern wired LANs, all the links are point-to-point. If you have an all-RBridged point-to-point campus, then the worst that an end-station can do by forging BPDUs or TRILL-Hello frames is to deny itself service. This could be either through falsely inhibiting the forwarding of native frames by the RBridge to which it is connected or by falsely activating the optional decapsulation check (see Section 4.2.4.3).
与IS-IS安全性类似的身份验证通常不适用于BPDU。然而，在典型的现代有线局域网中，所有链路都是点对点的。如果您有一个全桥点到点校园，那么终端站通过伪造BPDU或TRILL Hello帧所能做的最糟糕的事情就是拒绝自己的服务。这可能是通过错误地禁止其所连接的RBridge转发本机帧，或者错误地激活可选的去封装检查（参见第4.2.4.3节）。
However, when an RBridge campus contains bridged LANs, those bridged LANs appear to any connected RBridges to be multi-access links. The forging of BPDUs by an end-station attached to such a bridged LAN could affect service to other end-stations attached to the same bridged LAN. Note that bridges never forward BPDUs but process them, although this processing may result in the issuance of further BPDUs. Thus, for an end-station to forge BPDUs to cause continuing changes in the root bridge as seen by an RBridge through intervening bridges would typically require it to cause root bridge thrashing throughout the bridged LAN that would be disruptive even in the absence of RBridges.
但是，当RBridge校园包含桥接LAN时，这些桥接LAN对任何连接的RBridge来说都是多址链路。连接到此类桥接LAN的终端站伪造BPDU可能会影响连接到同一桥接LAN的其他终端站的服务。请注意，桥接器从不转发BPDU，而是对其进行处理，尽管此处理可能会导致发布更多BPDU。因此，如果终端站伪造BPDU以引起根网桥中的持续变化（如RBridge通过中间网桥看到的），则通常要求其在整个桥接LAN中引起根网桥振荡，这将是中断性的，即使在没有RBridge的情况下也是如此。
Some bridges can be configured to not send BPDUs and/or to ignore BPDUs on particular ports, and RBridges can be configured not to inhibit appointed forwarding on a port due to root bridge changes; however, such configuration should be used with caution as it can be unsafe.
一些网桥可以配置为不发送BPDU和/或忽略特定端口上的BPDU，并且RBridge可以配置为不由于根网桥更改而禁止端口上的指定转发；但是，应谨慎使用这种配置，因为它可能不安全。
This section discuses IANA and IEEE 802 assignment considerations. See [RFC5226].
本节讨论IANA和IEEE 802分配注意事项。见[RFC5226]。
A new IANA registry has been created for TRILL Parameters with two subregistries as below.
已为TRILL参数创建了一个新的IANA注册表，其中包含两个子区域，如下所示。
The initial contents of the TRILL Nicknames subregistry are as follows:
TRILL昵称子区域的初始内容如下：
0x0000 Reserved to indicate no nickname specified 0x0001-0xFFBF Dynamically allocated by the RBridges within each RBridge campus 0xFFC0-0xFFFE Available for allocation by RFC Required (single value) or IETF Review (single or multiple values) 0xFFFF Permanently reserved
0x0000保留，表示每个RBridge园区内RBridge动态分配的0x0001-0xFFBF未指定昵称0xFFC0-0xFFFE可由RFC Required（单值）或IETF Review（单值或多值）分配0xFFFF永久保留
The initial contents of the TRILL Multicast Address subregistry are as follows:
TRILL多播地址子区的初始内容如下：
01-80-C2-00-00-40 Assigned as All-RBridges 01-80-C2-00-00-41 Assigned as All-IS-IS-RBridges 01-80-C2-00-00-42 Assigned as All-ESADI-RBridges 01-80-C2-00-00-43 to 01-80-C2-00-00-4F Available for allocation by IETF Review
01-80-C2-00-00-40分配为所有RBridges 01-80-C2-00-00-41分配为所有IS RBridges 01-80-C2-00-00-42分配为所有ESADI RBridges 01-80-C2-00-00-43至01-80-C2-00-00-00-4F，供IETF审查分配
The Ethertype 0x22F3 is assigned by the IEEE Registration Authority to the TRILL Protocol.
以太网类型0x22F3由IEEE注册机构分配给TRILL协议。
The Ethertype 0x22F4 is assigned by the IEEE Registration Authority for L2-IS-IS.
Ethertype 0x22F4由IEEE注册机构为L2-is-is分配。
The block of 16 multicast MAC addresses from <01-80-C2-00-00-40> to <01-80-C2-00-00-4F> is assigned by the IEEE Registration Authority for IETF TRILL protocol use.
IEEE注册机构将从<01-80-C2-00-00-40>到<01-80-C2-00-00-4F>的16个多播MAC地址块分配给IETF TRILL协议使用。
[802.1ak] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks / Multiple Registration Protocol", IEEE Standard 802.1ak-2007, 22 June 2007.
[802.1ak]“局域网和城域网的IEEE标准/虚拟桥接局域网/多重注册协议”，IEEE标准802.1ak-2007，2007年6月22日。
[802.1D] "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004.
[802.1D]“局域网和城域网/媒体访问控制（MAC）网桥的IEEE标准”，802.1D-2004，2004年6月9日。
[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日。
[802.3] "IEEE Standard for Information technology / Telecommunications and information exchange between systems / Local and metropolitan area networks / Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", 802.3-2008, 26 December 2008.
[802.3]“IEEE系统/局域网和城域网之间信息技术/电信和信息交换标准/特定要求第3部分：带冲突检测的载波侦听多址（CSMA/CD）接入方法和物理层规范”，802.3-2008，2008年12月26日。
[ISO10589] ISO/IEC, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002.
[ISO10589]ISO/IEC，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统路由信息交换协议（ISO 8473）”，ISO/IEC 10589:2002。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[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月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417]Presohn，R.，Ed.“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002.
[RFC3419]Daniele，M.和J.Schoenwaeld，“运输地址的文本约定”，RFC 3419，2002年12月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]Haberman，B.和J.Martin，“多播路由器发现”，RFC 4286，2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 2008.
[RFC5303]Katz，D.，Saluja，R.，和D.Eastlake 3rd，“IS-IS点对点邻接的三方握手”，RFC 5303，2008年10月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 61652011年4月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC6326]伊斯特莱克，班纳吉，A.，杜特，D.，帕尔曼，R.，和A.加瓦尼，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 63262011年7月。
[802.1AB] "IEEE Standard for Local and Metropolitan Networks / Station and Media Access Control Connectivity Discovery", 802.1AB-2009, 17 September 2009.
[802.1AB]“本地和城域网络/站点和媒体访问控制连接发现的IEEE标准”，802.1AB-2009，2009年9月17日。
[802.1ad] "IEEE Standard for and metropolitan area networks / Virtual Bridged Local Area Networks / Provider Bridges", 802.1ad-2005, 26 May 2005.
[802.1ad]“城域网/虚拟桥接局域网/提供商网桥的IEEE标准”，802.1ad-2005，2005年5月26日。
[802.1ah] "IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Provider Backbone Bridges", 802.1ah-2008, 1 January 2008.
[802.1ah]“局域网和城域网/虚拟桥接局域网/提供商骨干网桥的IEEE标准”，802.1ah-2008，2008年1月1日。
[802.1aj] Virtual Bridged Local Area Networks / Two-Port Media Access Control (MAC) Relay, 802.1aj Draft 4.2, 24 September 2009.
[802.1aj]虚拟桥接局域网/双端口媒体访问控制（MAC）中继，802.1aj草案4.2，2009年9月24日。
[802.1AE] "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Security", 802.1AE-2006, 18 August 2006.
[802.1AE]“局域网和城域网/媒体访问控制（MAC）安全的IEEE标准”，802.1AE-2006，2006年8月18日。
[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.1X] "IEEE Standard for Local and metropolitan area networks / Port Based Network Access Control", 802.1X-REV Draft 2.9, 3 September 2008.
[802.1X]“局域网和城域网IEEE标准/基于端口的网络访问控制”，802.1X-REV 2.9草案，2008年9月3日。
[RBridges] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, March 2004.
[RBridges]Perlman，R.，“RBridges:透明路由”，过程。信息通信2005年，2004年3月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, November 2006.
[RFC4789]Schoenwaeld，J.和T.Jeffree，“IEEE 802网络上的简单网络管理协议（SNMP）”，RFC 4789，2006年11月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月。
[RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.
[RFC5342]Eastlake 3rd，D.，“IEEE802参数的IANA考虑因素和IETF协议使用”，BCP 141，RFC 5342，2008年9月。
[RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", RFC 5556, May 2009.
[RFC5556]Touch，J.和R.Perlman，“大量链路的透明互连（TRILL）：问题和适用性声明”，RFC 5556，2009年5月。
[RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols, 2nd Edition", Addison Wesley Longman, Chapter 3, 1999.
[RP1999]Perlman，R.“互连：网桥、路由器、交换机和互联协议，第二版”，Addison-Wesley Longman，第3章，1999年。
[VLAN-MAPPING] Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., and D. Eastlake 3rd, "RBridges: Campus VLAN and Priority Regions", Work in Progress, April 2011.
[VLAN-MAPPING]Perlman，R.，Dutt，D.，Banerjee，A.，Rijhsinghani，A.，和D.Eastlake 3rd，“RBridges:校园VLAN和优先区域”，正在进行的工作，2011年4月。
Some aspects of partial RBridge deployment are described below for link cost determination (Appendix A.1) and possible congestion due to appointed forwarder bottlenecks (Appendix A.2). A particular example of a problem related to the TRILL use of a single appointed forwarder per link per VLAN (the "wiring closet topology") is explored in detail in Appendix A.3.
下文描述了部分RBridge部署的一些方面，以确定链路成本（附录A.1）和指定转发器瓶颈导致的可能拥塞（附录A.2）。附录A.3中详细探讨了与每个VLAN每个链路使用单个指定转发器（“布线柜拓扑”）相关的问题的特定示例。
With an RBridged campus having no bridges or repeaters on the links between RBridges, the RBridges can accurately determine the number of physical hops involved in a path and the line speed of each hop, assuming this is reported by their port logic. With intervening devices, this is no longer possible. For example, as shown in Figure 12, the two bridges B1 and B2 can completely hide a slow link so that both Rbridges RB1 and RB2 incorrectly believe the link is faster.
如果RBridges校园在RBridges之间的链路上没有网桥或中继器，则RBridges可以准确地确定路径中涉及的物理跃点数量和每个跃点的线路速度，假设这是由其端口逻辑报告的。有了介入设备，这就不可能了。例如，如图12所示，两个网桥B1和B2可以完全隐藏慢速链路，因此RB1和RB2都错误地认为链路更快。
+-----+ +----+ +----+ +-----+
| | Fast | | Slow | | Fast | |
| RB1 +--------+ B1 +--------+ B2 +--------+ RB2 |
| | Link | | Link | | Link | |
+-----+ +----+ +----+ +-----+
+-----+ +----+ +----+ +-----+
| | Fast | | Slow | | Fast | |
| RB1 +--------+ B1 +--------+ B2 +--------+ RB2 |
| | Link | | Link | | Link | |
+-----+ +----+ +----+ +-----+
Figure 12: Link Cost of a Bridged Link
图12：桥接链路的链路成本
Even in the case of a single intervening bridge, two RBridges may know they are connected but each sees the link as a different speed from how it is seen by the other.
即使是在单个中间网桥的情况下，两个RBridge可能知道它们已连接，但每个RBridge都将链路视为与另一个不同的速度。
However, this problem is not unique to RBridges. Bridges can encounter similar situations due to links hidden by repeaters, and routers can encounter similar situations due to links hidden by bridges, repeaters, or Rbridges.
然而，这个问题并不是RBridges独有的。由于中继器隐藏的链接，网桥可能会遇到类似的情况，而路由器可能会由于网桥、中继器或RBridge隐藏的链接而遇到类似的情况。
With partial RBridge deployment, the RBridges may partition a bridged LAN into a relatively small number of relatively large remnant bridged LANs, or possibly not partition it at all so a single bridged LAN remains. Such configuration can result in the following problem:
通过部分RBridge部署，RBridge可以将桥接LAN划分为相对较少数量的相对较大的残余桥接LAN，或者可能根本不对其进行划分，从而保留单个桥接LAN。这种配置可能导致以下问题：
The requirement that native frames enter and leave a link via the link's appointed forwarder for the VLAN of the frame can cause congestion or suboptimal routing. (Similar problems can occur within a bridged LAN due to the spanning tree algorithm.) The extent to which such a problem will occur is highly dependent on the network
本机帧通过链路的指定转发器进入和离开链路（用于帧的VLAN）的要求可能会导致拥塞或次优路由。（由于生成树算法，桥接LAN中可能会出现类似问题。）此类问题的发生程度高度依赖于网络
topology. For example, if a bridged LAN had a star-like structure with core bridges that connected only to other bridges and peripheral bridges that connected to end stations and are connected to core bridges, the replacement of all of the core bridges by RBridges without replacing the peripheral bridges would generally improve performance without inducing appointed forwarder congestion.
拓扑结构。例如，如果桥接LAN具有星形结构，其核心网桥仅连接到其他网桥，外围网桥连接到终端站并连接到核心网桥，用RBridges替换所有核心网桥而不替换外围网桥通常会提高性能，而不会导致指定的转发器拥塞。
Solutions to this problem are discussed below and a particular example explored in Appendix A.3.
下文讨论了该问题的解决方案，附录a.3中探讨了一个具体示例。
Inserting RBridges so that all the bridged portions of the LAN stay connected to each other and have multiple RBridge connections is generally the least efficient arrangement.
插入RBridge以使LAN的所有桥接部分保持相互连接并具有多个RBridge连接通常是效率最低的安排。
There are four techniques that may help if the problem above occurs and that can, to some extent, be used in combination:
如果出现上述问题，有四种技术可能会有所帮助，并且在某种程度上可以结合使用：
1. Replace more IEEE 802.1 customer bridges with RBridges so as to minimize the size of the remnant bridged LANs between RBridges. This requires no configuration of the RBridges unless the bridges they replace required configuration.
1. 用RBridges替换更多IEEE 802.1客户网桥，以最小化RBridges之间剩余桥接LAN的大小。这不需要配置RBridge，除非它们替换了所需的配置。
2. Re-arrange network topology to minimize the problem. If the bridges and RBridges involved are configured, this may require changes in their configuration.
2. 重新安排网络拓扑以最小化问题。如果配置了所涉及的网桥和RBridge，则可能需要更改其配置。
3. Configure the RBridges and bridges so that end stations on a remnant bridged LAN are separated into different VLANs that have different appointed forwarders. If the end stations were already assigned to different VLANs, this is straightforward (see Section 4.2.4.2). If the end stations were on the same VLAN and have to be split into different VLANs, this technique may lead to connectivity problems between end stations.
3. 配置RBridge和bridges，以便将剩余桥接LAN上的端站分离为具有不同指定转发器的不同VLAN。如果终端站已经分配给不同的VLAN，这是很简单的（参见第4.2.4.2节）。如果终端站位于同一VLAN上，并且必须拆分为不同的VLAN，则此技术可能会导致终端站之间的连接问题。
4. Configure the RBridges such that their ports that are connected to the bridged LAN send spanning tree configuration BPDUs (see Section A.3.3) in such a way as to force the partition of the bridged LAN. (Note: A spanning tree is never formed through an RBridge but always terminates at RBridge ports.) To use this technique, the RBridges must support this optional feature, and would need to be configured to use it, but the bridges involved would rarely have to be configured. This technique makes the bridged LAN unavailable for TRILL through traffic because the bridged LAN partitions.
4. 配置RBridge，使其连接到桥接LAN的端口发送生成树配置BPDU（参见第A.3.3节），从而强制对桥接LAN进行分区。（注意：生成树从不通过RBridge形成，而是始终在RBridge端口终止。）要使用此技术，RBridge必须支持此可选功能，并且需要配置才能使用它，但很少需要配置涉及的桥。这种技术使桥接LAN无法用于TRILL直通通信，因为桥接LAN是分区的。
Conversely to item 3 above, there may be bridged LANs that use VLANs, or use more VLANs than would otherwise be necessary, to support the Multiple Spanning Tree Protocol or otherwise reduce the congestion
与上述第3项相反，可能存在使用VLAN的桥接LAN，或使用比其他必要的VLAN更多的VLAN，以支持多生成树协议或以其他方式减少拥塞
that can be caused by a single spanning tree. Replacing the IEEE 802.1 bridges in such LANs with RBridges may enable a reduction in or elimination of VLANs and configuration complexity.
这可能是由单个生成树引起的。用RBridge替换此类LAN中的IEEE 802.1网桥可以减少或消除VLAN和配置复杂性。
If 802.1 bridges are present and RBridges are not properly configured, the bridge spanning tree or the DRB may make inappropriate decisions. Below is a specific example of the more general problem that can occur when a bridged LAN is connected to multiple RBridges.
如果存在802.1网桥且RBridge未正确配置，网桥生成树或DRB可能会做出不适当的决定。下面是桥接LAN连接到多个RBridge时可能出现的更一般问题的具体示例。
In cases where there are two (or more) groups of end nodes, each attached to a bridge (say, B1 and B2), and each bridge is attached to an RBridge (say, RB1 and RB2, respectively), with an additional link connecting B1 and B2 (see Figure 13), it may be desirable to have the B1-B2 link only as a backup in case one of RB1 or RB2 or one of the links B1-RB1 or B2-RB2 fails.
在有两个（或更多）组端节点的情况下，每个端节点连接到一个网桥（比如B1和B2），每个网桥连接到一个RBridge（比如分别为RB1和RB2），另外一个链路连接B1和B2（见图13），在RB1或RB2中的一个或链路B1-RB1或B2-RB2中的一个出现故障时，可能希望B1-B2链路仅作为备份。
+-------------------------------+
| | | |
| Data +-----+ +-----+ |
| Center -| RB1 |----| RB2 |- |
| +-----+ +-----+ |
| | | |
+-------------------------------+
| |
| |
+-------------------------------+
| | | |
| +----+ +----+ |
| Wiring | B1 |-----| B2 | |
| Closet +----+ +----+ |
| Bridged |
| LAN |
+-------------------------------+
+-------------------------------+
| | | |
| Data +-----+ +-----+ |
| Center -| RB1 |----| RB2 |- |
| +-----+ +-----+ |
| | | |
+-------------------------------+
| |
| |
+-------------------------------+
| | | |
| +----+ +----+ |
| Wiring | B1 |-----| B2 | |
| Closet +----+ +----+ |
| Bridged |
| LAN |
+-------------------------------+
Figure 13: Wiring Closet Topology
图13：配线柜拓扑
For example, B1 and B2 may be in a wiring closet and it may be easy to provide a short, high-bandwidth, low-cost link between them while RB1 and RB2 are at a distant data center such that the RB1-B1 and RB2-B2 links are slower and more expensive.
例如，B1和B2可能位于接线柜中，当RB1和RB2位于远程数据中心时，在它们之间提供短、高带宽、低成本的链路可能很容易，因此RB1-B1和RB2-B2链路较慢且更昂贵。
Default behavior might be that one of RB1 or RB2 (say, RB1) would become DRB for the bridged LAN including B1 and B2 and appoint itself forwarder for the VLANs on that bridged LAN. As a result, RB1 would forward all traffic to/from the link, so end nodes attached to B2
默认行为可能是RB1或RB2（比如RB1）中的一个将成为桥接LAN（包括B1和B2）的DRB，并为该桥接LAN上的VLAN指定自己的转发器。因此，RB1会将所有流量转发至/转发自链路，因此连接到B2的终端节点
would be connected to the campus via the path B2-B1-RB1, rather than the desired B2-RB2. This wastes the bandwidth of the B2-RB2 path and cuts available bandwidth between the end stations and the data center in half. The desired behavior would be to make use of both the RB1-B1 and RB2-B2 links.
将通过路径B2-B1-RB1而不是所需的B2-RB2连接到校园。这会浪费B2-RB2路径的带宽，并将终端站和数据中心之间的可用带宽减少一半。期望的行为是同时使用RB1-B1和RB2-B2链路。
Three solutions to this problem are described below.
下面介绍了此问题的三种解决方案。
Of course, if B1 and B2 are replaced with RBridges, the right thing will happen without configuration (other than VLAN support), but this may not be immediately practical if bridges are being incrementally replaced by RBridges.
当然，如果B1和B2被RBridges替换，那么在没有配置的情况下（除了VLAN支持之外）会发生正确的事情，但是如果网桥被RBridges增量替换，这可能不会立即实现。
If the end stations attached to B1 and B2 are already divided among a number of VLANs, RB1 and RB2 could be configured so that whichever becomes DRB for this link will appoint itself forwarder for some of these VLANs and appoint the other RBridge for the remaining VLANs. Should either of the RBridges fail or become disconnected, the other will have only itself to appoint as forwarder for all the VLANs.
如果连接到B1和B2的终端站已经在多个VLAN之间划分，则可以配置RB1和RB2，以便无论哪个成为此链路的DRB，都将为其中一些VLAN指定自己的转发器，并为其余VLAN指定另一个RBridge。如果其中一个RBridge发生故障或断开连接，则另一个RBridge只能指定自己作为所有VLAN的转发器。
If the end stations are all on a single VLAN, then it would be necessary to assign them between at least two VLANs to use this solution. This may lead to connectivity problems that might require further measures to rectify.
如果终端站都在一个VLAN上，则有必要在至少两个VLAN之间分配它们以使用此解决方案。这可能导致连接问题，可能需要采取进一步措施来纠正。
Another solution is to configure the relevant ports on RB1 and RB2 to be part of a "wiring closet group", with a configured per-RBridge port "Bridge Address" Bx (which may be RB1 or RB2's System ID). Both RB1 and RB2 emit spanning tree BPDUs on their configured ports as highest priority root Bx. This causes the spanning tree to logically partition the bridged LAN as desired by blocking the B1-B2 link at one end or the other (unless one of the bridges is configured to also have highest priority and has a lower ID, which we consider to be a misconfiguration). With the B1-B2 link blocked, RB1 and RB2 cannot see each other's TRILL-Hellos via that link and each acts as Designated RBridge and appointed forwarder for its respective partition. Of course, with this partition, no TRILL through traffic can flow through the RB1-B1-B2-RB2 path.
另一种解决方案是将RB1和RB2上的相关端口配置为“接线柜组”的一部分，并配置每个RBridge端口的“网桥地址”Bx（可能是RB1或RB2的系统ID）。RB1和RB2都在其配置的端口上以最高优先级根Bx的形式发出生成树BPDU。这使得生成树通过在一端或另一端阻塞B1-B2链路来逻辑地划分桥接LAN（除非其中一个桥被配置为具有最高优先级并且具有较低的ID，我们认为这是一个错误配置）。在B1-B2链路被阻断的情况下，RB1和RB2无法通过该链路看到彼此的颤音Hello，并且各自充当其各自分区的指定RBridge和指定转发器。当然，有了这个分区，没有任何TRILL-through流量可以通过RB1-B1-B2-RB2路径。
In the spanning tree configuration BPDU, the Root is "Bx" with highest priority, cost to Root is 0, Designated Bridge ID is "RB1" when RB1 transmits and "RB2" when RB2 transmits, and port ID is a
在生成树配置BPDU中，根为具有最高优先级的“Bx”，根的成本为0，指定的网桥ID在RB1传输时为“RB1”，在RB2传输时为“RB2”，端口ID为
value chosen independently by each of RB1 and RB2 to distinguish each of its own ports. The topology change flag is zero, and the topology change acknowledgement flag is set if and only if a topology change BPDU has been received on the port since the last configuration BPDU was transmitted on the port. (If RB1 and RB2 were actually bridges on the same shared medium with no bridges between them, the result would be that the one with the larger ID sees "better" BPDUs (because of the tiebreaker on the third field: the ID of the transmitting bridge), and would turn off its port.)
RB1和RB2各自独立选择的值，以区分各自的端口。拓扑更改标志为零，并且仅当且仅当自上次配置BPDU在端口上传输以来端口上已接收到拓扑更改BPDU时，才会设置拓扑更改确认标志。（如果RB1和RB2实际上是同一共享介质上的网桥，它们之间没有网桥，那么结果就是ID越大的网桥看到的BPDU越“好”（因为第三个字段上的分接器：传输网桥的ID），并且会关闭其端口。）
Should either RB1 or the RB1-B1 link or RB2 or the RB2-B2 link fail, the spanning tree algorithm will stop seeing one of the RBx roots and will unblock the B1-B2 link maintaining connectivity of all the end stations with the data center.
如果RB1或RB1-B1链路或RB2或RB2-B2链路出现故障，生成树算法将停止看到其中一个RBx根，并将解除阻止B1-B2链路，以保持所有终端站与数据中心的连接。
If the link RB1-B1-B2-RB2 is on the cut set of the campus and RB2 and RB1 have been configured to believe they are part of a wiring closet group, the campus becomes partitioned as the link is blocked.
如果链路RB1-B1-B2-RB2位于园区的切割集上，并且RB2和RB1已配置为相信它们是配线柜组的一部分，则园区将在链路阻塞时被分区。
Replacing all 802.1 customer bridges with RBridges is usually the best solution with the least amount of configuration required, possibly none.
用RBridges替换所有802.1客户网桥通常是最好的解决方案，所需配置量最少，甚至可能没有。
The VLAN solution works well with a relatively small amount of configuration if the end stations are already divided among a number of VLANs. If they are not, it becomes more complex and problematic.
如果终端站已在多个VLAN之间划分，则VLAN解决方案在配置量相对较小的情况下运行良好。如果他们不这样做，它就会变得更加复杂和问题重重。
The spanning tree solution does quite well in this particular case. But it depends on both RB1 and RB2 having implemented the optional feature of being able to configure a port to emit spanning tree BPDUs as described in Appendix A.3.3 above. It also makes the bridged LAN whose partition is being forced unavailable for through traffic. Finally, while in this specific example it neatly breaks the link between the two bridges B1 and B2, if there were a more complex bridged LAN, instead of exactly two bridges, there is no guarantee that it would partition into roughly equal pieces. In such a case, you might end up with a highly unbalanced load on the RB1-B1 link and the RB2-B2 link although this is still better than using only one of these links exclusively.
生成树解决方案在这种特殊情况下表现得非常好。但这取决于RB1和RB2都实现了可选功能，即能够配置端口以发出生成树BPDU，如上文附录a.3.3所述。它还使其分区被强制不可用于直通通信的桥接LAN。最后，虽然在这个具体的例子中，它巧妙地断开了两个网桥B1和B2之间的链接，但如果有一个更复杂的网桥LAN，而不是两个网桥，则不能保证它将被划分为大致相等的部分。在这种情况下，RB1-B1链路和RB2-B2链路上的负载可能会非常不平衡，尽管这仍然比只使用其中一个链路要好。
Many modern bridged LANs are organized into a core and access model, The core bridges have only point-to-point links to other bridges while the access bridges connect to end stations, core bridges, and possibly other access bridges. It seems likely that some RBridge campuses will be organized in a similar fashion.
许多现代桥接LAN被组织成一个核心和接入模型，核心网桥只有到其他网桥的点对点链路，而接入网桥连接到终端站、核心网桥，可能还有其他接入网桥。似乎有些RBridge校区也将以类似的方式组织起来。
An RBridge port can be configured as a trunk port, that is, a link to another RBridge or RBridges, by configuring it to disable end-station support. There is no reason for such a port to have more than one VLAN enabled and in its Announcing Set on the port. Of course, the RBridge (or RBridges) to which it is connected must have the same VLAN enabled. There is no reason for this VLAN to be other than the default VLAN 1 unless the link is actually over carrier Ethernet or other facilities that only provide some other specific VLAN or the like. Such configuration minimizes wasted TRILL-Hellos and eliminates useless decapsulation and transmission of multi-destination traffic in native form onto the link (see Sections 4.2.4 and 4.9.1).
通过将RBridge端口配置为禁用终端站支持，可以将其配置为中继端口，即到另一个RBridge或RBridge的链路。这样的端口没有理由启用多个VLAN，并且在端口上设置了多个VLAN。当然，它所连接的RBridge（或RBridge）必须启用相同的VLAN。该VLAN没有理由不是默认VLAN 1，除非链路实际上是通过运营商以太网或仅提供某些其他特定VLAN等的其他设施。这种配置最大限度地减少了浪费的颤音hello，并消除了无用的解除封装和将本地形式的多目的地流量传输到链路上（见第4.2.4节和第4.9.1节）。
An RBridge access port would be expected to lead to a link with end stations and possibly one or more bridges. Such a link might also have more than one RBridge connected to it to provide more reliable service to the end stations. It would be a goal to minimize or eliminate transit traffic on such a link as it is intended for end-station native traffic. This can be accomplished by turning on the access port configuration bit for the RBridge port or ports connected to the link as further detailed in Section 4.9.1.
预计RBridge接入端口将与终端站和可能的一个或多个网桥连接。这样的链路还可以有多个RBridge连接到它，以向终端站提供更可靠的服务。这将是一个目标，以尽量减少或消除这种链接上的过境交通，因为它是为终端站本地交通。这可以通过打开RBridge端口或连接到链路的端口的访问端口配置位来实现，详见第4.9.1节。
When designing RBridge configuration user interfaces, consideration should be given to making it convenient to configure ports as trunk and access ports.
在设计RBridge配置用户界面时，应考虑方便地将端口配置为中继端口和访问端口。
Rbridges support multipathing of both known unicast and multi-destination traffic. Implementation of multipathing is optional.
Rbridges支持已知单播和多目的流量的多路径传输。多路径的实现是可选的。
Multi-destination traffic can be multipathed by using different distribution tree roots for different frames. For example, assume that in Figure 14 end stations attached to RBy are the source of various multicast streams each of which has multiple listeners attached to various of RB1 through RB9. Assuming equal bandwidth links, a distribution tree rooted at RBy will predominantly use the vertical links among RB1 through RB9 while one rooted at RBz will predominantly use the horizontal. If RBy chooses its nickname as the distribution tree root for half of this traffic and an RBz nickname
通过对不同的帧使用不同的分布树根，可以对多目的地流量进行多路径处理。例如，假设在图14中，连接到RBy的终端站是各种多播流的源，每个多播流都有多个侦听器连接到各种RB1到RB9。假设带宽相等，以RBy为根的分发树将主要使用RB1到RB9之间的垂直链接，而以RBz为根的分发树将主要使用水平链接。如果RBy选择它的昵称作为这个流量的一半和一个RBz昵称的分布树根
as the root for the other half, it may be able to substantially increase the aggregate bandwidth by making use of both the vertical and horizontal links among RB1 through RB9.
作为另一半的根，它可能能够通过利用RB1到RB9之间的垂直和水平链路来大幅增加聚合带宽。
Since the distribution trees an RBridge must calculate are the same for all RBridges and transit RBridges MUST respect the tree root specified by the ingress RBridge, a campus will operate correctly with a mix of RBridges some of which use different roots for different multi-destination frames they ingress and some of which use a single root for all such frames.
由于RBridge必须计算的分布树与所有RBridge的分布树相同，且运输RBridge必须遵守入口RBridge指定的树根，校园将通过混合使用RBridge正确运行，其中一些RBridge对其进入的不同多目标帧使用不同的根，而一些RBridge对所有此类帧使用单个根。
+---+
|RBy|---------------+
+---+ |
/ | \ |
/ | \ |
/ | \ |
+---+ +---+ +---+ |
|RB1|---|RB2|---|RB3| |
+---+ +---+ +---+\ |
| | | \ |
+---+ +---+ +---+ \+---+
|RB4|---|RB5|---|RB6|-----|RBz|
+---+ +---+ +---+ /+---+
| | | /
+---+ +---+ +---+/
|RB7|---|RB8|---|RB9|
+---+ +---+ +---+
+---+
|RBy|---------------+
+---+ |
/ | \ |
/ | \ |
/ | \ |
+---+ +---+ +---+ |
|RB1|---|RB2|---|RB3| |
+---+ +---+ +---+\ |
| | | \ |
+---+ +---+ +---+ \+---+
|RB4|---|RB5|---|RB6|-----|RBz|
+---+ +---+ +---+ /+---+
| | | /
+---+ +---+ +---+/
|RB7|---|RB8|---|RB9|
+---+ +---+ +---+
Figure 14: Multi-Destination Multipath
图14：多目标多路径
Known unicast Equal Cost Multipathing (ECMP) can occur at an RBridge if, instead of using a tiebreaker criterion when building SPF paths, information is retained about ports through which equal cost paths are available. Different unicast frames can then be sent through those different ports and will be forwarded by equal cost paths. For example, in Figure 15, which shows only RBridges and omits any bridges present, there are three equal cost paths between RB1 and RB2 and two equal cost paths between RB2 and RB5. Thus, for traffic transiting this part of the campus from left to right, RB1 may be able to perform three way ECMP and RB2 may be able to perform two-way ECMP.
已知的单播等成本多路径（ECMP）可能发生在RBridge，如果在构建SPF路径时不使用断开连接的标准，而是保留关于可通过其获得等成本路径的端口的信息。然后，可以通过这些不同的端口发送不同的单播帧，并通过相同成本的路径转发。例如，在图15中，只显示了RBridges，省略了存在的任何桥接，在RB1和RB2之间有三条等成本路径，在RB2和RB5之间有两条等成本路径。因此，对于从左向右通过校园这一部分的流量，RB1可能能够执行三路ECMP，RB2可能能够执行双向ECMP。
A transit RBridge receiving a known unicast frame forwards it towards the egress RBridge and is not concerned with whether it believes itself to be on any particular path from the ingress RBridge or a
接收到已知单播帧的传输RBridge将其转发到出口RBridge，并且不关心它是否认为自己位于来自入口RBridge或出口RBridge的任何特定路径上
previous transit RBridge. Thus, a campus will operate correctly with a mix of RBridges some of which implement ECMP and some of which do not.
上一次过境是在布里奇。因此，校园将正确运行，混合使用RBM，其中一些实现ECMP，而另一些不实现ECMP。
There are actually three possibilities for the parallel paths between RB1 and RB2 as follows:
RB1和RB2之间的并行路径实际上有三种可能，如下所示：
1. If two or three of these paths have pseudonodes, then all three will be distinctly visible in the campus-wide link state and ECMP as described above is applicable.
1. 如果这些路径中有两个或三个具有伪节点，那么所有三个都将在校园范围的链路状态中清晰可见，并且如上所述的ECMP是适用的。
2. If the paths use P2P Hellos or otherwise do not have pseudonodes, these three paths would appear as a single adjacency in the link state. In this case, multipathing across them would be an entirely local matter for RB1 and RB2. It can be freely done for known unicast frames but not for multi-destination frames as described in Section 4.5.2.
2. 如果路径使用P2P Hellos或没有伪节点，则这三条路径将在链接状态中显示为单个邻接。在这种情况下，它们之间的多路径传输对于RB1和RB2来说完全是局部问题。如第4.5.2节所述，它可以自由地用于已知单播帧，但不能用于多目的帧。
3. If and only if the three paths between RB1 and RB2 are single hop equal bandwidth links with no intervening bridges, then it would be permissible to combine them into one logical link through the [802.1AX] "link aggregation" feature. Rbridges MAY implement link aggregation since that feature operates below TRILL (see Section 4.9.2).
3. 如果且仅当RB1和RB2之间的三条路径是没有中间网桥的单跳等带宽链路，则允许通过[802.1AX]“链路聚合”功能将它们组合成一条逻辑链路。Rbridges可以实现链路聚合，因为该功能在颤音以下运行（见第4.9.2节）。
+---+ double line = 10 Gbps
----- ===|RB3|--- single line = 1 Gbps
/ \ // +---+ \
+---+ +---+ +---+
===|RB1|-----|RB2| |RB5|===
+---+ +---+ +---+
\ / \ +---+ //
----- ----|RB4|===
+---+
+---+ double line = 10 Gbps
----- ===|RB3|--- single line = 1 Gbps
/ \ // +---+ \
+---+ +---+ +---+
===|RB1|-----|RB2| |RB5|===
+---+ +---+ +---+
\ / \ +---+ //
----- ----|RB4|===
+---+
Figure 15: Known Unicast Multipath
图15：已知单播多路径
When multipathing is used, frames that follow different paths will be subject to different delays and may be re-ordered. While some traffic may be order/delay insensitive, typically most traffic consists of flows of frames where re-ordering within a flow is damaging. How to determine flows or what granularity flows should have is beyond the scope of this document. (This issue is discussed in [802.1AX].)
当使用多路径时，遵循不同路径的帧将受到不同的延迟，并且可能被重新排序。虽然一些流量可能对顺序/延迟不敏感，但通常大多数流量由帧流组成，其中流中的重新排序会造成损害。如何确定流或流应该具有什么粒度超出了本文档的范围。（此问题在[802.1AX]中讨论。）
A high-level, informative summary of how VLAN ID and priority are determined for incoming native frames, omitting some details, is given in the bulleted items below. For more detailed information, see [802.1Q-2005].
下面的项目符号中给出了关于如何为传入的本机帧确定VLAN ID和优先级的高级信息摘要，省略了一些细节。有关更多详细信息，请参见[802.1Q-2005]。
o When an untagged native frame arrives, an unconfigured RBridge associates the default priority zero and the VLAN ID 1 with it. It actually sets the VLAN for the untagged frame to be the "port VLAN ID" associated with that port. The port VLAN ID defaults to VLAN ID 1 but may be configured to be any other VLAN ID. An Rbridge may also be configured on a per-port basis to discard such frames or to associate a different priority code point with them. Determination of the VLAN ID associated with an incoming untagged non-control frame may also be made dependent on the Ethertype or NSAP (referred to in 802.1 as the Protocol) of the arriving frame, the source MAC address, or other local rules.
o 当未标记的本机帧到达时，未配置的RBridge将默认优先级0和VLAN ID 1与其关联。它实际上将未标记帧的VLAN设置为与该端口关联的“端口VLAN ID”。端口VLAN ID默认为VLAN ID 1，但可以配置为任何其他VLAN ID。还可以基于每个端口配置Rbridge，以丢弃这些帧或将不同的优先级代码点与它们关联。还可以根据到达帧的Ethertype或NSAP（在802.1中称为协议）、源MAC地址或其他本地规则来确定与传入的未标记非控制帧相关联的VLAN ID。
o When a priority tagged native frame arrives, an unconfigured RBridge associates with it both the port VLAN ID, which defaults to 1, and the priority code point provided in the priority tag in the frame. An Rbridge may be configured on a per-port basis to discard such frames or to associate them with a different VLAN ID as described in the point immediately above. It may also be configured to map the priority code point provided in the frame by specifying, for each of the eight possible values that might be in the frame, what actual priority code point will be associated with the frame by the RBridge.
o 当带有优先级标记的本机帧到达时，未配置的RBridge将端口VLAN ID（默认为1）和帧中优先级标记中提供的优先级代码点都与之关联。Rbridge可以基于每个端口进行配置，以丢弃这样的帧或将它们与不同的VLAN ID相关联，如上文所述。它还可以被配置为通过为帧中可能存在的八个可能值中的每一个指定RBridge将与帧相关联的实际优先级代码点来映射帧中提供的优先级代码点。
o When a C-tagged (formerly called Q-tagged) native frame arrives, an unconfigured RBridge associates with it the VLAN ID and priority in the C-tag. An RBridge may be configured on a per-port per-VLAN basis to discard such frames. It may also be configured on a per-port basis to map the priority value as specified above for priority tagged frames.
o 当C标记（以前称为Q标记）本机帧到达时，未配置的RBridge会将C标记中的VLAN ID和优先级与之关联。RBridge可以基于每个VLAN的每个端口配置，以丢弃这样的帧。还可以基于每个端口配置它，以映射上面为优先级标记帧指定的优先级值。
In 802.1, the process of associating a priority code point with a frame, including mapping a priority provided in the frame to another priority, is referred to as priority "regeneration".
在802.1中，将优先级码点与帧相关联的过程（包括将帧中提供的优先级映射到另一优先级）称为优先级“再生”。
This informational appendix briefly comments on RBridge support for completed and in-process amendments to IEEE [802.1Q-2005]. There is no assurance that existing RBridge protocol specifications or existing bridges will support not yet specified future [802.1Q-2005] amendments just as there is no assurance that existing bridge
本信息性附录简要评述了RBridge对IEEE[802.1Q-2005]已完成和正在进行的修订的支持。无法保证现有RBridge协议规范或现有网桥将支持尚未指定的未来[802.1Q-2005]修订，正如无法保证现有网桥
protocol specifications or existing RBridges will support not yet specified future TRILL amendments.
协议规范或现有RBridges将支持尚未指定的未来TRILL修订。
The information below is frozen as of 25 October 2009. For the latest status, see the IEEE 802.1 working group (http://grouper.ieee.org/groups/802/1/).
以下信息截至2009年10月25日已冻结。有关最新状态，请参阅IEEE 802.1工作组(http://grouper.ieee.org/groups/802/1/).
802.1ad-2005 Provider Bridges - Sometimes called "Q-in-Q", because VLAN tags used to be called "Q-tags", 802.1ad specifies Provider Bridges that tunnel customer bridge traffic within service VLAN tags (S-tags). If the customer LAN is an RBridge campus, that traffic will be bridged by Provider Bridges. Customer bridge features involving Provider Bridge awareness, such as the ability to configure a customer bridge port to add an S-tag to a frame before sending it to a Provider Bridge, are below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1ad-2005提供商网桥-有时称为“Q-in-Q”，因为VLAN标记过去被称为“Q-tags”，802.1ad指定了在服务VLAN标记（S-tags）内隧道客户网桥流量的提供商网桥。如果客户LAN是RBridge园区，则该流量将由提供商网桥桥接。涉及提供商网桥感知的客户网桥功能，如配置客户网桥端口以在将其发送到提供商网桥之前将S标记添加到帧的能力，位于EIS层之下，并且可以在RBridge端口中得到支持，而无需修改TRILL协议。
802.1ag-2007 Connectivity Fault Management (CFM) - This 802.1 feature is at least in part dependent on the symmetric path and other characteristics of spanning tree. The comments provided to the IETF TRILL working group by the IEEE 802.1 working group stated that "TRILL weakens the applicability of CFM".
802.1ag-2007连接故障管理（CFM）-此802.1功能至少部分依赖于对称路径和生成树的其他特征。IEEE 802.1工作组向IETF TRILL工作组提供的意见指出，“TRILL削弱了CFM的适用性”。
802.1ak-2007 Multiple Registration Protocol - Supported to the extent described in Section 4.9.4.
802.1ak-2007多重注册协议-支持第4.9.4节所述的范围。
802.1ah-2008 Provider Backbone Bridges - Sometimes called "MAC-in-MAC", 802.1ah provides for Provider Backbone Bridges that tunnel customer bridge traffic within different outer MAC addresses and using a tag (the "I-tag") to preserve the original MAC addresses and signal other information. If the customer LAN is an RBridge campus, that traffic will be bridged by Provider Backbone Bridges. Customer bridge features involving Provider Backbone Bridge awareness, such as the ability to configure a customer bridge port to add an I-tag to a frame before sending it to a Provider Backbone Bridge, are below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1ah-2008提供商主干网桥-有时称为“MAC中的MAC”，802.1ah为提供商主干网桥提供了通道，在不同的外部MAC地址内传输客户网桥流量，并使用标签（“I标签”）保留原始MAC地址和发信号通知其他信息。如果客户LAN是RBridge园区，则该流量将由提供商主干网桥桥接。涉及提供商主干网桥感知的客户网桥功能，如配置客户网桥端口以在将帧发送到提供商主干网桥之前将I-tag添加到帧的能力，位于EISS层之下，并且可以在RBridge端口中得到支持，而无需修改TRILL协议。
802.1Qaw-2009 Management of Data-Driven and Data-Dependent Connectivity Fault - Amendment building on 802.1ag. See comments on 802.1ag-2007 above.
802.1Qaw-2009数据驱动和数据相关连接故障的管理-基于802.1ag的修订版。见上文对802.1ag-2007的评论。
802.1Qay-2009 Provider Backbone Bridge Traffic Engineering - Amendment building on 802.1ah to configure traffic engineered routing. See comments on 802.1ah-2008 above.
802.1Qay-2009提供商主干网桥流量工程-修改802.1ah上的构建，以配置流量工程路由。见上文关于802.1ah-2008的评论。
The following are amendments to IEEE [802.1Q-2005] that are in process. As such, the brief comments below are based on drafts and may be incorrect for later versions or any final amendment.
以下是IEEE[802.1Q-2005]正在进行的修订。因此，以下简要评论基于草稿，可能不适用于后续版本或任何最终修订。
802.1aj Two-port MAC Relay [802.1aj] - This amendment specifies a MAC relay that will be transparent to RBridges. RBridges are compatible with IEEE 802.1aj devices as currently specified, in the same sense that IEEE 802.1Q-2005 bridges are compatible with such devices.
802.1aj双端口MAC中继[802.1aj]-本修正案规定了对RBRINGS透明的MAC中继。RBridges与当前指定的IEEE 802.1aj设备兼容，与IEEE 802.1Q-2005网桥与此类设备兼容的意义相同。
802.1aq Shortest Path Bridging - This amendment provides for improved routing in bridged LANs.
802.1aq最短路径桥接-此修正案提供了桥接LAN中的改进路由。
802.1Qat Stream Reservation Protocol - Modification to 802.1Q to support the 802.1 Timing and Synchronization. This protocol reserves resources for streams at supporting bridges.
802.1Qat流保留协议-修改802.1Q以支持802.1定时和同步。此协议在支持网桥处为流保留资源。
802.1Qau Congestion Notification - It currently appears that modifications to RBridge behavior above the EISS level would be needed to support this amendment. Such modifications are beyond the scope of this document.
802.1Qau拥塞通知-目前看来，需要在EIS级别以上对RBridge行为进行修改，以支持此修订。此类修改超出了本文件的范围。
802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive Streams - Modification to 802.1Q to support the 802.1 Timing and Synchronization protocol. This amendment specifies methods to support the resource reservations made through the 802.1Qat protocol (see above).
时间敏感流的802.1Qav转发和排队增强功能-修改802.1Q以支持802.1定时和同步协议。本修正案规定了支持通过802.1Qat协议进行资源预留的方法（见上文）。
802.1Qaz Enhanced Transmission Selection - It appears that this amendment will be below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1Qaz增强传输选择-似乎此修订将位于EIS层之下，并且可以在RBridge端口中支持，而无需修改TRILL协议。
802.1Qbb Priority-based Flow Control - Commonly called "per-priority pause", it appears that this amendment will be below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1Qbb基于优先级的流量控制-通常称为“每优先级暂停”，似乎此修改将位于EIS层之下，并且可以在RBridge端口中支持，而无需修改TRILL协议。
802.1bc Remote Customer Service Interfaces. This is an extension to 802.1Q provider bridging. See 802.1ad-2005 above.
802.1bc远程客户服务接口。这是对802.1Q提供商桥接的扩展。见上文802.1ad-2005。
802.1Qbe Multiple Backbone Service Instance Identifier (I-SID) Registration Protocol (MIRP). This is an extension to 802.1Q provider backbone bridging. See 802.1ah-2008 above.
802.1Qbe多骨干网服务实例标识符（I-SID）注册协议（MIRP）。这是对802.1Q提供商主干桥接的扩展。见上文802.1ah-2008。
802.1Qbf Provider Backbone Bridge Traffic Engineering (PBB-TE) Infrastructure Segment Protection. This amendment extends 802.1Q to support certain types of failover between provider backbone bridges. See 802.1ah-2008 above.
802.1Qbf提供商主干网桥流量工程（PBB-TE）基础设施段保护。此修正案扩展了802.1Q，以支持提供商主干网桥之间的某些类型的故障切换。见上文802.1ah-2008。
Many people have contributed to this design, including the following, in alphabetic order:
许多人对此设计做出了贡献，包括以下按字母顺序排列的人：
Bernard Aboba, Alia Atlas, Ayan Banerjee, Caitlin Bestler, Suresh Boddapati, David Michael Bond, Stewart Bryant, Ross Callon, James Carlson, Pasi Eronen, Dino Farinacci, Adrian Farrell, Don Fedyk, Bill Fenner, Eric Gray, Sujay Gupta, Joel Halpern, Andrew Lange, Acee Lindem, Vishwas Manral, Peter McCann, Israel Meilik, David Melman, Nandakumar Natarajan, Erik Nordmark, Jeff Pickering, Tim Polk, Dan Romascanu, Sanjay Sane, Pekka Savola, Matthew R. Thomas, Joe Touch, Mark Townsley, Kate Zebrose.
伯纳德·阿博巴、艾莉亚·阿特拉斯、阿扬·班纳吉、凯特琳·贝斯勒、苏雷什·博达帕蒂、大卫·迈克尔·邦德、斯图尔特·布莱恩特、罗斯·卡隆、詹姆斯·卡尔森、帕西·艾隆、迪诺·法里纳奇、阿德里安·法雷尔、唐·费迪克、比尔·芬纳、埃里克·格雷、苏杰·古普塔、乔尔·哈尔潘、安德鲁·兰格、亚齐·林登、维斯瓦斯·曼拉尔、彼得·麦肯、以色列·梅利克、大卫·梅尔曼、，Nandakumar Natarajan、Erik Nordmark、Jeff Pickering、Tim Polk、Dan Romascanu、Sanjay Sane、Pekka Savola、Matthew R.Thomas、Joe Touch、Mark Townsley、Kate Zebrose。
Authors' Addresses
作者地址
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
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
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
Silvano Gai Cisco Systems 170 Tasman Drive San Jose, CA 95134-1706 USA
Silvano Gai Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道170号，邮编95134-1706
EMail: silvano@ip6.com
EMail: silvano@ip6.com
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