JP2008228035A - ネットワークシステム、ノード装置及び管理サーバ - Google Patents

Abstract

【課題】経路に障害が無くとも通信遅延により障害を誤検出することを防ぐ。
【解決手段】ノード装置は、決定された障害検出時間が経過してもパケットを対向ノード装置から受信しないことにより、対向ノード装置との経路の障害を検出する。ノード装置は、対向ノード装置とのネゴシエーションによって定められたパケットの送信間隔に基づき、「リモートシステムのパケット送信間隔×障害検出乗数」を第１の障害検出時間６０とする。また、「リモートシステムのパケット実送信間隔×障害検出乗数」６１と「許容する遅延時間」６２の和を、第２の障害検出時間６３とする。第１の障害検出時間６０と第２の障害検出時間６３とを比較し、大きい方の値を実運用で適用する障害検出時間６４として決定する。
【選択図】図６

Description

本発明は、ネットワークシステム、ノード装置及び管理サーバに係り、特に、ノード装置間の通信障害を監視する障害検出プロトコルに関し、さらに、障害誤検知を防ぐために行う障害検出時間を補正するネットワークシステム、ノード装置及び管理サーバに関する。

ノード装置間において、ネクストホップ間の通信障害を検出するための、ルーティングプロトコルからは独立したプロトコルとして、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ）の標準化がＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で進められている。ＢＦＤはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を使ってシステム間で定期的なパケットの送受信を行い、一定時間パケットを受信しなかった場合に、通信路の障害（経路の障害）が発生したものとみなす。上記一定時間は予め定められ、以下障害検出時間と記す。障害検出時間はパケットを送信する間隔と、そのパケットがいくつ連続でロスした場合に障害と見なすかという障害検出乗数で算出され、その式は「送信間隔×障害検出乗数」で求めることが、例えば非特許文献１で定められている。
Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ、ｄｒａｆｔ−ｉｅｔｆ−ｂｆｄ−ｂａｓｅ−０５、Ｊｕｎｅ、２００６

障害検出用プロトコルであるＢＦＤプロトコルは、ＢＦＤパケットの通信遅延対策として、パケット送信を行う際はネゴシエーションにより決定した送信間隔を特定倍率だけ減少させた値を用いるよう規定している。例えば、実送信間隔を、決定されたパケット送信間隔の７５％〜１００％になるようにしている。この減少分が遅延の許容量に相当する。規定に則り、例えば、送信間隔を５０ミリ秒、障害検出乗数を１とした場合は、遅延に対する許容値は５〜１２．５ミリ秒となり、許容値以上の通信遅延が発生した場合は受信側の待ち時間内にパケットが到達しないことにより、通信障害を誤検出するという課題がある。ＢＦＤでは遅延の許容値はリモートシステムのパケット送信間隔に比例するため、送信間隔が短くなるほど遅延によって障害を誤検出する可能性が高くなる。
例えば、通信障害を検出するとプロトコル制御機能は経路の切替えを行う場合がある。ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）やＩＳ−ＩＳ（Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ−Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ）における経路切替えは高負荷なので、障害の誤検出によって切替えが頻発した場合はシステムの性能悪化に繋がる。そのため遅延による障害の誤検出はできるだけ抑えたいという課題がある。
本発明は、以上の点に鑑み、対向装置からのパケット送信間隔が短い場合でも、遅延として許容する基準値である必要猶予時間までの遅延であれば、これを通信障害として誤検出することを回避するネットワークシステム、ノード装置及び管理サーバを提供することを目的とする。また、本発明は、無用な迂回経路への切替えが発生を抑え、安定したネットワーク運用を行うことを目的のひとつとする。
また、本発明は、補正前の障害検出時間が必要障害検出時間（リモート送信時間＋必要猶予時間）より短い場合のみ補正を行い、障害検出時間を補正したことによる検出の遅れを抑えることを目的のひとつとする。

本発明は、例えば、障害検出時間補正手段により、リモートノードからパケットを受信しなかった際に障害を検出する時間である障害検出時間の値が、リモートノードが実際にパケットを送信する間隔であるリモート実送信間隔に、許容する遅延時間である必要猶予時間を加えたもの以上となるよう補正を行う。リモートノードからのパケット通信に必要猶予時間以下の遅延が発生しても誤って障害を検出せず、遅延に対する猶予時間が十分な場合は補正を行わない。

本発明の第１の解決手段によると、
複数のノード装置を備えたネットワークシステムであって、
前記ノード装置はそれぞれ、対向するノード装置との経路の障害を検出する障害検出部を備え、
第１のノード装置の前記障害検出部は、
対向する第２のノード装置とネゴシエーションによって、障害検出のためのパケットの送信間隔を定め、
前記第２のノード装置から送信される障害検出のためのパケットを受信し、及び、
決定された障害検出時間が経過しても前記パケットを前記第２のノード装置から受信しないことにより、該第２のノード装置との経路の障害を検出し、
前記障害検出時間は、前記第１のノード装置の前記障害検出部が、
前記第２のノード装置とのネゴシエーションによって定められた前記パケットの送信間隔に基づく第１の障害検出時間を求め、
予め設定された又は予め求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて、第２の障害検出時間を求め、
第１の障害検出時間と第２の障害検出時間とを比較し、大きい方の値が実運用で適用する前記障害検出時間として決定される
前記ネットワークシステムが提供される。

本発明の第２の解決手段によると、
複数のノード装置を備えたネットワークシステムにおける前記ノード装置であって、
前記ノード装置は、対向ノード装置との経路の障害を検出する障害検出部を備え、
前記障害検出部は、
対向ノード装置とネゴシエーションによって、障害検出のためのパケットの送信間隔を定め、
対向ノード装置から送信される障害検出のためのパケットを受信し、及び、
決定された障害検出時間が経過しても前記パケットを前記対向ノード装置から受信しないことにより、該対向ノード装置との経路の障害を検出し、
前記障害検出時間は、前記障害検出部が、
前記対向ノード装置とのネゴシエーションによって定められた前記パケットの送信間隔に基づく第１の障害検出時間を求め、
予め設定された又は予め求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて、第２の障害検出時間を求め、
第１の障害検出時間と第２の障害検出時間とを比較し、大きい方の値が実運用で適用する前記障害検出時間として決定される
前記ノード装置が提供される。

本発明の第３の解決手段によると、
第１及び第２のノード装置と管理サーバとを備えたネットワークシステムにおいて、前記第１のノード装置が、前記第２のノード装置とのネゴシエーションによって定められた障害検出のためのパケットの送信間隔に基づく第１の障害検出時間と、管理サーバより受信される猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えた第２の障害検出時間とのいずれかを障害検出時間として決定し、決定された障害検出時間が経過しても障害検出のための前記パケットを前記第２のノード装置から受信しないことにより、該第２のノード装置との経路の障害を検出する前記ネットワークシステムにおける前記管理サーバであって、
前記管理サーバは、
第１のノード装置の接続負荷情報と第２のノード装置の接続負荷情報に対応して、猶予時間が予め記憶されたテーブル
を有し、
第１のノード装置と対向する第２のノード装置で接続を行う旨の通知を、該第１のノード装置から受信し、
第１及び第２のノード装置から、それぞれの装置の接続負荷情報を受信し、
第１及び第２のノード装置から受信された接続負荷情報に基づき、前記テーブルを検索して対応する猶予時間を求め、前記第１及び第２のノード装置に猶予時間を送信し、
前記第１及び第２のノード装置により、該猶予時間を用いて前記第２の障害検出時間が求められるための前記管理サーバが提供される。

