ロング リーチ イーサネット(LRE)とデジタル加入者線(xDSL) : PPPoE/PPPoA(PPP over Ethernet / PPP over ATM)

PPPoA ベースライン アーキテクチャ

2002 年 9 月 12 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 2 月 26 日) | フィードバック

目次


概要

この文書は、Point-to-Point Protocol over Asynchronous Transfer Mode(PPPoA)を使用したエンドツーエンドの Asymmetric Digital Subscriber Line(ADSL; 非対称デジタル加入者線)アーキテクチャについて説明しています。ほとんどの展開はブリッジ アーキテクチャに基づいていますが、最近 PPPoA の利用が急激に増えており、将来の ADSL 展開では PPPoA が大部分を占めると予想されます。

前提

ベースライン アーキテクチャは、コア バックボーンとして PPPoA を使用した高速なインターネット アクセスおよび企業アクセスを末端加入者に提供する必要性を前提としています。この文書では、現在最もよく使用されている Private Virtual Channel(PVC; プライベート仮想チャネル)方式に基づいてこのアーキテクチャを説明します。Switched Virtual Circuit(SVC; 相手先選択接続)を使用したアーキテクチャについては、他の文書で説明する予定です。

この文書は、既存の配備だけでなく、アーキテクチャの社内テストの結果にも基づいています。

この文書は、読者が「RFC1483 ブリッジ ベースライン アーキテクチャ」White Paper に記載されている Network Access Provider(NAP; ネットワーク アクセス プロバイダー)の設計上の考慮事項について理解していることを前提として記述されています。

テクノロジーの概要

Point-to-Point Protocol(PPP)(RFC 1331)は、ポイントツーポイント接続を通じて上位層プロトコルをカプセル化するための標準的な方法を提供します。PPP は、パケットの内容に関する情報を含む 16 ビットのプロトコル識別子によって High-Level Data Link Control(HDLC; 高レベル データリンク制御)パケット構造を拡張します。

パケットには次の 3 種類の情報が含まれます。

  • Link Control Protocol(LCP; リンク制御プロトコル)- リンク パラメータ、パケット サイズ、または認証タイプをネゴシエートします。

  • Network Control Protocol(NCP)- IP や IPX などの上位層プロトコルと、それらの制御プロトコル(IP の場合は IPCP)に関する情報が含まれます。

  • データを含むデータ フレーム。

PPP over ATM Adaptation Layer 5(AAL5; ATM アダプテーション レイヤ 5)(RFC 2364)はフレーム プロトコルとして AAL5 を使用します。これは PVC と SVC をどちらもサポートします。PPPoA は、最初は ADSL の一部として実装されました。RFC1483 に準拠し、Logical Link Control-Subnetwork Access Protocol(LLC/SNAP; 論理リンク制御/サブネットワーク アクセス プロトコル)または VC-Mux モードで動作します。Customer Premises Equipment(CPE; 顧客宅内機器)デバイスは、この RFC に基づいて PPP セッションをカプセル化し、ADSL ループおよび Digital Subscriber Line Access Multiplexer(DSLAM; デジタル加入者回線アクセス マルチプレクサ)を通じて伝送します。

PPPoA アーキテクチャの利点と欠点

PPPoA アーキテクチャは、ダイヤル モデルで使用される PPP の利点のほとんどを継承しています。いくつかの要点を次に示します。

