JP4456543B2 - Ｖｐｎリソース管理装置 - Google Patents

Description

本発明は、ＶＰＮリソース管理装置に関する。

ストリーミング配信などでは、ネットワークリソース（以下、単にリソースとする）に要する帯域をトラヒックの送信前に確保することが、安定したサービス利用の前準備として必要となる。リソースは、コネクション型ネットワークにおいてはパスの本数やパスが使用する回線帯域などである。よって、サービスを利用するカスタマは、サービスを提供するプロバイダに対して、パスの新設またはパスの帯域増加などのパス要求を発し、プロバイダはそのパス要求を許可するか否かを判断する受付制御機能（アドミッション制御機能）を用いることが多い（非特許文献１）。

従来のネットワーク管理方法としては、パス要求を受けた段階でリソースの空き状況を調べ、空いている場合にパス（回線）の開通を行う（非特許文献２）。しかしながら、プロバイダは、パス要求を満たすために、ルータなどのネットワークの設備をどれだけ用意すればよいかわからず、設備設計が困難である。特に、パス要求の要求頻度が高い、または、需要予測が難しい場合には、必要とされる設備が不確定となる。
３ＧＰＰ、"携帯電話への映像サービスに向けて第３世代「３ＧＰＰ」準拠ゲートウェイ"、［２００５年７月検索］、[online]、インターネット〈ＵＲＬ：http://www.ftt.co.jp/3GPP/〉 須田宏一外３名著、"次世代コアネットワークのオペレーションアーキテクチャ"、ＮＴＴ技術ジャーナル２００１年１月号、電気通信協会、Ｐ７６〜８１（Ｐ７８参照）

なお、カスタマは、受付制御においてパス要求を拒否されてしまうことを防ぐため、プロバイダに対してパス要求の前にあらかじめ契約によってリソースを確保することが考えられる。これにより、カスタマは、適切にリソースを確保することができる。

しかしながら、従来の受付制御は、サービス単位に実施されているものの、カスタマが行った契約に関する情報は考慮されてこなかった。よって、従来の受付制御では、カスタマが発したパス要求において、契約内容より多くのリソースが要求されたときに、その要求通りにカスタマに使用させてしまう可能性がある。その結果、プロバイダは、カスタマとの契約を守るために、課金対象となる契約内容の水準の設備以上の過剰な設備投資を余儀なくされる。

そこで、本発明は、前記した問題を解決し、受付制御を処理するネットワークシステムを提供するプロバイダに適正な設備投資を支援することを主な目的とする。

前記課題を解決するために、本発明は、同一カスタマのＣＥ間に設定されるＣＥ間パスおよびプロバイダのＰＥ間に設定されるＰＥ間パスにより通信を行うＶＰＮにおいて、ＣＥ間のパスが利用する前記ＰＥ間パスを設定するためのリソースを管理するＶＰＮリソース管理装置であって、カスタマのリソース契約量および前記ＰＥ間パスが使用するリソース量を管理する受付制御手段と、前記ＶＰＮのネットワークトポロジを管理するリンクリソース管理手段と、前記ＰＥ間パスが使用するリソース量およびＶＰＮのネットワークトポロジをもとに、前記受付制御手段が受け付けたパス要求に対するパスの経路を計算する経路計算手段とを有し、前記受付制御手段は、前記パス要求によって変更された前記ＰＥ間パスが使用するリソース量が、カスタマとのリソース契約量以内なら、前記経路計算手段にパスの計算を許可し、前記受付制御手段は、カスタマのリソース契約量として、前記カスタマごとに定義される、各ＰＥについて流入するトラヒック量上限、流出するトラヒック量上限および各ＰＥ間のトラヒック量上限を用いることを特徴とする。

これにより、契約に従ったリソース管理が実現でき、カスタマとの契約の遵守を行うことができる。さらに、受付制御を処理するネットワークシステムを提供するプロバイダに適正な設備投資を支援することができる。

