JP5763081B2 - 仮想化ネットワークインフラストラクチャを用いたトランスペアレントなクラウドコンピューティングのための方法および装置 - Google Patents

Description

本発明は、一般に、クラウドコンピューティングの分野に関し、より詳細には、しかし排他的にではなく、顧客ネットワークにトランスペアレントなクラウドコンピューティングを提供することに関する。

クラウドコンピューティングは、クラウドサービスプロバイダのクラウドリソースを、個人ユーザおよび企業を含み得るクラウドクライアントが利用できる、コンピューティングのパラダイムである。クラウドサービスプロバイダのクラウドリソースは、クラウドサービス、クラウドアプリケーション、クラウドプラットフォーム、およびクラウドインフラストラクチャなどの他、それらの様々な組み合わせも含むことができる。例えば、既存のクラウドコンピューティングソリューションは、中でも、Ａｍａｚｏｎ ＥＣ２、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ、およびＧｏｏｇｌｅ ＡｐｐＥｎｇｉｎｅを含む。

クラウドコンピューティングモデルは、特に個人ユーザと大企業の双方にとって有益性があるので、インターネットで提供されるサービスの景観を再編しつつある。例えば、特定のアプリケーションを実行するために追加のサーバの使用を必要とするサーバを有するホームネットワークのホームユーザの場合、ホームユーザは、追加のサーバを購入するコストを費やす必要なしに、代わりに、クラウドサービスプロバイダから仮想サーバを借用するだけなので、クラウドコンピューティングは、魅力的な選択肢である。例えば、リソース需要の変化に対応するために定期的に追加のリソースを必要とする既存のネットワークインフラストラクチャを有する、企業の場合、企業は、ハードウェア購入コストを費やす必要なしに、代わりに、クラウドリソースを実際に使用した分だけクラウドサービスプロバイダに支払いしさえすればよいので、クラウドコンピューティングは、魅力的な選択肢である。

しかし、不都合なことに、既存のクラウドコンピューティングモデルは、クラウドサービスプロバイダのリソースを顧客ネットワークの既存のリソースと効果的に統合するためのメカニズムを欠いている。むしろ、既存のクラウドコンピューティングモデルにおいては、顧客ネットワークによって使用されるクラウドベースのリソースから顧客ネットワークを切り分ける明確な境界が存在する。この境界は、クラウド内のデバイスと顧客ネットワーク内のデバイスとは、異なるＩＰアドレスドメイン内に存在し、したがって、クラウドサービスプロバイダによって利用されるＩＰアドレスドメインが、顧客ネットワークのＩＰアドレスドメインと重複する場合（特に顧客アプリケーションが、顧客ネットワークのリソースとクラウドサービスプロバイダのリソースの組み合わせを利用する場合）、衝突が生じるおそれがあることを主な理由として維持されている。

異なる顧客に物理的に別々のネットワークを提供すれば、ＩＰアドレスドメインの分離を保証することができるが、そのようなソリューションは、非常に非効率的で柔軟性に乏しく、したがって、クラウドサービスプロバイダのリソースを顧客ネットワークの既存のリソースと効果的に統合するためのメカニズムが必要とされている。

従来技術の様々な欠点は、データセンタの様々なリソースを顧客ネットワークの拡張として使用できるようにする、仮想化ネットワークインフラストラクチャを用いたトランスペアレントなクラウドコンピューティングをサポートする実施形態によって対処される。データセンタは、コアドメインと、複数のエッジドメインとを含む。エッジドメインは、データセンタのリソースをホストする。コアドメインは、データセンタ内における通信を円滑化する。エッジドメインは、転送要素を使用して、コアドメインとインターフェースを取り、同様に、顧客ネットワークも、転送要素を使用して、コアドメインとインターフェースを取る。転送要素は、データセンタの中央コントローラを使用して制御される。転送要素および中央コントローラは、顧客ネットワークがデータセンタのリソースを効率的、安全、トランスペアレントに使用することを可能にする方法で、顧客ネットワークに関連するパケットを転送するための様々な機能をサポートする。

本明細書の教示は、添付の図面と併せて、以下の詳細な説明を検討することによって、容易に理解できよう。

通信システムアーキテクチャの高レベルブロック図である。 送信元転送要素においてパケットを処理するための方法であって、パケットが、関連付けられた宛先転送要素を有する宛先エッジドメインにおいてホストされる仮想マシン宛てである方法の一実施形態を示す図である。 パケットの宛先である仮想マシンをホストするエッジドメインに関連付けられた転送要素においてパケットを処理するための方法であって、転送要素がエッジドメイン内におけるＣＮのＶＬＡＮのＶＬＡＮ ＩＤを常に決定すると仮定される方法の一実施形態を示す図である。 パケットの宛先である仮想マシンをホストするエッジドメインに関連付けられた転送要素においてパケットを処理するための方法であって、転送要素がエッジドメイン内におけるＣＮのＶＬＡＮのＶＬＡＮ ＩＤを常に決定するとは仮定されない方法の一実施形態を示す図である。 本明細書で説明される機能を実行する際に使用するのに適した汎用コンピュータの高レベルブロック図である。

理解し易くなるように、可能な場合には、図面に共通の同じ要素を指示するために、同じ参照番号が使用されている。

統合エラスティッククラウドコンピューティング（ｉＥＣ２：ｉｎｔｅｇｒａｔｅｄ Ｅｌａｓｔｉｃ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ）アーキテクチャが、本明細書で示され、説明される。ｉＥＣ２アーキテクチャは、クラウドコンピューティングリソースが、既存の顧客インフラストラクチャに対するトランスペアレントな拡張になることを可能にし、それによって、顧客アプリケーションが、既存の顧客インフラストラクチャにどのような変更も施すことなく、シームレスで柔軟な方法で、顧客コンピューティングリソースとクラウドコンピューティングリソースの両方を利用できるようにする。ｉＥＣ２アーキテクチャは、ネットワーク仮想化を使用して、クラウド内に顧客ネットワークの仮想的な拡張をインスタンス化することによって、クラウドコンピューティングリソースが、既存の顧客インフラストラクチャに対するトランスペアレントな拡張になることを可能にする。ｉＥＣ２アーキテクチャは、既存の顧客インフラストラクチャのどのような変更も必要とすることなく、クラウドコンピューティングリソースと既存の顧客インフラストラクチャとのシームレスな統合を可能にする。ｉＥＣ２アーキテクチャは、そのような拡張された顧客ネットワークが、需要に応じて増大および縮小できるようにし、それによって、一時的に必要になることがあるだけのネットワークインフラストラクチャを顧客が配備する必要性を排除する。ｉＥＣ２アーキテクチャは、クラウドコンピューティングリソースを非常に多数の顧客（例えば、少数の顧客にだけ対応できる既存のクラウドコンピューティングアーキテクチャではなく、ホームネットワークを有する個人顧客から企業ネットワークを有する大企業顧客にわたる任意のタイプの顧客）が利用できるような、高度にスケーラブルな方法で、クラウドコンピューティングリソースが、既存の顧客インフラストラクチャに対するトランスペアレントな拡張になることを可能にする。ｉＥＣ２アーキテクチャは、異なる顧客に応じたデータセンタの動的なカスタマイズ（例えば、データ転送、ポリシー制御、および同様の機能の動的なカスタマイズ）を可能にする。

ｉＥＣ２アーキテクチャは、ネットワーク仮想化を提供することを可能にする。ネットワーク仮想化は、２つのタイプのエンティティ：転送要素（ＦＥ）と中央コントローラ（ＣＣ）を使用して提供される。一般に、ＦＥは、パケットハンドリング機能（例えば、アドレスマッピング、ポリシーチェックおよび実施、ならびにパケット転送など）を実行し、一方、ＣＣは、パケットハンドリング機能を実行する際にＦＥが使用するために構成された制御情報（例えば、構成情報、アドレスマッピング、およびポリシーなど）を維持および提供する。ＦＥは、イーサネット（登録商標）スイッチをＣＣによってリモート制御することを可能にする拡張ＡＰＩを有する、イーサネットスイッチとして実施することができる。典型的なネットワーク仮想化ソリューションとは異なり、ｉＥＣ２アーキテクチャは、データセンタネットワーク全体にわたって、専用ルータまたはスイッチを配備する必要はなく、代わりに、仮想化機能を提供するために、ＦＥが、データセンタネットワークのある選択されたポイントにだけ配備され、データセンタネットワークの大部分では、従来の市販のイーサネットスイッチを使用することができる。

ｉＥＣ２アーキテクチャは、データセンタネットワーク内において階層化ネットワーク構造を利用し、複数のエッジドメインが、中央のコアドメインを介して通信する。各エッジドメインは、１つまたは複数のスイッチを介して接続される、（エッジドメイン内でクラウドコンピューティングリソースを提供するための）物理ホストを含む。各エッジドメインは、（例えば、パケットを転送すべきエッジドメイン／レイヤ２アドレスを解決するための）パケットアドレスの解決、エッジドメイン内における異なる顧客のパケットの分離、（例えば、エッジドメイン内においてローカルに転送するか、それとも別のエッジドメインに向けて転送するためにコアドメインに向けて転送するかなど）意図する宛先に基づいたパケットの転送の決定、ならびにポリシーチェックおよび実施など、多くの機能を提供する。各エッジドメインは、１つまたは複数のＦＥを介して、コアドメインに接続される（すなわち、ＦＥは、エッジドメインとコアドメインの間のゲートウェイとして配備され、ＣＣは、ＦＥに構成機能および制御機能を提供するためにＦＥと通信する目的で、コアドメインに関連付けられる）。顧客ネットワークは、エッジドメインの特別なインスタンスとして扱うことができ、その場合、各顧客ネットワークは、１つまたは複数のＦＥを介して、データセンタネットワークにアクセスすることができる（そのようなＦＥは、顧客向きＦＥ（ｃｕｓｔｏｍｅｒ−ｆａｃｉｎｇ ＦＥ、ＣＮ向きＦＥ）と呼ばれ、顧客ネットワークをローカルなＬＡＮと見なす）。ＦＥは、ＦＥを通過するパケットのポリシーに従った扱いを提供するための、ファイアウォールおよびロードバランサなど、ＦＥに関連付けられた処理デバイスを有することができる。コアドメインは、エッジドメイン間でパケットを転送するために構成された、フラットなレイヤ２ネットワークとすることができる。

ｉＥＣ２アーキテクチャでは、顧客は、他の顧客の仮想ネットワークから分離された、１つまたは複数の仮想ネットワークを提供される。顧客の仮想ネットワークは、１つのエッジドメイン内で提供することができ、または顧客から隠蔽された下層ドメイン構造を用いて、複数のエッジドメインにわたって分散することができる。各エッジドメインでは、エッジドメイン内のリソースを利用している異なる顧客を分離するために、ＶＬＡＮが、エッジドメイン内においてローカルに利用され、さらに、ＶＬＡＮ ＩＤは、エッジドメインにわたって再使用され、それによって、データセンタネットワークによってサポートできる顧客の数を著しく増加させることが可能である。顧客ネットワークが複数のエッジドメインにまたがる場合、顧客ネットワークには、複数のエッジドメインの各々において、異なるＶＬＡＮ ＩＤを割り当てることができ、パケットがエッジドメイン間で転送される場合、そのようなＶＬＡＮ ＩＤは、エッジドメインとコアドメインの間のゲートウェイＦＥによって再マッピングされる。

