JP5364183B2 - ネットワークのリソース管理装置 - Google Patents

Description

本発明は、ＩＰ（Internet Protocol）、ＭＰＬＳ（Multiprotocol Label Switching）、ＧＭＰＬＳ（Generalized Multi-protocol label switching）などのパケット交換網、ＷＤＭ（Wavelength Division Multiplexing）やＴＤＭ（Time Division Multiplexing）などを用いたパス交換網のネットワークの物理リソースを管理するリソース管理装置に関する。

近年、Ｐ２Ｐ（Peer to Peer）トラヒックの増加、または、ＹｏｕＴｕｂｅ（登録商標）などに代表されるＣＧＭ（Consumer Generated Media）の隆盛に伴い、特定の人気サイトへトラヒックが集中するようになっている。このような特定人気サイトの登場により、トラヒックパターンの急激な変化が、頻繁に発生するようになった。特に、ＹｏｕＴｕｂｅ（登録商標）の登場以来、米国から日本へ向けた国際回線のトラヒックの量の増え方は、他よりも顕著であると報告されている。今後も同様なキラーアプリケーションやキラーサービスにより、トラヒックパターンは、大きく変化すると予測される。このトラヒックパターンの急激な変化により、効率的なネットワークを構築することは、一層困難になっている。

非特許文献１には、特に複数のオーバーレイ網を収容するインフラ網に於いて、オーバーレイ網間の相互作用により、性能が低下することが報告されている。種々の新サービスが登場し、現在では想定できないトラヒックの変動が生じるような時代に備えて、ネットワークは、環境の変動に柔軟に適応するために、物理リソースを柔軟に利用することが必要である。

この問題に対処する技術として、ネットワーク仮想化技術が注目されている。ネットワーク仮想化技術とは、ネットワークの物理リソースを仮想的に分割して、その一部を割り当てることで、複数の仮想網を構成する技術である。

非特許文献２に記載のPlanetLabは、米国で開発されたアプリケーション層仮想化技術であり、ＩＰネットワーク上で展開されるオーバーレイネットワークの技術である。非特許文献２に記載のPlanetLabは、参加者が物理リソースとしてLinux（登録商標）サーバを持ち寄り、Sliverと呼ばれる複数の仮想マシンに分割し、それら仮想マシンを組み合わせてサービス網を構成する。

非特許文献２に記載のPlanetLabは、仮想化リソースがLinuxサーバであり、ソフトウェアによって仮想網を実現している。そのため、PlanetLabが提供可能な通信速度には限界がある。更に、パケットネットワークの上での仮想網であるPlanetLabは、異なる仮想網が同じパケット転送に係る物理リソースを共有するので、干渉が発生する虞がある。

このように、既存のネットワーク仮想化技術では、複数の仮想網がＩＰパケットネットワーク上で多重化される。そのため、仮想網間の相互作用により、トラヒックパターンに大きな変化が現れ、ネットワークの安定性が低下する虞がある。

非特許文献３には、複数の仮想網を収容するインフラ網において、仮想網間の相互作用を抑制しつつ、各仮想網の構成変更を許容するインフラ網リソース管理技術が記載されている。非特許文献３に記載の技術は、特定の仮想網に対して予約リソースを配分することにより、仮想網間の干渉を回避している。

W. Jiang他、"On the interaction of multiple overlay routing"、Performance Evaluation 62、10 August 2005、p.229-246 中尾彰宏、「PlanetLab : Towards Ubiquitous Networking ユビキタス社会における分散コンピューティングの可能性」,電子情報通信学会技術研究報告、電子情報通信学会、2005-10-13、NSネットワークシステム 105(357)、pp25-28 Takashi Miyamura他、"Dynamic resource allocation mechanism for managed self-organization"、Network Operations and Management Symposium (APNOMS)、21-23 Sept 2011、13th Asia-Pacific

非特許文献３に記載の技術は、同一物理網に収容される全仮想網の交流トラヒック情報を取得した上で相関を計算し、制御対象となる仮想網のグループを抽出している。これにより、非特許文献３に記載の技術は、仮想網の数が増加すると、計算負荷が増大する虞がある。さらに、非特許文献３に記載の技術は、物理リソースが競合関係にある仮想網の数が増加すると、効率的に物理リソースを割り当てることができなくなる虞がある。

そこで、本発明は、仮想網の数が増加しても、容易に各仮想網間の相互干渉を最小化することができるネットワークのリソース管理装置を提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明では、インフラ網に係るインフラ網トポロジ情報と、当該インフラ網の上に構築された各仮想網に係る仮想網トポロジ情報とに基づき、前記各仮想網に係るトラヒック需要情報を収集する情報収集部と、前記トラヒック需要情報に基づき、前記各仮想網から制御対象の仮想網を選択し、当該仮想網に基づき、前記インフラ網に係る各物理リソースから制御対象の物理リソースを選択する仮想網選択部と、前記情報収集部が収集した前記トラヒック需要情報に基づき、区分線形関数によって、選択された前記仮想網に提供する前記物理リソースを算出する予約リソース計算部と、を備えたことを特徴とするネットワークのリソース管理装置とした。

