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

概要

このドキュメントでは、Point-to-Point Protocol over Asynchronous Transfer Mode（PPPoA）を使用するエンドツーエンドの非対称デジタル加入者線（ADSL）アーキテクチャについて説明します。 ほとんどの導入はブリッジング アーキテクチャに基づいていますが、PPPoA は非常に普及しており、将来の ADSL 導入でさらに広範な部分を形成します。

前提条件

基準となるアーキテクチャでは、コア バックボーンとして PPPoA を使用することで、エンド ユーザに高速インターネット アクセスおよび企業アクセスを提供する必要性が前提となっています。このアーキテクチャについては、現在の導入時に最も頻繁に使用される方法である、プライベート仮想チャネル（PVC）に基づいて説明します。スイッチド仮想回線（SVC）を使用するアーキテクチャについては、別のドキュメントで説明します。

このドキュメントは、既存の導入だけでなく、アーキテクチャのインハウス テストにも基づいています。

このドキュメントは、読者が RFC1483 ブリッジング ベースライン アーキテクチャのホワイトペーパーに記載されているネットワーク アクセス プロバイダー（NAP）の設計上の考慮事項を理解し、それに精通していることを前提に書かれています。

テクノロジーの概要

ポイントツーポイント プロトコル（PPP）（RFC 1331）は、ポイントツーポイント接続の両端の上位層のプロトコルをカプセル化する標準的な方法を提供します。これは、パケットの内容に関する情報を含む 16 ビットのプロトコル識別子によって、ハイレベル データ リンク制御（HDLC）パケット構造を拡張します。

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

• Link Control Protocol （LCP）：リンク パラメータ、パケット サイズ、または認証の種類をネゴシエートします

• Network Control Protocol （NCP）：IP および IPX、およびそれらの制御プロトコル（IP 用の IPCP）を含む上位層のプロトコルに関する情報が含まれます

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

PPP over ATM アダプテーション層 5 （AAL5）（RFC2364）は、PVC および SVC の両方をサポートするフレーミングされたプロトコルとして AAL5 を使用します。PPPoA は、主に ADSL の一部として実装されました。RFC1483 に準拠し、Logical Link Control-Subnetwork Access Protocol（LLC-SNAP）モードまたは VC-Mux モードで動作します。宅内装置（CPE）デバイスは、この RFC に基づいて PPP セッションをカプセル化し、ADSL ループとデジタル加入者線アクセス マルチプレクサ（DSLAM）へ転送できるようにします。

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

PPPoA アーキテクチャは、ダイヤルアップ モデルで使用される PPP の長所の大部分を継承しています。いくつかの要点を次に示します。

長所

• Password Authentication Protocol（PAP; パスワード認証プロトコル）または Challenge Handshake Authentication Protocol（CHAP; チャレンジ ハンドシェーク認証プロトコル）に基づくセッション単位の認証。 認証はブリッジング アーキテクチャのセキュリティ ホールを解消するので、これは PPPoA の最大の長所です。

• セッション単位の課金が可能です。これによりサービス プロバイダーは、提供するさまざまなサービスに対するセッション時間に基づいて、加入者に課金できます。セッションごとの課金によって、サービス プロバイダーは最小限の料金で最小アクセス レベルを提供し、追加で使用されたサービスに対して加入者に課金できます。

• CPE での IP アドレスの保全。これにより、サービス プロバイダーは、ネットワーク アドレス変換（NAT）用に設定された CPE を使用して、CPE に IP アドレスを 1 つのみ割り当てることができます。 1 つの CPE の背後にあるすべてのユーザが、単一の IP アドレスを使用して異なる宛先に到達できます。ネットワーク アクセス プロバイダー/ネットワーク サービス プロバイダー（NAP/NSP）は、IP アドレスを節約しながら、個々のユーザに対する IP 管理のオーバーヘッドを削減できます。さらに、サービス プロバイダーは、IP アドレスを小さなサブネットで提供することで、ポート アドレス変換（PAT）および NAT の制限を克服できます。

• NAP/NSP は、エンドツーエンドの PVC を管理したり、レイヤ 3 ルーティングまたは Layer 2 Forwarding/Layer 2 Tunneling Protocol （L2F/L2TP）トンネルを使用したりせずに、企業のゲートウェイへのセキュアなアクセスを提供します。そうすることで、大規模サービスを販売するためのビジネス モデルを拡大縮小できます。

