JP4255080B2 - 網障害復旧管理方法及び網障害復旧管理装置 - Google Patents

Description

本発明は、複数カスタマ収容網障害復旧管理方法及び複数カスタマ収容網障害復旧管理装置に関する。特に、拠点間にパスを設定し、複数のカスタマを同一の網に収容する場合において、リソースの割り当てポリシーに応じて、各カスタマに現用及び予備パスを設定する複数カスタマ収容網障害復旧管理方法及び複数カスタマ収容網障害復旧管理装置に関する。

従来の複数のカスタマを収容する網（通信ネットワーク）の例としては、網内にＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）のＬＳＰ（Ｌａｂｅｌ Ｓｗｉｔｃｈｅｄ Ｐａｔｈ）を設定して、複数のカスタマを収容するＬ３ＶＰＮ（Ｌａｙｅｒ３ Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）やＬ２ＶＰＮ（Ｌａｙｅｒ２ Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）がある。また、カスタマ装置間に波長パスやＴＤＭ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ：時分割多重）パスを設定して、複数のカスタマを収容する例として、Ｌ１ＶＰＮ（Ｌａｙｅｒ１ Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）がある。

なお、「カスタマ」とは、ある共通のポリシーによって運用されるネットワークに対する管理者を意味するものとする。また、カスタマと、カスタマに通信路を提供するプロバイダの管理者が、通常のように異なる場合もあれば、同じである場合もありうる。以後の説明では、網内で１つのＶｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ（以後、ＶＰＮと記述）を１人のカスタマが管理しているという前提で説明を行う。

従来の網管理技術として、リンクごとに識別子を追加するものがある（非特許文献１）。この技術の提供する識別子を利用すれば、各リンクをどのカスタマが利用可能か、また、現用か予備用か、などを示すことができる。

また、従来の網管理技術として、１つの障害に対して、複数のリンク故障が発生する可能性を考慮して、リンクに対して、どの障害に対して故障しうるかを示す識別子を追加するものがある（非特許文献２）。この技術を用いれば、どのような単一障害に対しても、同時に故障することがない複数の現用パスについては、予備パスのリソースを共有するように考慮して、経路計算とパス設定を行うことができる。

特許文献１は、カスタマに着目し、ネットワークトポロジやネットワークリソース状況を考慮した上で、カスタマに対して提案を行うことにより、ネットワークリソースの有効活用とカスタマへの差異化サービスを提供する技術について述べている。
特開２００４−２６０５６７号公報（段落００１５〜００１７、図２） 「Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ（ＴＥ） Ｅｘｔｅｎｓｉｏｎｓ ｔｏ ＯＳＰＦ Ｖｅｒｓｉｏｎ２」、ＩＥＴＦ，［ｏｎｌｉｎｅ］，２００３年９月掲載，［２００４年７月検索］，インターネット<http://www.ietf.org/rfc/rfc3630.txt> 「Ｒｏｕｔｉｎｇ Ｅｘｔｅｎｓｉｏｎｓｉｎ Ｓｕｐｐｏｒｔ ｏｆ Ｇｅｎｅｒａｌｉｚｅｄ Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ」，ＩＥＴＦ，［ｏｎｌｉｎｅ］，２００３年１０月掲載，［２００４年７月検索］，インターネット<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-09.txt>

しかしながら、従来の技術では、複数のカスタマが存在する場合に、障害復旧時にどのように振舞うかまでは充分に規定できない。具体的には、異なるカスタマの予備パスが、リソースを共有可能とするか否かを規定することができないので、異なるカスタマと予備パスのリソースを共有する場合には、単一障害には対応可能であるが、複数障害が起き、別のカスタマの予備パスが先に設定されてしまうと、リソースが不足して予備パスが使えなくなってしまう問題が起きる。

それに対して、異なるカスタマと予備パスのリソースを共有しない場合には、複数の障害が起きた場合でも、他のカスタマの予備パスが先に設定されてしまうことで、予備パスが使えなくなってしまうことはなく、予備パスが必ず確保できるが、必要になるリソースは多くなる。障害復旧時にリソースをどのように使わねばならないかは、カスタマの事情により決まるものであり、一律に対応を決定したのでは充分な対応ではない。

そこで、本発明は、このカスタマの要求にきめ細かく対応して、障害時のリソース割り当てを行えるようにすることを課題とする。

前記の課題を解決するために、本発明（請求項１）では、複数のカスタマを同一の網に収容する複数カスタマ収容網において、網障害復旧管理装置が、各リンクのリソースをどのカスタマに割り当てるかを設定する機能と前記リンクを現用パス又は予備パスに割り当てるかを設定する機能を有するリソース割り当て手段と、カスタマごとのリソースの割り当てポリシーを設定するポリシー設定手段と、各カスタマが利用可能なリソースを利用して現用パスの経路計算を行う現用パス経路計算手段と、各カスタマが利用可能なリソースを利用して予備パスの経路計算を行う予備パス経路計算手段と、前記現用パス経路計算手段又は前記予備パス経路計算手段によって計算されたパスの設定を行うパス設定手段と、網障害発生時にパスの切り替えを行うパス切り替え手段とを備え、前記リソース割り当て手段が、リソースを特定のカスタマ又は共有のリソースに割り当てた後に、前記リソースをそれぞれ現用パス又は予備パスに割り当て、前記ポリシー設定手段が、カスタマごとのリソースの割り当てポリシーを設定し、前記現用パス経路計算手段が、現用パスを計算し、前記予備パス経路計算手段が、予備パスを計算し、前記パス設定手段が、前記現用パス及び前記予備パスを網に設定し、前記現用パスの網障害発生時には、前記パス切り替え手段が、予め設定されている前記予備パスにパスの切り替えを行う。

この構成によれば、カスタマの要求にきめ細かく対応するリソース管理と網障害復旧とが可能になる。

また、本発明（請求項２）では、前記リソース割り当て手段が、リンクのリソースを、１つ以上の特定のカスタマ又は任意のカスタマに割り当て、どのカスタマが利用可能であるのかを前記リンクのリソースごとにデータベースに記述して、管理する。

これによれば、リンクのリソースごとの管理が可能になる。

本発明（請求項３）では、前記リソース割り当て手段が、リンクのリソースを、現用パス用又は予備パス用に割り当て、現用パス用と予備パス用のどちらが利用可能であるのかを前記リンクのリソースごとにデータベースに記述して、管理する。

