JP2015527825A - グレースフルリスタート対応のネイバのためにｒｓｖｐｈｅｌｌｏ抑制を使用するシステムおよび方法 - Google Patents

Abstract

アクティブまたはライブ状態であることを示すためにネイバノードとＨＥＬＬＯメッセージを交換するべく第１のモードで動作するために、また、アクティブまたはライブ状態を伝えるためにサービスまたは管理プロトコルに日和見的に依存することによってＨＥＬＬＯメッセージの使用を回避するべく第２のモードで動作するために、ネットワーク内の１つまたは複数のルータあるいはノードを適合するシステム、方法、および装置。

Description

本出願は、２０１２年７月２７日に出願された、係属中の米国仮特許出願第６１／６７６，７９６号「ＳＹＳＴＥＭ，ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＩＭＰＲＯＶＥＤ ＭＰＬＳ ＭＡＮＡＧＥＭＥＮＴ」の利益を主張し、その出願は、引用によりその全体が本明細書に組み込まれている。

本発明は、一般的に通信ネットワークに関し、より具体的には、これに限定されないが、通信ネットワークにおけるネイバノードステータス情報の効率的な検出および処理に関する。

マルチプロトコルラベルスイッチング（ＭＰＬＳ）によって、広範な差別化されたエンドツーエンドサービスの効率的な配信が可能になる。マルチプロトコルラベルスイッチング（ＭＰＬＳ）トラフィックエンジニアリング（ＴＥ）は、帯域幅上の問題、および管理ルールに基づいて、ＭＰＬＳネットワークにわたる効率的なパスを選択するためのメカニズムを提供する。各ラベルスイッチングルータは、現在のネットワークトポロジでＴＥリンク状態データベースを維持する。一旦パスが計算されると、ＴＥは、そのパスに沿って転送状態を維持するために使用される。

ＭＰＬＳリソース予約プロトコル（ＲＳＶＰ）インタードメイントラフィックエンジニアリングラベルスイッチパス（ＴＥ ＬＳＰ）を配備する場合、ＲＳＶＰネイバ関係が確立されるように、最初にＲＳＶＰ対応ルータ間でＲＳＶＰ ＨＥＬＬＯメッセージが交換される。

ノードの障害やリスタートを効率的に検出するために、正しく一定の間隔で、ネイバ単位でＨＥＬＬＯメッセージが交換される。複数のインターフェース／ネイバがあると、交換される必要があるＨＥＬＬＯメッセージの数が増加し、かなりの制御プレーンのオーバーヘッドが生じる。この制御プレーンのオーバーヘッドは、ＨＥＬＬＯメッセージ交換の間隔を減らすことによって減少される。しかしながら、この間隔の増加によって、遅延したフェイルオーバ（ドロップされたトラフィックをもたらす）、または、明らかに障害しているノードが動作を回復した（復元したノードの非効率的な使用をもたらす）ことを認識する際に遅延が生じる場合がある。

いくつかのポイントツーマルチポイント（Ｐ２ＭＰ）ネットワークのコンテキストでは、様々なボーダゲートウェイプロトコル（ＢＧＰ）拡張および手順によって、ネイバノード障害などの上流障害の迅速な検出およびフェイルオーバを提供するために双方向フォワーディング検出（ＢＦＤ）を使用することが可能になる。しかしながら、明らかなネイバノード障害が単にネイバノードのリスタートである場合、上流障害情報の伝搬が、長期間にわたるサービスからのリスタートノードの除去を不要にもたらす場合がある。

ＩＥＴＦ標準ＲＦＣ４７２６ ＩＥＴＦ標準ＲＦＣ５１５１ ＩＥＴＦ ＲＦＣ ３２０９

アクティブまたはライブ状態であることを示すためにネイバノードとｈｅｌｌｏメッセージを交換するべく第１のモードで動作するために、また、アクティブまたはライブ状態を伝えるためにサービスまたは管理プロトコルに日和見的（ｏｐｐｏｒｔｕｎｉｓｔｉｃａｌｌｙ）に依存することによってｈｅｌｌｏメッセージの使用を回避するべく第２のモードで動作するために、ネットワーク内の１つまたは複数のルータあるいはノードを適合するシステム、方法、および装置によって、従来技術における様々な欠陥が対処される。

一実施形態による方法は、リソース予約プロトコル（ＲＳＶＰ）ＨＥＬＬＯメッセージ交換を使用して、１つまたは複数のネイバノードとネイバノード関係を確立するステップと、ネイバノードに対して第１の動作モードで、ネイバノードが障害が発生した状態であることを決定するためにＨＥＬＬＯメッセージを使用するステップと、ネイバノードに対して第２の動作モードで、ネイバノードが障害が発生した状態であることを決定するために双方向フォワーディング検出（ＢＦＤ）メカニズムを使用するステップであって、ネイバノードから受信したＨＥＬＬＯ抑制アクティブ印（ｉｎｄｉｃｉａ）に応答して第２の応答モードに入る、使用するステップとを備える。様々な実施形態では、双方向フォワーディング検出（ＢＦＤ）メカニズムの使用に応答して、１つまたは複数の上流ネイバノードに向かってＨＥＬＬＯ抑制アクティブ印が送信される。

