JP4401913B2 - パケット転送装置およびアクセスネットワークシステム - Google Patents

Description

本発明は、ユーザ端末からのインターネットアクセスを制御するパケット転送装置およびアクセスネットワークシステムに関する。

ユーザ端末がインターネットを利用する場合、各ユーザ端末は、インターネットへの接続の都度、ユーザが加入しているインターネット接続事業者（以下、ＩＳＰ：Internet Service Providerと言う）の加入者認証サーバと交信し、ＩＰ（Internet Protocol）アドレスの割り当てを受ける。ユーザ端末は、上記ＩＰアドレスを送信元アドレスに適用して、インターネット上の目的サーバとパケット通信する。各ユーザ端末は、ＩＳＰが管理するＩＳＰ網を介してインターネットに接続されているが、ＩＳＰ網とユーザ端末との間には、一般的に、キャリアによって提供されるアクセスネットワークと呼ばれる網が存在している。アクセスネットワークによるユーザ端末とＩＳＰ網との接続サービスは、キャリアとＩＳＰとの間の契約のもとで実施される。

上述したアクセスネットワークには、一般的に、アクセスサーバまたはＢＡＳ（Broadband Access Server）と呼ばれる複数のパケット転送装置（以下、アクセスサーバと言う）が設置されている。各アクセスサーバは、ＩＳＰに加入した複数のユーザ端末（加入者端末）を収容し、各ユーザ端末のインターネットへの接続と切断を制御している。また、これらのアクセスサーバは、例えば、東京地区の加入者端末用サーバ、名古屋地区の加入者端末用サーバ、大阪地区の加入者端末用サーバの如く、地域毎にインターネットへの接続サービスを提供している。

このようなネットワーク構成において、ユーザ端末へのＩＰアドレスの割り当て（ＩＰアドレス配布）には、例えば、特開２００３−０８７２９９号公報に示されているように、次の２つの方法がある。

第１のＩＰアドレスの割り当て方法は、ＩＳＰ網内に設置された加入者認証サーバ、例えば、Ｒａｄｉｕｓ（Remote Authentication Dial In User Service）サーバで、ユーザ端末に配布すべきＩＰアドレス群（以下、このアドレス群をアドレスプールと呼ぶ）を管理しておき、ユーザ端末からインターネット接続要求を受けたアクセスサーバが、ユーザ端末のインターネットへの接続可否を判断するために上記加入者認証サーバに認証要求メッセージ（Access-Request）を送信した時、加入者認証サーバが、上記認証要求に対する応答メッセージ(Access-Accept)で、ユーザ端末に割り当てるべきＩＰアドレスを指定するものである。この方法は、ＩＳＰの加入者認証サーバにおいて、アドレスプールに登録された各ＩＰアドレスがユーザ端末に割り当て済みか否かを管理する必要があり、ユーザ端末のインターネットへの接続／切断の都度、アドレスプールにおけるアドレス状態情報の更新処理が発生するため、加入者認証サーバの負荷が大きくなるという問題がある。

第２のＩＰアドレスの割り当て方法は、ＩＳＰが、ユーザ端末に対する実際のＩＰアドレスの割り当てとＩＰアドレスの状態管理をキャリア（アクセスサーバ）に委ねるものであり、ＩＳＰのアドレスプールに登録されたＩＰアドレスをアクセスサーバと対応した複数のアドレスグループに分割しておき、各アクセスサーバが、ＩＳＰから委託されたアドレスグループ（以下、サブアドレスプールと言う）の範囲内で、ユーザ端末へのＩＰアドレスの割り当てを行う。

Ｒａｄｉｕｓプロトコルによれば、例えば、ＲＦＣ２８６５の３３頁に記述されているように、Ｒａｄｉｕｓサーバが、認証要求に対する応答メッセージ(Access-Accept)で端末への割り当てＩＰアドレスを指定する際に、Framed-IP-Addressアトリビュートのアドレスフィールドに特定値「255.255.255.254」を設定することによって、アクセスサーバ（ＮＡＳ：Network Access Server）に対して、アクセスサーバが保持しているサブアドレスプールからユーザ端末へのＩＰアドレスの割り当てを指示できるようになっている。上記第２のＩＰアドレスの割り当て方法によれば、ユーザ認証に成功した端末に対するＩＰアドレスの配布とＩＰアドレス管理を複数のアクセスサーバに分散できるため、加入者認証サーバの負荷を軽減することが可能となる。

特開２００３-０８７２９９号公報 ＩＥＴＦ ＲＦＣ２８６５ ３３頁

然るに、上述した従来の第２のＩＰアドレスの割り当て方法によれば、ＩＳＰがアドレスプールに所有するＩＰアドレスが、複数のアドレスグループ（サブアドレスプール）に分割され、各アクセスサーバにアドレスグループ単位でＩＰアドレスの管理が委託されているため、特定のアクセスサーバに多数のユーザ端末からのインターネット接続要求が集中した時、ＩＳＰ全体としてはＩＰアドレスに余裕があるにも関わらず、上記特定アクセスサーバでＩＰアドレスが不足するという問題が発生する。

例えば、アクセスネットワークに、東京地区、名古屋地区、大阪地区の３つのアクセスサーバが存在し、ＩＳＰが、東京地区のアクセスサーバには「10.10.0.0」〜「10.10.0.255」の２５６個のＩＰアドレス、名古屋地区のアクセスサーバには「10.10.1.0」〜「10.10.1.255」の２５６個のＩＰアドレス、大阪地区のアクセスサーバには「10.10.2.0」〜「10.10.2.255」の２５６個のＩＰアドレスについて、ユーザ端末への割り当てと状態管理を委託した場合を想定する。

ここで、特定の時間帯で、東京地区では３００ユーザ、名古屋地区では１５０ユーザ、大阪地区では２００ユーザ、合計６５０ユーザからインターネットへの接続要求が発生したと仮定すると、ＩＳＰがキャリアに委託した配布ＩＰアドレスの総数が、上記接続要求の合計よりも多い７６８であるにも関わらず、東京地区のアクセスサーバで空きＩＰアドレスが不足し、一部のユーザに対してインターネット接続サービスを提供できなくなると言う事態が発生する。

従来技術においては、このようにＩＳＰが所有する限定個数のＩＰアドレスを効果的に運用することが難しく、特定のアクセスサーバでＩＰアドレスが不足する場合、キャリアとＩＳＰとの間で、上記アクセスサーバに割り当てるサブアドレスプールの範囲を変更するための手続きが必要となる。

本発明の目的は、ＩＳＰが所有するＩＰアドレス群を効果的に利用できるパケット転送装置およびアクセスネットワークシステムを提供することにある。

上記目的を達成するために、本発明では、アクセス網にサブアドレスプールを管理するアドレスプール管理サーバを配置し、アクセス網内の各アクセスサーバ（パケット転送装置）が、認証に成功したユーザ端末に割り当てるべきＩＰアドレスを上記アドレスプール管理サーバから取得するようにしたことを特徴とする。

更に詳述すると、加入者認証サーバを含むインターネットサービスプロバイダ（ＩＳＰ）網に接続されたアクセス網内に位置し、複数のユーザ端末を上記ＩＳＰ網を介してインターネット網に接続する本発明のパケット転送装置は、
ユーザ端末との接続回線または上記ＩＳＰ網との接続回線に接続される複数の回線インタフェースと、制御部と、上記各回線インタフェースおよび上記制御部に接続され、これらの要素間で受信パケットを交換するプロトコル処理部とからなり、
上記制御部が、ユーザ端末の識別子と割り当てＩＰアドレスとの関係を記憶するためのユーザアドレス管理テーブルと、インターネットへの接続を要求したユーザ端末について、上記加入者認証サーバとの間で認証手順を実行し、上記加入者認証サーバから、サブアドレスプールの適用指示を含む認証応答パケットを受信した時、上記アクセス網内に位置したアドレスプール管理サーバに上記ユーザ端末に割り当てるべきＩＰアドレスを要求し、該アドレスプール管理サーバから取得したＩＰアドレスを要求元ユーザ端末の識別子と対応させて上記ユーザアドレス管理テーブルに記憶するサーバ間通信制御手段と、上記ユーザ端末との間で、加入者認証のための通信手順を実行した後、該ユーザ端末から受信したＩＰアドレス要求パケットに応答して、上記ユーザアドレス管理テーブルが示す上記ユーザ端末識別子と対応するＩＰアドレスを通知する端末通信制御手段とを含むことを特徴とする。

本発明の１実施例では、上記サーバ間通信制御手段が、加入者認証サーバから受信する認証応答で指定されたサーバアドレスに従って、上記アドレスプール管理サーバに前記ユーザ端末に割り当てるべきＩＰアドレスを要求する。本発明の他の実施例では、上記制御部が、前記ＩＳＰ網の識別子とアドレスプール管理サーバのアドレスとの関係を示すサーバアドレステーブルを備えており、上記サーバ間通信制御手段が、ユーザ端末の識別子に含まれるＩＳＰ網識別子に基づいて上記サーバアドレステーブルを参照し、上記ＩＰアドレスの要求先となるアドレスプール管理サーバのアドレスを特定する。

本発明によるパケット転送装置の１つの特徴は、上記制御部が、上記ＩＳＰ網で使用可能な複数のＩＰアドレスをサブアドレスプールとして保持するためのアドレスプール管理テーブルを備え、上記加入者認証サーバから、サブアドレスプールの適用指示を含む認証応答を受信した時、上記アドレスプール管理テーブルから空き状態にあるＩＰアドレスを検索し、空きＩＰアドレスが見つかった場合は、該ＩＰアドレスを上記ユーザアドレス管理テーブルに記憶しておき、上記アドレスプール管理テーブルから空きＩＰアドレスが見つからなかった場合に、上記サーバ間通信制御手段によって、アドレスプール管理サーバからＩＰアドレスを取得することをようにした構成にある。