これによれば、更に別の観点からリンクのリソースごとの管理が可能になる。

更に、本発明（請求項４）では、前記リソース割り当て手段が、リンクのリソースを、１つ以上の特定のカスタマ、任意のカスタマ又は予備パス用に割り当て、どのカスタマがどのリンクのリソースを利用可能であるのかを前記リンクのリソースごとにデータベースに記述して、管理する。

これによれば、更にきめ細かくリンクのリソースごとに管理することができる。

また、本発明（請求項５）では、前記ポリシー設定手段が、現用パス及び予備パスが使用するリソース指定において、特定のカスタマが利用可能と指定されたリソース又は任意のカスタマが利用可能なリソースの何れか１つ又は両方を利用可能であることをデータベースに記述し、前記データベースの内容に基づいてカスタマごとにリソースの割り当てポリシーを設定する。

この構成によれば、カスタマごとにリソースの割り当てポリシーを設定できる。

本発明（請求項６）では、前記ポリシー設定手段が、カスタマが他のカスタマとリソースの共有を許すか許さないかをデータベースに記述し、前記カスタマごとにリソースの割り当てポリシーを設定する。

この構成によれば、更に細かくカスタマごとにリソースの割り当てポリシーを設定できる。

本発明（請求項７）では、前記ポリシー設定手段が、特定のカスタマが利用可能と指定されたリソース及び任意のカスタマが利用可能と指定されたリソースから何れか１つ以上のリソースが現用パス用に利用可能であることと、特定のカスタマが利用可能と指定されたリソース、任意のカスタマが利用可能と指定されたリソース及び予備パス用に利用可能とされたリソースから何れか１つ以上のリソースが予備パス用に利用可能であることをデータベースに記述し、前記データベースの内容に基づいてカスタマごとにリソースの割り当てポリシーを設定する。

この構成によれば、カスタマごとにリソースの割り当てポリシーを設定できる。

本発明によれば、複数カスタマ収容網において、通常運用時にカスタマの要求に基づいた効率的なリソース管理ができるだけでなく、網障害復旧時にもカスタマの要求に基づいてリソースの割り当てに関するポリシーに従って復旧することが可能になる。

本発明の一実施形態について図面を参照して詳細に説明する。
図１は、本実施形態が前提とするネットワーク構成を示している。図１の（ａ）は、本実施形態において前提とするネットワークの最も基本的な形態の例を示す図であり、ノードとリンクのみからなる。ノードｎ１からノードｎ６までは、スイッチング機能を有し、かつ、ノード間にパスを設定する機能をもつものである。例えば、ＭＰＬＳのＬＳＲ（Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ Ｒｏｕｔｅｒ）、波長クロスコネクトなどが相当する。リンクは、ノード間を接続し、情報を転送する媒体である。例えば、光ファイバなどが相当する。パスは、波長パスのように、離散的な帯域をもつ場合もあれば、ＭＰＬＳのＬＳＰのように、連続的な帯域をもつ場合もある。

図１の（ｂ）は、本実施形態において前提とするネットワークの基本的な形態の例を補足説明する図である。図１（ｂ）も図１（ａ）のノードｎ１からノードｎ６までの６つのノードからなる構成例であるが、図１の（ｂ）ではリンクの方向性を区別し、加えて、現在の時点で運用に用いられている現用パスのために用意されたリンクと、予備用として準備される予備パスのために準備されたリンクを示している。リンクｌ１からリンクｌ１６までの１６本のリンクは、それぞれ向きを持っているが、そのうちノードｎ１とノードｎ３を結ぶ破線で示したリンクｌ５とリンクｌ６は予備パス用のリンクを示している。同じノードｎ１とノードｎ３を結ぶ実線で示したリンクｌ３とリンクｌ４は、同じ区間を結ぶ現用パス用のリンクである。なお、ここで説明に用いたｎ１からｎ６までの符号は、これらのノードのノードＩＤを表すものである。

なお、以下の説明では、１つのパスに対して、１つのカスタマが利用することを前提として説明するが（１本のパスが１つのカスタマのトラヒックのみを転送するが）、そうでなくてもかまわない。すなわち、１つのパスを複数のカスタマが利用してもかまわない。

［網障害復旧管理装置の構成］
図２は、本実施形態における網障害復旧管理装置1の構成例を示す図である。本実施形態においては、リンクのリソース（資源）を２つの観点で割り当て管理を行っている。まず、第１の観点は、カスタマごとのリソース管理である。リソースを特定の１人以上のカスタマもしくは任意のカスタマに割り当てる。第２の観点は、リンクのリソースが現用パス用であるか、予備パス用であるかという観点である。この２つの観点を組み合わせて、リンクのリソースごとにどのカスタマがどのように使えるリソースであるかを管理する。さらに、予備パス用のリソースについては、他のカスタマと共有を許すか許さないかを管理する。なお、網障害復旧管理装置１は、ノード中に実装されている場合もあれば、ノードとは別の装置に実装されている場合もある。

本実施形態における網障害復旧管理装置1は、６つの管理手段と４つのデータベースからなっている。管理手段には、リソース割り当て手段１１、ポリシー設定手段１２、現用パス経路計算手段１３、予備パス経路計算手段１４、パス設定手段１５及びパス切り替え手段１６があり、データベースには、ポリシーデータベース（以後、ポリシーＤＢと記述）２１、パスデータベース（以後、パスＤＢと記述）２２、リンクリソースデータベース（以後、リンクリソースＤＢと記述）２３及び予備リソースデータベース（以後、予備リソースＤＢと記述）２４がある。

［網障害復旧管理装置のデータベース］
ポリシーＤＢ２１は、ポリシー設定手段１２により設定されたカスタマごとのパス設定のためのリソースの割り当てポリシーを格納しているデータベースである。ポリシーＤＢ２１は、ＶＰＮＩＤ、現用パスリソースポリシー、予備パスリソースポリシー及びリソース共有ポリシーの各項目を含む。

