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

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

2016 年 10 月 28 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2002 年 9 月 12 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

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

前提条件

ベースラインアーキテクチャはコアバックボーンとして PPPoA を使用している末端 加入者へ高速 インターネット アクセスおよび法人アクセスを提供するための必要を伴います。 私用 仮想チャネル(PVC)に基づいてこのアーキテクチャを現在の配備で最も頻繁に使用された方式論議します。 相手先選択接続(SVC)を使用してアーキテクチャは個別 の 文書で論議されます。

この資料はアーキテクチャの既存 の 配備、また社内 テストに基づいています。

この文書は読者が RFC1483 ブリッジング ベースライン アーキテクチャ 白書に記述されているように Network Access Provider (NAP)の設計上の考慮事項について知識があり、詳しく知っているという前提で書かれました。

テクノロジーの概要

ポイントツーポイントプロトコル (PPP) (RFC 1331)はポイントツーポイント接続を渡るハイレイヤプロトコルをカプセル化する標準的な方法を提供します。 それはパケットのコンテンツについての情報が含まれている 16 ビット Protocol Identifier のハイレベル データ リンク コントロール(HDLC) パケット構造を拡張します。

パケットは情報の 3 つの型が含まれています:

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

  • Network Control Protocol (NCP) –含まれています IP および IPX を含むハイレイヤプロトコルについての情報、および制御プロトコル(IP のための IPCP)が

  • データが含まれているデータフレーム

PPP over ATM アダプテーションレイヤ 5 (AAL5) (RFC 2364)は PVC および SVC を両方サポートするフレームドプロトコルとして AAL5 を使用します。 PPPoA は ADSL の一部として主に設定されていました。 それは RFC1483 に頼りま、モード Logical Link Control-Subnetwork Access Protocol (LLC-SNAP)か VCMux で操作します。 Customer Premises Equipment (CPE) デバイスは ADSLループおよび digital subscriber line access multiplexer (DSLAM)を渡る転送するのためのこの RFC に基づいて PPP セッションをカプセル化します。

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

PPPoA アーキテクチャはダイヤル モデルで使用される PPPの有利な点のほとんどを受継ぎます。 いくつかのキーポイントは下記にリストされています。

利点

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

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

  • CPE の IPアドレスの保存。 これはサービスプロバイダーがネットワーク アドレス変換(NAT)のために CPE が設定されている CPE に 1 ただ IP アドレスを、割り当てることを可能にします。 1 CPE の後ろのすべてのユーザは異なる宛先に到達するのに単一 IP アドレスを使用できます。 各個々のユーザ向けの Network Access Provider/Network Services Provider (NAP/NSP)のための IP管理 オーバーヘッドは IP アドレスを節約している間減ります。 さらに、サービスプロバイダーはポート アドレス変換 (PAT)および NAT に関する制限事項を克服するために IP アドレスの小さいサブネットを提供できます。

  • NAP/NSP は企業ゲートウェイまたはレイヤ2 フォワーディング/Layer 2 Tunneling Protocol (L2F/L2TP)トンネルにエンドツーエンド PVC を管理しか、レイヤ3 ルーティングを使用しないで安全なアクセスを提供します。 それ故に、それらはホールセール サービスを販売するためのビジネスモデルを拡張できます。

  • 個々のサブスクライバのトラブルシューティング。 NSP はできま全体のグループをブリッジングアーキテクチャと同様に解決しますよりもむしろ容易にオン/オフはアクティブな PPP セッションに基づくどのサブスクライバであるか識別。

  • NSP は各サブスクライバのための業界標準 Remote Authentication Dial-In User Service (RADIUS) サーバを使用してアイドル/セッション タイムアウトの展開によってオーバーサブスクライブできます。

  • 集約ルータの非常に多くの PPP セッションを終了できるように拡張性が高い。 認証、許可、会計は外部 の RADIUSサーバを使用している各ユーザ向けに処理することができます。

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