利点

  • Password Authentication Protocol(PAP; パスワード認証プロトコル)または Challenge Handshake Authentication Protocol(CHAP)に基づくセッション単位での認証。認証によってブリッジ アーキテクチャのセキュリティ ホールが解消されるため、これは PPPoA の最大の利点といえます。

  • セッション単位でのアカウンティングが可能です。これにより、サービス プロバイダーは提供する各種サービスのセッション時間に基づいて加入者に課金できます。また、基本料金に対応する最小限のアクセス レベルを設定し、追加で使用されたサービスに応じて加入者に課金することもできます。

  • CPE での IP アドレスの保存。これにより、CPE で Network Address Translation(NAT; ネットワーク アドレス変換)を設定することが可能となるため、サービス プロバイダーは CPE 用に IP アドレスを 1 つ割り当てるだけで済みます。1 台の CPE の背後にいるユーザはすべて、1 つの IP アドレスを使用して互いに異なる宛先に到達できます。また、Network Access Provider/Network Services Provider(NAP/NSP; ネットワーク アクセス プロバイダー/ネットワーク サービス プロバイダー)における個々のユーザごとの IP 管理のオーバーヘッドが少なくなるとともに、IP アドレスの節約にもつながります。さらに、サービス プロバイダーでは、IP アドレスの小規模なサブネットを提供できるため、Port Address Translation(PAT; ポート アドレス変換)および NAT の制限を克服できます。

  • NAP/NSP では、企業ゲートウェイへの安全なアクセスを提供するために、PVC をエンドツーエンドで管理したり、レイヤ 3 ルーティングまたは Layer 2 Forwarding/Layer 2 Tunneling Protocol(L2F/L2TP)トンネルを使用したりする必要がありません。そのため、自社のビジネス モデルを拡張してホールセール サービスの販売に乗り出すことができます。

  • 個々の加入者のトラブルシューティング。NSP では、アクティブな PPP セッションに基づいて、接続している加入者と接続していない加入者を容易に識別できます。ブリッジ アーキテクチャの場合のようにグループ全体でトラブルシューティングを行う必要はありません。

  • NSP では、業界標準の Remote Authentication Dial-In User Service(RADIUS)サーバを使用して加入者ごとにアイドルおよびセッション タイムアウトを設定することにより、定員以上の利用者を加入させることができます。

  • 集約ルータで大量の PPP セッションを終端できる高度なスケーラビリティ。外部の RADIUS サーバを使用して、認証、認可、およびアカウンティングをユーザごとに処理できます。

  • Service Selection Gateway(SSG)での機能の最適な使用。

欠点

  • 1 つの Virtual Channel(VC; 仮想チャネル)上で CPE ごとに 1 つのセッションしか確立できません。ユーザ名とパスワードが CPE に設定されているため、特定の VC において CPE の背後にいるユーザがアクセスできるのは、1 つのサービス セットに限られます。ユーザごとに異なるサービス セットを選択することはできません。ただし、複数の VC を使用して、異なる VC 上で異なる PPP セッションを確立することは可能です。

  • CPE のセットアップが複雑になります。サービス プロバイダーのヘルプデスク担当者には、他のケースよりも豊富な知識が必要です。ユーザ名とパスワードは CPE に設定されているため、セットアップの変更は加入者または CPE ベンダーが行う必要があります。複数の VC を使用する場合は、設定がさらに複雑になります。ただし、この複雑さは、自動設定機能が今後リリースされれば解消されます。

  • サービス プロバイダーは、全加入者のユーザ名とパスワードを保存したデータベースを維持する必要があります。トンネルまたはプロキシ サービスを使用すれば、ドメイン名による認証が可能となり、ユーザ認証は企業ゲートウェイで行われます。そのため、サービス プロバイダーが維持するデータベースのサイズは小さくなります。

  • CPE に 1 つの IP アドレスが提供されていて、NAT/PAT が実装されている場合、ペイロードに IP 情報を埋め込む IPTV など、特定のアプリケーションが動作しません。また、IP サブネット機能を使用する場合は、CPE 用の IP アドレスも予約する必要があります。

PPPoA アーキテクチャの実装に関する考慮事項

