JP2020162146A - 仮想ネットワークにおける分散型フロー状態ｐ２ｐ設定のためのシステムおよび方法 - Google Patents

Abstract

【課題】物理ネットワーク上で仮想ネットワークをオーバーレイするシステムは、状態を記憶するデータベースに依存することなく、オーバーレイネットワークを実装する。【解決手段】ピアツーピアのメタデータ交換に基づく仮想ネットワークの実装および管理のためのシステムにおいて、下位ネットワークにオーバーレイする仮想ネットワークを通過するフローに関連するメタデータは、仮想ネットワークに対する下位ネットワークを介してデータパケットを送信するべく実行されるアクションに従って生成され、メタデータは下位ネットワークのノードの組へ送信される１つまたは複数の制御パケット内にカプセル化される。ノードの組の各ノードは、受信されたメタデータのコピーをローカルデータストア内の１つまたは複数の制御パケット内に維持し、メタデータはフローのパケットを処理するのに必要となったとき、ローカルデータストアを介してアクセスされる。【選択図】図１

Description

［関連出願の相互参照］
本出願は、参照によって全体が本明細書に組み込まれる、２０１４年１０月１４日に申請された、「仮想ネットワークにおける分散型フロー状態Ｐ２Ｐ設定のためのシステムおよび方法」と題された米国仮特許出願第６２／０６３，９０５号の優先権を主張する。

本出願は概して、ネットワークに関し、具体的には、物理ネットワーク上で仮想ネットワークをオーバーレイするシステムの方法に関する。より具体的には、本出願は、状態を記憶するデータベースに依存することなく、オーバーレイネットワークを実装することに関する。

クラウドベースのコンピューティングの出現により、サービスプロバイダに対する新たな要求が生まれた。サービスプロバイダは、ホストを追加でき、仮想トポロジを変更できる機能と併せて、物理ネットワークから切り離された仮想ネットワークを各顧客に提供するように努めている。ネットワークの仮想化により、物理ハードウェアの対応する何らかの変更を行うことなく、仮想ルータおよび仮想スイッチを構成することによって変更できる、顧客が構成可能なネットワークトポロジを作成できる。仮想化は更に、セキュリティおよび従量式課金のための、顧客データの分離をサポートする。

専用ハードウェアは、仮想化の機能を提供できるが、大きな費用が発生する。その他に、仮想ネットワークを既存の物理ネットワークにオーバーレイすることを可能にしながら、仮想ネットワークのトポロジを下位ネットワークと無関係に変更することを更に可能にするというソリューションが存在する。例えば、参照によって全体が本明細書に組み込まれる、「仮想ネットワークを実装および管理するためのシステムおよび方法」と題された米国特許出願第１４／２３６，０２０号（本明細書では以降、「〜０２０出願」と呼ぶ）が、そのようなソリューションを記載している。

〜０２０出願は、物理ネットワーク上にオーバーレイされた仮想ネットワークを使用してパケットルーティングを容易にするシステムおよび方法を開示している。〜０２０出願は、Ｌ２（第２層、すなわちデータリンク層）、Ｌ３（第３層、すなわちネットワーク層）、および、Ｌ４（第４層、すなわちトランスポート層）を含む、ＯＳＩモデルの複数の層におけるネットワーク要素の柔軟な相互接続を提供している。ネットワーク要素は、仮想Ｌ２スイッチおよびＬ３ルータによって、相互接続され得る。仮想Ｌ２ネットワークのパケットは、Ｌ３ネットワークのいかなる変更も必要とすることなく、トンネリングを使用して、既存のＬ３ネットワーク上で伝送され得る。ＧＲＥ、Ｅｔｈｅｒｎｅｔ ｏｖｅｒ ＩＰ（登録商標）、ＶＸＬａｎ、ＭＰＬＳ ｏｖｅｒ ＩＰ、または、ＣＡＰＷＡＰなど、様々なトンネリング方法が使用され得る。仮想Ｌ３ルータによってルーティングされるインターネットプロトコル（ＩＰ）パケットは、既存のＬ３ネットワークのいかなる変更も必要とすることなく、既存のＬ３ネットワーク上で伝送され得る。ネットワーク要素の（仮想的または物理的）編成、接続状態、パケット管理などに関連するデータは、パケットの処理または取り扱いを担当するネットワークノードがアクセス可能な、共有データベース内に記憶することができる。

後述の詳細な説明および付属図面における、例示的な非限定的実施形態の様々な態様の基本的または一般的な理解を可能にするべく、本明細書には単純化された概要が提供されている。しかしながら、この概要は、広範または網羅的な概要であることを意図しているわけではない。むしろ、この概要の唯一の目的は、後述の様々な実施形態の詳細な説明に対する前置きとして、いくつかの例示的な非限定的実施形態に関連するいくつかの概念を、より単純化した形式で提示することである。

様々な非限定的実施形態において、ピアツーピアのメタデータ交換に基づく、仮想ネットワークの実装および管理が開示されている。下位ネットワークにオーバーレイしている仮想ネットワークを通過するフローに関連するメタデータは、仮想ネットワークに対する下位ネットワークを介してデータパケットを送信するべく実行されるアクションに応じて生成される。メタデータは、下位ネットワークのノードの組に送信される１つまたは複数の制御パケット内にカプセル化される。ノードの組の各ノードは、１つまたは複数の制御パケット内にある受信したメタデータのコピーを、ローカルデータストア内に維持する。メタデータは、フローのパケットを処理するのに必要になったとき、ローカルデータストアを介ししてアクセスされる。

これらの実施形態、および他の実施形態は、以下でより詳細に説明されている。

様々な非限定的実施形態が、付属の図面を参照しながら、更に記載されている。

システムが汎用ネットワーク（サービスプロバイダのＩＰファブリックへのインターネットなど）との間でパケットをルーティングするのに使用するサーバコンピュータの例を示す。

例示的な物理ネットワークを示す。

図２の物理ネットワーク上にオーバーレイされ得る仮想ネットワークの例を示す。

仮想ルータから成る仮想トポロジ内でパケットをルーティングするべく、エッジコネクタ上で実行されるプロセスを示す。

仮想ルータおよび仮想スイッチから成る仮想トポロジ内でパケットをスイッチングおよびルーティングするべく、エッジコネクタ上で実行されるプロセスを示す。

図５のプロセスの続きである。

仮想ネットワークの実施形態を示す。

物理ネットワーク上にオーバーレイされる図７の仮想ネットワークを示す。

共有データベースによるフロー状態管理を示す。

状態のプッシュによるフロー状態管理を示す。

［汎用システムアーキテクチャおよび動作］

背景技術で説明したように、〜０２０出願は、仮想ネットワークを実装および管理するコンピューティングシステムを提供し、ソフトウェアデファインドネットワークのソリューションを提供し得る。具体的には、ネットワーク仮想化のためのソフトウェア抽象化層が提供されることで、クラウドコンピューティングシステムの効果を改善しながら、物理ネットワークの複雑性、および、関連する保守費用を低減する。〜０２０出願で開示されているコンピューティングシステムおよび関連する方法は、本明細書に開示されている１つまたは複数の態様の基礎となる汎用システムアーキテクチャおよび動作を説明している。

汎用システムアーキテクチャの一例によると、パケットは、下位ネットワーク（例えば、仮想ネットワークがオーバーレイするネットワーク）の第１ノードの第１ネットワークインタフェースに到達し得る。第１ネットワークインタフェースは、第１ノード上のハードウェアまたはソフトウェア内に実装され得る。パケットをどのように取り扱うか判定するべく、判定エンジンが起動され得る。一態様において、パケットと、パケットがネットワーク内に到達したときに通ったネットワークインタフェースの識別情報とは、処理を受けるべく、判定エンジンへ伝達される。判定エンジンは、パケットが遭遇する複数の仮想ネットワークデバイスの各々を含む、仮想ネットワークの仮想ネットワークトポロジを、パケットがどのように通過するかシミュレートし得る。パケットが仮想ネットワークを通して１つのデバイスから次のデバイスへどのように通過するかシミュレートすることに加え、判定エンジンはまた、遭遇した仮想デバイスの各々は、例えばパケットプロトコルヘッダを修正することによってパケットにどのような影響を及ぼすかシミュレートし得る。下位ネットワークのノードの１つにあるネットワークインタフェースからパケットが送出され得るように、シミュレーション結果に基づいて、判定された修正、または、修正の集合の各々を適用することによってパケットは処理される。パケットを送出するための特定のネットワークインタフェースは、判定エンジンによってシミュレーション中に判定されたものである。

仮想ネットワークトポロジを通る各段階において、判定エンジンは、一連のデバイスによってパケットがどのように取り扱われ得るか判定する。一例において、判定エンジンは、パケットがドロップされるものか、無視されるものか判定し得る。特定のパケットが、もはや処理されていない通信またはフローに関連している場合、パケットのドロップが生じ得る。また、パケットは、受信した種類のパケットを取り扱うための十分な命令が仮想デバイスに無いという理由でドロップされ得る。あるいは、デバイスは、特定のパケットを指定された送信先へ良好にルーティングできないことがある。パケットが送信先へ到達しなかったことをパケットの送信者へ通報するべく、エラーメッセージ、または、他の応答が提供され得る。

判定エンジンは、多くのパケットについて、パケットが第２ネットワークインタフェースに対応する仮想ポートから送出される必要があることを判定する。パケットの送信先、および、仮想ポートとホストとの間のマッピングに応じて、第２ネットワークインタフェースは、下位ネットワークの第１ノード上、または、第２の異なるノード上に存在し得る。パケットが第２ノード上の第２ネットワークインタフェースに配信されるとき、判定エンジンは、パケットがどのように処理されるか判定する。そ次にパケットは、第２ネットワークインタフェースによって送出されるべく、下位ネットワークによって第２ノードへ配信される。例えば、パケットのプロトコルヘッダは、第２ネットワークインタフェースへ配信される前に修正され得る。プロトコルヘッダの修正は、ネットワークアドレス変換、トンネリング、ＶＰＮ、および／または、他の機能を提供し得る。

下位ネットワーク上のノードのノードアドレスに対するノード識別子のマッピングが維持される。下位ネットワーク上でパケットをルーティングする目的で、個別ノードを区別するのにノード識別子が使用され得る。第１ノードから第２ノードへパケットを配信するべく、パケットはトンネリングプロトコルパケット（Ｅｔｈｅｒｎｅｔ＋ＩＰ＋ＧＲＥ（登録商標）など）のペイロードとして転送され得る。トンネリングプロトコルパケットは、第２ネットワークインタフェースのグローバル識別子を符号化するトンネルキーを有する。各ネットワークインタフェースを一意に識別できるように、グローバル識別子はネットワーク内で一意である。対照的に、ローカル識別子は、ネットワークのサブセット内のポートまたはインタフェースを一意に識別するべく、ノード内、または、ネットワークのサブセット内で使用され得る。トンネリングプロトコルパケットが第２ノードで受信されるとき、元のパケットを含むペイロードがトンネルキーと共に抽出される。次に、第２仮想ネットワークインタフェース識別子、および、第２ネットワークインタフェースから送出されるパケットを判定するべく、トンネルキーが復号され得る。このように、判定エンジンは、パケットが仮想ネットワークを通過するときにどのように取り扱われるか判定でき、判定後、下位ネットワークはパケットを効率的に伝送できる。

また、判定エンジンは、パケットがネットワークインタフェースの組から送出される必要があることを判定できる。マルチキャストまたはブロードキャストの用途においては、ネットワークインタフェースの組からの送出が必要となり得る。パケットの送出元となる必要のあるネットワークインタフェースは、ネットワークの単一ノードについてローカルであり得るか、または、２つ、もしくは、より多くのノードにわたって分散され得る。いずれの場合も、パケットは、インタフェースセット識別子に対応するネットワークインタフェースの組から送出される必要がある。次に、第１ノードについてローカルな組における各ネットワークインタフェースへパケットを配信することで、パケットが処理される。また、パケットは、トンネル経由で、第１ノードから第２ノードへ、修正して転送される。パケットは、インタフェースセット識別子を符号化するトンネルキーを使用して、トンネリングプロトコルパケットのペイロードとして転送され得る。トンネリングパケットが第２ノードで受信されると、インタフェースセット識別子と、第２ノードについてローカルな組に含まれるネットワークインタフェース上で送出されるパケットとを判定するべく、トンネルキーが復号化され得る。特定のインタフェースセット識別子に関連するネットワークインタフェースの組は、各ノードがアクセス可能な共有データベース内に記憶され得る。したがって、ノードが未知のインタフェースセット識別子を受信する場合、ノードは、識別された組の中にどのネットワークインタフェースが含まれているか判定するべく、共有データベースにアクセスし得る。更に、ノードは、インタフェースセット識別子に対するネットワークインタフェースのマッピングを、ノード上でローカルに記憶またはキャッシュし得る。しかしながら、インタフェースセット識別子が変化するとき、ローカルにキャッシュされたデータは無効となり、ノードは、インタフェースセットに対するインタフェースの現在または更新されたマッピングを読み出すべく、共有データベースにアクセスし得る。仮想ネットワークインタフェースは、１つより多くのインタフェースセットに属し得る。

別の態様において、判定エンジンは、仮想ネットワークトポロジを通過する特定のパケットのシミュレーションに基づいて、そのパケットをどのように取り扱うか判定する。多くの用途において、複数のパケットは、フローとして関連付けられ、フロー内の各パケットは、同一の方式で処理される。例えば、ＴＣＰ接続の一方向のすべてのパケットは、同一の方式で処理される必要がある。フローの第１パケットを受信すると、判定エンジンは、フローのパケットをどのように取り扱うか判定する。判定エンジンは次に、フローの後続パケットを取り扱うためのアクションまたはルールを記憶し得る。記憶されたアクションまたはルールは、共有データベース内に記憶され得る。当該ルールは、特定のフローのパケットを取り扱うべく、すべてのノードが利用可能である。代替的に、ルールはローカルに記憶され得る。

判定エンジンの出力は、第１パケットの場合と判定エンジンの出力が同一である他のパケットとマッチするのに使用され得るパケットプロトコルヘッダパターンを含み得る。すなわち、パケットプロトコルヘッダパターンは、第１パケットについて判定されたアクションまたはルールを適用することにより同一の方式で処理されるパケットを識別するのに使用され得る。判定エンジンの出力は、パケットをどのように処理するか判定するべく実行されるシミュレーションの結果である。パケットプロトコルヘッダパターン、および、第１パケットのシミュレーションの結果が記憶される。第２パケットを受信すると、ＴＣＰのシーケンス番号など、パケットごとに変化するフィールドを無視しながら、第２パケットのヘッダがパケットプロトコルヘッダパターンと比較される。第２パケットがパターンにマッチする場合、第２パケットが同一のフローの一部と見なされ、以前に記憶された、第１パケットについてのシミュレーションの結果が読み出されて第２パケットに適用される。記憶されているシミュレーション結果は、共有データベースか、ローカルキャッシュか、または、フローのパケットに適用されるルールを保持するのに適切な任意の他のメモリから読み出され得る。判定エンジンは、フロー内の第２および後続パケットに対するルールをフローに適用し得る。しかしながら、システムの速度または効率性を改善するべく、フローのルールを判定するための、第１パケットに関連するシミュレーション、および、それらのルールのパケットへの適用は、分離され得る。

特定のシミュレーション結果のキャッシュまたは記憶は、システムによって判定され得る。例えば、判定エンジンは、どのシミュレーション結果がキャッシュされる必要があるか示唆し得る。この文脈において、示唆は、効率性または利用可能なストレージ容量など、他の考慮事項に応じて特定の結果を記憶するという推奨を含み得る。一例において、システムは、頻繁に使用されないフローのシミュレーション結果を記憶しないことを選択し得る。また、判定エンジンは、どの成果またはシミュレーション結果が実際にキャッシュされているか、または、キャッシュされた結果から、どの結果が無効化もしくは排除されたかについて、通知され得る。キャッシュされた結果は、各種理由から、無効となり得る。一例において、新しいフロー、または、より頻繁に使用されるフローのためのストレージ空間を開放するべく、成果が排除され得る。記憶されているフロールールの数が増加するにつれて、システムの性能が低下し得る。したがって、いくつかの実施形態において、効率性および動作速度を増大させるべく、記憶されるフロールールの数は制限され得る。

仮想ネットワークトポロジおよび／または仮想デバイスの構成は、時間の経過に伴って変化し得る。そのため、以前に実行されたシミュレーション結果は、以前に確立された１つまたは複数のフローの後続パケットに適用される適切なルールを反映しなくなることがある。したがって、システムは、キャッシュされたシミュレーション結果の変化を検出して応答するべく、共有データベース、判定エンジン、および、他のコンポーネントの間で通信し得る。一例において、判定エンジンは、共有データベース内に記憶されたグローバル状態に反映された構成の変化に基づいて、キャッシュされた特定のエントリを除去するように、いつでも命令し得る。キャッシュされたエントリが除去される場合、除去されたフローに対応する次のパケットを受信すると、判定エンジンが起動され、フローのパケットをどのように処理するか判定するべく、シミュレーションが再計算される。再検討されたシミュレーション結果は、その後、記憶され得て、フローに関連するパケットプロトコルヘッダパターンとマッチする後続パケットに適用されることもできるであろう。

システムは、パケットのシミュレーション中に、特定のフローのパケットプロトコルヘッダパターンを判定し得る。パケットは、複数のフィールドを含むプロトコルヘッダを有し得る。パターンは、判定エンジンにより、シミュレーション中に読み込まれるフィールドの各々を識別することによって判定される。このように、仮想ネットワークトポロジがスキャンされるときに読み込まれる各フィールドが識別される。これには、複数の仮想ネットワークデバイスによって読み込まれるフィールドが含まれる。読み込まれる各フィールドは、パターンの一部として含まれ得る。対照的に、読み込まれず、したがって、パケットの取り扱いに影響しないフィールドは、ワイルドカードとして指定され得る。

別の例において、第１パケットは、下位ネットワークの第２ノード上で受信され、第２ノードは、第１パケットと同一のトンネルキーを有する他のパケットを識別するのに使用され得るプロトコルヘッダパターンを生成する。次に、第２ノードはプロトコルヘッダパターンを使用して、パケットプロトコルヘッダパターンにマッチする第２パケットを識別する。そして、第１パケットがそこから送出されたのと同一のローカルネットワークインタフェースから第２（および後続の）パケットを送出する。このように、第２ノードは、どのポート上で第２パケットを送出するか判定するプロセスを合理化し、システムの効率性を改善する。ノード上のフロープログラマブルスイッチは、第１パケットと同様に処理される後続パケットを識別するべく、プロトコルヘッダパターンをトンネルキーと組み合わせて利用し得るか、または、トンネルキーのみを利用し得る。

判定エンジンは、第１パケットのシミュレーションを判定しながら、ベースシステムに対し、ネットワークインタフェースまたはネットワークインタフェースの組から、１つまたは複数の追加パケットを生成するように要求し得る。ネットワークのポートの挙動を判定するべく、追加パケットが要求され得る。追加パケットを要求することで、判定エンジンは、シミュレーションプロセスにおいて役立つ、ネットワークの部分に関する追加情報を取得し得る。追加パケットの各々は実質的に、本明細書に記載されたように処理され得るか、または、判定エンジンがネットワークに関する必要な情報を構築できるように、必要に応じて、異なる処理を提供され得る。

本明細書に開示されているシステムアーキテクチャは、複数のノードを有する下位ネットワークからアクセス可能な共有データベースを含み得る。共有データベースは、複数の仮想ネットワークデバイスのための仮想ネットワークトポロジおよび仮想デバイス構成を記憶する。ネットワークパケットは、下位ネットワークの第１ノードの第１ネットワークインタフェースに到達する。複数の仮想ネットワークデバイスを含む仮想ネットワークトポロジをパケットがどのように通過するかについてのシミュレーションに基づいて、ネットワークパケットを処理するためのアクションが判定される。アクションは、下位ネットワークのノードで受信されたパケットを処理するべく、フロープログラマブルスイッチで動作可能なフロールールである。