ＶＰＮＩＤは、カスタマを一意に識別する情報である。現用パスリソースポリシーは、現用パスに対して割り当てることができるリソースの範囲をＶＰＮＩＤと任意の組み合わせを用いて指定し、予備パスリソースポリシーは、予備パスに割り当てることができるリソースの範囲を指定する。そして、リソース共有ポリシーは、他のカスタマが使うＶＰＮリソースを共有できるか否かを可と不可で指定する。ポリシーＤＢ２１の内容例を表１に示す。

この表1の例は、図１（ｂ）の例に対応している。また、後記する他のデータベースの内容例とも対応している。

パスＤＢ２２は、パス設定手段１５により設定されたパスの情報を格納している。パスＤＢ２２は、パスＩＤ、ＶＰＮＩＤ、帯域、経路リンクリスト、現用・予備フラグ及び対応パスＩＤの項目を含む。

パスＩＤは、パスを一意に識別する情報である。ＶＰＮＩＤとは、前記のＶＰＮＩＤと同じものである。帯域は、パスが使用する帯域（リソース）を示す。経路リンクリストは、パスの経路を、経由するリンクのリストで表している。図１（ｂ）の例で、ノード１−ノード３間のリンクＩＤをｌ３、ノード３−ノード４間のリンクＩＤをｌ９、ノード４−ノード２間のリンクＩＤをｌ８とし、ノード１からノード２にパスが張られ、その経路がノード１−ノード３−ノード４−ノード２である場合、経路リンクリストは、<ｌ８，ｌ９，ｌ３>となる。

現用・予備フラグは、そのリンクが属しているパスが現用パスか予備パスかを示すものである。対応パスＩＤは、現用パスと現用パスの障害時に用いる予備パスの対応関係を示す情報を持つ項目である。この項目には、現用パスである場合は対応する予備パスのパスＩＤを、予備パスである場合は対応する現用パスのパスＩＤを格納する。パスＤＢ２２の内容例を表２に示す。

表２に含まれている経路リンクリストの例は、リンクリソースＤＢ２３の内容例に含まれているリンクＩＤと対応している。

図３は、表２の内容を示す図であり、例えば、表２におけるＶＰＮ１の現用パスＶＰＮ１ａは、ノードｎ２からノードｎ４に至るリンクｌ７（図1（ｂ）も適宜参照）で表されているのに対して、障害時に復旧用として対応する予備パスＶＰＮ1ｂは、ノードｎ２からノードｎ１、ノードｎ３を経て、ノードｎ４に至る破線で示されたパスである。この経路では、リンクｌ２，ｌ５，ｌ９を経由している。図３には、表２のＶＰＮ２及びＶＰＮ３についても、ＶＰＮ１と同様に現用パスと予備パスが記載されており、ＶＰＮ２の現用パスＶＰＮ２ａと予備パスＶＰＮ２ｂとが対応し、同様にＶＰＮ３の現用パスＶＰＮ３ａと予備パスＶＰＮ３ｂとが対応する。

リンクリソースＤＢ２３は、各カスタマに割り当てられたリソースの残余リソースを格納する。図２に示すように、リンクリソースＤＢ２３には、リンクＩＤ、Ａ端ノードＩＤ、Ｚ端ノードＩＤ、Ａ端ＩＦ（Ｉｎｔｅｒｆａｃｅ）ＩＤ、Ｚ端ＩＦＩＤ、ＳＲＬＧ（Ｓｈａｒｅｄ Ｒｉｓｋ Ｌｉｎｋ Ｇｒｏｕｐ）ＩＤ、割り当てリソース、残余リソース、ＶＰＮＩＤ及び現用・予備用フラグの項目を含む。

リンクＩＤは、リンクを一意に識別する情報である。そして、Ａ端ノードＩＤは、リンクの上流側のノードのノードＩＤであり、Ｚ端ノードＩＤとは、当該リンクの下流側のノードのノードＩＤである。

ＩＦＩＤは、当該ノードでリンク（リンクへのインタフェース）を一意に識別する情報である。Ａ端ＩＦＩＤとは、Ａ端ノードにおける当該リンクのＩＦＩＤであり、Ｚ端ＩＦＩＤとは、Ｚ端ノードにおける当該リンクのＩＦＩＤである。
ＳＲＬＧＩＤとは、単一障害に対して複数のリンクが障害するケースを想定し（例えば、複数のリンクが同一の管路に収容されており、管路に障害が起きる場合）、単一障害に対して同時に障害が発生しうるリンクのグループを示す情報である。この値が同じ複数のリンクは、単一障害に対して同時に障害が発生しうる。

ＶＰＮＩＤは、前記のＶＰＮＩＤと同一の項目である。本実施形態においては、当該リンクが任意のカスタマに割り当てられる場合もあれば、１つ以上のカスタマに割り当てられる場合もあり、「任意」及び「ＶＰＮＩＤの１つ以上のリスト」の何れか一方が設定される。

割り当てリソースは、当該リンクにどれだけのリソース、すなわち、帯域が割り当てられているかを示す項目である。そして、残余リソースは、その割り当てられたリソースから、現用パスで使っているリソースと予備パス用に予約されたリソースを減算した残りのリソースを示す項目である。なお、予備パス用に予約されたリソースは、リソースの共有効果により最低限必要な帯域だけを減算の対象とする。例えば、消費する帯域が１の予備パスが３本あったとしても、帯域を３必要とするわけではなく、３本の予備パスは帯域を共有して、全体で１の帯域で足りる。

現用・予備フラグは、該当リソースが、現用パス、予備パス又は両者の何れで利用可能かを示すものであり、「現用」、「予備」又は「両者」の何れか１つが設定される。表３にリンクリソースＤＢ２３の内容例を示す。

表３の例は、図１（ｂ）１６本のリンクを含む例であり、このうち、ノードｎ１とノードｎ３の間のリンクには、現用パスのためのリンクｌ３，ｌ４及び予備パスのためのリンクｌ５，ｌ６を含んでいる。

前記の構成では、図１（ｂ）及び表３に示したように、同一装置かつ同一ＩＦ間においても、形成されるリンクは１つとは限らない。同一装置かつ同一ＩＦ間で、「現用」、「予備」及び「両者」の割り当てに別々にリソースを割り当てる場合には、複数のリンクが形成され、それらは異なるリンクＩＤを持つ。ただし、同一装置同一ＩＦ間には、単一のリンクＩＤを振って、１つのリンクを形成し、１つのリンクの中で、更に、ＶＰＮＩＤごと、予備・現用及び両者ごとに、リソースを割り当てる構成でもかまわない。

