[要約] RFC 2363は、PPP Over FUNI（Frame-based UNI）プロトコルに関する仕様を提供しています。このRFCの目的は、FUNIネットワーク上でのPPP接続を可能にするための手順と要件を定義することです。
Network Working Group G. Gross
Request for Comments: 2363 Lucent Technologies
Category: Standards Track M. Kaycee
Paradyne
A. Li
Shasta Networks
A. Malis
Ascend Communications
J. Stephens
Cayman Systems
July 1998
PPP Over FUNI
PPP over FUNI
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
ポイントツーポイントプロトコル（PPP）[1]は、ポイントツーポイントリンクを介してマルチプロトコルデータグラムを転送する標準的な方法を提供します。
This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets.
このドキュメントでは、PPPカプセル化パケットをフレーミングするためのATMフレームユーザーネットワークインターフェイス（FUNI）の使用について説明します。
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用に定義された機能を使用したい実装を対象としています。これらの機能には、ピア間のポイントツーポイントの関係が必要であり、ATMおよびその他のマルチアクセス環境で利用できるマルチポイントの関係用には設計されていません。
ATM FUNI 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 FUNIプロトコルは、同じネットワークに接続された端末間の仮想接続を提供するように設計されています。これらの接続は、エラー検出を含むパケット配信サービスを提供しますが、エラー修正は行いません。
Most existing implementations of PPP use ISO 3309 HDLC as a basis for their framing [3].
PPPの既存のほとんどの実装では、フレーミングの基礎としてISO 3309 HDLCを使用しています[3]。
When an ATM network is configured with point-to-point connections, PPP can use FUNI as a framing mechanism.
ATMネットワークがポイントツーポイント接続で構成されている場合、PPPはフレームメカニズムとしてFUNIを使用できます。
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]で説明されているように解釈する必要があります（必須、必須ではありません、必須、必須、必須ではありません、必須、必須ではありません）。
The PPP layer treats the underlying ATM FUNI layer service as a bit-synchronous point-to-point link. In this context, the PPP link corresponds to an ATM FUNI 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/FUNI service interface boundary MUST meet the following requirements:
PPP層は、基礎となるATM FUNI層サービスをビット同期ポイントツーポイントリンクとして扱います。このコンテキストでは、PPPリンクはATM FUNI仮想接続に対応しています。仮想接続は全二重、ポイントツーポイントである必要があり、専用（つまり、永続的で、プロビジョニングによってセットアップされる）または切り替えられる（オンデマンドでセットアップされる）場合があります。さらに、PPP / FUNIサービスインターフェイスの境界は、次の要件を満たしている必要があります。
Interface Format - The PPP/FUNI layer boundary presents an octet service interface to the FUNI layer. There is no provision for sub-octets to be supplied or accepted.
インターフェース形式-PPP / FUNIレイヤー境界は、FUNIレイヤーへのオクテットサービスインターフェースを提供します。サブオクテットを提供または受け入れる規定はありません。
Transmission Rate - The PPP layer does not impose any restrictions regarding transmission rate or the underlying ATM layer traffic descriptor parameters.
伝送速度-PPP層は、伝送速度や基になるATM層のトラフィック記述子パラメーターに関する制限を課しません。
Control Signals - The FUNI 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
制御信号-FUNI層は、仮想接続リンクがいつ接続または切断されたかを示す制御信号をPPP層に提供する必要があります。これらは「アップ」と
"Down" events to the LCP state machine [1] within the PPP layer.
PPPレイヤー内のLCPステートマシン[1]への「ダウン」イベント。
This specification uses the principles, terminology, and frame structure described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [4].
この仕様では、「ATMアダプテーションレイヤー5上のマルチプロトコルカプセル化」[4]で説明されている原理、用語、およびフレーム構造を使用しています。
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 a FUNI-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]ですでに標準化されているものを文書化することではなく、[4]で説明されているメカニズムを使用してPPPをFUNIベースのATMネットワークにマップする方法を指定することです。 [4]のセクション1は、プロトコルデータユニット（PDU）ペイロードフィールドのプロトコルタイプを識別するための2つのメカニズムを定義しています。仮想回線ベースの多重化と論理リンク制御（LLC）カプセル化です。前者の手法では、ペイロードのプロトコルタイプは、プロビジョニングまたはコントロールプレーン手順を使用して、各仮想回線のエンドポイントによって暗黙的に合意されます。 LLCカプセル化技術を使用する場合、ペイロードのプロトコルタイプは、インバンドLLCヘッダーとその後に続くペイロードデータによって、PDUごとに明示的に識別されます。
When transporting a PPP payload over FUNI, an implementation:
FUNIを介して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. 両方のエンドポイントの相互構成またはネゴシエーションによって、以下のセクション6で説明するように、PVC上のLLCカプセル化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. SVCセットアップの場合、実装はQ.2931 [9] Annex C手順を使用してネゴシエートし、ブロードバンド下位層インターフェイス（B-LLI）情報要素をエンコードして、VC多重化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 FUNI end point is inter-operating with an RFC 1973 end point.
実装がフレームリレー/ ATM FRF.8 [7]サービスインターワーキングユニットを介してRFC 1973 [6]エンドポイントに接続している場合、LLCカプセル化PPPペイロードを使用する必要があります。フレームリレー/ ATM FRF.8インターワーキングユニットは、VC多重化PPPをサポートする要件から除外されます。この免除により、PPP over FUNIエンドポイントがRFC 1973エンドポイントと相互運用している場合でも、FR / ATM IWUはFRF.8に準拠したままになります。
The FUNI protocol data unit (PDU) format [2] is as follows:
FUNIプロトコルデータユニット（PDU）形式[2]は次のとおりです。
+-------------------------------+
| Flag |
+-------------------------------+---------
| FUNI Header | ^
+-------------------------------+ |
| | |
| | |
| User SDU | FUNI PDU
| | |
| | |
+-------------------------------+ |
| FUNI FCS (2 or 4 octets) | v
+-------------------------------+---------
| Flag |
+-------------------------------+
Figure 1
The FUNI Header includes a 10-bit or 24-bit Frame Address (a.k.a. VPI/VCI bits), a Congestion Notification bit, a Congestion Loss Priority bit, and four Reserved bits.
FUNIヘッダーには、10ビットまたは24ビットのフレームアドレス（別名VPI / VCIビット）、輻輳通知ビット、輻輳損失優先ビット、および4つの予約ビットが含まれています。
The User SDU field contains user information up to 4096 (optionally up to 64K) octets.
User SDUフィールドには、最大4096（オプションで最大64K）オクテットのユーザー情報が含まれます。
The FCS field protects the entire FUNI PDU except for the FCS field itself.
FCSフィールドは、FCSフィールド自体を除いて、FUNI PDU全体を保護します。
A VC-multiplexed PPP frame SHALL constitute the User Service Data Unit (SDU) field and is defined as shown in figure 2:
VC多重化PPPフレームは、ユーザーサービスデータユニット（SDU）フィールドを構成する必要があり（SHALL）、図2に示すように定義されます。
+-------------+-------------+---------+
| Protocol ID | Information | Padding |
| 8/16 bits | | |
+-------------+-------------+---------+
Figure 2
Each of these fields are specifically defined in [1].
これらの各フィールドは、[1]で具体的に定義されています。
LLC encapsulated PPP over FUNI is the alternative technique to VC-multiplexed PPP over FUNI.
LLCカプセル化PPP over FUNIは、VC多重化PPP over FUNIの代替手法です。
The FUNI SDU payload field is encoded as shown in figure 3. The pertinent fields in that diagram are:
FUNI SDUペイロードフィールドは、図3に示すようにエンコードされます。この図の関連フィールドは次のとおりです。
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ヘッダー：ルーティングされたOSI PDUのソースSAPおよび宛先SAP（値0xFE 0xFE）を指定するためにエンコードされた2バイト、その後に番号なし情報（UI）フレームタイプ（値0x03）。
2. Network Layer Protocol IDentifier (NLPID) representing PPP, (value 0xCF).
2. PPPを表すネットワーク層プロトコル識別子（NLPID）（値0xCF）。
3. the PPP protocol identifier field, which can be either 1 or 2 octets long. See reference [1].
3. 1または2オクテットの長さのPPPプロトコル識別子フィールド。参考文献[1]を参照してください。
4. followed by the PPP information field as per Figure 2.
4. 図2のように、PPP情報フィールドが続きます。
+-------------------------+ --------
| 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
+-------------------------+ --------
| FUNI FCS (2 or 4 octets)| FUNI trailer
+-------------------------+---------
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カプセル化プロトコルを送信するために、双方向でプロビジョニングされる場合があります。ただし、PPPセッション内でアクティブなNCPを持つプロトコルに属するパケットを送信してはなりません（MUST NOT）。実装は、LLCカプセル化PPPおよび非PPPプロトコルフローの両方に関連するサービス品質コミットメントへのパフォーマンスの影響を最小限に抑えるパケットスケジューリングを行う必要があります。
When originating a switched virtual circuit FUNI 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 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.
スイッチドバーチャルサーキットFUNI接続を開始する場合、呼び出し元はSETUPメッセージでVC多重化PPP、LLCカプセル化PPP、またはVC多重化とLLCカプセル化PPPの両方を要求する必要があります。発信者が両方の技術を提供している場合、2つのB-LLI IEは、優先順でブロードバンドリピートインジケータIE内にエンコードされます。呼び出された実装は、発信者の要求でLLCカプセル化されたPPPを提供する着信呼び出しを受け入れることができなければなりません（MUST）。呼び出された実装は、サポートしていないカプセル化のみを提供する呼び出し設定要求を拒否する必要があります。両方のプロトコルカプセル化技術を提供するコールを発信する実装は、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 FUNI 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 TR 9577 [5]を選択するようにエンコードされます。拡張オクテットはPPP（0xCF）のIPI値を指定します。定義により、FUNIフレームのペイロードフィールドの最初のバイトには、常に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 FUNI frame's payload field will contain an LLC header, followed by a NLPID and the PPP payload.
PPPペイロードを伝送するLLCカプセル化コールを発信する場合、ITU Q.2931 B-LLI要素のユーザー情報レイヤー2プロトコルフィールドは、オクテット6でLAN論理リンク制御（ISO / IEC8802-2）を選択するようにエンコードされます。RFCを参照してください例として1755 [8]付録A。定義により、FUNIフレームのペイロードフィールドの最初のバイトにはLLCヘッダーが含まれ、その後にNLPIDと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
VC多重化PPPからLLCカプセル化PPPへの変更
LLC encapsulated PPP changing to VC-multiplexed PPP
LLCカプセル化PPPからVC多重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 FUNI frame. In the case of VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
LLCカプセル化PPPが使用されている場合、LCPパケットの最初の6オクテットには、fe-fe-03-cf-c0-21というシーケンスが含まれます。このシーケンスは、FUNIフレームの最初の6オクテットを構成します。 VC多重化PPPの場合、初期LCPパケットにはシーケンスc0-21が含まれます。
In the case of FUNI, this sequence follows the FUNI Header. When a LCP Configure-Request packet is received and recognized, the PPP link enters Link Establishment phase.
FUNIの場合、このシーケンスはFUNIヘッダーに従います。 LCP構成要求パケットが受信されて認識されると、PPPリンクはリンク確立フェーズに入ります。
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がネットワーク層プロトコルフェーズに入り、PPPプロトコルの特定のNCPのネゴシエーションに成功すると、[4]で定義されている代替の同等のデータカプセル化を使用してフレームが到着した場合、PPPリンクは次のようになります。
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を破棄し、エラーメッセージを生成し、終了状態に入り、受信したすべてのパケットを警告なしにドロップする必要があります。
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ネゴシエーションされた機能（認証など）を必要とする実装は、構成が失敗すると終了状態になる場合があります。
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:
マジックナンバーLCP構成オプションは推奨され、プロトコルフィールド圧縮（PFC）オプションは推奨されません。実装は以下のオプションのいずれも要求してはならず（MUST NOT）、そのようなオプションの要求を拒否しなければなりません（MUST）。
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.
Maximum-Receive-Unit（MRU）オプションは、仮想接続のトラフィックコントラクトの関連する方向で指定された最大CPCS-SDUサイズよりも大きいサイズにネゴシエートしてはなりません（MUST NOT）。
When viewed peer to peer, a PPP link may be bridged over multiple physical layer sections. For each such FUNI 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リンクは複数の物理層セクションにまたがってブリッジされることがあります。そのようなFUNIセクションごとに、LCPフレーミングオプションは、他の物理層セクションで使用されているLCPフレーミングオプションとは無関係に、ブリッジングコンバーターによってアクティブにネゴシエートされる必要があります。
Implementation Note: When an ATM FUNI 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 FUNI PVCが「停止」状態の場合、実装がConfigure-Requestsを待つことが推奨されます。リファレンス[1]の実装オプションのセクション4.2、「Stopped State」サブセクションを参照してください。
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ネットワークは仮想回線ベースであり、セキュリティは、パブリックデータネットワーキングサービスプロバイダーによるネットワーク境界間の永続的仮想回線（PVC）の管理に暗黙的に含まれています。誤ってルーティングされたATMセルによって引き起こされるセキュリティ違反の可能性は無視できると考えられます。
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 FUNI security is at parity with those practices already established by the existing Internet infrastructure.
公衆ATMネットワークが交換仮想回線をサポートしている場合、プロトコルモデルは、公衆電話交換網（PTSN）を介した従来の音声帯域モデムダイヤルアップに類似しています。インターネットダイヤルアップアクセスで既に広く使用されている同じPAP / CHAP認証プロトコルが利用されます。その結果、PPP over FUNIのセキュリティは、既存のインターネットインフラストラクチャによってすでに確立されているプラクティスと同等です。
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カプセル化フローも保護することを想定できません。
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フォーラムのパケットモードワーキンググループで実行された作業に基づいています。これは、William Simpsonによる「PPP in Frame Relay」（RFC 1973）に触発されています。 FlowpointのPhil Rakity、MicrosoftのTim Kwok、NortelのDavid Allanの建設的なレビューと解説に感謝します。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] シンプソン、W、編集者、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[2] The ATM Forum, "Frame based User-to-Network Interface (FUNI) Specification v2", af-saa-0088.000, May 1997.
[2] ATMフォーラム、「Frame based User-to-Network Interface（FUNI）Specification v2」、af-saa-0088.000、1997年5月。
[3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3] シンプソン、W。、編集者、「PPP in HDLC-like Framing」、STD 51、RFC 1662、1994年7月。
[4] Heinanen, J., "Multiprotocol Interconnect over AAL5", RFC 1483, July 1993.
[4] Heinanen、J。、「AAL5上のマルチプロトコル相互接続」、RFC 1483、1993年7月。
[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 DTR 9577.2、「情報技術-システム間のテレコミュニケーションおよび情報交換-ネットワークレイヤーでのプロトコル識別」、1995-08-16。
[6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[6] シンプソン、W。、「PPP in Frame Relay」、RFC 1973、1996年6月。
[7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working Implementation Agreement", FRF.8, April 1995.
[7] フレームリレーフォーラム、「Frame Relay / ATM PVC Service Inter-working Implementation Agreement」、FRF.8、1995年4月。
[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] Perez、M.、Liaw、F.、Mankin、A.、Hoffman、E.、Grossman、D。、およびA. Malis、「ATM Signaling Support for IP over ATM」、RFC 1755、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] 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ユニオン：ジュネーブ、2/95）
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、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
Karl Fox Ascend Communications 3518 Riverside Drive、Suite 101 Columbus、Ohio 43221
EMail: 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
George Gross Lucent Technologies、Inc 184 Liberty Corner Road Warren、NJ 07059
Phone: +1.908.580.4589
EMail: gmgross@lucent.com
Manu Kaycee Paradyne Corporation 21 Bear Meadow Road Londonderry, NH 03053-2168
Manu Kaycee Paradyne Corporation 21 Bear Meadow Road Londonderry、NH 03053-2168
Phone: +1.603.434.6088
EMail: mjk@nj.paradyne.com
Arthur Lin Shasta Networks Inc. 249 Humboldt Court Sunnyvale, CA 94089-1300
Arthur Lin Shasta Networks Inc. 249 Humboldt Court Sunnyvale、CA 94089-1300
Phone: +1.408.747.5051 EMail: alin@shastanets.com Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
電話：+1.408.747.5051メール：alin@shastanets.com Andrew Malis Ascend Communications、Inc. 1 Robbins Road Westford、MA 01886
Phone: +1.978.952.7414
EMail: malis@ascend.com
John Stephens Cayman Systems, Inc. 100 Maple Street Stoneham, MA 02180
John Stephens Cayman Systems、Inc.100 Maple Street Stoneham、MA 02180
Phone: +1.617.279.1101
EMail: john@cayman.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。