欠点

  • 1 Virtual Channel (VC)の CPE ごとの単一 セッションだけ。 ユーザ名 および パスワードが CPE で設定されるので、その特定の VC のための CPE の後ろのすべてのユーザは 1 つのサービスのセットだけアクセスできます。 ユーザは複数の VC を使用するがサービスの異なるセットを選択できないし、異なる VC の別の PPP セッションを設定することは可能性のあるです。

  • CPE セットアップのより複雑な状況。 サービスプロバイダーのヘルプデスク 担当者はより知識がある必要があります。 ユーザ名 および パスワードが CPE で設定されるので、サブスクライバか CPE ベンダーはセットアップ変更を行なう必要があります。 多重 VC 増加設定の複雑さの使用。 しかしこれはまだリリースされていない自動設定機能によって克服することができます。

  • サービスプロバイダーはすべてのサブスクライバのためのユーザ名 および パスワードのデータベースを維持する必要があります。 トンネルかプロキシサービスが利用される場合、認証はドメイン名に基づいて実行することができ、ユーザ認証は企業ゲートウェイで実行されます。 これは維持しなければサービスプロバイダーがならないデータベースのサイズを減らします。

  • 単一 IP アドレスが CPE および NAT/PAT にならペイロードで IP情報を組み込む IPTV のような設定された、ある特定のアプリケーション提供されれば、はたらきません。 IPサブネット 機能が使用されればさらに、IP アドレスはまた CPE のために予約済みでなければなりません。

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

PPPoA アーキテクチャを設定する前に考慮するべきキーポイントは下記のものを含んでいます:

  • これが必須 PPP セッションの数に影響を与えるように、現在および将来保守されるサブスクライバの数。

  • PPP セッション サービスプロバイダーで終えられているかどうかか。s 集約ルータまたは他の企業ゲートウェイかインターネットサービスプロバイダー(ISP)に転送されて。

  • サービスプロバイダーか最終的な サービス 宛先 サブスクライバに IP アドレスを提供しているかどうかか。s CPE。

  • 提供される IP アドレスは可能なパブリックまたは private であるかどうか。 CPE は NAT/PAT をする行っていますまたは NAT は終端 先で実行されたか。

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

  • 複数のユーザの場合には、同じ最終 宛先かサービスに達するすべてのユーザーのニーズにか皆異なるサービス宛先があるかどうか。

  • サービスプロバイダーは音声またはビデオのような付加価値サービスを提供していますか。 サービスプロバイダーは特定のネットワークに最初にに最終 宛先に到達する前にすべてのサブスクライバを行きます必要としますか。 サブスクライバが SSG を使用するとき、パススルー サービス、PPP Terminated Aggregation (PTA)、仲介装置、またはプロキシを使用する行っていますか。

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

  • 存在(POPs)の配備および CPEの準備、DSLAM および集約ポイント。

  • NAP に対するビジネス モデル。 モデルはまた音声およびビデオのような企業への安全なアクセスおよび付加価値サービスのようなホールセール サービスを販売することが含まれていますか。 NAP と NSP は同じエンティティか。

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

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

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

PPPoA アーキテクチャがどのようにサービスプロバイダーのための異なるビジネスモデルに、そしてどのようにプロバイダがこのアーキテクチャを使用して寄与できる適合し、拡張されるかこれらのポイントに留意して、論議します。

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

次のダイアグラムは典型的な PPPoA ネットワ ーク アーキテクチャを示します。 CPE を使用している顧客は Cisco DSLAM を通って ATM を使用して Cisco 6400 に集約機能を接続するサービスプロバイダーのネットワークに接続します。

/image/gif/paws/12914/pppoa_arch_1.gif

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

この資料の" Implementation Considerations " セクションでは、PPPoA アーキテクチャはサービスプロバイダーによって異なるシナリオを使用して展開することができますか。s ビジネスモデル。 このセクションでは、サービスプロバイダーがソリューションを展開する前に留意する必要がある考慮事項および異なる可能性を論議します。

このアーキテクチャのための PPPoA アーキテクチャおよび特定 の ソリューションを展開する前に、サービスプロバイダーを理解することは必要ですか。s ビジネスモデル。 サービスプロバイダーが提供するサービスを考慮して下さい。 サービスプロバイダーは末端 加入者に高速 インターネット アクセスのような 1 つのサービスを提供しますか、または異なる ISP にホールセール サービスを販売し、それらのサブスクライバに付加価値サービスを提供しますか。 サービスプロバイダーはすべてを提供しますか。

NSP および NAP が同じである環境の高速 インターネット アクセスの場合には、サブスクライバか。s PPP セッションは配置された集約ルータで終了する必要があります。 このシナリオでは、サービスプロバイダーはユーザセッションが終了されればインターネットに会計を行おうとしているパス筈であるかかどのようにユーザがどのように認証される何 PPP セッションがシングル ルータ 集約デバイスで終了することができるか考慮する必要があり。 PPP セッションおよびサブスクライバの数によっては、集約ルータは Cisco 6400 または Cisco 7200 である可能性があります。 今日か。7 台のノードルート プロセッサ(NRP)が付いている s Cisco 6400 は 14,000 まで PPP セッションを終了できます。 Cisco 7200 は 2,000 PPP セッションに制限されます。 これらの数は新しいリリースと変更されます。 リリース ノートをチェックすれば各集約ルータがサポートできるセッションの確定した数のための製品文書。