本発明のパケット転送装置は、上記制御部が、ユーザ端末からインターネット接続の切断要求パケットを受信した時、上記サーバ間通信制御手段によって、上記アドレスプール管理サーバに、上記ユーザ端末に割り当てられたＩＰアドレスを解放するための要求パケットを送信することを１つの特徴とする。

本発明のパケット転送装置は、上記プロトコル処理部が、インターネット網に接続されたユーザ端末の課金情報の収集機能を有し、上記制御部が、前記ユーザ端末からインターネット接続の切断要求パケットを受信した時、上記プロトコル処理部から上記ユーザ端末の課金情報を回収し、上記サーバ間通信制御手段によって、上記課金情報を含む課金停止要求パケットを前記加入者認証サーバに送信することを他の特徴とする。

また、加入者認証サーバを含むインターネットサービスプロバイダ（ＩＳＰ）網に接続される本発明のアクセスネットワークシステムは、ＩＳＰ網を介してユーザ端末をインターネット網に接続するためのパケット転送装置と、上記ＩＳＰ網で使用可能な複数のＩＰアドレスをサブアドレスプールとして保持するためのアドレスプール管理テーブルを備えたアドレスプール管理サーバとからなり、各パケット転送装置が、インターネットへの接続を要求するユーザ端末について、上記加入者認証サーバによる認証に成功した時、上記ユーザ端末に割り当てるべきＩＰアドレスを上記アドレスプール管理サーバから取得することを特徴とする。

更に詳述すると、本発明のアクセスネットワークシステムは、上記パケット転送装置が、ユーザ端末との接続回線または上記ＩＳＰ網との接続回線に接続される複数の回線インタフェースと、制御部と、上記各回線インタフェースおよび上記制御部に接続され、これらの要素間で受信パケットを交換するプロトコル処理部とからなり、
上記制御部が、ユーザ端末の識別子と割り当てアドレスとの関係を記憶するためのユーザアドレス管理テーブルと、上記アドレスプール管理サーバに、インターネットへの接続を要求したユーザ端末についての認証要求を送信し、上記アドレスプール管理サーバから上記認証要求に対する応答パケットを受信した時、該応答パケットから上記ユーザ端末に割り当てるべきＩＰアドレスを抽出し、該ＩＰアドレスを上記ユーザ端末の識別子と対応させて上記ユーザアドレス管理テーブルに記憶するサーバ間通信制御手段と、上記ユーザ端末との間で、加入者認証のための通信手順を実行した後、該ユーザ端末から受信したＩＰアドレス要求パケットに応答して、上記ユーザアドレス管理テーブルが示す上記ユーザ端末識別子と対応するＩＰアドレスを通知する端末通信制御手段とを有し、
上記アドレスプール管理サーバが、上記パケット転送装置から受信した上記認証要求を上記加入者認証サーバに転送し、上記加入者認証サーバから、サブアドレスプールの適用指示を含む応答パケットを受信した時、上記アドレスプール管理テーブルから空きＩＰアドレスを検索し、該ＩＰアドレスを含む応答パケットを上記パケット転送装置に返送するサーバ間通信制御手段を有することを特徴とする。

本発明によるアクセスネットワークシステムの１つの特徴は、上記パケット転送装置のプロトコル処理部が、インターネット網に接続されたユーザ端末の課金情報の収集機能を有し、上記制御部が、ユーザ端末からインターネット接続の切断要求パケットを受信した時、上記プロトコル処理部からユーザ端末の課金情報を回収し、該課金情報を含む課金停止要求パケットをアドレスプール管理サーバに送信し、上記アドレスプール管理サーバが、上記課金停止要求パケットを加入者認証サーバに転送するようにしたことにある。

本発明のパケット転送装置およびアクセスネットワークシステムは、アクセスサーバ（パケット転送装置）が、該アクセス網に配置されたアドレスプール管理サーバからユーザ端末割り当て用のＩＰアドレスを取得する構成となっているため、アドレスプール管理サーバが管理するサブアドレスプールを複数のアクセスサーバで共有でき、ＩＳＰ網に接続された加入者認証サーバの負荷の軽減と、ＩＳＰが所有するアドレスプールの有効利用が可能となる。また、アクセス網を管理するキャリアとＩＳＰとの間でのサブアドレスプール範囲の変更頻度を減少することが可能となる。

以下、本発明に実施例について図面を参照して説明する。
図１は、本発明のパケット転送装置が適用されるネットワーク構成の１例を示す。
ここに示したネットワークは、キャリアが提供するアクセス網ＮＷ１（ＮＷ１−１、ＮＷ１−２）と、ＩＳＰが管理するＩＳＰ網ＮＷ２と、インターネットＮＷ３とから構成され、これらの網は、ルータＲ１〜Ｒ５によって接続されている。ＩＳＰ網ＮＷ２には、加入者認証サーバとして機能するＲａｄｉｕｓ（Remote Authentication Dial In User Service）サーバＳＶが接続されている。

アクセス網ＮＷ１−１は、パケット転送装置Ｂ１−ｉ（ｉ＝１〜３）と、アドレスプール管理サーバ１−１とを含み、各パケット転送装置Ｂ１−ｉは、地域Ｓ１−ｉに位置した複数のユーザ端末Ｈｉ−ｊ（ｊ＝１〜ｎ、１〜ｍ、１〜ｋ）を収容し、これらのユーザ端末をインターネットＮＷ３に接続するためのアクセスサーバ（ＢＡＳ）として機能する。同様に、アクセス網ＮＷ１−２は、パケット転送装置Ｂ２−ｉ（ｉ＝１〜３）と、アドレスプール管理サーバ１−２を含み、各パケット転送装置Ｂ２−ｉは、地域Ｓ２−ｉに位置した複数のユーザ端末を収容し、インターネットＮＷ３へのアクセスサーバとして機能する。

ここで、パケット転送装置Ｂ１−ｉ（ｉ＝１〜３）とアドレス管理サーバ１−１は、アクセス網ＮＷ１−１のキャリアＡによって管理され、パケット転送装置Ｂ２−ｉ（ｉ＝１〜３）とアドレス管理サーバ１−２は、アクセス網ＮＷ１−２のキャリアＢによって管理されている。アドレスプール管理サーバ１−１と１−２は、それぞれＲａｄｉｕｓサーバＳＶから委託されたアドレス群をサブアドレスプールとして保持し、ＲａｄｉｕｓサーバＳＶに代わって、ユーザ端末へのＩＰアドレスの割り当てと、ＩＰアドレスの状態管理を実行する。図示した例では、アドレスプール管理サーバ１−１は、ＲａｄｉｕｓサーバＳＶから「10.10.0.0」〜「10.10.3.255」のＩＰアドレス群、アドレスプール管理サーバ１−２は、「10.10.4.0」〜「10.10.7.255」のＩＰアドレス群の運用と管理を委託されている。

パケット転送装置Ｂ１−ｉ、Ｂ２−ｉは、ユーザ端末からインターネットへの接続要求が発生した時、要求元ユーザ端末にユーザ認証のためのユーザＩＤとパスワードの送信を要求し、ユーザ端末から受信したユーザＩＤとパスワードを含むアクセス要求（認証要求）メッセージをＩＳＰ網ＮＷ２に位置するＲａｄｉｕｓサーバＳＶに送信し、ＲａｄｉｕｓサーバＳＶからの応答に従って、ユーザ端末のインターネットへの接続の可否を判断する。

ＲａｄｉｕｓサーバＳＶは、ユーザＩＤと対応して、パスワード、住所、氏名、口座番号、課金データなどの加入者情報を管理しており、パケット転送装置からアクセス要求メッセージを受信すると、受信メッセージが示すユーザＩＤに基づいて加入者情報を参照し、受信メッセージが示すパスワードの正当性を判定して、判定結果を示す応答メッセージを要求元のパケット転送装置に返送する。また、ＲａｄｉｕｓサーバＳＶは、パケット転送装置からの課金要求メッセージに従って、加入者毎の課金管理を開始する。ＲａｄｉｕｓサーバＳＶとパケット転送装置との間の通信は、ＲＡＤＩＵＳプロトコルに従って行われる。

図２は、パケット転送装置Ｂ１−１の構成を示すブロック図である。他のパケット転送装置Ｂ１−２〜Ｂ２−３も、これと同様の構成となっている。
本発明のパケット転送装置Ｂ１−１は、ユーザ端末またはルータに接続される入出力回線ＬＩ−ｉ、ＬＯ−ｉ（ｉ＝１〜ｋ）に結合された回線インタフェース１１−ｉ（ｉ＝１〜ｋ）と、これらの回線インタフェースに接続されたプロトコル処理部１２と、回線インタフェース１１−ｉ（ｉ＝１〜ｋ）およびプロトコル処理部１２に接続された制御部２０とからなる。

回線インタフェース１１−ｉは、入力回線ＬＩ−ｉからの受信信号を受信パケットに変換し、ポート番号を付加してプロトコル処理部１２に転送し、プロトコル処理部１２から受信したパケットから不要となったポート番号を除去し、送信信号に変換して出力回線ＬＯ−ｉに送出する。プロトコル処理部１２は、各回線インタフェースから受信パケットを取り込み、ヘッダ情報に応じて受信パケットの転送先ポートを決定し、制御部２０または何れかの回線インタフェースに受信パケットを転送する。プロトコル処理部１２は、ルーティングテーブル１３と課金のための統計テーブル１４を備えており、受信パケットの転送先ポートは、上記ルーティングテーブル１３を参照して決定される。

