Internet Engineering Task Force (IETF) H. Zhai
Request for Comments: 7781 JIT
Category: Standards Track T. Senevirathne
ISSN: 2070-1721 Consultant
R. Perlman
EMC
M. Zhang
Y. Li
Huawei Technologies
February 2016
Internet Engineering Task Force (IETF) H. Zhai
Request for Comments: 7781 JIT
Category: Standards Track T. Senevirathne
ISSN: 2070-1721 Consultant
R. Perlman
EMC
M. Zhang
Y. Li
Huawei Technologies
February 2016
Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access
大量链路的透明互连（TRILL）：主动访问的伪昵称
Abstract
摘要
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active-active access to such an end station is represented as a virtual RBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations.
IETF TRILL（多链路透明互连）协议为具有任意拓扑结构的网络中的单播和多目的流量提供流级多路径支持。如RFC 7379所述，TRILL边缘的主动接入是这些特性的延伸，延伸到与TRILL校园多重连接的终端站。在本文档中，提供对这样一个终端站的主动访问的边缘RBridge（路由桥或TRILL交换机）组被表示为虚拟RBridge。基于虚拟RBridge的概念及其伪昵称，本文件规定了此类终端站进行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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc7781.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7781.
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 ....................................................4
1.1. Terminology and Acronyms ...................................6
2. Overview ........................................................7
3. Virtual RBridge and Its Pseudo-Nickname .........................9
4. Auto-Discovery of Member RBridges ..............................10
4.1. Discovering Member RBridge for an RBv .....................11
4.2. Selection of Pseudo-Nickname for an RBv ...................13
5. Distribution Trees and Designated Forwarder ....................14
5.1. Different Trees for Different Member RBridges .............15
5.2. Designated Forwarder for Member RBridges ..................16
5.3. Ingress Nickname Filtering ................................18
6. TRILL Traffic Processing .......................................19
6.1. Ingressing Native Frames ..................................19
6.2. Egressing TRILL Data Packets ..............................20
6.2.1. Unicast TRILL Data Packets .........................20
6.2.2. Multi-Destination TRILL Data Packets ...............21
7. MAC Information Synchronization in Edge Group ..................22
8. Member Link Failure in an RBv ..................................23
8.1. Link Protection for Unicast Frame Egressing ...............24
9. TLV Extensions for Edge RBridge Group ..........................24
9.1. PN-LAALP-Membership APPsub-TLV ............................24
9.2. PN-RBv APPsub-TLV .........................................26
9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs ......................27
9.4. LAALP IDs .................................................29
10. OAM Packets ...................................................29
11. Configuration Consistency .....................................29
12. Security Considerations .......................................30
13. IANA Considerations ...........................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................33
Acknowledgments ...................................................34
Contributors ......................................................34
Authors' Addresses ................................................35
1. Introduction ....................................................4
1.1. Terminology and Acronyms ...................................6
2. Overview ........................................................7
3. Virtual RBridge and Its Pseudo-Nickname .........................9
4. Auto-Discovery of Member RBridges ..............................10
4.1. Discovering Member RBridge for an RBv .....................11
4.2. Selection of Pseudo-Nickname for an RBv ...................13
5. Distribution Trees and Designated Forwarder ....................14
5.1. Different Trees for Different Member RBridges .............15
5.2. Designated Forwarder for Member RBridges ..................16
5.3. Ingress Nickname Filtering ................................18
6. TRILL Traffic Processing .......................................19
6.1. Ingressing Native Frames ..................................19
6.2. Egressing TRILL Data Packets ..............................20
6.2.1. Unicast TRILL Data Packets .........................20
6.2.2. Multi-Destination TRILL Data Packets ...............21
7. MAC Information Synchronization in Edge Group ..................22
8. Member Link Failure in an RBv ..................................23
8.1. Link Protection for Unicast Frame Egressing ...............24
9. TLV Extensions for Edge RBridge Group ..........................24
9.1. PN-LAALP-Membership APPsub-TLV ............................24
9.2. PN-RBv APPsub-TLV .........................................26
9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs ......................27
9.4. LAALP IDs .................................................29
10. OAM Packets ...................................................29
11. Configuration Consistency .....................................29
12. Security Considerations .......................................30
13. IANA Considerations ...........................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................33
Acknowledgments ...................................................34
Contributors ......................................................34
Authors' Addresses ................................................35
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] [RFC7176] link-state routing and encapsulating traffic using a header that includes a Hop Count. Devices that implement TRILL are called RBridges (Routing Bridges) or TRILL switches.
IETF TRILL（大量链路的透明互连）协议[RFC6325]提供无需配置的最佳成对数据帧转发，即使在临时循环期间也能安全转发，并支持单播和多播流量的多路径传输。TRILL通过使用IS-IS[IS-IS][RFC7176]链路状态路由和使用包含跃点计数的报头封装流量来实现这一点。实现TRILL的设备称为RBridges（路由桥）或TRILL交换机。
In the base TRILL protocol, an end node can be attached to the TRILL campus via a point-to-point link or a shared link such as a bridged LAN (Local Area Network). Although there might be more than one edge RBridge on a shared link, to avoid potential forwarding loops, one and only one of the edge RBridges is permitted to provide forwarding service for end-station traffic in each VLAN (Virtual LAN). That RBridge is referred to as the Appointed Forwarder (AF) for that VLAN on the link [RFC6325] [RFC6439]. However, in some practical deployments, to increase the access bandwidth and reliability, an end station might be multiply connected to several edge RBridges, and all of the uplinks are handled via a Local Active-Active Link Protocol (LAALP [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or Distributed Resilient Network Interconnect (DRNI) [802.1AX]. In this case, it is required that traffic can be ingressed into, and egressed from, the TRILL campus by any of the RBridges for each given VLAN. These RBridges constitute an Active-Active Edge (AAE) RBridge group.
在基本TRILL协议中，终端节点可以通过点到点链路或共享链路（如桥接LAN（局域网））连接到TRILL园区。尽管共享链路上可能有多个边缘RBridge，但为了避免潜在的转发循环，允许且仅允许一个边缘RBridge为每个VLAN（虚拟LAN）中的终端站流量提供转发服务。该RBridge被称为链路[RFC6325][RFC6439]上该VLAN的指定转发器（AF）。然而，在一些实际部署中，为了增加接入带宽和可靠性，一个终端站可以与多个边缘RBridge多连接，并且所有上行链路都通过本地主动链路协议（LAALP[RFC7379]）处理，例如多机箱链路聚合（MC-LAG）或分布式弹性网络互连（DRNI）[802.1AX]。在这种情况下，要求每个给定VLAN的任何RBridge都可以将流量进出TRILL园区。这些RBridge构成活动边缘（AAE）RBridge组。
With an LAALP, traffic with the same VLAN and source Media Access Control (MAC) address but belonging to different flows will frequently be sent to different member RBridges of the AAE group and then ingressed into the TRILL campus. When an egress RBridge receives such TRILL Data packets ingressed by different RBridges, it learns different correspondences between a {Data Label and MAC address} and nickname continuously when decapsulating the packets if it has data-plane address learning enabled. This issue is known as "MAC address flip-flopping"; it makes most TRILL switches behave badly and causes the returning traffic to reach the destination via different paths, resulting in persistent reordering of the frames. In addition to this issue, other issues, such as duplicate egressing and loopback of multi-destination frames, may also disturb an end station multiply connected to the member RBridges of an AAE group [RFC7379].
使用LAALP，具有相同VLAN和源媒体访问控制（MAC）地址但属于不同流的流量将经常发送到AAE组的不同成员RBridge，然后进入TRILL校园。当出口RBridge接收到由不同RBridge进入的这种TRILL数据分组时，如果其启用了数据平面地址学习，则在对分组进行解封装时，它连续地学习{Data Label and MAC address}和昵称之间的不同对应关系。这个问题被称为“MAC地址触发器”；它使大多数颤音切换行为不好，并导致返回的流量通过不同的路径到达目的地，从而导致帧的持续重新排序。除此之外，其他问题，例如多目的地帧的重复出口和环回，也可能干扰连接到AAE组的成员rbridge的端站乘法[RFC7379]。
This document addresses the AAE issues of TRILL by specifying how members of an edge RBridge group can be represented by a virtual RBridge (RBv) and assigned a pseudo-nickname. A member RBridge of such a group uses a pseudo-nickname instead of its own nickname as
本文档通过指定边缘RBridge组的成员如何由虚拟RBridge（RBv）表示并分配一个伪昵称来解决TRILL的AAE问题。这样一个组的成员使用一个伪昵称，而不是自己的昵称
the ingress RBridge nickname when ingressing frames received on attached LAALP links. Other methods are possible: for example, the specification in this document and the specification in [RFC7782] could be simultaneously deployed for different AAE groups in the same campus. If the method defined in [RFC7782] is used, edge TRILL switches need to support the capability indicated by the Capability Flags APPsub-TLV as specified in Section 4.2 of [RFC7782]. If the method defined in this document is adopted, all TRILL switches need to support the Affinity sub-TLV defined in [RFC7176] and [RFC7783]. For a TRILL campus that deploys both of these AAE methods, TRILL switches are required to support both methods. However, it is desirable to only adopt one method in a TRILL campus so that the operating expense, complexity of troubleshooting, etc., can be reduced.
在连接的LAALP链路上接收到的帧进入时，进入RBridge昵称。其他方法也是可能的：例如，本文档中的规范和[RFC7782]中的规范可以同时部署到同一校园中的不同AAE组。如果使用[RFC7782]中定义的方法，边缘颤音开关需要支持[RFC7782]第4.2节中规定的功能标志APPsub TLV所指示的功能。如果采用本文档中定义的方法，则所有TRILL交换机都需要支持[RFC7176]和[RFC7783]中定义的关联子TLV。对于部署这两种AAE方法的TRILL园区，需要TRILL交换机来支持这两种方法。然而，希望在TRILL校园中仅采用一种方法，以便降低操作费用、故障排除的复杂性等。
The main body of this document is organized as follows:
本文件的正文组织如下：
o Section 2 provides an overview of the TRILL active-active access issues and the reason that a virtual RBridge (RBv) is used to resolve the issues.
o 第2节概述了TRILL主动访问问题以及使用虚拟RBv（RBv）解决这些问题的原因。
o Section 3 describes the concept of a virtual RBridge (RBv) and its pseudo-nickname.
o 第3节描述了虚拟RBridge（RBv）的概念及其伪昵称。
o Section 4 describes how edge RBridges can support an RBv automatically and get a pseudo-nickname for the RBv.
o 第4节描述了edge RBridges如何自动支持RBv并为RBv获取伪昵称。
o Section 5 discusses how to protect multi-destination traffic against disruption due to Reverse Forwarding Path (RPF) check failure, duplication, forwarding loops, etc.
o 第5节讨论了如何保护多目的地流量，防止因反向转发路径（RPF）检查失败、复制、转发循环等而中断。
o Section 6 covers the special processing of native frames and TRILL Data packets at member RBridges of an RBv (also referred to as an Active-Active Edge (AAE) RBridge group).
o 第6节涵盖在RBv（也称为活动边缘（AAE）RBridge组）的成员RBridge处的本机帧和颤音数据分组的特殊处理。
o Section 7 describes the MAC information synchronization among the member RBridges of an RBv.
o 第7部分描述RBv的成员RBv之间的MAC信息同步。
o Section 8 discusses protection against downlink failure at a member RBridge.
o 第8节讨论在成员RBridge处针对下行链路故障的保护。
o Section 9 lists the necessary TRILL code points and data structures for a pseudo-nickname AAE RBridge group.
o 第9节列出了伪昵称AAE RBridge组所需的颤音代码点和数据结构。
This document uses the acronyms and terms defined in [RFC6325] and [RFC7379], as well as the following additional acronyms:
本文件使用[RFC6325]和[RFC7379]中定义的首字母缩略词和术语，以及以下附加首字母缩略词：
AAE: Active-active Edge RBridge group. A group of edge RBridges to which at least one Customer Equipment (CE) node is multiply attached with an LAALP. AAE is also referred to as "edge group" or "virtual RBridge" in this document.
AAE：活动边RBridge组。一组边缘RBridge，其中至少一个客户设备（CE）节点与LAALP相乘连接。AAE在本文件中也称为“边缘组”或“虚拟RBridge”。
Campus: A TRILL network consisting of TRILL switches, links, and possibly bridges bounded by end stations and IP routers. For TRILL, there is no "academic" implication in the name "campus".
校园网：由TRILL交换机、链路和可能由终端站和IP路由器连接的网桥组成的TRILL网络。对于TRILL来说，“校园”这个名字没有“学术”含义。
CE: Customer Equipment (end station or bridge). The device can be either physical or virtual equipment.
CE：客户设备（终端站或桥接器）。设备可以是物理设备，也可以是虚拟设备。
Data Label: VLAN or Fine-Grained Label (FGL).
数据标签：VLAN或细粒度标签（FGL）。
DF: Designated Forwarder.
DF：指定货代。
DRNI: Distributed Resilient Network Interconnect. A link aggregation specified in [802.1AX] that can provide an LAALP between (a) one, two, or three CEs and (b) two or three RBridges.
分布式弹性网络互连。[802.1AX]中规定的链路聚合，可在（A）一个、两个或三个CE和（b）两个或三个RBRIGE之间提供LAALP。
E-L1FS: Extended Level 1 Flooding Scope [RFC7356].
E-L1FS：扩展1级洪水范围[RFC7356]。
ESADI: End-Station Address Distribution Information.
ESADI：终端站地址分布信息。
FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained Label [RFC7172].
FGL：细粒度标签或细粒度标签或细粒度标签[RFC7172]。
LAALP: Local Active-Active Link Protocol [RFC7379], e.g., MC-LAG or DRNI.
LAALP：本地主动链路协议[RFC7379]，例如MC-LAG或DRNI。
MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of Link Aggregation [802.1AX] that can provide an LAALP between one CE and two or more RBridges.
MC-LAG：多机箱链路聚合。链路聚合[802.1AX]的专有扩展，可在一个CE和两个或多个RBRIGE之间提供LAALP。
OE-flag: A flag used by a member RBridge of a given LAALP to tell other edge RBridges of this LAALP whether this LAALP is willing to share an RBv with other LAALPs that multiply attach to the same set of edge RBridges as the given LAALP does. When this flag for an LAALP is 1, it means that the LAALP needs to be served by an RBv by itself and is not willing to share, that is, it should Occupy an RBv Exclusively (OE).
OE标志：由给定LAALP的成员RBridge使用的标志，用于告知该LAALP的其他边缘RBridge该LAALP是否愿意与其他LAALP共享一个RBv，这些LAALP与给定LAALP相同的边缘RBridge集合相乘。当LAALP的标志为1时，意味着LAALP需要由RBv单独提供服务，并且不愿意共享，也就是说，它应该独占RBv（OE）。
RBv: Virtual RBridge. An alias for "active-active edge RBridge group" in this document.
RBv：虚拟的RBridge。本文档中“活动边缘RBridge组”的别名。
vDRB: The Designated RBridge in an RBv. It is responsible for deciding the pseudo-nickname for the RBv.
vDRB：RBv中指定的RBridge。它负责决定RBv的伪昵称。
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]中所述进行解释。
To minimize impact during failures and maximize available access bandwidth, Customer Equipment (referred to as "CE" in this document) may be multiply connected to the TRILL campus via multiple edge RBridges.
为了尽量减少故障期间的影响并最大限度地提高可用访问带宽，客户设备（在本文档中称为“CE”）可以通过多个边缘RBridge与TRILL校园进行多重连接。
Figure 1 shows such a typical deployment scenario, where CE1 attaches to RB1, RB2, ... RBk and treats all of the uplinks as an LAALP bundle. RB1, RB2, ... RBk then constitute an AAE RBridge group for CE1 in this LAALP. Even if a member RBridge or an uplink fails, CE1 will still get frame forwarding service from the TRILL campus if there are still member RBridges and uplinks available in the AAE group. Furthermore, CE1 can make flow-based load balancing across the available member links of the LAALP bundle in the AAE group when it communicates with other CEs across the TRILL campus [RFC7379].
图1显示了这样一个典型的部署场景，其中CE1连接到RB1、RB2。。。RBk并将所有上行链路视为LAALP包。RB1，RB2。。。然后，RBk构成本LAALP中CE1的AAE RBridge群。即使成员RBridge或上行链路出现故障，如果AAE组中仍有成员RBridge和上行链路可用，CE1仍将从TRILL校园获得帧转发服务。此外，当CE1与TRILL园区内的其他CE通信时，它可以在AAE组中的LAALP捆绑包的可用成员链路之间实现基于流的负载平衡[RFC7379]。
----------------------
| |
| TRILL Campus |
| |
----------------------
| | |
+-----+ | +--------+
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
LAALP1-->(| | |) (| | |) <--LAALPn
+-------+ . . . +-------+
| CE1 | | CEn |
+-------+ +-------+
----------------------
| |
| TRILL Campus |
| |
----------------------
| | |
+-----+ | +--------+
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
LAALP1-->(| | |) (| | |) <--LAALPn
+-------+ . . . +-------+
| CE1 | | CEn |
+-------+ +-------+
Figure 1: Active-Active Connection to TRILL Edge RBridges
图1：到颤音边缘RBridges的活动连接
By design, an LAALP (say LAALP1) does not forward packets received on one member port to other member ports. As a result, the TRILL Hello messages sent by one member RBridge (say RB1) via a port to CE1 will not be forwarded to other member RBridges by CE1. That is to say, member RBridges will not see each other's Hellos via the LAALP. So, every member RBridge of LAALP1 thinks of itself as Appointed Forwarder for all VLANs enabled on an LAALP1 link and can ingress/egress frames simultaneously in these VLANs [RFC6439].
根据设计，LAALP（比如LAALP1）不会将一个成员端口上接收到的数据包转发给其他成员端口。因此，一个成员RBridge（比如RB1）通过端口发送到CE1的TRILL Hello消息不会被CE1转发到其他成员RBridge。也就是说，RBridges成员不会通过LAALP看到彼此的问候。因此，LAALP1的每个成员RBridge都认为自己是在LAALP1链路上启用的所有VLAN的指定转发器，并且可以在这些VLAN中同时进出帧[RFC6439]。
The simultaneous flow-based ingressing/egressing can cause some problems. For example, simultaneous egressing of multi-destination traffic by multiple member RBridges will result in frame duplication at CE1 (see Section 3.1 of [RFC7379]); simultaneous ingressing of frames originated by CE1 for different flows in the same VLAN with the same source MAC address will result in MAC address flip-flopping at remote egress RBridges that have data-plane address learning enabled (see Section 3.3 of [RFC7379]). The flip-flopping would in turn cause packet reordering in reverse traffic.
同时基于流量的进出可能会导致一些问题。例如，多个成员RBridge同时退出多目的地业务将导致CE1处的帧复制（参见[RFC7379]第3.1节）；CE1为同一VLAN中具有相同源MAC地址的不同流发起的帧同时进入将导致启用数据平面地址学习的远程出口RBridge的MAC地址翻转（参见[RFC7379]第3.3节）。触发器反过来会导致反向流量中的数据包重新排序。
Edge RBridges learn correspondences between a {Data Label and MAC address} and nickname by default when decapsulating TRILL Data packets (see Section 4.8.1 of [RFC6325], as updated by [RFC7172]). Assuming that the default data-plane learning is enabled at edge RBridges, MAC address flip-flopping can be solved by using a virtual RBridge together with its pseudo-nickname. This document specifies a way to do so.
边缘RBridges在解除TRILL数据包封装时，默认情况下学习{数据标签和MAC地址}与昵称之间的对应关系（见[RFC6325]第4.8.1节，由[RFC7172]更新）。假设在边缘RBridge启用默认数据平面学习，则可以通过使用虚拟RBridge及其伪昵称来解决MAC地址翻转问题。本文件规定了一种方法。
A virtual RBridge (RBv) represents a group of edge RBridges to which at least one CE is multiply attached using an LAALP. More precisely, it represents a group of ports on the edge RBridges providing end-station service and the service provided to the CE(s) on these ports, through which the CE(s) is multiply attached to the TRILL campus using LAALP(s). Such end-station service ports are called RBv ports; in contrast, other access ports at edge RBridges are called regular access ports in this document. RBv ports are always LAALP connecting ports, but not vice versa (see Section 4.1). For an edge RBridge, if one or more of its end-station service ports are ports of an RBv, that RBridge is a member RBridge of that RBv.
虚拟RBridge（RBv）表示使用LAALP将至少一个CE多重连接到的一组边缘RBridge。更准确地说，它表示边缘RBridge上的一组端口，这些端口提供终端站服务和向这些端口上的CE提供的服务，通过这些端口，CE使用LAALP倍增连接到TRILL校园。这种终端站服务端口称为RBv端口；相反，在本文档中，边缘RBridge上的其他访问端口称为常规访问端口。RBv端口始终为LAALP连接端口，但反之亦然（见第4.1节）。对于边缘RBridge，如果其一个或多个端站服务端口是RBv的端口，则该RBridge是该RBv的成员RBridge。
For the convenience of description, a virtual RBridge is also referred to as an Active-Active Edge (AAE) group in this document. In the TRILL campus, an RBv is identified by its pseudo-nickname, which is different from any RBridge's regular nickname(s). An RBv has one and only one pseudo-nickname. Each member RBridge (say RB1, RB2 ..., RBk) of an RBv (say RBvn) advertises RBvn's pseudo-nickname using a Nickname sub-TLV in its TRILL IS-IS LSP (Link State PDU) [RFC7176] and SHOULD do so with maximum priority of use (0xFF), along with their regular nickname(s). (Maximum priority is recommended to avoid the disruption to an AAE group that would occur if the nickname were taken away by a higher-priority RBridge.) Then, from these LSPs, other RBridges outside the AAE group know that RBvn is reachable through RB1 to RBk.
为了便于描述，在本文档中，虚拟RBridge也称为活动边缘（AAE）组。在TRILL校园中，RBv通过其伪昵称来识别，这不同于任何RBridge的常规昵称。RBv只有一个伪昵称。RBv（RBvn）的每个成员RBridge（RB1、RB2…、RBk）在其TRILL IS-IS LSP（链路状态PDU）[RFC7176]中使用昵称子TLV来宣传RBvn的伪昵称，并应以最大使用优先级（0xFF）及其常规昵称进行宣传。（建议使用最大优先级，以避免在昵称被更高优先级的RBridge拿走时对AAE组造成中断。）然后，从这些LSP中，AAE组之外的其他RBridge知道RBvn可以通过RB1到RBk访问。
A member RBridge (say RBi) loses its membership in RBvn when its last port in RBvn becomes unavailable due to failure, reconfiguration, etc. RBi then removes RBvn's pseudo-nickname from its LSP and distributes the updated LSP as usual. From those updated LSPs, other RBridges know that there is no path to RBvn through RBi now.
当成员RBvn中的最后一个端口因故障、重新配置等而变得不可用时，RBRIGE（如RBi）将失去其在RBvn中的成员身份。RBi然后从其LSP中删除RBvn的伪昵称，并像往常一样分发更新后的LSP。从这些更新的LSP中，其他RBvn知道现在没有通过RBi到RBvn的路径。
When member RBridges receive native frames on their RBv ports and decide to ingress the frames into the TRILL campus, they use that RBv's pseudo-nickname instead of their own regular nicknames as the ingress nickname to encapsulate them into TRILL Data packets. So, when these packets arrive at an egress RBridge, even if they are originated by the same end station in the same VLAN but ingressed by
当成员RBv在其RBv端口上接收本机帧并决定将这些帧进入TRILL校园时，它们使用该RBv的伪昵称而不是自己的常规昵称作为入口昵称，将其封装到TRILL数据包中。因此，当这些数据包到达出口RBridge时，即使它们是由同一VLAN中的同一终端站发起的，但由用户进入
different member RBridges, no address flip-flopping is observed on the egress RBridge when decapsulating these packets. (When a member RBridge of an AAE group ingresses a frame from a non-RBv port, it still uses its own regular nickname as the ingress nickname.)
不同的成员RBridge，在解除封装这些数据包时，在出口RBridge上未观察到地址触发器。（当AAE组的成员RBridge从非RBv端口进入帧时，它仍然使用自己的常规昵称作为进入昵称。）
Since an RBv is not a physical node and no TRILL frames are forwarded between its ports via an LAALP, pseudonode LSP(s) MUST NOT be created for an RBv. An RBv cannot act as a root when constructing distribution trees for multi-destination traffic, and its pseudo-nickname is ignored when determining the distribution tree root for the TRILL campus [RFC7783]. So, the tree root priority of the RBv's nickname MUST be set to 0, and this nickname MUST NOT be listed in the "s" nicknames (see Section 4.5 of [RFC6325]) by the RBridge holding the highest-priority tree root nickname.
由于RBv不是物理节点，并且没有通过LAALP在其端口之间转发TRILL帧，因此不得为RBv创建伪节点LSP。在为多目的地流量构建分发树时，RBv不能充当根，在确定TRILL校园的分发树根时，其伪昵称被忽略[RFC7783]。因此，RBv昵称的树根优先级必须设置为0，并且拥有最高优先级树根昵称的RBridge不得将该昵称列在“s”昵称中（见[RFC6325]第4.5节）。
NOTE: In order to reduce the consumption of nicknames, especially in a large TRILL campus with lots of RBridges and/or active-active accesses, when multiple CEs attach to exactly the same set of edge RBridges via LAALPs, those edge RBridges should be considered a single RBv with a single pseudo-nickname.
注：为了减少昵称的使用，特别是在具有大量RBridge和/或活动访问的大型TRILL校园中，当多个CE通过LAALPs连接到完全相同的边缘RBridge集时，这些边缘RBridge应被视为具有单个伪昵称的单个RBv。
Edge RBridges connected to a CE via an LAALP can automatically discover each other with minimal configuration through the exchange of LAALP connection information.
通过LAALP连接到CE的边缘RBridge可以通过交换LAALP连接信息以最小配置自动发现彼此。
From the perspective of edge RBridges, a CE that connects to edge RBridges via an LAALP can be identified by the ID of the LAALP that is unique across the TRILL campus (for example, the MC-LAG or DRNI System ID [802.1AX]), which is referred to as an LAALP ID in this document. On each such edge RBridge, the access port to such a CE is associated with an LAALP ID for the CE. An LAALP is considered valid on an edge RBridge only if the RBridge still has an operational downlink to that LAALP. For such an edge RBridge, it advertises a list of LAALP IDs for its valid local LAALPs to other edge RBridges via its E-L1FS FS-LSP(s) [RFC7356] [RFC7780]. Based on the LAALP IDs advertised by other RBridges, each RBridge can know which edge RBridges could constitute an AAE group (see Section 4.1 for more details). One RBridge is then elected from the group to allocate an available nickname (the pseudo-nickname) for the group (see Section 4.2 for more details).
从边缘RBridges的角度来看，通过LAALP连接到边缘RBridges的CE可以通过整个TRILL园区唯一的LAALP ID（例如，MC-LAG或DRNI系统ID[802.1AX]）来识别，在本文档中称为LAALP ID。在每个这样的边缘RBridge上，到这样的CE的接入端口与CE的LAALP ID相关联。只有当边缘RBridge仍然具有到该LAALP的可操作下行链路时，LAALP才被认为在边缘RBridge上有效。对于这种边缘RBridge，它通过其E-L1FS FS-LSP[RFC7356][RFC7780]向其他边缘RBridge发布其有效本地LAALP的LAALP ID列表。根据其他RBridge发布的LAALP ID，每个RBridge可以知道哪些边缘RBridge可以构成AAE组（更多详细信息，请参见第4.1节）。然后从组中选出一个RBridge，为组分配一个可用的昵称（伪昵称）（有关更多详细信息，请参阅第4.2节）。
Take Figure 2 as an example, where CE1 and CE2 multiply attach to RB1, RB2, and RB3 via LAALP1 and LAALP2, respectively; CE3 and CE4 attach to RB3, and RB4 via LAALP3 and LAALP4, respectively. Assume that LAALP3 is configured to occupy a virtual RBridge by itself.
以图2为例，其中CE1和CE2分别通过LAALP1和LAALP2与RB1、RB2和RB3相乘；CE3和CE4分别通过LAALP3和LAALP4连接到RB3和RB4。假设LAALP3被配置为单独占用虚拟RBridge。
------------------------
/ \
| TRILL Campus |
\ /
-------------------------
| | | |
+-------+ | | +----------+
| | | |
+-------+ +-------+ +-------+ +-------+
| RB1 | | RB2 | | RB3 | | RB4 |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | |
| +--------|--+ | +-------|-+ | +-------|---+ |
| +----------+ | | | | | | | |
| | +-----------|-|-|-------+ | +-------+ | |
| | | | | | | | | |
LAALP1->(| | |) LAALP2->(| | |) LAALP3->(| |) LAALP4->(| |)
+-------+ +-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 | | CE4 |
+-------+ +-------+ +-------+ +-------+
------------------------
/ \
| TRILL Campus |
\ /
-------------------------
| | | |
+-------+ | | +----------+
| | | |
+-------+ +-------+ +-------+ +-------+
| RB1 | | RB2 | | RB3 | | RB4 |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | |
| +--------|--+ | +-------|-+ | +-------|---+ |
| +----------+ | | | | | | | |
| | +-----------|-|-|-------+ | +-------+ | |
| | | | | | | | | |
LAALP1->(| | |) LAALP2->(| | |) LAALP3->(| |) LAALP4->(| |)
+-------+ +-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 | | CE4 |
+-------+ +-------+ +-------+ +-------+
Figure 2: Different LAALPs to TRILL Campus
图2：不同的LAALPs到TRILL校园
RB1 and RB2 advertise {LAALP1, LAALP2} in the PN-LAALP-Membership APPsub-TLV (see Section 9.1 for more details) via their TRILL E-L1FS FS-LSPs, respectively; RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4}, and RB4 announces {LAALP3, LAALP4}, respectively.
RB1和RB2分别通过其颤音E-L1FS LSP在PN LAALP成员APPsub TLV（详见第9.1节）中宣传{LAALP1，LAALP2}；RB3分别宣布{LAALP1，LAALP2，LAALP3，LAALP4}，RB4宣布{LAALP3，LAALP4}。
An edge RBridge is called an "LAALP related RBridge" if it has at least one LAALP configured on an access port. On receipt of the PN-LAALP-Membership APPsub-TLVs, RBn ignores them if it is not an LAALP related RBridge; otherwise, RBn SHOULD use the LAALP information contained in the sub-TLVs, along with its own PN-LAALP-Membership APPsub-TLVs, to decide which RBv(s) it should join and which edge RBridges constitute each such RBv. Based on the information received, each of the four RBridges knows the following:
如果在接入端口上至少配置了一个LAALP，则边缘RBridge称为“LAALP相关RBridge”。在收到PN LAALP成员APPsub TLV后，如果RBn不是与LAALP相关的RBV，则RBn将忽略它们；否则，RBn应使用子TLV中包含的LAALP信息以及其自身的PN LAALP成员APPsub TLV，以决定其应加入哪些RBv以及哪些边缘RBv脊线构成每个此类RBv。根据收到的信息，四个RBridge中的每一个都知道以下内容：
LAALP ID OE-flag Set of edge RBridges
--------- -------- ---------------------
LAALP1 0 {RB1, RB2, RB3}
LAALP2 0 {RB1, RB2, RB3}
LAALP3 1 {RB3, RB4}
LAALP4 0 {RB3, RB4}
LAALP ID OE-flag Set of edge RBridges
--------- -------- ---------------------
LAALP1 0 {RB1, RB2, RB3}
LAALP2 0 {RB1, RB2, RB3}
LAALP3 1 {RB3, RB4}
LAALP4 0 {RB3, RB4}
where the OE-flag indicates whether a given LAALP is willing to share an RBv with other LAALPs that multiply attach to the same set of edge RBridges as the given LAALP does.
其中，OE标志表示给定LAALP是否愿意与其他LAALP共享RBv，这些LAALP与给定LAALP一样，与同一组边缘RBridge相乘。
For an LAALP (for example, LAALP3), if its OE-flag is one, it means that LAALP3 does not want to share, so it MUST Occupy an RBv Exclusively (OE). Support of OE is optional. RBridges that do not support OE ignore the OE-flag and act as if it were zero (see Section 11 ("Configuration Consistency")).
对于LAALP（例如，LAALP3），如果其OE标志为1，则意味着LAALP3不想共享，因此它必须独占RBv（OE）。OE支持是可选的。不支持OE的RBridge忽略OE标志，并将其视为零（参见第11节（“配置一致性”）。
Otherwise, the LAALP (for example, LAALP1) will share an RBv with other LAALPs if possible. By default, this flag is set to zero. For an LAALP, this flag is considered 1 if any edge RBridge advertises it as (value) 1 (see Section 9.1).
否则，LAALP（例如，LAALP1）将尽可能与其他LAALP共享RBv。默认情况下，此标志设置为零。对于LAALP，如果任何边缘RBridge将其宣传为（值）1，则该标志视为1（见第9.1节）。
In the above table, there might be some LAALPs that attach to a single RBridge due to misconfiguration or link failure, etc. Those LAALPs are considered to be invalid entries. Each of the LAALP related edge RBridges then performs the following algorithm to decide which valid LAALPs can be served by an RBv.
在上表中，由于配置错误或链路故障等原因，可能有一些LAALP连接到单个RBridge。这些LAALP被视为无效条目。然后，每个与LAALP相关的边缘RBridge执行以下算法，以确定RBv可以为哪些有效的LAALP提供服务。
Step 1: Take all the valid LAALPs that have their OE-flags set to 1 out of the table and create an RBv for each such LAALP.
步骤1：从表中取出所有OE标志设置为1的有效LAALP，并为每个此类LAALP创建RBv。
Step 2: Sort the valid LAALPs left in the table in descending order based on the number of RBridges in their associated set of multihomed RBridges. If several LAALPs have the same number of RBridges, these LAALPs are then ordered in ascending order in the proper places of the table, based on their LAALP IDs considered to be unsigned integers. (For example, in the above
步骤2：根据多宿RBridge关联集合中RBridge的数量，按降序对表中剩余的有效LAALP进行排序。如果多个LAALP具有相同数量的RBridge，则这些LAALP将根据其被视为无符号整数的LAALP ID按升序排列在表的适当位置。（例如，在上述
table, both LAALP1 and LAALP2 have three member RBridges, assuming that the LAALP1 ID is smaller than the LAALP2 ID, so LAALP1 is followed by LAALP2 in the ordered table.)
表中，LAALP1和LAALP2都有三个成员RBridge，假设LAALP1 ID小于LAALP2 ID，因此在有序表中LAALP1后面跟着LAALP2。）
Step 3: Take the first valid LAALP (say LAALP_i) with the maximum set of RBridges, say S_i, out of the table and create a new RBv (say RBv_i) for it.
步骤3：从表中取出第一个有效的LAALP（比如LAALP_i）和最大的RBridge集（比如S_i），并为其创建一个新的RBv（比如RBv_i）。
Step 4: Walk through the remaining valid LAALPs in the table one by one, pick up all the valid LAALPs whose sets of multi-homed RBridges contain exactly the same RBridges as that of LAALP_i, and take them out of the table. Then, appoint RBv_i as the servicing RBv for those LAALPs.
步骤4：逐个浏览表中剩余的有效LAALP，选择其多宿RBridge集合包含与LAALP_i完全相同RBridge的所有有效LAALP，并将其从表中取出。然后，指定RBv_i作为这些阿尔卑斯山的维修RBv。
Step 5: Repeat Steps 3 and 4 for any LAALPs left, until all the valid entries in the table are associated with an RBv.
步骤5：对剩余的所有LAALPs重复步骤3和4，直到表中的所有有效条目都与RBv关联。
After performing the above steps, all the four RBridges know that LAALP3 is served by an RBv, say RBv1, which has RB3 and RB4 as member RBridges; LAALP1 and LAALP2 are served by another RBv, say RBv2, which has RB1, RB2, and RB3 as member RBridges; and LAALP4 is served by RBv3, which has RB3 and RB4 as member RBridges, shown as follows:
在执行上述步骤之后，所有四个RBridge都知道LAALP3由RBv服务，例如RBv1，其成员RBridge为RB3和RB4；LAALP1和LAALP2由另一个RBv服务，如RBv2，其成员RB1、RB2和RB3；LAALP4由RBv3提供服务，RBv3和RB4作为成员RBridges，如下所示：
RBv Serving LAALPs Member RBridges
----- ------------------- ---------------
RBv1 {LAALP3} {RB3, RB4}
RBv2 {LAALP1, LAALP2} {RB1, RB2, RB3}
RBv3 {LAALP4} {RB3, RB4}
RBv Serving LAALPs Member RBridges
----- ------------------- ---------------
RBv1 {LAALP3} {RB3, RB4}
RBv2 {LAALP1, LAALP2} {RB1, RB2, RB3}
RBv3 {LAALP4} {RB3, RB4}
In each RBv, one of the member RBridges is elected as the vDRB (referred to in this document as the Designated RBridge of the RBv). Then, this RBridge picks up an available nickname as the pseudo-nickname for the RBv and announces it to all other member RBridges of the RBv via its TRILL E-L1FS FS-LSPs (refer to Section 9.2 for the relative extended sub-TLVs).
在每个RBv中，一名成员RBridge被选为vDRB（在本文件中称为RBv的指定RBridge）。然后，该RBridge选择一个可用昵称作为RBv的伪昵称，并通过其颤音E-L1FS LSP向RBv的所有其他成员RBridge宣布该昵称（有关相关扩展子TLV，请参阅第9.2节）。
As described in Section 3, in the TRILL campus, an RBv is identified by its pseudo-nickname. In an AAE group, one member RBridge is elected for the duty of selecting a pseudo-nickname for this RBv; this RBridge will be the vDRB. The winner in the group is the RBridge with the largest IS-IS System ID considered to be an unsigned integer. Then, based on its TRILL IS-IS link-state database and the potential pseudo-nickname(s) reported in the PN-LAALP-Membership APPsub-TLVs by other member RBridges of this RBv (see Section 9.1 for more details), the vDRB selects an available nickname as the pseudo-nickname for this RBv and advertises it to the other RBridges
如第3节所述，在TRILL校园中，RBv通过其伪昵称进行识别。在AAE小组中，选出一名成员RBridge，负责为该RBv选择一个伪昵称；此RBridge将成为vDRB。组中的获胜者是最大is-is系统ID为无符号整数的RBridge。然后，根据其TRILL IS-IS链路状态数据库和该RBv的其他成员RBridge在PN LAALP成员资格APPsub TLV中报告的潜在伪昵称（更多详细信息，请参见第9.1节），vDRB选择一个可用昵称作为该RBv的伪昵称，并向其他RBridge发布
via its E-L1FS FS-LSP(s) (see Section 9.2 and [RFC7780]). Except as provided below, the selection of a nickname to use as the pseudo-nickname follows the usual TRILL rules given in [RFC6325], as updated by [RFC7780].
通过其E-L1FS FS-LSP（见第9.2节和[RFC7780]）。除以下规定外，选择用作伪昵称的昵称遵循[RFC6325]中给出的通常颤音规则，并由[RFC7780]更新。
To reduce the traffic disruption caused by the changing of nicknames, if possible, the vDRB SHOULD attempt to reuse the pseudo-nickname recently used by the group when selecting nickname for the RBv. To help the vDRB to do so, each LAALP related RBridge advertises a reusing pseudo-nickname for each of its LAALPs in its PN-LAALP-Membership APPsub-TLV if it has used such a pseudo-nickname for that LAALP recently. Although it is up to the implementation of the vDRB as to how to treat the reusing pseudo-nicknames, the following are RECOMMENDED:
为了减少昵称更改造成的流量中断，如果可能，vDRB在为RBv选择昵称时应尝试重用组最近使用的伪昵称。为了帮助vDRB做到这一点，每个与LAALP相关的RBridge在其PN LAALP成员APPsub TLV中为其每个LAALP宣传一个可重用的伪昵称，前提是其最近使用了该LAALP的伪昵称。尽管如何处理重用伪昵称取决于vDRB的实现，但建议如下：
o If there are multiple available reusing pseudo-nicknames that are reported by all the member RBridges of some LAALPs in this RBv, the available one that is reported by the largest number of such LAALPs is chosen as the pseudo-nickname for this RBv. If a tie exists, the reusing pseudo-nickname with the smallest value considered to be an unsigned integer is chosen.
o 如果此RBv中某些LAALP的所有成员RBridge报告了多个可用的重用伪昵称，则选择由此类LAALP中数量最多的成员RBridge报告的可用昵称作为此RBv的伪昵称。如果存在tie，则选择重用伪昵称，其最小值被视为无符号整数。
o If only one reusing pseudo-nickname is reported, it SHOULD be chosen if available.
o 如果只报告了一个重用伪昵称，则应选择它（如果可用）。
If there is no available reusing pseudo-nickname reported, the vDRB selects a nickname by its usual method.
如果没有可用的重用伪昵称报告，vDRB将通过其常用方法选择昵称。
The selected pseudo-nickname is then announced by the vDRB to other member RBridges of this RBv in the PN-RBv APPsub-TLV (see Section 9.2).
然后，vDRB在PN RBv APPsub TLV中向该RBv的其他成员RBv宣布所选的伪昵称（见第9.2节）。
In an AAE group, as each of the member RBridges thinks it is the Appointed Forwarder for VLAN x, without changes made for active-active connection support, they would all ingress frames into, and egress frames from, the TRILL campus for all VLANs. For multi-destination frames, more than one member RBridge ingressing them may cause some of the resulting TRILL Data packets to be discarded due to failure of the Reverse Path Forwarding (RPF) check on other RBridges; for multi-destination traffic, more than one RBridge egressing it may cause local CE(s) to receive duplicate frames. Furthermore, in an AAE group, a multi-destination frame sent by a CE (say CEi) may be ingressed into the TRILL campus by one member RBridge, and another member RBridge will then receive it from the TRILL campus and egress it to CEi; this will result in loopback of the frame for CEi. These problems are all described in [RFC7379].
在AAE组中，由于每个成员RBridges都认为自己是VLAN x的指定转发器，因此在不改变主动-主动连接支持的情况下，他们将为所有VLAN将所有进入帧导入TRILL园区，并从TRILL园区中退出帧。对于多目的地帧，多个成员RBridge进入它们可能导致由于其他RBridge上的反向路径转发（RPF）检查失败而丢弃一些结果TRILL数据分组；对于多目的地业务，多个RBridge退出可能导致本地CE接收重复帧。此外，在AAE组中，由CE（例如CEi）发送的多目的地帧可由一个成员RBridge进入TRILL校园，并且另一成员RBridge随后将从TRILL校园接收该帧并将其出口到CEi；这将导致CEi帧的环回。[RFC7379]中描述了所有这些问题。
In the following subsections, the first two issues are discussed in Sections 5.1 and 5.2, respectively; the third issue is discussed in Section 5.3.
在以下小节中，前两个问题分别在第5.1节和第5.2节中讨论；第三个问题在第5.3节中讨论。
In TRILL, RBridges normally use distribution trees to forward multi-destination frames. (Under some circumstances, they can be unicast, as specified in [RFC7172].) An RPF check, along with other types of checks, is used to avoid temporary multicast loops during topology changes (Section 4.5.2 of [RFC6325]). The RPF check mechanism only accepts a multi-destination frame ingressed by an RBridge (say RBi) and forwarded on a distribution tree if it arrives at another RBridge (say RBn) on the expected port. If the frame arrives on any other port, the frame MUST be dropped.
在TRILL中，RBridges通常使用分布树转发多个目标帧。（根据[RFC7172]的规定，在某些情况下，它们可以是单播的。）RPF检查以及其他类型的检查用于避免拓扑更改期间出现临时多播循环（RFC6325的第4.5.2节）。RPF检查机制仅接受由RBridge（如RBi）进入并在分发树上转发的多目标帧，前提是该帧到达预期端口上的另一个RBridge（如RBn）。如果帧到达任何其他端口，则必须丢弃帧。
To avoid address flip-flopping on remote RBridges, member RBridges use the RBv's pseudo-nickname instead of their regular nicknames as the ingress nickname to ingress native frames, including multi-destination frames. From the view of other RBridges, these frames appear as if they were ingressed by the RBv. When multi-destination frames of different flows are ingressed by different member RBridges of an RBv and forwarded along the same distribution tree, they may arrive at RBn on different ports. Some of them will violate the RPF check principle at RBn and be dropped, which will result in lost traffic.
为了避免远程RBridge上的地址翻转，成员RBridge使用RBv的伪昵称而不是常规昵称作为入口本机帧（包括多目标帧）的入口昵称。从其他RBv桥的视图来看，这些帧似乎是RBv进入的。当RBv的不同成员RBv进入不同流的多个目的地帧并沿同一分发树转发时，它们可能到达不同端口上的RBn。其中一些将违反RBn的RPF检查原则并被丢弃，这将导致流量丢失。
In an RBv, if a different member RBridge uses different distribution trees to ingress multi-destination frames, the RPF check violation issue can be fixed. The Coordinated Multicast Trees (CMT) document [RFC7783] proposes such an approach and makes use of the Affinity sub-TLV defined in [RFC7176] to tell other RBridges which trees a member RBridge (say RBi) may choose when ingressing multi-destination frames; all RBridges in the TRILL campus can then calculate RPF check information for RBi on those trees, taking the tree affinity information into account [RFC7783].
在RBv中，如果不同的成员RBridge使用不同的分发树进入多目标帧，则可以修复RPF检查冲突问题。协调多播树（CMT）文档[RFC7783]提出了这样一种方法，并利用[RFC7176]中定义的亲和子TLV来告诉其他RBridge成员RBridge（例如RBi）在进入多个目的地帧时可以选择哪些树；然后，TRILL校园中的所有RBridge都可以计算这些树上RBi的RPF检查信息，并将树关联信息考虑在内[RFC7783]。
This document uses the approach proposed in [RFC7783] to fix the RPF check violation issue. Please refer to [RFC7783] for more details regarding this approach.
本文件使用[RFC7783]中提出的方法修复RPF检查违规问题。有关此方法的更多详细信息，请参阅[RFC7783]。
Take Figure 3 as an example, where CE1 and CE2 are served by an RBv that has RB1 and RB2 as member RBridges. In VLAN x, the three CEs can communicate with each other.
以图3为例，其中CE1和CE2由RBv提供服务，RBv将RB1和RB2作为成员RBv。在VLAN x中，三个CE可以相互通信。
---------------------
/ \ +-----+
| TRILL Campus |---| RBn |
\ / +-----+
-----------------------
| |
+----+ +------+
| |
+---------+ +--------+
| RB1 | | RB2 |
| oooooooo|oooooooooooooooo|ooooo |
+o--------+ RBv +-----o--+
o|oooo|oooooooooooooooooooo|o|o |
| +--|--------------------+ | |
| | +---------+ +----------+ |
(| |)<-LAALP1 (| |)<-LAALP2 |
+-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 |
+-------+ +-------+ +-------+
---------------------
/ \ +-----+
| TRILL Campus |---| RBn |
\ / +-----+
-----------------------
| |
+----+ +------+
| |
+---------+ +--------+
| RB1 | | RB2 |
| oooooooo|oooooooooooooooo|ooooo |
+o--------+ RBv +-----o--+
o|oooo|oooooooooooooooooooo|o|o |
| +--|--------------------+ | |
| | +---------+ +----------+ |
(| |)<-LAALP1 (| |)<-LAALP2 |
+-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 |
+-------+ +-------+ +-------+
Figure 3: A Topology with Multihomed and Single-Homed CEs
图3：具有多宿和单宿CEs的拓扑
When a remote RBridge (say RBn) sends a multi-destination TRILL Data packet in VLAN x (or the FGL that VLAN x maps to, if the packet is FGL), both RB1 and RB2 will receive it. As each of them thinks it is the Appointed Forwarder for VLAN x, without changes made for active-active connection support, they would both forward the frame to CE1/CE2. As a result, CE1/CE2 would receive duplicate copies of the frame through this RBv.
当远程RBridge（如RBn）在VLAN x（或VLAN x映射到的FGL，如果该数据包是FGL）中发送多目标TRILL数据包时，RB1和RB2都将接收该数据包。由于他们每个人都认为它是VLAN x的指定转发器，因此在不更改主动连接支持的情况下，他们都会将帧转发到CE1/CE2。因此，CE1/CE2将通过该RBv接收帧的副本。
In another case, assume that CE3 is single-homed to RB2. When it transmits a native multi-destination frame onto link CE3-RB2 in VLAN x, the frame can be locally replicated to the ports to CE1/CE2, and also encapsulated into TRILL Data packet and ingressed into the TRILL campus. When the packet arrives at RB1 across the TRILL campus, it will be egressed to CE1/CE2 by RB1. CE1/CE2 then receives duplicate copies from RB1 and RB2.
在另一种情况下，假设CE3是单宿RB2。当它将本机多目标帧传输到VLAN x中的链路CE3-RB2上时，该帧可以本地复制到CE1/CE2的端口，也可以封装到TRILL数据包中并进入TRILL园区。当数据包通过TRILL校园到达RB1时，它将由RB1出口到CE1/CE2。CE1/CE2然后从RB1和RB2接收副本。
In this document, the Designated Forwarder (DF) for a VLAN is introduced to avoid duplicate copies. The basic idea of the DF is to elect one RBridge per VLAN from an RBv to egress multi-destination TRILL Data traffic and replicate locally received multi-destination native frames to the CEs served by the RBv.
在本文档中，引入了VLAN的指定转发器（DF），以避免重复副本。DF的基本思想是从RBv中为每个VLAN选择一个RBridge，以退出多目的地TRILL数据流量，并将本地接收的多目的地本机帧复制到RBv服务的CE。
Note that the DF has an effect only on the egressing/replicating of multi-destination traffic. It has no effect on the ingressing, forwarding, or egressing of unicast frames. Furthermore, the DF check is performed only for RBv ports, not on regular access ports.
请注意，DF仅对多目的地流量的出口/复制产生影响。它对单播帧的进入、转发或退出没有影响。此外，DF检查仅对RBv端口执行，而不是在常规访问端口上执行。
Each RBridge in an RBv elects a DF using the same algorithm; this guarantees that, per VLAN, the same RBridge is elected as the DF by all members of the RBv.
RBv中的每个RBridge使用相同的算法选择DF；这保证了每个VLAN，RBv的所有成员都会选择相同的RBridge作为DF。
If we assume that there are m LAALPs and k member RBridges in an RBv, then (1) each LAALP is referred to as "LAALPi", where 0 <= i < m, and (2) each RBridge is referred to as "RBj", where 0 <= j < k. The DF election algorithm per VLAN is as follows:
如果我们假设RBv中有m个LAALP和k个成员RBridge，则（1）每个LAALP称为“LAALPi”，其中0<=i<m，（2）每个RBridge称为“RBj”，其中0<=j<k。每个VLAN的DF选择算法如下：
Step 1: For LAALPi, sort all the RBridges in numerically ascending order based on SHA-256(System IDj | LAALP IDi) considered to be an unsigned integer, where SHA-256 is the hash function specified in [RFC6234], "System IDj" is the 6-byte IS-IS System ID of RBj, "|" means concatenation, and "LAALP IDi" is the LAALP ID for LAALPi. The System ID and LAALP ID are considered to be byte strings. In the case of a tie, the tied RBridges are sorted in numerically ascending order by their System IDs considered to be unsigned integers.
步骤1：对于LAALPi，根据被认为是无符号整数的SHA-256（系统IDj | LAALP IDi），以数字升序对所有RBridge进行排序，其中SHA-256是[RFC6234]中指定的哈希函数，“系统IDj”是RBj的6字节is-is系统ID，“|”表示串联，“LAALP IDi”是LAALPi的LAALP ID。系统ID和LAALP ID被视为字节字符串。在tie的情况下，被绑定的rbridge按其被视为无符号整数的系统id按数字升序排序。
Step 2: Each RBridge in the numerically sorted list is assigned a monotonically increasing number j, such that increasing number j corresponds to its position in the sorted list, i.e., the first RBridge (the one with the smallest SHA-256(System ID | LAALP ID)) is assigned zero and the last is assigned k-1.
步骤2：数字排序列表中的每个RBridge被分配一个单调递增的数字j，使得递增的数字j对应于其在排序列表中的位置，即，第一个RBridge（具有最小SHA-256（系统ID | LAALP ID）的RBridge被分配为零，最后一个被分配为k-1。
Step 3: For each VLAN ID n, choose the RBridge whose number equals (n mod k) as the DF.
步骤3：对于每个VLAN ID n，选择其数量等于（n mod k）的RBridge作为DF。
Step 4: Repeat Steps 1-3 for the remaining LAALPs until there is a DF per VLAN per LAALP in the RBv.
步骤4：对其余LAALP重复步骤1-3，直到RBv中每个LAALP的每个VLAN都有DF。
For any multi-destination native frames of VLAN x that are received, if RBi is an LAALP attached RBridge, there are three cases where RBi replicates the multi-destination frame, as follows:
对于接收到的VLAN x的任何多目标本机帧，如果RBi是LAALP连接的RBridge，则RBi复制多目标帧的情况有三种，如下所示：
1) Local replication of the frame to regular (non-AAE) access ports as per [RFC6325] (and [RFC7172] for FGL).
1) 根据[RFC6325]（和[RFC7172]对FGL）将帧本地复制到常规（非AAE）访问端口。
2) RBv ports associated with the same pseudo-nickname as that of the incoming port, no matter whether RBi is the DF for the frame's VLAN on the outgoing ports, except that the frame MUST NOT be replicated back to the incoming port. RBi cannot simply depend on the DF to forward the multi-destination frame back into the AAEs associated with the pseudo-nickname, as that would cause the source CE to get the frame back, which is a violation of basic Ethernet properties. The DF will not forward such a frame back into the AAE due to ingress nickname filtering as described in Section 5.3.
2) RBv端口与传入端口的伪昵称相同，无论RBi是否是传出端口上帧VLAN的DF，但帧不得复制回传入端口。RBi不能简单地依赖DF将多目标帧转发回与伪昵称关联的AAE，因为这将导致源CE获取帧，这违反了基本以太网属性。由于第5.3节所述的入口昵称过滤，DF不会将这样的帧转发回AAE。
3) RBv ports on which RBi is the DF for the frame's VLAN while they are associated with different pseudo-nickname(s) than that of the incoming port.
3) RBv端口上的RBi是帧VLAN的DF，而它们与传入端口的伪昵称不同。
For any multi-destination TRILL Data packets that are received, RBi MUST NOT egress it out of the RBv ports where it is not the DF for the frame's Inner.VLAN (or for the VLAN corresponding to the Inner.Label if the packet is an FGL one). Otherwise, whether or not to egress it out of such ports is further subject to the filtering check result of the frame's ingress nickname on these ports (see Section 5.3).
对于接收到的任何多目标TRILL数据包，RBi不得将其从RBv端口流出，因为RBv端口不是帧的Inner.VLAN（或对应于Inner.Label的VLAN，如果该数据包是FGL）的DF。否则，是否将其从这些端口中退出将进一步取决于这些端口上帧的入口昵称的过滤检查结果（参见第5.3节）。
As shown in Figure 3, CE1 may send multi-destination traffic in VLAN x to the TRILL campus via a member RBridge (say RB1). The traffic is then TRILL-encapsulated by RB1 and delivered through the TRILL campus to multi-destination receivers. RB2 may receive the traffic and egress it back to CE1 if it is the DF for VLAN x on the port to LAALP1. The traffic then loops back to CE1 (see Section 3.2 of [RFC7379]).
如图3所示，CE1可以通过成员RBridge（比如RB1）将VLAN x中的多目的地流量发送到TRILL园区。然后，流量由RB1封装成TRILL，并通过TRILL园区传送到多个目的地接收器。如果RB2是LAALP1端口上VLAN x的DF，则RB2可以接收流量并将其返回CE1。然后，通信量返回CE1（见[RFC7379]第3.2节）。
To fix the above issue, this document requires an ingress nickname filtering check. The idea is to check the ingress nickname of a multi-destination TRILL Data packet before egressing a copy of it out of an RBv port. If the ingress nickname matches the pseudo-nickname of the RBv (associated with the port), the filtering check should fail and the copy MUST NOT be egressed out of that RBv port. Otherwise, the copy is egressed out of that port if it has also
要解决上述问题，此文档需要进行入口昵称筛选检查。其思想是在将多目标TRILL数据包的副本从RBv端口导出之前检查其入口昵称。如果入口昵称与RBv（与端口关联）的伪昵称匹配，则过滤检查应失败，且副本不得从该RBv端口流出。否则，副本将从该端口退出（如果它也已退出）
passed other checks, such as the Appointed Forwarder check described in Section 4.6.2.5 of [RFC6325] and the DF check described in Section 5.2.
通过其他检查，如[RFC6325]第4.6.2.5节所述的指定货运代理检查和第5.2节所述的DF检查。
Note that this ingress nickname filtering check has no effect on the multi-destination native frames that are received on access ports and replicated to other local ports (including RBv ports), since there is no ingress nickname associated with such frames. Furthermore, for the RBridge regular access ports, there is no pseudo-nickname associated with them, so no ingress nickname filtering check is required on those ports.
请注意，此入口昵称过滤检查对在访问端口上接收并复制到其他本地端口（包括RBv端口）的多目标本机帧没有影响，因为没有与此类帧相关联的入口昵称。此外，对于RBridge常规访问端口，没有与之关联的伪昵称，因此不需要对这些端口进行入口昵称过滤检查。
More details of data packet processing on RBv ports are given in the next section.
下一节将给出RBv端口上数据包处理的更多细节。
This section provides more details of native frame and TRILL Data packet processing as it relates to the RBv's pseudo-nickname.
本节提供了与RBv的伪昵称相关的本机帧和颤音数据包处理的更多细节。
When RB1 receives a unicast native frame from one of its ports that has end-station service enabled, it processes the frame as described in Section 4.6.1.1 of [RFC6325], with the following exception:
当RB1从其启用了端站服务的端口之一接收到单播本机帧时，它将按照[RFC6325]第4.6.1.1节所述处理该帧，但以下情况除外：
o If the port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame.
o 如果端口是RBv端口，则RB1在帧上进行颤音封装时使用RBv的伪昵称而不是其常规昵称之一作为入口昵称。
When RB1 receives a native multi-destination (broadcast, unknown unicast, or multicast) frame from one of its access ports (including regular access ports and RBv ports), it processes the frame as described in Section 4.6.1.2 of [RFC6325], with the following exceptions:
当RB1从其一个接入端口（包括常规接入端口和RBv端口）接收到本机多目的地（广播、未知单播或多播）帧时，它将按照[RFC6325]第4.6.1.2节所述处理该帧，但以下情况除外：
o If the incoming port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame.
o 如果传入端口是RBv端口，则RB1在帧上进行颤音封装时使用RBv的伪昵称而不是其常规昵称之一作为入口昵称。
o For the copies of the frame replicated locally to RBv ports, there are two cases, as follows:
o 对于本地复制到RBv端口的帧副本，有两种情况，如下所示：
- If the outgoing port(s) is associated with the same pseudo-nickname as that of the incoming port but not with the same LAALP as the incoming port, the copies are forwarded out of that outgoing port(s) after passing the Appointed Forwarder check for the frame's VLAN. That is to say, the copies are processed on such port(s), as discussed in Section 4.6.1.2 of [RFC6325].
- 如果传出端口与传入端口的伪昵称相同，但与传入端口的LAALP不同，则在通过帧VLAN的指定转发器检查后，副本将从该传出端口转发出去。也就是说，如[RFC6325]第4.6.1.2节所述，在此类端口上处理副本。
- Else, the Designated Forwarder (DF) check is also made on the outgoing ports for the frame's VLAN after the Appointed Forwarder check, and the copies are not output through any ports that failed the DF check (i.e., RB1 is not the DF for the frame's VLAN on the ports). Otherwise, the copies are forwarded out of the outgoing ports that pass both the Appointed Forwarder check and the DF check (see Section 5.2).
- 否则，指定转发器（DF）检查也在指定转发器检查后对帧VLAN的传出端口进行，并且副本不会通过DF检查失败的任何端口输出（即，RB1不是端口上帧VLAN的DF）。否则，副本将从通过指定转发器检查和DF检查的传出端口转发出去（见第5.2节）。
For any such frames received, the MAC address information learned by observing it, together with the LAALP ID of the incoming port, SHOULD be shared with other member RBridges in the group (see Section 7).
对于接收到的任何这样的帧，通过观察而获知的MAC地址信息以及传入端口的LAALP ID应与组中的其他成员RBridge共享（参见第7节）。
This section describes egress processing of the TRILL Data packets received on an RBv member RBridge (say RBn). Section 6.2.1 describes the egress processing of unicast TRILL Data packets, and Section 6.2.2 specifies the egressing of multi-destination TRILL Data packets.
本节描述在RBv成员RBridge（例如RBn）上接收的TRILL数据分组的出口处理。第6.2.1节描述了单播颤音数据包的出口处理，第6.2.2节规定了多目的地颤音数据包的出口。
When receiving a unicast TRILL Data packet, RBn checks the egress nickname in the TRILL Header of the packet. If the egress nickname is one of RBn's regular nicknames, the packet is processed as defined in Section 4.6.2.4 of [RFC6325].
当接收到单播TRILL数据包时，RBn检查该包TRILL报头中的出口昵称。如果出口昵称是RBn的常规昵称之一，则按照[RFC6325]第4.6.2.4节中的定义处理数据包。
If the egress nickname is the pseudo-nickname of a local RBv, RBn is responsible for learning the source MAC address, unless data-plane learning has been disabled. The learned {Inner.MacSA, Data Label, ingress nickname} triplet SHOULD be shared within the AAE group as described in Section 7.
如果出口昵称是本地RBv的伪昵称，RBn负责学习源MAC地址，除非已禁用数据平面学习。学习的{Inner.MacSA、数据标签、入口昵称}三元组应在AAE组内共享，如第7节所述。
The packet is then decapsulated to its native form. The Inner.MacDA and Data Label are looked up in RBn's local forwarding tables, and one of the three following cases will occur. RBn uses the first case that applies and ignores the remaining cases:
然后将数据包解封为其本机形式。在RBn的本地转发表中查找Inner.MacDA和数据标签，将出现以下三种情况之一。RBn使用适用的第一种情况并忽略其余情况：
o If the destination end station identified by the Inner.MacDA and Data Label is on a local link, the native frame is sent onto that link with the VLAN from the Inner.VLAN or VLAN corresponding to the Inner.Label if the packet is FGL.
o 如果由Inner.MacDA和数据标签标识的目标端站位于本地链路上，则本机帧将从Inner.VLAN或对应于Inner.Label的VLAN（如果数据包为FGL）发送到该链路上。
o Else if RBn can reach the destination through another member RBridge (say RBk), it tunnels the native frame to RBk by re-encapsulating it into a unicast TRILL Data packet and sends it to RBk. RBn uses RBk's regular nickname instead of the pseudo-nickname as the egress nickname for the re-encapsulation, and the ingress nickname remains unchanged (somewhat similar to Section 2.4.2.1 of [RFC7780]). If the Hop Count value of the packet is too small for it to reach RBk safely, RBn SHOULD increase that value properly in doing the re-encapsulation. (NOTE: When receiving that re-encapsulated TRILL Data packet, as the egress nickname of the packet is RBk's regular nickname rather than the pseudo-nickname of a local RBv, RBk will process it per Section 4.6.2.4 of [RFC6325] and will not re-forward it to another RBridge.)
o 否则，如果RBn可以通过另一个成员RBridge（比如RBk）到达目的地，它通过将本机帧重新封装到单播TRILL数据包并将其发送到RBk，从而将本机帧隧道到RBk。RBn使用RBk的常规昵称而不是伪昵称作为重新封装的出口昵称，入口昵称保持不变（与[RFC7780]第2.4.2.1节类似）。如果数据包的跃点计数值太小，无法安全到达RBk，RBn应在重新封装时适当增加该值。（注意：当接收到重新封装的TRILL数据包时，由于该数据包的出口昵称是RBk的常规昵称而不是本地RBv的伪昵称，RBk将根据[RFC6325]第4.6.2.4节对其进行处理，并且不会将其重新转发给另一个RBridge。）
o Else, RBn does not know how to reach the destination; it sends the native frame out of all the local ports on which it is Appointed Forwarder for the Inner.VLAN (or Appointed Forwarder for the VLAN into which the Inner.Label maps on that port for an FGL TRILL Data packet [RFC7172]).
o 否则，RBn不知道如何到达目的地；它从所有本地端口发送本机帧，在这些端口上，它被指定为Inner.VLAN的转发器（或指定为FGL TRILL数据包的Inner.Label映射到的VLAN的转发器[RFC7172]）。
When RB1 receives a multi-destination TRILL Data Packet, it checks and processes the packet as described in Section 4.6.2.5 of [RFC6325], with the following exception:
当RB1接收到多目的地TRILL数据包时，它会按照[RFC6325]第4.6.2.5节中的说明检查和处理该数据包，但以下情况除外：
o On each RBv port where RBn is the Appointed Forwarder for the packet's Inner.VLAN (or for the VLAN to which the packet's Inner.Label maps on that port if it is an FGL TRILL Data packet), the DF check (see Section 5.2) and the ingress nickname filtering check (see Section 5.3) are further performed. For such an RBv port, if either the DF check or the filtering check fails, the frame MUST NOT be egressed out of that port. Otherwise, it can be egressed out of that port.
o 在每个RBv端口上，RBn是数据包的Inner.VLAN（或数据包的Inner.Label映射到该端口的VLAN，如果是FGL TRILL数据包），将进一步执行DF检查（见第5.2节）和入口昵称过滤检查（见第5.3节）。对于这样的RBv端口，如果DF检查或过滤检查失败，则帧不得从该端口退出。否则，它可以从该端口中退出。
An edge RBridge, say RB1 in LAALP1, may have learned a correspondence between a {Data Label and MAC address} and nickname for a remote host (say h1) when h1 sends a packet to CE1. The returning traffic from CE1 may go to another member RBridge of LAALP1 (for example, RB2). RB2 may not have that correspondence stored. Therefore, it has to do the flooding for unknown unicast. Such flooding is unnecessary, since the returning traffic is almost always expected and RB1 had learned the address correspondence. To avoid the unnecessary flooding, RB1 SHOULD share the correspondence with other RBridges of LAALP1. RB1 synchronizes the correspondence by using the MAC-Reachability (MAC-RI) sub-TLV [RFC6165] in its ESADI-LSPs [RFC7357].
当h1向CE1发送数据包时，边缘RBridge，比如LAALP1中的RB1，可能已经学会了远程主机的{Data Label and MAC address}和昵称（比如h1）之间的对应关系。来自CE1的返回流量可能会到达LAALP1的另一个成员RBridge（例如，RB2）。RB2可能没有存储该通信。因此，必须对未知单播进行泛洪处理。这种泛洪是不必要的，因为返回的流量几乎总是预期的，并且RB1已经学会了地址通信。为避免不必要的洪水，RB1应与LAALP1的其他RBRIGE共享通信。RB1通过在其ESADI LSP[RFC7357]中使用MAC可达性（MAC-RI）子TLV[RFC6165]来同步通信。
On the other hand, RB2 has learned the MAC address and Data Label of CE1 when CE1 sends a frame to h1 through RB2. The returning traffic from h1 may go to RB1. RB1 may not have CE1's MAC address and Data Label stored even though it is in the same LAALP for CE1 as RB2. Therefore, it has to flood the traffic out of all its access ports where it is Appointed Forwarder for the VLAN (see Section 6.2.1) or the VLAN the FGL maps to on that port if the packet is FGL. Such flooding is unnecessary, since the returning traffic is almost always expected and RB2 had learned CE1's MAC and Data Label information. To avoid that unnecessary flooding, RB2 SHOULD share the MAC address and Data Label with other RBridges of LAALP1. RB2 synchronizes the MAC address and Data Label by enclosing the relative MAC-RI TLV within a pair of boundary TRILL APPsub-TLVs for LAALP1 (see Section 9.3) in its ESADI-LSP [RFC7357]. After receiving the enclosed MAC-RI TLVs, the member RBridges of LAALP1 (i.e., LAALP1 related RBridges) treat the MAC address and Data Label as if it were learned by them locally on their member port of LAALP1; the LAALP1 unrelated RBridges just ignore LAALP1's boundary APPsub-TLVs and treat the MAC address and Data Label as specified in [RFC7357]. Furthermore, in order to make the LAALP1 unrelated RBridges know that the MAC and Data Label are reachable through the RBv that provides service to LAALP1, the Topology-ID/Nickname field of the MAC-RI TLV SHOULD carry the pseudo-nickname of the RBv, rather than a zero value or one of the originating RBridge's (i.e., RB2's) regular nicknames.
另一方面，当CE1通过RB2向h1发送帧时，RB2已经学习了CE1的MAC地址和数据标签。从h1返回的流量可能会进入RB1。RB1可能没有存储CE1的MAC地址和数据标签，即使它与RB2位于CE1的LAALP中。因此，当它被指定为VLAN的转发器（参见第6.2.1节）或FGL映射到该端口上的VLAN（如果数据包是FGL）时，它必须将流量从其所有访问端口溢出。这种泛洪是不必要的，因为返回的流量几乎总是预期的，RB2已经了解了CE1的MAC和数据标签信息。为避免不必要的洪泛，RB2应与LAALP1的其他RBRIGE共享MAC地址和数据标签。RB2通过将相对MAC-RI TLV封装在其ESADI-LSP[RFC7357]中LAALP1（见第9.3节）的一对边界TRILL APPsub TLV内，从而同步MAC地址和数据标签。在接收到随附的MAC-RI TLV后，LAALP1的成员RBridge（即，与LAALP1相关的RBridge）将MAC地址和数据标签视为它们在其LAALP1的成员端口上本地学习到的；LAALP1不相关的RBridge只忽略LAALP1的边界APPsub TLV，并按照[RFC7357]中的规定处理MAC地址和数据标签。此外，为了使LAALP1无关的RBridge知道MAC和数据标签可通过向LAALP1提供服务的RBv到达，MAC-RI TLV的拓扑ID/昵称字段应携带RBv的伪昵称，而不是零值或原始RBridge的（即，RB2）常规昵称之一。
As shown in Figure 4, suppose that the link RB1-CE1 fails. Although a new RBv will be formed by RB2 and RB3 to provide active-active service for LAALP1 (see Section 5), the unicast traffic to CE1 might still be forwarded to RB1 before the remote RBridge learns that CE1 is attached to the new RBv. That traffic might be disrupted by the link failure. Section 8.1 discusses failure protection in this scenario.
如图4所示，假设链路RB1-CE1出现故障。尽管新的RBv将由RB2和RB3组成，为LAALP1提供主动服务（参见第5节），但在远程RBridge得知CE1连接到新RBv之前，到CE1的单播通信量仍可能转发到RB1。该流量可能会因链路故障而中断。第8.1节讨论了这种情况下的故障保护。
However, multi-destination TRILL Data packets can reach all member RBridges of the new RBv and be egressed to CE1 by either RB2 or RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the packet's Inner.Label maps to in the new RBv). Although there might be a transient hang time between failure and the establishment of the new RBv, special actions to protect against downlink failure for such multi-destination packets are not needed.
然而，多目的地TRILL数据包可以到达新RBv的所有成员RBridge，并通过RB2或RB3（即，新流量的Inner.VLAN的新DF或包的Inner.Label映射到新RBv中的VLAN）出口到CE1。尽管在故障和建立新的RBv之间可能存在暂时的挂起时间，但是不需要针对此类多目的地分组的下行链路故障采取特殊措施。
------------------
/ \
| TRILL Campus |
\ /
--------------------
| | |
+---+ | +----+
| | |
+------+ +------+ +------+
| RB1 | | RB2 | | RB3 |
ooooooo|ooooo|oooooo|ooo|ooooo |
o+------+ RBv +------+ +-----o+
o|oooo|ooooooo|oooo|ooooo|oo|o
| | | +-|-----+ |
\|/+--|-------+ | +------+ |
- B | +----------|------+ | |
/|\| +-----------+ | | |
(| | |)<--LAALP1 (| | |)<--LAALP2
+-------+ +-------+
| CE1 | | CE2 |
+-------+ +-------+
------------------
/ \
| TRILL Campus |
\ /
--------------------
| | |
+---+ | +----+
| | |
+------+ +------+ +------+
| RB1 | | RB2 | | RB3 |
ooooooo|ooooo|oooooo|ooo|ooooo |
o+------+ RBv +------+ +-----o+
o|oooo|ooooooo|oooo|ooooo|oo|o
| | | +-|-----+ |
\|/+--|-------+ | +------+ |
- B | +----------|------+ | |
/|\| +-----------+ | | |
(| | |)<--LAALP1 (| | |)<--LAALP2
+-------+ +-------+
| CE1 | | CE2 |
+-------+ +-------+
B - Failed Link or Link Bundle
B-失败的链接或链接束
Figure 4: A Multi-Homed CE with a Failed Link
图4：链接失败的多宿CE
When the link CE1-RB1 fails, RB1 loses its direct connection to CE1. The MAC entry through the failed link to CE1 is removed from RB1's local forwarding table immediately. Another MAC entry learned from another member RBridge of LAALP1 (for example, RB2, since it is still a member RBridge of LAALP1) is installed into RB1's forwarding table (see Section 9.3). In that new entry, RB2 (identified by one of its regular nicknames) is the egress RBridge for CE1's MAC address. Then, when a TRILL Data packet to CE1 is delivered to RB1, it can be tunneled to RB2 after being re-encapsulated (the ingress nickname remains unchanged and the egress nickname is replaced by RB2's regular nickname) based on the above installed MAC entry (see bullet 2 in Section 6.2.1). RB2 then receives the frame and egresses it to CE1.
当链路CE1-RB1发生故障时，RB1将失去与CE1的直接连接。通过到CE1的失败链接的MAC条目立即从RB1的本地转发表中删除。另一个从LAALP1的另一个成员RBridge（例如，RB2，因为它仍然是LAALP1的成员RBridge）学到的MAC条目被安装到RB1的转发表中（参见第9.3节）。在这个新条目中，RB2（由它的一个常规昵称标识）是CE1 MAC地址的出口RBridge。然后，当发送到CE1的TRILL数据包被发送到RB1时，可以基于上述安装的MAC条目（见第6.2.1节中的项目符号2）在重新封装（入口昵称保持不变，出口昵称替换为RB2的常规昵称）后将其隧道到RB2。RB2然后接收帧并将其输出到CE1。
After failure recovery, RB1 learns that it can reach CE1 via link CE1-RB1 again by observing CE1's native frames or from the MAC information synchronization by member RBridge(s) of LAALP1 as described in Section 7. It then restores the MAC entry to its previous one and downloads it to its data-plane "fast path" logic.
故障恢复后，RB1通过观察CE1的本机帧或通过LAALP1的成员RBridge的MAC信息同步（如第7节所述），得知其可以通过链路CE1-RB1再次到达CE1。然后，它将MAC条目恢复到以前的条目，并将其下载到其数据平面“快速路径”逻辑中。
The following subsections specify the APPsub-TLVs needed to support pseudo-nickname edge groups.
以下小节指定了支持伪昵称边缘组所需的APPsub TLV。
This APPsub-TLV is used by an edge RBridge to announce its associated pseudo-nickname LAALP information. It is defined as a sub-TLV of the TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs [RFC7780]. It has the following format:
边缘RBridge使用此APPsub TLV来宣布其关联的伪昵称LAALP信息。它被定义为TRILL GENINFO TLV[RFC7357]的子TLV，分布在E-L1FS LSP[RFC7780]中。其格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-LAALP-Membership | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-LAALP-Membership | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Figure 5: PN-LAALP-Membership Advertisement APPsub-TLV
图5:PN LAALP会员广告APPsub TLV
where each LAALP RECORD has the following form:
其中每个LAALP记录具有以下格式：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 ..
+--+-+-+-+-+-+-+-+
|OE| RESV | (1 byte)
+--+-+-+-+-+-+-+-+
| Size | (1 byte)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reusing Pseudo-Nickname | (2 bytes)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID | (variable)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 ..
+--+-+-+-+-+-+-+-+
|OE| RESV | (1 byte)
+--+-+-+-+-+-+-+-+
| Size | (1 byte)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reusing Pseudo-Nickname | (2 bytes)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID | (variable)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
o PN-LAALP-Membership (2 bytes): Defines the type of this sub-TLV, 2.
o PN LAALP成员资格（2字节）：定义此子TLV的类型，2。
o Length (2 bytes): The sum of the lengths of the LAALP RECORDs.
o 长度（2字节）：LAALP记录的长度总和。
o OE (1 bit): A flag indicating whether or not the LAALP wants to occupy an RBv by itself; 1 for occupying by itself (or Occupying Exclusively (OE)). By default, it is set to 0 on transmit. This bit is used for edge RBridge group auto-discovery (see Section 4.1). For any one LAALP, the values of this flag might conflict in the LSPs advertised by different member RBridges of that LAALP. In that case, the flag for that LAALP is considered to be 1.
o OE（1位）：指示LAALP是否希望自己占用RBv的标志；1自行占用（或独家占用（OE））。默认情况下，它在传输时设置为0。该位用于边缘RBridge组自动发现（见第4.1节）。对于任何一个LAALP，该标志的值可能与该LAALP的不同成员发布的LSP中的值冲突。在这种情况下，该LAALP的标志被认为是1。
o RESV (7 bits): MUST be transmitted as zero and ignored on receipt.
o RESV（7位）：必须作为零传输，并在接收时忽略。
o Size (1 byte): Size of the remaining part of the LAALP RECORD (2 plus the length of the LAALP ID).
o 大小（1字节）：LAALP记录剩余部分的大小（2加上LAALP ID的长度）。
o Reusing Pseudo-Nickname (2 bytes): Suggested pseudo-nickname of the AAE group serving the LAALP. If the LAALP is not served by any AAE group, this field MUST be set to zero. It is used by the originating RBridge to help the vDRB to reuse the previous pseudo-nickname of an AAE group (see Section 4.2).
o 重用伪昵称（2字节）：为LAALP服务的AAE组的建议伪昵称。如果LAALP未由任何AAE组提供服务，则此字段必须设置为零。原始RBridge使用它来帮助vDRB重用AAE组以前的伪昵称（参见第4.2节）。
o LAALP ID (variable): The ID of the LAALP. See Section 9.4.
o LAALP ID（变量）：LAALP的ID。见第9.4节。
On receipt of such an APPsub-TLV, if RBn is not an LAALP related edge RBridge, it ignores the sub-TLV; otherwise, it parses the sub-TLV. When new LAALPs are found or old ones are withdrawn compared to its old copy, and they are also configured on RBn, RBn performs the "Member RBridges Auto-Discovery" procedure described in Section 4.
收到此类APPsub TLV后，如果RBn不是LAALP相关的边缘RBridge，则忽略子TLV；否则，它将解析子TLV。当发现新的LAALP或旧的LAALP与其旧副本相比被撤回时，并且它们也在RBn上配置，RBn执行第4节中描述的“成员RBRIGES自动发现”程序。
The PN-RBv APPsub-TLV is used by a Designated RBridge of a virtual RBridge (vDRB) to dictate the pseudo-nickname for the LAALPs served by the RBv. It is defined as a sub-TLV of the TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs [RFC7780]. It has the following format:
PN RBv APPsub TLV由虚拟RBridge（vDRB）的指定RBridge用于为RBv服务的LAALPs口述伪昵称。它被定义为TRILL GENINFO TLV[RFC7357]的子TLV，分布在E-L1FS LSP[RFC7780]中。其格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-RBv | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBv's Pseudo-Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-RBv | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBv's Pseudo-Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
o PN-RBv (2 bytes): Defines the type of this sub-TLV, 3.
o PN RBv（2字节）：定义此子TLV的类型，3。
o Length (2 bytes): 3+n*k bytes, where there are n LAALP IDs, each of size k bytes. k is found in the LAALP ID Size field below. If Length is not 3 plus an integer times k, the sub-TLV is corrupt and MUST be ignored.
o 长度（2字节）：3+n*k字节，其中有n个LAALP ID，每个大小为k字节。k位于下面的LAALP ID大小字段中。如果长度不是3加上整数乘以k，则子TLV已损坏，必须忽略。
o RBv's Pseudo-Nickname (2 bytes): The appointed pseudo-nickname for the RBv that serves the LAALPs listed in the following fields.
o RBv的伪昵称（2字节）：为以下字段中列出的LAALPs服务的RBv指定的伪昵称。
o LAALP ID Size (1 byte): The size of each of the following LAALP IDs in this sub-TLV. 8 if the LAALPs listed are MC-LAGs or DRNI (Section 6.3.2 of [802.1AX]). The value in this field is the k value that appears in the formula for Length above.
o LAALP ID大小（1字节）：此子TLV中以下每个LAALP ID的大小。8如果列出的LAALP是MC LAG或DRNI（802.1AX第6.3.2节）。此字段中的值是出现在上述长度公式中的k值。
o LAALP ID (LAALP ID Size bytes): The ID of the LAALP. See Section 9.4.
o LAALP ID（LAALP ID大小字节）：LAALP的ID。见第9.4节。
This sub-TLV may occur multiple times with the same RBv pseudo-nickname; this means that all of the LAALPs listed are identified by that pseudo-nickname. For example, if there are LAALP IDs of different length, then the LAALP IDs of each size would have to be listed in a separate sub-TLV.
该子TLV可能使用同一RBv伪昵称出现多次；这意味着列出的所有LAALPs都是由这个伪昵称标识的。例如，如果存在不同长度的LAALP ID，则必须在单独的子TLV中列出每个大小的LAALP ID。
Because a PN-RBv APPsub-TLV is distributed as part of the application link state by using the E-L1FS FS-LSP [RFC7780], creation, changes to contents, or withdrawal of a PN-RBv APPsub-TLV is accomplished by the Designated RBridge updating and flooding an E-L1FS PDU.
由于PN RBv APPsub TLV是通过使用E-L1FS FS-LSP[RFC7780]作为应用程序链路状态的一部分分发的，因此PN RBv APPsub TLV的创建、内容更改或撤回是通过指定的RBridge更新和泛洪E-L1FS PDU来完成的。
On receipt of such a sub-TLV, if RBn is not an LAALP related edge RBridge, it ignores the sub-TLV. Otherwise, if RBn is also a member RBridge of the RBv identified by the list of LAALPs, it associates the pseudo-nickname with the ports of these LAALPs and downloads the association to data-plane fast path logic. At the same time, RBn claims the RBv's pseudo-nickname across the campus and announces the RBv as its child on the corresponding tree or trees using the Affinity sub-TLV [RFC7176] [RFC7783].
收到此类子TLV后，如果RBn不是LAALP相关边缘RBridge，则忽略子TLV。否则，如果RBn也是由LAALP列表标识的RBv的成员RBridge，则它将伪昵称与这些LAALP的端口相关联，并将关联下载到数据平面快速路径逻辑。同时，RBn在校园内声称RBv的伪昵称，并使用关联子TLV[RFC7176][RFC7783]在相应的树上宣布RBv为其子树。
In this document, two APPsub-TLVs are used as boundary APPsub-TLVs for an edge RBridge to enclose the MAC-RI TLV(s) containing the MAC address information learned from the local port of an LAALP when this RBridge wants to share the information with other edge RBridges. They are defined as TRILL APPsub-TLVs [RFC7357]. The PN-MAC-RI-LAALP-INFO-START APPsub-TLV has the following format:
在本文档中，两个APPsub TLV用作边缘RBridge的边界APPsub TLV，用于封闭MAC-RI TLV，其中包含当此RBridge希望与其他边缘RBridge共享信息时从LAALP的本地端口学习到的MAC地址信息。它们被定义为TRILL APPsub TLV[RFC7357]。PN-MAC-RI-LAALP-INFO-START APPsub TLV具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=PN-MAC-RI-LAALP-INFO-START| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
| LAALP ID | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=PN-MAC-RI-LAALP-INFO-START| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
| LAALP ID | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
o PN-MAC-RI-LAALP-INFO-START (2 bytes): Defines the type of this sub-TLV, 4.
o PN-MAC-RI-LAALP-INFO-START（2字节）：定义此子TLV的类型，4。
o Length (2 bytes): The size of the following LAALP ID. 8 if the LAALP listed is an MC-LAG or DRNI.
o 长度（2字节）：如果列出的LAALP是MC-LAG或DRNI，则以下LAALP ID.8的大小。
o LAALP ID (variable): The ID of the LAALP (see Section 9.4).
o LAALP ID（变量）：LAALP的ID（见第9.4节）。
The PN-MAC-RI-LAALP-INFO-END APPsub-TLV is defined as follows:
PN-MAC-RI-LAALP-INFO-END APPsub TLV定义如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PN-MAC-RI-LAALP-INFO-END | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PN-MAC-RI-LAALP-INFO-END | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o PN-MAC-RI-LAALP-INFO-END (2 bytes): Defines the type of this sub-TLV, 5.
o PN-MAC-RI-LAALP-INFO-END（2字节）：定义此子TLV的类型，5。
o Length (2 bytes): 0.
o 长度（2字节）：0。
This pair of APPsub-TLVs can be carried multiple times in an ESADI-LSP and in multiple ESADI-LSPs. When an LAALP related edge RBridge (say RBn) wants to share with other edge RBridges the MAC addresses learned on its local ports of different LAALPs, it uses one or more pairs of such APPsub-TLVs for each such LAALP in its ESADI-LSPs. Each encloses the MAC-RI TLVs containing the MAC addresses learned from a specific LAALP. Furthermore, if the LAALP is served by a local RBv, the value of the Topology-ID/Nickname field in the relative MAC-RI TLVs SHOULD be the pseudo-nickname of the RBv, rather than one of RBn's regular nicknames or a zero value. Then, on receipt of such a MAC-RI TLV, remote RBridges know that the contained MAC addresses are reachable through the RBv.
这对APPsub TLV可在一个ESADI-LSP和多个ESADI LSP中多次携带。当与LAALP相关的边缘RBridge（比如RBn）想要与其他边缘RBridge共享在其不同LAALP的本地端口上学习到的MAC地址时，它在其ESADI LSP中为每个这样的LAALP使用一对或多对这样的APPsub TLV。每个都包含MAC-RI TLV，其中包含从特定LAALP学习的MAC地址。此外，如果LAALP由本地RBv服务，则相对MAC-RI TLV中的拓扑ID/昵称字段的值应该是RBv的伪昵称，而不是RBn的常规昵称之一或零值。然后，在接收到这样的MAC-RI TLV时，远程RBv知道所包含的MAC地址可以通过RBv访问。
On receipt of such boundary APPsub-TLVs, when the edge RBridge is not an LAALP related one or cannot recognize such sub-TLVs, it ignores them and continues to parse the enclosed MAC-RI TLVs per [RFC7357]. Otherwise, the recipient parses the boundary APPsub-TLVs. The PN-MAC-RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-END pair MUST occur within one TRILL GENINFO TLV. If an END is encountered without any previous START in the ESADI-LSP, the END APPsub-TLV is ignored. After encountering a START, if the end of the ESADI-LSP is reached without encountering an END, then the end of the ESADI-LSP is treated as if it were a PN-MAC-RI-LAALP-INFO-END. The boundary APPsub-TLVs and TLVs between them are handled as follows:
收到此类边界APPsub TLV后，当边缘RBridge不是LAALP相关的TLV或无法识别此类子TLV时，它将忽略这些TLV，并根据[RFC7357]继续解析封闭的MAC-RI TLV。否则，接收方将解析边界APPsub TLV。PN-MAC-RI-LAALP-INFO-START/PN-MAC-RI-LAALP-INFO-END对必须出现在一个TRILL GENINFO TLV内。如果遇到ESADI-LSP中没有任何先前启动的END，则忽略END APPsub TLV。遇到开始后，如果到达ESADI-LSP的结束时未遇到结束，则ESADI-LSP的结束将被视为PN-MAC-RI-LAALP-INFO-end。边界APPsub TLV和它们之间的TLV处理如下：
1) If the edge RBridge is configured with the contained LAALP and the LAALP is also enabled locally, it treats all the MAC addresses contained in the following MC-RI TLVs enclosed by the corresponding pair of boundary APPsub-TLVs as if they were learned from its local port of that LAALP;
1) 如果边缘RBridge配置了包含的LAALP，并且LAALP也在本地启用，则它将以下MC-RI TLV中包含的所有MAC地址（由相应的边界APPsub TLV对包围）视为是从该LAALP的本地端口学习的；
2) Else, it ignores these boundary APPsub-TLVs and continues to parse the following MAC-RI TLVs per [RFC7357] until another pair of boundary APPsub-TLVs is encountered.
2) 否则，它将忽略这些边界APPsub TLV，并根据[RFC7357]继续解析以下MAC-RI TLV，直到遇到另一对边界APPsub TLV。
The LAALP ID identifies an AAE RBridge group in the TRILL campus and thus MUST be unique across the campus. In all of the APPsub-TLVs specified above, the length of the LAALP ID can be determined from a size field. If that length is 8 bytes, the LAALP ID is an MC-LAG or DRNI identifier as specified in Section 6.3.2 of [802.1AX]. The meaning and structure of LAALP IDs of other lengths are reserved and may be specified in future documents.
LAALP ID标识TRILL校园中的AAE RBridge组，因此在整个校园中必须是唯一的。在上面指定的所有APPsub TLV中，LAALP ID的长度可以通过大小字段确定。如果该长度为8字节，则LAALP ID为[802.1AX]第6.3.2节中规定的MC-LAG或DRNI标识符。保留其他长度的LAALP ID的含义和结构，并可能在未来的文件中规定。
Attention must be paid when generating Operations, Administration, and Maintenance (OAM) packets. To ensure that the response messages can return to the originating member RBridge of an RBv, a pseudo-nickname cannot be used as the ingress nickname in TRILL OAM messages, except in the response to an OAM message that has that RBv's pseudo-nickname as the egress nickname. For example, assume that RB1 is a member RBridge of RBvi. RB1 cannot use RBvi's pseudo-nickname as the ingress nickname when originating OAM messages; otherwise, the responses to the messages may be delivered to another member RBridge of RBvi rather than RB1. But when RB1 responds to the OAM message with RBvi's pseudo-nickname as the egress nickname, it can use that pseudo-nickname as the ingress nickname in the response message.
生成操作、管理和维护（OAM）数据包时必须注意。为了确保响应消息可以返回到RBv的原始成员RBridge，伪昵称不能用作TRILL OAM消息中的入口昵称，除非在对将该RBv的伪昵称用作出口昵称的OAM消息的响应中。例如，假设RB1是RBvi的成员RBridge。RB1在发起OAM消息时不能使用RBvi的伪昵称作为入口昵称；否则，对消息的响应可以传递给RBvi的另一成员RBridge而不是RB1。但是，当RB1以RBvi的伪昵称作为出口昵称响应OAM消息时，它可以使用该伪昵称作为响应消息中的入口昵称。
Since RBridges cannot use OAM messages for the learning of MAC addresses (Section 3.2.1 of [RFC7174]), it will not lead to MAC address flip-flopping at a remote RBridge, even though RB1 uses its regular nicknames as ingress nicknames in its TRILL OAM messages, and at the same time RB1 uses RBvi's pseudo-nickname in its TRILL Data packets.
由于RBridges不能使用OAM消息来学习MAC地址（RFC7174的第3.2.1节），因此不会导致远程RBridge的MAC地址翻转，即使RB1在TRILL OAM消息中使用其常规昵称作为入口昵称，同时RB1在TRILL数据包中使用RBvi的伪昵称。
The VLAN membership of all the RBridge ports in an LAALP MUST be the same. Any inconsistencies in VLAN membership may result in packet loss or non-shortest paths.
LAALP中所有RBridge端口的VLAN成员身份必须相同。VLAN成员资格中的任何不一致都可能导致数据包丢失或非最短路径。
Take Figure 1 as an example. Suppose that RB1 configures VLAN1 and VLAN2 for the CE1-RB1 link, while RB2 only configures VLAN1 for the CE1-RB2 link. Both RB1 and RB2 use the same ingress nickname RBv for all frames originating from CE1. Hence, a remote RBridge (say RBx) will learn that CE1's MAC address in VLAN2 is originating from the RBv. As a result, on the return path, RBx may deliver VLAN2 traffic to RB2. However, RB2 does not have VLAN2 configured on the CE1-RB2 link, and hence the frame may be dropped or has to be redirected to RB1 if RB2 knows that RB1 can reach CE1 in VLAN2.
以图1为例。假设RB1为CE1-RB1链路配置VLAN1和VLAN2，而RB2仅为CE1-RB2链路配置VLAN1。对于源自CE1的所有帧，RB1和RB2都使用相同的入口昵称RBv。因此，远程RBridge（比如RBx）将知道VLAN2中CE1的MAC地址来自RBv。因此，在返回路径上，RBx可以向RB2提供VLAN2流量。但是，RB2没有在CE1-RB2链路上配置VLAN2，因此，如果RB2知道RB1可以到达VLAN2中的CE1，帧可能会被丢弃或必须重定向到RB1。
How LAALP implementations maintain consistent VLAN configuration on the TRILL switch LAALP ports is out of scope for the TRILL protocol. However, considering the consequences that might be caused by inconsistencies, TRILL switches MUST disable the ports connected to an LAALP with an inconsistent VLAN configuration.
LAALP实现如何在TRILL交换机LAALP端口上保持一致的VLAN配置超出了TRILL协议的范围。但是，考虑到不一致可能导致的后果，TRILL交换机必须禁用连接到VLAN配置不一致的LAALP的端口。
It is important that if any VLAN in an LAALP is being mapped by edge RBridges to an FGL [RFC7172] the mapping MUST be the same for all edge RBridge ports in the LAALP. Otherwise, for example, unicast FGL TRILL Data packets from remote RBridges may get mapped into different VLANs, depending on which edge RBridge receives and egresses them.
重要的是，如果LAALP中的任何VLAN由边缘RBridge映射到FGL[RFC7172]，则LAALP中所有边缘RBridge端口的映射必须相同。否则，例如，来自远程RBridge的单播FGL TRILL数据包可能被映射到不同的vlan，这取决于RBridge接收和离开它们的边缘。
It is important that RBridges in an AAE group not be configured to assert the OE-flag if any RBridge in the group does not implement it. Since, as stated in [RFC7379], the RBridges in an AAE edge group are expected to be from the same vendor, due to the proprietary nature of deployed LAALPs, this will normally follow automatically from all of the RBridges in an AAE edge group supporting, or not supporting, OE.
重要的是，如果AAE组中的任何RBridge未实现OE标志，则不要将该组中的RBridge配置为断言OE标志。由于[RFC7379]中所述，AAE边缘组中的RBridge预计来自同一供应商，由于部署的LAALPs的专有性质，这通常会自动从支持或不支持OE的AAE边缘组中的所有RBridge开始。
Authenticity for contents transported in IS-IS PDUs is enforced using regular IS-IS security mechanisms [IS-IS] [RFC5310].
使用常规IS-IS安全机制[IS-IS][RFC5310]强制IS-IS PDU中传输内容的真实性。
For security considerations pertaining to extensions transported by TRILL ESADI, see the Security Considerations section in [RFC7357].
有关TRILL ESADI传输的扩展的安全注意事项，请参阅[RFC7357]中的安全注意事项部分。
Since currently deployed LAALPs [RFC7379] are proprietary, security over membership in, and internal management of, active-active edge groups is proprietary. If authentication is not used, a rogue RBridge that insinuates itself into an active-active edge group can disrupt end-station traffic flowing into or out of that group. For example, if there are N RBridges in the group, it could typically control 1/Nth of the traffic flowing out of that group and a similar amount of unicast traffic flowing into that group. For multi-destination traffic flowing into that group, it could control all that was in a VLAN for which it was the DF and can exercise substantial control over the DF election by changing its own System ID.
由于当前部署的LAALP[RFC7379]是专有的，因此活动边缘组的成员身份和内部管理的安全性是专有的。如果未使用身份验证，将自身暗示为活动边缘组的恶意RBridge可能会中断流入或流出该组的端站流量。例如，如果组中有N个rbridge，则它通常可以控制流出该组的1/N的通信量和流入该组的类似数量的单播通信量。对于流入该组的多目的地流量，它可以控制作为DF的VLAN中的所有内容，并且可以通过更改自己的系统ID对DF选择进行实质性控制。
For general TRILL security considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
IANA has allocated four code points from the range below 255 for the four TRILL APPsub-TLVs specified in Section 9 and added them to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry, as follows:
IANA为第9节规定的四个TRILL APPsub TLV分配了255以下范围内的四个代码点，并将其添加到“IS-IS TLV 251应用标识符1下的TRILL APPsub TLV类型”注册表中，如下所示：
Type Name Reference
---- -------------------------- ---------
2 PN-LAALP-Membership RFC 7781
3 PN-RBv RFC 7781
4 PN-MAC-RI-LAALP-INFO-START RFC 7781
5 PN-MAC-RI-LAALP-INFO-END RFC 7781
Type Name Reference
---- -------------------------- ---------
2 PN-LAALP-Membership RFC 7781
3 PN-RBv RFC 7781
4 PN-MAC-RI-LAALP-INFO-START RFC 7781
5 PN-MAC-RI-LAALP-INFO-END RFC 7781
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014.
[802.1AX]IEEE，“局域网和城域网的IEEE标准-链路聚合”，IEEE标准802.1AX-2014，DOI 10.1109/IEEESTD.2014.7055197，2014年12月。
[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>.
[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>.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 6165，DOI 10.17487/RFC6165，2011年4月<http://www.rfc-editor.org/info/rfc6165>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[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>.
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 6439，DOI 10.17487/RFC6439，2011年11月<http://www.rfc-editor.org/info/rfc6439>.
[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>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<http://www.rfc-editor.org/info/rfc7356>.
[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>.
[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, <http://www.rfc-editor.org/info/rfc7783>.
[RFC7783]Senevirathne，T.，Pathangi，J.，和J.Hudson，“用于大量链路（TRILL）透明互连的协调多播树（CMT）”，RFC 7783，DOI 10.17487/RFC7783，2016年2月<http://www.rfc-editor.org/info/rfc7783>.
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国际标准化组织，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，ISO/IEC 10589:2002，第二版，2002年11月。
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>.
[RFC7174]Salam，S.，Senevirathne，T.，Aldrin，S.，和D.Eastlake 3rd，“大量链路的透明互连（TRILL）运营、管理和维护（OAM）框架”，RFC 7174，DOI 10.17487/RFC7174，2014年5月<http://www.rfc-editor.org/info/rfc7174>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7379>.
[RFC7782] Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments", RFC 7782, DOI 10.17487/RFC7782, February 2016, <http://www.rfc-editor.org/info/rfc7782>.
[RFC7782]Zhang，M.，Perlman，R.，翟，H.，Durrani，M.，和S.Gupta，“使用多个MAC附件的大量链路（TRILL）活动边缘的透明互连”，RFC 7782，DOI 10.17487/RFC7782，2016年2月<http://www.rfc-editor.org/info/rfc7782>.
Acknowledgments
致谢
We would like to thank Mingjiang Chen for his contributions to this document. Additionally, we would like to thank Erik Nordmark, Les Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan Pathangi, Jon Hudson, and Fangwei Hu for their good questions and comments.
我们要感谢陈明江对本文件的贡献。此外，我们还要感谢Erik Nordmark、Les Ginsberg、Ayan Banerjee、Dinesh Dutt、Anoop Ghanwani、Janardhanan Pathangi、Jon Hudson和方伟Hu提出的良好问题和评论。
Contributors
贡献者
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
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States
Donald E.Eastlake第三华为技术有限公司美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Authors' Addresses
作者地址
Hongjun Zhai Jinling Institute of Technology 99 Hongjing Avenue, Jiangning District Nanjing, Jiangsu 211169 China
中国江苏省南京市江宁区红井大道99号翟鸿钧金陵理工学院211169
Email: honjun.zhai@tom.com
Email: honjun.zhai@tom.com
Tissa Senevirathne Consultant
Tissa Senevirathne顾问公司
Email: tsenevir@gmail.com
Email: tsenevir@gmail.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States
Radia Perlman EMC 2010美国华盛顿州贝尔维尤市东北第256大道200号，邮编：98007
Email: Radia@alum.mit.edu
Email: Radia@alum.mit.edu
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China
中国北京市海淀区北青路156号华为技术有限公司张明贵100095
Email: zhangmingui@huawei.com
Email: zhangmingui@huawei.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
宜州利华为技术有限公司软件大道101号南京210012
Phone: +86-25-56625409
Email: liyizhou@huawei.com
Phone: +86-25-56625409
Email: liyizhou@huawei.com