Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7180 M. Zhang
Updates: 6325, 6327, 6439 Huawei
Category: Standards Track A. Ghanwani
ISSN: 2070-1721 Dell
V. Manral
Ionos Corp.
A. Banerjee
Cumulus Networks
May 2014
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7180 M. Zhang
Updates: 6325, 6327, 6439 Huawei
Category: Standards Track A. Ghanwani
ISSN: 2070-1721 Dell
V. Manral
Ionos Corp.
A. Banerjee
Cumulus Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
大量链接的透明互连（TRILL）：澄清、更正和更新
Abstract
摘要
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data 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 this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.
IETF多链路透明互连（TRILL）协议在具有任意拓扑结构和链路技术的多跳网络中提供无需配置的最低成本成对数据转发，即使在临时环路期间也能安全转发，并支持单播和多播流量的多路径传输。TRILL通过使用中间系统到中间系统（IS-IS）链路状态路由和使用包含跃点计数的报头封装流量来实现这一点。自2011年7月发布TRILL基本协议以来，TRILL的积极发展已经揭示了RFC 6325中的勘误表以及一些可能需要澄清或更新的案例。
RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.
RFC 6327和6439提供了关于邻接和指定货运代理的澄清和更新。本文件提供了RFCs 6325、6327和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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7180.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7180.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Precedence .................................................4
1.2. Changes That Are Not Backward Compatible ...................4
1.3. Terminology and Acronyms ...................................5
2. Overloaded and/or Unreachable RBridges ..........................5
2.1. Reachability ...............................................6
2.2. Distribution Trees .........................................6
2.3. Overloaded Receipt of TRILL Data Frames ....................7
2.3.1. Known Unicast Receipt ...............................7
2.3.2. Multi-Destination Receipt ...........................7
2.4. Overloaded Origination of TRILL Data Frames ................7
2.4.1. Known Unicast Origination ...........................7
2.4.2. Multi-Destination Origination .......................8
2.4.2.1. An Example Network .........................8
2.4.2.2. Indicating OOMF Support ....................9
2.4.2.3. Using OOMF Service .........................9
3. Distribution Trees .............................................10
3.1. Number of Distribution Trees ..............................10
3.2. Clarification of Distribution Tree Updates ................10
3.3. Multicast Pruning Based on IP Address .....................10
3.4. Numbering of Distribution Trees ...........................11
3.5. Link Cost Directionality ..................................11
4. Nickname Selection .............................................11
5. MTU (Maximum Transmission Unit) ................................13
5.1. MTU-Related Errata in RFC 6325 ............................13
5.1.1. MTU PDU Addressing .................................14
5.1.2. MTU PDU Processing .................................14
5.1.3. MTU Testing ........................................14
5.2. Ethernet MTU Values .......................................15
6. Port Modes .....................................................15
7. The CFI/DEI Bit ................................................16
8. Graceful Restart ...............................................17
9. Updates to RFC 6327 ............................................17
10. Updates on Appointed Forwarders and Inhibition ................18
10.1. Optional TRILL Hello Reduction ...........................18
10.2. Overload and Appointed Forwarders ........................20
11. IANA Considerations ...........................................21
12. Security Considerations .......................................21
13. Acknowledgements ..............................................21
14. References ....................................................22
14.1. Normative References .....................................22
14.2. Informative References ...................................23
1. Introduction ....................................................4
1.1. Precedence .................................................4
1.2. Changes That Are Not Backward Compatible ...................4
1.3. Terminology and Acronyms ...................................5
2. Overloaded and/or Unreachable RBridges ..........................5
2.1. Reachability ...............................................6
2.2. Distribution Trees .........................................6
2.3. Overloaded Receipt of TRILL Data Frames ....................7
2.3.1. Known Unicast Receipt ...............................7
2.3.2. Multi-Destination Receipt ...........................7
2.4. Overloaded Origination of TRILL Data Frames ................7
2.4.1. Known Unicast Origination ...........................7
2.4.2. Multi-Destination Origination .......................8
2.4.2.1. An Example Network .........................8
2.4.2.2. Indicating OOMF Support ....................9
2.4.2.3. Using OOMF Service .........................9
3. Distribution Trees .............................................10
3.1. Number of Distribution Trees ..............................10
3.2. Clarification of Distribution Tree Updates ................10
3.3. Multicast Pruning Based on IP Address .....................10
3.4. Numbering of Distribution Trees ...........................11
3.5. Link Cost Directionality ..................................11
4. Nickname Selection .............................................11
5. MTU (Maximum Transmission Unit) ................................13
5.1. MTU-Related Errata in RFC 6325 ............................13
5.1.1. MTU PDU Addressing .................................14
5.1.2. MTU PDU Processing .................................14
5.1.3. MTU Testing ........................................14
5.2. Ethernet MTU Values .......................................15
6. Port Modes .....................................................15
7. The CFI/DEI Bit ................................................16
8. Graceful Restart ...............................................17
9. Updates to RFC 6327 ............................................17
10. Updates on Appointed Forwarders and Inhibition ................18
10.1. Optional TRILL Hello Reduction ...........................18
10.2. Overload and Appointed Forwarders ........................20
11. IANA Considerations ...........................................21
12. Security Considerations .......................................21
13. Acknowledgements ..............................................21
14. References ....................................................22
14.1. Normative References .....................................22
14.2. Informative References ...................................23
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides optimal pair-wise 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 this by using Intermediate System to Intermediate System (IS-IS) [IS-IS] [RFC1195] [RFC7176] link-state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs (Virtual Local Area Networks) and optimization of the distribution of multi-destination frames based on VLANs and IP derived multicast groups.
IETF多链路透明互连（TRILL）协议[RFC6325]在具有任意拓扑结构和链路技术的多跳网络中提供无需配置的最佳成对数据帧转发，即使在临时环路期间也能安全转发，并支持单播和多播流量的多路径传输。TRILL通过使用中间系统到中间系统（IS-IS）[IS-IS][RFC1195][RFC7176]链路状态路由和使用包含跃点计数的报头封装流量来实现这一点。该设计支持VLAN（虚拟局域网）和基于VLAN和IP派生多播组的多目标帧分布优化。
In the years since the TRILL base protocol [RFC6325] was published, active development of TRILL has revealed five errors in the specification [RFC6325] and cases that could use clarifications or updates.
自TRILL基本协议[RFC6325]发表以来的几年中，TRILL的积极开发已经揭示了规范[RFC6325]中的五个错误以及可能需要澄清或更新的案例。
[RFC6327] and [RFC6439] provide clarifications with respect to Adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to [RFC6325], [RFC6327], and [RFC6439].
[RFC6327]和[RFC6439]提供了关于邻接和指定货运代理的澄清。本文件提供了[RFC6325]、[RFC6327]和[RFC6439]的其他已知澄清、更正和更新。
In case of conflict between this document and any of [RFC6325], [RFC6327], or [RFC6439], this document takes precedence. In addition, Section 1.2 (Normative Content and Precedence) of [RFC6325] is updated to provide a more complete precedence ordering of the sections of [RFC6325] as following, where sections to the left take precedence over sections to their right:
如果本文件与[RFC6325]、[RFC6327]或[RFC6439]中的任何一项之间存在冲突，则以本文件为准。此外，[RFC6325]第1.2节（规范性内容和优先顺序）已更新，以提供[RFC6325]各节更完整的优先顺序，如下所示，其中左侧各节优先于右侧各节：
4 > 3 > 7 > 5 > 2 > 6 > 1
4 > 3 > 7 > 5 > 2 > 6 > 1
The change made by Section 3.4 below is not backward compatible with [RFC6325] but has nevertheless been adopted to reduce distribution tree changes resulting from topology changes.
下面第3.4节所做的更改与[RFC6325]不向后兼容，但已被采用以减少因拓扑更改而导致的配电树更改。
The several other changes herein that are fixes to errata for [RFC6325] -- [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] [Err3508] -- may not be backward compatible with previous implementations that conformed to errors in the specification.
本文中对[RFC6325]-[Err3002][Err3003][Err3004][Err3052][Err3053][Err3508]勘误表所做的其他几项更改可能与符合规范中错误的先前实现不向后兼容。
This document uses the acronyms defined in [RFC6325] and the following acronyms and terms:
本文件使用[RFC6325]中定义的首字母缩略词以及以下首字母缩略词和术语：
CFI - Canonical Format Indicator [802]
CFI-规范格式指示符[802]
DEI - Drop Eligibility Indicator [802.1Q-2011]
DEI-删除资格指标[802.1Q-2011]
EISS - Enhanced Internal Sublayer Service
EISS-增强的内部子层服务
OOMF - Overload Originated Multi-destination Frame
OOMF-重载起源的多目标帧
TRILL Switch - An alternative name for an RBridge
颤音开关-RBridge的另一个名称
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
RBridges may be in overload as indicated by the [IS-IS] overload flag in their LSPs (Link State PDUs). This means that either (1) they are incapable of holding the entire link-state database and thus do not have a view of the entire topology or (2) they have been configured to have the overload bit set. Although networks should be engineered to avoid actual link-state overload, it might occur under various circumstances. For example, if a large campus included one or more low-end TRILL Switches.
RBridge可能处于过载状态，如其LSP（链路状态PDU）中的[IS-IS]过载标志所示。这意味着（1）它们无法保存整个链路状态数据库，因此没有整个拓扑的视图，或者（2）它们已配置为设置过载位。虽然网络的设计应避免实际链路状态过载，但在各种情况下都可能发生过载。例如，如果一个大型园区包含一个或多个低端TRILL交换机。
It is a common operational practice to set the overload bit in an [IS-IS] router (such as an RBridge) when performing maintenance on that router that might affect its ability to correctly forward frames; this will usually leave the router reachable for maintenance traffic, but transit traffic will not be routed through it. (Also, in some cases, TRILL provides for setting the overload bit in the pseudonode of a link to stop TRILL Data traffic on an access link (see Section 4.9.1 of [RFC6325]).)
在[is-is]路由器（如RBridge）上执行可能影响其正确转发帧能力的维护时，在该路由器（如RBridge）中设置过载位是一种常见的操作实践；这通常会使维护流量可以到达路由器，但传输流量不会通过路由器路由。（此外，在某些情况下，TRILL用于设置链路伪节点中的过载位，以停止接入链路上的TRILL数据流量（参见[RFC6325]第4.9.1节）
[IS-IS] and TRILL make a reasonable effort to do what they can even if some RBridges/routers are in overload. They can do reasonably well if a few scattered nodes are in overload. However, actual least-cost paths are no longer assured if any RBridges are in overload.
[IS-IS]和TRILL尽其所能尽其所能，即使某些RBridge/路由器过载。如果几个分散的节点处于过载状态，它们可以做得相当好。但是，如果任何RBridge处于过载状态，则不再保证实际的最低成本路径。
For the effect of overload on the appointment of forwarders, see Section 10.2.
关于超载对货运代理人任命的影响，见第10.2节。
In this Section 2, the term "neighbor" refers only to actual RBridges and ignores pseudonodes.
在第2节中，术语“邻居”仅指实际RBridge，而忽略伪节点。
Frames are not least-cost routed through an overloaded TRILL Switch, although they may originate or terminate at an overloaded TRILL Switch. In addition, frames will not be least-cost routed over links with cost 2**24 - 1 [RFC5305]; such links are reserved for traffic-engineered frames, the handling of which is beyond the scope of this document.
帧不是通过重载TRILL开关路由的成本最低的，尽管它们可以在重载TRILL开关处发起或终止。此外，帧不会在成本为2**24-1[RFC5305]的链路上以最低成本路由；此类链接是为流量工程帧保留的，其处理超出了本文档的范围。
As a result, a portion of the campus may be unreachable for least-cost routed TRILL Data because all paths to it would be through a link with cost 2**24 - 1 or through an overloaded RBridge. For example, an RBridge RB1 is not reachable by TRILL Data if all of its neighbors are connected to RB1 by links with cost 2**24 - 1. Such RBridges are called "data unreachable".
因此，对于成本最低的路由TRILL数据，校园的一部分可能无法访问，因为到它的所有路径都将通过成本为2**24-1的链路或过载的RBridge。例如，如果RBridge RB1的所有邻居都通过成本为2**24-1的链路连接到RB1，则TRILL数据无法访问RBridge RB1。这种RBridge称为“数据不可访问”。
The link-state database at an RBridge RB1 can also contain information on TRILL Switches that are unreachable by IS-IS link-state flooding due to link or RBridge failures. When such failures partition the campus, the TRILL Switches adjacent to the failure and on the same side of the failure as RB1 will update their LSPs to show the lack of connectivity, and RB1 will receive those updates. As a result, RB1 will be aware of the partition. Nodes on the far side of the partition are both IS-IS unreachable and data unreachable. However, LSPs held by RB1 for TRILL Switches on the far side of the failure will not be updated and may stay around until they time out, which could be tens of minutes or longer. (The default in [IS-IS] is twenty minutes.)
RBridge RB1处的链路状态数据库还可以包含由于链路或RBridge故障导致IS-IS链路状态洪泛无法访问的TRILL交换机的信息。当此类故障对校园进行分区时，与故障相邻且与RB1位于故障同一侧的TRILL交换机将更新其LSP以显示缺乏连接，RB1将接收这些更新。因此，RB1将知道分区。分区远端的节点既不可访问，也不可访问数据。但是，RB1为故障远端的TRILL交换机持有的LSP将不会更新，并且可能会一直保留，直到超时为止，这可能需要几十分钟或更长时间。（在[IS-IS]中，默认值为20分钟。）
An RBridge in overload cannot be trusted to correctly calculate distribution trees or correctly perform the RPFC (Reverse-Path Forwarding Check). Therefore, it cannot be trusted to forward multi-destination TRILL Data frames. It can only appear as a leaf node in a TRILL multi-destination distribution tree. Furthermore, if all the immediate neighbors of an RBridge are overloaded, then it is omitted from all trees in the campus and is unreachable by multi-destination frames.
无法信任RBridge in重载正确计算分发树或正确执行RPFC（反向路径转发检查）。因此，转发多目标颤音数据帧是不可信的。它只能显示为TRILL多目标分发树中的叶节点。此外，如果RBridge的所有近邻都过载，那么它将从校园中的所有树中忽略，并且多目标帧无法访问。
When an RBridge determines what nicknames to use as the roots of the distribution trees it calculates, it MUST ignore all nicknames held by TRILL Switches that are in overload or are data unreachable. When calculating RPFCs for multi-destination frames, an RBridge RB1 MAY, to avoid calculating unnecessary RPF check state, ignore any trees
当RBridge确定使用什么昵称作为其计算的分发树的根时，它必须忽略TRILL开关持有的所有处于过载或数据无法访问状态的昵称。当计算多目标帧的rpfc时，RBridge RB1可以忽略任何树，以避免计算不必要的RPF检查状态
that cannot reach to RB1 even if other RBridges list those trees as trees that other TRILL Switches might use. (But see Section 3.)
即使其他RBridge将这些树列为其他TRILL交换机可能使用的树，也无法到达RB1。（但请参见第3节。）
The receipt of TRILL Data frames by overloaded RBridge RB2 is discussed in the subsections below. In all cases, the normal Hop Count decrement is performed, and the TRILL Data frame is discarded if the result is less than one or if the egress nickname is illegal.
在下面的小节中讨论了重载RBridge RB2接收TRILL数据帧的问题。在所有情况下，执行正常跳数递减，如果结果小于1或出口昵称非法，则丢弃颤音数据帧。
RB2 will not usually receive unicast TRILL Data frames unless it is the egress, in which case it decapsulates and delivers the frames normally. If RB2 receives a unicast TRILL Data frame for which it is not the egress, perhaps because a neighbor does not yet know it is in overload, RB2 MUST NOT discard the frame because the egress is an unknown nickname as it might not know about all nicknames due to its overloaded condition. If any neighbor, other than the neighbor from which it received the frame, is not overloaded, it MUST attempt to forward the frame to one of those neighbors. If there is no such neighbor, the frame is discarded.
RB2通常不会接收单播颤音数据帧，除非它是出口，在这种情况下，它正常地去封装并发送帧。如果RB2接收到非出口的单播TRILL数据帧，可能是因为邻居还不知道该帧处于过载状态，RB2不得丢弃该帧，因为出口是一个未知的昵称，因为由于其过载状态，RB2可能不知道所有的昵称。如果除接收帧的邻居之外的任何邻居未过载，则必须尝试将帧转发到这些邻居之一。如果没有这样的邻居，帧将被丢弃。
If RB2 in overload receives a multi-destination TRILL Data frame, RB2 MUST NOT apply an RPFC since, due to overload, it might not do so correctly. RB2 decapsulates and delivers the frame locally where it is Appointed Forwarder for the frame's VLAN, subject to any multicast pruning. But since, as stated above, RB2 can only be the leaf of a distribution tree, it MUST NOT forward a multi-destination TRILL Data frame (except as an egressed native frame where RB2 is Appointed Forwarder).
如果过载中的RB2接收到多目标TRILL数据帧，RB2不得应用RPFC，因为由于过载，它可能无法正确应用RPFC。RB2在本地为帧的VLAN指定转发器的位置解除封装并交付帧，并进行任何多播修剪。但是，如上所述，由于RB2只能是分发树的叶子，因此它不能转发多目的地TRILL数据帧（RB2被指定为转发器的外出本机帧除外）。
Overloaded origination of unicast frames with known egress and of multi-destination frames are discussed in the subsections below.
以下小节将讨论具有已知出口的单播帧和多目的帧的过载发起。
When an overloaded RBridge RB2 ingresses or creates a known destination unicast TRILL Data frame, it delivers it locally if the destination Media Access Control (MAC) is local. Otherwise, RB2 unicasts it to any neighbor TRILL Switch that is not overloaded. It MAY use what routing information it has to help select the neighbor.
当过载的RBridge RB2进入或创建已知的目标单播TRILL数据帧时，如果目标媒体访问控制（MAC）是本地的，它会在本地传送该数据帧。否则，RB2将其单播到任何未过载的相邻TRILL交换机。它可以使用它拥有的路由信息来帮助选择邻居。
Overloaded RBridge RB2 ingressing or creating a multi-destination TRILL Data frame is more complex than for a known unicast frame.
重载RBridge RB2进入或创建多目的地颤音数据帧比已知单播帧更复杂。
For example, consider the network below in which, for simplicity, end stations and any bridges are not shown. There is one distribution tree of which RB4 is the root; it is represented by double lines. Only RBridge RB2 is overloaded.
例如，考虑下面的网络，为了简单起见，没有示出终端站和任何桥梁。有一个以RB4为根的分布树；它由双线表示。只有RBridge RB2过载。
+-----+ +-----+ +-----+ +-----+
| RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
+-----+ +--+--+ +-++--+ +--+--|
| || |
+---+---+ || |
+------+RB2(ov)|======++ |
| +-------+ || |
| || |
+--+--+ +-----+ ++==++=++ +--+--+
| RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 |
+-----+ +-----+ ++=====++ +-----+
+-----+ +-----+ +-----+ +-----+
| RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
+-----+ +--+--+ +-++--+ +--+--|
| || |
+---+---+ || |
+------+RB2(ov)|======++ |
| +-------+ || |
| || |
+--+--+ +-----+ ++==++=++ +--+--+
| RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 |
+-----+ +-----+ ++=====++ +-----+
Since RB2 is overloaded, it does not know what the distribution tree or trees are for the network. Thus, there is no way it can provide normal TRILL Data encapsulation for multi-destination native frames. So RB2 tunnels the frame to a neighbor that is not overloaded if it has such a neighbor that has signaled that it is willing to offer this service. RBridges indicate this in their Hellos as described below. This service is called OOMF (Overload Originated Multi-destination Frame) service.
由于RB2过载，它不知道网络的分发树是什么。因此，它无法为多目标本机帧提供正常的TRILL数据封装。因此，如果RB2的邻居表示愿意提供此服务，则RB2通过隧道将帧传送给未过载的邻居。RBridges在其Hello中表示这一点，如下所述。此服务称为OOMF（重载起源的多目标帧）服务。
- The multi-destination frame MUST NOT be locally distributed in native form at RB2 before tunneling to a neighbor because this would cause the frame to be delivered twice. For example, if RB2 locally distributed a multicast native frame and then tunneled it to RB5, RB2 would get a copy of the frame when RB3 transmitted it as a TRILL Data frame on the multi-access RB2-RB3-RB4 link. Since RB2 would, in general, not be able to tell that this was a frame it had tunneled for distribution, RB2 would decapsulate it and locally distribute it a second time.
- 在隧道传输到邻居之前，多目标帧不得以本机形式在RB2本地分布，因为这将导致帧被传递两次。例如，如果RB2本地分发一个多播本机帧，然后通过隧道将其传输到RB5，则当RB3在多址RB2-RB3-RB4链路上将其作为颤音数据帧传输时，RB2将获得该帧的副本。一般来说，由于RB2无法判断这是一个为分发而挖隧道的帧，因此RB2将对其进行去封装，并在本地进行第二次分发。
- On the other hand, if there is no neighbor of RB2 offering RB2 the OOMF service, RB2 cannot tunnel the frame to a neighbor. In this case, RB2 MUST locally distribute the frame where it is Appointed Forwarder for the frame's VLAN and optionally subject to multicast pruning.
- 另一方面，如果RB2的邻居没有向RB2提供OOMF服务，则RB2无法通过隧道将帧传输到邻居。在这种情况下，RB2必须在本地分发帧，它被指定为帧VLAN的转发器，并且可以选择性地进行多播修剪。
An RBridge RB3 indicates its willingness to offer the OOMF service to RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit associated with the SNPA (Subnetwork Point of Attachment, also known as MAC address) of RB2 on the link. (See Section 11.) Overloaded RBridge RB2 can only distribute multi-destination TRILL Data frames to the campus if a neighbor of RB2 not in overload offers RB2 the OOMF service. If RB2 does not have OOMF service available to it, RB2 can still receive multi-destination frames from non-overloaded neighbors and, if RB2 should originate or ingress such a frame, it distributes it locally in native form.
RBridge RB3通过在链路上设置与RB2的SNPA（子网连接点，也称为MAC地址）相关的位，表示其愿意在RB3的TRILL Hellos中的TRILL邻居TLV中向RB2提供OOMF服务。（参见第11节。）如果RB2的邻居未处于过载状态，则过载的RBridge RB2只能将多目标TRILL数据帧分发到校园，并向RB2提供OOMF服务。如果RB2没有可用的OOMF服务，RB2仍然可以从未过载的邻居接收多目标帧，如果RB2应该发起或进入这样的帧，它会以本机形式在本地分发它。
If RB2 sees this OOMF (Overload Originated Multi-destination Frame) service advertised for it by any of its neighbors on any link to which RB2 connects, it selects one such neighbor by a means beyond the scope of this document. Assuming RB2 selects RB3 to handle multi-destination frames it originates, RB2 MUST advertise in its LSP that it might use any of the distribution trees that RB3 advertises so that the RPFC will work in the rest of the campus. Thus, notwithstanding its overloaded state, RB2 MUST retain this information from RB3 LSPs, which it will receive as it is directly connected to RB3.
如果RB2看到其任何邻居在RB2连接的任何链路上为其发布的OOMF（重载起源的多目标帧）服务，它将通过超出本文档范围的方式选择一个这样的邻居。假设RB2选择RB3来处理它发起的多目标帧，RB2必须在其LSP中通告，它可以使用RB3通告的任何分发树，以便RPFC在校园的其余部分工作。因此，尽管RB2处于过载状态，但它必须保留来自RB3 LSP的该信息，当它直接连接到RB3时，它将接收该信息。
RB2 then encapsulates such frames as TRILL Data frames to RB3 as follows: M bit = 0, Hop Count = 2, ingress nickname = a nickname held by RB2, and, since RB2 cannot tell what distribution tree RB3 will use, egress nickname = a special nickname indicating an OOMF frame (see Section 11). RB2 then unicasts this TRILL Data frame to RB3. (Implementation of Item 4 in Section 4 below provides reasonable assurance that, notwithstanding its overloaded state, the ingress nickname used by RB2 will be unique within at least the portion of the campus that is IS-IS reachable from RB2.)
然后，RB2将这些帧作为颤音数据帧封装到RB3，如下所示：M位=0，跳数=2，入口昵称=RB2持有的昵称，并且，由于RB2不能告诉RB3将使用什么分发树，出口昵称=指示OOMF帧的特殊昵称（参见第11节）。RB2然后将该颤音数据帧单播到RB3。（下文第4节第4项的实施提供了合理的保证，即尽管RB2处于过载状态，但RB2使用的入口昵称在至少可从RB2访问的校园部分内是唯一的。）
On receipt of such a frame, RB3 does the following:
收到该帧后，RB3执行以下操作：
- changes the Egress Nickname field to designate a distribution tree that RB3 normally uses, - sets the M bit to one, - changes the Hop Count to the value it would normally use if it were the ingress, and - forwards the frame on that tree.
- 更改出口昵称字段以指定RB3通常使用的分发树，-将M位设置为1，-将跃点计数更改为它在入口时通常使用的值，并-转发该树上的帧。
RB3 MAY rate limit the number of frames for which it is providing this service by discarding some such frames from RB2. The provision of even limited bandwidth for OOMFs by RB3, perhaps via the slow
RB3可以通过从RB2丢弃一些这样的帧来限制其提供此服务的帧的数量。RB3甚至为OOMFs提供有限的带宽，可能是通过慢速网络
path, may be important to the bootstrapping of services at RB2 or at end stations connected to RB2, such as supporting DHCP and ARP/ND (Address Resolution Protocol / Neighbor Discovery). (Everyone sometimes needs a little OOMF (pronounced "oomph") to get off the ground.)
路径，对于RB2或连接到RB2的终端站的服务引导可能很重要，例如支持DHCP和ARP/ND（地址解析协议/邻居发现）。（每个人有时都需要一点OOMF（发音为“oomph”）才能离开地面。）
Two corrections, a clarification, and two updates related to distribution trees appear in the subsections below. See also Section 2.2.
两个更正、一个澄清和两个与分发树相关的更新出现在下面的小节中。另见第2.2节。
In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. It should read "(up to k if j is zero or the minimum of (j, k) if j is non-zero)".
在[RFC6325]第56页第2点第4段第4.5.2节中，插入语“（最多{j，k}）”不正确[Err3052]。其读数应为“（如果j为零，则最大值为k；如果j为非零，则最小值为（j，k）”。
When a link-state database change causes a change in the distribution tree(s), there are several possibilities. If a tree root remains a tree root but the tree changes, then local forwarding and RPFC entries for that tree should be updated as soon as practical. Similarly, if a new nickname becomes a tree root, forwarding and RPFC entries for the new tree should be installed as soon as practical. However, if a nickname ceases to be a tree root and there is sufficient room in local tables, the forwarding and RPFC entries for the former tree MAY be retained so that any multi-destination TRILL Data frames already in flight on that tree have a higher probability of being delivered.
当链接状态数据库更改导致分发树中的更改时，有几种可能性。如果树根仍然是树根，但树发生了更改，则应尽快更新该树的本地转发和RPFC条目。类似地，如果新昵称成为树根，则应尽快安装新树的转发和RPFC条目。然而，如果昵称不再是树根，并且本地表中有足够的空间，则可以保留前一棵树的转发和RPFC条目，以便已经在该树上飞行的任何多目的地TRILL数据帧具有更高的被传送的概率。
The TRILL base protocol specification [RFC6325] provides for and recommends the pruning of multi-destination frame distribution trees based on the location of IP multicast routers and listeners; however, multicast listening is identified by derived MAC addresses as communicated in the Group MAC Address sub-TLV [RFC7176].
TRILL基本协议规范[RFC6325]规定并建议根据IP多播路由器和侦听器的位置修剪多目标帧分布树；然而，多播侦听通过在组MAC地址子TLV[RFC7176]中通信的派生MAC地址来识别。
TRILL Switches MAY communicate multicast listeners and prune distribution trees based on the actual IPv4 or IPv6 multicast addresses involved. Additional Group Address sub-TLVs are provided in [RFC7176] to carry this information. A TRILL Switch that is only capable of pruning based on derived MAC address SHOULD calculate and use such derived MAC addresses from multicast listener IPv4/IPv6 address information it receives.
TRILL交换机可以与多播侦听器通信，并根据实际涉及的IPv4或IPv6多播地址修剪分发树。[RFC7176]中提供了附加的组地址子TLV以承载此信息。只能基于派生MAC地址进行修剪的TRILL交换机应根据其接收的多播侦听器IPv4/IPv6地址信息计算并使用此类派生MAC地址。
Section 4.5.1 of [RFC6325] specifies that, when building distribution tree number j, node (RBridge) N that has multiple possible parents in the tree is attached to possible parent number j mod p. Trees are numbered starting with 1, but possible parents are numbered starting with 0. As a result, if there are two trees and two possible parents, in tree 1, parent 1 will be selected, and in tree 2, parent 0 will be selected.
[RFC6325]的第4.5.1节规定，在构建编号为j的分发树时，树中具有多个可能父节点的节点（RBridge）N连接到可能的父节点编号j mod p。树从1开始编号，但可能的父树从0开始编号。因此，如果有两棵树和两个可能的父级，则在树1中，将选择父级1，在树2中，将选择父级0。
This is changed so that the selected parent MUST be (j-1) mod p. As a result, in the case above, tree 1 will select parent 0, and tree 2 will select parent 1. This change is not backward compatible with [RFC6325]. If all RBridges in a campus do not determine distribution trees in the same way, then for most topologies, the RPFC will drop many multi-destination frames before they have been properly delivered.
此项已更改，因此所选父项必须为（j-1）mod p。因此，在上述情况下，树1将选择父级0，树2将选择父级1。此更改与[RFC6325]不向后兼容。如果校园中的所有RBFC不以相同的方式确定分发树，那么对于大多数拓扑，RPFC将在正确交付多个多目标帧之前丢弃多个多目标帧。
Distribution tree construction, like other least-cost aspects of TRILL, works even if link costs are asymmetric, so the cost of the hop from RB1 to RB2 is different from the cost of the hop from RB2 to RB1. However, it is essential that all RBridges calculate the same distribution trees, and thus, all must either use the cost away from the tree root or the cost towards the tree root. As corrected in [Err3508], the text in Section 4.5.1 of [RFC6325] is incorrect. It says:
与TRILL的其他最低成本方面一样，分布树构造即使在链路成本不对称的情况下也能工作，因此从RB1到RB2的跳的成本不同于从RB2到RB1的跳的成本。然而，至关重要的是，所有RBridge计算相同的分布树，因此，所有RBridge都必须使用远离树根的成本或朝向树根的成本。如[Err3508]所更正，[RFC6325]第4.5.1节中的文本不正确。它说：
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from N to R and ...
换言之，对于根在R的树，N的潜在父代集合由那些提供从N到R的最小成本路径和。。。
but the text should say "from R to N":
但是文本应该是“从R到N”：
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from R to N and ...
换句话说，对于根植于R的树，N的潜在双亲集由那些给出从R到N的最小代价路径的双亲集和。。。
Nickname selection is covered by Section 3.7.3 of [RFC6325]. However, the following should be noted:
[RFC6325]第3.7.3节介绍了昵称选择。但是，应注意以下几点：
1. The second sentence in the second bullet item in Section 3.7.3 of [RFC6325] on page 25 is erroneous [Err3002] and is corrected as follows:
1. 第25页[RFC6325]第3.7.3节第二个项目符号中的第二句错误[Err3002]，更正如下：
o The occurrence of "IS-IS ID (LAN ID)" is replaced with "priority".
o “IS-IS ID（LAN ID）”的出现被替换为“优先级”。
o The occurrence of "IS-IS System ID" is replaced with "seven-byte IS-IS ID (LAN ID)".
o 出现的“IS-IS系统ID”替换为“七字节IS-IS ID（LAN ID）”。
The resulting corrected sentence in [RFC6325] reads as follows:
[RFC6325]中更正后的句子如下：
If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, then the RBridge or pseudonode with the numerically higher priority keeps the nickname, or if there is a tie in priority, the RBridge with the numerically higher seven-byte IS-IS ID (LAN ID) keeps the nickname, and the other RBridge MUST select a new nickname.
如果RB1选择昵称x，并且RB1在以后任何时候通过接收RB2的LSP发现RB2也选择了x，则具有较高优先级的RBridge或伪节点保留昵称，或者如果优先级相同，则具有较高七字节is-is ID（LAN ID）的RBridge保留昵称，另一个RBridge必须选择一个新的昵称。
2. In examining the link-state database for nickname conflicts, nicknames held by IS-IS unreachable TRILL Switches MUST be ignored, but nicknames held by IS-IS reachable TRILL Switches MUST NOT be ignored even if they are data unreachable.
2. 在检查链路状态数据库中的昵称冲突时，必须忽略IS-IS不可访问TRILL开关持有的昵称，但IS-IS可访问TRILL开关持有的昵称不得忽略，即使它们是数据不可访问的。
3. An RBridge may need to select a new nickname, either initially because it has none or because of a conflict. When doing so, the RBridge MUST consider as available all nicknames that do not appear in its link-state database or that appear to be held by IS-IS unreachable TRILL Switches; however, it SHOULD give preference to selecting new nicknames that do not appear to be held by any TRILL Switch in the campus, reachable or unreachable, so as to minimize conflicts if IS-IS unreachable TRILL Switches later become reachable.
3. RBridge可能需要选择一个新的昵称，最初可能是因为它没有昵称，也可能是因为冲突。当这样做时，R桥必须考虑可用的所有昵称，这些昵称没有出现在其链路状态数据库中，或者看来是由IS-IS不可到达的Trip交换机所持有；但是，它应该优先选择新的昵称，这些昵称似乎不由校园中的任何TRILL交换机持有，可访问或不可访问，以便在IS-IS不可访问TRILL交换机以后变得可访问时将冲突降至最低。
4. An RBridge, even after it has acquired a nickname for which there appears to be no conflicting claimant, MUST continue to monitor for conflicts with the nickname or nicknames it holds. It does so by checking in LSP PDUs it receives that should update its link-state database for the following: any occurrence of any of its nicknames held with higher priority by some other TRILL Switch that is IS-IS reachable from it. If it finds such a conflict, it MUST select a new nickname, even when in overloaded state. (It is possible to receive an LSP that should update the link-state database but does not due to overload.)
4. RBridge即使在获得了一个似乎没有冲突索赔人的昵称之后，也必须继续监控与它所拥有的一个或多个昵称的冲突。它通过检查接收到的LSP PDU来实现这一点，该LSP PDU应更新其链路状态数据库，以获取以下信息：它的任何昵称的任何出现都被其他TRILL开关以更高的优先级保留，该开关可以从它处访问。如果它发现这样的冲突，它必须选择一个新的昵称，即使在重载状态下也是如此。（可能会收到一个LSP，该LSP应更新链路状态数据库，但不会因过载而更新。）
5. In the very unlikely case that an RBridge is unable to obtain a nickname because all valid RBridge nicknames (0x0001 through 0xFFBF inclusive) are in use with higher priority by IS-IS reachable TRILL Switches, it will be unable to act as an ingress, egress, or tree root but will still be able to function as a transit TRILL Switch. Although it cannot be a tree root, such an
5. 在极不可能的情况下，由于is-is可达颤音开关以更高的优先级使用所有有效的RBridge昵称（0x0001到0xFFBF），RBridge无法获得昵称，它将无法充当入口、出口或树根，但仍能充当传输颤音开关。虽然它不能是树根，但这样的
RBridge is included in distribution trees computed for the campus unless all its neighbors are overloaded. It would not be possible to send a unicast RBridge Channel message specifically to such a TRILL Switch [RFC7178]; however, it will receive unicast Channel messages sent by a neighbor to the Any-RBridge egress nickname and will receive appropriate multi-destination Channel messages.
RBridge包含在为校园计算的分布树中，除非其所有邻居都过载。不可能专门向这种颤音交换机发送单播RBridge信道消息[RFC7178]；然而，它将接收邻居发送到任意RBridge出口昵称的单播信道消息，并将接收适当的多目的地信道消息。
MTU values in TRILL key off the originatingL1LSPBufferSize value communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is the minimum value of originatingL1LSPBufferSize for the RBridges in a campus, but not less than 1470. The MTU testing mechanism and limiting LSPs to Sz assures that the LSPs can be flooded by IS-IS and thus that IS-IS can operate properly.
颤音中的MTU值关闭IS-IS-IS-IS-IS-IS-IS-IS中传送的原始L1LSPBufferSize值。如[RFC6325]第4.3.1节所述，校园范围内的值Sz是校园内RBridge的初始L1LSPBufferSize的最小值，但不小于1470。MTU测试机制和限制LSP至Sz可确保LSP可被IS-IS淹没，从而IS-IS可正常运行。
If nothing is known about the MTU of the links or the originatingL1LSPBufferSize of other RBridges in a campus, the originatingL1LSPBufferSize for an RBridge should default to the minimum of the LSP size that its TRILL IS-IS software can handle and the minimum MTU of the ports that it might use to receive or transmit LSPs. If an RBridge does have knowledge of link MTUs or other RBridge originatingL1LSPBufferSize, then, to avoid the necessity to regenerate the local LSPs using a different maximum size, the RBridge's originatingL1LSPBufferSize SHOULD be configured to the minimum of (1) the smallest value that other RBridges are or will be announcing as their originatingL1LSPBufferSize and (2) a value small enough that the campus will not partition due to a significant number of links with limited MTU. However, as provided in [RFC6325], in no case can originatingL1LSPBufferSize be less than 1470. In a well-configured campus, to minimize any LSP regeneration due to re-sizing, it is desirable for all RBridges to be configured with the same originatingL1LSPBufferSize.
如果对链路的MTU或校园中其他RBridge的起始L1LSPBufferSize一无所知，RBridge的起始L1LSPBufferSize应默认为其TRILL is-is软件可以处理的LSP大小的最小值，以及它可能用于接收或传输LSP的端口的最小MTU。如果RBridge确实知道链路MTU或其他RBridge发端L1LSPBufferSize，则为了避免使用不同的最大大小重新生成本地LSP的必要性，RBridge的发端L1LSPBufferSize应配置为最小值（1）其他RBridge正在或将要宣布为其原始L1lspBufferSize的最小值，以及（2）一个足够小的值，由于MTU有限的大量链接，校园不会分区。但是，如[RFC6325]所述，在任何情况下，发起L1LSPBufferSize都不能小于1470。在配置良好的校园中，为了最大限度地减少因重新调整大小而导致的任何LSP再生，所有RBridge都需要配置相同的原始L1LSPBufferSize。
Section 5.1 below corrects errata in [RFC6325], and Section 5.2 clarifies the meaning of various MTU limits for TRILL Ethernet links.
下面第5.1节更正了[RFC6325]中的勘误表，第5.2节澄清了TRILL以太网链路的各种MTU限制的含义。
Three MTU-related errata in [RFC6325] are corrected in the subsections below.
[RFC6325]中的三个MTU相关勘误表在以下小节中进行了更正。
Section 4.3.2 of [RFC6325] incorrectly states that multi-destination MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links with the All-RBridges multicast address as the Outer.MacDA [Err3004]. As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST be sent to the All-IS-IS-RBridges multicast address.
[RFC6325]第4.3.2节错误地指出，多目标MTU探测器和MTU ack TRILL IS-IS PDU通过以太网链路发送，所有RBridges多播地址作为Outer.MacDA[Err3004]。作为TRILL IS-IS PDU，当在以太网链路上进行多播时，必须将它们发送到All IS RBRIGES多播地址。
As discussed in [RFC6325] and, in more detail, in [RFC6327], MTU-probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of [RFC6325] erroneously does not allow for this possibility [Err3003]. It is corrected by replacing Item numbered "1" in Section 4.6.2 of [RFC6325] with the following quoted text to which TRILL Switches MUST conform:
如[RFC6325]和[RFC6327]中更详细地讨论的，MTU探测和MTU ack PDU可以是单播的；然而，[RFC6325]第4.6节错误地不允许这种可能性[Err3003]。通过将[RFC6325]第4.6.2节中编号为“1”的项目替换为以下引用文本进行纠正，颤音开关必须符合以下引用文本：
"1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All-IS-IS-RBridges or the unicast MAC address of the receiving RBridge port, the frame is handled as described in Section 4.6.2.1"
“1.如果Ethertype是L2-is-is，Outer.MacDA是All is RBridges或接收RBridge端口的单播MAC地址，则按照第4.6.2.1节所述处理帧。”
The reference to "Section 4.6.2.1" in the above quoted text is to that section in [RFC6325].
上述引用文本中提及的“第4.6.2.1节”是指[RFC6325]中的该节。
The last two sentences of Section 4.3.2 of [RFC6325] have errors [Err3053]. They currently read:
[RFC6325]第4.3.2节的最后两句有错误[Err3053]。它们目前的内容是：
If X is not greater than Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X > Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
如果X不大于Sz，则RB1在RB1的Hello中为RB2设置“最小MTU测试失败”标志。如果大小X成功，且X>Sz，则RB1在该链接上发送的颤音Hellos中为每个邻接播发最大的测试X，并且RB1可以在RB1的LSP中将X作为链接的属性播发给RB2。
They should read:
它们应为：
If X is not greater than or equal to Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X >= Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
如果X不大于或等于Sz，则RB1在RB1的Hello中为RB2设置“最小MTU测试失败”标志。如果大小X成功，且X>=Sz，则RB1在该链接上发送的颤音Hellos中为每个邻接播发最大的测试X，并且RB1可以在RB1的LSP中将X作为链接的属性播发给RB2。
originatingL1LSPBufferSize is the maximum permitted size of LSPs starting with the 0x83 Intradomain Routeing Protocol Discriminator byte. In Layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492 bytes. (This is because, in its previous life as DECnet Phase V, IS-IS was encoded using the SNAP SAP (Subnetwork Access Protocol Service Access Point) [RFC7042] format, which takes 8 bytes of overhead and 1492 + 8 = 1500, the classic Ethernet maximum. When standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC) encoding, this default could have been increased by a few bytes but was not.)
originatingL1LSPBufferSize是从0x83域内路由协议鉴别器字节开始的LSP的最大允许大小。在第3层IS-IS中，原始L1LSPBufferSize默认为1492字节。（这是因为，在其之前的DECnet阶段V中，is-is是使用SNAP SAP（子网访问协议服务访问点）[RFC7042]格式编码的，该格式需要8字节的开销和1492+8=1500，这是典型的以太网最大值。当ISO/IEC[is-is]标准化时，使用逻辑链路控制（LLC）编码时，此默认值可以增加几个字节，但没有。）
In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This allows 27 bytes of headroom or safety margin to accommodate legacy devices with the classic Ethernet maximum MTU despite headers such as an Outer.VLAN.
在TRILL中，originatingL1LSPBufferSize默认为1470字节。这允许27字节的净空或安全裕度，以容纳具有经典以太网最大MTU的传统设备，而不考虑诸如Outer.VLAN之类的标头。
Assuming the campus-wide minimum link MTU is Sz, RBridges on Ethernet links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of the PDU starting just after the L2-IS-IS Ethertype and ending just before the Ethernet Frame Check Sequence (FCS)) does not to exceed Sz. The PDU exceptions are TRILL Hello PDUs, which MUST NOT exceed 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded, depending on the size being tested (which may exceed Sz).
假设校园范围内的最小链路MTU为Sz，以太网链路上的RBridge必须限制大多数TRILL is-is PDU，以便PDUz（PDU的长度在L2-is-is以太类型之后开始，在以太网帧检查序列（FCS）之前结束）不超过Sz。PDU例外情况包括TRILL Hello PDU（不得超过1470字节）和MTU probe和MTU ack PDU（填充），具体取决于测试的大小（可能超过Sz）。
Sz does not limit TRILL Data frames. They are only limited by the MTU of the devices and links that they actually pass through; however, links that can accommodate IS-IS PDUs up to Sz would accommodate, with a generous safety margin, TRILL Data frame payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending just before the FCS. Most modern Ethernet equipment has ample headroom for frames with extensive headers and is sometimes engineered to accommodate 9K byte jumbo frames.
Sz不限制颤音数据帧。它们仅受实际通过的设备和链路的MTU限制；然而，能够容纳IS-IS PDU至Sz的链路将能够容纳（Sz-24）字节的TRILL数据帧有效负载，具有较大的安全裕度，从Inner.VLAN之后开始，在FCS之前结束。大多数现代以太网设备都有足够的净空空间来容纳具有大量报头的帧，并且有时设计为容纳9K字节的巨型帧。
Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports but may not be completely clear on the effects of various combinations of bits.
[RFC6325]第4.9.1节规定了RBridge端口的四种模式位，但可能不完全清楚各种位组合的影响。
The table below explicitly indicates the effect of all possible combinations of the TRILL port mode bits. "*" in one of the first four columns indicates that the bit can be either zero or one. The following columns indicate allowed frame types. The Disable bit normally disables all frames, but, as an implementation choice, some or all low-level Layer 2 control frames (as specified in [RFC6325], Section 1.4) can still be sent or received.
下表明确说明了TRILL端口模式位的所有可能组合的效果。前四列中的一列中的“*”表示该位可以是零或一。以下列表示允许的框架类型。禁用位通常禁用所有帧，但作为一种实现选择，仍然可以发送或接收部分或所有低级别第2层控制帧（如[RFC6325]第1.4节中所述）。
+-+-+-+-+--------+-------+-----+-----+-----+
|D| | | | | | | | |
|i| |A| | | |TRILL| | |
|s| |c|T| | |Data | | |
|a| |c|r| | | | | |
|b|P|e|u| |native | LSP | | |
|l|2|s|n|Layer 2 |ingress| SNP |TRILL| P2P |
|e|P|s|k|Control |egress | MTU |Hello|Hello|
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|0|0| Yes | Yes | Yes | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|0|1| Yes | No | Yes | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|1|0| Yes | Yes | No | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|1|1| Yes | No | No | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|1|0|*| Yes | No | Yes | No | Yes |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|1|1|*| Yes | No | No | No | Yes |
+-+-+-+-+--------+-------+-----+-----+-----+
|1|*|*|*|Optional| No | No | No | No |
+-+-+-+-+--------+-------+-----+-----+-----+
+-+-+-+-+--------+-------+-----+-----+-----+
|D| | | | | | | | |
|i| |A| | | |TRILL| | |
|s| |c|T| | |Data | | |
|a| |c|r| | | | | |
|b|P|e|u| |native | LSP | | |
|l|2|s|n|Layer 2 |ingress| SNP |TRILL| P2P |
|e|P|s|k|Control |egress | MTU |Hello|Hello|
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|0|0| Yes | Yes | Yes | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|0|1| Yes | No | Yes | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|1|0| Yes | Yes | No | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|1|1| Yes | No | No | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|1|0|*| Yes | No | Yes | No | Yes |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|1|1|*| Yes | No | No | No | Yes |
+-+-+-+-+--------+-------+-----+-----+-----+
|1|*|*|*|Optional| No | No | No | No |
+-+-+-+-+--------+-------+-----+-----+-----+
(The formal name of the "access bit" is the "TRILL traffic disable bit", and the formal name of the "trunk bit" is the "end-station service disable bit" [RFC6325].)
（访问位的正式名称为“TRILL流量禁用位”，“中继位”的正式名称为“终端站服务禁用位”[RFC6325]。）
In May 2011, the IEEE promulgated [802.1Q-2011], which changes the meaning of the bit between the priority and VLAN ID bits in the payload of C-VLAN tags. Previously, this bit was called the CFI (Canonical Format Indicator) bit [802] and had a special meaning in connection with IEEE 802.5 (Token Ring) frames. Now, under [802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar to that bit in S-VLAN/B-VLAN tags where this bit has always been a DEI bit.
2011年5月，IEEE颁布了[802.1Q-2011]，改变了C-VLAN标签有效载荷中优先级和VLAN ID位之间的位的含义。在此之前，该位被称为CFI（规范格式指示符）位[802]，在IEEE 802.5（令牌环）帧中具有特殊意义。现在，在[802.1Q-2011]下，它是一个DEI（丢弃合格性指示器）位，类似于S-VLAN/B-VLAN标记中的该位，其中该位始终是一个DEI位。
The TRILL base protocol specification [RFC6325] assumed, in effect, that the link by which end stations are connected to TRILL Switches and the restricted virtual link provided by the TRILL Data frame are IEEE 802.3 Ethernet links on which the CFI bit is always zero. Should an end station be attached by some other type of link, such as a Token Ring link, [RFC6325] implicitly assumed that such frames would be canonicalized to 802.3 frames before being ingressed, and similarly, on egress, such frames would be converted from 802.3 to the appropriate frame type for the link. Thus, [RFC6325] required
TRILL基本协议规范[RFC6325]实际上假设，终端站连接到TRILL交换机的链路和TRILL数据帧提供的受限虚拟链路是IEEE 802.3以太网链路，其CFI位始终为零。如果终端站通过某种其他类型的链路（例如令牌环链路）连接，则[RFC6325]隐含地假设，在进入之前，这些帧将被规范化为802.3帧，并且类似地，在出口时，这些帧将从802.3转换为链路的适当帧类型。因此，需要[RFC6325]
that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in Section 4.1.1 of [RFC6325], always be zero.
INTERNAR.VLAN中的CFI位（在[RFC6325]第4.1.1节中显示为“C”位）始终为零。
However, for TRILL Switches with ports conforming to the change incorporated in the IEEE 802.1Q-2011 standard, the bit in the Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by the EISS (Enhanced Internal Sublayer Service) interface on ingressing a native frame. Similarly, this bit MUST be provided to the EISS when transiting or egressing a TRILL Data frame. As with the 3-bit Priority field, the DEI bit to use in forwarding a transit frame MUST be taken from the Inner.VLAN. The exact effect on the Outer.VLAN DEI and priority bits and whether or not an Outer.VLAN appears at all on the wire for output frames may depend on output port configuration.
但是，对于端口符合IEEE 802.1Q-2011标准中所包含更改的TRILL交换机，Inner.VLAN中的位（现在是DEI位）必须设置为EISS（增强内部子层服务）接口在进入本机帧时提供的DEI值。类似地，在传输或输出颤音数据帧时，必须向EIS提供该位。与3位优先级字段一样，转发传输帧时使用的DEI位必须取自Inner.VLAN。对Outer.VLAN DEI和优先级位的确切影响以及Outer.VLAN是否出现在输出帧的线路上可能取决于输出端口配置。
TRILL campuses with a mixture of ports, some compliant with [802.1Q-2011] and some compliant with pre-802.1Q-2011 standards, especially if they have actual Token Ring links, may operate incorrectly and may corrupt data, just as a bridged LAN with such mixed ports and links would.
TRILL校园混合使用端口，有些符合[802.1Q-2011]标准，有些符合802.1Q-2011之前的标准，特别是如果它们有实际的令牌环链路，可能会运行不正确并损坏数据，就像使用这种混合端口和链路的桥接LAN一样。
TRILL Switches SHOULD support the features specified in [RFC5306], which describes a mechanism for a restarting IS-IS router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating link-state database synchronization.
TRILL交换机应支持[RFC5306]中规定的功能，该功能描述了一种重新启动IS-IS路由器的机制，以向其邻居发出重新启动的信号，使其能够在不通过关闭状态循环的情况下重新建立其邻接，同时仍能正确启动链路状态数据库同步。
[RFC6327] provides for multiple states of the potential adjacency between two TRILL Switches. It makes clear that only an adjacency in the "Report" state is reported in LSPs. LSP synchronization (LSP and Subnetwork Point (SNP) transmission and receipt), however, is performed if and only if there is at least one adjacency on the link in either the "2-Way" or "Report" state.
[RFC6327]提供了两个颤音开关之间潜在邻接的多种状态。它清楚地表明，LSP中只报告“报告”状态中的邻接。然而，LSP同步（LSP和子网点（SNP）传输和接收）仅在链路上至少有一个邻接处于“双向”或“报告”状态时执行。
To support the PORT-TRILL-VER sub-TLV specified in [RFC7176], the following updates are made to [RFC6327]:
为支持[RFC7176]中指定的PORT-TRILL-VER子TLV，对[RFC6327]进行了以下更新：
1. The first sentence of the last paragraph in [RFC6327] Section 3.1 is modified from
1. [RFC6327]第3.1节最后一段的第一句修改如下：
All TRILL LAN Hellos issued by an RBridge on a particular port MUST have the same source MAC address, priority, desired Designated VLAN, and Port ID, regardless of the VLAN in which the Hello is sent.
由特定端口上的RBridge发出的所有TRILL LAN Hello必须具有相同的源MAC地址、优先级、所需的指定VLAN和端口ID，而不考虑发送Hello的VLAN。
to
到
All TRILL LAN Hellos issued by an RBridge on a particular port MUST have the same source MAC address, priority, desired Designated VLAN, Port ID, and PORT-TRILL-VER sub-TLV [RFC7176] if included, regardless of the VLAN in which the Hello is sent.
由特定端口上的RBridge发出的所有TRILL LAN Hello必须具有相同的源MAC地址、优先级、所需的指定VLAN、端口ID和port-TRILL-VER子TLV[RFC7176]，如果包括在内，则与发送Hello的VLAN无关。
2. An additional bullet item is added to the end of Section 3.2 of [RFC6327] as follows:
2. [RFC6327]第3.2节末尾增加了一个额外的项目符号，如下所示：
o The five bytes of PORT-TRILL-VER sub-TLV data received in the most recent TRILL Hello from the neighbor RBridge.
o 在最近的TRILL Hello中从邻居RBridge接收到的五个字节的PORT-TRILL-VER子TLV数据。
3. In Section 3.3 of [RFC6327], near the bottom of page 12, a bullet item as follows is added:
3. 在[RFC6327]第3.3节第12页底部附近，添加了一个项目符号，如下所示：
o The five bytes of PORT-TRILL-VER sub-TLV data are set from that sub-TLV in the Hello or set to zero if that sub-TLV does not occur in the Hello.
o PORT-TRILL-VER子TLV数据的五个字节在Hello中从该子TLV设置，或者如果该子TLV未在Hello中出现，则设置为零。
4. At the beginning of Section 4 of [RFC6327], a bullet item is added to the list as follows:
4. 在[RFC6327]第4节开头，列表中添加了一个项目符号，如下所示：
o The five bytes of PORT-TRILL-VER sub-TLV data used in TRILL Hellos sent on the port.
o 在端口上发送的TRILL Hello中使用的五个字节的PORT-TRILL-VER子TLV数据。
An optional method of Hello reduction is specified in Section 10.1 below and a recommendation on forwarder appointments in the face of overload is given in Section 10.2.
下文第10.1节规定了减少Hello的可选方法，第10.2节给出了在超载情况下任命货运代理的建议。
If a network manager has sufficient confidence that it knows the configuration of bridges, ports, and the like, within a link, it may be able to reduce the number of TRILL Hellos sent on that link; for example, if all RBridges on the link will see all Hellos regardless of VLAN constraints, Hellos could be sent on fewer VLANs. However, because adjacencies are established in the Designated VLAN, an RBridge MUST always attempt to send Hellos in the Designated VLAN. Hello reduction makes TRILL less robust in the face of decreased VLAN connectivity in a link such as partitioned VLANs, many 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, can see each other's frames in that VLAN, and utilize the mechanisms specified below to update VLAN inhibition
如果网络管理器有足够的信心知道链路内的网桥、端口等的配置，则其可能能够减少在该链路上发送的颤音hello的数量；例如，如果链路上的所有RBridge都将看到所有Hello，而不考虑VLAN约束，则可以在更少的VLAN上发送Hello。但是，由于邻接是在指定的VLAN中建立的，因此RBridge必须始终尝试在指定的VLAN中发送HELOS。Hello Reduce使TRILL在链路中的VLAN连接减少（如分区VLAN、端口上禁用了许多VLAN或在指定VLAN上存在分歧）时变得不那么健壮；但是，只要链路上的所有RBridge端口配置为相同的期望指定VLAN，就可以在该VLAN中看到彼此的帧，并利用下面指定的机制来更新VLAN
timers, operations will be safe. (These considerations 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 and no native frame end-station service is provided.)
计时器，操作将是安全的。（在配置为点对点的RBridge之间的链路上不会出现这些注意事项，因为在这种情况下，每个RBridge仅在其认为是链路的指定VLAN的位置发送点对点Hello、其他TRILL IS-IS PDU和TRILL数据帧，并且不提供本机帧端站服务。）
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 [RFC6439] is still required. Under Section 3 of [RFC6439], 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, thus extending Section 3, Item 4, of [RFC6439]. Two such mechanisms are specified below. Support for both of these mechanisms is indicated by a capability bit in the PORT-TRILL-VER sub-TLV (see Section 9 above and [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 [RFC6327]) indicate support of these mechanisms and these mechanisms are in use.
为了在偶尔丢失帧、RBridge故障、链路故障、链路上出现新RBridge等情况下保持环路安全，仍然需要[RFC6439]中规定的抑制机制。根据[RFC6439]的第3节，只能通过接收VLAN中发送或接收的Hello来设置VLAN抑制计时器。因此，为了在数量减少的VLAN上安全地发送数量减少的TRILL Hello，需要在RBridge上设置VLAN抑制计时器的额外机制，从而扩展了[RFC6439]第3节第4项。下面具体说明了两种这样的机制。PORT-TRILL-VER子TLV中的能力位表明了对这两种机制的支持（参见上文第9节和[RFC7176]）。如果RBridge在链路上发送的VLAN少于[RFC6325]中建议的VLAN集，则可能不安全，除非该链路上的所有相邻VLAN（不包括处于关闭状态的[RFC6327]）表明支持这些机制，并且这些机制正在使用。
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 Appointed Forwarder sub-TLV MUST be the same as the Sender Nickname in the Special VLANs and Flags sub-TLV in the TRILL Hello. This indicates the sending RBridge believes it is Appointed Forwarder for those VLANs. An RBridge receiving such a sub-TLV sets each of its VLAN inhibition timers for every VLAN in the block or blocks listed in the Appointed Forwarders sub-TLV to the maximum of its current value and the Holding Time of the Hello containing the sub-TLV. This is backward compatible because such sub-TLVs will have no effect on any receiving RBridge not implementing this mechanism unless RB2 is the DRB (Designated RBridge) sending Hello on the Designated VLAN, in which case, as specified in [RFC6439], RB2 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中的指定者昵称字段必须与TRILL Hello中特殊VLAN和Flags子TLV中的发送者昵称相同。这表示发送RBridge相信它是这些VLAN的指定转发器。接收这种子TLV的RBridge将其块中或指定转发器子TLV中列出的块中的每个VLAN的每个VLAN抑制定时器设置为其当前值和包含子TLV的Hello的保持时间的最大值。这是向后兼容的，因为此类子TLV不会对任何未实现此机制的接收RBridge产生影响，除非RB2是在指定VLAN上发送Hello的DRB（指定RBridge），在这种情况下，如[RFC6439]中所述，RB2必须包括Hello all forwarder预约（如有），用于链接上除自身以外的其他RBridge。
2. An RBridge MAY use the new 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 the maximum of its current value and the Holding Time of the TRILL Hello containing the VLANs Appointed sub-TLV. 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。每个这样的计时器都会更新到其当前值的最大值以及包含VLAN指定子TLV的TRILL Hello的保持时间。此子TLV将是RBridges未实现的未知子TLV，且此类RBridges将忽略它。即使DRB在指定VLAN上发送的TRILL Hello包括一个或多个VLAN指定的子TLV，只要没有指定的转发器子TLV出现，Hello也不需要指示所有转发器指定。
Two different encodings are providing 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 it is Appointed Forwarder for the VLAN in which the Hello is sent. 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 MUST be 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 it is Appointed Forwarder in a Hello sent on the Designated VLAN three times per Holding Time.
上面提供了两种不同的编码来优化VLAN列表。使用指定的转发器子TLV对大块连续VLAN进行更有效的编码，使用VLAN指定的子TLV对分散的VLAN进行更有效的编码。这些编码可以在同一个Hello中混合使用。这些子TLV的使用不影响特殊VLAN和标志子TLV中的“AF”位必须设置的要求，前提是始发RBridge认为它是发送Hello的VLAN的指定转发器。如果在链路上使用上述机制，则链路上的每个RBridge必须使用指定的VLAN子TLV和/或自指定的转发器子TLV在一个或多个VLAN中发送HELOS，并且必须适当设置“AF”位，以确保除非丢失三个或更多HELO，否则VLAN抑制计时器不会不正确地过期。例如，RBridge可以在每个等待时间在指定VLAN上发送三次Hello，宣布其认为是指定转发器的所有VLAN。
An RBridge in overload (see Section 2) will, in general, do a poorer job of ingressing and forwarding frames than an RBridge not in overload that has full knowledge of the campus topology. For example, an overloaded RBridge may not be able to distribute multi-destination TRILL Data frames at all.
一般来说，与完全了解校园拓扑结构的非过载RBridge相比，处于过载状态的RBridge（参见第2节）在进入和转发帧方面的性能较差。例如，过载的RBridge可能根本无法分发多目标TRILL数据帧。
Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an Appointed Forwarder unless there is no alternative. Furthermore, if an Appointed Forwarder becomes overloaded, the DRB SHOULD re-assign VLANs from the overloaded RBridge to another RBridge on the link that is not overloaded, if one is available. DRB election is not affected by overload.
因此，除非没有其他选择，否则DRB不应指定超载的RBridge作为指定的货运代理。此外，如果指定的转发器过载，DRB应将VLAN从过载的RBridge重新分配给链路上未过载的另一个RBridge（如果有）。DRB选举不受超载影响。
A counter-example would be if all campus end stations in VLAN-x were on links attached to RB1 via ports where VLAN-x was enabled. In such a case, RB1 SHOULD be made the VLAN-x Appointed Forwarder on all such links even if RB1 is overloaded.
反例是，如果VLAN-x中的所有校园终端站都位于通过启用VLAN-x的端口连接到RB1的链路上。在这种情况下，即使RB1过载，也应使RB1成为所有此类链路上VLAN-x指定的转发器。
The following IANA actions have been completed.
以下IANA行动已经完成。
1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated for use in the TRILL Header Egress Nickname field to indicate an OOMF (Overload Originated Multi-destination Frame).
1. [RFC6325]保留的昵称0xFFC1分配用于TRILL报头出口昵称字段中，以指示OOMF（源自过载的多目标帧）。
2. Bit 1 from the seven previously reserved (RESV) bits in the per-neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is allocated to indicate that the RBridge sending the TRILL Hello volunteers to provide the OOMF forwarding service described in Section 2.4.2 to such frames originated by the TRILL Switch whose SNPA (MAC address) appears in that Neighbor RECORD. The description of this bit is "Offering OOMF service".
2. TRILL neighbor TLV[RFC7176]中每邻居“邻居记录”中七个先前保留（RESV）位中的位1被分配，以指示发送TRILL Hello的RBridge自愿向其SNPA（MAC地址）的TRILL交换机发起的帧提供第2.4.2节中所述的OOMF转发服务出现在该邻居记录中。此位的描述为“提供OOMF服务”。
3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub-TLV [RFC7176] and the VLAN inhibition setting mechanisms specified in Section 10.1. The description of this bit is "Hello reduction support".
3. 比特0是从PORT-TRILL-VER子TLV[RFC7176]中的能力比特分配的，以表示支持指定的VLAN子TLV[RFC7176]和第10.1节中规定的VLAN抑制设置机制。该位的描述是“Hello reduction support”。
This memo improves the documentation of the TRILL protocol, corrects five errata in [RFC6325], and updates [RFC6325], [RFC6327], and [RFC6439]. It does not change the security considerations of these RFCs.
本备忘录改进了TRILL协议的文档，更正了[RFC6325]中的五个勘误表，并更新了[RFC6325]、[RFC6327]和[RFC6439]。它不会改变这些RFC的安全注意事项。
The contributions of the following individuals are gratefully acknowledged: Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia Perlman, Mike Shand, Meral Shirazipour, and Varun Varshah.
感谢以下个人的贡献：Somnath Chatterjee、魏国豪、Rakesh Kumar、李益洲、Radia Perlman、Mike Shand、Meral Shirazipour和Varun Varsah。
[802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
[802.1Q-2011]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE标准802.1Q-2011，2011年8月。
[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", Second Edition, November 2002.
[IS-IS]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，第二版，2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[RFC5306]Shand，M.和L.Ginsberg，“IS-IS的重启信号”，RFC 5306，2008年10月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，2011年7月。
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011.
[RFC6327]东湖第三大道、佩尔曼大道、加瓦尼大道、杜特大道和V.曼拉尔大道，“路由桥（RBridges）：邻近”，RFC 6327，2011年7月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 64392011年11月。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，2014年5月。
[802] IEEE 802, "IEEE Standard for Local and metropolitan area networks: Overview and Architecture", IEEE Std 802.1-2001, 8 March 2002.
[802]IEEE 802，“局域网和城域网的IEEE标准：概述和体系结构”，IEEE标准802.1-2001，2002年3月8日。
[Err3002] RFC Errata, Errata ID 3002, RFC 6325, <http://www.rfc-editor.org>.
[Err3002]RFC勘误表，勘误表ID 3002，RFC 6325<http://www.rfc-editor.org>.
[Err3003] RFC Errata, Errata ID 3003, RFC 6325, <http://www.rfc-editor.org>.
[Err3003]RFC勘误表，勘误表ID 3003，RFC 6325<http://www.rfc-editor.org>.
[Err3004] RFC Errata, Errata ID 3004, RFC 6325, <http://www.rfc-editor.org>.
[Err3004]RFC勘误表，勘误表ID 3004，RFC 6325<http://www.rfc-editor.org>.
[Err3052] RFC Errata, Errata ID 3052, RFC 6325, <http://www.rfc-editor.org>.
[Err3052]RFC勘误表，勘误表ID 3052，RFC 6325<http://www.rfc-editor.org>.
[Err3053] RFC Errata, Errata ID 3053, RFC 6325, <http://www.rfc-editor.org>.
[Err3053]RFC勘误表，勘误表ID 3053，RFC 6325<http://www.rfc-editor.org>.
[Err3508] RFC Errata, Errata ID 3508, RFC 6325, <http://rfc-editor.org>.
[Err3508]RFC勘误表，勘误表ID 3508，RFC 6325<http://rfc-editor.org>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，2013年10月。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge信道支持”，RFC 7178，2014年5月。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA
美国马萨诸塞州米尔福德海狸街155号唐纳德东湖第三华为研发有限公司01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies Co., Ltd Huawei Building, No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District, Beijing 100095 P.R. China
中国北京市海淀区创业科技十番园北青路Z园156号华为大厦
EMail: zhangmingui@huawei.com
EMail: zhangmingui@huawei.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450美国加利福尼亚州圣克拉拉大美洲公园路95054
EMail: anoop@alumni.duke.edu
EMail: anoop@alumni.duke.edu
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
Vishwas Manral Ionios公司，美国加利福尼亚州圣何塞摩尔帕克大道4100号，邮编95117
EMail: vishwas@ionosnetworks.com
EMail: vishwas@ionosnetworks.com
Ayan Banerjee Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
美国加利福尼亚州桑尼维尔西伊夫林大道1089号Ayan Banerjee Cumulus Networks 94086
EMail: ayabaner@gmail.com
EMail: ayabaner@gmail.com