PPPoA アーキテクチャを実装する際に考慮すべき要点を次に示します。

  • 現在および将来的にサービスを提供する加入者の数。これは必要な PPP セッション数に影響を与えます。

  • PPP セッションがサービス プロバイダーの集約ルータで終端するか、あるいは他の企業ゲートウェイまたは Internet Service Provider(ISP; インターネット サービス プロバイダー)に転送されるか。

  • サービス プロバイダーまたは最終的なサービス先のどちらが加入者の CPE に IP アドレスを提供するか。

  • 提供される IP アドレスが正規のパブリック アドレスまたはプライベート アドレスのどちらであるか。CPE が NAT/PAT を実行するのか、または終端先で NAT が実行されるのか。

  • 末端加入者、家庭ユーザ、Small Office Home Office(SOHO)、および在宅勤務者のプロファイル。

  • 複数のユーザの場合、すべてのユーザが同じ最終宛先またはサービスに到達する必要があるか、あるいは各ユーザが異なるサービス先に到達すればよいか。

  • サービス プロバイダーが音声やビデオなどの付加価値サービスを提供しているか。そのサービス プロバイダーを利用した場合、すべての加入者が必ず特定のネットワークを経由してから最終的な宛先に到達するようになっているか。SSG を使用した加入者は、パススルー サービス、PPP Terminated Aggregation(PTA)、メディエーション デバイス、またはプロキシを使用することになるか。

  • サービス プロバイダーから加入者への請求方法(固定料金、セッションの使用状況や使用されたサービスに基づく従量制など)。

  • CPE、DSLAM、および集約 Point Of Presence(POP)の配備とプロビジョニング。

  • NAP のビジネス モデル。そのビジネス モデルに、安全な企業アクセスなどのホールセール サービスや、音声やビデオなどの付加価値サービスの販売が含まれているか。NAP と NSP の実体は同じか。

  • 企業のビジネス モデル。そのビジネス モデルは Independent Local Exchange Carrier(ILEC; 独立系地域通信事業者)、Competitive Local Exchange Carrier(CLEC; 競争的地域通信事業者)、または ISP に匹敵するか。

  • NSP が末端加入者に提供しているアプリケーションの種類。

  • アップストリームおよびダウンストリームのデータフローの推定量。

以降、これらのポイントを念頭に置きながら、PPPoA アーキテクチャがサービス プロバイダーのさまざまなビジネス モデルにどのように適合し、それをどのように拡張するかについて説明します。さらにプロバイダーがこのアーキテクチャを使用することでどのような利益を得られるかについて示します。

一般的な PPPoA ネットワーク アーキテクチャ

次の図は、一般的な PPPoA ネットワーク アーキテクチャを示しています。CPE を使用するカスタマーは Cisco DSLAM を介してサービス プロバイダーのネットワークに接続し、Cisco DSLAM は ATM を使用して Cisco 6400 アグリゲータに接続します。

PPPoA アーキテクチャの設計に関する考慮事項

この文書の「実装に関する考慮事項」の項では、サービス プロバイダーのビジネス モデルに応じた各種のシナリオに従って PPPoA アーキテクチャを展開できることを示しました。この項では、サービス プロバイダーがソリューションを導入する前に留意おく必要がある、その他の可能性と考慮事項について説明します。

PPPoA アーキテクチャを展開し、このアーキテクチャに基づく特定のソリューションを導入するには、事前に必ずサービス プロバイダーのビジネス モデルを把握する必要があります。サービス プロバイダーが提供するサービスについて検討してください。サービス プロバイダーには、自社の末端加入者に高速インターネット アクセスなどの単独サービスを提供するものや、他の ISP にホールセール サービスを販売して、その ISP の加入者に付加価値サービスを提供するものがあります。また、それらをすべて提供するサービス プロバイダーもあります。

NSP と NAP が同一である環境で高速インターネット アクセスを提供する場合、加入者の PPP セッションは配備された集約ルータで終端する必要があります。このシナリオでは、1 台のルータ集約デバイスで終端できる PPP セッションの数、ユーザの認証方法、アカウンティングの実行方法、およびユーザ セッションが終端した後のインターネットへのパスについて検討するのは、サービス プロバイダーの役割です。PPP セッションと加入者の数に応じて、Cisco 6400 または Cisco 7200 のどちらかを集約ルータとして使用できます。現在、7 つの Node Route Processer(NRP; ノード ルート プロセッサ)を装備した Cisco 6400 では、最大 14,000 の PPP セッションを終端できます。Cisco 7200 の処理能力は 2,000 PPP セッションに制限されています。これらの数は新しいリリースでは変更されます。各集約ルータがサポートできる正確な数については、リリース ノートと製品文書を参照してください。

