JP2013509015A - 高速再ルーティング条件下のｒｓｖｐ−ｔｅグレースフルリスタート - Google Patents

Abstract

１つの実施形態によれば、保護されるラベルスイッチパス（ＬＳＰ）のリンク障害及びノード障害のうち少なくとも１つに応じて、高速リルーティング（ＦＲＲ）方式に従ってネットワークトラフィックを保護経路上に切り替える。ネットワークエレメントに直接隣接しないリモートノードとのＨＥＬＬＯセッションが確立され、それは、ＩＰ転送が使用される場合、１よりも大きいＴＴＬ（time-to-live）値を各々有する１つ以上のＨＥＬＬＯメッセージをリモートノードと交換することを含む。ＨＥＬＬＯメッセージがトンネルを介して送信される場合、上記ＨＥＬＬＯメッセージのＴＴＬ値は、１に設定される。リスタートの要求に応じて、ＨＥＬＬＯセッションの間にリモートノードと交換される１つ以上のＨＥＬＬＯメッセージから取得される情報を用いて、ＲＳＶＰ（resource reservation protocol） ＴＥ（traffic engineering）グレースフルリスタート（ＧＲ）手続が実行される。
【選択図】図１

Description

本発明の実施形態は、一般的に、ネットワーキングの分野に関し、より具体的には、ネットワークエレメントのＲＳＶＰ−ＴＥグレースフルリスタートに関する。

ＲＳＶＰ（resource reservation protocol）−ＴＥ（traffic engineering）のグレースフルリスタート（ＧＲ：graceful restart）方式は、ネットワークエレメント又はネットワークノードの制御プレーンの障害の間に、トラフィックが影響を受けないように、ラベルスイッチパス（ＬＳＰ：label switched path）を維持する仕組みを提供する。ＲＳＶＰ−ＧＲの仕様に関するさらに詳細な情報は、ＲＦＣ−３４７３及びＲＦＣ−５０６３などの複数のＲＦＣ（request for comments）において見出すことができる。

ＲＳＶＰ高速再ルーティング（ＦＲＲ：fast reroute）方式は、ＲＦＣ−４０９０において仕様化されており、リンク又はノードの障害が発生した際に、設備の保護のために予め確立される保護されるＬＳＰからのバイパストンネルへ、ローカルリペアポイント（ＰＬＲ）ノード上でトラフィックを切り替えることができるように、高速なローカルリペアの仕組みを提供する。マージポイント（ＭＰ）ノードは、保護されるＬＳＰへトラフィックをマージバックする。バイパストンネルは、複数の保護されるＬＳＰについてＦＲＲ保護を提供することができる（１：Ｎ保護）。ＦＲＲが有効である際に、トラフィックは、延長される期間までバイパス経路に留まることができる。この期間の間、ＰＬＲノード又はＭＰノードがリスタートすると、ＭＰノードが直接ＰＬＲノードに接続されていなければ、ＰＬＲノードとＭＰノードとの間でＨＥＬＬＯメッセージが交換されないため、ＲＳＶＰ ＧＲ手続を適用することができない。ＲＦＣ−３２０９において定義されているように、ＲＳＶＰ ＨＥＬＬＯセッションは、直接隣接するノード間のみで稼働する。

ＲＦＣ−３２０９によれば、ＲＳＶＰ ＨＥＬＬＯメッセージが、直接接続される隣接するノードの間で交換されて、隣接するノードの制御プレーンの動作状態を検出する。ＲＦＣ−３４７３は、ＲＳＶＰ ＨＥＬＬＯの仕組みを拡張してＲＳＶＰグレースフルリスタートの機能をサポートする。ＨＥＬＬＯメッセージを使用して、グレースフルリスタート機能オブジェクトと、ＬＳＰを維持し、ネットワークエレメントの制御プレーンの障害又はリスタートの後でＬＳＰ状態を回復するのに使用される情報とを伝達する。ＨＥＬＬＯセッションが確立されない場合、グレースフルリスタートを実現することができない。ＲＦＣ−４５５８は、ノードＩＤベースのＨＥＬＬＯメッセージを導入する。

ネットワークエレメントのグレースフルリスタートを実行することを目的として、上記ネットワークエレメントに直接隣接しないリモートノードとのＨＥＬＬＯセッションを確立する方法が提供される。本発明の１つの観点によれば、上記ネットワークエレメントに直接隣接しない上記リモートノードとのＨＥＬＬＯセッションは、上記リモートノードとのＨＥＬＬＯメッセージの交換によって、確立される。ＩＰ転送を用いて上記ＨＥＬＬＯメッセージを送信することができ、一方、上記ＨＥＬＬＯメッセージのＴＴＬ（time-to-live）値は、１よりも大きく設定されるべきである。ターゲットとされる上記ネットワークエレメントのみが、上記ＨＥＬＬＯメッセージを処理し、上記ＨＥＬＬＯメッセージの送信者へＡＣＫＩＮＡＣＫを伴う上記ＨＥＬＬＯメッセージを応答する。ネットワーク内の他の全てのノードは、上記メッセージの上記ＴＴＬ値がゼロより大きい場合は、上記ＨＥＬＬＯメッセージの宛先へ向けて上記ＨＥＬＬＯメッセージをただ転送する。ＨＥＬＬＯメッセージの上記ＴＴＬ値がゼロに達した場合、上記ＨＥＬＬＯメッセージは、静かに廃棄されるであろう。非直接的に接続されるノード間にトンネルが存在する場合、上記トンネルを介して上記ＨＥＬＬＯメッセージを送信することができ、一方、上記ＨＥＬＬＯメッセージの上記ＴＴＬ値は、１に設定されてもよい。

本発明の別の観点によれば、保護されるＬＳＰのリンク／ノード障害の前に、上記ネットワークエレメントに直接隣接しないリモートネットワークエレメントとのＨＥＬＬＯセッションを確立することができる。上記保護されるＬＳＰの上記リンク／ノード障害に応じて、上記トラフィックは、高速リルーティング（ＦＲＲ）方式に従って、上記バイパストンネル上へ切り替えられる。その後、制御プレーンの障害又はリスタートの要求に応じて、上記ＨＥＬＬＯセッションの間に上記リモートノードと交換されるＨＥＬＬＯメッセージから取得される情報を用いて、ＲＳＶＰ（resource reservation protocol） ＴＥ（traffic engineering）グレースフルリスタート（ＧＲ）手続が実行される。上記ＨＥＬＬＯメッセージから取得される情報は、保護されるＬＳＰの状態を維持するのに役立つ。

本発明の別の観点によれば、上記保護されるＬＳＰのリンク／ノード障害によってトリガされる上記ＦＲＲに応じて、上記ネットワークエレメントに直接隣接しないネットワークエレメントとのＨＥＬＬＯセッションを確立することができ、バイパストンネルが確立されて、上記保護されるＬＳＰの上記トラフィックを伝達する。上記非直接的に接続されるノードは、Ｒｅｓｔａｒｔ＿Ｃａｐオブジェクトを含むＨＥＬＬＯメッセージを交換し、制御プレーンに障害が生じ、又はリスタートする際、グレースフルリスタートが行われる場合、Ｒｅｓｔａｒｔ＿Ｃａｐオブジェクトを用いて、保護されるＬＳＰの状態を維持し、回復することができる。上記非直接的に接続されるノード間で交換される上記ＨＥＬＬＯメッセージは、上記ＨＥＬＬＯメッセージの上記ＴＴＬ値が１より大きく設定されている間、ＩＰ転送を用いて送信され得る。上記非直接的に接続されるノード間における上記トンネルを介して上記ＨＥＬＬＯメッセージを送信することができる場合、上記ＨＥＬＬＯメッセージの上記ＴＴＬ値は、１に設定され得る。