これらのシナリオのユーザ認証および会計はユーザ名か使用される仮想パス識別子/仮想チャネル識別子(VPI/VCI)に基づいてユーザを認証できる業界標準 RADIUSサーバの使用によって処理される推奨です。

高速 インターネット アクセスに関しては、NSP は通常フラットレート 顧客に請求書を送ります。 現在の配備のほとんどはこうすれば設定されています。 NSP および NAP が同じエンティティのとき、顧客はインターネットアクセスのアクセスおよび別の固定速度のために一定のレートで請求書を送られます。 このモデルはサービスプロバイダーが付加価値サービスを提供し始めるとき変更します。 サービスプロバイダーはサービス タイプに基づいて顧客を満たすことができ、サービスが利用される期間。 顧客は Open Shortest Path First (OSPF)のようなルーティング プロトコルか Border Gateway Protocol (BGP)を実行する可能性があるエッジルータに 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 を規定 するようにします。 こうすればは別々の PVC でまたはレイヤ3 で、QoS ある可能性があります。

レイヤ3 の QoS を適用することはサービスプロバイダーが制限要因である可能性がある最終 宛先を知るように要求します。 しかし、もし使用するならレイヤ2 QoS と組み合わせて(異なる VC でそれを加えることによって)、それはサービスプロバイダーに役立ちます。 このモデルの制限は固定であり、サービスプロバイダーが QoS のために先立って提供する必要があることです。 QoS はサービスの選択で動的に適用されません。 現在、マウスのクリックの異なるサービスに異なる帯域幅を選択するユーザ向けのオプションがありません; ただしこの機能を開発する、懸命 な 開発作業は投資されました。

CPE がユーザ名 および パスワードのために設定される必要があるように CPE 配備、管理およびプロビジョニングはこのアーキテクチャで非常に挑戦的である可能性があります。 単純な解決方法として、いくつかのサービスプロバイダーはすべての CPE のために同じ ユーザ名およびパスワードを使用しています。 これは重要なセキュリティリスクを示します。 CPE が同時に CPE で提供される別のセッション、追加 VC 必要 NAP および NSP を開く必要がある場合、さらに。 Cisco DSLAM および集約デバイスに CPEコンフィギュレーションおよびプロビジョニングを簡素化する機能があります。 Flow-through マネジメントツールはエンドツーエンド PVCプロビジョニングにまた利用できます。 PVC を使用しているそう多くのサブスクライバのための NSP の提供はすべての異なる PVC が管理する必要があるので制限要因です。 さらに、マウスをクリックするか、または少数のキー ストロークを入力することによってプロビジョニングの単純な方法 単一 NRP の 2000 PVC 行いません。

今日 DSLAM のための Viewrunner およびそこの Cisco 6400 のための SCM のようなこのアーキテクチャの異なるコンポーネントのための異なる管理アプリケーションが、ですすべてのコンポーネントを提供する管理プラットフォームありません。 これはよく認識された制限であり、単一の、広範囲の管理 アプリケーション CPE を提供する、DSLAM および Cisco 6400 を持つ大きな 努力は投資されています。 さらに、現在配備を非常に促進する SVC の PPPoA を設定するソリューションがあります。 SVC の PPPoA はまたエンドユーザが宛先および QoS を動的に選択することを可能にします。

このアーキテクチャを使用して大きい ADSL 配備のために留意するべきもう一つの重要な点は集約ルータからの RADIUSサーバへ通信です。 数千 PPP セッションが集約デバイスで終了されるとき NRP ブレードが壊れた、それらの PPP セッションはすべて回復する必要があります。 これは接続が確立されればサブスクライバ全員が認証される必要がある停止し、再起動することをアカウンティング レコード意味し。 そう多くのサブスクライバが同時に認証されることを試みるとき RADIUSサーバへのパイプはボトルネックである場合もあります。 何人かのサブスクライバは認証できないかもしれないし、これはサービスプロバイダーのための問題を引き起こすことができます。