本明細書に記載された判定エンジンは、パケットが仮想ネットワークトポロジをどのように通過するかシミュレートする。判定エンジンは、各ノード上で受信されたパケットについて、シミュレーションを実行するべく、複数のノードの各々で動作可能であり得る。代替的に、判定エンジンは、シミュレーションが発生するパケットを受信するノードの各々と通信する別個のノード上で動作し得る。

仮想ネットワークトポロジは、複数の仮想ネットワークデバイスに対応する複数の仮想ポートを含む。各仮想ネットワークデバイスは、１つまたは複数の仮想ポートを含む。仮想ポートは、下位ネットワークのノードのネットワークインタフェースに関連する外向きポート、または、仮想ネットワークデバイスの間の仮想リンクに関連する内向きポートのいずれかであり得る。仮想リンクは、別の仮想ポートに対する、１つの仮想ポートの論理的接続を表し、仮想ケーブルとも呼ばれ得る。

共有データベースは、仮想ポートの構成を含む、仮想ネットワークトポロジおよび仮想デバイス構成を記憶する。共有データベースは、複数の仮想ポートの各々について、１つまたは複数の構成を含む。これには、外向きポートまたは内向きポートの１つとしての仮想ポートの識別情報と、複数の仮想ポートに関連する複数の仮想ネットワークデバイスの各々の構成と、下位ネットワークノードの識別子に対するネットワークインタフェース識別子のマッピングと、下位ネットワークノードの対応するネットワークインタフェースに対する外向きポートの双方向マッピングと、仮想リンクによって接続される別のデバイスのピア内向きポートに対する各デバイスの各内向きポートのマッピングとが含まれ得る。本明細書において使用される、ピア内向きポートとは、論理的接続によって特定の仮想ポートに接続された仮想ポートである。内向きポートは、単一のピアを有し、したがって、各内向き仮想ポートは、接続される内向き仮想ポートのピアである。

仮想ポートは、仮想ネットワークの所望の編成に応じて構成可能であり、ユーザはそれに応じて仮想ポートを定義し得る。外向き仮想ポートに出入りするパケットは、仮想ネットワークに出入りする。対照的に、内向き仮想ポートに出入りするパケットは、仮想ネットワーク内に留まる。このように、パケットがポートを通過するとき、仮想ネットワークに入るか、または仮想ネットワークから出るかに応じて、仮想ポートは、外向きまたは内向きの特徴を有し得る。

例において、判定エンジンは、第１ノード上でローカルに動作し、仮想ネットワークトポロジおよびデバイス構成を含む共有データベースと通信する。共有データベースは、トポロジおよびデバイス構成の情報の正式のコピー、またはマスターコピーを含み得る。効率性を改善するべく、仮想ネットワークトポロジおよび仮想デバイス構成の情報の少なくとも一部は、個別ノード上でローカルにキャッシュされ得る。キャッシュされたデータは、共有データベースが修正されるときに更新され得る。一実施形態において、特定のノードによって使用されるトポロジまたはデバイス構成の一部のみがノード上でキャッシュされる。システムは、仮想デバイスに到達するパケットのシミュレーションに基づいて、共有データベースから、シミュレーションを実行するノードへ、仮想デバイスの構成をロードし得て、後に使用するためのデバイス構成をノード上にキャッシュし得る。

第１ノードの第１ネットワークインタフェースは、対応する仮想ポートにマッピングされ得る。仮想ポートおよび仮想ポートに関連するデバイスの構成は、共有データベースから読み出され得る。次に、仮想ポートに関連するデバイスのシミュレーションに基づいて、ネットワークパケットを処理するためのアクションが判定される。判定されたアクションには、ネットワークデバイスの内部状態の修正と、パケットのドロップと、パケットのプロトコルヘッダの修正と、ネットワークデバイスの１つまたは複数の仮想ポートからのパケットの送出と、ネットワークデバイスの１つまたは複数の仮想ポートからの異なるパケットの送出とのうち、１つまたは複数が含まれ得る。ネットワークデバイスの１つまたは複数の仮想ポートからパケットを送出するとき、パケットは、外向きポートまたは内向きポートから送出され得る。

パケットをどのように処理するか判定するとき、判定エンジンは、内向き仮想ポートによって接続された複数の仮想デバイスをスキャンし得る。判定エンジンは、第２仮想ポートのピア内向きポートを判定し、ピア内向きポート、および、ピア内向きポートが位置するネットワークデバイスの構成を読み出す。次に、判定エンジンは、ピア内向きポートに関連するネットワークデバイスの動作をシミュレートし得て、パケットがどのように処理されるか判定し得る。このように、判定エンジンは、特定のパケットまたはフローがどのように処理されるか判定するべく、任意の数の仮想ネットワークデバイスを含む仮想ネットワークトポロジを通るルーティングをシミュレートし得る。

本明細書に記載されているシミュレーション処理は、パケットに通過される最後の仮想デバイスを判定エンジンがシミュレートするまで繰り返される。判定エンジンは、そのパケットと、パケットプロトコルヘッダパターンにマッチする後続パケットに適用されるシミュレーション結果またはアクションを提供する。シミュレーション結果またはアクションは、仮想ネットワークトポロジのスキャンを通して適用されるすべての修正に基づいて、パケットが最後の仮想デバイスによって送出されるようにするためのヘッダの構成にマッチするようにパケットのプロトコルヘッダを修正するための、パケットの修正の集合を含む。このように、判定エンジンはシミュレーションを通して、パケットに対する必要な修正を判定し、それにより、パケットが効率的に修正され、ネットワークを通してルーティングされ得る。

上述したように、パケットは、複数のフィールドを含むプロトコルヘッダを有する。システムは、シミュレーション結果に基づいて判定されたアクションまたはフロールールが適用されるパケットを識別するのに使用するパケットプロトコルヘッダパターンを判定する。システムは、仮想ネットワークトポロジおよび仮想ネットワークデバイスのシミュレーション中に読み込まれたプロトコルヘッダのフィールドの各々を識別することによって、パケットプロトコルヘッダパターンを判定する。このように、名前方式で処理される必要のあるパケットに判定されたフロールールが適用され得るように、ネットワークを通過するときに利用されるプロトコルヘッダのフィールドが識別される。利用されないプロトコルヘッダのフィールドは、後続パケットのプロトコルヘッダを判定されたパターンにマッチさせるプロセスにおいて、ワイルドカードとして処理されるか、そうでなければ、考慮から除外され得る。パケットプロトコルヘッダパターン、および対応するシミュレーション結果は、ノード上に記憶され得る。パターンおよび対応するシミュレーション結果は、ノードに到達する後続パケットを処理するべく構成されたフロー構成可能スイッチ内で使用するためのフロールールとして記憶される。フロールールが作成されていないノードにパケットが到達するとき、判定エンジンが起動され、パケットのシミュレーションを実行する。

判定エンジンによって生成されたシミュレーション結果は、仮想ネットワークトポロジ、および、シミュレーション中にスキャンされた仮想デバイスの仮想デバイス構成に依存し得る。トポロジまたはデバイス構成が変更されるとき、以前に判定された、パケットに適用されるシミュレーション結果および対応するアクションは、正確でなくなることがある。そのような変更に対応するべく、システムは、仮想ネットワークトポロジまたは仮想デバイス構成が変更されたときに、記憶されているパケットプロトコルヘッダパターン、および、対応する記憶されているシミュレーション結果を無効化するように構成されている。システムは、変更を検出すると、記憶されているパターンおよびシミュレーション結果をすべて無効化する。他の例において、変更された仮想デバイスに依存する、記憶されている結果のみが無効化される。例えば、シミュレーション中にスキャンされた仮想デバイスの組は、判定エンジンによるシミュレーション中に判定される。次に、スキャンされた仮想デバイスの組は、パケットプロトコルヘッダおよび／またはシミュレーション結果に関連付けられる。仮想デバイスの構成の変更が検出されると、変更された仮想デバイスを含む、スキャンされたあらゆる組に関連する、記憶されたシミュレーション結果が無効化され得る。このように、システムは特定の仮想デバイスの変更に基づいて、どのフロールールを無効化する必要があるか、効率的に判定する。

他の例によると、キャッシュが空間的に制限されたリソースである場合、フローは無効化または排除され得る。例えば、システムはローカルで（第１ノード上で）、下位システムによってキャッシュされたすべての判定エンジンをトラッキングし得、パケットが最後にパターンにマッチして関連するアクションが適用されたときである、判定の「最終マッチ」時間をトラッキングする。次に、システムはすべての判定の最終マッチ時間を問い合わせ得て、もっとも長い時間にわたって使用されなかった判定を排除する。最終マッチ時間の問い合わせは、指定の頻度で実行され得るか、または、記憶された判定のキャッシュのサイズを指定されたサイズより小さい状態で維持するのに必要な場合に実行され得る。また、システムは、「最近」作成されたランダムな判定を削除し得る。最近作成されたランダムの判定を除去することは、最近の判定の大部分が、短期間のパケットフローのものである場合に（比較的高い割合の長期間フローを有する、より古くから存続している判定と比較して）効率的であり得る。フローを無効化する処理は、ノード上に記憶されているデータのキャッシュを所望のパラメータ内で管理するべく、個別に使用され得るか、または、組み合わせて使用され得る。また、システムは、記憶されたキャッシュへの新たな判定の追加に関連する、判定エンジンの新たな起動の割合に基づいて、無効化または排除の割合を調節し得る。

動作中、本明細書に記載されている汎用システムアーキテクチャは、仮想デバイスの入口および出口フィルタのシミュレートを含む方法を実行するように構成されている。このフィルタは、ジャンプルールを介して互いに参照し得るリストに編成された個別のフィルタリングルールを含む。また、方法は、論理を読み込んで、パケットのＬ２〜Ｌ４ネットワークプロトコルヘッダの任意またはすべてのフィールドに適用し得る条件を指定する段階、および、パケットがその条件にマッチするときに実行されるアクション（例えば、ＤＲＯＰ、更なる処理のためのＡＣＣＥＰＴなど）を指定する段階を含み得る。

この方法は更に、各デバイスの入口／出口フィルタのフィルタリングルールを共有データベース内に維持する段階、デバイスのフィルタリングルールのローカルコピーを、デバイスを最近シミュレートした任意のノード上に維持する段階、共有データベース内でルールの正式のコピーが変更されたときにデバイスのフィルタリングルールのローカルコピーを更新する段階、および／または、デバイスのフィルタが修正されたときに、デバイスのシミュレーションを必要とする、ローカルにキャッシュされたフローの転送判定を再認証する段階を含む。また、方法は、フローごとの接続状態についてマッチするフィルタリングルールをシミュレートする段階を含み得て、フローごとの接続状態は、各シミュレートされたデバイスによって別個にトラッキングされ、接続状態の値の組は、パケットのトランスポート（Ｌ４）プロトコルに依存する。

更に、汎用システムアーキテクチャは、デバイスおよびフローごとの接続状態を記憶するための専用空間を中央データベース内に有すること、および、デバイスのシミュレーションが開始されるときに、接続状態を読み出すべくパケットのフロー署名を使用して中央データベースに問い合わせることを含む方法を実行するように構成されている。フロー署名は、シミュレートされたデバイスのデバイスＩＤ、パケットのＬ３ヘッダの（例えばＩＰ）送信元フィールド、Ｌ３送信先フィールド、Ｌ４プロトコルタイプ（例えばＴＣＰ）、Ｌ４ヘッダの送信元フィールド、Ｌ４ヘッダ送信先フィールドの順序でこれらのフィールドを付属することで計算される。中央データベース内にいかなる接続状態も見つからない場合、パケットは新しいフローを構成し、その接続状態は黙示的に、このパケットのネットワークプロトコルの状態の組の「開始」値である。また、方法は、このデバイスのフィルタリングルールによるマッチを行うべく接続状態値を公開し得る。デバイスのシミュレーションを終了する前に、デバイスがパケットを転送することをシミュレーションが判定した場合、このパケットのネットワークプロトコルの接続状態値の組の遷移ルールに従って、このパケットのフロー署名およびこのパケットのリターンフロー署名のための接続状態が設定される。同様に、パケットのリターンフロー署名は、これらの値を、シミュレートされたデバイスのデバイスＩＤ、パケットのＬ３ヘッダの送信先フィールド、Ｌ３送信元フィールド、Ｌ４プロトコルタイプ、Ｌ４ヘッダ送信先フィールド、Ｌ４ヘッダ送信元フィールドの順序で付属することによって計算される。また、フォワードフロー署名およびリターンフロー署名は、特定の用途で役立ち得る追加フィールドを使用して定義され得る。フォワードフローのためのキャッシュされた判定が失効したとき、システムは、そのフローおよびリターンフローの両方に関連する接続状態の除去をスケジュールし得る。

この方法は更に、パケットのフローの接続状態についてマッチするフィルタリングルールをシミュレートする段階を含む。ここで、フローごとの接続状態は、シミュレートされたデバイスすべての間で共有され、接続状態の組は、パケットのトランスポート（Ｌ４）プロトコルに依存する。このように、接続状態は、デバイスのネットワークを通る経路と無関係な、フローの特性として見なされる。この結果、判定エンジンへの単一の呼び出し内でシミュレートされたすべてのデバイスは、パケットのフローおよびリターンフローの接続状態について一致する。判定エンジンへの２つの異なる呼び出し内でシミュレートされた任意の２つのデバイスは、リターンフローが、フォワードフローが送出されたのと同一のデバイスで仮想ネットワークに入ること、および、リターンフローパケットがパブリック（すなわち、グローバルで一意）のＬ３アドレスを有することのうち、少なくとも１つが真である場合に、それらの接続状態について一致する。実施形態において、共有データベースは、フローごとの接続状態を記憶するための専用空間を含む。仮想ネットワークを通過するパケットのシミュレーションが開始すると、共有データベースは、パケットのフロー署名を使用して問い合わせを受け得る。Ｌ３送信元／送信先の少なくとも１つがパブリック（すなわち、グローバルで一意）でない場合、フロー署名は、第１のシミュレートされたデバイスのデバイスＩＤに依存し得る。また、フロー署名は、パケットのＬ３ヘッダの（例えばＩＰ）送信元フィールド、Ｌ３送信先フィールド、Ｌ４プロトコルタイプ（例えばＴＣＰ）、Ｌ４ヘッダの送信元フィールド、Ｌ４ヘッダ送信先フィールドに依存し得る。中央データベース内にいかなる接続状態も見つからない場合、パケットは新しいフローを構成し、その接続状態は黙示的に、このパケットのネットワークプロトコルの状態の組の開始値である。次に、任意のシミュレートされたデバイスのフィルタリングルールによるマッチのための接続状態値が公開され得る。仮想ネットワークを通過するパケットのシミュレーションが終了する前に、パケットが最終的にいくつかの仮想ポートから送出されるとシミュレーションが判定した場合、このパケットのネットワークプロトコルの接続状態値の組の遷移ルールに従って、このパケットのフロー署名およびこのパケットのリターンフロー署名のための接続状態が設定される。共有データベースへの接続状態の書き込みが完了する前に、リターンフローからのパケットがシミュレートされ、接続状態への問い合わせを始動する競合状態を回避するべく、パケットがトンネリング／転送される前に（したがって、判定を返す前に）、接続状態は共有データベースに書き込まれる。パケットのリターンフロー署名は、同様の方式で計算され得る。上述のように、フォワードフローのためのキャッシュされた判定が失効したとき、システムは、そのフローおよびリターンフローの両方に関連する接続状態の除去をスケジュールし得る。

別の態様において、方法は、いくつかのシミュレートされたデバイスにおけるフィルタリングルールがそのような状態を読み込む必要があるまで、パケットのフローの接続状態の問い合わせを遅らせることで、この状態がパケットのシミュレーションまたはリターンパケットのシミュレーションによって使用されない場合に、接続状態の問い合わせまたは書き込みを回避することでシミュレーション時間を低減する段階、リターンパケットのあり得る経路が、リターンフローの接続状態の読み込みを必要とするフィルタリングルールのシミュレートを含むかどうか判定する段階、および、含まないと判定した場合に、フォワードフローおよびリターンフローの接続状態の両方を共有データベースに書き込むことを省略する段階を含む。同一のフローからの任意のパケットが後に第２ノードのインタフェースに到達した場合に、第２ノードの判定エンジンが、（仮想ネットワーク構成変更が無い状態で）フローをどのように処理するかについて同一の判定に到達するように、接続状態が共有データベース内に保持される。これは、外部のルーティング判定により、下位ネットワークの１つより多くのノードのインタフェースにパケットが到達するとき、フローの完全性を保護するのに必要である。それらのルーティング判定は、ノードのインタフェースの認識された、または実際の非到達性に関連することも、関連しないこともある。

汎用システムアーキテクチャは更に、仮想デバイスのネットワーク（すなわちＬ３）およびトランスポート（すなわちＬ４）アドレス変換のシミュレーションを実行するように構成される。同様に、仮想デバイスのネットワークおよびプロトコルアドレスの逆変換もシミュレートされ得る。これらの動作は、「ネットワークアドレス変換」（ＮＡＴ）と総称され得る。例によれば、個別のＮＡＴルールは、フィルタリングルールに従う、もしくは優先する、または、フィルタリングルールが組み入れられ、論理を読み込んでパケットのＬ２〜Ｌ４ネットワークプロトコルヘッダの任意もしくはすべてのフィールドに適用し得る条件を指定し、パケットが条件にマッチしたときにＬ３およびＬ４フィールドがどのように変換もしくは逆変換される必要があるか指定し、および／または、変換が発生したときに実行されるアクション（例えば、デバイスによる更なる処理のためのＡＣＣＥＰＴ、ルールセット内の処理のためのＣＯＮＴＩＮＵＥ）を指定し得る。各デバイスの入口／出口フィルタの変換ルールは、共有データベース内で維持され、デバイスを最近シミュレートした任意のノード上にローカルでコピーされ得る。共有データベース内でルールの正式のコピーが変更されたとき、ローカルコピーは更新され得る。

デバイスのシミュレーション中、パケット処理がＮＡＴルールに到達した場合、（おそらく既に以前のデバイスまたはルールによって修正された）パケットがルールの条件を満たしているかどうか判定される。満たしていると判定された場合、パケットは、ルールによって指定された変換または逆変換に従って修正される。デバイスのシミュレーションを必要とする、ローカルでキャッシュされたフロー転送判定は、デバイスの変換が修正されるときに、再認証され得る。

汎用システムアーキテクチャは更に、ステートフル送信先ＮＡＴをサポートする物理的分散型仮想デバイスを実装する。いくつかのＮＡＴルールは、Ｌ３およびＬ４の送信先アドレスのための変換ターゲットを選択することを可能にし、変換ターゲットの間で選択するためのポリシーを指定する。システムは、フォワードフローおよびリターンフロー署名の両方をキーとして、各フォワードフローのための変換選択を共有データベース内に記憶し得る。フォワードフロー署名は、仮想デバイスのＩＤ、パケットのＬ３送信元アドレス、Ｌ３送信先アドレス、Ｌ４プロトコル番号、Ｌ４送信元アドレス、Ｌ４送信先アドレスの順序でこれらの値を含み得る。リターンフロー署名は、仮想デバイスのＩＤ、変換によって選択されたＬ３アドレス、パケットのＬ３送信元アドレス、Ｌ４プロトコル番号、変換によって選択されたＬ４アドレス、パケットのＬ４送信元アドレスの順序で、これらの値を含み得る。記憶された変換は、パケットの元のＬ３およびＬ４送信先アドレス、ならびに、変換するために選択されたＬ３およびＬ４送信先アドレスを符号化し得る。デバイスのシミュレーション中、パケット処理がそのような（送信先アドレスの選択を可能にする）ＮＡＴルールに到達し、ルールの条件を満たす場合、フォワードフロー署名のための上述のキーが生成され、以前の判定エンジンの実行によって（ローカルで、または、いくつかのリモート下位ネットワークノードで）、変換が既に記憶された（したがって、変換されたアドレスの選択が既に行われた）かどうか判定するべく共有データベースが問い合わせを受ける。そのような記憶された変換が共有データベース内に見つかる場合、パケットのＬ３およびＬ４送信先アドレスは、選択されたＬ３およびＬ４アドレスへ修正される。そのような記憶された変換が共有データベース内に見つからない場合、指定されたポリシーに従って選択が行われ、その選択に従ってパケットのＬ３およびＬ４送信先アドレスが修正され、変換選択が共有データベース内に記憶される。