予備リソースＤＢ２４は、予備パス用に割り当てられたリソースの情報の詳細を格納する。図２に示すように、予備リソースＤＢ２４は、リンクＩＤと共通リソースの項目群及び個別ＶＰＮリソースの項目群を含んでいる。共通リソースの項目群の中には、予約リソース及び、ＳＲＬＧＩＤリソースに関する項目があり、このＳＲＬＧＩＤリソースに関する項目は、さらにＳＲＬＧＩＤとＳＲＬＧ予約リソースの２つの項目を含んでいる。個別ＶＰＮリソースの項目群の中には、共通リソースの項目群の項目に加えて、ＶＰＮＩＤの項目を含む。すなわち、ＶＰＮＩＤ、予約リソース及びＳＲＬＧＩＤリソースに関する項目があり、このＳＲＬＧＩＤリソースに関する項目は、さらにＳＲＬＧＩＤとＳＲＬＧ予約リソースの２つの項目を含んでいる。

リンクＩＤは、リンクを一意に識別する情報である。共通リソースは、他のカスタマとリソースを共有してもかまわないカスタマの予備パスが消費しているリソースを指す。そして、共通リソースに関する項目群は、このようにリソースを共用した予備パスについての情報を格納する。共通リソースの予約リソースは、予備パス間のリソース共有効果も含め、予備パスに対して予約されたリソースを示す項目である。

共通リソースのＳＲＬＧＩＤリソースは、現用パスに対して割り振られたＳＲＬＧＩＤごとに、予備パスに対して予約が必要なリソースを示す項目である。ここで、共通リソースのＳＲＬＧＩＤリソースのＳＲＬＧＩＤとは、現用パスのＳＲＬＧのＩＤを示している。

共通リソースのＳＲＬＧＩＤリソースのＳＲＬＧ予約リソースは、現用パスのＳＲＬＧに対して、予備パスに予約が必要なリソースを示す項目である。

予備リソースＤＢ２４及び予備パス経路計算手段１４が、現用パスのＳＲＬＧＩＤに対応して、リソースを管理しなければならないのには理由がある。同時に複数の障害が起きるリスクに対応しなければならないからである。だから、対応する現用パスと予備パスは、ＳＲＬＧＩＤが同じグループに入ってはいけない。また、ＳＲＬＧＩＤが同じグループに入っている複数の現用パスに障害が同時に発生しうる。この場合、予備パスのリソースとして必要になるのは、ＳＲＬＧＩＤが同じグループに入っている複数の現用パスの帯域の合計値となる。このようなことから、現用パスのＳＲＬＧＩＤに対応して、予備リソースを管理しなければならない。

個別ＶＰＮリソースは、共通リソースの場合と異なり、他のカスタマとリソース共有ができないカスタマに対して割り当てられる予備パスに対して予約されたリソースである。個別ＶＰＮリソースの場合にも、同一カスタマの予備パス間のリソース共有効果はあるが、複数のカスタマにわたる共有効果は想定されていない。

個別ＶＰＮリソースのＳＲＬＧＩＤリソースは、現用パスのＳＲＬＧＩＤごとに、予備パスに対して予約が必要なリソースを示す項目群であり、共通リソースのＳＲＬＧＩＤリソースのＳＲＬＧＩＤは、現用パスのＳＲＬＧＩＤを示し、共通リソースのＳＲＬＧＩＤリソースのＳＲＬＧ予約リソースは、現用パスのＳＲＬＧＩＤに対して、予備パスに予約が必要なリソースを示す。

表４のｌ９のリンクの例でもわかるように、１つのリンクに対してＳＲＬＧＩＤリソースのエントリは必ずしも１つとは限らず、複数のエントリを持つ場合もある。また、リンク全体で予備パス用に予約しておくリソースは、共通リソースの予約リソースと、個別ＶＰＮリソースのそれぞれのＶＰＮの予約リソースの合計となる。これは、予備パス用に用いるリソースにおいて、共通リソースで予約するリソースと個別のカスタマが予約するリソースは、共用できないことを意味している。

［障害復旧のための手段］
本実施形態における障害復旧のための手段は、前記した４種類のデータベースを参照することを通して、障害復旧のための処理を行う。リソース割り当て手段１１は、リンクリソースＤＢ２３の各項目の値を設定する。ポリシー設定手段１２は、ポリシーＤＢ２１の各値を設定する。現用パス経路計算手段１３は、リンクリソースＤＢ２３を参照して、現用パスの経路を計算し、結果をパスＤＢ２２に格納する。予備パス経路計算手段１４は、リンクリソースＤＢ２３及び予備リソースＤＢ２４を参照して、予備パスの経路を計算し、結果をパスＤＢ２２に格納する。パス設定手段１５は、パスＤＢ２２から必要な情報を取り出して、パスの設定を行う。パス切り替え手段１６は、障害が発生した場合、障害が発生した現用パスに対してあらかじめ計算されていた予備パスの経路をパスＤＢ２２から取り出し、これに沿うようにパスを設定し、切り替える。それぞれの手段の動きについては、後記する処理の具体例を通して説明する。

［網障害復旧管理装置の動作］
網障害復旧管理装置１の動作を復旧のための各手段の動作の説明を通して説明する。まず、現用パス経路計算手段１３の動作を説明する。

図４は、現用パス経路計算手段１３が現用パスを設定する方法を説明する図である。
現用パス経路計算手段１３は、まず、現用パスポリシーに合致したリンクを抜き出す（Ｓ１１）。このとき、具体的には、現用パスポリシーに対応して、以下の３つの場合に対応して、それぞれ処理を行う。

該当するカスタマの現用パスポリシーが、「特定のカスタマが利用可能と指定されたリソース」である場合、該当するカスタマに割り当てられたリンクを抜き出す。

該当するカスタマの現用パスポリシーが、「任意のカスタマが利用可能と指定されたリソース」である場合、任意のカスタマに割り当てられたリンクを抜き出す。

該当するカスタマの現用パスポリシーが、「特定もしくは任意のカスタマが利用可能と指定されたリソース」である場合、該当するカスタマもしくは任意のカスタマに割り当てられたリンクを抜き出す。

