ネットワークの基礎講座

付属資料

RFC 2364 (PPP Over AAL5)邦訳版

PPPoAとは？

いわゆるSOHOや小企業では、一本のインターネットやアクセス回線を複数のユーザで共用しようと言うのが一般的であろう。特に最近はDSLサービスが高速で手軽なアクセス回線として拡大してきている（ケーブルモデムもブロードバンドインターネットアクセスの手段として普及が目覚しいが、これはPPPを使用していないのでここでは対象としていない）。

一般的なDSLではユーザ側に設置されるDSLモデムはイーサネット・ポートがついている。モデムはこの場合MAC層ブリッジとして機能する。つまりトラフィックを局舎(CO)またはリモートターミナル(RT)にあるDSL集合モデム(DSLAM)にATMのPVC（固定接続型仮想チャネル）を介して伝送する。すなわちDSL網はATMで構成されている。その先のISPへもそのままATMで接続されるか、フレーム・リレーやTDMなどで接続される。またこれから日本が先行して普及するであろうFTTHの場合も、宅内または近隣のゲートウエイ装置まではATMで構成されよう。

RFC 2364はATM網でのPPPを規定したものである。ATM網はご承知のように回線交換型の網であり、交換作業はATMスイッチ（交換機）が行う。AAL5はコネクション型データ・サービス用インターフェイス・レイヤである。AAL層は大きく2つのサブレイヤ、即ち下からセルの込みたて・分解の為のSAR(Segmentation and Reassembly Sublayer)と、融合層であるCPCS(Common Part Convergence Sublayer)から構成される。CPCSのフォーマットをどのようにPPPとして利用するかがPPPoAの内容である。

AAL5上のカプセル化に対しては、すでにRFC 1483(Multiprotocol Encapsulation over ATM Adaptation Layer 5: Obsoleted by 2684)に定められているので、このドキュメントを読む前にこれが理解されていることが好ましい。もちろん、ATMに関する基本的な知識も必要である。RFC 1483ではAAL5でコネクションレス型PDU(Protocol Data Unit)を運ぶ手段として2つのフォーマットを定めている。ひとつはLLCカプセル化で、複数のプロトコルをひとつのバーチャル・サーキットに載せるもので、IEEE802.2 LLC（論理リンク制御）を使う。もうひとつはVC多重化であり、プロトコル種別毎にバーチャル・サーキットを張るものである。RFC 2364はこの2つをサポートすることとしている。

1　概要(Introduction)

ATMのAAL5プロトコルは同じATM網に属する端局間でバーチャル・コネクション(virtual connections)を張るために設計されている。これらのコネクションでは、誤り検出を持つものの誤り訂正は行わないパケット伝送サービスがなされる。

一番多いPPP実装は、そのフレーミングのベースとしてISO 3309 HDLCを用いている[3]。

ATM網でポイント間接続を設定するときは、PPPはフレーミングのメカニズムとしてAAL5を使うことが出来る。

2　規約(Conventions)

MUST, MUST NOT, REQUIRED, SHALL, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONALなどのキーワードが本ドキュメントに現れた場合は、[10]で記されているごとく解釈されること。

3　AAL5レイヤのサービス・インターフェイス(AAL5 Layer Service Interface)

PPPレイヤはその下にあるATM AAL5レイヤ・サービスをビット同期のポイント対ポイント・リンクとして取扱う。このコンテキストに従えば、PPPリンクはATM AAL5のひとつのバーチャル・コネクションに対応する。このバーチャル・コネクションは、全2重で、ポイント対ポイントでなければならず[MUST]、また専用（云いかえれば永久、プロビジョニングつまりサービス設定時に設定される）または交換（デマンドによって設定される）のどちらであっても良い[MAY]。加えて、このPPP/AAL5サービス・インターフェイス境界は以下の要件を満たさねばならない[MUST]。

· インターフェイス・フォーマット(Interface Format) – このPPP/AAL5レイヤ境界は、AAL5レイヤにオクテット・サービス・インターフェイスを与える。サブオクテットの授受のプロビジョンはない。