本発明の教示は、添付の図面とともに以下の詳細な説明を考慮することによって容易に理解することができる。

様々な実施形態から利益を受ける、例示的なネットワークを示す図である。 一実施形態による方法の流れ図である。 一実施形態による方法の流れ図である。 本明細書に記載の様々な機能を実行する際の使用に適したコンピュータのハイレベルブロック図である。

理解を容易にするために、可能な場合は、図面に共通する同一の要素を示すために同一の参照番号が使用されている。

様々な実施形態を、アクティブまたはライブ状態であることを示すためにネイバノードとｈｅｌｌｏメッセージを交換するべく第１のモードで動作している、また、アクティブまたはライブ状態を伝えるためにサービスまたは管理プロトコルに日和見的に依存することによってｈｅｌｌｏメッセージの使用を回避するべく第２のモードで動作している、複数のルータまたはノードを含む通信ネットワークのコンテキストにおいて説明する。

有利なことに、様々な実施形態は、インターフェース、データリンク、および／または転送エンジンを含む、２つの転送エンジン間の双方向パスにおける障害を検出するように構成された非常に低いレイテンシメカニズムまたはプロトコルを提供する。メカニズムまたはプロトコルは、一般的に、媒体、データプロトコル、およびルーティングプロトコルとは無関係に動作可能である。

図１は、様々な実施形態から利益を受ける、通信ネットワークアーキテクチャのハイレベルブロック図を示している。具体的には、図１のアーキテクチャ１００は、隣接ＬＳＰ（Ｃｏｎｔｉｇｕｏｕｓ ＬＳＰ）タイプのリソース予約プロトコル（ＲＳＶＰ）インタードメイントラフィックエンジニアリングラベルスイッチパス（ＴＥ ＬＳＰ）をサポートする、マルチプロトコルラベルスイッチング（ＭＰＬＳ）ネットワークを提供する。ネットワークは、本明細書に記載の例示的なプロトコルではなく他のＭＰＬＳ関連プロトコルを使用するために、当業者によって修正されてよい。

アーキテクチャ１００は、ＩＰ／ＭＰＬＳ通信ネットワーク（ＣＮ）１０５と、少なくとも１つのネットワーク管理システム（ＮＭＳ）１２０とを含む。図示されるように、ＮＭＳ１２０は、ＣＮ１０５を形成する複数のルータ１１０を制御するように動作可能である。図示されるように、ＣＮ１０５は、複数のプロバイダエッジ（ＰＥ）ルータ１１０−１から１１０−４、ならびに複数のコアルータ１１０−Ｘ１および１１０−Ｘ２を備える。４つのＰＥルータだけが示されているが、ＣＮ１０５はより多くのＰＥルータを含むことができることが分かるだろう。同様に、２つのコアルータだけが示されているが、ＣＮ１０５はより多くのコアルータを含むことができる。ＣＮ１０５の表示は、この説明のために簡略化されている。

ＮＭＳ１２０は、本明細書に記載の様々な管理機能を実行するために適合されたネットワーク管理システムである。ＮＭＳ１２０は、ＣＮ１０５のノードと通信するように構成されている。また、ＮＭＳ１２０は、他の動作サポートシステム（たとえば、要素管理システム（ＥＭＳ）、トポロジ管理システム（ＴＭＳ）など、ならびにそれらの様々な組合せ）と通信するように構成され得る。

ＮＭＳ１２０は、ネットワークノード、ネットワーク動作センタ（ＮＯＣ）、またはＣＮ１０５およびそれに関連する様々な要素と通信することができる他の任意の位置で実装され得る。ＮＭＳ１２０は、１人または複数のユーザが、様々なネットワーク管理、構成、プロビジョニング、または制御関連機能（たとえば、情報の入力、情報のレビュー、本明細書に記載の様々な方法の実行開始など）を実行することができるようにするために、ユーザインターフェース機能をサポートすることができる。ＮＭＳ１２０の様々な実施形態は、様々な実施形態に関連する本明細書に記載の機能を実行するように構成されている。ＮＭＳ１２０は、図３に関して以下で説明するような、汎用コンピューティングデバイス、または専用コンピューティングデバイスとして実装され得る。

ＮＭＳ１２０および様々なルータ１１０は、ＩＥＴＦ標準ＲＦＣ４７２６およびＩＥＴＦ標準ＲＦＣ５１５１に定義されたものなどの、隣接ＬＳＰタイプのリソース予約プロトコル（ＲＳＶＰ）インタードメイントラフィックエンジニアリングラベルスイッチパス（ＴＥ ＬＳＰ）をサポートするために動作する。

