JP5863876B2 - ネットワークシステム、アクセスコントローラ、それらを運用する方法、及びコンピュータプログラム - Google Patents

Description

本発明は通信システムに関し、詳細には、物理トランスポートネットワークに依存する通信ネットワークのためのネットワークシステム及びアクセスコントローラに関する。

図７は、同じトランスポートネットワークインフラストラクチャ上にある複数の仮想ネットワークの概略的な表現を示す。例示的には、音声サービス７０が、例示的なスイッチ７２と、これらのスイッチ間の接続７３とによって示される物理トランスポートネットワークインターフェースのサービス品質クラス０を形成し、ビデオサービス７１が、そのサービス品質１を形成することが示される。図７は２つの点線７４、７５を更に示す。これらの点線７４、７５は、この場合には４Ｇ及び５Ｇによって表される、各仮想ネットワークに対してサービスごとに割り当てられる帯域幅を示す。例示的には、４Ｇの場合の第１の仮想ネットワークはＱｏＳクラス０に関して点線７５より下の帯域幅を割り当てられ、同じ仮想４Ｇネットワークが、ＱｏＳクラス１に関して点線７４より下に示される帯域幅を消費することになる。その結果として、第２の仮想ネットワーク５Ｇは、例えば、ＱｏＳクラス０に関して点線７５より上の帯域幅を、ＱｏＳクラス１に関して点線７４より上の帯域幅を消費することになる。しかしながら、現在既存の物理転送トランスポートネットワークは、異なる仮想ネットワークをサポートすることはできない。既知のトランスポートネットワークは、ＭＰＬＳ又は任意の他のトランポートプロトコル等のラベルスイッチングに基づくトランスポートプロトコルに従って動作する。そのようなトランスポートプロトコルは、同じ単一の物理トランスポートネットワーク上で異なる仮想ネットワークを柔軟に実施することはできず、詳細には、そのようなプロトコルは仮想ネットワークごとのサービス品質保証を提供することはできない。

一方、オープンフロー（ＯＦ）に基づくネットワークのようなソフトウェア定義ネットワーク（ＳＤＮ）は、仮想ネットワークのための柔軟なサービス品質サポートを有しない。

それゆえ、本発明の目的は、より柔軟なネットワークシステムを提供することである。

この目的は、請求項１に記載のネットワークシステム、請求項１３に記載のアクセスコントローラ、請求項１６に記載のネットワークシステムを運用する方法、又は請求項１７に記載のコンピュータプログラムによって達成される。

本発明は、２つの端末間のセッションからのデータをトランスポートするための物理トランスポートネットワークを含むネットワークシステムが、発信元端末から物理トランスポートネットワークへのありとあらゆるアクセスを制御する個別のアクセスコントローラに接続されるという研究結果に基づく。アクセスコントローラは発信元端末と物理トランスポートネットワークとの間に接続され、アクセスコントローラは、仮想ネットワークごとに、仮想ネットワークの利用可能帯域幅に関する情報を含むデータレコードを用いて、第１の仮想ネットワークにおける第１のセッションの開始、及び第２の仮想ネットワークにおける第２のセッションの開始を制御するように構成される。詳細には、本発明は、単一の物理トランスポートネットワーク上で異なる仮想ネットワークへのサポートを提供するという点で有利である。本発明の好ましい実施形態の更なる利点は、仮想ネットワークごとのサービス品質ポリシーが１つの同じ物理トランスポートネットワーク上でサポートされることである。

一実施形態では、第１の仮想ネットワークは第１の複数のサービス品質クラスを提供し、第２の仮想ネットワークは第２の複数のサービス品質クラスを提供し、物理トランスポートネットワークは、複数のトランスポートサービス品質クラスを更に提供する。この場合、アクセスコントローラは、対応する仮想ネットワークに対して具体的に要求されるサービス品質クラスのための利用可能帯域幅に関する情報を用いて、第１のセッション及び第２のセッションの開始を制御するように構成される。

好ましくは、アクセスコントローラに記憶されたデータレコードは、仮想ネットワークごとに、第１の複数のサービス品質クラス及び第２の複数のサービス品質クラスのサービス品質クラスごとの利用可能帯域幅に関する情報を含み、サービス品質クラスごとに、全ての仮想ネットワークのための最大帯域幅の和は対応するトランスポートサービス品質クラスの最大帯域幅以下である。更なる実施形態は、発信元端末からのセッション確立要求の取扱いに関する。このセッション確立要求はアクセスコントローラによって傍受され、このセッション及び対応する仮想ネットワークにおいて必要とされるサービス品質クラスに必要とされる帯域幅が利用可能であるとき、このセッション確立要求は物理トランスポートネットワークに転送される。しかしながら、必要とされる帯域幅が利用可能でないとき、プリエンプション手順が開始され、プリエンプション手順は１つの同じ仮想ネットワーク内でのみ動作するように容易に実施することができ、両方の仮想ネットワークが１つの同じ物理トランスポートネットワーク上で実施される場合であっても、一方の仮想ネットワークのユーザが他方の仮想ネットワークのユーザによって影響を及ぼされないという点で仮想ネットワークは特に有用であるので、プリエンプション手順は大抵の状況の場合に好ましい。

それにもかかわらず、仮想ネットワーク間の分離が主な目的ではなく、スループットが主な目的である状況では、１つの同じ仮想ネットワーク内でだけでなく、物理トランスポートネットワーク上に確立された一部又は全ての仮想ネットワーク内でも、非常に効率的でトランスペアレントなプリエンプション手順を実行することができる。

好ましくは、ソフトウェア定義ネットワークがＭＰＬＳタイププロトコルと組み合わせられ、例えば、ＧＭＰＬＳが他の変形形態のための一例である。好ましい実施形態では、ＳＤＮは許可制御ドメイン（ＡＣＤ）として働き、許可制御ドメインはＭＰＬＳトンネリングドメイン（ＴＤ）ＱｏＳポリシーに準拠して仮想ネットワークごとの許可制御を行う。

本発明は、所望のサービス品質保証を有する複数の仮想ネットワークを受け入れるために、既に標準化され、及び／又は展開されているＭＰＬＳに基づくトランスポートインフラストラクチャを何も変更する必要はないという点で特に有利である。これは、一方ではコストを節約し、更には、既に運用中の、標準化され、展開されているトランスポートインフラストラクチャが変更されなければならなかった場合に生じるおそれがあった誤りを回避する。さらに、本発明は、ハイエンドのサービス品質機構をサポートするために、ソフトウェア定義ネットワーク（ＳＤＮ）を必要としない。信頼性及び効率が更に高められるという事実に起因して、これも１つの利点である。

好ましくは、ＭＰＬＳ等の、ラベルスイッチングに基づくトンネリングプロトコルを用いる単一の物理トランスポートネットワーク上で、或るサービス品質（ＱｏＳ）保証を有する複数の仮想ネットワークがプロビジョニングされるべきである。

次に、本発明の好ましい実施形態が添付の図面に関して説明される。

好ましいネットワークシステムのブロック図である。 ネットワークシステムに関する更なる細部を示す図である。 アクセスコントローラに記憶される好ましいデータレコードを示す図である。 発信元端末からのセッション確立要求を取り扱う手順を示す図である。 ネットワークシステムに関する更なる細部を示す図である。 アクセスコントローラの好ましい実施態様を示す図である。 同じトランスポートネットワークインフラストラクチャ上に複数の仮想ネットワークがあるシナリオを示す図である。 本発明の背後にある問題を明らかにするための概要を示す図である。 概要のシナリオにおける本発明の好ましい実施態様を示す図である。 集中型ネットワーク管理システム／ＯＳＳを用いる好ましい実施形態を示す図である。 分散型ネットワーク管理システム／ＯＳＳを用いる実施形態を示す図である。 仮想ネットワーク確保要求のためのメッセージフローを示す図である。 セッション許可が生じるときの概要を示す図である。 セッション許可のためのメッセージフローの第１の部分を示す図である。 セッション終了におけるメッセージフローのための第２の部分を示す図である。 最大割当てモデルを用いる帯域幅割当てを示す図である。 最大割当てモデルに関する更なる詳細を示す図である。 ロシア人形モデルを用いる帯域幅割当て手順を示す図である。 仮想ネットワーク内プリエンプションのための手順を示す図である。 仮想ネットワーク間プリエンプションに関する詳細を示す図である。 プリエンプションシーケンスの第１の実施態様を示す図である。 プリエンプションシーケンスの更なる実施態様を示す図である。

図１はネットワークシステム１００を示す図である。そのネットワークシステムは、発信元端末１５０又は宛先端末１５２等の２つの端末間のセッションのためのデータをトランスポートする物理トランスポートネットワーク１２０を備える。さらに、そのネットワークシステムは、発信元端末１５０と物理トランスポートネットワーク１２０との間に接続されるアクセスコントローラ１７０を備える。アクセスコントローラ１７０は、記憶装置１７１に記憶されたデータレコードを用いて、第１の仮想ネットワークにおける第１のセッションの開始及び第２の仮想ネットワークにおける第２のセッションの開始を制御するように構成され、このデータレコードは、仮想ネットワークごとに、この仮想ネットワークのための利用可能帯域幅に関する情報を含む。それゆえ、アクセスコントローラは常に、物理トランスポートネットワーク上で動作する各仮想ネットワークが依然として利用可能帯域幅を有するか否かの概観を有する。例えば、１つの仮想ネットワークのための新たなセッション要求の結果として、現在使用している帯域幅と合わせて、全帯域幅が利用可能帯域幅より広くなるとき、アクセスコントローラはこの仮想ネットワークのためのこのセッション要求を拒否することになる。一方、他の仮想ネットワークのための利用可能帯域幅が依然として存在するとき、これは、第１の仮想ネットワークのユーザが拒否されることにより第２のネットワークのユーザを受け入れる余地が依然としてあり、このため限られた帯域幅リソースを用いて１つの同じ物理トランスポートネットワーク上で動作している２つの異なる仮想ネットワークが実際には分離されていることを意味する。したがって、各仮想ネットワークは、仮想ネットワークごとの単一のサービス品質クラス又は複数のサービス品質クラスのいずれかに必要とされるサービス品質を保証することができる。

図２に示されるように、物理ネットワーク１２０は、複数のトランスポートサービス品質クラスを提供するように実現される。さらに、ネットワークシステムは、第１の仮想ネットワーク１２１に複数のサービス品質クラスを提供し、第２の仮想ネットワーク１２２にも複数のサービス品質クラスを提供するように実現される。さらに、それぞれが複数のサービス品質クラスを有する複数の仮想ネットワークを備える図２の実施態様において、図１のアクセスコントローラ１７０内のデータレコードは、仮想ネットワークごとに、サービス品質ごとの利用可能帯域幅に関する情報を含み、重要なことには、最大帯域幅の和は、対応するトランスポートサービス品質クラスの最大帯域幅よりも小さい。言い換えると、トランスポートサービス品質クラスが、ＱｏＳクラス０に対して２０の（正規化された）帯域幅と、ＱｏＳクラス１に対して４０の帯域幅とを与えるときに、第１の仮想ネットワークのＱｏＳクラス１及び第２の仮想ネットワークのＱｏＳクラス１が最大で４０を消費する場合があり、第１の仮想ネットワークのＱｏＳクラス０及び第２の仮想ネットワークのＱｏＳクラス０が最大の状況において２０を消費することができる。それゆえ、図２の実施形態では、各仮想ネットワークは、少なくとも２つ、最大でトランスポート物理ネットワークと同じ数のＱｏＳクラスを有するように実現され、各仮想ネットワーク内の同じＱｏＳクラスのための帯域幅の和は物理トランスポートネットワーク内の対応するＱｏＳクラスの帯域幅以下である。

