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)
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.
レイヤ2トンネリングプロトコル（L2TP）は、物理的なポイントの代わりにネットワーク接続を使用して、ダイヤルアップサーバーおよびネットワーク・アクセス・サーバ間のポイントツーポイントプロトコル（PPP）のリンク層を輸送するための標準的な方法を提供し、 -to-Point接続。この文書では、基盤となるネットワーク接続のための非同期転送モード（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.
この仕様は、L2TPアクセスコンセントレータとL2TPネットワークサーバ間の通信リンクを提供するために、ATMを使用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とパーソナルコンピュータとの間のリンク上で使用されています。レイヤ2トンネリングプロトコル（L2TP）[RFC2661]それとNSPの両方が直接接続されたネットワーク内のトンネルを介してPPP接続を拡張することにより、リモートNSPへのアクセスを提供するために、ダイヤルアップサーバーを可能にします。 「トンネル」は、おそらく異なるネットワークの一部として、それらのノード間のデータリンク層接続の役割で使用される2つのノード間のネットワーク層接続、です。 [RFC2661]にダイヤルアップサーバーは、L2TPアクセス・コンセントレータ、またはLACと呼ばれます。ネットワークへのアクセスを提供するリモートデバイスは、L2TPネットワークサーバ、またはLNSと呼ばれています。 L2TPはLACとLNS間のトンネルを作成するために、パケット配信サービスを利用します。 「L2TPは、主にトンネルが確立される介してメディアの詳細から絶縁されるように設計され、L2TPトンネルメディアがパケット指向のポイントツーポイント接続を提供することのみを必要とする」[RFC2661]を。 AAL5でのATMネットワークはパケット指向の接続の適切な形態を提供しています。 LACとLNS間のポイントツーポイント接続のためのAAL5の使用に固有の詳細を提供することによって、この標準サプリメント[RFC2661]。
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].
要件は、この中で、キーワード "MUST" をキーワード、 "REQUIRED"、 "NOT SHALL"、 "べきではない" "べきである" "ないものと"、 "推奨" "てはならない"、 "MAY"、および "オプション"文書は、[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）を接続し、トンネルを使用するすべてのPPP接続のMTUを使用するL2TPトンネルのMTUを制約します。 （最大単位、またはMRUを受信するように[RFC1661]は、このことをいう。[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.
複数のVCを横切って逆多重化にトンネルを含むことができ、そのような差別化UBR等のQoSメカニズム、[DUBR]は、今後の検討課題です。単一の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.
PVCのためのエンドシステムの自動設定は、[ILMIA]に記載任意ILMI 4.0拡張機能を使用することによって容易にすることができます。これは、制御プレーン接続の確立に使用されるのIEに相当する情報を提供します。
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.
この仕様は、[RFC2684]「ATMアダプテーション・レイヤ5の上にマルチプロトコルカプセル化」に記載された原理、用語、及びフレーム構造を使用します。本明細書の目的は、すでに[RFC2684]で標準化されたものを繰り返すことではなく、[RFC2684]に記載メカニズムはAAL5ベースのATMネットワークにL2TPをマッピングするために使用される方法を指定しないことです。
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の（SSCS）が空でなければならないしなければなりません。
Section 1 of [RFC2684] defines two mechanisms for identifying the protocol encapsulated in the AAL5 PDU's payload field:
[RFC2684]のセクション1は、AAL5 PDUのペイロードフィールドにカプセル化されたプロトコルを識別するための2つのメカニズムを定義しています。
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. LLCはPVCでL2TPをカプセル化サポートしなければなりません。 2. LLCは、SVCの上で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をサポートしている場合、それはVC多重L2TPのいずれかを知らせるために広帯域下位レイヤインタフェース（B-LLI）情報要素（IE）をコードする、接続設定を交渉する[Q.2931]附属書Cの手順を使用しなければならないか、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ヘッダ国連番号情報のフレームタイプ（値0×03）、続いて0xAAをの送信元および宛先SAP。このLLCヘッダは、IEEE 802.1a SNAPヘッダは[RFC2684]を次のことを示しています。
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（Internet Assigned Numbers Authority。）を識別する2つのオクテットプロトコル識別子（PID）をカプセル化プロトコルとしてL2TPを識別する。 PID値は0x0007です。
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
| | |
+-------------------------+ --------
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."
AAL5オーバーVC-多重L2TP AAL5上でL2TPをカプセル化LLCへの代替技術です。この場合、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
+-------------------------------+ -------
The Common Part Convergence Sub-layer (CPCS) PDU payload field contains user information up to 2^16 - 1 octets.
1オクテット - 共通部コンバージェンスサブレイヤ（CPCS）PDUペイロードフィールドは、2 ^ 16までのユーザ情報を含みます。
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.
パッドフィールドパッドCPCS-PDUは、SARサブレイヤによって作成された最後の48オクテットのセルのペイロードは、細胞におけるCPCS-PDUトレーラーが右寄せになりますようにATMセルに正確に収まるようにします。
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（共通部インジケータ）フィールドは64ビットにCPCS-PDUトレーラを整列させます。可能性のある追加機能は、ITU-Tでのさらなる研究のためのものです。のみ64ビットアライメント機能を使用する場合、このフィールドは0×00のようにコーディングされます。
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.
Lengthフィールドは、ペイロードフィールドのオクテットの長さを、示しています。 Lengthフィールドの最大値は65535オクテットです。 0x00のように符号化された長さフィールドは、アボート機能のために使用されるかもしれません。
The CRC field is computed over the entire CPCS-PDU except the CRC field itself.
CRCフィールドは、CRCフィールド自体を除いて全体のCPCS-PDUにわたって計算されます。
The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in [RFC2661].
[RFC2661]で定義されるようにCPCS-PDUペイロードは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かLNSのどちらかで発生することができます。 SVCの使用をサポートする実装は、発信およびSVCの設定要求に応答して、両方できなければなりません。 B-LLIを除いIEは、以下の指定、ATMのユーザネットワークインタフェース（UNI）のために必要な他のすべてのIEシグナリング仕様バージョン4.0は、[SIG40] [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接続を発信するとき、発信者がSETUPメッセージのいずれかVC多重L2TPに要求しなければなりません、LLCは、L2TPカプセル化、またはその両方VC多重およびLLCカプセル化L2TP。 B-LLI IEは、要求されたカプセル化方法を指定するために使用されなければなりません。発信者が両方のカプセル化を提供している場合、2つのB-LLI IEは、送信者の好みの順に広帯域繰り返し識別子情報要素内に符号化されます。
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.
実装は、呼び出し側の要求にL2TPをカプセル化LLCを提供しています着信コールを受け入れることができなければなりません。呼ばれるピアの実装では、それがサポートされていないカプセル化を提供しています呼設定要求を拒絶しなければなりません。両方のプロトコルのカプセル化技術を提供してコールを発信する実装は、いずれかのカプセル化技術の使用を受け入れることができなければなりません。
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.
LLCは、L2TPペイロードを搬送するコールをカプセル化発信するとき、[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 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ペイロードを運ぶことであるVC-多重コールを発信するとき、[Q.2931] B-LLI IEユーザ情報レイヤ2プロトコルフィールドがなければならないオクテット6及びレイヤ3プロトコルフィールドにはレイヤ2プロトコルを選択しないように符号化されます[DSLF037] DSLフォーラムTR-037あたりとして、さらにオクテット7にISO / IEC TR 9577 [ISO9577]を選択するようにエンコードされ、拡張オクテットは、IANAが所有するOUIが続く、SNAP IPIを使用してVC-多重L2TPを指定しますL2TPのためにIANAによって割り当てられたPIDが続きます。このように、ユーザ情報レイヤ3プロトコルフィールドが符号化される：0B 80 00 00 5E 00 07. AAL5フレームのペイロードフィールドは、常にL2TP PDUを含むであろう。 SNAP IPIはVC多重PDUを指定するためにIANA L2TPプロトコル値を使用することのみに使用されます。
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.
発信者は、両方のカプセル化方法を提供し、呼ばれるピアがコールを受け入れる場合、呼ばれるピアは、Connectメッセージに正確に一つの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.
SVCトンネルが[RFC2661]のセクション4.1に応じてリセットされた場合、両端が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].
レイヤ2トンネリングプロトコルベース仕様[RFC2661]はL2TPトンネルに関する基本的なセキュリティ問題について説明します。 L2TP AAL5上のトンネルのセキュリティは、ATMトランスポートネットワーク自体の攻撃によって損なわれる可能性があります。 ATMフォーラムは、ATMトランスポートネットワークに共通の脅威から保護するための手順を定義するセキュリティフレームワーク[AFSEC1]とセキュリティ仕様[AFSEC2]を発表しました。 ATM交換ネットワークへの脅威に対する保護を必要とするアプリケーションは、認証ヘッダーを使用することを奨励、またはペイロードを暗号化し、および/またはATMレイヤセキュリティサービスは、[AFSEC2]で説明されています。
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.
Nagraj Arunkumar、マヌーKaycee、ティム・クォックによってジョージ・グロス、マヌーKaycee、アーサー・林、アンドリューMalis、ジョン・スティーブンスによって「PPPオーバー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.
このドキュメントの初期バージョンへの重要な貢献をするためのマイク・デイヴィソン、アーサー林、ジョン・スティーブンスに感謝します。
Special thanks to David Allan of Nortel for his invaluable review of this document.
このドキュメントの彼の貴重なレビューのために、ノーテルのデヴィッド・アランに感謝します。
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.
このドキュメントのセキュリティセクションはブルース・トンプソン、ブルースBuffamとThimaコレンにより、RFC 3337、「PPP非同期オーバー転送モードアダプテーションレイヤ2（AAL2）のクラスの拡張」に基づいています。
[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] Townsley、W.、バレンシア、A.、ルーベンス、A.、シンポール、G.、ソーン、G、BのPalter、 "レイヤ2トンネリングプロトコル（L2TP）"、RFC 2661、1999年8月。
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、エディタ、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]グロスマン、D.とJ. Heinanen、RFC 2684、1999年9月 "ATMアダプテーションレイヤ5以上のマルチプロトコルカプセル化"。
[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.8、1995年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]マー、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、、2001年3月 "ATMを使用してDSLブロードバンドネットワーク終端（B-NT）とネットワーク間の接続のための自動設定機能"。
[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フォーラム、 "TM 4.1への補遺：差別化UBR"、AF-TM-0149.000、2000年7月完成。 ftp://ftp.atmforum.com/pubでご利用いただけます
[ILMIA] ATM Forum, "Addendum to the ILMI Auto-configuration extension", af-nm-00165.000, April 2001.
[ILMIA] ATMフォーラム、AF-NM-00165.000、2001年4月 "ILMI自動設定の拡張機能への補遺"。
[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月
Appendix A. Acronyms
付録A.略語
AAL5 ATM Adaptation Layer Type 5
AAL5 ATMアダプテーションレイヤタイプ5
ATM Asynchronous Transfer Mode
ATM非同期転送モード
B-LLI Broadband Low Layer Information
B-LLI広帯域低レイヤの情報
CPCS Common Part Convergence Sublayer
CPCS共通パートコンバージェンスサブレイヤ
IANA Internet Assigned Numbers Authority
IANAインターネット割り当て番号機関
IE Information Element
IE情報要素
L2TP Layer Two Tunneling Protocol
L2TPレイヤ2つのトンネリングプロトコル
LAC L2TP Access Concentrator
LAC L2TPアクセスコンセントレータ
LLC Logical Link Control
LLC論理リンク制御
LNS L2TP Network Server
LNS L2TPネットワークサーバ
MTU Maximum Transfer Unit
MTU最大転送ユニット
MRU Maximum Receive Unit
MRU最大はユニットを受信します
NSP Network Service Provider
NSPネットワークサービスプロバイダー
OUI Organizationally Unique Identifier
OUI組織固有識別子
PDU Protocol Data Unit
PDUプロトコルデータユニット
PID Protocol Identifier
PIDプロトコル識別子
PPP Point-to-Point Protocol
PPPポイントツーポイントプロトコル
PVC Permanent Virtual Circuit
PVCパーマネントバーチャルサーキット
SAP Service Access Point
SAPサービスアクセスポイント
SNAP Subnetwork Address Protocol
SNAPサブネットワークアドレスプロトコル
SVC Switched Virtual Circuit
SVCは、仮想回線を交換しました
VC Virtual Circuit
VC仮想回線
Authors' Addresses
著者のアドレス
Rollins Turner Paradyne Corporation 8545 126th Avenue North Largo, FL 33773
ロリンズターナーパラダイン社8545第126回アベニュー北ラルゴ、FL 33773
EMail: rturner@eng.paradyne.com
メールアドレス：rturner@eng.paradyne.com
Rene Tio Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
ルネ・ティオレッドバックネットワークス株式会社300ホルガー・ウェイサンノゼ、CA 95134
EMail: tor@redback.com
メールアドレス：tor@redback.com
Ajoy Singh Motorola 1421 West Shure Dr, Arlington Heights, IL 60004
Ajoyシンモトローラ1421西シュアー博士、アーリントンハイツ、IL 60004
EMail: asingh1@motorola.com
メールアドレス：asingh1@motorola.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way Sunnyvale, CA 95134
Suhail蘭芝レッドバックネットワークス株式会社300ホルガー・ウェイサニーベール、CA 95134
EMail: suhail@redback.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。