説明のために、それぞれの直接接続されたルータ１１０は、直接接続されているそれぞれの他のルータ１１０とネイバノード関係を確立すると仮定する。したがって、様々なルータ１１０のそれぞれは、それぞれの複数のネイバノードと関連付けられている。たとえば、コアルータ１１０−Ｘ１および１１０−Ｘ２のそれぞれは、相互に接続されていると共に、ＰＥルータ１１０−１から１１０−４のそれぞれとも同様に、接続されているものとして示されている。同様に、ＰＥルータ１１０−１および１１０−２は、相互に接続されていると共に、コアルータ１１０−Ｘ１および１１０−Ｘ２とも同様に、接続されているものとして示されている。

ノードの障害やリスタートを効率的に検出するために、あらかじめ定められた間隔で、ネイバノード間でＨＥＬＬＯメッセージが交換される。あらかじめ定められた間隔内にそのようなメッセージを受信できないことは、メッセージを送信するべきネイバノードの障害を示している。

図１に示されるように、ポイントツーマルチポイント（Ｐ２ＭＰ）トラフィックストリーム（たとえば、ビデオまたは他のデータストリーム）は、プライマリラベルスイッチパス（ＬＳＰ）とセカンダリラベルスイッチパス、すなわちプライマリパスＰとセカンダリパスＳのうちの１つ、または両方を介して、送信元カスタマエッジ（ＣＥ）ルータ１３０−Ｓから宛先ＣＥルータ１３０−Ｄに通信している。プライマリパスＰは、ＰＥ１１０−１を起点として、ＣＮ１０５のコアを横断し、ＰＥ１１０−３で終了する。セカンダリパスＳは、ＰＥ１１０−２を起点として、ＣＮ１０５のコアを横断し、ＰＥ１１０−３で終了する。

したがって、ＰＥ１１０−３は、２つの独立したＰ２ＭＰツリー、すなわち、ルートノードＰＥ１１０−１を起点とするプライマリＬＳＰツリーと、ルートノードＰＥ１１０−２を起点とするセカンダリＬＳＰツリーからの、デュアルホームドリーフノードソーシングトラフィックとして動作する。Ｐ２ＭＰチャネルは、双方向フォワーディング検出（ＢＦＤ）、または、様々なボーダゲートウェイプロトコル（ＢＧＰ）および他の拡張および手順で提供されるものなどの同様のメカニズムを利用する。この方法では、ネイバノード障害などの、上流障害の迅速な検出およびフェイルオーバが提供される。

様々な実施形態では、ルータ１１０のうちの１つまたは複数は、ネイバノード関係を確立して、アクティブまたはライブ状態を示すためにネイバノードとｈｅｌｌｏメッセージを定期的に交換するために、第１の（抑制されていない）動作モードで動作するように構成されている。ＢＦＤメカニズムを含むプロトコルを利用してＬＳＰの確立に応答して、１つまたは複数のルータ１１０は、第２の（抑制された）動作モードで動作するように構成されており、下流ネイバノードのアクティブ／ライブ状態はＢＦＤメカニズムを使用して決定され、ｈｅｌｌｏメッセージ交換機能が部分的に、または完全に抑制される。

本明細書に記載の様々な実施形態は、ネットワーク管理要件、ＢＦＤメカニズムアクティブ化／非アクティブ化などに応答して第１の動作モードと第２の動作モードとの間を日和見的に移動するネイバノードを企図する。

図２は、一実施形態による方法の流れ図である。具体的には、図２は、ＢＦＤメカニズムを含む共通ＬＳＰをサポートするネイバノード間のｈｅｌｌｏメッセージを抑制するための方法２００を示している。方法２００は、通信ネットワーク内の複数のノードのうちのいくつか、またはすべてを使用するように適合されている。したがって、方法２００の機能性は単一のネットワークノードの観点から説明されるが、ネットワークのそれぞれの複数のネットワークノードは、日和見的に適応できるｈｅｌｌｏメッセージ抑制メカニズムを実現するために、この機能性に従って動作することができることが理解されよう。

ステップ２１０で、ネットワークノードまたはルータが、他の直接接続されたノードまたはルータとのネイバノード関係を確立する。すなわち、ネットワーク内のそれぞれのノードは、相互ネイバノード関係を確立するために、直接接続されたノードと対話する。ボックス２１５を参照すると、この関係は、ＲＳＶＰメッセージ交換、および／または他のメッセージ交換を使用して確立することができる。