• 個々の加入者のトラブルシューティング。NSA は、ブリッジング アーキテクチャの場合のようにグループ全体をトラブルシューティングするのではなく、アクティブな PPP セッションに基づいて、どの加入者がオンまたはオフなのか簡単に判断できます。

• NSP では、業界標準の Remote Authentication Dial-In User Service （RADIUS）サーバを使用するアイドル タイムアウトとセッション タイムアウトの導入により、加入者ごとのオーバーサブスクライブが可能です。

• 集約ルータ上で非常に多くの PPP セッションを終了できるので、高度にスケーラブルです。認証、認可、アカウンティングは、ユーザごとに外部 RADIUS サーバを使用して処理できます。

• Service Selection Gateway （SSG）上の機能の最適な使用。

デメリット

• 1 つの仮想チャネル（VC）上に CPE ごとに 1 つのセッションのみ使用できます。 ユーザ名とパスワードは CPE 上で設定されているので、その特定の VC の CPE の背後にあるすべてのユーザは、1 のサービス セットにのみアクセスできます。ユーザは、異なるサービス セットを選択できませんが、複数の VC を使用し、異なる VC で異なる PPP セッションを確立することはできます。

• CPE の設定が複雑になります。サービス プロバイダーのヘルプデスク担当者に求められる知識が増えます。ユーザ名とパスワードは CAPE 上で設定されているため、加入者または CPE ベンダーは、設定を変更する必要があります。複数の VC を使用すると、設定がより複雑になります。ただし、まだリリースされていない自動設定機能を使用すると、この問題が解決します。

• サービス プロバイダーは、すべての加入者に関するユーザ名とパスワードのデータベースを維持する必要があります。トンネル サービスまたはプロキシ サービスを使用する場合、認証はドメイン名に基づいて行うことができ、ユーザ認証は、企業ゲートウェイで行われます。これにより、サービス プロバイダーが維持しなければならないデータベースのサイズが小さくなります。

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

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

PPPoA のアーキテクチャを実装する前に考慮すべき重要なポイントは次のとおりです。

• 現在および将来的にサービスを提供される加入者の数。理由は、この数が必要な PPP セッションの数に影響するためです。

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

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

• 提供される IP アドレスが適法のパブリックなものか、またはプライベートなものか。CPE が NAT/ PAT を実施するのか、または終端の宛先で NAT が実行されるのか。

• エンド ユーザ、住宅ユーザ、小規模事業所（SOHO）顧客、および在宅勤務のプロファイル。

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

• 音声やビデオのような付加価値サービスをサービス プロバイダーが提供しているか。サービス プロバイダーは、すべての加入者に、最終目的地に到達する前にまずは特定のネットワークに移動するように求めるか。加入者が SSG を使用する場合、加入者はパススルー サービス、PPP 終端集約（PTA）、仲介デバイス、またはプロキシのいずれを使用するか。

• サービス プロバイダーの加入者に対する課金は、定額制か、セッション使用量単位か、使用したサービスごとか。

• CPE、DSLAM、および集約ポイント オブ プレゼンス（POP）の展開とプロビジョニング。

• NAP に対するビジネス モデル。そのモデルには、セキュアな企業アクセスなどの卸売りサービス、および音声や映像などの付加価値サービスの販売も含まれるか。NAP と NSP は同じエンティティか。

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

• NSP がエンド ユーザに提供するアプリケーションの種類。

• 予想されるアップストリームおよびダウンストリームのデータ フローの量。

以上の点に留意して、PPPoA アーキテクチャがサービス プロバイダーごとに異なるビジネス モデルにどのように適合し、規模を拡大縮小するのか、さらにはプロバイダーがこのアーキテクチャを利用してどのように利益を得られるのかについて説明します。

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

次の図は、典型的な PPPoA ネット ワークアーキテクチャを示しています。CPE を利用している顧客は、ATM を使用して Cisco6400 アグリゲータに接続する Cisco DSLAM 経由でサービス プロバイダーのネットワークに接続します。

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

このドキュメントの「実装に関する考慮事項」セクションでは、サービスプロバイダーのビジネスモデルに応じて、異なるシナリオを使用してPPPoAアーキテクチャを導入できます。この項では、サービス プロバイダーが解決策を導入する前に留意すべき別の可能性および考慮事項について説明します。

