JP4776582B2 - ネットワークシステム及び集約装置 - Google Patents

Description

本発明は、ネットワークシステム及び集約装置に係り、特に、アクセスネットワーク網を所有する通信事業者、企業等において、ユーザ端末（８０２．１Ｘ Ｓｕｐｐｌｉｃａｎｔを実装）を収容し、複数のネットワーク接続サービスを提供する８０２．１ＸのＡｕｔｈｅｎｔｉｃａｔｏｒとして機能する８０２．１Ｘ集約装置を備えるネットワークシステム及び集約装置に関する。

ブロードバンドによるインターネット接続の普及やアクセス回線の技術進歩によりＣＡＴＶ（Ｃｏｍｍｕｎｉｔｙ Ａｎｔｅｎｎａ ＴｅｌｅＶｉｓｉｏｎ）、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、ＦＴＴＨ（Ｆｉｂｅｒ Ｔｏ Ｔｈｅ Ｈｏｍｅ）、高速無線アクセス等、様々なブロードバンド接続を提供する通信事業者がある。利用者数、サービス、トラフィック量の増加につれ、設備投資、設備維持、運用保守コストも同様に増加している。
一方、パケット転送装置等のネットワーク製品を開発、製造する機器メーカーにおいても、このような変化に対応すべく、大容量の回線速度、データ転送能力、パケット転送能力、新しいテクノロジーを実装、提供する必要がある。
通信事業者には、伝送路設備、伝送交換設備、その付帯設備を保持運用し、エンドユーザやＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）等にサービスを提供する事業者（旧第一種通信事業者）と、旧第一種通信事業者に回線を借りてインターネット接続サービス、コンテンツサービス等を提供する事業者（旧第二種通信事業者）等に大きく分類することが出来る。旧第一種通信事業者において、旧第二種通信事業者に設備を提供する形態の事業者をホールセラーと呼ぶ。
本発明において焦点を当てるのは主にホールセラーである。ホールセラーの役割のひとつとしては、直接エンドユーザが接続されるアクセス回線、エンドユーザを収容するアクセスネットワーク網の保持、構築、運用、保守を行い、インターネット接続サービスを提供するＩＳＰ等へ、その足回りとしての網サービスを提供することである。ＩＳＰ等とは、アクセスネットワーク網のネットワーク上位箇所にて相互接続し、ユーザトラフィックの交換を行う。つまり、ホールセラーは、エンドユーザとＩＳＰ等との間に位置し、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ／ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）による通信トラフィックの橋渡しを行う網機能を有する。ＴＣＰ／ＩＰ通信の始点、終点となるエンドユーザ側の端末もしくはモデムと、ブロードバンドアクセス集線集約装置であるホールセラー側のＢＲＡＳ（Ｂｒｏａｄｂａｎｄ Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）との間においては、業界標準としてＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）プロトコルを使用するものがある。

ＰＰＰプロトコルを使用する利点としては、例えば、エンドユーザ接続要求時にユーザアカウント、パスワードによる認証機能が可能であること、Ｌ３（Ｌａｙｅｒ ３）プロトコルをカプセル化することにより様々な回線を意識せずに使用可能であること、ＩＰアドレスの付与が出来ること、アカウンティング情報の収集が出来ること、必要なときにだけＩＰアドレスを付与することにより、ＩＰアドレス数の有効利用が可能であること等が挙げられる。
また、認証処理を装置内管理情報で行わず、遠隔の一元管理された情報を利用する方式としては、主にＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ）プロトコルを使用するものがある。ＲＡＤＩＵＳサーバを使用することで、エンドユーザが異なるＢＲＡＳに接続される場合も認証情報を一括管理することが出来、エンドユーザ認証情報の追加、削除、変更管理が複数装置に分散されず煩雑にならなくなるという利点がある。
ＲＡＤＩＵＳクライアントとして動作するＢＲＡＳとＩＳＰ管理のＲＡＤＩＵＳサーバは、認証要求、認証応答、アカウンティング情報等の交換をＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）上にて行う。直接ＢＲＡＳと前述ＲＡＤＩＵＳサーバが通信する場合もあれば、ホールセラー、ＩＳＰ管理のＰｒｏｘｙ ＲＡＤＩＵＳ経由で通信する場合もある。Ｐｒｏｘｙ ＲＡＤＩＵＳを使用することにより、ＢＲＡＳの指定するＲＡＤＩＵＳサーバの指定を全ＢＲＡＳにて追加、削除、変更する必要が無くなる。例えば、他社ネットワークとの間で必要最低限のアクセスのみが通過出来るようにアクセス制御がされている場合、そのアクセス制限ポリシーを変更する必要が無くなる等の利点がある。

また、複数ＩＳＰを収容し、そのユーザトラフィックの送受信をする上で、アクセスネットワーク網およびＢＲＡＳにおいて、異ＩＳＰ間のトラフィックが混在させないことが必須となる。
しかし、ＩＳＰ単位で物理的にスイッチやルータやＢＲＡＳを複数台配置する構成は、アクセスネットワーク網全体の規模が収容ＩＳＰ数に比例して大きくなってしまい、機器購入コスト、運用コスト、運用負荷も上がってしまう。その為、装置内に論理的な仮想ルータを複数動作させ、通信経路を論理的に分けることにより、その課題を解決させることが可能となる。
また、仮想ルータ毎に動的ルーティングプロトコルを動作させ上位ネットワークへ冗長性を持たせること、アクセスフィルタリングにより不要なトラフィックのみ通過させたりもしくは逆に必要なトラフィックのみを通過させること、ＱｏＳ（Ｑｕａｌｉｔｙ Ｏｆ Ｓｅｒｖｉｃｅ）制御によるトラフィックの帯域制限、帯域保証、キューイング方法、キューイングされたパケットにおいて優先的にパケットを送出するスケジューリング方法等を用いた優先制御、様々な条件でパケットの転送を行うポリシールーティング、パケットを他のプロトコルによってカプセル化するトンネリング等多数の技術が実装されている。
複数ＩＳＰへインターネットサービスを提供しない通信事業者、すなわちアクセスネットワーク網を所有し、かつ、インターネット接続サービスも提供する一体型の通信事業者においては、ＩＳＰ毎トラフィックを分離する必要がなく、認証機能を有しないＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用することがあるが、ホールセラーのように接続されるユーザが複数ＩＳＰのうちどのＩＳＰのユーザか判断する為に、ＰＰＰが使用されているのが通例である。
また、大規模なホールセラーになるとＬ２ＴＰ（Ｌａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）トンネルを用いて、ＰＰＰ接続をＬ３ＶＰＮ（Ｌａｙｅｒ ３ Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ）にて離れたＩＰネットワーク越しに終端させる方式をとることが多い。

Ｌ２ＴＰは、ＬＡＣ（Ｌ２ＴＰ Ａｃｃｅｓｓ Ｃｏｎｃｅｎｔｒａｔｏｒ）と、ＬＮＳ（Ｌ２ＴＰ Ｎｅｔｗｏｒｋ Ｓｅｒｖｅｒ）に機能分担されている。エンドユーザの通信パケットを直接収容するＬＡＣは、認証要求時に使用されるユーザアカウントのドメイン部（フォーマット：ユーザアカウント＠ドメイン名／サンプル：ｔｅｓｔｕｓｅｒ１＠ｔｅｓｔｄｏｍａｉｎ１．ｃｏｍ）毎に、設定された転送先のＬＮＳ向けにＬ２ＴＰカプセル化を行う。また、ＬＡＣは、ＬＮＳ側からのＬ２ＴＰパケットに対してはＬ２ＴＰカプセル化解除を行い、エンドユーザへＰＰＰフレームを送出する。ＬＮＳ側でもインターネット側から受信したエンドユーザへ渡すべきパケットに対してＬ２ＴＰカプセル化処理を行いＬＡＣへ転送し、ＬＡＣから受信したエンドユーザの通信パケットをＬ２ＴＰカプセル化解除しインターネット側へ送出する。このようにＬＡＣ、ＬＮＳ間ではＰ２Ｐ（Ｐｅｅｒ−Ｔｏ−Ｐｅｅｒ）でＬ２ＴＰによるカプセル化通信が行わる。ＬＡＣ、ＬＮＳ間に位置する中継スイッチ及びルータ等のパケット転送装置は、エンドユーザの送受信するＰＰＰフレームを意識せずにＩＰ上で動作するＵＤＰフレームとしてパケット送受信を行う。
このような方式により、ＰＰＰ終端させるＬＮＳをＩＳＰ毎分割したり、ＰＰＰ接続数に応じＬＮＳを変更させたりすることが出来、Ｌ２ＴＰを使用しない方式に比べ、柔軟なネットワークを構築することが可能となる。
以上のようにＢＲＡＳやＬ２ＴＰ ＬＡＣ、ＬＮＳのようなブロードバンド集線集約装置は、多機能を実装、動作させ、さらにエンドユーザのアクセスが常に通過することにより、ホールセラーにとっては重要な位置付けとなっている。

また、有線、無線問わず、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）環境において、ユーザとそのユーザの接続するスイッチ間で認証する仕組みが、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃ Ｅｎｇｉｎｅｅｒｓ）によって規定されており、認証手段としてＥＡＰ（Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が使用され、これをＬＡＮ上で動作させることからＥＡＰｏＬ（ＥＡＰ ｏｖｅｒ ＬＡＮ）と呼ばれる。ＥＡＰには、例えば、ＥＡＰ−ＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ａｌｇｏｒｉｔｈｍ ５）、ＥＡＰ−ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）、ＥＡＰ−ＰＥＡＰ（Ｐｒｏｔｅｃｔｅｄ ＥＡＰ）、ＥＡＰ−ＴＴＬＳ（Ｔｕｎｎｅｌｅｄ ＴＬＳ）等の様々な認証アルゴリズムを使用して接続端末の認証を行うことが出来る。
８０２．１Ｘにおけるシステム構成要素は、スイッチやアクセスポイントに接続され、ネットワークへの接続を希望する端末もしくはモデムである「Ｓｕｐｐｌｉｃａｎｔ」と、認証要求の処理及び認証許可した場合、Ｓｕｐｐｌｉｃａｎｔをネットワークへ接続許可する「Ａｕｔｈｅｎｔｉｃａｔｏｒ」と、認証データベースを保持し、Ａｕｔｈｅｎｔｉｃａｔｏｒからの認証要求に対し認証可、不可の応答をする「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ」との３つに大きく分けられる。
この方式によれば、ＬＡＮ環境においてＳｕｐｐｌｉｃａｎｔのアクセス要求に応じてＡｕｔｈｅｎｔｉｃａｔｏｒは、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒを用いて認証処理を行い、認証が許可された場合、Ａｕｔｈｅｎｔｉｃａｔｏｒの接続されるポートもしくはエンドユーザのＭＡＣアドレス単位でＡｕｔｈｅｎｔｉｃａｔｏｒへの接続を許可する。
近年、Ｅｔｈｅｒｎｅｔ（商標登録）の普及の広がり、技術の進歩により、通信事業者の機器からエンドユーザ側の端末もしくはモデムまでＥｔｈｅｒｎｅｔ（商標登録）で接続されることが容易になってきている。その為、８０２．１Ｘを使用した認証方式もこのようなブロードバンドアクセス環境に適用出来ることが可能となって来ている。
また、特許文献１に８０２．１Ｘによるブロードバンドアクセス集線集約装置関する技術が開示されている。