本明細書で説明されるように、ｉＥＣ２アーキテクチャは、クラウドコンピューティングリソースと顧客ネットワークとのシームレスな統合を可能にし、それによって、顧客ネットワークを変更することなく、顧客がクラウドコンピューティングリソースを利用できるようにする。クラウドコンピューティングリソースと顧客ネットワークとのシームレスな統合は、データセンタネットワーク内において顧客ネットワークを論理的に分離するためのアドレッシング方式を使用して、達成することができる。そのようなアドレッシング方式の例示的な一実施形態が、以下で説明される。

アドレッシング方式は、異なる顧客を区別するためのメカニズムを含み、そのメカニズムによって、各顧客ネットワークには、（本明細書でｃｎｅｔ識別子と呼ばれる）一意的な顧客ネットワーク識別子が割り当てられる。顧客が単一のＶＬＡＮを有する場合、ｃｎｅｔ識別子は、顧客も識別する。顧客が複数のＶＬＡＮを有する場合、各ＶＬＡＮに対して異なるｃｎｅｔ識別子を使用することで、顧客のＶＬＡＮ構造を維持できることが保証される（これは、異なるＶＬＡＮに異なるポリシー制御が適用可能である場合などに、望ましいことがあり、または必要なことさえある）。このようにして、（ｃｎｅｔ識別子，ＩＰアドレス）の組み合わせを使用して、論理的に、仮想マシンを識別することができる。（ｃｎｅｔ識別子，ＩＰアドレス）の組み合わせは、仮想マシンのための一意的なレイヤ２ ＭＡＣアドレスにマッピングされる。仮想ＭＡＣアドレスの仮想マシンへの割り当てをサポートするホスト仮想化プラットフォームでは、仮想マシンのための一意的なレイヤ２ ＭＡＣアドレスは、物理サーバ上で他の仮想マシンをホストできる場合であっても、仮想マシンを直接的に識別する。仮想ＭＡＣアドレスの仮想マシンへの割り当てをサポートしないホスト仮想化プラットフォームでは、仮想マシンに割り当てられるレイヤ２ ＭＡＣアドレスは、物理サーバに割り当てられるＭＡＣアドレスと同じであり、したがって、物理サーバ上で仮想マシンを識別する目的で、追加の識別子が必要とされる。この場合、追加の識別子は、仮想マシンのために生成される疑似ＭＡＣアドレスとすることができ、疑似ＭＡＣアドレスは、パケット転送目的ではなく、仮想マシン識別目的で使用される。

アドレッシング方式は、各エッジドメイン内において異なる顧客を分離するためのメカニズムを含む。レイヤ２およびレイヤ３アドレスを使用するのに加えて、各エッジドメイン内において異なる顧客を分離するために、ＶＬＡＮが使用される。各エッジドメインでは、各顧客は、異なるＶＬＡＮにマッピングされる。顧客が、クラウドコンピューティングサービスを使用する複数のＶＬＡＮを有する場合、顧客の内部ＶＬＡＮの各々は、エッジドメインにおいて異なるＶＬＡＮにマッピングされる。エッジドメイン毎に、エッジドメインに関連付けられたＦＥ １２０において、エッジドメイン内においてパケットを転送するために使用するイーサネットスイッチにおいて、およびエッジドメイン内の物理サーバのホストハイパーバイザにおいて、ＶＬＡＮ構成が実行される。エッジドメインにおけるＶＬＡＮ構成は、仮想マシン上で動作するアプリケーションがＶＬＡＮ構成に気づかないように、仮想マシンにはトランスペアレントである。

アドレッシング方式は、エッジドメインがＶＬＡＮ ＩＤを再使用できるようにするためのメカニズムを含む。ＶＬＡＮタグ付け範囲は、エッジドメイン内に限定される。エッジドメインがＶＬＡＮ ＩＤを再使用できるようにすることによって、データセンタネットワークによって対応できる顧客の数に対する制限が取り除かれる。この設計は、各エッジドメインにおいてサポートできる仮想マシンの数には暗黙的に制限を課すが（一般に、多くの顧客が複数の仮想マシンを使用する可能性が高いので、エッジドメインは４０００個より多くの仮想マシンをサポートできる可能性が高いが、例えば、エッジドメインにおいて各仮想マシンが異なる顧客に属する最悪ケースでは、各エッジドメインには最大で４０００個の仮想マシンしか存在することができない）、データセンタ内においてサポートできるエッジドメインの数に対する制限は存在せず、したがって、サポートできる顧客の数に対する制限は存在しない。

上述のアドレッシング方式は、クラウドコンピューティングリソースと顧客ネットワークとのシームレスな統合を可能にすると同時に、顧客ネットワークを分離し、顧客それぞれのＩＰアドレス空間の維持を可能にする。これは、異なる顧客のサーバが同じＩＰアドレスを利用する場合であっても、データセンタ内において各顧客に対して物理的に別個のネットワークを使用する必要なしに、異なる顧客のサーバを区別できることを保証する。

顧客ネットワークのどのような変更も必要としない方法で、クラウドコンピューティングリソースと顧客ネットワークとのシームレスな統合を可能にするｉＥＣ２アーキテクチャを依然として提供しながら、上述のアドレッシング方式を変更することができる。

上述のアドレッシング方式は、図１に関して示され、説明される例示的なｉＥＣ２アーキテクチャを参照することで、より良く理解することができる。

ｉＥＣ２アーキテクチャの上記の説明は、ｉＥＣ２アーキテクチャを紹介する目的で提供された一般的な説明にすぎず、したがって、ｉＥＣ２アーキテクチャは、この説明を考慮することによって、限定されることはない。ｉＥＣ２アーキテクチャおよび様々な関連する実施形態が、以下でより詳細に説明される。

図１は、通信システムアーキテクチャの高レベルブロック図を示している。図１に示されるように、通信システムアーキテクチャ１００は、複数の顧客ネットワーク（ＣＮ）１０２_Ａ−１０２_Ｃ（一括してＣＮ １０２）にクラウドコンピューティングリソースを提供するデータセンタ（ＤＣ）１０１を含む、例示的なｉＥＣ２アーキテクチャである。

データセンタ１０１は、（例えば、顧客がクラウドコンピューティングリソースをリースまたは購入できる場合に）顧客が使用するために利用可能とすることができる、クラウドコンピューティングリソースを含む。クラウドコンピューティングリソースは、クラウドコンピューティングリソースが顧客の顧客ネットワークの拡張であると見なされるように、それらの顧客に提供される。クラウドコンピューティングリソースは、処理能力およびメモリなどの他、それらの様々な組み合わせなど、顧客に利用可能とすることができる任意のタイプのコンピューティングリソースを含むことができる。

データセンタ１０１は、顧客によるクラウドコンピューティングリソースの使用を円滑化する際に使用するために構成されたネットワークインフラストラクチャを含む。ＤＣ １０１は、複数のエッジドメイン（ＥＤ）１１０_１−１１０_３（一括してＥＤ １１０）と、複数の転送要素（ＦＥ）１２０_１−１２０_３（一括してＦＥ １２０）と、コアドメイン（ＣＤ）１３０とを含む。ＤＣ １０１は、中央コントローラ（ＣＣ）１４０と、任意選択的に、管理システム（ＭＳ）１５０も含む。ＤＣ １０１の様々な要素は、顧客がＤＣ １０１から入手可能なクラウドコンピューティングリソースを利用できるようにするための様々な機能を実行するために協力する。

ＣＮ １０２は、ＣＮ １０２を変更することなく、ＤＣ １０１のクラウドコンピューティングリソースを利用することができる。ＣＮ １０２は、例えば、個人顧客のホームネットワークから大企業顧客の企業ネットワークまで、任意のタイプの顧客ネットワークを含むことができる。言い換えると、ＣＮ １０１は、ＤＣ １０１のクラウドコンピューティングリソースを使用できる任意の顧客ネットワークとすることができる。ＣＮ １０２は、ＤＣ １０１のＦＥ １２０の１つまたは複数を使用して、ＤＣ １０１にアクセスする。

ＣＮ １０２がクラウドコンピューティングリソースにアクセスできるようにする、ＤＣ １０１の様々なコンポーネントが、以下で説明される。

ＥＤ １１０は、ＤＣ １０１によってサポートできるＣＮ １０２の数の著しい増加を可能にする。本明細書で説明されるように、各ＥＤ １１０は、他のＥＤ １１０の各々とは独立に、顧客のために１組のＶＬＡＮをサポートすることが可能である。このようにして、サポートできるＶＬＡＮの数（したがって、サポートできるＣＮ １０２の数）によって、ＤＣ １０１が制約される代わりに、サポートできるＶＬＡＮの数、したがって、サポートできるＣＮ １０２の数によって、個々のＥＤ １１０の各々だけが制約されるが、ＤＣ １０１の観点からすれば、任意の数のＥＤ １１０がＤＣ １０１によってサポートできるので、サポートできるＣＮ １０２の数に対するＥＤ毎の制限は、形だけのものである。

各ＥＤ １１０は、ＣＮ １０２に関連付けられた、顧客が使用するための物理サーバ１１２を含む（例示的には、ＥＤ １１０_１は、２つの物理サーバ１１２_１−１、１１２_１−２を含み、ＥＤ １１０_２は、２つの物理サーバ１１２_２−１、１１２_２−２を含み、ＥＤ １１０_３は、２つの物理サーバ１１２_３−１、１１２_３−２を含み、物理サーバは、一括して物理サーバ１１２と呼ばれる）。各物理サーバ１１２は、ＣＮ １０２が利用できるクラウドコンピューティングリソースをホストする。物理サーバ１１２は、そのようなクラウドコンピューティングリソースをサポートするのに適した任意のサーバとすることができ、ＣＮ １０２が使用するために利用可能とすることができるクラウドコンピューティングリソースのタイプに依存することができる。

各ＰＳ １１２は、ＣＮ １０２が利用できる、１つまたは複数の仮想マシン（ＶＭ）１１３を含む。各ＰＳ １１２が複数のＶＭ １１３をサポートする場合、ＰＳ １１２のＶＭ １１３は、物理サーバ１１２上で異なる顧客ネットワークを論理的に分離するのに（したがって、トランスペアレント、安全、コスト効果的な方法で、異なる顧客が使用するために同じ物理ハードウェアの異なる部分を利用可能にするのに）適した任意の仮想化技法を使用して、実施することができる。

ＶＭ １１３は、ＰＳ １１２上に構成される仮想マシンである。ＶＭ １１３は、ＣＮ １０２が使用するために、ＰＳ １１２上に構成できるクラウドコンピューティングリソースを提供する。クラウドコンピューティングリソースは、プロセッサリソースおよびメモリリソースなどの他、それらの様々な組み合わせなど、ＣＮ １０２が利用できる任意のリソースを含む。

