RFC3301 日本語訳
3301 Layer Two Tunnelling Protocol (L2TP): ATM access networkextensions. Y. T'Joens, P. Crivellari, B. Sales. June 2002. (Format: TXT=42756 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. T'Joens
Request for Comments: 3301 B. Sales
Category: Standards Track Alcatel
P. Crivellari
Belgacom
June 2002
T'Joensがコメントのために要求するワーキンググループY.をネットワークでつないでください: 3301年のB.販売カテゴリ: 標準化過程アルカテルP.Crivellari Belgacom2002年6月
Layer Two Tunnelling Protocol (L2TP):
ATM access network extensions
層Twoのトンネルプロトコル(L2TP): ATMアクセスネットワーク拡張子
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
要約
This document augments the procedures described in RFC 2661 to further support ATM SVC (Switched Virtual Circuits) or PVC (Permanent Virtual Circuits) based access networks. L2TP (Layer 2 Tunneling Protocol) specifies a protocol for tunnelling PPP packets over packet based networks and over IP networks in particular. L2TP supports remote access by ISDN and PSTN networks. The extensions defined within this document allow for asymmetric bi-directional call establishment and service selection in the ATM access network.
このドキュメントはATM SVC(Virtual Circuitsを切り換える)かPVC(永久的なVirtual Circuits)がベースのアクセスネットワークであるとさらにサポートするためにRFC2661で説明された手順を増大させます。 L2TP(層2のTunnelingプロトコル)はパケットに基づいているネットワークの上と、そして、特にIPネットワークの上でトンネルPPPパケットにプロトコルを指定します。 L2TPはISDNとPSTNネットワークで遠隔アクセスをサポートします。 このドキュメントの中に定義された拡張子はATMアクセスネットワークで非対称の双方向の呼び出し設立とサービス選択を考慮します。
Table Of Contents
目次
1. Introduction .................................................. 2 1.1 Conventions .................................................. 2 2. Assumptions ................................................... 3 2.1 Topology ..................................................... 3 2.2 Connection Establishment ..................................... 3 2.3 LCP Negotiation .............................................. 3 3. ATM access enhanced procedures ................................ 3 3.1 ATM connectivity ............................................. 4 3.2 Tunnel establishment ......................................... 4 3.3 Call establishment ........................................... 5 3.3.1 Incoming Call Establishment ................................ 5 3.3.2 Outgoing Call Establishment ................................ 6
1. 序論… 2 1.1のコンベンション… 2 2. 仮定… 3 2.1トポロジー… 3 2.2 接続設立… 3 2.3 LCP交渉… 3 3. ATMアクセスは手順を高めました… 3 3.1ATMの接続性… 4 3.2 設立にトンネルを堀ってください… 4 3.3 設立に電話をしてください… 5 3.3 .1 かかってきた電話設立… 5 3.3 .2 発信電話設立… 6
T'Joens, et al. Standards Track [Page 1] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[1ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
3.4 Framing ...................................................... 6 4. Service model issues .......................................... 7 4.1 Authentication ............................................... 7 4.2 Authorization ................................................ 7 5. New and extended AVPs ......................................... 7 5.1 New AVP Summary .............................................. 7 5.2 New AVP definition ........................................... 8 5.3 Changed AVP Definition ....................................... 12 6. IANA considerations ........................................... 16 7. Security considerations ....................................... 17 8. Acknowledgements .............................................. 17 9. References .................................................... 17 10. Authors Addresses ............................................ 18 11. Full Copyright Statement ..................................... 19
3.4 縁どっています。 6 4. モデル問題を修理してください… 7 4.1認証… 7 4.2承認… 7 5. 新しくて拡張しているAVPs… 7 5.1の新しいAVP概要… 7 5.2 新しいAVP定義… 8 5.3はAVP定義を変えました… 12 6. IANA問題… 16 7. セキュリティ問題… 17 8. 承認… 17 9. 参照… 17 10. アドレスを書きます… 18 11. 完全な著作権宣言文… 19
1. Introduction
1. 序論
L2TP [RFC2661] defines the procedures for tunneling PPP sessions between a so called L2TP Access Concentrator (LAC) and an L2TP Network Server (LNS). The main focus of [RFC2661] is on supporting HDLC based ISDN/PSTN access networks.
L2TP[RFC2661]はいわゆるL2TP Access Concentrator(LAC)とL2TP Network Server(LNS)とのトンネリングPPPセッションのための手順を定義します。 [RFC2661]の主な焦点がHDLCのベースのISDN/PSTNアクセスがネットワークであるとサポートするところにあります。
This document augments the procedures described in [RFC2661] to further support ATM SVC or PVC based access networks. Support for ATM access networks requires extensions to the present L2TP procedures so as to cope with :
このドキュメントがさらにATM SVCをサポートするために[RFC2661]で説明された手順を増大させるか、またはPVCはアクセスネットワークを基礎づけました。 ATMアクセスネットワークのサポートは対処するために現在のL2TP手順に拡大を必要とします:
(a) the traffic management aspects of ATM connections (e.g.
asymmetric bandwidth allocation and service category selection
capabilities),
(a) ATM接続(例えば、非対称の帯域幅配分とサービスカテゴリ選択能力)の輸送管理局面
(b) the addressing format to be used in switched ATM networks [AESA]
and
そして(b) 切り換えられたATMで使用されるべきアドレス指定形式が[AESA]をネットワークである。
(c) the limitations imposed on LCP negotiation by transporting PPP
over AAL5 over the access network segment of the PPP connection
[RFC2364].
(c) アクセスの上でAAL5の上でPPPを輸送することによってLCP交渉に課された制限はPPP接続[RFC2364]のセグメントをネットワークでつなぎます。
Within this document, the necessary extensions to [RFC2661] are defined to cope with issues (a) and (b), issue (c) which is not specific to ATM may be solved as described in [L2TP_link].
(b) このドキュメントの中では、[RFC2661]への必要な拡大は問題(a)に対処するために定義されます、そして、ATMに特定でない問題(c)は[L2TP_リンク]で説明されるように解決されるかもしれません。
1.1 Conventions
1.1 コンベンション
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]で説明されるように本書では解釈されることであるべきですか?
T'Joens, et al. Standards Track [Page 2] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[2ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
2. Assumptions
2. 仮定
In this section we describe some assumptions that have lead to the extensions described in this document.
このセクションで、私たちはリードが拡大に説明されるのを本書では持っているいくつかの仮定について説明します。
2.1 Topology
2.1 トポロジー
The procedures as defined in [RFC2661] apply mainly to access network technology such as PSTN and ISDN, which may be respectively asynchronous HDLC and synchronous HDLC based. The aim of this document is to extend L2TP support to allow for user / LAC communication based on ATM access network technology.
[RFC2661]で定義される手順は、主にそれぞれ非同期なHDLCとベースの同期HDLCであるかもしれないPSTNやISDNなどのネットワーク技術にアクセスするのに当てはまります。 このドキュメントの目的はATMアクセスネットワーク技術に基づくユーザ/LACコミュニケーションを考慮するためにL2TPサポートを広げることです。
2.2 Connection Establishment
2.2 コネクション確立
Due to the wide variety of existing signalling protocols and ATM service categories, and their support or non-support within ATM based access networks, this document takes as approach to provide for a flexible identification of ATM connection characteristics while establishing outgoing and incoming L2TP calls. The procedures as defined within this document allow the allocation of asymmetric bandwidth and service category selection in terms of real or non-real time requirements on the ATM portion of the access network.
ATMのベースのアクセスネットワークの中の彼らの広いバラエティーのプロトコルに合図しながら存在して、ATMサービスカテゴリと、サポートか非サポートのため、送受信のL2TPを設立している間にATM接続の特性のフレキシブルな識別に提供するアプローチが呼ぶようにこのドキュメントは取ります。 このドキュメントの中に定義される手順はアクセスネットワークのATM部分に関する本当の、または、非リアルタイムの要件に関して非対称の帯域幅とサービスカテゴリ選択の配分を許します。
As such, the detailed signalling protocol specific information elements that are necessary for switched VC service, are explicitly not negotiated during call establishment over the L2TP tunnel.
そういうものとして切り換えられたVCサービスに必要な詳細な合図プロトコル特殊情報要素はL2TPトンネルの上の呼び出し設立の間、明らかに交渉されません。
In order to identify the endpoint of the ATM connection within the ATM access network, SVCs can be established on the basis of the ATM end system addressing format [AESA]. For PVC based services, the PVC can either be referred to by using the ATM end system addressing procedure (Called/Calling Number), or by making use of a textual name (Service Name). The latter is inspired by the procedures defined within [Auto_PVC].
ATMアクセスネットワークの中でATM接続の終点を特定するために、形式が[AESA]であると扱うATMエンドシステムに基づいてSVCsを設立できます。 PVCのベースのサービスについて、ATM終わりのシステムアドレシング手順(Numberと呼ばれるか、または呼ぶ)を用いるか、または原文の名前(サービスName)を利用することによって、PVCについて言及できます。 後者は[自動車_PVC]の中で定義された手順で奮い立たせられます。
2.3 LCP negotiation
2.3 LCP交渉
The procedures described within this document may be combined with the procedures described in [L2TP_link] to limit LCP negotiation between LNS and user, so as to enforce PPP over AAL5 specific LCP negotiation [RFC2364].
このドキュメントの中に説明された手順はLNSとユーザとのLCP交渉を制限するために[L2TP_リンク]で説明される手順に結合されるかもしれません、AAL5の特定のLCP交渉[RFC2364]の上でPPPを実施するために。
3. ATM access enhanced procedures
3. ATMアクセスは手順を高めました。
In order to illustrate the procedures specified within this document, this section will provide an operational description of Virtual dial-up access through an ATM based access network (e.g., ADSL).
このドキュメントの中に指定された手順を例証するために、このセクションはATMのベースのアクセスネットワーク(例えば、ADSL)を通したVirtualダイヤルアップアクセスの操作上の記述を提供するでしょう。
T'Joens, et al. Standards Track [Page 3] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[3ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
Note that the emphasis is on the changes proposed within this document relative to [RFC2661].
このドキュメントの中に[RFC2661]に比例して提案された変化の上に強調があることに注意してください。
3.1 ATM connectivity
3.1 ATMの接続性
Prior to initiating the PPP protocol layer, a Virtual Connection (VC) MUST be established between the user and the Network Access Server (LAC). This virtual connection MAY either be a preconfigured Permanent VC(PVC), where the access network provider, NAS and user agree beforehand on the characteristics of the PVC, or MAY be an on- demand switched VC(SVC), where the negotiation between user, network and NAS takes place by means of an ATM signalling protocol. Note that for establishing PVCs, alternative use may be made of the procedures as described in [Auto_PVC].
PPPプロトコル層を開始する前に、ユーザとNetwork Access Server(LAC)の間でVirtual Connection(vc)を確立しなければなりません。 そこでは、アクセスネットワーク内の提供者、NAS、およびユーザがあらかじめ、PVCの特性に同意します。この仮想接続があらかじめ設定されたPermanent VCであるかもしれない(PVC)、またはいるかもしれない、オンである、要求はVC(SVC)を切り換えました。そこでは、ユーザと、ネットワークとNASとの交渉がATM合図プロトコルによって行われます。 PVCsを設立するので、それに注意してください、そして、[自動車_PVC]で説明されるように手順で代替の使用をしてもよいです。
In both cases, the user is referred to as the virtual dial-in user.
どちらの場合も、ユーザは仮想のダイヤルインのユーザと呼ばれます。
Prior to accepting the switched connection from the virtual dial-in user, the LAC MAY check with the LNS whether the call should be accepted. In the latter situation, the LAC MAY determine based upon parameters available within the call establishment message that this concerns a virtual dial in user, or MAY undertake a partial authentication of the end system/user, in order to bind the end system/user with a specific LNS.
仮想のダイヤルインのユーザから切り換えられた接続を受け入れる前に、呼び出しを受け入れるべきであるか否かに関係なく、LAC MAYはLNSに問い合わせます。 後者の状況で、ユーザをこれが仮想のダイヤルにかかわるという呼び出し設立メッセージの中で利用可能なパラメタに基礎づけるか、または終わりのシステム/ユーザの部分的な認証を引き受けるかもしれませんLAC MAYが、決定する、特定のLNSと共に終わりのシステム/ユーザを縛るために。
For PVC based users, the LAC MAY be triggered by the arrival of an LCP Configure Request, or PPP Authentication request message from the virtual dial-in user to initiate conversation with the LNS. Note that the exact timing of triggering communication between LAC and LNS is outside the scope of this document.
PVCのベースのユーザに関しては、LAC MAYは、LCP Configure Requestの到着で引き起こされるか、またはLNSとの会話を開始するために仮想のダイヤルインのユーザから通信しますPPP Authenticationが、要求する。 このドキュメントの範囲の外にLACとLNSとの引き金となるコミュニケーションの正確なタイミングがあることに注意してください。
3.2 Tunnel establishment
3.2 トンネル設立
If no tunnel connection currently exists to the desired LNS, one is initiated. During the tunnel establishment, LNS and LAC indicate bearer and framing capabilities to each other, according to normal procedures.
どんなトンネル接続も現在必要なLNSに存在しないなら、1は開始されます。 トンネル設立の間、正常な手順に従って、LNSとLACは互いに運搬人と縁どり能力を示します。
The bearer capability is extended to allow the LAC to indicate its support of ATM bearer devices. Positive receipt of this indication, allows both LAC and LNS to use the extensions as defined within this document to support ATM based incoming and outgoing calls.
運搬人能力は、LACがATM運搬人デバイスのサポートを示すのを許容するために広げられます。 この指示の積極的な領収書、ベースの送受信の呼び出しをATMにサポートするためにこのドキュメントの中に定義されるようにLACとLNSの両方が拡張子を使用するのを許容します。
If no compatibility between LNS and LAC exists according to the extensions defined within this document, no tunnel establishment can take place. This would be because the LAC does not support any bearer capability which is expected by the LNS (e.g., an ATM based LAC, that only signals the "Broadband" Bearer Capability), or vice
このドキュメントの中に定義された拡大に従ってLNSとLACとの互換性が全く存在していないなら、トンネル設立は全く行われることができません。 これはLACがLNS(例えば、ATMはLACを基礎づけました、とそれは「広帯域」のBearer Capabilityに合図するだけである)によって予想される能力、または悪をどんな運搬人にもサポートしないからです
T'Joens, et al. Standards Track [Page 4] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[4ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
versa. It is however encouraged that LAC or LNS implementations would allow for seamless interworking with peer devices which do not implement the extensions defined within this document. This could be implemented by allowing a graceful fallback to digital bearer capability.
versa。 どのように、奨励されていても、LACかLNS実装がこのドキュメントの中に定義された拡大を実装しない同輩デバイスによるシームレスの織り込むことを考慮するでしょう。 デジタル運搬人能力に優雅な後退を許容することによって、これを実装することができるでしょう。
3.3 call establishment
3.3 呼び出し設立
During incoming and outgoing broadband call establishment, the following extensions are defined to existing procedures.
送受信の広帯域の呼び出し設立の間、以下の拡大は既存の手順と定義されます。
3.3.1 Incoming Call Establishment
3.3.1 かかってきた電話設立
The ATM connection between the virtual Dial-in user and LAC MAY either be dynamically or statically established. When the VC connection is dynamically established (Switched VC), the LAC will receive a SETUP message over the interface that connects it to the ATM network. This specification does not assume any specific interface type (UNI or NNI). Permanent VC connections MAY either be manually configured, or configured by use of the extensions to the ILMI procedures as defined by [Auto_PVC].
仮想の中のDialユーザとダイナミックにである静的に設立されたLAC MAYとのATM接続。 VC接続がダイナミックに確立されるとき(VCを切り換えます)、LACはATMネットワークにそれを関連づけるインタフェースの上にSETUPメッセージを受け取るでしょう。 この仕様は、どんな特定のインターフェース型も(UNIかNNI)であると仮定しません。 [自動車_PVC]によって定義されるように、永久的なVC接続は、拡張子の使用で手動でILMI手順に構成されるか、または構成されるかもしれません。
For switched VC connections, the LAC MAY select the peer LNS on the basis of connection establishment information, or by allowing partial PPP authentication of the virtual Dial-in user. The connection establishment information that can be used by the LAC include Called Party AESA, Called Party AESA Subaddress, Calling Party AESA or Calling Party AESA Subaddress.
切り換えられたVC接続のために、LAC MAYは、コネクション確立情報に基づいて仮想の中のDialユーザの部分的なPPP認証を許すことによって、同輩LNSを選択します。 LACが使用できるコネクション確立情報はCalledパーティAESA、CalledパーティAESA Subaddress、CallingパーティAESAまたはCallingパーティAESA Subaddressを含んでいます。
For Permanent VC connections, the LAC MAY be triggered by (a) the establishment of the PVC, (b) by an LCP configure request, (c) by partially authenticating the virtual Dial-in user, or (d) by means outside the scope of this specification.
(b) Permanent VC接続には、LAC MAYが(a) PVCの設立によって引き起こされて、LCPで、要求、仮想の中のDialユーザを部分的に認証するのによる(c)、またはこの仕様の範囲の外の手段による(d)を構成してください。
Within the ICRQ, the LAC MUST indicate a broadband bearer in the Bearer Type AVP (B bit set to 1), MAY include the Service Category AVP, and MAY include the Service Name AVP. If the LNS would not support the B Bearer bit, it will return an error on the ICRQ message. In such a case, the implementation MAY decide to fall back to digital bearer capability, and SHOULD refrain from using the extensions defined within this document. Further, the ICRQ message MAY contain the VPI/VCI identifier AVP. This identifier can further be used at the LNS for management purposes next to or alternative to the Physical Channel ID AVP.
LAC MUSTがBearer Type AVPでICRQの中では、広帯域の運搬人を示して(Bビットは1にセットしました)、Service Category AVPを含んでいて、Service Name AVPを含むかもしれません。 LNSがB Bearerビットを支えないと、それはICRQメッセージで誤りを返すでしょう。 このような場合には、実装は、デジタル運搬人能力へ後ろへ下がると決めるかもしれません、そして、SHOULDはこのドキュメントの中に定義された拡張子を使用するのを控えます。 さらに、ICRQメッセージはVPI/VCI識別子AVPを含むかもしれません。 Physical Channel ID AVPへの管理目的か代替手段にLNSでさらにこの識別子を使用できます。
Within the ICCN, both Tx Connect Speed AVP and Rx Connect Speed SHOULD be used if an asymetric connection has been established.
ICCN、Tx Connect Speed AVPとRx Connect Speed SHOULDの両方、asymetric接続が確立されたなら、使用されてください。
T'Joens, et al. Standards Track [Page 5] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[5ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
3.3.2 Outgoing Call Establishment
3.3.2 発信電話設立
Within an OCRQ, the LNS MUST indicate to the LAC minimum and maximum speeds for receive and transmit traffic (from the LAC perspective). This is to allow for the bi-directional asymmetric nature of ATM traffic contracts. Note that in order to support UBR connections between LAC and user, the Minimum BPS MUST be set to zero.
OCRQの中では、LNS MUSTはトラフィック(LAC見解からの)を受けて、伝えるように最小限と最大が疾走するLACに示します。 これは、ATMトラフィック契約の双方向の非対称の本質を考慮するためのものです。 Minimum BPSがLACとユーザとのUBR接続をサポートするためにゼロに用意ができなければならないことに注意してください。
Further during OCRQ, the LNS MAY include the required Service Category AVP, i.e., indicating real time (rt) or non-real time (nrt) transport services. The combination of minimum and maximum receive and transmit speed, and the indication of the required service category allows the LAC to establish an ATM connection according to its own capabilities, and the ATM access network capabilities, however within the service requirement for the PPP layer.
より遠くに、OCRQの間、すなわち、LNS MAYは、リアルタイム(rt)か非リアルタイム(nrt)輸送サービスを示しながら、必要なService Category AVPを含んでいます。 LACは必要なサービスカテゴリのしるしによって、最小限と最大の組み合わせは、速度を受けて、伝えて、それ自身の能力、およびATMアクセスネットワーク能力に従ってATM接続を確立して、しかしながら、PPPのためのサービス要件の中で層にされます。
Real time connectivity can be provided by either CBR or rt-VBR ATM service categories, non-real time connectivity can be provided by UBR, nrt-VBR, ABR or GFR ATM service categories.
CBRかrt-VBR ATMサービスカテゴリのどちらかでリアルタイムの接続性を提供できて、UBR、nrt-VBR、ABRまたはGFR ATMサービスカテゴリで非リアルタイムの接続性を提供できます。
Further the LNS MUST indicate to the LAC in OCRQ message the called number according to the format described in this document (NSAP format). When the called number carries an all zero payload, the LAC SHOULD look at the Service Name AVP to bind the tunnel call to an ATM VC connection.
さらに、LNS MUSTは、形式に従った呼ばれた数が本書では(NSAP形式)について説明したのをOCRQメッセージのLACに示します。 呼ばれた数がすべてのペイロードを運ぶというわけではないとき、LAC SHOULDは、ATM VC接続にトンネル呼び出しを縛るためにService Name AVPを見ます。
Next to the normal AVPs, the OCRP message MAY contain the VPI/VCI identifier AVP. This identifier can further be used at the LNS for management purposes next to or alternative to the Physical Channel ID AVP.
正常なAVPsの横で、OCRPメッセージはVPI/VCI識別子AVPを含むかもしれません。 Physical Channel ID AVPへの管理目的か代替手段にLNSでさらにこの識別子を使用できます。
3.4 Framing
3.4 縁どり
Within this document the PPP PDU refers to the concatenation of PPP protocol ID, PPP Information and PPP padding fields.
このドキュメントの中では、PPP PDUはPPPプロトコルID、PPP情報、および分野を水増しするPPPの連結について言及します。
In the direction of user to LNS, the PPP PDU will be carried on top of an AAL5 connection between user and LAC. The LAC MUST strip off the AAL5 specific fields based on the encapsulation mechanism in use on the ATM connection, i.e. VC multiplexed or LLC encapsulated [RFC2364], and MUST encapsulate the PPP PDU with address and control field, as per HDLC procedures, on the L2TP tunnel.
LNSへのユーザの向きに、PPP PDUはユーザとLACとのAAL5接続の上で運ばれるでしょう。 LAC MUSTがATM接続のときに使用中のカプセル化メカニズムに基づくAAL5の特定の分野を全部はぎ取って、すなわち、VCが多重送信したか、LLCはアドレスと制御フィールドがあるPPP PDUをカプセル化して[RFC2364]、カプセル化しなければなりません、HDLC手順に従って、L2TPトンネルの上で。
In the direction of LNS to user, the PPP PDU will be carried on top of an AAL5 connection between LAC and user. The LAC MUST strip the PPP PDU from the address and control field on the L2TP tunnel, and
ユーザへのLNSの向きに、PPP PDUはLACとユーザとのAAL5接続の上で運ばれるでしょう。 そしてLAC MUSTがL2TPトンネルの上のアドレスと制御フィールドからPPP PDUを剥取る。
T'Joens, et al. Standards Track [Page 6] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[6ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
insert the AAL5 specific fields based on the encapsulation mechanism in use on the ATM connection, i.e. VC multiplexed or LLC encapsulated.
すなわち、ATM接続のときに使用中のカプセル化メカニズムに基づく特定の分野、VCが多重送信したか、またはLLCがカプセル化したAAL5を挿入してください。
4. Service model issues
4. サービスモデル問題
4.1 Authentication
4.1 認証
In case of ATM switched VC establishment, calling party number information may be used for first level authentication much in the same way as for PSTN or ISDN access. In case of permanent VC establishment, authentication may not be an issue from the LAC side, because of the permanent character of the VC. Bilateral agreement between LAC and LNS providers may eliminate the authentication phase in the latter case.
同様に、VC設立を切り換えて、パーティーと呼ぶATMの場合には、数の情報は最初に、平らな認証にPSTNやISDNアクセサリーのようにたくさん使用されるかもしれません。 永久的なVC設立の場合には、認証はLAC側からの問題でないかもしれません、VCの永久的なキャラクタのために。 LACとLNSプロバイダーの間の二国間条約は後者の場合における認証フェーズを排除するかもしれません。
4.2 Authorization
4.2 承認
Because of the flexibility of establishing ATM connections with varying parameters, some authorization may be required prior to accepting the establishment of a switched ATM connection from the user with certain ATM traffic parameters. This authorization may be performed against the ATM specific authentication information (e.g. calling line id), or may be performed after partial authentication of the user at the PPP level. Non authorized access requests result in connection release.
異なったパラメタとのATM関係を確立する柔軟性のために、あるATMトラフィックパラメタでユーザから切り換えられたATM接続の設立を受け入れる前に、何らかの承認が必要であるかもしれません。 この承認は、ATMの特定の認証情報(例えば、系列イドと呼ぶ)に対して実行されるか、またはユーザの部分的な認証の後にPPPレベルで実行されるかもしれません。 非認可されたアクセス要求はコネクション解放をもたらします。
5. New and extended AVPs
5. 新しくて拡張しているAVPs
5.1 New AVP Summary
5.1 新しいAVP概要
The following table lists the extra AVPs that are defined within this document. The "attr" column indicates the integer value assigned to this attribute. Note that the attribute value is relative compared to the vendor ID. The "M" column indicates the setting of the "Mandatory" bit of the AVP header for each attribute. The "LEN" column indicates the size of the AVP including the AVP header. A "+" in this column indicates that the length varies depending upon the length of the actual contents of the value field.
以下のテーブルはこのドキュメントの中に定義される付加的なAVPsを記載します。 "attr"コラムはこの属性に割り当てられた整数値を示します。 ベンダーIDと比べて、属性値が相対的であることに注意してください。 「M」コラムは各属性のためにAVPヘッダーの「義務的な」ビットの設定を示します。 「レン」コラムはAVPヘッダーを含むAVPのサイズを示します。 このコラムの「+」は、値の分野の実際のコンテンツの長さによって、長さが異なるのを示します。
The usage list for each entry indicates the message types that utilize each AVP. An abbreviation shown in mixed or upper case letters indicates that the corresponding AVP MUST be present in this message type. All lower case indicates that the AVP MAY optionally appear in this message type. Some AVPs MAY be present only when a corresponding optional AVP or specific setting within the AVP is present, these AVPs are shown in lower case as well.
各エントリーのための用法リストは各AVPを利用するメッセージタイプを示します。 混合されるか大文字手紙に示された略語は、対応するAVP MUSTがこのメッセージタイプで存在しているのを示します。 すべての小文字が、AVP MAYがこのメッセージタイプで任意に現れるのを示します。 これらのAVPsはAVPの中の対応する任意のAVPか特定の設定が存在しているときだけ、いくつかのAVPsが存在しているかもしれないのがまた、小文字で示されます。
T'Joens, et al. Standards Track [Page 7] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[7ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
Attr M Len Attribute Name (usage)
レンAttributeが命名するAttr M(用法)
40 0 10 Rx Minimum BPS (ocrq)
32-bit integer indicating the lowest acceptable line speed for the
call in the receive direction. Rx indicates the user to LAC
direction.
41 0 10 Rx Maximum BPS (ocrq)
32-bit integer indicating the highest acceptable line speed for
call in the receive direction. Rx indicates the user to LAC
direction.
42 0 8 Service Category (ocrq, icrq)
The Service Category indicates the service expected for the call,
e.g., real time or non-real time.
43 0 6+ Service Name (ocrq, icrq)
The Service Name indicates the service name linked to a
preestablished PVC.
44 0 26 Calling Sub-Address(icrq)
20 octet binary encoded NSAP subaddress indicating the Calling
Party Sub-Address.
45 0 10 VPI/VCI identifier (icrq, ocrp)
10 octet binary encoded identification of VPI/VCI values used for
incoming calls.
呼び出しのために中に示す中で許容できるライン・スピード最も低い40の32 10Rx Minimum BPS(ocrq)の0ビットの整数、方向を受けてください。 RxはLAC方向にユーザを示します。 呼び出しのために中に示す中で許容できるライン・スピード最も高い41の32 10Rx Maximum BPS(ocrq)の0ビットの整数、方向を受けてください。 RxはLAC方向にユーザを示します。 42 0 8サービスCategory(ocrq、icrq)Service Categoryは要求(例えば、リアルタイムでか非リアルタイム)のために予想されたサービスを示します。 43 0 6+サービスName(ocrq、icrq)Service Nameは、サービス名がpreestablished PVCにリンクされたのを示します。 44 0 26 Sub-アドレス(icrq)を20八重奏バイナリーと呼ぶと、CallingパーティSub-アドレスを示すNSAP subaddressがコード化されました。 45 0 10 VPI/VCI識別子(icrq、ocrp)10八重奏バイナリーはかかってきた電話に使用されるVPI/VCI値の識別をコード化しました。
5.2 New AVP definition
5.2 新しいAVP定義
The following lists the new AVPs defined within this document, and describes the expected behaviour when this AVP would be present within a message.
以下は、このドキュメントの中に定義された新しいAVPsを記載して、このAVPがメッセージの中に存在しているだろうというとき、予想されたふるまいについて説明します。
Rx Minimum BPS (OCRQ)
Rxの最小のビーピーエス(OCRQ)
The Rx Minimum BPS, Attribute Type 40, encodes the lowest
acceptable line speed for this call in the receive direction,
for these cases where asymmetric transmission is required.
Rx Minimum BPS(Attribute Type40)がこの呼び出しのために中で最も低い許容できるライン・スピードをコード化する、方向を受けてください、非対称伝送が必要であるこれらのケースのために。
The Attribute Value field for this AVP has the following
format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rxの最小のビーピーエス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Rx Minimum BPS is a 32 bit value indicating the speed in
bits per second.
Rx Minimum BPSはbpsにおける速度を示す32ビットの値です。
T'Joens, et al. Standards Track [Page 8] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[8ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
This AVP MAY be included within the OCRQ, and SHOULD only be
included when the LAC indicated broadband bearer support in the
bearer capabilities AVP during tunnel establishment.
OCRQ、およびSHOULDの中で含められてください。このAVP MAY、LACがトンネル設立の間、運搬人能力AVPで広帯域の運搬人サポートを示したときには単に含められてください。
This AVP may be hidden (the H-bit may be set to 0 or 1). The
M- bit for this AVP must be set to 0. The Length (before
hiding) of this AVP is 10.
このAVPは隠されるかもしれません(H-ビットは0か1に設定されるかもしれません)。 このAVPのためのMビットを0に設定しなければなりません。 このAVPのLength(隠れることの前の)は10歳です。
Rx Maximum BPS
Rxの最大のビーピーエス
The Rx Maximum BPS, Attribute Type 41, encodes the highest
acceptable line speed for this call in the receive direction,
for these cases where asymmetric transmission is required.
Rx Maximum BPS(Attribute Type41)がこの呼び出しのために中で最も高い許容できるライン・スピードをコード化する、方向を受けてください、非対称伝送が必要であるこれらのケースのために。
The Attribute Value field for this AVP has the following
format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rxの最大のビーピーエス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Rx Maximum BPS is a 32 bit value indicating the speed in
bits per second.
Rx Maximum BPSはbpsにおける速度を示す32ビットの値です。
This AVP MAY be included within the OCRQ, and SHOULD only be
included when the LAC indicated broadband bearer support in the
bearer capabilities AVP during tunnel establishment.
OCRQ、およびSHOULDの中で含められてください。このAVP MAY、LACがトンネル設立の間、運搬人能力AVPで広帯域の運搬人サポートを示したときには単に含められてください。
This AVP may be hidden (the H-bit may be set to 0 or 1). The
M- bit for this AVP must be set to 0. The Length (before
hiding) of this AVP is 10.
このAVPは隠されるかもしれません(H-ビットは0か1に設定されるかもしれません)。 このAVPのためのMビットを0に設定しなければなりません。 このAVPのLength(隠れることの前の)は10歳です。
Service Category
サービスカテゴリ
The Service Category AVP, Attribute type 42, indicates optional
extra information on the Quality of Service expected for the
call establishment on the broadband bearer medium.
Service Category AVP(Attributeタイプ42)は広帯域の運搬人媒体における呼び出し設立のために予想されたServiceのQualityの任意のその他の情報を示します。
The Attribute Value field for this AVP has the following
format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future QoS ind. |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 将来のQoS indのためのResvd。 |S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T'Joens, et al. Standards Track [Page 9] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[9ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
The Attribute Value field is a 16-bit mask, with one bit
defined. The S bit indicates either non real time (S bit set
to 0) or real time (S bit set to 1) service requirement. The
other bit fields are reserved for future use.
Attribute Value分野は1ビットが定義されている16ビットのマスクです。 Sビットは非リアルタイム(Sビットは0にセットした)かリアルタイム(1に設定されたSビット)のサービス要件のどちらかを示します。 他の噛み付いている分野は今後の使用のために予約されます。
The Service Category AVP MAY be present in OCRQ and ICRQ
messages, and SHOULD only be included when the LAC indicated
broadband bearer support in the bearer capabilities AVP during
tunnel establishment.
LACがトンネル設立の間運搬人能力AVPで広帯域の運搬人サポートを示したとき、含まれていて、OCRQでのプレゼント、ICRQメッセージ、およびSHOULDが唯一であったなら、Service Category AVPはそうするかもしれません。
This AVP may be hidden (the H-bit may be set to 0 or 1). The
M- bit for this AVP must be set to 0. The Length (before
hiding) of this AVP is 8.
このAVPは隠されるかもしれません(H-ビットは0か1に設定されるかもしれません)。 このAVPのためのMビットを0に設定しなければなりません。 このAVPのLength(隠れることの前の)は8歳です。
Service Name
サービス名
The Service Name AVP, Attribute Type 43, provides the peer with
an textual name for referring to an ATM VC connection.
Service Name AVP(Attribute Type43)は、ATM VC接続について言及するために原文の名前を同輩に提供します。
The Attribute Value field for this AVP has the following
format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name (arbitrary number of octets) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name(八重奏の特殊活字の数字)を調整してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Service Name is of arbitrary length, but must be at least 1
octet. The Service Name is UTF-8 encoded. [10646]
Service Nameは任意の長さがありますが、少なくとも1つの八重奏であるに違いありません。 Service Nameはコード化されたUTF-8です。 [10646]
The Service Name should be unique at least to the LNS/LAC
combination.
Service Nameは少なくともLNS/LAC組み合わせるのにユニークであるべきです。
The Service Name AVP MAY only be provided when the Called
Number field is encoded as all zeros in OCRQ. The Service Name
AVP MAY be present in OCRQ and ICRQ messages, and SHOULD only
be included when the LAC indicated broadband bearer support in
the bearer capabilities AVP during tunnel establishment.
OCRQのすべてのゼロとしてCalled Number分野をコード化するときだけ、Service Name AVPを提供するかもしれません。 LACがトンネル設立の間運搬人能力AVPで広帯域の運搬人サポートを示したとき、含まれていて、OCRQでのプレゼント、ICRQメッセージ、およびSHOULDが唯一であったなら、Service Name AVPはそうするかもしれません。
This AVP may be hidden (the H-bit may be set to 0 or 1). The
M- bit for this AVP must be set to 0. The length of this
attribute is arbitrary, however at least 7.
このAVPは隠されるかもしれません(H-ビットは0か1に設定されるかもしれません)。 このAVPのためのMビットを0に設定しなければなりません。 しかしながら、この属性の長さは少なくとも7に任意です。
Calling Sub-Address (ICRQ)
サブアドレスと呼びます。(ICRQ)
The Calling Sub-Address AVP, Attribute Type 44, encodes
additional Calling Party subaddress information.
Calling Sub-アドレスAVP(Attribute Type44)は追加Callingパーティ「副-アドレス」情報をコード化します。
T'Joens, et al. Standards Track [Page 10] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[10ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
The Attribute Value field for this AVP has the following
format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Calling Sub-Address AVP MUST be encoded as a 20 octet
binary encoded NSAP address when the B bit is set in the Bearer
Type AVP. The NSAP binary encoded address provides a broader
range of address encapsulation methods than an ASCII field.
The structure of the NSAP address (e.g., E.164, ICD, DCC) is
defined in [AESA].
AVP MUSTをCalling Sub扱ってください。20八重奏バイナリーがBビットがBearer Type AVPに設定されるNSAPアドレスをコード化したので、コード化されてください。 NSAP2進のコード化されたアドレスはASCII分野より広い範囲のアドレスカプセル化メソッドを提供します。 NSAPアドレス(例えば、E.164、ICD、DCC)の構造は[AESA]で定義されます。
The Calling Sub-Address number AVP MAY be present in ICRQ, and
SHOULD only be available if the Calling Party number is also
within the message.
ICRQでのプレゼント、およびSHOULDが唯一であったなら、Calling Sub-アドレスはAVP MAYに付番します。メッセージの中にもCallingパーティ番号があるなら、利用可能であってください。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
for this AVP MUST be set to 0. The Length (before hiding) of
this AVP is 26.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は26歳です。
VPI/VCI identifier(icrq, ocrp)
VPI/VCI識別子(icrq、ocrp)
The VPI/VCI identifier, Attribute Type 45, encodes the VPI/VCI
value used at the ATM interface at the LAC.
VPI/VCI識別子(Attribute Type45)は値がLACでATMインタフェースで使用したVPI/VCIをコード化します。
The Attribute Value field for this AVP has the following
format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|resvd | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |resvd| VPI| VCI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VPI/VCI identifier is a 32 bit value encoding the VPI(12
bits) and VCI (16 bits) value.
VPI/VCI識別子はVPI(12ビット)とVCI(16ビット)値をコード化する32ビットの値です。
T'Joens, et al. Standards Track [Page 11] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[11ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
This AVP MAY be included within the ICRQ and OCRP, and SHOULD
only be included when the LAC indicated broadband bearer
support in the bearer capabilities AVP during tunnel
establishment.
ICRQ、OCRP、およびSHOULDの中で含められてください。このAVP MAY、LACがトンネル設立の間、運搬人能力AVPで広帯域の運搬人サポートを示したときには単に含められてください。
This AVP may be hidden (the H-bit may be set to 0 or 1). The
M- bit for this AVP must be set to 0. The Length (before
hiding) of this AVP is 10.
このAVPは隠されるかもしれません(H-ビットは0か1に設定されるかもしれません)。 このAVPのためのMビットを0に設定しなければなりません。 このAVPのLength(隠れることの前の)は10歳です。
5.3 Changed AVP Definition
5.3 変えられたAVP定義
The following AVPs see their contents changed relative to [RFC2661] in order to support the procedures described in this document.
以下のAVPsは、彼らのコンテンツが本書では説明された手順をサポートするために[RFC2661]に比例して変えられるのを見ます。
Bearer Capabilities
運搬人能力
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future bearer capability definitions |B|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 今後の運搬人能力定義のためのResvd|B|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bearer Capabilities AVP within a SCCRQ or SCCRP indicates
the bearer capabilities that the sender of this message can
provide for outgoing calls. This document extends the existing
AVP with the B bit. If bit B is set, broadband access is
supported (ATM).
SCCRQかSCCRPの中の運搬人Capabilities AVPはこのメッセージの送付者が発信電話に提供できる運搬人能力を示します。 このドキュメントはBビットで既存のAVPを広げています。 ビットBが設定されるなら、広帯域アクセスは(ATM)であるとサポートされます。
Attempts to establish an outgoing call with the bearer type set
to B, while the bearer capability did not indicate this
capability will result in the call being rejected with Result
Code 5 'Call failed due to lack of appropriate facilities being
available (permanent condition)'.
運搬人能力が、この能力がResult Code5と共に拒絶される呼び出しをもたらすのを示していなかった間にタイプがBに設定する運搬人と共に発信電話を確立する試みは'利用可能な適切な施設(永久的な状態)の不足に失敗した支払われるべきものと呼びます'。
In these cases where the LAC only supports the B bit, and the
LNS would not recognize the B bit, no outgoing calls are
possible. Note that when the LAC only has ATM based devices,
it may still opt for seamless fall back to digital bearer
types.
LACがBビットを支えるだけであり、LNSがBビットを認識しないこれらの場合では、どんな発信電話も可能ではありません。 LACにATMのベースのデバイスがあるだけであるとき、それがまだデジタル運搬人タイプへのシームレスの落下に備えて選ばれているかもしれないことに注意してください。
This specification assumes a non-compliant LNS to categorize a
Bearer Capabilities AVP where the B bit is set as unrecognized
AVP, upon which the tunnel establishment will fail. This is to
be indicated by a Result Code '2-General error - Error Code
indicates the problem', Error Code '3- Reserved field was non-
zero'.
この仕様は、不従順なLNSがBビットがトンネル設立が行き詰まる認識されていないAVPとして設定されるBearer Capabilities AVPを分類すると仮定します。 これは'2一般のResult Code誤りで示されることになっています--誤りCodeは、'Error Codeの'3の予約された分野は非ゼロであったこと'を問題であり示します。
T'Joens, et al. Standards Track [Page 12] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[12ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
(Tx) Minimum BPS
(Tx)最小のビーピーエス
The (Tx) Minimum BPS AVP encodes the lowest acceptable line
speed for this call in the transmit direction. The (Tx)
Minimum BPS AVP MAY be used in OCRQ. If the Rx Minimum BPS
AVP, as defined within this document, is not available in the
message, then symmetric transmission is implied, with both
minimum receive and transmit bit-rates equal to Minimum BPS.
(Tx)最小のBPS AVPがこの呼び出しのために中で最も低い許容できるライン・スピードをコード化する、方向を伝えてください。 (Tx)最小のBPS AVP MAY、OCRQで使用されてください。 このドキュメントの中に定義されるRx Minimum BPS AVPがメッセージで利用可能でないなら左右対称のトランスミッションが含意されて、両方で、最小限は、Minimum BPSと等しいビット伝送速度を受けて、伝えます。
(Tx) Maximum BPS
(Tx)最大のビーピーエス
(Tx) Maximum BPS AVP encodes the highest acceptable line speed
for this call in the transmit direction. The (Tx) Maximum BPS
AVP MAY be used in OCRQ. If the Rx Maximum BPS AVP, as defined
within this document, is not available in the message, then
symmetric transmission is implied, with both maximum receive
and transmit bitrates equal to Maximum BPS.
(Tx)最大のBPS AVPがこの呼び出しのために中で最も高い許容できるライン・スピードをコード化する、方向を伝えてください。 (Tx)最大のBPS AVP MAY、OCRQで使用されてください。 このドキュメントの中に定義されるRx Maximum BPS AVPがメッセージで利用可能でないなら左右対称のトランスミッションが含意されて、両方で、最大は、Maximum BPSと等しいbitratesを受けて、伝えます。
Bearer Type
運搬人タイプ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resvd for future bearer types definitions |B|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 将来の運搬人のためのResvdは定義をタイプします。|B|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bearer type AVP encodes the bearer type for the requested
call. This document extends the bearer types with an
indication of ATM bearer support (B-bit). If bit B is set,
broadband access is requested (ATM). If bit A is set, analogue
access is requested. If bit D is set, Digital access is
requested.
運搬人タイプAVPは要求された呼び出しのための運搬人タイプをコード化します。 このドキュメントはATM運搬人サポート(Bで噛み付いている)のしるしで運搬人タイプを広げています。 ビットBが設定されるなら、広帯域アクセスは要求されます(ATM)。 ビットAが設定されるなら、アナログアクセスは要求されます。 ビットDが設定されるなら、Digitalアクセスは要求されます。
Note that in the OCRQ all 3 bits (B,A,D) may be set indicating
that the call may be of either type. The B bit SHOULD only be
set if the Broadband capability was indicated during tunnel
establishment.
OCRQでは、すべての3ビット(B、A、D)がタイプには呼び出しがあるかもしれないのを示すように設定されるかもしれないことに注意してください。 BはSHOULDに噛み付きました。Broadband能力がトンネル設立の間、示された場合にだけ、用意ができています。
Q.931 Cause Code
Q.931原因コード
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コード| 原因エムエスジー| 顧問エムエスジー… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T'Joens, et al. Standards Track [Page 13] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[13ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
The Cause code is not changed from [RFC2661], except for the
fact that it can also carry Cause Codes specific to ATM
signalling messages, these cause codes can be found in ATM
Causeコードは[RFC2661]から変えられません、また、ATM合図メッセージに特定のCause Codesを運ぶことができるという事実を除いてATMでこれらの原因コードは見つけることができます。
Forum UNI 4.0 [UNI] and the references thereof. The Cause code
should be interpreted relative to the Bearer Type in use for
the specific call.
4.0[UNI]のフォーラムUNIとそれの参照。 Causeコードは特定の呼び出しに、使用中のBearer Typeに比例して解釈されるべきです。
Called Number
数と呼ばれます。
The Called Number AVP, Attribute Type 21, encodes the AESA
number to be called for an OCRQ, and the Called number at the
LAC for an ICRQ.
Called Number AVP(Attribute Type21)はICRQのためにLACでOCRQのために電話をされるAESA番号、およびCalled番号をコード化します。
The Attribute Value field for this AVP has a changed encoding
from [RFC2661]:
このAVPのためのAttribute Value分野には、[RFC2661]からの変えられたコード化があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Called Number AVP MUST be encoded as a 20 octet binary
encoded NSAP address when the B bit is set in the Bearer Type
AVP. The NSAP binary encoded address provides a broader range
of address encapsulation methods than an ASCII field. The
structure of the NSAP address (e.g., E.164, ICD, DCC) is
defined in [AESA].
BビットがBearer Type AVPに設定されるとき、八重奏の20のバイナリーのコード化されたNSAPアドレスとしてCalled Number AVPをコード化しなければなりません。 NSAP2進のコード化されたアドレスはASCII分野より広い範囲のアドレスカプセル化メソッドを提供します。 NSAPアドレス(例えば、E.164、ICD、DCC)の構造は[AESA]で定義されます。
The Called number AVP MUST be present in OCRQ, and MAY be
present in ICRQ.
Called番号AVP MUSTはOCRQに存在していて、ICRQに存在しているかもしれません。
If the Called Number AVP in an OCRQ carries an all zero NSAP
address, the Service Name AVP SHOULD provide further
information to bind the L2TP call to a specific VC connection.
See also [Auto_PVC].
OCRQのCalled Number AVPがNSAPが扱うすべてのゼロを運ぶなら、Service Name AVP SHOULDは、特定のVC接続にL2TP呼び出しを縛るために詳細を提供します。 また、[自動車_PVC]を見てください。
T'Joens, et al. Standards Track [Page 14] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[14ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
for this AVP MUST be set to 0. The Length (before hiding) of
this AVP is 26.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は26歳です。
Calling Number
数と呼びます。
The Calling Number AVP, Attribute Type 22, encodes the Calling
Party AESA as received from the Virtual Dial-in User.
Calling Number AVP(Attribute Type22)は中のVirtual Dial Userから受け取るようにCallingパーティAESAをコード化します。
The Attribute Value field for this AVP has a changed encoding
from [RFC2661]:
このAVPのためのAttribute Value分野には、[RFC2661]からの変えられたコード化があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Calling Number AVP MUST be encoded as a 20 octet binary
encoded NSAP address when the B bit is set in the Bearer Type
AVP. The NSAP binary encoded address provides a broader range
of address encapsulation methods than an ASCII field. The
structure of the NSAP address (e.g., E.164, ICD, DCC) is
defined in [AESA].
BビットがBearer Type AVPに設定されるとき、八重奏の20のバイナリーのコード化されたNSAPアドレスとしてCalling Number AVPをコード化しなければなりません。 NSAP2進のコード化されたアドレスはASCII分野より広い範囲のアドレスカプセル化メソッドを提供します。 NSAPアドレス(例えば、E.164、ICD、DCC)の構造は[AESA]で定義されます。
The Calling number AVP MAY be present in ICRQ.
Callingは現在のコネがICRQであったならAVP MAYに付番します。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
for this AVP MUST be set to 0. The Length (before hiding) of
this AVP is 26.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は26歳です。
Sub-Address
サブアドレス
The Sub-Address AVP, Attribute Type 23, encodes additional
Called Party subaddress information.
Sub-アドレスAVP(Attribute Type23)は追加Calledパーティ「副-アドレス」情報をコード化します。
The Attribute Value field for this AVP has a changed encoding
from [RFC2661]:
このAVPのためのAttribute Value分野には、[RFC2661]からの変えられたコード化があります:
T'Joens, et al. Standards Track [Page 15] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[15ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSAP (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSAP(contはそうするでしょう)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Address AVP MUST be encoded as a 20 octet binary
encoded NSAP address when the B bit is set in the Bearer Type
AVP. The NSAP binary encoded address provides a broader range
of address encapsulation methods than an ASCII field. The
structure of the NSAP address (e.g., E.164, ICD, DCC) is
defined in [AESA].
AVP MUSTをSub扱ってください。20八重奏バイナリーがBビットがBearer Type AVPに設定されるNSAPアドレスをコード化したので、コード化されてください。 NSAP2進のコード化されたアドレスはASCII分野より広い範囲のアドレスカプセル化メソッドを提供します。 NSAPアドレス(例えば、E.164、ICD、DCC)の構造は[AESA]で定義されます。
The Sub-Address number AVP MAY be present in ICRQ and OCRQ, and
SHOULD only be available if the Called Party number is also
within the message.
ICRQでのプレゼント、OCRQ、およびSHOULDが唯一であったなら、Sub-アドレスはAVP MAYに付番します。メッセージの中にもCalledパーティ番号があるなら、利用可能であってください。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit
for this AVP MUST be set to 0. The Length (before hiding) of
this AVP is 26.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は26歳です。
6. IANA Considerations
6. IANA問題
This document requires IANA to allocate 6 new type values for the following AVPs (see section 5.2) :
このドキュメントは、IANAが以下のAVPsのために6つの新しいタイプ値を割り当てるのを必要とします(セクション5.2を見てください):
- Rx Minimum BPS
- Rxの最小のビーピーエス
- Rx Maximum BPS
- Rxの最大のビーピーエス
- Service Category
- サービスカテゴリ
- Service Name
- サービス名
- Calling Sub-Address
- サブアドレスと呼びます。
- VPI/VCI Identifier
- VPI/VCI識別子
This document further defines a new bit (B) in the bearer capabilities and bearer type AVPs (section 5.3).
このドキュメントは運搬人能力と運搬人タイプAVPs(セクション5.3)で新しいビット(B)をさらに定義します。
T'Joens, et al. Standards Track [Page 16] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[16ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
This document defines a flag field in the Service Category AVP, only one bit in this flag has been assigned within this document (S). Further assignments fall under the rule of "Specification Required", i.e. Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
このドキュメントはService Category AVPの旗の分野を定義して、このドキュメント(S)の中にこの旗による1ビットだけを割り当ててあります。 課題は「仕様が必要であること」の規則の下で下がります、すなわち、RFCか他の永久的で容易に利用可能な参照にValuesと彼らの意味を記録しなければなりません、詳細に十分なさらに、独立している実装の間の相互運用性は可能です。
7. Security Considerations
7. セキュリティ問題
No extra security risk outside these specified by [RFC2661] are foreseen.
これらの外のリスクが指定したどんな付加的なセキュリティも[RFC2661]によって見通されません。
8. Acknowledgements
8. 承認
The authors would like to thank Laurent Hermans for his work on earlier versions of this document, Juha Heinanen (Telia) and David Allen (Nortel Networks) for their constructive discussion on the document during the Minneapolis IETF meeting, Mark Townsley (cisco) for his hint on the use of the VPI/VCI identifier AVP.
作者はドキュメントの彼らの建設的な討議のためにミネアポリスのIETFミーティング(VPI/VCI識別子AVPの使用の彼のヒントのためのマークTownsley(コクチマス))の間、このドキュメント、ユハHeinanen(冬胞子堆)、およびデビッド・アレン(ノーテルNetworks)の以前のバージョンに対する彼の仕事についてローランHermansに感謝したがっています。
9. References
9. 参照
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G.,
Zorn, G. and B. Palter, "Layer Two Tunnelling Protocol
(L2TP)", RFC 2661, August 1999.
[RFC2661]Townsley、W.、バレンシア、A.、ルーベン、A.、シンPall、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル(L2TP)にトンネルを堀っ」て、RFC2661、1999年8月。
[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月。
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A. and J.
Stephens, "PPP over AAL5", RFC 2364, July 1998.
[RFC2364] グロスとG.とKayceeとM.とリンとA.とMalisとA.とJ.スティーブンズ、「AAL5"、RFC2364、1998年7月の間のppp。」
[UNI] User-Network Interface (UNI) Specification, Version 4.0,
ATM Forum, July, 1996
[UNI]ユーザネットワーク・インターフェース(UNI)仕様、バージョン4.0、気圧フォーラム、1996年7月
[AESA] ATM Forum Addressing : Reference Guide, version 1.0, ATM
Forum, Final Ballot, January 1999
[AESA]気圧フォーラムアドレシング: 参照ガイド、バージョン1.0、ATM Forum、Final Ballot、1999年1月
[L2TP_link] Townsley, M. and W. Palter, "L2TP Link Extensions", Work
in Progress.
[L2TP_リンク]Townsley、M.、およびW.はあしらわれて、「L2TPリンク拡張子」は進行中で働いています。
[Auto_PVC] ATM Forum, "Auto-configuration of PVCs", af-nm-0122.000,
March 1999
[自動車_PVC]ATM Forum、「PVCsの自動構成」、af nm0122.000、1999年3月
[10646] ISO/IEC, Information Technology - Universal Multiple-
Octet Coded Character Set (UCS) - Part 1: Architecture
and Basic Multilingual Plane, May 1993, with amendments
[10646] ISO/IEC、情報技術--普遍的な複数の八重奏コード化文字集合(UCS)--第1部: 修正があるアーキテクチャと基本多言語水準、1993年5月
T'Joens, et al. Standards Track [Page 17] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[17ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
10. Authors Addresses
10. アドレスを書きます。
Yves T'joens Alcatel Network Strategy Group Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 7890 EMail : yves.tjoens@alcatel.be
イヴT'joensアルカテルネットワーク戦略グループフランシスWellesplein1、アントワープ(ベルギー)が電話をする2018: +32 3 240 7890はメールされます: yves.tjoens@alcatel.be
Paolo Crivellari Belgacom bd du Roi Albert II 27 B-1030 Bruxelles Phone: +32 2 202 9698 EMail: paolo.crivellari@belgacom.be
パオロCrivellari Belgacom bd du RoiアルバートII27B-1030ブリュッセル電話: +32 2 202 9698はメールされます: paolo.crivellari@belgacom.be
Bernard Sales Alcatel Network Strategy Group Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 9574 EMail : bernard.sales@alcatel.be
バーナード販売アルカテルネットワーク戦略はフランシスWellesplein1、アントワープ(ベルギー)が電話をする2018を分類します: +32 3 240 9574はメールされます: bernard.sales@alcatel.be
T'Joens, et al. Standards Track [Page 18] RFC 3301 L2TP: ATM access network extensions June 2002
T'Joens、他 規格はRFC3301L2TPを追跡します[18ページ]: ATMは2002年6月にネットワーク拡大にアクセスします。
11. Full Copyright Statement
11. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
T'Joens, et al. Standards Track [Page 19]
T'Joens、他 標準化過程[19ページ]
一覧
スポンサーリンク
