Internet Engineering Task Force (IETF) J. Carlson
Request for Comments: 6361 WorkingCode
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei
August 2011
Internet Engineering Task Force (IETF) J. Carlson
Request for Comments: 6361 WorkingCode
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei
August 2011
PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol
PPP多链路透明互连（TRILL）协议控制协议
Abstract
摘要
The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links.
点到点协议（PPP）定义了一种链路控制协议（LCP）和一种通过点到点链路协商使用多协议通信量的方法。本文档描述了PPP对大量链路透明互连（TRILL）协议的支持，允许通过PPP链路在路由桥（RBridge）之间进行直接通信。
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/rfc6361.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6361.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
2. PPP TRILL Negotiation ...........................................3
2.1. TNCP Packet Format .........................................3
2.2. TNP Packet Format ..........................................4
2.3. TLSP Packet Format .........................................5
3. TRILL PPP Behavior ..............................................5
4. Security Considerations .........................................6
5. IANA Considerations .............................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
7. Acknowledgements ................................................8
1. Introduction ....................................................2
2. PPP TRILL Negotiation ...........................................3
2.1. TNCP Packet Format .........................................3
2.2. TNP Packet Format ..........................................4
2.3. TLSP Packet Format .........................................5
3. TRILL PPP Behavior ..............................................5
4. Security Considerations .........................................6
5. IANA Considerations .............................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
7. Acknowledgements ................................................8
The TRILL Protocol [RFC6325] defines a set of mechanisms used to communicate between RBridges. These devices can bridge together large 802 networks using link-state protocols in place of the traditional spanning tree mechanisms [RFC5556].
TRILL协议[RFC6325]定义了一组用于在RBridge之间通信的机制。这些设备可以使用链路状态协议代替传统的生成树机制将大型802网络桥接在一起[RFC5556]。
Over Ethernet, TRILL uses two separate Ethertypes to distinguish between encapsulation headers, which carry user data, and link-state messages, which compute network topology using a protocol based on [IS-IS] [RFC6326]. These two protocols must be distinguished from one another, and segregated from all other traffic.
在以太网上，TRILL使用两种不同的以太网类型来区分封装头（承载用户数据）和链路状态消息（使用基于[IS-IS][RFC6326]的协议计算网络拓扑）。这两个协议必须相互区分，并与所有其他通信隔离。
In a network where PPP [RFC1661] is used to interconnect routers (often over telecommunications links), it may be advantageous to be able to bridge between Ethernet segments over those PPP links, and thus integrate remote networks with an existing TRILL cloud. The existing Bridging Control Protocol (BCP) [RFC3518] allows direct bridging of Ethernet frames over PPP. However, this mechanism is inefficient and inadequate for TRILL, which can be optimized for use over PPP links.
在PPP[RFC1661]用于互连路由器（通常通过电信链路）的网络中，能够通过这些PPP链路在以太网段之间架桥，从而将远程网络与现有TRILL云集成可能是有利的。现有的桥接控制协议（BCP）[RFC3518]允许通过PPP直接桥接以太网帧。然而，这种机制效率低下，不适合TRILL，TRILL可以通过PPP链路进行优化。
To interconnect these devices over PPP links, three protocol numbers are needed, and are reserved as follows:
要通过PPP链路互连这些设备，需要三个协议编号，并保留如下：
Value (in hex) Protocol Name
-------------- -------------------------------------
005d TRILL Network Protocol (TNP)
405d TRILL Link State Protocol (TLSP)
805d TRILL Network Control Protocol (TNCP)
Value (in hex) Protocol Name
-------------- -------------------------------------
005d TRILL Network Protocol (TNP)
405d TRILL Link State Protocol (TLSP)
805d TRILL Network Control Protocol (TNCP)
The usage of these three protocols is described in detail in the following section.
这三个协议的使用将在下一节中详细描述。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The TRILL Network Control Protocol (TNCP) is responsible for negotiating the use of the TRILL Network Protocol (TNP) and TRILL Link State Protocol (TLSP) on a PPP link. TNCP uses the same option negotiation mechanism and state machine as described for LCP (Section 4 of [RFC1661]).
TRILL网络控制协议（TNCP）负责协商在PPP链路上使用TRILL网络协议（TNP）和TRILL链路状态协议（TLSP）。TNCP使用与LCP相同的选项协商机制和状态机（见[RFC1661]第4节）。
TNCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. Any TNCP packets received when not in that phase MUST be silently ignored.
在PPP达到网络层协议阶段之前，不得交换TNCP数据包。当不在该阶段时接收到的任何TNCP数据包都必须被静默忽略。
The encapsulated network layer data, carried in TNP packets, and topology information, carried in TLSP packets, MUST NOT be sent unless TNCP is in the Opened state. If a TNP or TLSP packet is received when TNCP is not in the Opened state and LCP is in the Opened state, an implementation MUST silently discard the unexpected TNP or TLSP packet.
除非TNCP处于打开状态，否则不得发送TNP数据包中携带的封装网络层数据和TLSP数据包中携带的拓扑信息。如果在TNCP未处于打开状态且LCP处于打开状态时接收到TNP或TLSP数据包，则实现必须自动丢弃意外的TNP或TLSP数据包。
Exactly one TNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex 805d (TNCP). A summary of the TNCP packet format is shown below. The fields are transmitted from left to right.
PPP信息字段中仅携带一个TNCP数据包，PPP协议字段设置为hex 805d（TNCP）。TNCP数据包格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
密码
Only LCP Code values 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. All other codes SHOULD result in a TNCP Code-Reject reply.
仅使用LCP代码值1到7（配置请求、配置确认、配置Nak、配置拒绝、终止请求、终止确认和代码拒绝）。所有其他代码应导致TNCP代码拒绝回复。
Identifier and Length
标识符和长度
These are as documented for LCP.
这些是为LCP记录的。
Data
数据
This field contains data formatted as described in Section 5 of [RFC1661]. Codes 1-4 use Type-Length-Data sequences, Codes 5 and 6 use uninterpreted data, and Code 7 uses a Rejected-Packet, all as described in [RFC1661].
此字段包含[RFC1661]第5节中所述格式的数据。代码1-4使用类型长度数据序列，代码5和6使用未解释的数据，代码7使用被拒绝的数据包，所有这些都如[RFC1661]中所述。
Because no Configuration Options have been defined for TNCP, negotiating the use of the TRILL Protocol with IS-IS for the link state protocol is the default when no options are specified. A future document may specify the use of Configuration Options to enable different TRILL operating modes, such as the use of a different link state protocol.
由于没有为TNCP定义任何配置选项，因此在未指定选项时，默认情况下，与IS-IS协商使用TRILL协议作为链路状态协议。未来的文档可能会指定配置选项的使用，以启用不同的TRILL操作模式，例如使用不同的链路状态协议。
When TNCP is in the Opened state, TNP packets are sent by setting the PPP Protocol field to hex 005d (TNP) and placing TRILL-encapsulated data representing exactly one encapsulated packet in the PPP Information field.
当TNCP处于打开状态时，通过将PPP协议字段设置为十六进制005d（TNP）并将表示一个封装数据包的TRILL封装数据放置在PPP信息字段中，发送TNP数据包。
A summary of this format is provided below:
该格式的摘要如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress (RB1) Nickname | Inner Destination MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress (RB1) Nickname | Inner Destination MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This is identical to the TRILL Ethernet format (Section 4.1 of [RFC6325], "Ethernet Data Encapsulation"), except that the Outer MAC (Media Access Control) header and Ethertype are replaced by the PPP headers and Protocol Field, and the Ethernet Frame Check Sequence (FCS) is not present. Both user data and End-Station Address Distribution Information (ESADI) packets are encoded in this format.
这与TRILL Ethernet格式（RFC6325第4.1节，“以太网数据封装”）相同，只是外部MAC（媒体访问控制）报头和Ethertype被PPP报头和协议字段替换，并且以太网帧检查序列（FCS）不存在。用户数据和终端站地址分布信息（ESADI）数据包均采用这种格式编码。
The PPP FCS follows the encapsulated data on links where the PPP FCS is in use.
PPP FCS遵循使用PPP FCS的链路上的封装数据。
Unlike the TRILL Ethernet encapsulation, PPP nodes do not have MAC addresses, so no outer MAC is present. (High-Level Data Link Control (HDLC) addresses MAY be present in some situations; such usage is outside the scope of this document.)
与TRILL以太网封装不同，PPP节点没有MAC地址，因此不存在外部MAC。（在某些情况下可能存在高级数据链路控制（HDLC）地址；此类使用不在本文件的范围内。）
When TNCP is in the Opened state, TLSP packets are sent by setting the PPP Protocol field to hex 405d (TLSP) and placing exactly one IS-IS Payload (Section 4.2.3 of [RFC6325], "TRILL IS-IS Frames") in the PPP Information field.
当TNCP处于打开状态时，通过将PPP协议字段设置为十六进制405d（TLSP）并将一个is-is有效负载（RFC6325的第4.2.3节，“TRILL is-is帧”）准确放置在PPP信息字段中，发送TLSP数据包。
Note that point-to-point IS-IS links have only an arbitrary circuit ID, and do not use MAC addresses for identification.
请注意，点对点IS-IS链路只有一个任意的电路ID，并且不使用MAC地址进行标识。
1. On a PPP link, TRILL always uses point-to-point (P2P) Hellos. There is no need for TRILL-Hello frames, nor is per-port configuration necessary. P2P Hello messages, per "Point-to-Point IS to IS hello PDU" (Section 9.7 of [IS-IS]), do not use Neighbor IDs in the same manner as on Ethernet. However, per Section 4.2.4.1 of [RFC6325], the three-way IS-IS handshake using extended circuit IDs is required on point-to-point links, such as PPP.
1. 在PPP链接上，TRILL始终使用点对点（P2P）Hello。不需要TRILL Hello帧，也不需要每个端口配置。P2P Hello消息，根据“点对点IS to IS Hello PDU”（[IS-IS]第9.7节），不以与以太网相同的方式使用邻居ID。然而，根据[RFC6325]第4.2.4.1节，在点到点链路（如PPP）上需要使用扩展电路ID进行三向IS-IS握手。
2. RBridges are never appointed forwarders on PPP links. If an implementation includes BCP [RFC3518], then it MUST ensure that only one of BCP or TNCP is negotiated on a link, and not both. If the peer is an RBridge, then there is no need to pass unencapsulated frames, as the link can have no TRILL-ignorant peer to be concerned about. If the peer is not an RBridge, then TNCP negotiation fails and TRILL is not used on the link.
2. RBridge从未被指定为PPP链接上的转发器。如果实现包括BCP[RFC3518]，则必须确保在链路上只协商BCP或TNCP中的一个，而不是两者。如果对等点是RBridge，那么就不需要传递未封装的帧，因为链接可以没有需要关注的颤音无知对等点。如果对等方不是RBridge，则TNCP协商失败，且链路上不使用TRILL。
3. An implementation that has only PPP links might have no Organizationally Unique Identifier (OUI) that can form an IS-IS System ID. Resolving that issue is outside the scope of this document; however, it is strongly RECOMMENDED that all TRILL implementations have at least one zero-configuration mechanism to obtain a valid System ID. Refer to ISO/IEC 10589 [IS-IS] regarding System ID uniqueness requirements.
3. 只有PPP链接的实现可能没有可以形成IS-IS系统ID的组织唯一标识符（OUI）。解决该问题超出了本文档的范围；但是，强烈建议所有TRILL实现至少有一个零配置机制，以获得有效的系统ID。有关系统ID唯一性要求，请参阅ISO/IEC 10589[is-is]。
4. TRILL MTU-probe and TRILL MTU-ack messages (Section 4.3.2 of [RFC6325]) are not needed on a PPP link. Implementations MUST NOT send MTU-probe messages and SHOULD NOT reply to these messages. The MTU computed by LCP SHOULD be used instead. Negotiating an LCP MTU of at least 1524, to allow for an inner Ethernet payload of 1500 octets, is RECOMMENDED.
4. PPP链路上不需要TRILL MTU探测和TRILL MTU确认消息（RFC6325第4.3.2节）。实现不得发送MTU探测消息，也不得回复这些消息。应改用LCP计算的MTU。建议协商至少1524的LCP MTU，以允许1500个八位字节的内部以太网有效负载。
Existing PPP and IS-IS security mechanisms may play important roles in a network of RBridges interconnected by PPP links. At the TRILL IS-IS layer, the IS-IS authentication mechanism [RFC5304] [RFC5310] prevents fabrication of link-state control messages.
现有PPP和IS-IS安全机制可能在通过PPP链路互连的RBridge网络中发挥重要作用。在TRILL IS-IS层，IS-IS认证机制[RFC5304][RFC5310]防止链路状态控制消息的制造。
Not all implementations need to include specific security mechanisms at the PPP layer, for example if they are designed to be deployed only in cases where the networking environment is trusted or where other layers provide adequate security. A complete enumeration of possible deployment scenarios and associated threats and options is not possible and is outside the scope of this document. For applications involving sensitive data, end-to-end security should always be considered in addition to link security to provide security in depth.
并非所有实现都需要在PPP层包含特定的安全机制，例如，如果它们被设计为仅在网络环境受信任或其他层提供足够安全的情况下部署。不可能完整列举可能的部署场景以及相关的威胁和选项，这超出了本文档的范围。对于涉及敏感数据的应用程序，除了链路安全性外，还应始终考虑端到端安全性，以提供深入的安全性。
However, in case a PPP layer authentication mechanism is needed to protect the establishment of a link and identify a link with a known peer, implementation of the PPP Challenge Handshake Authentication Protocol (CHAP) [RFC1994] is RECOMMENDED. Should greater flexibility than that provided by CHAP be required, the Extensible Authentication Protocol (EAP) [RFC3748] is a good alternative.
然而，如果需要PPP层认证机制来保护链路的建立并识别与已知对等方的链路，则建议实施PPP质询握手认证协议（CHAP）[RFC1994]。如果需要比CHAP提供更大的灵活性，可扩展身份验证协议（EAP）[RFC3748]是一个很好的替代方案。
If TRILL-over-PPP packets also require confidentiality, the PPP Encryption Control Protocol (ECP) link encryption mechanisms [RFC1968] can protect the confidentiality and integrity of all packets on the PPP link.
如果TRILL over PPP数据包也需要保密，PPP加密控制协议（ECP）链路加密机制[RFC1968]可以保护PPP链路上所有数据包的保密性和完整性。
And when PPP is run over tunneling mechanisms, such as the Layer Two Tunneling Protocol (L2TP) [RFC3931], tunnel security protocols may be available.
当PPP通过隧道机制运行时，例如第二层隧道协议（L2TP）[RFC3931]，隧道安全协议可能可用。
For general TRILL protocol security considerations, see [RFC6325].
有关TRILL协议的一般安全注意事项，请参阅[RFC6325]。
IANA has assigned three PPP Protocol field values, 005d, 405d, and 805d, as described in Section 1 of this document.
IANA分配了三个PPP协议字段值005d、405d和805d，如本文件第1节所述。
IANA has created a new "PPP TNCP Configuration Option Types" registry in the PPP-Numbers registry, using the same format as the existing "PPP LCP Configuration Option Types" registry.
IANA在PPP编号注册表中创建了一个新的“PPP TNCP配置选项类型”注册表，使用与现有“PPP LCP配置选项类型”注册表相同的格式。
All TNCP Configuration Option Types except 0 are "Unassigned" and available for future use, based on "IETF Review", as described in BCP 26 [RFC5226]. Option 0 is allocated for use with Vendor-Specific Options, as described in [RFC2153].
根据BCP 26[RFC5226]中所述的“IETF审查”，除0之外的所有TNCP配置选项类型均为“未分配”，可供将来使用。选项0分配用于供应商特定选项，如[RFC2153]中所述。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[IS-IS] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO/IEC 10589:2002，第二版，2002年11月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968]Meyer，G.“PPP加密控制协议（ECP）”，RFC 1968，1996年6月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[RFC2153]辛普森，W.，“PPP供应商扩展”，RFC 2153，1997年5月。
[RFC3518] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)", RFC 3518, April 2003.
[RFC3518]Higashiyama，M.，Baker，F.，和T.Liao，“点对点协议（PPP）桥接控制协议（BCP）”，RFC3518，2003年4月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Ed.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月。
[RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", RFC 5556, May 2009.
[RFC5556]Touch，J.和R.Perlman，“大量链路的透明互连（TRILL）：问题和适用性声明”，RFC 5556，2009年5月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC6326]伊斯特莱克，班纳吉，A.，杜特，D.，帕尔曼，R.，和A.加瓦尼，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 63262011年7月。
The authors thank Jari Arkko, Stewart Bryant, Ralph Droms, Linda Dunbar, Adrian Farrel, Stephen Farrell, Radia Perlman, Mike Shand, and William A. Simpson for their comments and help.
作者感谢贾里·阿尔科、斯图尔特·布莱恩特、拉尔夫·德罗姆斯、琳达·邓巴、阿德里安·法雷尔、斯蒂芬·法雷尔、拉迪亚·帕尔曼、迈克·山德和威廉·辛普森的评论和帮助。
Authors' Addresses
作者地址
James Carlson WorkingCode 25 Essex Street North Andover, MA 01845 USA
詹姆斯·卡尔森工作代码美国马萨诸塞州安多弗市北埃塞克斯街25号01845
Phone: +1-781-301-2471
EMail: carlsonj@workingcode.com
Phone: +1-781-301-2471
EMail: carlsonj@workingcode.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