本発明により、対向装置からのパケット送信間隔が短い場合でも、遅延として許容する基準値である必要猶予時間までの遅延であれば、これを通信障害として誤検出することを回避するネットワークシステム、ノード装置及び管理サーバを提供することが出来る。これにより、本発明は、無用な迂回経路への切替えが発生しなくなるため、安定したネットワーク運用を行うことが出来る。
また、本発明は、補正前の障害検出時間が必要障害検出時間（リモート送信時間＋必要猶予時間）より短い場合のみ補正を行うため、障害検出時間を補正したことによる検出の遅れを抑えるという利点がある。

１．システム構成
図１は、本実施の形態の通信障害検出システムの一構成例を示す図である。
通信障害検出システム（ネットワークシステム）は、例えば、複数のノード装置１０（以下、ノード）を備える。
ノードＡ（１０ａ）とノードＥ（１０ｅ）の間の通信路として、ノードＢ（１０ｂ）を介する経路１３と、ノードＣ（１０ｃ）とノードＤ（１０ｄ）を介する経路１４が存在する場合、ノードＡは、隣接する各ノード（ノードＢ、ノードＣ）との間で通信障害検出プロトコル（例えば、ＢＦＤ）を用いて障害の監視を行う。例えば、ＯＳＰＦやＩＳ−ＩＳ、またはｓｔａｔｉｃな経路設定により、ノードＡとノードＥの間の通信経路が経路１３で運用されていた時に、ノードＡとノードＢの間で監視を行っていた通信障害検出プロトコルで通信障害が検出された場合、通信障害検出プロトコルは同一ノード内の経路制御部に障害通知を挙げることで、ノードＡとノードＥの間の代替経路である経路１４に通信経路を切り替える。

なお、本実施の形態で示す障害とは、例えば、ノードＡがノードＢを介してノードＥに対してパケットを送信する際に、パケットがノードＥに到達しない状態のことを指す。従って、ある程度の遅延を伴うがパケットが到達する状態は検出対象の障害と見なさない。
図７は、本実施の形態の通信障害検出機能を有するノード装置の一構成例を示した装置ブロック図である。
ノード装置は、例えば、ユーザインタフェース７ｈと、上位アプリケーション（上位ＡＰ）７２と、ネットワークノード部７０と、ネットワークＩ／Ｆ７５と、メモリ７６と、記憶装置７７と、ＣＰＵ７ｇとを有する。ネットワークノード部７０は、障害検知プロトコル部７１、ＵＤＰ層７３、ＩＰ層７４を含む。
障害検知プロトコル部（障害検出部）７１は、経路制御などを行う機能モジュールである上位アプリケーション７２からの要求により、対象通信路の通信障害を監視する。障害検知プロトコルがＢＦＤの場合は、障害検知プロトコル自体はレイヤ３以上のプロトコルとなり、下位にはＵＤＰ層７３、ＩＰ層７４という構造になる。障害検知パケットは、物理的にはネットワークインタフェース７５を介在してリモートノードとのパケット送受信を行う。これらの機能をソフトウェアプログラムとして実装する場合は、記憶装置７７からメモリ７６上にロードして、ＣＰＵ（７ｇ）で実行する。

障害検知プロトコル部７１は、タイマ処理機構７８と、送信機構７９と、受信機構７ａと、セッション情報管理部７ｉを有する。タイマ処理機構７８は、周期送信タイマ７ｂと、障害検出タイマ７ｄと、タイマ補正部７ｆとを有する。また、送信機構７９は送信処理部７ｃを有し、受信機構７ａは受信処理部７ｅを有する。リモートノードとのネゴシエーションなどのセッション情報の獲得や更新の処理は、セッション情報管理部７ｉで行う。パケットを周期的に送信する際には、周期送信タイマ７ｂが契機を与えて、セッション情報管理部７ｉの情報を基に送信処理部７ｃがパケットを生成して送信する。
障害を検出する際には、受信処理部７ｅがパケットの受信を監視し、セッション管理部７ｉの情報を基に障害検出タイマ７ｄが障害検出時間の経過を監視する。障害検出時間が経過するまでの間に、受信処理部７ｅからパケット受信の通知がない場合は、障害とみなして上位アプリケーション７２に通知を行う。上位アプリケーション７２は、障害の通知を受けると、例えば経路を切り替える。

本実施の形態では、タイマ処理機構７８にタイマ補正部７ｆを有する。タイマ補正部７ｆは、障害検出タイマ７ｄから障害検出時間を得て、補正が必要な場合は障害検出タイマ７ｄに対してフィードバックする。これにより、既存の機構では解決できない遅延による障害の誤検出を防ぐ。ユーザがタイマ補正部７ｆのパラメータを設定する場合は、ユーザインタフェース７ｈの操作で行うことができる。

２．障害検出
まず、通信障害の検出及び課題について説明する。
図２は、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ）の障害監視メカニズムを示すシーケンス図である。
本装置（例えば、ノードＡ １０ａ）をローカルノード（第１のノード装置）２０とし、リモートノード（第２のノード装置、対向ノード装置）２１（例えば、ノードＢ、ノードＣ）との経路状態を監視する際の一定間隔でのパケット送信とその監視時間について示している。図では、ローカルノード２０における障害監視に関わる通信だけを示しているが、実際には、リモートノード２１でも同様の障害監視を行うため、反対方向でも同様の通信が行なわれる。

リモートノード２１からは、定期的にパケットが送信される。リモートノード２１からのパケット送信間隔（リモート送信間隔）２２は、セッション確立時のネゴシエーションで決定する。パケット送信間隔など、パラメータのネゴシエーション手順はＢＦＤの規格に則ることができるため、ここでは説明を省略する。
ローカルノード２０側では、同じくセッション確立時のネゴシエーションにより決定するパラメータである障害検出時間２３で、リモートノード２１からのパケット受信を監視する。ＢＦＤにおける障害検出時間は、リモートノード２１からのパケット送信間隔２２と障害検出乗数との乗算により決定する。障害検出時間内にパケットを受信した場合は、パケットを受信するごとに障害検出タイマ７ｄをリセットする。図２に示すように、障害検出時間内にパケットを受信している場合は、正常であるとみなす。