本発明の別の観点によれば、上記非直接的に接続されるネットワークエレメント間のＨＥＬＬＯセッションを、いずれの側においてもその論理的な隣接ノードとして上記リモートネットワークエレメントを構成することによって、開始することができる。上記リモートネットワークエレメントの構成されるアドレスは、上記リモートネットワークエレメントへ向けて送信される上記ＨＥＬＬＯメッセージの宛先アドレスのフィールド上で使用される。上記リモートネットワークエレメントからの応答をもって、上記ＨＥＬＬＯセッションの確立が完了する。

本発明の別の観点によれば、ＩＰ転送、又はリンク／ノード障害が発生し、ＦＲＲがトリガされる前、若しくは後に、保護されるラベルスイッチパス（ＬＳＰ）を保護するように構成されるバイパストンネル、を介して、上記ネットワークエレメントにおいて上記リモートネットワークエレメントから受信される経路メッセージによって、上記非直接的に接続されるネットワークエレメント間のＨＥＬＬＯセッションを開始することができる。上記経路メッセージに応じて、上記ネットワークエレメントに直接隣接しない上記リモートノードとＨＥＬＬＯセッションが交換され、それは、２５５のＴＴＬ（time-to-live）値を各々有するＨＥＬＬＯメッセージを上記リモートノードと交換することを含む。上記保護されるＬＳＰのリンク障害、及び／又はノード障害に応じて、上記ネットワークトラフィックは、高速リルーティング（ＦＲＲ）方式を用いて上記バイパストンネル上へ切り替えられている。その後、リスタートの要求に応じて、上記ＨＥＬＬＯセッションの間に上記リモートノードと交換される１つ以上の上記ＨＥＬＬＯメッセージから取得される情報を用いて、ＲＳＶＰ（resource reservation protocol） ＴＥ（traffic engineering）グレースフルリスタート（ＧＲ）手続が実行される。上記ＨＥＬＬＯメッセージから取得される上記情報は、保護されるＬＳＰの状態を維持するのに役立つ。

本発明の他の特徴は、添付の図面及び次の詳細な説明から明らかであろう。

本発明の実施形態は、添付図面の図において限定ではなく例として説明され、同様の参照が同等のエレメントを意味する。

本発明の一実施形態で使用され得るネットワーク構成を説明するブロック図である。 本発明の１つの実施形態に係るＨＥＬＬＯメッセージと共に使用され得るＩＰヘッダを説明するブロック図である。 本発明の１つの実施形態に係る、ＰＬＲノードによりＨＥＬＬＯセッションを開始するための方法を説明するフロー図である。 本発明の１つの実施形態に係る、ＭＰノードによりＨＥＬＬＯセッションを開始するための方法を説明するフロー図である。 本発明の１つの実施形態に係るネットワークエレメントを説明するブロック図である。

次の説明において、多くの具体的な詳細が説明される。一方、本発明の実施形態がこれら具体的な詳細がなくても実施され得ることは、理解される。他の事例において、本説明の理解を曖昧にしないために、周知の回路、構造、及び技術は、詳細に示されていない。

“one embodiment”、“an embodiment”、“an example embodiment”などへの本明細書における言及は、説明される実施形態が特定の特性、構造、又は特徴を含み得ることを意味するが、全ての実施形態は特定の特性、構造、又は特徴を必ずしも含まなくてもよい。さらに、そのような語句は、必ずしも同じ実施形態に言及しているわけではない。さらに、特定の特性、構造、又は特徴が、実施形態との関連において説明される場合、明確に説明されていようとなかろうと、そのような特性、構造、又は特徴が、他の実施形態との関連において作用することは、当業者の知識の範囲内であると考えられる。

次の説明及び特許請求の範囲において、“連結される（coupled）”及び“接続される（connected）”という用語が、その派生語と共に使用され得る。これらの用語がお互いに同義語として意図されていないことは、理解されるべきである。“連結される”は、お互いに直接に物理的に又は電気的に接触してもしなくてもよい２つ以上のエレメントが、お互いに協働し、又は相互作用することを意味するために使用される。“接続される”は、お互いに連結される２つ以上のエレメントの間における通信の確立を意味するために使用される。

１つの実施形態によれば、ＲＳＶＰ ＨＥＬＬＯの仕組みの拡張が提供されて、例えば、保護経路内で間に少なくとも１つの中間ノードが存在するＰＬＲノード及びＭＰノードのような、非直接的に接続される隣接する（neighboring）ノードの間で、ＨＥＬＬＯセッションが動作することを可能とする。結果として、ＦＲＲが有効である場合でも、ＰＬＲノード及びＭＰノードのＲＳＶＰグレースフルリスタートを実行することができる。

上述されるように、一般的に、ＲＳＶＰ ＨＥＬＬＯメッセージは、隣接するノードの制御プレーンの動作状態を検出するために、直接接続される隣接するノードの間で交換される。そのようなＨＥＬＬＯの仕組みは、ＲＳＶＰ ＧＲの機能をサポートするために拡張された。ＨＥＬＬＯメッセージは、グレースフルリスタート機能オブジェクトと、ＬＳＰを維持し、制御プレーンの障害又はリスタートの後でＬＳＰ状態を回復するのに使用される情報とを伝達するために使用される。ＨＥＬＬＯセッションが確立されなければ、グレースフルリスタートを実現することができない。

上述されるように、リンク／ノードに障害が生じると、ＦＲＲがトリガされ、ＰＬＲノードは、ネットワークトラフィックを設備の保護のためのバイパストンネルへ移動させる。トラフィックは、ＭＰノードにおいてＬＳＰへマージバックされる。トラフィックは、延長される期間までバイパストンネルを通って流れるが、この期間の間に制御プレーンがＰＬＲ又はＭＰノードにおいてリスタートすると、ＰＬＲ及びＭＰノードと保護されるＬＳＰとの間のバイパストンネルを通るトラフィックフローがグレースフルリスタート機能の欠如により維持されないため、保護されるＬＳＰ上のトラフィックは失われ得る。ＲＦＣ−３２０９によれば、間に１つより多くのホップが存在する場合、ＰＬＲとＭＰノードとの間でＨＥＬＬＯセッションを確立することができない。この状況において、経路メッセージがバイパストンネルを介して送信されるため、これらは、保護されるＬＳＰの観点から論理的に隣接ノード（neighbor）を形成していても、物理的には直接的な隣接ノードではない。

図１において示されるように、例えば、保護されるＬＳＰは、Ｒ１−Ｒ２−Ｒ３−Ｒ４−Ｒ５としてセットアップされる。ノードの保護のためのバイパストンネルは、Ｒ２−Ｒ６−Ｒ４として確立される。Ｒ２−Ｒ３の間のリンク、又はノードＲ３に障害が生じると、Ｒ２（例えば、ＰＬＲノード）は、ＦＲＲ方式に基づいて、バイパスＲ２−Ｒ６−Ｒ４を通るようにトラフィックフローを切り替える。ＦＲＲが有効である間、Ｒ２又はＲ４がリスタートする場合、それらがお互いに直接隣接して（adjacent）いないため、Ｒ２とＲ４との間でＨＥＬＬＯセッションを確立することができないことから、Ｒ２及びＲ４のグレースフルリスタートは実行されず、ＬＳＰは維持されず、結果として、ネットワークトラフィックは影響を受ける。

