JP6207559B2 - オフロードデバイスベースのパケット処理のためのフレームワークおよびインターフェース - Google Patents

Description

インターネットといったネットワーク上で利用可能なアプリケーションおよびサービスの増加に伴い、マルチテナント、共有リソース技術を利用するコンテンツ、アプリケーション、および／またはサービスプロバイダが増加している。例えば、クラウドコンピューティングは、ウェブサービスといったサービスを通じて、電子リソースへのアクセスを顧客に提供することができ、ここでは、それらのサービスをサポートするために使用されるハードウェアおよび／またはソフトウェアは、任意の所与の時間において、サービスの必要性を満たすように、動的にスケーリング可能である。顧客は、典型的に、クラウドを通じて、リソースへのアクセスを貸借するか、リースするか、またはそうでなければそれに対して支払いを行い、このため、必要とされるハードウェアおよび／またはソフトウェアを購入かつ維持する必要がない。

しかしながら、典型的に、種々の時間にリソースにアクセスする複数のユーザが存在するため、かかるアクセスは、これらの共有リソースのプロバイダに対するリスクを伴う。顧客ネットワークが、制限または１つ以上の追加の物理的ネットワークの追加のアドレスを伴わずに、単一の仮想ネットワークとして機能するように、ユーザが仮想アドレス空間を有する場合、この仮想アドレス空間に関連するパケットの処理およびルーティングを提供することが望ましい可能性がある。しかしながら、顧客がデバイスへのアクセスを有する時、デバイス上でルーティングおよび処理を実施することは、潜在的に、ユーザがパケットのルーティングまたは他のかかる処理を修正することを可能にし得る。さらに、かかる機能性は、サイズ制限、プロトコル制限等といった理由により、ユーザに露出されない多くの既存のハードウェアデバイスに容易に移動させることができない。

本開示に従う種々の実施形態が、以下の図面を参照して説明される。
種々の実施形態を実装することができる環境を例解する。 一実施形態に従って、使用することができる、種々のリソースへのアクセスを提供するための環境を例解する。 一実施形態に従って、使用することができる、特定のハードウェアリソースにアクセスするための構成を例解する。 一実施形態に従って、使用することができる、パケットカプセル化プロセスを例解する。 一実施形態に従って、使用することができる、パケットを処理するための構成を例解する。 種々の実施形態に従って、使用することができる、例示的なパケットヘッダを例解する。 種々の実施形態に従って、使用することができる、パケットを処理するための第５のプロセスの実施例を例解する。 種々の実施形態に従って、使用することができる、パケットを処理するための第６のプロセスの実施例を例解する。 種々の実施形態に従って、使用することができる、パケットを処理するための例示的な流れを例解する。

本開示の種々の実施形態に従うシステムおよび方法は、電子環境におけるリソースの管理のための従来の手法において経験される前述および他の欠陥のうちの１つ以上を克服することができる。種々の実施形態に従うシステムおよび方法は、顧客または仮想アドレス空間といった第１のアドレス空間と、クラウドネットワークプロバイダまたは物理アドレス空間といった第２のアドレス空間との間の、パケットの処理を提供する。種々のネットワークオフロードデバイスといった商品デバイスのセグメント化およびセグメント結合オフロード特性といった特性は、特に、それが仮想化された環境に関する際、ネットワークトラフィックに関するオーバーヘッドの低減を助長するために使用することができる。セグメント化およびセグメント結合オフロード特性の提供のための種々の手法は、例えば、「２００９年９月９日」出願の、「Ｓｔａｔｅｌｅｓｓ Ｐａｃｋｅｔ Ｓｅｇｍｅｎｔａｔｉｏｎ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ」と題する、同時係属の米国特許出願第１２／５５６，４５３号、および２０１０年９月１７日出願の「Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｓｔａｔｅｌｅｓｓ Ｐａｃｋｅｔ Ｔｕｎｎｅｌｉｎｇ」と題する同出願第１２／８８５，２５８において説明され、これらの各々は、参照することによって、本明細書に組み込まれる。

種々の実施形態は、仮想化されたオーバーレイネットワークを実装するために、シングルルートＩ／Ｏ仮想化（ｓｉｎｇｌｅ ｒｏｏｔ Ｉ／Ｏ ｖｉｒｔｕａｌｉｚａｔｉｏｎ：ＳＲ−ＩＯＶ）といったプロトコルと併せて、オフロードデバイスが、オープンな、および独自のステートレストンネリングをサポートすることを可能にする。ＳＲ−ＩＯＶは、一般的に、周辺構成要素相互接続（ＰＣＩ）デバイスといったデバイスが、複数の、独立した物理的デバイスとして考えられることを可能にする、相互運用に関する標準的な仕様を指す。ＳＲ−ＩＯＶは、物理的機能（ＰＦ）および仮想機能（ＶＦ）を活用する。物理的機能は、一般的に、完全装備の機能である一方、仮想機能は、一般的に、少なくとも一部の構成リソースを欠いている場合がある、より軽量な機能である。ＳＲ−ＩＯＶは、典型的に、ＢＩＯＳにおけるサポート、ならびにハードウェア上で実行されるハイパーバイザまたはオペレーティングシステムインスタンスにおけるサポートを必要とする。

少なくとも一部の実施形態において、オフロードデバイス（またはかかるデバイスのベンダもしくは製造元）は、パケット処理のための特定の機能性を提供することができる。例えば、Ｄｏｍ−０（即ち、ドメインゼロ、典型的に、起動時にＸｅｎハイパーバイザによって開始される最初のドメイン）に基づく実装は、進出パケットをカプセル化する、および進入パケットを脱カプセル化するといった、ある行為を実施するように、オフロードデバイスによって使用することができる種々の規則を利用することができる。進出パケット送信元チェックは、送信元ＶＭに基づき、全ての進出パケットにおいて実施され得、送信元ＭＡＣアドレスおよび送信元ＩＰアドレスを照合することを含む。一部の実施形態において、オフロードデバイスは、特定のＶＬＡＮ（仮想ローカルエリアネットワーク）タグを強行するか、またはそうでなければＶＬＡＮタグを追加することができる。進出パケット送信元チェックの後、パケットを、既存の規則のリストに対して適合させることができる。適合が存在する場合、対応するカプセル化行為をパケット上で行い、適宜、パケットを伝送することができる。そうでない場合、パケットを、さらなる処理のために、Ｄｏｍ−０制御ソフトウェアへ送信することができる。

進入パケットに関して、ある実施形態におけるパケットは、例えば、事前定義されたＩＰプロトコル番号、およびＬ２ヘッダエンドからの事前定義されたオフセットでの事前定義された１バイト値に基づく、特別な形式を使用して、カプセル化されているとして識別することができる。これらの値は、各々、Ｄｏｍ−０によって構成することができる。カプセル化されない全ての進入パケットは、Ｄｏｍ−０へ配信することができる。カプセル化された進入に関して、いずれの不明瞭なビット（外部Ｌ３ヘッダの直後に位置する）は、事前定義された長さの不明瞭なビットを使用して識別することができる。各パケットは、事前定義されたオフセットでの不明瞭なビット内の１バイトフィールドを使用して、特定の仮想機械（ＶＭ）（例えば、ＳＲ−ＩＯＶベクタ）に属するとしてさらに分類することができる。

各ＳＲ−ＩＯＶ機能は、一組の進入規則とともに構成することができる。各規則は、主に、カプセル化された進入パケット、外部送信元ＩＰアドレス、外部送信先ＩＰアドレス、ならびに送信元および標的ＭＡＣアドレスの不明瞭なビットと適合する、不明瞭なビットから成ることができる。カプセル化された進入パケットが、特定のＳＲ−ＩＯＶ機能に対する進入規則のうちの１つと適合する（即ち、不明瞭なビットが適合する）時、パケットは、脱カプセル化することができ（即ち、不明瞭なビットが除去される）、内部ＩＰヘッダのＴＴＬは、規則において指定される値分デクリメントされ、パケットは、ＳＲ−ＩＯＶ機能に対応するＶＭへ配信される。規則のうちのいずれにも適合しない進入パケットは、Ｄｏｍ−０へ配信することができる。

少なくとも一部の実施形態において、オフロードデバイスは、Ｄｏｍ−０から読み取られ得る、またはリセットされ得る、各カプセル化および脱カプセル化規則に対する、パケット数およびバイト数を維持する。種々の実施形態はまた、Ｄｏｍ−０からＳＲ−ＩＯＶ機能にパケットを注入する能力を提供することができる。ある実施形態は、各パケットが有効である適合規則にかかわらず、Ｄｏｍ−０を通過するように強制されるデバッグモードを提供することができる。ＳＲ−ＩＯＶ機能に対する最大伝送単位（ｍａｘｉｍｕｍ ｔｒａｎｓｍｉｓｓｉｏｎ ｕｎｉｔ：ＭＴＵ）は、Ｄｏｍ−０から設定することができ、少なくとも一実施形態においては、１５００にデフォルト設定される。ゲストがＭＴＵサイズを変更しようとする場合および時、オフロードデバイスは、提唱されたＭＴＵが、Ｄｏｍ−０によって設定される最大ＭＴＵを超過しないということを確実とすることができる。一部の実施形態において、オフロードデバイスはまた、接続追跡を実施することができ、これは、オフロードデバイス上でのステートフルなファイアウォール実装を提供するために使用することができる。

少なくとも一部の実施形態において、進入および進出パケットの両方のためのカプセル化および脱カプセル化規則を管理する、Ｄｏｍ−０制御ソフトウェアを提供することができる。Ｄｏｍ−０制御ソフトウェアは、例えば、オフロードデバイスによって提供されるパケット数統計値、ならびにサブストレートＡＲＰクエリを使用して、サブストレートネットワークのためのアドレス解決プロトコル（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＡＲＰ）キャッシュを管理することができる。Ｄｏｍ−０制御ソフトウェアはまた、ある場合、どの規則がオフロードデバイスにプッシュされなければならないか、およびオフロードデバイスが必要とされる規則の全てはサポートしない場合、どの規則が、オーバーフロー規則として、Ｄｏｍ−０によって管理されなければならないかを判断することができる。

図１は、種々の実施形態に従う態様を実装するための環境１００の実施例を例解する。理解されるように、ウェブベースの環境が解説目的で使用されるが、種々の実施形態を実装するために、適切な場合、異なる環境が使用されてもよい。示される環境１００は、試験または開発部分（もしくは側）および生産部分の両方を含む。電子クライアントデバイス１０２は、適切なネットワーク１０４上で要求、メッセージ、または情報を送信および受信し、デバイスのユーザに情報を伝達し戻すように動作可能な任意の適切なデバイスを含むことができる。かかるクライアントデバイスの例としては、パーソナルコンピュータ、携帯電話、手持ち式メッセージングデバイス、ラップトップコンピュータ、セットトップボックス、個人データアシスタント、電子書籍リーダ等が挙げられる。ネットワークは、イントラネット、インターネット、セルラネットワーク、ローカルエリアネットワーク、または任意の他のかかるネットワーク、もしくはこれらの組み合わせを含む、任意の適切なネットワークを含むことができる。かかるシステムのために使用される構成要素は、選択されるネットワークおよび／または環境のタイプに少なくとも部分的に依存し得る。かかるネットワークを介して通信するためのプロトコルおよび構成要素は、公知であり、本明細書においては詳細に述べない。ネットワーク上での通信は、有線または無線接続、およびこれらの組み合わせによって有効にすることができる。本実施例において、ネットワークは、環境が、要求を受信し、かつそれに応答してコンテンツをサーブするためのウェブサーバ１０６を含むとして、インターネットを含むが、他のネットワークに関しては、当業者には明らかであるように、同様の目的を果たす代替的なデバイスが使用され得る。

例解的な環境は、少なくとも１つのアプリケーションサーバ１０８と、複数のリソース、サーバ、ホスト、インスタンス、ルータ、スイッチ、データストア、および／または本明細書においてデータプレーン１１０と称されるものを定義する他のかかる構成要素とを含むが、このプレーンのリソースは、データの記憶、およびそれへのアクセスの提供に限定されないということが理解されるべきである。連鎖されるか、または別様に構成されてもよく、適切なデータストアからのデータの取得といったタスクを実施するように相互作用することができる、いくつかのアプリケーションサーバ、層、または他の要素、プロセス、もしくは構成要素が存在し得ることが理解されるべきである。本明細書において使用される際、「データストア」という用語は、データを記憶する、それへアクセスする、およびそれを取り出すことか可能な任意のデバイスまたはデバイスの組み合わせを指し、任意の標準、分散型、またはクラスタ化環境において、任意の組み合わせおよび数のデータサーバ、データベース、データ記憶デバイス、およびデータ記憶媒体を含んでもよい。アプリケーションサーバは、クライアントデバイスのための１つ以上のアプリケーションの様態を実行するように、必要に応じて、データストアと一体化させ、アプリケーションのためのデータアクセスおよびビジネスロジックの大部分を処理するための任意の適切なハードウェアおよびソフトウェアを含むことができる。アプリケーションサーバは、データストアと協働してアドミッション制御サービスを提供し、ユーザに転送されるべき文字、図、音声、および／またはビデオといったコンテンツを生成することができ、これは、本実施例において、ＨＴＭＬ、ＸＭＬ、または別の適切な構造化された言語の形態で、ウェブサーバによってユーザにサーブされ得る。一部の実施形態において、ウェブサーバ１０６、アプリケーションサーバ１０８、および同様の構成要素は、データプレーンの一部として見なすことができる。全ての要求および応答の処理、ならびにクライアントデバイス１０２とアプリケーションサーバ１０８との間のコンテンツの配信は、ウェブサーバによって処理することができる。本明細書の他の個所で述べられるように、構造化されたコードは、任意の適切なデバイスまたはホスト機械上で実行することができるため、ウェブおよびアプリケーションサーバは必須ではなく、例示的な構成要素であるに過ぎないということが理解されるべきである。

環境はまた、開発および／または試験サイドを含み、これは、開発者、データ管理者、または試験者といったユーザが、システムにアクセスすることを可能にする、ユーザデバイス１１８を含む。ユーザデバイス１１８は、クライアントデバイス１０２に関して上で説明されるようなものといった、任意の適切なデバイスまたは機械とすることができる。環境はまた、開発サーバ１２０を含み、これは、アプリケーションサーバ１０８と同様に機能するが、典型的には、例えば、コードが生産サイド上で配備および実行され、外部ユーザにアクセス可能となる前に、開発および試験中にコードを実行する。一部の実施形態において、アプリケーションサーバは、開発サーバとして機能することができ、別個の生産および試験記憶装置を使用しなくてもよい。

データプレーン１１０のデータストアは、いくつかの別個のデータ表、データベース、または特定の様態に関するデータを記憶するための他のデータ記憶機構および媒体を含むことができる。例えば、例解されるデータプレーンは、生産データ１１２およびユーザ情報１１６を記憶するための機構を含み、これらは、生産サイドのためにコンテンツをサーブするために使用することができる。データプレーンはまた、試験データ１１４を記憶するための機構を含むように示され、これは、試験サイドのためにユーザ情報とともに使用することができる。適切な場合、上で列記される機構のうちのいずれか、またはデータプレーン１１０における追加の機構に記憶することができる、ページイメージ情報およびアクセス権情報のためといった、データストアに記憶されるために必要とされ得る多くの他の態様が存在し得るということが理解されるべきである。データプレーン１１０は、それと関連付けられるロジックを通じて、アプリケーションサーバ１０８または開発サーバ１２０から命令を受信するように、およびそれに応答して、データ、命令、もしくは他のかかる情報を取得、更新、またはそうでなければ処理するように、動作可能である。一実施例において、ユーザは、あるタイプの項目に対して検索要求を提出する場合がある。この場合、データプレーンの構成要素は、ユーザのアイデンティティを照合するように、ユーザ情報にアクセスする、およびそのタイプの項目についての情報を取得するように、カタログ詳細情報にアクセスする場合がある。次いで、情報は、例えば、ユーザがユーザデバイス１０２上のブラウザを介して観視することができる、ウェブページ上の結果リストにおいて、ユーザに返すことができる。関心対象の特定の項目に関する情報は、専用ページまたはブラウザのウィンドウにおいて観視することができる。

各サーバは、典型的に、そのサーバの一般管理および動作に対する実行可能なプログラム命令を提供するオペレーティングシステムを含み、典型的に、サーバのプロセッサによって実行される時に、サーバが、その意図される機能を実施することを可能にする命令を記憶する、コンピュータが読み取り可能な媒体を含む。サーバのオペレーティングシステムおよび一般的な機能性に対する好適な実装は、既知であるか、または商業的に利用可能であり、特に本明細書における本開示を考慮すれば、当業者によって容易に実装される。

一実施形態における環境は、１つ以上のコンピュータネットワークまたは直接接続を使用して、通信リンクを介して相互接続される、いくつかのコンピュータシステムおよび構成要素を利用する、分散型コンピューティング環境である。しかしながら、かかるシステムは、図１に例解されるものよりも少ないまたは多い数の構成要素を有するシステムにおいて、同等に良好に動作し得るということが、当業者によって理解されるであろう。このため、図１におけるシステム１００の描写は、本質的に例解的なものであり、本開示の範囲を限定しないと捉えられるべきである。

図１に例解されるものといった環境は、複数のホストおよび種々のタイプのリソースが、コンテンツのサーブ、ユーザの認証、リソースの分配、またはいくつかの他のかかるタスクのうちのいずれかの実施といったタスクを実施するために使用される場合がある、種々のコンテンツプロバイダまたは他のかかるエンティティに有用であり得る。これらのホストのうちの一部は、同様の機能性を提供するように構成され得る一方で、他のサーバは、少なくとも何からの異なる機能を実施するように構成される場合がある。かかる場合における電子環境は、以下で詳細に述べられる、図２の構成２００において例解されるものといった、追加の構成要素および／または他の配設を含む場合がある。

一実施形態に従うシステムおよび方法は、データ環境の一部として、またはユーザとデータプレーンとの間の経路において、ユーザおよびアプリケーションが、共有および／または専用リソースにアクセスすることを可能にする一方で、顧客、管理者、または他の承認されたユーザが、リソースを、種々のユーザ、クライアント、またはアプリケーションに分配し、それらの分配への順守を確実とすることを可能にする、少なくとも１つのリソースアクセスゲートウェイ、または制御プレーンを提供する。かかる機能性は、ユーザが、リソースを共有する他のユーザによる待ち時間の悪化または他のかかる問題を懸念することなく、クラウドにおいて、リレーショナルデータセットを記憶、処理、およびクエリするといった、タスクを実施することを可能にする。かかる機能性はまた、ゲストユーザが、ストリーミング媒体をレンダリングおよび／もしくはサーブするといった任意の適切な機能性を実施するように、またはいくつかの他のかかる動作のうちのいずれかを実施するように、リソースへのアクセスを取得することを可能にする。本実施例は、インターネット、ウェブサービス、およびインターネットベースの技術に関して述べられるが、種々の実施形態の様態は、電子環境におけるネットワーク上で利用可能であるか、または提供される、任意の適切なリソースまたはサービスとともに使用することができるということが理解されるべきである。さらに、種々の実施例が、ディスク、データ記憶装置、ホスト、および周辺デバイスへの共有アクセスに関して提示されるが、任意の適切なリソースを、任意の適切な目的で種々の実施形態の範囲内において使用することができ、任意の適切なパラメータを、それぞれのユーザのいずれかまたは全てによって、かかるリソースのアクセスまたは使用を調節するために監視および使用することができるということが理解されるべきである。

