Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8139 Y. Li
Obsoletes: 6439 Huawei
Updates: 6325, 7177 M. Umair
Category: Standards Track IP Infusion
ISSN: 2070-1721 A. Banerjee
Cisco
F. Hu
ZTE
June 2017
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8139 Y. Li
Obsoletes: 6439 Huawei
Updates: 6325, 7177 M. Umair
Category: Standards Track IP Infusion
ISSN: 2070-1721 A. Banerjee
Cisco
F. Hu
ZTE
June 2017
Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders
大量链接的透明互连（TRILL）：指定的转发商
Abstract
摘要
TRILL (Transparent Interconnection of Lots of Links) supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439.
TRILL（大量链路的透明互连）支持多址LAN（局域网）链路，其中单个链路可以连接多个终端站和TRILL交换机。当多个TRILL交换机连接到一条链路时，该链路上与终端站之间的本机流量由RFC 6325中最初指定的称为“指定转发器”的TRILL交换机子集处理，目的是每个VLAN中的本机流量最多由一个TRILL交换机处理。本文件澄清并更新了指定的货运代理机制。它更新了RFC 6325和7177，淘汰了RFC 6439。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8139.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8139.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Appointed Forwarders and Active-Active .....................5
1.2. Terminology and Abbreviations ..............................6
2. Appointed Forwarders and Their Appointment ......................7
2.1. The Appointment Databases and DRB Actions ..................8
2.2. Appointment Effects of DRB Elections ......................10
2.2.1. Processing Forwarder Appointments in Hellos ........11
2.2.2. Frequency of Hello Appointments ....................13
2.2.3. Appointed Forwarders Hello Limit ...................13
2.3. Effects of Local Configuration Actions on Appointments ....14
2.4. Overload and Appointed Forwarders .........................14
2.5. VLAN Mapping within a Link ................................15
3. The Inhibition Mechanism .......................................15
3.1. Inhibited Appointed Forwarder Behavior ....................18
3.2. Root Bridge Change Inhibition Optimizations ...............18
3.2.1. Optimization for Change to Lower Priority ..........19
3.2.2. Optimization for Change to Priority Only ...........19
3.2.3. Optimizing the Detection of Completed Settling .....19
4. Optional TRILL Hello Reduction .................................20
5. Multiple Ports on the Same Link ................................22
6. Port-Shutdown Messages .........................................23
6.1. Planned Shutdown and Hellos ...............................23
6.2. Port-Shutdown Message Structure ...........................23
6.3. Port-Shutdown Message Transmission ........................24
6.4. Port-Shutdown Message Reception ...........................25
6.5. Port-Shutdown Message Security ............................25
6.6. Port-Shutdown Configuration ...............................26
7. FGL-VLAN Mapping Consistency Checking ..........................26
8. Support of E-L1CS ..............................................27
8.1. Backward Compatibility ....................................27
9. Security Considerations ........................................28
10. Code Points and Data Structures ...............................28
10.1. IANA Considerations ......................................28
10.2. AppointmentBitmap APPsub-TLV .............................29
10.3. AppointmentList APPsub-TLV ...............................30
10.4. FGL-VLAN-Bitmap APPsub-TLV ...............................31
10.5. FGL-VLAN-Pairs APPsub-TLV ................................32
11. Management Considerations .....................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................36
Appendix A. VLAN Inhibition Example ...............................37
Appendix B. Multi-Link VLAN Mapping Loop Example ..................38
Appendix C. Changes to RFCs 6325, 6439, and 7177 ..................39
Acknowledgments ...................................................40
Authors' Addresses ................................................41
1. Introduction ....................................................4
1.1. Appointed Forwarders and Active-Active .....................5
1.2. Terminology and Abbreviations ..............................6
2. Appointed Forwarders and Their Appointment ......................7
2.1. The Appointment Databases and DRB Actions ..................8
2.2. Appointment Effects of DRB Elections ......................10
2.2.1. Processing Forwarder Appointments in Hellos ........11
2.2.2. Frequency of Hello Appointments ....................13
2.2.3. Appointed Forwarders Hello Limit ...................13
2.3. Effects of Local Configuration Actions on Appointments ....14
2.4. Overload and Appointed Forwarders .........................14
2.5. VLAN Mapping within a Link ................................15
3. The Inhibition Mechanism .......................................15
3.1. Inhibited Appointed Forwarder Behavior ....................18
3.2. Root Bridge Change Inhibition Optimizations ...............18
3.2.1. Optimization for Change to Lower Priority ..........19
3.2.2. Optimization for Change to Priority Only ...........19
3.2.3. Optimizing the Detection of Completed Settling .....19
4. Optional TRILL Hello Reduction .................................20
5. Multiple Ports on the Same Link ................................22
6. Port-Shutdown Messages .........................................23
6.1. Planned Shutdown and Hellos ...............................23
6.2. Port-Shutdown Message Structure ...........................23
6.3. Port-Shutdown Message Transmission ........................24
6.4. Port-Shutdown Message Reception ...........................25
6.5. Port-Shutdown Message Security ............................25
6.6. Port-Shutdown Configuration ...............................26
7. FGL-VLAN Mapping Consistency Checking ..........................26
8. Support of E-L1CS ..............................................27
8.1. Backward Compatibility ....................................27
9. Security Considerations ........................................28
10. Code Points and Data Structures ...............................28
10.1. IANA Considerations ......................................28
10.2. AppointmentBitmap APPsub-TLV .............................29
10.3. AppointmentList APPsub-TLV ...............................30
10.4. FGL-VLAN-Bitmap APPsub-TLV ...............................31
10.5. FGL-VLAN-Pairs APPsub-TLV ................................32
11. Management Considerations .....................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................36
Appendix A. VLAN Inhibition Example ...............................37
Appendix B. Multi-Link VLAN Mapping Loop Example ..................38
Appendix C. Changes to RFCs 6325, 6439, and 7177 ..................39
Acknowledgments ...................................................40
Authors' Addresses ................................................41
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7780] provides optimal pairwise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes these by using IS-IS (Intermediate System to Intermediate System) [IS-IS] [RFC7176] link-state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs, FGLs (Fine-Grained Labels) [RFC7172], and optimization of the distribution of multi-destination frames based on VLANs and multicast groups. Devices that implement TRILL are called TRILL switches or "RBridges" (Routing Bridges).
IETF TRILL（大量链路的透明互连）协议[RFC6325][RFC7780]在具有任意拓扑和链路技术的多跳网络中提供最佳成对数据帧转发，即使在临时环路期间也能安全转发，以及对单播和多播流量的多路径支持。TRILL通过使用IS-IS（中间系统到中间系统）[IS-IS][RFC7176]链路状态路由和使用包含跃点计数的报头封装流量来实现这些。该设计支持VLAN、FGLs（细粒度标签）[RFC7172]，以及基于VLAN和多播组的多目标帧分布优化。实现TRILL的设备称为TRILL交换机或“RBridges”（路由桥）。
Section 2 of [RFC7177] discusses the environment for which the TRILL protocol is designed and the differences between that environment and the typical Layer 3 routing environment.
[RFC7177]第2节讨论了TRILL协议的设计环境以及该环境与典型的第3层路由环境之间的差异。
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those switches called "Appointed Forwarders" as originally specified in [RFC6325], with the intent that native traffic in each VLAN be handled by at most one switch. A TRILL switch can be Appointed Forwarder for many VLANs.
TRILL支持可连接多个终端站和TRILL交换机的多址LAN（局域网）链路。当多个TRILL交换机连接到一条链路时，该链路上与终端站之间的本机流量由[RFC6325]中最初指定的称为“指定转发器”的交换机子集处理，目的是每个VLAN中的本机流量最多由一个交换机处理。TRILL交换机可以被指定为许多VLAN的转发器。
The purpose of this document is to update and improve the Appointed Forwarder mechanism and free it from the limitations imposed by the requirement in its initial design that all appointments fit within a TRILL Hello Protocol Data Unit (PDU). This is accomplished by requiring support of link-scoped FS-LSPs (Flooding Scope Link State PDUs) (Section 8) and providing the option to send appointment information in those LSPs. In addition, this document provides a number of other optional features to
本文件的目的是更新和改进指定的转发器机制，使其不受初始设计中要求的限制，即所有指定都应符合TRILL Hello协议数据单元（PDU）的要求。这是通过要求支持链路作用域FS LSP（泛洪作用域链路状态PDU）（第8节）并提供在这些LSP中发送约会信息的选项来实现的。此外，本文档还提供了许多其他可选功能
1. detect inconsistent VLAN-ID-to-FGL [RFC7172] mappings among the TRILL switch ports on a link, as discussed in Section 7,
1. 检测链路上TRILL交换机端口之间不一致的VLAN ID到FGL[RFC7172]映射，如第7节所述，
2. expedite notification of ports going down so that Appointed Forwarders can be adjusted, as discussed in Section 6, and
2. 如第6节所述，加快港口关闭通知，以便调整指定的货运代理；以及
3. reduce or eliminate the need for "inhibition" of ports for loop safety, as discussed in Section 3.2.
3. 如第3.2节所述，减少或消除对回路安全端口“抑制”的需要。
This document replaces and obsoletes [RFC6439], incorporating the former material in [RFC6439] with these additions. The various optimizations are orthogonal and optional. Implementers can choose to provide all, some, or none of them, and TRILL switches will still be interoperable. In accordance with the TRILL design philosophy, these optimizations require zero or minimal configuration, but there are a couple of configurable parameters, as summarized in Section 11.
本文件取代并废弃[RFC6439]，将[RFC6439]中的原材料与这些补充内容合并。各种优化是正交的和可选的。实现者可以选择提供全部、部分或全部，TRILL交换机仍然可以互操作。根据TRILL设计理念，这些优化需要零配置或最小配置，但有几个可配置参数，如第11节所总结。
As described in Appendix C, this document updates [RFC6325] by mandating support of E-L1CS FS-LSPs and provides backward compatibility in the presence of legacy TRILL switches that do not provide this support. It also updates [RFC7177] by providing, as an optional optimization, that receipt of the Port-Shutdown message specified herein be treated as an event in the state machine specified in [RFC7177].
如附录C所述，本文件通过强制支持E-L1CS FS LSP来更新[RFC6325]，并在存在不提供此支持的传统TRILL交换机时提供向后兼容性。它还更新了[RFC7177]，作为可选的优化，它将此处指定的端口关闭消息的接收视为[RFC7177]中指定的状态机中的事件。
This document includes reference implementation details. Alternative implementations that interoperate on the wire are permitted.
本文件包括参考实施细节。允许在线路上进行互操作的替代实现。
The Appointed Forwarder mechanism is irrelevant to any link on which end-station service is not offered. This includes links configured as point-to-point IS-IS links and any link with all TRILL switch ports on that link configured as trunk ports. (In TRILL, configuration of a port as a "trunk port" just means that no end-station service will be provided. It does not imply that all VLANs are enabled on that port.)
指定的转发器机制与未提供终端站服务的任何链路无关。这包括配置为点对点IS-IS链路的链路以及该链路上所有TRILL交换机端口配置为中继端口的任何链路。（在TRILL中，将端口配置为“中继端口”只意味着不提供终端站服务。这并不意味着在该端口上启用了所有VLAN。）
The Appointed Forwarder mechanism has no effect on the formation of adjacencies, the election of the Designated RBridge (DRB) [RFC7177] for a link, MTU matching, or pseudonode formation. Those topics are covered in [RFC7177]. Furthermore, Appointed Forwarder status has no effect on the forwarding of TRILL Data frames; it only affects the handling of native frames to and from end stations.
指定的转发器机制对邻接的形成、链路的指定RBridge（DRB）[RFC7177]的选择、MTU匹配或伪节点的形成没有影响。[RFC7177]中介绍了这些主题。此外，指定的转发器状态对TRILL数据帧的转发没有影响；它只影响本机帧与端站之间的处理。
For other aspects of the TRILL base protocol, see [RFC6325], [RFC7177], and [RFC7780]. In cases of conflict between this document and [RFC6325] or [RFC7177], this document prevails.
有关TRILL基本协议的其他方面，请参见[RFC6325]、[RFC7177]和[RFC7780]。如果本文件与[RFC6325]或[RFC7177]之间存在冲突，则以本文件为准。
As discussed in [RFC7379], TRILL active-active provides support for end stations connected to multiple edge TRILL switches where these connections are separate links. Since TRILL Hellos are not forwarded between these links, the Appointed Forwarder mechanism as described herein operates separately on each such link.
如[RFC7379]所述，TRILL active为连接到多个边缘TRILL交换机的终端站提供支持，这些交换机的连接是独立的链路。由于TRILL Hello不在这些链路之间转发，因此本文所述的指定转发器机制在每个这样的链路上单独操作。
This document uses the abbreviations and terms defined in [RFC6325], some of which are repeated below for convenience, and additional abbreviations and terms listed below.
本文件使用[RFC6325]中定义的缩略语和术语，其中一些缩略语和术语为方便起见在下面重复，其他缩略语和术语在下面列出。
Data Label mapping: The mapping from VLAN ID to FGL and from FGL to VLAN ID.
数据标签映射：从VLAN ID到FGL以及从FGL到VLAN ID的映射。
DRB: Designated RBridge. The RBridge on a link elected as specified in [RFC7177] to handle certain decisions and tasks for that link, including forwarder appointment as specified herein.
DRB：指定为RBridge。按照[RFC7177]中的规定选择链路上的RBridge，以处理该链路的某些决策和任务，包括本文中规定的转发器任命。
E-L1CS: Extended Level 1 Circuit Scope (Section 8).
E-L1CS：扩展1级电路范围（第8节）。
FGL: Fine-Grained Label [RFC7172].
FGL：细粒度标签[RFC7172]。
FS-LSP: Flooding Scope Link State PDU (Section 8).
FS-LSP：泛洪作用域链路状态PDU（第8节）。
Link: The means by which adjacent TRILL switches are connected. A TRILL link may be various technologies and, in the common case of Ethernet, can be a "bridged LAN" -- that is to say, some combination of Ethernet links with zero or more bridges, hubs, repeaters, or the like.
连接：连接相邻颤音开关的方式。TRILL链路可以是各种技术，并且在以太网的常见情况下，可以是“桥接LAN”——也就是说，具有零个或多个网桥、集线器、中继器等的以太网链路的某种组合。
LSDB: Link State Database.
链接状态数据库。
PDU: Protocol Data Unit.
协议数据单元。
RBridge: An alternative name for a TRILL switch.
RBridge：颤音开关的另一个名称。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
TRILL：大量链路的透明互连或链路层中的隧道路由。
TRILL switch: A device implementing the TRILL protocol. An alternative name for an RBridge.
颤音开关：实现颤音协议的设备。RBridge的替代名称。
Trunk port: A TRILL switch port configured with the "end-station service disable" bit on, as described in Section 4.9.1 of [RFC6325].
中继端口：如[RFC6325]第4.9.1节所述，配置有“终端站服务禁用”位的TRILL交换机端口。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The Appointed Forwarder on a link for VLAN-x is the TRILL switch (RBridge) that ingresses native frames from the link and egresses native frames to the link in VLAN-x. By default, the DRB (Designated RBridge) on a link is in charge of native traffic for all VLANs on the link. The DRB may, if it wishes, act as Appointed Forwarder for any VLAN, and it may appoint other TRILL switches that have ports on the link as Appointed Forwarder for one or more VLANs.
VLAN-x链路上指定的转发器是TRILL交换机（RBridge），该交换机从链路进入本机帧，并将本机帧输出到VLAN-x中的链路。默认情况下，链路上的DRB（指定为RBridge）负责链路上所有VLAN的本机流量。如果DRB愿意，它可以作为任何VLAN的指定转发器，并且可以指定在链路上具有端口的其他TRILL交换机作为一个或多个VLAN的指定转发器。
By definition, the DRB considers the other ports on the link to be the ports with which a DRB port has adjacency on that link [RFC7177]. If the DRB loses adjacency to a TRILL switch that it has appointed as forwarder and the native traffic that was being handled by that Appointed Forwarder is still to be ingressed and egressed, it SHOULD immediately appoint another forwarder or itself become the forwarder for that traffic.
根据定义，DRB将链路上的其他端口视为DRB端口在该链路上与其相邻的端口[RFC7177]。如果DRB失去与其指定为转发器的TRILL交换机的邻接，并且由该指定转发器处理的本机流量仍将进入和退出，则DRB应立即指定另一个转发器或其自身成为该流量的转发器。
It is important that there not be two Appointed Forwarders on a link that are ingressing and egressing native frames for the same VLAN at the same time. Should this occur, it could form a loop where frames are not protected by a TRILL Hop Count for part of the loop. (Such a condition can even occur through two Appointed Forwarders for two different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the link are configured to map frames between VLAN-x and VLAN-y as discussed in Section 2.5.) While TRILL tries to avoid such situations, for loop safety there is also an "inhibition" mechanism (see Section 3) that can cause a TRILL switch that is an Appointed Forwarder not to ingress or egress native frames. Appointed Forwarder status and port "inhibition" have no effect on the reception, transmission, or forwarding of TRILL Data or TRILL IS-IS frames. Appointed Forwarder status and inhibition only affect the handling of native frames.
重要的是，链路上不能有两个指定的转发器同时进入和退出同一VLAN的本机帧。如果出现这种情况，它可能会形成一个循环，其中部分循环的帧不受颤音跳数的保护。（如果链路内的端口或网桥配置为映射VLAN-x和VLAN-y之间的帧（如第2.5节所述），则这种情况甚至可以通过两个不同VLAN（VLAN-x和VLAN-y）的指定转发器发生。）当TRILL试图避免这种情况时，为了环路安全，还有一种“抑制”机制（见第3节）这可能会导致指定转发器的颤音开关无法进入或退出本机帧。指定的转发器状态和端口“抑制”对TRILL数据或TRILL IS-IS帧的接收、传输或转发没有影响。指定的转发器状态和禁止仅影响本机帧的处理。
As discussed in Section 5, an RBridge may have multiple ports on a link. As discussed in [RFC7177], if there are multiple ports with the same Media Access Control (MAC) address on the same link, all but one will be suspended. The case of multiple ports on a link for the same TRILL switch and the case of multiple ports with the same MAC address on a link, as well as combinations of these cases, are fully accommodated; however, the case of multiple ports on a link for the same TRILL switch is expected to be a rare condition, and the case of duplicate MAC addresses is not recommended by either TRILL or IEEE 802.1 standards.
如第5节所述，RBridge在链路上可能有多个端口。如[RFC7177]中所述，如果同一链路上有多个具有相同媒体访问控制（MAC）地址的端口，则除一个端口外，所有端口都将挂起。对于同一TRILL交换机的链路上的多个端口的情况，以及链路上具有相同MAC地址的多个端口的情况，以及这些情况的组合，都被完全容纳；然而，同一TRILL交换机的链路上存在多个端口的情况预计是罕见的，TRILL或IEEE 802.1标准都不建议出现MAC地址重复的情况。
There are six mechanisms by which an RBridge can be appointed or unappointed as Appointed Forwarder:
RBridge可通过六种机制被任命或取消任命为指定货运代理：
1. assumption of appointment, when the DRB decides to act as Appointed Forwarder for a VLAN,
1. 当DRB决定担任VLAN的指定转发器时，担任指定转发器，
2. E-L1CS appointment, as a result of appointments sent by the DRB in E-L1CS FS-LSPs,
2. E-L1CS预约，作为DRB在E-L1CS FS LSP中发送预约的结果，
3. Hello appointment, as a result of appointments sent by the DRB in TRILL Hellos,
3. 你好约会，由于DRB在TRILL Hellos中发送的约会，
4. as a result of the DRB elections [RFC7177] as discussed in Section 2.2,
4. 由于第2.2节中讨论的DRB选举[RFC7177]，
5. as a result of a Port-Shutdown message as discussed in Section 6, and
5. 由于第6节中讨论的端口关闭消息，以及
6. as a result of a local configuration action as discussed in Section 2.3.
6. 由于第2.3节中讨论的本地配置操作。
Mechanisms 2 and 3 are covered in Section 2.1.
第2.1节介绍了机制2和机制3。
The DRB MAY appoint other RBridges on the link as Appointed Forwarders through two mechanisms, "A" and "B", as described below.
DRB可通过两种机制“A”和“B”指定链路上的其他RBridge作为指定的转发商，如下所述。
Each RBridge maintains two databases of appointment information: (1) its E-L1CS LSDB, which shows appointments that each RBridge on the link would make using mechanism A if that RBridge were the DRB, and (2) its Hello appointment database, which shows the appointments most recently sent by the DRB in a TRILL Hello. The E-L1CS LSDB is semi-permanent and is only changed by E-L1CS FS-LSPs or IS-IS purges. The Hello appointment database is more transient and is completely reset by each Hello received from the DRB that contains any appointments; this database is also cleared under other circumstances, as described below. An RBridge considers itself to be the Appointed Forwarder for VLAN-x if this is indicated by either its Hello appointment database or its E-L1CS LSDB entries from the DRB.
每个RBridge维护两个约会信息数据库：（1）其E-L1CS LSDB，该数据库显示链路上的每个RBridge将使用机制A（如果该RBridge是DRB）进行的约会；（2）其Hello约会数据库，该数据库以TRILL Hello的形式显示DRB最近发送的约会。E-L1CS LSDB是半永久性的，仅通过E-L1CS FS LSP或is-is清洗进行更改。Hello约会数据库更为短暂，从包含任何约会的DRB接收到的每个Hello都会完全重置该数据库；该数据库在其他情况下也会被清除，如下所述。如果RBridge的Hello约会数据库或来自DRB的E-L1CS LSDB条目表明它是VLAN-x的指定转发器，则RBridge认为自己是VLAN-x的指定转发器。
The two mechanisms by which the DRB can appoint other RBridges on a link as Appointed Forwarders are as follows:
DRB可以通过以下两种机制指定链路上的其他RBridge作为指定的转发器：
(A) The inclusion of one or more Appointed Forwarders sub-TLVs [RFC7176], AppointmentBitmap APPsub-TLVs (Section 10.2), or AppointmentList APPsub-TLVs (Section 10.3) in E-L1CS LSPs it sends on a link. Appointments sent using this method will not be seen by legacy RBridges that do not support E-L1CS (Section 8).
（A） 在其通过链路发送的E-L1CS LSP中包含一个或多个指定转发器子TLV[RFC7176]、指定位图子TLV（第10.2节）或指定列表子TLV（第10.3节）。使用此方法发送的约会不会被不支持E-L1C的传统RBridge看到（第8节）。
(B) The inclusion of one or more Appointed Forwarders sub-TLVs [RFC7176] in a TRILL Hello it sends on the Designated VLAN out of the port that won the DRB election. When the DRB sends any appointments in a TRILL Hello, it must send all appointments it is sending in Hellos for that link in that Hello. Any previous appointment it has sent in a Hello that is not included is implicitly revoked.
（B） 将一个或多个指定的转发器子TLV[RFC7176]包含在TRILL Hello中，该转发器从赢得DRB选举的端口在指定VLAN上发送。当DRB在TRILL Hello中发送任何约会时，它必须发送它在Hello中为该链接发送的所有约会。它以前在问候中发送的任何未包含的约会都将被隐式撤销。
To avoid the size limitations of the Hello PDU, it is RECOMMENDED that the E-L1CS FS-LSP method be used to distribute forwarder appointments and that all RBridges on a link use this method to advertise the appointments they would make if they were the DRB. However, if some RBridges on a link do not support E-L1CS FS-LSPs, then Hello appointments must be used for the DRB to appoint such legacy RBridges as Appointed Forwarders.
为了避免Hello PDU的大小限制，建议使用E-L1CS FS-LSP方法来分发转发器预约，并且链路上的所有RBridge都使用此方法来公布他们如果是DRB将进行的预约。但是，如果链路上的某些RBridge不支持E-L1CS FS LSP，则DRB必须使用Hello预约来指定这些遗留RBridge作为指定的转发器。
Although the DRB does not need to announce the VLANs for which it has chosen to act as Appointed Forwarder by sending appointments for itself, if the DRB wishes to revoke all appointments made in Hellos for RBridges other than itself on the link, it can do so by sending a TRILL Hello with just an appointment for itself for some VLAN.
尽管DRB不需要通过发送自己的预约来宣布其已选择作为指定转发器的VLAN，但如果DRB希望撤销除自身之外在链路上为RBridges在Hellos中所做的所有预约，它可以通过发送TRILL Hello，只为自己对某个VLAN进行预约来实现。
How the DRB decides what other RBridges on the link, if any, to appoint as forwarder for some VLAN or VLANs is beyond the scope of this document.
DRB如何决定链路上的哪些其他RBridge（如果有）指定为某些VLAN或VLAN的转发器超出了本文档的范围。
Unnecessary changes in Appointed Forwarders SHOULD NOT be made, as they may result in transient lack of end-station service.
不应对指定的货运代理进行不必要的变更，因为这些变更可能会导致短暂的末站服务缺失。
Should the network manager have misconfigured the enabled VLANs and Appointed Forwarders, resulting in two RBridges believing they are Appointed Forwarders for the same VLAN, the scenario described in item 4 in Section 3 will cause one or more of the RBridges to be inhibited for that VLAN, thus avoiding persistent loops.
如果网络管理器错误配置了启用的VLAN和指定转发器，导致两个RBridge认为它们是同一VLAN的指定转发器，则第3节第4项中描述的场景将导致该VLAN的一个或多个RBridge被禁用，从而避免持续循环。
When forwarder appointments are being encoded for transmission, different patterns of VLANs are most efficiently encoded in different ways. The following table gives advice regarding the most efficient encoding for a given pattern:
当对转发器预约进行编码以进行传输时，以不同的方式对不同的VLAN模式进行最有效的编码。下表给出了关于给定模式的最有效编码的建议：
sub-TLV and Reference
Pattern of VLAN IDs |enclosing TLV(s) and Reference
------------------- ------------------------------------
sub-TLV and Reference
Pattern of VLAN IDs |enclosing TLV(s) and Reference
------------------- ------------------------------------
Blocks of consecutive VLANs
Appointed Forwarders sub-TLV [RFC7176]
|Router CAPABILITY TLV [RFC7981]
|or MT-Capability TLV [RFC6329]
Blocks of consecutive VLANs
Appointed Forwarders sub-TLV [RFC7176]
|Router CAPABILITY TLV [RFC7981]
|or MT-Capability TLV [RFC6329]
Scattered VLANs within a small range AppointmentBitmap APPsub-TLV (Section 10.2) |TRILL GENINFO TLV [RFC7357]
小范围内分散的VLAN任命位图APPsub TLV（第10.2节）| TRILL GENINFO TLV[RFC7357]
Scattered VLANs over a large range AppointmentList APPsub-TLV (Section 10.3) |TRILL GENINFO TLV [RFC7357]
大范围任命列表APPsub TLV上分散的VLAN（第10.3节）| TRILL GENINFO TLV[RFC7357]
When a TRILL switch port on a link wins the DRB election, there are four possible cases:
当链路上的TRILL交换机端口赢得DRB选举时，有四种可能的情况：
1. A TRILL switch believes that it was the DRB and remains the DRB: there is no change in Appointed Forwarder status. This also applies in the corner case where a TRILL switch has more than one port on a link, one of which was previously the DRB election winner but has just lost the DRB election to a different port of the same TRILL switch on the same link (possibly due to management configuration of port priorities). In this case, there also is no change in which TRILL switch is the DRB.
1. TRILL开关认为它是DRB，并且仍然是DRB：指定的货运代理状态没有变化。这也适用于TRILL交换机在链路上有多个端口的情况，其中一个以前是DRB选举的获胜者，但刚刚失去了DRB选举，而在同一链路上失去了同一TRILL交换机的不同端口（可能是由于端口优先级的管理配置）。在这种情况下，颤音开关是DRB的位置也没有变化。
2. A TRILL switch believes that it was not the DRB but has now won the DRB election and become the DRB on a link: by default, it can act as Appointed Forwarder for any VLANs on that link that it chooses, as long as its port is not configured as a trunk port and has that VLAN enabled (or at least one of its ports meets these criteria, if it has more than one port on the link). It ignores any previous forwarder appointment information it received from other TRILL switches on the link.
2. TRILL交换机认为它不是DRB，但现在已经赢得了DRB选举并成为链路上的DRB：默认情况下，它可以作为它选择的链路上任何VLAN的指定转发器，只要它的端口未配置为中继端口并且启用了该VLAN（或者至少有一个端口符合这些标准，如果它在链路上有多个端口）。它忽略以前从链路上的其他TRILL交换机收到的任何转发器预约信息。
3. A TRILL switch was not the DRB and does not become the DRB, but it observes that the port winning the DRB election has changed: the TRILL switch loses all Hello appointments. In addition, there are two subcases:
3. TRILL交换机不是DRB，也不会成为DRB，但它观察到赢得DRB选举的端口发生了变化：TRILL交换机失去了所有Hello约会。此外，还有两个子类别：
a. The new winning port and the old winner are ports of different TRILL switches on the link. In this case, it switches to using the E-L1CS FS-LSP appointments for the winning TRILL switch.
a. 新赢端口和旧赢端口是链路上不同TRILL交换机的端口。在这种情况下，它会切换到使用E-L1CS FS-LSP预约来进行获胜的颤音切换。
b. The new winning port and the old winner are ports of the same TRILL switch, which has two (or more) ports on the link: although the Hello appointments are still discarded, since the same TRILL switch is the DRB, the E-L1CS FS-LSP appointments are unchanged.
b. 新获胜端口和旧获胜端口是同一TRILL交换机的端口，该交换机在链路上有两个（或更多）端口：尽管Hello约会仍然被丢弃，但由于同一TRILL交换机是DRB，因此E-L1CS FS-LSP约会保持不变。
4. The winning port is unchanged: as in case 1, there is no change in Appointed Forwarder status.
4. 获胜港口不变：与案例1一样，指定货代的状态没有变化。
When a non-DRB RBridge that can offer end-station service on a link receives a TRILL Hello that is not discarded for one of the reasons given in [RFC7177], it checks the source MAC address and the Port ID and System ID in the Hello to determine if it is from the winning DRB port. If it is not from that port, any forwarder appointment sub-TLVs in the Hello are ignored, and there is no change in the receiving RBridge's Appointed Forwarder status due to that Hello. Also, if no forwarder appointment sub-TLVs are present in the TRILL Hello, there is no change in the receiver's Appointed Forwarder status due to that Hello.
当能够在链路上提供终端站服务的非DRB RBridge收到由于[RFC7177]中给出的原因之一而未被丢弃的TRILL Hello时，它会检查Hello中的源MAC地址、端口ID和系统ID，以确定它是否来自获胜的DRB端口。如果不是来自该端口，则忽略Hello中的任何转发器指定子TLV，并且接收RBridge的指定转发器状态不会因该Hello而发生更改。此外，如果TRILL Hello中不存在转发器指定子TLV，则接收方的指定转发器状态不会因该Hello而发生变化。
However, if the TRILL Hello is from the winning DRB port and the Hello includes one or more forwarder appointment sub-TLVs, then the receiving RBridge sets its Hello appointment database to be the set of VLANs that have both of the following characteristics:
但是，如果TRILL Hello来自获胜的DRB端口，并且Hello包含一个或多个转发器预约子TLV，则接收RBridge将其Hello预约数据库设置为具有以下两个特征的VLAN集：
o The VLAN is listed as an appointment for the receiving RBridge in the Hello, and
o VLAN被列为Hello中接收RBridge的预约，并且
o The VLAN is enabled on the port where the Hello was received.
o VLAN在接收Hello的端口上启用。
(If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored, but any other VLAN IDs are still effective.) It then becomes Appointed Forwarder for all the VLANs for which it is appointed in either its Hello appointment database or its E-L1CS FS-LSP appointment database from the DRB if the VLAN is enabled and if the port is not configured as a trunk or IS-IS point-to-point port. If the receiver was Appointed Forwarder for any VLANs because
（如果约会包括VLAN ID 0x000或0xFFF，则忽略它们，但任何其他VLAN ID仍然有效。）然后，如果VLAN已启用且端口未配置为中继或is-is点对点端口，则它将成为所有VLAN的指定转发器，并在其Hello约会数据库或DRB的E-L1CS FS-LSP约会数据库中为其指定。如果接收方被指定为任何VLAN的转发器，因为
they were in the Hello appointment database and they are no longer in the Hello appointment database, its Appointed Forwarder status for such VLANs is revoked. For example, if none of these sub-TLVs in a Hello appoints the receiving RBridge, then it loses all Appointed Forwarder status on the port where the Hello was received due to Hello appointment database entries, but it retains Appointed Forwarder status due to E-L1CS FS-LSP appointments.
它们位于Hello约会数据库中，并且不再位于Hello约会数据库中，该VLAN的指定转发器状态已撤销。例如，如果Hello中的这些子TLV均未指定接收RBridge，则由于Hello约会数据库条目，它将丢失接收Hello的端口上的所有指定转发器状态，但由于E-L1CS FS-LSP约会，它将保留指定转发器状态。
The handling of one or more forwarder appointment sub-TLVs in a Hello from the winning port that appoints the receiving RBridge is as follows: an appointment in an Appointed Forwarders sub-TLV is for a specific RBridge and a contiguous interval of VLAN IDs; however, as stated above, it actually appoints that RBridge as forwarder only for the VLAN or VLANs in that range that are enabled on one or more ports that RBridge has on the link (ignoring any ports configured as trunk ports or as IS-IS point-to-point ports).
来自指定接收RBridge的获胜端口的Hello中的一个或多个转发器指定子TLV的处理如下：指定转发器子TLV中的指定用于特定RBridge和VLAN ID的连续间隔；但是，如上所述，它实际上指定RBridge仅作为该范围内的VLAN或VLAN的转发器，这些VLAN在RBridge在链路上的一个或多个端口上启用（忽略配置为中继端口或IS点到点端口的任何端口）。
There is no reason for an RBridge to remember that it received a valid appointment Hello message for a VLAN that was ineffective because the VLAN was not enabled on the port where the Hello was received or because the port was a trunk or point-to-point port. It does not become Appointed Forwarder for such a VLAN just because that VLAN is later enabled or the port is later reconfigured.
RBridge没有理由记住，它收到的VLAN的有效约会Hello消息无效，因为接收Hello的端口上未启用VLAN，或者端口是中继或点对点端口。它不会因为VLAN稍后启用或端口稍后重新配置而成为此类VLAN的指定转发器。
The limitations due to the size of the Hello PDU make it desirable to use E-L1CS FS-LSPs for appointment. But if Hellos need to be used, due to TRILL switches on the link not supporting E-L1CS FS-LSPs, the remainder of this section provides a method to maximize the use of the limited space in Hellos for forwarder appointment.
由于Hello PDU的大小而受到限制，因此需要使用E-L1CS FS LSP进行预约。但是，如果由于链路上的TRILL开关不支持E-L1CS FS LSP，需要使用Hellos，则本节的其余部分提供了一种方法，以最大限度地利用Hellos中的有限空间进行转发器预约。
It should be straightforward for the DRB to send, within one Hello, the appointments for several dozen VLAN IDs or several dozen blocks of contiguous VLAN IDs. Should the VLANs that the DRB wishes to appoint be inconveniently distributed (for example, the proverbial case where a DRB (say RB1) wishes to appoint RB2 as forwarder for all even-numbered VLANs and appoint RB3 as forwarder for all odd-numbered VLANs), the following method may be used:
DRB在一个Hello内发送几十个VLAN ID或几十个连续VLAN ID块的预约应该很简单。如果DRB希望指定的VLAN分布不方便（例如，众所周知，DRB（比如RB1）希望指定RB2作为所有偶数VLAN的转发器，并指定RB3作为所有奇数VLAN的转发器），可以使用以下方法：
The network manager normally controls what VLANs are enabled on an RBridge port. Thus, the network manager can appoint an RBridge as forwarder for an arbitrary set of scattered VLANs by enabling only those VLANs on the relevant port (or ports) and then having the DRB send an appointment that appears to appoint the target RBridge as forwarder for all VLANs. However, for proper operation and inter-RBridge communication, the Designated VLAN for a link SHOULD be enabled on all RBridge ports on that link, and it may not be desired to appoint the RBridge as forwarder for the Designated VLAN. Thus, in the general case, two appointments
网络管理器通常控制RBridge端口上启用的VLAN。因此，网络管理器可以通过仅启用相关端口（或多个端口）上的那些VLAN，然后让DRB发送一个似乎将目标RBridge指定为所有VLAN的转发器的指定，来指定RBridge作为任意分散VLAN集的转发器。但是，为了正确操作和RBridge间通信，应在该链路上的所有RBridge端口上启用链路的指定VLAN，并且可能不希望指定RBridge作为指定VLAN的转发器。因此，在一般情况下，有两项任命
would be required, although only one appointment would be required if the Designated VLAN value were extremely low or high (such as VLAN 0xFFE) or the default value (VLAN 1).
将是必需的，但如果指定的VLAN值极低或极高（如VLAN 0xFFE）或默认值（VLAN 1），则只需要一次预约。
For example, assume that the DRB wants RB2 to be Appointed Forwarder for all even-numbered VLANs and the Designated VLAN for the link is VLAN 101. The network manager could cause all even-numbered VLANs plus VLAN 101 to be enabled on the relevant port of RB2 and then, with the desired effect, cause the DRB to send appointments to RB2 appointing it forwarder for all VLANs from 1 through 100 and from 102 through 4,094.
例如，假设DRB希望RB2被指定为所有偶数VLAN的转发器，并且链路的指定VLAN是VLAN 101。网络管理器可以在RB2的相关端口上启用所有偶数编号的VLAN加上VLAN 101，然后，在期望的效果下，使DRB向RB2发送预约，为从1到100以及从102到4094的所有VLAN指定it转发器。
Appointments made through E-L1CS FS-LSPs use the same IS-IS timing constants as those for LSP flooding. The general IS-IS link-state flooding mechanism is robust and includes acknowledgments so that it automatically recovers from lost PDUs, rebooted TRILL switches, and the like.
通过E-L1CS FS LSP进行的预约使用与LSP泛洪相同的IS-IS定时常数。通用IS-IS链路状态泛洪机制是健壮的，并且包括确认，以便自动从丢失的PDU、重新启动的TRILL交换机等中恢复。
For Hello appointments, it is not necessary for the DRB to include the Hello forwarder appointments in every TRILL Hello that it sends on the Designated VLAN for a link. For loop safety, every RBridge is required to indicate, in every TRILL Hello it sends in VLAN-x on a link, whether it is an Appointed Forwarder for VLAN-x for that link (see item 4 in Section 3, but see also Section 4). It is also RECOMMENDED that the DRB have enabled all VLANs for which end-station service will be offered on the link as well as the Designated VLAN. Thus, the DRB will generally be informed by other RBridges on the link of the VLANs for which they believe that they are the Appointed Forwarder. If this matches the appointments the DRB wishes to make, it is not required to resend its forwarder appointments; however, for robustness, especially in cases such as VLAN misconfigurations in a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder appointments on the Designated VLAN at least once per its Holding Time on the port that won the DRB election.
对于Hello约会，DRB没有必要在其在指定的VLAN上为链接发送的每个TRILL Hello中包含Hello转发器约会。为了环路安全，要求每个RBridge在其在链路上以VLAN-x发送的每个TRILL Hello中指示它是否是该链路VLAN-x的指定转发器（请参见第3节中的第4项，但也请参见第4节）。还建议DRB启用链路上将提供终端站服务的所有VLAN以及指定的VLAN。因此，DRB通常会收到VLAN链路上的其他RBridge的通知，他们认为自己是VLAN的指定转发器。如果这与DRB希望作出的约定相符，则无需重新发送其货运代理人约定；然而，为了健壮性，特别是在桥接LAN链路中的VLAN配置错误的情况下，建议DRB在赢得DRB选举的端口上，每等待一次，至少在指定VLAN上发送一次其转发器预约。
The Hello mechanism of DRB forwarder appointment and the limited length of TRILL Hellos impose a limit on the number of RBridges on a link that can be Appointed Forwarders when E-L1CS FS-LSP appointments cannot be used due to the presence of legacy RBridges. To obtain a conservative estimate of this limit, assume that no more than 1,000 bytes are available in a TRILL Hello for such appointments. Assume also that it is desired to appoint various RBridges on a link as forwarder for arbitrary non-intersecting sets of VLANs. Using the technique discussed at the end of Section 2.2.1 would generally
DRB转发器任命的Hello机制和TRILL Hellos的有限长度对链路上可指定转发器的RBridge数量施加了限制，因为存在遗留RBridge，无法使用E-L1CS FS-LSP任命。要获得此限制的保守估计值，请假设此类约会的TRILL Hello中可用字节数不超过1000字节。还假设需要指定链路上的各种RBridge作为任意非交叉VLAN集的转发器。使用第2.2.1节末尾讨论的技术通常
require two appointments, or 12 bytes, per RBridge. With allowance for sub-TLV and TLV overhead, appointments for 83 RBridges would fit in under 1,000 bytes. Including the DRB, this implies a link with 84 or more RBridges attached. Links with more than a handful of RBridges attached are expected to be rare, and in any case such limitations are easily avoided by using E-L1CS FS-LSP appointment.
每个RBridge需要两次预约，或12个字节。考虑到子TLV和TLV开销，83个RBridge的预约将在1000字节以下。包括DRB，这意味着连接了84个或更多RBB的链路。与多个RBridge连接的链接预计很少，在任何情况下，使用E-L1CS FS-LSP预约都可以轻松避免此类限制。
Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder status that RBridge has for VLAN-x, unless VLAN-x is enabled on some other port that the RBridge has connected to the same link. Configuring a port as a trunk port or point-to-point port revokes any Appointed Forwarder status that depends on enabled VLANs at that port.
在RBridge端口禁用VLAN-x将取消RBridge为VLAN-x指定的任何转发器状态，除非在RBridge已连接到同一链路的其他端口上启用VLAN-x。将端口配置为中继端口或点对点端口将取消任何指定的转发器状态，该状态取决于该端口上已启用的VLAN。
Causing a port to no longer be configured as a trunk or point-to-point port or enabling VLAN-x on a port does not necessarily cause the RBridge to become an Appointed Forwarder for the link that port is on. However, such actions allow the port's RBridge to become Appointed Forwarder by choice if it is the DRB or, if it is not the DRB on the link, by appointment as indicated by the Hello appointment database or the E-L1CS FS-LSP appointment database.
使端口不再配置为中继或点对点端口或在端口上启用VLAN-x并不一定会使RBridge成为该端口所在链路的指定转发器。但是，如果是DRB，则此类操作允许港口的RBridge通过选择成为指定的转发器，如果不是链路上的DRB，则通过Hello约会数据库或E-L1CS FS-LSP约会数据库指示的约会成为指定的转发器。
A TRILL switch in link-state overload [RFC7780] will, in general, do a poorer job of forwarding frames than a TRILL switch not in overload, because the TRILL switch not in overload has full knowledge of the campus topology. For example, as explained in [RFC7780], an overloaded TRILL switch may not be able to distribute multi-destination TRILL Data packets at all.
通常，链路状态过载的TRILL交换机[RFC7780]在转发帧方面的性能不如未过载的TRILL交换机，因为未过载的TRILL交换机完全了解校园拓扑。例如，如[RFC7780]中所述，过载的TRILL交换机可能根本无法分发多目标TRILL数据包。
Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an Appointed Forwarder, and if an Appointed Forwarder becomes overloaded, the DRB SHOULD reassign VLANs from the overloaded RBridge to another RBridge on the link that is not overloaded, if one is available.
因此，DRB不应将过载中的RBridge指定为指定的转发器，如果指定的转发器过载，DRB应将VLAN从过载的RBridge重新分配给链路上未过载的另一个RBridge（如果有）。
A counter-example where it would be best to appoint an RBridge in overload as Appointed Forwarder would be if RB1 was in overload but all end stations in the campus in VLAN-x were on links attached to RB1. In such a case, RB1 would never have to route VLAN-x end-station traffic as TRILL Data packets but would always be forwarding them locally as native frames. In this case, RB1 SHOULD NOT be disadvantaged for selection as the VLAN-x Appointed Forwarder on any such links, even if RB1 is in overload.
一个反例是，如果RB1处于过载状态，但VLAN-x中校园中的所有终端站都在连接到RB1的链路上，则最好指定一个处于过载状态的RBridge作为指定的转发器。在这种情况下，RB1将永远不必将VLAN-x端站流量作为TRILL数据包路由，而是始终将它们作为本机帧在本地转发。在这种情况下，即使RB1处于过载状态，RB1也不应被选为任何此类链路上的VLAN-x指定转发器。
There is also the case where it is unavoidable to appoint an RBridge in overload as Appointed Forwarder, because all RBridges on the link are in overload.
还有一种情况是，由于链路上的所有RBridge都处于过载状态，因此不可避免地指定一个处于过载状态的RBridge作为指定的货运代理。
These cases do not violate the prohibition in the IS-IS standard against routing through an overloaded node. Designation as an Appointed Forwarder has to do with the ingress and egress of native frames and has nothing to do with the IS-IS routing of TRILL Data packets through a TRILL switch.
这些情况并不违反IS-IS标准中禁止通过过载节点进行路由的规定。指定为指定转发器与本机帧的进出有关，与通过TRILL交换机的TRILL数据包的IS-IS路由无关。
Overload does not affect DRB election, but a TRILL switch in overload MAY reduce its own priority to be the DRB.
重载不会影响DRB选择，但重载中的颤音开关可能会降低其作为DRB的优先级。
TRILL Hellos include a field that is set to the VLAN in which they are sent when they are sent on a link technology such as Ethernet that has outer VLAN labeling. (For link technologies such as PPP that do not have outer VLAN labeling, this Hello field is ignored.) If a TRILL Hello arrives on a different VLAN than the VLAN on which it was sent, then VLAN mapping is occurring within the link. VLAN mapping between VLAN-x and VLAN-y can lead to a loop if the Appointed Forwarders for the VLANs are different. If such mapping within a link was allowed and occurred on two or more links so that there was a cycle of VLAN mappings, a multi-destination frame would loop forever. Such a frame would be "immortal". For a specific example, see Appendix B.
TRILL Hello包括一个字段，该字段设置为当它们通过链路技术（如具有外部VLAN标签的以太网）发送时在其中发送的VLAN。（对于没有外部VLAN标签的PPP等链路技术，此Hello字段将被忽略。）如果TRILL Hello到达的VLAN与发送它的VLAN不同，则VLAN映射将在链路中发生。如果为VLAN指定的转发器不同，VLAN-x和VLAN-y之间的VLAN映射可能导致循环。如果允许在一个链路中进行这种映射，并且这种映射发生在两个或多个链路上，因此存在一个VLAN映射周期，那么多目标帧将永远循环。这样的框架将是“不朽的”。有关具体示例，请参见附录B。
To prevent this potential problem, if the DRB on a link detects VLAN mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it MUST make or revoke appointments so as to assure that the same TRILL switch (possibly the DRB) is the Appointed Forwarder on the link for both VLAN-x and VLAN-y.
为防止此潜在问题，如果链路上的DRB通过接收VLAN-y上发送的VLAN-x中的Hello来检测VLAN映射，则必须进行或撤销预约，以确保相同的TRILL交换机（可能是DRB）是VLAN-x和VLAN-y链路上的指定转发器。
A TRILL switch has, for every link on which it can offer end-station service (that is, every link for which it can act as an Appointed Forwarder), the following timers, denominated in seconds:
对于TRILL交换机可提供端站服务的每条链路（即，其可作为指定转发器的每条链路），其具有以下计时器，以秒为单位：
- a DRB inhibition timer,
- DRB抑制定时器，
- a root bridge change inhibition timer, and
- 根桥改变抑制定时器，以及
- up to 4,094 VLAN inhibition timers, one for each legal VLAN ID.
- 最多4094个VLAN抑制计时器，每个合法VLAN ID对应一个。
The DRB and root bridge change inhibition timers MUST be implemented.
必须实现DRB和根网桥更改抑制计时器。
The loss of native traffic due to inhibition will be minimized by logically implementing a VLAN inhibition timer per each VLAN for which end-station service will ever be offered by the RBridge on the link; this SHOULD be done. (See Appendix A for an example illustrating a potential problem that is solved by VLAN inhibition timers.) However, if implementation limitations make a full set of such timers impractical, the VLAN inhibition timers for more than one VLAN can, with care, be merged into one timer. In particular, an RBridge MUST NOT merge the VLAN inhibition timers for two VLANs if it is the Appointed Forwarder for one but not for the other, as this can lead to unnecessary indefinitely prolonged inhibition. In a given implementation limitation, there will be safe operations, albeit with more loss of native frames than would otherwise be required, even if only two VLAN inhibition timers are provided: one for the VLANs for which the RBridge is the Appointed Forwarder and one for all other VLANs. Thus, at least two VLAN inhibition timers MUST be implemented. Where a VLAN inhibition timer represents more than one VLAN, an update or test that would have been done to the timer for any of the VLANs is performed on the merged timer.
通过在逻辑上为每个VLAN实现VLAN抑制计时器，可以最大限度地减少由于抑制而导致的本机流量损失，RBridge将在链路上为每个VLAN提供终端站服务；应该这样做。（关于说明VLAN抑制定时器可解决的潜在问题的示例，请参见附录A。）但是，如果实施限制使得全套此类定时器不可行，则可以小心地将多个VLAN的VLAN抑制定时器合并到一个定时器中。特别是，如果RBridge是一个VLAN而不是另一个VLAN的指定转发器，则RBridge不得合并两个VLAN的VLAN抑制计时器，因为这可能导致不必要的无限期延长抑制。在给定的实现限制下，将存在安全操作，尽管本机帧的丢失比其他情况下需要的更多，即使只提供两个VLAN抑制计时器：一个用于RBridge作为指定转发器的VLAN，另一个用于所有其他VLAN。因此，必须至少实现两个VLAN抑制计时器。如果VLAN抑制计时器表示多个VLAN，则会在合并计时器上对任何VLAN的计时器执行更新或测试。
These timers are set as follows:
这些定时器设置如下：
1. On booting or management reset, each port will have its own set of timers, even if two or more such ports are on the same link, because the TRILL switch will not have had a chance yet to learn that they are on the same link. All inhibition timers are set to "expired", except the DRB inhibition timer that is set in accordance with item 2 below. The DRB inhibition timer is handled differently, because each port will initially believe that it is the DRB.
1. 在引导或管理重置时，每个端口都将有自己的计时器集，即使两个或更多这样的端口位于同一链路上，因为TRILL交换机还没有机会知道它们位于同一链路上。除根据以下第2项设置的DRB抑制定时器外，所有抑制定时器均设置为“过期”。DRB抑制计时器的处理方式不同，因为每个端口最初都认为它是DRB。
2. When a TRILL switch decides that it has become the DRB on a link, including when it is first booted or reset by management, it sets the DRB inhibition timer to the Holding Time of its port on that link that won the DRB election.
2. 当TRILL交换机决定它已成为链路上的DRB时，包括管理层首次启动或重置时，它会将DRB抑制计时器设置为该链路上赢得DRB选举的端口的保持时间。
3. When a TRILL switch decides that it has lost DRB status on a link, it sets the DRB inhibition timer to "expired".
3. 当颤音开关确定其已失去链路上的DRB状态时，它会将DRB抑制计时器设置为“过期”。
Note: In the corner case where one port of a TRILL switch was the DRB election winner but later lost the DRB election to a different port of the same TRILL switch on that link (perhaps due to management configuration of port priorities), neither item 2 nor item 3 above applies, and the DRB timer is not changed.
注意：在TRILL交换机的一个端口是DRB选择的赢家，但后来在该链路上的同一TRILL交换机的另一个端口上失去了DRB选择的情况下（可能是由于端口优先级的管理配置），上述第2项和第3项均不适用，且DRB计时器未更改。
4. When a TRILL switch RB1 receives a TRILL Hello asserting that the sender is the Appointed Forwarder and that Hello either (1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated
4. 当TRILL交换机RB1接收到TRILL Hello时，表明发送方是指定的转发器，并且Hello（1）到达VLAN-x或（2）在VLAN-x上发送，如图所示
inside the Hello, RB1 uses as its VLAN-x inhibition timer for the link (1) that timer's existing value or (2) the Holding Time in the received Hello, whichever is longer. A TRILL switch MUST maintain VLAN inhibition timers covering a link to which it connects if it can offer end-station service on that link, even if it is not currently the Appointed Forwarder for any VLAN on that link.
在Hello内部，RB1将其VLAN-x抑制计时器用于链路（1）该计时器的现有值或（2）接收到的Hello中的保持时间，以较长者为准。TRILL交换机必须维护覆盖其所连接链路的VLAN抑制计时器，如果它可以在该链路上提供终端站服务，即使它当前不是该链路上任何VLAN的指定转发器。
5. When a TRILL switch RB1 enables VLAN-x on a port connecting to a link and VLAN-x was previously not enabled on any of RB1's ports on that link, it sets its VLAN inhibition timer for VLAN-x for that link to its Holding Time for that port. This is done even if the port is configured as a trunk or point-to-point port, as long as there is some chance it might later be configured not to be a trunk or point-to-point port. Remember, inhibition has no effect on TRILL Data or IS-IS packets; inhibition only affects native frames.
5. 当TRILL交换机RB1在连接到链路的端口上启用VLAN-x，且该链路上的任何RB1端口上以前未启用VLAN-x时，它会将该链路的VLAN-x的VLAN抑制计时器设置为该端口的保持时间。即使将端口配置为中继或点对点端口，只要以后可能会将其配置为非中继或点对点端口，也可以执行此操作。记住，抑制对颤音数据或IS-IS数据包没有影响；抑制只影响本机帧。
6. When a TRILL switch detects a change in the common spanning tree root bridge on a port, it sets its root bridge change inhibition timer for the link to an amount of time that defaults to 30 seconds and is configurable to any value from 30 down to 0 seconds. This condition will not occur unless the TRILL switch is receiving Bridge PDUs (BPDUs) on the port from an attached bridged LAN; if no BPDUs are being received, the root bridge change inhibition timer will never be set. It is safe to configure this inhibition time to the settling time of an attached bridged LAN. For example, if it is known that the Rapid Spanning Tree Protocol (RSTP) [802.1Q] is running throughout the attached bridged LAN, it is safe to configure this inhibition time to 7 seconds or, if the attached bridges have been configured to have a minimum Bridge Hello Timer, it is safe to configure it to 4 seconds. Further optimizations are specified in Section 3.2.
6. 当TRILL交换机检测到端口上的公共生成树根网桥发生更改时，它会将链路的根网桥更改抑制计时器设置为默认为30秒的时间量，并可配置为从30秒到0秒的任何值。除非TRILL交换机在端口上从连接的桥接LAN接收桥接PDU（BPDU），否则不会出现这种情况；如果未接收到BPDU，则永远不会设置根网桥更改抑制计时器。将此抑制时间配置为连接的桥接LAN的稳定时间是安全的。例如，如果已知快速生成树协议（RSTP）[802.1Q]在整个连接的桥接LAN中运行，则安全地将该抑制时间配置为7秒，或者，如果连接的网桥已配置为具有最小网桥Hello定时器，则安全地将其配置为4秒。第3.2节规定了进一步的优化。
7. When a TRILL switch decides that one of its ports (or a set of its ports) P1 is on the same link as another one of its ports (or set of its ports) P2, the inhibition timers are merged into a single set of inhibition timers by using the longest value of the corresponding timers as the initial value of the merged timers.
7. 当TRILL交换机确定其一个端口（或其一组端口）P1与其另一个端口（或其一组端口）P2位于同一链路上时，通过使用相应计时器的最长值作为合并计时器的初始值，将抑制计时器合并为一组抑制计时器。
8. When an RBridge decides that a set of its ports that it had been treating as being on the same link are no longer on the same link, those ports will necessarily be on two or more links (up to one link per port). This is handled by cloning a copy of the timers for each of the two or more links to which the TRILL switch has decided these ports connect.
8. 当RBridge决定它一直视为在同一链路上的一组端口不再在同一链路上时，这些端口必须在两个或多个链路上（每个端口最多一个链路）。这是通过为TRILL交换机已确定这些端口连接的两个或多个链路中的每个链路克隆计时器副本来实现的。
Inhibition has no effect on the receipt or forwarding of TRILL Data packets or TRILL IS-IS packets. It only affects ingressing and egressing native frames.
抑制对TRILL数据包或TRILL IS-IS包的接收或转发没有影响。它只影响本机帧的进出。
An Appointed Forwarder for a link is inhibited for VLAN-x if:
在以下情况下，VLAN-x将禁止指定的链路转发器：
1. its DRB inhibition timer for that link is not expired,
1. 该链路的DRB抑制计时器未过期，
2. its root bridge change inhibition timer for that link is not expired, or
2. 该链接的根网桥更改抑制计时器未过期，或
3. its VLAN inhibition timer for that link covering VLAN-x is not expired.
3. 覆盖VLAN-x的链路的VLAN抑制计时器未过期。
If a VLAN-x Appointed Forwarder for a link is inhibited and receives a TRILL Data packet whose encapsulated frame would normally be egressed to that link in VLAN-x, it decapsulates the native frame as usual. However, it does not output it to, or queue it for, that link, although, if appropriate (for example, the frame is multi-destination), it may output it to, or queue it for, other links.
如果VLAN-x指定的链路转发器被禁止，并接收到一个TRILL数据包，该数据包的封装帧通常会被导出到VLAN-x中的该链路，则它会像往常一样解除本机帧的封装。但是，它不会将其输出到该链路，也不会为该链路排队，尽管在适当的情况下（例如，帧是多目的地），它可能会将其输出到其他链路，或为其他链路排队。
If a VLAN-x Appointed Forwarder for a link is inhibited and receives a native frame in VLAN-x that would normally be ingressed from that link, the native frame is ignored, except for address learning.
如果为链路指定的VLAN-x转发器被禁止，并在VLAN-x中接收通常从该链路进入的本机帧，则本机帧将被忽略，地址学习除外。
A TRILL switch with one or more unexpired inhibition timers, possibly including an unexpired inhibition timer covering VLAN-x, is still required to indicate in TRILL Hellos it sends on VLAN-x whether or not it is Appointed Forwarder for VLAN-x for the port on which it sends the Hello.
带有一个或多个未过期禁止计时器（可能包括覆盖VLAN-x的未过期禁止计时器）的TRILL交换机仍然需要在其在VLAN-x上发送的TRILL Hello中指示其是否为其发送Hello的端口的VLAN-x指定转发器。
The subsections below specify three optimizations that can reduce the inhibition time of an RBridge port under certain circumstances for changes in the root Bridge ID [802.1Q] being received by that port and thus decrease any transient interruption in end-station service due to inhibition. TRILL switches MAY implement these optimizations. In the first two optimizations, inhibition can be eliminated entirely under some circumstances. These optimizations are a bit heuristic in that with some unlikely multiple changes in a bridged LAN that occur simultaneously, or nearly so, the optimizations make transient looping more likely.
下面的小节指定了三种优化，它们可以在特定情况下减少RBridge端口对该端口接收到的根网桥ID[802.1Q]的更改的抑制时间，从而减少由于抑制而导致的终端站服务的任何瞬时中断。颤音开关可以实现这些优化。在前两种优化中，在某些情况下可以完全消除抑制。这些优化有点启发性，因为在桥接LAN中同时发生或几乎同时发生的一些不太可能的多个更改中，优化使瞬时循环更有可能发生。
Assume that the root Bridge ID being received on an RBridge port changes to a new root Bridge ID with lower priority and a different root Bridge MAC address due to a single change in the bridged LAN. There are two possible reasons for this:
假设由于桥接LAN中的单个更改，在RBridge端口上接收的根网桥ID更改为具有较低优先级的新根网桥ID和不同的根网桥MAC地址。这可能有两个原因：
1. The bridged LAN to which the port is connected has partitioned into two or more parts due to link failure or otherwise, and the port is connected to a part that does not contain the original root bridge.
1. 由于链路故障或其他原因，端口连接到的桥接LAN已划分为两个或多个部分，并且端口连接到不包含原始根网桥的部分。
2. The original root bridge has been reconfigured to have a lower priority, and a new root has taken over.
2. 原始根网桥已重新配置为具有较低的优先级，新根网桥已接管。
Both of these scenarios are safe conditions that do not require inhibition.
这两种情况都是不需要抑制的安全条件。
Assume that the root Bridge ID changes due to a single change in the bridged LAN but only the explicit priority portion of it changes. This means that the 48-bit MAC address portion of the root Bridge ID is unchanged and the root bridge has been reconfigured to have a different priority. Thus, the same bridge is root, and a topology change is not indicated. Thus, it is safe to ignore this sort of root Bridge ID change and not invoke the inhibition mechanism.
假设根网桥ID因网桥LAN中的单个更改而更改，但仅其显式优先级部分更改。这意味着根网桥ID的48位MAC地址部分不变，并且根网桥已重新配置为具有不同的优先级。因此，相同的网桥是根网桥，并且不指示拓扑更改。因此，可以安全地忽略这种根桥ID更改，而不调用抑制机制。
A dangerous case is the merger of bridged LANs that had been separate TRILL links in the same campus. In general, these links may have had different Appointed Forwarders on them for the same VLAN. Without inhibition, loops involving those VLANs could occur after the merger.
一个危险的案例是在同一校园中作为独立TRILL链路的桥接LAN的合并。通常，对于同一VLAN，这些链路上可能有不同的指定转发器。在没有抑制的情况下，合并后可能会发生涉及这些VLAN的循环。
Only native frames egressed and ingressed by RBridges are a potential problem. TRILL Data packets are either
只有RBridges进出的本机帧是一个潜在问题。颤音数据包是
1. individually addressed (TRILL Header M bit = 0) and will be ignored if delivered to any incorrect TRILL switch ports or
1. 单独寻址（TRILL报头M位=0），如果发送到任何错误的TRILL交换机端口或
2. multicast (TRILL Header M bit = 1), in which case the Reverse Path Forwarding Check discards any copies delivered to incorrect TRILL switch ports.
2. 多播（TRILL报头M位=1），在这种情况下，反向路径转发检查会丢弃发送到错误TRILL交换机端口的任何副本。
Thus, there is no need for inhibition to affect the sending or receiving of TRILL Data packets, and inhibition does not do so.
因此，不需要抑制来影响TRILL数据分组的发送或接收，并且抑制不这样做。
However, root bridge change inhibition is only needed until TRILL Hellos have been exchanged on the merged bridged LAN. Hellos indicate Appointed Forwarder status and, in general, after an exchange of Hellos the new merged bridged LAN link will, if necessary, be rendered TRILL loop safe by VLAN inhibition so that root bridge change inhibition is no longer needed.
但是，只有在合并的桥接LAN上交换TRILL Hello之前，才需要根网桥更改抑制。Hellos表示指定的转发器状态，通常，在交换Hellos后，新合并的桥接LAN链路（如有必要）将通过VLAN抑制提供TRILL环路安全，因此不再需要根网桥更改抑制。
TRILL switches are required to advertise in their link state the IDs of the root Bridge IDs they can see. If an RBridge port sees a change in root Bridge ID from Root1 to Root2, it is safe to terminate root bridge change inhibition on that port as soon as Hellos have been received on the port from all RBridges that can see Root1 or Root2, except any such RBridge that is no longer reachable.
TRILL开关需要在其链接状态中公布它们可以看到的根网桥ID的ID。如果RBridge端口看到根网桥ID从Root1更改为Root2，则在端口上从所有可以看到Root1或Root2的RBridge接收到Hello后，立即终止该端口上的根网桥更改抑制是安全的，不再可访问的任何此类RBridge除外。
In further detail, when a change from Root1 to Root2 is noticed at a port of RB1, RB1 associates with that port a list of all of the reachable RBridges, other than itself, that had reported in their LSPs that they could see either Root1 or Root2. It then removes from this list any RBridge that becomes unreachable from RB1 or from which it has received a Hello on that port. If there is a subsequent change in root Bridge ID being received before this list is empty, say to Root7, then those RBridges reporting in their LSPs that they can see Root7 are added to the list. Root bridge change inhibition can be terminated for the port as soon as either the timeout is reached or this list of RBridges is empty.
更详细地说，当在RB1的端口处注意到从Root1到Root2的更改时，RB1将所有可到达的RBridge（除了自身）的列表与该端口关联，这些RBridge在其LSP中报告它们可以看到Root1或Root2。然后，它将从该列表中删除从RB1无法访问的任何RBridge，或者从该端口接收到Hello的任何RBridge。如果在该列表为空之前收到根网桥ID的后续更改，比如对Root7，则那些在LSP中报告可以看到Root7的RBridge将添加到列表中。一旦达到超时或此RBridges列表为空，即可终止端口的根网桥更改抑制。
If the optimizations described in Sections 3.2.1 and/or 3.2.2 are in effect at an RBridge port and indicate that no inhibition is needed, then the mechanism described in this section is not needed either.
如果第3.2.1节和/或第3.2.2节中描述的优化在RBridge端口有效，并且表明不需要抑制，则也不需要本节中描述的机制。
If a network manager has sufficient confidence that they know the configuration of bridges, ports, and the like, within an Ethernet link, they may be able to reduce the number of TRILL Hellos sent on that link by sending Hellos in fewer VLANs -- for example, if all TRILL switches on the link will see all Hellos without VLAN constraints. However, because adjacencies are established in the Designated VLAN, an RBridge MUST always attempt to send Hellos in the Designated VLAN.
如果网络管理器有足够的信心知道以太网链路中网桥、端口等的配置，那么他们可能能够通过在更少的VLAN中发送HELO来减少在该链路上发送的TRILL HELO的数量——例如，如果链路上的所有TRILL交换机都将看到所有没有VLAN约束的HELO。但是，由于邻接是在指定的VLAN中建立的，因此RBridge必须始终尝试在指定的VLAN中发送HELOS。
Hello reduction makes TRILL less robust in the face of decreased VLAN connectivity within a link, such as partitioned VLANs, VLANs disabled on ports, or disagreement over the Designated VLAN; however, as long as all RBridge ports on the link are configured for the same Desired Designated VLAN [RFC6325], can see each other's frames in that VLAN, and utilize the mechanisms specified below to update VLAN inhibition timers, operations will be safe. (These considerations
Hello Reduce使TRILL在链路内的VLAN连接减少（如分区VLAN、端口上禁用的VLAN或指定VLAN的分歧）时变得不那么健壮；但是，只要链路上的所有RBridge端口配置为相同的期望指定VLAN[RFC6325]，就可以在该VLAN中看到彼此的帧，并利用下面指定的机制来更新VLAN抑制计时器，操作将是安全的。（b）这些考虑因素
do not arise on links between RBridges that are configured as point to point, since, in that case, each RBridge sends point-to-point Hellos, other TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to be the Designated VLAN of the link (although it may send them untagged) and no native frame end-station service is provided. Thus, for such links, there is no reason to send Hellos in any VLAN other than the Designated VLAN.)
请勿出现在配置为点对点的RBridge之间的链路上，因为在这种情况下，每个RBridge仅在其认为是链路的指定VLAN的位置发送点对点Hello、其他TRILL IS-IS PDU和TRILL数据帧（尽管它可能发送未标记的数据帧），并且不提供本机帧端站服务。因此，对于此类链路，没有理由在指定VLAN以外的任何VLAN中发送HELOS。）
The provision for a configurable set of "Announcing VLANs", as described in Section 4.4.3 of [RFC6325], provides a mechanism in the TRILL base protocol for a reduction in TRILL Hellos.
如[RFC6325]第4.4.3节所述，提供一组可配置的“公布VLAN”，在TRILL基本协议中提供了一种减少TRILL Hello的机制。
To maintain loop safety in the face of occasional lost frames, RBridge failures, link failures, new RBridges coming up on a link, and the like, the inhibition mechanism specified in Section 3 is still required. Strictly following Section 3, a VLAN inhibition timer can only be set by the receipt of a Hello sent or received in that VLAN. Thus, to safely send a reduced number of TRILL Hellos on a reduced number of VLANs requires additional mechanisms to set the VLAN inhibition timers at an RBridge. Two such mechanisms, specified below, expand upon the mechanisms provided in Section 3. Support for both of these mechanisms is indicated by a capability bit in the PORT-TRILL-VER sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe for an RBridge to send TRILL Hellos on fewer VLANs than the set of VLANs recommended in [RFC6325] on a link unless all its adjacencies on that link (excluding those in the Down state [RFC7177]) indicate support of these mechanisms and these mechanisms are in use.
为了在偶尔丢失帧、RBridge故障、链路故障、链路上出现新RBridge等情况下保持环路安全，仍然需要第3节中规定的抑制机制。严格按照第3节的规定，VLAN抑制计时器只能通过接收该VLAN中发送或接收的Hello来设置。因此，为了在数量减少的VLAN上安全地发送数量减少的TRILL Hello，需要在RBridge上设置VLAN抑制计时器的额外机制。下文规定的两种机制在第3节中提供的机制基础上进行了扩展。PORT-TRILL-VER子TLV（RFC7176第5.4节）中的一个能力位表示对这两种机制的支持。如果RBridge在链路上发送的VLAN少于[RFC6325]中建议的VLAN集，则可能不安全，除非该链路上的所有相邻VLAN（不包括处于关闭状态[RFC7177]的VLAN）表明支持这些机制，并且这些机制正在使用。
1. An RBridge RB2 MAY include in any TRILL Hello an Appointed Forwarders sub-TLV [RFC7176] appointing itself for one or more ranges of VLANs. The Appointee Nickname field(s) in the self-appointment Appointed Forwarders sub-TLV MUST be the same as the Sender Nickname in the Special VLANs and Flags sub-TLV in the TRILL Hellos sent by RB2. This indicates that the sending RBridge believes that it is Appointed Forwarder for those VLANs. For each of an RBridge's VLAN inhibition timers for every VLAN in the block or blocks listed in the Appointed Forwarders sub-TLV, the RBridge sets that timer to either (1) its current value or (2) the Holding Time of the Hello containing the sub-TLV, whichever is longer. This is backward compatible. That is, such sub-TLVs will have no effect on any legacy receiving RBridge not implementing this mechanism unless RB2, the sending RBridge, is the DRB sending Hellos on the Designated VLAN. If RB2 is the DRB, it MUST include in the Hello all forwarder appointments, if any, for RBridges other than itself on the link.
1. RBridge RB2可以在任何TRILL Hello中包括指定的转发器子TLV[RFC7176]，该子TLV为一个或多个VLAN范围指定自身。自委任指定转发器子TLV中的被委任者昵称字段必须与RB2发送的TRILL Hello中特殊VLAN和Flags子TLV中的发送者昵称相同。这表示发送RBridge相信它是这些VLAN的指定转发器。对于指定转发器子TLV中列出的块或块中的每个VLAN的RBridge的每个VLAN抑制计时器，RBridge将该计时器设置为（1）其当前值或（2）包含子TLV的Hello的保持时间，以较长者为准。这是向后兼容的。也就是说，这种子TLV不会对任何未实现此机制的传统接收RBridge产生影响，除非发送RBridge的RB2是在指定VLAN上发送HELOS的DRB。如果RB2是DRB，则必须在Hello all forwarder预约中包括RBridges（链接上的RB2除外）的预约（如有）。
2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176]. When RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2 on any VLAN, RB1 updates the VLAN inhibition timers for all the VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is Appointed Forwarder. Each such timer is updated to (1) its current value or (2) the Holding Time of the TRILL Hello containing the VLANs Appointed sub-TLV, whichever is longer. This sub-TLV will be an unknown sub-TLV to RBridges not implementing it, and such RBridges will ignore it. Even if a TRILL Hello sent by the DRB on the Designated VLAN includes one or more VLANs Appointed sub-TLVs, as long as no Appointed Forwarders sub-TLVs appear, the Hello is not required to indicate all forwarder appointments.
2. RBridge可以使用VLAN指定的子TLV[RFC7176]。当RB1从任何VLAN上的RB2接收到TRILL Hello中指定的VLAN子TLV时，RB1更新RB2在该子TLV中列出的所有VLAN的VLAN抑制计时器，作为RB2被指定为转发器的VLAN。每个这样的计时器更新为（1）其当前值或（2）包含VLAN指定子TLV的TRILL Hello的保持时间，以较长者为准。此子TLV将是RBridges未实现的未知子TLV，且此类RBridges将忽略它。即使DRB在指定VLAN上发送的TRILL Hello包括一个或多个VLAN指定的子TLV，只要没有指定的转发器子TLV出现，Hello也不需要指示所有转发器指定。
Two different encodings are provided above to optimize the listing of VLANs. Large blocks of contiguous VLANs are more efficiently encoded with the Appointed Forwarders sub-TLV, and scattered VLANs are more efficiently encoded with the VLANs Appointed sub-TLV. These encodings may be mixed in the same Hello. The use of these sub-TLVs does not affect the requirement that the AF bit in the Special VLANs and Flags sub-TLV MUST be set if the originating RBridge believes that it is Appointed Forwarder for the VLAN in which the Hello is sent.
上面提供了两种不同的编码来优化VLAN列表。使用指定的转发器子TLV对大块连续VLAN进行更有效的编码，使用VLAN指定的子TLV对分散的VLAN进行更有效的编码。这些编码可以在同一个Hello中混合使用。如果发起RBridge认为其是发送Hello的VLAN的指定转发器，则这些子TLV的使用不影响必须设置特殊VLAN和标志子TLV中的AF位的要求。
If the above mechanisms are used on a link, then each RBridge on the link MUST send Hellos in one or more VLANs with such VLANs Appointed sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s), and the AF bit is appropriately set such that no VLAN inhibition timer will improperly expire unless three or more Hellos are lost. For example, an RBridge could announce all VLANs for which it believes that it is Appointed Forwarder in a Hello sent on the Designated VLAN three times per Holding Time.
如果在链路上使用上述机制，则链路上的每个RBridge必须使用指定的VLAN子TLV和/或自指定的转发器子TLV在一个或多个VLAN中发送HELLO，并且AF位被适当地设置为，除非丢失三个或更多HELLO，否则VLAN抑制计时器不会不正确地过期。例如，RBridge可以在指定VLAN上的Hello中宣布其认为是指定转发器的所有VLAN，每个等待时间三次。
A TRILL switch may have multiple ports on the same link. Some of these ports may be suspended due to MAC address duplication, as described in [RFC7177]. Suspended ports never ingress or egress native frames.
TRILL交换机在同一链路上可能有多个端口。如[RFC7177]所述，其中一些端口可能由于MAC地址重复而挂起。挂起的端口从不进出本机帧。
If a TRILL switch has one or more non-suspended ports on a link and those ports offer end-station service -- that is, those ports are not configured as point-to-point or trunk ports -- then that TRILL switch is eligible to be an Appointed Forwarder for that link. It can become Appointed Forwarder in the ways discussed in Section 2.
如果TRILL交换机在链路上有一个或多个非挂起端口，并且这些端口提供端站服务（即，这些端口未配置为点到点或中继端口），则该TRILL交换机有资格成为该链路的指定转发器。它可以按照第2节讨论的方式成为指定的货运代理。
If a TRILL switch that is the Appointed Forwarder for VLAN-x on a link has multiple non-suspended ports on that link, it may load-share the task of ingressing and egressing VLAN-x native frames across those ports however it chooses, as long as there is no case in which a frame it egresses onto the link from one port can be ingressed on another one of its ports, creating a loop. If the TRILL switch is the Appointed Forwarder for multiple VLANs, a straightforward thing to do would be to partition those VLANs among the ports it has on the link.
如果作为链路上VLAN-x的指定转发器的TRILL交换机在该链路上具有多个非挂起端口，则它可能会在这些端口上以其选择的方式加载和共享VLAN-x本机帧的进出任务，只要不存在从一个端口进入链路的帧可以进入其另一个端口的情况，就可以创建循环。如果TRILL交换机是多个VLAN的指定转发器，那么一个简单的方法就是将这些VLAN划分到它在链路上拥有的端口中。
A TRILL switch may note that one of its ports has failed, or it may be about to shut down that port. If the port is on a link along with ports of other TRILL switches, those TRILL switches will not notice the port shutdown or failure using TRILL base protocol mechanisms until there is a failure to receive a number of Hellos from that port. This can take many seconds. Network topology (adjacencies) and forwarder appointments can react more rapidly to port shutdown or failure through explicit notification. As discussed below, this notification SHOULD be provided through the Port-Shutdown message.
TRILL交换机可能会注意到其一个端口出现故障，或者即将关闭该端口。如果端口与其他TRILL交换机的端口一起位于链路上，则这些TRILL交换机不会使用TRILL基本协议机制注意到端口关闭或故障，直到无法从该端口接收大量Hello。这可能需要很多秒。网络拓扑（邻接）和转发器预约可以通过显式通知对端口关闭或故障做出更快的反应。如下所述，应通过端口关闭消息提供此通知。
A TRILL switch that is shutting down one of its ports (say P1) soon SHOULD reduce its Holding Time on that port, so that the shutdown will be more rapidly noticed by adjacent RBridges that might not support the Port-Shutdown message.
即将关闭其一个端口（如P1）的TRILL交换机应缩短其在该端口上的保持时间，以便可能不支持端口关闭消息的相邻RBridge能够更快地注意到关闭。
The Port-Shutdown message is an RBridge Channel message [RFC7178] using RBridge Channel Protocol number 0x006. The payload specific to the Channel Protocol consists of a list of Port IDs (see Section 4.4.2 of [RFC6325]) for the port or ports that have failed or are being shut down, as shown in the diagram below. Support for the Port-Shutdown message is advertised by simply advertising support for its RBridge Channel Protocol in the RBridge Channel Protocols sub-TLV [RFC7176].
端口关闭消息是使用RBridge通道协议号0x006的RBridge通道消息[RFC7178]。信道协议特定的有效负载包括一个端口ID列表（见[RFC6325]第4.4.2节），用于已发生故障或正在关闭的一个或多个端口，如下图所示。仅通过在RBRIGE信道协议子TLV[RFC7176]中公布对其RBRIGE信道协议的支持，即可公布对端口关闭消息的支持。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA (cont.) | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype=0x8100 | Priority=7, DEI=0, VLAN ID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=0x006|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the Port-Shutdown Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID K |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA (cont.) | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype=0x8100 | Priority=7, DEI=0, VLAN ID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=0x006|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the Port-Shutdown Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID K |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For robustness, a TRILL switch sends a configurable number of copies of Port-Shutdown messages separated by a configurable time interval. The default number of copies is two, although this can be configured as one copy or as three copies, and the default interval is 20 milliseconds (see Section 6.6). As with any "adjacency critical" message, the Port-Shutdown message SHOULD be sent with the highest priority, which is priority 7, and SHOULD NOT be marked as "drop eligible".
为了保证健壮性，TRILL交换机发送可配置数量的端口关闭消息副本，这些副本由可配置的时间间隔分隔。默认副本数为两份，但可以配置为一份或三份，默认间隔为20毫秒（见第6.6节）。与任何“邻接关键”消息一样，端口关闭消息应以最高优先级发送，即优先级7，并且不应标记为“符合丢弃条件”。
If a failure of port P1 on RBridge RB2 is detected by RB2, then the Port-Shutdown message announcing this failure is sequentially unicast through the rest of the TRILL campus to all RBridges (1) with which P1 had an adjacency and (2) that are advertising support for the Port-Shutdown RBridge Channel Protocol.
如果RB2检测到RBridge RB2上的端口P1出现故障，则宣布此故障的端口关闭消息将通过TRILL园区的其余部分依次单播到所有RBridge（1），P1与这些RBridge（2）具有邻接关系，并且（1）正在宣传对端口关闭RBridge通道协议的支持。
If a port shutdown is planned within 1 second, then the TRILL switch ceases to send Hellos out of the port being shut down and either (1) sends the Port-Shutdown message to RBridge ports on the link advertising support of the Port-Shutdown RBridge Channel Protocol or (2) broadcasts the Port-Shutdown message announcing this event through the port as follows:
如果计划在1秒内关闭端口，则TRILL交换机停止从正在关闭的端口发送Hello，并且（1）在端口关闭RBridge通道协议的链接广告支持上向RBridge端口发送端口关闭消息，或者（2）通过端口广播端口关闭消息，宣布此事件，如下所示：
- The Outer.MacDA is the All-RBridges multicast address.
- Outer.MacDA是所有RBridges多播地址。
- If an outer VLAN tag is present, it specifies the Designated VLAN for the link, SHOULD specify priority 7, and SHOULD NOT specify "drop eligible".
- 如果存在外部VLAN标记，则它将指定链路的指定VLAN，应指定优先级7，而不应指定“符合删除条件”。
- In the TRILL Header, the egress nickname is All-RBridges, and the M bit in the TRILL Header is set to 0.
- 在TRILL报头中，出口昵称为All RBridges，TRILL报头中的M位设置为0。
- In the RBridge Channel Header, the MH and NA bits are zero.
- 在RBridge信道报头中，MH和NA位为零。
There is no need for a special message to indicate that a port P1 has come back up or that a shutdown has been "canceled". This is indicated by simply sending Hellos out of port P1.
不需要特殊消息来指示端口P1已恢复或关机已“取消”。这通过简单地从端口P1发送Hello来表示。
When a TRILL switch RB1 receives a Port-Shutdown message, RB1 checks to see if the ingress nickname specifies some TRILL switch RB2 with which RB1 has one or more adjacencies. If so, it drops those adjacencies that are to RB2 ports whose Port IDs are listed in the Port-Shutdown message. There could be more than one if RB2 had multiple ports on the link that are going down.
当颤音开关RB1收到端口关闭消息时，RB1检查入口昵称是否指定某个颤音开关RB2，RB1与该颤音开关RB2有一个或多个邻接。如果是这样，它将删除那些与RB2端口相邻的端口，这些端口的端口ID在端口关闭消息中列出。如果RB2在链路上有多个正在关闭的端口，则可能会有多个端口。
If RB1 is the DRB and this eliminates all adjacencies on a link between the DRB and RB2, then, for all VLANs whose ingress/egress was being handled by RB2, the DRB either starts acting as Appointed Forwarder or appoints some new TRILL switch with which it has adjacency as Appointed Forwarder.
如果RB1是DRB，这消除了DRB和RB2之间链路上的所有邻接，那么，对于其入口/出口由RB2处理的所有VLAN，DRB要么开始充当指定的转发器，要么指定一些新的TRILL交换机作为指定的转发器与其邻接。
Port-Shutdown messages can be secured through the use of the RBridge Channel Header Extension security feature [RFC7978].
端口关闭消息可以通过使用RBridge通道头扩展安全功能[RFC7978]进行保护。
There are two Port-Shutdown configuration parameters, as listed below. Section 6.3 provides details regarding their use.
有两个端口关闭配置参数，如下所示。第6.3节提供了有关其使用的详细信息。
Parameter Default Range
--------------- ---------------- ---------------------
PShutdownRepeat 2 1-3
PShutdownDelay 20 milliseconds 0-1,000 milliseconds
Parameter Default Range
--------------- ---------------- ---------------------
PShutdownRepeat 2 1-3
PShutdownDelay 20 milliseconds 0-1,000 milliseconds
TRILL switches support 24-bit Fine-Grained Labels as specified in [RFC7172]. Basically, a VLAN ID in native traffic between an edge TRILL switch and an end station is mapped from/to an FGL as an Inner.Label in TRILL Data packets. Since the Appointed Forwarder for a VLAN will be ingressing and egressing such native traffic, the mapping configured at the Appointed Forwarder is the mapping performed.
TRILL交换机支持[RFC7172]中指定的24位细粒度标签。基本上，边缘TRILL交换机和终端站之间的本机流量中的VLAN ID作为TRILL数据包中的内部.Label从FGL映射到FGL。由于VLAN的指定转发器将进出此类本机流量，因此在指定转发器处配置的映射是执行的映射。
However, the Appointed Forwarder for VLAN-x on a link can change for reasons discussed elsewhere in this document. Thus, all TRILL switches on a link that are configured with an FGL-VLAN mapping SHOULD be configured with the same mapping. Otherwise, traffic might unpredictably jump from one FGL to another when the Appointed Forwarder changes. TRILL switches SHOULD advertise their mapping on the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs (Sections 10.4 and 10.5) so that consistency checking can be automated.
但是，链路上VLAN-x的指定转发器可能会因本文档其他部分讨论的原因而更改。因此，链路上配置FGL-VLAN映射的所有TRILL交换机都应配置相同的映射。否则，当指定的转发器发生变化时，流量可能会不可预测地从一个FGL跳到另一个FGL。TRILL交换机应使用FGL VLAN位图和FGL VLAN对APPsub TLV（第10.4节和第10.5节）在链路上公布其映射，以便能够自动进行一致性检查。
A TRILL switch SHOULD compare the FGL-VLAN mappings that it sees advertised by other TRILL switches on a link with its own and alert the network operator if they are inconsistent. "Inconsistent" means that (1) one TRILL switch maps FGL-z to VLAN-x while another maps FGL-z to VLAN-y or (2) one TRILL switch maps VLAN-x to FGL-w while another maps VLAN-x to FGL-z, all on the same link.
TRILL交换机应将其在链路上看到的其他TRILL交换机公布的FGL-VLAN映射与其自己的映射进行比较，并在不一致时向网络运营商发出警报。“不一致”是指（1）一个TRILL交换机将FGL-z映射到VLAN-x，而另一个将FGL-z映射到VLAN-y；或（2）一个TRILL交换机将VLAN-x映射到FGL-w，而另一个将VLAN-x映射到FGL-z，所有这些都位于同一链路上。
Depending on how the network is being managed, a transient inconsistency may not be a problem. Thus, the network operator SHOULD NOT be alerted unless the inconsistency persists for a period of time that defaults to the TRILL switch's Holding Time and is configurable to between 0 seconds and 2**16 - 1 seconds, where 2**16 - 1 is a special value and indicates that such alerts are disabled.
根据网络的管理方式，暂时的不一致性可能不是问题。因此，除非不一致性持续一段时间（默认为颤音开关的保持时间）且可配置为0秒到2**16-1秒之间，否则不应向网络运营商发出警报，其中2**16-1是一个特殊值，表示此类警报已禁用。
All TRILL switches MUST support the E-L1CS flooding scope [RFC7356], Extended Level 1 Flooding Scope (E-L1FS) [RFC7780], and base LSPs [IS-IS]. It will be apparent to any TRILL switch on a link if any other TRILL switch on the link is a legacy implementation not supporting E-L1CS because, as stated in [RFC7780], all TRILL switches MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send. This support of E-L1CS increases the amount of information from each TRILL switch that can be synchronized on the link, compared with the information capacity of Hellos, by several orders of magnitude.
所有TRILL交换机必须支持E-L1CS泛洪范围[RFC7356]、扩展的1级泛洪范围（E-L1FS）[RFC7780]和基本LSP[IS-IS]。如果链路上的任何其他TRILL交换机是不支持E-L1C的遗留实现，则链路上的任何TRILL交换机都会很明显，因为如[RFC7780]中所述，所有TRILL交换机必须在其发送的所有TRILL Hello中包括作用域泛洪支持TLV[RFC7356]。与Hellos的信息容量相比，E-L1CS的支持将链路上每个颤音开关可同步的信息量增加了几个数量级。
For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs (Flooding Scope Complete Sequence Number PDUs) [RFC7356], and E-L1CS FS-PSNPs (Flooding Scope Partial Sequence Number PDUs) [RFC7356]) MUST NOT exceed 1,470 bytes in length; however, any such E-L1CS PDU that is received that is longer than 1,470 bytes is processed normally.
为确保健壮性，E-L1CS PDU（FS-LSP片段、E-L1CS FS CSNPs（泛洪作用域完整序列号PDU）[RFC7356]和E-L1CS FS PSNPs（泛洪作用域部分序列号PDU）[RFC7356]）的长度不得超过1470字节；然而，正常处理接收到的超过1470字节的任何此类E-L1CS PDU。
As with any type of IS-IS LSP, FS-LSPs are identified by the System ID of the originating router (TRILL switch) and the fragment number. In particular, there is no port identifier in the header of an E-L1CS PDU. Thus, a TRILL switch RB1 with more than one non-suspended port on a link (Section 5) transmitting such a PDU MAY transmit it out of any one or more of such ports. RB1 will generally receive such a PDU that other TRILL switches send on all of RB1's ports on the link. In addition, with multiple ports on the link, it will receive any such PDU that it sends on the ports it has on the link other than the transmitting port.
与任何类型的IS-IS LSP一样，FS LSP由发起路由器（TRILL交换机）的系统ID和片段号标识。特别是，E-L1CS PDU的报头中没有端口标识符。因此，在发送这样的PDU的链路（部分5）上具有多个非挂起端口的TRILL交换机RB1可以从任何一个或多个这样的端口将其发送出去。RB1通常会收到其他TRILL交换机在链路上所有RB1端口上发送的PDU。此外，当链路上有多个端口时，它将接收它在链路上的端口上发送的任何此类PDU，而不是发送端口。
Future TRILL specifications making use of E-L1CS MUST specify how situations involving a TRILL link will be handled when one or more TRILL switches attached to that link support E-L1CS and one or more do not.
未来使用E-L1C的颤音规范必须规定当连接到颤音链路的一个或多个颤音交换机支持E-L1C而一个或多个不支持E-L1C时，涉及颤音链路的情况将如何处理。
This document provides improved documentation of the TRILL Appointed Forwarder mechanism. It does not change the security considerations of the TRILL base protocol as described in Section 6 of [RFC6325].
本文件提供了TRILL指定货运代理机制的改进文件。它不会改变[RFC6325]第6节中描述的TRILL base协议的安全注意事项。
The Port-Shutdown messages specified in Section 6 are sent using the RBridge Channel facility [RFC7178]. Such messages SHOULD be secured through the use of the RBridge Channel Header Extension [RFC7978]. If they are not adequately secured, they are a potential denial-of-service vector.
第6节中指定的端口关闭消息使用RBridge通道设施[RFC7178]发送。此类消息应通过使用RBridge通道头扩展[RFC7978]进行保护。如果它们没有足够的安全性，那么它们就是一个潜在的拒绝服务载体。
The E-L1CS FS-LSPs added by Section 8 are a type of IS-IS PDU [RFC7356]. As such, they are securable through the addition of Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs.
第8节添加的E-L1CS FS LSP是IS-IS PDU的一种类型[RFC7356]。因此，通过添加身份验证TLV[RFC5310]，它们与Hellos或其他IS-IS PDU一样安全。
This section provides IANA considerations for this document and specifies the structures of the AppointmentBitmap, AppointmentList, VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs. These APPsub-TLVs appear within a TRILL GENINFO TLV [RFC7357] in E-L1CS FS-LSPs [RFC7356].
本节提供了本文档的IANA注意事项，并指定了AppointBitmap、AppointList、VLAN-FGL映射位图和VLAN-FGL映射对APPsub TLV的结构。这些APPsub TLV出现在E-L1CS FS LSP[RFC7356]中的TRILL GENINFO TLV[RFC7357]中。
IANA has assigned four new APPsub-TLV type codes from the range below 255 and entered them in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry as follows:
IANA从255以下的范围分配了四个新的APPsub TLV类型代码，并将其输入到“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表中，如下所示：
Type Name Reference
---- ----------------- ---------
17 AppointmentBitmap [RFC8139]
18 AppointmentList [RFC8139]
19 FGL-VLAN-Bitmap [RFC8139]
20 FGL-VLAN-Pairs [RFC8139]
Type Name Reference
---- ----------------- ---------
17 AppointmentBitmap [RFC8139]
18 AppointmentList [RFC8139]
19 FGL-VLAN-Bitmap [RFC8139]
20 FGL-VLAN-Pairs [RFC8139]
IANA has assigned a new RBridge Channel Protocol number in the range assigned by Standards Action [RFC5226] and updated the "RBridge Channel Protocols" registry as follows:
IANA已在标准行动[RFC5226]分配的范围内分配了一个新的RBridge信道协议号，并更新了“RBridge信道协议”注册表，如下所示：
Protocol Description Reference
-------- -------------- ---------
0x006 Port-Shutdown [RFC8139]
Protocol Description Reference
-------- -------------- ---------
0x006 Port-Shutdown [RFC8139]
IANA has updated the reference for the "Hello reduction support" bit in the "PORT-TRILL-VER Sub-TLV Capability Flags" registry to refer to this document.
IANA已更新了“PORT-TRILL-VER Sub-TLV能力标志”注册表中“Hello reduction support”位的参考，以参考本文档。
The AppointmentBitmap APPsub-TLV provides an efficient method for a TRILL switch to indicate which TRILL switches it appoints as forwarders for which VLAN IDs when those VLAN IDs are relatively compact (that is, they do not span a large numeric range). Such an appointment is only effective when the appointing TRILL switch is the DRB.
AppointmentBitmap APPsub TLV为TRILL交换机提供了一种有效的方法，当这些VLAN ID相对紧凑时（即，它们不跨越较大的数字范围），它可以指示指定哪些TRILL交换机作为VLAN ID的转发器。此类任命仅在任命TRILL开关为DRB时有效。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
o Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV 17.
o 类型：APPsub TLV类型，设置为AppointmentBitmap sub TLV 17。
o Length: 4 + size of bit map in bytes. If Length is less than 4, the APPsub-TLV is corrupt and MUST be ignored.
o 长度：4+位映射的大小（字节）。如果长度小于4，则APPsub TLV已损坏，必须忽略。
o Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder.
o 被任命人昵称：被任命为货运代理的TRILL switch的昵称。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV:4位，必须作为零发送，并在接收时忽略。
o Starting VLAN ID: The smallest VLAN ID to which the bits in the Bit Map correspond.
o 起始VLAN ID：位图中的位对应的最小VLAN ID。
o Bit Map: A bit map of the VLANs for which the TRILL switch with Appointee Nickname is appointed as the forwarder. The size of the bit map is length minus 4. If the size of the bit map is zero, no appointments are made.
o 位图：VLAN的位图，具有指定者昵称的TRILL交换机被指定为该VLAN的转发器。位图的大小为长度减4。如果位图的大小为零，则不进行预约。
Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field. Bit 1 is for that VLAN ID plus 1 (treating VLAN IDs as unsigned integers) and so on, with Bit N generally being Starting VLAN ID plus N. VLAN 0x000 and VLAN 0xFFF, or any larger ID, are invalid and are ignored.
位图中的每一位都对应一个VLAN ID。位0表示ID出现在起始VLAN ID字段中的VLAN。位1表示VLAN ID加1（将VLAN ID视为无符号整数）等等，位N通常表示起始VLAN ID加N。VLAN 0x000和VLAN 0xFFF或任何更大的ID无效，将被忽略。
If the AppointmentBitmap APPsub-TLV is originated by the DRB on a link, it appoints the TRILL switch whose nickname appears in the Appointee Nickname field for the VLAN IDs corresponding to 1 bits in the Bit Map and revokes any Hello appointment of that TRILL switch for VLANs corresponding to 0 bits in the Bit Map.
如果指定位图APPsub TLV是由DRB在链路上发起的，它将为对应于位图中1位的VLAN ID指定其昵称出现在指定者昵称字段中的TRILL交换机，并撤销对应于位图中0位的VLAN的该TRILL交换机的任何Hello指定。
The AppointmentList APPsub-TLV provides a convenient method for a TRILL switch to indicate which TRILL switches it appoints as forwarders for which VLAN IDs. Such an appointment is only effective when the appointing TRILL switch is the DRB.
AppointmentList APPsub TLV为TRILL交换机提供了一种方便的方法，用于指示它指定哪些TRILL交换机作为VLAN ID的转发器。此类任命仅在任命TRILL开关为DRB时有效。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID k | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID k | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: APPsub-TLV type, set to AppointmentList sub-TLV 18.
o 类型：APPsub TLV类型，设置为AppointList sub TLV 18。
o Length: 2 + 2 * k. If Length is not an even number, the APPsub-TLV is corrupt and MUST be ignored.
o 长度：2+2*k。如果长度不是偶数，则APPsub TLV已损坏，必须忽略。
o Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder.
o 被任命人昵称：被任命为货运代理的TRILL switch的昵称。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV:4位，必须作为零发送，并在接收时忽略。
o VLAN ID: A 12-bit VLAN ID for which the appointee is being appointed as the forwarder.
o VLAN ID：一个12位VLAN ID，被指定者被指定为转发器。
Type and Length are 2 bytes, because these are extended FS-LSPs.
类型和长度为2字节，因为它们是扩展的FS LSP。
This APPsub-TLV, when originated by the DRB, appoints the TRILL switch with Appointee Nickname to be the Appointed Forwarder for the VLAN IDs listed.
当DRB发起此APPsub TLV时，指定具有指定者昵称的TRILL交换机作为所列VLAN ID的指定转发器。
The FGL-VLAN-Bitmap APPsub-TLV provides a method for a TRILL switch to indicate mappings of FGLs to VLAN IDs that it is configured to perform when egressing and ingressing native frames.
FGL VLAN位图APPsub TLV为TRILL交换机提供了一种方法，用于指示FGL到VLAN ID的映射，该映射配置为在退出和进入本机帧时执行。
The coding is efficient when both of the following apply:
当以下两项都适用时，编码是有效的：
- the VLAN IDs are compact (that is, they do not span a large numeric range), and
- VLAN ID是紧凑的（也就是说，它们不跨越大的数字范围），并且
- the FGLs and VLAN IDs are paired in a monotonically increasing fashion.
- FGLs和VLAN ID以单调递增的方式配对。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
o Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV 19.
o 类型：APPsub TLV类型，设置为VLAN FGL位图sub TLV 19。
o Length: 5 + size of bit map in bytes. If Length is less than 5, the APPsub-TLV is corrupt and MUST be ignored.
o 长度：5+位映射的大小（字节）。如果长度小于5，则APPsub TLV已损坏，必须忽略。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV:4位，必须作为零发送，并在接收时忽略。
o Starting VLAN ID: Initial VLAN ID for the mapping information as discussed below.
o Starting VLAN ID：映射信息的初始VLAN ID，如下所述。
o Starting FGL: Fine-Grained Label [RFC7172].
o 启动FGL：细粒度标签[RFC7172]。
o Bit Map: Map of bits for VLAN-ID-to-FGL mappings. The size of the bit map is Length minus 5. If the size of the bit map is zero, no mappings are indicated.
o 位映射：VLAN ID到FGL映射的位映射。位图的大小为长度减5。如果位图的大小为零，则不指示任何映射。
Each bit in the Bit Map corresponds to a VLAN ID and to an FGL. Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field and the Fine-Grained Label that appears in the FGL field. Bit 1 is for that VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and FGLs as unsigned integers) and so on, with Bit N generally being Starting VLAN ID plus N and FGL plus N.
位图中的每一位都对应一个VLAN ID和一个FGL。位0表示ID出现在起始VLAN ID字段中的VLAN和出现在FGL字段中的细粒度标签。位1表示VLAN ID加1和FGL加1（将VLAN ID和FGL视为无符号整数），以此类推，位N通常表示起始VLAN ID加N和FGL加N。
If a Bit Map bit is a 1, it indicates that the advertising TRILL switch will map between the corresponding VLAN ID and FGL on ingressing native frames and egressing TRILL Data packets if it is Appointed Forwarder for the VLAN. If a Bit Map bit is a 0, it does not indicate any configured mapping of the VLAN ID to the FGL. However, VLAN ID 0x000 and VLAN ID 0xFFF or any larger ID are invalid, and FGLs larger than 0xFFFFFF are invalid; any Bit Map bits that correspond to an illegal VLAN ID or an illegal FGL are ignored.
如果位图位为1，则表示播发颤音交换机将在输入本机帧和输出颤音数据包（如果为VLAN指定转发器）上的相应VLAN ID和FGL之间进行映射。如果位图位为0，则不表示VLAN ID到FGL的任何配置映射。但是，VLAN ID 0x000和VLAN ID 0xFFF或任何更大的ID无效，大于0xFFFFFF的FGL无效；与非法VLAN ID或非法FGL对应的任何位图位都将被忽略。
The FGL-VLAN-Pairs APPsub-TLV provides a method for a TRILL switch to indicate a list of the mappings of FGLs to VLAN IDs that it is configured to perform when egressing and ingressing native frames.
FGL VLAN Pairs APPsub TLV为TRILL交换机提供了一种方法，用于指示FGL到VLAN ID的映射列表，该列表配置为在退出和进入本机帧时执行。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 1 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 2 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD k | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 1 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 2 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD k | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
Where a Mapping RECORD has the following structure:
其中映射记录具有以下结构：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV 20.
o 类型：APPsub TLV类型，设置为VLAN FGL Pairs sub TLV 20。
o Length: 5 * k. If Length is not a multiple of 5, the APPsub-TLV is corrupt and MUST be ignored.
o 长度：5*k。如果长度不是5的倍数，则APPsub TLV已损坏，必须忽略。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV:4位，必须作为零发送，并在接收时忽略。
o VLAN ID: 12-bit VLAN label.
o VLAN ID：12位VLAN标签。
o FGL: Fine-Grained Label [RFC7172].
o FGL：细粒度标签[RFC7172]。
Each Mapping RECORD indicates that the originating TRILL switch is configured to map between the FGL and VLAN given on egressing and ingressing native frames. However, VLAN ID 0x000 and VLAN ID 0xFFF are invalid; any Mapping RECORD that corresponds to an illegal VLAN ID is ignored.
每个映射记录都表明，原始TRILL交换机被配置为在FGL和VLAN之间进行映射，这两个VLAN是在出入口本机帧上给出的。但是，VLAN ID 0x000和VLAN ID 0xFFF无效；与非法VLAN ID对应的任何映射记录都将被忽略。
This document primarily adds optional enhancements or optimizations. The only configuration parameters specified in this document are the number and frequency of copies of Port-Shutdown messages sent, as specified in Section 6.6.
本文档主要添加可选的增强或优化。本文件中规定的唯一配置参数是第6.6节规定的发送端口关闭消息副本的数量和频率。
TRILL switch support of SNMPv3 is provided in the TRILL base protocol document [RFC6325]. MIBs have been specified in [RFC6850] and [RFC7784], but they do not include the configurable parameters specified herein. It is anticipated that YANG modules will be specified for TRILL.
TRILL基本协议文档[RFC6325]中提供了SNMPv3的TRILL交换机支持。MIB已在[RFC6850]和[RFC7784]中指定，但它们不包括此处指定的可配置参数。预计将为TRILL指定YANG模块。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE Std 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, <http://ieeexplore.ieee.org/ servlet/opac?punumber=6991460>.
[802.1Q]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，IEEE标准802.1Q-2014，DOI 10.1109/ieeestd.2014.6991462<http://ieeexplore.ieee.org/ servlet/opac？punumber=6991460>。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", November 2002.
[IS-IS]ISO/IEC 10589:2002，第二版，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由交换协议（ISO 8473）”，2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<http://www.rfc-editor.org/info/rfc6325>.
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>.
[RFC6329]Fedyk，D.，Ed.，Ashwood Smith，P.，Ed.，Allan，D.，Bragg，A.，和P.Unbehagen，“支持IEEE 802.1aq最短路径桥接的IS-IS扩展”，RFC 6329，DOI 10.17487/RFC6329，2012年4月<http://www.rfc-editor.org/info/rfc6329>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（颤音）：邻接”，RFC 7177，DOI 10.17487/RFC7177，2014年5月<http://www.rfc-editor.org/info/rfc7177>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge通道支持”，RFC 7178，DOI 10.17487/RFC7178，2014年5月<http://www.rfc-editor.org/info/rfc7178>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<http://www.rfc-editor.org/info/rfc7356>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<http://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<http://www.rfc-editor.org/info/rfc7780>.
[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <http://www.rfc-editor.org/info/rfc7978>.
[RFC7978]Eastlake 3rd，D.，Umair，M.，和Y.Li，“大量链路的透明互连（TRILL）：RBridge信道头扩展”，RFC 7978，DOI 10.17487/RFC7978，2016年9月<http://www.rfc-editor.org/info/rfc7978>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <http://www.rfc-editor.org/info/rfc7981>.
[RFC7981]Ginsberg，L.，Previdi，S.，和M.Chen，“广告路由器信息的IS-IS扩展”，RFC 7981，DOI 10.17487/RFC7981，2016年10月<http://www.rfc-editor.org/info/rfc7981>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 5310，DOI 10.17487/RFC5310，2009年2月<http://www.rfc-editor.org/info/rfc5310>.
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 6439，DOI 10.17487/RFC6439，2011年11月<http://www.rfc-editor.org/info/rfc6439>.
[RFC6850] Rijhsinghani, A. and K. Zebrose, "Definitions of Managed Objects for Routing Bridges (RBridges)", RFC 6850, DOI 10.17487/RFC6850, January 2013, <http://www.rfc-editor.org/info/rfc6850>.
[RFC6850]Rijhsinghani，A.和K.Zebrose，“路由桥（RBridges）管理对象的定义”，RFC 6850，DOI 10.17487/RFC6850，2013年1月<http://www.rfc-editor.org/info/rfc6850>.
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>.
[RFC7379]Li，Y.，Hao，W.，Perlman，R.，Hudson，J.，和H.Zhai，“大量链路透明互连（TRILL）边缘主动连接的问题陈述和目标”，RFC 7379，DOI 10.17487/RFC7379，2014年10月<http://www.rfc-editor.org/info/rfc7379>.
[RFC7784] Kumar, D., Salam, S., and T. Senevirathne, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB", RFC 7784, DOI 10.17487/RFC7784, February 2016, <http://www.rfc-editor.org/info/rfc7784>.
[RFC7784]Kumar，D.，Salam，S.，和T.Senevirathne，“大量链路（TRILL）运行、管理和维护（OAM）MIB的透明互连”，RFC 7784，DOI 10.17487/RFC7784，2016年2月<http://www.rfc-editor.org/info/rfc7784>.
The per-VLAN inhibition timers (or the equivalent) are needed to be loop safe in the case of misconfigured bridges on a link.
当链路上的网桥配置错误时，每VLAN抑制定时器（或等效定时器）需要是环路安全的。
For a simple example, assume that RB1 and RB2 are the only RBridges on the link, that RB1 is higher priority to be the DRB, and that they both want VLAN 1 (the default) to be the Designated VLAN. However, there is a bridge between them configured so that RB1 can see all the frames sent by RB2 but none of the frames from RB1 can get through to RB2.
对于一个简单的示例，假设RB1和RB2是链路上唯一的RBridge，RB1作为DRB具有更高的优先级，并且它们都希望VLAN 1（默认值）作为指定的VLAN。但是，它们之间有一个桥接器，配置为RB1可以看到RB2发送的所有帧，但RB1的所有帧都无法通过RB2。
Both will think they are the DRB: RB1 because it is higher priority even though it sees the Hellos from RB2, and RB2 because it doesn't see the Hellos from RB1 and therefore thinks it is highest priority.
两者都会认为它们是DRB:RB1，因为它的优先级更高，即使它从RB2看到Hello，而RB2，因为它没有从RB1看到Hello，因此认为它是最高优先级。
Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There is no problem with VLANs 2 and 4, but if you do not do something about it, you could have a loop involving VLAN 3. RB1 will see the Hellos that RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1 will be inhibited on VLAN 3. RB2 does not see the Hellos issued by RB1 on VLAN 3, so RB2 will become uninhibited and will handle VLAN 3 native traffic.
假设RB1选择作为VLAN 2和3的指定转发器，而RB2选择作为VLAN 3和4的指定转发器。VLAN2和VLAN4没有问题，但如果您不采取措施，可能会有一个涉及VLAN3的循环。RB1将看到RB2在VLAN 3上发出的Hello，并声明自己为指定转发器，因此RB1将在VLAN 3上被禁止。RB2看不到RB1在VLAN 3上发出的Hello，因此RB2将变得不受限制，并将处理VLAN 3本机流量。
However, this situation may change. RB2 might crash, the bridge might crash, RB2 might be reconfigured so it no longer tried to act as Appointed Forwarder for VLAN 3, or other issues may occur. So, RB1 has to maintain a VLAN 3 inhibition timer, and if it sees no Hellos from any other RBridge on the link claiming to be Appointed Forwarder for VLAN 3 for a long enough time, then RB1 becomes uninhibited for that VLAN on the port in question and can handle end-station traffic in VLAN 3.
然而，这种情况可能会改变。RB2可能会崩溃，网桥可能会崩溃，RB2可能会重新配置，以便不再尝试充当VLAN 3的指定转发器，或者可能会发生其他问题。因此，RB1必须维护一个VLAN 3抑制计时器，如果在足够长的时间内，它在链路上没有看到任何其他RBridge声称为VLAN 3指定的转发器，则RB1对所述端口上的该VLAN不受限制，并且可以处理VLAN 3中的端站流量。
Assume that RBridges RB1 and RB2 have ports P1 and P2, respectively, that are both on Link L1 and that RBridges RB3 and RB4 have ports P3 and P4, respectively, that are both on Link L2. Assume further that P1 and P3 are Appointed Forwarders for VLAN-x and P2 and P4 are Appointed Forwarders for VLAN-y. This situation is shown in the figure below.
假设RBridges RB1和RB2分别具有端口P1和P2，它们都位于链路L1上，RBridges RB3和RB4分别具有端口P3和P4，它们都位于链路L2上。进一步假设P1和P3是VLAN-x的指定转发器，P2和P4是VLAN-y的指定转发器。这种情况如下图所示。
+ - - - - - - - - - - - - - - - - - - - - - +
| |
| TRILL network |
| |
| +---+ +---+ +---+ +---+ |
+ -|RB1|- -|RB2|- - - - - - -|RB3|- -|RB4|- +
+---+ +---+ +---+ +---+
P1| P2| P3| P4|
| | | |
|x |y |x |y
| +-+ | | +-+ |
L1 ---+---|M|---+--+--- L2 ---+---|M|---+---
+-+ | +-+
+---+
|ES1|
+---+
+ - - - - - - - - - - - - - - - - - - - - - +
| |
| TRILL network |
| |
| +---+ +---+ +---+ +---+ |
+ -|RB1|- -|RB2|- - - - - - -|RB3|- -|RB4|- +
+---+ +---+ +---+ +---+
P1| P2| P3| P4|
| | | |
|x |y |x |y
| +-+ | | +-+ |
L1 ---+---|M|---+--+--- L2 ---+---|M|---+---
+-+ | +-+
+---+
|ES1|
+---+
Further assume that L1 and L2 are each bridged LANs that include a device M, presumably a bridge, that maps VLAN-x into VLAN-y and VLAN-y into VLAN-x.
进一步假设L1和L2都是桥接LAN，其中包括设备M，可能是桥接器，该设备将VLAN-x映射到VLAN-y，并将VLAN-y映射到VLAN-x。
If end station ES1 originated a broadcast or other multi-destination frame in VLAN-y, it would be ingressed by RB2. (The frame would also be mapped to VLAN-x and ingressed by RB1, but we initially ignore that.) RB2 will flood the resulting TRILL Data packet through the campus, and, at least in the broadcast and unknown unicast cases, it will get to RB4, where it will be egressed to L2. Inside L2, this broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3 then floods the resulting TRILL Data packet through the campus, this time with an Inner.VLAN of VLAN-x, as a result of which it will be egressed by RB1 into L1. Inside L1, it will be mapped back to VLAN-y and then ingressed by RB2, completing the loop. The packet will loop indefinitely, because in native form on L1 and L2 it has no TRILL Hop Count, and an indefinitely large number of copies will be delivered to ES1 and any other end station so situated. The same problem would occur even if P1 and P2 were on the same RBridge and/or P3 and P4 were on the same RBridge. Actually, because the original frame was also mapped to VLAN-x inside L1 and ingressed by RB1, there are two copies looping around in opposite directions.
如果终端站ES1在VLAN-y中发起广播或其他多目标帧，则RB2将进入该帧。（该帧也将被映射到VLAN-x，并由RB1进入，但我们最初忽略了这一点。）RB2将使产生的颤音数据包通过校园，并且，至少在广播和未知单播情况下，它将到达RB4，在那里它将出口到L2。在L2内部，该广播帧映射到VLAN-x，然后由RB3进入。然后，RB3将生成的TRILL数据包通过校园，这一次是VLAN-x的Inner.VLAN，其结果是RB1将其导出到L1中。在L1内部，它将映射回VLAN-y，然后由RB2进入，完成循环。数据包将无限期地循环，因为在L1和L2上的本机形式中，它没有颤音跳计数，并且无限期地大量拷贝将被传送到ES1和任何其他这样的终端站。即使P1和P2在同一个RBridge上和/或P3和P4在同一个RBridge上，也会出现相同的问题。实际上，由于原始帧也被映射到L1内的VLAN-x并由RB1进入，因此有两个副本在相反方向循环。
The use of Fine-Grained Labels [RFC7172] complicates but does not essentially change the potential problem.
细粒度标签的使用[RFC7172]使问题变得复杂，但并没有从本质上改变潜在的问题。
This example shows why VLAN mapping between Appointed Forwarder ports on a TRILL link is loop unsafe. When such a situation is detected, the DRB on the link changes Appointed Forwarders as necessary to assure that a single RBridge port is Appointed Forwarder for all VLANs involved in mapping. This change makes the situation loop safe.
此示例说明了为什么TRILL链路上指定转发器端口之间的VLAN映射不安全。当检测到这种情况时，链路上的DRB会根据需要更改指定的转发器，以确保为所有涉及映射的VLAN指定一个RBridge端口作为转发器。此更改使情况循环安全。
Appendix C. Changes to RFCs 6325, 6439, and 7177
附录C.对RFC 6325、6439和7177的变更
This document updates [RFC6325], obsoletes [RFC6439], and updates [RFC7177].
本文件更新了[RFC6325]，淘汰了[RFC6439]，并更新了[RFC7177]。
The change to [RFC6325], the TRILL base protocol, is as follows:
对TRILL基本协议[RFC6325]的更改如下：
Addition of mandatory support for E-L1CS FS-LSPs.
增加了对E-L1CS FS LSP的强制性支持。
Changes to [RFC6439], which this document obsoletes, are as follows:
本文件废止的[RFC6439]变更如下：
1. Specification of APPsub-TLVs and procedures to be used in E-L1CS FS-LSP forwarder appointments.
1. E-L1CS FS-LSP转发器预约中使用的APPsub TLV规范和程序。
2. Incorporation of updates to [RFC6439] that appeared in Section 10 of RFC 7180, which has been obsoleted by [RFC7780]. They appear primarily in Section 4 of this document.
2. 纳入RFC 7180第10节中出现的[RFC6439]更新，该更新已被[RFC7780]淘汰。它们主要出现在本文件第4节中。
3. Addition of an optional FGL-VLAN consistency check feature, including specification of APPsub-TLVs.
3. 添加可选的FGL-VLAN一致性检查功能，包括APPsub TLV规范。
4. Deletion of references to the October 2011 version of the document "RBridges: Campus VLAN and Priority Regions" (draft-ietf-trill-rbridge-vlan-mapping), which has been dropped by the TRILL WG.
4. 删除2011年10月版本的文件“RBridges：校园VLAN和优先区域”（ietf trill rbridge VLAN映射草案）的参考，trill工作组已删除该文件。
5. Addition of the Port-Shutdown message.
5. 添加端口关闭消息。
6. Elimination of the requirement that the DRB not send appointments in Hellos until its DRB inhibition timer has expired. This was an unnecessary safety precaution that is pointless, given that appointments in E-L1CS FS-LSPs are immediately visible.
6. 取消了DRB在其DRB抑制计时器过期之前不发送HELOS中约会的要求。这是一项毫无意义的不必要的安全预防措施，因为E-L1CS FS LSP中的预约可以立即看到。
7. Addition of three optional methods (Section 3.2) to optimize (reduce) inhibition time under various circumstances.
7. 增加三种可选方法（第3.2节），以优化（减少）各种情况下的抑制时间。
8. Editorial changes.
8. 编辑上的改动。
Changes to [RFC7177] are as follows:
[RFC7177]的变更如下：
As provided in Section 6, TRILL switches SHOULD treat the reception of a Port-Shutdown RBridge Channel message from RB1 listing port P1 as if it were an event A3 as specified in [RFC7177], resulting in transition of any adjacency to P1 to the Detect state.
如第6节所述，TRILL交换机应将从RB1接收的端口关闭RBridge通道消息（列出端口P1）视为[RFC7177]中规定的事件A3），从而导致P1的任何邻接转换为检测状态。
Acknowledgments
致谢
The following are hereby thanked for their contributions to this document:
特此感谢以下各方对本文件的贡献：
Spencer Dawkins, Shawn M. Emery, Stephen Farrell, Joel Halpern, Sue Hares, Christer Holmberg, Gayle Noble, Alvaro Retana, Dan Romascanu, and Mingui Zhang.
斯宾塞·道金斯、肖恩·埃莫里、斯蒂芬·法雷尔、乔尔·哈尔彭、苏·哈尔斯、克里斯特·霍姆伯格、盖尔·诺布尔、阿尔瓦罗·雷塔纳、丹·罗马斯坎努和张明贵。
The following are thanked for their contributions to [RFC6439], the predecessor to this document:
感谢以下人员对本文件前身[RFC6439]的贡献：
Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan Romascanu, and Mike Shand.
罗恩·博尼卡、斯图尔特·布莱恩特、琳达·邓巴、莱斯·金斯伯格、埃里克·诺德马克、丹·罗马斯坎努和迈克·尚德。
We also thank Radia Perlman, who coauthored [RFC6439].
我们还要感谢拉迪娅·帕尔曼，她是[RFC6439]的合著者。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为技术有限公司01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
宜州利华为技术有限公司软件大道101号南京210012
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Mohammed Umair IP Infusion
Mohammed Umair IP输液
Email: mohammed.umair2@ipinfusion.com
Email: mohammed.umair2@ipinfusion.com
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America
美国加利福尼亚州圣何塞西塔斯曼大道170号Ayan Banerjee Cisco Systems，邮编95134
Phone: +1-408-333-7149
Email: ayabaner@cisco.com
Phone: +1-408-333-7149
Email: ayabaner@cisco.com
Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai 201203 China
中国上海碧波路889号方伟胡中兴通讯股份有限公司201203
Phone: +86-21-68896273
Email: hu.fangwei@zte.com.cn
Phone: +86-21-68896273
Email: hu.fangwei@zte.com.cn