ステップ２２０で、ネットワークノードが、ｈｅｌｌｏメッセージ抑制が使用されない第１の動作モード、すなわち通常の動作モードに入る。ボックス２２５を参照すると、ネイバノード状態、および／または他の情報を決定するために、ネイバノードとのｈｅｌｌｏメッセージの交換が継続される。さらに、ネットワークノードは、その中でＢＦＤメカニズムが利用されているか否かを決定するために、サポートする様々なパスを監視する。本明細書で述べたように、ＢＦＤを使用して共通パスをサポートするネイバネットワークノードは、ｈｅｌｌｏメッセージ交換を回避できるようにするために、ノードまたはリンク障害を識別するためにＢＦＤメカニズムに依拠する場合がある。

ステップ２３０で、ネットワークノードは、状況が許せば、上流および下流ネイバノードとの第２の動作モード、すなわち抑制された動作モードに入る。これらの状況は、ネイバノード間の共通にサポートされたパス上のアクティブなＢＦＤメカニズム、ならびにｈｅｌｌｏ抑制モードで動作するための両方のノードの機能および要望を含む。ボックス２３５を参照すると、ネイバノード間でｈｅｌｌｏメッセージはもう交換されず、ｈｅｌｌｏメッセージによってノード障害（すなわち、あらかじめ定められた期間内にメッセージが受信されたか否か）はもう決定されない。

ステップ２４０で、状況がこの動作モードを許さない場合、上流または下流ネイバノードとの第２の（抑制された）動作モードを終了する。ボックス２４５を参照すると、（１）ノード制御プレーン障害の検出、（２）リンク障害、（３）ネイバノードグレースフルリスタート、（４）Ｒｅｓｔａｒｔ＿Ｃａｐオブジェクト変更、（５）Ｈｅｌｌｏ抑制無効メッセージ、および／または他の基準／イベントのうちのいずれかに応答して、第２の動作モード、すなわち抑制された動作モードを終了する。第２の動作モードを終了した後、ネットワークノードは、ネイバノードまたはリンクが復元／リスタートすると、第１の動作モードに戻る。

様々な実施形態は、ノードまたはリンク障害情報を提供するために、ＢＦＤメカニズムが存在する上流／下流ネイバノード間のこれらの動作モードを企図する。図１を参照すると、プライマリマルチキャストパスＰに関連付けられるＢＦＤメカニズムのために、ＰＥルータ１１０−１は、コアルータ１１０−Ｘ２に関して、抑制された動作モードに入ることができることが分かる。同様に、ＢＦＤメカニズムに関連付けられるパスが両方のルータに共通するように示されていないので、ＰＥルータ１１０−１は、コアルータ１１０−Ｘ１に関して、抑制された動作モードに入ることができない。

様々な実施形態は、下流ネイバノードからＨＥＬＬＯ抑制アクティブ印を受信するノードが、前記下流ネイバノードに関連付けられる１つまたは複数の上流ネイバノードに向かって対応するＨＥＬＬＯ抑制アクティブ印を送信する動作モードを企図する。関連付けられる上流ノードは、下流ノードとＬＳＰを共有するノードを備え得る。

アクティブまたはライブ状態を伝えるためにＢＦＤなどのサービスまたは管理プロトコルに日和見的に依拠することによって、ｈｅｌｌｏメッセージ交換を維持するために通常割り当てられたリソースを保存することができる。非常に多数のネットワーク要素を備えるネットワークのコンテキスト内で使用されると、この保存は非常に重要なものになる可能性がある。

様々な実施形態は、グレースフルリスタートを経験するネイバノードなどのさらなる状況に対応するために、ノード動作を適合する。具体的には、ネイバノード間でＢＦＤを有効にすることは制御プレーン障害を検出するには十分であるが、様々な実施形態は、ネイバノードグレースフルリスタートに関連付けられる環境、および他の状況に対処するために、上流／下流ネイバノード間にさらなる対話を提供する。このさらなる対話は、Ｈｅｌｌｏ抑制オブジェクトがネイバノード間で通信されるＨＥＬＬＯメッセージ内に含まれる、またはネイバノード間で通信されるＨＥＬＬＯメッセージに関連付けられる、ｈｅｌｌｏ抑制メカニズムを使用して提供される。

したがって、様々な実施形態では、ｈｅｌｌｏ抑制メカニズムは、ＢＦＤメカニズムを含むセッション（たとえば、ＲＳＶＰ ＢＦＤセッション）が確立された後、ネイバノード間で呼び出される。具体的には、様々な実施形態では、ｈｅｌｌｏ抑制メカニズムは、ｈｅｌｌｏ抑制有効／アクティブ、ｈｅｌｌｏ抑制無効／非アクティブ、ｈｅｌｌｏ抑制復元／修正、および／または他の情報をネイバノード間で通信するために、Ｈｅｌｌｏ抑制オブジェクトを利用する。