このようにすることで、仮想網の数が増加しても、容易に各仮想網間の相互干渉を最小化することができる。さらに、トラヒック需要がゼロであっても、物理リソースを予め提供しておくことができるので、当該物理リソースが新たに使用されはじめたときに備えることができる。
請求項２に記載の発明では、インフラ網に係るインフラ網トポロジ情報と、当該インフラ網の上に構築された各仮想網に係る仮想網トポロジ情報とに基づき、前記各仮想網に係るトラヒック需要情報を収集する情報収集部と、前記トラヒック需要情報に基づき、前記各仮想網から制御対象の仮想網を選択し、当該仮想網に基づき、前記インフラ網に係る各物理リソースから制御対象の物理リソースを選択する仮想網選択部と、前記情報収集部が収集した前記トラヒック需要情報に基づき、選択された前記仮想網に提供する前記物理リソースを、前記トラヒック需要情報に対して相乗的に大きくなるように算出する予約リソース計算部と、を備えたことを特徴とするネットワークのリソース管理装置とした。
このようにすることで、仮想網の数が増加しても、容易に各仮想網間の相互干渉を最小化することができる。さらに、多くの物理リソースを消費する重要な仮想網に、多くの物理リソースを予約することができる。

請求項３に記載の発明では、インフラ網に係るインフラ網トポロジ情報と、当該インフラ網の上に構築された各仮想網に係る仮想網トポロジ情報とに基づき、前記インフラ網に係る各物理リソースの前記各仮想網に係るトラヒック需要情報を収集する情報収集部と、前記トラヒック需要情報に基づき、前記各物理リソースから制御対象の物理リソースを選択し、当該物理リソースに基づき前記各仮想網から制御対象の仮想網を選択する仮想網選択部と、前記情報収集部が収集した前記トラヒック需要情報に基づき、選択された前記仮想網に提供する前記物理リソースを算出する予約リソース計算部と、を備えたことを特徴とするネットワークのリソース管理装置とした。

このようにすることで、仮想網の数が増加しても、容易に各仮想網間の相互干渉を最小化することができる。更に、仮想網の数が増加したとき、請求項１または請求項２に記載の発明よりも計算量を少なくすることができる。

請求項６に記載の発明では、前記予約リソース計算部が算出した前記物理リソースを、前記仮想網に予約配分するリソース配分部を、更に備えたことを特徴とする請求項１ないし請求項５のいずれか１項に記載のネットワークのリソース管理装置とした。

このようにすることで、算出した物理リソースを仮想網に予約配分して、仮想網を動的に再構成させることができる。

請求項７に記載の発明では、前記予約リソース計算部は、前記各仮想網に係る前記トラヒック需要情報に基づいて、予約リソースの配分量を算出し、前記物理リソースに、共有型の属性または予約型の属性のいずれかを設定する、ことを特徴とする請求項１ないし請求項６のいずれか１項に記載のネットワークのリソース管理装置とした。

このようにすることで、予約型の属性を設定することにより、仮想網の帯域を保証し、仮想網間の相互干渉を回避することができる。更に、物理リソースに共有型の属性を設定することにより、この物理リソースを仮想網間で融通し、トラヒック変動への耐性を向上し、インフラ網のリソース利用効率を向上させることができる。

請求項４に記載の発明では、前記予約リソース計算部は、区分線形関数によって、前記トラヒック需要情報から、選択された前記仮想網に提供する前記物理リソースを算出する、ことを特徴とする請求項３に記載のネットワークのリソース管理装置とした。

このようにすることで、トラヒック需要がゼロであっても、物理リソースを予め提供しておくことができるので、当該物理リソースが新たに使用されはじめたときに備えることができる。

請求項５に記載の発明では、前記予約リソース計算部は、前記トラヒック需要情報に対して、選択された前記仮想網に提供する前記物理リソースが相乗的に大きくなるように算出する、ことを特徴とする請求項３に記載のネットワークのリソース管理装置とした。

このようにすることで、多くの物理リソースを消費する重要な仮想網に、多くの物理リソースを予約することができる。

本発明によれば、仮想網の数が増加しても、容易に各仮想網間の相互干渉を最小化することができるネットワークのリソース管理装置を提供することが可能となる。

第１の実施形態に於けるインフラ網および仮想網を示す概略の構成図である。 第１の実施形態に於けるインフラ網および仮想網の詳細を示す図である。 第１の実施形態に於ける物理リソースの属性を示す図である。 第１の実施形態に於けるリソース管理装置を示す概略の構成図である。 第１の実施形態に於ける配分量計算関数の例を示す図である。 第１の実施形態に於けるリソース配分量計算処理を示すフローチャートである。 第２の実施形態に於けるリソース配分量計算処理を示すフローチャートである。

以降、本発明を実施するための形態を、各図を参照して詳細に説明する。
（第１の実施形態の構成）