特開２００３−２２４５７７号公報 ＩＥＴＦ、「Ｔｈｅ Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ （ＰＰＰ）」、ＲＦＣ１６６１ ＩＥＴＦ、「ＰＰＰ Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＥＡＰ）」、ＲＦＣ２２８４ ＩＥＴＦ、「Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＥＡＰ）」、ＲＦＣ３７４８ ＩＥＴＦ、「ＲＡＤＩＵＳ （Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｆｏｒ Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＥＡＰ）」、ＲＦＣ３５７９ ＩＥＴＦ、「Ｌａｙｅｒ Ｔｗｏ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ （Ｌ２ＴＰ）」、ＲＦＣ２６６１ ＩＥＴＦ、「Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」、ＲＦＣ２１３１ ＩＥＴＦ、「Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」、ＲＦＣ１５４１ ＩＥＴＦ、「Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」、ＲＦＣ１５３１ ＩＥＥＥ、「Ｐｏｒｔ−Ｂａｓｅｄ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ」、８０２．１Ｘ

Ｌ２ＴＰを使用した際の課題として、ユーザ通信に係るパケットが全てＬ２ＴＰカプセル化されていることから、ＬＡＣとＬＮＳの間にある中継ルータ、及びスイッチ等のパケット転送装置においては、そのカプセルを意識することが出来ない。そのようなパケット転送装置では、ユーザ毎、サービス毎のパケットフィルタリング及びＱｏＳ制御をすることが難しい、という課題が挙げられる。
ＬＡＮ環境にてＰＰＰプロトコルを扱うＰＰＰｏＥ（ＰＰＰ Ｏｖｅｒ Ｅｔｈｅｒｎｅｔ）においても、ＰＰＰｏＥ、ＰＰＰヘッダが付与され、パケットがカプセル化される為、同様の課題が起こり得る。
これは、例えば、図１の中継スイッチ１０２Ｂで示すように、上位ネットワーク方向または下位ネットワーク方向もしくは両方向へそれぞれ複数の接続ポートを持ち、同一ネットワーク内においてマルチポイントであるアクセスネットワークの構成において、多方面から流入するユーザ通信トラフィックが合流する場合に、ＱｏＳ制御できないことの課題が発生する。
図９にて例を挙げて説明をする。
中継パケット転送装置９０３は、１Ｇ ｂｐｓ（Ｇｉｇａ Ｂｉｔｓ Ｐｅｒ Ｓｅｃｏｎｄ）である３つのポート（９２５、９２６、９２７）に、カプセル化を実施する他のパケット転送装置（９０１、９０２）及びユーザ網９０４と接続され、マルチポイントのネットワークを構成している。この中継パケット転送装置９０３は、カプセル化された中身のパケット（エンドユーザが送受信するカプセル化されていないパケット）にあるポート番号、または、ＩＰヘッダ内ＤＳＣＰ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ）値を参照することが出来ないものとする。
パケット転送装置（９０１、９０２）のＱｏＳ設定値は、例えば、表９１０にあるように、電話、ＴＶ電話のサービスを上限帯域１００Ｍ ｂｐｓ（Ｍｅｇａ Ｂｉｔｓ Ｐｅｒ Ｓｅｃｏｎｄ）に制限し、映像系のサービスを上限帯域４００Ｍ ｂｐｓ、その他データ通信サービスにおいて上限帯域５００Ｍ ｂｐｓとする。カプセル化を実施するパケット転送装置（９０１、９０２）が、カプセル化しないポート（９２１、９２２）からパケット（９３１、９３２）を受信し、カプセル化するポート（９２３、９２４）からトラフィックを出力する場合、自身でカプセル化処理を実施する。このとき、パケット転送装置（９０１、９０２）は、ポート番号またはＤＳＣＰ値またはＵｓｅｒ Ｐｒｉｏｒｉｔｙ値を参照し、サービスタイプのクラス分けの判断をし、ＱｏＳ制御を実施することが出来る。その為、パケット転送装置（９０１、９０２）が、中継パケット転送装置９０３のポート９２７に繋がるユーザネットワーク９０４を宛先とした表９１１、９１２のようなトラフィックを受信した場合、その他データ通信サービスのパケットを１００Ｍ ｂｐｓ分破棄するだけで、残りのトラフィックについては表９１３、９１４のようにＱｏＳ制御を実施してそれぞれユーザネットワーク９０４を宛先としてポート（９２３、９２４）からカプセル化したパケット（９３３、９３４）を出力する。なお、説明をわかりやすくする為、カプセル化によるパケットサイズの増加は無視する。

中継パケット転送装置９０３は、ポート（９２５、９２６）において表９１３、９１４のトラフィックを受信すると、これをユーザネットワーク９０４の接続しているポート９２７に繋がる次パケット転送装置へ転送する動作を行う。このとき、合流したフレームは合計で１Ｇ ｂｐｓを超過する。中継パケット転送装置９０３では、ＱｏＳ設定の有無に関わらず、カプセル化されたパケット９３３、９３４のカプセル化される前のポート番号、ＤＳＣＰ値を参照することが出来ない為、３種のサービスパターンによるクラス分けを実施せずに、サービス種別に関係無く超過分のパケットを廃棄しパケット９３５を出力してしまう。その結果、トラフィック９１５のように本来優先して通過させたい電話、ＴＶ電話のサービスまで廃棄してしまうことが課題となる。
その為、Ｌ２ＴＰネットワークを構成し、ＬＡＣ、ＬＮＳのみにＱｏＳ制御を設定しただけでは、ＬＡＣ、ＬＮＳにおいては優先度の高い通信パケットは保護されるものの、中継のパケット転送装置においてその通信パケットが合流した際には優先度の高い通信パケットを破棄しないように制御することが困難であった。優先度の高い電話サービス、ＴＶ電話サービス、映像サービスの通信パケットを優先出力するアクセスネットワーク網を提供する為及び高品質確保の為には、中継のパケット転送装置においてもＱｏＳ制御を設定することが必要となる。
カプセル化する際にＥｔｈｅｒｎｅｔヘッダ内のＵｓｅｒ Ｐｒｉｏｒｉｔｙ値に優先度を反映させることにより、カプセルパケットが通過するネットワークにおいて一貫した優先度として扱う場合がある。しかし設定可能な優先度が３ビットしかないこと、中継パケット転送装置においては変更不可能であること、優先度を引き継ぐ為の実装と設定を必要とすること等のデメリットがある。
他の方式として上述した８０２．１Ｘにて考察すると、８０２．１ＸはＬ２ＴＰのようなカプセル処理を行わないことからＬ２ＴＰのようにＬＡＣ、ＬＮＳのような親子関係を持てず、柔軟かつＡｕｔｈｅｎｔｉｃａｔｏｒの冗長化、収容ユーザ数等による分散化を可能とするネットワーク機能を持たせることが難しい。また、８０２．１ＸにＬ２ＴＰなどカプセル化する技術を用いると、上述のような課題が発生する。
ホールセラーのように多数のＩＳＰを収容するアクセス網においては、ＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）により異ＩＳＰ間の通信を遮断するように設計することは可能である。しかし、Ｓｕｐｐｌｉｃａｎｔが直接収容されるスイッチをＡｕｔｈｅｎｔｉｃａｔｏｒとした場合、アクセスネットワークが大規模であったり、広範囲に配置される程、管理対象であるＡｕｔｈｅｎｔｉｃａｔｏｒの台数が増加し、管理が煩雑となる課題がある。

ＡｕｔｈｅｎｔｉｃａｔｏｒをＳｕｐｐｌｉｃａｎｔが直接収容されるスイッチより上位ネットワーク側に配置する場合（ユーザ〜Ａｕｔｈｅｎｔｉｃａｔｏｒ間の中継装置はＥＡＰｏＬフレーム透過機能を使用する）は、当該スイッチの冗長化を構成する為には、Ｌ２ネットワークにフラッディングされたＥＡＰｏＬをＡｕｔｈｅｎｔｉｃａｔｏｒ側で要不要の判断をすることが出来ない為、例えば、Ｌ２冗長化プロトコルであるＳＴＰ（Ｓｐａｎｎｉｎｇ Ｔｒｅｅ Ｐｒｏｔｏｃｏｌ）等を使用してＥＡＰｏＬフレームを処理させるＡｕｔｈｅｎｔｉｃａｔｏｒを選択させる方法となってしまう。この場合、セッション数や装置負荷、トラフィック量による分散化には対応出来なく、ネットワークのトポロジー管理も煩雑になってしまう。長時間の障害が致命的なネットワークを運用している場合、ユーザ数やトラフィック量に応じてＡｕｔｈｅｎｔｉｃａｔｏｒを分散することが必須となる為、現行８０２．１Ｘは大規模ネットワークには向いていないという課題がある。
また、特許文献１に開示された方式では、Ｌ２ＴＰのようにトラフィックを特定のパケット転送装置に集約させることまでは記載されておらず、大規模なネットワークで使用することは想定していない。また、そのまま大規模なネットワークに適用することは困難である。
本発明は、以上の点に鑑み、８０２．１Ｘをベースに、ＥＡＰｏＬフレームを複数のＡｕｔｈｅｎｔｉｃａｔｏｒが受信するようなマルチポイントであるアクセスネットワークにおいて、エンドユーザが直接収容されるスイッチに、ＩＳＰ単位等の条件を基に、ＥＡＰｏＬフレームを処理させたいＡｕｔｈｅｎｔｉｃａｔｏｒを選択させる機能を提供することを目的とする。また、本発明は、Ａｕｔｈｅｎｔｉｃａｔｏｒをグループ単位に配置したり、優先度に応じて変更したり、負荷により分散化したり、装置の障害及びメンテナンスにより切り替えをしたり、機器冗長プロトコルと組み合わせ冗長性を持たせることを可能とすることを目的のひとつとする。本発明は、Ｌ２ＴＰのように柔軟なエンドユーザアクセスの集約方式を保ちつつ、パケット転送処理を向上させることを可能とし、中継装置においてもＩＰｖ４、ＩＰｖ６の違いを意識すること無く、パケットフィルタリング、ＱｏＳ制御が可能とすることを目的のひとつとする。また、本発明は、フレームをカプセル化せずに、８０２．１ＸのＡｕｔｈｅｎｔｉｃａｔｏｒに親子関係をもたせたネットワークシステムを提供することを目的のひとつとする。