１つの実施形態によれば、直接隣接するノードではないノード間で、ＨＥＬＬＯメッセージの交換を通じて、ＨＥＬＬＯセッションを確立することができる。隣接ノードへ発信する全てのＨＥＬＬＯメッセージについてのＩＰヘッダのＴＴＬ（time-to-live）フィールドは、１より大きい値に設定される。好適な実施形態において、ＨｅｌｌｏメッセージがＩＰ転送を介して送信される場合、２５５であるＴＴＬ値が使用される。リモートノードのノード識別子（ＩＤ）又はインタフェースアドレス（例えば、ＩＰｖ４若しくはＩＰｖ６）は、ＨＥＬＬＯパケットの宛先フィールドにおいて使用される。ＲＦＣ−３２０９及びＲＦＣ−３４７３において説明されるような、対応するＨＥＬＬＯメッセージハンドリング手続が、適用される。これらの非直接的に接続されるノードの間で、一旦ｈｅｌｌｏセッションが確立されると、ＲＦＣ−３４７３及びＲＦＣ−５０６３において説明されるようなＲＳＶＰグレースフルリスタート手続を、これらノードに適用することができる。

ＨＥＬＬＯセッションが要求されると、非直接的に接続される隣接ノードを、ローカルノード上で動的に発見することができる。例えば、トンネルがセットアップされる際、入口（ingress）ノード及び出口（egress）ノードは、ＨＥＬＬＯセッションについて隣接ノードを形成することができる。ＨＥＬＬＯセッションが要求されているローカルノードにより、非直接的に接続されている隣接ノードが発見されると、ＨＥＬＬＯ要求オブジェクトを含むＨＥＬＬＯメッセージがリモートノードへ向けて送出され、その際、ＨＥＬＬＯメッセージの宛先アドレスのフィールドはリモートノードのアドレスをもって特定される。

ＲＳＶＰ ＦＲＲの設備の保護の場合、保護されるＬＳＰについてＰＬＲによりバイパストンネルが確立され又は選択されると、ＰＬＲは、Ｈｅｌｌｏ要求オブジェクトを含むＨＥＬＬＯメッセージをバイパスの出口ノードへ向けて送信することによって、ＨＥＬＬＯセッションを開始し得る。ＨＥＬＬＯメッセージは、ＩＰ転送を用いて又はバイパストンネルを介して送信され得る。バイパストンネルの出口ノードがＨＥＬＬＯ要求メッセージを受信すると、それは、ＨＥＬＬＯ＿ＡＣＫオブジェクトを伴うＨＥＬＬＯメッセージをバイパストンネルの入口ノードへ送信し返す。バイパストンネルの入口ノードがＨＥＬＬＯ ＡＣＫメッセージを受信すると、バイパストンネルの入口ノードと出口ノードとの間でＨＥＬＬＯセッションが確立される。

ローカルノードとリモートノードとの間にトンネル（例えば、ＬＳＰトンネル又はバイパストンネル）が存在する場合、ＨＥＬＬＯメッセージは、トンネル上で送信され得る。バイパストンネルが静的に構成される場合、トンネル上でＨＥＬＬＯセッションを稼働させることは、データプレーンの生存（liveness）チェックとして動作し得る。そのようなトンネルが利用不可能である場合、ＨＥＬＬＯメッセージは、それが宛先に達し、又はＴＴＬが０に達するまで、ＩＰルーティングにより転送される。ＨＥＬＬＯメッセージの宛先アドレスのフィールド内で特定されるアドレスを伴うリモートノードのみが、ＨＥＬＬＯメッセージを処理し、ＨＥＬＬＯ ＡＣＫオブジェクトを含むＨＥＬＬＯメッセージをもって、ＨＥＬＬＯ要求メッセージの送信者へ向けて応答するであろう。ＨＥＬＬＯ要求メッセージの送信者がＨＥＬＬＯ＿ＡＣＫを伴うＨＥＬＬＯメッセージを受信すると、ＨＥＬＬＯセッションが確立される。

リモートノードがトンネルの出口ノードであって、そのためＦＲＲから見るとＭＰポイントとして動作する場合に、リモートノードを、ＲＳＶＰ経路メッセージを受信することによって発見することができる。リンク／ノードに障害が生じてＦＲＲが行われる前に、又はその後に、リモートノードの発見を実行することができる。

バイパストンネルが確立されようとしている際にバイパストンネルの出口ノードにおいてバイパストンネルの経路メッセージを受信することによって、リモートノードを、リンク／ノードに障害が生じる前に発見することができる。やはりＭＰノードである出口ノードは、バイパストンネルについての経路メッセージを受信し、ＨＥＬＬＯ要求オブジェクトを伴うＨＥＬＬＯメッセージをやはりＰＬＲノードであるバイパスの入口ノードへ向けて送信することによって、ＨＥＬＬＯセッションを開始することができる。ＨＥＬＬＯメッセージは、１よりも大きい値に設定されるＴＴＬ値を伴って、ＩＰ転送を介して送信される。バイパストンネルの入口ノード上でＨＥＬＬＯ要求オブジェクトを伴うＨＥＬＬＯメッセージが受信されると、バイパストンネルの入口ノードは、バイパストンネルの出口ノードへ向けてＨＥＬＬＯ Ａｃｋオブジェクトを伴うＨＥＬＬＯメッセージを応答する。バイパストンネルの出口ノードがＨＥＬＬＯ Ａｃｋオブジェクトを伴うＨＥＬＬＯメッセージを受信すると、バイパストンネルの入口ノード（保護されるＬＳＰについてのＰＬＲノード）と出口ノード（保護されるＬＳＰについてのＭＰノード）との間でＨＥＬＬＯセッションが確立される。

また、ＦＲＲが有効である際に、保護されるＬＳＰの経路メッセージをバイパストンネル上で受信することによって、リモートノードを、リンク／ノードに障害が生じた後に発見することができる。ＭＰノードは、経路メッセージを受信し、ＨＥＬＬＯ要求オブジェクトを伴うＨＥＬＬＯメッセージをバイパスの入口ノードへ向けて送信することによって、ＨＥＬＬＯセッションを開始し得る。ＨＥＬＬＯメッセージは、ＩＦ転送を介して送信される。バイパストンネルの入口ノード上でＨＥＬＬＯ要求オブジェクトを伴うＨＥＬＬＯメッセージが受信されると、入口ノードは、バイパストンネルの出口ノードへ向けてＨＥＬＬＯ Ａｃｋオブジェクトを伴うＨＥＬＬＯメッセージを送信する。バイパストンネルの出口ノードがＨＥＬＬＯ Ａｃｋオブジェクトを伴うＨＥＬＬＯメッセージを受信すると、バイパストンネルの入口ノードと出口ノードとの間でＨＥＬＬＯセッションが確立される。