図３は、ＢＦＤのパケットロスによる障害発生の一例を示すシーケンス図である。
図は、障害検出乗数が２の場合の例であり、パケットを２個連続で障害検出時間内に受信できなかった場合にタイムアウトになり、障害として検出される。
ＢＦＤの規定により、リモートノード２１はパケットを送信する際の遅延対策として、実際に送信するリモート実送信間隔（３５）は、ネゴシエーションによって決定したリモート送信間隔よりも減少させる。その範囲は、プロトコルの規定により障害検出乗数が１の場合でリモート送信間隔の７５〜９０％、２以上の場合でリモート送信間隔の７５〜１００％である。例えば、リモート実送信間隔は以下の式で求められる。

障害検出乗数が１の場合：
実送信間隔（３５）＝送信間隔（２２）×（７５〜９０％）
障害検出乗数が２以上の場合：
実送信間隔（３５）＝送信間隔（２２）×（７５〜１００％）
なお、送信間隔（２２）に乗ずる値は、パケット送信ごとにランダムに変化させる。
リモートノード２１から送信されるパケット３０を受信したローカルノード２０では、障害検出タイマ７ｄをリセットする（ステップ３３）。この後、リモートノード２１からのパケット３１および３２が何らかの要因でローカルノード１０まで到達しないと、ローカルノード２０の障害検出タイマ７ｄはタイムアウトとなる。すなわち、障害検出時間内にリモートノード２１からパケットが１つも届かず、障害検出タイマ７ｄがリセット（更新）されること無くタイムアウトした場合、ローカルノード２０は、両システム間の通信路で通信障害が発生したものとみなし、これを障害として検出する（ステップ３４）。

図４は、ＢＦＤパケットの通信遅延による障害発生の一例を示すシーケンス図である。
この図も、障害検出乗数は図３と同様に２の場合である。図３との違いは、図３におけるパケット３２に相当するリモートノード２１からのパケット４２が遅延し、障害検出時間経過後にローカルノード２０に到達する例を示している。このように、パケットロスの個数が障害検出乗数の値（この場合２）より少ない１個であっても、遅延４３の大きさによっては障害検出時間内にパケットが２つとも到達しなかったことになるため、障害として検出される（ステップ４４）。
障害検出乗数が小さくなるほど、このような障害の発生頻度（誤検出の数）は、大きくなる。障害検出乗数が１の場合に至っては、通信路自体は生きていて、パケットロスが１つも発生しない場合でも、通信遅延により障害として検出されるケースが起こる。また、リモートノードのリモート実送信間隔３５はリモート送信間隔２２との乗算で与えているため、パケットの送信間隔を短くするほど、許容される遅延時間は短くなる。一般的に、通信遅延時間は送信間隔とは比例しないため、この遅延対策は特にパケット送信間隔が短い場合において十分ではない。

図５は、障害検出を行う処理の一例を示すフローチャートである。
例えば、以下の処理が繰り返し実行される。なお、本フローチャートの処理は、ノードＡ １０ａなどの各ノードにより実行されることができる。ここで示す検出タイマ（７ｄ）は、セッション作成時に開始される障害検出のためのタイマである。
ローカルノード２０は、リモートノード２１との接続性を確認する際には先ず、前回実行時からの経過時間算出し（ステップ５０）、その値を検出タイマ７ｄに加えて、検出タイマ７ｄの値を更新し、パケットを受信していない時間を記録する（ステップ５１）。なお、タイマの処理については適宜の処理でもよい。ローカルノード２０は、更新した検出タイマ７ｄの値と予め決定された障害検出時間を比較し（ステップ５２）、検出タイマ７ｄの値が障害検出時間以上である場合は、リモートノード２１との接続性に障害があることを検出し、経路（ルーティング）制御などを行う上位アプリケーション７２に対して通知を行う（ステップ５３）。一方、ローカルノード２０は、障害検出時間を未だ超過していない場合は（ステップ５０）、リモートノードからのパケットを受信しているかどうか確認を行う（ステップ５４）。パケットを受信している場合には、障害は発生していないものとみなして検出タイマ７ｄをリセットする（ステップ５５）。パケットを受信していない場合は処理を終了し、次回の処理を待つ。
図５に示す処理は、例えば、一定時間間隔およびリモートノードからのパケット受信を契機に繰り返し実行する。

３．障害検出時間の設定
図６は、本実施の形態の障害検出時間補正方式を説明するためのグラフである。
これは図４で示したステップ４２のように、パケットはロスしていないが送信遅延が発生することによって、誤って障害を検出してしまう課題を回避するための障害検出時間の補正方式である。
リモートノードからのパケットが連続でロスした場合に、障害を検出するまでの時間６０は、従来の方法ではリモート送信間隔２２×障害検出乗数である。また、実際にリモートノードが障害検出乗数と等しい個数のパケットを送信するのに必要なリモート実送信時間６１は、リモート実送信間隔３５×障害検出乗数である。なお、リモート実送信間隔３５は、上述のようにリモート送信間隔に７５〜１００％を乗じたものであり、リモート送信間隔よりも短い。
本方式では、必要猶予時間６２を設定し、リモートノードからのパケット通信の所要時間に必要猶予時間６２までの遅延が発生しても、誤って障害を検出しないような必要障害検出時間６３を「リモート実送信時間６１＋必要猶予時間６２」で与える。新たな（補正後の）障害検出時間６４は、障害検出時間６０と必要障害検出時間６３のうち長いものを採用する。

リモート実送信間隔３５については、ローカルノードではリモートノードが規定範囲のどの割合で送信間隔をその都度減少させるかは判らない。そこで、リモート実送信時間６１を求める際に用いるリモート実送信間隔３５を、ローカルノードでは次のようにして求める。障害検出乗数が１の場合は、リモートノードから通知されるリモート送信間隔２２の９０％をリモート実送信間隔の想定値とし、障害検出乗数が２以上の場合は、リモート送信間隔２２の１００％をリモート実送信間隔の想定値とする。つまり、遅延対策として導入されている規定の効果が最も弱くなる場合を想定して補正演算を行う。なお、これ以外にも適宜の想定値を用いてもよい。
上述の必要猶予時間の算出方法については図１１以降の図面を参照して後に述べる。
図８は、本実施の形態の必要猶予時間を適用した障害検出時間設定のフローチャートである。
本フローに先立ち、ノード装置は、対向ノード装置とのネゴシエーションにより、リモート送信間隔、障害検出乗数が予め得られており、適宜メモリに記憶されている。さらに、リモート送信間隔に基づき、リモート実送信間隔の想定値が予め求められていてもよい。
タイマ処理機構７８（例えば、タイマ補正部７ｆ）は、最初にプロトコル規定に基づいて、障害検出時間（第１の障害検出時間）を「リモート送信間隔×障害検出乗数」で算出する（ステップ８０）。次に、タイマ処理機構７８は、必要障害検出時間（第２の障害検出時間）６３を「リモート実送信間隔×障害検出乗数＋必要猶予時間」で算出する（ステップ８１）。必要猶予時間は、予め設定されていてもよいし、後述する処理により求められた値を用いることもできる。タイマ処理機構７８は、ステップ８０で算出した従来の障害検出時間と、ステップ８１で算出した必要障害検出時間を比較する（ステップ８２）。タイマ処理機構７８は、障害検出時間が必要障害検出時間に満たない場合は（ステップ８２）、障害検出時間として必要障害検出時間の値を設定する（ステップ８３）。タイマ処理機構７８は、更新した障害検出時間は（ステップ８２）、システムの記憶領域（メモリ７６または記憶装置７７）に書き込む（ステップ８４）。