８０２．１Ｘ Ａｕｔｈｅｎｔｉｃａｔｏｒ実装のスイッチ（図１ １０１）は、８０２．１Ｘ Ｓｕｐｐｌｉｃａｎｔ実装のエンドユーザ端末もしくはモデムから直接通信フレームを受信する。スイッチは、エンドユーザ（図１ １０３）側の認証時のＥＡＰｏＬフレームに含まれるユーザアカウントのドメイン部（フォーマット：ユーザアカウント＠ドメイン名）、もしくはその他条件により、ＥＡＰｏＬフレームを転送すべきＡｕｔｈｅｎｔｉｃａｔｏｒ実装スイッチ（図１ １０４）及びＩＳＰ単位等のＶＬＡＮ空間を関連付けるテーブル（図２ ２１１、図３）を参照する。スイッチは、ＥＡＰｏＬフレームの形式を一部変更し、他のＡｕｔｈｅｎｔｉｃａｔｏｒ実装スイッチ宛にＥＡＰｏＬフレームを転送する手段を有する。一方、転送先のＡｕｔｈｅｎｔｉｃａｔｏｒからのＥＡＰｏＬフレームについては、ＥＡＰｏＬ転送を行う手段を有する。

本発明の第１の解決手段によると、
８０２．１ｘの規定に従い認証を行う端末又はモデムと接続される第１の通信装置と、
前記第１の通信装置とネットワークを介して接続され、前記端末又はモデムと認証サーバとの間で、該端末又はモデムの８０２．１ｘ認証のための認証フレームであるＥＡＰｏＬフレームを転送し、前記端末又はモデムが利用するＩＳＰネットワークに対して複数台が接続される複数の第２の通信装置と
を備え、
前記第１の通信装置は、
前記端末又はモデムから、宛先ＭＡＣアドレスに予め定められたＥＡＰｏＬ用ＭＡＣアドレスを付与し且つドメイン名情報又はプロバイダ識別情報を含む認証フレームであるＥＡＰｏＬフレームを受信する受信部と、
ドメイン名情報又はプロバイダ識別情報に対応して、前記認証フレームであるＥＡＰｏＬフレームを転送するための複数の前記第２の通信装置のＭＡＣアドレスが記憶された転送テーブルを有し、受信された認証フレームであるＥＡＰｏＬフレームのドメイン名情報又はプロバイダ識別情報に基づき、前記転送テーブルを参照し、対応する前記第２の通信装置のＭＡＣアドレスのひとつを取得するフレーム転送先決定部と、
受信された認証フレームであるＥＡＰｏＬフレームの宛先ＭＡＣアドレスとして前記フレーム転送先決定部が取得した前記第２の通信装置のＭＡＣアドレスを設定し、前記第２の通信装置のＭＡＣアドレスに従い、認証フレームであるＥＡＰｏＬフレームを前記第２の通信装置に転送するフレーム転送処理部と
を有し、
前記第２の通信装置は、
前記第１の通信装置から受信された認証フレームであるＥＡＰｏＬフレームに従い、前記認証サーバに認証要求を送信することで、前記認証サーバと前記端末又はモデムとで認証がされるネットワークシステムが提供される。

本発明の第２の解決手段によると、
８０２．１ｘの規定に従い認証を行う端末又はモデムと認証サーバとの間で、該端末若しくはモデムの認証のための認証フレームであるＥＡＰｏＬフレームを転送し、前記端末又はモデムが利用するＩＳＰネットワークに対して複数台が接続される複数の通信装置を備えたネットワークシステムにおいて、該通信装置とネットワークを介して接続され、及び、前記端末又はモデムと接続される集約装置であって、
端末又はモデムから、宛先ＭＡＣアドレスに予め定められたＥＡＰｏＬ用ＭＡＣアドレスを付与し且つドメイン名情報又はプロバイダ識別情報を含む認証フレームであるＥＡＰｏＬフレームを受信する受信部と、
ドメイン名情報又はプロバイダ識別情報に対応して、前記認証フレームであるＥＡＰｏＬフレームを転送するための複数の前記通信装置のＭＡＣアドレスが記憶された転送テーブルを有し、受信された認証フレームであるＥＡＰｏＬフレームのドメイン名情報又はプロバイダ識別情報に基づき、前記転送テーブルを参照し、対応する前記通信装置のＭＡＣアドレスのひとつを取得するフレーム転送先決定部と、
受信された認証フレームであるＥＡＰｏＬフレームの宛先ＭＡＣアドレスとして前記フレーム転送先決定部が取得した前記通信装置のＭＡＣアドレスを設定し、前記通信装置のＭＡＣアドレスに従い、認証フレームを前記通信装置に転送するフレーム転送処理部と
を備え、
前記通信装置が認証フレームであるＥＡＰｏＬフレームに従い、前記認証サーバに認証要求を送信することで、前記認証サーバと前記端末又はモデムとで認証がされるための集約装置が提供される。

本発明によると、８０２．１Ｘをベースに、ＥＡＰｏＬフレームを複数のＡｕｔｈｅｎｔｉｃａｔｏｒが受信するようなマルチポイントアクセスネットワークにおいて、エンドユーザが直接収容されるスイッチにＩＳＰ単位等の条件を基に、ＥＡＰｏＬフレームを処理させたいＡｕｔｈｅｎｔｉｃａｔｏｒを選択させる機能を提供するができる。また、本発明によると、Ａｕｔｈｅｎｔｉｃａｔｏｒをグループ単位に配置したり、優先度に応じて変更したり、負荷により分散化したり、装置の障害、メンテナンスにより切り替えをしたり、機器冗長プロトコルと組み合わせ冗長性を持たせることを可能とし、Ｌ２ＴＰのように柔軟なエンドユーザアクセスの集約方式を保ちつつ、パケット転送処理を向上させることを可能とすることができる。本発明によると、中継装置においてもＩＰｖ４、ＩＰｖ６の違いを意識すること無く、パケットフィルタリング、ＱｏＳ制御が可能な接続装置を提供することができる。また、本発明によると、フレームをカプセル化せずに、８０２．１ＸのＡｕｔｈｅｎｔｉｃａｔｏｒに親子関係をもたせたネットワークシステムを提供することができる。

図５は、８０２．１Ｘ ＥＡＰ認証シーケンスの例である。
本実施の形態の動作を説明する前に、まずＬＡＮ環境のユーザ認証方式として定められている８０２．１Ｘの標準動作を図５を参照して説明する。
まず、８０２．１Ｘ Ａｕｔｈｅｎｔｉｃａｔｏｒより認証ネゴシエーション開始を意味するＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙフレーム（５０２）を送出する。８０２．１Ｘ Ｓｕｐｐｌｉｃａｎｔとして動作するエンドユーザ端末もしくはモデムの実装によっては、Ｓｕｐｐｌｉｃａｎｔ側より認証ネゴシエーション開始を意味するＥＡＰ−Ｓｔａｒｔフレーム（５０１）が先に送出される場合もある。
ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙフレームを受信し、かつネットワークへの接続を希望するＳｕｐｐｌｉｃａｎｔは、ユーザアカウント情報をＥＡＰペイロード内に埋め込み、送信元ＭＡＣアドレスフィールドにＳｕｐｐｌｉｃａｎｔのＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）に設定されたＭＡＣアドレス、宛先ＭＡＣアドレスフィールドにＥＡＰｏＬ用ＭＡＣアドレス（０１：８０：ｃ２：００：００：０３）、Ｅｔｈｅｒｎｅｔ ＴｙｐｅフィールドにＥＡＰｏＬフレームであることを示す値（８８８ｅ）のＥｔｈｅｒｎｅｔヘッダを付与して、Ｅｔｈｅｒｎｅｔフレーム形式にしてＡｕｔｈｅｎｔｉｃａｔｏｒ宛にＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙフレーム（５０３）を送出する。
８０２．１Ｘ Ａｕｔｈｅｎｔｉｃａｔｏｒを実装させ、かつ機能させているスイッチは、宛先ＭＡＣアドレスフィールド、Ｅｔｈｅｒｎｅｔ Ｔｙｐｅフィールドが前述の通りであるフレームを受信すると、自装置宛のＥＡＰｏＬフレームであることを認識し、他のスイッチに転送せずに自装置ＥＡＰプロセス部にて認証処理を行う。なお、スイッチの実装に依存するが、ＥＡＰｏＬフレームを自装置にて処理を行わず、そのままの形で同一ＶＬＡＮ内の他の装置に転送する機能（ＥＡＰｏＬ透過機能）を持つものも存在する。
自装置でＥＡＰ処理を行うと判断したＡｕｔｈｅｎｔｉｃａｔｏｒは、自装置内に設定されたＲＡＤＩＵＳサーバへ、ＥＡＰｏＬフレーム内の情報を基に、ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔパケット（５０４）を送出する。ＥＡＰ認証アルゴリズムにより具体的な認証シーケンスは異なるが、ＡｕｔｈｅｎｔｉｃａｔｏｒはＳｕｐｐｌｉｃａｎｔとＲＡＤＩＵＳサーバ間の認証情報交換の為に、橋渡しの役割を果たす。