これにより、プロバイダ網の内部の設備を指定した上での契約が実現できるので、プロバイダは、網内のリソースを契約として有効に課金することができる。

本発明は、前記受付制御手段がカスタマのリソース契約量を管理する前に、入力されたカスタマからの契約予定量から、前記ＰＥ間パスの経路およびリンクに確保すべきリソース量を計算する事前計算手段と、前記事前計算手段の計算結果である経路を格納する事前計算経路ＤＢと、前記事前計算手段の計算結果である確保すべきリソース量を格納する事前予約リソースＤＢとを有し、前記経路計算手段は、前記事前計算経路ＤＢを参照して、パスの経路を計算することを特徴とする。

これにより、契約に従ったリソース管理を実現しつつ、リソース利用を効率化することができ、低コストでのネットワーク構築・運用、ひいては、低コストでのサービス提供が可能となる。

本発明は、同一カスタマのＣＥ間に設定されるＣＥ間パスおよびプロバイダのＰＥ間に設定されるＰＥ間パスにより通信を行うＶＰＮにおいて、ＣＥ間のパスが利用する前記ＰＥ間パスを設定するためのリソースを管理するＶＰＮリソース管理装置であって、カスタマのリソース契約量および前記ＰＥ間パスが使用するリソース量を管理する受付制御手段と、前記ＶＰＮのネットワークトポロジを管理するリンクリソース管理手段と、前記ＰＥ間パスが使用するリソース量およびＶＰＮのネットワークトポロジをもとに、前記受付制御手段が受け付けたパス要求に対するパスの経路を計算する経路計算手段とを有し、前記受付制御手段は、前記パス要求によって変更された前記ＰＥ間パスが使用するリソース量が、カスタマとのリソース契約量以内なら、前記経路計算手段にパスの計算を許可し、前記受付制御手段は、カスタマのリソース契約量として、前記カスタマごとに定義される、各ＰＥについて流入するトラヒック量上限および流出するトラヒック量上限を用いることを特徴とする。

これにより、契約に従ったリソース管理が実現でき、カスタマとの契約の遵守を行うことができる。さらに、受付制御を処理するネットワークシステムを提供するプロバイダに適正な設備投資を支援することができる。
これにより、プロバイダ網の内部の設備を指定することなく契約が実現できるので、プロバイダは、網内の管理を簡略化でき、管理コストを抑制することができる。

本発明は、前記受付制御手段がカスタマのリソース契約量を管理する前に、入力されたカスタマからの契約予定量から、前記ＰＥ間パスの経路およびリンクに確保すべきリソース量を計算する事前計算手段と、前記事前計算手段の計算結果である確保すべきリソース量を格納する事前予約リソースＤＢと、を有することを特徴とする。

これにより、事前計算経路ＤＢの機能構成を省略することで、ネットワーク機器の低コスト化、ひいては、サービスの低コスト化が可能となる。

本発明では、受付制御を処理するネットワークシステムを提供するプロバイダに適正な設備投資を支援することができる。

次に、本発明の各実施形態について図面を参照して説明する。

まず、第１実施形態について、説明する。

図１は、第１実施形態におけるネットワーク構成の一例を示している。ＣＥ（Customer Edge）（図１のＣＥ１〜ＣＥ４）は、カスタマが所有し、１つ以上のＰＥと接続されている装置である。ＰＥ（Provider Edge）（図１のＰＥ１〜ＰＥ３）は、プロバイダが所有し、１つ以上のＣＥと接続されている装置である。Ｐ（Provider）（図１のＰ１）は、プロバイダが所有し、ＰＥもしくはＰと接続されている装置である。

