Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8397 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell EMC
H. Zhai
JIT
D. Liu
China Telecom Co., Ltd
May 2018
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8397 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell EMC
H. Zhai
JIT
D. Liu
China Telecom Co., Ltd
May 2018
Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames
使用唯一昵称的多链路透明互连（TRILL）多级
Abstract
摘要
TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.
TRILL（大量链路的透明互连）路由可以通过构建IS-IS路由的多级特性扩展到支持多个级别。根据昵称的管理方式，有两种实现TRILL多级的主要方法：RFC 8243中讨论的唯一昵称方法和聚合昵称方法。本文档指定了一种独特的昵称方法。这种方法为多级TRILL园区中的所有TRILL交换机提供了独特的昵称。
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/rfc8397.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8397.
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 ....................................................3
2. Acronyms and Terminology ........................................4
3. Data Routing ....................................................4
3.1. Unicast Routing ............................................4
3.2. Multi-destination Routing ..................................5
3.2.1. Local Distribution Trees ............................6
3.2.2. Global Distribution Trees ...........................6
4. Protocol Basics and Extensions ..................................8
4.1. Multilevel TRILL Basics ....................................8
4.2. Nickname Allocation ........................................9
4.3. Nickname Announcements .....................................9
4.4. Capability Indication .....................................11
5. Mix with Aggregated Nickname Areas .............................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
Contributors ......................................................15
Authors' Addresses ................................................15
1. Introduction ....................................................3
2. Acronyms and Terminology ........................................4
3. Data Routing ....................................................4
3.1. Unicast Routing ............................................4
3.2. Multi-destination Routing ..................................5
3.2.1. Local Distribution Trees ............................6
3.2.2. Global Distribution Trees ...........................6
4. Protocol Basics and Extensions ..................................8
4.1. Multilevel TRILL Basics ....................................8
4.2. Nickname Allocation ........................................9
4.3. Nickname Announcements .....................................9
4.4. Capability Indication .....................................11
5. Mix with Aggregated Nickname Areas .............................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
Contributors ......................................................15
Authors' Addresses ................................................15
The multiple-level feature of [IS-IS] can increase the scalability of TRILL as discussed in [RFC8243]. However, multilevel IS-IS needs some extensions to support the TRILL multilevel feature. The two most significant extensions are how TRILL switch nicknames are managed and how distribution trees are handled [RFC8243].
[IS-IS]的多级功能可以增加TRILL的可伸缩性，如[RFC8243]中所述。然而，多级IS-IS需要一些扩展来支持TRILL多级特性。两个最重要的扩展是TRILL交换机昵称的管理方式和分发树的处理方式[RFC8243]。
There are two primary alternatives to realize TRILL multilevel [RFC8243]. One approach, which is referred to as the "aggregated nickname" approach, involves assigning nicknames to the areas, and allowing nicknames to be reused in different areas by having the border TRILL switches rewrite nickname fields when entering or leaving an area. For more description of the aggregated nickname approach, one can refer to [RFC8243] and [SingleN]. The other approach, which is referred to as the "unique nickname" approach, is specified in this document. The unique nickname approach gives unique nicknames to all the TRILL switches in the multilevel campus by having the TRILL switches at the Level 1 / Level 2 border advertise into the Level 1 area those nicknames are not available for assignment in that area and advertising into the Level 2 area those nicknames that are used by the Level 1 area so that other areas cannot use them anymore. The advertising of Level 1 nicknames informs the rest of the campus how to reach the nicknames residing in that area. In this document, protocol extensions that support such advertisement are specified.
实现TRILL多电平[RFC8243]有两种主要选择。一种被称为“聚合昵称”的方法涉及将昵称分配给区域，并允许在不同区域中重用昵称，方法是让边界颤音开关在进入或离开区域时重写昵称字段。有关聚合昵称方法的更多描述，可以参考[RFC8243]和[SingleN]。另一种方法称为“唯一昵称”方法，在本文件中有详细说明。唯一昵称方法为多级园区中的所有颤音交换机提供唯一昵称，方法是将1级/2级边界处的颤音交换机播发到1级区域，这些昵称在该区域中不可分配，并将1级区域使用的昵称播发到2级区域，以便其他地区不能再使用它们了。一级昵称的广告告知校园其他人如何获得居住在该地区的昵称。在本文档中，指定了支持此类广告的协议扩展。
Each RBridge in a unique nickname area calculates two types of trees: local distribution trees and global distributions trees. For multi-destination traffic that is limited to an area, the packets will be flooded on a local distribution tree. Otherwise, the multi-destination packets will be flooded along a global distribution tree.
唯一昵称区域中的每个RBridge计算两种类型的树：局部分布树和全局分布树。对于受限于某个区域的多目的地流量，数据包将被淹没在本地分发树上。否则，多目的地数据包将沿着全局分发树被淹没。
In the unique nickname approach, nicknames are globally valid so that border RBridges do not rewrite the nickname field of TRILL data packets that transition between Level 1 and Level 2, as border RBridges do in the aggregated nickname approach. If a border RBridge is a transit node on a forwarding path, it does not learn MAC addresses of the TRILL data packets forwarded along this path. Testing and maintenance operations that originate in one area and terminate in a different area are also simplified [RFC8243]. For these reasons, the unique nickname approach might realize simpler border RBridges than the aggregated nickname approach. However, the unique nickname approach is less scalable and may be less well suited for very large campuses.
在唯一昵称方法中，昵称是全局有效的，因此border RBridges不会像聚合昵称方法中的border RBridges那样重写在级别1和级别2之间转换的TRILL数据包的昵称字段。如果边界RBridge是转发路径上的传输节点，它不会学习沿该路径转发的TRILL数据包的MAC地址。起源于一个区域并终止于另一个区域的测试和维护操作也被简化[RFC8243]。由于这些原因，唯一昵称方法可能比聚合昵称方法实现更简单的边界。然而，独特的昵称方法的可扩展性较差，可能不太适合非常大的校园。
Border RBridge: An RBridge that is located on the border between two or more RBridge areas.
边界RBridge：位于两个或多个RBridge区域边界上的RBridge。
Data Label: VLAN or FGL [RFC7172]
数据标签：VLAN或FGL[RFC7172]
IS-IS: Intermediate System to Intermediate System [IS-IS]
IS-IS：中间系统至中间系统[IS-IS]
RBridge: A device implementing the TRILL protocol.
RBridge：实现TRILL协议的设备。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325].
TRILL：链路层中大量链路的透明互连或隧道路由[RFC6325]。
TRILL switch: An alternative name for an RBridge.
颤音开关：RBridge的另一个名称。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Area X level 2 Area Y
+-----------------+ +---------------------+ +------------+
| | | | | |
S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D
| 27 | | | | 44 |
| | | | | |
+-----------------+ +---------------------+ +------------+
Area X level 2 Area Y
+-----------------+ +---------------------+ +------------+
| | | | | |
S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D
| 27 | | | | 44 |
| | | | | |
+-----------------+ +---------------------+ +------------+
Figure 1: An Example Topology for TRILL Multilevel
图1:TRILL多层结构的拓扑示例
Figure 1 is adapted from the example topology of [RFC8243], where S is Source, and D is Destination.
图1改编自[RFC8243]的示例拓扑，其中S是源，D是目的地。
The routing processes are described in the following two subsections.
路由过程在以下两个小节中描述。
The plain RBridge RB27 has a different view of the topology of the TRILL campus than its border RBridge RB2. For an outward path that reaches an RBridge not in the same area (say, RB44), RB27 calculates the segment of the path in Area X, the border RBridge RB2 calculates the segment in Level 2, while the border RBridge to the destination area, RBridge RB3, calculates the segment from itself to RB44.
与边界RBridge RB2相比，平面RBridge RB27对TRILL校园的拓扑结构有不同的看法。对于到达不在同一区域（如RB44）的RBridge的向外路径，RB27计算区域X中路径的分段，边界RBridge RB2计算级别2中的分段，而到达目的区域RBridge RB3的边界RBridge计算从自身到RB44的分段。
Let us say that S transmits a frame to destination D and let us say that D's location is learned by the relevant TRILL switches already. These relevant switches have learned the following:
假设S向目的地D发送了一个帧，并且相关的颤音开关已经知道了D的位置。这些相关开关已了解以下内容：
1) RB27 has learned that D is connected to nickname 44. 2) RB2 has learned that nickname 44 is accessible through RB3.
1) RB27了解到D与昵称44相连。2） RB2已经了解到昵称44可以通过RB3访问。
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的以太网帧。
- RB27 encapsulates with a TRILL header with ingress RBridge nickname 27, and egress RBridge nickname 44 producing a TRILL Data packet.
- RB27使用TRILL报头进行封装，该TRILL报头具有入口RBridge昵称27和出口RBridge昵称44，产生TRILL数据分组。
- RB2 has announced in the Level 1 IS-IS instance in Area X that it owns all nicknames of other areas, including 44. Therefore, IS-IS routes the packet to RB2.
- RB2在区域X的1级IS-IS实例中宣布，它拥有其他区域的所有昵称，包括44个。因此，IS-IS将数据包路由到RB2。
- The packet is forwarded through Level 2, from RB2 to RB3, which has advertised, in Level 2, it owns the nickname 44.
- 数据包通过级别2从RB2转发到RB3，RB3在级别2中公布它拥有昵称44。
- RB3, when forwarding into Area Y, does not change the ingress nickname 27 or the egress nickname 44.
- 当转发到区域Y时，RB3不改变入口昵称27或出口昵称44。
- RB44, when decapsulating, learns that S is attached to nickname 27.
- RB44在解封时，得知S附加到昵称27。
The scope of Multi-destination routing is defined by the tree root nickname. A tree with a Level 2 tree root nickname is global, and a tree with a Level 1 tree root nickname is local. See Section 4.2 for the Level 1 and Level 2 nickname allocation.
多目标路由的范围由树根昵称定义。具有2级树根昵称的树是全局树，具有1级树根昵称的树是局部树。1级和2级昵称分配见第4.2节。
Border RBridges announce the global trees to be calculated only for those Data Labels that span across areas. APPsub-TLVs as specified in Section 3.2 of [RFC7968] will be advertised for this purpose. Based on the Data Label, an ingress RBridge can determine whether a global tree or a local tree is to be used for a TRILL multi-destination Data packet.
Border RBridges宣布仅为跨区域的数据标签计算全局树。[RFC7968]第3.2节中规定的APPsub TLV将为此目的发布广告。基于数据标签，入口RBridge可以确定TRILL多目的地数据分组是使用全局树还是本地树。
If there are legacy TRILL switches that do not understand the APPsub-TLVs for tree selection, configuration MUST guarantee that Data Labels [RFC7172] being used globally in Level 2 are disabled on these legacy TRILL switches. (Otherwise, the legacy TRILL switches might use local trees for multi-destination traffic with a global scope.)
如果存在不了解用于树选择的APPsub TLV的传统TRILL交换机，则配置必须确保在这些传统TRILL交换机上禁用在级别2中全局使用的数据标签[RFC7172]。（否则，传统TRILL交换机可能会使用本地树来处理具有全局范围的多目标流量。）
These legacy TRILL switches may use global trees to flood multi-destination packets with a scope of the local area. Those global trees MUST be pruned at the border TRILL switches based on Data Labels.
这些传统TRILL交换机可以使用全局树以局部区域的范围来淹没多个目的地数据包。必须根据数据标签在边界颤音开关处修剪这些全局树。
The root RBridge RB1 of a local distribution tree resides in the area. RBridges in this area calculate this local tree based on the link state information of this area, using RB1's nickname as the root. Protocol behaviors for local distribution trees have been specified in Section 4.5 of [RFC6325]. The sole difference is that the local distribution tree spans this area only. A multi-destination packet with an egress nickname of the root RBridge of a local tree MUST NOT be leaked into Level 2 at the border RBridge.
本地分发树的根RBridge RB1位于该区域中。此区域中的RBridges基于此区域的链接状态信息，使用RB1的昵称作为根来计算此局部树。[RFC6325]第4.5节规定了本地分发树的协议行为。唯一的区别是，本地分布树仅跨此区域。具有本地树的根RBridge的出口昵称的多目的地数据包不得泄漏到边界RBridge处的级别2。
Within Level 2, the RBridge with the highest tree root priority advertises the set of global trees by providing a list of Level 2 RBridge nicknames as defined in Section 4.5 of [RFC6325].
在第2级中，具有最高树根优先级的RBridge通过提供[RFC6325]第4.5节中定义的第2级RBridge昵称列表来宣传全局树集。
According to [RFC6325], the RBridge with the highest root priority advertises the tree roots for a Level 1 area. There has to be a border RBridge with the highest root tree priority in each area so that it can advertise the global tree root nicknames into the area. Also, this border RBridge MUST advertise the set of local distribution trees by providing another set of nicknames. Since nicknames of global tree roots and local tree roots indicate different flooding scopes, these two sets MUST NOT overlap. If a border RBridge has been assigned both as a global tree root and a local tree root, it MUST acquire both global tree root nickname(s) and local tree root nickname(s). However, non-border RBridges in an area do not differentiate between a global tree root nickname and a local tree root nickname.
根据[RFC6325]，具有最高根优先级的RBridge为1级区域播发树根。每个区域都必须有一个具有最高根树优先级的边界RBridge，以便它可以在该区域中公布全局树根昵称。此外，此边界RBridge必须通过提供另一组昵称来宣传本地分发树集。由于全局树根和局部树根的昵称表示不同的泛洪范围，所以这两个集合不能重叠。如果边界RBridge同时被指定为全局树根和局部树根，则它必须同时获得全局树根昵称和局部树根昵称。但是，区域中的非边界RBridges不会区分全局树根昵称和本地树根昵称。
Suppose RB3 is the RBridge with the highest tree root priority within Level 2, and RB2 is the highest tree root priority in Area X. RB2 advertises in Area X that nickname RB3 is the root of a distribution tree. Figures 2 through 5 illustrate how different RBridges view the global distribution tree.
假设RB3是级别2内具有最高树根优先级的RBridge，RB2是区域X中的最高树根优先级。RB2在区域X中宣传昵称RB3是分发树的根。图2到图5说明了不同的RBridges如何查看全局分布树。
RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44
o
/
Rz o
/
Rx o
/
RB27 o
RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44
o
/
Rz o
/
Rx o
/
RB27 o
Figure 2: RB27's View of the Global Distribution Tree
图2:RB27的全球分布树视图
RB3,Rk,RB44
o
/
Re o
/
Rd o
/
Rc o
/
Rb o
/
RB2 o
/
Rz o
/
Rx o
/
RB27 o
RB3,Rk,RB44
o
/
Re o
/
Rd o
/
Rc o
/
Rb o
/
RB2 o
/
Rz o
/
Rx o
/
RB27 o
Figure 3: RB2's View of the Global Distribution Tree
图3:RB2的全局分布树视图
RB3
o
/ \
Re o o Rk
/ \
Rd o o RB44
/
Rc o
/
Rb o
/
R27,Rx,Rz,RB2 o
RB3
o
/ \
Re o o Rk
/ \
Rd o o RB44
/
Rc o
/
Rb o
/
R27,Rx,Rz,RB2 o
Figure 4: RB3's View of the Global Distribution Tree
图4:RB3的全球分布树视图
RB3,RB27,RBx,RBz,RB2,Rb,Rc,Rd,Re o \ o Rk \ o RB44
RB3、RB27、RBx、RBz、RB2、Rb、Rc、Rd、Re o\o Rk\o RB44
Figure 5: RB44's View of the Global Distribution Tree
图5:RB44的全球分布树视图
The following sequence of events will occur when a multi-destination TRILL Data packet is forwarded using the global distribution tree:
当使用全局分发树转发多目标TRILL数据包时，将发生以下事件序列：
- RB27 produces a multi-destination (M bit is one) TRILL Data packet with ingress RBridge nickname 27 and egress RBridge nickname 3. RB27 floods this packet using the segment of the global distribution tree that resides in Area X.
- RB27产生具有入口RBridge昵称27和出口RBridge昵称3的多目的地（M位为1）TRILL数据包。RB27使用驻留在区域X中的全局分发树的段来洪泛此数据包。
- RB2, when flooding the packet in Level 2, uses the segment of the global distribution tree that resides in Level 2.
- RB2在第2级中泛洪数据包时，使用驻留在第2级中的全局分发树的段。
- RB3, when flooding the packet into Area Y, uses the segment of the global distribution tree that resides in Area Y.
- RB3在将数据包注入区域Y时，使用驻留在区域Y中的全局分发树段。
- The multicast listener RB44, when decapsulating the received packet, learns that S is attached to nickname 27.
- 多播侦听器RB44在解除对接收到的分组的封装时，获悉S被附加到昵称27。
Multilevel TRILL builds on the multilevel feature of [IS-IS]. Border RBridges are in both a Level 1 area and in Level 2. They establish adjacency with Level 1 RBridges as specified in [RFC7177] and [RFC6325]. They establish adjacency with Level 2 RBridges in exactly the same way except that (1) for a LAN link, the IS-IS Hellos used are Level 2 Hello PDUs [IS-IS] and (2) for a point-to-point link, the Level is configured and indicated in flags in the point-to-point Hello. The state machines for Level 1 and Level 2 adjacency are independent, and two RBridges on the same LAN link can have any adjacency state for Level 1 and, separately, any adjacency state for Level 2. Level 1 and Level 2 link state flooding are independent using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP, CSNP, PSNP, FS-LSP, FS-CSNP, and FS-PSNP [RFC7356] [RFC7780]). Thus, Level 1 link state information stays within a Level 1 area and Level 2 link state information stays in Level 2 unless there are specific provisions for leaking (copying) information between levels. This is why multilevel can address the TRILL scalability issues as specified in Section 2 of [RFC8243].
多级颤音建立在[IS-IS]的多级功能的基础上。边界脊位于1级区域和2级区域。它们与[RFC7177]和[RFC6325]中规定的1级RBridge建立邻接关系。它们以完全相同的方式与2级RBridge建立邻接，除了（1）对于LAN链路，使用的IS-IS Hello是2级Hello PDU[IS-IS]和（2）对于点到点链路，该级别在点到点Hello中的标志中配置和指示。级别1和级别2邻接的状态机是独立的，同一LAN链路上的两个RBridge可以具有级别1的任何邻接状态，也可以分别具有级别2的任何邻接状态。使用相关IS-IS PDU（LSP、CSNP、PSNP、FS-LSP、FS-CSNP和FS-PSNP[RFC7356][RFC7780]）的1级和2级链路状态洪泛是独立的。因此，级别1链路状态信息保持在级别1区域内，级别2链路状态信息保持在级别2内，除非有关于在级别之间泄漏（复制）信息的特定规定。这就是为什么Multiple可以解决[RFC8243]第2节中指定的TRILL可伸缩性问题。
The former "campus wide" minimum acceptable link size Sz is calculated as before: by Level 1 RBridges (including border RBridges) using the originatingLSPBufferSize advertised in the Level 1 LSP so it is area local in multilevel TRILL. A minimum acceptable link size in Level 2, called Sz2, is calculated by the RBridges participating in Level 2 in the same way as Sz is calculated but using the originatingLSPBufferSize distributed in Level 2 LSPs.
以前的“校园范围”最小可接受链路大小Sz的计算方法与之前相同：由级别1的RBridges（包括边界RBridges）使用级别1 LSP中公布的原始LSPBufferSize，因此它是多级TRILL中的局部区域。级别2中的最小可接受链路大小（称为Sz2）由参与级别2的RBridge以与计算Sz相同的方式计算，但使用级别2 LSP中分布的原始LSPBufferSize。
Level 2 RBridges contend for nicknames in the range from 0xF000 through 0xFFBF the same way as specified in [RFC6325]: using Level 2 LSPs. The highest-priority border router for a Level 1 area should contend with others in Level 2 for blocks of nicknames for the range from 0x0001 to 0xEFFF. Blocks of 64 aligned on boundaries of multiples of 64 are RECOMMENDED in this document.
第2级RBF使用第2级LSP，以[RFC6325]中规定的相同方式争夺0xF000到0xFFBF范围内的昵称。级别1区域的最高优先级边界路由器应与级别2中的其他路由器争夺从0x0001到0xEFFF范围内的昵称块。本文件建议在64倍数的边界上对齐64块。
The nickname contention in Level 2 will determine which blocks of nicknames are available for an area and which blocks of nicknames are used elsewhere. The NickBlockFlags APPsub-TLV as specified in Section 4.3 will be used by the border RBridge(s) to announce the nickname availability.
级别2中的昵称争用将确定哪些昵称块可用于某个区域，哪些昵称块可用于其他地方。第4.3节中规定的NickBlockFlags APPsub TLV将由边界RBridge用于宣布昵称可用性。
Border RBridges need to exchange nickname information between Level 1 and Level 2; otherwise, forwarding paths inward or outward will not be calculated. For this purpose, border RBridges need to fabricate nickname announcements. Sub-TLVs used for such announcements are specified as follows.
需要在级别1和级别2之间交换昵称信息；否则，将不会计算向内或向外的转发路径。为此，边界RBridges需要制作昵称公告。用于此类公告的子TLV规定如下。
Besides its own nickname(s), a border RBridge MUST announce, in its area, the ownership of all external nicknames that are reachable from this border RBridge. These external nicknames include nicknames used in other unique nickname areas and nicknames in Level 2. Non-border RBridge nicknames within aggregated nickname areas are excluded. Also, a border RBridge MUST announce, in Level 2, the ownership of all nicknames within its area. From listening to these Level 2 announcements, border RBridges can figure out the nicknames used by other areas.
除了自己的昵称外，边境大桥还必须在其所在地区宣布可从此边境大桥访问的所有外部昵称的所有权。这些外部昵称包括在其他唯一昵称区域中使用的昵称和级别2中的昵称。不包括聚合昵称区域内的非边界RBridge昵称。此外，边境居民区必须在第2级宣布其所在区域内所有昵称的所有权。通过收听这些2级公告，border RBridges可以了解其他地区使用的昵称。
RBridges in the TRILL base protocol use the Nickname Sub-TLV as specified in Section 2.3.2 of [RFC7176] to announce the ownership of nicknames. However, it becomes uneconomic to use this Sub-TLV to announce a mass of internal/external nicknames. To address this issue, border RBridges SHOULD make use of the NickBlockFlags
TRILL基本协议中的RBridge使用[RFC7176]第2.3.2节中规定的昵称子TLV来宣布昵称的所有权。但是，使用此子TLV来公布大量内部/外部昵称是不经济的。为了解决这个问题，边界RBridges应该使用NickBlockFlags
APPsub-TLV to advertise into the Level 1 area the inclusive range of nicknames that are or are not available for self allocation by the Level 1 RBridges in that area. Its structure is as follows:
APPsub TLV向1级区域公布该区域中1级RBridge可自行分配或不可自行分配的昵称范围。其结构如下：
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 24 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|OK| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ...
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block K |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 24 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|OK| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ...
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname Block K |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: 24 (TRILL NickBlockFlags)
o 类型：24（颤音NickBlockFlags）
o Length: 2 + 4*K, where K is the number of nickname blocks.
o 长度：2+4*K，其中K是昵称块的数量。
o OK:
o 好 啊：
- When this bit is set to 1, the blocks of nicknames in this APPsub-TLV are associated to the border RBridge's attached Level 1 area. The APPsub-TLV will be advertised in both Level 1 and Level 2. For nicknames that fall in the ranges of the nickname blocks, RBridges of Level 2 always route to the originating border RBridge, just as if this border RBridge owns these nicknames.
- 当该位设置为1时，此APPsub TLV中的昵称块与边界RBridge的附加级别1区域相关联。APPsub TLV将在1级和2级中发布。对于属于昵称块范围的昵称，级别2的RBridge始终路由到原始边界RBridge，就像此边界RBridge拥有这些昵称一样。
- When this bit is set to 0, it indicates that the nicknames covered by the nickname blocks are being used in Level 2 or other areas so that they are not available for use in the border RBridge's attached Level 1 area. The APPsub-TLV will be advertised into Level 1 only. For nicknames that fall in the ranges of the nickname blocks, RBridges of the area always route to the originating border RBridge, just as if this border RBridge owns these nicknames. For nicknames in these ranges, other RBridges will deem that they are owned by the originating border RBridge. The paths to nicknames that fall in these ranges will be calculated to reach the originating border RBridge. TRILL Data packets with egress nicknames that are neither in these ranges nor announced by any RBridge in the area MUST be discarded.
- 当该位设置为0时，表示昵称块覆盖的昵称正在级别2或其他区域中使用，因此它们不可用于边界RBridge的附加级别1区域。APPsub TLV将仅在级别1中发布。对于属于昵称块范围的昵称，该区域的RBridge始终路由到原始边界RBridge，就像该边界RBridge拥有这些昵称一样。对于这些范围内的昵称，其他RBridge将认为它们属于原始边界RBridge。属于这些范围的昵称路径将被计算为到达原始边界RBridge。必须丢弃带有出口昵称的TRILL数据包，这些昵称既不在这些范围内，也不由该地区的任何RBridge宣布。
o RESV: reserved for future flag allocation. MUST be sent as zero and ignored on receipt.
o RESV：保留用于将来的标志分配。必须作为零发送，并在收到时忽略。
o Nickname Block: a starting and ending nickname as follows:
o 昵称块：起始和结束昵称，如下所示：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| starting nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ending nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| starting nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ending nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Nickname Sub-TLV as specified in Section 2.3.2 of [RFC7176] is still allowed to be used, given the above NickBlockFlags APPsub-TLV is being used.
鉴于使用上述NickBlockFlags APPsub TLV，仍允许使用[RFC7176]第2.3.2节中规定的昵称Sub TLV。
There might be multiple border RBridges connected to the same area. Each border RBridge may advertise a subset of the entire internal/external nickname space in order to realize load balance. However, optimization of such load balance is an implementation issue and is outside the scope of this document.
可能有多个边界脊连接到同一区域。为了实现负载平衡，每个边界RBridge可以公布整个内部/外部昵称空间的子集。然而，这种负载平衡的优化是一个实现问题，不在本文档的范围之内。
As specified in Section 4.2.6 of [RFC6325], multiple border RBridges may claim the same nicknames outwardly and/or inwardly. Other RBridges add those nicknames as if they are attached to all of those border RBridges.
如[RFC6325]第4.2.6节所述，多个边界RBridge可以在外部和/或内部使用相同的昵称。其他RBridge添加这些昵称，就好像它们附加到所有这些边界RBridge一样。
All border RBridges MUST understand the NickBlockFlags APPsub-TLV. Non-border RBridges in an area should understand the NickBlockFlags APPsub-TLV. If an RBridge within an area understands the NickBlockFlags APPsub-TLV, it MUST indicate this capability by announcing it in its TRILL-VER Sub-TLV. (See Section 7.)
所有边界RBridge必须理解NickBlockFlags APPsub TLV。区域内的非边界RBRINGS应了解NickBlockFlags APPsub TLV。如果区域内的RBridge了解NickBlockFlags APPsub TLV，则必须通过在颤音版本Sub TLV中宣布该能力来表明该能力。（见第7节。）
If there are RBridges that do not understand the NickBlockFlags APPsub-TLV, border RBridges of the area MUST also use the traditional Nickname Sub-TLV [RFC7176] to announce into the area those nicknames covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose OK is 0. The available range of nicknames for this area should be configured on these traditional RBridges.
如果存在不理解NickBlockFlags APPsub TLV的RBridge，则该区域的边界RBridge还必须使用传统昵称Sub TLV[RFC7176]向该区域宣布NickBlockFlags APPsub TLV昵称块覆盖的昵称，其OK为0。应在这些传统RBridge上配置此区域的可用昵称范围。
The design of TRILL multilevel allows a mixture of unique nickname areas and aggregated nickname areas (see Section 1.2 of [RFC8243]). Usage of nickname space MUST be planned so that nicknames used in any one unique nickname area and Level 2 are never used in any other areas, including unique nickname areas as well as aggregated nickname
TRILL Multiple的设计允许混合唯一昵称区域和聚合昵称区域（见[RFC8243]第1.2节）。必须计划昵称空间的使用，以便在任何一个唯一昵称区域和级别2中使用的昵称不会在任何其他区域中使用，包括唯一昵称区域和聚合昵称
areas. In other words, nickname reusage is merely allowed among aggregated nickname areas.
地区。换句话说，昵称重用只允许在聚合的昵称区域中进行。
Border RBridges of an aggregated area MUST announce nicknames heard from Level 2 into their area like just like a unique nickname border RBridge. However, these RBridges do not announce nicknames of their area into Level 2.
聚合区域的边界RBridge必须宣布从级别2听到的昵称进入其区域，就像唯一的昵称Border RBridge一样。然而，这些RBridge并没有宣布他们所在区域的昵称进入2级。
Each border RBridge of the aggregated areas will appear on the global tree, as specified in Section 4.1, as a single node. The global trees for unique nickname areas span unique nickname areas and Level 2 but never reach the inside of aggregated areas.
按照第4.1节的规定，聚合区域的每个边界将作为单个节点出现在全局树上。唯一昵称区域的全局树跨越唯一昵称区域和级别2，但从未到达聚合区域的内部。
Since TRILL multilevel uses the existing IS-IS multilevel facilities [IS-IS], flooding of control traffic for link-state information is automatically confined to a Level 1 area or to Level 2 (except for limited types of information that can be specifically flagged for wider flooding). This addresses the TRILL scalability issues as specified in Section 2 of [RFC8243], and also, except for the wider flooding case, this confines the scope of the effects of malicious events that could be communicated through the link state. However, due to the fact that unique nickname areas share a common nickname space, border RBridges still have to leak nickname information between levels. Such leaking means that nickname-related events in one area can affect other areas.
由于TRILL multilevel使用现有的IS-IS多级设施[IS-IS]，链路状态信息的控制流量洪流自动限制在1级区域或2级（可专门标记为更广泛洪流的有限类型信息除外）。这解决了[RFC8243]第2节中规定的TRILL可伸缩性问题，并且，除更广泛的泛洪情况外，这限制了可通过链路状态进行通信的恶意事件的影响范围。然而，由于独特的昵称区域共享一个共同的昵称空间，边界RBridge仍然必须在级别之间泄漏昵称信息。这种泄漏意味着一个区域中与昵称相关的事件可能会影响其他区域。
For this purpose, border RBridges need to fabricate the nickname announcements as specified in Section 4.3. Malicious devices may also fake the NickBlockFlags APPsub-TLV to announce a range of nicknames. By doing this, the attacker can attract TRILL data packets that were originally sent to a bunch of other RBridges. For this reason, RBridges SHOULD be configured to use the IS-IS Authentication TLV (10) in the IS-IS PDUs, particularly those containing the NickBlockFlags APPsub-TLV, so that IS-IS security [RFC5310] can be used to authenticate those PDUs and discard them if they are forged.
为此，需要按照第4.3节的规定制作昵称公告。恶意设备也可能伪造NickBlockFlags APPsub TLV以公布一系列昵称。通过这样做，攻击者可以吸引最初发送到一组其他RBridge的颤音数据包。因此，应将RBridge配置为在IS-IS PDU中使用IS-IS身份验证TLV（10），特别是那些包含NickBlockFlags APPsub TLV的PDU，以便可以使用IS-IS安全[RFC5310]对这些PDU进行身份验证，并在其伪造时丢弃。
If border RBridges do not prune multi-destination distribution tree traffic in Data Labels that are configured to be area local, then traffic that should have been contained within an area might be wrongly delivered to end stations in that Data Label in other areas. That is, the Data Label would no longer be area local. This would generally violate security constraints that require traffic to be delivered only to end stations in that Data Label in a single area.
如果边界RBridges没有修剪配置为区域本地的数据标签中的多目的地分发树通信量，则本应包含在某个区域内的通信量可能会错误地传递到其他区域中该数据标签中的终端站。也就是说，数据标签将不再是区域本地的。这通常会违反安全约束，即要求仅将流量传送到单个区域中该数据标签中的终端站。
For general TRILL Security Considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
IANA has registered a new flag bit under the "TRILL-VER Sub-TLV Capability Flags" registry.
IANA已在“TRILL-VER子TLV能力标志”注册表下注册了一个新标志位。
Bit Description Reference
--- ----------- ---------
5 Able to handle the RFC 8397
NickBlockFlags
APPsub-TLV
Bit Description Reference
--- ----------- ---------
5 Able to handle the RFC 8397
NickBlockFlags
APPsub-TLV
IANA has assigned a new type for the NickBlockFlags APPsub-TLV from the range available below 256 and add the following entry to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry as follows:
IANA已为NickBlockFlags APPsub TLV分配了256以下可用范围内的新类型，并将以下条目添加到“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表中，如下所示：
Type Name Reference
---- ------ ---------
24 NickBlockFlags RFC 8397
Type Name Reference
---- ------ ---------
24 NickBlockFlags RFC 8397
[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>.
[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>.
[RFC7968] Li, Y., Eastlake 3rd, D., Hao, W., Chen, H., and S. Chatterjee, "Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data", RFC 7968, DOI 10.17487/RFC7968, August 2016, <https://www.rfc-editor.org/info/rfc7968>.
[RFC7968]Li，Y.，Eastlake 3rd，D.，Hao，W.，Chen，H.，和S.Chatterjee，“大量链路的透明互连（TRILL）：使用数据标签选择多目标数据的树”，RFC 7968，DOI 10.17487/RFC7968，2016年8月<https://www.rfc-editor.org/info/rfc7968>.
[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>.
[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月。
[SingleN] Zhang, M., Eastlake, D., et al, "Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel", draft-ietf-trill-multilevel-single-nickname-05, Work in Progress, January 2018.
[SingleN]Zhang，M.，Eastlake，D.，等，“多链路的透明互连（TRILL）单区域边界RBridge多电平昵称”，草稿-ietf-TRILL-Multilevel-Single-昵称-05，正在进行中，2018年1月。
[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>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <https://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<https://www.rfc-editor.org/info/rfc7356>.
[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>.
[RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and H. Zhai, "Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 10.17487/RFC8243, September 2017, <https://www.rfc-editor.org/info/rfc8243>.
[RFC8243]Perlman，R.，Eastlake 3rd，D.，Zhang，M.，Ghanwani，A.，和H.Zhai，“多链路多级透明互连的替代方案（TRILL）”，RFC 8243，DOI 10.17487/RFC8243，2017年9月<https://www.rfc-editor.org/info/rfc8243>.
Contributors
贡献者
Margaret Cullen Painless Security 14 Summer St. Suite 202 Malden, MA 02148 United States of America
Margaret Cullen无痛安全14 Summer St.202套房美国马萨诸塞州马尔登02148
Email: margaret@painless-security.com
Email: margaret@painless-security.com
Authors' Addresses
作者地址
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张明贵100095
Phone: +86-13810702575
Email: zhangmingui@huawei.com
Phone: +86-13810702575
Email: zhangmingui@huawei.com
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
Radia Perlman Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
美国马萨诸塞州霍普金顿南街176号Radia Perlman Dell EMC 01748
Email: radia@alum.mit.edu
Email: radia@alum.mit.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
Dongxin Liu China Telecom Co., Ltd 109 West Zhongshan Ave, Tianhe District Guangzhou 510630 China
中国广州市天河区中山西街109号东信刘中国电信有限公司510630
Email: liudx@gsta.com
Email: liudx@gsta.com