Internet Engineering Task Force (IETF) Y. Li
Request for Comments: 7968 D. Eastlake 3rd
Category: Standards Track W. Hao
ISSN: 2070-1721 H. Chen
Huawei Technologies
S. Chatterjee
Cisco
August 2016
Internet Engineering Task Force (IETF) Y. Li
Request for Comments: 7968 D. Eastlake 3rd
Category: Standards Track W. Hao
ISSN: 2070-1721 H. Chen
Huawei Technologies
S. Chatterjee
Cisco
August 2016
Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data
大量链接的透明互连（TRILL）：使用数据标签选择多目标数据的树
Abstract
摘要
TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast-path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.
TRILL（大量链路的透明互连）使用分布树来传送多目标帧。无论流的VLAN、细粒度标签（FGL）和/或多播组如何，入口路由桥（RBridge）都可以为流使用多个树。不同的入口rbridge可以为同一VLAN、FGL和/或多播组中的TRILL数据包选择不同的分发树。为了避免不必要的链路利用率，应该基于以下一个或多个来修剪分发树：VLAN、FGL或多播目标地址。如果可以在任何树上发送任何VLAN、FGL或多播组，则对于典型的快速路径硬件，修剪信息量将乘以树的数量，但此类修剪信息的硬件容量有限。
This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.
本文档指定了一个可选功能，用于限制VLAN、FGL和/或多播组在特定分发树上发送的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 http://www.rfc-editor.org/info/rfc7968.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7968.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Background Description .....................................3
1.2. Terminology Used in This Document ..........................4
2. Motivations .....................................................5
3. Tree Selection Based on Data Labels .............................9
3.1. Overview of the Mechanism ..................................9
3.2. APPsub-TLVs Supporting Tree Selection .....................10
3.2.1. The Tree and VLANs APPsub-TLV ......................11
3.2.2. The Tree and VLANs Used APPsub-TLV .................12
3.2.3. The Tree and FGLs APPsub-TLV .......................12
3.2.4. The Tree and FGLs Used APPsub-TLV ..................13
3.2.5. The Tree and Groups APPsub-TLV .....................13
3.2.6. The Tree and Groups Used APPsub-TLV ................14
3.3. Detailed Processing .......................................14
3.4. Failure Handling ..........................................15
4. Backward Compatibility .........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
Acknowledgments ...................................................21
Authors' Addresses ................................................21
1. Introduction ....................................................3
1.1. Background Description .....................................3
1.2. Terminology Used in This Document ..........................4
2. Motivations .....................................................5
3. Tree Selection Based on Data Labels .............................9
3.1. Overview of the Mechanism ..................................9
3.2. APPsub-TLVs Supporting Tree Selection .....................10
3.2.1. The Tree and VLANs APPsub-TLV ......................11
3.2.2. The Tree and VLANs Used APPsub-TLV .................12
3.2.3. The Tree and FGLs APPsub-TLV .......................12
3.2.4. The Tree and FGLs Used APPsub-TLV ..................13
3.2.5. The Tree and Groups APPsub-TLV .....................13
3.2.6. The Tree and Groups Used APPsub-TLV ................14
3.3. Detailed Processing .......................................14
3.4. Failure Handling ..........................................15
4. Backward Compatibility .........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
Acknowledgments ...................................................21
Authors' Addresses ................................................21
One or more distribution trees, identified by their root nicknames, are used to distribute multi-destination data in a (Transparent Interconnection of Lots of Links) (TRILL) campus [RFC6325]. The Routing Bridge (RBridge) having the highest tree root priority announces the total number of trees that should be computed for the campus. It may also specify the list of trees that RBridges need to compute using the Tree Identifiers (TREE-RT-IDs) sub-TLV [RFC7176]. Every RBridge can specify the trees it will use for multi-destination TRILL Data packets it originates in the Trees Used Identifiers (TREE-USE-IDs) sub-TLV [RFC7176], and the VLANs or Fine-Grained Labels (FGLs) [RFC7172] it is interested in are specified in Interested VLANs and/or Interested Labels sub-TLVs [RFC7176]. It is suggested that by default the ingress RBridge uses the distribution tree whose root is the closest [RFC6325]. The TREE-USE-IDs sub-TLV is used to build the RPF (Reverse Path Forwarding) check table that is used for RPF checking. Interested VLANs and Interested Labels sub-TLVs are used for distribution tree pruning, and the multi-destination forwarding table with pruning information is built based on that RPF check table. To reduce unnecessary link loads, each distribution tree should be pruned per VLAN/FGL, eliminating branches that have no potential receivers downstream as specified in [RFC6325]. Further pruning based on Layer 2 or Layer 3 multicast addresses is also possible.
一个或多个分布树（由其根昵称标识）用于在（大量链路的透明互连）（TRILL）校园中分布多目标数据[RFC6325]。具有最高树根优先级的路由桥（RBridge）宣布应为校园计算的树总数。它还可以指定RBridges需要使用树标识符（树RT ID）子TLV[RFC7176]计算的树的列表。每个RBridge都可以指定它将用于多目标TRILL数据包的树，该数据包源自树使用标识符（树使用ID）子TLV[RFC7176]，并且它感兴趣的VLAN或细粒度标签（FGL）[RFC7172]在感兴趣的VLAN和/或感兴趣的标签子TLV[RFC7176]中指定。建议默认情况下，入口RBridge使用根最近的分发树[RFC6325]。树USE IDs sub TLV用于构建用于RPF检查的RPF（反向路径转发）检查表。感兴趣的VLAN和感兴趣的标签子TLV用于分布树修剪，并基于该RPF检查表构建具有修剪信息的多目的地转发表。为了减少不必要的链路负载，应按照VLAN/FGL修剪每个分发树，消除[RFC6325]中规定的下游没有潜在接收器的分支。基于第2层或第3层多播地址的进一步修剪也是可能的。
Defaults are provided, but how many trees are calculated, where the tree roots are located, and which tree or trees are to be used by an ingress RBridge are implementation dependent. With the increasing demand to use TRILL in data center networks, there are some features we can explore for multi-destination frames in the data center use case. In order to achieve non-blocking data forwarding, a fat tree structure is often used. Figure 1 shows a typical data center network based on the fat tree structure. RB1 and RB2 are aggregation switches, and RB11 through RB14 are access switches. It is a common practice to configure the tree roots to be at the aggregation switches for efficient traffic transportation. All the ingress RBridges that are access switches will then be equally distant from all the tree roots.
提供默认值，但计算多少树、树根位于何处以及入口RBridge将使用哪些树取决于实现。随着在数据中心网络中使用TRILL的需求不断增加，我们可以在数据中心用例中探索多目标帧的一些特性。为了实现无阻塞数据转发，通常使用胖树结构。图1显示了基于fat树结构的典型数据中心网络。RB1和RB2是聚合交换机，RB11到RB14是访问交换机。通常的做法是将树根配置在聚合交换机上，以实现高效的流量传输。作为接入交换机的所有入口RBridge与所有树根的距离将相等。
+-----+ +-----+
| RB1 | | RB2 |
+-----+ +-----+
/ | \\ / /|\
/ | \ \ / / | \
/ | \ \ / | \-----+
/ | \/ \ | |
/ | /\/ \| |
/ /---+---/ /\ |\ |
/ / | / \ | \ |
/ / | / \ | \ |
/ / | / \ | \ |
+-----+ +-----+ +-----+ +-----+
| RB11| | RB12| | RB13| | RB14|
+-----+ +-----+ +-----+ +-----+
+-----+ +-----+
| RB1 | | RB2 |
+-----+ +-----+
/ | \\ / /|\
/ | \ \ / / | \
/ | \ \ / | \-----+
/ | \/ \ | |
/ | /\/ \| |
/ /---+---/ /\ |\ |
/ / | / \ | \ |
/ / | / \ | \ |
/ / | / \ | \ |
+-----+ +-----+ +-----+ +-----+
| RB11| | RB12| | RB13| | RB14|
+-----+ +-----+ +-----+ +-----+
Figure 1: TRILL Network Based on Fat Tree Structure
图1：基于Fat树结构的TRILL网络
This document uses the terminology from [RFC6325] and [RFC7172], some of which is repeated below for convenience, along with some additional terms listed below:
本文件使用了[RFC6325]和[RFC7172]中的术语，为了方便起见，下面重复了其中一些术语，以及下面列出的一些附加术语：
Campus: The name for a network using the TRILL protocol in the same sense that a "bridged LAN" is the name for a network using bridging. In TRILL, the word "campus" has no academic implication.
校园：使用TRILL协议的网络的名称，其含义与“桥接LAN”是使用桥接的网络的名称相同。在TRILL中，“校园”一词没有学术含义。
Data Label: VLAN or FGL.
数据标签：VLAN或FGL。
ECMP: Equal-Cost Multipath [RFC6325].
ECMP：等成本多路径[RFC6325]。
FGL: Fine-Grained Label [RFC7172].
FGL：细粒度标签[RFC7172]。
Interested Labels sub-TLV: Short for "Interested Labels and Spanning Tree Roots sub-TLV" [RFC7176].
感兴趣标签子TLV：简称“感兴趣标签和生成树根子TLV”[RFC7176]。
Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning Tree Roots sub-TLV" [RFC7176].
感兴趣的VLAN子TLV：缩写为“感兴趣的VLAN和生成树根子TLV”[RFC7176]。
IPTV: "Television" (video) over IP.
IPTV：“通过IP的电视”（视频）。
RBridge: An alternative name for a TRILL switch.
RBridge：颤音开关的另一个名称。
RPF: Reverse Path Forwarding.
反向路径转发。
TRILL: Transparent Interconnection of Lots of Links (or Tunneled Routing in the Link Layer).
TRILL：大量链路的透明互连（或链路层中的隧道路由）。
TRILL switch: A device implementing the TRILL protocol. Sometimes called an RBridge.
颤音开关：实现颤音协议的设备。有时被称为RBridge。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In the structure of Figure 1, if we choose to put the tree roots at RB1 and RB2, the ingress RBridge (e.g., RB11) would find more than one equal-cost closest tree root (i.e., RB1 and RB2). An ingress RBridge has two options to select the tree root for multi-destination frames: choose one and only one as the distribution tree root, or use an ECMP-like algorithm to balance the traffic among the multiple trees whose roots are at the same distance from the RBridge.
在图1的结构中，如果我们选择将树根放在RB1和RB2，则入口RBridge（例如RB11）将找到多个相同成本的最近树根（即RB1和RB2）。入口RBridge有两个选项来选择多目标帧的树根：选择一个且仅选择一个作为分发树根，或者使用类似ECMP的算法来平衡根与RBridge距离相同的多棵树之间的流量。
- For the former (one distribution tree root), a single tree used by each ingress RBridge can have the problem of uneven or inefficient link usage. For example, if RB11 chooses the tree that is rooted at RB1 as the distribution tree, the link between RB11 and RB2 will not be used for multi-destination frames ingressed by RB11.
- 对于前者（一个分布树根），每个入口RBridge使用的单个树可能存在链路使用不均匀或低效的问题。例如，如果RB11选择以RB1为根的树作为分发树，则RB11和RB2之间的链路将不用于RB11进入的多目的地帧。
- For the latter (an ECMP-like algorithm), ECMP-based tree selection results in a linear increase in multicast forwarding table size with the number of trees, as explained in the next paragraph.
- 对于后者（类似于ECMP的算法），基于ECMP的树选择会导致多播转发表的大小随着树的数量线性增加，如下一段所述。
A multicast forwarding table at an RBridge is normally used to map the key of (distribution tree nickname + VLAN) to an index to a list of ports for multicast packet replication. The key used for mapping is simply the tree nickname when the RBridge does not prune the tree.
RBridge上的多播转发表通常用于将（分发树昵称+VLAN）的密钥映射到多播数据包复制端口列表的索引。当RBridge不修剪树时，用于映射的键只是树昵称。
The key could be the distribution tree nickname augmented by the FGL and/or Layer 2 or 3 multicast address when the RBridge supports FGL and/or Layer 2 or 3 pruning information.
当RBridge支持FGL和/或第2层或第3层剪枝信息时，密钥可以是由FGL和/或第2层或第3层多播地址扩充的分发树昵称。
For any RBridge RBn, for each VLAN x, if RBn is in a distribution tree t used by traffic in VLAN x, there will be an entry of (t, x, port list) in the multicast forwarding table on RBn. Typically, each entry contains a distinct combination of (tree nickname, VLAN) as the lookup key. If there are n such trees and m such VLANs, the multicast forwarding table size on RBn is n*m entries. If an FGL is used [RFC7172] and/or finer pruning is used (for example, VLAN + multicast group address is used for pruning), the value of m increases. In the larger-scale data center, more trees would be necessary for purposes of better load-balancing; this results in an increased value for n. In either case, the number of table entries (i.e., n*m) will increase dramatically.
对于任何RBridge RBn，对于每个VLAN x，如果RBn位于VLAN x中的流量使用的分发树t中，则RBn上的多播转发表中将有一个条目（t，x，端口列表）。通常，每个条目都包含一个不同的（树昵称，VLAN）组合作为查找键。如果有n个这样的树和m个这样的VLAN，则RBn上的多播转发表大小为n*m个条目。如果使用FGL[RFC7172]和/或使用更精细的修剪（例如，使用VLAN+多播组地址进行修剪），m的值将增加。在更大规模的数据中心中，为了更好地平衡负载，需要更多的树；这导致n的值增加。在任何一种情况下，表条目的数量（即n*m）都将显著增加。
The left-hand table in Figure 2 shows an example of the multicast forwarding table on RB11 in the Figure 1 topology, with two distribution trees in a campus using typical fast-path hardware.
图2中的左表显示了图1拓扑中RB11上的多播转发表的示例，其中校园中有两个分布树，使用典型的快速路径硬件。
Before VLAN-Based After VLAN-Based
Tree Selection Tree Selection
+--------------+-----+---------+ +--------------+-----+---------+
|tree nickname |VLAN |port list| |tree nickname |VLAN |port list|
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 1 | | | tree 1 | 1 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 2 | | | tree 1 | 2 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 1999| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 2000| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4093| | | tree 2 | 2001| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4094| | | tree 2 | 2002| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 1 | | | tree 2 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 2 | | | tree 2 | 4093| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | | | tree 2 | 4094| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | 4093| |
+--------------+-----+---------+
| tree 2 | 4094| |
+--------------+-----+---------+
Before VLAN-Based After VLAN-Based
Tree Selection Tree Selection
+--------------+-----+---------+ +--------------+-----+---------+
|tree nickname |VLAN |port list| |tree nickname |VLAN |port list|
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 1 | | | tree 1 | 1 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 2 | | | tree 1 | 2 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 1999| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 2000| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4093| | | tree 2 | 2001| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4094| | | tree 2 | 2002| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 1 | | | tree 2 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 2 | | | tree 2 | 4093| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | | | tree 2 | 4094| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | 4093| |
+--------------+-----+---------+
| tree 2 | 4094| |
+--------------+-----+---------+
Figure 2: Multicast Forwarding Table before and after Using VLAN-Based Tree Selection
图2：使用基于VLAN的树选择前后的多播转发表
The number of entries is approximately 2*4K in this case. If four distribution trees are used in a TRILL campus and RBn has 4K VLANs with downstream receivers, it consumes 16K table entries. The size of fast-path TRILL multicast forwarding tables is typically limited by hardware; therefore, the table entries are a precious resource.
在这种情况下，条目的数量大约为2*4K。如果在TRILL校园中使用四个分发树，并且RBn具有4K VLAN和下游接收器，那么它将消耗16K表项。快速路径TRILL多播转发表的大小通常受到硬件的限制；因此，表条目是宝贵的资源。
In some implementations, the table is shared with Layer 3 IP multicast for a total of 16K or 8K table entries. Therefore, we want to reduce the table size consumed for TRILL distribution trees as much as possible and at the same time maintain load-balancing among the trees.
在某些实现中，该表与第3层IP多播共享，共有16K或8K个表项。因此，我们希望尽可能减少TRILL分布树消耗的表大小，同时保持树之间的负载平衡。
In cases where blocks of consecutive VLANs or FGLs can be assigned to a tree, the multicast forwarding table could be greatly compressed if entries could have a Data Label value and mask, with the fast-path hardware doing the longest prefix matching. But few, if any, fast-path implementations provide such logic.
在连续VLAN或FGL块可以分配给树的情况下，如果条目可以具有数据标签值和掩码，则多播转发表可以大大压缩，快速路径硬件进行最长前缀匹配。但是很少有（如果有的话）快速路径实现提供这样的逻辑。
A straightforward way to alleviate the problem of limited table entries is not to prune the distribution tree. However, this can only be used in restricted scenarios, for the following reasons:
缓解有限表项问题的一种简单方法是不修剪分布树。但是，由于以下原因，这只能在受限场景中使用：
- Not pruning wastes bandwidth for multi-destination packets. There is normally broadcast traffic, like ARP and unknown unicast, that can be pruned on a VLAN (or FGL) so that it is not sent down branches of a distribution tree where it is not needed. In addition, if there is a lot of Layer 3 multicast traffic, no pruning may result in a worst-case scenario where that user data is unnecessarily flooded all over the campus. The volume of flooded data could be very large if certain applications such as IPTV are supported. More precise pruning, such as pruning based on multicast groups, may be desirable in this case.
- 不修剪会浪费多目标数据包的带宽。通常有广播流量，如ARP和未知单播，可以在VLAN（或FGL）上进行修剪，以便不在不需要的分发树分支下发送。此外，如果存在大量第3层多播流量，则任何修剪都可能导致最坏情况，即用户数据不必要地充斥整个校园。如果支持某些应用程序（如IPTV），淹没的数据量可能非常大。在这种情况下，可能需要更精确的修剪，例如基于多播组的修剪。
- Not pruning is only useful at pure transit nodes. Edge nodes always need to maintain the multicast forwarding table with the key of (tree nickname + VLAN (or FGL)), since the edge node needs to decide whether and how to replicate the frame to local access ports. It is likely that edge nodes are relatively low-end switches with a smaller shared table size, say 4K, available.
- “不修剪”仅在纯传输节点上有用。边缘节点始终需要使用（树昵称+VLAN（或FGL））键维护多播转发表，因为边缘节点需要决定是否以及如何将帧复制到本地访问端口。边缘节点可能是具有较小共享表大小（例如4K）的相对低端交换机。
- Due to security concerns, VLAN-based (or FGL-based) traffic isolation is a basic requirement in some scenarios. No pruning may increase the risk of leakage of the traffic. Misbehaving RBridges may take advantage of this leakage of traffic.
- 出于安全考虑，在某些场景中，基于VLAN（或基于FGL）的流量隔离是一项基本要求。不修剪可能会增加流量泄漏的风险。行为不端的RBridge可能会利用这种流量泄漏。
In addition to the concern regarding multicast table size, some silicon does not currently support hashing-based tree nickname selection at the ingress RBridge but commonly uses VLAN-based tree selection. If the control plane of the ingress RBridge maps the incoming VLAN x to a tree nickname t, the data plane will always use tree t for VLAN x multi-destination frames. Such an ingress RBridge may choose multiple trees to be used for load-sharing; it can use one and only one tree for each VLAN. If we make sure that all ingress
除了对多播表大小的关注之外，一些硅片目前不支持入口RBridge处基于哈希的树昵称选择，但通常使用基于VLAN的树选择。如果入口RBridge的控制平面将传入VLAN x映射到树昵称t，则数据平面将始终使用树t来表示VLAN x多目标帧。这样的入口RBridge可以选择多个树来用于负载共享；对于每个VLAN，它只能使用一个树。如果我们确保所有入口
RBridges campus-wide send VLAN x multi-destination packets only use tree t, then there would be no need to store the multicast table entry with the key of (tree-other-than-t, x) on any RBridge.
RBridges校园范围内发送VLAN x多目标数据包只使用树t，那么就不需要在任何RBridge上存储密钥为（tree-other-than-t，x）的多播表条目。
This document describes the TRILL control-plane support for distribution tree selection based on a VLAN, FGL, and/or multicast address to reduce the multicast forwarding table size. It is compatible with the silicon implementations mentioned in the previous paragraph.
本文档描述了TRILL控制平面对基于VLAN、FGL和/或多播地址的分发树选择的支持，以减少多播转发表的大小。它与前面提到的硅实现兼容。
Data Label (VLAN-based or FGL-based) tree selection can be used as a distribution tree selection mechanism, especially when the multicast forwarding table size is a concern. This section specifies that mechanism and how to extend it so that tree selection can be based on multicast groups.
数据标签（基于VLAN或基于FGL）树选择可以用作分发树选择机制，特别是在关注多播转发表大小时。本节指定该机制以及如何扩展该机制，以便可以基于多播组选择树。
The RBridge that has the highest priority to be a tree root announces the tree nicknames and the Data Labels allowed on each tree. Such announcements of correspondence of tree to Data Label can be based on static configuration or some predefined algorithm beyond the scope of this document. An ingress RBridge selects the tree-VLAN correspondence that it wishes to use from the list announced by the highest-priority tree root. It SHOULD NOT transmit VLAN x frames on tree y if the highest-priority tree root does not say that VLAN x is allowed on tree y.
作为树根具有最高优先级的RBridge将宣布每个树上允许的树昵称和数据标签。这种树与数据标签对应关系的声明可以基于静态配置或一些超出本文档范围的预定义算法。入口RBridge从最高优先级树根宣布的列表中选择它希望使用的树VLAN对应。如果最高优先级的树根未表示允许VLAN x在树y上，则不应在树y上传输VLAN x帧。
If we make sure that a particular VLAN is allowed on one and only one tree, we can keep the number of multicast forwarding table entries on any RBridge fixed at 4K maximum (or up to 16M in the case of an FGL). Take Figure 1 as an example, where two trees are rooted at RB1 and RB2, respectively. The highest-priority tree root appoints tree 1 to carry VLAN 1-2000 and tree 2 to carry VLAN 2001-4094. With such an announcement by the highest-priority tree root, every RBridge that understands the announcement will not send VLAN 2001-4094 traffic on tree 1 and will not send VLAN 1-2000 traffic on tree 2. That way, no RBridge would need to store the entries for tree 1 / VLAN 2001-4094 or tree 2 / VLAN 1-2000. Figure 2 shows the multicast forwarding table on an RBridge before and after we use VLAN-based tree selection. The number of entries is reduced by a factor f, where f is the number of trees used in the campus. In this example, it is reduced from 2*4094 to 4094. This affects both transit nodes and edge nodes. The data-plane encoding does not change.
如果我们确保在一棵树上且仅在一棵树上允许一个特定的VLAN，那么我们可以将任何RBridge上的多播转发表条目的数量固定为4K最大值（如果是FGL，则最多为16M）。以图1为例，其中两棵树分别扎根于RB1和RB2。最高优先级树根指定树1承载VLAN 1-2000，树2承载VLAN 2001-4094。通过最高优先级树根的这种通知，每个理解该通知的RBridge将不会在树1上发送VLAN 2001-4094流量，也不会在树2上发送VLAN 1-2000流量。这样，RBridge就不需要存储树1/VLAN 2001-4094或树2/VLAN 1-2000的条目。图2显示了使用基于VLAN的树选择前后RBridge上的多播转发表。条目的数量减少了一个因子f，其中f是校园中使用的树的数量。在此示例中，它从2*4094减少到4094。这会影响过渡节点和边缘节点。数据平面编码不变。
Six new APPsub-TLVs that can be carried in the TRILL GENINFO TLV [RFC7357] in Extended Level 1 Flooding Scope (E-L1FS) FS-Link State Protocol Data Units (FS-LSPs) [RFC7780] are defined below. The first four can be considered analogous to finer-granularity versions of the TREE-RT-IDs sub-TLV and the TREE-USE-IDs sub-TLV [RFC7176]. Two APPsub-TLVs supporting VLAN-based tree selection are specified in Sections 3.2.1 and 3.2.2. They are used by the highest-priority tree root to announce the allowed VLANs on each tree in the campus and by an ingress RBridge to announce the tree-VLAN correspondence that it selects from the list announced by the highest-priority tree root. Two APPsub-TLVs supporting FGL-based tree selection are specified in Sections 3.2.3 and 3.2.4 for the same purpose. Sections 3.2.5 and 3.2.6 define two APPsub-TLVs to support finer granularity in selecting trees based on multicast groups rather than Data Labels.
下面定义了可在TRILL GENINFO TLV[RFC7357]中携带的扩展1级泛洪范围（E-L1FS）FS链路状态协议数据单元（FS LSP）[RFC7780]中的六个新APPsub TLV。前四个可以被认为类似于树RT IDs子TLV和树USE IDs子TLV的更细粒度版本[RFC7176]。第3.2.1节和第3.2.2节规定了两个支持基于VLAN的树选择的APPsub TLV。最高优先级树根使用它们来宣布校园中每个树上允许的VLAN，入口RBridge使用它们来宣布它从最高优先级树根宣布的列表中选择的树VLAN对应关系。第3.2.3节和第3.2.4节规定了两个支持基于FGL的树选择的APPsub TLV，用于相同目的。第3.2.5节和第3.2.6节定义了两个APPsub TLV，以支持基于多播组而不是数据标签选择树的更细粒度。
New APPsub-TLVs Description
======================= =============
Tree and VLANs announcement by the highest-priority
tree root of the VLANs allowed per tree
New APPsub-TLVs Description
======================= =============
Tree and VLANs announcement by the highest-priority
tree root of the VLANs allowed per tree
Tree and VLANs Used tree-VLAN correspondence that an ingress RBridge selects
树和VLAN使用入口RBridge选择的树VLAN对应
Tree and FGLs announcement by the highest-priority tree root of the FGLs allowed per tree
每个树允许的FGL的最高优先级树根发布树和FGLs
Tree and FGLs Used tree-FGL correspondence that an ingress RBridge selects
Tree和FGL使用入口RBridge选择的Tree-FGL对应关系
Tree and Groups announcement by the highest-priority tree root of the multicast groups allowed on each tree
树和组通过每个树上允许的多播组的最高优先级树根进行公告
Tree and Groups Used tree and multicast group correspondence that an ingress RBridge selects
树和组使用入口RBridge选择的树和多播组对应
The RBridge that is the highest-priority tree root announces the VLANs allowed on each tree with the Tree and VLANs (TREE-VLANs) APPsub-TLV. Multiple instances of this APPsub-TLV may be carried. The same tree nicknames may occur in multiple Tree-VLAN RECORDs within the same APPsub-TLV or across multiple APPsub-TLVs. The APPsub-TLV format is as follows:
作为最高优先级树根的RBridge将通过树和VLAN（树VLAN）APPsub TLV宣布每个树上允许的VLAN。可携带此APPsub TLV的多个实例。相同的树别名可能出现在同一APPsub TLV内或跨多个APPsub TLV的多个树VLAN记录中。APPsub TLV格式如下所示：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
where each Tree-VLAN RECORD is of the form:
其中，每个树VLAN记录的形式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TRILL GENINFO APPsub-TLV type; set to 11 (TREE-VLANs).
o 类型：TRILL GENINFO APPsub TLV类型；设置为11（树VLAN）。
o Length: 6*n bytes, where there are n Tree-VLAN RECORDs. Thus, the value of Length can be used to determine n. If Length is not a multiple of 6, the APPsub-TLV is corrupt and MUST be ignored.
o 长度：6*n字节，其中有n个树VLAN记录。因此，长度的值可用于确定n。如果长度不是6的倍数，则APPsub TLV已损坏，必须忽略。
o Nickname: The nickname identifying the distribution tree by its root.
o 昵称：通过根标识分发树的昵称。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV:4位，必须作为零发送，并在接收时忽略。
o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the allowed VLAN range on the tree, inclusive. To specify a single VLAN, the VLAN's ID appears as both the start and end VLAN. If End.VLAN is less than Start.VLAN, the Tree-VLAN RECORD MUST be ignored.
o Start.VLAN，End.VLAN：这些字段是树上允许的VLAN范围的VLAN ID，包括。要指定单个VLAN，VLAN的ID将同时显示为起始VLAN和结束VLAN。如果End.VLAN小于Start.VLAN，则必须忽略树VLAN记录。
This APPsub-TLV has the same structure as the TREE-VLANs APPsub-TLV specified in Section 3.2.1. The differences are that its APPsub-TLV type is set to 12 (TREE-VLAN-USE) and the tree-VLAN correspondences in the Tree-VLAN RECORDs listed are those correspondences that the originating RBridge wants to use for multi-destination packets. This APPsub-TLV is used by an ingress RBridge to distribute the tree-VLAN correspondence that it selects from the list announced by the highest-priority tree root.
此APPsub TLV的结构与第3.2.1节中规定的树VLAN APPsub TLV相同。不同之处在于，其APPsub TLV类型设置为12（TREE-VLAN-USE），并且列出的树VLAN记录中的树VLAN对应是发起RBridge希望用于多目标数据包的那些对应。入口RBridge使用此APPsub TLV分发它从最高优先级树根宣布的列表中选择的树VLAN对应。
The RBridge that is the highest-priority tree root can use the Tree and FGLs (TREE-FGLs) APPsub-TLV to announce the FGLs allowed on each tree. Multiple instances of this APPsub-TLV may be carried. The same tree nicknames may occur in the multiple Tree-FGL RECORDs within the same APPsub-TLV or across multiple APPsub-TLVs. Its format is as follows:
作为最高优先级树根的RBridge可以使用树和FGLs（树FGLs）APPsub TLV来宣布每个树上允许的FGLs。可携带此APPsub TLV的多个实例。相同的树昵称可能出现在同一APPsub TLV内或跨多个APPsub TLV的多个树FGL记录中。其格式如下：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (1) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (N) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (1) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (N) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
where each Tree-FGL RECORD is of the form:
其中，每个树FGL记录的形式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Start.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| End.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Start.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| End.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
o Type: TRILL GENINFO APPsub-TLV type; set to 13 (TREE-FGLs).
o 类型：TRILL GENINFO APPsub TLV类型；设置为13（树FGLs）。
o Length: 8*n bytes, where there are n Tree-FGL RECORDs. Thus, the value of Length can be used to determine n. If Length is not a multiple of 8, the APPsub-TLV is corrupt and MUST be ignored.
o 长度：8*n字节，其中有n个树FGL记录。因此，长度的值可用于确定n。如果长度不是8的倍数，则APPsub TLV已损坏，必须忽略。
o Nickname: The nickname identifying the distribution tree by its root.
o 昵称：通过根标识分发树的昵称。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV:4位，必须作为零发送，并在接收时忽略。
o Start.FGL, End.FGL: These fields are the FGL IDs of the allowed FGL range on the tree, inclusive. To specify a single FGL, the FGL's ID appears as both the start and end FGL. If End.FGL is less than Start.FGL, the Tree-FGL RECORD MUST be ignored.
o Start.FGL、End.FGL：这些字段是树上允许的FGL范围的FGL ID，包括在内。要指定单个FGL，FGL的ID将同时显示为开始和结束FGL。如果End.FGL小于Start.FGL，则必须忽略树FGL记录。
This APPsub-TLV has the same structure as the TREE-FGLs APPsub-TLV specified in Section 3.2.3. The differences are that its APPsub-TLV type is set to 14 (TREE-FGL-USE) and the Tree-FGL correspondences in the Tree-FGL RECORDs listed are those that the originating RBridge wants to use for multi-destination packets. This APPsub-TLV is used by an ingress RBridge to distribute the tree-FGL correspondence that it selects from the list announced by the highest-priority tree root.
该APPsub TLV的结构与第3.2.3节中规定的树FGLs APPsub TLV相同。不同之处在于，其APPsub TLV类型设置为14（TREE-FGL-USE），并且列出的TREE FGL记录中的TREE FGL对应关系是发起RBridge希望用于多目标数据包的对应关系。入口RBridge使用此APPsub TLV分发它从最高优先级树根宣布的列表中选择的树FGL对应。
Tree selection based on Data Labels is easily extended to tree selection based on Data Label + Layer 2 or 3 multicast groups. We can appoint multicast group 1 in VLAN 10 to tree 1 and appoint group 2 in VLAN 10 to tree 2 for better load-sharing.
基于数据标签的树选择很容易扩展到基于数据标签+第2层或第3层多播组的树选择。我们可以将VLAN 10中的多播组1指定给树1，并将VLAN 10中的组2指定给树2，以实现更好的负载共享。
The RBridge that is the highest-priority tree root can announce the multicast groups allowed on each tree for each Data Label with the Tree and Groups (TREE-GROUPs) APPsub-TLV. Multiple instances of this APPsub-TLV may be carried. The APPsub-TLV format is as follows:
作为最高优先级树根的RBridge可以通过树和组（树组）APPsub TLV为每个数据标签宣布每个树上允许的多播组。可携带此APPsub TLV的多个实例。APPsub TLV格式如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 15 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Sub-Sub-TLVs (variable)
+-+-+-+-+-+-+-+-+-+....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 15 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Sub-Sub-TLVs (variable)
+-+-+-+-+-+-+-+-+-+....
o Type: TRILL GENINFO APPsub-TLV type; set to 15 (TREE-GROUPs).
o 类型：TRILL GENINFO APPsub TLV类型；设置为15（树组）。
o Length: 2 + the length of the Group Sub-Sub TLVs that are included.
o 长度：2+包含的组子TLV的长度。
o Nickname: The nickname identifying the distribution tree by its root.
o 昵称：通过根标识分发树的昵称。
o Group Sub-Sub-TLVs: Zero or more of the TLV structures that are allowed as sub-TLVs of the Group Address (GADDR) TLV [RFC7176]. Each such TLV structure specifies a multicast group and either a VLAN or FGL. Although these TLV structures are considered sub-TLVs when they appear inside a GADDR TLV, they are technically sub-sub-TLVs when they appear inside a TREE-GROUPs APPsub-TLV that is in turn inside a TRILL GENINFO TLV [RFC7357].
o 组子TLV：允许作为组地址（GADDR）TLV的子TLV的零个或多个TLV结构[RFC7176]。每个这样的TLV结构指定一个多播组和VLAN或FGL。尽管这些TLV结构出现在GADDR TLV内时被视为子TLV，但当它们出现在树组APPsub TLV内时，它们在技术上是子TLV，而树组APPsub TLV又出现在TRILL GENINFO TLV内[RFC7357]。
The Tree and Groups Used (TREE-GROUPs-USE) APPsub-TLV has the same structure as the TREE-GROUPs APPsub-TLV specified in Section 3.2.5. The differences are that its APPsub-TLV type is set to 16 (TREE-GROUPs-USE) and the Tree Nickname and Group sub-sub-TLVs listed in this APPsub-TLV are those that the originating RBridge wants to use for multi-destination packets. This APPsub-TLV is used by an ingress RBridge to distribute the tree-group correspondence that it selects from the list announced by the highest-priority tree root.
使用的树和组（树组使用）APPsub TLV与第3.2.5节中规定的树组APPsub TLV具有相同的结构。不同之处在于，其APPsub TLV类型设置为16（树组使用），并且此APPsub TLV中列出的树昵称和组sub TLV是发起RBridge希望用于多目标数据包的树昵称和组sub TLV。入口RBridge使用此APPsub TLV分发它从最高优先级树根宣布的列表中选择的树组对应关系。
The highest-priority tree root RBridge MUST include all the necessary tree-related sub-TLVs defined in [RFC7176] as usual in its E-L1FS FS-LSP and MAY include the TREE-VLANs APPsub-TLV and/or the TREE-FGLs APPsub-TLV in its E-L1FS FS-LSP [RFC7780]. In this way, it MAY indicate that each VLAN and/or FGL is only allowed on one or some other number of trees less than the number of trees being calculated in the campus in order to save table space in the fast-path forwarding hardware.
最高优先级树根RBridge必须像往常一样在其E-L1FS FS-LSP中包括[RFC7176]中定义的所有必要的树相关子TLV，并且可能在其E-L1FS FS FS-LSP[RFC7780]中包括树VLAN APPsub TLV和/或树FGLs APPsub TLV。以这种方式，它可以指示每个VLAN和/或FGL仅允许在一个或一些其他数量的树上，这些树的数量小于校园中正在计算的树的数量，以便在快速路径转发硬件中节省表空间。
An ingress RBridge that understands the TREE-VLANs APPsub-TLV SHOULD select the tree-VLAN correspondences that it wishes to use and put them in TREE-VLAN-USE APPsub-TLVs. If there are multiple tree nicknames announced in a TREE-VLANs APPsub-TLV for VLAN x, the ingress RBridge chooses one of them if it supports this feature. For example, the ingress RBridge may choose the closest (minimum-cost) root among them. How to make such a choice is out of scope for this document. It may be desirable to have some fixed algorithm to make sure that all ingress RBridges choose the same tree for VLAN x in this case. Any single Data Label that the ingress RBridge is
理解TREE-VLAN APPsub TLV的入口RBridge应选择其希望使用的TREE-VLAN对应，并将其放入TREE-VLAN-use APPsub TLV中。如果VLAN x的树VLAN APPsub TLV中宣布了多个树昵称，入口RBridge将选择其中一个，前提是它支持此功能。例如，入口RBridge可以选择其中最近的（最小成本）根。如何做出这样的选择超出了本文档的范围。在这种情况下，可能需要有一些固定的算法来确保所有入口RBridge为VLAN x选择相同的树。入口RBridge所在的任何单个数据标签
interested in should be related to only one tree ID in a TREE-VLAN-USE APPsub-TLV to minimize the multicast forwarding table size on other RBridges, but as long as the Data Label is related to less than all the trees being calculated, it will reduce the burden on the forwarding table size.
感兴趣的应仅与tree-VLAN-USE APPsub TLV中的一个树ID相关，以最小化其他RBridge上的多播转发表大小，但只要数据标签与小于所有正在计算的树相关，它将减少转发表大小的负担。
When an ingress RBridge encapsulates a multi-destination frame for Data Label x, it SHOULD use a tree nickname that it selected previously in a TREE-VLAN-USE or TREE-FGL-USE APPsub-TLV for Data Label x. However, that may not be possible because either (1) the RBridge may not have advertised such TREE-VLAN-USE or TREE-FGL-USE APPsub-TLVs, in which case it can use any tree that has been advertised as permitted for the Data Label by the highest-priority tree root RBridge, or (2) the tree or trees it advertised might be unavailable due to failures.
当入口RBridge封装数据标签x的多目标帧时，它应该使用它以前在数据标签x的tree-VLAN-use或tree-FGL-use APPsub TLV中选择的树昵称。然而，这可能是不可能的，因为（1）RBridge可能没有公布此类TREE-VLAN-USE或TREE-FGL-USE APPsub TLV，在这种情况下，它可以使用被最高优先级树根RBridge公布为允许用于数据标签的任何树，或者（2）它公布的树可能由于故障而不可用。
If RBridge RBn does not perform pruning, it builds the multicast forwarding table as specified in [RFC6325].
如果RBridge RBn不执行修剪，它将按照[RFC6325]中的规定构建多播转发表。
If RBn prunes the distribution tree based on VLANs, RBn uses the information received in TREE-VLAN-USE APPsub-TLVs to mark the set of VLANs reachable downstream for each adjacency and for each related tree. If RBn prunes the distribution tree based on FGLs, RBn uses the information received in TRILL-FGL-USE APPsub-TLVs to mark the set of FGLs reachable downstream for each adjacency and for each related tree.
如果RBn根据VLAN修剪分发树，RBn将使用tree-VLAN-USE APPsub TLV中接收到的信息来标记每个相邻树和每个相关树下游可访问的VLAN集。如果RBn基于FGL修剪分布树，RBn将使用TRILL-FGL-USE APPsub TLV中接收到的信息来标记每个邻接和每个相关树下游可到达的FGL集。
Logically, an ingress RBridge that does not support VLAN-based or FGL-based tree selection is equivalent to the one that supports it but uses it in such a way as to gain no advantage; for example, it announces the use of all trees for all VLANs and FGLs.
从逻辑上讲，不支持基于VLAN或基于FGL的树选择的入口RBridge等同于支持它的入口RBridge，但其使用方式不会获得任何优势；例如，它宣布对所有VLAN和FGL使用所有树。
This section discusses failure scenarios for a distribution tree root for the case where that tree root is not the highest-priority root and the case where it is the highest-priority root. This section also discusses some other transient error conditions.
本节讨论分发树根不是最高优先级根以及它是最高优先级根的情况下的故障场景。本节还讨论了其他一些瞬态错误情况。
Failure of a tree root that is not the highest-priority tree root: It is the responsibility of the highest-priority tree root to inform other RBridges of any change in the allowed tree-VLAN correspondence. When the highest-priority tree root learns that the root of tree t has failed, it should reassign the VLANs allowed on tree t to other trees or to a tree replacing the failed one.
不是最高优先级树根的树根失败：最高优先级树根负责通知其他RBridge允许的树VLAN通信中的任何更改。当最高优先级的树根得知树t的根失败时，它应该将树t上允许的VLAN重新分配给其他树或替换失败树的树。
Failure of the highest-priority tree root: It is suggested that the tree root of second-highest priority be pre-configured with the proper knowledge of the tree-VLAN correspondence allowed when the highest-priority tree root fails. The information announced by the RBridge that has the second-highest priority to be a tree root would be in the link state of all RBridges but would not take effect unless the RBridge noticed the failure of the highest-priority tree root. When the highest-priority tree root fails, the tree root that formerly had second-highest priority will become the highest-priority tree root of the campus. When an RBridge notices the failure of the original highest-priority tree root, it can immediately use the stored information announced by the tree root that originally had second-highest priority. It is suggested that the tree-VLAN correspondence information be pre-configured on the tree root of second-highest priority to be the same as that on the highest-priority tree root for the trees other than the highest-priority tree itself. This can minimize the change to multicast forwarding tables in the case of highest-priority tree root failure. For a large campus, it may make sense to pre-configure this information in a similar way on the third-priority, fourth-priority, or even lower-priority tree root RBridges.
最高优先级树根故障：建议使用最高优先级树根故障时允许的树VLAN对应的适当知识预先配置第二高优先级树根。RBridge宣布的具有第二高优先级的树根的信息将处于所有RBridge的链接状态，但除非RBridge注意到最高优先级树根的故障，否则不会生效。当最高优先级的树根失败时，以前具有第二高优先级的树根将成为校园的最高优先级树根。当RBridge注意到原始最高优先级的树根出现故障时，它可以立即使用原始具有第二高优先级的树根所宣布的存储信息。建议在第二高优先级的树根上预先配置树VLAN对应信息，以便与除最高优先级树本身之外的树的最高优先级树根上的信息相同。这可以在最高优先级树根失败的情况下最小化对多播转发表的更改。对于大型校园，在第三优先级、第四优先级甚至更低优先级的树根RBridge上以类似的方式预先配置此信息可能是有意义的。
In some transient conditions, or in the case of a misbehaving highest-priority tree root, an ingress RBridge may encounter the following scenarios:
在某些瞬态条件下，或在最高优先级树根行为异常的情况下，入口RBridge可能会遇到以下情况：
- No tree has been announced for which VLAN x frames are allowed.
- 尚未宣布允许使用VLAN x帧的树。
- An ingress RBridge is supposed to transmit VLAN x frames on tree t, but the root of tree t is no longer reachable.
- 入口RBridge应该在树t上传输VLAN x帧，但树t的根不再可到达。
For the second case, an ingress RBridge may choose another reachable tree root that allows VLAN x frames according to the highest-priority tree root announcement. If there is no such tree available, then it is the same as the first case above. The ingress RBridge should then be "downgraded" to a conventional RBridge with behavior as specified in [RFC6325]. A timer should be set to allow the temporary transient stage to complete before the change of the responsive tree or the downgrade takes effect. The value of the timer should be set to at least the LSP flooding time of the campus.
对于第二种情况，入口RBridge可以根据最高优先级树根公告选择允许VLAN x帧的另一个可到达树根。如果没有这样的树可用，则与上面的第一种情况相同。然后，入口RBridge应“降级”为具有[RFC6325]中规定行为的常规RBridge。应设置计时器，以允许临时瞬态阶段在响应树更改或降级生效之前完成。计时器的值应至少设置为校园的LSP泛洪时间。
RBridges MUST include the TREE-USE-IDs and INT-VLAN sub-TLVs in their LSPs when required by [RFC6325] whether or not they support the new TREE-VLAN-USE or TREE-FGL-USE APPsub-TLVs specified by this document.
[RFC6325]要求时，RBridges必须在其LSP中包含TREE-USE ID和INT-VLAN子TLV，无论它们是否支持本文档指定的新TREE-VLAN-USE或TREE-FGL-USE APPsub TLV。
RBridges that understand the new TREE-VLAN-USE APPsub-TLV sent from another RBridge RBn should use it to build the multicast forwarding table and ignore the TREE-USE-IDs and INT-VLAN sub-TLVs sent from the same RBridge. TREE-USE-IDs and INT-VLAN sub-TLVs are still useful for some purposes other than building the multicast forwarding table (e.g., building an RPF table, spanning tree root notification). If the RBridge does not receive TREE-VLAN-USE APPsub-TLVs from RBn, it uses the conventional way described in [RFC6325] to build the multicast forwarding table.
理解从另一个RBridge RBn发送的新TREE-VLAN-USE APPsub TLV的RBridge应使用它来构建多播转发表，并忽略从同一RBridge发送的TREE-USE ID和INT-VLAN子TLV。树使用ID和INT-VLAN子TLV对于构建多播转发表（例如，构建RPF表、生成树根通知）以外的其他目的仍然有用。如果RBridge没有从RBn接收TREE-VLAN-USE APPsub TLV，它将使用[RFC6325]中描述的常规方法来构建多播转发表。
For example, there are two distribution trees, tree 1 and tree 2, in the campus. RB1 and RB2 are RBridges that use the new APPsub-TLVs described in this document. RB3 is an old RBridge that is compatible with [RFC6325]. Assume that RB2 is interested in VLANs 10 and 11 and RB3 is interested in VLANs 100 and 101. Hence, RB1 receives ((tree 1, VLAN 10), (tree 2, VLAN 11)) as a TREE-VLAN-USE APPsub-TLV and (tree 1, tree 2) as a TREE-USE-IDs sub-TLV from RB2 on port x. Also, RB1 receives (tree 1) as a TREE-USE-IDs sub-TLV and no TREE-VLAN-USE APPsub-TLV from RB3 on port y. RB2 and RB3 announce their interested VLANs in an INT-VLAN sub-TLV as usual. RB1 will then build the entry of (tree 1, VLAN 10, port x) and (tree 2, VLAN 11, port x) based on RB2's LSP and the mechanism specified in this document. RB1 also builds entries of (tree 1, VLAN 100, port y), (tree 1, VLAN 101, port y), (tree 2, VLAN 100, port y), and (tree 2, VLAN 101, port y) based on RB3's LSP in the conventional way.
例如，校园中有两棵分布树，树1和树2。RB1和RB2是使用本文档中描述的新APPsub TLV的RBridge。RB3是与[RFC6325]兼容的旧RBridge。假设RB2对VLAN 10和11感兴趣，RB3对VLAN 100和101感兴趣。因此，RB1从端口x上的RB2接收（（树1，VLAN 10），（树2，VLAN 11））作为树-VLAN-USE APPsub TLV和（树1，树2）作为树-USE IDs子TLV。此外，RB1从端口y上的RB3接收（树1）作为树使用IDs子TLV和非树-VLAN-USE APPsub TLV。和往常一样，RB2和RB3在INT-VLAN子TLV中宣布它们感兴趣的VLAN。然后，RB1将基于RB2的LSP和本文档中指定的机制构建（树1，VLAN 10，端口x）和（树2，VLAN 11，端口x）的条目。RB1还以常规方式基于RB3的LSP构建（树1，VLAN 100，端口y）、（树1，VLAN 101，端口y）、（树2，VLAN 100，端口y）和（树2，VLAN 101，端口y）的条目。
The multicast forwarding table on RB1 with a merged entry would be like the following:
RB1上具有合并项的多播转发表如下所示：
+--------------+-----+---------+
|tree nickname |VLAN |port list|
+--------------+-----+---------+
| tree 1 | 10 | x |
+--------------+-----+---------+
| tree 1 | 100 | y |
+--------------+-----+---------+
| tree 1 | 101 | y |
+--------------+-----+---------+
| tree 2 | 11 | x |
+--------------+-----+---------+
| tree 2 | 100 | y |
+--------------+-----+---------+
| tree 2 | 101 | y |
+--------------+-----+---------+
+--------------+-----+---------+
|tree nickname |VLAN |port list|
+--------------+-----+---------+
| tree 1 | 10 | x |
+--------------+-----+---------+
| tree 1 | 100 | y |
+--------------+-----+---------+
| tree 1 | 101 | y |
+--------------+-----+---------+
| tree 2 | 11 | x |
+--------------+-----+---------+
| tree 2 | 100 | y |
+--------------+-----+---------+
| tree 2 | 101 | y |
+--------------+-----+---------+
As expected, that table is not as small as the one where every RBridge supports the new TREE-VLAN-USE APPsub-TLVs. In a hybrid campus, the worst case would be where the number of entries is equal to the number of entries required by the current practice that does not support VLAN-based tree selection. Such an extreme case happens when the set of interested VLANs from the new RBridges is a subset of the set of interested VLANs from the old RBridges.
正如所料，该表并不像每个RBridge都支持新的TREE-VLAN-USE APPsub TLV的表那样小。在混合校园中，最坏的情况是条目数等于当前做法（不支持基于VLAN的树选择）所需的条目数。当来自新RBridges的感兴趣VLAN集是来自旧RBridges的感兴趣VLAN集的子集时，就会发生这种极端情况。
Tree selection based on the Data Label and multicast group is compatible with the current practice. Its effectiveness increases with more RBridges supporting this feature in the TRILL campus.
基于数据标签和多播组的树选择与当前实践兼容。随着TRILL校园中支持此功能的RBridge越来越多，其有效性也随之提高。
This document does not change the general RBridge security considerations of the TRILL base protocol. The APPsub-TLVs specified can be secured using the IS-IS authentication feature [RFC5310]. See Section 6 of [RFC6325] for general TRILL security considerations.
本文件不改变TRILL基本协议的一般RBridge安全注意事项。可以使用IS-IS身份验证功能[RFC5310]保护指定的APPsub TLV。参见[RFC6325]第6节了解一般TRILL安全注意事项。
IANA has assigned six new TRILL APPsub-TLV types from the range less than 255, as specified in Section 3, and updated the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on <http://www.iana.org/assignments/trill-parameters/>, as shown below.
IANA根据第3节的规定，从小于255的范围内分配了六种新的TRILL APPsub TLV类型，并更新了上的“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表<http://www.iana.org/assignments/trill-parameters/>，如下所示。
Type Name of APPsub-TLV Reference
---- ----------------------- -------------------------
11 Tree and VLANs Section 3.2.1 of RFC 7968
12 Tree and VLANs Used Section 3.2.2 of RFC 7968
13 Tree and FGLs Section 3.2.3 of RFC 7968
14 Tree and FGLs Used Section 3.2.4 of RFC 7968
15 Tree and Groups Section 3.2.5 of RFC 7968
16 Tree and Groups Used Section 3.2.6 of RFC 7968
Type Name of APPsub-TLV Reference
---- ----------------------- -------------------------
11 Tree and VLANs Section 3.2.1 of RFC 7968
12 Tree and VLANs Used Section 3.2.2 of RFC 7968
13 Tree and FGLs Section 3.2.3 of RFC 7968
14 Tree and FGLs Used Section 3.2.4 of RFC 7968
15 Tree and Groups Section 3.2.5 of RFC 7968
16 Tree and Groups Used Section 3.2.6 of RFC 7968
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<http://www.rfc-editor.org/info/rfc6325>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<http://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<http://www.rfc-editor.org/info/rfc7780>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 5310，DOI 10.17487/RFC5310，2009年2月<http://www.rfc-editor.org/info/rfc5310>.
Acknowledgments
致谢
The authors wish to thank David M. Bond, Liangliang Ma, Naveen Nimmu, Radia Perlman, Rakesh Kumar, Robert Sparks, Daniele Ceccarelli, and Sunny Rajagopalan for their valuable comments and contributions.
作者要感谢David M.Bond、马良良、纳文·尼姆、拉迪亚·帕尔曼、拉凯什·库马尔、罗伯特·斯帕克斯、丹尼尔·塞卡雷利和桑尼·拉贾戈帕兰的宝贵评论和贡献。
Authors' Addresses
作者地址
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
宜州利华为技术有限公司软件大道101号南京210012
Phone: +86-25-56624629
Email: liyizhou@huawei.com
Phone: +86-25-56624629
Email: liyizhou@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
Weiguo Hao Huawei Technologies 101 Software Avenue Nanjing 210012 China
中国南京软件大道101号华为技术有限公司，邮编：210012
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Hao Chen Huawei Technologies 101 Software Avenue Nanjing 210012 China
中国南京软件大道101号华为技术有限公司，邮编：210012
Email: philips.chenhao@huawei.com
Email: philips.chenhao@huawei.com
Somnath Chatterjee Cisco Systems SEZ Unit, Cessna Business Park Outer Ring Road Bangalore 560087 India
印度班加罗尔塞斯纳商业园外环路Somnath Chatterjee Cisco Systems SEZ部门560087
Email: somnath.chatterjee01@gmail.com
Email: somnath.chatterjee01@gmail.com