ユーザが構成定義を変更する場合や、後述するように必要猶予時間が変化した場合など、パラメータの変更が行われた場合は図８の処理を再度行うことによって必要猶予時間を適したものへと更新するようにしてもよい。
補正の例として、補正前の障害検出時間６０に対して、リモート実送信間隔３５がリモート送信間隔２２の９０％となるような場合を考える。必要猶予時間として１０ミリ秒を確保する場合、補正が必要となるのは障害検出時間が１００ミリ秒以下の場合である。判り易い例としては、障害検出乗数が１でリモート送信間隔２２が５０ミリ秒（すなわち障害検出時間は５０ミリ秒）の場合、許容される遅延時間は５ミリ秒となるため、必要猶予時間の１０ミリ秒を下回ることになる。本実施の形態を適用すると、補正前の障害検出時間６０は５０ミリ秒（ステップ８０）、必要障害検出時間は５５ミリ秒（ステップ８１）であり、適用する障害検出時間は５５ミリ秒となる（ステップ８２、８３）ため、リモート実送信間隔４５ミリ秒との差分１０ミリ秒が遅延許容時間として確保されるようになる。
図９は、本実施の形態の障害検出処理の一例を示すフローチャートである。
障害の監視を行う際は、図５で示した障害検出フローに、ステップ９０として、図８の手順で算出する補正後の障害検出時間を読み込む手順を加える。他の処理は、図５と同様であるので、説明を省略する。なお、障害検出時間を、システム起動時などに定めて固定の値を用いる場合は、図５のフローを用いてもよい。ここでは、障害検出時間は適宜更新されることができる。

４．必要猶予時間の決定
以下に、必要猶予時間の決定方法として、本実施の形態で提案する第１〜第４の４つの方法について説明する。各方法の説明に先立ち、第２〜第４の３つ方法で用いる必要猶予時間検索テーブル７６０について説明する。
図１０に、必要猶予時間検索テーブル７６０、７６１の構成例を示す。
必要猶予時間検索テーブル７６０、７６１は、例えば、２つのキー情報ａ、ｂに対応して、必要猶予時間が予め記憶される。
必要猶予時間は、二種類のキー情報（１００、１０２）により検索する。キー情報として何を用いるかは、各方式の説明で具体的に述べる。テーブルの値は、システム管理者などが運用に先立ち設定することができる。なお、各カラム値の相関は次のとおりとなる。インデックスを決定する値（複数の第１の閾値）であるＡ１〜Ａｎ（１０１）が大きくなるにつれ、必要猶予時間も大きくなる。同様に、インデックスを決定する値（複数の第２の閾値）であるＢ１〜Ｂｍ（１０３）が大きくなると、必要猶予時間も大きくなる。
第１の必要猶予時間の決定方法は、固定値として予め与える方式である。ユーザ（管理者）がコンフィグの設定などを通じて指定し、コンフィグの設定変更が発生しない限り、ノードシステム動作中には変化しない。

第２の決定方法は、ローカルノードの負荷（処理負荷）を測定することにより、装置内負荷による遅延に対する猶予時間を与える方法である。ここで、必要猶予時間検索テーブル７６０のキー情報ａ、ｂは、負荷の平均及び分散である。また、ノードは、例えば、障害検知プロトコル部７１などに、負荷測定部を有してもよい。
図１１は、本実施の形態の自装置の負荷を用いて必要猶予時間を算出する方法の一例を示すフローチャートである。図１１に示した以下の一連の処理は、例えば、タイマ補正部７ｆで行う。
ローカルノード２０は、タイマ処理機構７８のような周期的に動作する処理部分の実際の実行周期と設定された周期の差分や、ＣＰＵ負荷などの自装置における負荷を測定し（ステップ１１０）、その値の平均や分散などの時間軸に対する変化を算出する（ステップ１１１）。ローカルノード２０は、図１０に示すようなテーブル７６０を参照して、対応する必要猶予時間を求める（ステップ１１２）。その際のキー情報（１００、１０２）は、ステップ１１１で求めた負荷の平均および分散を用いる。必要猶予時間が過去の値（例えば、前回求めた値）と変化した場合（ステップ１１３）は、図８に示した処理を行って障害検出時間を再計算する（ステップ１１４）。この時、ステップ８１で用いる必要猶予時間は、ステップ１１２で算出された値を用いる。ローカルノード２０は、求めた負荷の平均、分散、障害検出時間を適宜メモリ等に記憶してもよい。

第３の必要猶予時間の決定方法は、リモートノード２１からのパケット受信間隔（遅延ゆらぎ）を測定することにより、リモートノード２１および通信路で発生する遅延を推測して、それら対する猶予時間を与える方法である。ここで、必要猶予時間検索テーブル７６０のキー情報ａ、ｂは、例えば、パケットの受信間隔の平均及び分散である。また、ノードは、例えば、障害検知プロトコル部７１などに、受信間隔測定部を有してもよい。
図１２は、本実施の形態の遅延ゆらぎ測定方式を用いて必要猶予時間を算出する方法の一例を示すフローチャートである。図１２に示した以下の一連の処理は、例えばタイマ補正部７ｆで行う。
ローカルノード２０は、リモートノード２１からのパケットを受信した際に、前回のパケット受信から経過した時間間隔を算出し（ステップ１２０）、その値の平均や分散などの時間軸に対する変化（遅延ゆらぎ）を算出する（ステップ１２１）。必要猶予時間は、図１０に示すようなテーブル７６０を参照して求める（ステップ１２２）。その際のキー情報（１００、１０２）は、ステップ１２１で求めた受信間隔の平均や分散の値を用いる。必要猶予時間が変化した場合（ステップ１２３）は、図８に示した処理を行って障害検出時間を再計算する（ステップ１２４）。この時、ステップ８１で用いる必要猶予時間は、ステップ１２２で算出された値を用いる。ローカルノード２０は、求めた受信間隔の平均、分散、障害検出時間を適宜メモリ等に記憶してもよい。
上記第２及び第３の方法で平均値や分散値を分布を用いて解析することにより、それらの負荷、遅延の発生確率に基づいた必要猶予時間の決定を行うことができる。