次に、Ｓ１１のステップで抜き出されたリンクの中から更に現用パスに割り当てられたリンクを抜き出す（Ｓ１２）。具体的には、以下の３つの場合分けに応じて、リンクを抜き出す。

あるリンクが、「現用パス用に割り当てられたリンク」である場合、そのリンクは抜き出す。

あるリンクが、「予備パス用に割り当てられたリンク」である場合、そのリンクは抜き出さない。

あるリンクが、「現用パスと予備用パスの両方に割り当てられたリンク」である場合、そのリンクは抜き出す。

更に、リンクリソースＤＢ２３を参照して、抜き出されたリンクの中から、残余リソースがパスの要求帯域と同じか要求帯域より大きいリンクを抜き出す（Ｓ１３）。

そして、ここまでのステップで抜き出されたリンクの中から公知の方法でリンクを選んで、最短経路計算を行う（Ｓ１４）。この計算で、経路が見つからない場合は、経路計算エラーとなり、処理を終了する。このステップについての具体的な計算方法の例は、図５の説明で後記する。

そして、このステップＳ１４の計算結果をうけ、パスＤＢ２２の内容を更新し（Ｓ１５）、更にリンクリソースＤＢ２３も更新する（Ｓ１６）。パスＤＢ２２の更新の際には、パスＩＤを付け、ＶＰＮＩＤ、帯域及び経路計算結果のリンクリストを格納し、現用・予備フラグを「現用」に設定する。なお、この計算結果を受けて、パス設定手段１５により、実際にパスを設定する。

図５は、現用パスの設定方法のステップＳ１４において行う最短経路計算、すなわち、ネットワーク最短経路探索法の一例を説明する図である。

まず、ネットワークのノードとリンクの距離（コスト）を用意して参照できるようにする（Ｓ２１）。本実施形態では、全てのリンクが等距離として扱われているので、特にデータベースに項目が設けられていないが、距離の違いがあるリンクを扱う実施形態では、リンクリソースＤＢ２３にリンクの距離（コスト）の項目を設けて値を保存することになる。

次に、未調査のノードのグループに出発点以外の全ノードを保存し、調査済のノードのグループに出発点のノードを入れて初期化を行う（Ｓ２２）。

そして、調査済グループのノードから出ている最短のリンクを探索し、未調査グループで出発点から最短のノードを選び出す（Ｓ２３）。

そして、選んだノードが、未調査のものであるか否かを調べる（Ｓ２４）。その結果、未調査であった場合（Ｓ２４のＹｅｓ）、調査済のグループにそのノードを加え、そのノードまでの最短距離と経路を保存し（Ｓ２５）、ステップＳ２６に進む。既に調査済であった場合は（Ｓ２４のＮｏ）、何もせずにステップＳ２６に進む。

そして、その時点で、未調査のノードのグループを調べて、未調査のノードが残っているか否か調べる（Ｓ２６）。残っている場合（Ｓ２６のＹｅｓ）、Ｓ２３に戻って探索を繰り返す。もう残っていない場合には（Ｓ２６のＮｏ）、最短経路が計算できているので、到着点のノードの最短距離と経路を出力し（Ｓ２７）、終了する。

図６は、予備パス経路計算手段１４により、予備パスの経路計算を実行する手順を示す図である。この方法では、リンクリソースＤＢ２３と予備リソースＤＢ２４からそれぞれリンクを抜き出して、これらを合わせたリンクのグループから、経路を計算する。

まず、リンクリソースＤＢ２３を参照し、現用パスが使っているリンクのＳＲＬＧＩＤのうち、少なくとも１つと一致するＳＲＬＧＩＤをもつリンクを除く（Ｓ３１）。

次に、リンクリソースＤＢ２３を参照し、予備パスポリシーが合致するリンクを抜き出す（Ｓ３２）。具体的には、以下の３つの場合に分けて、それぞれ処理を行う。

該当するカスタマの予備パスポリシーが、「特定のカスタマが利用可能と指定されたリソース」である場合、該当するカスタマに割り当てられたリンクを抜き出す。

該当するカスタマの予備パスポリシーが、「任意のカスタマが利用可能と指定されたリソース」である場合、任意のカスタマに割り当てられたリンクを抜き出す。

該当するカスタマの予備パスポリシーが、「特定もしくは任意のカスタマが利用可能と指定されたリソース」である場合、該当するカスタマもしくは任意のカスタマに割り当てられたリンクを抜き出す。

次に、そのリンクの中から予備用に使えるリンクを抜き出す（Ｓ３３）。その際に、具体的には、以下のように３つの場合に分けて処理を行う。

あるリンクが、「現用パス用に割り当てられたリンク」である場合、そのリンクは抜き出さない。

あるリンクが、「予備パス用に割り当てられたリンク」である場合、そのリンクは抜き出す。

あるリンクが、「現用・予備パス両方に割り当てられたリンク」である場合、そのリンクは抜き出す。

そして、ここまでのステップで抜き出されたリンクの残余リソースの値をリンクリソースＤＢ２３から求めてリンクと共に保存する（Ｓ３４）。ここまでで、リンクリソースＤＢ２３からのリンクの抜き出しは終了する。

今度は、予備リソースＤＢ２４を参照して、予備用に使えるリンクのエントリがあるか否かを調べる（Ｓ３５）。

そして、そのようなエントリがない場合（Ｓ３５のＮｏ）、予備リソースＤＢ２４からのリンクの抜き出しを終了し、リンクリソースＤＢ２３からのリンクでＳ３９の経路計算の準備を行う。予備用に使えるリンクのエントリがあった場合（Ｓ３５のＹｅｓ）、そのエントリから、現用パスが使っているリンクのＳＲＬＧＩＤのうち、少なくとも１つと一致するＳＲＬＧＩＤをもつリンクを除く（Ｓ３６）。

更に、リソース共有ポリシーが合致するリンクを抜き出す（Ｓ３７）。具体的には、予備リソースＤＢ２４に既にエントリがあるリンクについて、以下の２つの場合に分けて、処理を行う。

該当するカスタマのリソース共有ポリシーが「他のカスタマと共有を許さない」である場合、個別のＶＰＮリソースに該当するＶＰＮＩＤのエントリがあるリンクを抜き出す。