非直接的に接続されるノードのいずれの側でも、ＨＥＬＬＯセッションがそれらの間で必要とされた場合に、非直接的に接続される隣接ノードを構成することができる。当該構成がトリガとなって、ＨＥＬＬＯ要求オブジェクトを伴うＨＥＬＬＯメッセージがリモートノードへ向けて送信される。ＨＥＬＬＯ ＡＣＫオブジェクトを伴うＨＥＬＬＯメッセージがリモートノードから戻って受信されると、ＨＥＬＬＯセッションが確立される。

ローカルノードとリモートノードとのペアごとに１つのＨＥＬＬＯセッションが確立される。ノード間に複数のトンネルが存在する場合、１つのＨＥＬＬＯセッションしか確立されない。ＨＥＬＬＯセッションについて複数のトンネルが存在する場合、ＨＥＬＬＯメッセージを転送するためのトンネルの選択が、ローカルポリシーに基づいて実行される。

直接接続されないローカルノードとリモートノードとの同じペアの間で、複数のＨＥＬＬＯセッションを、必要に応じて確立することができる。Ｈｅｌｌｏセッションの識別子（３２ビット）が、非直接的に接続されるノード間で交換されるＨＥＬＬＯメッセージに付加されて、ＨＥＬＬＯメッセージの発信元及び宛先アドレスのフィールドと共に特定のＨＥＬＬＯセッションを一意に識別する。１つの実施形態によれば、非直接的に接続されるノード間のＨＥＬＬＯセッションのサポートは、構成を介して有効化され、又は無効化され得る。

図１を参照すると、リンク、この例ではノードＲ２とＲ３との間のリンク、が停止している場合、保護されるＬＳＰ Ｒ２−Ｒ３−Ｒ４のネットワークトラフィックは、ＦＲＲの設備の保護のためのバイパストンネルである保護される経路Ｒ２−Ｒ６−Ｒ４へ切り替えられる。ネットワークトラフィックは、ＲＦＣ−４０９０において説明されるＦＲＲ手続に従って、ローカルリペアポイント（ＰＬＲ）ノード、この例では、Ｒ２、によってＦＲＲ方式を用いて、保護経路へ切り替えられ得る。ＦＲＲの仕様に係るさらに詳細な情報は、ここでの参照によって取り入れられ、ＲＦＣ−４０９０において見出すことができる。

加えて、ＦＲＲが有効である間、ＰＬＲノードとしてのＲ２は、ＨＥＬＬＯ要求オブジェクトを含むＨＥＬＬＯメッセージを定期的に生成し、ＭＰノードとしてのＲ４へ保護経路Ｒ２−Ｒ６−Ｒ４を通じて送信する。ＨＥＬＬＯメッセージにおいて、対応するＩＰヘッダのＴＴＬフィールドは、１より大きい値に設定される。好適には、ＨＥＬＬＯメッセージのＴＴＬフィールドは、２５５の値に設定される。典型的に、ＴＴＬフィールドは、特定のＩＰパケットのデータグラムがインターネットシステム内に残存することを可能とする最大時間を意味する。ＴＴＬフィールドが値ゼロを含む場合、データグラムは、廃棄されなければならない。ＴＴＬフィールドは、インターネットのヘッダ処理において変更される。時間は、秒単位で測定されるが、データグラムを処理するすべてのモジュールは、それが秒未満でデータグラムを処理する場合にも、少なくとも１ずつＴＴＬを減らさなければならないため、ＴＴＬは、データグラムが存在し得る時間上の単なる上限として考慮されなければならない。配達不能のデータグラムが廃棄されるようにし、データグラムの最大寿命を設ける（bind）ことが、意図される。ＲＦＣ−３２０９において説明される従来のＨＥＬＬＯメッセージは、ＨＥＬＬＯメッセージが２つの直接隣接し、又は直接接続されるノードの間で交換されるよう設計されるように、ＨＥＬＬＯメッセージのＴＴＬフィールドが１に設定されることを必要とする。

図１において示される例において、ＰＬＲノードＲ２とＭＰノードＲ４との間に少なくとも１つのホップ（例えば、ノードＲ６）が存在するため、１のＴＴＬ値を伴う従来のＨＥＬＬＯメッセージは、Ｒ２からＲ４へ達することができない。即ち、ＨＥＬＬＯメッセージのＴＴＬフィールドを１の値に設定することによって、ＨＥＬＬＯメッセージは、Ｒ６のような中間ノードによってドロップされ得る。ＨＥＬＬＯメッセージのＴＴＬフィールドを１より大きく、好適には２５５に、設定することによって、そのようなＨＥＬＬＯメッセージは、Ｒ２からＲ４へ達することができる。図２は、ＨＥＬＬＯメッセージと共に使用され得るＩＰヘッダを説明するブロック図であり、ここでＩＰヘッダのＴＴＬフィールドは、１より大きく、好適には２５５に、なるよう設定される。様々な動作構成におけるＨＥＬＬＯプロトコルに関するさらに詳細な情報は、ここでの参照により取り入れられるＲＦＣ−３２０９、ＲＦＣ−３４７３、ＲＦＣ−４５５８、及びＲＦＣ−５０６３において見出すことができる。本出願を通して説明される技術は、上述のＲＦＣにおいて定義される構成に適用され得る。

それに応じて、ＭＰノードとしてのＲ４は、ＨＥＬＬＯ ＡＣＫオブジェクトを伴うＨＥＬＬＯメッセージを返信する。Ｒ２及びＲ４のうちいずれか１つがグレースフルリスタートを実行する際、Ｒ２及びＲ４はＨＥＬＬＯメッセージを交換し得るため、バイパストンネルを用いる保護されるＬＳＰを迅速な回復のために維持することができる。

図３は、保護されるＬＳＰのリンク／ノード障害によってトリガされるＦＲＲが行われた後にＨＥＬＬＯセッションが開始され確立される場合の、本発明の１つの実施形態に係るＰＬＲノードによるＨＥＬＬＯセッションを開始するための方法を説明するフロー図である。なお、方法３００は、ソフトウェア、ハードウェア、又は両者の組合せを含み得る処理ロジックによって実行されてよい。方法３００は、例えば、図１のＲ２のようなＰＬＲノードにより実行されてよい。図３を参照すると、ブロック３０１において、保護されるＬＳＰ（例えば、図１のＲ２−Ｒ３−Ｒ４）のノード／リンク障害に応じて、ＰＬＲノード（例えば、図１のＲ２）は、ＦＲＲ方式に基づいてネットワークトラフィックを保護経路（例えば、図１のＲ２−Ｒ６−Ｒ４）上に切り替える。ブロック３０２において、ＰＬＲノードは、ＰＬＲノードに直接隣接しないＭＰノード（例えば、図１のＲ４）とのＲＳＶＰ−ＴＥ ＧＲのＨＥＬＬＯセッションを確立し、これは、１よりも大きいＴＴＬを伴うＨＥＬＬＯ要求メッセージを保護経路上でＭＰノードに送信することを含む。それに応じて、ブロック３０３において、ＭＰノードは、ＨＥＬＬＯ確認応答メッセージをＰＬＲノードに返送して、ＨＥＬＬＯセッションの確立を完了する。なお、ＨＥＬＬＯセッションは、トラフィックの保護経路上への切り替えに先立って確立されてもよい（ブロック３０２及び３０３）。

ブロック３０４において、リスタートの要求に応じて、ＰＬＲノードは、ＨＥＬＬＯセッションにおいて交換されるＨＥＬＬＯメッセージから取得される情報を用いて、ＦＲＲが有効である間に、グレースフルリスタート動作を実行する。

