Internet Engineering Task Force (IETF) Y. Li
Request for Comments: 7379 W. Hao
Category: Informational Huawei Technologies
ISSN: 2070-1721 R. Perlman
EMC
J. Hudson
Brocade
H. Zhai
JIT
October 2014
Internet Engineering Task Force (IETF) Y. Li
Request for Comments: 7379 W. Hao
Category: Informational Huawei Technologies
ISSN: 2070-1721 R. Perlman
EMC
J. Hudson
Brocade
H. Zhai
JIT
October 2014
Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge
大量链路透明互连（TRILL）边缘的主动连接问题陈述和目标
Abstract
摘要
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.
IETF TRILL（大量链路的透明互连）协议支持流级多路径，并在具有任意拓扑结构的网络中对单播和多目标流量进行快速故障切换。TRILL边缘的主动连接是这些特征的延伸，延伸到与TRILL校园多重连接的终端站。本信息性文档讨论在TRILL边缘提供活动连接时的高级问题和目标。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7379.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7379.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Target Scenario .................................................4
2.1. LAALP and Edge Group Characteristics .......................6
3. Problems in Active-Active Connection at the TRILL Edge ..........7
3.1. Frame Duplications .........................................7
3.2. Loopback ...................................................8
3.3. Address Flip-Flop ..........................................8
3.4. Unsynchronized Information among Member RBridges ...........8
4. High-Level Requirements and Goals for Solutions .................9
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Acknowledgments ...................................................12
Authors' Addresses ................................................13
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Target Scenario .................................................4
2.1. LAALP and Edge Group Characteristics .......................6
3. Problems in Active-Active Connection at the TRILL Edge ..........7
3.1. Frame Duplications .........................................7
3.2. Loopback ...................................................8
3.3. Address Flip-Flop ..........................................8
3.4. Unsynchronized Information among Member RBridges ...........8
4. High-Level Requirements and Goals for Solutions .................9
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Acknowledgments ...................................................12
Authors' Addresses ................................................13
The IETF TRILL (Transparent Interconnection of Lots of Links) [RFC6325] protocol provides loop-free and per-hop-based multipath data forwarding with minimum configuration. TRILL uses IS-IS [IS-IS] [RFC6165] [RFC7176] as its control-plane routing protocol and defines a TRILL-specific header for user data. In a TRILL campus, communications between TRILL switches can:
IETF TRILL（大量链路的透明互连）[RFC6325]协议以最小配置提供无环路和基于每跳的多路径数据转发。TRILL使用IS-IS[IS-IS][RFC6165][RFC7176]作为其控制平面路由协议，并为用户数据定义特定于TRILL的报头。在TRILL校园中，TRILL交换机之间的通信可以：
1) use multiple parallel links and/or paths,
1) 使用多个平行链接和/或路径，
2) spread load over different links and/or paths at a fine-grained flow level through equal-cost multipathing of unicast traffic and multiple distribution trees for multi-destination traffic, and
2) 通过单播业务的等成本多路径和多目的地业务的多分布树，以细粒度流级别在不同链路和/或路径上分散负载，以及
3) rapidly reconfigure to accommodate link or node failures or additions.
3) 快速重新配置以适应链路或节点故障或添加。
To the degree practical, "active-active" is the extension of similar load spreading and robustness to the connections between end stations and the TRILL campus. Such end stations may have multiple ports and will be connected, directly or via bridges, to multiple edge TRILL switches. It must be possible, except in some failure conditions, to spread end-station traffic load at the granularity of flows across links to such multiple edge TRILL switches and rapidly reconfigure to accommodate topology changes.
从实用的角度来看，“主动-主动”是类似负载扩展的延伸，并且对终端站和TRILL校园之间的连接具有鲁棒性。这种终端站可能有多个端口，并将直接或通过网桥连接到多个边缘TRILL交换机。除非在某些故障条件下，否则必须能够以流的粒度将端站流量负载分布到这样的多个边缘TRILL交换机，并快速重新配置以适应拓扑变化。
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]中所述进行解释。
The acronyms and terminology in the RBridges base protocol [RFC6325] are used herein with the following additions:
本文使用RBridges基本协议[RFC6325]中的首字母缩略词和术语，并添加以下内容：
CE: Customer Equipment (end station or bridge).
CE：客户设备（终端站或桥接器）。
Data Label: VLAN or FGL (Fine-Grained Label [RFC7172]).
数据标签：VLAN或FGL（细粒度标签[RFC7172]）。
LAALP: Local Active-Active Link Protocol. Any protocol similar to MC-LAG that runs in a distributed fashion on a CE, on the links from that CE to a set of edge group RBridges, and on those RBridges.
LAALP：本地主动链路协议。任何类似于MC-LAG的协议，在CE、从该CE到一组边缘组RBridge的链路以及这些RBridge上以分布式方式运行。
MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions to IEEE Std 802.1AX-2011 [802.1AX] so that the aggregated links can, at one end of the aggregation, attach to different switches.
MC-LAG：多机箱链路聚合。IEEE Std 802.1AX-2011[802.1AX]的专有扩展，以便聚合链路可以在聚合的一端连接到不同的交换机。
Edge group: a group of edge RBridges to which at least one CE is multiply attached using an LAALP. When multiple CEs attach to the exact same set of edge RBridges, those edge RBridges can be considered as a single edge group. An RBridge can be in more than one edge group.
边缘组：使用LAALP将至少一个CE多重连接到的一组边缘RBridge。当多个CE连接到完全相同的边RBridges集时，这些边RBridges可被视为单个边组。RBridge可以位于多个边组中。
RBridge: Routing Bridge. An alternative name for a TRILL switch.
RBridge：路由桥。颤音开关的替代名称。
TRILL: Transparent Interconnection of Lots of Links.
TRILL：大量链接的透明互连。
TRILL switch: a device that implements the TRILL protocol; an alternative term for an RBridge.
颤音开关：实现颤音协议的设备；RBridge的替代术语。
This section presents a typical scenario of active-active connection to a TRILL campus via multiple edge RBridges where the current TRILL Appointed Forwarder mechanism does not work as expected.
本节介绍了通过多个边缘RBridge与TRILL园区进行主动-主动连接的典型场景，其中当前TRILL指定的转发器机制无法按预期工作。
The TRILL Appointed Forwarder mechanism [RFC6439] can handle failover (active-standby), provides loop avoidance, and, with administrative configuration, provides load spreading based on VLAN. One and only one appointed RBridge can ingress/egress native frames into/from the TRILL campus for a given VLAN among all edge RBridges connecting a legacy network to the TRILL campus. This is true whether the legacy network is a simple point-to-point link or a complex bridged LAN or anything in between. By carefully selecting different RBridges as Appointed Forwarder for different sets of VLANs, load spreading over different edge RBridges across different Data Labels can be achieved.
TRILL指定的转发器机制[RFC6439]可以处理故障切换（主备），提供循环避免，并且通过管理配置，提供基于VLAN的负载分配。在将传统网络连接到TRILL园区的所有边缘RBridge中，一个且只有一个指定RBridge可以将给定VLAN的本机帧进出TRILL园区。无论传统网络是简单的点到点链路，还是复杂的桥接LAN或介于两者之间的任何东西，都是如此。通过仔细选择不同的RBridge作为不同VLAN集的指定转发器，可以实现跨不同数据标签的不同边缘RBridge的负载分布。
The Appointed Forwarder mechanism [RFC6439] requires all of the edge group RBridges to exchange TRILL IS-IS Hello packets through their access ports. As Figure 1 shows, when multiple access links of multiple edge RBridges are connected to a CE by an LAALP, Hello messages sent by RB1 via access port to CE1 will not be forwarded to RB2 by CE1. RB2 (and other members of LAALP1) will not see that Hello from RB1 via the LAALP1. Every member RBridge of LAALP1 thinks of itself as Appointed Forwarder on an LAALP1 link for all VLANs and will ingress/egress frames. Hence, the Appointed Forwarder mechanism cannot provide active-active or even active-standby service across the edge group in such a scenario.
指定的转发器机制[RFC6439]要求所有边缘组RBridge通过其访问端口交换TRILL IS-IS Hello数据包。如图1所示，当多个边缘RBridge的多个接入链路通过LAALP连接到CE时，RB1通过接入端口发送到CE1的Hello消息不会被CE1转发到RB2。RB2（和LAALP1的其他成员）不会通过LAALP1看到RB1的Hello。LAALP1的每个成员RBridge都认为自己是所有VLAN的LAALP1链路上的指定转发器，并将进入/离开帧。因此，在这种情况下，指定的转发器机制无法跨边缘组提供主动-主动甚至主动-备用服务。
----------------------
| |
| 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的活动连接
Active-active connection is useful when we want to achieve the following two goals:
当我们想要实现以下两个目标时，主动连接非常有用：
- Flow-based rather than VLAN-based load balancing is desired.
- 需要基于流而不是基于VLAN的负载平衡。
- More rapid failure recovery is desired.
- 需要更快速的故障恢复。
The current Appointed Forwarder mechanism relies on the TRILL Hello timer expiration to detect the unreachability of another edge RBridge connecting to the same local link. Then, reappointing the forwarder for specific VLANs may be required. Such procedures take time on the scale of seconds although this can be improved with TRILL use of Bidirectional Forwarding Detection (BFD) [RFC7175]. Active-active connection usually has a faster built-in mechanism for member node and/or link failure detection. Faster detection of failures minimizes the frame loss and recovery time.
当前指定的转发器机制依赖TRILL Hello计时器过期来检测连接到同一本地链路的另一个边缘RBridge的不可访问性。然后，可能需要为特定VLAN重新指定转发器。这种过程需要几秒钟的时间，尽管这可以通过双向转发检测（BFD）[RFC7175]的TRILL使用来改进。主动-主动连接通常具有更快的内置机制，用于成员节点和/或链路故障检测。更快的故障检测将帧丢失和恢复时间降至最低。
Today, LAALP is usually a proprietary facility whose implementation varies by vendor. So, to be sure the LAALP operates successfully across a group of edge RBridges, those edge RBridges will almost always have to be from the same vendor. In the case where the LAALP is an MC-LAG, the CE normally implements the logic described in IEEE Std 802.1AX-2011 [802.1AX], so proprietary elements would only be at
如今，LAALP通常是一种专有设施，其实现因供应商而异。因此，为了确保LAALP在一组边缘RBridge上成功运行，这些边缘RBridge几乎总是来自同一个供应商。在LAALP为MC-LAG的情况下，CE通常实现IEEE Std 802.1AX-2011[802.1AX]中描述的逻辑，因此专有元件仅在
the end of the edge group. There is also a revision of IEEE Std 802.1AX-2011 [802.1AX] underway (802.1X-REV) to remove the restriction in IEEE Std 802.1AX-2011 [802.1AX] that there be one box at each end of the aggregation. So it is possible that, in the future, an LAALP could be implemented through such a revised IEEE Std 802.1AX-2011 [802.1AX] with standards-conformant logic at the ends of both the CE and edge group. In order to have a common understanding of active-active connection scenarios, the assumptions in Section 2.1 are made about the characteristics of the LAALP and edge group of RBridges.
边组的末尾。此外，IEEE标准802.1AX-2011[802.1AX]的修订版（802.1X-REV）正在进行中，以取消IEEE标准802.1AX-2011[802.1AX]中关于聚合两端各有一个盒子的限制。因此，在未来，LAALP有可能通过在CE和edge组两端具有符合标准逻辑的修订版IEEE Std 802.1AX-2011[802.1AX]来实现。为了对主动连接场景有一个共同的理解，第2.1节中的假设是关于LAALP和RBridge边缘组的特征。
For a CE connecting to multiple edge RBridges via an LAALP (active-active connection), the following characteristics apply:
对于通过LAALP（主动-主动连接）连接到多个边缘RBridge的CE，以下特征适用：
a) The LAALP will deliver a frame from an end node to TRILL at exactly one edge group RBridge.
a) LAALP将在恰好一个边缘组RBridge处将帧从结束节点传送到颤音。
b) The LAALP will never forward frames it receives from one uplink to another.
b) LAALP永远不会将从一个上行链路接收到的帧转发到另一个上行链路。
c) The LAALP will attempt to send all frames for a given flow on the same uplink. To do this, it has some unknown rule for which frames get sent to which uplinks (typically based on a simple hash function of Layer 2 through 4 header fields).
c) LAALP将尝试在同一上行链路上发送给定流的所有帧。要做到这一点，它有一些未知的规则，用于将哪些帧发送到哪些上行链路（通常基于第2层到第4层头字段的简单哈希函数）。
d) Frames are accepted from any of the uplinks and passed down to end nodes (if any exist).
d) 接收来自任何上行链路的帧，并将其向下传递到终端节点（如果存在）。
e) The LAALP cannot be assumed to send useful control information to the uplink such as "this is the set of other RBridges to which this CE is attached" or "these are all the MAC addresses attached".
e) 不能假设LAALP向上行链路发送有用的控制信息，例如“这是附加了该CE的其他rbridge的集合”或“这些都是附加的MAC地址”。
For an edge group of RBridges to which a CE is multiply attached with an LAALP:
对于CE与LAALP多重连接的RBridge边缘组：
a) Any two RBridges in the edge group are reachable from each other via the TRILL campus.
a) 边缘组中的任何两个RBridge都可以通过TRILL校园相互访问。
b) Each RBridge in the edge group knows an ID for each LAALP instance multiply attached to that group. The ID will be consistent across the edge group and globally unique across the TRILL campus. For example, if CE1 attaches to RB1, RB2, ... RBn using an LAALP, then each of the RBs will know, for the port to CE1, that it has a label such as "LAALP1".
b) edge组中的每个RBridge都知道附加到该组的每个LAALP实例的ID。该ID将在整个edge组中保持一致，并在TRILL校园中保持全局唯一性。例如，如果CE1连接到RB1，RB2。。。使用LAALP的RBn，则每个RB将知道，对于CE1端口，它有一个标签，如“LAALP1”。
c) Each RB in the edge group can be configured with the set of acceptable VLANs for the ports to any CE. The acceptable VLANs configured for those ports should include all the VLANs the CE has joined and be consistent for all the member RBridges of the edge group.
c) 边缘组中的每个RB都可以为任何CE的端口配置一组可接受的VLAN。为这些端口配置的可接受VLAN应包括CE已加入的所有VLAN，并与边缘组的所有成员RBridge保持一致。
d) When an RBridge fails, all the other RBridges that have formed an LAALP instance with it learn of the failure in a timely fashion.
d) 当一个RBridge发生故障时，与之形成LAALP实例的所有其他RBridge都会及时了解故障。
e) When a downlink of an edge group RBridge to an LAALP instance fails, that RBridge and all the other RBridges participating in the LAALP instance, including that downlink, learn of the failure in a timely fashion.
e) 当边缘组RBridge到LAALP实例的下行链路失败时，该RBridge和参与LAALP实例的所有其他RBridge（包括该下行链路）及时了解到失败。
f) The RBridges in the edge group have a mechanism to exchange information with each other, information such as the set of CEs they are connecting to or the IDs of the LAALP instances their downlinks are part of.
f) 边缘组中的rbridge具有相互交换信息的机制，例如它们连接到的ce集或它们的下行链路所属的LAALP实例的id等信息。
Other than the applicable characteristics above, the internals of an LAALP are out of the scope of TRILL.
除上述适用特征外，LAALP的内部不在TRILL的范围内。
This section presents the problems that need to be addressed in active-active connection scenarios. The topology in Figure 1 is used in the following sub-sections as the example scenario for illustration purposes.
本节介绍在活动连接方案中需要解决的问题。图1中的拓扑在以下小节中用作示例场景，以便于说明。
When a remote RBridge ingresses a multi-destination TRILL data packet in VLAN x, all edge group RBridges of LAALP1 will receive the frame if any local CE1 joins VLAN x. As each of them thinks it is the Appointed Forwarder for VLAN x, without changes made for active-active connection support, they would all forward the frame to CE1. The bad consequence is that CE1 receives multiple copies of that multi-destination frame from the remote end-host source.
当远程RBridge进入VLAN x中的多目的地TRILL数据包时，如果任何本地CE1加入VLAN x，则LAALP1的所有边缘组RBridge将接收帧。因为他们每个人都认为它是VLAN x的指定转发器，所以在不改变主动连接支持的情况下，他们都会将帧转发到CE1。坏的结果是CE1从远程终端主机源接收该多目标帧的多个副本。
Frame duplication may also occur when an ingress RBridge is non-remote -- say, ingress and egress are two RBridges belonging to the same edge group. Assume LAALP m connects to an edge group g, and the edge group g consists of RB1, RB2, and RB3. The multi-destination frames ingressed from a port not connected to LAALP m by RB1 can be locally replicated to other ports on RB1 and also TRILL encapsulated and forwarded to RB2 and RB3. CE1 will receive duplicate copies from RB1, RB2, and RB3.
当入口RBridge不远程时也可能发生帧复制——例如，入口和出口是属于同一边缘组的两个RBridge。假设LAALP m连接到边组g，边组g由RB1、RB2和RB3组成。从RB1未连接到LAALP m的端口进入的多目的地帧可以本地复制到RB1上的其他端口，也可以TRILL封装并转发到RB2和RB3。CE1将收到RB1、RB2和RB3的副本。
Note that frame duplication is only a problem in multi-destination frame forwarding. Unicast forwarding does not have this issue as there is only ever one copy of the packet.
请注意，帧复制只是多目标帧转发中的一个问题。单播转发没有这个问题，因为数据包只有一个副本。
As shown in Figure 1, CE1 may send a native multi-destination frame to the TRILL campus via a member of the LAALP1 edge group (say RB1). This frame will be TRILL encapsulated and then forwarded through the campus to the multi-destination receivers. Other members (say RB2) of the same LAALP edge group will receive this multicast packet as well. In this case, without changes made for active-active connection support, RB2 will decapsulate the frame and egress it. The frame loops back to CE1.
如图1所示，CE1可以通过LAALP1边缘组（比如RB1）的成员向TRILL校园发送本机多目的帧。该帧将被TRILL封装，然后通过校园转发到多目标接收器。同一LAALP edge组的其他成员（比如RB2）也将接收此多播数据包。在这种情况下，在不更改主动连接支持的情况下，RB2将解除帧的封装并将其退出。帧循环回到CE1。
Consider RB1 and RB2 using their own nickname as ingress nickname for data into a TRILL campus. As shown in Figure 1, CE1 may send a data frame with the same VLAN and source Media Access Control (MAC) address to any member of the edge group LAALP1. If an egress RBridge receives TRILL data packets from different ingress RBridges but with the same source Data Label and MAC address, it learns different correspondences between a {Data Label and MAC address} and nickname when decapsulating the data frames. Address correspondence may keep flip-flopping among nicknames of the member RBridges of the LAALP for the same Data Label and MAC address. Existing hardware does not support data-plane learning of multiple nicknames for the same MAC address and Data Label -- when data-plane learning indicates attachment of the MAC address to a new nickname, it overwrites the old attachment nickname.
考虑RB1和RB2使用他们自己的昵称作为入口昵称的数据到颤音校园。如图1所示，CE1可以向边缘组LAALP1的任何成员发送具有相同VLAN和源媒体访问控制（MAC）地址的数据帧。如果出口RBridge从不同的入口RBridge接收到TRILL数据包，但具有相同的源数据标签和MAC地址，则在解除数据帧的封装时，它学习{data Label and MAC address}和昵称之间的不同对应关系。对于相同的数据标签和MAC地址，地址对应可以在LAALP的成员rbridge的昵称之间保持跳跃。现有硬件不支持对同一MAC地址和数据标签的多个昵称进行数据平面学习——当数据平面学习指示将MAC地址附加到新昵称时，它会覆盖旧的附加昵称。
Implementers have stated that most current TRILL switch hardware, when doing data-plane learning, behaves badly under these circumstances and, for example, interprets address flip-flopping as a severe network problem. It may also cause the returning traffic to go through different paths to reach the destination, resulting in persistent reordering of the frames.
实施者表示，当前大多数TRILL交换机硬件在进行数据平面学习时，在这些情况下表现不佳，例如，将地址触发器解释为严重的网络问题。它还可能导致返回的流量通过不同的路径到达目的地，从而导致帧的持续重新排序。
A local RBridge, say RB1 connected to LAALP1, may have learned a correspondence between a {Data Label and MAC address} and nickname for a remote host h1 when h1 sends a packet to CE1. The returning traffic from CE1 may go to any other member RBridge of LAALP1, for example, RB2. RB2 may not have h1's correspondence between a {Data Label and MAC address} and nickname stored. Therefore, it has to do the flooding for unknown unicast addresses [RFC6325]. Such flooding
当h1向CE1发送数据包时，本地RBridge，比如连接到LAALP1的RB1，可能已经学会了远程主机h1的{Data Label and MAC address}和昵称之间的对应关系。来自CE1的返回流量可以到达LAALP1的任何其他成员RBridge，例如RB2。RB2可能没有存储{Data Label and MAC address}和昵称之间的h1对应关系。因此，它必须对未知单播地址进行泛洪处理[RFC6325]。这样的洪水
is unnecessary since the returning traffic is almost always expected and RB1 had learned the address correspondence. It is desirable to avoid flooding; it imposes a greater burden on the network than known destination unicast traffic because the flooded traffic is sent over more links.
这是不必要的，因为返回的流量几乎总是预期的，并且RB1已经了解了地址对应关系。最好避免洪水泛滥；它比已知的目的地单播流量对网络造成更大的负担，因为淹没的流量通过更多的链路发送。
Synchronization of the correspondence between a {Data Label and MAC address} and nickname information among member RBridges will reduce such unnecessary flooding.
成员rbridge之间{Data Label and MAC address}和昵称信息之间的对应关系的同步将减少这种不必要的泛洪。
The problems identified in Section 3 should be solved in any solution for active-active connection to edge RBridges. The following high-level requirements and goals should be met.
第3节中确定的问题应在主动连接至边缘RBridges的任何解决方案中解决。应满足以下高级要求和目标。
Data plane:
数据平面：
1) All uplinks of a CE MUST be active: the LAALP is free to choose any uplink on which to send packets, and the CE is able to receive packets from any uplink of an edge group.
1) CE的所有上行链路都必须处于活动状态：LAALP可以自由选择发送数据包的任何上行链路，并且CE能够从边缘组的任何上行链路接收数据包。
2) Loopback and frame duplication MUST be prevented.
2) 必须防止环回和帧复制。
3) Learning of correspondence between a {Data Label and MAC address} and nickname by a remote RBridge MUST NOT flip-flop between the local multiply attached edge RBridges.
3) 远程RBridge对{Data Label and MAC address}和昵称之间的对应关系的学习不得在本地多联连接的边缘RBridge之间触发。
4) Packets for a flow SHOULD stay in order.
4) 流的数据包应保持有序。
5) The Reverse Path Forwarding Check MUST work properly as per the RBridges base protocol [RFC6325].
5) 反向路径转发检查必须按照RBridges基本协议[RFC6325]正常工作。
6) Single uplink failure on a CE to an edge group MUST NOT cause persistent packet delivery failure between a TRILL campus and CE.
6) CE到边缘组的单一上行链路故障不得导致TRILL园区和CE之间的持久数据包交付故障。
Control plane:
控制平面：
1) No requirement for new information to be passed between edge RBridges and CEs or between edge RBridges and end nodes exists.
1) 不需要在边缘RBridges和CEs之间或边缘RBridges和端点节点之间传递新信息。
2) If there is any TRILL-specific information required to be exchanged between RBridges in an edge group, for example, Data Labels and MAC addresses binding to nicknames, a solution MUST specify the mechanism to perform such exchange unless this is handled internal to the LAALP.
2) 如果需要在边缘组中的RBridge之间交换任何特定于TRILL的信息，例如绑定到昵称的数据标签和MAC地址，则解决方案必须指定执行此类交换的机制，除非这是在LAALP内部处理的。
3) RBridges SHOULD be able to discover other members in the same edge group by exchanging their LAALP attachment information.
3) RBridges应该能够通过交换其LAALP附件信息来发现同一边缘组中的其他成员。
Configuration, incremental deployment, and others:
配置、增量部署和其他：
1) Solution SHOULD require minimal configuration.
1) 解决方案应该需要最少的配置。
2) Solution SHOULD automatically detect misconfiguration of edge RBridge group.
2) 解决方案应自动检测边缘RBridge组的错误配置。
3) Solution SHOULD support incremental deployment, that is, not require campus-wide upgrading for all RBridges, only changes to the edge group RBridges.
3) 解决方案应支持增量部署，即不需要对所有RBridge进行校园范围的升级，只需要对边缘组RBridge进行更改。
4) Solution SHOULD be able to support from two up to at least four active-active uplinks on a multiply attached CE.
4) 该解决方案应能够在多连接CE上支持两条至至少四条主动上行链路。
5) Solution SHOULD NOT assume there is a dedicated physical link between any two edge RBridges in an edge group.
5) 解决方案不应假定一个边缘组中的任何两个边缘RBridge之间存在专用物理链路。
As an informational overview, this document does not introduce any extra security risks. Security risks introduced by a particular LAALP or other elements of solutions to the problems presented here will be discussed in the separate document(s) describing such LAALP or solutions.
作为信息概述，本文档不会引入任何额外的安全风险。由特定LAALP或解决方案的其他要素引入的安全风险将在描述此类LAALP或解决方案的单独文件中讨论。
End-station links in TRILL are Ethernet links, and consideration should be given to securing them with link security as described in IEEE Std 802.1AE-2006 [802.1AE] for the protection of end-station data and link-level control messages, including any LAALP control messages.
TRILL中的终端站链路是以太网链路，应考虑使用IEEE Std 802.1AE-2006[802.1AE]中所述的链路安全性来保护终端站数据和链路级控制消息，包括任何LAALP控制消息。
For general TRILL Security Considerations, see the RBridges base protocol [RFC6325].
有关一般TRILL安全注意事项，请参阅RBridges基本协议[RFC6325]。
[IS-IS] ISO/IEC, "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, 2002.
[IS-IS]ISO/IEC，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，ISO/IEC 10589:2002，第二版，2002
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 61652011年4月<http://www.rfc-editor.org/info/rfc6165>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 63252011年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, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 64392011年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, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链路的透明互连（TRILL）：细粒度标记”，RFC 7172，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, 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，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security", IEEE Std 802.1AE-2006, 18 August 2006.
[802.1AE]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）安全”，IEEE标准802.1AE-2006，2006年8月18日。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregration", IEEE Std 802.1AX-2008, 3 November 2008.
[802.1AX]IEEE，“局域网和城域网的IEEE标准——链路聚合”，IEEE标准802.1AX-2008，2008年11月3日。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014, <http://www.rfc-editor.org/info/rfc7175>.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，2014年5月<http://www.rfc-editor.org/info/rfc7175>.
Acknowledgments
致谢
Special acknowledgments to Donald Eastlake, Adrian Farrel, and Mingui Zhang for their valuable comments.
特别感谢Donald Eastlake、Adrian Farrel和Mingui Zhang的宝贵评论。
Authors' Addresses
作者地址
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
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
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
Jon Hudson Brocade 130 Holger Way San Jose, CA 95134 United States
Jon Hudson Brocade美国加利福尼亚州圣何塞霍尔格大道130号，邮编95134
Phone: +1-408-333-4062
EMail: jon.hudson@gmail.com
Phone: +1-408-333-4062
EMail: jon.hudson@gmail.com
Hongjun Zhai JIT
翟鸿钧JIT
EMail: honjun.zhai@tom.com
EMail: honjun.zhai@tom.com