図１は、第１の実施形態に於けるインフラ網および仮想網を示す概略の構成図である。
インフラ網１０は、ノード２０ａ〜２０ｄと、リンク２１−１〜２１−４とを備えている。ノード２０ａとノード２０ｂとは、リンク２１−１によって接続されている。ノード２０ｂとノード２０ｄとは、リンク２１−２によって接続されている。ノード２０ｄとノード２０ｃとは、リンク２１−３によって接続されている。ノード２０ｃとノード２０ａとは、リンク２１−４によって接続されている。
インフラ網１０は、例えば、各ノード２０ａ〜２０ｄが光ファイバで接続されているＷＤＭネットワークであり、IP over WDM（Internet Protocol over wavelength division multiplexing）をサポートしているものである。

ノード２０ａ〜２０ｄは、例えばＯＸＣ（optical cross-connect）などの光コネクト装置である。ノード２０ａ〜２０ｄは、光ファイバに於いて、データ伝送のための光通信路を自由に設定するようスイッチングできる装置である。以下、各ノード２０ａ〜２０ｄを特に区別しないときには、単にノード２０と記載する。

リンク２１−１〜２１−４は、例えば光ファイバであり、各ノード２０間を接続して光通信を可能とするものである。以下、リンク２１−１〜２１−４を特に区別しないときには、単にリンク２１と記載する。

インフラ網１０上には、ＷＤＭやＴＤＭなどのレイヤ１技術、Ｅｔｈｅｒｎｅｔ（登録商標）などのレイヤ２技術、および、パケット交換などのレイヤ３技術を組み合わせてネットワーク仮想化を行い、インフラ網１０の物理リソースを仮想的に分割したのちに組み合わせた仮想網「＃１」１１−１、仮想網「＃２」１１−２が構成されている。

仮想網「＃１」１１−１は、インフラ網１０の上に仮想的に構築されているネットワークである。仮想網「＃１」１１−１は、例えば、ＩＥＥＥ８０２．１Ｑで規定された仮想ネットワークである。仮想網「＃１」１１−１は、インフラ網１０と同様にノード２０ａ〜２０ｄを備え、インフラ網１０とは異なるパス２２を備えている。

仮想網「＃２」１１−２は、仮想網「＃１」１１−１と同様に、インフラ網１０の上に仮想的に構築されているネットワークである。仮想網「＃２」１１−２は、インフラ網１０と同様にノード２０ａ〜２０ｄを備え、インフラ網１０とは異なるパス２２を備えている。

仮想網「＃１」１１−１のパス２２は、インフラ網１０のリンク２１−１〜２１−４に、実線矢印で示されている。仮想網「＃２」１１−２のパス２２は、インフラ網１０のリンク２１−１〜２１−４に、破線矢印で示されている。以下、仮想網「＃１」１１−１、仮想網「＃２」１１−２を特に区別しないときには、単に仮想網１１と記載する。

このインフラ網１０には、リソース管理装置３０が接続されている。リソース管理装置３０は、各ノード２０ａ〜２０ｄを制御することによって、このインフラ網１０と仮想網１１とを制御する。

各仮想網１１は、運用条件により固定的に経路やトポロジを構築する場合もあれば、動的トポロジ最適化制御を行い、環境変化に適応して各仮想網１１のトポロジを変更する場合もある。動的トポロジ最適化制御により、各仮想網１１は、環境変化への適応性を向上させることができる。

複数の仮想網１１をインフラ網１０の上に実現する際に、帯域粒度の細かいパケットと広帯域の波長パスを、サービスが要求する帯域に応じて使い分ける仕組みが必要となる。このような仕組みとして、仮想網トポロジ（Virtual Network Topology：VNT）と呼ぶ概念がある。

仮想網トポロジは、インフラ網１０に於いて、ルータとそれらを相互接続するパスから構成されるパケットネットワークとみなすことができる。パスの制御をＧＭＰＬＳなどで行うことにより、動的に仮想網トポロジを再構成することができる。仮想網１１のトラヒック需要の変動や故障などの状態変化に追従して、動的に仮想網トポロジを再構成することにより、ネットワーク品質を安定化させ、リソース利用効率と耐故障性とを向上させることができる。

リソース管理装置３０は、仮想網トポロジを動的に再構成すると共に、各仮想網１１を安定的にインフラ網１０に収容するように、各仮想網１１に対して物理リソースを配分するものである。

仮想網１１間の競合の調停については、各仮想網１１のトラヒック需要や性能情報、インフラ網１０と仮想網トポロジの収容関係から、物理リソースの競合の発生を抑制するようにインフラ網１０のリソースの配分量を仮想網１１毎に設計することで実現する。

インフラ網１０の物理リソースとは、ＷＤＭ、ＴＤＭ、Ｅｔｈｅｒｎｅｔ（登録商標）などを用いたリンク２１、ルータや光クロスコネクト装置などのノード２０、ポート、プロセッサ、ストレージ、計算機などである。
本実施形態では、インフラ網１０の物理リソースとして、ＷＤＭリンクの各波長を各仮想網１１に配分する場合について説明している。

図２（ａ），（ｂ）は、第１の実施形態に於けるインフラ網および仮想網の詳細を示す図である。

