(57)【特許請求の範囲】
【請求項１】
着信端末を収容する第１のパケット転送装置と、ネットワークの入口に設けられた第２のパケット転送装置とからなるパケット転送システムにおいて、
前記第１のパケット転送装置は、受信したパケットのトラヒック量を監視し、前記トラヒック量が予め定められた量を超えたとき、そのパケットを異常と判断してトラヒック量に規制を加えて前記着信端末に転送し、前記第２のパケット転送装置に前記異常と判断したパケットに対する規制要求を送信し、
前記第２のパケット転送装置は、受信した規制要求に基づいて、前記異常と判断したパケットのトラヒック量に規制を加えて前記第１のパケット転送装置に転送し、
前記第１のパケット転送装置は、前記第２のパケット転送装置がトラヒック量に規制を加えたことを受けて、前記着信端末に転送するトラヒック量の規制を解除することを特徴とするパケット転送システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット転送装置およびパケット転送システムに係り、特にＰ２Ｐ通信を適用するパケット転送装置およびパケット転送システムに関する。
【背景技術】
【０００２】
近年、ブロードバンド回線の急激な普及や、それを利用するユーザの増加に伴い、ＩＰネットワークを流れるトラヒック量は日々増加の一途をたどり、非常に多くの帯域が使用されるようになってきている。
【０００３】
また、全世界の人々と手軽にファイルの共有が行える等の利点から、一般的なサーバ／クライアント型の通信形態ではなく、全てのコンピューターが対等に相互通信を行い、サービスを提供し合うＰ２Ｐ（peer-to-peer）型の通信形態を用いて情報のやり取りを行うユーザが増加している。
【０００４】
Ｐ２Ｐ型の通信形態でのファイルのやり取りにおいては、特にデータサイズの大きなマルチメディアファイル等が扱われる場合が多い。この結果、Ｐ２Ｐ型通信では、ＨＰ閲覧等の通信に比べて非常に大きな帯域を消費する。さらに、このＰ２Ｐ型通信によるトラヒックの増加は特に著しく、現在ではネットワーク全体を流れるトラヒックの中で、非常に大きな割合を占めるまでになっており、ネットワークに多大な影響を及ぼしている。
【０００５】
現在のネットワーク形態は、共有リソースを早い者勝ちで使用できるベストエフォート型が主流である。しかし、ベストエフォート型であることを利用して、Ｐ２Ｐ型通信で大量のデータをやり取りする一部のユーザが存在する。ネットワーク上の帯域を、この大量データのトラヒックが占領してしまい、他のユーザの使用できる帯域が少なくなってしまうという問題が起こっている。
【０００６】
これらの、異常トラヒックを監視し、規制を行う場合、次のような方法が検討されている。
特許文献１に記載された発明は、ネットワーク上のトラヒックの監視や、規制を行う場合、通常のネットワーク設備とは別に、監視サーバを設置する。この監視サーバが、ネットワーク上の各ルータを流れる異常トラヒックの監視を行い、それらの異常トラヒックに対する規制を各ルータに指示する。
【０００７】
特許文献２に記載された発明は、同様にサーバを用いてトラヒックの監視等を行う。特許文献１との違いは、複数の管理サーバを用いて、処理を分散させ、ネットワーク上のトラヒックの監視を行う点である。
【０００８】
【特許文献１】特開２００３−２９８６３１号公報
【特許文献２】特開２００１−１４４７６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、特許文献１または特許文献２に記載された技術では、本来必要としない設備投資が必要となる。さらに、サーバで集約的に、多数のルータごとのセッション監視、データ収集等をする方法では、ネットワークや各装置に非常に大きな負荷が加わるという問題がある。
【００１０】
また、ＩＳＰ(Internet Service Provider)網に属するユーザを収容しているルータにおいて、そのユーザに対して送られてきた大量のトラヒックを規制したとしても、そのルータまでは依然として、ＩＳＰが管理しているネットワークを通って、ルータで廃棄されてしまう等の、無駄なトラヒックが流れ込み、ネットワークのリソースを占有してしまう。
【課題を解決するための手段】
【００１１】
ユーザを収容しているルータが自律的に、異常トラヒックの検知を行い、自身を流れるトラヒックの規制を行う。ルータは、その異常トラヒックの流れている経路の探索を行い、経路上離れた他のルータに対して規制要求を行う。
規制を要求されたルータが、該当の異常トラヒックに対する規制および、規制解除の判定を行う。
また、経路の変更によって通過する可能性のあるルータに対しても規制の要求を行う。
【発明の効果】
【００１２】
ＩＳＰ網の入口のルータに対して規制の要求を行い、ＩＳＰ網の入口でトラヒックに対する規制を行うため、ＩＳＰ網の中を流れる無駄なトラヒックも削減することが出来る。
【発明を実施するための最良の形態】
【００１３】
以下本発明の実施の形態に付いて、実施例を用いて図面を参照しながら説明する。なお、実質的に同一の部位には同じ参照番号を付与し、説明を繰り返さない。また、以下の実施例では、理解を容易とするため、ユーザを収容するルータをアクセスサーバ、トラヒック規制機能を有するルータを規制ルータと呼ぶことにする。
【実施例１】
【００１４】
実施例１を、図１ないし図１４を用いて説明する。ここで、図１は、実施例１を適用するネットワークを説明するブロック図である。図１のネットワーク１０００には、ユーザ端末４、５が接続されている。ネットワーク１０００は、ユーザ端末を収容しパケット転送機能を有する２台のアクセスサーバ（ＡＳ）１０、４０、トラヒック規制機能を持ったパケット転送装置（ルータ）である２台の規制ルータ（Restriction RouTer：ＲＲＴ）２０、トラヒック規制機能を持たないパケット転送装置であるルータ（ＲＴ）３０で構成されている。ここで、アクセスサーバ１０およびルータ３０−１〜３０−７が属するネットワークは、ＩＳＰが管理するＩＳＰ網３００である。また、ルータ３０−８、３０−９、アクセスサーバ４０の属するネットワークは、一般的なＩＰ網４００である。
【００１５】
また、図１中の矢印は、発信端末５から着信端末４まで、アクセスサーバ４０、ルータ３０−９、規制ルータ２０−１、ルータ３０−３、ルータ３０−２、ルータ３０−１、アクセスサーバ１０を通って、Ｐ２Ｐ通信のトラヒックが流れることを示す。
【００１６】
図２は、アクセスサーバの構成を説明するブロック図である。アクセスサーバ１０は、ｎ式の入出力回線の回線インタフェース１１−１〜１１−ｎと、プロトコル処理部１２と、プロトコル処理部を制御する制御部１３から構成されている。また、アクセスサーバ１０には、制御端末１４が接続されている。
【００１７】
制御部１３はプロトコル処理部１２の状態を監視し、その状態を制御端末１４に通知する。制御部１３は、また、制御端末１４からの指示に応答して、プロトコル処理部１２への各種制御パラメータ設定を行う。制御部１３は、さらに、プロトコル処理部１２から受信したフレームを出力ポートが存在する回線インタフェース１１−１〜１１−ｎへ転送する。
【００１８】
プロトコル処理部１２は、回線インタフェース１１−１〜１１−ｎからフレームを受け取るための回線側受信バッファ１２１、フレームを回線インタフェース１１−１〜１１−ｎに送信するための送信バッファ１２２、プロセッサ間インタフェース１２５、複数の処理プログラムと複数のテーブルを格納するメモリ１２４、処理プログラムを実行するプロセッサ１２３からなる。
【００１９】
メモリ１２４は、プロセッサ１２３にて実施する処理プログラムとして、トラヒックの規制を行う規制制御処理プログラム１２４１、異常トラヒックの監視を行うトラヒック監視処理プログラム１２４２、異常トラヒックが流れる経路を特定する経路探索処理プログラム１２４３、規制用プロトコル処理プログラム１２４４が格納されている。また、メモリ１２４は、規制ルータ２０のＩＰアドレスを登録するための規制ＲＴアドレステーブル１２４５と、規制を要求するルータのグループのＩＰアドレスを登録するための同時規制ＲＴテーブル１２４６と、規制を要求する際に指定する規制帯域、規制解除判定帯域、規制解除判定時間を設定しておく規制情報テーブル１２４７と、パケット転送に用いるルーティングテーブル１２４８が格納されている。
なお、ＩＰ網４００に接続されたアクセスサーバ４０は、この構成である必要はない。
【００２０】
図３は、規制ルータの構成を説明するブロック図である。規制ルータ２０はｍ式の入出力回線の回線インタフェース１１−１〜１１−ｍと、プロトコル処理部２２と、プロトコル処理部を制御する制御部２３から構成されている。また、規制ルータ２０には、制御端末１４が接続されている。
【００２１】
制御部２３はプロトコル処理部２２の状態を監視し、その状態を制御端末２４に通知する。制御部２３は、また、制御端末２４からの指示に応答して、プロトコル処理部２２への各種制御パラメータ設定を行う。制御部２３は、さらに、プロトコル処理部２２から受信したフレームを出力ポートが存在する回線インタフェース１１−１〜１１−ｍへ転送する。
【００２２】
プロトコル処理部２２は、回線インタフェース１１−１〜１１−ｍからフレームを受け取るための回線側受信バッファ２２１、フレームを送信するための送信バッファ２２２、とプロセッサ間インタフェース２２５と、複数の処理プログラムと複数のテーブルを格納するメモリ２２４と、処理プログラムを実行するプロセッサ２２３からなる。
【００２３】
メモリ２２４には、プロセッサ２２３にて実施する処理プログラムとして、規制用プロトコル処理プログラム２２４１と、規制の実施や規制解除判定を行う規制制御処理プログラム２２４２と、トラヒックの監視を行うトラヒック監視処理プログラム２２４３と、ルートの有無を監視するルート監視処理プログラム２２４４が格納されている。また、メモリ２２４には、規制設定情報を格納するための規制設定テーブル２２４５と、ルートの監視に使用するルーティングテーブル２２４６が格納されている。
【００２４】
図４は、アクセスサーバが保持する規制ルータのＩＰアドレスを登録するテーブルを説明する図である。テーブル１２４５には、ＩＳＰ網３００の複数の規制ルータのＩＰアドレスを格納する。テーブル１２４５には、規制ルータ２０−１のＩＰアドレス「１０.１０.０.４」と、規制ルータ２０−２のＩＰアドレス「１０.１０.０.５」が登録されている。
【００２５】
図７は、発信端末と着信端末と各転送装置との間の規制開始までのシーケンス図である。まず、前提として、ＩＳＰ網３００の保守者が、アクセスサーバ１０に対して、規制ルータのＩＰアドレスを登録する。また、ＩＳＰ網３００の保守者が、アクセスサーバ１０に対して、規制ルータ２０に規制を要求する際に、送信する規制情報となる規制帯域値、規制解除判定帯域値、規制解除判定時間を登録する（Ｓ７０１）。登録されたＩＰアドレスは、規制ＲＴアドレステーブル１２４５に保持される。登録された規制情報は、規制情報テーブル１２４７に保持される。
【００２６】
図７のシーケンスにおいて、発信端末５から、着信端末４に向かって、大量のトラヒックが流れたとする（Ｓ７０２）。なお、ここで矢印の太さでトラヒック量を示している。アクセスサーバ１０は、この大量のトラヒックを検知し、このトラヒックに規制をかける（Ｓ７０３）。
【００２７】
ステップ７０３を、図８を用いて詳述する。ここで、図８はアクセスサーバにおける異常トラヒック検知および規制を行う処理フロー図である。アクセスサーバ１０のプロトコル処理プロセッサ１２３は、トラヒック監視処理プログラム１２４２の実行により、トラヒックの監視を行う（Ｓ８１）。プロトコル処理プロセッサ１２３は、異常トラヒックの判定を行う（Ｓ８２）。異常トラヒックを検知した場合、プロトコル処理プロセッサ１２３は、規制制御プログラム１２４１の実行により、該当トラヒックに対して規制を開始し（Ｓ８３）、終了する。ステップ８２で異常トラヒックを検知しない場合は、ステップ８１に戻り、監視を継続する。
【００２８】
図７に戻って、異常トラヒックに規制が掛けられた結果、アクセスサーバ１０から、着信端末４へ流れるトラヒックが規制される（Ｓ７０４、Ｓ７０５）。ここで規制とは、着信端末４に転送するパケット数を減らす処理である。次に、アクセスサーバ１０は、異常トラヒックの送信元アドレスを用い、該当の異常トラヒックが流れる経路を探索する。
【００２９】
具体的には、アクセスサーバ１０は、アクセスサーバ１０に異常トラヒックを転送したルータ３０−１に、送信元アドレスをキーとして、ルータ３０−１に異常トラヒックを転送した装置を問合せる（Ｓ７１０）。ルータ３０−１は、応答メッセージで転送元ルータ３０−２のＩＰアドレスを返信する（Ｓ７１０）。アクセスサーバ１０は、送信元アドレスと転送装置のアドレスを比較しながら、同様にルータ３０−２（Ｓ７１２）、３０−３（Ｓ７１４）、規制ルータ２０−１（Ｓ７１６）、図示しないルータ３０−９（Ｓ７１８）、アクセスサーバ４０（Ｓ７２０）に転送元を問合せる。各転送装置は、それぞれ応答し（Ｓ７１３、Ｓ７１５、Ｓ７１７、図示しないＳ７１９、Ｓ７２１）、アクセスサーバ１０は、発信元アドレスが、発信端末５のアドレスであることを検出する。
【００３０】
アクセスサーバ１０は、通信経路で最も遠い転送装置である発信端末５を収容するアクセスサーバ４、ルータ３０−９、規制ルータ２０−１の順に、各装置のＩＰアドレスと、図４に示す規制ＲＴアドレステーブル１２４５に記載された各ＩＰアドレスとを比較する。この結果、アクセスサーバ１０は、規制ルータ２０−１が、通信経路の最も遠い位置に配置された規制可能な転送装置と判断する（Ｓ７３０）。
【００３１】
アクセスサーバ１０は、規制ルータ２０−１に異常トラヒックの規制要求を送信する（Ｓ７３１）。規制ルータ２０−１は、アクセスサーバ１０からの規制要求を受信し、規制処理を開始する（Ｓ７３２）。規制ルータ２０−１は、アクセスサーバ１０にＡＣＫ応答を返信する（Ｓ７３３）。規制ルータ２０−１からの、ＡＣＫ応答を受信したアクセスサーバ１０は、トラヒックに対する着信端末５への転送規制を解除する（Ｓ７３４）。アクセスサーバ１０にＡＣＫ応答を返信した規制ルータ２０−１は、流入するトラヒック量の監視を開始する（Ｓ７３５）。ステップ７３２以降、発信端末から送信されたデータトラヒックは、規制ルータ２０−１で規制され、ＩＳＰ網３００に流れるトラヒックが大幅に減少する（Ｓ７４０、Ｓ７４１）。なお、ステップ７３４とステップ７３５の順序は逆であってもよい。
【００３２】
図９は、アクセスサーバの規制ルータに対して規制要求を行う処理のフロー図である。図９において、アクセスサーバ１０は、まず、経路探索の結果より、最も遠い位置にあるルータのアドレスを取得する（Ｓ９１）。このルータのアドレスを、図２の規制ＲＴアドレステーブル１２４５と比較する（Ｓ９２）。もし、一致するアドレスがなかった場合は、経路上全てのルータを比較したかを判定する（Ｓ９７）。ステップ９７で、全て比較した場合は（ＹＥＳ）終了し、まだ比較完了していない場合（ＮＯ）は、次に遠いルータのアドレスを取得し（Ｓ９８）、ステップ９２に戻る。
【００３３】
ステップ９２において、規制ＲＴアドレステーブル１２４５の中に、一致するアドレスがあるなら、そのアドレスの規制ルータ２０に対して規制要求を送信する（Ｓ９３）。規制ルータ２０から戻ってくる応答を判定し（Ｓ９４）、ＮＡＣＫ（Not ACKnowleged）もしくはタイムアウトの場合は、ステップ９７へ進む。ステップ９４で、応答がＡＣＫ（ACKnowlege）の場合はステップ９５へ進む。ここでは、ステップ９５でＮＯとなり、終了する。なお、ステップ９５とステップ９６は、実施例３で説明する。
なお、規制ルータ２０は規制要求に対して、原則的にはＡＣＫを応答するが、保守者の設定によっては、ＮＡＣＫを応答することもできる。
【００３４】
図５を参照して、パケット転送装置間で使用するメッセージのフォーマットを説明する。ここで、図５（ａ）は、パケット転送装置間で使用される規制制御に関する要求メッセージフレームのフォーマット１００である。要求フォーマット１００は、ＩＰヘッダ１０１と、メッセージのタイプ（規制要求、規制解除要求、規制解除通知、ルート切断通知等）を表すＴＹＰＥ１０２と、情報を識別するためのＩＤ１０３と、情報長を表すＬＥＮ１０４と、規制対象トラヒックの送信端末のＩＰアドレス１０５と、規制対象トラヒックの受信端末のＩＰアドレス１０６と、規制帯域１０７と、規制解除判定帯域１０８と、規制解除判定時間１０９と、主規制対象ＲＴアドレス１１０と、誤り検出用のＦＣＳ（Frame Check Sequence）１１１から構成されている。
【００３５】
一方、図５（ｂ）は、送られてきた要求メッセージに対する応答メッセージフレームのフォーマット２００である。応答フォーマット２００は、ＩＰヘッダ２０１と、メッセージのタイプ（規制要求に対する応答、規制解除要求に対する応答、規制解除通知に対する応答等）を表すＴＹＰＥ２０２と、規制情報を識別するためのＩＤ２０３と、情報長を表すＬＥＮ２０４と、要求に対して受諾するか拒否するかを示すＡＣＫ/ＮＡＣＫ２０５と、ＦＣＳ２０６から構成されている。
【００３６】
図７のステップ７３０では、経路情報として得た、規制ルータ２０−１のＩＰアドレスである「１０.１０.０.４」と、テーブル１２４５に登録してあったＩＰアドレス「１０.１０.０.４」がマッチする。そのため、アクセスサーバ１０は規制ルータ２０−１に対して、規制要求を行う（Ｓ７３１）。この時、図５（ａ）の要求フォーマット１００を用いて、ＴＹＰＥ１０２を規制要求に設定し、送信元アドレス１０５には発信端末５のＩＰアドレス、受信先アドレス１０６には着信端末４のＩＰアドレスを格納し、規制帯域１０７、規制解除判定帯域１０８、規制解除判定時間１０９には保守者によって予めアクセスサーバ１０の規制情報テーブル１２４７設定されている値を格納して、主規制対象ＲＴアドレス１１０に規制ルータ２０−１のＩＰアドレスを格納したメッセージを送信する。
【００３７】
図６は、規制ルータが保持する規制設定テーブルの構成を説明する図である。規制制御情報設定テーブル２２４５は、規制を行うトラヒックを送信する端末のＩＰアドレス２３１と、規制を行うトラヒックを受信する端末のＩＰアドレス２３２と、規制帯域２３３と、規制解除判定帯域２３４と、規制解除判定時間２３５と、主たる規制対象のルータのＩＰアドレスである主規制対象ＲＴＩＰアドレス２３６から構成される。なお、ここでは規制ルータ２０−１は、主規制対象ＲＴアドレス２３６に自分自身のＩＰアドレスを記録することになる。「主たる規制対象ルータ」については、実施例３で説明する。
【００３８】
図１０は、規制ルータがクセスサーバからの規制要求または規制解除要求メッセージを受け取った際の処理のフロー図である。規制ルータ２０は、要求を受信（Ｓ１０１）すると、要求メッセージのＴＹＰＥ１０２を参照し、タイプ判別を行う（Ｓ１０２）。規制要求の場合、規制ルータ２０は受諾するかの判定を行い（Ｓ１０３）、拒否する場合は図５（ｂ）の応答フォーマット２００のＡＣＫ/ＮＡＣＫ２０５をＮＡＣＫに設定した応答メッセージをアクセスサーバ１０に対して送信して（Ｓ１０４）、終了する。
【００３９】
ステップ１０３で、規制要求を受諾する場合、規制ルータ２０は、図６を用いて説明した規制設定テーブル２２４５に、規制要求メッセージの内容を登録し、送信元ＩＰアドレス２３１から、受信先ＩＰアドレス２３２へ流れるパケットのうち、規制帯域２３３以上のパケットを破棄する処理を開始する（Ｓ１０５）。次に、規制ルータ２０は、ＡＣＫ応答を返信する（Ｓ１０６）。規制ルータ２０は、規制設定テーブル２２４５の主規制対象ルータのＩＰアドレス２３６が、自身に設定されているＩＰアドレスと同じであるか判定を行う（Ｓ１０７）。ここでは同じであるので、規制ルータ２０は、流入トラヒック監視を開始し（Ｓ１０８）、終了する。また、ステップ１０７がＮＯなら、規制ルータ２０は、そのまま終了する。なお、ステップ１０７およびステップ１０８は後述する実施例３で詳述する。
【００４０】
ステップ１０２で、受け取った要求のタイプが規制解除要求の場合、規制ルータ２０は受諾するかの判定を行い（Ｓ１０９）、拒否する場合はＮＡＣＫ応答メッセージをアクセスサーバ１０に対して送信して（Ｓ１１０）、終了する。ステップ１０９で、規制解除要求を受諾する場合、規制ルータ２０は、ＡＣＫ応答を返信する（Ｓ１１１）。次に、規制ルータ２０は、規制設定テーブル２２４５の該当レコードをクリアして、規制を解除し（Ｓ１１２）、終了する。ここで、規制開始／解除とＡＣＫ応答の順序が、規制開始（Ｓ１０５）と規制解除（Ｓ１１２）とで異なる。
なお、規制ルータ２０は規制要求に対して、原則的にはＡＣＫを応答するが、保守者の設定によっては、ＮＡＣＫを応答することもできる。
【００４１】
図１１は規制ルータが送受信するトラヒックを説明する図である。図１１（ａ）は、ＩＰ網４００側から、規制ルータ２０−１に流入してくるトラヒック量を説明する図である。また、図１１（ｂ）は、規制ルータ２０−１から、ＩＳＰ網３００に流すトラヒック量を説明する図である。
【００４２】
図１１（ｂ）において、規制ルータ２０−１に於ける発信端末から受信端末へ流れるトラヒックは、一旦ＩＳＰ網３００内に流れ込む。これを検出したアクセスサーバ１０からの規制要求によって、規制ルータ２０−１がＩＳＰ網３００に流すトラヒック量を規制する。一方、図１１（ａ）において、トラヒック量を規制している規制ルータ２０−１は、トラヒック監視処理プログラム２２４３を実行し、トラヒック量が、規制帯域以下に設定された規制解除判定帯域以下の継続時間が、予め定めた規制解除判定時間以上になったとき、規制を解除する。なお、規制解除判定帯域と規制解除判定時間は、図６で説明した規制設定テーブル２２４５を参照する。
【００４３】
図１２を用いて、この規制解除の手順を説明する。ここで、図１２は、規制を実施中の規制ルータが規制を解除するまでのシーケンス図である。図１２は、図７のシーケンスに引き続くものである。図７のステップ７３５で開始した流入トラヒックの監視は、図１２のステップ７５０において継続されている。発信端末５からの流入トラヒック量が、規制解除判定帯域を超えているときには（Ｓ７５１）、規制ルータ２０−１は、規制を継続する（Ｓ７５２）。
【００４４】
その後、発信端末５からの流入トラヒック量が、規制解除判定帯域以下となったとする（Ｓ７５３）。規制解除判定帯域は、規制帯域以下に設定されているので、規制ルータ２０−１は、結果的に規制をかけずに着信端末４に転送する（Ｓ７５４）。規制ルータ２０−１は、規制解除を判定する（Ｓ７５５）。解除と判定した規制ルータ２０−１は、アクセスサーバ１０に対して、図５（ａ）の要求フォーマット１００を用いて、ＴＹＰＥ１０２を規制解除通知に設定し、送信元アドレス１０５には発信端末５のＩＰアドレス、受信先アドレス１０６には着信端末４のＩＰアドレスを格納したメッセージを送信する（Ｓ７５６）。
【００４５】
規制ルータ２０−１からの規制解除通知メッセージを受信したアクセスサーバ１０は、規制解除通知受諾判定を行う（Ｓ７５７）。受諾を判断したアクセスサーバ１０は、ＡＣＫ応答を送信する（Ｓ７５８）。アクセスサーバ１０からのＡＣＫ応答を受信した規制ルータ２０−１は、規制制御情報設定テーブル２２４５に登録してある、該当トラヒックの情報を削除し、該当トラヒックに対する規制を解除する（Ｓ７５９）。
【００４６】
図１３は、規制ルータに於ける、規制を解除するまでの処理を説明するフロー図である。規制ルータ２０−１は規制中のトラヒックの流入トラヒック量の監視を行い（Ｓ１３１）、規制解除条件を満たしたかの判定を行う（Ｓ１３２）。ここで規制解除条件とは、流入トラヒック量が、規制設定テーブル２２４５（図６）の規制解除判定帯域２３４以下の期間が規制解除判定時間２３５以上継続することである。ステップ１３２で、ＮＯならばＳ１３１に戻る。一方、ステップ１３２で、ＹＥＳならば、アクセスサーバ１０に対して、規制解除通知を送信する（Ｓ１３３）。具体的には、図５（ａ）の要求フォーマット１００において、ＴＹＰＥ１０２を規制解除通知に設定し、送信元アドレス１０５には発信端末５のＩＰアドレス、受信先アドレス１０６には着信端末４のＩＰアドレスを格納したメッセージを送信する。
【００４７】
規制ルータ２０−１は、アクセスサーバ１０からの応答を判定し（Ｓ１３４）、ＮＡＣＫまたはタイムアウトの場合はＳ１３３に戻り、規制解除通知を再送する。ステップ１３４で、ＡＣＫまたはリトライアウト（規制解除通知の再送が規定回数を超える）の場合は、規制制御情報設定テーブル２２４５に登録してある該当トラヒックに対する情報を削除し規制処理を解除し（Ｓ１３５）、終了する。なお、アクセスサーバ１０の応答は、通常ＡＣＫである。
【００４８】
図１４は、アクセスサーバに於ける規制ルータから規制解除通知を受け取った際の処理を説明するフロー図である。アクセスサーバ１０は、規制解除通知を受信し（Ｓ１４１）、受諾するかの判定を行う（Ｓ１４２）。受諾しない場合はＮＡＣＫ応答を返信し（Ｓ１４３）、終了する。ステップ１４２で受諾する場合は、ＡＣＫ応答を返信する（Ｓ１４４）。次に、ステップ１４５にて、同じグループに属する他の規制ルータがあるか判定する。ここでは、ＮＯなので終了する。なお、ステップ１４５ないしステップ１４７は、実施例３で説明する。
【００４９】
本実施例に拠れば、予め経路上に存在する規制ルータ２０のＩＰアドレスがアクセスサーバ１０に登録されているので、簡便な手順でＩＳＰ網の入口で規制をかけることが可能である。
【００５０】
なお、アクセスサーバ１０、規制ルータ２０、ルータ３０はいずれもパケット転送装置（ルータ）である。また、アクセスサーバ１０を、規制ルータ２０またはルータ３０として使用することもできる。これは、本明細書の他の実施例でも同様である。
【実施例２】
【００５１】
実施例１は、ＩＳＰ網の保守者が、予め経路上に存在する規制ルータのＩＰアドレスをアクセスサーバ１０に登録することを前提とした実施例であった。一方、実施例２では、ＩＳＰ網の保守者が、規制ルータのＩＰアドレス登録テーブルに情報を登録しなかった場合、または、経路上の全ルータのアドレスが、規制ルータのＩＰアドレス登録テーブルに登録されたＩＰアドレスとマッチしなかった場合にも、規制を可能とする実施例である。以下、図１５および図１６を用いて、実施例２を説明する。ここで、図１５は、規制ルータが規制を実施するまでのシーケンス図である。また、図１６は、アクセスサーバの規制要求を行う処理のフロー図である。
【００５２】
図１５は、実施例１の図７に相当するシーケンス図である。しかし、図７のステップ７０１は、不要である。アクセスサーバ１０が異常トラヒックを検出し、規制をかけるステップ（Ｓ７０３）、経路探索をするステップ（Ｓ７１０〜Ｓ７２１）は、図１５も共通である。また、図９で説明した、取得した経路上のルータのアドレスと、規制ルータのＩＰアドレス登録テーブル１２４５のＩＰアドレスとの比較において、ひとつもマッチしなかったとする（Ｓ７７０）。このとき、アクセスサーバ１０は、図１６で説明する処理フローに従い、経路探索により取得したルータのＩＰアドレスの中で、最も遠いアクセスサーバ４０のアドレス宛に、図５（ａ）の要求フォーマット１００を用いて、ＴＹＰＥ１０２を規制要求に設定したメッセージを送信する（Ｓ７７１）。この時、送信元アドレス１０５には発信端末５のＩＰアドレス、受信先アドレス１０６には着信端末４のＩＰアドレスを格納する。また規制帯域１０７、規制解除判定帯域１０８、規制解除判定時間１０９にはアクセスサーバ１０に保守者によって予め設定されている値を格納し、主規制対象ＲＴアドレス１１０には経路上最も遠いルータであるアクセスサーバ４０のＩＰアドレスを格納する。
【００５３】
規制要求を受け取ったアクセスサーバ４０はトラヒック規制機能を持たないルータのため、応答を返さない。
アクセスサーバ１０は、一定時間経過後、タイムアウトと判定し、次に遠いルータ３０−９に対して、主規制対象ＲＴアドレス１１０にルータ３０−９のＩＰアドレスを格納した規制要求メッセージを送信して、規制要求を行う（Ｓ７７２）。しかし、ルータ３０−９もトラヒック規制機能を持たないルータのため、応答を返さない。
【００５４】
アクセスサーバ１０は、タイムアウトと判定し、次に遠い規制ルータ２０−１に対して、主対象規制ＲＴアドレス１１０に規制ルータ２０−１のＩＰアドレスを格納した規制要求メッセージを送信する（Ｓ７７３）。このように、アクセスサーバ１０は、ＡＣＫ応答を返すルータが現れるまで、経路上の遠い順に、規制要求メッセージを送信していく。
【００５５】
規制ルータ２０−１は、規制機能付のルータであるため、図１０の処理フローに従い、要求メッセージを判別し、受諾する場合は規制を開始する（Ｓ７７４）。規制ルータ２０−１は、アクセスサーバ１０にＡＣＫ応答を返信する（Ｓ７７５）。アクセスサーバ１０は、規制ルータ２０−１からのＡＣＫ応答を受信したため、規制ルータ２０−１より近い位置のルータへの規制要求は行わない。アクセスサーバ１０は、自分自信の規制を解除する（Ｓ７７６）。ＡＣＫ応答を送信した規制ルータ２０−１は、主対象規制ＲＴアドレスに自身のＩＰアドレスが指定されているために、解除判定処理（流入トラヒックの監視）を開始する（Ｓ７７７）。なお、ステップ７７６とステップ７７７の順序は不同である。
以上のシーケンスによって、発信端末５から受信端末４へ流れるトラヒックは、ＩＳＰ網３００内に流れ込む前に制限される（Ｓ７８０、Ｓ７８１）。
【００５６】
図１６において、アクセスサーバ１０は、経路探索の結果より最も遠い位置にあるルータのアドレスを取り出す（Ｓ１６１）。アクセスサーバ１０は、このＩＰアドレスのルータに、規制要求を送信する（Ｓ１６２）。アクセスサーバ１０は、応答を判定し（Ｓ１６２）、ＮＡＣＫもしくはタイムアウトの場合は、経路上全てのルータに対して規制要求したかを判定する（Ｓ１６４）。経路上の全てのルータに規制要求した場合（ＹＥＳ）は終了する。ステップ１６４で、まだ経路上の全てのルータに規制要していない場合（ＮＯ）は、次に遠いルータのアドレスを取り出し（Ｓ１６５）、ステップ１６２に戻る。ステップ１６３において、ＡＣＫ応答を受信した場合は、該当ルータで規制が行われたので、終了する。  実施例２において、規制を解除するシーケンスおよび処理は実施例１の場合と同様である。
本実施例に拠れば、予め経路上に存在する規制ルータ２０のＩＰアドレスがアクセスサーバ１０に登録されていなくとも、簡便な手順でＩＳＰ網の入口で規制をかけることが可能である。
【実施例３】
【００５７】
実施例１および実施例２は、経路上の規制ルータ２０−１が規制を行う実施例である。このため、ネットワーク上の何らかの障害によって通信経路が変更され、規制ルータ２０−１を通らなくなった場合、異常トラヒックがＩＳＰ網３００を通って、再び着信端末４まで流れ込んでしまう。
【００５８】
実施例３は、経路上の規制ルータ２０−１（主規制対象ルータ）において規制を行うと同時に、経路変更によって通る可能性のある他のルータ（従規制ルータ２０−２）においても、同時に規制を行う実施例である。これによって、ネットワーク上の何らかの障害によって通信経路が変更されても、ＩＳＰ網３００内に異常トラヒックが流れるのを防ぐことができる。以下図１７ないし図２５および実施例１で説明した各図を参照しながら、実施例３を説明する。
【００５９】
図１７は、実施例３を適用するネットワークを説明するブロック図である。図１７のネットワーク１０００の構成は図１のネットワーク１０００の構成と同じである。図１７の太い点線は、規制ルータ２０−１とルータ３０−９の間で障害が発生した場合に、発信端末５と着信端末４間のトラヒックが、規制ルータ２０−１ではなく、規制ルータ２０−２を迂回して通る場合の経路を表す。
【００６０】
図１８は、発信端末と着信端末と各転送装置との間の規制開始までのシーケンス図である。図１８は、実施例１の図７に相当するシーケンス図である。ＩＳＰ網３００の保守者が、アクセスサーバ１０に対して、規制ルータ２０のＩＰアドレス、規制ルータ２０に規制を要求する際に、送信する規制情報となる規制帯域値、規制解除判定帯域値、規制解除判定時間を登録する（Ｓ７０１’）。登録されたＩＰアドレスは、規制ＲＴアドレステーブル１２４５および同時規制ＲＴテーブル１２４６に保持される。登録された規制情報は、規制情報テーブル１２４７に保持される。アクセスサーバ１０が異常トラヒックを検出し、規制を開始するステップ（Ｓ７０３）、経路探索をするステップ（Ｓ７１０〜Ｓ７２１）は、図１８も共通である。また、実施例１と同様に、アクセスサーバ１０は、規制ルータ２０−１が、通信経路の最も遠い位置に配置された規制可能な転送装置と判断する（Ｓ７３０）。さらに、図７のステップ７３１ないしステップ７３５も同様である。この結果、ステップ７３２以降、発信端末から送信されたデータトラヒックは、規制ルータ２０−１で規制され、ＩＳＰ網３００に流れるトラヒックが大幅に減少する（Ｓ７４０、Ｓ７４１）。なお、図１８において、規制ルータ２０−２に引かれた縦線が破線となっているのは、規制ルータ２０−２が通信経路上に無いことを意味する。
【００６１】
ここで一旦図２０に移って、図２のアクセスサーバ１０のメモリ１２４が保持するテーブルを説明する。ここで、図２０Ａは、規制ＲＴアドレステーブルを説明する図である。また、図２０Ｂは、同時規制ＲＴテーブルを説明する図である。
【００６２】
図２０Ａにおいて、規制ルータのＩＰアドレスを登録するためのテーブル１２４５’は、図４の規制ＲＴアドレステーブル１２４５に、そのルータの属するグループを示すグループＩＤ欄２４２を追加したテーブルである。ＩＰアドレス欄２４１には、規制ルータのＩＰアドレスを格納する。また、グループＩＤ２４２欄には、各ルータの属するグループのＩＤを格納する。
【００６３】
図２０Ａには、規制ルータ２０−１のＩＰアドレス「１０.１０.０.４」と、規制ルータ２０−２のＩＰアドレス「１０.１０.０.５」が登録されている。また、規制ルータ２０−１と２０−２のグループＩＤ欄２４２は、いずれも「１」が登録されている。一方、ＩＰアドレス「ｘｘ.ｘｘ.ｘ.ｃ」「ｘｘ.ｘｘ.ｘ.ｄ」の規制ルータのグループＩＤ欄２４２は、いずれも「２」が登録されている。
【００６４】
図２０Ｂは、各グループＩＤに所属している全てのルータのアドレスリストテーブル１２４６である。アドレスリストテーブル１２４６は、各グループＩＤに所属しているルータのアドレスリストテーブルである。アドレスリストテーブル１２４６には、グループＩＤ欄２５１にグループＩＤを格納し、ＩＰアドレス欄２５２に、各ＩＤグループに所属する複数の規制ルータのアドレスリストを格納する。
【００６５】
図２０ＢのグループＩＤ「１」の欄には、規制ルータ２０−１と規制ルータ２０−２のＩＰアドレスである「１０.１０.０.４」と「１０.１０.０.５」が登録されている。また、グループＩＤ「２」の欄には、ＩＰアドレス「ｘｘ.ｘｘ.ｘ.ｃ」「ｘｘ.ｘｘ.ｘ.ｄ」が登録されている。
【００６６】
図１８に戻って、ステップ７３４で規制を解除したアクセスサーバ１０は、規制ＲＴアドレステーブル１２４５を参照して、規制ルータ２０−１のグループＩＤ（この場合「１」）を取得する。アクセスサーバ１０は、続けて同時規制ＲＴテーブル１２４６を参照し、グループＩＤが「１」の全てのルータのＩＰアドレスから規制ルータ２０−１を除いた規制ルータ２０−２のＩＰアドレスを取得する（Ｓ７９１）。
【００６７】
アクセスサーバ１０は、ＩＰアドレスを取得した規制ルータ２０−２に対し、規制要求を送信する（Ｓ７９２）。なお、このときの要求メッセージの、主規制対象ＲＴアドレス１１０には規制ルータ２０−１のＩＰアドレスを格納する。規制要求を受信した規制ルータ２０−２は、該当トラヒックに対して規制を開始する（Ｓ７９３）。規制を開始した規制ルータ２０−２は、アクセスサーバ１０にＡＣＫ応答を返信する（Ｓ７９４）。ＡＣＫ応答を返信した規制ルータ２０−２は、流入トラヒックの監視要否を判定する（Ｓ７９５）。なお、ここでは否となって、規制ルータ２０−２は流入トラヒックの監視は実施しない。
【００６８】
実施例１で説明した図９を参照して、図１８のステップ７９１とステップ７９２のアクセスサーバ１０の動作を説明する。図９のステップ９５で規制ルータ２０−１からのＡＣＫ応答を受信したアクセスサーバ１０は、規制ルータ２０−１と同じグループに他の規制ルータが登録されているか判定する（Ｓ９５）。判定結果がＮＯであれば終了する。この場合、規制ルータ２０−１と同じグループに規制ルータ２０−２が登録されているので、ステップ９５はＹＥＳとなり、規制ルータ２０−２に対して規制要求を送信して（Ｓ９６）、終了する。
【００６９】
実施例１で説明した図１０を参照して、図１８のステップ７９５の規制ルータ２０−２の動作を説明する。なお、規制ルータ２０−２の動作は、図１０を用いて説明した規制ルータ２０−１の動作とほぼ同一である。ここでは、異なる点のみ説明する。規制ルータ２０−１と規制ルータ２０−２の違いは、図６を用いて説明した規制設定テーブル２２４５の主規制対象ＲＴアドレス２３６に、自らのＩＰアドレスが記載されているか（規制ルータ２０−１）いないか（規制ルータ２０−２）である。これは、規制ルータ２０−２が受け取った規制要求メッセージに記載された主規制対象ＲＴアドレス１１０に、規制ルータ２０−１のＩＰアドレスが記載されていたためである。この結果、図１０のステップ１０７はＮＯとなり、規制ルータ２０−２は規制ルータ２０−２に流入するトラヒック監視を実施しない。
【００７０】
図１９を参照して、この規制解除の手順を説明する。ここで、図１９は、規制を実施中の規制ルータが規制を解除するまでのシーケンス図である。図１９は、図１８のシーケンスに引き続くものである。図１８のステップ７３５で開始した流入トラヒックの監視は、図１９のステップ７５０において継続されている。
【００７１】
図１９と図１２とを対比すれば分かるように、ステップ７５０に続くステップ７５１からステップ７５９は、図１２のステップ７５１からステップ７５９とまったく同一である。このため説明を省く。
【００７２】
図１９において、規制ルータ２０−１の規制解除通知（Ｓ７５６）に対して、ＡＣＫを応答した（Ｓ７５８）アクセスサーバ１０は、次に規制ルータ２０−２に、規制解除要求を送信する（Ｓ８００）。具体的には、図５（ａ）の要求フォーマット１００の、ＴＹＰＥ１０２を規制解除要求に設定し、送信元アドレス１０５には発信端末５のＩＰアドレス、受信先アドレス１０６には着信端末４のＩＰアドレスを格納したメッセージを送信する。規制解除要求を受信した規制ルータ２０−２は、規制解除を判定し（Ｓ８０１）、この場合受諾してＡＣＫ応答を返信する（Ｓ８０２）。規制ルータ２０−２は、規制設定テーブル２２４５をクリアし、規制を解除する（Ｓ８０３）。なお、ステップ８０２の判定は、規制ルータ２０−２が、図１０の処理フローを実行することにより、実施される
図２１は、障害により通信経路が、主対象規制ルータである規制ルータ２０−１を通らず、同一グループである規制ルータ２０−２を通るルートに変更となった場合に、主対象規制ルータを規制ルータ２０−２に指定し直すまでを説明するシーケンス図である。
【００７３】
図２１のステップ７５０は、図１８で説明した手順によって、規制ルータ２０−１が、トラヒックに規制をかけ、流入するトラヒックを監視している状態である。また、規制ルータ２０−２は、通信経路上には無いが、該当するトラヒックを規制するように設定されている。この規制ルータ２０−１において、何らかの障害により通信経路が、主対象規制ルータである規制ルータ２０−１を通らず、同一グループである規制ルータ２０−２を通るルートに変更になったとしよう（Ｓ８１０）。なお、経路が切り替わっても規制ルータ２０−２には、当該トラヒックを規制するよう設定済みなので、ＩＳＰ網に異常トラヒックが流入することはない。
【００７４】
規制ルータ２０−１は、該当トラヒックの流れるルートが無くなったことを検知し（Ｓ８１１）、規制解除判定処理（流入トラヒック監視）を停止する（Ｓ８１２）。規制ルータ２０−１は、アクセスサーバ１０に対してルートが無くなった事を通知する（Ｓ８１３）。アクセスサーバ１０は、規制ルータ２０−１と同グループの他のルータ（規制ルータ２０−２）があると判定する（Ｓ８１４）。そのため、規制ルータ２０−２に対して、図５（ａ）のフレームフォーマット１００において、ＴＹＰＥ１０２を該当トラヒックの流れるルート存在確認に設定し、送信元アドレス１０５には発信端末５のＩＰアドレス、受信先アドレス１０６には着信端末４のＩＰアドレスを格納したメッセージフレームを送信する（Ｓ８１５）。
【００７５】
アクセスサーバ１０からのルート存在確認メッセージを受け取った規制ルータ２０−２は、該当トラヒックが流れるルートがあるか確認する（Ｓ８１６）。この時、該当トラヒックの流れるルートが存在する規制ルータ２０−２は、アクセスサーバ１０に対し、ＡＣＫ応答を送信する（Ｓ８１７）。
【００７６】
規制ルータ２０−２からのＡＣＫ応答を受信したアクセスサーバ１０は、同じグループの全ての規制ルータ２０に対して、図５（ａ）の要求フォーマット１００を用いて、ＴＹＰＥ１０２を規制要求に設定し、主規制対象ＲＴアドレス１１０には規制ルータ２０−２のＩＰアドレスを格納した、規制要求メッセージを送信する（Ｓ８１８、Ｓ８１９）。規制要求メッセージを受信したルータ２０は、図１０の処理フローを実行する。この結果、規制ルータ２０は受諾判定と規制設定テーブルを更新する（Ｓ８２０、Ｓ８２１）。規制ルータ２０は、アクセスサーバ１０にＡＣＫを返信する（Ｓ８２２、Ｓ８２３）。この後、規制ルータ２０−２は、自身のＩＰアドレスと規制要求メッセージの主規制対象ＲＴアドレスが同一のため、流入トラヒック監視処理を開始する（Ｓ８２４）。
【００７７】
図２２ないし図２５を用いて、図２１のシーケンスの規制ルータとアクセスサーバの動作を説明する。ここで、図２２はルーティングテーブルを説明する図である。図２３は主規制ルータのルート監視を説明するフロー図である。図２４はルート切断通知を受信したアクセスサーバの動作を説明するフロー図である。図２５はルートの存在確認要求を受信した規制ルータの動作を説明するフロー図である。
【００７８】
図２２（ａ）において、ルーティングテーブル２２４６は、ネットワーク欄２４１とネクストホップ欄２４２と、回線インタフェース欄１１から構成される。ネットワーク欄２４１にはネットワークのＩＰアドレスを記載し、ネクストホップ欄２４２にはネットワークに接続するために転送するルータのＩＰアドレスを記載する。回線インタフェース欄１１には、自装置の回線インタフェース番号を記載する。図２２（ｂ）のように、該当ルートがルーティングテーブルから無くなっていたら、ルートが変わったと判断することができる。
【００７９】
図２３において、主対象規制ルータは、規制を行っているトラヒックが通るルートが存在しているかの監視を行い（Ｓ９０１）、ルートが存在しているかどうかの判定をする（Ｓ９０２）。ルートが存在する場合はステップ９０１に戻る。一方ステップ９０２で、ルートが存在していないときは、ルートが変わったと判断し、流入トラヒック監視を停止し（Ｓ９０３）、アクセスサーバ１０にルートが切断されたことを通知する。
【００８０】
図２４において、アクセスサーバ１０は、主対象規制ルータからのルート切断通知を受信すると（Ｓ９１１）、その主対象規制ルータと同じグループに属する他の規制ルータが存在するかの判定を行う（Ｓ９１２）。存在しない場合（ＮＯ）、アクセスサーバ１０は、その主対象規制ルータに対し規制解除要求を送信して（Ｓ９１３）、終了する。ステップ９１２で他の規制ルータが存在する場合（ＹＥＳ）は、同グループの、他の全ルータに対し、該当トラヒックの流れるルート存在有無確認メッセージを送信する（Ｓ９１４）。そこで、ＡＣＫ応答を返すルータが存在しない場合は、グループ全ての規制ルータに対し、規制解除要求を送信する（Ｓ９１３）。ＡＣＫ応答を返す規制ルータが存在した場合は、図５（ａ）の要求フォーマット１００を用いて、主規制対象ＲＴアドレス１１０に、ＡＣＫ応答を返してきたＩＰアドレスを格納した規制要求メッセージを、同グループの全ての規制ルータに対し、送信する（Ｓ９１６）。
【００８１】
図２５において、規制ルータ２０は、アクセスサーバ１０からのルート存在確認要求メッセージを受信する（Ｓ９２１）。規制ルータ２０は、該当トラヒックの流れるルートが存在するか判定を行う（Ｓ９２２）。存在しない場合はＮＡＣＫ応答を返して（Ｓ９２３）、終了する。ステップ９２２でルートが存在する場合はＡＣＫ応答を返して（Ｓ９２４）、終了する。
【００８２】
以上説明した実施例に拠れば、通信経路が変わっても、ＩＳＰ網３００に無駄なトラヒックが流れ込むことを防ぐことができる。また、規制解除の判定処理も、新経路上のルータ（規制ルータ２０−２）に切り替えることができる。
【図面の簡単な説明】
【００８３】
【図１】ネットワークを説明するブロック図である。
【図２】アクセスサーバの構成を説明するブロック図である。
【図３】規制ルータの構成を説明するブロック図である。
【図４】アクセスサーバの規制ルータのＩＰアドレスを登録するテーブルを説明する図である。
【図５】パケット転送装置間で使用するメッセージのフォーマットを説明する図である。
【図６】規制ルータが保持する規制設定テーブルの構成を説明する図である。
【図７】発信端末と着信端末と各転送装置との間の規制開始までのシーケンス図である。
【図８】アクセスサーバにおける異常トラヒック検知および規制を行う処理フロー図である。
【図９】アクセスサーバの規制ルータに対して規制要求を行う処理のフロー図である。
【図１０】規制ルータがクセスサーバからの規制要求または規制解除要求メッセージを受け取った際の処理のフロー図である。
【図１１】規制ルータが送受信するトラヒックを説明する図である。
【図１２】規制を実施中の規制ルータが規制を解除するまでのシーケンス図である。
【図１３】規制ルータに於ける、規制を解除するまでの処理を説明するフロー図である。
【図１４】アクセスサーバに於ける規制ルータから規制解除通知を受け取った際の処理を説明するフロー図である。
【図１５】規制ルータが規制を実施するまでのシーケンス図である。
【図１６】アクセスサーバの規制要求を行う処理のフロー図である。
【図１７】ネットワークを説明するブロック図である。
【図１８】発信端末と着信端末と各転送装置との間の規制開始までのシーケンス図である。
【図１９】規制を実施中の規制ルータが規制を解除するまでのシーケンス図である。
【図２０Ａ】規制ＲＴアドレステーブルを説明する図である。
【図２０Ｂ】同時規制ＲＴテーブルを説明する図である。
【図２１】主対象規制ルータを他の規制ルータに指定し直すまでを説明するシーケンス図である。
【図２２】ルーティングテーブルを説明する図である。
【図２３】主規制ルータのルート監視を説明するフロー図である。
【図２４】ルート切断通知を受信したアクセスサーバの動作を説明するフロー図である。
【図２５】ルートの存在確認要求を受信した規制ルータの動作を説明するフロー図である。
【符号の説明】
【００８４】
４…着信端末、５…発信端末、１０…アクセスサーバ（ＡＳ）、１１…回線インタフェース、１２…プロトコル処理部、１３…制御部、１４…制御端末、２０…規制機能付きルータ（規制ルータ、ＲＲＴ）、２２…プロトコル処理部、３０…ルータ、４０…アクセスサーバ（ＡＳ）、１００…要求フォーマット、１２１…回線側受信バッファ、１２２…回線側送信バッファ、１２３…プロセッサ、１２４…メモリ、１２５…プロセッサ間インタフェース、２００…応答フォーマット、２２１…回線側受信バッファ、２２２…回線側送信バッファ、２２３…プロセッサ、２２４…メモリ、２２５…プロセッサ間インタフェース、３００…ＩＳＰ網、４００…ＩＰ網、１０００…ネットワーク。
【図１】
0004616728.tif 000002
【図２】
0004616728.tif 000003
【図３】
0004616728.tif 000004
【図４】
0004616728.tif 000005
【図５】
0004616728.tif 000006
【図６】
0004616728.tif 000007
【図７】
0004616728.tif 000008
【図８】
0004616728.tif 000009
【図９】
0004616728.tif 000010
【図１０】
0004616728.tif 000011
【図１１】
0004616728.tif 000012
【図１２】
0004616728.tif 000013
【図１３】
0004616728.tif 000014
【図１４】
0004616728.tif 000015
【図１５】
0004616728.tif 000016
【図１６】
0004616728.tif 000017
【図１７】
0004616728.tif 000018
【図１８】
0004616728.tif 000019
【図１９】
0004616728.tif 000020
【図２０Ａ】
0004616728.tif 000021
【図２０Ｂ】
0004616728.tif 000022
【図２１】
0004616728.tif 000023
【図２２】
0004616728.tif 000024
【図２３】
0004616728.tif 000025
【図２４】
0004616728.tif 000026
【図２５】
0004616728.tif 000027