図４は、保護されるＬＳＰのリンク／ノード障害によりトリガされるＦＲＲが行われた後にＨＥＬＬＯセッションが開始され確立される場合の、本発明の１つの実施形態に係るＭＰノードによるＨＥＬＬＯセッションを開始するための方法を説明するフロー図である。なお、方法４００は、ソフトウェア、ハードウェア、又は両者の組合せを含み得る処理ロジックによって実行されてよい。方法４００は、例えば、図１のＲ４のようなＭＰノードにより実行され得る。図４を参照すると、ブロック４０１において、保護されるＬＳＰ（例えば、図１のＲ２−Ｒ３−Ｒ４）のノード／リンク障害に応じて、ＰＬＲノード（例えば、図１のＲ２）は、ＦＲＲ方式に基づいてネットワークトラフィックを保護経路（例えば、図１のＲ２−Ｒ６−Ｒ４）上に切り替える。ブロック４０２において、ＭＰノード（例えば、図１のＲ４）は、ＰＬＲノードがＭＰノードに直接隣接しないことを示す経路メッセージをＰＬＲノードから保護経路上で受信する。ブロック４０３において、ＭＰノードは、ＭＰノードに直接隣接しないＰＬＲノードとのＨＥＬＬＯセッションを確立し、これは、１よりも大きい値、好適には２５５、を有するＴＴＬフィールドを伴うＨＥＬＬＯ要求メッセージをＰＬＲノード（例えば、図１のＲ２）へ保護経路上で送信することを含む。ブロック４０４において、ＭＰノードは、ＰＬＲノードから保護経路上でＨＥＬＬＯ確認応答メッセージを受信して、ＨＥＬＬＯセッションを完了する。なお、ＨＥＬＬＯセッションは、トラフィックの保護経路上への切り替えに先立って確立されてもよい（ブロック４０２、４０３、及び４０４）。

ブロック４０５において、リスタートの要求に応じて、ＭＰノードは、ＨＥＬＬＯセッションにおいて交換されるＨＥＬＬＯメッセージから取得される情報を用いて、ＦＲＲが有効である間に、グレースフルリスタート動作を実行する。

図５は、本発明の１つの実施形態に係るネットワークエレメントを説明するブロック図である。ネットワークエレメント７００は、図１に示されるネットワークノードのいずれとして実装されてもよい。ネットワークエレメント７００は、例えば、上述されるＰＬＲノード又はＭＰノードであってよい。図５を参照すると、ネットワークエレメント７００は、限定ではないが、メッシュ７０５上の１つ以上のラインカード７０２−７０３（インタフェースカード又はユーザプレーンとも呼ばれる）に通信可能に連結される制御カード７０１（制御プレーンとも呼ばれる）を含み、メッシュ７０５は、メッシュネットワーク、相互接続、バス、又はそれらの組合せであってよい。ラインカードは、データプレーンとも呼ばれる（転送プレーン又はメディアプレーンと呼ばれることもある）。ラインカード７０２−７０３の各々は、それぞれインタフェース７０６−７０７のような１つ以上のインタフェース（ポートとも呼ばれる）と関連付けられる。各ラインカードは、ルーティング機能のブロック又はロジック（例えば、ブロック７０９−７１０）を含み、ルーティング機能のブロック又はロジックは、インタフェース７１１（例えば、コマンドラインインタフェース、即ちＣＬＩ）を介して管理者によって設定され得る制御カード７０１によって設定される構成（例えば、ルーティングテーブル）に従って、パケットをルーティングし、及び／又は対応するインタフェースを介してパケットを転送する。

１つの実施形態によれば、制御カード７０１は、限定ではないが、障害検出ユニット７３０と、ＦＲＲユニット７３１と、ＨＥＬＬＯユニット７３２と、データベース７０８とを含む。障害検出ユニット７３０は、特定のリンク又は特定のノードに障害が生じているか否かを、上述のＲＦＣにおいて説明されるような様々な通信プロトコルを用いて検出するよう適応される。リンク又はノード障害に応じて、ＦＲＲユニットは、上述のＲＦＣにおいて説明されるように、ＦＲＲ方式に基づいて、ネットワークトラフィックを保護経路（例えば、バイパスＬＳＰトンネル）上へ切り替えるよう適応される。ＨＥＬＬＯユニット７３２は、ネットワークエレメント７００に直接隣接しないリモートノード（例えば、ＭＰノード又はＰＬＲノード）とのＨＥＬＬＯセッションを、１よりも大きい、好適には２５５の、ＴＴＬ値を有するＨＥＬＬＯメッセージをリモートノードと交換することによって確立するよう適応される。結果として、従来のＨＥＬＬＯセッションとは違って、保護されるＬＳＰのある状態（例えば、接続状態）の情報を維持して、ＦＲＲが有効である間にノードがグレースフルリスタートすることを可能とするために、ＨＥＬＬＯメッセージが非直接的に隣接するノードに達することを、本発明の実施形態は、可能とする。

再び図５を参照すると、ネットワークエレメント７００がルータである（又は、ルーティング機能を実装している）場合、制御プレーン７０１は、典型的には、いかにデータ（例えば、パケット）がルーティングされるべきか（例えば、当該データについての次のホップ及びそのデータについての発信ポート）を判定し、データプレーン（例えば、ラインカード７０２−７０３）は、そのデータの転送を担う。例えば、他のネットワークエレメントと通信して、ルートを交換し、１つ以上のルーティングメトリックに基づいてこれらルートを選択する、１つ以上のルーティングプロトコル（例えば、ＢＧＰ（Border Gateway Protocol）、ＩＧＰ（Interior Gateway Protocol）（例えば、ＯＳＰＦ（Open Shortest Path First）、ＲＩＰ（Routing Information Protocol）、ＩＳ−ＩＳ（Intermediate System to Intermediate System）など）、ＬＤＰ（Label Distribution Protocol）、ＲＳＶＰ（Resource Reservation Protocol）など）を、制御プレーン７０１は、典型的には含む。

ルート及び近隣ノード（adjacencies）は、制御プレーン（例えば、データベース７０８）上の１つ以上のルーティング構造（例えば、ＲＩＢ（Routing Information Base）、ＬＩＢ（Label Information Base）、１つ以上の近隣ノード構造、など）において記憶される。制御プレーン７０１は、ルーティング構造に基づく情報（例えば、近隣ノード及びルート情報）をもってデータプレーン（例えば、ラインカード７０２−７０３）をプログラムする。例えば、制御プレーン７０１は、データプレーン上の１つ以上の転送構造（例えば、ＦＩＢ（Forwarding Information Base）、ＬＦＩＢ（Label Forwarding Information Base）、及び１つ以上の近隣ノード構造）に、近隣ノード及びルート情報をプログラムする。データプレーンは、トラフィックを転送する際、これら転送構造及び近隣ノード構造を使用する。

ルーティングプロトコルの各々は、あるルートメトリック（メトリックは、異なるルーティングプロトコルについて異なってよい）に基づいて、ルートエントリをメインＲＩＢ（routing information base）へダウンロードする。ルーティングプロトコルの各々は、ローカルＲＩＢ（例えば、ＯＳＰＦのローカルＲＩＢ）において、メインＲＩＢへダウンロードされないルートエントリを含むルートエントリを、記憶することができる。メインＲＩＢを管理するＲＩＢモジュールは、（メトリックのセットに基づいて）ルーティングプロトコルによって、ダウンロードされるルートからルートを選択し、選択されるこれらルート（アクティブルートエントリと呼ばれることもある）をデータプレーンへダウンロードする。ＲＩＢモジュールによって、ルートをルーティングプロトコル間に再分配することもできる。レイヤ２転送について、ネットワークエレメント７００は、１つ以上のブリッジングテーブルを記憶することができ、これを使用して、データを、このデータ内のレイヤ２情報に基づいて転送する。