これらのシナリオでユーザ認証とアカウンティングを処理する最適な方法は、業界標準の RADIUS サーバを使用することです。RADIUS サーバでは、ユーザ名、または使用されている Virtual Path Identifier/Virtual Channel Identifier(VPI/VCI; 仮想パス識別子/仮想チャネル識別子)に基づいてユーザを認証できます。

高速インターネット アクセスの場合、NSP は一般に固定料金でカスタマーに請求します。現在はほとんどがこの方法で実装されています。NSP と NAP が同じ実体の場合、カスタマーにはアクセス用とインターネット アクセス用に別々の固定料金が請求されます。このモデルは、サービス プロバイダーが付加価値サービスの提供を開始すると変更されます。サービス プロバイダーは、サービスのタイプとその使用期間に基づいてカスタマーに課金できます。カスタマーは集約ルータを介してインターネットに接続します。集約ルータは Open Shortest Path First(OSPF)や Enhanced Interior Gateway Routing Protocol(EIGRP)などのルーティング プロトコルを使用してトラフィックをエッジ ルータにルーティングし、エッジ ルータでは Border Gateway Protocol(BGP; ボーダーゲートウェイ プロトコル)を実行できます。

サービス プロバイダーが高速インターネット アクセスを提供する場合、別のオプションとして、加入者からの着信 PPP セッションを、L2TP/L2F トンネリングを使用して別の ISP に転送する方法があります。L2x トンネリングを使用する場合は、トンネルの宛先に到達できるようにするために、特別な配慮が必要となります。使用可能なオプションは、集約ルータでいくつかのルーティング プロトコルを実行すること、またはスタティック ルートを提供するかのいづれかです。L2TP または L2F トンネルを使用する際は次のような制限があります。(1)トンネルの数と、それらのトンネルでサポートできるセッションの数。(2)サードパーティ ISP と互換性のないルーティング プロトコルの使用。ISP によっては、スタティック ルートの使用が必要となる場合があります。

サービス プロバイダーが末端加入者に異なる ISP または企業ゲートウェイ用のサービスを提供する場合、集約ルータに SSG 機能を実装しなければならないことがあります。これが実装されると、加入者は Web ベースのサービス選択機能を使用して、異なるサービス先を選択できるようになります。サービス プロバイダーは、加入者の PPP セッションを選択された宛先に転送するため、その ISP 宛てのすべてのセッションを 1 つにまとめて単一の PVC で送信できます。また、複数のサービス レベルを提供している場合は、コアを通じて複数の PVC を確立できます。

ホールセール サービス モデルでは、サービス プロバイダーは SSG 機能を使用しなくても構いません。このモデルでは、すべての PPP セッションがホーム ゲートウェイにまで拡張されます。ホーム ゲートウェイが末端加入者に IP アドレスを提供し、ユーザを認証します。

これらのシナリオすべてに共通する重要な考慮事項は、サービス プロバイダーがどのようにしてサービスごとに異なる Quality of Service(QoS)を提供し、どのようにして帯域幅割り当てを算出するかということです。現在、このアーキテクチャを展開しているほとんどのサービス プロバイダーが PVC ごとに異なる QoS を提供しています。家庭ユーザおよび企業顧客用のコアで複数の PVC を確立できる場合もあります。異なる PVC を使用すれば、サービス プロバイダーはサービスごとに異なる QoS を指定できます。このようにして、異なる PVC 上、つまりレイヤ 3 での QoS が可能になります。

レイヤ 3 で QoS を適用するには、サービス プロバイダーが最終的な宛先を知っている必要がありますが、これが制約要因になる可能性があります。しかし、レイヤ 2 QoS(VC ごとに QoS を適用する)と組み合せて使用すれば、サービス プロバイダーにとって有用となる場合があります。このモデルの制約は、固定的であり変更できないため、サービス プロバイダーがあらかじめ QoS をプロビジョニングする必要があることです。QoS はサービスの選択時にダイナミックに適用されません。現在、ユーザがマウスのクリックによってサービスごとに異なる帯域幅を選択できるオプションはありませんが、この機能の実現に向けて懸命な開発作業が進められています。

