Internet Engineering Task Force (IETF) W. Hao
Request for Comments: 8361 Y. Li
Updates: 6325 Huawei Technologies
Category: Standards Track M. Durrani
ISSN: 2070-1721 Equinix
S. Gupta
IP Infusion
A. Qu
MediaTec
April 2018
Internet Engineering Task Force (IETF) W. Hao
Request for Comments: 8361 Y. Li
Updates: 6325 Huawei Technologies
Category: Standards Track M. Durrani
ISSN: 2070-1721 Equinix
S. Gupta
IP Infusion
A. Qu
MediaTec
April 2018
Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic
大量链路的透明互连（TRILL）：针对主动-主动广播、未知单播和多播（BUM）流量的集中复制
Abstract
摘要
In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325). To avoid RPF check failure on an RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325.
在多链路透明互连（TRILL）主动访问中，当使用RFC 7781中指定的伪昵称机制时，可能会出现反向路径转发（RPF）检查失败问题。本文档介绍了通过集中复制解决此RPF检查失败问题的解决方案。所有入口路由桥（RBridge）通过单播颤音封装将广播、未知单播和多播（BUM）流量发送到集中节点。当集中式节点接收到BUM流量时，它使用根据TRILL基本协议（RFC 6325）建立的分发树来解除分组的封装并将其转发到其目的地rbridge。为了避免位于入口RBridge和集中式复制节点之间的RBridge上的RPF检查失败，需要对RPF计算算法进行一些更改。每个RBridge上的RPF检查必须像集中式节点是入口RBridge一样进行计算，而不是使用实际入口RBridge进行计算。本文档更新了RFC 6325。
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/rfc8361.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8361.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Centralized Replication Solution Overview .......................4
4. Frame Duplication from Remote RBridge ...........................6
5. Local Forwarding Behavior on Ingress RBridge ....................6
6. Loop Prevention among RBridges in an Edge Group .................8
7. Centralized Replication Forwarding Process ......................9
8. BUM Traffic Load-Balancing among Multiple Centralized Nodes ....10
9. Coexisting with the CMT Solution (RFC 7783) ....................11
10. Network Upgrade Analysis ......................................12
11. TRILL Protocol Extensions .....................................13
11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV ........13
12. Security Considerations .......................................14
13. IANA Considerations ...........................................14
14. References ....................................................15
14.1. Normative References .....................................15
14.2. Informative References ...................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................17
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Centralized Replication Solution Overview .......................4
4. Frame Duplication from Remote RBridge ...........................6
5. Local Forwarding Behavior on Ingress RBridge ....................6
6. Loop Prevention among RBridges in an Edge Group .................8
7. Centralized Replication Forwarding Process ......................9
8. BUM Traffic Load-Balancing among Multiple Centralized Nodes ....10
9. Coexisting with the CMT Solution (RFC 7783) ....................11
10. Network Upgrade Analysis ......................................12
11. TRILL Protocol Extensions .....................................13
11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV ........13
12. Security Considerations .......................................14
13. IANA Considerations ...........................................14
14. References ....................................................15
14.1. Normative References .....................................15
14.2. Informative References ...................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................17
The IETF TRILL protocol [RFC6325] provides multipath data forwarding that is loop free and per-hop based with minimum configuration. TRILL uses IS-IS [RFC6165] [RFC7176] as its control plane routing protocol and defines a TRILL-specific header for user data.
IETF TRILL协议[RFC6325]提供无环路、基于每跳的多路径数据转发，且配置最少。TRILL使用IS-IS[RFC6165][RFC7176]作为其控制平面路由协议，并为用户数据定义特定于TRILL的报头。
Customer Equipment (CE) devices can be multihomed to a set of edge RBridges forming an edge group where active-active service can be provided. In that case, all of the uplinks from a CE are handled via a Local Active-Active Link Protocol (LAALP) [RFC7379] such as Multi-
客户设备（CE）设备可以多址到形成可以提供主动服务的边缘组的一组边缘rbridge。在这种情况下，来自CE的所有上行链路都是通过本地主动链路协议（LAALP）[RFC7379]处理的，例如多链路-
Chassis Link Aggregation (MC-LAG) or Distributed Resilient Network Interconnect (DRNI) [IEEE802.1AX]. An active-active flow-based load-sharing mechanism can achieve better load-balancing and high reliability. A CE device can be a Layer 3 (L3) end system by itself or a bridge switch through which L3 end systems access the TRILL campus.
机箱链路聚合（MC-LAG）或分布式弹性网络互连（DRNI）[IEEE802.1AX]。基于主动流的负载共享机制可以实现更好的负载平衡和高可靠性。CE设备本身可以是第3层（L3）端系统，也可以是三层端系统访问TRILL园区的桥接交换机。
In active-active access, the pseudo-nickname solution in [RFC7781] can be used to avoid Media Access Control (MAC) flip-flop on remote RBridges. The basic idea is to use a virtual RBridge (RBv) with a single pseudo-nickname to represent an edge group. Any member RBridge of that edge group uses this pseudo-nickname rather than its own nickname as the ingress nickname when it injects TRILL data frames to the TRILL campus. The use of the nickname solves the address flip-flop issue by setting the nickname learned by a remote RBridge to be the pseudo-nickname. However, it introduces another issue of incorrect packet dropping as follows: When a pseudo-nickname is used by an edge RBridge as the ingress nickname to forward BUM traffic, any RBridges (RBn) sitting between the ingress RBridge and the distribution tree root will treat the traffic as if it were ingressed from the RBv. If the same distribution tree is used by different edge RBridges of the same RBv, the traffic may arrive at some RBn from different ports. Then, the Reverse Path Forwarding (RPF) check required by TRILL [RFC6325] fails, and the BUM traffic received on unexpected ports will be dropped by RBn.
在主动-主动访问中，[RFC7781]中的伪昵称解决方案可用于避免远程RBridge上的媒体访问控制（MAC）触发器。其基本思想是使用具有单个伪昵称的虚拟RBv（RBv）来表示边组。该边缘组的任何成员RBridge在向TRILL园区注入TRILL数据帧时，都使用此伪昵称而不是其自己的昵称作为入口昵称。通过将远程RBridge学习的昵称设置为伪昵称，昵称的使用解决了地址触发器问题。然而，它引入了另一个不正确的数据包丢弃问题，如下所示：当边缘RBridge使用伪昵称作为入口昵称转发BUM流量时，位于入口RBridge和分发树根之间的任何RBridge（RBn）将视流量为从RBv进入。如果同一RBv的不同边缘RBR使用同一分布树，则流量可能从不同端口到达某些RBn。然后，TRILL[RFC6325]所需的反向路径转发（RPF）检查失败，RBn将丢弃在意外端口上接收的BUM流量。
This document specifies a centralized replication solution for BUM traffic forwarding to resolve the issue of incorrect packet drop caused by the RPF check failure in the virtual RBridge case. The basic idea is that all ingress RBridges send BUM traffic to a centralized node, which MUST be a distribution tree root, using unicast TRILL encapsulation. When the centralized node receives the packets, it decapsulates and forwards them to their destination RBridges using a distribution tree established as per the TRILL base protocol. This document updates [RFC6325]; per [RFC6325], multi-destination traffic is ingressed to a multi-destination TRILL data packet. However, per this document, when using the centralized replication feature, multi-destination traffic is initially ingressed to a unicast TRILL data packet.
本文档指定了用于BUM流量转发的集中式复制解决方案，以解决虚拟RBridge案例中RPF检查失败导致的错误数据包丢弃问题。基本思想是，所有入口RBridge使用单播TRILL封装将BUM流量发送到集中节点，该节点必须是分发树根。当集中式节点接收到数据包时，它使用根据TRILL基本协议建立的分发树将数据包解封并转发到其目的地RBridge。本文件更新了[RFC6325]；根据[RFC6325]，多目的地流量进入多目的地TRILL数据包。但是，根据本文档，当使用集中式复制功能时，多目标流量最初会进入单播TRILL数据包。
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]所述进行解释。
The abbreviations and terminology in [RFC6325] are used herein with the following additions:
此处使用[RFC6325]中的缩写和术语，并添加以下内容：
BUM: Broadcast, Unknown unicast, and Multicast
BUM：广播、未知单播和多播
CE: Customer Equipment (as in [RFC7783]), as relates to a device (end station or bridge). The device can be either physical or virtual equipment.
CE：与设备（终端站或网桥）相关的客户设备（如[RFC7783]）。设备可以是物理设备，也可以是虚拟设备。
Data Label: VLAN or Fine-Grained Labeled (FGL) [RFC7172]
数据标签：VLAN或细粒度标签（FGL）[RFC7172]
DF: Designated Forwarder [RFC7781]
DF：指定货运代理[RFC7781]
FGL: Fine-Grained Label [RFC7172]
FGL：细粒度标签[RFC7172]
LAALP: Local Active-Active Link Protocol [RFC7379]
LAALP：本地主动链路协议[RFC7379]
MAC flip flop: A problem where the attachment point of a MAC address appears to a remote switch to keep changing. See Section 3.3 of [RFC7379].
MAC触发器：MAC地址的连接点出现在远程交换机上以保持变化的问题。见[RFC7379]第3.3节。
MC-LAG: Multi-Chassis Link Aggregation
MC-LAG：多机箱链路聚合
RPF: Reverse Path Forwarding
反向路径转发
When an edge RBridge receives BUM traffic from a CE device, it uses unicast TRILL encapsulation instead of multicast encapsulation to send the packets to a centralized node. The centralized node MUST be a distribution tree root. Distribution tree roots are normally chosen to be high-capacity core RBridges with many high-bandwidth adjacencies. This constraint makes it practical, as described below, to support centralized replication with only software changes to transit RBridges.
当边缘RBridge从CE设备接收BUM流量时，它使用单播TRILL封装而不是多播封装将数据包发送到集中节点。集中式节点必须是分发树根。分布树根通常被选择为具有许多高带宽邻接的高容量核心RBridge。如下文所述，这种限制使得支持集中复制变得切实可行，只需对传输数据进行软件更改。
The TRILL header of the unicast TRILL encapsulation contains an "ingress RBridge nickname" field and an "egress RBridge nickname" field [RFC6325]. If the ingress RBridge receives the BUM packet from a port that is in an active-active edge group using [RFC7781], it sets the ingress RBridge nickname to be the pseudo-nickname rather than its own nickname to avoid MAC flip-flop (see Section 3.3 of [RFC7379]) on remote RBridges. The egress RBridge nickname is set to a special nickname of the centralized node that is used to differentiate the centralized replication purpose unicast TRILL encapsulation from a normal unicast TRILL encapsulation. This special nickname is called an "R-nickname".
单播TRILL封装的TRILL报头包含“入口RBridge昵称”字段和“出口RBridge昵称”字段[RFC6325]。如果ingress RBridge使用[RFC7781]从活动边缘组中的端口接收BUM数据包，它会将ingress RBridge昵称设置为伪昵称，而不是其自己的昵称，以避免远程RBridge上的MAC触发器（参见[RFC7379]第3.3节）。出口RBridge昵称设置为集中式节点的特殊昵称，用于区分集中式复制目的单播颤音封装与普通单播颤音封装。这个特殊的昵称叫做“R-昵称”。
When the centralized RBridge receives a unicast TRILL-encapsulated packet with its R-nickname as the egress nickname, it decapsulates the packet. Then, the centralized RBridge replicates and forwards the BUM packet to the packet's destination RBridges using one of the distribution trees established per the TRILL base protocol [RFC6325]. It MUST use a distribution tree whose tree root is the centralized RBridge itself. (An RBridge may be the root of more than one tree.) When the centralized RBridge forwards the BUM traffic, it simply sends it on the distribution tree as if it were a locally ingressed frame, except that the ingress nickname remains the same as that in the packet it received to ensure that the MAC address learning by all egress RBridges is bound to the pseudo-nickname.
当集中式RBridge接收到以其R昵称作为出口昵称的单播TRILL封装的分组时，它解除该分组的封装。然后，集中式RBridge使用根据TRILL基本协议[RFC6325]建立的分发树之一复制BUM分组并将其转发到分组的目的地RBridge。它必须使用树根为集中式RBridge本身的分发树。（一个RBridge可能是多个树的根。）当集中式RBridge转发BUM流量时，它只是将其发送到分发树上，就好像它是本地进入的帧一样，除了入口昵称与它接收到的分组中的昵称保持相同，以确保所有出口rbridge学习的MAC地址绑定到伪昵称。
When the replicated packet is forwarded by each RBridge along the distribution tree starting from the centralized node, an RPF check is performed per [RFC6325]. For any RBridge sitting between the ingress RBridge and the centralized replication node, the incoming port of such a BUM packet should be the centralized-node-facing port, as the multicast traffic always comes from the centralized node in this solution. However, the RPF port as the result of distribution tree calculation as specified in [RFC6325] will be the real ingress RBridge-facing port, as it uses the edge group's virtual RBridge as the ingress RBridge, so the RPF check will fail.
当每个RBridge从集中式节点开始沿着分发树转发复制的数据包时，根据[RFC6325]执行RPF检查。对于位于入口RBridge和集中式复制节点之间的任何RBridge，这样的BUM数据包的传入端口应该是集中式面向节点的端口，因为在本解决方案中，多播流量始终来自集中式节点。但是，[RFC6325]中指定的分发树计算结果的RPF端口将是真正的入口RBridge面向端口，因为它使用边缘组的虚拟RBridge作为入口RBridge，因此RPF检查将失败。
To solve this problem, some change in the RPF test is required. In this case, the RPF calculation on each RBridge should use the centralized node as the ingress RBridge for each tree for which that node is the root instead of the real ingress virtual RBridge to perform the calculation. As a result, the RPF check will accept traffic on the centralized-node-facing port of the RBridge for multi-destination traffic. This prevents incorrect frame drops by the RPF check.
为了解决这个问题，需要对RPF测试进行一些更改。在这种情况下，每个RBridge上的RPF计算应使用集中节点作为每个树的入口RBridge，该树的该节点是根，而不是实际入口虚拟RBridge来执行计算。因此，RPF检查将接受面向RBridge端口的集中式节点上的多目的地流量。这可防止RPF检查导致不正确的帧下降。
The change in the actual RPF check on a received multi-destination TRILL data packet is easy. The RPF check from [RFC6325] is a check to see if a triple of {ingress nickname, tree, receiving RBridge port} is allowed. (The tree is indicated by the nickname of its root, which is stored in the TRILL Header "egress nickname" field.) When determining the RPF check, if "ingress nickname" is using centralized replication (indicated by a C-nickname, see Section 9), then the check is based on distribution from the tree root. If "ingress nickname" is not using centralized replication, then the check is based on distribution from the RBridge having the ingress nickname.
对接收到的多目的地TRILL数据包的实际RPF检查的更改很容易。来自[RFC6325]的RPF检查是一种检查，以查看是否允许三重{ingress昵称，tree，receiving RBridge port}。（树由其根的昵称表示，该昵称存储在TRILL标头“出口昵称”字段中。）确定RPF检查时，如果“入口昵称”使用集中复制（由C-昵称表示，请参见第9节），则检查基于来自树根的分发。如果“入口昵称”未使用集中式复制，则检查基于具有入口昵称的RBridge的分发。
To differentiate the centralized replication unicast TRILL encapsulation from normal unicast TRILL encapsulation, the R-nickname is introduced for centralized replication. When the centralized node
为了区分集中式复制单播颤音封装与普通单播颤音封装，为集中式复制引入了R昵称。当集中式节点
receives unicast TRILL encapsulation traffic with the egress nickname R-nickname, it decapsulates the packet and then forwards the packet to the destination RBridges through a distribution tree for which it is the root by re-encapsulation as aforementioned. In TRILL, RBridges can hold multiple nicknames, so the centralized RBridge simply obtains another nickname to use as the R-nickname. The centralized RBridge or RBridges should announce their R-nickname to all TRILL campuses through the TRILL Link State PDU (LSP) extension specified in Section 11.
接收具有出口昵称R-nickname的单播TRILL封装通信量，它解除对分组的封装，然后通过分发树将分组转发到目标rbridge，如前所述，该分发树是该分组的根。在TRILL中，RBridge可以拥有多个昵称，因此集中式RBridge只需获得另一个昵称用作R-昵称。中央RBridge或RBridge应通过第11节规定的TRILL链路状态PDU（LSP）扩展向所有TRILL校园公布其R-昵称。
Frame duplication may occur when a remote host sends a multi-destination frame to a local CE that has an active-active connection to the TRILL campus. To avoid the local CE receiving multiple copies from a remote RBridge, the Designated Forwarder (DF) mechanism is supported for egress-direction multicast traffic.
当远程主机将多目标帧发送到与TRILL园区有活动连接的本地CE时，可能会发生帧复制。为了避免本地CE从远程RBridge接收多个副本，出口方向多播流量支持指定转发器（DF）机制。
The DF election mechanism [RFC7781] allows only one port of one RBridge in an active-active group to forward multicast traffic from the TRILL campus to the local access side for each VLAN. The basic idea of using DF is to elect one RBridge per VLAN from an edge group to be responsible for egressing the BUM traffic. [RFC7781] describes the DF election mechanism among member RBridges involved in an edge group.
DF选择机制[RFC7781]只允许活动组中一个RBridge的一个端口将多播流量从TRILL校园转发到每个VLAN的本地接入端。使用DF的基本思想是从边缘组中为每个VLAN选择一个RBridge来负责BUM流量的退出。[RFC7781]描述了边缘组中成员之间的DF选举机制。
If the DF election mechanism is used for frame-duplication prevention, access ports on an RBridge are categorized as one of three types: non-group, group DF port, and group non-DF port. The last two types can be called group ports. Each of the group ports is associated with a pseudo-nickname. If consistent nickname allocation to edge group RBridges is used, it is possible that the same pseudo-nickname is associated with more than one port on a single RBridge. A typical scenario is that CE1 is connected to RB1 and RB2 by LAALP1, whereas CE2 is connected to RB1 and RB2 by LAALP2. In order to conserve the number of pseudo-nicknames used, member ports for both LAALP1 and LAALP2 on RB1 and RB2 are all associated with the same pseudo-nickname.
如果DF选择机制用于防止帧复制，则RBridge上的访问端口分为三种类型之一：非组、组DF端口和组非DF端口。最后两种类型可以称为组端口。每个组端口都与一个伪昵称相关联。如果对边缘组RBridge使用一致的昵称分配，则同一伪昵称可能与单个RBridge上的多个端口关联。典型情况是CE1通过LAALP1连接到RB1和RB2，而CE2通过LAALP2连接到RB1和RB2。为了节省使用的伪昵称数量，RB1和RB2上LAALP1和LAALP2的成员端口都与相同的伪昵称相关联。
When an ingress RBridge (RB1) receives BUM traffic from a local active-active connected CE (CE1) device, the traffic will be injected into the TRILL campus with TRILL encapsulation; it will be replicated and forwarded to all destination RBridges through central replication, including the ingress RBridge itself, along a TRILL
当入口RBridge（RB1）从本地主动连接的CE（CE1）设备接收BUM流量时，该流量将通过TRILL封装注入TRILL园区；它将通过中央复制（包括入口RBridge本身）沿颤音进行复制并转发到所有目标RBridge
distribution tree. To avoid the traffic looping back to the original sender CE, an ingress nickname of the CE group's pseudo-nickname is used for traffic filtering.
分布树。为了避免流量循环回原始发送方CE，CE组的伪昵称的入口昵称用于流量过滤。
However, if there are two CEs, say CE1 and CE2, connecting to the ingress RB1 and each associated with the same pseudo-nickname, RB1 needs to locally replicate and forward to CE2, because another copy of the BUM traffic between CE1 and CE2 through the TRILL campus will be blocked by the traffic filtering.
但是，如果有两个CE（比如CE1和CE2）连接到入口RB1，并且每个CE都与相同的伪昵称关联，则RB1需要本地复制并转发到CE2，因为CE1和CE2之间通过TRILL园区的BUM流量的另一个副本将被流量过滤阻止。
If CE1 and CE2 are not associated with the same pseudo-nickname, the copy of the BUM traffic between CE1 and CE2 through the TRILL campus won't be blocked by the traffic filtering. To avoid duplicated traffic on receiver CE, there cannot be local replicated BUM traffic between these two CEs on ingress RB1.
如果CE1和CE2未与同一伪昵称关联，则CE1和CE2之间通过TRILL校园的BUM流量副本不会被流量过滤阻止。为了避免接收器CE上的复制流量，入口RB1上这两个CE之间不能存在本地复制的BUM流量。
In summary, to ensure correct BUM traffic forwarding behavior for each CE, the local replication behavior on the ingress RBridge is as follows:
总之，为确保每个CE的BUM流量转发行为正确，入口RBridge上的本地复制行为如下所示：
1. Replicate to the active-active group ports associated with the same pseudo-nickname as that associated with the incoming port.
1. 复制到与传入端口关联的伪昵称相同的活动组端口。
2. Do not replicate to active-active group ports associated with other pseudo-nicknames.
2. 不要复制到与其他伪昵称关联的活动组端口。
3. Do not replicate to non-edge-group ports.
3. 不要复制到非边缘组端口。
The above local forwarding behavior on the ingress RBridge of RB1 can be called "centralized replication local forwarding behavior A".
上述RB1入口RBridge上的本地转发行为可称为“集中式复制本地转发行为A”。
If ingress RBridge RB1 itself is the centralized replication node, BUM traffic injected by RB1 into the TRILL campus won't loop back to RB1. In this case, the local forwarding behavior is called centralized replication local forwarding behavior B. Behavior B on RB1 is as follows:
如果入口RBridge RB1本身是集中式复制节点，则RB1注入TRILL园区的BUM流量将不会循环回RB1。在这种情况下，本地转发行为称为集中式复制本地转发行为B。RB1上的行为B如下所示：
1. Local replication to the ports associated with the same pseudo-nickname as that associated with the incoming port.
1. 本地复制到与传入端口关联的伪昵称相同的端口。
2. Local replication to the group DF port associated with different pseudo-nicknames. Do not replicate to group non-DF ports associated with different pseudo-nicknames.
2. 本地复制到与不同伪昵称关联的组DF端口。不要复制到与不同伪昵称关联的非DF端口组。
3. Local replication to non-edge-group ports.
3. 本地复制到非边缘组端口。
If a CE sends a BUM packet through a DF port to an ingress RBridge, that RBridge will forward that packet to all or a subset of the other RBridges that only have non-DF ports for that active-active group. Because BUM traffic forwarding to non-DF ports isn't allowed, in this case, the frame won't loop back to the CE.
如果CE通过DF端口向入口RBridge发送BUM数据包，则该RBridge将把该数据包转发给其他RBridge的所有或子集，这些RBridge仅具有该活动组的非DF端口。因为不允许将BUM通信转发到非DF端口，所以在这种情况下，帧不会循环回CE。
If a CE sends a BUM packet through a non-DF port to an ingress RBridge, say RB1, then RB1 will forward that packet to other RBridges that have a DF port for that active-active group. In this case, the frame will loop back to the CE and the traffic split-horizon filtering mechanism is used to avoid looping back among RBridges in the edge group.
如果CE通过非DF端口向入口RBridge（如RB1）发送BUM数据包，则RB1将该数据包转发给具有该活动组DF端口的其他RBridge。在这种情况下，帧将回环到CE，并且使用业务分割地平线过滤机制来避免在边缘组中的rbridge之间回环。
This split-horizon mechanism relies on the ingress nickname field in the TRILL header to check if a packet's egress port belongs to the same active-active group as the packet's incoming port to the TRILL campus.
这种水平分割机制依赖于TRILL报头中的入口昵称字段来检查数据包的出口端口是否属于与数据包到TRILL园区的输入端口相同的活动组。
When the ingress RBridge receives BUM traffic from an active-active connected CE device, the traffic will be sent through the TRILL campus with TRILL encapsulation to a centralized RBridge. There it will be replicated and forwarded to its destination RBridges, which include the ingress RBridge itself, through a TRILL distribution tree. If the same pseudo-nickname is used for two active-active access CEs as the ingress nickname, an egress RBridge can use that nickname to filter traffic forwarding to all local CEs. In this case, the traffic between these two CEs goes through the local RBridge and another copy of the traffic from the TRILL campus is filtered. If different ingress nicknames are used for two connecting CE devices, the access ports connecting to these two CEs should be isolated from each other. The BUM traffic between these two CEs should go through the TRILL campus; otherwise, the destination CE connected to same RBridge with the sender CE will receive two copies of the traffic.
当入口RBridge从活动连接的CE设备接收BUM流量时，该流量将通过TRILL封装的TRILL园区发送到集中式RBridge。在那里，它将被复制并通过TRILL分发树转发到其目的地RBridge，其中包括入口RBridge本身。如果两个活动接入CE使用的伪昵称与入口昵称相同，则出口RBridge可以使用该昵称过滤转发到所有本地CE的流量。在这种情况下，这两个CEs之间的流量通过本地RBridge，来自TRILL校园的另一个流量副本被过滤。如果两个连接的CE设备使用不同的入口昵称，则连接到这两个CE的访问端口应彼此隔离。这两个CEs之间的流动交通应该通过TRILL校园；否则，与发送方CE连接到同一RBridge的目的地CE将接收两个通信量副本。
+-----------+
| (RB5) |
+-----------+
|
+-----------+
| (RB4) |
+-----------+
+-----------+
| (RB5) |
+-----------+
|
+-----------+
| (RB4) |
+-----------+
| | |
-------- | --------
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RB3)|
+------+ +------+ +------+
* | * | * | ^
* | * | * | ^
* ----------*-------------*-- ^
***************************** | ^
* | ^
LAALP1 * LAALP2 | ^
+------+ +------+ +------+
| CE1 | | CE2 | | CE3 |
+------+ +------+ +------+
| | |
-------- | --------
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RB3)|
+------+ +------+ +------+
* | * | * | ^
* | * | * | ^
* ----------*-------------*-- ^
***************************** | ^
* | ^
LAALP1 * LAALP2 | ^
+------+ +------+ +------+
| CE1 | | CE2 | | CE3 |
+------+ +------+ +------+
Figure 1: TRILL Active-Active Access
图1:TRILL主动访问
Note: The asterisk line, hyphen & vertical bar line, and circumflex line in this figure indicate the connection of the various CEs to the various RBs.
注：本图中的星号线、连字符和竖线以及回旋线表示各种CE与各种RBs的连接。
Assuming the centralized replication solution is used in the example network of above Figure 1: RB5 is the distribution tree root and centralized replication node; CE1 and CE2 are active-active accessed to RB1, RB2, and RB3 through LAALP1 and LAALP2, respectively; and CE3 is single-homed to RB3. The RBridge's own nicknames of RB1 to RB5 are nick1 to nick5, respectively. RB1, RB2, and RB3 use the same pseudo-nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The R-nickname on the centralized replication node of RB5 is S-nick.
假设在上图1的示例网络中使用了集中式复制解决方案：RB5是分发树根和集中式复制节点；CE1和CE2分别通过LAALP1和LAALP2主动访问RB1、RB2和RB3；CE3是RB3的单宿。RBridge自己的昵称RB1到RB5分别是nick1到nick5。RB1、RB2和RB3对LAALP1和LAALP2使用相同的伪昵称；那个假绰号是P-nick。RB5的集中式复制节点上的R昵称为S-nick。
The BUM traffic forwarding process from CE1 to CE2 and CE3 is as follows:
从CE1到CE2和CE3的BUM流量转发过程如下：
1. CE1 sends BUM traffic to RB3.
1. CE1向RB3发送BUM流量。
2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 also sends the traffic to RB5 using unicast TRILL encapsulation. In the TRILL Header, the ingress nickname is set as P-nick and the egress nickname is set as S-nick.
2. RB3在本地复制并发送BUM流量到CE2。RB2还使用单播颤音封装将流量发送到RB5。在TRILL报头中，入口昵称设置为P-nick，出口昵称设置为S-nick。
3. RB5 decapsulates the unicast TRILL data packet. Then, it uses a distribution tree for which it is the root to forward the packet as a multi-destination TRILL data packet. The egress nickname in the multi-destination TRILL Header is the nick5 and the ingress nickname is still P-nick. If RB3 had sent the unicast to some nickname that was not an R-nickname, the packet would not be re-encapsulated. If it is sent to an R-nickname that is not a tree root, it either will not be forwarded at all or, if it is re-encapsulated and forwarded, will be subject to incorrect pruning and will not be delivered to all of its intended recipients.
3. RB5解除单播颤音数据包的封装。然后，它使用作为根的分发树将数据包作为多目标TRILL数据包转发。多目的地TRILL报头中的出口昵称是nick5，而入口昵称仍然是P-nick。如果RB3将单播发送到某个不是R-昵称的昵称，则不会重新封装数据包。如果它被发送到一个不是树根的R-昵称，它或者根本不会被转发，或者，如果它被重新封装和转发，将受到不正确的修剪，并且不会被发送到所有预期的收件人。
4. RB4 receives multicast TRILL traffic from RB5. The incoming traffic port is the up port facing the distribution tree root. RB4's RPF check will be correct based on the changed RPF port calculation algorithm in this document. After the RPF check is performed, it forwards the traffic to all other egress RBridges (RB1, RB2, and RB3).
4. RB4从RB5接收多播颤音通信量。传入流量端口是面向分发树根的上行端口。根据本文档中更改的RPF端口计算算法，RB4的RPF检查将是正确的。在执行RPF检查后，它将流量转发到所有其他出口RBridge（RB1、RB2和RB3）。
5. RB3 receives multicast TRILL traffic from RB4. It decapsulates the multi-destination TRILL data packet. Because the ingress nickname of P-nick is equivalent to the nickname of local LAALPs connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 and CE2 to avoid a duplicated frame. RB3 only forwards the packet to CE3.
5. RB3从RB4接收多播颤音通信。它解除了多目的地TRILL数据包的封装。由于P-nick的入口昵称相当于连接到CE1和CE2的本地LAALPs的昵称，RB3不会将流量转发到CE1和CE2以避免重复帧。RB3仅将数据包转发给CE3。
6. RB1 and RB2 receive multicast TRILL traffic from RB4. The forwarding process is similar to the process on RB3, i.e., because the ingress nickname of P-nick is equivalent to the nickname of the local LAALPs connecting CE1 and CE2, they also don't forward the traffic to local CE1 and CE2.
6. RB1和RB2从RB4接收多播TRILL流量。转发过程类似于RB3上的过程，即，因为P-nick的入口昵称相当于连接CE1和CE2的本地LAALPs的昵称，所以它们也不会将流量转发到本地CE1和CE2。
To support unicast TRILL encapsulation BUM traffic load-balancing, multiple centralized replication nodes can be deployed and the traffic can be spread over these nodes based on data label (VLAN or FGL). Furthermore, if it was desirable for a centralized node to be
为了支持单播TRILL封装BUM流量负载平衡，可以部署多个集中式复制节点，并且流量可以基于数据标签（VLAN或FGL）分布在这些节点上。此外，如果希望使用集中式节点
sent more of this BUM traffic, it could hold two or more R-nicknames. The share of BUM traffic it would receive would be proportional to the number of R-nicknames it held.
发送了更多的垃圾流量，它可能有两个或更多的R-昵称。它将收到的BUM流量份额与它拥有的R昵称数量成正比。
Assuming there are k different R-nicknames held by centralized nodes in a TRILL campus, the VLAN-based (or FGL-based [RFC7172]) load-balancing algorithm used by an ingress active-active access RBridge is as follows:
假设TRILL园区中的集中式节点拥有k个不同的R-昵称，入口主动访问RBridge使用的基于VLAN（或基于FGL[RFC7172]）的负载平衡算法如下所示：
1. All R-nicknames are ordered and numbered from 0 to k-1 in ascending order, treating the nicknames as unsigned 16-bit integers.
1. 所有R-昵称按升序从0到k-1排序和编号，将昵称视为无符号16位整数。
2. For data label ID m, choose the R-nickname whose index is given by (m mod k) as egress nickname for BUM traffic unicast TRILL encapsulation.
2. 对于数据标签ID m，选择其索引由（m mod k）给出的R-昵称作为BUM流量单播TRILL封装的出口昵称。
For example, there are three R-Nicknames (RNs). The RNs will be ordered RN0 to RN2. Assuming there are five VLANs from VLAN ID1 to ID5 spreading among edge RBridges, the traffic in VLAN1 will go to RN1, VLAN2 will go to RN2, and so on.
例如，有三个R-昵称（RNs）。RNs将从RN0订购至RN2。假设从VLAN ID1到ID5有五个VLAN分布在边缘RBridge之间，VLAN1中的流量将流向RN1，VLAN2将流向RN2，依此类推。
When an ingress RBridge participating in an active-active connection receives BUM traffic from a local CE, the RBridge decides which R-nickname to send the traffic to based on the VLAN-based load-spreading algorithm; thus, data-label-based load-balancing for the BUM traffic can be achieved using multiple centralized nodes/multiple R-nicknames.
当参与主动-主动连接的入口RBridge从本地CE接收到BUM流量时，RBridge基于基于VLAN的负载扩展算法决定将流量发送到哪个R昵称；因此，可以使用多个集中式节点/多个R-昵称来实现针对BUM流量的基于数据标签的负载平衡。
+------+ +------+
|(RB6) | |(RB7) |
+------+ +------+
------------------|-----------|----------------------
| | | | |
+------+ +------+ +------+ +------+ +------+
|(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) |
+------+ +------+ +------+ +------+ +------+
| | | | |
------------ -------------------------
| |
+------+ +------+
| CE1 | | CE2 |
+------+ +------+
+------+ +------+
|(RB6) | |(RB7) |
+------+ +------+
------------------|-----------|----------------------
| | | | |
+------+ +------+ +------+ +------+ +------+
|(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) |
+------+ +------+ +------+ +------+ +------+
| | | | |
------------ -------------------------
| |
+------+ +------+
| CE1 | | CE2 |
+------+ +------+
Figure 2: CMT and Centralized Replication Coexisting Scenario
图2:CMT和集中式复制共存的场景
Both the centralized replication solution and the Coordinated Multicast Trees (CMT) solution from [RFC7783] rely on using pseudo-nicknames to avoid MAC flip-flop on remote RBridges. These two solutions can coexist in a single TRILL campus. Each solution can be selected by each active-active edge group of RBridges independently.
[RFC7783]的集中式复制解决方案和协调多播树（CMT）解决方案都依赖于使用伪昵称来避免远程RBridge上的MAC触发器。这两种解决方案可以在一个TRILL校园中共存。每个解决方案可由RBridges的每个活动边组独立选择。
As illustrated in Figure 2, RB1 and RB2 use CMT for CE1's active-active access; RB3, RB4, and RB5 use the centralized replication for CE2's active-active access.
如图2所示，RB1和RB2使用CMT进行CE1的主动访问；RB3、RB4和RB5将集中复制用于CE2的主动访问。
For the centralized replication solution, edge group RBridges MUST announce the local pseudo-nickname using the Nickname Flags APPsub-TLV with C flag set. A nickname with the C flag set is called a "C-nickname". A transit RBridge will perform the centralized replication-specific RPF check algorithm if it receives TRILL data packets with a C-nickname as the ingress nickname.
对于集中式复制解决方案，边缘组RBridges必须使用昵称标志APPsub TLV和C标志集宣布本地伪昵称。带有C标志集的昵称称称为“C-昵称”。如果transit RBridge接收到以C昵称作为入口昵称的TRILL数据包，它将执行集中式复制特定RPF检查算法。
An edge group using CMT [RFC7783] MUST NOT set the C flag on the pseudo-nickname it is using. This is already mandatory behavior because any RBridge originating a Nickname Flags APPsub-TLV is required by [RFC7780] to set any flag bit it does not know about to zero. If an edge RBridge using CMT [RFC7783] nevertheless set the C-bit for an edge group pseudo-nickname, it is very likely that BUM traffic encapsulated with that nickname as ingress would be incorrectly pruned early in its distribution and would, thus, reach few (possibly none) of its intended targets. To avoid confusion, a pseudo-nickname MUST NOT be shared between a centralized replication edge group and a CMT-based edge group.
使用CMT[RFC7783]的边缘组不得在其使用的伪昵称上设置C标志。这已经是强制性的行为，因为[RFC7780]要求生成昵称标志APPsub TLV的任何RBridge将其不知道的任何标志位设置为零。如果使用CMT[RFC7783]的边缘RBridge仍然为边缘组伪昵称设置了C位，则使用该昵称作为入口封装的BUM流量很可能在其分发的早期被错误地剪除，从而很少（可能没有）达到其预期目标。为避免混淆，集中式复制边缘组和基于CMT的边缘组之间不得共享伪昵称。
Centralized nodes will typically need software and hardware upgrades to support centralized replication, which stitches together the TRILL unicast traffic decapsulation process and the process of normal TRILL multicast traffic forwarding along the distribution tree.
集中式节点通常需要软件和硬件升级以支持集中式复制，集中式复制将TRILL单播通信量解除封装过程和沿分发树的正常TRILL多播通信量转发过程缝合在一起。
Active-active connection edge RBridges will typically need software and hardware upgrades to support unicast TRILL encapsulation for BUM traffic; the process is similar to other head-end replication processes.
主动-主动连接边缘RBridge通常需要软件和硬件升级，以支持BUM流量的单播颤音封装；该过程与其他前端复制过程类似。
Transit nodes typically need only a software upgrade to support the changed RPF port calculation algorithm.
中转节点通常只需要软件升级即可支持更改后的RPF端口计算算法。
Two new flags, "R" and "C", are specified in the Nickname Flags APPsub-TLV [RFC7780]. A nickname with the R flag set is called an "R-nickname" and a nickname with the C flag set is called a "C-nickname". The R-nickname is a specialized nickname attached to a centralized node to differentiate unicast TRILL-encapsulated BUM traffic from normal unicast TRILL traffic. The C-nickname flag is set on the pseudo-nickname for each edge group that uses the centralized replication. A C-nickname is a specialized pseudo-nickname for which transit RBridges perform a different RPF check algorithm for TRILL data packets with the C-nickname in the ingress nickname field.
昵称标志APPsub TLV[RFC7780]中指定了两个新标志“R”和“C”。带有R标志集的昵称称称为“R-昵称”，带有C标志集的昵称称称为“C-昵称”。R-昵称是附加到集中式节点的专用昵称，用于区分单播颤音封装的BUM流量与正常单播颤音流量。在使用集中复制的每个边缘组的伪昵称上设置C-昵称标志。C-昵称是一种专用的伪昵称，对于该昵称，transit RBridges对入口昵称字段中具有C-昵称的TRILL数据包执行不同的RPF检查算法。
When active-active edge RBridges use centralized replication to forward BUM traffic, the R-nickname is used as the egress nickname and the C-nickname is used as ingress nickname in the TRILL header for the unicast TRILL encapsulation of BUM traffic.
当活动边缘RBridge使用集中复制转发BUM流量时，R-昵称用作出口昵称，C-昵称用作TRILL报头中的入口昵称，用于BUM流量的单播TRILL封装。
If this APPsub-TLV is being advertised by an RBridge that does not have the nickname appearing in the Nickname Flags APPsub-TLV, the R and C flag bits in the APPsub-TLV MUST be treated as if they were zero. If an RBridge that is not a distribution tree root advertises an R-nickname, that nickname MUST NOT be treated as an R-nickname but rather as an ordinary nickname; that is, the R-nickname flag is ignored for all purposes if the nickname is held by an RBridge that is not a tree root.
如果此APPsub TLV由没有昵称标志APPsub TLV中显示的昵称的RBridge播发，则必须将APPsub TLV中的R和C标志位视为零。如果不是分发树根的RBridge发布R-昵称，则该昵称不得视为R-昵称，而应视为普通昵称；也就是说，如果昵称由非树根的RBridge持有，则无论出于何种目的，R-昵称标志都将被忽略。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE|R | C| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE|R | C| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD
o R = If the R flag is one, it indicates that the advertising TRILL switch holding Nickname is a centralized replication node, and Nickname is used as egress nickname for edge group RBridges to inject BUM traffic into the TRILL campus when the edge group RBridges use this centralized replication solution for active-active access. If the R flag is zero, that nickname will not be used for that purpose.
o R=如果R标志为1，则表示持有昵称的广告TRILL交换机是集中复制节点，并且昵称用作边缘组RBridges的出口昵称，以便在边缘组RBridges使用此集中复制解决方案进行主动访问时将BUM流量注入TRILL园区。如果R标志为零，则该昵称将不会用于该目的。
o C = If C flag is one, it indicates that the TRILL traffic with this nickname as an ingress nickname requires the special RPF check algorithm specified in Section 3. If the C flag is zero, that nickname will not be used for that purpose.
o C=如果C标志为1，则表示将此昵称作为入口昵称的TRILL流量需要第3节中指定的特殊RPF检查算法。如果C标志为零，则该昵称将不会用于该目的。
Due to errors or due to transient inconsistent LSPs when the link state database is converging after a configuration change or the like, it is possible for there to be inconsistent Nickname Flags APPsub-TLVs for the same nickname. In this case, it is RECOMMENDED that the nickname be treated as if the R / C flag were set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set.
由于错误或当链路状态数据库在配置更改等之后会聚时的暂时不一致lsp，可能存在用于相同昵称的不一致昵称标志APPsub tlv。在这种情况下，建议将昵称视为设置了R/C标志，如果该昵称的任何昵称标志APPsub TLV已设置R/C标志。
This document does not introduce any extra security risks. A rogue RBridge that is a tree root can attract traffic by advertising an R-nickname. However, this does not represent a substantial increase in risk as RBridges could cause problems in a number of other ways by advertising low-cost adjacencies or making themselves the highest priority tree root or the like. In general, the protection against an untrusted device acting as an RBridge and wrecking havoc is to use IS-IS authentication [RFC5310] and configure and administer the TRILL campus so that only trusted RBridges have the authentication key.
本文件不会带来任何额外的安全风险。作为树根的流氓RBridge可以通过广告R昵称来吸引流量。然而，这并不代表风险的大幅增加，因为RBridges可能通过宣传低成本邻接或使自己成为最高优先级树根等方式在许多其他方面造成问题。通常，针对充当RBridge和破坏性破坏的不受信任设备的保护是使用is-is身份验证[RFC5310]并配置和管理TRILL校园，以便只有受信任的RBridge具有身份验证密钥。
For general TRILL security considerations, see [RFC6325]. For security considerations related to pseudo-nickname active-active, see [RFC7781].
有关一般TRILL安全注意事项，请参阅[RFC6325]。有关与伪昵称active-active相关的安全注意事项，请参阅[RFC7781]。
IANA has assigned two bits in the Nickname Flags APPsubTLV flags for the R and C bits discussed in Section 11.1 and update the "NickFlags Bits" subregistry of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry as follows:
IANA已在昵称标志APPSUTLV标志中为第11.1节中讨论的R和C位分配了两位，并更新了“大量链路透明互连（TRILL）参数”注册表的“NickFlags位”子区，如下所示：
Bit Mnemonic Description Reference
--- -------- -------------------- -----------
2 R Replication Nickname [RFC8361]
3 C Special RPF Check [RFC8361]
Bit Mnemonic Description Reference
--- -------- -------------------- -----------
2 R Replication Nickname [RFC8361]
3 C Special RPF Check [RFC8361]
[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>.
[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>.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <https://www.rfc-editor.org/info/rfc6165>.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 6165，DOI 10.17487/RFC6165，2011年4月<https://www.rfc-editor.org/info/rfc6165>.
[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>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <https://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<https://www.rfc-editor.org/info/rfc7780>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, <https://www.rfc-editor.org/info/rfc7781>.
[RFC7781]翟，H.，Senevirathne，T.，Perlman，R.，张，M.，和Y.Li，“大量链路的透明互连（TRILL）：主动-主动访问的伪昵称”，RFC 7781，DOI 10.17487/RFC7781，2016年2月<https://www.rfc-editor.org/info/rfc7781>.
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <https://www.rfc-editor.org/info/rfc7379>.
[RFC7379]Li，Y.，Hao，W.，Perlman，R.，Hudson，J.，和H.Zhai，“大量链路透明互连（TRILL）边缘主动连接的问题陈述和目标”，RFC 7379，DOI 10.17487/RFC7379，2014年10月<https://www.rfc-editor.org/info/rfc7379>.
[RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, <https://www.rfc-editor.org/info/rfc7783>.
[RFC7783]Senevirathne，T.，Pathangi，J.，和J.Hudson，“用于大量链路（TRILL）透明互连的协调多播树（CMT）”，RFC 7783，DOI 10.17487/RFC7783，2016年2月<https://www.rfc-editor.org/info/rfc7783>.
[IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregation", IEEE 802.1AX, DOI 10.1109/IEEESTD.2017.7888436, March 2017, <http://ieeexplore.ieee.org/document/7888436/>.
[IEEE802.1AX]IEEE，“局域网和城域网的IEEE标准——链路聚合”，IEEE 802.1AX，DOI 10.1109/IEEESTD.2017.7888436，2017年3月<http://ieeexplore.ieee.org/document/7888436/>.
Acknowledgments
致谢
The authors wish to acknowledge the important contributions of Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia, and Francis Dupont.
作者希望感谢唐纳德·伊斯特莱克、翟红军、吴晓敏、梁霞和弗朗西斯·杜邦的重要贡献。
Authors' Addresses
作者地址
Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China
中国南京软件大道101号华为技术有限公司，邮编：210012
Email: haoweiguo@huawei.com
Email: haoweiguo@huawei.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
中国南京软件大道101号宜州利华为技术有限公司210012
Email: liyizhou@huawei.com
Email: liyizhou@huawei.com
Muhammad Durrani Equinix
穆罕默德·杜拉尼·伊克尼克斯
Email: mdurrani@equinix.com
Email: mdurrani@equinix.com
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore - 560048 India
苏杰·古普塔（Sujay Gupta）印度班加罗尔后马哈德瓦普拉百周年纪念酒店
Email: sujay.gupta@ipinfusion.com
Email: sujay.gupta@ipinfusion.com
Andrew Qu MediaTec
屈宏发
Email: laodulaodu@gmail.com
Email: laodulaodu@gmail.com