特許7228315仮想ネットワークを実装する方法、媒体、コンピュータプログラム、コンピューティングデバイス
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-02-15
(45)【発行日】2023-02-24
(54)【発明の名称】仮想ネットワークを実装する方法、媒体、コンピュータプログラム、コンピューティングデバイス
(51)【国際特許分類】
H04L 45/44 20220101AFI20230216BHJP
H04L 41/40 20220101ALI20230216BHJP
【ＦＩ】
H04L45/44
H04L41/40
【請求項の数】
19
【外国語出願】
(21)【出願番号】P 2021102573
(22)【出願日】2021-06-21
(62)【分割の表示】P 2020068582の分割
【原出願日】2010-04-01
(65)【公開番号】P2021168483
(43)【公開日】2021-10-21
【審査請求日】2021-07-16
(31)【優先権主張番号】61/165,875
(32)【優先日】2009-04-01
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】511235548
【氏名又は名称】ニシラ， インコーポレイテッド
(74)【代理人】
【識別番号】100076428
【弁理士】
【氏名又は名称】大塚 康徳
(74)【代理人】
【識別番号】100115071
【弁理士】
【氏名又は名称】大塚 康弘
(74)【代理人】
【識別番号】100112508
【弁理士】
【氏名又は名称】高柳 司郎
(74)【代理人】
【識別番号】100116894
【弁理士】
【氏名又は名称】木村 秀二
(74)【代理人】
【識別番号】100130409
【弁理士】
【氏名又は名称】下山 治
(72)【発明者】
【氏名】カサド， マーティン
(72)【発明者】
【氏名】イングラム， ポール エス．
(72)【発明者】
【氏名】アミドン， キース エリック
(72)【発明者】
【氏名】バランド サード， ピーター ジェイ．
(72)【発明者】
【氏名】コポネン， テーム
(72)【発明者】
【氏名】プファフ， ベンジャミン レビー
(72)【発明者】
【氏名】ペティット， ジャスティン
(72)【発明者】
【氏名】グロス フォース， ジェシー イー．
(72)【発明者】
【氏名】ウェンドラント， ダニエル ジェイ．
【審査官】宮島 郁美
(56)【参考文献】
【文献】国際公開第２００９／１４２８２６（ＷＯ，Ａ１）
【文献】特表２０１１－５２３１２８（ＪＰ，Ａ）
【文献】特開２００１－３１３６６３（ＪＰ，Ａ）
【文献】特開２００８－０４２６６５（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１０／０２４６４４３（ＵＳ，Ａ１）
【文献】仮想化技術の本命 ハイパーバイザ型の仮想化ソフトウェア，ＮＥＴＷＯＲＫ ｍａｇａｚｉｎｅ，第１３巻 第１２号，日本，株式会社アスキー・メディアワークス，2008年12月01日，第46-51頁
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ１２／００－１３／１８，４１／００－４９／９０５７，６１／００－６５／８０，６９／００－６９／４０
(57)【特許請求の範囲】
【請求項1】
データセンタ内の複数のテナント間で共有される物理ネットワークを介して第１のテナントの仮想ネットワークを実装する方法であって、複数のホストコンピュータ上で実行される複数のソフトウェア転送要素（ＳＦＥ）によって実装される論理転送要素（ＬＦＥ）を定義することと、
前記ＬＦＥを実装するように前記ＳＦＥを構成するために、前記複数のホストコンピュータ上で実行されている前記複数のＳＦＥにデータを配信することと、
前記ＬＦＥの特定のポートと、少なくとも１台のホストコンピュータで実行されている少なくとも１つの特定のＳＦＥのポートとの間のマッピングを提供することと、を備え、
前記ＳＦＥは、前記配信されたデータと前記提供されたマッピングを使用して、前記ＬＦＥに関連付けられたパケットを転送し、
各ＳＦＥは、前記配信されたデータを使用して、前記第１のテナントのマシンから受信されたパケットを転送するための論理転送判断を実行する、方法。
【請求項2】
データセンタ内の複数のテナント間で共有される物理ネットワークを介してテナントの仮想ネットワークを実装する方法であって、
複数のホストコンピュータ上で実行される複数のソフトウェア転送要素（ＳＦＥ）によって実装される論理転送要素（ＬＦＥ）を定義することと、
前記ＬＦＥを実装するように前記ＳＦＥを構成するために、前記複数のホストコンピュータ上で実行されている前記複数のＳＦＥにデータを配信することと、
前記ＬＦＥの特定のポートと、少なくとも１台のホストコンピュータで実行されている第１のＳＦＥのポートとの間のマッピングを提供することと、を備え、
前記ＳＦＥは、前記配信されたデータと前記提供されたマッピングを使用して、前記ＬＦＥに関連付けられたパケットを転送し、
第２のＳＦＥは、パケットの論理コンテキストをルックアップし、前記論理コンテキストに従って前記パケットの論理出力ポートを識別し、前記論理出力ポートを物理ポートにマップし、前記パケットを前記物理ポートに転送する、方法。
【請求項3】
前記論理出力ポートは前記ＬＦＥの前記特定のポートであり、前記物理ポートは前記第１のＳＦＥの前記ポートであり、前記第２のＳＦＥは、前記提供されたマッピングを使用して、前記ＬＦＥの前記特定のポートを前記第１のＳＦＥの前記ポートにマッピングする、請求項２に記載の方法。
【請求項4】
前記複数のＳＦＥは前記ＬＦＥを実装し、前記データセンタ内でホストされている他のテナントのマシンから第１のテナントのマシンを分離しながら、前記第１のテナントのマシン間でパケットを処理する、請求項１に記載の方法。
【請求項5】
前記複数のＳＦＥが、それぞれのテナントのマシンを分離しながら、前記他のテナントのマシン間でパケットを処理するために他のＬＦＥを実装する、請求項４に記載の方法。
【請求項6】
データセンタ内の複数のテナント間で共有される物理ネットワークを介して第１のテナントの仮想ネットワークを実装する方法であって、
複数のホストコンピュータ上で実行される複数のソフトウェア転送要素（ＳＦＥ）によって実装される論理転送要素（ＬＦＥ）を定義することと、
前記ＬＦＥを実装するように前記ＳＦＥを構成するために、前記複数のホストコンピュータ上で実行されている前記複数のＳＦＥにデータを配信することと、
前記ＬＦＥの特定のポートと、少なくとも１台のホストコンピュータで実行されている少なくとも１つの特定のＳＦＥのポートとの間のマッピングを提供することと、を備え、
前記ＳＦＥは、前記配信されたデータと前記提供されたマッピングを使用して、前記ＬＦＥに関連付けられたパケットを転送し、
前記特定のＳＦＥは、前記配信されたデータを使用して、前記第１のテナントのマシンから受信したパケットに対する前記ＬＦＥの論理出力ポートを識別し、前記識別された論理出力ポートを前記特定のＳＦＥの物理ポートにマッピングすることによって、前記パケットを転送する、方法。
【請求項7】
前記特定のＳＦＥは、前記識別された論理出力ポートを物理的なネクストホップアドレスにマッピングし、前記物理的なネクストホップアドレスで前記パケットをカプセル化し、前記特定のＳＦＥの前記物理ポートから前記パケットを転送することにより、前記識別された論理出力ポートを前記物理的なポートにマップする、請求項６に記載の方法。
【請求項8】
前記特定のＳＦＥが第１のＳＦＥであり、前記物理的なネクストホップアドレスが、前記ＬＦＥを実装する第２のＳＦＥに関連付けられている、請求項７に記載の方法。
【請求項9】
前記第１のテナントの前記マシンは、前記特定のＳＦＥと同じホストコンピュータ上で実行される、請求項６に記載の方法。
【請求項10】
前記論理転送判断は、論理スイッチのＬ２ルックアップを含む、請求項１に記載の方法。
【請求項11】
前記論理転送判断は、論理ルータのためのＬ３ルックアップを含む、請求項１に記載の方法。
【請求項12】
前記第１のテナントの前記マシンは、複数の仮想マシンを含む、請求項１に記載の方法。
【請求項13】
前記方法は、ネットワークハイパーバイザーにより実行される、請求項１に記載の方法。
【請求項14】
前記ＳＦＥは、１つ以上の仮想スイッチを含む、請求項１に記載の方法。
【請求項15】
前記ＬＦＥが第１のＬＦＥであり、前記複数のＳＦＥが第１の複数のＳＦＥであり、前記複数のホストコンピュータが第１の複数のホストコンピュータであり、前記特定のＳＦＥが第１のホストコンピュータで実施される第１のＳＦＥであり、第２の複数のホストコンピュータ上で実行される第２の複数のＳＦＥによって実装される第２のＬＦＥを定義することと、
前記第２のＬＦＥを実装するように前記第２の複数のＳＦＥを構成するために、前記第２の複数のホストコンピュータ上で実行される前記第２の複数のＳＦＥにデータを配信することと、
前記第２のＬＦＥの特定のポートと、第２のホストコンピュータ上で実行されている第２のＳＦＥの特定のポートとの間のマッピングを提供することとをさらに含み、
前記第２の複数のＳＦＥのＳＦＥは、前記配信されたデータおよび前記提供されたマッピングを使用して、前記第２のＬＦＥに関連するパケットを転送する、請求項１に記載の方法。
【請求項16】
前記第２の複数のＳＦＥが、前記第１の複数のＳＦＥと部分的に重複する、請求項１５に記載の方法。
【請求項17】
少なくとも１つの処理ユニットによって実施されると、請求項１乃至１６のいずれか１項に記載の方法を実施するプログラムを格納する機械可読媒体。
【請求項18】
少なくとも１つの処理ユニットによって実行されると、請求項１乃至１６のいずれか１項に記載の方法を実施するコンピュータプログラム。
【請求項19】
処理ユニットのセットと、前記処理ユニットの少なくとも１つによって実施されると、請求項１乃至１６のいずれか１項に記載の方法を実施するプログラムを格納する機械可読媒体と、を備えるコンピューティングデバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、２００９年４月１日提出の米国仮特許出願第６１／１６５８７５号を基礎として優先権を主張するものであり、その記載内容の全てを、ここに援用する。
【0002】
本発明は、ネットワーキングに関し、特に仮想ネットワーキングでの仮想スイッチの設計及び使用に関する。
【背景技術】
【0003】
移動性、仮想化、動的ワークロード、マルチテナンシー及びセキュリティニーズを含むコンピューティングが高度になるにつれて、ネットワーキングに対するより適切なパラダイムが必要とされる。仮想化は、ネットワークに対する新たな要求の重要な要因である。その要因により、複数のＶＭは同一の物理サーバを共有でき、それらのＶＭは移行（migrate）可能であり、ワークロードは容量が必要となるために「スケールアウト」に動的に組み込まれている。この新しいレベルのダイナミクスに準拠するために、分散仮想スイッチの概念が生じた。分散仮想スイッチの背後にある考えは、基盤となるハードウェアから切り離され且つ複数のスイッチ又はハイパーバイザを介して拡張するスイッチの論理ビューを提供することである。
【0004】
従来の分散仮想スイッチの一例は、Ｓａｎ Ｊｏｓｅ、ＣａｌｉｆｏｒｎｉａのＣｉｓｃｏにより提供されたＮｅｘｕｓ１０００Ｖである。別の例は、Ｐａｌｏ ＡｌｔｏのＶＭＷａｒｅにより提供されたＤＶＳである。これらの双方とも仮想のみの環境を意図するが、同一の概念を物理環境に適用できないという構造的理由はない。
【0005】
大きなネットワーク（データセンタ及び企業を含む）の多くの課題のうちの３つは、拡張性、移動性及びマルチテナンシーであり且つ多くの場合、他者を妨害するものに対処する方法である。例えば、Ｌ２ドメイン内でＶＭにネットワークモビリティを容易に提供できるが、Ｌ２ドメインを大きなサイズに拡張することはできない。また、テナントを隔離し続けることにより、移動性が非常に複雑になる。従来の分散仮想スイッチは、多くの領域においてこれらの問題に対処しきれていない。まず、分散仮想スイッチは、マルチテナンシーを提供せず、ＩＰサブネットをブリッジせず、何万ものエンドホストをサポートするように拡張しない。更に概念は、物理ホストを統括的に且つ柔軟に含む仮想環境を効果的に超えていない。
【0006】
従って、これらの問題及び他の問題に対処する分散仮想ネットワーキングプラットフォームに対する必要性は、当技術分野において依然として存在する。
【発明の概要】
【課題を解決するための手段】
【0007】
一般に本発明は、１つ以上の分散仮想スイッチが仮想ネットワークで使用するために作成される仮想プラットフォームに関する。いくつかの態様によると、本発明に係る分散仮想スイッチは、仮想機械及び物理機械が同一の物理ホスト上及び／あるいは同一のサブネット又はＶＬＡＮに配置されない場合でも、互いにより簡単に、安全に且つ効率的に通信する機能をそれらに提供する。他の態様によると、本発明の分散仮想スイッチは、従来のＩＰネットワークとの統合をサポートし、ＮＡＴ機能性を含む複雑なＩＰ技術、ステートフルファイアウォール及びＩＰネットワークにワークロード移行を通知するのをサポートする。更なる態様によると、本発明の仮想プラットフォームは、隔離及び／又は独立した構成状態を必要とするテナント、アプリケーション又は他のエンティティに割り当てられてもよい１つ以上の分散仮想スイッチを作成する。更に別の態様によると、本発明の仮想プラットフォームは、ネットワークで既存のスイッチ及びルータを用いて動作しつつ、ネットワークに対して分散仮想スイッチを作成するためにＶＬＡＮ又はトンネル（例えば、ＧＲＥ）を管理し且つ／あるいは使用する。本発明は、社内ネットワーク、データセンタ及び他の施設の全てで有用であることが分かる。
【0008】
これらの態様及び他の態様に従って、本発明の実施形態に係る複数のホスト及び物理転送要素を含むサイトでネットワーキングリソースを管理する方法は、複数のホスト及び物理転送要素の第１の集合を使用する仮想機械の第１の集合を識別することと、複数のホスト及び物理転送要素の第２の集合を使用する仮想機械の第２の集合を識別することであり、第１の集合及び第２の集合のホスト及び物理転送要素のうちのいくつかが同一であることと、仮想機械の第１の集合と第２の集合との間の隔離を維持しつつ、それぞれ、仮想機械の第１の集合と第２の集合との間の通信を排他的に処理する第１の分散仮想スイッチ及び第２の分散仮想スイッチを提供することとを備える。
【0009】
これらの態様及び他の態様を更に推進するために、本発明の実施形態に係る１つ以上の物理転送要素を含むネットワークで通信を管理する方法は、論理転送要素を含むネットワーク仮想化レイヤを提供することと、論理転送要素のポートから物理転送要素のうちのいくつかのポートへのマッピングを提供することと、提供されたマッピングを使用して物理転送要素によりパケットを転送することとを備える。
【図面の簡単な説明】
【0010】
添付の図面と共に本発明の特定の実施形態の以下の説明を検討することにより、本発明のこれらの態様及び特徴、並びに他の態様及び特徴が当業者には明らかとなるだろう。
【発明を実施するための形態】
【0011】
次に、当業者が本発明を実施できるように本発明の例として提供される図面を参照して、本発明を詳細に説明する。特に、以下の図面及び例は本発明の範囲を単一の実施形態に限定することを意図せず、説明されるかあるいは図示される要素のうちのいくつか又は全てを交換することにより他の実施形態が可能である。また、本発明のある特定の要素は既知の構成要素を使用して部分的に又は完全に実現され、本発明を理解するのに必要なそのような既知の構成要素のこれらの部分のみが説明され、そのような既知の構成要素の他の部分の詳細な説明は本発明を不明瞭にしないように省略される。特に指定のない限り、当業者には明らかとなるように、ソフトウェアで実現されるものとして説明される実施形態は、それに限定されるべきではなく、ハードウェア又はソフトウェアとハードウェアとの組合せで実現される実施形態を含んでもよく、逆も同様である。明示的な指示のない限り、本明細書において、単数の構成要素を示す一実施形態は限定するものと考えられるべきではなく、本発明は複数の同一の構成要素を含む他の実施形態を含むことを意図し、逆も同様である。また、明示的なそのような説明のない限り、出願人は、明細書又は請求の範囲のあらゆる用語が一般的でない意味又は特別な意味を有することを意図しない。更に本発明は、例として本明細書で示される既知の構成要素に対する現在の既知の等価物及び将来の既知の等価物を含む。
【0012】
一態様によると、本発明は、ネットワークで使用するための仮想プラットフォームに関する。仮想フラットフォームは、物理機械及び仮想機械が同一の物理ホスト上及び／あるいは同一のＶＬＡＮ又はサブネットに配置されない場合でも、互いにより簡単に、安全に且つ効率的に通信する機能をそれと関連付けられた物理機械及び仮想機械に提供する。更なる態様によると、更に本発明により、同一の物理ネットワークインフラストラクチャを共有する複数の異なるテナントは、通信し且つ互いに隔離して構成状態を設定できる。
【0013】
本発明の態様の実現例の一例を図１に示す。図１に示すように、データセンタ又は社内ネットワーク等のサイトは、物理ネットワーク１０４を含む。物理ネットワーク１０４は、複数のＶＭ及び／又は非仮想化物理サーバ、並びに物理スイッチ及び仮想スイッチを含む。ＶＭは、ＶＭＷａｒｅ（例えば、ｖＳｐｈｅｒｅ、ｖＣｅｎｔｅｒ等に含まれた）により提供されるような仮想化プラットフォームによりホストされ、物理サーバは、ＨＰ、Ｄｅｌｌ及び他社により提供されるようなあらゆる汎用演算ユニットであってもよい。大きなホスティングサービス又は社内ネットワークが地理的に分散され得る（例えば、Ｓａｎ Ｆｒａｎｃｉｓｃｏ、Ｎｅｗ Ｙｏｒｋ等）複数のデータセンタ又はいくつかのサイトにおけるネットワークを維持できることは、明らかであるべきである。
【0014】
図１は、本発明がネットワーク仮想化レイヤ１０６を導入する方法を更に示す。ネットワーク仮想化レイヤ１０６上には、ネットワークハイパーバイザ１０２により１つ以上の分散仮想スイッチ１０８が維持される。これらの分散仮想スイッチ１０８は、サブネットを介して拡張してもよく、物理ホスト又は物理ネットワークポートを含んでもよく、同一の物理ハードウェアを共有することができる。本発明の態様によると、これらの分散仮想スイッチは、マルチテナント環境に隔離されたコンテキストを提供し、サブネットを介してＶＭ移行をサポートし、何万又は何十万もの物理サーバに拡張し、物理環境とのシームレスな統合をサポートする。
【0015】
特定の例として、本発明は、複数の顧客に対するサーバの仮想ホスティング及び物理ホスティングの双方をサポートすることが多いサービスプロバイダ（Ｓａｎ Ａｎｔｏｎｉｏに本社を置くＲａｃｋｓｐａｃｅ等）により展開される。そのような一例において、単一の顧客は、同一のサービスプロバイダにホストされたＶＭ及び物理サーバの双方を有してもよい。更にサービスプロバイダは、地理的に別個の場所に複数のデータセンタを有してもよい。顧客／テナントの各々が１つ以上の分散仮想スイッチ（ＤＶＳ）１０８に割り当てられるように、本発明はサービスプロバイダ動作内で展開されてもよい。これらのＤＶＳは、ハイパーバイザ１０２を使用するサービスプロバイダオペレータにより規定されたように、最小リソース保証を個別に構成され且つ与えられる。単一のＤＶＳは、物理ホスト及び仮想ホストの双方を含んでもよく、複数のサブネット又はＶＬＡＮをブリッジしてもよい。例えば単一のＤＶＳ１０８は、管理されたホスティングサービスの一部としてサービスプロバイダの仮想機械、物理機械に接続してもよく、インターネットを介して拡張して顧客構内に接続してもよい。
【0016】
更なる態様によると、本発明は、物理転送要素と制御プレーンとの間に新しい抽象概念を導入する。抽象概念により、転送要素を制御プレーンに対する１つ以上の論理転送要素とする。論理転送要素は、物理転送要素と同様の特性及び機能性、すなわちルックアップテーブル、ポート、カウンタ、並びに関連付けられた能力（例えば、ポートスピード及び／又は二重帯域）を所有する。
【0017】
ネットワークハイパーバイザ１０２及びネットワーク仮想化レイヤ１０６は、本発明の態様を説明しやすくするために別個に示されるが、論理転送要素を作成及び維持し、且つそれらを基盤となるハードウェアにマッピングする共通のソフトウェアの集合（以下に更に詳細に説明する）により実現されるのが好ましい。名目上、これは、対応する論理コンテキストで転送状態、カウンタ及び転送要素イベントを示すことを意味する。制御プレーンは、物理転送要素を直接駆動するのではなく、論理転送要素とインタフェースする。
【0018】
更に詳細には、ネットワーク仮想化レイヤ１０６は、ネットワーク１０４の物理トポロジの変化により最小限の影響を受ける制御プレーンに転送抽象概念を提示する。制御プレーンの観点から、物理トポロジにスイッチを追加することにより、より多くの転送帯域幅を提供するが、制御論理又は論理転送テーブルの既存の状態に何らかの変化を要求すべきではない。
【0019】
レイヤ１０６により、論理転送要素ポートは、物理ポートに結合されるか、あるいは仮想機械インタフェース、ＶＬＡＮ又はトンネル等の他のポート抽象概念を提供できる。レイヤ１０６の論理転送要素上のポートと基盤となるネットワーク１０４との間のマッピングを維持し、且つそれに応じて物理ネットワークの物理スイッチ及び／又は仮想スイッチのフローテーブルを更新することがネットワークハイパーバイザ１０２の仕事である（以下に説明する）。
【0020】
レイヤ１０６の各論理転送要素は、従来のスイッチデータ経路と互換性があるインタフェースを提供する。これは２つの理由から望ましい。第１に、本発明は既存のハードウェアと互換性があり且つ有用であるのが好ましく、全ての転送はハードウェア高速経路上に依然として存在すべきである。従って、論理転送プレーンは、好ましくは既存の転送パイプラインにマッピングすべきである。第２に、既存のネットワーク制御スタックは、本発明に準拠するのが好ましい。従って、レイヤ１０６の論理要素のインタフェースは以下のものを含む。
【0021】
・ルックアップテーブル：論理転送要素は１つ以上の転送テーブルを示す。一般にこれは、Ｌ２、Ｌ３及びＡＣＬテーブルを含む。より一般化されたテーブル構造が規則毎に規定された転送動作でＴＣＡＭのパイプラインの周囲に組み込まれることに従って、実現例の一例は、ＯｐｅｎＦｌｏｗ（ｗｗｗ．ｏｐｅｎｆｌｏｗ．ｏｒｇを参照）の周囲に設計される。この構造により、規則、ＡＣＬ、ＳＰＡＮ及び他の基本要素を転送するのをサポートできるかなりの柔軟性を提供する。
【0022】
・ポート：論理転送要素は、基盤となるネットワークへの結合を示すポートを含む。ポートは、管理上追加されるか、あるいは自身が結合される構成要素が故障又は離脱する際に動的に出現し且つ離脱してもよい。本発明の実施形態において、ポートは、ｒｘ／ｔｘカウンタ、ＭＴＵ、速度、エラーカウンタ及び搬送波信号を含む物理アナログの同一の品質の大部分を維持する。
【0023】
物理ネットワーク１０４は物理転送要素から構成される。本発明の実施形態において、転送要素は、標準的な転送シリコンを含む従来のハードウェアスイッチ及びハイパーバイザと共に含まれたような仮想スイッチである。本発明の実施形態において、既存のスイッチのうちのいくつか又は全ては、プロトコルが本発明の分散仮想スイッチを実現するようにそれらのフローテーブルを調整できるようにサポートする。そのようなプロトコルはＯｐｅｎＦｌｏｗを含むが、他の自社開発のプロトコル及びＯＳＰＦ等のオープンプロトコルが使用されてもよい。本発明の他の実施形態において及び以下に更に詳細に説明されるある特定の有益な態様に従って、既存の物理スイッチのうちのいくつか又は全て（及び場合によっては仮想スイッチのうちのいくつか）は、そのようなプロトコルをサポートし且つ／あるいはそれらのフローテーブルを調整する必要はない。そのような実施形態において、そのような既存のスイッチを介してトラフィックをルーティングするためにトンネリングが使用されてもよい。
【0024】
高レベルにおいて、分散仮想スイッチ１０８を実現するためにネットワークハイパーバイザ１０２により使用される物理ネットワーク１０４の転送要素は、４つの主な役割、すなわちｉ）入力パケットを適切な論理コンテキストにマッピングする役割、ii）論理転送判断を行う役割、iii）論理転送判断を物理的な次のホップアドレスに再度マッピングする役割、及び、iv）パケットを物理的な次のホップに送出するために物理転送判断を行う役割、を有する。
【0025】
更に詳細には、図２に示すように、全てのパケットは、レイヤ１０６で厳密に１つの論理転送要素により処理される。しかし、複数の論理転送要素が、物理ネットワーク１０４で同一の物理スイッチを介して多重化されてもよい。従って、入力上で、パケットは適切な論理コンテキストにマッピングされなければならない（Ｓ２０２）。現在のスイッチが、所定のパケットに対する論理転送状態を含まず、その場合に単に物理転送判断を実行する（すなわち、ステップＳ２０８にスキップする）場合があってもよい。また、全ての物理スイッチが単一の論理転送要素のみを実現するためのものである場合、論理アドレス指定が物理ネットワークにおいて使用されてもよいため、マッピングはｎｏ－ｏｐとなる。
【0026】
本発明によりパケットを論理コンテキストにマッピングするために使用される多くの異なるフィールドがある。例えばフィールドは、ＭＰＬＳヘッダ等の識別タグ又は入力ポートであってもよい。しかし、エンドシステムを透過的にするために、論理コンテキストを識別するために使用されるタグは、論理スイッチに接続するシステムに示されないのが好ましい。一般にこれは、パケットを受信する第１の物理スイッチがそれをタグ付けしてコンテキストをマーク付けし、最後のスイッチがタグを除去することを意味する。当業者には理解されるように、第１のタグが選択される方法は展開環境に大きく依存する。
【0027】
ステップＳ２０４において、パケットが論理コンテキストにマッピングされると、物理スイッチは論理コンテキスト内でのみ意味のある転送判断を実行する。例えばこれは、論理スイッチに対するＬ２ルックアップ又は論理Ｌ３ルータに対して必要な一連のルックアップであってもよい。しかし、論理判断を実行する物理スイッチが全ての論理状態を維持するのに十分な容量を有さない場合、実行された論理判断が実行される必要のある全体的な論理判断のたった１ステップであってもよいため、パケットは、論理転送プレーンを離脱する前に更なる論理処理を必要とするだろう。
【0028】
ステップＳ２０６において、論理判断は物理にマッピングされる。論理転送判断（パケットがドロップしなかったと仮定する）の結果、レイヤ１０６の論理転送要素上に１つ以上の出力ポートが得られる。これらが判定されると、ネットワークは、これらの出力ポートが結合されるネットワーク１０４でパケットを物体に送出しなければならない。例えばこれは、別の物理スイッチ上の物理ポート又は異なる物理サーバ上の仮想機械の仮想ポートであってもよい。
【0029】
従って、ネットワークハイパーバイザ１０２は、物理転送要素をテーブルエントリに提供し、論理出力ポートを物理的な次のホップにマッピングしなければならない。実施形態において、論理ネットワーク及び物理ネットワークは、別個の（潜在的にオーバラップするが）アドレス空間を共有する。従って、物理アドレスが次のホップに対して見つけられると、（論理）パケットは、次のホップ物理アドレスに転送されるようにカプセル化されなければならない。尚、ルックアップが複数の物理構成要素を介して分散され、その場合に「次のホップ」が次の物理構成要素となり、論理出力ポートではなくルックアップを継続する場合があってもよい。
【0030】
ステップＳ２０８において、物理転送が最終的に行われる。物理転送判断は、先のマッピングステップにより判定された物理アドレスに基づいて適切な物理出力ポートからパケットを転送する役割を担う。これには、新しい物理ヘッダ（先のステップで作成された）上の第３の（又はそれを上回る）ルックアップが必要である。
【0031】
尚、ネットワークの物理スイッチが複数の論理コンテキストではなく１つの論理コンテキストのみを有する場合、先の２つのステップＳ２０４及びＳ２０６はｎｏ－ｏｐになってもよい。
【0032】
上記の４つのステップを実現するため、物理スイッチは、i）論理コンテキストにマッピングするためのルックアップ、ii）論理転送判断、iii）論理出力ポートから物理的な次のホップアドレスへのマッピング及びiv）物理転送判断に対する状態を有する必要がある。物理ネットワークを介して制御を最大限にするのが好ましい場合、ハイパーバイザ１０２は最初の３つを管理する役割を担い、物理転送状態は、標準的なＩＧＰ（ＯＳＰＦ又はＩＳＩＳ等）の実現例又はハイパーバイザ１０２により管理される。
【0033】
本発明の実施形態において、物理ネットワーク１０４機能は最新のラインカード機能に対応する。例えば、少なくとも、ネットワーク１０４の物理スイッチ及び／又は仮想スイッチは、パケット転送パイプラインを提供し、パケット毎に複数の論理ルックアップ及び物理ルックアップの双方をサポートすべきである。基本転送動作（出力ポート選択等）に加え、物理スイッチングインフラストラクチャが複数の論理転送プレーンにより共有される場合、ハードウェアは、（ネストされた）カプセル化／非カプセル化をサポートし、論理アドレス指定を物理アドレス指定から隔離すべきである。また、ネットワーク１０４の物理スイッチ及び／又は仮想スイッチのうちのいくつか又は全ては、例えばＯｐｅｎＦｌｏｗ等のプロトコルを使用するネットワークハイパーバイザ１０２によりフローテーブルを適応するためのサポートを有するべきである。フローテーブルを変更する他の例示的な方法は、ネットワーキングチップセットプロバイダのＭａｒｖｅｌｌ又はＢｒｏａｄｃｏｍにより提供されたようなＳＤＫを使用すること、あるいはＪｕｎｉｐｅｒにより与えられたＯｐｅｎＪｕｎｏｓ ＡＰＩ等のスイッチベンダＡＰＩを使用することを含む。尚、いくつかの実施形態において及び本発明の態様に従って、既存のスイッチ及びルータは、トンネリングを使用することによりそれらのフローテーブルを調整することなく使用されてもよい。
【0034】
論理転送要素の容量は、個々の物理転送要素の容量を超えてもよい。従って、物理スイッチ／転送要素は、トラフィック分割動作（例えば、ＥＣＭＰ又はハッシング）及びリンク集約を提供し、複数の物理経路／リンクを介してトラフィックを分散するのが好ましい。最後に、リンク及びトンネルを効果的に監視するため、物理スイッチは、ハードウェアに基づくリンク及びトンネル監視プロトコルの実現例（ＢＦＤ等）を提供すべきである。これらの例に基づいて及び本明細書の全体的な説明から物理ネットワーク１０４で物理スイッチ及び他の要素を実現する方法は、当業者により理解されるだろう。
【0035】
実施形態において、ネットワークハイパーバイザ１０２の実現例がネットワーク状態に対してグローバルビューを有するように、ハイパーバイザの実現例は物理転送要素から切り離される。従って、ネットワークハイパーバイザ１０２は、それに応じてネットワーク１０４で全ての影響を受けたスイッチに対するマッピング及び／又はフローテーブルを調整することにより、状態がそのいずれかの側で変化する場合は常に含まれる必要がある。換言すると、物理ネットワーク上にネットワークトポロジイベントがある場合又は制御実現例が論理転送プレーンの状態を変化させる場合、ネットワークハイパーバイザ１０２はそれに関与される必要がある。更にハイパーバイザは、単独で定期的にリソース管理タスクを実行し、物理ネットワークリソースの使用を最適に維持する。
【0036】
次に、本発明の実施形態に従って論理インタフェース１０６の抽象概念を物理ネットワーク１０４にマッピングするために使用されるハイパーバイザ１０２の例示的なメカニズムを説明する。例えば、論理インタフェースにあるべきもの、すなわち例えば、インタフェースが示すべき論理転送要素の数及びそれらの相互接続の類似点を作成し、規定し且つ管理する別個の機構があると仮定する。
【0037】
使用された全ての物理スイッチが上述した全ての基本要素を提供すると仮定する場合、ハイパーバイザ１０２は、論理インタフェース抽象概念を物理ハードウェアにマッピングする間、達成すべき以下の２つの課題を有する。
【0038】
・個々の物理転送要素の潜在的に限られたスイッチング容量、並びに限られた数及び限られた容量のポート。
【0039】
・個々の物理転送要素のＴＣＡＭテーブルの潜在的に限られた容量。
【0040】
データセンタのコンテキストにおいて、ネットワークトポロジがファットツリーである可能性が高いため、ネットワークハイパーバイザのタスクは簡略化される。従って、オフライン負荷分散（例えば、ＥＣＭＰ）又はオンライン（例えば、ＴｅＸＣＰ）のいずれかにより実現されたマルチパスは、ネットワークトポロジのあらゆるポイント間に統一された容量を提供する。その結果、ネットワークハイパーバイザ１０２は、マッチング容量を含む物理転送要素を有することなく、超大容量の論理スイッチに対しても必要な容量を実現する。
【0041】
配置の問題：物理転送要素と関連付けられたＴＣＡＭテーブル容量がたいして重要な問題でない場合（特定の制御プレーンの実現例に対して）、ＴＣＡＭテーブル容量が全ての物理転送要素で全ての論理転送状態を有するため、ネットワークハイパーバイザのタスクは簡略化される。しかし、使用可能な物理ＴＣＡＭリソースがより不足している場合、ハイパーバイザ１０２は、よりインテリジェントに物理ネットワーク内で論理転送判断を配置しなければならない。物理ネットワーク要素が同等でなく（ＴＣＡＭサイズの点で）且つ物理ネットワーク要素のうちのいくつかが論理転送テーブルに対して十分な容量を有する展開において、ネットワークハイパーバイザ１０２は、論理転送判断に対してこれらの要素を使用してもよく、それらの間でパケットを転送するためだけに残りの要素を使用してもよい。大容量物理転送要素の厳密なトポロジ場所が展開特有の問題にされるが、それらを第１のホップ要素としてエッジに有すること又はコア（それらが共有される）にそれらを有することが妥当な出発点であることは、当業者には理解されるだろう。
【0042】
展開が完全な論理転送テーブルを保持できる物理転送要素を有さない場合、ハイパーバイザ１０２は、複数の物理要素にまたがるように問題の論理ルックアップステップを分割することにより、あるいは別個の論理ルックアップステップを実現するために別個の物理転送要素を使用することにより（論理転送が一連のステップである場合）、問題を区分する。どちらの場合でも、物理転送要素は、先の物理転送が停止した処理を継続するように次に必要なコンテキストを搬送する方法で、処理されたパケットを次の物理転送要素に送出すべきである。
【0043】
展開特有の制限が上記の２つの極値の間のどこかにある場合、ネットワークハイパーバイザ１０２は、最適な転送テーブルリソース使用と最適な物理ネットワーク帯域幅使用との間で明示的に妥協する。
【0044】
尚、最後に、全ての物理転送要素と同様に、論理転送テーブルに対して必要な容量を含む個々の要素の転送容量が制限因子となる場合、ハイパーバイザ１０２は、この制限を回避する複数のそのような要素を介して負荷分散を活用してもよい。
【0045】
図３に示す１つの特定の例示的な実現例において、本発明は、複数の仮想スイッチ及び物理スイッチを介して分散し、且つ新規な方法で速度、セキュリティ及び柔軟性の全てを組み合わせる分散仮想ネットワークプラットフォームを提供する。図３に示すように、本発明は、ＶＭが、同一のＬ２ネットワーク内にあるのと同様に効率的にホスト、並びに／あるいは仮想ＬＡＮ及び／又はサブネットを介して通信できるようにする分散仮想スイッチ（ＤＶＳ）１０８を提供する。更に本発明は、複数の分散仮想スイッチ１０８が同一の物理ホスト上又は同一のデータセンタ内でインスタンス化されることにより、複数のテナントが、互いにアドレス指定すること及び互いのリソースを消費することの双方から依然として隔離されたままで同一の物理ハードウェアを共有できるようにする。
【0046】
図３に示すように、組織（例えば、データセンタテナント）は、ホスト３００－Ａ～３００－Ｘを有するデータセンタのサービスを使用する複数の物理ホスト及びＶＭを有する。図示されるように、これらは、少なくともホスト３００－Ａ上のＶＭ３０２－１及び３０２－３、ホスト３００－Ｃ上のＶＭ３０２－４及びホスト３００－Ｄ上のＶＭ３０２－６を含む。データセンタは管理及び他の目的のために一般的なＶＬＡＮでこれらのＶＭを含もうとするが、ＶＭの数がデータセンタによりサポートされたＶＬＡＮサイズを超える場合、これは不可能になる。更にＶＬＡＮは、ＶＭが移動する時にネットワークの構成を必要とし、更なる機構なしではサブネットを介して拡張できない。
【0047】
図３に更に示されるように、場合によっては複数の異なるホスト３００上に更に分散された仮想スイッチ３０４及び物理スイッチ３０６は、これらの種々のＶＭが異なるホスト及び／又はＶＬＡＮ（すなわち、サブネット）上に配置される場合でもそれらが総合的に互いに通信し、且つ更に正規ホスト３０５（例えば、別個の外部顧客構内上にあってもよく、且つ／あるいはパブリックネットワーク又はプライベートネットワークを介してデータセンタのリソースに接続してもよいテナント組織の正規ユーザ）とも通信できるように単一の分散仮想スイッチ３０８として総合的に動作するために、本発明の仮想化レイヤ１０６及び／又はハイパーバイザ１０２により使用される。上述し且つ以下に更に詳細に説明するように、ハイパーバイザ１０２は、例えばＱＯＳ設定、ＡＣＬ、ファイアウォール、負荷分散等を構成することにより、仮想ネットワークを管理するために使用されてもよい。
【0048】
実施形態において、ハイパーバイザ１０２は、本発明の原理を用いて適応されるように、内容が参考として本明細書に取り入れられる同時係属出願第１２／２８６，０９８号において説明されるようなネットワークオペレーティングシステムを使用するコントローラにより実現される。しかし、他のＯｐｅｎＦｌｏｗ標準、あるいは他の自社開発のコントローラ又はオープンコントローラが使用されてもよい。ハイパーバイザ１０２及び／又は分散仮想スイッチ１０８は、全ての内容が参考として本明細書に更に取り入れられる米国特許出願第１１／９７０，９７６号において説明されたある特定の技術を更に活用する。
【0049】
仮想スイッチ３０４は、Ｃｉｓｃｏ及びＶＭｗａｒｅにより提供されるような市販されている仮想スイッチ又は他の自社開発の仮想スイッチを含む。仮想スイッチ３０４の殆ど又は全ては、ネットワークハイパーバイザ１０２と通信するためにＯｐｅｎＦｌｏｗ、あるいは他の標準的なプロトコルサポート又は自社開発のプロトコルサポートを含む。物理スイッチ３０６は、ネットワークハイパーバイザ１０２と通信するために上述したようなＯｐｅｎＦｌｏｗ、あるいは他の標準的なプロトコルサポート又は自社開発のプロトコルサポートを含むあらゆる市販されているスイッチ（例えば、ＮＥＣ（ＩＰ８８００）又はＨＰ（ＰｒｏＣｕｒｖｅ５４０６ＺＬ））又は自社開発のスイッチを含む。しかし、上述した本発明の実施形態及び以下の更なる説明において、ネットワークの既存の物理スイッチ３０６及びルータのうちのいくつか又は全ては、トンネリングを使用することによりフローテーブルに影響を及ぼすことなく使用される。
【0050】
図３に示すように、仮想スイッチ３０４は仮想機械３０２と通信し、物理スイッチ３０６は物理ホスト３０５と通信する。
【0051】
例えば例示的なホスト３００は、ＶＭｗａｒｅ ＥＳＸハイパーバイザを実行するサーバ（例えば、Ｄｅｌｌ、ＨＰ等）を含む。しかし、本発明はこの例示的な本実施形態に限定されず、他のオペレーティングシステム及び／又はハイパーバイザ等を使用して本発明の本実施形態及び同等の実施形態を実現する方法は、当業者には理解されるだろう。例えばこれらは、Ｃｉｔｒｉｘ ＸｅｎＳｅｒｖｅｒ、Ｌｉｎｕｘ（登録商標） ＫＶＭを含む。尚、ハイパーバイザ１０２により管理された組織に含まれた全ての物理ホストが何らかの仮想化ソフトウェアを実行する必要はない（例えば、ホスト３０５のうちのいくつか又は全て）。
【0052】
次に、図４に関連して、本発明の一実施形態に係る分散仮想スイッチ１０８の例示的な一実現例を説明する。上述したように、図４に示すような分散仮想スイッチ１０８は、基盤となる構成から切り離される論理抽象概念を提供するために、複数の従来の仮想スイッチ３０４及び物理スイッチ３０６を利用する。
【0053】
尚、図４に示すように、分散仮想スイッチ１０８は、基盤となるスイッチ３０４及び３０６のフローテーブルと同一であってもよくあるいは同一でなくてもよい自身のＬ２論理フローテーブル及びＬ３論理フローテーブルを含むのが好ましい。上述したように、これは、仮想化レイヤ１０６の制御プレーンで論理転送要素を実現するためである。
【0054】
図４に示すように、分散仮想スイッチ１０８により使用される仮想スイッチ及び物理スイッチの各々は、ネットワークハイパーバイザ１０２と通信するセキュアチャネルを含む。例えばこれは、ＯｐｅｎＦｌｏｗ標準（ｗｗｗ．ｏｐｅｎｆｌｏｗ．ｏｒｇを参照）を実現し、且つＯｐｅｎＦｌｏｗプロトコルを使用するコントローラと通信するように構成される通信モジュールである。しかし、他の自社開発のプロトコル及びオープンプロトコルが可能である。
【0055】
仮想スイッチ３０４及び物理スイッチ３０６の各々は、自身の論理フローテーブル及び物理フローテーブル、並びに入力パケットを論理コンテキストにマッピングするマッパーを更に含む（すなわち、単一の物理スイッチが複数の論理スイッチをサポートできるように）。これらは、ハイパーバイザ１０２により操作されるように、従来のスイッチで使用可能な標準的なフローテーブル及び転送エンジンを使用して実現される。換言すると、３０４及び３０６の既存の転送エンジンが上述した論理マッピング及び他のマッピングを実現するように、ハイパーバイザ１０２は既存のフローテーブルのエントリを調整する。本発明の影響を受けず、且つ従来の手段（例えば、ネットワーク管理、ポリシー、ルーティング要件等）を使用して作成及び維持される更なるフローテーブルエントリをスイッチ３０４及び３０６が有することが理解されるべきである。
【0056】
図４に更に示すように、種々のサブネットを介した通信をサポートし、且つフローテーブルを調整したことによる影響を受けない既存の物理スイッチ及び／又は仮想スイッチ、並びに物理ルータ及び／又は仮想ルータに更に適応させるために、分散仮想スイッチ１０８を実現するために本発明で使用されるある特定の物理スイッチ３０６及び仮想スイッチ３０４は、トンネルマネージャを含むのが好ましい。例示的な一実施形態において、トンネルマネージャは、仮想プライベートＬ２ブロードキャストドメインとして機能する仮想プライベートネットワーク（ＰＶＮ）の集合に対してＶＬＡＮ又は総称ルーティングカプセル化（ＧＲＥ（Generic Routing Encapsulation））トンネルを使用する。コントローラ１１０は、ＶＭ１０２を１つ以上の関連付けられたＰＶＮにマッピングするデータベースを維持する。ＰＶＮコントローラ１１０及び／又はスイッチ１０４の各々は、ブロードキャストパケット及び他のパケットが搬送されるホストに接続するＰＶＮトンネルの集合を作成し且つ維持する。このように、同一のＰＶＮのＶＭ１０２は、異なるＬ２ドメイン及び／又は異なるホストに存在す場合でも互いに通信する。また、ＰＶＮでホストと関連付けられた全てのＶＭは、ＰＶＮ内で他のホスト上のＶＭにより送出された全てのブロードキャストパケットを参照し、これらのパケットはそのＰＶＮの外側のいずれのホストによっても参照されない。
【0057】
当業者には理解されるように、本発明に従ってトンネルが作成される多くの種々の方法及び／又はトンネルマネージャ２０４を使用してＰＶＮを介してホストが相互接続される方法がある。
【0058】
本発明はその好適な実施形態を参照して特に説明されたが、本発明の趣旨及び範囲から逸脱せずに形態及び詳細の変更及び変形が行われてもよいことは、当業者には容易に明らかとなるべきである。添付の請求の範囲は、そのような変更及び変形を含むことを意図する。
【図1】
【図2】
【図3】
【図4】