図５において、説明のみを目的として、１つの制御カード及び２つのラインカードのみが示されている。典型的には、ネットワークエレメントは、１つ以上のラインカードのセットと、１つ以上の制御カードのセットと、オプションとして１つ以上のサービスカード（リソースカードと呼ばれることもある）のセットとを含む。これらカードは、１つ以上の仕組み（例えば、ラインカードを連結する第１のフルメッシュ及び全てのカードを連結する第２のフルメッシュ）を通じて共に連結される。ラインカードのセットは、データプレーンを構成し、一方制御カードのセットは、制御プレーンを提供して、ラインカードを通じて外部のネットワークエレメントとパケットを交換する。サービスカードのセットは、特化された処理（例えば、レイヤ４〜レイヤ７のサービス（例えば、ファイアウォール、ＩＰｓｅｃ、ＩＤＳ、Ｐ２Ｐ）、ＶｏＩＰセッションボーダコントローラ、モバイル無線ゲートウェイ（ＧＧＳＮ、ＥＰＳ（Evolved Packet System）ゲートウェイ）など）を提供することができる。例として、サービスカードを使用して、ＩＰｓｅｃのトンネルを終端し、受付認証（attendant authentication）を実行し、アルゴリズムを暗号化し得る。ここで使用されるように、ネットワークエレメント（例えば、ルータ、スイッチ、ブリッジ、など）は、ネットワーク上の他の機器（例えば、他のネットワークエレメント、終端局、など）と通信可能に相互接続する、ハードウェア及びソフトウェアを含むネットワーク機器の一部である。いくつかのネットワークエレメントは、複数のネットワーク機能（例えば、ルーティング、ブリッジング、スイッチング、レイヤ２集約、セッションボーダ制御、サービス品質、及び／又は加入者管理）についてのサポートを提供し、及び／又は複数のアプリケーションサービス（例えば、データ、音声、及びビデオ）についてのサポートを提供する、“複数サービスのネットワークエレメント”である。

加入者終端局（例えば、サーバ、ワークステーション、ラップトップ、パームトップ、携帯電話、スマートフォン、マルチメディアフォン、ＶＯＩＰ（Voice Over Internet Protocol）フォン、携帯型メディアプレイヤー、ＧＰＳ（global positioning system）ユニット、ゲームシステム、セットトップボックス、など）は、インターネット上で提供されるコンテンツ／サービス、及び／又はインターネット上に敷かれるＶＰＮ（virtual private networks）上で提供されるコンテンツ／サービスにアクセスする。コンテンツ、及び／又はサービスは、サービス又はコンテンツプロバイダに属する１つ以上の終端局（例えば、サーバ終端局）、若しくはピアツーピアサービスに参加している終端局によって典型的に提供され、パブリックウェブページ（フリーコンテンツ、ストアフロント、検索サービス、など）、プライベートウェブページ（例えば、Ｅメールサービスなどを提供するユーザネーム／パスワードによりアクセスされるウェブページ）、ＶＰＮ上の企業ネットワーク、などを含み得る。典型的には、加入者終端局は、エッジネットワークエレメントに（例えば、アクセスネットワークに（有線又は無線で）連結されるＣＰＥ（customer premise equipment）を通じて）連結され、当該エッジネットワークエレメントは、他の終端局（例えば、サーバ終端局）に連結される他のエッジネットワークエレメントに（例えば、１つ以上のコアネットワークエレメントを通じて）連結される。

先の詳細な説明のいくつかの部分は、コンピュータメモリ内のデータビット上の動作のアルゴリズム及びシンボル表現の観点で提示されている。これらアルゴリズム的な説明及び表現は、データプロセシングの分野における当業者によって、他の当業者へ最も効果的にその内容を伝達するために使用されるやり方である。アルゴリズムは、ここでは、そして一般的には、望ましい結果へ導く動作の首尾一貫したシーケンスであると考えられる。動作は、物理量の物理的操作を要求するものである。必ずしもというわけではないが、通常、これらの量は、記憶され、送信され、結合され、比較され、それ以外のやり方で操作されることが可能な、電気的又は磁気的信号の形態をとる。主に一般的な使用のために、これら信号をビット、値、エレメント、記号、文字、用語、数などと呼ぶことは、時として都合が良いことがわかっている。

一方、全てのこれらの及び同様の用語は、適当な物理量と関連付けられるべきであり、これら量に適用される単なる便宜上のラベルであるということは、念頭に置かれるべきである。上の議論から明らかである以外に具体的に記述されなければ、本説明を通して、以下の特許請求の範囲において説明されるような用語を用いる議論は、コンピュータシステム、又はコンピュータシステムのレジスタ及びメモリ内の物理（電気）量として表されるデータを、操作し、コンピュータシステムのメモリ、若しくはレジスタ、若しくは他のそのような情報ストレージ、送信信号、若しくはディスプレイデバイス内の物理量として同様に表される他のデータに変換する、同様の電気的な計算デバイスの、アクション及び処理についてものであると理解される。

本発明の実施形態は、ここでの動作を実行するための装置にも関する。この装置は、要求される目的のために特別に構築されてもよく、又はコンピュータ内に記憶されるコンピュータプログラムによって選択的にアクティブ化され、若しくは再構成される汎用コンピュータを含んでもよい。そのようなコンピュータプログラムは、コンピュータ読取可能な媒体内に記憶され得る。マシン読取可能な媒体は、マシン（例えば、コンピュータ）によって読取可能な形態で情報を記憶するための任意の仕組みを含む。例えば、マシン読取可能な（例えば、コンピュータ読取可能な）媒体は、マシン（例えば、コンピュータ）読取可能な記憶媒体（例えば、“ＲＯＭ”（read only memory）、“ＲＡＭ”（random access memory）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、など）などを含む。

ここで提示されるアルゴリズム及び表示は、いかなる特定のコンピュータ又は他の装置とも本質的に関係しない。様々な汎用システムがここでの技術に従ったプログラムと共に使用されてもよく、又は要求される方法の動作を実行するためにより特化された装置を構築することが、都合が良いとわかるかもしれない。様々なこれらシステムについて要求される構造は、上の説明から明らかであろう。加えて、本発明の実施形態は、いかなる特定のプログラミング言語をも参照して説明されない。様々なプログラミング言語を使用して、ここで説明される本発明の実施形態の技術を実装し得ることは、明らかであろう。

ここまでの明細書において、本発明の実施形態は、それらの具体的な例となる実施形態を参照して説明されている。次の特許請求の範囲において説明される本発明のより広い思想及び範囲から逸脱することなく、様々な変更が施され得ることは明白であろう。従って、本明細書及び図面は、限定的な意味ではなく説明的な意味でとらえられるべきである。