第４の必要猶予時間の決定方法は、管理サーバが決定する方法である。以下、本方式について説明する。
図１３は、本実施の形態の管理サーバを含む通信障害検出システムの一構成例を示す図である。
管理サーバ１３０は、各ノード１３１、１３２、１３３とネットワークを介して接続されている（１３４、１３５、１３６）。また、各ノード１３１、１３２、１３３は、ネットワークを介して相互に接続性の監視を行う（１３７、１３８、１３９）。各ノード１３１、１３２、１３３は、それぞれ、図１のノード１０ａ、１０ｂ、１０ｃに対応する。管理サーバ１３０は、各ノードの接続状態の情報を保持している。各ノードは、他ノードに対して接続を試みる前に、管理サーバ１３０に対して必要猶予時間を要求する。管理サーバ１３０は、要求に応じて全ノードの必要猶予時間を算出し、必要猶予時間の変化のあるノードに対して通知する。管理サーバ１３０を用いることにより、各ノードの接続負荷を考慮した必要猶予時間の設定を行うことが出来る。

図１５は、本実施の形態の必要猶予時間算出機能を有する管理サーバ１３０の一構成例を示した装置ブロック図である。
管理サーバ１３０は、例えば、ユーザインタフェース１５１と、管理機構１５０と、ネットワークＩ／Ｆ１５４と、メモリ１５５と、記憶装置１５６と、ＣＰＵ１５ｄとを有する。メモリ１５５は、例えば、必要猶予時間検索テーブル７６１が記憶される。ここで、必要猶予時間検索テーブル７６１のキー情報ａ、ｂは、各ノードを装置のセッション数である。
管理機構１５０は、ユーザからの要求を受け付けるユーザインタフェースプログラム１５１からの設定により、必要猶予時間算出用のテーブルの値を得て、テーブル７６１に予め設定する。下位にはＴＣＰ／ＵＤＰ層１５２、ＩＰ ｖ４／ｖ６層１５３が存在し、ネットワークインタフェース１５４を介在してノードシステムとのパケット送受信を行う。各ノード装置の情報はメモリ１５５や記憶装置１５６に記録する。
本実施の形態では、管理機構１５０は、タイマ処理機構１５７と送信機構１５８と受信機構１５９を有する。タイマ処理機構１５７は、必要猶予時間算出部１５ｂを有する。受信機構１５９は、受信処理部１５ａによってノード装置からの要求を受け取ると、必要猶予時間算出部１５ｂに通知する。必要猶予時間算出部１５ｂは、必要猶予時間を算出する。算出した値は、送信機構１５８内の送信処理部１５ｄにより、通知先のノード装置に対してパケットを送信される。

図１４は、本実施の形態の管理サーバ１３０による必要猶予時間の決定及び通知方式の一例を示すシーケンス図である。
ノードＡ（１３１）は、例えば、ノードＢ（１３２）との間に新たなセッションを確立する前に、自装置でのセッション数を含むセッション数通知（１４０）と、ノードＢとの間で確立する通信障害監視セッションで用いる必要猶予時間要求（１４１）を、管理サーバ（１３０）に送る。なお、ノードは、セッション数を例えばセッション情報管理部７ｉなどで管理している。管理サーバ１３０は、受信したノードのセッション数をノード毎に記憶する。管理サーバ１３０は、ノードＢに関する情報（例えば、セッション情報）を未取得の場合、または、ノードＢの最新の情報を取得する必要がある場合、ノードＢのセッション数を取得する（１４２、１４３）。最新の情報を取得する必要がある場合とは、例えば、ノードＢから所定時間以上の間セッション数の通知を受信していない場合などがある。管理サーバ１３０は、ノードＡおよびノードＢに対して、その必要猶予時間を算出する（ステップ１４４）。必要猶予時間は、各ノードＡ、Ｂのセッション数をキー情報（１００、１０２）として、図１０に示すようなテーブル７６１を参照して、対応する必要猶予時間を求める。ノードＡもしくはＢとセッションを確立している全てのノードについても、同様に必要猶予時間を求めてもよい。

管理サーバ１３０は、必要猶予時間をノードに送信する。ステップ１４４で求めた必要猶予時間は、新規セッション分だけでなく、既存セッションでも値が変化した場合は、管理サーバ１３０は、対象ノードに対して通知を行う（１４５）。ここで、対象ノードとは、例えば、ノードＡ及び／又はノードＢと接続されたノード（例えば、ノードＣ）である。各ノードは、通知された必要猶予時間を用いて障害検出時間を算出する（１４６）。
各ノードは、自身の持つセッション数が変化した場合は同様に管理サーバに対して通知を行い、新たな必要猶予時間を得るようにしてもよい。また、各ノードは、定期的に、セッション数を管理サーバ１３０に送信し、必要猶予時間を得るようにしてもよい。管理サーバ１３０は、セッション数の変化したノード（例えば、ノードＡ）と既にセッションを確立しているノード（例えば、ノードＢ）に対しても必要猶予時間が変化する場合は新たな必要猶予時間を通知する。

図１６は、本実施の形態の管理サーバ１３０における必要猶予時間算出方法の一例を示すフローチャートである。
管理サーバ１３０は、ノードＡがノードＢに対してセッションを確立する際に送信される、セッション数の通知と、ノードＢとのセッションにおける必要猶予時間の要求を受信する（ステップ１６０）。管理サーバ１３０は、ノードＢのセッション数の情報を保持しているか確認し（ステップ１６１）、存在する場合はステップ１６４に移る。一方、存在しない場合はノードＢに対してセッション数を要求する（ステップ１６２）。ノードＢからセッション数を通知されたならば（ステップ１６３）、ステップ１６４に移る。
ステップ１６４では、管理サーバ１３０は、ノードＡとノードＢに関連する全てのノード間で用いる必要猶予時間を算出する（ステップ１６４）。管理サーバ１３０は、求められた必要猶予時間を記憶する（ステップ１６５）。管理サーバ１３０は、必要猶予時間が変化したノードに対して、必要猶予時間を通知する（ステップ１６６）。必要猶予時間を受け取ったノードは、新たな必要猶予時間を用いて図８の処理を行い、障害検出時間の更新を行う。

管理サーバ１３０は、タイムアウト時間未満（ステップ１６７）で、ノードＢからセッション数の通知が得られない場合は、セッション数の要求を再送する（ステップ１６２）。タイムアウト時間以上応答がない場合は（ステップ１６７）、管理サーバ１３０は、必要猶予時間の算出を失敗としてノードＡに通知する（ステップ１６８）。一方、再送を行わない場合はタイムアウト時間が経過するまで応答を待ち、タイムアウト後にステップ１６８へ移行する。ノードＡは補正値算出の失敗を受け取った際、ノードＢに問題があると判断して、接続を行わなくてもよい。なお、ここでは必要猶予時間を求めるキーにセッション数のみを用いているが、セッションの送信間隔や受信間隔などの値を組み合わせてキーとしてもよい。
以上で説明した必要猶予時間を決定する４つの方式は、それぞれ組み合わせて用いても構わない。例えば、上述の第２の方法と第３の方法の双方を実行し、得られるそれぞれの
障害検出時間のうち、値が大きいほうを実運用で用いるものとして決定するようにしてもよい。また、他の方法を同様に組み合わせてもよい。また、第２、第３の方法を管理サーバを用いて行ってもよいし、第４の方法を管理サーバを備えずに、各ノード装置がセッション数情報をやりとりして、各ノード装置で上記管理サーバの処理を行うようにしてもよい。
以上のように本実施の形態では、ノード間における通信障害監視において、必要猶予時間を導入して障害検出時間の補正を行うことにより、通信路に遅延は発生しているが経路に問題が無い場合において、障害検出時間の増加を抑えつつ、遅延を誤って障害として検出することを避けることが可能になる。