なお、ＣＥ、ＰＥ、Ｐとしては、例えば、ルータやＬ２ＳＷ（Layer 2 Switch）、ＴＤＭ（Time Division Multiplexing）クロスコネクト、波長クロスコネクト、ＭＰＬＳ（Multi Protocol Label Switching）のＬＳＲ（Label Switching Router）、などの通信装置が相当する。リンクＬ１〜Ｌ９は、ＣＥ−ＰＥ、ＰＥ−Ｐ、ＰＥ−ＰＥ間に存在し、情報転送の媒体となる。プロバイダ網は、ＰＥ、Ｐ、リンクＬ１，Ｌ２，Ｌ３により構成される。

さらに、図１は、同一カスタマ間の通信を他のカスタマ間の通信とは分離するＶＰＮ（Virtual Private Network）を例示している。同一カスタマのＣＥ間にパスを設定することで、同一カスタマのＣＥ間でのみ通信を可能とする。例えば、ＶＰＮ＃１に属する各ＣＥは、ＶＰＮ＃１に属する他のＣＥとの間でパスを通じて通信を行う。また、プロバイダ網は、複数のカスタマの通信を中継するコアネットワークの役割を担う。プロバイダ網に属するＰＥおよびＰは、カスタマの契約以内であればリソースを保証する。

図１のネットワークを管理するＶＰＮリソース管理装置１（図３参照）は、ＶＰＮのカスタマごとにネットワークのリソースを管理する。そして、ＶＰＮリソース管理装置１は、カスタマおよびプロバイダの間の契約により確保されたリソースをカスタマに提供するために、パスの設定を制御する。パスは、ＰＥ間パスまたはＣＥ間パスに分類される。ＰＥ間パスはＶＰＮリソース管理装置１によって設定および制御されるパスであり、プロバイダ網のＰＥ間を両端点として設定される。そして、ＣＥ間パスは、ＰＥ間パスを使用して設定されるＣＥ間のパスである。ＶＰＮの通信は、ＣＥ間パスを介して行われる。

なお、ＶＰＮリソース管理装置１は、演算処理を行う際に用いられる記憶手段としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上のプログラムを実行することで、実現される。なお、ＶＰＮリソース管理装置１は、ＰＥ、Ｐ内にあってもよいし、別の装置であってもよい。

図２のフローチャートは、ＶＰＮリソース管理装置１の動作概要を説明するものである。

まず、ＶＰＮリソース管理装置１は、プロバイダおよびカスタマの間で締結された仮契約に関する情報を入力されると、その情報を記憶する（Ｓ１０２）。次に、ＶＰＮリソース管理装置１は、Ｓ１０２の仮契約に関する情報に基づきカスタマからの契約予定量を受けると、その契約予定量をもとに事前に仮契約に関する経路を計算する（Ｓ１０４）。

そして、ＶＰＮリソース管理装置１は、プロバイダおよびカスタマの間で締結された契約（本契約）に関する情報を入力されると、その情報を記憶する（Ｓ１０６）。さらに、ＶＰＮリソース管理装置１は、カスタマからのパス要求を受け、Ｓ１０６の契約に基づきパスを決定する（Ｓ１０８）。そして、ＶＰＮリソース管理装置１は、Ｓ１０８で設定したパスを介してトラヒックを通信する（Ｓ１１０）。

このように、仮契約の段階で契約予定量を入手することにより、プロバイダは、カスタマとの契約において必要とされるリソース量を推測することができる。よって、プロバイダは、カスタマとの直接的な本契約において確定するリソース量の分だけ、設備を配備しておけばよいため、カスタマとの契約を遵守するための余計に設備を配備しておくことがなくなり、ネットワークコストを抑制することができる。なお、Ｓ１０２，Ｓ１０４は、省略してもよい。

図３は、ＶＰＮリソース管理装置１の構成を示している。以下、ＶＰＮリソース管理装置１の各構成要素について、具体的に説明する。

プロファイルＤＢ１２は、トラヒック量上限などのＶＰＮカスタマごとの契約、および、現在のトラヒック量を格納するものである。VPN-IDとは、ＶＰＮを一意に識別する情報である。１つのVPN-IDに対して、１つ以上の「PE-ID」、または、１つ以上の「PE-ID→PE-ID」が対応付けられる。