デバイスのシミュレーション中、パケット処理が、選択の反転を指定する逆変換ルールに到達し、そのパケットがルールの条件を満たす場合、そのパケットは変換されたフォワードフローのリターンパケットであると仮定して、リターンフロー署名に対応するキーが生成される。そのリターンフローについて、変換が記憶されたかどうか判定するべく、共有データベースが問い合わせを受ける。リターンフロー署名は、仮想デバイスのＩＤ、パケットのＬ３送信元アドレス、Ｌ３送信先アドレス、Ｌ４プロトコル番号、Ｌ４送信先アドレス、Ｌ４送信元アドレスの順序で、これらの値を含み得る。そのような記憶された変換がデータベース内で見つかる場合、パケットのＬ３およびＬ４送信元アドレスを、記憶された変換の元のＬ３およびＬ４アドレスへ修正することによって、変換が逆方向にパケットへ適用される。そのような記憶された変換が共有データベース内に見つからない場合、パケットが変換されたフォワードフローのリターンパケットであるという仮定は不正確なので、逆変換を適用する必要はない。シミュレーションは、逆のルールの条件が満たされていないかのように継続する。このように、仮想デバイスが、正確に機能しているハードウェアデバイスと見分けがつかないように正確に挙動するように、システムは変換を共有データベース内に記憶し、競合状態に対処する。しかしながら、ハードウェアデバイスと比較して、仮想デバイスは利用可能性が高い。

同様に、いくつかのＮＡＴルールは、Ｌ３およびＬ４送信元アドレスのための変換ターゲットの選択を可能にし、選択するためのポリシーを指定する。システムは、フォワードフローおよびリターンフロー署名の両方をキーとして、各フォワードフローのための変換選択を共有データベース内に記憶し得る。記憶された変換は、パケットの元のＬ３およびＬ４送信元アドレス、ならびに、変換するために選択されたＬ３およびＬ４送信元アドレスを符号化し得る。デバイスのシミュレーション中、パケット処理がそのような（送信元アドレスの選択を可能にする）ＮＡＴルールに到達し、ルールの条件を満たす場合、フォワードフロー署名の上述のキーが生成され、以前の判定エンジンの実行によって（ローカルで、または、いくつかのリモート下位ネットワークノードで）、変換が既に記憶された（したがって、変換されたアドレスの選択が既に行われた）かどうか判定するべく共有データベースが問い合わせを受ける。そのような記憶された変換が共有データベース内で見つかる場合、パケットのＬ３およびＬ４送信元アドレスは、選択されたＬ３およびＬ４アドレスへ修正される。そのような記憶された変換が共有データベース内に見つからない場合、指定されたポリシーに従って選択が行われ、その選択に従ってリターンフロー署名が構築され、そのキーによって、いかなる変換も記憶されていないことを確認するべくデータベースが問い合わせを受ける。データベースがそのキーについてノーマッチを返すまで、選択およびデータベースチェックが繰り返される。パケットのＬ３およびＬ４送信元フィールドは、最終選択に従って修正され、最終変換選択は共有データベース内に記憶され、シミュレーションが継続する。正確性のため、および、リターンフローのルーティングにおける曖昧性を回避するべく、データベース内のリターンフローキーのチェックが使用され得る。

デバイスのシミュレーション中、パケット処理が、選択の反転を指定する逆変換ルールに到達し、そのパケットがルールの条件を満たす場合、そのパケットは、変換されたフォワードフローのリターンパケットであると仮定して、リターンフロー署名に対応するキーが生成され、共有データベースは、そのリターンフローについて、変換が記憶されたかどうか判定するための問い合わせを受ける。そのような記憶された変換がデータベース内で見つかる場合、パケットのＬ３およびＬ４送信先アドレスを、記憶された変換の元のＬ３およびＬ４アドレスへ修正することによって、記憶された変換はこのパケットへ逆方向に適用され、シミュレーションが継続する。記憶された変換が共有データベース内に見つからない場合、パケットが変換されたフォワードフローのリターンパケットであるという仮定は不正確なので、逆変換を適用する必要はなく、したがって、逆のルールの条件が満たされていないかのようにシミュレーションが継続し得る。

更に別の態様において、Ｌ３およびＬ４アドレス範囲を、個別ノードによって確保され得るブロックへ分割することによって、既にデータベース内にあるＬ３およびＬ４アドレス変換を選択する試行の回数が低減され得る。変換のためのＬ３およびＬ４アドレスを選択するとき、ノードは、未使用のアドレスの組み合わせが自身のブロック内に存在するかどうかローカルでチェックし、そうでなければ、新しいブロックを確保する。多くの場合、これは、データベースへの一往復の通信を発生させる。ノードが新しいブロックを確保できず、新しい変換に利用可能な未使用のＬ３およびＬ４アドレスの組み合わせが無い場合、ルールによって指定された制限の範囲内で、ランダムなＬ３およびＬ４アドレスの組み合わせを使用することを試みる。

本明細書に記載されている汎用システムアーキテクチャは、下位ネットワーク上にオーバーレイされる仮想ネットワークを使用するパケットルーティングを可能にする。下位ネットワークは物理ネットワークであるが、他の実施形態によると、下位ネットワークは仮想または論理ネットワークであり得る。下位ネットワークは、物理ネットワークの観点で記載され得るが、１つまたは複数の仮想ネットワークが別の上に重ねられ得て、各々、次にオーバーレイされている仮想ネットワークのための下位ネットワークを提供し得る。

汎用システムアーキテクチャには、複数のノードを相互接続するネットワークが含まれる。ネットワークのノードは、サーバ、ルータ、または、ネットワークと通信する他のコンピューティングデバイスなど、物理コンポーネントに対応し得る。各デバイスは、１つまたは複数のノードをサポートし得る。ノードは、論理または仮想デバイスを表し得る。ネットワークは、サービスプロバイダによって維持されるプライベートネットワークであり得る。サービスプロバイダは、複数のテナントに対して、ネットワーク機能を販売、リース、または、そうでなければ、提供する。ネットワークは、パブリックネットワークへの接続性を提供する、エッジノードなど、１つまたは複数のノードを有し得る。一例において、ネットワークは、インターネットとネットワークとの間で複数の入出力通信経路を提供するための、複数のインターネット直結ノードを含む。インターネット直結ノードは、インターネットに接続されたルータであり得る。別の例において、ネットワークには、テナント仮想マシンをホストするように構成された複数のノードが含まれる。テナント仮想マシンをホストするノードは、１つまたは複数のテナント仮想マシンを動作させるのに必要なリソースを備えたホストサーバまたは他のデバイスであり得る。いくつかの実装において、ノードは、単一のテナントからの複数の仮想マシンをホストし得る。別の実施形態において、ノードは、異なるテナントが所有する複数の仮想マシンをホストし得る。更に別の実施形態において、ノードは、テナント仮想マシンをホストすること、および、インターネット接続性をネットワークに提供することの両方のために動作し得る。

動作中、システムは、第１ノードから第２ノードへパケットをルーティングするための方法を実装する。方法は、ネットワークの第１ノードでパケットを受信する段階を含む。方法は更に、パケットがどのような仮想ネットワークを通過するかシミュレートするべく、判定エンジンを起動する段階を含む。シミュレーションは、パケットのネクストホップを判定するべく仮想ルーティングテーブルにアクセスする段階と、ネクストホップが、ネットワークの第２ノード上の外向きポートであると判定されるまで、次の仮想ルーティングテーブルへの連続的なアクセスを継続する段階を含む。ここで、ネクストホップは、内向きポート（論理ポートとも呼ばれる）か、または、外向きポート（実体化ポートとも呼ばれる）のいずれかである。パケットをどのように処理するか、判定エンジンが判定した後、パケットは下位ネットワーク上で、第２ノードの外向きポートへ送信され得る。下位ネットワークは、イーサネット（登録商標）ネットワーク、プライベートもしくはパブリックＩＰネットワーク、または、複数のノード間で接続性を提供する他のネットワークであり得る。

ネットワークの各ノードは、エッジコネクタを含む。各エッジコネクタは、同一の物理ホストまたはノード上で動作するフロー構成可能スイッチ、および、判定エンジンのインスタンスを含む。一実施形態において、フロー構成可能スイッチは、Ｏｐｅｎ ｖＳｗｉｔｃｈなどのソフトウェアを含み得る。判定エンジンは、１つまたは複数の仮想Ｌ２スイッチおよび仮想Ｌ３ルータをシミュレートし得る。エッジコネクタは、物理インタフェース、仮想インタフェース、または、その両方を含み得る。仮想インタフェースは、例えば、ＴＡＰインタフェース、または、カーネルレベルの仮想インタフェースなどのインタフェースである。物理インタフェースは、例えば、物理ネットワークインタフェースカード（ＮＩＣ）である。

フロー構成可能スイッチは、アクションリストを、フロールールにマッチするパケットすべてに適用するソフトウェアコンポーネントである。アクションリストに関連するのは、何のパケットがフローにマッチするか指定するフローマッチングである。いくつかの実施形態において、フローマッチングは、パケットプロトコルヘッダパターンによって指定され得る。フローマッチングは、例えば、送信元ポートおよび送信先ポート、送信元アドレスおよび送信先アドレス、ＭＡＣアドレスなどを含む、パケットデータの１つまたは複数の部分に基づき得る。また、フローマッチングは、送信元または送信先アドレスの部分など、パケットデータの組み合わせ、または、パケットデータのサブセットに基づき得る。フロールールは、少なくともフローマッチング、およびアクションリストを含み得て、「フロー」と呼ばれ得る。２つのフロー（１つはインバウント、１つはアウトバウンド）は、接続を形成する。概して、２つのフロー（インバウントフローおよびアウトバウンドフロー）は、通信のための接続を、ネットワーク外部のクライアントと、テナントの仮想マシン、またはネットワーク内で提供される他のサービスとの間で形成する。１つまたは複数のフロールールによって表される各フローは、共有データベース内に維持される分散状態内に記憶され得る。一実施形態において、各フローは、分散状態へのアクセスを要求する他のすべてのノードがアクセス可能なネットワークのノード上で維持されている分散状態内に記憶される。記憶されたフローは、それらのフローマッチングによって、または、フロールールに関連する他の基準によってインデックスを付与され得る。

一実施形態において、接続の一方向における第１パケットのためのルーティング判定をキャッシュするフローテーブルが維持され得る。フローテーブルは、フロー構成可能スイッチ内で維持される。ネットワークは、外部ネットワークへの複数の可能なアクセスポイントを有し得る。接続は、アウトバウンドとインバウントで同一の仮想ルートを使用する必要はない。インバウントおよびアウトバウンドで異なるルートを可能することで、ネットワークの特定部分に遮断が発生した場合に、システムのフォールトトレランスが改善し得る。また、インバウントおよびアウトバウンドで異なるルートを可能することで、ネットワークの異なる経路の間で負荷を分散することにより、ネットワークリソースの利用率を改善することを可能にし得る。

また、ネットワークは、ネットワークのノード間でパケットをルーティングおよびスイッチングする転送要素を含み得る。転送要素は、Ｌ２スイッチ、Ｌ３ルータ、または、Ｌ２スイッチおよびＬ３ルータの組み合わせのいずれかであり得る。転送要素は、物理的または仮想的な転送要素のいずれかであり得、ネットワークは、物理転送要素および仮想転送要素の組み合わせを含み得る。物理転送要素は、ハードウェアコンポーネントであり、仮想転送要素は、ソフトウェア内に実装され得る。一実施形態において、仮想転送要素は、テーブルを使用して実装され得る。例えば、判定エンジンは、ネットワークのために確立された仮想トポロジに従って、パケットのルーティングおよびスイッチングをシミュレートするのに使用され得る。

ネットワークにおいて、仮想ネットワークグラフによって示され得る仮想ネットワークトポロジを構築するべく、仮想ルータは、他の仮想ルータに接続され得る。各仮想ルータは、複数の仮想ポートを含み得る。各仮想ポートは、内向き（論理）ポート、または、外向き（実体化）ポートのいずれかであり得る。例えば、各仮想ルータは、仮想ルーティングテーブルを含み得る。仮想ルータによってルーティングされるパケットのためのネクストホップを判定するべく、内向きポートは、仮想ルーティングテーブル内の検索を実行することによって識別され得る。各検索は、別の仮想ルータのピア内向きポート、または、外向きポートへ出力され得て、複数の仮想ルータを有する仮想トポロジの通過を判定エンジンがシミュレートすることを可能にする。

別の実施形態において、エッジコネクタは、仮想ルータのポートではないトンネルポートを有し得る。トンネルポートは、ネットワーク全体にわたって１つのエッジコネクタを別のエッジコネクタに接続するのに使用され得る。例えば、１つのエッジコネクタのフロー構成可能スイッチは、トンネルポートによって、別のエッジコネクタのフロー構成可能スイッチに接続され得る。別のエッジコネクタの仮想マシン宛てのパケットが、１つのエッジコネクタに到達し得る。パケットが別のエッジコネクタ上の外向きポート宛てである場合、トンネルを介してそのエッジコネクタへ送信される。ポートをエッジコネクタに対してマッピングするテーブルと、エッジコネクタをトンネルに対してマッピングするテーブルとが、分散状態内に維持され得る。従って、エッジコネクタは、選択された（非ローカル）ポートに基づいて、どのトンネルを通ってパケットを送信するか判定し得る。エッジコネクタに対する外向きポートのマッピング、および、トンネルに対するエッジコネクタのマッピングは、別個のノード上で維持され得る。エッジコネクタは、パケットのための適切なトンネルを判定するべく、別個のノードと通信し得る。

一実施形態において、各ノード上のエッジコネクタは、分散状態へのアクセスを有し、これは、共有データベース内に記憶され得る。分散状態は、エッジコネクタによって維持および共有される。分散状態は、例えば、構成ツリー、ならびに、仮想および／または物理ネットワークトポロジに関する他のデータを含み得る。一実施形態において、分散状態は、Ｚｏｏｋｅｅｐｅｒおよびｍｅｍｃａｃｈｅを使用して実装され得る。別の実施形態において、分散状態の一部は、構成ツリーであるが、ハッシュテーブルおよび多分木など、他の構造が考えられる。構成ツリーおよび他の共有データは、必要に応じて、判定エンジンなど、エッジコネクタによってアクセスされ得る。

本明細書で利用されている、「クライアント」という用語は、本明細書において、例えば、仮想マシンのサービスにアクセスするべく、システム内でホストされているサーバに到達することを試みている、ウェブブラウザなどの外部ネットワーククライアントを示すのに使用されている。「テナント」という用語は、サービスプロバイダの顧客を示すのに使用されている。テナントは、１つまたは複数の仮想マシン、または、システム内の物理マシン上で動作する他のサービスを有し得て、これらの仮想マシンとクライアントとの間で、負荷分散またはネットワークアドレス変換（ＮＡＴ）ルールを動的に確立することを希望し得る。本明細書で使用される、「キャッシュ」、「キャッシュする」という用語、またはその他のバリエーションは、キャッシュとして明示的に指定されたメモリ内にデータが記憶されるかどうかに関係なく、すべての形態の一時的データストレージを指す。

仮想ネットワークを下位ネットワーク上にオーバーレイするのに適切な汎用システムアーキテクチャのいくつかの機能の概要が上述されている。上述の機能および実施形態を、図面に関連して説明する（全体を通して、同様の参照番号は、同様の要素を指すのに使用される）。その後、汎用システムアーキテクチャについて実装され得る追加的な態様を説明する。

図１において、ノード１０１（例えばサーバ）が、２つのネットワークインタフェースカード、ＮＩＣ Ａ １１１およびＮＩＣ Ｂ １１２と共に示されている。例示の目的で、いくつかのノードは、インターネットクライアントに直結するエッジノードとして指定され得て、ネットワークに対してインターネット接続性を提供し得る。他のノードは、ネットワーク内のテナント仮想マシンまたは他のサービスをホストするように構成されたホストノードとして指定され得る。例示の目的で、エッジノードおよびホストノードは、対称的アーキテクチャで示され得るが、様々な実施形態において、システム内の様々なノードに各種アーキテクチャが使用され得る。また、システムはインターネット直結エッジノードおよび仮想マシンホストノードの観点で示されているが、ネットワークの動作を促進する必要があるデータストレージデバイスおよびサポートサーバを含む中間ノードを有し得る。図１に示されているように、ＮＩＣ Ａ １１１は、インターネット１５１への接続を有し、ＮＩＣ Ｂ １１２は、内部プロバイダファブリック１５２（例えば、下位ネットワーク）への接続を有する。内部プロバイダファブリック１５２は、プライベートＩＰネットワーク、または、ノード間でＩＰ接続性を提供する別のネットワークであり得る。

システムは、物理ネットワーク上にオーバーレイされる仮想ネットワークの機能の多くを実装するソフトウェアコンポーネントを含む。フロー構成可能スイッチ１６１および判定エンジン１６５などのソフトウェアコンポーネントは、その中に符号化されている様々な機能を実行するようにプロセッサを構成するべく、コンピュータプロセッサによって実行可能なコンピュータ実行可能命令を含む。ソフトウェアコンポーネントの動作を示すべく、選択された動作について、パケットの受信後のアクションが記載されている。

一実施形態において、ＴＣＰ接続を確立するべく、ＳＹＮパケットが受信される。ＳＹＮパケットは、インターネット１５１から、ＮＩＣ Ａ １１１上で受信される。パケットは、スイッチングのためのフロー構成可能スイッチ１６１で、エッジコネクタによって受信される。フロー構成可能スイッチ１６１は、パケットに関連するデータを、フローテーブル１６２に記憶されているフロールールにマッチさせることで、フロールールを識別するように試行する。マッチされるデータには、例えば、送信元ポートおよび送信先ポート、ネットワークアドレス、ＭＡＣアドレス、または、パケットに関連する他のデータが含まれ得る。ＳＹＮパケットは通常、フロー内の第１パケットであり、したがって、フロー構成可能スイッチ１６１は、第１パケットに対応するエントリをフローテーブル１６２内で見つけない。フローテーブル内に対応するエントリが見つからない場合、フロー構成可能スイッチ１６１は、判定エンジン１６５に対し、機能呼び出しを行い、パケットを判定エンジンに伝達する。パケットは、フロー構成可能スイッチのポート上に到達し得て、フロー構成可能スイッチは、パケットによって受信ポートＩＤを判定エンジンに伝達し得る。分かり易くするため、フロープログラマブルスイッチおよび判定エンジンの機能は別個に記載されているが、要望に応じて、ソフトウェアコンポーネントが一体化され得ることは明らかであろう。代替的に、各コンポーネントは、そのコンポーネントの機能が維持されていれば、分割したり、他のコンポーネントと組み合わせたりしてもよい。一実施形態において、判定エンジンは、ＯｐｅｎＦｌｏｗプロトコルを介して、フロー構成可能スイッチ１６１と通信し、フロー構成可能スイッチの受信ポートＩＤを仮想ポートＩＤ（ｖｐｏｒｔ）へ変換する。代替的に、このマッピングは、受信ポートＩＤではなく、ＭＡＣアドレス、または８０２．１ｘ認証情報に基づき得る。パケットのルーティングの残り部分は、そのＬ３情報に依存し得る。判定エンジン１６５は、仮想ネットワークトポロジを通るパケットのルートをシミュレートするための論理を有する。一実施形態において、接続の第１パケットのみが、判定エンジンへの呼び出しを発生させる。なぜなら、フローがフローテーブル１６２内に作成されると、そのフローは、同一のフローの後続パケットに適用され得るからである。