図１の例示的なネットワークでは、３つの顧客が、３つの顧客のＣＮ １０２が使用するための、ＤＣ １０１内にプロビジョニングされたＶＭ １１３を有する。第１のＣＮ １０２_Ａは、ＤＣ １０１内にプロビジョニングされた４つのＶＭ １１３（すなわち、ＥＤ １１０_１のＰＳ １１２_１−１上に２つのＶＭ １１３、ＥＤ １１０_１のＰＳ １１２_１−２上に１つのＶＭ １１３、およびＥＤ １１０_２のＰＳ １１２_２−１上に１つのＶＭ １１３）を有する。第２のＣＮ １０２_Ｂは、ＤＣ １０１内にプロビジョニングされた４つのＶＭ １１３（すなわち、ＥＤ １１０_１のＰＳ １１２_１−２上に１つのＶＭ １１３、ＥＤ １１０_２のＰＳ １１２_２−１上に１つのＶＭ １１３、ＥＤ １１０_２のＰＳ １１２_２−２上に１つのＶＭ １１３、およびＥＤ １１０_３のＰＳ １１２_３−２上に１つのＶＭ １１３）を有する。第３のＣＮ １０２_Ｃは、ＤＣ １０１内にプロビジョニングされた２つのＶＭ １１３（すなわち、ＥＤ １１０_３のＰＳ １１２_３−１上に２つのＶＭ １１３）を有する。これらの例示的な顧客から、ＶＭ １１３をＤＣ １０１内に多くの異なる構成でプロビジョニングできることが理解されよう（例えば、顧客は、１つの物理サーバ、同じエッジドメイン内の複数の物理サーバ、および異なるエッジドメインにわたる複数の物理サーバなどを利用することができ、さらに、顧客は、任意の与えられた物理サーバ上で１つまたは複数の仮想マシンを利用することができる）。

各ＥＤ １１０は、ＥＤ １１０内においてパケットをルーティングするための通信インフラストラクチャを含む。一実施形態では、ＥＤ １１０は、ＥＤ １１０内においてパケット転送を実行するために、スイッチを利用することができる。例えば、各ＥＤ １１０は、１つまたは複数のイーサネットスイッチを利用することができる。一実施形態では、各ＥＤ １１０内のスイッチは、異なる顧客のために異なるＶＬＡＮを扱う必要があるので、各ＥＤ １１０内のスイッチは、（例えば、ＥＤ １１０にそれぞれ関連付けられたＦＥ １２０でルーティングされる）従来のツリーベースのトポロジで構成することができる。ＥＤ １１０は、他のタイプのネットワーク要素および他の関連する通信機能を使用して実施できることが理解されよう。

各ＥＤ １１０は、それに関連付けられた１つまたは複数のＦＥ １２０を有する。ＦＥ １２０は、ＥＤ １１０とＣＤ １３０の間のゲートウェイとして動作する。ＤＣ １０１内においてネットワーク仮想化機能をサポートするためには、ＥＤ １１０当たり１つのＦＥ １２０で十分であるが、ロードバランシングおよび信頼性の改善などを目的として、ＥＤ １１０とＣＤ １３０とのインターフェースのために、複数のＦＥ １２０を使用できることが理解されよう。

ＦＥ １２０は、ＤＣ １０１に関連するパケットのために、パケットハンドリング機能（例えば、アドレスルックアップおよびマッピング、ポリシーチェックおよび実施、ならびにパケット転送およびトンネリングなど）を実行する。ＦＥ １２０は、ＣＮ １０２とＣＤ １３０の間およびＥＤ １１０とＣＤ １３０の間のゲートウェイとして機能する。ＦＥ １２０は、ＣＮ向きＦＥ（例示的に、ＣＮ １０２の各々のためにＤＣ １０１においてゲートウェイとして動作するＦＥ １２０_４）と、ＥＤ向きＦＥ（例示的に、ＥＤ １１０_１、１１０_２、１１０_３とＣＤ １３０の間のゲートウェイとしてそれぞれ動作するＦＥ １２０_１、１２０_２、１２０_３）とを含む。ＣＮ １０２およびＥＤ １１０のために通信を円滑化する際のＦＥ １２０の動作が、以下でさらに詳細に説明される。

ＦＥ １２０は、アドレスルックアップおよびマッピング機能を実行する。アドレスルックアップおよびマッピングは、ＦＥ １２０のローカルストレージ内に記憶されたマッピング情報を使用してＦＥ １２０によって、および／または（例えば、必要なマッピング情報が、ＦＥ １２０のローカルストレージから入手可能ではない場合などには）必要なマッピング情報をＣＣ １４０に要求することによって、実行することができる。ローカルに記憶できるマッピング情報および／またはＣＣ １４０に要求できるマッピング情報は、（例えば、本明細書ではＣＣ １４０によって維持されると説明される、仮想マシンＭＡＣ⇔（ｃｎｅｔ識別子，ＩＰアドレス）マッピング、仮想マシンＭＡＣ⇔エッジドメイン識別子マッピング、エッジドメイン識別子⇔ＦＥ ＭＡＣリストマッピング、および（ｃｎｅｔ識別子，エッジドメイン識別子）⇔ＶＬＡＮ識別子マッピングなど）パケットハンドリング機能を実行するために必要とされる任意のマッピング情報を含む。

ＦＥ １２０は、ポリシーチェックおよび実施機能を実行することができる。ポリシーは、データセンタ事業者によって実施される全般的ポリシー、および／または顧客のために実施される顧客ポリシーとすることができる。ポリシーチェックおよび実施機能は、ポリシー情報を使用して提供することができ、ポリシー情報は、ＦＥ １２０上にローカルに記憶することができ、および／または（例えば、必要なポリシー情報がＦＥ １２０上でローカルに入手可能でない場合には）ＦＥ １２０によってＣＣ １４０に要求することができる。例えば、ＦＥ １２０は、パケットの送信元および宛先について、ＭＡＣアドレス、ＩＰアドレス、およびＶＬＡＮ ＩＤなどに矛盾がないことを保証するために、パケットを処理することができる。例えば、ＦＥ １２０は、顧客ポリシー（例えば、配送前にパケットをファイアウォールに転送すること、ロードバランサを利用することなど）を適用することができる。ＦＥ １２０が、他の任意の適切なデータセンタ事業者ポリシーおよび／または顧客ポリシーをチェックおよび実施できることが理解されよう。

ＦＥ １２０は、パケット転送機能を実行する。アドレスルックアップおよびマッピング機能は、パケット転送機能と併せて利用することができる。例えば、ＦＥ １２０は、ＣＮ １０２から発信されたパケットをＤＣ １０１内の仮想マシンによって処理する目的で転送すること、ＤＣ １０１内の仮想マシンから発信されたパケットをＣＮ １０２宛てに転送すること、ＤＣ １０１内の仮想マシンから発信されたパケットをＤＣ １０１内の他の仮想マシン宛てに転送すること、（例えば、プロビジョニング情報およびマッピング情報などを伝えるパケットなど）ＤＣ １０１内において交換される制御パケットを転送することなどができる。

これらの例示的なパケットフローから分かるように、ＦＥ １２０は、ＥＤ １１０からパケットを受信し、ＣＤ １３０を介してパケットを転送すること、ＣＤ １３０からパケットを受信し、ＥＤ １１０にパケットを転送すること、およびＥＤからパケットを受信し、同じＥＤ １１０内にパケットを転送し戻すことなどができる。ＦＥ １２０は、任意の適切なパケット転送機能を使用して、そのようなパケット転送を実行することができる。

一実施形態では、ＣＤ １３０を介して宛先ＥＤ １１０に転送するためにＣＮ １０２またはＥＤ １１０からパケットを受信した送信元ＦＥ １２０は、トンネリングを使用して、パケットにＣＤ １３０をトンネリングさせる。そのような一実施形態では、送信元ＦＥは、ＭＡＣ−ｉｎ−ＭＡＣトンネリングを使用して、パケットにトンネリングさせる。ＭＡＣ−ｉｎ−ＭＡＣトンネリングでは、送信元ＦＥ １２０が、外側ＭＡＣヘッダをイーサネットフレームに追加し（イーサネットフレームのヘッダが内側ヘッダとなる）、変更されたイーサネットフレームは、外側ＭＡＣヘッダを使用して、ＣＤ １３０のイーサネットスイッチによってルーティングされ、宛先ＦＥ １２０が、外側ＭＡＣヘッダを除去する。ほとんどのイーサネットスイッチは、外側ＭＡＣヘッダの追加バイトが、ＣＤ １３０内で（特に、すべてのＥＤ １１０のトラフィック要求を満たすために、より高容量のイーサネットスイッチを配備できるＣＤ １３０内で）、どのような問題も引き起こさないように、より大きなフレームサイズの使用を可能にすることが理解されよう。他の任意の適切なタイプのトンネリングも使用できることが理解されよう。

一実施形態では、ＦＥ １２０が関連付けられたＥＤ １１０内における（例えばＶＭ １１３への）配送のためにパケットを受信したＦＥ １２０は、ＶＭ １１３のＭＡＣアドレス、ＶＭ １１３のＩＰアドレス、およびパケットが関連付けられたＣＮ １０２のＶＬＡＮ ＩＤを使用して、ＥＤ １１０内においてパケットを転送する。パケットは、ＦＥ １２０とＥＤ １１０内でホストされるＶＭ １１３との間の通信を円滑化するためにＥＤ １１０内に配備された１つまたは複数のイーサネットスイッチによって、ＥＤ １１０を介してルーティングすることができる。このタイプのパケット転送は、ＣＤ １３０を介してＦＥ １２０において受信したパケットに対して、およびＦＥ １２０が関連付けられたＥＤ １１０内から発信されたパケット（すなわちＥＤ内通信）に対して実行できることが理解されよう。

ＦＥ １２０は、そのような機能を実行するのに適した任意の情報を使用して、そのような機能を実行する。上で指摘されたように、ＦＥ １２０は、任意の適切な方法で、そのような情報にアクセスすることができる。例えば、ＦＥ １２０は、そのような情報（例えば、パケット転送エントリおよび顧客ポリシー規則など）をローカルに記憶することができ、ならびに／またはそのような情報をそのような情報の１つもしくは複数のリモートソースから（例えば、他のＦＥ １２０とのシグナリングおよびＣＣ １４０への要求を介するなどして）受信することができる。

ＦＥ １２０は、アドレスルックアップおよびマッピング機能、ポリシーチェックおよび実施機能、ならびにパケット転送機能に加えて、他の様々な機能をサポートすることができる。

ＦＥ １２０は、任意の適切な方法で実施することができる。一実施形態では、ＦＥ １２０は、スイッチとして実施することができる。そのような一実施形態では、例えば、ＦＥ １２０は、そのような機能をサポートする高容量イーサネットスイッチとして実施することができる。ＦＥ １２０は、ＣＣ １４０によってＦＥ １２０をリモートに制御できるようにするために構成された拡張ＡＰＩをサポートすることもできる。

一実施形態では、ＦＥ １２０の１つまたは複数は、様々なパケット処理機能を実行する際に使用するために、ＦＥ １２０に関連付けられた１つまたは複数の追加のネットワーク要素（例えば、ファイアウォールおよびロードバランサなど）を有することができる。例えば、ＦＥ １２０_１は、パケットを処理する（例えば、ＤＣ １０１内においてパケットをルーティングする前に、ＣＮ １０２から受信したパケットを処理する）際に使用するために、ＦＥ １２０_１に関連付けられたファイアウォールおよびロードバランサを有し、ＦＥ １２０_４は、パケットを処理する（例えば、ＥＤ １１０_１内においてパケットをルーティングする前に、ＣＤ １２０からＦＥ １２０_１において受信したパケットを処理し、および／またはＣＤ １２０に向けてパケットをルーティングする前に、ＥＤ １１０_１からＦＥ １２０_１において受信したパケットを処理する）際に使用するために、ＦＥ １２０_４に関連付けられたファイアウォールおよびロードバランサを有する。