該当するカスタマのリソース共有ポリシーが「他のカスタマとリソース共有を許す」である場合、共通リソースにエントリがあるリンクを抜き出す。

そして、全ての現用パスのＳＲＬＧの中で最小の予約リソースの空きを求めて保存する（Ｓ３８）。具体的には、以下の手順で予約リソースの空きの最小値を求める。この求め方は、リソースの共有ポリシーによって、若干異なる。また、この最小値の求め方の詳細については、図７を用いて後記し、ここでは概略だけを述べる。

まず、他のカスタマとの共有を許さない場合については、現用パスのＳＲＬＧに対応するエントリがないときは、該当するリンクの該当ＶＰＮＩＤに対応する個別ＶＰＮリソースの予約リソースを保存し、現用パスのＳＲＬＧに対応するエントリがあるときは、該当リンクの該当ＶＰＮＩＤリソースの予約リソースから、ＳＲＬＤＩＤのＳＲＬＧ予約リソースを引いた値を保存する。そして、これらの処理を現用パスの全てのＳＲＬＧＩＤについて調べて、その最小値を保存する。

他のカスタマとの共有を許す場合については、現用パスのＳＲＬＧに対応するエントリがないときは、該当するリンクの共通リソースの予約リソースを保存し、現用パスのＳＲＬＧに対応するエントリがあるときは、該当するリンクの共通リソースの予約リソースから、ＳＲＬＤＩＤのＳＲＬＧ予約リソースを引いた値を保存する。そして、これらの処理を現用パスの全てのＳＲＬＧＩＤについて調べて、その最小値を保存する。

次に、リンクリソースＤＢ２３から求めた残余リソースと予備リソースＤＢ２４から求めた予約リソースの空きを使って、予備パスに使えるリンクを求めて保存する（Ｓ３９）。このとき、Ｓ３４までに抜き出したリンクとＳ３８までに抜き出したリンクの情報も合わせて経路計算に用いるように準備する。

Ｓ３９のステップでどのような方法で計算をするかについて、２つの方法がある。まず、第１の方法は、Ｓ３４で保存した情報を用いて、このリンクの中から要求された帯域以上のリンクを抜き出した上で経路計算を試みて、経路が見つからなかったときに、Ｓ３８からの情報を用いるという方法である。Ｓ３８からの情報には、リンクとリソースの最小値が含まれているが、Ｓ３４のリンクとその残余リソースの情報に対して、リンクごとにＳ３８のリソースの最小値を加え合わせて帯域を補い、リンクごとに使える帯域を求めた上で、この中から要求帯域を満たすリンクを抜き出して経路計算に使うという方法である。

これに対して、第２の方法は、最初からＳ３４のリンクとその残余リソースの情報に対して、リンクごとにＳ３８のリソースの最小値を加え合わせて帯域を補い、リンクごとに使える帯域を求めた上で、この中から要求帯域を満たすリンクを抜き出して経路計算に使う方法である。

このようにして与えられたリンクの中から、図５で説明した計算方法の例などを用いて、最短経路を計算する（Ｓ４０）。そして、計算結果に基づいてパスＤＢ２２を更新して（Ｓ４１）、予備パスを加え、リンクリソースＤＢ２３及び予備リソースＤＢ２４も合わせて更新する（Ｓ４２）。このステップＳ４２におけるリンクリソースＤＢ２３及び予備リソースＤＢ２４の更新手順は、図８を用いてより詳細に説明する。

図７は、図６のステップＳ３８における空きリソースの最小値を求める方法を説明する図である。まず、現用パスのＳＲＬＧＩＤの１つを選択する。そして、最小値を格納する変数ＭＩＮの初期値を大きな値に設定して初期化する（Ｓ５１）。

次に、予備リソースＤＢの中で該当するリンクのエントリの中に前記のＳＲＬＧＩＤのエントリがあるか否かを調べる（Ｓ５２）。

調べた結果、最初に選んだＳＲＬＧＩＤのエントリがなかった場合には（Ｓ５２のＮｏ）、リソース共有のポリシーに応じて、予約リソースの値を抽出する。まず、リソースの共有を許さないポリシーの場合には、そのエントリが該当するカスタマのＶＰＮＩＤに対応する個別ＶＰＮリソースの予約リソースの値を抽出する。そして、リソースの共有を許す場合には、共通リソースの予約リソースの値を抽出する（Ｓ５３）。そして、この値をＭＩＮとの比較のステップＳ５５で用いる。

最初に選んだＳＲＬＧＩＤのエントリがあった場合には（Ｓ５２のＹｅｓ）、やはりリソースの共有ポリシーに応じて、実際に使えるリソースの量を求める。まず、リソースの共有を許さないポリシーの場合には、そのエントリが該当するカスタマのＶＰＮＩＤに対応する個別ＶＰＮリソースの予約リソースから、対応するＳＲＬＧＩＤのＳＲＬＧ予約リソースの値を減算して、使えるリソース量を計算する。そして、リソースの共有を許す場合には、共通リソースの予約リソースから、対応するＳＲＬＧＩＤのＳＲＬＧ予約リソースの値を減算して、使えるリソース量を計算する（Ｓ５４）。そして、この値を次のＭＩＮとの比較のステップＳ５５で用いる。

そして、Ｓ５３又はＳ５４で求めた値をその時点で保存されているＭＩＮの値と比較を行い、前記の値が、ＭＩＮより小さいか否か調べる（Ｓ５５）。

その値が小さい場合は（Ｓ５５のＹｅｓ）、ＭＩＮの値を前記の値に更新し、新たな最小値とする（Ｓ５６）。その上でステップＳ５７に進む。その値がＭＩＮより大きいか等しい場合は（Ｓ５５のＮｏ）、そのままステップ５７に進む。

ここまでの過程で、１つのＳＲＬＧＩＤに関する処理が終了するが、この時点で現用パスの全ＳＲＬＧＩＤについて確認したか否かを調べる（Ｓ５７）。そして、終了していた場合は（Ｓ５７のＹｅｓ）、その時点でのＭＩＮの値を使えるリソースの最小値として保存し（Ｓ５８）、終了する。まだ他のＳＲＬＧＩＤが残っている場合には（Ｓ５７のＮｏ）、現用パスの次のＳＲＬＧＩＤを選択し（Ｓ５９）、ステップＳ５２に戻って処理を繰り返す。

