(57)【要約】  本発明は、サービスファンクションチェーンの管理に関する方法、装置、及びコンピュータプログラム製品に関する。マネージメントファンクションは、サービスファンクションチェーンのソフトウェア構成を効率的に制御し、そして動的な生活上のトラフィックに対処するための負荷バランシングの目的でバーチャルマシンを適応的に呼び出し、再構成し又は停止することに向けられる。【選択図】図３
2018528526.tif 000002
【特許請求の範囲】
【請求項１】
多数のバーチャルマシンが所与のハードウェアで実行され、バーチャルマシンの単一のインスタンスが完全なサービスファンクションチェーンを実行し、前記サービスファンクションチェーンが多数のサービスファンクションより成る適応サービスファンクションチェーン構成のための方法において、
−特定のサービスファンクションチェーンを実行する各バーチャルマシンの処理負荷を連続的に測定し、及び
−あるバーチャルマシンの処理負荷が規定の負荷レベルを越える場合には、特定のサービスファンクションチェーンを実行できる付加的なバーチャルマシンがその特定のサービスファンクションチェーンを実行するようにアクチベートされ、一方、
−あるバーチャルマシンの処理負荷が規定の負荷レベルより低い場合には、前記バーチャルマシンの特定のサービスファンクションチェーンの作用負荷が、サービスファンクションチェーンを実行できる別のバーチャルマシンへ転送され、その結果、前記バーチャルマシンの特定のサービスファンクションチェーンがデアクチベートされる、
というステップを含む方法。
【請求項２】
サービスファンクションチェーンの実行がデアクチベートされたバーチャルマシンを使用して、規定の負荷レベルを越えるバーチャルマシンのサービスファンクションを実行する、請求項１に記載の方法。
【請求項３】
任意のサービスチェーンファンクションを実行するのに必要なソフトウェアコンポーネントが全てのバーチャルマシンにロードされる、請求項１又は２に記載の方法。
【請求項４】
サービスファンクションチェーンリソースマネージャーは、バーチャルマシンにおけるサービスファンクションチェーンのアクチベーション又はデアクチベーションを実行する、請求項３に記載の方法。
【請求項５】
ソフトウェアコンポーネントのサブセットは、バーチャルマシンにロードされ、そしてソフトウェアコンポーネントのロードされたサブセットは、１つ又は多数のサービスチェーンファンクションを実行するのに充分である、請求項４に記載の方法。
【請求項６】
バーチャルマシンのインスタンスのサービスファンクションチェーンは、サービスファンクションチェーン記述子により構成される、請求項１から５のいずれかに記載の方法。
【請求項７】
サービスファンクションチェーンそれ自体を実行するバーチャルマシンは、処理負荷を測定する手段を含み、又は基礎的なインフラストラクチャー（ＨＷ又はオペレーティングシステム）は、処理負荷を測定し、そしてこの情報は、インフラストラクチャーマネージャー及びサービスファンクションチェーンリソースマネージャーへ規則的に転送される、請求項１から６のいずれかに記載の方法。
【請求項８】
前記処理負荷は、プロセッサ負荷、メモリスペース、空きメモリのような関連パラメータ、及び負荷測定に適した他のパラメータ、或いは負荷測定パラメータの組み合せにより定義される、請求項７に記載の方法。
【請求項９】
−多数のバーチャルマシンを所与のハードウェアでサービスチェーンとして実行し、
−バーチャルマシンの単一のインスタンスが完全なサービスファンクションチェーンを実行し、前記サービスファンクションチェーンは多数のサービスファンクションより成るものであり、
−特定のサービスファンクションチェーンを実行する各バーチャルマシンの処理負荷が連続的に測定され、
−あるバーチャルマシンの処理負荷が規定の負荷レベルを越える場合には、特定のサービスファンクションチェーンを実行できる付加的なバーチャルマシンがその特定のサービスファンクションチェーンを実行するようにアクチベートされ、一方、
−あるバーチャルマシンの処理負荷が規定の負荷レベルより低い場合には、前記バーチャルマシンの特定のサービスファンクションチェーンの作用負荷が、サービスファンクションチェーンを実行できる別のバーチャルマシンへ転送され、その結果、前記バーチャルマシンの特定のサービスファンクションチェーンがデアクチベートされる、
ように構成された装置。
【請求項１０】
バーチャルマシンの前者のアクティブなサービスチェーン実行がデアクチベートされた場合には、前記バーチャルマシンは、規定の負荷レベルを越えた別のバーチャルマシンのサービスファンクションチェーン実行を引き継ぐことができるよう更に構成された、請求項９に記載の装置。
【請求項１１】
任意のサービスチェーンファンクションのための必要なソフトウェアコンポーネントを全バーチャルマシンへロードし、そしてそれらを実行するよう更に構成された、請求項１０に記載の装置。
【請求項１２】
バーチャルマシンにおけるサービスファンクションチェーンをアクチベート又はデアクチベートできるサービスファンクションチェーンのリソースマネージャーソフトウェアを付加的に実行するよう更に構成された、請求項１１に記載の装置。
【請求項１３】
ソフトウェアコンポーネントのサブセットをバーチャルマシンへロードするように更に構成され、ソフトウェアコンポーネントのロードされたサブセットは、多数のサービスチェーンファンクションを実行するよう構成された、請求項１０から１２のいずれかに記載の装置。
【請求項１４】
サービスファンクションチェーンとして実行するバーチャルマシンは、サービスファンクションチェーンそれ自体が処理負荷を測定できるようにするか、又はその基礎的なＨＷ又はオペレーティングシステムからこの情報を規則的に収集できるようにする付加的なソフトウェアコンポーネントを含む、請求項９から１３のいずれかに記載の装置。
【請求項１５】
非一時的なコンピュータ読み取り可能な媒体上で実施されるコンピュータプログラムにおいて、
−所与のハードウェア上のサービスチェーンとして多数のバーチャルマシンを実行するためのコード、
−多数のサービスファンクションより成る完全なサービスファンクションチェーンを実施するバーチャルマシンのインスタンスを実行するためのコード、
−特定のサービスファンクションチェーンを実行する各バーチャルマシンの処理負荷を連続的に測定するためのコード、
−あるバーチャルマシンの処理負荷が規定の負荷レベルを越える場合に、特定のサービスファンクションチェーンを実行できる付加的なバーチャルマシンが特定のサービスファンクションチェーンを実行するためにアクチベートされることを制御するコード、及び
−あるバーチャルマシンの処理負荷が規定の負荷レベルより低い場合に、前記バーチャルマシンの特定のサービスファンクションチェーンの作用負荷が、そのサービスファンクションチェーンを実行できる別のバーチャルマシンへ転送され、その結果、前記バーチャルマシンの特定のサービスファンクションチェーンがデアクチベートされることを制御するコード、
を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスファンクションチェーンの管理に関する方法、装置、及びコンピュータプログラム製品に関する。より詳細には、本発明は、サービスファンクションチェーンの負荷及びソフトウェア構成の制御に関する方法、装置、及びコンピュータプログラム製品に関する。
【背景技術】
【０００２】
事業者ネットワークＴＣＯを縮小するための手段は、ネットワークファンクションのバーチャル化、及び異なるネットワークファンクション用の共通のデータセンター（ＤＣ）ハードウェアの使用である（ＥＴＳＩ  ＮＦＶ（ネットワークファンクションバーチャル化スタディグループ）の文書を参照されたい）。
【０００３】
これは、サービスファンクションチェーン化にも適用される。サービスファンクションチェーン化は、典型的に、サービスファンクションのセットを所与の順序で呼び出すことによりユーザ装置とアプリケーションプラットホーム（ウェブ、ビデオ、ＶｏＩＰ、等）との間でセッションフローを観察し、変更し、又は終了及び再確立もする。所与のサービスファンクションチェーン（ＳＦＣ、以下、時々、「チェーン」と表わされる）に含まれるサービスファンクションは、負荷バランシング、ファイアウオール、侵入防止、等を含む。
【０００４】
所与のＳＦＣイネーブル型ドメインは、同じサービスファンクションの多数のインスタンスを含む。サービスファンクションインスタンスは、所与のＳＦＣに追加されたり又はそこから除去されたりする。ＳＦは、共同配置されるか、個別の物理的ノードに埋設されるか、又はバーチャル化される。
【０００５】
今日、移動ネットワーク事業者は、いわゆる“Ｇｉ−ＬＡＮ”（ＮＡＴ、ＴＣＰオプチマイザー、ファイアウオール、ビデオオプチマイザー等の）において多数の付加価値パケット処理ファンクションを提供している。それらは、ＳＦＣと考えられ、ここで、ＳＦＣは、トラフィックを引き回す必要のあるボックスのチェーンにより実施される。これらの解決策の効率の悪さ及びこれを管理するための複雑さが、３ＧＰＰ  Ｒｅｌ．１３（柔軟な移動サービス操向ＦＭＳＳ）及びＩＥＴＦ（ＳＦＣ、サービスファンクションチェーン化）において標準化活動を引き起こした。
【０００６】
例えば、ネットワークファンクションのほとんどのケースにおいて（セキュリティ、ＮＡＴ、負荷バランシング、等）、フローの一部分だけが全てのファンクションによる処理を要求し、フローの残りの部分は、限定された処理又は他の処理を要求する。柔軟なフロー引き回しにより、要求されるリソースの量を減少することができる。
【０００７】
ネットワーク柔軟性の次のレベルは、図５で導入されたものとなることが期待される。サービスを終了するための提案された終了（例えば、５Ｇ  ＮＯＲＭＡ）に基づいて調整されたネットワークファンクションを導入するためリサーチプロジェクトが設定される。その考え方は、ＲＡＮ及びコアの現在ネットワークファンクションを分解し、そして両方に特有のサービスを選択することである。
−分解されたファンクションの風味（例えば、サービスに基づく異なるスケジューリングアルゴリズム）、及び
−位置（より中心であるか又はより移動端）。
【０００８】
これは、非常に多数の基本的ファンクションモジュールからのネットワークサービスを効率的にコンポーズしそして接続する必要性を高める。使用されそして導入されるテクノロジーは、アクセステクノロジーとは独立していることに注意されたい。
【０００９】
一般的に、これらのサービスファンクション（ＳＦ）をクラウドにおいて最も有効に且つ効率的に具現化することが目的である。現在の解決策（以下を参照）は、前者の物理的「ボックスファンクション」を単にバーチャル化して、ＶＮＦ（バーチャルネットワークファンクション）になるようにし、そしてデータセンター（ＤＣ）により与えられる接続フレームワークを使用して、要求されたデータ経路を生成する。
【００１０】
しかし、ＤＣを通して全てのユーザプレーントラフィックを引き回すことは、かなりの挑戦である。ＥＴＳＩ  ＮＦＶ  ＩＮＦ００５文書を参照されたい。
「データプレーンスループットは、ＮＦＶアーキテクチャー［・・・］に対する一般的な問題である。ＮＦＶＩノードにおけるバーチャル化ネットワークファンクション展開のスループット容量は、物理的ネットワークファンクションを具現化するネットワーク要素に対するものであるので基本的な事柄である。」
【００１１】
ＳＦチェーンにおける典型的なＳＦは、あるスタティックなそして比較的小さなＣＰＵコードを含むがスループット及び／又は低いレイテンシーに関して高い要求をもつアプリケーションである。ネットワークファンクションインフラストラクチャー（ＮＦＶＩ）については、これは、限定された計算要求であるが高いネットワーク要求を意味する。
【００１２】
現在、この問題は、今日バーチャルスイッチにより典型的に実施されるクラウド環境における接続／ネットワークのデータ経路処理の加速によって対処されている。
【００１３】
幾つかのＯＳファンクション（ソケットＡＰＩ及びｖＮＩＣ）が拡張されるか、或いはネットワーキングとアプリケーションファンクションとの間に新規な直接インターフェイスが導入される（例えば、インテルのＤＰＤＫ及び／又はＳＲ−ＩＯＶを使用して高速パケット転送のためのホスト及び／又はゲストＯＳをバイパスする）解決策が存在する。
【００１４】
これらの手段により、サービスファンクションをホストするバーチャルマシン（ＶＭ）間のネットワーキング性能を加速できるが、依然、多数の問題が残される。
−各ＶＭ−ＶＭ通信により付加的なレイテンシーが導入され、
−この遅延がどれほど大きいか予想できず：これは、トポロジー、例えば、同じブレード、ラック、等に存在し且つ異なる加速メカニズムを使用するＶＭに依存し、
−各個々のＳＦをスケーリングし且つ負荷バランスさせる必要があり（ＤＣにおけるスケーリングが、通常、特定のネットワークファンクションを実行するのに使用されるＶＭの数を増加（スケールアウト）又は減少（スケールイン）することで実施されることから問題が生じ）、
−ＶＭの数が多いためにＶＭ／ＳＦインスタンス化のリソース割り当て及びスケジューリングが複雑であり、且つＶＩＭ及びネットワーキングコントローラにより考慮する必要のある制約が存在する（遅延バジェット、スループット）。
【００１５】
又、“ＩＴ−ＤＣ”（ウェブサーバーのためのＤＣのような汎用ＤＣ）を“ＴｅｌｃｏクラウドＤＣ”（テレコミュニケーションサービス専用のＤＣ）へ変化させるべき付加的な特徴がコストを高め、且つＩＴ−ＤＣの典型的な作用負荷に必要でない複雑さが追加される場合にスケールの経済性を破壊することになるかどうかも考慮される。従って、ＴｅｌｃｏクラウドＤＣサービスを改善するための新規な手段がバーチャル化の複雑さを高めることがある。
【００１６】
図１は、従来技術で提案された構成を示す。
【００１７】
データプレーン（底部）において、ルータ（“Ｘ”でマークされたボックスにより示された）は、制御エンティティ（例えば、ＰＣＲＦ）により制御されるクラシファイア（例えば、ＵＬクラシファイア）に基づいて複数のＳＦＣ（図１には、上位ＳＦＣ（チェーン１）及び下位ＳＦＣ（チェーン２）が示されている）の１つへトラフィックを引き回す。各ＳＦＣにおいて、多数のＳＦ（図１では、ＳＦ１ないしＳＦ４）及び負荷バランサーがチェーン化されている。幾つかのＳＦ（例えば、図１では、ＳＦ１及びＳＦ２）が複数のＳＦＣに使用される。エンティティ、特に、ＳＦＣにおいてチェーンのあるＳＦから別のＳＦへトラフィックをフォワーディングする役割を果たすエンティティは、例えば、ＳＤＮコントローラにより制御される。ＳＦ及びＬＢ、クラシファイア、及び制御エンティティの各インスタンスは、個別のＶＭにより実現される。ある具現化では、１つ以上のクラシファイアがルータ“Ｘ”又は負荷バランサーと一体化される。ある具現化では、１つ以上のクラシファイアが専用ハードウェアにより具現化される。即ち、バーチャル化コンピューティング及びネットワーキングにより、堅牢なＧｉ−ＬＡＮは、サービスチェーン、即ち、バーチャル化ネットワーキングにより接続されるバーチャルアプライアンス（又は単にＶＮＦ）に基づき、ＶＮＦ及びクラウドマネージメントＡＰＩを使用してサービスチェーンオーケストレータにより自動化及び管理されるソフトウェアフレームワークに置き換えることができる。
【００１８】
図２（ＩＥＴＦ：サービスファンクションチェーン化（ＳＦＣ）制御プレーンアーキテクチャー、ｄｒａｆｔ−ｗｗ−ｓｆｃ−ｃｏｎｔｒｏｌ−ｐｌａｎｅ−０４、https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/から検索）は、ＳＦＣアーキテクチャーを示す。ＳＦＣ制御プレーンは、ＳＦＣを構築し、ＳＦＣをフォワーディング経路へ変換し、そして経路情報を関連ノードへ伝播して、必要なフォワーディング振舞いを達成し、そしてサービスオーバーレイを構築するのに役立つものである。ＳＦＣイネーブル型ドメインに入るトラフィックは、ＳＦＣ制御プレーンがクラシファイアに与えるルールに基づいて分類される。分類の後に、トラフィックは、ＳＦＣイネーブル型ドメインへフォワーディングされ、それに対応するＳＦＣインストラクションで定義されたサービスファンクションのセットを通過させる。ＳＦＣ特有のフォワーディング情報は、サービスフォワーダーエンティティ（即ち、サービスフォワーダーファンクション（ＳＦＦ）を含むノード）により使用されて、トラフィックフォワーディング判断を実行すると共に、制御プレーン情報から導出され且つクラシファイアからインスタンス化されたサービスファンクション経路を通して、チェーン内の次のサービスファンクションインスタンスへトラフィックを通過させる。更なる詳細については、ＩＥＴＦ文書を参照されたい。
【発明の概要】
【００１９】
以下の実施形態は例示に過ぎない。明細書の多数の位置に「一(an)」「１つの(one)」又は「幾つかの(some)」実施形態という表現が出現するが、これは、必ずしも、そのような各表現が同じ実施形態に対するものであること、又は特徴が単一の実施形態のみに適用されることを意味していない。異なる実施形態の単一の特徴を結合して、他の実施形態を形成してもよい。更に、「備える(comprising)」及び「含む(including)」という語は、ここに述べる実施形態を、言及した特徴のみで構成することに限定するものではないことを理解すべきであり、そしてそのような実施形態は、特に言及されなかった特徴／構造も包含する。
【００２０】
特に、データセンターのソフトウェアに対して最新のコンピューティング環境を説明するためにバーチャルマシン（ＶＭ）の概念をここでは使用する。ＶＭは、ハイパーバイザーの最上部で実行されて物理的コンピューティングリソースのバーチャル化を果たすソフトウェアアプライアンス（アプリケーションＳＷ及びオペレーティングシステム）に関連している。ＶＭという表現は、ソフトウェアアプリケーションがオペレーティングシステムの部分も共有できるいわゆるコンテナのような他のバーチャル環境、或いはハイパーバイザーベース及びコンテナベースのバーチャル化の組み合せを除外するものではない。
【００２１】
ここに提案する概念及び従来の構成（図１）は、バーチャル化なしでも機能する。これは、ＳＦＣのサービスファンクションがサーバーブレードにおけるＣＰＵのプールに配置できる物理的プロセッサ（ＣＰＵ）上で直接実行されることを意味する。これらのケースでは、ＶＭ及びプロセッサ／ＣＰＵという用語を交換する必要があり、ＶＭの負荷に代って、ＣＰＵの負荷の測定等が必要になる。
【００２２】
要約すれば、ＶＭという用語は、サービスファンクション又は完全なＳＦＣをどのように実行するかに関する一例として使用するだけである。
【００２３】
本発明の第１の実施形態によれば、多数のバーチャルマシンが所与のハードウェアで実行され、バーチャルマシンの単一のインスタンスが完全なサービスファンクションチェーンを実行し、前記サービスファンクションチェーンが多数のサービスファンクションより成る適応サービスファンクションチェーン構成のための方法において、特定のサービスファンクションチェーンを実行する各バーチャルマシンの処理負荷を連続的に測定し、及びあるバーチャルマシンの処理負荷が規定の負荷レベルを越える場合には、特定のサービスファンクションチェーンを実行できる付加的なバーチャルマシンがその特定のサービスファンクションチェーンを実行するようアクチベートされ、一方、あるバーチャルマシンの処理負荷が規定の負荷レベルより低い場合には、前記バーチャルマシンの特定のサービスファンクションチェーンの作用負荷が、サービスファンクションチェーンを実行できる別のバーチャルマシンへ転送され、その結果、前記バーチャルマシンの特定のサービスファンクションチェーンがデアクチベートされる、というステップを含む方法が提供される。
【００２４】
本発明の前記実施形態の変形例は、サービスファンクションチェーンの実行が何らかの理由で、例えば、作用負荷が著しく低いためにデアクチベートされたバーチャルマシンを使用して、別のバーチャルマシンのファンクションを引き継ぎ、そして規定の負荷レベルを越える別のバーチャルマシンのサービスファンクションを実行する方法である。
【００２５】
複合サービスファンクションチェーンの中で負荷及びソフトウェア制御のための本発明の別の実施形態では、あるサービスチェーンファンクションを実行するのに必要とされる必要なソフトウェアコンポーネントが全てのバーチャルマシンにロードされる。これは、サービスチェーンの考えられるサブセットが、ソフトウェアコンポーネントをこのバーチャルマシンに事前にロードすることなく、それらバーチャルマシンで実行されるシステムを可能にする。
【００２６】
バーチャルマシンにおけるサービスファンクションチェーンのアクチベーション又はデアクチベーションは、いわゆるリソースマネージャーにより制御される。リソースマネージャーは、制御及び管理エンティティ、特に、エレメントマネージメントシステムＥＭＳにより実施される。
【００２７】
又、ソフトウェアコンポーネントのサブセットだけがバーチャルマシンにロードされる実施形態もある。しかしながら、ソフトウェアコンポーネントのロードされたサブセットは、１つ又は多数のサービスチェーンファンクションを実行するのに充分でなければならない。
【００２８】
ランタイム中にバーチャルマシンのインスタンスにおいてアクチベートされるファンクションは、いわゆるサービスファンクションチェーン記述子により定義されねばならない。この記述子は、どんなサービスファンクションがＳＦＣを構成するか及びそれらがどんなトポロジーに配置されるかを定義する。
【００２９】
別の重要な観点は、永久的に変化する負荷状態に対してシステムが柔軟に反応できることである。それ故、システムがバーチャルマシンの処理負荷を測定できるようにする手段を設けねばならない。これは、異なる仕方で達成できる。１つの可能性は、サービスファンクションチェーンそれ自体を実行するバーチャルマシンが処理負荷測定手段を含むことである。考えられる別の解決策は、基礎的なインフラストラクチャー（ＨＷ又はオペレーティングシステム）がバーチャルマシンの処理負荷を測定する手段をなし、そしてこの情報がインフラストラクチャーマネージャー及びサービスファンクションチェーンリソースマネージャーへ規則的に転送されることである。
【００３０】
別の実施形態において、処理負荷は、プロセッサの負荷、メモリスペース、空き又は未使用メモリスペース、及び／又はその組み合せのような関連パラメータ、並びに負荷測定に適した他のパラメータにより定義される。
【００３１】
もちろん、上述した異なる実施形態は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを備えたハードウェア装置で実行され、メモリの一部分は、コンピュータプログラムコードを含み、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、前記方法ステップのいずれかを遂行するようにさせるよう構成される。
【００３２】
更に別の実施形態として、非一時的コンピュータ読み取り可能な媒体に存在するコンピュータプログラム製品が考えられ、コンピュータプログラムは、所与のハードウェア上のサービスチェーンとして多数のバーチャルマシンを実行するためのプログラムコード、多数のサービスファンクションより成る完全なサービスファンクションチェーンを実施するバーチャルマシンのインスタンスを実行するためのプログラムコード、特定のサービスファンクションチェーンを実行する各バーチャルマシンの処理負荷を連続的に測定するためのプログラムコード、あるバーチャルマシンの処理負荷が規定の負荷レベルを越える場合に、特定のサービスファンクションチェーンを実行できる付加的なバーチャルマシンが特定のサービスファンクションチェーンを実行するためにアクチベートされるファンクションを制御するプログラムコード、及びあるバーチャルマシンの処理負荷が規定の負荷レベルより低い場合に、前記バーチャルマシンの特定のサービスファンクションチェーンの作用負荷が、そのサービスファンクションチェーンを実行できる別のバーチャルマシンへ転送され、その結果、前記バーチャルマシンの特定のサービスファンクションチェーンがデアクチベートされることを制御するプログラムコード、を含むものである。
【００３３】
本発明の幾つかの実施形態によれば、少なくとも以下の効果がもたらされる。
−予想可能な性能、
−容易な負荷バランシング、
−容易で且つ動的なスケーリング、
−ＶＭの再利用性、
−リソースオーバープロビジョニングの必要性が低い
【００３４】
以上の変形例は、代替物を除外すると明確に述べられていない限り、それらが参照する各観点に単独で又は組み合わせて適用できることを理解されたい。
【００３５】
更なる詳細、特徴、目的、及び効果は、添付図面を参照してなされた本発明の好ましい実施形態の以下の詳細な説明から明らかとなろう。
【図面の簡単な説明】
【００３６】
【図１】従来技術による負荷バランシングを伴うＤＣにおける２つのＳＦＣを示す。
【図２】ＩＥＴＦによるＳＦＣアーキテクチャーを示す。
【図３】ＶＭにおけるＳＦＣ構成を示す。
【図４】ＳＦＣを伴うＶＭインスタンス化を示す。
【図５】ＳＦチェーン記述子（上のボックス）及びＳＦ記述子（下のボックス）（左側：一般的設計；右側：特定例）を示す。
【図６】ＳＦＣインスタンス化プロセスを示す。
【図７】ＶＮＦチェーンＶＭ再構成の結果を示す。
【図８】本発明の実施形態による装置を示す。
【図９】本発明の実施形態による方法を示す。
【図１０】本発明の実施形態による装置を示す。
【図１１】本発明の実施形態による方法を示す。
【図１２】本発明の実施形態による装置を示す。
【図１３】本発明の実施形態による方法を示す。
【図１４】本発明の実施形態による装置を示す。
【図１５】本発明の実施形態による方法を示す。
【図１６】本発明の実施形態による装置を示す。
【発明を実施するための形態】
【００３７】
以下、添付図面を参照して、本発明の幾つかの実施形態を詳細に説明する。これら実施形態の特徴は、特に記載のない限り、互いに自由に組み合せすることができる。しかしながら、幾つかの実施形態の記述は、一例として示されたに過ぎず、そして本発明を、ここに開示する詳細に限定するものではないことを理解されたい。
【００３８】
更に、装置は、それに対応する方法を遂行するように構成されるが、あるケースでは、装置のみ又は方法のみが記述されることを理解されたい。
【００３９】
以上のことから、チェーンの物理的サービスファンクションの１対１マッピング、又はその分解されたコンポーネント対ＶＭのバーチャルＳＦは、クラウドへのサービスファンクションチェーンの最適な移行であるとのことには、ある程度の疑念がある。
【００４０】
図１及び２に示すアーキテクチャーによれば、異なる売主及びサービスファンクションプロバイダーにより異なるＳＦが提供されることがある。各ＳＦを単一のＶＭに割り当てることの効果は、全てのＳＦがそれ自身のＯＳ−「コンテナ」により分離される場合に、定義された安定なランタイム環境があることである。又、これは、例えば、より簡単なテストも許す。
【００４１】
しかしながら、最新のＳＷ処理は、更に非常に効果があり、異なる売主からの通常異なるアプリケーションは、同じＯＳにおいて実行される。例えば、移動装置又は動的リンクライブラリのアプリケーションは、異なる売主により提供され、そしてアプリケーションプログラムにおいて結合される。例えば、ウインドウズＯＳでは、メディアプレーヤのメディアストリーム処理は、例えば、ランタイム中に結合されるソースフィルタ、デマルチプレクシング、デコーディング及びレンダリングに対して異なる売主からの異なるコンポーネントを使用することができる。
【００４２】
本発明の幾つかの実施形態によれば、各ＶＭは、ＶＭ上で実行されることが意図されたＳＦＣを作り上げる全てのＳＦのＳＷを含む。ＶＭは、ＶＭ上で実行されることが意図された全てのＳＦＣに対する全てのＳＦのＳＷを含む。複数のＶＭに同じＳＷが装備される。配備のために、ＳＷイメージが使用される。
【００４３】
従来技術に勝るこの解決策の効果は、次の少なくとも１つである。
−特にサービスファンクションチェーンのレイテンシーに対する予想可能な性能（必要なレイテンシーを達成するための複雑なトポロジー又はトランスポートメカニズムの考慮を必要としない）。
−個々のＳＦには必要とされず、チェーンごとに必要となる非常に容易な負荷バランシング、及び
−容易で且つ非常に動的なスケールイン及びアウト−リソース再利用（未使用のＳＦチェーンを除去しそして既存のＶＭにおいて新規なＳＦチェーンを展開する）。
【００４４】
図３は、ＶＭにおけるＳＦＣ構成を示す。「チェーンＶＮＦ」（１つ以上のＳＦＣが実行されるＶＮＦ）として働くＶＭ３０１には、ＯＳ３０４の頂部に、ＳＷイメージ３０２がインストールされる。ＳＷイメージ３０２は、ＳＦＣのＳＦ（ＳＦ１、ＳＦ２、ＳＦ３、ＳＦ４、・・・として表わされた）に必要とされる全てのＳＷを含む。加えて、ＳＦに基づいてＳＦＣを展開する「チェーンＯＳ」ミドルウェア３０３、及び「ＳＦグラフ」と示されたそのトポロジー記述も含む。より詳細には、「チェーンＯＳ」ミドルウェアは、ＳＦグラフ及びＳＦレジストリを含む。
【００４５】
「チェーンＯＳミドルウェア」は、制御エンティティによって制御される。制御エンティティは、ＥＭＳ３０５の一部分、ＶＮＦマネージャー３０６の一部分、個別のエンティティであるか、又は別のファンクションと一体化される。そのファンクションは、ＥＭＳ３０５及びＶＮＦマネージャー３０６にわたって分散されるように、複数のエンティティにわたって分割分散される。図３において、一例として、制御エンティティは、ＥＭＳ３０５と一体化される。
【００４６】
ＯＳＳ／ＢＳＳ３０７、オーケストレータ３０８及びＶＩＭ３０９は、完全性のために示されており、いつものとおりにそれらの各ファンクションを満足する。
【００４７】
１つ以上の「チェーンＶＮＦ」ＶＭの構成を担当する制御エンティティ（例えば、ＥＭＳ３０５）は、とりわけ、２つのデータテーブルを含む。
特定チェーンをインスタンス化するためにチェーンＶＮＦ  ＶＭへダウンロードされるべきチェーン表現を含む各チェーンを記述する１つのテーブル（例えば、ＳＦ間のトポロジー関係を記述するグラフテンプレート）、及び
チェーン（１つ又は複数）が構築されるＳＦのテーブルであって、ＳＦ記述子／テンプレートを含むテーブル。
【００４８】
ＶＭに展開する必要のあるＳＦチェーンの厳密な記述がグラフテンプレートに記憶される。グラフテンプレートは、チェーンをコンポーズするＳＦがどのように接続されるか特定する。そのような特定は、複合ＳＦのリストの形態であるが、この種の表現に限定されない。
【００４９】
チェーンを管理するため、ＳＦ記述／テンプレートは、更に、ＳＦの更なる記述を、例えば、負荷／計算要件、指定のＳＦ重み、等に関して含む。そのような付加的な情報は、ＶＭインスタンス化の間に、特に、あるサービングチェーンから別のサービングチェーンへのＶＭ再構成のために使用される。ＤＣにおけるユーザの人数に基づいて、異なる数のＶＭが、異なる要件をもつ個々のＳＦチェーンに対して最初にインスタンス化される。
【００５０】
チェーンＶＮＦ内のチェーン管理ファンクションのためのインターフェイスは、「チェーンＯＳミドルウェア」３０３と称されるエンティティ内に存在する。実施形態に基づいて、制御エンティティ（例えば、ＶＮＦマネージャー３０５又はＥＭＳ３０６）又はチェーンＯＳミドルウェア或いはそれらの間のファンクションの分散は、ＳＦチェーンを管理するための次のファンクションを与える。
【００５１】
ＳＦは、それ自身を制御エンティティ又は「チェーンＯＳミドルウェア」に登録し、そしてそれらのサポートされるインターフェイスに関する入力パラメータを与える。これは、例えば、ＩＥＴＦのようなある標準的仕様に基づくパケットヘッダ拡張のサポートを含む。
【００５２】
特定のＳＦＣをインスタンス化するＳＦグラフが構成される。ＥＭＳ又はチェーンＯＳは、ＳＦＣの全てのＳＦが要求どおりに接続できるかどうかのチェックを与える。チェーンＯＳは、制御エンティティ、ＥＭＳ又はＶＮＦマネージャーのような外部管理エンティティに対してチェーンインスタンス化を確認する。チェーンＯＳミドルウェアは、特定チェーンのインスタンス化に必要な全てのＳＦがＶＭのＳＷイメージに既に含まれているかどうか検証する。もしそうでなければ、外部管理エンティティに欠落ＳＦを通知する。
【００５３】
チェーンＶＮＦ（チェーンＯＳミドルウェア又は他のＶＮＦ内部管理エンティティ）は、現在ＳＦチェーンのＶＭ利用に関するレポートをＥＭＳ及びＶＮＦマネージャーに与える。そのような情報は、ＶＭの効率的な動的スケーリングイン／アウトに必須である。
【００５４】
ここに述べるファンクションの幾つかは、ＶＭそれ自体のＯＳの一部分でもよい。
【００５５】
１つの特定のグラフ上に展開するチェーンＶＮＦ（チェーンＩＤを伴うＳＦＣに関連した）ごとに、同じ専用負荷バランサーが指定される。全てのチェーンＶＮＦは、グラフを首尾良くインスタンス化した後に、その特定のグラフ／チェーンＩＤに対応する負荷バランサーに登録される。
【００５６】
ＳＦＣを実施するための２つのオプションがある。
ＳＷイメージがＳＦチェーンのランタイムバージョンを既に含むという静的な解決策。全てのもの（ＳＦ及びＳＦＣ）が既に構成される。このオプションは、計算効率についてより最適な潜在性を有し、又は
図３に示す動的なインスタンス化：「チェーンＶＮＦ」ＳＷ（ＳＷイメージ１  ３０２）を伴うＶＭ（例えば、ＶＭ３０１のような数「ｎ」）のインスタンス化の後、制御機能（例えば、ＥＭＳ３０５又はＶＮＦマネージャー３０６又は個別エンティティ）は、ＶＭ３０１の特定チェーン（例えば、チェーンＩＤｘを伴う）をアクチベートするＳＦＣグラフを構成する。その後、制御エンティティは、フロークラシファイア及び負荷バランサーを、チェーンｘにサービスする対応ＶＭ（１つ又は複数）に接続するようにＤＣのパケットフォワーディングシステムをプログラムする。負荷バランサーは、ＶＭｎのインスタンス化と共に更新される。
【００５７】
そのようなプロセスの結果として、異なるＳＦチェーンのための異なる数のＶＭが、図４に例示されたように、負荷要件に基づいてインスタンス化される。
【００５８】
図４において、ＥＭＳ３０５、ＶＮＦマネージャー３０６、オーケストレータ３０８、及びＶＩＭ３０９は、図３に例示したものに対応する。バーチャルインフラストラクチャーリソース３１０（ＶＩＭ３０９により管理される）に基づいて、多数のＶＭ３０１ａ、・・・３０１ｍ、３０１ｎ、・・・３０１ｚが展開される。ＶＭ３０１ａ、・・・３０１ｍの数、及びＶＭ３０１ｎ、・・・３０１ｚの数は、任意である。これらＶＭ３０１ａ、・・・３０１ｚの各々は、図３のＶＭ３０１に対応する。これらＶＭ３０１ａ、・・・３０１ｚの各々において、同じＳＷイメージ（ＳＷイメージ１  ３０２）がインストールされる。ＳＷイメージ１  ３０２は、ＳＦＣ１及びＳＦＣ２を作り上げるＳＦのためのＳＷを含む。従って、ＶＭ３０１ａ、・・・３０１ｚの各々は、ＳＦＣ１及びＳＦＣ２のいずれか又は両方を実行する。更に、ＶＭ３０１ａ、・・・３０１ｚの各々又は幾つかにおいて、例えば、他のＳＦ又は他のＳＦＣに関連した付加的なＳＷが展開されてもよい（図示せず）。
【００５９】
図４の例において、ＶＭ３０１ａ、・・・３０１ｍは、ＳＦＣ１を実行するために制御エンティティ（ここでは、ＥＭＳ３０５）により構成され、そしてＶＭ３０１ｎ、・・・３０１ｚは、ＳＦＣ２を実行するように構成される。
【００６０】
ＳＦ記述子は、各ＳＦに関する詳細な情報を記憶する。これは、詳細なシステム要件、プライオリティ、等を含む。ＳＦ記述子は、ＳＦのシステム要件、及び任意であるが、厳密なＳＦ実施又は事業者の好みに関連した付加的なパラメータを含む。
【００６１】
図５は、グラフテンプレート及びＳＦ記述子／テンプレートを含むＳＦチェーンのデータ構造の一例を示す。左側には、制御エンティティ（図５では一例としてＥＭＳ）におけるデータ構造の一般的な設計が示されている。右側には、特定例に従って左側のテンプレートがどのように満たされるか示されている。各ＶＭの「チェーンＯＳ」ミドルウェアには、対応する表示が与えられる。
【００６２】
上部ボックスは、サービスチェーンを定義するＳＦチェーン記述子を含む。特に、それは、グラフテンプレートを含む。図５の右側に見られるように、グラフテンプレートは、ＳＦＣを作り上げる一連のＳＦ（例えば、ＳＦＣ１についてはＳＦ１、ＳＦ２、ＳＦ３、ＳＦ４）を指示する。幾つかの規範的ＳＦが指示される。更に、チェーン記述子は、例えば、トラフィックポリシー、プライオリティ、スケーリングポリシー、等に関する情報を含む。ＳＦＣごとに個別のＳＦチェーン記述子がある。
【００６３】
図５の両側の下部ボックスは、ＳＦ記述子を含む。各ＳＦ記述子は、ＳＦＧの名前及びインターフェイス記述を含む。更に、システム要件のようなＳＦに関連した他の情報も含む。ＳＦチェーン記述子により記述されるＳＦＣの少なくとも１つに含まれるＳＦごとにＳＦ記述子がある。しかしながら、ＳＦ（例えば、右側の例では、ＳＦＣ１及びＳＦＣ２により使用されるＳＦ４）が多数のＳＦＣにより使用される場合には、このＳＦに対して１つのＳＦ記述子しかない。
【００６４】
インスタンス化プロセスの一例が図６に示されている。図６に示すエンティティは、図３に対応する。
【００６５】
オーケストレータ３０８は、異なるＳＦＣを展開するＶＭをインスタント化するための全ての利用可能なリソースのある部分を割り当て、例えば、あるネットワークプランニングに基づき入力テンプレートに従ってそのような目的で１００のＶＭが割り当てられる。図６には、複数（例えば、１００）のＶＭの１つ（ＶＭ３０１）だけが示されている。ＶＮＦマネージャー３０６は、ＳＦＣのインスタント化専用の利用可能な実行中ＶＭについてＥＭＳ３０５に通知する。
【００６６】
ＥＭＳ３０６は、予想トラフィック負荷、及びＳＦＣの特性、例えば、各ＳＦＣの予想トラフィックプロファイルを考慮に入れて、各ＶＭにおける適当な数の異なるＳＦＣをインスタンス化し、そしてそれらの間での最適な作用負荷分布を計算する。例えば、ＥＭＳ３０６は、アクチベートされた１００のＶＭにおけるチェーンのインスタンス化が、次のスキーマ、即ちＳＦＣ１に対する４０のＶＭ、ＳＦＣ２に対する３０のＶＭ、ＳＦＣ３に対する１０のＶＭ、ＳＦＣ４に対する１０のＶＭ、ＳＦＣ５に対する１０のＶＭに従わねばならないと決定する。従って、各ＶＭは、１つのＳＦＣのみを実行する。しかしながら、他の例では、幾つかの又は全てのＶＭが複数のＳＦＣを実行してもよい。
【００６７】
制御エンティティ（例えば、ＥＭＳ又はＶＮＦＭ；図６に示す例では、ＥＭＳが制御エンティティとして働く）は、ＳＦＣごとに各負荷バランサーをインスタンス化する。一例において、５つのＳＦＣに対して５つの負荷バランサーがインスタンス化されるが、その１つ（ＬＢ３１１）しか示されていない。
【００６８】
ＳＦＣは、ＶＭにおいてインスタンス化されるとき、それに対応する負荷バランサーに登録される。従って、負荷バランサーは、各ＳＦＣのパケットを、それに対応するＶＭに対して分散させる。
【００６９】
前記構成によれば、ＳＦＣのＳＦ間には、より効率的なＶＭ内部通信が使用される。これは、データプレーンにおけるＳＦＣ実行効率を高める。各ＳＦがそれ自身のＶＭを必要とせず各ＳＦＣしか必要としない場合には、高いリソース効率のためにＶＭの全数を減少することができる。又、これは、ＶＮＦに必要とされるゲストＯＳの数のようなバーチャル化オーバーヘッドも減少する。
【００７０】
本発明の幾つかの実施形態によれば、全ＳＦを伴うＳＦＣが単一のＶＭにおいて実施されるＤＣでは、ＶＭの使用は、利用可能なリソースが最適な仕方でＳＦＣ間に分散されるように適応され、即ちランタイム中に、負荷レベルがあるスレッシュホールドより低い１つ以上のＶＭにおいて、高いネットワークスループットが要求される別のチェーンをアクチベートできるように（例えば、それらＳＦＣに現在割り当てられているＶＭが高い負荷レベルをもつので）、ＶＭを再構成することができる。対応的に、ＶＭにおいてチェーンが充分活用されない（チェーンのＬＢがこのＶＭをあるスレッシュホールドより低い頻度で選択する）場合には、ＶＭは、このチェーンをそれ以上実行せず、従って、ＶＭの他のＳＦＣの容量を高めるように再構成される。
【００７１】
ＶＭにおいてチェーンが充分に活用されていないかどうか決定する基準として、ＶＭの負荷（特に、そのＶＭにおいて各チェーンしか実行されない場合）が使用される。
【００７２】
それとは別に又はそれに加えて、呼び出し頻度、即ちＶＭ上のＳＦＣをどれほど頻繁に呼び出すかが使用される。呼び出し頻度は、ＶＭにおいて、又はＬＢの出力側で測定される。ＬＢが特定のルールに従ってＳＦＣ呼び出しを分散すると仮定した場合には、特定ＶＭにおけるＳＦＣの呼び出し頻度は、ＳＦＣの合計呼び出し頻度（即ち、各ＬＢの入力側で測定されるＳＦＣに対する需要）から、及び当該特定ＶＭのシェアを計算することから決定されてもよい。例えば、ＬＢのルールが、ＳＦＣを実行するように構成された全てのＶＭにおいて等しい分散である場合には、シェアが１／（ＳＦＣを実行するように構成されたＶＭの数）である。
【００７３】
これらのファンクションは、制御エンティティ（例えば、ＳＦＣ−ＶＮＦのためのＶＮＦマネージャーと任意に協働するＳＦＣ  ＶＮＦのためのＥＭＳ）により遂行される。
【００７４】
このメカニズムは、ＳＦチェーン化のためのＶＭの所与のグループにおいてサービスファンクションチェーン化について割り当てられたリソース／ＶＭを最適に使用するために制御の「内部ループ」を導入する。「内部ループ」という語は、従来技術によりＳＦチェーン化のためのグループにおけるＶＭの全数の増加又は減少を意味する「外部ループ」とは対照的に使用される。「外部ループ」の動作は、典型的に、ＤＣのオーケストレータにより行われる。「外部ループ」による再構成は、より厳しい動作であり、即ち「内部ループ」による再構成より大きなＣＰＵ容量及び帯域巾を要求する。「内部ループ」により、本発明の幾つかの実施形態では、「外部ループ」をあまり頻繁に行う必要がない（ある場合には、全く行わない）。
【００７５】
この「内部ループ」では、既に確立されたＶＭ間に負荷を分散できる限り新たなＶＭをインスタンス化する必要はない。そのプロセスは、ＶＭの数をスケーリングする（「外部ループ」）よりも非常に動的に遂行することができる。
【００７６】
「内部ループ」の効果は、次の少なくとも１つである。
・チェーン当たり容易で且つ非常に動的なスケールイン及びアウト；
・リソースを再使用でき（使用しない（未使用の）ＳＦチェーンを除去しそしてサービスチェーン化のために既に構成されたＶＭにおいて新たなＳＦチェーンを展開することにより）；
・負荷バランシングがチェーンごとに遂行されそして個々のＳＦに対して遂行する必要がないので負荷バランシングが容易であり；及び
・リソースオーバープロビジョニングの必要性が低いのでＳＦチェーン化のためのＶＭの数を減少できる。
【００７７】
チェーンＶＮＦにより与えられるＳＦチェーン及びＶＭ利用に関する情報に基づいて、制御エンティティ（例えば、ＥＭＳ及び／又はＶＮＦマネージャー及び／又は個別のエンティティ）は、ＶＭ及びＳＦチェーン割り当てを次のように調整する。この説明は、例えば、制御エンティティであるＥＭＳとＶＮＦマネージャーとの間の典型的なファンクション分割を仮定する。しかしながら、このファンクション分割は、何ら限定するものではなく、ＥＭＳ、ＶＮＦＭ及び個別の制御エンティティ間の他のあり得るファンクション分割を採用してもよい。
【００７８】
「チェーンＶＮＦ」ＶＭの構成を担当するＥＭＦは、とりわけ、ＳＦチェーンのインスタンスを実行するよう構成された全てのＶＭに対する負荷状態を含む負荷テーブルを収容する。ＥＭＳは、負荷情報をＳＦＣ−ＶＭから直接的に収集するか（オプション１）又はＶＮＦマネージャーから間接的に収集する（オプション２、ＶＮＦＭは、そのような情報をＳＦＣ−ＶＭ又はＶＩＭから直接的に収集する）。内部ポリシー（負荷スレッシュホールド、ＳＦチェーンのプライオリティ、等）に基づき、ＥＭＳは、ＶＭを再構成することを決定する。例えば、トラフィック需要を満足するため、ＳＦＣ−ｎではなくＳＦＣ−ｍのインスタンスを実行するよう構成されるようにＶＭを再構成する。例えば、これが生じるのは、所与の時間に幾つかの特定のＳＦチェーンに対して高い需要があり、他方、他のチェーンを実行するあるＶＭに僅かな負荷しか掛からない場合である。他のオプションとして、あるＳＦＣをそれ以上実行しないようにＶＭを再構成するか、又は実行するように既に構成されたＳＦＣのインスタンスに加えて、あるＳＦＣのインスタンスを実行するように構成してもよい。
【００７９】
優雅な移行を与えるため、ＥＭＳは、そのような動作を前もってＳＦＣ  ＶＮＦに通知する。ＳＦＣ  ＶＭは、次いで、（特にステートフルなファンクションが遂行される場合には）このＶＭに新たなフローを指定しないようその負荷バランサーに通知する。更に、ＳＦＣ−ＶＭの最終的な再構成及び以前に展開されたＳＦＣのシャットダウンの前に、ＥＭＳは、そのＳＦＣ−ＶＭの負荷テーブルにおいて、ＶＭにもはや負荷が掛からない（全ての進行中フローが処理された）かどうかチェックする。加えて、新たなＳＦＣの展開が安全であるかどうかもチェックする。
【００８０】
ＥＭＳが新たなグラフテンプレートのダウンロードによりＶＭを再構成した後に、ＶＭは、新たなＳＦチェーンに対して責任を負う新たな負荷バランサーによりそれ自身を登録する。或いは又、ＥＭＳは、新たなＳＦＣのインスタンスを実行するよう構成された付加的なＶＭにおける新たなＳＦＣについてＬＢに通知してもよい。
【００８１】
負荷テーブルの規則的更新に要求されるシグナリングを最小にするため、それとは別に（又はそれに加えて）減少レポートが使用されてもよい。ＳＦチェーンの全ＶＭの負荷状態に関する規則的なレポートに応答するのではなく、ある規定のスレッシュホールドを越える場合だけＥＭＳに更新を送ることができる。そのようなスレッシュホールドは、予め決定されるか、又は使用されるポリシーに関して定義されてもよい。「内部制御ループ」の効率的な動作のために、ＳＦＣ−ＶＭ負荷に関する２つのスレッシュホールドが特に重要である。
【００８２】
・最大スレッシュホールド：それより低いと、ＳＦＣ−ＶＭの動作及び負荷が正常であると考えられるＳＦＣ−ＶＭに対する上限。ＳＦＣの負荷が「最大スレッシュホールド」より高くなると、ＥＭＳは、１つ以上の他のＶＭの再構成及び他のＶＭにおけるＳＦＣ−ＶＭで実行されるＳＦＣの展開をトリガーしなければならない。
【００８３】
・最少スレッシュホールド：それより低いと、ＳＦＣに対する個別ＶＭの実行が正当化されず、即ちＳＦＣの負荷が低くて、そのような負荷に対して個別のＶＭを持たせることがリソースの浪費と考えられるＳＦＣ−ＶＭ負荷に対する下限。ＳＦＣの負荷が「最少スレッシュホールド」より低くなった場合には、そのＶＭは、より多くのリソースが必要である別のＳＦＣ、例えば、「最大スレッシュホールド」に達したＳＦＣの再構成及び展開のための候補である。
【００８４】
ＥＭＳは、ＳＦチェーン当りのＶＭの数に基づいてスレッシュホールド値を決定する。そのようなスレッシュホールドは、減少レポートのためにＥＭＳによりＳＦチェーンＶＮＦにおいてダウンロードされ／構成されてもよい。それ故、ＥＭＳにおけるＳＦＣ−ＶＭ負荷テーブルの更新は、ＳＦＣ−ＶＭ負荷が「最大スレッシュホールド」を越えるか又は「最少スレッシュホールド」より下がるとトリガーされる。ＥＭＳは、タイムウインドウ又は他の経歴情報を考慮してもよい。内部ポリシー（例えば、ＳＦＣプライオリティ）に基づき、ＥＭＳは、更に、現在トラフィック負荷を取り扱いそしてそれに応じてＳＦＣ−ＶＭを再構成するアクションをとることができる。
【００８５】
ＶＭの数、及びそれらにおいて展開されるＳＦチェーンのタイプは、例えば、ＶＭ利用レポートに基づいて動的に調整される。
【００８６】
又、あるＳＦＣの需要を考慮することから、１つ以上のＶＭを再構成する必要性が生じる。この需要は、各負荷バランサーにおける負荷から導出される。各ＳＦＣを実行するように構成されたＶＭの数で需要を分割することにより、この特定のＳＦＣにより生じる各ＶＭの負荷が推定される。
【００８７】
又、制御エンティティ（例えば、ＥＭＳ及び／又はＶＮＦマネージャー）は、典型的なトラフィックプロフィールを学習し、そして展開されたＳＦチェーンを伴うＶＭを、予想されるトラフィック特性に従って割り当てることで、先験的に反応することもできる。例えば、夜間に、ビデオ最適化ＳＦチェーンの需要が高まった場合には、ＥＭＳは、多数の既存のＶＭにおいてその特定のＳＦチェーンを再構成する。
【００８８】
ＳＦＣがチェーンＶＮＦにおいてインスタンス化される仕方、即ち上述したように静的にインスタンス化されるか動的にインスタンス化されるかに関わりなく、グラフテンプレートに記憶された情報、及び制御エンティティ（例えば、ＥＭＳ）及びオーケストレータの記述子に収容されるＳＦ記述子／テンプレートに基づいてリソース最適化及びＳＦＣの初期展開の効率的プランニングを行う可能性がある。グラフテンプレート（ＳＦ間に要求される接続に関する情報を与える）に加えて、ＳＦＣ記述は、トラフィックプロフィール（例えば、そのチェーンに対するピーク負荷を伴う１日の時刻、等）に関する情報、又は特定チェーンに対するリソース不足を取り扱う場合にはスケーリングポリシー及びプライオリティに関する情報を与えることができる。更に、ＤＣにおけるユーザの人数、チェーンの個々のＳＦのトラフィックプロフィール及びシステム要件に基づいて、各個々のＳＦＣの予想されるトラフィック負荷が推定される。チェーンテンプレートに記憶された全てのそのような付加的な情報は、ＳＦＣインスタント化の間にリソースプランニングのための貴重な入力として働く。
【００８９】
図７は、ＶＮＦチェーンＶＭ再構成の結果を示す。左側では、再構成の前に、４つのＶＭ３０１ａから３０１ｄがＳＦＣ１を実行し、そして２つのＶＭ３０１ｅ及び３０１ｆがＳＦＣ２を実行する。これらのＶＭの各々は、同じＳＷイメージがインストールされた図４のＶＭに対応することに注意されたい。再構成の後に、右側に示すように、２つのＶＭ３０１ａ及び３０１ｂがＳＦＣ１を実行し、そして４つのＶＭ３０１ｃから３０１ｆがＳＦＣ２を実行する。従って、ＳＦＣ２の容量は、ＳＦＣ１の容量減少を犠牲にして増加されるが、サービスチェーン化について構成されるＶＭの数を増加することはない。
【００９０】
本発明の幾つかの実施形態によれば、「内部制御ループ」に加えて「外部制御ループ」が次のように依然遂行されてもよい。
【００９１】
・「ＳＦＣ−ＶＭ」の全負荷レベルが特定スレッシュホールドより低い場合にはＶＭを除去することにより。これは、ＶＮＦマネージャーとオーケストレータ（リソースを除去する）及びＥＭＳ（ＶＭの数の減少をＥＭＳに通知する）とのインターワーキングを経て行われる。
【００９２】
・新たなＶＭを追加することにより。ＥＭＳは、高い需要のあるＳＦチェーンを展開してもよい。上述した再構成のために、全チェーンのＶＭは、ある程度等しい負荷が課せられ、そして負荷が特定のスレッシュホールドに到達する。これは、ＶＮＦマネージャーの標準的なスケールアウト動作、及びオーケストレータ（リソースの割り当て）及びＥＭＳ（ＳＦチェーン化のために新たなＶＭについて通知する）とのインターワーキングを経て行われる。
【００９３】
「外部ループ」は、高レベルでのリソース割り当ての責任を果たし（要求されるＳＦＣ間に異なる仕方で分散できるＶＭの全数を展開する）、一方、微細粒度のリソース割り当て及び調整は、「外部ループ」の不要なトリガー動作を回避する目的で「内部ループ」（既存のリソースの再利用）において行われる。しかしながら、リソースの利用を最適化するために「内部制御ループ」及び「外部制御ループ」の動作は、緊密に相関される。換言すれば、内部ループは、ある規定の条件を満足すると、外部ループをトリガーする。
【００９４】
そのような条件の一例として、次のシナリオを考える。Ｘ個のＳＦＣ−ＶＭが「最小」スレッシュホールドに到達しそしてＹ個のＳＦＣ−ＶＭが「最大」スレッシュホールドに到達し、ＸはＹよりかなり小さく、且つその条件がＺ回を越えても有効のままであるとＥＭＳが検出すると、外部ループは、新たなＶＭの追加をトリガーしなければならない。ＸがＹよりかなり大きいという条件が満足されると、「外部ループ」は、ＶＭの除去をトリガーしなければならない。
【００９５】
「内部ループ」がアクチベートされる条件は、利用可能な全リソース、定義されたポリシー及びオーケストレーションアクションの希望レベルに依存する。例えば、ＶＭの解放が重要でない場合には、ＥＭＳは、非常に多数のＶＭが空いている場合だけ外部ループのスケーリングダウンをトリガーするよう命令される。又、オーケストレータからのアクションを最小にする必要がある場合にも、ある非常に重要なスレッシュホールドに到達した場合だけスケーリングアウトがトリガーされ、さもなければ、「内部ループ」は、できるだけ多数のリソースの再使用を試みる。
【００９６】
又、ＥＭＳ及びＶＮＦマネージャーも、典型的なトラフィックプロフィールを学習し、そして展開されたＳＦチェーンを伴うＶＭを、予想されるトラフィック特性に従って割り当てることで、先験的に反応することもできる。例えば、夜間に、ビデオ最適化ＳＦチェーンの需要が高まった場合には、ＥＭＳは、多数の既存のＶＭにおいてその特定のＳＦチェーンを再構成する。
【００９７】
別のオプションとして、外側ループ（例えば、オーケストレーション）は、内部ループがどれほど頻繁にＶＭを再構成するか観察してもよい。再構成頻度が比較的高い場合は、内部ループにおいてＶＭ容量が欠落しているためにシステムが安定でないと仮定する。この場合には、本発明の幾つかの実施形態により、外部ループがサービスチェーン化のための容量を増加する。例えば、外部ループは、サービスチェーン化のために１つ以上のＶＭを追加するか、又はサービスチェーン化に指定された１つ以上のＶＭの容量を増加する。
【００９８】
再構成頻度を監視するため、外部ループは、ＶＭを監視するか、又は内部ループの制御エンティティにより発生される再構成コマンドを監視する。
【００９９】
そのようなプロセスの結果として、異なるＳＦチャンネルの異なる数のＶＭが負荷要件に基づいてインスタンス化される。ＶＭの数及びそれらにおいて展開されるＳＦチェーンのタイプは、ＳＦＣ−ＶＭ利用レポートに基づいて動的に調整される。
【０１００】
図８は、本発明の実施形態による装置を示す。この装置は、ＥＭＳ又はＶＮＦマネージャーのような制御装置或いはその要素である。図９は、本発明の実施形態による方法を示す。図８の装置は、図９の方法を遂行するが、この方法に限定されない。図９の方法は、図８の装置により遂行されるが、この装置により遂行されることに限定されない。
【０１０１】
この装置は、需要検出手段１０及び再構成手段２０を備えている。この需要検出手段１０及び再構成手段２０は、各々、需要検出回路及び再構成回路である。
【０１０２】
需要検出手段１０は、サービスファンクションチェーンの需要が１つ以上のバーチャルマシンの容量を越えるかどうか検出する（Ｓ１０）。容量とは、サービスファンクションチェーンの容量であるか、又はバーチャルマシンの合計容量である。１つ以上のバーチャルマシンの各々は、バーチャルマシンのグループに属し、グループの各バーチャルマシンは、サービスファンクションチェーンの各インスタンス、及びサービスファンクションチェーンを作り上げる全サービスファンクションの各インスタンスを実行するように構成されるよう指定され、即ちグループのＶＭは、ＳＦＣ−ＶＭである。
【０１０３】
需要が容量を越える（Ｓ１０＝「イエス」）場合には、再構成手段２０は、サービスファンクションチェーンの各インスタンスを実行するようにグループの付加的なバーチャルマシンを再構成する（Ｓ２０）。更に、ＳＦＣ−ＶＭの各々は、ＳＦＣの全ＳＦを実行するように構成されるので、サービスファンクションチェーンを作り上げる全てのサービスファンクションの各インスタンスを実行するようにＶＭを再構成する（Ｓ２０）。付加的なバーチャルマシンは、再構成の前にＳＦＣのインスタンスを実行するように構成された１つ以上のバーチャルマシンの各々とは異なる。
【０１０４】
図１０は、本発明の実施形態による装置を示す。この装置は、ＥＭＳ又はＶＮＦマネージャーのような制御装置或いはその要素である。図１１は、本発明の実施形態による方法を示す。図１０の装置は、図１１の方法を遂行するが、この方法に限定されない。図１１の方法は、図１０の装置により遂行されるが、この装置により遂行されることに限定されない。
【０１０５】
この装置は、呼び出し頻度検出手段１１０及び再構成手段１２０を備えている。呼び出し頻度検出手段１１０及び再構成手段１２０は、各々、呼び出し頻度検出回路及び再構成回路である。
【０１０６】
呼び出し頻度検出手段１１０は、バーチャルマシンにおけるサービスファンクションチェーンのインスタンスを呼び出す呼び出し頻度が低呼び出し頻度スレッシュホールドより低いかどうか検出する（Ｓ１１０）。バーチャルマシンは、ＳＦＣ−ＶＭであり、即ちバーチャルマシンは、サービスファンクションチェーンのインスタンス、及びサービスファンクションチェーンを作り上げる全サービスファンクションの各インスタンスを実行するように構成される。
【０１０７】
呼び出し頻度が低呼び出し頻度スレッシュホールドより低い（Ｓ１１０＝「イエス」）場合には、再構成手段１２０は、サービスファンクションチェーンのインスタンスをそれ以上実行するよう構成されないようにバーチャルマシンを再構成する（Ｓ１２０）。
【０１０８】
図１２は、本発明の実施形態による装置を示す。この装置は、ＥＭＳ又はＶＮＦマネージャーのような制御装置或いはその要素である。図１３は、本発明の実施形態による方法を示す。図１２の装置は、図１３の方法を遂行するが、この方法に限定されない。図１３の方法は、図１２の装置により遂行されるが、この装置により遂行されることに限定されない。
【０１０９】
この装置は、負荷検出手段２１０及び再構成手段２２０を備えている。負荷検出手段２１０及び再構成手段２２０は、各々、負荷検出回路及び再構成回路である。
【０１１０】
負荷検出手段は、バーチャルマシンの負荷が低負荷スレッシュホールドより低いかどうか検出する（Ｓ２１０）。バーチャルマシンは、ＳＦＣ−ＶＭであり、即ちバーチャルマシンは、サービスファンクションチェーンのインスタンス、及びサービスファンクションチェーンを作り上げる全サービスファンクションの各インスタンスを実行するように構成される。ある実施形態では、ＶＭは、一度に１つのＳＦＣだけを実行するように構成される。
【０１１１】
負荷が低負荷スレッシュホールドより低い（Ｓ２１０＝「イエス」）場合には、再構成手段２２０は、サービスファンクションチェーンのインスタンスをそれ以上実行するよう構成されないようにバーチャルマシンを再構成する（Ｓ２２０）。
【０１１２】
図１４は、本発明の実施形態による装置を示す。この装置は、オーケストレータのような外部ループの制御装置或いはその要素である。図１５は、本発明の実施形態による方法を示す。図１４の装置は、図１５の方法を遂行するが、この方法に限定されない。図１５の方法は、図１４の装置により遂行されるが、この装置により遂行されることに限定されない。
【０１１３】
この装置は、構成監視手段３１０及び追加手段３２０を備えている。構成監視手段３１０及び追加手段３２０は、各々、構成監視回路及び追加回路である。
【０１１４】
構成監視手段３１０は、１つ以上のバーチャルマシンが高再構成頻度スレッシュホールドより高い再構成頻度で再構成されるよう命令されるかどうか監視する（Ｓ３１０）。ここで、再構成とは、サービスチェーンのセットを実行するための構成の変更を意味する。即ち、再構成は、再構成インストラクションが受け取られるときに実行していなかった第１のサービスファンクションチェーンのインスタンスを実行する構成、及び再構成インストラクションが受け取られるときに実行していた第２のサービスファンクションチェーンのインスタンスを実行しない構成、の少なくとも１つを含む。１つ以上のバーチャルマシンの各々は、バーチャルマシンのグループに属し、グループの各バーチャルマシンは、グループのサービスファンクションチェーンの各インスタンス、及び各サービスファンクションチェーンを作り上げる全サービスファンクションの各インスタンスを実行するように構成されるよう指定される。
【０１１５】
追加手段３２０は、再構成頻度が高再構成スレッシュホールドより高い場合に、バーチャルマシン容量をグループに追加する（例えば、１つ以上のＶＭをグループに追加することにより、及び／又は１つ以上のＶＭの容量をグループに追加することにより）（Ｓ３２０）。
【０１１６】
図１６は、本発明の実施形態による装置を示す。この装置は、少なくとも１つのプロセッサ６１０、及びコンピュータプログラムコードを含む少なくとも１つのメモリ６２０を備え、少なくとも１つのプロセッサ６１０は、少なくとも１つのメモリ６２０及びコンピュータプログラムコードとで、装置が、少なくとも、図９、１１、１３及び１５の方法、及び関連説明の少なくとも１つを遂行するようにさせるよう構成される。
【０１１７】
本発明の幾つかの実施形態は、３ＧＰＰネットワークで使用される。又、それらは、他の３ＧＰＰ及び非３ＧＰＰモバイル及び固定ネットワーク、例えば、ＣＤＭＡ、ＥＤＧＥ、ＬＴＥ、ＬＴＥ−Ａ、ＵＴＲＡＮ、ＷｉＦｉ、ＷＬＡＮネットワーク、ＰＳＴＮ、等でも使用される。即ち、本発明の実施形態は、アクセス技術に関わりなく使用される。
【０１１８】
ある情報断片は、あるエンティティから別のエンティティへ１つ又は複数のメッセージにおいて送信される。それらメッセージの各々は、更なる（異なる）情報断片を含んでもよい。
【０１１９】
ネットワーク要素、プロトコル及び方法の名前は、現在の規格に基づく。他のバージョン又は他の技術では、それらのネットワーク要素及び／又はプロトコル及び／又は方法の名前は、それらが対応ファンクションを与える限り、異なってもよい。
【０１２０】
他の記載がないか又は文脈から明らかでない限り、２つのエンティティが異なるという記載は、それらが異なるファンクションを遂行することを意味する。それらが異なるハードウェアに基づくことは必ずしも意味しない。即ち、この説明に述べられたエンティティの各々は、異なるハードウェアに基づいてもよいし、或いはエンティティの幾つか又は全部が同じハードウェアに基づいてもよい。
【０１２１】
従って、前記説明によれば、本発明の規範的な実施形態は、例えば、ＥＭＳ又はＶＮＦマネージャー或いはそのコンポーネントのような制御装置、それを具現化する装置、それを制御及び／又は動作する方法、及びそれを制御及び／又は動作するコンピュータプログラム、並びにそのようなコンピュータプログラムを保持しそしてコンピュータプログラム製品を形成する媒体を提供することが明らかであろう。
【０１２２】
前記ブロック、装置、システム、技術、手段、デバイス又は方法のいずれかを具現化することは、非限定例として、ハードウェア、ソフトウェア、ファームウェア、特殊目的回路又はロジック、汎用ハードウェア又はコントローラ、又は他のコンピューティング装置、バーチャルマシン、或いはその幾つかの組み合せとしての具現化を包含する。
【０１２３】
以上、本発明の好ましい実施形態と現在考えられるものが説明されたと理解されたい。しかしながら、好ましい実施形態の説明は、一例に過ぎず、特許請求の範囲に規定された本発明の範囲から逸脱せずに種々の修正がなされ得ることに注意されたい。
【０１２４】
当業者であれば、技術の進歩と共に、本発明の概念は、種々の仕方で具現化できることが明らかであろう。本発明及びその実施形態は、上述した例に限定されず、特許請求の範囲内で変更可能である。
【０１２５】
略語
３ＧＰＰ：第３世代パートナーシッププロジェクト
５Ｇ：第５世代
ＡＰＩ：アプリケーションプログラムインターフェイス
ＢＳＳ：ビジネスサポートシステム
ＣＰＵ：中央処理ユニット
Ｃｔｒｌ：制御
ＤＣ：データセンター
ＤＬ：ダウンリンク
ＤＰＤＫ：インテルデータプレーン開発キット
ＥＤＧＥ：ＧＳＭ進化のためのエンハンストデータレート
ＥＭＳ：エレメントマネージメントシステム
ＥＰＣ：進化型パケットコア
ＥＴＳＩ：ヨーロピアンテレコミュニケーションズスタンダードインスティテュート
ＧＰＲＳ：ジェネリックパケットラジオサービス
ＧＳＭ：移動通信用グローバルシステム
ＩＤ：識別子
ＩＥＴＦ：インターネットエンジニアリングタスクフォース
ＩＰ：インターネットプロトコル
ＩＴ：情報テクノロジー
ＬＢ：負荷バランサー
ＬＴＥ：長期進化
ＬＴＥ−Ａ：ＬＴＥアドバンスト
ＮＡＴ：ネットワークアドレス変換
ＮＦＶ：ネットワークファンクションバーチャル化
ＮＦＶＩ：ＮＦＶインフラストラクチャー
ＮＯＲＭＡ：ＮＯｖｅｌラジオマルチサービス適応ネットワークアーキテクチャー
ＯＳ：オペレーティングシステム
ＯＳＳ：オペレーションサポートシステム
ＰＣＲＦ：ポリシー及び課金ルールファンクション
ＰＳＴＮ：公衆交換電話ネットワーク
Ｒｅｌ：リリース
ＳＤＮ：ソフトウェア定義ネットワーキング
ＳＦ：サービスファンクション
ＳＦＣ：サービスファンクションチェーン
ＳＦＦ：サービスフォワーダーファンクション
ＳＲ−ＩＯＶ：単一ルートＩ／Ｏバーチャル化
ＳＷ：ソフトウェア
ＴＣＯ：総保有コスト
ＴＣＰ：送信制御プロトコル
ＴＳ：技術仕様
ＵＥ：ユーザ装置、移動装置
ＵＬ：アップリンク
ＵＭＴＳ：ユニバーサルモバイルテレコミュニケーションシステム
ＵＲＬ：ユニフォームリソースロケーター
ＶＩＭ：バーチャルインフラストラクチャーマネージャー
ＶＭ：バーチャルマシン
ＶＮＦ：バーチャル化ネットワークファンクション
ｖＮＩＣ：バーチャルネットワークインターフェイスカード
ＶｏＩＰ：ボイスオーバーＩＰ
ＷｉＦｉ：ワイヤレスフィデリティ
ＷＬＡＮ：ワイヤレスローカルエリアネットワーク
【符号の説明】
【０１２６】
１０：需要検出手段
２０：再構成手段
１１０：呼び出し頻度検出手段
１２０：再構成手段
２１０：負荷検出手段
２２０：再構成手段
３１０：構成監視手段
３２０：追加手段
６１０：プロセッサ
６２０：メモリ
【図１】
2018528526.tif 000003
【図２】
2018528526.tif 000004
【図３】
2018528526.tif 000005
【図４】
2018528526.tif 000006
【図５】
2018528526.tif 000007
【図６】
2018528526.tif 000008
【図７】
2018528526.tif 000009
【図８】
2018528526.tif 000010
【図９】
2018528526.tif 000011
【図１０】
2018528526.tif 000012
【図１１】
2018528526.tif 000013
【図１２】
2018528526.tif 000014
【図１３】
2018528526.tif 000015
【図１４】
2018528526.tif 000016
【図１５】
2018528526.tif 000017
【図１６】
2018528526.tif 000018
【国際調査報告】
2018528526.tif 000019
2018528526.tif 000020
2018528526.tif 000021
2018528526.tif 000022