Ｈｅｌｌｏ抑制オブジェクト
様々な実施形態では、Ｈｅｌｌｏ抑制オブジェクトは、Ｈｅｌｌｏ抑制が有効である場合のみ、ＨＥＬＬＯメッセージ内で搬送される。この説明のために、Ｈｅｌｌｏ抑制オブジェクトのフォーマットは以下のように提供されると仮定する。しかしながら、当業者は、ネイバノード間で関連情報を通信するために、他の、および異なるフォーマットも使用することができることが容易に理解できるだろう。

具体的には、例示的なＨｅｌｌｏ抑制リクエストは１６ビットの長さを有する。Ｈｅｌｌｏ抑制がノード上で有効である場合、Ｈｅｌｌｏ抑制リクエストフィールドは（１）に設定される。Ｈｅｌｌｏ抑制がノード上で有効であるが、ＲＳＶＰ ＢＦＤがダウンしている場合、Ｈｅｌｌｏ抑制リクエストフィールドは（０）に設定される。

同様に、例示的なＨｅｌｌｏ抑制ＡＣＫは１６ビットの長さを有する。Ｈｅｌｌｏ抑制がノード上で有効であり、ネイバノードがＨｅｌｌｏ抑制リクエストを送信する場合、Ｈｅｌｌｏ抑制ＡＣＫフィールドは（１）に設定される。ＢＦＤセッションがダウンしている場合、Ｈｅｌｌｏ抑制ＡＣＫフィールドは（０）に設定されることが分かる。

図３は、一実施形態による方法の流れ図である。具体的には、図３は、ＢＦＤメカニズムを含む共通ＬＳＰをサポートするネイバノードに対してｈｅｌｌｏメッセージ抑制動作モードに入るための方法３００を示している。方法３００は、適応できるｈｅｌｌｏメッセージ抑制メカニズムを提供するために、通信ネットワーク内の複数のノードのうちのいくつかまたはすべてを使用するように適合されている。

この説明のために、第１のノードＲ１は、第２およびネイバノードＲ２からの上流であると仮定する。ノードＲ１およびノードＲ２のそれぞれは、ＲＳＶＰ ＢＦＤおよびＨＥＬＬＯメッセージが有効である、ＩＰ−ＭＰＬＳクラウド内のＭＰＬＳ対応ルータを備える。図１を参照すると、第１のノードＲ１および第２のノードＲ２は、例示的に、ＰＥルータ１１０−１およびコアルータ１１０−Ｘ２をそれぞれ備えることができる。

ネイバ間にＭＰＬＳ ＬＳＰトンネルを確立した後、ＲＳＶＰネイバノード状態はアクティブであり、ノードはＨＥＬＬＯメッセージの交換を開始する。

様々な実施形態では、Ｈｅｌｌｏ抑制動作モードに入ることは、以下で様々なステップに関して説明するように、２つのネイバ間の３ウェイハンドシェイク手順を含む。

ステップ３１０で、上流ノードＲ１などのネットワーク要素が、ＲＳＶＰ ＢＦＤがアップ／アクティブか否か、およびＨｅｌｌｏ抑制が有効か否かを決定する。両方の状況が当てはまる場合、上流ノードＲ１が下流ノードＲ２に向かってＨＥＬＬＯ抑制リクエスト（ＲＥＱ）メッセージを送信する。ボックス３１５を参照すると、ｈｅｌｌｏ抑制ＲＥＱメッセージは、（１）に設定されたリクエストフィールドと、（０）に設定されたＡＣＫフィールドとを備えるＨｅｌｌｏ抑制オブジェクトを含む。２つのネイバノード間でｈｅｌｌｏ抑制モードが要求されていることを示すために、他のビット設定または状態も使用され得る。

ステップ３２０で、下流ノードＲ２などのネットワーク要素が、上流ノードＲ１からｈｅｌｌｏ抑制ＲＥＱメッセージを受信して、ＲＳＶＰ ＢＦＤがアップ／アクティブか否か、およびＨｅｌｌｏ抑制が有効か否かを決定する。両方の状況が当てはまる場合、ノードＲ２が、ＨＥＬＬＯ抑制確認（ＡＣＫ）メッセージをノードＲ１に向かって送信することによって、ノードＲ１から受信したメッセージに応答する。ボックス３２５を参照すると、ｈｅｌｌｏ抑制ＡＣＫメッセージは、両方とも（１）に設定されたリクエストおよびＡＣＫフィールドを備えるＨｅｌｌｏ抑制オブジェクトを含む。２つのネイバノード間の要求されたＨＥＬＬＯ抑制モードが確認されたことを示すために、他のビット設定または状態も使用され得る。

ステップ３３０で、ノードＲ１が、２つのノード間のｈｅｌｌｏ抑制モードを確立または確認するように構成されたＨＥＬＬＯメッセージをノードＲ２に向かって送信することによって、ノードＲ２から受信されたＡＣＫメッセージに応答する。ボックス３３５を参照すると、ｈｅｌｌｏ抑制確立または確認メッセージは、両方とも（１）に設定されたリクエストおよびＡＣＫフィールドを備えるＨｅｌｌｏ抑制オブジェクトを含む。２つのネイバノード間のｈｅｌｌｏ抑制モードが確立または確認されたことを示すために、他のビット設定または状態も使用され得る。