PPPoAアーキテクチャとこのアーキテクチャの特定のソリューションを導入する前に、サービスプロバイダーのビジネスモデルを理解することが不可欠です。サービス プロバイダーが提供するサービスを検討します。サービス プロバイダーは、そのエンド ユーザに高速インターネット アクセスなどのサービスを提供しますか。または、別の ISP に卸売りサービスを販売し、それらの ISP の加入者に付加価値サービスを提供しますか。サービス プロバイダーは、それらすべてを提供しますか。

NSPとNAPが同じ環境で高速インターネットアクセスを行う場合、加入者のPPPセッションは、配備されている集約ルータで終端する必要があります。このシナリオでは、サービス プロバイダーは、単一ルータのアグリゲーション デバイス上で終了できる PPP セッションの数、ユーザの認証方法、アカウンティングの実施方法、ユーザ セッションを終了してからのインターネットへのパスを考慮する必要があります。PPP セッションと加入者の数に応じて、集約ルータは Cisco6400 または Cisco7200 のいずれかになります。現在、7ノードルートプロセッサ(NRP)を搭載したCisco 6400は、最大14,000のPPPセッションを終了できます。Cisco 7200 は 2,000 の PPP セッションに制限されています。これらの数字は新しいリリースで変更されます。集約ルータごとにサポートできるセッションの正確な数については、リリース ノートと製品ドキュメントを確認してください。

これらのシナリオでのユーザ認証とアカウンティングは、業界標準の RADIUS サーバを使用して最もうまく処理されます。このサーバは、ユーザ名または使用されている仮想パス識別子/仮想チャネル識別子（VPI/VCI）に基づいてユーザを認証できます。

高速インターネット アクセスに関して、NSP は、通常、顧客に定額料金を請求します。現在の導入事例のほとんどでは、このように実装されています。NSP および NAP が同じエンティティである場合は、顧客はアクセスに対して定額料金で請求され、さらにインターネット アクセスに対して別の定額料金で請求されます。このモデルは、サービス プロバイダーが付加価値サービスの提供を開始すると変更されます。サービス プロバイダーは、サービスの種類とサービスの使用期間に基づいて顧客に請求できます。顧客は、Border Gateway Protocol （BGP）を実行している可能性のあるエッジ ルータに対して Open Shortest Path First （OSPF）または Enhanced Interior Gateway Routing Protocol （EIGRP）などのルーティング プロトコルを使用して集約ルータ経由でインターネットに接続します。

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

サービス プロバイダーがエンド ユーザに異なる ISP または企業ゲートウェイに対するサービスを提供する場合、それらは集約ルータ上に SSG 機能を実装する必要がある可能性があります。これにより、加入者は Web ベースのサービス選択を使用して、異なるサービスの宛先を選択できます。サービス プロバイダーは、ISP 宛てのすべてのセッションを転送用の単一の PVC に組み合わせることで、加入者の PPP セッションを選択された宛先に転送するか、サービス プロバイダーが複数のサービス レベルを提供している場合は、コアを越えて複数の PVC を確立できる可能性があります。

卸売りサービス モデルでは、サービス プロバイダーは SSG の機能を使用できません。このモデルでは、サービス プロバイダーは、ホーム ゲートウェイのすべての PPP セッションを拡張します。ホーム ゲートウェイは、エンド ユーザに IP アドレスを提供し、エンド ユーザを認証します。

これらのすべてのシナリオにおいて、サービス プロバイダーがサービスごとに異なる Quality of Service （QoS）をどのように提供するのか、さらには帯域幅割り当てをどのように計算するのかが主な考慮事項となっています。現在、ほとんどのサービス プロバイダーがこのアーキテクチャを導入する方法では、PVC ごとに異なる QoS を提供しています。これらのプロバイダーは、一般顧客と企業顧客のために、コアに対して別々の PVC を持っている可能性があります。サービス プロバイダーは、別の PVC を使用することで、サービスごとに異なる QoS を指定できます。この方法によって、QoS が別々の PVC に対して、またはレイヤ 3 で実施される可能性があります。

レイヤ 3 で QoS を適用するには、サービス プロバイダーは最終的な宛先を知る必要があり、そのことが制限要因になる可能性があります。ただし、レイヤ 2 QoS との組み合わせで使用すると（別の VC 上に適用する）、サービス プロバイダーにとって役立つ可能性があります。このモデルの制限は、それが固定されることであり、サービス プロバイダーは、事前に QoS をプロビジョニングする必要があります。QoS は、サービスの選択に動的には適用されません。現在、ユーザがマウスをクリックするだけでサービスごとに異なる帯域幅を選択するオプションはありません。しかしながら、この機能を開発するために技術者による多大な労力が投資されています。