制御部２０は、プロセッサ２１と、プロセッサ２１が実行する各種プログラムが格納されるプログラムメモリ２２と、プロセッサ２１が参照する各種のテーブルが格納されるデータメモリ２３と、システム管理者が操作する制御端末４０と接続するための制御端末インタフェース２４とからなり、ユーザ端末とインターネットとの接続確立／切断制御と、ＲａｄｉｕｓサーバＳＶおよびアドレスプール管理サーバ１−１との間でユーザ認証、ＩＰアドレス割り当て、課金制御のための制御メッセージを交信する機能を備えている。

プログラムメモリ２２には、プロセッサ２１が実行する本発明に関係するプログラムとして、例えば、接続制御ルーチン３０と、ユーザ端末との間でコネクション確立／切断用の制御メッセージを交信するＰＰＰ ＬＣＰ／ＮＣＰ通信制御ルーチン３１と、加入者認証サーバ（ＩＳＰ−Ｒａｄｉｕｓサーバ）ＳＶおよびアドレスプール管理サーバ１−１との間で制御メッセージを交信するサーバ間通信用のＲａｄｉｕ通信制御ルーチン３２とが用意されている。尚、破線ブロックで示したアドレスプール検索ルーチン３３は、後述する本発明の第３実施例に関係するルーチンである。

データメモリ２３には、本発明が関係するテーブルとして、ユーザ端末に割り当てるべきＩＰアドレスの要求先となるアドレスプール管理サーバのアドレスを示す管理サーバアドレステーブル３４と、アドレスプール管理サーバから受信したＩＰアドレスの使用状態を管理するためのユーザアドレス管理テーブル３５とが用意されている。破線ブロックで示したアドレスプール管理テーブル３５は、後述する本発明の第３実施例に関係するテーブルである。

図３は、管理サーバアドレステーブル３４の内容の１例を示す。
管理サーバアドレステーブル３４は、ＩＳＰ名３４１と、アドレスプール管理サーバアドレス３４２との対応関係を示す複数のエントリからなる。管理サーバアドレステーブル３４の内容は、システム管理者が制御端末４０を介して設定する。

例えば、図１に示したネットワークでは、ＩＳＰ網ＮＷ２のプロバイダ（ＩＳＰ１）がアクセス網ＮＷ１−１に収容された加入者端末に配布すべきＩＰアドレスは、アドレスプール管理サーバ１−１によって管理されている。従って、アクセス網ＮＷ１−１内に配置された各パケット転送装置Ｂ１−ｉ（ｉ＝１〜３）の管理サーバアドレステーブル３４には、ＩＳＰ名３４１：「ＩＳＰ１」と対応するアドレスプール管理サーバアドレス３４２として、アドレスプール管理サーバ１−１のＩＰアドレス「10.20.0.1」が登録される。

パケット転送装置Ｂ１−１は、ユーザ端末Ｈ１−１〜Ｈ１−ｎにＩＰアドレスを割り当てる際、上記管理サーバアドレステーブル３４を参照することによって、アドレスプール管理サーバ１−１にＩＰアドレスの配布を要求することが可能となる。尚、ＩＳＰ名に関係なく通信すべきアドレスプール管理サーバを指定する場合は、ＩＳＰ名３４１：「Default」と対応して、アドレスプール管理サーバのＩＰアドレスを指定したデフォルトエントリを登録しておけばよい。

図４（Ａ）〜（Ｄ）は、ユーザアドレス管理テーブル３５の１例を示す。
ユーザアドレス管理テーブル３５には、インターネットへの接続要求時に端末ユーザが使用したユーザＩＤ３５１と対応して、ユーザ端末に割り当てるＩＰアドレス３５３と、該ＩＰアドレス３５３の状態３５２とを示す複数のエントリ３５０−１、３５０−２、・・が登録される。本実施例では、状態３５２として、パケット転送装置Ｂ１−１がアドレスプール管理サーバにＩＰアドレスの配布を申請中の状態であることを示す「申請中」と、アドレスプール管理サーバからＩＰアドレスを受信した直後で、要求元のユーザ端末には未だＩＰアドレスを配布していない状態を示す「配布待ち」と、ユーザ端末にＩＰアドレスを配布済みの状態を示す「配布済み」の３つの状態がある。図４の（Ｂ）〜（Ｄ）は、端末Ｈ１−ｎからユーザＩＤ「yyy＠tokyo.ISP1」でインターネット接続要求が発生した場合のエントリ３５０−２の状態変化を示している。ユーザアドレス管理テーブル３５の更新処理については、後で詳述する。

図５は、アドレスプール管理サーバ１−１（１−２）の構成を示すブロック図である。
アドレスプール管理サーバ１−１は、プロセッサ５１と、アクセス網ＮＷ１−１（ＮＷ１−２）に接続するための回線インタフェース５２と、データメモリ５３と、プログラムメモリ５４と、入力装置５５および表示装置５６からなる。

回線インタフェース５２は、アクセス網ＮＷ１−１の入力回線からの受信信号を受信パケットに変換して、プロセッサ５１に転送し、プロセッサ５１から出力された送信パケットを送信信号に変換してアクセス網ＮＷ１−１の出力回線に送出する。
データメモリ５３には、プロセッサ５１が参照するテーブルとして、アドレスプール管理テーブル７０が用意されている。また、プログラムメモリ５４には、プロセッサ５１が実行する本発明に関係するプログラムとして、アクセスサーバＢ１−ｉ（ｉ＝１〜ｋ）と制御メッセージを交信するためのサーバ間通信制御ルーチン７１と、アドレスプール検索ルーチン７３が用意されている。

図６の（Ａ）、（Ｂ）は、アドレスプール管理テーブル７０の１例を示す。
アドレスプール管理テーブル７０は、ドメイン名７０１毎にサブアドレスプールの内容を定義している。サブアドレスプールは、項番７０２と、ＩＰアドレス７０３と、配布先７０４とを示す複数のエントリからなっている。

アクセスネットワークを運営する各キャリアのシステム管理者は、ＩＳＰとのサービス契約時に、ＩＳＰからユーザ端末に割り当て可能なＩＰアドレスの範囲を通知される。システム管理者は、契約時に入手した割り当て可能ＩＰアドレスに基づいて、上記アドレスプール管理テーブル７０のサブアドレスプールを構成する。

例えば、ＩＳＰ１からキャリアＡに、ドメイン名「ＩＳＰ１」を含むユーザＩＤを用いたインターネット接続要求に対して、「10.10.0.0」〜「10.10.3.255」の範囲内でＩＰアドレスを割り当てるように指示した場合を想定する。この場合、ＩＳＰ１の加入者認証サーバ（ＩＳＰ−Ｒａｄｉｕｓサーバ）では、図１にＤＢ−１で示すように、キャリアＡと割り当てＩＰアドレス範囲との関係をテーブルに記憶しておく。

一方、キャリアＡのアドレスプール管理サーバ１−１では、アドレスプール管理テーブル７０に、ドメイン名７０１：「ＩＳＰ１」と対応するサブアドレスプールとして、ＩＰアドレス７０３が「10.10.0.0」〜「10.10.3.255」のエントリを登録する。ここで、予め端末に割り当て不能と判っているＩＰアドレスの配布先７０４には「配布不可」、それ以外のＩＰアドレスの配布先７０４には「空き」を示す状態情報が記憶される。但し、ドメイン名７０１を、例えば、「tokyo.ISP1」や「osaka.ISP1」の如く地域別に分割し、割り当てＩＰアドレスの範囲を細分化して指定することも可能である。

図６（Ａ）では、項番「５２」のエントリが示すように、ＩＰアドレス「10.10.0.52」が空き状態となっている。図６（Ｂ）は、上記ＩＰアドレス「10.10.0.52」が、ユーザＩＤ「yyy＠tokyo.ISP1」を使用してインターネットの接続要求を発行したユーザ端末Ｈ１−ｎに割り当て済みとなった状態を示している。ユーザ端末へのＩＰアドレスの割り当てについては、図１３、図１４を参照して後で詳述する。

次に、図７に示すシーケンス図を参照して、本発明のパケット転送装置（ＢＡＳ）Ｂ１−１によるユーザ端末へのＩＰアドレス割り当てに関する第１実施例について説明する。
ここでは、図１に示したユーザＩＤ「yyy＠tokyo.ISP1」をもつユーザ端末Ｈ１−ｎが、ＰＰＰ（Point to Point Protocol）を使用して、パケット転送装置（ＢＡＳ）Ｂ１−１に、インターネット接続要求を発生した場合について説明する。

ユーザ端末Ｈ１−ｎは、ＰＰＰにおける通常の接続シーケンスに従って、パケット転送装置Ｂ１−１との間にＰＰＰ ＬＣＰセッションを確立する（ステップＳＱ１）。ＰＰＰ ＬＣＰセッションは、ユーザ端末Ｈ１−ｎからパケット転送装置Ｂ１−１に、PPP LCP Configure-Requestを送信し、これに応答して、パケット転送装置Ｂ１−１からユーザ端末Ｈ１−ｎにPPP LCP Configure-Requestを返送することによって成立する。

ユーザ端末Ｈ１−ｎとの間にＰＰＰ ＬＣＰセッションを確立したパケット転送装置Ｂ１−１は、ユーザ端末Ｈ１−ｎがインターネットとの接続資格をもっているか否かを判断するため、ユーザ端末Ｈ１−ｎに、ユーザＩＤとパスワードの送信を求める認証データ要求メッセージを送信する（ＳＱ２）。ユーザ端末Ｈ１−ｎが、上記要求に応答して、ユーザＩＤ「yyy＠tokyo.ISP1」とパスワードを含む認証応答メッセージを送信すると（ＳＱ３）、パケット転送装置Ｂ１−１は、ＩＳＰ１が管理する加入者認証サーバ（Ｒａｄｉｕｓサーバ）ＳＶに対して、上記ユーザＩＤとパスワードを含むアクセス要求メッセージ（Access-Request）を送信する（ＳＱ４Ａ）。

