(57)【特許請求の範囲】
【請求項１】
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの始点に位置する通信装置であって、
第１の通信パスの始点から終点までの帯域、及び、第１の通信パスの一部区間の予備として第２の通信パスの始点から終点までの帯域が確立されているか否かを確認する確認部と、
前記確認部が前記第１の通信パスの始点から終点までの帯域及び前記第１の通信パスの一部区間の予備として前記第２の通信パスの始点から終点までの帯域が確立されていることを確認したとき、前記第１の通信パスの一部区間の帯域を維持するための経路維持情報を生成する経路情報管理部と、
第１の通信パス上の終点側に隣接する通信装置に、前記経路情報管理部が生成した前記経路維持情報を送信する送信部と、
を有する通信装置。
【請求項２】
前記第１の通信パス上の終点側に隣接する通信装置から、前記第１の通信パス上の終点側に隣接する通信装置より終点側でリンク障害が発生したことを示す経路エラー情報を受信する受信部を備え、
前記確認部が、第１の通信パスの始点から終点までの帯域と、第１の通信パスの一部区間の予備として第２の通信パスの始点から終点までの帯域とが確立されていることを確認し、かつ、前記受信部が、前記第１の通信パス上の終点側に隣接する通信装置から、前記第１の通信パス上の終点側に隣接する通信装置より終点側でリンク障害が発生したことを示す経路エラー情報を受信したとき、前記送信部は、前記第１の通信パス上の終点側に隣接する通信装置に、経路維持情報を送信する、
請求項１に記載の通信装置。
【請求項３】
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの始点と終点との間の第１の通信パス上に位置する通信装置であって、
第１の通信パス上の始点側に隣接する通信装置から、第１の通信パスの一部区間の帯域を維持するための経路維持情報を受信する受信部と、
前記経路維持情報を格納する経路情報管理部と、
第１の通信パス上の終点側に隣接する通信装置に、前記経路維持情報を送信する送信部と、
を有する通信装置。
【請求項４】
前記第１の通信パス上の始点側に隣接する通信装置との間でリンク障害が発生した場合、前記送信部は、第１の通信パス上の終点側に隣接する通信装置に、前記経路情報管理部に格納された経路維持情報を送信する、
請求項３に記載の通信装置。
【請求項５】
前記受信部が、前記第１の通信パス上の終点側に隣接する通信装置から、第１の通信パス
の帯域の削除要求情報を受信した場合、前記経路情報管理部は、前記経路維持情報を削除する、
請求項３または４に記載の通信装置。
【請求項６】
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの終点に位置する通信装置であって、
第１の通信パス上の始点側に隣接する通信装置から、第１の通信パスの一部区間の帯域を維持するための経路維持情報を受信する受信部と、
前記経路維持情報を格納する経路情報管理部と、
を有する通信装置。
【請求項７】
第２の通信パスの始点と終点との間の第１の通信パス上でリンク障害が発生し、前記経路情報管理部が前記経路維持情報を格納し、かつ、前記受信部が前記第２の通信パスの通信装置から第１の通信パスの帯域の削除要求情報を受信したとき、第１の通信パス上の始点側に隣接する通信装置に、前記削除要求情報を送信する送信部を備える、
請求項６に記載の通信装置。
【請求項８】
始点及び終点を有する第１の通信パスと、第１の通信パスからみた分岐点及び合流点が始点及び終点として規定され、且つこれらの分岐点から合流点までで規定される第１の通信パスの中間部分をバイパスするように作成される第２の通信パスとを有し、前記中間部分に障害が生じていない場合には、前記第１の通信パスの始点から送信されるデータが前記中間部分を経由して前記第１の通信パスの終点に転送されるネットワークシステムにおいて、
前記中間部分の障害を検出する検出部と、
前記中間部分の障害が検出された場合に、前記第１の通信パスの始点から終点までのデータの転送経路の一部を前記中間部分から前記第２の通信パスに切り替え、前記中間部分の障害から復旧した場合に、前記第１の通信パスの始点から終点までのデータの転送経路の一部を前記第２の通信パスから前記中間部分に切り戻す切替制御部と、
前記中間部分の障害発生から復旧までの間において、前記中間部分の障害未発生部分に関する前記第１の通信パス用のリソース解放を禁止する禁止部と、
を備えるネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＭＰＬＳ（Multi Protocol Label Switching）ネットワークにおける通信装置およびネットワークシステムに関する。特に、ＲＳＶＰ−ＴＥ（Resource Reservation
Protocol: Traffic Extension）を用いたＦＲＲ（Fast ReRoute、facility backup方式
）用の通信パス（ＬＳＰ（Label Switched Path）と呼ばれる）をセットアップして、Local Revertive方式による切り戻しを行う通信装置およびネットワークシステムに関する。
【背景技術】
【０００２】
ＭＰＬＳは、ラベルスイッチング方式を用いたパケット転送技術である。ＭＰＬＳでは、ルータが他のルータから受け取ったパケットを別のルータに転送する際に、ルーティング情報としてＩＰヘッダの代わりに短い固定長の識別標識（ラベル）を利用する。ＭＰＬＳのルーティング方式として、ＦＲＲがある。ＦＲＲは、ＭＰＬＳネットワークにおいて、予備経路として使用するための通信経路をあらかじめ用意し、使用している通信経路に障害が発生したときに、予備経路に切り替えて、通信を復旧させる方式である。ＦＲＲによれば、予備経路をあらかじめ用意することで、迅速に通信障害の復旧を行うことができる。
【０００３】
図１は、通常状態のネットワークの構成例を示す図である。ＭＰＬＳネットワークでは、ＰＳＶＰ‐ＴＥシグナリングを使用したＦＲＲ用のＬＳＰとして、Protected LSP（保
護されるＬＳＰ（現用系ＬＳＰ））とBackup LSP（Protected LSP障害時の迂回ルート（
予備系ＬＳＰ））をセットアップする。図１では、Protected LSP（ＬＳＰ＃１）が、ノ
ードＨから、ノードＡ、ノードＢ、ノードＣを経由して、ノードＴまでセットアップされている。また、Backup LSP（ＬＳＰ＃２）が、ノードＡからノードＤを経由してノードＣまでセットアップされている。
【０００４】
ここで、ＬＳＰの先頭ノード（図１において、ＬＳＰ＃１の場合はノードＨ、ＬＳＰ＃２の場合はノードＡ）をIngressノードといい、ＬＳＰの終点ノード（図１において、Ｌ
ＳＰ＃１の場合はノードＴ、ＬＳＰ＃２の場合はノードＣ）をEgressノードという。また、ＬＳＰの分岐点にあたるノード（図１において、ノードＡ）をＰＬＲ（Point of Local
Repair）といい、ＬＳＰの合流ポイントにあたるノード（図１において、ノードＣ）を
ＭＰ（Merge Point）という。
【０００５】
ノードＡにはＰＬＲであること、ノードＣにはＭＰであることが明示的に設定されており、その後、各ＬＳＰが設定される。Protected LSPは、IngressノードであるノードＨに対して、ノードＨから、ノードＡ、ノードＢ、ノードＣを経由して、EgressノードであるノードＴまでの経路情報が与えられることで、セットアップされる。
【０００６】
また、同様に、Backup LSPは、IngressノードであるノードＡに対して、ノードＡから
、ノードＤを経由して、EgressノードであるノードＣまでの経路情報が与えられることで、セットアップされる。その後、ＰＬＲ（ノードＡ）は、Protected LSPとBackup LSPと
の対応関係、すなわち、Protected LSP（ＬＳＰ＃１）とBackup LSP（ＬＳＰ＃２）との
ペアの関係を作成する。
【０００７】
この結果、Protected LSP上の保護区間（ノードＡ‐ノードＢ‐ノードＣ間）において
、ノードＡとノードＢとの間のリンク障害、ノードＢとノードＣとの間のリンク障害、又は、ノードＢのノード障害が、発生した時の迂回ルートが作成されたことになる。
【０００８】
通常時、ノードＨからのデータトラフィックは、Protected LSPを通ってノードＴまで
運ばれる。
【０００９】
図２７は、ＦＲＲのリンク障害発生時の動作概要を示す図である。図２７に示すように、保護区間であるノードＡとノードＢとの間でリンク障害が発生したとする。ＰＬＲ（ノードＡ）が、このリンク障害を認識すると、ノードＨからのデータトラフィックをBackup
LSP側に切り替える。ＭＰ（ノードＣ）は、ノードＤを経由して入ってきたデータトラフィックをノードＴに向けて送信する。このようにして、ノードＨからのデータトラフィックは、保護区間のリンク障害時に迂回ルートであるBackup LSPを経由してノードＴまで運ばれる。この切替動作が高速に実施できることから、ＦＲＲ（Fast ReRoute）と呼ばれる。
【００１０】
図２８は、ＦＲＲのリンク障害復旧時の動作概要を示す図である。保護区間であるノードＡとノードＢとの間のリンク障害が復旧（解消）したとする。ＰＬＲが、このリンク障害の復旧を認識し、シグナリングにより再度ノードＡとノードＢとの間が正常になったことを確認すると、ノードＨからのデータトラフィックを、Backup LSP側からProtected LSP側に切り戻す。ノードＨからのデータトラフィックは、ノードＨから、ノードＡ、ノー
ドＢ、ノードＣを経由してノードＴまで運ばれる。
【００１１】
このような切り戻しのことを、Local Revertive方式という。Backup LSPは、Protected
LSPより（遅延や帯域に関して）最適な経路ではない可能性がある。よって、（遅延や帯域に関して）常に最適な経路でデータトラフィックを送信するため、Backup LSPからProtected LSPに切り戻しを行う。
【００１２】
図２９は、保護区間において障害発生中に新たなＬＳＰがセットアップされる場合の動作の例を示す図である。図２９では、ノードＡとノードＢとの間にリンク障害が発生している。リンク障害発生中は、Protected LSPのIngressノードであるノードＨからのデータトラフィックは、ノードＨから、ノードＡ、ノードＤ、ノードＣを経由してEgressノードであるノードＴまで送信される。このとき、ノードＢとノードＣとの間のリソースは、開放される。この後、ノードＸをIngressノードとし、ノードＸから、ノードＢ、ノードＣ
を経由してEgressノードであるノードＹまでのＬＳＰ＃３をセットアップしようとすると、ノードＢとノードＣとの間のリソースが空いているため、正常にセットアップされる。
【特許文献１】特開２００５−３９３６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
図３０は、保護区間において障害発生中に新たなＬＳＰがセットアップされたことによりリソース競合が起きる場合の動作の例を示す図である。図２９で示したように、ノードＸをIngressノードとし、ノードＸから、ノードＢ、ノードＣを経由して、Egressノード
であるノードＹまでのＬＳＰ＃３がセットアップされている。
【００１４】
図３０のノードＡとノードＢとの間で発生していたリンク障害が復旧（解消）した時、復旧を認識したＰＬＲ（ノードＡ）がノードＢにProtected LSP用のPath Messageを送信
する。このPath Messageを受信したノードＢは、ノードＢとノードＣとの間にリソースがないことから、Protected LSPがセットアップできないことをPath Error Messageでノー
ドＡに通知する。この結果、Local RevertiveするためのProtected LSPがセットアップされないことになり迂回したデータトラフィックを切り戻すことができなくなる。保護されているＬＳＰの障害発生時に、障害が発生していない下流のリソース（例えば、ノードＢとノードＣとの間のリソース）が解放（Path Tear）されるからである。
【００１５】
本発明の目的は、第1の通信パスと、第1の通信パスの中間部分をバイパスするように作成される第２の通信パスとを有し、中間部分の障害中、第1の通信パスの始点から送信さ
れるデータが中間部分の代わりの第２の通信パスを経由して第1の通信パスの終点に転送
されるネットワークシステムにおいて、障害復旧時に第２の通信パスから中間部分への切り戻しができなくなることを抑止する技術を提供することである。
【課題を解決するための手段】
【００１６】
本発明は、上記課題を解決するために、以下の手段を採用する。
【００１７】
即ち、本発明の第１の態様は、
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの始点に位置する通信装置であって、
第１の通信パスの始点から終点までの帯域、及び、第１の通信パスの一部区間の予備として第２の通信パスの始点から終点までの帯域が確立されているか否かを確認する確認部と、
前記確認部が前記第１の通信パスの始点から終点までの帯域及び前記第１の通信パスの一部区間の予備として前記第２の通信パスの始点から終点までの帯域が確保されていることを確認したとき、前記第１の通信パスの一部区間の帯域を維持するための経路維持情報を生成する経路情報管理部と、
第１の通信パス上の終点側に隣接する通信装置に、前記経路情報管理部が生成した前記経路維持情報を送信する送信部と、
を有する通信装置
である。
【００１８】
また、本発明の第２の態様は、
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの始点と終点との間の第１の通信パス上に位置する通信装置であって、
第１の通信パス上の始点側に隣接する通信装置から、第１の通信パスの一部区間の帯域を維持するための経路維持情報を受信する受信部と、
前記経路維持情報を格納する経路情報管理部と、
第１の通信パス上の終点側に隣接する通信装置に、前記経路維持情報を送信する送信部と、
を有する通信装置
である。
【００１９】
また、本発明の第３の態様は、
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークに
おける、第２の通信パスの終点に位置する通信装置であって、
第１の通信パス上の始点側に隣接する通信装置から、第１の通信パスの一部区間の帯域を維持するための経路維持情報を受信する受信部と、
前記経路維持情報を格納する経路情報管理部と、
を有する通信装置
である。
【００２０】
本発明の態様によると、主とする通信パスの一部区間に予備の通信パスが確保されている場合、予備の通信パスが確保されている区間の通信装置に対して、その旨を通知することができる。
【００２１】
また、本発明の第１の態様において、
前記第１の通信パス上の終点側に隣接する通信装置から、前記第１の通信パス上の終点側に隣接する通信装置より終点側でリンク障害が発生したことを示す経路エラー情報を受信する受信部を備え、
前記確認部が、第１の通信パスの始点から終点までの帯域と、第１の通信パスの一部区間の予備として第２の通信パスの始点から終点までの帯域とが確立されていることを確認し、かつ、前記受信部が、前記第１の通信パス上の終点側に隣接する通信装置から、前記第１の通信パス上の終点側に隣接する通信装置より終点側でリンク障害が発生したことを示す経路エラー情報を受信したとき、前記送信部は、前記第１の通信パス上の終点側に隣接する通信装置に、経路維持情報を送信する、
通信装置
とすることができる。
【００２２】
また、本発明の第２の態様において、
前記第１の通信パス上の始点側に隣接する通信装置との間でリンク障害が発生した場合、前記送信部は、第１の通信パス上の終点側に隣接する通信装置に、前記経路情報管理部に格納された経路維持情報を送信する、
とすることができる。
【００２３】
本発明の態様によると、第１の通信パス上でリンク障害が発生した場合、経路情報を送信し続けることで、第１の通信パス上の帯域を維持することができる。
【発明の効果】
【００２４】
本発明によれば、第1の通信パスと、第1の通信パスの中間部分をバイパスするように作成される第２の通信パスとを有し、中間部分の障害中、第1の通信パスの始点から送信さ
れるデータが中間部分の代わりの第２の通信パスを経由して第1の通信パスの終点に転送
されるネットワークシステムにおいて、障害復旧時に第２の通信パスから中間部分への切り戻しができなくなることを抑止する技術を提供することができる。
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００２６】
〔実施形態〕
図１は、通常状態のネットワークの構成例を示す図である。ＭＰＬＳネットワークでは、ＰＳＶＰ‐ＴＥシグナリングを使用したＦＲＲ用のＬＳＰとして、Protected LSP及びBackup LSPをセットアップする。図１では、Protected LSP（ＬＳＰ＃１）が、ノードＨから、ノードＡ、ノードＢ、ノードＣを経由して、ノードＴまでセットアップされている。また、Backup LSP（ＬＳＰ＃２）が、ノードＡからノードＤを経由してノードＣまでセッ
トアップされている。ノードＡはＰＬＲ（Point of Local Repair）であり、ノードＣは
ＭＰ（Merge Point）である。ＰＬＲはProtected LSPの分岐点に該当し、ＭＰはProtected LSPの合流点に該当する。また、Backup LSPは、Protected LSPのＰＬＲとＭＰとの間をバイパスする。
【００２７】
〈標準の動作例〉
最初に、図１の通信ネットワークの標準の動作例について説明する。
【００２８】
《Protected LSPのセットアップ》
図２は、Protected LSPのセットアップ方法を示す図である。ＬＳＰは、ＲＳＶＰ−Ｔ
Ｅというシグナリングプロトコルによってセットアップされる。シグナリングプロトコルは、ラベル配布用プロトコルである。シグナリングプロトコルは、Path MessageをIngressノードからEgressノードまで送信しながら、任意の経路で必要な帯域を要求しデータ転
送に必要なラベル要求を行う。また、シグナリングプロトコルは、Path Messageの応答であるResv Message（Reserve Message）をPath Messageと逆の経路をたどってEgressノー
ドからIngressノードまで送信しながら、必要な帯域を確保しラベル通知を行う。
【００２９】
Path MessageのObjectについて説明する。Path MessageのObjectは、Session Object（ＳＯ）、Fast Reroute Object（ＦＲＯ）、Session Attribute Object（ＳＡＯ）、Explicit Route Object（ＥＲＯ）、HOP Objectを含む。
【００３０】
ＳＯは、ＬＳＰのsessionを識別するObjectである。ＳＯには、ＬＳＰのIngressノードおよびEgressノードを示す情報（ＩＰアドレスなど）が格納されている。
【００３１】
ＦＲＯは、ＬＳＰをProtected LSPとしてセットアップすることを要求するObjectであ
る。ＦＲＯには、Protected LSPで必要な帯域が格納されている。ＦＲＯは、Protected LSPのPath Messageに必ず含まれる。
【００３２】
ＳＡＯは、sessionの属性を示すObjectである。ＳＡＯには、Local Protectionを要求
することを示す情報等が格納されている。
【００３３】
ＥＲＯは、明示的にＬＳＰの経路を指定するためのObjectである。ＥＲＯには、Messageを受信するInterfaceのＩＰアドレスが格納されている。
【００３４】
HOP Objectは、Messageの送信元を示すObjectである。HOP Objectには、Messageを送信するInterfaceのＩＰアドレスが格納されている。
【００３５】
Resv MessageのObjectについて説明する。Resv MessageのObjectは、Session Object（ＳＯ）、Record Route Object（ＲＲＯ）、HOP Objectを含む。
【００３６】
ＳＯは、ＬＳＰのsessionを識別するObjectである。Path MessageのＳＯと同様に、Ｓ
Ｏには、ＬＳＰのIngressノードおよびEgressノードを示す情報（ＩＰアドレスなど）が
格納されている。
【００３７】
ＲＲＯは、Messageの送信元を示すObjectである。ＲＲＯには、Messageを送信するInterfaceのＩＰアドレスが格納されている。また、ＲＲＯには、予約されたラベル情報が格
納されている。さらに、ＲＲＯには、Local Protectionが利用可能か否かを示す情報が格納されている。
【００３８】
HOP Objectは、Messageの送信元を示すObjectである。HOP Objectは、Path MessageのH
OP Objectと同じである。
【００３９】
Path Message及びResv Messageには、上記に示していない他のObjectも含まれ得る。
【００４０】
Path Message及びResv Messageは、通信パスのリソース（帯域）を予約する経路情報であり、かつ、通信パスのリソース（帯域）の予約を更新する経路情報である。
【００４１】
図２に示すように、Ingressノード（ノードＨ）から送信されたPath Messageをノード
Ａが受信すると、ノードＡは、ＥＲＯを１つ削除（Ａ−ＩＦ１）するとともに、HOP Objectを変更（Ａ−ＩＦ２）して下流ノード（ノードＢ）に向けて送信する。ノードＢ、ノードＣでも、同様に処理をして、Path Messageを下流ノードに向けて送信する。
【００４２】
Egressノード（ノードＴ）は、受信したPath Messageに対する応答としてResv Messageを上流ノード（ノードＣ）に向けて返送する。ノードＣは、受信したResv MessageにＲＲＯを１つ追加（Ｃ−ＩＦ１，Ｌａｂｅｌ２００）するとともに、HOP Objectを変更（Ｃ−ＩＦ１）して上流ノード（ノードＢ）に向けて返送する。ノードＢ、ノードＡでも、同様に処理をして、Resv Messageを上流ノードに向けて送信する。
【００４３】
この後、Path Message及びResv Messageは、一定周期（例えば３０秒）で、原則として、同じ情報が同じノードに対して送信される。この一定周期の送信動作をRefreshという
。Refreshにより、セットアップされたＬＳＰが維持される。
【００４４】
《Backup LSPのセットアップ》
図３は、Backup LSPのセットアップ方法を示す図である。Backup LSPで使用されるMessageは、基本的には、図２に示すProtected LSPで使用されるMessageと同様である。しか
し、Backup LSPで使用されるPath Messageには、ＦＲＯはない。
【００４５】
Path Messageは、Backup LSPのIngressノードであるノードＡからノードＤを経由してBackup LSPのEgressノードであるノードＣに向けて送信される。一方、Resv Messageは、Backup LSPのEgressノードであるノードＣからノードＤを経由してBackup LSPのIngressノードであるノードＡに向けて送信される。このようにして、Backup LSPがセットアップされ、Refreshを行うことで維持される。
【００４６】
ＰＬＲであるノードＡは、Resv Messageを受信することで、Backup LSPがセットアップされたことを認識することができる。
【００４７】
《Backup LSPセットアップ後のProtected LSPのシグナリング》
図４は、Backup LSPがセットアップされた後のProtected LSPのシグナリングを示す図
である。ＰＬＲであるノードＡにおいてProtected LSPに対するBackup LSPがセットアッ
プされている。
【００４８】
ＰＬＲであるノードＡは、Protected LSPのIngressノード（ノードＨ）に対し、Backup
LSPがセットアップされた旨をＲＲＯのLocal Protection Available（LP Available）情報で通知する。これにより、Protected LSPのIngressノード（ノードＨ）は、下流のリンクやノードがプロテクション（保護）されていることを認識する。図４では、Backup LSPのPath Message及びResv Messageは省略されている。
【００４９】
《リンク障害発生時の動作》
図５は、保護区間における障害が発生した状態での動作を示す図である。Protected LSPが通るノードＡとノードＢとの間のリンク障害が発生した時、ＰＬＲは、リンク障害を
認識した後、ノードＢに送信していたPath Massageを、データトラフィックと同様に、Backup LSP側に切り替える。このPath Messageは、Backup LSPを通ってノードＣ（ＭＰ）に送信される。
【００５０】
一方、ノードＢは上流のリンク障害を認識することで、もはやノードＡからPath MessageがRefreshされないと判断し、下流のノードＣに対してPath Tear Messageを送信する。このPath Tear Messageは、Path Messageで一旦予約されたリソースの開放を要求するMessageである。Path Tear Messageを受信したノードＣは、予約していた関連する予約情報
を削除する。なお、ノードＣはBackup LSP側からPath MessageがRefreshされるのでノー
ドＣからノードＴへのPath MessageのRefreshは行われる。
【００５１】
《リンク障害復旧時の動作》
図６は、保護区間におけるリンク障害が復旧した状態での動作を示す図である。ＰＬＲ（ノードＡ）は、リンク障害の復旧を認識した後Path MessageをノードＢに向けて送信する。Path Messageを受信したノードＢは、新たにノードＣにPath Messageを送信する。ノードＣはノードＢにResv Messageを送信し、ノードＢはノードＡにResv Messageを送信する。Resv Messageを受信したＰＬＲ（ノードＡ）は、Protected LSPが正常に復旧したこ
とを認識し、データトラフィックの切り戻しを行うとともに、Backup LSP側に送信していたPath Messageの送信を停止する。これによりLocal Revertiveが完了する。
【００５２】
ここで、Local Revertiveを実施する目的を具体的に説明する。もし、他に経路があっ
て、例えば、ノードＡとノードＸとの間にリンクがあったとすると、ノードＡとノードＢとの間でリンク障害発生中に一旦Backup LSPに切り替えを行った後、再度別のＬＳＰをノードＨ、ノードＡ、ノードＸ、ノードＢ、ノードＣ、ノードＴの径路でセットアップすることも可能である。しかし、その後また、そのＬＳＰ（ノードＨ、ノードＡ、ノードＸ、ノードＢ、ノードＣ、ノードＴ）に対して新たなBackup LSPを用意しなければならない。さらに、既にセットアップしているノードＡ、ノードＤ、ノードＣ間のBackup LSPは、不要なＬＳＰとなるので、削除する必要がある。これらの処理を障害が発生するたびに管理者によって実施する必要がある。しかし、Local Revertiveを行うことによってこのよう
な煩雑な処理を回避することができる。
【００５３】
〈装置〉
《ノード》
次に、本実施形態のノードについて説明する。ノードは、配置された位置等に応じて、Ingressノード、Egressノード、Transitノード（中継ノード）、ＰＬＲ、ＭＰ等として動作し得る。
【００５４】
図７は、ノードの構成例を示す図である。ノード２００は、外部入出力ＩＦ（InterFace）部２０６、受信パケット処理部２０２、送信パケット処理部２０４、受信Path State
管理部２１２、送信Path Message管理部２１４、受信Resv State管理部２２２、送信Resv
Message管理部２２４、ラベル・経路情報管理部２３０、ラベルテーブル＆フォワーディング処理部２４０を含む。
【００５５】
（外部入出力ＩＦ部）
外部入出力ＩＦ部２０６は、自ノードに対する制御や情報収集を行うためのインタフェースである。
【００５６】
（受信パケット処理部）
受信パケット処理部２０２は、入力インタフェースからの受信パケットに異常がないかのチェックを行う。受信パケット処理部２０２は、受信した受信パケットが正常であれば
、当該受信パケットを適切な管理部等に送信する。
【００５７】
受信パケット処理部２０２は、受信したパケットがPath Messageであれば、当該受信パケットを受信Path State管理部２１２に送信する。受信パケット処理部２０２は、受信したパケットがResv messageであれば、当該受信パケットを受信Resv State管理部２２２に送信する。受信パケット処理部２０２は、受信したパケットが主信号トラフィックであれば、当該受信パケットをラベルテーブル＆フォワーディング部２４０に送信する。
【００５８】
図７では、２つの受信パケット処理部２０２が記載されているが、１つの受信パケット処理部で上記の処理をしてもよい。
【００５９】
（送信パケット処理部）
送信パケット処理部２０４は、送信Path Message管理部２１４、送信Resv Message管理部２２４、または、ラベルテーブル＆フォワーディング部２４０から受信したパケットを出力インタフェースに送信する。
【００６０】
図７では、２つの送信パケット処理部２０４が記載されているが、１つの送信パケット処理部で上記の処理をしてもよい。
【００６１】
（受信Path State管理部）
受信Path State管理部２１２は、受信したPath Messageの経路情報が正しいか否かをラベル・経路情報管理部２３０に問い合わせる。また、受信Path State管理部２１２は、受信したPath Messageの各Objectの管理を行うとともにPath Stateが定期的にリフレッシュ（Refresh）されることを確認する。
【００６２】
（送信Path Message管理部）
Ingressノードとして動作する場合は、送信Path Message管理部２２４は、ＬＳＰをセ
ットアップするために外部入出力ＩＦ部２０６から入力された経路や帯域情報をもとに、Path Messageを生成する。
【００６３】
Egressノードとして動作する場合は、送信Path Message管理部２２４は、Path Messageを送信しない。
【００６４】
IngressノードでもなくEgressノードでもなく中継ノード（Transitノード）として動作する場合、送信Path Message管理部２２４は、受信したPath Messageをもとに送信Path Messageを生成する。このとき、送信Path Message管理部２２４は、ラベル・経路情報管理部２３０にその経路情報を問い合わせる。
【００６５】
ＰＬＲとして動作する場合、受信Path State管理部２１２からBackup LSPがセットアップされたことの通知を受けたとき、送信Path Message管理部２２４は、ＦＲＯを有するＬＳＰに対して、ＬＰＡＯ（Local Protection Available Object）を付与する。
【００６６】
ＭＰとして動作する場合、ＬＰＡＯを受信したとき、送信Path Message管理部２２４は、ＬＰＡＯを削除する。ＭＰではない場合、ＬＰＡＯを受信したとき、送信Path Message管理部２２４は、ＬＰＡＯをそのまま通過させる。
【００６７】
送信Path Message管理部２２４は、上流のリンク障害を認識すると、下流のノードに対してPath Tear Messageを送信する。但し、送信Path Message管理部２２４は、ＬＰＡＯ
を有するＬＳＰに関しては、下流のノードに対してPath Tear Messageを送信しない。
【００６８】
送信Path Message管理部２１４は、ＬＳＰのリソースを予約（確保）する予約部と、ＬＳＰのリソースの予約状態を更新（維持）する予約更新部として、実現され得る。
【００６９】
（受信Resv State管理部）
受信Resv State管理部２２２は、受信Resv Messageから下流ノードからラベル情報をラベル・経路情報管理部２３０に送信するとともに、受信したResv Stateを管理する。この際に、受信Resv State管理部２２２は、一定時間にResv StateがRefreshされることを確
認する。また、Backup LSPがセットアップされたときは、受信Resv State管理部２２２は、送信Path Message管理部２２４にその旨を通知する。
【００７０】
（送信Resv Message管理部）
Ingressノードとして動作する場合、送信Resv Message管理部２２４は、Resv Message
を送信しない。
【００７１】
Egressノード、または、Transitノードとして動作する場合は、受信したResv Message
をもとに送信Resv Messageを生成する。このとき、送信Resv Message管理部２２４は、払い出すラベル情報や経路情報をラベル・経路情報管理部２３０に問い合わせる。
【００７２】
（ラベル・経路情報管理部）
ラベル・経路情報管理部２３０は、ラベル、及び、経路情報を管理する。ラベル・経路情報管理部２３０は、各ブロック（受信Path State管理部２１２、送信Path Message管理部２１４、送信Resv State管理部２２２、受信Resv Message管理部２２４、ラベルテーブル＆フォワーディング処理部２４０等）からの問い合わせに応答する。ラベル・経路情報管理部２３０は、ラベルに関する情報をラベルテーブル＆フォワーディング処理部２４０に送信する。
【００７３】
受信Path State管理部２１２、送信Path Message管理部２１４、送信Resv State管理部２２２、受信Resv Message管理部２２４、及び、ラベル・経路情報管理部２３０は、１つの経路情報管理部として実現されてもよい。
【００７４】
ノードは、ＬＳＰのPath Message及びResv Messageを受信することで、当該ＬＳＰのリソースが確保されていることを確認することができる。
【００７５】
（ラベルテーブル＆フォワーディング処理部）
ラベルテーブル＆フォワーディング処理部２４０は、ラベル・経路情報管理部２３０からラベルに関する情報を受信し、ラベルテーブルに保持する。
【００７６】
Ingressノードとして動作する場合、ラベルテーブル＆フォワーディング処理部２４０
は、受信パケット処理部２０２からのパケットを受信すると、フォワーディング先を判定した後、ラベルを付与して当該パケットを送信パケット処理部２０４に送信する。
【００７７】
Transitノードとして動作する場合、ラベルテーブル＆フォワーディング処理部２４０
は、受信パケット処理部２０２からのパケットを受信すると、受信したパケットに付与されたラベルをもとにフォワーディング先を判定するとともに、ラベルを付け替えて、送信パケット処理部２０４に送信する。
【００７８】
Egressノードとして動作する場合、ラベルテーブル＆フォワーディング処理部２４０は、受信パケット処理部２０２からのパケットを受信すると、受信したパケットに付与されたラベルをもとにフォワーディング先を判定するとともに、ラベルを削除して、送信パケット処理部２０４に送信する。
【００７９】
〈本実施形態の動作例〉
上記のノードを使用した通信ネットワークの動作例を示す。
【００８０】
Protected LSPの障害時に、ＬＰＡＯを利用して障害発生箇所より下流のリソースを解
放しない方法について説明する。
【００８１】
《Protected LSPのセットアップ》
図８は、Protected LSP生成時の構成を示す図である。図８では、ノードＨ（Ingressノード）からノードＴ（Egressノード）までのProtected LSP（ＬＳＰ＃１）がセットアッ
プされる。Backup LSPは、まだ、セットアップされていない。
【００８２】
図９は、Protected LSPセットアップ時の各ノードの送信Path Msg及びPath Stateを示
す図である。
【００８３】
図１０は、Protected LSPセットアップ時の各ノードの送信Resv Msg及びResv Stateを
示す図である。
【００８４】
Protected LSP（ＬＳＰ＃１）は、ノードＨ（Ingressノード）からノードＴ（Egressノード）に向けてセットアップされる。ネットワーク管理者は、そのネットワーク内におけるノードの役割としてＰＬＲ及びＭＰを明示的に指定する。図８では、ノードＡがＰＬＲに、ノードＣがＭＰに、指定されていることとする。ネットワーク管理者は、ノードＨに対して、Protected LSP（ＬＳＰ＃１）をセットアップするための情報を与える。
【００８５】
ノードＨは、外部入出力ＩＦ部２０６で、外部からProtected LSP（ＬＳＰ＃１）をセ
ットアップするための情報（例えば、経路や帯域の情報）を受信する。外部入出力ＩＦ部２０６は、受信した情報を送信Path Message管理部２１４に送信する。
【００８６】
送信Path Message管理部２２４は、受信した情報をもとに、Protected LSP（ＬＳＰ＃
１）をセットアップするためのPath Messageを生成する。図９のノードＨの送信Path Msg（Message）Ｔ１０２がこれに該当する。
【００８７】
送信Path Message管理部２２４は、生成したPath Messageを送信パケット処理部２０４に送信する。送信パケット処理部２０４は、受信したPath Messageを、該Path Messageに従って、ノードＡに向けて送信する。
【００８８】
ノードＨの送信Path MsgＴ１０２には、Path Messageを生成するために必要な情報などが記録されている。例えば、ＬＳＰ識別情報、Session管理情報（ＳＯ）、Fast Reroute
に対する帯域などの要求（ＦＲＯ）、Local Protectionの要求（ＳＡＯ）、明示的経路情報（ＥＲＯ）、送信Interface情報（ＨＯＰ）である。ノードＨは、これらの情報をもと
にPath Messageを一定周期で生成し、送信する（Refresh）。
【００８９】
ノードＡは、ノードＨからのPath Messageを受信パケット処理部２０４で受信する。受信パケット処理部２０４は、受信したパケットがPath Messageであることから、当該パケットを受信Path State管理部２１２に送信する。
【００９０】
ノードＡの受信Path State管理部２１２は、受信したPath Messageの経路情報が正しいか否かをラベル・経路情報管理部２３０に問い合わせる。受信Path State管理部２１２は、受信したPath Messageの各Objectの情報をPath StateＴ１５４としてそのまま保持する。
【００９１】
ノードＡの受信Path State管理部２１２は、次のPath Messageを受信した時は、Path StateＴ１５４を更新する。受信Path State管理部２１２は、ノードＨからのPath Messageを所定時間（例えば、１５０秒間。上記の一定時間と同じでもよい）、受信しない場合は、Path StateＴ１５４の各Objectの情報をクリアする。
【００９２】
ノードＡの受信Path State管理部２１２は、受信したPath Messageを送信Path Message管理部２１４に送信する。
【００９３】
ノードＡの送信Path Message管理部２１４は、Path State管理部２１２からPath Messageを受信する。送信Path Message管理部２１４は、Path MessageのＥＲＯからノードＡ自身の受信ＩＦ情報（Ａ−ＩＦ１）を削除する。また、送信Path Message管理部２２４は、Path MessageのHOP ObjectをノードＡ自身の送信ＩＦ情報（Ａ−ＩＦ２）に変更する。
【００９４】
ノードＡの送信Path Message管理部２１４は、情報を更新したPath Messageを送信パケット処理部２０４へ送信する。送信パケット処理部２０４は、受信したPath Messageを、該Path Messageに従って、ノードＢに向けて送信する。
【００９５】
以下、ノードＢ、ノードＣの場合も、ノードＡの場合と同様に、それぞれ、Path Messageを受信し、所定の処理の後、次のノードにPath Messageを送信する。それぞれのノードで、Path State及び送信Path Msgが記録され、ＥＲＯおよびHOP Object等の情報が順次更新される。
【００９６】
ノードＴ（Egressノード）は、ノードＣからのPath Messageを受信パケット処理部２０４で受信する。受信パケット処理部２０４は、受信したパケットがPath Messageであることから、当該パケットを受信Path State管理部２１２に送信する。
【００９７】
ノードＴの受信Path State管理部２１２は、受信したPath Messageの経路情報が正しいか否かをラベル・経路情報管理部２３０に問い合わせる。受信Path State管理部２１２は、受信したPath Messageの各Objectの情報をPath StateＴ１６０としてそのまま保持する。
【００９８】
ノードＴの受信Path State管理部２１２は、次のPath Messageを受信した時は、Path StateＴ１６０を更新する。受信Path State管理部２１２は、ノードＣからのPath Messageを所定時間、受信しない場合は、Path StateＴ１６０の各Objectの情報をクリアする。
【００９９】
図１０は、Protected LSP（ＬＳＰ＃１)をセットアップする際のResv Messageに関する各ノードの情報を示す図である。この中にはResv Messageを生成するために必要な以下の情報などが記録されている。例えば、ＬＳＰ識別情報、Session管理情報（ＳＯ）、経路
情報やラベル情報、Local Protection情報が含まれるレコード情報（ＲＲＯ）、送信Interface情報（ＨＯＰ）である。
【０１００】
ノードＴ（Egressノード）の送信Resv Message管理部２２４は、送信Resv MsgＴ２６０をもとに、Resv Messageを一定周期で生成する（Refresh）。送信Resv Message管理部２
２４は、生成したResv Messageを送信パケット処理部２０４に送信する。送信パケット処理部２０４は、送信Resv Message管理部２２４から受信したResv Messageを、該Resv Messageに従って、ノードＣに向けて送信する。
【０１０１】
ノードＣ（Transitノード）は、ノードＴからのResv Messageを受信パケット処理部２
０４で受信する。受信パケット処理部２０４は、受信したパケットがResv Messageである
ことから、当該パケットを受信Resv State処理部２２２に送信する。
【０１０２】
受信Resv State管理部２２２は、受信したResv Messageの各Objectの情報をResv StateＴ２０８としてそのまま保持する。ノードＣの受信Resv State管理部２２２は、受信したResv Messageからラベル情報を抽出し、抽出したラベル情報をラベル・経路情報管理部２３０に送信する。ラベル・経路情報管理部２３０は、受信Resv State管理部２２２から受信したラベル情報をラベルテーブル＆フォワーディング処理部２４０に送信する。ラベルテーブル＆フォワーディング処理部２４０は、受信したラベル情報をラベルテーブルに保持する。
【０１０３】
ノードＣの受信Resv State管理部２２２は、次のResv Messageを受信した時は、Resv StateＴ２０８を更新する。受信Resv State管理部２２２は、ノードＴからのResv Messageを所定時間（例えば、１５０秒間。上記の一定時間と同じでもよい）、受信しない場合は、Resv StateＴ２０８の各Objectの情報をクリアする。
【０１０４】
ノードＣの受信Resv State管理部２２２は、受信したResv Messageを送信Resv Message管理部２２４に送信する。
【０１０５】
ノードＣの送信Resv Message管理部２２４は、Resv State管理部２２２からResv Messageを受信する。送信Resv Message管理部２２４は、Resv MessageのＲＲＯに対してノードＣ自身の送信ＩＦ情報（Ｃ−ＩＦ１）及びラベル情報（２００）を追加する。また、送信Resv Message管理部２２４は、Resv MessageのHOP ObjectをノードＣ自身の送信ＩＦ情報（Ｃ−ＩＦ１）に変更する。
【０１０６】
ノードＣの送信Resv Message管理部２２４は、情報を更新したResv Messageを送信パケット処理部２０４へ送信する。送信パケット処理部２０４は、受信したResv Messageを、該Resv Messageに従って、ノードＢに送信する。
【０１０７】
以下、ノードＢ、ノードＡの場合も、ノードＣの場合と同様に、Resv Messageを受信し、所定の処理の後、Resv Messageを送信する。それぞれのノードで、Resv State及び送信Resv Msgが記録され、ＲＲＯおよびHOP Object等の情報が順次更新される。
【０１０８】
ノードＨ（Ingressノード）は、ノードＡからのResv Messageを受信パケット処理部２
０４で受信する。受信パケット処理部２０４は、受信したパケットがResv Messageであることから、当該パケットを受信Resv State管理部２２２に送信する。
【０１０９】
ノードＨの受信Resv State管理部２２２は、受信したResv Messageからラベル情報を抽出し、抽出したラベル情報をラベル・経路情報管理部２３０に送信する。受信Resv State管理部２２２は、受信したResv Messageの各Objectの情報をResv StateＴ２０２としてそのまま保持する。
【０１１０】
各ノードは、ＬＳＰのPath Message及びResv Messageを受信することで、当該ＬＳＰがセットアップされていること、即ちリソースが確保されていることを認識することができる。
【０１１１】
ノードＨの受信Resv State管理部２２２は、次のResv Messageを受信した時は、Resv StateＴ２０２を更新する。受信Resv State管理部２２２は、ノードＡからのResv Messageを所定時間、受信しない場合は、Resv StateＴ２０２の各Objectの情報をクリアする。
【０１１２】
ノードＨは、Resv Messageを受信することで、Protected LSPがセットアップされてい
ること、即ちリソースが確保されていることを認識することができる。
【０１１３】
《Backup LSPのセットアップ》
Backup LSPは、図３に示す標準の動作例のBackup LSPのセットアップと同様にセットアップされる。
【０１１４】
《Backup LSPセットアップ後のProtected LSPのシグナリング》
図１１は、Protected LSPおよびBackup LSPがセットアップされた後のProtected LSPのシグナリングの概要を示す図である。ＰＬＲであるノードＡにおいてProtected LSPに対
するBackup LSPがセットアップされている。Backup LSP（ＬＳＰ＃２）は、ノードＡからノードＤを経由してノードＣに向けてセットアップされる。
【０１１５】
ＰＬＲであるノードＡは、Protected LSP及びBackup LSPがセットアップされたことを
契機にPath MessageにＬＰＡＯ（Local Protection Available Object）を追加して下流
のノードに送信する。中継ノードであるノードＢはＬＰＡＯをそのまま通過させ、ＭＰであるノードＣはPath MessageからこのＬＰＡＯを削除して下流のノードに送信する。
【０１１６】
ここで、ＬＰＡＯ（Local Protection Available Object）は、Protected LSPに対してBackup LSPがセットアップされていることを示すObjectである。ＬＰＡＯは、標準のシグナリングメッセージには存在しないObjectである。ＬＰＡＯは、本実施形態により新規に追加するObjectである。ＬＰＡＯは、ＰＬＲからＭＰまでの間で送信される。
【０１１７】
図１２は、Backup LSPをセットアップした後の各ノードの送信Path MsgとPath Stateを示す図である。
【０１１８】
図１３は、Backup LSPをセットアップした後の各ノードの送信Resv MsgとResv Stateを示す図である。
【０１１９】
ＰＬＲであるノードＡがBackup LSPがセットアップされたことを認識すると、ノードＡの受信Path State管理部２１２は、送信Path Massage管理部２１４に対し、Backup LSPがセットアップされたことを通知する。
【０１２０】
Protected LSP及びBackup LSPがセットアップされたことの確認は、ノードの確認部と
して実現されてもよい。
【０１２１】
送信Path Message管理部２１４は、送信Path MsgのＦＲＯを有するＬＳＰ＃１にＬＰＡＯを新たに追加する（図１２：ノードＡの送信Path MsgＴ３０４）。送信Path Message管理部２１４は、ＬＰＡＯを追加したPath Messageを送信パケット処理部２０４に送信する。
【０１２２】
送信パケット処理部２０４は、受信したPath Messageを、該Path Messageに従って、ノードＢに向けて送信する。
【０１２３】
中継ノードであるノードＢは、ノードＡからのPath Messageを受信パケット処理部２０４で受信する。受信パケット処理部２０４は、受信したパケットがPath Messageであることから、当該パケットを受信Path State管理部２１２に送信する。
【０１２４】
ノードＢの受信Path State管理部２１２は、受信したPath Messageの経路情報が正しいか否かをラベル・経路情報管理部２３０に問い合わせる。受信Path State管理部２１２は、受信したPath Messageの各Object（ＬＰＡＯを含む）の情報をPath StateＴ３５６とし
てそのまま保持する。
【０１２５】
ノードＢの受信Path State管理部２１２は、次のPath Messageを受信した時は、Path Stateを更新する。受信Path State管理部２１２は、ノードＡからのPath Messageを所定時間、受信しない場合は、Path StateＴ３５６の各Objectの情報をクリアする。
【０１２６】
ノードＢの受信Path State管理部２１２は、受信したPath Messageを送信Path Message管理部２１４に送信する。
【０１２７】
ノードＢの送信Path Message管理部２１４は、Path State管理部２１２からPath Messageを受信する。送信Path Message管理部２１４は、Path MessageのＥＲＯからノードＢ自身の受信ＩＦ情報（Ｂ−ＩＦ１）を削除する。また、送信Path Message管理部２２４は、Path MessageのHOP ObjectをノードＢ自身の送信ＩＦ情報（Ｂ−ＩＦ２）に変更する。
【０１２８】
ノードＢの送信Path Message管理部２１４は、情報を更新したPath Message（ＬＰＡＯを含む）を送信パケット処理部２０４へ送信する。送信パケット処理部２０４は、受信したPath Messageを、該Path Messageに従って、ノードＣに送信する。
【０１２９】
ＭＰであるノードＣは、ノードＢからのPath Messageを受信パケット処理部２０４で受信する。受信パケット処理部２０４は、受信したパケットがPath Messageであることから、当該パケットを受信Path State管理部２１２に送信する。
【０１３０】
ノードＣの受信Path State管理部２１２は、受信したPath Messageの経路情報が正しいか否かをラベル・経路情報管理部２３０に問い合わせる。受信Path State管理部２１２は、受信したPath Messageの各Object（ＬＰＡＯを含む）の情報をPath StateＴ３５８としてそのまま保持する。
【０１３１】
ノードＣの受信Path State管理部２１２は、次のPath Messageを受信した時は、Path Stateを更新する。受信Path State管理部２１２は、ノードＢからのPath Messageを所定時間、受信しない場合は、Path StateＴ３５８の各Objectの情報をクリアする。
【０１３２】
ノードＣの受信Path State管理部２１２は、受信したPath Messageを送信Path Message管理部２１４に送信する。
【０１３３】
ノードＣの送信Path Message管理部２１４は、Path State管理部２１２からPath Messageを受信する。送信Path Message管理部２１４は、Path MessageのＥＲＯからノードＣ自身の受信ＩＦ情報（Ｃ−ＩＦ１）を削除する。また、送信Path Message管理部２２４は、Path MessageのHOP ObjectをノードＣ自身の送信ＩＦ情報（Ｃ−ＩＦ２）に変更する。
【０１３４】
送信Path Message管理部２１４は、受信したPath MessageからＬＰＡＯを削除して、Path Messageを送信Path Msgとして保持する（図１２：ノードＣの送信Path MsgＴ３０８）。
【０１３５】
ノードＣの送信Path Message管理部２１４は、情報を更新したPath Messageを送信パケット処理部２０４へ送信する。送信パケット処理部２０４は、受信したPath Messageを、該Path Messageに従って、ノードＴに送信する。
【０１３６】
図１４は、ＬＰＡＯの追加、削除の処理条件を示す図である。自ノードがＰＬＲであり、ＦＲＯを有するPath Messageを受信し、Backup LSPがセットアップされている場合、下流へのPath MessageにＬＰＡＯを追加する。自ノードがＭＰであり、ＦＲＯを有するPath
Messageを受信する場合、ＬＰＡＯを削除する。
【０１３７】
また、ＰＬＲであるノードＡは、Backup LSPがセットアップされたことを認識すると、図１３のノードＡの送信Resv MsgＴ４５４のＲＲＯに示すようにLocal Protection Available（LP avilable）になったことをIngressノードであるノードＨに通知する。
【０１３８】
《リンク障害発生時の動作》
図１５は、Protected LSP上でリンク障害が発生したときの動作概要を示す図である。
図１５では、ノードＡとノードＢとの間でリンク障害が発生している。
【０１３９】
ノードＢは、上流のリンク障害によってPath MessageがRefreshされないことを認識す
る。ノードＢは、ＬＳＰのPath MessageがＦＲＯ及びＬＰＡＯを有するため、Path Tear Messageによるリソース解放を行わず、下流のノード（ノードＣ）へのRefresh動作を継続する。これにより、Protected LSP（ＬＳＰ＃１）に関するノードＢとノードＣとの間の
リソースは開放されずに維持されることになる。つまり、Protected LSP（ＬＳＰ＃１）
に関するノードＢとノードＣとの間のリソースの解放が禁止される。
【０１４０】
図１６は、Protected LSP上でリンク障害が発生した時の構成を示す図である。
【０１４１】
図１７は、リンク障害発生中の各ノードの送信Path Msg及びPath Stateを示す図である。
【０１４２】
図１８は、リンク障害発生中の各ノードの送信Resv Msg及びResv Stateを示す図である。
【０１４３】
ＰＬＲであるノードＡは、ノードＡとノードＢとの間の障害を認識すると、データトラフィックをBackup LSP側に切り替える。ノードＡは、受信Resv State管理部２２２でノードＢからのResv Messageが受信されないことにより、ノードＡとノードＢとの間の障害を認識することができる。ノードＡは、これにより障害を検出する。ノードＡは、ノードＢ側へ送信していたPath MessageをBackup LSP側に切り替える。このとき、ノードＡの送信Path Message管理部２１４は、ノードＡの送信Path MsgのＥＲＯの「Ｂ−ＩＦ１」及び「Ｃ−ＩＦ１」を「Ｃ−ＩＦ３」に、ＨＯＰの「Ａ−ＩＦ２」を「Ａ−ＩＦ３」に変更する（図１７：ノードＡの送信Path MsgＴ５０４）。送信Path Message管理部２１４は、変更したPath Messageを送信パケット処理部２０４に送信する。
【０１４４】
送信パケット処理部２０４は、受信したPath Messageを、該Path Messageに従って、Backup LSP側から、ノードＣに送信する。
【０１４５】
ノードＣは、Backup LSP側からノードＡからのPath Messageを受信パケット処理部２０４で受信する。受信パケット処理部２０４は、受信したパケットがPath Messageであることから、当該パケットを受信Path State管理部２１２に送信する。
【０１４６】
ノードＣの受信Path State管理部２１２は、受信したPath Messageの経路情報が正しいか否かをラベル・経路情報管理部２３０に問い合わせる。
【０１４７】
受信Path State管理部２１２は、Path StateにＬＳＰ＃１‐ＢＵ（BackUp）を追加し、受信したPath Messageの各Objectの情報を保持する（図１７：ノードＣのPath StateＴ５５８）。
【０１４８】
ノードＣの受信Path State管理部２１２は、受信したPath Messageを送信Path Message
管理部２１４に送信する。
【０１４９】
ノードＣの送信Path Message管理部２１４は、Path State管理部２１２からPath Messageを受信する。送信Path Message管理部２１４は、Path MessageのＥＲＯからノードＣ自身の受信ＩＦ情報（Ｃ−ＩＦ３）を削除する。また、送信Path Message管理部２２４は、Path MessageのHOP ObjectをノードＣ自身の送信ＩＦ情報（Ｃ−ＩＦ２）に変更する。ノードＣはＭＰであることから、送信Path Message管理部２１４は、受信したPath MessageからＬＰＡＯを削除する。
【０１５０】
送信Path Message管理部２１４は、情報を更新したPath Messageを送信パケット処理部２０４に送信する。送信パケット処理部２０４は、受信したPath Messageを、該Path Messageに従って、ノードＴに送信する。
【０１５１】
一方、中継ノードであるノードＢは、ノードＡとノードＢとの間の障害を認識すると、ノードＢのPath Stateをクリアする（図１７：ノードＢのPath StateＴ５５６）。ノードＢは、受信Path State管理部２１２でノードＡからのPath Messageが受信されないことにより、ノードＡとノードＢとの間の障害を認識することができる。ノードＢの送信Path Message管理部２１４は、ノードＢの送信Path MsgＴ５０６をそのまま維持する。ノードＢの送信Path MessageＴ５０６は、ＦＲＯとＬＰＡＯとを有しているので、継続したRefresh動作が必要となるためである。これにより、図１６に示すように、ノードＢは、ノード
ＡとノードＢとの間の障害発生中も、ノードＣに向けて継続してPath Messageを送信する。よって、ノードＢとノードＣとの間では、Protected LSP（ＬＳＰ＃１）のためのリソ
ースを維持することができる。
【０１５２】
ノードＣでは、ノードＡからのPath Message（ＬＳＰ＃１−ＢＵ）と、ノードＢからのPath Message（ＬＳＰ＃１−Ｐ）とを受信することになる。
【０１５３】
図１９は、保護区間中の中継ノード（例えば、ノードＣ）がPath MessageのRefresh動
作を継続するか否かの判断条件を示す図である。保護区間中の中継ノードにおいて、上流のリンクが正常かつ上流からPath MessageがRefreshされるならば、ノードは、下流へのPath MessageもRefreshする。保護区間中の中継ノードにおいて、上流のリンクが異常であっても送信するPath MessageがＦＲＯとＬＰＡＯとを有する場合は、ノードは、下流へのPath MessageもRefreshする。それ以外の場合は、RefreshせずにPath Tearする。
【０１５４】
ノードＡとノードＢとの間の障害発生中、ノードＣは、Protected LSP側から、及び、Backup LSP側から、Path Messageを受信する。よって、図１８のノードＣの送信Resv Msg
Ｔ６５８に示すように、ノードＡ及びノードＢの双方にResv Messageを送信する。
【０１５５】
また、ノードＡは、Backup LSP側からResv Messageを受信する。ノードＡの受信Resv State管理部２２２は、ノードＡのResv StateのＲＲＯの「Ｃ−ＩＦ１」を「Ｃ−ＩＦ３」に、ＨＯＰを「Ｂ−ＩＦ１」に変更する（図１８：ノードＡのResv StateＴ６０４）。受信Resv State管理部２２２は、受信したResv Messageを送信Resv Message管理部２２４に送信する。
【０１５６】
ノードＡの送信Resv Message管理部２２４は、Resv State管理部２２２からResv Messageを受信する。送信Resv Message管理部２２４は、送信Resv Msgを更新する。送信Resv Message管理部２２４は、Resv Messageを、送信パケット処理部２０４に送信する。送信パケット処理部２０４は、Resv Messageに従って、該Resv Messageを、ノードＨに向けて送信する。これらの動作によって、障害発生中のリソース競合を回避することができる。
【０１５７】
Protected LSPに対してBackup LSPがセットアップされていることを示すＬＰＡＯを使
用することにより、Protected LSPのリソースを維持することができる。ＬＰＡＯは、経
路維持情報をもって、実現できる。
【０１５８】
ＰＬＲであるノードＡは、リンク障害の復旧を認識すると、Path MessageをノードＢに向けて送信する。Path Messageを受信したノードＢは、ノードＣにPath Messageを送信する。ノードＣはノードＢにResv Messageを送信し、ノードＢはノードＡにResv Messageを送信する。Resv Messageを受信したＰＬＲ（ノードＡ）は、Protected LSPが正常に復旧
したことを認識し、データトラフィックの切り戻しを行うとともに、Backup LSP側に送信していたPath Messageの送信を停止する。
【０１５９】
この構成によると、リンク障害発生中も、Protected LSP上のリソースを維持すること
ができるので、リンク障害が復旧した際、データトラフィックの切り戻しが可能となる。
【０１６０】
リンク障害の検出は、検出部として実現され得る。データトラフィックの切り戻しは、切替制御部として実現され得る。Protected LSPのリソースの維持は、リソースの解放を
禁止する禁止部として実現され得る。
【０１６１】
《新たなＬＳＰのセットアップが要求されたときの動作》
図２０は、新たなＬＳＰ（ＬＳＰ＃１、ＬＳＰ＃２以外）のセットアップが要求されたときの動作例を示す図である。
【０１６２】
図２０に示すように、ノードＸから、ノードＢ、ノードＣを経由してノードＹまでのＬＳＰ＃３のセットアップが要求されたとする。このとき、ＬＳＰ＃３のPath Messageを受信したノードＢは、ノードＢとノードＣとの間のリソースがないことから、そのＬＳＰがセットアップできないことをPath Error MessageでノードＸに通知する。その結果、ノードＢにおいてProtected LSP（ＬＳＰ＃１)とＬＳＰ＃３のリソース競合を回避（Protected LSP（ＬＳＰ＃１）のリソースを優先）することができるので、ノードＡとノードＢと
の間の障害復旧時に確実にLocal Revertiveすることが可能となる。
【０１６３】
《Protected LSP上でリンク障害発生中にＬＳＰの削除要求がされた場合の動作》
Protected LSP上で障害発生中にそのＬＳＰの削除要求（Path Tear）を受信した場合の動作について説明する。
【０１６４】
図２１は、Protected LSP上で障害発生中にＬＳＰの削除要求がされたときの構成を示
す図である。
【０１６５】
図２２は、Path Tear Messageを受信した後の各ノードの送信Path MsgとPath Stateを
示す図である。
【０１６６】
図２３は、Path Tear Messageを受信した後の各ノードの送信Resv MsgとResv Stateを
示す図である。
【０１６７】
ノードＨは、ＬＳＰ＃１の削除要求を受信すると、Path Tear Messageを、ノードＨか
ら、ノードＡ、ノードＤ、ノードＣを経由してノードＴに送信する。この構成によると、Backup LSPを経由したＬＳＰ＃１のリソースが解放される。
【０１６８】
ノードＢは、ノードＡとノードＢとの間が障害発生中のため、上流（ノードＡ）からPath Tear Messageを受信することができない。このため、ノードＢとノードＣとの間のリ
ソースは、解放されない。そこで、不要なリソースの維持を回避するために、ＭＰである
ノードＣはBackup LSP側からPath Tear Messageの受信を契機に上流のノードＢに向かっ
てResv Tear Messageを送信する。ノードＢは、Resv Tear Messageを受信すると、ノードＢとノードＣとの間のリソースを解放する。この構成によると、ノードＢとノードＣとの間のリソースが解放される。
【０１６９】
図２４は、ＭＰがProtected LSP側の上流にResv Tear Messageを送信する条件を示す図である。自ノードがＭＰであり、同一ＬＳＰに対するProtected LSPとBackup LSPのPath Stateを持ち、さらにBackup LSP側からPath Tear Messageを受信すると、Protected LSP
側の上流にResv Tear Messageを送信する。図２２及び図２３には、Path Tear後、ＬＳＰ＃１に関する情報がすべてクリアされた結果が示されている。
【０１７０】
この構成によると、Backup LSPに切り替っている時に受信するＬＳＰの削除要求にも対応することが可能となる。
【０１７１】
《ノードＢとノードＣとの間でリンク障害が発生した場合の動作》
上記のようなＰＬＲであるノードＡの直近ではない、ノードＢとノードＣとの間でリンク障害が発生した場合の動作（リンク障害が発生した箇所の上流のリソースを開放しない方法）について説明する。
【０１７２】
図２５は、ノードＢとノードＣとの間でリンク障害が発生した場合の構成図を示す図である。
【０１７３】
上記のように、ノードＡとノードＢとの間のリンク障害発生時には、ＰＬＲであるノードＡは、直近の下流リンク異常を直接検出することができる。ノードＡとノードＢとの間のリンク障害を認識したノードＡは、データトラフィック及びPath MessageをBackup LSP側に切り替える。
【０１７４】
一方、図２５に示すように、ノードＢとノードＣとの間のリンク障害が発生した場合、ノードＢは、上流のノードＡに向かってPath Error Messageを送信する。Path Error Messageは、下流のリンク障害等を通知する経路エラー情報である。ノードＢからPath Error
Messageを受信したＰＬＲであるノードＡは、下流でリンク障害が発生したことを認識する。ノードＡは、データトラフィック及びノードＢに送信していたPath MessageをBackup
LSP側に切り替える。さらに、ノードＡがノードＢに送信するPath MessageがＦＲＯとＬＰＡＯとを有する場合、ノードＡとノードＢとの間のリソースを維持する必要がある。そのため、ノードＡは、ノードＢにもPath Messageを送信し続ける。これにより、例えばノードＺ、ノードＡ、ノードＢ、ノードＸのような経路のＬＳＰとのリソース競合を回避することができる。
【０１７５】
図２６は、ＰＬＲにおけるProtected LSPのPath MessageをRefreshする条件を示す図である。
【０１７６】
ＰＬＲであるノードにおいて、上流リンクが正常かつ上流からPath MessageがRefresh
され、直近の下流リンクが正常で、下流からPath Error Messageを受信しない場合、Protected LSP側のみにPath MessageをRefreshする。
【０１７７】
ＰＬＲであるノードにおいて、上流リンクが正常かつ上流からPath MessageがRefresh
され、直近の下流リンクが異常である場合、Backup LSP側にPath MessageをRefreshする
（切り替え）。
【０１７８】
ＰＬＲであるノードにおいて、上流リンクが正常かつ上流からPath MessageがRefresh
され、送信するPath MessageがＦＲＯとＬＰＡＯとを有し、直近の下流リンクが正常で、下流からPath Error Messageを受信する場合、Protected LSP側及びBackup LSP側にPath MessageをRefreshする。
【０１７９】
ＰＬＲであるノードにおいて、上流リンクが正常かつ上流からPath MessageがRefresh
され、送信するPath MessageがＦＲＯとＬＰＡＯとを有さず、直近の下流リンクが正常であり、下流からPath Error Messageを受信する場合、Backup LSP側にPath MessageをRefreshする（切り替え）。
【０１８０】
ＰＬＲであるノードにおいて、上流リンクが異常である場合、Path Tear Messageを送
信する。
【０１８１】
この構成によると、ＰＬＲであるノードが下流リンクの障害状態によりPath MessageのRefresh動作を変えることでProtected LSPと他のＬＳＰとのリソース競合を回避することができる。
【０１８２】
〔付記〕
上述の実施形態は、以下の発明を開示する。以下の発明は、必要に応じて適宜組み合わせることができる。
【０１８３】
（付記１）
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの始点に位置する通信装置であって、
第１の通信パスの始点から終点までの帯域、及び、第１の通信パスの一部区間の予備として第２の通信パスの始点から終点までの帯域が確立されているか否かを確認する確認部と、
前記確認部が前記第１の通信パスの始点から終点までの帯域及び前記第１の通信パスの一部区間の予備として前記第２の通信パスの始点から終点までの帯域が確立されていることを確認したとき、前記第１のパスの一部区間の帯域を維持するための経路維持情報を生成する経路情報管理部と、
第１の通信パス上の終点側に隣接する通信装置に、前記経路情報管理部が生成した前記経路維持情報を送信する送信部と、
を有する通信装置。
【０１８４】
（付記２）
前記第１の通信パス上の終点側に隣接する通信装置から、前記第１の通信パス上の終点側に隣接する通信装置より終点側でリンク障害が発生したことを示す経路エラー情報を受信する受信部を備え、
前記確認部が、第１の通信パスの始点から終点までの帯域と、第１の通信パスの一部区間の予備として第２の通信パスの始点から終点までの帯域とが確立されていることを確認し、かつ、前記受信部が、前記第１の通信パス上の終点側に隣接する通信装置から、前記第１の通信パス上の終点側に隣接する通信装置より終点側でリンク障害が発生したことを示す経路エラー情報を受信したとき、前記送信部は、前記第１の通信パス上の終点側に隣接する通信装置に、経路維持情報を送信する、
付記１に記載の通信装置。
【０１８５】
（付記３）
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上にあって互いに異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの始点と終点との間の第１の通信パス上に位置する通信装置であって、
第１の通信パス上の始点側に隣接する通信装置から、第１の通信パスの一部区間の帯域を維持するための経路維持情報を受信する受信部と、
前記経路維持情報を格納する経路情報管理部と、
第１の通信パス上の終点側に隣接する通信装置に、前記経路維持情報を送信する送信部と、
を有する通信装置。
【０１８６】
（付記４）
前記第１の通信パス上の始点側に隣接する通信装置との間でリンク障害が発生した場合、前記送信部は、第１の通信パス上の終点側に隣接する通信装置に、前記経路情報管理部に格納された経路維持情報を送信する、
付記３に記載の通信装置。
【０１８７】
（付記５）
前記受信部が、前記第１の通信パス上の終点側に隣接する通信装置から、第１の通信パスの帯域の削除要求情報を受信した場合、前記経路情報管理部は、前記経路維持情報を削除する、
付記３または４に記載の通信装置。
【０１８８】
（付記６）
前記第１の通信パス上の終点側に隣接する通信装置との間でリンク障害が発生した場合、前記送信部は、第１の通信パス上の始点側に隣接する通信装置に、前記第１の通信パス上の終点側でリンク障害が発生したことを示す経路エラー情報を送信する、
付記３乃至５のいずれか１つに記載の通信装置。
【０１８９】
（付記７）
複数の通信装置が縦続接続され、始点と終点を有する第１の通信パスと、
複数の通信装置が縦続接続され、その両端の通信装置がともに前記第１の通信パス上の異なる通信装置であり、前記両端の通信装置のうち、前記第１の通信パスの始点側に位置する通信装置を始点とし、前記両端の通信装置のうち、前記第１の通信パスの終点側に位置する通信装置を終点とする第２の通信パスと、を含む通信ネットワークにおける、第２の通信パスの終点に位置する通信装置であって、
第１の通信パス上の始点側に隣接する通信装置から、第１の通信パスの一部区間の帯域を維持するための経路維持情報を受信する受信部と、
前記経路維持情報を格納する経路情報管理部と、
を有する通信装置。
【０１９０】
（付記８）
第２の通信パスの始点と終点との間の第１の通信パス上でリンク障害が発生し、前記経路情報管理部が前記経路維持情報を格納し、かつ、前記受信部が前記第２の通信パスの通信装置から第１の通信パスのリソースの削除要求情報を受信したとき、第１の通信パス上の始点側に隣接する通信装置に、前記削除要求情報を送信する送信部を備える、
付記７に記載の通信装置。
【０１９１】
（付記９）
始点及び終点を有する第１の通信パスと、第１の通信パスからみた分岐点及び合流点が始点及び終点として規定され、且つこれらの分岐点から合流点までで規定される第１の通信パスの中間部分をバイパスするように作成される第２の通信パスとを有し、前記中間部分に障害が生じていない場合には、前記第１の通信パスの始点から送信されるデータが前記中間部分を経由して前記第１の通信パスの終点に転送されるネットワークシステムにおいて、
前記中間部分の障害を検出する検出部と、
前記中間部分の障害が検出された場合に、前記第１の通信パスの始点から終点までのデータの転送経路の一部を前記中間部分から前記第２の通信パスに切り替え、前記中間部分の障害から復旧した場合に、前記第１の通信パスの始点から終点までのデータの転送経路の一部を前記第２の通信パスから前記中間部分に切り戻す切替制御部と、
前記中間部分の障害発生から復旧までの間において、前記中間部分の障害未発生部分に関する前記第１の通信パス用のリソース解放を禁止する禁止部と、
を備えるネットワークシステム。
【０１９２】
（付記１０）
始点及び終点を有する第１の通信パスと、第１の通信パスからみた分岐点及び合流点が始点及び終点として規定され、且つこれらの分岐点から合流点までで規定される第１の通信パスの中間部分をバイパスするように作成される第２の通信パスとを有し、前記中間部分に障害が生じていない場合には、前記第１の通信パスの始点から送信されるデータが前記中間部分を経由して前記第１の通信パスの終点に転送され、前記中間部分に障害が発生した場合に、前記第１の通信パスの始点から送出されるデータの転送経路が前記中間部分から前記第２のパスに切り替えられ、前記中間部分が前記障害から復旧した場合に、前記第１の通信パスの始点から送出されるデータの転送経路が前記第２の通信パスから前記中間部分に切り替えられるネットワークシステムにおいて、前記中間部分に配置される通信装置であって、
前記第１の通信パスの作成時に、前記中間部分に関する前記第１の通信パス用のリソースを予約する予約部と、
前記第１の通信パス用のリソースの予約状態を更新する予約更新部とを備え、
前記第１の通信パス用のリソースの予約状態は、前記中間部分の障害発生によっては解除されず、前記予約更新部は、前記中間部分の障害発生時においても前記予約状態を更新する、
通信装置。
【図面の簡単な説明】
【０１９３】
【図１】通常状態のネットワークの構成例を示す図である。
【図２】Protected LSPのセットアップ方法を示す図である。
【図３】Backup LSPのセットアップ方法を示す図である。
【図４】Backup LSPがセットアップされた後のProtected LSPのシグナリングを示す図である。
【図５】保護区間における障害が発生した状態での動作を示す図である。
【図６】保護区間におけるリンク障害が復旧した状態での動作を示す図である。
【図７】ノードの構成例を示す図である。
【図８】Protected LSP生成時の構成を示す図である。
【図９】Protected LSPセットアップ時の各ノードの送信Path Msg及びPath Stateを示す図である。
【図１０】Protected LSPセットアップ時の各ノードの送信Resv Msg及びResv Stateを示す図である。
【図１１】Backup LSPを生成した後の構成を示す図である。
【図１２】Backup LSPをセットアップした後の各ノードの送信Path Msg及びPath Stateを示す図である。
【図１３】Backup LSPをセットアップした後の各ノードの送信Resv Msg及びResv Stateを示す図である。
【図１４】ＬＰＡＯの追加、削除の処理条件を示す図である。
【図１５】Protected LSP上で障害が発生したときの動作を示す図である。
【図１６】Protected LSP上で障害が発生したときの動作を示す図である。
【図１７】障害発生中の各ノードの送信Path Msg及びPath Stateを示す図である。
【図１８】障害発生中の各ノードの送信Resv Msg及びResv Stateを示す図である。
【図１９】Path messageのRefresh動作の判断条件を示す図である。
【図２０】新たなＬＳＰ（ＬＳＰ＃１、ＬＳＰ＃２以外）のセットアップが要求されたときの動作例を示す図である。
【図２１】Protected LSP上で障害発生中にＬＳＰの削除要求がされたときの動作を示す図である。
【図２２】Path Tear Messageを受信した後の各ノードの送信Path Msg及びPath Stateを示す図である。
【図２３】Path Tear Messageを受信した後の各ノードの送信Resv Msg及びResv Stateを示す図である。
【図２４】ＭＰがResv Tear Msgを送信する条件を示す図である。
【図２５】ノードＢとノードＣとの間でリンク障害が発生した場合の動作の構成を示す図である。
【図２６】ＰＬＲにおけるProtected LSPのPath MessageをRefreshする条件を示す図である。
【図２７】ＦＲＲ動作概要（保護区間においてリンク障害が発生した場合）を示す図である。
【図２８】ＦＲＲ動作概要（保護区間の障害が復旧した場合）を示す図である。
【図２９】保護区間において障害発生中に新たなＬＳＰがセットアップされる場合の動作例を示す図である。
【図３０】保護区間において障害発生中に新たなＬＳＰがセットアップされたことによりリソース競合が起きる場合の動作例を示す図である。
【符号の説明】
【０１９４】
２００          ノード
２０２          受信パケット処理部
２０４          送信パケット処理部
２０６          外部入出力ＩＦ（InterFace）部
２１２          受信Path State管理部
２１４          送信Path Message管理部
２２２          受信Resv State管理部
２２４          送信Resv Message管理部
２３０          ラベル・経路情報管理部
２４０          ラベルテーブル＆フォワーディング処理部
Ａ          ノード（ＰＬＲ、ＬＳＰ＃２のIngressノード）
Ｂ          ノード（中継ノード）
Ｃ          ノード（ＭＰ、ＬＳＰ＃２のEgressノード）
Ｄ          ノード（中継ノード）
Ｈ          ノード（ＬＳＰ＃１のIngressノード）
Ｙ          ノード（ＬＳＰ＃１のEgressノード）
Ｘ          ノード（ＬＳＰ＃３のIngressノード）
Ｙ          ノード（ＬＳＰ＃３のEgressノード）
Ｚ          ノード
Ｔ１０２          ノードＨの送信Path Message
Ｔ１０４          ノードＡの送信Path Message
Ｔ１０６          ノードＢの送信Path Message
Ｔ１０８          ノードＣの送信Path Message
Ｔ１５４          ノードＡのPath State
Ｔ１５６          ノードＢのPath State
Ｔ１５８          ノードＣのPath State
Ｔ１６０          ノードＴのPath State
Ｔ２０２          ノードＨの送信Resv Message
Ｔ２０４          ノードＡの送信Resv Message
Ｔ２０６          ノードＢの送信Resv Message
Ｔ２０８          ノードＣの送信Resv Message
Ｔ２５４          ノードＡのResv State
Ｔ２５６          ノードＢのResv State
Ｔ２５８          ノードＣのResv State
Ｔ２６０          ノードＴのResv State
Ｔ３０２          ノードＨの送信Path Message
Ｔ３０４          ノードＡの送信Path Message
Ｔ３０６          ノードＢの送信Path Message
Ｔ３０８          ノードＣの送信Path Message
Ｔ３５４          ノードＡのPath State
Ｔ３５６          ノードＢのPath State
Ｔ３５８          ノードＣのPath State
Ｔ３６０          ノードＴのPath State
Ｔ４０２          ノードＨの送信Resv Message
Ｔ４０４          ノードＡの送信Resv Message
Ｔ４０６          ノードＢの送信Resv Message
Ｔ４０８          ノードＣの送信Resv Message
Ｔ４５４          ノードＡのResv State
Ｔ４５６          ノードＢのResv State
Ｔ４５８          ノードＣのResv State
Ｔ４６０          ノードＴのResv State
Ｔ５０２          ノードＨの送信Path Message
Ｔ５０４          ノードＡの送信Path Message
Ｔ５０６          ノードＢの送信Path Message
Ｔ５０８          ノードＣの送信Path Message
Ｔ５５４          ノードＡのPath State
Ｔ５５６          ノードＢのPath State
Ｔ５５８          ノードＣのPath State
Ｔ５６０          ノードＴのPath State
Ｔ６０２          ノードＨの送信Resv Message
Ｔ６０４          ノードＡの送信Resv Message
Ｔ６０６          ノードＢの送信Resv Message
Ｔ６０８          ノードＣの送信Resv Message
Ｔ６５４          ノードＡのResv State
Ｔ６５６          ノードＢのResv State
Ｔ６５８          ノードＣのResv State
Ｔ６６０          ノードＴのResv State
【図１】
0004342580.tif 000002
【図２】
0004342580.tif 000003
【図３】
0004342580.tif 000004
【図４】
0004342580.tif 000005
【図５】
0004342580.tif 000006
【図６】
0004342580.tif 000007
【図７】
0004342580.tif 000008
【図８】
0004342580.tif 000009
【図９】
0004342580.tif 000010
【図１０】
0004342580.tif 000011
【図１１】
0004342580.tif 000012
【図１２】
0004342580.tif 000013
【図１３】
0004342580.tif 000014
【図１４】
0004342580.tif 000015
【図１５】
0004342580.tif 000016
【図１６】
0004342580.tif 000017
【図１７】
0004342580.tif 000018
【図１８】
0004342580.tif 000019
【図１９】
0004342580.tif 000020
【図２０】
0004342580.tif 000021
【図２１】
0004342580.tif 000022
【図２２】
0004342580.tif 000023
【図２３】
0004342580.tif 000024
【図２４】
0004342580.tif 000025
【図２５】
0004342580.tif 000026
【図２６】
0004342580.tif 000027
【図２７】
0004342580.tif 000028
【図２８】
0004342580.tif 000029
【図２９】
0004342580.tif 000030
【図３０】
0004342580.tif 000031