CPE はユーザ名とパスワードを設定する必要があるので、このアーキテクチャでは CPE の展開、管理、およびプロビジョニングは非常に困難になる可能性があります。簡単な解決策として、一部のサービス プロバイダーが、すべての CPE に同じユーザ名とパスワードを使用しています。これは多大なセキュリティ リスクとなります。さらに、CPE が同時に異なるセッションを開く必要がある場合、CPE、NAP、および NSP で追加の VC をプロビジョニングする必要があります。Cisco DSLAM およびアグリゲーション デバイスは、CPE の設定およびプロビジョニングを簡素化できます。さらに、エンドツーエンドの PVC プロビジョニングには、フロースルー管理ツールも利用できます。PVC を使用して非常に多くの加入者に NSP でプロビジョニングすることは、異なる PVC をすべて管理しなければならないので制限要因となります。また、単独の NRP 上で 2,000 の PVC をプロビジョニングするのに、マウスをクリックしたり、いくつかのキーストロークを入力したりするだけのような簡単な方法はありません。

今日では、DSLAM 用の Viewrunner や Cisco 6400 用の SCM など、このアーキテクチャのコンポーネントごとに異なる管理アプリケーションが存在します。すべてのコンポーネントをプロビジョニングするような単一の管理プラットフォームはありません。これは広く知られた制限事項であり、CPE、DSLAM、および Cisco6400 をプロビジョニングするような単一の包括的な管理アプリケーションを開発しようと多大な労力が投資されています。さらに現在では SVC に PPPoA を実装するための解決策があります。これにより、導入が大幅に容易になります。また、PPPoA を使用する SVC は、エンド ユーザが宛先および QoS を動的に選択できるようにします。

このアーキテクチャを使用した大規模な ADSL の導入に関して、留意する必要があるもう 1 つの重要なポイントは、集約ルータから RADIUS サーバへの通信です。数千の PPP セッションが集約デバイス上で終了される場合に NRP ブレードに障害が発生すると、これらすべての PPP セッションを再確立する必要があります。つまり、すべての加入者が認証されなければならず、そのアカウンティング記録が停止して接続が確立されると再開することを意味します。非常に多くの加入者が同時に認証を受けようとすると、RADIUS サーバへのパイプがボトルネックになる可能性があります。一部の加入者は認証を受けられない可能性があり、それによりサービス プロバイダーに問題が発生する場合があります。

同時にすべての加入者を処理するのに十分な帯域幅を持つ RADIUS サーバへのリンクを準備していることが非常に重要です。さらに RADIUS サーバは、すべての加入者に権限を付与できるように、十分に強力である必要があります。何千もの加入者が存在する場合、利用可能な RADIUS サーバ間でロード バランスを実施するオプションを考慮すべきです。この機能は、Cisco IOS® ソフトウェアで利用できます。

最後の考慮事項として、多くの PPP セッションを処理するのに集約ルータが十分なパフォーマンスを備えている必要があります。他の実装で使用されるのと同じトラフィック エンジニアリングの原則を適用します。以前は、ユーザはポイントツーポイント サブインターフェイスで PVC を設定する必要がありました。最近の PPPoA では、ユーザがマルチポイント サブインターフェイス上で複数の PVC を設定するだけでなく、ポイントツーポイントで設定することもできます。PPPoA の接続ごとに、1 つは仮想アクセス インターフェイス用、もう 1 つは ATM サブインターフェイス用の 2 つのインターフェイス記述子ブロック（DBS）を必要とすることはなくなりました。この拡張により、ルータ上で実行されている PPPoE セッションの最大数が増加します。

プラットフォームでサポートされる PPPoA セッションの最大数は、メモリや CPU 速度などの利用可能なシステム リソースに依存します。PPPoA セッションごとに 1 つの仮想アクセス インターフェイスが使用されます。各仮想アクセス インターフェイスは、ハードウェア インターフェイス記述子ブロックとソフトウェア インターフェイス記述子ブロック（hwidb/swidb）のペアで構成されます。hwidb ごとに約 4.5K かかります。swidb ごとに約 2.5K かかります。仮想アクセスインターフェイスには7.5 Kが必要です。2000の仮想アクセスインターフェイスには2000 * 7.5 Kまたは15 Mが必要です。2,000 のセッションを実行するには、ルータには追加で 15M が必要です。セッションの制限が増加するので、ルータはより多くの IDB をサポートする必要があります。このサポートにより、PPP のステート マシンのより多くのインスタンスを実行するために、CPU サイクルがさらに増えるので、パフォーマンスに影響が及びます。