このアーキテクチャでは、CPE の配備、管理、およびプロビジョニングが非常に困難になる可能性があります。これは、CPE にユーザ名とパスワードを設定する必要があるためです。単純な解決策として、一部のサービス プロバイダーでは、すべての CPE で同じユーザ名とパスワードを使用しています。これは重大なセキュリティ上のリスクを伴います。また、CPE で同時に異なるセッションを開く必要がある場合は、CPE、NAP、および NSP で追加の VC をプロビジョニングしなければなりません。Cisco DSLAM および集約デバイスには、CPE の設定とプロビジョニングを容易にする機能があります。エンドツーエンドの PVC プロビジョニングには、フロースルー管理ツールも使用できます。数多くの加入者が PVC を使用する場合は、個々の PVC をすべて管理する必要があるため、NSP でのプロビジョニングが制約要因になります。また、マウスをクリックしたり、キーを数回入力したりするだけで、1 つの NRP に 2000 の PVC をプロビジョニングできるような、簡単な方法はありません。

現在、このアーキテクチャの各種コンポーネントを管理するためのアプリケーションは、DSLAM 用の Viewrunner や Cisco 6400 用の SCM など、複数存在します。すべてのコンポーネントをプロビジョニングする単一の管理プラットフォームはありません。この制約は十分認識されており、CPE、DSLAM、および Cisco 6400 をプロビジョニングできる包括的な単一の管理アプリケーションの開発作業が進められています。また、現在では SVC を使用した PPPoA を実装するソリューションもあり、これを利用すれば展開が非常に容易になります。SVC を使用した PPPoA では、エンド ユーザが宛先と QoS をダイナミックに選択することも可能です。

このアーキテクチャを使用して ADSL を大規模に展開する際に留意すべきもう 1 つの重要なポイントは、集約ルータから RADIUS サーバへの通信です。集約デバイスで数千もの PPP セッションが終端しているときに NRP ブレードで障害が発生した場合は、これらの PPP セッションをすべて再確立する必要があります。これは、すべての加入者を認証し、接続確立後にそのアカウンティング レコードを停止および再開することを意味します。それほど多くの加入者を同時に認証しようとすると、RADIUS サーバへのパイプがボトルネックになるおそれがあります。一部の加入者が認証できない事態が発生すると、それはサービス プロバイダーにとって大きな問題になります。

すべての加入者に同時に対応できるように十分な帯域幅を持つ RADIUS サーバへのリンクを備えることが非常に重要です。また、RADIUS サーバにはすべての加入者にアクセス権を与えられるだけの性能が必要となります。加入者が数千名にのぼる場合は、使用可能な RADIUS サーバの間でロード バランスをとるオプションも検討する必要があります。この機能は Cisco IOS(R) ソフトウェアで利用できます。

最後の考慮事項として、集約ルータには多数の PPP セッションを収容できるだけの十分な処理能力が必要です。他の実装で使用されるものと同じトラフィック処理原則を適用してください。以前は、ポイントツーポイント サブインターフェイスで PVC を設定する必要がありました。現在は、PPPoA を使用することにより、マルチポイント サブインターフェイスだけでなく、ポイントツーポイント サブインターフェイスでも複数の PVC を設定できます。各 PPPoA 接続は、もはや 2 つの Interface Descriptor Block(IDB)(仮想アクセス インターフェイス用に 1 つと ATM サブインターフェイス用に 1 つ)を必要としません。この機能拡張により、1 台のルータで実行できる PPPoA セッションの最大数が増加します。

1 台のプラットフォームでサポートされる PPPoA セッションの最大数は、メモリや CPU 速度などの使用可能なシステム リソースによって異なります。各 PPPoA セッションはそれぞれ 1 つの仮想アクセス インターフェイスを必要とします。仮想アクセス インターフェイスは、ハードウェア インターフェイス ディスクリプタ ブロックとソフトウェア インターフェイス ディスクリプタ ブロック(hwidb/swidb)のペアから成ります。hwidb は 1 つあたり約 4.5 K、swidb は 1 つあたり約 2.5 K のメモリを消費します。合計すると、1 つの仮想アクセス インターフェイスには 7.5 K が必要になります。2000 の仮想アクセス インターフェイスでは、2000 * 7.5 K = 15 M が必要です。つまり、2000 のセッションを実行するには、ルータに 15 M の追加メモリが必要になります。セッションの制約が増加すると、ルータではより多くの IDB をサポートする必要が生じます。PPP ステートのマシンのインスタンスをより多く実行するにはより多くの CPU サイクルが必要なため、このサポートによってパフォーマンスに影響が生じます。

