(57)【要約】  【課題】障害となった区間の異なる経路が迂回経路として選択される可能性をなくし、障害救済処理を安定に行うことを可能にする。  【解決手段】ＭＰＬＳまたはＧＭＰＬＳネットワークのいずれかの経路で障害が発生すると、障害を検出したノードから障害イベント情報であるNotifyメッセージが送信される。障害救済を行うノードは、Notifyメッセージを受信する（Ｓ１）と、この受信をトリガとして保護時間の計時を開始する（Ｓ２）。この保護時間の間にＯＳＰＦのＬＳＡが収集される。保護時間が完了すると、障害救済を行うノードは、NotifyメッセージとＯＳＰＦのＬＳＡに基づいて迂回経路計算を実行し（Ｓ３）、レストレーションによる障害救済を行う（Ｓ４）。  【選択図】図３
2005333383.tif 000002
【特許請求の範囲】
【請求項１】
ＭＰＬＳまたはＧＭＰＬＳネットワークにおいて発生した障害に対して迂回経路計算を行って新たにＬＳＰを設定するための障害救済処理方法において、
障害救済を行うノードは、障害箇所の切り分けが行われて障害発生を示す障害イベント通知を受信した後、ＬＳＰが用いるリンク以外のリンクについての状態情報通知が行われる時間以上の所定の保護時間をおき、前記障害イベント通知および保護時間中に受信された状態情報通知に基づいて迂回経路計算を行うことを特徴とする障害救済処理方法。
【請求項２】
前記保護時間は、ネットワークの規模に応じて設定可能であることを特徴とする請求項１に記載の障害救済処理化方法。
【請求項３】
ＭＰＬＳネットワークにおいて発生した障害に対して、コンピュータに迂回経路計算を行わせて新たにＬＳＰを設定し、障害救済を行わせるプログラムにおいて、
障害箇所の切り分けが行われて障害発生を示す障害イベント通知を受信する手順と、ＬＳＰが用いるリンク以外のリンクについての状態情報通知が行われる時間以上の所定の保護時間をおく手順と、前記障害イベント通知および保護時間中に受信された状態情報通知に基づいて迂回経路計算を行う手順を含むことを特徴とするプログラム。
【請求項４】
前記保護時間は、ネットワークの規模に応じて設定可能であることを特徴とする請求項３に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、障害救済処理方法およびプログラムに関し、特に、ＭＰＬＳ(Multi Protocol Label Switching)またはＧＭＰＬＳ(Generalized MPLS)ネットワークにおけるＬＳＰ(Label Switched Path)の高信頼な障害復旧方法であるレストレーションおいて障害救済処理を安定に行うことができる障害救済処理方法およびプログラムに関する。
【背景技術】
【０００２】
従来、ネットワークの障害復旧方式として、プロテクション方式とレストレーション方式が知られている。プロテクション方式は、現用経路に対して予備経路を予め用意しておき、現用経路に障害が発生した時に予備経路にパスを設定するものである。この方式では、事前に迂回経路としての予備経路が予め用意されており、現用経路の障害発生時に新たに障害のない経路を再計算して設定する必要がないので、高速な障害復旧が可能であり、高速化が要求されるネットワームに対する障害復旧方式として適している。
【０００３】
一方、レストレーション方式は、現用経路の障害発生時に新たに障害のない経路を再計算して迂回経路として設定するものであり、この方式では、プロテクション方式に比べて高速化の点では劣るが、予め予備経路を用意しておく必要がなく、リンクの帯域を有効に利用することができるので、高速化を余り問題にしないネットワークに対する障害復旧方式として適している。
【０００４】
下記非特許文献１には、ＧＭＰＬＳネットワーク内において障害が発生した際、現用経路（LSP）の発ノード（Initiatorノード）に対してその障害イベントに関する情報を通知し、障害救済を促すことが記載されている。この通知にはＲＳＶＰ(Resource reSerVation Protocol)のNotifyメッセージが使用され、これにより障害区間のノードから障害救済を行う発ノードに対して直接、障害イベントが通知される。これは、従来のＭＰＬＳ技術に対する拡張機能である。
【０００５】
下記特許文献１には、従来のＭＰＬＳ技術における障害通知に関するメカニズムの不十分さを補うため、障害通知に係わるラベル処理に工夫を施し、各中継ノードでのＦＥＣまたはＬＳＰ−ＩＤでの検索を省略可能とすることにより高速化を図る技術が記載されている。
【特許文献１】特開２００３−６０６８０号公報
【非特許文献１】Internet Engineering Task Force(IETF),RFC 3473
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献１と非特許文献１の技術は、何れも障害救済を行うノードに対して効率的に障害の発生を伝達するものの、該ノードに通知するのは当該ＬＳＰが用いるリンクに係わる障害情報のみである。
【０００７】
ＷＤＭ(Wavelength Division Multiplexing)ネットワークのように、１つの伝送路、例えば１つのファイバに複数のリンクが収容される構成を想定した場合、ＬＳＰが用いるリンクに障害が発生すると、多くの障害では当該ＬＳＰが用いるリンク以外のリンクも同時に障害になるケースが多いと考えられるが、上記特許文献１および非特許文献１の技術におけるNotifyメッセージでは、障害救済を行うノードに、他のＬＳＰが用いるリンクに係わる障害や未使用のリンクに係わる障害は通知されない。
【０００８】
復旧前のオリジナルのＬＳＰが最小コスト計算により構築された経路であれば、同じ伝送路に収容される障害となった異なるリンクが最小コスト計算により検索され、迂回経路候補として選択される可能性が高い。このように、障害救済を行うノードがレストレーションのための経路を（再）計算する上で、十分なトポロジ状態の同期が行われないままレストレーション処理が行わる結果、ＬＳＰの障害救済に失敗してしまう危険性がある。
【０００９】
本発明の目的は、障害となった区間の異なるリンクが迂回経路候補として選択される可能性をなくし、障害救済処理を安定に行うことができる障害救済処理方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明は、ＭＰＬＳまたはＧＭＰＬＳネットワークにおいて発生した障害に対して迂回経路計算を行って新たにＬＳＰを設定するための障害救済処理方法において、障害救済を行うノードは、障害箇所の切り分けが行われて障害発生を示す障害イベント通知を受信した後、ＬＳＰが用いるリンク以外のリンクについての状態情報通知が行われる時間以上の所定の保護時間をおき、前記障害イベント通知および保護時間中に受信された状態情報通知に基づいて迂回経路計算を行う点に特徴がある。
【００１１】
また、本発明は、ＭＰＬＳネットワークにおいて発生した障害に対して、コンピュータに迂回経路計算を行わせて新たにＬＳＰを設定し、障害救済を行わせるプログラムにおいて、障害箇所の切り分けが行われて障害発生を示す障害イベント通知を受信する手順と、ＬＳＰが用いるリンク以外のリンクについての状態情報通知が行われる時間以上の所定の保護時間をおく手順と、前記障害イベント通知および保護時間中に受信された状態情報通知に基づいて迂回経路計算を行う手順を含む点に特徴がある。
【００１２】
ここで、ＬＳＰが用いるリンク以外のリンクについての状態情報通知が受信されてから迂回経路計算が行われることを保証するための保護時間は、ネットワークの規模に応じて設定可能にすることができる。
【発明の効果】
【００１３】
本発明によれば、障害救済を行うノードは、障害発生を示す障害イベント通知の他にＬＳＰが用いるリンク以外のリンクについての状態情報通知を受信してから、それらに基づいて迂回経路計算を行うので、いわゆるダイナミックレストレーション方式で障害救済処理を行う場合の救済確率を高めることができる。
【００１４】
また、保護時間をネットワークの規模に応じて設定可能にしておくことにより、どのような規模のネットワークにも適用でき、また、ネットワークの規模が変わってもそれに対処できる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の実施の形態を図面を参照して詳細に説明する。図１は、本発明が適用されるネットワークの一例を示す構成図である。このネットワークは、ノードＡ〜Ｆ間を光ファイバなどで接続することにより構成され、ノードＡ−Ｂ間、Ａ−Ｃ間、Ｃ−Ｅ間、Ｄ−Ｆ間、Ｅ−Ｆ間には、それぞれ１つのリンク１−１、１−２、１−５、１−６、１−７が存在し、ノードＡ−Ｄ間には２つのリンク１−３、１−４が存在する。ここでは、ノードＡを発ノード（Inisiator）とし、ノードＦを着ノード（Terminator）とし、ノードＡ−中間ノード（Transit）Ｂ−中間ノード（Transit）Ｄ−ノードＦの経路に現用経路（LSP）が設定されているものとする。
【００１６】
ここで、中間ノードＢと中間ノードＤ間のリンク１−３で障害が発生し、同時にリンク１−４でも障害が発生したとすると、障害区間のノード（本例の場合は中間ノードＢ）は、障害区間切り分け作業（Fault localization）を行った後、障害救済を行うノード（本例の場合は発ノードＡ）に対してＲＳＶＰのNotifyメッセージにより障害イベントの通知を行う。
【００１７】
この通知では、ＬＳＰが使用しているリンク１−３のみに関する情報が伝達され、同一区間（ノードＢ−Ｄ間）の未使用のリンク１−４が同時に障害になっていることの通知は行われない。したがって、発ノードＡがNotifyメッセージを受けて、ダイナミックレストレーション処理のための迂回経路の計算を直ちに行うと、正しい迂回経路（本例の場合、ノードＡ−中間ノード（Transit）Ｃ−中間ノード（Transit）Ｅ−ノードＦの経路）へのレストレーションが行われない可能性が高い。
【００１８】
すなわち、ノードＡ−中間ノード（Transit）Ｂ−（リンク１−３）−中間ノード（Transit）Ｄ−ノードＦの経路が最小コスト計算により構築されたＬＳＰであるとすると、ノードＡ−中間ノード（Transit）Ｂ−（リンク１−４）−中間ノード（Transit）Ｄ−ノードＦの経路が最小コスト再計算により検索され、迂回経路候補として選択される可能性が高い。特にネットワークの規模が大きい場合にこの可能性が高い。
【００１９】
未使用のリンク１−４の障害に関する情報は、ＯＳＰＦ(Open shortest path first)のＬＳＡ(Link state advertisement)により、各ノードをホップしてネットワーク全体に広告される。これにより、ネットワーク全体のリンクステートデータベースの同期が可能となるが、この同期には広告時間が必要である。この広告時間は、ネットワークの規模やリンクの数に依存する。さらに、障害区間のノードＢから発ノードＡに対して直接通知が可能なNotifyメッセージと比較して、ホップ・バイ・ホップ(hop by hop)で通知されるＯＳＰＦメッセージは、それが障害救済を行うノードＡに伝達されるまでの伝達時間が長いことが想定される。
【００２０】
図２は、ネットワークのノード数(Node count)とＬＳＡの広告時間(Averaged flooding time)の関係の一例を示す図である。同図に示されるように、ＬＳＡの広告時間は、ネットワークのノード数によって大きく変化する。この例では、ＬＳＡの広告に必要な時間は、例えばノードの数が３個のネットワークでは200msec程度であるが、ノードの数が６個のネットワークになると600msec程度となる。
【００２１】
本発明では、この例で示されるように、ネットワークによってＬＳＡの広告時間が変化する点を考慮し、障害救済を行うノードＡに、ＬＳＡの広告が完了するまで迂回路計算を行うことなく待機する保護時間を導入する。障害救済を行うノードＡは、保護時間内にＬＳＡを受信してＬＳＰが用いるリンク以外のリンクについての状態情報を取得することができる。
【００２２】
保護時間の計時は、Notifyメッセージによる障害イベント通知をトリガとして開始させればよく、その期間は、例えば図２に示される特性を考慮して、ＬＳＰが用いるリンク以外のリンクについての状態情報が、障害救済を行うノードＡにより取得されるのに十分な時間とすればよい。
【００２３】
この保護時間の適用により、障害救済を行うノードＡは、障害が発生したＬＳＰが用いるリンク１−３の状態をNotifyメッセージにより収集するのみでなく、同時に障害となる可能性のあるリンク１−４の状態をＯＳＰＦのＬＳＡにより収集することができるようになり、結果として適切なリンクステートデータベース同期が行われ、正しく迂回経路計算を実施できるようになる。
【００２４】
図３は、障害救済を行うノードにおける障害救済処理を示すフローチャートである。ネットワークのいずれかの経路で障害が発生すると、障害を検出したノードは、障害区間切り分け作業を行った後、障害イベント情報であるNotifyメッセージを障害救済を行うノードに送信する。
【００２５】
障害救済を行うノードは、このNotifyメッセージを受信する（Ｓ１）と、この受信をトリガとして保護時間の計時を開始する（Ｓ２）。保護時間は、図１の例の場合、ネットワークのノード数が６（ノードＡ〜Ｆ）であるので、図２の例に従えば600msecに設定すれば十分である。
【００２６】
保護時間の間に、障害救済を行うノードによりＯＳＰＦのＬＳＡが収集される。保護時間が完了すると、障害救済を行うノードは、NotifyメッセージとＯＳＰＦのＬＳＡに基づいて迂回経路計算を実行する（Ｓ３）。この迂回経路計算は、例えばＧＭＰＬＳネットワークの場合、リンク属性などの制約を考慮した最小コスト計算（ＣＳＰＦ：Constraint-base shortest path first）である。迂回経路計算が実行される時点では、既にNotifyメッセージの他にＯＳＰＦのＬＳＡが収集されており、障害救済を行うノードは、これらに基づいて迂回経路計算を実行するので、レストレーション時に正しい迂回経路が検索されない確率を極めて低く抑えることが可能になる。最後に、障害救済を行うノードは、迂回経路計算の結果に従って障害救済処理を実行する（Ｓ４）。
【００２７】
本発明は、障害救済を行うノードにコンピュータを搭載し、このコンピュータに上述の障害救済処理の手順を実行させるプログラムとしても実施できる。このようなプログラムをＣＤ−ＲＯＭなどの記憶媒体に記憶させておき、これを読み出してインストールすれば本発明に従うノードを構成できる。
【００２８】
以上、実施形態について説明したが、本発明は、上記実施形態に限られず、種々に変形できる。例えば、保護時間をネットワークの規模に応じて設定可能にすることができ、それにより本発明はどのような規模のネットワークにも適用でき、また、ネットワークの規模が変わってもそれに対処できる。また、上記実施形態では、ネットーワークの規模を示すものとして、ネットワークのノードの数を用いたが、ＯＳＰＦのＬＳＡの広告が行われる場合の最大ホップ数を用いることもでき、その他にノード間距離、制御ネットワークの帯域、遅延、リンク数などを用いることもできる。
【図面の簡単な説明】
【００２９】
【図１】本発明が適用されるネットワークの一例を示す構成図である。
【図２】ネットワークのノードの数とＬＳＡの広告時間の関係の一例を示す説明図である。
【図３】障害救済を行うノードにおける障害救済処理を示すフローチャートである。
【符号の説明】
【００３０】
１−１〜１−７・・・リンク、Ａ〜Ｆ・・・ノード
【図１】
2005333383.tif 000003
【図２】
2005333383.tif 000004
【図３】
2005333383.tif 000005