認証アルゴリズムが決まると、ＳｕｐｐｌｉｃａｎｔとＲＡＤＩＵＳサーバ間にてユーザアカウント、パスワードの照合を行う。ＲＡＤＩＵＳサーバにて認証許可された場合、ＲＡＤＩＵＳサーバは、ＲＡＤＩＵＳ Ａｔｔｒｉｂｕｔｅ Ｔｕｎｎｅｌ ＴｙｐｅフィールドにＳｕｐｐｌｉｃａｎｔに対してどのＶＬＡＮ空間に所属させるかを記した情報等をセットし、Ａｕｔｈｅｎｔｉｃａｔｏｒに対してＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔパケット（５１０）を送出する。認証方式や認証照合の結果、認証許可されなかった場合は、ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ｒｅｊｅｃｔパケットが送信され、当該Ｓｕｐｐｌｉｃａｎｔの認証処理を終了させる。
ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔパケット（５１０）を受信したＡｕｔｈｅｎｔｉｃａｔｏｒは、Ｓｕｐｐｌｉｃａｎｔの接続する物理ポートやＭＡＣアドレスに対しＶＬＡＮ空間への接続を可能とすると共に、Ｓｕｐｐｌｉｃａｎｔに対してＥＡＰ−Ｓｕｃｃｅｓｓパケット（５０９）を送出する。このＥＡＰ−Ｓｕｃｃｅｓｓパケットを受信したＳｕｐｐｌｉｃａｎｔは、ＤＨＣＰを使用してＩＰアドレスを要求し、ＩＰアドレスを払い出されるとＴＣＰ／ＩＰ通信が可能となる。また、Ａｕｔｈｅｎｔｉｃａｔｏｒは、ユーザアカウント、接続開始時間等のアカウンティング情報をＲＡＤＩＵＳサーバへ送付し、課金ログ、アクセスログとして記録する。このようにして、Ｓｕｐｐｌｉｃａｎｔの認証を完了し、ネットワークに接続可能とする仕組みを提供している。

以下、本実施の形態の構成・処理について説明する。
図１は、本実施の形態のネットワーク構成例である。
エンドユーザ側の端末もしくはモデム（端末装置）１０３は８０２．１Ｘ Ｓｕｐｐｌｉｃａｎｔ機能を実装する。端末もしくはモデム１０３は、ホールセラーの有するアクセスネットワーク網１０５内のスイッチ（１０１、１０２、１０４、１０９）等を中継し、及び、ユーザの希望するＩＳＰ（１０６Ａ、１０６Ｂ、１０６Ｃ）への相互接続箇所（１０８Ａ、１０８Ｂ、１０８Ｃ）と、ＩＳＰの運用保持するネットワークを経由して、インターネット１０７へ接続する。
アクセスネットワーク網１０５は、例えば、Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１と、中継Ｌ２スイッチ１０２と、Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４とを備える。さらに、ＲＡＤＩＵＳサーバ（認証サーバ）１１０を備えてもよい。
Ａｕｔｈｅｎｔｉｃａｔｏｒ（第１の通信装置、集約装置）１０１（以下、本実施の形態においてＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒと呼ぶ）は、有線区間１１１、無線区間１１２、またはその両方を使ったアクセス回線にてエンドユーザ側の端末もしくはモデム１０３を直接収容する。また、Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、８０２．１Ｘ Ａｕｔｈｅｎｔｉｃａｔｏｒに本実施の形態の手段を実装されるＬ２スイッチである。中継Ｌ２スイッチ１０２は、８０２．１Ｘ Ａｕｔｈｅｎｔｉｃａｔｏｒを実装しないもしくは機能させない。Ａｕｔｈｅｎｔｉｃａｔｏｒ（第２の通信装置）１０４（以下、本実施の形態においてＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒと呼ぶ）は、８０２．１Ｘ Ａｕｔｈｅｎｔｉｃａｔｏｒに本実施の形態の手段を実装し、エンドユーザを直接収容していないがＡｕｔｈｅｎｔｉｃａｔｏｒとしての振る舞いをするＬ２もしくはＬ３スイッチである。例えば、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１、ネットワーク内の中継スイッチ１０２を介して端末もしくはモデム１０３に接続される。ＲＡＤＩＵＳサーバ（１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ）は、認証データベースを保持する。なお中継Ｌ２スイッチ１０２は、必ずしも存在する必要はない。
それぞれの装置に設定すべきＶＬＡＮは、例えば、ＩＳＰ単位等のポリシーでトラフィックを分割する為のＶＬＡＮ、及び、管理者が装置を運用にてＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）やＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）による状態監視や確認、設定変更、装置操作のする為に必要なＶＬＡＮとなる。
ＩＳＰ単位等のポリシーでトラフィック分割する為のＶＬＡＮは、スイッチ１０１におけるスイッチ１０２と接続されるインターフェイス、スイッチ１０２におけるスイッチ１０１方向とスイッチ１０４方向と接続されるインターフェイス、スイッチ１０４におけるスイッチ１０２が接続されるインターフェイスにおいて設定されるこの間においては、フレーム転送をＬ２処理にて実施するように、ブロードキャストドメインとして構成する。
スイッチ１０４においては、ＩＳＰ単位等のポリシー毎に自装置の所有するＭＡＣアドレス、場合によってはＩＰアドレスを持たせる。これは、後述する認証パケットを受信、処理するインターフェイスとして利用されたり、エンドユーザ側の端末もしくはモデム１０３のＩＰゲートウェイアドレスとしてＤＨＣＰで伝えられ、受信パケットをＬ３処理にて送受信する用途として利用される。

本実施の形態におけるネットワークの構成例のひとつとして、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、例えば冗長構成とすることができる。例えば、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ａ）とＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ｂ）が冗長構成となり、一方が現用系、他方が予備系となってもよい。また、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ａ）とＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ｂ）に負荷が分散するように分散化してもよい。
また、本実施の形態におけるネットワークの他の構成例として、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、例えば、ＩＳＰ毎に備えることができる。例えば、ＩＳＰ−Ａに対応するＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ａ）と、ＩＳＰ−Ｃに対応するＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ｃ）を備えることができる。
Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０１Ａ）は、複数のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ａ、１０４Ｂ、１０４Ｃ等）のいずれかを選択してフレームを転送する。なお、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０１Ａ）と、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ（１０４Ａ、１０４Ｂ、１０４Ｃ等）との通信は、中継スイッチ（１０２Ｂ等）を介してもよい。なお、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１、中継スイッチ１０２では、例えば、複数のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４からのフレームが合流する。中継スイッチ１０２は、複数のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４とＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１との間で通信されるフレームに対して、ＱｏＳ制御（通信品質制御）を行う。

図２は、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒの構成図である。
Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ２０８（図１の１０１）は、例えば、受信部２２０と、フレーム種別判定処理部２０２と、ＥＡＰｏＬフレーム転送先決定部２０３と、フレーム転送処理部２０５と、フレーム転送テーブル２０６と、ＥＡＰｏＬ転送テーブル２１１と、ユーザステータスリスト（第１のステータスリスト）２１２とを備える。フレーム転送処理部２０５は、例えば、ＥＡＰｏＬフレーム転送処理部２０４を有する。
受信部２２０は、端末又はモデム１０３からドメイン名情報又はＩＳＰ識別情報（プロバイダ識別情報）を含む認証フレームを受信する。フレーム転送先決定部２０３は、例えば、受信された認証フレームのドメイン名情報又はプロバイダ識別情報に基づき、転送テーブル２１１を参照し、対応するＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のアドレス情報のひとつを取得する。フレーム転送処理部２０５は、取得されたＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のアドレス情報に従い、認証フレームをＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４に転送する。
エンドユーザ端末もしくはモデム（図２ ２０１、図１の１１１に相当）を直接収容するＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ（図２ ２０８）に本実施の形態により実装される情報には、例えば、ＥＡＰｏＬ転送テーブル（図２ ２１１、図３）、ユーザステータスリスト（図２ ２１２、図４）がある。

図３は、ＥＡＰｏＬ転送テーブルの構成例である。
ＥＡＰｏＬ転送テーブル２１１には、例えば、ドメイン部情報またはＩＳＰ識別情報（図３ ３１０）と、物理ポート情報（図３ ３１１）と、ＳｕｐｐｌｉｃａｎｔのＭＡＣアドレス情報（図３ ３１２）とに対応して、第１優先の転送先Ｓｅｒｖｅｒ ＡｕｔｈｅｎｔｉｃａｔｏｒのＭＡＣアドレス情報（図３ ３１４）と、割当ＶＬＡＮ番号（図３ ３１３）と、第２優先のＳｅｒｖｅｒ ＡｕｔｈｅｎｔｉｃａｔｏｒのＭＡＣアドレス情報（図３ ３１６）と、各Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒにそれぞれ対応する複数のＳｅｒｖｅｒ Ｐｒｉｏｒｉｔｙ値（図３ ３１５、３２１）と、監視間隔（図３ ３１７）と、監視タイムアウト値（図３ ３１８）と、監視回数（図３ ３１９）と、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ Ｓｔａｔｕｓ（図３ ３２０）とが記憶される。
例えば、これらの情報は、適宜のＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）に保持することができる。ＥＡＰｏＬ転送テーブル２１１は、例えば、ドメイン部情報またはＩＳＰ識別情報（図３ ３１０）と、物理ポート情報（図３ ３１１）と、ＭＡＣアドレス情報（図３ ３１２）のいずれかを検索条件として、対応する各情報を選択可能である。
ドメイン部情報は、ＥＡＰによる認証要求時に含まれる認証時に使用されるユーザアカウントのドメイン部情報である。ＩＳＰ識別情報は、Ｓｕｐｐｌｉｃａｎｔ機能を構成するプログラムがユーザアカウントに付与する。物理ポート情報（図３ ３１１）は、予め装置内に設定されたエンドユーザからのフレームを受信する物理ポートを示す。
ＭＡＣアドレス情報（図３ ３１２）は、Ｓｕｐｐｌｉｃａｎｔ１０３の予め設定されたＭＡＣアドレス情報である。Ｓｅｒｖｅｒ ＡｕｔｈｅｎｔｉｃａｔｏｒのＭＡＣアドレス情報（図３ ３１４、３１６）は、エンドユーザ側から送信されるＥＡＰｏＬフレームを転送させたいＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＭＡＣアドレスを示す。この例では、第１優先、第２優先のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４があるが、ひとつでもよいし、三つ以上あってもよい。割当ＶＬＡＮ番号（図３ ３１３）は、エンドユーザを前記検索条件を基にグループ分けする為のＶＬＡＮを識別する番号（識別子）である。Ｓｅｒｖｅｒ Ｐｒｉｏｒｉｔｙ値（図３ ３１５）は、例えば、第２優先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒへフレーム転送を切り替える為の契機として使用される。