好ましくは、図３に示されるように、データレコード又はメモリ記憶場所１７１は記憶されたテーブルを含む。記憶されたテーブルは、仮想ネットワークごとに、仮想ネットワーク識別情報１７１ａ、サービス品質クラス識別情報１７１ｂ、１７１ｃにおいて示されるサービス品質クラスごとの全帯域幅に関する情報、及びサービス品質クラスごとに現在利用可能な、又は現在使用されている帯域幅に関する情報１７１ｄを有する。さらに、記憶されたテーブルは、仮想ネットワークのための情報を記憶するだけでなく、物理トランスポートネットワークのための情報、すなわち、物理トランスポートネットワークのＱｏＳクラス１及び物理トランスポートネットワークのＱｏＳクラス２内に、又は更なるＱｏＳクラス内にどの程度の利用可能帯域幅があるかに関する情報も記憶する、１７２において示される更なるデータレコードを含むことが好ましい。当然、本発明は、仮想ネットワーク又は仮想ネットワークＱｏＳクラスだけに限定されるのではなく、利用可能帯域幅及び仮想ネットワークごとの帯域幅に関する対応する要件の限度内で、仮想ネットワークの数及び仮想ネットワークごとのＱｏＳクラスの数を選択することができる。基本的に、アクセスコントローラは、物理トランスポートネットワークのサービス品質ポリシー、物理トランスポートネットワークによってサポートされるサービス品質クラスに関する情報を含むサービス品質ポリシー、及び物理トランスポートネットワークのサービス品質クラスごとの利用可能帯域幅に関する情報を記述する更なるデータレコード１７２を保持するように構成される。それゆえ、仮想ネットワークによって用いられるＱｏＳクラスは、物理ネットワークによって規定されるＱｏＳクラスに従わなければならない。

図４は、セッション確立要求を取り扱うための概要の流れ図を示す。詳細には、アクセスコントローラは、図４に示される手順を実行するように構成される。詳細には、図１のアクセスコントローラ１７０は、図１の発信元端末１５０からセッション確立要求を傍受するように構成される（１７３）。セッション確立要求は、第１の仮想ネットワークを識別する仮想ネットワーク識別情報、この新たなセッションに必要とされる帯域幅、及び必要とされるサービス品質クラスを含む。その後、アクセスコントローラ１７０は、このセッション及び必要とされるサービス品質クラスに必要とされる帯域幅が利用可能であるか否かをチェックする（１７４）。これをチェックするために、アクセスコントローラは記憶装置に記憶されるデータレコード１７１にアクセスし、現在の帯域幅エントリを、セッション確立要求において特定された具体的な仮想ネットワーク及びセッション確立要求において更に特定されたサービス品質クラスの場合に必要とされる帯域幅エントリと比較する。

それゆえ、図４は、セッション確立要求をトランスポート／トンネリングドメインに転送する一般的な概念を規定する。更なる実施形態では、入口ＬＥＲの要素管理システムへのコマンドラインインターフェースを通してそのような機構を直接実行することが好ましい。

結局、十分な帯域幅が利用可能であることがわかったとき、すなわち、ブロック１７４が「イエス」で終了するとき、そのセッション確立要求は図１の物理トランスポートネットワーク１２０に転送される（１７５）。

しかしながら、必要とされる仮想ネットワーク及びこの仮想ネットワークのサービス品質クラスのために十分な帯域幅が利用可能でないと判断されるとき、ブロック１７６が実行され、図４に示されるように、特に図１６ａ、図１６ｂ（仮想ネットワーク内プリエンプション）又は図１７（仮想ネットワーク間プリエンプション）に関して後に論じられるように、自らの仮想ネットワーク内でのみ、又は異なる仮想ネットワーク間でプリエンプションアルゴリズムを実行することができる。当然、複雑でないシステムでは、プリエンプションを全く実行することはできないが、セッション確立要求を単に拒否することができるか、又はセッション確立要求を一定期間保留にすることができる。この場合、このことは、セッション確立要求に更に含まれる情報を用いて発信元端末に通知されなければならない。

新たなセッションに成功した場合、アクセスコントローラ１７０は、以前に転送しているセッション確立要求に応答して受信されるセッション確立応答を傍受するように更に構成される。傍受されたセッション確立応答を考慮して、アクセスコントローラは、仮想ネットワーク及びサービス品質クラスのための利用可能帯域幅をこのセッションに必要とされる量だけ削減することにより、データレコードを更新する。これは、セッション確立応答から、このセッションによって消費される帯域幅を指示する情報を検索することによって果たすことができるか、又はセッション確立要求に含まれる必要とされる帯域幅を記憶し、その後、新たなセッションのために消費される帯域幅を見いだすために、受信されたセッション確立応答を対応するセッション確立要求と照合することによって果たすことができる。その後、データレコード内のこの仮想ネットワークのための利用可能帯域幅は、新たなセッション及びサービス品質クラスに必要とされる帯域幅を減算することによって新たに計算され、その際、アクセスコントローラは再び、更なるセッション確立要求を傍受する準備ができている。当然、セッション終了の場合、そのようなセッション終了通信も図１のアクセスコントローラ１７０によって傍受することができ、それによって、アクセスコントローラは、利用可能帯域幅の量を終了したセッションの量だけ、すなわち、この量は再び空きであるので、増加させることによって、データレコードを再び更新することができる。その代わりに、又はそれに加えて、セッションは所定の存続時間を与えられ、セッションがリフレッシュされない場合、そのセッションは終了される。これは、例えば、ネットワークコントローラ等によってシグナリングすることもできるが、代替的には、アクセスコントローラは、データレコード内に存続時間と、或る特定のセッションがリフレッシュされたか否かの指示とを保持することもでき、それによって、アクセスコントローラは、以前の既存のセッションが意図的に又はタイムアウトによって終了されたときに利用可能帯域幅を増加させることによって、データレコードを自動的に更新することができる。

図５は、アクセスコントローラ１７０及び物理トランスポートネットワーク１２０を備えるネットワークシステムの更に詳細な実施形態を示す。詳細には、物理トランスポートネットワークは、複数のラベルエッジルータ１２５、１２６と、複数のラベルスイッチルータ１２７、１２８とを備える。ラベルエッジルータだけが物理トランスポートネットワークからの入口点／出口点を与え、それゆえ、アクセスコントローラ１７０は、ラベルエッジルータ１２５、１２６に接続されるが、ラベルスイッチルータ１２７、１２８等には直接接続されない。さらに、物理トランスポートネットワークは、分散型又は集中型として実現することができるコントローラを備え、このコントローラ１２９は、ネットワーク管理システム／運用支援システム（ＮＭＳ／ＯＳＳ）として動作する。コントローラ１２９は、アクセスコントローラ１７０への接続を有するように構成され、このコントローラは、１３０、１３１において示される、異なる仮想ネットワークコントローラＶＮ１、ＶＮ２に接続することもできる。詳細には、コントローラ１２９は、トンネリングドメイン、すなわち、ＬＥＲ及びＬＳＲと、対応する接続とによって構成されるドメインにおけるサービス品質ポリシーを初期化するように構成される。さらに、コントローラ１２９は、トランスポートネットワークＱｏＳポリシー等のデータレコード上の情報をアクセスコントローラに与えることによって、アクセスコントローラ１７０を構成するようになっている。

さらに、１３０及び１３１において示されるように、そのネットワークは、第１の仮想ネットワークのための第１の仮想ネットワークコントローラと、第２の仮想ネットワークのための第２の仮想ネットワークコントローラとを更に備え、各仮想ネットワークコントローラは、特定の仮想ネットワークのための利用可能帯域幅に関する情報をデータレコード内に保持するようにコントローラ又はアクセスコントローラに指示するようになっている。

図６は、アクセスコントローラ１７０の実施態様を更に示す。詳細には、アクセスコントローラは、メモリ／記憶データレコード１７１を備え、さらに、この実施態様では、プロセッサ／制御ユニット１７９と、アクセスコントローラの入力及び出力を接続するプログラマブルスイッチ１７８とを備える。プロセッサ／制御ユニット１７９は、到来するセッション確立要求又は到来するセッション終了要求等の、プログラマブルスイッチにおいて受信されるメッセージを傍受するように構成される。さらに、プロセッサ１７９は、利用可能帯域幅の場合にセッション許可を実行するように、又はプリエンプションアルゴリズムを実行するように、又は異なるプリエンプションコントローラから受信される命令を実際に実行するように構成される。

さらに、プロセッサ／制御ユニットは、データレコード１７１を用いて、第１の仮想ネットワークにおける第１のセッションの開始、及び第２の仮想ネットワークにおける第２のセッションの開始を制御し、データレコードは、仮想ネットワークごとに、対応する仮想ネットワークのための利用可能帯域幅に関する情報を含む。

次に、図８を参照すると、既存ネットワークのシナリオの状況が示される。通常、ＭＡＭ（最大割当てモデル）又はＲＤＭ（ロシア人形モデル）等のＭＰＬＳ帯域幅制約モデルは、特定のサービス品質クラスのための利用可能帯域幅に基づいてトラフィックを許可する。しかしながら、そのようなモデル／ネットワークは、このトラフィックがどの仮想ネットワーク（ＶＮ）から到来しているかを区別する能力を備えていない。１つの仮想ネットワークからのトラフィックが別の仮想ネットワークのリソースに入るのを許可される場合がある状況が起こり得る。通常、複雑でない物理トランスポートネットワーク１２０のシナリオであるそのようなシナリオは、この実施態様において、テーブルに示されるようなＱｏＳクラスＣ０〜ＣＮを許す。再び、図示されるようなラベルエッジルータ（ＬＥＲ）及びラベルスイッチルータ（ＬＳＲ）を備えるＭＰＬＳスイッチングドメインが、ユーザ機器１５０及びユーザ機器１５１等の幾つかのユーザ機器において示される。具体的には、２つの異なる仮想ネットワーク内で動作するように構成される、１５２及び１５３等の特定のユーザ機器が存在する。

一例として、図９を参照すると、Ｃ１＝１０のためのＭＰＬＳドメイン最大帯域幅が存在し、利用可能帯域幅はその時点で３であり、第１の仮想ネットワークの場合、Ｃ１最大帯域幅が６に等しく、それゆえ、利用可能帯域幅は０に等しい。別の仮想ネットワークＣ１ ＱｏＳクラスの場合、最大帯域幅は４であり、利用可能帯域幅は３である。その際、第２の仮想ネットワークのみからの帯域幅３のＣ１トラフィックは許可されるべきであり、第１の仮想ネットワークからのＱｏＳクラスＣ１におけるトラフィックは拒否されるべきである。しかしながら、ＭＰＬＳは、ＱｏＳクラスがＣ１であり、トラフィックが３を超えない限りトラフィックを許可することができ、そのトラフィックがどの仮想ネットワークから到来するかは重要ではない。それゆえ、本発明は、図９に示されるように、アクセスコントローラを設けることによってこの問題に対処する。略述されるように、コアトランスポートネットワーク又は物理トランスポートネットワーク１２０は、１つ又は複数のラベルスイッチングベーストランスポート、例えば、マルチプロトコルラベルスイッチング（ＭＰＬＳ）スイッチングドメインからなることができる［１２］、［１０］。この物理トランスポートネットワークは、「トンネリングドメイン」（ＴＤ）とも呼ばれる。さらに、例えば、図９に示されるアクセスコントローラ１７０は、ＬＥＲのような、トンネリングドメインへの入口点に取り付けられ、ＬＥＲはＭＰＬＳラベルエッジルータである。アクセスコントローラ１７０は２つの機能を有することができる。アクセス制御モジュール（ＡＣＭ）機能、及びプログラマブルスイッチ（ＰＳ）によるセッションデータのスイッチングの機能である。ＡＣＤはＡＣＭとＰＳとの間のオープンフロープロトコル［４］等を用いることによって、ソフトウェア定義ネットワーク（ＳＤＮ）［５］ドメインとして実現することができる。