５．概略
５．１ ネットワークシステム
本発明におけるネットワークシステムは、例えば、複数のノード装置により構成されるネットワークシステムであって、
前記ノード装置は通信路の障害を検知する障害検出プロトコルを備え、
前記障害検出プロトコルは、
対向ノードに対して互いにパケットを送信し、
対向ノードから障害検出時間が経過してもパケットを受信しない場合に障害を検出し、
前記障害検出時間は、
対向ノードとのネゴシエーションによって得る値を規準とする障害検出プロトコルを備えたノード装置により構成されるネットワークシステムにおいて、
前記基準値に対して障害誤検出を防ぐための補正を加え、実運用に適用する障害検出時間を決定する
障害検出時間補正機能を有する。

（固定方式）
上述のネットワークシステムにおける前記障害検出時間の補正は、装置構成定義などを通じて設定値として与える必要猶予時間を、対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。
（負荷測定方式）
上述のネットワークシステムにおける前記障害検出時間の補正は、ノード装置の処理負荷を測定し、前記ノード装置内の負荷から必要猶予時間を決定し、前期必要猶予時間を対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。

（受信パケット測定方式）
上述のネットワークシステムにおける前記障害検出時間の補正は、対向ノード装置からの実パケット受信間隔を測定し、受信間隔の平均および分散から必要猶予時間を決定し、前期必要猶予時間を対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。
（管理サーバ方式）
本実施の形態における他のネットワークシステムは、例えば、通信路の障害を検知する障害検出プロトコルを備えた複数のノード装置と管理サーバにより構成されるネットワークシステムであって、
ノード装置Ａは対向ノード装置Ｂと接続を行う際に、
ノード装置Ａと対向ノード装置Ｂで接続を行う旨を管理サーバに通知し、
前記接続通知を受信した管理サーバは、
各ノード装置の接続負荷情報を基に障害誤検出を防ぐための必要猶予時間を求めてノード装置に通知を行い、
前記ノード装置は、管理サーバから通知された前記必要猶予時間を用いて障害検出時間の補正を行う
障害検出時間補正機能を有する。

（管理サーバにおける必要猶予時間算出方式）
上述のネットワークシステムにおいて前記管理サーバが求める必要猶予時間は、ローカルノードのセッション数およびリモートノードのセッション数をキー情報として検索したテーブルの値を用いることを特徴のひとつとする。
（管理サーバにおけるテーブルの設定方式）
上述のネットワークシステムにおける前記テーブルの値は、サーバ管理者の設定により決定することを特徴のひとつとする。
（必要猶予時間の通知対象）
上述のネットワークシステムにおいて前記管理サーバが必要猶予時間を通知する対象は、ノードＡおよびノード装置Ｂと、両ノード装置と接続状態にあるノード装置であることを特徴のひとつとする。
（ＢＦＤ）
上述のネットワークシステムにおける前記障害検知プロトコルとしてＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ）を用い、必要猶予時間を加味した障害検出時間を利用することを特徴のひとつとする。

５．２ ノード装置
本実施の形態におけるノード装置は、例えば、通信路の障害を検知する障害検出プロトコルを備えたノード装置であって、
前記障害検出プロトコルは、
対向ノードに対してパケットを送信し、
対向ノードから障害検出時間が経過してもパケットを受信しない場合に障害を検出し、
前記障害検出時間は、
対向ノードとのネゴシエーションによって得る値を規準とする障害検出プロトコルを備えたノード装置において、
前記基準値に対して障害誤検出を防ぐための補正を加え、実運用に適用する障害検出時間を決定する
障害検出時間補正機能を有する。

（固定方式）
上述のノード装置における前記障害検出時間の補正は、装置構成定義などを通じて設定値として与える必要猶予時間を、対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。
（負荷測定方式）
上述のノード装置における前記障害検出時間の補正は、ノード装置の処理負荷を測定し、前記ノード装置内の負荷から必要猶予時間を決定し、前期必要猶予時間を対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。
（受信パケット測定方式）
上述のノード装置における前記障害検出時間の補正は、対向ノード装置からの実パケット受信間隔を測定し、受信間隔の平均および分散から必要猶予時間を決定し、前期必要猶予時間を対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。

（管理サーバ方式）
本実施の形態における他のノード装置は、例えば、通信路の障害を検知する障害検出プロトコルを備え、管理サーバとネットワークで接続されたノード装置であって、
ノード装置Ａは対向ノード装置Ｂと接続を行う際に、
ノード装置Ａと対向ノード装置Ｂで接続を行う旨を管理サーバに通知し、
管理サーバから通知された必要猶予時間を用いて障害検出時間の補正を行う
障害検出時間補正機能を有する。
（ＢＦＤ）
上述のノード装置における前記障害検知プロトコルとしてＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ）を用い、必要猶予時間を加味した障害検出時間を利用することを特徴のひとつとする。

５．３ 管理サーバ
本実施の形態における管理サーバは、例えば、通信路の障害を検知する障害検出プロトコルを備えた複数のノード装置と接続された管理サーバであって、
前記ノード装置から対向ノード装置との間で障害監視を開始する通知を受信した管理サーバは、
各ノード装置の接続負荷情報を基に障害誤検出を防ぐための必要猶予時間を求めてノード装置に通知を行う。
（管理サーバにおける必要猶予時間算出方式）
前記管理サーバが求める必要猶予時間は、ローカルノードのセッション数およびローカルノードのセッション数をキー情報として検索したテーブルの値を用いることを特徴のひとつとする。
（管理サーバにおけるテーブルの設定方式）
上記管理サーバにおける前記テーブルの値は、サーバ管理者の設定により決定することを特徴のひとつとする。

（必要猶予時間の通知対象）
前記管理サーバが必要猶予時間を通知する対象は、
ノードＡおよびノード装置Ｂと、両ノード装置と接続状態にあるノード装置であることを特徴のひとつとする。
５．４ 障害検出方法
本実施の形態における障害検出方式（障害検出方法）は、例えば、ネットワークで接続されたノード装置間の通信障害を検出する障害検出方式であって、
前記障害検出方式は、
対向ノードに対して互いにパケットを送信し、
対向ノードから障害検出時間が経過してもパケットを受信しない場合に障害を検出し、
前記障害検出時間は、
対向ノードとのネゴシエーションによって得る値を規準とする障害検出方式において、
前記基準値に対して障害誤検出を防ぐための補正を加え、実運用に適用する障害検出時間を決定する
障害検出時間補正機能を有する。

