(57)【特許請求の範囲】
【請求項１】
第１網から第２網へパケットの中継を行う中継装置において、
前記第１網から前記第２網へ中継される各パケットに設定されている少なくとも宛先アドレス及び送信元アドレスでそれぞれ特定される複数の通信単位のうち、輻輳の生じた通信単位を検出する輻輳検出手段と、
前記複数の通信単位のうち、前記輻輳検出手段で検出された輻輳の生じた通信単位との間で前記第２網内の少なくとも１つの特定リンクを共有する他の通信単位を特定する特定手段と、
前記複数の通信単位のうち、前記特定手段により特定された他の通信単位及び前記輻輳の生じた通信単位の前記第２網への送信帯域を制限する帯域制御手段と、
前記複数の通信単位のうちの２つの通信単位において、一方の通信単位の送信帯域幅を所定帯域幅分増やし、かつ、他方の通信単位の送信帯域幅を該所定帯域幅分減らすような帯域制御を前記帯域制御手段に実行させ、該帯域制御の後の該一方の通信単位の通信状態に応じて、該一方の通信単位と該他方の通信単位とが前記第２網内の少なくとも１つの特定リンクを共有するか否かを判定する判定手段と、
を備えることを特徴とする中継装置。
【請求項２】
前記輻輳の生じた通信単位の経路情報を収集する収集手段と、
前記収集手段により収集された経路情報に応じて、前記輻輳の生じた通信単位の経路に含まれるボトルネックリンクを検出する検出手段と、
を更に備え、
前記特定手段は、前記検出手段により検出されたボトルネックリンクを前記少なくとも１つの特定リンクとして共有する他の通信単位を特定する、
ことを特徴とする請求項１に記載の中継装置。
【請求項３】
前記収集手段は、前記複数の通信単位の宛先アドレス毎の経路情報をそれぞれ収集し、
前記特定手段は、前記収集手段により収集された前記複数の通信単位の経路情報に基づいて、該経路情報に含まれるリンク毎に該リンクを利用する通信単位の集合情報をそれぞれ記憶する記憶手段を含む、
ことを特徴とする請求項２に記載の中継装置。
【請求項４】
第１網から第２網へパケットの中継を行う中継装置で実行される帯域制御方法において、
前記第１網から前記第２網へ中継される各パケットに設定されている少なくとも宛先アドレス及び送信元アドレスでそれぞれ特定される複数の通信単位のうち、輻輳の生じた通信単位を検出するステップと、
前記複数の通信単位のうち、前記検出された輻輳の生じた通信単位との間で前記第２網内の少なくとも１つの特定リンクを共有する他の通信単位を特定するステップと、
前記複数の通信単位のうち、前記特定された他の通信単位及び前記輻輳の生じた通信単位の前記第２網への送信帯域を制限するステップと、
前記複数の通信単位のうちの２つの通信単位において、一方の通信単位の送信帯域幅を所定帯域幅分増やし、かつ、他方の通信単位の送信帯域幅を該所定帯域幅分減らすような帯域制御を実行させ、該帯域制御の後の該一方の通信単位の通信状態に応じて、該一方の通信単位と該他方の通信単位とが前記第２網内の少なくとも１つの特定リンクを共有するか否かを判定するステップと、
を含むことを特徴とする帯域制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、帯域制御技術に関する。
【背景技術】
【０００２】
遠隔の各拠点間をネットワークで結んだ通信システムはＷＡＮ（Wide Area Network）
通信システムなどと呼ばれる。以降、このような遠隔の各拠点間を結ぶネットワークをＷＡＮ、ＷＡＮ回線等と表記する。このようなＷＡＮ通信システムには、ＷＡＮ回線の高速化又は最適化を行うネットワーク機器が存在する。ＷＡＮ回線の高速化又は最適化は、ＶＰＮ（Virtual Private Network）ルータ、ＷＡＮ高速化装置、ＷＡＮ最適化装置等のよ
うに、各拠点のネットワークをＷＡＮに接続させる各ネットワーク機器でそれぞれ実現される。
【０００３】
このようなネットワーク機器では、ＷＡＮ回線の帯域制御が行われる。例えば、ネットワーク機器内でのバッファフル等によりリンクの輻輳が検出された場合には、高速化が要求される通信に他の通信よりも優先的に帯域を割り当てるといった優先帯域制御が行われる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−５０７８号公報
【特許文献２】特開２００７−２４３３００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一般的に、上述したようなＷＡＮは、インターネット等のように、エッジノードメーカ等にとって管理外のブラックボックス網であることが多い。このようなブラックボックス網では、網内で輻輳が起こり、拠点間の通信に必要な帯域が得られない場合がある。このような問題を回避するには、ＲＳＶＰ（Resource Reservation Protocol）や優先制御等
がブラックボックス網に含まれるルータ等の各中継装置に実装されている必要がある。しかしながら、ブラックボックス網内は各利用者が管理できないため、ブラックボックス網内に含まれる各中継装置の実装機能に依存することができない場合が多い。
【０００６】
これにより、上述のような従来のエッジノードは、ブラックボックス網のような特定網に含まれる複数の中継装置をそれぞれ繋ぐ各リンクのうち、自身と直接接続されないリンクにおける輻輳を検出することができない。このように従来のエッジノードでは、特定網内の輻輳に対応するための帯域制御を実行することができないという問題点がある。
【０００７】
本発明の一態様に係る目的は、このような問題点に鑑み、特定網内の輻輳を回避する帯域制御技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の各態様では、上述した課題を解決するために、それぞれ以下の構成を採用する。
【０００９】
第１の態様は、第１網から第２網へパケットの中継を行う中継装置に関する。第１の態様に係る中継装置は、第１網から第２網へ中継される各パケットに設定されている少なくとも宛先アドレス及び送信元アドレスでそれぞれ特定される複数の通信単位のうち、輻輳
の生じた通信単位を検出する輻輳検出手段と、当該複数の通信単位のうち、上記輻輳検出手段で検出された輻輳の生じた通信単位との間で第２網内の少なくとも１つの特定リンクを共有する他の通信単位を特定する特定手段と、当該複数の通信単位のうち、上記特定手段により特定された他の通信単位及び上記輻輳の生じた通信単位の第２網への送信帯域を制限する帯域制御手段と、を備える。
【００１０】
本発明の別態様としては、以上の構成を実現する方法であってもよいし、コンピュータに以上の構成を実現させるプログラムであってもよいし、このようなプログラムを記録したコンピュータが読み取り可能な記録媒体であってもよい。
【発明の効果】
【００１１】
上記各態様によれば、特定網内の輻輳を回避する帯域制御技術を提供することができる。
【図面の簡単な説明】
【００１２】
【図１】ＷＡＮ通信システムの概略構成を示す図。
【図２】実施例１におけるエッジノード１０の概略構成を示すブロック図。
【図３】実施例１におけるセッション管理テーブルの例を示す図。
【図４】ルート情報テーブル２６の例を示す図。
【図５】リンク集合テーブル２７の例を示す図。
【図６Ａ】実施例１における帯域制御装置の動作例を示すフローチャート。
【図６Ｂ】実施例１における帯域制御装置の動作例を示すフローチャート。
【図７】実施例２におけるエッジノード１０の概略構成を示すブロック図。
【図８】実施例２におけるセッション管理テーブルの例を示す図。
【図９】共有セッショングループを示すイメージ図。
【図１０】共有セッションテーブル７３の例を示す図。
【図１１】実施例２における共有セッショングループの検査の動作例を示すフローチャート。
【図１２】実施例２における送信帯域制御の動作例を示すフローチャート。
【発明を実施するための形態】
【００１３】
以下、一実施形態としての帯域制御装置について具体例を挙げ説明する。実施形態としての帯域制御装置は、各拠点間をＷＡＮ経由で接続するエッジノードとして作用する。以降、本実施形態における帯域制御装置をエッジノードとも表記する。
【００１４】
本実施形態は、ＷＡＮの意味を限定するものではなく、ＷＡＮはルータ等の複数の中継装置を含むネットワークであればよい。本実施形態におけるエッジノードによれば、当該ＷＡＮがエッジノード提供者にとって管理外のネットワークであったとしても適用可能である。以下に挙げた各実施例はそれぞれ例示であり、本実施形態は以下の各実施例の構成に限定されない。
【実施例１】
【００１５】
以下、実施形態としての帯域制御装置（エッジノード）の第１実施例について説明する。
【００１６】
［システム構成］
図１は、ＷＡＮ通信システムの概略構成を示す図である。ＷＡＮ通信システムは、ＷＡＮ１を介してそれぞれ接続される拠点網２、３及び４を含む。ＷＡＮ１は、例えば、インターネット等の公衆網である。各拠点網は、例えば、拠点Ａ、拠点Ｂ及び拠点Ｃにそれぞれ設けられたＬＡＮ（Local Area Network）である。
【００１７】
実施例１におけるエッジノード１０は、拠点網２とＷＡＮ１との境界に配置され、拠点網２をＷＡＮ１に接続する。実施例１におけるエッジノード１０は、拠点網２からＷＡＮ１に向けて送出される通信の帯域幅を制御し、ＷＡＮ１から各拠点に向けて送出される通信を特に限定するものではない。よって、実施例１におけるエッジノード１０で帯域制御されてＷＡＮ方向に送出されたパケットを受信する他のエッジノード８及び９は一般的な中継装置でよい。このため、実施例１では、拠点網３及び４をＷＡＮ１に接続するエッジノード８及び９は一般的なルータとする。なお、エッジノード８及び９についても実施例１におけるエッジノードを用いるようにしてもよい。
【００１８】
［装置構成］
図２は、実施例１におけるエッジノード１０の概略構成を示すブロック図である。実施例１におけるエッジノード１０は、図２に示すように、拠点側受信部１１、セッション解析部１２、セッション管理テーブル１３、セッションキュー１４、出力制御器１５、ＷＡＮ側送信部１６、ＷＡＮ側受信部２１、パケット解析部２２、経路探索部２３、応答確認処理部２４、帯域制御部２５、ルート情報テーブル２６、リンク集合テーブル２７、拠点側送信部２８等を含む。これら各処理部は、ソフトウェアの構成要素、又はハードウェアの構成要素、若しくはこれらの組み合わせとしてそれぞれ実現される（［その他］の項参照）。
【００１９】
拠点側受信部１１及び拠点側送信部２８は、拠点網２との通信インタフェースとして動作する。拠点側受信部１１は、拠点網２からのパケットを受信する。拠点側受信部１１は、受信されたパケットがＷＡＮ１に向けて送出すべきと判断すると、このパケットの受信をセッション解析部１２へ通知する。拠点側送信部２８は、ＷＡＮ１からのパケットをパケット解析部２２から受けると、そのパケットを拠点網２へ送信する。
【００２０】
セッション解析部１２は、拠点側受信部１１で受信されたパケットを解析する。具体的には、セッション解析部１２は、受信されたパケットから、宛先ＩＰ（Internet Protocol）アドレス、送信元ＩＰアドレス、プロトコルデータ、サービスタイプ、宛先ポート番
号、送信元ポート番号、シーケンス番号、パケット長、コードビット等を抽出する。
【００２１】
セッション解析部１２は、抽出された、宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号、送信元ポート番号に基づいて、そのパケットが属するセッションを識別する。ここで用いるセッションとは、宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号及び送信元ポート番号で特定される通信単位を示す。よって、例えば、１つのＴＣＰ（Transmission Control Protocol）コネクションは１つのセッションに対応する。ＵＤＰ
（User Datagram Protocol）でやりとりされるパケットも１つのセッションを構成する。
【００２２】
セッション解析部１２は、受信パケットが属するセッションを識別し終えると、そのパケットを、識別されたセッションに対応するセッションキューに入れる。
【００２３】
また、セッション解析部１２は、受信パケットに応じて識別されたセッションをセッション管理テーブル１３で管理する。図３は、実施例１におけるセッション管理テーブルの例を示す図である。セッション管理テーブル１３には、各セッションについて、セッションＩＤ（Identification）、セッション特定情報、状態、輻輳検出用情報、ルート情報、速度情報、キュー情報等が格納される。
【００２４】
セッションＩＤは、各セッションをエッジノード１０内で識別するためにセッション解析部１２により付される識別情報である。セッション特定情報は、各セッションを特定するための宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号及び送信元ポート番号
を含む。セッション解析部１２は、受信パケットから抽出された宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号及び送信元ポート番号がセッション特定情報としてセッション管理テーブル１３に格納されていない場合に、新たなセッションＩＤを生成する。セッション解析部１２は、この新たなセッションＩＤ、受信パケットから抽出された宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号及び送信元ポート番号が設定された新たなレコードをセッション管理テーブル１３に追加する。
【００２５】
セッション解析部１２は、受信パケットから抽出されたプロトコルデータがＴＣＰを示す場合には、同様に抽出されたコードビットに応じて、セッション管理テーブル１３内の状態フィールドを更新する。例えば、コードビットのＳＹＮ（Synchronize）フラグがセ
ットされている場合には、状態フィールドにＳＹＮが受信されたことを示す値（ＳＹＮ＿ＲＣＶＤ）が設定される。また、コードビットのＦＩＮフラグがセットされている場合には、状態フィールドにＦＩＮパケット待ち状態を示す値（ＦＩＮ＿ＷＡＩＴ）が設定される。状態フィールドにＦＩＮ＿ＷＡＩＴが設定されているセッションが存在した場合に、パケット解析部２２によりそのセッションのＦＩＮパケットが受信されたと判定されると、セッション管理テーブル１３からそのセッションのレコードが削除される。
【００２６】
輻輳検出用情報は、ＴＣＰにおける応答確認パケット（以降、ＡＣＫパケットと表記する）を用いた輻輳検出で利用される情報である。輻輳検出用情報は、最新送出時間、最大送出シーケンス番号、最小未確認応答シーケンス番号、平均ＲＴＴ（Round Trip Time）
、ＲＴＴ平均偏差を含む。最新送出時間は、拠点網２から受信されたパケットをＷＡＮ１へ送出した時間を示す。実施例１では、セッション解析部１２が、受信パケットをセッションキューに入れた際に、そのときの時間情報を最新送出時間として設定する。
【００２７】
最大送出シーケンス番号は、エッジノード１０がＷＡＮ１へ送出したパケットに関する、同一セッション中で最大のシーケンス番号を示す。セッション解析部１２は、セッション管理テーブル１３における該当セッションを示すレコードに設定されている最大送出シーケンス番号よりも、受信パケットから抽出されたシーケンス番号が大きい場合に、その抽出されたシーケンス番号をセッション管理テーブル１３に反映させる。
【００２８】
最小未確認応答シーケンス番号、平均ＲＴＴ（Round Trip Time）及びＲＴＴ平均偏差
は、応答確認処理部２４によりそれぞれ更新される。ルート情報フィールドには、ルート情報テーブル２６のそのセッションに関するレコードへのポインタが格納される。ルート情報テーブル２６は経路探索部２３により管理されるため、このルート情報フィールドも経路探索部２３により更新される。
【００２９】
速度情報は、各セッションを帯域制御するために利用される情報である。速度情報は、優先順位、実績送信帯域幅等を含む。セッション解析部１２は、セッション管理テーブル１３に新たなセッションのレコードを追加する際に、そのセッションの優先順位を決める。セッション解析部１２は、この決定された優先順位を当該優先順位フィールドに格納する。セッションの優先順位は、例えば、受信パケットから抽出されたサービスタイプやポート番号から決定される。
【００３０】
実績送信帯域幅は、対象セッションについて、エッジノード１０からＷＡＮ１へ送出された単位時間当りのデータ量を示す。セッション解析部１２は、セッションキューに入れたパケットのパケット長を累積し、この累積値を単位時間（例えば１０ミリ秒（ｍｓ））で除算した値を最新データとして取得する。セッション解析部１２は、この最新データと、セッション管理テーブル１３の実績送信帯域幅フィールドに既に格納されているデータとの加重平均を取ることにより得られた値で実績送信帯域幅フィールドを更新する。
【００３１】
キュー情報フィールドには、対象セッションのパケットがキューイングされるセッションキューへのポインタが格納される。セッション解析部１２は、パケットをセッションキューに入れると、そのセッションキューへのポインタをキュー情報フィールドに格納する。
【００３２】
セッションキュー１４は、セッション毎にそれぞれ設けられ、ＷＡＮ１へ送出するためのパケットを一時格納するバッファである。上述したように、拠点網２から受信されたパケットがセッション解析部１２で識別されたセッションに対応するセッションキューに格納される。
【００３３】
出力制御器１５は、各セッションキュー１４を所定の順番で選択し、選択されたセッションキュー１４に格納されているパケットをＦＩＦＯ（First-IN First-OUT）で抽出し、抽出されたパケットをＷＡＮ側送信部１６へ送る。出力制御器１５は、帯域制御部２５からの優先制御の指示を受けた場合には、その指示に応じてパケットの抽出とパケットの廃棄を行う。この優先制御の詳細については後述する。
【００３４】
ＷＡＮ側送信部１６及びＷＡＮ側受信部２１は、ＷＡＮ１との通信インタフェースとして動作する。ＷＡＮ側送信部１６は、出力制御器１５により抽出されたパケットをＷＡＮ１へ送出する。ＷＡＮ側受信部２１は、ＷＡＮ１からのパケットを受信し、受信されたパケットをパケット解析部２２へ送る。
【００３５】
パケット解析部２２は、ＷＡＮ側受信部２１で受信されたパケットを解析する。パケット解析部２２は、受信パケットがＡＣＫパケットである場合には、ＡＣＫパケットが受信されたことを応答確認処理部２４へ通知する。パケット解析部２２は、受信パケットがＩＣＭＰ（Internet Control Message Protocol）の時間超過（Time Exceeded）メッセージ（以降、単に時間超過メッセージと表記する）である場合には、時間超過メッセージが受信されたことを経路探索部２３に通知する。パケット解析部２２は、ＷＡＮ側受信部２１で受信されたパケットを拠点網２へ送出するように拠点側送信部２８へ指示する。
【００３６】
経路探索部２３は、定期的に、セッション管理テーブル１３に格納される各セッションの経路情報をそれぞれ収集する。各セッションの経路情報としては、経路上の各中継装置（ルータ等）の情報が収集される。経路探索部２３は、新たなセッションが発生したことによりセッション管理テーブル１３に新たなレコードが追加された際、及び、帯域制御部２５から指示を受けた場合等にも、同様に、セッションの経路情報を取得する。
【００３７】
セッションの経路情報は、例えば、ｔｒａｃｅｒｏｕｔｅと呼ばれるコマンドと同様に、ＩＣＭＰの時間超過メッセージを用いて収集される。経路探索部２３は、ＩＰヘッダの生存時間（ＴＴＬ）フィールドを１から順に更新しながら、セッション管理テーブル１３に格納されるセッションの宛先ＩＰアドレスを宛先とする経路探索のための所定ＩＰパケットを順次送信する。経路探索部２３は、パケット解析部２２から時間超過メッセージの受信の通知を受けると、この時間超過メッセージを解析することにより経路情報を取得する。
【００３８】
経路探索部２３は、このように収集された経路情報をルート情報テーブル２６を用いて管理する。経路探索部２３は、新たな宛先ＩＰアドレスに関する経路情報を収集した際には、ルート情報テーブル２６に新たなレコードを追加すると共に、その新たなレコードへのポインタ情報を上述のセッション管理テーブル１３のルート情報フィールドに格納する。
【００３９】
図４は、ルート情報テーブル２６の例を示す図である。ルート情報テーブル２６には、
宛先ＩＰアドレス毎に、エッジルータ１０からその宛先ＩＰアドレスまでの間に経由される各ルータのＩＰアドレス、平均ＲＴＴ、ＲＴＴ平均偏差がそれぞれ格納される。経路探索部２３は、受信された各時間超過メッセージから当該宛先ＩＰアドレスまでに経由する各ルータのＩＰアドレスをそれぞれ取得し、取得されたＩＰアドレスをルート情報テーブル２６に格納する。
【００４０】
また、経路探索部２３は、経路探索のためのＩＰパケットの送信時間から時間超過メッセージの受信時間までのレスポンス時間（ＲＴＴ）を各ルータについてそれぞれ計測する。経路探索部２３は、計測された各ルータのＲＴＴと既にルート情報テーブル２６に格納されている各ルータのＲＴＴとの重み付け平均を算出し、算出された値でルート情報テーブル２６の平均ＲＴＴフィールドを更新する。重み付け平均は、以下の式で示すことができる。
【００４１】
今回の平均ＲＴＴ＝１／ｎ×（今回計測されたＲＴＴ＋（ｎ−１）×前回の平均ＲＴＴ）
重み付け係数ｎは、例えば、８に設定される。なお、経路探索部２３は、同じＴＴＬ値が設定された経路探索のための所定ＩＰパケットを複数回送信することにより、同一ルータから複数回時間超過メッセージを受信するようにしてもよい。経路探索部２３は、複数回受信された時間超過メッセージにより各ルータのＲＴＴの平均を算出するようにしてもよい。
【００４２】
経路探索部２３は、平均ＲＴＴを更新する際に、その平均ＲＴＴと既にルート情報テーブル２６に格納されている平均ＲＴＴとを用いてＲＴＴ平均偏差を以下の式を用いて算出する。
【００４３】
今回のＲＴＴ平均偏差＝１／ｍ×（｜今回の平均ＲＴＴ−既存の平均ＲＴＴ｜＋（ｍ−１）×前回のＲＴＴ平均偏差）
重み付け係数ｍは、例えば、４に設定される。経路探索部２３は、取得されたＲＴＴ平均偏差をルート情報テーブル２６のＲＴＴ平均偏差フィールドに格納する。
【００４４】
経路探索部２３は、ルート情報テーブル２６に新たな宛先ＩＰアドレスのレコードを追加した際に、リンク集合テーブル２７を更新する。また、セッション解析部１２は、新たなセッションの発生を検出した場合に、リンク集合テーブル２７を更新する。
【００４５】
図５は、リンク集合テーブル２７の例を示す図である。リンク集合テーブル２７は、ルート情報テーブル２６に格納される各経路に含まれるリンクの情報を格納する。ここでのリンクとはルータ間の接続を示すため、リンク集合テーブル２７の各レコードには、２つの隣接するルータのＩＰアドレスとそのリンクを利用するセッションＩＤのリストがそれぞれ格納される。ルート情報テーブル２６の情報により隣接するルータの各ＩＰアドレスが取得される。そのリンクを利用するセッションのセッションＩＤは、セッション管理テーブル１３のルート情報フィールドに格納されるポインタに基づいて当該セッション管理テーブル１３から抽出される。
【００４６】
応答確認処理部２４は、パケット解析部２２からＡＣＫパケットの受信の通知を受けると、セッション管理テーブル１３における最小未確認応答シーケンス番号、平均ＲＴＴ、ＲＴＴ平均偏差を更新する。最小未確認応答シーケンス番号フィールドには、ＷＡＮ１から未だ受信されていないＡＣＫパケットにおける同一セッション中の最小のシーケンス番号が格納される。
【００４７】
平均ＲＴＴフィールドには、或るパケットが送信されてからこのパケットのＡＣＫパケ
ットが受信されるまでの時間（往復応答時間）の重み付け平均された値が格納される。実施例１では、応答確認処理部２４が、ＡＣＫパケットを受信した時間とそのＡＣＫパケットに設定されているタイムスタンプとの差（時間）と、セッション管理テーブル１３に既に格納されている平均ＲＴＴとを重み付け平均した値を平均ＲＴＴとして格納する。重み付け平均は、上述した式で示すことができる。
【００４８】
通常、ＡＣＫパケットのタイムスタンプには、確認応答の対象となるパケットに設定されていたタイムスタンプと同一データが設定される。よって、厳密には、送信元ノードがパケットを送信した時間（タイムスタンプ）とそのパケットに対するＡＣＫパケットがエッジノード１０で受信された時間との差がＲＴＴとして取得される。
【００４９】
ＲＴＴ平均偏差フィールドには、平均ＲＴＴの平均偏差が格納される。応答確認処理部２４は、平均ＲＴＴを新たに算出すると、この新たな平均ＲＴＴを用いて、ＲＴＴ平均偏差を上述の式を用いて算出する。
【００５０】
応答確認処理部２４は、セッション管理テーブル１３における最小未確認応答シーケンス番号、平均ＲＴＴ、ＲＴＴ平均偏差を更新すると、このセッション管理テーブル１３に基づいて各セッションにおいて輻輳が発生しているか否かを判定する。具体的には、応答確認処理部２４は、ＲＴＴの増大やパケットロス率から輻輳の発生を検出する。
【００５１】
或る回線で輻輳が発生すると、その回線に接続しているルータのバッファにパケットが蓄積され、最終的には、バッファが溢れてパケットロスが生じる。これにより、ＲＴＴの増大は輻輳の前兆を示し、ＡＣＫパケットの不達はパケットロスの発生を示す。しかし、ネットワークの状況（長距離か短距離か）や状態（品質）によりＲＴＴの取り得る値の幅が大きいため、ＲＴＴ増大の判定は困難である。
【００５２】
そこで、応答確認処理部２４は、ＲＴＴの平均偏差を用いて、以下のような条件を満たす場合にＲＴＴの増大を判定する。なお、所定係数ｋは、例えば、２に設定される。平均偏差を用いることにより、正常時におけるＲＴＴの取り得る値の幅を考慮した上でのＲＴＴの増大を検出することができる。
【００５３】
今回計測されたＲＴＴ＞今回の平均ＲＴＴ＋今回のＲＴＴ平均偏差×所定係数ｋ
また、応答確認処理部２４は、或るパケットをＷＡＮ１へ送出してから以下の式で示されるパケットロス判定時間経ってもＡＣＫパケットが受信されない場合に、パケットロスを判定する。応答確認処理部２４は、パケットロス判定によりパケットロス率を取得する。パケットロス率は、所定単位時間内に発生したパケットロス回数として算出される。応答確認処理部２４は、算出されたパケットロス率が所定閾値よりも大きい場合に、パケットロス率の増大と判断する。この所定閾値はシミュレーション等により適切値に設定され、予め調整可能にメモリ等に保持される。
【００５４】
パケットロス判定時間＝平均ＲＴＴ＋２×ＲＴＴ平均偏差×所定係数ｋ
応答確認処理部２４は、上述のようにＲＴＴの増大が検出され、かつ、パケットロス率の増大が検出された場合に、該当セッションの輻輳が生じたと判定する。応答確認処理部２４は、輻輳発生が検出された場合、輻輳が生じているセッションを示すセッションＩＤと共に輻輳発生を帯域制御部２５に通知する。
【００５５】
帯域制御部２５は、セッションＩＤと共にセッションの輻輳発生の通知を受けると、そのセッションの経路上のボトルネックリンクを検出する。ここで、ボトルネックリンクとは、そのセッションに輻輳を生じさせている可能性の高いリンクを意味する。帯域制御部２５は、リンク集合テーブル２７とセッション管理テーブル１３とを用いて、検出された
ボトルネックリンクをその経路上に含むセッションを特定する。帯域制御部２５は、セッション管理テーブル１３に格納される情報に基づいて、特定された全セッションの実績送信帯域幅を合計し、この合計送信帯域幅から目標送信帯域幅を決定する。帯域制御部２５は、ボトルネックリンクをその経路上に含むセッションで利用される帯域幅がその目標送信帯域幅となるように出力制御器１５を制御する。この制御では、優先順位が高いセッションのパケットが優先的に目標送信帯域幅内でセッションキュー１４からＷＡＮ１へ送出するために取り出され、目標送信帯域幅を超えるパケットがセッションキュー１４から廃棄される。帯域制御部２５の詳細処理については、動作例の項において後述する。
【００５６】
［動作例］
以下、実施例１における帯域制御装置の動作例について図６Ａ及び図６Ｂを用いて説明する。図６Ａ及び図６Ｂは、実施例１における帯域制御装置の動作例を示すフローチャートである。
【００５７】
応答確認処理部２４は、セッション管理テーブル１３に基づいて、各セッションにおける輻輳の発生を監視している。応答確認処理部２４は、ＷＡＮ１から受信されたＡＣＫパケットに応じて、セッション管理テーブル１３における最小未確認応答シーケンス番号、平均ＲＴＴ、ＲＴＴ平均偏差を更新すると共に、各セッションについてのＲＴＴが増大しているか否かを監視している。また、応答確認処理部２４は、セッション管理テーブル１３の最新送出時間とパケットロス判定時間とを用いて、各セッションについてＡＣＫパケットの不達を監視し、結果、パケットロス率が増大しているか否かを判定する。
【００５８】
応答確認処理部２４は、ＲＴＴが増大しており、かつ、パケットロス率が増大しているセッションを検出した場合に、そのセッションに輻輳が発生したと判断する（Ｓ６１）。応答確認処理部２４は、輻輳の発生したセッションを検出すると、そのセッションを識別するセッションＩＤと共に輻輳発生を帯域制御部２５に通知する。
【００５９】
帯域制御部２５は、セッションＩＤと共にセッションの輻輳発生の通知を受けると、そのセッションの経路上のボトルネックリンクを調べるためにその輻輳が発生したセッションの経路情報を新たに収集するように経路探索部２３に指示する。
【００６０】
経路探索部２３は、帯域制御部２５から指示に応じて、そのセッションＩＤに対応する宛先ＩＰアドレスをセッション管理テーブル１３から抽出し、この宛先ＩＰアドレスまでの経路情報を収集する（Ｓ６２）。この収集処理により、経路探索部２３は、宛先ＩＰアドレスまでの間に経由されるルータ情報（Ｒ（ｉ）；ｉはルータ数）とＲＴＴ情報（Ｍ（ｉ）；各ルータＲ（ｉ）のＲＴＴ）とを取得する。経路探索部２３は、取得されたルータ情報及びＲＴＴ情報を帯域制御部２５へ送る。
【００６１】
帯域制御部２５は、経路探索部２３からルータ情報及びＲＴＴ情報を受けると、当該セッションＩＤに対応するルート情報テーブルへのポインタをセッション管理テーブル１３から抽出する。帯域制御部２５は、この抽出されたポインタで示される経路情報をルート情報テーブル２６から抽出する（Ｓ６３）。即ち、輻輳発生セッションの宛先ＩＰアドレスに関する経路情報がルート情報テーブル２６から抽出される。この抽出された経路情報には、宛先ＩＰアドレスまでの間に経由されるルータ情報（Ｒ（ｉ）；ｉはルータ数）と、平均ＲＴＴ情報（Ａ（ｉ）；各ルータＲ（ｉ）の平均ＲＴＴ）とＲＴＴ平均偏差情報（Ｄ（ｉ）；各ルータＲ（ｉ）のＲＴＴ平均偏差）とが含まれる。
【００６２】
帯域制御部２５は、経路探索部２３から送られた新たな経路情報と、ルート情報テーブル２６から抽出された既存の経路情報と、を用いて、輻輳が発生したセッションの経路上のボトルネックリンクを検出する（Ｓ６４）。具体的には、帯域制御部２５は、まず、輻
輳が発生したセッションの経路上のルータ（Ｒ（ｉ））のうち、新たに収集されたＲＴＴ（Ｍ（ｉ））がこれまでの平均ＲＴＴ（Ａ（ｉ））と比較して著しく相違するルータを抽出する。例えば、ルータ（Ｒ（ｉ））のうち、｜Ａ（ｉ）−Ｍ（ｉ）｜／Ｄ（ｉ）で得られる値が最大となるルータ（Ｒ（ｘ）；ｉ＝ｘ）が特定される。次に、帯域制御部２５は、ルート情報テーブル２６から取得された経路情報に含まれるホップ情報に基づいて、宛先から離れる方向でそのルータ（Ｒ（ｘ））と隣接するルータ（Ｒ（ｘ−１））を特定する。結果、帯域制御部２５は、ルータ（Ｒ（ｘ））とルータ（Ｒ（ｘ−１））との間のリンクをボトルネックリンクとして検出する。
【００６３】
帯域制御部２５は、検出されたボトルネックリンク（Ｒ（ｘ−１）、Ｒ（ｘ））をその経路上に含むセッションを特定する（Ｓ６５）。具体的には、帯域制御部２５は、ルータ（Ｒ（ｘ−１））とルータ（Ｒ（ｘ））との組で示されるレコードをリンク集合テーブル２７から抽出し、このレコードに含まれるセッションＩＤのリスト（セッションの集合（Ｓ））を抽出する。
【００６４】
帯域制御部２５は、抽出されたセッションの集合（Ｓ）の実績送信帯域幅の合計を算出する（Ｓ６６）。具体的には、帯域制御部２５は、抽出された各セッションＩＤに対応する実績送信帯域幅をセッション管理テーブル１３からそれぞれ抽出し、この抽出された各実績送信帯域幅を合計する。
【００６５】
帯域制御部２５は、この合計された実績送信帯域幅から目標送信帯域幅を決定する（Ｓ６７）。例えば、帯域制御部２５は、合計された実績送信帯域幅に所定の係数（例えば０．５）を乗算した結果を目標送信帯域幅に決定する。帯域制御部２５は、この目標送信帯域幅に実績送信帯域幅の算出に利用された単位時間（例えば１０（ｍｓ））を乗算することにより目標送信データ量を決定する（Ｓ６８）。
【００６６】
帯域制御部２５は、セッションの集合（Ｓ）をセッション管理テーブル１３に格納される優先順位の高い順に並べ替える（Ｓ７０）。続いて、帯域制御部２５は、セッションの集合（Ｓ）から最高優先度のセッションを示すセッションＩＤを抽出し、この抽出されたセッションＩＤをセッションの集合（Ｓ）から削除する（Ｓ７１）。
【００６７】
帯域制御部２５は、この抽出されたセッションＩＤに対応するセッションキューへのポインタをセッション管理テーブル１３から抽出し、この抽出されたポインタにより特定されるセッションキュー１４のパケットを送出するように出力制御器１５へ指示する。この指示に応じて、セッションキュー１４の先頭パケットがＷＡＮ１へ送出され、セッションキュー１４から削除される（Ｓ７２）。
【００６８】
帯域制御部２５は、送出されたパケットのパケット長を出力制御器１５から受け、このパケット長を累積する（Ｓ７３）。帯域制御部２５は、累積されたパケット長が目標送信データ量よりも大きいか否かを判定する（Ｓ７４）。帯域制御部２５は、累積されたパケット長が目標送信データ量を超えた場合には（Ｓ７４；ＹＥＳ）、特定されているセッションキュー１４に残留しているパケット、及び、その他のセッションの集合（Ｓ）に含まれる全セッションのセッションキュー１４に残留しているパケットを各セッションキュー１４からそれぞれ廃棄する（Ｓ７５）。
【００６９】
これにより、実施例１における帯域制御装置１０によれば、管理不可能なＷＡＮ１を含むエッジノード１０から宛先端末までのネットワークにおけるボトルネックリンクを検出することができ、かつ、ボトルネックリンクを利用する全セッションの送信帯域幅を制限することができる。結果、実施例１によれば、セッションの輻輳を解消させることができる。
【００７０】
なお、帯域制御部２５は、累積されたパケット長が目標送信データ量以下である場合には（Ｓ７４；ＮＯ）、特定されているセッションキュー１４にパケットが残留しているか否かを判定する（Ｓ７６）。
【００７１】
帯域制御部２５は、パケットが残留している場合には（Ｓ７６；ＮＯ）、その特定されているセッションキュー１４から更にパケットを送出するように出力制御器１５へ指示する。この指示に応じて、セッションキュー１４から更にパケットがＷＡＮ１へ送出される（Ｓ７２）。一方で、帯域制御部２５は、特定されているセッションキュー１４にパケットがなくなった場合には（Ｓ７６；ＹＥＳ）、当該セッションの集合（Ｓ）から新たに優先度の高いセッションを示すセッションＩＤを抽出する（Ｓ７１）。以降、帯域制御部２５は、この新たに抽出されたセッションについて、上述のようなパケット送信処理を行う（Ｓ７２）。
【００７２】
帯域制御部２５は、順次、送出されたパケットのパケット長を累積し（Ｓ７３）、累積されたパケット長が目標送信データ量以下となるまでパケット送信処理を繰り返す。累積されたパケット長が目標送信データ量以下となる前に、当該セッションの集合（Ｓ）に残留するセッションがなくなった場合には（Ｓ７７；ＹＥＳ）、帯域制御部２５は、その他のセッションのパケットを順次送出するように、出力制御器１５へ指示する（Ｓ７８）。以降、通常通り、各セッションのパケットが順次ＷＡＮ１へ送出される。
【００７３】
〈実施例１の作用及び効果〉
上述したとおり、実施例１における帯域制御装置１０では、拠点網２からＷＡＮ１方向へ送出すべきパケットが解析されることにより、当該帯域制御装置１０で中継される各セッションがセッション管理テーブル１３を用いてそれぞれ管理される。各セッションで通信されるパケットは、セッション毎に設けられたセッションキュー１４にそれぞれ格納され、各セッションの優先順位等に応じて出力制御器１５によりセッションキュー１４から順次取り出され、ＷＡＮ１へ送出される。
【００７４】
応答確認処理部２４では、ＡＣＫパケットが監視されることにより、各セッションに関し、往復遅延時間、往復遅延時間の重み付け平均された値（平均ＲＴＴ）、この重み付け平均された応答遅延時間の平均偏差（ＲＴＴ平均偏差）が取得され、結果として、ＲＴＴの増大が検出される。
【００７５】
ＲＴＴの取り得る値の幅は大きいことからＲＴＴ増大の判定は困難であるところ、実施例１における帯域制御装置１０によれば、平均偏差を用いることによりＲＴＴ増大に基づく正確な輻輳検出を行うことができる。
【００７６】
更に、応答確認処理部２４では、ＡＣＫパケットの不達が監視されることにより、パケットロス率が取得され、パケットロス率が所定閾値より大きい場合にパケットロス率の増大が検出される。最終的に、ＲＴＴの増大及びパケットロス率の増大により、セッションの輻輳が検出される。
【００７７】
セッションの輻輳が検出されると、このセッションの宛先ＩＰアドレスまでの経路情報がＩＣＭＰの時間超過メッセージを用いて収集される。結果、この収集された経路情報に含まれるルータ情報及び各ルータのＲＴＴに基づいて、そのセッションの経路上の輻輳を生じさせているリンクがボトルネックリンクとして検出される。
【００７８】
このように、実施例１によれば、ＩＣＭＰの時間超過メッセージにより各セッションの経路情報が取得されるため、例え、ＷＡＮ１が管理外のブラックボックス網であったとし
ても、正確にボトルネックリンクを検出することができる。
【００７９】
また、実施例１では、宛先ＩＰアドレスまでに経由されるルータ情報及び各ルータまでのＲＴＴ情報（平均ＲＴＴ及びＲＴＴ平均偏差）がルート情報テーブル２６で管理される。また、このルート情報テーブル２６に基づいて隣接ルータの組み合わせにより各リンクの情報、及び、各リンクを利用するセッション情報がそれぞれリンク集合テーブル２７により管理される。
【００８０】
これにより、実施例１によれば、ボトルネックリンクが検出された場合に、即座に、そのボトルネックリンクを経路上に含むセッションの集合を取得することができる。この抽出されたセッション集合は、ボトルネックリンクを共有するセッション群であるため、各々の通信が輻輳を生じさせている一因となっている。そこで、この抽出されたセッション群の通信が送信帯域制限される。
【００８１】
従って、実施例１によれば、或るセッションの輻輳が検出された場合に早急にその原因となっている通信を正確に特定し、原因となる通信のみを対象として輻輳を解消させる帯域制御を行うことができる。実施例１によれば、例え、ＷＡＮ１が公衆網のような管理対象外のブラックボックス網であったとしてもそのブラックボックス網内の輻輳を回避することができる。
【実施例２】
【００８２】
以下、実施例２における帯域制御装置（エッジノード）について説明する。先に説明した実施例１では、ＩＣＭＰの時間超過メッセージを用いて各セッションの経路探索が行われ、ボトルネックリンクが検出されていた。実施例２におけるエッジノードは、ＩＣＭＰの時間超過メッセージを用いず、セッションの帯域制御によりＷＡＮ内の輻輳を回避する。実施例２におけるエッジノードを含むＷＡＮ通信システムのシステム構成は、図１に示す実施例１と同様とする。以下に説明する実施例２の構成は例示であり、本実施形態は以下の構成に限定されなるものではない。
【００８３】
〔装置構成〕
図７は、実施例２におけるエッジノード１０の概略構成を示すブロック図である。実施例２におけるエッジノード１０は、図７に示すように、実施例１における、経路探索部２３、ルート情報テーブル２６、及びリンク集合テーブル２７に替え、共有検査部７１、検査通信部７２、及び共有セッションテーブル７３を有する。以下、実施例１と異なる点を中心に、各処理部について説明する。
【００８４】
セッション解析部１２は、新たなセッションを検出した場合、この新たなセッションを示すレコードをセッション管理テーブル１３に追加すると共に、共有検査部７１にその新たなセッションについての情報を通知する。セッション解析部１２は、この通知に応じて、共有検査部７１から共有セッションテーブル７３へのポインタを受け、このポインタをセッション管理テーブル１３の該当レコードの共有情報フィールドに格納する。
【００８５】
図８は、実施例２におけるセッション管理テーブルの例を示す図である。図８に示すように、実施例２におけるセッション管理テーブル１３は、実施例１における、ルート情報フィールドに替え、共有情報フィールドを有する。共有情報フィールドには、後述する共有セッションテーブル７３におけるそのセッションが含まれる共有セッショングループを示すレコードへのポインタが格納される。
【００８６】
共有検査部７１は、セッション解析部１２からの指示により、新たに検出されたセッション（以降、新規セッションと表記する）とＷＡＮ１内でボトルネックリンクとなり得る
リンクを共有する他のセッションを検査する。ＷＡＮ１内のボトルネックリンクとなり得るリンクを共有するセッションの集合を共有セッショングループと表記する。
【００８７】
図９は、共有セッショングループを示すイメージ図である。ＷＡＮ１内には、ルータ等のような複数の中継装置９２、９３、９４及び９５が存在する。各中継装置間は、所定の物理帯域幅を持つリンク９７、９８及び９９でそれぞれ接続されている。各リンクは、各セッションを実現するための通信に利用される。リンク９７にとっては、セッション９１（＃２）、９１（＃３）及び９１（＃４）が共有セッションとなる。また、リンク９８にとっては、セッション９１（＃２）及び９１（＃３）が共有セッションとなる。
【００８８】
ところで、図９では、各リンク９７、９８及び９９を示す各ブロックはその物理帯域幅に応じた大きさでそれぞれ示される。図９の例では、リンク９８は物理帯域幅が他のリンクより小さく、かつ、端末９０（＃２）及び９０（＃３）のセッション９１（＃２）及び９１（＃３）を通している。このような状態で、もし、リンク９８に他のセッションが割り当てられた場合、リンク９８がボトルネックリンクとなり、輻輳が生じる可能性が高い。ところが、リンク９７は、３つのセッション９１（＃２）、９１（＃３）及び９１（＃４）で共有されているものの、物理帯域幅が他のリンクよりも大きいため、他のセッションが追加されたとしても輻輳が生じない可能性もある。図９の例によれば、共有検査部７１は、リンク９８のようなボトルネックリンクとなり得るリンクを共有するセッション９１（＃２）及び９１（＃３）を共有セッショングループと決める。
【００８９】
共有検査部７１により決定された共有セッショングループについての情報は共有セッションテーブル７３に格納される。図１０は、共有セッションテーブル７３の例を示す図である。共有セッションテーブル７３の各レコードには、各共有セッショングループについての情報として、ボトルネックリンクとなり得るリンクを共有するセッションのセッションＩＤのリストがそれぞれ格納される。更に、各レコードでは、各セッションＩＤがその優先順位毎に区分けされて格納される。共有セッションテーブル７３における各セッションの優先順位は、セッション管理テーブル１３に格納される優先順位が利用される。各レコードでは、そのグループに含まれる全セッションのうち最高優先順位を持つセッションの１つが代表セッション（図１０の下線が引かれたセッション）に設定される。また、各レコードでは、そのグループの最高優先順位がそれぞれ設定される。
【００９０】
共有検査部７１は、新規セッションの情報を得ると、その新規セッションが共有セッションテーブル７３に格納されるいずれの共有セッショングループに属するかを検査する。この検査手法の概念を以下に説明し、詳細については動作例の項において説明する。共有検査部７１は、共有セッショングループの代表セッションの送信帯域幅を所定帯域幅小さくし、新規セッションの送信帯域幅をその所定帯域幅分大きくするような送信帯域制御を帯域制御部２５に指示する。
【００９１】
共有検査部７１は、この送信帯域制御の開始から所定時間経過後、新規セッションについてＲＴＴの増大及びパケットロス率の増大が生じた場合、その新規セッションがその代表セッションとボトルネックリンクとなり得るリンクを共有しないと判定する。一方で、共有検査部７１は、送信帯域制御の開始から所定時間経過しても新規セッションについてＲＴＴの増大等が生じない場合、その新規セッションがその代表セッションとボトルネックリンクとなり得るリンクを共有する、即ち、その代表セッションと同じ共有セッショングループに属すると判定する。当該所定時間は、例えば、ＲＴＴの２倍の時間が利用される。共有検査部７１は、この判定結果に応じて、共有セッションテーブル７３における同じ共有セッショングループを示すレコードにその新規セッションのセッションＩＤを含める。
【００９２】
以下、共有セッショングループに属するか否かの上記判定手法の根拠について説明する。図９の例において、セッション９１（＃２）が新規セッションであり、セッション９１（＃３）が代表セッションであると仮定する。この場合、例えば、共有検査部７１は、セッション９１（＃２）の送信帯域幅を１００（Ｍｂｐｓ）増やし、セッション９１（＃３）の送信帯域幅を１００（Ｍｂｐｓ）減らすような送信帯域制御を帯域制御部２５に指示する。この例では、セッション９１（＃２）及び９１（＃３）の合計送信帯域幅は制御前と制御後とで変わらないため、ＲＴＴの増大等が生じない。すなわち、セッション９１（＃２）及び９１（＃３）はボトルネックリンク９８を共有する同一共有セッショングループと判定することができる。
【００９３】
一方、セッション９１（＃２）が新規セッションであり、セッション９１（＃４）が代表セッションである場合には、送信帯域制御後のセッション９１（＃２）及び９１（＃３）の合計送信帯域幅は、制御前よりも１００（Ｍｂｐｓ）増加することになる。この例では、リンク９８で輻輳が生じ、ＲＴＴの増大等が発生する。すなわち、セッション９１（＃２）及び９１（＃４）はボトルネックリンク９８を共有せず、同一共有セッショングループに属さないと判定することができる。
【００９４】
つまり、共有検査部７１は、送信帯域制御前と送信帯域制御後とで合計送信帯域幅が変わらないか所定帯域幅分増えてしまうかをＲＴＴの増加等で検出することで、共有セッショングループを検査する。ここで、所定帯域幅は、シミュレーション等を繰り返すことにより最適な値に設定されればよく、例えば、新規セッションの実績送信帯域幅の０．５倍の帯域幅に設定される。
【００９５】
上述のような送信帯域制御に関しては、共有検査部７１は、具体的には、新規セッション及び代表セッションの各送信帯域幅を検査用帯域幅として指定することにより、帯域制御部２５にその送信帯域制御を依頼する。帯域制御部２５は、この指定に基づいて、新規セッション及び代表セッションの各送信帯域幅が検査用帯域幅となるように、出力制御器１５を制御する。帯域制御部２５は、セッション管理テーブル１３の実績送信帯域幅フィールドを監視し、代表セッションの実績送信帯域幅が指定の検査用帯域幅を越えた場合に、代表セッションが格納されるセッションキュー１４からの取り出しを停止するよう出力制御器１５に指示する。一方で、帯域制御部２５は、新規セッションの実績送信帯域幅が指定の検査用帯域幅より小さい場合には、検査通信部７２に検査用のダミーパケットを指定の検査用帯域幅に満たない量分送信するように指示する。
【００９６】
また、帯域制御部２５は、応答確認処理部２４から輻輳の発生の通知を受けた場合の処理が実施例１と異なる。帯域制御部２５は、輻輳発生の通知を受けると、共有セッションテーブル７３からその通知の対象となるセッションＩＤを含む共有セッショングループについての情報を抽出する。帯域制御部２５は、抽出された共有セッショングループを帯域幅制限対象として、実施例１と同様の手法によりその共有セッショングループに含まれるセッションの送信帯域幅を制限する。
【００９７】
上述のような共有セッショングループの検査中においては、セッション管理テーブル１３にはその検査対象である新規セッションを示すレコードが格納されているが、共有セッションテーブル７３にはその新規セッションを示すセッションＩＤが格納されていない。帯域制御部２５は、輻輳発生の通知の対象となるセッションＩＤが共有セッションテーブル７３に含まれていない場合には、共有セッショングループの検査中と判断し、このセッションＩＤと共に輻輳の発生を共有検査部７１に通知する。
【００９８】
検査通信部７２は、帯域制御部２５からの指示により、指定された帯域幅分の検査用ダミーパケットを生成し、出力制御器１５へ送る。以降、この検査用ダミーパケットを単に
検査パケットと表記する。検査パケットには、例えば、宛先ポート番号フィールドに廃棄（DISCARD）ポート（ポート番号＝９）が設定され、宛先ＩＰアドレスフィールドに当該
新たなセッションの宛先ＩＰアドレスが設定されたＵＤＰの廃棄パケットが利用される。
【００９９】
［動作例］
以下、実施例２における帯域制御装置の動作例について図１１及び図１２を用いて説明する。
【０１００】
図１１は、実施例２における共有セッショングループの検査の動作例を示すフローチャートである。セッション解析部１２は、拠点側受信部１１で受信されたパケットの解析結果に基づいて、この受信パケットに応じて識別されたセッションがセッション管理テーブル１３で既に管理されているか否かを判定する。セッション解析部１２は、当該セッションがセッション管理テーブル１３に未だ格納されていない場合、当該セッションが新規セッションであると判定する（Ｓ１０１）。図１１では、このセッション解析部１２で検出された新規セッションを新規セッション（ｉ）と表記している。セッション解析部１２は、この新規セッションを示すレコードをセッション管理テーブル１３に追加すると共に、共有検査部７１にその新規セッションについての情報を通知する。
【０１０１】
共有検査部７１は、新規セッションの情報を得ると、共有セッションテーブル７３に格納されるレコードのうち優先度が高い共有セッショングループを示すレコードから順に選択する（Ｓ１０２）。共有検査部７１は、選択された共有セッショングループの代表セッションを共有セッションテーブル７３から抽出する（Ｓ１０３）。図１１では、この抽出された代表セッションを代表セッション（ｊ）と表記している。
【０１０２】
共有検査部７１は、新規セッション（ｉ）と代表セッション（ｊ）とがボトルネックリンクとなり得るリンクを共有しているか否かを以下のように検査する。共有検査部７１は、代表セッション（ｊ）の検査用帯域幅（Ｊ）と、新規セッション（ｉ）の検査用帯域幅（Ｉ）と、を決定する。具体的には、共有検査部７１は、代表セッション（ｊ）の実績送信帯域幅から新規セッション（ｉ）の実績送信帯域幅に検査係数を乗算した値を減算した値を代表セッション（ｊ）の検査用帯域幅（Ｊ）に決定する（Ｓ１０４）。図１１の例では、検査係数を０．５に設定する。共有検査部７１は、新規セッション（ｉ）の実績送信帯域幅に新規セッション（ｉ）の実績送信帯域幅に検査係数を乗算した値を加算した値を新規セッション（ｉ）の検査用帯域幅（Ｉ）に決定する（Ｓ１０５）。各セッションの実績送信帯域幅は、セッション管理テーブル１３の該当レコードの実績送信帯域幅フィールドからそれぞれ抽出される。
【０１０３】
共有検査部７１は、新規セッション（ｉ）及び代表セッション（ｊ）の各検査用帯域幅（Ｉ）及び（Ｊ）と共に、送信帯域制御要求を帯域制御部２５に送る（Ｓ１０６）。帯域制御部２５は、新規セッション（ｉ）及び代表セッション（ｊ）がそれぞれ各検査用帯域幅（Ｉ）及び（Ｊ）で送信されるように出力制御器１５を制御する。具体的には、帯域制御部２５は、セッション管理テーブル１３に格納される代表セッション（ｊ）の実績送信帯域幅が検査用帯域幅（Ｊ）を越える場合には、代表セッション（ｊ）が格納されるセッションキュー１４からの取り出しを停止するよう出力制御器１５に指示する。これにより、帯域幅が制限された代表セッション（ｊ）のパケットは、検査用帯域幅（Ｊ）を超えないようにセクションキュー１４から取り出され、送信される。
【０１０４】
一方で、帯域制御部２５は、新規セッション（ｉ）の実績送信帯域幅が検査用帯域幅（Ｈ）より小さい場合には（Ｓ１０７；ＹＥＳ）、検査用帯域幅（Ｈ）から実績送信帯域幅を引いた帯域幅の情報と共に、検査パケットの送信を検査通信部７２に依頼する。
【０１０５】
検査通信部７２は、帯域制御部２５からの依頼により、新規セッション（ｉ）と同一宛先のＵＤＰの廃棄パケットを生成し、その廃棄パケットを検査用帯域幅に満たない量分、出力制御器１５へ送る（Ｓ１０８）。
【０１０６】
応答確認処理部２４は、セッション管理テーブル１３に基づいて実施例１と同様にＲＴＴの増大やパケットロス率を監視することにより、各セッションにおいて輻輳が発生しているか否かを判定する。帯域制御部２５は、応答確認処理部２４から輻輳発生の通知を受けると、共有セッションテーブル７３にその通知の対象となるセッションＩＤが格納されているか否かを判定する。このセッションＩＤが新規セッション（ｉ）のセッションＩＤである場合には、このセッションＩＤは共有セッションテーブル７３には格納されていない。この場合、帯域制御部２５は、共有セッショングループ検査中と判断し、新規セッション（ｉ）のセッションＩＤと共に、輻輳発生の通知を共有検査部７１に送る。
【０１０７】
共有検査部７１は、この輻輳発生の通知及びセッションＩＤを受けると、そのセッションＩＤの共有セッショングループ検査の開始から所定時間（２×ＲＴＴ時間）経過しているか否かを判定する。共有検査部７１は、検査の開始から所定時間経過している場合には、新規セッション（ｉ）で輻輳発生と判断し（Ｓ１１０；ＹＥＳ）、新規セッション（ｉ）と代表セッション（ｊ）とは同一共有セッショングループに属さないと判定する（Ｓ１１２）。
【０１０８】
一方で、共有検査部７１は、検査の開始から所定時間経過しても輻輳発生の通知を受領しない場合には、新規セッション（ｉ）で輻輳発生しないと判断する（Ｓ１１０）。共有検査部７１は、新規セッション（ｉ）で輻輳発生しないと判断すると（Ｓ１１０；ＮＯ）、新規セッション（ｉ）と代表セッション（ｊ）とは同一共有セッショングループに属すると判定する（Ｓ１１１）。
【０１０９】
共有検査部７１は、新規セッション（ｉ）と代表セッション（ｊ）とは同一共有セッショングループに属すると判定すると、共有セッションテーブル７３におけるその代表セッション（ｊ）が属する共有セッショングループのレコードに、新規セッション（ｉ）のセッションＩＤを追加する。共有検査部７１は、共有セッションテーブル７３に他の共有セッショングループの存在を確認する（Ｓ１１３）。共有検査部７１は、他の共有セッショングループがない場合には（Ｓ１１３；ＮＯ）、処理を終了する。一方で、共有検査部７１は、他の共有セッショングループがある場合には（Ｓ１１３；ＹＥＳ）、共有セッションテーブル７３から次に優先度が高い共有セッショングループを示すレコードを選択する（Ｓ１０２）。以降、新たに選択された共有セッショングループについて上述と同様の処理が実行される。
【０１１０】
図１２は、実施例２における送信帯域制御の動作例を示すフローチャートである。実施例２における送信帯域制御は、図６Ａ及び図６Ｂに示す実施例１と、セッションの集合（Ｓ）の取得の仕方が異なり、その他の処理は実施例１と同様である。
【０１１１】
実施例１と同様に、応答確認処理部２４においてセッションの輻輳発生が検出される（Ｓ６１）。帯域制御部２５は、セッションＩＤと共にセッションの輻輳発生の通知を受けると、セッション管理テーブル１３の共有情報フィールドに格納されている共有セッションテーブルへのポインタを取得する。帯域制御部２５は、この取得されたポインタにより共有セッションテーブル７３の該当レコードを特定する。この特定されたレコードは、対象セッションが含まれる共有セッショングループを示すレコードである。
【０１１２】
帯域制御部２５は、共有セッションテーブル７３において特定されたレコードに含まれるセッションの集合（Ｓ）を主とする（Ｓ１２２）。以降、実施例１と同様の手法により
、送信帯域制御が実行される（Ｓ６６以降）。
【０１１３】
〈実施例２の作用及び効果〉
実施例２における帯域制御装置１０では、拠点網２からＷＡＮ１方向へ送出すべきパケットを解析することにより、新規セッションが検出されると、共有検査部７１によりこの新規セッションとＷＡＮ１内でボトルネックリンクとなり得るリンクを共有する他のセッションが検査される。この検査では、ＩＣＭＰの時間超過メッセージを用いることなく、セッションの帯域制御によりＷＡＮ１内のボトルネックリンクとなり得るリンクを共有するセッションの集合が特定される。
【０１１４】
これにより、実施例２によれば、ＩＣＭＰの時間超過メッセージに対応しない中継装置がＷＡＮ１内に含まれていた場合であっても、ボトルネックリンクとなり得るリンクを共有するセッションの集合を適切に特定することができる。
【０１１５】
また、実施例２では、新規セッションが検出された際にその新規セッションとボトルネックリンクとなり得るリンクを共有するセッションの集合が、取得され、共有セッションテーブル７３に格納される。
【０１１６】
これにより、実施例２によれば、輻輳が発生したセッションが検出された場合に早急にその原因となっている通信を正確に特定し、原因となる通信のみを対象として輻輳を解消させる帯域制御を行うことができる。実施例２によれば、例え、ＷＡＮ１が公衆網のような管理対象外のブラックボックス網であり、かつ、ＷＡＮ１内の中継装置がＩＣＭＰの時間超過メッセージに対応していない場合であったとしても、ＷＡＮ１内の輻輳を回避することができる。
【０１１７】
［補足］
上述の実施例１及び２では、応答確認処理部２４がＡＣＫパケットを監視することで、輻輳の発生したセッションを特定していた。つまり、応答確認処理部２４において輻輳発生を検出し得るセッションはＴＣＰセッションである。ところが、セッション管理テーブル１３、ルート情報テーブル２６、リンク集合テーブル２７、及び共有セッションテーブル７３で管理されるセッションは、ＴＣＰセッションに限定されない。これにより、輻輳発生が検出されたＴＣＰセッションとボトルネックリンクを共有するＴＣＰセッション以外のセッション（例えばＵＤＰセッション）も当然に送信帯域幅が制限される対象となり得る。また、実施例２では、新規セッションがＴＣＰ以外のセッションである場合であっても、帯域制御により共有セッショングループの検査が行われる。
【０１１８】
［その他］
〈ハードウェアの構成要素（Component）及びソフトウェアの構成要素（Component）について〉
ハードウェアの構成要素とは、ハードウェア回路であり、例えば、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、ゲートアレイ、論理ゲートの組み合わせ、信号処理回路、アナログ回路等がある。
【０１１９】
ソフトウェアの構成要素とは、ソフトウェアとして上記処理を実現する部品（断片）であり、そのソフトウェアを実現する言語、開発環境等を限定する概念ではない。ソフトウェアの構成要素としては、例えば、タスク、プロセス、スレッド、ドライバ、ファームウェア、データベース、テーブル、関数、プロシジャ、サブルーチン、プログラムコードの所定の部分、データ構造、配列、変数、パラメータ等がある。これらソフトウェアの構成要素は、コンピュータ内において、１又は複数のメモリ上で実現されるか、或いは、１又は複数のメモリ上のデータが１又は複数のプロセッサ（例えば、ＣＰＵ（Central Proces
sing Unit）、ＤＳＰ（Digital Signal Processor）等）で実行されることにより実現さ
れる。
【０１２０】
なお、上述の各実施形態は、上記各処理部の実現手法を限定するものではない。上記各処理部は、上記ハードウェアの構成要素又はソフトウェアの構成要素若しくはこれらの組み合わせとして、本技術分野の通常の技術者において実現可能な手法により構成されていればよい。
【０１２１】
〈付記〉
以上の本実施形態に関し、更に以下の付記を開示する。各項に開示される態様は、必要に応じて可能な限り組み合わせることができる。
（付記１）
第１網から第２網へパケットの中継を行う中継装置において、
前記第１網から前記第２網へ中継される各パケットに設定されている少なくとも宛先アドレス及び送信元アドレスでそれぞれ特定される複数の通信単位のうち、輻輳の生じた通信単位を検出する輻輳検出手段と、
前記複数の通信単位のうち、前記輻輳検出手段で検出された輻輳の生じた通信単位との間で前記第２網内の少なくとも１つの特定リンクを共有する他の通信単位を特定する特定手段と、
前記複数の通信単位のうち、前記特定手段により特定された他の通信単位及び前記輻輳の生じた通信単位の前記第２網への送信帯域を制限する帯域制御手段と、
を備えることを特徴とする中継装置。
（付記２）
前記輻輳の生じた通信単位の経路情報を収集する収集手段と、
前記収集手段により収集された経路情報に応じて、前記輻輳の生じた通信単位の経路に含まれるボトルネックリンクを検出する検出手段と、
を更に備え、
前記特定手段は、前記検出手段により検出されたボトルネックリンクを前記少なくとも１つの特定リンクとして共有する他の通信単位を特定する、
ことを特徴とする付記１に記載の中継装置。
（付記３）
前記収集手段は、前記複数の通信単位の宛先アドレス毎の経路情報をそれぞれ収集し、
前記特定手段は、前記収集手段により収集された前記複数の通信単位の経路情報に基づいて、該経路情報に含まれるリンク毎に該リンクを利用する通信単位の集合情報をそれぞれ記憶する記憶手段を含む、
ことを特徴とする付記１又は２に記載の中継装置。
（付記４）
前記輻輳検出手段は、往復遅延時間の平均値及び往復遅延時間の平均偏差を用いて各通信単位の往復遅延時間が増大しているか否かを判定し、輻輳の生じたセッションを特定するために該往復遅延時間の増大の判定結果を用いることを特徴とする付記１から３のいずれか１つに記載の中継装置。
（付記５）
前記複数の通信単位のうちの２つの通信単位において、一方の通信単位の送信帯域幅を所定帯域幅分増やし、かつ、他方の通信単位の送信帯域幅を該所定帯域幅分減らすような帯域制御を前記帯域制御手段に実行させ、該帯域制御の後の該一方の通信単位の通信状態に応じて、該一方の通信単位と該他方の通信単位とが前記第２網内の少なくとも１つの特定リンクを共有するか否かを判定する判定手段、
を更に備えることを特徴とする付記１に記載の中継装置。
（付記６）
前記判定手段による判定結果に基づいて、前記第２網内において少なくとも１つの特定
リンクを共有する通信単位の集合に関する情報を記憶する記憶手段、
を更に備える付記５に記載の中継装置。
（付記７）
第１網から第２網へパケットの中継を行う中継装置で実行される帯域制御方法において、
前記第１網から前記第２網へ中継される各パケットに設定されている少なくとも宛先アドレス及び送信元アドレスでそれぞれ特定される複数の通信単位のうち、輻輳の生じた通信単位を検出するステップと、
前記複数の通信単位のうち、前記検出された輻輳の生じた通信単位との間で前記第２網内の少なくとも１つの特定リンクを共有する他の通信単位を特定するステップと、
前記複数の通信単位のうち、前記特定された他の通信単位及び前記輻輳の生じた通信単位の前記第２網への送信帯域を制限するステップと、
を含むことを特徴とする帯域制御方法。
【符号の説明】
【０１２２】
１  ＷＡＮ
２、３、４  拠点網
１０  帯域制御装置（エッジノード）
１１  拠点側受信部
１２  セッション解析部
１３  セッション管理テーブル
１４  セッションキュー
１５  出力制御器
１６  ＷＡＮ側送信部
２１  ＷＡＮ側受信部
２２  パケット解析部
２３  経路探索部
２４  応答確認処理部
２５  帯域制御部
２６  ルート情報テーブル
２７  リンク集合テーブル
２８  拠点側送信部
７１  共有検査部
７２  検査通信部
７３  共有セッションテーブル
【図１】
0005440200.tif 000002
【図２】
0005440200.tif 000003
【図３】
0005440200.tif 000004
【図４】
0005440200.tif 000005
【図５】
0005440200.tif 000006
【図６Ａ】
0005440200.tif 000007
【図６Ｂ】
0005440200.tif 000008
【図７】
0005440200.tif 000009
【図８】
0005440200.tif 000010
【図９】
0005440200.tif 000011
【図１０】
0005440200.tif 000012
【図１１】
0005440200.tif 000013
【図１２】
0005440200.tif 000014