リソースゲートウェイまたは制御プレーン２０８は、データプレーン２３２における種々のリソースへのアクセスを提供および／または管理するように、一部の環境において使用することができる。クラウドコンピューティング環境において、これは、クラウドマネージャ２１０、またはクラウドにおいて、種々のリソースへのアクセスを管理する同様のシステムに対応し得る。一実施形態において、ユーザまたは顧客が、種々のリソースへのアクセスを要求することを可能にする、一組のアプリケーションプログラミングインターフェース（ＡＰＩ）２２０または他のかかるインターフェースが提供される。一度、アクセスの確立、リソースの分配等が行われると、ユーザは、データ記憶または処理といった、そのリソースに関するあるタスクを実施するように、リソースと直接通信することができる。ユーザは、一度アクセスが確立されると、データインスタンス、ホスト、または他のリソースと通信するように、直接インターフェースまたはＡＰＩを使用することができるが、アクセスを取得するように制御プレーン構成要素（複数を含む）を使用する。

図２は、一実施形態に従って、使用することができる、クラウドコンピューティングマネージャシステムを含み得るといった、構成２００の実施例を例解する。本実施例において、エンドユーザのためのコンピューティングデバイス２０２は、指定されたリソースまたはリソースタイプへのアクセスを取得するといったタスクを実施するように、制御プレーン２０８（または他のかかるアクセス層）に、ネットワーク２０６を通じて、呼び出しを行うことができるように示される。エンドユーザコンピューティングデバイスおよびアプリケーションが、解説目的で使用されるが、種々の実施形態において、適切な場合、任意の適切なユーザ、アプリケーション、サービス、デバイス、構成要素、またはリソースが、インターフェース（複数を含む）、ならびに接続構成要素およびデータ環境の構成要素にアクセスすることができるということが理解されるべきである。さらに、ある構成要素は、データ「プレーン」にグループ化されるが、これは、それぞれの機能性を提供するために使用される、少なくとも一部のリソース（例えば、ハードウェアおよび／またはソフトウェア）の実際のまたは仮想の分離を指し得るということが理解されるべきである。さらに、制御プレーンは、ある実施形態において、データプレーンの一部であると見なすことができる。本実施形態において、単一の制御プレーンが示されるが、他の実施形態において、制御またはアクセス管理構成要素もしくはサービスの複数のインスタンスが存在し得る。制御プレーンは、コンピュータが実行可能な命令とともに構成される少なくとも１つのサーバといった、ハードウェアおよび／またはソフトウェアの任意の適切な組み合わせを含むことができる。制御プレーンはまた、ネットワーク２０６からウェブサービス呼び出しまたは他のかかる要求を受信するための一組のＡＰＩ（または他のかかるインターフェース）を含むことができ、ここで、ウェブサービス層２１２が、呼び出しに作用するまたはそれを処理するために必要とされるステップまたは行為を判断するように、解析または別様に分析することができる。例えば、ユーザに対してクエリを実行するように、データリポジトリへの接続を確立するための要求を含む、ウェブサービス呼び出しが受信される場合がある。本実施例において、ウェブサービス層は、必要とされる接続またはアクセスのタイプ、必要とされるリソースの適切なタイプ（複数を含む）、または他のかかる態様を判断するように、要求を解析することができる。

制御プレーンは、１つ以上のリソース分配マネージャ２１０を含むことができ、各々が、要求と関連付けられるユーザまたはクライアントの認証、および適切なリソース（複数を含む）へのアクセスの取得または分配といった、タスクを担う。かかるシステムは、種々のタイプの要求を処理し、種々のタイプの接続を確立することができる。かかるシステムはまた、特定のグラフィックプロセッサまたは他のタイプのハードウェアもしくはハードウェア機能性といった、種々のタイプのリソースに対する要求を処理することができ、かつ適切なリソース（複数を含む）へのアクセスを提供することができる。データプレーンの構成要素、またはクラウドのリソース層は、リソースを提供するように、必要なタスクを実施することができる。例えば、データインスタンスへのアクセスに関して、これは、データストアインスタンスのプロビジョニング、オフインスタンス永続記憶装置のボリュームの分配、永続記憶装置ボリュームのデータストアインスタンスへの取り付け、ならびにＩＰアドレス（ＤＮＳマッピングから導出）、または顧客がデータインスタンスにアクセスする、または別様に接続するために使用することができる、他のアドレス、ポート、インターフェース、もしくは識別子の分配および取り付けといった、タスクを含むことができる。例えば、特定のタイプのハードウェアを使用する命令の処理の取得といったタスクに関して、データプレーンの構成要素は、制御プレーンと併せて、ユーザのためのデバイスのプロビジョニング、ならびにリソースへの特定のアクセスレベルにおける、ある期間のリソースへの共有および／または専用アクセスの提供といった、行為を実施することができる。本実施例において、ユーザには、リソースにアクセスするために使用されるべきＩＰアドレスおよびポートアドレスを提供することができる。次いで、ユーザは、制御プレーン２０８にアクセスする、またはそれを通過することを必要とせずに、ＩＰアドレスおよびポートを使用して、直接、リソースにアクセスすることができる。

本実施形態における制御プレーン２０８はまた、少なくとも１つの監視構成要素２１４を含む。データインスタンスまたは他のリソースが分配される、作成される、またはそうでなければデータプレーン内で利用可能とされる時、リソースに関する情報は、監視データストア２１６といった、制御プレーンにアクセス可能なデータストアに書き込むことができる。監視データストアは、別個のデータストア、または別のデータストアの一部分とすることができるということが理解されるべきである。監視構成要素２１４は、種々のユーザによるリソースの過去の使用、ユーザに分配されているスレッドまたはリソースの現在の数もしくはタイプ、および他のかかる使用情報といった情報を判断するように、監視データストア２１６内の情報にアクセスすることができる。監視構成要素はまた、データ環境における所与のユーザに対するアクティブな接続の数、および各接続の使用についての態様といった情報を判断するように、データ環境の構成要素を呼び出すことができる。監視構成要素は、常に、接続マネージャを通じて提供される分配を有する、ユーザ、クライアント等による、各リソースの使用を監視することができる。監視構成要素はまた、ユーザに与えられる一般的な分配、ユーザに対するスロットリングまたは制限情報、ユーザに対するリソース許可、またはアドミニストレータもしくは他のかかるユーザによって指定および／または更新することができる任意の他のかかる情報といった情報を記憶することができる、管理（「Ａｄｍｉｎ」）または同様のデータストア２１６に記憶される情報にアクセスすることができる。

ユーザが、種々のデータインスタンスへの接続を要求する実施例において、データ環境における各インスタンス２２２は、少なくとも１つのデータストア２２６と、データストアへのアクセスを提供する機械のためのホストマネージャ構成要素２２８とを含むことができる。一実施形態におけるホストマネージャは、ソフトウェア開発およびデータストア動作、ならびにデータストアおよび／またはそれぞれのインスタンスの状態の監視といったタスクを管理するようにプログラムされる、ＴｏｍｃａｔもしくはＪａｖａ（登録商標）アプリケーションサーバといった、インスタンスおよび／またはアプリケーションサーバ上で実行される、アプリケーションまたはソフトウェアエージェントである。ホストマネージャは、論理ボリュームおよびファイルシステムのセットアップ、データベースバイナリおよびシードのインストール、ならびにリポジトリの開始または停止を含む、新しいリポジトリに対するインスタンスのセットアップといったタスクの管理および／または実施を担うことができる。ホストマネージャは、データストアの健全状態を監視することができ、Ｉ／Ｏエラーまたはデータ記憶装置エラーといったエラー条件に関して、データストアを監視し、必要な場合、データストアを再起動することができる。ホストマネージャはまた、ソフトウェアパッチのインストール、ならびにデータストアおよび／またはオペレーティングシステムのアップグレードを実施および／または管理することができる。ホストマネージャはまた、ＣＰＵ、メモリ、およびＩ／Ｏ使用に関し得るといった、関連メトリックを収集することができる。

リソースマネージャ２１０は、負荷、使用、容量等といったステータス情報を判断するように、接続が確立されている各ホストマネージャ２２８と、またはリソース環境の管理サーバもしくは他の構成要素に、定期的に通信することができる。

述べられるように、一度リソースがプロビジョニングされ、ユーザに、ＤＮＳマッピングから導出されるＩＰアドレス、または他のアドレスもしくは場所が提供されると、ユーザは、リソース２２２と直接相互作用するように、Ｊａｖａ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）または他のかかるプロトコルを使用して、ネットワークを通じて、データプレーン２３２の構成要素またはリソースと「直接」通信することができる。種々の実施形態において、述べられるように、データプレーンは、コンピューティングクラウド環境、あるいは「クラウド」、またはハードウェアおよび／もしくはソフトウェア構成要素の動的ネットワークにわたり、データ記憶装置およびアクセスを提供する、一組のウェブサービスおよびリソースの形態を採る（または少なくともそれらを含むか、もしくはそれら一部である）。例えば、インスタンスまたは利用可能性障害は、使用のための任意の適切な置換インスタンスにＩＰアドレスをプログラムで再マッピングすることによって、マスクすることができるため、ＤＮＳマッピングから導出されるＩＰアドレスは、かかる動的クラウド環境において有益である。例えば、ユーザ２０２またはアプリケーション２０４から受信される要求を、ネットワークアドレス翻訳（ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｉｏｎ：ＮＡＴ）ルータ２２４、または他の適切な構成要素に方向付けることができ、これは、実際のリソース２２２、または要求のマッピングされたアドレスに対応するホストに、要求を方向付けることができる。かかる手法は、ユーザまたはアプリケーションが、インスタンスにアクセスするために使用されるＩＰアドレスまたは他のアドレスを変更することを必要とせずに、インスタンスが、動的に移動されること、更新されること、複製されること等を可能にする。一部の場合において、データインスタンスといったリソース２２２は、少なくとも１つのバックアップインスタンス２３０またはコピーを、永続記憶装置内に有することができる。

述べられるように、リソースは、様々なアクセスまたは分配レベルでもって、同時、または異なる時間のいずれかに、複数のユーザ、クライアント、アプリケーション等間で共有することができる。ユーザが、機械またはリソースへの専用アクセスを有する時、ユーザはまた、必要とされるアクセスのタイプ、および他のかかる要因に依存して、ある期間、リソースへのネイティブまたは「ベアメタル」アクセスを有する場合がある。デバイスへのネイティブアクセスを有するユーザは、リソースに対するファームウェアまたは他の構成情報を修正する能力を有し得、これは、その後のユーザが、最初に再イメージングすること、またはそうでなければリソースの状態を照合することなく、リソースを利用する能力に影響し得るため、リソースへのこのレベルのアクセスの提供は、リソースのプロバイダに対する潜在的なリスクを伴う。

種々の実施形態は、プロバイダが、ユーザまたは顧客に、妥当なレベルのセキュリティを有するハードウェアリソースへの実質的に完全なアクセスを与えることを可能にする。リモートハードウェアへのこのネイティブレベルアクセスは、例えば、サーバ、ホスト、およびクラスタインスタンスといったリソースに提供することができる。クラスタインスタンスといったリソースに関して、顧客は、周辺構成要素相互接続（ｐｅｒｉｐｈｅｒａｌ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔ：ＰＣＩ）バスといった構成要素を使用して接続される周辺デバイスを含み得るといった、ハードウェアリソースのサブセットへのネイティブアクセスを有し得る。これらの周辺デバイスは、ネットワークインターフェースカード（ＮＩＣ）、グラフィック処理装置（ＧＰＵ）、および、現在のクラウド環境において、しばしば、仮想化されるであろう同様のデバイスを含むことができる。一部の場合において、顧客は、その中に組み込まれる任意もしくは全てのデバイスを含む、機械全体、または機械群への完全なアクセスを有する場合がある。サーバのラックといった機械群に関して、ユーザには、ラックの一部として提供される任意のスイッチまたは他のデバイスもしくは構成要素を含む、ラック全体への実質的に完全なアクセスが与えられる場合がある。

あるプロバイダは、物理的ハードウェアの管理を「より信頼できる」実行コンテキストにおいて行うことができるように、また実行を中断することなく、異なるリソースへ顧客を移行させる能力、ならびに顧客または「ゲスト」は特定のハードウェアに結び付いていないため、その価格で最良のユーティリティのコンピューティングの価値を提供することを競合するベンダの能力といった、追加の利益を提供することができるように、かかるハードウェアリソースを仮想化された抽象として提示する。また、ゲストは、多数のハードウェア固有のドライバを必要としないため、より少ないかつより単純なゲストインスタンス画像を使用することができる。しかしながら、仮想化は、仮想化のためのネイティブ加速を含まないハードウェアに対する、桁違いの性能ペナルティを招く可能性があり、特定のハードウェアデバイスの仮想化は、そのデバイス（例えば、ネットワークインターフェースを仮想化するために使用されるプロセッサおよび／またはメモリ）と無関係の相当なリソースを消費する可能性があるため、かかる仮想化は、潜在的に著しい費用を伴う可能性がある。また、仮想化サポートは、新しいハードウェア（例えば、ビデオカード）の商品の利用可能性より数年遅れる可能性があり、あるアプライアンスハードウェアは、しばしば、特殊すぎるか、または「ニッチ」であり、強力な仮想化サポートを保証することができない。利益率の高いニッチアプライアンスのサポートにおける、または新しいハードウェアタイプのクラウドサポートに対して市場初となることにおける、潜在的に大きい市場機会が存在する。しかしながら、ネイティブアクセスを通じてかかるサポートを提供することは、例えば、プロビジョニング技術、支払請求、リソース利用および均衡化、ならびにネットワーク層２レイアウトといった、内部クラウドの種々の態様を脆弱なままにする可能性があり、顧客要件をはるかに超えて、脅威モデルを侵害する可能性がある。

種々の実施形態は、ホストハードウェア、または周辺制御バスもしくは同様のハードウェアデータ経路にプラグインされるカードといった特定のデバイスへのネイティブアクセスをユーザに提供することによって、ホストサーバといったリソースへの「部分的」または「実質的に」完全なアクセスを提供することができる。特定のレベルの性能が問題である、ある実施形態において、入力／出力メモリ管理装置（Ｉ／Ｏ ＭＭＵ）といった技術は、周辺デバイスをゲストオペレーティングシステムに「割り当てる」ために使用することができ（例えば、指定Ｉ／Ｏ（ＩｎｔｅｌのＶＴ−Ｄ）のための仮想化技術）、それらの周辺デバイスのみへのネイティブアクセスを効果的にゲストに与える。当業者には明らかであるはずであるように、ゲストオペレーティングシステム（ＯＳ）は、ホスティングプロバイダの管理制御下にない、ＢＩＯＳ、構成等を含む、ＯＳもしくはハイパーバイザが依存する、何らかのハードウェアまたは機械状態への少なくとも部分的に仮想化されていないアクセスを有する、実行中のＯＳをホストする仮想機械といった、異なる実施形態における、異なるシステムを指すことができる。他の実施形態において、ゲストＯＳは、完全な仮想化を伴わずに実行するホスティングプロバイダの管理制御下にないＯＳを指す場合がある。一実施形態において、ＭＭＵは、直接メモリアクセス（ＤＭＡ）可能なＩ／Ｏバス（例えば、ＰＣＩバス）を、ホスト上の主メモリへ論理的に接続することができ、ゲストから種々のＰＣＩまたは同様のデバイスへの情報の流れを調整するように、物理アドレスへのＩ／Ｏデバイスのマッピングを管理することができる。これらのデバイスは、例えば、グラフィック処理装置（ＧＰＵ）コプロセッサ、高性能ＮＩＣ、ディスクコントローラ、または暗号カードもしくはハードウェアコードといった他の「ニッチ」共処理デバイスを含むことができる。一部の例において、仮想化または他のかかる技術は、ネイティブアクセスを、所与のホスト上の特定のデバイスに対して潜在的に利用可能にしながら、中央システムハードウェア（例えば、ＣＰＵ、メモリ等）から、ゲストとホスト機械との間のあるレベルの分離を提供するために使用することができる。他の実施形態において、ネイティブアクセスは、特定のホストに含まれるか、またはそれに対して利用可能ないずれのハードウェアにも提供することができる。

特定のハードウェアへのネイティブアクセスを顧客に提供することに関する主な問題のうちの１つは、顧客が、ホストハードウェア上の特権的構成もしくはＢＩＯＳ（基本Ｉ／Ｏシステム）設定、または他のファームウェア画像を修正する能力を有し得るということである。これらの変更は、物理的システムの再起動後も持続し得るため、ハードウェアが、その顧客がホストもしくはそのデバイス（複数を含む）へのアクセスを与えられる前のハードウェアと同じ状態に戻ることができない。例えば、Ｒｉｎｇ−１ハイパーバイザによって管理される仮想機械モニタ（ＶＭＭ）に対する動的に構成可能な設定の場合、変更は、一般的に、起動後までは持続しないが、仮想化された環境（例えば、ＩＯＭＭＵ技術をサポートするためのチップセット設定）における、ゲストオペレーティングシステムのインスタンス化後まで持続する可能性がある。顧客が本来不変であるべき設定またはファームウェアを修正するこの能力は、深刻なセキュリティへの影響を有し得る。例えば、悪意のあるソフトウェア（例えば、トロイの木馬またはウイルス）が、種々のデバイスのためのファームウェアに挿入される可能性がある。しかしながら、ファームウェア変更が、意図的に悪意のあるプログラミングを含まない場合でさえも、変更は、依然として、性能および／または互換性問題を引き起こすことによって、非意図的に損害を与える可能性がある。ファームウェアフラッシングは、潜在的に、ハードウェアを回復不可能なほどにまでに物理的に破壊する可能性がある（ハードウェアの「ブリッキング」としても知られる）。これらの課題のうちの少なくとも一部に、特に、マザーボードファームウェアまたはチップセット構成に対して、対処することができる、ある技術が開発されている。これらの技術には、例えば、信頼されるプラットフォームモジュール（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：ＴＰＭ）、ＩｎｔｅｌからのＬａＧｒａｎｄｅ技術（ＬＴ）、メジャーブート技術、トラステッドブート技術、信頼性の動的ルート（Ｄｙｎａｍｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ：ＤＲＴＭ）、および信頼性の静的ルート（Ｓｔａｔｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ：ＳＲＴＭ）技術が挙げられる。しかしながら、これらのソリューションのいずれも、デバイスファームウェア、ホスト全体、および他のかかるハードウェア態様に固有の種々の問題に対処することは知られていない。