新しいフローに関連するフロールールを作成するべく、判定エンジンは一実施形態において、パケットをどのように処理および転送するか示すアクションリストを構築し、それをフロールールとしてフローテーブル内に挿入する。そのフローの基準にマッチする後続パケットは、パケットを特定ポートへルーティングすることを含み得る、適用されるアクションリストを有する。パケットが、別のサーバ上で動作している別のエッジコネクタ宛てである場合、トンネルポートを介して、他のエッジコネクタへルーティングされ得る。トンネルポートは、下位ネットワーク上でエッジコネクタまたはノードを接続し得て、エッジコネクタ間でパケットを転送するのに使用される。代わりに、パケットが別のエッジコネクタ上の仮想ポート宛てである場合、トンネルを介してエッジコネクタへ送信される。トンネルプロトコルは、一実施形態において、ＧＲＥ＋ＩＰである。このトンネリングプロトコルは、サーバ１０１上の１つのフロー構成可能スイッチ１６１が、内部プロバイダファブリック１５２を介して、別のサーバ（図示せず）上の別のフロー構成可能スイッチ（図示せず）と通信することを可能にする。

図２は、複数のエッジコネクタ２０３、２０４、２０５の物理的相互接続を示す。これらはそれぞれ、プロバイダの内部Ｌ３ネットワークファブリック２０２によって接続された複数のホスト２１０、２２１、２２２上にある。例示の目的で、仮想マシン２１１および２１２は、ホスト２２１上で動作し、仮想マシン２１３および２１４は、ホスト２２２上で動作する。管理コンソール２０６は、下位ネットワークを形成する内部ネットワークファブリック２０２にも接続され得る。

図３は、この物理ネットワーク上にオーバーレイされる仮想トポロジを示す。トンネリングプロトコルは、ファブリックが、プロバイダファブリック１５２内のハードウェアに修正を加えることなく、フロー構成可能スイッチ間でパケットをルーティングすることを可能にする。実際のパケットは、イーサネット（登録商標）（Ｌ２）ではなく、ＩＰ（Ｌ３）上で移動するので、ネットワークは拡張可能であり、イーサネット（登録商標）通信に適用される距離の限界によって制限を受けないことがある。トンネルのエンドポイントは、エッジコネクタのフロー構成可能スイッチ内のポートであるが、トンネルポートは、外向きポートと異なる処理を受ける。トンネルパケットヘッダのＩＰ部分は、パケットが的確なホストへ到達することを可能にし、次に、ヘッダのＧＲＥ部分は、パケットを正しいトンネルポートへ到達させるのに役立つ。ヘッダ内の更に別のキーは、送信先の外向きポートを識別するのに役立つので、受信するエッジコネクタは、パケットを的確なローカルポートへルーティングし得る。

再び図２において、３つのエッジコネクタ２０３、２０４および２０５を含むネットワークが示されている。各エッジコネクタはホスト上に存在する。一態様において、各エッジコネクタは、図１に関して上述したノード１０１と同様であり得る。上の例に引き続き、パケットは、インターネット１５１から、インターネットに接続されたルータ２０１を介して、物理ネットワークインタフェースカード（ＮＩＣ）上のエッジコネクタ２０３で受信され、パケットは仮想マシン２１１宛てであると仮定する。上述のように、パケットは、フローの第１パケットであり、そのようなパケットに対応するフロールールはフローテーブル内に存在しない。対応するフローエントリがフローテーブル内に存在しないので、判定エンジンが起動される。判定エンジンは、フロー構成可能スイッチによって、場合によっては、ＭＡＣアドレスおよび８０２．１ｘ認証情報によって、パケットが受信されたポートに基づいて、仮想ポート（ｖｐｏｒｔ）を判定する。この例におけるｖｐｏｒｔは、ＮＩＣに対応する外向き（実体化）ポート、および、フロー構成可能スイッチ内のポートである。判定エンジンは、ｖｐｏｒｔを使用して、ポートが仮想ルータまたは仮想スイッチのうちどれに接続されているか判定する。上述のように、仮想ルータは、判定エンジンがアクセス可能なテーブルによって実装され得て、分散状態内に維持され得る。何れの仮想ルータが外向きポートに接続されているかを判定エンジンが一旦判定すると、判定エンジンは、対応する仮想ルータテーブル内の送信先ＩＰアドレスを識別することで、マッチするルートを選択する。一実施形態において、判定エンジンは、負荷分散アルゴリズムを使用して、複数のルートから１つのルート、または、コストが等しい複数のルートを選択し得る。

別の実施形態において、判定エンジンが仮想ルータテーブルにアクセスして、ＩＰアドレスを検索する場合、ルーティング前処理およびルーティング後処理が適用され得る。ルーティング前処理は、ネットワークアドレス変換（ＮＡＴ）を実行するべく、送信元ＩＰアドレスおよび送信先ＩＰアドレス、ならびに、送信元ポートおよび送信先ポートを含むパケットを変更し得る。ルーティング方法は、送信元ＩＰアドレスおよび送信先ＩＰアドレスを抽出する段階と、仮想ルータに対応する仮想ルーティングテーブル内のＩＰアドレスを検索する段階と、（１より多くのルートが見つかった場合）送信先を選択する段階と、パケットをルートエントリに対応するポートへ転送する段階とを含み得る。パケットの転送は、マッチするルートのネクストホップが内向きの（論理的）ポートであるか、外向きの（実体化された）ポートであるかに依存する。仮想ルータは、テーブルとして実装され得るので、２つの仮想ルータ間のルーティングは、連続する仮想ルータテーブル内の検索を含む。一実施形態において、各仮想Ｌ３ルータについて、グローバルルーティングテーブルが維持される。グローバルルーティングテーブルは、共有データベース内の分散状態に記憶され得る。代替的に、グローバルルーティングテーブルは、選択されたエッジコネクタ上に記憶され得る。別の実施形態において、グローバルルーティングテーブルは、各エッジコネクタ上に維持され、エッジコネクタは、協働して、ネットワーク内のエッジコネクタにおけるグローバルルーティングテーブルを互いに維持および更新する。

再び図３において、図２の物理ネットワークなどの下位ネットワーク上にオーバーレイされ得る仮想トポロジが示されている。一例において、パケットは、仮想Ｌ３ルータ３０１に関連する外向きポートに到達し得て、その送信先ＩＰアドレスは、ＶＭ２１１のＩＰアドレスである。判定エンジンは、ｖｐｏｒｔがどの仮想ルータに接続されているか判定するべく、パケットが到達するｖｐｏｒｔを使用し得る（この場合では、仮想Ｌ３ルータ３０１）。一実施形態において、仮想Ｌ３ルータ３０１は、プロバイダルータであり得、ネットワークを運用するサービスプロバイダによって作成および管理され得る。次に、判定エンジンは、パケットの出力ポートを判定するべく、パケットに関連するＩＰアドレスを利用し得る。出力ポートがローカルの外向きポートである場合、フロー構成可能スイッチ内でフローが確立され、パケットはローカルの外向きポートへルーティングされる。外向きポートがローカルでない場合、パケットは、ｖｐｏｒｔ‐ホストのテーブル、および、ホスト‐トンネルポートのテーブルに従って、トンネルポートからルーティングされる。ポートが別のルータまたはスイッチの内向きポートである場合、外向きポートが識別されるまで、同一の検索処理が繰り返される。引き続き図３において、仮想ルータ３０１のテーブル内の検索は、仮想ルータ３０２に対応する内向きポートを返し得る。要望に応じて、検索後、または、検索と組み合わせて、ルーティング後処理がパケットへ適用され得る。検索が、別の仮想ルータ（この例では仮想Ｌ３ルータ３０２）に対応する内向きポートを返す場合、判定エンジンは、仮想ルータ３０２について、同一の処理を繰り返し得る。仮想ルータ３０２は、例えば、テナントの仮想マシン、仮想マシン２１１および２１２の間でトラフィックをルーティングするべく、テナントによって作成された仮想ルータであり得る。テナントの仮想マシンは、同一ホスト上にあり得るか、または、ネットワーク内の異なるホスト上に位置し得る。テナントは、サービスプロバイダによって確立されたルールに従うネットワーク容量の範囲内で、任意の数の仮想マシンまたは他のサービスを運用するべく、サービスプロバイダからネットワークリソースをリースし得る。判定エンジンは、仮想Ｌ３ルータ３０２に関連する何らかのルーティング前処理と、ネクストホップを判定することを目的とした仮想ルーティングテーブル内のＩＰアドレス検索と、任意のルーティング後処理とを含み得るシミュレーションを実行する。この例において、ネクストホップは、エッジコネクタ２０３と異なるエッジコネクタ上でホストされる仮想マシン２１１である。仮想ルータ３０２の仮想ルータテーブルは、テナントまたはサービスプロバイダによって構成されるようなＶＭ２１１に対応するｖｐｏｒｔを提供する。一実施形態において、装置利用率を管理するべく、または、ネットワーク内の物理コンポーネントの保守もしくは修理中の動作を維持するべく、サービスプロバイダは、ネットワーク内の異なるノード間でテナント仮想マシンを移動させ得る。次に、判定エンジンは、分散状態に維持されているポート位置ディクショナリ内で、出口ｖｐｏｒｔの物理的位置を検索する。スイッチによって転送されるすべてのパケットは、Ｌ２パケットなので、Ｌ２パケット内には、ＭＡＣアドレスのための空間がある。しかしながら、トンネルポートは、２つのフロー構成可能スイッチの間にあるので、ＭＡＣアドレスは、特定の用途には必要でないことがある。より具体的には、特定の実施形態において、実際のＭＡＣアドレスを転送する必要はない。なぜなら、出口エッジコネクタは、ＡＲＰを使用してネクストホップＭＡＣを判定することによって、自身のローカル情報に基づいて、ＭＡＣアドレスを構築できるからである。代わりに、送信先（この場合はＶＭ２１１）のｖｐｏｒｔは、ＭＡＣアドレスのための空間へ符号化される。パケットは次に、エッジノードのＩＰアドレスを送信先として、ＧＲＥ＋ＩＰ内に包まれる。これで、Ｌ３ネットワークを介してパケットをルーティングする準備ができた。

再び図１において、このフローの以後すべてのパケットとマッチするべく、ルーティング前処理、ルーティング後処理、および、ルーティング先を含むアクションリストが、フローテーブル１６２内にインストールされ得る。パケットは、トンネリングプロトコルを介して、オペレーティングシステムルータ１１３を通って、その後、ＮＩＣ Ｂ １１２へ送出され得る。パケットは、ＮＩＣ Ｂ １１２を出た後、エッジコネクタ２０４の送信先ＩＰアドレスによって、任意の他のＩＰパケットと同様に、内部プロバイダファブリック１５２上でルーティングされる。

パケットがエッジコネクタ２０４によって受信されるとき、フロー構成可能スイッチのトンネルポートに対応するトンネル上で受信される。パケットはトンネルポート上で受信されるので、エッジコネクタは、外向きポート上で入ってきたパケットと異なる処理を、このパケットに対して行い得る。上述のように、パケットは、このフロー上で受信された第１パケットなので、エッジコネクタ２０４は、判定エンジンを起動する。一実施形態において、トンネルキーは、送信先ｖｐｏｒｔ ＩＤを符号化する。判定エンジンは、仮想マシン２１１のＭＡＣアドレスおよびローカルポート番号を判定するべく、ｖｐｏｒｔ ＩＤを使用し得る。いくつかの場合、判定エンジンは、ＶＭ２１１のＭＡＣアドレスを判定するべく、ＡＲＰ要求を開始し得る。代替的に、ＭＡＣアドレスは、ＡＲＰテーブル内にキャッシュされ得る。ＡＲＰテーブル（ＩＰからＭＡＣ）は、仮想ルータのポートごとに維持される。ＡＲＰテーブルは、共有データベース内に記憶された分散状態で共有され得る。判定エンジンがＶＭ２１１のｖｐｏｒｔを判定した後で、システムは、フローテーブル内にフローをインストールし得て、これにより、このフローの以後のパケットをルーティングし得る。その後、パケットは、ＶＭ２１１に対応するフロー構成可能スイッチのポートへルーティングされ得る。ＶＭ２１１は、エッジコネクタ２０５もホストしているホスト２２１上で動作しているローカル仮想マシンであるが、判定エンジンは、送信先ＭＡＣアドレスを見つけるのに、送信先ＩＰアドレスをやはり使用し得る。このように、システムは、ＶＭがローカルであるか、または、別のルータもしくはスイッチへの標準ポートであるかを抽象化し、システムの柔軟性を更に提供す。

フローが確立されると、同一の接続上での後のインバウントパケットは、エッジコネクタ２０３および２０４のフローテーブル内のフローにマッチして、判定エンジンを起動することなく、それらのマシン上のフロー構成可能スイッチによって、修正および転送される。この処理は、システムを通る、所望の送信先への接続のインバウントフローを確立する。

同一の接続上でＶＭ２１１が応答すると、それが送信する第１パケットは、反対方向の対応するフローを確立するべくシステムを始動する。新しいフローが確立されるとき、判定エンジンは、反対方向のフローが以前に確立されたかどうか判定するべく、分散状態にアクセスし得る。この分散状態は、ＮＡＴなど他の処理の実装を容易にして、また、詳細は後述するが、終了した接続をシステムがクリーンアップすることを可能にする。別の実施形態において、異なる物理コンポーネント上でホストされる仮想マシンは、同一の仮想ルータに接続され得る。

ここで図４において、上述の方法の実施形態を実行するエッジコネクタ上で動作する処理の高いレベルの概要が示されている。実施形態において、エッジコネクタは、インターネットなどの外部ネットワークからパケットを受信する、少なくとも１つのＣＰＵを備えた物理マシン上で動作する。ここで、パケットは、システムのテナントに関連するＩＰアドレスに宛てられる。テナントＩＰアドレスは、システム内の１つまたは複数のホスト上で動作するテナント仮想マシンに割り当てられ得る。一実施形態において、テナントまたはサービスプロバイダが仮想マシンをシステム内の異なるホストへ移動させる場合でも、テナント仮想マシンに関連するＩＰアドレスは、一定のままであり得る。実施形態において、システムは、１つのアップリンク上の複数のＩＰアドレスが、異なるエッジコネクタおよび異なるテナント仮想マシンへルーティングされることを可能にすることで、複数のテナントが、１つのサービスプロバイダのアップリンクを共有することを可能にする。エッジコネクタが段階４１０でパケットを受信するとき、段階４１２で、これらに制限されないが、送信元アドレスおよび送信先アドレス、ならびに、送信元ポートおよび送信先ポートなどを含む複数のデータを抽出する。データを抽出後、エッジコネクタは、フローテーブル内で複数のデータを検索し（段階４１４）、フローが既に確立されたかどうか判定する（段階４１６）。フローの例として、組み合わされて単一のＴＣＰ接続を形成するインバウントフローおよびアウトバウンドフローを有するＴＣＰ接続の一方向がある。フローが既に存在する場合、段階４１８において、フローアクションリストはパケットに適用され、パケットは、フローアクションリストによって示されたフロー構成可能スイッチのポートへ転送される。

フローが存在しない場合、これはノードによって受信された、フロー内の第１パケットであり、エッジコネクタは段階４１７において、例えば、ＭＡＣアドレス、送信元アドレスおよび送信先アドレス、または、送信元ポートおよび送信先ポートに基づいて、パケットが何の仮想ポートに到達したか判定する必要がある。エッジコネクタが仮想ポートＩＤを判定すると、エッジコネクタは、何の仮想転送要素にそのポートが接続されているか判定できる。図１０の実施形態において、仮想転送要素は仮想ルータであるが、後述するように、仮想スイッチなど他の仮想転送要素（ＶＦＥ）が必要に応じてシステム内で利用され得る。エッジコネクタがＶＦＥを判定すると、エッジコネクタは段階４２０において、別の検索を実行する。検索は、一連の仮想転送要素内の送信先ＩＰアドレスを検索することで実行される。仮想転送要素は、パケットが転送される適切な経路を判定するべく、仮想ルーティングテーブルを含む仮想ルータおよび仮想スイッチの任意の組み合わせを有し得る。示されている実施形態において、判定エンジンは段階４２０で、第１仮想転送要素におけるパケットの送信先を判定する。第１仮想転送要素は、仮想ルータであり得、この場合、返される送信先は、外向きポートまたは内向きポートのいずれかであり得る。上述のように、内向きポートは、第２仮想ルータの別の内向きポートと対を成し、第２仮想ルータは別のルーティングテーブルを有する。内向きポートが返される場合、判定エンジンは段階４２０で、第２仮想ルータのルーティングテーブル内の送信先アドレスを検索し、外向きポートが返されるまで継続する。一実施形態において、各テナントは、そのテナントによって取り扱われるすべてのパケットをルーティングするように構成された単一の仮想ルータを有し得る。別の実施形態において、いくつかのテナントは、複数の仮想ルータ、仮想スイッチ、または、仮想ネットワークトポロジのテナントの部分を定義する他の仮想転送要素を有し得る。また、判定エンジンは、各仮想ルーティングテーブルから、パケットに実行される一連のアクションを構築する。アクションリストに追加され、フローにマッチするパケットに適用されるフロールール内に組み込まれるルーティング前またはルーティング後処理を各ルーティング段階は含み得る。

外向きポートが返されると（段階４２４）、エッジコネクタは、外向きポートがローカルかどうか判定する（段階４２６）。ポートがローカルである場合、ローカルの外向きポートへパケットをルーティングするためのアクションがアクションリストに追加される（段階４２８）。様々な実施形態において、ローカルの外向きポートは、ネットワークインタフェースカードまたは仮想マシンであり得る。次に、フロールールがフローテーブルへ追加され（段階４３０）、パケットへ適用される（段階４１８）。外向きポートがローカルでない場合、ポートは異なるエッジコネクタ上にある。一実施形態において、エッジコネクタは、ＧＲＥ＿ＩＰトンネルポートなどのトンネルポートによって接続され得る。段階４３２において、エッジコネクタは、外向きポートをトンネルポートへマッピングすることを試行するべく、仮想ポート‐トンネルのテーブルにアクセスする。仮想ポート‐トンネルのテーブルマッピング内に対応するエントリが無い場合、パケットをドロップし、ＩＣＭＰパケットを送信するためのアクションがアクションリストに追加され（段階４３４）、フロールールがフローテーブルに追加され（段階４３０）、フロールールがパケットへ適用される（段階４１８）。

外向きポートが外向きポート‐トンネルのテーブル内にある場合、そのトンネルへパケットを出力するためのアクションがアクションリストに追加され（段階４３６）、フローがフローテーブルに追加され（段階４３０）、アクションリストがパケットに適用される（段階４１８）。

一実施形態において、システムは、アクションリストおよびフロールールをフロー構成可能スイッチデータ経路内にインストールし、フロー構成可能スイッチは、段階４１６に示すように、フロールールにマッチする任意の後続パケットにアクションリストを適用する。上述のように、アクションリストの一部は、フロー構成可能スイッチのどのポート上でパケットが送信されるかを含む。エッジコネクタは、ポート‐ホストＩＰのテーブルにおいてポートを検索し、パケットをそのＩＰアドレスへ送信する。エッジコネクタは次に、アクションリストをフローテーブル内に記憶する。マッチする複数のデータを有するすべての後続パケットは、それらに適用されるアクションの同一の組を有するので、それらは、同一のＩＰアドレスへルーティングされる。

仮想ルータ内の送信先アドレスを識別する処理の間、フローは、ルーティング不可能であるか、破棄されるか、拒否ルートにマッチすることがあり、この時点で、パケットはドロップされるか、ＩＣＭＰパケットが返される。この実施形態において、フローのルールにマッチするすべてのパケットをドロップするべく、フローが作成され得る。このように、システムは、サービスプロバイダもしくはテナントによって確立されたルールに従って、ルーティング不可能のパケットを取り扱うか、または、望ましくないデータを選択的にスクリーニングするように構成され得る。

