(57)【特許請求の範囲】
【請求項１】
１つ又は複数のサーバとネットワーク構成プラットフォーム（ＮＣＰ）とを備えるネットワークエンティティを仮想化することにより、該ネットワークエンティティを実施する方法であって、該１つ又は複数のサーバはそれぞれ、実行ユニットとして動作し、該実行ユニット上で動作する１つ又は複数のアプリケーション及び／又は１つ又は複数の仮想マシンを前記サーバ上で実行し、サーバ上で動作し前記ネットワークエンティティの機能の少なくとも一部分を実施する前記アプリケーション又は前記仮想マシンのそれぞれは、仮想ネットワーク機能（ＶＮＦ）モジュールと呼ばれ、複数の該ＶＮＦモジュールは合わせて前記ネットワークエンティティを実施し、それによって仮想ネットワーク機能（ＶＮＦ）を形成し、該方法は、
前記ＮＣＰにより、前記ＶＮＦの必要とされる全体性能を規定するｍ個の重要業績評価指標（ＫＰＩ）を仮想化要求から取得するステップと、
前記ＮＣＰにより、利用可能なタイプの実行ユニットのｎ個の性能特性を前記１つ又は複数のサーバのプロバイダから取得するステップと、
前記ＮＣＰにより、前記取得したｍ個のＫＰＩ及びｎ個の性能特性に基づいて１つ又は複数の可能な展開計画を求めるステップと、
を含み、
各展開計画は、実行ユニット上で動作するＶＮＦモジュールの統合性能が前記ＶＮＦの前記必要とされる全体性能を達成するように、実行ユニットの数及びタイプを規定するものである、ネットワークエンティティを実施する方法。
【請求項２】
前記１つ又は複数の可能な展開計画を求めるステップは、利用可能なタイプの実行ユニットのｎ個の抽象的な性能特性の、前記タイプの実行ユニット上で実行されるＶＮＦモジュールによって達成されるｍ個のＫＰＩへの、ｎ：ｍのマッピングを用いて実行する、請求項１に記載の方法。
【請求項３】
前記１つ又は複数の可能な展開計画を求めるステップは、前記利用可能なタイプの実行ユニットのＶＮＦモジュール性能情報に基づいて実行され、該ＶＮＦモジュール性能情報は、或る特定のタイプの実行ユニットにおけるＶＮＦモジュール性能を、この実行ユニット上にこのＶＮＦモジュールをインストールし、トラフィックジェネレータによってこのモジュールに負荷を課し、このＶＮＦモジュールについて規定されたＱｏＳ値に違反することなく及び／又はこの実行ユニットのリソース制限に違反することなく達成することができる前記ＫＰＩを測定することによって求めることにより取得される、請求項１又は２に記載の方法。
【請求項４】
前記ｎ：ｍのマッピングを用いて実行した後に、１つ又は複数の相互接続された前記ＶＮＦモジュールのトポロジ情報と、該ＶＮＦモジュールのＫＰＩとに基づいて、前記ＶＮＦのｌ個のＫＰＩを、前記ＶＮＦモジュールをリンクするネットワーキングリソースに対するｋ個のリンク要件にマッピングするｌ：ｋマッピングによって、該ＶＮＦモジュールをリンクするネットワーキングリソースに対する要件を求めるステップを更に含む、請求項２に記載の方法。
【請求項５】
前記ＶＮＦモジュールをリンクするネットワーキングリソースに対する要件を求めるステップの後に、前記展開計画、前記ネットワーキングリソースに対する要件、及び現在利用可能なデータセンタリソースに従って、実際の実行ユニットへのＶＮＦモジュールの割り当てを規定する１つ又は複数の構築計画を決定するステップを更に含む、請求項４に記載の方法。
【請求項６】
前記１つ又は複数の構築計画を決定するステップの後に、前記１つ又は複数の構築計画の効用関数を評価するステップであって、前記効用関数はデータセンタ内のＶＮＦの特定の展開の予期される費用及び／又は電力消費を表す、評価するステップと、
前記効用関数の最大値に従って構築計画を選択するステップと、
を更に含む、請求項５に記載の方法。
【請求項７】
前記構築計画を選択するステップの後に、前記選択された構築計画に従って個々のＶＮＦモジュールを実施するステップを更に含む、請求項６に記載の方法。
【請求項８】
前記ＫＰＩは、サポートされるベアラ数及び／又はスループット及び／又はフロー及び／又はセッションの観点で規定され、前記ＶＮＦの性能及び／又は容量を含む、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記抽象的な性能特性は、ＧＦＬＯＰＳ、ＲＡＭ及び／又はＩＯ容量として規定され、ハードウェア性能パラメータを含む、請求項２に記載の方法。
【請求項１０】
１つ又は複数の相互接続されたＶＮＦモジュール及び対応するトポロジ情報を通じたＶＮＦの可能な構成がＶＮＦ記述テンプレートによって記述され、該ＶＮＦ記述テンプレートはＶＮＦテンプレートリポジトリに記憶され、ＶＮＦトポロジをノードの相互接続として記述するのに対し、前記相互接続は、
前記リンクの多様性、及び
同じノードタイプ間の相互接続、及び
異なるノードタイプ間の相互接続、
のうちの１つ又は複数を規定する、請求項４に記載の方法。
【請求項１１】
前記ＶＮＦ記述テンプレートは、利用可能なタイプの実行ユニットのｎ個の抽象的な性能特性の、前記タイプの実行ユニット上で実行されるＶＮＦモジュールによって達成されるｍ個のＫＰＩへの、前記ｎ：ｍのマッピング、及び／又は
前記リンクのための前記ｌ：ｋのマッピング、
を規定するテーブルを含む、請求項１０に記載の方法。
【請求項１２】
前記ＶＮＦ記述テンプレートは、ＶＮＦモジュールごとにバイナリソフトウェアの複数のインスタンスを含み、
各バイナリは別のターゲットプラットフォームについてコンパイルされ、最も適したバイナリが目標実行ユニットのために選択される、請求項１０又は１１に記載の方法。
【請求項１３】
前記抽象的な性能特性のマッピング及び実際に達成されるＫＰＩに関する知識は現実世界のワークロードの下で取得され、前記知識を用いて、前記ＶＮＦ記述テンプレートに含まれる前記ｎ：ｍのマッピングに含まれる少なくとも１つの抽象的な性能特性のパラメータの値を調整する、請求項１０に記載の方法。
【請求項１４】
前記個々のＶＮＦモジュールを実施するステップの後に、前記ＶＮＦに、該ＶＮＦがインストールされるハードウェアの性能を記述する１組のパラメータを通知するステップであって、ＶＮＦが基礎を成すハードウェアに適合することを可能にする、通知するステップを更に含む、請求項７に記載の方法。
【請求項１５】
前記パラメータは、前記ＶＮＦモジュールがインストールされる前記実行ユニットのパラメータと、
これらの実行ユニット及び／又はＶＮＦモジュールを相互接続するネットワークリンクを記述するパタメータと、
を含む、請求項１４に記載の方法。
【請求項１６】
前記ネットワーク構成プラットフォームは、前記展開計画を求めるステップにおいてＶＮＦに対する要件を提供するインタフェースを備え、これらの要件は以下のもの、すなわち、
前記ＶＮＦのタイプ及び該ＶＮＦが達成すべき前記ＫＰＩと、
前記ＶＮＦがインスタンス化されることになるロケーションと、
前記ネットワーク内の或る特定の所与のノードと新たにインスタンス化されたＶＮＦとを相互接続するリンクのレイテンシと、
ＶＮＦの要求される容量に対する更新要求と、
のうちの１つ又は複数を含む、請求項１〜１５のいずれか１項に記載の方法。
【請求項１７】
１つ又は複数のサーバとネットワーク構成プラットフォーム（ＮＣＰ）とを備えるネットワークエンティティを仮想化することにより、該ネットワークエンティティを実施する装置であって、該１つ又は複数のサーバはそれぞれ、実行ユニットとして動作し、該実行ユニット上で動作する１つ又は複数のアプリケーション及び／又は１つ又は複数の仮想マシンを前記サーバ上で実行し、サーバ上で動作し前記ネットワークエンティティの機能の少なくとも一部分を実施する前記アプリケーション又は前記仮想マシンのそれぞれは、仮想ネットワーク機能（ＶＮＦ）モジュールと呼ばれ、複数の該ＶＮＦモジュールは合わせて前記ネットワークエンティティを実施し、それによって仮想ネットワーク機能（ＶＮＦ）を形成し、該装置は、
前記ＮＣＰにより、前記ＶＮＦの必要とされる全体性能を規定するｍ個の重要業績評価指標（ＫＰＩ）を仮想化要求から取得するモジュールと、
前記ＮＣＰにより、利用可能なタイプの実行ユニットのｎ個の性能特性を前記１つ又は複数のサーバのプロバイダから取得するモジュールと、
前記ＮＣＰにより、前記取得したｍ個のＫＰＩ及びｎ個の性能特性に基づいて１つ又は複数の可能な展開計画を求めるモジュールと、
を備え、
各展開計画は、これらの実行ユニット上で動作するＶＮＦモジュールの統合性能が前記ＶＮＦの前記必要とされる全体性能を達成するように、実行ユニットの数及びタイプを規定するものである、ネットワークエンティティを実施する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化されたネットワーク機能を実施するための方法及び装置に関する。
【背景技術】
【０００２】
ネットワーク機能の仮想化のための既存の解決策が存在する。
【０００３】
ソフトウェアがどのように定義、展開又は計算されるかに関する問題に対する既存の解決策のほとんどは、ハードウェアがソフトウェアに従う（hardware follows software）と名付けることができる分類に入る。これは、インストールされることになる１つのソフトウェア（本明細書において用いられる用語ではＶＮＦモジュール）について、ハードウェアに対する要件が完全に規定されることを意味する。これに関する例が特許文献１によって与えられている。このため、モジュールの記述は、それらの要件、及びモジュールがそのような特定のハードウェアプラットフォーム上で達成する性能に関する情報を含む。一例は、「このモジュールは１５００ベアラの処理容量を提供し、Ｉｎｔｅｌ  Ｘｅｏｎ  Ｅ７プロセッサ及び８ＧＢのＲＡＭを必要とする」というものである。これは、第１に、ハードウェアが規定よりも多くのリソースを提供する場合には、容量が無駄になる場合があり、第２に、パワーが劣るハードウェアしか利用可能でない場合には、このハードウェア上でモジュールをインストールすること、特に実行することが完全に可能でない場合があるという不利な点を有する。
【０００４】
別の例は、特許文献２において与えられている。特許文献２では、クラウド上でインスタンス化することができるＶＭの性能要件又はタイプに基づいてリソースの仮想グループが定義される。提案されるクラウド管理システムは、要求と仮想グループとの間のマッピングを実行する。しかしながら、そのような発明は単一のＶＭのインスタンス化（のみ）を検討する。
【０００５】
１組のＶＭを自動的に展開するためのテンプレートの概念は、ＤｅｖＯｐｓ（開発及び運用）コミュニティにおいてよく知られている。Ｃｈｅｆ（Opscode社Ｃｈｅｆ［オンライン］http://www.opscode.com/chef/において入手可能）又はＰｕｐｐｅｔ（Puppet Labs社Ｐｕｐｐｅｔ［オンライン］https://puppetlabs.comにおいて入手可能）のようなツールを用いてＩＴシステム構成全体をコードとして記述することができる。これらのテンプレートを用いて、異なるアプリケーションを実行する異なるＶＭ（例えば、データベースサーバに接続されたウェブサーバ）によって構成されるシステムを自動的に展開することができる。これらのテンプレートは、幾つかのＶＭにわたるソフトウェアの展開の自動化に焦点を当て、これらのＶＭに対するハードウェア要件（例えば、ｖＣＰＵ数、ＲＡＭ、記憶容量）の非常に高水準の記述を提供する。しかしながら、これらのハードウェア要件は固定であり、クラウドサービスプロバイダがそれらの要件に合致しない場合、展開は実現可能でない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第２０１３／０４３３２６
【特許文献２】米国特許公開第２０１２／００５５３９８号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、本発明の目的は、従来技術の欠点を克服することができる仮想化の方法及び装置を提供することである。
【課題を解決するための手段】
【０００８】
１つの実施形態によれば、ネットワークのエンティティを、該ネットワークエンティティを仮想化し、該ネットワークエンティティを１つ又は複数のサーバ上で実施することによって実施する方法であって、該１つ又は複数のサーバはそれぞれ、実行ユニットとして動作し、該実行ユニット上で動作する１つ又は複数のアプリケーション及び／又は１つ又は複数の仮想マシンを前記サーバ上で実行し、サーバ上で動作し前記ネットワークエンティティの機能の少なくとも一部分を実施する前記アプリケーションプログラム又は前記仮想マシンのそれぞれは、仮想ネットワーク機能（ＶＮＦ）モジュールと呼ばれ、複数の該ＶＮＦモジュールは合わせて前記ネットワークエンティティを実施し、それによって仮想ネットワーク機能（ＶＮＦ）を形成し、該方法は、
前記ＶＮＦの必要とされる全体性能を規定するｍ個の重要業績評価指標（ＫＰＩ）を取得するステップと、
利用可能なタイプの実行ユニットのｎ個の性能特性を取得するステップと、
前記取得したｍ個のＫＰＩ及びｎ個の性能特性に基づいて１つ又は複数の可能な展開計画（デプロイメントプラン；deployment plan）を求めるステップと、
を含み、
各展開計画は、実行ユニットの数及びタイプを、これらの実行ユニット上で動作するＶＮＦモジュールの統合性能が前記ＶＮＦの前記必要とされる全体性能を達成するように規定する方法が提供される。
【０００９】
数ｍ及びｎは、１以上の整数とすることができ、必要とされる全体性能はＫＰＩによって規定することができる。
【００１０】
これによって、ソフトウェアの実施態様がハードウェアの特性とソフトウェアの性能要件とに基づいて選択される新たなパラダイム「ソフトウェアがハードウェアに従う（software follows hardware）」による手法が提供される。これによって、より柔軟な実施態様が可能になり、起こり得るリソースの無駄が回避される。
【００１１】
１つの実施形態によれば、ｍ個のＫＰＩを、様々なタイプの実行ユニットのｎ個の性能特性との関係に設定することによって、１つ又は複数の可能な展開計画が求められる。
【００１２】
これによって、複数の可能な実施態様の中から、場合によっては費用関数又は効用関数に基づいて最も有効な実施態様を選択する選択肢が可能になる。
【００１３】
１つの実施形態によれば、前記１つ又は複数の可能な展開計画を求めるステップは、利用可能なタイプの実行ユニットのｎ個の抽象的な性能特性の、前記タイプの実行ユニット上で実行されるＶＮＦモジュールによって達成されるｍ個のＫＰＩへの、ｎ：ｍのマッピングを通じて実行される。
【００１４】
これによって、一方では性能要件を満たし、他方では利用可能なハードウェアに基づいて適切かつ可能である実際の実施に辿り着く方法の具体的な実施が可能になる。
【００１５】
１つの実施形態によれば、前記１つ又は複数の可能な展開計画を求めるステップは、前記利用可能なタイプの実行ユニットのＶＮＦモジュール性能情報に基づいて実行され、該ＶＮＦモジュール性能情報は、或る特定のタイプの実行ユニットにおけるＶＮＦモジュール性能を、この実行ユニット上にこのＶＮＦモジュールをインストールし、トラフィックジェネレータによってこのモジュールに負荷を課し、このＶＮＦモジュールについて規定されたＱｏＳ値に違反することなく及び／又はこの実行ユニットのリソース制限に違反することなく達成することができる前記ＫＰＩを測定することによって求めることにより取得される。
【００１６】
これは、展開計画の実際の実施に辿り着く別の方法である。
【００１７】
１つの実施形態によれば、本方法は、前記ＶＮＦのｌ個のＫＰＩをｋ個のリンク要件にマッピングするｌ：ｋマッピングによって、１つ又は複数の相互接続された前記ＶＮＦモジュールのトポロジ情報と、該ＶＮＦモジュールのＫＰＩとに基づいて、該ＶＮＦモジュールをリンクするネットワーキングリソースに対する要件を求めるステップを更に含む。
【００１８】
これは、実際の実施トポロジを考慮に入れ、ネットワークリソース要件を、例えば費用関数の考慮に入れることを可能にする。
【００１９】
１つの実施形態によれば、本方法は、前記展開計画、前記ネットワーキングリソースに対する要件、及び前記現在利用可能なデータセンタリソースに従って、実際の実行ユニットへのＶＮＦモジュールの割り当てを規定する１つ又は複数の構築計画を決定するステップを更に含む。
【００２０】
これによって、インスタンス化することができる１つ又は複数の可能な展開計画による実際の実施が可能になる。
【００２１】
１つの実施形態によれば、本方法は、前記１つ又は複数の構築計画の効用関数を評価するステップと、
なお、前記効用関数はデータセンタ内のＶＮＦの特定の展開の予期される費用及び／又は電力消費を表すことが好ましく、
前記効用関数の最大値に従って構築計画を選択するステップと、
を更に含む。
【００２２】
これによって、最良かつ最適な仮想化の実施態様の選択が可能になる。
【００２３】
１つの実施形態によれば、本方法は、前記選択された構築計画に従って個々のＶＮＦモジュールを展開するステップを更に含む。
【００２４】
このようにして、実際の実施が行われる。
【００２５】
１つの実施形態によれば、前記ＫＰＩは、サポートされるベアラ数及び／又はスループット及び／又はフロー及び／又はセッションの観点で規定されることが好ましい、前記ＶＮＦの性能及び／又は容量を含む。
【００２６】
これらはＫＰＩの適切な実施態様である。
【００２７】
１つの実施形態によれば、前記（抽象的な）性能特性は、ＧＦＬＯＰＳ、ＲＡＭ及び／又はＩＯ容量として規定されることが好ましい、ハードウェア性能パラメータを含む。
【００２８】
１つの実施形態によれば、１つ又は複数の相互接続されたＶＮＦモジュール及び対応するトポロジ情報を通じたＶＮＦの可能な構成がＶＮＦ記述テンプレートによって記述され、該ＶＮＦ記述テンプレートはＶＮＦテンプレートリポジトリに記憶されることが好ましく、前記ＶＮＦトポロジをノードの相互接続として記述するのに対し、前記相互接続は、
前記リンクの多様性、及び
同じノードタイプ間の相互接続、及び
異なるノードタイプ間の相互接続、
のうちの１つ又は複数を規定する。
【００２９】
これらはトポロジを考慮に入れたＶＮＦ記述の実施態様である。
【００３０】
１つの実施形態によれば、前記ＶＮＦ記述テンプレートは、利用可能なタイプの実行ユニットのｎ個の抽象的な性能特性の、前記タイプの実行ユニット上で実行されるＶＮＦモジュールによって達成されるｍ個のＫＰＩへの、前記ｎ：ｍのマッピング、及び／又は
前記リンクのための前記ｌ：ｋのマッピング、
を規定するテーブルを含む。
【００３１】
これは、仮想化のネットワーク要件を考慮に入れることを可能にする特殊な実施態様である。
【００３２】
１つの実施形態によれば、前記ＶＮＦ記述テンプレートは、ＶＮＦモジュールごとにバイナリソフトウェアの複数のインスタンスを含み、
各バイナリは別のターゲットプラットフォームについてコンパイルされ（例えば、一方はＡＭＤ３２ビット用に、他方はインテル６４ビット用に…）、最も適したバイナリが目標実行ユニットのために選択される。
【００３３】
これは様々な仮想化プラットフォームにおける実施態様間の選択を可能にする。
【００３４】
１つの実施形態によれば、前記抽象的な性能特性のマッピング及び実際に達成されるＫＰＩに関する知識は現実世界のワークロードの下で取得され、前記知識を用いて、前記ＶＮＦ記述テンプレートに含まれる前記ｎ：ｍのマッピングに含まれる前記情報が調整される。
【００３５】
これは、実際に実施される仮想化の性能のフィードバックを可能にし、場合によっては、必要であれば適合を可能にする。
【００３６】
１つの実施形態によれば、本方法は、前記ＶＮＦに、該ＶＮＦがインストールされる前記ハードウェアの性能を記述する１組のパラメータを通知するステップであって、ＶＮＦが基礎を成すハードウェアに適合することを可能にする、通知するステップを更に含む。
【００３７】
このフィードバックメカニズムも、必要であれば適合を可能にする。
【００３８】
１つの実施形態によれば、
前記パラメータは、前記ＶＮＦモジュールがインストールされる前記実行ユニットのパラメータと、
これらの実行ユニット及び／又はＶＮＦモジュールを相互接続する前記ネットワークリンクを記述するパタメータと、
を含む。
【００３９】
これらはフィードバックパラメータの具体的な実施態様である。
【００４０】
１つの実施形態によれば、本方法は、ＶＮＦに対する要件を提供するインタフェースであって、これらの要件は以下のもの、すなわち、
前記ＶＮＦのタイプ及び該ＶＮＦが達成すべき前記ＫＰＩと、
前記ＶＮＦがインスタンス化されることになる前記地理的エリアに関する情報と、
前記ネットワーク内の或る特定の所与のノードと前記新たにインスタンス化されたＶＮＦとを相互接続する最大レイテンシと、
ＶＮＦの前記要求される容量に対する更新要求と、
のうちの１つ又は複数を含む、ＶＮＦに対する要件を提供するインタフェースを更に含む。
【００４１】
これによって実施態様の別の適合方法が可能になる。
【００４２】
１つの実施形態によれば、ネットワークのエンティティを、該ネットワークエンティティを仮想化し、該ネットワークエンティティを１つ又は複数のサーバ上で実施することによって実施する装置であって、該１つ又は複数のサーバはそれぞれ、実行ユニットとして動作し、該実行ユニット上で動作する１つ又は複数のアプリケーション及び／又は１つ又は複数の仮想マシンを前記サーバ上で実行し、サーバ上で動作し前記ネットワークエンティティの機能の少なくとも一部分を実施する前記アプリケーションプログラム又は前記仮想マシンのそれぞれは、仮想ネットワーク機能（ＶＮＦ）モジュールと呼ばれ、複数の該ＶＮＦモジュールは合わせて前記ネットワークエンティティを実施し、それによって仮想ネットワーク機能（ＶＮＦ）を形成し、該装置は、
前記ＶＮＦの必要とされる全体性能を規定するｍ個の重要業績評価指標（ＫＰＩ）を取得するモジュールと、
利用可能なタイプの実行ユニットのｎ個の性能特性を取得するモジュールと、
前記取得したｍ個のＫＰＩ及びｎ個の性能特性に基づいて１つ又は複数の可能な展開計画を求めるモジュールと、
を備え、
各展開計画は、実行ユニットの数及びタイプを、これらの実行ユニット上で動作するＶＮＦモジュールの統合性能が前記ＶＮＦの前記必要とされる全体性能を達成するように規定する、ネットワークのエンティティを、該ネットワークエンティティを仮想化し、該ネットワークエンティティを１つ又は複数のサーバ上で実施することによって実施する装置が提供される。
【００４３】
これによってネットワーク機能の仮想化のための装置が提供される。
【００４４】
１つの実施形態によれば、本方法は、本発明の実施形態のうちの１つによる方法のステップを実行するための１つ又は複数のモジュールを更に備える装置を更に含む。
【００４５】
１つの実施形態によれば、本方法は、コンピュータにおいて実行されると、そのコンピュータに、本発明の実施形態のうちの１つによる方法を実行させるコンピュータープログラムコードを含むコンピュータプログラムを更に含む。
【図面の簡単な説明】
【００４６】
【図１】本発明の実施形態を概略的に説明する図である。
【図２】本発明の実施形態を概略的に説明する図である。
【図３】本発明の実施形態を概略的に説明する図である。
【図４】本発明の実施形態を概略的に説明する図である。
【図５】本発明の実施形態を概略的に説明する図である。
【図６】本発明の実施形態を概略的に説明する図である。
【図７】本発明の実施形態を概略的に説明する図である。
【図８】本発明の実施形態を概略的に説明する図である。
【図９】本発明の実施形態を概略的に説明する図である。
【図１０】本発明の実施形態を概略的に説明する図である。
【図１１】本発明の実施形態を概略的に説明する図である。
【図１２】本発明の実施形態を概略的に説明する図である。
【図１３】本発明の実施形態を概略的に説明する図である。
【発明を実施するための形態】
【００４７】
本発明の実施形態を説明する前に、まず以下の説明において用いられる幾つかの用語を定義する。
ＣＭＳ：クラウド管理システム。クラウド環境に含まれる物理リソースを管理するためのツール及び方法と、そのようなインフラストラクチャの上位で実行される論理（仮想）マシンインスタンスとを備えるシステム。
ＫＰＩ：重要業績評価指標（key performance indicator）。特定のネットワーク機能アクティビティの成功を評価するのに用いられる性能測定タイプ。
ＮＣＰ：ネットワーク構成プラットフォーム。仮想化されたネットワーク機能の仮想化固有の面を管理するネットワーク運用及び管理システム。
ＮＦＶ：ネットワーク機能仮想化。仮想ハードウェア抽象化を用いることによって、ネットワーク機能をそれらが実行されるハードウェアから分離する原理。
ＮＭＳ：ネットワーク管理システム。個々のネットワーク要素から構成されるネットワークを構成及び監視するためのツール及び方法を含むシステム。
ＯＳＳ運用サポートシステム。ネットワークインベントリをメンテナンスし、サービスを供給し、ネットワーク構成要素を構成し、障害を管理するためのサポートプロセスを提供する、電気通信サービスプロバイダによって用いられるコンピュータシステム。
ＶＭ：仮想マシン。物理マシンのようにプログラムを実行するマシンのソフトウェアによる実施。
ＶＮＦ：仮想化ネットワーク機能。仮想化され、ネットワークサービスとして提供することができるか、又は仮想化されたネットワーク機能及び／又は仮想化されていないネットワーク機能の組から構成されるサービスの一部とすることができるネットワーク機能。
【００４８】
以下において、本発明を例示的な実施形態として説明する。
【００４９】
本発明の実施形態は、３ＧＰＰ発展型パケットコア（ＥＰＣ）サービングゲートウェイ（Ｓ−ＧＷ）のようなネットワーク機能又は移動ネットワークのファイアウォールが仮想化され、商用オフザシェルフ（ＣＯＴＳ）ＩＴサーバ上で実施されるシナリオを検討する。以下において、そのような機能は「仮想化ネットワーク機能（ＶＮＦ）」と呼ばれる。「Ｓゲートウェイ（S-Gateway）」が仮想化される仮想化シナリオが図１において概略的に示されている。図１は、様々なＩＴサーバ上に搭載された複数の要素からクラスタＳ−ＧＷをどのように構成することができるかを示している。外部に対し、このクラスタは単一のＳ−ＧＷのように見える。
【００５０】
図１に示すように、クラスタアーキテクチャに従うＩＴサーバの集合体において単一の仮想Ｓ−ＧＷが実施されると仮定することができる。完全なクラスタは、外部に対し単一のＳ−ＧＷのように見える。各ＩＴサーバは、サーバ上のアプリケーションとして又は図に示すように仮想マシン（ＶＭ）内に実施することができるような仮想化ネットワーク機能の１つ（又は複数）のモジュールをホストする。これらのモジュールのそれぞれがＶＮＦモジュールと呼ばれる。
【００５１】
そのようなアーキテクチャの例として、「ロードバランサ」ＶＮＦモジュール及び「ベアラ処理」ＶＮＦモジュール（図１を参照されたい）から構成されるＳ−ＧＷを検討することができる。ロードバランサは、到来するパケットをそれらのトンネルＩＤに従って分類し、担当のベアラ処理ＶＮＦモジュールに転送することができる。ベアラ処理モジュールはＳ−ＧＷにおいて必要な全ての計算及びトンネルハンドリングを行う。そのようなアーキテクチャにより、クラスタの容量はベアラ処理モジュールを追加又は除去することによって容易にスケーリングすることができる一方、外部にはシステム全体が単一のＳ−ＧＷのように見える。
【００５２】
本発明の一実施形態によるＶＮＦは、以下の要素、すなわち、ＶＮＦモジュールのためのソフトウェアと、ソフトウェアインストールに関する情報と、用いられるハードウェアの性能特性（例えば、後に説明するｍ：ｎテーブルにおいて表される）と、モジュールがどのように相互接続されるかに関するトポロジ情報とを含むＶＮＦ記述テンプレートによって定義される。次に、いわゆるネットワーク構成プラットフォーム（ＮＣＰ）が、上述のテンプレートに基づくＶＮＦの実際の展開の計算を担当する。次に、これはクラウド管理システム（ＣＭＳ）に通信され、ＣＭＳは計算クラウドにおける埋め込みを実行する。
【００５３】
本発明の実施形態によって、ＶＮＦの実際の展開をどのように計算することができるかの問題が対処される。詳細には、これはハードウェア不均一性の問題を踏まえて対処される。このハードウェア不均一性の問題は、現実に即したデータセンタが、絶え間ない更新及びリプレースに起因して非常に様々な性能特性を有する複数のタイプのサーバを含むことにより生じる。ＶＮＦがそのようなデータセンタに搭載される場合、規定の性能を達成するために、様々なソフトウェアモジュールのＶＮＦ記述テンプレートに規定された要件が満たされなくてはならない。このため、ＶＮＦの実際のインスタンスを計算するには、様々なモジュールのテンプレートによって与えられた仕様を満たすか又はそれを上回る適切なハードウェアを見つけなくてはならない。これは、規定のハードウェアが利用可能でないか、又はより高い性能を有するハードウェアのみが搭載されており、このため容量が無駄になる場合に問題となる可能性がある。
【００５４】
１つの実施形態によれば、解決策は、ＶＮＦの必要な全体性能を規定する１つ又は複数のｍ個の重要業績評価指標（ＫＰＩ）を取得することを含む。これは、幾つかのネットワーク事業者によって要件として定義することができる。次に、利用可能なタイプの実行ユニットについてｎ個の性能特性が得られる。これらのｎ個の性能特性は、利用可能な実行ユニット（すなわち、例えばクラウドにおいて利用可能なマシン）の性能特性を調査した仮想化環境のプロバイダ／ベンダによって提供することができる。次に、性能特性及びＫＰＩは「展開計画」の基礎を形成し、この展開計画は、仮想化の実際の展開の実行ユニットの数及びタイプを、ＫＰＩ及びｎ個の性能特性に基づいてこれらの実行ユニット上で実行されるＶＮＦモジュールの共同性能が、ＫＰＩによって定義されるＶＮＦの必要な全体性能を達成するように規定する。
【００５５】
したがって、実施形態は、ＫＰＩ（ネットワーク事業者からの要件から得られる）及び性能特性に基づいて、例えばクラウド管理システムによってインスタンス化することができる「展開計画」を生成する。
【００５６】
このために、実施形態は、利用可能なハードウェア（例えば、ＧＦＬＯＰＳ、ＲＡＭ等）のハードウェア性能パラメータをＫＰＩに対し「マッピング」するＶＮＦ記述子又はＶＮＦ記述テンプレートを含むことができる。そのようなＶＮＦ記述子マッピングは、仮想化サービスのベンダによって提供することができる。
【００５７】
次に、仮想化要求から受信したＶＮＦ記述子及びＫＰＩに基づいて、１つの実施形態によれば、ハードウェアの性能特性に対しＫＰＩをマッピングする「マッピング」を実行することができる。この結果として、複数の可能なマッピングを得ることができ、次にそれぞれの結果として、クラウド管理システムによってインスタンス化することができる可能な展開計画が得られる。
【００５８】
一実施形態によれば、上記手法は、複数の独立したネットワーク接続（Ｓ−ＧＷの場合ベアラと呼ばれる）を並列に処理するＶＮＦに適している。ＥＰＣノード、ファイアウォール、又はブロードバンドリモートアクセスサーバ（ＢＲＡＳ）のような仮想化のための検討中の多数の機能がこの分類に入ることに留意されたい。
【００５９】
接続のパケットの処理は、利用可能なリソース（例えば、ＲＡＭ、ＣＰＵサイクル、ネットワーク容量）の或る特定の一部分を必要とする。このため、ＶＮＦモジュールは単一のモノリシックワークロードを処理するのではなく、より小さなワークロード、すなわち接続の集合を処理する。ワークロードのモジュール性を利用して、ＶＮＦモジュールが処理する接続量を展開時点において計算することによって、この接続量を利用可能なハードウェアに適合させる。ＶＮＦに要求される全体性能を達成するために、次にそれに応じてＶＮＦモジュール数がスケーリングされる。
【００６０】
このために、実施形態は３つの構成要素からなる。
１．顧客又はオペレーティングサポートシステム（ＯＳＳ）要求に基づいて展開可能なＶＮＦテンプレート又はＶＮＦ展開計画を実現するのに必要な処理。この処理は、必要とされるアプリケーションレイヤ性能（ＫＰＩ）及び利用可能なハードウェアリソース（性能特性）を考慮に入れる。既存の手法は、ソフトウェアの所定の要件に適した適切なハードウェアを検索し、所定のトポロジを展開することを必要とする。それとは対照的に、提案される手法は、ＶＮＦ（モジュール数及びそのトポロジ）を利用可能なハードウェアに適合させる。
２．例えばサポートされるベアラ数及びＧｂｐｓ単位の目標スループットのようなｍ個のアプリケーションレベル重要業績評価指標（ＫＰＩ）へのｎ個のハードウェア性能パラメータ（例えば、ＧＦＬＯＰＳ、ＲＡＭ、ＩＯ容量）のマッピングを提供するＶＮＦ記述子における多次元テーブル。これは、達成される性能に対するハードウェアの関係を抽象的に記述することを可能にし、上記で概略を述べたソフトウェアの適合を利用可能なハードウェアにより容易にかつより柔軟にする。
３．実際の計算及び埋め込みを実現するのに必要なステップ及びメッセージフロー。
【００６１】
そのような手法は以下の利点を有する。
【００６２】
上記手法は、ＶＮＦ展開を利用可能なハードウェアに適合させ、これによってリソース利用全体を改善することによって、データセンタに存在するハードウェア不均一性を利用する。
【００６３】
上記手法は、ＶＮＦモジュールが処理する接続量を利用可能なハードウェアに適合させるので、従来の手法では解に辿り着くことができない場合、例えば、従来の規定によるＶＮＦが要求するだけのリソース量をハードウェアが提供しない事例であっても、埋め込みを作成することができる。
【００６４】
リソース（性能特性）を達成される性能（ＫＰＩ）にマッピングするＶＮＦ記述子テンプレートにおける多次元テーブルの設計を用いて、ＶＮＦのベンダによって測定されていないサーバ構成の埋め込みを計算することが可能である。このため、ＶＮＦ展開はより柔軟で将来性がある。
【００６５】
この手法の間接的な態様は、ＯＳＳ（後に説明する）をＮＣＰ（これについても後に説明する）が仮想化固有の管理タスクを実行するときに再利用することができることである。
【００６６】
これによって、レガシーＯＳＳに対する変更が最小限になるので費用が節減される。
【００６７】
ここで、幾つかの更なる実施形態をより詳細に説明する。
【００６８】
１．１システムアーキテクチャ
全体的なシステムアーキテクチャが、関連する要素間の参照点とともに図２に示されている。第１の要素はオペレーティングサポートシステム（ＯＳＳ）１００である。ＯＳＳは、ネットワークプロビジョニングサービス、ネットワーク構成要素の構成及び管理、アカウント管理及び課金を担当する。現行のＯＳＳ／ＢＳＳは仮想化に対応していない。ＯＳＳは、複数の仮想ネットワーク機能４００を供給するために、ネットワーク構成プラットフォーム（ＮＣＰ）２００とインタラクトする。ＮＣＰは、数ある動作の中でも、ＶＮＦ展開を計算し、展開をトリガし、仮想化ライフサイクル全体を管理することを担当する。このアーキテクチャにおいて、２つの新たなエンティティ、すなわち、クラウド管理システム（ＣＭＳ）３０１と物理的に同じ場所に配置することができるＮＣＰクラウドエージェント２０３と、トランスポートネットワーク管理システム（ＮＭＳ）３０２と物理的に同じ場所に配置することができるＮＣＰネットワークエージェント２０４とが導入されている。これらのエージェントは、クラウド及びネットワークにおけるハードウェアリソース使用に関する最新情報を必要とするＮＣＰ関連の動作及び計算を実行する。ＮＣＰは、要素２００、２０３、２０４を備える単一のエンティティとして見ることもできることに留意すべきである。
【００６９】
ＶＮＦインスタンス４００は、１つ又は幾つかのＶＮＦモジュール４０１から構成され、これらのモジュールは、幾つかのソフトウェア又は仮想マシンイメージ４０２として実施される。この特定の実施形態において、ＶＮＦ４００が２つのＶＮＦモジュール４０１から構成される例を示し、これらのＶＮＦモジュール４０１は２つのそれぞれのＶＭ４０２内に含まれる。提案された解決策を実現するために、ＮＣＰはクラウド管理システム及びネットワーク管理システムとインタラクトする。ＣＭＳ３０１は、インタフェース１０６を通じて、クラウド３０３内の物理インフラストラクチャリソース及び仮想インフラストラクチャリソースの管理を担当する。これらのリソースは、計算リソース、記憶リソース、及びクラウド内ネットワーク接続リソースを含むことができる。マルチクラウド環境を含むＶＮＦのインスタンス化はＮＭＳ３０２からの支援も必要とする。ＮＭＳ３０２は、インタフェース１０７を通じて、そのようなクラウドを相互接続するトランスポートネットワーク３０４の接続を管理することができる。最後に、ＶＮＦ記述テンプレート２０１がデータベース２０２又はデータリポジトリ内に記憶され、ＮＣＰはこれらに対し書き込み権限及び読み出し権限を有する。
【００７０】
１．２テンプレート及び処理
仮想化の実際の実施を達成するために、利用可能なハードウェアリソースに適合されるＶＮＦ展開計画が計算される。このプロセスを概説する前に、まずこの実施形態において用いられるテンプレートのタイプを説明する。
【００７１】
１．２．１テンプレートタイプ
ＶＮＦ記述テンプレート：この記述テンプレートはＶＮＦの抽象的な記述を提供し、ＶＮＦがどのように実施されるか、その要件、提供されるハードウェアリソースに依拠して達成することができる性能の量等に関する情報を含む。この記述テンプレートは直接インスタンス化することができないが、現在使用可能なハードウェア及び要求される性能に適合させる必要がある。
ＶＮＦ構築計画：この構築計画は、最終的な展開テンプレートを計算する間に用いられる一時的なテンプレートであり、ＶＮＦ記述テンプレートと、ユーザ／ＯＳＳ要求から受信した入力パラメータ及び要件（ＫＰＩ）と、中間ＮＣＰ（及びＮＣＰエージェント）計算とを組み合わせた結果である。
ＶＮＦ展開テンプレート：この展開テンプレートは、ＶＮＦテンプレート計算結果であり、クラウド管理システムが物理リソースの実際のインスタンス化を実現し、ソフトウェア及び／又はＶＭイメージを割り当てるために処理することができる情報を含む。
【００７２】
１．２．２構築計画計算
図３は、１つの実施形態によるハードウェア適合可能なＶＮＦインスタンス化プロセスを示している。このプロセスは、ＯＳＳからＶＮＦ要求６００を受信することによって開始する。この要求は、インスタンス化するＶＮＦのタイプを決定し、この機能のための複数の重要業績評価指標（ＫＰＩ）を含む。ＮＣＰはＶＮＦテンプレートリポジトリ２０２から正しいＶＮＦテンプレート２０１を参照する。そこに含まれる情報、例えばハードウェアアーキテクチャ又は他の同様のパラメータと、データベース６１１からの様々な利用可能なクラウド及びネットワークに関する情報とに基づいて、ステップ６１０において、ＮＣＰは候補クラウド及び候補ネットワークを選択し、それに従って計算リソース及びネットワーキングリソースの要求を分割する。この情報は次に、ステップ６１２に示すように選択されたＮＣＰエージェントに適切に分散される。次に、ＮＣＰエージェント２０３は、ステップ６２０において、要求されたリソースの適切な埋め込みの計算を担当する。利用可能なハードウェアへのＶＮＦの適合は、ステップ６２０において実行されることに留意されたい。これについては後に詳細に説明する。
【００７３】
物理リソースマッピングの計算結果は、ステップ６５０に規定されているように失敗する場合も成功する場合もある。マッピングに成功しない場合、要求を取り下げることができ、ＮＣＰは通知される（６５１）。成功する場合、構築計画６５２が一時リポジトリ６５４内に記憶され（６５３）、この要求のためのリソースは、将来の予約が他の要求と衝突することを回避するために予約される（６５５）。ＮＣＰは、ステップ６５６におけるように動作結果を通知され、次に、（ステップ６１０において要求された）様々なクラウドによる様々な埋め込みオファーのうちのいずれを受けるかを、例えば或る特定の効用関数を最大にするか、又は最低の費用を有するオファーを選択することによって決定することができる。次に、提供されたＣＭＳ／ＮＭＳインタフェースを用いることによって、ＮＣＰエージェントは必要とされるコマンドを実行して、選択されたクラウド又はトランスポートネットワークにおいて、要求された仮想リソースを作成する。
【００７４】
図４は、１つの実施形態によるＶＮＦ構築計画（又はＶＮＦ展開計画）計算６２０の詳細な説明を示している。上記で概説したように、このプロセスへの入力は、ＫＰＩのリスト６００及びＶＮＦ記述テンプレート２０１（「性能特性」）を有する要求である。
【００７５】
１つの実施形態によれば、要求６００は少なくとも以下に関する情報を含む。
−インスタンス化されるＶＮＦのクラス／タイプ、例えば新たな３ＧＰＰ準拠サービングゲートウェイ（Ｓ−ＧＷ）。
−幾つかのＫＰＩ、すなわち、必要とされる性能及び／又は容量。
【００７６】
そのような要求の例は、要求されたＳ−ＧＷが毎秒１０ｋベアラを処理し、５０Ｇｂｐｓのピークスループットを提供することができなくてはならないことを規定する場合がある。
【００７７】
１つの実施形態によれば、追加の要求パラメータ６００（「ＫＰＩ」と呼ばれる場合もある）は以下とすることができる。
−制約：
１）Ｓ−ＧＷが約９９．９９９％の利用可能性のフォールトトレランスレベルを有することを規定するフォールトトレランスに対する制約、
２）Ｓ−ＧＷの地理的ロケーション／エリアに対する制約等。
−ＶＮＦ記述子テンプレートリポジトリから選択するＶＮＦをより良好に定義するのに役立つものとする他のパラメータ。
【００７８】
次に、以下のステップがＮＣＰエージェント２０３による計算において実行される。
１．ＮＣＰクラウドエージェントは、どの種類のサーバが利用可能であるかをチェックし、これらのサーバが提供するハードウェアリソースを決定する。ＮＣＰクラウドエージェントは、ステップ６２１において、ＫＰＩへのハードウェアリソースのマッピングを提供するＶＮＦ記述テンプレートからの多次元テーブルを用いることによって（これについては特定の実施形態に従ってセクション１．４においてより詳細に説明する）、各タイプのサーバがどれだけＫＰＩに貢献するかを計算する。これは単純なテーブル参照によって行われ、すなわち、ハードウェアによって提供される値に最も近く、かつそれよりも小さい値がクエリされ、このようにしてサーバごとのＫＰＩが取り出される。
２．次に、サーバタイプごとに、ＮＣＰはステップ６２２のように展開計画を計算及び生成し、すなわち、要求されるＫＰＩ全体に達するのに幾つのＶＮＦモジュールをインスタンス化する必要があるかを計算する。
３．ＶＮＦ記述テンプレートに含まれるＶＮＦモジュールのトポロジ情報に基づいて、ＮＣＰ  Ｃエージェントはまず、ステップ６２３に示すようにこのＶＮＦのトポロジを計算する。次に、ＮＣＰ  Ｃエージェントは異なるＶＮＦモジュール間のリンクのパラメータを導出する。或る特定のモジュール、したがってサーバによって幾つの接続が処理されるかがわかると、各モジュールが生成及び消費するトラフィック量を求め、それを用いてリンクを適切に測ることが可能である。
４．その後、ＮＣＰエージェントは、ステップ６２４におけるように、現在利用可能なデータセンタリソースを考慮に入れることによって、データセンタにおけるこのトポロジの実際の埋め込み及び構築計画６２５を計算する。
５．最後のステップ６２６において、埋め込みの「効用」／費用が、例えばこの展開の予期される費用及び電力消費を合算することによって計算される。
６．結果として、クラウドデータセンタ内にこのＶＮＦを埋め込む費用（又は効用関数）に関する情報を含むＶＮＦ構築計画６５２が得られる。
【００７９】
１．３ＶＮＦ記述テンプレート
ＶＮＦがどのように見えるべきかがＶＮＦ記述子テンプレート２０２に記述されており、すなわち、テンプレートはＶＮＦを記述する。ＶＮＦテンプレートは展開前及び実行時間中のＶＮＦの論理挙動をモデル化する。
【００８０】
すなわち、１つの実施形態によれば、テンプレートは、トポロジ、管理可能性、及び要件の観点でどのようにＶＮＦが定義されるかを定義し、かつ、インスタンス化されると、ＶＮＦを実行時間中に動作させることができるメカニズムを定義する。例えば、異なるリリースバージョン又は試験モジュール構成について同じＶＮＦを実現するための複数のテンプレートが存在することができる。ＶＮＦ記述子テンプレート又はＶＮＦ記述テンプレートは、対応するソフトウェアパッケージとともにＶＮＦのベンダ／実装者によって提供することができる。以下において、提案されるハードウェア適合可能性に関するＶＮＦ記述テンプレートの態様に焦点が当てられる。
【００８１】
１つの実施形態によるＶＮＦ記述テンプレートは以下の属性を含む。
−モジュール。これはＶＮＦを形成するＶＮＦモジュール４０１を定義する。例えば、３ＧＰＰ  Ｓ−ＧＷ  ＶＮＦは、３つのモジュール、すなわち、ロードバランサと、ベアラプロセッサと、トンネルカプセル化ユニットとから構成することができる。ＶＮＦが単一のモジュールから構成されることも起こる場合がある。モジュール情報はコンパイルされたプログラム及び／又は仮想マシンイメージを参照する。さらに、各モジュールは既に展開されたＶＮＦにおいて複数回インスタンス化することができることに留意されたい。
−構成。この属性は、ＶＮＦモジュールの相互接続、すなわち特定のモジュールがアタッチされる入力ＶＮＦモジュール及び出力ＶＮＦモジュールを定義する。この属性は頂点（モジュール）及びエッジ（モジュール間のネットワークリンク）のグラフとして表すことができる。例えば、以下のＳ−ＧＷ  ＶＮＦの構成を考える。１：ｋのトポロジにおいてロードバランサがｋ個のベアラプロセッサに接続され、ｋ個のベアラプロセッサはｋ：１のトポロジにおいてトンネルカプセル化ユニットに接続されている。このシーケンスは、ベアラからの入力がロードバランサからの出力であり、ベアラプロセッサの出力がトンネルカプセル化ユニットの入力であることを意味する。１つの実施形態において、ＶＮＦ構成は固定の仕様ではなく、例えば、１つ又は複数のベアラ処理モジュールを単一のロードバランサに接続することによって、様々な多様性を可能にする。
−フォールトトレランス（Ｒｅｓｉｌｅｎｃｙ）。この属性は、フォールトトレランスの目的でＶＮＦ構成に追加の情報を提供する。特に、この属性は、ＶＮＦを含むＶＮＦモジュールごとに、フォールトトレランスがどのように提供されるか（どのモデルか、例えばアクティブ−バックアップ構成又はアクティブ−アクティブ構成）を詳細に示す。これは、例えば、主要な機能中のモジュールと特定の物理リソースを共有しないために、どこでバックアップモジュールを展開するかを求めるのに有用な情報を含むことに留意されたい。フォールトトレランス構成は、ＶＮＦモジュールの計画、配置及び相互接続性全体に関わる。
−リソース。この属性は、提供されるハードウェアリソースに基づいて様々な構成要素が達成することができるＫＰＩに関する情報を提供する。その一実施形態は、以下のセクション１．４において詳細に説明される。
−バージョン。この属性は、ＶＮＦのソフトウェアバージョン又は仮想マシンイメージバージョンに関する情報を定義する。
【００８２】
１．４リソース：（ＶＮＦ記述テンプレートの）ＫＰＩマッピングテーブル
上記で概説したように、或る特定のモジュールが達成する性能は、提供されるハードウェアに依拠する。この関係は、ＶＮＦ記述子テンプレートのリソースパラメータにおいて多次元テーブルとして規定される。これによって既存のパラダイム「ハードウェアがソフトウェアに従う」が逆転することに留意されたい。すなわち、モジュールに対するハードウェア要件を与える代わりに、提供されるハードウェアリソースに基づいてモジュールがどれだけの性能を達成するかを計算する手段が提供される。
【００８３】
リソース：ＫＰＩテーブルは、サポートされるベアラ数及びＧｂｐｓ単位の目標スループットのようなｍ個のアプリケーションレベル重要業績評価指標（ＫＰＩ）へのｎ個のハードウェア性能パラメータ（例えば、ＧＦＬＯＰＳ、ＲＡＭ、ＩＯ容量）のマッピングを提供する。この概念の視覚化例（２：１のマッピングを用いる）が図５に示されている。
【００８４】
マッピングテーブルは、ＣＰＵアーキテクチャ及びバージョン（例えば、Ｉｎｔｅｌ  ｉ５プロセッサであるか又はＩｎｔｅｌ  ｉ７プロセッサであるか）のような特定のリソースを定義することを回避し、ＧＦＬＯＰＳ、ＲＡＭ、レベル１キャッシュ量等のような抽象パラメータを用いる。例えば、そのような抽象化によって、対応するＶＮＦ及びマッピングテーブルが作成された時点に存在しなかった新たなプロセッサについても埋め込みを計算することが可能になる。
【００８５】
別の態様は、１つの実施形態によれば、ＶＮＦが展開されると、ＮＣＰがマッピングテーブルを記憶し、含まれる値を調整することができるというものである。このようにして、ＮＣＰにおいて、モジュールが実世界のワークロードの下で達成する実際のリソース：ＫＰＩマッピングに関する知識を取得する自己学習機能を実施することができる。これは、インターネットにおけるトラフィック傾向が非常に迅速に変化し、これに起因してモジュール性能が変化し得るので重要である可能性がある。
【００８６】
例として、より大量のビデオ消費に起因して生じる平均パケットサイズの変化を考慮することができる。このため、ＶＮＦモジュールが同じ量のＧｂｐｓを処理するのに必要なＣＰＵリソースをより少なくすることができる。なぜなら、ＶＮＦモジュールはパケットヘッダのみを処理すればよく、その場合にパケットヘッダ数が低減するためである。
【００８７】
このため、この目的に向けて、ＮＣＰはマッピングテーブルのコピーを記憶し、ＣＭＳ（ハードウェア側の情報を提供する）とＶＮＦ自体（アプリケーションレベルのパラメータに関する情報を提供する）との双方からのモジュール性能に関するフィードバックを結合することができる。このため、６２０に従って埋め込みを計算するために、ＮＣＰはベンダのＶＮＦ記述テンプレートによって提供される値ではなく、記憶されたテーブルからの更新値を用いることができる。
【００８８】
１．５データ構造
１つの実施形態によるＶＮＦテンプレートを処理し、ＶＮＦ展開テンプレートを計算する方法は、２つの主要なデータベース及び／又はリポジトリを用いる。第１のデータベースはＶＮＦ記述テンプレートリポジトリ２０２である。このリポジトリは、ＮＣＰがインスタンス化することができる記述テンプレートをリストアップする。
【００８９】
このリポジトリに対しクエリが実行され、これらのクエリは１つ又は幾つかのパラメータに基づくことができる。例えば、ＶＮＦへのクエリは特定の規格に準拠した特定のＶＮＦベンダを指定する場合がある。表１は、ＶＮＦ記述テンプレートリポジトリの実現例を示している。
【表１】
0006007217.tif 000002
【００９０】
第２のデータベースは、物理リソース６１１に関する情報を含む。例として表２を参照されたい。
【表２】
0006007217.tif 000003
【００９１】
ＮＣＰは、幾つかのクラウド及びネットワークリソース領域に関する知識を有する。しかしながら、詳細レベルは低く、利用可能なリソースのイベントリ、例えば或る特定のクラウドにおいて利用可能なサーバのタイプに関する要約された情報のみを含む。そのようなクラウドリソース記述及びネットワークリソース記述のための特定のテーブルが存在し、これらはテーブル２からリンクされ、この例が表３及び表４に示されている。
【表３】
0006007217.tif 000004
【表４】
0006007217.tif 000005
【００９２】
６２０においてＶＮＦの構築計画を計算するために、ＮＣＰはクラウドのローカルリソースデータベース６４０にもアクセスする必要がある。このデータベースは、現在のデータセンタにおける正確な負荷状況に関する最新情報、すなわち、いずれのサーバが用いられ、いずれが空いており、ネットワーク負荷がどれ程であるか等を含む。このデータベースは、ＣＭＳがクラウドを制御するのに用いるものと同じであることができる。実行ユニットにおける実際の埋め込み又は実施はＣＭＳを介して実行されることになるので、目的を果たすには読み出しアクセスで十分であることに留意されたい。データベースはデータセンタに対しローカルであり、データベースのコンテンツは頻繁に更新されるので、最新情報に直接アクセスするために、ＣＭＳ／このデータベースと同じ場所に配置されるＮＣＰ  Ｃエージェントの概念が提案される。例が表５に示されている。
【００９３】
ＮＣＰ  Ｃエージェントは、リソースの抽象化に関する情報、例えば、特定のＣＰＵモデルが提供するＧＦｌｏｐｓ数に関する情報を必要とする。これはこのテーブルに含めることもできるし、何らかの他の場所に記憶することもできる。
【表５】
0006007217.tif 000006
【００９４】
１．６ＶＮＦ初期化フローチャート
図６は、少なくとも１つのＶＭ４０２上で実行される少なくとも１つのＶＮＦモジュール４０１からなる仮想化ネットワーク機能４００を初期化するためのシーケンスの例を示している。ステップＳ１０１において、オペレーティングサポートシステムは、ネットワーク構成プラットフォームに新たなＶＮＦをセットアップするように命令する。このステップは、セットアップ（SETUP）要求メッセージ６００のＯＳＳ−ＮＣＰインタフェースを介した送信を含む。このメッセージは、限定ではないが、セットアップするネットワーク機能のタイプ、ネットワーク機能の所望の容量、ＯＳＳからのログイン認証情報、及び少なくともジオロケーションデータを含む要件に関する情報を含む。ＮＣＰ（２００）は、セットアップメッセージ６００を受信すると、メッセージを処理する。ステップＳ１０２において、ＮＣＰは、以前のメッセージにおいて要求されたＶＮＦのタイプに適したテンプレート２０１をリポジトリ（２０２）からロードする。テンプレートデータと、セットアップメッセージにおいてＯＳＳによって表された容量及び要件とに基づいて、ＮＣＰはステップＳ１０２におけるように候補クラウドを計算する。
【００９５】
次のステップは、見積り（QUOTE）メッセージを選択されたクラウド、特に対応するＮＣＰ  Ｃエージェント２０３に送信することを含む。エージェントは見積り要求を受信すると、ステップＳ１０４のようにＣＭＳを照会することによってクラウドにおいて利用可能なリソースのオンデマンド更新を実行することができる。このオプションのステップ（すなわち、エージェントは定期的な更新も実行することができる）の後、エージェントはステップＳ１０５に示すような手順６２０を実行して、利用可能なクラウドリソースにおけるＶＮＦ埋め込みの効用費用とともに構築計画を計算する。後続の要求に対して衝突を回避するために、エージェントは埋め込み計算Ｓ１０６において計画されたリソースの予約を行う。
【００９６】
次に、エージェントはステップＳ１０７におけるように、ＶＮＦ埋め込みの結果とともに主要ＮＣＰにメッセージを返送する。この際、ＮＣＰはステップＳ１０８において、少なくとも１つのＮＣＰエージェントからのクラウドリソース見積り及びネットワークリソース見積りをチェックし、ＶＮＦが最終的にインスタンス化されることになる場所を選択することができる。したがって、ＮＣＰは選択されたエージェントにＶ−ＳＥＴＵＰメッセージを送信する（Ｓ１０９）。これらは、ステップＳ１１０に規定されているように、対応するＣＭＳインタフェースＡＰＩに従って特定のＶＮＦ展開テンプレート変換を実行しなくてはならない場合がある。
【００９７】
この後、展開（DEPLOY）コマンドＳ１１１がＣＭＳに送信され、ＣＭＳは、ステップＳ１１２に示すように新たなＶＮＦ４００の物理リソース及び仮想リソースを割り当てる。エージェントは、ＣＭＳからの確認を受信した後（ＯＫメッセージＳ１１３を参照されたい）、ＶＮＦ展開を記憶し、ステップＳ１１４、Ｓ１１５、Ｓ１１６、及びＳ１１７に従って、ＶＮＦに向けて任意の特定のＶＮＦ仮想構成を実行する。
【００９８】
ＶＮＦインスタンス化の最終ステップは、ＮＣＰエージェントからＮＣＰへのＶ−ＳＥＴＵＰ確認応答を含み（ステップＳ１１８を参照されたい）、ＮＣＰは次にインスタンス化の結果を記憶することができる（Ｓ１１９）。これらの全てのステップが完了すると、ＮＣＰはステップＳ１２０においてセットアップ完了（SETUP-COMPLETE）メッセージをＯＳＳに送信し、ネットワーク機能の展開及び起動が完了し、このネットワーク機能が以後ＯＳＳによって動作を管理されるべきであることを通知する。
【００９９】
１．７インタフェース
説明される実施形態において、以下のインタフェースが用いられる（図２を参照されたい）。
−ＮＣＰ  Ｃエージェント対ＣＭＳ（１０８）：このインタフェースは、既存のコマンドを用い、クラウドマネージャを用いて仮想マシンを展開及びインスタンス化する。既存のクラウド管理システム、例えばＯｐｅｎＳｔａｃｋ、ＡｍａｚｏｎのＥＣ２等は、既に仮想マシンのインスタンス化及び管理を可能にするアプリケーションプログラマブルインタフェース（ＡＰＩ）を提供している。
−ＮＣＰ  Ｎエージェント対ＴＭＮＳ（１０９）：このインタフェースは既存のＡＰＩを用いてネットワーク全体の管理システムにアクセスし、ネットワークにわたって接続性を要求するのに用いられる。本発明において、インタフェース１０９は、トランスポートネットワークリソースの管理に関連付けて特許請求されることも説明されることもない。そのようなインタフェースはより詳細な要素管理プロトコルによってネットワーク要素、例えばスイッチ、ルータ等を構成するのに用いられる。
−ＯＳＳ−ＶＮＦ（１０２）：このインタフェースは、ハードウェアベースのネットワーク機能を管理するのに用いられる現在の要素及びネットワーク管理インタフェースにおいて同じままである（又は大部分がそれらに基づく）ことになる。このインタフェースは、ネットワーク管理、すなわち特定機能管理パラメータによって実行される論理サービスを管理するのに主に用いられる。
【０１００】
加えて、既存のインタフェースに対する以下の新たなインタフェース／変更が提供される。
−ＯＳＳ−ＮＣＰ（１０３）：このインタフェースを介して、ＯＳＳはＮＣＰにＶＮＦのライフサイクルに関する要求を行う。例は、新たなＶＮＦのインスタンス化又はＶＮＦ容量の更新（例えば、Ｓ−ＧＷが処理することができるベアラ量の増加／減少）である。新たなパラメータは以下の通りとすることができる。要求（Ｓ１０１）は、少なくともＫＰＩ（例えば、ベアラ量及び集計した負荷）及びＶＮＦが配置されることになるロケーション（地理的ロケーション又はネットワークレイテンシの観点のロケーション）を含む。
−ＮＣＰ−ＶＮＦ（１１１）：ＮＣＰをＶＮＦの仮想化管理ロジック（例えば、ＶＮＦの他のモジュールを管理する特定のＶＮＦモジュール）に相互接続する新たなインタフェース。このインタフェースを介して、ＮＣＰはＶＮＦ及びそのＶＮＦのモジュールに、その仮想化環境、すなわちマッピング「ＶＮＦモジュール対ハードウェアプラットフォーム」を通知し、このモジュールに配分することができる最大セッション数を計算する。
−ＮＣＰ−ＮＣＰ−Ｃエージェント（１０４）：見積り要求（Ｓ１０３／６１２）は、要求パラメータ（ＯＳＳからのＫＰＩ…）及びインスタンス化されることになるＶＮＦ記述子テンプレートを含む。応答メッセージは、要求が送信されたクラウド内にＶＮＦを埋め込む費用、効用と、見積りがどれだけの期間有効であるかのタイマとをそれぞれ提供する。
【０１０１】
１．８例示的な使用事例
以下において、本発明の実施形態の可能な使用事例が説明される。
【０１０２】
１．８．１単一レベルのロードバランサ
第１の使用事例が図７において概略的に示されている。このアーキテクチャにおいて、ＶＮＦは或る特定の量のトラフィックの処理を担当し、外部に対しては、ＶＮＦの詳細は単一のエントリポイントとしての役割を果たすロードバランサの背後に隠れている。図の左側は、強力なサーバが利用可能であり、僅かな処理ノードしか必要でない場合の展開を示している。図の右側は、処理リソースがより少ないサーバの場合の展開を示している。この場合、同じ全体性能を達成するために、説明された計算及びシグナリングによって、はるかに多くの処理ノードがインスタンス化されることになる。
【０１０３】
１．８．２マルチレベルロードバランサ
図８における実施形態は、様々な能力を有するデバイスをどのように組み合わせることができ、適切なスケーリングを計算することができるかを示している。またここでは、複数の処理ノードがデータプレーンロードバランサの背後で展開されることになるシナリオが示されているが、ここではロードバランサに焦点を当てている。
【０１０４】
データプレーンロードバランサは、ソースＩＰアドレス、宛先ＩＰアドレス、入力ポート及び出力ポートの４つ組に依拠してパケットを転送することが可能であるべきである。
【０１０５】
図の左側に概略を示した事例において、要求された量のエントリを保持することができ、エントリあたり４つのプロトコルフィールドに合致することもできる単一のスイッチ（例えばＯｐｅｎＦｌｏｗスイッチ）が利用可能である。このため、データプレーンロードバランサとして単一のスイッチで十分である。図の右側は、そのような強力なスイッチが利用可能でない事例を示している。
【０１０６】
この例において、要求された４つのプロトコルフィールドに合致することができるが、あまり多くのエントリを保持することができない幾つかの利用可能な小さなスイッチが存在するか、又は全てのエントリを保持することができるが全てのプロトコルフィールドに合致することができない単一のスイッチが存在する。この場合、それにもかかわらず、利用可能なハードウェアに展開を適合させることにより、少数のフィールドとしか合致しない単一の大きなスイッチを、全ての要求されたフィールドと合致することができる複数の小さなスイッチと組み合わせる埋め込みを計算することが可能である。
【０１０７】
実施形態によるそのような計算について、ＶＮＦ記述テンプレートが、そのような適合をどのように実行することができるかに関する情報を含むべきであり、すなわち、異なる可能な展開オプション（オプション１：全てのフィールドに合致する単一の大きなスイッチ、オプション２：全てのフィールドに合致することができる複数の小さなスイッチと対にされた、全てのフィールドの一部分と合致する単一の大きなスイッチの階層的展開）に関する情報を含むべきであることに留意すべきである。
【０１０８】
１．８．３制御プレーンのスケーリング
第３の応用例が図９に与えられている。ここで、ＯｐｅｎＦｌｏｗ（ＯＦ）スイッチのネットワークは、適切に寸法合わせされた制御プレーン（Ｃプレーン）によって制御されるべきであり、規定されるＫＰＩは、秒ごとに処理することができるメッセージ量である。サーバがそのようなメッセージを処理する能力は、中でも、そのＣＰＵ速度及びそのネットワークインタフェースの速度に関する。単一のサーバが十分なＣＰＵ速度又はインタフェース速度を提供しない場合、ＶＮＦ記述テンプレートは、１つ又は複数の追加のサーバが組み合わされること、及びそれらのサーバが、例えばネットワークトポロジ情報を交換することを可能にするために、それらのサーバ間で追加の協調チャネルが確立されることを規定する。図の左側において、単一の強力なサーバに関する事例が示されている。右側は、パワーが劣る複数のサーバが組み合わされる展開が示されている。
【０１０９】
幾つかの非常に詳細な実施形態を説明した後、次に、幾つかのより基本的な実施形態及びそれらの背後にある根拠を示す。
【０１１０】
まず、図１０は上側部分において、例えば、ロードバランサのために４ＧＢ  ＲＡＭを有するＥ７  ＣＰＵが必要であり、ベアラ処理のために１６ＧＢ  ＲＡＭを有するＥ５  ＣＰＵが必要であることを宣言することによって、「ハードウェアがソフトウェアに従う」パラダイムに基づく「従来の手法」を示している。これに基づいて、古い手法は仮想化を実施する。
【０１１１】
下側に示す「新たな手法」は、「性能特性」、例えば、Ｅ５が毎秒５ギガビットで５００ベアラを処理することができること、及びＥ７が１０Ｇｂｐｓで１５００ベアラを処理することができることを考慮に入れる。ＫＰＩの観点で利用可能なハードウェアの性能を示すこの「性能特性」によって、最適化に対し更にオープンな、より柔軟な仮想化を選択することが可能になる。
【０１１２】
図１１は、次にこの手法をどのように実施することができるかをより詳細に示している。（例えば、ネットワーク事業者からの）１００００ベアラのＳ−ＧＷの要件に基づいて、ＮＣＰは可能なＶＮＦ記述及びそれらの対応するＫＰＩを参照する。この結果、２つの可能な実施態様が得られ、利用可能なハードウェアに基づくＶＮＦ実施態様の性能特性に基づいて、「上側」は７つのサーバを必要とし、下側は２０個のサーバを必要とする。
【０１１３】
次に同様に考慮に入れられるのは、異なる実施態様の対応するネットワークトポロジである。上側において、ベアラ処理へのロードバランサの１：７のマッピング（７つのサーバに起因する）が存在し、下側において、１：２０のマッピングが存在する。
【０１１４】
実際の埋め込みのネットワークトポロジに基づいて、上側の例の具体的な実施態様は、下側よりも「分散」しており（図１１の下部よりも上部においてより分散したＶＮＦを参照されたい）、結果として更なるネットワーキングリソースが必要とされる。そしてこれは、次に、仮想化ベンダによって計算される「費用関数」に負の影響を及ぼす場合があり、したがって、図１１の例において費用関数の観点におけるより有利な埋め込みは下側の例である。
【０１１５】
図１２は、本発明による計算フローの別の実施形態を示している。要求される性能（ＫＰＩ）及びハードウェアパラメータをＫＰＩにマッピングするそれらの「性能特性」を有する利用可能なハードウェアが入力され、次に必要なモジュール数が計算される。次に、トポロジが考慮に入れられ、対応するネットワーク要件を用いた埋め込みが計算される。次に、最終的に、様々な可能な埋め込みについて費用関数が計算され、次に最も効果的な埋め込みが選択され実施される。
【０１１６】
図１３は一実施形態を示し、この実施形態によれば、ＶＮＦモジュールはそのリソース、例えばそのノード特性及びそのネットワーク特性を「通知」される。この実施形態では、左側に示すＶＮＦはロードバランサを実施するのに対し、右側のＶＮＦはベアラ処理を実施する。この実施形態において、ＶＮＦがインスタンス化された後、ＶＮＦは、各ＶＮＦモジュールに転送される負荷を正しく測るために、そのＶＮＦに割り当てられたリソースを通知される。これは、「計算」（様々なＶＮＦモジュールに割り当てられたハードウェアリソースをＶＮＦに通知する）及び「ネットワーク」（ＶＮＦモジュールを相互接続するために予約されたリンクのパラメータをＶＮＦに通知する）に分解することができる。
【０１１７】
図１３に例が示され、ここでＮＣＰはＶＮＦに、リンクＣがリンクＡ及びＢよりも少ない容量を有すること（このためＶＮＦが、Ｃを介してアタッチされたノードにより小さな負荷を割り当てる可能性も最も高いこと）を通知する。各ＶＮＦが、この情報を受信する専用の「ＶＮＦマネージャモジュール」を有すると仮定することができる。
【０１１８】
１つの実施形態によれば、以下のインタフェースが提供される。
ＮＣＰ−ＶＮＦ（１１１）：ＮＣＰをＶＮＦの仮想化管理ロジック（例えば、ＶＮＦの他のモジュールを管理する特定のＶＮＦモジュール）に相互接続する新たなインタフェース。このインタフェースを介して、ＮＣＰはＶＮＦ及びそのＶＮＦのモジュールに、その仮想化環境、すなわちマッピング「ＶＮＦモジュール対ハードウェアプラットフォーム」を通知し、このモジュールに配分することができる最大セッション数を計算する。インタフェース１１１を介して、ＮＣＰはＶＮＦ管理モジュールに、そのＶＮＦ管理モジュールのＶＮＦモジュールに配分されたリソースを通知する。
・リソース計算の観点から、この情報は、ＣＰＵユニット数、ＣＰＵユニットのタイプ（仮想／物理）、ＣＰＵフラグ、ＣＰＵキャッシュサイズ、ＣＰＵ周波数、ＣＰＵモデル、ＣＰＵアーキテクチャ（３２／６４ビット）、揮発性メモリの量（ＲＡＭ）、ネットワークインタフェースカードモデル…とすることができる。
・ネットワーキングリソースの観点から、この情報は、ＶＮＦモジュールを相互接続するリンクの詳細、すなわちリンク帯域幅、リンクレイテンシ、フォールトトレランス、トラフィック損失…を記述するが、リンクをどのように使用するか、例えば送信パケットにおいていずれのヘッダフラグをセットするか、又はいずれのアドレス空間を用いることができるか（及びいずれを用いることができないか）という情報も含むことができる。
ＯＳＳ−ＮＣＰ（１０３）：このインタフェースを介して、ＯＳＳはＮＣＰにＶＮＦのライフサイクルに関する要求を行う。例は、新たなＶＮＦのインスタンス化又はＶＮＦ容量の更新（例えば、Ｓ−ＧＷが処理することができるベアラ量の増加／減少）である。この実施形態における新たなパラメータは以下の通りとすることができる。要求（Ｓ１０１）は、少なくともＫＰＩ（例えば、ベアラ量及び集計した負荷）及びＶＮＦが配置されることになるロケーション（地理的ロケーション又はネットワークレイテンシの観点のロケーション）を含む。
【０１１９】
以下において、１つの実施形態によるｌ：ｋマッピングを説明する。
【０１２０】
例えば図７に示すように、ロードバランサの異なる実施態様では、リンクのためのリソース量は、計算されるトポロジ及びリンクが相互接続するＶＮＦモジュールのサポートされるＫＰＩの量にも依拠する。
【０１２１】
例において、これは、「大きなサーバ」の例（より少ないリンクを有する例）について太線によって視覚化され、個々のリンクは「小さなサーバ」の例（図７の右側の例）におけるリンクよりも多くの帯域幅を必要とする。
【０１２２】
ＶＮＦ記述子テンプレートにおけるＶＮＦトポロジを記述するために、１つの実施形態によれば２つのものが必要である。
−リンクの多様性を示すＶＮＦモジュールを相互接続するためのグラフの記述（例えば、１：ｎの多様性を有する「ロードバランサ−ベアラプロセッサ」の相互接続）→これはＵＭＬクラス図に匹敵するものであるので、更に詳細に説明する必要がない。
−リンクの要件は、アタッチされるＶＭのＫＰＩに依拠して規定される。これは、このリンクが相互接続する２つのＶＭのｌ個のＫＰＩをｋ個のリンク要件にマッピングする、ｌ：ｋマッピングテーブルによって行われる。
【０１２３】
このｌ：ｋマッピングテーブルを用いて、仮想化実施態様のトポロジを定義し検討することができる。
【図３】
0006007217.tif 000007
【図１】
0006007217.tif 000008
【図２】
0006007217.tif 000009
【図４】
0006007217.tif 000010
【図５】
0006007217.tif 000011
【図６】
0006007217.tif 000012
【図７】
0006007217.tif 000013
【図８】
0006007217.tif 000014
【図９】
0006007217.tif 000015
【図１０】
0006007217.tif 000016
【図１１】
0006007217.tif 000017
【図１２】
0006007217.tif 000018
【図１３】
0006007217.tif 000019