図２（ａ）は、インフラ網１０および仮想網１１を流れるフレーム６０（パケット）の構造を示している。
インフラ網１０および仮想網１１を流れるフレーム６０は、ＩＥＥＥ８０２．１Ｑに準拠している。ＩＥＥＥ８０２．１Ｑは、ブリッジなどで連結されたネットワークに於いて、同一のネットワークリンクを透過的に共有する規格である。

フレーム６０は、宛先アドレス６１（Destination Address）と、送信元アドレス６２（Source Address）と、タグ６３（Tag）と、イーサタイプ６７（Ether Type）と、データ６８（Data）と、ＦＣＳ（Frame Check Sequence）６９とを有している。更に、タグ６３は、優先度６４（Priority）と、ＣＦＩ（Canonical Format Indicator）６５と、仮想網識別子６６（VID:Vertial lan ID）とを有している。
宛先アドレス６１は、このフレーム６０の宛先の機器が有しているＭＡＣ（Media Access Control）アドレスを格納している。
送信元アドレス６２は、このフレーム６０の送信元の機器が有しているＭＡＣアドレスを格納している。

タグ６３の優先度６４は、３ビットのフィールドであり、フレーム６０の優先度を格納している。優先度６４は、フレーム６０の優先度を０（最低）から７（最高）で示し、各種トラヒック（音声、動画、データなど）の優先順位付けに利用されるものである。
タグ６３のＣＦＩ６５は、１ビットのフィールドであり、フレーム６０のＭＡＣアドレスが非正規フォーマットであるか否かを示すものである。

タグ６３の仮想網識別子６６は、１２ビットのフィールドで、当該フレーム６０が属する仮想網１１の識別子を格納している。仮想網識別子６６が０の場合には、当該フレーム６０は、いずれの仮想網１１にも属していないことを意味している。本実施形態に於いて、仮想網「＃１」１１−１に流れるフレーム６０は、仮想網識別子６６に１が設定されている。仮想網「＃２」１１−２に流れるフレーム６０は、仮想網識別子６６に２が設定されている。
イーサタイプ６７は、データ６８で送信しているプロトコルタイプを格納している。
データ６８は、当該フレーム６０のペイロードである。
ＦＣＳ６９は、当該フレーム６０が壊れていないかどうかをチェックするためのものである。

図２（ｂ）は、インフラ網１０および仮想網１１のリンクとノードの詳細を示す図である。
インフラ網１０は、ノード２０ａ，２０ｂと、ＩＰルータ５０ａ，５０ｂとを備えている。ノード２０ａとノード２０ｂとは、リンク２１−１を介して接続されている。

ＩＰルータ５０ａは、ノード２０ａに接続されている。ＩＰルータ５０ｂは、ノード２０ｂに接続されている。以下、ＩＰルータ５０ａ，５０ｂを特に区別しないときには、単にＩＰルータ５０と記載する。

ＩＰルータ５０ａには、仮想網「＃１」１１−１と仮想網「＃２」１１−２とからフレーム６０（パケット）が送信される。同様に、ＩＰルータ５０ｂには、仮想網「＃１」１１−１と仮想網「＃２」１１−２とからフレーム６０（パケット）が送信される。

各ＩＰルータ５０から送信された各仮想網１１のフレーム６０は、各ノード２０とリンク２１とを介して、宛先アドレス６１によって指定された宛先の機器に中継される。
以下、このインフラ網１０の物理リソースの配分量の調節による予約リソース量の配分方法について説明する。

各仮想網１１は、インフラ網１０のリソースの一部を利用し、仮想網トポロジを構成する。インフラ網１０の物理リソースのうち、各仮想網１１が利用可能な範囲はリソース管理装置３０（図１）によって管理する。リソース管理装置３０（図１）は、インフラ網１０のトポロジ情報、各仮想網１１のトポロジ情報、パス経路の情報、トラヒック需要情報を収集し、それらの情報をもとに各仮想網１１に提供するリソース量を算出する。

本実施形態のリソース管理装置３０（図１）は、各仮想網１１が柔軟にインフラ網１０の物理リソースを利用するため、共有型（非予約型）の属性の物理リソースと、予約型の属性の物理リソースとを、各仮想網１１に提供している。

ここで物理リソースとは、仮想網１１に配分可能な単位のインフラ網１０の構成要素のことである。物理リソースは、例えば、ＷＤＭリンクに於ける各波長であり、ＴＤＭリンクに於ける各ＴＤＭスロットである。リソース管理装置３０は、これらの物理リソースに対して、共有型の属性と予約型の属性のいずれかを予め設定する。
共有型の属性の物理リソースは、複数の仮想網１１が利用可能である。予約型の属性の物理リソースは、予約された特定の仮想網１１のみが利用可能である。各仮想網１１は、利用権限を有している予約型の物理リソースと、共有型の物理リソースとを組み合わせて、仮想網トポロジを構成する。

図３（ａ），（ｂ）は、第１の実施形態に於ける物理リソースの属性を示す図である。

図３（ａ）は、リンク２１の波長＃１〜＃１０を示す図である。全ての波長＃１〜＃１０は、仮想網「＃１」１１−１と仮想網「＃２」１１−２との共有である。すなわち、波長＃１〜＃１０は、未予約であり、共有型の属性を有している。