ＲａｄｉｕｓサーバＳＶは、上記アクセス要求メッセージを受信すると、ユーザＩＤ「yyy＠tokyo.ISP1」と対応して予め登録されている加入者情報に基づいて、上記アクセス要求メッセージが示すパスワードをチェックし、パスワードの認証結果を示すアクセス応答メッセージを要求元のパケット転送装置Ｂ１−１に返送する（ＳＱ５Ａ）。上記パスワードが予め登録されたパスワードと一致していた場合、ＲａｄｉｕｓサーバＳＶは、ユーザ端末Ｈ１−ｎとインターネットとの接続を許可する応答メッセージ（Access-Accept）を返送する。

上記アクセス応答メッセージ（Access-Accept）は、図８に示すように、ＩＰヘッダ１０１とＵＤＰヘッダ１０２を付加したＩＰパケット形式で送信される。アクセス応答メッセージは、メッセージ種類「Access-Accept」を示すRadius Code１０３に続くRadius アトリビュートとして、ユーザ端末Ｈ１−ｎが使用すべきＩＰアドレスを示すFramed-IP-Addressアトリビュート１０４と、Vendor-Specificアトリビュート１０５と、その他のアトリビュート１０６を含む。
本実施例では、ＲａｄｉｕｓサーバＳＶは、上記アクセス応答メッセージのFramed-IP-Addressアトリビュート１０４に、アクセス網側のサブアドレスプールからユーザ端末へのＩＰアドレスの割り当てを指示する特定値「255.255.255.254」を設定し、Vendor-Specificアトリビュート１０５でアドレスプール管理サーバのＩＰアドレス「10.20.0.1」を指定する。但し、パケット転送装置Ｂ１−１の管理サーバアドレステーブル３４に、アドレスプール管理サーバのＩＰアドレスが予め登録されている場合は、上記Vendor-Specificアトリビュートの内容は不要となる。

パケット転送装置Ｂ１−１は、ＲａｄｉｕｓサーバＳＶから受信したアクセス応答メッセージ（Access-Accept）のFramed-IP-Addressアトリビュート１０４が特定値「255.255.255.254」となっていた場合、Vendor-Specificアトリビュート１０５（または、管理サーバアドレステーブル３４）が示すアドレスプール管理サーバ１−１に対して、上記ユーザＩＤ「yyy＠tokyo.ISP1」を含む第２のアクセス要求メッセージ（Access-Request）を送信する（ＳＱ６Ａ）。

アドレスプール管理サーバ１−１は、上記アクセス要求メッセージ（Access-Request）を受信すると、アドレスプール管理テーブル７０３から、ユーザＩＤ「yyy＠tokyo.ISP1」に割り当てるための空き状態のＩＰアドレスを検索し、該ＩＰアドレスを示す応答メッセージ（Access-Accept）を要求元パケット転送装置Ｂ１−１に返送する（ＳＱ７Ａ）。この時、アドレスプール管理テーブル７０３には、図６（Ｂ）に示したように、割り当てＩＰアドレスと対応する配布先７０４にユーザＩＤが登録され、該ＩＰアドレスが空き状態から使用中の状態に変化する。

アドレスプール管理サーバ１−１が返送する応答メッセージ（Access-Accept）は、図８のメッセージフォーマットからVendor-Specificアトリビュート１０５を省略したフォーマットとなっている。例えば、ユーザＩＤ「yyy＠tokyo.ISP1」にＩＰアドレス「10.10.0.52」を割り当てる場合、Framed-IP-Addressアトリビュート１０４には、ＩＰアドレス値「10.10.0.52」が設定される。

パケット転送装置Ｂ１−１は、アドレスプール管理サーバ１−１から上記応答メッセージ（Access-Accept）を受信すると、Framed-IP-Addressアトリビュート１０４から、ユーザ端末Ｈ１−ｎに割り当てるべきＩＰアドレスが「10.10.0.52」であることを知る。この場合、パケット転送装置Ｂ１−１は、図４（Ｂ）に示したユーザアドレス管理テーブル３５内のユーザＩＤ「yyy＠tokyo.ISP1」をもつテーブルエントリ３５０−２に、配布アドレス３５３として「10.10.0.52」を設定し、図４（Ｃ）に示すように、状態３５２を「配布待ち」に設定した後、ユーザ端末Ｈ１−ｎに対して、認証完了メッセージを送信する（ＳＱ８）。上記認証完了メッセージの送信によって、ＰＰＰ ＬＣＰの通信シーケンスが完了し、ＰＰＰ・ＮＣＰの通信シーケンスに移行する。

ユーザ端末Ｈ１−ｎは、上記認証完了メッセージを受信すると、パケット転送装置Ｂ１−１に対して、ＩＰアドレス割り当て要求（IPCP Configure-Request）を送信する（ＳＱ９）。パケット転送装置Ｂ１−１は、上記ＩＰアドレス割り当て要求に応答して、ユーザアドレステーブルのエントリ２１５０−２に記憶してあるＩＰアドレス「10.10.0.52」を含むＩＰアドレス配布メッセージ（IPCP Configure-Ack）を生成し、これをユーザ端末Ｈ１−ｎに返信する（ＳＱ１０）。

この時、パケット転送装置Ｂ１−１は、図４（Ｄ）に示すように、ユーザアドレス管理テーブル３５のエントリ３５０−２の状態３５２を「配布済み」に変更することによって、ユーザ端末Ｈ１−ｎへのＩＰアドレスの割り当てを完了する。この後、パケット転送装置Ｂ１−１は、ＲａｄｉｕｓサーバＳＶに対して、ユーザ端末Ｈ１−ｎの課金開始の要求メッセージ（Accounting-Request(Start)）を送信する（ＳＱ１１Ａ）。

上記課金開始要求メッセージは、例えば、図９に示すように、メッセージ種類「Accounting-Request」を示すRadius Code１０３に続くRadius アトリビュートとして、User-Nameアトリビュート１１０と、Acct-Status-Typeアトリビュート１１１と、その他のアトリビュート１１２を含む。本実施例の場合、User-Nameアトリビュート１１０にはユーザＩＤ「yyy＠tokyo.ISP1」が設定され、Acct-Status-Typeアトリビュート１１１には、課金開始を示す“Start”が設定される。

ＲａｄｉｕｓサーバＳＶは、上記課金開始要求メッセージに応答して、課金開始応答メッセージ（Accounting-Response）を返送する（ＳＱ１２Ａ）。パケット転送装置Ｂ１−１は、ＲａｄｉｕｓサーバＳＶから課金開始応答メッセージを受信すると、プロトコル処理部１２による課金用統計データの収集動作を開始し、アドレスプール管理サーバ１−１に対して、ユーザ端末Ｈ１−ｎの課金開始要求メッセージ（Accounting-Request(Start)）を送信する（ＳＱ１３Ａ）。

アドレスプール管理サーバ１−１は、上記要求メッセージを受信すると、パケット転送装置Ｂ１−１に課金開始応答メッセージ（Accounting-Response(Start)）を返送する（ＳＱ１４Ａ）。パケット転送装置Ｂ１−１は、上記アドレスプール管理サーバ１−１からの課金開始応答メッセージを受信すると、ユーザ端末Ｈ１−ｎによるインターネットのアクセスパケット（IP over PPP）の転送動作を開始する（ＳＱ２０）。

次に、インターネット接続の切断シーケンスについて説明する。
ユーザ端末Ｈ１−ｎは、インターネットとの接続を切断する場合、パケット転送装置Ｂ１−１に対してＰＰＰ ＬＣＰセッションの切断要求メッセージ（PPP LCP Terminate-Request）を送信する（ＳＱ３１）。パケット転送装置Ｂ１−１は、上記切断要求を受信すると、ユーザ端末Ｈ１−ｎに応答メッセージ（PPP LCP Terminate-Response）に返送する（ＳＱ３２）。この後、パケット転送装置Ｂ１−１は、ユーザＩＤ「yyy＠tokyo.ISP1」に対する課金処理の停止要求メッセージ（Accounting-Request(Stop)）をＲａｄｉｕｓサーバＳＶに送信する（ＳＱ３３Ａ）。上記課金停止要求メッセージには、プロトコル処理部１２で収集したユーザ端末Ｈ１−ｎの課金統計データが含まれる。

ＲａｄｉｕｓサーバＳＶは、上記課金停止要求メッセージの受信に応答して、ユーザＩＤ「yyy＠tokyo.ISP1」についての課金処理を終了した後、パケット転送装置Ｂ１−１に課金停止応答メッセージ（Accounting-Response(Stop)）を返信する（ＳＱ３４Ａ）。

パケット転送装置Ｂ１−１は、上記課金停止応答メッセージを受信すると、ユーザアドレス管理テーブル３５から、ユーザＩＤフィールド３５１が「yyy＠tokyo.ISP1」のエントリ３５０−２を削除し、今度は、アドレスプール管理サーバ１−１に対して、ユーザＩＤ「yyy＠tokyo.ISP1」に対する課金処理の停止要求メッセージ（Accounting-Request(Stop)）を送信する（ＳＱ３５Ａ）。上記課金停止要求メッセージは、図９に示したフォーマットにおいて、Acct-Status-Typeアトリビュート１１１が、課金停止を示す“Stop”となっている。

