JP4080765B2 - ネットワークシステム - Google Patents
ネットワークシステム Download PDFInfo
- Publication number
- JP4080765B2 JP4080765B2 JP2002055503A JP2002055503A JP4080765B2 JP 4080765 B2 JP4080765 B2 JP 4080765B2 JP 2002055503 A JP2002055503 A JP 2002055503A JP 2002055503 A JP2002055503 A JP 2002055503A JP 4080765 B2 JP4080765 B2 JP 4080765B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- message
- pppoe
- pado
- server device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2212/00—Encapsulation of packets
Description
【０００１】
【発明が属する技術分野】
本発明はネットワークシステムに関し、特に、ＰＰＰｏＥネットワークシステムに適用すると好適であって、複数のＰＰＰｏＥサーバを有し、ＰＰＰｏＥクライアント端末からの接続要求がその都度ＰＰＰｏＥサーバ間で振り分けられるＰＰＰｏＥネットワークシステムに関する。
【０００２】
【従来の技術】
ＰＰＰｏＥ(PPP over Ethernet)は、従来アナログ電話回線やＩＳＤＮ回線を経由したダイヤルアップ接続等で用いられていたＰＰＰ(Point-to-Point Protocol)を、イーサネット（登録商標）上に通すために提案されたクライアント・サーバ型のプロトコルで、ＩＥＴＦ(The Internet Engineering Task Force)が１９９９年２月に発行したＲＦＣ２５１６"A Method for Transmitting PPP Over Ethernet(PPPoE)"によって規定されている。ＰＰＰｏＥは、ＡＤＳＬやＦＴＴＨのようなブロードバンドアクセス網における加入者収容プロトコルとして普及しており、例えば、ＮＴＴ地域会社が２００１年１１月現在において提供する「フレッツ・ＡＤＳＬ」や「Ｂフレッツ」というサービスで採用されている。東日本電信電話株式会社は、これらのサービスに関する技術参考資料として、２００１年１０月１７日に「ＩＰ通信網サービスのインタフェース―フレッツシリーズ―第１版」を作成している。
【０００３】
ＲＦＣ２５１６が規定するＰＰＰｏＥのセッション確立シーケンス(Discovery Stage)では、ＰＰＰｏＥクライアント端末と通信可能なＰＰＰｏＥサーバが複数存在する場合に、ＰＰＰｏＥクライアント端末が接続先のＰＰＰｏＥサーバを選択する枠組みが提供されている。
【０００４】
図１６は、従来のＰＰＰｏＥにおけるセッション確立時のＰＣ１０１とＢＡＳ１３２、１３３との間のメッセージシーケンスの一例を示す。
【０００５】
この従来技術では、ＰＣ１０１とＢＡＳ１３２、１３３との間で、例えば、ＰＰＰｏＥディスカバリーステージはＲＦＣ２５１６に規定されたシーケンスの処理を行う等、現在標準的に行われている処理と同様の処理を行う。
【０００６】
まず、ＰＰＰｏＥクライアント端末であるＰＣ１０１が、ＰＡＤＩメッセージ７０１をブロードキャストＭＡＣアドレス宛に送信する。ＰＡＤＩメッセージ７０１は中継装置１３１を経由してＰＰＰｏＥサーバであるＢＡＳ１３２、１３３まで到達し、ＰＡＤＩ受信手段７１１、７２１によって受信される。セッション管理テーブル割当手段７１２、７２２は、本シーケンスの管理用にセッション管理テーブル６４３を割り当て、ＰＡＤＩメッセージ７０１中の、ＰＣ１０１のＭＡＣアドレス値が格納されているSource MAC Addressフィールド４１２を前記セッション管理テーブル６４３に登録する。ＢＡＳ１３２はＰＡＤＯ送信手段７１３によってＰＡＤＯメッセージ７０３をＰＣ１０１のＭＡＣアドレス宛に送信し、ＢＡＳ１３３はＰＡＤＯ送信手段７２３によってＰＡＤＯメッセージ７０２をＰＣ１０１のＭＡＣアドレス宛に送信する。
【０００７】
ＰＣ１０１は２つのＰＡＤＯメッセージ７０２、７０３を受信するが、ＰＣ１０１に設けられた接続先選択手段７３１は、ＰＡＤＯメッセージ中に含まれるService-Name TAGフィールドの値を基準にする等して、ＢＡＳ１３２、１３３のどちらに接続するかを選択する。図１６に示す例では、ＰＣ１０１がＢＡＳ１３３を接続先として選択した場合を示す。この場合、ＰＣ１０１はＰＡＤＲメッセージ７０４をＢＡＳ１３３のＭＡＣアドレス宛に送信する。
【０００８】
ＢＡＳ１３３はＰＡＤＲ受信手段７４１によってＰＡＤＲメッセージ７０４を受信する。セッションＩＤ生成手段７４２によってＰＣ１０１との間でユニークなセッションＩＤ値を生成し、セッション管理テーブル更新手段７４３によって、セッション管理テーブル割当手段７２２が割り当てたセッション管理テーブル６４３に生成されたセッションＩＤ値を登録する。そして、ＰＡＤＳメッセージ送信手段７４４によって、セッションＩＤフィールド４２２に前記セッションＩＤ値を設定したＰＡＤＳメッセージ７４０を、ＰＣ１０１のＭＡＣアドレス宛に送信する（なお、ＰＡＤＩ、ＰＡＤＯ、ＰＡＤＲの各メッセージにおけるセッションＩＤフィールド４２２の値は０ｘ０である）。このように、ＰＡＤＩ、ＰＡＤＯ、ＰＡＤＲ、ＰＡＤＳという２往復のメッセージを送受信することによって、ＰＣ１０１とＢＡＳ１３３との間でＰＰＰｏＥディスカバリーステージが完了し、ＰＰＰｏＥセッションが確立される。
【０００９】
一方、ＰＡＤＲメッセージを受信しなかったＢＡＳ１３２では、ＰＡＤＯメッセージ７０３の送信から一定限度の時間が経過した時点でタイムアウト７５１となり、セッション管理テーブル解放手段７５２によって、セッション管理テーブル割当手段７１２が本シーケンス処理用に割り当てたセッション管理テーブルが解放される。
【００１０】
ＰＰＰｏＥセッションが確立されると、引き続いてＰＰＰネゴシエーション７６０が行われる。ＰＰＰネゴシエーション７６０では、ＰＰＰリンクを確立し（ＬＣＰ）、ユーザ認証を行い（ＣＨＡＰ又はＰＡＰ）、ＰＣ１０１に対してＩＰアドレスが割り当てられる（ＩＰＣＰ）。ＰＰＰネゴシエーション７６０が完了するとＩＰ通信７７０が可能となり、ＰＣ１０１のインターネット１４０への接続性が確立される。
【００１１】
【発明が解決しようとする課題】
前述した、ＰＰＰｏＥクライアント側主導で接続先を選択する従来技術では、特定のＰＰＰｏＥサーバにアクセスが集中し、ＰＰＰｏＥサーバやネットワークの能力を十分に引き出せない可能性がある。
【００１２】
本発明の目的は、ＰＰＰｏＥネットワークシステムにおいて、複数のＰＰＰｏＥサーバ間で、ＰＰＰｏＥクライアント端末からの接続要求をＰＰＰｏＥサーバ主導で特定のＰＰＰｏＥサーバに対して振り分けることができるネットワークシステムを提供することにある。
【００１３】
また、複数のＰＰＰｏＥサーバ間で確立された複数のＰＰＰｏＥセッションの一意性を保証することにある。
【００１４】
さらに、複数のＰＰＰｏＥサーバ間で互いの負荷情報を交換し、ＰＰＰｏＥセッション単位の負荷分散を実現することにある。
【００１５】
さらに、前記負荷分散を実現するにあたり、新たなＰＰＰｏＥサーバを設置したり運用中のＰＰＰｏＥサーバを停止しても、各ＰＰＰｏＥサーバが自律的に新たな構成に適応し、継続的に適切な負荷分散を実現することにある。
【００１６】
さらに、前記各目的を達成するにあたり、ＰＰＰｏＥクライアント端末に対する変更を必要とせず、またＰＰＰｏＥクライアント端末や加入者に前記各目的を達成する手段を意識させないことにある。
【００１７】
【課題を解決するための手段】
上記課題を解決するために、本発明に係るネットワークシステムは、少なくとも１つのクライアント端末と、複数のサーバとの接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応した前記サーバからの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するネットワークシステムにおいて、前記サーバは、前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバを決定し、前記決定されたサーバを識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有する。
【００１８】
また、少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバとの接続を、少なくとも前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージと、前記ＰＡＤＩメッセージに対応して前記サーバから送信されるＰＡＤＯメッセージと、前記ＰＡＤＯメッセージに対応して前記クライアント端末から送信されるＰＡＤＲメッセージとによって実現するネットワークシステムにおいて、前記各ＰＰＰｏＥサーバの、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスをそれぞれ異ならせて設定し、前記ＰＰＰｏＥサーバは、前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信すると、前記ＰＡＤＩメッセージに対応するＰＡＤＲメッセージを受信すべき特定のＰＰＰｏＥサーバのＭＡＣアドレスを前記ＰＡＤＯメッセージに設定する識別情報設定手段を有する。
【００１９】
また、少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバとの接続を、少なくとも前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージと、前記ＰＡＤＩメッセージに対応して前記サーバから送信されるＰＡＤＯメッセージと、前記ＰＡＤＯメッセージに対応して前記クライアント端末から送信されるＰＡＤＲメッセージとによって実現するネットワークシステムにおいて、前記各ＰＰＰｏＥサーバの、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスを同一に設定し、前記ＰＰＰｏＥサーバは、前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信すると、前記ＰＡＤＩメッセージに対応するＰＡＤＲメッセージを受理すべき特定のＰＰＰｏＥサーバのサーバ識別子を前記ＰＡＤＯメッセージに設定する識別情報設定手段を有する。
【００２０】
また、少なくとも１つのクライアント端末との間の接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応したサーバ装置からの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するサーバ装置において、前記クライアント端末からの接続開始信号を受信した前記サーバ装置が、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバ装置を決定し、前記決定されたサーバ装置を識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有する。
【００２１】
【発明の作用および効果】
上記課題を解決するために、本発明に係るネットワークシステムは、少なくとも１つのクライアント端末と、複数のサーバとの接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応した前記サーバからの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するネットワークシステムにおいて、前記サーバは、前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバを決定し、前記決定されたサーバを識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有するので、複数のサーバ（例えば、ＰＰＰｏＥサーバ）間で、クライアント端末（例えば、ＰＰＰｏＥクライアント端末）からの接続要求を、その都度サーバ主導で振り分けることができる。また、複数のサーバ間で、セッション（例えば、ＰＰＰｏＥセッション）単位の負荷分散を実現することができる。
【００２２】
また、各ＰＰＰｏＥサーバが同一のＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスがそれぞれ同一にする場合に、前記各ＰＰＰｏＥサーバに、前記ＭＡＣアドレスとは別のＰＰＰｏＥサーバ間でユニークなサーバ識別子を設け、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＩメッセージに対応するＰＡＤＲメッセージを受理するべきＰＰＰｏＥサーバのサーバ識別子をＰＡＤＯメッセージに設定して前記ＰＰＰｏＥクライアント端末に返送する手段を設け、前記ＰＡＤＲメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＲメッセージ中に含まれる前記サーバ識別子を抽出する手段と、前記サーバ識別子と自分自身のサーバ識別子とを比較して両者が一致する場合に前記ＰＡＤＲメッセージを受理する手段を設けたことによって、前記ＰＡＤＯメッセージによって指定された特定のＰＰＰｏＥサーバが前記ＰＡＤＲメッセージを受理することができる。
【００２３】
また、各ＰＰＰｏＥサーバが同一のＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスがそれぞれ同一である場合に、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＩメッセージを受信するＬＡＮセグメント上で自サーバが確立中の全てのＰＰＰｏＥセッションのセッションＩＤ値のリストをＰＡＤＯメッセージに設定する手段を設け、前記ＰＡＤＯメッセージを送信するのとは別のＰＰＰｏＥサーバに、前記ＬＡＮセグメント上を流れる前記ＰＡＤＯメッセージを観測する手段と、前記ＰＡＤＯメッセージ中に設定された前記セッションＩＤ値のリストを抽出する手段と、抽出した前記セッションＩＤ値のリストを記憶する手段と、ＰＡＤＲメッセージを受信して新たなＰＰＰｏＥセッションを確立する際に、記憶した前記セッションＩＤ値と重複しないセッションＩＤ値を割り当てる手段を設けたことによって、前記ＬＡＮセグメント上での各ＰＰＰｏＥセッションの一意性を保証することができる。
【００２４】
また、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、自サーバの前記ＭＡＣアドレスまたはサーバ識別子と、自サーバの負荷情報とを、ＰＡＤＯメッセージに設定する手段を設け、前記ＰＡＤＯメッセージを観測する別のＰＰＰｏＥサーバに、前記ＰＡＤＯメッセージ中に設定された前記ＭＡＣアドレスまたはサーバ識別子と前記負荷情報とを抽出する手段と、抽出した前記ＭＡＣアドレスまたはサーバ識別子と前記負荷情報とを記憶する手段と、記憶した前記各サーバの負荷情報を元に、ＰＡＤＲメッセージを受信するべきＰＰＰｏＥサーバを決定する手段を設けたことによって、ＰＰＰｏＥサーバ間での負荷分散を実現することができる。
【００２５】
また、各ＰＰＰｏＥサーバが、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージに対してＰＡＤＯメッセージで応答する度毎に互いに負荷情報を更新し合うことによって、新たなＰＰＰｏＥサーバを設置したり運用中のＰＰＰｏＥサーバを停止させたりしても、各ＰＰＰｏＥサーバが自律的に新たな構成に適応し、前記新たな構成における各ＰＰＰｏＥサーバ間での適切な負荷分散を可能とする。
【００２６】
また、ＰＰＰｏＥサーバが、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信した場合以外の任意時点において、他のＰＰＰｏＥサーバの記憶する負荷情報を更新させることを目的としてＰＡＤＯメッセージを送信したり、自サーバが記憶する他のＰＰＰｏＥサーバの負荷情報を更新することを目的としてＰＡＤＩメッセージを送信することができる。
【００２７】
また、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＩメッセージの受信時刻を表すタイムスタンプをＰＡＤＯメッセージに設定して前記ＰＰＰｏＥクライアント端末に返送する手段を設け、前記ＰＡＤＲメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＲメッセージ中に含まれる前記タイムスタンプを抽出する手段と、前記ＰＡＤＲメッセージの受信時刻が前記タイムスタンプの示す時刻から一定時間以上経過していた場合には前記ＰＡＤＲメッセージを無効と判定する手段を設けたので、無効なメッセージに基づく無駄な処理を排除することができる。
【００２８】
また、各ＰＰＰｏＥサーバに、共通の暗号化／復号化手段を設け、ＰＡＤＯメッセージを送信するＰＰＰｏＥサーバが上記のような各種情報を設定するのに前記暗号化手段を適用し、ＰＡＤＯメッセージやＰＡＤＲメッセージから前記各種情報を抽出するＰＰＰｏＥサーバが前記復号化手段を適用することによって、ＰＰＰｏＥサーバ間で交換される前記各種情報の内容をＰＰＰｏＥクライアント端末から隠蔽することができる。
【００２９】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００３０】
図１は、ＤＳＬ網によって加入者を収容するネットワークにおいて本発明を適用した一例を示したネットワーク構成図である。
【００３１】
ＤＳＬ(Digital Subscriber Line)は、電話線を用いた高速ディジタル伝送方式である。ＤＳＬによる加入者収容システムでは、加入者宅に設置されたＤＳＬモデム１１１は加入者側のEthernetインタフェースによってパーソナルコンピュータ(PC)１０１と接続される。また、ＤＳＬモデムに宅内ルータ１０２を接続して、宅内ルータ１０２に複数のパーソナルコンピュータを接続して、宅内ルータ１０２を経由して複数台のＰＣをＤＳＬ回線に接続することもできる。また、ＤＳＬモデム１１３がＵＳＢ(Universal Serial Bus)を有する場合には、ＵＳＢによってパーソナルコンピュータと接続することもできる。
【００３２】
ＤＳＬモデム１１１は、モジュラーコネクタ(RJ-11)による一般の電話回線インタフェースによって加入者宅の電話線に接続される。電話局側にはＤＳＬＡＭ(DSL Access Multiplexer)１１２が設置され、複数の加入者宅からのＤＳＬ回線を収容する。ＤＳＬＡＭ１１２はＡＴＭ網によって構成されるネットワーク側にＡＴＭインタフェースを持ち、ＡＴＭ網１２０へ接続されている。ＡＴＭ網１２０は、ＤＳＬ網１１０と、ＩＳＰのネットワーク（ＩＳＰ網）１３０とを接続する。
【００３３】
ＩＳＰ網１３０の入り口には中継装置１３１が設置される。中継装置１３１はＡＴＭインタフェースを備え、ＡＴＭ網１２０と、ＢＡＳ(Broadband Access Server)１３２、１３３とを接続する。ＢＡＳ１３２、１３３はＩＳＰ内ＬＡＮ１３４に接続される。ＩＳＰ内ＬＡＮ１３４には、認証サーバ、ＤＮＳサーバ、Ｗｅｂサーバ、Ｍａｉｌサーバ等が設置され、加入者へInternet１４０への接続をはじめとする種々のサービスを提供する。
【００３４】
図２は、ＰＣ１０１からＢＡＳ１３２、１３３までの区間におけるプロトコルスタックを示す。
【００３５】
ＰＣ１０１は、ＰＰＰｏＥクライアント端末として機能し、ＢＡＳ１３２や１３３との間でＰＰＰｏＥセッションおよびＰＰＰセッションを確立し、インターネット(Internet)１４０に対してＩＰ(Internet Protocol)通信を行う。ＰＰＰｏＥクライアントの機能は、ＰＣに直接行わせる場合の他、宅内ルータ１０２やＤＳＬモデム１１１等の加入者宅内の別の装置に実行させることもできる。
【００３６】
ＢＡＳ１３２、１３３は、ＰＰＰｏＥサーバの機能を有する。ＰＣ１０１等の各加入者宅のＰＰＰｏＥクライアント端末との間でＰＰＰｏＥセッションおよびＰＰＰセッションを確立することによって、各加入者のＰＣ１０１をインターネット１４０に接続して、インターネット接続サービスを提供する。
【００３７】
ＤＳＬ網１１０内では、レイヤ２にＡＴＭ(Asynchronous Transfer Mode)が用いられる。ＤＳＬモデム１１１は、ＰＣ１０１から受信したイーサネットフレームをＲＦＣ１４８３ブリッジ形式のＡＴＭ ＡＡＬ５パケットにカプセル化し、さらにＡＴＭセル化してＤＳＬＡＭ１１２に向けて転送する。ＤＳＬＡＭ１１２はＤＳＬからＡＴＭへの物理レイヤ変換を行い、ＤＳＬモデム１１１から受信したＡＴＭセルをそのままＡＴＭ網１２０へ転送する。ＡＴＭ網１２０内にはＡＴＭスイッチが配置され、ＡＴＭセルレベルでの転送が行われる。
【００３８】
中継装置１３１は、ＡＴＭ網とＢＡＳ１３２、１３３との間でイーサネットフレームレベルの中継を行う。この中継装置１３１は、複数のＡＴＭ ＶＣ(ATM Virtual Connection)をグループ化して仮想ＬＡＮセグメントを構成する機能を有する。あるＶＣ上で受信したイーサネットフレームは、同一グループに属する他の全てのＶＣ上にブロードキャストされる。
【００３９】
ＤＳＬモデム１１１からＢＡＳ１３２、１３３までの区間の通信では、レイヤ２にＡＴＭが用いられ、ＡＴＭレイヤの上位をイーサネットフレームがＲＦＣ１４８３ブリッジ形式のＡＴＭ ＡＡＬ５パケットとして転送される。
【００４０】
図３は、この区間におけるＡＴＭ ＶＣのトポロジを示す。
【００４１】
中継装置１３１とＢＡＳ１３２、１３３及びＤＳＬモデム１１１間に設けられたＶＣ３２０、３３０、３１０は、１つの仮想ＬＡＮセグメントを形成する。ＰＣ１０１が送信したイーサネットフレームは、ＤＳＬモデム１１１において、ＲＦＣ１４８３ブリッジ形式のＡＡＬ５パケットにカプセル化され、さらにＡＴＭセル化されてＶＣ３１０上に送信される。このＡＴＭセルは、ＤＳＬＡＭ１１２やＡＴＭ網１２０においてはＡＴＭセルのまま転送され、中継装置１３１に到達する。中継装置１３１は、ＶＣ３１０上で受信したＡＴＭセルからＡＡＬ５パケットを復元し、上位レイヤのイーサネットフレームを取り出す。このイーサネットフレームは、ＶＣ３１０と同一の仮想ＬＡＮセグメントに属するＶＣ３２０と３３０に向けて送信（ブロードキャスト）される。その際、イーサネットフレームは再びＲＦＣ１４８３ブリッジ形式のＡＡＬ５パケットにカプセル化され、さらにＡＴＭセル化される。
【００４２】
ＢＡＳ１３２、１３３は、ＶＣ３２０や３３０上で受信したＡＴＭセルからＡＡＬ５パケットを復元し、上位レイヤのイーサネットフレームを取り出す。このようにして、ＰＣ１０１とＢＡＳ１３２、１３３ の間のイーサネットレベルの通信が実現される。ＢＡＳ１３２、１３３からＰＣ１０１への通信についても同様である。
【００４３】
ＢＡＳは、１人の加入者を１つのＡＴＭ ＶＣによって収容する。ＤＳＬモデムは加入者宅毎に設置されるので、１つのＤＳＬモデムからＢＡＳ１３２、１３３に１本ずつのＶＣが設定される。つまり、各ＤＳＬモデムはそれぞれ独立の仮想イーサネットセグメントに収容される。このようにして、ＩＳＰ(Internet Service Provider)は加入者をＡＴＭ ＶＣによって識別することができる。
【００４４】
なお、ＤＳＬモデム１１１、ＤＳＬＡＭ１１２、ＡＴＭ網１２０内の装置のいずれかが、前記中継装置１３１として機能する場合には、中継装置１３１を別個に設置せず、ＢＡＳ１３２、１３３を直接ＡＴＭ網１２０に接続するというネットワーク構成とすることもできる。
【００４５】
図４は、ＲＦＣ２５１６で規定されるＰＰＰｏＥパケットのデータフォーマットを示す。
【００４６】
ＰＰＰｏＥパケットは、イーサネットヘッダ４１０中のEther Typeフィールド４１３の値によって、その種類が識別される。Ether Typeフィールド４１３の値が０ｘ８８６３ならばディスカバリーステージ(Discovery Stage Packet)パケットであることを表し、ＰＰＰｏＥセッションの確立時や切断時に流されるメッセージパケットである。Ether Typeフィールド４１３の値が０ｘ８８６４ならばセッションステージパケット(Session Stage Packet)を表し、セッション確立中に流されるデータパケットである。
【００４７】
イーサネットヘッダ４１０の後にはＰＰＰｏＥヘッダ４２０が続く。ＰＰＰｏＥヘッダ４２０中のCodeフィールド４２１によってディスカバリーステージパケットの種類が識別され、セッションＩＤ(Session ID)フィールド４２２によって同一回線上に多重された複数のＰＰＰｏＥセッションが識別される。
【００４８】
ペイロード４３０には、ディスカバリーステージパケットではＴＡＧと呼ばれる情報フィールドが格納され、セッションステージパケットでは上位レイヤとしてＰＰＰフレームが格納される。
【００４９】
図５は、ペイロード４３０に格納されるＴＡＧのデータフォーマットを示す。
【００５０】
ＴＡＧには、Service#Name、AC#Name、AC#Cookie等の種類がある。TAG Typeフィールド５１０によってＴＡＧの種類が識別される。TAG Valueフィールド５３０はＴＡＧの値を格納する可変長のフィールドで、TAG Lengthフィールド５２０によってそのバイト数が識別される。
【００５１】
図６は、本発明の接続要求振り分け方法を実現するＢＡＳ１３３の装置構成例を示す。
【００５２】
ＢＡＳ１３２は、ＢＡＳ１３３と同様の構成であるか、またはＢＡＳ１３３と同等の機能を実現する別の構成であっても構わない。
【００５３】
ＢＡＳ１３３はいくつかのネットワークインタフェースを持つ。ＡＴＭポート６１１は中継装置１３１に接続されており、ＰＣ１０１からの通信を収容するＶＣ３３０が設定されている。ポート６１２はＩＳＰ内ＬＡＮ１３４と接続されているが、ＩＳＰ内ＬＡＮ１３４とのインタフェース種別に応じて、ＡＴＭインタフェースであったりイーサネットインタフェースであったりする。
【００５４】
ＰＨＹ処理部６２０では、ＡＴＭやイーサネット（登録商標）などの物理レイヤが終端され、ＭＡＣフレームが取り出される。例えば、ＰＣ１０１が送信したＰＰＰｏＥパケットは、ＡＴＭポート６１１のＶＣ３３０上でＡＴＭセルとして受信され、ＰＨＹ処理部６２０においてＡＴＭセルからＡＡＬ５パケットが復元され、図４に示したようなＰＰＰｏＥパケットが取り出される。取り出されたＰＰＰｏＥパケットは転送処理部６３０を経由してＰＰＰｏＥ処理部６４０に転送される。ＰＰＰｏＥシーケンス処理部６４１はディスカバリーステージパケットを処理し、別のＢＡＳとの間で接続要求の振り分けを実現する。例えば、ＰＣ１０１からＰＡＤＩメッセージを受信した場合、ＰＰＰｏＥシーケンス処理部６４１は後述するサーバ間通信情報９００（図８参照）を含んだＰＡＤＯメッセージを生成し、転送処理部６３０を経由してＡＴＭポート６１１を介してＶＣ３３０に向けて返送する。ＰＨＹ処理部６２０は、前記ＰＡＤＯメッセージをＡＡＬ５パケットにカプセル化し、さらにＡＴＭセル化してＡＴＭポート６１１のＶＣ３３０上に送信する。
【００５５】
ＰＰＰｏＥ処理部６４０は、ＰＰＰｏＥシーケンス処理部６４１、サーバ情報テーブル６４２セッション管理テーブル６４３によって構成される。サーバ情報テーブル６４２はＡＴＭ ＶＣ（仮想ＬＡＮセグメント）毎に別々に管理されているＢＡＳの情報を収集して、保持する。ＰＰＰｏＥシーケンス処理部６４１がクライアント端末からの接続要求を振り分けるＢＡＳを決定したり、セッション確立時にユニークなセッションＩＤを生成するのに利用される。ＰＰＰｏＥシーケンス処理部６４１における処理フローや、サーバ情報テーブル６４２の詳細については後述する。
【００５６】
セッション管理テーブル６４３は、確立したＰＰＰｏＥセッションの情報を管理し、セッションステージパケットのカプセル化／デカプセル化処理はセッション管理テーブル６４３を参照して実行される。セッションステージパケットは、ＰＰＰｏＥ処理部６４０においてイーサネットヘッダ４１０とＰＰＰｏＥヘッダ４２０を外され、ＰＰＰ処理部６５０に転送される。ＰＰＰ処理部６５０はクライアント端末（例えば、ＰＣ１０１）との間でＰＰＰネゴシエーション（ＬＣＰ、ＣＨＡＰ、ＰＡＰ、ＩＰＣＰ等）を行い、ＰＰＰセッションを確立する。ＰＰＰセッション確立後のデータパケットはＰＰＰ処理部６５０においてＰＰＰヘッダを外され、ＩＰ処理部６６０に転送される。ＩＰ処理部６６０は、ＩＰヘッダのDestination IP Address（宛先ＩＰアドレス）フィールドによってルーティングテーブルから転送先のポートを検索する。この検索結果に基づき、インターネット１４０へ向かうパケットは転送処理部６３０を経由してＩＳＰ内ＬＡＮ１３４と接続されたポート６１２へ向けて転送される。このＩＰパケットは、ＰＨＹ処理部６２０においてポート６１２のインタフェース種別に対応した物理レイヤのカプセル化が行われ、ポート６１２上に送信される。
【００５７】
インターネット１４０からＰＣ１０１へ向かうＩＰパケットはポート６１２上で受信され、前述とは逆に、ＰＨＹ処理部６２０→転送処理部６３０→ＩＰ処理部６６０→ＰＰＰ処理部６５０→ＰＰＰｏＥ処理部６４０→転送処理部６３０→ＰＨＹ処理部６２０という経路を辿りながら処理される。ＩＰ処理部６６０においては、ＩＰヘッダのDestination IP Addressフィールドをキーとしてルーティングテーブルが検索され、転送先であるＰＣ１０１の論理回線がＡＴＭポート６１１上のＶＣ３３０であることが分かる。ＰＣ１０１へ向かうＩＰパケットはＰＰＰ処理部６５０においてＰＰＰヘッダでカプセル化され、ＰＰＰｏＥ処理部６４０においてさらにＰＰＰｏＥヘッダ４２０とイーサネットヘッダ４１０でカプセル化される。
【００５８】
このようにして、ＢＡＳ１３３におけるＰＰＰｏＥシーケンス処理、ＰＰＰシーケンス処理、ＩＰパケット転送等の機能が実現される。
【００５９】
次に、ＰＣ１０１と、ＢＡＳ１３２、１３３とのメッセージシーケンス、及び、ＰＰＰｏＥシーケンス処理部６４１における処理について説明する。本発明に係る接続要求の振り分け機能は、ＰＰＰｏＥシーケンス処理部６４１において実現される。接続要求の振り分けを実現する具体的な方法は、ＢＡＳ１３２とＢＡＳ１３３とでＰＣ１０１との通信に用いるＭＡＣアドレスの値が異なる場合（図７）と、ＭＡＣアドレスを同一の値とする場合（図１３）とについて説明する。
【００６０】
図７は、図１に示したネットワーク構成において、ＢＡＳ１３２とＢＡＳ１３３とが異なるＭＡＣアドレスで通信をする通常の場合における、ＰＣ１０１とのメッセージシーケンスと、ＰＰＰｏＥシーケンス処理部６４１における処理手順の一例（第１の実施の形態）を示すものであるが、図７に示すメッセージシーケンスにおいて、ＢＡＳ１３２、１３３で用いられる、サーバ間通信情報９００（図８）、サーバ情報テーブル６４２（図９）について先に説明する。
【００６１】
図８に、サーバ間通信情報９００を構成する情報の種類と、ＢＡＳ１３２、１３３がサーバ間通信情報９００として設定する値を示す。
【００６２】
第１の実施の形態（図７）のメッセージシーケンスで用いられるサーバ間通信情報９００には、ＰＡＤＯ送信サーバＭＡＣアドレス９０１、ＰＡＤＯ送信サーバ負荷情報９０２及びＰＡＤＯ送信サーバタイムスタンプ９０３が含まれている。これらの情報のうち、ＰＡＤＯ送信サーバＭＡＣアドレス９０１及びＰＡＤＯ送信サーバ負荷情報９０２は、ＰＡＤＯ観測８３１、８４２で設定される。ＰＡＤＯ送信サーバタイムスタンプ９０３はＰＡＤＲ受信７４１で設定される。そして、これらの収集された情報は、次回のサイクルにおいて、サーバ間通信情報として設定される（８１１、８１２）。
【００６３】
ＰＡＤＯ送信サーバＭＡＣアドレス９０１は、このＰＡＤＯメッセージの送信元のサーバのＭＡＣアドレスであり、具体的には、ＢＡＳ１３２が送信したＰＡＤＯメッセージにはＢＡＳ１３２のＭＡＣアドレスが、ＢＡＳ１３３が送信したＰＡＤＯメッセージにはＢＡＳ１３３のＭＡＣアドレスが設定されている。
【００６４】
ＰＡＤＯ送信サーバ負荷情報９０２は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージ受信時点における、このＰＡＤＯメッセージの送信元のサーバの負荷情報である。具体的には、当該ＢＡＳにおいて確立されているＰＰＰｏＥセッションの総数、当該ＢＡＳのプロセッサ使用率、パケット転送バッファの使用率等が用いられる。
【００６５】
ＰＡＤＯ送信サーバタイムスタンプ９０３は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージを、このＰＡＤＯメッセージの送信元のサーバが受信した時刻である。
【００６６】
図９に、サーバ間通信情報設定８１１、８２１時点でＢＡＳ１３２、１３３が当該ＬＡＮセグメントにおいて保持するサーバ情報テーブル６４２の内容を示す。
【００６７】
サーバ情報テーブル６４２は各サーバ毎のエントリから構成され、第１の実施の形態の場合、ＢＡＳ１３２のエントリ１０１０とＢＡＳ１３３のエントリ１０２０が保持されている。各エントリは、当該サーバをユニークに識別するためのサーバＭＡＣアドレス１００１と、当該サーバの負荷情報１００２とからなる。後述するように、サーバ情報テーブル６４２の情報は、１つ前のサイクルにおいて各ＢＡＳが送信したＰＡＤＯメッセージを観測することによって収集された情報なので、ＢＡＳ１３２、１３３のいずれにおいても、図９に示す同じ情報が保持されている。
【００６８】
次に、図７に従って、ＢＡＳ１３２とＢＡＳ１３３とが異なるＭＡＣアドレスで通信をする通常の場合における、ＰＣ１０１とのメッセージシーケンスと、ＰＰＰｏＥシーケンス処理部６４１における処理手順の一例について説明する。図７には、ＢＡＳ１３２よりもＢＡＳ１３３の方が負荷が小さい状態で、ＰＣ１０１からのＰＡＤＩメッセージ８０１を受信してから接続要求の振り分け先であるＢＡＳ１３３によってＰＰＰｏＥセッションが確立されるまでの１サイクルの間の処理を示す。
【００６９】
ＰＣ１０１がＰＡＤＩメッセージ８０１をブロードキャストすると、ＢＡＳ１３２、１３３はそれぞれＰＡＤＩ受信手段７１１、７２１によってこれを受信する。前記ＰＡＤＩメッセージ８０１に対して、ＢＡＳ１３２、１３３は、それぞれＰＡＤＯメッセージ８０３、８０２によって応答するが、当該ＰＡＤＯメッセージを生成する際、サーバ間通信情報設定手段８１１、８２１によって、ペイロード４３０中のAC-Cookie TAGのTAG Valueの値としてサーバ間通信情報９００を設定する。
【００７０】
従来のシーケンス（図１６）においては、接続要求の振り分けを行わないので、ＢＡＳ１３２、１３３が送信するＰＡＤＯメッセージ７０３や７０２のSource MAC Addressフィールド４１２には自分自身のＭＡＣアドレス値が設定されているが、第１の実施の形態（図７）においては、ＰＡＤＯメッセージ８０３のSource MAC Addressフィールド４１２と、ＰＡＤＯメッセージ８０２のSource MAC Addressフィールド４１２とには、Source MAC Address設定手段８１２、８２２によって、接続要求の振り分け先となるＢＡＳのＭＡＣアドレス値が設定される。Source MAC Address設定手段８１２、８２２は、接続要求の振り分け先となるＢＡＳを決定するためにサーバ情報テーブル６４２（図９参照）を参照し、負荷の最も小さいＢＡＳのエントリを選択し（図９に示す状態では、Ｌ４＜Ｌ３なのでＢＡＳ１３３の負荷が小さく、ＢＡＳ１３３が選択される）、そのサーバＭＡＣアドレス１００１をＰＡＤＯメッセージ８０３のSource MAC Addressフィールド４１２と、にＰＡＤＯメッセージ８０２とのSource MAC Addressフィールド４１２とに設定する。
【００７１】
Source MAC Address設定手段８１２、８２２が実行された後、サーバ情報テーブル更新手段８１３、８２３によって、サーバ情報テーブル６４２の自分自身のエントリが現在の情報に更新され、他のＢＡＳのエントリが削除される。そして、ＰＡＤＯ送信手段７１３によって、ＰＡＤＯメッセージ８０３が送信され、ＰＡＤＯ送信手段７２３によって、ＰＡＤＯメッセージ８０２が送信される。
【００７２】
ＢＡＳ１３３が送信するＰＡＤＯメッセージ８０２は、Destination MAC Addressフィールド４１１にＰＣ１０１のＭＡＣアドレス値が設定されており、ＰＣ１０１宛のユニキャストイーサネットフレームであるが、物理的には図３に示した仮想ＬＡＮセグメント上をブロードキャストされる。従ってＢＡＳ１３２は、自分宛でない前記ＰＡＤＯメッセージ８０２を、ＰＡＤＯ観測手段８３１によって観測することができる。
【００７３】
そして、サーバ間通信情報抽出手段８３２によって、ＢＡＳ１３３がＰＡＤＯメッセージ８０２中のAC-Cookie TAGに格納したサーバ間通信情報９００が抽出される。そしてサーバ情報テーブル更新手段８３３によって、ＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２が、サーバ情報テーブル６４２のエントリ１０２０と同様に、サーバＭＡＣアドレス１００１と負荷情報１００２として新たに登録される。なお、このエントリ１０２０（サーバＭＡＣアドレス１００１及び負荷情報１００２）はサーバ情報テーブル更新手段８１３によって一旦削除されている。前述したように、エントリ１０１０はＢＡＳ１３２自身の情報であるので、サーバ情報テーブル更新手段８１３によって既に更新されている。
【００７４】
ＢＡＳ１３３においても同様に、ＢＡＳ１３２が送信するＰＡＤＯメッセージ８０３をＰＡＤＯ観測手段８４１によって観測することができ、サーバ間通信情報抽出手段８４２、サーバ情報テーブル更新手段８４３が実行される。すなわち、ＢＡＳ１３２が送信するＰＡＤＯメッセージ８０３は、仮想ＬＡＮセグメント上をブロードキャストされるので、ＢＡＳ１３３は、自分宛でない前記ＰＡＤＯメッセージ８０３を、ＰＡＤＯ観測手段８４１によって観測することができる。そして、サーバ間通信情報抽出手段８４２によって、ＰＡＤＯメッセージ８０３中のAC-Cookie TAGにＢＡＳ１３２が格納したサーバ間通信情報９００が抽出される。そしてサーバ情報テーブル更新手段８４３によって、ＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２が、サーバ情報テーブル６４２のエントリ１０１０と同様に、サーバＭＡＣアドレス１００１と負荷情報１００２として新たに登録される。なお、このエントリ１０１０（サーバＭＡＣアドレス１００１及び負荷情報１００２）はサーバ情報テーブル更新手段８２３によって一旦削除されている。前述したように、エントリ１０２０はＢＡＳ１３３自身の情報であるので、サーバ情報テーブル更新手段８１３によって既に更新されている。よって、結果として、ＢＡＳ１３２、１３３のサーバ情報テーブル６４２には再び同じ情報が保持された状態となる。
【００７５】
このようにして、サーバ情報テーブル６４２に登録された新たなエントリは、次回のサイクルにおいてSource MAC Address設定手段８１２、８２２が接続要求の振り分け先となるＢＡＳを決定するために用いられる。
【００７６】
ＰＣ１０１は２つのＰＡＤＯメッセージ８０２と８０３を受信するが、２つのＰＡＤＯメッセージはどちらともSource MAC Addressフィールド４１２がＢＡＳ１３３のＭＡＣアドレス値である。ＰＣ１０１はＲＦＣ２５１６に従った既存の接続先選択手段７３１によってどちらのＰＡＤＯメッセージに対して応答するかを決定してＰＡＤＲメッセージ８０４を送信するが、前記ＰＡＤＲメッセージ８０４がどちらのＰＡＤＯメッセージに応答するものであったとしても、そのDestination MAC Addressフィールド４１１にはＢＡＳ１３３のＭＡＣアドレス値が設定されるので、ＰＡＤＲメッセージ８０４はＢＡＳ１３３が受信する。
【００７７】
ＲＦＣ２５１６の規定によると、クライアント端末がAC-Cookie TAGを含むＰＡＤＯメッセージに対して応答する場合には、受信したAC-Cookie TAGを改変することなくそのままＰＡＤＲメッセージで返送しなければならない。従って、前記ＰＡＤＲメッセージ８０４には、サーバ間通信情報設定手段８１１または８２１によってサーバ間通信情報９００が設定されたAC-Cookie TAGがそのまま格納されている。ＰＡＤＲ受信手段７４１によってＰＡＤＲメッセージ８０４を受信したＢＡＳ１３３は、サーバ間通信情報抽出手段８５１により、このAC-Cookie TAGに含まれるサーバ間通信情報９００を抽出する。タイムアウト判定手段８５２は、サーバ間通信情報９００のうちのＰＡＤＯ送信サーバタイムスタンプ９０３を、ＢＡＳ１３３がＰＡＤＲメッセージ８０４を受信した時刻と比較し、その経過時間がある一定値以上に大きい場合には前記ＰＡＤＲメッセージ８０４は無効であると判断して、受信したＰＡＤＲメッセージ８０４を廃棄する。
【００７８】
ＰＡＤＯ送信サーバタイムスタンプ９０３とＰＡＤＲメッセージ８０４を受信した時刻との比較結果がタイムアウトしていなければ、ＢＡＳ１３３はセッションＩＤ生成手段７４２によってユニークなセッションＩＤ値を生成する。セッション管理テーブル割当手段８５３は、本セッションを管理するためのセッション管理テーブル６４３を割り当て、前記ＰＡＤＲメッセージ８０４のSource MAC Addressフィールド４１２（ＰＣ１０１のＭＡＣアドレス値が格納されている）と前記セッションＩＤとを、前記セッション管理テーブル６４３に登録する。そしてＰＡＤＳ送信手段７４４によってＰＡＤＳメッセージ８０５を送信し、ＰＣ１０１とＢＡＳ１３３との間でＰＰＰｏＥセッションが確立される。
【００７９】
従来のシーケンス（図１６）においては、ＰＡＤＲメッセージを受信しなかったＢＡＳ１３２では、セッション管理テーブル割当手段７１２によって割り当てられたセッション管理テーブル６４３は不要となるため、セッションが成立しなかったシーケンス処理用に割り当てたセッション管理テーブルは、タイムアウトによって解放させる必要があった。しかし、第１の実施の形態（図７）においては、ＰＰＰｏＥディスカバリーステージのシーケンスを管理するために、セッション管理テーブル６４３を利用することなく、ＰＡＤＲメッセージを受信してセッションを確立する段階になってから初めてセッション管理テーブル６４３に割り当てをするので、ＰＡＤＲメッセージを受信しなかったＢＡＳ１３２においてはリソースを解放させるような処理は発生せず、図１０において後述するような内部状態の遷移のみが行われる。
【００８０】
第１の実施の形態は２台のＢＡＳを設置する場合を示しているが、３台以上のＢＡＳを設置する場合においても、クライアント端末（ＰＣ１０１）からのＰＡＤＩメッセージに対して複数のＢＡＳがサーバ間通信情報９００を格納したＰＡＤＯメッセージによって応答するので、各ＢＡＳは、他のＢＡＳが送信したＰＡＤＯメッセージを観測することによって、他の全てのＢＡＳの情報を収集することができる。
【００８１】
また、第１の実施の形態においては、サーバ間通信情報９００はＰＡＤＯメッセージ中のAC-Cookie TAGに格納される。これは、クライアント端末がAC-Cookie TAGを改変することなくそのままＰＡＤＲメッセージで返送しなければならないというＲＦＣ２５１６の規定を利用して、ＰＡＤＯ送信サーバタイムスタンプ９０３をＰＡＤＲメッセージ中に含ませるためである。AC-Cookie TAGは本来、TAG Valueフィールド５３０にクライアント端末のＭＡＣアドレスから生成された値を格納するように規定されているが、詳細は規定されておらず、またクライアント端末はその中身を関知しないので、サーバ間通信情報を格納するのにAC-Cookie TAGを利用すると都合がよい。
【００８２】
例えば、ＢＡＳ１３２のサーバ間通信情報設定手段８１１がＰＡＤＯメッセージ８０３のAC-Cookie TAGに設定したサーバ間通信情報９００は、ＢＡＳ１３３のサーバ間通信情報抽出手段８４２や８５１によって抽出される。すなわち、これらの情報は、サーバ間通信情報９００設定するＢＡＳとは異なるＢＡＳによって抽出されるので、サーバ間通信情報９００が格納されるAC-Cookie TAGのTAG Valueフィールド５３０には、各ＢＡＳで共通のフォーマットが用いられる。図８に示した複数の情報を格納するためには、例えば、図５に示したＴＡＧの形式のように、TAG Typeフィールド、TAG Lengthフィールド、TAG Valueフィールドを持つＴＬＶ形式を用いることができる。
【００８３】
また、サーバ間通信情報９００はクライアント端末に開示する必要のない情報である。悪意のあるクライアント端末がサーバ間通信情報９００を解読することを防ぐために、各ＢＡＳに共通の暗号化／復号化手段を設けることができる。すなわち、各ＢＡＳは暗号化／復号化のための共通のキーを持つ。例えば、前記ＰＡＤＯメッセージ８０３においては、ＢＡＳ１３２のサーバ間通信情報設定手段８１１がＴＬＶ形式のサーバ間通信情報９００を共通の暗号キーで暗号化して、AC-Cookie TAGのTAG Valueフィールド５３０に設定する。ＢＡＳ１３３のサーバ間通信情報抽出手段８４２や８５１は、前記ＰＡＤＯメッセージ８０３中のAC-Cookie TAGのTAG Valueフィールド５３０を前記共通キーで復号化することによって、ＴＬＶ形式のサーバ間通信情報９００を抽出することができる。
【００８４】
また、サーバ間通信情報９００のうち、ＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２とは、ＰＡＤＯメッセージを送信したＢＡＳとは別のＢＡＳが前記ＰＡＤＯメッセージを観測することによって抽出するものであって、ＰＡＤＲメッセージには含まれていなくて構わない。例えば、TAG Typeフィールド５１０にＲＦＣ２５１６で規定されていない独自のＴＡＧを定義して、該ＴＡＧにＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２を格納するように構成することもできる。ＲＦＣ２５１６によれば不明なＴＡＧは単に無視しなければならないので、新しく定義されたＴＡＧを用いることによってクライアント端末側に悪影響を及ぼすことはない。
【００８５】
ＲＦＣ２５１６には規定されていないが、AC-Cookie TAGと同様に、Service-Name TAGやAC-Name TAGもＰＡＤＯメッセージに含まれるものをそのままＰＡＤＲメッセージで返送するように構成されているクライアント端末もある。そのようなクライアント端末における実施の形態としては、サーバ間通信情報をService-Name TAGやAC-Name TAGに格納するように構成することもできる。
【００８６】
図１０は、前述した第１の実施の形態（図７）に示したシーケンスにおいて、ＢＡＳ１３３のＰＰＰｏＥシーケンス処理部６４１で実行される処理を示すフローチャートである。なお、ＢＡＳ１３２においても同様の手順の処理が実行される。
【００８７】
ＰＰＰｏＥシーケンス処理部６４１には、スタンバイ状態１１１０とサイクル起動状態１１２０とがある。
【００８８】
スタンバイ状態１１１０において、ＰＣ１０１からのＰＡＤＩメッセージ８０１を受信すると、ＰＡＤＩ受信７２１から始まる一連のＰＡＤＩ処理手順（具体的には図７で説明したＰＡＤＩ受信７２１→サーバ間通信情報設定８２１→Source MAC Address設定８２２→サーバ情報テーブル更新８２３→ＰＡＤＯ送信７２３からなる処理）が実行され、サイクル起動状態１１２０へと遷移する。
【００８９】
また、スタンバイ状態１１１０において、別のＢＡＳからのＰＡＤＯメッセージ１１３１が観測された場合、サイクル起動状態１１２０において観測された場合と同様に、ＰＡＤＯ観測１１４１から始まる一連のＰＡＤＯ処理手順（具体的には図７で説明したＰＡＤＯ観測８４１→サーバ情報抽出８４２→サーバ情報テーブル更新８４３と同様の処理）が実行される。このときの状態はスタンバイ状態１１１０が維持される。これは後述するように、ＰＡＤＯメッセージを、ＰＡＤＩメッセージに対して応答する場合以外にもＢＡＳ同士で負荷情報の交換を行うことを目的として送信するという実施の形態の変形例を可能とする。
【００９０】
また、スタンバイ状態１１１０において、クライアント端末からのＰＡＤＲメッセージ１１３２を受信した場合、ＰＰＰｏＥシーケンス処理部６４１は何も実行せず、受信したＰＡＤＲメッセージ１１３２はＰＡＤＲ廃棄処理１１５１によって廃棄される。このときの状態はスタンバイ状態１１１０が維持される。これは、サイクル起動状態１１２０の間に受信されなかったＰＡＤＲメッセージが、後に受信されたとしても、遅れて受信されたＰＡＤＲメッセージは時間的有効性が失われるためである。また、クライアント端末がＰＡＤＩメッセージを送信してＰＡＤＯメッセージを受信するという手順を踏まずに、いきなりＰＡＤＲメッセージを送信して接続要求を行うことを防止するためである。
【００９１】
一方、サイクル起動状態１１２０において、別のＢＡＳが送信したＰＡＤＳメッセージ１１３３が観測された場合、又は、サイクル起動状態１１２０に遷移してから一定時間を経過してタイムアウトした場合、ＰＰＰｏＥシーケンス処理部６４１はスタンバイ状態１１１０へと遷移する。
【００９２】
また、サイクル起動状態１１２０においてＰＣ１０１からのＰＡＤＲメッセージ８０４を受信すると、ＰＡＤＲ受信手段７４１から始まる一連のＰＡＤＲ処理手順（具体的には図７で説明したＰＡＤＲ受信７４１→サーバ間通信情報抽出８５１→タイムアウト確認８５２→セッションＩＤ生成７４２→セッション管理テーブル割り当て８５３→ＰＡＤＳ送信７４４からなる処理）が実行されてＰＣ１０１との間でセッションを確立して、ＰＰＰｏＥシーケンス処理部６４１はスタンバイ状態１１１０へと遷移する。
【００９３】
また、サイクル起動状態１１２０において、ＢＡＳ１３２からのＰＡＤＯメッセージ８０３が観測されると、ＰＡＤＯ観測手段によるＰＡＤＯ観測８４１から始まる一連のＰＡＤＯ処理手順（具体的には図７で説明したＰＡＤＯ観測８４１→サーバ情報抽出８４２→サーバ情報テーブル更新８４３からなる処理）が実行される。この一連のＰＡＤＯ処理手順の実行中はサイクル起動状態１０２０が維持される。
【００９４】
また、サイクル起動状態１１２０において、クライアント端末からのＰＡＤＩメッセージ１１３４を受信した場合、ＰＰＰｏＥシーケンス処理部６４１は何も実行せず、受信したＰＡＤＩメッセージ１１３４はＰＡＤＩ廃棄処理１１７１によって廃棄される。このときの状態はサイクル起動状態１１２０が維持される。これは、悪意のあるクライアント端末からＰＡＤＩメッセージが連続して送信された場合に、手順８２１〜８２３、７２３からなるＰＡＤＩ処理手順が起動されて、余計な処理負荷がかかるのを防止するためである。また、サイクルの多重起動を防止することによって、サーバ情報テーブル６４２の管理を容易にし、保持するサーバ情報に不整合が発生するのを防止するためである。
【００９５】
図７及び図１０に示した動作によれば、ＰＡＤＯメッセージを利用してＢＡＳ間で情報交換を行い、各サイクル毎に、互いの持つサーバ情報テーブル６４２を更新し合う。これによって、新たにＢＡＳを追加したり運用中のＢＡＳを停止した場合にも、それぞれのＢＡＳが自律的に新しい構成に適応することができる、柔軟な負荷分散システムを実現している。以下、ＢＡＳを追加、停止した場合の処理について説明する。
【００９６】
図１１は、ＢＡＳ１３２、１３３の２台のＢＡＳが運用されている状態において、３台目のＢＡＳ１２０１が新たに設置された場合のシーケンスを示す。図１１に示す実施の形態において、ＰＡＤＩ、ＰＡＤＯ、ＰＡＤＲメッセージのそれぞれを受信したときに各ＢＡＳでは図７に示した処理が行われる。図１１では、これらの処理をＰＡＤＩ処理、ＰＡＤＯ処理、ＰＡＤＲ処理というように簡略に記述している。なお、ＢＡＳ１２０１の運用開始１２５０の後に、ＰＣ１０１がＰＡＤＩメッセージ１２１１を送信することによって開始した最初のサイクルを、第ｎサイクルとする。
【００９７】
ＰＣ１０１がＰＡＤＩメッセージ１２１１を送信したＰＡＤＩメッセージ１２１１は各ＢＡＳによって受信され、各ＢＡＳでは各々ＰＡＤＩ処理手順１２３１、１２４１、１２５１が実行される。この時点ではＢＡＳ１３２、１３３のサーバ情報テーブル６４２（図９参照）にＢＡＳ１２０１のエントリは存在しないので、ＰＡＤＯメッセージ１２１３と１２１４のSource MAC Addressフィールド４１２にはＢＡＳ１３３のＭＡＣアドレス値が設定される。一方、ＢＡＳ１２０１のサーバ情報テーブル６４２にはＢＡＳ１３２、１３３のエントリが存在しないので、ＰＡＤＯメッセージ１２１２にはSource MAC Addressフィールド４１２にＢＡＳ１２０１自身のＭＡＣアドレス値が設定される。
【００９８】
ＰＣ１０１は３つのＰＡＤＯメッセージ１２１２、１２１３、１２１４を受信し、そのどれかに応答してＰＡＤＲメッセージ１２１５を送信するが、ＰＡＤＯメッセージ１２１３か１２１４に応答した場合にはＢＡＳ１３３との間でセッションが確立され、ＰＡＤＯメッセージ１２１２に応答した場合にはＢＡＳ１２０１との間でセッションが確立される。図１１では、ＰＣ１０１がＢＡＳ１３３を選択してＰＡＤＲを返送し、ＢＡＳ１３３がＰＡＤＳを送信して、ＢＡＳ１３３との間でセッションが確立するシーケンスを示している。
【００９９】
各ＢＡＳは、ＰＡＤＯ処理手順１２３２、１２４２、１２５２によって、他のＢＡＳが送信したＰＡＤＯメッセージを観測し、サーバ情報テーブルを更新するので、第ｎサイクルが完了した時点で、各ＢＡＳの持つサーバ情報管理テーブルには自分自身を含めて３台のＢＡＳ１３２、１３３、１２０１の情報が登録されている。従って、次回のＰＡＤＩメッセージ１２２１を受信することによって開始される第ｎ＋１サイクルにおいては、ＰＣ１０１からの接続要求はＰＡＤＩ処理手順１２６１、１２７１、１２８１によって負荷情報が最小のＢＡＳに振り分けられるので、３台のＢＡＳの間での負荷分散が正しく行われる。
【０１００】
図１２は、ＢＡＳ１３２、１３３の２台で運用されている状態において、保守運用上の理由や装置故障のためにＢＡＳ１３３が停止した場合のシーケンスを示す。図１２において、ＢＡＳ１３３の運用停止１３３０の後に、ＰＣ１０１がＰＡＤＩメッセージ１３１１を送信することによって開始した最初のサイクルを、第ｎサイクルとする。
【０１０１】
ＢＡＳ１３２はＰＡＤＩメッセージ１３１１を受信するが、サーバ情報テーブル６４２（図９参照）にはＢＡＳ１３３のエントリ１０２０が存在するので、ＢＡＳ１３２はSource MAC Addressフィールド４１２にＢＡＳ１３３のＭＡＣアドレス値を設定したＰＡＤＯメッセージ１３１２で応答する。そして、ＰＡＤＩ受信とＰＡＤＯ送信の間に実行されるＰＡＤＩ処理手順１３４１中のサーバ情報更新手段によって、ＢＡＳ１３３のエントリが削除される。
【０１０２】
ＢＡＳ１３３は停止しているので、ＰＣ１０１に対しては、ＢＡＳ１３２から一つのＰＡＤＯメッセージ１３１２のみが送信される。
【０１０３】
ＰＡＤＯメッセージ１３１２を受信したＰＣ１０１は、Destination MAC Addressフィールド４１１にＢＡＳ１３３のＭＡＣアドレス値が設定されたＰＡＤＲメッセージ１３１３によって応答する。しかし前記ＰＡＤＲメッセージ１３１３は、停止しているＢＡＳ１３３によって受信されることはないので、第ｎサイクルにおいてＰＣ１０１はＰＡＤＳメッセージを受信することができず、セッション確立は失敗する。
【０１０４】
ＲＦＣ２５１６には、ＰＡＤＳメッセージを受信できなかったクライアント端末は、何度かＰＡＤＲメッセージを再送し、それでもＰＡＤＳメッセージを受信できなかった場合にはＰＡＤＩメッセージの送信からやり直すことが規定されている。ＰＣ１０１はこの規定に従い、ＰＡＤＲリトライ手段１３５１によって、ＰＡＤＲメッセージを再送し、それでもＰＡＤＳメッセージを受信できないのでＰＡＤＩリトライ手段１３５２によってＰＡＤＩメッセージ１３２１を再送する。ＰＡＤＩメッセージ１３２１はＢＡＳ１３２に受信されて第ｎ＋１サイクルが開始されるが、既にＢＡＳ１３２のサーバ情報テーブル６４２からはＢＡＳ１３３のエントリ１０２０が削除されている。これは、第ｎサイクルにおいて、ＢＡＳ１３３が停止しているためＢＡＳ１３２はＰＡＤＯメッセージを観測してＢＡＳ１３３の情報を得ることができずに、サーバ情報テーブル６４２のＢＡＳ１３３のエントリ１０２０はＰＡＤＩ処理手順１３４１中のサーバ情報更新手段によって削除されたままとなるためである。
【０１０５】
従って、第ｎ＋１サイクルにおいてＢＡＳ１３２が送信するＰＡＤＯメッセージ１３２２では、ＰＡＤＩ処理手順１３６１によってSource MAC Addressフィールド４１２にＢＡＳ１３２自身のＭＡＣアドレス値が指定される。ＰＡＤＯメッセージ１３２２を受信したＰＣ１０１は、Destination MAC Addressフィールド４１１にＢＡＳ１３２のＭＡＣアドレス値が設定されたＰＡＤＲメッセージ１３２３によって応答するので、ＢＡＳ１３２においてＰＡＤＲ処理手順１３６２によって受理されて、ＰＡＤＳメッセージ１３２４が送信されてセッションが確立する。
【０１０６】
このように、運用中のＢＡＳを停止させた際、たまたま停止させたＢＡＳの負荷が低く、接続要求の振り分け先となっていた場合には、セッション確立までに２回のサイクルが費やされることになる。しかし、ＰＣ１０１におけるＰＡＤＲリトライ手段１１５１やＰＡＤＩリトライ手段１１５２はＰＰＰｏＥクライアント機能を提供するソフトウェアによって自動的に実行され、ユーザにはセッション確立までに若干時間がかかったという程度にしか意識されないので、加入者を収容するというサービス自体に問題を及ぼすことなく、システム全体として継続的に運用することができる。
【０１０７】
以上のように、第１の実施の形態では、運用中にシステムの構成が変化した場合でも自律的に適応することができ、柔軟な負荷分散システムを実現している。これは、ＰＡＤＯメッセージを利用してＢＡＳ間でその都度情報交換を行うことにより、システム構成の変化が直ちに各ＢＡＳのサーバ情報テーブル６４２に反映されるからである。また、第１の実施の形態によれば、各ＢＡＳに互いのＢＡＳの情報をあらかじめ登録しておく必要がなく、各ＢＡＳを協調動作させるための特定の管理装置なども必要ない。各ＢＡＳがそれぞれ対等に、自律的に動作した結果として、各ＢＡＳのサーバ情報テーブル６４２が等しい状態を維持することができる。
【０１０８】
以上説明した第１の実施の形態（図７〜図１２）では、Source MAC Address設定手段８１２や８２２によって設定されるSource MAC Addressフィールド４１２の値は、サーバ情報テーブル６４２を参照し、負荷情報１００２の最も小さいエントリのサーバＭＡＣアドレス１００１を選択することによって決定される。よって、この負荷情報１００２は前回のサイクルにおいて収集した情報であった。クライアント端末がＰＡＤＩメッセージを送信したことを契機として負荷情報を交換するという第１の実施の形態の受動的な動作では、前回のサイクルからの時間が開くことがあり、サーバ情報テーブル６４２の保持する負荷情報１００２と現在の負荷状態とのずれが大きくなる可能性がある。
【０１０９】
以下、サーバ情報テーブル６４２に保持される負荷情報１００２が古くなり、現在の負荷状態との齟齬が生じるのを防ぐための第１の実施の形態の変形例について説明する。この実施の形態では、前述した第１の実施の形態の基本的な動作に加えて、ＰＡＤＩメッセージに対して応答する場合以外にも、ＢＡＳ同士で負荷情報の交換を行うことを目的としてＰＡＤＯメッセージが送信される。負荷情報の交換を目的としたこのＰＡＤＯメッセージは、クライアント端末からのＰＡＤＩメッセージに応答するためのものではないので、クライアント端末の動作に悪影響を及ぼすことのないように、Destination MAC Addressフィールド４１１には、例えば、自分自身のＭＡＣアドレス値を設定する。前記ＰＡＤＯメッセージは通常のＰＡＤＯメッセージ８０２や８０３と同様に他のＢＡＳによって観測され、サーバ情報テーブル６４２が更新される。例えば、図１０のフローチャートに示したように、ＢＡＳ１３３がスタンバイ状態１１１０においてＰＡＤＯメッセージ１１３１を受信した場合にも、ＰＡＤＯ観測手段１１４１から始まる一連のＰＡＤＯ受信手順が実行される。負荷情報の交換を目的としたこのようなＰＡＤＯメッセージを送信するタイミングについては、定期的にＰＡＤＯメッセージを送信する方法や、自分自身の実際の負荷状態がサーバ情報テーブル６４２の保持する自分自身の負荷情報９０２から一定限度以上に変化したときにＰＡＤＯメッセージを送信する方法を挙げることができる。
【０１１０】
別の実施の形態の変形例では、あるＢＡＳが他のＢＡＳの情報を収集することを目的としてＰＡＤＩメッセージを送信し、他のＢＡＳにＰＡＤＯメッセージで応答させる。この実施の形態は、例えば、図１１のように、既に運用中のシステムにおいて新たなＢＡＳを後から追加し、そのＢＡＳを始動する際の処理として適用すれば効果的である。
【０１１１】
また別の実施の形態の変形例では、特定のＢＡＳの情報を更新したいＢＡＳが、Destination MAC Addressフィールド４１１に前記特定のＢＡＳのＭＡＣアドレス値を指定したＰＡＤＩメッセージを送信することによって、前記特定のＢＡＳのみにＰＡＤＯメッセージで応答させる。この実施の形態においては、サーバ情報テーブル６４２に、図９に示した情報に加えてＰＡＤＯ送信サーバタイムスタンプ９０３が登録される。このタイムスタンプが示す時刻から一定時間が経過した場合には、当該エントリの情報が古くなったと判断して対応するＢＡＳ宛にＰＡＤＩメッセージが送信される。
【０１１２】
負荷情報として用いる値が装置単位の値であるような実施の形態の変形例においては、負荷情報を管理するのにＡＴＭ ＶＣ（＝仮想ＬＡＮセグメント）毎に独立のサーバ情報テーブル６４２を用いるのではなく、サーバ情報テーブル６４２とは別に単一の負荷情報テーブルが用意される。そうすることにより、どのＡＴＭ ＶＣ上でＰＡＤＯメッセージを観測しても共通の負荷情報テーブルが更新されるので、ＶＣ毎に別々のサーバ情報テーブル６４２で管理するよりも負荷情報の更新頻度が高くなり、それだけ負荷情報が新しい状態に保たれる。また、サーバ情報テーブル６４２の管理に必要な情報が少なくなることによって、テーブルを保持するために必要なメモリの量を節約することができる。このような実施の形態としては、負荷情報として、例えば、当該ＢＡＳにおいて確立されているＰＰＰｏＥセッションの総数を用いるという例が挙げられる。
【０１１３】
同様に、負荷情報として用いる値がネットワークカード単位やインタフェース単位のように、装置を構成する特定の単位毎の値であるような実施の形態の変形例においては、その単位毎の負荷情報テーブルが用意される。
【０１１４】
負荷情報として用いる値がＡＴＭ ＶＣ（＝仮想ＬＡＮセグメント）毎の値であるような実施の形態の変形例においては、図１６に示した第１の実施の形態のように、負荷情報は個々のサーバ情報テーブル６４２毎に独立に管理される。
【０１１５】
以上、各ＢＡＳがクライアント端末との通信に用いるＭＡＣアドレスの値がそれぞれ異なる通常の場合における接続要求を振り分ける第１の実施の形態について説明した。以下に説明する第２の実施の形態では、各ＢＡＳがクライアント端末との通信に用いるＭＡＣアドレスをそれぞれ同一の値に設定した場合における接続要求を振り分けるように構成されている。
【０１１６】
図１３は、図１に示したネットワーク構成において、ＢＡＳ１３２とＢＡＳ１３３とのＭＡＣアドレスを同一とする場合における、ＰＣ１０１とのメッセージシーケンスと、ＰＰＰｏＥシーケンス処理部６４１における処理手順の一例（第２の実施の形態）について説明する。図１３には、ＢＡＳ１３２よりもＢＡＳ１３３の方が負荷が小さい状態で、ＰＣ１０１からのＰＡＤＩメッセージ１４０１を受信してから接続要求の振り分け先であるＢＡＳ１３３によってＰＰＰｏＥセッションが確立されるまでの１サイクルの間の処理を示す。なお、第１の実施の形態（図７）と同一の動作をするものには、同一の符号を付し、その詳細な説明は省略する。
【０１１７】
また、第２の実施の形態では、ＢＡＳ１３２、１３３においてＰＣ１０１との通信に用いるＭＡＣアドレスとして同一の値が設定されているので、ＰＣ１０１がＢＡＳ１３２、１３３のどちらに接続されても、ＰＣ１０１からは接続先が異なることを意識されない。この場合、ＢＡＳ同士が互いを識別するのにＭＡＣアドレスを利用することはできないので、ＭＡＣアドレスとは別に、各ＢＡＳをユニークに識別する（サーバ間において重複することのない）サーバ識別子を設ける。各ＢＡＳには初期状態において自分自身のサーバ識別子が記憶されている。
【０１１８】
ＰＣ１０１が送信したＰＡＤＩメッセージ１４０１に対して、ＢＡＳ１３２、１３３はそれぞれＰＡＤＯメッセージ８０３、８０２によって応答するが、第１の実施の形態（図７）と異なり、サーバ間通信情報設定手段８１１、８１２によって設定されるサーバ間通信情報１５００の含まれる情報が異なることと、Source MAC Address設定手段８１２と８２２が実行されないことである。
【０１１９】
ここで、サーバ間通信情報１５００について説明する。図１４に、サーバ間通信情報１５００を構成する情報の種類と、ＢＡＳ１３２、１３３がサーバ間通信情報１５００として設定する値を示す。
【０１２０】
第２の実施の形態（図１３）のメッセージシーケンスで用いられるサーバ間通信情報１５００には、ＰＡＤＲ宛先サーバ識別子１５０１、ＰＡＤＯ送信サーバ識別子１５０２、ＰＡＤＯ送信サーバ負荷情報９０２、ＰＡＤＯ送信サーバセッションＩＤリスト１５０３及びＰＡＤＯ送信サーバタイムスタンプ９０３が含まれている。これらの情報のうち、ＰＡＤＯ送信サーバ識別子１５０２、ＰＡＤＯ送信サーバ負荷情報９０２及びＰＡＤＯ送信サーバセッションＩＤリスト１５０３は、ＰＡＤＯ観測８３１、８４２で設定される。ＰＡＤＲ宛先サーバ識別子１５０１、及びＰＡＤＯ送信サーバタイムスタンプ９０３はＰＡＤＲ受信１４１１、７４１で設定される。そして、これらの収集された情報は、次回のサイクルにおいて、サーバ間通信情報として設定される（８１１、８１２）。
【０１２１】
ＰＡＤＲ宛先サーバ識別子１５０１は、クライアント端末がこのＰＡＤＯメッセージに応答した場合に、対応するＰＡＤＲメッセージを受信すべきサーバを表す識別子であり、具体的には、両ＢＡＳの負荷状況によって定められ、ＢＡＳ１３３の負荷の方が小さい場合には、ＢＡＳ１３２及びＢＡＳ１３３の何れのＢＡＳが送信したＰＡＤＯメッセージにもＢＡＳ１３３の識別子が設定されている。すなわち、第２の実施の形態では、ＰＡＤＲ宛先サーバ識別子１５０１には、負荷情報１００２（図１５参照）の最も小さいＢＡＳ１３３のサーバ識別子１６０１が指定され、第１の実施の形態（図７）においてSource MAC Address設定手段８１２と８２２によって接続要求の振り分け先となるＢＡＳを指定したのと同様の役割を果たす。
【０１２２】
ＰＡＤＯ送信サーバ識別子１５０２は、このＰＡＤＯメッセージを送信したサーバを表す識別子であり、具体的には、ＢＡＳ１３２が送信したＰＡＤＯメッセージにはＢＡＳ１３２の識別子が、ＢＡＳ１３３が送信したＰＡＤＯメッセージにはＢＡＳ１３３の識別子が設定されている。すなわち、ＰＡＤＯ送信サーバ識別子１５０２は、第１の実施の形態（図８）におけるＰＡＤＯ送信サーバＭＡＣアドレス９０１と同様の役割を果たす。
【０１２３】
ＰＡＤＯ送信サーバ負荷情報９０２は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージ受信時点における、このＰＡＤＯメッセージの送信元のサーバの負荷情報である。具体的には、当該ＢＡＳにおいて確立されているＰＰＰｏＥセッションの総数、当該ＢＡＳのプロセッサ使用率、パケット転送バッファの使用率等が用いられる。
【０１２４】
ＰＡＤＯ送信サーバセッションＩＤリスト１５０３は、このＰＡＤＯメッセージを送信したサーバの、対応するＰＡＤＩメッセージ受信時点における当該ＡＴＭ ＶＣ上で確立しているセッションのセッションＩＤのリストである。例えば、ＢＡＳ１３２では二つのセッションが確立しており、０ｘ１、０ｘ３が、ＢＡＳ１３３では一つのセッションが確立しており、０ｘ２が設定される。このＰＡＤＯ送信サーバセッションＩＤリスト１５０３は、後述するようにセッション確立時にユニークなセッションＩＤ値を生成するために利用される。
【０１２５】
ＰＡＤＯ送信サーバタイムスタンプ９０３は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージを、このＰＡＤＯメッセージの送信元のサーバが受信した時刻である。
【０１２６】
サーバ間通信情報１５００のＰＡＤＲ宛先サーバ識別子１５０１を決定する際に参照されるサーバ情報テーブル６４２は、図１５に示すような情報を保持している。
【０１２７】
サーバ情報テーブル６４２は各サーバ毎のエントリから構成され、第２の実施の形態の場合、ＢＡＳ１３２のエントリ１６１０とＢＡＳ１３３のエントリ１６２０が保持されている。各エントリは、当該サーバをユニークに識別するためのサーバ識別子１６０１、当該サーバの負荷情報１００２及び各サーバにおいて確立しているセッションのセッションＩＤのリストからなる。これらのサーバ情報テーブル６４２の情報は、第１の実施の形態（図７）と同様に、１つ前のサイクルにおいて各ＢＡＳの送信したＰＡＤＯメッセージを観測することによって収集された情報なので、ＢＡＳ１３２、１３３のいずれにおいても、図１５に示す同じ情報が保持されている。
【０１２８】
この第２の実施の形態でも、第１の実施の形態（図７）と同様に、ＰＡＤＯメッセージ１４０２や１４０３は、ＰＡＤＯ観測手段８３１、８４１によって観測される。サーバ間通信情報抽出手段８３２、８４２によって抽出されたサーバ間通信情報１５００のうち、ＰＡＤＯ送信サーバ識別子１５０２が、サーバ情報テーブル更新手段８３３、８４３によって、サーバ情報テーブル６４２にサーバ識別子１６０１として登録される。また、同様に、ＰＡＤＯ送信サーバ負荷情報９０２が負荷情報１００２として登録され、ＰＡＤＯ送信サーバセッションＩＤリスト１５０３がセッションＩＤリスト１６０２として登録される。
【０１２９】
ＰＣ１０１は２つのＰＡＤＯメッセージ１４０２と１４０３を受信するが、ＢＡＳ１３２、１３３のＭＡＣアドレスは同一であるので、２つのＰＡＤＯメッセージのどちらとも、Source MAC Addressフィールド４１２には同一のＭＡＣアドレスが設定されている。ＰＣ１０１が既存の接続先選択手段７３１によりどちらのＰＡＤＯメッセージに対してＰＡＤＲメッセージ１４０４で応答した場合でも、そのDestination MAC Addressフィールド４１１はＢＡＳ１３２、１３３に共通のＭＡＣアドレス値であるので、ＰＡＤＲ受信手段１４１１、７４１により、前記ＰＡＤＲメッセージ１４０４はＢＡＳ１３２、１３３の両方に受信される。ＢＡＳ１３２、１３３は、サーバ間通信情報抽出手段１４１２、８５１により、ＰＡＤＲメッセージ１４０４中に含まれるAC-Cookie TAGからサーバ間通信情報１５００を抽出する。そしてサーバ識別子比較手段１４１３や１４２１により、前記サーバ間通信情報１５００のうちのＰＡＤＲ宛先サーバ識別子１５０１を、自分自身のサーバ識別子と比較する。両者が一致すれば前記ＰＡＤＲメッセージ１４０４を自分宛だと判断して受理するが、一致しなければ自分宛ではないと判断して受理しない。
【０１３０】
前記ＰＡＤＲメッセージ１４０４が、ＰＡＤＯメッセージ１４０２と１４０３のどちらに応答したものであったとしても、その中に格納されているＰＡＤＲ宛先サーバ識別子１５０１はＢＡＳ１３３を示しているので、ＢＡＳ１３２のサーバ識別子比較手段１４１３は前記ＰＡＤＲメッセージ１４０４を受理せず、ＰＡＤＲ廃棄手段１４１４によって廃棄する。ＢＡＳ１３３は、サーバ識別子比較手段１４２１によって前記ＰＡＤＲメッセージ１４０４を受理し、第１の実施の形態（図７）と同様にタイムアウト判定手段８５２によって、ＰＡＤＯ送信サーバタイムスタンプ９０３とＰＡＤＲメッセージ１４０４を受信した時刻までの経過時間がある一定値より小さい場合には、タイムアウトしていないと判断し、ＢＡＳ１３３はセッションＩＤ生成手段１４２２によってユニークなセッションＩＤ値を生成する。
【０１３１】
セッションＩＤ生成手段１４２２では、サーバ情報テーブル６４２のセッションＩＤリスト１６０２が参照され、既に確立されているセッションのセッションＩＤ値と重複しないような値が生成される。そうすることによって、ＢＡＳ１３２とＢＡＳ１３３のＭＡＣアドレスが同一であるという条件の下で、図３に示した仮想ＬＡＮセグメント上の各々のセッションが、セッションＩＤによってユニークに識別できる。
【０１３２】
なお、図３に示すように、ＡＴＭ ＶＣによる仮想ＬＡＮセグメントは各ＤＳＬモデム毎（＝加入者毎）に別々に構築されるので、１つの仮想ＬＡＮセグメント上に多重されるセッション数はそれほど多くはなく、サーバ間通信情報設定手段によりＰＡＤＯメッセージ中に格納されるＰＡＤＯ送信サーバセッションＩＤリスト１５０３がそれほど大きくなる心配はない。
【０１３３】
１つの仮想ＬＡＮセグメントは１人の加入者に対応するので、サーバ情報テーブル６４２のセッションＩＤリスト１６０２を参照すれば、その加入者が確立中のセッションの総数を知ることができる。そのため、セッションＩＤリスト１６０２は、ユニークなセッションＩＤを生成するためだけでなく、加入者毎に（ＢＡＳ１３２、１３３を区別せずに）同時に確立することのできる最大セッション数を制限するという目的にも利用することができる。典型的なＡＤＳＬ加入者収容サービスでは、最大セッション数は１個または数個である。
【０１３４】
第２の実施の形態において、ＰＣ１０１とＢＡＳ１３３との間でＰＰＰｏＥセッションが確立された後にＰＣ１０１から送信されるセッションステージパケットのDestinatioin MAC Addressフィールド４１１は、ＢＡＳ１３２、１３３に共通のＭＡＣアドレスである。従って、ＢＡＳ１３３が前記セッションステージパケットが自分宛であるかどうかを識別するためには、ＰＰＰｏＥヘッダ４２０中のセッションＩＤフィールド４２２まで参照する必要がある。従来は、ＰＨＹ処理部６２０においてDestinatioin MAC Addressフィールド４１１を識別し、ＰＰＰｏＥ処理部６４０においてセッションＩＤフィールド４２２を識別するという方法が一般的である。その場合、ＢＡＳ１３２宛のセッションステージパケットは、ＰＨＹ処理部６２０では自分宛でないことが識別されずにＰＰＰｏＥ処理部６４０まで転送され、そこで初めて自分宛でないことが識別されて廃棄される。しかし、装置の処理性能を向上させる観点からは、余計なパケットは装置の内部まで転送することなく、なるべく装置の入り口部分で廃棄するのが望ましい。そのための図６とは別の装置構成の例として、セッション管理テーブル６４３をＰＨＹ処理部６２０に持たせることによって、ＰＨＹ処理部６２０がDestinatioin MAC Addressフィールド４１１とセッションＩＤフィールド４２２の両方を識別して自分宛のパケットかどうかを判定するという構成とすることもできる。
【０１３５】
また、中継装置１３１には、例えば、従来技術に基づくレイヤ２スイッチを用いることができる。但し、以上説明した実施の形態（図７、図１３）においては、ＰＡＤＯメッセージを利用してＢＡＳ間で情報交換を行うので、あるＢＡＳがクライアント宛に送信したＰＡＤＯメッセージが、物理的に他のＢＡＳに到達しなければならない。従来技術に基づくレイヤ２スイッチは、受信したパケットのSource MAC Addressフィールド４１２の値を回線毎に登録管理するＭＡＣアドレステーブルを備え、どの回線にどのＭＡＣアドレスを持った装置が接続されているかを学習する機能を備えている。そしてパケットを転送する際にはDestinatioin MAC Addressフィールド４１１をキーとして前記ＭＡＣアドレステーブルを検索し、宛先となる装置が接続されている回線のみにパケットを転送する機能を備えている。このＭＡＣアドレス学習機能が機能していると、あるＢＡＳがクライアント宛に送信したＰＡＤＯメッセージが、クライアント端末へ向かう回線のみに転送され、物理的に他のＢＡＳに到達しなくなるので、第１又は第２の実施の形態（図７、図１３）においては、中継装置１３１として従来技術に基づくレイヤ２スイッチを利用する場合には前記ＭＡＣアドレス学習機能を停止した状態で利用する必要がある。
【０１３６】
なお、従来技術に基づくレイヤ２スイッチにおける前記ＭＡＣアドレス学習機能は、パケットを宛先の回線以外には転送しないことによって、回線の帯域を無駄に消費することを防止することが目的である。この従来技術と同様の目的を実現するために、中継装置１３１に次のような機能を設ける実施の形態の変形例を挙げることができる。
【０１３７】
各ＢＡＳのＭＡＣアドレスが異なる通常の場合に適用される第１の実施の形態（図７）では、中継装置１３１は前述したようなＭＡＣアドレス学習機能を備えるが、受信したパケットのEther Typeフィールド４１３の値がＰＰＰｏＥディスカバリーステージパケットであることを表す０ｘ８８６３であった場合には、前記ＭＡＣアドレス学習機能によらずにこのパケットを全ての回線にブロードキャスト（送信）する。このことによって、第１の実施の形態（図７）における、ＰＡＤＯメッセージを観測することによって実現されるＢＡＳ間の情報交換を阻害することがなくなる。また、セッション確立後のセッションステージパケットは前記ＭＡＣアドレス学習機能によってDestinatioin MAC Addressフィールド４１１に基づいて宛先の回線のみに転送することによって、回線の帯域を無駄に消費することを防止することができる。
【０１３８】
各ＢＡＳのＭＡＣアドレスが同一である場合において適用される第２の実施の形態（図１３）では、中継装置１３１はSource MAC Addressフィールド４１２とセッションＩＤフィールド４２２とを対にして学習する機能を備える。セッションＩＤフィールド４２２が０ｘ０であれば、ＰＰＰｏＥディスカバリーステージパケットであるので、全ての回線にブロードキャストする。セッションＩＤフィールド４２２が０ｘ０以外の値であった場合には、Source MAC Addressフィールド４１２とセッションＩＤフィールド４２２の対に基づいて、宛先となるの装置が接続されている回線を特定し、その回線のみに転送することによって、回線の帯域を無駄に消費することを防止することができる。
【０１３９】
特許請求の範囲に記載した以外の本発明の観点の代表的なものとして、次のものがあげられる。
【０１４０】
（１）前記サーバは、
自サーバが確立中のセッションのセッションＩＤのリストを接続提供信号に設定するセッションＩＤリスト設定手段と、
他のサーバが送信した接続提供信号を観測する信号観測手段と、
前記観測された接続提供信号に設定された前記セッションＩＤのリストを抽出するセッションＩＤリスト抽出手段と、
接続要求信号を受信して新たなセッションを確立する際に、前記抽出したセッションＩＤ値と重複しないセッションＩＤ値を割り当てるセッションＩＤ割当手段と、を有することを特徴とする請求項１又は２に記載のネットワークシステム。
【０１４１】
（２）前記サーバは、抽出した前記サーバ識別情報と前記負荷情報とを記憶する記憶手段を有し、
前記サーバが、前記クライアント端末からの接接続開始信号対して接続提供信号によって応答して、互いに前記記憶手段に記憶された負荷情報を更新することを特徴とする請求項３に記載のネットワークシステム。
【０１４２】
（３）前記サーバは、
前記クライアント端末以外の装置からの接続開始信号を受信すると、他のサーバが記憶する負荷情報を更新させるための接続提供信号を送信する接続提供信号送信手段と、
自サーバが記憶する他のサーバの負荷情報を更新するために接続開始信号を送信する接続開始信号送信手段との少なくとも一方の手段を備えることを特徴とする請求項３に記載のネットワークシステム。
【０１４３】
（４）前記サーバは、
前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号の受信時刻を表す受信時刻情報を接続提供信号に設定する時刻情報設定手段と、
前記接続要求信号を受信すると、前記接続要求信号に含まれる前記受信時刻情報を抽出する受信時刻情報抽出手段とを有し、
前記クライアント端末は、前記受信した接続提供信号に含まれる前記受信時刻情報をそのまま接続要求信号に設定して返送する信号返送手段を有し、
前記サーバは、前記接続要求信号の受信時刻と前記受信時刻情報が表す時刻との比較結果に基づいて（例えば、前記接続要求信号の受信時刻が前記受信時刻情報が表す時刻から所定の一定時間以上経過していた場合には）、前記接続要求信号が有効か無効かを判定する判定手段を有することを特徴とする請求項４に記載のネットワークシステム。
【０１４４】
（５）前記サーバは、
各サーバに共通する暗号化手段及び復号化手段を有し、
前記暗号化手段によって暗号化した情報を接続提供信号に設定し、
接続提供信号又は前記接続提供信号に対応して返送された接続要求信号から前記暗号化された情報を抽出し、前記復号化手段によって抽出した暗号化された情報を復号化することを特徴とする請求項４に記載のネットワークシステム。
【０１４５】
（６）前記ＰＰＰｏＥサーバは、
前記ＰＰＰｏＥクライアント端末以外の装置からのＰＡＤＩメッセージを受信すると、ＰＰＰｏＥサーバが記憶する負荷情報を更新させるためのＰＡＤＯメッセージを送信するＰＡＤＯメッセージ送信手段と、
自サーバが記憶する他のＰＰＰｏＥサーバの負荷情報を更新するためにＰＡＤＩメッセージを送信するＰＡＤＩメッセージ送信手段との少なくとも一方の手段を備えることを特徴とする請求項５又は６に記載のネットワークシステム。
【０１４６】
（７）抽出した前記サーバ識別情報（例えば、ＭＡＣアドレス、サーバ識別子）と前記負荷情報とを記憶する記憶手段を有し、
前記クライアント端末からの接続開始信号に対して接続提供信号によって応答して、互いに前記記憶手段に記憶された負荷情報を更新することを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【０１４７】
（８）前記クライアント端末以外の装置からの接続開始信号を受信すると、他のサーバ装置が記憶する負荷情報を更新させるための接続提供信号を送信する接続提供信号送信手段と、
自サーバ装置が記憶する他のサーバ装置の負荷情報を更新するために接続開始信号を送信する接続開始信号送信手段との少なくとも一方の手段を備えることを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【０１４８】
（９）前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号の受信時刻を表す受信時刻情報を接続提供信号に設定する時刻情報設定手段と、
前記接続要求信号を受信すると、前記接続要求信号に含まれる前記受信時刻情報を抽出する時刻情報抽出手段とを有し、
前記接続要求信号の受信時刻と前記受信時刻情報が表す時刻との比較結果に基づいて（例えば、前記接続要求信号の受信時刻が前記受信時刻情報が表す時刻から所定の一定時間以上経過していた場合には）、前記接続要求信号が有効か無効かを判定する判定手段を有することを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【０１４９】
（１０）前記各サーバ装置に共通する暗号化手段及び復号化手段を有し、
前記暗号化手段によって暗号化した情報を接続提供信号に設定し、
接続提供信号又は前記接続提供信号に対応して返送された接続要求信号から前記暗号化された情報を抽出し、前記復号化手段によって抽出した暗号化された情報を復号化することを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【図面の簡単な説明】
【図１】本発明の実施の形態のＤＳＬ網によって加入者を収容するネットワークの構成図である。
【図２】図１に示したネットワークにおけるプロトコルスタック図である。
【図３】図１に示したネットワークにおけるＡＴＭ ＶＣのトポロジを示す説明図である。
【図４】図１に示したネットワークにおけるＰＰＰｏＥパケットのフォーマット図である。
【図５】図１に示したネットワークにおけるＰＰＰｏＥディスカバリーステージパケットのペイロードに格納されるＴＡＧのフォーマット図である。
【図６】本発明の実施の形態のＢＡＳの構成図である。
【図７】第１の実施の形態のＰＰＰｏＥディスカバリーステージのシーケンス図である。
【図８】第１の実施の形態のサーバ間通信情報の構成の説明図である。
【図９】第１の実施の形態のサーバ情報テーブルの内容の説明図である。
【図１０】第１の実施の形態のＰＰＰｏＥシーケンス処理部の処理を示すフローチャートである。
【図１１】第１の実施の形態において、新たにＢＡＳが設置された場合のシーケンス図である。
【図１２】第１の実施の形態において運用中のＢＡＳが停止した場合のシーケンス図である。
【図１３】第２の実施の形態のＰＰＰｏＥディスカバリーステージのシーケンス図である。
【図１４】第２の実施の形態のサーバ間通信情報の構成の説明図である。
【図１５】第１の実施の形態のサーバ情報テーブルの内容の説明図である。
【図１６】従来のＰＰＰｏＥディスカバリーステージのシーケンス図である。
【符号の説明】
１０１ ＰＣ
１３１ 中継装置
１３２，１３３ ＢＡＳ
４１２ Source MAC Addressフィールド
４２２ セッションＩＤフィールド
６４１ ＰＰＰｏＥシーケンス処理部
６４２ サーバ情報テーブル
８１１，８２１ サーバ間通信情報設定手段
８１２，８２２ Source MAC Address設定手段
８１３，８２３，８３３，８４３ サーバ情報テーブル更新手段
８３１，８４１ ＰＡＤＯ観測手段
８３２，８４２，８５１ サーバ間通信情報抽出手段
８５２ タイムアウト判定手段
９０１ ＰＡＤＯ送信サーバＭＡＣアドレス
９０２ ＰＡＤＯ送信サーバ負荷情報
９０３ ＰＡＤＯ送信サーバタイムスタンプ
１４１３，１４２１ サーバ識別子比較手段
１４２２ セッションＩＤ生成手段
１５０１ ＰＡＤＲ宛先サーバ識別子
１５０２ ＰＡＤＯ送信サーバ識別子
１５０３ ＰＡＤＯ送信サーバセッションＩＤリスト
【発明が属する技術分野】
本発明はネットワークシステムに関し、特に、ＰＰＰｏＥネットワークシステムに適用すると好適であって、複数のＰＰＰｏＥサーバを有し、ＰＰＰｏＥクライアント端末からの接続要求がその都度ＰＰＰｏＥサーバ間で振り分けられるＰＰＰｏＥネットワークシステムに関する。
【０００２】
【従来の技術】
ＰＰＰｏＥ(PPP over Ethernet)は、従来アナログ電話回線やＩＳＤＮ回線を経由したダイヤルアップ接続等で用いられていたＰＰＰ(Point-to-Point Protocol)を、イーサネット（登録商標）上に通すために提案されたクライアント・サーバ型のプロトコルで、ＩＥＴＦ(The Internet Engineering Task Force)が１９９９年２月に発行したＲＦＣ２５１６"A Method for Transmitting PPP Over Ethernet(PPPoE)"によって規定されている。ＰＰＰｏＥは、ＡＤＳＬやＦＴＴＨのようなブロードバンドアクセス網における加入者収容プロトコルとして普及しており、例えば、ＮＴＴ地域会社が２００１年１１月現在において提供する「フレッツ・ＡＤＳＬ」や「Ｂフレッツ」というサービスで採用されている。東日本電信電話株式会社は、これらのサービスに関する技術参考資料として、２００１年１０月１７日に「ＩＰ通信網サービスのインタフェース―フレッツシリーズ―第１版」を作成している。
【０００３】
ＲＦＣ２５１６が規定するＰＰＰｏＥのセッション確立シーケンス(Discovery Stage)では、ＰＰＰｏＥクライアント端末と通信可能なＰＰＰｏＥサーバが複数存在する場合に、ＰＰＰｏＥクライアント端末が接続先のＰＰＰｏＥサーバを選択する枠組みが提供されている。
【０００４】
図１６は、従来のＰＰＰｏＥにおけるセッション確立時のＰＣ１０１とＢＡＳ１３２、１３３との間のメッセージシーケンスの一例を示す。
【０００５】
この従来技術では、ＰＣ１０１とＢＡＳ１３２、１３３との間で、例えば、ＰＰＰｏＥディスカバリーステージはＲＦＣ２５１６に規定されたシーケンスの処理を行う等、現在標準的に行われている処理と同様の処理を行う。
【０００６】
まず、ＰＰＰｏＥクライアント端末であるＰＣ１０１が、ＰＡＤＩメッセージ７０１をブロードキャストＭＡＣアドレス宛に送信する。ＰＡＤＩメッセージ７０１は中継装置１３１を経由してＰＰＰｏＥサーバであるＢＡＳ１３２、１３３まで到達し、ＰＡＤＩ受信手段７１１、７２１によって受信される。セッション管理テーブル割当手段７１２、７２２は、本シーケンスの管理用にセッション管理テーブル６４３を割り当て、ＰＡＤＩメッセージ７０１中の、ＰＣ１０１のＭＡＣアドレス値が格納されているSource MAC Addressフィールド４１２を前記セッション管理テーブル６４３に登録する。ＢＡＳ１３２はＰＡＤＯ送信手段７１３によってＰＡＤＯメッセージ７０３をＰＣ１０１のＭＡＣアドレス宛に送信し、ＢＡＳ１３３はＰＡＤＯ送信手段７２３によってＰＡＤＯメッセージ７０２をＰＣ１０１のＭＡＣアドレス宛に送信する。
【０００７】
ＰＣ１０１は２つのＰＡＤＯメッセージ７０２、７０３を受信するが、ＰＣ１０１に設けられた接続先選択手段７３１は、ＰＡＤＯメッセージ中に含まれるService-Name TAGフィールドの値を基準にする等して、ＢＡＳ１３２、１３３のどちらに接続するかを選択する。図１６に示す例では、ＰＣ１０１がＢＡＳ１３３を接続先として選択した場合を示す。この場合、ＰＣ１０１はＰＡＤＲメッセージ７０４をＢＡＳ１３３のＭＡＣアドレス宛に送信する。
【０００８】
ＢＡＳ１３３はＰＡＤＲ受信手段７４１によってＰＡＤＲメッセージ７０４を受信する。セッションＩＤ生成手段７４２によってＰＣ１０１との間でユニークなセッションＩＤ値を生成し、セッション管理テーブル更新手段７４３によって、セッション管理テーブル割当手段７２２が割り当てたセッション管理テーブル６４３に生成されたセッションＩＤ値を登録する。そして、ＰＡＤＳメッセージ送信手段７４４によって、セッションＩＤフィールド４２２に前記セッションＩＤ値を設定したＰＡＤＳメッセージ７４０を、ＰＣ１０１のＭＡＣアドレス宛に送信する（なお、ＰＡＤＩ、ＰＡＤＯ、ＰＡＤＲの各メッセージにおけるセッションＩＤフィールド４２２の値は０ｘ０である）。このように、ＰＡＤＩ、ＰＡＤＯ、ＰＡＤＲ、ＰＡＤＳという２往復のメッセージを送受信することによって、ＰＣ１０１とＢＡＳ１３３との間でＰＰＰｏＥディスカバリーステージが完了し、ＰＰＰｏＥセッションが確立される。
【０００９】
一方、ＰＡＤＲメッセージを受信しなかったＢＡＳ１３２では、ＰＡＤＯメッセージ７０３の送信から一定限度の時間が経過した時点でタイムアウト７５１となり、セッション管理テーブル解放手段７５２によって、セッション管理テーブル割当手段７１２が本シーケンス処理用に割り当てたセッション管理テーブルが解放される。
【００１０】
ＰＰＰｏＥセッションが確立されると、引き続いてＰＰＰネゴシエーション７６０が行われる。ＰＰＰネゴシエーション７６０では、ＰＰＰリンクを確立し（ＬＣＰ）、ユーザ認証を行い（ＣＨＡＰ又はＰＡＰ）、ＰＣ１０１に対してＩＰアドレスが割り当てられる（ＩＰＣＰ）。ＰＰＰネゴシエーション７６０が完了するとＩＰ通信７７０が可能となり、ＰＣ１０１のインターネット１４０への接続性が確立される。
【００１１】
【発明が解決しようとする課題】
前述した、ＰＰＰｏＥクライアント側主導で接続先を選択する従来技術では、特定のＰＰＰｏＥサーバにアクセスが集中し、ＰＰＰｏＥサーバやネットワークの能力を十分に引き出せない可能性がある。
【００１２】
本発明の目的は、ＰＰＰｏＥネットワークシステムにおいて、複数のＰＰＰｏＥサーバ間で、ＰＰＰｏＥクライアント端末からの接続要求をＰＰＰｏＥサーバ主導で特定のＰＰＰｏＥサーバに対して振り分けることができるネットワークシステムを提供することにある。
【００１３】
また、複数のＰＰＰｏＥサーバ間で確立された複数のＰＰＰｏＥセッションの一意性を保証することにある。
【００１４】
さらに、複数のＰＰＰｏＥサーバ間で互いの負荷情報を交換し、ＰＰＰｏＥセッション単位の負荷分散を実現することにある。
【００１５】
さらに、前記負荷分散を実現するにあたり、新たなＰＰＰｏＥサーバを設置したり運用中のＰＰＰｏＥサーバを停止しても、各ＰＰＰｏＥサーバが自律的に新たな構成に適応し、継続的に適切な負荷分散を実現することにある。
【００１６】
さらに、前記各目的を達成するにあたり、ＰＰＰｏＥクライアント端末に対する変更を必要とせず、またＰＰＰｏＥクライアント端末や加入者に前記各目的を達成する手段を意識させないことにある。
【００１７】
【課題を解決するための手段】
上記課題を解決するために、本発明に係るネットワークシステムは、少なくとも１つのクライアント端末と、複数のサーバとの接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応した前記サーバからの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するネットワークシステムにおいて、前記サーバは、前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバを決定し、前記決定されたサーバを識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有する。
【００１８】
また、少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバとの接続を、少なくとも前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージと、前記ＰＡＤＩメッセージに対応して前記サーバから送信されるＰＡＤＯメッセージと、前記ＰＡＤＯメッセージに対応して前記クライアント端末から送信されるＰＡＤＲメッセージとによって実現するネットワークシステムにおいて、前記各ＰＰＰｏＥサーバの、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスをそれぞれ異ならせて設定し、前記ＰＰＰｏＥサーバは、前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信すると、前記ＰＡＤＩメッセージに対応するＰＡＤＲメッセージを受信すべき特定のＰＰＰｏＥサーバのＭＡＣアドレスを前記ＰＡＤＯメッセージに設定する識別情報設定手段を有する。
【００１９】
また、少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバとの接続を、少なくとも前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージと、前記ＰＡＤＩメッセージに対応して前記サーバから送信されるＰＡＤＯメッセージと、前記ＰＡＤＯメッセージに対応して前記クライアント端末から送信されるＰＡＤＲメッセージとによって実現するネットワークシステムにおいて、前記各ＰＰＰｏＥサーバの、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスを同一に設定し、前記ＰＰＰｏＥサーバは、前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信すると、前記ＰＡＤＩメッセージに対応するＰＡＤＲメッセージを受理すべき特定のＰＰＰｏＥサーバのサーバ識別子を前記ＰＡＤＯメッセージに設定する識別情報設定手段を有する。
【００２０】
また、少なくとも１つのクライアント端末との間の接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応したサーバ装置からの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するサーバ装置において、前記クライアント端末からの接続開始信号を受信した前記サーバ装置が、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバ装置を決定し、前記決定されたサーバ装置を識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有する。
【００２１】
【発明の作用および効果】
上記課題を解決するために、本発明に係るネットワークシステムは、少なくとも１つのクライアント端末と、複数のサーバとの接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応した前記サーバからの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するネットワークシステムにおいて、前記サーバは、前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバを決定し、前記決定されたサーバを識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有するので、複数のサーバ（例えば、ＰＰＰｏＥサーバ）間で、クライアント端末（例えば、ＰＰＰｏＥクライアント端末）からの接続要求を、その都度サーバ主導で振り分けることができる。また、複数のサーバ間で、セッション（例えば、ＰＰＰｏＥセッション）単位の負荷分散を実現することができる。
【００２２】
また、各ＰＰＰｏＥサーバが同一のＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスがそれぞれ同一にする場合に、前記各ＰＰＰｏＥサーバに、前記ＭＡＣアドレスとは別のＰＰＰｏＥサーバ間でユニークなサーバ識別子を設け、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＩメッセージに対応するＰＡＤＲメッセージを受理するべきＰＰＰｏＥサーバのサーバ識別子をＰＡＤＯメッセージに設定して前記ＰＰＰｏＥクライアント端末に返送する手段を設け、前記ＰＡＤＲメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＲメッセージ中に含まれる前記サーバ識別子を抽出する手段と、前記サーバ識別子と自分自身のサーバ識別子とを比較して両者が一致する場合に前記ＰＡＤＲメッセージを受理する手段を設けたことによって、前記ＰＡＤＯメッセージによって指定された特定のＰＰＰｏＥサーバが前記ＰＡＤＲメッセージを受理することができる。
【００２３】
また、各ＰＰＰｏＥサーバが同一のＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスがそれぞれ同一である場合に、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＩメッセージを受信するＬＡＮセグメント上で自サーバが確立中の全てのＰＰＰｏＥセッションのセッションＩＤ値のリストをＰＡＤＯメッセージに設定する手段を設け、前記ＰＡＤＯメッセージを送信するのとは別のＰＰＰｏＥサーバに、前記ＬＡＮセグメント上を流れる前記ＰＡＤＯメッセージを観測する手段と、前記ＰＡＤＯメッセージ中に設定された前記セッションＩＤ値のリストを抽出する手段と、抽出した前記セッションＩＤ値のリストを記憶する手段と、ＰＡＤＲメッセージを受信して新たなＰＰＰｏＥセッションを確立する際に、記憶した前記セッションＩＤ値と重複しないセッションＩＤ値を割り当てる手段を設けたことによって、前記ＬＡＮセグメント上での各ＰＰＰｏＥセッションの一意性を保証することができる。
【００２４】
また、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、自サーバの前記ＭＡＣアドレスまたはサーバ識別子と、自サーバの負荷情報とを、ＰＡＤＯメッセージに設定する手段を設け、前記ＰＡＤＯメッセージを観測する別のＰＰＰｏＥサーバに、前記ＰＡＤＯメッセージ中に設定された前記ＭＡＣアドレスまたはサーバ識別子と前記負荷情報とを抽出する手段と、抽出した前記ＭＡＣアドレスまたはサーバ識別子と前記負荷情報とを記憶する手段と、記憶した前記各サーバの負荷情報を元に、ＰＡＤＲメッセージを受信するべきＰＰＰｏＥサーバを決定する手段を設けたことによって、ＰＰＰｏＥサーバ間での負荷分散を実現することができる。
【００２５】
また、各ＰＰＰｏＥサーバが、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージに対してＰＡＤＯメッセージで応答する度毎に互いに負荷情報を更新し合うことによって、新たなＰＰＰｏＥサーバを設置したり運用中のＰＰＰｏＥサーバを停止させたりしても、各ＰＰＰｏＥサーバが自律的に新たな構成に適応し、前記新たな構成における各ＰＰＰｏＥサーバ間での適切な負荷分散を可能とする。
【００２６】
また、ＰＰＰｏＥサーバが、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信した場合以外の任意時点において、他のＰＰＰｏＥサーバの記憶する負荷情報を更新させることを目的としてＰＡＤＯメッセージを送信したり、自サーバが記憶する他のＰＰＰｏＥサーバの負荷情報を更新することを目的としてＰＡＤＩメッセージを送信することができる。
【００２７】
また、ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＩメッセージの受信時刻を表すタイムスタンプをＰＡＤＯメッセージに設定して前記ＰＰＰｏＥクライアント端末に返送する手段を設け、前記ＰＡＤＲメッセージを受信するＰＰＰｏＥサーバに、前記ＰＡＤＲメッセージ中に含まれる前記タイムスタンプを抽出する手段と、前記ＰＡＤＲメッセージの受信時刻が前記タイムスタンプの示す時刻から一定時間以上経過していた場合には前記ＰＡＤＲメッセージを無効と判定する手段を設けたので、無効なメッセージに基づく無駄な処理を排除することができる。
【００２８】
また、各ＰＰＰｏＥサーバに、共通の暗号化／復号化手段を設け、ＰＡＤＯメッセージを送信するＰＰＰｏＥサーバが上記のような各種情報を設定するのに前記暗号化手段を適用し、ＰＡＤＯメッセージやＰＡＤＲメッセージから前記各種情報を抽出するＰＰＰｏＥサーバが前記復号化手段を適用することによって、ＰＰＰｏＥサーバ間で交換される前記各種情報の内容をＰＰＰｏＥクライアント端末から隠蔽することができる。
【００２９】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００３０】
図１は、ＤＳＬ網によって加入者を収容するネットワークにおいて本発明を適用した一例を示したネットワーク構成図である。
【００３１】
ＤＳＬ(Digital Subscriber Line)は、電話線を用いた高速ディジタル伝送方式である。ＤＳＬによる加入者収容システムでは、加入者宅に設置されたＤＳＬモデム１１１は加入者側のEthernetインタフェースによってパーソナルコンピュータ(PC)１０１と接続される。また、ＤＳＬモデムに宅内ルータ１０２を接続して、宅内ルータ１０２に複数のパーソナルコンピュータを接続して、宅内ルータ１０２を経由して複数台のＰＣをＤＳＬ回線に接続することもできる。また、ＤＳＬモデム１１３がＵＳＢ(Universal Serial Bus)を有する場合には、ＵＳＢによってパーソナルコンピュータと接続することもできる。
【００３２】
ＤＳＬモデム１１１は、モジュラーコネクタ(RJ-11)による一般の電話回線インタフェースによって加入者宅の電話線に接続される。電話局側にはＤＳＬＡＭ(DSL Access Multiplexer)１１２が設置され、複数の加入者宅からのＤＳＬ回線を収容する。ＤＳＬＡＭ１１２はＡＴＭ網によって構成されるネットワーク側にＡＴＭインタフェースを持ち、ＡＴＭ網１２０へ接続されている。ＡＴＭ網１２０は、ＤＳＬ網１１０と、ＩＳＰのネットワーク（ＩＳＰ網）１３０とを接続する。
【００３３】
ＩＳＰ網１３０の入り口には中継装置１３１が設置される。中継装置１３１はＡＴＭインタフェースを備え、ＡＴＭ網１２０と、ＢＡＳ(Broadband Access Server)１３２、１３３とを接続する。ＢＡＳ１３２、１３３はＩＳＰ内ＬＡＮ１３４に接続される。ＩＳＰ内ＬＡＮ１３４には、認証サーバ、ＤＮＳサーバ、Ｗｅｂサーバ、Ｍａｉｌサーバ等が設置され、加入者へInternet１４０への接続をはじめとする種々のサービスを提供する。
【００３４】
図２は、ＰＣ１０１からＢＡＳ１３２、１３３までの区間におけるプロトコルスタックを示す。
【００３５】
ＰＣ１０１は、ＰＰＰｏＥクライアント端末として機能し、ＢＡＳ１３２や１３３との間でＰＰＰｏＥセッションおよびＰＰＰセッションを確立し、インターネット(Internet)１４０に対してＩＰ(Internet Protocol)通信を行う。ＰＰＰｏＥクライアントの機能は、ＰＣに直接行わせる場合の他、宅内ルータ１０２やＤＳＬモデム１１１等の加入者宅内の別の装置に実行させることもできる。
【００３６】
ＢＡＳ１３２、１３３は、ＰＰＰｏＥサーバの機能を有する。ＰＣ１０１等の各加入者宅のＰＰＰｏＥクライアント端末との間でＰＰＰｏＥセッションおよびＰＰＰセッションを確立することによって、各加入者のＰＣ１０１をインターネット１４０に接続して、インターネット接続サービスを提供する。
【００３７】
ＤＳＬ網１１０内では、レイヤ２にＡＴＭ(Asynchronous Transfer Mode)が用いられる。ＤＳＬモデム１１１は、ＰＣ１０１から受信したイーサネットフレームをＲＦＣ１４８３ブリッジ形式のＡＴＭ ＡＡＬ５パケットにカプセル化し、さらにＡＴＭセル化してＤＳＬＡＭ１１２に向けて転送する。ＤＳＬＡＭ１１２はＤＳＬからＡＴＭへの物理レイヤ変換を行い、ＤＳＬモデム１１１から受信したＡＴＭセルをそのままＡＴＭ網１２０へ転送する。ＡＴＭ網１２０内にはＡＴＭスイッチが配置され、ＡＴＭセルレベルでの転送が行われる。
【００３８】
中継装置１３１は、ＡＴＭ網とＢＡＳ１３２、１３３との間でイーサネットフレームレベルの中継を行う。この中継装置１３１は、複数のＡＴＭ ＶＣ(ATM Virtual Connection)をグループ化して仮想ＬＡＮセグメントを構成する機能を有する。あるＶＣ上で受信したイーサネットフレームは、同一グループに属する他の全てのＶＣ上にブロードキャストされる。
【００３９】
ＤＳＬモデム１１１からＢＡＳ１３２、１３３までの区間の通信では、レイヤ２にＡＴＭが用いられ、ＡＴＭレイヤの上位をイーサネットフレームがＲＦＣ１４８３ブリッジ形式のＡＴＭ ＡＡＬ５パケットとして転送される。
【００４０】
図３は、この区間におけるＡＴＭ ＶＣのトポロジを示す。
【００４１】
中継装置１３１とＢＡＳ１３２、１３３及びＤＳＬモデム１１１間に設けられたＶＣ３２０、３３０、３１０は、１つの仮想ＬＡＮセグメントを形成する。ＰＣ１０１が送信したイーサネットフレームは、ＤＳＬモデム１１１において、ＲＦＣ１４８３ブリッジ形式のＡＡＬ５パケットにカプセル化され、さらにＡＴＭセル化されてＶＣ３１０上に送信される。このＡＴＭセルは、ＤＳＬＡＭ１１２やＡＴＭ網１２０においてはＡＴＭセルのまま転送され、中継装置１３１に到達する。中継装置１３１は、ＶＣ３１０上で受信したＡＴＭセルからＡＡＬ５パケットを復元し、上位レイヤのイーサネットフレームを取り出す。このイーサネットフレームは、ＶＣ３１０と同一の仮想ＬＡＮセグメントに属するＶＣ３２０と３３０に向けて送信（ブロードキャスト）される。その際、イーサネットフレームは再びＲＦＣ１４８３ブリッジ形式のＡＡＬ５パケットにカプセル化され、さらにＡＴＭセル化される。
【００４２】
ＢＡＳ１３２、１３３は、ＶＣ３２０や３３０上で受信したＡＴＭセルからＡＡＬ５パケットを復元し、上位レイヤのイーサネットフレームを取り出す。このようにして、ＰＣ１０１とＢＡＳ１３２、１３３ の間のイーサネットレベルの通信が実現される。ＢＡＳ１３２、１３３からＰＣ１０１への通信についても同様である。
【００４３】
ＢＡＳは、１人の加入者を１つのＡＴＭ ＶＣによって収容する。ＤＳＬモデムは加入者宅毎に設置されるので、１つのＤＳＬモデムからＢＡＳ１３２、１３３に１本ずつのＶＣが設定される。つまり、各ＤＳＬモデムはそれぞれ独立の仮想イーサネットセグメントに収容される。このようにして、ＩＳＰ(Internet Service Provider)は加入者をＡＴＭ ＶＣによって識別することができる。
【００４４】
なお、ＤＳＬモデム１１１、ＤＳＬＡＭ１１２、ＡＴＭ網１２０内の装置のいずれかが、前記中継装置１３１として機能する場合には、中継装置１３１を別個に設置せず、ＢＡＳ１３２、１３３を直接ＡＴＭ網１２０に接続するというネットワーク構成とすることもできる。
【００４５】
図４は、ＲＦＣ２５１６で規定されるＰＰＰｏＥパケットのデータフォーマットを示す。
【００４６】
ＰＰＰｏＥパケットは、イーサネットヘッダ４１０中のEther Typeフィールド４１３の値によって、その種類が識別される。Ether Typeフィールド４１３の値が０ｘ８８６３ならばディスカバリーステージ(Discovery Stage Packet)パケットであることを表し、ＰＰＰｏＥセッションの確立時や切断時に流されるメッセージパケットである。Ether Typeフィールド４１３の値が０ｘ８８６４ならばセッションステージパケット(Session Stage Packet)を表し、セッション確立中に流されるデータパケットである。
【００４７】
イーサネットヘッダ４１０の後にはＰＰＰｏＥヘッダ４２０が続く。ＰＰＰｏＥヘッダ４２０中のCodeフィールド４２１によってディスカバリーステージパケットの種類が識別され、セッションＩＤ(Session ID)フィールド４２２によって同一回線上に多重された複数のＰＰＰｏＥセッションが識別される。
【００４８】
ペイロード４３０には、ディスカバリーステージパケットではＴＡＧと呼ばれる情報フィールドが格納され、セッションステージパケットでは上位レイヤとしてＰＰＰフレームが格納される。
【００４９】
図５は、ペイロード４３０に格納されるＴＡＧのデータフォーマットを示す。
【００５０】
ＴＡＧには、Service#Name、AC#Name、AC#Cookie等の種類がある。TAG Typeフィールド５１０によってＴＡＧの種類が識別される。TAG Valueフィールド５３０はＴＡＧの値を格納する可変長のフィールドで、TAG Lengthフィールド５２０によってそのバイト数が識別される。
【００５１】
図６は、本発明の接続要求振り分け方法を実現するＢＡＳ１３３の装置構成例を示す。
【００５２】
ＢＡＳ１３２は、ＢＡＳ１３３と同様の構成であるか、またはＢＡＳ１３３と同等の機能を実現する別の構成であっても構わない。
【００５３】
ＢＡＳ１３３はいくつかのネットワークインタフェースを持つ。ＡＴＭポート６１１は中継装置１３１に接続されており、ＰＣ１０１からの通信を収容するＶＣ３３０が設定されている。ポート６１２はＩＳＰ内ＬＡＮ１３４と接続されているが、ＩＳＰ内ＬＡＮ１３４とのインタフェース種別に応じて、ＡＴＭインタフェースであったりイーサネットインタフェースであったりする。
【００５４】
ＰＨＹ処理部６２０では、ＡＴＭやイーサネット（登録商標）などの物理レイヤが終端され、ＭＡＣフレームが取り出される。例えば、ＰＣ１０１が送信したＰＰＰｏＥパケットは、ＡＴＭポート６１１のＶＣ３３０上でＡＴＭセルとして受信され、ＰＨＹ処理部６２０においてＡＴＭセルからＡＡＬ５パケットが復元され、図４に示したようなＰＰＰｏＥパケットが取り出される。取り出されたＰＰＰｏＥパケットは転送処理部６３０を経由してＰＰＰｏＥ処理部６４０に転送される。ＰＰＰｏＥシーケンス処理部６４１はディスカバリーステージパケットを処理し、別のＢＡＳとの間で接続要求の振り分けを実現する。例えば、ＰＣ１０１からＰＡＤＩメッセージを受信した場合、ＰＰＰｏＥシーケンス処理部６４１は後述するサーバ間通信情報９００（図８参照）を含んだＰＡＤＯメッセージを生成し、転送処理部６３０を経由してＡＴＭポート６１１を介してＶＣ３３０に向けて返送する。ＰＨＹ処理部６２０は、前記ＰＡＤＯメッセージをＡＡＬ５パケットにカプセル化し、さらにＡＴＭセル化してＡＴＭポート６１１のＶＣ３３０上に送信する。
【００５５】
ＰＰＰｏＥ処理部６４０は、ＰＰＰｏＥシーケンス処理部６４１、サーバ情報テーブル６４２セッション管理テーブル６４３によって構成される。サーバ情報テーブル６４２はＡＴＭ ＶＣ（仮想ＬＡＮセグメント）毎に別々に管理されているＢＡＳの情報を収集して、保持する。ＰＰＰｏＥシーケンス処理部６４１がクライアント端末からの接続要求を振り分けるＢＡＳを決定したり、セッション確立時にユニークなセッションＩＤを生成するのに利用される。ＰＰＰｏＥシーケンス処理部６４１における処理フローや、サーバ情報テーブル６４２の詳細については後述する。
【００５６】
セッション管理テーブル６４３は、確立したＰＰＰｏＥセッションの情報を管理し、セッションステージパケットのカプセル化／デカプセル化処理はセッション管理テーブル６４３を参照して実行される。セッションステージパケットは、ＰＰＰｏＥ処理部６４０においてイーサネットヘッダ４１０とＰＰＰｏＥヘッダ４２０を外され、ＰＰＰ処理部６５０に転送される。ＰＰＰ処理部６５０はクライアント端末（例えば、ＰＣ１０１）との間でＰＰＰネゴシエーション（ＬＣＰ、ＣＨＡＰ、ＰＡＰ、ＩＰＣＰ等）を行い、ＰＰＰセッションを確立する。ＰＰＰセッション確立後のデータパケットはＰＰＰ処理部６５０においてＰＰＰヘッダを外され、ＩＰ処理部６６０に転送される。ＩＰ処理部６６０は、ＩＰヘッダのDestination IP Address（宛先ＩＰアドレス）フィールドによってルーティングテーブルから転送先のポートを検索する。この検索結果に基づき、インターネット１４０へ向かうパケットは転送処理部６３０を経由してＩＳＰ内ＬＡＮ１３４と接続されたポート６１２へ向けて転送される。このＩＰパケットは、ＰＨＹ処理部６２０においてポート６１２のインタフェース種別に対応した物理レイヤのカプセル化が行われ、ポート６１２上に送信される。
【００５７】
インターネット１４０からＰＣ１０１へ向かうＩＰパケットはポート６１２上で受信され、前述とは逆に、ＰＨＹ処理部６２０→転送処理部６３０→ＩＰ処理部６６０→ＰＰＰ処理部６５０→ＰＰＰｏＥ処理部６４０→転送処理部６３０→ＰＨＹ処理部６２０という経路を辿りながら処理される。ＩＰ処理部６６０においては、ＩＰヘッダのDestination IP Addressフィールドをキーとしてルーティングテーブルが検索され、転送先であるＰＣ１０１の論理回線がＡＴＭポート６１１上のＶＣ３３０であることが分かる。ＰＣ１０１へ向かうＩＰパケットはＰＰＰ処理部６５０においてＰＰＰヘッダでカプセル化され、ＰＰＰｏＥ処理部６４０においてさらにＰＰＰｏＥヘッダ４２０とイーサネットヘッダ４１０でカプセル化される。
【００５８】
このようにして、ＢＡＳ１３３におけるＰＰＰｏＥシーケンス処理、ＰＰＰシーケンス処理、ＩＰパケット転送等の機能が実現される。
【００５９】
次に、ＰＣ１０１と、ＢＡＳ１３２、１３３とのメッセージシーケンス、及び、ＰＰＰｏＥシーケンス処理部６４１における処理について説明する。本発明に係る接続要求の振り分け機能は、ＰＰＰｏＥシーケンス処理部６４１において実現される。接続要求の振り分けを実現する具体的な方法は、ＢＡＳ１３２とＢＡＳ１３３とでＰＣ１０１との通信に用いるＭＡＣアドレスの値が異なる場合（図７）と、ＭＡＣアドレスを同一の値とする場合（図１３）とについて説明する。
【００６０】
図７は、図１に示したネットワーク構成において、ＢＡＳ１３２とＢＡＳ１３３とが異なるＭＡＣアドレスで通信をする通常の場合における、ＰＣ１０１とのメッセージシーケンスと、ＰＰＰｏＥシーケンス処理部６４１における処理手順の一例（第１の実施の形態）を示すものであるが、図７に示すメッセージシーケンスにおいて、ＢＡＳ１３２、１３３で用いられる、サーバ間通信情報９００（図８）、サーバ情報テーブル６４２（図９）について先に説明する。
【００６１】
図８に、サーバ間通信情報９００を構成する情報の種類と、ＢＡＳ１３２、１３３がサーバ間通信情報９００として設定する値を示す。
【００６２】
第１の実施の形態（図７）のメッセージシーケンスで用いられるサーバ間通信情報９００には、ＰＡＤＯ送信サーバＭＡＣアドレス９０１、ＰＡＤＯ送信サーバ負荷情報９０２及びＰＡＤＯ送信サーバタイムスタンプ９０３が含まれている。これらの情報のうち、ＰＡＤＯ送信サーバＭＡＣアドレス９０１及びＰＡＤＯ送信サーバ負荷情報９０２は、ＰＡＤＯ観測８３１、８４２で設定される。ＰＡＤＯ送信サーバタイムスタンプ９０３はＰＡＤＲ受信７４１で設定される。そして、これらの収集された情報は、次回のサイクルにおいて、サーバ間通信情報として設定される（８１１、８１２）。
【００６３】
ＰＡＤＯ送信サーバＭＡＣアドレス９０１は、このＰＡＤＯメッセージの送信元のサーバのＭＡＣアドレスであり、具体的には、ＢＡＳ１３２が送信したＰＡＤＯメッセージにはＢＡＳ１３２のＭＡＣアドレスが、ＢＡＳ１３３が送信したＰＡＤＯメッセージにはＢＡＳ１３３のＭＡＣアドレスが設定されている。
【００６４】
ＰＡＤＯ送信サーバ負荷情報９０２は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージ受信時点における、このＰＡＤＯメッセージの送信元のサーバの負荷情報である。具体的には、当該ＢＡＳにおいて確立されているＰＰＰｏＥセッションの総数、当該ＢＡＳのプロセッサ使用率、パケット転送バッファの使用率等が用いられる。
【００６５】
ＰＡＤＯ送信サーバタイムスタンプ９０３は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージを、このＰＡＤＯメッセージの送信元のサーバが受信した時刻である。
【００６６】
図９に、サーバ間通信情報設定８１１、８２１時点でＢＡＳ１３２、１３３が当該ＬＡＮセグメントにおいて保持するサーバ情報テーブル６４２の内容を示す。
【００６７】
サーバ情報テーブル６４２は各サーバ毎のエントリから構成され、第１の実施の形態の場合、ＢＡＳ１３２のエントリ１０１０とＢＡＳ１３３のエントリ１０２０が保持されている。各エントリは、当該サーバをユニークに識別するためのサーバＭＡＣアドレス１００１と、当該サーバの負荷情報１００２とからなる。後述するように、サーバ情報テーブル６４２の情報は、１つ前のサイクルにおいて各ＢＡＳが送信したＰＡＤＯメッセージを観測することによって収集された情報なので、ＢＡＳ１３２、１３３のいずれにおいても、図９に示す同じ情報が保持されている。
【００６８】
次に、図７に従って、ＢＡＳ１３２とＢＡＳ１３３とが異なるＭＡＣアドレスで通信をする通常の場合における、ＰＣ１０１とのメッセージシーケンスと、ＰＰＰｏＥシーケンス処理部６４１における処理手順の一例について説明する。図７には、ＢＡＳ１３２よりもＢＡＳ１３３の方が負荷が小さい状態で、ＰＣ１０１からのＰＡＤＩメッセージ８０１を受信してから接続要求の振り分け先であるＢＡＳ１３３によってＰＰＰｏＥセッションが確立されるまでの１サイクルの間の処理を示す。
【００６９】
ＰＣ１０１がＰＡＤＩメッセージ８０１をブロードキャストすると、ＢＡＳ１３２、１３３はそれぞれＰＡＤＩ受信手段７１１、７２１によってこれを受信する。前記ＰＡＤＩメッセージ８０１に対して、ＢＡＳ１３２、１３３は、それぞれＰＡＤＯメッセージ８０３、８０２によって応答するが、当該ＰＡＤＯメッセージを生成する際、サーバ間通信情報設定手段８１１、８２１によって、ペイロード４３０中のAC-Cookie TAGのTAG Valueの値としてサーバ間通信情報９００を設定する。
【００７０】
従来のシーケンス（図１６）においては、接続要求の振り分けを行わないので、ＢＡＳ１３２、１３３が送信するＰＡＤＯメッセージ７０３や７０２のSource MAC Addressフィールド４１２には自分自身のＭＡＣアドレス値が設定されているが、第１の実施の形態（図７）においては、ＰＡＤＯメッセージ８０３のSource MAC Addressフィールド４１２と、ＰＡＤＯメッセージ８０２のSource MAC Addressフィールド４１２とには、Source MAC Address設定手段８１２、８２２によって、接続要求の振り分け先となるＢＡＳのＭＡＣアドレス値が設定される。Source MAC Address設定手段８１２、８２２は、接続要求の振り分け先となるＢＡＳを決定するためにサーバ情報テーブル６４２（図９参照）を参照し、負荷の最も小さいＢＡＳのエントリを選択し（図９に示す状態では、Ｌ４＜Ｌ３なのでＢＡＳ１３３の負荷が小さく、ＢＡＳ１３３が選択される）、そのサーバＭＡＣアドレス１００１をＰＡＤＯメッセージ８０３のSource MAC Addressフィールド４１２と、にＰＡＤＯメッセージ８０２とのSource MAC Addressフィールド４１２とに設定する。
【００７１】
Source MAC Address設定手段８１２、８２２が実行された後、サーバ情報テーブル更新手段８１３、８２３によって、サーバ情報テーブル６４２の自分自身のエントリが現在の情報に更新され、他のＢＡＳのエントリが削除される。そして、ＰＡＤＯ送信手段７１３によって、ＰＡＤＯメッセージ８０３が送信され、ＰＡＤＯ送信手段７２３によって、ＰＡＤＯメッセージ８０２が送信される。
【００７２】
ＢＡＳ１３３が送信するＰＡＤＯメッセージ８０２は、Destination MAC Addressフィールド４１１にＰＣ１０１のＭＡＣアドレス値が設定されており、ＰＣ１０１宛のユニキャストイーサネットフレームであるが、物理的には図３に示した仮想ＬＡＮセグメント上をブロードキャストされる。従ってＢＡＳ１３２は、自分宛でない前記ＰＡＤＯメッセージ８０２を、ＰＡＤＯ観測手段８３１によって観測することができる。
【００７３】
そして、サーバ間通信情報抽出手段８３２によって、ＢＡＳ１３３がＰＡＤＯメッセージ８０２中のAC-Cookie TAGに格納したサーバ間通信情報９００が抽出される。そしてサーバ情報テーブル更新手段８３３によって、ＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２が、サーバ情報テーブル６４２のエントリ１０２０と同様に、サーバＭＡＣアドレス１００１と負荷情報１００２として新たに登録される。なお、このエントリ１０２０（サーバＭＡＣアドレス１００１及び負荷情報１００２）はサーバ情報テーブル更新手段８１３によって一旦削除されている。前述したように、エントリ１０１０はＢＡＳ１３２自身の情報であるので、サーバ情報テーブル更新手段８１３によって既に更新されている。
【００７４】
ＢＡＳ１３３においても同様に、ＢＡＳ１３２が送信するＰＡＤＯメッセージ８０３をＰＡＤＯ観測手段８４１によって観測することができ、サーバ間通信情報抽出手段８４２、サーバ情報テーブル更新手段８４３が実行される。すなわち、ＢＡＳ１３２が送信するＰＡＤＯメッセージ８０３は、仮想ＬＡＮセグメント上をブロードキャストされるので、ＢＡＳ１３３は、自分宛でない前記ＰＡＤＯメッセージ８０３を、ＰＡＤＯ観測手段８４１によって観測することができる。そして、サーバ間通信情報抽出手段８４２によって、ＰＡＤＯメッセージ８０３中のAC-Cookie TAGにＢＡＳ１３２が格納したサーバ間通信情報９００が抽出される。そしてサーバ情報テーブル更新手段８４３によって、ＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２が、サーバ情報テーブル６４２のエントリ１０１０と同様に、サーバＭＡＣアドレス１００１と負荷情報１００２として新たに登録される。なお、このエントリ１０１０（サーバＭＡＣアドレス１００１及び負荷情報１００２）はサーバ情報テーブル更新手段８２３によって一旦削除されている。前述したように、エントリ１０２０はＢＡＳ１３３自身の情報であるので、サーバ情報テーブル更新手段８１３によって既に更新されている。よって、結果として、ＢＡＳ１３２、１３３のサーバ情報テーブル６４２には再び同じ情報が保持された状態となる。
【００７５】
このようにして、サーバ情報テーブル６４２に登録された新たなエントリは、次回のサイクルにおいてSource MAC Address設定手段８１２、８２２が接続要求の振り分け先となるＢＡＳを決定するために用いられる。
【００７６】
ＰＣ１０１は２つのＰＡＤＯメッセージ８０２と８０３を受信するが、２つのＰＡＤＯメッセージはどちらともSource MAC Addressフィールド４１２がＢＡＳ１３３のＭＡＣアドレス値である。ＰＣ１０１はＲＦＣ２５１６に従った既存の接続先選択手段７３１によってどちらのＰＡＤＯメッセージに対して応答するかを決定してＰＡＤＲメッセージ８０４を送信するが、前記ＰＡＤＲメッセージ８０４がどちらのＰＡＤＯメッセージに応答するものであったとしても、そのDestination MAC Addressフィールド４１１にはＢＡＳ１３３のＭＡＣアドレス値が設定されるので、ＰＡＤＲメッセージ８０４はＢＡＳ１３３が受信する。
【００７７】
ＲＦＣ２５１６の規定によると、クライアント端末がAC-Cookie TAGを含むＰＡＤＯメッセージに対して応答する場合には、受信したAC-Cookie TAGを改変することなくそのままＰＡＤＲメッセージで返送しなければならない。従って、前記ＰＡＤＲメッセージ８０４には、サーバ間通信情報設定手段８１１または８２１によってサーバ間通信情報９００が設定されたAC-Cookie TAGがそのまま格納されている。ＰＡＤＲ受信手段７４１によってＰＡＤＲメッセージ８０４を受信したＢＡＳ１３３は、サーバ間通信情報抽出手段８５１により、このAC-Cookie TAGに含まれるサーバ間通信情報９００を抽出する。タイムアウト判定手段８５２は、サーバ間通信情報９００のうちのＰＡＤＯ送信サーバタイムスタンプ９０３を、ＢＡＳ１３３がＰＡＤＲメッセージ８０４を受信した時刻と比較し、その経過時間がある一定値以上に大きい場合には前記ＰＡＤＲメッセージ８０４は無効であると判断して、受信したＰＡＤＲメッセージ８０４を廃棄する。
【００７８】
ＰＡＤＯ送信サーバタイムスタンプ９０３とＰＡＤＲメッセージ８０４を受信した時刻との比較結果がタイムアウトしていなければ、ＢＡＳ１３３はセッションＩＤ生成手段７４２によってユニークなセッションＩＤ値を生成する。セッション管理テーブル割当手段８５３は、本セッションを管理するためのセッション管理テーブル６４３を割り当て、前記ＰＡＤＲメッセージ８０４のSource MAC Addressフィールド４１２（ＰＣ１０１のＭＡＣアドレス値が格納されている）と前記セッションＩＤとを、前記セッション管理テーブル６４３に登録する。そしてＰＡＤＳ送信手段７４４によってＰＡＤＳメッセージ８０５を送信し、ＰＣ１０１とＢＡＳ１３３との間でＰＰＰｏＥセッションが確立される。
【００７９】
従来のシーケンス（図１６）においては、ＰＡＤＲメッセージを受信しなかったＢＡＳ１３２では、セッション管理テーブル割当手段７１２によって割り当てられたセッション管理テーブル６４３は不要となるため、セッションが成立しなかったシーケンス処理用に割り当てたセッション管理テーブルは、タイムアウトによって解放させる必要があった。しかし、第１の実施の形態（図７）においては、ＰＰＰｏＥディスカバリーステージのシーケンスを管理するために、セッション管理テーブル６４３を利用することなく、ＰＡＤＲメッセージを受信してセッションを確立する段階になってから初めてセッション管理テーブル６４３に割り当てをするので、ＰＡＤＲメッセージを受信しなかったＢＡＳ１３２においてはリソースを解放させるような処理は発生せず、図１０において後述するような内部状態の遷移のみが行われる。
【００８０】
第１の実施の形態は２台のＢＡＳを設置する場合を示しているが、３台以上のＢＡＳを設置する場合においても、クライアント端末（ＰＣ１０１）からのＰＡＤＩメッセージに対して複数のＢＡＳがサーバ間通信情報９００を格納したＰＡＤＯメッセージによって応答するので、各ＢＡＳは、他のＢＡＳが送信したＰＡＤＯメッセージを観測することによって、他の全てのＢＡＳの情報を収集することができる。
【００８１】
また、第１の実施の形態においては、サーバ間通信情報９００はＰＡＤＯメッセージ中のAC-Cookie TAGに格納される。これは、クライアント端末がAC-Cookie TAGを改変することなくそのままＰＡＤＲメッセージで返送しなければならないというＲＦＣ２５１６の規定を利用して、ＰＡＤＯ送信サーバタイムスタンプ９０３をＰＡＤＲメッセージ中に含ませるためである。AC-Cookie TAGは本来、TAG Valueフィールド５３０にクライアント端末のＭＡＣアドレスから生成された値を格納するように規定されているが、詳細は規定されておらず、またクライアント端末はその中身を関知しないので、サーバ間通信情報を格納するのにAC-Cookie TAGを利用すると都合がよい。
【００８２】
例えば、ＢＡＳ１３２のサーバ間通信情報設定手段８１１がＰＡＤＯメッセージ８０３のAC-Cookie TAGに設定したサーバ間通信情報９００は、ＢＡＳ１３３のサーバ間通信情報抽出手段８４２や８５１によって抽出される。すなわち、これらの情報は、サーバ間通信情報９００設定するＢＡＳとは異なるＢＡＳによって抽出されるので、サーバ間通信情報９００が格納されるAC-Cookie TAGのTAG Valueフィールド５３０には、各ＢＡＳで共通のフォーマットが用いられる。図８に示した複数の情報を格納するためには、例えば、図５に示したＴＡＧの形式のように、TAG Typeフィールド、TAG Lengthフィールド、TAG Valueフィールドを持つＴＬＶ形式を用いることができる。
【００８３】
また、サーバ間通信情報９００はクライアント端末に開示する必要のない情報である。悪意のあるクライアント端末がサーバ間通信情報９００を解読することを防ぐために、各ＢＡＳに共通の暗号化／復号化手段を設けることができる。すなわち、各ＢＡＳは暗号化／復号化のための共通のキーを持つ。例えば、前記ＰＡＤＯメッセージ８０３においては、ＢＡＳ１３２のサーバ間通信情報設定手段８１１がＴＬＶ形式のサーバ間通信情報９００を共通の暗号キーで暗号化して、AC-Cookie TAGのTAG Valueフィールド５３０に設定する。ＢＡＳ１３３のサーバ間通信情報抽出手段８４２や８５１は、前記ＰＡＤＯメッセージ８０３中のAC-Cookie TAGのTAG Valueフィールド５３０を前記共通キーで復号化することによって、ＴＬＶ形式のサーバ間通信情報９００を抽出することができる。
【００８４】
また、サーバ間通信情報９００のうち、ＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２とは、ＰＡＤＯメッセージを送信したＢＡＳとは別のＢＡＳが前記ＰＡＤＯメッセージを観測することによって抽出するものであって、ＰＡＤＲメッセージには含まれていなくて構わない。例えば、TAG Typeフィールド５１０にＲＦＣ２５１６で規定されていない独自のＴＡＧを定義して、該ＴＡＧにＰＡＤＯ送信サーバＭＡＣアドレス９０１とＰＡＤＯ送信サーバ負荷情報９０２を格納するように構成することもできる。ＲＦＣ２５１６によれば不明なＴＡＧは単に無視しなければならないので、新しく定義されたＴＡＧを用いることによってクライアント端末側に悪影響を及ぼすことはない。
【００８５】
ＲＦＣ２５１６には規定されていないが、AC-Cookie TAGと同様に、Service-Name TAGやAC-Name TAGもＰＡＤＯメッセージに含まれるものをそのままＰＡＤＲメッセージで返送するように構成されているクライアント端末もある。そのようなクライアント端末における実施の形態としては、サーバ間通信情報をService-Name TAGやAC-Name TAGに格納するように構成することもできる。
【００８６】
図１０は、前述した第１の実施の形態（図７）に示したシーケンスにおいて、ＢＡＳ１３３のＰＰＰｏＥシーケンス処理部６４１で実行される処理を示すフローチャートである。なお、ＢＡＳ１３２においても同様の手順の処理が実行される。
【００８７】
ＰＰＰｏＥシーケンス処理部６４１には、スタンバイ状態１１１０とサイクル起動状態１１２０とがある。
【００８８】
スタンバイ状態１１１０において、ＰＣ１０１からのＰＡＤＩメッセージ８０１を受信すると、ＰＡＤＩ受信７２１から始まる一連のＰＡＤＩ処理手順（具体的には図７で説明したＰＡＤＩ受信７２１→サーバ間通信情報設定８２１→Source MAC Address設定８２２→サーバ情報テーブル更新８２３→ＰＡＤＯ送信７２３からなる処理）が実行され、サイクル起動状態１１２０へと遷移する。
【００８９】
また、スタンバイ状態１１１０において、別のＢＡＳからのＰＡＤＯメッセージ１１３１が観測された場合、サイクル起動状態１１２０において観測された場合と同様に、ＰＡＤＯ観測１１４１から始まる一連のＰＡＤＯ処理手順（具体的には図７で説明したＰＡＤＯ観測８４１→サーバ情報抽出８４２→サーバ情報テーブル更新８４３と同様の処理）が実行される。このときの状態はスタンバイ状態１１１０が維持される。これは後述するように、ＰＡＤＯメッセージを、ＰＡＤＩメッセージに対して応答する場合以外にもＢＡＳ同士で負荷情報の交換を行うことを目的として送信するという実施の形態の変形例を可能とする。
【００９０】
また、スタンバイ状態１１１０において、クライアント端末からのＰＡＤＲメッセージ１１３２を受信した場合、ＰＰＰｏＥシーケンス処理部６４１は何も実行せず、受信したＰＡＤＲメッセージ１１３２はＰＡＤＲ廃棄処理１１５１によって廃棄される。このときの状態はスタンバイ状態１１１０が維持される。これは、サイクル起動状態１１２０の間に受信されなかったＰＡＤＲメッセージが、後に受信されたとしても、遅れて受信されたＰＡＤＲメッセージは時間的有効性が失われるためである。また、クライアント端末がＰＡＤＩメッセージを送信してＰＡＤＯメッセージを受信するという手順を踏まずに、いきなりＰＡＤＲメッセージを送信して接続要求を行うことを防止するためである。
【００９１】
一方、サイクル起動状態１１２０において、別のＢＡＳが送信したＰＡＤＳメッセージ１１３３が観測された場合、又は、サイクル起動状態１１２０に遷移してから一定時間を経過してタイムアウトした場合、ＰＰＰｏＥシーケンス処理部６４１はスタンバイ状態１１１０へと遷移する。
【００９２】
また、サイクル起動状態１１２０においてＰＣ１０１からのＰＡＤＲメッセージ８０４を受信すると、ＰＡＤＲ受信手段７４１から始まる一連のＰＡＤＲ処理手順（具体的には図７で説明したＰＡＤＲ受信７４１→サーバ間通信情報抽出８５１→タイムアウト確認８５２→セッションＩＤ生成７４２→セッション管理テーブル割り当て８５３→ＰＡＤＳ送信７４４からなる処理）が実行されてＰＣ１０１との間でセッションを確立して、ＰＰＰｏＥシーケンス処理部６４１はスタンバイ状態１１１０へと遷移する。
【００９３】
また、サイクル起動状態１１２０において、ＢＡＳ１３２からのＰＡＤＯメッセージ８０３が観測されると、ＰＡＤＯ観測手段によるＰＡＤＯ観測８４１から始まる一連のＰＡＤＯ処理手順（具体的には図７で説明したＰＡＤＯ観測８４１→サーバ情報抽出８４２→サーバ情報テーブル更新８４３からなる処理）が実行される。この一連のＰＡＤＯ処理手順の実行中はサイクル起動状態１０２０が維持される。
【００９４】
また、サイクル起動状態１１２０において、クライアント端末からのＰＡＤＩメッセージ１１３４を受信した場合、ＰＰＰｏＥシーケンス処理部６４１は何も実行せず、受信したＰＡＤＩメッセージ１１３４はＰＡＤＩ廃棄処理１１７１によって廃棄される。このときの状態はサイクル起動状態１１２０が維持される。これは、悪意のあるクライアント端末からＰＡＤＩメッセージが連続して送信された場合に、手順８２１〜８２３、７２３からなるＰＡＤＩ処理手順が起動されて、余計な処理負荷がかかるのを防止するためである。また、サイクルの多重起動を防止することによって、サーバ情報テーブル６４２の管理を容易にし、保持するサーバ情報に不整合が発生するのを防止するためである。
【００９５】
図７及び図１０に示した動作によれば、ＰＡＤＯメッセージを利用してＢＡＳ間で情報交換を行い、各サイクル毎に、互いの持つサーバ情報テーブル６４２を更新し合う。これによって、新たにＢＡＳを追加したり運用中のＢＡＳを停止した場合にも、それぞれのＢＡＳが自律的に新しい構成に適応することができる、柔軟な負荷分散システムを実現している。以下、ＢＡＳを追加、停止した場合の処理について説明する。
【００９６】
図１１は、ＢＡＳ１３２、１３３の２台のＢＡＳが運用されている状態において、３台目のＢＡＳ１２０１が新たに設置された場合のシーケンスを示す。図１１に示す実施の形態において、ＰＡＤＩ、ＰＡＤＯ、ＰＡＤＲメッセージのそれぞれを受信したときに各ＢＡＳでは図７に示した処理が行われる。図１１では、これらの処理をＰＡＤＩ処理、ＰＡＤＯ処理、ＰＡＤＲ処理というように簡略に記述している。なお、ＢＡＳ１２０１の運用開始１２５０の後に、ＰＣ１０１がＰＡＤＩメッセージ１２１１を送信することによって開始した最初のサイクルを、第ｎサイクルとする。
【００９７】
ＰＣ１０１がＰＡＤＩメッセージ１２１１を送信したＰＡＤＩメッセージ１２１１は各ＢＡＳによって受信され、各ＢＡＳでは各々ＰＡＤＩ処理手順１２３１、１２４１、１２５１が実行される。この時点ではＢＡＳ１３２、１３３のサーバ情報テーブル６４２（図９参照）にＢＡＳ１２０１のエントリは存在しないので、ＰＡＤＯメッセージ１２１３と１２１４のSource MAC Addressフィールド４１２にはＢＡＳ１３３のＭＡＣアドレス値が設定される。一方、ＢＡＳ１２０１のサーバ情報テーブル６４２にはＢＡＳ１３２、１３３のエントリが存在しないので、ＰＡＤＯメッセージ１２１２にはSource MAC Addressフィールド４１２にＢＡＳ１２０１自身のＭＡＣアドレス値が設定される。
【００９８】
ＰＣ１０１は３つのＰＡＤＯメッセージ１２１２、１２１３、１２１４を受信し、そのどれかに応答してＰＡＤＲメッセージ１２１５を送信するが、ＰＡＤＯメッセージ１２１３か１２１４に応答した場合にはＢＡＳ１３３との間でセッションが確立され、ＰＡＤＯメッセージ１２１２に応答した場合にはＢＡＳ１２０１との間でセッションが確立される。図１１では、ＰＣ１０１がＢＡＳ１３３を選択してＰＡＤＲを返送し、ＢＡＳ１３３がＰＡＤＳを送信して、ＢＡＳ１３３との間でセッションが確立するシーケンスを示している。
【００９９】
各ＢＡＳは、ＰＡＤＯ処理手順１２３２、１２４２、１２５２によって、他のＢＡＳが送信したＰＡＤＯメッセージを観測し、サーバ情報テーブルを更新するので、第ｎサイクルが完了した時点で、各ＢＡＳの持つサーバ情報管理テーブルには自分自身を含めて３台のＢＡＳ１３２、１３３、１２０１の情報が登録されている。従って、次回のＰＡＤＩメッセージ１２２１を受信することによって開始される第ｎ＋１サイクルにおいては、ＰＣ１０１からの接続要求はＰＡＤＩ処理手順１２６１、１２７１、１２８１によって負荷情報が最小のＢＡＳに振り分けられるので、３台のＢＡＳの間での負荷分散が正しく行われる。
【０１００】
図１２は、ＢＡＳ１３２、１３３の２台で運用されている状態において、保守運用上の理由や装置故障のためにＢＡＳ１３３が停止した場合のシーケンスを示す。図１２において、ＢＡＳ１３３の運用停止１３３０の後に、ＰＣ１０１がＰＡＤＩメッセージ１３１１を送信することによって開始した最初のサイクルを、第ｎサイクルとする。
【０１０１】
ＢＡＳ１３２はＰＡＤＩメッセージ１３１１を受信するが、サーバ情報テーブル６４２（図９参照）にはＢＡＳ１３３のエントリ１０２０が存在するので、ＢＡＳ１３２はSource MAC Addressフィールド４１２にＢＡＳ１３３のＭＡＣアドレス値を設定したＰＡＤＯメッセージ１３１２で応答する。そして、ＰＡＤＩ受信とＰＡＤＯ送信の間に実行されるＰＡＤＩ処理手順１３４１中のサーバ情報更新手段によって、ＢＡＳ１３３のエントリが削除される。
【０１０２】
ＢＡＳ１３３は停止しているので、ＰＣ１０１に対しては、ＢＡＳ１３２から一つのＰＡＤＯメッセージ１３１２のみが送信される。
【０１０３】
ＰＡＤＯメッセージ１３１２を受信したＰＣ１０１は、Destination MAC Addressフィールド４１１にＢＡＳ１３３のＭＡＣアドレス値が設定されたＰＡＤＲメッセージ１３１３によって応答する。しかし前記ＰＡＤＲメッセージ１３１３は、停止しているＢＡＳ１３３によって受信されることはないので、第ｎサイクルにおいてＰＣ１０１はＰＡＤＳメッセージを受信することができず、セッション確立は失敗する。
【０１０４】
ＲＦＣ２５１６には、ＰＡＤＳメッセージを受信できなかったクライアント端末は、何度かＰＡＤＲメッセージを再送し、それでもＰＡＤＳメッセージを受信できなかった場合にはＰＡＤＩメッセージの送信からやり直すことが規定されている。ＰＣ１０１はこの規定に従い、ＰＡＤＲリトライ手段１３５１によって、ＰＡＤＲメッセージを再送し、それでもＰＡＤＳメッセージを受信できないのでＰＡＤＩリトライ手段１３５２によってＰＡＤＩメッセージ１３２１を再送する。ＰＡＤＩメッセージ１３２１はＢＡＳ１３２に受信されて第ｎ＋１サイクルが開始されるが、既にＢＡＳ１３２のサーバ情報テーブル６４２からはＢＡＳ１３３のエントリ１０２０が削除されている。これは、第ｎサイクルにおいて、ＢＡＳ１３３が停止しているためＢＡＳ１３２はＰＡＤＯメッセージを観測してＢＡＳ１３３の情報を得ることができずに、サーバ情報テーブル６４２のＢＡＳ１３３のエントリ１０２０はＰＡＤＩ処理手順１３４１中のサーバ情報更新手段によって削除されたままとなるためである。
【０１０５】
従って、第ｎ＋１サイクルにおいてＢＡＳ１３２が送信するＰＡＤＯメッセージ１３２２では、ＰＡＤＩ処理手順１３６１によってSource MAC Addressフィールド４１２にＢＡＳ１３２自身のＭＡＣアドレス値が指定される。ＰＡＤＯメッセージ１３２２を受信したＰＣ１０１は、Destination MAC Addressフィールド４１１にＢＡＳ１３２のＭＡＣアドレス値が設定されたＰＡＤＲメッセージ１３２３によって応答するので、ＢＡＳ１３２においてＰＡＤＲ処理手順１３６２によって受理されて、ＰＡＤＳメッセージ１３２４が送信されてセッションが確立する。
【０１０６】
このように、運用中のＢＡＳを停止させた際、たまたま停止させたＢＡＳの負荷が低く、接続要求の振り分け先となっていた場合には、セッション確立までに２回のサイクルが費やされることになる。しかし、ＰＣ１０１におけるＰＡＤＲリトライ手段１１５１やＰＡＤＩリトライ手段１１５２はＰＰＰｏＥクライアント機能を提供するソフトウェアによって自動的に実行され、ユーザにはセッション確立までに若干時間がかかったという程度にしか意識されないので、加入者を収容するというサービス自体に問題を及ぼすことなく、システム全体として継続的に運用することができる。
【０１０７】
以上のように、第１の実施の形態では、運用中にシステムの構成が変化した場合でも自律的に適応することができ、柔軟な負荷分散システムを実現している。これは、ＰＡＤＯメッセージを利用してＢＡＳ間でその都度情報交換を行うことにより、システム構成の変化が直ちに各ＢＡＳのサーバ情報テーブル６４２に反映されるからである。また、第１の実施の形態によれば、各ＢＡＳに互いのＢＡＳの情報をあらかじめ登録しておく必要がなく、各ＢＡＳを協調動作させるための特定の管理装置なども必要ない。各ＢＡＳがそれぞれ対等に、自律的に動作した結果として、各ＢＡＳのサーバ情報テーブル６４２が等しい状態を維持することができる。
【０１０８】
以上説明した第１の実施の形態（図７〜図１２）では、Source MAC Address設定手段８１２や８２２によって設定されるSource MAC Addressフィールド４１２の値は、サーバ情報テーブル６４２を参照し、負荷情報１００２の最も小さいエントリのサーバＭＡＣアドレス１００１を選択することによって決定される。よって、この負荷情報１００２は前回のサイクルにおいて収集した情報であった。クライアント端末がＰＡＤＩメッセージを送信したことを契機として負荷情報を交換するという第１の実施の形態の受動的な動作では、前回のサイクルからの時間が開くことがあり、サーバ情報テーブル６４２の保持する負荷情報１００２と現在の負荷状態とのずれが大きくなる可能性がある。
【０１０９】
以下、サーバ情報テーブル６４２に保持される負荷情報１００２が古くなり、現在の負荷状態との齟齬が生じるのを防ぐための第１の実施の形態の変形例について説明する。この実施の形態では、前述した第１の実施の形態の基本的な動作に加えて、ＰＡＤＩメッセージに対して応答する場合以外にも、ＢＡＳ同士で負荷情報の交換を行うことを目的としてＰＡＤＯメッセージが送信される。負荷情報の交換を目的としたこのＰＡＤＯメッセージは、クライアント端末からのＰＡＤＩメッセージに応答するためのものではないので、クライアント端末の動作に悪影響を及ぼすことのないように、Destination MAC Addressフィールド４１１には、例えば、自分自身のＭＡＣアドレス値を設定する。前記ＰＡＤＯメッセージは通常のＰＡＤＯメッセージ８０２や８０３と同様に他のＢＡＳによって観測され、サーバ情報テーブル６４２が更新される。例えば、図１０のフローチャートに示したように、ＢＡＳ１３３がスタンバイ状態１１１０においてＰＡＤＯメッセージ１１３１を受信した場合にも、ＰＡＤＯ観測手段１１４１から始まる一連のＰＡＤＯ受信手順が実行される。負荷情報の交換を目的としたこのようなＰＡＤＯメッセージを送信するタイミングについては、定期的にＰＡＤＯメッセージを送信する方法や、自分自身の実際の負荷状態がサーバ情報テーブル６４２の保持する自分自身の負荷情報９０２から一定限度以上に変化したときにＰＡＤＯメッセージを送信する方法を挙げることができる。
【０１１０】
別の実施の形態の変形例では、あるＢＡＳが他のＢＡＳの情報を収集することを目的としてＰＡＤＩメッセージを送信し、他のＢＡＳにＰＡＤＯメッセージで応答させる。この実施の形態は、例えば、図１１のように、既に運用中のシステムにおいて新たなＢＡＳを後から追加し、そのＢＡＳを始動する際の処理として適用すれば効果的である。
【０１１１】
また別の実施の形態の変形例では、特定のＢＡＳの情報を更新したいＢＡＳが、Destination MAC Addressフィールド４１１に前記特定のＢＡＳのＭＡＣアドレス値を指定したＰＡＤＩメッセージを送信することによって、前記特定のＢＡＳのみにＰＡＤＯメッセージで応答させる。この実施の形態においては、サーバ情報テーブル６４２に、図９に示した情報に加えてＰＡＤＯ送信サーバタイムスタンプ９０３が登録される。このタイムスタンプが示す時刻から一定時間が経過した場合には、当該エントリの情報が古くなったと判断して対応するＢＡＳ宛にＰＡＤＩメッセージが送信される。
【０１１２】
負荷情報として用いる値が装置単位の値であるような実施の形態の変形例においては、負荷情報を管理するのにＡＴＭ ＶＣ（＝仮想ＬＡＮセグメント）毎に独立のサーバ情報テーブル６４２を用いるのではなく、サーバ情報テーブル６４２とは別に単一の負荷情報テーブルが用意される。そうすることにより、どのＡＴＭ ＶＣ上でＰＡＤＯメッセージを観測しても共通の負荷情報テーブルが更新されるので、ＶＣ毎に別々のサーバ情報テーブル６４２で管理するよりも負荷情報の更新頻度が高くなり、それだけ負荷情報が新しい状態に保たれる。また、サーバ情報テーブル６４２の管理に必要な情報が少なくなることによって、テーブルを保持するために必要なメモリの量を節約することができる。このような実施の形態としては、負荷情報として、例えば、当該ＢＡＳにおいて確立されているＰＰＰｏＥセッションの総数を用いるという例が挙げられる。
【０１１３】
同様に、負荷情報として用いる値がネットワークカード単位やインタフェース単位のように、装置を構成する特定の単位毎の値であるような実施の形態の変形例においては、その単位毎の負荷情報テーブルが用意される。
【０１１４】
負荷情報として用いる値がＡＴＭ ＶＣ（＝仮想ＬＡＮセグメント）毎の値であるような実施の形態の変形例においては、図１６に示した第１の実施の形態のように、負荷情報は個々のサーバ情報テーブル６４２毎に独立に管理される。
【０１１５】
以上、各ＢＡＳがクライアント端末との通信に用いるＭＡＣアドレスの値がそれぞれ異なる通常の場合における接続要求を振り分ける第１の実施の形態について説明した。以下に説明する第２の実施の形態では、各ＢＡＳがクライアント端末との通信に用いるＭＡＣアドレスをそれぞれ同一の値に設定した場合における接続要求を振り分けるように構成されている。
【０１１６】
図１３は、図１に示したネットワーク構成において、ＢＡＳ１３２とＢＡＳ１３３とのＭＡＣアドレスを同一とする場合における、ＰＣ１０１とのメッセージシーケンスと、ＰＰＰｏＥシーケンス処理部６４１における処理手順の一例（第２の実施の形態）について説明する。図１３には、ＢＡＳ１３２よりもＢＡＳ１３３の方が負荷が小さい状態で、ＰＣ１０１からのＰＡＤＩメッセージ１４０１を受信してから接続要求の振り分け先であるＢＡＳ１３３によってＰＰＰｏＥセッションが確立されるまでの１サイクルの間の処理を示す。なお、第１の実施の形態（図７）と同一の動作をするものには、同一の符号を付し、その詳細な説明は省略する。
【０１１７】
また、第２の実施の形態では、ＢＡＳ１３２、１３３においてＰＣ１０１との通信に用いるＭＡＣアドレスとして同一の値が設定されているので、ＰＣ１０１がＢＡＳ１３２、１３３のどちらに接続されても、ＰＣ１０１からは接続先が異なることを意識されない。この場合、ＢＡＳ同士が互いを識別するのにＭＡＣアドレスを利用することはできないので、ＭＡＣアドレスとは別に、各ＢＡＳをユニークに識別する（サーバ間において重複することのない）サーバ識別子を設ける。各ＢＡＳには初期状態において自分自身のサーバ識別子が記憶されている。
【０１１８】
ＰＣ１０１が送信したＰＡＤＩメッセージ１４０１に対して、ＢＡＳ１３２、１３３はそれぞれＰＡＤＯメッセージ８０３、８０２によって応答するが、第１の実施の形態（図７）と異なり、サーバ間通信情報設定手段８１１、８１２によって設定されるサーバ間通信情報１５００の含まれる情報が異なることと、Source MAC Address設定手段８１２と８２２が実行されないことである。
【０１１９】
ここで、サーバ間通信情報１５００について説明する。図１４に、サーバ間通信情報１５００を構成する情報の種類と、ＢＡＳ１３２、１３３がサーバ間通信情報１５００として設定する値を示す。
【０１２０】
第２の実施の形態（図１３）のメッセージシーケンスで用いられるサーバ間通信情報１５００には、ＰＡＤＲ宛先サーバ識別子１５０１、ＰＡＤＯ送信サーバ識別子１５０２、ＰＡＤＯ送信サーバ負荷情報９０２、ＰＡＤＯ送信サーバセッションＩＤリスト１５０３及びＰＡＤＯ送信サーバタイムスタンプ９０３が含まれている。これらの情報のうち、ＰＡＤＯ送信サーバ識別子１５０２、ＰＡＤＯ送信サーバ負荷情報９０２及びＰＡＤＯ送信サーバセッションＩＤリスト１５０３は、ＰＡＤＯ観測８３１、８４２で設定される。ＰＡＤＲ宛先サーバ識別子１５０１、及びＰＡＤＯ送信サーバタイムスタンプ９０３はＰＡＤＲ受信１４１１、７４１で設定される。そして、これらの収集された情報は、次回のサイクルにおいて、サーバ間通信情報として設定される（８１１、８１２）。
【０１２１】
ＰＡＤＲ宛先サーバ識別子１５０１は、クライアント端末がこのＰＡＤＯメッセージに応答した場合に、対応するＰＡＤＲメッセージを受信すべきサーバを表す識別子であり、具体的には、両ＢＡＳの負荷状況によって定められ、ＢＡＳ１３３の負荷の方が小さい場合には、ＢＡＳ１３２及びＢＡＳ１３３の何れのＢＡＳが送信したＰＡＤＯメッセージにもＢＡＳ１３３の識別子が設定されている。すなわち、第２の実施の形態では、ＰＡＤＲ宛先サーバ識別子１５０１には、負荷情報１００２（図１５参照）の最も小さいＢＡＳ１３３のサーバ識別子１６０１が指定され、第１の実施の形態（図７）においてSource MAC Address設定手段８１２と８２２によって接続要求の振り分け先となるＢＡＳを指定したのと同様の役割を果たす。
【０１２２】
ＰＡＤＯ送信サーバ識別子１５０２は、このＰＡＤＯメッセージを送信したサーバを表す識別子であり、具体的には、ＢＡＳ１３２が送信したＰＡＤＯメッセージにはＢＡＳ１３２の識別子が、ＢＡＳ１３３が送信したＰＡＤＯメッセージにはＢＡＳ１３３の識別子が設定されている。すなわち、ＰＡＤＯ送信サーバ識別子１５０２は、第１の実施の形態（図８）におけるＰＡＤＯ送信サーバＭＡＣアドレス９０１と同様の役割を果たす。
【０１２３】
ＰＡＤＯ送信サーバ負荷情報９０２は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージ受信時点における、このＰＡＤＯメッセージの送信元のサーバの負荷情報である。具体的には、当該ＢＡＳにおいて確立されているＰＰＰｏＥセッションの総数、当該ＢＡＳのプロセッサ使用率、パケット転送バッファの使用率等が用いられる。
【０１２４】
ＰＡＤＯ送信サーバセッションＩＤリスト１５０３は、このＰＡＤＯメッセージを送信したサーバの、対応するＰＡＤＩメッセージ受信時点における当該ＡＴＭ ＶＣ上で確立しているセッションのセッションＩＤのリストである。例えば、ＢＡＳ１３２では二つのセッションが確立しており、０ｘ１、０ｘ３が、ＢＡＳ１３３では一つのセッションが確立しており、０ｘ２が設定される。このＰＡＤＯ送信サーバセッションＩＤリスト１５０３は、後述するようにセッション確立時にユニークなセッションＩＤ値を生成するために利用される。
【０１２５】
ＰＡＤＯ送信サーバタイムスタンプ９０３は、このＰＡＤＯメッセージに対応するＰＡＤＩメッセージを、このＰＡＤＯメッセージの送信元のサーバが受信した時刻である。
【０１２６】
サーバ間通信情報１５００のＰＡＤＲ宛先サーバ識別子１５０１を決定する際に参照されるサーバ情報テーブル６４２は、図１５に示すような情報を保持している。
【０１２７】
サーバ情報テーブル６４２は各サーバ毎のエントリから構成され、第２の実施の形態の場合、ＢＡＳ１３２のエントリ１６１０とＢＡＳ１３３のエントリ１６２０が保持されている。各エントリは、当該サーバをユニークに識別するためのサーバ識別子１６０１、当該サーバの負荷情報１００２及び各サーバにおいて確立しているセッションのセッションＩＤのリストからなる。これらのサーバ情報テーブル６４２の情報は、第１の実施の形態（図７）と同様に、１つ前のサイクルにおいて各ＢＡＳの送信したＰＡＤＯメッセージを観測することによって収集された情報なので、ＢＡＳ１３２、１３３のいずれにおいても、図１５に示す同じ情報が保持されている。
【０１２８】
この第２の実施の形態でも、第１の実施の形態（図７）と同様に、ＰＡＤＯメッセージ１４０２や１４０３は、ＰＡＤＯ観測手段８３１、８４１によって観測される。サーバ間通信情報抽出手段８３２、８４２によって抽出されたサーバ間通信情報１５００のうち、ＰＡＤＯ送信サーバ識別子１５０２が、サーバ情報テーブル更新手段８３３、８４３によって、サーバ情報テーブル６４２にサーバ識別子１６０１として登録される。また、同様に、ＰＡＤＯ送信サーバ負荷情報９０２が負荷情報１００２として登録され、ＰＡＤＯ送信サーバセッションＩＤリスト１５０３がセッションＩＤリスト１６０２として登録される。
【０１２９】
ＰＣ１０１は２つのＰＡＤＯメッセージ１４０２と１４０３を受信するが、ＢＡＳ１３２、１３３のＭＡＣアドレスは同一であるので、２つのＰＡＤＯメッセージのどちらとも、Source MAC Addressフィールド４１２には同一のＭＡＣアドレスが設定されている。ＰＣ１０１が既存の接続先選択手段７３１によりどちらのＰＡＤＯメッセージに対してＰＡＤＲメッセージ１４０４で応答した場合でも、そのDestination MAC Addressフィールド４１１はＢＡＳ１３２、１３３に共通のＭＡＣアドレス値であるので、ＰＡＤＲ受信手段１４１１、７４１により、前記ＰＡＤＲメッセージ１４０４はＢＡＳ１３２、１３３の両方に受信される。ＢＡＳ１３２、１３３は、サーバ間通信情報抽出手段１４１２、８５１により、ＰＡＤＲメッセージ１４０４中に含まれるAC-Cookie TAGからサーバ間通信情報１５００を抽出する。そしてサーバ識別子比較手段１４１３や１４２１により、前記サーバ間通信情報１５００のうちのＰＡＤＲ宛先サーバ識別子１５０１を、自分自身のサーバ識別子と比較する。両者が一致すれば前記ＰＡＤＲメッセージ１４０４を自分宛だと判断して受理するが、一致しなければ自分宛ではないと判断して受理しない。
【０１３０】
前記ＰＡＤＲメッセージ１４０４が、ＰＡＤＯメッセージ１４０２と１４０３のどちらに応答したものであったとしても、その中に格納されているＰＡＤＲ宛先サーバ識別子１５０１はＢＡＳ１３３を示しているので、ＢＡＳ１３２のサーバ識別子比較手段１４１３は前記ＰＡＤＲメッセージ１４０４を受理せず、ＰＡＤＲ廃棄手段１４１４によって廃棄する。ＢＡＳ１３３は、サーバ識別子比較手段１４２１によって前記ＰＡＤＲメッセージ１４０４を受理し、第１の実施の形態（図７）と同様にタイムアウト判定手段８５２によって、ＰＡＤＯ送信サーバタイムスタンプ９０３とＰＡＤＲメッセージ１４０４を受信した時刻までの経過時間がある一定値より小さい場合には、タイムアウトしていないと判断し、ＢＡＳ１３３はセッションＩＤ生成手段１４２２によってユニークなセッションＩＤ値を生成する。
【０１３１】
セッションＩＤ生成手段１４２２では、サーバ情報テーブル６４２のセッションＩＤリスト１６０２が参照され、既に確立されているセッションのセッションＩＤ値と重複しないような値が生成される。そうすることによって、ＢＡＳ１３２とＢＡＳ１３３のＭＡＣアドレスが同一であるという条件の下で、図３に示した仮想ＬＡＮセグメント上の各々のセッションが、セッションＩＤによってユニークに識別できる。
【０１３２】
なお、図３に示すように、ＡＴＭ ＶＣによる仮想ＬＡＮセグメントは各ＤＳＬモデム毎（＝加入者毎）に別々に構築されるので、１つの仮想ＬＡＮセグメント上に多重されるセッション数はそれほど多くはなく、サーバ間通信情報設定手段によりＰＡＤＯメッセージ中に格納されるＰＡＤＯ送信サーバセッションＩＤリスト１５０３がそれほど大きくなる心配はない。
【０１３３】
１つの仮想ＬＡＮセグメントは１人の加入者に対応するので、サーバ情報テーブル６４２のセッションＩＤリスト１６０２を参照すれば、その加入者が確立中のセッションの総数を知ることができる。そのため、セッションＩＤリスト１６０２は、ユニークなセッションＩＤを生成するためだけでなく、加入者毎に（ＢＡＳ１３２、１３３を区別せずに）同時に確立することのできる最大セッション数を制限するという目的にも利用することができる。典型的なＡＤＳＬ加入者収容サービスでは、最大セッション数は１個または数個である。
【０１３４】
第２の実施の形態において、ＰＣ１０１とＢＡＳ１３３との間でＰＰＰｏＥセッションが確立された後にＰＣ１０１から送信されるセッションステージパケットのDestinatioin MAC Addressフィールド４１１は、ＢＡＳ１３２、１３３に共通のＭＡＣアドレスである。従って、ＢＡＳ１３３が前記セッションステージパケットが自分宛であるかどうかを識別するためには、ＰＰＰｏＥヘッダ４２０中のセッションＩＤフィールド４２２まで参照する必要がある。従来は、ＰＨＹ処理部６２０においてDestinatioin MAC Addressフィールド４１１を識別し、ＰＰＰｏＥ処理部６４０においてセッションＩＤフィールド４２２を識別するという方法が一般的である。その場合、ＢＡＳ１３２宛のセッションステージパケットは、ＰＨＹ処理部６２０では自分宛でないことが識別されずにＰＰＰｏＥ処理部６４０まで転送され、そこで初めて自分宛でないことが識別されて廃棄される。しかし、装置の処理性能を向上させる観点からは、余計なパケットは装置の内部まで転送することなく、なるべく装置の入り口部分で廃棄するのが望ましい。そのための図６とは別の装置構成の例として、セッション管理テーブル６４３をＰＨＹ処理部６２０に持たせることによって、ＰＨＹ処理部６２０がDestinatioin MAC Addressフィールド４１１とセッションＩＤフィールド４２２の両方を識別して自分宛のパケットかどうかを判定するという構成とすることもできる。
【０１３５】
また、中継装置１３１には、例えば、従来技術に基づくレイヤ２スイッチを用いることができる。但し、以上説明した実施の形態（図７、図１３）においては、ＰＡＤＯメッセージを利用してＢＡＳ間で情報交換を行うので、あるＢＡＳがクライアント宛に送信したＰＡＤＯメッセージが、物理的に他のＢＡＳに到達しなければならない。従来技術に基づくレイヤ２スイッチは、受信したパケットのSource MAC Addressフィールド４１２の値を回線毎に登録管理するＭＡＣアドレステーブルを備え、どの回線にどのＭＡＣアドレスを持った装置が接続されているかを学習する機能を備えている。そしてパケットを転送する際にはDestinatioin MAC Addressフィールド４１１をキーとして前記ＭＡＣアドレステーブルを検索し、宛先となる装置が接続されている回線のみにパケットを転送する機能を備えている。このＭＡＣアドレス学習機能が機能していると、あるＢＡＳがクライアント宛に送信したＰＡＤＯメッセージが、クライアント端末へ向かう回線のみに転送され、物理的に他のＢＡＳに到達しなくなるので、第１又は第２の実施の形態（図７、図１３）においては、中継装置１３１として従来技術に基づくレイヤ２スイッチを利用する場合には前記ＭＡＣアドレス学習機能を停止した状態で利用する必要がある。
【０１３６】
なお、従来技術に基づくレイヤ２スイッチにおける前記ＭＡＣアドレス学習機能は、パケットを宛先の回線以外には転送しないことによって、回線の帯域を無駄に消費することを防止することが目的である。この従来技術と同様の目的を実現するために、中継装置１３１に次のような機能を設ける実施の形態の変形例を挙げることができる。
【０１３７】
各ＢＡＳのＭＡＣアドレスが異なる通常の場合に適用される第１の実施の形態（図７）では、中継装置１３１は前述したようなＭＡＣアドレス学習機能を備えるが、受信したパケットのEther Typeフィールド４１３の値がＰＰＰｏＥディスカバリーステージパケットであることを表す０ｘ８８６３であった場合には、前記ＭＡＣアドレス学習機能によらずにこのパケットを全ての回線にブロードキャスト（送信）する。このことによって、第１の実施の形態（図７）における、ＰＡＤＯメッセージを観測することによって実現されるＢＡＳ間の情報交換を阻害することがなくなる。また、セッション確立後のセッションステージパケットは前記ＭＡＣアドレス学習機能によってDestinatioin MAC Addressフィールド４１１に基づいて宛先の回線のみに転送することによって、回線の帯域を無駄に消費することを防止することができる。
【０１３８】
各ＢＡＳのＭＡＣアドレスが同一である場合において適用される第２の実施の形態（図１３）では、中継装置１３１はSource MAC Addressフィールド４１２とセッションＩＤフィールド４２２とを対にして学習する機能を備える。セッションＩＤフィールド４２２が０ｘ０であれば、ＰＰＰｏＥディスカバリーステージパケットであるので、全ての回線にブロードキャストする。セッションＩＤフィールド４２２が０ｘ０以外の値であった場合には、Source MAC Addressフィールド４１２とセッションＩＤフィールド４２２の対に基づいて、宛先となるの装置が接続されている回線を特定し、その回線のみに転送することによって、回線の帯域を無駄に消費することを防止することができる。
【０１３９】
特許請求の範囲に記載した以外の本発明の観点の代表的なものとして、次のものがあげられる。
【０１４０】
（１）前記サーバは、
自サーバが確立中のセッションのセッションＩＤのリストを接続提供信号に設定するセッションＩＤリスト設定手段と、
他のサーバが送信した接続提供信号を観測する信号観測手段と、
前記観測された接続提供信号に設定された前記セッションＩＤのリストを抽出するセッションＩＤリスト抽出手段と、
接続要求信号を受信して新たなセッションを確立する際に、前記抽出したセッションＩＤ値と重複しないセッションＩＤ値を割り当てるセッションＩＤ割当手段と、を有することを特徴とする請求項１又は２に記載のネットワークシステム。
【０１４１】
（２）前記サーバは、抽出した前記サーバ識別情報と前記負荷情報とを記憶する記憶手段を有し、
前記サーバが、前記クライアント端末からの接接続開始信号対して接続提供信号によって応答して、互いに前記記憶手段に記憶された負荷情報を更新することを特徴とする請求項３に記載のネットワークシステム。
【０１４２】
（３）前記サーバは、
前記クライアント端末以外の装置からの接続開始信号を受信すると、他のサーバが記憶する負荷情報を更新させるための接続提供信号を送信する接続提供信号送信手段と、
自サーバが記憶する他のサーバの負荷情報を更新するために接続開始信号を送信する接続開始信号送信手段との少なくとも一方の手段を備えることを特徴とする請求項３に記載のネットワークシステム。
【０１４３】
（４）前記サーバは、
前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号の受信時刻を表す受信時刻情報を接続提供信号に設定する時刻情報設定手段と、
前記接続要求信号を受信すると、前記接続要求信号に含まれる前記受信時刻情報を抽出する受信時刻情報抽出手段とを有し、
前記クライアント端末は、前記受信した接続提供信号に含まれる前記受信時刻情報をそのまま接続要求信号に設定して返送する信号返送手段を有し、
前記サーバは、前記接続要求信号の受信時刻と前記受信時刻情報が表す時刻との比較結果に基づいて（例えば、前記接続要求信号の受信時刻が前記受信時刻情報が表す時刻から所定の一定時間以上経過していた場合には）、前記接続要求信号が有効か無効かを判定する判定手段を有することを特徴とする請求項４に記載のネットワークシステム。
【０１４４】
（５）前記サーバは、
各サーバに共通する暗号化手段及び復号化手段を有し、
前記暗号化手段によって暗号化した情報を接続提供信号に設定し、
接続提供信号又は前記接続提供信号に対応して返送された接続要求信号から前記暗号化された情報を抽出し、前記復号化手段によって抽出した暗号化された情報を復号化することを特徴とする請求項４に記載のネットワークシステム。
【０１４５】
（６）前記ＰＰＰｏＥサーバは、
前記ＰＰＰｏＥクライアント端末以外の装置からのＰＡＤＩメッセージを受信すると、ＰＰＰｏＥサーバが記憶する負荷情報を更新させるためのＰＡＤＯメッセージを送信するＰＡＤＯメッセージ送信手段と、
自サーバが記憶する他のＰＰＰｏＥサーバの負荷情報を更新するためにＰＡＤＩメッセージを送信するＰＡＤＩメッセージ送信手段との少なくとも一方の手段を備えることを特徴とする請求項５又は６に記載のネットワークシステム。
【０１４６】
（７）抽出した前記サーバ識別情報（例えば、ＭＡＣアドレス、サーバ識別子）と前記負荷情報とを記憶する記憶手段を有し、
前記クライアント端末からの接続開始信号に対して接続提供信号によって応答して、互いに前記記憶手段に記憶された負荷情報を更新することを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【０１４７】
（８）前記クライアント端末以外の装置からの接続開始信号を受信すると、他のサーバ装置が記憶する負荷情報を更新させるための接続提供信号を送信する接続提供信号送信手段と、
自サーバ装置が記憶する他のサーバ装置の負荷情報を更新するために接続開始信号を送信する接続開始信号送信手段との少なくとも一方の手段を備えることを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【０１４８】
（９）前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号の受信時刻を表す受信時刻情報を接続提供信号に設定する時刻情報設定手段と、
前記接続要求信号を受信すると、前記接続要求信号に含まれる前記受信時刻情報を抽出する時刻情報抽出手段とを有し、
前記接続要求信号の受信時刻と前記受信時刻情報が表す時刻との比較結果に基づいて（例えば、前記接続要求信号の受信時刻が前記受信時刻情報が表す時刻から所定の一定時間以上経過していた場合には）、前記接続要求信号が有効か無効かを判定する判定手段を有することを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【０１４９】
（１０）前記各サーバ装置に共通する暗号化手段及び復号化手段を有し、
前記暗号化手段によって暗号化した情報を接続提供信号に設定し、
接続提供信号又は前記接続提供信号に対応して返送された接続要求信号から前記暗号化された情報を抽出し、前記復号化手段によって抽出した暗号化された情報を復号化することを特徴とする請求項１５から２０のいずれか一つに記載のサーバ装置。
【図面の簡単な説明】
【図１】本発明の実施の形態のＤＳＬ網によって加入者を収容するネットワークの構成図である。
【図２】図１に示したネットワークにおけるプロトコルスタック図である。
【図３】図１に示したネットワークにおけるＡＴＭ ＶＣのトポロジを示す説明図である。
【図４】図１に示したネットワークにおけるＰＰＰｏＥパケットのフォーマット図である。
【図５】図１に示したネットワークにおけるＰＰＰｏＥディスカバリーステージパケットのペイロードに格納されるＴＡＧのフォーマット図である。
【図６】本発明の実施の形態のＢＡＳの構成図である。
【図７】第１の実施の形態のＰＰＰｏＥディスカバリーステージのシーケンス図である。
【図８】第１の実施の形態のサーバ間通信情報の構成の説明図である。
【図９】第１の実施の形態のサーバ情報テーブルの内容の説明図である。
【図１０】第１の実施の形態のＰＰＰｏＥシーケンス処理部の処理を示すフローチャートである。
【図１１】第１の実施の形態において、新たにＢＡＳが設置された場合のシーケンス図である。
【図１２】第１の実施の形態において運用中のＢＡＳが停止した場合のシーケンス図である。
【図１３】第２の実施の形態のＰＰＰｏＥディスカバリーステージのシーケンス図である。
【図１４】第２の実施の形態のサーバ間通信情報の構成の説明図である。
【図１５】第１の実施の形態のサーバ情報テーブルの内容の説明図である。
【図１６】従来のＰＰＰｏＥディスカバリーステージのシーケンス図である。
【符号の説明】
１０１ ＰＣ
１３１ 中継装置
１３２，１３３ ＢＡＳ
４１２ Source MAC Addressフィールド
４２２ セッションＩＤフィールド
６４１ ＰＰＰｏＥシーケンス処理部
６４２ サーバ情報テーブル
８１１，８２１ サーバ間通信情報設定手段
８１２，８２２ Source MAC Address設定手段
８１３，８２３，８３３，８４３ サーバ情報テーブル更新手段
８３１，８４１ ＰＡＤＯ観測手段
８３２，８４２，８５１ サーバ間通信情報抽出手段
８５２ タイムアウト判定手段
９０１ ＰＡＤＯ送信サーバＭＡＣアドレス
９０２ ＰＡＤＯ送信サーバ負荷情報
９０３ ＰＡＤＯ送信サーバタイムスタンプ
１４１３，１４２１ サーバ識別子比較手段
１４２２ セッションＩＤ生成手段
１５０１ ＰＡＤＲ宛先サーバ識別子
１５０２ ＰＡＤＯ送信サーバ識別子
１５０３ ＰＡＤＯ送信サーバセッションＩＤリスト
Claims (20)
- 少なくとも１つのクライアント端末と複数のサーバ装置との接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応した前記サーバ装置からの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するネットワークシステムにおいて、
前記サーバ装置は、前記クライアント端末からの接続開始信号を受信すると、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバ装置を決定し、前記決定されたサーバ装置を識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有することを特徴とするネットワークシステム。 - 前記クライアント端末は、前記受信した接続提供信号に含まれる前記サーバ識別情報をそのまま前記接続要求信号に設定して返送する信号返送手段を有し、
前記サーバ装置は、
前記受信した接続要求信号に含まれる前記サーバ識別情報を抽出する識別情報抽出手段と、
前記サーバ識別情報と自己のサーバ識別情報との比較結果に基づいて、前記接続要求信号を受理する信号受理手段と、を有することを特徴とする請求項１に記載のネットワークシステム。 - 前記サーバ装置は、
前記クライアント端末からの接続開始信号を受信すると、前記自サーバ装置のサーバ識別情報及び自サーバ装置の負荷情報を、前記接続提供信号に設定する負荷情報設定手段と、
他のサーバ装置から送信された接続提供信号を観測すると、前記接続提供信号に設定された前記サーバ識別情報及び前記負荷情報を抽出する負荷情報抽出手段と、
前記抽出した各サーバ装置の負荷情報に基づいて前記接続要求信号を受信すべきサーバ装置を決定するサーバ識別手段と、を有することを特徴とする請求項１又は２に記載のネットワークシステム。 - 前記ネットワークシステムは、少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバ装置とで構成されるＰＰＰｏＥネットワークシステムであって、
前記接続開始信号はＰＡＤＩメッセージであり、前記接続提供信号はＰＡＤＯメッセージであり、前記接続要求信号はＰＡＤＲメッセージであって、
前記各ＰＰＰｏＥサーバ装置の、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスをそれぞれ異ならせて設定し、
前記識別情報設定手段は、前記サーバ識別情報として、前記特定のＰＰＰｏＥサーバ装置のＭＡＣアドレスを前記ＰＡＤＯメッセージに設定することを特徴とする請求項１に記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、
前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信すると、前記自サーバ装置のＭＡＣアドレス及び自サーバ装置の負荷情報を、ＰＡＤＯメッセージに設定する負荷情報設定手段と、
他のサーバ装置から送信されたＰＡＤＯメッセージを観測すると、前記ＰＡＤＯメッセージに設定された前記ＭＡＣアドレス及び前記負荷情報を抽出する負荷情報抽出手段と、
前記抽出した各サーバ装置の負荷情報に基づいて前記ＰＡＤＲメッセージを受信すべきＰＰＰｏＥサーバ装置を決定するサーバ識別手段と、を有することを特徴とする請求項４に記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、抽出した前記ＭＡＣアドレスと前記負荷情報とを記憶する記憶手段を有し、
前記ＰＰＰｏＥサーバ装置が、前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージに対してＰＡＤＯメッセージによって応答して、互いに前記記憶手段に記憶された負荷情報を更新することを特徴とする請求項５に記載のネットワークシステム。 - 前記ネットワークシステムは、少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバ装置とで構成されるＰＰＰｏＥネットワークシステムであって、
前記接続開始信号はＰＡＤＩメッセージであり、前記接続提供信号はＰＡＤＯメッセージであり、前記接続要求信号はＰＡＤＲメッセージであって、
前記各ＰＰＰｏＥサーバ装置の、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスを同一に設定し、
前記識別情報設定手段は、前記サーバ識別情報として、前記ＭＡＣアドレスとは異なるＰＰＰｏＥサーバ装置間で重複することのないサーバ識別子を前記ＰＡＤＯメッセージに設定することを特徴とする請求項１に記載のネットワークシステム。 - 前記ＰＰＰｏＥクライアント端末は、前記受信したＰＡＤＯメッセージに含まれる前記サーバ識別子をそのまま前記ＰＡＤＲメッセージに設定して返送するメッセージ返送手段を有し、
前記ＰＰＰｏＥサーバ装置は、
前記受信したＰＡＤＲメッセージに含まれる前記サーバ識別子を抽出する識別子抽出手段と、
前記サーバ識別子と自己のサーバ識別子との比較結果に基づいて、前記サーバ識別子と自己のサーバ識別子とを比較して両者が一致した場合に、前記ＰＡＤＲメッセージを受理するメッセージ受理手段と、を有することを特徴とする請求項７に記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、自サーバ装置が確立中のＰＰＰｏＥセッションのセッションＩＤのリストをＰＡＤＯメッセージに設定するセッションＩＤリスト設定手段を有し、
他のＰＰＰｏＥサーバ装置が送信したＰＡＤＯメッセージを観測するメッセージ観測手段と、
前記観測されたＰＡＤＯメッセージに設定された前記セッションＩＤのリストを抽出するセッションＩＤリスト抽出手段と、
ＰＡＤＲメッセージを受信して新たなＰＰＰｏＥセッションを確立する際に、前記抽出したセッションＩＤ値と重複しないセッションＩＤ値を割り当てるセッションＩＤ割当手段と、を有することを特徴とする請求項４から８のいずれか一つに記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、
前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信すると、前記自サーバ装置のサーバ識別子及び自サーバ装置の負荷情報を、ＰＡＤＯメッセージに設定する負荷情報設定手段と、
他のサーバ装置から送信されたＰＡＤＯメッセージを観測すると、前記ＰＡＤＯメッセージに設定された前記サーバ識別子及び前記負荷情報を抽出する負荷情報抽出手段と、
前記抽出した各サーバ装置の負荷情報に基づいて前記ＰＡＤＲメッセージを受信すべきＰＰＰｏＥサーバ装置を決定するサーバ識別手段と、を有することを特徴とする請求項４から９のいずれか一つに記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、抽出した前記サーバ識別子と前記負荷情報とを記憶する記憶手段を有し、
前記ＰＰＰｏＥサーバ装置が、前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージに対してＰＡＤＯメッセージによって応答して、互いに前記記憶手段に記憶された負荷情報を更新することを特徴とする請求項１０に記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、
前記ＰＰＰｏＥクライアント端末以外の装置からのＰＡＤＩメッセージを受信すると、ＰＰＰｏＥサーバ装置が記憶する負荷情報を更新させるためのＰＡＤＯメッセージを送信するＰＡＤＯメッセージ送信手段と、
自サーバ装置が記憶する他のＰＰＰｏＥサーバ装置の負荷情報を更新するためにＰＡＤＩメッセージを送信するＰＡＤＩメッセージ送信手段との少なくとも一方の手段を備えることを特徴とする請求項１０又は１１に記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、
前記ＰＰＰｏＥクライアント端末からのＰＡＤＩメッセージを受信すると、前記ＰＡＤＩメッセージの受信時刻を表す受信時刻情報をＰＡＤＯメッセージに設定する時刻情報設定手段と、
前記ＰＡＤＲメッセージを受信すると、前記ＰＡＤＲメッセージに含まれる前記受信時刻情報を抽出する時刻情報抽出手段とを有し、
前記ＰＰＰｏＥクライアント端末は、前記受信したＰＡＤＯメッセージに含まれる前記受信時刻情報をそのままＰＡＤＲメッセージに設定して返送するメッセージ返送手段を有し、
前記ＰＰＰｏＥサーバ装置は、前記ＰＡＤＲメッセージの受信時刻と前記受信時刻情報が表す時刻との比較結果に基づいて、前記ＰＡＤＲメッセージが有効か無効かを判定する判定手段を有することを特徴とする請求項４から１２のいずれか一つに記載のネットワークシステム。 - 前記ＰＰＰｏＥサーバ装置は、暗号化手段及び復号化手段を有し、
前記暗号化手段によって暗号化した情報をＰＡＤＯメッセージに設定し、
ＰＡＤＯメッセージ又は前記ＰＡＤＯメッセージに対して返送されたＰＡＤＲメッセージから前記暗号化された情報を抽出し、前記復号化手段によって抽出した暗号化された情報を復号化することを特徴とする請求項４から１３のいずれか一つに記載のネットワークシステム。 - 少なくとも１つのクライアント端末との間の接続を、少なくとも前記クライアント端末からの接続開始信号と、前記接続開始信号に対応したサーバ装置からの接続提供信号と、前記接続提供信号に対応した前記クライアント端末からの接続要求信号とによって実現するサーバ装置において、
前記クライアント端末からの接続開始信号を受信した前記サーバ装置が、前記接続開始信号に対応する接続要求信号を受信すべき他のサーバ装置を決定し、前記決定されたサーバ装置を識別するサーバ識別情報を前記接続提供信号に設定する識別情報設定手段を有することを特徴とするサーバ装置。 - 前記クライアント端末が受信した接続提供信号に含まれる前記サーバ識別情報をそのまま設定して返送した接続要求信号を受信する接続要求信号受信手段と、
該受信した接続要求信号に含まれる前記サーバ識別情報を抽出する識別情報抽出手段と、
前記サーバ識別情報と自己のサーバ識別情報との比較結果に基づいて、前記サーバ識別情報と自己のサーバ識別情報とを比較して両者が一致した場合に、前記接続要求信号を受理する信号受理手段と、を有することを特徴とする請求項１５に記載のサーバ装置。 - 自サーバ装置が確立中のセッションのセッションＩＤのリストを接続提供信号に設定するセッションＩＤリスト設定手段と、
他のサーバ装置が送信した接続提供信号を観測する信号観測手段と、
前記観測された接続提供信号に設定された前記セッションＩＤのリストを抽出するセッションＩＤリスト抽出手段と、
接続要求信号を受信して新たなセッションを確立する際に、前記抽出したセッションＩＤ値と重複しないセッションＩＤ値を割り当てるセッションＩＤ割当手段と、を有することを特徴とする請求項１５又は１６に記載のサーバ装置。 - 前記クライアント端末からの接続開始信号を受信すると、前記自サーバ装置のサーバ識別情報及び自サーバ装置の負荷情報を、接続提供信号に設定する負荷情報設定手段と、
他のサーバ装置から送信された接続提供信号を観測すると、前記接続提供信号に設定された前記サーバ識別情報及び前記負荷情報を抽出する負荷情報抽出手段と、
前記抽出した各サーバ装置の負荷情報に基づいて前記接続要求信号を受信すべきサーバ装置を決定するサーバ識別手段と、を有することを特徴とする請求項１５から１７のいずれか一つに記載のサーバ装置。 - 少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバ装置とで構成されるＰＰＰｏＥネットワークシステムに用いられるＰＰＰｏＥサーバ装置であって、
前記接続開始信号はＰＡＤＩメッセージであり、前記接続提供信号はＰＡＤＯメッセージであり、前記接続要求信号はＰＡＤＲメッセージであって、
前記各ＰＰＰｏＥサーバ装置の、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスをそれぞれ異ならせて設定し、
前記識別情報設定手段は、前記サーバ識別情報として、前記特定のＰＰＰｏＥサーバ装置のＭＡＣアドレスを前記ＰＡＤＯメッセージに設定することを特徴とする請求項１５から１８のいずれか一つに記載のサーバ装置。 - 少なくとも１つのＰＰＰｏＥクライアント端末と、複数のＰＰＰｏＥサーバ装置とで構成されるＰＰＰｏＥネットワークシステムに用いられるＰＰＰｏＥサーバ装置であって、
前記接続開始信号はＰＡＤＩメッセージであり、前記接続提供信号はＰＡＤＯメッセージであり、前記接続要求信号はＰＡＤＲメッセージであって、
前記各ＰＰＰｏＥサーバ装置の、前記ＰＰＰｏＥクライアント端末との通信に用いるＭＡＣアドレスを同一に設定し、
前記識別情報設定手段は、前記サーバ識別情報として、前記ＭＡＣアドレスとは異なるＰＰＰｏＥサーバ装置間で重複することのないサーバ識別子を前記ＰＡＤＯメッセージに設定することを特徴とする請求項１５から１８のいずれか一つに記載のサーバ装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002055503A JP4080765B2 (ja) | 2002-03-01 | 2002-03-01 | ネットワークシステム |
| US10/219,290 US7512688B2 (en) | 2002-03-01 | 2002-08-16 | PPPoE network system that can distribute connection requests from PPPoE client terminals to specific PPPoE servers |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002055503A JP4080765B2 (ja) | 2002-03-01 | 2002-03-01 | ネットワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003258935A JP2003258935A (ja) | 2003-09-12 |
| JP4080765B2 true JP4080765B2 (ja) | 2008-04-23 |
Family
ID=28034807
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002055503A Expired - Fee Related JP4080765B2 (ja) | 2002-03-01 | 2002-03-01 | ネットワークシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7512688B2 (ja) |
| JP (1) | JP4080765B2 (ja) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3892375B2 (ja) * | 2002-09-11 | 2007-03-14 | 株式会社ウエルストーン | コンテンツサーバ、ＰＰＰｏＥ管理サーバまたはルータ |
| US20040105444A1 (en) * | 2002-11-15 | 2004-06-03 | Korotin Dmitry O. | Auto-configuration of broadband service for one of a plurality of network communication protocols |
| KR100542361B1 (ko) * | 2003-02-12 | 2006-01-10 | 삼성전자주식회사 | 피피피오이 네트워크 시스템 및 이 시스템의 접속 방법 |
| US7346062B2 (en) * | 2003-07-10 | 2008-03-18 | International Business Machines Corporation | Apparatus and method to coordinate calendar searches in a network scheduler given limited resources |
| US7085838B2 (en) * | 2003-08-04 | 2006-08-01 | Sbc Knowledge Ventures, Lp | Communications system for identifying remote digital subscriber line (DSL) customer premises equipment (CPE) devices during a discovery phase |
| US7165111B2 (en) * | 2003-08-04 | 2007-01-16 | Sbc Knowledge Ventures, L.P. | System and method to identify devices employing point-to-point-over Ethernet encapsulation |
| US7447780B2 (en) * | 2003-11-21 | 2008-11-04 | Time Warner Cable, Inc. | Technique for communicating information over a broadband communications network |
| CN101076978B (zh) * | 2004-01-16 | 2014-01-01 | 艾利森电话股份有限公司 | 一种用于在服务器间分配负载的方法 |
| CN1309233C (zh) * | 2004-07-20 | 2007-04-04 | 华为技术有限公司 | 在宽带接入设备上支持PPPoA的方法 |
| CN100518185C (zh) * | 2005-04-29 | 2009-07-22 | 华为技术有限公司 | Ppp接入终端获取运营商服务器地址的方法 |
| JP2006338338A (ja) * | 2005-06-02 | 2006-12-14 | Sanden Corp | 集中管理システムにおける被管理端末 |
| JP3920305B1 (ja) | 2005-12-12 | 2007-05-30 | 株式会社日立コミュニケーションテクノロジー | パケット転送装置 |
| EP1798901A1 (en) * | 2005-12-15 | 2007-06-20 | Alcatel Lucent | Access multiplexer |
| EP1798900A1 (en) * | 2005-12-15 | 2007-06-20 | Alcatel Lucent | Access multiplexer |
| JP4439476B2 (ja) | 2006-02-08 | 2010-03-24 | 株式会社東芝 | データ転送装置および携帯電話 |
| JP4791252B2 (ja) * | 2006-05-22 | 2011-10-12 | 株式会社日立製作所 | パケット転送装置、パケット転送システム、ユーザ端末装置およびパケット転送方法 |
| US8204074B2 (en) | 2006-06-07 | 2012-06-19 | Broadcom Corporation | Flexible MAC/PHY association |
| JP4680866B2 (ja) * | 2006-10-31 | 2011-05-11 | 株式会社日立製作所 | ゲートウェイ負荷分散機能を備えたパケット転送装置 |
| WO2008105030A1 (ja) * | 2007-02-28 | 2008-09-04 | Fujitsu Limited | バックアップ装置 |
| GB0709102D0 (en) * | 2007-05-11 | 2007-06-20 | Kitchener Renato | Power over broadband backbone for control and instrumentation |
| JP4621259B2 (ja) * | 2008-01-16 | 2011-01-26 | 株式会社日立製作所 | パケット転送制御方法 |
| JP4760963B2 (ja) * | 2009-06-26 | 2011-08-31 | 株式会社日立製作所 | ＩＰｖ６アドレス割り当て方法 |
| JP5321536B2 (ja) * | 2010-05-21 | 2013-10-23 | トヨタ自動車株式会社 | 遠隔制御装置、サービスセンタ |
| US20130230036A1 (en) * | 2012-03-05 | 2013-09-05 | Interdigital Patent Holdings, Inc. | Devices and methods for pre-association discovery in communication networks |
| JP6057345B2 (ja) * | 2014-02-07 | 2017-01-11 | 日本電信電話株式会社 | ユーザ端末収容装置およびその方法 |
| CN107454621A (zh) * | 2017-09-13 | 2017-12-08 | 凌云天博光电科技股份有限公司 | 一种局域网设备的管理系统 |
Family Cites Families (60)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5774668A (en) * | 1995-06-07 | 1998-06-30 | Microsoft Corporation | System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing |
| US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
| US5752003A (en) * | 1995-07-14 | 1998-05-12 | 3 Com Corporation | Architecture for managing traffic in a virtual LAN environment |
| US6711162B1 (en) * | 1995-09-08 | 2004-03-23 | 3Com Corporation | Method and apparatus for providing proxy service, route selection, and protocol conversion for service endpoints within data networks |
| US6047309A (en) * | 1995-10-02 | 2000-04-04 | International Business Machines Corporation | Recording observed and reported response characteristics at server and/or client nodes in a replicated data environment, and selecting a server to provide data based on the observed and/or reported response characteristics |
| US6038664A (en) * | 1996-06-10 | 2000-03-14 | Cubix Corporation | Method for selecting communication access method for local area networks |
| US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
| US6182139B1 (en) * | 1996-08-05 | 2001-01-30 | Resonate Inc. | Client-side resource-based load-balancing with delayed-resource-binding using TCP state migration to WWW server farm |
| US6366558B1 (en) * | 1997-05-02 | 2002-04-02 | Cisco Technology, Inc. | Method and apparatus for maintaining connection state between a connection manager and a failover device |
| US6128642A (en) * | 1997-07-22 | 2000-10-03 | At&T Corporation | Load balancing based on queue length, in a network of processor stations |
| US6006264A (en) * | 1997-08-01 | 1999-12-21 | Arrowpoint Communications, Inc. | Method and system for directing a flow between a client and a server |
| US6067545A (en) * | 1997-08-01 | 2000-05-23 | Hewlett-Packard Company | Resource rebalancing in networked computer systems |
| US6128279A (en) * | 1997-10-06 | 2000-10-03 | Web Balance, Inc. | System for balancing loads among network servers |
| US6148405A (en) * | 1997-11-10 | 2000-11-14 | Phone.Com, Inc. | Method and system for secure lightweight transactions in wireless data networks |
| US6266335B1 (en) * | 1997-12-19 | 2001-07-24 | Cyberiq Systems | Cross-platform server clustering using a network flow switch |
| US6185598B1 (en) * | 1998-02-10 | 2001-02-06 | Digital Island, Inc. | Optimized network resource location |
| US6912588B1 (en) * | 1998-04-02 | 2005-06-28 | Intel Corporation | System and method for managing client requests in client-server networks |
| US6112245A (en) * | 1998-04-07 | 2000-08-29 | 3Com Corporation | Session establishment for static links in Point-to-Point Protocol sessions |
| US6175869B1 (en) * | 1998-04-08 | 2001-01-16 | Lucent Technologies Inc. | Client-side techniques for web server allocation |
| US6078960A (en) * | 1998-07-03 | 2000-06-20 | Acceleration Software International Corporation | Client-side load-balancing in client server network |
| JP2000029813A (ja) | 1998-07-14 | 2000-01-28 | Hitachi Ltd | サーバ選択システム |
| US6327622B1 (en) * | 1998-09-03 | 2001-12-04 | Sun Microsystems, Inc. | Load balancing in a network environment |
| US6094437A (en) * | 1998-10-09 | 2000-07-25 | Asc - Advanced Switching Communications | Layer two tunneling protocol (L2TP) merging and management |
| JP2000155736A (ja) | 1998-11-24 | 2000-06-06 | Nec Corp | サービス要求の振り分け方法及びアドレス変換装置 |
| US6466976B1 (en) * | 1998-12-03 | 2002-10-15 | Nortel Networks Limited | System and method for providing desired service policies to subscribers accessing the internet |
| US6556541B1 (en) * | 1999-01-11 | 2003-04-29 | Hewlett-Packard Development Company, L.P. | MAC address learning and propagation in load balancing switch protocols |
| US6748416B2 (en) * | 1999-01-20 | 2004-06-08 | International Business Machines Corporation | Client-side method and apparatus for improving the availability and performance of network mediated services |
| JP2000244526A (ja) | 1999-02-23 | 2000-09-08 | Hitachi Ltd | 多重化したネットワーク接続装置システム |
| JP2000259539A (ja) | 1999-03-12 | 2000-09-22 | Hitachi Information Technology Co Ltd | トランザクション分配方法及び装置 |
| US6671259B1 (en) * | 1999-03-30 | 2003-12-30 | Fujitsu Limited | Method and system for wide area network load balancing |
| US6728961B1 (en) * | 1999-03-31 | 2004-04-27 | International Business Machines Corporation | Method and system for dynamically load balancing a process over a plurality of peer machines |
| US6317434B1 (en) * | 1999-04-14 | 2001-11-13 | Verizon Laboratories Inc. | Data link layer switch with multicast capability |
| EP1201060A2 (en) * | 1999-05-26 | 2002-05-02 | Bigband Networks, Inc. | Communication management system and method |
| US6704282B1 (en) * | 1999-06-30 | 2004-03-09 | 3Com Corporation | VPN tunnel redirection |
| JP2001053744A (ja) | 1999-08-06 | 2001-02-23 | Toshiba Corp | パラレル配信システム |
| US6772333B1 (en) * | 1999-09-01 | 2004-08-03 | Dickens Coal Llc | Atomic session-start operation combining clear-text and encrypted sessions to provide id visibility to middleware such as load-balancers |
| JP2001094558A (ja) | 1999-09-17 | 2001-04-06 | Ddi Corp | ネットワーク管理における負荷分散制御方法 |
| US6625152B1 (en) * | 1999-10-13 | 2003-09-23 | Cisco Technology, Inc. | Methods and apparatus for transferring data using a filter index |
| WO2001044894A2 (en) * | 1999-12-06 | 2001-06-21 | Warp Solutions, Inc. | System and method for dynamic content routing |
| US6389448B1 (en) * | 1999-12-06 | 2002-05-14 | Warp Solutions, Inc. | System and method for load balancing |
| US6891825B1 (en) * | 1999-12-22 | 2005-05-10 | Mci, Inc. | Method and system of providing multi-user access to a packet switched network |
| JP3417374B2 (ja) | 2000-02-04 | 2003-06-16 | 日本電気株式会社 | サーバ、クライアント、クライアントサーバシステム、負荷分散方法、記録媒体 |
| US6377975B1 (en) * | 2000-03-01 | 2002-04-23 | Interactive Intelligence, Inc. | Methods and systems to distribute client software tasks among a number of servers |
| US6718361B1 (en) * | 2000-04-07 | 2004-04-06 | Network Appliance Inc. | Method and apparatus for reliable and scalable distribution of data files in distributed networks |
| US6742044B1 (en) * | 2000-05-10 | 2004-05-25 | Cisco Technology, Inc. | Distributed network traffic load balancing technique implemented without gateway router |
| US7228358B1 (en) * | 2000-07-25 | 2007-06-05 | Verizon Services Corp. | Methods, apparatus and data structures for imposing a policy or policies on the selection of a line by a number of terminals in a network |
| US6904054B1 (en) * | 2000-08-10 | 2005-06-07 | Verizon Communications Inc. | Support for quality of service and vertical services in digital subscriber line domain |
| US7349994B2 (en) * | 2000-10-17 | 2008-03-25 | Avaya Technology Corp. | Method and apparatus for coordinating routing parameters via a back-channel communication medium |
| US7406539B2 (en) * | 2000-10-17 | 2008-07-29 | Avaya Technology Corp. | Method and apparatus for performance and cost optimization in an internetwork |
| US6950849B1 (en) * | 2000-11-01 | 2005-09-27 | Hob Gmbh & Co. Kg | Controlling load-balanced access by user computers to server computers in a computer network |
| US6763018B1 (en) * | 2000-11-30 | 2004-07-13 | 3Com Corporation | Distributed protocol processing and packet forwarding using tunneling protocols |
| US6917592B1 (en) * | 2001-01-22 | 2005-07-12 | 3Com Corporation | LNS high availability and load balancing with LNS-to-LNS state offloading |
| US6944678B2 (en) * | 2001-06-18 | 2005-09-13 | Transtech Networks Usa, Inc. | Content-aware application switch and methods thereof |
| US6996110B1 (en) * | 2001-08-31 | 2006-02-07 | 3Com Corporation | Distributed MPLS architecture |
| US7039916B2 (en) * | 2001-09-24 | 2006-05-02 | Intel Corporation | Data delivery system for adjusting assignment of connection requests to nodes based upon the tracked duration |
| US20030074467A1 (en) * | 2001-10-11 | 2003-04-17 | Oblak Sasha Peter | Load balancing system and method for data communication network |
| US7149224B1 (en) * | 2001-10-23 | 2006-12-12 | Cisco Technology, Inc. | Method of point-to-point protocol negotiation |
| US7295953B2 (en) * | 2001-12-21 | 2007-11-13 | International Business Machines Corporation | Scenario based testing and load generation for web applications |
| US7043253B2 (en) * | 2001-12-26 | 2006-05-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Load balancing in a mobile telecommunications network |
| US6956846B2 (en) * | 2002-08-16 | 2005-10-18 | Utstarcom Incorporated | System and method for foreign agent control node redundancy in a mobile internet protocol network |
-
2002
- 2002-03-01 JP JP2002055503A patent/JP4080765B2/ja not_active Expired - Fee Related
- 2002-08-16 US US10/219,290 patent/US7512688B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003258935A (ja) | 2003-09-12 |
| US20030182434A1 (en) | 2003-09-25 |
| US7512688B2 (en) | 2009-03-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4080765B2 (ja) | ネットワークシステム | |
| CN101026519B (zh) | 基于用户信息字符串动态创建vlan接口 | |
| JP3917290B2 (ja) | 収容局側終端装置におけるｓｖｃアクセス方式 | |
| US5894479A (en) | Providing address resolution information for self registration of clients on power-up or dial-in | |
| US7864773B2 (en) | Virtual circuit auto-configuration for customer premises equipment | |
| JP3920305B1 (ja) | パケット転送装置 | |
| TWI243559B (en) | Dynamic host configuration protocol spoofing in point-to-point protocol over ATM using ADSL modem | |
| EP1748603B1 (en) | A transmission method for message in layer 2 and an access device | |
| JP4431213B2 (ja) | 接続モードで動作するネットワークにおける接続識別子を再割り当てする再割り当て方法 | |
| JP2007221533A (ja) | Ｐｐｐゲートウェイ装置 | |
| US20090089431A1 (en) | System and method for managing resources in access network | |
| MXPA05012873A (es) | Metodo para intercambiar paquetes de datos de usuario. | |
| JP2010514290A (ja) | メディアアクセス制御アドレスを変換するためのネットワーク装置及び方法 | |
| JP3757863B2 (ja) | アクセスネットワーク装置 | |
| US20090190584A1 (en) | Method, communication arrangement and communication device for transferring information | |
| JP4621259B2 (ja) | パケット転送制御方法 | |
| US20050132061A1 (en) | Method for autoconfiguring CPEs in DSL networks | |
| JP4143663B2 (ja) | ネットワークシステム | |
| EP1981217A1 (en) | Method for forwarding data packets in an access network and device | |
| KR20010056740A (ko) | 다중 프로토콜을 지원하는 에이디에스엘 라우터 및 그라우터의 패킷 송수신 방법 | |
| KR100224318B1 (ko) | 공중망 비동기 전달 모드(atm) 교환시스템에서의랜(lan) 트래픽 처리 방법 | |
| KR100317990B1 (ko) | 랜 에뮬레이션 클라이언트 다중 엔터티 처리장치 및 방법 | |
| JP2003078548A (ja) | 加入者無線アクセスシステム | |
| KR100301021B1 (ko) | Ieee 1394와 atm간의 게이트웨이 관리 방법 및 그에 대한 게이트 웨이 | |
| KR20020051189A (ko) | 비동기 전송 모드 기반 엠피엘에스망에서 이더넷상의점대점 프로토콜 서비스 처리 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050228 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070306 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070424 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080205 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080207 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110215 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110215 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120215 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120215 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130215 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130215 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |