Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 8243 EMC
Category: Informational D. Eastlake 3rd
ISSN: 2070-1721 M. Zhang
Huawei
A. Ghanwani
Dell
H. Zhai
JIT
September 2017
Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 8243 EMC
Category: Informational D. Eastlake 3rd
ISSN: 2070-1721 M. Zhang
Huawei
A. Ghanwani
Dell
H. Zhai
JIT
September 2017
Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)
多链路多级透明互连的备选方案（TRILL）
Abstract
摘要
Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?
尽管TRILL基于is-is，支持多级单播路由，但将TRILL扩展到多个级别仍面临着is-is现有功能无法解决的挑战。一个问题是多目的地数据包分发树的处理。其他问题是颤音开关的昵称。如何在多级TRILL网络中分配此类昵称？昵称在整个多级颤音网络中是否需要是唯一的？或者它们仅仅在每个多层次区域内是唯一的？
This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.
本信息性文档列举并检查了基于许多因素的备选方案，包括向后兼容性、简单性和可伸缩性；它在某些情况下提出建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc8243.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8243.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 ....................................................4
1.1. The Motivation for Multilevel ..............................4
1.2. Improvements Due to Multilevel .............................5
1.2.1. The Routing Computation Load ........................5
1.2.2. LSDB Volatility Creating Too Much Control Traffic ...5
1.2.3. LSDB Volatility Causing Too Much Time Unconverged ...6
1.2.4. The Size of the LSDB ................................6
1.2.5. Nickname Limit ......................................6
1.2.6. Multi-Destination Traffic ...........................7
1.3. Unique and Aggregated Nicknames ............................7
1.4. More on Areas ..............................................8
1.5. Terminology and Abbreviations ..............................9
2. Multilevel TRILL Issues ........................................10
2.1. Non-Zero Area Addresses ...................................11
2.2. Aggregated versus Unique Nicknames ........................12
2.2.1. More Details on Unique Nicknames ...................12
2.2.2. More Details on Aggregated Nicknames ...............13
2.3. Building Multi-Area Trees .................................18
2.4. The RPF Check for Trees ...................................18
2.5. Area Nickname Acquisition .................................19
2.6. Link State Representation of Areas ........................19
3. Area Partition .................................................20
4. Multi-Destination Scope ........................................21
4.1. Unicast to Multi-Destination Conversions ..................21
4.1.1. New Tree Encoding ..................................22
4.2. Selective Broadcast Domain Reduction ......................22
5. Coexistence with Old TRILL Switches ............................23
6. Multi-Access Links with End Stations ...........................24
7. Summary ........................................................25
8. Security Considerations ........................................26
9. IANA Considerations ............................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Acknowledgements ..................................................28
Authors' Addresses ................................................29
1. Introduction ....................................................4
1.1. The Motivation for Multilevel ..............................4
1.2. Improvements Due to Multilevel .............................5
1.2.1. The Routing Computation Load ........................5
1.2.2. LSDB Volatility Creating Too Much Control Traffic ...5
1.2.3. LSDB Volatility Causing Too Much Time Unconverged ...6
1.2.4. The Size of the LSDB ................................6
1.2.5. Nickname Limit ......................................6
1.2.6. Multi-Destination Traffic ...........................7
1.3. Unique and Aggregated Nicknames ............................7
1.4. More on Areas ..............................................8
1.5. Terminology and Abbreviations ..............................9
2. Multilevel TRILL Issues ........................................10
2.1. Non-Zero Area Addresses ...................................11
2.2. Aggregated versus Unique Nicknames ........................12
2.2.1. More Details on Unique Nicknames ...................12
2.2.2. More Details on Aggregated Nicknames ...............13
2.3. Building Multi-Area Trees .................................18
2.4. The RPF Check for Trees ...................................18
2.5. Area Nickname Acquisition .................................19
2.6. Link State Representation of Areas ........................19
3. Area Partition .................................................20
4. Multi-Destination Scope ........................................21
4.1. Unicast to Multi-Destination Conversions ..................21
4.1.1. New Tree Encoding ..................................22
4.2. Selective Broadcast Domain Reduction ......................22
5. Coexistence with Old TRILL Switches ............................23
6. Multi-Access Links with End Stations ...........................24
7. Summary ........................................................25
8. Security Considerations ........................................26
9. IANA Considerations ............................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Acknowledgements ..................................................28
Authors' Addresses ................................................29
The IETF Transparent Interconnection of Lot of Links (TRILL) protocol [RFC6325] [RFC7177] [RFC7780] provides optimal pairwise data routing without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic in networks with arbitrary topology and link technology, including multi-access links. TRILL accomplishes this by using Intermediate System to Intermediate System [IS-IS] [RFC7176]) link state routing in conjunction with a header that includes a hop count. The design supports Data Labels (VLANs and Fine-Grained Labels (FGLs) [RFC7172]) and optimization of the distribution of multi-destination data based on Data Label and multicast group. Devices that implement TRILL are called TRILL Switches or RBridges.
IETF大量链路透明互连（TRILL）协议[RFC6325][RFC7177][RFC7780]提供无配置的最佳成对数据路由，即使在临时环路期间也能安全转发，并支持具有任意拓扑和链路技术的网络中单播和多播流量的多路径传输，包括多址链路。TRILL通过使用中间系统到中间系统[IS-IS][RFC7176]）链路状态路由以及包含跳数的报头来实现这一点。该设计支持数据标签（VLAN和细粒度标签（FGLs）[RFC7172]）以及基于数据标签和多播组的多目的地数据分布优化。实现颤音的设备称为颤音开关或RBridge。
Familiarity with [IS-IS], [RFC6325], and [RFC7780] is assumed in this document.
本文件假设熟悉[IS-IS]、[RFC6325]和[RFC7780]。
The primary motivation for multilevel TRILL is to improve scalability. The following issues might limit the scalability of a TRILL-based network:
多级TRILL的主要动机是提高可伸缩性。以下问题可能会限制基于TRILL的网络的可扩展性：
1. The routing computation load
1. 路由计算负载
2. The volatility of the link state database (LSDB) creating too much control traffic
2. 链路状态数据库（LSDB）的波动性造成了过多的控制流量
3. The volatility of the LSDB causing the TRILL network to be in an unconverged state too much of the time
3. LSDB的波动性导致TRILL网络大部分时间处于未转换状态
4. The size of the LSDB
4. LSDB的大小
5. The limit of the number of TRILL switches, due to the 16-bit nickname space (for further information on why this might be a problem, see Section 1.2.5)
5. 由于16位昵称空间，颤音开关的数量限制（有关为什么会出现问题的更多信息，请参阅第1.2.5节）
6. The traffic due to upper-layer protocols use of broadcast and multicast
6. 上层协议使用广播和多播产生的流量
7. The size of the end-node learning table (the table that remembers (egress TRILL switch, label / Media Access Control (MAC)) pairs)
7. 终端节点学习表（记忆（出口颤音开关、标签/媒体访问控制（MAC））对的表）的大小
As discussed below, extending TRILL IS-IS to be multilevel (hierarchical) can help with all of these issues except issue 7.
如下所述，将TRILL IS-IS扩展为多级（分层）可以帮助解决除问题7之外的所有这些问题。
IS-IS was designed to be multilevel [IS-IS]. A network can be partitioned into "areas". Routing within an area is known as "Level 1 routing". Routing between areas is known as "Level 2 routing". The Level 2 IS-IS network consists of Level 2 routers and links between the Level 2 routers. Level 2 routers may participate in one or more Level 1 areas, in addition to their role as Level 2 routers.
IS-IS被设计为多级[IS-IS]。网络可以划分为“区域”。区域内的布线称为“1级布线”。区域之间的布线称为“2级布线”。2级IS-IS网络由2级路由器和2级路由器之间的链路组成。2级路由器除了作为2级路由器的角色外，还可以参与一个或多个1级区域。
Each area is connected to Level 2 through one or more "border routers", which participate both as a router inside the area, and as a router inside the Level 2 area. Care must be taken that it is clear, when transitioning multi-destination packets between a Level 2 and a Level 1 area in either direction, that exactly one border TRILL switch will transition a particular data packet between the levels; otherwise, duplication or loss of traffic can occur.
每个区域通过一个或多个“边界路由器”连接到2级，边界路由器既作为区域内的路由器参与，也作为2级区域内的路由器参与。必须注意的是，当在2级和1级区域之间的任意方向上转换多个目的地分组时，很明显，只有一个边界颤音交换机将在两个级别之间转换特定的数据分组；否则，可能会发生通信量的重复或丢失。
Partitioning the network into areas directly solves the first four scalability issues listed above, as described in Sections 1.2.1 through 1.2.4. Multilevel also contributes to solving issues 5 and 6, as discussed in Sections 1.2.5 and 1.2.6, respectively.
如第1.2.1节至第1.2.4节所述，将网络划分为多个区域可直接解决上述前四个可伸缩性问题。如第1.2.5节和第1.2.6节所述，多层次也有助于解决问题5和6。
In the subsections below, N indicates the number of TRILL switches in a TRILL campus. For simplicity, it is assumed that each TRILL switch has k links to other TRILL switches. An "optimized" multilevel campus is assumed to have Level 1 areas containing sqrt(N) switches.
在下面的小节中，N表示TRILL园区中TRILL交换机的数量。为简单起见，假设每个颤音开关都有k个到其他颤音开关的链接。假设“优化”多级园区具有包含sqrt（N）交换机的1级区域。
The Dijkstra algorithm uses computational effort on the order of the number of links in a network (N*k) times the log of the number of nodes to calculate least cost routes at a router (Section 12.3.3 of [InterCon]). Thus, in a single-level TRILL campus, it is on the order of N*k*log(N). In an optimized multilevel campus, it is on the order of sqrt(N)*k*log(N). So, for example, assuming N is 3,000, the level of computational effort would be reduced by about a factor of 50.
Dijkstra算法使用网络中链路数（N*k）乘以节点数日志的计算量来计算路由器上的最低成本路由（InterCon第12.3.3节）。因此，在单级颤音校园中，其顺序为N*k*log（N）。在优化的多级校园中，其顺序为sqrt（N）*k*log（N）。例如，假设N为3000，计算工作量将减少大约50倍。
The rate of LSDB changes is assumed to be approximately proportional to the number of routers and links in the TRILL campus or N*(1+k) for a single-level campus. With an optimized multilevel campus, each area would have about sqrt(N) routers and proportionately fewer links reducing the rate of LSDB changes by about a factor of sqrt(N).
假设LSDB的变化率与TRILL园区中路由器和链路的数量近似成比例，或者与单级园区的N*（1+k）近似成比例。有了优化的多级园区，每个区域将有大约sqrt（N）个路由器，相应地减少链路，从而将LSDB的变化率降低大约sqrt（N）的一倍。
With the simplifying assumption that routing converges after each topology change before the next such change, the fraction of time that routing is unconverged is proportional to the product of the rate of change occurrence and the convergence time. The rate of topology changes per some arbitrary unit of time will be roughly proportional to the number of router and links (Section 1.2.2). The convergence time is approximately proportional to the computation involved at each router (Section 1.2.1). Thus, based on these simplifying assumptions, the time spent unconverged in a single-level network is proportional to (N*(1+k))*(N*k*log(N)) while that time for an optimized multilevel network would be proportional to (sqrt(N)*(1+k))*(sqrt(N)*k*log(N)). Thus, in changing to multilevel, the time spent unconverged, using these simplifying assumptions, is improved by about a factor of N.
通过简化假设，即路由在每次拓扑变化后收敛于下一次拓扑变化之前，路由未收敛的时间分数与变化发生率和收敛时间的乘积成正比。每任意时间单位的拓扑变化率大致与路由器和链路的数量成正比（第1.2.2节）。收敛时间大致与每个路由器的计算量成正比（第1.2.1节）。因此，基于这些简化假设，单级网络中未融合的时间与（N*（1+k））*（N*k*log（N））成正比，而优化多级网络的时间与（sqrt（N）*（1+k））*（sqrt（N）*k*log（N））成正比。因此，在转向多级时，使用这些简化假设，花费在未转化上的时间大约提高了N倍。
The size of the LSDB, which consists primarily of information about routers (TRILL switches) and links, is also approximately proportional to the number of routers and links. So, as with item 2 in Section 1.2.2, it should improve by about a factor of sqrt(N) in going from single level to multilevel.
LSDB的大小主要由有关路由器（TRILL交换机）和链路的信息组成，也大致与路由器和链路的数量成比例。因此，与第1.2.2节中的第2项一样，在从单级到多级的过程中，它应该提高大约sqrt（N）的一倍。
For many TRILL protocol purposes, RBridges are designated by 16-bit nicknames. While some values are reserved, this appears to provide enough nicknames to designated over 65,000 RBridges. However, this number is effectively reduced by the following two factors:
对于许多TRILL协议，RBridge由16位昵称指定。虽然保留了一些值，但这似乎提供了足够的昵称来指定超过65000个RBridge。然而，这一数字通过以下两个因素有效减少：
- Nicknames are consumed when pseudo-nicknames are used for the active-active connection of end stations. Using the techniques in [RFC7781], for example, could double the nickname consumption if there are extensive active-active edge groups connected to different sets of edge TRILL switch ports.
- 当伪昵称用于端站的活动连接时，使用昵称。例如，如果有大量的活动边缘组连接到不同的边缘TRILL交换机端口集，则使用[RFC7781]中的技术可以使昵称使用量翻倍。
- There might be problems in multilevel campus-wide contention for single-nickname allocation of nicknames were allocated individually from a single pool for the entire campus. Thus, it seems likely that a hierarchical method would be chosen where blocks of nicknames are allocated at Level 2 to Level 1 areas and contention for a nickname by an RBridge in such a Level 1 area would be only within that area. Such hierarchical allocation leads to further effective loss of nicknames similar to the situation with IP addresses discussed in [RFC3194].
- 在多级校园范围内争夺单个昵称分配时可能会出现问题。昵称是从单个池中为整个校园单独分配的。因此，似乎有可能选择分层方法，其中昵称块在2级分配给1级区域，并且RBridge在这样的1级区域中争夺昵称将仅在该区域内。这种分层分配导致昵称的进一步有效丢失，类似于[RFC3194]中讨论的IP地址情况。
Even without the above effective reductions in nickname space, a very large multilevel TRILL campus, say one with 200 areas each containing 500 TRILL switches, could require 100,000 or more nicknames if all nicknames in the campus must be unique, which is clearly impossible with 16-bit nicknames.
即使没有上述有效的昵称空间缩减，如果校园中的所有昵称都必须是唯一的，那么一个非常大的多级TRILL校园（比如一个有200个区域，每个区域包含500个TRILL交换机）可能需要100000个或更多的昵称，而16位昵称显然是不可能的。
This scaling limit, namely, the 16-bit nickname space, will only be addressed with the aggregated-nickname approach. Since the aggregated-nickname approach requires some complexity in the border TRILL switches (for rewriting the nicknames in the TRILL header), the suggested design in this document allows a campus with a mixture of unique-nickname areas, and aggregated-nickname areas. Thus, a TRILL network could start using multilevel with the simpler unique nickname method and later add aggregated-nickname areas as a later stage of network growth.
此扩展限制，即16位昵称空间，将仅使用聚合昵称方法解决。由于聚合昵称方法要求边界颤音开关具有一定的复杂性（用于在颤音头中重写昵称），因此本文中建议的设计允许校园混合使用唯一昵称区域和聚合昵称区域。因此，TRILL网络可以开始使用具有更简单的唯一昵称方法的多级，然后添加聚合昵称区域，作为网络增长的后期阶段。
With this design, nicknames must be unique across all Level 2 and unique-nickname area TRILL switches taken together; whereas nicknames inside an aggregated-nickname area are visible only inside that area. Nicknames inside an aggregated-nickname area must still not conflict with nicknames visible in Level 2 (which includes all nicknames inside unique nickname areas), but the nicknames inside an aggregated-nickname area may be the same as nicknames used within one or more other aggregated-nickname areas.
在这种设计中，昵称必须在所有级别2和唯一昵称区域颤音开关中都是唯一的；而聚集昵称区域内的昵称仅在该区域内可见。聚合昵称区域内的昵称不得与级别2中可见的昵称冲突（包括唯一昵称区域内的所有昵称），但聚合昵称区域内的昵称可能与一个或多个其他聚合昵称区域内使用的昵称相同。
With the design suggested in this document, TRILL switches within an area need not be aware of whether they are in an aggregated-nickname area or a unique nickname area. The border TRILL switches in area A1 will indicate, in their LSP inside area A1, which nicknames (or nickname ranges) are or are not available to be chosen as nicknames by area A1 TRILL switches.
使用本文档中建议的设计，区域内的颤音开关不需要知道它们是在聚合昵称区域还是唯一昵称区域。区域A1中的边界颤音开关将在其区域A1内的LSP中指示哪些昵称（或昵称范围）可供或不可供区域A1颤音开关选择作为昵称。
In many cases, scaling limits due to protocol use of broadcast and multicast can be addressed in a multilevel campus by introducing locally scoped multi-destination delivery, limited to an area or a single link. See further discussion of this issue in Section 4.2.
在许多情况下，由于广播和多播的协议使用而产生的扩展限制可以通过引入本地范围的多目的地交付（限于一个区域或单个链路）在多级校园中解决。请参阅第4.2节中对该问题的进一步讨论。
We describe two alternatives for hierarchical or multilevel TRILL. One we call the "unique-nickname" alternative. The other we call the "aggregated-nickname" alternative. In the aggregated-nickname alternative, border TRILL switches replace either the ingress or egress nickname field in the TRILL header of unicast packets with an aggregated nickname representing an entire area.
我们描述了分层或多级颤音的两种选择。我们称之为“独特昵称”的替代品。另一个我们称之为“聚合昵称”替代方案。在聚合昵称替代方案中，边界TRILL开关用表示整个区域的聚合昵称替换单播分组的TRILL报头中的入口或出口昵称字段。
The unique-nickname alternative has the advantage that border TRILL switches are simpler and do not need to do TRILL Header nickname modification. It also simplifies testing and maintenance operations that originate in one area and terminate in a different area.
独特的昵称替代方案的优点是边界颤音开关更简单，不需要修改颤音头昵称。它还简化了源于一个区域并终止于另一个区域的测试和维护操作。
The aggregated-nickname alternative has the following advantages:
聚合昵称替代方案具有以下优点：
- it solves scaling issue 5 above, the 16-bit nickname limit, in a simple way,
- 它以一种简单的方式解决了上面的缩放问题5，即16位昵称限制，
- it lessens the amount of inter-area routing information that must be passed in IS-IS, and
- 它减少了必须在IS-IS中传递的区域间路由信息量，并且
- it logically reduces the RPF (Reverse Path Forwarding) Check information (since only the area nickname needs to appear, rather than all the ingress TRILL switches in that area).
- 它在逻辑上减少了RPF（反向路径转发）检查信息（因为只需要显示区域昵称，而不需要显示该区域中的所有入口颤音开关）。
In both cases, it is possible and advantageous to compute multi-destination data packet distribution trees such that the portion computed within a given area is rooted within that area.
在这两种情况下，计算多目的地数据分组分布树使得在给定区域内计算的部分根在该区域内是可能的并且是有利的。
For further discussion of the unique and aggregated-nickname alternatives, see Section 2.2.
有关唯一和聚合昵称备选方案的进一步讨论，请参见第2.2节。
Each area is configured with an "area address", which is advertised in IS-IS messages, so as to avoid accidentally interconnecting areas. For TRILL, the only purpose of the area address would be to avoid accidentally interconnecting areas although the area address had other purposes in CLNP (ConnectionLess Network Protocol), IS-IS was originally designed for CLNP/DECnet.
每个区域都配置了一个“区域地址”，该地址在is-is消息中公布，以避免意外地互连区域。对于TRILL，区域地址的唯一用途是避免意外互连区域，尽管区域地址在CLNP（无连接网络协议）中有其他用途，IS-IS最初是为CLNP/DECnet设计的。
Currently, the TRILL specification says that the area address must be zero. If we change the specification so that the area address value of zero is just a default, then most IS-IS multilevel machinery works as originally designed. However, there are TRILL-specific issues, which we address in Section 2.1.
目前，TRILL规范规定区域地址必须为零。如果我们更改规范，使区域地址值为零只是默认值，那么大多数is-is多级机器的工作原理与最初设计的相同。但是，有一些特定于颤音的问题，我们将在第2.1节中讨论。
This document generally uses the abbreviations defined in [RFC6325] plus the additional abbreviation DBRB. However, for ease of reference, most abbreviations used are listed here:
本文件通常使用[RFC6325]中定义的缩写以及附加缩写DBRB。但是，为了便于参考，此处列出了使用的大多数缩写：
CLNP: ConnectionLess Network Protocol
CLNP：无连接网络协议
DECnet: a proprietary routing protocol that was used by Digital Equipment Corporation. "DECnet Phase 5" was the origin of IS-IS.
DECnet：数字设备公司使用的专有路由协议。“DECnet第5阶段”是IS-IS的起源。
Data Label: VLAN or Fine-Grained Label [RFC7172]
数据标签：VLAN或细粒度标签[RFC7172]
DBRB: Designated Border RBridge
DBRB：指定边界RBRIGE
ESADI: End-Station Address Distribution Information
ESADI：端站地址分布信息
IS-IS: Intermediate System to Intermediate System [IS-IS]
IS-IS：中间系统至中间系统[IS-IS]
LSDB: Link State DataBase
链路状态数据库
LSP: Link State PDU
链路状态PDU
PDU: Protocol Data Unit
协议数据单元
RBridge: Routing Bridge, an alternative name for a TRILL switch
RBridge：路由桥，TRILL交换机的另一个名称
RPF: Reverse Path Forwarding
反向路径转发
TLV: Type-Length-Value
TLV：类型长度值
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325] [RFC7780]
TRILL：链路层中大量链路的透明互连或隧道路由[RFC6325][RFC7780]
TRILL switch: a device that implements the TRILL protocol [RFC6325] [RFC7780], sometimes called an RBridge
颤音开关：实现颤音协议[RFC6325][RFC7780]的设备，有时称为RBridge
VLAN: Virtual Local Area Network
虚拟局域网
The TRILL-specific issues introduced by multilevel include the following:
multilevel引入的TRILL特定问题包括：
a. Configuration of non-zero area addresses, encoding them in IS-IS PDUs, and possibly interworking with old TRILL switches that do not understand non-zero area addresses.
a. 配置非零区域地址，在IS-IS PDU中对其进行编码，并可能与不了解非零区域地址的旧TRILL交换机互通。
See Section 2.1.
见第2.1节。
b. Nickname management.
b. 昵称管理。
See Sections 2.5 and 2.2.
见第2.5节和第2.2节。
c. Advertisement of pruning information (Data Label reachability, IP multicast addresses) across areas.
c. 跨区域发布修剪信息（数据标签可达性、IP多播地址）。
Distribution tree pruning information is only an optimization, as long as multi-destination packets are not prematurely pruned. For instance, border TRILL switches could advertise they can reach all possible Data Labels, and have an IP multicast router attached. This would cause all multi-destination traffic to be transmitted to border TRILL switches, and possibly pruned there, when the traffic could have been pruned earlier based on Data Label or multicast group if border TRILL switches advertised more detailed Data Label and/or multicast listener and multicast router attachment information.
分发树剪枝信息只是一种优化，只要多目标数据包没有被过早剪枝。例如，border TRILL交换机可以宣传它们可以访问所有可能的数据标签，并连接一个IP多播路由器。如果border TRILL交换机公布更详细的数据标签和/或多播侦听器和多播路由器附件信息，则当可以基于数据标签或多播组更早地修剪流量时，这将导致所有多目的地流量传输到border TRILL交换机，并可能在那里修剪。
d. Computation of distribution trees across areas for multi-destination data.
d. 多目标数据跨区域分布树的计算。
See Section 2.3.
见第2.3节。
e. Computation of RPF information for those distribution trees.
e. 计算这些分布树的RPF信息。
See Section 2.4.
见第2.4节。
f. Computation of pruning information across areas.
f. 跨区域修剪信息的计算。
See Sections 2.3 and 2.6.
见第2.3节和第2.6节。
g. Compatibility, as much as practical, with existing, unmodified TRILL switches.
g. 与现有未经修改的TRILL开关尽可能兼容。
The most important form of compatibility is with existing TRILL fast-path hardware. Changes that require upgrade to the slow-path firmware/software are more tolerable. Compatibility for the relatively small number of border TRILL switches is less important than compatibility for non-border TRILL switches.
最重要的兼容性形式是与现有TRILL快速路径硬件兼容。需要升级到慢路径固件/软件的更改更容易接受。相对较少数量的边界颤音开关的兼容性不如非边界颤音开关的兼容性重要。
See Section 5.
见第5节。
The current TRILL base protocol specification [RFC6325] [RFC7177] [RFC7780] says that the area address in IS-IS must be zero. The purpose of the area address is to ensure that different areas are not accidentally merged. Furthermore, zero is an invalid area address for Layer 3 IS-IS, so it was chosen as an additional safety mechanism to ensure that Layer 3 IS-IS packets would not be confused with TRILL IS-IS packets. However, TRILL uses other techniques to avoid confusion on a link, such as different multicast addresses and Ethertypes on Ethernet [RFC6325], different PPP (Point-to-Point Protocol) code points on PPP [RFC6361], and the like. Thus, using an area address in TRILL that might be used in Layer 3 IS-IS is not a problem.
当前的TRILL基本协议规范[RFC6325][RFC7177][RFC7780]规定IS-IS中的区域地址必须为零。区域地址的目的是确保不同区域不会意外合并。此外，对于第3层is-is，零是无效的区域地址，因此选择它作为附加安全机制，以确保第3层is-is数据包不会与TRILL is-is数据包混淆。然而，TRILL使用其他技术来避免链路上的混淆，例如以太网[RFC6325]上的不同多播地址和以太网类型、PPP[RFC6361]上的不同PPP（点对点协议）代码点等等。因此，在TRILL中使用可能在第3层IS-IS中使用的区域地址不是问题。
Since current TRILL switches will reject any IS-IS messages with non-zero area addresses, the choices are as follows:
由于当前TRILL开关将拒绝任何具有非零区域地址的IS-IS消息，因此选择如下：
a.1. upgrade all TRILL switches that are to interoperate in a potentially multilevel environment to understand non-zero area addresses,
a、 一,。升级所有TRILL交换机，以便在潜在的多级环境中进行互操作，以了解非零区域地址，
a.2. neighbors of old TRILL switches must remove the area address from IS-IS messages when talking to an old TRILL switch (which might break IS-IS security and/or cause inadvertent merging of areas),
a、 二,。当与旧TRILL交换机通话时，旧TRILL交换机的邻居必须从IS-IS消息中删除区域地址（这可能会破坏IS-IS安全性和/或导致区域意外合并），
a.3. ignore the problem of accidentally merging areas entirely, or
a、 三,。忽略意外完全合并区域的问题，或
a.4. keep the fixed "area address" field as 0 in TRILL, and add a new, optional TLV for "area name" to Hellos that, if present, could be compared, by new TRILL switches, to prevent accidental area merging.
a、 四,。在TRILL中将固定的“区域地址”字段保持为0，并为“区域名称”添加一个新的可选TLV，如果存在，可以通过新的TRILL开关进行比较，以防止意外的区域合并。
In principal, different solutions could be used in different areas but it would be much simpler to adopt one of these choices uniformly. A simple solution would be a.1, with each TRILL switch using a
原则上，在不同的领域可以使用不同的解决方案，但统一采用其中一种选择要简单得多。一个简单的解决方案是A.1，每个颤音开关使用一个
dominant area nickname as its area address. For the unique-nickname alternative, the dominant nickname could be the lowest value nickname held by any border RBridge of the area. For the aggregated-nickname alternative, it could be the lowest nickname held by a border RBridge of the area or a nickname representing the area.
主区域昵称作为其区域地址。对于唯一的昵称备选方案，主导昵称可以是该地区任何边界桥所持有的最低值昵称。对于聚合昵称备选方案，它可以是该区域边界RBridge所持有的最低昵称，也可以是代表该区域的昵称。
In the unique-nickname alternative, all nicknames across the campus must be unique. In the aggregated-nickname alternative, TRILL switch nicknames within an aggregated-nickname area are only of local significance, and the only nickname externally (outside that area) visible is the "area nickname" (or nicknames), which aggregates all the internal nicknames.
在唯一昵称替代方案中，校园内的所有昵称都必须是唯一的。在聚合昵称替代方案中，聚合昵称区域内的颤音开关昵称仅具有局部意义，外部（该区域外）唯一可见的昵称是“区域昵称”（或昵称），它聚合所有内部昵称。
The unique-nickname approach simplifies border TRILL switches.
独特的昵称方法简化了边界颤音开关。
The aggregated-nickname approach eliminates the potential problem of nickname exhaustion, minimizes the amount of nickname information that would need to be forwarded between areas, minimizes the size of the forwarding table, and simplifies RPF calculation and RPF information.
聚合昵称方法消除了昵称耗尽的潜在问题，最小化了需要在区域之间转发的昵称信息量，最小化了转发表的大小，简化了RPF计算和RPF信息。
With unique cross-area nicknames, it would be intractable to have a flat nickname space with TRILL switches in different areas contending for the same nicknames. Instead, each area would need to be configured with or allocate one or more blocks of nicknames. Either some TRILL switches would need to announce that all the nicknames other than those in blocks available to the area are taken (to prevent the TRILL switches inside the area from choosing nicknames outside the area's nickname block) or a new TLV would be needed to announce the allowable or the prohibited nicknames, and all TRILL switches in the area would need to understand that new TLV.
由于具有独特的跨区域昵称，很难有一个平坦的昵称空间，不同区域的颤音开关争夺相同的昵称。相反，每个区域需要配置或分配一个或多个昵称块。要么一些颤音开关需要宣布除该区域可用块中的昵称外的所有昵称都已使用（以防止该区域内的颤音开关选择该区域昵称块外的昵称），要么需要一个新的TLV来宣布允许或禁止的昵称，该地区的所有颤音开关都需要了解新的TLV。
Currently, the encoding of nickname information in TLVs is by listing of individual nicknames; this would make it painful for a border TRILL switch to announce into an area that it is holding all other nicknames to limit the nicknames available within that area. Painful means tens of thousands of individual nickname entries in the Level 1 LSDB. The information could be encoded as ranges of nicknames to make this manageable by specifying a new TLV similar to the Nickname Flags APPsub-TLV specified in [RFC7780] but providing flags for blocks of nicknames rather than single nicknames. Although this would require updating software, such a new TLV is the preferred method.
目前，TLV中昵称信息的编码是通过列出个人昵称；这将使边界颤音切换痛苦地向一个区域宣布它持有所有其他昵称，以限制该区域内可用的昵称。痛苦意味着在1级LSDB中有成千上万个单独的昵称条目。可以将信息编码为昵称范围，以便通过指定与[RFC7780]中指定的昵称标志APPsub TLV类似的新TLV，但为昵称块而不是单个昵称提供标志，从而实现可管理性。尽管这需要更新软件，但这种新的TLV是首选方法。
There is also an issue with the unique-nickname approach in building distribution trees, as follows:
在构建分发树时，独特的昵称方法也存在一个问题，如下所示：
With unique nicknames in the TRILL campus and TRILL header nicknames not rewritten by the border TRILL switches, there would have to be globally known nicknames for the trees. Suppose there are k trees. For all of the trees with nicknames located outside an area, the local trees would be rooted at a border TRILL switch or switches. Therefore, there would be either no splitting of multi-destination traffic within the area or restricted splitting of multi-destination traffic between trees rooted at a highly restricted set of TRILL switches.
由于TRILL校园中有唯一的昵称，而且TRILL头昵称没有被边界TRILL开关重写，因此树必须有全球知名的昵称。假设有k棵树。对于所有昵称位于区域外的树，本地树将植根于一个或多个边界颤音开关。因此，该区域内的多目的地流量不会被分割，或者在高度受限的TRILL交换机组上的树之间的多目的地流量的分割会受到限制。
As an alternative, just the "egress nickname" field of multi-destination TRILL Data packets could be mapped at the border, leaving known unicast packets unmapped. However, this surrenders much of the unique nickname advantage of simpler border TRILL switches.
作为替代方案，可以在边界处仅映射多目的地TRILL数据包的“出口昵称”字段，而不映射已知的单播数据包。然而，这放弃了更简单的边界颤音开关的许多独特的昵称优势。
Scaling to a very large campus with unique nicknames might exhaust the 16-bit TRILL nicknames space particularly if (1) additional nicknames are consumed to support active-active end-station groups at the TRILL edge using the techniques standardized in [RFC7781] and (2) use of the nickname space is less efficient due to the allocation of, for example, power-of-two size blocks of nicknames to areas in the same way that use of the IP address space is made less efficient by hierarchical allocation (see [RFC3194]). One method to avoid nickname exhaustion might be to expand nicknames to 24 bits; however, that technique would require TRILL message format and fast-path processing changes and all TRILL switches in the campus to understand larger nicknames.
如果（1）使用[RFC7781]中标准化的技术消耗额外的昵称以支持颤音边缘的活动端站组，以及（2）由于分配了，例如，两个大小的昵称块对区域的作用与使用IP地址空间的方式相同，通过分层分配降低了效率（参见[RFC3194]）。避免昵称耗尽的一种方法可能是将昵称扩展到24位；然而，这种技术需要TRILL消息格式和快速路径处理更改，以及校园中的所有TRILL交换机来理解更大的昵称。
The aggregated-nickname approach enables passing far less nickname information. It works as follows, assuming both the source and destination areas are using aggregated nicknames:
聚合昵称方法允许传递少得多的昵称信息。它的工作原理如下，假设源区域和目标区域都使用聚合昵称：
There are at least two ways areas could be identified.
至少有两种方法可以识别区域。
One method would be to assign each area a 16-bit nickname. This would not be the nickname of any actual TRILL switch. Instead, it would be the nickname of the area itself. Border TRILL switches would know the area nickname for their own area(s). For an example of a more-specific multilevel proposal using unique nicknames, see [UNIQUE].
一种方法是为每个区域分配一个16位的昵称。这不是任何实际颤音开关的昵称。相反，它将是该地区本身的昵称。Border TRILL交换机将知道自己区域的区域昵称。有关使用唯一昵称的更具体的多级提案的示例，请参阅[唯一]。
Alternatively, areas could be identified by the set of nicknames that identify the border routers for that area. (See [SingleName] for a multilevel proposal using such a set of nicknames.)
或者，可以通过标识该区域边界路由器的一组昵称来标识该区域。（请参见[SingleName]，了解使用此类昵称集的多级提案。）
The TRILL Header nickname fields in TRILL Data packets being transported through a multilevel TRILL campus with aggregated nicknames are as follows:
通过具有聚合昵称的多级TRILL园区传输的TRILL数据包中的TRILL头昵称字段如下所示：
- When both the ingress and egress TRILL switches are in the same area, there need be no change from the existing base TRILL protocol standard in the TRILL Header nickname fields.
- 当入口和出口颤音开关位于同一区域时，颤音头昵称字段中的现有基本颤音协议标准无需更改。
- When being transported between different Level 1 areas in Level 2, the ingress nickname is a nickname of the ingress TRILL switch's area, whereas the egress nickname is either a nickname of the egress TRILL switch's area or a tree nickname.
- 当在级别2的不同级别1区域之间传输时，入口昵称是入口颤音开关区域的昵称，而出口昵称是出口颤音开关区域的昵称或树昵称。
- When being transported from Level 1 to Level 2, the ingress nickname is the nickname of the ingress TRILL switch itself, whereas the egress nickname is either a nickname for the area of the egress TRILL switch or a tree nickname.
- 当从级别1传输到级别2时，入口昵称是入口颤音开关本身的昵称，而出口昵称是出口颤音开关区域的昵称或树昵称。
- When being transported from Level 2 to Level 1, the ingress nickname is a nickname for the ingress TRILL switch's area, whereas the egress nickname is either the nickname of the egress TRILL switch itself or a tree nickname.
- 当从级别2传输到级别1时，入口昵称是入口颤音开关区域的昵称，而出口昵称是出口颤音开关本身的昵称或树昵称。
There are two variations of the aggregated-nickname approach. The first is the Border Learning approach, which is described in Section 2.2.2.1. The second is the Swap Nickname Field approach, which is described in Section 2.2.2.2. Section 2.2.2.3 compares the advantages and disadvantages of these two variations of the aggregated-nickname approach.
聚合昵称方法有两种变体。第一种是边界学习方法，如第2.2.2.1节所述。第二种是交换昵称字段方法，如第2.2.2.2节所述。第2.2.2.3节比较了聚合昵称方法这两种变体的优缺点。
This section provides an illustrative example and description of the border-learning variation of aggregated nicknames where a single nickname is used to identify an area.
本节提供聚合昵称的边界学习变体的说明性示例和描述，其中使用单个昵称来标识区域。
In the following picture, RB2 and RB3 are area border TRILL switches (RBridges). A source S is attached to RB1. The two areas have nicknames 15961 and 15918, respectively. RB1 has a nickname, say 27, and RB4 has a nickname, say 44 (and in fact, they could even have the same nickname, since the TRILL switch nickname will not be visible outside these aggregated-nickname areas).
在下图中，RB2和RB3是区域边界颤音开关（RBRINGS）。源S连接到RB1。这两个地区的昵称分别为15961和15918。RB1有一个昵称，比如27，RB4有一个昵称，比如44（事实上，他们甚至可以有相同的昵称，因为颤音开关昵称在这些聚集的昵称区域之外不可见）。
Area 15961 level 2 Area 15918
+-------------------+ +-----------------+ +--------------+
| | | | | |
| S--RB1---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB4---D |
| 27 | | | | 44 |
| | | | | |
+-------------------+ +-----------------+ +--------------+
Area 15961 level 2 Area 15918
+-------------------+ +-----------------+ +--------------+
| | | | | |
| S--RB1---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB4---D |
| 27 | | | | 44 |
| | | | | |
+-------------------+ +-----------------+ +--------------+
Let's say that S transmits a frame to destination D, which is connected to RB4, and let's say that D's location has already been learned by the relevant TRILL switches. These relevant switches have learned the following:
假设s向连接到RB4的目的地D发送一个帧，并且假设D的位置已经被相关的颤音开关识别。这些相关开关已了解以下内容：
1. RB1 has learned that D is connected to nickname 15918 2. RB3 has learned that D is attached to nickname 44.
1. RB1了解到D与昵称15918 2相连。RB3了解到D附加在昵称44上。
The following sequence of events will occur:
将发生以下一系列事件：
- S transmits an Ethernet frame with source MAC = S and destination MAC = D.
- S传输源MAC=S和目标MAC=D的以太网帧。
- RB1 encapsulates with a TRILL header with ingress RBridge = 27, and egress = 15918 producing a TRILL Data packet.
- RB1使用TRILL报头进行封装，入口RBridge=27，出口=15918，生成TRILL数据包。
- RB2 has announced in the Level 1 IS-IS instance in area 15961, that it is attached to all the area nicknames, including 15918. Therefore, IS-IS routes the packet to RB2. Alternatively, if a distinguished range of nicknames is used for Level 2, Level 1 TRILL switches seeing such an egress nickname will know to route to the nearest border router, which can be indicated by the IS-IS "attached bit" [IS-IS].
- RB2在15961区域的1级IS-IS实例中宣布，它附加到所有区域昵称，包括15918。因此，IS-IS将数据包路由到RB2。或者，如果可分辨的昵称范围用于级别2，则看到此类出口昵称的级别1 TRILL交换机将知道路由到最近的边界路由器，该边界路由器可由is-is“附加位”[is-is]指示。
- RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with the area nickname, so it replaces 27 with 15961. Within Level 2, the ingress RBridge field in the TRILL header will therefore be 15961, and the egress RBridge field will be 15918. Also RB2 learns that S is attached to nickname 27 in area 15961 to accommodate return traffic.
- RB2在将数据包从级别1转换到级别2时，将入口颤音交换机昵称替换为区域昵称，因此将27替换为15961。在级别2内，颤音报头中的入口RBridge字段因此将为15961，而出口RBridge字段将为15918。RB2还了解到，S被附加到15961区域的昵称27上，以容纳返回流量。
- The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, reachability to the nickname 15918.
- 分组通过级别2转发到RB3，RB3在级别2中通告了昵称15918的可达性。
- RB3, when forwarding into area 15918, replaces the egress nickname in the TRILL header with RB4's nickname (44). So, within the destination area, the ingress nickname will be 15961 and the egress nickname will be 44.
- 当转发到区域15918时，RB3将颤音报头中的出口昵称替换为RB4的昵称（44）。因此，在目的地区域内，入口昵称为15961，出口昵称为44。
- RB4, when decapsulating, learns that S is attached to nickname 15961, which is the area nickname of the ingress.
- RB4在解除封装时，得知S附加到昵称15961，该昵称是入口的区域昵称。
Now suppose that D's location has not been learned by RB1 and/or RB3. What will happen, as it would in TRILL today, is that RB1 will forward the packet as multi-destination, choosing a tree. As the multi-destination packet transitions into Level 2, RB2 replaces the ingress nickname with the area nickname. If RB1 does not know the location of D, the packet must be flooded, subject to possible pruning, in Level 2 and, subject to possible pruning, from Level 2 into every Level 1 area that it reaches on the Level 2 distribution tree.
现在，假设RB1和/或RB3没有识别D的位置。正如今天的TRILL一样，RB1将选择一棵树作为多目的地转发数据包。当多目的地数据包过渡到第2级时，RB2将入口昵称替换为区域昵称。如果RB1不知道D的位置，则必须在第2级将数据包淹没，并进行可能的修剪，并且在可能的修剪下，从第2级将数据包淹没到它在第2级分发树上到达的每个第1级区域。
Now suppose that RB1 has learned the location of D (attached to nickname 15918), but RB3 does not know where D is. In that case, RB3 must turn the packet into a multi-destination packet within area 15918. In this case, care must be taken so that in the case in which RB3 is not the designated transitioner between Level 2 and its area for that multi-destination packet, but was on the unicast path, that border TRILL switch in that area does not forward the now multi-destination packet back into Level 2. Therefore, it would be desirable to have a marking, somehow, that indicates the scope of this packet's distribution to be "only this area" (see also Section 4).
现在假设RB1已经知道了D的位置（附加到昵称15918），但RB3不知道D在哪里。在这种情况下，RB3必须在区域15918内将该分组转变为多目的地分组。在这种情况下，必须小心，以便在RB3不是该多目的地数据包的级别2与其区域之间的指定传递者，而是在单播路径上的情况下，该区域中的边界颤音交换机不会将现在的多目的地数据包转发回级别2。因此，希望有一个标记，以某种方式表明该数据包的分发范围为“仅此区域”（另见第4节）。
In cases where there are multiple transitioners for unicast packets, the border-learning mode of operation requires that the address learning between them be shared by some protocol such as running ESADI [RFC7357] for all Data Labels of interest to avoid excessive unknown unicast flooding.
在单播分组有多个转发器的情况下，边界学习操作模式要求它们之间的地址学习由一些协议共享，例如对所有感兴趣的数据标签运行ESADI[RFC7357]，以避免过度未知的单播泛洪。
The potential issue described at the end of Section 2.2.1 with trees in the unique-nickname alternative is eliminated with aggregated nicknames. With aggregated nicknames, each border TRILL switch that will transition multi-destination packets can have a mapping between Level 2 tree nicknames and Level 1 tree nicknames. There need not even be agreement about the total number of trees: just agreement that the border TRILL switch have some mapping and replace the egress TRILL switch nickname (the tree name) when transitioning levels.
第2.2.1节末尾描述的唯一昵称备选方案中的树的潜在问题通过聚合昵称消除。使用聚合的昵称，每个将转换多个目的地数据包的边界TRILL开关可以在2级树昵称和1级树昵称之间具有映射。甚至不需要就树的总数达成一致：只需同意边界颤音开关有一些映射，并在转换级别时替换出口颤音开关昵称（树名）。
There is a variant possibility where two additional fields could exist in TRILL Data packets that could be called the "ingress swap nickname field" and the "egress swap nickname field". This variant is described below for completeness, but it would require fast-path hardware changes from the existing TRILL protocol. The changes in the example above would be as follows:
TRILL数据包中可能存在两个附加字段，分别称为“入口交换昵称字段”和“出口交换昵称字段”。为了完整起见，下面描述了该变体，但它需要对现有TRILL协议进行快速路径硬件更改。上述示例中的更改如下所示：
- RB1 will have learned the area nickname of D and the TRILL switch nickname of RB4 to which D is attached. In encapsulating a frame to D, it puts an area nickname of D (15918) in the egress nickname field of the TRILL Header and puts a nickname of RB3 (44) in an egress swap nickname field.
- RB1将学习D的区域昵称和RB4的颤音开关昵称，D连接到该昵称。在将帧封装到D中时，它将区域昵称D（15918）置于TRILL报头的出口昵称字段中，并将昵称RB3（44）置于出口交换昵称字段中。
- RB2 moves the ingress nickname to the ingress swap nickname field and inserts 15961, an area nickname for S, into the ingress nickname field.
- RB2将入口昵称移动到入口交换昵称字段，并将15961（入口的区域昵称）插入入口昵称字段。
- RB3 swaps the egress nickname and the egress swap nickname fields, which sets the egress nickname to 44.
- RB3交换出口昵称和出口交换昵称字段，这将出口昵称设置为44。
- RB4 learns the correspondence between the source MAC/VLAN of S and the { ingress nickname, ingress swap nickname field } pair as it decapsulates and egresses the frame.
- RB4在解封装和退出帧时，学习S的源MAC/VLAN与{ingress昵称，ingress交换昵称字段}对之间的对应关系。
See [TRILL-IP] for a multilevel proposal using aggregated swap nicknames with a single nickname representing an area.
请参阅[TRILL-IP]，了解使用聚合交换昵称和表示区域的单个昵称的多级方案。
The border-learning variant described in Section 2.2.2.1 minimizes the change in non-border TRILL switches, but it imposes the burden on border TRILL switches of learning and doing lookups in all the end-station MAC addresses within their area(s) that are used for communication outside the area. This burden could be reduced by decreasing the area size and increasing the number of areas.
第2.2.2.1节中描述的边界学习变体将非边界颤音开关的变化降至最低，但它对边界颤音开关施加了学习和查找其区域内用于区域外通信的所有终端站MAC地址的负担。可以通过减小面积和增加面积来减轻这一负担。
The Swap Nickname Field variant described in Section 2.2.2.2 eliminates the extra address learning burden on border TRILL switches, but it requires changes to the TRILL Data packet header and more extensive changes to non-border TRILL switches. In particular, with this alternative, non-border TRILL switches must learn to associate both a TRILL switch nickname and an area nickname with end-station MAC/label pairs (except for addresses that are local to their area).
第2.2.2.2节中描述的交换昵称字段变量消除了边界TRILL交换机的额外地址学习负担，但它需要更改TRILL数据包头，并对非边界TRILL交换机进行更广泛的更改。特别是，使用此替代方案，非边界TRILL交换机必须学会将TRILL交换机昵称和区域昵称与终端站MAC/标签对相关联（其所在区域的本地地址除外）。
The Swap Nickname Field alternative is more scalable but less backward compatible for non-border TRILL switches. It would be possible for border and other Level 2 TRILL switches to support both border learning, for support of legacy Level 1 TRILL switches, and Swap Nickname Field, to support Level 1 TRILL switches that understood the Swap Nickname Field method based on variations in the TRILL header; however, this would be even more complex.
交换昵称字段选项更具可扩展性，但对于非边界TRILL交换机向后兼容程度较低。border和其他2级TRILL交换机可以支持border学习（支持传统1级TRILL交换机）和Swap昵称字段，以支持1级TRILL交换机，该1级TRILL交换机基于TRILL报头中的变化理解Swap昵称字段方法；然而，这将更加复杂。
The requirement to change the TRILL header and fast-path processing to support the Swap Nickname Field variant make it impractical for the foreseeable future.
更改TRILL报头和快速路径处理以支持交换昵称字段变量的要求在可预见的未来不可行。
It is easy to build a multi-area tree by building a tree in each area separately, (including the Level 2 area), and then having only a single-border TRILL switch, say RBx, in each area, attach to the Level 2 area. RBx would forward all multi-destination packets between that area and Level 2.
通过分别在每个区域（包括Level 2区域）中构建一棵树，然后在每个区域中只有一个边框颤音开关（例如RBx）连接到Level 2区域，可以轻松构建多区域树。RBx将在该区域和级别2之间转发所有多目的地数据包。
However, people might find this unacceptable because of the desire to path split (not always sending all multi-destination traffic through the same border TRILL switch).
然而，人们可能会发现这是不可接受的，因为他们希望路径分割（并不总是通过同一个边界颤音交换机发送所有多目的地流量）。
This is the same issue as with multiple ingress TRILL switches injecting traffic from a pseudonode, and it can be solved with the mechanism that was adopted for that purpose: the affinity TLV [RFC7783]. For each tree in the area, at most one border RB announces itself in an affinity TLV with that tree name.
这与从伪节点注入流量的多个入口TRILL交换机的问题相同，可以通过为此目的采用的机制来解决：亲和TLV[RFC7783]。对于该区域中的每棵树，最多有一个边界RB在具有该树名称的关联TLV中声明自己。
For multi-destination data originating locally in RBx's area, computation of the RPF check is done as today. For multi-destination packets originating outside RBx's area, computation of the RPF check must be done based on which one of the border TRILL switches (say RB1, RB2, or RB3) injected the packet into the area.
对于源自RBx区域的本地多目的地数据，RPF检查的计算与今天一样。对于源自RBx区域之外的多目的地数据包，必须根据哪一个边界颤音交换机（如RB1、RB2或RB3）将数据包注入该区域来计算RPF检查。
A TRILL switch, say RB4, located inside an area, must be able to know which of RB1, RB2, or RB3 transitioned the packet into the area from Level 2 (or into Level 2 from an area).
位于某个区域内的TRILL交换机（如RB4）必须能够知道RB1、RB2或RB3中的哪一个将数据包从第2级转换到该区域（或从某个区域转换到第2级）。
This could be done using any one of a variety of mechanisms such as having the DBRB announce the transitioner assignments to all the TRILL switches in the area or using the Affinity sub-TLV mechanism given in [RFC7783] or with a New Tree Encoding mechanism discussed in Section 4.1.1.
这可以使用多种机制中的任何一种来实现，例如让DBRB向该区域中的所有颤音开关宣布传递者分配，或者使用[RFC7783]中给出的亲和子TLV机制，或者使用第4.1.1节中讨论的新树编码机制。
In the aggregated-nickname alternative, each area must acquire a unique identifier, for example, by acquiring a unique area nickname or by using an identifier based on the area's set of border TRILL switches. It is probably simpler to allocate a block of nicknames (say, the top 4000) to either (1) represent areas and not specific TRILL switches or (2) be used by border TRILL switches if the set of such border TRILL switches represent the area.
在聚合昵称备选方案中，每个区域必须获取唯一标识符，例如，通过获取唯一的区域昵称或使用基于区域边界颤音开关集的标识符。将一组昵称（例如，前4000个）分配给（1）表示区域而不是特定的颤音开关，或者（2）由边界颤音开关使用（如果这组边界颤音开关表示区域），可能更简单。
The nicknames used for area identification need to be advertised and acquired through Level 2.
用于区域标识的昵称需要通过级别2进行宣传和获取。
Within an area, all the border TRILL switches can discover each other through the Level 1 LSDB, by using the IS-IS "attached bit" [IS-IS] or by explicitly advertising in their LSP "I am a border RBridge".
在一个区域内，通过使用IS-IS“附加位”[IS-IS]或通过在其LSP中明确宣传“我是边界RBridge”，所有边界颤音交换机都可以通过级别1 LSDB相互发现。
Of the border TRILL switches, one will have highest priority (say RB7). RB7 can dynamically participate, in Level 2, to acquire a nickname for identifying the area. Alternatively, RB7 could give the area a pseudonode IS-IS ID, such as RB7.5, within Level 2. So an area would appear, in Level 2, as a pseudonode and the pseudonode could participate, in Level 2, to acquire a nickname for the area.
在边界颤音开关中，一个具有最高优先级（比如RB7）。RB7可以在第2级动态参与，以获取用于标识该区域的昵称。或者，RB7可以在级别2内为该区域提供伪节点IS-IS ID，例如RB7.5。因此，在第2级中，一个区域将显示为伪节点，并且该伪节点可以在第2级中参与，以获取该区域的昵称。
Within Level 2, all the border TRILL switches for an area can advertise reachability to the area, which would mean connectivity to a nickname identifying the area.
在第2级中，一个区域的所有边界颤音开关都可以宣传该区域的可达性，这意味着连接到标识该区域的昵称。
Within an area, say area A1, there is an election for the DBRB, say RB1. This can be done through LSPs within area A1. The border TRILL switches announce themselves, together with their DBRB priority. (Note that the election of the DBRB cannot be done based on Hello messages, because the border TRILL switches are not necessarily physical neighbors of each other. They can, however, reach each other through connectivity within the area, which is why it will work to find each other through Level 1 LSPs.)
在一个区域内，比如A1区域，有一个DBRB选举，比如RB1。这可以通过A1区内的LSP完成。边界颤音开关宣布它们自己以及它们的DBRB优先级。（请注意，DBRB的选择不能基于Hello消息，因为border TRILL交换机不一定是彼此的物理邻居。但是，它们可以通过区域内的连接相互联系，这就是为什么通过级别1 LSP查找彼此。）
RB1 can acquire an area nickname (in the aggregated-nickname approach), and may give the area a pseudonode IS-IS ID (just like the Designated RBridge (DRB) would give a pseudonode IS-IS ID to a link) depending on how the area nickname is handled. RB1 advertises, in area A1, an area nickname that RB1 has acquired (and what the pseudonode IS-IS ID for the area is if needed).
RB1可以获取区域昵称（在聚合昵称方法中），并且可以根据区域昵称的处理方式为该区域提供伪节点IS-IS ID（就像指定的RBridge（DRB）将为链路提供伪节点IS-IS ID）。RB1在区域A1中公布RB1已获得的区域昵称（如果需要，该区域的伪节点ID是什么）。
Level 1 LSPs (possibly pseudonode) initiated by RB1 for the area include any information external to area A1 that should be input into area A1 (such as nicknames of external areas, or perhaps (in the unique nickname variant) all the nicknames of external TRILL switches in the TRILL campus and pruning information such as multicast listeners and labels). All the other border TRILL switches for the area announce (in their LSP) attachment to that area.
RB1为区域启动的1级LSP（可能是伪节点）包括区域A1外部的任何信息，这些信息应输入到区域A1中（例如外部区域的昵称，或者可能（在唯一昵称变体中）TRILL校园中外部TRILL交换机的所有昵称，以及修剪信息（如多播侦听器和标签）。该区域的所有其他边界颤音开关宣布（在其LSP中）连接到该区域。
Within Level 2, RB1 generates a Level 2 LSP on behalf of the area. The same pseudonode ID could be used within Level 1 and Level 2, for the area. (There does not seem any reason why it would be useful for it to be different, but there's also no reason why it would need to be the same). Likewise, all the area A1 border TRILL switches would announce, in their Level 2 LSPs, connection to the area.
在级别2内，RB1代表区域生成级别2 LSP。对于该区域，可以在级别1和级别2内使用相同的伪节点ID。（似乎没有任何理由说明它的不同是有用的，但也没有理由说明它需要相同）。同样，所有A1区边界颤音交换机将在其2级LSP中宣布与该区的连接。
It is possible for an area to become partitioned, so that there is still a path from one section of the area to the other, but that path is via the Level 2 area.
一个区域可能被分区，因此仍然存在从该区域的一个部分到另一个部分的路径，但该路径是通过Level 2区域的。
With multilevel TRILL, an area will naturally break into two areas in this case.
在这种情况下，使用多级颤音时，一个区域将自然分为两个区域。
Area addresses might be configured to ensure two areas are not inadvertently connected. Area addresses appear in Hellos and LSPs within the area. If two chunks, connected only via Level 2, were configured with the same area address, this would not cause any problems. (They would just operate as separate Level 1 areas.)
区域地址可以配置为确保两个区域不会意外连接。区域地址显示在区域内的Hellos和LSP中。如果仅通过级别2连接的两个区块配置了相同的区域地址，这不会导致任何问题。（它们将作为单独的一级区域运行。）
A more serious problem occurs if the Level 2 area is partitioned in such a way that it could be healed by using a path through a Level 1 area. TRILL will not attempt to solve this problem. Within the Level 1 area, a single-border RBridge will be the DBRB, and will be in charge of deciding which (single) RBridge will transition any particular multi-destination packets between that area and Level 2. If the Level 2 area is partitioned, this will result in multi-destination data only reaching the portion of the TRILL campus reachable through the partition attached to the TRILL switch that transitions that packet. It will not cause a loop.
如果2级区域的分区方式可以通过使用穿过1级区域的路径进行修复，则会出现更严重的问题。TRILL不会试图解决这个问题。在级别1区域内，单个边界RBridge将是DBRB，并将负责决定哪个（单个）RBridge将在该区域和级别2之间转换任何特定的多目的地数据包。如果对2级区域进行分区，这将导致多目标数据仅到达TRILL园区的部分，该部分可通过连接到转换该数据包的TRILL交换机的分区到达。它不会导致循环。
There are at least two reasons it would be desirable to be able to mark a multi-destination packet with a scope that indicates the packet should not exit the area, as follows:
至少有两个原因，希望能够用指示数据包不应退出该区域的范围来标记多目的地数据包，如下所示：
1. To address an issue in the border learning variant of the aggregated-nickname alternative, when a unicast packet turns into a multi-destination packet when transitioning from Level 2 to Level 1, as discussed in Section 4.1.
1. 如第4.1节所述，当单播分组从第2级过渡到第1级时变为多目的地分组，以解决聚合昵称备选方案的边界学习变量中的问题。
2. To constrain the broadcast domain for certain discovery, directory, or service protocols as discussed in Section 4.2.
2. 如第4.2节所述，为某些发现、目录或服务协议约束广播域。
Multi-destination packet distribution scope restriction could be done in a number of ways. For example, there could be a flag in the packet that means "for this area only". However, the technique that might require the least change to TRILL switch fast-path logic would be to indicate this in the egress nickname that designates the distribution tree being used. There could be two general tree nicknames for each tree, one being for distribution restricted to the area and the other being for multi-area trees. Or there would be a set of N (perhaps 16) special currently reserved nicknames used to specify the N highest priority trees but with the variation that if the special nickname is used for the tree, the packet is not transitioned between areas. Or one or more special trees could be built that were restricted to the local area.
多目的地数据包分布范围限制可以通过多种方式完成。例如，数据包中可能有一个标志，表示“仅适用于此区域”。然而，可能需要对TRILL交换机快速路径逻辑进行最少更改的技术是在出口昵称中指明这一点，该昵称指定正在使用的分发树。每棵树可能有两个通用的树别名，一个用于限制在该区域的分布，另一个用于多区域树。或者将有一组N个（可能16个）当前保留的特殊昵称用于指定N个最高优先级树，但是如果特殊昵称用于树，则数据包不会在区域之间转换。或者可以建造一棵或多棵限制在当地的特殊树木。
In the border learning variant of the aggregated-nickname alternative, the following situation may occur:
在聚合昵称备选方案的边界学习变体中，可能出现以下情况：
- a unicast packet might be known at the Level 1 to Level 2 transition and be forwarded as a unicast packet to the least-cost border TRILL switch advertising connectivity to the destination area, but
- 单播分组可能在级别1到级别2的转换处已知，并且作为单播分组转发到成本最低的边界颤音交换机，以广告连接到目的地区域，但是
- upon arriving at the border TRILL switch, it turns out to have an unknown destination { MAC, Data Label } pair.
- 到达border TRILL交换机后，发现它有一个未知的目的地{MAC，数据标签}对。
In this case, the packet must be converted into a multi-destination packet and flooded in the destination area. However, if the border TRILL switch doing the conversion is not the border TRILL switch designated to transition the resulting multi-destination packet, there is the danger that the designated transitioner may pick up the packet and flood it back into Level 2 from which it may be flooded into multiple areas. This danger can be avoided by restricting any
在这种情况下，必须将数据包转换为多目的地数据包，并在目的地区域进行泛洪处理。但是，如果执行转换的边界颤音交换机不是指定用于转换生成的多目的地数据包的边界颤音交换机，则存在这样的危险，即指定的转换者可能会拾取该数据包并将其泛流回级别2，从该级别它可能被泛流到多个区域。这种危险可以通过限制任何
multi-destination packet that results from such a conversion to the destination area as described above.
由如上所述的到目的地区域的这种转换产生的多目的地分组。
Alternatively, a multi-destination packet intended only for the area could be tunneled (within the area) to the RBridge RBx, that is the appointed transitioner for that form of packet (say, based on VLAN or FGL), with instructions that RBx only transmit the packet within the area, and RBx could initiate the multi-destination packet within the area. Since RBx introduced the packet, and is the only one allowed to transition that packet to Level 2, this would accomplish scoping of the packet to within the area. Since this case only occurs in the unusual case when unicast packets need to be turned into multi-destination as described above, the suboptimality of tunneling between the border TRILL switch that receives the unicast packet and the appointed level transitioner for that packet might not be an issue.
或者，仅用于该区域的多目的地分组可以通过隧道（在该区域内）传输到RBridge RBx，即该形式分组的指定传递者（例如，基于VLAN或FGL），并指示RBx仅在该区域内传输该分组，RBx可以在该区域内发起多目的地分组。由于RBx引入了该数据包，并且是唯一允许将该数据包转换到第2级的数据包，因此这将完成该数据包在该区域内的作用域。由于这种情况仅发生在如上所述单播分组需要转变为多目的地的异常情况下，因此接收单播分组的边界颤音交换机和该分组的指定级别转发器之间的隧道的次优性可能不是问题。
The current encoding, in a TRILL header of a tree, is of the nickname of the tree root. This requires all 16 bits of the egress nickname field. TRILL could instead, for example, use the bottom 6 bits to encode the tree number (allowing 64 trees), leaving 10 bits to encode information such as:
树的颤音头中的当前编码是树根的昵称。这需要出口昵称字段的所有16位。例如，TRILL可以使用底部6位编码树编号（允许64棵树），留下10位编码信息，例如：
scope: a flag indicating whether it should be single area only or an entire campus
范围：一个标志，指示它应该是单个区域还是整个校园
border injector: an indicator of which of the k border TRILL switches injected this packet
border injector（边界注入器）：指示哪个k border TRILL开关注入此数据包的指示器
If TRILL were to adopt this new encoding, any of the TRILL switches in an edge group could inject a multi-destination packet. This would require all TRILL switches to be changed to understand the new encoding for a tree, and it would require a TLV in the LSP to indicate which number each of the TRILL switches in an edge group would be.
如果TRILL采用这种新编码，边缘组中的任何TRILL开关都可以注入多目的地数据包。这需要更改所有颤音开关以了解树的新编码，并且需要LSP中的TLV来指示边缘组中每个颤音开关的编号。
While there are a number of advantages to this technique, it requires fast-path logic changes; thus, its deployment is not practical at this time. It is included here for completeness.
虽然这种技术有许多优点，但它需要快速的路径逻辑更改；因此，它的部署在目前并不实际。为了完整起见，这里包含了它。
There are a number of service, discovery, and directory protocols that, for convenience, are accessed via multicast or broadcast frames. Examples are DHCP, the NetBIOS Service Location Protocol, and multicast DNS.
有许多服务、发现和目录协议，为了方便起见，可以通过多播或广播帧访问这些协议。例如DHCP、NetBIOS服务位置协议和多播DNS。
Some such protocols provide means to restrict distribution to an IP subnet or equivalent to reduce size of the broadcast domain they are using, and then they provide a proxy that can be placed in that subnet to use unicast to access a service elsewhere. In cases where a proxy mechanism is not currently defined, it may be possible to create one that references a central server or cache. With multilevel TRILL, it is possible to construct very large IP subnets that could become saturated with multi-destination traffic of this type unless packets can be further restricted in their distribution. Such restricted distribution can be accomplished for some protocols, say protocol P, in a variety of ways including the following:
一些这样的协议提供了将分发限制到IP子网或等效子网的方法，以减小它们正在使用的广播域的大小，然后它们提供了一个可以放置在该子网中的代理，以使用单播访问其他地方的服务。在当前未定义代理机制的情况下，可以创建一个引用中央服务器或缓存的代理机制。使用多级TRILL，可以构建非常大的IP子网，这些子网可能会被这种类型的多目的地流量饱和，除非数据包在其分布中受到进一步限制。对于某些协议，例如协议P，可以通过多种方式实现这种受限分发，包括以下方式：
- Either (1) at all ingress TRILL switches in an area, place all protocol P multi-destination packets on a distribution tree in such a way that the packets are restricted to the area or (2) at all border TRILL switches between that area and Level 2, detect protocol P multi-destination packets and do not transition them.
- （1）在一个区域内的所有入口颤音开关处，将所有协议P多目的地数据包放置在分发树上，使数据包限制在该区域内；或（2）在该区域和级别2之间的所有边界颤音开关处，检测协议P多目的地数据包，并且不转换它们。
- Then, place one, or a few for redundancy, protocol P proxies inside each area where protocol P may be in use. These proxies unicast protocol P requests or other messages to the actual campus server(s) for P. They also receive unicast responses or other messages from those servers and deliver them within the area via unicast, multicast, or broadcast as appropriate. (Such proxies would not be needed if it was acceptable for all protocol P traffic to be restricted to an area.)
- 然后，在可能使用协议P的每个区域内放置一个或几个冗余的协议P代理。这些代理将单播协议P请求或其他消息发送到P的实际校园服务器。它们还接收来自这些服务器的单播响应或其他消息，并根据需要在区域内通过单播、多播或广播进行传递。（如果可以接受将所有协议P流量限制在一个区域内，则不需要此类代理。）
While it might seem logical to connect the campus servers to TRILL switches in Level 2, they could be placed within one or more areas so that, in some cases, those areas might not require a local proxy server.
虽然在第2级将校园服务器连接到TRILL交换机似乎是合乎逻辑的，但它们可以放置在一个或多个区域内，以便在某些情况下，这些区域可能不需要本地代理服务器。
TRILL switches that are not multilevel aware may have a problem with calculating RPF check and filtering information, since they would not be aware of the assignment of border TRILL switch transitioning.
没有多级感知的颤音开关在计算RPF检查和过滤信息时可能有问题，因为它们不知道边界颤音开关转换的分配。
A possible solution, as long as any old TRILL switches exist within an area, is to have the border TRILL switches elect a single DBRB and have all inter-area traffic go through the DBRB (unicast as well as multi-destination). If that DBRB goes down, a new one will be elected, but at any one time, all inter-area traffic (unicast as well as multi-destination) would go through that one DRBR. However this eliminates load splitting at level transition.
只要一个区域内存在任何旧的TRILL交换机，一个可能的解决方案就是让边界TRILL交换机选择一个DBRB，并让所有区域间通信通过DBRB（单播和多目的地）。如果该DBRB失效，将选择一个新的DBRB，但在任何时候，所有区域间通信（单播和多目的地）都将通过该DRBR。但是，这消除了级别转换时的负载拆分。
Care must be taken in the case where there are multiple TRILL switches on a link with one or more end stations, keeping in mind that end stations are TRILL ignorant. In particular, it is essential that only one TRILL switch ingress/egress any given data packet from/ to an end station so that connectivity is provided to that end station without duplicating end-station data and that loops are not formed due to one TRILL switch egressing data in native form (i.e., with no TRILL header) and having that data re-ingressed by another TRILL switch on the link.
当一条链路上有多个颤音开关与一个或多个终端站连接时，必须小心，记住终端站不受颤音影响。特别是，必须只有一个TRILL交换机从/到终端站进出任何给定数据包，以便在不复制终端站数据的情况下提供到该终端站的连接，并且由于一个TRILL交换机以本机形式（即，没有TRILL报头）输出数据而不会形成环路并通过链路上的另一个颤音开关重新进入数据。
With existing, single-level TRILL, this is done by electing a single DRB per link, which appoints a single Appointed Forwarder per VLAN [RFC7177] [RFC8139]. This mechanism depends on the RBridges establishing adjacency. But, suppose there are two (or more) TRILL switches on a link in different areas, say RB1 in area A1 and RB2 in area A2, as shown below; and suppose that the link also has one or more end stations attached. If RB1 and RB2 ignore each other's Hellos because they are in different areas, as they are required to do under normal IS-IS PDU processing rules, then they will not form an adjacency. If they are not adjacent, they will ignore each other for the Appointed Forwarder mechanism and will both ingress/egress end-station traffic on the link causing loops and duplication.
对于现有的单级TRILL，这是通过为每个链路选择一个DRB来实现的，该DRB为每个VLAN指定一个指定的转发器[RFC7177][RFC8139]。这种机制依赖于RBRINGS建立邻接关系。但是，假设在不同区域的链路上有两个（或更多）颤音开关，比如A1区域的RB1和A2区域的RB2，如下所示；并且假设链路还连接了一个或多个终端站。如果RB1和RB2由于位于不同的区域而忽略彼此的问候，就像在正常IS-IS PDU处理规则下所要求的那样，那么它们将不会形成邻接。如果它们不是相邻的，它们将在指定的转发器机制中相互忽略，并将同时进入/离开链路上的端站流量，从而导致环路和重复。
The problem is not avoiding adjacency or avoiding TRILL-Data-packet transfer between RB1 and RB2; the area address mechanism of IS-IS or possibly the use of topology constraints (or the like) does that quite well. The problem stems from end stations being TRILL ignorant; therefore, care must be taken so that multiple RBridges on a link do not ingress the same frame originated by an end station and so that an RBridge does not ingress a native frame egressed by a different RBridge because the RBridge mistakes the frame for a frame originated by an end station.
问题不是避免相邻或避免RB1和RB2之间的TRILL数据包传输；IS-IS的区域地址机制或可能使用拓扑约束（或类似）可以很好地实现这一点。问题源于终端站不懂颤音；因此，必须小心，以便链路上的多个RBridge不会进入由端站发起的同一帧，并且RBridge不会进入由不同RBridge退出的本机帧，因为RBridge将帧误认为是由端站发起的帧。
+--------------------------------------------+
| Level 2 |
+----------+---------------------+-----------+
| Area A1 | | Area A2 |
| +---+ | | +---+ |
| |RB1| | | |RB2| |
| +-+-+ | | +-+-+ |
| | | | | |
+-----|----+ +-----|-----+
| |
--+---------+-------------+--------+-- Link
| |
+------+------+ +--+----------+
| End Station | | End Station |
+-------------+ +-------------+
+--------------------------------------------+
| Level 2 |
+----------+---------------------+-----------+
| Area A1 | | Area A2 |
| +---+ | | +---+ |
| |RB1| | | |RB2| |
| +-+-+ | | +-+-+ |
| | | | | |
+-----|----+ +-----|-----+
| |
--+---------+-------------+--------+-- Link
| |
+------+------+ +--+----------+
| End Station | | End Station |
+-------------+ +-------------+
A simple rule, which is preferred, is to use the TRILL switch or switches having the lowest-numbered area, comparing area numbers as unsigned integers, to handle all native traffic to/from end stations on the link. This would automatically give multilevel-ignorant legacy TRILL switches, that would be using area number zero, highest priority for handling end-station traffic, which they would try to do anyway.
首选的一个简单规则是使用一个或多个具有最低编号区域的TRILL交换机，将区域编号作为无符号整数进行比较，以处理链路上与终端站之间的所有本机流量。这将自动为多电平TRILL交换机提供服务，该交换机将使用区域编号0，处理端站通信的最高优先级，他们无论如何都会尝试这样做。
Other methods are possible. For example, making the selection of the Appointed Forwarders and the TRILL switch in charge of that selection across all TRILL switches on the link, regardless of area. However, a special case would then have to be made for legacy TRILL switches using area number zero.
其他方法也是可能的。例如，选择指定的转发器和负责链接上所有颤音开关选择的颤音开关，而不考虑区域。然而，对于使用区域编号为零的传统颤音开关，必须进行特殊处理。
These techniques require multilevel-aware TRILL switches to take actions based on Hellos from RBridges in other areas, even though they will not form an adjacency with such RBridges. However, the action is quite simple in the preferred case: if a TRILL switch sees Hellos from lower-numbered areas, then they would not act as an Appointed Forwarder on the link until the Hello timer for such Hellos had expired.
这些技术要求多级感知颤音开关根据来自其他区域的RBridges的hello采取行动，即使它们不会与此类RBridges形成邻接。但是，在首选情况下，操作非常简单：如果TRILL开关从编号较低的区域看到Hello，则在Hello计时器过期之前，它们不会充当链接上的指定转发器。
This document describes potential scaling issues in TRILL and possible approaches to multilevel TRILL as a solution or element of a solution to most of them.
本文档描述了TRILL中潜在的扩展问题，以及将多级TRILL作为解决方案或解决方案的一部分的可能方法。
The alternative using aggregated-nickname areas in multilevel TRILL has significant advantages in terms of scalability over using campus-wide unique nicknames, not just in avoiding nickname exhaustion, but by allowing RPF checks to be aggregated based on an entire area.
与使用校园范围内的唯一昵称相比，在多级TRILL中使用聚合昵称区域的替代方案在可伸缩性方面具有显著优势，这不仅避免了昵称耗尽，而且允许基于整个区域聚合RPF检查。
However, the alternative of using unique nicknames is simpler and avoids the changes in border TRILL switches required to support aggregated nicknames. It is possible to support both. For example, a TRILL campus could use simpler unique nicknames until scaling begins to cause problems and then start to introduce areas with aggregated nicknames.
但是，使用唯一昵称的替代方法更简单，并且避免了支持聚合昵称所需的边界颤音开关的更改。两者都可以支持。例如，TRILL校园可以使用更简单的唯一昵称，直到扩展开始导致问题，然后开始引入具有聚合昵称的区域。
Some multilevel TRILL issues are not difficult, such as dealing with partitioned areas. Other issues are more difficult, especially dealing with old TRILL switches that are multilevel ignorant.
一些多级颤音问题并不困难，例如处理分区区域。其他问题则更为困难，尤其是处理多级无知的旧颤音开关。
This informational document explores alternatives for the design of multilevel IS-IS in TRILL and generally does not consider security issues.
该信息文件探索替代设计的多级IS-IS在颤音，一般不考虑安全问题。
If aggregated nicknames are used in two areas that have the same area address, and those areas merge, there is a possibility of a transient nickname collision that would not occur with unique nicknames. Such a collision could cause a data packet to be delivered to the wrong egress TRILL switch, but it would still not be delivered to any end station in the wrong Data Label; thus, such delivery would still conform to security policies.
如果在具有相同区域地址的两个区域中使用聚合的昵称，并且这些区域合并，则可能会发生暂时的昵称冲突，该冲突不会与唯一的昵称发生。这种冲突可能导致数据分组被传送到错误的出口TRILL交换机，但它仍然不会被传送到错误数据标签中的任何终端站；因此，这种交付仍然符合安全政策。
For general TRILL security considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- 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)", ISO/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国际标准化组织，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，ISO/IEC 10589:2002，第二版，2002年11月。
[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>.
[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>.
[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>.
[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>.
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, DOI 10.17487/RFC3194, November 2001, <https://www.rfc-editor.org/info/rfc3194>.
[RFC3194]Durand，A.和C.Huitema，“地址分配效率的H密度比——H比率的更新”，RFC 3194，DOI 10.17487/RFC3194，2001年11月<https://www.rfc-editor.org/info/rfc3194>.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, <https://www.rfc-editor.org/info/rfc6361>.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 6361，DOI 10.17487/RFC6361，2011年8月<https://www.rfc-editor.org/info/rfc6361>.
[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>.
[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>.
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, <https://www.rfc-editor.org/info/rfc7781>.
[RFC7781]翟，H.，Senevirathne，T.，Perlman，R.，张，M.，和Y.Li，“大量链路的透明互连（TRILL）：主动-主动访问的伪昵称”，RFC 7781，DOI 10.17487/RFC7781，2016年2月<https://www.rfc-editor.org/info/rfc7781>.
[RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, <https://www.rfc-editor.org/info/rfc7783>.
[RFC7783]Senevirathne，T.，Pathangi，J.，和J.Hudson，“用于大量链路（TRILL）透明互连的协调多播树（CMT）”，RFC 7783，DOI 10.17487/RFC7783，2016年2月<https://www.rfc-editor.org/info/rfc7783>.
[InterCon] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley Longman, Second Edition, Chapter 3, 1999.
[InterCon]Perlman，R.，“互连：网桥、路由器、交换机和互联协议”，Addison-Wesley Longman，第二版，第3章，1999年。
[TRILL-IP] Bhikkaji, B., Venkataswami, B., Mahadevan, R., Sundaram, S., and N. Swamy, "Connecting Disparate Data Center/PBB/ Campus TRILL sites using BGP", Work in Progress, draft-balaji-trill-over-ip-multi-level-05, March 2012.
[TRILL-IP]Bhikkaji，B.，Venkataswami，B.，Mahadevan，R.，Sundaram，S.，和N.Swamy，“使用BGP连接不同的数据中心/PBB/校园TRILL站点”，正在进行的工作，草案-balaji-TRILL-over-IP-multi-level-052012年3月。
[UNIQUE] Zhang, M., Eastlake, D., Perlman, R., Cullen, M., Zhai, H., and D. Liu, "TRILL Multilevel Using Unique Nicknames", Work in Progress, draft-ietf-trill-multilevel-unique-nickname-02, May 2017.
[独特]张，M.，伊斯特莱克，D.，帕尔曼，R.，卡伦，M.，翟，H.，和D.刘，“使用独特昵称的颤音多电平”，正在进行的工作，草稿-ietf-颤音多电平-独特昵称-02，2017年5月。
[SingleName] Zhang, M., Eastlake, D., Perlman, R., Cullen, M., and H. Zhai, "Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel", Work in Progress, draft-ietf-trill-multilevel-single-nickname-04, July 2017.
[SingleName]Zhang，M.，Eastlake，D.，Perlman，R.，Cullen，M.，和H.Zhai，“多链路的透明互连（TRILL）单区域边界RBridge多电平昵称”，正在进行的工作，草稿-ietf-TRILL-Multiple-Single-昵称-042017年7月。
Acknowledgements
致谢
The helpful comments and contributions of the following are hereby acknowledged:
特此确认以下人员的有用意见和贡献：
Alia Atlas, David Michael Bond, Dino Farinacci, Sue Hares, Gayle Noble, Alexander Vainshtein, and Stig Venaas.
Alia Atlas、David Michael Bond、Dino Farinaci、Sue Hares、Gayle Noble、Alexander Vainstein和Stig Venaas。
Authors' Addresses
作者地址
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America
Radia Perlman EMC 2010美国华盛顿州贝尔维尤市东北第256大道200号，邮编：98007
Email: radia@alum.mit.edu
Email: radia@alum.mit.edu
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为技术有限公司01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies No.156 Beiqing Rd. Haidian District, Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司，邮编100095
Email: zhangmingui@huawei.com
Email: zhangmingui@huawei.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 United States of America
美国加利福尼亚州圣克拉拉大美洲大道5450号Anoop Ghanwani Dell，邮编95054
Email: anoop@alumni.duke.edu
Email: anoop@alumni.duke.edu
Hongjun Zhai Jinling Institute of Technology 99 Hongjing Avenue, Jiangning District Nanjing, Jiangsu 211169 China
中国江苏省南京市江宁区红井大道99号翟鸿钧金陵理工学院211169
Email: honjun.zhai@tom.com
Email: honjun.zhai@tom.com