RFC3070 日本語訳
3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay. V. Rawat,R. Tio, S. Nanji, R. Verma. February 2001. (Format: TXT=12940 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Rawat Request for Comments: 3070 ONI Systems, Inc. Category: Standards Track R. Tio S. Nanji Redback Networks, Inc. R. Verma Deloitte Consulting February 2001
Rawatがコメントのために要求するワーキンググループV.をネットワークでつないでください: 3070年のONIシステムInc.カテゴリ: 規格はInc.R.Verma Deloitteコンサルティング2001年2月にR.Tio S.Nanji20ドル紙幣ネットワークを追跡します。
Layer Two Tunneling Protocol (L2TP) over Frame Relay
フレームリレーの上でプロトコル(L2TP)にトンネルを堀る層Two
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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel Point-to-Point (PPP) sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over the User Datagram Protocol (UDP) and the Internet Protocol (IP). This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs).
層のTwo Tunnelingプロトコル(L2TP)はトンネルのPointからポイント(PPP)へのセッションまでメカニズムについて説明します。 プロトコルは、それが目を通すメディアから独立しているように設計されています。基礎仕様はそれがユーザー・データグラム・プロトコル(UDP)とインターネットプロトコル(IP)をひくためにどう実装されるべきであるかを説明します。 このドキュメントはL2TPがFrame Relay Permanent Virtual Circuits(PVCs)とSwitched Virtual Circuits(SVCs)の上でどう実装されるかを説明します。
Applicability
適用性
This specification is intended for those implementations which desire to use facilities which are defined for L2TP and applies only to the use of Frame Relay pont-to-point circuits.
この仕様は、L2TPのために定義される施設を使用することを望んでいるそれらの実装のために意図して、Frame Relay pontからポイントへの回路の使用だけに適用されます。
1.0 Introduction
1.0 序論
L2TP [1] defines a general purpose mechanism for tunneling PPP over various media. By design, it insulates L2TP operation from the details of the media over which it operates. The base protocol specification illustrates how L2TP may be used in IP environments. This document specifies the encapsulation of L2TP over native Frame Relay and addresses relevant issues.
L2TP[1]はトンネリングPPPのために様々なメディアの上で汎用のメカニズムを定義します。 故意に、それはそれが作動するメディアの細部からL2TP操作を隔離します。 ベースプロトコル仕様はL2TPがIP環境でどう使用されるかもしれないかを例証します。 このドキュメントは、ネイティブのFrame Relayの上でL2TPのカプセル化を指定して、当該の問題を扱います。
Rawat, et al. Standards Track [Page 1] RFC 3070 L2TP over Frame Relay February 2001
Rawat、他 規格は2001年2月にフレームリレーの上でRFC3070L2TPを追跡します[1ページ]。
2.0 Conventions
2.0 コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3.0 Problem Space Overview
3.0 問題スペース概要
In this section we describe in high level terms the scope of the problem being addressed. Topology:
このセクションでは、私たちは高い平らな用語で扱われることにおける問題の範囲について説明します。 トポロジー:
+------+ +---------------+ | | PSTN | | Frame Relay | | User--| |----LAC ===| |=== LNS --+ LANs | ISDN | | Cloud | | +------+ +---------------+ |
+------+ +---------------+ | | PSTN| | フレームリレー| | ユーザ--| |----ラック===| |=== LNS--+ LAN| ISDN| | 雲| | +------+ +---------------+ |
An L2TP Access Concentrator (LAC) is a device attached to the switched network fabric (e.g., PSTN or ISDN) or co-located with a PPP end system capable of handling the L2TP protocol. The LAC need only implement the media over which L2TP is to operate to pass traffic to one or more LNS's. It may tunnel any protocol carried within PPP.
L2TP Access Concentrator(LAC)は交換網骨組み(例えば、PSTNかISDN)に取り付けられたか、またはPPPエンドシステムができていた状態でL2TPプロトコルを扱うのについて共同見つけられたデバイスです。 LACはL2TPがLNSの1つ以上のものにトラフィックを通過するために作動することになっているメディアを実装するだけでよいです。 それはPPPの中で運ばれたどんなプロトコルにもトンネルを堀るかもしれません。
L2TP Network Server (LNS) operates on any platform capable of PPP termination. The LNS handles the server side of the L2TP protocol. L2TP is connection-oriented. The LNS and LAC maintain state for each user that is attached to an LAC. A session is created when an end- to-end PPP connection is attempted between a user and the LNS. The datagrams related to a session are sent over the tunnel between the LAC and LNS. A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS.
L2TP Network Server(LNS)はPPP終了ができるどんなプラットホームも作動させます。 LNSはL2TPプロトコルのサーバ側を扱います。 L2TPは接続指向です。 LNSとLACはLACに付けられている各ユーザのために状態を維持します。 終わりまでの終わりのPPP接続がユーザとLNSの間で試みられるとき、セッションは作成されます。 LACとLNSの間のトンネルの上にセッションまで関係づけられたデータグラムを送ります。 トンネルはLNS-LAC組によって定義されます。 トンネルはLACとLNSの間までPPPデータグラムを運びます。
L2TP protocol operates at a level above the particular media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. L2TP over IP/UDP is described in the base L2TP specification [1]. Issues related to L2TP over Frame Relay are addressed in later sections of this document.
それが運ばれる特定のメディアを超えてL2TPプロトコルはレベルで作動します。 しかしながら、メディアとの接続のいくつかの細部が、共同利用できる実装を可能にするのに必要です。 IP/UDPの上のL2TPはベースL2TP仕様[1]で説明されます。 Frame Relayの上でL2TPに関連する問題はこのドキュメントの後のセクションで扱われます。
4.0 Encapsulation and Packet Format
4.0 カプセル化とパケット・フォーマット
L2TP MUST be able to share a Frame Relay virtual circuit (VC) with other protocols carried over the same VC. The Frame Relay header format for data packet needs to be defined to identify the protocol being carried in the packets. The Frame Relay network may not understand these formats.
L2TP MUST、同じVCの上まで運ばれる他のプロトコルとFrame Relayの仮想の回路(VC)を共有できてください。 データ・パケットのためのFrame Relayヘッダー形式は、パケットで運ばれるプロトコルを特定するために定義される必要があります。 Frame Relayネットワークはこれらの形式を理解しないかもしれません。
Rawat, et al. Standards Track [Page 2] RFC 3070 L2TP over Frame Relay February 2001
Rawat、他 規格は2001年2月にフレームリレーの上でRFC3070L2TPを追跡します[2ページ]。
All protocols over this circuit MUST encapsulate their packets within a Q.922 frame. Additionally, frames must contain information necessary to identify the protocol carried within the frame relay Protocol Data Unit (PDU), thus allowing the receiver to properly process the incoming packet.
この回路の上のすべてのプロトコルがQ.922フレームの中にそれらのパケットをカプセルに入れらなければなりません。 さらに、フレームはフレームリレープロトコルData Unit(PDU)の中で運ばれたプロトコルを特定するのに必要な情報を含まなければなりません、その結果、受信機が適切に入って来るパケットを処理するのを許容します。
The frame format for L2TP MUST be SNAP encapsulation as defined in RFC 1490 [6] and FRF3.1 [3]. SNAP format uses NLPID followed by Organizationally Unique Identifier and a PID.
フレームはRFC1490[6]で定義されるSNAPカプセル化とFRF3.1が[3]であったならL2TP MUSTのためにフォーマットします。 SNAP形式はOrganizationally Unique IdentifierとPIDによって続かれたNLPIDを使用します。
NLPID
NLPID
The single octet identifier provides a mechanism to allow easy protocol identification. For L2TP NLPID value 0x80 is used which indicates the presence of SNAP header.
ただ一つの八重奏識別子は、簡単なプロトコル識別を許すためにメカニズムを提供します。 L2TP NLPIDに関しては、値0x80は使用されています(SNAPヘッダーの存在を示します)。
OUI & PID
OUI&PID
The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5E identifies IANA who administers the meaning of the Protocol Identifier (PID) 0x0007. Together they identify a distinct protocol.
3八重奏の00-5 0×00Organizationally Unique Identifier E(OUI)がプロトコルIdentifier(PID)0×0007のものの意味を管理するIANAを特定します。 彼らは異なったプロトコルを一緒に、特定します。
Format of L2TP frames encapsulated in Frame Relay is given in Figure 1.
図1でFrame Relayでカプセル化されたL2TPフレームの書式を与えます。
Octet 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Q.922 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Control 0x03 | pad 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | NLPID 0x80 | OUI 0x00 | +-+-+-+-+-+-+-+-+ + 7 | OUI 0x00-5E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | PID 0x0007 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | L2TP packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
八重奏1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+++++++++++++++++1| Q.922アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | コントロール0x03| パッド0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | NLPID0x80| OUI0x00| +-+-+-+-+-+-+-+-+ + 7 | OUI0×00-5E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | PID0x0007| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | L2TPパケット| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Format for L2TP frames encapsulated in Frame Relay
図1 Frame Relayでカプセル化されたL2TPフレームへのFormat
Rawat, et al. Standards Track [Page 3] RFC 3070 L2TP over Frame Relay February 2001
Rawat、他 規格は2001年2月にフレームリレーの上でRFC3070L2TPを追跡します[3ページ]。
5.0 MTU Considerations
5.0 MTU問題
FRF.12 [5] is the Frame Relay Fragmentation Implementation Agreement. If fragmentation is not supported, the two Frame Relay endpoints MUST support an MTU size of at least 1526 which is based on adding the PPP Max-Receive-Unit size with the PPP header size with the Max L2TP Header Size with the Frame Relay header size (PPP header size is the protocol field size plus HDLC framing bytes, which is required by L2TP). To avoid packet discards on the Frame Relay interface, the RECOMMENDED default Frame Relay MTU is 1564 based on a PPP default MRU of 1500. The means to ensure these MTU settings are left to implementation.
FRF.12[5]はFrame Relay Fragmentation Implementation Agreementです。 断片化がサポートされないなら、2つのFrame Relay終点が、MTUがマックスL2TP Header Sizeと共にFrame RelayヘッダーサイズでPPPヘッダーサイズに従ったマックスがユニットを受けているPPPサイズを加えるのに基づいている少なくとも1526年のサイズであるとサポートしなければなりません(PPPヘッダーサイズは、プロトコル分野サイズとHDLC縁どりバイトです)。(バイトはL2TPによって必要とされます)。 Frame Relayインタフェースでパケット破棄を避けるために、RECOMMENDEDデフォルトFrame Relay MTUは1500年のPPPデフォルトMRUに基づいた1564です。 これらのMTU設定を確実にする手段は実装に残されます。
6.0 QOS Issues
6.0 QOS問題
In general, QoS mechanisms can be roughly provided for with proprietary mechanisms localized within the LAC or LNS. QoS considerations are beyond the scope of this document.
一般に、独占メカニズムがLACかLNSの中でローカライズされている状態で、手荒くQoSメカニズムに備えることができます。 QoS問題はこのドキュメントの範囲を超えています。
7.0 Frame Relay and L2TP Interaction
7.0 フレームリレーとL2TP相互作用
In case of Frame Relay SVCs, connection setup will be triggered when L2TP tries to create a tunnel. Details of triggering mechanism are left to implementation. There SHALL NOT be any change in Frame Relay SVC signaling due to L2TP. The endpoints of the L2TP tunnel MUST be identified by X.121/E.164 addresses in case of Frame Relay SVC. These addresses MAY be obtained as tunnel endpoints for a user as defined in [4]. In case of PVCs, the Virtual Circuit to carry L2TP traffic MAY be configured administratively. The endpoints of the tunnel MUST be identified by DLCI, assigned to the PVC at configuration time. This DLCI MAY be obtained as tunnel endpoints for a user as defined in [4].
Frame Relay SVCsの場合には、L2TPがトンネルを作成しようとするなら、接続設定は引き起こされるでしょう。 トリガー・メカニズムの細部は実装に残されます。 そこでは、SHALL NOTがいくらかそうです。Frame Relay SVCでL2TPのため合図するのを変えてください。 Frame Relay SVCの場合にX.121/E.164アドレスでL2TPトンネルの終点を特定しなければなりません。 [4]で定義されるユーザのためのトンネル終点としてこれらのアドレスを得るかもしれません。 PVCsの場合には、L2TPトラフィックを運ぶVirtual Circuitは行政上構成されるかもしれません。 構成時にPVCに割り当てられたDLCIはトンネルの終点を特定しなければなりません。 このDLCI MAY、[4]で定義されるユーザのためのトンネル終点として、得てください。
There SHALL be no framing issues between PPP and Frame Relay. PPP frames received by LAC from remote user are stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over Frame Relay tunnel.
そこ、PPPとFrame Relayの間の問題を縁どらないことであるSHALL。 LACによってリモート・ユーザーから受け取られたPPPフレームを、CRC、リンク縁どり、および透明バイトを奪い取って、L2TPでカプセル化して、Frame Relayトンネルの上に送ります。
8.0 Security Considerations
8.0 セキュリティ問題
Currently there is no standard specification for Frame Relay security although the Frame Relay Forum is working on a Frame Relay Privacy Agreement. In light of this work, the issue of security will be re- examined at a later date to see if L2TP over Frame Relay specific protection mechanisms are still required. In the interim, basic security issues are discussed in the base L2TP specification [1].
現在、Frame Relay ForumはFrame Relay Privacy Agreementに勤めていますが、Frame Relayセキュリティのためのどんな標準の仕様もありません。 この仕事の観点から、秘密保持の問題は、より後日、Frame Relay特異的予防メカニズムの上のL2TPがまだ必要であるかどうか確認するために再調べられるでしょう。 その間、ベースL2TP仕様[1]で基本的な安全保障問題について議論します。
Rawat, et al. Standards Track [Page 4] RFC 3070 L2TP over Frame Relay February 2001
Rawat、他 規格は2001年2月にフレームリレーの上でRFC3070L2TPを追跡します[4ページ]。
9.0 Acknowledgments
9.0 承認
Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com Corporation) contributed to the editing of this document.
ケン・ピアス(3Com社)と(リックDynarski 3Com社)はこのドキュメントの編集に貢献しました。
10.0 References
10.0の参照箇所
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.
[1] Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.は「層Twoのトンネリングプロトコル'L2TP'」をあしらいます、RFC2661、1999年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Multiprotocol Encapsulation Implementation Agreement, FRF.3.1 , Frame Relay Forum Technical Committee, June 1995.
[3] Multiprotocolカプセル化実装協定、FRF.3.1、フレームリレーフォーラム専門委員会、1995年6月。
[4] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[4]ゾルン、G.、ライファー、D.、ルーベン、A.、シュライバー、J.、Holdrege、M.、およびI.Goyret、「トンネルへの半径属性はサポートについて議定書の中で述べます」、RFC2868、2000年6月。
[5] Frame Relay Fragmentation Implementation Agreement, FRF.12, Frame Relay Forum Technical Committee, December 1997.
[5] フレームリレー断片化実装協定、FRF.12、フレームリレーフォーラム専門委員会、1997年12月。
[6] Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
[6]ブラッドリーとT.とブラウンとC.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC1490、1993年7月。
Rawat, et al. Standards Track [Page 5] RFC 3070 L2TP over Frame Relay February 2001
Rawat、他 規格は2001年2月にフレームリレーの上でRFC3070L2TPを追跡します[5ページ]。
11.0 Authors' Addresses
11.0 作者のアドレス
Vipin Rawat ONI Systems, Inc. 166 Baypointe Parkway San Jose CA 95134
Vipin Rawat ONI Systems Inc.166Baypointe公園道路サンノゼカリフォルニア 95134
EMail: vrawat@oni.com
メール: vrawat@oni.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
Rohit Verma Deloitte Consulting 180 N. Stetson Avenue Chicago Illinois 60601
Rohit Verma Deloitte Consulting180N.ステットソン帽アベニューシカゴイリノイ 60601
EMail: rverma@dc.com
メール: rverma@dc.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Suhail Nanji20ドル紙幣はInc.300オルガーWayサンノゼ(カリフォルニア)95134をネットワークでつなぎます。
EMail: suhail@redback.com
メール: suhail@redback.com
Rawat, et al. Standards Track [Page 6] RFC 3070 L2TP over Frame Relay February 2001
Rawat、他 規格は2001年2月にフレームリレーの上でRFC3070L2TPを追跡します[6ページ]。
12.0 Full Copyright Statement
12.0 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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機能のための基金は現在、インターネット協会によって提供されます。
Rawat, et al. Standards Track [Page 7]
Rawat、他 標準化過程[7ページ]
一覧
スポンサーリンク