ＣＤ １３０は、ＤＣ １０１内での通信を円滑化する。ＣＤ １３０は、ＦＥ １２０に関連する通信を円滑化する。例えば、ＣＤ １３０は、ＣＮ １０２とＥＤ １１０の間の通信、ＥＤ １１０間の通信、ＦＥ １２０間の通信、ならびに（例えば、ＦＥ １２０とＣＣ １４０の間およびＦＥ １２０とＭＳ １５０の間など）ＦＥ １２０とデータセンタコントローラの間の通信などの他、それらの様々な組み合わせを円滑化する。ＣＤ １３０は、ＣＣ １４０とＤＣ １０１の他のコンポーネント（例えば、ＦＥ １２０およびＶＭ １１３など）の間の通信、ならびに任意選択的に、ＭＳ １５０とＤＣ １０１の他のコンポーネント（例えば、ＦＥ １２０およびＶＭ １１３など）の間の通信も円滑化する。

ＣＤ １３０は、ＣＤ １３０内においてパケットをルーティングするための通信インフラストラクチャを含む。ＣＤ １３０は、任意の適切な方法で実施することができる。一実施形態では、ＣＤ １３０は、ＣＤ １３０内においてパケット転送を実行するために、スイッチを利用する。そのような一実施形態では、例えば、ＣＤ １３０は、１つまたは複数のイーサネットスイッチを利用することができる。ＣＤ １３０内のスイッチは、主としてパケット転送のために使用されるので、ＣＤ １３０のスイッチング構成の設計は、どのようなポリシーによっても制限されないことが理解されよう。一実施形態では、より良いリソース使用を保証するために、最短経路フレームルーティング、または複数の経路の使用を可能にする他の適切な方式を、ＣＤ １３０内において実施することができる。ＣＤ １３０は、他の任意の適切なタイプのネットワーク要素および関連する通信機能を使用して実施できることが理解されよう。

ＣＣ １４０は、ＦＥ １２０がＤＣ １０１にパケット転送機能を提供できるようにするために、ＦＥ １２０と協力する。ＣＣ １４０は、ＤＣ １０１のコンピューティングリソースを求める顧客要求をサポートするためにＦＥ １２０をプロビジョニングする際に使用するためのプロビジョニング情報を決定することができ、そのようなプロビジョニング情報をＦＥ １２０に提供することができる。ＣＣ １４０は、ＤＣ １０１のためのパケットを転送する際にＦＥ １２０が使用するために構成されたマッピング情報を維持することができ、そのようなマッピング情報をＦＥ １２０に提供することができる。ＣＣ １４０は、ＤＣ １０１のためのパケットを転送しながら顧客ポリシーを実施する際にＦＥ １２０が使用するために構成されたポリシー情報を維持することができ、そのようなポリシー情報をＦＥ １２０に提供することができる。

一実施形態では、ＣＣ １４０は、ＤＣ １０１のためのパケットを転送する際にＦＥ １２０が使用するために構成された以下のマッピング情報を維持する：
（１）仮想マシンＭＡＣ⇔（ｃｎｅｔ識別子，ＩＰアドレス）マッピング：このマッピングは、ＶＭ １１３のＭＡＣアドレスを、ＶＭ １１３がそれのためにプロビジョニングされる顧客の顧客ネットワーク識別子（ｃｎｅｔ識別子）とＶＭ １１３のＩＰアドレスの組み合わせにマッピングする。各顧客がそれ独自の独立のＩＰ空間を有する場合、（ｃｎｅｔ識別子，ＩＰアドレス）も、ＶＭ １１３を一意的に識別する。

（２）仮想マシンＭＡＣ⇔エッジドメイン識別子マッピング：このマッピングは、ＶＭ １１３のＭＡＣアドレスを、そのＶＭ １１３がその中でホストされるＥＤ １１０の識別子にマッピングする。上で言及されたように、ＣＮ １０２は、特別なエッジドメインと見なされ、したがって、各ＣＮ １０２にも、エッジドメイン識別子が割り当てられる。

（３）エッジドメイン識別子⇔ＦＥ ＭＡＣリストマッピング：このマッピングは、ＥＤ １１０が接続するＦＥ １２０のＭＡＣアドレス間の関連付けを維持する。上で言及されたように、例えば、ロードバランシング理由および信頼性理由などのために、ＥＤ １１０は、複数のＦＥ １２０を有することが可能である。

（４）（ｃｎｅｔ識別子，エッジドメイン識別子）⇔ＶＬＡＮ識別子マッピング：（顧客は複数のＥＤ １１０内のＶＭ １１３にアクセスできるので）このマッピングは、顧客ネットワーク識別子とエッジドメイン識別子の組み合わせを、顧客のためのＶＬＡＮ識別子にマッピングする。言い換えると、各ＣＮ １０２には、顧客の１つまたは複数のＶＭ １１３を有する各ＥＤ １１０においてＶＬＡＮ識別子が割り当てられ、与えられたＣＮ １０２のためのＶＬＡＮ識別子は、異なるＥＤ １１０では異なることができる。ＤＣ １０１におけるＶＬＡＮ識別子は、ＣＣ １４０によって割り当てることができる（またはそのような割り当てを実行するのに適した他の任意の要素によって割り当てることができる）。ＣＮ １０２において使用されるＶＬＡＮ識別子は、それぞれの顧客によって割り当てられる。

一実施形態では、ＣＣ １４０によって維持されるこのマッピング情報の少なくとも一部は、ＦＥ １２０が、そのようなマッピング情報を求めてＣＣ １４０に絶えず問い合わせることを必要とせず、パケット転送を実行するためにそのようなマッピング情報をローカルで利用できるように、各ＦＥ １２０内にも記憶することができる。

一実施形態では、ＣＣ １４０は、ＤＣ １０１のためのパケットを転送しながら顧客ポリシーを実施する際にＦＥ １２０が使用するために構成されたポリシー情報を維持する。ポリシーは、任意の適切なポリシー規則を含むことができる。例えば、顧客のためのポリシー規則は、すべてのパケットは、宛先に転送される前に、最初に関連するＣＮ向きＦＥ １２０からファイアウォールに転送されなければならないとすることができる。この場合、このポリシーを実施する送信元ＦＥ １２０は、パケットが最終的に宛先ＦＥ １２０に向けて転送される前に、パケットをファイアウォールまでトンネリングさせる。

ＣＣ １４０は、任意の適切な方法で（例えば、１つまたは複数のデータベースを使用して情報を維持する、任意の適切なフォーマットで情報を記憶するなどの他、それらの様々な組み合わせで）、情報を維持することができる。ＣＣ １４０は、任意の適切な方法で、例えば、定期的に、ＦＥ １２０からの問い合わせに応答してなどの他、それらの様々な組み合わせで、ＦＥ １２０に情報を提供することができる。

本明細書では、主として、ＤＣ １０１内における単一のＣＣ １４０の使用に関して示され、説明されたが、ＤＣ １０１内においてＣＣ １４０の機能を提供するために、標準的な信頼性技法およびスケーラビリティ技法を使用できることが理解されよう。ＣＣ １４０の機能は、任意の適切な方法で分散させることができる。一実施形態では、例えば、異なるＣＣによって、異なるＥＤ １１０を管理することができる。一実施形態では、例えば、異なる顧客には、（例えば、分散ハッシュテーブル（ＤＨＴ）を使用して）異なるＣＣを割り当てることができる。管理およびポリシー制御は、異なる顧客ネットワークに対して相対的に独立であるので、ＣＣ １４０の機能のそのような区分は、ＣＣ １４０の機能に影響しないことが理解されよう。

一実施形態では、ＦＥ １２０とＣＣ １４０は、分散ルータとして協力し、ＦＥ １２０は、簡略化されたパケット転送要素であり、ＣＣ １４０は、ＦＥ １２０の中央集中制御を提供する。そのような分散ルータアーキテクチャの使用は、ＤＣ １０１に様々な利点を提供し、ＤＣ １０１内におけるリソースおよびポリシーの管理を簡素化する。一実施形態では、ＦＥ １２０とＣＣ １４０は、参照によってその全体が本明細書に組み込まれる、２００９年６月２２日に出願された、「ＰＲＯＶＩＤＩＮＧ ＣＬＯＵＤ−ＢＡＳＥＤ ＳＥＲＶＩＣＥＳ ＵＳＩＮＧ ＤＹＮＡＭＩＣ ＮＥＴＷＯＲＫ ＶＩＲＴＵＡＬＩＺＡＴＩＯＮ」と題する、米国特許出願第１２／４８９，１８７号に示され、説明されているような、ＶＩＣＴＯＲを一緒になって形成する。

ＭＳ １５０は、顧客がそれによってＤＣ １０１のコンピューティングリソースを要求できる、顧客フロントエンドを提供する。例えば、顧客は、その顧客のＣＮ １０２が使用するためにＤＣ １０１のコンピューティングリソースを利用可能にすることを要求するために、ＭＳ １５０にリモートアクセスすることができる。顧客は、リソースのタイプ、リソースの量、およびリソース使用／利用可能性の持続時間などの他、それらの様々な組み合わせなど、コンピューティングリソースを求める要求に関連した様々なパラメータを指定することができる。ＭＳ １５０は、コンピューティングリソースを求める要求に基づいて、コンピューティングリソースを求める要求をサポートするためにＦＥ １２０をプロビジョニングするようにＦＥ １２０の１つもしくは複数に通知し、またはコンピューティングリソースを求める要求をサポートするためにＦＥ １２０をプロビジョニングするようＦＥ １２０の１つもしくは複数に通知するように、ＣＣ １４０に通知する。プロビジョニングは、（例えば、コンピューティングリソースが直ちに使用されることを要求が示している場合は）直ちに実行すること、および（例えば、コンピューティングリソースが後の時間に使用されることを要求が示している場合は）後の時間に実行されるようにスケジュールすることなどができる。ＭＳ １５０は、ＤＣ １０１内における様々なネットワーク管理機能を提供することもできる。

主として、特定のタイプ、数、および構成のネットワーク要素を有するデータセンタに関して示され、説明されたが、データセンタは、異なるタイプ、数、および／または構成のネットワーク要素を使用して、実施できることが理解されよう。例えば、主として、ＥＤ １１０をＣＤ １３０に接続する単一のＦＥ １２０の使用に関して示され、説明されたが、（例えば、ロードバランシングおよび信頼性などのために）複数のＦＥ １２０を介して１つまたは複数のＥＤ １１０をＣＤ １３０に接続できることが理解されよう。例えば、主として、単一のＣＣ １４０の使用に関して示され、説明されたが、ＣＣ １４０の機能は、複数のＣＣ １４０にわたって分散させることができる。他の様々な変更も行うことができることが理解されよう。

本明細書で説明されるように、ＤＣ １０１は、ＣＮ １０２を変更することなく、ＣＮ １０２が、ＤＣ １０１のクラウドコンピューティングリソースを利用できるようにする。

ＣＮ １０２は、例えば、個人顧客のホームネットワークから大企業顧客の企業ネットワークまで、任意のタイプの顧客ネットワークを含むことができる。言い換えると、ＣＮ １０１は、ＤＣ １０１のクラウドコンピューティングリソースを使用できる任意の顧客ネットワークとすることができる。

ＣＮ １０２は、任意の適切な通信手段（例えば、仮想プライベートＬＡＮサービス（ＶＰＬＳ）およびマルチプロトコルラベルスイッチング（ＭＰＬＳ）など）を使用して、ＤＣ １０１と通信することができる。