リソース管理装置３０は、干渉が大きい場合など、どちらかの仮想網１１の品質が満足できない場合には、共有型の属性を付与した物理リソースの一部を、品質が低下した仮想網１１の予約リソースとして割り当てる。

図３（ｂ）は、リンク２１の波長＃１〜＃１０を示す図である。
波長＃１〜＃５は、仮想網「＃１」１１−１用に予約されている。すなわち、波長＃１〜＃５は、予約型の属性を有している。
波長＃６〜＃１０は、仮想網「＃１」１１−１と仮想網「＃２」１１−２との共有である。すなわち、波長＃６〜＃１０は、未予約であり、共有型の属性を有している。

ノード２０は、仮想網「＃１」１１−１のフレーム６０を、波長＃１〜＃５に優先的に流す。ノード２０は、当該波長＃１〜＃５のリンク利用率が閾値を超えた場合には、仮想網「＃１」１１−１のフレーム６０を、波長＃６〜＃１０に流す。

本実施形態のリソース管理装置３０は、各仮想網１１に独立したレイヤ１の物理リソースであるＷＤＭリンクの波長を提供し、当該仮想網１１を構築している。これにより、リソース管理装置３０は、ネットワーク仮想化技術の課題であった、仮想網１１間の物理リソースの相互干渉を回避することができる。

図４は、第１の実施形態に於けるリソース管理装置を示す概略の構成図である。
リソース管理装置３０は、記憶部３１と、処理部３５と、通信部４０とを備えている。記憶部３１は、網状態情報ＤＢ（Database）３２と、トラヒック需要情報ＤＢ３３と、仮想網パス情報ＤＢ３４とを備えている。処理部３５は、情報収集部３６と、仮想網選択部３７と、予約リソース計算部３８と、リソース配分部３９とを備えている。通信部４０は、インフラ網１０に接続されている。
記憶部３１は、例えば、フラッシュメモリやＨＤＤ（Hard Disk Drive）などであり、情報を格納するものである。
網状態情報ＤＢ３２は、インフラ網１０を構成する各リンク２１と各ノード２０の情報を格納するデータベースである。
トラヒック需要情報ＤＢ３３は、各仮想網１１で転送されるトラヒック量の情報を格納するデータベースである。
仮想網パス情報ＤＢ３４は、各仮想網１１のノード２０間に設定されるパス２２の中継経路の情報を格納するデータベースである。

処理部３５は、例えば、ＣＰＵ（Central Processing Unit）が、ＲＡＭ（Random Access Memory）にソフトウェアプログラムを読み込んで実行することによって具現化されるものである。
情報収集部３６は、定期的に各ノード２０から、各仮想網１１の交流トラヒック情報を取得して、トラヒック需要情報ＤＢ３３に蓄積するものである。

仮想網選択部３７は、予約リソースの配分制御対象とするリソース、および、配分制御対象とする仮想網１１を選択するものである。仮想網選択部３７は、各仮想網１１の状態に基づき、各仮想網１１が適切に制御されているか否かを判断し、配分制御対象とする仮想網１１を選択するものである。

予約リソース計算部３８は、ノード２０やリンク２１に配分する予約リソースの配分量を計算するものである。予約リソース計算部３８は、共有型の物理リソースを予約型の物理リソースに切り替えるなどして、仮想網１１同士の物理リソースの競合を回避するものである。
リソース配分部３９は、予約リソースの配分量を、ノード２０やリンク２１に通知することにより、物理リソースを配分するものである。
通信部４０は、インフラ網１０の各ノード２０と通信するものであり、例えば、ＮＩＣ（Network Interface Card）である。

図５（ａ）〜（ｃ）は、第１の実施形態に於ける配分量計算関数の例を示す図である。
この配分量計算関数Ｆ（ｘ）は、予約リソース計算部３８が配分量を計算するときに用いる関数である。
図５（ａ）〜（ｃ）の縦軸は、配分量計算関数Ｆ（ｘ）の値を示している。図５（ａ）〜（ｃ）の横軸は、当該仮想網１１のトラヒック需要比率ｘの値を示している。ここでトラヒック需要比率ｘとは、仮想網１１のトラヒック需要を、全ての仮想網１１のトラヒック需要の総和に対する当該仮想網１１のトラヒック需要の比率である。

図５（ａ）は、トラヒック需要比率ｘに応じて、線形に配分量を計算する例を示している。

図５（ｂ）は、トラヒック需要比率ｘに応じて、区分線形に配分量を計算する例を示している。配分量計算関数Ｆ（ｘ）は、トラヒック需要比率ｘがＣ１からＣ２（Ｃ１、Ｃ２は、０＜Ｃ１、Ｃ１＜Ｃ２、かつ、Ｃ２＜１である。）の間は一定値の配分量を計算する。配分量計算関数Ｆ（ｘ）は、Ｃ１未満の範囲、または、Ｃ２超過の範囲は、トラヒック需要比率ｘに応じて、配分量を計算する。このとき、トラヒック需要比率ｘが０であっても所定の配分量が算出されるので、トラヒック需要比率ｘが０であった物理リソースに、新たに所定のトラヒック需要が発生したときであっても、対応することができる。