PPPoA アーキテクチャの要点

この項では、PPPoA アーキテクチャにおける 3 つの要点、つまり CPE、IP 管理、およびサービス先への到達について説明します。

CPE

このシナリオでは、PAT の性質により、ペイロードに IP 情報を埋め込むタイプのアプリケーションが動作しません。この問題を解決するには、単一の IP アドレスではなく IP アドレスのサブネットを利用します。

このアーキテクチャでは、CPE に IP アドレスが割り当てられているため、NAP/NSP から CPE に Telnet して設定やトラブルシューティングを容易に実行できます。

CPE では加入者のプロファイルに応じて異なるオプションを使用できます。たとえば、家庭ユーザの場合は、CPE の PAT/DHCP 機能をオフに設定できます。加入者が複数の PC を所有している場合は、CPE の PAT/DHCP 機能をオンにすることも、あるいは家庭ユーザと同様にオフにすることも可能です。CPE に IP Phone が接続されている場合は、CPE に複数の PVC を設定できます。

IP 管理

PPPoA アーキテクチャでは、加入者 CPE への IP アドレスの割り当てには IPCP ネゴシエーションが使用されます。これはダイヤル モードの PPP と同じ動作原理です。IP アドレスは、加入者が使用するサービスのタイプに基づいて割り当てられます。加入者が NSP からのインターネット アクセスだけを行う場合、NSP は加入者からの PPP セッションを終端し、IP アドレスを割り当てます。この IP アドレスはローカルに定義されたプールか、DHCP サーバから割り当てられます。RADIUS サーバから適用することも可能です。また、ISP が加入者にスタティック IP アドレスのセットを事前に提供しておけば、加入者が PPP セッションを開始したときに、ISP はダイナミックに IP アドレスを割り当てなくてすみます。このシナリオでは、サービス プロバイダーはユーザ認証に RADIUS サーバだけを使用します。

加入者が複数のサービスの使用を希望している場合、NSP は SSG を実装する必要があります。IP アドレスの割り当てには、次のような方法が考えられます。

  • SP はローカル プールまたは RADIUS サーバを通じて加入者に IP アドレスを提供できます。ユーザがサービスを選択した後は、SSG によってユーザのトラフィックがサービス先に転送されます。SSG がプロキシ モードを使用している場合は、最終的な宛先から IP アドレスを提供できます。SSG では、この IP アドレスを NAT の際のアクセス可能アドレスとして使用します。

  • PPP セッションはサービス プロバイダーの集約ルータで終端されません。PPP セッションは最終宛先またはホーム ゲートウェイにトンネル伝送または転送され、そこで終端されます。最終宛先またはホーム ゲートウェイが加入者と IPCP をネゴシエートし、これによって IP アドレスがダイナミックに割り当てられます。また、スタティック アドレスを使用することも可能です。この場合は、それらのスタティック IP アドレスが最終宛先から事前に割り当てられていて、最終宛先がそれらのアドレスへの経路を持っていることが必要です。

Cisco 6400 NRP の Cisco IOS ソフトウェア リリースが 12.0.5DC 以前の場合は、サービス プロバイダーから加入者に IP アドレスのサブネットを提供することはできません。Cisco 6400 プラットフォームと Cisco 600 シリーズ CPE を使用すれば、PPP ネゴシエーション中に CPE に IP サブネットをダイナミックに設定できます。このサブネットの中から 1 つの IP アドレスが CPE に割り当てられ、残りの IP アドレスは DHCP を通じて端末にダイナミックに割り当てられます。この機能を使用すると、CPE で PAT を設定する必要がなくなりますが、これは一部のアプリケーションには対応していません。