次に、集中型ＮＭＳ／ＯＳＳを示す図１０ａ及び分散型ＮＭＳ／ＯＳＳコントローラを示す図１０ｂが論じられる。トランスポートネットワークの初期設定及び構成が、図５に既に示されているネットワーク管理システム／オペレーティングシステムサポートコントローラ１２９によって行われる。図１０ａのシナリオでは、ＴＤ及びＡＣＤドメインは単一の管理ドメイン内に含まれ、それゆえ、その管理は、単一のネットワーク管理システム（ＮＭＳ）／運用支援システム（ＯＳＳ）によって実行することができる。図１０ｂの他の実施態様では、「マルチアドミン」構成であり、ＴＤ及びＡＣＤドメインがそれぞれ自らの管理を有し、それゆえ、複数のＮＭＳ／ＯＳＳが関与する。それゆえ、アクセスコントローラ１７０及びコントローラ１２９が図５において別々の要素として示される場合であっても、それら２つの要素は１つの同じコントローラインスタンスを用いて実現することもできる。それゆえ、例えば、図５における例示及び他の図における例示は、好ましい実施態様以外の機能を示すと理解されるべきである。当然、全ての機能が単一のワークステーションにおいて、又は異なる場所に位置する複数のワークステーションにおいて実際にどのように実現されるかは設計上の問題である。

「直接の」事例では、メッセージがプログラマブルスイッチを通して送信され、「セッション確立」メッセージ及び「セッション終了」メッセージは「制御プレーン」に属し、これらのメッセージはＴＤの入口ルータ（ＬＥＲ）の制御／管理エージェントに実際に送信されることになる。好ましくは、ＡＣＭとＭＰＬＳ ＬＥＲとの間にコマンドラインインターフェース（ＣＬＩ）が設けられ、それにより、その後、ＡＣＭはＬＥＲに要求を出すことができる。それゆえ、アクセスドメインコントローラがセッション確立要求を受信するとき、アクセスドメインコントローラは、コマンドラインインターフェース等のトンネリングドメインの入口エッジルータに向かう接続を開始し、経路設定シグナリングをトリガする（例えば、ＭＰＬＳ ＬＥＲがＲＳＶＰ−ＴＥメッセージを送出し始める）。

それゆえ、ＭＰＬＳドメインにおける経路確立がトリガされる。通常、ＭＰＬＳによれば、これはＬＥＲに向かうベンダ特有のユーザネットワークインターフェースを用いて行われ、それゆえ、ＳＥＲはそのような特有のメッセージとすることができる。しかしながら、ＳＥＲとして異なるものを（例えば、ビデオセッションの開始パケットだけを）送信する事例もあり得る。この場合、オープンフローコントローラ自体がＭＰＬＳ ＬＥＴにデータを送信し、経路設定をトリガすることができる。

そのシナリオにおいて独立して、異なるドメインのサービス品質設定を構成し、異なる構成を協調させる必要がある。このために、最初に、ＴＤドメインのＱｏＳポリシーが設定され、その後、この情報がＡＣＤドメインにも転送される。これにより、ＡＣＤドメインは、ＡＣＤドメインが接続されるＴＤドメインのＱｏＳポリシーについて学習できるようになり、したがって、結果として略述されたように協調する。利用されるシナリオに応じて、構成ステップも異なる場合がある。図１０ｂの実施態様の場合、最初の構成ステップが矢印１によって視覚化される。ここで、ＮＭＳ／ＯＳＳはＴＤドメインのための全体的なＱｏＳポリシーを構成する。この品質の構成は以下のものを含む。
帯域幅（ＢＷ）割当てモデル：「最大割当て帯域幅制約モデル」（ＭＡＭ）［６］又は「ロシア人形帯域幅制約モデル」（ＲＤＭ）［７］等をここで適用することができる。
サポートされることになるＱｏＳクラスの総数。
ＱｏＳクラス（ＲＤＭの場合、クラスの組み合わせ）ごとに割り当てられることになる帯域幅（ＢＷ）の量。
用いられるＱｏＳクラス識別方式、すなわち、ＥＸＰ［１０］又はラベル等。
非ＴＤ ＱｏＳクラスとＴＤスイッチングドメインのＱｏＳクラスとの間のマッピング。

ＮＭＳ／ＯＳＳがＴＤドメインを設定した後に、ＮＭＳ／ＯＳＳは、以下の情報を用いて第２のステップ（矢印２を用いて視覚化される）においてＡＣＤドメインを構成する。
ＴＤドメインによって用いられるＢＷ割当てモデル、すなわち、ＭＡＭ又はＲＤＭ等。
サポートされるＱｏＳクラスの総数。
クラス（ＲＤＭの場合、クラスの組み合わせ）ごとの帯域幅の最大量。
ＲＤＭ帯域幅割当てモデルが用いられる場合：何がプリエンプションポリシーであるか。
さらに、ＮＭＳ／ＯＳＳは、ＱｏＳクラスごとに、又はＱｏＳクラスの組み合わせごとに現在どの程度のＢＷが利用可能であるかを、定期的に又はコントローラからの要求に応じてＡＣＤに知らせることができる（そのような場合、ＴＤスイッチングドメインはこの情報をＮＭＳ／ＯＳＳ定期的に、又はＮＭＳ／ＯＳＳからの要求に応じて与える）。それゆえ、ＢＷ情報はＴＤドメインからＮＭＳ／ＯＳＳによって与えられるか、又は
さらに、ＴＤスイッチングドメインが、ＱｏＳクラス／ＱｏＳクラスの組み合わせごとの現在のＢＷ利用可能性について、定期的に又はＡＣＤからの要求に応じて、ＡＣＤに知らせることができる。それゆえ、ＴＤドメインが、他の手段を通して（ＮＭＳ／ＯＳＳを通してではなく）、この情報を提供する。

図１０ｂに示されるマルチアドミンシナリオでは、ＮＭＳ／ＯＳＳｘによるＴＤの構成は、シングルアドミンシナリオのための構成に従う。これらのシナリオの違いは、ＴＤとＡＣＤとの間の協調にある。ＡＣＤが別の管理下（ＮＭＳ／ＯＳＳｙ、ｚ、．．．）にあるので、これが必要である。２つのシナリオ、すなわち、ＴＤ−ＡＣＤの直接インタラクション、又はそれぞれのＮＭＳ／ＯＳＳを通したインタラクションが可能である。

ＮＭＳ／ＯＳＳ間のインタラクション
独立したＮＭＳ／ＯＳＳｘ，ｙ，ｚは、その間にインターフェース（Ｉ／Ｆ）を有し（図１０ｂ、矢印２．ａ）、以下の情報を交換することができ、その後、それぞれのＡＣＤに向かって伝えることができる（矢印３）。
・最大割当てモデル（ＭＡＭ）又はロシア人形モデル（ＲＤＭ）等の帯域幅（ＢＷ）モデル。
・サポートされるＱｏＳクラスの数。
・クラス（ＲＤＭの場合、クラスの組み合わせ）ごとの最大ＢＷ。
・ＲＤＭの場合、何がプリエンプションポリシーであるか（オプションで、ＳＤＮドメインがプリエンプションポリシーを独立して決定することができる）。
・さらに、ＮＭＳ／ＯＳＳｘが、ＱｏＳクラスごとに、又はＱｏＳクラスの組み合わせごとに現在どの程度のＢＷが利用可能であるかを、定期的に又はコントローラからの要求に応じてＳＤＮドメインＮＭＳ／ＯＳＳｙ，ｚに知らせることができる（そのような場合、ＭＰＬＳスイッチングドメインはこの情報をＮＭＳ／ＯＳＳｘに定期的に、又はＮＭＳ／ＯＳＳｘからの要求に応じて与える）。
この場合には、ＮＭＳ／ＯＳＳｙ，ｚはこの情報を、その管理下にあり、本特許において論じられているＭＰＬＳドメインに接続されるＡＣＤコントローラに中継する。

ＴＤ−ＡＣＤの直接インタラクション
以下の情報をＴＤとＡＣＤとの間で直接交換することができる（図１０ｂ、矢印２．ｂ）。
・ＭＰＬＳドメインのＢＷ割当てモデル、すなわち、ＭＡＭ又はＲＤＭ等。
・サポートされるＱｏＳクラスの数。
・クラス（ＲＤＭの場合、クラスの組み合わせ）あたりの最大ＢＷ
・ＲＤＭの場合、何がプリエンプションポリシーであるか（オプションで、ＡＣＤがこれを独立して決定することもできる）
・ＴＤは、ＱｏＳクラス／クラスの組み合わせごとに現在どの程度のＢＷが利用可能であるかを、定期的に又はＡＣＤからの要求に応じてＡＣＤに知らせることができる。

要約すると、上記のプロトコルを通して、ＡＣＤは、ＡＣＤが接続されるＴＤのＱｏＳポリシーを発見することができる。

それゆえ、要約すると、図１０ａ及び図１０ｂの手順によれば、３つの主な特徴が可能である。第１の特徴は、帯域幅制約モデル、サポートされるＱｏＳクラスの数及びＱｏＳクラスの種類、並びにＱｏＳクラスごとに利用可能な最大帯域幅を含む、ＱｏＳポリシーの設定である。第２の特徴は、帯域幅制約モデル、サポートされるＱｏＳ数及びクラス、並びにＱｏＳクラスの利用可能な最大帯域幅及び仮想ネットワーク確保情報を含む、トンネリングドメインＱｏＳポリシーの伝達である。第３の特徴は、帯域幅制約モデル、サポートされるＱｏＳクラスの種類、並びにＱｏＳクラスのための最大帯域幅を含む、仮想ネットワーク確保要求である。ＱｏＳクラスのための例を、例えば、ＤＥＳ−ＴＥ又はＭＰＬＳ−ＴＥにおいて見いだすことができる。

次に、図９を再び参照する。図９は、物理トランスポートネットワーク１２０及び複数のアクセスコントローラ１７０を備えるネットワークシステムを示す。詳細には、データレコードが例示されており、幾つかの端末が存在し、例えば、端末１５２は、第１の仮想ネットワーク１及び第２の仮想ネットワーク２の両方の仮想ネットワークをサポートし、同じことが端末１５３にも当てはまり、全ての他の端末は、この例では、仮想ネットワーク１のみをサポートし、言い方を変えると、仮想ネットワーク１に登録される。データレコード１７１は、仮想ネットワークごとに、Ｃ０及びＣ１等のＱｏＳクラスごとの識別子と、クラスごとの最大帯域幅及び現在の利用可能帯域幅とを示す。代替的には、現在使用されている帯域幅及び最大帯域幅から利用可能帯域幅を計算できるように、現在使用されている帯域幅も指示することができる。

さらに、更なるデータレコードはＱｏＳクラスＣ０及びＱｏＳクラスＣ１のための情報を含み、これが全てアクセスコントローラ１７０に記憶される。両方の仮想ネットワーク内のＱｏＳクラスＣ０のための最大帯域幅は、更なるデータレコード１７２内のトランスポートネットワークのＱｏＳクラスの最大帯域幅に等しいこと、及び同じことが第１のＱｏＳクラスＣ１にも当てはまることが図９の例から明らかである。さらに、利用可能帯域幅の総計は、各サービス品質クラスにおける利用可能帯域幅の和に対応する。それゆえ、物理トランスポートネットワークの異なるＱｏＳクラスのための帯域幅は、図１０ａ及び図１０ｂにおいて論じられるような、ＮＭＳ／ＯＳＳによって決定されるＱｏＳポリシーに従って、仮想ネットワーク及び対応するＱｏＳクラスに分けられる。

ここで、ＡＣＤ及びＴＤを介してデータを送信するための異なるネットワーク要素間での詳細なインタラクションが論じられる。図１２に示されるように、ＡＣＤに接続される幾つかの発信元／宛先対間でデータ通信が行われる。仮想ネットワーク２（ＶＮ−２）の発信元がセッションを開始したいとき、その発信元は、このセッションが必要とするＢＷ及びそのＱｏＳクラスに関する情報を含むセッション確立要求をその所望の宛先に送信する。このセッション確立要求はＰＳによって傍受され、そのＡＣＭに転送される。ＡＣＭは、ＴＤドメイン内でサポートされる全てのＱｏＳクラスのために、どの程度のＢＷが利用可能であるかを示すテーブル（異なるＢＷ割当てモデルについて以下で説明する）を保持する。コントローラがこの情報を有しない場合には、コントローラは、このＱｏＳクラスのための利用可能ＢＷに関する情報を提供するようにＰＳ又はＴＤに求める。そこからセッション確立要求が到着したＶＮ−２のために十分なＢＷが利用可能である場合には、ＡＣＭは、このセッションを許可するようにＰＳに求める（すなわち、このセッション確立要求をＴＤに転送し、ＰＳがセッションの結果データ（例えば、パケット）のためにすることを指示する「フローエントリ又はセッションエントリ」を開く。この場合、「フローエントリ」は、結果データをＴＤに転送するように指示するであろう）。ＴＤは、本発明が影響を及ぼされない自らの許可制御手順を有することができる。