ステップ３４０で、ステップ３１０−３３５に関して上述した最初のハンドシェイク手順の後、ノードＲ１とノードＲ２の両方が、相互に対してＨｅｌｌｏ抑制動作モードに入る。ステップ３４５を参照すると、それぞれのノードはもう一方のノードへのｈｅｌｌｏメッセージ送信を停止して、それぞれのノードは、普通なら予測されるｈｅｌｌｏメッセージの不在に応答して、ノード障害が発生した状態の決定を停止する。本明細書に記載するように、他の動作も行われ得る。この動作抑制モードの間、対応するノードまたはリンク障害を決定するためにＢＦＤメカニズムだけが使用される。

図２および図３に関して上述した方法２００／３００は、複数のネットワーク要素のうちの１つまたは複数でｈｅｌｌｏ抑制モードに日和見的に入る、および終了することを企図する。具体的には、様々な実施形態では、ノードは、（１）ノード制御プレーン障害の検出、（２）リンク障害、（３）ネイバノードグレースフルリスタート、（４）Ｒｅｓｔａｒｔ＿Ｃａｐオブジェクト変更、（５）および／またはＨｅｌｌｏ抑制無効メッセージに応答して、ＨＥＬＬＯ抑制モードを終了する。これらは例示的には以下の通りである。

（１）ノードＲ２でのノード制御プレーン障害が、ＢＦＤメカニズムを介してノードＲ１で検出される。次いで、ノードＲ１が、現在使用されているネイバダウン手順を呼び出す。ノードＲ２上でＲＳＶＰ制御プレーンが発生する（ｃｏｍｅ ｕｐ）と、再びＨＥＬＬＯメッセージの送信を開始する。リクエストフィールドは、ＲＳＶＰ ＢＦＤセッションが発生したことをノードＲ２が検出した後にのみ（１）に設定される。ＡＣＫフィールドは（０）に設定される。Ｈｅｌｌｏ抑制フェーズに再び入るために、ノードによって上述の３ウェイハンドシェイク手順が使用される。ＨＥＬＬＯメッセージ内の送信元および宛先インスタンスの値は、例示的に、ＩＥＴＦ ＲＦＣ ３２０９に記載の手順に従って適合され得る。

（２）両方のノード上で、ＢＦＤメカニズムを介して、Ｒ１とＲ２との間のリンク障害が検出される。障害が検出されると、両方のノードが、現在使用されているネイバダウン手順を呼び出す。ノード間にリンクが発生した場合、一旦ＲＳＶＰ ＢＦＤセッションがアップされると３ウェイハンドシェイク手順が呼び出される。ＨＥＬＬＯメッセージ内の送信元および宛先インスタンスの値は、例示的に、ＩＥＴＦ ＲＦＣ ３２０９に記載の手順に従って適合され得る。

（３）グレースフルリスタートが有効であるノードＲ２のリスタートの後、ノードＲ２が、ノードＲ１にＲｅｓｔａｒｔ＿Ｃａｐオブジェクトを含むＨＥＬＬＯメッセージを送信する。Ｈｅｌｌｏ抑制オブジェクトリクエストおよびＡＣＫフィールドが（０）に設定されているリスタートフェーズの間、ノードＲ１およびノードＲ２は、ＨＥＬＬＯメッセージの交換を継続する。

グレースフルリスタートフェーズの完了を検出すると、ノードは、それらのＨｅｌｌｏ抑制オブジェクトリクエストフィールドを（１）に設定して、ＡＣＫフィールドを（０）に設定する。次いで、ノードは、Ｈｅｌｌｏ抑制モードに再び入るために、３ウェイハンドシェイキングフェーズに入る。

（４）グレースフルリスタートが有効ではないノードＲ２のリスタートの後、ノードＲ２が、ノードＲ１にＲｅｓｔａｒｔ＿Ｃａｐオブジェクトを含まないＨＥＬＬＯメッセージを送信する。Ｒ１およびＲ２がＨｅｌｌｏ抑制モードにすでに入っており、グレースフルリスタートがノードＲ１上で有効である場合、Ｒ１はＨＥＬＬＯメッセージの再送信を開始する。ＨＥＬＬＯメッセージは、ＲＦＣ ３４７３に記載のＲｅｓｔａｒｔ＿Ｃａｐオブジェクト、および、リクエストフィールドを（１）に設定して、ＡＣＫフィールドを（０）に設定したＨｅｌｌｏ抑制オブジェクトを搬送する。

