Network Working Group V. Rawat
Request for Comments: 3070 ONI Systems, Inc.
Category: Standards Track R. Tio
S. Nanji
Redback Networks, Inc.
R. Verma
Deloitte Consulting
February 2001
Network Working Group V. Rawat
Request for Comments: 3070 ONI Systems, Inc.
Category: Standards Track R. Tio
S. Nanji
Redback Networks, Inc.
R. Verma
Deloitte Consulting
February 2001
Layer Two Tunneling Protocol (L2TP) over Frame Relay
帧中继上的第二层隧道协议（L2TP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel Point-to-Point (PPP) sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over the User Datagram Protocol (UDP) and the Internet Protocol (IP). This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs).
第二层隧道协议（L2TP）描述了一种隧道点对点（PPP）会话的机制。该协议被设计为独立于它所运行的媒体。基本规范描述了如何实现它以在用户数据报协议（UDP）和互联网协议（IP）上运行。本文档描述了L2TP如何在帧中继永久虚拟电路（PVC）和交换虚拟电路（SVC）上实现。
Applicability
适用性
This specification is intended for those implementations which desire to use facilities which are defined for L2TP and applies only to the use of Frame Relay pont-to-point circuits.
本规范适用于那些希望使用为L2TP定义的设施的实现，并且仅适用于帧中继桥到点电路的使用。
L2TP [1] defines a general purpose mechanism for tunneling PPP over various media. By design, it insulates L2TP operation from the details of the media over which it operates. The base protocol specification illustrates how L2TP may be used in IP environments. This document specifies the encapsulation of L2TP over native Frame Relay and addresses relevant issues.
L2TP[1]定义了一种通用机制，用于在各种媒体上对PPP进行隧道传输。通过设计，它将L2TP操作与其操作介质的细节隔离开来。基本协议规范说明了L2TP如何在IP环境中使用。本文档规定了L2TP在本机帧中继上的封装，并解决了相关问题。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
In this section we describe in high level terms the scope of the problem being addressed. Topology:
在本节中，我们将从高层次上描述正在解决的问题的范围。拓扑结构：
+------+ +---------------+ |
| PSTN | | Frame Relay | |
User--| |----LAC ===| |=== LNS --+ LANs
| ISDN | | Cloud | |
+------+ +---------------+ |
+------+ +---------------+ |
| PSTN | | Frame Relay | |
User--| |----LAC ===| |=== LNS --+ LANs
| ISDN | | Cloud | |
+------+ +---------------+ |
An L2TP Access Concentrator (LAC) is a device attached to the switched network fabric (e.g., PSTN or ISDN) or co-located with a PPP end system capable of handling the L2TP protocol. The LAC need only implement the media over which L2TP is to operate to pass traffic to one or more LNS's. It may tunnel any protocol carried within PPP.
L2TP接入集中器（LAC）是连接到交换网络结构（如PSTN或ISDN）或与能够处理L2TP协议的PPP终端系统共存的设备。LAC只需实现L2TP将在其上运行的介质，以将流量传递给一个或多个LN。它可以对PPP中的任何协议进行隧道传输。
L2TP Network Server (LNS) operates on any platform capable of PPP termination. The LNS handles the server side of the L2TP protocol. L2TP is connection-oriented. The LNS and LAC maintain state for each user that is attached to an LAC. A session is created when an end-to-end PPP connection is attempted between a user and the LNS. The datagrams related to a session are sent over the tunnel between the LAC and LNS. A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS.
L2TP网络服务器（LNS）在任何能够终止PPP的平台上运行。LNS处理L2TP协议的服务器端。L2TP是面向连接的。LNS和LAC为连接到LAC的每个用户维护状态。当尝试在用户和LNS之间建立端到端PPP连接时，将创建会话。与会话相关的数据报通过LAC和LN之间的隧道发送。隧道由LNS-LAC对定义。隧道在LAC和LN之间传输PPP数据报。
L2TP protocol operates at a level above the particular media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. L2TP over IP/UDP is described in the base L2TP specification [1]. Issues related to L2TP over Frame Relay are addressed in later sections of this document.
L2TP协议在其承载的特定媒体之上的级别上运行。然而，为了实现可互操作性，需要一些与媒体连接的细节。L2TP over IP/UDP在基本L2TP规范[1]中进行了描述。与L2TP帧间中继相关的问题将在本文档后面的章节中讨论。
L2TP MUST be able to share a Frame Relay virtual circuit (VC) with other protocols carried over the same VC. The Frame Relay header format for data packet needs to be defined to identify the protocol being carried in the packets. The Frame Relay network may not understand these formats.
L2TP必须能够与通过同一个虚拟电路承载的其他协议共享一个帧中继虚拟电路（VC）。需要定义数据包的帧中继报头格式，以识别数据包中承载的协议。帧中继网络可能不理解这些格式。
All protocols over this circuit MUST encapsulate their packets within a Q.922 frame. Additionally, frames must contain information necessary to identify the protocol carried within the frame relay Protocol Data Unit (PDU), thus allowing the receiver to properly process the incoming packet.
该电路上的所有协议都必须将其数据包封装在一个Q.922帧内。此外，帧必须包含识别帧中继协议数据单元（PDU）内承载的协议所需的信息，从而允许接收机正确处理传入分组。
The frame format for L2TP MUST be SNAP encapsulation as defined in RFC 1490 [6] and FRF3.1 [3]. SNAP format uses NLPID followed by Organizationally Unique Identifier and a PID.
L2TP的帧格式必须是RFC 1490[6]和FRF3.1[3]中定义的快照封装。快照格式使用NLPID，后跟组织唯一标识符和PID。
NLPID
NLPID
The single octet identifier provides a mechanism to allow easy protocol identification. For L2TP NLPID value 0x80 is used which indicates the presence of SNAP header.
单八位组标识符提供了一种机制，允许轻松识别协议。对于L2TP，使用NLPID值0x80，表示存在快照标头。
OUI & PID
OUI和PID
The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5E identifies IANA who administers the meaning of the Protocol Identifier (PID) 0x0007. Together they identify a distinct protocol.
三个八位组的组织唯一标识符（OUI）0x00-00-5E标识管理协议标识符（PID）0x0007含义的IANA。它们共同确定了一个不同的协议。
Format of L2TP frames encapsulated in Frame Relay is given in Figure 1.
图1给出了封装在帧中继中的L2TP帧的格式。
Octet 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Q.922 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Control 0x03 | pad 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | NLPID 0x80 | OUI 0x00 |
+-+-+-+-+-+-+-+-+ +
7 | OUI 0x00-5E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | PID 0x0007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| L2TP packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Octet 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Q.922 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Control 0x03 | pad 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | NLPID 0x80 | OUI 0x00 |
+-+-+-+-+-+-+-+-+ +
7 | OUI 0x00-5E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | PID 0x0007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| L2TP packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Format for L2TP frames encapsulated in Frame Relay
图1帧中继中封装的L2TP帧格式
FRF.12 [5] is the Frame Relay Fragmentation Implementation Agreement. If fragmentation is not supported, the two Frame Relay endpoints MUST support an MTU size of at least 1526 which is based on adding the PPP Max-Receive-Unit size with the PPP header size with the Max L2TP Header Size with the Frame Relay header size (PPP header size is the protocol field size plus HDLC framing bytes, which is required by L2TP). To avoid packet discards on the Frame Relay interface, the RECOMMENDED default Frame Relay MTU is 1564 based on a PPP default MRU of 1500. The means to ensure these MTU settings are left to implementation.
FRF.12[5]是帧中继分段实施协议。如果不支持分段，则两个帧中继端点必须支持至少1526的MTU大小，这是基于将PPP最大接收单元大小与PPP报头大小、最大L2TP报头大小与帧中继报头大小相加（PPP报头大小是协议字段大小加上HDLC帧字节，L2TP需要）。为了避免帧中继接口上的数据包丢弃，基于PPP默认MRU 1500，推荐的默认帧中继MTU为1564。确保这些MTU设置的方法留待实施。
In general, QoS mechanisms can be roughly provided for with proprietary mechanisms localized within the LAC or LNS. QoS considerations are beyond the scope of this document.
一般来说，QoS机制可以通过定位在LAC或LN中的专有机制大致提供。QoS考虑超出了本文档的范围。
In case of Frame Relay SVCs, connection setup will be triggered when L2TP tries to create a tunnel. Details of triggering mechanism are left to implementation. There SHALL NOT be any change in Frame Relay SVC signaling due to L2TP. The endpoints of the L2TP tunnel MUST be identified by X.121/E.164 addresses in case of Frame Relay SVC. These addresses MAY be obtained as tunnel endpoints for a user as defined in [4]. In case of PVCs, the Virtual Circuit to carry L2TP traffic MAY be configured administratively. The endpoints of the tunnel MUST be identified by DLCI, assigned to the PVC at configuration time. This DLCI MAY be obtained as tunnel endpoints for a user as defined in [4].
对于帧中继SVC，L2TP尝试创建隧道时将触发连接设置。触发机制的细节留待实现。帧中继SVC信号不得因L2TP而发生任何变化。对于帧中继SVC，L2TP隧道的端点必须由X.121/E.164地址标识。这些地址可以作为[4]中定义的用户的隧道端点获得。在pvc的情况下，可以管理性地配置承载L2TP业务的虚拟电路。隧道的端点必须由DLCI标识，并在配置时分配给PVC。该DLCI可作为[4]中定义的用户的隧道端点获得。
There SHALL be no framing issues between PPP and Frame Relay. PPP frames received by LAC from remote user are stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over Frame Relay tunnel.
PPP和帧中继之间不应存在帧问题。LAC从远程用户接收到的PPP帧被去除CRC、链路帧和透明字节，封装在L2TP中，并通过帧中继隧道转发。
Currently there is no standard specification for Frame Relay security although the Frame Relay Forum is working on a Frame Relay Privacy Agreement. In light of this work, the issue of security will be re-examined at a later date to see if L2TP over Frame Relay specific protection mechanisms are still required. In the interim, basic security issues are discussed in the base L2TP specification [1].
尽管帧中继论坛正在制定一项帧中继隐私协议，但目前还没有关于帧中继安全的标准规范。鉴于这项工作，将在稍后重新审查安全问题，以确定是否仍然需要L2TP帧间继电器专用保护机制。在此期间，基本L2TP规范[1]讨论了基本安全问题。
Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com Corporation) contributed to the editing of this document.
Ken Pierce（3Com公司）和Rick Dynarski 3Com公司）对本文件的编辑做出了贡献。
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.
[1] 汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特“第二层隧道协议‘L2TP’”，RFC 26611999年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Multiprotocol Encapsulation Implementation Agreement, FRF.3.1 , Frame Relay Forum Technical Committee, June 1995.
[3] 多协议封装实施协议，FRF.3.1，帧中继论坛技术委员会，1995年6月。
[4] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[4] Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[5] Frame Relay Fragmentation Implementation Agreement, FRF.12, Frame Relay Forum Technical Committee, December 1997.
[5] 帧中继分段实施协议，FRF.12，帧中继论坛技术委员会，1997年12月。
[6] Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
[6] Bradley，T.，Brown，C.和A.Malis，“帧中继上的多协议互连”，RFC 1490，1993年7月。
Vipin Rawat ONI Systems, Inc. 166 Baypointe Parkway San Jose CA 95134
Vipin Rawat ONI Systems，Inc.加利福尼亚州圣何塞Baypointe公园路166号95134
EMail: vrawat@oni.com
EMail: vrawat@oni.com
Rene Tio Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Rene Tio Redback Networks，Inc.加利福尼亚州圣何塞霍尔格大道300号，邮编95134
EMail: tor@redback.com
EMail: tor@redback.com
Rohit Verma Deloitte Consulting 180 N. Stetson Avenue Chicago Illinois 60601
伊利诺伊州芝加哥Stetson大道北180号Rohit Verma Deloitte Consulting 60601
EMail: rverma@dc.com
EMail: rverma@dc.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Suhail Nanji Redback Networks，Inc.加利福尼亚州圣何塞霍尔格大道300号，邮编95134
EMail: suhail@redback.com
EMail: suhail@redback.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。