契約は、ｈｏｓｅモデルまたはｐｉｐｅモデルに分類される。まず、ｈｏｓｅモデルは、ＰＥからみてプロバイダ網の外側に関する通信を規定する契約モデルであり、VPN-IDおよび「PE-ID」の対応によって示される。一方、ｐｉｐｅモデルは、ＰＥからみてプロバイダ網の内側に関する通信を規定する契約モデルであり、VPN-IDおよび「PE-ID→PE-ID」の対応によって示される。本明細書では、ｈｏｓｅモデルおよびｐｉｐｅモデルを併用するモデルを、ｈｙｂｒｉｄモデルと定義する。

ｈｏｓｅモデルにおける「PE-ID」とは、ＰＥを一意に識別する情報であり、例えば、ＩＰアドレスが相当する。以下、「PE-ID」に対応付けられる情報を説明する。流入トラヒック量とはプロバイダ網の外からＰＥへ流入するトラヒック量を示し、流出トラヒック量とはＰＥからプロバイダ網の外へ流出するトラヒック量を示す。そして、流入トラヒック量上限および流出トラヒック量上限とは、それぞれのトラヒック量についての契約で定められた上限値である。

なお、各トラヒック量およびその上限は、VPN-IDで特定されるカスタマごとに定義される。例えば、図１のＶＰＮ＃１のＰＥ１での流入トラヒック上限とは、ＶＰＮ＃１のＣＥ１からＰＥ１に流れこむトラヒック量の上限を指す。同様に、ＶＰＮ＃１のＰＥ２での流出トラヒック量上限とは、ＰＥ２からＶＰＮ＃１のＣＥ１に流れ出すトラヒック量の上限を指す。なお、１つのＰＥに同一ＶＰＮに属する複数のＣＥが接続しているときには、ＰＥのトラヒック量は、同一ＶＰＮに属する各ＣＥのトラヒック量の総和となる。

ｐｉｐｅモデルにおける「PE-ID→PE-ID」とは、ＰＥ間にリソースを確保すべきＰＥのペアを示し、→はトラヒックの流れる方向を示す。例えば、ＰＥ１→ＰＥ２となっている場合、ＰＥ１からＰＥ２にトラヒックが流れる。ＰＥ間トラヒック量上限とは、ＰＥ間のトラヒック量の上限を示す。ＰＥ間トラヒック量とは、ＰＥ間の現在のトラヒック量を示す。なお、各トラヒック量およびその上限は、VPN-IDで特定されるカスタマごとに定義される。

図３のプロファイルＤＢは，ｈｏｓｅモデルおよびｐｉｐｅモデルの組み合わせで表されるｈｙｂｒｉｄモデルとなっている。

受付制御手段２２は、所定カスタマからのパス要求（パスのリソース増加または減少の要求）があった場合、パス要求を反映した後の所定カスタマの利用リソースが、プロファイルＤＢ１２に示される所定カスタマの契約内容の許容範囲内か否かを判断する。許容範囲内でない利用リソースが要求されたときには、その要求を拒絶する。

リンクＤＢ１４は、プロバイダ網のリンク情報を格納するものである。Ａ端とはリンクの一方の端であり、Ｚ端とはそのリンクのもう一方の端である。装置ＩＤとしては、例えば、ＩＰアドレスが相当し、Ａ端装置ＩＤとは、リンクの一方の端となっている装置のＩＤであり、Ｚ端装置ＩＤとは、リンクのもう一方の端となっている装置のＩＤである。

また、Ａ端またはＺ端のIF-IDとは、ＩＰアドレス、もしくは単なる数字が相当する。Ａ端IF-IDとはＡ端装置で前記リンクを一意に示す情報であり、Ｚ端IF-IDとはＺ端装置で前記リンクを一意に示す情報である。さらに、残余帯域とは、前記リンクの残余帯域を示す情報である。リンクＤＢ１４が格納するその他の情報としては、例えば、リンクにおける故障率が挙げられる。故障率は例えば、所定値以上の故障値となるリンクをパス計算から除外する用途で使用される。

