(57)【要約】【課題】  トンネルを用いてパケットを伝送する通信ネットワークにおいて、回線障害発生時のトンネル障害の検出を高速化し、ネットワークの負荷を低減する。【解決手段】  Ｃｏｒｅ＃Ｂ−Ｔａｉｌ  Ｅｎｄ間の回線障害が発生すると、Ｃｏｒｅ＃Ｂのルータは、上流のＣｏｒｅ＃Ａに対して、回線単位の障害発生を通知するＨｅｌｌｏメッセージを送信し、Ｃｏｒｅ＃Ａのルータは、そのメッセージを受けて、上流のＨｅａｄ  Ｅｎｄに対して障害通知のＨｅｌｌｏメッセージを送信する。Ｈｅａｄ  Ｅｎｄのルータは、そのメッセージを受信すると、障害が発生した回線を通過する複数のトンネルの切断処理を行い、復旧通知のＨｅｌｌｏメッセージを受信するまでトンネルの設定を待ち合わせる。【選択図】図２
2006033124.tif 000002
【特許請求の範囲】
【請求項１】
トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
前記通信ネットワーク内の回線上における障害の発生を検出する検出手段と、
前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する通知手段と
を備えることを特徴とするトンネル障害通知装置。
【請求項２】
トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する通知手段と
を備えることを特徴とするトンネル障害通知装置。
【請求項３】
トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うトンネル障害処理装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる制御手段と
を備えることを特徴とするトンネル障害処理装置。
【請求項４】
トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うトンネル障害処理装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う制御手段と
を備えることを特徴とするトンネル障害処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイルＩＰ（Internet Protocol ）ネットワークやＶＯＩＰ（Voice over Internet Protocol）のようなリアルタイムアプリケーション等、トラフィックエンジニアリングを適用し、回線リソース（帯域）を予約して信頼性の高いサービスを提供するＩＰネットワークにおいて、トンネル障害を通知する装置および方法に関する。
【背景技術】
【０００２】
トンネル技術は、あるプロトコルで記述されたパケットを別のプロトコルでカプセル化して通信を行う技術である（例えば、特許文献１参照）。この技術によれば、１つの物理回線上に複数のトンネルを構築することが可能である。ＲＦＣ３２０９（非特許文献１）には、ＬＳＰ（Label-Switched Paths）トンネルに対する資源予約プロトコル（Resource ReSerVation Protocol ，以下ＲＳＶＰという）の拡張について記述されている。
【０００３】
ＲＳＶＰによってＩＰパケットの高速伝送のためにトンネル技術を利用した伝送を実施している場合において、ネットワーク上に予約されたトンネル（帯域）が回線障害となった場合、ＲＳＶＰは、回線配下に存在する全トンネルに対して、切断メッセージを隣接ノードに向けて送信する。この際に、トンネル開始ノードであるＨｅａｄ  Ｅｎｄが切断メッセージを受信した場合は、受信した切断メッセージを元に該当トンネルの切断処理を行う。トンネルが現用・予備構成を持っている場合は、トンネル切断時にトンネル切り替えを行う。
【０００４】
図２５は、４つのルータからなるＩＰネットワークの構成例を示している。図２５のルータ１１および１４は、それぞれトンネル開始ノード（Ｈｅａｄ  Ｅｎｄ）および終了ノード（Ｔａｉｌ  Ｅｎｄ）のルータであり、ルータ１２および１３は、開始ノードと終了ノードの間でＩＰパケットを中継する中継ノード（Ｃｏｒｅ＃ＡおよびＣｏｒｅ＃Ｂ）のルータである。
【０００５】
図２６は、図２５のＩＰネットワークにおけるトンネルの構成例を示している。Ｈｅａｄ  Ｅｎｄ−Ｃｏｒｅ＃Ａ間、Ｃｏｒｅ＃Ａ−Ｃｏｒｅ＃Ｂ間、およびＣｏｒｅ＃Ｂ−Ｔａｉｌ  Ｅｎｄ間は、１００Ｍの帯域を持つ物理回線２１、２２、および２３によりそれぞれ接続されており、これらの回線上に１Ｍの帯域を持つｎ個のトンネル１〜ｎが確立されている。
【０００６】
このネットワーク構成においてＣｏｒｅ＃Ｂ−Ｔａｉｌ  Ｅｎｄ間の回線障害が発生した場合、図２７に示すように、Ｃｏｒｅ＃Ｂは、上流のＣｏｒｅ＃Ａに対してトンネルｎ個分の障害通知（切断メッセージ）を送信する（ステップ３１）。Ｃｏｒｅ＃Ａは、Ｃｏｒｅ＃Ｂからのトンネルｎ個分の切断メッセージを受けて、上流のＨｅａｄ  Ｅｎｄに対してトンネルｎ個分の切断メッセージを送信する。
【０００７】
Ｈｅａｄ  Ｅｎｄは、トンネル毎に切断メッセージを受信した契機に、障害発生トンネルの切断処理を行う（ステップ３２−１〜３２−ｎ）。また、Ｈｅａｄ  Ｅｎｄの隣接ノードであるＣｏｒｅ＃Ａには障害が発生していないため、Ｅｘｐｌｉｃｉｔで定義トンネルの再確立を行う。ここで、「Ｅｘｐｌｉｃｉｔで」とは、トンネルの経路を明示的に指定することを意味する。回線障害が復旧していない場合は、Ｃｏｒｅ＃Ｂにおいて設定ＮＧとなってしまうが、Ｔａｉｌ  Ｅｎｄから設定ＯＫが返送されるまでは、繰り返しトンネル再確立が行われる。
【０００８】
図２８は、８つのルータからなる別のＩＰネットワークの構成例を示している。図２８のルータ４１および４６は、それぞれＨｅａｄ  ＥｎｄおよびＴａｉｌ  Ｅｎｄのルータであり、ルータ４２〜４５、４７、および４８は、中継ノード（Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、Ｃｏｒｅ＃Ｄ、Ｃｏｒｅ＃Ｅ、およびＣｏｒｅ＃Ｆ）のルータである。
【０００９】
このネットワーク構成において、トンネルの高速障害切り替えであるＦａｓｔ  Ｒｅｒｏｕｔｅが実装されている場合、従来技術では現用系と予備系の開始点が一致するノード（Point of Local Repair，ＰＬＲ）であるＣｏｒｅ＃Ａにおいて、現用トンネルと予備トンネルの切り替えが行われる。
【００１０】
現用トンネルは、Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、およびＣｏｒｅ＃Ｄを経由し、予備トンネルは、Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｅ、Ｃｏｒｅ＃Ｆ、およびＣｏｒｅ＃Ｄを経由する。例えば、Ｃｏｒｅ＃Ａの隣接ノードであるＣｏｒｅ＃Ｂに障害が発生した場合、Ｃｏｒｅ＃Ａが予備系側にトンネルを切り替えることができる。
【００１１】
ＲＳＶＰのＨｅｌｌｏ機能は、隣接ノードとＨｅｌｌｏメッセージを一定周期で送受信し、お互いのＲＳＶＰプロトコルが正常状態（サービス状態）であることを確認し合う機能である。Ｈｅｌｌｏメッセージは、各ノードの回線単位でやりとりされる。送受信の周期は、Ｈｅｌｌｏ  Ｉｎｔｅｒｖａｌタイマと呼ばれ、このタイマがタイムアウトした場合、Ｈｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）が送信される。
【００１２】
例えば、ノードＡとノードＢの間でＨｅｌｌｏメッセージがやりとりされる場合、図２９に示すように、ノードＡは、ノードＢにＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）を送信した後、Ｈｅｌｌｏ  Ｉｎｔｅｒｖａｌタイマをリセットする（ステップ５１）。
【００１３】
ノードＢは、ノードＡからＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）を受信すると、受信したＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）に対してＨｅｌｌｏメッセージ（Ａｃｋ）を返却するので、タイムアウト契機でのＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）の送信は不要となる。そこで、Ｈｅｌｌｏ  Ｉｎｔｅｒｖａｌタイマをリセットする（ステップ５２）。また、Ｈｅｌｌｏ  Ｌｉｆｅタイマもリセットする（ステップ５３）。
【００１４】
Ｈｅｌｌｏ  Ｌｉｆｅタイマの時間内にＨｅｌｌｏメッセージ（Ｒｅｑｕｅｓｔ）あるいはＨｅｌｌｏメッセージ（Ａｃｋ）を受信しなかった場合、隣接ノードに障害が発生したものとみなされる。ノードＡは、ノードＢからＨｅｌｌｏメッセージ（Ａｃｋ）を受信したとき、Ｈｅｌｌｏ  Ｌｉｆｅタイマをリセットする（ステップ５４）。
【特許文献１】特開２００２−３１４５８２号公報
【非特許文献１】“RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC3209, 2001
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかしながら、上述した従来の回線障害通知方法には、以下のような問題がある。
（１）ネットワークトポロジによっては、１つの回線配下に大量のトンネルが存在する場合があり、回線障害発生時に大量のトンネル切断が発生する。これにより、大量のトンネル切断メッセージを隣接ノードに通知しなければならず、ネットワーク内に大量のメッセージが流入し、ネットワークの負荷を上げる恐れがある。また、ＲＳＶＰはＵＤＰ（User Datagram Protocol）であるために、到達確認が行えない。大量のトンネル切断時には、パケットロス等の理由によりメッセージが紛失し、トンネル切断が迅速に行えない可能性がある。
（２）回線障害が復旧していない状態であったとしても、Ｈｅａｄ  Ｅｎｄから見た隣接ノード（図２５のＣｏｒｅ＃Ａ）に障害が発生していない場合は、ＲＳＶＰのプロトコル動作としては、切断したトンネルのためのトンネル設定要求を下流ノードに対して送信する（Ｅｘｐｌｉｃｉｔで指定されたトンネルのみ）。したがって、回線障害が復旧するまでの間、不要なメッセージがネットワークに流入し、ネットワークの負荷が上がってしまう恐れがある。
（３）Ｆａｓｔ  Ｒｅｒｏｕｔｅは、隣接ノードでの障害発生時のみトンネル切り替えが可能である。図２８のネットワーク構成の場合、Ｃｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間またはＣｏｒｅ＃Ｃ−Ｃｏｒｅ＃Ｄ間で障害が発生すると、Ｆａｓｔ  Ｒｅｒｏｕｔｅによるトンネル切り替えを行うことができない。
【００１６】
本発明の課題は、回線障害発生時のトンネル障害の検出を高速化し、ネットワークの負荷を低減することである。
本発明のもう１つの課題は、現用系と予備系の開始点が一致するノードの隣接ノード以外で障害が発生した場合でも、Ｆａｓｔ  Ｒｅｒｏｕｔｅを行えるようにすることである。
【課題を解決するための手段】
【００１７】
図１は、本発明のトンネル障害通知装置およびトンネル障害処理装置の原理図である。
本発明の第１の局面において、トンネル障害通知装置は、検出手段１０１および通知手段１０２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知する。検出手段１０１は、通信ネットワーク内の回線上における障害の発生を検出し、通知手段１０２は、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、障害の発生を回線単位で隣接ノードに通知する。
【００１８】
本発明の第２の局面において、第１の局面におけるトンネル障害通知装置は、格納手段１０３をさらに備える。格納手段１０３は、障害が発生した回線の回線情報を格納し、通知手段１０２は、その回線情報が異常を示すとき、障害の発生を隣接ノードに通知する。
【００１９】
第１および第２の局面におけるトンネル障害通知装置によれば、障害が発生した回線配下の複数のトンネルの切断メッセージが１つに集約されて隣接ノードに通知されるので、トンネル障害を高速に通知することができ、ネットワークの負荷が低減される。
【００２０】
本発明の第３の局面において、トンネル障害通知装置は、受信手段１１１および通知手段１１２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知する。受信手段１１１は、通信ネットワーク内の回線上で障害が発生したとき、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信する。通知手段１１２は、受信した障害通知に基づいて、障害の発生を回線単位で第２の隣接ノードに通知する。
【００２１】
本発明の第４の局面において、第３の局面におけるトンネル障害通知装置は、格納手段１１３をさらに備える。格納手段１１３は、障害が発生した回線の回線情報を格納し、通知手段１１２は、その回線情報が異常を示すとき、障害の発生を第２の隣接ノードに通知する。
【００２２】
第３および第４の局面におけるトンネル障害通知装置によれば、第１および第２の局面におけるトンネル障害通知装置の場合と同様に、障害が発生した回線配下の複数のトンネルの切断メッセージが１つに集約されて隣接ノードに通知されるので、トンネル障害を高速に通知することができ、ネットワークの負荷が低減される。
【００２３】
本発明の第５の局面において、トンネル障害通知装置は、受信手段１２１および制御手段１２２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行う。受信手段１２１は、通信ネットワーク内の回線上で障害が発生したとき、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する。制御手段１２２は、受信した障害通知に基づいて、複数のトンネルの切断処理を行った後、障害の復旧を通知する復旧通知を受信するまでそれらのトンネルの再確立を待ち合わせる。
【００２４】
本発明の第６の局面において、第５の局面におけるトンネル障害通知装置は、格納手段１２３および回線管理手段１２４をさらに備える。格納手段１２３は、通信ネットワーク内の複数の回線の回線情報を格納し、回線管理手段１２４は、障害通知を受信したとき、障害が発生した回線の回線情報を正常から異常に変更する。制御手段１２２は、障害が発生した回線の回線情報が異常に変更されたとき、複数のトンネルの切断処理を行う。
【００２５】
第５および第６の局面におけるトンネル障害処理装置によれば、障害が発生した回線配下のトンネルの再確立は障害が復旧するまで行われないので、不要なトンネルの再確立が抑止され、ネットワークの負荷が低減される。
【００２６】
本発明の第７の局面において、トンネル障害通知装置は、受信手段１２１および制御手段１２２を備え、トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行う。受信手段１２１は、通信ネットワーク内の回線上で障害が発生したとき、障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する。制御手段１２２は、受信した障害通知に基づいて、それらのトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う。
【００２７】
本発明の第８の局面において、第７の局面におけるトンネル障害通知装置は、格納手段１２３および回線管理手段１２４をさらに備える。格納手段１２３は、通信ネットワーク内の複数の回線の回線情報を格納し、回線管理手段１２４は、障害通知を受信したとき、障害が発生した回線の回線情報を正常から異常に変更する。制御手段１２２は、障害が発生した回線の回線情報が異常に変更されたとき、現用トンネルから予備トンネルへの切り替え処理を行う。
【００２８】
第７および第８の局面におけるトンネル障害処理装置によれば、現用系と予備系の開始点が一致するノードの隣接ノード以外で障害が発生した場合でも、回線単位の障害通知により回線障害を認識できるので、障害が発生した回線を通過する現用トンネルから、その回線を迂回する予備トンネルへの切り替えを行うことができる。
【００２９】
検出手段１０１は、例えば、後述する図３のルーティング制御モジュール３１３に対応し、通知手段１０２および１１２は、例えば、図３のＨｅｌｌｏ制御モジュール３１６に対応し、受信手段１１１および１２１は、例えば、図３のＳｅｓｓｉｏｎ制御モジュール３１１に対応する。制御手段１２２は、例えば、図３のＳｅｓｓｉｏｎ制御モジュール３１１に対応し、回線管理手段１２４は、例えば、図３の回線管理モジュール３１４に対応する。格納手段１０３、１１３、および１２３は、例えば、ルータ内のメモリに対応する。
【発明の効果】
【００３０】
本発明によれば、回線障害発生時のトンネル障害を、大量のトンネル切断メッセージを送信することなく、高速に検出することができる。これにより、信頼性の高いサービスを提供することが可能になる。
【００３１】
また、現用系と予備系の開始点が一致するノードの隣接ノード以外で障害が発生した場合でも、Ｆａｓｔ  Ｒｅｒｏｕｔｅを行うことが可能になる。
【発明を実施するための最良の形態】
【００３２】
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
本発明における主な改善点は、以下の通りである。
（１）Ｈｅｌｌｏメッセージによる回線単位でのトンネル切断メッセージの送信
従来技術では、回線障害が発生した場合でも、回線配下のトンネル単位に切断メッセージを送信しているが、本発明では回線単位にて切断メッセージを隣接ノードに通知するようにメッセージを集約する。これにより、トンネル障害を高速に通知することができるとともに、ネットワークへの大量のメッセージの流入が抑えられ、ネットワークの負荷を低減させることができる。
（２）不要なトンネル再確立の防止
従来技術では、回線障害が発生している場合でも、トンネル切断後に該当トンネルの再確立を行っている。本発明では、Ｈｅａｄ  Ｅｎｄが障害となった回線を認識し、その回線に対応する復旧通知を受信するまでは、該当回線配下のトンネルの再確立を抑止する。復旧通知は、障害通知と同様に回線単位にて行う。これにより、ネットワークへの不要なメッセージの流入が抑えられ、ネットワークの負荷を低減させることができる。
（３）Ｆａｓｔ  Ｒｅｒｏｕｔｅへの適用
従来技術では、現用系と予備系の開始点が一致するノードの隣接ノードにて障害が発生した場合にのみ、Ｆａｓｔ  Ｒｅｒｏｕｔｅを適用可能である。本発明では、（１）の障害通知を用いて、現用系と予備系の開始点が一致するノードに回線障害を認識させ、隣接ノード以外の障害発生時においても、Ｆａｓｔ  Ｒｅｒｏｕｔｅが機能できるようにする。
【００３３】
図２は、上記改善点を盛り込んだ、回線障害発生時の障害通知シーケンスを示している。図２５のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｔａｉｌ  Ｅｎｄ間の回線障害が発生した場合、Ｃｏｒｅ＃Ｂは、上流のＣｏｒｅ＃Ａに対して、回線単位の障害発生を通知するＨｅｌｌｏメッセージを送信する（ステップ２０１）。Ｃｏｒｅ＃Ａは、Ｃｏｒｅ＃ＢからのＨｅｌｌｏメッセージを受けて、上流のＨｅａｄ  Ｅｎｄに対して障害通知のＨｅｌｌｏメッセージを送信する。
【００３４】
Ｈｅａｄ  Ｅｎｄは、Ｈｅｌｌｏメッセージを受信すると、障害が発生したＣｏｒｅ＃Ｂ−Ｔａｉｌ  Ｅｎｄ間を通過するトンネルを抽出し（ステップ２０２）、トンネルの切断処理を行う（ステップ２０３−１〜２０３−ｎ）。そして、回線障害が復旧するまでトンネルの設定を待ち合わせる（ステップ２０４）。
【００３５】
次に、Ｃｏｒｅ＃Ｂ−Ｔａｉｌ  Ｅｎｄ間の回線障害が復旧すると、Ｃｏｒｅ＃Ｂは、上流のＣｏｒｅ＃Ａに対して、回線単位の障害復旧を通知するＨｅｌｌｏメッセージを送信する（ステップ２０５）。Ｃｏｒｅ＃Ａは、Ｃｏｒｅ＃ＢからのＨｅｌｌｏメッセージを受けて、上流のＨｅａｄ  Ｅｎｄに対して復旧通知のＨｅｌｌｏメッセージを送信する。
【００３６】
Ｈｅａｄ  Ｅｎｄは、Ｈｅｌｌｏメッセージを受信すると、障害が復旧したＣｏｒｅ＃Ｂ−Ｔａｉｌ  Ｅｎｄ間を通過するトンネルを抽出し（ステップ２０６）、Ｅｘｐｌｉｃｉｔで定義トンネルの再確立を行う。
【００３７】
このような障害通知シーケンスによれば、図２７の障害通知シーケンスと比較して、障害通知のための処理数が大幅に軽減される。また、回線障害の復旧通知を受信してからトンネルの設定を行うので、復旧前の不要なトンネル設定処理が削減される。
【００３８】
図３は、本実施形態における各ルータに共通のモジュール構成を示している。図３のルータは、経路管理部３０１およびＲＳＶＰ管理部３０２を備え、ＲＳＶＰ管理部３０２は、Ｓｅｓｓｉｏｎ制御モジュール３１１、メッセージ制御モジュール３１２、ルーティング制御モジュール３１３、回線管理モジュール３１４、タイマ制御モジュール３１５、およびＨｅｌｌｏ制御モジュール３１６を含む。経路管理部３０１は、経路を管理する。
【００３９】
ＲＳＶＰ管理部３０２のＳｅｓｓｉｏｎ制御モジュール３１１は、トンネルの接続、切断、切り替え、Ｒｅｆｒｅｓｈ等、トンネル制御全般を行うとともに、ＲＳＶＰメッセージの受信・送信を実施する。Ｈｅｌｌｏメッセージを受信した場合は、受信したメッセージをＨｅｌｌｏ制御モジュール３１６に渡す。また、トンネル接続時に回線障害が発生している配下トンネルの接続を抑止する機能を備える。
【００４０】
メッセージ制御モジュール３１２は、ＲＳＶＰ  Ｓｅｓｓｉｏｎ制御メッセージ・オブジェクトの分析、編集、比較を行う。
ルーティング制御モジュール３１３は、トンネルアドレスについて自局宛判定および出側ルートの特定を実施する。また、Ｅｘｐｌｉｃｉｔの場合のルート情報の妥当性判定および情報の更新も実施する。また、回線障害の通知を受け付けて、Ｈｅｌｌｏ制御モジュール３１６に通知する。
【００４１】
回線管理モジュール３１４は、ＲＳＶＰで使用する回線情報と帯域情報を管理する。また、回線障害発生時のトンネル解放要求も実施する。
タイマ制御モジュール３１５は、Ｓｅｓｓｉｏｎ制御タイマ（ＰａｔｈのＩｎｔｅｒｖａｌ、ＲｅｆｒｅｓｈのＩｎｔｅｒｖａｌ等）を制御する。また、Ｈｅｌｌｏ制御モジュール３１６を周期的に起動する。
【００４２】
Ｈｅｌｌｏ制御モジュール３１６は、Ｈｅｌｌｏメッセージの送受信を行い、メッセージ送信の際に自ノード内に回線障害が発生したか否か、回線障害が復旧したか否かを回線管理モジュール３１４に問い合わせ、障害／復旧情報をＨｅｌｌｏメッセージに付与してメッセージ送信を行う。
【００４３】
また、自ノード内では発生しておらず、受信したＨｅｌｌｏメッセージに障害／復旧情報が付与されていた場合には、回線管理モジュール３１４が管理している回線情報を更新し、イベント駆動にて障害／復旧情報を付与してＨｅｌｌｏメッセージ送信を行う。
【００４４】
新たに隣接ノードからの障害情報を回線情報に設定した場合は復旧メッセージを受信するまで、復旧情報を設定した場合は障害メッセージを受信するまでは、更新された回線情報を保持し、その情報に応じたＨｅｌｌｏメッセージを一定周期で送信する。また、Ｈｅｌｌｏタイマ（Ｉｎｔｅｒｖａｌ、Ｌｉｆｅ）の制御を実施し、Ｈｅｌｌｏエラー検出時にはトンネル解放を実施する。
【００４５】
経路管理部３０１およびＲＳＶＰ管理部３０２の各モジュールの機能は、ハードウェアまたはソフトウェアにより実現される。ソフトウェアにより実現する場合、ルータ内のメモリに、経路管理部３０１およびＲＳＶＰ管理部３０２に対応するプログラムと、回線情報等のデータが格納され、ルータ内のプロセッサがメモリを利用してプログラムを実行することにより、経路管理部３０１およびＲＳＶＰ管理部３０２の処理を行う。
【００４６】
ＲＳＶＰ管理部３０２のプログラムは、Ｓｅｓｓｉｏｎ制御モジュール３１１、メッセージ制御モジュール３１２、ルーティング制御モジュール３１３、回線管理モジュール３１４、タイマ制御モジュール３１５、およびＨｅｌｌｏ制御モジュール３１６の各プログラムを含む。
【００４７】
これらのプログラムおよびデータは、通信ネットワークや可搬記録媒体を介してユーザに提供され、情報処理装置を介してルータ内のメモリにロードされる。このとき、提供者の情報処理装置は、プログラムおよびデータを搬送する搬送信号を生成し、通信ネットワーク上の伝送媒体を介してユーザの情報処理装置に送信する。可搬記録媒体としては、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体が用いられる。
【００４８】
次に、図４から図８までを参照しながら、図２８のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で回線障害が発生した場合の動作を説明する。
図４に示すように、Ｈｅａｄ  Ｅｎｄ、Ｔａｉｌ  Ｅｎｄ、Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、Ｃｏｒｅ＃Ｄ、Ｃｏｒｅ＃Ｅ、およびＣｏｒｅ＃Ｆのネットワークアドレスを、それぞれ、Ｘ．Ｘ．Ｘ．Ｘ、Ｙ．Ｙ．Ｙ．Ｙ、Ａ．Ａ．Ａ．Ａ、Ｂ．Ｂ．Ｂ．Ｂ、Ｃ．Ｃ．Ｃ．Ｃ、Ｄ．Ｄ．Ｄ．Ｄ、Ｅ．Ｅ．Ｅ．Ｅ、およびＦ．Ｆ．Ｆ．Ｆとする。また、Ｈｅａｄ  Ｅｎｄ−Ｔａｉｌ  Ｅｎｄ間の現用トンネルとしてトンネル１およびトンネル２が確立されており、予備トンネルとしてトンネル３およびトンネル４が確立されているものとする。
【００４９】
回線管理モジュール３１４が回線情報として管理するデータは、Ｈｅａｄ  Ｅｎｄとそれ以外のノードとで保持するデータが異なる。図５は、Ｈｅａｄ  Ｅｎｄに保持される回線情報の例を示している。この回線情報には、トンネルが通過するすべての回線の情報が含まれる。回線識別情報は、回線を一意に識別するための情報であり、回線が接続している２つのノードのネットワークアドレスを含む。回線状態は、回線が正常か異常かを表し、配下トンネルは、回線を通過するすべてのトンネルの識別情報を含む。
【００５０】
Ｈｅａｄ  Ｅｎｄは、Ｃｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間の障害を認識した時点で、“Ｂ．Ｂ．Ｂ．Ｂ−Ｃ．Ｃ．Ｃ．Ｃ”の回線の回線状態を“正常”から“異常”に更新する。
一方、Ｈｅａｄ  Ｅｎｄ以外のノード（Ｃｏｒｅ＃Ａ、Ｃｏｒｅ＃Ｂ、Ｃｏｒｅ＃Ｃ、Ｃｏｒｅ＃Ｄ、Ｃｏｒｅ＃Ｅ、Ｃｏｒｅ＃Ｆ、Ｔａｉｌ  Ｅｎｄ）には、図６に示すような回線情報が保持される。この回線情報は“異常”のみの管理を行うために用いられ、回線障害が発生した時に発生した数だけのデータが作成される。したがって、例えば、新たにＣｏｒｅ＃Ｃ−Ｃｏｒｅ＃Ｄ間で障害が発生した場合は、Ｈｅａｄ  Ｅｎｄの回線情報は図７のようになり、それ以外のノードの回線情報は図８のようになる。
【００５１】
回線障害が復旧したとき、Ｈｅａｄ  Ｅｎｄが保持するデータは“異常”から“正常”に更新される。また、それ以外のノードが保持するデータは削除される。したがって、障害が発生していない定常時には、Ｈｅａｄ  Ｅｎｄ以外のノードは、図６および８に示すようなデータを保持していない。
【００５２】
また、図５〜８に示した回線情報を用いずに、従来技術でトンネルを確立しているときに保持しているトンネル情報内の回線情報を用いて、回線状態を管理してもよい。従来からこの回線状態の正常／異常を管理している場合は、受信したＨｅｌｌｏメッセージを元に回線状態の正常／異常を更新する。回線状態の正常／異常を管理していない場合は、正常／異常を示すフィールドを回線情報に追加すればよい。
【００５３】
次に、図９から図１４までを参照しながら、障害通知に用いられるＨｅｌｌｏメッセージについて説明する。
図９および１０は、それぞれ、ＲＦＣ３２０９で規定されているＲＳＶＰ  ＨｅｌｌｏメッセージおよびＲＳＶＰ  ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのフォーマットを示している。図９のＲＳＶＰ  Ｈｅｌｌｏメッセージに含まれるＣｏｍｍｏｎ  Ｈｅａｄｅｒは、図１１に示すようなフォーマットを有する。
【００５４】
本実施形態では、定常時は図９のフォーマットでＨｅｌｌｏメッセージを送信するが、回線障害発生時には、図９と図１０を組み合わせたフォーマットでＨｅｌｌｏメッセージを送信する。後者のＨｅｌｌｏメッセージのフォーマットは、図１２のようになる。
【００５５】
図４のネットワーク構成においてネットワークアドレスＢ．Ｂ．Ｂ．Ｂ（Ｃｏｒｅ＃Ｂ）とＣ．Ｃ．Ｃ．Ｃ（Ｃｏｒｅ＃Ｃ）間において回線障害が発生した場合、障害を検出したノード（Ｃｏｒｅ＃ＢとＣｏｒｅ＃Ｃ）は、回線障害が発生したネットワークアドレスを図１０のＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのＩＰｖ４Ａｄｄｒｅｓｓに書き込み、図１２のフォーマットにて隣接ノードにＨｅｌｌｏメッセージを送信する。図１２のその他のデータメンバには従来と同様のデータが設定される。
【００５６】
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトは、図１３に示すように、従来技術ではＲＳＶＰのＰａｔｈ／Ｒｅｓｖメッセージが転送されたルートを記録する機能として用いられる。Ｈｅａｄ  Ｅｎｄルータ１１は、常時ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＰａｔｈメッセージを送信する。
【００５７】
Ｃｏｒｅルータ１２、１３は、受信したＰａｔｈ／ＲｅｓｖメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されている場合にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＰａｔｈ／Ｒｅｓｖメッセージを送信する。Ｔａｉｌ  Ｅｎｄルータ１４は、受信したＰａｔｈメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されている場合にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＲｅｓｖメッセージを送信する。
【００５８】
本実施形態では、図１４に示すように、このＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトをＲＳＶＰ  Ｈｅｌｌｏメッセージにも適用する。回線障害を検出したノードは、障害検出時にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。それ以降は、通常通り周期起動にて、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。この動作は、障害が復旧するまで継続する。
【００５９】
この例では、ネットワークアドレス“Ｂ．Ｂ．Ｂ．Ｂ”および“Ｃ．Ｃ．Ｃ．Ｃ”が書き込まれたＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを有するＨｅｌｌｏメッセージが送信されている。
【００６０】
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されたＨｅｌｌｏメッセージを受信したノードは、第１回目の受信時には、イベント駆動にて同様にＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを設定して隣接ノードにＨｅｌｌｏメッセージを送信する。２回目以降は、通常通り周期起動にて、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。この動作は、障害が復旧するまで継続する。
【００６１】
次に、本発明の障害通知機能を具備していないノードがネットワーク内に存在する場合の処理について説明する。
この場合、障害が認識されない問題を回避するために、ＲＳＶＰ−ＴＥメッセージのＣｏｍｍｏｎ  Ｈｅａｄｅｒに含まれるＦｌａｇｓを使用する。Ｆｌａｇｓは、ＲＦＣ３２０９にて未使用と定義されている。そこで、本発明の障害通知を適用するノードは、Ｆｌａｇｓに常時本発明が適用されていることを示すユニークな値（例えば、“３”等）を設定してメッセージを送信する。これにより、本発明が適用されていないノードからは、Ｆｌａｇｓにユニークな値が設定されずに（通常は“０”が設定されて）メッセージが送信されてくるため、本発明の適用可否を判断することが可能である。
【００６２】
次に、図１５から図１９までを参照しながら、障害発生時および復旧時の動作についてより詳細に説明する。
図１５は、障害検出時のノード内処理シーケンスを示している。図４のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で回線障害が発生した場合、Ｃｏｒｅ＃ＢおよびＣｏｒｅ＃Ｃのルーティング制御モジュール３１３は、障害を検出し（ステップ１５０１）、Ｈｅｌｌｏ制御モジュール３１６に障害発生を通知する。
【００６３】
Ｈｅｌｌｏ制御モジュール３１６は、図６のような障害情報データを作成して回線管理モジュール３１４に転送し（ステップ１５０２）、回線管理モジュール３１４は、転送された障害情報データを回線情報としてメモリに格納する。
【００６４】
次に、Ｈｅｌｌｏ制御モジュール３１６は、回線管理モジュール３１４に対して障害情報があるか否かを問い合わせる（ステップ１５０３）。回線管理モジュール３１４は、図６の障害情報データがある場合は、その内容をＨｅｌｌｏ制御モジュール３１６に通知し、障害情報データがない場合は、その旨をＨｅｌｌｏ制御モジュール３１６に通知する。
【００６５】
Ｈｅｌｌｏ制御モジュール３１６は、図６の障害情報データを受け取った場合は、図１０のＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのＩＰｖ４Ａｄｄｒｅｓｓに回線障害が発生したネットワークアドレスを書き込む。そして、Ｓｅｓｓｉｏｎ制御モジュール３１１を介して、図１２のフォーマットにてＨｅｌｌｏメッセージを隣接ノード（Ｃｏｒｅ＃ＡまたはＣｏｒｅ＃Ｄ）に送信する。この場合、Ｈｅｌｌｏメッセージは、周期起動ではなくイベント駆動で送信される。
【００６６】
障害情報データがない場合は、Ｓｅｓｓｉｏｎ制御モジュール３１１を介して、図９のフォーマットにてＨｅｌｌｏメッセージを隣接ノードに送信する。
イベント駆動でＨｅｌｌｏメッセージを送信した後、Ｈｅｌｌｏ制御モジュール３１６は、タイマ制御モジュール３１５により一定周期で起動され、ステップ１５０３と同様の処理を繰り返す（ステップ１５０３）。そして、別回線の障害検出あるいは障害回線の復旧検出がない限り、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する。
【００６７】
Ｈｅａｄ  Ｅｎｄにおいて回線障害が検出された場合は、ステップ１５０２において、回線管理モジュール３１４は、転送された障害情報データを元に、メモリ内に保持された図５のような回線情報を正常から異常に更新する。
【００６８】
図１６は、障害発生を通知するＨｅｌｌｏメッセージを受信したときのノード内処理シーケンスを示している。Ｓｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏメッセージ受信をＨｅｌｌｏ制御モジュール３１６に通知し、Ｈｅｌｌｏ制御モジュール３１６は、受信したＨｅｌｌｏメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されているか否かをチェックする（ステップ１６０１）。
【００６９】
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されている場合は、障害発生を認識して、そのオブジェクトを元に障害情報データを作成して回線管理モジュール３１４に転送し（ステップ１６０２）、回線管理モジュール３１４は、転送された障害情報データを回線情報としてメモリに格納する。このとき、受信ノードがＨｅａｄ  Ｅｎｄであれば、図５のような回線情報が正常から異常に更新され、それ以外のノードであれば、図６のような回線情報が作成される。
【００７０】
次に、Ｈｅｌｌｏ制御モジュール３１６は、図１５のステップ１５０３および１５０４と同様の処理を行って、別回線の障害検出あるいは障害回線の復旧検出がない限り、同様のＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを付与したＨｅｌｌｏメッセージを送信する（ステップ１６０３および１６０４）。
【００７１】
前述したように、従来技術では、回線障害が発生している場合でも、トンネル切断後に該当トンネルの再確立を行っている。例えば、Ｅｘｐｌｉｃｉｔで定義されているトンネルについては、図４のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で回線障害が発生している場合に、Ｈｅａｄ  Ｅｎｄでは、Ｃｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間の障害が発生していることをプロトコル動作上認識できないためである。本実施形態では、Ｈｅａｄ  Ｅｎｄ内に保持された回線情報を利用して、この問題を回避する。
【００７２】
図１７は、図２の障害通知シーケンスにおいて、トンネルの再確立を抑止する処理を示している。Ｈｅａｄ  Ｅｎｄのタイマ制御モジュール３１５は、Ｓｅｓｓｉｏｎ制御モジュール３１１によるトンネル確立処理を一定周期で起動し、Ｓｅｓｓｉｏｎ制御モジュール３１１は、回線管理モジュール３１４に対して、該当トンネルが通過する回線の状態を問い合わせる。回線管理モジュール３１４は、回線情報を参照して、該当回線の回線状態をＳｅｓｓｉｏｎ制御モジュール３１１に通知する。
【００７３】
Ｓｅｓｓｉｏｎ制御モジュール３１１は、受け取った回線状態をチェックし（ステップ１７０１）、異常であれば、トンネル確立要求を送信せずに、回線状態の問い合わせを繰り返す。そして、回線状態が正常になれば、障害復旧を認識して、下流ノードへトンネル確立要求を送信する（ステップ１７０２）。
【００７４】
図１８は、復旧検出時のノード内処理シーケンスを示している。図４のネットワーク構成においてＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間で発生していた回線障害が復旧した場合、Ｃｏｒｅ＃ＢおよびＣｏｒｅ＃Ｃのルーティング制御モジュール３１３は、復旧を検出し（ステップ１８０１）、Ｈｅｌｌｏ制御モジュール３１６に障害復旧を通知する。Ｈｅｌｌｏ制御モジュール３１６は、回線管理モジュール３１４を介して図６の障害情報データを削除する（ステップ１８０２）。
【００７５】
次に、Ｈｅｌｌｏ制御モジュール３１６は、図１５のステップ１５０３および１５０４と同様の処理を行って、Ｈｅｌｌｏメッセージを送信する。この場合、障害情報データがなくなったので、図１２のＨｅｌｌｏメッセージからＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを削除して、図９のフォーマットにてＨｅｌｌｏメッセージを隣接ノードに送信する（ステップ１８０３）。その後、新たな回線障害や復旧の検出がない限り、Ｈｅｌｌｏメッセージを一定周期で送信する（ステップ１８０４）。
【００７６】
Ｈｅａｄ  Ｅｎｄにおいて復旧が検出された場合は、ステップ１８０２において、回線管理モジュール３１４を介して図５の回線情報が異常から正常に更新される。
図１９は、障害復旧を通知するＨｅｌｌｏメッセージを受信したときのノード内処理シーケンスを示している。Ｓｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏメッセージ受信をＨｅｌｌｏ制御モジュール３１６に通知し、Ｈｅｌｌｏ制御モジュール３１６は、受信したＨｅｌｌｏメッセージにＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されているか否かをチェックする（ステップ１９０１）。
【００７７】
ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトが付与されていない場合は、障害復旧を認識して、回線管理モジュール３１４を介して回線情報を変更する（ステップ１９０２）。このとき、受信ノードがＨｅａｄ  Ｅｎｄであれば、図５のような回線情報が異常から正常に更新され、それ以外のノードであれば、図６のような該当回線の回線情報が削除される。
【００７８】
次に、Ｈｅｌｌｏ制御モジュール３１６は、図１５のステップ１５０３および１５０４と同様の処理を行って、新たな回線障害や復旧の検出がない限り、同様のＨｅｌｌｏメッセージを送信する（ステップ１９０３および１９０４）。
【００７９】
このような障害／復旧検出時の動作は高速トンネル障害切り替え方法であるＦａｓｔ  Ｒｅｒｏｕｔｅにも適用可能である。その場合は、上述したＨｅａｄ  Ｅｎｄが行う処理をすべてＦａｓｔ  Ｒｅｒｏｕｔｅの現用系と予備系の開始点が一致するノードが実施する。したがって、図４のネットワーク構成の場合は、Ｃｏｒｅ＃Ａが図５のような回線情報を保持する。これにより、Ｃｏｒｅ＃ＡがＣｏｒｅ＃Ｂ−Ｃｏｒｅ＃Ｃ間の回線障害を認識して、現用トンネルから予備トンネルに切り替えを行うことができる。
【００８０】
次に、図２０から図２４までを参照しながら、本発明の障害通知機能を具備していないノードがネットワーク内に存在する場合の処理について、より詳細に説明する。
図２０に示すようなネットワーク構成において、ネットワーク上に存在する３つのルータのうち、ルータ＃Ａおよび＃Ｃが本発明の障害通知機能を具備し、ルータ＃Ｂがこの機能を具備していないものとする。
【００８１】
図２１は、これらのルータ間の接続方法を示している。各ルータは複数のスロットを具備し、各スロットは複数の回線位置を有する。ネットワークを構成する際には、一方のルータの１つの回線位置と他方のルータの１つの回線位置がケーブル２１０１〜２１０３で物理的に接続される。
【００８２】
各ルータは、公知の技術により、自ルータから隣接ルータに向けてケーブルが接続されている回線位置を特定することが可能である。例えば、ルータ＃Ａにおいて、ルータ＃Ｃ向けにケーブル２１０１が接続されている回線位置は、（ｓｌｏｔ１，回線２）と認識しており、ルータ＃Ｂ向けにケーブル２１０３が接続されている回線位置は、（ｓｌｏｔ３，回線０）と認識している。ルータ＃Ｂおよび＃Ｃにおいても、同様にして回線位置を認識している。
【００８３】
この場合、ルータ＃Ａおよび＃Ｃは、それぞれ図２２および図２３に示すような管理データをメモリ内に保持する。これらの管理データにおいて、“ＯＮ”は、回線が本発明の障害通知機能を具備していることを表し、“ＯＦＦ”は、回線がその機能を具備していないことを表す。ルータ＃Ａおよび＃Ｃは、隣接ノードからのメッセージ受信時に、図１１のＣｏｍｍｏｎ  Ｈｅａｄｅｒ内のＦｌａｇｓの値を分析して、管理データの値を更新する。
【００８４】
図２４は、このようなメッセージ受信時のフラグ分析シーケンスを示している。本発明の障害通知機能を具備するノードのＳｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏメッセージ送信前、つまりトンネル確立を実施する際に送信されるＰａｔｈメッセージ、Ｒｅｓｖメッセージ等の一連のメッセージを受信したとき、各メッセージのＣｏｍｍｏｎ  Ｈｅａｄｅｒ内のＦｌａｇｓに含まれている値をチェックし（ステップ２４０１）、その値を所定値と比較する（ステップ２４０２）。
【００８５】
Ｆｌａｇｓの値が所定値であれば、発明動作が可能であることをＨｅｌｌｏ制御モジュール３１６に通知する。これにより、Ｈｅｌｌｏ制御モジュール３１６は、隣接ノードが本発明の障害通知機能を具備していると判断し、回線管理モジュール３１４を介して、メモリ内の管理データの該当回線の状態を“ＯＦＦ”から“ＯＮ”に更新する（ステップ２４０３）。これ以降、該当回線については、図１５〜１９に示した本発明の動作が行われる。
【００８６】
また、Ｆｌａｇｓの値が所定値でなければ、Ｓｅｓｓｉｏｎ制御モジュール３１１は、Ｈｅｌｌｏ制御モジュール３１６に何も通知しない。この場合、管理データの該当回線の状態は“ＯＦＦ”のままとなり、その回線については従来通りの動作が行われる。
【００８７】
（付記１）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
前記通信ネットワーク内の回線上における障害の発生を検出する検出手段と、
前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する通知手段と
を備えることを特徴とするトンネル障害通知装置。
【００８８】
（付記２）  前記障害が発生した回線の回線情報を格納する格納手段をさらに備え、前記通知手段は、該回線情報が異常を示すとき、該障害の発生を前記隣接ノードに通知することを特徴とする付記１記載のトンネル障害通知装置。
【００８９】
（付記３）  前記格納手段は、前記隣接ノードが回線単位での障害通知機能を具備するか否かを示す管理データをさらに格納し、前記通知手段は、該隣接ノードが該障害通知機能を具備するとき、該障害の発生を回線単位で該隣接ノードに通知し、該隣接ノードが該障害通知機能を具備しないとき、前記複数のトンネルの切断メッセージをトンネル単位で該隣接ノードに通知することを特徴とする付記２記載のトンネル障害通知装置。
【００９０】
（付記４）  前記検出手段は、前記回線上における前記障害の復旧を検出し、前記通知手段は、該障害が復旧した回線を通過する複数のトンネルの復旧メッセージを集約して、該障害の復旧を回線単位で前記隣接ノードに通知することを特徴とする付記１または２記載のトンネル障害通知装置。
【００９１】
（付記５）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する通知手段と
を備えることを特徴とするトンネル障害通知装置。
【００９２】
（付記６）  前記障害が発生した回線の回線情報を格納する格納手段をさらに備え、前記通知手段は、該回線情報が異常を示すとき、該障害の発生を前記第２の隣接ノードに通知することを特徴とする付記５記載のトンネル障害通知装置。
【００９３】
（付記７）  前記格納手段は、前記第２の隣接ノードが回線単位での障害通知機能を具備するか否かを示す管理データをさらに格納し、前記通知手段は、該第２の隣接ノードが該障害通知機能を具備するとき、該障害の発生を回線単位で該第２の隣接ノードに通知し、該第２の隣接ノードが該障害通知機能を具備しないとき、前記複数のトンネルの切断メッセージをトンネル単位で該第２の隣接ノードに通知することを特徴とする付記６記載のトンネル障害通知装置。
【００９４】
（付記８）  前記受信手段は、前記回線上で前記障害が復旧したとき、該障害が復旧した回線を通過する複数のトンネルの復旧メッセージを集約して該障害の復旧を回線単位で通知する復旧通知を、前記第１の隣接ノードから受信し、前記通知手段は、受信した復旧通知に基づいて、該障害の復旧を回線単位で前記第２の隣接ノードに通知することを特徴とする付記５または６記載のトンネル障害通知装置。
【００９５】
（付記９）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うトンネル障害処理装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる制御手段と
を備えることを特徴とするトンネル障害処理装置。
【００９６】
（付記１０）  前記通信ネットワーク内の複数の回線の回線情報を格納する格納手段と、前記障害通知を受信したとき、前記障害が発生した回線の回線情報を正常から異常に変更する回線管理手段とをさらに備え、前記制御手段は、該障害が発生した回線の回線情報が異常に変更されたとき、前記複数のトンネルの切断処理を行うことを特徴とする付記９記載のトンネル障害通知装置。
【００９７】
（付記１１）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うトンネル障害処理装置であって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信する受信手段と、
受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う制御手段と
を備えることを特徴とするトンネル障害処理装置。
【００９８】
（付記１２）  前記通信ネットワーク内の複数の回線の回線情報を格納する格納手段と、前記障害通知を受信したとき、前記障害が発生した回線の回線情報を正常から異常に変更する回線管理手段とをさらに備え、前記制御手段は、該障害が発生した回線の回線情報が異常に変更されたとき、前記現用トンネルから予備トンネルへの切り替え処理を行うことを特徴とする付記１１記載のトンネル障害通知装置。
【００９９】
（付記１３）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知方法であって、
検出手段が、前記通信ネットワーク内の回線上における障害の発生を検出し、
通知手段が、前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する
ことを特徴とするトンネル障害通知方法。
【０１００】
（付記１４）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するトンネル障害通知方法であって、
受信手段が、前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信し、
通知手段が、受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する
ことを特徴とするトンネル障害通知方法。
【０１０１】
（付記１５）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うトンネル障害処理方法であって、
受信手段が、前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
制御手段が、受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる
ことを特徴とするトンネル障害処理方法。
【０１０２】
（付記１６）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うトンネル障害処理方法であって、
受信手段が、前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
制御手段が、受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う
ことを特徴とするトンネル障害処理方法。
【０１０３】
（付記１７）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上における障害の発生を検出し、
前記障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して、該障害の発生を回線単位で隣接ノードに通知する
処理を前記プロセッサに実行させることを特徴とするプログラム。
【０１０４】
（付記１８）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害の発生を通知するプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、第１の隣接ノードから受信し、
受信した障害通知に基づいて、該障害の発生を回線単位で第２の隣接ノードに通知する
処理を前記プロセッサに実行させることを特徴とするプログラム。
【０１０５】
（付記１９）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切断処理を行うプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
受信した障害通知に基づいて、前記複数のトンネルの切断処理を行った後、該障害の復旧を通知する復旧通知を受信するまで該複数のトンネルの再確立を待ち合わせる
処理を前記プロセッサに実行させることを特徴とするプログラム。
【０１０６】
（付記２０）  トンネルを用いてパケットを伝送する通信ネットワークにおいてトンネル障害が発生したとき、トンネルの切り替え処理を行うプロセッサのためのプログラムであって、
前記通信ネットワーク内の回線上で障害が発生したとき、該障害が発生した回線を通過する複数のトンネルの切断メッセージを集約して該障害の発生を回線単位で通知する障害通知を、隣接ノードから受信し、
受信した障害通知に基づいて、前記複数のトンネルに含まれる現用トンネルから迂回経路を経由する予備トンネルへの切り替え処理を行う
処理を前記プロセッサに実行させることを特徴とするプログラム。
【図面の簡単な説明】
【０１０７】
【図１】本発明のトンネル障害通知装置およびトンネル障害処理装置の原理図である。
【図２】本発明の障害通知シーケンスを示す図である。
【図３】ルータのモジュール構成を示す図である。
【図４】ネットワークアドレスを示す図である。
【図５】第１の回線情報を示す図である。
【図６】第２の回線情報を示す図である。
【図７】第３の回線情報を示す図である。
【図８】第４の回線情報を示す図である。
【図９】第１のＨｅｌｌｏメッセージのフォーマットを示す図である。
【図１０】ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトのフォーマットを示す図である。
【図１１】Ｃｏｍｍｏｎ  Ｈｅａｄｅｒのフォーマットを示す図である。
【図１２】第２のＨｅｌｌｏメッセージのフォーマットを示す図である。
【図１３】Ｐａｔｈメッセージの送信を示す図である。
【図１４】ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクトを含むＨｅｌｌｏメッセージの送信を示す図である。
【図１５】障害検出時の処理シーケンスを示す図である。
【図１６】第１のＨｅｌｌｏメッセージ受信時の処理シーケンスを示す図である。
【図１７】トンネルの再確立を抑止する処理シーケンスを示す図である。
【図１８】復旧検出時の処理シーケンスを示す図である。
【図１９】第２のＨｅｌｌｏメッセージ受信時の処理シーケンスを示す図である。
【図２０】２種類のルータからなるネットワーク構成を示す図である。
【図２１】ルータ間の接続方法を示す図である。
【図２２】第１の管理データを示す図である。
【図２３】第２の管理データを示す図である。
【図２４】フラグ分析シーケンスを示す図である。
【図２５】第１のネットワーク構成を示す図である。
【図２６】トンネル構成を示す図である。
【図２７】従来の障害通知シーケンスを示す図である。
【図２８】第２のネットワーク構成を示す図である。
【図２９】従来のＨｅｌｌｏメッセージのシーケンスを示す図である。
【符号の説明】
【０１０８】
１１、１２、１３、１４、４１、４２、４３、４４、４５、４６、４７、４８  ルータ
２１、２２、２３  回線
１０１  検出手段
１０２、１１２  通知手段
１０３、１１３、１２３  格納手段
１１１、１２１  受信手段
１２２  制御手段
１２４  回線管理手段
３０１  経路管理部
３０２  ＲＳＶＰ管理部
３１１  Ｓｅｓｓｉｏｎ制御モジュール
３１２  メッセージ制御モジュール
３１３  ルーティング制御モジュール
３１４  回線管理モジュール
３１５  タイマ制御モジュール
３１６  Ｈｅｌｌｏ制御モジュール
２１０１、２１０２、２１０３  ケーブル
【図１】
2006033124.tif 000003
【図２】
2006033124.tif 000004
【図３】
2006033124.tif 000005
【図５】
2006033124.tif 000006
【図６】
2006033124.tif 000007
【図７】
2006033124.tif 000008
【図８】
2006033124.tif 000009
【図９】
2006033124.tif 000010
【図１０】
2006033124.tif 000011
【図１１】
2006033124.tif 000012
【図１２】
2006033124.tif 000013
【図１５】
2006033124.tif 000014
【図１６】
2006033124.tif 000015
【図１７】
2006033124.tif 000016
【図１８】
2006033124.tif 000017
【図１９】
2006033124.tif 000018
【図２１】
2006033124.tif 000019
【図２２】
2006033124.tif 000020
【図２３】
2006033124.tif 000021
【図２４】
2006033124.tif 000022
【図２６】
2006033124.tif 000023
【図２７】
2006033124.tif 000024
【図２９】
2006033124.tif 000025
【図４】
2006033124.tif 000026
【図１３】
2006033124.tif 000027
【図１４】
2006033124.tif 000028
【図２０】
2006033124.tif 000029
【図２５】
2006033124.tif 000030
【図２８】
2006033124.tif 000031