図８は、図６の最後のステップＳ４２におけるリンクリソースＤＢ２３及び予備リソースＤＢ２４の更新を説明する図である。まず、予備パスの計算結果をうけて、予備リソースＤＢ２４に更新対象のリンクのエントリがあるか否かを調べる（Ｓ６１）。

更新対象のエントリがある場合（Ｓ６１のＹｅｓ）、リソース共有ポリシーに対応したエントリがあるか否か調べる（Ｓ６３）。そして、そのようなエントリがない場合（Ｓ６３のＮｏ）、残余リソースを新規に設定される予備パスの帯域だけ減らし（Ｓ６２）、ステップＳ６４以後の処理を続ける。対象のエントリがある場合（Ｓ６３のＹｅｓ）、後記するステップＳ６５に進んで、予備リソースＤＢ２４の更新を行う。

更新対象のリンクのエントリがない場合（Ｓ６１のＮｏ）、リンクリソースＤＢ２３の更新対象リンクについて、まず、残余リソースを新規に設定される予備パスの帯域だけ減らす（Ｓ６２）。そして、ステップＳ６４に進む。

ステップＳ６４では、まだ、予備リソースＤＢ２４にエントリがないリンクについて、どのテーブルにエントリを作るべきか否かを判定する。具体的には、当該リンクのリソース共有ポリシーが他のカスタマとリソースの共有を許すか否かを調べる（Ｓ６４）。

リソース共有ポリシーが共有を許す場合（Ｓ６４のＹｅｓ）、まず、予備リソースＤＢ２４の共通リソースのテーブルにエントリを追加する（Ｓ６９）。そして、共通リソースのテーブルに関係するＳＲＬＧＩＤごとにエントリを作成する（Ｓ７０）。次に、ＳＲＬＧＩＤリソースのＳＲＬＧ予約リソースとして、新規に設定する予備パスの使用帯域を記入し（Ｓ７１）、同様に、共通リソースの予約リソースとして、予備パスの使用帯域を記入して（Ｓ７２）、処理を終了する。

リソース共有ポリシーが共有を許さない場合（Ｓ６４のＮｏ）、まず、予備リソースＤＢ２４の個別ＶＰＮリソースのテーブルにエントリを追加する（Ｓ７３）。そして、カスタマ別に管理されている個別ＶＰＮリソースのテーブルにＳＲＬＧＩＤごとにエントリを作成する（Ｓ７４）。次に、ＳＲＬＧＩＤリソースのＳＲＬＧ予約リソースとして、予備パスの使用帯域を記入し（Ｓ７５）、個別ＶＰＮリソースの予約リソースとして予備パスの使用帯域を記入して（Ｓ７６）、更新処理を終了する。

ステップＳ６５では、更新対象のパスのＳＲＬＧＩＤのＳＲＬＧ予約リソース値を予備パスで使う帯域分だけ増加させる（Ｓ６５）。そして、ここで増加させたＳＲＬＧ予約リソースの値が、既存の予約リソースを上回ったものがあるか否か調べる（Ｓ６６）。これは、予備パスに予約したリソースを使っただけでは新規に設定する予備パスの帯域を賄いきれないリンクがないか否かを調べるものである。このような予約リソース不足のリンクがなかった場合（Ｓ６６のＮｏ）、これ以上の更新の必要はないので、更新処理を終了する。それに対して、予約リソース不足のリンクがあった場合（Ｓ６６のＹｅｓ）、予備リソースＤＢ２４において予備パス用に不足分だけ予約リソースを増加させ（Ｓ６７）、リンクリソースＤＢ２３において該当するリンクの残余リソースをその不足分だけ減らして（Ｓ６８）、更新処理を終了する。

［その他のデータベース構成による実施形態］
図９は、網障害復旧管理装置１の他の実施形態の例を説明する図である。図９をここまで説明してきた実施形態を示す図２と比較すると、リンクリソースＤＢ２３が管理する項目が異なっているだけで、他の構成は全て同じになっている。よって、ここでは扱いが異なる部分だけを説明する。

本実施形態になって最も異なる点は、リンクリソースＤＢ２３で現用・予備フラグの項目がなくなっている点である。これにより、リンクレベルでの管理において、現用パスに割り当てられているリンクと予備パス用に割り当てられているリンクとを区別しないために、１つのリンクのハードウェアを現用パスに割り当てられているものと予備パスに割り当てられているものの２つに分けて管理する必要がなくなる。

リンクリソースＤＢ２３において現用パス用と予備パス用の区別がなくなった代わりに、本実施形態では、ポリシーＤＢ２１での予備パスポリシーの管理を変更する。具体的には、予備パスポリシーとして、「特定のカスタマが利用可能と指定されたリソース」及び「任意のカスタマが利用可能と指定されたリソース」に加えて「予備パス用に指定されたリソース」も指定できるようにして、この３つの何れかもしくは複数を利用可能と設定できることとした。更にリンクリソースＤＢ２３のＶＰＮＩＤとして、「任意」、「ＶＰＮＩＤの１つ以上のリスト」又は「予備」が設定されるようになる。

これに伴って、現用パス経路計算手段１３及び予備パス経路計算手段１４に若干の変更が生じる。まず、現用パス経路計算手段１３においては、現用パスと予備パスの区別がなくなったために、図４におけるＳ１２のステップがなくなり、現用のリンクの抜き出しを行わなくなる。そして、予備パス経路計算手段１４においては、リソースポリシーが変更されているので、ポリシーに対応したリンクの抜き出しを行う最初のステップが変わる。具体的には、図６におけるステップＳ３２及びステップＳ３３の代わりに以下に示す１つのリンク抜き出しを行うステップに置き換える。

新規の予備パスの割り当てをうけるカスタマの予備パスポリシーが、「特定のカスタマが利用可能と指定されたリソース」を含む場合は、そのカスタマに割り当てられたリンクを抜き出す。そして、そのカスタマの予備パスポリシーが、「任意のカスタマが利用可能と指定されたリソース」を含む場合は、任意のカスタマに割り当てられたリンクを抜き出す。そして、そのカスタマの予備パスポリシーが、「予備パス用に指定されたリソース」を含む場合、予備パス用に割り当てられたリンクを抜き出す。