種々の実施形態に従うシステムおよび方法は、クラウドまたは同様の電子環境における、ゲストによる、ファームウェア画像または構成情報へのアクセスおよび／またはそれらの操作を阻止および／または監視することができる。ある実施形態において、顧客には、数時間またはさらには数分といった、任意の所望の期間、ハードウェアリソースへの専用ゲストアクセスを提供することができる。図３は、一実施形態に従う、顧客にかかるネイティブアクセスを提供するために使用することができる、構成３００の実施例を例解する。本実施例は、従来のＰＣＩベースの技術を使用して、ホスト機械における周辺デバイスへのアクセスをユーザに提供することに関して述べられるが、これは、例に過ぎず、種々の実施形態の範囲内の手法を、かかる目的で現在使用されるか、またはその後開発される、任意の適切なハードウェア（異なるバス技術に基づく、または個々の構成要素または「チップ」内のより大きなもしくはより小さな程度のシステム統合を伴うものを含む）、ソフトウェア、およびプロトコルとともに使用することができるということが理解されるべきである。

本実施例の構成３００は、各々が、一連のネットワークポート３０４を有することができる、サーバまたは同様のデバイスといった、一組のホストデバイス３０２を含む。これらのポートの一部は、各デバイスへの／からのネットワークトラフィックを処理およびルーティングすることが可能な少なくとも１つのネットワークスイッチ３０６へ、各ホストを接続する、「生産」ポートとして機能することができる。一部の実施形態において、ネットワークスイッチは、「スマート」ネットワークスイッチとすることができる一方、他の実施形態において、スイッチの第１のティアよりも、ネットワークにおけるより高いレベルで分離を行うことができる。データセンタの実施例において、例えば、サーバ３０８の各ラックに対して、１つのスマートスイッチが存在する場合がある。これらのネットワークポート３０４のうちの少なくとも１つは、ゲストオペレーティングシステムのためのトラフィックをホストすることができ、ここで、ゲストは、この生産ネットワークポートへのアクセスを有する、分配された、またはパーティションされたホストデバイス（例えば、サーバ）３０２における、少なくとも１つの中央処理装置（ＣＰＵ）３１０「の上部で」効果的に動作している。ホストデバイス３０２はまた、少なくとも１つのコンソールポート３１２と、コンソールコントローラ３１４とを含むことができ、別個のコンソールネットワーク３１６に接続することができる。この「コンソールネットワーク」はまた、イーサネット（登録商標）技術といった、「生産ネットワーク」と同じネットワーク技術を使用して、実装することができる。一部の実施形態において、これらのポートのうちの少なくとも一部は、マージすることができるが、論理的には分離（例えば、同じ物理的ポート上で多重化）される。各ホストデバイスはまた、コンソールコントローラおよび／または主ＣＰＵによってアクセスすることができる、１つ以上の専用電源装置（ＰＳＵ）３１８を有することができ、それにより、機械は、例えば、ホストＣＰＵまたはネットワーク上のデバイスのいずれかを介して、電源をオフにすることができる。ラック内の全てのサーバのための電源は、ラック電力分散装置（ＰＤＵ）３２０に接続することができ、これは、１つ以上のデータセンタＰＤＵ３２２へより高い電力ケーブルによって接続することができ、これらの各々は、複数のラックＰＤＵをサポートすることができる。一部の場合において、ホスト３０２は、各デバイスに電力サイクルを行うように、リレーまたは他のかかる構成要素を用いて、ラックＰＤＵからコンソールコントローラへラインを引くことによって、電源をオンおよびオフにすることができる。

少なくとも１つのルータ３２４は、ホストデバイスを、１つ以上のプロビジョニングシステム３２６へ接続することができ、スイッチおよび／またはルータは、これらのプロビジョニングシステムへのアクセスを管理することができる。一部の実施形態において、ラック内のネットワークトラフィックは、各ラックから出るケーブルの数を最小化するために、集約される。一部の実施形態において、起動前実行環境（ＰＸＥ）といった能力は、電力をコンソールを使用してサイクルすることができ、かつ機械がＰＸＥを起動する時、コードをネットワークポート上で実行することができるように、生産ネットワークポート３０４において、ホスト機械３０２上に存在する。ＰＸＥアクセスもまた、承認されている再起動のタイプに依存して、有効化または無効化され得る。例えば、再起動は、顧客が開始する再起動に対して、ホスト上のローカルイメージから可能であり得るが、ＰＸＥアクセスは、上流では無効化され得る。スイッチ３０６が、ホスト機械３０２をプロビジョニングシステムに接続するように構成される時、ＰＸＥは、デバイスをプロビジョニングシステムに接続し、機械を、例えば、ＲＡＭ（ランダムアクセスメモリ）ディスクまたは記憶装置の他のブロックで起動することができ、これは、新しい顧客イメージのファームウェアフラッシングまたはプロビジョニングといった制御動作を有効にする。一実施形態における、特殊ドライバを有するＲＡＭディスクは、そうでなければ、特定の機械上で起動することができない場合がある、信頼されない、または不明なイメージを起動および／または実行するために使用することができる。このように、プロビジョニングイメージは、ネットワーク上でＰＸＥへ受信することができ、これは、プロビジョニングコードまたはファームウェアフラッシングコードを含有する。一度プロビジョニングが完了すると、承認された顧客ネットワーク３２８は、スイッチ３０６を介して、デバイス３０２と相互作用することができる。プロビジョニングおよび制御システムは、その経路の自動切り替えが、例えば、プロビジョニング事象および外部調整に基づくことができるため、ヒトが関与することなく、リアルタイムでスイッチを制御することができる。調整は、クラウドマネージャデータベースおよびシステム３３０、またはある行為を実施するように、プロビジョニングシステム（複数を含む）３２６、コンソールネットワーク３１６、およびラック構成要素に命令することができる、本明細書の他の個所で述べられるような、他のかかる制御プレーンまたは制御システムといった、外部システムによって、提供および／または管理することができる。クラウドマネージャ３３０は、リソース管理の種々の態様を実施するように、一実施形態においては、中央データベースと協働する、１つ以上のワークフローシステムを含むことができる。

異なる物理的サーバが、異なる時間に、顧客をホストするために使用され得る、クラウドコンピューティング環境といった環境において、経時的に変化する可能性があるリソース分配への依存を回避するように、ユーザまたは顧客ネットワークに対する、あるレベルの抽象を提供することが望ましい可能性がある。顧客ネットワークルータおよび顧客ネットワークファイアウォールといった、仮想ネットワーク機器提示もまた、オーバーレイネットワーキング技術を使用して、達成することができる。例えば、複数のコンピューティングノード間の顧客の仮想ローカルネットワークまたは他の仮想ネットワークは、複数のコンピューティングノードを分離する、１つ以上の中間物理的ネットワーク上で、オーバーレイネットワークを創出することによって、少なくとも一部の実施形態において、提供することができる。オーバーレイネットワークは、例えば、通信をカプセル化すること、および１つ以上の中間物理的ネットワークのネットワーキングプロトコルのために使用される、より大きな物理的ネットワークアドレス空間において、仮想ネットワークのための仮想ネットワークアドレス情報を埋め込むことによって、種々の実施形態において、種々の方法において実装することができる。

これは、顧客が、顧客ネットワークにおいてリソースをアドレスするための標準化されたアドレス空間を利用することを可能にする。標準化されたアドレス空間を利用することによって、顧客は、サブストレートネットワークが物理アドレス空間を制限することなく、共通のベースアドレス、サブネットワーク等を使用することができる、「仮想」またはオーバーレイネットワークを創出することができる。

仮想化を使用して、顧客ネットワークの一部であるとして、ユーザに対して表示され、機能するが、別個またはリモートクラウド、ネットワーク等において、実際のサーバまたは他の物理的リソースにマッピングされる、いくつかの仮想機械インスタンスを生成することができる。述べられるように、標準化されたアドレス空間の使用は、物理的サブストレートアドレスと、顧客アドレス空間のために使用される仮想オーバーレイアドレスとの間のマッピングの構築および維持を必要とし得る。一部の既存の手法において、ホストデバイス上で実行する中央処理装置は、顧客から受信される要求を、適切なリソースに方向付けることができるように、仮想および物理アドレスのマッピングを制御することができる。これは、例えば、データパケットカプセル化および脱カプセル化の形態を採ることができ、物理アドレスおよび／またはヘッダ情報は、パケットを、顧客ネットワーク上の送信元によって、仮想アドレスへアドレスすることができるが、クラウドまたはリモートネットワークインフラにある時、物理的ヘッダ情報を追加することによって、適切な物理アドレスへ適切にルーティングすることができるように、仮想アドレスおよび／またはヘッダ情報とともに、種々の時間に、「共存する」ことができる。

例えば、図４は、一実施形態に従い、仮想クラウド環境がホストされる、物理的サブストレートネットワーク内でルーティングされるために、顧客または「オーバーレイ」ネットワークから受信されるパケット４００が、カプセル化される、実施例を例解する。本実施例において、受信された顧客パケット４００は、仮想アドレス４０２（ここでは「ＩＰ_ｖ」と示される、顧客オーバーレイネットワークに関連する「仮想ＩＰアドレス」等）、プロトコルヘッダ４０４（ここでは「ＴＣＰ_ｏ」と示される、インターネットプロトコル群において見出されるような元の伝送制御プロトコルヘッダ等）、およびデータまたは「ペイロード」部分４０６という、３つの主要部分を含む。仮想ＩＰアドレスは、顧客またはオーバーレイネットワークにのみ関連するアドレスとすることができる。意図される送信先ホストにパケットを適切にルーティングするために、このパケットは、サブストレートネットワークもしくはクラウド、または他のかかるリソース群内で、パケットをルーティングすることができる、「外部」データ構造またはフレームを含むように、カプセル化することができる。本実施例において、カプセル化プロセスは、「サブストレート」パケットまたはデータグラム４１０を生成するように示され、これは、元の顧客パケットのＩＰ_ｖ、ＴＣＰ_ｏ、およびペイロードを含むが、ここでは、物理的または「実」アドレス４１２（クラウドのサブストレートネットワーク内のＩＰアドレスもしくは「ＩＰ_Ｒ」等）、ならびに制御ヘッダ４１４（パケットを処理および／もしくはルーティングするように、制御プレーンによって有用なプロトコルヘッダ等）を含む、そこに追加される追加の「ヘッダ」情報を有する。顧客ルーティング情報（例えば、４０２によって具現化される）は、顧客のオーバーレイネットワークにのみ意味があり、クラウドホストリソースが接続される物理的ネットワーキングインフラには意味がないため、この「実」情報のうちのいずれも追加しなければ、ルータ、およびクラウドインフラをホストする他のかかる構成要素は、一般的に、適切な送信先（複数を含む）にパケットを適切にルーティングすることができないであろう。一部の実施形態において、クラウド内のデバイスへ受信されているいずれの顧客パケットも、クラウド内で使用されるべきこの物理的ルーティング情報を含むように、カプセル化することができる。クラウド内でパケットを受信する第１のデバイスは、クラウドの「エッジ」上にあると見なすことができるため、これらのデバイスは、本明細書において「エッジ」デバイスと称される。「エッジ」デバイスは、本明細書において使用される際、クラウドの外側から情報のパケットを受信することが可能な、ならびに／またはクラウドの内側から情報のパケットを伝送することが可能な、ハードウェアおよび／もしくはソフトウェアにおける任意のデバイスを指すことができる。カプセル化プロセスは、一部の実施形態において、任意の適切なエッジデバイスにおいて行われ得る一方、他の実施形態において、エッジデバイスは、カプセル化構成要素、またはパケットをカプセル化もしくは脱カプセル化することが可能な他のデバイスに、パケットをルーティングすることができる。理解されるべきであるように、パケットが顧客ネットワークに伝送し戻されるか、またはそうでなければ、クラウドの外側に伝送される時、「脱カプセル化」プロセスを実行することができ、ＩＰ_Ｒ４１２および制御ヘッダ４１４が除去され、パケットは、顧客ネットワークに対する仮想アドレス空間情報を使用して、ルーティングすることができる。簡略化の目的上、カプセル化のプロセスは、種々の実施形態に関して述べられるが、脱カプセル化プロセスはまた、種々の実施形態に従って、かかる構成要素およびプロセスを使用して、実施することができるということが理解されるべきである。

ある従来の手法は、ホストデバイスおよびサーバといったハードウェア上で、あるレベルのカプセル化を実施する。これらの手法において、中央プロセッサは、ネットワークポート、ネットワークインターフェースカード（ＮＩＣ）、または同様のデバイスへ受信されるパケットをルーティングするために、カプセル化手順を実施することができる。カプセル化プロセスは、一般的に、ユーザには露出されない。一部の実施形態において、ＮＩＣのためのドライバは、ＮＩＣを介して、顧客ネットワークへの、またはそれからのパケットをルーティングする前に、プロセッサが、物理的サブストレートパケットを仮想オーバーレイパケットにマッピングする（逆も同様）ように、マッピング機構または分散マッピングサービスにアクセスすることができるように、プロセッサによって直接アクセス可能であろう。一部の場合において、マッピング情報は、集中型のサービスから、クラウドにわたって、各適切なノードに分散させることができる。

しかしながら、述べられるように、リソースプロバイダは、ホスト機械といったハードウェアリソースへの実質的に完全なネイティブアクセス、または「ベアメタル」アクセスを、ユーザまたは顧客に提供する能力を欲する場合がある。例えば、マッピングが、ホスト機械のＣＰＵ上で実行するアプリケーションによって管理される場合、そのマッピングは、潜在的に、ホスト機械上で実行する、ユーザまたはゲストオペレーティングシステム（ＯＳ）によって、アクセスすることができる。かかるアクセスは、潜在的に、マッピングサービスを損ない得、ゲストオペレーティングシステムが、パケットをリダイレクトする、パケットを拒絶する、またはそうでなければ、クラウドネットワークにおけるパケットの処理に影響を及ぼすことを可能にし得る。さらに、かかる機能性は、パケットを、クラウドの外側の意図されない場所へ送信することができるように、損なわれる可能性がある。他の潜在的な問題には、ホストが、異なるホストまたは場所から発信するように見えるパケットを送信する、「パケットスプーフィング」が含まれる。これは、しばしば、どこから敵対攻撃が来ているかを難読化するために使用され、また、標準的なネットワークプロトコルの一部である、確認パケットが、伝送等を開始していないホストに送信される、「ＡＣＫベース」のサービス妨害（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ：ＤｏＳ）攻撃の基本でもあり得る。種々の他の潜在的な問題が、ゲストＯＳまたはＣＰＵが、潜在的に、マッピングおよび／またはカプセル化機能性へのアクセスを有する時に生じる。

したがって、種々の実施形態に従うシステムおよび方法は、プロビジョニングされたホスト機械または操作の他のかかる潜在的な送信元上の顧客、ゲストＯＳ、ＣＰＵに露出されない構成要素を使用して、カプセル化、脱カプセル化、およびステートフルなファイアウォール動作といった動作を実施しつつ、種々のユーザによる、リソースへの実質的な「ベアメタル」アクセスを提供することができる。図５は、種々の実施形態に従う、パケット処理および他の安全なネットワーキング機能を実施するために使用することができる、構成５００の実施例を例解する。本実施例において、パケットは、例えば、パケットが、物理的相互接続伝送のためにフレーム化される（例えば、イーサネットフレーム化）直前に、ここではネットワークカードレベルにおいて、顧客アクセス可能なホストリソースの「上流」でカプセル化される。本実施例において、オフロードデバイス５０６は、クラウドマネージャ５０４およびマッピングサービス５０２といった構成要素と通信することができる、外部ポート５０８を有するということを見ることができる。外部ポート５０８は、これらの構成要素が、ホスト機械５１６上のＣＰＵ５１４、またはホスト機械上でプロビジョニングされる任意のゲストイメージ５１８もしくはゲストＯＳから独立して、オフロードデバイスと通信することを可能にすることができる。かかる手法を使用して、クラウドへ、またはそれから伝送されるいずれのパケットも、マッピングが、ユーザにアクセス可能ではないか、またはユーザによって修正可能ではないように、ゲストアクセス可能な部分から独立して処理することができる。本実施例において、オフロードデバイスは、メモリ５１０と、少なくとも基本的なマッピング、カプセル化、脱カプセル化、および／または同様のかかる機能を実施することが可能な処理デバイス５１２とを有することができる。これは、概して、本明細書において「オフロードデバイスベースの」カプセル化と称されるが、他の周辺デバイスまたはハードウェア構成要素が、同様の機能性を実施することができるということ、および機能性は、カプセル化に限定されず、脱カプセル化、ファイアウォール等といった他の機能も含むことができるということが理解されるべきである。オフロードデバイスは、ユーザまたはゲストオペレーティングシステムに露出されない、ホスト機械内の埋め込みシステムとして、機能することができる。ユーザが、オフロードデバイスの機能性のうちの少なくとも一部へのネイティブアクセスを欲する可能性がある場合、オフロードデバイスは、一部の機能性のみにアクセスすることができるように、ゲストＯＳに対してマッピングされる、あるメモリ部分のみを有することができる。一部の実施形態において、これは、ゲストＯＳが、オフロードデバイスの部分を発見および／または利用することができるが、カプセル化といった安全な行為に対して利用される部分にはアクセスすることができない、仮想オフロードデバイスイメージの形態を採ることができる。

オフロードデバイスベースのカプセル化機能性は、ホスト単位で、あるいは、少なくとも、パケットを受信および／もしくは伝送することが可能な、ならびに／またはそれにプロビジョニングされる顧客イメージを有することが可能な、それらのホスト機械に対して、提供することができる。かかる場合において、クラウドマネージャ５０４、または同様の構成要素もしくはシステムは、種々のホストおよび／またはノードへのマッピング情報、ならびにかかるプロセスに対して有用な他のかかる態様および構成情報の分散を管理することができる。かかる場合において、クラウドマネージャは、構成情報、ファームウェア、またはカプセル化および同様のかかる行為を実施するために有用な他の情報を更新するように、外部ポート５０８を介して、オフロードデバイス５０６と通信することができる。外部チャネルを介して構成情報を更新するためのプロセスは、参照することによって、本明細書に組み込まれる、２００９年９月４日出願の同時係属の米国特許出願第１２／５５４，６９０号［代理人整理番号第０２６０１４−０１０７００ＵＳ号］において開示される。かかる手法を使用して、オフロードデバイスのためのファームウェアおよび／または構成情報は、所望の機能性を実施するように、ならびにマッピングサービス５０２、または必要とされる他の適切な構成要素（複数を含む）と通信するように、更新することができる。構成は、例えば、大きいペイロードを送信する、またはそうでなければオフロードデバイスの機能性を調節するように、クラウドマネージャおよび／またはマッピングシステム（複数を含む）によって管理することができるように、定期的に更新することができる。