すべてのサブスクライバを同時に取り扱う十分な帯域幅の RADIUSサーバにリンクを持っていることは非常に重要です。 すべてのサブスクライバに権限を与えるにはなお、RADIUSサーバは十分に強力であるはずです。 サブスクライバの桁の場合には、利用可能 な RADIUSサーバ間のロード バランスへのオプションは検討する必要があります。 この機能は Cisco IOS で利用できますか。 ソフトウェア。

最終的 な 検討として多くの PPP セッションを取り扱うために、集約ルータは十分に作動する必要があります。 他の実装によって使用される同じトラフィック処理プリンシパルを適用して下さい。 以前は、ユーザはポイントツーポイント サブインターフェイスの PVC を設定しなければなりませんでした。 今日 PPPoA はユーザがマルチポイント サブインターフェイス、またポイントツーポイントの複数の PVC を設定することを可能にします。 各 PPPoA 接続はもはや 2 つのインターフェイス 記述子ブロック(IDB)、1 および ATM サブインターフェイスのための仮想アクセスインターフェイスのための 1 を必要としません。 この機能拡張はルータで動作している PPPoAセッションの最大数を増加します。

プラットフォームでサポートされる最大数 PPPoAセッションはメモリおよび CPU 速度のような利用可能 システム資源によって決まります。 各 PPPoAセッションは 1 つの仮想アクセスインターフェイスを戻します。 各仮想アクセスインターフェイスはハードウェアインターフェイス 記述子ブロックおよびソフトウェアインターフェイス 記述子ブロック(hwidb/swidb)ペアで構成されています。 各 hwidb は 4.5K について奪取 します。 各 swidb は 2.5K について奪取 します。 ともに、仮想アクセスインターフェイスは 7.5K を必要とします。 2000 の仮想アクセスインターフェイスは 2000 年* 7.5K か 15M を必要とします。 2000 年のセッションを実行するために、ルータは追加 15M を必要とします。 セッション 限度の増加が理由で、ルータはより多くの IDB をサポートする必要があります。 このサポートは PPP 状態 マシンのより多くの例を実行することより多くの CPU サイクルによるパフォーマンスに影響を与えます。

PPPoA アーキテクチャの要点

このセクションは PPPoA アーキテクチャで 3 つのキーポイントを説明します: CPE、IP管理、およびサービス の 宛先に到達すること。

/image/gif/paws/12914/pppoa_arch_2.gif

PAT の性質が原因で、組み込むある特定のアプリケーションはこのシナリオでペイロードの IP情報はたらくことができません。 この問題を解決するために、単一 IP アドレスよりもむしろ IP アドレスのサブネットを適用して下さい。

このアーキテクチャで IP アドレスが CPE に割り当てられるので NAP/NSP が設定し、解決するために CPE に Telnet で接続することは容易です。

CPE はサブスクライバによって異なるオプションを使用できますか。s プロファイル。 たとえば、なぜなら家庭 ユーザ CPE は PAT/DHCP なしで設定されるかもしれません。 複数の PC のサブスクライバの場合、CPE は家庭 ユーザのそれと PAT/DHCP か同じ方法のために設定することができます。 CPE に接続される IP Phone がある場合 CPE は複数の PVC のために設定されるかもしれません。

IP 管理

pppoa_arch_3.gif

PPPoA アーキテクチャでは、サブスクライバ CPE のための IPアドレス割り当てはダイヤル モデムで IPCPネゴシエーションを、PPP の同じ原則使用します。 IP アドレスはサービス タイプによってサブスクライバ使用割り当てられます。 サブスクライバは NSP からインターネットアクセスだけある場合、NSP はサブスクライバからのそれらの PPP セッションを終了し、ために IP アドレスを割り当てて下さい。 IP アドレスは定義された プールから、DHCPサーバ ローカルで割り当てられるか、または RADIUSサーバから適用します。 また、ISP はサブスクライバにサブスクライバが PPP セッションを始めるとき一組の静的な IP アドレスを提供し、し IP アドレスを動的に割り当てないそうではないかもしれません。 このシナリオでは、サービスプロバイダーはユーザを認証するのに RADIUSサーバだけ使用します。