図５（ｃ）は、曲線（２次関数、指数関数等）による配分量計算関数Ｆ（ｘ）を示している。図５（ｃ）の配分量計算関数Ｆ（ｘ）は、トラヒック需要比率ｘが増大すると、仮想網１１に提供する物理リソースが相乗的に大きくなるように、配分量を算出している。これにより、トラヒック需要比率ｘが大きい仮想網１１は、優先的にリソースが配分され、例えば動画ストリーミングサービスを中心とする仮想網１１に於いて、ストレスなく動画を閲覧することができるようになる。

（第１の実施形態の動作）

図６は、第１の実施形態に於けるリソース配分量計算処理を示すフローチャートである。
処理を開始すると、ステップＳ１０に於いて、リソース管理装置３０の仮想網選択部３７は、仮想網パス情報ＤＢ３４の各仮想網１１の性能状態と、トラヒック需要情報ＤＢ３３の各仮想網１１のトラヒック需要の情報とから、予約リソースの配分対象とする仮想網１１の集合を選択する。すなわち、仮想網選択部３７は、問題となりやすい仮想網１１を選択する。

ステップＳ１１に於いて、リソース管理装置３０の仮想網選択部３７は、インフラ網１０を構成し、ステップＳ１０で選択した各仮想網１１の集合が収容している物理リソースのうち、特に競合が予測され、ボトルネックとなりやすいために予約型の設定が必要となる物理リソースを選択する。

ステップＳ１２に於いて、リソース管理装置３０の予約リソース計算部３８は、選択した当該物理リソースに於ける、各仮想網１１の集合のトラヒック需要比率ｘを計算する。

ステップＳ１３に於いて、リソース管理装置３０の予約リソース計算部３８は、トラヒック需要比率ｘと配分量計算関数Ｆ（ｘ）に基づき、各仮想網１１の集合に割り当てる予約リソース量を算出する。ステップＳ１３の処理が終了すると、リソース管理装置３０の予約リソース計算部３８は、図６の処理を終了する。
以下、各ステップＳ１０〜Ｓ１４の処理を詳細に説明する。

《ステップＳ１０の処理》
ステップＳ１０の処理は、仮想網１１の選択方法の処理である。制御対象の仮想網の選択には、以下の方法がある。以下の方法のうち、１つまたは複数を組み合わせて、制御対象の仮想網１１を選択することができる。

第１の仮想網選択方法は、性能が低下している仮想網１１を選択するものである。第１の仮想網選択方法に於いて、仮想網選択部３７は、例えば、仮想網１１の最大リンク利用率（性能指標）が過去一定期間（例えば１時間など）に亘って継続的に、予め設定された閾値（例えば８０％）を超過しているか否かを判断し、当該判断条件が成立したならば当該仮想網１１を選択する。

第２の仮想網選択方法は、トラヒック需要が大きい問題を有している仮想網１１を選択する方法である。第２の仮想網選択方法に於いて、仮想網選択部３７は、例えば、仮想網１１のトラヒック需要の総和、または、特定対地間の需要の合計が、予め設定された閾値（例えば１０Ｇｂｐｓ）を超過しているか否かを判断し、当該判断条件が成立したならば当該仮想網１１を選択する。

第３の仮想網選択方法は、ボトルネックとなりやすいリソースを利用している仮想網１１を選択する方法である。第３の仮想網選択方法は、他の仮想網１１の性能を改善する上で重要である。第３の仮想網選択方法に於いて、仮想網選択部３７は、例えば、各仮想網１１の通信経路を最短経路等で収容設計した場合、一定数以上の仮想網１１が収容される物理リソースを特定し、当該物理リソースを収容している仮想網１１を選択する。

《ステップＳ１１の処理》
ステップＳ１１の処理は、各仮想網１１の集合への配分対象とする物理リソースを選択する処理である。
ステップＳ１１の処理に於いて、リソース管理装置３０の仮想網選択部３７は、各仮想網１１の集合が収容している物理リソースのうち、競合の発生している物理リソース、または競合の発生が予期される物理リソースに対して、予約型の属性を設定する。リソース管理装置３０の仮想網選択部３７は、例えば、当該物理リソースの使用割合が閾値（例えば９０％）を超えていたならば、物理リソースの競合の発生が予期されると判断する。

《ステップＳ１２の処理》
ステップＳ１２の処理は、ステップＳ１０で選択された仮想網１１の集合に対して、各トラヒック需要比率ｘを計算する処理である。
リソース管理装置３０の予約リソース計算部３８は、トラヒック需要比率ｘを、予約リソースの配分対象となる物理リソース単位で計算する。リソース管理装置３０の予約リソース計算部３８は、当該物理リソースを通過する全ての仮想網１１のトラヒック需要の総和を計算したのち、当該トラヒック需要の総和に対する当該仮想網１１のトラヒック需要比率を計算する。