一実施形態では、ＤＣ １０１とＣＮ １０２は、ＶＰＬＳを使用して通信する。ＣＮ １０２が、インターネットサービスプロバイダ（ＩＳＰ）のプロバイダエッジ（ＰＥ）ルータを介して、ＶＰＬＳを使用してＤＣ １０１と通信する、そのような一実施形態では、ＣＮ １０２内の顧客エッジ（ＣＥ）デバイスは、ＩＳＰの第１のＶＰＬＳ ＰＥルータに接続し、ＣＮ １０２に関連付けられたＤＣ １０１のＣＥ動作ＦＥ １２０は、ＩＳＰの第２のＶＰＬＳ ＰＥルータに接続する。エンドのＣＥデバイスにとっては、関連付けられたＰＥルータは、ローカルイーサネットスイッチのように見える。さらなる一実施形態では、（例えば、ＰＥとＣＥ動作ＦＥによってサポートできる顧客の総数がポートの数によって制限されるように、ＣＥデバイスインターフェースとＰＥルータインターフェースの両方において、異なる顧客に対して異なるポートを割り当てる必要があるために）生じることがあるスケーラビリティ問題を回避するために、ＱｉｎＱカプセル化が、ＣＥ動作ＦＥとＰＥルータの間で使用され、それによって、各ポートが、最大で４０００顧客までサポートできるようにし、したがって、サポートできる顧客の数を著しく増加させる。他の任意の適切な方法で、ＤＣ １０１とＣＮ １０２の間の通信をサポートするためにも、ＶＰＬＳを利用できることが理解されよう。

一実施形態では、ＤＣ １０１とＣＮ １０２は、ＭＰＬＳを使用して通信する。ＤＣ １０１とＣＮ １０２の両方が同じインターネットサービスプロバイダ（ＩＳＰ）からネットワーク接続を取得する、そのような一実施形態では、ＭＰＬＳを、下層トランスポートとして使用することができ、より良いサービス品質のために、帯域幅をプロビジョニングすることができる。ＤＣ １０１とＣＮ １０２が異なるインターネットサービスプロバイダ（ＩＳＰ）からネットワーク接続を取得する、別のそのような実施形態では、レイヤ３ネットワークを通過するために、（例えば、汎用ルーティングカプセル化（ＧＲＥ）、またはレイヤ３ネットワークを通過するのに適した他のカプセル化プロトコルなど）１つまたは複数の他のカプセル化プロトコルも利用することができる。他の任意の適切な方法で、ＤＣ １０１とＣＮ １０２の間の通信をサポートするためにも、ＭＰＬＳを利用できることが理解されよう。

一実施形態では、個人ユーザまたは小企業の場合、ネットワークサービスプロバイダからの支援なしに、基本的な接続性およびセキュリティを提供するために、ＤＣ １０１とＣＮ １０２の間で、レイヤ２トンネリングプロトコル（Ｌ２ＴＰ）／インターネットプロトコルセキュリティ（ＩＰＳｅｃ）を使用することができる。

ＤＣ １０１とＣＮ １０２の間の通信は、他の任意の適切なタイプの通信機能を使用しても実施できることが理解されよう。

本明細書で説明されるように、ｉＥＣ２アーキテクチャは、クラウドコンピューティングリソースと顧客ネットワークとの統合を可能にし、それによって、顧客ネットワークを変更することなく、顧客がクラウドコンピューティングリソースを利用できるようにする。顧客ネットワークによるデータセンタのクラウドコンピューティングリソースの利用は、データセンタと顧客ネットワークの間におけるパケットの交換の他、データセンタ内におけるパケットの交換も必要とする。ｉＥＣ２アーキテクチャにおいてクラウドコンピューティングサービスを提供するために利用される異なるデータ転送経路が、以下で説明される。

クラウドコンピューティングサービスを利用する際、ＣＮ １０２内のデバイスは、ＤＣ １０１内のＶＭ １１３にパケットを送信することができる。データフローの説明を明瞭にする目的で、この例では、パケットは、ＣＮ １０２_Ａ内のデバイスから、ＣＮ １０２_ＡのためにＥＤ １１０_１内のＰＳ １１２_１−２上でホストされるＶＭ １１３に送信されると仮定する。パケットは、ＣＮ １０２_Ａから、ＣＮ １０２_Ａに関連付けられたＣＮ向きＦＥ １２０_４に転送される。パケットは、ＣＮ １０２_Ａに関連付けられたＣＮ向きＦＥ １２０_４において受信される。ＣＮ向きＦＥ １２０_４において受信されたパケットは、宛先であるＶＭ １１３のＭＡＣアドレスおよびＩＰアドレスを含む。ＣＮ向きＦＥ １２０_４は、仮想マシンＭＡＣ⇔（ｃｎｅｔ識別子，ＩＰアドレス）マッピングを使用して、パケット内に含まれる宛先であるＶＭ １１３のＭＡＣアドレスが、（ｃｎｅｔ ｉｄ，ＩＰアドレス）の組み合わせと矛盾しないことを保証する。ＣＮ向きＦＥ １２０_４は、パケットからのＭＡＣアドレスを使用して、仮想マシンＭＡＣ⇔エッジドメイン識別子マッピングにアクセスすることによって、パケットの宛先であるＶＭ １１３をホストするＥＤ １１０（この例では、ＣＮ １０２_Ａにとっての宛先であるＶＭ １１３をホストするＥＤ １１０_１）を決定する。ＣＮ向きＦＥ １２０_４は、決定されたエッジドメイン識別子を使用して、エッジドメイン識別子⇔ＦＥ ＭＡＣリストマッピングにアクセスすることによって、パケットの宛先であるＶＭ １１３をホストする識別されたＥＤ １１０のＦＥ １２０の１つ（この例では、ＥＤ １１０_１にサービスするＦＥ １２０_１）のＭＡＣアドレスを決定する。ＣＮ向きＦＥ １２０_４は、パケットの宛先であるＶＭ １１３をホストするＥＤ １１０のＦＥ １２０の１つの決定されたＭＡＣアドレス（この例では、ＥＤ １１０_１にサービスするＦＥ １２０_１のＭＡＣアドレス）を含むように、受信したパケットを変更する。例えば、ＣＮ向きＦＥ １２０_４は、変更されたパケットを形成するために、受信したパケットの外側ヘッダとして、ＦＥ １１０_１の決定されたＭＡＣアドレスを追加することができる。ＣＮ向きＦＥ １２０_４は、任意選択的に、変更されたパケットを転送する前に、および／または変更されたパケットを転送する一環として、適切な場合には、顧客のためのポリシー情報にアクセスし、ポリシー情報を適用すること（例えば、ＦＥ １１０_４に関連付けられたファイアウォールを介してＦＥ １１０_１にパケットを転送すること、または他の任意の適用可能なポリシー規則を適用すること）もできる。ＣＮ向きＦＥ １２０_４は、ＣＤ １３０を介して、変更されたパケットをＦＥ １１０_１に向けて転送する。ＣＤ １３０は、変更されたパケットの外側ヘッダとして使用されるＦＥ １１０_１のＭＡＣアドレスに基づいて、変更されたパケットを伝搬する（すなわち、変更されたパケットは、ＭＡＣ−ｉｎ−ＭＡＣトンネリングを使用して、ＣＤ １３０を介して、ＦＥ １１０_４からＦＥ １１０_１にトンネリングされる）。ＦＥ １１０_１は、ＣＤ １３０を介して、変更されたパケットを受信する。ＦＥ １１０_１は、パケットを獲得するために、変更されたパケットのヘッダを除去する。ＦＥ １１０_１は、ＥＤ １１０_１を介して、パケットの宛先であるＶＭ １１３に向けてパケットを伝搬する。ＦＥ １１０_１とＥＤ １１０_１は、（ａ）ＥＤ １１０_１内におけるＣＮ １０２_ＡのＶＬＡＮ ＩＤと、（ｂ）パケットの宛先であるＶＭ １１３のＭＡＣアドレスとを使用して、パケットを伝搬する。パケットの宛先であるＶＭ １１３が、パケットを受信する。ＶＭ １１３は、ＣＮ １０２_Ａのために、受信したパケットを処理する。このデータ転送フローでは、パケットの宛先であるＶＭ １１３をホストしているＥＤ １１０_１内におけるパケットの伝搬は、ＥＤ １１０_１内におけるＣＮ １０２_ＡのＶＬＡＮ ＩＤを使用して実行される。そのため、ＥＤ １１０_１内におけるＣＮ １０２_ＡのＶＬＡＮ ＩＤが、ＤＣ １０１内において決定されなければならず、パケットは、ＥＤ １１０_１内におけるＣＮ １０２_Ａの決定されたＶＬＡＮ ＩＤを含むように変更されなければならない。送信元ＦＥ（この例ではＦＥ １２０_４）と宛先ＦＥ（この例ではＦＥ １２０_１）の両方が、ＣＮ １０２_Ａのｃｎｅｔ識別子と、パケットの宛先であるＶＭ １１３をホストしているＥＤ １１０_１のエッジドメイン識別子とを知っているので、（ｃｎｅｔ識別子，エッジドメイン識別子）⇔ＶＬＡＮ識別子マッピングを使用して、送信元ＦＥによって、または宛先ＦＥによって、ＶＬＡＮ ＩＤを決定し、パケット内に挿入することができる。ＶＬＡＮ ＩＤの決定に関して、以下の構成を使用することができる：（ａ）宛先ＦＥに代わって、送信元ＦＥがＶＬＡＮ ＩＤの決定および挿入を常に担うように、ＤＣ １０１が構成される場合、宛先ＦＥは、ＣＤ １３０を介して受信されるパケットが、関連するＥＤ内でのパケットの配送に必要とされるＶＬＡＮ ＩＤを含むと（すなわち、宛先ＦＥは、受信したパケットが適切なＶＬＡＮ ＩＤを含むかどうかを判定する必要がないと）常に仮定することができ、あるいは（ｂ）宛先ＦＥに代わって、送信元ＦＥがＶＬＡＮ ＩＤの決定および挿入を常に担うように、ＤＣ １０１が構成されない場合、宛先ＦＥは、ＣＤ １３０を介してパケットを受信したときに、受信したパケットがＶＬＡＮ ＩＤを含むかどうかを判定し、（ｂ１）受信したパケットがＶＬＡＮ ＩＤを含まない場合、宛先ＦＥは、（ｃｎｅｔ識別子，エッジドメイン識別子）⇔ＶＬＡＮ識別子マッピングを使用して、ＶＬＡＮ ＩＤを決定し、決定されたＶＬＡＮ ＩＤをパケット内に挿入し、または（ｂ２）受信したパケットがＶＬＡＮ ＩＤを含む場合、宛先ＦＥは、ＶＬＡＮ ＩＤが有効であると仮定し、もしくは（ｃｎｅｔ識別子，エッジドメイン識別子）⇔ＶＬＡＮ識別子マッピングを使用して、ＶＬＡＮ ＩＤを決定し、それを受信したパケット内に含まれるＶＬＡＮ ＩＤと比較して、比較されたＶＬＡＮ ＩＤが一致しない場合は、パケット内のＶＬＡＮ ＩＤを、決定されたＶＬＡＮ ＩＤと置き換えることができる。