更に別の実施形態において、テナントＶＭをホストするエッジコネクタは、内部ファブリックネットワークに接続された複数のＩＰアドレスおよび複数のＮＩＣを有し得る。そのような場合、インターネット直結エッジコネクタは、エッジコネクタをホストするＶＭへの複数の経路の１つを選択し得る。更に、複数のＩＰアドレスを有するエッジコネクタをホストするＶＭは、エッジコネクタを識別するための一意のＩＤを有し得て、フローをルーティングする判定エンジンは、例えば負荷分散アルゴリズムを使用して、または、ランダムに、エッジコネクタをホストするＶＭのＩＰアドレスの１つを選択し得る。

システムの別の実施形態は、エッジノードのための、ＩＰアドレス以外の識別子を使用し得る。例えば、ネットワークファブリックは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）、もしくは、エッジコネクタの間に専用回路を有する別のカスタムＯｐｅｎＦｌｏｗコントローラなど、回路ベースであり得る。この実施形態において、回路は、エッジノード上のフロー構成可能スイッチの間のＧＲＥトンネルと置き換わり得る。

別の実施形態において、システムは、ルーティングステージの前後に、ルーティング前およびルーティング後のステージを提供する。ルーティング前およびルーティング後のステージは、ネットワークアドレス変換（ＮＡＴ）、負荷分散、または、他のＬ３／Ｌ４機能を実装するべく利用され得る。一実施形態において、ルーティング前ステージは、（例えば、ネットワークアドレス変換内で）フローの送信先を変更し得て、アウトバウンドルーティングは、（例えば、やはりネットワークアドレス変換内で）フローの送信元を変更し得る。ＴＣＰ接続など単一の接続を含むフォワードフローおよびリバースフローによって実行されるマッピングを調整するべく、接続変換は、長いタイムアウトで分散状態内に記憶され得る。接続トラッキングが、良好に閉じられた接続を検出するとき、これらの変換は事前にクリーンアップされ得る。

本システムの一実施形態において、ＮＡＴは、ルーティング前およびルーティング後の変換を使用して実装される。フロー設定において、ＮＡＴルーティング前ステージは、以前に反対方向（インバウントまたはアウトバウンド）で確立されたフローが分散状態内にあるかどうか判定し、そうである場合、以前に作成されたマッピングは、新しいフローのために反転される。フロールールは、すべてのノードがアクセス可能な分散状態システム内に記憶されるので、異なるノード上で新しいフローが作成されると、反対方向のフローが以前に作成されたものかどうか判定することができる。反対方向のフローが分散状態内にない場合、判定エンジンは、新しい変換を作成し、その変換マッピングを新しいフローに関連する分散状態内に記憶する。インバウントフロー、または代替的に、確立された第１フローについて、ルーティング段階の前に、アドレス変換が送信先アドレスへ適用され得て、ルーティング段階は、変換されたＩＰアドレスに基づいてルーティングし得る。送信元アドレスを外部の非プライベートＩＰアドレスへ変換するべく、アウトバウンドフロー、または代替的に、接続内の第２フロー上で、ルーティング後にＮＡＴが実行され得る。変換情報は、フローの初期パケットの転送前に、フロールールに関連する分散状態内に記憶され得て、それにより、リバースフローの初期パケットが対応するエッジコネクタで受信されたときに変換情報がアクセス可能となる。

別の実施形態において、プライベートネットワーク上でホストされるサービスを汎用インターネットに公開するべく、パブリックで利用可能なＩＰアドレスをプライベートネットワークアドレスへ変換するのに、送信先ネットワークアドレス変換（ＤＮＡＴ）が使用され得る。いくつかの実施形態において、汎用インターネットとプライベートネットワークとの間に非武装地帯（ＤＭＺ）が提供され得る。ＤＮＡＴ処理において、受信フローのためのルーティング前ステージ中に送信先アドレスが変換され得て、対応する発信フローにおいて、ルーティング後ステージ中に送信元アドレスが変換され得る。一実装において、送信先アドレスは、複数の潜在的なサーバの１つであり得て、送信先サーバは、ランダムアルゴリズムまたはラウンドロビンアルゴリズムなどの負荷分散アルゴリズムによって選択され得る。

送信元ネットワークアドレス変換（ＳＮＡＴ）において、プライベートＬＡＮ上の複数のクライアントは、同一のパブリックＩＰアドレスを共有し得る。テナント仮想マシンから外部ネットワークへの接続など、アウトバウンド接続に関連する送信元アドレスは、アウトバウンドフロー内の同一のＩＰアドレスへ変換され得る。対応するインバウントフローにおいて、パケットの送信先ＩＰアドレスは、例えば、ポート番号および送信元ＩＰアドレスに基づいて、対応するプライベートＩＰアドレスへ変換され得る。

別の実施形態において、システムは、プライベートのローカルエリアネットワークのためのＡＲＰスプーフィングを提供するべく構成され得る。システムは、仮想マシンゲストなど、単一のネットワークホストが、他の単一ホストにＡＲＰを行うときにそれらになりすますことによって、ゲートウェイ／ブロードキャストアドレスを消費することなく、仮想ルータポートへ接続されることを許可し得る。従来のイーサネット（登録商標）ベースの設計において、これは、ゲストのアドレス、ゲートウェイアドレス、および、ブロードキャストアドレス、更には、１つの未使用アドレスを含む、少なくともａ／３０のアドレス範囲を消費する。

消費されるＩＰアドレスの数を低減する１つの方法として、ルータの各ポートは、ＭＡＣアドレスおよびネットワークプレフィックス（ｎｗ＿ｐｒｅｆｉｘ）、ならびに、ポートに接続されている単一ホストがあるかどうか示すフラグについて、構成され得る。使用されるゲートウェイアドレスは、ｎｗ＿ｐｒｅｆｉｘ範囲内の第１アドレスであり得る。単一ホストフラグが未設定である場合、ルータは、標準動作ルールに従って、ポートとの間のトラフィックに対処する。単一ホストフラグが設定されている場合、ｎｗ＿ｐｒｅｆｉｘのアドレス部分は、そのポートの単一ネットワークホストのアドレスを指定する。ルータの下流ポートは、単一ホストフラグが未設定である、重複していないｎｗ＿ｐｒｅｆｉｘと、ｎｗ＿ｐｒｅｆｉｘによって指定される同一のアドレス範囲を共有し得る、単一ホストフラグが設定されているポートとを有するように構成され得る。多くの実施形態において、単一ホストおよび非単一ホストポートによって使用されるアドレス範囲は重複しない。

単一ホストフラグが設定されたポートの間でＩＰパケットが送信される場合、ルータは、有効期間（ＴＴＬ）をチェックまたはデクリメントすることなく、Ｌ２スイッチをエミュレートして、ＩＰパケットを転送し得る。単一ホストフラグが設定されたポートから、別の単一ホストポートに関連するアドレス宛てに、ＡＲＰ要求が受信されると、ルータはターゲットになりすましてＡＲＰに応答する。その結果、ローカルセグメントと見なしたものの外部のホストへトラフィックを送信したい単一ホストは、ゲートウェイアドレスのためにＡＲＰを行い、ルータの通常の挙動は、ポートのＭＡＣを返し、次にホストはそのＩＰパケットを送信する。ローカルセグメントの一部であると見なしたホストへトラフィックを送信したい単一ホストは、直接的にそのホストのためにＡＲＰを行う。ルータは、そのアドレスの単一ホストポートを有する場合、そのＡＲＰに応答し、この場合、ホストは次に、そのＩＰパケットを送信する。単一ホストのフラグが付いたポート上にないホストの挙動は、変化しないことがある。

システムの別の実施形態において、ステートフル接続トラッキングが、接続のライフサイクルをトラッキングするのに使用され得て、それにより、それらの接続に関連するデータは、接続の終了など、特定のイベントのときにクリーンアップされ得る。接続が良好に停止されたとき、クリーンアップされるデータは、ステートフルＮＡＴおよびＬＢマッピングなど、分散状態内に記憶されるデータを含む、様々な接続状態データを含み得る。接続が良好に停止されない場合、例えば、一方または他方が故障または切断した場合、長い構成可能なタイムアウト後に、接続状態が失効し得る。接続はＴＣＰ接続であり得、２つのフロー、すなわち、フォワードフロー、および、リターンフローを含み得る。ＴＣＰの場合、接続状態を判定するべく、システムは、ＴＣＰ接続状態のマシンをシミュレートし得る。

更に別の実施形態においてシステムは、接続のフォワードフローを取り扱うノードとは異なるノードによって取り扱われる接続のリターンフローを提供する。この種類の接続は、スプリットフローと呼ばれ得て、フォワードフローおよびリバースフローが異なる判定エンジンによって取り扱われることを特徴とする。一実施形態において、システムは、フォワードフローおよびリバースフローを見ている判定エンジンに、それぞれの側の閉鎖を伝達させることによって、スプリットフローをサポートする。例えば、フォワードフローのＦＩＮを取り扱う判定エンジンは、ＦＩＮのＡＣＫにマッチするアクションをインストールするべく、リターンフローを取り扱う判定エンジンに通知し得る（その逆も成立）。判定エンジンは協働することで、接続の両方の側が閉鎖したときを識別し得て、閉鎖した接続に関連するデータをクリーンアップできる。判定エンジンの間のこの通信は、分散状態システム内の共有された状態を通して発生し得る。追加的に、分散状態システムは、接続の両方の側の閉鎖など、特定の条件を識別し得て、通信のフローの各々を取り扱う判定エンジンに通知を伝達し得る。

別の実施形態において、エッジノードまたはエッジコネクタが、（ＴＣＰ接続であるかどうか、および、例えば、接続に対してＮＡＴが行われている場合に、ステートフルトラッキングが必要かどうかに基づいて）トラッキングされる必要がある接続の一部である、フォワードフローまたはリバースフローのいずれかの設定を取り扱う場合、エッジコネクタは、ＴＣＰ ＦＩＮビットをチェックしてＦＩＮパケットを出力するアクションを追加する。ＦＩＮパケットを受信すると、リバースフローを取り扱う判定エンジンは、ＦＩＮのＡＣＫをチェックするアクションをインストールし得る。ＦＩＮのＡＣＫがシステムによって検出されると、接続はハーフオープンと見なされ、ＡＣＫ以外のいかなるデータも待たない状態になる。ハーフオープン接続によってデータが受信される場合、システムは、予期しない状態がシステムに発生したことを示すエラーを生成し得る。

判定エンジンが新しいフローを受信するとき、ＴＣＰ ＦＩＮおよびＲＳＴフラグをチェックするためのルールをインストールする。ピアがＲＳＴパケットを受信すると接続が終了されるので、システムがＲＳＴパケットを受信する場合、接続のタイムアウト期間が短くなるように、フロールールを修正する。システムがＦＩＮパケットを受信する場合、ＦＩＮパケットのシーケンス番号である、確認されたシーケンス番号にマッチするアクションを、リターンフローのアクションリストに挿入する。ＦＩＮを確認するパケットをシステムが取得する場合、接続のその側を閉鎖としてマークする。両方の側が閉鎖される場合、接続が短いタイムアウトを有するようにフロールールを修正する。いくつかの場合、ＦＩＮのＡＣＫは、ドロップされ得て、この場合、閉鎖する側は、同一のシーケンス番号を有するＦＩＮパケットを再送信する。フロールールが失効するとき、システムは、接続が閉鎖したことを識別し、ＮＡＴトラッキングなどの追加状態データをクリーンアップし得る。

本発明で開示されているシステムおよび方法の別の実施形態において、追加の仮想転送要素として、仮想スイッチが提供されている。システムは、各仮想Ｌ２スイッチの一部である、エッジコネクタのポートの間でＬ２パケットを送信し得る。このように、システムは、物理スイッチに接続されているＮＩＣの間でパケットを送信する物理Ｌ２スイッチの動作をシミュレートし得る。また、システムは、仮想ルータを使用して、パケットのＬ３パケットを、上述のように送信し得る。フローを設定するとき、入口ポートまたはＭＡＣアドレスのマッピングから、受信ｖｐｏｒｔ ＵＵＩＤが識別される。このｖｐｏｒｔのＵＵＩＤに基づき、ｖｐｏｒｔが属する仮想デバイスが判定される。仮想デバイスの種類（スイッチまたはルータ）に基づき、パケットは（上述のように）ルーティングまたはスイッチングされる。つまり、パケットがＬ３パケットである場合、上述の仮想ルータプロセスに従って取り扱われる。代替的に、パケットは、Ｌ２パケットであり、図５および図６に示すように、仮想スイッチによって処理される。図５および図６に示されているプロセスは、図４に示されているプロセスと実質的に同様である。段階４１７においてＶＦＥが判定された後で、エッジコネクタは、ＶＦＥが仮想ルータか仮想スイッチか判定する。ＶＦＥが仮想ルータである場合、図４に関して記載されたように処理が続く。ＶＦＥが仮想スイッチである場合、処理は点Ａ（５２０）で継続し、図６の点Ａ（５２０）に接続される。図６で示されているように、ＶＦＥが仮想スイッチである場合、エッジコネクタは、送信先ＭＡＣアドレスがブロードキャストアドレスであるか、または、ユニキャストＭＡＣアドレスであるか判定する（段階６１０）。ＭＡＣアドレスがブロードキャストアドレスである場合、パケットは、仮想スイッチに接続されている各ポートへ送信される（段階６２０）。この段階は、パケットごとに、段階４２６で開始する、図４のプロセスと同一であり得る。ＶＦＥのメンバーである各外向きポートについては、パケットは、ローカルｖｐｏｒｔ、または、外向きポートに対応するトンネルポートのいずれかへ送信される。

パケットがブロードキャストパケットでない場合（例えば、ユニキャストパケット）、送信先ＭＡＣは、例えば、ＭＡＣ‐ｖｐｏｒｔテーブル内の送信先ＭＡＣを検索することによって判定される（段階６３０）。対応するエントリが存在しない場合（段階６４０でテスト）、ドロップアクションがアクションリストに追加される（段階６５０）。処理は次に図５の点Ｂに続く。ここでは、ルールがフローテーブルに追加され（４３０）、アクションがパケットに適用される（４１８）。

ＭＡＣ‐ｖｐｏｒｔテーブル内に段階６４０の対応するｖｐｏｒｔが存在する場合、処理は図５の点Ｃに続き、上述のように、処理は段階４２６に続く。

図７および図８において、本発明で開示されているシステムおよび方法の別の実施形態が示されている。図７に示されているように、仮想ネットワークトポロジは、汎用インターネット９０２など、外部ネットワークへの複数の接続９０１を有するプロバイダ仮想ルータ９００を含む。この構成において、仮想ネットワークには、外部ネットワークへの複数の通信経路が提供され、システムの柔軟性および冗長性を可能にする。プロバイダ仮想ルータ９００は、複数のエッジノードに対応する複数の外向きポートを有し得る（エッジノードは、外部ネットワークへのアクセスを提供する物理コンポーネントである）。一実施形態において、エッジノードは、インターネット直結ルータまたはサーバであり得る。また、仮想ネットワークトポロジは、複数のテナント仮想ルータを有し得る。一構成において、各テナント仮想ルータは、テナント仮想データセンターに関連し得る。図７に示されているように、第１テナント仮想データセンター９０３は、複数の第１テナント仮想マシン９０５と通信する、第１テナント仮想ルータ９０４を含み得る。また、第１テナント仮想マシン９０５は、図示されているように、仮想イーサネット（登録商標）スイッチであり得るテナント仮想スイッチ９０６と通信し得る。第１テナント仮想マシン９０５は、ネットワーク内の１台、または、１台より多くのサーバもしくはホストノード上に存在し得る。

図７に示されているように、仮想ネットワークトポロジは、プロバイダ仮想ルータ９００および複数の第２テナント仮想マシン９０９と通信する第２テナント仮想ルータ９１０を含む、第２テナント仮想データセンター９０７を有し得る。また、複数の第２テナント仮想マシン９０９は、示されているように、仮想イーサネット（登録商標）スイッチであり得る第２テナント仮想スイッチ９０８と通信し得る。

また、仮想ルータは、各テナントの要望に応じて、負荷分散、ＤＨＣＰ、および／または、ネットワークアドレス変換のような追加機能を実行し得る。各テナントについて、１台の仮想ルータのみが示されているが、別の実施形態において、テナントは、テナント固有の仮想ネットワークトポロジを生成する複数の仮想ルータを採用し得る。テナント固有の仮想ネットワークトポロジは、所望の構成でテナント仮想マシンの編成を提供し得るか、または、同一のテナントによって制御される仮想マシンの間での分離を提供し得て、テナントはそこで、例えば、ネットワークを利用して、複数の個別の機能またはビジネスプロセスをホストする。

別の実施形態において、テナント仮想ルータは、セキュアなアクセスをリモートテナントオフィスまたは他の場所に提供し得る。示されているように、第２テナント仮想ルータ９１０は、第２テナントオフィス９１３における第２テナントＶＰＮルータ９１１、および、第２テナントオフィスネットワーク９１２への接続を提供する。このように、各テナントは、その仮想データセンターの構成を定義し得る。したがって、本発明で開示されているシステムおよび方法を利用するサービスプロバイダは、物理ネットワーク上で、テナントがカスタマイズできる多くのソリューションを提供し得る。

ここで図８において、図７で示された仮想ネットワークトポロジが、物理ネットワーク上にオーバーレイされた状態で示されている。物理ネットワークは、インターネット９０２などの外部ネットワークへアクセスするよう構成された複数のエッジノード９２０を備え得る。また、物理ネットワークは、仮想マシンをホストするよう構成された複数のホストノード９２１を備え得る。ネットワーク９２２は、複数のエッジノード９２０および複数のホストノード９２１を相互接続し得て、システム全体でデータパケットを伝送するように適用され得る。一実施形態において、ネットワークは、プライベートＩＰネットワークであり得る。エッジノード９２０およびホストノード９２１は、対称形のアーキテクチャを有し得る。一実施形態において、エッジノード９２０およびホストノード９２１は、クラウドコンピューティングシステム内で動作するよう構成されている汎用サーバである。別の実施形態において、エッジノード９２０は、専用のインターネット直結ルータである。更に別の実施形態において、サーバまたは他のコンピューティングデバイスは、同一ネットワーク内のエッジノードおよびホストノードの両方として機能し得る。また、システムは、ネットワークを通るエッジノードの各々、および、ホストノードの各々と通信する分散状態システムを含む。また、分散状態システムは、仮想ネットワークトポロジに関連するデータを記憶し得て、共有データベース内に記憶され得る。システムは、ノードの各々で動作して、プロバイダ仮想ルータおよびテナント仮想ルータの各々を含む仮想ネットワークトポロジを実装するソフトウェアコンポーネントを備え得る。新しいルーティングが構成されると、ノードの各々の上で動作するソフトウェアコンポーネントは、分散状態が仮想ネットワークトポロジの包括的なマッピング、および、システムのフロールールを維持するように、分散状態システムと通信し得る。他の例において、分散状態システムは、仮想ネットワークの選択部分について複数の分散状態が維持されるように、細分され得る。

図８に示されているように、仮想ネットワークトポロジは、物理ネットワーク上にオーバーレイされる。プロバイダ仮想ルータは、エッジノード９２０の各々に関連する外向きポートを有し得る。プロバイダ仮想ルータ９００の外向きポートは、インターネットサービスプロバイダのための１つまたは複数のアクセスポイントへマッピングし得て、システムと、インターネットなどの外部ネットワークとの間の複数の接続を提供し得る。また、プロバイダ仮想ルータ９００は、テナント仮想ルータの対応するピア内向きポートへの仮想リンクを定義する内部ポートを有し得る。示されているように、システム内の各仮想リンクのスループットは選択され得る。例えば、サービスプロバイダは、第１テナント仮想ルータ９０４への５０Ｍｂｐｓの仮想リンクを提供してもよい、第２テナント仮想ルータ９１０への１０Ｍｂｐｓ仮想リンクを提供してもよい。仮想リンクは構成可能なので、第２テナントが仮想データセンターのために、より高いスループットの購入を希望する場合、サービスプロバイダは、ハードウェアを修正することなく、利用可能なスループットを修正し得る。

