Internet Engineering Task Force (IETF) L. Yong
Request for Comments: 7173 D. Eastlake 3rd
Category: Standards Track S. Aldrin
ISSN: 2070-1721 Huawei
J. Hudson
Brocade
May 2014
Internet Engineering Task Force (IETF) L. Yong
Request for Comments: 7173 D. Eastlake 3rd
Category: Standards Track S. Aldrin
ISSN: 2070-1721 Huawei
J. Hudson
Brocade
May 2014
Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires
使用伪线的大量链路透明互连（TRILL）传输
Abstract
摘要
This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.
本文档指定了如何根据现有的TRILL和伪线仿真端到端（PWE3）标准，使用伪线互连一对透明互连的多链路（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/rfc7173.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7173.
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.....................................................2
1.1. Conventions Used in This Document...........................2
2. PWE3 Interconnection of TRILL Switches...........................3
2.1. PWE3 Type-Independent Details...............................3
2.2. PPP PWE3 Transport of TRILL.................................4
3. Security Considerations..........................................6
Appendix A. Use of Other Pseudowire Types ..........................7
Acknowledgements ...................................................8
Normative References ...............................................9
Informative References ............................................10
1. Introduction.....................................................2
1.1. Conventions Used in This Document...........................2
2. PWE3 Interconnection of TRILL Switches...........................3
2.1. PWE3 Type-Independent Details...............................3
2.2. PPP PWE3 Transport of TRILL.................................4
3. Security Considerations..........................................6
Appendix A. Use of Other Pseudowire Types ..........................7
Acknowledgements ...................................................8
Normative References ...............................................9
Informative References ............................................10
The Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides optimal pair-wise data frame routing without configuration in multi-hop networks with arbitrary topology. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement TRILL are called TRILL switches or Routing Bridges (RBridges).
多链路透明互连（TRILL）协议[RFC6325]在具有任意拓扑结构的多跳网络中提供了无需配置的最佳成对数据帧路由。TRILL支持单播和多播流量的多路径传输。实现TRILL的设备称为TRILL交换机或路由桥（rbridge）。
Links between TRILL switches can be based on arbitrary link protocols, for example, PPP [RFC6361], as well as Ethernet [RFC6325]. A set of connected TRILL switches together form a TRILL campus that is bounded by end stations and Layer 3 routers.
TRILL交换机之间的链路可以基于任意链路协议，例如PPP[RFC6361]和以太网[RFC6325]。一组连接的TRILL交换机一起构成一个TRILL园区，由终端站和第3层路由器限定。
This document specifies how to interconnect a pair of TRILL switch ports using a pseudowire under existing TRILL and PWE3 (Pseudowire Emulation End-to-End) standards.
本文档指定了如何根据现有TRILL和PWE3（伪线仿真端到端）标准，使用伪线互连一对TRILL交换机端口。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Acronyms used in this document include the following:
本文件中使用的首字母缩略词包括：
IS-IS - Intermediate System to Intermediate System [IS-IS]
IS-IS-中间系统至中间系统[IS-IS]
MPLS - Multi-Protocol Label Switching
多协议标签交换
PPP - Point-to-Point Protocol [RFC1661]
PPP-点对点协议[RFC1661]
PW - Pseudowire [RFC3985]
PW-伪线[RFC3985]
PWE3 - PW Emulation End-to-End
PWE3-PW仿真端到端
RBridge - Routing Bridge, an alternative name for a TRILL switch
RBridge-路由桥，TRILL交换机的另一个名称
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
TRILL-大量链路的透明互连[RFC6325]
TRILL Switch - A device implementing the TRILL protocol
颤音开关-实现颤音协议的设备
When a pseudowire is used to interconnect a pair of TRILL switch ports, a PPP [RFC4618] pseudowire is used as described below. The pseudowire between such ports can be signaled [RFC4447] or manually configured. In this context, the TRILL switch ports at the ends of the pseudowire are acting as native service processing (NSP) elements [RFC3985] and, assuming that the pseudowires are over MPLS or IP [RFC4023] networks, as label switched or IP routers at the TRILL switch ports.
当使用伪线互连一对TRILL交换机端口时，使用PPP[RFC4618]伪线，如下所述。这些端口之间的伪线可以发信号[RFC4447]或手动配置。在此上下文中，伪线末端的TRILL交换机端口充当本机服务处理（NSP）元素[RFC3985]，并假设伪线通过MPLS或IP[RFC4023]网络，充当TRILL交换机端口处的标签交换或IP路由器。
Pseudowires provide transparent transport, and the two TRILL switch ports appear directly interconnected with a transparent link. With such an interconnection, the TRILL adjacency over the link is automatically discovered and established through TRILL IS-IS control messages [RFC7177].
伪线提供透明传输，两个TRILL交换机端口通过透明链路直接互连。通过这种互连，通过TRILL is-is控制消息自动发现并建立链路上的TRILL邻接[RFC7177]。
A pseudowire is carried over a packet switched network tunnel [RFC3985], for example, an MPLS or MPLS-TP label switched path tunnel in MPLS networks. Either a signaling protocol or manual configuration can be used to configure a label switched path tunnel between two TRILL switch ports. This application needs no additions to the existing pseudowire standards.
伪线通过分组交换网络隧道[RFC3985]承载，例如，MPLS网络中的MPLS或MPLS-TP标签交换路径隧道。可以使用信令协议或手动配置来配置两个TRILL交换机端口之间的标签交换路径隧道。此应用程序不需要添加到现有的伪线标准中。
The sending pseudowire TRILL switch port SHOULD map the inner priority of the TRILL Data packets being sent to the Traffic Class field of the pseudowire label [RFC5462] so as to minimize the probability that higher priority TRILL Data packets will be discarded due to excessive TRILL Data packets of lower priority.
发送伪线颤音交换端口应将正在发送的颤音数据包的内部优先级映射到伪线标签[RFC5462]的流量类别字段，以最小化由于优先级较低的颤音数据包过多而丢弃高优先级颤音数据包的概率。
TRILL IS-IS PDUs critical to establishing and maintaining adjacency (Hello and MTU PDUs) SHOULD be sent with the MPLS Traffic Class that calls for handling with the maximum priority. Other TRILL IS-IS PDUs SHOULD be sent with the MPLS Traffic Class denoting the highest priority that is less than the maximum priority. TRILL Data packets SHOULD be sent with appropriate MPLS Traffic Classes, typically mapped from the TRILL Data packet priority, such that TRILL Data packet Traffic Classes denote priorities less than the priorities
TRILL IS-IS PDU对于建立和维护邻接关系（Hello和MTU PDU）至关重要，应与MPLS流量类一起发送，该类要求以最大优先级进行处理。其他TRILL IS-IS PDU应与MPLS通信量类别一起发送，表示低于最大优先级的最高优先级。TRILL数据包应使用适当的MPLS流量类别发送，通常从TRILL数据包优先级映射，使得TRILL数据包流量类别表示优先级小于优先级
used for TRILL IS-IS PDUs. This minimizes the probability of other traffic interfering with these important control PDUs and causing false loss of adjacency or other control problems.
用于TRILL IS-IS PDU。这将使其他交通干扰这些重要控制PDU并导致邻接错误丢失或其他控制问题的可能性降至最低。
If a pseudowire supports fragmentation and reassembly (a feature that has received little or no deployment), then there is no reason to do TRILL MTU testing on it, and the pseudowire will not be a constraint on the TRILL campus-wide MTU size (Sz) (see Section 4.3.1 of [RFC6325]). If the pseudowire does not support fragmentation (the more common case), then the available TRILL IS-IS packet payload size over the pseudowire (taking into account MPLS encapsulation with a control word) or some lower value, MUST be used in helping to determine MTU size (Sz) (see Section 5 of [RFC7180]).
如果伪线支持分段和重新组装（一种很少或没有部署的功能），则没有理由对其进行TRILL MTU测试，并且伪线不会限制TRILL校园范围的MTU大小（Sz）（参见[RFC6325]第4.3.1节）。如果伪线不支持分段（更常见的情况），则必须使用伪线上可用的TRILL IS-IS数据包有效负载大小（考虑到带有控制字的MPLS封装）或一些较低的值来帮助确定MTU大小（Sz）（参见[RFC7180]的第5节）。
An intervening MPLS label switched router or similar packet switched network device has no awareness of TRILL. Such devices will not change the TRILL Header hop count.
中间的MPLS标签交换路由器或类似的分组交换网络设备不知道TRILL。这样的设备不会改变颤音头跳数。
For a PPP pseudowire (PW type = 0x0007), the two TRILL switch ports being connected are configured to form a pseudowire with PPP encapsulation [RFC4618]. After the pseudowire is established and TRILL use is negotiated within PPP, the two TRILL switch ports appear directly connected with a PPP link [RFC1661] [RFC6361].
对于PPP伪线（PW类型=0x0007），连接的两个TRILL交换机端口被配置为形成具有PPP封装的伪线[RFC4618]。建立伪线并在PPP内协商TRILL使用后，两个TRILL交换机端口似乎直接与PPP链路[RFC1661][RFC6361]连接。
If pseudowire interconnection of two TRILL switch ports is signaled [RFC4447], the initiating TRILL switch port MUST attempt the connection setup with pseudowire type PPP (0x0007).
如果两个TRILL交换机端口的伪线互连发出信号[RFC4447]，则启动TRILL交换机端口必须尝试使用伪线类型PPP（0x0007）进行连接设置。
Behavior for TRILL with a PPP pseudowire continues to follow that of TRILL over PPP as specified in Section 3 of [RFC6361].
按照[RFC6361]第3节的规定，带PPP伪线的颤音行为继续遵循PPP上颤音的行为。
The following figures show what a TRILL Data packet and TRILL IS-IS packet look like over such a pseudowire in the MPLS case, assuming no TRILL Header extensions:
下图显示了在MPLS情况下，假设没有TRILL报头扩展，在这种伪线上TRILL数据包和TRILL IS-IS包的外观：
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Control Word | 4 octets
+--------------------------------+
| PPP Header 0x005d | 2 octets
+--------------------------------+
| TRILL Header | 6 octets
+--------------------------------+
| Destination MAC Address | 6 octets
+--------------------------------+
| Source MAC Address | 6 octets
+--------------------------------+
| Data Label | 4 or 8 octets
+--------------------------------+
| Payload Body | variable
+--------------------------------+
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Control Word | 4 octets
+--------------------------------+
| PPP Header 0x005d | 2 octets
+--------------------------------+
| TRILL Header | 6 octets
+--------------------------------+
| Destination MAC Address | 6 octets
+--------------------------------+
| Source MAC Address | 6 octets
+--------------------------------+
| Data Label | 4 or 8 octets
+--------------------------------+
| Payload Body | variable
+--------------------------------+
Figure 1: TRILL Data Packet in Pseudowire
图1：伪线中的颤音数据包
"Data Label" is the VLAN Label or Fine-Grained Label [RFC7172] of the payload.
“数据标签”是有效负载的VLAN标签或细粒度标签[RFC7172]。
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Control Word | 4 octets
+--------------------------------+
| PPP Header 0x405d | 2 octets
+--------------------------------+
| Common IS-IS Header | 8 octets
+--------------------------------+
| IS-IS PDU Type Specific Header | variable
+--------------------------------+
| IS-IS TLVs | variable
+--------------------------------+
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Control Word | 4 octets
+--------------------------------+
| PPP Header 0x405d | 2 octets
+--------------------------------+
| Common IS-IS Header | 8 octets
+--------------------------------+
| IS-IS PDU Type Specific Header | variable
+--------------------------------+
| IS-IS TLVs | variable
+--------------------------------+
Figure 2: TRILL IS-IS Packet in Pseudowire
图2：伪线中的TRILL IS-IS数据包
The PPP Header fields (0x005d and 0x405d, respectively) for TRILL Data and IS-IS packets shown above are specified in [RFC6361].
[RFC6361]中指定了上述TRILL数据和IS-IS数据包的PPP头字段（分别为0x005d和0x405d）。
TRILL-level security mechanisms, such as the ability to use authentication with TRILL IS-IS PDUs [RFC6325], are not affected by link technology, such as the use of pseudowire links as specified in this document.
TRILL级别的安全机制，例如使用TRILL IS-IS PDU[RFC6325]进行身份验证的能力，不受链接技术的影响，例如使用本文档中指定的伪线链接。
Link security may be useful in improving TRILL campus security. TRILL is transported over pseudowires as TRILL over PPP over pseudowires, pseudowires are over MPLS or IP, and MPLS and IP are over some lower-level link technology. Thus, link security below the TRILL level for a pseudowire link could be provided by PPP security, pseudowire security, MPLS or IP security, or security of the link technology supporting MPLS or IP.
链接安全性可能有助于提高TRILL校园安全性。TRILL通过伪线传输，就像通过伪线传输PPP上的TRILL一样，伪线通过MPLS或IP传输，MPLS和IP通过一些较低级别的链路技术传输。因此，伪线链路的TRILL级别以下的链路安全可以通过PPP安全、伪线安全、MPLS或IP安全或支持MPLS或IP的链路技术的安全来提供。
PPP TRILL security considerations are discussed in [RFC6361]. For security considerations introduced by carrying PPP TRILL links over pseudowires, see [RFC3985], which discusses the risks introduced by sending protocols that previously assumed a point-to-point link on a pseudowire built on a packet switched network (PSN). However, the PPP layer in TRILL transport by pseudowire is somewhat vestigial and intended primarily as a convenient way to use existing PPP code points to identify TRILL Data packets and TRILL IS-IS packets. Furthermore, existing PPP security standards are arguably questionable in terms of current security criteria. For these reasons, it is NOT RECOMMENDED to use PPP security in the transport of TRILL by pseudowires as specified in this document.
[RFC6361]中讨论了PPP TRILL安全注意事项。有关通过伪线承载PPP TRILL链路所引入的安全考虑，请参见[RFC3985]，其中讨论了发送协议所引入的风险，该协议先前假设在分组交换网络（PSN）上构建的伪线上存在点对点链路。然而，伪线TRILL传输中的PPP层有点退化，主要用于使用现有PPP码点来识别TRILL数据包和TRILL is-is包。此外，就目前的安全标准而言，现有PPP安全标准可能存在疑问。出于这些原因，不建议在本文件规定的伪线传输TRILL时使用PPP安全性。
It is RECOMMENDED that link security be provided at the layers supporting pseudowires transporting TRILL, that is, at the MPLS or IP layer or the link layer transporting MPLS or IP.
建议在支持传输TRILL的伪线的层上提供链路安全性，即在MPLS或IP层或传输MPLS或IP的链路层上。
For applications involving sensitive data, end-to-end security should always be considered, in addition to link security, to provide security in depth. In this context, such end-to-end security should be between the end stations involved so as to protect the entire path to, through, and from the TRILL campus.
对于涉及敏感数据的应用程序，除了链路安全性外，还应始终考虑端到端安全性，以提供深入的安全性。在这种情况下，这种端到端安全应该在相关的端站之间进行，以保护进出TRILL校园的整个路径。
For general TRILL protocol security considerations, see [RFC6325].
有关TRILL协议的一般安全注意事项，请参阅[RFC6325]。
This informational appendix briefly discusses the use of pseudowire types other than PPP for the transport of TRILL.
本信息性附录简要讨论了除PPP以外的伪导线类型在TRILL传输中的使用。
The use of Ethernet pseudowires [RFC4448] was examined by the authors and would be possible without change to such pseudowires; however, this would require an additional 12 or 16 bytes per packet within the payload being transmitted over the pseudowire for a TRILL Data packet (Figure 3) and a TRILL IS-IS packet (Figure 4) over such an Ethernet pseudowire in the MPLS case, assuming no TRILL Header extensions (compare with Figures 1 and 2):
作者对以太网伪线[RFC4448]的使用进行了研究，并且在不改变此类伪线的情况下是可能的；然而，在MPLS情况下，对于TRILL数据包（图3）和TRILL IS-IS包（图4），在通过这种以太网伪线传输的有效载荷内，假设没有TRILL报头扩展（与图1和图2相比），这将需要额外的12或16个字节：
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Optional Control Word | 4 octets
+--------------------------------+
| TRILL Hop Dest. MAC Address | 6 octets
+--------------------------------+
| TRILL Hop Source MAC Address | 6 octets
+--------------------------------+
|Optional VLAN and/or other tags | variable
+--------------------------------+
| TRILL Ethertype (0x22f3) | 2 octets
+--------------------------------+
| TRILL Header | 6 octets
+--------------------------------+
| Destination MAC Address | 6 octets
+--------------------------------+
| Source MAC Address | 6 octets
+--------------------------------+
| Data Label | 4 or 8 octets
+--------------------------------+
| Payload Body | variable
+--------------------------------+
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Optional Control Word | 4 octets
+--------------------------------+
| TRILL Hop Dest. MAC Address | 6 octets
+--------------------------------+
| TRILL Hop Source MAC Address | 6 octets
+--------------------------------+
|Optional VLAN and/or other tags | variable
+--------------------------------+
| TRILL Ethertype (0x22f3) | 2 octets
+--------------------------------+
| TRILL Header | 6 octets
+--------------------------------+
| Destination MAC Address | 6 octets
+--------------------------------+
| Source MAC Address | 6 octets
+--------------------------------+
| Data Label | 4 or 8 octets
+--------------------------------+
| Payload Body | variable
+--------------------------------+
Figure 3: TRILL Data Packet in Ethernet Pseudowire
图3：以太网伪线中的颤音数据包
"Data Label" is the VLAN Label or Fine-Grained Label [RFC7172] of the payload.
“数据标签”是有效负载的VLAN标签或细粒度标签[RFC7172]。
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Optional Control Word | 4 octets
+--------------------------------+
| TRILL Hop Dest. MAC Address | 6 octets
+--------------------------------+
| TRILL Hop Source MAC Address | 6 octets
+--------------------------------+
|Optional VLAN and/or other tags | variable
+--------------------------------+
| Layer 2 IS-IS Ethertype 0x22f4 | 2 octets
+--------------------------------+
| Common IS-IS Header | 8 octets
+--------------------------------+
| IS-IS PDU Type Specific Header | variable
+--------------------------------+
| IS-IS TLVs | variable
+--------------------------------+
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Optional Control Word | 4 octets
+--------------------------------+
| TRILL Hop Dest. MAC Address | 6 octets
+--------------------------------+
| TRILL Hop Source MAC Address | 6 octets
+--------------------------------+
|Optional VLAN and/or other tags | variable
+--------------------------------+
| Layer 2 IS-IS Ethertype 0x22f4 | 2 octets
+--------------------------------+
| Common IS-IS Header | 8 octets
+--------------------------------+
| IS-IS PDU Type Specific Header | variable
+--------------------------------+
| IS-IS TLVs | variable
+--------------------------------+
Figure 4: TRILL IS-IS Packet in Ethernet Pseudowire
图4：以太网伪线中的TRILL IS-IS数据包
It would also be possible to specify a new pseudowire type for TRILL traffic, but the authors feel that any efficiency gain over PPP pseudowires would be too small to be worth the complexity of adding such a specification. Furthermore, using PPP pseudowire encoding means that any traffic dissector that understands TRILL PPP encoding [RFC6361] and PPP pseudowires [RFC4618] will automatically be able to recursively decode TRILL transported by pseudowire.
也可以为TRILL流量指定一种新的伪线类型，但作者认为，与PPP伪线相比，任何效率增益都太小，不值得添加这样的规范。此外，使用PPP伪线编码意味着任何理解TRILL PPP编码[RFC6361]和PPP伪线[RFC4618]的流量解析器将能够自动递归地解码伪线传输的TRILL。
Acknowledgements
致谢
Thanks for the valuable comments from the following, who are listed in alphabetic order:
感谢以下人员的宝贵意见，他们按字母顺序排列：
Stewart Bryant, Stephen Farrell, Brian Haberman, Christer Holmberg, Joel Jaeggli, Barry Leiba, Erik Nordmark, Yaron Sheffer, and Yaakov (J) Stein.
Stewart Bryant、Stephen Farrell、Brian Haberman、Christer Holmberg、Joel Jaeggli、Barry Leiba、Erik Nordmark、Yaron Sheffer和Yaakov（J）Stein。
Normative References
规范性引用文件
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618]Martini，L.，Rosen，E.，Heron，G.，和A.Malis，“通过MPLS网络传输PPP/高级数据链路控制（HDLC）的封装方法”，RFC 4618，2006年9月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，2011年7月。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 63612011年8月。
[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.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链路的透明互连（TRILL）：细粒度标记”，RFC 7172，2014年5月。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
[RFC7180]Eastlake 3rd，D.，Zhang，M.，Ghanwani，A.，Manral，V.，和A.Banerjee，“大量链路的透明互连（TRILL）：澄清、更正和更新”，RFC 7180，2014年5月。
Informative References
资料性引用
[IS-IS] ISO/IEC 10589:2002, Second Edition, "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)", 2002.
[IS-IS]ISO/IEC 10589:2002，第二版，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，2002年。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC4023，2005年3月。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（TRILL）：邻接”，RFC 7177，2014年5月。
Authors' Addresses
作者地址
Lucy Yong Huawei Technologies 5340 Legacy Drive Plano, TX 75024 USA
Lucy Yong华为技术5340美国德克萨斯州普莱诺市传统硬盘75024
Phone: +1-469-227-5837
EMail: lucy.yong@huawei.com
Phone: +1-469-227-5837
EMail: lucy.yong@huawei.com
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald E.Eastlake第三华为技术有限公司美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA
美国加利福尼亚州圣克拉拉中央高速公路2330号Sam Aldrin华为技术公司，邮编95050
Phone: +1-408-330-4517
EMail: sam.aldrin@huawei.com
Phone: +1-408-330-4517
EMail: sam.aldrin@huawei.com
Jon Hudson Brocade 130 Holger Way San Jose, CA 95134 USA
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