· 伝送レート(Transmission Rate) – PPPレイヤは、伝送レートやあるいは下位のATMレイヤのトラフィック記述パラメタに関しては、何ら制限を課さない。

· 制御信号(Control Signals) – AAL5レイヤは、PPPレイヤに、何時そのバーチャル・コネクションのリンクが接続あるいは開放されたかを示す制御信号を提供しなければならない[MUST]。

· PPPレイヤ内のLCPステート・マシンへの“Down”イベント[1]。

4　マルチプロトコルのカプセル化(Multi-Protocol Encapsulation)

本仕様では文献[4]の「ATMアダプテーション・レイヤ5上のマルチプロトコルのカプセル化」(Multiprotocol Encapsulation over ATM Adaptation Layer 5)で記された原則、用語、およびフレーム構造を使用している。

本仕様の目的は[4]に既に標準化されているものをドキュメント化することではなく、[4]で記されたメカニズムが、如何にPPPをAAL5ベースのATM網にマッピングするのに使用するか、を規定するものである。[4]の第1章ではプロトコル・データ・ユニット(PDU: Protocol Data Unit)ペイロード・フィールドに乗っているデータのプロトコル・タイプを識別する2つのメカニズムを定義している。即ち、バーチャル・サーキット・ベースの多重化（プロトコル毎にバーチャル・サーキットを張る）、そしてひとつのバーチャル・サーキットに複数のプロトコルを載せる論理リンク制御(LLC: Logical Link Control)カプセル化である。最初の技術では、プロビジョニングあるいは制御プレーンの手続きを使って、ペイロード上のプロトコルのタイプがバーチャル・サーキット毎に黙示的に端間で合意される。LLCカプセル化の技術を使えば、PDUベースで組み込まれているペイロード・データの直前につくLLCヘッダにより(NLPID)、ペイロード上のプロトコルは明示的に識別される。

AAL5上でPPPペイロードを転送するときには、実装の際は：

1. 端点双方で相互設定またはネゴシエーションにより、第5章で記述されているバーチャル・サーキット多重方式がサポートされねばならない[MUST]。この技術を「VC多重化PPP」(VC-multiplexed PPP)と称する。

2. 端点双方で相互設定またはネゴシエーションにより、第6章で記述されているPVC上のLLCカプセル化PPPペイロード方式がサポートされねばならない[MUST]。この技術を「LLCカプセル化PPP」(LLC encapsulated PPP)と称する。

3. 交換型VCのセットアップにあたっては、実装はVC多重化PPPまたはLLCカプセル化PPPいずれかを相手に知らせるのに、Q.2931のAnnex C手順、ブロードバンド下位レイヤ・インターフェイス情報エレメント(Broadband Lower Layer Interface (B-LLI) information element)を使ってネゴシエートしなければならない[MUST]。この制御面の手順の詳細は、第7章に記されている。

実装がフレームリレー／ATM FRF.8 [7]サービス・インターワーキング・ユニット(service inter-working unit)を介してRFC 1973 [6]端点と接続している場合は、LLCカプセル化PPPを使用しなければならない[MUST]。フレームリレー／ATM FRF.8インターワーキング・ユニットはVC多重化PPPをサポートする要求が免除されている。この除外は、FR/ATM IWUが、AAL5上のPPP端点がRFC 1973端点と相互運用しているときに、FRF.8準拠を維持させるためである。

5　AAL5上のバーチャル・サーキット多重化PPP(Virtual Circuit Multiplexed PPP over AAL5)

AAL5のPDUフォーマットを図1に示す：

AAL5 CPCS-PDU Format

+-------------------------------+

| . |

| CPCS-PDU Payload |

| up to 2^16 - 1 octets) |

| . |

+-------------------------------+

| PAD ( 0 - 47 octets) |

+-------------------------------+ -------

| CPCS-UU (1 octet ) | ^

+-------------------------------+ |

| CPI (1 octet ) | |