示されている実施形態において、各ホストノード９２０は、第１テナントに関連する１つの仮想マシンと、第２テナントに関連する１つの仮想マシンをホストする。サービスプロバイダは、仮想ネットワークトポロジを使用して、物理ネットワークハードウェアを再構成することなく、利用可能な複数のホストノードの間でテナント仮想マシンを再割り当てし得る。分散状態システム内に記憶された仮想ネットワークトポロジは、システムを動的に再構成することを可能にする。

別の実施形態において、複数のテナント仮想ルータの各々は、少なくとも１つのパブリックＩＰアドレスを公開するように構成され得て、複数のエッジノードのうちの１つまたは複数を通して外部ネットワークにアクセスするように構成され得る。各テナント仮想データセンターが、複数のエッジノードを通して外部ネットワークへアクセスすることを可能にすることで、単一のエッジノードの障害が、ネットワーク内で動作するテナントのサービスの利用可能性に干渉しにくくなる。

［仮想ネットワーク内のフロー状態のＰ２Ｐ設定］

上述のように、汎用システムアーキテクチャは、共有データベースを利用して、下位ネットワーク上にオーバーレイされた仮想ネットワークのためのパケットルーティングをサポートする情報を記憶する。したがって、重大なＩ／Ｏオーバーヘッドが発生し得る。

説明の目的で、第４層の負荷分散は、汎用システムアーキテクチャに関連して上述したものと同様のＮＡＴ実装を利用し得る。この実装において、ＮＡＴテーブルは、別個のルータ間での衝突を回避するべく、単一の仮想デバイスに属する。別個のＮＡＴテーブルは、各負荷分散装置が、負荷分散装置とルータとの間の衝突を更に回避するように利用される。したがって、新しいパケットがルータに到達すると、以下の段階が発生する。
１．ルータが、取り付けられたアクティブ状態の負荷分散装置を有する場合、受信パケットが負荷分散装置のアクティブなＶＩＰのいずれかにマッチするかどうかチェックする。
２．パケットがＶＩＰにマッチする場合、ＶＩＰのためのプールを取得し、有効（ａｄｍｉｎＳｔａｔｅＵｐ＝＝ｔｒｕｅ）かつ健康（ｓｔａｔｕｓ＝＝ＵＰ）なプールメンバーを有するかどうかチェックする。 ３．このＶＩＰに対する、パケットの（ｓｒｃ ｉｐ／ｓｒｃ ｐｏｒｔ）のための既存のＮＡＴエントリを有し、バックエンドがまだ健康である場合、このＮＡＴエントリを使用する。 ４．それ以外の場合、アクティブなプールメンバーの重みを考慮して、アクティブなプールメンバーの１つをランダムに選択する。 ５．受信トラフィックから関連バックエンドへの送信先ＮＡＴ（バックエンドのＩＰおよびポートを、パケットの送信先ＩＰポートフィールドとして設定する）。

バックエンドが無効化される例において、そのバックエンドへの既存のＴＣＰ接続は、完了させることができる。しかしながら、そのバックエンドとの新しい接続は確立されない。例えば、この挙動を実装するべく、バックエンドが無効化されている（ａｄｍｉｎＳｔａｔｅＵｐ＝＝ｆａｌｓｅ）がまだ健康（ｓｔａｔｕｓ＝＝ＵＰ）な場合、段階３において、既存のＮＡＴエントリが尊重される。

スティッキーな送信元ＩＰは、通常の負荷分散と同様に実装される。（例えば、Ｃａｓｓａｎｄｒａまたは他の適切な分散型データベース管理システムで実装された）共有データベース内の通常のＮＡＴエントリのためのキーは、以下の通りである。
＜ｓｒｃ ｉｐ＞｜＜ｓｒｃ ｐｏｒｔ＞｜＜ｄｓｔ ｐｏｒｔ＞｜＜ｄｓｔ ｐｏｒｔ＞
しかしながら、スティッキーな送信元ＩＰについては、単一の送信元ＩＰからＶＩＰへの任意の受信トラフィックは、同一のバックエンドＩＰ／ポートへ送信されるので、クライアントの送信元ポートは無関係である。これを考慮すると、ｓｒｃ ｐｏｒｔ値０（すなわち、そうでなければ未使用）が、スティッキーな送信元ＩＰエントリに利用される。したがって、それらのエントリのキーは、以下のようになる。
＜ｓｒｃ ｉｐ＞｜０｜＜ｄｓｔ ｐｏｒｔ＞｜＜ｄｓｔ ｐｏｒｔ＞

このようにスティッキーな送信元ＩＰを実装することで共有データベース（例えば、Ｃａｓｓａｎｄｒａが考えられるが、他のシステムも考えられる）への往復回数の低減を提供する。すべての新しいＴＣＰ接続について、１つの通常ＮＡＴエントリを維持すること（および、クライアントＩＰ→バックエンドのスティッキーなマッピングを別個にトラッキングし続けること）は可能であるが、これは、共有データベースへの問い合わせの増加に起因して、費用の増大を発生させる。

ＶＩＰがスティッキーとしてマークされているときの負荷分散フロー（ｓｅｓｓｉｏｎＰｅｒｓｉｓｔｅｎｃｅ＝＝ＳＯＵＲＣＥ＿ＩＰ）は、通常の負荷分散フローと同様である。つまり、このＶＩＰに対するｓｒｃ ＩＰ（ｓｒｃ ｉｐ／０）の既存のＮＡＴエントリが存在し、かつ、バックエンドがまだ健康かつ有効である場合、既存のＮＡＴエントリが利用される。それ以外の場合、アクティブなプールメンバーは、アクティブなプールメンバーの重みを考慮して、ランダムに選択される。バックエンドのＩＰおよびポートがパケットの送信先ＩＰ／ポートフィールドとして設定されるように、関連するバックエンドへの受信トラフィック上で送信先ＮＡＴ（ＤＮＡＴ）が採用され得る。この例において、ＮＡＴエントリのキーは、（ｓｒｃ ＩＰ／０）である。

例として、スティッキーな送信元ＩＰのモードにおいて、バックエンドが無効化されているが（ａｄｍｉｎＳｔａｔｅＵｐ＝＝ｆａｌｓｅ）、まだ健康な場合、既存のＮＡＴエントリは維持されない。概して、スティッキーなエントリは、より長いタイムアウトを有し、したがって、現在のＴＣＰ接続の最後でタイムアウトし得ない。

トラフィックが負荷分散装置を介して、バックエンド（プールメンバー）から流れ戻るとき、（ｓｒｃ ｉｐ／ｓｒｃ ｐｏｒｔ）をＶＩＰ ＩＰ／ポートに置き換えるべく、ＤＮＡＴの逆引きが実行される。通常エントリのための逆ＮＡＴエントリを検索するとき、（ｄｅｓｔ ｉｐ／ｄｅｓｔ ｐｏｒｔ）がキーとして使用される。スティッキーな送信元ＩＰエントリの場合、（ｄｅｓｔ ｉｐ／０）がキーとして利用される。負荷分散装置がスティッキーなＶＩＰのみ、または、通常のＶＩＰのみを有する場合、検索は１回のみ実行される。しかしながら、負荷分散装置が両方を有する場合、検索は２回実行される。

ある態様によると、各ルータは、一連のルールをルータに入るトラフィックに適用するインバウントフィルタと、一連のルールをルータから出るトラフィックに適用するアウトバウンドフィルタとを有する。通常の使用事例において、送信元ＮＡＴルールは、これら一連のルール内に（例えば、ＯｐｅｎＳｔａｃｋプラグインによって）インストールされる。したがって、負荷分散が利用され、フィルタルールが有効にされている場合、ＤＮＡＴおよび送信元ＮＡＴ（ＳＮＡＴ）の両方が発生し、その結果、トラフィックの不正確なルーティングが生じる。したがって、負荷分散（ＤＮＡＴ）が有効である場合、インバウントフィルタはスキップされ、逆負荷分散（逆ＤＮＡＴ、すなわち、プールメンバーからのリターントラフィック）が有効である場合、アウトバウンドフィルタはスキップされる。

受信パケットの送信先ＩＰが再書き込みされるように、第４層負荷分散は、「ルーティングモード」で動作し得る。このモードは、バックエンドサーバが、クライアントの実際のＩＰアドレスおよびポートを送信元として見ることを可能にする。他の多くの負荷分散モードにおいて、バックエンドサーバは、負荷分散装置のＩＰを送信元ＩＰとして見る。したがって、元のクライアントＩＰを検出するための他の機構（例えば、ＨＴＴＰ Ｘ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒヘッダ）が採用される。

接続トラッキングおよび動的ＮＡＴ（ＳＮＡＴ／Ｌ４ＬＢ）は、接続内のパケットを関連付ける機能である。接続は、反対方向に通過するパケットを有する。つまり、異なるホストが関与する。したがって、パケットを関連付ける状態は、それらのホストの間で共有される必要がある。例えば、上述の汎用システムアーキテクチャにおいて、状態は共有データベース内に記憶される。例えば、フローエントリは、フォワードフローシミュレーションによって書き込まれ、リターンフローシミュレーションによって読み込まれる。

一態様において、フォワードフローシミュレーション中の書き込みは、非同期に、ファイアアンドフォーゲット方式で実施される。これにより、リターンフローがシミュレートされえいるときに、状態がまだ共有データベース（例えばＣａｓｓａｎｄｒａ）内に無い可能性が存在する。したがって、リターンフローからのいくつかのパケットはドロップされ得るが、これは、ネットワークの通常の挙動に似ている。また、リターンフローシミュレーション中に実行される読み込みは、シミュレーションのレイテンシを増大させる。これは、効率的にスケジュールされる完全に連続的なシミュレーションを妨げる。

これを考慮して、すべてのステートフルなＬ４の処理が物理ホストのコールオフを決して行うことなく実行されるように、上述の汎用システムアーキテクチャが修正され得る。この結果、Ｌ２、Ｌ３、Ｌ４ステートレスフローと同様の、ユーザに見えるレイテンシおよびスループットが生じる。以下で詳細に説明するが、クラスタコンポーネントは、ホスト（例えばノード）上のソフトウェアエージェントのパケット処理高速経路から除去され、クラスタから切り離されている間にエージェントがステートフルな処理を実行することを可能にする。したがって、エージェント内のパケット処理は、１００％同期およびノンブロッキングであり得る。

更に図示するべく、上述の汎用システムアーキテクチャによると、ＮＡＴ状態および接続状態は、外部システム（すなわち、共有データベースシステム）全体で共有される。外部システムへの呼び出しは、フォワードフローをシミュレートするホスト（本明細書では入口ホストと呼ぶ）に、フローのシミュレーションを発生させるパケットが送信される前に、この情報を出口ホストへトンネリングさせることによって回避できる。情報は、帯域内で、または、制御ネットワークを介して、送信され得る。２つの経路（制御経路およびデータ経路）が存在する場合、制御パケットの前に、第１データパケットが到達するというリスクがいくらか存在する。しかしながら、ＶＭ宛てのトラフィックの場合、通常、下位の非対称ルーティングが存在しない。ゲートウェイノードを通過するトラフィックの場合、ステートフルなポートグループが導入され得る。したがって、ステートフルなデータがホストへプッシュされるとき、データは、同一のステートフルなポートグループのメンバーであるポートを有するすべてのホストへプッシュされる。例示的な展開（Ｏｐｅｎｓｔａｃｋシステムなど）において、ゲートウェイホストを含む、そのようなグループは、１つのみ存在し得る。

ＮＡＴ変換については、データストアは、現在使用されているポートを保持するのに使用され得る。しかしながら、外部システムへの呼び出しは、各ホストに、（例えば、計算ノード上でホストされているＶＭの量に基づいて）いくらかの量のポートを事前確保させることによって回避できる。したがって、データストアへの往復は、追加バッチをフェッチする、または返すためだけに発生する。代替的に、衝突の頻度が少ないことが期待されているので、調整の無い、ランダムなポートを選択できる。

ＶＭマイグレーションに対処するべく、シミュレーション経路と非同期的に、いくつかのＬ４メタデータが共有データベース（例えば、Ｃａｓｓａｎｄｒａ）に書き込まれ得る。これにより、ホストが新しいポートバインディングを検出したとき、共有データベースに問い合わせでき、（ＶＭマイグレーションの場合、空でないことがあり得る）そのポートに関連するマッピングをシード（ｓｅｅｄ）できることを確実にする。追加的に、新しいホストが入口ホストに通知することを可能にするように、メタデータが拡張され得て、それにより、フォワードフローを古い出口ホストに向かわせる任意のフローを無効化する。

本明細書に記載のメタデータメッセージは、信頼できる、または、信頼できないプロトコルのいずれかを使用して配信され得る。ホストツーホストの交換については、ＡＣＫ（確認応答）および再試行ポリシーが導入され得る。ポートグループのマルチキャストについては、グループ通信プロトコル（すなわち、ゴシップなど）に加えて、または、代替的に、共有データベースの周期的ポーリングが発生し得る。

上述のピアツーピアのメタデータ交換により達成される改善を更に示すべく、以前の汎用システムアーキテクチャの汎用プロセスと、様々なシナリオにＰ２Ｐメタデータ交換を利用する処理との間での例示的な比較を以下に示す。

これらの仮定において、ネットワークノードの例示的な非限定的実施形態、および、それにより実行される処理が説明されている。ネットワークノードは、非一時的なコンピュータ可読記憶媒体（例えば、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、フラッシュメモリ、磁気メモリ（不揮発性：ハードディスク、他の永続的記憶媒体、揮発性：ＭＲＡＭなど）、または、コンピュータ可読データおよび命令の記憶および読み出しが可能な、実質的に任意の他の形態の記憶媒体）に接続されているコンピュータプロセッサを含むコンピューティングデバイスであり得る。コンピュータ可読記憶媒体は、本明細書に記載されている機能およびアクションを実行するようプロセッサを構成するべく、コンピュータプロセッサが実行可能なコンピュータ実行可能命令を記憶できる。例えば、コンピュータ可読記憶媒体は、少なくとも、仮想ネットワークを使用することでパケットを処理し、パケットをルーティングするよう構成されたエージェントと、ポート／アドレスの対についてのパケット変換を選択および管理するよう構成されたＮＡＴリースマネージャモジュールと、状態情報を問い合わせる、および／または、読み出すよう構成されたパケットコンテクストモジュールと、状態情報を、分散型データベース管理システムなどの共有データベース（例えば、Ｃａｓｓａｎｄｒａまたは同様の実装）に記憶するよう構成されたコーディネータモジュールとのためのコンピュータ実行可能命令を記憶し得る。コンピュータ可読記憶媒体は更に、作業用データおよびメタデータ、状態情報、構成情報などのコンピュータ可読データを記憶し得る。

動的な送信元のＮＡＴを伴う、第１の例示的シナリオによると、汎用システムアーキテクチャによって実行される一般的な方法は、入口ホストが受信（転送）パケットを受信するときの、共有データベースに対する、２つの書き込み動作、および、１つの読み込み動作を伴う。具体的には、実行される一般的方法は、ホストでパケットを受信する段階、および、処理のためにパケットをエージェントへルーティングする段階を伴う。この例において、エージェントは、パケットがＮＡＴルールにマッチすることを判定する。それに応じて、エージェントは、ＮＡＴリースマネージャモジュールによって、ＮＡＴエントリを割り当てる。ＮＡＴリースマネージャモジュールは、フリーかつ利用可能と考えられるポート／アドレスを選択する。ポート／アドレスがフリーであることを検証するべく、ＮＡＴリースマネージャモジュールは、共有データベースに対して、検索動作（例えば、読み込み動作）を実行する。フリーである場合、ＮＡＴリースマネージャモジュールは、同一のフローに属する後続パケットのための接続フローのフォワードキーおよびリバースキーを記憶する。これにより、共有データベースに対する２つの書き込み動作が生じる。このように単純化されたプロセスの説明において、エージェントが、ＮＡＴリースマネージャモジュールによって生成された転送キーにしたがってパケットを修正し、上述の仮想ネットワークを使用してパケットをルーティングするとき、パケットの取り扱いが完了する。フローがキーを参照する限り、ホストは周期的に更新する。例えば、失効期間が６０秒である場合、フローがキーを参照し続ける限り、ホストは３０秒おきに更新し得る。

対応するリバースフローの場合、出口ホストが、出口ホストに関連する物理ホスト上でホストされる仮想マシン（ＶＭ）からリターンパケットを受信するとき、汎用システムアーキテクチャの汎用プロセスが開始する。リターンプロセスまたはリバースフローは、接続（例えば、ＴＣＰ接続）のトラフィックを返すリターントンネルを確立し、その結果、共有データベースに対する２つの読み込み動作が生じる。パケットは、出口ホストによって受信されると、出口ホストのコンピュータプロセッサによって実行されるエージェントへルーティングされる。エージェントは、パケットが逆ＮＡＴルールにマッチすることを判定する。それに応じて、ＮＡＴ逆検索がＮＡＴリースマネージャモジュールによって実行され、実施される。フォワード方向のためのＮＡＴエントリが作成され、共有データベース内に記憶されると、ＮＡＴリースマネージャモジュールはこのエントリを検出し、読み出す。その間、出口ホストのＮＡＴリースマネージャモジュールは、フォワードキーおよびリバースキー上で、タッチ（ｔｏｕｃｈ）を実行する。そのようなタッチは、キーを更新する（すなわち、フローへの参照、または、フローによる利用継続をシグナリングにより伝える）。したがって、エントリを読み出す（例えば、フォワードキーおよびリバースキーを読み出す）とき、２つの読み込み動作が共有データベースへ送信される。エージェントは、パケットを処理するべく、ＮＡＴエントリを逆にする。例えば、入口ノードのエージェントでは、フォワード方向のパケットの送信先アドレスを修正し、出口ノードのエージェントでは、対応する、しかし、逆の方式で、送信元アドレスを修正する。

接続トラッキングを伴う第２の例示的シナリオにおいて、共有データベースを利用する汎用システムアーキテクチャによって実行される汎用プロセスは、フォワード方向のパケットの１つの読み込み動作、および、１つの書き込み動作を伴う。具体的には、パケットは、入口ホストによって受信され、その上で実行されるエージェントへルーティングされる。エージェントは、パケットがルールにマッチすることを判定し、ルールはエージェントに対し、パケットがフォワードフローに対応しているかどうかについてチェックを実行するよう指示する。パケットコンテクストモジュールは、共有データベース内の接続トラッキングキーを問い合わせる。この例において、キーは見つからない。エージェントは、パケットのためのフォワードフローシミュレーションを実行し、コーディネータモジュールは、新しい接続トラッキングキーを共有データベースへ書き込む。

リターンパケットについては、読み込み動作は１回実行される。具体的には、パケットは出口ノードによって受信され、その上で実行するエージェントへルーティングされる。エージェントは、やはり接続トラッキングを必要とするルールにパケットがマッチしていると判定する。パケットコンテクストモジュールは共有データベースに対し、接続トラッキングキーを問い合わせ、この状況においては、それを見つける。

ここで、比較のため、Ｐ２Ｐメタデータ交換の利用に関連して上述のシナリオを説明する。上述のように、メタデータ交換は、共有データベースへの依存を低減し、したがって、Ｉ／Ｏに関連する費用を回避する。比較を分かり易く示すべく、以下に説明する例は、対称的なルーティングを有する状況へと単純化されている。