また、ＦＲＲが有効である際に、保護されるＬＳＰの経路メッセージをバイパストンネル上で受信することによって、リモートノードを、リンク／ノードに障害が生じた後に発見することができる。ＭＰノードは、経路メッセージを受信し、ＨＥＬＬＯ要求オブジェクトを伴うＨＥＬＬＯメッセージをバイパスの入口ノードへ向けて送信することによって、ＨＥＬＬＯセッションを開始し得る。ＨＥＬＬＯメッセージは、ＩＰ転送を介して送信される。バイパストンネルの入口ノード上でＨＥＬＬＯ要求オブジェクトを伴うＨＥＬＬＯメッセージが受信されると、入口ノードは、バイパストンネルの出口ノードへ向けてＨＥＬＬＯ Ａｃｋオブジェクトを伴うＨＥＬＬＯメッセージを送信する。バイパストンネルの出口ノードがＨＥＬＬＯ Ａｃｋオブジェクトを伴うＨＥＬＬＯメッセージを受信すると、バイパストンネルの入口ノードと出口ノードとの間でＨＥＬＬＯセッションが確立される。

Claims (20)

1. リモートノードのリスタートを考慮してネットワークエレメント内でリスタート手続を実行することを目的として、前記ネットワークエレメントと前記リモートノードとの間の１つ以上の保護されるラベルスイッチパス（ＬＳＰ）の状態情報を維持し及び回復するために、前記ネットワークエレメントに直接隣接しない前記リモートノードとのＨＥＬＬＯセッションを確立して、前記ＨＥＬＬＯセッションの間に交換されるＨＥＬＬＯメッセージに基づいて前記リモートノードがリスタートするかを判定する、前記ネットワークエレメント内で実行されるマシン実装される方法であって、
   前記ネットワークエレメントに直接隣接しない前記リモートノードの構成及び自動発見のうち１つに応じて、前記保護されるＬＳＰのリンク／ノード障害に先立って、前記リモートノードとのＨＥＬＬＯセッションを確立するステップと、当該ステップは、リモートノードとのＨＥＬＬＯメッセージの交換を含むことと、
   各ＨＥＬＬＯメッセージは、ＩＰ（Internet Protocol）転送プロトコルを用いてルーティングされる場合には、１よりも大きい値であるＴＴＬ（time-to-live）を含み、ローカルノードと前記リモートノードとの間で確立されるトンネルを介して転送される場合には、１であるＴＴＬ値を含むことと、
   前記保護されるＬＳＰのリンク障害及びノード障害のうち少なくとも１つに応じて、高速リルーティング（ＦＲＲ）方式に従って前記保護経路上へネットワークトラフィックを切り替えるステップと、
   前記保護されるＬＳＰの前記リンク／ノード障害に先立って前記ＨＥＬＬＯセッションが確立されていなければ、前記ネットワークエレメントに直接隣接しない前記リモートノードとの前記ＨＥＬＬＯセッションを確立するステップと、当該ステップは、リモートノードとのＨＥＬＬＯメッセージの交換を含むことと、
   各ＨＥＬＬＯメッセージは、ＩＦ転送プロトコルに基づいてルーティングされる場合には、１よりも大きい値であるＴＴＬを含み、バイパストンネルを介して転送される場合には、１であるＴＴＬ値を含むことと、
   前記ＨＥＬＬＯセッションの間に交換される前記ＨＥＬＬＯメッセージに基づいて、前記リモートノードのリスタートに応じて、前記保護されるＬＳＰのＬＳＰ状態情報の維持及び回復のために、ＲＳＶＰ（resource reservation protocol） ＴＥ（traffic engineering）グレースフルリスタート（ＲＳＶＰ−ＴＥ ＧＲ）の仕組みに従ってリスタート手続を実行するステップと、
   を含む方法。
2. 前記ＨＥＬＬＯメッセージが中間ノードのいずれによってもドロップされないように、前記ＨＥＬＬＯメッセージの前記ＴＴＬ値は、前記ネットワークエレメントと前記リモートノードとの間の前記中間ノードの数に少なくとも等しく、又はより大きく設定される、請求項１の方法。
3. 前記ネットワークエレメントは、ローカルリペアポイント（ＰＬＲ）ノードであり、前記リモートノードは、前記保護されるＬＳＰのマージポイント（ＭＰ）ノードであり、前記ＰＬＲノードと前記ＭＰノードとの間の前記保護経路には、少なくとも１つの中間ノードが存在する、請求項１の方法。
4. 前記保護経路上で前記ＦＲＲ方式が有効である間に、前記ＨＥＬＬＯメッセージセッションが確立され、前記リスタート手続が実行される、請求項１の方法。
5. 前記ＨＥＬＬＯセッションは、前記リモートノードを隣接するノードとして静的に設定する必要なく、前記ネットワークエレメントにより確立される、請求項１の方法。
6. リモートノードのリスタートを考慮してネットワークエレメント内でリスタート手続を実行することを目的として、前記ネットワークエレメントと前記リモートノードとの間の保護されるラベルスイッチパス（ＬＳＰ）の状態情報を維持するために、前記ネットワークエレメントに直接隣接しない前記リモートノードとのＨＥＬＬＯセッションを確立して、前記ＨＥＬＬＯセッションの間に交換されるＨＥＬＬＯメッセージに基づいて前記リモートノードがリスタートするかを判定するためのネットワークエレメントであって、
   前記保護されるＬＳＰのリンク障害及びノード障害のうち少なくとも１つに応じて、保護経路を選択し、及び、高速リルーティング（ＦＲＲ）方式に従って前記保護経路上へネットワークトラフィックを切り替える、高速リルーティング（ＦＲＲ）ユニットと、
   前記ＦＲＲユニットに連結され、前記ネットワークエレメントに直接隣接しない前記リモートノードとのＨＥＬＬＯセッションを確立するＨＥＬＬＯハンドリングユニットと、当該確立することは、前記保護経路上における前記リモートノードとの１つ以上のＨＥＬＬＯメッセージの交換を含むことと、
   各ＨＥＬＬＯメッセージは、ＩＰ（Internet Protocol）転送プロトコルに基づいてルーティングされる場合には、１よりも大きいＴＴＬ（time-to-live）値を含み、前記ネットワークエレメントと前記リモートノードとの間のトンネルを介して送信される場合には、１であるＴＴＬ値を含むことと、
   前記ＦＲＲユニットと前記ＨＥＬＬＯハンドリングユニットとに連結され、前記ＨＥＬＬＯセッションの前記１つ以上のＨＥＬＬＯメッセージに基づいて維持される前記保護されるＬＳＰのＬＳＰ状態情報を用いて、前記ＨＥＬＬＯセッションの間に交換される前記１つ以上のＨＥＬＬＯメッセージに基づいて、前記リモートノードのリスタートに応じて、ＲＳＶＰ（resource reservation protocol） ＴＥ（traffic engineering）グレースフルリスタート（ＲＳＶＰ−ＴＥ ＧＲ）のプロトコルに従ってリスタート手続を実行するリスタートユニットと、
   を備える、ネットワークエレメント。
