(57)【特許請求の範囲】
【請求項１】
クラウドシステム内のマルチキャストクラウドコントローラ（“ＭＣＣ”）により実行される、クラウドネットワーク内のマルチキャストトラフィックを管理する方法であって、前記ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、前記仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、前記仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結され、前記方法は、
前記ＭＣＣにおいて、マルチキャストグループに加入しているテナントのＶＭのセットのうちのＶＭからの、前記マルチキャストグループを識別するグループ退去メッセージを受信するステップ（１７０１）と、
前記ＶＭのＶＳにおける、前記マルチキャストグループについての前記ＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリ及び出力グループを削除するステップ（１７０３）と、
前記ＶＳにおける、前記ＶＭへインカミングパケットを転送する入力グループ内のアクションを削除するステップ（１７０５）と、
前記ＶＭについてのＴＯＲＳからのループバックトラフィックを破棄するルールを削除するステップ（１７０７）と、
を含む方法。
【請求項２】
前記ＶＳにおける、前記ＶＭへインカミングパケットを転送するルール及び関連付けられる入力グループを削除するステップ、
をさらに含む、請求項１の方法。
【請求項３】
前記ＴＯＲＳにおける、マルチキャストグループトラフィックを前記ＶＳへ転送するための、入力グループ及び出力グループ内のアクションを削除するステップ、
をさらに含む、請求項１の方法。
【請求項４】
前記ＶＭは、前記マルチキャストグループに加入している、ラック内の最後のＶＭであり、前記方法は、
入力グループ及び出力グループを含めて、前記ＴＯＲＳにおける、マルチキャストグループを管理するルールを削除するステップ、
を含む、請求項１の方法。
【請求項５】
前記ＶＭについてのインカミングマルチキャストトラフィックを、ＶＭ移動の期間中にバッファリングするためにクラウドネットワークマネージャへ転送するように前記ＶＳを構成するステップ、
をさらに含む、請求項１の方法。
【請求項６】
ＶＭの移動が完了した後に、バッファリングされたトラフィックを前記ＶＭへ転送するステップと、
前記ＭＣＣにおいて、前記ＶＭについてのＶＳレコード及びＴＯＲＳレコードを修正するステップと、
前記ＶＭが加入している各マルチキャストグループについて、前記ＶＭの新たなＶＳ及び新たなＴＯＲＳのための参加動作を実行するステップと、
前記ＶＭが加入している各マルチキャストグループについて、前記ＶＭの前記ＶＳ及び前記ＴＯＲＳのための退去動作を実行するステップと、
をさらに含む、請求項１の方法。
【請求項７】
クラウドシステム内のマルチキャストクラウドコントローラ（“ＭＣＣ”）により実行される、クラウドネットワーク内のマルチキャストトラフィックを管理する方法であって、前記ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、前記仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、前記仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結され、前記方法は、
前記ＭＣＣにおいて、ＶＭからの、グループ退去メッセージを受信するステップ（１７０１）と、
前記ＶＭのＶＳにおける、前記グループ退去メッセージにより識別されるマルチキャストグループについての前記ＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリ及び出力グループを削除するステップ（１７０３）と、
前記ＶＳにおける、前記ＶＭへインカミングパケットを転送する入力グループ内のアクションを削除するステップ（１７０５）と、
前記ＶＭについてのＴＯＲＳからのループバックトラフィックを破棄するルールを削除するステップ（１７０７）と、
前記ＶＳにおいて前記ＶＭが前記マルチキャストグループに加入している最後のＶＭであるかどうかをチェックするステップ（１７０９）と、
ＶＭについてのインカミングパケットを転送するルールを、関連付けられる入力グループと共に削除するステップ（１７１１）と、
前記ＴＯＲＳのフローテーブルにおいて、入力グループ及び出力グループ内の、前記ＶＭの前記ＶＳへマルチキャストグループパケットを転送するためのアクションを削除するステップ（１７１３）と、
前記ＶＭが、ラック上の、前記マルチキャストグループに加入している最後のＶＭであるかどうかをチェックするステップ（１７１５）と、
入力グループ及び出力グループを含めて、前記ＴＯＲＳの前記フローテーブル内の、前記マルチキャストグループを管理するルールを削除するステップ（１７１７）と、
を含む方法。
【請求項８】
クラウドシステム内に実装されるマルチキャストクラウドコントローラ（“ＭＣＣ”）（２９０）であって、前記ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、前記仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、前記仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結され、前記ＭＣＣは、
各々のモジュールが他のモジュールと通信関係にある、グループ退去モジュール（４２７）及びＶＭ移動モジュールを実行するプロセッサ、
を含み、
前記グループ退去モジュールは、前記ＭＣＣにおいて、ＶＭからの、マルチキャストグループを識別するグループ退去メッセージを受信し、前記ＶＳにおける、前記マルチキャストグループについての前記ＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリ及び出力グループを削除し、前記ＶＳにおける、前記ＶＭへインカミングパケットを転送するための入力グループ内のアクションを削除し、前記ＶＭについての前記ＴＯＲＳからのループバックトラフィックを破棄するためのルールを削除する、ように構成される、
ＭＣＣ。
【請求項９】
前記グループ退去モジュールは、前記ＶＳにおける、前記ＶＭへインカミングパケットを転送するためのルール及び関連付けられる入力グループを削除する、ようにさらに構成される、請求項８のＭＣＣ。
【請求項１０】
前記グループ退去モジュールは、前記ＴＯＲＳにおける、マルチキャストグループトラフィックを前記ＶＳへ転送するための、入力グループ及び出力グループ内のアクションを削除する、ようにさらに構成される、請求項８のＭＣＣ。
【請求項１１】
前記ＶＭは、前記マルチキャストグループに加入している、ラック内の最後のＶＭであり、前記グループ退去モジュールは、入力グループ及び出力グループを含めて、前記ＴＯＲＳにおける、マルチキャストグループを管理するルールを削除する、ように構成される、請求項８のＭＣＣ。
【請求項１２】
前記グループ退去モジュールは、前記ＶＳにおいて、前記ＶＭについてのインカミングマルチキャストトラフィックを、ＶＭ移動の期間中にバッファリングするためにクラウドネットワークマネージャへ転送する、ようにさらに構成される、請求項１１のＭＣＣ。
【請求項１３】
前記マルチキャストＶＭ移動モジュールは、ＶＭの移動が完了した後に、バッファリングされたトラフィックを前記ＶＭへ転送し、前記ＭＣＣにおける前記ＶＭについてのＶＳレコード及びＴＯＲＳレコードを修正し、前記ＶＭが加入している各マルチキャストグループについて、前記ＶＭの新たなＶＳ及び新たなＴＯＲＳのための参加動作を実行し、前記ＶＭが加入している各マルチキャストグループについて、前記ＶＭの前記ＶＳ及び前記ＴＯＲＳのための退去動作を実行する、ようにさらに構成される、請求項８のＭＣＣ。
【請求項１４】
クラウドシステム内において、クラウドネットワーク内のマルチキャストトラフィックを管理するために実装されるマルチキャストクラウドコントローラ（“ＭＣＣ”）（２９０）であって、前記ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、前記仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、前記仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結され、ＭＣＣは、
グループ退去モジュールを実行するプロセッサを含み、
前記グループ退去モジュール（４２７）は、前記ＭＣＣにおいて、ＶＭからの、グループ退去メッセージを受信し、前記ＶＭのＶＳにおける、前記グループ退去メッセージにより識別されるマルチキャストグループについての前記ＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリ及び出力グループを削除し、前記ＶＳにおける、前記ＶＭへインカミングパケットを転送するための入力グループ内のアクションを削除し、前記ＶＭについてのＴＯＲＳからのループバックトラフィックを破棄するためのルールを削除し、前記ＶＳにおいて前記ＶＭが前記マルチキャストグループに加入している最後のＶＭであるかどうかをチェックし、ＶＭについてのインカミングパケットを転送するルールを、関連付けられる入力グループと共に削除し、前記ＴＯＲＳのフローテーブルにおいて、入力グループ及び出力グループ内における、前記ＶＭの前記ＶＳへマルチキャストグループパケットを転送するためのアクションを削除し、前記ＶＭが、ラック上の、前記マルチキャストグループに加入している最後のＶＭであるかどうかをチェックし、入力グループ及び出力グループを含めて、前記ＴＯＲＳの前記フローテーブル内における、前記マルチキャストグループを管理するルールを削除する、
ＭＣＣ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、クラウドコンピューティングの分野に関し、より具体的には、クラウドコンピューティングにおけるマルチキャストサポートに関する。
【背景技術】
【０００２】
多年にわたって、大規模な法人はそのコンピュータリソースをデータセンタへと集中させてきた。この傾向は、ここ数年で、サーバ仮想化技術がますます普及するにつれて加速している。データセンタがより大規模になったために、いくつかのデータセンタ事業者は、コンピューティング、ストレージ及びネットワーク通信リソースを外部の顧客へと提供し始めており、すると外部の顧客はデータセンタのテナントになる。提供されるサービスは、典型的には、伸縮自在の、オンデマンドの処理、最も実用的な目的のためにテナントの支払い能力によってのみ制限されるストレージ、及びインターネットへのネットワーク帯域幅からなる。この発展は、クラウドコンピューティングと呼ばれる。
【０００３】
サーバ仮想化技術は、複数のサーバのプールを本質的に１つの大規模なコンピュータリソースとして管理することを可能とする。オペレーティングシステムとハードウェアとの間には、ハイパーバイザと呼ばれるソフトウェアのレイヤが存在する。ハイパーバイザは、仮想化されたサーバ上での仮想マシン（ＶＭ）の実行をスケジューリングする。ＶＭは、いくつかのアプリケーションと共にパッケージ化されたオペレーティングシステムイメージである。ハイパーバイザは、ＶＭを一時停止し、及び負荷分散をするためにＶＭをサーバ間で移動させることを可能とする。負荷分散及びクラッシュを捕捉するためのＶＭ実行の監視は、遥かに高コストで専門化された解決策と共に達成される企業アプリケーションについて、同じ種類の耐障害性及びスケーラビリティサービスを提供する。これらシステムを、ここでは“クラウドシステム”という。クラウドマネージャシステムは、クラウドシステム内のＶＭの実行を監督し、実行をスケジューリングして、需要を満たし、サーバ利用率を最適化し、及び電力消費を最小化する。クラウド実行マネージャは、進行中のサービス提供への影響の無い、ハードウェア及びソフトウェアのサービス中（in-service）アップグレードを可能とするように、実行をスケジューリングすることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
マシン間のＶＭの任意の移動をサポートするために、クラウドシステム内のネットワーキングもまた仮想化されなければならない。今日のほとんどのクラウドシステムは、ハイパーバイザへ仮想スイッチを取り入れることにより、ネットワークを仮想化する。仮想スイッチは、ハイパーバイザの制御下で実行中のＶＭへの仮想ネットワークポートを提供する。仮想スイッチソフトウェアは、サーバリソースがハイパーバイザにより仮想化されるのと同様のやり方で、ネットワークリソースを仮想化することをも可能とする。ハイパーバイザ及び仮想スイッチは、それにより、サーバ間でＶＭを移動させることを可能とするように協働することができる。ハイパーバイザは、ＶＭを移動させる場合には新たなロケーションについて仮想スイッチと通信し、仮想スイッチは、ＶＭのアドレス（例えば、レイヤ２のＭＡＣ（Media  Access  Control）アドレス及びレイヤ３のＩＰ（Internet  Protocol）アドレス）についてのネットワークのルーティングテーブルが更新され、そしてパケットがその新たなロケーションへとルーティングされることを保証する。
【０００５】
マルチキャストは、ソースノードによる加入ノード（例えば、ＶＭ）のグループへのデータのデリバリのためのシステムである。クラウドシステム内のＶＭにより提供されるいくつかのサービスは、データセンタ内のマルチキャストプロトコルの実装から恩恵を受けることができるはずである。しかしながら、そうしたマルチキャストプロトコルのサポートは、クラウドシステムによってはサポートされず、なぜなら、それらマルチキャストプロトコルは、ホストマシンのキャパシティを上回る多量の制御ステートを維持することを要し、データセンタ及び全てのクラウドサービスの性能を減少させかねないからである。
【課題を解決するための手段】
【０００６】
クラウドシステム内のマルチキャストクラウドコントローラ（“ＭＣＣ”）により、クラウドネットワーク内のマルチキャストトラフィックを管理する方法が実行される。ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結される。当該方法は、ＭＣＣにおいて、マルチキャストグループに加入しているテナントのＶＭのセットのうちのＶＭからの、マルチキャストグループを識別するグループ退去メッセージを受信することを含む。ＶＭのＶＳにおける、マルチキャストグループについてのＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリ及び出力グループが削除される。ＶＳにおける、ＶＭへインカミングパケットを転送する入力グループ内のアクションが削除され、ＶＭについてのＴＯＲＳからのループバックトラフィックを破棄するルールが削除される。
【０００７】
クラウドシステム内のマルチキャストクラウドコントローラ（“ＭＣＣ”）により、クラウドネットワーク内のマルチキャストトラフィックを管理する方法が実行される。ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結される。当該方法は、ＭＣＣにおいて、ＶＭからの、グループ退去メッセージを受信することを含む。ＶＭのＶＳにおける、フローテーブルエントリ及び出力グループが削除される。マルチキャストグループについてのＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリは、グループ退去メッセージにより識別される。ＶＳにおける、ＶＭへインカミングパケットを転送する入力グループ内のアクションが削除される。ＶＭについてのＴＯＲＳからのループバックトラフィックを破棄するルールが削除される。ＶＳにおいてＶＭがマルチキャストグループに加入している最後のＶＭであるかどうかのチェックが行われる。ＶＭについてのインカミングパケットを転送するルールが、関連付けられる入力グループと共に削除される。ＴＯＲＳのフローテーブルにおいて、入力グループ及び出力グループ内における、ＶＭのＶＳへマルチキャストグループパケットを転送するためのアクションが削除される。ＶＭが、ラック上の、マルチキャストグループに加入している最後のＶＭであるかどうかのチェックが行われ、入力グループ及び出力グループを含めて、ＴＯＲＳのフローテーブル内における、マルチキャストグループを管理するルールが削除される。
【０００８】
クラウドシステム内において、マルチキャストクラウドコントローラ（“ＭＣＣ”）が実装される。当該ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結される。当該ＭＣＣは、各々のモジュールが他のモジュールと通信関係にある、グループ退去モジュール及びＶＭ移動モジュールを実行するプロセッサを含む。グループ退去モジュールは、ＭＣＣにおいて、ＶＭからの、マルチキャストグループを識別するグループ退去メッセージを受信し、ＶＳにおける、マルチキャストグループについてのＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリ及び出力グループを削除し、ＶＳにおける、ＶＭへインカミングパケットを転送する入力グループ内のアクションを削除し、ＶＭについてのＴＯＲＳからのループバックトラフィックを破棄するルールを削除する、ように構成される。
【０００９】
クラウドシステム内において、クラウドネットワーク内のマルチキャストトラフィックを管理するためにマルチキャストクラウドコントローラ（“ＭＣＣ”）が実装される。当該ＭＣＣは、１つ以上の仮想マシン（“ＶＭ”）をホスティングするための少なくとも１つの仮想化されたサーバへ連結され、仮想化されたサーバは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）をサポートする少なくとも１つの仮想スイッチ（“ＶＳ”）を含み、仮想スイッチは、ＭＰＬＳをサポートするＴＯＲ（top  of  rack）スイッチ（“ＴＯＲＳ”）へ連結される。ＭＣＣは、グループ退去モジュールを実行するプロセッサを含む。グループ退去モジュールは、ＭＣＣにおいて、ＶＭからの、グループ退去メッセージを受信し、ＶＭのＶＳにおける、グループ退去メッセージにより識別されるマルチキャストグループについてのＶＭからのアウトバウンドマルチキャストトラフィックを転送するためのフローテーブルエントリ及び出力グループを削除する。グループ退去モジュールは、ＶＳにおける、ＶＭへインカミングパケットを転送する入力グループ内のアクションを削除し、ＶＭについてのＴＯＲＳからのループバックトラフィックを破棄するルールを削除する。グループ退去モジュールは、ＶＳにおいてＶＭがマルチキャストグループに加入している最後のＶＭであるかどうかをチェックし、ＶＭについてのインカミングパケットを転送するルールを、関連付けられる入力グループと共に削除し、ＴＯＲＳのフローテーブルにおいて、入力グループ及び出力グループ内における、ＶＭのＶＳへマルチキャストグループパケットを転送するためのアクションを削除し、ＶＭが、ラック上の、マルチキャストグループに加入している最後のＶＭであるかどうかをチェックし、入力グループ及び出力グループを含めて、ＴＯＲＳのフローテーブル内における、マルチキャストグループを管理するルールを削除する。
【図面の簡単な説明】
【００１０】
この発明は、この発明の実施形態を例示するために使用される以下の説明及び添付の図面を参照することにより、最も良く理解され得る。図面は以下の図を含む。
【００１１】
【図１Ａ】図１Ａ及び図１Ｂは、ラベルスタックの図である。
【図１Ｂ】図１Ａ及び図１Ｂは、ラベルスタックの図である。
【図２】図２は、クラウドシステム内のコンポーネントの１つの実施形態の図である。
【図３Ａ】図３Ａ〜図３Ｃは、マルチキャストコントローラ（ＭＣＣ）により維持されるデータ構造の１つの実施形態の図である。
【図３Ｂ】図３Ａ〜図３Ｃは、マルチキャストコントローラ（ＭＣＣ）により維持されるデータ構造の１つの実施形態の図である。
【図３Ｃ】図３Ａ〜図３Ｃは、マルチキャストコントローラ（ＭＣＣ）により維持されるデータ構造の１つの実施形態の図である。
【図４】図４は、クラウドシステム内のコンポーネントの他の実施形態の図である。
【図５】図５は、クラウドシステム内の仮想マシンをアクティブ化するための処理の１つの実施形態のフローチャートである。
【図６】図６は、仮想マシンをアクティブ化するための処理の１つの実施形態の図である。
【図７】図７は、ＶＭからのＤＨＣＰリクエストを傍受するための処理の１つの実施形態のフローチャートである。
【図８】図８は、仮想マシンからのＤＨＣＰリクエストを傍受するための処理の１つの実施形態の図である。
【図９】図９は、ＶＭからのＡＲＰリクエストを傍受するための処理の１つの実施形態のフローチャートである。
【図１０】図１０は、仮想マシンからのＡＲＰリクエストを傍受するための処理の１つの実施形態の図である。
【図１１】図１１は、クラウドコンピューティングネットワーク内において第１の仮想化されたサーバから第２の仮想化されたサーバへとＶＭを移動させる処理の１つの実施形態の図である。
【図１２】図１２は、クラウドシステム内のマルチキャストグループにＶＭが加入する処理の１つの実施形態のフローチャートである。
【図１３】図１３は、仮想スイッチが構成されているクラウドシステム内のマルチキャストグループにＶＭが加入する処理の他の実施形態のフローチャートである。
【図１４】図１４は、クラウドシステム内のマルチキャストグループに加入しているＶＭをサポートするように構成されるフローテーブルの１つの実施形態の図である。
【図１５】図１５は、ＴＯＲスイッチが構成されているクラウドシステム内のマルチキャストグループにＶＭが加入する処理の他の実施形態のフローチャートである。
【図１６】図１６は、クラウドシステム内のマルチキャストグループに加入しているＶＭをサポートするように構成されるＴＯＲスイッチのフローテーブルの１つの実施形態の図である。
【図１７】図１７は、クラウドシステム内のマルチキャストグループを退去するＶＭをサポートするための処理の１つの実施形態のフローチャートである。
【図１８】図１８は、クラウドシステム内の仮想サーバ間でのＶＭの移動をサポートするための処理の１つの実施形態のフローチャートである。
【図１９】図１９は、この発明の実施形態による例示的なコンピュータシステムのブロック図を例示する。
【発明を実施するための形態】
【００１２】
以下の説明は、クラウドネットワーク内においてマルチプロトコルラベルスイッチング（ＭＰＬＳ）フローエントリを管理してマルチキャストをサポートするための方法及び装置を記載する。以下の説明では、本発明の、より完全な理解をもたらすために、ロジック実装、ＯＰコード、オペランドを特定する手段、リソースパーティショニング／共有／複製の実装、システムコンポーネントのタイプ及び相互関係、並びにロジックパーティショニング／統合の選択肢といった多数の固有の詳細が明記されている。しかしながら、この発明がそうした固有の詳細を用いなくても実施され得ることが、当業者により認められるであろう。その他の例では、この発明を不明瞭にすることのないように、制御構造、ゲートレベル回路、及び全ソフトウェア命令シーケンスが詳細には示されていない。当業者は、含まれる説明を用いて、必要以上の実験を行うことなく、適正な機能性を実装することが可能であろう。
【００１３】
明細書における、“１つの実施形態”、“一実施形態”、“例示的な実施形態”などへの言及は、記載される実施形態が特定の特徴、構造、又は特性を含み得るものの、各実施形態が当該特定の特徴、構造、又は特性を必ずしも含むとは限らないかもしれないことを示す。その上、そうした語句は、必ずしも同じ実施形態を指している訳ではない。さらに、一実施形態に結びつけて特定の特徴、構造、又は特性が説明されている場合、明示的に記載されているか否かに関わらず、その他の実施形態に結びつけてそうした特徴、構造、又は特性を作用させることは、当業者の知識の範囲内であることが思量される。
【００１４】
以下の説明及び特許請求の範囲では、“連結される”及び“接続される”という用語が、その派生語と共に使用され得る。これら用語が互いに対して同義語として意図されないことを理解されるべきである。“連結される”は、互いに物理的に又は電気的に直接接触する関係にあり得るか又はあり得ない２つ以上の要素が互いに協働し又は相互作用することを示すために使用される。“接続される”は、互いに連結される２つ以上の要素間における通信の確立を示すために使用される。
【００１５】
理解を容易にするために、図においては、或る項目の任意選択の特質（例えば、この発明の所与の実装によりサポートされていない特徴、所与の実装によりサポートされているものの、或る状況では使用され、また或る状況では使用されない特徴）を表明するために、破線が使用される。
【００１６】
図に示される技法は、１つ以上の電子デバイス上で記憶されて実行されるコード及びデータを使用して実装されることが可能である。そうした電子デバイスは、非一時的であって有形のコンピュータ可読記憶媒体（例えば、磁気ディスク、光ディスク、読み出し専用メモリ、フラッシュメモリデバイス、相変化メモリ）及び一時的コンピュータ可読通信媒体（例えば、電気的、光学的、音響的、又はその他の形の伝播信号−例えば、搬送波、赤外線信号、デジタル信号など）を使用して、コード及びデータを記憶し、コード及びデータを（内部的に、及び／又は、その他の電子デバイスとの間でネットワークを通じて）通信する。加えて、そうした電子デバイスは、典型的には、ストレージデバイス、１つ以上の入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、並びにネットワーク接続といった１つ以上のその他のコンポーネントと連結されるプロセッサのセット又は１つ以上のプロセッサを含む。プロセッサのセット及びその他のコンポーネントを連結することは、典型的には、１つ以上のバス又はブリッジ（バスコントローラとも呼称される）を経由する。ネットワークトラフィックを担持するストレージデバイス及び信号は、それぞれ、１つ以上の非一時的かつ有形のコンピュータ可読媒体及び一時的なコンピュータ可読通信媒体の代表である。よって、所与の電子デバイスのストレージデバイスは、典型的には、当該電子デバイスの１つ以上のプロセッサのセット上での実行のためにコード及び／又はデータを記憶する。当然ながら、この発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの様々な組み合わせを使用して実装されてよい。
【００１７】
概観
本実施形態は、ここで以下に説明するように、マルチプロトコルラベルスイッチング（ＭＰＬＳ）サービスを使用してＩＰ（Internet  Protocol）マルチキャストをサポートする方法及び装置を提供する。特に、本実施形態は、ＭＰＬＳサービスを使用してデータセンタ内におけるＩＰマルチキャストをサポートして、クラウドコンピューティングサービスをサポートする。
【００１８】
データセンタは、しばしば、仮想化されたサービスを実行する物理的コンピューティングデバイスのセットとして編成される。これら物理的コンピューティングデバイスは、仮想化されたサービスを個々に又は組み合わせて実行することができるデバイスのラック又はグループへと編成されることが可能である。物理的コンピューティングデバイスは、ラック内のその他の物理的デバイスと、及び、ＴＯＲスイッチ（ＴＯＲＳ）のセットを経由してその他のラック内の物理的デバイスと、ネットワーク接続されることが可能である。これらＴＯＲＳは、それらのラック内の各物理的デバイスへ接続され、次いで、互いに接続されるか、又は、データセンタ内のＴＯＲＳのサブセットへ接続される。ＴＯＲＳは、メッシュトポロジーにおいて、データセンタのその他のＴＯＲＳとネットワーク接続されることが可能である。このメッシュ又はネットワークファブリックは、ＴＯＲＳ及びその他のデバイスを接続するために、任意の数の中間ネットワーキングデバイスを含むことができる。ＴＯＲＳは、データセンタの外部のデバイスと、直接的に又は間接的に、のいずれかで接続されることも可能である。このデータセンタアーキテクチャについては、より詳細に、ここでは以下においてさらに説明する。
【００１９】
クラウドコンピューティング施設としてサービスする多くのデータセンタは、ウェブサービスアプリケーションをサポートするに過ぎない。ウェブサービスアプリケーションは、リクエストをウェブサーバのプールへディスパッチする負荷分散フロントエンドからなる。リクエストは、概念的にはインターネット上のアプリケーションから発生し、従って、セキュリティ及びプライバシー要件は、プライベートな法人ネットワーク内のアプリケーションについての要件よりも遥かに緩い。他のクラウドコンピューティングのトレンドは、セキュアなマルチテナンシーであり、ここでは、クラウドサービスプロバイダが、クラウドの外部におけるテナントの分散オフィスネットワークとクラウド内における仮想プライベートネットワーク（ＶＰＮ）との間にＶＰＮ様の接続を提供する。このことは、クラウド内のテナントのアプリケーションが、法人のワイドエリアネットワーク（ＷＡＮ）に類似するネットワーク環境において動作することを可能とする。データセンタを所有する法人の範囲内の顧客にのみこれらサービスが提供されるプライベートデータセンタについては、マルチテナンシーについてのセキュリティ及びプライバシー要件が緩和される。パブリックデータセンタについては、複数個のテナントからのトラフィックがその他のテナントから隔離されること、及び、１つのテナントからのトラフィックが他のテナントへ到達する可能性のないことを、クラウドサービス事業者が保証しなければならない。いずれのケースにおいても、クラウドコンピューティング施設は、ＭＡＣ（media  access  control）レイヤの仮想ローカルエリアネットワーク（ＶＬＡＮ）を使用して、クラウドコンピュータネットワークを実装する傾向を有する。
【００２０】
例えば、２つの異なる外部の企業顧客に対して２つの仮想プライベートクラウド（ＶＰＣ）がセットアップされることが可能である。ＶＰＣは、クラウド内で空間を賃借している企業にセキュアなマルチテナンシーを提供する、ＶＭ、ストレージ、及びネットワーキングリソースの集まりからなる。企業顧客は、パブリック事業者ネットワーク上で稼働するインターネットを通じて、ＶＰＮを介してＶＰＣ内へ接続する。
【００２１】
ＶＰＣに新たなサービスインスタンス（例えば、新たな仮想マシン“ＶＭ”）を追加するために、クラウド実行マネージャは、当該ＶＭを、仮想化されたサーバ上のハイパーバイザ上で稼働するように初期化する。仮想化されたサーバ上の仮想スイッチは、新たなＶＭを追加するテナントについてのＶＰＮの一部分であるＶＬＡＮ内に、当該ＶＭを含むように構成される。いくつかのケースでは、新たなサービスについて仮想顧客エッジルータが更新され、その新たなサービスでクラウドコンピューティング施設内のプロバイダエッジルータが更新される。
【００２２】
ＶＰＮを提供するために、クラウドシステムは、３つの解決策のうちの１つを実装する。第１の可能な解決策では、各テナントが、別々のＶＬＡＮスライスを受信する。第２の可能な解決策では、テナントＶＰＮが、ＩＰカプセル化を使用して実装される。第３の可能な解決策では、テナントＶＰＮが、ＭＡＣアドレスカプセル化を使用して実装される。これら解決策の各々は、異なる欠陥に苦慮している。クラウドシステムがＶＬＡＮ隔離を実装する場合、各テナントには別々のＶＬＡＮタグが割り当てられ、クラウドネットワークは、フラットなレイヤ２ネットワークとして稼働される。ＶＬＡＮタグは１２ビットを有しており、従って、クラウド事業者がＶＬＡＮ隔離を使用する場合、テナントの数は、４０９６に制限される。可能なテナントの数に対するこの制限が、クラウドシステムのスケーラビリティに対しての、主たる制限となっている。
【００２３】
ＶＬＡＮ隔離の他の問題は、標準的なエリアネットワーキング（例えば、ＬＡＮ、ＷＡＮ、ＭＡＮ；ＩＥＥＥ（Institute  of  Electrical  and  Electronics  Engineers）８０２．１）スイッチングがスパニングツリープロトコル（ＳＴＰ）を使用して、ルートをセットアップすることである。ルーティングループの可能性をなくすために、ＳＴＰは、複数個のルートが存在するかどうかに関わらず、ソースアドレスと宛先アドレスとの間に唯一のパスを指定する。スパニングツリールートがトラフィック圧迫下に入り、且つ代替ルートが無視される場合、このことは、スイッチングファブリックの輻輳及び過少利用を招く恐れがある。
【００２４】
クラウドシステムがＩＰカプセル化を実装する場合、クラウドシステムは、ルーテッドＩＰネットワークとして稼働され、各テナントのトラフィックを隔離するために、ＩＰトンネルが使用される。トンネルのエンドポイントが、ＶＭが稼働している仮想化されたソースサーバ及び仮想化された宛先サーバ上のソース仮想スイッチ及び宛先仮想スイッチであるという状態で、テナントからのトラフィックは、（典型的にはＧＲＥ（Generic  Routing  Encapsulation)を使用して）ＩＰパケット内にカプセル化される。
【００２５】
ＩＰカプセル化は、クライアントが、レイヤ２トンネリングプロトコル（Ｌ２ＴＰ）においてイーサネットフレームをカプセル化することにより、任意のレイヤ２サービスを最上位に定義することを可能とする。ＩＰカプセル化は、クラウドシステム全体のＩＰアドレス空間によってのみ制約を受ける、多数のテナントを可能にもする。テナントは、それ自体のＩＰアドレス空間をＩＰトンネルの最上位に配備することもできる。しかしながら、その他の方策が無ければ、ＩＰルーティングは単一ルートも選択し、従って、マルチパスルートが無視されて不必要な輻輳を招く。クラウドルーティングは、複数個のリンクにわたってパケットを拡散させるために等コストマルチパスを利用することができるものの、さらなる構成の複雑性を費やしてしまう。一般に、ＩＰルーテッドネットワークを構成することは時間を要し、ルータは、簡素なスイッチよりも、より高価なデバイスである傾向を有する。加えて、大規模なデータフローにとって必要であり得る専用帯域幅を提供するためにＩＰネットワークが有する手段は制限されている。
【００２６】
クラウドシステムがＭＡＣカプセル化を実装する場合、別々のテナントＶＰＮは、ＩＰカプセル化と同様に、ＭＡＣトンネルの内側でカプセル化されることにより実装される。ＭＡＣトンネルのエンドポイントは、典型的には、ＶＭが稼働している仮想化されたソースサーバ及び仮想化された宛先サーバ上の仮想スイッチである。ＭＡＣカプセル化は、ＶＬＡＮ隔離型を上回る、ＩＰカプセル化と同様の恩恵を提供し、所望であれば、クラウドをフラットなレイヤ２ネットワークとして稼働させることが可能であるという、付加された恩恵を伴う。欠点は、ＩＰとは異なり、ＭＡＣカプセル化についてのシグナリングプロトコルについての標準がほとんど存在せず、データプレーンカプセル化についての標準は存在するものの、それらがいくつかの既存のクラウド管理ソフトウェアプロダクトにおいては使用されないことである。このことは、或るタイプのハードウェアと共に作用しないというリスクを生じる。ＭＡＣカプセル化ネットワークを構成して維持することもまた、ＶＬＡＮ隔離型ネットワークを維持することよりも、より複雑である。
【００２７】
この発明の実施形態において、クラウドシステムは、ＶＰＣテナントについてＶＰＮを形成するためにＭＰＬＳを使用し、仮想スイッチ及びＴＯＲＳ内にフロールートをプログラミングする。例えば、ＭＰＬＳスイッチは、ＯｐｅｎＦｌｏｗスイッチ仕様バージョン１．１．０（２０１１年２月）に記述されるようなＯｐｅｎＦｌｏｗを介して、プログラミングされたフロールートを有することができる。仮想スイッチは、イーサネットＭＡＣアドレスを使用して、仮想化されたサーバ上のＶＭへパケットをルーティングすること、及び、パケットを特定のＭＰＬＳラベルスイッチパス（ＬＳＰ）に分類することが可能であるが、仮想スイッチ以降では、イーサネットもＩＰアドレスも、ルーティング用には使用されない。その代りに、ルーティングは、ＩＰ宛先アドレス及びＭＡＣ宛先アドレスに基づいて割り当てられたＭＰＬＳラベルを厳密に使用することによって行われる。当該処理は、ワイドエリアネットワーク内の仮想プライベート無線サービス（ＶＰＷＳ）又はレイヤ３ＶＰＮ（Ｌ３ＶＰＮ）と同様ではあるが、同一ではない。
【００２８】
１つの実施形態において、ＯｐｅｎＦｌｏｗコントローラにより実行されるクラウドネットワークマネージャ（ＣＮＭ）は、ＯｐｅｎＦｌｏｗを使用するフロールートを、ＶＭが稼働している仮想化されたサーバ上の仮想スイッチ内にインストールすることができる。フロールートは、ルートを指定するＭＰＬＳラベルであってＴＯＲＳと宛先側の仮想スイッチとの間でテナントに固有な当該ＭＰＬＳラベルと共に、仮想化されたサーバ上のテナントＶＭからのイーサネットフレームをカプセル化する。パケットは、次いで、ソースＶＭの仮想化されたサーバのＴＯＲＳへ転送される。ソースＴＯＲＳは、次いで、パケットをデータセンタネットワークファブリック内へルーティングする。クラウドネットワークファブリックがＭＰＬＳネットワークである場合、ソースＴＯＲＳは、ソースＴＯＲＳと宛先ＴＯＲＳとの間のルートを特定する他のＭＰＬＳラベルを付与する。宛先ＴＯＲＳは、当該ＭＰＬＳルーティングラベルを外し、ソース仮想スイッチにより付与されたラベルを使用して、パケットを適正な宛先サーバ及び仮想スイッチへルーティングする。宛先仮想スイッチは、ＴＯＲＳから仮想スイッチへのラベルを外し、当該パケットを、宛先ＭＡＣアドレスに基づいて正しいＶＭへ転送する。クラウドスイッチファブリックが光技術といった何らかのその他の技術をサポートしている場合、ＴＯＲＳは、適切な適応を実行する。
【００２９】
クラウドシステム内における、ＭＰＬＳのこの使用は、多数の利点を提供する。例えば、データプレーン上でＩＰルーティングが必要とされず、それにより、コスト、電力使用量、及び、ＩＰルーテッドクラウドネットワークを有する複雑性をなくす。クラウドアーキテクチャは、安価なＭＰＬＳスイッチのみを必要とする。クラウドシステム内のスイッチファブリックは、標準的なイーサネットスイッチ、ＭＰＬＳ対応スイッチ、光回路スイッチ、又は混成物（mixture）、例えば、高キャパシティフローには光スイッチ、その他のトラフィックには電気スイッチ、ですらあり得る。スイッチファブリックは、分散されたコンピューティングリソース間におけるワイドエリアネットワークですらあり得る。ＴＯＲＳは、カプセル化を適正にハンドリングする。サポートされることが可能なテナントの数は、ＭＰＬＳラベル空間のサイズに制限されない。テナントは、（所望であれば）それ自体のＩＰアドレス空間、及び（所望であれば）ＤＮＳサーバを管理することができる。クラウドスイッチファブリック内へのルーティングの詳細は、ＴＯＲＳによってハンドリングされ、そこでスケーラビリティ及びアグリゲーションの適正な混成を達成することができるハンドリングされ。
【００３０】
データプレーン上ではＭＰＬＳ、及び、制御プレーン上ではＯｐｅｎＦｌｏｗを使用して、ＶＰＣ内のＶＭ間におけるＩＰユニキャストのためにＶＰＮを使用する、クラウドシステム内の、このＭＰＬＳベースのルーティングの冒頭において、本実施形態は、ＭＰＬＳベースのＶＰＣネットワーク内においてマルチキャストをハンドリングする方法を提供する。クラウドシステムがデータプレーン内でＭＰＬＳを使用していることから、クラウドシステムは、そうでなければ分散制御プレーンネットワーク内において必要な、ＭＰＬＳマルチキャストの制御プレーンの複雑性の必要がない。このオーバーヘッドを回避することは、スケーラビリティ及び帯域幅利用率の観点で利点を提供し、それによりマルチキャストをクラウドシステム内で実用的且つ効果的に実装することができる。
【００３１】
高いレベルでは、本実施形態は以下のように作用する。仮想スイッチ（ＶＳ）は、ＶＭからの、ＩＰｖ４についてはインターネットグループ管理プロトコル（ＩＧＭＰ）パケットを、又は、ＩＰｖ６についてはマルチキャストリスナ発見（ＭＬＤ）パケットを、マルチキャストクラウドコントローラ（ＭＣＣ）へ転送する。ＭＣＣは、当該ＶＭをマルチキャストグループに追加し、ＶＳ及びソース側のＴＯＲＳ上に、当該ＶＭからマルチキャストグループへマルチキャストパケットをルーティングするルートをインストールする。各マルチキャストグループには、ＭＰＬＳラベルが割り当てられる。これが、グループに参加する、ラック上の最初のＶＭである場合、ＭＣＣは、グループ内のＶＭを有するラックにサービスするその他のＴＯＲＳ上にも、当該グループについてのパケットを当該新たなＴＯＲＳへルーティングするルートをインストールする。
【００３２】
マルチキャストのこの実装の利点は、データプレーン上でＩＰルーティングが必要とされず、コスト、電力使用量、及びＩＰルーテッドクラウドネットワークを有する複雑性をなくすことを含む。本実施形態は、安価なＭＰＬＳスイッチを使用して実装されることが可能である。クラウドシステム内における、ＴＯＲＳ間のネットワークファブリックは、標準的なイーサネットスイッチ、ＭＰＬＳ対応スイッチ、光回路スイッチ、又は混成物、例えば、高キャパシティフローには光スイッチ、及び、その他のトラフィックには電気スイッチ、ですらあり得る。ネットワークファブリックは、分散されたコンピューティングリソース間におけるワイドエリアネットワークですらあり得る。ＴＯＲＳは、カプセル化を適正にハンドリングする。クラウドネットワークファブリック内へのルーティングの詳細は、ＴＯＲＳによってハンドリングされハンドリングされ、そこでスケーラビリティ及びアグリゲーションの適正な混成を達成することができる。
【００３３】
上である程度まで論じたように、既存の解決策には様々な問題が存在する。今日のマルチテナントクラウドシステムにおいて、クラウドシステム事業者は、マルチキャストを使用可能にしないが、その理由は、マルチキャストがルータ内において過剰な制御ステートを必要とし、ＶＭ移動を妨げるためである。それとは対照的に、本実施形態は、ルータから制御ステートをなくし、当該制御ステートを、多量のメモリを有するサーバ内で稼働することの可能なＯｐｅｎＦｌｏｗコントローラ内に入れる。加えて、本実施形態は、マルチキャストをハンドリングするために必要とされる制御ステートの量を徹底的に削減するが、その理由は、データセンタネットワークが極めて定型的なものであり、ＴＯＲスイッチ、アグリゲーションスイッチ及びルータ、並びに仮想スイッチからなるためである。本実施形態は、ＶＭ移動も適切にハンドリングするハンドリングする。
【００３４】
本実施形態は、集中化されたＯｐｅｎＦｌｏｗコントローラがＴＯＲスイッチ及び仮想スイッチを直接プログラミングする集中制御プレーンを特徴とする。スケーラビリティは、メモリの量が非常に大きいことが可能なサーバ上で、転送を実装するのに必要なフローテーブルステートを除く、制御プレーンステートの全てを保持することによって、ハンドリングされる。ＯｐｅｎＦｌｏｗコントローラは、スイッチを直接プログラミングする。本実施形態が集中制御プレーンに基づいていることから、本実施形態は、クラウドシステム内におけるリンク発見プロトコル（ＬＤＰ）又はボーダーゲートウェイプロトコル（ＢＧＰ）の使用を必要としない。トラフィックは、入口側のＴＯＲスイッチ毎に複製されるが、マルチキャストグループに加入しているＶＭを有するラックにサービスしているＴＯＲスイッチへのみ送信され、本実施形態は、非常に効率的である。
【００３５】
本実施形態は、一意のラベルスタックを有する。マルチキャストが構築されている標準（ＲＦＣ  ４７６２）ＶＰＬＳラベルスタックは、図１Ａのように見える。本実施形態のラベルスタックは、図１Ｂに示されている。本実施形態とＶＰＬＳラベルスタックとの間の重要な差異は、ＶＰＬＳでは、異なるＶＬＡＮ上であるが同じテナントについて稼働している異なるホストからのマルチキャストパケットが異なるＶＬＡＮラベルを有する一方で、本実施形態は同じテナントについてのマルチキャストグループについて同じラベルを利用することである。本実施形態では、マルチキャストツリーラベルがテナントパケットのＩＰヘッダに隣接し、バックボーンメッシュラベルがスタックの最上位に存在する。１つの実施形態では、本ラベルスタックは標準的なＭＰＬＳ  ＶＰＮラベルスタックとの互換性を有しないことから、ここで説明されるＭＰＬＳマルチキャストは、サイトボーダールータ（構内機器（ＰＥ）又は顧客機器（ＣＥ）ルータ）において終端される。
【００３６】
クラウドシステムアーキテクチャ
図２は、この発明の１つの実施形態による、クラウドシステム内のコンポーネントを例示する。クラウドシステムは、クラウドネットワーク２７０を経由して連結される複数のラック２００Ａ〜２００Ｄ内に複数の仮想化されたサーバを含む。これら仮想化されたサーバ及びラックのうち、３つのラック２００Ａ、２００Ｂ、及び２００Ｃが例示されている。例示される各ラックは、ＴＯＲスイッチ（ＴＯＲＳ）と、複数の仮想化されたサーバとを含む。ラック２００Ａは、ＴＯＲＳ  ２０１Ａと、複数の仮想化されたサーバ２０５Ａ〜２０５Ｎとを含む。ラック２００Ｂは、ＴＯＲＳ  ２０１Ｂと、複数の仮想化されたサーバ２１５Ａ〜２１５Ｎとを含む。ラック２００Ｃは、ＴＯＲＳ  ２０１Ｃ、仮想化されたサーバ２２５Ａ、及び仮想化されたサーバ２２５Ｂを含む。各ＴＯＲＳ  ２００Ａ〜２００Ｃは、当該ラック内において複数の仮想化されたサーバを連結し、クラウドネットワーク２７０とさらに連結される。クラウドネットワーク２７０の構造は、任意のタイプのスイッチング又はルーティングプロトコル、例えば、光回路交換ネットワーク、又はＯｐｅｎＦｌｏｗ  ＭＰＬＳスイッチのネットワークをサポートすることができる。クラウドネットワーク２７０は、分散されたサーバラック間で稼働するワイドエリアネットワーク（ＷＡＮ）ですらあり得る。図における接続性は、限定ではなく例として提供されており、ここではネットワークファブリックとも称される、クラウドネットワーク２７０内においてＴＯＲＳを連結する多くの方式が存在する。
【００３７】
図２の例において、クラウドネットワーク２７０は、複数のスイッチング要素（例えばスイッチ又はルータ）２８０Ａ〜２８０Ｄを含む。各ＴＯＲＳ  ２００Ａ〜２００Ｃ、並びに仮想化された各サーバ２０５Ａ〜２０５Ｎ、２１５Ａ〜２１５Ｎ、２２５Ａ、及び２２５Ｂは、管理ネットワーク２７５とさらに連結されることが可能である。管理ネットワーク２７５は、ＴＯＲＳ及び仮想化されたサーバを管理要素と連結する。管理要素は、クラウド実行マネージャ２５０、仮想ディスク２５５、マルチキャストクラウドコントローラ（ＭＣＣ）２９０、及びクラウドネットワークマネージャ２６０を含む。
【００３８】
クラウド実行マネージャ（ＣＥＭ）２５０は、実行のためにＶＭをスケジューリングし、各ＶＭのイメージに対して永久ストレージを提供する仮想ディスク２５５内にＶＭをマッピングするための、及び、当該仮想ディスク２５５からＶＭをマッピング解除するための、オブジェクトマネージャを含む。クラウドネットワークマネージャ（ＣＮＭ）２６０は、テナントＶＰＣについてのＶＰＮを管理する。
【００３９】
ＭＣＣは、マルチキャストを実装するために、ＴＯＲＳ内においてフローテーブルエントリを構成し、マルチキャストを実装するのに必要とされるステートデータをトラッキングする。ＭＣＣは、各テナントについて、マルチキャストグループ管理テーブル（ＭＧＭＴ）を維持することができる。ＭＣＣは、テナント毎のベースで、ＭＡＣアドレスからテナントＩＤへのマッピング（１：１）、テナントＩＤからＭＡＣアドレスへのマッピング（ｌ：ｍ）、及び、全てのマルチキャストグループについての各テナントについてのＯｐｅｎＦｌｏｗグループＩＤをトラッキングすることもできる。ＭＣＣは、テナント毎に１つのＭＧＭＴを包含する。テナントは、各テナントについて一意であるテナントＩＤ（Ｔｉｄｎ）により識別される。ＶＰＣを作成するリクエストを新たなテナントが開始する際、ＭＣＣ内において、対応するエントリも作成される。ＭＧＭＴは、マルチキャストグループについてのレコードを包含する。各レコードは、以下の情報、即ち、グループのマルチキャストＩＰアドレス、マルチキャストグループ内に包含されるＶＭについてのＶＭレコードのセット、及び、グループについてのＭＰＬＳルーティングラベル、を包含する。
【００４０】
マルチキャストデータトラフィックは、テナント毎に分離されることが可能であり、ＭＣＣは、必要に応じてテナント毎に、マルチキャストアドレスについてのＯｐｅｎＦｌｏｗマルチキャストグループ識別子（ＩＤ）ＩＧ１．．．ＩＧｎを作成する。１つの実施形態において、ＯｐｅｎＦｌｏｗテーブル内のマルチキャストグループＩＤは、マルチキャストアドレス及びテナントＩＤの組み合わせである。マルチキャストグループは、テナントが仮想プライベートクラウド（ＶＰＣ）を要求する際に、ＯｐｅｎＦｌｏｗテーブル内で事前作成されることが可能であり、又は、最初の参加（join）動作が所与のマルチキャストアドレスについて受信される場合、実行時に生成されることが可能であるはずである。テナントがマルチキャストグループに参加するのに伴い、ＭＣＣにより維持されるデータ構造のセットに、エントリが構築（populate）される。これらデータ構造については、ここでは以下においてさらに論じる。
【００４１】
図３Ａ〜図３Ｃは、ＭＣＣにより維持されるデータ構造のうちのいくつかの１つの実施形態の図である。図３Ａは、テナントＩＤと、関連付けられるＭＡＣアドレスとの間の相関関係を記憶し、その一方で、各ＭＡＣアドレスが、１つのテナントＩＤに同様に相関付けされている、テナントトラッキング構造３２９を例示している。図３Ｂは、ＭＧＭＴトラッキングテーブル３０１が各テナントについて各ＭＧＭＴ  ３０３へのポインタを包含しており、ここでは、テナントがテナントＩＤ（Ｔｉｄｎ）により識別されることを例示している。ＭＧＭＴ  ３０３は、テナントＩＤ  ３０５を、マルチキャストＩＰアドレス（ＭＧｎ）３０７、マルチキャストグループについてのＭＰＬＳルーティングラベル（ＲＬＭＧｎ）３０９、及び、マルチキャストグループに加入しているテナントの各ＶＭについてのＶＭレコードのセット３１１、に相関付けするエントリを含む。
【００４２】
図３Ｃは、（例えば、ＶＭレコードのセット３１１内の）ＶＭレコード３２５が、ＶＭをサポートするＶＳ（ＶＳＶＭｎ）（ＶＳのＭＡＣ及びサーバＩＤを含む）へのポインタと、当該ＶＭが実行しているラックについてのＴＯＲＳ（ＴＯＲＳのＭＡＣを含む）へのポインタとを追加的に包含していることを例示する。図３Ａ〜図３Ｃのデータ構造の各々は、ＭＣＣによりＯｐｅｎＦｌｏｗコントローラにおいて維持されており、当該ＯｐｅｎＦｌｏｗコントローラは、クラウドシステム内の全てのマルチキャストについてのデータ構造を記憶するのに充分なワーキングメモリ又は同様のストレージデバイスを有する。
【００４３】
図４は、この発明の１つの実施形態による、ＭＰＬＳを使用してＶＭマイグレーション及びＶＭ通信をサポートするクラウドシステム内のコンポーネントの図である。図４は、１つ以上のフローエントリテーブル２１２Ａ〜２１２Ｚを含むＴＯＲＳ  ２０１Ａを示す。フローエントリテーブル２１２Ａ〜２１２Ｚは、ＯｐｅｎＦｌｏｗ仕様を参照して記載されるように、ＭＰＬＳラベルをＭＰＬＳアクションにマッチさせるために使用される。ＴＯＲＳ  ２０１Ａは、１つ以上の仮想化されたサーバ２１５Ａ〜２１５Ｎと連結される。
【００４４】
仮想化された各サーバ２１５Ａ〜２１５Ｎは、１つ以上のＶＭを実行するように構成される。図４において、仮想化されたサーバ２１５Ａは、ＶＭ（例えば、ＶＭ  Ｔｌ及びＶＭ  Ｔ２）の実行をスケジューリングするハイパーバイザ２１６Ａを含む。仮想化されたサーバ２１５Ａは、仮想スイッチ２１７Ａをさらに含む。仮想スイッチ２１７Ａは、ハイパーバイザ２１６Ａの制御下において実行するＶＭへの仮想ネットワークポートを提供する。仮想スイッチ２１７Ａは、ＯｐｅｎＦｌｏｗ仕様を参照して記載されるように、ＭＰＬＳラベルをＭＰＬＳアクションにマッチさせるために使用される１つ以上のフローエントリテーブル２１８Ａ〜２１８Ｚを含む、ＭＰＬＳ対応型スイッチである。
【００４５】
ＴＯＲＳ  ２０１Ａは、図２に記載されるクラウドネットワークといったクラウドネットワーク２７０と連結される。ＴＯＲＳ  ２０１Ａは、管理ネットワーク２７５とさらに連結される。図２におけるように、管理ネットワーク２７５は、ＴＯＲＳ及び仮想化されたサーバを、ＣＥＭ  ２５０、ＭＣＣ  ２９０、仮想ディスク２５５、及びＣＭＮ  ２６０といった管理要素と連結する。ＣＭＮ  ２６０は、アドレスマッピングテーブル２６２及びラベルマッピングテーブル２６４を含む、ＶＰＮを記述するテーブルを含む。アドレスマッピングテーブル２６２は、ＶＭのＭＡＣアドレス、ＶＭを稼働させている仮想化されたサーバのＭＡＣアドレス（これは、仮想スイッチ２１７ＡのＭＡＣアドレスである）、及びＶＭのＩＰアドレス間で、マッピングを行う。ラベルマッピングテーブル２６４は、仮想化されたサーバ２１５ＡのＭＡＣアドレス（これは、仮想スイッチ２１７ＡのＭＡＣアドレスである）を、仮想スイッチ２１７ＡとＴＯＲＳ  ２０１Ａとの間のリンクについてのＴＯＲＳリンクラベルにマッピングする。その他の実施形態において、ＣＮＭ  ２６０は、どのＤＨＣＰ（“Dynamic  Host  Configuration  Protocol”）及びＤＮＳ（“Domain  Name  Service”）サーバ（もしあれば）がどのテナントに属しているのかをトラッキングする。
【００４６】
１つの実施形態において、ＣＮＭは、テナントＶＭがそれらのＩＰスタックを構成することについて良好に振る舞い、テナントＶＭがそのＩＰ／ＭＡＣアドレスを任意に変更しないものと想定する。テナントＶＭの振る舞いが悪く、そうした変更を行う場合、そのパケットはＣＮＭへルーティングされ、ＣＮＭは、ＣＥＭに知らせるであろう。すると、ＣＥＭは、違反するＶＭをシャットダウンすることができる。
【００４７】
ＭＣＣ  ２９０は、ＭＧＭＴ  ３０３と、ＶＭレコード３２５と、ここで上において説明したように、マルチキャストトラフィックを管理するためのその他のデータ構造とを含む。ＭＣＣ  ２９０又はＣＮＭ  ２６０は、ＶＳ  ２１７Ａ内のフローテーブルエントリ２１８Ａを、インターネットグループマルチキャストプロトコル（ＩＧＭＰ）又はマルチキャストリスナ発見（ＭＬＤ）メッセージといった全てのマルチキャストレポーティングメッセージをＭＣＣ  ２９０へ転送するように構成することもできる。ＭＣＣ  ２９０又はＣＮＭ  ２６０は、フローエントリテーブル２１２Ａ又はＶＳ  ２１７Ａのフローエントリテーブル２１８Ａ内のフローエントリを作成又は除去して、ここで以下にさらに説明するように、マルチキャストグループについての参加動作を生じさせること、マルチキャストグループを退去すること、又はＶＭマイグレーションといった、クラウドシステム内でのマルチキャストの実装を管理することもできる。
【００４８】
１つの実施形態において、ＣＮＭ  ２６０、ＭＣＣ  ２９０、ＣＥＭ  ２５０、及び同様のコンポーネントを、ＯｐｅｎＦｌｏｗコントローラ４５０内に実装することが可能である。それにより、ＯｐｅｎＦｌｏｗコントローラ４５０は、クラウドシステムネットワークファブリックについての制御プレーンを実装することができる。従って、ＴＯＲＳ  ２０１Ａ及びＶＳ  ２１５Ａの管理は、フローテーブル２１２Ａ及び２１８内のフローテーブルエントリの構成により行われる。フローテーブルは、ＯｐｅｎＦｌｏｗ仕様において定義されるように、ＯｐｅｎＦｌｏｗフローテーブル更新メッセージの適用により維持される。
【００４９】
ＶＭのアクティブ化
図５は、この発明の１つの実施形態による、仮想マシンをアクティブ化するための方法のブロック図を例示する。ブロック５００において、ＣＮＭは、ＶＭが、仮想化されたサーバ上でアクティブ化のためにスケジューリングされているという通知を受信する。例えば、ＣＥＭはＣＮＭに対し、ＣＥＭがアクティブ化のためにＶＭをスケジューリングしたことを通知する。ＣＮＭは、ブロック５１０において、ＶＭのＭＡＣアドレスを判定する。１つの実施形態において、ＣＥＭはＣＮＭに対し、通知と共にＶＭのＭＡＣアドレスを提供し、その一方で、他の実施形態において、ＣＥＭはＣＮＭに対し、別々のメッセージ内でＶＭのＭＡＣアドレスを提供する。ブロック５１５において、ＣＮＭは、ＶＭがアクティブ化されるであろう仮想サーバ上に常駐する仮想スイッチに対応する、仮想スイッチのＭＡＣアドレスを判定する。ブロック５２０において、ＣＮＭは、ＣＮＭのアドレスマッピングテーブル内に、ＶＭのＭＡＣアドレスと仮想スイッチのＭＡＣアドレスとの間の関連付けを記録する。ＣＮＭは、ブロック５２５において、仮想スイッチを当該仮想スイッチと連結されるＴＯＲＳに関連付けるＭＰＬＳラベルをさらに判定する。ブロック５３０において、ＣＮＭは、ＭＰＬＳラベル及びＶＭのＭＡＣアドレスにマッチするデータパケットがＶＭへ転送されるべきであることを示すフローエントリ修正メッセージを仮想スイッチへ送信する。１つの実施形態において、ＣＮＭは、ブロック５３２において、ＶＭから発生するＤＨＣＰリクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを仮想スイッチへ送信する。他の実施形態において、ＣＮＭは、ブロック５３３において、ＶＭから発生するアドレス解決プロトコル（“ＡＲＰ”）リクエストがＣＮＭへ転送されるべきであることを示すフローエントリ修正メッセージを仮想スイッチへ送信する。
【００５０】
図６は、この発明の１つの実施形態による、仮想マシンをアクティブ化するための方法を例示する。図６において、ＴＯＲＳ  ２０１Ａは、仮想化されたサーバ２１５Ａと連結される。仮想化されたサーバ２１５Ａは、ハイパーバイザ２１６Ａ及び仮想スイッチ２１７Ａを含む。図６において、仮想化されたサーバ２１５Ａは、２つのアクティブなＶＭ  Ｔｌ  ４９０Ａ及びＶＭ  Ｔ２  ４９０Ｂを有する。さらに、図６は、ＣＥＭ  ２５０、仮想ディスク２５５、及びＣＮＭ  ２６０を示す。
【００５１】
図６において、ＣＥＭ  ２５０は、仮想化されたサーバ２１５Ａ上での実行のために、第３のＶＭ  Ｔ３  ４９０Ｃをスケジューリングする。この図は、仮想マシンのアクティブ化の期間中における様々なポイントを例示する。ポイントＡにおいて、ＣＥＭ  ２５０は、ＶＭ  Ｔ３  ４９０Ｃ、例えば、テナント１に属するＶＭを、実行のためにスケジューリングする。オブジェクトファイルは、仮想ディスク２５５からＣＥＭのオブジェクトマネージャを経由してマッピングされる。ＣＥＭは、テナント１に割り当てられたＭＡＣアドレスのうちの１つにＶＭ  ４９０Ｃの  ＭＡＣアドレスを設定するように、ＶＭ  ４９０Ｃのスタックを編集する。ポイントＢにおいて、ＣＥＭ  ２５０は、ＣＮＭ  ２６０にアクティブ化について知らせる。ＣＥＭ  ２５０はＣＮＭ  ２６０に対し、ＶＭ  ４９０ＣのＭＡＣアドレスと、ＶＭが実行している、仮想化されたサーバ２１５ＡのＭＡＣアドレス（これは、仮想化されたサーバ２１５Ａの仮想スイッチ２１７ＡのＭＡＣアドレスである）とを提供する。
【００５２】
ポイントＣにおいて、ＣＮＭ  ２６０は、ＣＮＭのアドレスマッピングテーブル（図示せず）内に、ＶＭ  ４９０ＣのＭＡＣアドレスを、ＶＭ  ４９０Ｃがスケジューリングされている、仮想化されたサーバ２１５ＡのＭＡＣアドレスと共に記録する。ポイントＤにおいて、ＣＮＭ  ２６０は、ＶＭ  ４９０Ｃが稼働している、仮想化されたサーバ２１５ＡとＴＯＲＳ  ２０１Ａとの間のリンクについての、仮想スイッチからＴＯＲＳ  ２０１ＡへのＭＰＬＳラベル（これは、ソースＴＯＲＳ“ＳＴＯＲＳ”リンクラベルとしても知られている）を、ＣＮＭ  ２６０のラベルマッピングテーブルからルックアップする。ポイントＥにおいて、ＣＮＭ  ２６０は、ＶＭ  ４９０Ｃの  ＭＡＣ及びＳＴＯＲＳリンクラベルを、当該ＳＴＯＲＳリンクラベルを外してパケットをＶＭ  ４９０Ｃへ転送するアクションにマッチさせるルールをインストールするフローエントリ修正メッセージを、ＭＰＬＳ対応型仮想スイッチ２１７Ａへ送信する。
【００５３】
１つの実施形態において、ＣＮＭ  ２６０は、ポイントＦにおいて、以下のルールをインストールする第２のフローエントリ修正メッセージを仮想スイッチ２１７Ａへ送信する。ソースＭＡＣがＶＭ  ４９０ＣについてのＭＡＣアドレスにマッチし、且つ、プロトコルがＡＲＰである場合、パケットをＣＮＭ  ２６０へルーティングして、ＣＮＭ  ２６０がＡＲＰリクエストにサービスすることを可能とする。このルールは、ＡＲＰトラフィックを削減し、ＣＮＭ  ２６０がＣＮＭアドレスマッピングテーブルから回答することを可能とする。
【００５４】
他の実施形態において、ＣＮＭ  ２６０は、ポイントＧにおいて、以下のルールをインストールする第３のフローエントリ修正メッセージを仮想スイッチ２１７Ａへ送信する。ソースＭＡＣがＶＭ  ４９０ＣについてのＭＡＣアドレスにマッチし、且つ、プロトコルがＤＨＣＰである場合、パケットをＣＮＭ  ２６０へルーティングして、ＣＮＭ  ２６０がＤＨＣＰリクエストにサービスすることを可能とする。このルールは、ＣＮＭ  ２６０が、ＤＨＣＰサーバからの応答パケットを傍受することにより、ＣＮＭアドレスマッピングテーブル内に、ＭＡＣアドレスからＩＰアドレスへのマッピングを記録することを可能とする。
【００５５】
図６は、これまでに記載された全ての３つのフローエントリ修正メッセージが通信されたものと想定する、仮想スイッチ２１７Ａのフローエントリテーブル２１８Ａ内の３つのエントリを例示する。フローエントリテーブル２１８Ａには、５つの列、即ち、ソースＭＡＣ、宛先ＭＡＣ、ＭＰＬＳラベル、ＩＰプロトコル、及びアクション、が例示されている。フローエントリは、４９０Ｃのアクティブ化に対応する。
【００５６】
例示されるフローエントリテーブル２１８Ａ内の第１のエントリは、ソースＭＡＣアドレスとしてＶＭ  Ｔ３  ４９０ＣのＭＡＣアドレスにマッチする。宛先ＭＡＣアドレス及びＭＰＬＳラベルは、任意のエントリにマッチするように設定され、その一方で、ＩＰプロトコルは、ＡＲＰプロトコルにマッチするように設定される。アクションは、次いで、ＣＮＭ  ２６０へ転送することである。このルールは、上記のステップＦに対応する。
【００５７】
例示されるフローエントリテーブル２１８Ａ内の第２のエントリは、ソースＭＡＣアドレスとしてＶＭ  Ｔ３  ４９０ＣのＭＡＣアドレスにマッチする。宛先ＭＡＣアドレス及びＭＰＬＳラベルは、任意のエントリにマッチするように設定され、その一方で、ＩＰプロトコルは、ＤＨＣＰプロトコルにマッチするように設定される。アクションは、次いで、ＣＮＭ  ２６０へ転送することである。このルールは、上記のステップＧに対応する。
【００５８】
例示されるフローエントリテーブル２１８Ａ内の第３のエントリは、ソースＭＡＣアドレスとしてアドレス指定された全てのＭＡＣにマッチする。宛先ＭＡＣアドレスは、ＶＭ  Ｔ３  ４９０ＣのＭＡＣアドレスにマッチするように設定され、その一方で、ＭＰＬＳラベルは、ＴＯＲＳ  ２０１ラベルに設定される。ＩＰプロトコルは、全てのエントリにマッチするように設定される。アクションは、次いで、ＭＰＬＳラベルを外してパケットをＶＭ  Ｔ３  ４９０Ｃへ転送することである。このルールは、上記のステップＥに対応する。
【００５９】
上で説明したように、ＣＮＭは、ＶＭ  ＭＡＣアドレス、仮想化されたサーバＭＡＣ、及びＶＭ  ＩＰアドレス間のマッピングを維持する。テナントがＤＨＣＰアドレスを使用しないことを選んだ場合、ＣＥＭは、スケジューリングの実行の前にＶＭのＩＰスタックを修正し、静的ＩＰアドレスをインストールする。しかしながら、その他の実施形態において、テナントは、ＤＨＣＰアドレスを使用することを選ぶであろう。そうしたケースにおいて、ＣＮＭは、“ＤＨＣＰリレーエージェント情報オプション”（ＩＥＴＦ  ＲＦＣ３０４６、２００１年１月）に従って、ＤＨＣＰリクエストを傍受してリレーとして働くであろう。
【００６０】
ＤＨＣＰリクエスト
図７は、この発明の１つの実施形態による、ＶＭからのＤＨＣＰリクエストを傍受するための方法のブロック図を例示する。ブロック７００において、ＣＮＭは、ＶＭから発生したＤＨＣＰリクエストを受信する。ＣＮＭは、ブロック７０５において、ＲＦＣ  ３０４６に従って、ＤＨＣＰリクエストをＤＨＣＰサーバへ中継する。ブロック７１０において、ＣＮＭは、ＤＨＣＰサーバからＤＨＣＰ応答を受信する。ブロック７１５において、ＣＮＭは、アドレスマッピングテーブル内に、ＶＭのＭＡＣアドレスとＤＨＣＰ応答内で受信されたＩＰアドレスとの間の関連付けを記録する。この発明の実施形態によると、当該関連付けは、ＶＭを実行する仮想サーバのＭＡＣアドレスをさらに含む。ブロック７２０において、ＣＮＭは、ＤＨＣＰ応答をＶＭへ転送する。
【００６１】
図８は、この発明の１つの実施形態による、仮想マシンからのＤＨＣＰリクエストを傍受するための方法を例示する。図８において、仮想化されたサーバ２１５Ａは、ハイパーバイザ２１６Ａ及び仮想スイッチ２１７Ａを含む。図８において、仮想化されたサーバ２１５Ａは、３つのアクティブなＶＭ  Ｔｌ  ４９０Ａ、ＶＭ  Ｔ２  ４９０Ｂ、及びＶＭ  Ｔ３  ４９０Ｃを有する。仮想スイッチ２１７Ａは、ＤＨＣＰリクエストを、ＶＭ  Ｔ３  ４９０Ｃから、ＤＨＣＰサーバ６３０と連結されるＣＮＭ  ６６０へ転送するルールを含むフローエントリテーブル２１８Ａを含む。
【００６２】
この図は、仮想マシンからのＤＨＣＰリクエストの傍受の期間中における、様々なポイントを例示する。ポイントＡにおいて、ＶＭ  Ｔ３  ４９０Ｃは、ＩＰアドレス、及び、ＤＮＳサーバといった、その他の構成情報を取得するＤＨＣＰリクエストを発行する。ポイントＢにおいて、仮想スイッチ２１７Ａは、ＤＨＣＰリクエストを、当該リクエストをＣＮＭ  ２６０へルーティングするフロールールにマッチさせる。ポイントＣにおいて、ＣＮＭ  ２６０は、ＤＨＣＰリレーとして働き、標準ＤＨＣＰリレーオプションを挿入し、リクエストをテナントのＤＨＣＰサーバ６３０へ転送する。ＣＮＭ  ２６０は、ＤＨＣＰリクエストのソースＭＡＣアドレスを調査することにより、どのテナントにＶＭ  Ｔ３  ４９０Ｃが属しているのかを判定することができる。ポイントＤにおいて、テナントのＤＨＣＰサーバ２３０は、ＶＭ  Ｔ３  ４９０ＣについてのＩＰアドレス及びその他の構成情報を包含するＤＨＣＰ応答を用いて応える。ポイントＥにおいて、ＣＮＭ  ２６０は、ＣＮＭのアドレスマッピングテーブル２６２内に、ＶＭ  Ｔ３  ４９０ＣのＭＡＣアドレスとＩＰアドレスとの間のマッピングを記録する。ポイントＦにおいて、ＣＮＭ  ２６０は、ＤＨＣＰリレーオプションを取り除き、ＤＨＣＰリプレイを仮想スイッチ２１７Ａへ転送し、仮想スイッチ２１７Ａは、ポイントＧにおいて、当該リクエストをＶＭ  Ｔ３  ４９０Ｃへ返送する。
【００６３】
典型的なＩＰ  ＬＡＮのシナリオにおいて、宛先アプリケーションと通信することを望む、サーバ内で稼働するソースアプリケーションは、ＤＮＳを使用して、宛先アプリケーションのＩＰアドレスを発見する。ＩＰアドレスが見つかった後に、ソースサーバ内のＩＰスタックは、宛先のＩＰアドレスとＭＡＣアドレスとの間のマッピングを発見するＡＲＰメッセージをブロードキャストする。宛先がローカルＬＡＮ上に存在する場合、宛先は、ＡＲＰに応答する。宛先がローカルＬＡＮ上で稼働していない場合、ソースサーバＩＰスタックは、ローカルルータのＭＡＣアドレスを、その他のサブネットへのゲートウェイとして使用する。
【００６４】
クラウド内において、ＶＭは、仮想化されたＬＡＮの最上位で稼働する。テナントは、それ自体のＤＮＳサーバを稼働させるか、又は、クラウド事業者からＤＮＳサービスを購入する。ＶＭは、当該ＶＭが使用することになるＤＮＳサーバのアドレスと共に構成される。テナントは、サービスにコンタクトすることを望む場合、ちょうど正規の法人ＬＡＮ内におけるように、ＩＰアドレスを発見するＤＮＳリクエストをＤＮＳサーバへ送信する。ＤＮＳサーバは、クラウド事業者の制御下にあるか、又は、個々のテナントにより制御されることが可能である。ＤＮＳ応答が返ってきた場合、ＶＭは、ＩＰからＭＡＣアドレスへのマッピングを判定するＡＲＰリクエストをブロードキャストする。
【００６５】
この発明の実施形態において、仮想スイッチは、ＡＲＰメッセージを傍受して、それをブロードキャストするよりもむしろ、ＣＮＭへ中継する。ＣＮＭは、ＡＲＰメッセージがクラウドネットワークの全体にわたってブロードキャストされる必要がないように、アドレスマッピングサービスを提供する。
【００６６】
ＡＲＰリクエスト
図９は、この発明の１つの実施形態による、ＶＭからのＡＲＰリクエストを傍受するための方法のブロック図を例示する。ブロック９００において、ＣＮＭは、ＶＭから発生したＡＲＰリクエストを受信する。ＣＮＭは、ブロック９０５において、ＡＲＰリクエストから宛先ＩＰアドレスを判定する。ブロック９１０において、ＣＮＭは、ＩＰアドレスに対応する、宛先ＶＭ  ＭＡＣアドレス及び宛先仮想スイッチＭＡＣアドレスを判定する。例えば、ＣＮＭは、ＡＲＰリクエスト内のＩＰアドレスに基づいて、ＣＮＭのアドレスマッピングテーブルからマッピングをルックアップすることができる。ブロック９１５において、ＣＮＭは、宛先仮想スイッチＭＡＣアドレスに対応する宛先ＭＰＬＳラベルを判定する。ブロック９２０において、ＣＮＭは、ソースＶＭを実行している仮想サーバ上の仮想スイッチへフローエントリ修正メッセージを送信する。エントリ修正メッセージは、宛先ＶＭ  ＭＡＣアドレスにマッチするパケットに、宛先ＭＰＬＳラベルが付与されて、当該パケットが、ソース仮想スイッチについてのＴＯＲＳへ転送されるべきであることを示す。ブロック９２５において、ＣＮＭは、宛先ＶＭ  ＭＡＣアドレスが宛先ＩＰアドレスに対応していることを示すＡＲＰ応答を生成する。
【００６７】
ＣＮＭは、ブロック９３０において、ＡＲＰ応答をソースＶＭへ転送する。
【００６８】
図１０は、この発明の１つの実施形態による、仮想マシンからのＡＲＰリクエストを傍受するための方法を例示する。図１０において、仮想化されたサーバ２１５Ａは、ハイパーバイザ２１６Ａ及び仮想スイッチ２１７Ａを含む。図８において、仮想化されたサーバ２１５Ａは、アクティブなＶＭ  Ｔ３  ４９０Ｃを有する。仮想スイッチ２１７Ａは、ＶＭ  Ｔ３  ４９０ＣからＣＮＭ  ２６０へＡＲＰリクエストを転送するルールを含むフローエントリテーブル２１８Ａを含む。仮想化されたサーバ２１６Ａは、ＴＯＲＳ  ２０１と連結され、ＴＯＲＳ  ２０１は、クラウドネットワーク２７０を経由して他のＴＯＲＳ  ２０１Ｃへ連結される。ＴＯＲＳ  ２０１Ｃは、ハイパーバイザ２２６Ｂ及び仮想スイッチ２２７Ｂを含む、仮想化されたサーバ２２５Ｂと連結される。仮想化されたサーバ２２５Ｂは、ＶＭ  Ｔ４  ２９５Ｂを実行している。
【００６９】
この図は、ＶＭ  Ｔ３  ４９０ＣからのＡＲＰリクエストの傍受の期間中における、様々なポイントを例示する。ポイントＡにおいて、ＶＭ  Ｔ３  ４９０Ｃは、ＡＲＰリクエストをブロードキャストする。傍受の残りの部分は、ＡＲＰリクエストが、仮想サーバ２２５Ｂ上に常駐する宛先ＶＭ  Ｔ４  ４９５ＢのＩＰアドレスを示すものと想定する。仮想スイッチ２１７Ａは、ポイントＢにおいて、ＡＲＰリクエストを傍受して、当該リクエストを、フローエントリテーブル２１８Ａ内における、ＡＲＰリクエストをＣＮＭ  ２６０へルーティングするルールにマッチさせる。
【００７０】
ポイントＣにおいて、ＣＮＭ  ２６０は、要求された宛先ＩＰアドレス（“ＤＩＰ”）をキーとして使用して、ＣＮＭのアドレスマッピングテーブル２６２内で宛先ＭＡＣアドレス（“ＤＭＡＣ”）をルックアップする。ＤＩＰが存在していない場合、その宛先は、クラウド内に存在せず、ＣＮＭは、ＡＲＰリクエストに応答しない。ＶＭは、次いで、提供されたローカルルータのＭＡＣアドレスを使用するであろう。ＤＩＰアドレスがＣＮＭのアドレスマッピングテーブル２６２内に存在する場合、ＣＮＭ  ２６０は、ＤＭＡＣ  ＶＭアドレス及びＤＭＡＣ仮想化されたサーバアドレスを取り出す。このケースにおいて、ＣＮＭは、ＶＭ  Ｔ４  ２９５ＢのＭＡＣをＤＭＡＣ  ＶＭアドレスとして、及び、仮想スイッチ２２７Ｂ  ＭＡＣをＤＭＡＣ仮想化されたサーバアドレスとして取り出すであろう。
【００７１】
ポイントＤにおいて、ＣＮＭは、宛先ＴＯＲＳ（“ＤＴＯＲＳ”）リンクラベルとしても知られる、ＣＮＭのラベルマッピングテーブル２６４からの、宛先ＴＯＲＳと、ＤＭＡＣ仮想化されたサーバアドレスとの間のリンクについてのＭＰＬＳフローラベルをルックアップする。このフローラベルは、ＴＯＲＳ  ２０１Ａと、ＤＭＡＣ仮想化されたサーバにおける仮想化されたサーバとの間のルートを記述する。このケースでは、ＴＯＲＳ  ２０１ＡからＴＯＲＳ  ２０１Ｃへのルートを示すために、ラベルＴＯＲＳ：ＶＳ  ２０１Ｃ：２２７Ｂ  ＬＬが取り出されるであろう。
【００７２】
ポイントＥにおいて、ＣＮＭ  ２６０は、仮想スイッチの２１７Ａのフローエントリテーブル２１８Ａ内にフロールートをインストールする。ルールは、ＶＭ  Ｔ４  ４９５ＢについてのＤＭＡＣ  ＶＭ  アドレスにマッチする。アクションは、ＶＭ  Ｔ３  ２９０ＣによりＶＭ  Ｔ４  ８９５Ｂへ送信されるトラフィックパケット上にＤＴＯＲＳリンクラベルＴＯＲＳ：ＶＳ  ２０１Ｃ：２２７Ｂ  ＬＬを付与し、次いで、当該パケットをＴＯＲＳ  ２０１Ａへ転送する。ポイントＦにおいて、ＣＮＭ  ２６０は、ＡＲＰ応答を仮想スイッチ２１７Ａに返し、仮想スイッチ２１７Ａは、当該応答をＶＭ  Ｔ３  ４９０Ｃへ転送する。
【００７３】
１つの実施形態において、ＣＮＭ  ２６０は、ＶＭへＡＲＰ応答を返す前に、ＴＯＲＳ−ＶＳルール及びアクションを、ＴＯＲＳ  ２０１のフローエントリテーブル（図示せず）内にインストールする。クラウドネットワーク２７０がＭＰＬＳネットワークである場合、ＡＲＰ応答が返されたときには、クラウドネットワーク２７０のスイッチファブリック内のＴＯＲＳ間のＬＳＰについてのルールはインストールされる必要がない。クラウドネットワーク２７０のスイッチが追加的にＯｐｅｎＦｌｏｗをサポートする場合、ＣＮＭ  ２６０は、新たなＴＯＲＳがインストールされるか、又は既存のＴＯＲＳがデコミッションされた時にＯｐｅｎＦｌｏｗを使用する、より高レベルのクラウドネットワーク２７０のスイッチ内に、ＭＰＬＳ転送ルールをインストールするだけでよい。しかしながら、より高レベルのデータセンタスイッチがＯｐｅｎＦｌｏｗをサポートしていない場合、ＴＯＲＳは、その代りにＬＤＰを使用して、それ自体とその他のＴＯＲＳとの間にＬＳＰをセットアップし、そうするとＬＳＰが構成されるはずである。クラウドネットワーク２７０のスイッチは、ＩＰルーティングプロトコルをサポートする必要も、ルーティングを実行する必要もない。
【００７４】
テーブル１は、この発明の実施形態による、宛先ＴＯＲＳへルーティング中のトラフィック、即ちアウトゴーイングトラフィック及びカレントラック内に宛先サーバがあるトラフィック、を扱うフローテーブルの一部について、ＴＯＲＳのＯｐｅｎＦｌｏｗフローテーブルのルール構造を例示する。インカミングトラフィックについてのルール構造については、後でさらに解説する。ラック内のソースＶＭにより宛先としてその時点で使用されている、各ＤＴＯＲＳ（宛先ＴＯＲＳ）−ＤＶＳ（宛先の仮想化されたサーバ）リンクラベルについて、テーブル内にフロールールが存在する。ＴＯＲＳは、ＶＭの移動時にインカミングトラフィックを捕捉するためのいくつかのフロールールを追加的にキャッシュし得る。ラック内のソースＶＭから来るトラフィックは、仮想スイッチにより付与されたＭＰＬＳ  ＤＴＯＲＳリンクラベルにマッチすることによりルーティングされ、当該ルールに関連付けられるアクションがアクティブ化されてパケットに適用される。アクションは、クラウドネットワークの性質に依存して異なる。
【００７５】
【表１】
0005927352.tif 000002
【００７６】
クラウドネットワークがＭＰＬＳネットワークではない場合、ＴＯＲＳは、ＯｐｅｎＦｌｏｗ仮想ポートを経由して、トラフィックをクラウドネットワークに適応させる。フローマッチングルール上のアクションに関連付けられる仮想ポートは、パケットを処理し、当該パケットをクラウドネットワーク内へルーティングするために必要な任意のヘッダを追加する。例えば、ネットワークが光回路交換ネットワークである場合、仮想ポートは、光クロスコネクトを経由してパケットをルーティングし得る。当業者は、その他のタイプのクラウドネットワークがその他の適応仮想ポートを利用することを理解するであろう。
【００７７】
しかしながら、クラウドネットワークがＭＰＬＳネットワークである場合、テーブル２に例示的なアクションが示されている。各アクションは、ＳＴＯＲＳからＤＴＯＲＳへのルーティングラベルを付与し、次いで、パケットをＯｐｅｎＦｌｏｗ  ＳＥＬＥＣＴグループへ送信する。ＳＥＬＥＣＴグループは、等コストマルチキャスト（ＥＣＭＰ）又は何らかのその他の負荷分散アルゴリズムを使用して、出力ポートバケットリストから１つの出力ポートバケットを選択し、パケットを出力ポートへ転送する。負荷分散は、輻輳を回避することを助け、２つのＴＯＲＳ間の全てのルートのマルチパス利用を促進にする。
【００７８】
【表２】
0005927352.tif 000003
【００７９】
パケットは、宛先ＴＯＲＳへ一旦到着すると、テーブル３及びテーブル４に示されるようなＯｐｅｎＦｌｏｗフローテーブルを経由してルーティングされる。パケットが宛先ＴＯＲＳにおいて“ＬＡＢＥＬ−Ｎ”のラベルを有するものと想定すると、ルールは、パケットがこのＴＯＲＳ宛てであることを示すＤＴＯＲＳルーティングラベル“ＬＡＢＥＬ−Ｎ”にマッチする。アクションは、ＤＴＯＲＳルーティングラベルを外し、処理のためにパケットをテーブル４へ送出する。テーブル４のルールは、パケットがどの仮想化されたサーバ宛てであるのかを示す、ラック内のサーバについてのＴＯＲＳ−ＶＳラベルにマッチする。アクションは、パケットを、当該仮想化されたサーバに到達するために適正なポートから転送する。
【００８０】
【表３】
0005927352.tif 000004
【００８１】
【表４】
0005927352.tif 000005
【００８２】
仮想スイッチ２２７Ｂにおいて、ＶＭ  Ｔ４  ２２７Ｂの  ＭＡＣアドレス及びＶＳ−ＴＯＲＳルーティングラベルにマッチするルールがトリガされる。ＶＳ−ＴＯＲＳルーティングラベルは外されて、パケットは、ＶＭ  Ｔ４  ４２７Ｂへ転送される。
【００８３】
クラウドネットワーキングの最も困難な局面のうちの１つは、ＶＭの、第１の仮想化されたサーバから第２の仮想化されたサーバへの移動を扱うことである。ＣＥＭは、ＶＭを１つのサーバから他のサーバへといつでも移動させることができる。移動は、サーバ利用率を最適化するため、電力消費若しくは発熱を低減するため、又は、データベースといった外部リソースへのアクセスに、ＶＭをより接近させて位置付けるために、行われ得る。そうした移動が生じる場合、古いサーバにおけるＶＭへのルートは、もはや有効ではない。ＶＭを移動させている間の“転送中（in  flight）”のパケットは、破棄される恐れがあり、新たなパケットは、ルートを整備する方策が取られない限り、ＶＭの新たなロケーションへ到達しないかもしれない。
【００８４】
基本的なＶＭマイグレーション
図１１は、クラウドコンピューティングネットワーク内において第１の仮想化されたサーバから第２の仮想化されたサーバへとＶＭを移動させる方法を例示する。図１１において、第１の仮想化されたサーバ２１５Ａ（古い仮想化されたサーバとも称される）は、クラウドネットワーク２７０へ連結されるＴＯＲＳ  ２０１Ａと連結される。クラウドネットワーク２７０は、ＴＯＲＳ  ２０１Ａを他のＴＯＲＳ  ２０１Ｃと連結し、ＴＯＲＳ  ２０１Ｃは、第２の仮想化されたサーバ２２５Ａ（新たな仮想化されたサーバとも称される）へ連結される。
【００８５】
各仮想化されたサーバ２１５Ａ及び２２５Ａは、複数のＶＭを稼働させ、対応するハイパーバイザ２１６Ａ及び２２６Ａ、並びにＭＰＬＳ対応型仮想スイッチ２１７Ａ及び２２７Ａを含む、ように構成される。各仮想スイッチ２１７Ａ及び２２７Ａは、対応する仮想スイッチが、それ自体が受信するパケットをいかに処理すべきかを示すＭＰＬＳルールを含むフローエントリテーブル２１８Ａ及び２２８Ａを含む。ＶＭの移動のために使用される固有のエントリについて、以下に詳細に論じる。図９の例示に先立ち、古い仮想化されたサーバ９１５Ａは、３つのアクティブなＶＭ、即ち、ＶＭ  Ｔｌ  ４９０Ａ、ＶＭ  Ｔ２  ４９０Ｂ、及びＶＭ  Ｔ３  ４９０Ｃを有する。図９は、管理ネットワーク９７５を経由してＣＮＭ  ２６０と連結されるＣＥＭ  ２５０をさらに例示する。管理ネットワークは、ＣＥＭ  ２５０及びＣＮＭ  ２６０をＴＯＲＳ  ２１５Ａ及び２２５Ａとさらに連結し、それにより、仮想化されたサーバ２１５Ａ及び２２５Ａへの通信パスを提供する。
【００８６】
この図は、古い仮想化されたサーバ２１５Ａから新たな仮想化されたサーバ２２５Ａへの、ＶＭ  Ｔ３  ４９０Ｃの移動期間中における様々なポイントを例示する。古い仮想化されたサーバ及び新たな仮想化されたサーバという用語は、移動の前にＶＭ  Ｔ３  ４９０Ｃが古い仮想化されたサーバにおいてアクティブであったこと、及び、移動の後にＶＭ  Ｔ３  ４９０Ｃが新たな仮想化されたサーバ２２５Ａにおいてアクティブになるであろうことを反映している。
【００８７】
ポイントＡにおいて、ＣＥＭ  ２５０は、古い仮想化されたサーバ２１５Ａから新たな仮想化されたサーバ２２５ＡへのＶＭ  Ｔ３  ４９０Ｃの移動を開始させ移動を開始させる。ポイントＡは、９  Ｔ３  ４９０Ｃの移動が開始されていることを示すメッセージがＣＥＭ  ２５０から古い仮想化されたサーバ２１５Ａへ送信されていることを示す。ＶＭ  Ｔ３  ４９０Ｃが古い仮想化されたサーバ２１５Ａ上においてアクティブである限り、ＶＭ  Ｔ３  ４９０Ｃは、トラフィックに引き続きサービスすることができ、フローエントリテーブル２１８Ａ内では古いフロールールが維持される。ハイパーバイザ２１６Ａは、ＶＭ  Ｔ３  ２９０Ｃのステート情報を保存すること、及び、ＶＭ  Ｔ３  ２９０Ｃが待機ステート又は非アクティブステートに入るように仕向けることにより、ＶＭ  Ｔ３  ４９０Ｃが新たな仮想化されたサーバ２２５Ａへ移行することを準備する。ポイントＢにおいて、ＶＭ  Ｔ３  ４９０Ｃのステート情報は、古い仮想化されたサーバ２１５Ａから新たな仮想化されたサーバ２２５Ａへ移行される。
【００８８】
ＶＭ  Ｔ３  ４９０Ｃの非アクティブ化の期間中における何らかのポイント、ポイントＣにおいて、ＣＥＭ４５０は、ＶＭ  Ｔ３  ４９０Ｃがトラフィックにもはやサービスできないことを決定する。この時、ＣＥＭ  ２５０はＣＮＭ  ２６０に対し、ＶＭ  Ｔ３  ４９０Ｃが移動されているが故にその時点でトラフィックにサービスできないことを通知する。このメッセージに反応して、ＣＮＭ  ２６０は、仮想スイッチ２１７Ａのフローエントリテーブル２１８Ａ内のルールを修正する。よって、ポイントＤにおいて、ＣＮＭ  ２６０は、宛先ＭＡＣとしてのＶＭ  Ｔ３  ４９０ＣのＭＡＣアドレスを、仮想化されたサーバ２１５ＡをＴＯＲＳ  ２０１ＡとリンクするＭＰＬＳラベルにマッチさせるトラフィックが、ＣＮＭ  ２６０へ（又は何らかのその他のエンティティへ）転送されるべきであることを示すルールをフローエントリテーブル２１８Ａ内にインストールする。ＣＮＭ  ２６０、又は任意選択として何らかのその他のエンティティは、ＶＭ  Ｔ３  ４９０Ｃへ向けての古い仮想化されたサーバ２１５Ａへ方向付けられたトラフィックをいかに扱うべきかを、知能部（intelligence）へ提供するであろう。
【００８９】
１つの実施形態において、ＣＮＭ  ２６０、又は、この目的のために設計された何らかのその他のエンティティは、移行ピリオドの期間中にＶＭ  Ｔ３  ４９０Ｃ向けのパケットを記憶するために使用されるパケットバッファ１１６６を含む。このようにして、パケットバッファ１１６６内の、ＶＭ  Ｔ３  ４９０向けのパケットは、ＶＭ  Ｔ３  ４９０が新たな仮想化されたサーバ２２５Ａにおいて一旦アクティブになると、ＶＭ  Ｔ３  ４９０へ送信されることが可能である。
【００９０】
１つの実施形態において、ＶＭ  Ｔ３  ４９０が、新たな仮想化されたサーバ２２５Ａにおいてデータにサービスする準備が整うと、ＣＥＭ  ２５０はＣＮＭ  ２６０に対し、ポイントＥにおいて、ＶＭ  Ｔ３  ４９０が再度アクティブになったことを通知する。他の実施形態において、ＣＮＭ  ２６０は、ＶＭ  Ｔ３  ４９０が再度アクティブ化された後にＶＭ  Ｔ３  ４９０から発生した（ＡＲＰリクエストなどの）パケットを当該ＣＮＭ  ２６０が受信したが故に、ＶＭ  Ｔ３  ４９０がアクティブになっていることを検出することができる。ＣＮＭ  ２６０は、フローエントリテーブル２２８Ａを修正することにより、ＶＭ  Ｔ３  ４９０がデータにサービスする準備が整っていることに反応する。
【００９１】
ポイントＦにおいて、ＣＮＭ  ２６０は、１つ以上のエントリをフローエントリテーブル２２８Ａに追加する。ＣＮＭ  ９６０は、宛先ＭＡＣとしてのＶＭ  Ｔ３  ４９０ＣのＭＡＣアドレスにマッチするのと共に、仮想化されたサーバ２２５ＡをＴＯＲＳ  ２０１ＣとリンクするＭＰＬＳラベルにマッチするフロールールを、フローエントリテーブル２２８Ａに追加する。このルールは、仮想スイッチ２２７Ａに対し、マッチするパケットにおいてＭＰＬＳラベルが外されるべきであり、且つ、当該マッチするパケットがＶＭ  Ｔ３  ４９０Ｃへ転送されるべきであることを知らせる。この発明のその他の実施形態は、追加的なルールをサポートする。例えば、１つの実施形態は、ＶＭ  Ｔ３  ４９０Ｃから発生するＤＨＣＰパケットが、ＣＮＭ  ２６０へ転送されるべきであることを示すルールを追加する。他の実施形態は、ＶＭ  Ｔ３  ４９０Ｃから発生するＡＲＰリクエストが、ＣＮＭ  ２６０へ転送されるべきであることを示すルールを追加する。
【００９２】
ポイントＧにおいて、ＣＮＭ  ２６０（又は、古い仮想化されたサーバから新たな仮想化されたサーバへのＶＭの移行期間中にパケットをバッファリングするように設計された何らかのその他のエンティティ）は、ＶＭ  Ｔ３  ４９０Ｃ宛ての累積されたパケットを、仮想化されたサーバ２２５Ａへ転送し、それにより、それらパケットはＶＭ  Ｔ３  ４９０Ｃへデリバリされ得る。
【００９３】
ポイントＧにおいて、ＣＮＭ  ２６０は、ＶＭ  Ｔ３  ４９０Ｃについての仮想化されたサーバＭＡＣアドレスエントリを、新たな仮想化された宛先サーバ２２５ＡのＭＡＣアドレスに変更するように、ＣＮＭ  ２６０のアドレスマッピングテーブル２６２のテーブルを修正する。これら変更の後に、図９に従った、ＶＭ  Ｔ３  ４９０Ｃについての任意の新たなＡＲＰリクエストは、ソース仮想スイッチにおいて、トラフィックが２２５Ａへルーティングされるべきであることを示すフローエントリを結果的に生じるであろう。
【００９４】
１つの実施形態において、ＣＮＭ  ２６０は、ＶＭ  Ｔ３  ４９０Ｃとの間でトラフィックを依然として交換しているかもしれない任意のピアＶＭのために、古い仮想化されたサーバ２１５Ａの仮想スイッチ２１７Ａ上の所定の位置にフロールールを保持しており、なぜなら、それらピアＶＭは古い仮想化されたサーバ２１５Ａ上でＶＭ  Ｔ３  ４９０Ｃがアクティブであることを依然として期待し得るためである。そうしたピアＶＭがピアデータパケットをＶＭ  Ｔ３  ４９０Ｃへ送信することになる場合、当該ピアデータパケットは、ポイントＤにおいてインストールされたルールに従って、ＣＮＭ  ２６０へ転送されるであろう。ＣＮＭ  ２６０は、次いで、ピアＶＭの仮想化されたサーバ上におけるフロールールを、パケット上のＭＡＣ及びＩＰアドレスを使用してＶＭ  Ｔ３  ４９０Ｃの位置を特定することで、新たな仮想化されたサーバ２２５Ａ上のＶＭ  Ｔ３  ４９０Ｃへトラフィックを転送するように修正する。ＣＮＭ  ２６０は、ピアデータパケットを、新たな仮想化されたサーバ２２５Ａ上のＶＭ  Ｔ３  ４９０Ｃへ転送する。このようにして、全てのフロールールは、最終的にタイムアウトになるか、又は、新たな仮想化されたサーバ２２５Ａ上のＶＭ  Ｔ３  ４９０Ｃへトラフィックを送信するように修正されるか、のいずれかである。ＣＮＭは、ソース仮想スイッチフロールールが、事前に定義されたグレースピリオドの後にタイムアウトになることを可能とすることができる。
【００９５】
クラウドシステム内のマルチキャストグループメンバーシップを管理すること−概観
図１２は、クラウドシステム内のマルチキャストグループに仮想マシンが参加する処理の１つの実施形態のフローチャートである。１つの実施形態において、処理は、ＯｐｅｎＦｌｏｗコントローラにおけるＭＣＣにより実装される。処理は、ブロック１２０１において、ＭＣＣにおいて受信される、ＩＧＭＰ又はＭＬＤレポートメッセージといったマルチキャスト参加メッセージに応答して開始されることが可能である。例えば、ＶＭは、ＩＧＭＰレポートメッセージをＩＰｖ４を介して発行することにより、又は、ＭＬＤレポートメッセージをＩＰｖ６を介して発行することにより、マルチキャストグループに参加することができる。これら参加メッセージは、ＶＭのソースアドレスだけではなくマルチキャストグループアドレスも含む。１つの実施形態において、ＣＮＭ、又はクラウドシステムの同様のコンポーネントのスタートアップの期間中に、各ＶＳのフローテーブルは、全てのＩＧＭＰ又はＭＬＤメッセージを検出し、且つ、処理されるためにそれらをＭＣＣへ転送する、エントリを含むように構成される。
【００９６】
ＭＣＣは、テナント毎のベースで少なくとも１つのＶＭが加入している各マルチキャストグループをトラッキングするマルチキャストグループ管理テーブル（ＭＧＭＴ）を維持する。ＭＧＭＴについては、ここでは以下においてさらに詳細に説明する。ＶＭ参加メッセージが受信されると、ブロック１２０３において、ＶＭは、当該参加メッセージ内で特定されたマルチキャストグループに加入している、テナントについてのＶＭのセットに追加される。
【００９７】
ここで上において説明したように、ＭＣＣは、各テナントに関連付けられるＶＭのセットだけではなく、各ＶＭについての、関連付けられるＶＳ及びＴＯＲＳもトラッキングすることができる。参加メッセージが受信され、ＶＭがＭＧＭＴに追加された場合、ブロック１２０５において、これらデータ構造を使用するルックアップが実行されて、参加メッセージを送信するＶＭのＶＳ及びＴＯＲＳを判定することができる。ＶＳ及びＴＯＲＳ情報は、次いで、各々のフローテーブルエントリを構成するために利用される。ＶＳは、ブロック１２０７において、（ＶＭを基準とした）アウトバウンドマルチキャストトラフィックを、ＶＭのＴＯＲＳを介して、マルチキャストグループに加入しているＶＭを有するＴＯＲＳのセットへ転送するように構成される。ブロック１２０９において、ＶＳは、ＴＯＲＳから受信されるＶＭから発生したマルチキャストグループトラフィックを破棄するようにも構成されることが可能であり、その理由は、そのマルチキャストデータがループバックしていて、従って廃棄され得るからである。ＴＯＲＳのフローテーブルエントリは、シーケンシャルに、又は、ＶＳのフローテーブルエントリと並行して、更新されることが可能である。ＴＯＲＳフローテーブルエントリは、ブロック１２１１において、ＭＰＬＳを使用して、アウトバウンドマルチキャストトラフィックを、加入ＶＭのＴＯＲＳへ転送するように、及び、インカミングマルチキャストトラフィックを、ラック内の、マルチキャストグループに加入しているＶＭのＶＳへ転送するように、更新される。処理の１つの実施形態については、ここでは以下においてさらに詳細に説明する。
【００９８】
ＶＭがマルチキャストグループを退去する場合、ＶＭにより同様に退去メッセージが送信され、ＶＳにおいて傍受される。傍受された退去メッセージは、ＭＣＣへ転送される。ＭＣＣは、退去メッセージ内において識別されたマルチキャストグループに加入しているＶＭのセットから、当該ＶＭを除去するようにＭＧＭＴを更新する。ＶＳフローテーブルは、次いで、マルチキャストトラフィックを受信するＶＭのセットから当該ＶＭを除去するように更新され、同様にＴＯＲＳは、当該ＶＭが、マルチキャストグループに加入している、ＶＳに関連付けられる最後のＶＭである場合、当該ＶＭのＶＳを除去するように更新され得る。また、クラウドシステム内の各ＴＯＲＳは、当該ＶＭが、マルチキャストグループに加入している、ＴＯＲＳに関連付けられる最後のＶＭであった場合、マルチキャストグループについての転送から、当該ＶＭのＴＯＲＳを除去するように更新されることが可能である。
【００９９】
マルチキャストグループに参加すること−仮想スイッチ構成
図１３は、ＶＭがマルチキャストグループに参加するための、及び、ＶＭの仮想スイッチを構成するための、処理の１つの実施形態のフローチャートである。１つの実施形態において、参加する処理は、ブロック１３０１において、ＭＣＣがＶＭからレポートメッセージを受信すると開始される。上述のように、ＣＮＭ又は同様のコンポーネントは、各ＶＳを、ＩＧＭＰレポートメッセージ及びＭＬＤレポートメッセージを傍受し、処理されるためにそれらをＭＣＣへ転送する、ように構成する。ＩＧＭＰレポートメッセージ又はＭＬＤレポートメッセージは、ソースアドレスとしてＶＭ  ＭＡＣアドレスを含む。ブロック１３０３において、ＭＣＣは、ここにおいて上で説明したデータ構造、例えばテナントテーブルを使用して、ＶＭのＭＡＣアドレスに対するルックアップを実行して、ＶＭについてのテナントＩＤを判定する。ＭＣＣは、次いで、ブロック１３０５において、テナントｉｄを用いてＭＣＣテーブル内における第２のルックアップを実行して、対応するＭＧＭＴエントリをフェッチするポインタを取得する。
【０１００】
ＶＭレコードが存在していない場合、ＭＣＣは、ブロック１３０７において、ＶＭに関連付けられるＶＳ及びＴＯＲＳのＶＳレコード及びＴＯＲＳレコードへのポインタを含むＶＭレコードを構築する。ブロック１３０９において、ＩＧＭＰ又はＭＬＤレポートメッセージにより識別されるマルチキャストグループのＭＧＭＴエントリ内に、ＶＭレコード、又はＶＭレコードへのポインタが挿入される。各マルチキャストグループについてのＭＧＭＴエントリは、マルチキャストソーススタートアップにおいて、ＭＣＣスタートアップにおいて、又は同様の時に、グループに参加するための最初のリクエストに応答して作成されることが可能である。ＭＧＭＴエントリは、各マルチキャストグループについて利用されるべきＭＰＬＳラベルを含む。ブロック１３１１において、ＭＣＣは、ＶＭに関連付けられるＶＳ及びＴＯＲＳのフローテーブルをプログラミングする際に使用するための、マルチキャストグループについてのＭＰＬＳラベルを取り出す。
【０１０１】
新たに加入したＶＭが、当該テナントについてのマルチキャストグループに加入する、ＶＳに関連付けられる最初のＶＭである場合、ＭＣＣは、ＶＳのフローテーブル内に、以下のフローテーブルエントリをセットアップする：
ブロック１３１５において、受信されたパケットのＭＰＬＳラベルがＭＰＬＳマルチキャストルーティングラベルにマッチする場合、当該ラベルを外し（pop）、パケットを、入力、例えばＩＧｎをハンドリングするＯｐｅｎＦｌｏｗグループにコピーする。
【０１０２】
ＯｐｅｎＦｌｏｗグループテーブルは、追加的な転送方法（例えば、ｓｅｌｅｃｔ及びａｌｌ）をＯｐｅｎＦｌｏｗが表現することを可能にする。各グループエントリは、そのグループ識別子により識別され、アクションバケットの順番付きリストを有する。各バケットは、実行すべきアクションと、関連付けられるパラメータとのリストを包含する。ＩＧｎは、新たなマルチキャストグループがテナントについて追加された場合に作成される入力グループである。ＩＧｎは、パケットがＴＯＲＳからＭＰＬＳラベルを有して来る場合に当該パケットが転送される必要がある、全てのＶＭのリストを包含する。
【０１０３】
ＩＧのタイプはＡＬＬであり、このことは、パケットが複製されてグループ内の各バケットへ送信されることを結果的に生じる。ＶＭがマルチキャストグループに追加されるのに伴い、ＩＧｎは、新たに加入したＶＭへのルートを包含するようにインクリメンタルに修正される。新たなテナントリクエストがコントローラに来る場合、マルチキャストグループごとに仮想スイッチ内でＩＧｎが作成される。
【０１０４】
上記の構成に加えて、特定のテナントについての任意の新たに加入したＶＭについて、ＭＣＣは、以下のフローエントリ及び修正をＩＧに追加することにより、ＶＳのフローテーブルを修正する：
受信されたパケットの宛先ＩＰアドレスが、テナントＶＭのアドレスが存在するマルチキャストグループアドレス（ＤＩＰＭＧ１）入力ポートにマッチする場合、ＭＰＬＳマルチキャストルーティングラベル（ＭＬＭＧ１）を付与（push）し、出力（ＯＧ１）をハンドリングするＯｐｅｎＦｌｏｗグループにパケットをコピーする。ＯＧ１は、テナントがマルチキャストグループに参加するのに伴い、サーバ上の各テナントについて作成され、且つ、エントリが構築されるグループである。
ソースアドレスが、新たに加入したＶＭのソースアドレス（ＳＩＰＶＭ１）にマッチし、且つ、パケットがＴＯＲＳポート（ＰＴＯＲＳ１）上に入来（incoming）している場合、パケットを破棄する。このルールの目的は、ルーティングループを防止することであり、このルールの目的については、次のセクションでより詳細に解説する。
ＩＧ１内に、パケットをＤＩＰＶＭ１へ転送する転送アクションを追加する。
【０１０５】
ＶＳのフローテーブルについて定義された入力グループＩＧ及び出力グループＯＧの構築に関し。ＯＧのタイプはＡＬＬである。よって、パケットは、複製されて、グループ内の各バケットへ送信される。ＯＧのバケットは、以下のルートを包含する：即ち、１つのバケットが、ＴＯＲＳに至る出力ポートからパケットを転送する；複数のバケットのうちの残りのバケットが、ＶＭ１を除き、マルチキャストグループのメンバーであるサーバ上のその他のＶＭへパケットを送信する。ＩＧグループのタイプもまた、ＡＬＬである。ＩＧグループは、ＴＯＲＳからの、ＭＰＬＳラベルを有するインカミングパケットについての場合に使用される。ＭＰＬＳラベルは外され、パケットは、ＩＧの全てのメンバーＶＭへ送信される。
【０１０６】
ＭＣＣは、ＯＧ１を構築するために、マルチキャストグループ内のＶＭのリストを利用し、ＶＭの当該リストをサーチしてどのＶＭがＶＭ１と同じＶＳを有しているかを判定することにより、どのＶＭがＶＭ１と同じＶＳ上に存在しているかを判定する。ＩＧ１は、インクリメンタルに構築される。ＶＳ上のＶＭがマルチキャストグループに加入するのに伴い、転送アクションがＩＧ１に追加される。
【０１０７】
図１４は、仮想スイッチの例示的なフローテーブルの１つの実施形態の図である。ＶＳ  １４０１は、クラウドシステム内のＶＭ  １４０５のセットについて、ユニキャスト及びマルチキャストデータトラフィックをハンドリングすることができる。ＶＭ  １４０５及びＶＳは、ここで上においてさらに説明したように、サーバがハイパーバイザ又は同様のシステムを実行することにより、ホスティング又は実行されることが可能である。ＶＭ  １４０５への、及びＶＭ  １４０５からの全てのデータトラフィックは、ＶＳ  １４０１を通過するが、その理由は、ＶＳ  １４０１が、クラウドシステムにわたるＶＭ  １４０５の移動を可能にする、ＶＭ  １４０５のネットワーク通信ポートの抽象化／仮想化として働くためである。
【０１０８】
ＶＳ  １４０１のフローテーブル１４０３は、ルール及びアクションへと各々が分割されるフローテーブルエントリのセットを含む。ルールは、アクションが実行される条件を定義する。複数個のアクションが行われる必要のあるシナリオでは、ＯＧ  １４０７及びＩＧ  １４０９といったアクショングループを定義することが可能である。これらグループは、ルール及びグループの構成に依存して、グループ内のアクションの任意の組み合わせが行われ得るように構成されることが可能であり、さらに特定の基準によってグループ内のアクション群の実行が有効化され得る。
【０１０９】
図１４の例示的な実施形態において、フローテーブルは、例示的なルール及びアクションのセットと共に構成されている。第１のフローテーブルにおいて、エントリは、ＶＳに関連付けられるＶＭから発生するアウトバウンドマルチキャストトラフィックを管理する。当該フローテーブルエントリは、ローカルＶＭからのソースＩＰアドレスと、マルチキャストグループに関連付けられる宛先ＩＰアドレスとを有するパケットを探す。マッチが見つかった場合、アクションは、マルチキャストグループのＭＰＬＳラベルをパケット上にカプセル化又は“付与する”ことと、次いで、ＶＳに関連付けられるＴＯＲＳ及びその他の加入ＶＭへパケットを転送することを含めた、行われるべき追加のアクションを定義するアウトバウンドグループＯＧへ、カプセル化されたパケットを転送することとを含む。
【０１１０】
次のフローテーブルエントリは、マルチキャストグループについてマッチするＭＰＬＳラベルを探すこと、次いで、アクションとしてラベルを除去することにより、インカミングパケットを管理する。逆カプセル化されたパケットは、次いで、ＶＳに関連付けられるローカル加入ＶＭへ転送される。最後のフローテーブルエントリは、ソースＩＰ及びＴＯＲＳポートのマッチを探し、そうしたパケットはＴＯＲＳからＶＳへループバックされるパケットであるため、そうしたパケットを廃棄する破棄アクションを定義する。ノードがマルチキャストを受信することを望むはずの場合にのみ、ＩＧＭＰレポートが発行される。あるアドレスでマルチキャストをまさに行うノードは、ＩＧＭＰレポートメッセージを発行しない。従って、複数のマルチキャストアドレスをコントローラへ転送することにより、あるマルチキャストアドレスについて“参加（joining）”が推測される。コントローラは、次いで、ＩＧＭＰレポートメッセージが受信された場合にフローがインストールされる要領とちょうど同じように、フローをインストールしなければならない。
【０１１１】
マルチキャストグループに参加すること−ＴＯＲスイッチルート
図１５は、参加処理についてＴＯＲＳを構成するための処理の１つの実施形態の図である。ＶＳルートがインストールされた後、又はインストールと並列して、ＭＣＣは、ＴＯＲＳ内へのマルチキャストグループについてのフロールートのインストールを、それらルートが既にインストールされていない場合、即ち、ＶＭに関連付けられるＴＯＲＳ内及びクラウドシステム内のその他のＴＯＲＳ内の双方に既にインストールされていない場合に、行う。同じサーバ又はＶＳ上の他のＶＭが、マルチキャストグループに既に加入している場合、当該ＴＯＲＳには追加的なＴＯＲＳルートが必要ではなく、このチェックは、ブロック１５０１において、クラウドシステム内の各ＴＯＲＳに対して行われるか、又は、参加メッセージを発行したＶＭに関連付けられるＴＯＲＳに対してのみ行われる。
【０１１２】
アウトゴーイングパケットに関し、ＭＣＣは、ＴＯＲＳ上において、マルチキャストグループ向けのＭＰＬＳラベル（即ち、ＭＬＭＧ１）を有するパケットにそのルールがマッチする、第１のテーブル内のフロールートをインストールする。アクションは、パケットを複製し、当該複製をＴＯＲＳ出力グループ（ＴＯＧ１）へ送信する。ＴＯＧ１内の各アクションバケットは、以下のアクションを包含する：
ブロック１５０３において、宛先ＴＯＲＳ（ＤＴＯＲＳｎ）に対応するバックボーンルーティングラベル（ＢＲＬｎ）をパケット上に付与する。
ブロック１５０５において、ＤＴＯＲＳｎに至る出力ポートからパケットを転送する。
【０１１３】
ＤＴＯＲＳｎについてのアクションバケットが既に存在している場合、ＭＣＣは、新たなフロールールを何ら書き込む必要がない。ＭＣＣは、ＶＭのリストを調べること、及び、パケットをマルチキャストグループ内のＶＭへルーティングするＴＯＲＳのセットを抽出することにより、どのＤＴＯＲＳがパケットを受信するのかを判定する。ラック内の最初のＶＭがマルチキャストグループに最初に参加する場合、この手続のみが行われる必要がある旨に留意されたい。その後、次の段落で説明するように、その他のラック上の、その他の最初に参加するＶＭがマルチキャストグループに新たに参加するのに伴い、ＴＯＧはインクリメンタルに更新される。
【０１１４】
ＶＭが、マルチキャストグループに参加する、ラック上の最初のＶＭである場合、ＭＣＣは、ブロック１５０７において、マルチキャストグループのメンバーであるＶＭを有するラックにサービスする全てのその他のＴＯＲＳ内に、新たな加入ＶＭのＴＯＲＳへのルートもインストールしなければならない。この手続は、ソースＴＯＲＳによりサービスされるラック上の最初のＶＭがマルチキャストグループに最初に参加する場合、一度のみ必要となるはずである。ＭＣＣは、マルチキャストグループ内のＶＭのリストをサーチすること、及び、グループ内のＶＭにサービスするＴＯＲＳのリストを抽出することにより、どのＴＯＲＳがルートを必要としているのかを判定する。次いで、ＭＣＣは、リスト内の各ＴＯＲＳのＴＯＧ内に、パケットを新たなソースＴＯＲＳへルーティングするアクションをインストールする。
【０１１５】
ブロック１５０９において、その他のラック上のサーバに加えて、ＴＯＲＳは、マルチキャストグループに加入している、同じラック内のその他のサーバへマルチキャストパケットを転送する必要がある。グループに加入しているＶＳを有するラック上の各サーバについて、パケットをＶＳに向けて転送するアクションを有するアクションバケットが存在する。このことが、パケットの発生元であるＶＳもまたパケットを受信するであろうことを意味する旨に留意されたい。ＶＳが、ルーティングループを防止するために、送信するＶＭと同じソースアドレスを有するＴＯＲＳから入来するパケットを破棄するルールを包含することは、この目的のためである。
【０１１６】
インカミングパケットについては、２つのフローテーブルが使用される。第１のフローテーブルは、マルチキャストグループ内のＶＭにサービスするＴＯＲＳに対応する各バックボーンルーティングラベルにマッチする１つのルールを包含する。アクションは、ブロック１５１１において、バックボーンルーティングラベルを外し、パケットを次のテーブルへ送出する。第２のテーブルは、マルチキャストルーティングラベル（ＭＬＭＧ１）にマッチするルールを包含する。アクションは、パケットを複製し、それをＴＯＲＳ入力グループ（ＴＩＧ１）へ送信する。入力グループ内の各バケットは、ブロック１５１３において、マルチキャストグループのメンバーである少なくとも１つのＶＭが稼働しているラック上のＶＳ又はサーバのうちの一方へパケットを転送するアクションを包含する。出力に関してとちょうど同じように、ラックからのＶＭが、参加する最初のＶＭである場合、ＭＣＣは、マルチキャストグループのメンバーとしてのＶＭを有するラックにサービスする全てのＴＯＲＳ内に、ルールをインストールしなければならない。
【０１１７】
図１６は、例示的な構成を有するＴＯＲＳのフローテーブルの図である。ＴＯＲＳは、マルチレベルパケット処理のために２フローテーブル構成を利用する。第１のフローテーブル１６０１においては、例示的なエントリのセットが示されている。第１のエントリは、ＭＰＬＳラベルを使用する特定のマルチキャストグループについてのマッチを探して、アウトバウンドマルチキャストトラフィックを管理する。これらマッチするパケットは、バックボーンＭＰＬＳラベルを用いてカプセル化され、ＴＯＲＳ出力グループ１６０３を使用して、マルチキャストグループについての加入ＶＭを有する、クラウドシステム内の各ＴＯＲＳへ送信される。インバウンドトラフィックは、第１のフローテーブル内の第２のフローテーブルエントリを用いてハンドリングされ、当該第２のフローテーブルエントリは、パケットをバックボーンラベルにマッチさせ、これらパケットを逆カプセル化する。逆カプセル化されたパケットは、次いで、第２のフローテーブル１６０７へ送信される。
【０１１８】
第２のフローテーブル１６０７において、パケットは、ＭＰＬＳラベルについてマッチが行われ、当該パケットがマルチキャストグループＭＰＬＳラベルにマッチするかどうかを判定する。マッチが見つかった場合、パケットはＴＯＲＳ入力グループにコピーされ、ＴＯＲＳ入力グループは、当該パケットを、ラック内に加入ＶＭを有する、各ＶＳへ転送する。
【０１１９】
上で説明したユニキャスト処理におけるように、バックボーンルートは変化することにならず、従って、クラウドシステムバックボーン内のスイッチには影響する必要がない旨に留意されたい。加えて、バックボーンラベルは、上記のユニキャストのケース向けのものとまさに同じであることが可能であり、又は、クラウドシステム事業者は、マルチキャストトラフィックについての或るルートを確保して、それらを固有のラベルで指定することを選択してもよい。
【０１２０】
マルチキャストグループを退去すること
図１７は、クラウドシステム内においてグループ退去メッセージをハンドリングするための処理の１つの実施形態のフローチャートである。ＶＭは、マルチキャストグループを退去する場合、ＩＰｖ４においてはＩＧＭＰグループ退去メッセージを、及び、ＩＰｖ６においてはＭＬＤグループ退去メッセージを送信する。サーバがスタートアップすると、ＣＮＭは、全てのグループ退去メッセージをＭＣＣへ転送するＯｐｅｎＦｌｏｗルールをサーバのＶＳ内にインストールする。どのＶＭがグループに加入しているのかに依存して、フロールーティングがどこで修正の必要を有するのかに影響する３つのケースが存在する：
第１に、マルチキャストグループを退去しようとするＶＭが存在するＶＳのサーバ上において、当該マルチキャストグループに加入しているその他のＶＭが存在するケース。
第２に、ＶＭが、サーバ又はＶＳ上においてグループを退去する最後のＶＭであるが、その他のラック上に、及び、ラック内のＶＳのその他のサーバ上に、同じマルチキャストグループに加入しているその他のＶＭが存在するケース。
第３に、ＶＭが、ラック上の、マルチキャストグループを退去する最後のＶＭであるケース。
【０１２１】
ＭＣＣは、マルチキャストグループ内のＶＭのリストをサーチすること、適正なＭＧＭＴを使用すること、並びに、どのＶＭが、ＶＳの、退去するＶＭと同じサーバ上に存在しているか、及び、どれがラック内のＶＳのその他のサーバ上に存在しているかに従って、それらを類別することにより、これらケースのうちのどれを考慮すべきであるのかを判定する。考え得るケースのうちの各々について、ここでは以下に扱う。
【０１２２】
同じＶＳ上で他のＶＭが依然として加入している
ＶＳの同じサーバ上に、加入しているその他のＶＭが存在する場合、ＭＣＣは、ＶＳのフローテーブル内の以下のルール及びアクションを削除するだけでよい：
退去するＶＭのソースＩＰアドレス（ＳＩＰＶＭ１）及びマルチキャストグループの宛先ＩＰアドレス（ＤＩＰＭＧ１）にマッチし、ＶＭ１からのアウトゴーイングパケットを転送するルール。これは、関連付けられるＯＧ１も削除する。このルール及び関連付けられるアクション並びにＯＧは、退去するＶＭからのアウトバウンドマルチキャストトラフィックを管理しており、従って、ブロック１７０３において削除されることが可能である。
全ＩＧ１という訳ではないが、ＩＧ１における、インカミングパケットをＶＭ１へ転送するアクション。このルールは、退去するＶＭへインカミングマルチキャストグループトラフィックを転送し、従って、ブロック１７０５において削除されることが可能である。
ＳＩＰＶＭ１及びＰＴＯＲＳ１にマッチする、ルーティングループを防止するためにパケットを破棄するルール。このルールは、退去するＶＭのアウトバウンドマルチキャストトラフィックのループバックを防止し、従って、ブロック１７０７において削除されることが可能である。
【０１２３】
次いで、ブロック１７０９及びブロック１７１５において、その他のケースのうちのいずれかが当てはまるかどうか、チェックを行うことができる。当てはまらない場合、その他のルールは修正される必要がなく、処理が完了する。
【０１２４】
ＶＳ上の、グループを退去する最後のＶＭ
退去するＶＭが、マルチキャストグループを退去する、ＶＳ上の最後のＶＭである場合、インカミングパケットをＶＭへ転送するルール及び関連付けられるＩＧ１は、ブロック１７１１において追加的に削除される。加えて、ＴＯＲＳ出力グループ（ＴＯＧ１）及びＴＯＲＳ入力グループ（ＴＩＧ１）内における、ＶＭに関連付けられるＶＳ１へマルチキャストグループのパケットを転送するアクションは、ブロック１７１３において削除される。
【０１２５】
次いで、ブロック１７１５において、退去するＶＭが、ラック上の、即ちＴＯＲＳに関連付けられる、マルチキャストグループに加入している最後のＶＭであるかどうか、チェックが行われることが可能である。退去するＶＭが、ＴＯＲＳ上の、マルチキャストグループに加入する最後のＶＭではない場合、処理は完了する。
【０１２６】
ラック上の、グループを退去する最後のＶＭ
ＶＭが、ラック上の、マルチキャストグループを退去する最後のＶＭである場合、追加的に、ＴＯＲＳ１の第１のフローテーブル内の２つのルール及び第２のフローテーブル内の１つのルールは、ブロック１７１７において、それらのそれぞれの入力グループ及び出力グループと共に除去される。
【０１２７】
ＶＭ移動をハンドリングすること
図１８は、クラウドシステム内において、ＭＰＬＳを使用してマルチキャストをサポートしてＶＭ移動をハンドリングするための処理の１つの実施形態のフローチャートである。サーバ及びＶＳ間のＶＭ移動は、上記の技法と、上記のユニキャストに関して説明した一般的なＶＭ移動技法との混成物により、ハンドリングされることが可能である。この処理は、ブロック１８０１において、負荷分散の目的のため、又は同様の理由のために、ＶＭの移動により開始される。
【０１２８】
移動の期間中に、移動するＶＭに関連付けられるＶＳ及びＴＯＲＳ内における、マルチキャストトラフィックを当該移動するＶＭへ方向付けるルートは、ＶＭが新たなロケーションにおいて実行し、トラフィックを受信する準備が整うまで維持される。ＶＭ移動の期間中に、ブロック１８０３において、ユニキャストに関して上で説明された手続に従い、移動するＶＭ宛てのユニキャストトラフィックだけではなくマルチキャストトラフィックをも捕捉し、それをバッファリングのためにＣＮＭへ送信するように、新たなルート（即ち、フローテーブルエントリ）が古いＶＳ内に配置される。
【０１２９】
バッファリングは、ブロック１８０５において、ＶＭ移動が完了するまで継続する。ＣＮＭは、次いで、ブロック１８０７において、バッファリングされたパケットを新たなロケーションにおけるＶＭへ転送するように通知を受けることが可能である。新たなＶＭがアクティブになる前に、当該ＶＭがマルチキャストグループのメンバーである場合、マルチキャストグループＶＭレコード内のＶＳレコード及びＴＯＲＳレコードは、ブロック１８０９において、新たなロケーションを反映するように修正される必要がある。加えて、マルチキャストグループに参加するための上記の手続は、ブロック１８１１において、ＶＭが加入している各マルチキャストグループについて、新たなＶＳ及びＴＯＲＳ上で実行されなければならない。ブロック１８１３において、各加入されたマルチキャストグループについて、古いＶＳ及びＴＯＲＳ対して退去動作も実行される。
【０１３０】
図１９は、この発明の実施形態による、例示的なコンピュータシステムのブロック図を例示する。図１０の例示的なコンピュータシステム１０００は、ＴＯＲＳ  ２０１Ａ、仮想化されたサーバ２０５Ａ、ＣＥＭ  ２５０、ＭＣＣ  ２９０、及び／又はＣＮＭ  ２６０を実装するために使用されることが可能である。ＣＥＭ  ２５０、ＭＣＣ  ２９０、及び／又はＣＮＭ  ２６０がＯｐｅｎＦｌｏｗコントローラにおいて実装される場合、このシステムは、ＯｐｅｎＦｌｏｗコントローラを実行することができる。当業者は、これらデバイスを実装するために使用されるその他のコンピュータシステムが、それよりも多くの、又はそれよりも少ないコンポーネントを有してよいこと、及び、この発明の実施形態において使用されてよいことを認識するであろう。
【０１３１】
コンピュータシステム１９００は、処理システム１９１５、電源１９２０、揮発性メモリ１９２５（例えば、ダブルデータレートランダムアクセスメモリ（ＤＤＲ−ＲＡＭ）、シングルデータレート（ＳＤＲ）ＲＡＭ）、不揮発性メモリ１９３０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）と連結されるバス１０５０を含む。処理システム１９１５は、処理システムキャッシュ１９１０へさらに連結され得る。処理システム１９１５は、揮発性メモリ１９２５及び／又は不揮発性メモリ１９３０から命令を取り出して、当該命令を実行して上記の動作を実行し得る。バス１９５０は、上記のコンポーネントを共に連結し、ディスプレイコントローラ１０７０、１つ以上の入力／出力デバイス１０８０（例えば、ネットワークインタフェースカード、カーソルコントロール（例えば、マウス、トラックボール、タッチスクリーン、タッチパッドなど）、キーボードなど）、及び任意選択として、１つ以上の無線送受信機（例えば、ブルートゥース、ＷｉＦｉ、赤外線など）をさらに連結する。１つの実施形態において、ディスプレイコントローラ１９７０は、ディスプレイデバイス１９７５へさらに連結される。
【０１３２】
ここで説明されるように、命令は、或る動作を実行するように構成されるか、又は、メモリ内に記憶される、事前に定義された機能性若しくはソフトウェア命令を、非一時的コンピュータ可読媒体内で具現化させるように構成される、特定用途向け集積回路（ＡＳＩＣ）といったハードウェアの固有の構成を指し得る。よって、図に示される技法は、１つ以上の電子デバイス（例えば、終端局、ネットワーク要素）上で記憶されて実行されるコード及びデータを使用して実装されることが可能である。そうした電子デバイスは、非一時的コンピュータ可読記憶媒体（例えば、磁気ディスク、光ディスク、ランダムアクセスメモリ、読み出し専用メモリ、フラッシュメモリデバイス、相変化メモリ）及び一時的コンピュータ可読通信媒体（例えば、電気的、光学的、音響的、又はその他の形の伝播信号−例えば、搬送波、赤外線信号、デジタル信号）などのコンピュータ可読媒体を使用して、コード及びデータを記憶し、コード及びデータを（内部的に、及び／又は、その他の電子デバイスとの間でネットワークを通じて）通信する。加えて、そうした電子デバイスは、典型的には、１つ以上のストレージデバイス（非一時的マシン可読記憶媒体）、ユーザ入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又はディスプレイ）、並びにネットワーク接続といった１つ以上のその他のコンポーネントへ連結される１つ以上のプロセッサのセットを含む。プロセッサのセット及びその他のコンポーネントを連結することは、典型的には、１つ以上のバス及びブリッジ（バスコントローラとも呼称される）を経由する。よって、所与の電子デバイスのストレージデバイスは、典型的には、当該電子デバイスの１つ以上のプロセッサのセット上での実行のためにコード及び／又はデータを記憶する。当然ながら、この発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの様々な組み合わせを使用して実装されてよい。
【０１３３】
図におけるフロー図は、この発明の或る実施形態により実行される動作の特定の順序を示しているが、そうした順序が例示的であることを理解されるべきである（例えば、代替的実施形態は、異なる順序における当該動作の実施、或る動作の組み合わせ、或る動作の重複などを行ってよい）。
【０１３４】
この発明を、いくつかの実施形態の観点で説明してきたが、当業者は、この発明が、説明された実施形態に限定されないこと、並びに、添付の特許請求の範囲の思想及び範囲内にある修正及び変形を用いて実施可能であることを認識するであろう。よって、この説明は、限定的というよりはむしろ、例示的であるとみなされるべきである。
【図１Ａ】
0005927352.tif 000006
【図１Ｂ】
0005927352.tif 000007
【図２】
0005927352.tif 000008
【図３Ａ】
0005927352.tif 000009
【図３Ｂ】
0005927352.tif 000010
【図３Ｃ】
0005927352.tif 000011
【図４】
0005927352.tif 000012
【図５】
0005927352.tif 000013
【図６】
0005927352.tif 000014
【図７】
0005927352.tif 000015
【図８】
0005927352.tif 000016
【図９】
0005927352.tif 000017
【図１０】
0005927352.tif 000018
【図１１】
0005927352.tif 000019
【図１２】
0005927352.tif 000020
【図１３】
0005927352.tif 000021
【図１４】
0005927352.tif 000022
【図１５】
0005927352.tif 000023
【図１６】
0005927352.tif 000024
【図１７】
0005927352.tif 000025
【図１８】
0005927352.tif 000026
【図１９】
0005927352.tif 000027