（固定方式）
上述の障害検出方式における前記障害検出時間の補正は、
装置構成定義などを通じて設定値として与える必要猶予時間を、対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。
（負荷測定方式）
上述の障害検出方式における前記障害検出時間の補正は、ノード装置の処理負荷を測定し、前記ノード装置内の負荷から必要猶予時間を決定し、前期必要猶予時間を対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。

（受信パケット測定方式）
上述の障害検出方式における前記障害検出時間の補正は、対向ノード装置からの実パケット受信間隔を測定し、受信間隔の平均および分散から必要猶予時間を決定し、前期必要猶予時間を対向装置からのパケット送信間隔であるリモート送信時間に加えて必要障害検出時間とし、補正前の障害検出時間の基準値と前記必要障害検出時間とを比較し、大きい方の値を実運用で適用する障害検出時間とすることを特徴のひとつとする。
（管理サーバ方式）
本実施の形態における他の障害検出方式は、例えば、管理サーバとネットワークで接続されたノード装置において通信路の障害を検出する障害検出方式であって、
障害監視を開始する際には、対向ノード装置と接続を行う旨を管理サーバに通知し、
前記管理サーバから障害誤検出を防ぐための必要猶予時間の通知を受け、
前記必要猶予時間を用いて障害検出時間の補正を行う
障害検出時間補正機能を有する。

（管理サーバにおける必要猶予時間算出方式）
上述の障害検出方式における前記管理サーバが求める必要猶予時間は、ローカルノードのセッション数およびリモートノードのセッション数をキー情報として検索したテーブルの値を用いることを特徴のひとつとする。
（管理サーバにおけるテーブルの設定方式）
上述の障害検出方式における前記テーブルの値は、使用者の設定により決定することを特徴のひとつとする。
（必要猶予時間の通知対象）
上述の障害検出方式における前記管理サーバが必要猶予時間を通知する対象は、
ノードＡおよびノード装置Ｂと、両ノード装置と接続状態にあるノード装置であることを特徴のひとつとする。
（ＢＦＤ）
上述の障害検出方式における障害検知プロトコルとしてＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ）を用い、必要猶予時間を加味した障害検出時間を利用することを特徴のひとつとする。

本発明の障害検出時間補正方式は、高速な通信障害検出を必要とするルータ間の通信路監視のみならず、サーバなど通信タイムアウトによる障害監視を行う通信機器全般において、通信遅延による障害誤検出を回避する手法として利用できる。また、本発明は、例えば、通信障害検出システム、通信障害検出機能を有するノード装置、または通信遅延による経路障害の誤検出を防ぐ障害検出時間の補正に関する産業に利用可能である。

本実施の形態の通信障害検出システムの一構成例を示す図。 ＢＦＤの障害監視メカニズムを示すシーケンス図。 ＢＦＤのパケットロスによる障害発生の一例を示すシーケンス図。 ＢＦＤの通信遅延による障害発生の一例を示すシーケンス図。 障害検出を行う処理の一例を示すフローチャート。 本実施の形態の障害検出時間補正方式を示すグラフ。 本実施の形態の通信障害検出機能を有するノード装置の一構成例を示した装置ブロック図。 本実施の形態の必要猶予時間の適用方式の一例を示すフローチャート。 本実施の形態の障害検出処理の一例を示すフローチャート。 本実施の形態の必要猶予時間検索テーブルの一例を示す図。 本実施の形態の自装置の負荷を用いて必要猶予時間を算出する方法の一例を示すフローチャート。 本実施の形態の遅延ゆらぎ測定方式を用いて必要猶予時間を算出する方法の一例を示すフローチャート。 本実施の形態の管理サーバを含む通信障害検出システムの一構成例を示す図。 本実施の形態の管理サーバによる必要猶予時間の通知方式の一例を示すシーケンス図。 本実施の形態の必要猶予時間算出機能を有する管理サーバの一構成例を示した装置ブロック図。 本実施の形態の管理サーバによる必要猶予時間算出方法の一例を示すフローチャート。

符号の説明

１０ａ〜１０ｅ ノード装置
６０ 障害検出時間（補正前）
６１ リモート実送信時間
６２ 必要障害検出時間
６３ 必要猶予時間
６４ 障害検出時間（補正後）
７０ ネットワークノード部
７１ 障害検知プロトコル
７２ 上位ＡＰ
７３ ＵＤＰ層
７４ ＩＰ層
７５ ネットワークＩ／Ｆ
７６ メモリ
７７ 記憶装置
７８ タイマ処理機構
７９ 送信機構
７ａ 受信機構
７ｂ 周期送信タイマ
７ｃ 送信処理部
７ｄ 障害検出タイマ
７ｅ 受信処理部
７ｆ タイマ補正部
７ｇ ＣＰＵ
１３０ 管理サーバ
１５０ 管理機構
１５１ ユーザインタフェース
１５２ ＴＣＰ／ＵＤＰ層
１５３ ＩＰ層
１５４ ネットワークＩ／Ｆ
１５５ メモリ
１５６ 記憶装置
１５７ タイマ処理機構
１５８ 送信機構
１５９ 受信機構
１５ａ 受信処理部
１５ｂ 必要猶予時間算出部
１５ｃ 送信処理部
１５ｄ ＣＰＵ

Claims (18)

1. 複数のノード装置を備えたネットワークシステムであって、
   前記ノード装置はそれぞれ、対向するノード装置との経路の障害を検出する障害検出部を備え、
   第１のノード装置の前記障害検出部は、
   対向する第２のノード装置とネゴシエーションによって、障害検出のためのパケットの送信間隔を定め、
   前記第２のノード装置から送信される障害検出のためのパケットを受信し、及び、
   決定された障害検出時間が経過しても前記パケットを前記第２のノード装置から受信しないことにより、該第２のノード装置との経路の障害を検出し、
   前記障害検出時間は、前記第１のノード装置の前記障害検出部が、
   前記第２のノード装置とのネゴシエーションによって定められた前記パケットの送信間隔に基づく第１の障害検出時間を求め、
   予め設定された又は予め求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて、第２の障害検出時間を求め、
   第１の障害検出時間と第２の障害検出時間とを比較し、大きい方の値が実運用で適用する前記障害検出時間として決定される
   前記ネットワークシステム。
2. 前記第２の障害検出時間は、
   前記障害検出部が、
   設定値として予め与えられる猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて、第２の障害検出時間とすることを特徴とする請求項１に記載のネットワークシステム。
3. 前記第２の障害検出時間は、
   前記障害検出部が、
   自ノード装置の負荷を測定し、
   測定された自ノード装置内の負荷に基づき猶予時間を求め、
   求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて第２の障害検出時間とすることを特徴とする請求項１に記載のネットワークシステム。
4. 前記ノード装置は、自ノード装置の負荷の平均及び分散に対応して猶予時間が予め記憶されたテーブル
   をさらに備え、
   前記障害検出部は、
   自ノード装置のＣＰＵ負荷、及び、周期的に動作する処理部分の実際の実行周期と設定された周期との差のいずれかを含む負荷の平均及び分散を測定し、
   測定された負荷の平均及び分散に基づき前記テーブルを参照して、対応する猶予時間を求める請求項３に記載のネットワークシステム。