サブスクライバは利用可能 な マルチプルサービスがあることを好む場合 NSP は SSG を設定する必要がある場合もあります。 以下は IP アドレスを割り当てるための可能性です。

  • SP はローカルプールか RADIUSサーバを通してサブスクライバに IP アドレスを提供するかもしれません。 ユーザがサービスを選択した後、SSG はユーザを転送しますか。その宛先への s トラフィック。 SSG がプロキシモードを使用している場合、最終 宛先は SSG が NAT のために可視アドレスとして使用する IP アドレスを提供するかもしれません。

  • PPP セッションはサービスプロバイダーで終了しませんか。s 集約ルータ。 彼らは結局 PPP セッションを終了するホームゲートウェイ トンネル伝送されるか、または転送されます、か最終 宛先に。 最終 宛先かホームゲートウェイは IP アドレスを動的に提供しているサブスクライバと IPCP を、それによりネゴシエートします。 スタティック アドレスは最終 宛先にそれらの IP アドレスを割り当て、それらにルートをある限りまた可能性のあるです。

Cisco 6400 NRPCisco IOS12.0.5DC Cisco 6400 プラットフォームは Cisco 600 シリーズ CPE IP サブネットが動的に PPPネゴシエーションの間に CPE で設定されるようにし。 このサブネットから 1 IP アドレスは CPE に割り当てられ、残りの IP アドレスは DHCP によるステーションに動的に割り当てられます。 この機能が使用されるとき、CPE はいくつかのアプリケーションを使用しない PAT のために設定される必要はありません。

サービス先への到達方法

PPPoA アーキテクチャでは、サービス の 宛先はさまざまな方法で到達することができます。 いくつかの最も一般に展開されたメソッドは次のとおりです:

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

  • L2TP トンネリング

  • SSG の使用

すべての 3 つのメソッドで CPE から固定一組の集約ルータの PVC に切り替えられる DSLAM に定義される固定一組の PVC があります。 PVC は DSLAM から集約ルータ ATMクラウドによるへのマッピング されます。

サービス の 宛先はまた他のメソッド SVC のそのような PPPoA、か Multiprotocol Label Switching/Virtual Private Network を使用して到達することができます。 これらのメソッドはこの資料の範囲を超えてあり、個別 の 文書で説明されています。

集約の PPP の終了

pppoa_arch_4.gif

サブスクライバによって始められる PPP セッションはルータのまたは RADIUSサーバを通したローカルデータベースを使用しているユーザを認証するサービスプロバイダーで終了されます。 ユーザが認証された後、IPCPネゴシエーションは起こり、IP アドレスは CPE に割り当てられます。 IP アドレスが割り当てられた後、CPE と集約ルータでホスト ルートが確立しましたあります。 サブスクライバに割り当てられる IP アドレスはエッジルータに可能なら、アドバタイズされます。 エッジルータはサブスクライバがインターネットにアクセスできるゲートウェイです。 IP アドレスが私用である場合、サービスプロバイダーはエッジルータにアドバタイジングの前にそれらをそれら変換します。

L2TP/L2F トンネリング

pppoa_arch_5.gif

L2TP を使用してアップストリーム終端地点へのサービスプロバイダーによる PPP セッション、か株式会社、トンネルまたはサービスプロバイダーで終えられるかわりに L2F か。s 集約ルータ。 この終端地点はユーザ名を認証し、サブスクライバ DHCP かローカルプールによって IP アドレスは割り当てられます。 このシナリオに関しては通常 L2TP Access Concentrator/ネットワーク アクセス サーバ(LAC/NAS)の間でおよびホームゲートウェイまたは L2TP Network Server (LNS)確立される 1 トンネルがあります。 LAC はドメイン名に基づいて着信セッションを認証します; ユーザ名は最終 宛先かホームゲートウェイで認証されます。

しかしこのモデルではユーザは最終 宛先にアクセスでき、ただ 1 つの宛先だけ一度にアクセスできます。 たとえば、CPE が rtr@cisco.com のユーザ名で設定されれば、その CPE の後ろの PC は Cisco ドメインにアクセスできるただことができます。 別の社内ネットワークに接続したいと思う場合その団体ドメイン名を反映するために CPE のユーザ名 および パスワードを変更する必要があります。 トンネル宛先はルーティング プロトコル、スタティック・ルート、または Classical IP over ATM をすることの使用によってこの場合(ATM が層として 2)好まれれば到達します。

Service Selection Gateway (SSG)の使用

/image/gif/paws/12914/pppoa_arch_6.gif

トンネリング上の SSG の主な利点はトンネリングが 1対1マッピングだけ提供する一方 SSG が一対多 サービスのマッピングを提供することです。 これはシングル ユーザがマルチプルサービスにアクセスを必要とする、または各必要が固有のサービスにアクセスする一つの場所の複数のユーザとき非常に有用になります。 SSG は異なるサービスで構成され、ユーザに利用可能である Webベースサービスの選択 ダッシュボード(SSD)を使用します。 ユーザは 1 つのサービスかマルチプルサービスに一度にアクセスできます。 SSG を使用するもう一つの長所はサービスプロバイダーが利用されるサービスおよびセッションタイムに基づいてユーザに請求書を送ることができるユーザは SSD によってサービスを断続的に回すことができますことであり。

