Network Working Group J. Touch
Request for Comments: 5556 USC/ISI
Category: Informational R. Perlman
Sun
May 2009
Network Working Group J. Touch
Request for Comments: 5556 USC/ISI
Category: Informational R. Perlman
Sun
May 2009
Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement
大量链路的透明互连（TRILL）：问题和适用性声明
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities.
当前的IEEE 802.1局域网使用的生成树协议存在许多挑战。由于缺少报头循环检测支持，这些协议需要在路由传播期间严格避免循环，甚至是临时循环。路由往往不充分利用备用路径，甚至不重叠的成对路径（在生成树的情况下）。本文档解决了这些问题，并建议在链路层应用现代网络层路由协议。本文档假设解决方案不会解决现有IEEE 802.1桥接链路之外的可扩展性问题，但解决方案将向后兼容802.1，包括集线器、网桥及其现有即插即用功能。
Table of Contents
目录
1. Introduction ....................................................2
2. The TRILL Problem ...............................................3
2.1. Inefficient Paths ..........................................3
2.2. Multipath Forwarding .......................................5
2.3. Convergence and Safety .....................................6
2.4. Stability of IP Multicast Optimization .....................6
2.5. IEEE 802.1 Bridging Protocols ..............................7
2.6. Problems Not Addressed .....................................8
3. Desired Properties of Solutions to TRILL ........................9
3.1. No Change to Link Capabilities .............................9
3.2. Zero Configuration and Zero Assumption ....................10
3.3. Forwarding Loop Mitigation ................................10
3.4. Spanning Tree Management ..................................11
3.5. Multiple Attachments ......................................11
3.6. VLAN Issues ...............................................11
3.7. Operational Equivalence ...................................12
3.8. Optimizations .............................................12
3.9. Internet Architecture Issues ..............................13
4. Applicability ..................................................13
5. Security Considerations ........................................14
6. Acknowledgments ................................................15
7. Informative References .........................................15
1. Introduction ....................................................2
2. The TRILL Problem ...............................................3
2.1. Inefficient Paths ..........................................3
2.2. Multipath Forwarding .......................................5
2.3. Convergence and Safety .....................................6
2.4. Stability of IP Multicast Optimization .....................6
2.5. IEEE 802.1 Bridging Protocols ..............................7
2.6. Problems Not Addressed .....................................8
3. Desired Properties of Solutions to TRILL ........................9
3.1. No Change to Link Capabilities .............................9
3.2. Zero Configuration and Zero Assumption ....................10
3.3. Forwarding Loop Mitigation ................................10
3.4. Spanning Tree Management ..................................11
3.5. Multiple Attachments ......................................11
3.6. VLAN Issues ...............................................11
3.7. Operational Equivalence ...................................12
3.8. Optimizations .............................................12
3.9. Internet Architecture Issues ..............................13
4. Applicability ..................................................13
5. Security Considerations ........................................14
6. Acknowledgments ................................................15
7. Informative References .........................................15
Conventional Ethernet networks -- known in the Internet as Ethernet link subnets -- have a number of attractive features, allowing hosts and routers to relocate within the subnet without requiring renumbering, and supporting automatic configuration. The basis of the simplicity of these subnets is the spanning tree, which although simple and elegant, can have substantial limitations. With spanning trees, the bandwidth across the subnet is limited because traffic flows over a subset of links forming a single tree -- or, with the latest version of the protocol and significant additional configuration, over a small number of superimposed trees. The oldest version of the spanning tree protocol can converge slowly when there are frequent topology changes.
传统的以太网（在Internet中称为以太网链路子网）具有许多吸引人的特性，允许主机和路由器在子网内重新定位，而无需重新编号，并支持自动配置。这些子网的简单性的基础是生成树，它虽然简单而优雅，但有很大的局限性。使用生成树，子网中的带宽是有限的，因为流量通过形成一棵树的链路子集流动——或者，使用最新版本的协议和重要的附加配置，通过少量的重叠树流动。当拓扑结构频繁变化时，最古老的生成树协议可能会缓慢收敛。
The alternative to an Ethernet link subnet is often a network subnet. Network subnets can use link-state routing protocols that allow traffic to traverse least-cost paths rather than being aggregated on a spanning tree backbone, providing higher aggregate capacity and more resistance to link failures. Unfortunately, IP -- the dominant network layer technology -- requires that hosts be renumbered when relocated in different network subnets, interrupting network (e.g.,
以太网链路子网的替代方案通常是网络子网。网络子网可以使用链路状态路由协议，该协议允许流量通过成本最低的路径，而不是在生成树主干上聚合，从而提供更高的聚合容量和更大的链路故障抵抗能力。不幸的是，IP——主要的网络层技术——要求主机在重新定位到不同的网络子网时重新编号，从而中断网络（例如。，
tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are in progress during the transition.
过渡期间正在进行的隧道（IPsec）和传输（例如TCP、UDP）关联。
It is thus useful to consider a new approach that combines the features of these two existing solutions, hopefully retaining the desirable properties of each. Such an approach would develop a new kind of bridge system that was capable of using network-style routing, while still providing Ethernet service. It allows reuse of well-understood network routing protocols to benefit the link layer.
因此，考虑一种结合这两个现有解决方案的特征的新方法是有用的，希望保留每个期望的特性。这种方法将开发一种新的网桥系统，能够使用网络式路由，同时仍然提供以太网服务。它允许重用理解良好的网络路由协议，使链路层受益。
This document describes the challenge of such a combined approach. This problem is known as "Transparent Interconnection of Lots of Links" or "TRILL". The remainder of this document makes minimal assumptions about a solution to TRILL.
本文件描述了这种组合方法的挑战。这个问题被称为“大量链接的透明互连”或“颤音”。本文档的其余部分对TRILL的解决方案进行了最低限度的假设。
Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted pair with hubs to twisted pair with switches, becoming increasingly simple to wire and manage. Each level has corresponding topology restrictions; thicknet is inherently linear, whereas thinnet and hub-connected twisted pair have to be wired as a tree. Switches, added in IEEE 802.1D, allow network managers to avoid thinking in trees, where the spanning tree protocol finds a valid tree automatically; unfortunately, this additional simplicity comes with a number of associated penalties [Pe99].
以太网子网已经从“thicknet”发展到“think”，再到带集线器的双绞线，再到带交换机的双绞线，布线和管理变得越来越简单。每一层都有相应的拓扑限制；thicknet本质上是线性的，而Thinket和集线器连接的双绞线必须像树一样布线。IEEE 802.1D中添加的交换机允许网络管理员避免在树中思考，生成树协议会自动找到有效的树；不幸的是，这种额外的简单性伴随着许多相关的惩罚[Pe99]。
The spanning tree often results in inefficient use of the link topology; traffic is concentrated on the spanning tree path, and all traffic follows that path even when other more direct paths are available. The addition in IEEE 802.1Q of support for multiple spanning trees helps a little, but the use of multiple spanning trees requires additional configuration, the number of trees is limited, and these defects apply within each tree regardless. The spanning tree protocol reacts to certain small topology changes with large effects on the reconfiguration of links in use. Each of these aspects of the spanning tree protocol can cause problems for current link-layer deployments.
生成树经常导致链路拓扑的低效使用；流量集中在生成树路径上，所有流量都遵循该路径，即使其他更直接的路径可用。IEEE 802.1Q中增加了对多棵生成树的支持，这有点帮助，但是使用多棵生成树需要额外的配置，树的数量是有限的，并且这些缺陷在每棵树中都适用。生成树协议对某些小的拓扑变化作出反应，对正在使用的链路的重新配置产生重大影响。生成树协议的每一个方面都会给当前的链路层部署带来问题。
The Spanning Tree Protocol (STP) helps break cycles in a set of interconnected bridges, but it also can limit the bandwidth among that set and cause traffic to take circuitous paths. For example, in a set of N nodes that are interconnected pairwise along a ring, a spanning tree will disable one physical link so that connectivity is loop free. This will cause traffic between the pair of nodes connected by that disabled link to have to go N-1 physical hops
生成树协议（STP）有助于打破一组互连网桥中的循环，但它也会限制该组网桥之间的带宽，并导致流量采用迂回路径。例如，在一组沿环成对互连的N个节点中，生成树将禁用一个物理链路，从而使连接无环路。这将导致由该禁用链路连接的一对节点之间的通信量必须经过N-1个物理跃点
around the entire remainder of the ring rather than take the most efficient single-hop path. Using modern routing protocols with such a topology, no traffic should have to go more than N/2 hops.
环绕环的整个剩余部分，而不是采用最有效的单跳路径。使用具有这种拓扑结构的现代路由协议，通信量不应超过N/2跳。
For another example, consider the network shown in Figure 1, which shows a number of bridges and their interconnecting links. End-hosts and routers are not shown; they would connect to the bridges that are shown, labeled A-H. Note that the network shown has cycles that would cause packet storms if hubs (repeaters) were used instead of spanning-tree-capable bridges. One possible spanning tree is shown by double lines.
再举一个例子，考虑图1所示的网络，它显示了许多桥梁及其互连链路。未显示终端主机和路由器；它们将连接到图中标记为A-H的网桥。请注意，如果使用集线器（中继器）而不是支持生成树的网桥，则图中所示的网络具有可能导致数据包风暴的周期。一个可能的生成树用双线表示。
[A]
// \ [C]
// \ / \\ [D]
// \ / \\ //
[B]=====[H]=====[E]
\ // ||
\ // ||
\ // ||
[G]--------[F]
[A]
// \ [C]
// \ / \\ [D]
// \ / \\ //
[B]=====[H]=====[E]
\ // ||
\ // ||
\ // ||
[G]--------[F]
Figure 1: Bridged subnet with spanning tree shown
图1：显示了生成树的桥接子网
The spanning tree limits the capacity of the resulting subnet. Assume that the links are 100 Mbps. Figure 2 shows how traffic from hosts on A to hosts on C goes via the spanning tree path A-B-H-E-C (links replaced with '1' in the figure); traffic from hosts on G to F go via the spanning three path G-H-E-F (links replaced by '2' in the figure). The link H-E is shared by both paths (alternating '1's and '2's), resulting in an aggregate capacity for both A..C and G..F paths of a total of 100 Mbps.
生成树限制生成子网的容量。假设链路为100 Mbps。图2显示了从A上的主机到C上的主机的流量如何通过生成树路径A-B-H-E-C（图中的链接替换为“1”）；从G到F的主机的流量通过跨越三条路径的G-H-E-F（图中的链接替换为“2”）。链路H-E由两条路径共享（交替“1”和“2”），从而使A..C和G..F路径的总容量达到100 Mbps。
[A]
1 [C]
1 1
1 1
[B]1111111[H]121212[E]
2 2
2 2
2 2
[G] [F]
[A]
1 [C]
1 1
1 1
[B]1111111[H]121212[E]
2 2
2 2
2 2
[G] [F]
Figure 2: Traffic from A..C (1) and G..F (2) share a link
图2：来自A..C（1）和G..F（2）的流量共享一条链路
If traffic from G to F were to go directly using full routing, e.g., from G-F, both paths could have 100 Mbps each, and the total aggregate capacity could be 200 Mbps (Figure 3). In this case, the
如果从G到F的流量使用完整路由（例如从G-F）直接传输，则两条路径可能各有100 Mbps，且总总容量可能为200 Mbps（图3）。在这种情况下
H-F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is more direct.
H-F链路仅承载A-C通信量（'1's），而G-F通信量（'2's）更直接。
[A]
1 [C]
1 1
1 1
[B]1111111[H]111111[E]
[A]
1 [C]
1 1
1 1
[B]1111111[H]111111[E]
[G]2222222[F]
[G] 2222222[F]
Figure 3: Traffic from A..C (1) and G..F (2) with full routing
图3：来自A..C（1）和G..F（2）的全路由流量
There are a number of features of modern layer 3 routing protocols which would be beneficial if available at layer 2, but which cannot practically be integrated into the spanning tree system such as multipath routing discussed in Section 2.2 below. Layer 3 routing typically optimizes paths between pairs of endpoints based on a cost metric, conventionally based on bandwidth, hop count, latency, and/or policy measures.
现代第3层路由协议有许多功能，如果在第2层可用，这些功能将是有益的，但实际上无法集成到生成树系统中，如下面第2.2节讨论的多路径路由。第3层路由通常基于成本度量优化端点对之间的路径，通常基于带宽、跳数、延迟和/或策略度量。
The discussion above assumes that all traffic flowing from one point to another follows a single path. Using spanning trees reduces aggregate bandwidth by forcing all such paths onto one tree, while modern routing causes such paths to be selected based on a cost metric. However, extensions to modern routing protocols enable even greater aggregate bandwidth by permitting traffic flowing from one endpoint to another to be sent over multiple, typically equal-cost, paths. (Traffic sent over different paths will generally encounter different delays and may be reordered with respect to traffic on another path. Thus, traffic must be divided into flows, such that reordering of traffic between flows is not significant, and those flows are allocated to paths.)
上面的讨论假设从一个点到另一个点的所有流量都遵循一条路径。使用生成树通过将所有此类路径强制放在一棵树上来减少聚合带宽，而现代路由则会根据成本度量选择此类路径。然而，对现代路由协议的扩展通过允许从一个端点到另一个端点的流量通过多条通常成本相等的路径发送，从而实现更大的聚合带宽。（通过不同路径发送的流量通常会遇到不同的延迟，并且可能会相对于另一条路径上的流量重新排序。因此，必须将流量划分为流，以便流之间的流量重新排序不重要，并且这些流被分配给路径。）
Multipathing typically spreads the traffic more evenly over the available physical links. The addition of multipathing to a routed network would typically result in only a small improvement in capacity for a network with roughly equal traffic between all pairs of nodes, because in that situation traffic is already fairly well dispersed. Conversely, multipathing can produce a dramatic improvement in a routed network where the traffic between a small number of pairs of nodes dominates, because such traffic can -- under the right circumstances -- be spread over multiple paths that might otherwise be lightly loaded.
多路径通常在可用的物理链路上更均匀地分布流量。在路由网络中添加多路径通常只会使所有节点对之间的通信量大致相等的网络的容量略有提高，因为在这种情况下，通信量已经相当分散。相反，多路径可以在路由网络中产生巨大的改进，在路由网络中，少量节点对之间的流量占主导地位，因为在适当的情况下，这种流量可以分布在多条路径上，否则可能会很轻地加载。
The spanning tree is dependent on the way a set of bridges are interconnected, i.e., the link-layer topology. Small changes in this topology can cause large changes in the spanning tree. Changes in the spanning tree can take time to propagate and converge, especially for older versions of STP.
生成树取决于一组网桥的互连方式，即链路层拓扑。此拓扑中的小更改可能会导致生成树中的大更改。生成树中的更改可能需要时间来传播和收敛，尤其是对于较旧版本的STP。
One possible case occurs when one of the branches connected to the root bridge fails, causing a large number of ports to block and unblock before the network reconverges [Me04]. Consider a ring with a stub as shown in Figure 4.
一种可能的情况是，连接到根网桥的一个分支发生故障，导致大量端口在网络重新聚合之前阻塞和解除阻塞[Me04]。考虑一个带有存根的环，如图4所示。
[R]----[A]----[B]----[C]----[D]----[E]
| |
+--------[F]-----[G]--------+
[R]----[A]----[B]----[C]----[D]----[E]
| |
+--------[F]-----[G]--------+
Figure 4: Ring with poor convergence under reconfiguration
图4：重构下收敛性差的环
If A is the root bridge, then the paths A->B->C->D and A->F->G->E are the two open paths, while the D->E link is blocked. If the A->B link fails, then E must unblock its port to D for traffic to flow again, but it may require recomputation of the entire tree through BPDUs (Bridge PDUs). Even worse, if R is root and R or the A-R connection fails, BPDU updates related to the old and new root can lead to a brief count-to-infinity event, and, if RSTP (Rapid Spanning Tree Protocol) is in use, can delay convergence for a few seconds. The original IEEE 802.1 spanning tree protocol can impose 30-second delays in re-establishing data connectivity after a topology change in order to be sure a new topology has stabilized and been fully propagated.
如果A是根网桥，那么路径A->B->C->D和A->F->G->E是两个打开的路径，而D->E链接被阻塞。如果A->B链接失败，则E必须解除其到D的端口的阻塞，以使流量再次流动，但它可能需要通过BPDU（网桥PDU）重新计算整个树。更糟糕的是，如果R是根，并且R或A-R连接失败，则与旧根和新根相关的BPDU更新可能会导致一个简短的无限计数事件，并且，如果正在使用RSTP（快速生成树协议），则可能会延迟收敛几秒钟。原始的IEEE 802.1生成树协议可以在拓扑更改后重新建立数据连接时施加30秒延迟，以确保新拓扑已稳定并完全传播。
The spanning tree protocol is inherently global to an entire layer 2 subnet; there is no current way to contain, partition, or otherwise factor the protocol into a number of smaller, more stable subsets that interact as groups. Contrast this with Internet routing, which includes both intradomain and interdomain variants, split to provide exactly that containment and scalability within a domain while allowing domains to interact freely independent of what happens within a domain.
生成树协议本质上是整个第2层子网的全局协议；目前没有办法将协议包含、划分或以其他方式分解为若干更小、更稳定的子集，这些子集作为组进行交互。与此形成对比的是，Internet路由（包括域内和域间的变体）被拆分以在域内提供精确的包容和可伸缩性，同时允许域与域内发生的事情自由交互。
Although it is a layer violation, it is common for high-end bridges to snoop on IP multicast control messages for the purpose of optimizing the distribution of IP multicast data and of those control messages [RFC4541].
尽管这是一种层冲突，但高端网桥通常会窥探IP多播控制消息，以优化IP多播数据和这些控制消息的分布[RFC4541]。
When such snooping and optimization is performed by spanning-tree-based bridges, it done at each bridge based on the traffic observed on that bridge's ports. Changes in topology may reverse or otherwise change the required forwarding ports of messages for a multicast group. Bridges must relearn the correct multicast forwarding from the receipt of multicast control messages on new ports. Such control messages are sent to establish multicast distribution state and then to refresh it, sometimes at intervals of seconds. If a bridging topology change has occurred during such intervals, multicast data may be misdirected and lost.
当通过基于生成树的网桥执行这种窥探和优化时，它会根据在网桥端口上观察到的流量在每个网桥上执行。拓扑的更改可能会反转或以其他方式更改多播组所需的消息转发端口。网桥必须通过在新端口上接收多播控制消息来重新学习正确的多播转发。发送此类控制消息以建立多播分发状态，然后刷新状态，有时每隔几秒钟。如果在这些间隔期间发生桥接拓扑更改，则多播数据可能会被错误定向并丢失。
However, a solution based on link-state routing, for example, can form and maintain a global view of the multicast group membership and multicast router situation in a similar fashion to that in which it maintains a global view of the status of links. Thus, such a solution can adjust the forwarding of multicast data and control traffic immediately as it sees the LAN topology change.
然而，例如，基于链路状态路由的解决方案可以以类似于其维护链路状态的全局视图的方式形成和维护多播组成员资格和多播路由器状况的全局视图。因此，这种解决方案可以在看到LAN拓扑变化时立即调整多播数据的转发并控制流量。
There have been a variety of IEEE protocols beyond the initial shared-media Ethernet variant, including:
除了最初的共享媒体以太网变体外，还有多种IEEE协议，包括：
o 802.1D - added bridges (i.e., switches) and a spanning tree protocol (STP) (incorporates 802.1w, below) [IEEE04].
o 802.1D-添加网桥（即交换机）和生成树协议（STP）（包含802.1w，如下）[IEEE04]。
o 802.1w - extension for rapid reconvergence of the spanning tree protocol (RTSP) [IEEE04].
o 802.1w-扩展生成树协议（RTSP）的快速重新聚合[IEEE04]。
o 802.1Q - added VLAN and priority support, where each link address maps to one VLAN (incorporates 802.1v and 802.1s, below) [IEEE06].
o 802.1Q-增加了VLAN和优先级支持，其中每个链路地址映射到一个VLAN（下面包含802.1v和802.1s）[IEEE06]。
o 802.1v - added VLANs where segments map to VLANs based on link address together with network protocol and transport port [IEEE06].
o 802.1v-添加了VLAN，其中段根据链路地址以及网络协议和传输端口映射到VLAN[IEEE06]。
o 802.1s - added support for multiple spanning trees, up to a maximum of 65, one per non-overlapping group of VLANs (Multiple STP) [IEEE06].
o 802.1s-增加了对多个生成树的支持，最多65个，每个不重叠的VLAN组一个（多个STP）[IEEE06]。
This document presumes the above variants are supported on the Ethernet subnet, i.e., that a TRILL solution would not interfere with (i.e., would not affect) any of the above.
本文档假定以太网子网支持上述变体，即TRILL解决方案不会干扰（即不会影响）上述任何变体。
In addition, the following more recent extensions have been standardized to specify provider/carrier Ethernet services that can be effectively transparent to the previously specified customer Ethernet services. The TRILL problem as described in this document
此外，以下较新的扩展已经标准化，以指定能够对先前指定的客户以太网服务有效透明的提供商/运营商以太网服务。本文档中描述的颤音问题
is limited to customer Ethernet services; however, there is no reason that a TRILL solution might not be easily applicable to both customer and provider Ethernet.
仅限于客户以太网服务；然而，没有理由说TRILL解决方案不容易同时适用于客户和提供商以太网。
o 802.1ad (Provider Bridges) - added support for a second level of VLAN tag, called a "service tag", and renamed the original 802.1Q tag a "customer tag". Also known as Q-in-Q because of the stacking of 802.1Q VLAN tags.
o 802.1ad（提供商网桥）-增加了对第二级VLAN标记的支持，称为“服务标记”，并将原始802.1Q标记重命名为“客户标记”。也称为Q-in-Q，因为802.1Q VLAN标签的堆叠。
o 802.1ah (Provider Backbone Bridges) - added support for stacking of MAC addresses by providing a tag to contain the original source and destination MAC addresses. Also know as MAC-in-MAC.
o 802.1ah（提供商主干网桥）-通过提供包含原始源和目标MAC地址的标记，增加了对MAC地址堆叠的支持。在MAC中也称为MAC。
It is useful to note that no extension listed above in this section addresses the issue of independent, localized routing in a single LAN -- which is the focus of TRILL.
值得注意的是，本节中上面列出的扩展没有解决单个LAN中独立的本地化路由问题，这是TRILL的重点。
The TRILL problem and a sketch of a possible solution [Pe04] were presented to both the IETF (via a BoF) and IEEE 802 (via an IEEE 802 Plenary Meeting Tutorial). The IEEE, in response, approved a project called Shortest Path Bridging (IEEE Project P802.1aq), taking a different approach than that presented in [Pe04]. The current Draft of P802.1aq appears to describe two different techniques. One, which does not use encapsulation, is, according to the IEEE Draft, limited in applicability to small networks of no more than 100 shortest path bridges. The other, which uses 802.1ah, is, according to the IEEE Draft, limited in applicability to networks of no more than 1,000 shortest path bridges.
颤音问题和可能解决方案的草图[Pe04]已提交给IETF（通过BoF）和IEEE 802（通过IEEE 802全体会议教程）。作为回应，IEEE批准了一个名为最短路径桥接（IEEE项目P802.1aq）的项目，采用了与[Pe04]中所述不同的方法。P802.1aq的当前草案似乎描述了两种不同的技术。根据IEEE草案，其中一个不使用封装，仅适用于不超过100个最短路径网桥的小型网络。另一种使用802.1ah，根据IEEE草案，其适用范围仅限于不超过1000个最短路径网桥的网络。
There are other challenges to deploying Ethernet subnets that are not addressed in this document other than, in some cases, to mention relevant IEEE 802.1 documents, although it is possible for a solution to address one or more of these in addition to the TRILL problem. These include:
除了在某些情况下提及相关的IEEE 802.1文档之外，本文档中没有提到部署以太网子网的其他挑战，尽管除了TRILL问题外，解决方案还可以解决其中一个或多个问题。这些措施包括：
o increased Ethernet link subnet scale
o 增加以太网链路子网规模
o increased node relocation
o 增加节点重新定位
o security of the Ethernet link subnet management protocol
o 以太网链路子网管理协议的安全性
o flooding attacks on a Ethernet link subnet
o 对以太网链路子网的泛洪攻击
o support for "provider" services such as Provider Bridges (802.1ad), Provider Backbone Bridges (802.1ah), or Provider Backbone Bridge Traffic Engineering (802.1Qay)
o 支持“提供商”服务，如提供商网桥（802.1ad）、提供商主干网桥（802.1ah）或提供商主干网桥流量工程（802.1Qay）
Solutions to TRILL need not support deployment of larger scales of Ethernet link subnets than current broadcast domains can support (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges, or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges).
TRILL解决方案不需要支持部署比当前广播域所能支持的规模更大的以太网链路子网（例如，100个网桥组成的单个桥接LAN中约1000个终端主机，或10000个网桥服务的1000个VLAN中的100000个终端主机）。
Similarly, solutions to TRILL need not address link-layer node migration, which can complicate the caches in learning bridges. Similar challenges exist in the Address Resolution Protocol (ARP), where link-layer forwarding is not updated appropriately when nodes move to ports on other bridges. Again, the compartmentalization available in network routing, like that of network-layer Autonomous Systems (ASes), can help hide the effect of migration. That is a side effect, however, and not a primary focus of this work.
类似地，TRILL的解决方案不需要解决链路层节点迁移问题，这会使学习桥中的缓存复杂化。地址解析协议（ARP）也存在类似的挑战，当节点移动到其他网桥上的端口时，链路层转发没有得到适当的更新。同样，网络路由中可用的划分，如网络层自治系统（ASes）的划分，可以帮助隐藏迁移的影响。然而，这是一个副作用，而不是这项工作的主要重点。
Current link-layer control-plane protocols, including Ethernet link subnet management (spanning tree) and link/network integration (ARP), are vulnerable to a variety of attacks. Solutions to TRILL need not address these insecurities. Similar attacks exist in the data plane, e.g., source address spoofing, single address traffic attacks, traffic snooping, and broadcast flooding. TRILL solutions need not address any of these issues, although it is critical that they do not introduce new vulnerabilities in the process (see Section 5).
当前的链路层控制平面协议，包括以太网链路子网管理（生成树）和链路/网络集成（ARP），容易受到各种攻击。TRILL的解决方案不需要解决这些不安全问题。数据平面中存在类似的攻击，例如源地址欺骗、单地址流量攻击、流量窥探和广播泛滥。TRILL解决方案不需要解决任何这些问题，但关键是它们不在过程中引入新的漏洞（请参见第5节）。
This section describes some of the desirable or required properties of any system that would solve the TRILL problems, independent of the details of such a solution. Most of these are based on retaining useful properties of bridges, or maintaining those properties while solving the problems listed in Section 2.
本节描述了解决颤音问题的任何系统的一些理想或必需特性，与此类解决方案的细节无关。其中大多数是基于保留桥梁的有用特性，或在解决第2节列出的问题时保持这些特性。
There must be no change to the service that Ethernet subnets already provide as a result of deploying a TRILL solution. Ethernet supports unicast, broadcast, and multicast natively. Although network protocols, notably IP, can tolerate link layers that do not provide all three, it would be useful to retain the support already in place [RFC3819]. So called "zero configuration protocols" (also known as "zeroconf", e.g., as used to configure link-local addresses [RFC3927]), as well as existing bridge autoconfiguration, are also dependent on broadcast.
由于部署TRILL解决方案，以太网子网已经提供的服务不得有任何更改。以太网本机支持单播、广播和多播。尽管网络协议，尤其是IP协议，可以容忍不提供所有三种协议的链路层，但保留现有的支持将是有益的[RFC3819]。所谓的“零配置协议”（也称为“零配置”，例如用于配置链路本地地址[RFC3927]）以及现有网桥自动配置也依赖于广播。
Current Ethernet ensures in-order delivery for frames of the same priority and no duplicated frames, under normal operation (excepting transients during reconfiguration). These criteria apply in varying degrees to the different types of Ethernet, e.g., basic Ethernet up through basic VLAN (802.1Q) ensures that all frames with the same
当前以太网可确保在正常运行（重新配置期间的瞬态除外）下，相同优先级的帧有序交付，且无重复帧。这些标准在不同程度上适用于不同类型的以太网，例如，通过基本VLAN（802.1Q）的基本以太网确保所有帧具有相同的带宽
priority between two link addresses have both properties, but protocol/port VLAN (802.1v) ensures this only for packets with the same protocol and port. There are subtle implications to such a requirement. Bridge autolearning already is susceptible to moving nodes between ports, because previously learned associations between the port and link address change. A TRILL solution could be similarly susceptible to such changes.
两个链路地址之间的优先级具有这两个属性，但协议/端口VLAN（802.1v）仅确保具有相同协议和端口的数据包具有这两个属性。这一要求有着微妙的含义。网桥自动学习已经很容易受到端口之间移动节点的影响，因为以前学习到的端口和链接地址之间的关联会发生变化。TRILL解决方案也同样容易受到此类变化的影响。
Both bridges and hubs are zero configuration devices; hubs having no configuration at all, and bridges being automatically self-configured. Bridges are further zero-assumption devices, unlike hubs. Bridges can be interconnected in arbitrary topologies, without regard for cycles or even self-attachment. Spanning tree protocols (STPs) remove the impact of cycles automatically, and port autolearning reduces unnecessary broadcast of unicast traffic.
网桥和集线器都是零配置设备；集线器完全没有配置，网桥自动自配置。与集线器不同，桥接器是进一步的零假设设备。桥可以在任意拓扑中互连，而不考虑循环甚至自连接。生成树协议（STP）自动消除循环的影响，端口自动学习减少不必要的单播流量广播。
A TRILL solution should strive to have a similar zero-configuration, zero-assumption operation. This includes having TRILL solution components automatically discover other TRILL solution components and organize themselves, as well as to configure that organization for proper operation (plug-and-play). It also includes zero-configuration backward compatibility with existing bridges and hubs, which may include interacting with some of the bridge protocols, such as spanning tree.
TRILL解决方案应力求具有类似的零配置、零假设操作。这包括让TRILL解决方案组件自动发现其他TRILL解决方案组件并自行组织，以及配置该组织以实现正确操作（即插即用）。它还包括与现有网桥和集线器的零配置向后兼容性，这可能包括与一些网桥协议（如生成树）交互。
VLANs add a caveat to zero configuration; a TRILL solution should support automatic use of a default VLAN (like non-VLAN bridges), but would undoubtedly require explicit configuration for VLANs where bridges require such configuration.
VLAN为零配置添加了警告；TRILL解决方案应支持自动使用默认VLAN（如非VLAN网桥），但毫无疑问，当网桥需要此类配置时，需要对VLAN进行显式配置。
Autoconfiguration extends to optional services, such as multicast support via Internet Group Management Protocol (IGMP) snooping, broadcast support via serial copy, and support of multiple VLANs.
自动配置扩展到可选服务，例如通过Internet组管理协议（IGMP）侦听的多播支持、通过串行拷贝的广播支持以及对多个VLAN的支持。
Using spanning trees avoids forwarding loops by construction, although transient loops can occur, e.g., via the temporarily undetected appearance of new link connectivity or the loss of a sufficient number of spanning-tree control frames. Solutions to TRILL are intended to use adapted network-layer routing protocols that may introduce transient loops during routing convergence. A TRILL solution thus needs to provide support for mitigating the effect of such routing loops.
使用生成树避免了通过构造转发循环，尽管可能会发生瞬时循环，例如，通过临时未检测到的新链路连接或丢失足够数量的生成树控制帧。TRILL的解决方案旨在使用经过调整的网络层路由协议，这些协议可能会在路由收敛期间引入瞬时环路。因此，TRILL解决方案需要提供支持，以减轻此类路由循环的影响。
In the Internet, loop mitigation is provided by decrementing hop counts (Time To Live (TTL)); in other networks, packets include a trace (sometimes referred to as 'serialized' or 'unioned') of visited nodes [RFC1812]. In addition, there may be localized consistency checks, such as whether traffic is received on an unexpected interface, which indicates that routing is in flux and that such traffic should probably be discarded for safety. These types of mechanisms limit the impact of loops or detect them explicitly. Mechanisms with similar effect should be included in TRILL solutions.
在互联网上，通过减少跳数（生存时间（TTL））来缓解环路；在其他网络中，数据包包括访问节点的跟踪（有时称为“序列化”或“联合”）[RFC1812]。此外，可能存在局部一致性检查，例如是否在意外接口上接收到流量，这表明路由正在变化，并且出于安全考虑，可能应该丢弃此类流量。这些类型的机制限制循环的影响或显式地检测循环。TRILL解决方案中应包括具有类似效果的机制。
In order to address convergence under reconfiguration and robustness to link interruption (Section 2.2), participation in the spanning tree (STP) must be carefully managed. The goal is to provide the desired stability of the TRILL solution and of the entire Ethernet link subnet, which may include bridges using STP. This may involve a TRILL solution participating in the STP, where the protocol used for TRILL might dampen interactions with STP, or it may involve severing the STP into separate STPs on 'stub' external Ethernet link subnet segments.
为了解决重新配置下的收敛性和对链路中断的鲁棒性（第2.2节），必须仔细管理生成树（STP）的参与。目标是为TRILL解决方案和整个以太网链路子网（可能包括使用STP的网桥）提供所需的稳定性。这可能涉及参与STP的TRILL解决方案，其中TRILL使用的协议可能会抑制与STP的交互，或者可能涉及将STP断开为“存根”外部以太网链路子网段上的单独STP。
A requirement is that a TRILL solution must not require modifications or exceptions to the existing spanning tree protocols (e.g., STP, RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree Protocol)).
一项要求是TRILL解决方案不得要求对现有生成树协议（例如STP、RSTP（快速生成树协议）、MSTP（多生成树协议））进行修改或例外。
In STP, a single node with multiple attachments to a single spanning tree segment will always get and send traffic over only one of the those attachment points. TRILL must manage all traffic, including multicast and broadcast traffic, so as not to create traffic loops involving Ethernet segments with multiple TRILL attachment points. This includes multiple attachments to a single TRILL node and attachments to multiple TRILL nodes. Support for multiple attachments can improve support for forms of mobility that induce topology changes, such as "make before break", although this is not a major goal of TRILL.
在STP中，具有多个连接到单个生成树段的单个节点将始终仅通过其中一个连接点获取和发送流量。TRILL必须管理所有流量，包括多播和广播流量，以避免创建涉及具有多个TRILL连接点的以太网段的流量环路。这包括到单个颤音节点的多个附件和到多个颤音节点的附件。对多个附件的支持可以提高对引起拓扑变化的移动性形式的支持，例如“先通后断”，尽管这不是TRILL的主要目标。
A TRILL solution should support multiple customer VLANs (802.1Q, which includes 802.1v and 802.1s). This may involve ignorance, just as many bridge devices do not participate in the VLAN protocols. A TRILL solution may alternately furnish direct VLAN support, e.g., by providing configurable support for VLAN-ignorant end stations equivalent to that provided by 802.1Q non-provider bridges.
TRILL解决方案应支持多个客户VLAN（802.1Q，包括802.1v和802.1s）。这可能涉及无知，就像许多网桥设备不参与VLAN协议一样。TRILL解决方案可以交替地提供直接VLAN支持，例如，通过提供与802.1Q非提供商网桥提供的支持等效的对VLAN无关的终端站的可配置支持。
Provider VLANs (802.1ad) are outside of the scope of this document. A TRILL solution might or might not be easily adaptable to handling provider VLANs.
提供商VLAN（802.1ad）不在本文档的范围内。TRILL解决方案可能很容易适应，也可能不适合处理提供者VLAN。
As with any extension to an existing architecture, it would be useful -- though not strictly necessary -- to be able to describe or consider a TRILL solution as equivalent to an existing link layer component. Such equivalence provides a validation model for the architecture and a way for users to predict the effect of the use of a TRILL solution on a deployed Ethernet. In this case, 'user' refers to users of the Ethernet protocol, whether at the host (data segments), bridge (ST control segments), or VLAN (VLAN control).
与现有体系结构的任何扩展一样，能够描述或考虑与现有链路层组件相当的颤振解决方案是有用的（虽然不是严格必要的）。这种等价性为体系结构提供了一个验证模型，并为用户提供了一种预测在部署的以太网上使用TRILL解决方案的效果的方法。在这种情况下，“用户”是指以太网协议的用户，无论是在主机（数据段）、网桥（ST控制段）还是VLAN（VLAN控制段）上。
This provides a sanity check, i.e., "we got it right if we can exchange a TRILL solution component or components with an X" (where "X" might be a single bridge, a hub, or some other link layer abstraction). It does not matter whether "X" can be implemented on the same scale as the corresponding TRILL solution. It also does not matter if it can -- there may be utility to deploying the TRILL solution components incrementally, in ways that a single "X" could not be installed.
这提供了一个健全性检查，即“如果我们可以用X交换一个或多个TRILL解决方案组件，我们就做对了”（其中“X”可能是单个网桥、集线器或其他一些链路层抽象）。“X”是否可以在与相应TRILL解决方案相同的规模上实现并不重要。如果可以，这也无关紧要——可能有一个实用程序可以增量部署TRILL解决方案组件，这样就无法安装单个“X”。
For example, if a TRILL solution's components were equivalent to a single IEEE 802.1D bridge, it would mean that they would -- as a whole - participate in the STP. This need not require that TRILL solution components would propagate STP, any more than a bridge need do so in its on-board control. It would mean that the solution would interact with BPDUs at the edge, where the solution would -- again, as a whole - participate as if a single node in the spanning tree. Note that this equivalence is not required; a solution may act as if an IEEE 802.1 hub, or may not have a corresponding equivalent link layer component at all.
例如，如果TRILL解决方案的组件相当于一个IEEE 802.1D网桥，这意味着它们将——作为一个整体——参与STP。这不需要TRILL解决方案组件传播STP，就像网桥在其板载控制中需要这样做一样。这意味着该解决方案将在边缘与BPDU交互，在那里，该解决方案将——同样，作为一个整体——像生成树中的单个节点一样参与。请注意，此等效性不是必需的；解决方案的作用可能类似于IEEE 802.1集线器，也可能根本没有相应的等效链路层组件。
There are a number of optimizations that may be applied to TRILL solutions. These must be applied in a way that does not affect functionality as a tradeoff for increased performance. Such optimizations may address broadcast and multicast frame distribution, VLAN support, and snooping of ARP and IPv6 neighbor discovery.
有许多优化可应用于TRILL解决方案。必须以不影响功能的方式应用这些功能，以作为提高性能的折衷方案。此类优化可以解决广播和多播帧分布、VLAN支持以及ARP和IPv6邻居发现的监听问题。
In addition, there may be optimizations which make the implementation of a TRILL solution easier than roughly equivalent existing bridge devices. For example, in many bridged LANs, there are topologies such that central ("core") bridges which have both a greater volume of traffic flowing through them as well as traffic to and from a
此外，可能存在一些优化，使TRILL解决方案的实现比大致相当的现有桥接设备更容易。例如，在许多桥接LAN中，存在这样的拓扑结构，即中央（“核心”）网桥既有更大的流量通过它们，也有进出网络的流量
larger variety of end station than do non-core bridges. Thus means that such core bridges need to learn a large number of end station addresses and need to do lookups based on such addresses very rapidly. This might require large high speed content addressable memory making implementation of such core bridges difficult. Although a TRILL solution need not provide such optimizations, it may reduce the need for such large, high speed content addressable memories or provide other similar optimizations.
与非核心桥梁相比，端站的种类更多。因此，这意味着这样的核心网桥需要学习大量的终端站地址，并且需要非常快速地基于这样的地址进行查找。这可能需要大型高速内容寻址内存，这使得实现此类核心网桥变得困难。尽管TRILL解决方案不需要提供此类优化，但它可以减少对此类大型高速内容寻址内存的需求，或者提供其他类似的优化。
TRILL solutions are intended to have no impact on the Internet network layer architecture. In particular, the Internet and higher layer headers should remain intact when traversing a deployed TRILL solution, just as they do when traversing any other link subnet technologies. This means that the IP TTL field cannot be co-opted for forwarding loop mitigation, as it would interfere with the Internet layer assuming that the link subnet was reachable with no changes in TTL. (Internet TTLs are changed only at routers, as per RFC 1812, and even if IP TTL were considered, TRILL is expected to support non-IP payloads, and so requires a separate solution anyway [RFC1812]).
TRILL解决方案旨在对Internet网络层架构没有影响。特别是，在遍历已部署的TRILL解决方案时，Internet和更高层的头应该保持不变，就像遍历任何其他链路子网技术时一样。这意味着IP TTL字段不能用于转发环路缓解，因为它会干扰Internet层，假设链路子网在TTL没有变化的情况下是可访问的。（根据RFC 1812，互联网TTL仅在路由器上更改，即使考虑了IP TTL，TRILL也将支持非IP有效负载，因此无论如何都需要单独的解决方案[RFC1812]）。
TRILL solutions should also have no impact on Internet routing or signaling, which also means that broadcast and multicast, both of which can pervade an entire Ethernet link subnet, must be able to transparently pervade a deployed TRILL solution. Changing how either of these capabilities behaves would have significant effects on a variety of protocols, including RIP (broadcast), RIPv2 (multicast), ARP (broadcast), IPv6 neighbor discovery (multicast), etc.
TRILL解决方案也应该不会影响Internet路由或信令，这也意味着广播和多播（两者都可以覆盖整个以太网链路子网）必须能够透明地覆盖已部署的TRILL解决方案。更改这些功能的行为方式将对各种协议产生重大影响，包括RIP（广播）、RIPv2（多播）、ARP（广播）、IPv6邻居发现（多播）等。
Note that snooping of network-layer packets may be useful, especially for certain optimizations. These include snooping multicast control-plane packets (IGMP) to tune link multicast to match the network multicast topology, as is already done in existing smart switches [RFC3376] [RFC4286]. This also includes snooping IPv6 neighbor discovery messages to assist with governing TRILL solution edge configuration, as is the case in some smart learning bridges [RFC4861]. Other layers may similarly be snooped, notably ARP packets, for similar reasons as for IPv4 [RFC826].
请注意，窥探网络层数据包可能很有用，特别是对于某些优化。这些包括监听多播控制平面数据包（IGMP）以调整链路多播以匹配网络多播拓扑，正如在现有智能交换机[RFC3376][RFC4286]中所做的那样。这还包括窥探IPv6邻居发现消息，以帮助管理TRILL解决方案边缘配置，就像某些智能学习桥[RFC4861]中的情况一样。出于与IPv4[RFC826]类似的原因，其他层可能类似地被监听，尤其是ARP数据包。
As might be expected, TRILL solutions are intended to be used to solve the problems described in Section 2. However, not all such installations are appropriate environments for such solutions. This section outlines the issues in the appropriate use of these solutions.
正如所料，TRILL解决方案旨在解决第2节中描述的问题。但是，并非所有此类安装都适合于此类解决方案。本节概述了适当使用这些解决方案的问题。
TRILL solutions are intended to address problems of path efficiency and concentration, inability to multipath, and path stability within a single Ethernet link subnet. Like bridges, individual TRILL solution components may find other TRILL solution components within a single Ethernet link subnet and aggregate into a single TRILL solution.
TRILL解决方案旨在解决单一以太网链路子网中的路径效率和集中、无法多径和路径稳定性问题。与网桥一样，单个TRILL解决方案组件可以在单个以太网链路子网中找到其他TRILL解决方案组件，并聚合到单个TRILL解决方案中。
TRILL solutions are not intended to span separate Ethernet link subnets interconnected by network-layer (e.g., router) devices, except via link-layer tunnels, where such tunnels render the distinct subnet undetectably equivalent from a single Ethernet link subnet.
TRILL解决方案不打算跨越由网络层（如路由器）设备互连的单独以太网链路子网，除非通过链路层隧道，此类隧道使不同的子网与单个以太网链路子网不可检测地等效。
A currently open question is whether a single Ethernet link subnet should contain components of only one TRILL solution, either of necessity of architecture or utility. Multiple TRILL solutions, like Internet ASes, may allow TRILL routing protocols to be partitioned in ways that help their stability, but this may come at the price of needing the TRILL solutions to participate more fully as nodes (each modeling a bridge) in the Ethernet link subnet STP. Each architecture solution should decide whether multiple TRILL solutions are supported within a single Ethernet link subnet, and mechanisms should be included to enforce whatever decision is made.
目前一个悬而未决的问题是，单个以太网链路子网是否应仅包含一个TRILL解决方案的组件，无论是架构还是实用程序的需要。多个TRILL解决方案，如Internet ASE，可能允许以有助于其稳定性的方式对TRILL路由协议进行分区，但其代价可能是需要TRILL解决方案更充分地参与以太网链路子网STP中的节点（每个都建模为网桥）。每个体系结构解决方案应决定是否在单个以太网链路子网中支持多个TRILL解决方案，并应包括执行任何决策的机制。
TRILL solutions need not address scalability limitations in bridged subnets. Although there may be scale benefits of other aspects of solving TRILL problems, e.g., of using network-layer routing to provide stability under link changes or intermittent outages, this is not a focus of this work.
TRILL解决方案不需要解决桥接子网中的可伸缩性限制。虽然解决TRILL问题的其他方面可能会带来规模效益，例如，使用网络层路由在链路变化或间歇性中断情况下提供稳定性，但这不是本工作的重点。
As also noted earlier, TRILL solutions are not intended to address security vulnerabilities in either the data plane or control plane of the link layer. This means that TRILL solutions should not limit broadcast frames, ARP requests, or spanning tree protocol messages (if such are interpreted by the TRILL solution or solution edge).
如前所述，TRILL解决方案无意解决链路层的数据平面或控制平面中的安全漏洞。这意味着TRILL解决方案不应限制广播帧、ARP请求或生成树协议消息（如果TRILL解决方案或解决方案边缘解释了这些消息）。
TRILL solutions should not introduce new vulnerabilities compared to traditional bridged subnets.
与传统桥接子网相比，TRILL解决方案不应引入新的漏洞。
TRILL solutions are not intended to be a solution to Ethernet link subnet vulnerabilities, including spoofing, flooding, snooping, and attacks on the link control plane (STP, flooding the learning cache) and link-network control plane (ARP). Although TRILL solutions are intended to provide more stable routing than STP, this stability is limited to performance, and the subsequent robustness is intended to address non-malicious events.
TRILL解决方案并非针对以太网链路子网漏洞的解决方案，包括对链路控制平面（STP，淹没学习缓存）和链路网络控制平面（ARP）的欺骗、淹没、窥探和攻击。尽管TRILL解决方案旨在提供比STP更稳定的路由，但这种稳定性仅限于性能，随后的健壮性旨在解决非恶意事件。
There may be some side-effects to the use of TRILL solutions that can provide more robust operation under certain attacks, such as those interrupting or adding link service, but TRILL solutions should not be relied upon for such capabilities.
使用TRILL解决方案可能会产生一些副作用，在某些攻击（例如中断或添加链路服务）下，TRILL解决方案可以提供更稳健的操作，但此类功能不应依赖TRILL解决方案。
Finally, TRILL solutions should not interfere with other protocols intended to address these vulnerabilities, such as those to secure IPv6 neighbor discovery [RFC3971].
最后，TRILL解决方案不应干扰旨在解决这些漏洞的其他协议，例如用于保护IPv6邻居发现的协议[RFC3971]。
Portions of this document are based on documents that describe a preliminary solution, and on a related network-layer solution [Pe04] [Pe05] [To03]. Donald Eastlake III provided substantial text and comments. Additional comments and feedback were provided by the members of the IETF TRILL WG, in which this document was developed, and by the IESG.
本文档的部分内容基于描述初步解决方案的文档以及相关的网络层解决方案[Pe04][Pe05][To03]。唐纳德·伊斯特莱克三世提供了大量文本和评论。IETF TRILL工作组成员和IESG提供了补充意见和反馈，本文件就是在该工作组中编写的。
This document was prepared using 2-Word-v2.0.template.dot.
本文件使用2-Word-v2.0.template.dot编制。
[IEEE04] IEEE 802.1D bridging standard, "IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges", (incorporates 802.1w), Jun. 2004.
[IEEE04]IEEE 802.1D桥接标准，“局域网和城域网IEEE标准：媒体访问控制（MAC）网桥”，（合并802.1w），2004年6月。
[IEEE06] IEEE 802.1Q VLAN standard, "IEEE Standards for Local and metropolitan area networks: Virtual Bridged Local Area Networks", (incorporates 802.1v and 802.1s), May 2006.
[IEEE06]IEEE 802.1Q VLAN标准，“局域网和城域网的IEEE标准：虚拟桥接局域网”（包含802.1v和802.1s），2006年5月。
[Me04] Myers, A., T.E. Ng, H. Zhang, "Rethinking the Service Model: Scaling Ethernet to a Million Nodes", Proc. ACM Third Workshop on Hot Topics in Networks (HotNets-III), Mar. 2004.
[Me04]Myers，A.，T.E.Ng，H.Zhang，“重新思考服务模型：将以太网扩展到一百万个节点”，Proc。ACM第三次网络热点问题研讨会（HotNets III），2004年3月。
[Pe99] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley, Chapter 3, 1999.
[Pe99]Perlman，R.，“互连：网桥、路由器、交换机和互联协议”，Addison-Wesley，第3章，1999年。
[Pe04] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, Mar. 2004.
[Pe04]Perlman，R.，“RBridges:透明路由”，过程。信息通信2005年，2004年3月。
[Pe05] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent Routing," (expired work in progress), Apr. 2004 - May 2005.
[Pe05]Perlman，R.，J.Touch，A.Yegin，“RBridges:透明路由”，（已过期的正在进行的工作），2004年4月至2005年5月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Ed.，Bormann，C.，Fairhurst，G.，Grossman，D.，Ludwig，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4286] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4286]Rosenberg，J.，“用于表示资源列表的可扩展标记语言（XML）格式”，RFC 4826，2007年5月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[To03] Touch, J., Y. Wang, L. Eggert, G. Finn, "A Virtual Internet Architecture", ISI Technical Report ISI-TR-570, Presented at the Workshop on Future Directions in Network Architecture (FDNA) 2003 at Sigcomm 2003, March 2003.
[To03]Touch，J.，Y.Wang，L.Eggert，G.Finn，“虚拟互联网架构”，ISI技术报告ISI-TR-570，在2003年3月于Sigcomm 2003举办的2003年网络架构（FDNA）未来方向研讨会上介绍。
Authors' Addresses
作者地址
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676美国加利福尼亚州玛丽娜·德雷海军部路90292-6695号。
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Radia Perlman Sun Microsystems 16 Network Circle umpk16-161 Menlo Park, CA 94025 U.S.A.
美国加利福尼亚州门罗公园16-161号拉迪亚·帕尔曼太阳微系统公司，邮编94025。
EMail: Radia.Perlman@sun.com
EMail: Radia.Perlman@sun.com