RFC2364 日本語訳
2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT=23539 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Gross
Request for Comments: 2364 Lucent Technologies
Category: Standards Track M. Kaycee
Paradyne
A. Lin
Shasta Networks
A. Malis
Ascend Communications
J. Stephens
Cayman Systems
July 1998
コメントを求めるワーキンググループのG.の総計の要求をネットワークでつないでください: 2364年のルーセントテクノロジーズカテゴリ: 標準化過程M.Kaycee Paradyne A.リンシャスタネットワークA.MalisはコミュニケーションJ.スティーブンズケイマンシステム1998年7月に昇ります。
PPP Over AAL5
AAL5の上のppp
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets.
縁どりPPPがパケットをカプセルに入れったので、このドキュメントはATM Adaptation Layer5(AAL5)の使用について説明します。
Applicability
適用性
This specification is intended for those implementations which desire to use the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and compression. These capabilities require a point-to-point relationship between the peers, and are not designed for the multi- point relationships which are available in ATM and other multi-access environments.
この仕様はPPPのために定義される施設を使用するそれの願望がLink ControlプロトコルなどのようにControlプロトコル、認証をNetwork層にするそれらの実現と圧縮のために意図します。 これらの能力は、同輩の間の二地点間関係を必要として、ATMと他のマルチアクセス環境で利用可能なマルチポイント関係のために設計されていません。
Gross, et. al. Standards Track [Page 1] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[1ページ]RFC2364ppp
1. Introduction
1. 序論
ATM AAL5 protocol is designed to provide virtual connections between end stations attached to the same network. These connections offer a packet delivery service that includes error detection, but does not do error correction.
ATM AAL5プロトコルは、同じネットワークに付けられた端のステーションの間の仮想接続を提供するように設計されています。 これらの接続は誤り検出を含んでいますが、エラー修正をしないパケットデリバリ・サービスを提供します。
Most existing implementations of PPP use ISO 3309 HDLC as a basis for their framing [3].
PPPのほとんどの既存の実現が彼らの縁ど[3]りの基礎としてISO3309HDLCを使用します。
When an ATM network is configured with point-to-point connections, PPP can use AAL5 as a framing mechanism.
ATMネットワークが二地点間接続に構成されるとき、PPPは縁どりメカニズムとしてAAL5を使用できます。
2. Conventions
2. コンベンション
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [10].
キーワードが解釈しなければならない、本書では現れるとき、[10]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
3. AAL5 Layer Service Interface
3. AAL5層のサービスインタフェース
The PPP layer treats the underlying ATM AAL5 layer service as a bit- synchronous point-to-point link. In this context, the PPP link corresponds to an ATM AAL5 virtual connection. The virtual connection 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). In addition, the PPP/AAL5 service interface boundary MUST meet the following requirements:
PPP層は基本的なATM AAL5層のサービスを少し同期のポイントツーポイント接続として扱います。 このような関係においては、PPPリンクはATM AAL5仮想接続に文通されます。 仮想接続が全二重、ポイント・ツー・ポイントでなければならなく、それは、捧げられるか(すなわち、永久的であることで、食糧を供給することによって、セットアップしてください)、または切り換えられるかもしれません(要求に応じてセットアップしてください)。 さらに、PPP/AAL5サービスインタフェース境界は以下の必要条件を満たさなければなりません:
Interface Format - The PPP/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--PPP/AAL5層の境界は八重奏サービスインタフェースをAAL5層に提示します。 サブ八重奏を供給するか、または受け入れるために、支給は全くありません。
Transmission Rate - The PPP layer does not impose any
restrictions regarding transmission rate or the underlying ATM
layer traffic descriptor parameters.
トランスミッションRate--PPP層は通信速度に関するどんな制限か基本的なATM層の交通記述子パラメタも課しません。
Control Signals - The AAL5 layer MUST provide control signals to
the PPP layer which indicate when the virtual connection link
has become connected or disconnected. These provide the "Up"
and
コントロールSignals--AAL5層はPPP層への仮想接続リンクがいつ接続されるようになるか、または連絡を断ったかを示す制御信号を提供しなければなりません。 そしてこれらが“Up"を提供する。
"Down" events to the LCP state machine [1] within the PPP layer.
LCP状態への"Down"出来事はPPP層の中で[1]を機械加工します。
Gross, et. al. Standards Track [Page 2] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[2ページ]RFC2364ppp
4. Multi-Protocol Encapsulation
4. マルチプロトコルカプセル化
This specification uses the principles, terminology, and frame structure described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [4].
この仕様は「気圧適合層の5インチ[4]の上のMultiprotocolカプセル化」で説明された原則、用語、および枠組構造を使用します。
The purpose of this specification is not to document what is already standardized in [4], but to specify how the mechanisms described in [4] are to be used to map PPP onto an AAL5-based ATM network. Section 1 within [4] defines the two mechanisms for identifying the Protocol Data Unit (PDU) payload field's protocol type: virtual circuit based multiplexing, and Logical Link Control (LLC) encapsulation. In the former technique, the payload's protocol type is implicitly agreed to by the end points for each virtual circuit using provisioning or control plane procedures. When using the LLC encapsulation technique, the payload's protocol type is explicitly identified on a per PDU basis by an in-band LLC header, followed by the payload data.
この仕様の目的は[4]で既に標準化されることを記録するのではなく、AAL5を拠点とするATMネットワークにPPPを写像するのに使用される[4]で説明されたメカニズムがことである方法を指定することです。 [4]の中のセクション1はプロトコルData Unit(PDU)ペイロードフィールドのプロトコルタイプを特定するために2つのメカニズムを定義します: 仮想のサーキットはマルチプレクシング、およびLogical Link Control(LLC)カプセル化を基礎づけました。 前のテクニックでは、食糧を供給するかコントロール飛行機手順を用いることでペイロードのプロトコルタイプはエンドポイントによってそれとなくそれぞれの仮想のサーキットに同意されます。 LLCカプセル化技術を使用するとき、ペイロードのプロトコルタイプはPDU基礎あたりのaでバンドにおけるペイロードデータがあとに続いたLLCヘッダーによって明らかに特定されます。
When transporting a PPP payload over AAL5, an implementation:
AAL5、実現の上でPPPペイロードを輸送するとき:
1. MUST support virtual circuit multiplexed PPP payloads as
described in section 5 below by mutual configuration or
negotiation of both end points. This technique is referred to
as "VC-multiplexed PPP".
1. 両端点の互いの構成か交渉によって下のセクション5で説明されるように仮想のサーキット多重送信されたPPPペイロードを支えなければなりません。 このテクニックは「VCによって多重送信されたppp」と呼ばれます。
2. MUST support LLC encapsulated PPP payloads on PVCs as
described in section 6 below by mutual configuration or
negotiation of both end points. This technique is referred to
as "LLC encapsulated PPP".
2. LLCが両方の互いの構成か交渉でセクション6で説明されるPVCsのPPPペイロードを要約したサポートはポイントを終わらせなければなりませんか? このテクニックは「LLCはPPPを要約した」と呼ばれます。
3. For SVC set up, an implementation MUST negotiate using the
Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
Interface (B-LLI) information element to signal either VC-
multiplexed PPP or LLC encapsulated PPP. The details of this
control plane procedure are described in section 7.
3. Q.2931[9]別館C手順を用いて、実現が交渉されなければならない、セットアップされたSVCに関しては、VCに合図するためにBroadband Lower Layer Interface(B-LLI)情報要素をコード化すると、PPPが多重送信されたか、またはさもなければ、LLCはPPPを要約しました。 このコントロール飛行機手順の詳細はセクション7で説明されます。
If an implementation is connecting through a Frame Relay/ATM FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, then it MUST use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8 inter-working units are exempted from the requirement to support VC- multiplexed PPP. This exemption allows the FR/ATM IWU to remain compliant with FRF.8 when the PPP over AAL5 end point is inter- operating with an RFC 1973 end point.
実現がユニットを織り込むFrame Relay/ATM FRF.8[7]サービスで接続することであるなら、RFC1973[6]エンドポイント、それが使用しなければならないその時まで、LLCはPPPペイロードを要約しました。 フレームRelay/ATM FRF.8織り込むユニットはVCの多重送信されたPPPを支持するという要件から免除されています。 AAL5エンドポイントの上のPPPが1973年のRFCエンドポイントがある相互操作であるときに、この控除で、FR/ATM IWUはFRF.8と共に言いなりになったままで残ることができます。
Gross, et. al. Standards Track [Page 3] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[3ページ]RFC2364ppp
5. Virtual Circuit Multiplexed PPP Over AAL5
5. 仮想のサーキットはAAL5の上にpppを多重送信しました。
The AAL5 PDU format is shown in figure 1:
書式が示されるAAL5 PDUは1について計算します:
AAL5 CPCS-PDU Format
+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) | ^
+-------------------------------+ |
| CPI (1 octet ) | |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) | |
+-------------------------------| |
| CRC (4 octets) | V
+-------------------------------+ -------
Figure 1
AAL5 CPCS-PDU形式+-------------------------------+ | . | | . | | CPCS-PDU有効搭載量| | 最大2^16--1八重奏) | | . | +-------------------------------+ | PAD(0--47の八重奏) | +-------------------------------+ ------- | CPCS-UU(1つの八重奏) | ^ +-------------------------------+ | | CPI(1つの八重奏) | | +-------------------------------+ CPCS-PDUトレーラ| 長さ(2つの八重奏) | | +-------------------------------| | | CRC(4つの八重奏) | +に対して-------------------------------+ ------- 図1
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 described in this memo and can 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ビットのアライメント機能だけが使用されているとき、この分野は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 is used for the abort function.
Length分野は有効搭載量分野の八重奏における長さを示します。 Length分野への最大値は65535の八重奏です。 0×00としてコード化されたLength分野は放棄機能に使用されます。
The CRC field protects the entire CPCS-PDU except the CRC field itself.
CRC分野自体を除いて、CRC分野は全体のCPCS-PDUを保護します。
Gross, et. al. Standards Track [Page 4] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[4ページ]RFC2364ppp
A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and is defined as:
VCによって多重送信されたPPPフレームSHALLはCPCS-PDUペイロードを構成して、以下と定義されます。
+-------------+-------------+---------+
| Protocol ID | Information | Padding |
| 8/16 bits | | |
+-------------+-------------+---------+
Figure 2
+-------------+-------------+---------+ | プロトコルID| 情報| 詰め物| | 8/16ビット| | | +-------------+-------------+---------+ 図2
Each of these fields are specifically defined in [1].
それぞれのこれらの分野は[1]で明確に定義されます。
6. LLC Encapsulated PPP Over AAL5
6. LLCはAAL5の上にpppを要約しました。
LLC encapsulated PPP over AAL5 is the alternative technique to VC- multiplexed PPP over AAL5.
LLCはPPPを要約しました。AAL5の上に、AAL5の上のVCの多重送信されたPPPへの代替手段のテクニックがあります。
The AAL5 CPCS-PDU payload field is encoded as shown in figure 3. The pertinent fields in that diagram are:
3が中で計算するのが示されるようにAAL5 CPCS-PDUペイロード分野はコード化されます。 そのダイヤグラムの適切な分野は以下の通りです。
1. LLC header: 2 bytes encoded to specify a source SAP and
destination SAP of routed OSI PDU (values 0xFE 0xFE), followed
by an Un-numbered Information (UI) frame type (value 0x03).
1. LLCヘッダー: ソースSAPとUn番号付の情報(UI)フレームタイプ(値0x03)によって後をつけられた発送されたOSI PDU(0xFE 0xFEを評価する)の目的地SAPを指定するためにコード化された2バイト。
2. Network Layer Protocol IDentifier (NLPID) representing PPP,
(value 0xCF).
2. PPP、(値の0xCF)を表して、LayerプロトコルIDentifier(NLPID)をネットワークでつないでください。
3. the PPP protocol identifier field, which can be either 1 or 2
octets long. See reference [1].
3. PPPは識別子分野について議定書の中で述べます。(長い間、それは、1か2つの八重奏であるかもしれません)。 参照[1]を見てください。
4. followed by the PPP information field as per Figure 2.
4. PPP情報フィールドは図2に従ってあとに続きます。
Gross, et. al. Standards Track [Page 5] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[5ページ]RFC2364ppp
+-------------------------+ --------
| Destination SAP (0xFE) | ^
+-------------------------+ |
| Source SAP (0xFE) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| NLPID = PPP (0xCF) |
+-------------------------+ --------
| Protocol Identifier | ^
| (8 or 16 bits) | |
+-------------------------+ PPP payload
| . | |
| . | |
| PPP information field | |
| . | |
| . | |
+-------------------------+ |
| padding | V
+-------------------------+ --------
| PAD ( 0 - 47 octets) |
+-------------------------+ --------
| CPCS-UU (1 octet ) | ^
+-------------------------+ |
| CPI (1 octet ) | |
+-------------------------+CPCS-PDU Trailer
| Length (2 octets) | |
+-------------------------| |
| CRC (4 octets) | V
+-------------------------+ --------
+-------------------------+ -------- | 目的地体液(0xFE)| ^ +-------------------------+ | | ソースSAP(0xFE)| LLCヘッダー+-------------------------+ | | フレームタイプはUI(0×03)と等しいです。| +に対して-------------------------+ -------- | NLPIDはppp(0xCF)と等しいです。| +-------------------------+ -------- | プロトコル識別子| ^ | (8ビットか16ビット) | | +-------------------------+ PPPペイロード| . | | | . | | | PPP情報フィールド| | | . | | | . | | +-------------------------+ | | 詰め物| +に対して-------------------------+ -------- | PAD(0--47の八重奏)| +-------------------------+ -------- | CPCS-UU(1つの八重奏)| ^ +-------------------------+ | | CPI(1つの八重奏)| | +-------------------------+ CPCS-PDUトレーラ| 長さ(2つの八重奏)| | +-------------------------| | | CRC(4つの八重奏)| +に対して-------------------------+ --------
Figure 3
図3
The end points MAY be bi-laterally provisioned to send other LLC- encapsulated protocols besides PPP across the same virtual connection. However, they MUST NOT send packets belonging to any protocol that has an active NCP within the PPP session. Implementations SHOULD do packet scheduling that minimizes the performance impact on the quality of service commitments associated with both the LLC-encapsulated PPP and non-PPP protocol flows.
エンドポイントは、同じ仮想接続の向こう側のPPP以外に要約のプロトコルを他のLLCに送るために2横に食糧を供給されるかもしれません。 しかしながら、彼らはパケットにPPPセッション中にアクティブなNCPを持っているどんなプロトコルにも属させてはいけません。 実現SHOULDはLLCによって要約されたPPPと非PPPの両方に関連しているサービスの質委任への性能影響を最小にするパケットスケジューリングにプロトコル流れをします。
7. Out-Of-Band Control Plane Signaling
7. バンドの外では、飛行機シグナリングは制御されます。
When originating a switched virtual circuit AAL5 connection, the caller MUST request in the SETUP message either VC-multiplexed PPP, LLC-encapsulated PPP, or else both VC-multiplexed and LLC- encapsulated PPP. When a caller is offering both techniques, the two
交換仮想回路AAL5接続を溯源するとき、VCによって多重送信されていた状態で、訪問者はSETUPメッセージでVCによって多重送信されたPPP、LLCによって要約されたPPPか両方のどちらかを要求しなければなりません、そして、LLCはPPPを要約しました。 訪問者がテクニック、両方の2を提供しているとき
Gross, et. al. Standards Track [Page 6] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[6ページ]RFC2364ppp
B-LLI IEs are encoded within a Broadband Repeat Indicator IE in the order of their preference. The called implementation MUST be able to accept an incoming call that offers LLC-encapsulated PPP in the caller's request. The called implementation MUST reject a call set up request that only offers an encapsulation that it does not support. Implementations originating a call offering both protocol encapsulation techniques MUST be able to negotiate the use of LLC- encapsulated PPP.
B-LLI IEsは彼らの好みの注文におけるBroadband Repeat Indicator IEの中でコード化されます。 呼ばれた実現は訪問者の要求でLLCによって要約されたPPPを提供するかかってきた電話を受け入れることができなければなりません。 呼ばれた実現はそれが支持しないカプセル化を提供するだけである要求に呼び出しセットを拒絶しなければなりません。 両方のプロトコルカプセル化技術を提供する呼び出しを溯源する実現はLLCの要約のPPPの使用を交渉できなければなりません。
When originating a virtual circuit multiplexed call that is to carry a PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3 protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The extension octets specify an IPI value of PPP (0xCF). By definition, the first bytes of the AAL5 frame's payload field will always contain a PPP header followed by a packet.
PPPペイロードを運ぶことになっている仮想のサーキット多重送信された呼び出しを溯源するとき、ITU Q.2931[9]B-LLI要素ユーザー情報層3のプロトコル分野は、八重奏7におけるISO/IEC TR9577[5]を選択するためにコード化されます。 拡大八重奏はPPP(0xCF)のIPI値を指定します。 定義上、AAL5フレームの最初のバイトのペイロード分野はいつもPPPヘッダーを含むでしょう、続いて、パケットを含みます。
When originating an LLC encapsulated call that is to carry a PPP payload, the ITU Q.2931 B-LLI element user information layer 2 protocol field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in octet 6. See RFC 1755 [8] appendix A for an example. By definition, the first bytes of the AAL5 frame's payload field will contain an LLC header, followed by a NLPID and the PPP payload.
由来するとき、LLCはPPPペイロードを運ぶことになっている呼び出しを要約して、ITU Q.2931 B-LLI要素ユーザー情報層2のプロトコル分野は、八重奏6でLAN Logical Link Control(ISO/IEC8802-2)を選択するためにコード化されます。 例に関してRFC1755[8]付録Aを見てください。 定義上、AAL5フレームの最初のバイトのペイロード分野はLLCヘッダーを含むでしょう、続いて、NLPIDとPPPペイロードを含みます。
8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions
8. 求められていないpppカプセル化変遷からの検出と回復
When the virtual connection loses state, the PPP encapsulation technique may uni-laterally and unexpectedly change across such transitions. Detection and recovery procedures are defined for the following state transitions:
仮想接続が状態を失うと、PPPカプセル化技術はそのような変遷の向こう側に一方的に不意に変化するかもしれません。 検出とリカバリ手順は以下の状態遷移のために定義されます:
VC-multiplexed PPP changing to LLC encapsulated PPP
LLCに変化するVCによって多重送信されたPPPがPPPを要約しました。
LLC encapsulated PPP changing to VC-multiplexed PPP
LLCはVCによって多重送信されたPPPに変化するPPPを要約しました。
When LLC-encapsulated PPP is being used, the inital 6 octets of the LCP packets contain the sequence: fe-fe-03-cf-c0-21. This sequence constitutes the first 6 octets of the AAL5 frame. In the case of VC-multiplexed PPP, initial LCP packets contain the sequence c0-21. This sequence constitutes the first 2 octets of an AAL5 frame. When a LCP Configure-Request packet is received and recognized, the PPP link enters Link Establishment phase.
LLCによってカプセル化されたPPPが使用されているとき、LCPパケットのinital6八重奏は系列を含んでいます: fe-fe03Cf c0-21。 この系列はAAL5フレームの最初の6つの八重奏を構成します。 VCによって多重送信されたPPPの場合では、初期のLCPパケットは系列c0-21を含んでいます。 この系列はAAL5フレームの最初の2つの八重奏を構成します。 LCP Configure-リクエスト・パケットが受け取られて、認識されるとき、PPPリンクはLink特権階級フェーズに入ります。
Once PPP has entered the Network-layer Protocol phase, and successfully negotiated a particular NCP for a PPP Protocol, if a frame arrives using an alternate but equivalent data encapsulation as defined in [4], then the PPP Link MUST:
PPPがいったんNetwork-層のプロトコルフェーズに入って、PPPプロトコルのために首尾よく特定のNCPを交渉すると、[4]で定義されるように代替の、同等なデータカプセル化を使用することでフレームが届くなら、PPP Linkは交渉しなければなりませんでした:
Gross, et. al. Standards Track [Page 7] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[7ページ]RFC2364ppp
For a SVC, immediately clear the call with the cause value 111,
"protocol error, unspecified".
SVCに関しては、至急、「プロトコル誤りで、不特定」の原因値111で呼び出しをクリアしてください。
For a PVC: tear down the active NCPs, SHOULD generate an error
message, enter the Termination state, and silently drop all
received packets.
PVCのために: アクティブなNCPを取りこわしてください、SHOULDはエラーメッセージを生成して、Termination状態に入って、静かにすべての容認されたパケットを下げます。
These policies prevent "black-holes" that occur when the peer loses state. An implementation which requires PPP link configuration, and other PPP negotiated features (such as authentication), MAY enter Termination state when configuration fails.
これらの方針は同輩が状態を失うと起こる「ブラックホール」を防ぎます。 構成が失敗すると、PPPリンク構成、および他のPPPの交渉された特徴(認証などの)を必要とする実装はTermination状態に入るかもしれません。
9. LCP Configuration Options
9. LCP設定オプション
The Magic Number LCP configuration option is RECOMMENDED, and the Protocol Field Compression (PFC) option is NOT RECOMMENDED. An implementation MUST NOT request any of the following options, and MUST reject a request for such an option:
マジックNumber LCP設定オプションはRECOMMENDEDです、そして、プロトコルField Compression(PFC)オプションはNOT RECOMMENDEDです。 実装は、以下のオプションのどれかを要求してはいけなくて、そのようなオプションを求める要求を拒絶しなければなりません:
Field Check Sequence (FCS) Alternatives,
チェック系列(FCS)代替手段をさばいてください。
Address-and-Control-Field-Compression (ACFC),
分野圧縮を扱って、制御してください(ACFC)。
Asynchronous-Control-Character-Map (ACCM)
非同期な規制キャラクター地図(ACCM)
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than the maximum CPCS-SDU size specified in the associated direction for the virtual connection's traffic contract.
仮想接続のトラフィック契約として関連方向に指定された最大のCPCS-SDUサイズより大きいサイズとMaximumがユニットを受けている(MRU)オプションを交渉してはいけません。
When viewed peer to peer, a PPP link may be bridged over multiple physical layer sections. For each such AAL5 section, the LCP framing options MUST be actively negotiated by the bridging convertors independently of the LCP framing options in use by other physical layer sections.
見られたピアツーピアであるときに、PPPリンクは複数の物理的な層の部分の上でブリッジされるかもしれません。 そのようなそれぞれのAAL5部において、他の物理的な層の部分のそばで使用中のLCP縁どりオプションの如何にかかわらずブリッジする変換器でLCP縁どりオプションを活発に交渉しなければなりません。
Implementation Note:
When an ATM AAL5 PVC is in the "Stopped" state, it is
RECOMMENDED that the implementation wait for Configure-Requests.
See the implementation option in reference [1] section 4.2, the
"Stopped State" sub-section.
実装注意: ATM AAL5 PVCが「止まっている」状態にあるとき、実装がConfigure-要求を待っているのは、RECOMMENDEDです。 参照[1]セクション4.2の実装オプション、「止まっている状態」小区分を見てください。
10. Security Considerations
10. セキュリティ問題
Generally, ATM networks are virtual circuit based, and security is implicit in the public data networking service provider's administration of Permanent Virtual Circuits (PVCs) between the network boundaries. The probability of a security breach caused by mis-routed ATM cells is considered to be negligible.
一般に、ATMネットワークはベースの仮想の回路です、そして、セキュリティは公衆データネットワークサービスプロバイダーのネットワーク限界の間のPermanent Virtual Circuits(PVCs)の管理で暗黙です。 誤発送されたATMセルによって引き起こされた機密保護違反の確率が取るにたらないと考えられます。
Gross, et. al. Standards Track [Page 8] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[8ページ]RFC2364ppp
When a public ATM network supports Switched Virtual Circuits, the protocol model becomes analogous to traditional voice band modem dial up over the Public Telephone Switched Network (PTSN). The same PAP/CHAP authentication protocols that are already widely in use for Internet dial up access are leveraged. As a consequence, PPP over AAL5 security is at parity with those practices already established by the existing Internet infrastructure.
公立のATMネットワークがSwitched Virtual Circuitsをサポートすると、プロトコルモデルはPublic Telephone Switched Network(PTSN)の上のダイヤルアップの伝統的な音声帯域モデムに類似するようになります。 インターネットダイヤルアップ接続には、広く既に使用中ののと同じPAP/CHAP認証プロトコルは利用されます。 結果として、AAL5セキュリティのPPPがそれらの習慣が既存のインターネット基盤によって既に設立されている同等であるのにあります。
Those applications that require stronger security are encouraged to use authentication headers, or encrypted payloads, and/or ATM-layer security services.
より強いセキュリティを必要とするそれらのアプリケーションが認証ヘッダー、暗号化されたペイロード、そして/または、ATM-層のセキュリティー・サービスを使用するよう奨励されます。
When using LLC-encapsulated PPP over a virtual connection, an end point can not assume that the PPP session authentication and related security mechanisms also secure the other LLC encapsulated flows on that same virtual connection.
仮想接続の上でLLCによってカプセル化されたPPPを使用するとき、エンドポイントは、また、PPPセッション認証と関連するセキュリティー対策がその同じ仮想接続のときに流れであるとカプセル化されたもう片方のLLCを固定すると仮定できません。
11. Acknowledgments
11. 承認
This design is based on work performed in ADSL Forum's Packet Mode Working Group. It is inspired by "PPP in Frame Relay", RFC 1973, by William Simpson. Special thanks to Phil Rakity of Flowpoint, Tim Kwok of Microsoft, and David Allan of Nortel for their constructive review and commentary.
このデザインはADSL ForumのPacket Mode作業部会で行われた仕事に基づいています。 それはウィリアム・シンプソンによって「フレームリレーにおけるppp」、RFC1973によって奮い立たせられます。 彼らの建設的なレビューと論評のためのFlowpointのフィルRakity、マイクロソフトのティム・クォック、およびノーテルのデヴィッド・アランへの特別な感謝。
12. References
12. 参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[2] The ATM Forum, "Frame based User-to-Network Interface (FUNI)
Specification v2", af-saa-0088.000, May 1997.
[2] ATM Forum、「フレームUserからネットワークへのベースのInterface(FUNI)仕様v2"、af-saa-0088.000、1997年5月。」
[3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
1662, July 1994.
[3] シンプソン、W.、エディタ、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
[4] Heinanen, J., "Multiprotocol Interconnect over AAL5", RFC 1483,
July 1993.
[4] Heinanen、J.、「Multiprotocolは1993年7月にAAL5"、RFC1483の上で内部連絡します」。
[5] ISO/IEC DTR 9577.2, "Information technology -
Telecommunications and Information exchange between systems -
Protocol Identification in the network layer", 1995-08-16.
[5] ISO/IEC DTR9577.2、「情報技術(システムの間のテレコミュニケーションと情報交換)はネットワーク層でIdentificationについて議定書の中で述べます」、1995年8月16日。
[6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[6] シンプソン、W.、「フレームリレーにおけるppp」、RFC1973、1996年6月。
[7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-
working Implementation Agreement", FRF.8, April 1995.
1995年4月の[7] Frame Relay Forum、「フレームRelay/ATM PVC Service Interの働くImplementation Agreement」FRF.8。
Gross, et. al. Standards Track [Page 9] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[9ページ]RFC2364ppp
[8] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
February 1995.
[8] ペレス、M.、Liaw、F.、マンキン、A.、ホフマン、E.、グロースマン、D.、およびA.Malis、「気圧でのIPの気圧シグナリングサポート」、RFC1755(1995年2月)。
[9] 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, (International Telecommunication Union: Geneva, 2/95)
[9] 国際電気通信連合、「ブロードバンドは基本的な呼び出し/接続コントロールのためのサービスディジタル通信網(B-ISDN)のデジタル加入者シグナリングシステムNo.2(DSS2)ユーザネットワーク・インターフェース層の3仕様を統合しました」、ITU-T推薦Q.2931(国際電気通信連合: ジュネーブ、2/95)
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl Fox Ascend Communications 3518 Riverside Drive, Suite 101 Columbus, Ohio 43221
カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。
EMail: karl@ascend.com
メール: karl@ascend.com
Authors' Addresses
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
George Gross Lucent Technologies, Inc 184 Liberty Corner Road Warren, NJ 07059
ジョージGrossのルーセントテクノロジーズ、Inc184自由コーナーRoadウォレン、ニュージャージー 07059
Phone: +1.908.580.4589 EMail: gmgross@lucent.com
以下に電話をしてください。 +1.908 .580 .4589 メール: gmgross@lucent.com
Manu Kaycee Paradyne Corporation 21 Bear Meadow Road Londonderry, NH 03053-2168
マヌーKaycee Paradyne社21は草地Roadロンドンデリー、ニューハンプシャー03053-2168に堪えます。
Phone: +1.603.434.6088 EMail: mjk@nj.paradyne.com
以下に電話をしてください。 +1.603 .434 .6088 メール: mjk@nj.paradyne.com
Gross, et. al. Standards Track [Page 10] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[10ページ]RFC2364ppp
Arthur Lin Shasta Networks Inc. 249 Humboldt Court Sunnyvale, CA 94089-1300
アーサー・リンシャスタはハンボルト法廷サニーベル、株式会社249カリフォルニア94089-1300をネットワークでつなぎます。
Phone: +1.408.747.5051 EMail: alin@shastanets.com
以下に電話をしてください。 +1.408 .747 .5051 メール: alin@shastanets.com
Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
アンドリューMalisはInc.1ロビンス・Roadウェストフォード、Communications MA 01886を昇ります。
Phone: +1.978.952.7414 EMail: malis@ascend.com
以下に電話をしてください。 +1.978 .952 .7414 メール: malis@ascend.com
John Stephens Cayman Systems, Inc. 100 Maple Street Stoneham, MA 02180
通りストーナム、ジョン・スティーブンスケイマンSystems Inc.100Maple MA 02180
Phone: +1.617.279.1101 EMail: john@cayman.com
以下に電話をしてください。 +1.617 .279 .1101 メール: john@cayman.com
Gross, et. al. Standards Track [Page 11] RFC 2364 PPP Over AAL5 July 1998
etグロス、アル。 AAL5 July 1998の上の標準化過程[11ページ]RFC2364ppp
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Gross, et. al. Standards Track [Page 12]
etグロス、アル。 標準化過程[12ページ]
一覧
スポンサーリンク