アドレスプール管理サーバ１−１は、上記課金停止要求メッセージの受信によって、User-Nameアトリビュート１１０が示すユーザＩＤ「yyy＠tokyo.ISP1」への割り当てＩＰアドレスが解放されたことを知る。そこで、アドレスプール管理サーバ１−１は、アドレスプール管理テーブル７０から、配布先７０４にユーザＩＤ「yyy＠tokyo.ISP1」が設定されているエントリを検索し、配布先７０４を「空き」状態に変更することによって、上記エントリのＩＰアドレス「10.10.0.52」を空きアドレスとして解放する。
アドレスプール管理サーバ１−１は、上記ＩＰアドレスの解放処理が終了すると、パケット転送装置Ｂ１−１に対して、課金停止応答メッセージ（Accounting-Response (Stop)）を返信する（ＳＱ３６Ａ）。

図１０は、上述した通信シーケンスを実現するためにパケット転送装置Ｂ１−１のプロセッサ２１が実行する接続制御ルーチン３０のフローチャートを示す。
パケット転送装置Ｂ１−１のプロトコル処理部１２は、回線インタフェース１１−ｉ（ｉ＝１〜ｋ）から受信したパケットのうち、ＰＰＰ制御パケットと、宛先がパケット転送装置Ｂ１−１のＩＰアドレスとなっているＩＰパケットを制御部２０のプロセッサ２１に転送する。その他の受信パケットは、ルーティングテーブル１３に従って、宛先ＩＰアドレスと対応した何れかの回線インタフェースに転送される。

制御部２０のプロセッサ２１は、プロトコル処理部１２からパケットを受信すると、図１０に示す接続制御ルーチン３０に従って、受信パケットに応じた応答動作を実行する。

すなわち、受信パケットが、ユーザ端末からのＰＰＰ ＬＣＰの接続要求パケットの場合（ステップ３０１でＹＥＳ）、プロセッサ２１は、ＰＰＰ ＬＣＰ／ＮＣＰ通信制御ルーチン３１によって、ＰＰＰ ＬＣＰ接続のための所定の処理を実行（３１１）した後、要求元ユーザ端末に認証データ要求メッセージを送信して（３１２）、このルーチンを終了する。

受信パケットが、認証データ要求に対するユーザ端末からの応答の場合（ステップ３０２でＹＥＳ）、プロセッサ２１は、Ｒａｄｉｕｓ通信制御ルーチン３２によって、加入者認証サーバＳＶにアクセス要求（Access-Request）を送信（３１３）して、このルーチンを終了する。

受信パケットが、ユーザ端末からのＩＰアドレス要求（IPCP Configure-Req）の場合（ステップ３０３でＹＥＳ）、プロセッサ２１は、ユーザアドレス管理テーブル３５からＩＰアドレスを読み出し、ＰＰＰ ＬＣＰ／ＮＣＰ通信制御ルーチン３１によって、上記ＩＰアドレスを示すＩＰアドレス配布メッセージを要求元ユーザ端末に送信する（３１４）。この後、プロセッサ２１は、ユーザアドレス管理テーブル３５の状態フィールド３５２を「配布済み」に更新（３１５）した後、Ｒａｄｉｕｓ通信制御ルーチン３２によって、加入者認証サーバＳＶに課金要求メッセージ（Accounting-Request (Start)）を送信して（３１６）、このルーチンを終了する。

受信パケットが、ユーザ端末からのＰＰＰ ＬＣＰの終了要求パケットの場合（ステップ３０４でＹＥＳ）、プロセッサ２１は、ＰＰＰ ＬＣＰ／ＮＣＰ通信制御ルーチン３１によって、要求元ユーザ端末にＰＰＰ ＬＣＰ終了要求応答を送信する（３１８）。この後、プロセッサ２１は、プロトコル処理部１２から、上記ユーザ端末の課金統計情報を回収し（３１９）、Ｒａｄｉｕｓ通信制御ルーチン３２によって、加入者認証サーバＳＶに上記課金統計情報を含む課金停止要求メッセージ（Accounting-Request (Stop)）を送信し（３２０）、このルーチンを終了する。

プロセッサ２１は、受信パケットがＲａｄｉｕｓパケット場合（ステップ３０５でＹＥＳ）、それがアクセス要求応答パケットであれば（ステップ３０６でＹＥＳ）、図１１で詳述するアクセス要求応答受信処理３４０を実行し、そうでなければ、図１２で詳述する課金要求応答受信処理３６０を実行して、このルーチンを終了する。受信パケットが、上述したパケットの何れにも該当しない場合（ステップ３０５でＮＯ）、プロセッサ２１は、その他の処理３３０を実行して、このルーチンを終了する。

図１１は、アクセス要求応答受信処理３４０の詳細を示すフローチャートである。
アクセス要求応答受信処理３４０では、プロセッサ２１は、受信パケットが、ユーザ認証に成功したことを示すAccess-Acceptパケットか否かを判定する（３４１）。受信パケットが、Access-Acceptパケットでなければ、プロセッサ２１は、ＰＰＰ異常終了処理（３４２）を実行して、このルーチンを終了する。

受信パケットが、Access-Acceptパケットの場合、プロセッサ２１は、Framed-IP-Addressアトリビュートをチェックし（３４３）、通常のＩＰアドレスを示していた場合は、ユーザアドレス管理テーブル３５の要求元端末のユーザＩＤと対応するエントリに、上記ＩＰアドレスを配布アドレス３５３として登録（３４４）した後、ＰＰＰ ＬＣＰ／ＮＣＰ通信制御ルーチン３１によって、要求元ユーザ端末に認証完了メッセージを送信して（３４５）、このルーチンを終了する。

受信パケットのFramed-IP-Addressアトリビュートが、特定値「255.255.255.254」を示していた場合、プロセッサ２１は、受信パケットのVendor-Specificアトリビュートをチェックする（３４６）。Vendor-Specificアトリビュートでサーバアドレスが指定されていた場合、プロセッサ２１は、上記サーバアドレスをＩＰアドレス要求すべきアドレスプール管理サーバのアドレスとして特定し（３４７）、Ｒａｄｉｕｓ通信制御ルーチン３２によって、上記サーバアドレスが示すアドレスプール管理サーバにアクセス要求（Access-Request）を送信する（４５０）。この後、プロセッサ２１は、ユーザアドレス管理テーブル３５に、受信パケットに含まれる認証対象ユーザＩＤと対応するテーブルエントリを登録して（３５１）、このルーチンを終了する。

Vendor-Specificアトリビュートでサーバアドレスが指定されていなかった場合、プロセッサ２１は、受信パケットに含まれる認証対象要求元ユーザＩＤを解析することによって、ドメイン名を特定（３４８）した後、管理サーバアドレステーブル３４から、上記ドメイン名（ＩＳＰ名）に該当するアドレスプール管理サーバのアドレスを特定する（３４９）。この後、プロセッサ２１は、Ｒａｄｉｕｓ通信制御ルーチン３２によって、上記サーバアドレスが示すアドレスプール管理サーバにアクセス要求（Access-Request）を送信し（４５０）、ユーザアドレス管理テーブルに、認証対象ユーザＩＤと対応するテーブルエントリを登録して（３５１）、このルーチンを終了する。

図１２は、課金要求応答受信処理３６０の詳細を示すフローチャートである。
課金要求応答受信処理３６０では、プロセッサ２１は、受信パケットが、課金開始要求に対する応答パケットか否かを判定する（３６１）。受信パケットが、課金開始要求に対する応答パケットの場合、プロセッサ２１は、受信パケットの送信元を判定し（３６２）、送信元が加入者認証サーバでなければ、この処理を終了する。送信元が加入者認証サーバの場合、プロセッサ２１は、プロトコル処理部１２に、割り当てＩＰアドレスをもつＩＰパケットについて、課金用統計データの収集開始を指示し（３６３）、Ｒａｄｉｕｓ通信制御ルーチン３２によって、アドレスプール管理サーバに課金開始要求を送信して（３６４）、この処理を終了する。

受信パケットが、課金開始要求に対する応答パケットでなかった場合、プロセッサ２１は、受信パケットが、課金停止要求に対する応答パケットか否かを判定する（３６５）。
受信パケットが、課金停止要求応答パケットの場合、プロセッサ２１は、受信パケットの送信元を判定する（３６７）。受信パケットの送信元が加入者認証サーバの場合、プロセッサ２１は、Ｒａｄｉｕｓ通信制御ルーチン３２によって、アドレスプール管理サーバに課金停止要求を送信して（３６８）、この処理を終了する。受信パケットの送信元が加入者認証サーバでなかった場合、すなわち、アドレスプール管理サーバの場合、プロセッサ２１は、ユーザアドレス管理テーブル３５から、課金対象となっていたユーザＩＤと対応するテーブルエントリを削除して（３６９）、この処理を終了する。

図１３は、アドレスプール管理サーバ１−１のプロセッサ５１が実行するサーバ間通信制御ルーチン７３のフローチャートを示す。本実施例の場合、アドレスプール管理サーバ１−１の通信相手は、アクセスサーバＢ１−１〜Ｂ１−３であり、サーバ間の通信にはＲａｄｉｕｓプロトコルが適用されているため、上記サーバ間通信制御ルーチン７３が送受信するパケットは、原則としてＲａｄｉｕｓメッセージを含むパケットである。

プロセッサ５１は、回線インタフェース５２からパケットを受信すると、上記サーバ間通信制御ルーチン７１を実行して、まず、受信パケットがＲａｄｉｕｓパケットか否か判定する（７１０）。受信パケットがＲａｄｉｕｓパケットでなければ、プロセッサ５１は、その他の処理７１１を実行して、このルーチンを終了する。

受信パケットがＲａｄｉｕｓパケットの場合、プロセッサ５１は、受信パケットが示すメッセージ種別（Radius Code）から、受信パケットがアクセス要求（Access-Request）パケットか否かを判定する（７１２）。