監視間隔（図３ ３１７）、監視タイムアウト値（図３ ３１８）、監視回数（図３ ３１９）は、転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒの転送切り替え契機である稼動状態監視の為のＩＣＭＰもしくは、ＩＥＥＥ ８０２．１ａｇ、ＩＴＵ−Ｔ Ｙ．１７３１のようなＥｔｈｅｒｎｅｔ ＯＡＭ（ｏｐｅｒａｔｉｏｎｓ、ａｄｍｉｎｉｓｔｒａｔｉｏｎ、ｍａｉｎｔｅｎａｎｃｅ）と呼ばれるＬ２上で動作する回線ヘルスチェック機能にて使用される。Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ Ｓｔａｔｕｓ（図３ ３２０）は、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒの障害、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒまでの経路における障害によりＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒへの到達不可を検知した場合や、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒより転送不可の旨を受け取った場合、またはこれらと逆にＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒへ転送可と判断した場合、等にＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒへの転送可不可状態（Ａｃｔｉｖｅ／Ｉｎａｃｔｉｖｅ）が記録される。
このＥＡＰｏＬ転送テーブル２１１は、運用管理者により追加、削除、任意の値に環境、運用ポリシーに合わせて変更することを可能とする。この情報はＳｕｐｐｌｉｃａｎｔとの間で使用されるＥＡＰによる認証処理の際に使用される。

図４は、ユーザステータスリストの構成例である。
ユーザステータスリスト２１２は、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１においては、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４から受信したフレームをエンドユーザへ転送すべきかどうかを判断する為に利用される。
Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１のユーザステータスリスト２１２は、例えば、ＳｕｐｐｌｉｃａｎｔのＭＡＣアドレス４０１と、ユーザステータス情報４０２と、割当ＶＬＡＮ番号４０３と、転送先Ｓｅｒｖｅｒ ＡｕｔｈｅｎｔｉｃａｔｏｒのＭＡＣアドレス４０４とが記憶される。
Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４からＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１へ送出されるフレームの宛先ＭＡＣアドレスフィールドには、エンドユーザ側の端末もしくはモデム１０３のＭＡＣアドレスがセットされている。もし、中継網のＦＤＢ（Ｆｉｌｔｅｒｉｎｇ ＤａｔａＢａｓｅ）情報がエージングアウトしていた場合、Ｌ２ネットワークにおけるフレームのフラッディングが発生し、複数のＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒがフレームを受信する可能性がある。
その為、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、ユーザステータスリスト２１２を参照して宛先ＭＡＣアドレスフィールドにセットされているＭＡＣアドレスが自配下のエンドユーザに対するものかどうかを判断する。例えば、エンドユーザ側の端末もしくはモデムのＭＡＣアドレス情報（図４ ４０１）と、現在のユーザステータス情報（図４ ４０２）とを保持したユーザステータスリスト２１２により、受信したフレームのＶＬＡＮタグフィールドのＶＬＡＮ番号とユーザステータスリスト２１２に記載された割当ＶＬＡＮ番号（図４ ４０３）に合致し、かつ、受信フレームの宛先ＭＡＣアドレスフィールドの情報が、ユーザステータスリスト２１２に記載されたユーザＭＡＣアドレスであるリスト４０１に合致するか判断する。合致した場合、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、このフレームをエンドユーザ側の端末もしくはモデム１０３に、ＶＬＡＮタグを外し、それ以外はそのままの形で転送する。前記条件に合致しないフレームを受信した場合は、当該フレームを廃棄する。なお、マルチキャストＭＡＣアドレス宛、ブロードキャストＭＡＣアドレス宛のフレームにおいてはこの限りではない。
Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４においてもユーザステータスリスト（第２のステータスリスト）４１０を保持する。Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のユーザステータスリスト４１０は、例えば、ＳｕｐｐｌｉｃａｎｔのＭＡＣアドレス４１１と、ユーザステータス情報４１２と、割当ＶＬＡＮ番号４１３とが記憶される。

これもＬ２ネットワークにおけるフレームフラッディングにより複数のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４からフレームがＩＳＰ１０６に出力される可能性がある為である。
その為、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、受信フレームの送信元ＭＡＣアドレスフィールドにセットされているＭＡＣアドレスが自配下のエンドユーザに対するものかどうかを判断する。例えば、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、エンドユーザ側の端末もしくはモデムのＭＡＣアドレス情報（図４ ４１１）と現在のユーザステータス情報（図４ ４１２）を保持したユーザステータスリスト４１０により、受信したフレームのＶＬＡＮタグフィールドのＶＬＡＮ番号とユーザステータスリスト４１０に記載された割当ＶＬＡＮ番号（図４ ４１３）が合致し、かつ、受信フレームの送信元ＭＡＣアドレスフィールドの情報が、ユーザステータスリストに記載されたユーザＭＡＣアドレスであるリストに合致するか判断する。合致した場合、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、このフレームをＩＳＰ側にＶＬＡＮタグを外し、それ以外はそのままの形で転送する。前記条件に合致しないフレームを受信した場合は、当該フレームを廃棄する。なお、マルチキャストＭＡＣアドレス宛、ブロードキャストＭＡＣアドレス宛のフレームにおいてはこの限りではない。
次に動作シーケンスを説明する。

図６は、本実施の形態の認証シーケンス図である。図７、図８は、ＥＡＰｏＬフレームフォーマットの例である。
まず、現行８０２．１Ｘ同様、エンドユーザ側の端末もしくはモデム１０３によるＥＡＰ−Ｓｔａｒｔフレーム（図６ ６０１）、もしくは、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１によるＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙフレーム（図６ ６０２）の送信にて、ＥＡＰネゴシエーションが開始される。
ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙフレームを受信し、かつネットワークへの接続を希望するエンドユーザ側の端末もしくはモデム１０３は、予め定められたドメイン名を含むユーザアカウント情報又はＩＳＰ識別情報をＥＡＰペイロード７０４内に埋め込み、送信元ＭＡＣアドレスフィールド７０２に自身のＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）に設定されたＭＡＣアドレス、宛先ＭＡＣアドレスフィールド７０１に予め定められたＥＡＰｏＬ用ＭＡＣアドレス（０１：８０：ｃ２：００：００：０３）、Ｅｔｈｅｒｎｅｔ Ｔｙｐｅフィールド７０３にＥＡＰｏＬフレームであることを示す値（８８８ｅ）のＥｔｈｅｒｎｅｔヘッダを付与し、Ｅｔｈｅｒｎｅｔフレーム形式にしてＡｕｔｈｅｎｔｉｃａｔｏｒ宛にＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙフレーム（図６ ６０３）を送出する。
このＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＩｄｅｎｔｉｆｙフレームをＳｕｐｐｌｉｃａｎｔ側接続インターフェイス（図２ ２２０）にて受信したＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、フレーム種別判定処理部（図２ ２０２）にて受信したフレームが、ＥＡＰｏＬフレームであることを認識する。例えば、フレームの宛先ＭＡＣアドレス７０１、Ｔｙｐｅフィールド７０３を参照して認識できる。
次に、ＥＡＰｏＬフレーム転送先決定部（図２ ２０３）にＥＡＰ処理を引き渡す。なお、ＥＡＰｏＬ以外であれば、フレーム転送処理部２０５に処理を引き渡す。ＥＡＰｏＬフレーム転送先決定部２０３では、このＥＡＰｏＬフレームのペイロードに含まれるドメイン名やＩＳＰ識別情報に基づき、上述のＥＡＰｏＬ転送テーブル情報２１１（図３）を検索し、このＥＡＰｏＬフレームを転送すべきＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＭＡＣアドレス情報（３１４、３１６）、ＩＳＰ単位等にネットワークをグループ分けする為の管理ＶＬＡＮ番号（図３ ３１３）等を取得する。なお、ＥＡＰｏＬ転送テーブル情報２１１に記憶された複数のＭＡＣアドレス３１４、３１６からひとつのＭＡＣアドレスを取得する手法については後に詳しく述べる。

ＥＡＰｏＬフレーム転送処理部（図２ ２０４）は、このＥＡＰｏＬフレーム（図２ ７００、図７ ７００）のＥｔｈｅｒｎｅｔヘッダ内の宛先ＭＡＣアドレスフィールド（図７ ７０１）を、ＥＡＰｏＬ用ＭＡＣアドレス（０１：８０：ｃ２：００：００：０３）から、取得されたＥＡＰｏＬフレームの転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＭＡＣアドレス（図３ ３１４、３１６、図７ ７１１）に付け替える。また、送信元ＭＡＣアドレスフィールド（図７ ７１２）、Ｅｔｈｅｒｎｅｔ Ｔｙｐｅフィールド（図７ ７１４）は変更せず、割当ＶＬＡＮ番号（図３ ３１３、図７ ７１３）を付加する。ＥＡＰｏＬフレーム転送処理部（図２ ２０４）は、転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４宛にユニキャストフレームとして、フレーム転送テーブル（図２ ２０６）の情報に従い、該当するＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４宛にＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙフレーム（図６ ６０４）をＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４側の接続インターフェイス（図２ ２２１）より送信し、ＥＡＰ処理をＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４に委ねる。フレーム転送テーブル（図２ ２０６）は、例えば、転送先のＭＡＣアドレスに対応して、出力するポート情報、インターフェイス情報が予め記憶されている。また、ＥＡＰｏＬフレーム転送処理部（図２ ２０４）は、受信フレーム内の各情報、転送テーブル２０６から取得された各情報基づき、ユーザステータスリスト（図２ ２１２、図４ ２１２）にユーザＭＡＣアドレス情報（図４ ４０１）、ユーザステータス情報（図４ ４０２）、割当ＶＬＡＮ情報（図４ ４０３）、転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４ ＭＡＣアドレス情報（図４ ４０４）を書き込む。
上記のようなＭＡＣアドレスの付け替えとは別に、ＥＡＰｏＬフレームを新たにＵＤＰ ｏｖｅｒ ＩＰ、ＴＣＰ ｏｖｅｒ ＩＰであるパケットにカプセル化することでも同様な動作が可能である。この場合は、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１及びＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４にカプセル化された認証パケットを送受信する為のＩＰアドレスが必要となる。Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１のＥＡＰｏＬ転送テーブル２１１内の転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ ＭＡＣアドレス３１４、３１６の代わりに、転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ ＩＰアドレスの情報を持たせる。パケットの送信先ＭＡＣアドレスフィールド、送信先ＩＰアドレスフィールドには互いのＭＡＣアドレス、ＩＰアドレスがセットされ、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１とＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４においてＰ２Ｐで通信すると共に、双方で発信するパケットのカプセル化、受信するパケットのカプセル解除化を行い、ＥＡＰｏＬフレームを取り出すことが出来る。その結果、上述と同様の認証動作を行え、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４に設定したＩＰアドレスは、後述のＤＨＣＰによるＩＰゲートウェイアドレスとして通知することも可能となる。