セッション確立要求はＴＤを通って宛先まで進む。成功する場合には、発信元にセッション確立応答が返送される。これは、このセッションのためにＴＤにおいてリソースを確保するのに成功したことを指示する。ＰＳはこのセッション確立応答を傍受し、それを発信元に転送する前に、ＡＣＭに伝達することができる。この新たなセッションに対してそのテーブルを更新したＡＣＭは、この時点で、その更新、及び「セッションエントリ」のためにＰＳに送信した命令が有効であることを確信することができる。セッション確立応答が一定の時間内に受信されない場合には、関連するテーブルエントリ（ＱｏＳクラスのＢＷ情報）が、セッション確立要求が到着する前の状態にロールバックことになる。また、ＡＣＭは、この特定のセッションのための「フローエントリ」を除去するようにＰＳに指示する。

この仮想ネットワークのために十分なＢＷが利用可能でない場合、ＡＣＭの応答は、ＴＤドメインによって選択された帯域幅制約モデルによって決まる。

ＭＡＭが選択された場合には、コントローラは、このセッションを破棄するようにスイッチに指示し、すなわち、セッション確立要求がＴＤドメインに転送されない。さらに、ＡＣＭは、ＰＳを通して、「リソース利用不可」メッセージを発信元に返送することができる。

ＲＤＭが選択された場合には、コントローラは、「プリエンプション」が必要であるか否か、すなわち、低い優先順位を有するＴＤセッションを破棄することができるか否かをチェックする必要がある。プリエンプションの詳細は、後にＲＤＭセクションにおいて説明されることになる。

図１３ａ及び図１３ｂは、セッションを許可するためのメッセージフローを更に詳細に示す。１３００において示されるように、発信元は、仮想ネットワークＩＤ、ＱｏＳクラス、オプションの指標としての優先レベル及び必要とされる帯域幅を有するセッション確立要求をアクセスコントローラに、そして例示的には、アクセスコントローラのプログラマブルスイッチＰＳに送信する。このセッション確立要求は傍受され（１３０１）、アクセスコントローラの制御ユニットに転送される。制御ユニットはそのセッションを許可するか、又は許可しない。セッションが許可される場合には、セッション確立要求は、１３０２において示されるように、プログラマブルスイッチＳＷに転送される。その後、この情報は、１３０３によって示されるように、プログラマブルスイッチによってトンネリングドメインに転送される。その際、トンネリングドメインは、そのセッションを許可するか、許可しないかのいずれかである。トンネリングドメインがそのセッションを許可する場合には、１３０４において示されるように、セッション確立要求は宛先に転送される。その後、１３０５において示されるように、セッション確立応答がアクセスコントローラを介して宛先から発信元に返送される。代替的には、セッション確立応答は、１３０６においてプログラマブルスイッチに転送され、プログラマブルスイッチによって傍受され、１３０７において示されるようにデータレコードを更新するために制御ユニットに転送され、それと同時に、又はその後に、１３０８において示されるように発信元に転送される。そのセッションが終わったとき、発信元はセッション終了要求を送信することができ（１３０９）、その後、セッション終了要求はプログラマブルスイッチ１３１０によって傍受され、その際、アクセスコントローラの制御ユニットは、１３１１において示されるように、図９のテーブル１７１及び１７２に提示されるデータレコードからの確保情報を更新する。その後、セッション終了要求は、１３１２において略述されるように、プログラマブルスイッチＰＳを通してトンネリングドメインに送信され、その後、１３１３において示されるように、宛先に転送される。その後、宛先は、１３１４において示されるように、セッション終了応答によって応答する。アクセスコントローラがセッションを許可しない、すなわち、図１３ａのそのブロックにおいて「ノー」によって応答する状況の場合、セッション破棄メッセージ１３１５がアクセスコントローラの制御ユニットからプログラマブルスイッチに転送され、１３１６において示されるように、リソースが利用不可であるという情報が発信元に送信される。しかしながら、トンネリングドメインが、図１３ａの右側において示されるように、何らかの理由のためにセッションが許可されないと判断するとき、これは、１３１７において示されるように、トンネリングドメインから発信元にシグナリングされる。

次に、仮想ネットワーク設定（ＶＮ全体ＱｏＳクラス確保）が論じられる。このために、最大割当てモデルに関して図１４ａ及び図１４ｂを、ロシア人形モデルに関して図１６を参照する。

ＴＤの最大割当てモデル（ＭＡＭ）では、ＱｏＳクラスあたりのＢＷが固定される［６］。図１４ａは、ＴＤ入口点、例えば、ＡＣＤに接続されるＭＰＬＳラベルエッジルータ（ＬＥＲ）内に構成される３つのＱｏＳクラス、すなわち、Ｃ０、Ｃ１及びＣ２の一例を示す。ＴＤドメインによってサポートされるＱｏＳクラスの数は、ＡＣＤが提供することができるＱｏＳクラスに関する上限を強要することに留意されたい。この例では、仮想ネットワークは多くても３つ、すなわち、Ｃ０〜Ｃ２又はこれらのＱｏＳクラスのうちの幾つかしか得ることができない。

事例１：ＭＰＬＳ ＱｏＳ確保があらかじめ決定される
この場合、ＱｏＳクラスの数（この例ではＣ０〜Ｃ２）及びクラスあたりの最大ＢＷがＴＤにおいてあらかじめ決定されると仮定される。したがって、ＶＮからの要求は、ＴＤドメインにおける設定の範囲内で受け入れられなければならない。

ＴＤスイッチングドメインからのリソースを要求する３つのＶＮが存在する。ＶＮ（ＶＮはその自らのＮＭＳ／ＯＳＳを有することになるので、このＶＮネットワーク設定要求は、ＶＮのＮＭＳ／ＯＳＳから到来することになる）は、ＱｏＳクラス及び必要とするＱｏＳクラスあたりのＢＷを提示する（例えば、ＶＮ−２の場合、クラスごとの必要とされるＢＷとともにＣ０（ＶＮ−２）、Ｃ１（ＶＮ−２）及びＣ２（ＶＮ−２）が提示される（図１４ａの左側における確保））。この要求を受信するＡＣＭは、図１４ｂのそのＶＮ状態テーブル（テーブル１）を調べ、この要求を満たすことができるか否かを確認する。必要とされるＢＷはＣ０、Ｃ１、Ｃ２、すなわち、ＶＮ−２要求到着時においてＴＤドメイン内で利用可能な最大ＢＷ以下でなければならない。以前に受け入れられたＶＮ、例えば、ＶＮ−０及びＶＮ−１が存在する場合には、ＶＮ−２の必要とされるＢＷは、それぞれのＱｏＳクラスの残りのＢＷ以下でなければならない。十分なＢＷが利用可能でない場合には、ＡＣＭは新たなＶＮ要求、すなわち、この例ではＶＮ−２を受け入れない。ＡＣＤは、どのＱｏＳクラスのためのＢＷが利用不可であるかを提示する、「リソース利用不可」メッセージを発行することができる。対応するＶＮはその要件を緩和して、再びＡＣＤに求めることができる。ＶＮからのＢＷ要求と、ＴＤによって与えられるＢＷへのマッピングとの関係が図１４ａに示された。

ＡＣＭによって用いられるテーブルの概要が図１４ｂにおいて与えられる。

ＡＣＭは、そのＮＭＳ／ＯＳＳによって、又は人手が介在することによって、又はＶＮからの情報に基づいて、以下のものを識別する能力を備える必要がある。
・ＶＮ：ＩＰアドレス、ＩＰネットワークプレフィックス、具体的に規定されるＶＮ ＩＤ、Ｌ２アドレス、Ｌ２．５アドレス、ＩＰポート等、又はこれらの組み合わせ。
・ＱｏＳクラス：ＩＰポート、ＩＰサービスタイプ（ＴＯＳ）ビット、Ｌ２ＱｏＳビット、Ｌ２タグ、ＭＰＬＳラベルの内容、例えば、ＥＸＰビット又はラベル自体。
・ＴＤドメインがサポートするＱｏＳクラスごとにＴＤドメインによって与えられる全ＢＷ：このＡＣＭが接続されるＮＭＳ／ＯＳＳによるか、又はＴＤドメインからの直接広告による。
・利用可能ＢＷ（現時点で特定のＱｏＳクラスのためにどの程度のＢＷが利用可能であるか）：このＡＣＭが接続されるＮＭＳ／ＯＳＳによって、又はＴＤドメインからの直接広告によって、又は許可を要求するこのセッションのＱｏＳクラス（又は他の１つ又は複数のＱｏＳクラス）によって現時点でどの程度のＢＷが消費されているかに関して、セッションの入口点であるＰＳに尋ねることによって通知される。

このテーブルは、定期的に、又は関連するイベントの発生時に、例えば、新たなセッションのための許可要求、セッションの終了等の発生時にリフレッシュされる。

事例２：ＴＤドメインＱｏＳ確保がＶＮ確保要求に基づいて行われる
ＴＤドメイン自体におけるＢＷ割当ては、到来するＶＮ確保要求によって決定することができる。この場合、ＶＮ確保要求はＡＣＭに達する。ＡＣＭは、どのＱｏＳクラスをサポートする必要があるか、及びＱｏＳクラスあたりどの程度のＢＷが利用可能であるかをＴＤドメインに尋ねる。例えば、図１４ａにおいて、ＶＮ要求到着順序がＶＮ−０→ＶＮ−１→ＶＮ−２であると仮定しよう。それゆえ、Ｃ０（ＶＮ−０）、Ｃ１（ＶＮ−０）、Ｃ２（ＶＮ−０）の３つのＱｏＳクラスのためのＶＮ−０要求と、クラスごとに必要とされるＢＷとを受信すると、ＡＣＭは、ＴＤコンテキストにおいてこれら３つのＱｏＳクラス、すなわち、Ｃ０、Ｃ１及びＣ２をサポートし始めるように、かつＶＮ−０がこれらの３つのクラスのために要求したＢＷを確保するようにＴＤに求める（それぞれのＮＭＳ／ＯＳＳを通して、又は直接）。

例えば、同じくＣ０（ＶＮ−１）、Ｃ１（ＶＮ−１）、Ｃ２（ＶＮ−１）の３つのＱｏＳクラスと、クラスごとのＢＷとを要求するＶＮ−１の形の新たな要求が到着するとき、ＡＣＭは、ＶＮ−１の要求を満たすことができるように、ＴＤにＣ０、Ｃ１及びＣ２のクラスのためのＢＷを増やすように求める。ＶＮ−１が１つ又は複数の新たなクラスを要求する場合には、ＡＣＭは、そのような新たなクラスのためのサポートを開始するようにＴＤに求める。同じ動作がＶＮ−２又は更なる新たなＶＮ要求に対して実行される。

ＴＤがそのような要求を受け入れることができない場合には、ＴＤはＡＣＭに対して「不可」応答を発行し、そのように要求を受け入れることができない理由を明示することができる。そのような理由は、ＢＷが利用不可能であること、要求されたＱｏＳクラスをサポートできないこと、認証失敗のように管理ポリシーに適合しないこと、セキュリティ機構が一致しないこと、及び課金上の問題等とすることができる。

ＶＮ確保要求の存続時間はＡＣＭによって監視される。ＶＮが要求を取り消す場合には、又は要求の存続時間が満了する場合には、入口ＡＣＭは、このＶＮ確保に関連する「フローエントリ」を除去するようにＰＳに指示する。

さらに、ＡＣＭは、特定の確保を削除するために、ＴＤに取消要求を送信することができる。このようにして、確保の全体又はその一部（特定のＱｏＳクラスのＢＷの増加／減少、新たなＱｏＳクラスの追加）を変更する（取り消す、修正する）ことができる。

