RFC3355 日本語訳
3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5(AAL5). A. Singh, R. Turner, R. Tio, S. Nanji. August 2002. (Format: TXT=25114 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Singh
Request for Comments: 3355 Motorola
Category: Standards Track R. Turner
Paradyne
R. Tio
S. Nanji
Redback Networks
August 2002
コメントを求めるワーキンググループA.シンの要求をネットワークでつないでください: 3355年のモトローラカテゴリ: 規格は2002年8月にR.ターナーParadyne R.Tio S.Nanji20ドル紙幣ネットワークを追跡します。
Layer Two Tunnelling Protocol (L2TP)
Over ATM Adaptation Layer 5 (AAL5)
気圧適合層5の上でプロトコル(L2TP)にトンネルを堀る層Two(AAL5)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
Layer Two Tunnelingプロトコル(L2TP)はPointからポイントへのプロトコル(PPP)のリンクレイヤを輸送するための標準方法をダイヤルアップサーバとNetwork Access Serverの間に供給します、物理的な二地点間接続の代わりにネットワーク接続を使用して。 このドキュメントはAsynchronous Transfer Mode(ATM)ネットワークの基本的なネットワーク接続の使用について説明します。 ATM Adaptation Layer5(AAL5)と共にSpecificationバージョン4.0かバージョン3.1に合図するATM User-ネットワークInterface(UNI)がインタフェースとして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 Access ConcentratorとL2TP Network Serverとのコミュニケーションリンクを提供することを意図します。
Singh, et. al. Standards Track [Page 1] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[1ページ]RFC3355L2TP
1. Introduction
1. 序論
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.
頻繁にPointからポイントへのプロトコル(PPP)[RFC1661]はそうです。ダイヤルモデムとネットワークサービスプロバイダーか、NSPがあるパーソナルコンピュータの間のリンクでは、使用されています。 Layer Two Tunnelingプロトコル(L2TP)[RFC2661]は、ダイヤルアップサーバがトンネルを通ってそれとNSPの両方が直接接続されるネットワークでPPP接続を広げることによってリモートNSPへのアクセスを提供するのを可能にします。 「トンネル」はことによると異なったネットワークの一部としてそれらのノードの間のデータ・リンク層接続の役割に使用される2つのノードの間のネットワーク層接続です。 [RFC2661]では、ダイヤルアップサーバはL2TP Access Concentrator、またはLACと呼ばれます。 ネットワークへのアクセスを提供する遠隔装置はL2TP Network Server、またはLNSと呼ばれます。 L2TPは、LACとLNSの間のトンネルを作成するのにパケットデリバリ・サービスを使用します。 「L2TPはトンネルが確立されるメディアの細部から主に隔離されるように設計されています」。 「L2TPは、トンネルメディアがパケット指向の二地点間接続性を提供するだけであるのを必要とである」[RFC2661]。 AAL5とのATMネットワークは適当な形式のパケット指向の接続を提供します。 この規格は、AAL5のLACとLNSとの二地点間接続の使用に特定の詳細を明らかにすることによって、[RFC2661]を補います。
2. Conventions
2. コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
A list of acronyms used in this document is given at the end of the document as Appendix A.
Appendix Aとしてドキュメントの端で本書では使用される頭文字語のリストを与えます。
3. AAL5 Layer Service Interface
3. AAL5層のサービスインタフェース
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 MUSTは全二重、ポイント・ツー・ポイント、およびそれが捧げられるかもしれないという(すなわち、永久的であることで、食糧を供給することによって、セットアップしてください)ことであるか切り替わりました。(要求に応じてセットアップしてください。)
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.
インタフェースFormat--L2TP/AAL5層の境界は八重奏サービスインタフェースをAAL5層に提示します。 サブ八重奏を供給するか、または受け入れるために、支給は全くありません。
Singh, et. al. Standards Track [Page 2] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[2ページ]RFC3355L2TP
3.1 Maximum Transfer Unit
3.1 最大の移動単位数
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 MUST、独身のAAL5 PDUの中で輸送されてください。 したがって、AAL5接続の最大の移動単位数(MTU)は接続を使用するL2TPトンネルのMTUとトンネルを使用するすべてのPPP接続のMTUを抑制します。 ([RFC1661]はMaximum Receive Unit、またはMRUにこれについて言及します。 [SIG31]では、それは、ForwardとBackward Maximum CPCS-SDU Sizeです。)
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.
SHOULDが最小値が指定したより大きいMTUを使用する実装。 実装がPPP PDUで少なくとも9180バイトのIPパケットをサポートするのは、RECOMMENDEDです。
3.2 Quality of Service
3.2 サービスの質
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.
Service(QoS)の必要なQuality、およびことによると異なった異なったクライアント接続に対するサービスの品質を提供するために、実装はLACとLNSとの1つ以上の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.
さらなる研究には複数のVCsの向こう側にトンネルを多重送信する逆を伴うことができたDifferentiated UBRなどのQoSメカニズム[DUBR]があります。 独身のVCに対応する単一のトンネルに適切なQoSメカニズムはATM輸送の如何にかかわらずこのドキュメントの範囲からのそうです。
3.3 ATM Connection Parameters
3.3 気圧接続パラメタ
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]に記録された任意のILMI4.0拡張子の使用でPVCsのエンドシステムの自動構成を容易にすることができます。 これはコントロール飛行機コネクション確立に使用されるIEsに匹敵する情報を供給します。
Singh, et. al. Standards Track [Page 3] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[3ページ]RFC3355L2TP
4. Multi-Protocol Encapsulation
4. マルチプロトコルカプセル化
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.
この仕様は「気圧適合層の5インチ[RFC2684]の上のMultiprotocolカプセル化」で説明された原則、用語、および枠組構造を使用します。 この仕様の目的は[RFC2684]で既に標準化されることを繰り返すのではなく、AAL5を拠点とするATMネットワークにL2TPを写像するのに使用される[RFC2684]で説明されたメカニズムがことである方法を指定することです。
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 PDUsはAAL5のCommon Part Convergence Sublayer(CPCS)PDUsのペイロード分野で運ばれるものとします、そして、AAL5のService Specific Convergence Sublayer(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. 論理的なLink Control(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番目のメカニズムで、ペイロードのプロトコルタイプは各AAL5 PDUでIEEE802.2LLCヘッダーによって明らかに特定されます。 このメカニズムは「L2TPであるとカプセル化されたLLC」と呼ばれるでしょう。
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. PVCsの上のL2TPであるとカプセル化されたLLCをサポートしなければなりません。 2. 5月のサポートLLCはSVCsの上のL2TPをカプセル化しました。 3. PVCsかSVCsの上のVCによって多重送信されたL2TPをサポートするかもしれません。
When a PVC is used, the endpoints must be configured to use one of the two encapsulation methods.
PVCが使用されているとき、2つのカプセル化メソッドの1つを使用するために終点を構成しなければなりません。
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.
実装がSVCsをサポートするなら、接続設定を交渉するのに[Q.2931]別館C手順を用いなければなりません、VCによって多重送信されたL2TPかL2TPであるとカプセル化されたLLCのどちらかに合図するために、Broadband Lower Layer Interface(B-LLI)情報要素(IE)をコード化して。 このコントロール飛行機手順の詳細はセクション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.
実装がユニットを織り込むFrame Relay/ATM FRF.8[FRF8]サービスで接続しているなら、それはL2TPであるとカプセル化されたLLCを使用しなければなりません。
Singh, et. al. Standards Track [Page 4] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[4ページ]RFC3355L2TP
5. LLC Encapsulated L2TP over AAL5
5. AAL5の上のL2TPであるとカプセル化されたLLC
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 SHALLでは、示されるとして図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. IEEE802.2LLCヘッダー: Un番号付の情報(値0x03)のフレームタイプで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はヘッダーを折ります: 0×00 00-5Eの3八重奏Organizationally Unique Identifier(OUI)価値はIANA(インターネットAssigned民数記Authority)を特定します。 2八重奏プロトコルIdentifier(PID)は、L2TPがカプセル化されたプロトコルであると認識します。 PID値は0×0007です。
3. The L2TP PDU:
3. L2TP PDU:
Figure 1 - LLC Encapsulated L2TP PDU
図1--L2TP PDUであるとカプセル化されたLLC
+-------------------------+ --------
| Destination SAP (0xAA) | ^
+-------------------------+ |
| Source SAP (0xAA) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| OUI (0x00-00-5E)| |
+-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header
| PID (0x00-07) | |
+-------------------------+ --------
| | |
| | L2TP PDU
| | |
+-------------------------+ --------
+-------------------------+ -------- | 目的地体液(0xAA)| ^ +-------------------------+ | | ソースSAP(0xAA)| LLCヘッダー+-------------------------+ | | フレームタイプはUI(0×03)と等しいです。| +に対して-------------------------+ -------- | OUI(0×00 00-5E)| | +-+-+-+-+-+-+-+-+-+-+-+-+-| ヘッダーを折ってください。| PID(0×00-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を送るために2横に食糧を供給されるかもしれません。
Singh, et. al. Standards Track [Page 5] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[5ページ]RFC3355L2TP
6. Virtual Circuit Multiplexed L2TP over AAL5
6. 仮想の回路はAAL5の上にL2TPを多重送信しました。
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
+-------------------------------+ -------
+-------------------------------+ ------- | . | ^ | . | | | CPCS-PDUペイロード| L2TP PDU| 最大2^16--1八重奏) | | | . | +に対して-------------------------------+ ------- | PAD(0--47の八重奏) | +-------------------------------+ ------- | CPCS-UU(1つの八重奏) | ^ +-------------------------------+ | | CPI(1つの八重奏) | | +-------------------------------+ CPCS-PDUトレーラ| 長さ(2つの八重奏) | | +-------------------------------| | | CRC(4つの八重奏) | +に対して-------------------------------+ -------
The Common Part Convergence Sub-layer (CPCS) PDU payload field contains user information up to 2^16 - 1 octets.
Common Part Convergence Sub-層(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分野は、セルの中でSAR副層によって作成された最後の48八重奏セルペイロードでCPCS-PDU Trailer権利を正当化するようにちょうどATMセルに収まるように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(一般的なPart Indicator)分野はCPCS-PDUトレーラを64ビットに並べます。 さらなる研究には可能な追加機能がITU-Tにあります。 64だけがいつアライメント機能に噛み付いたかは、使用されていて、この分野はSHALLです。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の八重奏です。 0×00としてコード化されたLength分野は放棄機能に使用されるかもしれません。
Singh, et. al. Standards Track [Page 6] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[6ページ]RFC3355L2TP
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ペイロードSHALLは[RFC2661]で定義されるようにL2TP PDUから成ります。
7. Out-of-Band Control Plane Signaling
7. バンドの外では、飛行機シグナリングは制御されます。
7.1 Connection Setup
7.1 接続設定
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のどちらかで起因することができます。 SVCsの使用をサポートする実装は、SVCセットアップ要求に起因して、応じることができなければなりません。 以下で指定されたB-LLI IEを除いて、他のすべてのIEsが(UNI)が[RFC2331]に従ってコード化されるべきであるとSpecificationバージョン4.0[SIG40]に合図するATM User-ネットワークInterfaceに必要です。
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(L2TPか、VCによって多重送信されたものと同様にLLCによってカプセル化されたL2TPであるとカプセル化されたLLC)を要求しなければなりません。 B-LLI IE SHALL、使用されて、要求されたカプセル化メソッドを指定してください。 カプセル化、2B-LLI IEs SHALLを両方に提供して、訪問者がそうであるときには送付者の好みの注文におけるBroadband Repeat Indicator情報要素の中でコード化されてください。
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.
電話することであるとL2TPペイロード、[Q.2931]B-LLI IEユーザー情報2プロトコル分野SHALL層を運ぶことになっているカプセル化されたLLCを溯源するときにはコード化されて、八重奏6でLAN Logical Link Control(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ペイロード、層2のプロトコル分野SHALLが2が八重奏6で議定書の中で述べない層を全く選択するためにコード化されて、層にするという[Q.2931]B-LLI IEユーザー情報を運ぶために、3が分野SHALLについて議定書の中で述べるというVCによって多重送信された要求を溯源するときにはコード化されて、八重奏7でISO/IEC TR9577[ISO9577]を選択してください。 その上、DSL Forum TR-037[DSLF037]に従って拡大八重奏はVCによって多重送信されたL2TPを指定します、L2TPのためにIANAによって割り当てられたPIDが続いてIANAによって所有されていたOUIによって続かれたSNAP IPIを使用するのを指定します。 したがって、User情報層3のプロトコル分野はコード化されます: 0B80 00 00 5E00 07。 AAL5フレームのもの
Singh, et. al. Standards Track [Page 7] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[7ページ]RFC3355L2TP
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は使われますが、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.
訪問者が両方のカプセル化メソッドを提供して、呼ばれた同輩が呼び出しを受け入れるなら、呼ばれた同輩SHALLは、ちょうどConnectメッセージの1B-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をきれいにしなければなりません。 トンネルのどんなユーザセッションもリセットで終えられるでしょう。 どちらの終わりも、クライアントからの新しい要求を受け取り次第トンネルを復職させるのを試みるかもしれません。
7.2 Connection Setup Failure
7.2 接続設定失敗
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実体は、呼ばれた実体が手が届かないと考えるかもしれません。 実体が別のものが手が届かないことを決定する状態とそれが、もう片方が再び利用可能であることをどう決定するかは、実装決定です。
7.3 Connection Teardown
7.3 接続分解
When there are no active sessions on an SVC tunnel, either end MAY optionally clear the connection.
いつ、どんな活発なセッションもSVCトンネル、どちらの終わりにもないかが任意に接続をきれいにするかもしれません。
8. Connection Failure
8. 接続失敗
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接続がきれいにされて、トンネルとリターンの下側へのImplementation SHALL裂け目が活動していない状態へのコントロール接続であるという通知に関して。
9. Security Considerations
9. セキュリティ問題
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].
Layer Two Tunnelingプロトコル基礎仕様[RFC2661]はL2TPトンネリングに関する基本的な安全保障問題について議論します。 ATM転送ネットワーク自体の攻撃でAAL5トンネルセキュリティのL2TPが感染されるのは、可能です。 ATM ForumはATM転送ネットワークへの一般的な脅威に用心するために手順を定義するセキュリティフレームワーク[AFSEC1]とセキュリティ仕様[AFSEC2]を発表しました。 ATM切り換えネットワークへの脅威に対する保護を必要とするアプリケーションが認証ヘッダー、暗号化されたペイロード、そして/または、セキュリティー・サービスが[AFSEC2]で説明したATM-層を使用するよう奨励されます。
Singh, et. al. Standards Track [Page 8] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[8ページ]RFC3355L2TP
10. Acknowledgments
10. 承認
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.
このドキュメントは以下から材料を大いに利用します。 「マヌーのジョージGross、Kaycee、アーサー・リン、アンドリューMalis、およびジョン・スティーブンスのそばのPPP Over AAL5"(RFC2364)とNagraj Arunkumar、マヌーKaycee、ティム・クォック、およびアーサー・リンのそばのAAL5の上のL2TPの以前のドキュメント。」
Special thanks to Mike Davison, Arthur Lin, John Stevens for making significant contributions to the initial version of this document.
マイク・デイヴィソン、アーサー・リン、このドキュメントの初期のバージョンへの重要な貢献をするためのJohn Stevensへの特別な感謝。
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.
このドキュメントのセキュリティ部はRFC3337、「非同期通信モード適合層2(AAL2)の上のpppのためのクラス拡大」に基づいています、ブルーストンプソン、ブルースBuffam、およびThimaコーレン。
11. References
11. 参照
[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.、シンPall、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル(L2TP)にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[SIG31] The ATM Forum, "ATM User-Network Interface Specification
V3.1", af-uni-0010.002, 1994.
[SIG31] ATM Forum、「気圧ユーザネットワーク・インターフェース仕様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気圧適合層(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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684] グロースマン、D.、およびJ.Heinanen、「気圧適合の上のMultiprotocolカプセル化は1999年9月に5インチ、RFC2684を層にします」。
[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)のデジタル加入者シグナリングシステム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] フレームリレーフォーラム、「実装協定を織り込むフレームリレー/気圧PVCサービス」、FRF.8、1995年4月。
Singh, et. al. Standards Track [Page 9] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[9ページ]RFC3355L2TP
[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 DTR9577.2、「情報技術(システムの間のテレコミュニケーションと情報交換)はネットワーク層でIdentificationについて議定書の中で述べます」、1995-08- 16。
[RFC2331] Maher, M., "ATM Signaling Support for IP over ATM - UNI
Signaling 4.0 Update", RFC 2331, April 1998.
[RFC2331]マーヘル、M.、「UNIが4.0アップデートに合図して、シグナリングがIPのために気圧でサポートする気圧」、RFC2331、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)と気圧を使用するネットワークの間の自動構成」、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 Forum、「仕様バージョン4インチに合図する気圧ユーザネットワーク・インターフェース(UNI)(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]気圧フォーラム、「TM4.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 Forum、「ILMI Auto-構成拡大への付加物」、af nm00165.000、2001年4月。
[AFSEC1] The ATM Forum, "ATM Security Framework Version 1.0", af-
sec-0096.000, February 1998
[AFSEC1] ATM Forum、「気圧セキュリティフレームワークバージョン1インチ、af秒-0096.000、1998年2月」
[AFSEC2] The ATM Forum, "ATM Security Specification v1.1", af-sec-
0100.002, March 2001
[AFSEC2] ATM Forum、「ATM Security Specification v1.1"、af秒-0100.002、2001年3月」
Singh, et. al. Standards Track [Page 10] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[10ページ]RFC3355L2TP
Appendix A. Acronyms
付録A.頭文字語
AAL5 ATM Adaptation Layer Type 5
AAL5気圧適合層のタイプ5
ATM Asynchronous Transfer Mode
気圧非同期通信モード
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層Twoのトンネリングプロトコル
LAC L2TP Access Concentrator
ラック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
サブネットワークアドレスプロトコルを折ってください。
SVC Switched Virtual Circuit
SVC交換仮想回路
VC Virtual Circuit
VCの仮想の回路
Singh, et. al. Standards Track [Page 11] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[11ページ]RFC3355L2TP
Authors' Addresses
作者のアドレス
Rollins Turner Paradyne Corporation 8545 126th Avenue North Largo, FL 33773
フロリダ ロリンターナーParadyne社8545の第126アベニュー北部ラルゴ、33773
EMail: rturner@eng.paradyne.com
メール: rturner@eng.paradyne.com
Rene Tio Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
レネイTio RedbackはInc.300オルガーWayサンノゼ(カリフォルニア)95134をネットワークでつなぎます。
EMail: tor@redback.com
メール: tor@redback.com
Ajoy Singh Motorola 1421 West Shure Dr, Arlington Heights, IL 60004
アーリントンハイツ、イリノイ Ajoyシン・モトローラ1421西シュアー博士、60004
EMail: asingh1@motorola.com
メール: asingh1@motorola.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way Sunnyvale, CA 95134
Suhail Nanji20ドル紙幣はInc.300オルガーWayサニーベル(カリフォルニア)95134をネットワークでつなぎます。
EMail: suhail@redback.com
メール: suhail@redback.com
Singh, et. al. Standards Track [Page 12] RFC 3355 L2TP Over AAL5 August 2002
etシン、アル。 AAL5 August 2002の上の標準化過程[12ページ]RFC3355L2TP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Singh, et. al. Standards Track [Page 13]
etシン、アル。 標準化過程[13ページ]
一覧
スポンサーリンク