一部の実施形態において、カプセル化および同様のプロセスは、ホスト機械５１６のオフロードデバイス５０６および／またはネットワークポート５２０への、およびそれらからのメッセージをルーティングするように構成される、スマートスイッチ５２０といった、ユーザに露出されない、他の構成要素において実行することができる。かかるスイッチは、パケットのカプセル化といった動作を実施するように動作可能なプロセッサ５２２を含むことができ、それにより、スイッチは、パケットを処理し、それを物理的および／または仮想アドレス空間における適切なアドレスへルーティングすることができる。かかる場合において、ホスト機械は、（アドレス空間の観点から）クラウド、または信頼される環境の外側にあると見なされ得、それにより、スイッチは、エッジデバイスとして機能し、ホスト機械（およびクライアントネットワーク）の仮想アドレス空間から、クラウドにおけるリソースの物理アドレス空間へ受信されるパケットを修正することができる。種々の実施形態の範囲内のルータまたは専用エッジデバイスといった、種々の他の構成要素も使用することができる。

多くの従来のシステムにおける制限の１つは、物理的伝送経路または「ワイヤ」が、１．５ＫＢまたは９ＫＢパケットといった、比較的小さい情報のパケットのみを可能にすることができるということである。より小さいパケットの使用は、厳密には、物理的考慮ではなく、歴史的およびプロトコル定義の理由にも起因する。例えば、ほとんどまたは全てのリンクが切り替わり、伝送速度が高い、現代のネットワークにおいて、この制限は、衝突を耐えられないほど増加させることなく、数桁増加され得る。オフロードデバイスといった物理的ネットワークインターフェースが、１．５ＫＢもしくは９ＫＢのパケットを伝送または受信することができるのみである場合でさえ、少なくとも一部の実施形態において、より大きいパケットを、ＤＯＭ−ＵからＤＯＭ−０ネットワークスタックへ、およびオフロードデバイス上へ伝送し、かつオフロードデバイスに、より大きいパケットを複数の１．５ＫＢもしくは９ＫＢのパケットにセグメント化させることが望ましい。多くの商品オフロードデバイスは、この要件に対処するように、セグメント化オフロードといった高度な機能性をサポートする。セグメント化オフロード能力を有するオフロードデバイスは、比較的大きいパケットを受信および／またはバッファするように、ならびにそれらのより大きなパケットを、１．５ＫＢ、９ＫＢ、もしくは他のかかるサイズ制限に準拠する、より小さいパケットもしくはイーサネットフレームにセグメント化またはフレーム化するように、構成することができる。これらのパケットを受信するデバイスは、複数のより小さいパケットに基づいて、より大きなパケットを再組み立てするように構成することができる。

多くのオフロードデバイスは、高速ネットワーキングを支援することができる、ＴＣＰセグメント化オフロードといった、高度な特性を提供する。種々の実施形態に従うシステムおよび方法は、顧客が、顧客アドレス空間とプロバイダネットワークアドレス空間との間に位置するホストデバイスへのアクセスを有するといった、「仮想」ネットワーキングを提供するように、かかる特性を活用することができる。典型的に、セグメント化オフロード機能性は、ＴＣＰといった公知のレベル４（「Ｌ４」）プロトコルのみで作用する。パケットが、図４に関して前項において説明されるもののようにカプセル化される時、Ｌ４プロトコルは、ＴＣＰ以外の何かに変更される。このため、オフロードデバイス上のセグメント化オフロード特性は、かかるカプセル化されたパケットで作用することができない。物理的ハードウェア（「レベル１」）と、そのハードウェア上で実行されるアプリケーション（「レベル７」）との間の層を説明するために当該技術分野において使用されるように、レベル４は、「プロトコル」レベルを指し、インターネットプロトコルの場合、伝送制御プロトコル（ＴＣＰ）およびユーザデータグラムプロトコル（ＵＤＰ）といったプロトコルを指すことができる。受信サイドのＴＣＰセグメント処理は、ＴＣＰセグメントペイロードが、完全に顧客データ（または他のかかるデータ）であると仮定する。したがって、メタデータの追加は、受信サイドが、カプセル化／脱カプセル化メタデータを有するパケットペイロードを破損することにつながるため、伝送サイド上では、カプセル化関連のメタデータは、元のＬ４ヘッダを保持するために、Ｌ４ペイロードへ追加することができない。

既存のカプセル化および／またはオーバーレイネットワーク実装に伴う別の潜在的な問題は、ヘッダが、しばしば、ルーティングおよび負荷均衡の目的で、従来のハードウェアデバイスによって利用される、物理的ポート情報を含まないということである。

種々の実施形態は、偽装の、または一部の場合において、元のポート番号を有する偽装ＴＣＰヘッダを利用することができ、ヘッダが、確立されたプロトコル規則（例えば、ＴＣＰオプション）に従って拡張され、カプセル化／脱カプセル化情報は、プロトコル拡張において渡される。例えば、「偽装」ＴＣＰヘッダは、任意の適切なＴＣＰ関連の情報に加えて、任意の慣例に応じたポート情報を含むことができる。多くの従来のハードウェアデバイスは、少なくとも部分的に、ヘッダにおいて指定されるポートに基づいて、負荷分散決定を下すため、この偽装ポート情報を含むことによって、従来のルータおよび他のかかるデバイスは、改善された負荷分散を得ることができる。ルータまたはオフロードデバイスは、例えば、ＩＰアドレスおよびＴＣＰ情報を見ることができ、かつパケットを標準的なパケットとして処理することができる。かかる手法はまた、主に、従来のハードウェアデバイスおよびネットワークを使用するソフトウェアにおいて実装することができるため、有利であり得る。

レベル４ペイロード（上で述べられるように、ネットワークスタックにおいて）を変更しない、プロトコルもまた、使用することができる。ユーザから受信される元のパケットは、仮想ＩＰアドレス（ネットワークスタックにおけるレベル３）、および元のＴＣＰヘッダ（レベル４）とともに、ペイロード（ここでは、レベル４ペイロード）を含むことができる。先で述べられるカプセル化手法を使用して、制御ホストは、物理的または安全なネットワークにおいて、パケット（もしくはフレーム）をルーティングする上で使用するために、ＩＰ_Ｒといった実アドレス、偽装ＴＣＰヘッダ、ＴＣＰ_Ｆ（もしくは、例えば、ＵＤＰ_Ｆ）を取り付けることができる。カプセル化後のパケットに関して、元の仮想ＩＰアドレス、ＴＣＰ（もしくはＵＤＰ等）、およびペイロード情報は、ここで、効果的に、レベル４ペイロードを形成し、ＩＰ_Ｒは、レベル３アドレスを形成し、ＴＣＰ_Ｆは、レベル４プロトコルヘッダを形成する。パケットは、元のまたは偽装ポート番号を有するため、かかる形式はまた、先で言及されるルータＥＣＭＰハッシング問題といった問題を解決することができる。しかしながら、ＮＩＣは、ここでレベル４ペイロード内に含有される情報を適切に解釈することができないため、従来のＮＩＣまたは同様のデバイスは、カプセル化されたフレームに従って、６４Ｋまたは同様のパケットをどのように適切に分割するかが分からない。また、述べられるように、レベル４ペイロードは、ＩＰ_ＶおよびＴＣＰ_Ｏ情報を含むことによって、変更されている。

代わりに、種々の実施形態は、カプセル化されたパケットを処理するように、わずかに修正されたプロトコル形式を活用することができる。従来のプロトコルは、ＴＣＰヘッダの終端に余分な空間を提供し、これは、典型的に、「ＴＣＰオプション」または「ＴＣＰアドオン」と称されるものを可能にする。これらのＴＣＰオプションは、追加の特性を含むように、ＴＣＰプロトコルが拡張されることを可能にする。一部の実施形態において、ＴＣＰパケットは、効果的に、追加の情報をＴＣＰオプションとして宣言しながら、約２４バイト拡張することができる。理解されるべきであるように、パケットは、異なる実施形態および／または実装において、異なる量、拡張することができ、２４バイトの拡張は、一例に過ぎない。このため、偽装ＴＣＰヘッダは、元のＴＣＰ情報に加え、制御ヘッダ情報を含むことができる。仮想ＩＰアドレスに関する情報もまた、このＴＣＰオプション空間に含むことができる。このため、ペイロードまたはデータ部分が変更しないように、ペイロードのカプセル化および修正の間、実ヘッダを追加する代わりに、ＩＰ_ＶおよびＴＣＰ_Ｏ情報を、偽装ＴＣＰのＴＣＰオプションセクションに含むことができる。

仮想化された環境に関して、パケット情報を管理するための例示的なプロセスにおいて、仮想アドレス情報を含むパケットが受信される。ホストデバイス、またはユーザが実質的に完全にアクセスを有する他の機械へ受信される場合、パケットは、ユーザが、ルーティングおよび他のかかる処理を修正することができないように、ユーザが制御可能なハードウェアの上流にある１つ以上のデバイスまたは構成要素へ方向付けられる。ゲストからＤＯＭ−０へといった、構成要素間で伝送されるパケットは、一部の実施形態において、６４ＫＢまでのサイズとなり得、このため、セグメント化を必要とし得る。パケットに対するマッピング情報は、例えば、仮想アドレス情報に対応する物理アドレス情報を判断するように、マッピングサービスにコンタクトを取ることによって、判断することができる。アドレス情報は、受信されたメッセージ、例えば、ヘッダ（ＩＰ_Ｒセクション等）に追加することができ、ここで、アドレス情報は、パケットが方向付けられるべき物理アドレスに対応する。仮想アドレス情報は、パケットを依然としてルーティングする、セグメント化する、および別様に商品ハードウェアによって処理することができるように、ペイロードを修正することなく、パケットに対して、ＴＣＰヘッダといったプロトコルヘッダに追加することができる。パケットは、ＴＣＰセグメント化オフロード機能性を使用してパケットをセグメント化し、かつ結果としてのパケットをワイヤへ、および最終送信先へ伝送することができる、オフロードデバイスへ伝送される。明らかであるはずであるように、同様の機能性は、物理アドレス空間から受信されるパケットを処理するために使用することができ、マッピング情報は、パケットに対して判断され、仮想アドレス情報は、パケットに追加される。仮想マッピング情報が、ポートを指定しない場合、例えば、負荷均衡化または同様の機能性を可能にするように、パケットが仮想送信先への途中で処理されることを可能にする、「偽装」ポートを使用することができる。

仮想化された環境に関して、パケット情報を管理するための同様のプロセスの実施例において、イーサネットフレームは、物理的ネットワークインターフェース（例えば、ＮＩＣ）へ受信され、ここで、フレームは、物理アドレス情報を含む。ＩＰ_ＲおよびＴＣＰ_Ｆといった情報を有するセグメントは、一部の実施形態において、１つ以上のより大きなセグメントを生成するように、合体させることができ、これは、性能を改善することができる。パケット形式は、全てのＴＣＰ形式規則に従っており、かつＴＣＰペイロードは、顧客パケットのペイロードと全く同じであるため、これは、受信サイド合体（Ｒｅｃｅｉｖｅ Ｓｉｄｅ Ｃｏａｌｅｓｃｉｎｇ）をサポートする商品ＮＩＣによって行うこともできる。オフロードデバイス（または他のかかるデバイス）は、ユーザが、ルーティングおよび他のかかる処理を修正することができないように、ユーザが制御可能なハードウェアの上流にある。仮想アドレス情報は、例えば、ヘッダおよびフッタフレーム化情報を除去した後に、ペイロードに対して、ＴＣＰヘッダといったプロトコルヘッダから抽出することができる。仮想アドレス情報は、受信されたイーサネットフレームから抽出される、データパケットに対するヘッダを組み立てるために使用することができる。次いで、パケットは、例えば、仮想アドレス空間内の送信先へパケットを伝送することによって、処理することができる。明らかであるはずであるように、同様の機能性は、仮想アドレス空間から受信されるイーサネットフレームを処理するために使用することができ、仮想アドレス情報は、パケットに対するヘッダから抽出される。

しかしながら、受信される各パケットが１．５Ｋであり、２４バイトの情報がこれらのパケットの各々に追加される場合、ここで、パケットは、各々が、１．５Ｋの伝送制限を超え、各々が、２つのパケットに分割されることを必要とし、これは、望ましくない量のオーバーヘッドおよび追加のトラフィックにつながる可能性があるため、単純にＴＣＰヘッダを拡張することは、一部の実施形態において、望ましくない場合がある。このため、少なくとも一部の実施形態において、オーバーヘッドを著しく増加させないながらも、この追加の情報を利用することが、望ましい可能性がある。

種々の実施形態は、ＩＰ_ＶおよびＴＣＰ_Ｏ情報といった情報が、セグメント化時には、各パケットに対して必要とされないが、セグメント結合化時に判断され得るという事実を活用する。このため、一手法は、種々の実施形態において、ＩＰ_ＶおよびＴＣＰ_Ｏ情報等に関する追加の情報（一実施例において、約２４バイト）を採り、一実施形態においては、約１〜５つの情報のインスタンスである、コード化された情報（一実施例において、約１２０バイト）を作成することであるが、例えば、ハッシング技術に依存し得るように、他の長さのコード化された情報も使用することができる。コード化された情報は、ハッシングまたは同様の機構を使用して再構築することができるため、元の情報は、セグメント化されたパケットの１つ以上のインスタンスから取得され得る、ハッシュ化されたメタデータの少なくとも２４バイトから再構築することができる。このため、例えば、各パケットセグメントに２４バイトを追加する代わりに、追加の１２０バイト程度を、適切な数のピースに分割することができ、例えば、データがセグメント化される境界において、ペイロードに沿って、戦略的に位置付けることができる。例えば、オフロードデバイスまたは同様のデバイスは、データが、ある場所（追加の５０バイトを含む）において、サイズに基づいて、自動的にセグメント化されるということを知っている。これらのセグメント化場所が分かっているため、オフロードデバイスは、１．５Ｋパケットの少なくとも５つ（または適切なサイズの任意の他の適切な数）が、その中に記憶されるＩＰ_ＶおよびＴＣＰ_Ｏに対する情報を有するが、各パケットは、全ての１０バイトの追加の情報は含まないように、追加の情報のインスタンスを、これらのセグメントラインで（またはそうでなければ異なるセグメント内に）挿入することができる。

パケットが受信される時、セグメント結合化プロセスを、従来のシステムと同様に行うことができる。１．５Ｋのセグメントが、６４Ｋのペイロードに組み立てられる時、またはセグメント結合化プロセス中、情報の一部分は、ＩＰ_ＶおよびＴＣＰ_Ｏ情報等を再構築するために使用することができる。例えば、ハッシングプロセスを使用する、および種々のパケット間で情報を分散することの利点は、１．５Ｋのパケットの一部が損失した場合でさえも、情報の一部分を有する少なくとも２つのセグメントが受信される限り、ＩＰ_ＶおよびＴＣＰ_Ｏ情報を再構築することができるということである。ペイロード全体は、再構築することができない可能性があるが、少なくともヘッダ情報は再構築することができる。さらに、受信デバイスは、ヘッダ情報を再構築することができるため、単純に、受信されなかったそれらの１．５Ｋのセグメント（例えば、イーサネットフレーム）を要求することができ、したがって、ペイロード全体の再送を要求する必要はない。かかる手法は、性能における大きい変動をもたらし得る、大きいパケットの再送の必要性がしばしば存在しないため、はるかに低いジッタ分散を有することができる。例えば、ビデオトラフィックの場合、データ損失が著しくない限り、損失したトラフィックは、無視することができ、このため、少なくとも一部の実施形態において、要求される必要がない。これは、部分的なセグメントを無事に受信することができるという利点である。

仮想化された環境において、パケットを処理するための例示的なプロセスにおいて、パケットは、顧客アドレス空間から受信され、これは、仮想アドレス情報を含む。述べられるように、ユーザから受信される最初のパケットは、ＩＰ_ＶおよびＴＣＰ_Ｏ情報を伴う６４Ｋのパケットであり得る。パケットは、顧客がパーティションしたデバイスのユーザには少なくとも部分的にアクセス不可能である、制御ホストまたは別のかかる安全な構成要素へ受信されるか、または方向付けることができる。仮想アドレス情報は、例えば、上で述べられるように、マッピングサービスにコンタクトを取ることによって、安全な構成要素を使用して、実アドレスに翻訳することができる。所望される場合、ＴＣＰヘッダ（または他のプロトコルヘッダ）を更新することができるが、ＩＰ_ＶおよびＴＣＰ_Ｏ情報といった追加の情報を、代わりに、データに挿入することができる。ＩＰ_ＶおよびＴＣＰ_Ｏ情報をデータに追加する時、この「仮想化」情報をハッシュすることができるか、または別様に、複数の部分に分割することができる。既に判断されていない場合、安全なデバイスは、伝送経路に対するセグメント化制限を発見することができ、ユーザペイロードのセグメントに対する境界を判断することができる。仮想化情報の一部分は、ペイロードの中央パケット内のセグメント化境界に隣接して配置することができるか、またはそれに対して位置付けることができる。次いで、「新しい」パケットまたはフレームは、パケットを、１．５Ｋのパケットといった判断されたサイズの一組のパケットに自動的にセグメント化することができる、例えば、オフロードデバイスまたは他のかかる安全なデバイスに渡すことができ、セグメントの数は、全体的なパケットのサイズに少なくとも部分的に依存する。ＩＰおよびＴＣＰヘッダは、オフロードデバイスまたは他のかかるデバイスのセグメント化オフロードプロセスを使用して、サイズの全体的な変更を補うように、潜在的に一部の小さい変更を伴って、各パケットに関して複製することができる。次いで、パケットを、送信先に伝送することができる。

同様のプロセスを、仮想化された環境に対するパケットを処理するために使用することができ、一組のイーサネットフレームが受信され、イーサネットフレームのうちの少なくとも一部は、ハッシュされているか、または別様に複数の部分に分割されている「仮想化」情報を含む。仮想化情報は、関連付けられるペイロードにおいて、仮想化情報の一部分を含む、各フレームの下部のセグメントから抽出することができる。仮想化情報（例えば、ヘッダデータ）は、仮想化情報を含む十分な数のフレームが受信される限り、再組み立てされ、受信されたパケットは、可能な程度にセグメント結合することができる。全てのフレームが受信されるわけではないが、ヘッダデータを再組み立てすることができた場合、欠落したセグメントのみに対する要求を送信することができる。