図１、図９、図１２に示されるように、ＰＳはＴＤの入口点／出口点に接続され、トラフィック発信元及び宛先はＰＳに接続される。特定のＶＮのトラフィック発信元がＴＤを介して新たなセッションを作成したいとき、発信元から所望の宛先にセッション確立要求が送信される。

次に、再び図９、図１０ａ、図１０ｂ及び図１１を参照する。これらの図において、更には図１にも示されるように、アクセスコントローラ、詳細には、プログラマブルスイッチは、トンネリングドメインへの入口点／出口点に接続され、トラフィック発信元及び宛先はプログラマブルスイッチに接続される。特定の仮想ネットワークのトラフィック発信元が、トンネリングドメインを介して新たなセッションを開始したいとき、発信元から所望の宛先にセッション確立要求が送信される。この要求がプログラマブルスイッチに到着するとき、その要求はプログラマブルスイッチのＡＣＭに転送される。

この要求がＰＳに到着するとき、その要求はＰＳのＡＣＭに転送される。セッション確立要求は所望のＱｏＳクラス及びこのセッションに必要なＢＷの量に関する情報を含む。ＡＣＭはそのＶＮ状態テーブル（Ｔａｂｌｅ）を調べ、この要求を受け入れるために、この特定のＶＮ及びＱｏＳクラスのための十分なＢＷが利用可能であるか否かをチェックする。
・十分な帯域幅が利用可能である場合には、ＡＣＭは、このセッション確立要求をＴＤに転送するようにＰＳに指示する。そこから、ＴＤは自らのセッション許可、転送、リソース確保手順［１〜３］、［８〜９］に従って、そのセッションを許可する責任を負う。決定を下したＡＣＭは、それに応じて、そのＶＮ状態テーブル（Ｔａｂｌｅ）を、具体的には、「利用可能ＢＷ」の列を更新する。そのような更新は、ＰＳにおいてセッション終了要求を傍受することによってセッションが終了され（その場合、「利用可能ＢＷ」が増加する）、ＡＣＭに転送される場合にも実行されることに留意されたい。
・要求されたセッションのための十分なＢＷが利用可能でない場合には、ＡＣＭは、セッション確立要求を破棄するようにプログラマブルスイッチに指示し、それゆえ、ＴＤには転送されない。さらに、ＡＣＭ自体が、拒否の理由を通知するためにセッション確立要求の発信元に「ＢＷ利用不可メッセージ」を発行するか、又は発行するようにＰＳに指示することができる。

別の実施形態では、ＰＳ自体が、ＰＳを経由するセッションのための統計データを保持することができる［４］。オプションとして、そのような新たなセッション確立要求がＡＣＭに到着するときに、ＡＣＭは、この特定のＶＮのこの特定のＱｏＳクラスのための「利用可能ＢＷ」に関する情報を送信するようにＰＳに求める。そのような場合、ＡＣＭにあるテーブル１において最も右側の列の「利用可能ＢＷ」を維持管理する必要はない。

さらに、ＰＳは、新たなセッション確立要求を受信すると、セッション確立要求自体を転送するとともに、又はセッション確立要求自体を転送することなく、特定のＶＮからのこのセッションの特定のＱｏＳクラスに関する利用可能ＢＷ情報を積極的に転送することができる。ＰＳがセッション確立要求自体をＡＣＭに転送しない場合には、ＰＳは、このセッション確立要求によってすべきことに関するコントローラに対する命令を受信するまで、そのメッセージをメモリに記憶する。

ロシア人形モデル（ＲＤＭ）（図１５）
ＭＡＭとは異なり、ＲＤＭでは、クラスの入れ子の組み合わせに対して帯域幅が割り当てられる［７］。例えば、図２５において、最も優先順位が高いクラスＣ０は全ＢＷのうちの２５％を割り当てられる。Ｃ１＋Ｃ０は合わせて５０％を得る。Ｃ０は、より高い優先順位を有するので、クラスＣ０を有するトラフィックが存在しない場合、Ｃ１は全５０％を使用することができる。しかしながら、Ｃ０は多くても２５％しか使用することができない。Ｃ０が１０％を使用しており、Ｃ１が４５％であり、かつＢＷの５％を必要とする新たなセッション確立要求が到着する場合には、これらが、より高い優先順位を有するときに新たなＣ０セッションを受け入れるために、Ｃ１の幾つかのセッションを削除して、５％のＢＷを解放する必要がある。割り当てられたＢＷ部分内で、より優先順位の高いセッションを受け入れるために、優先順位の低いセッションを削除するこの手順は「プリエンプション」と呼ばれる。現時点で、プリエンプションを実行する標準的な方法は存在せず、ベンダによって決まる方法において解決される。

図１６ａのテーブルは図１４ｂと比べてわずかに異なる。ここでは、「全ＢＷ」列が、クラスの組み合わせ（入れ子のクラス）ごとにどの程度のＢＷが割り当てられたかを記憶する。この例において、Ｃ０＞Ｃ１＞Ｃ２の優先順位を仮定すると、ＶＮ−０の場合、そのテーブルは、Ｃ０、Ｃ１＋Ｃ０及びＣ２＋Ｃ１＋Ｃ０の形で、このＶＮ−０に対して割り当てることができる（最初にＶＮの要求に基づいて確保された）全ＢＷに関するエントリを保持する。「利用可能ＢＷ」列は、特定のクラス、この例ではＣ０、Ｃ１及びＣ２ごとにどの程度のＢＷが利用可能であるかを記憶する。利用可能ＢＷは以下の式によって容易に計算することができる。
利用可能ＢＷ（Ｃ０）＝全ＢＷ（Ｃ０）−使用中ＢＷ（Ｃ０）
利用可能ＢＷ（Ｃ１）＝全ＢＷ（Ｃ１＋Ｃ０）−（使用中ＢＷ（Ｃ０）＋使用中ＢＷ（Ｃ１））
利用可能ＢＷ（Ｃ２）＝全ＢＷ（Ｃ２＋Ｃ１＋Ｃ０）−（使用中ＢＷ（Ｃ０）＋使用中ＢＷ（Ｃ１）＋使用中ＢＷ（Ｃ２））

この方式は、Ｔａｂｌｅ内のＶＮ−ｍ入力によって同じく示されるようなｍ個のＱｏＳクラスに一般化することができる（注記：「ｍ」及び「ｎ」は自然数である）。

新たなセッションが許可される（又は削除される）とき、現在利用可能である帯域幅のこの変更後の量を反映させるために、「利用可能ＢＷ」エントリがそれに応じて更新されなくてはならない。ＡＣＭは、「利用可能」列自体を維持管理することができるか、又はＰＳを経由するセッションのＢＷ使用量についての自らの統計データを保持するＰＳに尋ねることができる［４］。その場合、ＡＣＭは、ＰＳにＶＮ ＩＤ、宛先アドレス及びＱｏＳクラスを提示する。その際、ＰＳは、宛先に向かう送出リンク（Ｉ／Ｆ）のためのそのようなセッションに対する使用中ＢＷを返送する。ＡＣＭは、送出リンク（Ｉ／Ｆ）を明示することもできる。その場合、ＡＣＭは、特定の宛先の場合にこのＰＳ上でいずれが送出インターフェースであるかを決定することができるネットワーク接続性テーブル（ネットワークトポロジ）を維持管理する。プログラマブルスイッチが１つの入口点（例えばＭＰＬＳ ＬＥＲ）にのみ接続される場合には、１つの送出Ｉ／Ｆからの使用中ＢＷ情報しか必要とされない。

この特定のＶＮ、ＱｏＳクラスのためにＢＷが利用可能である場合には、ＡＣＭは、このセッション確立要求をＴＤに転送するようにＰＳに指示する。そこから、ＴＤは自らのセッション許可、転送、リソース確保手順［２〜３］、［８〜１０］に従ってそのセッションを許可する責任を負う。決定を下したＡＣＭは、それに応じて、そのＶＮ状態テーブル（図１６ａ）を、具体的には、「利用可能ＢＷ」の列を更新する。これは、セッションが終了される／終わるときにも更新される（その場合、「使用中ＢＷ」は減少する）。

さらに、ＰＳは、新たなセッション確立要求を受信すると、セッション確立要求自体を転送するとともに、又はセッション確立要求自体を転送することなく、特定のＶＮからのこのセッションの特定のＱｏＳクラスに関する使用中ＢＷ／利用可能ＢＷ情報を積極的に転送することができる。ＰＳがセッション確立要求自体をＡＣＭに転送しない場合には、ＰＳは、このセッション確立要求によってすべきことに関するコントローラに対する命令を受信するまで、そのメッセージをメモリに記憶する。ＰＳは、メッセージをコントローラに転送する前にメッセージのコピーを保持することもできる。

より優先順位の高いＱｏＳクラストラフィックが存在しない場合、図１５に示される例の場合に略述されたたように、その残りのＢＷを優先順位の低いＱｏＳクラスによって消費することができる。しかしながら、より優先順位の高いＱｏＳクラスのための新たなセッションが到着する場合には、より優先順位の高いＱｏＳクラスのために十分なＢＷを解放するために、優先順位の低いＱｏＳクラスから適切な数のセッションが削除／解除されなければならない。複数のＶＮが同じＴＤを使用しているとき、同じＶＮクラス内でプリエンプションが実行されなければならない。ＡＣＭがこのタスクを実行する。

新たなセッション確立要求がＡＣＭに到着するとき、上記で説明されたように、ＡＣＭは、ＶＮ内でプリエンプションが必要であるか否かをチェックする。ＡＣＭはＶＮ ＩＤをチェックし、そのセッション確立要求がどのＶＮから到来しているかを判断する。ＡＣＮは図１６ａ（Ｔａｂｌｅ）を調べ、プリエンプションが必要であるか否かを判断する。ＶＮ−０からＣ０セッションが到着したと仮定しよう。テーブルを調べた後に、ＡＣＭコントローラは、ＶＮ−０からの１つ／幾つかのＣ１セッションがプリエンプトされる必要があることを見いだす。その際、コントローラは以下の方法のいずれか、又は組み合わせにおいてプリエンプションを実行する。
ｉ ＶＮ ＩＤ（例えば、ＩＰ発信元／宛先アドレス）、ＱｏＳ ＩＤ（例えば、ＩＰ発信元／宛先ポート、ＩＰ ＴＯＳビット、ＭＰＬＳ ＥＸＰビット、ＭＰＬＳラベル等）に一致するＣ１からのセッションを破棄するようにプログラマブルスイッチに指示する。これらのセッションはＰＳを経由してＴＤに進むので、ＰＳは、上記の判定基準に一致するパケットを、接続されたＴＤ、例えば、ＭＰＬＳ ＬＥＲに転送するのを中止する。
ｉｉ この機能は、そのセッションのパケットがＴＤに入るのを防ぐが、ＴＤリソースは、一定時間にわたって依然として確保される。この確保を解消するために、複数の可能性がある。最初に、ＴＤ確保［８−９］がタイムアウト時間を有するという事実を利用することができる。ＬＥＲが一定の時間にわたって特定のセッションのパケットを確認しないとき、ＬＥＲはそのセッションに関するＢＷ確保を解消する。そのセッションは存続時間も有し、満了する前にリフレッシュされない場合には、確保状態も解消される。それゆえ、最初にどのタイムアウトが生じるかに応じて、リソースが自動的に解放される。

スイッチがセッション統計データを記憶するとき、ＡＣＭは、セッションの存続時間を知るためにスイッチに尋ねることができ、この情報から、Ｃ１セッション確保が満了する時点を判断することができる。

パケットが存在しないことに起因するタイムアウト時間に関する情報の場合、ＴＤは、ＰＳを通して、又はその対応するＮＭＳ／ＯＳＳを通してＡＣＤに直接知らせることができる。

いずれの場合でも、タイムアウトが生じると直ちに新たなセッションを許可することができる。同時に発生し、衝突するセッション要求を回避できるように、ＡＣＭは、当該の新たなセッションを許可する前に、一定時間待つことができる。