《ステップＳ１３の処理》
ステップＳ１３の処理は、仮想網１１のトラヒック需要比率ｘに基づき、仮想網１１に配分する予約リソースを計算する処理である。リソース管理装置３０の予約リソース計算部３８は、計算対象となる物理リソース単位で、以下の計算式に従って配分量計算関数Ｆ（ｘ）により配分量を計算する。仮想網１１の予約リソース配分量は、以下の式１によって算出される。

配分量計算関数Ｆ（ｘ）は、前記した図５に示している。リソース管理装置３０の予約リソース計算部３８は、式１により、仮想網１１への予約リソースの配分量を計算することができる。当該物理リソースのうち、予約型の属性が設定されたもの以外は、共有型の属性が設定される。

リソース管理装置３０の予約リソース計算部３８は、ステップＳ１１の処理で選択された全物理リソースに対して、式１の計算を行う。ここで、計算対象となる仮想網１１は、ステップＳ１０の処理で選択した、制御対象の仮想網１１である。

インフラ網１０の有限な物理リソースを複数の各仮想網１１で共用する場合、仮想網１１間で物理リソースの競合が発生する虞がある。
本実施形態に於いて、各仮想網１１の通信によって直接に物理リソースの競合を調停するのではなく、リソース管理装置３０が、インフラ網１０のネットワーク仮想化を行う際に、各仮想網１１に割り当てる物理リソースを調整し、間接的に物理リソースの競合を調停する。これにより、各仮想網１１は、通信によるオーバヘッドを回避し、システム全体の堅牢性を高めることができる。

本実施形態のリソース管理装置３０は、物理リソースの配分量を規定する際に、物理リソースの属性に、予約型と共有型の２種類を設定している。リソース管理装置３０は、物理リソースに予約型の属性を設定することにより、仮想網１１の帯域を保証し、仮想網１１間の相互干渉を回避することができる。更に、リソース管理装置３０は、物理リソースに共有型の属性を設定することにより、この物理リソースを仮想網１１間で融通し、トラヒック変動への耐性を向上し、インフラ網１０のリソース利用効率を向上させることができる。
（第１の実施形態の効果）
以上説明した第１の実施形態では、次の（Ａ）〜（Ｃ）のような効果がある。

（Ａ） リソース管理装置３０は、各仮想網１１が利用可能な物理リソースに予約型の属性を設定し、各仮想網１１の構成を適用的に変更する。これにより、仮想網１１の数が増加しても、容易に仮想網１１間の相互干渉を最小化することができる。

（Ｂ） リソース管理装置３０は、物理リソースに予約型の属性を設定することにより、仮想網１１の帯域を保証し、仮想網１１間の相互干渉を回避することができる。

（Ｃ） リソース管理装置３０は、物理リソースに共有型の属性を設定することにより、この物理リソースを仮想網１１間で融通し、トラヒック変動への耐性を向上し、インフラ網１０のリソース利用効率を向上させることができる。

（Ｄ） 予約リソース計算部３８は、区分線形関数によって、トラヒック需要情報から、選択された仮想網１１に提供する物理リソースを算出する、これにより、トラヒック需要情報がゼロであっても予め物理リソースを予約でき、当該物理リソースの使用に備えることができる。

（Ｅ） 予約リソース計算部３８は、選択された仮想網１１に提供する物理リソースが相乗的に大きくなるように算出している。これにより、多くの物理リソースを消費する重要な仮想網１１に、多くの物理リソースを予約することができる。

（第２の実施形態の構成）
第２の実施形態のリソース管理装置３０は、第１の実施形態のリソース管理装置３０よりも、更に計算量を抑えて処理負荷を軽減することを特徴としている。
第２の実施形態のインフラ網１０および各仮想網１１の構成は、第１の実施形態のインフラ網１０および各仮想網１１（図１）の構成と同様である。
第２の実施形態のリソース管理装置３０の構成は、第１の実施形態のリソース管理装置３０（図４）の構成と同様である。

（第２の実施形態の動作）
図７は、第２の実施形態に於けるリソース配分量計算処理を示す図である。図６で示す第１の実施形態のリソース配分量計算処理と同一の要素には同一の符号を付与している。
処理を開始すると、ステップＳ１０ａに於いて、リソース管理装置３０の仮想網選択部３７は、インフラ網１０を構成する物理リソースのうち、トラヒック需要情報ＤＢ３３に基づき、ボトルネックとなりやすい物理リソースを選択する。すなわち、仮想網選択部３７は、特に競合が予測され、予約型の設定が必要とされる物理リソースを選択する。

ステップＳ１１ａに於いて、リソース管理装置３０の仮想網選択部３７は、ステップＳ１０ａの処理で選択した物理リソースを収容している仮想網１１の中から、選択した当該物理リソースを収容し、かつ問題となりやすい仮想網１１を選択する。すなわち、仮想網選択部３７は、仮想網パス情報ＤＢ３４の各仮想網１１の性能状態と、トラヒック需要情報ＤＢ３３の各仮想網１１のトラヒック需要の情報、予約リソースの配分対象とする仮想網１１の集合を選択する。
ステップＳ１２，Ｓ１３の処理は、第１の実施形態のステップＳ１２，Ｓ１３の処理（図６）と同様である。