クラウドコンピューティングサービスを利用する際、ＤＣ １０１内のＶＭ １１３は、ＣＮ １０２内のデバイスにパケットを送信することができる。この場合のデータ転送フローは、ＣＮ １０２がＤＣ １０１内のＶＭ １１３にパケットを送信する上述の場合のデータ転送フローと非常に類似しているが、そのわけは、ＣＮ １０２が、本質的に特別なエッジドメインであるからである。

クラウドコンピューティングサービスを利用する際、ＤＣ １０１内の第１のＶＭ １１３は、ＤＣ １０１内の第２のＶＭにパケットを送信することができる。第１のＶＭ １１３と第２のＶＭ １１３が、異なるＥＤ １１０内にある場合、この場合のデータ転送フローは、ＣＮ １０２がＤＣ １０１内のＶＭ １１３にパケットを送信する上述の場合のデータ転送フローと非常に類似している。第１のＶＭ １１３と第２のＶＭ １１３が、同じＥＤ １１０内にあるが、異なるＶＬＡＮに関連付けられている場合、ＥＤ １１０に関連付けられたＦＥ １２０の１つが、ＶＬＡＮ ＩＤを変換し、任意選択的に、ポリシーチェックおよび実施を実行できるように、パケットは、ＥＤ １１０に関連付けられたＦＥ １２０の１つを介して、配送されなければならない。第１のＶＭ １１３と第２のＶＭ １１３が、同じＥＤ １１０内にあり、同じＶＬＡＮに関連付けられている場合、アドレスルックアップおよびマッピング、ならびにポリシーチェックおよび実施は必要とされないので、送信元ＶＭ １１３からのパケットは、宛先ＶＭ １１３に直接的に（すなわち、パケットがＦＥ １２０を通過する必要なしに）配送することができる。

上述のデータ転送フローの１つまたは複数では、ＭＡＣアドレスを学習するために、ＡＲＰプロセスを利用することができる。これは、上で説明されたデータ転送フローにおけるパケットの送信元デバイスが、パケットの宛先である宛先デバイスのＭＡＣアドレスを知ることを可能にする。

そのような実施形態では、ＡＲＰプロセスは、エンドポイントからの（例えば、ＣＮ １０２内のデバイスからの、もしくはＶＭ １１３からの）第１のパケットが、送信元ＦＥ １２０において受信される前に、またはエンドポイントからの（例えば、ＣＮ １０２内のデバイスからの、もしくはＶＭ １１３からの）第１のパケットが、送信元ＦＥ １２０において受信されたのに応答して、適用することができる。

そのような実施形態では、ＡＲＰフローは、上で説明されたデータ転送フローに類似している。ＡＲＰフローの説明を明瞭にする目的で、ＡＲＰフローは、ＣＮ １０２内のデバイスがＤＣ １０１内のＶＭ １１３にパケットを送信することを望んでいるデータ転送フローに関連して説明される（しかし、ＡＲＰプロセスは、他のタイプのデータ転送フローにも適用可能であることが理解されよう）。さらにＡＲＰフローの説明を明瞭にする目的で、この例では、ＣＮ １０２_Ａ内のデバイスが、ＣＮ １０２_ＡのためにＥＤ １１０_１内のＰＳ １１２_１−２上でホストされるＶＭ １１３にパケットを送信することを望んでいるが、ＣＮ １０２_ＡのためにＥＤ １１０_１内のＰＳ １１２_１−２上でホストされるＶＭ １１３のＭＡＣアドレスを知らないと仮定する。この場合、ＭＡＣアドレスを学習するために、ＣＮ １０２_Ａ内のデバイスは、ＡＲＰ要求パケットを開始する。ＡＲＰ要求パケットは、ＣＮ １０２_Ａから、ＣＮ １０２_Ａに関連付けられたＣＮ向きＦＥ １２０_４に転送される。ＡＲＰ要求パケットは、ＣＮ １０２_Ａに関連付けられたＣＮ向きＦＥ １２０_４において受信される。ＣＮ向きＦＥ １２０_４において受信されたＡＲＰ要求パケットは、ＣＮ １０２_Ａのｃｎｅｔ ｉｄと、宛先ＶＭ １１３のＩＰアドレスとを含むが、宛先ＶＭ １１３のＭＡＣアドレスは含まない。ＣＮ向きＦＥ １２０_４は、仮想マシンＭＡＣ⇔（ｃｎｅｔ識別子，ＩＰアドレス）マッピングを使用して、宛先ＶＭ １１３のＭＡＣアドレスを決定する。この時点で、ＣＮ向きＦＥ １２０_４は、ＡＲＰ要求に応答するのに十分な情報を今では有している（したがって、そうすることができる）が、スイッチは、一般にＡＲＰメッセージに応答しないことが（代わりに、エンドデバイスによって処理するために、ＡＲＰメッセージを単に転送するだけであることが）理解されよう。したがって、ＣＮ向きＦＥ １２０_４は、ＶＭ １１３の決定されたＭＡＣアドレス使用して、仮想マシンＭＡＣ⇔エッジドメイン識別子マッピングにアクセスすることによって、パケットの宛先であるＶＭ １１３をホストするＥＤ １１０（この例では、ＣＮ １０２_Ａのために宛先ＶＭ １１３をホストするＥＤ １１０_１）を決定する。ＣＮ向きＦＥ １２０_４は、決定されたエッジドメイン識別子を使用して、エッジドメイン識別子⇔ＦＥ ＭＡＣリストマッピングにアクセスすることによって、パケットの宛先であるＶＭ １１３をホストする識別されたＥＤ １１０のＦＥ １２０の１つ（この例では、ＥＤ １１０_１にサービスするＦＥ １２０_１）のＭＡＣアドレスを決定する。ＣＮ向きＦＥ １２０_４は、パケットの宛先であるＶＭ １１３をホストするＥＤ １１０のＦＥ １２０の１つの決定されたＭＡＣアドレス（この例では、ＥＤ １１０_１にサービスするＦＥ １２０_１のＭＡＣアドレス）を含むように、受信したＡＲＰ要求パケットを変更する。例えば、ＣＮ向きＦＥ １２０_４は、変更されたＡＲＰ要求パケットを形成するために、ＡＲＰ要求パケットの外側ヘッダとして、ＦＥ １１０_１の決定されたＭＡＣアドレスを追加することができる。ＣＮ向きＦＥ １２０_４は、ＣＤ １３０を介して、変更されたＡＲＰ要求パケットをＦＥ １１０_１に向けて転送する。ＣＤ １３０は、変更されたＡＲＰ要求パケットの外側ヘッダとして使用されるＦＥ １１０_１のＭＡＣアドレスに基づいて、変更されたＡＲＰ要求パケットを伝搬する（すなわち、変更されたＡＲＰ要求パケットは、ＭＡＣ−ｉｎ−ＭＡＣトンネリングを使用して、ＣＤ １３０を介して、ＦＥ １１０_４からＦＥ １１０_１にトンネリングされる）。ＦＥ １１０_１は、ＣＤ １３０を介して、変更されたＡＲＰ要求パケットを受信する。ＦＥ １１０_１は、ＡＲＰ要求パケットを獲得するために、変更されたＡＲＰ要求パケットの外側ヘッダを除去する。ＦＥ １１０_１は、ＣＮ １０２_ＡのためのＥＤ １１０_１内に存在するＶＬＡＮ内においてＡＲＰ要求パケットをブロードキャストする。ＶＬＡＮ ＩＤは、ＣＮ向きＦＥ １２０_４またはＦＥ １１０_１によって決定することができる。ＡＲＰ要求パケットの宛先であるＶＭ １１３（すなわち、ＡＲＰ要求パケット内に含まれるＩＰアドレスと一致するＩＰアドレスを有するＶＭ １１３）は、そのＭＡＣアドレスを含むＡＲＰ応答パケットを生成する。ＶＭ １１３は、ＥＤ １１０_１を介して、ＡＲＰ応答パケットをＦＥ １１０_１に伝搬する。ＦＥ １１０_１は、ＣＮ １０２_Ａに関連付けられたＣＮ向きＦＥ １２０_４までＡＲＰ応答パケットをトンネリングさせる。ＣＮ １０２_Ａに関連付けられたＣＮ向きＦＥ １２０_４は、ＡＲＰ要求パケットを開始したＣＮ １０２_Ａ内のデバイスまでＡＲＰ応答パケットをトンネリングさせて戻す。ＡＲＰ応答パケットは、ＶＭ １１３のＭＡＣアドレスを含み、その後、ＣＮ １０２_Ａ内のデバイスは、そのＭＡＣアドレスを使用して、データ転送フローに関して上で説明されたように、ＶＭ １１３にパケットを送信することができる。上で説明されたＡＲＰフローは、上で説明されたデータ転送フローに類似していることが理解されよう。

上で説明されたように、データセンタによって、多くの異なるデータ転送フローをサポートすることができる。したがって、ＦＥ １２０の各々は、パケットを転送する目的で、様々なステップを有する多くの異なる方法を実行できることが理解されよう。図２、図３、および図４に関して、３つのそのような例示的な方法が示され、説明されるが、そのようなステップの異なる組み合わせを含む他の様々な方法もサポートできることが理解されよう。

図２は、送信元転送要素においてパケットを処理するための方法であって、パケットが、関連付けられた宛先転送要素を有する宛先エッジドメインにおいてホストされる仮想マシン宛てである方法の一実施形態を示している。

ステップ２０２において、方法２００が開始する。

ステップ２０４において、パケットが、ＣＮまたは送信元ＥＤに関連付けられた送信元ＦＥにおいて受信される。パケットは、関連付けられた宛先ＦＥを有する宛先ＥＤ内のＶＭ宛てである。パケットは、ｃｎｅｔ ｉｄと、ＶＭのＩＰアドレスと、ＶＭのＭＡＣアドレスとを含む。

ステップ２０６において、宛先ＥＤに関連付けられた宛先ＦＥのＭＡＣアドレスが決定される。宛先ＦＥのＭＡＣアドレスは、仮想マシンＭＡＣ⇔エッジドメイン識別子マッピングと、エッジドメイン識別子⇔ＦＥ ＭＡＣリストマッピングとを使用して決定される。仮想マシンＭＡＣ⇔エッジドメイン識別子は、宛先ＥＤのＥＤ識別子を決定するために使用され、宛先ＥＤのＥＤ識別子は、エッジドメイン識別子⇔ＦＥ ＭＡＣリストマッピングにアクセスして、宛先ＦＥのＭＡＣアドレスを決定するために使用される。

（例えば、ＣＤを介したパケットの転送の前に、宛先ＥＤ内におけるＣＮのためのＶＬＡＮのＶＬＡＮ ＩＤがパケットに追加される場合に、任意選択的に）ステップ２０７において、宛先ＥＤ内におけるＣＮのためのＶＬＡＮのＶＬＡＮ ＩＤが決定され、宛先ＥＤ内におけるＣＮのためのＶＬＡＮの決定されたＶＬＡＮ ＩＤを含むように、パケットが更新される。

ステップ２０８において、パケット（すなわち、ステップ２０７が実行されたかどうかに応じて、元のパケットまたは更新されたパケット）が、宛先ＦＥのＭＡＣアドレスを使用して（例えば、ＭＡＣ−ｉｎ−ＭＡＣトンネリングを使用して）、送信元ＦＥから宛先ＦＥに向けて伝搬される。

ステップ２１０において、方法２００は終了する。

図３は、パケットの宛先である仮想マシンをホストするエッジドメインに関連付けられた転送要素においてパケットを処理するための方法であって、転送要素がエッジドメイン内におけるＣＮのＶＬＡＮのＶＬＡＮ ＩＤを常に決定すると仮定される方法の一実施形態を示している。この仮定は、データセンタが実施および／または構成される方法に基づくことができる。

