(57)【特許請求の範囲】
【請求項１】
複数のタスクがそれぞれ複数のリソースを利用できる通信網上で、あらかじめ定義されたリソース状態変化イベントの各々に対応する複数のリソース管理プロセスを備え、
各リソース管理プロセスは、自プロセスが対応するリソース状態変化イベントに対する任意のタスクの保護要求を受け取ると、少なくとも状態変化イベントに影響されるリソースを利用する救済対象タスクのリストを含む自ら維持するデータベースを参照し、当該リソースを利用する全ての保護要求されたタスクが前記リソース状態変化イベントに対し保護可能なように、他のリソース管理プロセスが既に選択したリソースを含む予備リソースを当該タスクに対し割り当てる割当手段と、
前記割り当てられた予備リソースの情報を１つ以上の救済実行プロセスに通知する通知手段と、
備え、
前記各リソース管理プロセスは、他プロセスからリリース要求を受けると、リリースの結果全予備予約帯域が減少する場合には、まずその減少分に対し状態をリリース予定として広告し、一定時間後に実際にリリースすることを特徴とする分散リソース管理システム。
【請求項２】
請求項１に記載の分散リソース管理システムにおいて、
前記通知手段は、対応するリソース状態変化イベントとタスクの組み合わせに対して救済実行プロセスを決定し、当該タスクが当該リソース状態変化イベント発生時に利用すべき予備リソースの情報を当該救済実行プロセスに通知することを特徴とする分散リソース管理システム。
【請求項３】
請求項１又は２に記載の分散リソース管理システムにおいて、
前記救済実行プロセスは、対応する予備リソースの情報を通知されたタスクの状態変化または該通知の送信元であるリソース管理プロセスが対応するリソース状態変化イベントの発生を検出すると、当該タスクの救済処理を起動することを特徴とする分散リソース管理システム。
【請求項４】
請求項１に記載の分散リソース管理システムにおいて、
前記予備リソースの予約のシグナリングは、予備リソース決定以降所定時間内の任意のタイミングで完了させることを特徴とする分散リソース管理システム。
【請求項５】
請求項１乃至４の何れか一項に記載の分散リソース管理システムにおいて、
前記予備リソースとして選択可能なリソースの状態情報を異なるリソース管理プロセス間で共有する情報共有手段を有し、
前記各リソース管理プロセスは、前記リソース状態の更新を前記リソース状態共有手段により受けると、自プロセスが保持するデータのみを用いてさらに予備リソース選択の最適化を行うことを特徴とする分散リソース管理システム。
【請求項６】
請求項１乃至５の何れか一項に記載の分散リソース管理システムにおいて、
前記各リソース管理プロセスは、タスク起動シグナリングメッセージを受信した時点で予備リソースの決定及び予約シグナリングを行い、前記割り当てられた予備リソースの情報を次のリソース管理プロセスに転送し、これを受信した下流のリソース管理プロセスは、受信した予備リソースの情報をリソース状態データベースに反映させた上で予備リソースの選択を行うことを特徴とする分散リソース管理システム。
【請求項７】
請求項１乃至６の何れか一項に記載の分散リソース管理システムにおいて、
前記各リソース管理プロセスは、保護要求したタスクに予備リソースを割り当てる際、同じタスクに対する予備リソースとして他のリソース管理プロセスが既に割り当てたリソースを優先的に割り当てることを特徴とする分散リソース管理システム。
【請求項８】
請求項１乃至７の何れか一項に記載の分散リソース管理システムにおいて、
保護要求された一部のタスクに対しては、割り当てられた予備リソースの予約を救済処理の起動以前には行わないことを特徴とする分散リソース管理システム。
【請求項９】
複数のタスクがそれぞれ複数のリソースを利用できる通信網上で、あらかじめ定義されたリソース状態変化イベントの各々に対応する複数のリソース管理プロセスを用いた分散リソース管理方法であって、
各リソース管理プロセスは、
自プロセスが対応するリソース状態変化イベントに対する任意のタスクの保護要求を受け取ると、少なくとも状態変化イベントに影響されるリソースを利用する救済対象タスクのリストを含む自ら維持するデータベースを参照し、当該リソースを利用する全ての保護要求されたタスクが前記リソース状態変化イベントに対し保護可能なように、他のリソース管理プロセスが既に選択したリソースを含む予備リソース群を当該タスクに対し割り当て、
前記割り当てた予備リソースの情報を１つ以上の救済実行プロセスに通知し、
他プロセスからリリース要求を受けると、リリースの結果全予備予約帯域が減少する場合には、まずその減少分に対し状態をリリース予定として広告し、一定時間後に実際にリリースすることを特徴とする分散リソース管理方法。
【請求項１０】
コンピュータを、請求項９に記載のリソース管理プロセスとして機能させることを特徴とする分散リソース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
複数のタスクがそれぞれ複数のリソースを利用できる通信網上におけるリソース管理プロセスの技術に関する。
【背景技術】
【０００２】
通信網上のリソースに障害が生じた場合、そのリソースを利用しているタスクにあらかじめ専用の予備リソースが割り当てられており、かつ障害の検出手段と予備リソースへの切り替え手段が用意されていれば自動的に救済可能である。
【０００３】
しかしながら、全てのタスクに対して専用の予備リソースを割り当てるには、現用リソースと同等量以上の予備用リソースを用意する必要があり、リソースコストが高くなる問題がある。この問題を緩和するには、複数のタスクで予備リソースを共有して、必要なリソースの総量を抑制することが有効である。
【０００４】
予備リソースを複数のタスクで共有した場合、それらのタスクが同時に障害を被ると両方は救済できない。このために生じる、各タスクに専用予備リソースを用意した場合に比べた救済確率の低下を防ぐには、同時に影響を受ける可能性が高いタスク同士による予備リソースの共有を避けることが有効である。
【０００５】
そのような予備リソース割り当て方法は、特に障害対応の社会的・経済的影響が大きい基幹系通信インフラ設計の分野で活発に検討されており、中でも同時に障害が生じる可能性が高い通信リソースをグループ化したShared Risk Link Group (SRLG)に基づく予備経路設定技術が近年注目されている。SRLGとは、単一の障害イベントに対し同時に利用不能となる複数のリソースのグループを指す。
【０００６】
異なるタスクを救済する予備リソースは、それぞれのタスクが同じSRLGに属するリソースを現用リソースとして利用していない限りは、単一障害に際して救済用リソースの競合を避けることが出来る。ただしこのような条件下で全体最適な予備リソースの割り当てを行う問題の複雑度はNP完全であることが非特許文献１に示されている。
【０００７】
したがってリソース利用計画を計算する際には、可能な組み合わせを限定したり、小規模な問題に分解できるよう階層化したりして、現実的な計算時間で結果を出す手法が非特許文献２により提案されている。
【０００８】
以上は問題の対象となる全てのSRLGに関する利用タスクのリストを知り得た場合のリソース割り当て最適化問題を、単一のプロセスが計算する集中的解法に関する公知例である。
【非特許文献１】S. Yuan and J. P. Jue, ”Dynamic Lightpath Protection in WDM Mesh Networks under Risk-Disjoint Constraints,” in Proceedings of IEEE Globecom 2004, pp. 1770-1774 (2004).
【非特許文献２】H. Matsuura, N. Morita, T. Murakami, K. Takami, “Disjoint SRLG Routing for GMPLS Networks by Hierarchically Distributed PCE,” IEICE Trans. Commun., Vol. E90-B, No.1, pp.51-61 (2007).
【非特許文献３】E. Bouillet and J.-F. Labourdette, “Distributed Computation of Shared Backup Path in Mesh Optical Networks Using Probabilistic Methods,” IEEE/ACM Transactions on Networking, Vol.12, No.5, pp.920-930 (2004).
【非特許文献４】Z.-Li Tang and X.-M. Li, “A Mixed Shared and Multi Paths Protection Scheme with SRLG Constraints,” in Proceedings of 8thACIS Int’l Conf. on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, pp.60-65 (2007).
【非特許文献５】” RSVP-TE: Extensions to RSVP for LSP Tunnels,” RFC3209.
【非特許文献６】” Signaling Extension for the End-to-End Restoration with SRLG ,” internet draft, draft-choi-ccamp-e2e-restoration-srlg-01.txt
【非特許文献７】”Generalized Multi-Protocol Label Switching (GMPLS)  Recovery Functional Specification,” RFC4426.
【非特許文献８】” Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration),” RFC4428.
【非特許文献９】“Traffic Engineering (TE) Extensions to OSPF Version 2,” RFC3630.
【特許文献１】特開2007-129782号公報
【特許文献２】U.S. Patent 7,289,450
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、経路決定機能を１つの計算プロセスに集約するのは網管理機能の脆弱性をもたらす。これを避けるためには、例えば各タスクの管理プロセスが個別に予備リソースを決定するような分散型の予備経路設定方式が望ましい。非特許文献３には、タスクが通信パスであり、タスク管理プロセスが通信パスの始点ノードである場合の分散型の共有予備経路設定方式が提案されている。
【００１０】
しかしながら、始点ノードが単一障害に対する救済を保証できる予備パスを設定するためには、検索対象となる全てのリソース（文献ではリンクのみを扱っている）の各々から、各SRLGの救済用に割り当てられた帯域の情報を保有している必要がある。この始点ノードが保持すべき情報量は網全体のリソース数の２乗のオーダーとなり、大規模網においては情報交換による帯域や処理能力の圧迫が問題となる。
【００１１】
以上いずれの例においても、現用通信パスが経由するいかなるSRLGの障害に対しても同一の救済パスを提供するため、それらのSRLGのいずれにも属さないリソースのみを、予備リソースとして選択している。
【００１２】
しかしながら、現用通信パスが経由する各SRLGについて個別に予備リソースを選択すれば、より高効率なリソース割り当てが可能である。非特許文献４には、予備リソース設定を行うノードが、複数の救済パスの組み合わせで全てのSRLGの障害を救済するように予備リソースを選択する方法が提案されている。
【００１３】
しかしながら、この例においてもリソース選択を行うノードはリソース数の２乗のオーダーの情報を保持する必要があり、大規模網において分散実装するには情報交換による帯域や処理能力の圧迫が問題となる。
【００１４】
以上ではあるタスクの、他のタスクと共有可能な予備リソースとして、現用リソースと属するSRLGが重複しないリソースを選択する際の問題について指摘したが、選択したリソースを利用開始するかまたは予備用として予約するためには、さらに選択したリソースへのシグナリング処理が必要になる。リソース取得のためのシグナリング方式としては、例えばRSVP-TE（非特許文献５）などが知られており、通信開始前に行う現用リソースの予約に適用可能である。
【００１５】
一方予備リソースの予約に際しては、その予約により、対象リソースが同一のSRLGの救済に要する帯域が、予備リソースとして利用可能な容量を超過しないことが、予約許可の条件となる。この判断のためには、救済対象タスクがいかなる現用リソースを取得しているかの情報が必要である。この情報は、非特許文献３、４に示した予備リソース選択を分散実装する場合には、リソースの選択を行ったノードが保持しているはずであるので、これを予備リソース予約要求メッセージに含めればよいことになる。このような拡張を含むリソース予約シグナリングプロトコルは、非特許文献６、特許文献１で提案されている。
【００１６】
しかしいずれの例においても、単一障害に対する救済を保障するタスクの利用開始までには、現用と予備のリソースのシグナリングが全て終了する必要があるため、要求発信から利用開始までの遅延が大きくなる問題がある。また先に指摘した、リソース状態に関する情報交換の消費帯域の問題とは別に、要求が集中した際にはシグナリングトラフィックが通信や処理能力を圧迫してしまう問題がある。
【００１７】
他のタスクと共有可能な予備リソースは、障害救済の実行のために利用するには、たとえ予約されていても、さらに複数ある救済対象タスクのいずれが利用するかを確定させるためのシグナリング処理が必要である。このとき、非特許文献４のように複数の救済パスが定義されている場合、救済処理を起動するノードは、いずれの救済パスを用いて救済するかを決定するには、障害が生じたSRLGを同定しなければならない。救済パスを１つに特定せず、複数の救済パスに同時にRSVP-TEなどを適用すると、リソース競合のために救済時間が長くなるとともに、シグナリングメッセージに帯域が多く消費される問題がある。これを避けるには、特許文献２にあるような、複数パスを含むスコープを持ったシグナリング方式を用いればよい。
【００１８】
しかしながら、この場合は救済処理を起動するノードが通信パスに対し一意に決まっている必要があり（始点ノードまたは終点ノードなど）、ホップ数の多い通信パスなどでSRLGの障害を検出したノードが救済処理起動ノードから遠い場合には、障害を救済処理起動ノードに通知するための時間および帯域の消費が顕著となる問題がある。
【００１９】
一方、同じ通信タスクの高信頼化でも、通信パスというタスク単位ではなく、異なる複数の通信パスが多重化された伝送スパン単位で救済を行う方式も検討されている（非特許文献７）。ただし対象となるスパン内のリソースを用いる全てのタスクに対して同一の救済リンクを割り当てるため、タスクによっては非効率なリソース選択となり、網全体でのリソース活用効率は、非特許文献１〜非特許文献４の例に比べ低くなる問題がある（非特許文献８）。
【００２０】
本発明は、以上の問題等に鑑みてなされたものであり、シグナリングトラフィック及び処理負荷を軽減し、また時間・空間的な負荷集中を回避することができ、また、リソース選択及び救済処理を局所化することで、大規模網へのタスク救済保障の導入を容易にすることが可能な分散リソース管理システム、分散リソース管理方法、及び分散リソース管理プログラムを提供することを課題とする。
【課題を解決するための手段】
【００２１】
上記課題を解決するため、請求項１に記載の発明は、複数のタスクがそれぞれ複数のリソースを利用できる通信網上で、あらかじめ定義されたリソース状態変化イベントの各々に対応する複数のリソース管理プロセスを備え、各リソース管理プロセスは、自プロセスが対応するリソース状態変化イベントに対する任意のタスクの保護要求を受け取ると、少なくとも状態変化イベントに影響されるリソースを利用する救済対象タスクのリストを含む自ら維持するデータベースを参照し、当該リソースを利用する全ての保護要求されたタスクが前記リソース状態変化イベントに対し保護可能なように、他のリソース管理プロセスが既に選択したリソースを含む予備リソースを当該タスクに対し割り当てる割当手段と、前記割り当てられた予備リソースの情報を１つ以上の救済実行プロセスに通知する通知手段と、備え、前記各リソース管理プロセスは、他プロセスからリリース要求を受けると、リリースの結果全予備予約帯域が減少する場合には、まずその減少分に対し状態をリリース予定として広告し、一定時間後に実際にリリースすることを特徴とする。例えば、現用リソースのシグナリング過程において、またはシグナリング終了後に、想定される現用リソースの状態変化イベントに対応するリソース管理プロセスの各々が自らの維持するデータベースを参照して予備リソースを選択する。なお、このデータベースは該状態変化イベントに影響されるリソースを利用する救済対象タスクのリストを含む。また、予備リソース選択の際、該状態変化イベントに影響されるリソースを利用するタスクの間では競合が生じないことを条件とし、他のリソース管理プロセスが対応する状態変化イベントに対する予備リソースとは共有を許可する。
【００２２】
この発明によれば、予備リソースの選択を、タスクである通信パスの始点や終点ノードにあるようなタスク管理プロセスが行うのではなく、当該タスクが用いるリソースの状態変化イベントに対応する複数のリソース管理プロセスが各々独立に行うことにより、シグナリングトラフィック及び処理負荷を軽減し、また時間・空間的な負荷集中を回避することができる。また、リソース選択及び救済処理を局所化することで、大規模網へのタスク救済保障の導入を容易にすることができる。
【００２３】
請求項２に記載の発明は、請求項１に記載の分散リソース管理システムにおいて、前記通知手段は、対応するリソース状態変化イベントとタスクの組み合わせに対して救済実行プロセスを決定し、当該タスクが当該リソース状態変化イベント発生時に利用すべき予備リソースの情報を当該救済実行プロセスに通知することを特徴とする。
【００２４】
請求項３に記載の発明は、請求項１又は２に記載の分散リソース管理システムにおいて、前記救済実行プロセスは、対応する予備リソースの情報を通知されたタスクの状態変化または該通知の送信元であるリソース管理プロセスが対応するリソース状態変化イベントの発生を検出すると、当該タスクの救済処理を起動することを特徴とする。
【００２６】
請求項４に記載の発明は、請求項１に記載の分散リソース管理システムにおいて、前記予備リソースの予約のシグナリングは、予備リソース決定以降所定時間内の任意のタイミングで完了させることを特徴とする。
【００２７】
請求項５に記載の発明は、請求項１乃至４の何れか一項に記載の分散リソース管理システムにおいて、前記予備リソースとして選択可能なリソースの状態情報を異なるリソース管理プロセス間で共有する情報共有手段を有し、前記各リソース管理プロセスは、前記リソース状態の更新を前記リソース状態共有手段により受けると、自プロセスが保持するデータのみを用いてさらに予備リソース選択の最適化を行うことを特徴とする。
【００２８】
請求項６に記載の発明は、請求項１乃至５の何れか一項に記載の分散リソース管理システムにおいて、前記各リソース管理プロセスは、タスク起動シグナリングメッセージを受信した時点で予備リソースの決定及び予約シグナリングを行い、前記割り当てられた予備リソースの情報を次のリソース管理プロセスに転送し、これを受信した下流のリソース管理プロセスは、受信した予備リソースの情報をリソース状態データベースに反映させた上で予備リソースの選択を行うことを特徴とする。
【００２９】
請求項７に記載の発明は、請求項１乃至６の何れか一項に記載の分散リソース管理システムにおいて、前記各リソース管理プロセスは、保護要求したタスクに予備リソースを割り当てる際、同じタスクに対する予備リソースとして他のリソース管理プロセスが既に割り当てたリソースを優先的に割り当てることを特徴とする。
【００３０】
請求項８に記載の発明は、請求項１乃至７の何れか一項に記載の分散リソース管理システムにおいて、保護要求された一部のタスクに対しては、割り当てられた予備リソースの予約を救済処理の起動以前には行わないことを特徴とする。
【００３１】
請求項９に記載の発明は、複数のタスクがそれぞれ複数のリソースを利用できる通信網上で、あらかじめ定義されたリソース状態変化イベントの各々に対応する複数のリソース管理プロセスを用いた分散リソース管理方法であって、各リソース管理プロセスは、自プロセスが対応するリソース状態変化イベントに対する任意のタスクの保護要求を受け取ると、少なくとも状態変化イベントに影響されるリソースを利用する救済対象タスクのリストを含む自ら維持するデータベースを参照し、当該リソースを利用する全ての保護要求されたタスクが前記リソース状態変化イベントに対し保護可能なように、他のリソース管理プロセスが既に選択したリソースを含む予備リソース群を当該タスクに対し割り当て、前記割り当てた予備リソースの情報を１つ以上の救済実行プロセスに通知し、他プロセスからリリース要求を受けると、リリースの結果全予備予約帯域が減少する場合には、まずその減少分に対し状態をリリース予定として広告し、一定時間後に実際にリリースすることを特徴とする。
【００３２】
請求項１０に記載の分散リソース管理プログラムの発明は、コンピュータを、請求項９に記載のリソース管理プロセスとして機能させることを特徴とする。
【発明の効果】
【００３３】
本発明によれば、予備リソースの選択を、タスクである通信パスの始点や終点ノードにあるようなタスク管理プロセスが行うのではなく、当該タスクが用いるリソースの状態変化イベントに対応する複数のリソース管理プロセスが各々独立に行うことにより、シグナリングトラフィック及び処理負荷を軽減し、また時間・空間的な負荷集中を回避することができる。また、リソース選択及び救済処理を局所化することで、大規模網へのタスク救済保障の導入を容易にすることができる。
【発明を実施するための最良の形態】
【００３４】
以下、図面を参照して本発明の最良の実施形態について詳細に説明する。
（第１の実施例）
先ず、本発明の第１の実施例における分散リソース管理システムについて説明する。
【００３５】
図１に、本発明の第１の実施例における分散リソース管理システムの構成例を示す。
【００３６】
図中、100-A, 100-B, … 100-Gは局舎やデータセンタなどの拠点を表し、101-1, 101-2, … 101-8はノード装置（以下、「ノード」という）を表す。
【００３７】
各ノードは、交換部200, リソース管理プロセス201, 通信タスク管理プロセス202を含み、各通信タスクは始点から終点ノードまでの転送帯域が確保される限り実行可能であるとする。また、複数のタスクがそれぞれ複数のリソースを利用できる、図１に示すような通信網上で、あらかじめ定義されたリソース状態変化イベントの各々に、１つ以上のリソース管理プロセス201が対応するようになっている。
【００３８】
そして、各リソース管理プロセス201は、自プロセスが対応するリソース状態変化イベントに対する任意のタスクの保護要求を受け取ると、当該リソースを利用する全ての保護要求されたタスクが、リソース状態変化イベントに対し保護可能なように、他のリソース管理ノードが既に選択したリソースを含む予備リソースを当該タスクに対し割り当てる（選択する）割当手段と、割り当てられた予備リソースの情報（予備リソースの選択結果）を１つ以上の救済実行プロセスに通知する通知手段を有している。この通知手段は、例えば、対応するリソース状態変化イベントとタスクの組み合わせに対して救済実行プロセスを決定し、当該タスクが当該リソース状態変化イベント発生時に利用すべき予備リソースの情報を当該救済実行プロセスに通知するようになっている。また、各リソース管理プロセス201は、リソース状態の更新を伝送路300により受けると、自プロセスが保持するデータのみを用いてさらに予備プロセス選択の最適化を行う。
【００３９】
また、タスクが利用するノード間の転送帯域は、交換部200に接続された伝送路300により提供されるものとする。
【００４０】
また、通信タスク管理プロセス202は、救済実行プロセスの動作も兼ねられるものとする。かかる救済実行プロセスは、例えば、タスクとリソース状態変化イベントの対として定義される影響事象ごとに定められ、対応する予備リソースの情報を通知されたタスクの状態変化または該通知の送信元であるリソース管理プロセス201が対応するリソース状態変化イベントの発生を検出すると、当該タスクの救済処理を起動するようになっている。つまり、上記リソース管理プロセス201は、予備リソースの選択結果を通信タスク管理プロセス202に通知し、救済実行プロセスは、自プロセスが対応する影響事象に含まれるリソース状態変化またはタスクの状態変化を検出したら、当該タスクの救済処理を起動する。
【００４１】
なお、リソース管理プロセス201と通信タスク管理プロセス202は同じハードウェア上に別個のソフトウェア（分散リソース管理プログラム等）のとして実装してもよく、同じソフトウェア上に両プロセスの機能を共存させても良い。
【００４２】
また、伝送路300は双方向伝送路であり、便宜上ノード100-xと100-yを結ぶ伝送路300-zにおいては、「x < y」の場合、100-xから100-yへ向かう伝送路を300-zの下り伝送路、yからxへ向かう伝送路を300-zの上り伝送路とする。
【００４３】
また、各ノードのリソース管理プロセス202は、例えば拡張OSPF-TEのような（非特許文献９参照）リンクステート型ルーティングプロトコルを通して伝送路300-1, 300-2, … 300-10の帯域利用状況を全ノードで共有しているものとする。ただし各伝送路について共有する情報は伝送路容量、現用リソースとして利用中の帯域、予備リソースとして予約された帯域を含むものとする。なお、リンクステート型ルーティングプロトコルは、予備リソースとして選択可能なリソースの状態情報を異なるリソース管理プロセス201間で共有する情報共有手段の一例である。
【００４４】
本実施例では、障害として仮定する状態変化イベントは天災や攻撃などによる拠点障害とする。例えば拠点100-Dの障害に際しては、ノード101-4, 101-5とも利用不能となると仮定する。ところで本発明では状態変化イベントに対して一意にリソース管理プロセスを対応させる必要があるので、拠点100-Dの障害には201-4か201-5のいずれのリソース管理プロセスが対応するかあらかじめ決めなければならない。ここでは、拠点100-Dの障害にはリソース管理プロセス201-5を対応させることとする。この場合、ノード101-4を経由するが101-5は経由しないタスクを拠点100-Dの障害に対し救済するには、当該タスク実行のためのシグナリングはリソース管理プロセス201-4のみならずリソース管理プロセス201-5に対しても行う必要がある。なお201-4と201-5のデータベース内容を常に同期できる場合は、拠点100-Dの障害に両方が対応しても良い。図１の他の拠点の障害に対しては、各拠点に唯一のリソース管理プロセス201がそれぞれ対応する。 
【００４５】
以下、第１の実施例の動作について説明する。
【００４６】
いま図１の通信網において、ノード101-3から101-7までの、帯域保証通信のタスク開始要求がタスク管理プロセス202-3から発信されるものとする。タスク管理プロセス202-3は、現用リソースとしてノード101-3, 101-4, 101-5, 101-6, 101-7およびそれらを直接接続する伝送路からなる経路を指定しているとする。このとき、タスク開始要求のシグナリングメッセージは図２に示したような経路で転送される。
【００４７】
シグナリングメッセージを受信したリソース管理プロセスは、自プロセスが対応するリソース状態変化イベント（拠点障害）が影響するリソースを用いる救済対象タスクのリストと、リンクステート型ルーティングプロトコルにより更新されるネットワーク全体のリンク帯域利用および予約状況の情報に基づき、シグナリングされたタスクの予備リソースとして選択する。ただし拠点100-Dの拠点障害に対応するリソース管理プロセスは202-5であるため、シグナリング系路上にあってもリソース管理プロセス202-4は予備リソースの選択は行わない（現用リソースの確保は行う）。
【００４８】
以下では予備リソース選択を行うリソース管理プロセスの動作の例として、リソース管理プロセス201-5によるリソース選択の動作について説明する。
【００４９】
現用リソースに関しては、シグナリングメッセージにタスク管理プロセス202-3が選択したリソースが明記されており、リソース管理プロセス201-5に関してはノード202-5の処理負荷及び伝送路300-5, 300-6のそれぞれ下り伝送路の帯域であるとする。したがってリソース管理プロセス201-5はこれらのリソースが利用可能な状態であることを確認する。予備リソースに関しては、リソース管理プロセス201-5が能動的にリソースの選択を以下の手順により行い、この選択処理が完了後にシグナリングメッセージは下流ノードのリソース管理プロセスである201-6に転送される。
【００５０】
図３および図４には、図２で示したタスク開始要求シグナリングメッセージを受信する前のリソース管理プロセス201-5が保持していたデータベースの内容の一部が示される。
【００５１】
図３はリンクステート型ルーティングプロトコルを通して得た予備リソースとして利用可能なリソースのリストであり、簡単のため伝送路のみがリストされている（伝送路が予約できればそれらの伝送路間の転送を行うノードの処理能力は必ず利用可能と仮定している）。図３で、「現用利用中帯域」は、各リソースの全タスクによる現用リソースとしての帯域利用量の総計である。同図中、「全予備予約帯域」は全タスクによる予備リソースとしての帯域予約量の総計、「自プロセスによる予備予約帯域」はそのうち自プロセスにより予約された帯域の総計を表す。
【００５２】
図４は、自プロセスが管理するリソースを利用中のタスクのリストである。図３、図４から、ノード101-3から101-6までの帯域保証通信のタスク（タスクID=3-1）が、伝送路300-2と300-3を予備リソースとして予約していることがわかる。また、ノード101-3から101-6までの帯域保証通信タスク（タスクID=3-2）も存在するが、こちらは予備リソースを割り当てられていない。予備リソースを割り当てない理由としては、例えば該当するタスク管理プロセスが障害救済を要求していないことなどが考えられる。
【００５３】
いま、リソース管理プロセス201-5は新たなタスク（タスクID=3-3）の開始要求シグナリングメッセージを図２に示したような経路により受信し、シグナリング発信元のタスク管理プロセス202-3は当該タスクに“４”の帯域を要求しているものとする。
【００５４】
このタスクが拠点100-Dの障害に対して救済可能であるためには、例えば伝送路300-3, 300-2の帯域をさらに“４”だけ予備リソースとして予約し、障害時にこれらのリソースの利用により、ノード101-3から101-1を経由して101-6に至る経路を確保できるようにすればよい。これを経路1とする。また、伝送路300-3, 300-1, 300-8の帯域を４だけ予約して、ノード101-3から101-1, 101-2を経由して101-7に至る経路を用いても同様にタスクは救済可能である。この経路を経路2とする。リソース管理プロセス201-5はこのように可能な経路の全てについて、当該経路に含まれるリソースを予約した場合のコストの増加分を比較し、最低コスト増の経路を構成する予備リソースを選択する。例えばコスト関数として 
（式1）経路コスト＝（伝送路容量/空き容量）の、経路を構成する全伝送路に関する和 
を採用して各経路についてコスト増加を計算すると、経路2を選択した場合が最低コスト増となる。ここで空き容量は次の式で表される。 
【００５５】
（式2）空き容量  ＝  伝送路容量  ―  現用利用中帯域  −  全予備予約帯域
また、全予備予約帯域がr, 自プロセスによる予備予約帯域がwであるリソースSについて、新たに帯域をw’だけ予備リソースとして予約した場合、予約後の自プロセスによる予備予約帯域Wおよび全予備予約帯域Rは次の式で表されると仮定している。
【００５６】
（式３）W = w + w’ 
（式４）R = Max(W, r) 
したがって全予備予約帯域が、新たな予約により増加した自プロセスによる予備予約帯域よりも大きい場合には、この予約によるコストの増分は０となる。これは、自プロセスが対応する障害に対する予備リソースと、他のリソース管理プロセスが対応する障害に対する予備リソースは共用可能であることを反映している。つまりこれらの予備リソースは同時に利用されることがないため、最悪でもいずれか大きい方の帯域が障害時に利用されるのみであるので、コスト関数にも自プロセスによる予備予約帯域が他プロセスによる予備予約帯域を超えない限り空き容量には影響しない。したがって上記コスト関数により選択した経路によれば、いかなる単一拠点障害に際しても全タスクを救済可能である（空き容量が0であればコスト無限大となり、そのような経路は利用不能とする）。なおコスト関数としては単一障害に際し救済対象リソース間の競合を生じないことが保証される限りは任意のものが選択可能である。例えば上記に加え伝送路の信頼性などのパラメータを含めても良い。また、経路分岐可能なタスクに関しては、単一の経路で救済するのではなく、複数の経路に救済帯域を分散しても良い。 
【００５７】
リソース管理プロセス201-5は上記計算を受け、経路２に含まれるリソースのリストからなる選択結果と、救済実行プロセスの選択結果をタスク開始要求シグナリングメッセージに挿入して下流のリソース管理プロセスに転送する。救済実行プロセスは拠点障害時に救済を実行するプロセスであるので、拠点100-Dの外にある必要がある。例えば、シグナリング帯域の節約と、障害を検出しやすい位置にあることを主眼に選択すると、現用リソースのシグナリング系路上にあるタスク管理プロセス202-6または202-7などが可能である。または、シグナリング発信元のタスク管理プロセスがシグナリングメッセージ内で指定している場合や、システムのデフォルトで始点ノードや終点ノードのタスク管理プロセスなどと決められている場合は、それらに従う。本実施例では、タスクID=3-3と拠点ID=100-Dで定義される影響事象の救済実行プロセスとして、タスク管理プロセス202-6を選択するものとする。 
【００５８】
次に、図２に示される経路によりリソース管理プロセス201-5から転送されたタスク開始要求シグナリングメッセージを受信したリソース管理プロセス201-6の動作について説明する。
【００５９】
まず、（タスク3-3, 拠点100-D）で定義される影響事象を同じノード内のタスク管理プロセス202-5の救済実行対象として登録する。また、リソース管理プロセス201-5が行ったのと同様な手続きにより、拠点100-Eの障害に際しタスク3-3を救済する予備リソースの選択を行う。
【００６０】
リソース管理プロセス201-6が保持するデータベースの一部を図５、図６に示す。リソース管理プロセス201-5, 201-6ともに同じリンクステート型ルーティングプロトコルによりリソース情報を共有しているので、図３と図４の差異は自プロセスによる予備予約帯域のみとなる。また、図５、図６から、タスクID=1−1のタスクが伝送路300-1, 300-8の帯域を予備リソースとして予約していることがわかる。リソース管理プロセス201-6は、リソース管理プロセス201-5と同様に、（式１）〜（式４）を用いてタスク3-3に対して可能な全ての救済経路のコストを計算し、ノード101-4から101-8を経由して101-7に至る経路（伝送路300-9と300-10を予約）が最低コスト増との結果を得、伝送路300-9と300-10がタスクID=3-3および拠点ID=100-Eで定義される影響事象の予備リソースとして選択される。また、同影響事象の救済実行ノードとして例えばタスク管理プロセス202-7を選択する。この結果を、図２に示される次のタスク開始要求シグナリング転送先であるタスク管理プロセス202-7に転送する。
【００６１】
以上で説明した往路シグナリングが成功すると、復路のシグナリングによりタスク3-3の情報がリソース管理プロセス201-5, 201-6の各々にそれぞれ図７、図８のように登録される。
【００６２】
ここまでの本実施例の動作についてまとめると、単一障害に対する救済保障が要求されるタスクのリソース確保シグナリングに応じ（つまり、タスクの保護要求を受け取ると）、各リソース管理プロセスは、リソースを利用する全ての保護要求されたタスクがリソース状態変化イベントに対し保護可能なように、自らのデータベースに格納されたリソース状態リストおよびタスクリストに基づき予備リソースの選択を行い、結果を救済実行ノードに通知する。
【００６３】
一方、非特許文献１−４に示される公知例ではいずれもタスクごとまたは網全体に関して特定のノードが予備経路の選択を行うことが仮定されている。その場合、本発明においては各リソース管理プロセスが別個に管理する、各拠点を経由するタスクのリスト（図４、図６）またはそれらによるリソース選択への制限情報を、経路選択を行うノードに集約する必要がある。このために生じるノード間のタスク情報交換の通信を、本発明を用いることで省略できることがわかる。
【００６４】
以上の説明において、予備リソースの予約のためのシグナリングについては言及しなかったが、これには何通りかの実装が可能である。一つには、予備リソースを選択したリソース管理プロセスまたは各影響事象の救済実行プロセスが行う方法が考えられる。この方法では、例えばタスク3-3と拠点100-Dの影響事象については、対応するリソース管理プロセス201-5または救済実行プロセス202-6が、選択された予備リソース300-3, 300-1, 300-8の予約のためにリソース管理プロセス201-3, 201-1, 201-2, 201-7にシグナリングする。または、図２のタスク開始要求シグナリングにより、現用リソース確保と予備リソースの選択結果を得たタスク管理プロセス202-7、またはその結果を返送された202-3がシグナリングを行っても良い。この場合、拠点100-Dおよび100-E双方の影響事象の予備リソース300-3, 300-1, 300-8, 300-9, 300-10の予約のために201-3, 201-1, 201-2, 201-7, 201-8へのシグナリングが必要である。いずれにしても、救済実行ノードは予備リソース予約シグナリング結果を得てから予備リソースが実際に利用可能であると判断する。シグナリング結果の救済実行ノードへの通知手段については、予備リソース予約シグナリング発信プロセスが救済実行プロセス自身である場合は自明であるが、タスク管理プロセスである場合には別途通知が必要である。ただしタスク管理プロセスが救済実行プロセスを兼ねる場合はこの限りではない。予備リソース予約シグナリング発信プロセスがリソース管理プロセスである場合については後述する。
【００６５】
タスク管理プロセスが予備リソース予約シグナリングを行う場合、予備リソース予約シグナリングの通信量は、タスク管理プロセスから、当該タスクの現用リソースに影響するリソース状態変化イベントに対応するリソース管理プロセスが選択する予備リソースの和集合に対するシグナリング通信量の総和で表される。図２におけるようなタスク開始要求シグナリングの経路に沿って順次リソース管理プロセスが予備値ソースを選択する場合、上流のリソース管理プロセスの予備リソース選択結果を下流のリソース管理プロセスの予備リソース選択に反映させることで、予備リソースの和集合自体を小さく出来、したがってシグナリングコストの節約が可能である。具体的には、各リソース管理プロセスの予備リソース選択を、自プロセスより上流のリソース管理プロセスが選択した予備リソースの和集合に含まれないリソースの数を最小にするよう行えばよい。このような選択は、上流のリソース管理プロセスが選択した予備リソースの和集合に含まれないリソースのコストを高く設定するように（式１）のコスト関数を変更することで可能である。 
【００６６】
（式２）〜（式４）により計算したコスト増分が０であるリソース、つまり自プロセスによる予備リソース予約によるコスト増加がないリソースについては、リンクステート型ルーティングプロトコルによるリソース情報の更新時点ではリソースは確保されていると考えられる。ただし当該リソースを予約した他のリソース管理プロセスによるリリースにより、自プロセスが選択した予備リソースが確保されない状況となることを防ぐためにはやはりシグナリングが必要である。例えば、各リソース管理プロセスは他プロセスからリリース要求を受けると、（式４）に従い全予備予約帯域が減少する場合には、まずその減少分に対し状態を「リリース予定」などとして広告し、一定時間T後に実際にリリースするなどすれば、予備リソース予約のシグナリングはリリース予定であるリソース以外についてはT内にシグナリングを完了すれば十分であることになり、必ずしも予備リソース選択後直ちに行う必要はない（予備リソースの予約のシグナリングは、予備リソース決定直後ではなく、それ以降T内の任意のタイミングで完了させる）。このようにすることでシグナリングのタイミングを分散させ、通信負荷の短時間への集中を避けることが出来る。その結果、特に予約された予備リソースが多い状況、つまり網帯域の利用率が大きく網の負荷が大きい状況において、シグナリング負荷の集中が軽減される効果が得られる。
【００６７】
予備リソースについてのシグナリング後、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたリソース状態のリストは、リソース管理プロセス201-5, 201-6の各々においてそれぞれ図９，１０のように更新される。これらの更新を受けて、各リソース管理プロセスは自プロセスが保持するデータのみを用いてさらに予備プロセス選択を最適化することができる。例えば図１０において、リソース300-9下りと300-10上りは全予備予約帯域と自プロセスによる予備予約帯域が等しいため、（式４）により、これらの自プロセスによる予備予約帯域を減らすと、全予備予約帯域も減少すると期待される。一方、（全予備予約帯域−自プロセスによる予備予約帯域）の値はリソース300-1下りと300-8下りについては、“２”であり、リソース300-3上りについては、“７”であることから、現在300-9下りと300-10上りを用いた経路（経路Aとする）でまかなっている予備帯域４のうち“２”だけを、リソース300-3上り、300-1下り、300-8下りを用いる経路（経路Bとする）に分配しても、経路Bのコストは増加しない。一方、経路Aのコストは同じまたは減少する。以上のことが、リソース管理プロセス201-6が保持している情報のみで分かるので、リソース管理プロセス201-6はコスト低減のために上記のように予備リソースの選択を変更すべきであることを判断できる。この判断の時点で救済実行プロセスに伝えるとともに新たに選択した予備リソースにシグナリング（リリース予定でないリソースに対しては一定時間T以内に行えばよい）すれば、他のリソース管理プロセスや要求元タスク管理プロセスに直接通知することなく経路変更可能である。
【００６８】
リソース管理プロセスが予備リソース予約のシグナリングを行う場合には、その結果を待ってから図２に示されるタスク開始要求シグナリングを次のリソース管理プロセスに転送しても良い。この場合、予備リソースの予約結果をシグナリングメッセージに含めれば、これを受信した下流のリソース管理プロセスはリソース状態データベースに反映させることが出来る。つまり、本実施例のリソース管理プロセス201-6がタスク3-3の予備リソースを選択する際、リンクステート型ルーティングプロトコルによる更新を待たずに図１０に示されるのと同じ情報を参照することが出来、より早期に最適なリソース選択が可能となる。 
【００６９】
以上の動作の説明ではいずれも、各タスクについて、リソース管理プロセスが選択した予備リソースを、（障害の検出などにより）実際のタスク救済処理が必要となる以前から予約する必要があることを前提としていた。一方で、リソース管理プロセスに対し予備リソースの選択およびその結果の救済実行プロセスへの伝達は要求するが、選択した予備リソースの、タスク救済処理起動前の予約は（いずれのプロセスに対しても）要求しないタスクを定義しても良い。タスク救済処理起動前の予約の要否は、例えばタスク起動シグナリングメッセージに保護要求の種別フィールドを含め、その値により識別できるようにすれば良い。この場合、予備リソースが選択されるが予約が行われないタスクについては、単一の状態変化イベントに対する救済は保証されないが、救済成功確率の高い予備経路を救済実行プロセスが保持することになる。このようなタスクには、予備リソースの予約を行うタスクよりは低く、予備リソースの選択を行わない（タスクID3-2のような）タスクよりは高い信頼性が与えられる。
（第２の実施例） 
次に、本発明の第２の実施例における分散リソース管理システムについて説明する。
【００７０】
以上の実施例における通信タスクは、始点から終点までの転送帯域が確保されれば実行可能であることを仮定している。一方本発明は、転送帯域以外のリソースの予約を要するタスクに対しても適用可能である。実例として、図１１に第２の実施例の構成例、及びシグナリングメッセージが転送される経路を示す。
【００７１】
図１１では、一部のノード101-xにデータ処理手段400-xが含まれている。本実施例での一部のタスクは、始点から終点までの間の転送帯域およびデータ処理スループットを確保することで実行可能となる。ここでデータ処理とは、例えばデータ暗号化、映像や音声データのコーデック変換などを想定している。これらの処理はデータ処理手段のスループットの消費を伴い、各データ処理手段が当該処理に提供できる合計スループットは決まっているものとする。データ処理手段のスループットの利用および予約状況は、伝送路リソースの帯域利用および予約状況と共に各ノードで共有される。図１２、図１３にそれぞれリソース管理プロセス201-5が管理するリソース状態および拠点経由タスクのデータベースの一部を、図１４、図１５にはそれぞれリソース管理プロセス201-6が管理するリソース状態および拠点経由タスクのデータベースの一部を示す。なおデータ処理はデータ暗号化やコーデック変換など、各タスクについて経路上で1回だけ行われるものを想定している。このため例えばタスク3-1では、データ処理手段400を持つ２つのノード101-4および101-5を経由しているが、このタスクに対しデータ処理を行うのは400-5の１つのみである。 
【００７２】
ここで先の実施例と同様、ノード101-3から101-7までの、単一拠点障害に対する救済が保障されたタスクID=3-3のタスクの起動要求がタスク管理プロセス202-3から発信されるものとする。このタスクも途中1回のデータ処理を必要とするものとする。シグナリング経路は図１１に示されている通りであり、現用リソースとしては伝送路300-4, 300-5, 300-6, 300-7およびデータ処理手段400-5が選択されているとする。シグナリング系路上の各リソース管理プロセスは、シグナリングメッセージを受信すると先の実施例と同様に現用リソースの確保と予備リソースの選択を行う。リソース管理プロセス201-5は、要求タスクの予備リソースとして、先の実施例におけるのと同様に伝送路300-3, 300-1, 300-8を含む経路を選択し、さらにデータ処理用の予備リソースとして400-1を選択する。 
【００７３】
一方リソース管理プロセス201-5は、先の実施例では伝送路300-9, 300-10からなる経路を選択しているが、本実施例ではこの経路を選択できない。この経路上で利用可能なデータ処理手段は400-4だけであるが、その処理容量が現在利用中のタスク3-2と、新たなシグナリング元タスク3-3が同時に利用するには足りないためである。この場合とりうる経路として、１つにはデータ処理手段は現用と同じ400-5を用い、予備伝送路として300-5上り、300-9下り、300-10上りを用いてノード101-7に至る経路が考えられる。これを経路Kとする。一方、伝送路300-3, 300-1, 300-8とデータ処理手段400-1を用いる経路も可能であり、これを経路Jとする。両者につき（式１）〜（式４）を用いてコスト増分を計算すると、経路Jの方が低コスト増分となり、こちらを構成するリソースが予備リソースとして選択される。以上のように各リソース管理プロセスで選択された予備リソースについてのシグナリング後、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたリソース状態およびタスクのリストは、リソース管理プロセス201-5においてはそれぞれ図１６、図１７のように, 201-6においてはそれぞれ図１８、図１９のように更新される。 
【００７４】
以上説明したように、上記実施例によれば、予備リソースの選択を、タスクである通信パスの始点や終点ノードにあるようなタスク管理プロセスが行うのではなく、当該タスクが用いるリソースの状態変化イベントに対応する複数のリソース管理プロセスが各々独立に行うことにより、シグナリングトラフィック及び処理負荷を軽減し、また時間・空間的な負荷集中を回避することができる。また、リソース選択及び救済処理を局所化することで、大規模網へのタスク救済保障の導入を容易にすることができる。
【００７５】
以上の実施例は、データ処理の前後で要求される帯域が異なる場合にも容易に拡張できる。これは例えばデータ処理がデータ圧縮のように、処理前後のデータレートを変更する場合に相当する。また、以上の実施例の始点ノードと終点ノードは等しくてもよい。これは例えば始点＝終点をクライアントとし、データ処理手段をサーバとした、クライアント・サーバ間通信に相当する。本発明の適用により、クライアントがサーバに要求したスループット保証タスクへの、通信経路まで含めた耐障害性の追加が低コストで可能となる。
【００７６】
さらに、本発明は始点ノードまたは終点ノードが複数有る場合にも適用可能である。例えば、任意のデータ処理プロセスにてデータ圧縮を行い、複数の終点ノードに圧縮後のデータをマルチキャストするようなタスクも本発明により高効率に保護可能である。
【図面の簡単な説明】
【００７７】
【図１】本発明の第１の実施例における分散リソース管理システムの構成例を示す図である。
【図２】第１の実施例において、シグナリングメッセージが転送される経路を示す図である。
【図３】リソース管理プロセス201-5が保持するデータベースの内容の一部を示す図である。
【図４】リソース管理プロセス201-5が保持するデータベースの内容の一部を示す図である。
【図５】リソース管理プロセス201-6が保持するデータベースの内容の一部を示す図である。
【図６】リソース管理プロセス201-6が保持するデータベースの内容の一部を示す図である。
【図７】リソース管理プロセス201-5に登録されるタスク3-3の情報の一例を示す図である。
【図８】リソース管理プロセス201-6に登録されるタスク3-3の情報の一例を示す図である。
【図９】リソース管理プロセス201-5において、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたリソース状態のリストの一例である。
【図１０】リソース管理プロセス201-6において、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたリソース状態のリストの一例である。
【図１１】本発明の第２の実施例における分散リソース管理システムの構成例、及びシグナリングメッセージが転送される経路を示す図である。
【図１２】リソース管理プロセス201-5が管理するリソース状態のデータベースの一部を示す図である。
【図１３】リソース管理プロセス201-5が管理する拠点経由タスクのデータベースの一部を示す図である。
【図１４】リソース管理プロセス201-6が管理するリソース状態のデータベースの一部を示す図である。
【図１５】リソース管理プロセス201-6が管理する拠点経由タスクのデータベースの一部を示す図である。
【図１６】リソース管理プロセス201-5において、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたリソース状態のリストの一例である。
【図１７】リソース管理プロセス201-5において、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたタスクのリストの一例である。
【図１８】リソース管理プロセス201-6において、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたリソース状態のリストの一例である。
【図１９】リソース管理プロセス201-6において、リンクステート型ルーティングプロトコルによりシグナリング結果が反映されたタスクのリストの一例である。
【符号の説明】
【００７８】
100-A, 100-B, … 100-G  拠点
101-1, 101-2, … 101-8  ノード  
200-1, 200-2, … 200-8  交換部
201-1, 201-2, … 201-8  リソース管理プロセス
202-1, 202-2, … 202-8  通信タスク管理プロセス
300-1, 300-2, … 300-10  伝送路
400-1, 400-4, 400-5  データ処理手段
【図１】
0005130997.tif 000002
【図２】
0005130997.tif 000003
【図３】
0005130997.tif 000004
【図４】
0005130997.tif 000005
【図５】
0005130997.tif 000006
【図６】
0005130997.tif 000007
【図７】
0005130997.tif 000008
【図８】
0005130997.tif 000009
【図９】
0005130997.tif 000010
【図１０】
0005130997.tif 000011
【図１１】
0005130997.tif 000012
【図１２】
0005130997.tif 000013
【図１３】
0005130997.tif 000014
【図１４】
0005130997.tif 000015
【図１５】
0005130997.tif 000016
【図１６】
0005130997.tif 000017
【図１７】
0005130997.tif 000018
【図１８】
0005130997.tif 000019
【図１９】
0005130997.tif 000020