次いで、ノードは、最初のハンドシェイク手順の後でＨｅｌｌｏ抑制フェーズに再び入ることができる。一般的に言えば、上述のように、ノードは、Ｒｅｓｔａｒｔ＿Ｃａｐオブジェクトに変更がある場合はいつでもＨｅｌｌｏ抑制フェーズを終了するべきである。

（５）ｈｅｌｌｏ抑制モードを無効にする、または終了するための明示的なコマンドがネットワークマネージャ、特定のノード、サービスプロバイダ、またはそのような権限を与えられた他の任意のソースによって生成され得る。ｈｅｌｌｏ抑制モード無効／終了コマンドまたはメッセージの受信に応答して、ノードＲ１（例示的に）はＨｅｌｌｏ抑制オブジェクトによってＨＥＬＬＯメッセージの送信を停止し、ノードＲ２は、リクエストフィールドを（１）に設定して、ＡＣＫフィールドを（０）に設定したＨＥＬＬＯメッセージの送信を開始する。同様に、ノードＲ１上でＨｅｌｌｏ抑制が可能になると、ノードは、上述の３ウェイハンドシェイク手順の後で抑制フェーズに再び入る。

本発明の様々な実施形態では、ＨＥＬＬＯメッセージ交換を完全に抑制するよりも、むしろＨＥＬＬＯメッセージを受信できないことが障害が発生したネイバノードを示す時間間隔が、より長い時間間隔に修正される。修正された時間間隔の実施形態は、有利には、依拠していたＢＦＤメカニズムの障害が発生したネイバノードの障害を識別するためのメカニズムを提供する。

様々な実施形態では、修正された時間間隔を提供するために、既存の時間間隔がある因数だけ乗算または増加される。様々な実施形態では、修正された時間間隔が直接指定される。修正された時間間隔を示すデータは、本明細書に記載の様々なＨＥＬＬＯ抑制印内に含まれ得る。

修正された時間間隔の実施形態は、様々な図面に関して上述した方法と実質的に同じ方法で動作する。１つの違いは、第２の（抑制された）動作モードが、修正された時間間隔内にＨＥＬＬＯメッセージを受信できないことに応答した場合にも２４０で終了する（ボックス２４５を参照）点で図２の方法２００が修正されていることである。同様に、図３の方法３００は、ステップ３４０でＨＥＬＬＯ抑制動作モードが修正された間隔スケジュールに従ってＨＥＬＬＯメッセージの送信をさらに企図する点で修正される。

図４は、本明細書に記載の機能を実行する際の使用に適したコンピュータのハイレベルブロック図を示している。

図４に示されるように、コンピュータ４００は、プロセッサ要素４０３（たとえば、中央処理装置（ＣＰＵ）および／または他の適切なプロセッサ）、メモリ４０４（たとえば、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）など）、協働モジュール／処理４０５、ならびに様々な入力／出力デバイス４０６（たとえば、ユーザ入力デバイス（キーボード、キーパッド、マウスなど）、ユーザ出力デバイス（ディスプレイ、スピーカなど）、入力ポート、出力ポート、受信機、送信機、および記憶装置（たとえば、テープドライブ、フロッピー（登録商標）ドライブ、ハードディスクドライブ、コンパクトディスクドライブなど））を含む。

本明細書に図示および記載された機能は、たとえば汎用コンピュータ、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、および／あるいは他の任意のハードウェア均等物を使用して、ソフトウェアとハードウェアの組合せに実装することができ、一実施形態では、本明細書に記載の機能を実装するために、協働処理４０５は、メモリ４０４にロードされて、プロセッサ４０３によって実行され得ることが理解されよう。したがって、協働処理４０５（関連するデータ構造を含む）は、ＲＡＭメモリ、磁気または光ドライブ、あるいはディスケットなどのコンピュータ可読記憶媒体に記憶され得る。

図４に示されたコンピュータ４００は、本明細書に記載の機能要素、または本明細書に記載の機能要素の部分ネットワークの実装に適した一般的なアーキテクチャおよび機能性を提供することが理解されよう。

本明細書で論じたステップのうちのいくつかは、たとえば、様々な方法ステップを実行するためにプロセッサと協働する回路としてハードウェア内で実装され得ることが企図される。本明細書に記載の機能／要素の一部は、コンピュータプログラム製品として実装されてよく、コンピュータ命令は、コンピュータによって処理されると、本明細書に記載の方法および／または技法が呼び出される、または他の方法で提供されるように、コンピュータの動作を適合する。本発明の方法を読み出すための命令は、固定またはリムーバブルの媒体あるいはメモリなどの、有形の非一時的なコンピュータ可読媒体に記憶されてもよく、および／または、命令に従って動作するコンピューティングデバイス内のメモリ内に記憶されてもよい。

上記は、本発明の様々な実施形態を対象としているが、本発明の基本的な範囲から逸脱することなしに、他の、およびさらなる実施形態を考案することができる。したがって、本発明の適切な範囲は特許請求の範囲によって決定されるべきである。