受信パケットがアクセス要求パケットの場合、プロセッサ５１は、アドレスプール検索ルーチン７２を実行して、アドレスプール管理テーブル７０からユーザ端末に割り当てるべきＩＰアドレスを検索する。検索の結果（７１３）、ユーザ端末に割り当てるべき空きＩＰアドレスが見つかった場合、プロセッサ５１は、上記ＩＰアドレスを含む応答パケット（Access-Accept）を要求元のアクセスサーバに送信して（７１４）、このルーチンを終了する。上記応答パケットは、図８からVendor-Specificアトリビュート１０５を省略したパケットフォーマットを有し、Framed-IP-Addressアトリビュート１０４に、ユーザ端末に割り当てるべきＩＰアドレスの値、例えば、「10.10.0.52」を含む。

アドレスプール管理テーブル７０に空きＩＰアドレスが無かった場合、プロセッサ５１は、要求元のアクセスサーバに、アクセス要求に応じられなかったことを示す応答パケット（Access-Reject）を送信して（７１５）、このルーチンを終了する。

受信パケットがアクセス要求パケットでなかった場合、プロセッサ５１は、受信パケットが課金開始要求パケットか否かを判定し（７１６）、受信パケットが課金開始要求パケットの場合は、何もせずにこのルーチンを終了する。受信パケットが課金開始要求パケットでなかった場合、プロセッサ５１は、受信パケットが課金停止要求パケットか否かを判定する（７１７）。プロセッサ５１は、受信パケットが課金停止要求パケットの場合は、アドレスプール管理テーブル７０から、配布先７０４に課金停止対象となったユーザＩＤを含むエントリを検索し、該エントリのユーザＩＤを空き状態に置き換える（７１８）。
受信パケットが課金停止要求パケット以外の場合、プロセッサ５１は、その他の処理７１９を実行して、このルーチンを終了する。

図１４は、アドレスプール検索ルーチン７２の詳細フローチャートを示す。
ここでは、例えば、アドレスプール管理テーブル７０にドメイン名「ISP1」と対応して登録されているサブアドレスプールを項番「１」のエントリから順にサーチする場合の検索処理フローを示している。

プロセッサ５１は、先ず、サブアドレスプールの判定対象エントリを指定するためのパラメータｉの値を初期値０に設定し（７２０）、サブアドレスプールの第ｉエントリの配布先７０４を判定する（７２１）。配布先７０４の設定値から、第ｉエントリが空きエントリでないと判った場合は、プロセッサ５１は、パラメータｉの値が、アブアドレスプールの登録エントリ数ｉｍａｘ（図６の例では、1023）に一致するか否かを判定し（７２２）、パラメータｉの値がｉｍａｘに達していなければ、パラメータｉの値をインクリメント（７２３）した後、ステップ７２１に戻って、次エントリの配布先７０４の状態を判定する。

第ｉエントリが空きエントリの場合は、プロセッサ５１は、該エントリが示すＩＰアドレス７０３の値をユーザ端末割り当てＩＰアドレスとして特定し（７２５）、サブアドレスプールの上記エントリに含まれる配布先７０４に、ＩＰアドレス要求元のユーザ端末ＩＤを登録して（７２６）、このルーチンを終了する。パラメータｉの値がｉｍａｘに達した場合、すなわち、アドレスプールに空き状態のエントリが存在しない場合は、「空きＩＰアドレスなし」を検索結果として（７２４）、このルーチンが終了する。

図６（Ａ）に示した例では、パラメータｉの値が「５２」となった時、空き状態のエントリが見つかり、図６（Ｂ）に示すように、第５２エントリにユーザ端末ＩＤの値「yyy＠tokyo.ISP1」を登録して、アドレスプール検索が完了する。

上記フローチャートでは、アドレスプール管理テーブルサーチの都度、パラメータｉの値が初期化されるようになっているが、テーブルサーチを高速化するために、新たな認証要求が発生した時、前回サーチ終了時のパラメータｉの値を初期値として、テーブルサーチを開始するようにしてもよい。この場合、アドレスプールの最終エントリのＩＰアドレスが使用中と判定された時、パラメータｉの値をｉｍａｘから０に戻して、アドレスプールの最初のエントリから順に、空きＩＰアドレスをもつエントリの検索を継続するようにすればよい。

また、パラメータｉの値がアドレスプールを一巡して、テーブルサーチ開始エントリの項番に戻った時、空きＩＰアドレス無しと判断できるように、テーブルサーチ開始時のパラメータｉを保存しておき、ｉ値更新の都度、パラメータｉと保存値（最初の値）とを照合するようにすればよい。これに代えて、判定済みのエントリ数ｎをカウントし、カウント値ｎがアドレスプールの登録エントリ数ｉｍａｘに一致した時、空きＩＰアドレス無しと判断するようにしてもよい。

図１５は、本発明のパケット転送装置（ＢＡＳ）によるユーザ端末へのＩＰアドレス割り当ての第２実施例を示すシーケンス図である。以下、図７と同様、ユーザＩＤ「yyy＠tokyo.ISP1」をもつユーザ端末Ｈ１−ｎが、ＰＰＰを使用してインターネット接続を要求した場合について説明する。第２の実施例の特徴は、アドレスプール管理サーバ１−１が、加入者認証サーバ（Ｒａｄｉｕｓサーバ）ＳＶの代理装置として、パケット転送装置からのユーザ認証用のアクセス要求を受信する点にある。

ユーザ端末Ｈ１−ｎは、第１実施例と同様、パケット転送装置Ｂ１−１との間にＰＰＰ ＬＣＰセッションを確立し（ステップＳＱ１）、パケット転送装置Ｂ１−１からの認証データ要求の受信（ＳＱ２）に応答して、応答メッセージを送信する（ＳＱ３）。

第２実施例では、上記認証データ要求に対する応答メッセージを受信したパケット転送装置Ｂ１−１が、加入者認証サーバ（Ｒａｄｉｕｓサーバ）ＳＶの代理であるアドレスプール管理サーバ１−１に対して、上記応答メッセージが示すユーザＩＤ「yyy＠tokyo.ISP1」とパスワードとを含むアクセス要求（認証要求）メッセージ（Access-Request）を送信する（ＳＱ６Ｂ）。上記アクセス要求メッセージのアドレスプール管理サーバ１−１への送信は、パケット転送装置Ｂ１−１の管理者が、パケット転送装置Ｂ１−１に対するＲａｄｉｕｓサーバアドレスの指定時に、Ｒａｄｉｕｓサーバアドレスの代わりに、上記アドレスプール管理サーバ１−１のＩＰアドレス「10.20.0.１」を適用することによって実現できる。

アドレスプール管理サーバ１−１は、上記アクセス要求メッセージを受信すると、これをＲａｄｉｕｓサーバＳＶに転送する（ＳＱ４Ｂ）。ＲａｄｉｕｓサーバＳＶは、上記アクセス要求メッセージを受信すると、受信メッセージからユーザＩＤ「yyy＠tokyo.ISP1」とパスワードを抽出し、第１実施例と同様、ユーザＩＤ「yyy＠tokyo.ISP1」と対応して予め登録されている加入者情報に基づいて、パスワードの正当性をチェックする。

パスワードの正当性が認証された場合、ＲａｄｉｕｓサーバＳＶは、図８に示したアクセス応答メッセージ（Access-Accept）をアドレスプール管理サーバ１−１に返送する（ＳＱ５Ｂ）。上記アクセス応答メッセージのFramed-IP-Addressアトリビュート１０４には、第１実施例と同様、ユーザ端末Ｈ１−ｎへのＩＰアドレスの割り当てをアクセス網でサブアドレスプールから行うことを指示する特定値「255.255.255.254」が設定されている。尚、第２実施例では、Vender-Specificアトリビュート１０５によるアドレスプール管理サーバ１−１のＩＰアドレス指定は不要となる。

上記アクセス応答メッセージを受信したアドレスプール管理サーバ１−１は、受信メッセージのFramed-IP-Addressアトリビュートが特定値「255.255.255.254」を示しているため、図６に示したアドレスプール管理テーブル７０から、図１４で説明したアドレスプール検索によって、ユーザ端末Ｈ１−ｎに割り当てるべき空きＩＰアドレス、例えば、「10.10.0.52」を検索し、上記ＩＰアドレス「10.10.0.52」をFramed-IP-Addressアトリビュートで指定したアクセス応答メッセージ（Access-Accept）をパケット転送装置Ｂ１−１に送信する（ＳＱ７Ｂ）。

上記アクセス応答メッセージを受信したパケット転送装置Ｂ１−１は、第１実施例と同様、ユーザアドレス管理テーブル３５内のユーザＩＤ「yyy＠tokyo.ISP1」をもつテーブルエントリ３５０−２に、割り当てＩＰアドレス「10.10.0.52」を設定した後、ユーザ端末Ｈ１−ｎに対して、認証完了メッセージを送信する（ＳＱ８）。

上記認証完了メッセージを受信したユーザ端末Ｈ１−ｎは、パケット転送装置Ｂ１−１に対して、ＩＰアドレス割り当て要求（IPCP Configure-Rec）を送信し（ＳＱ９）、パケット転送装置Ｂ１−１は、上記ＩＰアドレス割り当て要求に応答して、ＩＰアドレス「10.10.0.52」を含むＩＰアドレス配布メッセージ（IPCP Configure-Ack）をユーザ端末Ｈ１−ｎに返信する（ＳＱ１０）。これによって、ユーザ端末Ｈ１−ｎに対するＩＰアドレスの割り当てが完了する。

パケット転送装置Ｂ１−１は、ユーザ端末Ｈ１−ｎに対するＩＰアドレスの割り当てが完了すると、ユーザ端末Ｈ１−ｎ（ユーザＩＤ「yyy＠tokyo.ISP1」）に関する課金開始要求メッセージ（Accounting-Request(Start)）を生成し、これをＲａｄｉｕｓサーバＳＶの代理であるアドレスプール管理サーバ１−１に送信する（ＳＱ１３Ｂ）、アドレスプール管理サーバ１−１は、パケット転送装置Ｂ１−１から受信した上記課金開始要求メッセージをＲａｄｉｕｓサーバＳＶに転送する（ＳＱ１１Ｂ）。