+-------------------------------+CPCS-PDU Trailer

| Length (2 octets) | |

+-------------------------------| |

| CRC (4 octets) | V

+-------------------------------+ -------

Figure 1

共通部コンバージェンス・サブレイヤ(CPCS: Common Part Convergence Sub-layer) – PDUペイロード・フィールドは最大2^16-1オクテットのユーザ情報を含む。

PADフィールドはCPCS-PDUがきちんとATMセルに乗り、セル分割・組み立てサブレイヤ (SAR)で作られる最後の48オクテット・セルにてCPCS-PDUトレイラがきちんと右詰で収まるようにパッディングするためのものである。

CPCS-UU（ユーザ間表示）フィールドは、透過的にCPCSユーザ間情報を転送するために使われる。このフィールドは本ドキュメントに記されているマルチプロトコルATMカプセル化においては機能を持たないので、任意の値がセットできる。

共通部識別子(CPI: Common Part Indicator)は、CPCS-PDUトレイラを64ビットに揃える。あり得る更なる機能の付加は、ITU-Tの今後のスタディによる。端に64ビットにあわせるための目的に使われるときは、このフィールドは0x00にエンコードされねばならない[SHALL BE]。

長さフィールドはペイロード・フィールドの長さをオクテットで表示する。長さフィールドの最大値は65535オクテットである。放棄機能の為に長さフィールドを使うときは0x00がはいる。

CRCフィールドは、CRCフィールドそれ自身を除くCPCS-PDU全体を誤りから保護する。

VC多重化PPPフレームはCPCS-PDUで構成されねばならず[SHALL]、以下のように定義される：

+-------------+-------------+---------+

| Protocol ID | Information | Padding |

| 8/16 bits | | |

+-------------+-------------+---------+

Figure 3.2

これらのフィールドの各々は[1]に明確に定義されている。

6　 LLCカプセル化のAAL5上のPPP(LLC Encapsulated PPP Over AAL5)

LLCカプセル化のAAL5上のPPPはVC多重化のAAL5上のPPPの替りとなる技術である。

AAL5 CPCS-PDUのペイロード・フィールドは図3.3のようにエンコードされる。このダイヤグラムの関連するフィールドは：

1. LLC論理リンク・ヘッダ(LLC header)：ルーティングされたOSIのPDUの元SAPと宛先SAPを指定する為にエンコード(0xFE, 0xFE) された2バイトと、それに従う非数値情報(UI: Un-numbered Information)のフレームタイプ(0x03)。

2. PPPであることを示すネットワーク・レイヤ・プロトコル識別子(NLPID: Network Layer Protocol Identifier)(0xCF)。

3. 1もしくは2オクテットののいずれかのPPPプロトコル識別子フィールド。参考資料[1]参照のこと。

4. そのあとに続く図3.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

+-------------------------+ --------

| PAD ( 0 - 47 octets) |

+-------------------------+ --------

| CPCS-UU (1 octet ) | ^

+-------------------------+ |

| CPI (1 octet ) | |

+-------------------------+CPCS-PDU Trailer

| Length (2 octets) | |

+-------------------------| |

| CRC (4 octets) | V

+-------------------------+ --------

Figure 3.3

端点は同じバーチャル・コネクションをまたいだPPPに更に別のLLCカプセル化プロトコルを送るべく相互に設定されても良い[MAY]。しかしながら、該PPPセッション内でのアクティブなNCPを持つ如何なるプロトコルに属するパケットも送ってはならない[MUST NOT]。実装はパケットのスケジューリングを行い[SHOULD]、LLCカプセル化PPPと非PPPプロトコル双方をまとめたプロトコル・フローのQOSコミットメントに与える性能インパクトを最小限にしなければならない。

7　バンド外制御プレーン・シグナリング(Out-Of-Band Control Plane Signaling)