ステップ３０２において、方法３００が開始する。

ステップ３０４において、パケットが、パケットの宛先であるＶＭをホストするＥＤに関連付けられたＦＥにおいて受信される。パケットは、ｃｎｅｔ ｉｄと、ＶＭのＩＰアドレスと、ＶＭのＭＡＣアドレスとを含む。パケットは、（例えば、送信元ＥＤおよび／またはＣＮに関連付けられたＦＥが、ＣＤを介したパケットの転送の前にパケットのためのＶＬＡＮ ＩＤを決定するように構成されているかどうかに応じて）任意選択的に、ＥＤ内におけるＣＮのＶＬＡＮにとって正しいＶＬＡＮ ＩＤであることも、または正しいＶＬＡＮ ＩＤではないこともある、ＶＬＡＮ ＩＤを含む。

ステップ３０６において、ＥＤ内におけるＣＮのためのＶＬＡＮのＶＬＡＮ ＩＤが決定される。ＶＬＡＮ ＩＤは、（ｃｎｅｔ識別子，エッジドメイン識別子）⇔ＶＬＡＮ識別子マッピングを使用して決定され、ｃｎｅｔ識別子は、パケットから決定され、エッジドメイン識別子は、任意の適切な方法で決定することができる。

ステップ３０８において、決定されたＶＬＡＮ ＩＤを含むように、パケットが処理される。

受信したパケットがＶＬＡＮ ＩＤを含まない一実施形態では、処理は、決定されたＶＬＡＮ ＩＤをパケット内に挿入することを含むことができる。

受信した各パケットがＶＬＡＮ ＩＤをすでに含む一実施形態では、処理は、パケット内のＶＬＡＮ ＩＤが決定されたＶＬＡＮ ＩＤと一致するかどうか判定することと、それらが一致する場合には、パケットのＶＬＡＮ ＩＤを変更しないでおくこと、またはそれらが一致しない場合には、パケットのＶＬＡＮ ＩＤを決定されたＶＬＡＮ ＩＤと置き換えることを含むことができる。

受信したパケットがＶＬＡＮ ＩＤを含むこともあり（ＶＬＡＮ ＩＤを含む受信パケットはいずれも、ＥＤ内におけるＣＮのための正しいＶＬＡＮ ＩＤを含むと仮定される）、または含まないこともある一実施形態では、処理は、受信したパケットがＶＬＡＮを含むかどうか決定することと、受信したパケットがＶＬＡＮ ＩＤを含む場合には、パケットのＶＬＡＮ ＩＤを変更しないでおくこと、または受信したパケットがＶＬＡＮ ＩＤを含まない場合には、パケットのＶＬＡＮ ＩＤを決定されたＶＬＡＮ ＩＤと置き換えることを含むことができる。

受け取ったパケットがＶＬＡＮ ＩＤを含むこともあり（ＶＬＡＮ ＩＤを含む受け取ったパケットはいずれも、ＥＤ内におけるＣＮのための正しいＶＬＡＮ ＩＤを含むと仮定されない）、または含まないこともある一実施形態では、処理は、パケットがＶＬＡＮ ＩＤを含むかどうか判定することと組み合わせて、適宜、ＶＬＡＮ ＩＤを含む場合には、パケット内のＶＬＡＮ ＩＤがＥＤ内におけるＣＮにとっての正しいＶＬＡＮ ＩＤであるか判定することに加えて、パケットのＶＬＡＮ ＩＤを変更しないでおくこと、またはパケットのＶＬＡＮ ＩＤを決定されたＶＬＡＮ ＩＤと置き換えることを、さもなければ決定されたＶＬＡＮ ＩＤをパケットに挿入することを含むことができる。

いずれの場合でも、処理が実施される方法に係わらず、受信したパケットは、受信したパケットが正しいＶＬＡＮ ＩＤを含むことが保証されるように、最終的に処理される。

ステップ３１０において、パケットは、ＶＬＡＮ ＩＤおよびＶＭのＭＡＣアドレスを使用して、ＦＥからＶＭに向けて伝搬される。

ステップ３１２において、方法３００は終了する。

図４は、パケットの宛先である仮想マシンをホストするエッジドメインに関連付けられた転送要素においてパケットを処理するための方法であって、転送要素がエッジドメイン内におけるＣＮのＶＬＡＮのＶＬＡＮ ＩＤを常に決定するとは仮定されない方法の一実施形態を示している。この仮定は、データセンタが実施および／または構成される方法に基づくことができる。

ステップ４０２において、方法４００が開始する。

ステップ４０４において、パケットが、パケットの宛先であるＶＭをホストするＥＤに関連付けられたＦＥにおいて受信される。パケットは、ｃｎｅｔ ｉｄと、ＶＭのＩＰアドレスと、ＶＭのＭＡＣアドレスとを含む。パケットは、（例えば、送信元ＥＤおよび／またはＣＮに関連付けられたＦＥが、ＣＤを介したパケットの転送の前にパケットのためのＶＬＡＮ ＩＤを決定するように構成されているかどうかに応じて）任意選択的に、ＥＤ内におけるＣＮのＶＬＡＮにとって正しいＶＬＡＮ ＩＤであることも、または正しいＶＬＡＮ ＩＤではないこともある、ＶＬＡＮ ＩＤを含む。

ステップ４０６において、パケットがＶＬＡＮ ＩＤを含むかどうかに関して判定が行われる。

パケットがＶＬＡＮ ＩＤを含まない場合、方法４００は、ステップ４０８とステップ４１０に相次いで進む。ステップ４０８において、ＥＤ内におけるＣＮのためのＶＬＡＮのＶＬＡＮ ＩＤが決定される。ＶＬＡＮ ＩＤは、（ｃｎｅｔ識別子，エッジドメイン識別子）⇔ＶＬＡＮ識別子マッピングを使用して決定され、ｃｎｅｔ識別子は、パケットから決定され、エッジドメイン識別子は、任意の適切な方法で決定することができる。ステップ４１０において、決定されたＶＬＡＮ ＩＤを含むように、パケットが更新される。ステップ４１０から、方法４００はステップ４１２に進む。

パケットがＶＬＡＮ ＩＤを含む場合、方法４００は、選択的に、（パケット内のＶＬＡＮ ＩＤが有効であると仮定されない場合）ステップ４１１の１つもしくは複数に進み、またはさもなければ、（パケット内のＶＬＡＮ ＩＤが有効であると仮定される場合）ステップ４１２に直接的に進む。選択的なステップ４１１Ａにおいて、パケット内のＶＬＡＮ ＩＤが有効であるかどうかに関して、（例えば、パケットからの情報と１つまたは複数のマッピングとを使用して、ＥＤ内におけるＣＮのためのＶＬＡＮのＶＬＡＮ ＩＤを決定し、決定されたＶＬＡＮ ＩＤをパケット内に含まれるＶＬＡＮ ＩＤと比較することによって）判定が行われる。パケット内のＶＬＡＮ ＩＤが有効である場合、方法４００は、ステップ４１１Ａからステップ４１２に進む。パケット内のＶＬＡＮ ＩＤが有効ではない場合、方法４００は、ステップ４１１Ｂに進み、ステップ４１１Ｂにおいて、パケット内のＶＬＡＮ ＩＤが、決定されたＶＬＡＮ ＩＤによって置き換えられ、方法４００は、ステップ４１２に進む。

ステップ４１２において、パケットは、ＶＬＡＮ ＩＤおよびＶＭのＭＡＣアドレスを使用して、ＦＥからＶＭに向けて伝搬される。

ステップ４１４において、方法４００は終了する。

主として、逐次的に実行されるものとして示され、説明されたが、上述の方法２００、３００、および４００の１つまたは複数の少なくとも一部は、同時に実行することができ、またはそれぞれ図２、図３、および図４に関して示され、説明されたのとは異なる順序で実行することができる。

本明細書で説明されたように、顧客は、顧客ネットワークにトランスペアレントに拡張を提供するために、データセンタリソースを利用することができる。ｉＥＣ２アーキテクチャは、顧客が、レイヤ２および／またはレイヤ３ネットワーク拡張を獲得できるようにする。

レイヤ２ネットワーク拡張では、データセンタ内の仮想サーバは、論理的に、顧客ネットワーク内の顧客サーバと同じＬＡＮ内に存在する。あるアプリケーションは、そのアプリケーションを実行するサーバが同じＬＡＮの部分であることを必要とすることがあるので、これは都合がよい。また、同じＬＡＮ内で仮想サーバに移行するほうが容易であるので、これは都合がよい。一般に、レイヤ２拡張は、レイヤ３拡張よりも柔軟性があるのが普通である。

レイヤ３ネットワーク拡張では、データセンタ内の仮想サーバは、顧客ネットワークと同じサブネット内に存在しない。顧客は、データセンタ内に１つまたは複数のサブネットを有することができる。一般に、レイヤ３ネットワークは、ポリシー上の理由などのために、より多くのサーバを有するために必要とされることがある。

一実施形態では、顧客に対してレイヤ３拡張をサポートするために、ＦＥ １２０およびＣＣ １４０は、追加のルータ機能をサポートすることができる。追加のルータ機能は、レイヤ３拡張がサポートされる各顧客について、少なくとも１つの仮想ルータが顧客に割り当てられ、仮想ルータが顧客ネットワークのアウタ（ｏｕｔｅｒ）と相互接続できるようにすることを含むことができる。この構成では、データは、ＦＥ １２０によって転送され、ルーティングプロトコルは、ＣＣ １４０において実行される。

異なるタイプの拡張を提供することに関して、仮想サーバはロケーション独立とされる（すなわち、仮想サーバは任意の物理ホストにおいて実行できる）ので、データセンタ内での移行はネットワークレイヤとは独立であるが、異なるサブネットにまたがる顧客ネットワークとデータセンタの間の移行はより困難であることが理解されよう。一実施形態では、異なるサブネットにまたがる顧客ネットワークとデータセンタの間の移行は、仮想サーバのロケーションを登録し、データセンタ内のＦＥに／ＦＥからパケットをトンネリングさせるように構成されたＦＥを、顧客ネットワークのエッジに配備することによって実行することができる。

上で示され、説明されたように、ｉＥＣ２アーキテクチャは、既存のクラウドベースのコンピューティングアーキテクチャにまさる多くの利点を提供する。

ｉＥＣ２アーキテクチャは、異なる顧客ネットワークの効果的な分離を提供する。これは、（顧客間で潜在的に重複し得る）顧客のプライベートなＩＰアドレス空間をサポートすること、顧客のトラフィックを分離すること、および類似の分離機能を提供することを含む。これは、どの顧客も他のいかなる顧客のリソース使用に制御不能な仕方で影響を及ぼすことができないように、リソース割り当てを実行することも含むことができる。

ｉＥＣ２アーキテクチャは、データセンタの下層インフラストラクチャが顧客にトランスペアレントであるように、顧客に透過性を提供する。このようにして、各顧客は、データセンタの実際の実施とは独立に、データセンタ内のクラウドコンピューティングリソースを含む、自らのネットワークの論理ビューを有する。これは、顧客のための管理の簡素化および顧客のための改善されたセキュリティなどを含む、多くの利点を提供する。