/image/gif/paws/12914/pppoa_arch_7.gif

ユーザは PPP セッションがサブスクライバから入ると同時に認証されます。 ユーザはローカルプールまたは RADIUSサーバからの IP アドレスを割り当てられます。 ユーザの認証に成功された後、ソース オブジェクトは SSG コードによって作成され、ユーザはデフォルトネットワークにアクセスを可能になります。 デフォルトネットワークは SSDサーバが含まれています。 ブラウザを使用する、ユーザ ダッシュボードにログオンしましたり、AAAサーバによって、およびユーザによって認証されますか。RADIUSサーバで保存される s プロファイルはアクセスするべきサービスのセットを提供されます。

認証済みユーザがサービスを選択するたびに、SSG はそのユーザ向けのデスティネーションオブジェクトを作成します。 デスティネーションオブジェクトはその宛先のための宛先アドレス、DNSサーバ アドレス、およびホームゲートウェイからの割り当てられたソース IP アドレスのような情報が含まれています。 ユーザから入って来パケットか。s 側はデスティネーションオブジェクトに含まれている情報に基づいて宛先に転送されます。

SSG はプロキシサービス、透過パススルー、または PTA のために設定することができます。 Subscriber 要求がプロキシサービスにアクセスする場合、NRP-SSG はリモートRADIUSサーバに access-request を渡します。 access-accept を受け取った上で、SSG は access-accept のサブスクライバに応答します。 SSG はリモートRADIUSサーバにクライアントとして現われます。

透過パススルーはどちらの方向でも SSG によってルーティングされるに非認証加入者トラフィックを可能にします。 透過パススルー トラフィックを制御するのにフィルターを使用して下さい。

PTA は PPPタイプ ユーザによってしか使用することができません。 認証、許可および会計は丁度実行された 次 プロキシサービス サービス・タイプです。 サブスクライバは形式 user@service のユーザ名を使用してサービスにログオンします。 SSG は SSG にサービス プロファイルをロードする RADIUSサーバにそれを転送します。 SSG はサービス プロファイルによって規定 されるようにリモートRADIUSサーバに要求を転送しますか。s RADIUSサーバ アトリビュート。 要求が認証された後、IP アドレスはサブスクライバに割り当てられます。 NAT は実行された。 すべてのユーザトラフィックはリモートネットワークに集約されます。 PTA を使うと、ユーザは 1 つのサービスだけアクセスし、デフォルトネットワークか SSD にアクセスできないことをできます。

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

CPE は最初に動力を与えられるとき、集約サーバに LCP コンフィギュレーション要求を送信 し始めます。 また PVC が設定されている集約サーバは、仮想アクセスインターフェイスの LCP コンフィギュレーション要求を送信します(PVC と関連付けられる)。 各自が他のコンフィギュレーション要求を見るとき、彼らは要求を確認し、LCP 状態は開きます。

認証段階に関しては、CPE は集約サーバに認証要求を送信 します。 サーバは、設定によって、どちらか(供給された場合)ドメイン名に、またはローカルデータベースか RADIUSサーバを使用してユーザ名を基づいてユーザ認証します。 サブスクライバからの要求が username@domainname の形にある場合、集約サーバは 1 つがそこにまだあっていない場合宛先にトンネルを作成することを試みます。 トンネルが作成された後、集約サーバはサブスクライバから宛先に PPP 要求を転送します。 宛先は、それから、ユーザを認証し、IP アドレスを割り当てます。 サブスクライバからの要求がドメイン名が含まれない場合、ユーザはローカルデータベースによって認証されます。 SSG が集約ルータで設定される場合、ユーザは規定 されるようにデフォルトネットワークにアクセス、異なるサービスを選択するオプションを得ることができます。

結論

PPPoA は拡張性が高く、SSG 機能性を使用し、セキュリティを提供するので多くのサービスプロバイダーのための最も適したアーキテクチャになっています。 この用紙のフォーカスは PPPoA アーキテクチャだったので、詳細な SSG のような機能をカバーすることはできませんでした。 これらの機能はそれに続く用紙でカバーされます。 この資料で説明されていたまた個別 の 文書で異なるシナリオのための設定 例は表記され、説明されます。


関連情報


Document ID: 12914