タイムアウトに基づいてＴＤリソースを解放することに加えて、ＡＣＤはリソース解放を能動的にトリガすることもできる。このために、ＡＣＤは、ＰＳを介して、このＰＳに直接接続され、かつＴＤへの入口点としての役割を果たすＬＥＲに向かって「セッション確保状態解消」メッセージを発行する。このメッセージは、Ｃ１セッションを解消するようにＬＥＲに指示し、ＬＥＲは、宛先への途中にある関連するＴＤスイッチにそのメッセージを更に転送する。ここで、ＡＣＤは、ＴＤへのＴＤスイッチとしての役割を果たし、ＴＤ制御メッセージを発行する権利を有する。そのような場合、ＡＣＤ及びＴＤは、［１１］、［１２］において説明された適切なセキュリティ関連付けを必要とする。ＰＳのアドレスは、「セッション確保状態解消」の発信元アドレスとして用いられる。それゆえ、ＴＤにおける確保を解消すると、確認応答（ＡＣＫ）メッセージがＰＳに返送され、そのメッセージはＰＳによってＡＣＭに転送される。

そのようなＡＣＫメッセージを受信すると、その際、ＡＣＭは新たなセッション要求、この例では、Ｃ０セッション要求を許可する。このステップにおいて説明されるように、明示的な確保解消を発行すると、ｉｉにおいて説明されるタイムアウトに基づく手法よりも迅速に所望のリソースが解放される。
・幾つかのセッションを解消する、すなわち、プリエンプトすると、ＡＣＭがＰＳを通して、又はＴＤ ＬＥＲが、プリエンプトされたセッションの発信元に「リソース利用不可」メッセージ［８−９］を送信することができる。

次に、図１７が説明される。図１７は、自然ネットワーク間でのプリエンプションを示す。これは、帯域幅使用効率を高めるのに役立つことができる。そのような場合、仮想ネットワーク間に、又は仮想ネットワークのうちの幾つかの間に優先レベルが存在する。その代わりに、又はそれに加えて、異なる仮想ネットワークに属する異なるＱｏＳクラス間に優先順位を設定することもできる。そのような拡張の場合、図１７において例示される情報は、図１６ａのテーブルに加えて、アクセス制御ドメインにおいて維持管理されることになる。仮想ネットワーク間優先順位の場合、仮想ネットワーク１が仮想ネットワーク０より高い優先順位を有し、また、仮想ネットワーク０は仮想ネットワーク７に比べて高い優先順位を有し、また、仮想ネットワーク７は、例えば、仮想ネットワークｎより高い優先順位を有する等の、仮想ネットワークの優先順位付けが必要とされる。この場合、例えば、仮想ネットワーク０のＱｏＳクラスは、仮想ネットワーク７の全てのＱｏＳクラスより高い優先順位を有する。各Ｃ０は最も優先順位が高く、Ｃ２は全ＭＰＬＳ（トンネリングドメイン又は物理トランスポートネットワーク）内で最も優先順位が低いクラスであると言うことができ、その際、仮想ネットワーク７のＣ０をプリエンプトして、仮想ネットワーク０のＣ２に優先して、Ｃ０を許可することができる。

１つの代替的で、全て追加的な特徴は、ＶＮ ＱｏＳクラス間優先順位の場合である。ここでは、例えば、仮想ネットワーク１のＣ０は仮想ネットワーク０のＣ２より高い優先順位を有し、仮想ネットワーク０のＣ２は仮想ネットワーク７のＣ１より高い優先順位を有し、また、仮想ネットワーク７のＣ１は仮想ネットワーク１のＣ１に比べて高い優先順位を有する。それゆえ、優先レベルは、全ての仮想ネットワークにわたって全てのＱｏＳクラスに対して各仮想ネットワーク内のＱｏＳクラスごとに設定することができる。

そのようなシナリオの１つの使用例は、高い料金を支払う仮想ネットワークほど高い優先順位を与えることである。コストは、第２の事例が使用するようになるＱｏＳクラスごとにも設定することができる。

図１８及び図１９は、異なるプリエンプションシーケンスを示しており、これらのシーケンスが次に論じられる。表記に関して、例えば、図９を再び参照する。ステップ１８０１において、発信元はセッション確立要求をアクセスコントローラに送信し、この要求は、１８０２において傍受され、アクセスコントローラの制御ユニットに転送される。その後、アクセスコントローラは、プリエンプションが必要であるか否かを決定する。プリエンプションが不要である場合には、図１３ａ、図１３ｂに示されるように制御が進む。しかしながら、プリエンプションが必要とされるとき、制御ユニットは、１８０３において示されるようにプリエンプション候補セッションを選択することに進む。その後、１８０４において示されるように、プリエンプション候補セッションの統計データが要求され、これらの統計データはプログラマブルスイッチによって保持される。その後、１８０５において示されるように、プログラマブルスイッチは統計データを返送し、これらの統計データに基づいて、１８０６において示されるように、アクセスコントローラはプリエンプションセッションを選択する。その後、１８０７において示されるように、メッセージが制御ユニットからプログラマブルスイッチに進み、その後、プログラマブルスイッチは、指示されたセッションＩＤを有するセッションを破棄する。プログラマブルスイッチは、破棄（DROP）メッセージにおいて告知されたセッションを破棄する（１８０８）。その後、１８０９において示されるように、破棄されたセッションのためにこれらのソースが利用不可であるというメッセージが発信元に進む。さらに、１８１０において示されるように、アクセス制御ドメインはそのための余地が作成されたそのセッションのためのセッション確立要求をプログラマブルスイッチに転送し、その後、１８１１において示されるように、プログラマブルスイッチはこの情報をトンネリングドメインに転送し、そこから、１８１２において示されるように、セッション確立要求は宛先に進み、その後、１８１３において示されるように、宛先はセッション確立応答によって応答する。

図１９に示される他のプリエンプションシーケンスでは、その手順はブロック１８０７まで同じように進む。しかしながら、その後、１８１４において示されるように、ＡＣＭは、ＰＳを介して、セッション確保状態解消情報をトンネリングドメインに送信する。その後、１８０８において示されるように、指示されたセッションＩＤを有するセッションが破棄される。さらに、１８１５において示されるように、トンネリングドメインは、セッション確保が解消されたという確認応答を送信し、その後、リソース利用不可メッセージが、１８１６において示されるようにＰＳから発信元に、又は１８１７において示されるようにトンネリングドメインから進み、他のステップ１８１０〜１８１３は図１８と同様に進む。

上記で論じられたように、最初の動作を開始する前に、又は再スケジューリングが行われるときに、ネットワークシステム全体が初期化されることになる。ネットワークを初期化するための手順が図１１に示されており、表記は再び図１０ａ及び図１０ｂに戻って参照する。さらに、図５が参照される。図１１のＶＮは、仮想ネットワークコントローラ１３０又は１３１を表し、ＮＭＳ／ＯＳＳはコントローラ１２９を表し、トンネリングドメインはブロック１２０によって、詳細には、スイッチ及び接続１２５〜１２８によって実現され、アクセス制御ドメインは図５においてアクセスコントローラ１０７によって表される。

第１のステップ１１００では、コントローラ１２９は、上記ＱｏＳポリシー命令をトンネリングドメインに送信し、トンネリングドメインは確認／応答確認メッセージ１１０１によって応答する。その後、コントローラ１２９はトンネリングドメインＱｏＳポリシーをアクセスコントローラ１７０（アクセス制御ドメイン）に伝達する。その後、このメッセージ１１０２に応答して、アクセスコントローラは、データレコード内のトンネリングドメインＱｏＳ情報に関する第１のエントリを開き、このエントリは、１１０３において示されるように、例えば、図３の更なるデータレコード１２に対応する。その後、例えば、仮想ネットワーク１のための仮想ネットワークコントローラ１３０は仮想ネットワーク確保要求１１０４を送出し、１１０５において示されるように、この要求は、ＮＭＳ／ＯＳＳ１２９からアクセスコントローラ１７０に転送され、アクセス制御ドメイン／アクセスコントローラ１７０が、図１４ｂ若しくは図１６ｂのテーブル又は図９若しくは図３の対応するテーブル等のこの仮想ネットワークのためのエントリを開くことができるようにする。その際、そのようなエントリは仮想ネットワーク識別子、ＱｏＳクラス識別子、全帯域幅指示子及び現在帯域幅指示子で開始する。当然、最初に、現在帯域幅指示子は０に設定することができる。

その後、アクセスコントローラはメッセージ１１０６を用いて中央コントローラ１２９に応答し、その後、１１０７において示されるように、中央コントローラはこの情報を、メッセージ１１０４で最初に開始した仮想ネットワークコントローラ１３０又は１３１にフィードバックする。図１１に示されるように、メッセージ１１０４〜１１０７のための代替の手順は、中央コントローラ１２９又はトンネリングドメインが或る特定の通信を開始する必要がないように、ブロック１３０／１３１と１７０との間の矢印によって示されるように仮想ネットワークコントローラ１３０、１３１からアクセスコントローラへの、又はその逆の直接通信とすることができる。

次に、更なる態様及び実施形態が説明される。一実施態様では、ネットワークシステムは、プログラマブルスイッチ及び意思決定コントローラからなるソフトウェア定義ネットワークと、ラベルスイッチングに基づくトンネリングトランスポートプロトコルドメイン（トンネリングドメイン）と、ネットワーク管理エンティティと、仮想ネットワーキング環境におけるトラフィック発信元及び宛先とからなり、１つの仮想ネットワーク上にあるトラフィック発信元及び対応する宛先はノード仮想化手順によって分離され、ソフトウェア定義ネットワークドメインはトンネリングドメインの入口点に接続され、ソフトウェア定義ネットワークドメインは、トンネリングドメインのＱｏＳポリシーに準拠するために、トラフィック発信元からのセッション生成のための許可制御を実行する。

本発明の更なる態様は、ネットワーク管理（ＮＭＳ／ＯＳＳ）システム又は複数のネットワーク管理システムに関連し、そのシステムは、ＳＤＮドメインがトンネリングドメインＱｏＳプロビジョニングポリシー情報を受信するように、トンネリングドメイン及びソフトウェア定義ネットワークドメインのＱｏＳプロビジョニングポリシーを設定する。

本発明の更なる態様は、トラフィック発信元からのセッション確立要求生成ステップと、ＳＤＮドメインにおけるセッション許可要求傍受ステップと、ＳＤＮドメインにおけるセッション許可決定ステップと、ＳＤＮドメインにおけるトンネリングドメインへのセッション許可要求転送ステップ／セッション許可要求破棄ステップとを含む方法に関連する。

この方法は、トラフィック発信元へのセッション許可破棄ステップの通知を含むことができる。

更なる態様は、確保されるＱｏＳクラスのレコード、或る特定の時点におけるＱｏＳクラスあたりの最大利用可能帯域幅及びＱｏＳクラスあたりの帯域幅使用量を維持管理する、ＳＤＮドメインにあるテーブルに関連し、このテーブルは、ネットワークシステム内に仮想ネットワークごとに存在する。

データレコードは、トンネリングドメインにおいてサポートされるＱｏＳクラス、ＱｏＳクラス／ＱｏＳクラスの組み合わせあたりのトンネリングドメインにおける最大使用可能又は確保可能帯域幅、ＱｏＳクラス／ＱｏＳクラスの組み合わせあたりの或る特定の時点における利用可能帯域幅、各ＱｏＳクラスの優先レベル、単一のＱｏＳクラス内のセッションの優先レベル、仮想ネットワーク間の優先レベル、又は特に、別の仮想ネットワークの優先順位の高いセッションのために、或る仮想ネットワークの優先順位の低いセッションのプリエンプションを実現するために、セッションがどの仮想ネットワークに属するかに関係なく全てのセッション間の優先レベルを更に含むことができる。

上記で論じられたようなセッション許可決定ステップは、ＮＭＳ／ＯＳＳによってあらかじめ規定される仮想ネットワークＩＤ、そのセッションのＱｏＳクラス、そのセッションの必要な帯域幅及びそのセッションの宛先によって、セッション確立生成ステップを実行した仮想ネットワークを識別することを含むことができる。

