(57)【要約】  大規模な波長分割多重（ＷＤＭ）メッシュネットワーク内など、保護リソース共有機会を識別して、オプションで、これを管理するための方法およびシステム。
2011518517.tif 000002
【特許請求の範囲】
【請求項１】
メッシュネットワーク内で保護容量を分散するための方法であって、
メッシュネットワーク内の複数の保護された光路のそれぞれに関連する主容量および保護容量を識別するステップと、
複数のｋ個の要素障害のそれぞれに関して、ｋ個の要素障害から回復するための対応する保護容量を決定するステップと、
複数の保護共有機構のそれぞれに従って、保護容量共有機会を決定するステップと、
決定された保護共有機会に応答して、保護容量割振りを適合するステップとを含む、方法。
【請求項２】
保護共有機構が管理制約およびサービス制約のうちの少なくとも１つに従って選択される、請求項１に記載の方法。
【請求項３】
メッシュネットワークのそれぞれの保護された光路に関して、複数の故障した経路のそれぞれに関するバックアップリンク容量を決定するステップと、
故障した経路の１つまたは複数のリンクをその他の光路に割り当てるステップと、
バックアップ容量全体を表すデータを格納するステップと
をさらに含む、請求項１に記載の方法。
【請求項４】
最高でｋ個までの保護された光路のセットＤに関して、主リンク容量Ｃｐを決定するステップと、
主リンク容量Ｃｐを表すデータを記憶するステップと
をさらに含む、請求項２に記載の方法。
【請求項５】
主経路順序およびバックアップ経路順序を決定するために、前処理の発見的方法を起動させるステップをさらに含み、前処理の発見的方法が、それぞれの光路ｄに関して、最小の最大リンク容量に関連する、それぞれの経路ｐを決定するために、最高でｋ個までの保護された光路のセットＤ内のそれぞれの光路ｄを反復的に処理するように動作する、
請求項３に記載の方法。
【請求項６】
最高でｋ個までの保護された光路のセットＤ内のそれぞれの光路ｄに関する総バックアップリンク容量が、公称共有機構、保護解放機構、層別機構、非層別機構、動作再使用機構、およびフェイルオーバ順序機構のうち少なくとも１つを使用して決定される、請求項４に記載の方法。
【請求項７】
処理されている光路ｄが、当初、ｋに設定されたａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタと関連付けられており、光路ｄの障害が別の光路に影響を及ぼすことが決定された場合、ａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタが減じられる、請求項３に記載の方法。
【請求項８】
前記影響を受けた光路が同じ保護階層のメンバーである場合だけ、ａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタが減じられ、保護階層が、サービスタイプ、地理的領域、および／またはサービスプロバイダの点から画定される、請求項７に記載の方法。
【請求項９】
メッシュネットワーク内の保護容量共有機会を識別するための方法を実行するために、コンピュータの動作を適合させる命令を実行するためのコンピュータを含むネットワーク管理システム（ＮＭＳ）であって、方法が、
保護された光路のセットＤ内のそれぞれの光路ｄに関して、最高でｋ個までの保護された光路のセットＤ内のそれぞれの光路ｄに関する複数の障害タイプのそれぞれを処理することによって、総バックアップリンク容量を決定するステップであって、最高でｋ個までの保護された光路のセットＤ内のそれぞれの故障した光路ｄに関連するリンク容量が、利用可能な容量プールに解放される、決定するステップと、
バックアップ容量全体Ｃを表すデータを格納するステップとを含む、ネットワーク管理システム（ＮＭＳ）。
【請求項１０】
メッシュネットワーク内の保護容量を分散するための方法を実行するために、コンピュータの動作を適合させる命令を実行するためのコンピュータを含むネットワーク管理システム（ＮＭＳ）であって、方法が、
メッシュネットワーク内の複数の保護された光路のそれぞれに関連する主容量および保護容量を識別するステップと、
それぞれの考えられるｋ個の要素障害に関して、ｋ個の要素障害から回復するための対応する保護容量を決定するステップと、
複数の保護共有機構のそれぞれに従って、保護容量共有機会を決定するステップと、
決定された保護共有機会に応答して、保護容量割振りを適合するステップとを含む、ネットワーク管理システム（ＮＭＳ）。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、参照により本明細書に組み込まれている、２００８年４月１８に出願した米国仮特許出願第６１／０４６，２３８号の優先権を主張するものである。
【０００２】
本発明は、通信ネットワークに関し、より詳細には、大規模な波長分割多重（ＷＤＭ）メッシュネットワーク内などの保護リソース共有機会を決定することに関する。
【背景技術】
【０００３】
今日の光トランスポートネットワーク（ｏｐｔｉｃａｌ  ｔｒａｎｓｐｏｒｔ  ｎｅｔｗｏｒｋｓ）は、共有された経路保護を備えたメッシュネットワークとして、ますます設計され、配備され、プロビジョニングされている。典型的なメッシュネットワーク設計は、ネットワーク内の単一のノード障害またはリンク障害の仮定に基づく経路保護を含む。リンク切断またはリンク障害の可能性が低いことを考慮すると、これは高可用性ノードにとって合理的な仮定である。しかし、かかる設計仮定は、圧縮されたタイムフレーム内に発生する複数の障害を伴う可能性がある、破滅的なシナリオ、または計画された攻撃および組織的な攻撃など、障害が独立した偶発的なイベントでない可能性を十分に考慮に入れない。したがって、防衛機関および民間機関による、複数の障害に対する回復性に富む、ロバストな高速基幹陸上ネットワークの必要が存在する。しかし、複数の障害に対してロバストなマルチサービスネットワークを設計する主な課題のうちの１つは、能力または費用対効果の高い形で、必要とされる冗長性を提供することである。したがって、容量共有は、リンク障害またはノード障害の場合に、経路の需要フロー（すなわち、需要）をサポートするために必要なリソースが依然として満たされるように、ネットワーク設計およびネットワークプロビジョニングという文脈において望ましい。特に有利なのは、大規模な波長分割多重（ＷＤＭ）メッシュネットワーク内の容量共有である。
【０００４】
共有された保護に対する１つの手法は、それぞれの光リソースの需要フローに関して、送信元ノードと宛先ノードとの間に２つのノード分離光路（ｎｏｄｅ−ｄｉｓｊｏｉｎｔ  ｌｉｇｈｔｐａｔｈｓ）（すなわち、主経路に関して１つ、およびバックアップ経路すなわち保護経路に関して１つ）を見つけることである。かかる分離経路は、故障隔離を要求しない利点を提供し、したがって、代替の手法に比べて、より速い回復を実現する傾向がある。ノード分離経路を使用して、単一のノード障害またはリンク障害に関する保護のための容量を計画および／またはプロビジョニングするとき、２つの需要の主経路がノード分離されており、基礎となるグラフトポロジがバックアップ経路のリンク交差を可能にする場合、２つの需要は保護容量を共有することができる。この設計は、ネットワーク内のどこかで１つのかかる障害が発生した後で、残りのリソース需要が保護を有することが期待されず、したがって、単一の障害から回復するためのその保証を喪失する（すなわち、残りのリソース需要は１つの保護された需要から非保護の需要に「降格される（ｄｅｍｏｔｅｄ）」）という仮定に基づく。そうでない場合、それぞれのリソース需要だけに直接的に影響する１つの障害の後で、そのそれぞれのリソース需要が回復可能でなければならない場合、その回復帯域幅は専用でなければならない。主経路は分離されるため、単一の障害は両方の需要に同時に影響を与えないことになり、ネットワーク内の任意の１つの故障の後で、第２の重要に関する保護は求められないため、２つの需要は保護帯域幅を共有することができる。
【０００５】
共有された保護に対する別の手法は、故障した主経路の帯域幅が、その他の需要の回復のために利用可能にされる場合である。これは、主再使用（ｐｒｉｍａｒｙ  ｒｅｕｓｅ）またはスタブの解放（ｓｔｕｂ  ｒｅｌｅａｓｅ）と呼ばれ、詳細には、回復のためにその他の需要によって再使用するために、障害によって影響を受けた需要の主経路の容量を解放することである。主再使用に対する１つの欠点は、かかる再使用は復帰（すなわち、故障した需要に対する修正が完了すると、故障した需要を元の主経路に回復すること）を妨げる可能性がある点である。しかし、復帰を実施する制御プレーンの複雑さにより、共有されたメッシュ経路保護を使用しているネットワークは、主再使用を可能にするかまたは妨げるが、通常、復帰を実施しない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
先行技術に関連する様々な欠点は、複数の保護された光リソース需要を用いている大規模な波長分割多重（ＷＤＭ）メッシュネットワーク内でなど、保護リソース共有機会を識別し、オプションで、管理するための方法およびシステムの本発明によって対処される。
【課題を解決するための手段】
【０００７】
一実施形態では、メッシュネットワーク内で保護容量を分散するための方法は、メッシュネットワーク内の複数の保護された光路のそれぞれに関連する主容量および保護容量を識別するステップと、それぞれの考えられるｋ個の要素障害に関して、ｋ個の要素障害から回復するための対応する保護容量を決定するステップと、複数の保護共有機構のそれぞれに従って、保護容量共有機会を決定するステップと、その決定された保護共有機会に応答して、保護容量割振りを適合させるステップとを含む。
【０００８】
その他の実施形態は、ｋレベルの保護およびバックアップ容量共有を使用して、メッシュネットワーク内で必要とされるバックアップ容量を決定するための方法およびシステムを含む。一実施形態では、保護容量を分散するための方法は、メッシュネットワークのそれぞれの保護された光路に関して、複数の故障した経路のそれぞれに関するバックアップ経路容量を決定して、故障した経路の１つまたは複数のリンクをその他の光路に割り当てることによって実施される。バックアップ容量全体を表すデータは、次いで、例示的に、保護管理機構による使用のために格納される。
【０００９】
様々な実施形態は、添付の図面と共に、以下の詳細な説明を考慮することによって、容易に理解されよう。
【００１０】
理解を円滑にするために、可能な場合、図面に共通な同一要素を示すために、同一の参照番号が使用されている。
【図面の簡単な説明】
【００１１】
【図１】本明細書で説明される様々な実施形態によるメッシュネットワークのハイレベルブロック図である。
【図２】一実施形態による方法の流れ図である。
【図３Ａ】一実施形態による容量共有決定方法の流れ図である。
【図３Ｂ】一実施形態による容量共有判定方法の流れ図である。
【図４】図３の容量共有決定方法における使用に適した前処理方法の流れ図である。
【図５】図３の容量共有決定方法における使用に適した障害処理方法の流れ図である。
【発明を実施するための形態】
【００１２】
様々な実施形態のその他の態様、特徴、および利点は、以下の詳細な説明、添付の特許請求の範囲、および添付の図面からより十分に明らかになるであろう。
【００１３】
様々な実施形態は、ネットワーク内で保護容量を共有することによって、大規模な波長分割多重（ＷＤＭ）メッシュネットワークなど、通信ネットワークの回復性を改善するように構成された管理方法を提供する。詳細には、様々な実施形態は、ネットワークの拡張されたパフォーマンス全体、リンク障害またはノード障害からの改善された回復、およびネットワークパフォーマンスに伴う改善されたカスタマ満足度を提供するために、かかるネットワーク内で保護容量を分散し、かつ／または再度割り振る。
【００１４】
様々な実施形態は、例示的に、光トランスポートネットワークにおける経路保護パラダイムに基づいて、別々にまたは組み合わせて効率的な保護容量共有を提供する、１つまたは複数の共有方法を用いる。様々な実施形態の方法論は、ネットワーク設計ツール、オンライン（もしくはオフライン）プロビジョニングシステム、またはより一般的に、利用可能な保護容量共有機会の決定から利益を得る管理機構という文脈で用いられることが可能である。プロビジョニングシステムにおいて、共有結果は、例えば、複数のバックアップ経路が利用可能なとき、使用されるバックアップ経路の順序でネットワーク管理および制御システムに渡される。
【００１５】
一実施形態では、保護容量を分散するための方法は、メッシュネットワークのそれぞれの保護された光路に関して、複数の故障した経路のそれぞれに関するバックアップ経路容量を決定して、故障した経路の１つまたは複数のリンクをその他の光路に割り当てて、保護管理機構による使用のためのバックアップ容量全体を示すデータを格納することによって実施される。
【００１６】
図１は、本明細書で説明される様々な実施形態によるメッシュネットワークのハイレベルブロック図を示す。詳細には、図１のメッシュネットワーク１００は、複数の相互接続されたノード１１０と、ネットワークマネージャ１２０とを含む。図１に示されたネットワーク１００は、単に例示的である点を当業者は理解されよう。様々な実施形態は、異なる数のノードを備えた、異なるネットワークトポロジおよび／またはネットワークを含み得る。ネットワークは、マルチレイヤネットワークおよび／またはマルチサービスネットワークであり得る。
【００１７】
ノード１１０のそれぞれは、ある数のその他のノードに接続される（連結される）。詳細には、任意の特定のノードに対するノード間リンクの数は、ｋ個の保護された需要をサポートするために十分多くあるべきであり、この場合、「ｋ」は、事前に選択された整数である。すなわち、ノードが単一のリンク障害（ｋ＝１）に耐える必要がある経路内に含まれる場合、そのノードは、２つの追加ノードに対するリンク（すなわち、２つの宛先ノードに対するリンク、ならびに１つの発信元ノードからのリンク）を有さなければならない。ノードが、２つのリンク障害（ｋ＝２）に耐える必要がある経路内に含まれる場合、そのノードは、３つの追加ノードに対するリンク（すなわち、３つの宛先ノードに対するリンク、ならびに１つの発信元ノードからのリンク）を有さなければならない。
【００１８】
ネットワークマネージャ１２０は、遠隔位置からネットワーク全体１００を管理するとして示される。しかし、ネットワークマネージャ１２０は、１つまたは複数のノードに動作可能に結合され得る点を当業者は理解されよう。さらに、複数のネットワークマネージャは、協働的な分配ネットワークマネージャ（ｃｏｏｐｅｒａｔｉｖｅ  ｄｉｓｔｒｉｂｕｔｉｖｅ  ｎｅｔｗｏｒｋ  ｍａｎａｇｅｒ）を作成するために、ネットワークの全体にわたって分散されることが可能である。
【００１９】
ネットワークマネージャ１２０は、例示的に、入出力（Ｉ／Ｏ）インターフェースと、データプロッサと、メモリとを有するコンピューティングシステムを含む。本発明の実施形態による方法論は、メモリ内にコンピュータ実行可能な形態で格納され、かつ／またはプロセッサによって実行されるソフトウェアからの命令によって実行され得る。
【００２０】
様々な実施形態は、コンピュータプログラム製品として実装されることも可能であり、コンピュータ実行可能命令は、コンピュータによって処理されるとき、本明細書で説明される方法が実行されるように、コンピュータの動作を適合させる。これらの方法を起動させる命令は、固定デジタルデータ記憶媒体内もしくは着脱可能なデジタルデータ記憶媒体内に格納されて、ブロードキャスト媒体などの信号担持媒体上でデジタルデータストリームを経由して送信され、かつ／またはデジタルコンピューティングデバイス内のワーキングメモリ内に格納されることが可能である。
【００２１】
本明細書において、管理方法は、様々なタイプのメッシュネットワーク光（例えば、ＷＤＭ）トランスポートネットワーク内の使用のために構成される。これらのネットワークは、ユーザに対する複数のサービスタイプ、例えば、様々なＱｏＳカテゴリをサポートすることが可能である。それぞれのサービスは、その独自の保護等級を有する。本明細書において、サービスのｋ個の障害に耐えるように設計されたサービスタイプは、ｋ個の保護されているサービスと呼ばれる。これらの障害は、ノード障害および／またはリンク障害であり得る。メッシュネットワークは、そのノード同士の間にｋ個の保護されたサービスを提供することが可能であり、ｋの値はノードによって異なる。これらの様々な実施形態は、それぞれのサービスに関して事前に選択された保護レベルを提供する保護方式を設計するための方法を提供する。
【００２２】
サービスは、サービス終点ノード間のトランスポート層の波長回路（エンドツーエンド光路）によって含有または提供される。それぞれの波長回路は、送信元ノードと宛先ノードとの間に波長サービスを提供するための専用であるか、または一緒に集約されたサブ波長トラフィック（ｓｕｂ−ｗａｖｅｌｅｎｇｔｈ  ｔｒａｆｆｉｃ）を含む。前者の場合、波長サービスは、波長の全体を占有することになり、したがって、波長回路の保護等級は、関連する波長サービスのものである。後者の場合、波長回路は、集約デバイスおよび／または終端デバイスの間でサブ波長トラフィックをトランスポートしている。サブ波長トラフィックが波長回路に集約されるとき、サブレートトラフィックは、同じ保護等級内にあってよく、または保護等級の異質の混合物であってもよい。どちらの場合も、波長回路の保護等級は、その回路内の最高サブレート保護等級のものに割り当てられる。２つのノード間の保護等級内の波長回路要件は需要を成す。保護等級内のすべての需要のセットは保護階層を成す。
【００２３】
保護階層内のすべてのトラフィックは、適切な数の光トランスポート障害から保護される。この保護は、様々な実施形態において、ノード分離経路を経由して経路保護されたエンドツーエンド波長回路の使用を介して、光トランスポート層内で提供される。ノード分離性という用語は、中間ノードを指し、波長回路の終端ノードを指すとは限らない。この実施形態は、ｋ以上の程度のノード間のｋ個の保護された需要に対して、高速な複数の障害に対する保護を提供する。すべての可能な保護パラダイム（経路保護、局所迂回など）の点から、ｋ個の保護された需要が回復可能である十分な条件は、終端ノード間においてネットワークトポロジ内にｋ＋１個のノード分離経路が存在することである。任意のｋ個の保護されたサービスは、ｋ個の保護可能なサービスであること、すなわち、終端ノード間に必要数のノード分離経路が存在することが仮定される。
【００２４】
本発明の一実施形態では、帯域幅要件は、まず複数の保護トポロジを計画し（または複数の保護トポロジに関する計画にアクセスし）、次いで、必要とされる保護容量内の共有機会を追求することによって、容量削減を決定することによって決定される。
【００２５】
したがって、それぞれの需要に関する主経路および保護経路のセットを考慮すると、必要とされる保護容量は、それらの需要およびその保護レベルに関するすべての考えられる障害シナリオを考慮するとき、どれだけの容量が共有されることが可能であるかを識別することによって決定され得る。本発明は、保護容量共有の様々な選択可能な方法を適用することに基づいて、この決定を下す。
【００２６】
図２は、一実施形態による方法の流れ図を示す。図２の方法２００は、図３Ａ−５でさらに説明される方法のハイレベル表示である。
【００２７】
詳細には、図２の方法２００は、メッシュネットワーク内のそれぞれの光路に関する主容量が識別されるステップ２０５で開始される。この識別は、枠２０７によれば、サービス接続性、トラフィック行列情報、またはネットワーク設計システムもしくはネットワーク管理システムに利用可能なその他の情報を使用する。ステップ２１０において、メッシュネットワーク内のそれぞれの光路に関する保護容量が識別される。オプションのステップ２１５において、複数の光路をサポートしている保護経路が識別される。ステップ２２０において、メッシュネットワーク内の複数のｋ個の障害の組合せのそれぞれに関連する保護容量が計算される。すなわち、ｋ＝３であると仮定すると、以下でより詳細に説明されるように、３つの要素すなわち３つのリンクを伴う、複数の障害の組合せのそれぞれが識別される。オプションで、考えられるｋ個の障害の組合せのすべてが識別される。ステップ２０５−２２０は、ｋ個の障害の組合せのいずれかに関して、すべての光路すなわち需要の継続的な動作を可能にするために、（共有なしで）必要な総保護容量を決定するために動作する。
【００２８】
ステップ２２５において、複数の保護共有機構のそれぞれに関連する機会が決定される。この決定は、枠２２３によれば、ネットワーク管理条件および／もしくはネットワーク管理制約、またはカスタマ要件、サービス要件など、その他の条件に関して下される。以下で述べられるように、用いられることが可能ないくつかの保護共有機構が存在する。特定の機構の選択は、制限、管理条件／管理制約（例えば、トポロジ、管理システム、ネットワーク要素／ネットワークリンクの同質性または異質性など）、サービス条件／サービス制約（例えば、階層的なサービス、保証されたサービスレベルなど）、ならびにその他の要因を処理することによって行われる。
【００２９】
ステップ２３０において、ネットワークの主容量および／または保護容量の割振りは、ステップ２２５において識別された機会に応答して適用される。様々な実施形態において、反復プロセスは、それぞれの障害シナリオに関して、ネットワーク内で主容量および保護容量の割振りを適応することによって、ネットワークの「最善の」プロビジョニングが実現され得るように、複数の可能な共有機会を決定するために起動される。このプロビジョニングは、本明細書で説明される、いくつかの要因によって影響を受ける。
【００３０】
保護容量共有を可能にするためには、以下の２つの条件を満たすことが望ましい：すなわち、（１）関連する需要に関して、主波長回路およびバックアップ波長回路向けのノード分離経路を有することが可能なトポロジ要件、および（２）バックアップ経路／保護経路の少なくともいくつかの交差である。２つの需要のそれぞれの１つまたは複数の動作経路に関するすべての考えられる障害シナリオを考慮すると、同じ保護帯域幅が必要とされない場合、トポロジ的に適切な経路を有する２つの需要は共有し得る。障害シナリオの分離性は、２つの需要の経路がトポロジ的に分離する場合に発生する可能性がある。バックアップ経路が分離されない場合、保護共有は、保護階層の降格、すなわち、（それらが需要の動作経路に直接的に影響を及ぼすか否かにかかわらず、ネットワーク全体のトランスポート波長回路が耐えなければならない障害の数によって定義される）需要の保護等級が、それぞれの障害に関して一度削減されることによって可能にされる。ネットワーク全体の障害を障害カウント内に含むことは、バックアップ経路が交差して、需要に関して分離された障害を生み出し、これにより、保護容量共有を可能にする。したがって、ｋ個の保護された波長回路は、ネットワーク内のｋ個のトランスポートノード障害およびリンク障害の任意の組合せから保護されなければならない。
保護容量共有のための機構
本実施形態の方法論は、需要フローに関する一次保護経路および／または二次保護経路（例えば、経路をサポートしている特定のＷＤＭ光路）の使用がネットワークパフォーマンス全体を改善するような形で適用されるように、いくつかの保護共有機構のうちの１つまたは複数を利用する。これらの保護容量共有機構のそれぞれは、特定の形で保護リソースの共有を実現する。
【００３１】
様々な実施形態は、需要（需要フロー）およびその保護レベルに関するすべての考えられる障害シナリオを考慮するとき、共有され得る保護容量（および共有され得ない保護容量）を識別することによって、ネットワークによって必要とされる保護容量を決定する。このようにして、ネットワーク事業者は、ノード分離経路保護を使用して、マルチサービスネットワーク内で複数の障害に対する保護を提供するために、別々にまたは組み合わせて、様々な保護容量共有機構を適用することを選択することができる。
【００３２】
一実施形態は、階層構造の点からネットワークを画定する。例えば、１つの階層構造は、ノードによって終了された、保証された帯域幅（ＧＢ）トラフィックの量に従って、ノードを分割する。この実施形態では、第１の階層は、比較的大量のＧＢトラフィックを終了しているノードを含み、第２の階層は、中間量のＧＢトラフィックを終了しているノードを含み、第３の階層は、比較的小さな量のＧＢトラフィックを終了しているノードを含む、等々である。保証された帯域幅（ＧＢ）トラフィック、インターネットプロトコル（ＩＰ）ポイントツーポイント需要フロー、マルチ波長サービスポイントツーポイント需要フローなどの波長サービス（ＷＳ）、サブレートＩＰポイントツーポイント需要フローに対するベストエフォートなど、相対的なトラフィック等級またはトラフィック優先順位に基づく階層を含めて、その他の階層構造が本発明者によって想到される。一般に、階層は、優先順位レベル、トラフィックレベルなどの点から画定される。
【００３３】
保護共有機構は、公称共有、保護解放、層別（ｓｔｒａｔｉｆｉｅｄ）共有、非層別共有、動作再使用（ｗｏｒｋｉｎｇ  ｒｅｕｓｅ）、および／またはフェイルオーバ順序（ＦＯＯ）を含み得る。様々な実施形態による保護共有方法内に含める目的で、１つまたは複数の保護共有機構が選択され得る。この選択は、カスタマ基準、管理基準、および／またはサービス基準に従って行われる。これらの保護共有機構は、以下のように画定される：
（１）公称共有。画定された保護階層内の保護等級の降格により保護容量を共有することであり、障害は、その階層内の需要だけに影響を及ぼす（階層内の降格）。すなわち、特定の需要フローをサポートしているリソースの障害に応答して、同じ保護等級内の需要フローをサポートしている保護容量だけが影響を受ける（例えば、同じ保護等級内のその他の需要に関する保護経路の減少／降格）。
【００３４】
（２）保護解放、すなわち保護要件解放は、１つもしくは複数のより高い保護階層に関連する需要に対する使用または割振りのために、１つの階層内の未使用の保護容量を解放することである。保護解放は、結果として、より高い階層に関して不十分な保護を引き起こす保護損失（階層間の降格）をもたらす、ネットワーク全体の障害の発生の後に実施される。すなわち、より高い保護等級内の需要フローをサポートしているリソースの障害に応答して、より低い保護等級内の需要フローをサポートしている保護容量が影響を受ける（例えば、より低い保護等級内のその他の需要に関する保護経路の減少／降格）。したがって、より高い保護等級またはより高い保護階層に関する保護容量は、可能な限り長く維持される。
【００３５】
（３）層別化、すなわち層別共有は、単一の保護階層に限定された保護容量共有である（すなわち、保護容量の階層間共有は存在しない）。層別共有は、個々の階層に対する保護容量のデディケーション（ｄｅｄｉｃａｔｉｏｎ）を含む。公称共有は、層別共有パラダイムまたは非層別共有パラダイムを使用して実施され得る。
【００３６】
（４）非層別共有は、複数の保護階層間の保護容量共有（すなわち、保護容量の階層間共有）である。非層別方式では、公称共有は、層別の場合に発生する保護容量共有、ならびに発生し得る任意の階層間共有を伴う。保護解放は、非層別共有方式においてだけ用いられることが可能である点に留意されたい。
【００３７】
（５）動作再使用は、１つの需要に関する、故障した動作経路の帯域幅が、その他の需要の回復のために利用可能にされる場合である。すなわち、現在の動作経路（元の主経路または任意のアクティブ化されたバックアップ経路）の保護容量は、保護容量の回復のために、その他の需要によって再使用するために解放される。動作再使用は、層別保護共有方式または非層別保護共有方式において、かつ単一の階層の場合または多階層の場合に適用されることが可能である。動作再使用の２つの特別な事例が存在する。すなわち、（故障した動作経路が元の主経路である）主再使用と、（故障した動作経路が、障害によって影響を受けた需要によって現在使用されているバックアップ経路である）バックアップ再使用である。バックアップ再使用は、ｋ＞１の状態で、ｋ個の保護された需要に対してだけ適用される。再使用のために、主でない帯域幅だけが解放されるため、バックアップ再使用は即時の復帰を妨げない。
【００３８】
（６）フェイルオーバ順序（ＦＯＯ）。複数の保護された需要の場合、これは、それぞれの障害が発生するにつれて、その需要を回復するために複数のバックアップがアクティブ化される順序である。フェイルオーバ順序は、静的であってよく、または動的であってもよい。静的な場合、ＦＯＯは、すべての障害シナリオに関して事前に割り当てられ、事前に決定される。動的な場合、ＦＯＯは、ネットワークの動作の間に、元の（静的）順序から修正されることが可能である。
【００３９】
上記の保護共有機構は、より低い保護レベルへの降格など、保護レベルの変更を想到する。上で述べたように、本明細書において、２つのタイプの降格、すなわち、階層内の降格および階層間の降格が考慮されるべきである。複数の保護階層が存在するとき、層別に基づく容量共有は、オプションで考慮されることになる。
【００４０】
動作再使用は、障害によって影響を受けた需要が、回復のためにその他の需要による再使用のために利用可能である場合、オプションで考慮される。動作再使用を適用するための１つの考慮事項は、復帰が用いられるべきか否かである。需要の復帰は、その動作経路に対する修正が完了すると、障害の前に（１つまたは複数の）そのバックアップ経路（のうちの１つ）に関して動作しているサービスを（１つまたは複数の）その動作経路（のうちの１つ）に回復している。ネットワーク復帰は、すべての影響を受けた需要が復帰されているときである。理解できるように、ある種の需要が復帰することが可能な２つ以上の動作経路、またはバックアップ経路に関するすべての需要が復帰するとは限らない２つ以上の動作経路が存在し得るため、複数の保護環境では、いくつかの程度のネットワーク復帰が存在し得る。１つの特別な事例は、完全なネットワーク復帰、すなわち、それぞれの保護された需要の元の主経路へのネットワーク復帰である。
【００４１】
完全なネットワーク復帰を考慮するとき、動作再使用の２つの特別な事例が存在する。影響を受けた動作経路が元の主経路であるとき、これを主再使用（スタブの解放）と呼ぶ。主再使用は、復帰を妨げる場合がある（修正が完了次第に、正確には、とは言え、主な帯域幅を利用している、回復された需要がその元の主に復帰する場合、ネットワークは元の状態に戻ることが可能である、すなわち、ネットワークの復帰された状態は、その障害前の状態に「戻され」なければならない）。バックアップ再使用は、回復のために、その他の需要によって再使用するために、障害によって影響を受けた需要の現在の動作経路である任意の（元の）バックアップ経路の容量を解放することである。バックアップ再使用は、ｋ＞１の状態で、ｋ個の保護された需要にだけ適用される。主でない帯域だけが再使用を目指して解放されるため、バックアップ再使用は即時の復帰を妨げない。
【００４２】
複数の障害に対する保護において、追加の考慮事項は、複数のバックアップがアクティブ化される順序である。複数の保護された需要の場合、フェイルオーバ順序（ＦＯＯ）は、複数の障害が発生したとき、（影響を受けていない）バックアップが需要を回復するために使用される順序である。このフェイルオーバ順序は、静的であってよく、または動的であってもよい。静的な場合、ＦＯＯは、すべての障害シナリオに関して、事前に割り当てられ、事前に決定される。動的な場合、ＦＯＯは、特定の障害シナリオにおいて、元の（静的）順序から修正されることが可能である。
【００４３】
たいていの場合、これらの共有戦略は、容量共有方式全体を生み出すために、様々な形で構成されることが可能である。組み合わされる特定の保護共有機構および保護共有戦略は、事業者の選択、管理要件、サービス要件、および／または意図されたネットワークに関するパフォーマンス目標に依存することになる。
様々な機構の適用に関する考慮事項
たいていの場合、これらの共有戦略は、容量共有方式全体を生み出すために、様々な形で構成されることが可能である。どの戦略がその方式に組み込まれることになるかは、事業者の選択、および意図されたネットワークに関するパフォーマンス目標に依存することになる。例えば、静的な場合、バックアップ経路が利用可能であるかどうか、または最善であるかどうかを決定する必要がないため、簡素化された動作およびプロトコルにより、静的ＦＯＯは、動的ＦＯＯよりもより速い回復を導く可能性が高いことになる。しかし、最悪の場合、動的順序付けはデフォルトの最適な静的順序であり得るため、動的ＦＯＯは、一般に、静的ＦＯＯよりもより容量効率的であり得る。
【００４４】
復帰の背後にある論理的根拠は、例えば、場合によっては、よりよい遅延特性によって、先の動作経路（例えば、元の主経路）は好ましい場合があるということ、または先の動作経路は、そこから新しい成長が計画および理解される、ネットワークの「基本」状態を表す場合があるということである。その場合、バックアップ再使用だけが用いられるべきである。しかし、例えば、復帰同期による制御プレーンの複雑さなど、復帰方式を実装する複雑さが存在する場合がある。復帰が適用されないとき、共有容量効率を改善するために、完全な動作再使用が利用され得る。
【００４５】
もう１つの考慮事項は、層別方式を用いるか、または非層別方式を用いるかである。非層別の方式は、一般に、単に機会を共有する際に、より少なく制約されているという理由で、より大きな容量効率を提供することになる。しかし、層別方式は、非層別方式と比べて、操作が容易な可能性がある。例えば、経路および共有容量が決定された後の層別方式に対する１つの操作手法は、それぞれの階層をより低い階層の上に置くことであろう。要するに、それぞれの階層は、その独自の専用帯域幅内のその独自の保護サブネットワークである。操作の容易さは、プロトコルおよび制御がすべての階層に対処しなければならないことに対して、プロトコルおよび制御が１つの階層に充てられることから生じる。層別方式の操作の複雑さが削減されることは、その増大した容量要件に関するコストを埋め合わせることができる。
【００４６】
本発明の一実施形態の実装形態
前述の構想および共有方法は、それらの構想に基づいて共有機会を識別して、ネットワークトポロジ、保護等級内の需要のセット、ならびにその主経路およびバックアップ経路を考慮して、容量条件を削減するためのシステムの形で実装される。この実装形態は、ネットワーク計画および設計システムの一部として、もしくはネットワークプロビジョニング枠組みの一部としてオフラインで、またはオンラインプロビジョニングシステムの一部としてオンラインで用いられることが可能である。
【００４７】
以下の説明は、ｋ＝３の保護等級、およびせいぜい１つのノード障害を伴う、最高で３つまでの障害のすべての考えられる障害シナリオに関する例示的な実施形態に関する。また、静的フェイルオーバ順序付けが仮定される。
【００４８】
図３Ａおよび３Ｂは、せいぜい１つのノードが故障する、リンク障害およびノード障害のシナリオに関して最高で３つまでのレベルの保護を示す、本発明の一実施形態による容量共有決定方法の流れ図を示す。図３Ａおよび３Ｂの容量共有決定方法３００は、反復方法論３００Ａに関する準備と、反復決定方法論３００Ｂとを含むとして示される。
【００４９】
反復方法論３００Ａに関する準備は、２つのタイプの入力情報を利用する。第１の入力情報３０１は、ノードおよびリンクの形をとるネットワークトポロジを指定する。第２の入力情報３０２は、Ｄ個の光路需要に関して（ノードホップの点から）経路を指定する。３つのタイプの光路需要が存在する：すなわち、ｋ個の保護された需要は、ｋ＝１、２、および３の場合、（ｋ＋１）個の分離経路を有する。それぞれの光路は、１つの波長の帯域幅、すなわちλを有すると仮定される。加えて、それぞれの需要に関して、変数ａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅは、保護等級ｋ（例えば、１、２、３など）に等しく設定される。
【００５０】
ステップ３０１においてトポロジ情報を受信して、ステップ３０２において経路情報を受信するとすぐ、ステップ３０３において、主リンク容量ベクトルおよびバックアップリンク容量ベクトルの初期化が実行される。
【００５１】
オプションのステップ３０４において、主経路順序およびバックアップ経路順序を決定するために、前処理の発見的方法（ｈｅｕｒｉｓｔｉｃ）が起動される。例示的な前処理の発見的方法は、図３Ａおよび３Ｂに関して以下でより詳細に説明される。ステップ３０３および３０４の順序は反転され得る点に留意されたい。前処理の発見的方法は、光路需要に関する経路フェイルオーバ順序（すなわち、複数の障害がネットワーク内で発生するとき、光路に関連する経路が試みられる順序）を決定するために使用される。発見的方法の実行の終わりに、それぞれの光路は、自らを割り充てられた主経路および順序付けられたバックアップ経路と関連付けられていることになる。
【００５２】
前処理の発見的方法が起動されない場合（すなわち、ステップ３０４が省かれる場合）、経路のフェイルオーバ順序は、入力情報によって提供されたデフォルトのその順序になる。一実施形態では、入力バックアップ順序は、経路長に関係し、したがって、最短の経路が主経路になると見なされる。その他の変更形態は当業者に知られるであろう。
【００５３】
バックアップ順序が確立されると、ステップ３０５において、主リンク容量Ｃｐが主経路から決定され、この場合、Ｃｐは、その成分がネットワーク内のそれぞれのリンクの波長内の主容量であるベクトルである。以下において、容量は、その入力がネットワークリンクに対応するベクトルによって表される。様々なベクトルに関して実行される、本明細書で説明されるすべての動作は、ベクトル操作を含む。
【００５４】
バックアップリンク容量Ｃは、反復決定方法論３００Ｂ（すなわち、ステップ３１０−３７５）を使用して、反復的に決定される。詳細には、ステップ３１０で述べられるように、４つのタイプの順序付けられた３種類の障害が考慮される。すなわち、リンク−リンク−リンク（Ｌ−Ｌ−Ｌ）、リンク−リンク−ノード（Ｌ−Ｌ−Ｎ）、リンク−ノード−リンク（Ｌ−Ｎ−Ｌ）、およびノード−リンク−リンク（Ｎ−Ｌ−Ｌ）である。ステップ３１５−３２０において示されるように、それぞれのタイプの障害に関して、すべての考えられる障害シナリオが反復的に処理される。例えば、Ｌ−Ｌ−Ｌの場合、３つの順次リンク障害のすべての組合せが考慮される。それぞれの反復（障害の組合せ）に関して、独立したバックアップ容量Ｃｂが計算される。３種類の障害シナリオは互いに独立しているため、それぞれの反復の終わりに、容量全体Ｃは、Ｃｂを用いて、成分の点で最大Ｃを取得することによって更新される。すなわち、Ｃｉ＝ｍａｘ｛Ｃｉ，Ｃｂｉ｝を設定する。
【００５５】
それぞれの反復の始まりに、ステップ３２５において、実行容量はＣｂ＝０に初期化される。それぞれの反復は、３つの要素が（例示的に）順次に故障することを必要とする。本来の仮定は、ある障害の処理は、競争条件が考慮される必要がないように、次の障害の発生に先立って完了されるということである。
【００５６】
ステップ３３０において、第１の要素が故障し、ステップ３３５において、Ｐｒｏｃｅｓｓ＿Ｆａｉｌｕｒｅルーチンを使用して、この障害から回復するために必要とされる容量Ｃｆが計算される。例示的な処理障害ルーチンは、図５に関して、以下でより詳細に説明される。実行容量は、次いで、Ｃｂ＝Ｃｂ＋Ｃｆを使用して更新される。
【００５７】
ステップ３４０において、第２の障害が考慮されるべきか否かについて決定が下される。詳細には、同じ要素は再度故障しないことになる。加えて、その要素がすでに故障状態にある場合、第２の要素の障害は考慮されないことになる。例えば、第１の要素の障害がノードに対応する場合、すべての付随するリンクはすでに故障状態にあることになる。第２の要素がこれまでに故障している場合、または故障状態にある場合、この方法はステップ３５５に進む。第２の要素がまだ故障状態にない場合、第２の要素は、ステップ３４５において故障し、方法３００は、Ｐｒｏｃｅｓｓ＿Ｆａｉｌｕｒｅルーチンを使用して、この障害から回復するために必要とされる要素Ｃｆが計算され、Ｃｂ＝Ｃｂ＋Ｃｆを使用して、実行容量が更新されるステップ３５０に進む。
【００５８】
ステップ３５５において、第３の障害が考慮されるべきか否かについて決定が下される（上の第２の障害考慮事項を参照されたい）。第３の要素がこれまで故障している場合、または故障状態にある場合、この方法はステップ３７０に進む。第３の要素がまだ故障状態にない場合、第３の要素は、ステップ３６０において故障し、方法３００は、Ｐｒｏｃｅｓｓ＿Ｆａｉｌｕｒｅルーチンを使用して、この障害から回復するために必要とされる容量Ｃｆが計算され、Ｃｂ＝Ｃｂ＋Ｃｆを使用して、実行容量が更新されるステップ３６５に進む。
【００５９】
３つの障害が処理された後で、次いで、ステップ３７０において、Ｃｂを用いて、成分の点で最大Ｃを取得することによって、バックアップ容量全体が更新され、Ｃ＝ｃｍａｘ（Ｃ，Ｃｂ）であり（すなわち、Ｃｉ＝ｍａｘ｛Ｃｉ，Ｃｂｉ｝を設定し）、式中、Ｃｂは処理された３種類の障害シナリオに関して必要とされるバックアップ容量を表す。３種類の障害シナリオは互いから独立している点に留意されたい。方法３００は、次いで、次の３種類の障害の処理を開始するために、ステップ３２０に進む。しかし、すべての４つの順序付けられた３種類の障害シナリオがステップ３２０−３７０を通じて反復されている場合、ステップ３７５において、方法３００は、必要とされるバックアップ容量全体Ｃ、主容量Ｃｐ、および総必要容量Ｃｐ＋Ｃを報告する（すなわち、メモリ内に格納して、数量または解決法としてプロビジョニングシステムに返すなど）。これは、需要セットの完全なプロビジョニングとなる、需要の経路に関するフェイルオーバ順序の利用可能性とは別である。
【００６０】
図４は、図３Ａおよび３Ｂの容量共有決定方法で使用するのに適した前処理方法の流れ図を示す。詳細には、図３Ａおよび３Ｂは、図３Ａの方法３００のステップ３０４を実施する際に使用するのに適した前処理方法、すなわち前処理の発見的方法を示す。
【００６１】
図４の前処理の発見的方法は、光路に関する主経路順序およびバックアップ経路順序を決定する。この方法は、それぞれの光路を観察して、仮定的容量を用いて、その画定された経路のすべてをネットワークに追加することによってこれを行う。ネットワーク内でより小さな最大リンク容量を生み出す光路がこれに先立って追加され、この発見的方法はその順序を決定する。
【００６２】
ステップ４０５において、実行容量は、仮定的ネットワークに関して、Ｃｒ＝０として初期化される。
【００６３】
ステップ４１０において、第１の経路、または次の類似経路ｄが処理のために選択され、この場合、ｋ個の保護されたｄ∈Ｄであり、ｋ＋１個の経路が画定される。すなわち、ｋ個の保護されたそれぞれの光路ｄ∈Ｄに関して、ｋ＋１個の経路が画定される。発見的方法４００は、それらをネットワークに個々に追加して、仮定的な更新された容量Ｃ’を生み出すことによって、（ステップ４１５において、当初、１に等しく設定された最上の経路変数ｐを通して）これらのｋ＋１個の経路のそれぞれを検査する（ステップ４２０−４３５）。
【００６４】
更新されたリンク容量のそれぞれのセットに関して（ステップ’２０）、最大リンク容量ｍａｘ｛Ｃ’｝＝ｍａｘｉ｛Ｃ’ｉ｝が決定される（ステップ４２５）。詳細には、最小ｍａｘ｛Ｃ’｝を生成する経路は、主経路になるとして指定され、次の最小容量は、第１のバックアップ経路になるとして指定される、等々である。ある関係が存在する場合、タイブレーカ（ｔｉｅ−ｂｒｅａｋｅｒ）は最低の総容量ｓｕｍ｛Ｃ’｝＝ΣｉＣ’ｉである。２個の経路が同じｍａｘ｛Ｃ’｝を生成する場合、より小さなｍａｘ｛Ｃ’｝を生成する経路は、その他の経路の前に順序付けられる。この手順は、光路ｄに関するすべてのｋ＋１個の経路を順序付け、Ｃ’は、この時、ｄのｋ＋１個の経路のすべての追加された容量を含む。光路ｄに関する主経路順序およびバックアップ経路順序が決定されると、仮定的ネットワークに関する実行容量は、Ｃｒ＝Ｃｒ＋Ｃ’を使用して更新され（ステップ４３５）、発見的方法は、次の光路に進む（ステップ４４０、４４５）。
【００６５】
これにより、ステップ４２０−４３５は、発見的方法の終わり（ステップ４５０）に、すべての光路が指定された主経路順序およびバックアップ経路順序を有し、Ｃｒが破棄されるまで、光路ｐのそれぞれに関して繰り返される。
【００６６】
図５は、図３Ａおよび３Ｂの容量共有決定方法において使用するのに適した障害処理方法の流れ図を示す。詳細には、図５は、図３Ｂの方法３００のステップ３３５、３５０、および／または３６５を実施する際に使用するのに適した、プロセス障害方法またはプロセス障害の発見的方法を示す。
【００６７】
Ｐｒｏｃｅｓｓ＿Ｆａｉｌｕｒｅ機能は、セットＤ内のすべての光路ｄを検査して、その光路が障害によって影響を受けるかどうかを決定し、そうである場合、その光路の状態を変更して、必要とされる容量を決定することによって、所与の要素の障害を処理する。バックアップ経路は事前に画定されているにもかかわらず、バックアップ容量は、障害が光路をバックアップ経路に切り替えさせるまで、使用されることが考慮されない点に留意されたい。
【００６８】
ステップ５０５において、要素の障害から回復するために必要とされる容量は、Ｃｆ＝０として初期化される。次いで、残りの反復処理ステップ（ステップ５１０−５６０）が、それぞれの光路ｄ∈Ｄに関して実行される。
【００６９】
ステップ５１０において、第１の光路または次の光路ｄが選択され、ステップ５１５において、その選択された光路ｄが（例えば、これまでの要素の障害から）すでに故障状態にあるかどうかについて決定が下される。その選択された光路ｄがすでに故障状態にある場合、方法５００は、次の光路ｄが処理のために選択されるステップ５１０に戻る。
【００７０】
ステップ５１７において、オプションの保護解放機構が動作可能にされる場合、ｄは保護等級ｋであるため、当初ｋである光路ｄに関するａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタは、１だけ減じられる（すなわち、ネットワーク内の任意の障害は、それぞれの動作光路を降格させる）。保護解放機構が動作可能にされない場合、光路ｄのａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタは、別のｋ個の保護された光路が、この要素の障害によって影響を受けると決定された場合だけ、１だけ減じられる（すなわち、ｋ個の保護された等級内の障害だけがｋ個の保護された光路を降格させる）。
【００７１】
代替の実施形態では、より高い保護等級に優先的な処理が与えられる。したがって、１個の保護された光路に関するａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタは、それ自体が、３個の保護された光路のａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタの前に減じられることになる、２個の保護された光路のａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタの前に減じられることになる、等々である。この実施形態は、非常に保護された光路に関して支払っているカスタマが、その他のカスタマよりも障害から回復する可能性が高いことを確実にすることを追求する。
【００７２】
代替の実施形態では、より低い保護等級に優先的な処理が与えられる。したがって、３個の保護された光路に関するａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタは、それ自体が１個の保護された光路のａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタの前に減じられることになる、２個の保護された光路のａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタの前に減じられることになる、等々である。この実施形態は、平均してすべてのカスタマが障害から回復する可能性があることを確実にすることを追求する。
【００７３】
代替の実施形態では、光路ｄに関するａｌｌｏｗｅｄ＿ｆａｉｌｕｒｅカウンタは、同じ階層内のネットワーク障害の場合だけ減じられる。詳細には、本発明の一実施形態では、それぞれの光路ｄは、それぞれのサービス階層と関連付けられる。サービス階層は、サービスタイプ、地理的領域、サービスプロバイダなどの点から画定され得る。この実施形態は、特定の階層内の障害が、主として、その階層内のその他のカスタマに影響を及ぼすことになることを確実にすることを追求する。例えば、特定のサービスタイプに関連する障害、および／もしくは特定の地理的領域内の障害、ならびに／または特定のサービスプロバイダに関連する障害は、そのサービスタイプ内、その地理的領域内、かつ／またはそのサービスプロバイダ内に制限される可能性が高いことになる。
【００７４】
ステップ５２０において、ｄの現在の経路、すなわち、その第ｐ番目の経路がこの要素の障害によって影響を受けるかどうかについて決定が下される。影響が存在しない場合、方法５００は、次の光路ｄが処理のために選択されるステップ５１０に戻る（すなわち、この光路に関して何の措置も講じられない）。ｄがこの障害による影響を受ける場合、いくつかの事例が考慮される。
【００７５】
ステップ５２５において、オプションのバックアップ再使用機構が動作可能にされ、光路ｄはその元の主経路（ｐ＞１）上にない場合、または光路ｄは（ｐ＝１）であるが、オプションの主再使用機構が動作可能にされる場合、影響を受けた経路からの容量は、ステップ５３０において容量プールに解放される。
【００７６】
したがって、ｄが故障した場合、またはその要素の障害の結果として、そのバックアップ経路に切り替えることによって回復した場合、障害に先立って使用された容量は、バックアップ再使用オプションまたは主再使用オプションが選択された場合、その他の光路の回復によって使用されるために解放される。主再使用がオプションとして選択されない場合、主経路に関する将来の修正は、結果として、光路ｄをその主経路に復帰させることになることが仮定されるため、容量は主経路から解放され得ない点に留意されたい。オプションとして、主再使用またはバックアップ再使用が選択された場合、容量は、主経路を含めて、任意の経路状態から解放される。したがって、任意の障害の処理の間、回復に関して使用するために利用可能な容量が解放され得る。この解放された容量は、いかなる追加の容量要件も課せられないことになる。
【００７７】
代替の実施形態では、主リンクおよびバックアップリンクは両方とも、ｋ個の保護された光路の第ｋ番目の障害の場合に解放される。別の実施形態では、主リンク予約は、故障した光路に関して維持される。さらに別の実施形態では、主リンク予約および１つのバックアップリンク予約は、故障した光路に関して維持される。
【００７８】
ステップ５３５において、ｄがそのバックアップ経路のすべてを有するかどうか、またはネットワーク全体の障害の数が、そこからｄが回復される資格を有する障害の数を超えたかどうかについて決定が下される。これらのいずれかの場合、ｄは回復可能でなく、故障状態に置かれ（ステップ５４０）、この方法は、次の光路ｄが処理のために選択されるステップ５１０に進む。そうでない場合、ステップ５５０において、ｄは、その後続のバックアップ経路に切り替えることによって回復される。後続の経路は、ＦＯＯによって指定された順序で次に機能しているバックアップ経路である点に留意されたい。
【００７９】
やはりステップ５５０において、その後続のバックアップ経路に切り替えることによってｄが回復されるとき、まず、いずれかの解放された容量が使用され得るかどうかを検査して、次いで、ｄの新しいバックアップ経路の全域で任意の必要な容量をリンクに追加することによって、必要とされる新しい容量Ｃｐ＋１が計算される。次いで、ステップ５６０において、次いで、Ｃｆ＝Ｃｆ＋Ｃｐ＋１を使用して、必要とされる容量全体が更新される。Ｄ内の別の光路ｄが選択のために利用可能である場合、方法５００は、次の光路ｄが処理のために選択されるステップ５１０に進む。
【００８０】
Ｄ内のすべての光路ｄの処理が完了すると、ステップ５７０において、所与の要素の障害から回復するために必要とされる容量全体Ｃｆが報告される（すなわち、メモリ内に格納され、数量または解決法としてプロビジョニングシステムに戻されるなど）。
【００８１】
上述の発明は、３種類の障害という文脈において提示されている。複数の保護された光需要に保護共有を提供するための本発明の方法論に従って、より多い障害の組合せまたはより少ない障害の組合せが処理され得る点が当業者によって理解され、かつ本発明の教示によって知らされるであろう。
【００８２】
主題の発明の一実施形態による装置は、ネットワーク管理システム（ＮＭＳ）または要素管理システム（ＥＭＳ）の一部として動作しているコンピュータを含み得る。この装置は、１つの特定のネットワーク要素または複数の要素と関連付けられることが可能である。本明細書で説明された機能性は、装置の一例またはその複数の例によって完全に実現されることが可能である。一般に、ネットワーク内のノードもしくはネットワーク要素のいずれかを伴う任意のコンピューティングデバイスまたはこれらのいずれも伴わない任意のコンピューティングデバイスが、本明細書で説明された方法を実装するために用いられることが可能である。したがって、様々な実施形態において、本明細書で用いられた処理方法論は、メッシュネットワークに関連するネットワーク管理システムまたは要素管理システムという文脈において実行される。様々な方法論に従って下された決定は、ネットワークもしくは要素マネージャに関連するデジタルメモリ内またはデジタルデータ記憶デバイス内に格納される。これらの様々な実施形態は、ネットワーク要素内、ネットワーク管理システム内、または要素管理システム内のコンピュータもしくはその他の処理システムを経由して実装され得る。
【００８３】
本発明の教示を組み込んだ様々な実施形態が本明細書において詳細に示され、説明されているが、当業者は、これらの教示をさらに組み込む多くのその他の様々な実施形態を容易に考案することが可能である。
【図１】
2011518517.tif 000003
【図２】
2011518517.tif 000004
【図３Ａ】
2011518517.tif 000005
【図３Ｂ】
2011518517.tif 000006
【図４】
2011518517.tif 000007
【図５】
2011518517.tif 000008
【国際調査報告】
2011518517.tif 000009
2011518517.tif 000010