Network Working Group A. Singh
Request for Comments: 3355 Motorola
Category: Standards Track R. Turner
Paradyne
R. Tio
S. Nanji
Redback Networks
August 2002
Network Working Group A. Singh
Request for Comments: 3355 Motorola
Category: Standards Track R. Turner
Paradyne
R. Tio
S. Nanji
Redback Networks
August 2002
Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)
ATM适配层5（AAL5）上的第二层隧道协议（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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
The Layer Two Tunneling Protocol (L2TP) provides a standard method for transporting the link layer of the Point-to-Point Protocol (PPP) between a dial-up server and a Network Access Server, using a network connection in lieu of a physical point-to-point connection. This document describes the use of an Asynchronous Transfer Mode (ATM) network for the underlying network connection. ATM User-Network Interface (UNI) Signaling Specification Version 4.0 or Version 3.1 with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to the ATM network.
第二层隧道协议（L2TP）提供了一种标准方法，用于使用网络连接代替物理点到点连接，在拨号服务器和网络接入服务器之间传输点到点协议（PPP）的链路层。本文档描述了使用异步传输模式（ATM）网络进行底层网络连接。支持ATM用户网络接口（UNI）信令规范版本4.0或版本3.1以及ATM适配层5（AAL5）作为ATM网络的接口。
Applicability
适用性
This specification is intended for implementations of L2TP that use ATM to provide the communications link between the L2TP Access Concentrator and the L2TP Network Server.
本规范适用于使用ATM在L2TP接入集中器和L2TP网络服务器之间提供通信链路的L2TP实现。
The Point-to-Point Protocol (PPP) [RFC1661], is frequently used on the link between a personal computer with a dial modem and a network service provider, or NSP. The Layer Two Tunneling Protocol (L2TP) [RFC2661] enables a dial-up server to provide access to a remote NSP by extending the PPP connection through a tunnel in a network to which both it and the NSP are directly connected. A "tunnel" is a network layer connection between two nodes, used in the role of a data link layer connection between those nodes, possibly as part of a different network. In [RFC2661] the dial-up server is called an L2TP Access Concentrator, or LAC. The remote device that provides access to a network is called an L2TP Network Server, or LNS. L2TP uses a packet delivery service to create a tunnel between the LAC and the LNS. "L2TP is designed to be largely insulated from the details of the media over which the tunnel is established; L2TP requires only that the tunnel media provide packet oriented point-to-point connectivity" [RFC2661]. An ATM network with AAL5 offers a suitable form of packet oriented connection. This standard supplements [RFC2661] by providing details specific to the use of AAL5 for a point-to-point connection between LAC and LNS.
点对点协议（PPP）[RFC1661]常用于带有拨号调制解调器的个人计算机与网络服务提供商（NSP）之间的链路。第二层隧道协议（L2TP）[RFC2661]允许拨号服务器通过其和NSP直接连接的网络中的隧道扩展PPP连接，从而提供对远程NSP的访问。“隧道”是两个节点之间的网络层连接，用作这些节点之间的数据链路层连接，可能作为不同网络的一部分。在[RFC2661]中，拨号服务器称为L2TP访问集中器或LAC。提供网络访问的远程设备称为L2TP网络服务器或LNS。L2TP使用数据包交付服务在LAC和LN之间创建隧道。“L2TP的设计在很大程度上与建立隧道的介质的细节隔离；L2TP只要求隧道介质提供面向分组的点对点连接”[RFC2661]。带有AAL5的ATM网络提供了一种适合的面向分组的连接形式。本标准补充了[RFC2661]，提供了LAC和LNS之间使用AAL5进行点对点连接的具体细节。
Requirements keywords 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]中的说明进行解释。
A list of acronyms used in this document is given at the end of the document as Appendix A.
本文件中使用的首字母缩略词列表见附录A。
L2TP treats the underlying ATM AAL5 layer service as a bit-synchronous point-to-point link. In this context, the L2TP link corresponds to an ATM AAL5 virtual circuit (VC). The VC MUST be full-duplex, point to point, and it MAY be either dedicated (i.e., permanent, set up by provisioning) or switched (set up on demand.)
L2TP将底层ATM AAL5层服务视为位同步点到点链路。在此上下文中，L2TP链路对应于ATM AAL5虚拟电路（VC）。VC必须是全双工、点对点，并且可以是专用的（即永久的，通过供应设置）或交换的（按需设置）
The AAL5 message mode service, in the non-assured mode of operation, without the corrupted delivery option MUST be used.
必须使用非保证操作模式下的AAL5消息模式服务，且不使用损坏的传递选项。
Interface Format - The L2TP/AAL5 layer boundary presents an octet service interface to the AAL5 layer. There is no provision for sub-octets to be supplied or accepted.
接口格式-L2TP/AAL5层边界表示到AAL5层的八位组服务接口。没有提供或接受子八位字节的规定。
Each L2TP PDU MUST be transported within a single AAL5 PDU. Therefore the maximum transfer unit (MTU) of the AAL5 connection constrains the MTU of the L2TP tunnel that uses the connection and the MTU of all PPP connections that use the tunnel. ([RFC1661] refers to this as Maximum Receive Unit, or MRU. In [SIG31], it is the Forward and Backward Maximum CPCS-SDU Size.)
每个L2TP PDU必须在单个AAL5 PDU内运输。因此，AAL5连接的最大传输单元（MTU）约束使用该连接的L2TP隧道的MTU和使用该隧道的所有PPP连接的MTU。（[RFC1661]将其称为最大接收单元或MRU。在[SIG31]中，它是前向和后向最大CPCS-SDU大小。）
An implementation MUST support a PPP MRU of at least 1500 bytes.
实现必须支持至少1500字节的PPP MRU。
An implementation SHOULD use a larger MTU than the minimum value specified above. It is RECOMMENDED that an implementation support an IP packet of at least 9180 bytes in the PPP PDU.
实现应使用大于上述最小值的MTU。建议实现支持PPP PDU中至少9180字节的IP数据包。
In order to provide a desired Quality of Service (QoS), and possibly different qualities of service to different client connections, an implementation MAY use more than one AAL5 connection between LAC and LNS.
为了向不同的客户端连接提供期望的服务质量（QoS）和可能不同的服务质量，实现可以在LAC和LNS之间使用多个AAL5连接。
QoS mechanisms, such as Differentiated UBR [DUBR], that could involve inverse multiplexing a tunnel across multiple VCs are for further study. QoS mechanisms applicable to a single tunnel corresponding to a single VC, are independent of the ATM transport and out of scope of this document.
QoS机制，如差异化UBR[DUBR]，可能涉及跨多个VCs的反向多路复用隧道，有待进一步研究。适用于对应于单个VC的单个隧道的QoS机制独立于ATM传输，不在本文档的范围内。
The L2TP layer does not impose any restrictions regarding transmission rate or the underlying ATM layer traffic descriptor parameters.
L2TP层不会对传输速率或底层ATM层流量描述符参数施加任何限制。
Specific traffic parameters MAY be set for a PVC connection by agreement between the communicating parties. The caller MAY request specific traffic parameters at the time an SVC connection is set up.
通过通信双方之间的协议，可以为PVC连接设置特定的流量参数。呼叫方可以在建立SVC连接时请求特定的流量参数。
Autoconfiguration of end-systems for PVCs can be facilitated by the use of the optional ILMI 4.0 extensions documented in [ILMIA]. This provides comparable information to the IEs used for control plane connection establishment.
通过使用[ILMIA]中记录的可选ILMI 4.0扩展，可以促进PVC终端系统的自动配置。这提供了与用于建立控制平面连接的IEs类似的信息。
This specification uses the principles, terminology, and frame structure described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC2684]. The purpose of this specification is not to reiterate what is already standardized in [RFC2684], but to specify how the mechanisms described in [RFC2684] are to be used to map L2TP onto an AAL5-based ATM network.
本规范使用“ATM适配层5上的多协议封装”[RFC2684]中描述的原理、术语和帧结构。本规范的目的不是重申[RFC2684]中已经标准化的内容，而是指定如何使用[RFC2684]中描述的机制将L2TP映射到基于AAL5的ATM网络。
As specified in [RFC2684], L2TP PDUs shall be carried in the payload field of Common Part Convergence Sublayer (CPCS) PDUs of AAL5, and the Service Specific Convergence Sublayer (SSCS) of AAL5 shall be empty.
按照[RFC2684]中的规定，L2TP PDU应在AAL5的公共部分会聚子层（CPCS）PDU的有效载荷字段中承载，且AAL5的特定服务会聚子层（SSC）应为空。
Section 1 of [RFC2684] defines two mechanisms for identifying the protocol encapsulated in the AAL5 PDU's payload field:
[RFC2684]第1节定义了两种机制，用于识别封装在AAL5 PDU有效载荷字段中的协议：
1. Virtual circuit (VC) based multiplexing. 2. Logical Link Control (LLC) encapsulation.
1. 基于虚拟电路（VC）的多路复用。2.逻辑链路控制（LLC）封装。
In the first mechanism, the payload's protocol type is implicitly agreed to by the end points for each virtual circuit using provisioning or control plane procedures. This mechanism will be referred to as "VC-multiplexed L2TP".
在第一种机制中，有效负载的协议类型由使用供应或控制平面过程的每个虚拟电路的端点隐式同意。该机制将被称为“VC多路复用L2TP”。
In the second mechanism, the payload's protocol type is explicitly identified in each AAL5 PDU by an IEEE 802.2 LLC header. This mechanism will be referred to as "LLC encapsulated L2TP".
在第二种机制中，通过IEEE 802.2 LLC报头在每个AAL5 PDU中明确标识有效负载的协议类型。该机制称为“LLC封装L2TP”。
An L2TP implementation:
L2TP实现：
1. MUST support LLC encapsulated L2TP on PVCs. 2. MAY support LLC encapsulated L2TP on SVCs. 3. MAY support VC-multiplexed L2TP on PVCs or SVCs.
1. 必须在PVC上支持LLC封装的L2TP。2.可在SVC上支持LLC封装的L2TP。3.可在PVC或SVC上支持VC多路复用L2TP。
When a PVC is used, the endpoints must be configured to use one of the two encapsulation methods.
使用PVC时，必须将端点配置为使用两种封装方法之一。
If an implementation supports SVCs, it MUST use the [Q.2931] Annex C procedure to negotiate connection setup, encoding the Broadband Lower Layer Interface (B-LLI) information element (IE) to signal either VC-multiplexed L2TP or LLC encapsulated L2TP. The details of this control plane procedure are described in section 7.
如果实现支持SVC，则必须使用[Q.2931]附录C程序协商连接设置，对宽带低层接口（B-LLI）信息元素（IE）进行编码，以向VC多路复用L2TP或LLC封装L2TP发送信号。第7节描述了该控制平面程序的细节。
If an implementation is connecting through a Frame Relay/ATM FRF.8 [FRF8] service inter-working unit, then it MUST use LLC encapsulated L2TP.
如果一个实现通过帧中继/ATM FRF.8[FRF8]服务交互工作单元进行连接，那么它必须使用LLC封装的L2TP。
When LLC encapsulation is used, the payload field of the AAL5 CPCS PDU SHALL be encoded as shown in Figure 1. The pertinent fields in that diagram are:
当使用LLC封装时，AAL5 CPCS PDU的有效载荷字段应按照图1所示进行编码。该图中的相关字段为：
1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA followed by a frame type of Un-numbered Information (value 0x03). This LLC header indicates that an IEEE 802.1a SNAP header follows [RFC2684].
1. IEEE 802.2 LLC标头：源和目标SAP为0xAA，后跟未编号信息的帧类型（值0x03）。此LLC报头表示[RFC2684]后面有IEEE 802.1a快照报头。
2. IEEE 802.1a SNAP Header: The three octet Organizationally Unique Identifier (OUI) value of 0x00-00-5E identifies IANA (Internet Assigned Numbers Authority.) The two octets Protocol Identifier (PID) identifies L2TP as the encapsulated protocol. The PID value is 0x0007.
2. IEEE 802.1a SNAP标头：0x00-00-5E的三个八位字节组织唯一标识符（OUI）值标识IANA（互联网分配号码授权）。两个八位字节协议标识符（PID）标识L2TP为封装协议。PID值为0x0007。
3. The L2TP PDU:
3. L2TP PDU：
Figure 1 - LLC Encapsulated L2TP PDU
图1-LLC封装L2TP PDU
+-------------------------+ --------
| Destination SAP (0xAA) | ^
+-------------------------+ |
| Source SAP (0xAA) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| OUI (0x00-00-5E)| |
+-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header
| PID (0x00-07) | |
+-------------------------+ --------
| | |
| | L2TP PDU
| | |
+-------------------------+ --------
+-------------------------+ --------
| Destination SAP (0xAA) | ^
+-------------------------+ |
| Source SAP (0xAA) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| OUI (0x00-00-5E)| |
+-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header
| PID (0x00-07) | |
+-------------------------+ --------
| | |
| | L2TP PDU
| | |
+-------------------------+ --------
Note: The format of the overall AAL5 CPCS PDU is shown in the next section.
注：整个AAL5 CPCS PDU的格式见下一节。
The end points MAY be bi-laterally provisioned to send other LLC-encapsulated protocols besides L2TP across the same virtual connection.
端点可以是双边配置的，以便在同一虚拟连接上发送L2TP之外的其他LLC封装协议。
VC-multiplexed L2TP over AAL5 is an alternative technique to LLC encapsulated L2TP over AAL5. In this case, the L2TP PDU is the AAL5 payload without an LLC header. This is sometimes called "Null encapsulation."
VC在AAL5上多路复用L2TP是LLC在AAL5上封装L2TP的替代技术。在这种情况下，L2TP PDU是没有LLC报头的AAL5有效负载。这有时称为“空封装”
Figure 2 - AAL5 CPCS-PDU Format
图2-AAL5 CPCS-PDU格式
+-------------------------------+ -------
| . | ^
| . | |
| CPCS-PDU payload | L2TP PDU
| up to 2^16 - 1 octets) | |
| . | V
+-------------------------------+ -------
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) | ^
+-------------------------------+ |
| CPI (1 octet ) | |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) | |
+-------------------------------| |
| CRC (4 octets) | V
+-------------------------------+ -------
+-------------------------------+ -------
| . | ^
| . | |
| CPCS-PDU payload | L2TP PDU
| up to 2^16 - 1 octets) | |
| . | V
+-------------------------------+ -------
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) | ^
+-------------------------------+ |
| CPI (1 octet ) | |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) | |
+-------------------------------| |
| CRC (4 octets) | V
+-------------------------------+ -------
The Common Part Convergence Sub-layer (CPCS) PDU payload field contains user information up to 2^16 - 1 octets.
公共部分聚合子层（CPCS）PDU有效负载字段包含最多2^16-1个八位字节的用户信息。
The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such that the last 48 octet cell payload created by the SAR sublayer will have the CPCS-PDU Trailer right justified in the cell.
PAD字段将CPCS-PDU填充到ATM信元中，以便SAR子层创建的最后48个八位字节信元有效载荷将使CPCS-PDU拖车在信元中正确对齐。
The CPCS-UU (User-to-User indication) field is used to transparently transfer CPCS user to user information. The field has no function under the multi-protocol ATM encapsulation and MAY be set to any value.
CPCS-UU（用户到用户指示）字段用于透明地传输CPCS用户到用户的信息。该字段在多协议ATM封装下没有功能，可以设置为任何值。
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. Possible additional functions are for further study in ITU-T. When only the 64 bit alignment function is used, this field SHALL be coded as 0x00.
CPI（公共零件指示器）字段将CPCS-PDU尾部对齐到64位。可能的附加功能供ITU-T进一步研究。当仅使用64位校准功能时，该字段应编码为0x00。
The Length field indicates the length, in octets, of the payload field. The maximum value for the Length field is 65535 octets. A Length field coded as 0x00 MAY be used for the abort function.
长度字段表示有效负载字段的长度（以八位字节为单位）。长度字段的最大值为65535个八位字节。编码为0x00的长度字段可用于中止功能。
The CRC field is computed over the entire CPCS-PDU except the CRC field itself.
CRC字段在整个CPCS-PDU上计算，CRC字段本身除外。
The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in [RFC2661].
CPCS-PDU有效载荷应包括[RFC2661]中定义的L2TP PDU。
An SVC connection can originate at either the LAC or the LNS. An implementation that supports the use of SVCs MUST be able to both originate and respond to SVC setup requests. Except for the B-LLI IE specified below, all other IEs required for ATM User-Network Interface (UNI) Signaling Specification Version 4.0 [SIG40] should be encoded as per [RFC2331].
SVC连接可以起源于LAC或LN。支持使用SVC的实现必须能够发起和响应SVC设置请求。除下文规定的B-LLI IE外，ATM用户网络接口（UNI）信令规范版本4.0[SIG40]所需的所有其他IE应按照[RFC2331]进行编码。
When originating an SVC AAL5 connection, the caller MUST request in the SETUP message either VC-multiplexed L2TP, LLC encapsulated L2TP, or both VC-multiplexed and LLC-encapsulated L2TP. The B-LLI IE SHALL be used to specify the requested encapsulation method. When a caller is offering both encapsulations, the two B-LLI IEs SHALL be encoded within a Broadband Repeat Indicator information element in the order of the sender's preference.
发起SVC AAL5连接时，调用方必须在设置消息中请求VC多路复用L2TP、LLC封装L2TP或VC多路复用和LLC封装L2TP。应使用B-LLI IE规定所需的封装方法。当呼叫者提供两种封装时，两个B-LLI IEs应按照发送者的偏好顺序编码在宽带重复指示符信息元素中。
An implementation MUST be able to accept an incoming call that offers LLC encapsulated L2TP in the caller's request. The called peer's implementation MUST reject a call setup request that only offers an encapsulation that it does not support. Implementations originating a call offering both protocol encapsulation techniques MUST be able to accept the use of either encapsulation techniques.
实现必须能够接受呼叫者请求中提供LLC封装L2TP的传入呼叫。被调用对等方的实现必须拒绝只提供其不支持的封装的调用设置请求。发起同时提供两种协议封装技术的调用的实现必须能够接受这两种封装技术的使用。
When originating an LLC encapsulated call that is to carry an L2TP payload, the [Q.2931] B-LLI IE user information layer 2 protocol field SHALL be encoded to select LAN Logical Link Control (ISO/IEC8802-2) in octet 6. See [RFC2331] Appendix A for an example.
当发起承载L2TP有效载荷的LLC封装呼叫时，[Q.2931]B-LLI IE用户信息第2层协议字段应进行编码，以选择八位组6中的LAN逻辑链路控制（ISO/IEC8802-2）。有关示例，请参见[RFC2331]附录A。
When originating a VC-multiplexed call that is to carry an L2TP payload, the [Q.2931] B-LLI IE user information layer 2 protocol field SHALL be encoded to select no layer 2 protocol in octet 6 and layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577 [ISO9577] in octet 7. Furthermore, as per DSL Forum TR-037 [DSLF037], the extension octets specify VC-multiplexed L2TP by using the SNAP IPI, followed by an OUI owned by IANA, followed by the PID assigned by IANA for L2TP. Thus, the User Information layer 3 protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's
当发起承载L2TP有效载荷的VC多路复用呼叫时，[Q.2931]B-LLI IE用户信息第2层协议字段应进行编码，以在八位组6中选择第2层协议，而第3层协议字段应进行编码，以在八位组7中选择ISO/IEC TR 9577[ISO9577]。此外，根据DSL论坛TR-037[DSLF037]，扩展八位字节通过使用SNAP IPI指定VC多路复用L2TP，后跟IANA拥有的OUI，后跟IANA为L2TP分配的PID。因此，对用户信息层3协议字段进行编码：0B 80 00 00 5E 00 07。AAL5机架的
payload field will always contain an L2TP PDU. The SNAP IPI is employed only to use the IANA L2TP protocol value to specify the VC-multiplexed PDU.
有效负载字段将始终包含L2TP PDU。SNAP IPI仅用于使用IANA L2TP协议值来指定VC多路复用PDU。
If the caller offers both encapsulation methods and the called peer accepts the call, the called peer SHALL specify the encapsulation method by including exactly one B-LLI IE in the Connect message.
如果调用方同时提供两种封装方法，并且被调用的对等方接受该调用，则被调用的对等方应通过在连接消息中仅包含一个B-LLI IE来指定封装方法。
If an SVC tunnel is reset in accordance with section 4.1 of [RFC2661], both ends MUST clear the SVC. Any user sessions on the tunnel will be terminated by the reset. Either end MAY attempt to re-establish the tunnel upon receipt of a new request from a client.
如果根据[RFC2661]第4.1节重置SVC通道，两端必须清除SVC。隧道上的任何用户会话都将被重置终止。在收到来自客户端的新请求后，任何一端都可以尝试重新建立隧道。
When a connection setup fails, the L2TP entity that attempted the connection setup MAY consider the called entity unreachable until notified that the unreachable entity is available. The conditions under which an entity determines that another is unreachable and how it determines that the other is available again are implementation decisions.
当连接设置失败时，尝试连接建立的L2TP实体可以考虑调用的实体不可访问，直到通知不可达实体可用。实体确定另一个实体不可访问以及如何确定另一个实体再次可用的条件是实现决策。
When there are no active sessions on an SVC tunnel, either end MAY optionally clear the connection.
当SVC隧道上没有活动会话时，任何一端都可以选择清除连接。
Upon notification that an AAL5 SVC connection has been cleared, an Implementation SHALL tear down the tunnel and return the control connection to the idle state.
在通知AAL5 SVC连接已清除后，实施应拆除隧道并将控制连接返回空闲状态。
The Layer Two Tunneling Protocol base specification [RFC2661] discusses basic security issues regarding L2TP tunneling. It is possible that the L2TP over AAL5 tunnel security may be compromised by the attack of ATM transport network itself. The ATM Forum has published a security framework [AFSEC1] and a security specification [AFSEC2] that define procedures to guard against common threats to an ATM transport network. Applications that require protection against threats to an ATM switching network are encouraged to use authentication headers, or encrypted payloads, and/or the ATM-layer security services described in [AFSEC2].
第二层隧道协议基本规范[RFC2661]讨论了L2TP隧道的基本安全问题。AAL5隧道上的L2TP安全可能会受到ATM传输网络本身的攻击。ATM论坛发布了一个安全框架[AFSEC1]和一个安全规范[AFSEC2]，定义了防范ATM传输网络常见威胁的程序。鼓励需要防止ATM交换网络受到威胁的应用程序使用身份验证标头、加密有效负载和/或[AFSEC2]中描述的ATM层安全服务。
This document draws heavily on material from: "PPP Over AAL5" (RFC 2364) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and John Stephens and an earlier document of L2TP over AAL5 by Nagraj Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin.
本文件大量引用了乔治·格罗斯、马努·凯西、阿瑟·林、安德鲁·马利斯和约翰·斯蒂芬斯的《AAL5上的购买力平价》（RFC 2364）以及纳格拉·阿伦库马尔、马努·凯西、蒂姆·郭和阿瑟·林的早期文件《AAL5上的L2TP》。
Special thanks to Mike Davison, Arthur Lin, John Stevens for making significant contributions to the initial version of this document.
特别感谢Mike Davison、Arthur Lin、John Stevens为本文件的初始版本做出了重大贡献。
Special thanks to David Allan of Nortel for his invaluable review of this document.
特别感谢北电公司的David Allan对本文件的宝贵审阅。
The security section of this document is based upon RFC 3337, "Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", by Bruce Thompson, Bruce Buffam and Thima Koren.
本文档的安全部分基于RFC 3337，“异步传输模式适应层2（AAL2）上PPP的类扩展”，由Bruce Thompson、Bruce Buffam和Thima Koren编写。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，辛格·帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议（L2TP）”，RFC 26611999年8月。
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[SIG31] The ATM Forum, "ATM User-Network Interface Specification V3.1", af-uni-0010.002, 1994.
[SIG31]ATM论坛，“ATM用户网络接口规范V3.1”，af-uni-0010.002，1994年。
[ITU93] International Telecommunication Union, "B-ISDN ATM Adaptation Layer (AAL) Specification", ITU-T Recommendation I.363, March 1993.
[ITU93]国际电信联盟，“B-ISDN ATM适配层（AAL）规范”，ITU-T建议I.363，1993年3月。
[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月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
[Q.2931] International Telecommunication Union, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control", ITU-T Recommendation Q.2931, Feb. 1995.
[Q.2931]国际电信联盟，“宽带综合业务数字网（B-ISDN）数字用户信令系统第2号（DSS2）用户网络接口层3基本呼叫/连接控制规范”，ITU-T建议Q.2931，1995年2月。
[FRF8] The Frame Relay Forum, "Frame Relay/ATM PVC Service Interworking Implementation Agreement", FRF.8, April 1995.
[FRF8]帧中继论坛，“帧中继/ATM PVC业务互通实施协议”，FRF.81995年4月。
[ISO9577] ISO/IEC DTR 9577.2, "Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer", 1995-08- 16.
[ISO9577]ISO/IEC DTR 9577.2，“信息技术-系统间电信和信息交换-网络层协议识别”，1995-08-16。
[RFC2331] Maher, M., "ATM Signaling Support for IP over ATM - UNI Signaling 4.0 Update", RFC 2331, April 1998.
[RFC2331]Maher，M.“ATM上IP的ATM信令支持-UNI信令4.0更新”，RFC 2331，1998年4月。
[DSLF037] DSL Forum Technical Report TR-037, "Auto-Configuration for the Connection Between the DSL Broadband Network Termination (B-NT) and the Network using ATM", March 2001.
[DSLF037]DSL论坛技术报告TR-037，“DSL宽带网络终端（B-NT）与使用ATM的网络之间连接的自动配置”，2001年3月。
[SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signaling Specification Version 4.0", af-sig-0061.000, finalized July 1996; available at ftp://ftp.atmforum.com/pub.
[SIG40]ATM论坛，“ATM用户网络接口（UNI）信令规范版本4.0”，af-sig-0061.000，1996年7月定稿；可在ftp://ftp.atmforum.com/pub.
[DUBR] ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af-
tm-0149.000, finalized July, 2000; available at
ftp://ftp.atmforum.com/pub
[DUBR] ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af-
tm-0149.000, finalized July, 2000; available at
ftp://ftp.atmforum.com/pub
[ILMIA] ATM Forum, "Addendum to the ILMI Auto-configuration extension", af-nm-00165.000, April 2001.
[ILMIA]ATM论坛，“ILMI自动配置扩展附录”，af-nm-00165.000，2001年4月。
[AFSEC1] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-0096.000, February 1998
[AFSEC1]ATM论坛，“ATM安全框架1.0版”，af-sec-0096.000，1998年2月
[AFSEC2] The ATM Forum, "ATM Security Specification v1.1", af-sec-0100.002, March 2001
[AFSEC2]ATM论坛，“ATM安全规范v1.1”，af-sec-0100.002，2001年3月
AAL5 ATM Adaptation Layer Type 5
AAL5 ATM适配层类型5
ATM Asynchronous Transfer Mode
异步传输模式
B-LLI Broadband Low Layer Information
B-LLI宽带低层信息
CPCS Common Part Convergence Sublayer
公共部分收敛子层
IANA Internet Assigned Numbers Authority
IANA互联网分配号码管理局
IE Information Element
信息元素
L2TP Layer Two Tunneling Protocol
L2TP第二层隧道协议
LAC L2TP Access Concentrator
LAC L2TP接入集中器
LLC Logical Link Control
逻辑链路控制
LNS L2TP Network Server
LNS L2TP网络服务器
MTU Maximum Transfer Unit
最大传输单元
MRU Maximum Receive Unit
最大接收单元
NSP Network Service Provider
网络服务提供商
OUI Organizationally Unique Identifier
OUI组织唯一标识符
PDU Protocol Data Unit
协议数据单元
PID Protocol Identifier
PID协议标识符
PPP Point-to-Point Protocol
点对点协议
PVC Permanent Virtual Circuit
永久虚拟电路
SAP Service Access Point
服务访问点
SNAP Subnetwork Address Protocol
SNAP子网地址协议
SVC Switched Virtual Circuit
SVC交换虚拟电路
VC Virtual Circuit
虚拟电路
Authors' Addresses
作者地址
Rollins Turner Paradyne Corporation 8545 126th Avenue North Largo, FL 33773
佛罗里达州北拉戈第126大道8545号罗林斯特纳帕拉丹公司，邮编33773
EMail: rturner@eng.paradyne.com
EMail: rturner@eng.paradyne.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
Ajoy Singh Motorola 1421 West Shure Dr, Arlington Heights, IL 60004
Ajoy Singh摩托罗拉1421西舒尔博士，伊利诺伊州阿灵顿高地，邮编60004
EMail: asingh1@motorola.com
EMail: asingh1@motorola.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way Sunnyvale, CA 95134
Suhail Nanji Redback Networks，Inc.加利福尼亚州桑尼维尔霍尔格路300号，邮编95134
EMail: suhail@redback.com
EMail: suhail@redback.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。