交換型バーチャル・サーキットAAL5コネクションを開始するときは、VC多重化PPP、またはLLCカプセル化PPP、またはその双方で、発呼側はSETUP（設定）メッセージで要求しなければならない[MUST]。発呼側がその双方で要求するときは、2つのB-LLIのIEは、優先させてたいものからの順でブロードバンド繰り返し表示子(BRI: Broadband Repeat Indicator) IEのなかにエンコードされる。着呼側の実装は、発呼側からの要求のなかでLLCカプセル化PPPを要求している到来呼が受理できなければならない[MUST]。着呼側の実装は、それがサポートしないカプセル化のみが要求されている呼設定要求を拒否しなければならない[MUST]。双方のプロトコル・カプセル化を要求する発呼側の実装は、LLCカプセル化PPPの使用がネゴシエート出来なければならない[MUST]。

PPPペイロードを運ぶ為のVC多重化の呼を開始するときは、ITU Q.2931 [9] B-LLIエレメントのユーザ情報レイヤ3プロトコル・フィールドは、ISO/IEC TR 9577 [5]を選択するようオクテット7にエンコードされる。この拡張オクテットは,PPP(0xCF)なる値のIPIを指定する。定義により、AAL5フレームのペイロード・フィールドの最初のバイト部分は、常にパケットが続くPPPヘッダである。

PPPペイロードを運ぶ為のLLCカプセル化の呼を開始するときは、ITU Q.2931 [9] B-LLIエレメントのユーザ情報レイヤ2プロトコル・フィールドは、LAN論理リンク制御(ISO/IEC 8802-2)を選択するようオクテット6にエンコードされる。事例として、RFC 1755[8] Appendix Aを参照のこと。定義により、AAL5フレームのペイロード・フィールドの最初のバイト部分は、NLPIDとPPPペイロードがあとに続くLLCヘッダを含むことになる。

8　自発的なPPPカプセル遷移の検出と復帰(Detection And Recovery From Unsolicited PPP Encapsulation Transitions)

バーチャル接続が状態を失うと、PPPカプセル化技術が一方向的にそして予期せぬうちにかかる遷移を介して変わってしまうことがあり得る。検出と復帰の手順が以下の状態遷移で定義されている：

VC多重化PPPのLLCカプセル化PPPへの変化

LLCカプセル化PPPのVC多重化PPPへの変化

LLCカプセル化PPPが使われているときは、LCPパケットの最初の6オクテットはfe-fe-03-cf-c0-21なるシーケンスになっている。このシーケンスがAAL5フレームの最初の6オクテットとなっている。VC多重化PPPの場合は,最初のLCPパケットはc0-21なるシーケンスを含む。このシーケンスがAAL5フレームの最初の2オクテットを構成する。LCP設定要求(LPC Configure-Request)パケットが受信され認識されたら、このPPPリンクはリンク確立(Link Establishment)のフェーズにはいる。

いったんPPPがネットワーク層プロトコル(Network-layer Protocol)のフェーズに入り、またPPPプロトコルのための特定のNCPを成功裏にネゴシエートした状態において、もしも[4]で定義された等価なデータ・カプセル化ではあるものの代替を使ったフレームが到来したときは、該PPPリンクは以下の事項を実施しなければならない[MUST]：

· SVCに対しては、ただちに事由コード111（プロトコル・エラー、指定されず protocol error, unspecified）でその呼をクリアする。

· PVCに対しては、アクティブなNCPsを外し、エラー・メッセージを作成し[SHOULD]、終了(Termination)状態に入り、無通知で全到来パケットを廃棄する。

この原則により、ピアが状態を失ったときに生ずる「ブラック・ホール」を防止する。PPPリンク設定、及び他のPPPネゴシエーション機能（認証など）を要求する実装においては、設定に失敗した場合は終了(Termination)の状態に入って良い[MAY]。

9　LPC設定オプション(LPC Configuration Options)

マジック・ナンバーLPC設定(Magic Number LPC configuration)が推奨され[RECOMMENDED]、プロトコル・フィールド圧縮(PFC: Protocol Field Compression)オプションは推奨されない[NOT RECOMMENDED]。実装は以下のオプションのいずれかも要求してはならず[MUST NOT]、かかるオプションの要求を拒絶しなければならない[MUST]。