パケットの少なくとも大部分が、最終的に、送信先、または送信先への経路に沿ったデバイスで受信される時、デバイスは、完全な６４Ｋまたは他のパケットでない場合、これらのパケットを少なくとも１つのより大きなセグメントへのセグメント結合または再組み立てを試行することができる。ペイロードにおいて追加のヘッダ情報を有する、２つのパケット（または必要とされるパケットの数が特定のハッシング技術によって判断される場合、セグメント化の間に、元々生成されたものよりも少ない数のパケット）が受信される限り、少なくとも一部の実施形態において、これらのパケットは、ヘッダデータを再構築するため、およびパケットをセグメント結合するために使用することができ、実アドレスおよびプロトコル情報を、仮想またはクライアントネットワークに関する情報と置換し、それにより、より大きい組み立てられたセグメントを、クライアントまたは他の送信先に渡すことができる。一部の実施形態において、セグメント結合化は、オフロードデバイスまたは同様のデバイス上で行うことができる一方、他の実施形態において、セグメント結合化は、受信デバイス上のゲストオペレーティングシステム等を使用して行うことができる。さらに、上のプロセスの種々のステップは、任意の適切な順序で、または並行して、実施することができ、かつより少ない、追加の、または代替的なステップが、種々の実施形態の範囲内において可能である。

仮想化を使用して、顧客ネットワークの一部であるとして、ユーザに対して表示され、機能するが、別個またはリモートのクラウド、ネットワーク等において、実際のサーバまたは他の物理的リソースにマッピングされる、いくつかの仮想機械インスタンスを生成することができる。述べられるように、標準化されたアドレス空間の使用は、物理的サブストレートアドレスと、顧客アドレス空間のために使用される仮想オーバーレイアドレスとの間のマッピングの構築および維持を必要とし得る。一部の既存の手法において、ホストデバイス上で実行する中央処理装置は、顧客から受信される要求を、適切なリソースに方向付けることができるように、仮想および物理アドレスのマッピングを制御することができる。これは、例えば、データパケットカプセル化および脱カプセル化の形態を採ることができ、物理アドレスおよび／またはヘッダ情報は、パケットを、顧客ネットワーク上の送信元によって、仮想アドレスへアドレスすることができるが、適切な物理アドレスへ適切にルーティングすることができるように、仮想アドレスおよび／またはヘッダ情報とともに、種々の時間に、「共存」することができる。

フレームワークは、従来のまたは他のネットワーキング構成要素が、多様な異なる標準的な、および独自のプロトコルといった複数のプロトコルをサポートすることを可能にすることができる、商品ＮＩＣデバイスといった、これらの構成要素によって実装することができる。次いで、これらの商品デバイスは、顧客固有のパケット形式から独立して、強化された性能、およびこれらのデバイスの従来のプロトコルに対して使用される他の利点を提供することができる。例えば、ＮＩＣベンダは、ＮＩＣが、いかなるカスタム化または特別なハードウェアに対する必要性も伴わずに、任意の準拠したプロトコルを用いて顧客によって使用されることを可能にする、フレームワークを実装することができる。

一実施例において、ネットワーク環境におけるオフロードデバイスは、ＴＣＰセグメントを処理することができる。顧客ネットワークは、オフロードデバイスは、例えば、約８Ｋまたは９Ｋのサイズ（ネットワーク構成および他のかかる問題に依存して）のネットワークパケットを伝送することができるのみである場合があるため、典型的に、オフロードデバイスからネットワークへ渡すことができないサイズ（例えば、６４Ｋ）のパケットを利用する場合がある。上で述べられるように、より大きなパケットが、オフロードデバイスにおいて、適切なサイズ（例えば、１．５Ｋまたは９Ｋ等）の複数のイーサネットフレームにセグメント化されることを可能にする技術が存在する。例えば、ＴＣＰセグメント化オフロード（ＴＣＰ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ：ＴＳＯ）および受信サイド合体（Ｒｅｃｅｉｖｅ Ｓｉｄｅ Ｃｏａｌｅｓｃｉｎｇ：ＲＳＣ）は、ホストが、より大きいＴＣＰセグメント（例えば、６４Ｋのサイズ）に対処することを可能にすることによって、ネットワークスループット性能を増加させるように、それぞれ、進出および進入エンドポイント上で使用することができる。ＴＳＯは、ネットワーク上での伝送のために、ＴＣＰパケットを適切なサイズのセグメントにセグメント化するための技術であり、ＲＳＣは、これらのセグメントが、ネットワークの他方のサイドで再組み立てされることを可能にする。しかしながら、一般的に、ＴＳＯおよびＲＳＣといった技術は、図４（ｂ）に例解される追加のヘッダ情報といった独自のプロトコル情報を伴って、カプセル化されるパケットに対してサポートされていない。例えば、独自の形式を使用してカプセル化されるパケットは、典型的に、ＴＣＰパケットよりも大きく、オフロードデバイスが、これらのカプセル化されたパケットを認識しないように、予想されるＴＣＰヘッダ情報を有しない。

しかしながら、適切なフレームワークを実装することによって、オフロードデバイスまたは他の適切なネットワーク構成要素は、カプセル化されたパケットを、構成要素がＴＣＰパケットとして理解することができる何かにマッピングするための能力および仕様を有することができる。例えば、一度、オフロードデバイスが、パケットをＴＣＰパケットとして認識すると、オフロードデバイスは、パケットをセグメント化し、適切なヘッダを追加する、および／またはオフロードデバイスが、典型的に、従来のＴＣＰパケットに対して行うであろう他のことのいずれかを行うことができる。多様な異なるプロトコルのうちのいずれかでカプセル化されるパケットに関してさえも、ＴＳＯおよびＲＳＣは、有意な改善（例えば、最大８０％の性能増強）、ならびに他の十分に確立された利点を提供することができる。さらに、フレームワークを実装することによって、オフロードデバイスは、異なるプロトコルとともに使用することができるだけでなく、顧客が、顧客の既存のハードウェアを購入、アップグレード、または修正することを必要とせずに、プロトコルをアップグレードまたは変更することも可能にすることができる。

不明瞭なフィールドは、ＧＲＥまたは他のかかるプロトコルといった、顧客ネットワークの特定の形式またはプロトコルによって利用されるいかなる情報も含むように、カプセル化されたパケットとともに使用することができる。少なくとも一部の実施形態における、不明瞭なフィールドは、ＴＣＰもしくはＵＤＰベースのヘッダ、または他のかかるプロトコルヘッダである。一実施例において、不明瞭なヘッダは、不明瞭なフィールドにおいて、指定されたオフセットに、セグメントまたはパケットの特定の形式を示すまたは識別する、第１の組の情報を有する。例えば、情報は、特定の形式に対応する値を含む、２バイトフィールドであり得る。ネットワークハードウェアは、第１の組の情報の値から、パケットの適切な形式を判断するために、第１のオフセット値および対応する形式のマッピングからの値を含有するか、それへのアクセスを有することができる。

本実施例において、不明瞭なフィールドはまた、不明瞭なフィールドにおいて、指定された第２のオフセットに、情報の第２のフィールドを含む。この第２のフィールドは、２バイトといった適切な長さであり得、セグメント結合化に有用であり得るような、フロー識別子、またはトラフィックの特定のフローに対する識別子を指定する値を含むことができる。一部の実施形態において、このフィールドは、特定の形式パケット上でＴＳＯまたはＲＳＣ動作を実施する時、一般的な５タプルとともに、一意的なＴＣＰフロー（またはＵＤＰフローといった他のフロー）を識別することができる。

これらの実施例は、例えば、ヘッダが、パケットが属する仮想ネットワーク、パケットが発信される仮想機械、および／またはパケットが向かっている仮想機械といった情報を有する、特定のプロトコルに対する環境に対応することができる。この情報は、共通のＴＣＰストリーム内のパケット間で変化しない。例えば、仮想化されたネットワーク環境においては、２つの異なる仮想ネットワークに属する、同じ物理的ホスト上に、２つの異なる仮想機械が存在する可能性があるため、スロットＩＤ、または仮想機械識別子は、接続情報のために使用することができる。それらの仮想機械は、全く同じＩＰアドレスを有する可能性があり、かつ潜在的に、偶然同じポートおよびＩＰアドレスを有する誰かと通信する可能性がある。ＴＣＰの観点から、５タプルは、全く同じであり得る。送信元ＩＰおよび送信先ＩＰ、送信元ポートおよび標的ポート等といった他の情報もまた、全く同じであり得る。このため、ＴＣＰの観点から、接続は、同じ接続として考えられるが、実際には、２つの異なるプライベートネットワークである可能性がある。スロットＩＤの使用は、これらの状況を一意的に分離することができる。他のプロトコルに関して、明らかであるはずであるように、仮想機械識別子以外の値を使用することができる。

一実施例において、カプセル化されたパケットは、オフロードデバイスへ受信される。オフロードデバイスは、フレームワークの仕様を使用して、パケットがカプセル化され、従来のＴＣＰまたはＵＤＰパケットとは異なって処理される必要があるということを識別するように、パケットを分析することができる。一実施例において、カプセル化されたパケットは、内部および外部ＩＰヘッダを含む。カプセル化されたパケットはまた、不明瞭なフィールド（ペイロードの一部として表示され得る）を有し、これは、プロトコル固有の情報に対して使用することができる。不明瞭なフィールドの長さ、およびその中に含有される情報は、実施形態間で変化し得る。カプセル化されているとしてパケットを識別するために、外部ＩＰヘッダは、事前構成されたプロトコル情報を含有することができる。さらに、パケットは、不明瞭なフィールド内に少なくとも１つの２バイトフィールドを含有することができる（しかしながら、他のサイズおよび場所も、他の実施形態の範囲内において使用することができる）。２バイトフィールドは、不明瞭なフィールドの開始から事前構成された距離であり得、２バイトフィールドの値もまた、事前構成され得る。外部ＩＰヘッダ内のプロトコル情報、および不明瞭なフィールドの２バイトフィールド内の形式情報の組み合わせは、オフロードデバイスまたは別のネットワーク構成要素が、パケットがカプセル化されること、ならびにカプセル化の形式を認識することを可能にすることができる。オフロードデバイスは、本来、不明瞭なヘッダ内の他の情報を見ないため、不明瞭なヘッダは、オフロードデバイスによるパケットの処理に影響を及ぼすことなく、任意の特定のプロトコルに固有の情報を含むことができる。不明瞭なヘッダ内の２バイトは、パケットの特定の形式を識別することができ、これは、パケットを処理するための規則または方針を判断することを支援することができる。外部ＩＰヘッダおよび不明瞭なフィールド内のこの情報に基づいて、オフロードデバイスは、従来の手法を使用してパケットを処理することができるかどうか、またはパケットがカプセル化されたパケットであるかどうか、およびフレームワークによって指定される特別な規則に従って処理されるべきかどうかを判断するように、各受信されたパケットを分析することができる。

例えば、ＴＳＯプロセスの間、進出（例えば、発信）ＴＣＰセグメントのセグメント化は、内部ＩＰヘッダにおいて開始する、ＴＣＰセグメントデータ上で、標準的なアルゴリズムを使用して実施することができる。大きいカプセル化されたパケットは、セグメントがネットワーク上で伝送されることを可能にするサイズのいくつかのパケットに、セグメント化される。フレームワークがステートレストンネリングとも協働するために、不明瞭なフィールドは、得られたセグメント化されたＴＣＰ／ＩＰパケットの各々に、逐語的にコピーされ、内部および外部ＩＰヘッダ間に配置される。外部ＩＰヘッダは、各得られたパケットにコピーされ、「長さ」情報への変更といった適切な調節は、内部ＩＰヘッダに適用される同じロジックを使用して行うことができる。さらに、ＩＰヘッダに対するチェックサムとともに、ＩＰヘッダの一部である、ＩＰ ＩＤを生成することができる。

同様に、ＲＳＣプロセスの間、特別なプロトコル形式情報を有するパケットまたはセグメントのＴＣＰフローは、ＴＣＰポート、内部ＩＰアドレス、内部ＩＰプロトコルフィールド、および内部Ｌ４ポート（例えば、ＴＣＰポートまたはＵＤＰポート）の一般的な５タプル、ならびに不明瞭なフィールドの開始から事前構成されたオフセットにおける追加の２バイトによって、定義される。特別な形式パケットのＴＣＰフローは、一般的なパケットのフローと重複しないということが理解されるべきである。さらに、「パケット」といった用語は、全体を通して、解説の簡略化の目的で使用されるが、他の場所またはインスタンスにおいて、プロセスは、より一般的にセグメントまたはフレームと称されるオブジェクトを含み、単一のオブジェクトに対する共通の名称は、本明細書において述べられるプロセスにおける種々の点において、これらと他の用語との間で変化する場合があるということが理解されるべきである。

ＲＳＣは、内部ＩＰヘッダで開始するＴＣＰパケットデータ上で、従来のアルゴリズムを使用して実施される。関連ＴＣＰパケットを合体させる時、第１のＴＣＰパケットからの不明瞭なフィールドは、内部ＩＰヘッダと外部ＩＰヘッダとの間の得られたＴＣＰセグメントへコピーすることができる。得られたＴＣＰセグメントの外部ＩＰヘッダは、内部ＩＰヘッダが合体されるのと同じように合体することができる。ＲＳＣに対して不適格であることを進入パケットに強制する、ＩＰフラグ上の制限（例えば、「Ｄｏｎ’ｔ ｆｒａｇｍｅｎｔ」または「Ｍｏｒｅ ｂｉｔ」）が存在する場合、制限は、内部および外部ＩＰヘッダの両方において、ＩＰフラグに適用され得る。

ＲＳＣは、パケットが受信されている各接続に対するハッシュバケット（または他のキューもしくは一時的な記憶場所）を維持することができる。ＴＣＰパケットが受信される時、次いで、受信デバイスは、ＩＰおよびＴＣＰ情報といった情報、ならびに外部ＴＣＰヘッダ内のシーケンス番号ビットを使用して、パケットが属する接続を判断することができ、かつ適切なハッシュバケットに対するパケットをキューに入れることができる。既にパケットが存在するバケットに関して、ネットワーク構成要素は、完全なパケットが合体されるまで、セグメント化されたパケットのマージを試行することができる。サイズがある閾値に到達する、またはパケットが、特定の長さもしくは範囲の時間、キューに入れられる時、合体されたパケットをオペレーティングシステム上で送信するといった、従来の基準を適用することができる。

しかしながら、少なくとも一部の実施形態において、接続の概念は、標準的なＴＣＰパケット処理のための接続とは異なる。上で言及される従来の５タプルの代わりに、接続は、不明瞭なフィールドの２バイトにおいて識別される新しい接続情報とともに、５タプルの標準的なＴＣＰ接続情報を含む、６タプルに基づいて判断される。一度、ネットワーク構成要素が、パケットが特別な規則を使用して処理されるべきであるということを把握すると、構成要素は、接続情報を把握するために５タプルの代わりに６タプルを使用し、次いで、従来のパケットと本質的に同じであるＲＳＣプロセスを実行して、パケットの合体、シーケンス番号のチェック等を行う。

加えて、ＲＳＣはまた、多くの場合、一部の実施形態における最初に受信されたパケット等の１つを除いて、合体されるパケットの全ての不明瞭なビットを捨てる必要がある。一部の実施形態において、ＲＳＣは、不明瞭なフィールドが適合しない時には実施することができないため、他方のパケットからの不明瞭なフィールドが、少なくともそれらのパケットを別様に処理することができるまで、破棄されない。不明瞭なビットの１つのコピーが受信および記憶された（例えば、少なくとも一時的に記憶されるか、またはキャッシュされた）後、不明瞭なフィールドの記憶されたコピーと適合する、合体されるべき全ての他のパケットの不明瞭なビットは、オフロードデバイスによって破棄することができる。さらに、パケットの全長は、マージの間に変化しているため、オフロードデバイスは、外部ＩＰおよび内部ＩＰヘッダの両方に対する、チェックサム、ＩＰヘッダフラグ、または他のかかる情報への適切な調節を行わなければならない。不明瞭なフィールド、および他の個所において、バイト数および他の態様もまた、変化する可能性がある。識別のために使用される情報の２バイト（またはｎバイト）とは別に、不明瞭なビットの残りは、特定のＴＣＰストリーム内の全てのパケットに対するものと全く同じであることが予想される。１つのプロトコルの実施例において、不明瞭な情報は、特定のネットワーク識別子と対応する可能性がある。仮想機械識別子またはスロットＩＤといった他の情報も存在し得、これは、ＴＣＰストリーム内の各パケットに対するものと同じである。特に、ｎバイトは、特定の仮想機械と対応するとしてパケットを識別することができる。

多くの実施形態において、フレームワークは、特定の事前構成された値に依存する。例えば、上で述べられるように、フレームワークは、不明瞭なフィールドの事前構成された長さ、ならびに受信されたパケットに対する特定のまたは特別な形式を識別するＩＰプロトコル値に依存し得る。一部の実施形態における、不明瞭なフィールドの長さは、パケットの特別な形式に対するヘッダの長さと対応する。ＩＰプロトコル値は、特定のプロトコルに対する任意の適切な識別子である可能性がある。フレームワークは、形式を識別する、不明瞭なフィールドにおけるｎバイトフィールドのオフセットが、事前構成されるということを予想することができる。一部の実施形態において、これは、特定のポート値と対応し得る。

不明瞭なフィールドの特定の事前構成された値は、あるプロトコルに対して変化し得る。例えば、ＧＲＥサポートに対する不明瞭なフィールドの長さは、一実施形態において、１６バイトであり得、特定のパケットまたはセグメント形式を識別するＩＰプロトコル値は、４７といった値に設定される。一意的なフローを識別するオフセット値は、「キー」フィールドの一部を指す、例えば１０といった値、または、他のかかる値に設定され得る。

例示的なプロトコルの場合、不明瞭なフィールドの長さは、２０といった値でもって、プロトコル固有のヘッダの長さと適合する場合がある。特定のプロトコルのパケットまたはセグメントを識別するＩＰプロトコル値は、例えば、１７といった値でもって、ＵＤＰに対するＩＡＮＡプロトコル番号に設定され得る。特定の形式のパケットまたはセグメントを識別する、不明瞭なフィールドにおけるオフセット値は、値２を有する、ＵＤＰ送信先ポートといった、使用される特定のＵＤＰポートに少なくとも部分的に依存し得る。ＴＳＯまたはＲＳＣ実施する時、一意的なフローを識別する、フィールドの値は、一意的なＴＣＰフローを識別するように、一般的な接続５タプルとともに、送信元スロットおよび標的スロットＩＤを指定することができる。同様の手法は、種々の実施形態の範囲内で、他のプロトコルに対する値を判断するために使用することができるということが理解されるべきである。