7. 前記ＨＥＬＬＯメッセージが中間ノードのいずれによってもドロップされないように、前記ＨＥＬＬＯメッセージの前記ＴＴＬ値は、前記ネットワークエレメントと前記リモートノードとの間の前記中間ノードの数に少なくとも等しく、又はより大きく設定される、請求項６のネットワークエレメント。
8. 前記ネットワークエレメントは、ローカルリペアポイント（ＰＬＲ）ノードであり、前記リモートノードは、前記保護されるＬＳＰのマージポイント（ＭＰ）ノードであり、前記ＰＬＲノードと前記ＭＰノードとの間の前記保護経路には、少なくとも１つの中間ノードが存在する、請求項６のネットワークエレメント。
9. 前記保護経路上で前記ＦＲＲ方式が有効である間に、前記ＨＥＬＬＯメッセージセッションが確立され、前記リスタート手続が実行される、請求項６のネットワークエレメント。
10. 前記ＨＥＬＬＯセッションは、前記リモートノードを隣接するノードとして静的に設定する必要なく、前記ネットワークエレメントにより確立される、請求項６のネットワークエレメント。
11. リモートノードのリスタートを考慮してネットワークエレメント内でリスタート手続を実行することを目的として、前記ネットワークエレメントと前記リモートノードとの間の保護されるラベルスイッチパス（ＬＳＰ）の状態情報を維持するために、前記ネットワークエレメントに直接隣接しない前記リモートノードとのＨＥＬＬＯセッションを確立して、前記ＨＥＬＬＯセッションの間に交換されるＨＥＬＬＯメッセージに基づいて前記リモートノードがリスタートするかを判定する、前記ネットワークエレメント内で実行されるマシン実装される方法であって、
    前記リモートノードから、ＩＰ転送、又は前記ネットワークエレメントとリモートノードとの間のバイパストンネルを介して、前記保護されるＬＳＰを保護するように構成される経路メッセージを受信するステップと、
    前記保護されるＬＳＰのリンク障害／ノード障害に応じて、高速リルーティング（ＦＲＲ）方式を用いて、前記保護経路上へネットワークトラフィックが切り替えられていることと、
    前記経路メッセージに応じて、前記ネットワークエレメントに直接隣接しない前記リモートノードとのＨＥＬＬＯセッションを確立するステップと、当該ステップは、前記保護経路上における前記リモートノードとのＨＥＬＬＯメッセージの交換を含むことと、
    各ＨＥＬＬＯメッセージは、ＩＰ転送を介してルーティングされる場合には、１よりも大きいＴＴＬ（time-to-live）値を含み、前記ネットワークエレメントと前記リモートノードとの間で確立されるトンネルを介して転送される場合には、１であるＴＴＬ値を含むことと、
    前記ＨＥＬＬＯセッションの間に交換される前記ＨＥＬＬＯメッセージに基づいて、前記リモートノードのリスタートに応じて、前記ＨＥＬＬＯセッションの１つ以上の前記ＨＥＬＬＯメッセージに基づいて維持される前記保護されるＬＳＰのＬＳＰ状態情報を用いて、ＲＳＶＰ（resource reservation protocol） ＴＥ（traffic engineering）グレースフルリスタート（ＲＳＶＰ−ＴＥ ＧＲ）プロトコルに従ってリスタート手続を実行するステップと、
    を含む、方法。
12. 前記ＨＥＬＬＯメッセージが中間ノードのいずれによってもドロップされないように、前記ＨＥＬＬＯメッセージの前記ＴＴＬ値は、前記ネットワークエレメントと前記リモートノードとの間の前記中間ノードの数に少なくとも等しく、又はより大きく設定される、請求項１１の方法。
13. 前記ネットワークエレメントは、マージポイント（ＭＰ）ノードであり、前記リモートノードは、前記保護されるＬＳＰのローカルリペアポイント（ＰＬＲ）ノードであり、前記ＰＬＲノードと前記ＭＰノードとの間の前記保護経路には、少なくとも１つの中間ノードが存在する、請求項１１の方法。
14. 前記保護経路上で前記ＦＲＲ方式が有効である間に、前記ＨＥＬＬＯメッセージセッションが確立され、前記リスタート手続が実行される、請求項１１の方法。
15. 前記ＨＥＬＬＯセッションは、前記リモートノードを隣接するノードとして静的に設定する必要なく、前記ネットワークエレメントにより確立される、請求項１１の方法。
16. リモートノードのリスタートを考慮してネットワークエレメント内でリスタート手続を実行することを目的として、前記ネットワークエレメントと前記リモートノードとの間の保護されるラベルスイッチパス（ＬＳＰ）の状態情報を維持するために、前記ネットワークエレメントに直接隣接しない前記リモートノードとのＨＥＬＬＯセッションを確立して、前記ＨＥＬＬＯセッションの間に交換されるＨＥＬＬＯメッセージに基づいて前記リモートノードがリスタートするかを判定するためのネットワークエレメントであって、
    前記リモートノードから、ＩＰ転送、及びバイパストンネルのうち１つを介して、前記保護されるＬＳＰを保護するように構成される経路メッセージを受信する受信機と、
    前記保護されるＬＳＰのリンク障害及びノード障害のうち少なくとも１つに応じて、高速リルーティング（ＦＲＲ）方式を用いて、前記保護経路上へネットワークトラフィックが切り替えられていることと、
    前記受信機に連結され、前記経路メッセージに応じて、前記ネットワークエレメントに直接隣接しない前記リモートノードとのＨＥＬＬＯセッションを確立するＨＥＬＬＯハンドリングユニットとし、当該確立することは、前記保護経路上における前記リモートノードとの１つ以上のＨＥＬＬＯメッセージの交換を含むことと、
    各ＨＥＬＬＯメッセージは、ＩＰ転送を介してルーティングされる場合には、１よりも大きいＴＴＬ（time-to-live）値を含み、前記ネットワークエレメントと前記リモートノードとの間で確立されるトンネルを介して転送される場合には、１であるＴＴＬ値を含むことと、
    前記ＨＥＬＬＯハンドリングユニットに連結され、前記ＨＥＬＬＯセッションの前記１つ以上のＨＥＬＬＯメッセージに基づいて維持される前記保護されるＬＳＰのＬＳＰ状態情報を用いて、前記ＨＥＬＬＯセッションの間に交換される前記１つ以上のＨＥＬＬＯメッセージに基づいて、前記リモートノードのリスタートに応じて、ＲＳＶＰ（resource reservation protocol） ＴＥ（traffic engineering）グレースフルリスタート（ＲＳＶＰ−ＴＥ ＧＲ）プロトコルに従ってリスタート手続を実行するリスタートユニットと、
    を備える、ネットワークエレメント。
17. 前記ＨＥＬＬＯメッセージが中間ノードのいずれによってもドロップされないように、前記１つ以上のＨＥＬＬＯメッセージの前記ＴＴＬ値は、前記ネットワークエレメントと前記リモートノードとの間の前記中間ノードの数に少なくとも等しく、又はより大きく設定される、請求項１６のネットワークエレメント。
18. 前記ネットワークエレメントは、マージポイント（ＭＰ）ノードであり、前記リモートノードは、前記保護されるＬＳＰのローカルリペアポイント（ＰＬＲ）ノードであり、前記ＰＬＲノードと前記ＭＰノードとの間の前記保護経路には、少なくとも１つの中間ノードが存在する、請求項１６のネットワークエレメント。
19. 前記保護経路上で前記ＦＲＲ方式が有効である間に、前記ＨＥＬＬＯメッセージセッションが確立され、前記リスタート手続が実行される、請求項１６のネットワークエレメント。
20. 前記ＨＥＬＬＯセッションは、前記リモートノードを隣接するノードとして静的に設定する必要なく、前記ネットワークエレメントにより確立される、請求項１６のネットワークエレメント。

Images