[要約] RFC 3355は、L2TPをATM Adaptation Layer 5（AAL5）上で使用するためのプロトコルを定義しています。目的は、L2TPをATMネットワークで使用するための標準化と相互運用性の確保です。
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）上の2つのトンネルプロトコル（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.
Copyright（c）The Internet Society（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）のリンクレイヤーを輸送するための標準的な方法を提供します。 - ポイントへの接続。このドキュメントでは、基礎となるネットワーク接続のために非同期転送モード（ATM）ネットワークの使用について説明します。ATMユーザーネットワークインターフェイス（UNI）シグナリング仕様バージョン4.0またはATM適応レイヤー5（AAL5）を備えたバージョン3.1は、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 Access Concencoratorと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を備えたパーソナルコンピューターとの間のリンクで頻繁に使用されます。レイヤー2トンネリングプロトコル（L2TP）[RFC2661]により、ダイヤルアップサーバーは、ITと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].
要件キーワード「必須」、「必須」、「必須」、「「shall」、「shall」、「suld」、 "nove"、 "becommended"、 "may"、 "optional"は、文書は、[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を制約します。（[RFC1661]は、これを最大受信ユニット、または[sig31]のmruと呼びます。これは、順方向および後方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 [DUBR]などのQoSメカニズムは、さらなる研究のためです。単一の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拡張機能を使用することにより促進できます。これにより、コントロールプレーン接続の確立に使用される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]で説明されているメカニズムを使用して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）PDUSのペイロードフィールドに運ばれ、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のペイロードフィールドにカプセル化されたプロトコルを識別するための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".
2番目のメカニズムでは、ペイロードのプロトコルタイプは、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. 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を使用する場合、エンドポイントを2つのカプセル化方法のいずれかを使用するように構成する必要があります。
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）情報要素（つまり）をエンコードして、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ヘッダー：0xAAのソースおよび宛先SAPに続いて、フレームタイプの非番号情報（値0x03）が続きます。このLLCヘッダーは、IEEE 802.1Aスナップヘッダーが続くことを示しています[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スナップヘッダー：0x00-00-5Eの3つのOctet組織的に一意の識別子（OUI）値はIANA（インターネット割り当てされた番号当局）を識別します。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
| | |
+-------------------------+ --------
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を介したLLCカプセル化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
+-------------------------------+ -------
The Common Part Convergence Sub-layer (CPCS) PDU payload field contains user information up to 2^16 - 1 octets.
Common Part Combrgenceサブレイヤー（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.
パッドフィールドは、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フィールドは、CRCフィールド自体を除き、CPCS-PDU全体で計算されます。
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またはLNSのいずれかで発生します。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マルチプレックス化されたL2TPおよび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.
実装は、発信者のリクエストで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ユーザー情報レイヤー2プロトコルフィールドは、Octet 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ユーザー情報レイヤー2プロトコルフィールドは、Octet 6およびレイヤー3プロトコルフィールドでレイヤー2プロトコルを選択するようにエンコードするものとします。オクテット7でISO/IEC TR 9577 [ISO9577]を選択するようにエンコードされました。さらに、DSLフォーラムTR-037 [DSLF037]によると、拡張オクテットは、IANAが所有するOUIが続くSNAP IPIを使用してVCマルチプレックスL2TPを指定します。L2TPにIANAによって割り当てられたPIDが続きます。したがって、ユーザー情報レイヤー3プロトコルフィールドはエンコードされています：0B 80 00 00 5E 00 07. AAL5フレームのペイロードフィールドには、常に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.
発信者が両方のカプセル化方法を提供し、呼び出されたピアがコールを受け入れる場合、呼び出されたピアは、接続メッセージに正確に1つの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エンティティは、到達不可能なエンティティが利用可能であることを通知するまで、呼び出しのエンティティが到達不可能であると考える場合があります。エンティティが他の人が到達不可能であると判断する条件は、もう1つが再び利用可能であると判断する方法が実装決定であると判断します。
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トンネルに関する基本的なセキュリティ問題について説明しています。AAL5トンネルのセキュリティを介したL2TPが、ATM輸送ネットワーク自体の攻撃によって損なわれる可能性があります。ATMフォーラムは、ATM輸送ネットワークに対する一般的な脅威を防ぐ手順を定義するセキュリティフレームワーク[AFSEC1]とセキュリティ仕様[AFSEC2]を公開しています。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.
この文書は、ジョージ・グロス、マヌ・ケイシー、アーサー・リン、アンドリュー・マリス、ジョン・スティーブンスの「PPP over AAL5」（RFC 2364）の「PPP over AAL5」（RFC 2364）と、Nagraj Arunkumar、Manu Kaycee、Tim Kwokの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.
このドキュメントのセキュリティセクションは、Bruce Thompson、Bruce Buffam、Thima KorenによるRFC 3337、「非同期転送モード適応レイヤー2（AAL2）を超えるPPPのクラス拡張機能」に基づいています。
[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.、Valencia、A.、Rubens、A.、Singh Pall、G.、Zorn、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] International Telecommunication Union、「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] International Telecommunication Union、「Broadband Integrated Service Digital Network（B-ISDN）Digital Subscriber Signaling System No.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] 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フォーラム、「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フォーラム、「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
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
Rollins Turner Paradyne Corporation 8545 126th Avenue North Largo、FL 33773
EMail: rturner@eng.paradyne.com
Rene Tio Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Rene Tio Redback Networks、Inc。300 Holger Way San Jose、CA 95134
EMail: tor@redback.com
Ajoy Singh Motorola 1421 West Shure Dr, Arlington Heights, IL 60004
Ajoy Singh Motorola 1421 West Shure Dr、アーリントンハイツ、イリノイ州60004
EMail: asingh1@motorola.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way Sunnyvale, CA 95134
Suhail Nanji Redback Networks、Inc。300 Holger Way Sunnyvale、CA 95134
EMail: suhail@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。