次に、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１が転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４を選択する方法について説明する。
転送元Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１のＥＡＰｏＬフレーム転送先決定部２０３では、認証要求をどのＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４へ転送すべきかを判断しているが、これはＥＡＰｏＬ転送テーブルのＳｅｒｖｅｒ Ｐｒｉｏｒｉｔｙ値（図３ ３１５）に基づき判断されることができる。
Ｓｅｒｖｅｒ Ｓｔａｔｕｓ（図３ ３２０）がＡｃｔｉｖｅ状態であるＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４が複数存在する場合、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１におけるＥＡＰｏＬフレーム転送アルゴリズムとしては、Ｐｒｉｏｒｉｔｙ値３１５が最も高いＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のみへＥＡＰｏＬフレームを転送するモードと、Ｐｒｉｏｒｉｔｙ値３１５の重みに従ってＥＡＰｏＬフレームの転送を割り振るモードを有する。これにより高い優先度から順にＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４を使用していく運用形態と、優先度の重みに従い公平にＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４を使用していく運用形態を選択することが可能となる。
例えば、図３の例においては、ドメイン名が「ＡＡＡ．ｃｏｍ」の受信フレームに対して、Ｐｒｉｏｒｉｔｙ値が高いＭＡＣアドレス情報「００：００：００：０１：００：Ａ１」を選択するようにしてもよいし、複数のＰｒｉｏｒｉｔｙ値「１０００」、「５００」に応じて、ＭＡＣアドレス情報「００：００：００：０１：００：Ａ１」と「００：００：００：０１：００：Ａ２」を、２対１の割合（又は１対２の割合）で選択するようにしてもよい。
Ｐｒｉｏｒｉｔｙ値３１５が「０」となった場合は、Ｓｅｒｖｅｒ Ｓｔａｔｕｓ３２０をＩｎａｃｔｉｖｅ状態とし、当該Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４へのＥＡＰｏＬフレームの転送を停止する。
このＰｒｉｏｒｉｔｙ値３１５は、例えば、ヘルスチェックにてタイムアウトになった場合に「０」とされる他、接続ユーザ数に応じて増減することが出来る。接続ユーザ数１に対して１を増減することも出来れば、ユーザ接続数が１０００を超える時点もしくは下回る時点で一度に１０００を増減させることが出来る。Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４においては、ユーザ接続数、接続ポートの使用帯域幅帯域幅、ＣＰＵ使用率等の負荷に応じて、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１へ自装置への転送を停止するように（例えば、Ｐｒｉｏｒｉｔｙ値を０にするように）伝えること出来る。このようにＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４の転送先を制御することが可能となり、負荷分散も可能となる。なお、負荷については上述の例以外にも適宜の負荷でもよい。

転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４を対象として、ＩＣＭＰもしくは、ＩＥＥＥ ８０２．１ａｇのようにＬ２上で動作する定期的な回線ヘルスチェックは、認証フレームを転送してよいかどうかの確認をする為に行われる。これは、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１がＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ監視間隔（図３ ３１７）の間隔でヘルスチェックフレームを送出し、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４からの応答フレームがＳｅｒｖｅｒ Ｔｉｍｅｏｕｔ値（図３ ３１８）までに応答が無い場合、Ｓｅｒｖｅｒ監視回数（図３ ３１９）から「１」を減算する。これを繰り返し、Ｓｅｒｖｅｒ監視回数が「０」になった場合は、転送先のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４へフレームを転送すべきではないと判断し、Ｓｅｒｖｅｒ Ｓｔａｔｕｓ（図３ ３２０）をＩｎａｃｔｉｖｅへ状態変更し、Ｓｅｒｖｅｒ Ｐｒｉｏｒｉｔｙ値（図３ ３１５）を「０」（最低値）とする。
Ｉｎａｃｔｉｖｅ状態であるＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４へは一定時間認証フレームを転送せずに、転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４の対象外とする。一定時間後、Ｉｎａｃｔｉｖｅ状態のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４へのヘルスチェックを行い、転送してよいと確認が取れた場合（応答を受信した場合）は、Ｓｅｒｖｅｒ Ｓｔａｔｕｓ３２０をＡｃｔｉｖｅへ状態変更し、再び転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４の対象とする。
Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１からＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙフレーム６０４を受信したＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、現行８０２．１Ｘ ＡｕｔｈｅｎｔｉｃａｔｏｒがＥＡＰｏＬフレームを受信した際と同様に、装置内に設定された認証サーバ１１０へＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔパケット（図６ ６０５）にて認証要求を行う。この際に、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、受信フレームの各情報に基づき、ユーザステータスリスト４１０にユーザＭＡＣアドレス情報（図４ ４１１）、ユーザステータス情報（図４ ４１２）、割当ＶＬＡＮ情報（図４ ４１３）を書き込む。
なお、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、エンドユーザ側の端末もしくはモデム１０３に対しＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙフレームを送信していないが、ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙフレームを受信し、ＥＡＰ処理が出来るよう実装する。実際にエンドユーザ側の端末もしくはモデム１０３にはＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１からＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙフレームが送信されている為、エンドユーザ側の端末もしくはモデム１０３のＳｕｐｐｌｉｃａｎｔ実装を変更する必要は無い。

これより先は認証アルゴリズムに従い、エンドユーザ側の端末もしくはモデム１０３とＲＡＤＩＵＳサーバ１１０の認証ネゴシエーションをＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４が共に橋渡しするように、ＥＡＰｏＬフレームとＲＡＤＩＵＳパケットの互換（図６ ６０６〜６１１）を行う。この際もＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１からＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４宛に送出されるＥＡＰｏＬフレームは、宛先ＭＡＣアドレスフィールドがＥＡＰｏＬフレーム転送先のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＭＡＣアドレスに変更される。一方、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４からＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１宛に送出されるＥＡＰｏＬフレームの宛先ＭＡＣアドレスフィールドには、エンドユーザ側の端末もしくはモデム１０３のＭＡＣアドレス（図８ ８０５）を、送信元ＭＡＣアドレスフィールド（図８ ８０２）にはＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＭＡＣアドレスをセットし送出する。Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１からエンドユーザ側の端末もしくはモデム１０３に対して送出されるＥＡＰｏＬフレームは、ＶＬＡＮタグ（図８ ８０３）を取り除き、宛先ＭＡＣアドレスフィールド（図８ ８０１、図８ ８１１）、送信元アドレスフィールド（図８ ８０２、図８ ８１２）はそのままの形で送出する。
ＲＡＤＩＵＳサーバ１１０によってユーザアカウント、パスワードを照合した結果、認証許可となった場合、ＲＡＤＩＵＳサーバ１１０からＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４へＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ（図６ ６１２）パケットによりＲＡＤＩＵＳ Ａｔｔｒｉｂｕｔｅ Ｔｕｎｎｅｌ Ｔｙｐｅフィールドにエンドユーザ側の端末もしくはモデム１０３が接続されている物理ポート、もしくはそのＭＡＣアドレスに対してどのＶＬＡＮ空間に所属させるかを記した情報を含む、各種ＲＡＤＩＵＳ Ａｔｔｒｉｂｕｔｅを送出する。これにより、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、ＥＡＰｏＬフレームにて認証要求を受信したＭＡＣアドレスに対して該当ドメイン通信用ＶＬＡＮ番号を割り当て、エンドユーザ側の端末もしくはモデム１０３を適切なＶＬＡＮ空間に接続可能とすると共に、ＥＡＰ−Ｓｕｃｃｅｓｓフレーム（図６ ６１４）をＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１へ送出する。

また、ＲＡＤＩＵＳサーバ１１０からのＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔパケットによって、エンドユーザに通知するエンドユーザが接続されるＶＬＡＮ情報が誤って伝えられてしまった場合、接続ポリシーの異なるドメインが同じＶＬＡＮを割り当ててしまうおそれがある。その為、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４にて各ドメインで使用されるＶＬＡＮ番号を保持し、ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔパケットで割り当てられたＶＬＡＮ番号より優先し、ユーザ接続ＭＡＣアドレスが接続されるＶＬＡＮ番号を決定するという実装をした方が、安定したアクセスネットワーク網を維持することが出来る。
ＥＡＰ−Ｓｕｃｃｅｓｓフレームを受信したＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、宛先ＭＡＣアドレスフィールド８０１とＶＬＡＮタグ８０３を精査し、現在認証ネゴシエーション中のユーザステータスリスト２１２に記載されているＶＬＡＮ番号とユーザＭＡＣアドレス値に一致した場合、ユーザステータス情報４０２を更新し（例えば、接続中とし）、エンドユーザ側の端末もしくはモデム１０３をＶＬＡＮ空間に接続可能とすると共に、ＥＡＰ−Ｓｕｃｃｅｓｓフレーム（図６ ６１５）を送出する。
上述の動作を経て、エンドユーザ側の端末もしくはモデム１０３は、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４までのＬ２通信を可能とする。
その後、ＥＡＰ−Ｓｕｃｃｅｓｓフレームを受信したエンドユーザ側の端末もしくはモデム１０３は、ＩＰアドレスを取得する為に、ＤＨＣＰパケット（アドレス配布要求パケット）をＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１方向にブロードキャスト送信する。このＤＨＣＰパケットは、複数のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４まで到達しまうことから、接続させるべきでないＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４にも届いてしまうことを防ぐ為の実装が必要となる。
基本的には、複数のＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４宛にＤＨＣＰパケットが届いたとしても、そのフレームを必要とするＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のみがＤＨＣＰ処理（アドレス配布処理）を続行する方式でも可能である。この方式では、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４が、ＤＨＣＰパケットの送信元ＭＡＣアドレスフィールドを参照し、当該ＭＡＣアドレスからのフレーム転送を許可しているかどうかユーザステータスリスト４１０を参照することで、自配下にそのユーザが接続されているかどうかを確認する。接続されている場合（ユーザステータスリスト４１０に該当するＭＡＣアドレスが記憶されている場合）は、ＤＨＣＰ処理を行い、接続されていない場合は、以後のＤＨＣＰ処理を行わない実装とする。