· フィールド・チェック・シーケンス代替(Field Check Sequence (FCS) Altanatives)

· アドレス・制御フィールド圧縮(ACFC: Address-and-Control-Field-Compression)

· 非同期制御文字マップ(ACCM: Asynchronous-Control-Character-Map)

最大受信ユニット(MRU: Maximum-Receive-Unit)のオプションは、バーチャル・コネクションのトラフィック契約として関連指示に指定された最大CPCS-SDUサイズを超えるようなサイズでネゴシエートされてはならない[MUST NOT]。

ピア間で見た場合には、PPPリンクは複数の物理層区間をまたぐブリッジともなる。かかる各AAL5区間は、ブリッジ・コンバータにより、他の物理層区間に使われるLPCフレーミング・オプションとは独立して、LPCフレーミング・オプションが積極的にネゴシエートされねばならない[MUST]。

実装にあたっての注意：

ATM AAL5 PVCが”Stopped”の状態にあるとき、実装は設定要求(Configure-Requests)を待つことが推奨される[RECOMMENDED]。参考[1]の4.2節の”Stopped State”副節にある実装のオプションを参照のこと。

10　セキュリティの考察(Security Considerations)

一般に、ATM網はバーチャル・サーキット・ベースであるので、ネットワーク境界間の固定接続型VC(PVCs: Permanent Virtual Circuits)の公衆データ・ネットワーク・サービス提供者のネットワーク管理のもとでセキュリティは実質的に確保されている。ATMセルのルーティング・ミスに起因するセキュリティの漏れは無視できると考えられる。

公衆ATM網が交換型VC(SVCs: Switched Virtual Circuits)をサポートしている場合は、公衆電話回線(PTSN: Public Telephone Switched Network)による従来の音声帯域モデムのダイヤル・アップと類似したプロトコル・モデルとなる。インターネット・ダイヤルアップ・アクセスにすでに広く採用されていると同じPAP/CHAP認証プロトコルが有効である。従って、PPPオーバAAL5のセキュリティは、既存のインターネット・インフラストラクチャですでに確立されているセキュリティ事項と等価である。

より強度のセキュリティが必要なアプリケーションにあっては、認証ヘッダ、または暗号化ペイロード、及び／またはATM層のセキュリティ・サービスの使用が推奨される。

バーチャル・コネクション上でのLLCカプセル化PPPを使用しているときは、端点はPPPセッションの認証と関連したセキュリティの機構がまた同じバーチャル・コネクション上の他のLLCカプセル化のフローに対してもセキュリティを与えると考えてはいけない。

11　謝辞(Acknowledgements)

本設計は、ADSLフォーラムのパケット・モード作業グループ(ADSL Forum’s Packet Mode Working Group)での作業に基づく。これはW. Simpson氏のRFC 1973 “PPP in Frame Relay”に大きく影響を受けている。フローポイント社のPhil Rakity氏、マイクロソフト社のTim Kwok氏、そしてノーテル社のDavid Allan氏の建設的なレビューとコメントに特に感謝する。

12　参考(References)

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD

51, RFC 1661, July 1994.

[2] The ATM Forum, "Frame based User-to-Network Interface (FUNI)

Specification v2", af-saa-0088.000, May 1997.

[3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC

1662, July 1994.

[4] Heinanen, J., "Multiprotocol Interconnect over AAL5", RFC 1483,

July 1993.

[5] ISO/IEC DTR 9577.2, "Information technology -

Telecommunications and Information exchange between systems -

Protocol Identification in the network layer", 1995-08-16.

[6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.

[7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-

working Implementation Agreement", FRF.8, April 1995.

[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.

[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)

[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC 2119, March 1997.

13　議長と著者の連絡先

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

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

Phone: +1.908.580.4589

EMail: gmgross@lucent.com

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

Phone: +1.408.747.5051

EMail: 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

Phone: +1.617.279.1101

EMail: john@cayman.com