なお、リンクＤＢ１４は、１台のＶＰＮリソース管理装置１によって集中的に管理されていてもよいし、ＲＦＣ３６３０（Traffic Engineering（ＴＥ）Extensions to OSPF Version2）に示すような方法で、分散的に管理されていてもよい。

リンクリソース管理手段２４とは、リンクＤＢ１４の残余帯域を管理し、経路計算手段２８により計算されたパスの経路上のリンクについて、残余帯域から要求帯域分を減らす。また、リソース減少要求があった場合、要求されたパスを解放する必要があるが、解放するパスの経路上のリンクについて、残余帯域を解放帯域分増加させるものである。

経路計算手段２８は、受付制御手段２２に要求されたパス要求を受け、パス要求で指定されたリソースを確保できるＰＥ間パスを設定する。なお、経路計算手段２８は、パス要求のうち、受付制御手段２２によって契約する通信サービスの規定値を超えるものについて、設定対象から除外する。経路計算手段２８は、パスの経路を計算するアルゴリズムとしては、リンクＤＢ１４を入力として用い、公知手法である制約付ダイクストラ法などを用いることができる。

図４は、ＶＰＮリソース管理装置１による、リソース管理の手順を示している。この手順は、契約に基づくパスの設定（Ｓ１０８）を具体化したものである。

まず、受付制御手段２２は、パス要求を受け（Ｓ２０２）、そのパス要求の内容がリソース増加か減少かを判定する。以下、Ｓ２０２でリソース増加要求の時の動作を説明する。なおリソース増加要求はカスタマからの要求や、網オペレータからの指示により発生する。受付制御手段２２は、リソース増加要求によって増加されたリソースの利用量およびカスタマの契約量を照合する。

受付制御手段２２は、契約以内である場合は（Ｓ２０４，Ｙｅｓ）、経路計算手段２８にパスの経路を計算させる。経路計算手段２８が経路を発見したら（Ｓ２０６，Ｙｅｓ）、リンクリソース管理手段２４がカスタマが利用するパスのリソースを増加させるとともに（Ｓ２０８）、リンクの残余帯域を減らす。一方、受付制御手段２２が契約量と照合した結果、契約以内でない場合（Ｓ２０４，Ｎｏ）、または、経路計算手段２８がパスの経路を発見しなかった場合（Ｓ２０６，Ｎｏ）は、リソースを確保することができないため、要求元に拒否メッセージを発信するなどして、要求を拒否する（Ｓ２１０）。

次に、Ｓ２０２でリソース減少要求が発生した場合について述べる。リンクリソース管理手段２４は、解放するパスの経路上のリンクについて、カスタマが利用するリソースを減少させるとともに（Ｓ２１２）、リンクの残余帯域を増やす。なお、パス設定がリソースの増加でもなく減少でもないときには（Ｓ２０２，その他）、シグナリングプロトコルの処理部（図示省略）などに処理を委譲して、終了する。

以上説明したように、ＶＰＮリソース管理装置１は、リソース増加要求に対しては、次のように動作する。ＶＰＮリソース管理装置１は、あるＶＰＮに対して所定カスタマからリソース増加要求があった場合、プロファイルＤＢ１２に示される所定カスタマの契約内容の上限値以内である場合は、パス設定許可をするとともに、プロファイルＤＢ１２のトラヒック量を増加されたトラヒック量に更新する。一方、ＶＰＮリソース管理装置１は、リソース増加要求によって増加された所定カスタマの使用するトラヒック量が、契約内容の上限値を超えてしまったときには、契約内容を超えたリソース増加要求として、拒絶する。