PPPoA アーキテクチャの要点

この項では、PPPoA のアーキテクチャの 3 つの重要なポイントである、CPE、IP 管理、およびサービス宛先への到達について説明します。

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

このアーキテクチャでは、IP アドレスが CPE に割り当てられるので、NAP/ NSP がより簡単に CPE に Telnet 接続し、設定およびトラブルシューティングできます。

CPEは、加入者のプロファイルに応じて異なるオプションを使用できます。たとえば、住宅ユーザの場合、CPE は PAT/DHCP なしで設定できます。複数の PC を使用する加入者の場合、CPE は PAT/DHCP に対して設定するか、住宅ユーザと同様の設定にすることができます。CPE に接続された IP 電話がある場合は、CPE は複数の PVC 向けに設定できます。

IP 管理

PPPoA のアーキテクチャでは、加入者の CPE への IP アドレスの割り当ては、ダイヤル モードの PPP と同じ原理である、IPCP ネゴシエーションを使用します。IP アドレスは、加入者が使用するサービスの種類に応じて割り当てられます。加入者が NSP からのみインターネットにアクセスできる場合、NSP は加入者からの PPP セッションを終了し、IP アドレスを割り当てます。IP アドレスはローカルに定義されたプールまたは DHCP サーバから割り当てられるか、RADIUS サーバから適用できます。また、ISP は加入者に一連の静的 IP アドレスを提供し、加入者が PPP セッションを開始する際に動的に IP アドレスを割り当てない可能性があります。このシナリオでは、サービス プロバイダーは RADIUS サーバのみを使用してユーザを認証します。

加入者が複数のサービスを利用できるよう希望する場合は、NSP は SSG を実装する必要があります。IP アドレスを割り当てるためのオプションは次のとおりです。

• SP はローカル プールまたは RADIUS サーバ経由で加入者に IP アドレスを提供できます。ユーザがサービスを選択すると、SSGはその宛先にユーザのトラフィックを転送します。SSG がプロキシ モードを使用している場合、最終宛先が IP アドレスを提供する可能性があり、SSG はこのアドレスを NAT 用のビジブル アドレスとして使用します。

• PPPセッションは、サービスプロバイダーの集約ルータでは終了しません。それらはトンネリングされるか、最終宛先またはホーム ゲートウェイに転送され、それにより最終的に PPP セッションを終了します。最終宛先またはホーム ゲートウェイが加入者と IPCP をネゴシエーションし、それによって動的に IP アドレスを提供します。最終宛先がそれらの IP アドレスを割り当て、それらのアドレスにルートが設定されている限り、静的アドレスも使用できます。

Cisco 6400 NRP のための Cisco IOS ソフトウェア リリース 12.0.5DC 以前は、サービス プロバイダーから加入者に IP アドレスのサブネットの提供ができませんでした。Cisco 6400 プラットフォームおよび Cisco 600 シリーズ CPE は、PPP ネゴシエーション時に IP サブネットを CPE 上で動的に設定できるようにします。このサブネットから IP アドレスが CPE に 1 つ割り当てられ、残りの IP アドレスが DHCP 経由でステーションに動的に割り当てられます。この機能を使用すると、一部のアプリケーションでは動作しない PAT のために CPE を設定する必要はありません。

サービス先への到達方法

PPPoA のアーキテクチャでは、サービスの宛先に異なる方法でアクセスできます。最も一般的に利用される方法の一部を次に挙げます。

• サービス プロバイダーでの PPP セッションの終了

• L2TP トンネリング

• SSG の使用

集約ルータで PVC の固定セットに切り替えられる DSLAM に対して、CPE から定義された PVC の固定セットが 3 つすべての方法に存在します。PVC は ATM クラウド経由で DSLAM から集約ルータにマッピングされます。

サービスの宛先には、SVC を使用する PPPoA、またはマルチプロトコル ラベル スイッチング/バーチャル プライベート ネットワークなどの他の方法を使用しても到達できます。これらの方法は、このドキュメントの範囲を超えているので、別のドキュメントで説明します。