本実施形態においては、データベースの管理を若干簡易化したが、それによって網障害復旧において、特に不都合は生じない。そして、リンクのリソースの記述を行うリンクリソースＤＢ２３の管理は容易に行えるようになる。

ここまで説明してきたように、２つの実施形態のいずれにおいても、現用パスと予備パスのそれぞれについて、カスタマのポリシーに基づいて、きめ細かくリンクのリソースを割り当てることができる。これにより、網障害時においても、カスタマの要求に応じた形で、カスタマの網の運用への影響を最小限に抑えて、迅速に網を復旧することができる。更に、網障害の発生前にも、網障害のリスクを最小限に抑えるリスク管理を行うことができる。なお、前記の２つの実施形態のいずれにおいても、リソース割り当て手段１１、ポリシー設定手段１２、現用パス経路計算手段１３、予備パス経路計算手段１４、パス設定手段１５及びパス切り替え手段１６は、網障害復旧管理装置が備える演算装置によるプログラムの実行処理により実現される。

（ａ）は、本実施形態において前提とするネットワークの最も基本的な形態の例を示す図であり、（ｂ）は、リンクの方向性を考慮する形態の例を示す図である。 網障害復旧管理装置1の構成例を示す図である。 パス経路の例を示す図である。 現用パス経路計算手段により、現用パスの経路計算を実行する手順を示す図である。 ネットワーク最短経路探索法の一例を説明する図である。 予備パス経路計算手段により、予備パスの経路計算を実行する手順を示す図である。 図６のステップＳ３８における空きリソースの最小値を求める方法を説明する図である。 図６のステップＳ４２におけるリンクリソースＤＢ２３及び予備リソースＤＢ２４の更新の動作を説明する図である。 図９は、網障害復旧管理装置のその他の実施形態の例を説明する図である。

符号の説明

１ 網障害復旧管理装置
１１ リソース割り当て手段
１２ ポリシー設定手段
１３ 現用パス経路計算手段
１４ 予備パス経路計算手段
１５ パス設定手段
１６ パス切り替え手段
２１ ポリシーデータベース（ポリシーＤＢ）
２２ パスデータベース（パスＤＢ）
２３ リンクリソースデータベース（リンクリソースＤＢ）
２４ 予備リソースデータベース（予備リソースＤＢ）

Claims (8)

1. 複数のカスタマを同一の網に収容する複数カスタマ収容網において、
   網障害復旧管理装置が、
   各リンクのリソースをどのカスタマに割り当てるかを設定する機能と前記リンクを現用パス又は予備パスに割り当てるかを設定する機能を有するリソース割り当て手段と、
   カスタマごとのリソースの割り当てポリシーを設定するポリシー設定手段と、
   各カスタマが利用可能なリソースを利用して現用パスの経路計算を行う現用パス経路計算手段と、
   各カスタマが利用可能なリソースを利用して予備パスの経路計算を行う予備パス経路計算手段と、
   前記現用パス経路計算手段又は前記予備パス経路計算手段によって計算されたパスの設定を行うパス設定手段と、
   網障害発生時にパスの切り替えを行うパス切り替え手段とを備え、
   前記リソース割り当て手段が、リソースを特定のカスタマ又は共有のリソースに割り当てた後に、前記リソースをそれぞれ現用パス又は予備パスに割り当て、
   前記ポリシー設定手段が、カスタマごとのリソースの割り当てポリシーを設定し、
   前記現用パス経路計算手段が、現用パスを計算し、
   前記予備パス経路計算手段が、予備パスを計算し、
   前記パス設定手段が、前記現用パス及び前記予備パスを網に設定し、
   前記現用パスの網障害発生時には、前記パス切り替え手段が、予め設定されている前記予備パスにパスの切り替えを行うこと
   を特徴とする網障害復旧管理方法。
   
2. 前記リソース割り当て手段が、リンクのリソースを、１つ以上の特定のカスタマ又は任意のカスタマに割り当て、
   どのカスタマが利用可能であるのかを前記リンクのリソースごとにデータベースに記述して、管理すること
   を特徴とする請求項１に記載の網障害復旧管理方法。
3. 前記リソース割り当て手段が、リンクのリソースを、現用パス用又は予備パス用に割り当て、
   現用パス用と予備パス用のどちらが利用可能であるのかを前記リンクのリソースごとに
   データベースに記述して、管理すること
   を特徴とする請求項２に記載の網障害復旧管理方法。
4. 前記リソース割り当て手段が、リンクのリソースを、１つ以上の特定のカスタマ、任意のカスタマ又は予備パス用に割り当て、
   どのカスタマがどのリンクのリソースを利用可能であるのかを前記リンクのリソースごとにデータベースに記述して、管理すること
   を特徴とする請求項１に記載の網障害復旧管理方法。
5. 前記ポリシー設定手段が、現用パス及び予備パスが使用するリソース指定において、
   特定のカスタマが利用可能と指定されたリソース又は任意のカスタマが利用可能なリソースの何れか１つ又は両方を利用可能であることをデータベースに記述し、
   前記データベースの内容に基づいてカスタマごとにリソースの割り当てポリシーを設定すること
   を特徴とする請求項１乃至請求項４の何れか１項に記載の網障害復旧管理方法。
6. 前記ポリシー設定手段が、
   カスタマが他のカスタマとリソースの共有を許すか許さないかをデータベースに記述し、
   前記カスタマごとにリソースの割り当てポリシーを設定すること
   を特徴とする請求項５に記載の網障害復旧管理方法。
7. 前記ポリシー設定手段が、
   特定のカスタマが利用可能と指定されたリソース及び任意のカスタマが利用可能と指定されたリソースから何れか１つ以上のリソースが現用パス用に利用可能であることと、
   特定のカスタマが利用可能と指定されたリソース、任意のカスタマが利用可能と指定されたリソース及び予備パス用に利用可能とされたリソースから何れか１つ以上のリソースが予備パス用に利用可能であること
   をデータベースに記述し、
   前記データベースの内容に基づいてカスタマごとにリソースの割り当てポリシーを設定すること
   を特徴とする請求項１乃至請求項４の何れか１項に記載の網障害復旧管理方法。
8. 請求項１乃至請求項７の何れか１項に記載の網障害復旧管理方法を実行すること
   を特徴とする網障害復旧管理装置。

Images