また、ＶＰＮリソース管理装置１は、所定カスタマからリソース減少要求があった場合、契約内容に関係なく、プロファイルＤＢ１２のトラヒック量を減少されたトラヒック量に更新することで、契約に従った受付制御を行う。これは、リソース減少要求においては必要とするリソース量は減少するため、契約内容を参照するまでもなく契約が守られることが自明であるためである。

次に、第２実施形態について、説明する。第２実施形態は、契約モデルとして、ＰＥへの流入トラヒック量上限、流出トラヒック量上限、および、ＰＥ間のトラヒック量を規定するｈｙｂｒｉｄモデルを用いるものである。図５は、第２実施形態のＶＰＮリソース管理装置１の構成を示している。

事前計算経路ＤＢ１６は、事前計算手段２６により計算された経路を格納するものである。VPN-IDとは、ＶＰＮを一意に識別する情報である。始点ＰＥ装置ＩＤは、ＣＥ間パスの一部であるＰＥ間パスの始点となるＰＥの装置ＩＤである。終点ＰＥ装置ＩＤは、ＣＥ間パスの一部であるＰＥ間パスの終点となるＰＥの装置ＩＤである。経路とは、始点ＰＥから終点ＰＥまでのパスの経路をリンクのリストで表したものである。

例えば、図１で、ＶＰＮ１に対して、ＰＥ１からＰＥ２の事前経路としてＰＥ１−Ｐ１−ＰＥ２が計算された場合、始点ＰＥ装置ＩＤとして、ＰＥ１の装置ＩＤ、終点ＰＥ装置ＩＤとして、ＰＥ２の装置ＩＤ、経路として、（ＰＥ１装置ＩＤ、ＰＥ１−Ｐ１間リンクのＰＥ１でのIF-ID）−（Ｐ１装置ＩＤ、Ｐ１−ＰＥ２間リンクのＰ１でのIF-ID）となる。

事前予約リソースＤＢ１８とは、事前計算手段２６により計算されたＶＰＮに割り当てるべきリソース量を格納する。VPN-IDとは、ＶＰＮを一意に識別する情報である。Ａ端装置ＩＤとは、リンクの一方の端となっている装置のＩＤ、Ｚ端装置ＩＤとは、リンクのもう一方の端となっている装置のＩＤ、Ａ端IF-IDとは、Ａ端装置で、前記リンクを一意に示す情報、Ｚ端IF-IDとは、Ｚ端装置で、前記リンクを一意に示す情報、予約帯域とは、前記ＶＰＮに対して前記リンクで予約すべきリソース量を意味する。

事前計算手段２６は、経路の事前計算を行う（Ｓ１０４）。つまり、事前計算手段２６は、プロファイルＤＢ１２とリンクＤＢ１４をインプットとし、契約を満たし、かつリソース利用を効率化するように、事前に予約すべきリソース量を計算し、事前計算経路と、事前計算経路上の各リンクに確保すべき事前予約リソース量をアウトプットとする。この時の計算アルゴリズムとしては、例えば発見的手法を用いる方法がある（文献「武田、大羽、井上、漆谷著、“ＶＰＮリソースプロビジョニング法の提案”、信学会ソ大会、Ｂ−１２−６、２００４年９月」参照）。

そして、経路計算手段２８の計算方法としては、第１実施形態（図２）と比較して、事前計算経路ＤＢ１６を問い合わせ、該当する経路を検索するように変更される。つまり、経路計算手段２８は、事前計算経路ＤＢ１６に格納されているVPN-ID、始点ＰＥ装置ＩＤ、および、終点ＰＥ装置ＩＤを参照して、経路を検索する。さらに、経路計算手段２８は、Ｓ１０２の仮契約およびＳ１０６の契約の内容が同一なら、事前計算経路ＤＢ１６に格納されている経路を参照する。

そして、第３実施形態について、説明する。第３実施形態は、契約モデルとして、ＰＥへの流入トラヒック量上限、流出トラヒック量上限のみを規定し、ＰＥ間のトラヒック量を規定しないｈｏｓｅモデルを用いるものである。例えば、図６（ａ）は、ＰＥへの流入トラヒック量上限、および、流出トラヒック量上限として、４Ｇのトラヒック量を規定する一例を示している。