Claims (10)

1. ネットワークノードで使用するための方法であって、
   リソース予約プロトコル（ＲＳＶＰ）ＨＥＬＬＯメッセージ交換を使用して、１つまたは複数のネイバノードとネイバノード関係を確立するステップと、
   ネイバノードに対して第１の動作モードで、ネイバノードが障害が発生した状態であることを決定するためにＨＥＬＬＯメッセージを使用するステップと、
   ネイバノードに対して第２の動作モードで、ネイバノードが障害が発生した状態であることを決定するために双方向フォワーディング検出（ＢＦＤ）メカニズムを使用するステップであって、ネイバノードから受信したＨＥＬＬＯ抑制アクティブ印に応答して第２の応答モードに入る、使用するステップとを備える、ネットワークノードで使用するための方法。
2. 双方向フォワーディング検出（ＢＦＤ）メカニズムの使用に応答して、１つまたは複数の上流ネイバノードに向かって前記ＨＥＬＬＯ抑制アクティブ印を送信するステップをさらに備える、請求項１に記載の方法。
3. 下流ネイバノードから送信されたＨＥＬＬＯ抑制アクティブ印を受信するステップに応答して、前記下流ネイバノードに関連付けられる１つまたは複数の上流ネイバノードに向かって前記ＨＥＬＬＯ抑制アクティブ印を送信するステップをさらに備える、請求項２に記載の方法。
4. 前記ＨＥＬＬＯ抑制アクティブ印が、ＨＥＬＬＯメッセージ内にＨｅｌｌｏ抑制オブジェクトの含有を備え、前記Ｈｅｌｌｏ抑制オブジェクトが、通常の動作モードを示すために第１の状態に設定され、抑制された動作モードを示すために第２の状態に設定される、請求項１に記載の方法。
5. 前記Ｈｅｌｌｏ抑制オブジェクトが、ＨＥＬＬＯメッセージを受信できないことが障害が発生したネイバノードを示す修正された時間間隔を示すデータを含む、請求項４に記載の方法。
6. 修正された時間間隔を示す前記データが、既存の時間間隔乗数と特定の時間間隔とのうちの１つを備える、請求項５に記載の方法。
7. 前記ネイバノードによる前記ＢＦＤメカニズムの使用停止と、ネイバノードから受信されたＨＥＬＬＯ抑制非アクティブ印とのうちの１つに応答して、前記ネイバノードに対して前記通常の動作モードに入るステップをさらに備える、請求項１に記載の方法。
8. リソース予約プロトコル（ＲＳＶＰ）ＨＥＬＬＯメッセージ交換を使用して、１つまたは複数のネイバノードとネイバノード関係を確立して、
   ネイバノードに対して第１の動作モードで、ネイバノードが障害が発生した状態であることを決定するためにＨＥＬＬＯメッセージを使用して、
   ネイバノードに対して第２の動作モードで、ネイバノードが障害が発生した状態であることを決定するために双方向フォワーディング検出（ＢＦＤ）メカニズムを使用して、ネイバノードから受信したＨＥＬＬＯ抑制アクティブ印に応答して前記第２の応答モードに入るように構成されたプロセッサを備える、装置。
9. コンピュータによって実行されると、
   リソース予約プロトコル（ＲＳＶＰ）ＨＥＬＬＯメッセージ交換を使用して、１つまたは複数のネイバノードとネイバノード関係を確立するステップと、
   ネイバノードに対して第１の動作モードで、ネイバノードが障害が発生した状態であることを決定するためにＨＥＬＬＯメッセージを使用するステップと、
   ネイバノードに対して第２の動作モードで、ネイバノードが障害が発生した状態であることを決定するために双方向フォワーディング検出（ＢＦＤ）メカニズムを使用するステップであって、前記第２の動作モードが、ネイバノードから受信したＨＥＬＬＯ抑制アクティブ印に応答して入った、使用するステップとを備える方法を提供するために、コンピュータの動作を適合する命令を記憶する、コンピュータ可読記憶媒体。
10. コンピュータ命令がコンピュータによって処理されると、
    リソース予約プロトコル（ＲＳＶＰ）ＨＥＬＬＯメッセージ交換を使用して、１つまたは複数のネイバノードとネイバノード関係を確立するステップと、
    ネイバノードに対して第１の動作モードで、ネイバノードが障害が発生した状態であることを決定するためにＨＥＬＬＯメッセージを使用するステップと、
    ネイバノードに対して第２の動作モードで、ネイバノードが障害が発生した状態であることを決定するために双方向フォワーディング検出（ＢＦＤ）メカニズムを使用するステップであって、ネイバノードから受信したＨＥＬＬＯ抑制アクティブ印に応答して前記第２の応答モードに入る、使用するステップとを備える方法を提供するために、コンピュータの動作を適合する、コンピュータプログラム製品。

Images