もしくは、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、受信したＤＨＣＰパケットの送信元ＭＡＣアドレスフィールドに基づきユーザステータスリスト２１２参照することで、エンドユーザ側のＭＡＣアドレスが認識出来る。また、ユーザステータスリスト２１２を参照することで、どのＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４にフレームを転送すべきかを知っている為（図４ ４０４）、送信先ＭＡＣアドレスフィールドを当該Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＭＡＣアドレス４０４に変更し、ＤＨＣＰパケットを送信する。
以上の方式によれば、アクセスネットワーク網にＤＨＣＰパケットが氾濫することを防ぐことが可能となる。
ＤＨＣＰパケットを自装置で処理すると判断したＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、ホールセラーもしくはＩＳＰ等の管理するＤＨＣＰサーバへＤＨＣＰリレーを行い、ＤＨＣＰ情報の交換を行う。
また、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、エンドユーザ側の端末もしくはモデム１０３に対しては、受信したＤＨＣＰパケットを他のエンドユーザ側へ送出しない方が好ましい。これは、エンドユーザ側でＤＨＣＰサーバを稼動させてしまうことにより、意図しないＩＰアドレスが付与されてしまうことを防ぐ為である。
上述のような動作により、最終的には通常ＤＨＣＰ処理と同様にエンドユーザ側の端末もしくはモデム１０３へＩＰアドレス、デフォルトゲートウェイのＩＰアドレス、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ等の情報が付与される。
エンドユーザ側の端末もしくはモデム１０３は、ＩＰ通信によるデフォルトゲートウェイとしてＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＶＬＡＮ毎に保持されるＩＰアドレスが設定されることが出来る。エンドユーザ側の端末もしくはモデム１０３からのインターネットアクセスはＩＰパケットのファーストホップをＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４とし、その間の通信はＰＰＰやＬ２ＴＰのようなヘッダが付与されず、ＶＬＡＮタグが付与されただけのイーサネットフレームにて処理することが可能となる。その為、近年Ｌ２スイッチがＬ３、Ｌ４ヘッダフィールドの条件を基にパケットフィルタリング、ＱｏＳ制御等のパケット転送処理を可能とする実装が多いことから、ユーザ単位（例えば、優先処理させたいＭＡＣアドレス、プレミアムサービスドメイン用ＶＬＡＮタグ）、サービス単位（電話、映像サービス等をＬ３、Ｌ４ヘッダフィールドにより識別）でのトラフィックエンジニアリングが行え、かつ柔軟なネットワークを構築可能とし、現行では難しい効率よくかつ高品質なキャリアアクセスネットワークを実現することが出来るようになる。

エンドユーザ側の端末もしくはモデム１０３に対しての死活監視として、Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１はＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙフレーム（図６ ６１５）にて定期的にチェックを行う。このフレームに対してエンドユーザ側からのＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙフレーム（図６ ６１６）による応答が無い場合、エンドユーザが使用不可になったことを認識する。Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１は、そのＭＡＣアドレスを通信ＶＬＡＮから削除すると共に、送信元ＭＡＣアドレスフィールドをそのエンドユーザの端末もしくはモデム１０３のＭＡＣアドレス、送信先ＭＡＣアドレスフィールドを転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４のＭＡＣアドレスとしたＥＡＰ−Ｌｏｇｏｆｆフレーム（図６ ６１７）を送信し、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４へもそのＭＡＣアドレスが使用不可になったことを伝える。これを受信したＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４においても同様に、転送不可としてエンドユーザＭＡＣアドレスの削除を行う。
また、所定のＭＡＣアドレスを送信元としたトラフィックが一定時間経っても増加しない場合、接続されているものの無通信であることを認識し、同様の動作を行わせることが出来る。これによりＩＰアドレスの有効活用が可能となる。
Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４は、エンドユーザのネットワーク接続時（具体的にはＥＡＰ−Ｓｕｃｃｅｓｓフレームを送信した際）、切断時（具体的にはＥＡＰ−Ｌｏｇｏｆｆフレームを受信した際）に、ＲＡＤＩＵＳサーバ１１０へアカウンティング情報を送付する。ただし、同一ＶＬＡＮ内の通信はＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４を介さず、その手前の中継スイッチ１０２にて折り返し通信される場合があり、正しく送受信フレーム数、オクテット数が取得出来ないことも考えられる。また、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４にて一括したアクセスフィルタリング等の制御をする場合も、中継スイッチ１０２での折り返し通信を許可することで、そのアクセスフィルタリング制御が意味を成さなくなってしまう場合もある。その為、エンドユーザの送出するトラフィックは、全てＳｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４を介して通信させるように実装させる場合、中継スイッチ１０２においてＡｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０１の接続されている側のポートから入力されたフレームを、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１０４の接続されている側のポートのみに転送することで可能となる。

以上による動作により、８０２．１Ｘ認証を大規模ネットワークへ適用させ、かつ汎用的に拡張した方式を用いることにより仕様用途が広がると考えられる。
また、従来の課題と本実施の形態の効果として補足すると、ＰＰＰプロトコルやＬ２ＴＰプロトコルは、トンネルセッションの維持、ユーザセッションの維持、ＰＰＰ、Ｌ２ＴＰによるカプセル化、ＰＰＰ、Ｌ２ＴＰカプセル化解除のように、そのプロトコルの複雑性からソフトウェア部で処理され、結果ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に掛かる負荷が高くなることから、パケット転送能力が大幅に落ちることがある。
その場合、ＬＡＣ、ＬＮＳの持つ回線の伝送速度（ワイヤーレート）での処理が出来ず、それに見合うだけのユーザ数を効率よく収容させることが出来ない場合があった。
一方、ハードウェアで多くの処理が行われる場合でも、複雑なプロトコル処理に特化した開発が必要となってしまうことから、機器ベンダーにおいて、開発工数、費用が掛かってしまうことになり、それが機器の価格に反映された結果、機器購入コストが高価なものとなってしまう。従って、このコストの制約により、通信事業者が購入出来る機器台数に制限が発生する場合があった。
上記の理由から、通信事業者が毎年増加している通信量に対応していく上で、ＬＡＣ、ＬＮＳが、アクセス網のボトルネックになってしまうことになってしまうという課題があった。
また、ユーザへのサービスとして、ＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ４）に加え、ＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６）の提供により、ＰＰＰ処理部ではＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ネゴシエーションにＩＰｖ４用としてＩＰＣＰ （Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＩＰｖ６用としてＩＰｖ６ＣＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）をそれぞれ実装、動作させる必要があり、マルチキャストによる映像配信等を行う場合は、さらなる処理負荷が掛かることが考えられる。
このように認証時以外での通常通信フレームに対してのカプセル化処理や、ＩＰ４ＣＰとＩＰｖ６ＣＰの複数プロセスが動作することが、ＣＰＵ負荷要因の一部である場合、本実施の形態では認証時以外の通常通信フレームに対してはソフトウェア介在をしない為、ＣＰＵ負荷を軽減させることが可能となる。

本発明は、例えば、アクセスネットワーク網を所有する通信事業者、企業等において、ユーザ端末（８０２．１Ｘ Ｓｕｐｐｌｉｃａｎｔを実装）を収容し、複数のネットワーク接続サービスを提供する産業に利用可能である。

本実施の形態のネットワーク構成図。 Ａｃｃｅｓｓ ＡｕｔｈｅｎｔｉｃａｔｏｒにおけるＳｕｐｐｌｉｃａｎｔからのＥＡＰｏＬフレーム受信時の処理機構。 Ａｃｃｅｓｓ ＡｕｔｈｅｎｔｉｃａｔｏｒにおけるＥＡＰｏＬ転送テーブルの例。 Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ、Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒにおけるユーザステータスリストの例。 ８０２．１Ｘ ＥＡＰ認証シーケンスの例。 本発明によるＥＡＰ認証シーケンスの例。 ＥＡＰｏＬフレームフォーマットの例（１）。 ＥＡＰｏＬフレームフォーマットの例（２）。 課題の説明図。

符号の説明

１０１、２０８ Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ
１０２ 中継スイッチ
１０３、２０１ Ｓｕｐｐｌｉｃａｎｔ（エンドユーザ端末、モデム）
１０４、２１０ Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ
１０５ アクセスネットワーク網
１０６ ＩＳＰ
１０７ インターネット
１０８ ホールセラー、ＩＳＰ相互接続箇所
１０９ 相互接続スイッチ
１１０ ＲＡＤＩＵＳサーバ
１１１ アクセス回線（有線）
１１２ アクセス回線（無線）
２０２ フレーム判定処理部
２０３ ＥＡＰｏＬフレーム転送先決定部
２０４ ＥＡＰｏＬフレーム転送処理部
２０５ フレーム転送処理部
２０６ フレーム転送テーブル
２０７ 中継スイッチ網
２１１ ＥＡＰｏＬ転送テーブル
２１２ ユーザステータスリスト
２２０ Ｓｕｐｐｌｉｃａｎｔ側インターフェイス
２２１ Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ側インターフェイス
３１０ ドメイン名もしくはＩＳＰ識別情報
３１１ 物理ポート番号
３１２ Ｓｕｐｐｌｉｃａｎｔ ＭＡＣアドレス
３１３ 割当ＶＬＡＮ
３１４ 転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１ ＭＡＣアドレス
３１５ 転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１ Ｐｒｉｏｒｉｔｙ値
３１６ 転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ２ ＭＡＣアドレス
３１７ Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ監視間隔
３１８ Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ Ｔｉｍｅｏｕｔ値
３１９ Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ監視回数
３２０ 転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ１ Ｓｔａｔｕｓ
３２１ 転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ２ Ｐｒｉｏｒｉｔｙ値
４０１ Ｓｕｐｐｌｉｃａｎｔ ＭＡＣアドレス（Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ）
４０２ ユーザステータス（Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ）
４０３ 割当ＶＬＡＮ（Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ）
４０４ 転送先Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ ＭＡＣアドレス（Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ）
４１１ Ｓｕｐｐｌｉｃａｎｔ ＭＡＣアドレス（Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ）
４１２ ユーザステータス（Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ）
４１３ 割当ＶＬＡＮ（Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ）
７００ ＳｕｐｐｌｉｃａｎｔからＡｃｃｅｓｓ ＡｕｔｈｅｎｔｉｃａｔｏｒへのＥＡＰｏＬフレーム
７０１、７１１、８０１、８１１ 宛先ＭＡＣアドレス
７０２、７１２、８０２、８１２ 送信元ＭＡＣアドレス
７０３、７１４、８０３、８１３ Ｅｔｈｅｒｎｅｔ Ｔｙｐｅ
７０４、７１５、８０４、８１４ ＥＡＰｏＬペイロード
７１０ Ａｃｃｅｓｓ ＡｕｔｈｅｔｉｃａｔｏｒからＳｅｒｖｅｒ ＡｕｔｈｅｎｔｉｃａｔｏｒへのＥＡＰｏＬフレーム
７１３、８０３ ＶＬＡＮタグ
８００ Ｓｅｒｖｅｒ Ａｕｔｈｅｎｔｉｃａｔｏｒ→Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ ＥＡＰｏＬフレーム
８１０ Ａｃｃｅｓｓ Ａｕｔｈｅｎｔｉｃａｔｏｒ→Ｓｕｐｐｌｉｃａｎｔ ＥＡＰｏＬフレーム
９０１、９０２ パケット転送装置（カプセル化実施装置、ＱｏＳ設定あり）
９０３ パケット転送装置（非カプセル化実施装置、ＱｏＳ設定無効）
９０４ ユーザ側ネットワーク
９１０ パケット転送装置 ＱｏＳ設定値
９１１ ポート９２１にて受信するトラフィックパターン
９１２ ポート９２２にて受信するトラフィックパターン
９１３ ポート９２３より送信するトラフィックパターン
９１４ ポート９２４より送信するトラフィックパターン
９１５ ポート９２７より送信するトラフィックパターン
９２１〜９２７ ポート（１Ｇ ｂｐｓ）
９３１、９３２ パケット（カプセル化ヘッダ無）
９３３〜９３５ パケット（カプセル化ヘッダ有）