上で言及されるように、クラウドコンピューティングプラットフォームといった環境の一目標は、各顧客に、ネットワークインフラの一部分が、その顧客専用であるという錯覚を提供することであり得る。この錯覚を提供するために、プラットフォームは、低ジッタ、低待ち時間、および高スループットネットワーク性能を含み得るといった、あるレベルの性能を提供することが必要である。ジッタは、常に、概して低くあるべきであるが、所与の実装に対して、低待ち時間および高スループットの定義は、物理的ネットワーク機器および製品設計といった要因に依存し、インスタンス間で変動する。錯覚はまた、他の顧客の選好に起因するアドレス制限を伴わずに、顧客が、カスタム化されたレベル２（Ｌ２）またはレベル３（Ｌ３）ネットワークトポロジーを定義することを可能にすることによって、部分的に提供することができる。Ｓｅａｔｔｌｅ， ＷａｓｈｉｎｇｔｏｎのＡｍａｚｏｎ．ｃｏｍ， Ｉｎｃ．によって提供される仮想私的クラウド（ＶＰＣ）環境といったある環境において、カスタム化可能なＬ２またはＬ３のルーティング可能なネットワークのオプションは、ＩＰアドレストンネリングの洗練されたソフトウェア実装を介して、大部分は達成される。しかしながら、これらのソフトウェア実装のうちの少なくとも一部において、仮想化された環境において、低ジッタ、低待ち時間、および高スループットネットワーキング性能を維持するのは困難である可能性がある。現在のハードウェア傾向に、より多くのコア、ＲＡＭ、およびホスト単位の仮想機械が継続し、ネットワーキングサブシステムにますます負荷を課すにつれて、問題 は、さらに悪化し得る。エンドツーエンドソフトウェアスタックを最適化することによって、利得を得ることができるが、少なくとも一部の環境において、ネットワークリソースの仮想化におけるハードウェア支援を提供することが有益であり得る。

上で概説される目標のうちの少なくとも一部を満たすために、種々のオフロードデバイスといったハードウェアは、種々の特性を含む必要があり得る。本明細書において使用される際、「ハードウェアベースの」処理は、概して、ハードウェアデバイスがその処理のうちの少なくとも一部を実施する、任意の処理を指し、処理構成要素は、それ自体を、物理的デバイス（例えば、ＮＩＣ）として提示するが、実際には、ハードウェアおよび／またはソフトウェアとして実装されてもよい。一部の実施形態において、ハードウェアベースの処理は、システムの構成要素には、少なくとも１つのハードウェア構成要素であるように見える、汎用オフロードデバイスまたは埋め込みシステムを通じて提供されてもよい。例として、それ自体をＳＲ−ＩＯＶデバイスとして提示する汎用オフロードデバイスを使用することができる。これらの特性の考察は、提唱される進出および進入経路の高レベルの概要、続いて、種々の実施形態に従って実装することができる個々の段階に関する詳細を示すことによって提供される。例えば、図６は、かかる仮想パケットの例示的な形式６００を例解する。図７は、少なくとも一実施形態に従って、仮想化されたデータセンタにおける顧客のかかる顧客パケットとともに使用することができる、例示的なオフロードハードウェア進出プロセス７００の高レベルの概要を例解する。進出プロセスの一部として、顧客仮想機械に割り当てられるＳＲ−ＩＯＶ仮想機能（ＶＦ）は、顧客の仮想ネットワークに向かう進出パケットを受信する７０２。この初期段階において、パケットヘッダ６００の内部構成要素６０８、６１０、６１２が存在する一方で、外部構成要素６０２、６０４、６０６、および６１４は、存在しない。１つ以上の一般チェックは、進出パケットに適用することができる７０４。これらのチェックは、例えば、Ｌ２および／またはＬ３送信元アンチスプーフィング、ならびに全ての非ＩＰおよびブロードキャストパケット（即ち、サービスＤＨＣＰ、ＡＲＰ等への）に対するトラッピングを含むことができる。オフロードデバイスは、一般的な場合は、単一の標的を指定するＩＰＶ４「／３２」サブネットである、サブネットマスクを有するＬ２送信先およびＬ３送信先に基づき得るように、事前投入された規則表においてルックアップを実施することができる７０６。転送の規則タイプでヒットするある規則を想定すると、規則はまた、オフロードデバイスが発信パケットに付加するトンネルヘッダに対して、システムメモリ内のポインタを指定することができる。この点において、パケットはまた、初期外部構成要素６０２、６０４、６０６を含むことができる。オフロードデバイスは、以下でさらに詳細に述べられる、１つ以上のメトリック更新を実施することができる７０８。

少なくとも部分的に規則適合（または規則適合の欠如）に基づいて、オフロードデバイスは、取るべき適切な行為を判断することができる７１０。行為は、例えば、信頼されるルートドメインへのトラップ７１２、パケットのドロップ７１４、またはカプセル化および／もしくはマングリングを伴うパケットの転送７１６を含むことができる。オフロードデバイスが、信頼されるドメインへのパケットのトラップ７１２を決定する場合、ドライバコールバックは、信頼されるドメインが、パケットのさらなるソフトウェアベースの処理を実施することを可能にすることができる。オフロードデバイスが、パケットのドロップ７１４を決定する場合、さらなる処理は行われない（少なくとも一部の実施形態において）。オフロードデバイスが、代わりに、パケットの転送７１６を決定する場合、パケットを物理的ネットワーク上へ解放することができる前に、さらなる処理が必要とされ得る。本実施例において、オフロードデバイスは、例えば、さらに詳細に以下で説明されるように、パケット上でスロットリングおよびＱｏＳ行為７１８を行う。オフロードデバイスはまた、オフロードエンジンに送給される最終パケットを構築および／またはマングリング７２０することができる。外部パケットヘッダ構成要素６０２、６０４、６０６は、パケットに付加することができる。これらは、先の規則適合に基づくパケットバイトとともに、スキャッターおよび／またはギャザーＤＭＡを介して、取り出されている可能性がある。次いで、オフロードデバイスは、該当する場合、ＴＳＯを含む、オフロード（複数を含む）を実施７２０することができる。パケットヘッダフィールドは、必要な場合、更新することができ、以下でより詳細に述べられるように、内部および外部ＩＰ長さ、内部および外部ＴＣＰチェックサム（即ち、ＩＰプロトコルがＴＣＰである場合）、内部Ｌ２ ＭＡＣ送信元および送信先アドレス、ならびに内部Ｌ３ ＩＰ ＴＴＬを含むが、必ずしもこれらに限定されない。

図８は、少なくとも一実施形態に従って使用することができる、仮想化されたデータセンタにおける顧客パケットに対する、例示的なオフロードデバイスハードウェアベースの進入プロセス８００の同様の高レベルの概要を例解する。この例示的なプロセス８００において、パケットは、オフロードデバイス物理的機能上で受信８０２される。オフロードデバイスは、以下でさらに詳細に述べられるように、その後の規則処理に対して構築される規則ルックアップキーを構築８０４することができる。次いで、オフロードデバイスは、導出されたルックアップキーに基づき、事前投入された規則表において、ルックアップを実施８０６することができる。オフロードデバイスは、必要な場合、種々のメトリック更新８０８を実施し、少なくとも部分的に規則適合（または規則適合の欠如）に基づいて、取るべき適切な行為を判断８１０することができる。最初の行為において、オフロードデバイスは、信頼されるルートドメインへのパケットのトラップ８１２を決定することができる。この場合、ドライバコールバックは、信頼されるドメインが、パケットのさらなるソフトウェアベースの処理を実施することを可能にすることができる。別の可能な行為において、オフロードデバイスは、パケットのドロップ８１４を決定することができるため、そのパケットのさらなる処理は行われない。別の可能な行為において、オフロードデバイスは、例えば、カプセル化および／またはマングリングを伴って、内部ＶＦへのパケットの転送８１６を決定することができる。ＶＦ（ＶＭ）ＩＤは、転送規則において指定することができる。オフロードデバイスは、パケットから外部カプセル化ヘッダ６０２、６０４、６０６をストリップ８１８することができる。内部マングリングは、全てのかかるマングリングが先に進出において行われたため、本実施例において、必要とされない。１つ以上のパケットまたはパケットデータ部分の再順序付け、分割、またはそうでなければ修正といった、種々の他のパケット修正も実施することができる。この段階で、パケットは、ゲストＶＦを介して、ゲストＶＭに配信８２０することができる。

述べられるように、かかる手法は、パケットのハードウェアベースの、規則ベースのパケットマングリングおよびカプセル化を提供することができる。かかる手法は、複数の（および恐らく重複する）顧客仮想ネットワークが、統一されたＬ３ルーティング可能な物理的サブストレート上にオーバーレイされることを可能にする。共通の規則表を、進出および進入パケット経路の両方に対して使用することができ、少なくとも一部の実施形態において、規則表は、ソフトウェア機構を介して、信頼されるルートドメインによって投入される。

以下は、種々の実施形態に従って、使用することができる、例示的な規則表実装のサイズおよび性能に関するガイドラインを提供する。例示的な規則表は、ホスト上で実行される仮想機械あたり約１，０００の規則エントリ（進入と進出との間で共有される）を有することができる。少なくとも一部の実施形態において、可能な最も大きい規則表サイズを利用することが望ましい可能性があるが、少なくとも一部の場合において、増加した表サイズの素価は、オフロードデバイスにおける増加したＲＡＭ要件となるため、デバイスＲＡＭによって課される規則表サイズにおける制限がある。ホスト上のＶＭの数が増加するにつれて、規則の数も適宜変化し得る。例えば、少なくとも一実施形態において、１２８のＶＭおよび１２８の対応するＳＲ−ＩＯＶ ＶＦが存在する場合、１２８，０００の規則エントリが存在するであろうが、３２，０００または１６，０００といった数も可能であり得る。規則エントリは、少なくとも一部の実施形態において、信頼されるルートドメインによって定義されるように、ＶＦ間で分割可能であるべきである。例えば、１つのＶＦは、１０の規則エントリを有し得る一方で、別のＶＦは、規則エントリの可能な総数のうち２，０００を有する。規則表更新の性能もまた、パケット処理パイプラインに過剰なストールを引き起こさないように、十分に高速であるべきである、一部の実施形態において、規則表は、正常な動作中、約５秒程度ごとにその全体として修正される場合がある。

例示的な進出規則表は、多様な異なるフィールドを有することができる。一実施例において、規則表は、内部Ｌ２送信先ＭＡＣ（適合標的）フィールドを有する。全ての進出規則は、内部Ｌ２ ＭＡＣアドレスにおいて適合され得る。これは、顧客の仮想ネットワークが、所望される場合、Ｌ２のみであること（およびＬ３対応ではないＲｏＣＥのようなプロトコルをサポートすること）を可能にする。表はまた、サブネットマスク（適合標的）フィールドを伴う、オプションの内部ＩＰＶ４／ＩＰＶ６送信先を有することができる。進出規則は、任意に、標的ＩＰアドレス／サブネットにおいて適合され得る。サブネット規則の使用は、所望される場合、複数の規則が崩壊することを可能にする。オプションの内部Ｌ２ ＭＡＣ送信元／送信先マングリング置換フィールドもまた、使用することができる。任意のＬ３トポロジーをサポートするために、「ファントムルータ」をサポートするように、内部送信先および送信元ＭＡＣアドレスの両方を交換する能力をサポートすることができる。ＶＭは、例えば、それが、サブネットＡ上にあり、パケットをサブネットＢに送信使用としていると考える場合がある。このため、パケットは、以下のような、ゲストＶＭによって構築されるようなＬ２ヘッダを有し得る。
Ｌ２ ＭＡＣ送信元アドレス：ホスト１（サブネットＡ）ＶＦオフロードデバイスのＭＡＣアドレス
Ｌ２ ＭＡＣ送信先アドレス：サブネットＡゲートウェイのＭＡＣアドレス
進出時には、少なくとも一部の実施形態において、以下の実施例のように見えるように、内部Ｌ２ヘッダを動的にマングリングすることができる（それにより、パケットが標的上で脱カプセル化される時、内部Ｌ２ヘッダは、２つの仮想機械間に実ルータ（複数を含む）が存在した場合に予期されるもののように見える）ことが望ましい可能性がある。
Ｌ２ ＭＡＣ送信元アドレス：サブネットＢゲートウェイのＭＡＣアドレス
Ｌ２ ＭＡＣ送信先アドレス：ホスト２（サブネットＢ）ＶＦオフロードデバイスのＭＡＣアドレス
オプションの内部ＩＰ ＴＴＬデクリメントフィールドもまた、使用することができる。例えば、「ファントムルータ」をサポートするために、内部ＩＰ ＴＴＬ（該当する場合）を任意に自動デクリメントする能力が必要とされ得る。ＴＴＬがゼロに到達する場合、パケットは、信頼されるルートパーティションへトラップされるべきである。

表はまた、システムＲＡＭにおけるカプセル化ブロブに対するポインタといったフィールドを有することができる。ブロブの表は、信頼されるルートパーティションによって所有されるメモリに記憶することができる。これらのメモリアドレスは、例えば、機械固有のＤＭＡ機構に依存し得るような、信頼されるルートパーティションのホスト物理アドレスまたはゲスト物理アドレスであり得る。表はまた、メトリックのためのフィールド、および規則行為のための少なくとも１つのフィールドといった、追加のフィールドも含むことができる。上で述べられるように、規則行為は、例えば、信頼されるルートパーティションへのトラップ、パケットのドロップ、またはカプセル化／マングリング、および転送を指定することができる。

例示的な進入規則表は、種々のフィールドも有することができる。例えば、適合キー（適合標的）フィールドは、進入規則適合のために使用することができ、これは、システムのより複雑な態様のうちの１つであり得る。特定のカプセル化形式を必要とするハードウェアを有しないために、ハードウェアにおいて合理的に取得可能であるものの中でできる限り一般的であるスキームを利用することができる。図９は、一実施形態に従って、使用することができる、進入適合キー作成の例示的な実装を示す。オフロードデバイスは、いくつかのシステム定義されたバイト範囲および／またはバイト範囲コレータ９０４を利用することができ、これは、着信パケット９０２からのバイト範囲を照合するように、システム初期化時に、信頼されるルートパーティションによって、プログラムすることができる。これらのパケットは、一時的なバイトバッファ９０６、または他の適切な場所へと照合することができる。少なくとも一実施形態において、パケットの開始から２５６以下のバイトの０〜１２８バイトの４つのバイト範囲は、十分であり得、全てのバイト範囲は、ともに、合計で１２８超のバイトにはならない。次いで、さらなるシステム全体のビットマスク９０８（信頼されるルートパーティションによってプログラムされる）を、バイトバッファに適用して、どのバイトが規則表における適合に使用されるかを判断することができる。次いで、最終進入適合キー９１０を、結果として生成することができ、キーは、進入規則表において適切な規則をルックアップするために使用することができる。

他のフィールドは、進入規則表とともに使用することもできる。例えば、転送すべきＶＭ／ＶＦ ＩＤを明示的に指定することができる、ＶＭ／ＶＦ ＩＤフィールドを使用することができ、規則行為は、ＶＭ／ＶＦへの転送を含む。他のフィールドは、上で述べられる進出規則表と同様の、例えば、メトリックフィールド、および規則行為フィールドを含むことができる。メトリックは、信頼されるルートパーティションによる後の取り出しのために、ハードウェアによって収集することができる。進入／進出規則ごとに必要とされ得るメトリックの例としては、行為が行われる（ドロップされる、転送される等）バイト数、および行為が行われる（ドロップされる、転送される等）パケット数が挙げられる。各メトリックフィールドは、信頼されるルートパーティションによって読み取り可能かつ消去可能であるべきである。フィールドのサイズは、例えば、ハードウェアベンダの自由裁量により得、信頼されるルートパーティションからの割り込み駆動型の収集方法を想定することができる。

少なくとも一部の実施形態において、少なくとも２つの大まかなタイプの可能なスロットリングまたはサービスの質（ＱｏＳ）が存在する。第１のタイプは、本明細書において「ハードキャップ」タイプのスロットリングと称され、各スロットリングされたエンティティは、システムにおける他のスロットリングされたエンティティの使用にかかわらず、特定の量でキャップされる。第２のタイプは、本明細書において「バースト可能なキャップ」タイプと称され、スロットリングされたエンティティが、システムにおいて利用可能な余剰容量があるかどうかに依存して、それらのキャップ上でバーストすることが可能とされる。例示的な実施形態において、ＳＲ−ＩＯＶ仮想機能上で５０Ｍｂ／秒間隔（または一部の実施形態において、１０〜２５Ｍｂ／秒間隔）といった、ハードキャップを配置する能力が必要とされ得る。少なくとも一部の実施形態において、異なるトラフィックを異なる割合でスロットリングすることができるように、進出規則あたり少なくとも１つのスロットリングクラスを、および異なるトラフィックを優先化することができるように、進出規則あたり１つのＱｏＳクラスを、ハードウェアにおいて利用する。少なくとも一部の実施形態において、利用可能および所望される場合、未使用のシステム容量を、消費することができるように、１つ以上の構成可能な、バースト可能な、規則あたりのスロットリングクラスを提供することもまた、望ましい可能性がある。

少なくとも一部の実施形態において、パケットにおける種々のチェックを提供することが望ましい可能性がある。例えば、一部の実施形態において、全ての進出パケットは、ＶＦに割り当てられた正確なＬ２ ＭＡＣアドレスに対してチェックされなければならない。少なくとも一部の実施形態において、進出パケットがＬ３ ＩＰである場合、送信元ＩＰアドレスもまた、チェックされなければならない。正確なＬ２ ＭＡＣおよび／またはＬ３ ＩＰアドレスを有しないパケットは、少なくとも一部の実施形態において、ドロップされるべきである。ＤＨＣＰ、ＡＲＰ、ＩＰブロードキャスト、およびマルチキャスト等を含む、信頼されるルートパーティションへトラップされるように、全てのＬ２および／またはＬ３ブロードキャストトラフィックを構成する能力もまた存在し得る。さらに、信頼されるルートパーティションは、少なくとも一部の実施形態において、進入パケットを仮想機能パケットキューに注入する能力を有する。これらのパケットは、通常のマングリング／カプセル化システムを回避することができる。

少なくとも一部の実施形態において、オフロードデバイスハードウェアは、ＳＲ−ＩＯＶ仮想機能におけるカプセル化／マングリングを行いつつ、少なくとも１つの標準的な組のオフロードおよびハードウェア強化をサポートする。これらは、例えば、種々のチェックサムオフロード、マルチキュー能力、および割り込み合体を含む、ＴＣＰセグメント化オフロード（ＴＳＯ）を含むことができる。その組はまた、ＲＤＭＡサポート（例えば、ＲｏＣＥまたはｉＷＡＲＰ）を含むことができる。例えば、Ｌ２のみのＲＤＭＡプロトコルが使用される場合でさえも、パケットが、Ｌ３ラッパの内側でカプセル化されるという事実は、アプリケーションレベルプロトコルが、下部の物理的ネットワークサブストレートから不可知であり得るということを意味する。

