[要約] RFC 3336は、PPPを使用してAsynchronous Transfer Mode Adaptation Layer 2（AAL2）上で通信するためのプロトコル仕様です。このRFCの目的は、AAL2を介してPPPを使用するための手順と要件を定義することです。
Network Working Group B. Thompson
Request for Comments: 3336 T. Koren
Category: Standards Track Cisco Systems
B. Buffam
Seaway Networks
December 2002
PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)
非同期転送モード適応レイヤー2（AAL2）のPPP
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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
ポイントツーポイントプロトコル（PPP）は、ポイントツーポイントリンクでマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。
This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets.
このドキュメントでは、PPPカプセル化されたパケットをフレーミングするためのATM適応レイヤー2（AAL2）の使用について説明します。
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やその他のマルチアクセス環境で利用できるマルチポイント関係向けには設計されていません。
PPP over AAL5 [2] describes the encapsulation format and operation of PPP when used with the ATM AAL5 adaptation layer. While this encapsulation format is well suited to PPP transport of IP, it is bandwidth inefficient when used for transporting small payloads such as voice. PPP over AAL5 is especially bandwidth inefficient when used with RTP header compression [3].
PPP Over AAL5 [2]は、ATM AAL5適応層で使用した場合のPPPのカプセル化形式と動作について説明します。このカプセル化形式は、IPのPPP輸送に適していますが、音声などの小さなペイロードを輸送するために使用される場合、帯域幅は非効率的です。AAL5上のPPPは、RTPヘッダー圧縮で使用する場合、特に帯域幅が非効率的です[3]。
PPP over AAL2 addresses the bandwidth efficiency issues of PPP over AAL5 for small packet transport by making use of the AAL2 Common Part Sublayer (CPS) [4] to allow multiple PPP payloads to be multiplexed into a set of ATM cells.
AAL2オーバーAAL2は、AAL2共通部品サブレイヤー（CPS）[4]を使用することにより、小さなパケット輸送のためにAAL5を介したPPPの帯域幅効率の問題に対処し、複数のPPPペイロードをATMセルのセットに多重化します。
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 [6].
キーワードは、このドキュメントに表示される場合、[6]で説明されているように解釈される場合、必要な、要求されてはなりません。
The PPP layer treats the underlying ATM AAL2 layer service as a bit-synchronous point-to-point link. In this context, the PPP link corresponds to an ATM AAL2 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/AAL2 service interface boundary MUST meet the following requirements.
PPPレイヤーは、基礎となるATM AAL2レイヤーサービスを少し同期ポイントツーポイントリンクとして扱います。これに関連して、PPPリンクはATM AAL2仮想接続に対応します。仮想接続はフルダプレックス、ポイントツーポイントでなければならず、それは専用（つまり、永続的、プロビジョニングによってセットアップされる）または切り替え（デマンドで設定）である場合があります。さらに、PPP/AAL2サービスインターフェイスの境界は、次の要件を満たす必要があります。
Interface Format - The PPP/AAL2 layer boundary presents an octet service interface to the AAL2 layer. There is no provision for sub-octets to be supplied or accepted.
インターフェイス形式-PPP/AAL2レイヤー境界は、AAL2レイヤーへのオクテットサービスインターフェイスを示します。サブオクテットが供給または受け入れられる規定はありません。
Transmission Rate - The PPP layer does not impose any restrictions regarding transmission rate on the underlying ATM layer traffic descriptor parameters.
伝送速度 - PPP層は、基礎となるATMレイヤートラフィック記述子パラメーターに伝送速度に関する制限を課しません。
Control Signals - The AAL2 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 "Down" events to the LCP state machine [1] within the PPP layer.
制御信号 - AAL2レイヤーは、仮想接続リンクが接続または切断された時期を示すPPPレイヤーに制御信号を提供する必要があります。これらは、PPPレイヤー内のLCP状態マシン[1]に「UP」および「ダウン」イベントを提供します。
In the case of PPP over AAL2, the state of the link can be derived from the type 3 fault management packets carried in-band within a given AAL2 CID flow.
AAL2を介したPPPの場合、リンクの状態は、特定のAAL2 CIDフロー内で帯域内に搭載されたタイプ3障害管理パケットから導出できます。
PPP over AAL2 defines an encapsulation that uses the Service Specific Segmentation and Reassembly Sublayer (SSSAR) [5] for AAL type 2. The SSSAR sub-layer is used to segment PPP packets into frames that can be transported using the AAL2 CPS. The SSSAR sub-layer uses different AAL2 UUI code-points to indicate whether a segment is the last segment of a packet or not.
AAL2を超えるPPPは、AALタイプ2にサービス固有のセグメンテーションと再組み立てサブレーヤー（SSSAR）[5]を使用するカプセル化を定義します。SSSARサブレイヤーは、AAL2 CPSを使用して輸送できるフレームにPPPパケットをセグメント化するために使用されます。SSSARサブレイヤーは、さまざまなAAL2 UUIコードポイントを使用して、セグメントがパケットの最後のセグメントであるかどうかを示します。
The encapsulation of PPP over AAL2 provides a 16-bit CRC for PPP payloads. There are 2 UUI code points assigned from SSSAR to indicate intermediate fragments of a packet and the last fragment of a packet. Code point 27 indicates intermediate frames of a fragmented packet and code point 26 indicates the last frame of a packet. The encapsulation format is more fully described in section 6.2.1.
AAL2を介したPPPのカプセル化は、PPPペイロードに16ビットCRCを提供します。パケットの中間断片とパケットの最後のフラグメントを示すために、SSSARから割り当てられた2つのUUIコードポイントがあります。コードポイント27は、断片化されたパケットの中間フレームを示し、コードポイント26はパケットの最後のフレームを示します。カプセル化形式は、セクション6.2.1でより完全に説明されています。
An implementation of PPP over AAL2 MAY use one or more AAL2 Channel Identifiers (CIDs) for transport of PPP packets associated with each PPP session. Multiple CIDs could be used to implement a multiple class real time transport service for PPP using the AAL2 layer for link fragmentation and interleaving. A companion document [10] describes class extensions for PPP over AAL2 using multiple AAL2 CIDs.
AAL2を介したPPPの実装は、各PPPセッションに関連付けられたPPPパケットの輸送に1つ以上のAAL2チャネル識別子（CID）を使用する場合があります。複数のCIDを使用して、リンクの断片化とインターリーブにAAL2層を使用して、PPPの複数のクラスリアルタイムトランスポートサービスを実装できます。コンパニオンドキュメント[10]は、複数のAAL2 CIDを使用してAAL2を介したPPPのクラス拡張機能を説明しています。
This document proposes the substitution of AAL2 transport for PPP in scenarios where small packets are being transported over an ATM network. This is most critical in applications such as voice transport using RTP [9] where RTP Header compression [3] is used. In applications such as voice transport, both bandwidth efficiency and low delay are very important.
このドキュメントでは、ATMネットワーク上で小さなパケットが輸送されているシナリオで、PPPのAAL2輸送の代替を提案しています。これは、RTPヘッダー圧縮[3]が使用されるRTP [9]を使用した音声輸送などのアプリケーションで最も重要です。音声輸送などのアプリケーションでは、帯域幅の効率と低遅延の両方が非常に重要です。
This section provides justification for the PPP over AAL2 service for ATM transport by comparing it to existing PPP encapsulation formats used for transport over ATM. Two encapsulation formats will be examined here: PPP over AAL5 [2], and PPP with PPPMUX [8] over AAL5.
このセクションでは、ATMの輸送に使用される既存のPPPカプセル化形式と比較することにより、ATM輸送用のAAL2サービスを介したPPPを正当化します。ここでは、2つのカプセル化形式を検討します：AAL5 [2]を介したPPP、およびAAL5を使用したPPPMUX [8]を使用します。
This proposal uses ATM AAL2 [4] rather than AAL5 as the transport for PPP. SSSAR along with the AAL2 CPS generates less ATM encapsulation overhead per PPP payload. The payload encapsulation consists of a 2 byte CRC. The AAL2 CPS header consists of 3 bytes, and the AAL2 Start Field (STF) is 1 byte. This is a total encapsulation overhead of 6 bytes. This compares to 8 bytes of overhead for the AAL5 trailer used for PPP over AAL5.
この提案は、PPPの輸送としてAAL5ではなくATM AAL2 [4]を使用しています。SSSARとAAL2 CPSとともに、PPPペイロードごとにATMカプセル化オーバーヘッドが少なくなります。ペイロードカプセル化は、2バイトCRCで構成されています。AAL2 CPSヘッダーは3バイトで構成され、AAL2開始フィールド（STF）は1バイトです。これは、6バイトの合計カプセル化オーバーヘッドです。これは、AAL5を介してPPPに使用されるAAL5トレーラーの8バイトのオーバーヘッドと比較されます。
The multiplexing function of the AAL2 CPS layer allows more bandwidth efficient transport of PPP frames by multiplexing multiple PPP frames into one or more ATM cells using the AAL2 CPS function. This removes the pad overhead of AAL5 when used to transport short frames.
AAL2 CPS層の多重化関数は、AAL2 CPS関数を使用して複数のPPPフレームを1つ以上のATMセルに多重化することにより、PPPフレームの帯域幅効率的な輸送を可能にします。これにより、短いフレームの輸送に使用すると、AAL5のパッドオーバーヘッドが削除されます。
PPP Multiplexing (PPPMUX) [8] is a new method for doing multiplexing in the PPP layer. PPPMUX provides functionality similar to the CPS based multiplexing function of AAL2. Using PPP multiplexing, a PPP stack would look like PPP/PPPMUX/AAL5.
PPP多重化（PPPMUX）[8]は、PPP層で多重化を行うための新しい方法です。PPPMUXは、AAL2のCPSベースの多重化関数と同様の機能を提供します。PPP多重化を使用すると、PPPスタックはPPP/PPPMUX/AAL5のように見えます。
Both PPP/PPPMUX/AAL5 and PPP/AAL2 use multiplexing to reduce the overhead of cell padding when frames are sent over an ATM virtual circuit. However, the bandwidth utilization of PPP/AAL2 will typically be better than the bandwidth used by PPP/PPPMUX/AAL5. This is because multiplexed frames in PPP/PPPMUX/AAL5 must always be encapsulated within an AAL5 frame before being sent. This encapsulation causes an additional 8 bytes of AAL5 trailer to be added to the PPPMUX encapsulation. In addition to the 8 bytes of AAL5 trailer, PPPMUX will incur an average of 24 additional bytes of AAL5 PAD. These 2 factors will end up reducing the effective efficiency of PPPMUX when it is used over AAL5.
PPP/PPPMUX/AAL5とPPP/AAL2の両方が多重化を使用して、ATM仮想回路にフレームが送信されたときにセルパディングのオーバーヘッドを減らします。ただし、PPP/AAL2の帯域幅の使用率は、通常、PPP/PPPMUX/AAL5で使用される帯域幅よりも優れています。これは、送信する前にPPP/PPPMUX/AAL5の多重化されたフレームを常にAAL5フレーム内でカプセル化する必要があるためです。このカプセル化により、追加の8バイトのAAL5トレーラーがPPPMuxのカプセル化に追加されます。AAL5トレーラーの8バイトに加えて、PPPMUXはAAL5パッドの平均24バイトの追加バイトを発生させます。これらの2つの要因は、AAL5で使用される場合、PPPMuxの効果的な効率を低下させることになります。
With PPP/AAL2, the AAL2 CPS layer treats individual PPP frames as a series of CPS payloads that can be multiplexed. As long as PPP frames arrive at the CPS layer before the CPS TIMER_CU expires, all ATM cells coming from the CPS layer will be filled. Under these conditions, PPP/AAL2 will have no PAD associated with it. When the AAL2 CPS function causes no PAD to be generated, PPP/AAL2 will be more bandwidth efficient than PPP/PPPMUX/AAL5.
PPP/AAL2を使用すると、AAL2 CPS層は、個々のPPPフレームを多重化できる一連のCPSペイロードとして扱います。PPPフレームがCPS Timer_CUの有効期限が切れる前にCPS層に到着する限り、CPS層から来るすべてのATMセルが満たされます。これらの条件下では、PPP/AAL2にはそれに関連するパッドがありません。AAL2 CPS関数がPADを生成しない場合、PPP/AAL2はPPP/PPPMUX/AAL5よりも帯域幅効率が高くなります。
In PPP/PPPMUX/AAL5, the AAL5 SAR and the PPP MUX/DEMUX are performed in two different layers. Thus, the PPPMUX/AAL5 receiver must reassemble a full AAL5 frame from the ATM layer before the PPPMUX layer can extract the PPP payloads. To derive maximum PPP Multiplexing efficiency, many PPP payloads may be multiplexed together. This increases the size of the multiplexed frame to many ATM cells. If one of these ATM cells is lost, the whole PPPMUX packet will be discarded. Also, there may be a significant delay incurred while the AAL5 layer waits for many ATM cell arrival times until a full frame has been assembled before the full frame is passed up to the PPP Multiplexing layer where the inverse PPP demux then occurs. This same issue also applies to PPPMUX/AAL5 frames progressing down the stack.
PPP/PPPMUX/AAL5では、AAL5 SARとPPP MUX/DEMUXが2つの異なる層で実行されます。したがって、PPPMUX/AAL5レシーバーは、PPPMux層がPPPペイロードを抽出する前に、ATM層から完全なAAL5フレームを再組み立てる必要があります。最大のPPP多重化効率を導出するために、多くのPPPペイロードが一緒に多重化される場合があります。これにより、多重化されたフレームのサイズが多くのATMセルに増加します。これらのATMセルのいずれかが失われた場合、PPPMUXパケット全体が破棄されます。また、AAL5層がフルフレームが組み立てられるまでAAL5層が多くのATMセルの到着時間を待っている間に発生する可能性があります。この同じ問題は、スタックを進行するPPPMUX/AAL5フレームにも適用されます。
With AAL2, both the segmentation and reassembly and multiplexing functions are performed in the AAL2 CPS layer. Because of the definition of the AAL2 CPS function, a multiplexed payload will be extracted as soon as it is received. The CPS receiver does not wait until the many payloads of an AAL2 multiplexed frame are received before removing payloads from the multiplexed stream. The same benefit also applies to AAL2 CPS sender implementations. Also, the loss of an ATM cell causes the loss of the packets that are included in that cell only.
AAL2を使用すると、AAL2 CPS層でセグメンテーションと再組み立て関数と多重化関数の両方が実行されます。AAL2 CPS関数の定義により、受信するとすぐに多重化ペイロードが抽出されます。CPSレシーバーは、多重化されたストリームからペイロードを削除する前に、AAL2多重化フレームの多くのペイロードが受信されるまで待機しません。同じ利点は、AAL2 CPS送信者の実装にも当てはまります。また、ATMセルが失われると、そのセルのみに含まれるパケットが失われます。
The AAL2 CPS function provides multiplexing in AAL2. This function often needs to be implemented in hardware for performance reasons. Because of this, a PPP/AAL2 implementation that takes advantage of an AAL2 SAR implemented in hardware will have significant performance benefits over a PPP/PPPMUX/AAL5 implementation where PPPMUX is implemented in software. Also, the AAL2 specification has been available significantly longer than the PPP Multiplexing specification and because of this, optimized software and hardware implementations of the AAL2 CPS function are further in development than PPP Multiplexing implementations.
AAL2 CPS関数は、AAL2で多重化を提供します。この機能は、パフォーマンス上の理由でハードウェアに実装する必要があることがよくあります。このため、ハードウェアに実装されたAAL2 SARを活用するPPP/AAL2実装は、PPPMUXがソフトウェアに実装されているPPP/PPPMUX/AAL5実装よりも大きなパフォーマンスの利点をもたらします。また、AAL2仕様はPPP多重化仕様よりも大幅に長く利用可能であり、このため、AAL2 CPS関数の最適化されたソフトウェアとハードウェア実装は、PPP多重化の実装よりも開発中です。
ITU-T I.363.2 specifies ATM Adaptation Layer Type 2. This AAL type provides for bandwidth efficient transmission of low-rate, short and variable length packets in delay sensitive applications. More than one AAL type 2 user information stream can be supported on a single ATM connection. There is only one definition for the sub-layer because it implements the interface to the ATM layer and is shared by more than one SSCS layer.
ITU-T I.363.2は、ATM適応層タイプ2を指定します。このAALタイプは、遅延敏感なアプリケーションで低料金、短い、可変長さパケットの帯域幅効率的な伝送を提供します。1つのATM接続で複数のAALタイプ2ユーザー情報ストリームをサポートできます。サブレイヤーには、ATMレイヤーにインターフェイスを実装し、複数のSSCSレイヤーで共有されるため、1つの定義は1つだけです。
ITU-T I.366.1 and I.366.2 define Service Specific Convergence Sub-layers (SSCS) that operate above the Common Part Sub-layer defined in I.363.2. This layer specifies packet formats and procedures to encode the different information streams in bandwidth efficient transport. As the name implies, this sub-layer implements those elements of service specific transport. While there is only one definition of the Common Part Sublayer for AAL2, there can be multiple SSCS functions defined to run over this CPS layer. Different CIDs within an AAL2 virtual circuit may run different SSCSs.
ITU-T I.366.1およびI.366.2は、i.363.2で定義された共通部分のサブレイヤーを超えて動作するサービス固有の収束サブレイヤー（SSC）を定義します。このレイヤーは、帯域幅の効率的な輸送で異なる情報ストリームをエンコードするパケット形式と手順を指定します。名前が示すように、このサブ層は、これらのサービス固有の輸送の要素を実装しています。AAL2の共通部品サブレイヤーの定義は1つだけですが、このCPS層を実行するために定義された複数のSSC関数がある場合があります。AAL2仮想回路内の異なるCIDは、異なるSSCSを実行する場合があります。
The CPS-PKT format over AAL2 as defined in I.363.2:
i.363.2で定義されているように、AAL2を介したCPS-PKT形式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| + + + + |
| CID + LI + UUI + HEC + CPS-INFO |
| + + + + |
| + + + + |
| (8) + (6) + (5) + (5) + (45/64 * 8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The size of the fields denote bit-width
注：フィールドのサイズはビット幅を示します
The Channel ID (CID) identifies the sub-stream within the AAL2 connection. The Length indication (LI) indicates the length of the CPS-INFO payload. The User-to-User Indication (UUI) carries information between the SSCS/Application running above the CPS. The SSSAR sub-layer as defined in I.366.1 uses the following code points:
チャネルID（CID）は、AAL2接続内のサブストリームを識別します。長さの表示（LI）は、CPS-INFOペイロードの長さを示します。ユーザーからユーザーへの表示（UUI）は、CPSの上で実行されているSSC/アプリケーション間の情報を伝達します。I.366.1で定義されているSSSARサブレイヤーは、次のコードポイントを使用します。
UUI Code-point Packet Content
++++++++++++++ ++++++++++++++
0-26 Framed mode data, final packet.
0-26フレームモードデータ、最終パケット。
27 Framed mode data, more to come.
27フレームモードデータ、今後さらに。
This proposal uses two UUI code-points as follows:
この提案では、次の2つのUUIコードポイントを使用しています。
UUI Code-point Packet Content
++++++++++++++ ++++++++++++++
27 non-final packet.
27非ファイナルパケット。
26 final packet.
26最終パケット。
The CPS-PDU format over AAL2 as defined in I.363.2:
i.363.2で定義されているように、AAL2を介したCPS-PDU形式：
+-+-+-+~+~+-+-+
|CPS| CPS-INFO|
|PKT| |
|HDR| |
+-+-+-+~+~+-+-+
| CPS-PKT |
| +-+-+-+~+~+-+-+
|CPS| CPS-INFO|
| |PKT| |
|HDR| |
| +-+-+-+~+~+-+-+
CPS-PKT
| | +-+-+-+~+~+-+-+
|CPS| CPS-INFO|
| | |PKT| |
|HDR| |
| | +-+-+-+~+~+-+-+
CPS-PKT
V V V V
+-+-+-+-+-+-+-+~+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cell | | | |
Header | STF | CPS-PDU Payload | PAD |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
Note: The size of the fields denote bitwidth
注：フィールドのサイズは、bit幅を示します
The CPS-PDU format is used to carry one or more CPS-PKT's multiplexed on a single CPS-PDU. The CPS header contains enough information to identify the CPS packets within a CPS-PDU. In the event of cell loss, the STF field is used to find the first CPS-PKT in the current cell.
CPS-PDU形式は、単一のCPS-PDUで1つ以上のCPS-PKTの多重化を携帯するために使用されます。CPSヘッダーには、CPS-PDU内のCPSパケットを識別するのに十分な情報が含まれています。細胞損失の場合、STFフィールドは現在の細胞で最初のCPS-PKTを見つけるために使用されます。
PPP encapsulation over AAL2 uses the AAL2 CPS with no change.
AAL2上のPPPカプセル化は、AAL2 CPSを使用して変更せずに使用します。
Some PPP encapsulated protocols such as RTP header compression require that the link layer provide packet error detection. Because of this, PPP over AAL2 defines a 16-bit CRC that is used along with the SSSAR sub-layer of I.366.1 to provide packet error detection. The encapsulation format is described below.
RTPヘッダー圧縮などの一部のPPPカプセル化プロトコルでは、リンクレイヤーがパケットエラー検出を提供する必要があります。このため、AAL2のPPPは、I.366.1のSSSARサブレイヤーとともに使用される16ビットCRCを定義し、パケットエラー検出を提供します。カプセル化形式については、以下に説明します。
6.2.1 PPP Payload Encapsulation Over AAL2 with 16-bit CRC (CRC-16).
6.2.1 16ビットCRC（CRC-16）を使用したAAL2を介したPPPペイロードカプセル化。
The payload encapsulation of PPP appends a two byte CRC to each PPP frame before using the SSSAR layer to send the PPP packet as a series of AAL2 frames.
PPPのペイロードカプセル化は、SSSARレイヤーを使用してPPPパケットを一連のAAL2フレームとして送信する前に、各PPPフレームに2バイトCRCを追加します。
The format of a PPP over AAL2 packet is shown in the diagram below. Note that the diagram below shows the payload encapsulation when the packet is not segmented (UUI=26). When the PPP packet is segmented, the PPP Protocol ID, Information field, and CRC-16 fields will be split across multiple SSSAR frames. In this case, the UUI field will be set to 27 for all frames except the last frame. In the last frame, the UUI field will be set to 26.
AAL2パケット上のPPPの形式を以下の図に示します。下の図は、パケットがセグメント化されていない場合のペイロードカプセル化を示していることに注意してください（UUI = 26）。PPPパケットがセグメント化されると、PPPプロトコルID、情報フィールド、およびCRC-16フィールドが複数のSSSARフレームに分割されます。この場合、UUIフィールドは、最後のフレームを除くすべてのフレームに対して27に設定されます。最後のフレームでは、UUIフィールドは26に設定されます。
Payload Encapsulation
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| + + + + + + |
| CID + LI + UUI + HEC + Protocol + + |
| + + + + ID + Information + CRC-16 |
| + + + + + + |
| (8) + (6) + (5) + (5) + (8/16) + + (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The size of the fields denote bit-width
注：フィールドのサイズはビット幅を示します
The algorithms used for computing and verifying the CRC-16 field are identical to the algorithms specified for the Frame Check Sequence (FCS) field in Q.921 [13]. The algorithms from Q.921 are included in this section for ease of access.
CRC-16フィールドの計算と検証に使用されるアルゴリズムは、Q.921 [13]のフレームチェックシーケンス（FCS）フィールドに指定されたアルゴリズムと同一です。Q.921のアルゴリズムは、アクセスを容易にするためにこのセクションに含まれています。
The CRC-16 field is filled with the value of a CRC calculation which is performed over the contents of the PPP packet, including the PPP Protocol ID and the information field. The CRC field shall contain the ones complement of the sum (modulo 2) of:
CRC-16フィールドは、PPPプロトコルIDや情報フィールドを含むPPPパケットの内容に対して実行されるCRC計算の値で満たされています。CRCフィールドには、次の合計（Modulo 2）の補体が含まれます。
1) the remainder of x^k (x^15 + x^14 + ... + x + 1) divided (modulo
2) by the generator polynomial, where k is the number of bits of
the information over which the CRC is calculated; and
2) the remainder of the division (modulo 2) by the generator polynomial of the product of x^16 by the information over which the CRC is calculated.
2) x^16の積の発電機多項式による分裂の残り（Modulo 2）は、CRCが計算される情報によるものです。
The CRC-16 generator polynomial is:
CRC-16ジェネレーター多項式は次のとおりです。
G(x) = x^16 + x^12 + x^5 + 1
The result of the CRC calculation is placed with the least significant bit right justified in the CRC field.
CRC計算の結果は、CRCフィールドで正当化された最小の右に配置されます。
As a typical implementation at the transmitter, the initial content of the register of the device computing the remainder of the division is preset to all "1"s and is then modified by division by the generator polynomial (as described above) on the information over which the CRC is to be calculated; the ones complement of the resulting remainder is put into the CRC field.
送信機での典型的な実装として、デバイスのレジスタの初期コンテンツは、分割の残りの部分を計算することですべての「1」にプリセットされ、その後、ジェネレーター多項式（上記のように）によって分割によって変更されます。CRCは計算されます。結果の残りを補完するものは、CRCフィールドに配置されます。
As a typical implementation at the receiver, the initial content of the register of the device computing the remainder of the division is preset to all "1"s. The final remainder, after multiplication by x^16 and then division (modulo 2) by the generator polynomial of the serial incoming PPP packet (including the Protocol ID, the information and the CRC fields), will be 0001110100001111 (x^15 through x^0, respectively) in the absence of transmission errors.
受信機での典型的な実装として、デバイスのレジスタの初期コンテンツは、部門の残りの部分をすべての「1」にプリセットします。x^16による乗算後、次に分割後（モジュロ2）の最終的な残りは、シリアル着信PPPパケット（プロトコルID、情報、CRCフィールドを含む）の発電機多項式によるものです。^0、それぞれ）送信エラーがない場合。
An implementation of PPP over AAL2 MAY use a single AAL2 Channel Identifier (CID) or multiple CIDs for transport of all PPP packets. In order for the endpoints of a PPP session to work with AAL2, they MUST both agree on the number, SSCS mapping, and values of AAL2 CIDs that will be used for a PPP session. The values of AAL2 CIDs to be used for a PPP session MAY be obtained from either static provisioning in the case of a dedicated AAL2 connection (PVC) or from Q.2630.2 [7] signaling in the case of an AAL2 switched virtual circuit (SPVC or SVC).
AAL2を介したPPPの実装では、すべてのPPPパケットの輸送に単一のAAL2チャネル識別子（CID）または複数のCIDを使用できます。PPPセッションのエンドポイントがAAL2で動作するためには、PPPセッションに使用されるAAL2 CIDの数、SSCマッピング、および値に同意する必要があります。PPPセッションに使用されるAAL2 CIDの値は、専用AAL2接続（PVC）の場合の静的プロビジョニングまたはQ.2630.2 [7]の場合、AAL2スイッチ付き仮想回路の場合のシグナル伝達から取得できます。またはSVC）。
Using this proposal it is possible to support the use of conventional AAL2 in CIDs that are not used to support PPP over AAL2. This proposal allows the co-existence of multiple types of SSCS function within the same AAL2 VCC.
この提案を使用すると、AAL2を介してPPPをサポートするために使用されていないCIDでの従来のAAL2の使用をサポートすることができます。この提案により、同じAAL2 VCC内の複数のタイプのSSC関数の共存が可能になります。
PPP operation with AAL2 will perform basic PPP encapsulation with the PPP protocol ID. A 16-bit CRC is calculated as described above and appended to the payload. The SSSAR sub-layer of AAL2 is used for transport.
AAL2を使用したPPP操作は、PPPプロトコルIDを使用して基本的なPPPカプセル化を実行します。16ビットCRCは、上記のように計算され、ペイロードに追加されます。AAL2のSSSARサブレイヤーは、輸送に使用されます。
Applications implementing PPP over AAL2 MUST meet all the requirements of PPP [1].
AAL2にPPPを実装するアプリケーションは、PPPのすべての要件を満たす必要があります[1]。
This section describes an example implementation of how PPP can be encapsulated over AAL2. The example shows two application stacks generating IP packets that are sent to the same interface running PPP/AAL2. One Application stack is generating RTP packets and another application is generating IP Datagrams. The PPP/AAL2 interface shown in this example is running an RFC 2508 compliant version of RTP header compression.
このセクションでは、AAL2を介してPPPをカプセル化する方法の実装の例について説明します。この例は、PPP/AAL2を実行している同じインターフェイスに送信されるIPパケットを生成する2つのアプリケーションスタックを示しています。1つのアプリケーションスタックはRTPパケットを生成し、別のアプリケーションはIPデータグラムを生成することです。この例に示されているPPP/AAL2インターフェイスは、RFC 2508準拠バージョンのRTPヘッダー圧縮を実行しています。
Here are the paths an Application packet can take in this implementation:
この実装でアプリケーションパケットが取ることができるパスは次のとおりです。
+---+---+---+---+--+ +
| Application A | |
+---+---+---+---+--+ |
| RTP | |
+---+---+---+---+--+ +---+---+---+---+---+ Application
| UDP | | Application B | |
+---+---+---+---+--+ +---+---+---+---+---+ |
| IP | | IP | |
+---+---+---+---+--+ +---+---+---+---+---+ +
| |
+---------------+------------+
|
|
+---+---+---+---+---+--+ +
| Compression Filter | |
+---+---+---+---+---+--+ |
| |
| |
+---------+-----------+ |
| | |
RTP | | Non-RTP |
Packets V | Packets |
+---+---+---+---+---+---+ | |
| CRTP | | |
+---+---+---+---+---+---+---+---+---+---+---+---+ Transport
| PPP | |
+---+---+---+---+---+---+---+---+---+---+---+---+ |
| |
+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |
| Segmentation (SSSAR) | |
+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |
+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |
| AAL2 CPS | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |
| ATM Layer | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ +
In the picture above, application A is an RTP application generating RTP packets. Application B is an IP application generating IP datagrams. Application A gathers the RTP data and formats an RTP packet. Lower level layers of application A add UDP and IP headers to form a complete IP packet. Application B is generating datagrams to the IP layer. These datagrams may not have UDP or RTP headers.
上の写真では、アプリケーションAはRTPパケットを生成するRTPアプリケーションです。アプリケーションBは、IPデータグラムを生成するIPアプリケーションです。アプリケーションAはRTPデータを収集し、RTPパケットをフォーマットします。アプリケーションの低レベルのレイヤーAを追加して、IPヘッダーを追加して、完全なIPパケットを形成します。アプリケーションBは、IPレイヤーにデータグラムを生成しています。これらのデータグラムには、UDPまたはRTPヘッダーがない場合があります。
In the above picture, a protocol stack is configured to apply CRTP/PPP/AAL2 compression on an interface to a destination host. All packets that are sent to this interface will be tested to see if they can be compressed using RTP header compression. As packets appear at the interface, they will be tested by a compression filter to determine if they are candidates for header compression. If the compression filter determines that the packet is a candidate for compression, the packet will be sent to the CRTP compressor. If the packet is not a candidate for compression, it will be sent directly to the PPP layer for encapsulation as an IP packet encapsulated in PPP.
上記の写真では、宛先ホストにインターフェイスにCRTP/PPP/AAL2圧縮を適用するようにプロトコルスタックが構成されています。このインターフェイスに送信されるすべてのパケットは、RTPヘッダー圧縮を使用して圧縮できるかどうかを確認するためにテストされます。インターフェイスにパケットが表示されると、圧縮フィルターでテストされ、ヘッダー圧縮の候補かを判断します。圧縮フィルターがパケットが圧縮の候補であると判断した場合、パケットはCRTPコンプレッサーに送信されます。パケットが圧縮の候補でない場合、PPPにカプセル化されたIPパケットとしてカプセル化のためにPPPレイヤーに直接送信されます。
The destination UDP port number and packet length are examples of criteria that may be used by the compression filter to select the interface.
宛先UDPポート番号とパケット長は、圧縮フィルターがインターフェイスを選択するために使用できる基準の例です。
In this example, packets from application A will be passed to the CRTP compressor which then hands the compressed packet to the PPP layer for encapsulation as one of the compressed header types of CRTP. The PPP layer will add the appropriate CRTP payload type for the compressed packet.
この例では、アプリケーションAのパケットがCRTPコンプレッサーに渡され、圧縮されたパケットをPPPレイヤーに渡して、CRTPの圧縮ヘッダータイプの1つとしてカプセル化します。PPPレイヤーは、圧縮パケットに適切なCRTPペイロードタイプを追加します。
Packets from application B will be sent directly to the PPP layer for encapsulation as an IP/PPP packet. The PPP layer will add the PPP payload type for an IP packet encapsulated in PPP.
アプリケーションBのパケットは、IP/PPPパケットとしてカプセル化するためにPPPレイヤーに直接送信されます。PPPレイヤーは、PPPにカプセル化されたIPパケットのPPPペイロードタイプを追加します。
PPP packets are then segmented using I.366.1 segmentation with SSSAR.
PPPパケットは、SSSARを使用したi.366.1セグメンテーションを使用してセグメント化されます。
The resulting AAL2 frame mode PDU is passed down as a CPS SDU to the CPS Layer for multiplexing accompanied by the CPS-UUI and the CPS-CID. The CPS Layer multiplexes the CPS-PKT onto a CPS-PDU. CPS-PDUs are passed to the ATM layer as ATM SDUs to be carried end-to-end across the ATM network.
結果のAAL2フレームモードPDUは、CPS-UUIおよびCPS-CIDを伴う多重化のためにCPS SDUとしてCPS SDUとして渡されます。CPS層は、CPS-PKTをCPS-PDUにマルチプレックスします。CPS-PDUは、ATM SDUSとしてATM層に渡され、ATMネットワーク全体でエンドツーエンドが届きます。
At the receiving end, the ATM SDU's arrive and are passed up to the AAL2 CPS. As the AAL2 CPS PDU is accumulated, complete CPS-PKT's are reassembled by the SSSAR SSCS. Reassembled packets are checked for errors using the CRC algorithm.
受信側では、ATM SDUが到着し、AAL2 CPSに渡されます。AAL2 CPS PDUが蓄積されると、完全なCPS-PKTはSSSAR SSCによって再組み立てされます。再構築されたパケットは、CRCアルゴリズムを使用してエラーをチェックします。
At this point, the PPP layer on the receiving side uses the PPP payload type to deliver the packet to either the CRTP decompressor or the IP layer depending on the value of the PPP payload type.
この時点で、受信側のPPPレイヤーは、PPPペイロードタイプを使用して、PPPペイロードタイプの値に応じてCRTP分解器またはIPレイヤーにパケットを配信します。
By default, PPP over AAL2 will use the 16 bit CRC encapsulation for all packets.
デフォルトでは、AAL2のPPPは、すべてのパケットに16ビットCRCカプセル化を使用します。
The default Maximum-Receive-Unit (MRU) is 1500 bytes.
デフォルトの最大receive-unit（MRU）は1500バイトです。
This memo defines mechanisms for PPP encapsulation over ATM. There is an element of trust in any encapsulation protocol: a receiver should be able to trust that the sender has correctly identified the protocol being encapsulated and that the sender has not been spoofed or compromised. A receiver should also be able to trust that the transport network between sender and receiver has not been compromised.
このメモは、ATM上のPPPカプセル化のメカニズムを定義します。カプセル化プロトコルには信頼の要素があります。受信者は、送信者がカプセル化されているプロトコルを正しく特定し、送信者がスプーフィングまたは侵害されていないことを信頼できるはずです。また、受信者は、送信者と受信機の間の輸送ネットワークが損なわれていないことを信頼できるはずです。
A PPP session that runs over an ATM Virtual Circuit must follow the PPP link operation state machine described in RFC 1661 [1]. This state machine includes the ability to enforce the use of an authentication phase using the PAP/CHAP authentication protocols before any network layer packets are exchanged. Using PPP level authentication, a PPP receiver can authenticate a PPP sender.
ATM仮想回路を介して実行されるPPPセッションは、RFC 1661 [1]に記載されているPPPリンク操作ステートマシンに従う必要があります。この状態マシンには、ネットワークレイヤーパケットが交換される前に、PAP/Chap認証プロトコルを使用して認証フェーズの使用を実施する機能が含まれています。PPPレベル認証を使用して、PPPレシーバーはPPP送信者を認証できます。
System security may also be compromised by the attacks of the ATM transport network itself. The ATM Forum has published a security framework [11] and a security specification [12] that define procedures to guard against common threats to an ATM transport network.
また、システムセキュリティは、ATM輸送ネットワーク自体の攻撃によって侵害される場合があります。ATMフォーラムは、ATM輸送ネットワークに対する一般的な脅威から守る手順を定義するセキュリティフレームワーク[11]とセキュリティ仕様[12]を公開しています。
PPP level authentication does not guard against man in the middle attacks. These attacks could occur if an attacker was able to compromise the security infrastructure of an ATM switching network. Applications that require protection against threats to an ATM switching network are encouraged to use authentication headers, or encrypted payloads, and/or the ATM-layer security services described in [12].
PPPレベル認証は、中間攻撃で人間を守らない。これらの攻撃は、攻撃者がATMスイッチングネットワークのセキュリティインフラストラクチャを損なうことができた場合に発生する可能性があります。ATMスイッチングネットワークへの脅威に対する保護を必要とするアプリケーションは、[12]に記載されている認証ヘッダー、または暗号化されたペイロード、および/またはATMレイヤーセキュリティサービスを使用することをお勧めします。
When PPP over AAL2 is used on a set of CIDs in a virtual connection, there may be other non PPP encapsulated AAL2 CIDs running on the same virtual connection. Because of this, an end point cannot assume that the PPP session authentication and related security mechanisms also secure the non PPP encapsulated CIDs on that same virtual connection.
仮想接続のCIDのセットでAAL2を超えるPPPが使用されると、同じ仮想接続で実行されている他の非PPPカプセル化AAL2 CIDがある場合があります。このため、エンドポイントは、PPPセッション認証と関連するセキュリティメカニズムが、同じ仮想接続で非PPPカプセル化されたCIDを保護することを想定することはできません。
The authors would like to thank Rajesh Kumar, Mike Mclaughlin, Pietro Schicker, James Carlson and John O'Neil for their contributions to this proposal.
著者は、この提案への貢献について、Rajesh Kumar、Mike Mclaughlin、Pietro Schicker、James Carlson、John O'Neilに感謝したいと思います。
[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] Gross, G., Kaycee, M., Li, A., Malis, A. and J. Stephens, "PPP over AAL5", STD 51, RFC 2364, July 1998.
[2] Gross、G.、Kaycee、M.、Li、A.、Malis、A。、およびJ. Stephens、「Ppp over AAL5」、STD 51、RFC 2364、1998年7月。
[3] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[3] Casner、S。およびV. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[4] International Telecommunications Union, "BISDN ATM Adaptation layer specification: Type 2 AAL(AAL2)", ITU-T Recommendation I.363.2, September 1997.
[4] International Telecommunications Union、「Bisdn ATM適応層の仕様：タイプ2 AAL（AAL2）」、ITU-T推奨I.363.2、1997年9月。
[5] International Telecommunications Union, "Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2", ITU-T Recommendation I.366.1, June 1998.
[5] International Telecommunications Union、「AAL Type 2のセグメンテーションおよびサービス固有の収束サブレーヤー」、ITU-T推奨I.366.1、1998年6月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] ITU-T, "ITU-T RECOMMENDATION Q.2630.2", December 2000.
[7] ITU-T、「ITU-Tの推奨Q.2630.2」、2000年12月。
[8] Pazhyannur, R, Ali, I. and C. Fox, "PPP Multiplexing", RFC 3153, August 2001.
[8] Pazhyannur、R、Ali、I。およびC. Fox、「PPP Multiplexing」、RFC 3153、2001年8月。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[9] Schulzrinne、H.、Casner、S.、Frederick、R。and V. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[10] Thompson, B., Koren, T. and B. Buffam, "Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2", RFC 3337, December 2002.
[10] Thompson、B.、Koren、T。およびB. Buffam、「非同期転送モード適応レイヤー2を超えるPPPのクラス拡張」、RFC 3337、2002年12月。
[11] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-0096.000, February 1998.
[11] ATMフォーラム、「ATMセキュリティフレームワークバージョン1.0」、AF-SEC-0096.000、1998年2月。
[12] The ATM Forum, "ATM Security Specification v1.1", af-sec-0100.002, March 2001.
[12] ATMフォーラム、「ATMセキュリティ仕様v1.1」、AF-SEC-0100.002、2001年3月。
[13] International Telecommunications Union, ISDN User-Network Interface-Data Link Layer Specification, ITU-T Recommendation Q.921, March 1993.
[13] International Telecommunications Union、ISDNユーザーネットワークインターフェイスDATAリンクレイヤー仕様、ITU-T推奨Q.921、1993年3月。
Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ブルース・トンプソン・シスコ・システムズ、170ウェスト・タスマン・ドライブ・サンノゼ、カリフォルニア95134 USA
Phone: +1 408 527-0446
EMail: brucet@cisco.com
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Tmima Koren Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 408 527-6169
EMail: tmima@cisco.com
Bruce Buffam Seaway Networks One Chrysalis Way, Suite 300, Ottawa, Canada K2G-6P9
ブルースバッファムシーウェイネットワークワンクリサリスウェイ、スイート300、オタワ、カナダK2G-6p9
Phone: +1 613 723-9161
EMail: bruce@seawaynetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。