サービス先への到達方法

PPPoA アーキテクチャでは、いつくかの方法でサービス先に到達できます。その中で最も一般的に使用されているのは次のような方法です。

    • サービス プロバイダーでの PPP セッションの終端
    • L2TP トンネリング
    • SSG の使用

    これら 3 つのどの方法でも、CPE から DSLAM への PVC の固定セットが定義されていて、それが集約ルータ上の PVC の固定セットにスイッチングされます。これらの PVC は、ATM クラウドを経由して DSLAM から集約ルータにマップされます。

    サービス先には、その他の方法、たとえば、SVC を使用した PPPoA や マルチプロトコル ラベル スイッチング/バーチャル プライベート ネットワークなどの方法を使用して到達することもできます。これらの方法については、この文書の適用範囲外であり、他の文書で説明される予定です。

    集約ルータでの PPP の終端

    加入者が開始した PPP セッションはサービス プロバイダーで終端し、そこでルータ上のローカル データベースまたは RADIUS サーバを使用してユーザが認証されます。ユーザが認証された後、IPCP ネゴシエーションが行われ、CPE に IP アドレスが割り当てられます。IP アドレスが割り当てられると、CPE と集約ルータの両方にホスト ルートが確立されます。加入者に割り当てられた IP アドレスが正規のものであれば、そのアドレスがエッジ ルータにアドバタイズされます。エッジ ルータとは、加入者がインターネットにアクセスする際に通過するゲートウェイのことです。IP アドレスがプライベートの場合は、サービス プロバイダーで変換されてからエッジ ルータにアドバタイズされます。

    L2TP/L2F トンネリング

    サービス プロバイダーまたは企業によっては、PPP セッションがサービス プロバイダーの集約ルータで終端するのではなく、L2TP または L2F を使用してアップストリームの終端ポイントにトンネル伝送されます。この終端ポイントでユーザ名が認証され、DHCP またはローカル プールによって加入者に IP アドレスが割り当てられます。このシナリオでは通常、L2TP Access Concentrator/Network Access Server(LAC/NAS; L2TP アクセス コンセントレータ/ネットワーク アクセス サーバ)とホーム ゲートウェイまたは L2TP Network Server(LNS; L2TP ネットワーク サーバ)との間に 1 つのトンネルが確立されます。LAC でドメイン名に基づいて着信セッションが認証され、最終宛先またはホームゲートウェイでユーザ名が認証されます。

    ただし、このモデルでは、ユーザは最終宛先にアクセスできるだけであり、一度に 1 つの宛先にしかアクセスできません。たとえば、CPE に rtr@cisco.com というユーザ名が設定されている場合、その CPE の背後にある PC は Cisco ドメインだけにアクセスできます。他の企業ネットワークに接続する場合は、その企業のドメイン名を反映するように CPE のユーザ名とパスワードを変更する必要があります。このケースでは、ルーティング プロトコル、スタティック ルートを使用するか、または Classical IP over ATM(ATM がレイヤ 2 で使用される場合)を実行することで、トンネルの宛先に到達します。

    Service Selection Gateway(SSG)の使用

    トンネリングに対する SSG の主な利点は、トンネリングが 1 対 1 のマッピングしかできないのに対し、SSG では 1 対複数のサービスのマッピングが可能な点です。これは、1 人のユーザが複数のサービスにアクセスする場合、または 1 つのロケーションに存在する複数のユーザがそれぞれ固有のサービスにアクセスする場合に非常に役立ちます。SSG は Web ベースの Service Selection Dashboard(SSD)を使用します。SSD は複数のサービスから構成されていて、ユーザが使用できるように公開されています。ユーザは一度に 1 つのサービスまたは複数のサービスにアクセスできます。SSG を使用するもう 1 つの利点は、サービス プロバイダーが使用されたサービスとセッション時間に基づいてユーザに課金できることと、ユーザが SSD を使用してサービスをオン/オフできることです。

    加入者からの PPP セッションが到達すると、ユーザ認証が行われます。ユーザには、ローカル プールまたは RADIUS サーバから IP アドレスが割り当てられます。ユーザの認証が成功すると、SSG コードによって発信元オブジェクトが作成され、デフォルト ネットワークへのアクセス権がユーザに与えられます。デフォルト ネットワークには SSD サーバがあります。ユーザがブラウザを使用してダッシュボードにログインすると、AAA サーバによってユーザ認証が行われた後、RADIUS サーバに保存されたユーザのプロファイルに応じて、アクセス可能なサービスのセットが提示されます。

    認証済みのユーザがサービスを選択するたびに、SSG はそのユーザの宛先オブジェクトを作成します。宛先オブジェクトには、宛先アドレス、その宛先の DNS サーバ アドレス、ホーム ゲートウェイから割り当てられた発信元 IP アドレスなどの情報が含まれます。ユーザ側から到達したパケットは、宛先オブジェクトに含まれる情報に基づいて宛先に転送されます。

    SSG では、プロキシ サービス、透過的パススルー、または PTA を設定できます。加入者がプロキシ サービスへのアクセスを要求すると、NRP-SSG はその Access-Request をリモート RADIUS サーバに渡します。Access-Accept を受信すると、SSG は加入者に Access-Accept で応答します。SSG は、リモート RADIUS サーバのクライアントとして動作します。

    透過的パススルーを使用すると、認証されていない加入者のトラフィックを、SSG を経由してどちらの方向にもルーティングできます。透過的パススルー トラフィックの制御にはフィルタを使用します。

    PTA は PPP タイプのユーザのみが使用できます。認証、認可、およびアカウンティングは、プロキシ サービス タイプの場合とまったく同じように実行されます。加入者は user@service 形式のユーザ名を使用してサービスにログインします。SSG はそれを RADIUS サーバに転送し、続いてサービス プロファイルが SSG にロードされます。SSG は要求をサービス プロファイルの RADIUS サーバ属性で指定されたリモート RADIUS サーバに転送します。要求が認証された後、IP アドレスが加入者に割り当てられます。NAT は実行されません。すべてのユーザ トラフィックがリモート ネットワークに集約されます。PTA では、ユーザは 1 つのサービスのみにアクセス可能で、デフォルト ネットワークや SSD にはアクセスできません。

    PPPoA アーキテクチャの動作に関する説明

    最初に CPE の電源をオンにすると、CPE から集約サーバに LCP 設定要求が送信されます。集約サーバ(PVC が設定済み)も、(その PVC に関連付けられた)仮想アクセス インターフェイス上に LCP 設定要求を送出します。両デバイスがそれぞれ相手側の設定要求を受信すると、その要求に対する確認応答が送信され、LCP ステートがオープンします。

    認証段階では、CPE から集約サーバに認証要求が送信されます。サーバはその設定に応じて、ドメイン名(提供されている場合)に基づいてユーザを認証するか、またはローカル データベースまたは RADIUS サーバを使用してユーザ名を認証します。加入者からの要求が username@domainname の形式をとっている場合、集約サーバは宛先へのトンネルを作成しようとします(まだトンネルが作成されていない場合)。トンネルが作成されると、集約サーバは加入者からの PPP 要求を宛先に転送します。続いて宛先でユーザが認証され、IP アドレスが割り当てられます。加入者からの要求にドメイン名が含まれない場合は、ローカル データベースによってユーザが認証されます。集約ルータで SSG が設定されていれば、ユーザは指定されたデフォルト ネットワークにアクセスして、各種サービスを選択するためのオプションを取得できます。

    最後に

    PPPoA は非常にスケーラビリティが高く、SSG 機能が使用可能で、セキュリティも装備されているため、多くのサービス プロバイダーにとって最適なアーキテクチャになりつつあります。この文書は PPPoA のアーキテクチャを対象としているため、SSG などの機能について詳しく説明できませんでした。これらの機能については、今後発行される文書で取り上げる予定です。この文書に記載された各種シナリオの設定例についても、他の文書で説明する予定です。


    関連するシスコ サポート コミュニティ ディスカッション

    シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


    関連情報


    Document ID: 12914