Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8377 M. Zhang
Updates: 6325, 7177 Huawei
Category: Standards Track A. Banerjee
ISSN: 2070-1721 Cisco
July 2018
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8377 M. Zhang
Updates: 6325, 7177 Huawei
Category: Standards Track A. Banerjee
ISSN: 2070-1721 Cisco
July 2018
Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
大量链路的透明互连（TRILL）：多拓扑
Abstract
摘要
This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177.
本文件规定了IETF TRILL（大量链路的透明互连）协议的扩展，以支持基于RFC 5120中规定的IS-IS（中间系统到中间系统）多拓扑的单播和多目的地流量的多拓扑路由。本文件更新了RFCs 6325和7177。
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 https://www.rfc-editor.org/info/rfc8377.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8377.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................4
2. Topologies ......................................................5
2.2. Links and Multi-Topology ...................................5
2.3. TRILL Switches and Multi-Topology ..........................6
2.4. TRILL Data Packets and Multi-Topology ......................6
2.4.1. Explicit Topology Labeling Support ..................7
2.4.2. The Explicit Topology Label .........................8
2.4.3. TRILL Use of the MT Label ...........................8
3. TRILL Multi-Topology Adjacency and Routing .....................10
3.1. Adjacency .................................................10
3.2. TRILL Switch Nicknames ....................................10
3.3. TRILL Unicast Routing .....................................11
3.4. TRILL Multi-Destination Routing ...........................11
3.4.1. Distribution Trees .................................11
3.4.2. Multi-Access Links .................................13
4. Mixed Links ....................................................13
5. Other Multi-Topology Considerations ............................14
5.1. Address Learning ..........................................14
5.1.1. Data Plane Learning ................................14
5.1.2. Multi-Topology ESADI ...............................14
5.2. Legacy Stubs ..............................................14
5.3. RBridge Channel Messages ..................................14
5.4. Implementations Considerations ............................15
6. Allocation Considerations ......................................15
6.1. IEEE Registration Authority Considerations ................15
6.2. IANA Considerations .......................................15
7. Security Considerations ........................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Appendix A. Differences from RFC 5120 .............................19
Acknowledgements ..................................................19
Authors' Addresses ................................................20
1. Introduction ....................................................2
1.1. Terminology ................................................4
2. Topologies ......................................................5
2.2. Links and Multi-Topology ...................................5
2.3. TRILL Switches and Multi-Topology ..........................6
2.4. TRILL Data Packets and Multi-Topology ......................6
2.4.1. Explicit Topology Labeling Support ..................7
2.4.2. The Explicit Topology Label .........................8
2.4.3. TRILL Use of the MT Label ...........................8
3. TRILL Multi-Topology Adjacency and Routing .....................10
3.1. Adjacency .................................................10
3.2. TRILL Switch Nicknames ....................................10
3.3. TRILL Unicast Routing .....................................11
3.4. TRILL Multi-Destination Routing ...........................11
3.4.1. Distribution Trees .................................11
3.4.2. Multi-Access Links .................................13
4. Mixed Links ....................................................13
5. Other Multi-Topology Considerations ............................14
5.1. Address Learning ..........................................14
5.1.1. Data Plane Learning ................................14
5.1.2. Multi-Topology ESADI ...............................14
5.2. Legacy Stubs ..............................................14
5.3. RBridge Channel Messages ..................................14
5.4. Implementations Considerations ............................15
6. Allocation Considerations ......................................15
6.1. IEEE Registration Authority Considerations ................15
6.2. IANA Considerations .......................................15
7. Security Considerations ........................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Appendix A. Differences from RFC 5120 .............................19
Acknowledgements ..................................................19
Authors' Addresses ................................................20
This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7177] [RFC7780] to support multi-topology routing for both unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) [IS-IS] multi-topology [RFC5120]. Implementation and use of multi-topology are optional, and use requires configuration. It is anticipated that not all TRILL campuses will need or use multi-topology.
本文件规定了IETF TRILL（大量链路的透明互连）协议[RFC6325][RFC7177][RFC7780]的扩展，以支持基于IS-IS（中间系统到中间系统）[IS-IS]多拓扑[RFC5120]的单播和多目的地流量的多拓扑路由。多拓扑的实现和使用是可选的，使用需要配置。预计并非所有TRILL校区都需要或使用多拓扑。
Multi-topology creates different topologies or subsets from a single physical TRILL campus topology. This is different from Data Labels (VLANs and Fine-Grained Labels (FGLs) [RFC7172]). Data Labels specify communities of end stations and can be viewed as creating virtual topologies of end station connectivity. However, in a single topology TRILL campus, TRILL Data packets can use any part of the physical topology of TRILL switches and links between TRILL switches, regardless of the Data Label of that packet's payload. In a multi-topology TRILL campus, TRILL data packets in a topology are restricted to the TRILL switches and links that are in their topology, regardless of the Data Label of their payload.
多拓扑从单个物理TRILL校园拓扑创建不同的拓扑或子集。这不同于数据标签（VLAN和细粒度标签（FGL）[RFC7172]）。数据标签指定端站的社区，可以视为创建端站连接的虚拟拓扑。但是，在单个拓扑TRILL校园中，TRILL数据包可以使用TRILL交换机物理拓扑的任何部分以及TRILL交换机之间的链路，而不管该数据包的有效负载的数据标签如何。在多拓扑TRILL校园中，拓扑中的TRILL数据包仅限于其拓扑中的TRILL交换机和链路，而不考虑其有效负载的数据标签。
The essence of multi-topology behavior is that a multi-topology router classifies packets as to the topology within which they should be routed and uses logically different routing tables for different topologies. If routers in the network do not agree on the topology classification of packets or links, persistent routing loops can occur. It is the responsibility of the network manager to consistently configure multi-topology to avoid such routing loops.
多拓扑行为的本质是多拓扑路由器将数据包分类为应该在其中路由的拓扑，并为不同的拓扑使用逻辑上不同的路由表。如果网络中的路由器对数据包或链路的拓扑分类不一致，则可能发生持久路由循环。网络管理器负责一致地配置多拓扑以避免此类路由循环。
The multi-topology TRILL extensions can be used for a wide variety of purposes, such as maintaining separate routing domains for isolated multicast or IPv6 islands, routing a class of traffic so that it avoids certain TRILL switches that lack some characteristic needed by that traffic, or making a class of traffic avoid certain links due to security, reliability, or other concerns.
多拓扑TRILL扩展可用于多种用途，例如为独立多播或IPv6孤岛维护单独的路由域，路由一类流量，以避免某些TRILL交换机缺少该流量所需的某些特性，或者出于安全性、可靠性或其他考虑，使一类流量避免某些链接。
It is possible for a particular topology to not be fully connected, either intentionally or due to node or link failures or incorrect configuration. This results in two or more islands of that topology that cannot communicate. In such a case, end stations connected in that topology to different islands will be unable to communicate with each other.
可能是由于故意或由于节点或链路故障或配置不正确而导致特定拓扑未完全连接。这将导致该拓扑的两个或多个孤岛无法通信。在这种情况下，在该拓扑中连接到不同岛屿的终端站将无法相互通信。
Multi-topology TRILL supports regions of topology-ignorant TRILL switches as part of a multi-topology campus; however, such regions can only ingress to, egress from, or transit TRILL Data packets in the special base topology zero.
多拓扑TRILL支持无拓扑TRILL交换机区域作为多拓扑校园的一部分；然而，这些区域只能进入、离开或传输特殊基本拓扑零中的TRILL数据包。
The terminology and abbreviations of [RFC6325] are used in this document. Some of these are paraphrased below for convenience. Some additional terms are also listed.
本文件中使用了[RFC6325]的术语和缩写。为了方便起见，下面对其中一些内容进行了解释。还列出了一些附加术语。
campus: The name for a TRILL network, like "bridged LAN" is a name for a bridged network. It does not have any academic implication.
校园：TRILL网络的名称，如“桥接LAN”是桥接网络的名称。它没有任何学术意义。
DRB: Designated RBridge [RFC7177].
DRB：指定的RBridge[RFC7177]。
FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained Label [RFC7172]. By implication, an "FGL TRILL switch" does not support Multi-Topology (MT).
FGL：细粒度标签或细粒度标签或细粒度标签[RFC7172]。言下之意，“FGL颤音开关”不支持多拓扑（MT）。
IS: Intermediate System [IS-IS].
IS：中间系统[IS-IS]。
LSP: Link State PDU (Protocol Data Unit) [IS-IS]. For TRILL, this includes Level 1 LSPs and Extended Level 1 Flooding Scope LSPs [RFC7780].
LSP：链路状态PDU（协议数据单元）[IS-IS]。对于TRILL，这包括1级LSP和扩展的1级泛洪范围LSP[RFC7780]。
MT: Multi-Topology [RFC5120].
MT：多拓扑[RFC5120]。
MT TRILL Switch: A TRILL switch supporting the multi-topology feature specified in this document. An MT TRILL switch MUST support FGL in the sense that it MUST be FGL safe [RFC7172].
MT TRILL Switch：支持本文档中指定的多拓扑功能的TRILL Switch。MT颤音开关必须支持FGL，即它必须是FGL安全的[RFC7172]。
RBridge: Routing Bridge; an alternative name for a TRILL switch.
RBridge：路由桥；颤音开关的替代名称。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325].
TRILL：链路层中大量链路的透明互连或隧道路由[RFC6325]。
TRILL Switch: A device implementing the TRILL protocol. TRILL switches are Intermediate Systems (routers) [IS-IS].
颤音开关：实现颤音协议的设备。TRILL交换机是中间系统（路由器）[IS-IS]。
VL: VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172]. By implication, a "VL RBridge" or "VL TRILL switch" does not support FGL or MT.
VL:VLAN标签或VLAN标签或VLAN标签[RFC7172]。言下之意，“VL RBridge”或“VL TRILL switch”不支持FGL或MT。
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]所述进行解释。
In TRILL multi-topology, a topology is a subset of the TRILL switches and of the links between TRILL switches in the TRILL campus. TRILL Data packets are constrained to the subset of switches and links corresponding to the packet's topology. TRILL multi-topology is based on IS-IS multi-topology [RFC5120]. See Appendix A for differences between TRILL multi-topology and [RFC5120].
在TRILL multi topology中，拓扑是TRILL交换机和TRILL园区中TRILL交换机之间链路的子集。TRILL数据包被约束到与包的拓扑结构相对应的交换机和链路的子集。TRILL多拓扑基于is-is多拓扑[RFC5120]。TRILL multi-topology与[RFC5120]之间的差异见附录A。
The zero topology is special, as described in Section 2.1. Sections 2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and TRILL Data packets, respectively.
零拓扑是特殊的，如第2.1节所述。第2.2、2.3和2.4节分别讨论了链路、TRILL交换机和TRILL数据包的拓扑结构。
The zero topology is special as the default base topology. All TRILL switches and links are considered to be in, and MUST support, topology zero. Thus, for example, topology zero can be used for general TRILL switch access within a campus for management messages, Bidirectional Forwarding Detection (BFD) messages [RFC7175], RBridge Channel messages [RFC7178], and the like.
零拓扑作为默认的基本拓扑是特殊的。所有TRILL交换机和链路都被认为是零拓扑，并且必须支持零拓扑。因此，例如，拓扑零可用于校园内用于管理消息、双向转发检测（BFD）消息[RFC7175]、RBridge信道消息[RFC7178]等的一般TRILL交换机接入。
Multi-topology TRILL switches advertise the topologies for which they are willing to send and receive TRILL Data packets on a port by listing those topologies in one or more MT TLVs [RFC5120] appearing in every TRILL Hello [RFC7177] they send out that port, except that they MUST handle topology zero, which it is optional to list.
多拓扑TRILL交换机通过在每个TRILL Hello[RFC7177]中出现的一个或多个MT TLV[RFC5120]中列出它们愿意在端口上发送和接收TRILL数据包的拓扑来宣传这些拓扑，但它们必须处理拓扑零，这是可选的。
A link is usable for TRILL Data packets in non-zero topology T only if:
只有在以下情况下，链路才可用于非零拓扑T中的TRILL数据包：
(1) all TRILL switch ports on the link advertise topology T support in their Hellos, and
(1) 链路上的所有TRILL交换机端口在其Hello中不支持，以及
(2) if any TRILL switch port on the link requires explicit TRILL Data packet topology labeling (see Section 2.4) every other TRILL switch port on the link is capable of generating explicit packet topology labeling.
(2) 如果链路上的任何TRILL交换机端口需要显式TRILL数据包拓扑标记（参见第2.4节），则链路上的每一个其他TRILL交换机端口都能够生成显式数据包拓扑标记。
A TRILL switch advertises the topologies that it supports by listing them in one or more MT TLVs [RFC5120] in its LSP, except that it MUST support topology zero, which is optional to list. For robust and rapid flooding, MT TLV(s) SHOULD be advertised in core LSP fragment zero.
TRILL交换机通过在其LSP中的一个或多个MT TLV[RFC5120]中列出其支持的拓扑来公布其支持的拓扑，但它必须支持拓扑零，拓扑零是列表的可选选项。为了实现稳健快速的注水，MT TLV应在岩芯LSP碎片0中公布。
There is no "MT capability bit". A TRILL switch advertises that it is MT capable by advertising in its LSP support for any topology or topologies with the MT TLV, even if it just explicitly advertises support for topology zero.
没有“MT能力位”。TRILL交换机通过在其LSP中宣传对任何拓扑或具有MT TLV的拓扑的支持来宣传其具有MT能力，即使它只是明确宣传对拓扑零的支持。
The topology of a TRILL Data packet is commonly determined from either (1) some field or fields present in the packet itself or (2) the port on which the packet was received; however, optional explicit topology labeling of TRILL Data packets is also proved. This can be included in the data labeling area of TRILL Data packets as specified below.
TRILL数据包的拓扑结构通常由（1）包本身中存在的一个或多个字段或（2）接收包的端口确定；然而，也证明了TRILL数据包的可选显式拓扑标记。这可以包括在TRILL数据包的数据标签区域中，如下所述。
Examples of fields that might be used to determine topology are values or ranges of values of the payload VLAN or FGL [RFC7172], packet priority, IP version (IPv6 versus IPv4) or IP protocol, Ethertype, unicast versus multi-destination payload, IP Differentiated Services Code Point (DSCP) bits, or the like.
可用于确定拓扑的字段的示例是有效负载VLAN或FGL[RFC7172]的值或值范围、分组优先级、IP版本（IPv6与IPv4）或IP协议、以太网类型、单播与多目的地有效负载、IP区分服务码点（DSCP）位等。
Multi-topology does not apply to TRILL IS-IS packets or to link level control frames. Those messages are link local and can be thought of as being above all topologies. Multi-topology only applies to TRILL Data packets.
多拓扑不适用于TRILL IS-IS数据包或链路级控制帧。这些消息是本地链接的，可以认为是高于所有拓扑的。多拓扑仅适用于TRILL数据包。
Support of the topology label is optional. Support could depend on port hardware and is indicated by a 2-bit capability field in the Port TRILL Version sub-TLV [RFC7176] appearing in the Port Capabilities TLV in Hellos. If there is no Port TRILL Capabilities sub-TLV in a Hello, then it is assumed that explicit topology labeling is not supported on that port. See the table below for the meaning of values of the Explicit Topology capability field:
支持拓扑标签是可选的。支持可能取决于端口硬件，并由Hellos中端口功能TLV中出现的端口TRILL版本子TLV[RFC7176]中的2位功能字段表示。如果Hello中没有端口颤音功能子TLV，则假定该端口不支持显式拓扑标记。显式拓扑能力字段值的含义见下表：
Value Meaning
----- -------
0 No support. Cannot send TRILL Data packets with an
explicit topology label and will likely treat as
erroneous and discard any TRILL Data packet received with
a topology label. Such a port is assumed to have the
ability and configuration to correctly classify TRILL
Data packets into all topologies for which it is
advertising support in its Hellos, either by examining
those packets or because they are arriving at that port.
Value Meaning
----- -------
0 No support. Cannot send TRILL Data packets with an
explicit topology label and will likely treat as
erroneous and discard any TRILL Data packet received with
a topology label. Such a port is assumed to have the
ability and configuration to correctly classify TRILL
Data packets into all topologies for which it is
advertising support in its Hellos, either by examining
those packets or because they are arriving at that port.
1 Capable of inserting an explicit topology label in TRILL Data packets sent and tolerant of such labels in received TRILL Data packets. Such a port is capable, for all of the topologies it supports, of determining TRILL Data packet topology without an explicit label. Thus, it does not require such a label in received TRILL Data packets. On receiving a packet whose explicit topology label differs from the port's topology determination for that packet, the TRILL switch MUST discard the packet.
1能够在发送的TRILL数据包中插入显式拓扑标签，并在接收的TRILL数据包中容忍此类标签。对于它支持的所有拓扑，这样的端口能够在没有明确标签的情况下确定TRILL数据包拓扑。因此，在接收到的TRILL数据包中不需要这样的标签。当接收到其显式拓扑标签不同于端口对该数据包的拓扑确定的数据包时，TRILL交换机必须丢弃该数据包。
2 & 3 Require an explicit topology label in received TRILL Data packets except for topology zero. Any TRILL Data packets received without such a label are classified as being in topology zero. Also capable of inserting an explicit topology label in TRILL Data packets sent. (Values 2 and 3 are treated the same, which is the same as saying that if the 2 bit is on, the 1 bit is ignored.)
2和3在接收到的TRILL数据包中需要明确的拓扑标签，拓扑零除外。没有这样的标签接收到的任何TRILL数据包被分类为拓扑为零。还能够在发送的TRILL数据包中插入显式拓扑标签。（值2和3的处理方式相同，这与表示如果2位打开，则忽略1位相同。）
In a Hello on Port P, a TRILL switch advertising support for topology T but not advertising that it requires explicit topology labeling is assumed to have the ability and configuration to correctly classify TRILL Data packets into topology T by examination of those TRILL Data packets and/or by using the fact that they are arriving at port P.
在端口P上的Hello中，TRILL交换机广告支持拓扑T，但不广告它需要明确的拓扑标签，假定它具有通过检查这些TRILL数据包和/或使用它们到达端口P的事实将TRILL数据包正确分类到拓扑T中的能力和配置。
When a TRILL switch transmits a TRILL Data packet onto a link, if any other TRILL switch on that link requires explicit topology labeling, an explicit topology label MUST be included unless the TRILL Data
当TRILL交换机将TRILL数据包传输到链路上时，如果该链路上的任何其他TRILL交换机需要显式拓扑标签，则必须包括显式拓扑标签，除非TRILL数据
packet is in topology zero, in which case, an explicit topology label MAY be included. If a topology label is not so required, but all other TRILL switches on that link support explicit topology labeling, then such a label MAY be included.
数据包处于拓扑零，在这种情况下，可以包括显式拓扑标签。如果不需要拓扑标签，但该链接上的所有其他TRILL开关都支持显式拓扑标签，则可以包括此类标签。
This section specifies the explicit topology label. Its use by TRILL is specified in Section 2.4.3. This label may be used by other technologies besides TRILL. The MT Label is structured as follows:
本节指定显式拓扑标签。第2.4.3节规定了颤音的使用。除TRILL外，该标签还可用于其他技术。MT标签的结构如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype 0x9A22 | V | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype 0x9A22 | V | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MT Label
图1:MT标签
Where the fields are as follows:
其中字段如下所示：
MT Ethertype: The MT Label Ethertype (see Section 6.1).
MT Ethertype：MT标签Ethertype（见第6.1节）。
V: The version number of the MT Label. This document specifies version zero.
V：MT标签的版本号。此文档指定版本0。
R: A 2-bit reserved field that MUST be sent as zero and ignored on receipt.
R：一个2位保留字段，必须作为零发送，并在接收时忽略。
MT-ID: The 12-bit topology using the topology number space of the MT TLV [RFC5120].
MT-ID：使用MT TLV[RFC5120]的拓扑编号空间的12位拓扑。
With the addition of the version zero MT Label, the four standardized content varieties for the TRILL Data packet data labeling area (the area after the Inner.MacSA -- or Flag Word if the Flag Word is present [RFC7780] -- and before the payload) are as show below. TRILL Data packets received with any other data labeling are discarded. {PRI, D} is a 3-bit priority and a drop eligibility indicator bit [RFC7780].
随着版本zero MT标签的添加，TRILL数据包数据标签区域（Inner.MacSA后面的区域——如果存在标志字，则为标志字[RFC7780]）和有效负载之前的四个标准化内容变体如下所示。使用任何其他数据标签接收的颤音数据包将被丢弃。{PRI，D}是一个3位优先级和一个丢弃合格性指示符位[RFC7780]。
All MT TRILL switches MUST support FGL, in the sense of being FGL safe [RFC7172]; thus, they MUST support all four data labeling area contents shown below. (This requirement is imposed, rather than having FGL support and MT support be independent, to reduce the number of variations in RBridges and simplify testing.)
所有MT颤音开关必须支持FGL，即FGL安全[RFC7172]；因此，它们必须支持下面显示的所有四个数据标签区域内容。（这一要求是强制性的，而不是使FGL支架和MT支架相互独立，以减少RBL支架的变化数量并简化测试。）
1. C-VLAN [RFC6325]
1. C-VLAN[RFC6325]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. FGL [RFC7172]
2. FGL[RFC7172]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. MT C-VLAN [RFC8377]
3. MT C-VLAN[RFC8377]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. MT FGL [RFC8377] [RFC7172]
4. MT FGL[RFC8377][RFC7172]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inclusion or use of S-VLAN or further stacked tags are beyond the scope of this document, but, as stated in [RFC6325], are obvious extensions.
包含或使用S-VLAN或进一步堆叠的标记超出了本文档的范围，但如[RFC6325]所述，这些标记是明显的扩展。
Routing calculations in IS-IS are based on adjacency. Section 3.1 specifies multi-topology TRILL adjacency. Section 3.2 describes the handling of nicknames. Sections 3.3 and 3.4 specify how unicast and multi-destination TRILL multi-topology routing differ from the TRILL base protocol routing.
IS-IS中的路由计算基于邻接。第3.1节规定了多拓扑颤音邻接。第3.2节描述了昵称的处理。第3.3节和第3.4节规定了单播和多目的TRILL多拓扑路由与TRILL基本协议路由的区别。
There is no change in the determination or announcement of adjacency for topology zero, which is as specified in [RFC7177]. When a topology zero adjacency reaches the Report state, as specified in [RFC7177], the adjacency is announced in core LSPs using the Extended Intermediate System Reachability TLV (#22). This will be compatible with any legacy topology-ignorant RBridges that might not support E-L1FS FS-LSPs [RFC7780].
[RFC7177]中规定的拓扑零邻接的确定或宣布没有变化。当拓扑零邻接达到[RFC7177]中规定的报告状态时，使用扩展中间系统可达性TLV（#22）在核心LSP中宣布邻接。这将与可能不支持E-L1FS LSP[RFC7780]的任何传统拓扑兼容。
Adjacency is announced for non-zero topologies in LSPs using the MT Reachable Intermediate Systems TLV (#222) as specified in [RFC5120]. A TRILL switch reports adjacency for non-zero topology T if and only if that adjacency is in the Report state [RFC7177] and the two conditions listed in Section 2.2 are true, namely:
使用[RFC5120]中规定的MT可到达中间系统TLV（#222），宣布LSP中非零拓扑的邻接。颤音开关报告非零拓扑T的邻接，当且仅当该邻接处于报告状态[RFC7177]，且第2.2节中列出的两个条件为真时，即：
1. All the ports on the link are announcing support of topology T.
1. 链路上的所有端口都宣布支持拓扑T。
2. If any port announces that it requires explicit topology labeling (Explicit Topology capability field value 2 or 3), all other ports advertise that they are capable of producing such labeling (Explicit Topology capability field value of 1, 2, or 3).
2. 如果任何端口宣布它需要显式拓扑标记（显式拓扑能力字段值2或3），则所有其他端口都会宣布它们能够生成此类标记（显式拓扑能力字段值1、2或3）。
TRILL switches are usually identified within the TRILL protocol (for example, in the TRILL Header) by nicknames [RFC6325] [RFC7780]. Such nicknames can be viewed as simply 16-bit abbreviation for a TRILL switch's (or pseudo-node's) 7-byte IS-IS System ID. A TRILL switch or pseudo-node can have more than one nickname, each of which identifies it.
TRILL开关通常在TRILL协议中（例如，在TRILL头中）通过昵称[RFC6325][RFC7780]标识。这种昵称可以简单地看作是TRILL交换机（或伪节点）7字节IS-IS系统ID的16位缩写。TRILL交换机或伪节点可以有多个昵称，每个昵称都标识它。
Nicknames are common across all topologies, just as IS-IS System IDs are. Nicknames are determined as specified in [RFC6325] and [RFC7780] using only the Nickname sub-TLVs appearing in Router Capabilities TLVs (#242) advertised by TRILL switches. In particular, the nickname allocation algorithm ignores Nickname sub-TLVs that appear in MT Router Capability TLVs (#144). (However,
昵称在所有拓扑中都很常见，就像IS-IS系统ID一样。根据[RFC6325]和[RFC7780]中的规定，仅使用TRILL交换机公布的路由器功能TLV（#242）中出现的昵称子TLV来确定昵称。特别是，昵称分配算法忽略出现在MT路由器能力TLV（#144）中的昵称子TLV。（但是，
Nickname sub-TLVs that appear in MT Router Capability TLVs with a non-zero topology do affect the choice of distribution tree roots as described in Section 3.4.1.)
如第3.4.1节所述，在具有非零拓扑的MT路由器能力TLV中出现的昵称子TLV确实会影响分配树根的选择。）
To minimize transient inconsistencies, all Nickname sub-TLVs advertised by a TRILL switch for a particular nickname, whether in Router Capability or MT Router Capability TLVs, SHOULD appear in the same LSP PDU. If that is not the case, then all LSP PDUs in which they do occur SHOULD be flooded as an atomic action.
为了尽量减少暂时的不一致性，TRILL交换机为特定昵称播发的所有昵称子TLV，无论是在路由器功能TLV中还是在MT路由器功能TLV中，都应出现在同一LSP PDU中。如果不是这样，那么所有发生它们的LSP PDU都应该作为原子操作被淹没。
TRILL Data packets being TRILL unicast (those with TRILL Header M bit = 0) are routed based on the egress nickname using logically separate forwarding tables per topology T, where each such table has been calculated based on least cost routing within T: that is, only using links and nodes that support T. Thus, the next hop when forwarding TRILL Data packets is determined by a lookup logically based on {topology, egress nickname}.
作为TRILL单播的TRILL数据包（具有TRILL报头M比特=0的数据包）基于出口昵称，使用每个拓扑T的逻辑上独立的转发表进行路由，其中每个这样的表都是基于T内的最小成本路由进行计算的：即，仅使用支持T的链路和节点。因此，转发TRILL数据包时的下一跳由基于{拓扑，出口昵称}的逻辑查找确定。
TRILL sends multi-destination data packets (those packets with TRILL Header M bit = 1) over a distribution tree. Trees are designated by nicknames that appear in the "egress nickname" field of multi-destination TRILL Data packet TRILL Headers. To constrain multi-destination packets to a topology T and still distribute them properly requires the use of a distribution tree constrained to T. Handling such TRILL Data packets and distribution trees in TRILL MT is as described in the subsections below.
TRILL通过分发树发送多目标数据包（TRILL头M位=1的数据包）。树由出现在多目标TRILL数据包TRILL头的“出口昵称”字段中的昵称指定。要将多目标数据包约束到拓扑T并仍然正确地分发它们，需要使用约束到T的分发树。在TRILL MT中处理此类TRILL数据包和分发树如以下小节所述。
General provisions for distribution trees and how those trees are determined are as specified in [RFC6325], [RFC7172], and [RFC7780]. The distribution trees for topology zero are determined as specified in those references and are the same as they would be with topology-ignorant TRILL switches.
[RFC6325]、[RFC7172]和[RFC7780]中规定了分配树的一般规定以及如何确定这些树。拓扑零的分布树是按照这些参考中的规定确定的，与拓扑无关TRILL交换机的分布树相同。
The TRILL distribution tree construction and packet handling for some non-zero topology T are determined as specified in [RFC6325], [RFC7172], and [RFC7780] with the following changes:
根据[RFC6325]、[RFC7172]和[RFC7780]中的规定确定一些非零拓扑T的TRILL分布树构造和数据包处理，并进行以下更改：
o As specified in [RFC5120], only links usable with topology T TRILL Data packets are considered when building a distribution tree for topology T. As a result, such trees are automatically limited to and separately span every internally connected
o 如[RFC5120]所述，在为拓扑T构建分布树时，仅考虑可用于拓扑T TRILL数据包的链路。因此，此类树自动限制并分别跨越每个内部连接的节点
island of topology T. In other words, if non-zero topology T consists of disjoint islands, each distribution tree construction for topology T is local to one such island.
换句话说，如果非零拓扑T由不相交的岛组成，则拓扑T的每个分布树构造都是一个这样的岛的局部。
o Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub-TLV, and Trees Used sub-TLV occurring in an MT Router Capabilities TLV (#144) specifying topology T are used in determining the tree root(s), if any, for a connected area of non-zero topology T.
o 只有指定拓扑T的MT路由器功能TLV（#144）中出现的昵称sub-TLV、Trees sub-TLV、Tree Identifiers sub-TLV和Trees Used sub-TLV用于确定非零拓扑T连接区域的树根（如果有）。
+ There may be non-zero topologies with no multi-destination traffic or, as described in [RFC5120], even topologies with no traffic at all. For example, if only known destination unicast IPv6 TRILL Data packets were in topology T and all multi-destination IPv6 TRILL Data packets were in some other topology, there would be no need for a distribution tree for topology T. For this reason, a Number of Trees to Compute field value of zero in the Trees sub-TLV for the TRILL switch holding the highest priority to be a tree root for a non-zero topology T is honored and causes no distribution trees to be calculated for non-zero topology T. This is different from the base topology zero where, as specified in [RFC6325], a zero Number of Trees to Compute field value causes one tree to be computed.
+ 可能存在无多目的地流量的非零拓扑，或者如[RFC5120]中所述，甚至可能存在根本无流量的拓扑。例如，如果只有已知的目标单播IPv6 TRILL数据包位于拓扑T中，而所有多目标IPv6 TRILL数据包位于其他拓扑中，则不需要拓扑T的分发树。因此，对于持有最高优先级的TRILL交换机，在Trees子TLV中计算字段值为零的许多树是非零拓扑T的树根，并且不会导致为非零拓扑T计算分布树。这与[RFC6325]中指定的基本拓扑零不同，要计算字段值的树数为零会导致计算一棵树。
o Nicknames are allocated as described in Section 3.2. If a TRILL switch advertising that it provides topology T service holds nickname N, the priority of N to be a tree root is given by the tree root priority field of the Nickname sub-TLV that has N in its nickname field and occurs in a topology T MT Router Capabilities TLV advertised by that TRILL switch. If no such Nickname sub-TLV can be found, the priority of N to be a tree root is the default for an FGL TRILL switch as specified in [RFC7172].
o 昵称的分配如第3.2节所述。如果发布其提供拓扑T服务的TRILL交换机拥有昵称N，则昵称子TLV的树根优先级字段给出了N的树根优先级，该昵称子TLV的树根优先级字段在其昵称字段中有N，并且出现在该TRILL交换机发布的拓扑T MT路由器功能TLV中。如果找不到这样的昵称sub-TLV，则按照[RFC7172]中的规定，对于FGL颤音开关，树根的优先级N是默认值。
+ There could be multiple topology T Nickname sub-TLVs for N being advertised for a particular RBridge or pseudo-node, due to transient conditions or errors. In that case, any advertised in a core LSP PDU are preferred to those advertised in an E-L1FS FS-LSP PDU. Within those categories, the one in the lowest numbered fragment is used and if there are multiple in that fragment, the one with the smallest offset from the beginning of the PDU is used.
+ 由于瞬态条件或错误，可能会有多个拓扑T昵称子TLV为N为特定RBridge或伪节点播发。在这种情况下，在核心LSP PDU中的任何广告都优先于在E-L1FS FS-LSP PDU中的广告。在这些类别中，使用编号最低的片段中的一个，如果该片段中有多个片段，则使用从PDU开始偏移量最小的片段。
o Tree pruning for topology T uses only the Interested VLANs sub-TLVs and Interested Labels sub-TLVs [RFC7176] advertised in MT Router Capabilities TLVs for topology T.
o 拓扑T的树修剪仅使用拓扑T的MT路由器功能TLV中公布的感兴趣的VLAN子TLV和感兴趣的标签子TLV[RFC7176]。
An MT TRILL switch MUST have logically separate routing tables per topology for the forwarding of multi-destination traffic.
MT TRILL交换机必须为每个拓扑具有逻辑上独立的路由表，以便转发多目标流量。
Multi-destination TRILL Data packets are forwarded on broadcast (multi-access) links in such a way as to be received by all other TRILL switch ports on the link. For example, on Ethernet links they are sent with a multicast Outer.MacDA [RFC6325]. Care must be taken that a TRILL Data packet in a non-zero topology is only forwarded by an MT TRILL switch.
多目的地颤音数据包在广播（多址）链路上转发，以便链路上的所有其他颤音交换机端口接收。例如，在以太网链路上，它们通过多播Outer.MacDA[RFC6325]发送。必须注意，非零拓扑中的TRILL数据包只能由MT TRILL交换机转发。
For this reason, a non-zero topology TRILL Data packet MUST NOT be forwarded onto a link unless the link meets the requirements specified in Section 2.2 for use in that topology even if there are one or more MT TRILL switch ports on the link.
因此，非零拓扑TRILL数据包不得转发到链路上，除非链路满足第2.2节中规定的用于该拓扑的要求，即使链路上有一个或多个MT TRILL交换机端口。
There might be any combination of MT, FGL, or even VL TRILL switches [RFC7172] on a link. DRB (Designated RBridge) election and Forwarder appointment on the link work as previously specified in [RFC8139] and [RFC7177]. It is up to the network manager to configure and manage the TRILL switches on a link so that the desired switch is DRB and the desired switch is the Appointed Forwarder for the appropriate VLANs.
链路上可能有MT、FGL甚至VL颤音开关[RFC7172]的任意组合。按照[RFC8139]和[RFC7177]中的规定，选择DRB（指定RBRIGE）并任命承运商从事链接工作。由网络管理器配置和管理链路上的TRILL交换机，以便所需交换机为DRB，所需交换机为相应VLAN的指定转发器。
Frames ingressed by MT TRILL switches can potentially be in any topology recognized by the switch and permitted on the ingress port. Frames ingressed by VL or FGL TRILL switches can only be in the base zero topology. Because FGL and VL TRILL switches do not understand topologies, all occurrences of the following sub-TLVs MUST occur only in MT Port Capability TLVs with a zero MT-ID. Any occurrence of these sub-TLVs in an MT Port Capability TLV with a nonzero MT-ID is ignored.
MT TRILL交换机进入的帧可能位于交换机识别的任何拓扑中，并且在入口端口上允许。VL或FGL颤音开关进入的帧只能在基零拓扑中。由于FGL和VL TRILL交换机不了解拓扑结构，因此以下子TLV的所有出现必须仅出现在MT-ID为零的MT端口能力TLV中。这些子TLV在MT-ID为非零的MT端口能力TLV中的任何出现都将被忽略。
Special VLANs and Flags Sub-TLV Enabled-VLANs Sub-TLV Appointed Forwarders Sub-TLV VLANs Appointed Sub-TLV
特殊VLAN和标志子TLV启用VLAN子TLV指定转发器子TLV VLAN指定子TLV
Native frames cannot be explicitly labeled (see Section 2.4) as to their topology.
本机框架的拓扑结构不能明确标记（见第2.4节）。
The learning of end station Media Access Control (MAC) addresses is per topology as well as per label (VLAN or FGL). The same MAC address can occur within a TRILL campus for different end stations that differ only in topology without confusion.
终端站媒体访问控制（MAC）地址的学习是根据拓扑和标签（VLAN或FGL）进行的。相同的MAC地址可以出现在TRILL校园内，用于不同的终端站，这些终端站仅在拓扑结构上不同，不会造成混乱。
End station MAC addresses learned from ingressing native frames or egressing TRILL Data packets are, for MT TRILL switches, qualified by topology. That is, either the topology into which that TRILL switch classified the ingressed native frame or the topology that the egressed TRILL Data frame was in.
对于MT-TRILL交换机，从输入本机帧或输出TRILL数据包中学习的终端站MAC地址由拓扑限定。也就是说，该颤音开关将进入的本机帧分类到的拓扑，或者是退出的颤音数据帧所在的拓扑。
In an MT TRILL switch, End Station Address Distribution Information (ESADI) [RFC7357] operates per label (VLAN or FGL) per topology. Since ESADI messages appear, to transit TRILL switches, like normal multi-destination TRILL Data packets, ESADI link state databases and ESADI protocol operation are per topology as well as per label and local to each area of multi-destination TRILL data connectivity for that topology.
在MT TRILL交换机中，端站地址分布信息（ESADI）[RFC7357]在每个拓扑的每个标签（VLAN或FGL）上运行。由于出现了ESADI消息，为了传输TRILL交换机，与正常的多目标TRILL数据包一样，ESADI链路状态数据库和ESADI协议操作是按拓扑、标签以及该拓扑的多目标TRILL数据连接的每个区域进行的。
Areas of topology-ignorant TRILL switches can be connected to and become part of an MT TRILL campus but will only be able to ingress to, transit, or egress from topology zero TRILL Data packets.
拓扑无关的TRILL交换机区域可以连接到MT TRILL园区并成为其一部分，但只能进入、传输或从拓扑零TRILL数据包中退出。
RBridge Channel messages [RFC7178], such as BFD over TRILL [RFC7175] appear, to transit TRILL switches, like normal multi-destination TRILL Data packets. Thus, they have a topology and, if that topology is non-zero, are constrained by topology like other TRILL Data packets. Generally, when sent for network management purposes, they are sent in topology zero to avoid such constraint.
RBridge通道消息[RFC7178]如BFD over TRILL[RFC7175]出现，以传输TRILL交换机，就像普通的多目的地TRILL数据包一样。因此，它们有一个拓扑，如果该拓扑为非零，则与其他TRILL数据包一样受拓扑的约束。通常，当出于网络管理目的发送时，它们以零拓扑发送以避免此类约束。
MT is an optional TRILL switch capability.
MT是可选的颤音切换功能。
Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120] indicates that a single router handling more than eight topologies is rare. There may be many more than eight distinct topologies in a routed area, such as a TRILL campus; in that case, many of these topologies will be handled by disjoint sets of routers and/or links.
第3层IS-IS MT[RFC5120]的实际部署经验表明，单个路由器处理八种以上拓扑的情况很少。一个路由区域中可能有八种以上不同的拓扑，例如TRILL校园；在这种情况下，这些拓扑中的许多将由不相交的路由器和/或链路集处理。
Based on this deployment experience, a TRILL switch capable of handling eight or more topologies can be considered a full implementation while a TRILL switch capable of handling four topologies can be considered a minimal implementation but still useful under some circumstances.
根据此部署经验，能够处理八种或更多拓扑的TRILL交换机可以被视为完整实现，而能够处理四种拓扑的TRILL交换机可以被视为最小实现，但在某些情况下仍然有用。
IEEE Registration Authority and IANA considerations are given below.
IEEE注册机构和IANA注意事项如下所示。
The IEEE Registration Authority has allocated Ethertype 0x9A22 for the MT Label (see Section 2.4).
IEEE注册机构已为MT标签分配Ethertype 0x9A22（见第2.4节）。
IANA has assigned a field of two adjacent bits (14-15) of the Capabilities bits of the Port TRILL Version Sub-TLV for the Explicit Topology capability field and updated the "PORT-TRILL-VER Sub-TLV Capability Flags" registry as follows.
IANA已为显式拓扑能力字段分配了Port TRILL版本子TLV能力位的两个相邻位（14-15）字段，并更新了“Port-TRILL-VER子TLV能力标志”注册表，如下所示。
Bit Description Reference
----- ------------------------- ---------------
14-15 Topology labeling support. [RFC8377]
Bit Description Reference
----- ------------------------- ---------------
14-15 Topology labeling support. [RFC8377]
IANA has created the informational "TRILL Ethertypes" subregistry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.
IANA已在“大量链接透明互连（TRILL）参数”注册表中创建了信息性“TRILL Ethertypes”子区。
Name: TRILL Ethertypes Registration Procedure(s): Ethertypes are assigned by the IEEE Registration Authority. Updates to this registry are coordinated with the designated expert. Reference: [RFC8377]
名称：TRILL Ethertypes注册程序：Ethertypes由IEEE注册机构指定。本登记册的更新由指定专家协调。参考文献：[RFC8377]
Note: This registry provides centralized documentation of Ethertypes that were assigned by the IEEE for initial use with TRILL. In some cases, particularly L2-IS-IS and MT, they may be used with other protocols.
注：此注册表提供IEEE为TRILL最初使用而分配的Ethertypes的集中文档。在某些情况下，特别是L2-IS-IS和MT，它们可以与其他协议一起使用。
Value Mnemonic Explanation Reference
------ -------- --------------------- ---------
0x22F3 TRILL TRILL data [RFC6325]
0x22F4 L2-IS-IS IS-IS [RFC6325]
0x893B FGL Fine Grained Labeling [RFC7172]
0x8946 - TRILL RBridge Channel [RFC7178]
0x9A22 MT Multi-Topology [RFC8377]
Value Mnemonic Explanation Reference
------ -------- --------------------- ---------
0x22F3 TRILL TRILL data [RFC6325]
0x22F4 L2-IS-IS IS-IS [RFC6325]
0x893B FGL Fine Grained Labeling [RFC7172]
0x8946 - TRILL RBridge Channel [RFC7178]
0x9A22 MT Multi-Topology [RFC8377]
Multiple topologies are sometimes used for the isolation or security of traffic. For example, if some links were more likely than others to be subject to adversarial observation, it might be desirable to classify certain sensitive traffic in a topology that excluded those links.
多拓扑有时用于隔离或保护通信。例如，如果某些链接比其他链接更有可能受到敌对观察，则可能需要在排除这些链接的拓扑中对某些敏感流量进行分类。
Delivery of data originating in one topology outside of that topology is generally a security policy violation to be avoided at all reasonable costs. Using IS-IS security [RFC5310] on all IS-IS PDUs and link security appropriate to the link technology on all links involved, particularly those between RBridges, supports the avoidance of such violations.
在该拓扑之外的一个拓扑中发送数据通常是违反安全策略的行为，必须不惜一切合理代价避免。在所有IS-IS PDU上使用IS-IS安全[RFC5310]，并在所有相关链路（尤其是RBridge之间的链路）上使用适合于链路技术的链路安全性，有助于避免此类违规行为。
For general TRILL security considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
[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)", 2002.
[IS-IS]ISO/IEC 10589:2002，第二版，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由交换协议（ISO 8473）”，2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，DOI 10.17487/RFC5120，2008年2月<https://www.rfc-editor.org/info/rfc5120>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc5310>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc6325>.
[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, <https://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月<https://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, <https://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月<https://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, <https://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月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc7178>.
[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, <https://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc7780>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <https://www.rfc-editor.org/info/rfc7175>.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，DOI 10.17487/RFC7175，2014年5月<https://www.rfc-editor.org/info/rfc7175>.
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 2017, <https://www.rfc-editor.org/info/rfc8139>.
[RFC8139]Eastlake 3rd，D.，Li，Y.，Umair，M.，Banerjee，A.，和F.Hu，“大量链接的透明互连（TRILL）：指定的货运代理”，RFC 8139，DOI 10.17487/RFC8139，2017年6月<https://www.rfc-editor.org/info/rfc8139>.
TRILL multi-topology, as specified in this document, differs from RFC 5120 as follows:
本文件中规定的TRILL multi-topology与RFC 5120的不同之处如下：
1. [RFC5120] provides for unicast multi-topology. This document extends that to cover multi-destination TRILL data distribution (see Section 3.4).
1. [RFC5120]提供单播多拓扑。本文件将其扩展，以涵盖多目标TRILL数据分发（见第3.4节）。
2. [RFC5120] assumes the topology of data packets is always determined implicitly, that is, based on the port over which the packets are received and/or preexisting fields within the packet. This document supports such implicit determination, but it extends this by providing for optional explicit topology labeling of data packets (see Section 2.4).
2. [RFC5120]假设数据包的拓扑始终是隐式确定的，即，基于接收数据包的端口和/或数据包中预先存在的字段。本文件支持此类隐式确定，但通过提供数据包的可选显式拓扑标签（见第2.4节），对其进行了扩展。
3. [RFC5120] makes support of the default topology zero optional for MT routers and links. For simplicity and ease in network management, this document requires all TRILL switches and links between TRILL switches to support topology zero (see Section 2.1).
3. [RFC5120]为MT路由器和链路提供默认拓扑零可选支持。为简化网络管理，本文件要求所有TRILL交换机和TRILL交换机之间的链路支持零拓扑（见第2.1节）。
Acknowledgements
致谢
The comments and contributions of the following are gratefully acknowledged:
感谢以下各方的评论和贡献：
Vishwas Manral and Martin Vigoureux
维什瓦斯·曼拉尔和马丁·维古鲁
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technologies 1424 Pro Shop Court Davenport, FL 33896 United States of America
Donald Eastlake 3rd Huawei Technologies 1424 Pro Shop Court Davenport，美国佛罗里达州33896
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.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, 100085 China
中国北京市海淀区上地信息产业基地新西路3号华为大厦张明贵华为技术有限公司，邮编100085
Email: zhangmingui@huawei.com
Email: zhangmingui@huawei.com
Ayan Banerjee Cisco 170 W. Tasman Drive San Jose, CA 95134 United States of America
美国加利福尼亚州圣何塞塔斯曼大道西170号Ayan Banerjee Cisco邮编95134
Email: ayabaner@cisco.com
Email: ayabaner@cisco.com