ｉＥＣ２アーキテクチャは、顧客にロケーション独立性を提供する。顧客のための仮想サーバおよびネットワークは、物理的にデータセンタ内のどこにでも配置することができる。これは、リソース利用の改善およびプロビジョニングの簡素化などを含む、多くの利点を提供する。

ｉＥＣ２アーキテクチャは、容易な顧客ポリシー制御を提供し、顧客が、ポリシー設定を実行中に構成できるように、およびネットワーク内でポリシー設定を実施できるようにする。特に、各顧客は自らのポリシー要件およびセキュリティ要件を有することがある（例えば、家庭顧客は基本的なファイアウォール保護のみを必要とすることがあるのに対し、企業顧客は異なるアクセス制御を有する複数のセキュリティゾーンを必要とすることがある）ので、これは有利である。

ｉＥＣ２アーキテクチャは、高度にスケーラブルである。サポートできる顧客の数は、データセンタにおいて利用可能なリソースによってのみ制約され、ＶＬＡＮのスケーラビリティ問題など、設計上の人為的結果によっては制約されない。

ｉＥＣ２アーキテクチャは、低コストである。クラウドサービスプロバイダが新規投資を削減できるように、ｉＥＣ２アーキテクチャは、クラウドサービスプロバイダが、ほとんどのデバイスについて市販のデバイスに依存できるようにする。異なる顧客に物理的に別個のネットワークおよびリソースを割り当てると、コストは法外なものになるので、ｉＥＣ２アーキテクチャは、クラウドサービスプロバイダが、そのリソースを異なる顧客の間で共用できるようにする。

本明細書では、主として、本明細書で示され、説明されたｉＥＣ２アーキテクチャの機能を提供するためのイーサネットの使用（したがって、ＭＡＣアドレスの使用）に関して示され、説明されたが、本明細書で示され、説明されたｉＥＣ２アーキテクチャの機能は、他の任意の適切なプロトコルおよび関連するアドレスを使用して、提供することもできることが理解されよう。

本明細書では、主として、本明細書で示され、説明されたｉＥＣ２アーキテクチャの機能を提供するための特定のマッピングの使用に関して示され、説明されたが、本明細書で示され、説明されたｉＥＣ２アーキテクチャの機能は、より少数または多数のマッピングおよび異なるマッピングを使用して、提供することもできることが理解されよう。本明細書で示され、説明されたｉＥＣ２アーキテクチャの機能を提供するために、１つまたは複数の他の適切なプロトコルが使用される場合、本明細書で示され、説明されたマッピングは、しかるべく変更できることがさらに理解されよう。

図５は、本明細書で説明される機能を実行する際に使用するのに適したコンピュータの高レベルブロック図を示している。図５に示されるように、コンピュータ５００は、プロセッサ要素５０２（例えば、中央処理装置（ＣＰＵ）および／または他の適切なプロセッサ）と、メモリ５０４（例えば、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）など）と、クラウドコンピューティングモジュール５０５と、様々な入出力デバイス５０６（例えば、ユーザ入力デバイス（キーボード、キーパッド、およびマウスなど）、ユーザ出力デバイス（ディスプレイおよびスピーカなど）、入力ポート、出力ポート、受信機、送信機、ならびにストレージデバイス（例えば、テープドライブ、フロッピドライブ、ハードディスクドライブ、およびコンパクトディスクドライブなど））とを含む。

本明細書で示され、説明された機能は、ソフトウェアで、および／または例えば、汎用コンピュータ、１つもしくは複数の特定用途向け集積回路（ＡＳＩＣ）を使用する、ソフトウェアとハードウェアの組み合わせで、および／または他の任意のハードウェア同等物で実施できることに留意されたい。一実施形態では、本明細書において上で説明されたような機能を実施するために、クラウドコンピューティングプロセス５０５を、メモリ５０４にロードし、プロセッサ５０２によって実行することができる。したがって、（関連するデータ構造を含む）クラウドコンピューティングプロセス５０５は、例えば、ＲＡＭメモリ、磁気または光ドライブもしくはディスケットなどの、コンピュータ可読記憶媒体上に記憶することができる。

ソフトウェア方法として本明細書で説明されたステップのいくつかは、例えば、様々な方法ステップを実行するためにプロセッサと協力する回路として、ハードウェア内で実施できることが想到されている。本明細書で説明された機能／要素の一部は、コンピュータプログラム製品として実施することができ、コンピュータ命令は、コンピュータによって処理されたときに、本明細書で説明された方法および／または技法が呼び出され、または他の方法で提供されるように、コンピュータの動作を適合させる。本発明の方法を呼び出すための命令は、固定媒体もしくは着脱可能媒体内に記憶することができ、ブロードキャスト媒体もしくは他の信号搬送媒体内のデータストリームを介して送信することができ、および／または命令に従って動作するコンピューティングデバイス内のメモリ内に記憶することができる。

本発明の教示を含む様々な実施形態が、本明細書で詳細に示され、説明されたが、当業者であれば、これらの教示を依然として含む他の多くの様々な実施形態を容易に考案することができよう。

Claims (10)

1. 顧客の顧客ネットワークの拡張としてデータセンタのリソースを使用することを可能にするための方法であって、
   転送要素（ＦＥ）において、データセンタのエッジドメインにおいてホストされる仮想マシンを宛先とするパケットを受信するステップであって、エッジドメインが、複数の顧客ネットワークのそれぞれのための複数のＶＬＡＮをサポートし、パケットが、顧客ネットワークの識別子と、仮想マシンのＭＡＣアドレスとを含む、ステップと、
   顧客ネットワークの識別子と仮想マシンのＭＡＣアドレスとを使用して、エッジドメインにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを決定するステップと、
   エッジドメインにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを含むようにパケットを更新するステップと、
   更新されたパケットをＦＥから仮想マシンに向けて伝搬するステップと
   を含む、方法。
2. エッジドメインにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを決定するステップが、
   仮想マシンのＭＡＣアドレスを使用して、エッジドメインの識別子を決定するステップと、
   顧客ネットワークの識別子とエッジドメインの識別子とを使用して、エッジドメインにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを決定するステップと
   を含む、請求項１に記載の方法。
3. ＦＥが、仮想マシンがホストされるデータセンタのエッジドメインに関連付けられ、エッジドメインにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを含むようにパケットを更新するステップが、
   受信したパケットが既存のＶＬＡＮ ＩＤを含む場合に、既存のＶＬＡＮ ＩＤを決定されたＶＬＡＮ ＩＤと置き換えるステップ、または
   パケットが既存のＶＬＡＮ ＩＤを含まない場合に、決定されたＶＬＡＮ ＩＤをパケット内に挿入するステップ
   を含む、請求項１に記載の方法。
4. ＦＥが、仮想マシンがホストされるデータセンタのエッジドメインに関連付けられ、更新されたパケットをＦＥから仮想マシンに向けて伝搬するステップが、
   更新されたパケット内に含まれるＶＬＡＮ ＩＤと仮想マシンのＭＡＣアドレスとを使用して、更新されたパケットを仮想マシンに向けて伝搬するステップ
   を含む、請求項１に記載の方法。
5. ＦＥが、データセンタの第１のエッジドメインに関連付けられた第１のＦＥであり、仮想マシンがホストされるエッジドメインが、関連付けられた第２のＦＥを有するデータセンタの第２のエッジドメインであり、方法が、
   仮想マシンのＭＡＣアドレスを使用して、第２のエッジドメインの識別子を決定し、第２のエッジドメインの識別子を使用して、第２のＦＥのＭＡＣアドレスを決定することによって、仮想マシンのＭＡＣアドレスを使用して、第２のＦＥのＭＡＣアドレスを決定するステップ
   をさらに含む、請求項１に記載の方法。
6. 更新されたパケットを第１のＦＥから仮想マシンに向けて伝搬するステップが、
   第２のＦＥのＭＡＣアドレスを使用して、更新されたパケットを第１のＦＥから第２のＦＥに向けて伝搬するステップ
   を含む、請求項５に記載の方法。
7. ＦＥが、顧客ネットワークに関連付けられた第１のＦＥであり、仮想マシンがホストされるエッジドメインが、関連付けられた第２のＦＥを有し、方法が、
   仮想マシンのＭＡＣアドレスを使用して、エッジドメインの識別子を決定し、エッジドメインの識別子を使用して、第２のＦＥのＭＡＣアドレスを決定することによって、第２のＦＥのＭＡＣアドレスを決定するステップ
   をさらに含む、請求項１に記載の方法。
8. 更新されたパケットを第１のＦＥから仮想マシンに向けて伝搬するステップが、
   第２のＦＥのＭＡＣアドレスを使用して、更新されたパケットを第１のＦＥから第２のＦＥに向けて伝搬するステップ
   を含む、請求項７に記載の方法。
9. 顧客の顧客ネットワークの拡張としてデータセンタのリソースを使用することを可能にするための装置であって、
   転送要素（ＦＥ）において、データセンタのエッジドメインにおいてホストされる仮想マシンを宛先とするパケットを受信するための手段であって、エッジドメインが、複数の顧客ネットワークのそれぞれのための複数のＶＬＡＮをサポートし、パケットが、顧客ネットワークの識別子と、仮想マシンのＭＡＣアドレスとを含む、手段と、
   顧客ネットワークの識別子と仮想マシンのＭＡＣアドレスとを使用して、エッジドメインにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを決定するための手段と、
   エッジドメインにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを含むようにパケットを更新するための手段と、
   更新されたパケットをＦＥから仮想マシンに向けて伝搬するための手段と
   を備える、装置。
10. 顧客の顧客ネットワークの拡張としてデータセンタのリソースを使用することを可能にするためのネットワークであって、
    データセンタの複数のエッジドメインであって、各エッジドメインが、少なくとも１つの顧客によって使用される少なくとも１つの仮想マシンをホストするために構成された少なくとも１つの物理サーバを備え、各エッジドメインが、プロビジョニングされた仮想マシンを有する各顧客ネットワークのためのＶＬＡＮをサポートするように構成される、データセンタの複数のエッジドメインと、
    複数の転送要素であって、
    各転送要素が、エッジドメインの少なくとも１つまたは少なくとも１つの顧客ネットワークの少なくとも一方のためのパケット転送機能をサポートするように構成され、
    エッジドメインの１つのためのパケット転送機能をサポートするように構成された各転送要素が、エッジドメイン内でホストされる少なくとも１つの仮想マシンを有する各顧客ネットワークについて、ＶＬＡＮ ＩＤを顧客ネットワークに関連付けるように構成される、
    複数の転送要素と、
    データセンタのコアドメインであって、コアドメインが、転送要素間においてパケットを転送するために構成された複数のスイッチを備える、データセンタのコアドメインと
    を備え、
    エッジドメインの１つのためのパケット転送機能をサポートするように構成された少なくとも１つの転送要素について、エッジドメインの１つのためのパケット転送機能をサポートするように構成された転送要素は、
    エッジドメインの１つにおいてホストされる仮想マシンを宛先とする、顧客ネットワークの識別子と、仮想マシンのＭＡＣアドレスとを含むパケットを受信し、
    顧客ネットワークの識別子と、仮想マシンのＭＡＣアドレスとを使用して、エッジドメインの１つにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを決定し、
    エッジドメインの１つにおける顧客ネットワークのためのＶＬＡＮのＶＬＡＮ ＩＤを含むようにパケットを更新し、
    更新されたパケットを転送要素から仮想マシンに向けて伝搬する、
    ように構成されている、ネットワーク。

Images