図６（ｂ）は、リンクＤＢ１４に格納されているネットワークトポロジの一例を示す。なお、図中のＡ，Ｂ，Ｃは、Ｐ（Provider）に分類される。図６（ｃ）は、図６（ｂ）のネットワークトポロジに対して事前計算手段２６が計算して事前計算経路ＤＢ１６に格納した経路（図中の矢印）の一例を示す。図６（ｄ）は、図６（ｂ）のネットワークトポロジに対して事前計算手段２６が計算して事前予約リソースＤＢ１８に格納したリソース量の一例を示す。例えば、ＰＥ１およびＡの間には、４Ｇのリソースが予約される。

図７は、第３実施形態のＶＰＮリソース管理装置１の構成を示している。図７の構成は、図５と比較して、事前計算経路ＤＢ１６がない。また、事前予約リソースＤＢ１８に、予約残余帯域が追加される。これは、予約帯域に対して、どれだけの帯域が残されているかを示す。

事前計算手段２６は、ｈｏｓｅモデルの場合、ツリーを構成し、ツリー上に事前計算経路をとり、かつ、この事前計算経路上に各リンクに確保すべき事前予約リソース量をとる（文献「A.Juttner et al.著、“On bandwidth efficiency of the hose resource management model in virtual private networks”、IEEE INFOCOM 2003」、および、文献「A.Kumar et al.著、“Algorithms for provisioning virtual private networks in the hose model”、IEEE Trans.Networking,Aug.2002」を参照）。

このような場合、事前予約リソースＤＢ１８をリンクＤＢ１４と見立てると、ＰＥ間の経路が一意に決まるため、事前計算経路を格納する必要はない。すなわち、経路計算手段２８が、事前予約リソース量をリンクＤＢ１４に見立てた上で、制約付ダイクストラ法を適用すればよい。これにより、機能構成を簡略化できる。また、リンクリソース管理手段２４は、事前予約リソースＤＢ１８の予約残余帯域のリソースもリソース増減にあわせ、管理する。

以上説明した各実施形態は、ＶＰＮを実現する通信ネットワークにおいて、カスタマとの通信サービスの契約規定値（例：帯域量）に対する実数値を管理する受付制御手段２２と、装置間のリンクのリソース（帯域）を管理するリンクリソース管理手段２４と、パスの経路を計算する経路計算手段２８とを含むＶＰＮリソース管理装置１が、通信サービスの契約規定値に従ってリソース（帯域）を管理することを特徴とする。

ＶＰＮリソース管理装置１が、１つ以上のカスタマを同一の網に収容しながら、同一カスタマのＣＥ間にのみパス設定を許容することで、同一カスタマのＣＥ間でのみ通信を可能とするＶＰＮにおいて、カスタマとのリソース契約に基づいてリソース管理を行う。なおリソース契約とは、例えば通信サービスの規定値を意味する。

各実施形態により、ＶＰＮにおけるリソースを通信サービスの契約規定値に従って管理することが可能になり、各サービス契約への余裕を考慮したような契約規定値以上の多大なリソースを準備する必要がなくなる。よって、リソースの適正配備（効率的な設備配備）を行うことができる。

本発明の各実施形態に関するＶＰＮを示す構成図である。 本発明の各実施形態に関するＶＰＮリソース管理装置の動作概要を示すフローチャートである。 本発明の第１実施形態に関するＶＰＮリソース管理装置を示す構成図である。 本発明の第１実施形態に関するリソース管理装置によるリソース管理処理を示すフローチャートである。 本発明の第２実施形態に関するｈｙｂｒｉｄモデルにおけるＶＰＮリソース管理装置を示す構成図である。 本発明の第３実施形態に関するｈｏｓｅモデルにおける各データを示す説明図である。 本発明の第３実施形態に関するｈｏｓｅモデルにおけるＶＰＮリソース管理装置を示す構成図である。