5. 前記障害検出部は、
   自ノード装置内の負荷を定期的に又は不定期に複数回測定し、
   測定された負荷に基づき求められた猶予時間が、過去に求められた猶予時間から変化している場合、求められた猶予時間に基づき第２の障害検出時間を再度求め、及び、前記障害検出時間を再度決定する請求項３に記載のネットワークシステム。
6. 前記第２の障害検出時間は、
   前記障害検出部が、
   対向ノード装置からの前記パケットの受信間隔を測定し、受信間隔の平均及び分散を測定し、
   測定された受信間隔の平均および分散に基づき猶予時間を求め、
   求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて第２の障害検出時間とすることを特徴とする請求項１に記載のネットワークシステム。
7. 前記ノード装置は、パケットの受信間隔の平均及び分散に対応して猶予時間が予め記憶されたテーブル
   をさらに備え、
   前記障害検出部は、
   測定された受信間隔の平均及び分散に基づき前記テーブルを参照して、対応する猶予時間を決定する請求項６に記載のネットワークシステム。
8. 前記障害検出部は、
   対向ノード装置からの前記パケットの受信間隔の平均及び分散を、定期的に又は不定期に複数回測定し、
   測定された受信間隔の平均及び分散に基づく猶予時間が、過去に求められた猶予時間から変化している場合、求められた猶予時間に基づき第２の障害検出時間を再度求め、及び、前記障害検出時間を再度決定する請求項６に記載のネットワークシステム。
9. 前記ノード装置のそれぞれと通信する管理サーバ
   をさらに備え、
   前記第１のノード装置は、対向する前記第２のノード装置と接続を行う際に、前記第１のノード装置と対向する前記第２のノード装置で接続を行う旨を前記管理サーバに通知し、
   前記第１及び第２のノード装置は、自装置の接続負荷情報を前記管理サーバに送信し、
   前記通知を受信した管理サーバは、
   前記第１及び第２のノード装置から受信された接続負荷情報に基づき猶予時間を求めて、前記第１及び第２のノード装置に猶予時間を送信し、
   前記第１及び第２のノード装置は、前記管理サーバから受信した猶予時間を用いて前記第２の障害検出時間を求めることを特徴とする請求項１に記載のネットワークシステム。
10. 前記接続負荷情報は、前記第１又は第２のノード装置のセッション数であり、
    前記管理サーバは、
    前記第１のノード装置のセッション数と前記第２のノード装置のセッション数に対応して、猶予時間が予め記憶されたテーブルを有し、
    受信された前記第１のノード装置のセッション数及び前記第２のノード装置のセッション数に基づき前記テーブルを検索して対応する猶予時間を取得し、取得された猶予時間を前記第１及び第２のノード装置に送信することを特徴とする請求項９に記載のネットワークシステム。
11. 前記障害検出部は、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ）プロトコルを用い、及び、猶予時間を加味した障害検出時間を用いて障害を検出することを特徴とする請求項１乃至１０のいずれかに記載のネットワークシステム。
12. 複数のノード装置を備えたネットワークシステムにおける前記ノード装置であって、
    前記ノード装置は、対向ノード装置との経路の障害を検出する障害検出部を備え、
    前記障害検出部は、
    対向ノード装置とネゴシエーションによって、障害検出のためのパケットの送信間隔を定め、
    対向ノード装置から送信される障害検出のためのパケットを受信し、及び、
    決定された障害検出時間が経過しても前記パケットを前記対向ノード装置から受信しないことにより、該対向ノード装置との経路の障害を検出し、
    前記障害検出時間は、前記障害検出部が、
    前記対向ノード装置とのネゴシエーションによって定められた前記パケットの送信間隔に基づく第１の障害検出時間を求め、
    予め設定された又は予め求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて、第２の障害検出時間を求め、
    第１の障害検出時間と第２の障害検出時間とを比較し、大きい方の値が実運用で適用する前記障害検出時間として決定される
    前記ノード装置。
13. 前記第２の障害検出時間は、
    前記障害検出部が、
    設定値として予め与えられる猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて、第２の障害検出時間とすることを特徴とする請求項１２に記載のノード装置。
14. 前記第２の障害検出時間は、
    前記障害検出部が、
    自ノード装置の負荷を測定し、
    測定された自ノード装置内の負荷に基づき猶予時間を求め、
    求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて第２の障害検出時間とすることを特徴とする請求項１２に記載のノード装置。
15. 前記第２の障害検出時間は、
    前記障害検出部が、
    対向ノード装置からの前記パケットの受信間隔を測定し、受信間隔の平均及び分散を測定し、
    測定された受信間隔の平均および分散に基づき猶予時間を求め、
    求められた猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えて第２の障害検出時間とすることを特徴とする請求項１２に記載のノード装置。
16. 前記障害検出部が、
    対向ノード装置と接続を行う際に、対向ノード装置で接続を行う旨を管理サーバに通知し、
    自装置の接続負荷情報を前記管理サーバに送信し、
    該接続負荷情報と、対向ノード装置の接続負荷情報とに基づき管理サーバにより求められ及び送信された猶予時間を受信し、
    受信した猶予時間を用いて前記第２の障害検出時間を求めることを特徴とする請求項１２に記載のノード装置。
17. 前記障害検出部は、ＢＦＤ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｔｅｃｔｉｏｎ）プロトコルを用い、及び、猶予時間を加味した障害検出時間を用いて障害を検出することを特徴とする請求項１２乃至１６のいずれかに記載のノード装置。
18. 第１及び第２のノード装置と管理サーバとを備えたネットワークシステムにおいて、前記第１のノード装置が、前記第２のノード装置とのネゴシエーションによって定められた障害検出のためのパケットの送信間隔に基づく第１の障害検出時間と、管理サーバより受信される猶予時間を、ネゴシエーションによって定められた前記パケットの送信間隔、又は、該送信間隔に基づく前記パケットが実際に送信される実送信間隔の予測値に加えた第２の障害検出時間とのいずれかを障害検出時間として決定し、決定された障害検出時間が経過しても障害検出のための前記パケットを前記第２のノード装置から受信しないことにより、該第２のノード装置との経路の障害を検出する前記ネットワークシステムにおける前記管理サーバであって、
    前記管理サーバは、
    第１のノード装置の接続負荷情報と第２のノード装置の接続負荷情報に対応して、猶予時間が予め記憶されたテーブル
    を有し、
    第１のノード装置と対向する第２のノード装置で接続を行う旨の通知を、該第１のノード装置から受信し、
    第１及び第２のノード装置から、それぞれの装置の接続負荷情報を受信し、
    第１及び第２のノード装置から受信された接続負荷情報に基づき、前記テーブルを検索して対応する猶予時間を求め、前記第１及び第２のノード装置に猶予時間を送信し、
    前記第１及び第２のノード装置により、該猶予時間を用いて前記第２の障害検出時間が求められるための前記管理サーバ。

Images