セッション許可決定７は、データレコードからそのＩＤのための一致するエントリを見いだすことと、見いだされたＱｏＳクラスのためにどの程度の帯域幅が利用可能であるかをチェックすることとを含むこともできる。

セッション許可決定ステップの更なる実施態様は、十分な帯域幅が見いだされたときにセッション確立要求をトンネリングドメインに転送すること、又は十分な帯域幅が見いだされないときにセッション確立要求を破棄することも含む。

本発明の更なる態様は、ＳＤＮドメイン（又はＮＭＳ／ＯＳＳ）への仮想ネットワーク確保要求であり、その要求は、仮想ネットワークがＳＤＮドメインに仮想ネットワーク確保要求を送信することを含み、その要求は、この仮想ネットワークが必要とするＱｏＳクラスと、対応するＱｏＳクラスの優先レベル及び必要な帯域幅とを含む。

さらに、ＳＤＮにおける仮想ネットワーク確保許可方法が本発明の一態様であり、ＳＤＮドメインがＭＰＬＳドメインにおける利用可能なＱｏＳクラス及び帯域幅と比較することによって、ネットワーク確保要求を許可するか否かを決定する。ＭＰＬＳドメインが、この仮想ネットワークコントローラが要求している全てのＱｏＳクラスのために、より大きな帯域幅を有するとき、仮想ネットワーク確保要求は許可され、アクセスコントローラのデータレコードにおいて、この仮想ネットワークのための新たなエントリが開かれる。

ＳＤＮドメインが仮想ネットワーク確保要求を許可しないと決定する場合には、ＳＤＮドメインは、要求している仮想ネットワークコントローラに「リソース利用不可」応答を発行する。「リソース利用不可」メッセージは、どのＱｏＳクラスが、どの程度の帯域幅を利用できないかを含むことができる。その後、仮想ネットワークコントローラは、最終的に更なる仮想ネットワークが確立されるように、アクセスコントローラから受信された情報に応答して、ＱｏＳクラスに関して更新された帯域幅要求を有する新たな要求を開始する機会を得る。

本発明の更なる態様は、特定の仮想ネットワークからのどの優先順位の低いＱｏＳセッショングループがプリエンプトされることになるかを決定するステップからなる、ＳＤＮドメイン（アクセスコントローラドメイン）におけるプリエンプション方法に関連し、更なるステップは上記で言及されたＱｏＳセッショングループに関する帯域幅消費情報を収集することであり、更なるステップは、優先順位の高いセッションの帯域幅要求を受け入れるために、セッションのうちのいずれをプリエンプトすべきかを決定することであり、更なるステップは、選択されたセッションを破棄するようにデータ転送スイッチに指示することを含む。

プリエンプション方法の更なる実施態様は、仮想ネットワーク間の優先レベルを設定することを含むことができ、優先順位の低い仮想ネットワークからのセッションをプリエンプトして、優先順位の高い仮想ネットワークからのセッションを許可することができる。プリエンプション方法の更なる実施形態は、仮想ネットワークにわたってＱｏＳクラスに対する優先レベルを設定することを含むことができ、仮想ネットワーク内の優先順位の低いＱｏＳクラスをプリエンプトして、別の仮想ネットワーク内の優先順位の高いＱｏＳクラスを受け入れることができる。

本発明の更なる態様は、プリエンプション通知方法に関連し、アクセスコントローラ又はＳＤＮドメインが、プリエンプションに関する決定を行うと、トンネリングドメインへのプリエンプション通知メッセージを生成し、そのメッセージに基づいて、トンネリングドメイン内にある受信者は、プリエンプション通知メッセージ内で提示されるセッションのためのリソース確保状態を解消する。

本発明の更なる態様は、セッション解消通知方法であり、ＳＤＮドメインが、プリエンプション方法においてプリエンプトされると決定されたセッションの発信元へのセッション解消通知メッセージを生成する。

本発明の更なる態様は、ＳＤＮドメインが、トンネリングドメインのコンテキストにおいて有効である制御メッセージをトンネリングドメインに送信することができるような、ＳＤＮとトンネリングドメインとの間の信頼関係確立方法である。この信頼関係確立は、鍵交換又は任意の他の暗号化若しくは認証プロトコルを含むことができる。

本発明の更なる態様は、アクセス制御ドメイン、ラベルスイッチングに基づくトンネリングトランスポートプロトコルドメイン（トンネリングドメイン）、ネットワーク管理エンティティ、仮想ネットワーク環境内のトラフィック発信元及びトラフィック宛先からなるネットワークシステムに関連し、トラフィック発信元及び対応する宛先は、１つの仮想ネットワーク内にあり、ノード仮想化技術によって分離され、アクセスコントローラ等のアクセス制御ドメインはトンネリングドメインの入口点に接続され、アクセス制御ドメインは、トンネリングドメインのＱｏＳポリシーへの準拠を保証するために、トラフィック発信元から生成されたセッションのための許可制御を実行する。

このネットワークシステムのアクセス制御ドメインは、許可制御の論理及びトンネリングドメインに対する変化するセッション状態を維持管理するアクセス制御モジュールと、アクセス制御モジュールからの命令に従ってセッションデータを切り替えるプログラマブルスイッチ（ＰＳ）とからなることができる。

このネットワークシステムのアクセス制御ドメインは、ソフトウェア定義ネットワーク（ＳＤＮ）コントローラ及びＳＤＮスイッチを更に備えることができ、ＳＤＮコントローラは許可制御の論理及びトンネリングドメインに対する変化するセッション状態を維持管理し、ＳＤＮスイッチはＳＤＮコントローラからの命令に従ってセッションデータを切り替える。

ネットワークシステムのアクセスコントローラ／ＡＣＤはオープンフロー（ＯＦ）コントローラ及びＯＦスイッチを備えることができ、ＯＦコントローラは許可制御の論理及びトンネリングドメインに対する変化するセッション状態を維持管理し、ＯＦスイッチはＯＦコントローラからの命令に従ってセッションデータを切り替える。

幾つかの態様を装置との関連で説明してきたが、これらの態様は、対応する方法の記述も表していることは明らかであり、この対応する方法では、ブロック又はデバイスが、方法ステップ又は方法ステップの特徴に対応する。同様に、方法ステップとの関連で説明した態様も、対応する装置の対応するブロック又は項目又は特徴の記述を表している。

或る特定の実施態様要件に依拠して、本発明の実施形態はハードウェア又はソフトウェアにおいて実施することができる。実施態様は、電子的に読取り可能な制御信号が記憶されたデジタル記憶媒体、例えばフロッピーディスク、ＢＤ、ＤＶＤ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、又はフラッシュメモリを用いて実行することができ、それらは、それぞれの方法が実行されるようにプログラム可能なコンピュータシステムと連携する（又は連携可能である）。

本発明による幾つかの実施形態は、本明細書に記載される方法のうちの１つが実行されるようにプログラム可能なコンピュータシステムと連携することができる電子的に読取り可能な制御信号を有する非一時的記憶媒体又は非一時的データキャリアを含む。

概して、本発明の実施形態は、プログラムコードを有するコンピュータプログラム製品として実装することができる。該プログラムコードは、コンピュータプログラム製品がコンピュータ上で実行されると、方法のうちの１つを実行するように動作可能である。プログラムコードは、例えば機械可読キャリア上に記憶することができる。

他の実施形態は、機械可読キャリア上に記憶された、本明細書に記載された方法のうちの１つを実行するコンピュータプログラムを含む。

したがって、換言すれば、本発明の方法の一実施形態は、コンピュータプログラムがコンピュータ上で実行されるときに本明細書に記載された方法のうちの１つを実行するプログラムコードを有するコンピュータプログラムである。

したがって、本発明の方法の更なる実施形態は、データ担体（又はデジタル記憶媒体若しくはコンピュータ可読媒体）であって、該データ担体上に記録された、本明細書に記載された方法のうちの１つを実行するコンピュータプログラムを含む、データ担体である。

したがって、本発明の方法の更なる実施形態は、本明細書に記載された方法のうちの１つを実行するコンピュータプログラムを表すデータストリーム又は信号シーケンスである。データストリーム又は信号シーケンスは、例えば、データ通信接続を介して、例えばインターネットを介して転送されるように構成することができる。

更なる実施形態は、本明細書に記載された方法のうちの１つを実行するように構成又は適合された処理手段、例えばコンピュータ又はプログラム可能な論理デバイスを含む。

更なる実施形態は、本明細書に記載された方法のうちの１つを実行するコンピュータプログラムがインストールされたコンピュータを含む。

幾つかの実施形態では、プログラム可能な論理デバイス（例えばフィールドプログラマブルゲートアレイ）を用いて、本明細書に記載された方法の機能のうちの幾つか又は全てを実行することができる。幾つかの実施形態では、フィールドプログラマブルゲートアレイは、本明細書に記載された方法のうちの１つを実行するためにマイクロプロセッサと連携することができる。概して、本方法は任意のハードウェア装置によって実行されることが好ましい。

上述した実施形態は、単に本発明の原理を説明するものである。本明細書において記載される構成並びに詳細の変更及び変形は当業者には明らかであることが理解される。したがって、本発明は、同封の特許請求の範囲の範囲によってのみ制限され、本明細書における実施形態の記述及び説明のために提示された特定の詳細によって制限されるものではないことが意図される。

参考文献
[1] E. Rosen et al., “Multiprotocol Label Switching Architecture,” RFC 3031, IETF, Jan 2001.
[2] D. Awduche et al., “Requirements for Traffic Engineering Over MPLS,” RFC 2702, IETF, Sept 1999.
[3] F. Le Faucheur, Ed, “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering,” RFC 4124, IETF, Jun 2005.
[4] Open Networking Foundation (ONF), “OpenFlow Switch Specification Version 1.3.0,” www.opennetworking.org, Jun 2012
[5] IRTF, “Software-Defined Network Research Group (SDNRG),” http://irtf.org/sdnrg
[6] F. Le Faucheur et al., “Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering,” RFC 4125, IETF, Jun 2005.
[7] F. Le Faucheur, Ed., “Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering,” RFC 4127, IETF, Jun 2005.
[8] R. Braden, Ed. et al., “Resource ReSerVation Protocol (RSVP),” RFC 2205, IETF, Sept 1997.
[9] D. Awduche et al., “RSVP-TE: Extensions to RSVP for LSP Tunnels,” RFC 3209, IETF, Dec 2001.
[10] F. Le Faucheur, Ed. et al., “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services’” RFC 3270, IETF, May 2002.
[11] F. Baker et al., “RSVP Cryptographic Authentication,” RFC 2747, IETF, Jan 200.
[12] R. Braden et al., “RSVP Cryptographic Authentication -- Updated Message Type Value,” RFC 3097, IETF, Apr 2001.

Claims (17)

1. ２つの端末間でセッションのためのデータをトランスポートする物理トランスポートネットワーク（１２０）と、
   発信元端末と前記物理トランスポートネットワークとの間に接続されるアクセスコントローラ（１７０）であって、仮想ネットワークごとに、該仮想ネットワークのための利用可能帯域幅に関する情報を含むデータレコード（１７１）を用いて、第１の仮想ネットワークにおける第１のセッションの開始及び第２の仮想ネットワークにおける第２のセッションの開始を制御するように構成される、アクセスコントローラと
   を備え、
   前記第１の仮想ネットワークは第１の複数のサービス品質クラス（１２１）を与えるように構成され、
   前記第２の仮想ネットワークは第２の複数のサービス品質クラス（１２２）を与えるように構成され、
   前記物理トランスポートネットワークは、複数のトランスポートサービス品質クラス（１２０）を与えるように構成され、
   前記アクセスコントローラ（１７０）は、対応する前記仮想ネットワークの具体的に要求されるサービス品質クラスの利用可能帯域幅に関する情報を用いて、前記第１のセッション又は前記第２のセッションの前記開始を制御するように構成され、
   前記データレコード（１７１）は、仮想ネットワークごとに、前記第１の複数のサービス品質クラス及び前記第２の複数のサービス品質クラスのサービス品質クラスごとの利用可能帯域幅に関する情報を更に含み、
   サービス品質クラスごとに、全ての仮想ネットワークの最大帯域幅の和は、対応するトランスポートサービス品質クラスの最大帯域幅以下である、ネットワークシステム。