符号の説明

１ ＶＰＮリソース管理装置
１２ プロファイルＤＢ
１４ リンクＤＢ
１６ 事前計算経路ＤＢ
１８ 事前予約リソースＤＢ
２２ 受付制御手段
２４ リンクリソース管理手段
２６ 事前計算手段
２８ 経路計算手段

Claims (4)

1. 同一カスタマのＣＥ間に設定されるＣＥ間パスおよびプロバイダのＰＥ間に設定されるＰＥ間パスにより通信を行うＶＰＮにおいて、ＣＥ間のパスが利用する前記ＰＥ間パスを設定するためのリソースを管理するＶＰＮリソース管理装置であって、
   カスタマのリソース契約量および前記ＰＥ間パスが使用するリソース量を管理する受付制御手段と、
   前記ＶＰＮのネットワークトポロジを管理するリンクリソース管理手段と、
   前記ＰＥ間パスが使用するリソース量およびＶＰＮのネットワークトポロジをもとに、前記受付制御手段が受け付けたパス要求に対するパスの経路を計算する経路計算手段とを有し、
   前記受付制御手段は、前記パス要求によって変更された前記ＰＥ間パスが使用するリソース量が、カスタマとのリソース契約量以内なら、前記経路計算手段にパスの計算を許可し、
   前記受付制御手段は、カスタマのリソース契約量として、前記カスタマごとに定義される、各ＰＥについて流入するトラヒック量上限、流出するトラヒック量上限および各ＰＥ間のトラヒック量上限を用いること
   を特徴とするＶＰＮリソース管理装置。
2. 前記受付制御手段がカスタマのリソース契約量を管理する前に、入力されたカスタマからの契約予定量から、前記ＰＥ間パスの経路およびリンクに確保すべきリソース量を計算する事前計算手段と、
   前記事前計算手段の計算結果である経路を格納する事前計算経路ＤＢと、
   前記事前計算手段の計算結果である確保すべきリソース量を格納する事前予約リソースＤＢとを有し、
   前記経路計算手段は、前記事前計算経路ＤＢを参照して、パスの経路を計算すること
   を特徴とする請求項１に記載のＶＰＮリソース管理装置。
3. 同一カスタマのＣＥ間に設定されるＣＥ間パスおよびプロバイダのＰＥ間に設定されるＰＥ間パスにより通信を行うＶＰＮにおいて、ＣＥ間のパスが利用する前記ＰＥ間パスを設定するためのリソースを管理するＶＰＮリソース管理装置であって、
   カスタマのリソース契約量および前記ＰＥ間パスが使用するリソース量を管理する受付制御手段と、
   前記ＶＰＮのネットワークトポロジを管理するリンクリソース管理手段と、
   前記ＰＥ間パスが使用するリソース量およびＶＰＮのネットワークトポロジをもとに、前記受付制御手段が受け付けたパス要求に対するパスの経路を計算する経路計算手段とを有し、
   前記受付制御手段は、前記パス要求によって変更された前記ＰＥ間パスが使用するリソース量が、カスタマとのリソース契約量以内なら、前記経路計算手段にパスの計算を許可し、
   前記受付制御手段は、カスタマのリソース契約量として、前記カスタマごとに定義される、各ＰＥについて流入するトラヒック量上限および流出するトラヒック量上限を用いること
   を特徴とするＶＰＮリソース管理装置。
4. 前記受付制御手段がカスタマのリソース契約量を管理する前に、入力されたカスタマからの契約予定量から、前記ＰＥ間パスの経路およびリンクに確保すべきリソース量を計算する事前計算手段と、
   前記事前計算手段の計算結果である確保すべきリソース量を格納する事前予約リソースＤＢと、を有すること
   を特徴とする請求項１または請求項３に記載のＶＰＮリソース管理装置。

Images