ＳＲ−ＩＯＶの使用は、下部ハードウェアが、もはや抽象化されていないという点において、仮想化の利益を無効にし得る。高度な機能性をユーザに提供しつつ、同じレベルの柔軟性を保つために、ハードウェアベンダは、ＶＭＭからゲストＶＭにドライバコードを動的に注入する手法を提供することができる。かかる手法は、ゲストＶＭ内の単一の抽象ドライバが、共通のインターフェースを介して任意のハードウェアで実行することを可能にし、このため、ソフトウェアにおいて完全にエミュレートされるハードウェアデバイス、またはハードウェアにおいて主に実装されているもののいずれかをラップすることができる。

上で列記されるものに加えて、種々の他の規則もまた、実装することができる。例えば、進出パケットに関して、許容可能な送信先ＭＡＣアドレス、および各規則の「適合」部分を形成する送信先ＩＰサブネットのリストが存在し得る。規則は、送信先ＭＡＣアドレスおよび送信先ＩＰサブネットを有することができるか、または規則は、全てのＩＰアドレスを受け入れることができる場合、送信先ＭＡＣアドレスのみを有することができる。各規則は、規則の一部として、「Ｎ」バイトの不明瞭なヘッダ、送信元ＭＡＣアドレス、および標的ＭＡＣアドレスを有することができる。規則が適合する時、「Ｎ」バイトの不明瞭なヘッダは、元のＬ２ヘッダの前に挿入することができ、Ｌ２ヘッダ内のＭＡＣアドレスは、事前指定された値と置換することができる。新しい外部Ｌ２およびＬ３ヘッダ（例えば、ＭＡＣおよびＩＰ）は、規則表からの外部送信元ＩＰアドレス、外部送信先ＩＰアドレス、外部送信先ＭＡＣ、および外部送信元ＭＡＣとともに、不明瞭なフィールドの前に挿入することができる。任意に、不明瞭なヘッダは、Ｌ２およびＬ３ヘッダを含むことができ、オフロードデバイスは、すぐに、ＩＤ、長さ、チェックサム、およびフラグといったフィールドに記入することができる。一部の実施形態において、内部送信元および送信先ＩＰアドレスもまた、例えば、ＮＡＴ、エニーキャスト等の将来の仮想化を可能にするように、置換可能である。

処理および管理の少なくとも一部は、Ｘｅｎ Ｄｏｍ−０といった信頼されるホストプラットフォームにおいて実行するように動作可能な、ソフトウェア管理インターフェースによって実施することができる。かかるインターフェースは、スロットリング、セキュリティグループ、およびパートナ構成要素を含み得るような、テナントごとのネットワーク仕様をリアルタイムでロードするように、分散サービスと通信することができる。インターフェースは、例えば、テナントごとの（ＳＲ−ＩＯＶ）仕様を実行するように、オフロード構成要素に命令することができる。これらのコマンドは、仕様が変化する際に、リアルタイムで処理することができる。インターフェースはまた、ハードウェアまたは他のオフロード構成要素が、任意の所与の時間に、規則全体を同時に保持することができない場合、オフロード構成要素ベースの規則の拡張された管理を実施することができる。これらは、例えば、ソフトウェアトラップまたは他のかかるプロセスを介して、使用されることがより少ない規則のサブセットを処理しつつ、最新の規則、または頻繁に利用される規則のサブセットをローディングするといった、技術を含むことができる。インターフェースは、信頼されるホストプラットフォームまたは仮想テナントに対するトラフィックといった、異なるタイプのトラフィック間で区別することができ、かつ適宜配信することができる。

少なくとも一部の実施形態において、アドレス解決プロトコル（ＡＲＰ）パケットおよびマルチキャストパケットといった、特別な処理を必要とするパケットもまた、Ｄｏｍ−０内のソフトウェア管理構成要素によって管理することができる。ＤＮＳ、セキュリティインターフェース、およびウェブサーバインターフェースといった、他の高度な機能性もまた、ソフトウェア管理インターフェースによって処理することができる。セキュリティインターフェースに関して、インスタンスは、ネットワーク接続を得る前に、安全なログインを実施することができる。ウェブサーバインターフェースは、例えば、メタデータサービスまたは他のかかるアプリケーションに対するインターフェースであり得る。

種々の実施形態は、以下の付記を考慮して説明することができる。
付記１． マルチテナント環境において、データパケットを処理するためのフレームワークであって、
少なくとも１つのプロセッサと、
プロセッサによって実行される時、フレームワークが、
１つ以上のテナントごとのネットワーク仕様をロードするように、１つ以上の分散サービスと通信することと、
ロードされたテナントごとのネットワーク仕様を実行するように、少なくとも１つのオフロードデバイスに命令することと、
少なくとも１つのオフロードデバイスが、一組の規則の全てを同時に記憶することができない時、少なくとも１つのオフロードデバイスに対する一組の規則を管理することと、
複数のトラフィックタイプの各々に対する適切な送信先に、データパケットを配信することと、を可能にする、命令を含む、メモリと、を備える、フレームワーク。
付記２． フレームワークは、信頼されるホストドメインにおいて実行するように動作可能なソフトウェア管理インターフェースを提供する、付記１に記載のフレームワーク。
付記３． ソフトウェア管理インターフェースは、特別な処理を必要とするパケットを管理するようにさらに動作可能である、付記２に記載のフレームワーク。
付記４． 特別な処理を必要とするパケットは、マルチキャストパケット、ブロードキャストパケット、およびアドレス解決プロトコル（ＡＲＰ）パケットを含む、付記３に記載のフレームワーク。
付記５． ソフトウェア管理インターフェースは、ドメイン名サービス（ＤＮＳ）、セキュリティインターフェーシング、およびウェブサーバインターフェーシングのうちの少なくとも１つを含む機能性を管理するようにさらに動作可能である、付記２に記載のフレームワーク。
付記６． ソフトウェア管理インターフェースは、オフロードデバイスによって収集されることが必要なネットワーク統計、および維持されるべき統計を構成するように動作可能である、付記２に記載のフレームワーク。
付記７． テナントごとのネットワーク仕様は、データパケットのスロットリング、セキュリティグループの動作、およびパートナ構成要素間の通信のうちの少なくとも１つに対する仕様を含む、付記１に記載のフレームワーク。
付記８． テナントごとのネットワーク仕様は、ＳＲ−ＩＯＶネットワーク仕様である、付記１に記載のフレームワーク。
付記９． テナントごとのネットワーク仕様は、仕様が変化する際、リアルタイムで処理される、付記１に記載のフレームワーク。
付記１０． 少なくとも１つのオフロードデバイスに対する一組の規則の管理は、オフロードデバイスにおいて、規則の第１のサブセットをロードする一方で、ソフトウェアストラッピングを使用して、規則の第２のサブセットを処理することを含む、付記１に記載のフレームワーク。
付記１１． 規則の第１のサブセットは、規則の第２のサブセットよりもしばしば利用される、付記１０に記載のフレームワーク。
付記１２． テナントごとの仕様は、ハードウェアベンダが、複数のプロトコルに関する特定の情報を入手することなく、それらの複数のプロトコルをサポートすることを可能にする、付記１に記載のフレームワーク。
付記１３． トラフィックタイプは、信頼されるホストプラットフォームに対するトラフィック、および仮想テナントに対するトラフィックのうちの少なくとも１つを含む、付記１に記載のフレームワーク。
付記１４． オフロードデバイスであって、
プロセッサと、
プロセッサによって実行される時、オフロードデバイスが、
ハードウェアデバイスとしてオフロードデバイスを露出することと、
オフロードハードウェアデバイスと関連付けられる物理的機能に対して受信されるユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、データパケットの内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、ユーザデータパケットを内部仮想機能へ転送することと、を含み、内部仮想機能は、ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、を可能にする、命令を記憶するメモリと、を備える、オフロードデバイス。
付記１５． 処理は、少なくとも１つの外部カプセル化ヘッダをユーザデータパケットから除去することを含む、付記１４に記載のオフロードデバイス。
付記１６． オフロードデバイスは、ネットワークインターフェースカード（ＮＩＣ）である、付記１４に記載のオフロードデバイス。
付記１７． オフロードデバイスは、複数のプロトコルに関する特定の情報を入手することなく、それらの複数のプロトコルをサポートするように動作可能である、付記１４に記載のオフロードデバイス。
付記１８． マルチテナント環境において、データパケットを処理するための方法であって、
１つ以上のテナントごとのネットワーク仕様をロードするように、１つ以上の分散サービスと通信することと、
ロードされたテナントごとのネットワーク仕様を実行するように、少なくとも１つのオフロードデバイスに命令することと、
少なくとも１つのオフロードデバイスが、一組の規則の全てを同時に記憶することができない時、少なくとも１つのオフロードデバイスに対する一組の規則を管理することと、
複数のトラフィックタイプの各々に対する適切な送信先に、データパケットを配信することと、を含む、方法。
付記１９． 信頼されるホストドメインにおいて実行するように動作可能なソフトウェア管理インターフェースを露出することと、をさらに含む、付記１８に記載の方法。
付記２０． ソフトウェア管理インターフェースは、ドメイン名サービス（ＤＮＳ）、セキュリティインターフェーシング、およびウェブサーバインターフェーシングのうちの少なくとも１つを含む機能性を管理するようにさらに動作可能である、付記１９に記載の方法。
付記２１． オフロードデバイスは、ＳＲ−ＩＯＶネットワーク仕様に従って動作する、付記１９に記載の方法。
付記２２． 電子環境において、データパケットを処理するためのコンピュータ実装方法であって、
実行可能な命令とともに構成される１つ以上のコンピュータシステムの制御下で、
ユーザに対する仮想ネットワークと関連付けられる仮想機能に対するユーザデータパケットを受信することと、
ユーザデータパケットを処理するための少なくとも１つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、外部ヘッダをユーザデータパケットに追加することと、ユーザデータパケットを物理的ネットワーク上へ送信することと、を含み、外部ヘッダは、少なくとも１つの不明瞭なフィールドを含み、かつプロトコル固有の情報を含む、実施することと、を含む、コンピュータ実装方法。
付記２３． ルックアップを実施する前に、ユーザデータパケットに対して、少なくとも１つの一般チェックを実施することをさらに含む、付記２２に記載のコンピュータ実装方法。
付記２４． 少なくとも１つの一般チェックは、少なくとも１つのタイプのパケットに対するレベル２（Ｌ２）またはレベル３（Ｌ３）アンチスプーフィング、またはトラッピングのうちの少なくとも１つを含む、付記２３に記載のコンピュータ実装方法。
付記２５． ルックアップは、オフロードデバイスによって実施される、付記２２に記載のコンピュータ実装方法。
付記２６． オフロードデバイスは、シングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）プロトコルに基づく、仮想化されたオーバーレイネットワークを提供する、付記２５に記載のコンピュータ実装方法。
付記２７． ルックアップを実施する前に、ユーザデータパケットにおいて、少なくとも１つのメトリック更新を実施することをさらに含む、付記２２に記載のコンピュータ実装方法。
付記２８． オフロードデバイスを使用する処理は、ユーザデータパケットのスロットリング、またはサービスの質行為の実施のうちの少なくとも１つをさらに含む、付記２２に記載のコンピュータ実装方法。
付記２９． ユーザデータパケットを物理的ネットワークに送信することは、セグメント化オフロードプロセスの一部として実施される、付記２２に記載のコンピュータ実装方法。
付記３０． オフロードデバイスを使用する処理は、ユーザデータパケットのヘッダフィールドを更新することをさらに含み、ヘッダフィールドは、内部および外部パケットの長さ、ならびに内部および外部チェックサム、送信元および送信先アドレス、ならびに有効時間（ＴＴＬ）値のうちの少なくとも１つを含む、付記２２に記載のコンピュータ実装方法。
付記３１． オフロードデバイスを使用する処理は、少なくとも部分的に送信元仮想機械に基づいて、各進出パケットにおいて、パケット送信元チェックを実施することを含む、付記２２に記載のコンピュータ実装方法。
付記３２． ソフトウェアベースの処理は、Ｄｏｍ−０制御ソフトウェアによる処理を含む、付記２２に記載のコンピュータ実装方法。
付記３３． 処理は、ルックアップキーのパラメータの変更を通じて、いかなる適切なプロトコルもサポートすることができるように、一般形式を利用する、付記２２に記載のコンピュータ実装方法。
付記３４． 適切なプロトコルを、ステートレストンネリングプロトコルにマップすることができる、付記３３に記載のコンピュータ実装方法。
付記３５． 電子環境において、データパケットを処理するためのコンピュータ実装方法であって、
実行可能な命令とともに構成される１つ以上のコンピュータシステムの制御下で、
オフロードデバイスと関連付けられる物理的機能に対するユーザデータパケットを受信することと、
オフロードデバイスを使用して、ユーザデータパケットに対するルックアップキーを構築することと、
ルックアップキーを使用してユーザデータパケットを処理するための少なくとも１つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、ユーザデータパケットを内部仮想機能へ転送することとを含み、内部仮想機能は、ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、を含む、コンピュータ実装方法。
付記３６． オフロードデバイスを使用する処理は、少なくとも１つの外部カプセル化ヘッダをユーザデータパケットから除去することを含む、付記３５に記載のコンピュータ実装方法。
付記３７． 内部仮想機能は、転送規則によって識別される、付記３５に記載のコンピュータ実装方法。
付記３８． オフロードデバイスを使用する処理は、事前定義されたオフセットにおいて、事前定義されたプロトコルの形式を使用してカプセル化されているとして、ユーザデータパケットを識別するように動作可能である、付記３５に記載のコンピュータ実装方法。
付記３９． ユーザデータパケットがカプセル化されない時、ソフトウェアベースの処理を使用して、ユーザデータパケットを処理することをさらに含む、付記３５に記載のコンピュータ実装方法。
付記４０． オフロードデバイスは、ネットワークインターフェースカード（ＮＩＣ）である、付記３５に記載のコンピュータ実装方法。
付記４１． ユーザデータパケット内の既定のオフセットにおける不明瞭なビット内の固定長フィールドを使用して、ユーザデータパケットに対応する仮想機械を判断することをさらに含む、付記３５に記載のコンピュータ実装方法。
付記４２． 各物理的機能は、一組の進入規則を有し、各規則は、少なくとも部分的に、カプセル化された進入パケットの不明瞭なビットと適合されることが可能である、一組の不明瞭なビットから成る、付記３５に記載のコンピュータ実装方法。
付記４３． 他のトラフィックは、規則表からの通過規則の判断に応答して、処理を伴わずに通過される、付記３５に記載のコンピュータ実装方法。
付記４４． 顧客がカプセル化したトラフィックおよび制御トラフィックは、規則表からの通過規則の判断から独立してトラップされる、付記３５に記載のコンピュータ実装方法。
付記４５． 電子環境において、データパケットを処理するためのシステムであって、
プロセッサと、
プロセッサによって実行される時、プロセッサに、
ユーザに対する仮想ネットワークと関連付けられる仮想機能に対するユーザデータパケットを受信することと、
ユーザデータパケットを処理するための少なくとも１つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、外部ヘッダをユーザデータパケットに追加することと、ユーザデータパケットを物理的ネットワーク上へ送信することと、を含み、外部ヘッダは、少なくとも１つの不明瞭なフィールドを含み、かつプロトコル固有の情報を含む、実施することと、を行わせる、命令を含むメモリデバイスと、を備える、システム。
付記４６． ルックアップを実施するように動作可能な、少なくとも１つのオフロードデバイスをさらに備える、付記４６に記載のシステム。
付記４７． オフロードデバイスは、シングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）プロトコルに基づく、仮想化されたオーバーレイネットワークを提供する、付記４６に記載のシステム。
付記４８． 電子環境において、データパケットを処理するためのシステムであって、
プロセッサと、
プロセッサによって実行される時、プロセッサに、
オフロードデバイスと関連付けられる物理的機能に対するユーザデータパケットを受信することと、
オフロードデバイスを使用して、ユーザデータパケットに対するルックアップキーを構築することと、
ルックアップキーを使用してユーザデータパケットを処理するための少なくとも１つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、ユーザデータパケットを内部仮想機能へ転送することとを含み、内部仮想機能は、ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、を行わせる、命令を含むメモリデバイスと、を備える、システム。
付記４９． オフロードデバイスを使用する処理は、少なくとも１つの外部カプセル化ヘッダをユーザデータパケットから除去することを含む、付記４８に記載のシステム。
付記５０． オフロードデバイスは、ネットワークインターフェースカード（ＮＩＣ）である、付記４８に記載のシステム。

上で述べられるように、種々の実施形態は、一部の場合において、いくつかのアプリケーションのうちのいずれかを動作させるために使用することができる、１つ以上のユーザコンピュータ、コンピューティングデバイス、または処理デバイスを含むことができる、多種多様な動作環境において実装することができる。ユーザまたはクライアントデバイスは、標準的なオペレーティングシステムを実行するデスクトップまたはラップトップコンピュータといった、いくつかの汎用パーソナルコンピュータ、ならびにモバイルソフトウェアを実行し、いくつかのネットワーキングおよびメッセージングプロトコルをサポートすることが可能である、セルラ、無線、およびハンドヘルドデバイスのうちのいずれかを含むことができる。かかるシステムはまた、多様な商業的に利用可能なオペレーティングシステム、ならびに開発およびデータベース管理といった目的のための他の既知のアプリケーションを実行する、いくつかのワークステーションを含むことができる。これらのデバイスはまた、ネットワークを介して通信することが可能なダミー端末、シンクライアント、ゲームシステム、および他のデバイスといった他の電子デバイスを含むことができる。

種々の態様もまた、サービス指向アーキテクチャの一部であってもよいように、少なくとも１つのサービスまたはウェブサービスの一部として実装することができる。ウェブサービスといったサービスは、拡張可能マークアップ言語（ＸＭＬ）形式のメッセージを使用し、ＳＯＡＰ（「シンプルオブジェクトアクセスプロトコル」から派生）等の適切なプロトコルを使用して交換する等によって、任意の適切なタイプのメッセージングを使用して通信することができる。かかるサービスによって提供または実行されるプロセスは、ウェブサービス記述言語（ＷＳＤＬ）といった任意の適切な言語で書くことができる。ＷＳＤＬといった言語を使用することは、種々のＳＯＡＰフレームワークにおけるクライアントサイドコードの自動生成といった機能性を可能にする。

ほとんどの実施形態は、ＴＣＰ／ＩＰ、ＯＳＩ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ、ＣＩＦＳ、およびＡｐｐｌｅＴａｌｋといった多様な商業的に利用可能なプロトコルのうちのいずれかを使用する通信をサポートするために、当業者が熟知しているであろう、少なくとも１つのネットワークを利用する。ネットワークは、例えば、ローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、およびこれらの組み合わせであり得る。