ＲａｄｉｕｓサーバＳＶは、上記課金開始要求メッセージを受信すると、ユーザＩＤ「yyy＠tokyo.ISP1」の通信に対する課金処理を開始し、課金開始応答メッセージ（Accounting-Response）をアドレスプール管理サーバ１に返送する（ＳＱ１２Ｂ）。アドレスプール管理サーバ１−１は、ＲａｄｉｕｓサーバＳＶから受信した課金開始応答メッセージをパケット転送装置Ｂ１−１に転送する（ＳＱ１４Ｂ）。パケット転送装置Ｂ１−１は、アドレスプール管理サーバ１−１から課金開始応答メッセージを受信すると、プロトコル処理部１２に、ＩＰアドレス「10.10.0.52」をもつ受信パケットについての課金用統計データの収集開始を指示し、ユーザ端末Ｈ１−ｎによるインターネットのアクセスパケット（IP over PPP）の転送動作を開始する（ＳＱ２０）。

ユーザ端末Ｈ１−ｎが、インターネットとの接続を切断する場合、ユーザ端末Ｈ１−ｎは、パケット転送装置Ｂ１−１にＰＰＰ ＬＣＰセッションの終了要求メッセージ（PPP LCP Terminate-Request）を送信する（ＳＱ３１）。パケット転送装置Ｂ１−１は、上記終了要求を受信すると、ユーザ端末Ｈ１−ｎに応答メッセージ（PPP LCP Terminate-response）に返送（ＳＱ３２）した後、プロトコル処理部１２に課金処理の停止を指令し、課金統計データを回収する。この後、ユーザＩＤ「yyy＠tokyo.ISP1」の課金統計データを含む課金処理の停止要求メッセージ（Accounting-Request(Stop)）を生成し、これをアドレスプール管理サーバ１−１宛に送信する（ＳＱ３５Ｂ）。

アドレスプール管理サーバ１−１は、上記課金停止要求メッセージ（Accounting-Request(Stop)）をＲａｄｉｕｓサーバＳＶに転送する（ＳＱ３３Ｂ）。ＲａｄｉｕｓサーバＳＶは、上記課金停止要求メッセージの受信に応答して、ユーザＩＤ「yyy＠tokyo.ISP1」についての課金処理を停止した後、アドレスプール管理サーバ１−１に課金停止応答メッセージ（Accounting-Request）を返信する（ＳＱ３４Ｂ）。

アドレスプール管理サーバ１−１は、上記課金停止応答メッセージを受信すると、アドレスプール管理テーブル７０から、配布先フィールド７０４にユーザＩＤ「yyy＠tokyo.ISP1」が設定されているエントリを検索し、配布先フィールド７０４を「空き」状態に変更することによって、上記エントリのＩＰアドレス「10.10.0.52」を解放する。
アドレスプール管理サーバ１−１は、上記ＩＰアドレスの解放処理が終了すると、パケット転送装置Ｂ１−１に対して、課金停止応答メッセージ（Accounting-Response）を返信する（ＳＱ３６Ｂ）。
パケット転送装置Ｂ１−１は、課金停止応答メッセージを受信すると、ユーザアドレステーブル２１５から、ユーザＩＤフィールド２１５１が「yyy＠tokyo.ISP1」のエントリ２１５０−２を削除する。

上記第１、第２実施例では、アクセス網ＮＷ１−１にアクセスプール管理サーバ１−１を配置し、パケット転送装置Ｂ１−１〜Ｂ１−３が、上記アクセスプール管理サーバ１−１から、ユーザ端末に割り当てるべきＩＰアドレスを取得したが、これらの実施例の変形として、アクセスプール管理サーバの機能をパケット転送装置Ｂ１−１〜Ｂ１−３のうちの何れかに実装しておき、他のパケット転送装置が、上記アクセスプール管理機能をもつパケット転送装置から、ＩＰアドレスを取得するようにしてもよい。

図１６は、本発明の第３実施例として、アクセス網ＮＷ１−１に所属する複数のパケット転送装置Ｂ１−１〜Ｂ１−３のそれぞれがサブアドレスプールを備え、各パケット転送装置が、自分のサブアドレスプールに空きＩＰアドレスが在る期間中は、自分のサブアドレスプールからユーザ端末にＩＰアドレスを割り当て、サブアドレスプール空きＩＰアドレスが無くなった時、アドレスプール管理サーバ１−１から、ユーザ端末に割り当てるべき新たなＩＰアドレスを取得するようにしたネットワーク構成を示す。

本実施例に適用されるパケット転送装置Ｂ１−１〜Ｂ１−３は、図２に破線ブロックで示したアドレスプール検索ルーチン３３と、アドレスプール管理テーブル３６を備える。アドレスプール管理テーブル３６は、アドレスプール管理サーバが備える図６に示したテーブルと同様のエントリからなる。

ここでは、ＩＳＰ１とアクセス網ＮＷ１−１を管理するキャリアＡとの間でのインターネット接続サービス契約において、第１実施例と同様、ＩＳＰ１からキャリアＡに「10.10.0.0」〜「10.10.3.255」の１０２４個のＩＰアドレスの運用を指示し、キャリアＡが、アクセス網ＮＷ１−１に配置されたパケット転送装置Ｂ１−１、Ｂ１−２、Ｂ１−３が備えるアドレスプール管理テーブル３６に、サブアドレスプールとして、それぞれ２５６個のＩＰアドレスを登録し、アドレスプール管理サーバ１が備えるアドレスプール管理テーブル７０に、サブアドレスプールとして２５６個のＩＰアドレスを登録した場合を想定する。

第３実施例では、各パケット転送装置Ｂ１−ｉ（ｉ＝１〜３）は、地域Ｓ１−ｉに位置したユーザ端末Ｈｉ−ｊ（ｊ＝ｎ、ｍ、ｋ）をインターネットに接続する時、自分が保有するアドレスプール管理テーブル３６から空きＩＰアドレスを選択して、ユーザ端末Ｈｉ−ｊに割り当てる。アドレスプール管理テーブル３６からの空きＩＰアドレスの検索と、テーブルエントリにおける配布先７０４の状態管理は、アドレスプール管理ルーチン３３によって行われる。もし、地域Ｓ１−ｉにおけるユーザ端末からのインターネット接続要求が増加し、パケット転送装置Ｂ１−ｉのサブアドレスプールで空きＩＰアドレスが枯渇した場合、パケット転送装置Ｂ１−ｉは、第１実施例で説明した手順に従って、アドレスプール管理サーバ１−１からＩＰアドレスを取得し、これをユーザ端末に割り当てる。

具体的に言うと、第３実施例のパケット転送装置は、図１１で説明したアクセス要求応答受信処理３４０において、加入者認証サーバから受信したアクセス要求応答メッセージのFramed-IP-Addressアトリビュートが特定値「255.255.255.254」を示していた場合（ステップ３４３でＹＥＳ）、アドレスプール検索ルーチン３３によって、アドレスプール管理テーブル３６からの空きアドレスを検索する。もし、空きアドレスが見つかれば、ステップ３５１に進んで、ユーザアドレス管理テーブルに上記ＩＰアドレスを登録し、空きアドレスが無かった場合に、ステップ３４６〜３５０を実行する。

第３実施例によれば、各地域Ｓ１−ｉで時間的に重複して発生するインターネット接続要求数が２５６以下の場合は、それぞれのパケット転送装置Ｂ１−ｉが独自にユーザ端末にＩＰアドレスを割り当てることができるため、インターネット接続サービスを迅速化できる。また、インターネット接続要求数が２５６を超えて、パケット転送装置Ｂ１−ｉのサブアドレスプールで空きＩＰアドレスが枯渇した場合、各パケット転送装置Ｂ１−ｉは、アドレスプール管理サーバ１−１から空きＩＰアドレスを取得できるため、最大で５１２台のユーザ端末に対して、インターネット接続サービスを提供できる。

上記説明では、アドレスプール管理サーバ１−１と各パケット転送装置Ｂ１−ｉのサブアドレスプールの容量（ＩＰアドレス数）を同一にしたが、パケット転送装置のサブアドレスプールは、地域毎に異なった容量にしてもよい。また、特定のパケット転送装置に空きＩＰアドレスが残っているにも関わらず、アドレスプール管理サーバ１−１のサブアドレスプールで空きＩＰアドレスが不足する事態を回避し、キャリアＡに委託された限定個数のＩＰアドレスを有効利用するためには、パケット転送装置Ｂ１−１〜Ｂ１−３が備えるサブアドレスプールに割り当てるＩＰアドレスの総数を減らして、アドレスプール管理サーバ１−１が備えるサブアドレスプールの登録ＩＰアドレス数を増加すればよい。

以上の実施例では、パケット転送装置とアクセスプール管理サーバとの通信にＲａｄｉｕｓプロトコルを適用したが、他のプロトコルを使用してもよい。また、以上の実施例では、パケット転送装置、アクセスプール管理サーバ、加入者認証サーバの間の通信パケットとして、ＩＰｖ４（Internet Protocol version 4）を適用したが、ＩＰｖ６（Internet Protocol version 6）を適用してもよい。ＩＰｖ６の場合、図８に示したFramed-IP-Addressアトリビュート１０４は、Framed-IPv6-Prefixアトリビュートに置き換えられる。

