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)
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.
著作権（C）インターネット協会（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].
ATM AAL5アダプテーション層を使用した場合AAL5上のPPP [2] 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上PPP [4]複数PPPペイロードは、ATMセルのセットに多重化されることを可能にするためにAAL2共通部サブレイヤ（CPS）を使用することによって、小さなパケットトランスポートのためのAAL5上のPPPの帯域幅効率の問題に対処します。
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].
キーワードは、REQUIREDは、、、、、MAYを推奨、オプション、彼らは、この文書に表示されたときに、で説明したように解釈されるすべきでないないものとものとしてはなりませんしなければならない[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層内[1] LCPステートマシンへの「アップ」と「ダウン」イベントを提供します。
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 [5] AALタイプ2用SSSAR副層をAAL2 CPSを使用して輸送することができるフレームにセグメントPPPパケットに使用されるサービス固有のセグメンテーションとリアセンブリサブレイヤ（SSSAR）を使用してカプセル化を定義します。 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パケットの輸送のための一つ以上の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を使用して音声トランスポート[9] RTPヘッダ圧縮[3]が使用される用途において最も重要です。そのような音声伝送などのアプリケーションでは、帯域幅の効率と低遅延の両方が非常に重要です。
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のための正当化を提供します。二つのカプセル化フォーマットはここで検討する。PPPMUXとAAL5上のPPP [2]、およびPPP [8] AAL5上。
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.
この提案は、ATM AAL2 [4]よりもむしろAAL5 PPPのためのトランスポートとして使用します。 AAL2 CPSと共にSSSARは、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機能を使用して、1つ以上のATMセルに多重化複数PPPフレームによって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及びフレームはATM仮想回線を介して送信されるセルパディングのオーバーヘッドを低減するPPP / AAL2使用多重化の両方。しかし、PPP / AAL2の帯域幅の使用は、一般的にPPP / PPPMUX / AAL5が使用する帯域幅よりも良くなります。 PPP / PPPMUX / AAL5における多重化フレームが常に送信される前にAAL5フレーム内にカプセル化する必要があるためです。このカプセル化はAAL5トレーラの追加の8つのバイトはPPPMUXカプセル化に追加させます。 AAL5トレーラの8つのバイトに加えて、PPPMUXはAAL5 PADの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層が多重化されることができるCPSペイロード一連の個々のPPPフレームを処理します。限りCPS TIMER_CUが満了する前に、PPPフレームがCPS層に到達するように、CPS層から来る全てのATMセルが充填されます。これらの条件下では、PPP / AAL2は、それに関連付けられたパッドを持っていません。 AAL2 CPS機能が生成すべきパッドを引き起こさない場合は、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層は、PPPペイロードを抽出することができる前に、したがって、PPPMUX / AAL5受信機は、ATMレイヤから完全なAAL5フレームを再構築しなければなりません。最大PPP多重化効率を導出するために、多くのPPPペイロードは一緒に多重化することができます。これは、多くのATMセルに多重化されたフレームのサイズを増大させます。これらのATMセルの1が失われた場合、全体PPPMUXパケットが破棄されます。完全なフレームが逆PPPは、次に発生するデマルチプレクサPPP多重層に渡される前に、フルフレームがアセンブルされるまで、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関数の定義で、多重化ペイロードはすぐにそれを受信したとして抽出されます。 AAL2多重フレームの多くのペイロードは、多重化ストリームからペイロードを削除する前に受信されるまで、CPS受信機は待機しません。同じ利点はまた、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このAALタイプは、低レート、遅延に敏感なアプリケーションにおける短い可変長パケットの帯域幅効率的な伝送を提供するATMアダプテーションレイヤのタイプ2を指定します。複数のAALタイプ2のユーザの情報ストリームは、単一のATM接続で支持することができます。それはATMレイヤへのインタフェースを実装し、複数のSSCS層によって共有されているので、副層のための唯一の定義があります。
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で定義された共通部分サブ層上に動作サービス特定収束副層（SSCS）を定義します。この層は、帯域幅の効率的な輸送に異なる情報ストリームを符号化するためにパケットフォーマットと手順を指定します。名前が示すように、このサブレイヤーは、サービス特定のトランスポートのこれらの要素を実現します。 AAL2の一般的なパートサブレイヤの唯一の定義がありますが、このCPS層の上に実行するように定義された複数のSSCS機能があることができます。 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の上方実行SSCS /アプリケーション間で情報を運びます。 I.366.1で定義されるようSSSAR副層は、次のコードポイントを使用します。
UUI Code-point Packet Content ++++++++++++++ ++++++++++++++
UUIコードポイントのパケット内容++++++++++++++ ++++++++++++++
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 ++++++++++++++ ++++++++++++++
UUIコードポイントのパケット内容++++++++++++++ ++++++++++++++
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
注：フィールドのサイズは、ビット幅を示し、
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上の一つ以上の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を定義します。カプセル化フォーマットを以下に説明します。
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のペイロードカプセル化はAAL2フレームのシリーズとしてPPPパケットを送信するSSSAR層を使用する前に、各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.
PPP AAL2上のパケットのフォーマットは、次の図に示されています。図は以下のパケットがセグメント化されていないペイロードカプセル化（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フィールドは、合計（モジュロ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
1）ここで、kは、CRCがその上情報のビット数である生成多項式によるX ^ K（x ^ 15 + X ^ 14 + ... + X + 1）分割（モジュロ2）の残りの部分を計算;そして
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）CRCが計算され、その上情報によってX ^ 16の生成物の生成多項式除算の剰余（モジュロ2）。
The CRC-16 generator polynomial is:
CRC-16の生成多項式は次のようになります。
G(x) = x^16 + x^12 + x^5 + 1
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」にプリセットされています。 （プロトコルID、情報及びCRCフィールドを含む）シリアル入来PPPパケットの生成多項式によってX ^ 16、次いで分割（モジュロ2）による乗算後の最終残りは、Xを介して0001110100001111（X ^ 15であろう^ 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を使用するかもしれ。 AAL2で動作するようにPPPセッションのエンドポイントのために、彼らは両方とも、PPPセッションのために使用される数、SSCSマッピング、およびAAL2 CIDの値に同意しなければなりません。 [7] AAL2の場合にシグナリングPPPセッションのために使用されるAAL2 CIDの値専用AAL2接続（PVC）の場合、またはQ.2630.2から静的プロビジョニングから得ることができる、仮想回線（SPVCを切り替えますまたは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内SSCS機能、複数の種類の共存を可能にします。
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.
このセクションでは、PPPがAAL2上でカプセル化することができる方法の実装例を示します。例は、PPP / AAL2を実行し、同じインタフェースに送信されるIPパケットを生成する2つのアプリケーションスタックを示します。一つのアプリケーション・スタックは、RTPパケットを生成していると、別のアプリケーションは、IPデータグラムを生成しています。この例に示すPPP / AAL2インターフェースは、RTPヘッダ圧縮のRFC 2508に準拠したバージョンを実行しています。
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パケットを形成するために、UDPおよび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圧縮機に渡されます。 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層にCPS SDUとして渡されます。 CPSレイヤ多重CPS-PDUへのCPS-PKT。 ATM SDUがエンドツーエンドのATMネットワーク上を搬送されるようにCPS-PDUは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 SSCSによって再構築されます。再構成されたパケットは、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層がCRTP減圧装置またはPPPペイロードタイプの値に応じて、IP層のいずれかにパケットを配信するためにPPPペイロードタイプを使用します。
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.
デフォルトの最大受信・ユニット（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で説明PPPリンクの動作ステートマシンに従う必要があります[1]。この状態マシンは、任意のネットワーク層パケットが交換される前に、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交換ネットワークへの脅威に対する保護を必要とするアプリケーションは、認証ヘッダーを使用することを奨励、またはペイロードを暗号化し、および/またはATMレイヤセキュリティサービスは、[12]で説明されています。
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.
AAL2上PPP仮想接続にCIDのセットで使用する場合、他の非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氏、マイク・マクローリン、ピエトロSchicker、ジェームズ・カールソンとジョン・オニールに感謝したいと思います。
[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]グロス、G.、Kaycee、MはLi、A.、Malis、A.およびJ.スティーブンス、 "AAL5上PPP"、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.ヤコブソンを、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[4] International Telecommunications Union, "BISDN ATM Adaptation layer specification: Type 2 AAL(AAL2)", ITU-T Recommendation I.363.2, September 1997.
[4]国際電気通信連合、 "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]国際電気通信連合、「AALタイプ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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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、アリ、I.およびC.フォックス、 "PPP多重化"、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.、フレデリック、R.と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]トンプソン、B.、コレン、T.とB. Buffam、RFC 3337 "PPP非同期オーバー転送モードアダプテーションレイヤ2のクラスの拡張"、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]国際電気通信連合、ISDNユーザ・ネットワーク・インターフェイス・データリンク層仕様、ITU-T勧告Q.921、1993年3月。
Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ブルース・トンプソンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408 527-0446 EMail: brucet@cisco.com
電話：+1 408 527-0446 Eメール：brucet@cisco.com
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Tmimaコレンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408 527-6169 EMail: tmima@cisco.com
電話：+1 408 527-6169 Eメール：tmima@cisco.com
Bruce Buffam Seaway Networks One Chrysalis Way, Suite 300, Ottawa, Canada K2G-6P9
ブルース・Buffam水路網の一つクリサリス・ウェイ、スイート300、オタワ、カナダK2G-6P9
Phone: +1 613 723-9161 EMail: bruce@seawaynetworks.com
電話：+1 613 723-9161 Eメール：bruce@seawaynetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。