動的ＳＮＡＴシナリオにおいて、フォワードパケットの処理は、共有データベースへのいかなる読み込みまたは書き込み動作も始動しない。つまり、フォワードパケットの処理は、読み込み／書き込み動作を実行するべく停止しない。なぜなら、共有データベースへの任意の補助的な呼び出しは、非同期的に、かつ、パケット処理と無関係に発生するからである。例えば、入口ノードがローカルで利用可能なマッピングのプールを作成するべく、入口ノードのＮＡＴリースマネージャモジュールは、ポートのブロックを共有データベース内に事前確保する。ＮＡＴリースマネージャは、プールを監視し得て、プールが枯渇しそうなとき、別のブロックを確保し得る。これらの読み込み動作は、パケット処理とは無関係であり、入口ノードのスローパスステートフル機能を形成する。

パケットが入口ノードによって受信され、対応するエージェントが、ＮＡＴルールにマッチしていると判定したとき、ＮＡＴリースマネージャは、ローカルで利用可能なマッピングを選択する。マッピングはフロー状態内に記憶され、フロー状態は、ローカルＮＡＴマッピングテーブルに書き込まれる。エージェントは、選択されたＮＡＴ情報に応じて、パケットを修正する。次に、メタデータ交換が発生し得る。具体的には、エージェントは制御パケットを生成し、制御パケットを出口ノードへトンネリングする。制御パケットは、選択されたマッピングを含む。出口ノードは、制御パケットを受信するとき、関連するローカルＮＡＴマッピングテーブルにマッピングを書き込む。修正されたフォワードパケットは、出口ホストへトンネリングされる。例によると、入口ノードは、ハッシュテーブルデータ構造内にマッピングを維持し得る。検索および失効は、共有データベースに関連して利用されるのと同様のポリシーに従って、ただし、ローカルレベルで実行され得る。

リターンパケットについては、処理は更に、共有データベースに対するいかなる読み込みまたは書き込み動作も生じさせない。ここで、パケットは出口ノードによって受信され、エージェントは、パケットが逆ＮＡＴルールにマッチすることを判定する。ＮＡＴリースマネージャモジュールは、マッピングのローカルテーブルに問い合わせ、制御パケットの結果として以前に記憶されたマッピングを読み出す。パケットは、フォワード方向と逆の方式で修正され、入口ノードへトンネリングされる。

一態様において、キーの更新を実行するべく、入口および出口ノードは、周期的に制御パケットを交換し得る。代替的に、テーブル内のマッピングの失効時間は、時期尚早の接続切断を回避するべく、適切な長さになり得る。

ＮＡＴシナリオと同様に、フォワードパケットの接続トラッキングは、共有データベースにいかなるＩ／Ｏ費用も生じさせない。パケットは、入口ホストで受信され、エージェントは、ルールがマッチすることを判定する。ローカルトラッキングテーブルは、対応する接続トラッキングキーについて、問い合わせを受ける。この例において、問い合わせが失敗し、新しいエントリがテーブルに書き込まれる。ＮＡＴシナリオと同様に、エージェントは、制御パケットを生成し、制御パケットを出口ノードへトンネリングする。制御パケットは、トラッキングキーを含む。出口ノードは、制御パケットを受信すると、関連するローカルトラッキングテーブルにキーを書き込む。入口ノードは、パケットを出口ノードへトンネリングする。

リターンパケットについては、パケットは出口ノードによって受信され、エージェントは、ルールがマッチすることを判定する。ローカルトラッキングテーブルは問い合わせを受け、接続トラッキングキーが返される。ここで、上述の制御パケットを受信すると、接続トラッキングキーは、ローカルトラッキングテーブルへ書き込まれる。したがって、リターンパケットのための接続トラッキングも、共有データベースに関連するＩ／Ｏ費用を発生させない。

上述の汎用システムアーキテクチャへの修正を表す上の説明より、様々な機能は明らかである。

第１の１つまたは複数の関連データ構造（例えばテーブル）は、各ノードのローカルＬ４状態を保持する。これらの構造は、状態の種類（例えば、ＮＡＴマッピングおよび接続トラッキングのメタデータ）によって区分され得て、ポートの組ごとにインデックスを付与され得る。ポートの組は、入口ポート、すべての出口ポート、および、同一のステートフルなポートグループのメンバーを含み得る。テーブルは、シミュレーション全体を通して、アクセス可能でなくてはならない。なぜなら、テーブル上での動作は、共有データベースへの読み込み／書き込み動作に置き換わるからである。このテーブルに関連して、テーブルに書き込まれ、ピア全体にわたって分配される新しいエントリを保持するための保持機構が提供される。

次に、ＮＡＴマッピングについて、ランダムなターゲットマッピングが生成される必要がある。共有データベースは、マッピングと無関係に、または非同期的に、調整のために、または、マッピングのブロックの確保のために利用され得る。

別の機能は、第４層状態の分散である。例えば、ステートフルなテーブルエントリをローカルで生成したパケットを送出するとき、エージェントは、エントリを出口ホストへトンネリングする。出口ホストはメタデータを受信するとき、それを出口ポートに関連するテーブル内に書き込む。例において、トンネルキーの特定ビットは、ペイロード内の明示的なメタデータ情報を送信するのではなく、接続トラッキングの信号を送るべく設定され得る。

それに関連する別の態様は、ポートグループをサポートする。メタデータメッセージは、ポートグループ（例えば、（ポート、ホスト）ペアの組）内のピアへ送信される。ポートグループは、仮想要素の物理要素へのマッピングの構成内容に従って管理される。共有される必要がある状態情報を導入するシミュレーションを完了したとき（および、この状態情報を含むメタデータメッセージを出口ホストへ送信するとき）、出口および／または入口ポートがポートグループの一部であるかどうか判定する。一部である場合、状態情報も、ポートグループ内の異なるホストへプッシュされる。メタデータは、特定のトンネルキーを使用してトンネリングされ得るか、または、ＵＤＰメッセージであり得る。

仮想ネットワーク、仮想デバイス、オーバーレイマッピングなどの構成を可能にするアプリケーションプログラムインタフェース（ＡＰＩ）が、汎用システムアーキテクチャによって提供される。ＡＰＩは、ポートグループ構成のためのエンドポイントを有し、構成を、分散構成サービス（例えばＺｏｏｋｅｅｐｅｒ）に書き込む。エージェントは、ローカルポートが属するグループへの変更を監視し、それに応じて、ローカルのメモリ内データ構造を更新する。

仮想マシン（ＶＭ）マイグレーションがサポートされている。すべてのポート範囲のデータ構造の複製は、共有データベース内で保持され得る。したがって、これは、接続トラッキング設定およびＮＡＴマッピングを共有データベースへ非同期的に、シミュレーション経路の外で書き込むことを伴う。効率的な問い合わせを可能にするべく、エントリは、入口ポートおよび出口ポートの両方によってインデックスを付与され得る。新しいポートバインディングを検出すると、ホストは、そのポートによってインデックスを付与されたデータ構造について、共有データベースに問い合わせを行う。空でない場合、ホストは、問い合わせによって返されたデータによって、ポートの接続トラッキング設定、および、ＮＡＴマッピングをシードする。

更に、入口ホストフローの無効化も提供される。新しいポートバインディングを検出すると、ホストは、ポートによってインデックスを付与されたデータ構造について、共有データベースに問い合わせを行う。空でない場合、そのポートをバインドした以前のホストにトラフィックを送信する、インストールされたフローを有し得るすべてのピアについて、現在のホストは、ピアがそれらのフローを無効化できるように、メッセージを送信する。

上述の汎用システムアーキテクチャに従って、各物理ホスト上でプロセッサによって実行されるエージェントは、共有データベース（例えば、Ｃａｓｓａｎｄｒａなどの分散データ管理システム）内に記憶される、フローごとのＬ４状態を提供する。エージェントは通常、パケットをシミュレートしながら、トポロジの一部が状態情報を必要とするたびに、共有データベースに問い合わせを行う。更に、共有データベースへの書き込みはまた、シミュレーションに合わせて、ブロッキング方式で発生する。

一般的に、わずかなホストしか、状態情報の特定の部分に関与したことがない。更に、それらのホストは、あらかじめ判定され得る。共有データベースに問い合わせることなくフローを処理できるように、メモリ内にできるだけ多くのデータを維持するべく、ピアツーピアのメタデータ交換が利用される。したがって、エージェントが状態情報の一部を作成するとき、エージェントは、あらかじめ知られているホストの他のエージェントへ情報をプッシュする。これらのホストは、リターンフローをシミュレートするか、または、発信元と異なるホストを通って入ってくるフォワードフローを処理するべく、状態情報を利用し得る。

メタデータ交換によって、外部システムに依存することなく、ステートフルな第４層処理がローカルで実行される。したがって、Ｌ２、Ｌ３、またはＬ４のステートレスなフローと同様の、ユーザに見えるレイテンシ、および、スループットが生じる。更に、クラスタコンポーネント（例えば、共有データベースのコンポーネント）は、エージェントのパケット処理高速経路から除去できる。これにより、クラスタから切り離されている間でも、エージェントによるステートフルな処理が可能になる。更に、パケット処理は、１００％同期およびノンブロッキングになる。

切り離されたパケット処理によって、共有データベースのクラスタは、パケット処理高速経路に直接加わらなくなる。共有データベースは、ポートマイグレーションのキーのためのバックアップとして利用される。改善されたシステムは、他の要件のいずれかのためのソリューションについて、それに依存しない。これにより、ステートレスな処理と比較して、レイテンシに違いが無い。これは、この設計の主な利点である。ただし、他の利点も存在する。その結果、第４層のフロー処理のレイテンシは、ステートレスなパケット処理と同様である必要がある。更に、汎用システムアーキテクチャと同一の特性を提供するべく、ＮＡＴリースが継続する。システムは、異なるホスト上で同時に処理されるフローについても、キーの衝突が無いという保証を可能にする。例えば、衝突を考慮しないダミーのランダムリースマネージャが利用され得る。リースマネージャは、ローカルであり、その状態を維持する。ｓｏｕｒｃｅ−ｐｏｒｔ：ｓｏｕｒｃｅ−ｉｐ：ｄｅｓｔ−ｉｐ：ｄｅｓｔ−ｐｏｒｔ ｑｕａｄ−ｔｕｐｌｅのすべての要素は、衝突の一部である必要があるので、衝突の可能性は低い。別の例において、ＮＡＴリースマネージャモジュールは、以下のように構成され得る。リースが初めて要求されるとき、シミュレーションは取り消されるか、または、保留される。ＮＡＴリースマネージャモジュールは、ＩＰ／ポートのグループを共有データベースから確保する。必要に応じて（すなわち、予備が枯渇したとき）、追加の確保が行われ得る。確保後、リースがローカルで利用可能になると、割り当ては即時かつ純粋にローカルになる（すなわち、外部システムへの呼び出しが無い）。確保されたリースは、利用率ゼロの時間間隔後、返され得る（すなわち、確保解除）。

状態情報のインスタンスが失効すると、出口ホストにおけるリターンフローは、一定期間後に消える。汎用システムアーキテクチャについては、そのようなフローは、時間固定の失効を有し、再シミュレーションは、共有データベース内にデータを見つけない。保証を順守するべく、出口ホストは、トポロジの変更または他の状態失効イベント後、一定時間内に収束する必要がある。

すべてのフローは、参照された状態（例えば、ＮＡＴまたは接続トラッキング）キーでタグ付けされている。キーを所有するホストは、キーが除去されるときに、削除状態メッセージをプッシュする。すべてのホストは、キーを削除すると、タグとしてキーを使用するフローを無効化する。概して、関連する参照カウントがゼロになるまで、キーは失効しない。しかしながら、所有者ホストが削除を要求したためキーが削除される場合、関連するフローは即時に無効化される。

一実施形態において、ファイアアンドフォーゲット状態プッシュメッセージは、ホスト間で交換される。未配信メッセージにより、切断の接続が生じるので、高いパケット損失率を有する下位ネットワークで、信頼できる配信プロトコルが利用され得る。説明のため、ＳＹＮを受信し、パケットを送出し、フローをインストールし、状態情報をプッシュする入口ノードを検討する。出口ノードへの状態情報がドロップされる（例えば、配信されない）場合、リターンパケットは状態情報にマッチせず、ドロップフローが作成される。ＳＹＮパケット配信のための再試行回数は、エージェントを実行するノードにインストールされているオペレーティングシステムに応じて変化する。時折切断する接続に耐える以外に、ＡＣＫベースのプロトコルを導入できる。入口ノードは、送出されるすべての状態プッシュメッセージ（例えば、状態情報）について、ＡＣＫを待ち、トラッキングする。ＡＣＫが受信されない場合、状態情報は再送信される。上述のように、フローは関連するキーでタグ付けされる。失われた状態情報については、フローはヌル値でタグ付けされる。状態情報を再送信し、受信が成功した後、出口ノードは、キーがローカルの状態テーブルにとって新しいことを認識する。したがって、ヌル値でタグ付けされたすべてのフローは無効化される。リターンフローは、状態情報によって、適切に発生し、それにより、接続を回復する。別の例において、状態情報をプッシュするのに、ＴＣＰトランスポートが利用され得る。上述のヌルタグおよび無効化技術だけでなく、接続マネージャが利用される。

非対称ルーティングにより、リターンフローは、元の出口ホストと異なる１つのホストまたは複数のホストを通して、クラウドへ入り得る。これらのホストのすべては、リターンフローを正確に計算するべく、関連状態を認識する必要がある。上述のステートフルなポートグループは、非対称ルーティングの状況に対処する。

ポートが移動するとき、接続を切断しないように、関連する状態情報も移動する。ポートの移動後、ポートを所有していなかったが、そのポート宛てのフローがあったホストは、任意の関連するフローを無効化する。

状態情報の失効は、キーを所有するホストがキーの更新を中止した時間から、ある時間間隔後に、自然に発生する。キーを参照していたすべてのフローが除去されたとき、キーの更新が停止する。

フローごとの状態のキーのレプリケーションを可能にするべく、少なくとも４種類のホストが、特定のフローに関連する状態のローカルコピーを保持する。すなわち、入口ホストと、出口ホストと、入口ポートと同一のポートグループ内のポートを所有するホスト（複数の入口ホストと総称）と、出口ポートと同一のポートグループ内のポートを所有するホスト（複数の出口ホストと総称）である。

フローに参加しているホストは、フローの状態への強い参照、または弱い参照のいずれかを有し得る。入口ホストは、フロー状態への強い参照を行う。つまり、状態の参照カウントに寄与する。参照する入口ホストが無いとき、分散システムから、状態の特定の部分が除去され得る。出口ホストは、状態を参照しないが、参照カウントにカウントされない。セキュリティ上の理由から、フローに影響を及ぼす、トポロジ内の変化に対し、入口ホストのみが応答するので、出口ホストは観察主体のままであり続ける。

ホスト間での調整を回避するべく、いくつかの強い参照が、弱い参照へ変換される。入口ホストは、２つのグループ、すなわち、（１）発信元と呼ばれる、特定のキーを生成したホスト、および、（２）残りの入口ホストに分けられる。非発信元ホストは、出口ホストのように挙動し、強い参照ではなく、弱い参照を保持する。したがって、２種類の参加者、すなわち、発信元およびその他すべてが存在する。ここで、その他すべては、受信ホストと呼ばれる。受信ホストは、すべての非発信元ホスト、および、すべての出口ホストを含む。

これらの指定に基づいて、各種類の異なる担当が、異なるイベントに関連して説明される。キー作成時間において、発信元ホストは、キーをすべての受信ホストへプッシュして、ポート→キー→ピアの２レベルのマッピング内において、プッシュされた状態情報をトラッキングする。キー作成時間において、受信ホストはキーをインストールして、参照カウントを１に設定し、送信者→キー、および、ｉｎｇｒｅｓｓＰｏｒｔ→キーの関連を維持し、送信者がオフラインか、ポートが送信者に属していないか、送信者のエポック（ｅｐｏｃｈ）が古すぎる場合、参照カウントをゼロに設定する。

キーにヒットするフローがシミュレートされるとき（例えば、入口ポートを有するキーが発信元ホストに所有されている）、発信元ホストは、参加者を再計算し、キーを再度プッシュする。例えば、関与するホストのリストは、キーが初めてプッシュされたホストのリストと、キーが２回目にプッシュされたリストを組み合わせたものである。キーのためのローカルの参照カウントがインクリメントされる。ここで、受信ホストは、アクションを行わない。

キーが（例えば、ブートまたはポートバインディング時に）共有データベースから読み出されるとき、発信元ホストは、参照カウントをゼロに設定したキーをインポートする。発信元ホストは、新しいフローがキーにヒットするとき、キーの所有権を主張する。このイベントに応答して、受信ホストは、参照カウントがゼロであるキーをインストールする。

発信元ホストに所有される入口ポートが別のホストへ移動するとき、発信元ホストは、そのポートのキー→ホストの関連を忘れることによって、所有権をドロップする。受信ホストは、参照カウントをゼロに設定する。新しい所有者がトラフィックを受信し、再送信する場合、受信ホストは、続いて参照カウントを１に戻す。発信元ホストがオフラインになったとき、同様のアクションが受信ホストによって行われる。

キーが失効するとき、発信元ホストは、キーをローカルで削除し、キーを受信したホストに削除メッセージをプッシュする。参加しているポートグループにおける３組のポートが変化するとき、または、参加しているポートグループに属するポートがホストを変更するとき、発信元ホストは、そのポートグループを入口または出口として使用して、キーを参照するフローを無効化する。

下に提供されている表１は、様々なイベントについての、上述の担当を要約している。

例示的な非限定的実施形態によると、エージェントは１つまたは複数の物理ホスト上にインストールされる。物理ホストは、下位ネットワークによって接続されるハイパーバイザを実行する。これらのホスト上で動作する仮想マシンは、完全分散型仮想ネットワークデバイス（例えば、ポート、ブリッジ、ルータ、負荷分散装置、ファイアウォールなど）を備えるオーバーレイネットワークによって、相互に接続される。仮想ネットワークデバイスの組は、仮想トポロジと呼ばれる。

物理ホストのエージェントは、デバイスから成る仮想トポロジを構築するべく、ネットワークオーバーレイを実装する。パケットが仮想トポロジに入るとき、ホスト上で動作しているエージェントによってシミュレートされる。このホストは、入口ホストと呼ばれる。パケットは、例えば、外部からクラウドへ入ることで、または、仮想マシンによって送出されることで、仮想トポロジに入り得る。シミュレート後、パケットがドロップされない、または消費されない場合、送信先仮想マシンが存在する出口ホストへ送出される。同一ホスト内に、通信するＶＭが２つ存在するという特定の場合、入口ホストおよび出口ホストは同一である。仮想トポロジのエンドポイント（仮想マシン、ＬＸＣコンテナ、物理インタフェースなど）は、エージェント上で動作している物理ホストにバインドされる仮想ポートとしてモデル化される。これらのバインドは、ポートが異なるホストにバインドされる、仮想マシンマイグレーションなどのイベントの結果、変化し得る。

フローは、送信者から特定の送信先へ移動するパケットの一方向の流れである。フローは、下位のパケットの特徴、すなわちヘッダによって識別できる。反対方向の２つのフローがある接続において、１つのフローは、フォワードフローであり、他方は、リターンフローである。フォワードフローは、接続の発信元である。通常、ホストは制限された数だけフローまたは接続に参加し、この数は接続の期間、ほとんど変化しない。このホストの数は、少なくとも、仮想トポロジを通過するパケットの入口ホストおよび出口ホスト（これらの役割は方向と共に反転する）を含む。フローが別のホストへミラーリングされる場合、または、ミドルボックスを通して迂回される場合、これらのホストもフローに参加する。フローのパケットが仮想トポロジに出入りするときに通ることができるポートが複数存在する場合、下位の非対称ルーティングに起因して、それらのポートのすべてがバインドされるホストも、フローに参加する。

各フローまたは接続は、それらに関連する状態を有する可能性がある。例えば、この状態は、接続トラッキングメタデータ、ＮＡＴマッピング、トラフィック分類メタデータなどであり得る。フローに参加するすべてのホストは、この状態にアクセスできる。例えば、リターンフロー内のパケットを処理するホストは、ＮＡＴを反転し得る。更に、パケットが入るときに通ることができるすべてのホストは、同一の分類のメタデータにアクセスできる必要がある。