集約で PPP を終了

ユーザが開始した PPP セッションは、ルータ上のローカル データベースを使用するか、RADIUS サーバ経由のいずれかで加入者を認証するサービス プロバイダーで終了します。ユーザが認証されると、IPCP ネゴシエーションが実施され、IP アドレスが CPE に割り当てられます。IP アドレスが割り当てられると、CPE および集約ルータの両方でホスト ルートが確立されます。加入者に割り当てられた IP アドレスが適法なものであれば、エッジ ルータにアドバタイズされます。エッジ ルータは、加入者がインターネットにアクセスするためのゲートウェイです。IP アドレスがプライベートの場合、サービス プロバイダーは、エッジ ルータにアドバタイズする前にそれらを変換します。

L2TP/L2F トンネリング

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

ただし、このモデルでは、ユーザは最終宛先に対するアクセス権のみを持つことができ、同時に 1 つの宛先にのみアクセスできます。たとえば、CPI が rtr@cisco.com のユーザ名で設定されている場合、その CPE の背後にある PC は Cisco ドメインのみにアクセスできます。ユーザが別の企業ネットワークへの接続を希望する場合、その企業のドメイン名を反映するように CAPE でユーザ名とパスワードを変更する必要があります。この場合、トンネルの宛先に到達するには、ルーティング プロトコルまたはスタティック ルートを使用するか、Classical IP over ATM （レイヤ 2 として ATM が好ましい場合）を使用します。

Service Selection Gateway （SSG）の使用

トンネリングと比較した場合の SSG の主な利点は、トンネリングは 1 対 1 のマッピングのみを提供するのに対し、SSG は 1 対多サービスのマッピングを提供する点です。これは、単独のユーザが複数の場所にアクセスする必要がある場合、または 1 つの場所にいる複数のユーザが固有のサービスにアクセスする必要がある場合に非常に便利です。SSG は、異なるサービスで構成され、ユーザが使用できる Web ベースのサービス選択ダッシュボード（SSD）を使用しています。ユーザは、一度に 1 つまたは複数のサービスにアクセスできます。SSG を使用するもう 1 つの利点は、サービス プロバイダーはユーザが使用したサービスおよびセッション時間に基づいてユーザに課金でき、ユーザが SSD 経由でサービスのオンとオフを切り替えられる点です。

PPP セッションが加入者から入ってくる時点でユーザが認証されます。ユーザにはローカル プールまたは RADIUS サーバのいずれかから IP アドレスが割り当てられます。ユーザが正常に認証されると、ソース オブジェクトが SSG コードによって作成され、ユーザはデフォルト ネットワークへのアクセスが許可されます。デフォルトのネットワークには SSD サーバが含まれています。ブラウザを使用して、ユーザはダッシュボードにログインし、AAAサーバによって認証され、RADIUSサーバに保存されているユーザのプロファイルに応じて、アクセスする一連のサービスが提供されます。

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

プロキシ サービス、透過的パススルー、または PTA に対して SSG を設定できます。加入者がプロキシ サービスへのアクセスを要求すると、NRP-SSG がリモート RADIUS サーバに access-request を渡します。NSA は access-accept を受信すると、加入者にその access-accept 付きで応答します。SSG はリモート RADIUS サーバにとってはクライアントとして表示されます。

透過的パススルーは、認証されていない加入者トラフィックを SSG 経由でいずれかの方向にルーティングできるようにします。透過的パススルー トラフィックを管理するにはフィルタを使用します。

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

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

CPE の電源が最初にオンになると、集約サーバに LCP 設定リクエストの送信を開始します。PVC が設定されて集約サーバも、仮想アクセス インターフェイス（PVC に関連付けられている）上で LCP 設定リクエストを送信します。 それぞれが他方の設定リクエストを認識すると、リクエストを承認し、LCP の状態がオープンになります。

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

結論

PPPoA は非常にスケーラブルで、SSG の機能を使用し、セキュリティを提供するので、多くのサービス プロバイダーにとって最も適したアーキテクチャになっています。このドキュメントの焦点は PPPoA のアーキテクチャであるので、SSG のような機能を詳細には説明できません。それらの機能については、後続のドキュメントで説明します。このドキュメントで説明するさまざまなシナリオのサンプル設定は、別のドキュメントでも使用および説明されます。

関連情報

• Cisco DSL 製品に関するサポート情報
• テクニカルサポート - Cisco Systems