本発明のパケット転送装置が適用されるネットワーク構成の１例を示す図。 本発明のパケット転送装置の構成例を示すブロック図。 本発明のパケット転送装置が備える管理サーバアドレステーブルを示す図。 本発明のパケット転送装置が備えるユーザアドレステーブルの更新過程を説明するための図。 図１にけるアドレスプール管理サーバ１−１の構成例を示すブロック図。 アドレスプール管理サーバ１−１が備えるアドレスプール管理テーブルを説明するための図。 本発明のパケット転送装置によるユーザ端末へのアドレス割り当てに関する第１実施例を示すシーケンス図。 図７において、加入者認証サーバ（ＩＳＰ−ＲＡＤＩＵＳ）からパケット転送装置（ＢＡＳ）に送信される応答パケットのフォーマットを示す図。 図７において、パケット転送装置（ＢＡＳ）から加入者認証サーバ（ＩＳＰ−ＲＡＤＩＵＳ）に送信される課金開始要求パケットのフォーマットを示す図。 本発明のパケット転送装置で実行される接続制御ルーチン２２の１実施例を示すフローチャート。 図１０におけるアクセス要求応答受信処理３４０の詳細を示すフローチャート。 図１０における課金要求応答受信処理３６０の詳細を示すフローチャート。 アドレスプール管理サーバで実行されるサーバ間通信制御ルーチン７１の１実施例を示すフローチャート。 アドレスプール管理サーバで実行されるアドレスプール検索ルーチン７２の１実施例を示すフローチャート。 本発明のパケット転送装置によるユーザ端末へのアドレス割り当てに関する第２実施例を示すシーケンス図。 本発明のパケット転送装置の第３実施例を説明するためのネットワーク構成図。

符号の説明

Ｈ１−１〜Ｈ３−ｋ：加入者端末、１：アドレスプール管理サーバ、
Ｂ１−１〜Ｂ２−３：パケット転送装置、ＳＶ：加入者認証（Ｒａｄｉｕｓ）サーバ、
Ｒ１〜Ｒ５：ルータ、ＮＷ１−１、ＮＷ１−２：アクセス網、ＮＷ２：ＩＳＰ網、
ＮＷ３：インターネット、１１：回線インタフェース、１２：プロトコル処理部、
１３：ルーティングテーブル、１４：統計テーブル、２０：制御部、４０：制御端末、
２１、５１：プロセッサ、２２、５４：プログラムメモリ、２３、５３：データメモリ、３０：接続制御ルーチン、３１：ＰＰＰ ＬＣＰ／ＮＣＰ通信制御ルーチン、
３２：Ｒａｄｉｕｓ通信制御ルーチン、３３：アドレス検索ルーチン、３４：管理サーバアドレステーブル、３５：ユーザアドレス管理テーブル、
３６、７０：アドレスプール管理テーブル、５４：サーバ間通信制御ルーチン。

Claims (9)

1. 加入者認証サーバを含むインターネットサービスプロバイダ（ＩＳＰ）網に接続されたアクセス網内に位置し、複数のユーザ端末を上記ＩＳＰ網を介してインターネット網に接続するためのパケット転送装置であって、
   ユーザ端末との接続回線または上記ＩＳＰ網との接続回線に接続される複数の回線インタフェースと、制御部と、上記各回線インタフェースおよび上記制御部に接続され、これらの要素間で受信パケットを交換するプロトコル処理部とからなり、
   上記制御部が、
   ユーザ端末の識別子と割り当てＩＰアドレスとの関係を記憶するためのユーザアドレス管理テーブルと、
   インターネットへの接続を要求したユーザ端末について、上記加入者認証サーバとの間で認証手順を実行し、上記加入者認証サーバから、サブアドレスプールの適用指示を含む認証応答パケットを受信した時、上記アクセス網内に位置し、上記ＩＳＰ網で使用されるＩＰアドレス群の一部をＩＳＰから委託された上記アクセス網用のＩＰアドレスとしてサブアドレスプールに保持しているアドレスプール管理サーバに対して、上記ユーザ端末に割り当てるべきＩＰアドレスを要求し、該アドレスプール管理サーバから取得したＩＰアドレスを要求元ユーザ端末の識別子と対応させて上記ユーザアドレス管理テーブルに記憶するサーバ間通信制御手段と、
   上記ユーザ端末との間で、加入者認証のための通信手順を実行した後、該ユーザ端末から受信したＩＰアドレス要求パケットに応答して、上記ユーザアドレス管理テーブルが示す上記ユーザ端末識別子と対応するＩＰアドレスを通知する端末通信制御手段とを含むことを特徴とするパケット転送装置。
2. 前記サーバ間通信制御手段が、前記加入者認証サーバから受信する認証応答で指定されたサーバアドレスに従って、前記アドレスプール管理サーバに前記ユーザ端末に割り当てるべきＩＰアドレスを要求することを特徴とする請求項１に記載のパケット転送装置。
3. 前記制御部が、前記ＩＳＰ網の識別子とアドレスプール管理サーバのアドレスとの関係を示すサーバアドレステーブルを備え、
   前記サーバ間通信制御手段が、前記ユーザ端末の識別子に含まれるＩＳＰ網識別子に基づいて上記サーバアドレステーブルを参照し、前記ＩＰアドレスの要求先となるアドレスプール管理サーバのアドレスを特定することを特徴とする請求項１に記載のパケット転送装置。
4. 前記制御部が、前記ＩＳＰ網で使用可能な複数のＩＰアドレスをサブアドレスプールとして保持するためのアドレスプール管理テーブルを備え、上記加入者認証サーバから、サブアドレスプールの適用指示を含む認証応答を受信した時、上記アドレスプール管理テーブルから空き状態にあるＩＰアドレスを検索し、空きＩＰアドレスが見つかった場合は、該ＩＰアドレスを前記ユーザアドレス管理テーブルに記憶しておき、上記アドレスプール管理テーブルから空きＩＰアドレスが見つからなかった場合に、前記サーバ間通信制御手段によって、前記アドレスプール管理サーバからＩＰアドレスを取得することを特徴とする請求項１〜請求項３の何れかに記載のパケット転送装置。
5. 前記制御部が、前記ユーザ端末からインターネット接続の切断要求パケットを受信した時、前記サーバ間通信制御手段によって、前記アドレスプール管理サーバに、上記ユーザ端末に割り当てられたＩＰアドレスを解放するための要求パケットを送信することを特徴とする請求項１〜請求項３の何れかに記載のパケット転送装置。
6. 前記プロトコル処理部が、前記インターネット網に接続されたユーザ端末の課金情報の収集機能を有し、
   前記制御部が、前記ユーザ端末からインターネット接続の切断要求パケットを受信した時、上記プロトコル処理部から上記ユーザ端末の課金情報を回収し、前記サーバ間通信制御手段によって、上記課金情報を含む課金停止要求パケットを前記加入者認証サーバに送信することを特徴とする請求項１〜請求項３の何れかに記載のパケット転送装置。
7. 加入者認証サーバを含むインターネットサービスプロバイダ（ＩＳＰ）網に接続されたアクセスネットワークシステムであって、
   上記ＩＳＰ網を介してユーザ端末をインターネット網に接続するための複数のパケット転送装置からなるアクセス網と、
   上記アクセス網内に位置し、上記ＩＳＰ網で使用されるＩＰアドレス群の一部をＩＳＰから委託された上記アクセス網用のＩＰアドレス群として保持するためのアドレスプール管理テーブルを備えたアドレスプール管理サーバとからなり、
   上記パケット転送装置が、ユーザ端末との接続回線または上記ＩＳＰ網との接続回線に接続される複数の回線インタフェースと、制御部と、上記各回線インタフェースおよび上記制御部に接続され、これらの要素間で受信パケットを交換するプロトコル処理部とからなり、
   上記制御部が、ユーザ端末の識別子と割り当てアドレスとの関係を記憶するためのユーザアドレス管理テーブルと、上記アドレスプール管理サーバに対して、インターネットへの接続を要求したユーザ端末についての認証要求を送信し、上記アドレスプール管理サーバから上記認証要求に対する応答パケットを受信した時、該応答パケットから上記ユーザ端末に割り当てるべきＩＰアドレスを抽出し、該ＩＰアドレスを上記ユーザ端末の識別子と対応させて上記ユーザアドレス管理テーブルに記憶するサーバ間通信制御手段と、上記ユーザ端末との間で、加入者認証のための通信手順を実行した後、該ユーザ端末から受信したＩＰアドレス要求パケットに応答して、上記ユーザアドレス管理テーブルが示す上記ユーザ端末識別子と対応するＩＰアドレスを通知する端末通信制御手段とを有し、
   上記アドレスプール管理サーバが、上記パケット転送装置から受信した認証要求を上記加入者認証サーバに転送し、上記加入者認証サーバから、サブアドレスプールの適用指示を含む応答パケットを受信した時、上記アドレスプール管理テーブルから空きＩＰアドレスを検索し、該ＩＰアドレスを含む応答パケットを上記パケット転送装置に返送するサーバ間通信制御手段を有することを特徴とするアクセスネットワークシステム。
8. 前記パケット転送装置のプロトコル処理部が、前記インターネット網に接続されたユーザ端末の課金情報の収集機能を有し、前記制御部が、前記ユーザ端末からインターネット接続の切断要求パケットを受信した時、上記プロトコル処理部から上記ユーザ端末の課金情報を回収し、前記アドレスプール管理サーバに、上記課金情報を含む課金停止要求パケットを送信し、
   上記アドレスプール管理サーバが、上記課金停止要求パケットを前記加入者認証サーバに転送することを特徴とする請求項７に記載のアクセスネットワークシステム。
9. 前記アドレスプール管理サーバが、上記課金停止要求パケットに対する前記加入者認証サーバからの応答パケットを受信した時、前記ユーザアドレス管理テーブルが示す前記ユーザ端末識別子と対応するＩＰアドレスを空き状態に戻すことを特徴とする請求項８に記載のアクセスネットワークシステム。

Images