ウェブサーバを利用する実施形態において、ウェブサーバは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データサーバ、Ｊａｖａサーバ、およびビジネスアプリケーションサーバを含む、多様なサーバまたは中間層アプリケーションのうちのいずれかを稼動することができる。サーバはまた、Ｊａｖａ（登録商標）、Ｃ、Ｃ＃またはＣ＋＋等の任意のプログラム言語、あるいはＰｅｒｌ、Ｐｙｔｈｏｎ、またはＴＣＬ等の任意のスクリプト言語、ならびにこれらの組み合わせで作成された１つ以上のスクリプトまたはプログラムとして実装されてもよい、１つ以上のウェブアプリケーションを実行することによって等、ユーザデバイスからのリクエストに応答して、プログラムまたはスクリプトを実行することが可能であってもよい。サーバはまた、これらに限定されないが、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、およびＩＢＭ（登録商標）から市販されているデータベースサーバを含んでもよい。

環境は、上で述べられるように、多様なデータストアならびに他のメモリおよび記憶媒体を含むことができる。これらは、コンピュータのうちの１つ以上にローカルの（および／もしくは内部に常駐）、あるいはネットワーク全体のコンピュータのうちのいずれかまたは全てからリモートの記憶媒体等、多様な場所に常駐することができる。特定の組の実施形態において、情報は、当業者が熟知するストレージエリアネットワーク（「ＳＡＮ」）の中に常駐してもよい。同様に、コンピュータ、サーバ、または他のネットワークデバイスに帰属する機能を実施するための必要ないずれのファイルも、必要に応じて、ローカルおよび／またはリモートに記憶されてもよい。システムがコンピュータデバイスを含む場合、各かかるデバイスは、バスを介して電気的に連結されてもよいハードウェア要素を含むことができ、要素としては、例えば、少なくとも１つの中央処理装置（ＣＰＵ）、少なくとも１つの入力デバイス（例えば、マウス、キーボード、コントローラ、タッチ画面、またはキーパッド）、および少なくとも１つの出力デバイス（例えば、表示デバイス、プリンタ、またはスピーカ）が挙げられる。かかるシステムはまた、ランダムアクセスメモリ（以下「ＲＡＭ」）、または読み取り専用メモリ（以下「ＲＯＭ」）、ならびに取り外し可能媒体デバイス、メモリカード、フラッシュカード等のディスクドライブ、光学式記憶装置、およびソリッドステート記憶装置などの１つ以上の記憶装置も含んでもよい。

かかるデバイスはまた、上で説明されるように、コンピュータが読み取り可能な記憶媒体リーダ、通信デバイス（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信デバイス等）、およびワーキングメモリを含むことができる。コンピュータが読み取り可能な記憶媒体リーダは、コンピュータが読み取り可能な情報を一時的におよび／またはより永続的に含有、記憶、伝送、および取り出すためのリモート、ローカル、固定、および／または取り外し可能な記憶デバイス、ならびに記憶媒体を代表する、コンピュータが読み取り可能な記憶媒体と接続、またはそれを受容するように構成することができる。システムおよび種々のデバイスはまた、典型的に、オペレーティングシステム、およびクライアントアプリケーションまたはウェブブラウザといったアプリケーションプログラムを含む、少なくとも１つのワーキングメモリデバイス内に位置する、いくつかのソフトウェアアプリケーション、モジュール、サービス、または他の要素を含む。代替的な実施形態は、上で説明されるものからの数多くの変形を有し得るということが理解されるべきである。例えば、カスタム化されたハードウェアが使用される場合があり、かつ／または特定の要素が、ハードウェア、ソフトウェア（アプレットといったポータブルソフトウェアを含む）、またはこれらの両方において実装される場合がある。さらに、ネットワーク入力／出力デバイスといった、他のコンピューティングデバイスへの接続が採用されてもよい。

コードまたはコードの一部分を含有するための記憶媒体およびコンピュータが読み取り可能な媒体としては、所望の情報を記憶するために使用することができ、かつシステムデバイスによってアクセスすることができる、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または任意の他の媒体を含む、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータといった、情報の記憶および／もしくは伝送のための任意の方法または技術において実装される、揮発性および非揮発性、取り外し可能および非取り外し可能な媒体等であるが、これらに限定されない、記憶媒体および通信媒体を含む、当該技術分野において既知または使用される、任意の適切な媒体を挙げることができる。本明細書において提供される開示および教示に基づいて、当業者は、種々の実施形態を実装するための他の方式および／または方法を理解するであろう。

したがって、明細書および図面は、制限の意味ではなく、例解の意味で解釈されるべきである。しかしながら、請求項に記載の本発明の広義の精神および範囲から逸脱することなく、そこに多様な修正および変更が行われてもよいことは自明である。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［１］オフロードデバイスであって、
プロセッサと、
前記プロセッサによって実行される時、前記オフロードデバイスが、
ハードウェアデバイスとして前記オフロードデバイスを露出することと、
前記オフロードハードウェアデバイスと関連付けられる物理的機能に対して受信されるユーザデータパケットの処理の少なくとも一部分を実施することとであって、前記処理は、少なくとも、前記データパケットの内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、前記ユーザデータパケットを、内部仮想機能へ転送することと、を含み、前記内部仮想機能は、前記ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、
を可能にする、命令を記憶するメモリと、を備える、オフロードデバイス。
［２］前記処理は、少なくとも１つの外部カプセル化ヘッダを前記ユーザデータパケットから除去することを含む、［１］に記載のオフロードデバイス。
［３］前記オフロードデバイスは、ネットワークインターフェースカード（ＮＩＣ）である、［１］に記載のオフロードデバイス。
［４］前記オフロードデバイスは、複数のプロトコルに関する特定の情報を入手することなく、それらの複数のプロトコルをサポートするように、動作可能である、［１］に記載のオフロードデバイス。
［５］電子環境において、データパケットを処理するためのコンピュータ実装方法であって、
実行可能な命令とともに構成される１つ以上のコンピュータシステムの制御下で、
オフロードデバイスと関連付けられる物理的機能に対するユーザデータパケットを受信することと、
前記オフロードデバイスを使用して、前記ユーザデータパケットのためのルックアップキーを構築することと、
前記ルックアップキーを使用して、前記ユーザデータパケットを処理するために、少なくとも１つの規則に対して、規則表においてルックアップを実施することと、
前記規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいて、前記ユーザデータパケットのソフトウェアベースの処理を実施することと、
前記規則表からのドロップ規則の判断に応答して、前記ユーザデータパケットのさらなる処理を実施しないことと、
前記規則表からの転送規則の判断に応答して、前記オフロードデバイスを使用して、前記ユーザデータパケットの前記処理の少なくとも一部分を実施することであって、前記処理は、少なくとも、内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、前記ユーザデータパケットを、内部仮想機能へ転送することとを含み、前記内部仮想機能は、前記ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、を含む、コンピュータ実装方法。
［６］前記オフロードデバイスを使用する前記処理は、前記ユーザデータパケットから少なくとも１つの外部カプセル化ヘッダを除去することを含む、［５］に記載のコンピュータ実装方法。
［７］前記内部仮想機能は、前記転送規則によって識別される、［５］に記載のコンピュータ実装方法。
［８］前記オフロードデバイスを使用する前記処理は、事前定義されたオフセットにおいて、事前定義されたプロトコルの形式を使用してカプセル化されているとして、前記ユーザデータパケットを識別するように動作可能である、［５］に記載のコンピュータ実装方法。
［９］オフロードデバイスを使用する前記処理は、前記ユーザデータパケットのヘッダフィールドを更新することをさらに含み、前記ヘッダフィールドは、内部および外部パケットの長さ、ならびに内部および外部チェックサム、送信元および送信先アドレス、ならびに有効時間（ｔｉｍｅ−ｔｏ−ｌｉｖｅ：ＴＴＬ）値のうちの少なくとも１つを含む、［５］に記載のコンピュータ実装方法。
［１０］前記ユーザデータパケットがカプセル化されない時、ソフトウェアベースの処理を使用して、前記ユーザデータパケットを処理することをさらに含む、［５］に記載のコンピュータ実装方法。
［１１］前記オフロードデバイスは、ネットワークインターフェースカード（ＮＩＣ）である、［５］に記載のコンピュータ実装方法。
［１２］前記ユーザデータパケット内の既定のオフセットにおける不明瞭なビット内の固定長フィールドを使用して、前記ユーザデータパケットに対応する仮想機械を判断することをさらに含む、［５］に記載のコンピュータ実装方法。
［１３］各物理的機能は、一組の進入規則を有し、各規則は、少なくとも部分的に、カプセル化された進入パケットの前記不明瞭なビットと適合されることが可能である、一組の不明瞭なビットから成る、［５］に記載のコンピュータ実装方法。
［１４］他のトラフィックは、前記規則表からの通過規則の判断に応答して、処理を伴わずに通過される、［５］に記載のコンピュータ実装方法。
［１５］顧客がカプセル化したトラフィックおよび制御トラフィックは、前記規則表からの通過規則の判断から独立してトラップされる、［５］に記載のコンピュータ実装方法。

Claims (15)

1. 仮想アドレス空間における仮想化された顧客ネットワークのゲスト仮想機械がホスト機械の物理的リソースにマッピングされるマルチテナント環境中でデータパケットを処理するためのフレームワークにおいて、
   前記フレームワークは、
   少なくとも１つのプロセッサと、
   命令を含むメモリと、
   を具備し、
   前記命令は、前記少なくとも１つのプロセッサによって実行されるとき、前記少なくとも１つのプロセッサに、
   前記データパケットを処理するための１組の規則を適用するように少なくとも１つのオフロードデバイスを構成させ、ここにおいて、前記１組の規則は、前記ゲスト仮想機械から前記データパケットをルーティングするために前記データパケットを処理するための行為を決定するためにオフロードデバイスによって使用され、
   前記少なくとも１つのオフロードデバイスが前記１組の規則の少なくとも一部分を記憶する一方で、前記少なくとも１つのオフロードデバイスが前記１組の規則のすべてを同時には記憶できないとき、前記少なくとも１つのオフロードデバイスに対する前記１組の規則を管理させ、
   前記少なくとも１つのオフロードデバイスが前記１組の規則を適用することに少なくとも部分的によって、前記データパケットからの少なくとも１つのデータパケット上で前記行為を実施させ、ここにおいて、前記行為は、送られるべき前記少なくとも１つのデータパケットが、前記ゲスト仮想機械のための正しいメディアアクセス制御アドレスまたはインターネットプロトコルアドレスを有しているかどうかを決定するために、前記少なくとも１つのデータパケットを送る前記ゲスト仮想機械のメディアアクセス制御アドレスまたはインターネットプロトコルアドレスをチェックすることを具備する、
   フレームワーク。
2. 前記少なくとも１つのオフロードデバイスに対する前記１組の規則を管理することは、前記１組の規則のうちの第１のサブセットを前記少なくとも１つのオフロードデバイスにロードする一方で、前記少なくとも１つのオフロードデバイスなしで前記１組の規則のうちの第２のサブセットを処理することをさらに含む、請求項１記載のフレームワーク。
3. 前記データパケットからの少なくとも１つのデータパケット上で前記行為を実施することは、
   前記ゲスト仮想機械の、前記メディアアクセス制御アドレスまたは前記インターネットプロトコルアドレスが正しくないと決定することと、
   前記少なくとも１つのデータパケットをドロップすることと、
   をさらに含む、請求項１記載のフレームワーク。
4. 前記データパケットからの少なくとも１つのデータパケット上で前記行為を実施することは、
   前記少なくとも１つのデータパケットが、ブロードキャストパケットまたはマルチキャストパケットのうちの少なくとも１つであると決定することと、
   前記少なくとも１つのデータパケットの処理のために、信頼されるルートドメイン中に、前記少なくとも１つのデータパケットをトラップすることと、
   をさらに含む、請求項１記載のフレームワーク。
5. 前記データパケットからの少なくとも１つのデータパケット上で前記行為を実施することは、
   前記少なくとも１つのデータパケットを宛先に転送するための少なくとも１つの規則に、前記少なくとも１つのデータパケットが適合すると決定することと、
   前記少なくとも１つの規則によって参照される少なくとも１つのトンネルヘッダを記述するデータを取得し、前記トンネルヘッダは前記宛先を参照することと、
   前記少なくとも１つのトンネルヘッダを前記少なくとも１つのデータパケットに挿入することと、
   前記少なくとも１つのデータパケットを前記宛先に送ることと、
   をさらに含む、請求項１記載のフレームワーク。
6. 仮想アドレス空間における仮想化された顧客ネットワークのゲスト仮想機械がホスト機械の物理的リソースにマッピングされるマルチテナント環境中でデータパケットを処理するための方法において、
   前記方法は、
   前記データパケットを処理するための１組の規則を適用するように少なくとも１つのオフロードデバイスに命令することと、ここにおいて、前記１組の規則は、前記ゲスト仮想機械から前記データパケットをルーティングするために前記データパケットを処理するための行為を決定するためにオフロードデバイスによって使用され、
   前記少なくとも１つのオフロードデバイスが前記１組の規則のすべてを同時には記憶できないとき、前記少なくとも１つのオフロードデバイスに対する前記１組の規則を管理することと、
   前記少なくとも１つのオフロードデバイスが前記１組の規則を適用することに少なくとも部分的によって、前記データパケットからの少なくとも１つのデータパケット上で前記行為を実施することと、
   を含み、
   前記少なくとも１つのデータパケット上で前記行為を実施することは、前記少なくとも１つのデータパケットの更なるソフトウェアベースの処理を実施することによって、前記少なくとも１つのデータパケットを送るゲスト仮想機械に対して、帯域幅スロットリング制約またはサービス品質（ＱｏＳ）制約を実施することを含む、方法。
7. 前記少なくとも１つのデータパケット上で前記行為を実施することは、前記少なくとも１つのデータパケットに少なくとも部分的に基づいて、１つ以上のネットワークメトリックを更新することをさらに含み、
   前記１つ以上のメトリックは、前記オフロードデバイスの作用を受けるバイト数、または、前記オフロードデバイスの作用を受けるデータパケット数、のうちの少なくとも１つを記述する、
   請求項６記載の方法。
8. 前記帯域幅スロットリング制約または前記ＱｏＳ制約は、前記ゲスト仮想機械に対応する１つ以上のネットワークメトリックに少なくとも部分的に基づいており、
   前記１つ以上のメトリックは、前記オフロードデバイスの作用を受けるバイト数、または、前記オフロードデバイスの作用を受けるデータパケット数、のうちの少なくとも１つを記述する、
   請求項６記載の方法。
9. 前記少なくとも１つのオフロードデバイスに対する前記１組の規則を管理することは、前記１組の規則のうちの第１のサブセットを前記少なくとも１つのオフロードデバイスにロードする一方で、前記１組の規則のうちの第２のサブセットを処理することをさらに含み、
   前記規則の第１のサブセット中の各規則は、最新の規則または頻繁に利用される規則のうちの少なくとも１つであり、
   前記１組の規則のうちの前記第２のサブセットは、ソフトウェアに少なくとも部分的によって処理される、
   請求項６記載の方法。
10. 前記オフロードデバイスの前記行為は、前記ゲスト仮想機械によるアクセスから安全にされる、請求項１に記載のフレームワーク。
11. 前記オフロードデバイスの前記行為は、前記ゲスト仮想機械によるアクセスから安全にされる、請求項６に記載の方法。
12. 前記規則の組は、前記ゲスト仮想機械の仮想アドレス空間と物理アドレス空間との間で前記データパケットをルーティングするために前記データパケットを処理するための行為を決定するために、前記オフロードデバイスによって使用される、請求項１に記載のフレームワーク。
13. 前記規則の組は、前記ゲスト仮想機械の仮想アドレス空間と物理アドレス空間との間で前記データパケットをルーティングするために前記データパケットを処理するための行為を決定するために、前記オフロードデバイスによって使用される、請求項６に記載の方法。
14. マルチテナント環境中でデータパケットを処理するためのフレームワークにおいて、
    前記フレームワークは、
    少なくとも１つのプロセッサと、
    命令を含むメモリと、
    を具備し、
    前記命令は、前記少なくとも１つのプロセッサによって実行されるとき、前記少なくとも１つのプロセッサに、
    前記データパケットを処理するための１組の規則を適用するように少なくとも１つのオフロードデバイスを構成させ、
    前記少なくとも１つのオフロードデバイスが前記１組の規則の少なくとも一部分を記憶する一方で、前記少なくとも１つのオフロードデバイスが前記１組の規則のすべてを同時には記憶できないとき、前記少なくとも１つのオフロードデバイスに対する前記１組の規則を管理させ、
    前記少なくとも１つのオフロードデバイスが前記１組の規則を適用することに少なくとも部分的によって、前記データパケットからの少なくとも１つのデータパケットを処理させ、ここにおいて、前記少なくとも１つのデータパケットを処理することは、
    前記少なくとも１つのデータパケットを送るゲスト仮想機械のメディアアクセス制御アドレスまたはインターネットプロトコルアドレスをチェックすることと、
    前記少なくとも１つのデータパケットが、ブロードキャストパケットまたはマルチキャストパケットの少なくとも一方であることを決定することと、
    前記少なくとも１つのデータパケットの処理のために、信頼されるルートドメイン中に、前記少なくとも１つのデータパケットをトラップすることと、
    を具備する、
    フレームワーク。
15. マルチテナント環境中でデータパケットを処理するためのフレームワークにおいて、
    前記フレームワークは、
    少なくとも１つのプロセッサと、
    命令を含むメモリと、
    を具備し、
    前記命令は、前記少なくとも１つのプロセッサによって実行されるとき、前記少なくとも１つのプロセッサに、
    前記データパケットを処理するための１組の規則を適用するように少なくとも１つのオフロードデバイスを構成させ、
    前記少なくとも１つのオフロードデバイスが前記１組の規則の少なくとも一部分を記憶する一方で、前記少なくとも１つのオフロードデバイスが前記１組の規則のすべてを同時には記憶できないとき、前記少なくとも１つのオフロードデバイスに対する前記１組の規則を管理させ、
    前記少なくとも１つのオフロードデバイスが前記１組の規則を適用することに少なくとも部分的によって、前記データパケットからの少なくとも１つのデータパケットを処理させ、ここにおいて、前記少なくとも１つのデータパケットを処理することは、
    前記少なくとも１つのデータパケットを送るゲスト仮想機械のメディアアクセス制御アドレスまたはインターネットプロトコルアドレスをチェックすることと、
    前記少なくとも１つのデータパケットを宛先に転送するための少なくとも１つの規則に、前記少なくとも１つのデータパケットが適合すると決定することと、
    前記少なくとも１つの規則によって参照される少なくとも１つのトンネルヘッダを記述するデータを取得し、前記トンネルヘッダは前記宛先を参照することと、
    前記少なくとも１つのトンネルヘッダを前記少なくとも１つのデータパケットに挿入することと、
    前記少なくとも１つのデータパケットを前記宛先に送ることと、
    を具備する、
    フレームワーク。

Images