（第２の実施形態の効果）
以上説明した第２の実施形態では、次の（Ｆ）のような効果がある。

（Ｆ） リソース管理装置３０の仮想網選択部３７は、特に競合が予測される物理リソースを選択したのち、当該物理リソースを収容している仮想網１１から、予約リソースの配分対象とする仮想網１１の集合を選択している。これにより、仮想網１１の個数が増大したときであっても、先に物理リソースを選択して仮想網１１を絞り込むことにより、計算量を抑えて処理負荷を軽減することができる。

（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。この利用形態や変形例としては、例えば、次の（ａ）〜（ｂ）のようなものがある。

（ａ） 第１の実施形態では、インフラ網１０の物理リソースとして、ＷＤＭリンクの各波長を各仮想網１１に配分している。しかし、これに限られず、ＴＤＭリンクの各ＴＤＭスロット、ノード２０、ポート、プロセッサ、ストレージ、または、計算機などを、各仮想網１１に配分してもよい。

（ｂ） 第１の実施形態の仮想網１１は、仮想ネットワーク（Virtual Private Network）である。しかし、これに限られず、各ノードがパスによって接続されている一般的な論理ネットワークであればよい。

１０ インフラ網
１１ 仮想網
２０ ノード
２１ リンク
２２ パス
３０ リソース管理装置
３１ 記憶部
３２ 網状態情報ＤＢ（インフラ網トポロジ情報）
３３ トラヒック需要情報ＤＢ（トラヒック需要情報）
３４ 仮想網パス情報ＤＢ（仮想網トポロジ情報）
３５ 処理部
３６ 情報収集部
３７ 仮想網選択部
３８ 予約リソース計算部
３９ リソース配分部
４０ 通信部
５０ ＩＰルータ
６０ フレーム

Claims (7)

1. インフラ網に係るインフラ網トポロジ情報と、当該インフラ網の上に構築された各仮想網に係る仮想網トポロジ情報とに基づき、前記各仮想網に係るトラヒック需要情報を収集する情報収集部と、
   前記トラヒック需要情報に基づき、前記各仮想網から制御対象の仮想網を選択し、当該仮想網に基づき、前記インフラ網に係る各物理リソースから制御対象の物理リソースを選択する仮想網選択部と、
   前記情報収集部が収集した前記トラヒック需要情報に基づき、区分線形関数によって、選択された前記仮想網に提供する前記物理リソースを算出する予約リソース計算部と、
   を備えることを特徴とするネットワークのリソース管理装置。
2. インフラ網に係るインフラ網トポロジ情報と、当該インフラ網の上に構築された各仮想網に係る仮想網トポロジ情報とに基づき、前記各仮想網に係るトラヒック需要情報を収集する情報収集部と、
   前記トラヒック需要情報に基づき、前記各仮想網から制御対象の仮想網を選択し、当該仮想網に基づき、前記インフラ網に係る各物理リソースから制御対象の物理リソースを選択する仮想網選択部と、
   前記情報収集部が収集した前記トラヒック需要情報に基づき、選択された前記仮想網に提供する前記物理リソースを、前記トラヒック需要情報に対して相乗的に大きくなるように算出する予約リソース計算部と、
   を備えることを特徴とするネットワークのリソース管理装置。
3. インフラ網に係るインフラ網トポロジ情報と、当該インフラ網の上に構築された各仮想網に係る仮想網トポロジ情報とに基づき、前記インフラ網に係る各物理リソースの前記各仮想網に係るトラヒック需要情報を収集する情報収集部と、
   前記トラヒック需要情報に基づき、前記各物理リソースから制御対象の物理リソースを選択し、当該物理リソースに基づき前記各仮想網から制御対象の仮想網を選択する仮想網選択部と、
   前記情報収集部が収集した前記トラヒック需要情報に基づき、選択された前記仮想網に提供する前記物理リソースを算出する予約リソース計算部と、
   を備えたことを特徴とするネットワークのリソース管理装置。
4. 前記予約リソース計算部は、区分線形関数によって、前記トラヒック需要情報から、選択された前記仮想網に提供する前記物理リソースを算出する、
   ことを特徴とする請求項３に記載のネットワークのリソース管理装置。
5. 前記予約リソース計算部は、前記トラヒック需要情報に対して、選択された前記仮想網に提供する前記物理リソースが相乗的に大きくなるように算出する、
   ことを特徴とする請求項３に記載のネットワークのリソース管理装置。
6. 前記予約リソース計算部が算出した前記物理リソースを、前記仮想網に予約配分するリソース配分部を、
   更に備えたことを特徴とする請求項１ないし請求項５のいずれか１項に記載のネットワークのリソース管理装置。
7. 前記予約リソース計算部は、
   前記各仮想網に係る前記トラヒック需要情報に基づいて、予約リソースの配分量を算出し、
   前記物理リソースに、共有型の属性または予約型の属性のいずれかを設定する、
   ことを特徴とする請求項１ないし請求項６のいずれか１項に記載のネットワークのリソース管理装置。

Images