Claims (13)

1. ８０２．１ｘの規定に従い認証を行う端末又はモデムと接続される第１の通信装置と、
   前記第１の通信装置とネットワークを介して接続され、前記端末又はモデムと認証サーバとの間で、該端末又はモデムの８０２．１ｘ認証のための認証フレームであるＥＡＰｏＬフレームを転送し、前記端末又はモデムが利用するＩＳＰネットワークに対して複数台が接続される複数の第２の通信装置と
   を備え、
   前記第１の通信装置は、
   前記端末又はモデムから、宛先ＭＡＣアドレスに予め定められたＥＡＰｏＬ用ＭＡＣアドレスを付与し且つドメイン名情報又はプロバイダ識別情報を含む認証フレームであるＥＡＰｏＬフレームを受信する受信部と、
   ドメイン名情報又はプロバイダ識別情報に対応して、前記認証フレームであるＥＡＰｏＬフレームを転送するための複数の前記第２の通信装置のＭＡＣアドレスが記憶された転送テーブルを有し、受信された認証フレームであるＥＡＰｏＬフレームのドメイン名情報又はプロバイダ識別情報に基づき、前記転送テーブルを参照し、対応する前記第２の通信装置のＭＡＣアドレスのひとつを取得するフレーム転送先決定部と、
   受信された認証フレームであるＥＡＰｏＬフレームの宛先ＭＡＣアドレスとして前記フレーム転送先決定部が取得した前記第２の通信装置のＭＡＣアドレスを設定し、前記第２の通信装置のＭＡＣアドレスに従い、認証フレームであるＥＡＰｏＬフレームを前記第２の通信装置に転送するフレーム転送処理部と
   を有し、
   前記第２の通信装置は、
   前記第１の通信装置から受信された認証フレームであるＥＡＰｏＬフレームに従い、前記認証サーバに認証要求を送信することで、前記認証サーバと前記端末又はモデムとで認証がされるネットワークシステム。
2. 前記転送テーブルは、ドメイン名情報又はプロバイダ識別情報に対応して、予め定められた仮想ネットワーク識別子がさらに記憶され、
   前記フレーム転送先決定部は、受信された認証フレームのドメイン名情報又はプロバイダ識別情報に基づき、前記転送テーブルから対応する仮想ネットワーク識別子をさらに取得し、
   前記フレーム転送処理部は、取得された仮想ネットワーク識別子を受信された認証フレームに付加して前記第２の通信装置に転送する請求項１に記載のネットワークシステム。
   
3. 前記転送テーブルは、複数の前記第２の通信装置のＭＡＣアドレスにそれぞれ対応する複数の優先度情報をさらに含み、
   前記フレーム転送先決定部は、
   該優先度情報に従い、複数の前記第２の通信装置のＭＡＣアドレスをひとつ取得する請求項１に記載のネットワークシステム。
4. 前記フレーム転送先決定部は、認証フレームに含まれるドメイン名情報又はプロバイダ識別情報に基づき前記転送テーブルの対応する複数の優先度情報を参照して、優先度が最も高い前記第２の通信装置のＭＡＣアドレスを取得する請求項３に記載のネットワークシステム。
5. 前記フレーム転送先決定部は、認証フレームに含まれるドメイン名情報又はプロバイダ識別情報に基づき前記転送テーブルの対応する複数の優先度情報を参照して、該複数の優先度情報が示す値に応じて転送先の前記第２の通信装置を振り分けるように、前記第２の通信装置のＭＡＣアドレスをひとつ取得する請求項３に記載のネットワークシステム。
6. 前記第１の通信装置は、前記第２の通信装置にヘルスチェックフレームを送信し、
   前記第２の通信装置から該ヘルスチェックフレームに対する応答が所定時間内にない場合、前記転送テーブルの該第２の通信装置のＭＡＣアドレスに対応する優先度情報を最低値に更新する請求項３に記載のネットワークシステム。
7. 前記第１の通信装置は、前記第２の通信装置における端末接続数、接続ポートの使用帯域幅、ＣＰＵ使用率のいずれかを含む負荷に応じて、前記転送テーブルの該第２の通信装置のＭＡＣアドレスに対応する優先度情報を更新する請求項３に記載のネットワークシステム。
8. 前記第１の通信装置と複数の前記第２の通信装置との間に配置され、複数の前記第２の通信装置と前記第１の通信装置との間で通信されるフレームに対して、通信品質制御を行う中継装置
   をさらに備え、
   前記第１の通信装置と前記第２の通信装置は、フレームをカプセル化せずに互いに通信する請求項１に記載のネットワークシステム。
9. 前記第１の通信装置は
   前記端末又はモデムのＭＡＣアドレスと仮想ネットワーク識別子が対応して記憶される第１のステータスリスト
   をさらに有し、
   前記端末又はモデムから受信された認証フレーム内の端末又はモデムのＭＡＣアドレスと、前記転送テーブルから取得された仮想ネットワーク識別子とを前記第１のステータスリストに記憶し、
   前記第２の通信装置から、宛先ＭＡＣアドレスと仮想ネットワーク識別子を含むフレームを受信すると、
   受信したフレームの仮想ネットワーク識別子と前記第１のステータスリストに記憶された仮想ネットワーク識別子とが合致し、かつ、受信したフレームの宛先ＭＡＣアドレスが、前記第１のステータスリストに記憶された端末又はモデムのＭＡＣアドレスに合致するか判断し、
   いずれも合致した場合、受信されたフレームを前記端末又はモデムに仮想ネットワーク識別子を外して転送し、及び、少なくともいずれかが合致しない場合、受信されたフレームを廃棄する請求項２に記載のネットワークシステム。
10. 前記第２の通信装置は
    前記端末又はモデムのＭＡＣアドレスと、仮想ネットワーク識別子とが対応して記憶される第２のステータスリスト
    をさらに有し、
    前記第１の通信装置から受信された認証フレーム内の端末又はモデムのＭＡＣアドレス及び仮想ネットワーク識別子を前記第２のステータスリストに記憶し、
    前記端末又はモデムから、送信元ＭＡＣアドレスと仮想ネットワーク識別子を含むフレームを受信すると、
    受信したフレームの仮想ネットワーク識別子と前記第２のステータスリストに記憶された仮想ネットワーク識別子とが合致し、かつ、受信したフレームの送信元ＭＡＣアドレスが、前記第２のステータスリストに記憶された端末又はモデムのＭＡＣアドレスに合致するか判断し、
    いずれも合致した場合、受信したフレームをプロバイダ側のネットワークに仮想ネットワーク識別子を外して転送し、及び、少なくともいずれかが合致しない場合受信したフレームを廃棄する請求項２に記載のネットワークシステム。
11. 前記第２の通信装置のひとつは、前記端末又はモデムのＭＡＣアドレスを送信元ＭＡＣアドレスとしたアドレス配布要求パケットを受信すると、該アドレス配布要求パケットの送信元ＭＡＣアドレスに基づき前記第２のステータスリストを参照し、該当する端末又はモデムのＭＡＣアドレスが記憶されている場合に予め定められたアドレス配布処理を実行する請求項１０に記載のネットワークシステム。
12. 前記第１のステータスリストは、フレームの転送先の前記第２の通信装置のＭＡＣアドレスがさらに記憶され、
    前記第１の通信装置は、
    前記転送テーブルから取得された前記第２の通信装置のＭＡＣアドレスを、前記第１のステータスリストに記憶し、
    前記端末又はモデムのＭＡＣアドレスを送信元アドレス情報としたアドレス配布要求パケットを受信すると、受信されたアドレス配布要求パケットの送信元ＭＡＣアドレスに基づき前記第１のステータスリストを参照して、対応する前記第２の通信装置のＭＡＣアドレスを取得し、取得されたＭＡＣアドレスに従い該アドレス配布要求パケットを前記第２の通信装置に送信し、
    前記第２の通信装置は、受信されたアドレス配布要求パケットに従い予め定められたアドレス配布処理を実行する請求項９に記載のネットワークシステム。
13. ８０２．１ｘの規定に従い認証を行う端末又はモデムと認証サーバとの間で、該端末若しくはモデムの認証のための認証フレームであるＥＡＰｏＬフレームを転送し、前記端末又はモデムが利用するＩＳＰネットワークに対して複数台が接続される複数の通信装置を備えたネットワークシステムにおいて、該通信装置とネットワークを介して接続され、及び、前記端末又はモデムと接続される集約装置であって、
    端末又はモデムから、宛先ＭＡＣアドレスに予め定められたＥＡＰｏＬ用ＭＡＣアドレスを付与し且つドメイン名情報又はプロバイダ識別情報を含む認証フレームであるＥＡＰｏＬフレームを受信する受信部と、
    ドメイン名情報又はプロバイダ識別情報に対応して、前記認証フレームであるＥＡＰｏＬフレームを転送するための複数の前記通信装置のＭＡＣアドレスが記憶された転送テーブルを有し、受信された認証フレームであるＥＡＰｏＬフレームのドメイン名情報又はプロバイダ識別情報に基づき、前記転送テーブルを参照し、対応する前記通信装置のＭＡＣアドレスのひとつを取得するフレーム転送先決定部と、
    受信された認証フレームであるＥＡＰｏＬフレームの宛先ＭＡＣアドレスとして前記フレーム転送先決定部が取得した前記通信装置のＭＡＣアドレスを設定し、前記通信装置のＭＡＣアドレスに従い、認証フレームを前記通信装置に転送するフレーム転送処理部と
    を備え、
    前記通信装置が認証フレームであるＥＡＰｏＬフレームに従い、前記認証サーバに認証要求を送信することで、前記認証サーバと前記端末又はモデムとで認証がされるための集約装置。

Images