2. 前記データレコード（１７１）は記憶されたテーブルを含み、該記憶されたテーブルは、仮想ネットワークごとに、仮想ネットワーク識別情報（１７１ａ）、サービス品質クラス識別情報（１７１ｂ）、サービス品質クラスごとの全帯域幅に関する情報（１７１ｃ）、又はサービス品質クラスごとの現在利用可能な、又は現在使用されている帯域幅に関する情報（１７１ｄ）を含む、請求項１に記載のネットワークシステム。
3. 前記アクセスコントローラ（１７０）は、
   前記発信元端末から、前記第１の仮想ネットワークを識別する仮想ネットワーク識別情報、このセッションに必要とされる帯域幅及び必要とされるサービス品質クラスを含むセッション確立要求を傍受し（１７３）、
   前記データレコードを用いて、このセッション及び前記必要とされるサービス品質クラスに前記必要とされる帯域幅が利用可能であるか否かをチェックし（１７４）、
   前記帯域幅が利用可能である場合、前記セッション確立要求を前記物理トランスポートネットワークに転送する（１７５）ように構成される、請求項１又は２に記載のネットワークシステム。
4. 前記アクセスコントローラ（１７０）は更に、前記転送されたセッション確立要求に応答してセッション確立応答を傍受するように構成され、前記仮想ネットワーク及び前記サービス品質クラスのための前記利用可能帯域幅をこのセッションのために要求された量だけ削減することによって、前記データレコードを更新するように構成される、請求項３に記載のネットワークシステム。
5. 前記アクセスコントローラ（１７０）は、
   前記発信元端末から、前記第１の仮想ネットワークを識別する仮想ネットワーク識別情報、このセッションに必要とされる帯域幅及び必要とされるサービス品質クラスを含むセッション確立要求を傍受し（１７３）、
   前記データレコードを用いて、このセッション及び前記必要とされるサービス品質クラスに前記必要とされる帯域幅が利用可能であるか否かをチェックし（１７４）、
   前記第１の仮想ネットワーク及び前記サービス品質クラスのために十分な帯域幅が利用可能でない場合には、前記第２の仮想ネットワークにおけるいかなるセッションにも影響を及ぼすことなく、前記第１の仮想ネットワークにおける異なるセッションを選択し、終了するプリエンプションアルゴリズムを実行する（１７６）ように構成される、請求項１〜４のいずれか一項に記載のネットワークシステム。
6. 前記アクセスコントローラ（１７０）は、
   前記発信元端末から、前記第１の仮想ネットワークを識別する仮想ネットワーク識別情報、このセッションに必要とされる帯域幅及び必要とされるサービス品質クラスを含むセッション確立要求を傍受し（１７３）、
   前記データレコードを用いて、このセッション及び前記必要とされるサービス品質クラスに前記必要とされる帯域幅が利用可能であるか否かをチェックする（１７４）ように構成され、
   前記仮想ネットワーク又は前記サービス品質クラスは優先順位を付けられ、十分な帯域幅が利用可能でない場合、前記アクセスコントローラは、前記第１の仮想ネットワーク若しくは前記第２の仮想ネットワークのいずれか、又は両方の仮想ネットワークにおいて同じ又は低い優先順位を有する仮想ネットワーク又はサービス品質クラスに属する異なるセッションを選択し、終了するプリエンプションアルゴリズムを実行する（１７６）ように構成される、請求項１〜５のいずれか一項に記載のネットワークシステム。
7. 前記物理トランスポートネットワークは、データラインによって互いに接続される複数のラベルエッジルータ（１２５、１２６）と複数のラベルスイッチルータ（１２７、１２８）とを備え、
   前記アクセスコントローラ（１７０）は、前記物理トランスポートネットワークのラベルエッジルータと前記発信元端末との間に接続される、請求項１〜６のいずれか一項に記載のネットワークシステム。
8. 前記アクセスコントローラ（１７０）は、コマンドラインインターフェース等の、前記物理トランスポートネットワークの入口ラベルエッジルータに向かう接続を開始し、前記物理トランスポートネットワークにわたる通信のためのラベル付きのトンネル経路シグナリングをトリガするように構成される、請求項７に記載のネットワークシステム。
9. 前記アクセスコントローラ（１７０）は、プログラマブルスイッチ（１７８）と、前記プログラマブルスイッチの制御信号を生成するプロセッサ（１７９）と、前記データレコードを記憶するメモリ（１７１）とを備える、請求項１〜８のいずれか一項に記載のネットワークシステム。
10. 請求項１〜９のいずれか一項に記載のネットワークシステムであって、
    前記アクセスコントローラ（１７０）は、前記物理トランスポートネットワークに直接接続されるいかなる端末も存在しないように、該ネットワークシステムの前記端末と前記物理トランスポートネットワークとの間に接続されるように構成され、
    前記アクセスコントローラ（１７０）は、集中型コントローラとして、又は分散して実現される、請求項１〜９のいずれか一項に記載のネットワークシステム。
11. 請求項１〜１０のいずれか一項に記載のネットワークシステムであって、
    前記物理トランスポートネットワーク（１２０）は、トンネリングドメインと、ネットワーク管理システム／運用支援システムとして実現される分散型又は集中型コントローラ（１２９）を備え、
    前記コントローラ（１２９）は、前記トンネリングドメイン内の前記サービス品質ポリシーを初期化する（１１００）ように構成され、
    前記コントローラ（１２９）は、前記データレコード上の情報を前記アクセスコントローラに与えることによって前記アクセスコントローラを構成する（１１０２、１１０５）ようにされ、
    該ネットワークシステムは、前記第１の仮想ネットワークの第１の仮想ネットワークコントローラ（１３０）と、前記第２の仮想ネットワークの第２の仮想ネットワークコントローラ（１３１）とを更に備え、
    各仮想ネットワークコントローラは、前記特定の仮想ネットワークの前記データレコード内の前記利用可能帯域幅に関する情報を保持するように前記コントローラ又は前記アクセスコントローラに指示する（１１０４、１１０８）ようになっている、請求項１〜１０のいずれか一項に記載のネットワークシステム。
12. 前記アクセスコントローラ（１７０）は、前記物理トランスポートネットワークのサービス品質ポリシーを記述する更なるデータレコード（１７２）を保持するように更に構成され、前記サービス品質ポリシーは、前記物理トランスポートネットワークによってサポートされるサービス品質クラスに関する情報と、前記物理トランスポートネットワークのサービス品質クラスごとの利用可能帯域幅に関する情報とを含む、請求項１〜１１のいずれか一項に記載のネットワークシステム。
13. 仮想ネットワークごとに、該仮想ネットワークのための利用可能帯域幅に関する情報を含むデータレコードを記憶するためのメモリ（１２１）と、
    前記データレコードを用いて、第１の仮想ネットワークにおける第１のセッションの開始及び第２の仮想ネットワークにおける第２のセッションの開始を制御するように構成される制御ユニット（１７９）と、
    を備え、
    前記第１の仮想ネットワークは第１の複数のサービス品質クラス（１２１）を与えるように構成され、
    前記第２の仮想ネットワークは第２の複数のサービス品質クラス（１２２）を与えるように構成され、
    前記物理トランスポートネットワークは、複数のトランスポートサービス品質クラス（１２０）を与えるように構成され、
    前記制御ユニット（１７９）は、対応する前記仮想ネットワークの具体的に要求されるサービス品質クラスの利用可能帯域幅に関する情報を用いて、前記第１のセッション又は前記第２のセッションの前記開始を制御するように構成され、
    前記データレコード（１７１）は、仮想ネットワークごとに、前記第１の複数のサービス品質クラス及び前記第２の複数のサービス品質クラスのサービス品質クラスごとの利用可能帯域幅に関する情報を更に含み、
    サービス品質クラスごとに、全ての仮想ネットワークの最大帯域幅の和は、対応するトランスポートサービス品質クラスの最大帯域幅以下である、発信元端末と物理トランスポートネットワークとの間に接続可能なアクセスコントローラ。
14. 請求項１３に記載のアクセスコントローラであって、該アクセスコントローラは、
    前記発信元端末から、前記第１の仮想ネットワークを識別する仮想ネットワーク識別情報、このセッションに必要とされる帯域幅及び必要とされるサービス品質クラスを含むセッション確立要求を傍受し（１７３）、
    前記データレコードを用いて、このセッション及び前記必要とされるサービス品質クラスに前記必要とされる帯域幅が利用可能であるか否かをチェックし（１７４）、
    前記第１の仮想ネットワーク及び前記サービス品質クラスのために十分な帯域幅が利用可能でない場合には、前記第２の仮想ネットワークにおけるいかなるセッションにも影響を及ぼすことなく、前記第１の仮想ネットワークにおける異なるセッションを選択し、終了するプリエンプションアルゴリズムを実行する（１２６）ように構成される、請求項１３に記載のアクセスコントローラ。
15. 請求項１３に記載のアクセスコントローラであって、該アクセスコントローラは、
    前記発信元端末から、前記第１の仮想ネットワークを識別する仮想ネットワーク識別情報、このセッションに必要とされる帯域幅及び必要とされるサービス品質クラスを含むセッション確立要求を傍受し（１７３）、
    前記データレコードを用いて、このセッション及び前記必要とされるサービス品質クラスに前記必要とされる帯域幅が利用可能であるか否かをチェックする（１７４）ように構成され、
    前記仮想ネットワーク又は前記サービス品質クラスは優先順位を付けられ、十分な帯域幅が利用可能でない場合、前記アクセスコントローラは、前記第１の仮想ネットワーク若しくは前記第２の仮想ネットワークのいずれか、又は両方の仮想ネットワークにおいて同じ又は低い優先順位を有する仮想ネットワーク又はサービス品質クラスに属する異なるセッションを選択し、終了するプリエンプションアルゴリズムを実行する（１７６）ように構成される、請求項１３に記載のアクセスコントローラ。
16. ２つの端末間のセッションのためのデータをトランスポートする物理トランスポートネットワークと、発信元端末と前記物理トランスポートネットワークとの間に接続されるアクセスコントローラとを備えるネットワークシステムを運用するか、又はアクセスコントローラを運用する方法であって、
    仮想ネットワークごとに、該仮想ネットワークのための利用可能帯域幅に関する情報を含むデータレコードを記憶するステップと、
    前記データレコードを用いて、第１の仮想ネットワークにおける第１のセッションの開始及び第２の仮想ネットワークにおける第２のセッションの開始を制御するステップと
    を含み、
    前記第１の仮想ネットワークは第１の複数のサービス品質クラス（１２１）を与えるように構成され、
    前記第２の仮想ネットワークは第２の複数のサービス品質クラス（１２２）を与えるように構成され、
    前記物理トランスポートネットワークは、複数のトランスポートサービス品質クラス（１２０）を与えるように構成され、
    前記制御するステップは、対応する前記仮想ネットワークの具体的に要求されるサービス品質クラスの利用可能帯域幅に関する情報を用いて、前記第１のセッション又は前記第２のセッションの前記開始を制御するステップを含み、
    前記データレコード（１７１）は、仮想ネットワークごとに、前記第１の複数のサービス品質クラス及び前記第２の複数のサービス品質クラスのサービス品質クラスごとの利用可能帯域幅に関する情報を更に含み、
    サービス品質クラスごとに、全ての仮想ネットワークの最大帯域幅の和は、対応するトランスポートサービス品質クラスの最大帯域幅以下である、２つの端末間のセッションのためのデータをトランスポートする物理トランスポートネットワークと、発信元端末と前記物理トランスポートネットワークとの間に接続されるアクセスコントローラとを備えるネットワークシステムを運用するか、又はアクセスコントローラを運用する方法。
17. コンピュータ又はプロセッサ上で実行されるときに、前記コンピュータ又は前記プロセッサに請求項１６に記載の方法を実行させるコンピュータプログラム。

Images