ネットワーク障害検知プログラム、システム、及び方法
【課題】送信経路上の障害箇所の特定（検知）精度を維持しつつ、監視サーバが解析の対象とする情報量をより抑えるための技術を提供する。
【解決手段】計測エージェントを実行するノード３０には、配信サーバから送信されたサービストラヒックを計測する計測部３１、そのサービストラヒックが送信される送信経路全体に対応する論理木を自律的に構築し、その論理木上で隣接する隣接ノード３０を発見する隣接エージェント発見部３２、及び隣接ノード３０によって決定される監視対象範囲の障害状況を監視する障害箇所推定部３３が実現される。それにより、各ノード３０で障害の特定に必要な負荷や情報を分散させて、監視サーバに要求される負荷を軽減させる。
【解決手段】計測エージェントを実行するノード３０には、配信サーバから送信されたサービストラヒックを計測する計測部３１、そのサービストラヒックが送信される送信経路全体に対応する論理木を自律的に構築し、その論理木上で隣接する隣接ノード３０を発見する隣接エージェント発見部３２、及び隣接ノード３０によって決定される監視対象範囲の障害状況を監視する障害箇所推定部３３が実現される。それにより、各ノード３０で障害の特定に必要な負荷や情報を分散させて、監視サーバに要求される負荷を軽減させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信サーバからサービストラヒックが送信されるネットワーク上の経路に発生する障害を検知（特定）するための技術に関する。
【背景技術】
【０００２】
現在、インターネットに代表されるネットワークは、各種サービスを提供するために幅広く用いられている。そのサービスのなかには、映像配信やオンラインゲームのように、サービストラヒックを比較的に長い時間、継続して送信するサービスがある。
【０００３】
そのようなサービスでは、サービストラヒックの転送経路上にスイッチの故障やルータでの輻輳等による障害が発生すると、サービストラヒックの受信品質が大きく低下する。例えばパケットロス率が大きくなると、サービストラヒックの送信に必要な時間がより長くなる、といった不具合が発生する。このことから、経路（ネットワーク）上に発生した障害には迅速に対応することが重要となっている。
【０００４】
これまでは、ネットワーク上で障害が発生した障害箇所は、ネットワーク管理者がノウハウを基に特定していた。しかし、管理者による障害箇所の特定には、非常に長い時間を要するのが普通である。このことから近年では、ネットワーク上の障害箇所を自動的に特定する技術が検討されている。
【０００５】
図２９は、従来のネットワーク障害検知システムにおける障害箇所推定方法の説明図である。このシステムは、アプリケーションサーバから送信されるサービストラヒックの経路上に発生した障害を自動的に検知するためのものである。
【０００６】
図２９に示すネットワーク障害検知システムは、ソフトウェアである計測エージェントを実行する多数のノード、及び監視サーバ２８０を備えた構成である。計測エージェントを実行するノードについては、そのエージェントを実行しないノードと区別するために、以降「計測ノード」と呼ぶことにする。
【０００７】
図２９では、計測ノードとして２７１或いは２７２を付した２つを示している。それら計測ノード２７１及び２７２のうちの何れであっても良い場合には、符号として２７０を用いることにする。これは２６１或いは２６２を付した２つのアプリケーションサーバ、及び２９１或いは２９２を付した計測ノード２７０以外のノードでも同様である。例えばアプリケーションサーバでは、アプリケーションサーバ２６１及び２６２のうちの何れであっても良い場合には符号として「２６０」を用いる。
【０００８】
計測エージェントは、アプリケーションサーバ２６０から送信されたサービストラヒックの受信品質およびサービストラヒックの送信経路を計測し、計測した受信品質とサービストラヒックの送信経路とを含む計測結果を監視サーバ２８０に送信する機能を備えている。監視サーバ２８０は、各計測ノード２７０から受信した計測結果を解析し、障害の発生の有無を判定する。障害が発生していると判定した場合に、障害箇所を推定する。このようなことから、障害箇所の推定は、計測ノード２７０による計測（ＳＴ１）、計測結果の監視サーバ２８０への報告（ＳＴ２）、監視サーバ２８０による解析（ＳＴ３）、のシーケンスで行われる。
【０００９】
障害箇所の推定は、以下のようにして行われる。ここでは、アプリケーションサーバ２６１が送信するサービストラヒックは計測ノード２７２によって計測され、アプリケーションサーバ２６２が送信するサービストラヒックは計測ノード２７１によって計測されることを想定する。つまり、アプリケーションサーバ２６１が送信するサービストラヒックは、アプリケーションサーバ２６１とノード２９１間のリンクＬ４、ノード２９１とノード２９２間のリンクＬ２、及びノード２９２と計測ノード２７２間のリンクＬ５を含む送信経路であるパス１を介して計測ノード２７２に転送され、アプリケーションサーバ２６２が送信するサービストラヒックは、アプリケーションサーバ２６２とノード２９２間のリンクＬ３、リンクＬ２、及びノード２９１と計測ノード２７１間のリンクＬ１を含む送信経路であるパス２を介して計測ノード２７１に転送されることを想定する。
【００１０】
計測ノード２７２が監視サーバ２８０に送信する計測結果には、受信品質の他に、サービストラヒックの送信経路が含まれる。図２９中に示す表では、送信経路に含まれるリンクは「１」を表記することで示している。表中の「劣化」は、計測した受信品質が悪い、つまり送信系路上の何れかのリンクに障害が発生していることを表している。
【００１１】
受信品質は、サービストラヒックが輻輳することで低下する。このことから監視サーバ２８０は、受信品質が「劣化」の送信経路間で共通するリンクを抽出し、そのリンクを障害箇所と推定する。それにより、図２９に示す例では、パス１及び２で共通するリンクＬ２が障害箇所と推定される。
【特許文献１】特開２００６−２３８０５２号公報
【非特許文献１】N.G. Duffield, and et. al., Simple Network Performance Tomography,” In Proc. of ACM SIGCOMM Internet Measurement Conference 2003.
【非特許文献２】Q. Lv, et. al., “Search and Replication in Unstructured Peer-to-Peer Networks,” Proc. of ICS’02, pp. 84-95, 2002.
【非特許文献３】E. Keong, et. al., “A Survey and Comparisonof Peer-to-Peer Overlay Network Schemes,” Journal of IEEE Communication Surveys, Vol. 7, No. 2, pp. 72-93, 2005.
【非特許文献４】I. Stoica, et. al., ``Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications,” Journal of IEEE/ACM Transactions on Networking, Vol. 11, No. 1, 2003.
【発明の開示】
【発明が解決しようとする課題】
【００１２】
上述したような従来のネットワーク障害検知システムでは、各計測ノード２７０が送信する計測結果を監視サーバ２８０が解析して、障害箇所を特定する。このようなことから、監視サーバ２８０が解析の対象とする情報量が膨大となり易いという問題点があった。その問題点は、必要なハードウェア資源が大きくなる、負荷が重くなって障害箇所の特定にかかる時間が長くなる、といった形で表面化する。
【００１３】
膨大な情報量を管理する必要性を回避して、高速に障害箇所を特定するために、複数の監視サーバを設置して分散処理させる手法も提案されている。しかし、そのような分散処理を採用した場合、各監視サーバは全情報のうちの一部を対象に解析を行うことになる。このため、ネットワーク全体を俯瞰する形での解析を行うことができず、障害箇所の特定精度が低下することが知られている。監視サーバは、ネットワークの規模に応じた数分、設置する必要がある。このため、大規模なネットワークでは、多数の監視サーバを設置しなければならず、設備投資にかかるコストは膨大となる。このようなことから、複数の監視サーバを用いた分散処理は実用上、望ましいものではない。
【００１４】
本発明は、送信経路上の障害箇所の特定（検知）精度を維持しつつ、監視サーバが解析の対象とする情報量をより抑えるための技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明を適用した１システムでは、ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するために、送信経路上に存在し、配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを備えている。各ノードは、サービストラヒックを計測する計測手段と、送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、計測手段による計測結果を用いて、隣接ノード特定手段が設定した監視対象リンクのなかで障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を隣接ノード及び監視サーバのうちの一方に送信する障害リンク推定手段と、を具備する。監視サーバは、ノードから受信した障害箇所の推定結果を解析して、送信経路上の障害箇所を特定する障害リンク特定手段、を具備する。
【００１６】
上記システムを構成するノードは、サービストラヒックの送信経路に対応した論理的なツリー構造を自律的に構築し、該送信経路の中で障害の発生を監視すべき監視対象リンクを自動的に設定し、設定した監視対象リンクを監視して、そのなかで障害が発生している可能性のある監視対象リンクを障害箇所として推定する。そのような障害箇所の推定により、送信経路全体のなかで発生した障害を特定するために考慮すべき範囲（リンク）は非常に狭められる。しかし、障害箇所の特定は、配信サーバから送信されているサービストラヒックの送信経路全体の情報を用いて行う形となる。そのため，既存の集中型のシステムには及ばないが，ネットワークの広範囲を俯瞰する形での解析を行うことができる。これらの結果、障害箇所の特定精度は高く維持させつつ、監視サーバが解析の対象とする情報量はより抑えられることとなる。それにより、監視サーバに必要なハードウェア資源は抑えられ、その負荷は軽減される。
【発明の効果】
【００１７】
本発明を適用した場合には、送信経路上の障害箇所の特定（検知）精度を維持しつつ、監視サーバが解析の対象とする情報量をより抑えることができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態によるネットワーク障害検知システムの概要を示す図である。
図１中の物理ネットワークは、サービストラヒックを送信する配信サーバ１０毎に存在する、ネットワーク全体でそのサービストラヒックの送信に用いられる部分、つまり送信経路の集合体に相当する。本実施形態では、物理ネットワークを構成するノード３０に、その物理ネットワークに対応する論理木（論理的なツリー構造）を自律的に構築させ、各ノード３０に障害の推定に係わる処理を実行させる。監視サーバ２０には、各ノード３０で確定できていない（推定はできているが、特定はできていない）障害を特定させる。そのようにして、発生した障害の特定に要する処理を各ノード３０に分散させて実行させることにより、障害箇所の特定精度を維持させつつ、監視サーバ２０による解析の対象となる情報量を低減させる。
【００１９】
論理木を自律的に構築させるノード３０は、分散処理用のソフトウェアである計測エージェントを実行可能なデータ処理装置（コンピュータ）として用いることが可能なものである。本実施形態では、論理木の構築にオーバレイネットワーク技術を利用している。オーバレイネットワーク技術とは、以下のようなものである。
【００２０】
オーバレイネットワーク技術は、インターネットに代表されるネットワークを構成する
ノード群（ルータ、コンピュータ、ゲートウェイ、など）の中で、ある定められた目的に用いるノードのみが存在する論理的なネットワークを構築する技術である。論理ネットワーク内では、その目的が達成しやすいようにノード間に論理的なリンクが確立されており、その論理的なリンクに沿ってノード間で情報の交換が行われる。ピアツーピア（Ｐ２Ｐ）ネットワークは、各ノードが所持する情報の流通・共有・発見に特化したオーバレイネットワークである。そのＰ２Ｐネットワークでは、全てのノードが目的の情報を短時間で発見できるように、自身のノード（自ノード）に論理ネットワーク上で隣接する隣接ノードおよびデータの転送規則が設定されている。本実施形態では、このＰ２Ｐネットワーク技術を応用したオーバレイネットワーク技術を利用している。
【００２１】
Ｐ２Ｐネットワークは、確実に目的の情報は発見できないが、実装が容易でありキーワード検索のような曖昧検索を得意とする非構造型Ｐ２Ｐネットワーク（非特許文献２）と、実装は複雑であるが目的の情報を確実に発見できる構造型Ｐ２Ｐネットワーク（非特許文献３）とに大別できる。本実施形態では構造型Ｐ２Ｐネットワークを採用している。しかし、以下の特徴を持つオーバレイネットワークならば採用は可能である。
・Ｐ２Ｐネットワーク全体で管理するＩＤの空間が与えられており、各ノードは、その中で決められた範囲のＩＤを管理している。ここで、あるＩＤを管理するノードは１台のみとなっている
・各ノードは、管理対象のＩＤに対応する情報または情報のインデックスを管理している
・論理ネットワーク上でのデータ転送規則に従ってノード間でメッセージが交換されることにより、指定されたＩＤを管理するノードまで短時間でメッセージを送信することができる
構造型Ｐ２Ｐネットワーク（以降、特に断らない限り「Ｐ２Ｐネットワーク」は構造型Ｐ２Ｐネットワークを指す意味で用いる）に参加している各ノードは、基本的に以下の情報を管理している。
・Ｐ２Ｐネットワーク上で、一意に自身を識別するためのＩＤ(ノードＩＤ)
（一般的に、ＩＰアドレスやポート番号などのノードの識別子をハッシュ関数（ＳＨＡ−１など）に入力することにより算出する）
・Ｐ２Ｐネットワークに参加している複数の他のノードへの経路表（ノードＩＤと識別子の対応表）
（一般的に、log(N)個のノードへの情報を管理 （Ｎ：Ｐ２Ｐネットワークを構成する全ノード数）
Ｐ２Ｐネットワークでは、例えば利用者からあるＩＤに対応する情報の取得要求があった場合、取得要求を受けたノードはそのＩＤを格納した検索メッセージを生成し、経路表の中で、そのＩＤ側で自ノードに最も近いＩＤを持つノードへ検索メッセージを送信する。そのメッセージを受信したノードは、同様に自ノードに最も近いＩＤを持つノードに検索メッセージを転送する。そのようにして転送を繰り返し行うことにより、指定されたＩＤを管理しているノード（以下、対応ノード）に検索メッセージが届けられる。この結果、対応ノードがＩＤに対応する情報を持っている場合には、その情報が要求元のノードへ送信される。このとき、対応ノードへ検索メッセージが届くまでに、検索メッセージは高々log(N)個のノードしか経由しない。
【００２２】
本実施形態では、上述のようなオーバレイネットワーク技術を用いて物理ネットワーク（送信経路）に対応する論理木を自律的に構築する。各ノード３０は、論理木の構築により、送信経路のなかで自ノードが障害の発生を監視すべき監視対象範囲（論理木のなかで隣接するノード間のリンク）を認識し、その監視対象範囲の障害状況を推定、つまり障害が発生しているか否か推定する。その障害状況の推定は、他のノード３０から受信する計測結果を参照して行う。その計測結果とは、計測した受信品質、及びその送信経路を含むメッセージである。
【００２３】
論理木を自律的に構築するノード３０は、本実施形態によるネットワーク障害検知システムの実現用のソフトウェアである計測エージェントを実行するノードである。他のノードと区別するために、計測エージェントを実行するノードは以降「計測ノード」と呼ぶ。計測ノード３０は計測エージェントによって制御されることから、特に断らない限り、計測エージェントは計測ノード３０と同じ意味で用いる。
【００２４】
図２は、計測エージェントによって計測ノード３０上に実現される機能構成を示す図である。図２に示すように、計測エージェントは、配信サーバ１０から送信されたサービストラヒックを計測する計測部３１、論理木を自律的に構築し、その論理木上で隣接する隣接ノードを発見する隣接エージェント発見部３２、及び隣接ノードによって決定される監視対象範囲の障害状況を監視する障害箇所推定部３３をノード３０上に実現させ、計測結果収納データベース（ＤＢ）３４、解析結果収納ＤＢ３５及びグループ情報管理ＤＢ３５を生成・管理する。その計測エージェントは、計測ノード３０が備えた、或いはアクセス可能な記憶装置に格納される。必要に応じて、ネットワーク７０を介して送信するようにしても良い。
【００２５】
図２８は、上記計測ノード３０として用いることが可能なコンピュータのハードウェア構成の一例を示す図である。図２に示す各部３１〜３３の詳細な説明の前に、算計測ノード３０として用いることが可能なコンピュータの構成について具体的に説明する。
【００２６】
図２８に示すコンピュータは、ＣＰＵ８１、メモリ８２、入力装置８３、出力装置８４、外部記憶装置８５、媒体駆動装置８６、及びネットワーク接続装置８７を有し、これらがバス８８によって互いに接続された構成となっている。同図に示す構成は一例であり、これに限定されるものではない。
【００２７】
ＣＰＵ８１は、当該コンピュータ全体の制御を行う。メモリ８２は、プログラム実行、データ更新等の際に、外部記憶装置８５（あるいは可搬型の記録媒体ＭＤ）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ８１は、プログラムをメモリ８２に読み出して実行することにより、全体の制御を行う。
【００２８】
入力装置８３は、例えば、キーボード、マウス等の操作対象装置と接続されたインターフェース、或いはそれらを全て有するものである。操作対象装置に対するユーザの操作を検出し、その検出結果をＣＰＵ８１に通知する。
【００２９】
出力装置８４は、例えば表示装置と接続された表示制御装置、或いはそれらを有するものである。ＣＰＵ８１の制御によって送られてくるデータを表示装置上に出力させる。
ネットワーク接続装置８７は、ネットワーク７０を介して、外部装置である他の計測ノード３０、配信サーバ１０、或いは監視サーバ２０と通信を行うためのものである。外部記憶装置８５は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。
【００３０】
記憶媒体駆動装置８６は、光ディスクや光磁気ディスク等の可搬型の記録媒体ＭＤにアクセスするものである。
図２８に示す構成では、上記計測エージェントは、外部記憶装置８５、若しくは記録媒体ＭＤに格納されているか、或いはネットワーク接続装置８７によりネットワーク７０を介して外部装置から受信される。図２に示すＤＢ３４〜３６は、例えば外部記憶装置８５上に構築される。外部記憶装置８５、若しくは記録媒体ＭＤから読み出された、或いはネットワーク接続装置８７が受信した計測エージェントはメモリ８２に格納され、ＣＰＵ８１により実行される。その計測エージェントを実行することにより、図２８に示す構成のコンピュータは計測モード３０として機能する。
【００３１】
図３は、隣接エージェント発見部３２の機能構成を示す図である。図３に示すように、隣接エージェント発見部３２は、オーバレイネットワーク機能部３２ａ、メッセージ送出部３２ｂ、メッセージ転送部３２ｃ、隣接エージェント決定部３２ｄ、冗長エージェント削除開始部３２ｅ、及び冗長エージェント判断部３２ｆを備えた機能構成となっている。図３中では、配信サーバ１０は「アプリケーションサーバ」と表記している。これは図４でも同様である。
【００３２】
図４は、障害箇所推定部３３の機能構成を示す図である。図４に示すように、障害箇所推定部３３は、計測情報通知部３３ａ、計測結果解析部３３ｂ及び障害箇所通知部３３ｃを備えた機能構成となっている。
【００３３】
隣接エージェント発見部３２、及び障害箇所推定部３３を実現させる計測エージェントは、以下のような処理を計測ノード３０に実行させる。以降は図９〜図１９に示す各種フローチャートを参照して、隣接エージェント発見部３２、及び障害箇所推定部３３の動作について詳細に説明する。
【００３４】
図９は、計測エージェントにより実行される処理の全体的な流れを示すフローチャートである。始めに図９を参照して、その処理の全体的な流れについて具体的に説明する。
計測ノード３０は、ネットワーク７０を構成するルータ等のエンティティか、或いは配信サーバ１０によるサービスを利用する利用者が使用するコンピュータ（パーソナル・コンピュータ（ＰＣ）、ＰＤＡ、或いは家電商品（例えばセットトップボックス）など）である。この計測ノード３０は、論理木上では最下層に位置し、ネットワーク７０上では、配信サーバ１０から送信されるサービストラヒックの最終的な転送先となる。図９に示すフローチャートは、利用者が使用するコンピュータが計測ノード３０であった場合のものである。
【００３５】
計測エージェントは、利用者が使用するコンピュータで配信サーバ１０によるサービスを利用するためのアプリケーション（以降「サービス受信用アプリケーション」と呼ぶ。そのアプリケーションとしては、映像受信（再生）用のもの、電話用のもの、などを挙げることができる）の起動と連動して起動される（ステップＳ１）。この計測エージェントは利用者のコンピュータ上でメモリに常駐させても良い。ホームゲートウェイのようなハードウェア、或いはルータ等が計測ノード３０であった場合には、電源の投入と連動して起動させれば良い。
【００３６】
起動後の計測エージェントは、例えば利用者の指示に従って「計測結果の算出間隔」、「計測結果の解析間隔」、「解析結果の通知間隔」、「受信品質の閾値」、「監視サーバ２０の識別子」といった各種設定パラメータの読み込みを行う（ステップＳ２）。それら設定パラメータとは、例えば「計測結果の算出間隔」や「計測結果の解析間隔」或いは「解析結果の通知間隔」のような時間に係わるパラメータでは１０（秒）といった時間情報である。「受信品質の閾値」では、パケットロス率１％といったように、受信品質を評価する指標と、その指標での閾値とを組みにする情報である。それにより、その情報がパケットロス率１％を示していた場合、実際に計測したパケットロス率が１％を越えれば受信品質は「Ｂａｄ」、そうでなければ受信品質は「Ｇｏｏｄ」と判定される。その指標は、パケット到着間隔のゆらぎなど、受信品質を表すものであれば幅広く適用可能である。
【００３７】
「監視サーバの識別子」とは、例えばそのＩＰアドレスである。その識別子は、ＵＲＬなど監視サーバ２０が一意に識別できる値ならば何でも利用できる。また、監視サーバ２０から通知させても良いし、他の計測ノード３０から通知させても良い。
【００３８】
上記のような各種設定パラメータは、ファイルなどに用意して読み込ませても良い。ルータ等の計測ノード３０では、各種設定ファイルを格納したファイルに用意して、起動後に読み込ませれば良い。
【００３９】
設定パラメータを読み込んだ後は、オーバレイネットワークへ参加し、論理的なリンクを確立するために隣接ノード３０を発見する手続きを行う（ステップＳ３）。オーバレイネットワークへの参加では、例えばChord（非特許文献４）というオーバレイネットワークを想定した場合には、先ずネットワーク７０上で一意に自身を識別できるＩＤを算出した上で、既にオーバレイネットワークに参加している他の計測ノード３０との間で仮想的なリンクを確立する。次に、計測ノード３０はリンクを確立した計測ノード３０との間で検索メッセージを交換することにより、全体として配信（アプリケーション）サーバ１０から計測ノード３０へサービストラヒックが送信される経路に対応する論理木が構築できるように、隣接する計測ノード３０の識別子を把握する。論理木を自律的に構築する上では、以下の特徴を持つオーバレイネットワークであることが望ましい。
・各計測ノード３０は、ある決められた範囲のＩＤを管理している(つまり、あるＩＤを管理している計測ノード３０の数は1個のみ)
・複数の計測ノード３０を経由することにより、どのＩＤを管理する計測ノード３０にも必ずメッセージを届けることが可能
隣接ノード３０を発見する手続きを行った後は、サービストラヒックの送信経路と論理木の構成を比較することにより、監視対象区間を把握する（ステップＳ４）。図３に機能構成を示す隣接エージェント発見部３２は、ステップＳ３及びＳ４の実行により実現される。図４に機能構成を示す障害箇所推定部３３は、後述するステップＳ５〜Ｓ７の実行により実現される。
【００４０】
ステップＳ５では、各種設定パラメータに従い、監視対象区間の障害状況の把握を行う。例えば「計測結果の算出間隔」が１０秒であれば、１０秒が経過するたびに、サービストラヒックの受信結果を「受信品質の閾値」と比較し、受信品質を判定する。「受信品質の閾値」がパケットロス率１％であり、実際のパケットロス率が１．５％であれば、受信品質はＢａｄと判定する。そのように判定される受信品質は、計測結果として計測結果収納ＤＢ３４に格納される。また、「計測結果の解析間隔」が１０秒であれば、１０秒が経過するたびに、計測結果収容ＤＢ３４から計測結果を読み出し、監視対象区間内／外の障害状況を推定する。監視対象区間外の計測結果は、論理木の上流に位置する隣接ノード３０に送信され、監視対象区間内の計測結果は解析結果収容ＤＢ３５に格納される。
【００４１】
ここで、図６及び図７を参照して、計測結果収納ＤＢ３４及び解析結果収納ＤＢ３５のデータ構成について具体的に説明する。図６は、計測結果収納ＤＢ３４のデータ構成を示す図であり、図７は、解析結果収納ＤＢ３５のデータ構成を示す図である。
【００４２】
計測結果収納ＤＢ３４には、図６に示すように、グループ識別子（ＩＤ）、受信品質、及び区間の各データが１レコードに格納される。解析結果収納ＤＢ３５には、図７に示すように、グループ識別子（ＩＤ）毎に、監視対象区間、及び受信品質が１レコードに格納される。
【００４３】
論理木は、配信サーバ１０毎、或いは配信サーバ１０が提供するサービス毎に構築される。これは、配信サーバ１０毎、或いは配信サーバ１０が提供するサービス毎に利用者、つまり送信経路が異なるからである。グループ識別子は、そのように配信サーバ１０毎、或いは配信サーバ１０が提供するサービス毎に構築される論理木を一意に表す情報である。以降は便宜的に、論理木は配信サーバ１０毎に構築されるとの想定で説明を行う。その想定では、グループ識別子は例えば配信サーバ１０のＩＰアドレスから算出されるハッシュ値である。
【００４４】
図９の説明に戻る。
ステップＳ６では、「解析結果の通知間隔」で指定された時間が経過するたびに、解析結果収容ＤＢ３５の情報を読み出し、監視対象区間内に障害が発生しているか否か判定（推定）して、障害が発生していると判定した場合に、その障害が発生していると判定した監視対象区間に関する情報を監視サーバ２０に通知する。ステップＳ７では、「解析結果の通知間隔」で指定された時間が経過するたびに、計測結果収容ＤＢ３４の情報（計測結果）を読み出し、隣接ノード３０に送信する。監視サーバ２０への通知を必要に応じて行い、隣接ノード３０への送信を行った後はステップＳ５に戻る。それにより、障害の発生に対応可能な状態を維持する。
【００４５】
図１０は、ステップＳ３及びＳ４として実行される処理の詳細を示すフローチャートである。隣接エージェント発見部３２は、図１０に示す処理を実行することにより実現される。次に図１０を参照して、隣接エージェント発見部３２を実現させる処理についてより具体的に説明する。
【００４６】
先ず、ステップＳ１１では、配信サーバ１０から受信しているサービストラヒックを監視し、そのサーバ１０の識別子を用いてグループ識別子を算出する。このグループ識別子は、配信サーバ１０のＩＰアドレス（及びポート番号）を用いて算出されるハッシュ値など、配信サーバ１０を一意に識別できる値である。
【００４７】
続くステップＳ１２では、サービストラヒックの送信経路に対応する論理木における自身の隣接エージェントを発見するために、ステップＳ１１で導出したグループ識別子、およびアプリケーションサーバから自ノード３０までのサービストラヒックの送信経路に関する情報を格納した図２０に示すようなリンク構築メッセージを生成する。
【００４８】
ステップＳ１３では、生成したリンク構築メッセージを、自ノード３０が参加しているオーバレイネットワークを介して複数の計測ノード３０の間で交換する。続くステップＳ１４では、メッセージの交換により、サービストラヒックの送信経路に対応する論理木において自ノード３０と隣接関係にある計測ノード３０を把握し、その隣接ノード３０との間で論理的なリンクを確立する。その確立により、論理木における自ノード３０および隣接ノード３０の位置が特定、つまり論理木が構築される。その後はステップＳ１５に移行する。
【００４９】
ステップＳ１５では、構築した論理木における自ノード３０の位置および隣接ノード３０の位置から、サービストラヒックの送信経路における監視対象区間を把握する。その後はステップＳ１１に戻る。それにより、新たな論理木の構築に備える。
【００５０】
図１１〜図１５は、隣接エージェント発見部３２を構成する各部３２ｂ〜３２ｆを実現させる各種処理のフローチャートである。次に図１１〜図１５の各フローチャートを参照して、各部３２ｂ〜３２ｆを実現させる処理について詳細に説明する。
【００５１】
図３に示すオーバレイネットワーク機能部３２ａは、論理木（オーバレイネットワーク）の構築や、オーバレイネットワークを構成する他の計測ノード３０との間の通信を実現させるものである。他の構成要素と連動する形で動作する。このことから、フローチャートを用いて説明する対象から除外している。
【００５２】
図１１は、メッセージ送出部３２ｂを実現させる処理のフローチャートである。始めに図１１を参照して、その送出部３２ｂを実現させる処理について詳細に説明する。この処理は、上記ステップＳ１２及びＳ１３として実行される。
【００５３】
先ず、ステップＳ２１では、自ノード３０が受信しているサービストラヒックを監視し、そのサービストラヒックを送信する配信（アプリケーション）サーバ１０の識別子を取得する。次のステップＳ２２では、取得した配信サーバ１０の識別子を用いて、その配信サーバ１０のグループ識別子を算出する。その後はステップＳ２３に移行する。
【００５４】
ステップＳ２３では、配信サーバ１０と自ノード３０の間でのサービストラヒックの送信経路(サービストラヒックが中継するルータ等の識別子)を取得する。この取得方法としては、計測ノード３０から計測用パケットを送信することにより中継ルータの識別子を調査するTracerouteが代表的であるが、中継ルータの識別子を取得できる方法であればどのようなものでも良い。
【００５５】
ステップＳ２３に続くステップＳ２４では、リンク構築メッセージを作成する。次のステップＳ２５では、作成したリンク構築メッセージ内に、取得したグループ識別子、および取得したサービストラヒックの送信経路を記録する。その記憶により、リンク構築メッセージが完成する（図２０）。
【００５６】
ステップＳ２５の実行後に移行するステップＳ２６では、取得したサービストラヒックの送信経路で自ノード３０と隣接関係（上流側）にある計測ノード３０宛に、自ノード３０が参加しているオーバレイネットワークのメッセージ転送に従い、リンク構築メッセージを送信する。次のステップＳ２７では、ステップＳ２２で取得したグループ識別子に対応する論理木における自ノードの役割を「計測」として、グループ情報管理ＤＢ３６に記録する。その後はステップＳ２１に戻る。
【００５７】
計測部３１はサービストラヒックを監視して受信品質を示す指標を計測する。このことから、計測部３１を実現させる処理は、図９に示す処理とは別に実行される。しかし、その処理は、周知の計測技術を用いて実行されることから、詳細な説明は省略する。その処理により得られた計測結果は、「計測結果の算出間隔」で指定された時間毎に障害箇所推定部３３により参照される。
【００５８】
図５は、グループ情報管理ＤＢ３６のデータ構成を示す図である。図５に示すように、この管理ＤＢ３６は、論理木（グループ識別子）毎に、自ノード３０の役割、サービストラヒックの送信経路上で隣接する計測ノード３０、及び監視対象区間を含むグループ情報を管理するためのＤＢである。隣接ノード３０としては、送信経路上で上流（配信サーバ１０側）に位置するもの、その送信経路上で下流に位置するものを登録するようになっている。監視対象区間は、自ノード３０と下流側の隣接ノード３０の間に確立されたリンクである。この監視対象区間は、図８に示すように、自ノード３０とその隣接ノード３０の間に存在するノードのＩＰアドレスの順序で示している。
【００５９】
役割としての「計測」とは、構築された論理木で最下層に位置する計測ノード３０に要求される役割のことである。論理木の最下層に位置する計測ノード３０は、サービストラヒックの送信先である。従い、計測した受信品質は、送信経路に障害が発生しているか否かを直接、示すものとなる。障害箇所を推定することや、他の計測ノード３０から送信された計測結果を転送する必要はない。このことから、論理木の最下層に位置する計測ノード３０には、計測のみを行えば良いとする「計測」を役割として割り当てるようにしている。監視対象区間は登録しない。図１では、「計測」が役割として割り当てられた計測ノード３０には括弧書きで「６０」を併記している。
【００６０】
括弧書きで「４０」を併記した計測ノード３０では、配信サーバ１０との間のルータに対応する他の計測ノード３０が存在しない。そのような計測ノード３０には、役割として
「代表」が割り当てられる。「代表」及び「計測」の何れも割り当てられない計測ノード３０には、役割として「中継」が割り当てられる。その計測ノード３０には、括弧書きで「５０」を併記している。論理木によって計測ノード３０の位置は異なることから、図５に示すように、「代表」「中継」及び「計測」の全ての役割が１計測ノード３０に割り当てられる場合がある。
【００６１】
中継の役割が割り当てられた計測ノード３０は、下流の計測ノード３０から送信された計測結果を上流の計測ノード３０に転送する、監視対象区間の障害状況を推定する、といったことを行う。代表の役割が割り当てられた計測ノード３０は、それらに加えて、物理ネットワーク上に存在する計測ノード３０のなかで論理木の構築に不要な計測ノード（冗長ノード）３０を排除するための処理を行う。これら役割毎の動作についての詳細は後述する。以降、役割が明らかとなっている計測ノード３０では、その役割に応じた符号を用いることとする。つまり役割が「代表」では「４０」、「中継」では「５０」、「計測」では「６０」を用いる。
【００６２】
図１２は、メッセージ転送部３２ｃを実現させる処理のフローチャートである。次に、図１２を参照して、その転送部３２ｃを実現させる処理について詳細に説明する。この処理は、図１０のステップＳ１３で、例えばリンク構築メッセージの受信を契機に実行される。
【００６３】
先ず、ステップＳ３１では、オーバレイネットワークを構成する他の計測ノード３０から受信されたリンク構築メッセージを取得する。次のステップＳ３２では、リンク構築メッセージに記録されているグループ識別子およびサービストラヒックの送信経路に関する情報を取得する。その次に移行するステップＳ３３では、サービストラヒックの送信経路に関する情報を参照して、送信経路における自ノード３０の位置を確認し、リンク構築メッセージを次に転送すべき計測ノード３０が存在するか否か判定する。リンク構築メッセージを次に転送すべき計測ノード３０が存在しない場合、つまり論理木上の上流に配信サーバ１０が位置している場合、判定はＮＯとなってステップＳ３４に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ３５に移行する。
【００６４】
ステップＳ３４では、取得したグループ識別子に対応する論理木における自ノード３０の役割が「代表」であるとして、グループ情報管理ＤＢ３６の内容を更新する。その後は上記ステップＳ３１に戻る。
【００６５】
ステップＳ３５では、次に転送すべき計測ノード３０にリンク構築メッセージを送信する。リンク構築メッセージの送信経路は、自ノード３０と配信サーバ１０間のネットワーク機器群を含むものに更新して送信する。続くステップＳ３６では、取得したグループ識別子に対応する論理木における自ノード３０の役割が「中継」であるとして、グループ情報管理ＤＢ３６の内容を更新する。その後は上記ステップＳ３１に戻る。
【００６６】
サービストラヒックは、上流側から下流側に送信され、リンク構築メッセージは逆に、下流側から上流側に送信される。それにより、上流側、及び下流側の少なくとも一方に隣接ノード３０が存在する自ノード３０は、その隣接ノード３０や、その隣接ノード３０を介した送信経路を把握することができる。それにより、自ノード３０の役割を適切に設定することができる。
【００６７】
図１３は、隣接エージェント決定部３２ｄを実現させる処理のフローチャートである。次に、図１３を参照して、その決定部３２ｄを実現させる処理について詳細に説明する。この処理は、図１０のステップＳ１４及びＳ１５として実行される。
【００６８】
先ず、ステップＳ４１では、自ノード３０がリンク構築メッセージを生成したか否か判定する。そのリンク構築メッセージを生成していない場合、判定はＮＯとなってステップＳ４２に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ４４に移行する。
【００６９】
ステップＳ４２では、他の計測ノード３０から受信したリンク構築メッセージに記録されているグループ識別子を取得する。次のステップＳ４３では、取得したグループ識別子（論理木）における下流の隣接ノード３０として、リンク構築メッセージの送信元である計測ノード３０の識別子をグループ情報管理ＤＢ３６に記録する。その後はステップＳ４４に移行する。
【００７０】
ステップＳ４４では、次にリンク構築メッセージを転送する計測ノード３０が存在するか否か判定する。その計測ノード３０が存在する場合、判定はＹＥＳとなってステップＳ４５に移行する。そうでない場合には、判定はＮＯとなってステップＳ４６に移行する。
【００７１】
ステップＳ４５では、リンク構築メッセージに記録されているグループ識別子に対応するサービストラヒックの送信経路で自ノード３０より配信サーバ１０側に位置する送信先の隣接ノード３０を論理木の上流の隣接ノード３０として、その識別子をグループ情報管理ＤＢ３６に記録する。続くステップＳ４６では、リンク構築メッセージに記録されている送信経路において、自ノード３０と自ノード３０の下流に位置する隣接ノード３０に対応するネットワーク機器間の経路を監視対象区間として、グループ情報管理ＤＢ３６に記録する。その後はステップＳ４１に戻る。
【００７２】
図１４は、冗長エージェント削除開始部３２ｅを実現させる処理のフローチャートである。次に、図１４を参照して、その開始部３２ｅを実現させる処理について詳細に説明する。この処理は、図１０のステップＳ１４及びＳ１５として実行される。
【００７３】
先ず、ステップＳ５１では、グループ情報管理ＤＢ３６を検索して、自ノード６０が「代表」の役割を持つ論理木における下流の隣接ノード３０の識別子を取得する。次のステップＳ５２では、冗長エージェント削除メッセージを作成する。続くステップＳ５３では、冗長エージェント削除メッセージに、自ノード６０が「代表」の役割を持つ論理木に対応するグループ識別子を記録する。その次に移行するステップＳ５４では、全ての下流の隣接ノード３０に対して、冗長エージェント削除メッセージを送信する。その後は上記ステップＳ５１に戻る。
【００７４】
このようにして冗長エージェント削除メッセージは、役割として「代表」が設定された計測ノード４０のみが生成して送信する。送信された冗長エージェント削除メッセージは、冗長エージェント削除部３２ｆによって処理される。その削除部３２ｆは、図１５にフローチャートを示す処理を実行することで実現される。隣接エージェント発見部３２の構成要素としては最後に、図１５を参照して、その削除部３２ｆを実現させる処理について詳細に説明する。この処理は、例えば削除メッセージの受信を契機にして、図１０のステップＳ１４及びＳ１５として実行される。
【００７５】
図１５に示すフローチャートを説明する前に、図２１を参照して、冗長ノードとして削除対象となる計測ノード３０について具体的に説明する。図２１中、代表の役割を持つ１つの計測ノード４０、中継の役割を持つ５つの計測ノード５０、及び計測の役割を持つ３つの計測ノード６０を含む論理木は、冗長ノードを削除する前のものである。
【００７６】
その論理木では、４つの計測ノード５０が冗長ノードとして削除される。削除される計測ノード５０は何れも、下流に位置する隣接ノード３０は一つのみである。そのように一
つのみ隣接ノード３０が存在する計測ノード３０は事実上、下流の隣接ノード３０から受信した情報を上流の隣接ノード３０に転送するだけである。障害箇所の推定を行う必要はない。しかし、計測ノード３０として機能させる場合、計測ノード３０は計測結果の処理を行うことから、資源を浪費させ、負荷を重くさせる。これは、他の実行すべき処理の効率的な実行を阻害する。また、各種情報の転送にかかる時間をより長くさせる。このようなことから本実施形態では、下流に位置する隣接ノード３０が一つのみの計測ノード３０を冗長ノードとして、論理木上から削除する。
【００７７】
図１５に示す処理では先ず、ステップＳ６１で隣接ノード３０から受信した冗長エージェント削除メッセージを取得する。続くステップＳ６２では、冗長エージェント削除メッセージに記録されているグループ識別子を取得する。その次に移行するステップＳ６３では、グループ情報管理ＤＢ３６を検索して、取得したグループ識別子に対応する論理木上でより下流に位置する隣接ノード３０を把握する。その後はステップＳ６４に移行する。
【００７８】
ステップＳ６４では、把握した下流の隣接ノード３０の数が０か否か判定する。取得したグループ識別子に対応する論理木で自ノード３０の役割が「計測」であった場合、下流に隣接ノード３０は存在しないことから、判定はＹＥＳとなって上記ステップＳ６１に戻る。そうでない場合には、判定はＮＯとなってステップＳ６５に移行する。
【００７９】
ステップＳ６５では、把握した下流の隣接ノード３０の数が２以上か否か判定する。把握した下流の計測ノード３０が２以上であった場合、判定はＹＥＳとなり、ステップＳ６６で下流の全計測ノード３０に冗長エージェント削除メッセージを送信した後、上記ステップＳ６１に戻る。そうでない場合には、判定はＮＯとなってステップＳ６７に移行する。
【００８０】
ステップＳ６７〜Ｓ７１では、冗長ノードの条件を満たす計測ノードを論理木上から削除するための処理が実行される。
先ずステップＳ６７では、自ノード３０の上流の隣接ノード３０に関する情報を、自ノード３０の下流の隣接ノード３０に送信する。これにより、その情報を受信した下流の隣接ノード３０は、その情報が示す隣接ノード３０を自ノード３０の上流の隣接ノード３０として、グループ情報管理ＤＢ３６を更新する。
【００８１】
次にステップＳ６８では、自ノード３０の下流の隣接ノード３０に関する情報を、自ノード３０の上流の隣接ノード３０に送信する。これにより、その情報を受信した上流の隣接ノード３０は、その情報が示す隣接ノード３０を自ノード３０の下流の隣接ノード３０として、グループ情報管理ＤＢ３６を更新する。
【００８２】
次にステップＳ６９では、自ノード３０の監視対象区間に関する情報を、自ノード３０の上流の隣接ノード３０に送信する。これにより、その情報を受信した計測ノード３０は、その情報が示す監視対象区間を自ノード３０の監視対象区間に加え、グループ情報管理ＤＢ３６を更新する。
【００８３】
次にステップＳ７０では、下流の計測ノード３０に冗長エージェント削除メッセージを送信する。その後に移行するステップＳ７１では、ステップＳ６２で取得したグループ識別子に対応する情報をグループ情報管理ＤＢ３６から削除する。その削除後は上記ステップＳ６１に戻る。
【００８４】
図１６は、図９のステップＳ５〜Ｓ７として実行される処理の詳細を示すフローチャートである。障害箇所推定部３３は、図１６に示す処理を実行することにより実現される。次に図１６を参照して、障害箇所推定部３３を実現させる処理についてより具体的に説明
する。
【００８５】
先ず、ステップＳ８１では、「計測結果の算出間隔」で指定された時間ごとに、配信サーバ１０から受信しているサービストラヒックの計測結果である受信品質（図中「計測情報」）を取得する。次のステップＳ８２では、取得した受信品質を自ノード３０の上流の隣接ノード３０、或いは監視サーバ２０に計測結果として送信する。その後はステップＳ８３に移行する。
【００８６】
役割として「計測」が設定されていない計測ノード３０では、下流の隣接ノード３０から計測結果が送信される。このことからステップＳ８３では、受信した計測結果を計測結果収納ＤＢ３４に格納すると共に、その収納ＤＢ３４に格納されている計測結果を解析して、監視対象区間内／外の障害状況を推定する。推定結果は解析結果収納ＤＢ３５に格納する。その格納後に移行するステップＳ８４では、推定した障害状況を上流の隣接ノード３０、或いは監視サーバ２０に通知する。その通知後は上記ステップＳ８１に戻る。
【００８７】
図１７〜図１９は、障害箇所推定部３３を構成する各部３３ａ〜３３ｃを実現させる各種処理のフローチャートである。次に図１７〜図１９の各フローチャートを参照して、各部３３ａ〜３３ｃを実現させる処理について詳細に説明する。
【００８８】
図１７は、計測結果通知部３３ａを実現させる処理のフローチャートである。始めに図１７を参照して、その通知部３３ａを実現させる処理について詳細に説明する。この処理は、上記ステップＳ８２で、「計測結果の通知間隔」として指定された時間ごとに実行される。
【００８９】
先ず、ステップＳ９１では、グループ情報管理ＤＢ３６を検索し、自ノード３０が「計測」の役割を持つ論理木に対応するグループ識別子を取得する。続くステップＳ９２では、グループ情報管理ＤＢ３６を検索し、ステップＳ９１で取得したグループ識別子に対応する論理木で上流に位置する隣接ノード３０に関する情報を取得する。ステップＳ９３には、その情報を取得した後に移行する。
【００９０】
ステップＳ９３では、ステップＳ９１で取得したグループ識別子に対応する配信サーバ１０から受信しているサービストラヒックの受信品質を計測結果として取得する。その次のステップＳ９４では、その計測結果を上流の隣接ノード３０に送信する。その送信を行った後は上記ステップＳ９１に戻り、「計測結果の通知間隔」として指定された時間が経過するのを待って実行する。
【００９１】
上記のようにして送信された計測結果を受信した計測ノード３０は、計測結果収納ＤＢ３４に格納する。このとき、図６に示すように、グループ識別子、及び計測結果を送信した計測ノード３０の監視対象区間を併せて格納する。
【００９２】
図１８は、計測結果解析部３３ｂを実現させる処理のフローチャートである。次に図１８を参照して、その解析部３３ｂを実現させる処理について詳細に説明する。この処理は、図１６のステップＳ８３及びＳ８４として、「計測結果の解析間隔」で指定された時間ごとに実行される。
【００９３】
先ず、ステップＳ１０１では、グループ情報管理ＤＢ３６を検索して、自ノード３０が「代表」または「中継」の役割を持つ論理木に対応するグループ識別子を取得する。次のステップＳ１０２では、計測結果収容ＤＢ３４を検索して、ステップＳ１０１で取得したグループ識別子に対応する計測結果を取得する。その取得後はステップＳ１０３に移行する。
【００９４】
ステップＳ１０３では、取得した計測結果を解析し、各グループ識別子に対応する計測結果が全てＧｏｏｄとなっているか否か判定する。計測結果が全てＧｏｏｄでなかった場合、判定はＮＯとなってステップＳ１０９に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ１０４に移行する。
【００９５】
ここで、図２２に示す説明図を参照して、監視対象区間の内／外の障害状況の推定方法について具体的に説明する。この図２２において、３０−１は自ノード、３０−２及び３０−３は共に自ノード３０−１の下流に位置する隣接ノードを指していることとする。
【００９６】
自ノード３０−１は、２つの隣接ノード３０−２及び３０−３に対応するネットワーク機器にそれぞれ転送するサービストラヒックを解析して，障害箇所を推定する．その解析により、隣接ノード３０−２及び３０−３への受信品質が共にＧｏｏｄであれば、自ノード３０−１の監視対象区間の内／外もＧｏｏｄと推定する。しかし、隣接ノード３０−３に対応するネットワーク機器への受信品質がＧｏｏｄ、隣接ノード３０−３に対応するネットワーク機器への受信品質がＢａｄといったように、ＧｏｏｄとＢａｄの受信品質が混在している場合には、障害箇所は下流にのみ存在すると推定する。これは、自ノード３０−１に対応するネットワーク機器まではサービストラヒックが適切に送信されている可能性が高いからである。
【００９７】
一方、受信品質が全てＢａｄであった場合には、障害箇所は上流にのみ存在すると推定する。これは、上流に障害が発生していれば、その障害箇所より下流では全て受信品質はＢａｄとなるからである。このことから、自ノード３０−１に対応するネットワーク機器と配信サーバとの間の何れかのリンクに障害が発生していると推定し、その推定結果をその隣接ノード３０に通知する。
【００９８】
そのような推定結果が通知された隣接ノード３０では、同様にして、監視対象区間の受信品質から、監視対象区間の内／外の障害箇所を推定する。このとき、下流の隣接ノード３０から上流に障害箇所が存在することを示す推定結果を受信していた場合、監視対象区間の受信品質が全てＢａｄであれば障害箇所は上流に存在すると推定する。そのようにして、上流に発生した障害箇所は、下流から順次、推定結果が上流の計測ノード３０に通知されることにより、特定されるか、存在する可能性のある範囲が狭められる。この結果、たとえ計測ノード３０によって障害箇所を推定できなくとも、監視サーバ２０は容易に障害箇所を特定できることとなる。その障害箇所を特定するために必要な情報量も大幅に低減される。
【００９９】
図１８の説明に戻る。
上記ステップＳ１０３の判定がＹＥＳ、つまり全ての監視対象区間の受信品質がＧｏｏｄであった場合に移行するステップＳ１０４では、全監視対象区間の品質をＧｏｏｄと推定する。続くステップＳ１０５では、監視対象区間外の品質をＧｏｏｄと推定する。その次に移行するステップＳ１０６では、監視対象区間毎に品質、即ち障害の推定結果を解析結果収納ＤＢ３５に格納する。そのように監視対象区域内／外の障害状況を推定し、その推定結果を保存してから、ステップＳ１０７に移行する。
【０１００】
ステップＳ１０７では、グループ情報管理ＤＢ３６を検索して、自ノード３０に役割として中継が設定されたグループ識別子が存在するか否か判定する。そのようなグループ識別子が存在する場合、判定はＹＥＳとなってステップＳ１０８に移行し、監視対象区間外の推定結果を受信品質として計測結果を生成し、上流の隣接ノード３０に送信した後、上記ステップＳ１０１に戻る。そうでない場合には、判定はＮＯとなって、そのステップＳ１０１に戻る。ステップＳ１０１の実行は、「計測結果の解析間隔」として指定された時
間が経過するのを待って行う。
【０１０１】
一方、上記ステップＳ１０３の判定がＮＯとなって移行するステップＳ１０９では、取得した計測結果が全てＢａｄか否か判定する。計測結果が全てＢａｄでなかった場合、つまりＢａｄとＧｏｏｄが混在していた場合、判定はＮＯとなってステップＳ１１２に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ１１０に移行する。
【０１０２】
ステップＳ１１０では、全ての監視対象区間の品質をＧｏｏｄと推定する。続くステップＳ１１１では、監視対象区間外の品質をＢａｄと推定する。そのようにして監視対象区間の内／外の障害状況を推定してから、上記ステップＳ１０６に移行する。
【０１０３】
ステップＳ１１２では、下流の隣接ノード３０（図２２では隣接ノード３０−３が相当）と結ぶ監視対象区間をＢａｄと推定する。続くステップＳ１１３では、監視対象区間外の品質をＧｏｏｄと推定する。そのようにして監視対象区間の内／外の障害状況を推定した後、上記ステップＳ１０６に移行する。
【０１０４】
ステップＳ１１２への移行は、下流の隣接ノード３０と結ぶリンクに障害が発生した場合に実現される。その場合、下流の隣接ノード３０はリンクを介して受信されるサービストラヒックを計測し、計測結果としてＢａｄを送信する。自ノード３０自体は、自身が受信するサービストラヒックを計測し、計測結果としてＧｏｏｄを得る。このことから、自ノード３０は、下流の隣接ノード３０と結ぶリンクである監視対象区間に障害が発生したと推定する。
【０１０５】
図１９は、障害箇所通知部３３ｃを実現させる処理のフローチャートである。障害箇所推定部３３の構成要素としては最後に、図１９を参照して、その通知部３３ｃを実現させる処理について詳細に説明する。この処理は、図１６のステップＳ８４内で、「解析結果の通知間隔」として指定された時間ごとに実行される。
【０１０６】
先ず、ステップＳ２０１では、解析結果収容ＤＢ３５を検索して、受信品質がＢａｄである監視対象区間、つまり推定した障害箇所（リンク）に関する情報を取得する。続くステップＳ２０２では、取得した監視対象区間に関する情報を監視サーバ２０宛に送信する。その後は上記ステップＳ２０１に戻る。そのステップＳ２０１の実行は、「解析結果の通知間隔」として指定された時間が経過するのを待って行う。
【０１０７】
各計測ノード３０が管理する解析結果収納ＤＢ３５には、自ノード３０より下流の計測ノード３０による解析結果が反映された解析結果が格納される。このため、受信品質がＢａｄの監視対象区間は、障害が発生しているか、或いは障害が発生している可能性が考えられる区間となっている。そのような監視対象区間のみを監視サーバ２０に通知することにより、監視サーバ２０はより少ない情報量で障害が発生している監視対象区間（リンク）を高精度に特定することができる。その監視サーバ２０は、受信した監視対象区間に関する情報は図２３に示す障害推定箇所ＤＢ２３に格納する。
【０１０８】
以降は図２３〜図２７を参照して、監視サーバ２０について具体的に説明する。
図２３は、監視サーバ２０の機能構成を示す図である。図２３に示す機能構成は、計測ノード３０と同様に、監視サーバ２０として動作させるための機能を搭載したプログラム（以降、便宜的に「監視プログラム」と呼ぶ）を監視サーバ２０に実行させることで実現される。その監視プログラムは、監視サーバ２０上に障害箇所特定部２２を実現させ、障害推定箇所ＤＢ２３を生成・管理する。
【０１０９】
監視サーバ２０には、計測ノード３０と同様に、図２８に示す構成のコンピュータを用
いることができる。図２８に示す構成では、例えば監視プログラムは外部記憶装置８５、若しくは記録媒体ＭＤに格納されているか、或いはネットワーク接続装置８７によりネットワーク７０を介して外部装置から受信する。障害推定箇所ＤＢ２３は、例えば外部記憶装置８５上に構築される。
【０１１０】
障害推定箇所ＤＢ２３には、上述したように、各計測ノード３０が推定した障害箇所を示す情報が障害箇所特定部２２によって格納される。そのＤＢ２３には、図２４に示すように、グループ識別子毎に推定された故障箇所を示す情報が格納される。図２４では、推定故障箇所はＩＰアドレスで示している。それにより事実上、図２９に示す表のように送信経路上で受信品質がＢａｄの箇所（リンク）を表すものとなっている。後述する図２７では、図２９と同じく、Ｂａｄの受信品質を表す値として１を用いている。
【０１１１】
障害箇所特定部２２を実現させる監視プログラムは、以下のような処理を監視サーバ２０に実行させる。以降は図２５及び図２６に示す各種フローチャートを参照して、監視プログラムにより実現される処理について詳細に説明する。
【０１１２】
図２５は、監視プログラムにより実行される処理の全体的な流れを示すフローチャートである。始めに図２５を参照して、その処理の全体的な流れについて具体的に説明する。
監視プログラムは、管理者からの起動要求に応じて起動される（ステップＳ３０１）。起動後は、例えば管理者の指示に従って「計測結果の特定間隔」といった設定パラメータの読み込みを行う（ステップＳ３０２）。その特定間隔とは、障害箇所の特定を行う時間間隔のことであり、その時間間隔として指定された時間が１０秒であれば、障害箇所の特定は１０秒間隔で行われることとなる。
【０１１３】
設定パラメータの読み込みを行った後は、計測ノード３０から障害箇所と推定された区間（リンク）の情報を随時、受信して取得し、その情報を障害推定箇所ＤＢ２３に格納する（ステップＳ３０３）。その情報への対応は、「計測結果の特定間隔」として指定された時間に従って行い、ステップＳ３０４に移行する。そのステップＳ３０４では、障害推定箇所ＤＢ２３から障害箇所と推定された区間の情報（計測結果）を読み出し、読み出した情報を解析して、障害箇所を特定する。その特定結果は、例えば監視サーバ２０に設けられた障害箇所出力Ｉ／Ｆを介して外部に公開する。この公開方法としては、解析結果を格納する目的で設けられたＤＢへの情報の書き出し、ソケット通信による外部プロセスへの情報受け渡し、Ｗｅｂ上に公開する方法などが考えられる。そのような公開を行った後に上記ステップＳ３０３に戻る。それにより、障害箇所の特定は「計測結果の特定間隔」として指定された時間毎に行う。
【０１１４】
図２６は、障害箇所特定部２２を実現させる処理のフローチャートである。最後に、図２６を参照して、その特定部２２を実現させる処理について詳細に説明する。この処理は、上記ステップＳ３０４で実行される部分を抽出して示したものである。
【０１１５】
先ず、ステップＳ４０１では、障害推定箇所ＤＢ２３から全ての情報を読み出す。続くステップＳ４０２では、読み出した情報を解析し、図２７に示すように、複数のグループ識別子に共通して含まれている区間を抽出し、抽出した区間を障害箇所と特定する。その特定後、図２６に示す一連の処理を終了する。終了後に、障害箇所の特定結果の公開が行われる。
【０１１６】
以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知システムにおいて、
前記ネットワーク障害システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを備え、
前記ノードは、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害リンク推定手段と、を具備し、
前記監視サーバは、
前記ノードから受信した前記障害箇所の推定結果を解析して、前記送信経路上の障害箇所を特定する障害リンク特定手段、を具備する、
ことを特徴とするネットワーク障害検知システム。
（付記２）
付記１記載のネットワーク障害検知システムを構成するノードとして用いられるデータ処理装置であって、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定手段と、
を具備することを特徴とするデータ処理装置。
（付記３）
前記隣接ノード特定手段は、前記ツリー構造上で認識した自身の位置を基に、該ツリー構造上、冗長なノードか否か判定し、該冗長なノードと判定した場合に、該ツリー構造上から離脱するための処理を行う、
ことを特徴とする付記２記載のデータ処理装置。
（付記４）
前記隣接ノード特定手段は、前記ツリー構造上で下流に位置する隣接ノードとの間のリンクを前記監視対象リンクとして設定する、
ことを特徴とする付記２記載のデータ処理装置。
（付記５）
前記障害箇所推定手段は、前記監視対象リンクに加えて、前記ツリー構造上で上流に位置する隣接ノードとの間のリンクを対象に前記推定を行い、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する、
ことを特徴とする付記４記載のデータ処理装置。
（付記６）
前記障害箇所推定手段は、前記障害箇所の推定結果を送信する隣接ノードとして、前記ツリー構造上で上流に位置する隣接ノードを対象にする、
ことを特徴とする付記２、または５記載のデータ処理装置。
（付記７）
前記障害箇所推定手段は、前記ツリー構造上で下流に位置する隣接ノードから前記障害
箇所の推定結果を受信した場合に、該推定結果を該障害箇所の推定に用いる、
ことを特徴とする付記６記載のデータ処理装置。
（付記８）
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知方法において、
前記障害を検知するためのネットワーク障害検知システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを用いて構築し、
前記ネットワーク障害検知システムを構成するノードに、前記サービストラヒックの送信経路に対応した論理的なツリー構造の自律的な構築、及び該送信経路の中で前記障害の発生を監視すべき監視対象区間の設定を行わせて、該設定した監視対象区間で発生する障害を監視させ、
前記監視サーバによる前記送信経路上の障害の特定は、各ノードによる障害の監視結果を用いて行わせる、
ことを特徴とするネットワーク障害検知方法。
（付記９）
付記１記載のネットワーク障害検知システムを構成するノードとして用いられるコンピュータに、
前記サービストラヒックを計測する計測機能と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定機能と、
前記計測機能による計測結果を用いて、前記隣接ノード特定機能が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定機能と、
を実現させるためのプログラム。
【図面の簡単な説明】
【０１１７】
【図１】本実施形態によるネットワーク障害検知システムの構成を説明する図である。
【図２】計測エージェントを実行するノードの機能構成を示す図である。
【図３】隣接エージェント発見部の機能構成を示す図である。
【図４】障害箇所推定部の機能構成を示す図である。
【図５】グループ情報管理ＤＢのデータ構成を示す図である。
【図６】計測結果収納ＤＢのデータ構成を示す図である。
【図７】解析結果収納ＤＢのデータ構成を示す図である。
【図８】計測エージェントを実行するノードが障害を監視する監視対象区間の説明図である。
【図９】計測エージェントにより実行される処理の全体的な流れを示すフローチャートである。
【図１０】図９のステップＳ３及びＳ４として実行される処理の詳細を示すフローチャートである。
【図１１】メッセージ送出部を実現させる処理のフローチャートである。
【図１２】メッセージ転送部を実現させる処理のフローチャートである。
【図１３】隣接エージェント決定部を実現させる処理のフローチャートである。
【図１４】冗長エージェント削除開始部を実現させる処理のフローチャートである。
【図１５】冗長エージェント判断部を実現させる処理のフローチャートである。
【図１６】図９のステップＳ５〜Ｓ７として実行される処理の詳細を示すフローチャートである。
【図１７】計測情報通知部を実現させる処理のフローチャートである。
【図１８】計測結果解析部を実現させる処理のフローチャートである。
【図１９】障害箇所通知部を実現させる処理のフローチャートである。
【図２０】リンク構築メッセージに格納されるデータを示す図である。
【図２１】論理木上から削除対象となるノードの説明図である。
【図２２】ノードでの障害箇所の推定方法を示す図である。
【図２３】監視サーバの機能構成を示す図である。
【図２４】障害推定箇所ＤＢのデータ構成を示す図である。
【図２５】監視サーバの監視プログラムにより実行される処理の全体的な流れを示すフローチャートである。
【図２６】障害箇所特定部を実現させる処理のフローチャートである。
【図２７】監視サーバによる障害箇所の特定方法を示す説明図である。
【図２８】計測ノードとして用いることが可能なコンピュータのハードウェア構成の一例を示す図である。
【図２９】従来のネットワーク障害検知システムで行われている障害箇所の特定方法を示す説明図である。
【符号の説明】
【０１１８】
１０ 配信サーバ
２０ 監視サーバ
２２ 障害箇所特定部
２３ 障害推定箇所ＤＢ
３０ ノード
３１ 計測部
３２ 隣接エージェント発見部
３２ａ オーバレイネットワーク機能部
３２ｂ メッセージ送出部
３２ｃ メッセージ転送部
３２ｄ 隣接エージェント決定部
３２ｅ 冗長エージェント削除開始部
３２ｆ 冗長エージェント判断部
３３ 障害箇所推定部
３３ａ 計測情報通知部
３３ｂ 計測結果解析部
３３ｃ 障害箇所通知部
３４ 計測結果収納ＤＢ
３５ 解析結果収納ＤＢ
３６ グループ情報管理ＤＢ
７０ ネットワーク
【技術分野】
【０００１】
本発明は、配信サーバからサービストラヒックが送信されるネットワーク上の経路に発生する障害を検知（特定）するための技術に関する。
【背景技術】
【０００２】
現在、インターネットに代表されるネットワークは、各種サービスを提供するために幅広く用いられている。そのサービスのなかには、映像配信やオンラインゲームのように、サービストラヒックを比較的に長い時間、継続して送信するサービスがある。
【０００３】
そのようなサービスでは、サービストラヒックの転送経路上にスイッチの故障やルータでの輻輳等による障害が発生すると、サービストラヒックの受信品質が大きく低下する。例えばパケットロス率が大きくなると、サービストラヒックの送信に必要な時間がより長くなる、といった不具合が発生する。このことから、経路（ネットワーク）上に発生した障害には迅速に対応することが重要となっている。
【０００４】
これまでは、ネットワーク上で障害が発生した障害箇所は、ネットワーク管理者がノウハウを基に特定していた。しかし、管理者による障害箇所の特定には、非常に長い時間を要するのが普通である。このことから近年では、ネットワーク上の障害箇所を自動的に特定する技術が検討されている。
【０００５】
図２９は、従来のネットワーク障害検知システムにおける障害箇所推定方法の説明図である。このシステムは、アプリケーションサーバから送信されるサービストラヒックの経路上に発生した障害を自動的に検知するためのものである。
【０００６】
図２９に示すネットワーク障害検知システムは、ソフトウェアである計測エージェントを実行する多数のノード、及び監視サーバ２８０を備えた構成である。計測エージェントを実行するノードについては、そのエージェントを実行しないノードと区別するために、以降「計測ノード」と呼ぶことにする。
【０００７】
図２９では、計測ノードとして２７１或いは２７２を付した２つを示している。それら計測ノード２７１及び２７２のうちの何れであっても良い場合には、符号として２７０を用いることにする。これは２６１或いは２６２を付した２つのアプリケーションサーバ、及び２９１或いは２９２を付した計測ノード２７０以外のノードでも同様である。例えばアプリケーションサーバでは、アプリケーションサーバ２６１及び２６２のうちの何れであっても良い場合には符号として「２６０」を用いる。
【０００８】
計測エージェントは、アプリケーションサーバ２６０から送信されたサービストラヒックの受信品質およびサービストラヒックの送信経路を計測し、計測した受信品質とサービストラヒックの送信経路とを含む計測結果を監視サーバ２８０に送信する機能を備えている。監視サーバ２８０は、各計測ノード２７０から受信した計測結果を解析し、障害の発生の有無を判定する。障害が発生していると判定した場合に、障害箇所を推定する。このようなことから、障害箇所の推定は、計測ノード２７０による計測（ＳＴ１）、計測結果の監視サーバ２８０への報告（ＳＴ２）、監視サーバ２８０による解析（ＳＴ３）、のシーケンスで行われる。
【０００９】
障害箇所の推定は、以下のようにして行われる。ここでは、アプリケーションサーバ２６１が送信するサービストラヒックは計測ノード２７２によって計測され、アプリケーションサーバ２６２が送信するサービストラヒックは計測ノード２７１によって計測されることを想定する。つまり、アプリケーションサーバ２６１が送信するサービストラヒックは、アプリケーションサーバ２６１とノード２９１間のリンクＬ４、ノード２９１とノード２９２間のリンクＬ２、及びノード２９２と計測ノード２７２間のリンクＬ５を含む送信経路であるパス１を介して計測ノード２７２に転送され、アプリケーションサーバ２６２が送信するサービストラヒックは、アプリケーションサーバ２６２とノード２９２間のリンクＬ３、リンクＬ２、及びノード２９１と計測ノード２７１間のリンクＬ１を含む送信経路であるパス２を介して計測ノード２７１に転送されることを想定する。
【００１０】
計測ノード２７２が監視サーバ２８０に送信する計測結果には、受信品質の他に、サービストラヒックの送信経路が含まれる。図２９中に示す表では、送信経路に含まれるリンクは「１」を表記することで示している。表中の「劣化」は、計測した受信品質が悪い、つまり送信系路上の何れかのリンクに障害が発生していることを表している。
【００１１】
受信品質は、サービストラヒックが輻輳することで低下する。このことから監視サーバ２８０は、受信品質が「劣化」の送信経路間で共通するリンクを抽出し、そのリンクを障害箇所と推定する。それにより、図２９に示す例では、パス１及び２で共通するリンクＬ２が障害箇所と推定される。
【特許文献１】特開２００６−２３８０５２号公報
【非特許文献１】N.G. Duffield, and et. al., Simple Network Performance Tomography,” In Proc. of ACM SIGCOMM Internet Measurement Conference 2003.
【非特許文献２】Q. Lv, et. al., “Search and Replication in Unstructured Peer-to-Peer Networks,” Proc. of ICS’02, pp. 84-95, 2002.
【非特許文献３】E. Keong, et. al., “A Survey and Comparisonof Peer-to-Peer Overlay Network Schemes,” Journal of IEEE Communication Surveys, Vol. 7, No. 2, pp. 72-93, 2005.
【非特許文献４】I. Stoica, et. al., ``Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications,” Journal of IEEE/ACM Transactions on Networking, Vol. 11, No. 1, 2003.
【発明の開示】
【発明が解決しようとする課題】
【００１２】
上述したような従来のネットワーク障害検知システムでは、各計測ノード２７０が送信する計測結果を監視サーバ２８０が解析して、障害箇所を特定する。このようなことから、監視サーバ２８０が解析の対象とする情報量が膨大となり易いという問題点があった。その問題点は、必要なハードウェア資源が大きくなる、負荷が重くなって障害箇所の特定にかかる時間が長くなる、といった形で表面化する。
【００１３】
膨大な情報量を管理する必要性を回避して、高速に障害箇所を特定するために、複数の監視サーバを設置して分散処理させる手法も提案されている。しかし、そのような分散処理を採用した場合、各監視サーバは全情報のうちの一部を対象に解析を行うことになる。このため、ネットワーク全体を俯瞰する形での解析を行うことができず、障害箇所の特定精度が低下することが知られている。監視サーバは、ネットワークの規模に応じた数分、設置する必要がある。このため、大規模なネットワークでは、多数の監視サーバを設置しなければならず、設備投資にかかるコストは膨大となる。このようなことから、複数の監視サーバを用いた分散処理は実用上、望ましいものではない。
【００１４】
本発明は、送信経路上の障害箇所の特定（検知）精度を維持しつつ、監視サーバが解析の対象とする情報量をより抑えるための技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明を適用した１システムでは、ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するために、送信経路上に存在し、配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを備えている。各ノードは、サービストラヒックを計測する計測手段と、送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、計測手段による計測結果を用いて、隣接ノード特定手段が設定した監視対象リンクのなかで障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を隣接ノード及び監視サーバのうちの一方に送信する障害リンク推定手段と、を具備する。監視サーバは、ノードから受信した障害箇所の推定結果を解析して、送信経路上の障害箇所を特定する障害リンク特定手段、を具備する。
【００１６】
上記システムを構成するノードは、サービストラヒックの送信経路に対応した論理的なツリー構造を自律的に構築し、該送信経路の中で障害の発生を監視すべき監視対象リンクを自動的に設定し、設定した監視対象リンクを監視して、そのなかで障害が発生している可能性のある監視対象リンクを障害箇所として推定する。そのような障害箇所の推定により、送信経路全体のなかで発生した障害を特定するために考慮すべき範囲（リンク）は非常に狭められる。しかし、障害箇所の特定は、配信サーバから送信されているサービストラヒックの送信経路全体の情報を用いて行う形となる。そのため，既存の集中型のシステムには及ばないが，ネットワークの広範囲を俯瞰する形での解析を行うことができる。これらの結果、障害箇所の特定精度は高く維持させつつ、監視サーバが解析の対象とする情報量はより抑えられることとなる。それにより、監視サーバに必要なハードウェア資源は抑えられ、その負荷は軽減される。
【発明の効果】
【００１７】
本発明を適用した場合には、送信経路上の障害箇所の特定（検知）精度を維持しつつ、監視サーバが解析の対象とする情報量をより抑えることができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態によるネットワーク障害検知システムの概要を示す図である。
図１中の物理ネットワークは、サービストラヒックを送信する配信サーバ１０毎に存在する、ネットワーク全体でそのサービストラヒックの送信に用いられる部分、つまり送信経路の集合体に相当する。本実施形態では、物理ネットワークを構成するノード３０に、その物理ネットワークに対応する論理木（論理的なツリー構造）を自律的に構築させ、各ノード３０に障害の推定に係わる処理を実行させる。監視サーバ２０には、各ノード３０で確定できていない（推定はできているが、特定はできていない）障害を特定させる。そのようにして、発生した障害の特定に要する処理を各ノード３０に分散させて実行させることにより、障害箇所の特定精度を維持させつつ、監視サーバ２０による解析の対象となる情報量を低減させる。
【００１９】
論理木を自律的に構築させるノード３０は、分散処理用のソフトウェアである計測エージェントを実行可能なデータ処理装置（コンピュータ）として用いることが可能なものである。本実施形態では、論理木の構築にオーバレイネットワーク技術を利用している。オーバレイネットワーク技術とは、以下のようなものである。
【００２０】
オーバレイネットワーク技術は、インターネットに代表されるネットワークを構成する
ノード群（ルータ、コンピュータ、ゲートウェイ、など）の中で、ある定められた目的に用いるノードのみが存在する論理的なネットワークを構築する技術である。論理ネットワーク内では、その目的が達成しやすいようにノード間に論理的なリンクが確立されており、その論理的なリンクに沿ってノード間で情報の交換が行われる。ピアツーピア（Ｐ２Ｐ）ネットワークは、各ノードが所持する情報の流通・共有・発見に特化したオーバレイネットワークである。そのＰ２Ｐネットワークでは、全てのノードが目的の情報を短時間で発見できるように、自身のノード（自ノード）に論理ネットワーク上で隣接する隣接ノードおよびデータの転送規則が設定されている。本実施形態では、このＰ２Ｐネットワーク技術を応用したオーバレイネットワーク技術を利用している。
【００２１】
Ｐ２Ｐネットワークは、確実に目的の情報は発見できないが、実装が容易でありキーワード検索のような曖昧検索を得意とする非構造型Ｐ２Ｐネットワーク（非特許文献２）と、実装は複雑であるが目的の情報を確実に発見できる構造型Ｐ２Ｐネットワーク（非特許文献３）とに大別できる。本実施形態では構造型Ｐ２Ｐネットワークを採用している。しかし、以下の特徴を持つオーバレイネットワークならば採用は可能である。
・Ｐ２Ｐネットワーク全体で管理するＩＤの空間が与えられており、各ノードは、その中で決められた範囲のＩＤを管理している。ここで、あるＩＤを管理するノードは１台のみとなっている
・各ノードは、管理対象のＩＤに対応する情報または情報のインデックスを管理している
・論理ネットワーク上でのデータ転送規則に従ってノード間でメッセージが交換されることにより、指定されたＩＤを管理するノードまで短時間でメッセージを送信することができる
構造型Ｐ２Ｐネットワーク（以降、特に断らない限り「Ｐ２Ｐネットワーク」は構造型Ｐ２Ｐネットワークを指す意味で用いる）に参加している各ノードは、基本的に以下の情報を管理している。
・Ｐ２Ｐネットワーク上で、一意に自身を識別するためのＩＤ(ノードＩＤ)
（一般的に、ＩＰアドレスやポート番号などのノードの識別子をハッシュ関数（ＳＨＡ−１など）に入力することにより算出する）
・Ｐ２Ｐネットワークに参加している複数の他のノードへの経路表（ノードＩＤと識別子の対応表）
（一般的に、log(N)個のノードへの情報を管理 （Ｎ：Ｐ２Ｐネットワークを構成する全ノード数）
Ｐ２Ｐネットワークでは、例えば利用者からあるＩＤに対応する情報の取得要求があった場合、取得要求を受けたノードはそのＩＤを格納した検索メッセージを生成し、経路表の中で、そのＩＤ側で自ノードに最も近いＩＤを持つノードへ検索メッセージを送信する。そのメッセージを受信したノードは、同様に自ノードに最も近いＩＤを持つノードに検索メッセージを転送する。そのようにして転送を繰り返し行うことにより、指定されたＩＤを管理しているノード（以下、対応ノード）に検索メッセージが届けられる。この結果、対応ノードがＩＤに対応する情報を持っている場合には、その情報が要求元のノードへ送信される。このとき、対応ノードへ検索メッセージが届くまでに、検索メッセージは高々log(N)個のノードしか経由しない。
【００２２】
本実施形態では、上述のようなオーバレイネットワーク技術を用いて物理ネットワーク（送信経路）に対応する論理木を自律的に構築する。各ノード３０は、論理木の構築により、送信経路のなかで自ノードが障害の発生を監視すべき監視対象範囲（論理木のなかで隣接するノード間のリンク）を認識し、その監視対象範囲の障害状況を推定、つまり障害が発生しているか否か推定する。その障害状況の推定は、他のノード３０から受信する計測結果を参照して行う。その計測結果とは、計測した受信品質、及びその送信経路を含むメッセージである。
【００２３】
論理木を自律的に構築するノード３０は、本実施形態によるネットワーク障害検知システムの実現用のソフトウェアである計測エージェントを実行するノードである。他のノードと区別するために、計測エージェントを実行するノードは以降「計測ノード」と呼ぶ。計測ノード３０は計測エージェントによって制御されることから、特に断らない限り、計測エージェントは計測ノード３０と同じ意味で用いる。
【００２４】
図２は、計測エージェントによって計測ノード３０上に実現される機能構成を示す図である。図２に示すように、計測エージェントは、配信サーバ１０から送信されたサービストラヒックを計測する計測部３１、論理木を自律的に構築し、その論理木上で隣接する隣接ノードを発見する隣接エージェント発見部３２、及び隣接ノードによって決定される監視対象範囲の障害状況を監視する障害箇所推定部３３をノード３０上に実現させ、計測結果収納データベース（ＤＢ）３４、解析結果収納ＤＢ３５及びグループ情報管理ＤＢ３５を生成・管理する。その計測エージェントは、計測ノード３０が備えた、或いはアクセス可能な記憶装置に格納される。必要に応じて、ネットワーク７０を介して送信するようにしても良い。
【００２５】
図２８は、上記計測ノード３０として用いることが可能なコンピュータのハードウェア構成の一例を示す図である。図２に示す各部３１〜３３の詳細な説明の前に、算計測ノード３０として用いることが可能なコンピュータの構成について具体的に説明する。
【００２６】
図２８に示すコンピュータは、ＣＰＵ８１、メモリ８２、入力装置８３、出力装置８４、外部記憶装置８５、媒体駆動装置８６、及びネットワーク接続装置８７を有し、これらがバス８８によって互いに接続された構成となっている。同図に示す構成は一例であり、これに限定されるものではない。
【００２７】
ＣＰＵ８１は、当該コンピュータ全体の制御を行う。メモリ８２は、プログラム実行、データ更新等の際に、外部記憶装置８５（あるいは可搬型の記録媒体ＭＤ）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ８１は、プログラムをメモリ８２に読み出して実行することにより、全体の制御を行う。
【００２８】
入力装置８３は、例えば、キーボード、マウス等の操作対象装置と接続されたインターフェース、或いはそれらを全て有するものである。操作対象装置に対するユーザの操作を検出し、その検出結果をＣＰＵ８１に通知する。
【００２９】
出力装置８４は、例えば表示装置と接続された表示制御装置、或いはそれらを有するものである。ＣＰＵ８１の制御によって送られてくるデータを表示装置上に出力させる。
ネットワーク接続装置８７は、ネットワーク７０を介して、外部装置である他の計測ノード３０、配信サーバ１０、或いは監視サーバ２０と通信を行うためのものである。外部記憶装置８５は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。
【００３０】
記憶媒体駆動装置８６は、光ディスクや光磁気ディスク等の可搬型の記録媒体ＭＤにアクセスするものである。
図２８に示す構成では、上記計測エージェントは、外部記憶装置８５、若しくは記録媒体ＭＤに格納されているか、或いはネットワーク接続装置８７によりネットワーク７０を介して外部装置から受信される。図２に示すＤＢ３４〜３６は、例えば外部記憶装置８５上に構築される。外部記憶装置８５、若しくは記録媒体ＭＤから読み出された、或いはネットワーク接続装置８７が受信した計測エージェントはメモリ８２に格納され、ＣＰＵ８１により実行される。その計測エージェントを実行することにより、図２８に示す構成のコンピュータは計測モード３０として機能する。
【００３１】
図３は、隣接エージェント発見部３２の機能構成を示す図である。図３に示すように、隣接エージェント発見部３２は、オーバレイネットワーク機能部３２ａ、メッセージ送出部３２ｂ、メッセージ転送部３２ｃ、隣接エージェント決定部３２ｄ、冗長エージェント削除開始部３２ｅ、及び冗長エージェント判断部３２ｆを備えた機能構成となっている。図３中では、配信サーバ１０は「アプリケーションサーバ」と表記している。これは図４でも同様である。
【００３２】
図４は、障害箇所推定部３３の機能構成を示す図である。図４に示すように、障害箇所推定部３３は、計測情報通知部３３ａ、計測結果解析部３３ｂ及び障害箇所通知部３３ｃを備えた機能構成となっている。
【００３３】
隣接エージェント発見部３２、及び障害箇所推定部３３を実現させる計測エージェントは、以下のような処理を計測ノード３０に実行させる。以降は図９〜図１９に示す各種フローチャートを参照して、隣接エージェント発見部３２、及び障害箇所推定部３３の動作について詳細に説明する。
【００３４】
図９は、計測エージェントにより実行される処理の全体的な流れを示すフローチャートである。始めに図９を参照して、その処理の全体的な流れについて具体的に説明する。
計測ノード３０は、ネットワーク７０を構成するルータ等のエンティティか、或いは配信サーバ１０によるサービスを利用する利用者が使用するコンピュータ（パーソナル・コンピュータ（ＰＣ）、ＰＤＡ、或いは家電商品（例えばセットトップボックス）など）である。この計測ノード３０は、論理木上では最下層に位置し、ネットワーク７０上では、配信サーバ１０から送信されるサービストラヒックの最終的な転送先となる。図９に示すフローチャートは、利用者が使用するコンピュータが計測ノード３０であった場合のものである。
【００３５】
計測エージェントは、利用者が使用するコンピュータで配信サーバ１０によるサービスを利用するためのアプリケーション（以降「サービス受信用アプリケーション」と呼ぶ。そのアプリケーションとしては、映像受信（再生）用のもの、電話用のもの、などを挙げることができる）の起動と連動して起動される（ステップＳ１）。この計測エージェントは利用者のコンピュータ上でメモリに常駐させても良い。ホームゲートウェイのようなハードウェア、或いはルータ等が計測ノード３０であった場合には、電源の投入と連動して起動させれば良い。
【００３６】
起動後の計測エージェントは、例えば利用者の指示に従って「計測結果の算出間隔」、「計測結果の解析間隔」、「解析結果の通知間隔」、「受信品質の閾値」、「監視サーバ２０の識別子」といった各種設定パラメータの読み込みを行う（ステップＳ２）。それら設定パラメータとは、例えば「計測結果の算出間隔」や「計測結果の解析間隔」或いは「解析結果の通知間隔」のような時間に係わるパラメータでは１０（秒）といった時間情報である。「受信品質の閾値」では、パケットロス率１％といったように、受信品質を評価する指標と、その指標での閾値とを組みにする情報である。それにより、その情報がパケットロス率１％を示していた場合、実際に計測したパケットロス率が１％を越えれば受信品質は「Ｂａｄ」、そうでなければ受信品質は「Ｇｏｏｄ」と判定される。その指標は、パケット到着間隔のゆらぎなど、受信品質を表すものであれば幅広く適用可能である。
【００３７】
「監視サーバの識別子」とは、例えばそのＩＰアドレスである。その識別子は、ＵＲＬなど監視サーバ２０が一意に識別できる値ならば何でも利用できる。また、監視サーバ２０から通知させても良いし、他の計測ノード３０から通知させても良い。
【００３８】
上記のような各種設定パラメータは、ファイルなどに用意して読み込ませても良い。ルータ等の計測ノード３０では、各種設定ファイルを格納したファイルに用意して、起動後に読み込ませれば良い。
【００３９】
設定パラメータを読み込んだ後は、オーバレイネットワークへ参加し、論理的なリンクを確立するために隣接ノード３０を発見する手続きを行う（ステップＳ３）。オーバレイネットワークへの参加では、例えばChord（非特許文献４）というオーバレイネットワークを想定した場合には、先ずネットワーク７０上で一意に自身を識別できるＩＤを算出した上で、既にオーバレイネットワークに参加している他の計測ノード３０との間で仮想的なリンクを確立する。次に、計測ノード３０はリンクを確立した計測ノード３０との間で検索メッセージを交換することにより、全体として配信（アプリケーション）サーバ１０から計測ノード３０へサービストラヒックが送信される経路に対応する論理木が構築できるように、隣接する計測ノード３０の識別子を把握する。論理木を自律的に構築する上では、以下の特徴を持つオーバレイネットワークであることが望ましい。
・各計測ノード３０は、ある決められた範囲のＩＤを管理している(つまり、あるＩＤを管理している計測ノード３０の数は1個のみ)
・複数の計測ノード３０を経由することにより、どのＩＤを管理する計測ノード３０にも必ずメッセージを届けることが可能
隣接ノード３０を発見する手続きを行った後は、サービストラヒックの送信経路と論理木の構成を比較することにより、監視対象区間を把握する（ステップＳ４）。図３に機能構成を示す隣接エージェント発見部３２は、ステップＳ３及びＳ４の実行により実現される。図４に機能構成を示す障害箇所推定部３３は、後述するステップＳ５〜Ｓ７の実行により実現される。
【００４０】
ステップＳ５では、各種設定パラメータに従い、監視対象区間の障害状況の把握を行う。例えば「計測結果の算出間隔」が１０秒であれば、１０秒が経過するたびに、サービストラヒックの受信結果を「受信品質の閾値」と比較し、受信品質を判定する。「受信品質の閾値」がパケットロス率１％であり、実際のパケットロス率が１．５％であれば、受信品質はＢａｄと判定する。そのように判定される受信品質は、計測結果として計測結果収納ＤＢ３４に格納される。また、「計測結果の解析間隔」が１０秒であれば、１０秒が経過するたびに、計測結果収容ＤＢ３４から計測結果を読み出し、監視対象区間内／外の障害状況を推定する。監視対象区間外の計測結果は、論理木の上流に位置する隣接ノード３０に送信され、監視対象区間内の計測結果は解析結果収容ＤＢ３５に格納される。
【００４１】
ここで、図６及び図７を参照して、計測結果収納ＤＢ３４及び解析結果収納ＤＢ３５のデータ構成について具体的に説明する。図６は、計測結果収納ＤＢ３４のデータ構成を示す図であり、図７は、解析結果収納ＤＢ３５のデータ構成を示す図である。
【００４２】
計測結果収納ＤＢ３４には、図６に示すように、グループ識別子（ＩＤ）、受信品質、及び区間の各データが１レコードに格納される。解析結果収納ＤＢ３５には、図７に示すように、グループ識別子（ＩＤ）毎に、監視対象区間、及び受信品質が１レコードに格納される。
【００４３】
論理木は、配信サーバ１０毎、或いは配信サーバ１０が提供するサービス毎に構築される。これは、配信サーバ１０毎、或いは配信サーバ１０が提供するサービス毎に利用者、つまり送信経路が異なるからである。グループ識別子は、そのように配信サーバ１０毎、或いは配信サーバ１０が提供するサービス毎に構築される論理木を一意に表す情報である。以降は便宜的に、論理木は配信サーバ１０毎に構築されるとの想定で説明を行う。その想定では、グループ識別子は例えば配信サーバ１０のＩＰアドレスから算出されるハッシュ値である。
【００４４】
図９の説明に戻る。
ステップＳ６では、「解析結果の通知間隔」で指定された時間が経過するたびに、解析結果収容ＤＢ３５の情報を読み出し、監視対象区間内に障害が発生しているか否か判定（推定）して、障害が発生していると判定した場合に、その障害が発生していると判定した監視対象区間に関する情報を監視サーバ２０に通知する。ステップＳ７では、「解析結果の通知間隔」で指定された時間が経過するたびに、計測結果収容ＤＢ３４の情報（計測結果）を読み出し、隣接ノード３０に送信する。監視サーバ２０への通知を必要に応じて行い、隣接ノード３０への送信を行った後はステップＳ５に戻る。それにより、障害の発生に対応可能な状態を維持する。
【００４５】
図１０は、ステップＳ３及びＳ４として実行される処理の詳細を示すフローチャートである。隣接エージェント発見部３２は、図１０に示す処理を実行することにより実現される。次に図１０を参照して、隣接エージェント発見部３２を実現させる処理についてより具体的に説明する。
【００４６】
先ず、ステップＳ１１では、配信サーバ１０から受信しているサービストラヒックを監視し、そのサーバ１０の識別子を用いてグループ識別子を算出する。このグループ識別子は、配信サーバ１０のＩＰアドレス（及びポート番号）を用いて算出されるハッシュ値など、配信サーバ１０を一意に識別できる値である。
【００４７】
続くステップＳ１２では、サービストラヒックの送信経路に対応する論理木における自身の隣接エージェントを発見するために、ステップＳ１１で導出したグループ識別子、およびアプリケーションサーバから自ノード３０までのサービストラヒックの送信経路に関する情報を格納した図２０に示すようなリンク構築メッセージを生成する。
【００４８】
ステップＳ１３では、生成したリンク構築メッセージを、自ノード３０が参加しているオーバレイネットワークを介して複数の計測ノード３０の間で交換する。続くステップＳ１４では、メッセージの交換により、サービストラヒックの送信経路に対応する論理木において自ノード３０と隣接関係にある計測ノード３０を把握し、その隣接ノード３０との間で論理的なリンクを確立する。その確立により、論理木における自ノード３０および隣接ノード３０の位置が特定、つまり論理木が構築される。その後はステップＳ１５に移行する。
【００４９】
ステップＳ１５では、構築した論理木における自ノード３０の位置および隣接ノード３０の位置から、サービストラヒックの送信経路における監視対象区間を把握する。その後はステップＳ１１に戻る。それにより、新たな論理木の構築に備える。
【００５０】
図１１〜図１５は、隣接エージェント発見部３２を構成する各部３２ｂ〜３２ｆを実現させる各種処理のフローチャートである。次に図１１〜図１５の各フローチャートを参照して、各部３２ｂ〜３２ｆを実現させる処理について詳細に説明する。
【００５１】
図３に示すオーバレイネットワーク機能部３２ａは、論理木（オーバレイネットワーク）の構築や、オーバレイネットワークを構成する他の計測ノード３０との間の通信を実現させるものである。他の構成要素と連動する形で動作する。このことから、フローチャートを用いて説明する対象から除外している。
【００５２】
図１１は、メッセージ送出部３２ｂを実現させる処理のフローチャートである。始めに図１１を参照して、その送出部３２ｂを実現させる処理について詳細に説明する。この処理は、上記ステップＳ１２及びＳ１３として実行される。
【００５３】
先ず、ステップＳ２１では、自ノード３０が受信しているサービストラヒックを監視し、そのサービストラヒックを送信する配信（アプリケーション）サーバ１０の識別子を取得する。次のステップＳ２２では、取得した配信サーバ１０の識別子を用いて、その配信サーバ１０のグループ識別子を算出する。その後はステップＳ２３に移行する。
【００５４】
ステップＳ２３では、配信サーバ１０と自ノード３０の間でのサービストラヒックの送信経路(サービストラヒックが中継するルータ等の識別子)を取得する。この取得方法としては、計測ノード３０から計測用パケットを送信することにより中継ルータの識別子を調査するTracerouteが代表的であるが、中継ルータの識別子を取得できる方法であればどのようなものでも良い。
【００５５】
ステップＳ２３に続くステップＳ２４では、リンク構築メッセージを作成する。次のステップＳ２５では、作成したリンク構築メッセージ内に、取得したグループ識別子、および取得したサービストラヒックの送信経路を記録する。その記憶により、リンク構築メッセージが完成する（図２０）。
【００５６】
ステップＳ２５の実行後に移行するステップＳ２６では、取得したサービストラヒックの送信経路で自ノード３０と隣接関係（上流側）にある計測ノード３０宛に、自ノード３０が参加しているオーバレイネットワークのメッセージ転送に従い、リンク構築メッセージを送信する。次のステップＳ２７では、ステップＳ２２で取得したグループ識別子に対応する論理木における自ノードの役割を「計測」として、グループ情報管理ＤＢ３６に記録する。その後はステップＳ２１に戻る。
【００５７】
計測部３１はサービストラヒックを監視して受信品質を示す指標を計測する。このことから、計測部３１を実現させる処理は、図９に示す処理とは別に実行される。しかし、その処理は、周知の計測技術を用いて実行されることから、詳細な説明は省略する。その処理により得られた計測結果は、「計測結果の算出間隔」で指定された時間毎に障害箇所推定部３３により参照される。
【００５８】
図５は、グループ情報管理ＤＢ３６のデータ構成を示す図である。図５に示すように、この管理ＤＢ３６は、論理木（グループ識別子）毎に、自ノード３０の役割、サービストラヒックの送信経路上で隣接する計測ノード３０、及び監視対象区間を含むグループ情報を管理するためのＤＢである。隣接ノード３０としては、送信経路上で上流（配信サーバ１０側）に位置するもの、その送信経路上で下流に位置するものを登録するようになっている。監視対象区間は、自ノード３０と下流側の隣接ノード３０の間に確立されたリンクである。この監視対象区間は、図８に示すように、自ノード３０とその隣接ノード３０の間に存在するノードのＩＰアドレスの順序で示している。
【００５９】
役割としての「計測」とは、構築された論理木で最下層に位置する計測ノード３０に要求される役割のことである。論理木の最下層に位置する計測ノード３０は、サービストラヒックの送信先である。従い、計測した受信品質は、送信経路に障害が発生しているか否かを直接、示すものとなる。障害箇所を推定することや、他の計測ノード３０から送信された計測結果を転送する必要はない。このことから、論理木の最下層に位置する計測ノード３０には、計測のみを行えば良いとする「計測」を役割として割り当てるようにしている。監視対象区間は登録しない。図１では、「計測」が役割として割り当てられた計測ノード３０には括弧書きで「６０」を併記している。
【００６０】
括弧書きで「４０」を併記した計測ノード３０では、配信サーバ１０との間のルータに対応する他の計測ノード３０が存在しない。そのような計測ノード３０には、役割として
「代表」が割り当てられる。「代表」及び「計測」の何れも割り当てられない計測ノード３０には、役割として「中継」が割り当てられる。その計測ノード３０には、括弧書きで「５０」を併記している。論理木によって計測ノード３０の位置は異なることから、図５に示すように、「代表」「中継」及び「計測」の全ての役割が１計測ノード３０に割り当てられる場合がある。
【００６１】
中継の役割が割り当てられた計測ノード３０は、下流の計測ノード３０から送信された計測結果を上流の計測ノード３０に転送する、監視対象区間の障害状況を推定する、といったことを行う。代表の役割が割り当てられた計測ノード３０は、それらに加えて、物理ネットワーク上に存在する計測ノード３０のなかで論理木の構築に不要な計測ノード（冗長ノード）３０を排除するための処理を行う。これら役割毎の動作についての詳細は後述する。以降、役割が明らかとなっている計測ノード３０では、その役割に応じた符号を用いることとする。つまり役割が「代表」では「４０」、「中継」では「５０」、「計測」では「６０」を用いる。
【００６２】
図１２は、メッセージ転送部３２ｃを実現させる処理のフローチャートである。次に、図１２を参照して、その転送部３２ｃを実現させる処理について詳細に説明する。この処理は、図１０のステップＳ１３で、例えばリンク構築メッセージの受信を契機に実行される。
【００６３】
先ず、ステップＳ３１では、オーバレイネットワークを構成する他の計測ノード３０から受信されたリンク構築メッセージを取得する。次のステップＳ３２では、リンク構築メッセージに記録されているグループ識別子およびサービストラヒックの送信経路に関する情報を取得する。その次に移行するステップＳ３３では、サービストラヒックの送信経路に関する情報を参照して、送信経路における自ノード３０の位置を確認し、リンク構築メッセージを次に転送すべき計測ノード３０が存在するか否か判定する。リンク構築メッセージを次に転送すべき計測ノード３０が存在しない場合、つまり論理木上の上流に配信サーバ１０が位置している場合、判定はＮＯとなってステップＳ３４に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ３５に移行する。
【００６４】
ステップＳ３４では、取得したグループ識別子に対応する論理木における自ノード３０の役割が「代表」であるとして、グループ情報管理ＤＢ３６の内容を更新する。その後は上記ステップＳ３１に戻る。
【００６５】
ステップＳ３５では、次に転送すべき計測ノード３０にリンク構築メッセージを送信する。リンク構築メッセージの送信経路は、自ノード３０と配信サーバ１０間のネットワーク機器群を含むものに更新して送信する。続くステップＳ３６では、取得したグループ識別子に対応する論理木における自ノード３０の役割が「中継」であるとして、グループ情報管理ＤＢ３６の内容を更新する。その後は上記ステップＳ３１に戻る。
【００６６】
サービストラヒックは、上流側から下流側に送信され、リンク構築メッセージは逆に、下流側から上流側に送信される。それにより、上流側、及び下流側の少なくとも一方に隣接ノード３０が存在する自ノード３０は、その隣接ノード３０や、その隣接ノード３０を介した送信経路を把握することができる。それにより、自ノード３０の役割を適切に設定することができる。
【００６７】
図１３は、隣接エージェント決定部３２ｄを実現させる処理のフローチャートである。次に、図１３を参照して、その決定部３２ｄを実現させる処理について詳細に説明する。この処理は、図１０のステップＳ１４及びＳ１５として実行される。
【００６８】
先ず、ステップＳ４１では、自ノード３０がリンク構築メッセージを生成したか否か判定する。そのリンク構築メッセージを生成していない場合、判定はＮＯとなってステップＳ４２に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ４４に移行する。
【００６９】
ステップＳ４２では、他の計測ノード３０から受信したリンク構築メッセージに記録されているグループ識別子を取得する。次のステップＳ４３では、取得したグループ識別子（論理木）における下流の隣接ノード３０として、リンク構築メッセージの送信元である計測ノード３０の識別子をグループ情報管理ＤＢ３６に記録する。その後はステップＳ４４に移行する。
【００７０】
ステップＳ４４では、次にリンク構築メッセージを転送する計測ノード３０が存在するか否か判定する。その計測ノード３０が存在する場合、判定はＹＥＳとなってステップＳ４５に移行する。そうでない場合には、判定はＮＯとなってステップＳ４６に移行する。
【００７１】
ステップＳ４５では、リンク構築メッセージに記録されているグループ識別子に対応するサービストラヒックの送信経路で自ノード３０より配信サーバ１０側に位置する送信先の隣接ノード３０を論理木の上流の隣接ノード３０として、その識別子をグループ情報管理ＤＢ３６に記録する。続くステップＳ４６では、リンク構築メッセージに記録されている送信経路において、自ノード３０と自ノード３０の下流に位置する隣接ノード３０に対応するネットワーク機器間の経路を監視対象区間として、グループ情報管理ＤＢ３６に記録する。その後はステップＳ４１に戻る。
【００７２】
図１４は、冗長エージェント削除開始部３２ｅを実現させる処理のフローチャートである。次に、図１４を参照して、その開始部３２ｅを実現させる処理について詳細に説明する。この処理は、図１０のステップＳ１４及びＳ１５として実行される。
【００７３】
先ず、ステップＳ５１では、グループ情報管理ＤＢ３６を検索して、自ノード６０が「代表」の役割を持つ論理木における下流の隣接ノード３０の識別子を取得する。次のステップＳ５２では、冗長エージェント削除メッセージを作成する。続くステップＳ５３では、冗長エージェント削除メッセージに、自ノード６０が「代表」の役割を持つ論理木に対応するグループ識別子を記録する。その次に移行するステップＳ５４では、全ての下流の隣接ノード３０に対して、冗長エージェント削除メッセージを送信する。その後は上記ステップＳ５１に戻る。
【００７４】
このようにして冗長エージェント削除メッセージは、役割として「代表」が設定された計測ノード４０のみが生成して送信する。送信された冗長エージェント削除メッセージは、冗長エージェント削除部３２ｆによって処理される。その削除部３２ｆは、図１５にフローチャートを示す処理を実行することで実現される。隣接エージェント発見部３２の構成要素としては最後に、図１５を参照して、その削除部３２ｆを実現させる処理について詳細に説明する。この処理は、例えば削除メッセージの受信を契機にして、図１０のステップＳ１４及びＳ１５として実行される。
【００７５】
図１５に示すフローチャートを説明する前に、図２１を参照して、冗長ノードとして削除対象となる計測ノード３０について具体的に説明する。図２１中、代表の役割を持つ１つの計測ノード４０、中継の役割を持つ５つの計測ノード５０、及び計測の役割を持つ３つの計測ノード６０を含む論理木は、冗長ノードを削除する前のものである。
【００７６】
その論理木では、４つの計測ノード５０が冗長ノードとして削除される。削除される計測ノード５０は何れも、下流に位置する隣接ノード３０は一つのみである。そのように一
つのみ隣接ノード３０が存在する計測ノード３０は事実上、下流の隣接ノード３０から受信した情報を上流の隣接ノード３０に転送するだけである。障害箇所の推定を行う必要はない。しかし、計測ノード３０として機能させる場合、計測ノード３０は計測結果の処理を行うことから、資源を浪費させ、負荷を重くさせる。これは、他の実行すべき処理の効率的な実行を阻害する。また、各種情報の転送にかかる時間をより長くさせる。このようなことから本実施形態では、下流に位置する隣接ノード３０が一つのみの計測ノード３０を冗長ノードとして、論理木上から削除する。
【００７７】
図１５に示す処理では先ず、ステップＳ６１で隣接ノード３０から受信した冗長エージェント削除メッセージを取得する。続くステップＳ６２では、冗長エージェント削除メッセージに記録されているグループ識別子を取得する。その次に移行するステップＳ６３では、グループ情報管理ＤＢ３６を検索して、取得したグループ識別子に対応する論理木上でより下流に位置する隣接ノード３０を把握する。その後はステップＳ６４に移行する。
【００７８】
ステップＳ６４では、把握した下流の隣接ノード３０の数が０か否か判定する。取得したグループ識別子に対応する論理木で自ノード３０の役割が「計測」であった場合、下流に隣接ノード３０は存在しないことから、判定はＹＥＳとなって上記ステップＳ６１に戻る。そうでない場合には、判定はＮＯとなってステップＳ６５に移行する。
【００７９】
ステップＳ６５では、把握した下流の隣接ノード３０の数が２以上か否か判定する。把握した下流の計測ノード３０が２以上であった場合、判定はＹＥＳとなり、ステップＳ６６で下流の全計測ノード３０に冗長エージェント削除メッセージを送信した後、上記ステップＳ６１に戻る。そうでない場合には、判定はＮＯとなってステップＳ６７に移行する。
【００８０】
ステップＳ６７〜Ｓ７１では、冗長ノードの条件を満たす計測ノードを論理木上から削除するための処理が実行される。
先ずステップＳ６７では、自ノード３０の上流の隣接ノード３０に関する情報を、自ノード３０の下流の隣接ノード３０に送信する。これにより、その情報を受信した下流の隣接ノード３０は、その情報が示す隣接ノード３０を自ノード３０の上流の隣接ノード３０として、グループ情報管理ＤＢ３６を更新する。
【００８１】
次にステップＳ６８では、自ノード３０の下流の隣接ノード３０に関する情報を、自ノード３０の上流の隣接ノード３０に送信する。これにより、その情報を受信した上流の隣接ノード３０は、その情報が示す隣接ノード３０を自ノード３０の下流の隣接ノード３０として、グループ情報管理ＤＢ３６を更新する。
【００８２】
次にステップＳ６９では、自ノード３０の監視対象区間に関する情報を、自ノード３０の上流の隣接ノード３０に送信する。これにより、その情報を受信した計測ノード３０は、その情報が示す監視対象区間を自ノード３０の監視対象区間に加え、グループ情報管理ＤＢ３６を更新する。
【００８３】
次にステップＳ７０では、下流の計測ノード３０に冗長エージェント削除メッセージを送信する。その後に移行するステップＳ７１では、ステップＳ６２で取得したグループ識別子に対応する情報をグループ情報管理ＤＢ３６から削除する。その削除後は上記ステップＳ６１に戻る。
【００８４】
図１６は、図９のステップＳ５〜Ｓ７として実行される処理の詳細を示すフローチャートである。障害箇所推定部３３は、図１６に示す処理を実行することにより実現される。次に図１６を参照して、障害箇所推定部３３を実現させる処理についてより具体的に説明
する。
【００８５】
先ず、ステップＳ８１では、「計測結果の算出間隔」で指定された時間ごとに、配信サーバ１０から受信しているサービストラヒックの計測結果である受信品質（図中「計測情報」）を取得する。次のステップＳ８２では、取得した受信品質を自ノード３０の上流の隣接ノード３０、或いは監視サーバ２０に計測結果として送信する。その後はステップＳ８３に移行する。
【００８６】
役割として「計測」が設定されていない計測ノード３０では、下流の隣接ノード３０から計測結果が送信される。このことからステップＳ８３では、受信した計測結果を計測結果収納ＤＢ３４に格納すると共に、その収納ＤＢ３４に格納されている計測結果を解析して、監視対象区間内／外の障害状況を推定する。推定結果は解析結果収納ＤＢ３５に格納する。その格納後に移行するステップＳ８４では、推定した障害状況を上流の隣接ノード３０、或いは監視サーバ２０に通知する。その通知後は上記ステップＳ８１に戻る。
【００８７】
図１７〜図１９は、障害箇所推定部３３を構成する各部３３ａ〜３３ｃを実現させる各種処理のフローチャートである。次に図１７〜図１９の各フローチャートを参照して、各部３３ａ〜３３ｃを実現させる処理について詳細に説明する。
【００８８】
図１７は、計測結果通知部３３ａを実現させる処理のフローチャートである。始めに図１７を参照して、その通知部３３ａを実現させる処理について詳細に説明する。この処理は、上記ステップＳ８２で、「計測結果の通知間隔」として指定された時間ごとに実行される。
【００８９】
先ず、ステップＳ９１では、グループ情報管理ＤＢ３６を検索し、自ノード３０が「計測」の役割を持つ論理木に対応するグループ識別子を取得する。続くステップＳ９２では、グループ情報管理ＤＢ３６を検索し、ステップＳ９１で取得したグループ識別子に対応する論理木で上流に位置する隣接ノード３０に関する情報を取得する。ステップＳ９３には、その情報を取得した後に移行する。
【００９０】
ステップＳ９３では、ステップＳ９１で取得したグループ識別子に対応する配信サーバ１０から受信しているサービストラヒックの受信品質を計測結果として取得する。その次のステップＳ９４では、その計測結果を上流の隣接ノード３０に送信する。その送信を行った後は上記ステップＳ９１に戻り、「計測結果の通知間隔」として指定された時間が経過するのを待って実行する。
【００９１】
上記のようにして送信された計測結果を受信した計測ノード３０は、計測結果収納ＤＢ３４に格納する。このとき、図６に示すように、グループ識別子、及び計測結果を送信した計測ノード３０の監視対象区間を併せて格納する。
【００９２】
図１８は、計測結果解析部３３ｂを実現させる処理のフローチャートである。次に図１８を参照して、その解析部３３ｂを実現させる処理について詳細に説明する。この処理は、図１６のステップＳ８３及びＳ８４として、「計測結果の解析間隔」で指定された時間ごとに実行される。
【００９３】
先ず、ステップＳ１０１では、グループ情報管理ＤＢ３６を検索して、自ノード３０が「代表」または「中継」の役割を持つ論理木に対応するグループ識別子を取得する。次のステップＳ１０２では、計測結果収容ＤＢ３４を検索して、ステップＳ１０１で取得したグループ識別子に対応する計測結果を取得する。その取得後はステップＳ１０３に移行する。
【００９４】
ステップＳ１０３では、取得した計測結果を解析し、各グループ識別子に対応する計測結果が全てＧｏｏｄとなっているか否か判定する。計測結果が全てＧｏｏｄでなかった場合、判定はＮＯとなってステップＳ１０９に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ１０４に移行する。
【００９５】
ここで、図２２に示す説明図を参照して、監視対象区間の内／外の障害状況の推定方法について具体的に説明する。この図２２において、３０−１は自ノード、３０−２及び３０−３は共に自ノード３０−１の下流に位置する隣接ノードを指していることとする。
【００９６】
自ノード３０−１は、２つの隣接ノード３０−２及び３０−３に対応するネットワーク機器にそれぞれ転送するサービストラヒックを解析して，障害箇所を推定する．その解析により、隣接ノード３０−２及び３０−３への受信品質が共にＧｏｏｄであれば、自ノード３０−１の監視対象区間の内／外もＧｏｏｄと推定する。しかし、隣接ノード３０−３に対応するネットワーク機器への受信品質がＧｏｏｄ、隣接ノード３０−３に対応するネットワーク機器への受信品質がＢａｄといったように、ＧｏｏｄとＢａｄの受信品質が混在している場合には、障害箇所は下流にのみ存在すると推定する。これは、自ノード３０−１に対応するネットワーク機器まではサービストラヒックが適切に送信されている可能性が高いからである。
【００９７】
一方、受信品質が全てＢａｄであった場合には、障害箇所は上流にのみ存在すると推定する。これは、上流に障害が発生していれば、その障害箇所より下流では全て受信品質はＢａｄとなるからである。このことから、自ノード３０−１に対応するネットワーク機器と配信サーバとの間の何れかのリンクに障害が発生していると推定し、その推定結果をその隣接ノード３０に通知する。
【００９８】
そのような推定結果が通知された隣接ノード３０では、同様にして、監視対象区間の受信品質から、監視対象区間の内／外の障害箇所を推定する。このとき、下流の隣接ノード３０から上流に障害箇所が存在することを示す推定結果を受信していた場合、監視対象区間の受信品質が全てＢａｄであれば障害箇所は上流に存在すると推定する。そのようにして、上流に発生した障害箇所は、下流から順次、推定結果が上流の計測ノード３０に通知されることにより、特定されるか、存在する可能性のある範囲が狭められる。この結果、たとえ計測ノード３０によって障害箇所を推定できなくとも、監視サーバ２０は容易に障害箇所を特定できることとなる。その障害箇所を特定するために必要な情報量も大幅に低減される。
【００９９】
図１８の説明に戻る。
上記ステップＳ１０３の判定がＹＥＳ、つまり全ての監視対象区間の受信品質がＧｏｏｄであった場合に移行するステップＳ１０４では、全監視対象区間の品質をＧｏｏｄと推定する。続くステップＳ１０５では、監視対象区間外の品質をＧｏｏｄと推定する。その次に移行するステップＳ１０６では、監視対象区間毎に品質、即ち障害の推定結果を解析結果収納ＤＢ３５に格納する。そのように監視対象区域内／外の障害状況を推定し、その推定結果を保存してから、ステップＳ１０７に移行する。
【０１００】
ステップＳ１０７では、グループ情報管理ＤＢ３６を検索して、自ノード３０に役割として中継が設定されたグループ識別子が存在するか否か判定する。そのようなグループ識別子が存在する場合、判定はＹＥＳとなってステップＳ１０８に移行し、監視対象区間外の推定結果を受信品質として計測結果を生成し、上流の隣接ノード３０に送信した後、上記ステップＳ１０１に戻る。そうでない場合には、判定はＮＯとなって、そのステップＳ１０１に戻る。ステップＳ１０１の実行は、「計測結果の解析間隔」として指定された時
間が経過するのを待って行う。
【０１０１】
一方、上記ステップＳ１０３の判定がＮＯとなって移行するステップＳ１０９では、取得した計測結果が全てＢａｄか否か判定する。計測結果が全てＢａｄでなかった場合、つまりＢａｄとＧｏｏｄが混在していた場合、判定はＮＯとなってステップＳ１１２に移行する。そうでない場合には、判定はＹＥＳとなってステップＳ１１０に移行する。
【０１０２】
ステップＳ１１０では、全ての監視対象区間の品質をＧｏｏｄと推定する。続くステップＳ１１１では、監視対象区間外の品質をＢａｄと推定する。そのようにして監視対象区間の内／外の障害状況を推定してから、上記ステップＳ１０６に移行する。
【０１０３】
ステップＳ１１２では、下流の隣接ノード３０（図２２では隣接ノード３０−３が相当）と結ぶ監視対象区間をＢａｄと推定する。続くステップＳ１１３では、監視対象区間外の品質をＧｏｏｄと推定する。そのようにして監視対象区間の内／外の障害状況を推定した後、上記ステップＳ１０６に移行する。
【０１０４】
ステップＳ１１２への移行は、下流の隣接ノード３０と結ぶリンクに障害が発生した場合に実現される。その場合、下流の隣接ノード３０はリンクを介して受信されるサービストラヒックを計測し、計測結果としてＢａｄを送信する。自ノード３０自体は、自身が受信するサービストラヒックを計測し、計測結果としてＧｏｏｄを得る。このことから、自ノード３０は、下流の隣接ノード３０と結ぶリンクである監視対象区間に障害が発生したと推定する。
【０１０５】
図１９は、障害箇所通知部３３ｃを実現させる処理のフローチャートである。障害箇所推定部３３の構成要素としては最後に、図１９を参照して、その通知部３３ｃを実現させる処理について詳細に説明する。この処理は、図１６のステップＳ８４内で、「解析結果の通知間隔」として指定された時間ごとに実行される。
【０１０６】
先ず、ステップＳ２０１では、解析結果収容ＤＢ３５を検索して、受信品質がＢａｄである監視対象区間、つまり推定した障害箇所（リンク）に関する情報を取得する。続くステップＳ２０２では、取得した監視対象区間に関する情報を監視サーバ２０宛に送信する。その後は上記ステップＳ２０１に戻る。そのステップＳ２０１の実行は、「解析結果の通知間隔」として指定された時間が経過するのを待って行う。
【０１０７】
各計測ノード３０が管理する解析結果収納ＤＢ３５には、自ノード３０より下流の計測ノード３０による解析結果が反映された解析結果が格納される。このため、受信品質がＢａｄの監視対象区間は、障害が発生しているか、或いは障害が発生している可能性が考えられる区間となっている。そのような監視対象区間のみを監視サーバ２０に通知することにより、監視サーバ２０はより少ない情報量で障害が発生している監視対象区間（リンク）を高精度に特定することができる。その監視サーバ２０は、受信した監視対象区間に関する情報は図２３に示す障害推定箇所ＤＢ２３に格納する。
【０１０８】
以降は図２３〜図２７を参照して、監視サーバ２０について具体的に説明する。
図２３は、監視サーバ２０の機能構成を示す図である。図２３に示す機能構成は、計測ノード３０と同様に、監視サーバ２０として動作させるための機能を搭載したプログラム（以降、便宜的に「監視プログラム」と呼ぶ）を監視サーバ２０に実行させることで実現される。その監視プログラムは、監視サーバ２０上に障害箇所特定部２２を実現させ、障害推定箇所ＤＢ２３を生成・管理する。
【０１０９】
監視サーバ２０には、計測ノード３０と同様に、図２８に示す構成のコンピュータを用
いることができる。図２８に示す構成では、例えば監視プログラムは外部記憶装置８５、若しくは記録媒体ＭＤに格納されているか、或いはネットワーク接続装置８７によりネットワーク７０を介して外部装置から受信する。障害推定箇所ＤＢ２３は、例えば外部記憶装置８５上に構築される。
【０１１０】
障害推定箇所ＤＢ２３には、上述したように、各計測ノード３０が推定した障害箇所を示す情報が障害箇所特定部２２によって格納される。そのＤＢ２３には、図２４に示すように、グループ識別子毎に推定された故障箇所を示す情報が格納される。図２４では、推定故障箇所はＩＰアドレスで示している。それにより事実上、図２９に示す表のように送信経路上で受信品質がＢａｄの箇所（リンク）を表すものとなっている。後述する図２７では、図２９と同じく、Ｂａｄの受信品質を表す値として１を用いている。
【０１１１】
障害箇所特定部２２を実現させる監視プログラムは、以下のような処理を監視サーバ２０に実行させる。以降は図２５及び図２６に示す各種フローチャートを参照して、監視プログラムにより実現される処理について詳細に説明する。
【０１１２】
図２５は、監視プログラムにより実行される処理の全体的な流れを示すフローチャートである。始めに図２５を参照して、その処理の全体的な流れについて具体的に説明する。
監視プログラムは、管理者からの起動要求に応じて起動される（ステップＳ３０１）。起動後は、例えば管理者の指示に従って「計測結果の特定間隔」といった設定パラメータの読み込みを行う（ステップＳ３０２）。その特定間隔とは、障害箇所の特定を行う時間間隔のことであり、その時間間隔として指定された時間が１０秒であれば、障害箇所の特定は１０秒間隔で行われることとなる。
【０１１３】
設定パラメータの読み込みを行った後は、計測ノード３０から障害箇所と推定された区間（リンク）の情報を随時、受信して取得し、その情報を障害推定箇所ＤＢ２３に格納する（ステップＳ３０３）。その情報への対応は、「計測結果の特定間隔」として指定された時間に従って行い、ステップＳ３０４に移行する。そのステップＳ３０４では、障害推定箇所ＤＢ２３から障害箇所と推定された区間の情報（計測結果）を読み出し、読み出した情報を解析して、障害箇所を特定する。その特定結果は、例えば監視サーバ２０に設けられた障害箇所出力Ｉ／Ｆを介して外部に公開する。この公開方法としては、解析結果を格納する目的で設けられたＤＢへの情報の書き出し、ソケット通信による外部プロセスへの情報受け渡し、Ｗｅｂ上に公開する方法などが考えられる。そのような公開を行った後に上記ステップＳ３０３に戻る。それにより、障害箇所の特定は「計測結果の特定間隔」として指定された時間毎に行う。
【０１１４】
図２６は、障害箇所特定部２２を実現させる処理のフローチャートである。最後に、図２６を参照して、その特定部２２を実現させる処理について詳細に説明する。この処理は、上記ステップＳ３０４で実行される部分を抽出して示したものである。
【０１１５】
先ず、ステップＳ４０１では、障害推定箇所ＤＢ２３から全ての情報を読み出す。続くステップＳ４０２では、読み出した情報を解析し、図２７に示すように、複数のグループ識別子に共通して含まれている区間を抽出し、抽出した区間を障害箇所と特定する。その特定後、図２６に示す一連の処理を終了する。終了後に、障害箇所の特定結果の公開が行われる。
【０１１６】
以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知システムにおいて、
前記ネットワーク障害システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを備え、
前記ノードは、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害リンク推定手段と、を具備し、
前記監視サーバは、
前記ノードから受信した前記障害箇所の推定結果を解析して、前記送信経路上の障害箇所を特定する障害リンク特定手段、を具備する、
ことを特徴とするネットワーク障害検知システム。
（付記２）
付記１記載のネットワーク障害検知システムを構成するノードとして用いられるデータ処理装置であって、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定手段と、
を具備することを特徴とするデータ処理装置。
（付記３）
前記隣接ノード特定手段は、前記ツリー構造上で認識した自身の位置を基に、該ツリー構造上、冗長なノードか否か判定し、該冗長なノードと判定した場合に、該ツリー構造上から離脱するための処理を行う、
ことを特徴とする付記２記載のデータ処理装置。
（付記４）
前記隣接ノード特定手段は、前記ツリー構造上で下流に位置する隣接ノードとの間のリンクを前記監視対象リンクとして設定する、
ことを特徴とする付記２記載のデータ処理装置。
（付記５）
前記障害箇所推定手段は、前記監視対象リンクに加えて、前記ツリー構造上で上流に位置する隣接ノードとの間のリンクを対象に前記推定を行い、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する、
ことを特徴とする付記４記載のデータ処理装置。
（付記６）
前記障害箇所推定手段は、前記障害箇所の推定結果を送信する隣接ノードとして、前記ツリー構造上で上流に位置する隣接ノードを対象にする、
ことを特徴とする付記２、または５記載のデータ処理装置。
（付記７）
前記障害箇所推定手段は、前記ツリー構造上で下流に位置する隣接ノードから前記障害
箇所の推定結果を受信した場合に、該推定結果を該障害箇所の推定に用いる、
ことを特徴とする付記６記載のデータ処理装置。
（付記８）
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知方法において、
前記障害を検知するためのネットワーク障害検知システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを用いて構築し、
前記ネットワーク障害検知システムを構成するノードに、前記サービストラヒックの送信経路に対応した論理的なツリー構造の自律的な構築、及び該送信経路の中で前記障害の発生を監視すべき監視対象区間の設定を行わせて、該設定した監視対象区間で発生する障害を監視させ、
前記監視サーバによる前記送信経路上の障害の特定は、各ノードによる障害の監視結果を用いて行わせる、
ことを特徴とするネットワーク障害検知方法。
（付記９）
付記１記載のネットワーク障害検知システムを構成するノードとして用いられるコンピュータに、
前記サービストラヒックを計測する計測機能と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定機能と、
前記計測機能による計測結果を用いて、前記隣接ノード特定機能が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定機能と、
を実現させるためのプログラム。
【図面の簡単な説明】
【０１１７】
【図１】本実施形態によるネットワーク障害検知システムの構成を説明する図である。
【図２】計測エージェントを実行するノードの機能構成を示す図である。
【図３】隣接エージェント発見部の機能構成を示す図である。
【図４】障害箇所推定部の機能構成を示す図である。
【図５】グループ情報管理ＤＢのデータ構成を示す図である。
【図６】計測結果収納ＤＢのデータ構成を示す図である。
【図７】解析結果収納ＤＢのデータ構成を示す図である。
【図８】計測エージェントを実行するノードが障害を監視する監視対象区間の説明図である。
【図９】計測エージェントにより実行される処理の全体的な流れを示すフローチャートである。
【図１０】図９のステップＳ３及びＳ４として実行される処理の詳細を示すフローチャートである。
【図１１】メッセージ送出部を実現させる処理のフローチャートである。
【図１２】メッセージ転送部を実現させる処理のフローチャートである。
【図１３】隣接エージェント決定部を実現させる処理のフローチャートである。
【図１４】冗長エージェント削除開始部を実現させる処理のフローチャートである。
【図１５】冗長エージェント判断部を実現させる処理のフローチャートである。
【図１６】図９のステップＳ５〜Ｓ７として実行される処理の詳細を示すフローチャートである。
【図１７】計測情報通知部を実現させる処理のフローチャートである。
【図１８】計測結果解析部を実現させる処理のフローチャートである。
【図１９】障害箇所通知部を実現させる処理のフローチャートである。
【図２０】リンク構築メッセージに格納されるデータを示す図である。
【図２１】論理木上から削除対象となるノードの説明図である。
【図２２】ノードでの障害箇所の推定方法を示す図である。
【図２３】監視サーバの機能構成を示す図である。
【図２４】障害推定箇所ＤＢのデータ構成を示す図である。
【図２５】監視サーバの監視プログラムにより実行される処理の全体的な流れを示すフローチャートである。
【図２６】障害箇所特定部を実現させる処理のフローチャートである。
【図２７】監視サーバによる障害箇所の特定方法を示す説明図である。
【図２８】計測ノードとして用いることが可能なコンピュータのハードウェア構成の一例を示す図である。
【図２９】従来のネットワーク障害検知システムで行われている障害箇所の特定方法を示す説明図である。
【符号の説明】
【０１１８】
１０ 配信サーバ
２０ 監視サーバ
２２ 障害箇所特定部
２３ 障害推定箇所ＤＢ
３０ ノード
３１ 計測部
３２ 隣接エージェント発見部
３２ａ オーバレイネットワーク機能部
３２ｂ メッセージ送出部
３２ｃ メッセージ転送部
３２ｄ 隣接エージェント決定部
３２ｅ 冗長エージェント削除開始部
３２ｆ 冗長エージェント判断部
３３ 障害箇所推定部
３３ａ 計測情報通知部
３３ｂ 計測結果解析部
３３ｃ 障害箇所通知部
３４ 計測結果収納ＤＢ
３５ 解析結果収納ＤＢ
３６ グループ情報管理ＤＢ
７０ ネットワーク
【特許請求の範囲】
【請求項１】
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知システムにおいて、
前記ネットワーク障害システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを備え、
前記ノードは、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害リンク推定手段と、を具備し、
前記監視サーバは、
前記ノードから受信した前記障害箇所の推定結果を解析して、前記送信経路上の障害箇所を特定する障害リンク特定手段、を具備する、
ことを特徴とするネットワーク障害検知システム。
【請求項２】
請求項１記載のネットワーク障害検知システムを構成するノードとして用いられるデータ処理装置であって、
前記データ処理装置は、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定手段と、
を具備することを特徴とするネットワーク障害検知システム。
【請求項３】
前記隣接ノード特定手段は、前記ツリー構造上で認識した自身の位置を基に、該ツリー構造上、冗長なノードか否か判定し、該冗長なノードと判定した場合に、該ツリー構造上から離脱するための処理を行う、
ことを特徴とする請求項２記載のネットワーク障害検知システム。
【請求項４】
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知方法において、
前記障害を検知するためのネットワーク障害システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを用いて構築し、
前記ネットワーク障害検知システムを構成するノードに、前記サービストラヒックの送信経路に対応した論理的なツリー構造の自律的な構築、及び該ツリー構造上で前記障害の発生を監視すべき監視対象区間の設定を行わせて、該設定した監視対象区間で発生する障
害を監視させ、
前記監視サーバによる前記送信経路上の障害の特定は、各ノードによる障害の監視結果を用いて行わせる、
ことを特徴とするネットワーク障害検知方法。
【請求項５】
請求項１記載のネットワーク障害検知システムを構成するノードとして用いられるコンピュータに、
前記サービストラヒックを計測する計測機能と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定機能と、
前記計測機能による計測結果を用いて、前記隣接ノード特定機能が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定機能と、
を実現させるためのプログラム。
【請求項１】
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知システムにおいて、
前記ネットワーク障害システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを備え、
前記ノードは、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害リンク推定手段と、を具備し、
前記監視サーバは、
前記ノードから受信した前記障害箇所の推定結果を解析して、前記送信経路上の障害箇所を特定する障害リンク特定手段、を具備する、
ことを特徴とするネットワーク障害検知システム。
【請求項２】
請求項１記載のネットワーク障害検知システムを構成するノードとして用いられるデータ処理装置であって、
前記データ処理装置は、
前記サービストラヒックを計測する計測手段と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定手段と、
前記計測手段による計測結果を用いて、前記隣接ノード特定手段が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定手段と、
を具備することを特徴とするネットワーク障害検知システム。
【請求項３】
前記隣接ノード特定手段は、前記ツリー構造上で認識した自身の位置を基に、該ツリー構造上、冗長なノードか否か判定し、該冗長なノードと判定した場合に、該ツリー構造上から離脱するための処理を行う、
ことを特徴とする請求項２記載のネットワーク障害検知システム。
【請求項４】
ネットワーク上に配置された配信サーバからサービストラヒックが送信される送信経路上に発生している障害を検知するためのネットワーク障害検知方法において、
前記障害を検知するためのネットワーク障害システムは、前記送信経路上に存在し、前記配信サーバから送信されるサービストラヒックを監視するノード、及び該ノードから送信される情報を解析して障害が発生している障害箇所を特定する監視サーバを用いて構築し、
前記ネットワーク障害検知システムを構成するノードに、前記サービストラヒックの送信経路に対応した論理的なツリー構造の自律的な構築、及び該ツリー構造上で前記障害の発生を監視すべき監視対象区間の設定を行わせて、該設定した監視対象区間で発生する障
害を監視させ、
前記監視サーバによる前記送信経路上の障害の特定は、各ノードによる障害の監視結果を用いて行わせる、
ことを特徴とするネットワーク障害検知方法。
【請求項５】
請求項１記載のネットワーク障害検知システムを構成するノードとして用いられるコンピュータに、
前記サービストラヒックを計測する計測機能と、
前記送信経路に対応した論理的なツリー構造上で隣接するノードである隣接ノードを認識してリンクを確立し、該ツリー構造上における自身の位置を認識して、該ツリー構造上で前記障害の発生を監視すべきリンクである監視対象リンクを設定する隣接ノード特定機能と、
前記計測機能による計測結果を用いて、前記隣接ノード特定機能が設定した監視対象リンクのなかで前記障害が発生している可能性のある監視対象リンクを障害箇所として推定し、該推定結果を前記隣接ノード及び前記監視サーバのうちの一方に送信する障害箇所推定機能と、
を実現させるためのプログラム。
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１１】
【図１３】
【図１９】
【図２３】
【図２４】
【図２５】
【図２６】
【図２８】
【図１】
【図８】
【図９】
【図１０】
【図１２】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２０】
【図２１】
【図２２】
【図２７】
【図２９】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１１】
【図１３】
【図１９】
【図２３】
【図２４】
【図２５】
【図２６】
【図２８】
【図１】
【図８】
【図９】
【図１０】
【図１２】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２０】
【図２１】
【図２２】
【図２７】
【図２９】
【公開番号】特開２０１０−１１３７４（Ｐ２０１０−１１３７４Ａ）
【公開日】平成２２年１月１４日（２０１０．１．１４）
【国際特許分類】
【出願番号】特願２００８−１７１３０９（Ｐ２００８−１７１３０９）
【出願日】平成２０年６月３０日（２００８．６．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年１月１４日（２０１０．１．１４）
【国際特許分類】
【出願日】平成２０年６月３０日（２００８．６．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]