大部分のフロー状態は、接続状態である。フロー状態のいくつかの例において、リターンフロー状態は、フォワードフローを処理するホストによって計算され得る。したがって、リターンフロー状態は、利用可能である必要がある。リターンフロー状態は、フォワードフロー状態の存在に従属し、ライフサイクルは、フォワードフロー状態のライフサイクルにマッチする。

パケットの処理中、フローに参加するすべてのホストが知られる。新しいフローの状態情報は、その処理中に生成される。一実装において、実際のデータパケットを送信する前に、新しいフロー状態情報が、１つまたは複数の制御パケットとして、関与しているホストへ通知され得る。上述のように、下位は、制御パケットの無損失配信をサポートするように構成され得る。状態情報は、フローを識別するためのデータを含む。例えば、ＮＡＴ状態情報は、５タプルのフローと、ＮＡＴを適用したデバイスの識別子とを含み得る。

フローに参加しているホストは、フローの状態への強い参照または弱い参照のいずれかを有し得る。入口ホストは、フロー状態への強い参照を行う。つまり、状態の参照カウントに寄与する。参照する入口ホストが無いとき、状態の特定の部分は、分散システムから除去され得る。出口ホストは、状態を参照するが、そのフロー状態のコピーを有する他のホストとは異なり、参照カウントにはカウントされない。

実施形態によると、高度なネットワークサービスは、フローの期間中に順守される、フローごとの判定を行う。例えば、ＩＰｖ４ポートマスカレード（ＮＡＰＴ）は、フリーなパブリックＩＰ：ポートペアを選択して、クラウド内のクライアントからインターネット上のサーバへ送信されたＴＣＰ／ＵＤＰパケット内のプライベートＩＰ：ポートペアを置き換える。従来、このフローごとの状態は、例えば、ネットワークデバイスなど、単一の場所において存続できた。フォワードフローおよびリターンフローの両方は、同一のデバイスを通過して、これにより、ポートマスカレードの場合には逆変換を、ステートフルなファイアウォールの場合には接続状態ベースのフィルタリングを可能にした。

したがって、単一の場所は、単一障害点になる。この懸念を緩和するべく、ネットワークデバイスは、フォールトトレラントのペアの間、または、負荷分散装置のクラスタの間でセッション状態を共有する。

複数ノードにおける、フローごとの状態の共有は、複数の利点を可能にする。例えば、負荷分散およびファイアウォールなどのステートフルなネットワークサービスに到達するべく、中間のハイパーバイザまたはネットワークデバイスへオーバーレイフローを転送することを回避することを可能にする。更に、フローがＬ２およびＬ３ゲートウェイを通過するとき、フローごとの状態を共有することで、非対称のリターン経路をサポートし、ゲートウェイノードのフォールトトレランスを促進する。

上述のように、フローを受信する入口ノード上で実行する、汎用システムアーキテクチャ内のエージェントは、フローがオーバーレイネットワークをどのように通過するかシミュレートすることで、パケットがドロップされるかどうか判定し、または、パケットがオーバーレイネットワークを出る仮想デバイスおよびポートを判定する。エージェントは、出口の仮想ポートを物理ノードにマッピングし、高速経路パターンマッチを確立し、計算された出口ノードへのフローを修正、カプセル化、トンネリングする。汎用システムアーキテクチャの一般的な構成において、分散データベース（例えばＣａｓｓａｎｄｒａ）は、オーバーレイネットワークを通過するフローの計算中に作成または利用される任意のフロー状態を記憶するのに使用された。この状態は、これらの質問に回答し得る。（１）これはフォワードフローか、またはリターンフローか、（２）このＴＣＰ接続は何の状態か、（３）負荷分散装置ＬＢ１はこのフローをどこへ送信する必要があるか、（４）このポートマスカレードインスタンスは、何のパブリック送信元ＩＰｖ４アドレスおよびＴＣＰポートを選択するか、または、（５）このパブリックＩＰｖ４アドレスおよびＴＣＰポートによって、何のプライベート送信元ＩＰｖ４およびＴＣＰポートがマスクされているか。状態情報の他の使用も考えられる。

図９は、共有データベースによるフロー状態管理を示す。新しいフローについては、入口ノード（ノード１）は、フロー状態データベースへ、２回の往復を実行する。１つのデータベースアクセスは、既存の状態をチェックし（すなわち、新しいフローであったかどうか検出し）、他のデータベースアクセスは、新しく作成されたフロー状態を記憶する。

リターンフローについては、リターンフローのための入口ノード（リターン経路が非対称である場合、フォワードフローからのノード２、または、いくつかのノード３のいずれか）は、フロー状態データベースからフロー状態を読み出し、リターンフローを計算し、フローをノード１（または、ことによると、リターン経路がいくつかのＥＣＭＰルートと同じ位置で終端する場合、おそらく、いくつかのノード４）へトンネリングする。

図９は更に、フォワードフローが（上流のＥＣＭＰルーティングが原因で）いくつかのノード４、または、アムニージアック（ａｍｎｅｓｉａｃ）のノード１に入るシナリオを示す。入口ノードは、データベース内でフロー状態を見つけることができ、フローをノード２へトンネリングするべく、フローを正確に計算する。

図１０は、状態プッシュが利用されるとき（すなわち、入口ノードが、ノードの関与する組へ直接的にフロー状態をプッシュするとき）のフロー状態管理およびネットワーク動作を示す。新しいフローの入口ノードは、状態情報へアクセスできる必要があるノードの組（例えば、関与する組）を判定して、それらのノードへ状態情報をプッシュし得る。

ノード１へ入る新しいフローについては、入口ノードは、ローカル状態テーブルへ問い合わせ、フローを新しいフローとして識別する。ノードは、フロー状態が作成され、ローカルに記憶されている間、フロー計算を実行する。ノードは、ノードの関与する組を判定し、その組のノードへフロー状態をプッシュする。図１０に示されているように、関与する組には、ノード１、ノード２、ノード３、ノード４が含まれ、ノード１および４は、フォワードフローの潜在的な入口であり、ノード２および３は、リターンフローの潜在的な入口である。

ノード２に入るリターンフローについては、ノードはフロー状態を読み出すべく、ローカルストアに問い合わせる。リターンフローはその後、ノード１へトンネリングされる。図１０に示されているように、フォワードフローが異なるノード（例えばノード４）に入るとき、入口ノードは、フロー状態を読み出すべくローカルストアに問い合わせ、それに応じてフローをトンネリングする。フロー状態は以前にノード２およびノード４へプッシュされたので、上のシナリオは、共有データベース管理システムへのアクセスを必要としない。

一実施形態において、フロー状態は、パケットが状態情報を含むことを示す特殊な値のトンネルキーを有するトンネルパケットを介して通知される。このパケットは、関連するデータパケットの前に、信頼できない方式（例えば、ファイアアンドフォーゲット）で入口から出口へ送信され得る。しかしながら、上述のように、パケットを送信するのに、信頼できるプロトコルも利用され得る。

関与する組は、事前に知られている様々な情報によって示唆され得る。例えば、上流のルーティングに応じて、プロバイダルータの静的または動的アップリンクのいずれかは、Ｎｏｒｔｈ‐Ｓｏｕｔｈフローを受信し得る。したがって、プロバイダルータのアップリンクは、単一の入口セットに追加される必要がある。同様に、テナントは、オフィスネットワークからテナントルータへの冗長なＬ３ＶＰＮを有し得る。テナントのＶＰＮトラフィックは、１つより多くのノードで、仮想ネットワークに入り得る。

更に、ＶＬＡＮ Ｌ２ゲートウェイは、８０２．１Ｑ仮想ブリッジ内に、２つの物理リンクを可能にする。ＳＴＰに応じて、物理ワークロードからのトラフィックは、８０２．１Ｑブリッジのアップリンクポートのいずれかに入り得る。ＶＸＬＡＮ Ｌ２ゲートウェイは、任意のノードがトラフィックを物理ＶＴＥＰへ直接トンネリングすることを可能にする。トラフィックは、ＶＮＩに関連する、ポートの組／ＶＬＡＮのペアへ転送される。物理ＶＴＥＰは、仮想スイッチ上のトラフィックを、送信先ＭＡＣに対してローカルであるホストへ直接転送する。仮想スイッチ上のトラフィックについては、ＶＴＥＰから来るトラフィックのためのリターン入口セットと共に、ＶＴＥＰ宛てのトラフィックのためのフォワード入口セットのみが考慮される。

ポートマイグレーションは、ＶＭマイグレーションを容易にする。共有データベースのアプローチとは対照的に、状態プッシュでは、新しいノードでのフロー計算は、上述のように機能する。しかしながら、ポートが移動した後の数秒間、フローはローカル状態情報を見つけず、フロー計算は不正確に実行される。しかしながら、新しいノード上でのエージェントは、すべての関連するフロー状態情報をノードからプルする。フロー状態は、入口ポートによってインデックスを付与され（そしてメモリ内で隣接して配置され）、古いノードから新しいノードへ迅速に伝達される。

本明細書で利用されている、「また」という用語は、排他的な「また」ではなく、包括的な「また」を意味することを意図している。つまり、別段の記載が無い限り、または、文脈から明らかである場合を除き、「ＸはＡまたはＢを採用する」という表現は、自然の包括的な任意の順列を意味することが意図されている。つまり、「ＸはＡまたはＢを採用する」という表現は、「ＸはＡを採用する」、「ＸはＢを採用する」、または、「ＸはＡおよびＢの両方を採用する」という例のうち、いずれによっても満たされる。更に、本出願および付属の特許請求の範囲において使用される冠詞「ａ」および「ａｎ」は、別段の記載が無い限り、または、単数形を示すことが文脈から明らかである場合を除き、一般的に、「１つまたは複数」を意味すると解釈されるべきである。

更に、本明細書で使用される「例示的」という用語は、「何らかの説明または例としての役割を持つ」ことを意味することを意図したものである。

例示的な実施形態が本明細書で上述されている。当業者にとって、上述のデバイスおよび方法は、主張される主題の一般的な範囲を逸脱することなく、変更および修正を組み込み得ることは明らかである。主張されている主題の範囲内で、そのような修正および変更のすべてを含めることが意図されている。更に、「含む」という用語が詳細な説明または特許請求の範囲のいずれかにおいて使用されている限り、その用語は、「備える」という用語が請求項において移行句として採用されているときに「備える」という用語が解釈されるのと同様に包括的であることが意図されている。
［項目１］
コンピューティングデバイスであって、
上記コンピューティングデバイスをネットワークへ接続するための通信インタフェースと
非一時的コンピュータ可読記憶媒体に接続されているプロセッサであって、下位ネットワークにオーバーレイする仮想ネットワークを使用してデータパケットをルーティングする仮想ネットワークエージェントのためのコンピュータ実行可能命令を自身に記憶するプロセッサと
を備え、
上記仮想ネットワークエージェントは、上記プロセッサによって実行されるときに、
第１の上記通信インタフェースで受信されたデータパケットに関連する通信フローが新しいフローかどうか判定する段階と、
上記通信フローが新しいフローであると判定されたときに上記通信フローのための状態情報を生成する段階と、
上記通信フローの上記状態情報を含む制御パケットを生成する段階と、
上記制御パケットを、上記通信フローに関連するノードへ送信する段階と、
上記データパケットを上記ノードへ送信する段階と
を実行するように上記プロセッサを構成する、
コンピューティングデバイス。
［項目２］
上記ノードは、上記下位ネットワークを介して上記コンピューティングデバイスに通信可能に接続される第２コンピューティングデバイスである、項目１に記載のコンピューティングデバイス。
［項目３］
上記仮想ネットワークエージェントは更に、上記データパケットから抽出された情報に基づいてローカルデータストアに問い合わせることで、上記通信フローを新しいフローとして識別するようにプロセッサを構成する、項目１または２に記載のコンピューティングデバイス。
［項目４］
抽出された上記情報は、上記データパケットが受信される入口ポートを含む、項目３に記載のコンピューティングデバイス。
［項目５］
上記ローカルデータストアは、上記非一時的コンピュータ可読記憶媒体上に記憶されている関連データ構造を有する、項目３または４に記載のコンピューティングデバイス。
［項目６］
上記仮想ネットワークエージェントは更に、生成された上記状態情報を上記ローカルデータストアへ書き込むように上記プロセッサを構成する、項目３から５のいずれか一項に記載のコンピューティングデバイス。
［項目７］
上記仮想ネットワークエージェントは更に、仮想ネットワークトポロジに基づいて、上記仮想ネットワークを通る上記データパケットの通過をシミュレートするように上記プロセッサを構成する、項目１から４のいずれか一項に記載のコンピューティングデバイス。
［項目８］
上記仮想ネットワークトポロジは、上記仮想ネットワークの仮想ノードのグラフと、上記下位ネットワークの物理ノードに対する、それぞれの仮想ノードのマッピングとを指定する、項目７に記載のコンピューティングデバイス。
［項目９］
上記仮想ネットワークエージェントは更に、
分散型データベース管理システムから上記仮想ネットワークトポロジを読み出す段階と、
上記仮想ネットワークトポロジを上記非一時的コンピュータ可読記憶媒体にローカルでキャッシュする段階と
を実行するように上記プロセッサを構成する、項目７または８に記載のコンピューティングデバイス。
［項目１０］
シミュレートされた上記通過の結果は、上記データパケットをドロップすると判定すること、または、上記ノードが上記仮想ネットワークの出口ノードであると識別することのうち少なくとも１つを含む、項目７から９のいずれか一項に記載のコンピューティングデバイス。
［項目１１］
上記状態情報は、上記データパケットの送信元フィールドまたは送信先フィールドのうち少なくとも１つを修正するネットワークアドレス変換マッピングを含む、項目１に記載のコンピューティングデバイス。
［項目１２］
上記仮想ネットワークエージェントは更に、
上記状態情報を削除する要求を示す第２制御パケットを生成する段階と、
上記第２制御パケットを上記ノードへ送信して上記状態情報の削除を有効にする段階と
を実行するように、上記プロセッサを構成する、項目１または１１に記載のコンピューティングデバイス。
［項目１３］
上記仮想ネットワークエージェントは更に、
上記下位ネットワークの第２ノードから第３制御パケットを受信する段階と、
上記第３制御パケットに含まれる第２状態情報を抽出する段階と、
上記第２状態情報をローカルデータストアへ書き込む段階と
を実行するように、上記プロセッサを構成する、
項目１、１１、または１２のいずれか一項に記載のコンピューティングデバイス。
［項目１４］
上記仮想ネットワークエージェントは更に、
信頼できる配信プロトコルに従って上記制御パケットを送信するように上記プロセッサを構成する、項目１、１１から１３のいずれか一項に記載のコンピューティングデバイス。
［項目１５］
下位ネットワークにオーバーレイする仮想ネットワークでフローをルーティングするためのコンピュータ実行可能命令を自身に記憶する非一時的コンピュータ可読記憶媒体であって、
プロセッサによって実行されたとき、上記プロセッサを、
上記仮想ネットワークのオーバーレイに基づいて上記下位ネットワークを通してルーティングされる通信フローのための状態情報を含む制御パケットを受信する段階と、
上記状態情報をローカルデータストアへ書き込む段階と、
上記通信フローに関連するデータパケットを受信する段階と、
上記ローカルデータストアから上記状態情報を読み出す段階と、
上記状態情報に従って上記データパケットを変換する段階と、
変換された上記データパケットを、上記下位ネットワークのノードへ送信する段階と
を実行するように構成する、ソフトウェアアプリケーションを備える、コンピュータ実行可能命令。
［項目１６］
双方向接続を確立するための、コンピュータ実装方法であって、
仮想ノードおよび物理ノードのグラフを含むネットワークトポロジをネットワークの共有データベース内に記憶する段階と、
上記共有データベースへのアクセスを、複数の物理ノードに提供する段階であって、上記複数の物理ノードは、入口ノードおよび出口ノードを含む、段階と、
上記入口ノードでデータパケットを受信する段階であって、上記データパケットは、送信元フィールドおよび送信先フィールドを含むヘッダを有する、段階と、
上記データパケットを、上記入口ノードによってホストされる、入口ノード判定エンジンと呼ばれる判定エンジンへ提供する段階であって、上記入口ノード判定エンジンは、上記データパケットを少なくとも１つのフィルタリングルールと比較して、フィルタリング結果を生成し、上記フィルタリング結果および上記ネットワークトポロジに基づいて、上記送信先フィールドを入口ノードへ関連付けるためのマッピングを計算し、上記マッピングをローカルマッピングテーブルへ書き込み、上記マッピングを上記データパケットへ適用し、上記マッピングをマッピングパケット内に符号化し、インバウントフローをフローテーブル内に入力し、上記インバウントフローは、同一のフィルタリング結果を生成する複数の後続パケットを、上記入口ノードから上記出口ノードへ向かわせる、段階と、
上記マッピングパケットを上記出口ノードへ送信する段階と、
上記データパケットを上記出口ノードへ送信する段階と
を含む方法。
［項目１７］
上記出口ノードは、上記マッピングパケットを受信し、マッピングを上記出口ノード上のマッピングテーブル内に書き込み、アウトバウンドフローを上記出口ノード上のフローテーブル内に入力する、項目１６に記載の方法。
［項目１８］
上記マッピングは、上記データパケットの上記送信元フィールドおよび上記送信先フィールドのうち少なくとも１つを変更するネットワークアドレス変換マッピングである、項目１６または１７に記載の方法。
［項目１９］
上記判定エンジンは、ネットワークの上記共有データベース内のポートのブロックを確保する、項目１８に記載の方法。
［項目２０］
上記判定エンジンは、ネットワークの上記共有データベースから読み出した上記ネットワークトポロジの部分をローカルにキャッシュする、項目１６から１８のいずれか一項に記載の方法。

Claims (5)

1. 双方向接続を確立するための、コンピュータ実装方法であって、
   仮想ノードおよび物理ノードのグラフを含むネットワークトポロジをネットワークの共有データベース内に記憶する段階と、
   前記共有データベースへのアクセスを、複数の物理ノードに提供する段階であって、前記複数の物理ノードは、入口ノードおよび出口ノードを含む、段階と、
   前記入口ノードでデータパケットを受信する段階であって、前記データパケットは、送信元フィールドおよび送信先フィールドを含むヘッダを有する、段階と、
   前記データパケットを、前記入口ノードによってホストされる、入口ノード判定エンジンと呼ばれる判定エンジンへ提供する段階であって、前記入口ノード判定エンジンは、前記データパケットを少なくとも１つのフィルタリングルールと比較して、フィルタリング結果を生成し、前記フィルタリング結果および前記ネットワークトポロジに基づいて、前記送信先フィールドを入口ノードへ関連付けるためのマッピングを計算し、前記マッピングをローカルマッピングテーブルへ書き込み、前記マッピングを前記データパケットへ適用し、前記マッピングをマッピングパケット内に符号化し、インバウントフローをフローテーブル内に入力し、前記インバウントフローは、同一のフィルタリング結果を生成する複数の後続パケットを、前記入口ノードから前記出口ノードへ向かわせる、段階と、
   前記マッピングパケットを前記出口ノードへ送信する段階と、
   前記データパケットを前記出口ノードへ送信する段階と
   を含む方法。
2. 前記出口ノードは、前記マッピングパケットを受信し、マッピングを前記出口ノード上のマッピングテーブル内に書き込み、アウトバウンドフローを前記出口ノード上のフローテーブル内に入力する、請求項１に記載の方法。
3. 前記マッピングは、前記データパケットの前記送信元フィールドおよび前記送信先フィールドのうち少なくとも１つを変更するネットワークアドレス変換マッピングである、請求項１または２に記載の方法。
4. 前記判定エンジンは、ネットワークの前記共有データベース内のポートのブロックを確保する、請求項３に記載の方法。
5. 前記判定エンジンは、ネットワークの前記共有データベースから読み出した前記ネットワークトポロジの部分をローカルにキャッシュする、請求項１から３のいずれか一項に記載の方法。