特許 7417816 ゲストＶＭモビリティを使用したサービスの提供

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-01-11

(45)【発行日】2024-01-19

(54)【発明の名称】ゲストＶＭモビリティを使用したサービスの提供

(51)【国際特許分類】

   H04L 49/60 20220101AFI20240112BHJP

   G06F 9/455 20180101ALI20240112BHJP

   H04L 41/0895 20220101ALI20240112BHJP

【ＦＩ】

H04L49/60

G06F9/455 150

H04L41/0895

【請求項の数】 12

(21)【出願番号】P 2021546813

(86)(22)【出願日】2020-02-03

(65)【公表番号】

(43)【公表日】2022-04-05

(86)【国際出願番号】 US2020016457

(87)【国際公開番号】W WO2020171937

(87)【国際公開日】2020-08-27

【審査請求日】2021-10-06

(31)【優先権主張番号】16/444,884

(32)【優先日】2019-06-18

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/444,956

(32)【優先日】2019-06-18

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/809,464

(32)【優先日】2019-02-22

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】201941007860

(32)【優先日】2019-02-28

(33)【優先権主張国・地域又は機関】IN

(31)【優先権主張番号】16/444,826

(32)【優先日】2019-06-18

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/444,927

(32)【優先日】2019-06-18

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/445,004

(32)【優先日】2019-06-18

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】514097912

【氏名又は名称】ヴィーエムウェア エルエルシー

【氏名又は名称原語表記】ＶＭｗａｒｅ ＬＬＣ

【住所又は居所原語表記】３４０１ Ｈｉｌｌｖｉｅｗ Ａｖｅ．， Ｐａｌｏ Ａｌｔｏ， ＣＡ ９４３０３， Ｕ．Ｓ．Ａ

(74)【代理人】

【識別番号】100087642

【弁理士】

【氏名又は名称】古谷 聡

(74)【代理人】

【識別番号】100082946

【弁理士】

【氏名又は名称】大西 昭広

(74)【代理人】

【識別番号】100195693

【弁理士】

【氏名又は名称】細井 玲

(74)【代理人】

【識別番号】100203242

【弁理士】

【氏名又は名称】河戸 春樹

(74)【代理人】

【識別番号】100212657

【弁理士】

【氏名又は名称】塚原 一久

(72)【発明者】

【氏名】ミシュラ， ラウル

(72)【発明者】

【氏名】レクイア， キャミール

(72)【発明者】

【氏名】ゴカーレ， サーリ

(72)【発明者】

【氏名】ナイアー， ラジーブ

(72)【発明者】

【氏名】チャルバディ， アヌプレム

(72)【発明者】

【氏名】ピン， ヤン

(72)【発明者】

【氏名】ムンダラギ， カンテシュ

(72)【発明者】

【氏名】ローランド， ピエールンギ

(72)【発明者】

【氏名】ジャイン， ジェヤント

(72)【発明者】

【氏名】コガンティ， ラジュ

【審査官】鈴木 香苗

(56)【参考文献】

【文献】米国特許出願公開第２０１９／０１１６０６３（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０２８１１８０（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０３７９２７７（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１６／００９４４５１（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０００５９２３（ＵＳ，Ａ１）

【文献】特表２０１５－５１９８２２（ＪＰ，Ａ）

【文献】中国特許出願公開第１１０５２１１６９（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４９／６０

Ｇ０６Ｆ ９／４５５

Ｈ０４Ｌ ４１／０８９５

(57)【特許請求の範囲】

【請求項1】

ホストコンピュータ上で動作するマシンに関連するデータメッセージのためのサービスを実行する方法であって、前記方法は、
前記ホストコンピュータにおいて、
マシンによって指定されたネットワークアドレスに基づいて、前記マシンによって送信されたデータメッセージを転送する第１の分散転送要素（ＤＦＥ）を構成することと、
前記マシンによって指定された前記ネットワークアドレスに基づいて前記データメッセージが前記第１のＤＦＥによって転送される前に、前記マシンによって送信されたデータメッセージを１つ以上のサービスノードのセットに転送する第２のＤＦＥを構成することとを含み、
各ＤＦＥは、前記ホストコンピュータ上で動作する少なくとも１つのソフトウェア転送要素（ＳＦＥ）と、少なくとも１つの他のホストコンピュータ上で動作する少なくとも１つの他のＳＦＥによって実施される、方法。

【請求項2】

請求項１に記載の方法であって、前記第１のＤＦＥおよび前記第２のＤＦＥは、論理スイッチ、論理ルータ、および、論理ネットワークまたはその部分を形成する論理スイッチおよび／または論理ルータの任意の組み合わせのうちの同一タイプの転送要素である、方法。

【請求項3】

請求項２に記載の方法であって、各ＤＦＥは分散ソフトウェアスイッチであり、各ＳＦＥはソフトウェアスイッチである、方法。

【請求項4】

請求項１に記載の方法であって、前記ホストコンピュータ上の１つのＳＦＥは、前記ホストコンピュータの外部で動作するソフトウェア転送要素の第１のセットおよび第２のセットと協働して前記第１のＤＦＥおよび前記第２のＤＦＥの両方を実施するように構成される、方法。

【請求項5】

請求項１に記載の方法であって、前記ホストコンピュータ上の第１のＳＦＥおよび第２のＳＦＥは、前記ホストコンピュータの外部で動作するソフトウェア転送要素の第１のセットおよび第２のセットと協働して前記第１のＤＦＥおよび前記第２のＤＦＥをそれぞれ実施するように構成される、方法。

【請求項6】

請求項１に記載の方法であって、前記第２のＤＦＥは、前記マシンによって指定されたネットワークアドレスに基づいてデータメッセージが転送される前にサービスノードに前記データメッセージを転送するためのサービス転送プレーンを定義する一方で、前記第１のＤＦＥは、前記マシンによって指定されたネットワークアドレスに基づいて前記データメッセージを転送するためのゲスト転送プレーンを定義する、方法。

【請求項7】

請求項６に記載の方法であって、
前記方法は、送信元として機能するゲストマシンと、データメッセージフローの宛先マシンと、サービスノードの少なくともサブセットとして機能するサービスマシンを有するデータセンタにおいて実施され、
前記第１のＤＦＥは、前記ゲスト転送プレーンに接続されるゲストマシンからデータメッセージを受信し、且つ、該ゲストマシンにデータメッセージを供給するポートを含み、
前記第２のＤＦＥは、前記サービス転送プレーンに接続されるサービスマシンにデータメッセージを供給し、且つ、該サービスマシンからデータメッセージを受信するポートを含み、
前記サービスマシンは、前記第１のＤＦＥ上の前記サービスマシンのためのポートを定義しないことにより前記ゲスト転送プレーンから分離され、前記ゲストマシンは、前記第２のＤＦＥ上の各ゲストマシンのためのポートを定義しないことにより前記サービス転送プレーンから分離され、
前記分離は、前記サービスマシンが前記ゲストマシンにデータメッセージを直接転送することができないことと、前記ゲストマシンが前記サービスマシンにデータメッセージを直接転送することができないこととを保証することにより、前記ゲストマシンと前記サービスマシンのセキュリティを向上させる、方法。

【請求項8】

請求項６に記載の方法であって、
前記第１のＤＦＥは、前記マシンからデータメッセージを受信するためのポートを有し、
前記第２のＤＦＥは、前記マシンからデータメッセージを受信するためのポートを有していないが、前記マシンによって送信されたデータメッセージを受信して前記データメッセージを特定のポートに転送するための、前記ホストコンピュータ上で動作する特定のポートプロキシから、データメッセージを受信するための前記特定のポートを有する、方法。

【請求項9】

請求項８に記載の方法であって、前記ポートプロキシは、前記ホストコンピュータ上で動作する複数のマシンと前記第２のＤＦＥとの間のインターフェースとして機能する、方法。

【請求項10】

請求項１に記載の方法であって、前記第２のＤＦＥは、前記ホストコンピュータ上で動作して前記マシンによって送信された前記データメッセージに対してサービス動作を実行する各サービスノードのためのサービスプロキシと、前記サービスプロキシの関連サービスノードに提供される前記データメッセージを定式化するサービスプロキシとを含む、方法。

【請求項11】

少なくとも１つの処理ユニットによって実施されると、請求項１から１０のいずれか１項に記載の方法を実施するコンピュータプログラム。

【請求項12】

コンピューティングデバイスであって、
処理ユニットのセットと、
少なくとも１つの前記処理ユニットによって実施されると、請求項１から１０のいずれか１項に記載の方法を実施するプログラムを格納する機械可読媒体と、を含む処理デバイス。

【発明の詳細な説明】

【背景技術】

【0001】

[0001] 現在のデータセンタでは、静的で構成集約的な方法を使用して、異なるアプリケーションレイヤ間および異なるサービスレイヤにデータメッセージを分配している。今日の一般的なアプローチは、仮想マシンが仮想IP(VIP)アドレスにパケットを送信するように構成し、次に、ＶＩＰアドレスで指定されたパケットを適切なアプリケーションまたはサービスレイヤー（あるいはその両方）に転送するように指示する転送ルールを使用して、データセンタ内の転送要素とロードバランサを構成することである。既存のメッセージ分配スキームの別の問題は、今日のロードバランサが分配されるトラフィックのための難所であることである。したがって、データセンタ内のデータメッセージを異なるアプリケーションレイヤおよび／またはサービスレイヤ間でシームレスに分配する新しいアプローチが当技術分野において必要とされている。理想的には、この新しいアプローチは、データメッセージを送信するサーバを再設定することなく、分配スキームを容易に修正することを可能にするであろう。

【発明の概要】

【0002】

[0002] いくつかの実施形態は、１つ以上のデータセンタで動作するマシンのためのサービスを実行するための新しい方法を提供する。例えば、関連するゲストマシンのグループ（例えば、テナントマシンのグループ）に対して、いくつかの実施形態は、（１）ゲスト転送プレーンと（２）サービス転送プレーンの２つの異なる転送プレーンを定義する。ゲスト転送プレーンは、グループ内のマシンに接続し、これらのマシンに対してＬ２および／またはＬ３転送を実行する。サービス転送プレーンは、（１）これらのマシンとの間で送受信されるデータメッセージに対してサービスを実行するサービスノードに接続し、（２）これらのデータメッセージをサービスノードに転送する。

【0003】

[0003] いくつかの実施形態では、ゲストマシンは、サービス転送プレーンと直接接続しない。例えば、いくつかの実施形態では、各転送プレーンは、マシンまたはサービスノードからデータメッセージを受信するか、またはマシンまたはサービスノードにデータメッセージを供給するポートを介して、マシンまたはサービスノードに接続する。このような実施形態では、サービス転送プレーンは、任意のゲストマシンからデータメッセージを直接受信したり、任意のゲストマシンにデータメッセージを供給したりするポートを持たない。代わりに、いくつかのそのような実施形態では、ゲストマシンに関連するデータは、同じホストコンピュータ上で実行されるポートプロキシモジュールにルーティングされ、このポートプロキシモジュールは、サービスプレーンポートを有する。いくつかの実施形態におけるこのポートプロキシモジュールは、同一ホスト上の複数のゲストマシンをサービスプレーンに間接的に接続することができる（すなわち、同一ホスト上の複数のゲストマシンのポートプロキシモジュールとして機能することができる）。

【0004】

[0004] いくつかの実施形態では、ゲストマシンは、サービスマシンまたはノードではない任意のマシンである。ゲストマシンは、マルチテナントデータセンタ内のテナントのマシンにすることはできるが、必ずしもする必要はない。いくつかの実施形態におけるゲストマシンは、ゲスト仮想マシンまたはゲストコンテナである。いくつかの実施形態におけるサービスノードは、サービス仮想マシン、サービスコンテナ、またはサービスアプライアンスである。いくつかの実施形態では、サービスノードは、ファイアウォール、侵入検知システム、侵入防御システム、ロードバランサ、暗号化器、メッセージモニタ、メッセージコレクタ、または任意の数の他のミドルボックスサービスなどのミドルボックスサービス動作を実行する。したがって、本書で使用されるサービスは、いくつかの実施形態における任意のタイプのミドルボックスサービス動作である。

【0005】

[0005] 前述の概要は、本発明のいくつかの実施形態の簡単な紹介として役立つことを意図している。これは、この文書に開示されたすべての発明の主題の導入または概要であることを意味するものではない。以下の詳細な説明および詳細な説明で参照される図面は、概要ならびに他の実施形態で説明される実施形態をさらに説明する。したがって、本書面によって説明されるすべての実施形態を理解するために、概要、詳細な説明、図面、および特許請求の範囲の全体的な検討が必要である。さらに、特許請求の範囲に記載される主題は、概要、詳細な説明、および図面における例示的な詳細によって限定されるべきではない。

【図面の簡単な説明】

【0006】

[0006] 本発明の新規な特徴は、添付の特許請求の範囲に記載されている。しかしながら、説明の目的のために、本発明のいくつかの実施形態を以下の図に示す。

【図1】[0007] 図１は、２つの論理転送要素によっていくつかの実施形態で実現される分離ゲストおよびサービスプレーンの例を示す。

【図2】[0008] 図２は、いくつかの実施形態のサービス仮想マシン（ＳＶＭ）によって処理されるサービスパスに沿ってリダイレクトされる、２つのゲスト仮想マシン（ＧＶＭ）間のデータメッセージを示す。

【図3】[0009] 図３は、いくつかの実施形態において、サービスチェーンと、サービスチェーンを実装する１つ以上のサービスパスのセットとの間の関係を概念的に示す。

【図4】[0010] 図４は、サービスチェーンとそれに関連するサービスパスの例を示す。

【図5】[0011] 図５は、図４に示すフォワードサービスパスのリバースサービスパスの例を示す。

【図6】[0012] 図６は、いくつかの実施形態におけるサービスプレーンを実装する入出力（ＩＯ）チェーンコンポーネントの例を示す。

【図7】[0013] 図７は、いくつかの実施形態のサービスインデックスプリプロセッサおよびサービストランスポートレイヤ呼び出し元によって実行されるプロセスを示す。

【図8】[0014] 図８は、図７で説明したプロセスに対応するデータフロー例を示す。

【図9】[0015] 図９は、第１のサービスノードによって転送するためのデータメッセージを定式化するための、いくつかの実施形態のポートプロキシの動作を示す。

【図10】[0016] 図１０は、サービスパス内のデータメッセージをネクストホップに渡すための、いくつかの実施形態のプロセスを概念的に示す。

【図11】[0017] 図１１は、図６のサービスプロキシが、サービスノードの入口パスに沿って横断するデータメッセージを受信するたびに、いくつかの実施形態において実行するプロセスを示す。

【図12】[0018] 図１２は、いくつかの実施形態のデータメッセージの３つのカプセル化ヘッダを概念的に示す。

【図13】[0019] 図１３は、サービスプロキシから処理するデータメッセージを受信するたびにＳＶＭがいくつかの実施形態で実行する１つの例示的なプロセスを概念的に示す。

【図14】[0020] 図１４は、いくつかの実施形態のＳＶＭの第１のマッピングテーブルを示す。

【図15】[0021] 図１５は、いくつかの実施形態におけるデータメッセージが第１ホップサービスノードから第２ホップサービスノードに転送される例を示す。

【図16】[0022] 図１６は、サービスプロキシが、そのサービスノードの出口パスに沿って通過するデータメッセージを受信するたびに、いくつかの実施形態において実行するプロセスを概念的に示す。

【図17】[0023] 図１７は、コンピュータ上で実行されるＳＶＭによって処理される必要があるカプセル化されたデータメッセージを受信するネクストホップコンピュータ上のカプセル化プロセッサによって開始されるプロセスを概念的に示す。

【図18】[0024] 図１８は、いくつかの実施形態におけるデータメッセージが第２ホップサービスノードから第３ホップサービスノードに転送される例を示す。

【図19】[0025] 図１９は、いくつかの実施形態におけるデータメッセージが、第３ホップサービスノードから第１ホップサービスノードに戻される例を示す。

【図20】[0026] 図２０は、サービスインデックスポストプロセッサがいくつかの実施形態において実行するプロセスを概念的に示す。

【図21】[0027] 図２１は、いくつかの実施形態のネットワークサービスヘッダを示す。

【図22】[0028] 図２２は、いくつかの実施形態のメタデータコンテンツヘッダに記憶されるメタデータコンテンツの例を示す。

【図23】、

【図24】[0029] 図２３－２４は、ＧＲＥヘッダをカプセル化したＧＶＭのＳＶＭ出口側および入口側データメッセージへのサービスプロキシ転送の例を示す。

【図25】[0030] 図２５は、いくつかの実施形態において、出口方向のサービスデータを記憶するために使用されるＧＲＥヘッダフォーマットを示す。

【図26】[0031] 図２６は、いくつかの実施形態において、入口方向のサービスデータを記憶するために使用されるＧＲＥヘッダフォーマットを示す。

【図27】[0032] 図２７は、２つのＧｅｎｅｖｅカプセル化ヘッダ（サービストランスポートレイヤデータを運ぶための外側Ｇｅｎｅｖｅヘッダと、サービス挿入レイヤメタデータを運ぶための内側Ｇｅｎｅｖｅヘッダ）の使用を示す。

【図28】[0033] 図２８は、図２７の２つのＧｅｎｅｃｅカプセル化ヘッダを１つのＧｅｎｅｖｅカプセル化ヘッダにまとめたものである。

【図29】[0034] 図２９は、いくつかの実施形態のオブジェクトデータモデルを示す。

【図30】[0035] 図３０は、サービス挿入、ネクストサービスホップ転送、およびサービス処理のためのルールを定義するために、ネットワークマネージャおよびコントローラがいくつかの実施形態において実行するいくつかの動作を概念的に示す。

【図31】[0036] 図３１は、いくつかの実施形態において、サービスパスがどのように動的に修正されるかを示す。

【図32】[0037] 図３２は、いくつかの実施形態で、マルチテナントデータセンタ内のテナントのサービスプレーンとそれに関連するサービスノードを定義するために実行されるプロセスを示す。

【図33】[0038] 図３３は、移行されたＧＶＭの送信元ホストで実行されるプロセスと、移行されたＧＶＭの宛先ホストで実行されるプロセスを示す。

【図34A】、

【図34B】、

【図34C】[0039] 図３４Ａ～３４Ｃは、いくつかの実施形態におけるＧＶＭ移行の例を示す。

【図35】[0040] 図３５は、いくつかの実施形態において、ＧＶＭ移行後に制御プレーンによって実行される動作を概念的に示す。

【図36】[0041] 図３６は、移行されたＳＶＭの移行元ホストで実行されるプロセスと、移行されたＳＶＭの移行先ホストで実行されるプロセスを示す。

【図37A】、

【図37B】、

【図37C】[0042] 図３７Ａ－３７Ｃは、いくつかの実施形態におけるＳＶＭ移行の例を示す。

【図38】[0043] 図３８は、いくつかの実施形態において、ＧＶＭ移行後に制御プレーンによって実行される動作を概念的に示す。

【図39】[0044] 図３９は、いくつかの実施形態におけるホスト内ＳＶＭ移行の例を示す。

【図40】[0045] 図４０は、本発明のいくつかの実施形態が実施される電子システムを概念的に示す。

【発明を実施するための形態】

【0007】

[0046] 本発明の以下の詳細な説明では、本発明の多数の詳細、例、および実施形態を説明する。しかしながら、本発明は、説明された実施形態に限定されず、本発明は、説明された特定の詳細および例のいくつかなしに実施されてもよいことが、当業者には明らかであり、明確であろう。

【0008】

[0047] いくつかの実施形態は、１つ以上のデータセンタで動作するマシンのためのサービスを実行するための新しい方法を提供する。例えば、関連するゲストマシンのグループ（例えば、テナントマシンのグループ）に対して、いくつかの実施形態は、（１）ゲスト転送プレーンと（２）サービス転送プレーンの２つの異なる転送プレーンを定義する。ゲスト転送プレーンは、グループ内のマシンに接続し、これらのマシンに対してＬ２および／またはＬ３転送を実行する。サービス転送プレーンは、（１）これらのマシンとの間で送受信されるデータメッセージに対してサービスを実行するサービスノードに接続し、（２）これらのデータメッセージをサービスノードに転送する。

【0009】

[0048] いくつかの実施形態では、ゲストマシンは、サービス転送プレーンと直接接続しない。例えば、いくつかの実施形態では、各転送プレーンは、マシンまたはサービスノードからデータメッセージを受信するか、またはマシンまたはサービスノードにデータメッセージを供給するポートを介して、マシンまたはサービスノードに接続する。このような実施形態では、サービス転送プレーンは、任意のゲストマシンからデータメッセージを直接受信したり、任意のゲストマシンにデータメッセージを供給したりするポートを持たない。代わりに、いくつかのそのような実施形態では、ゲストマシンに関連するデータは、同じホストコンピュータ上で実行されるポートプロキシモジュールにルーティングされ、この他のモジュールはサービスプレーンポートを有する。いくつかの実施形態におけるこのポートプロキシモジュールは、同一ホスト上の複数のゲストマシンをサービスプレーンに間接的に接続することができる（すなわち、同一ホスト上の複数のゲストマシンのポートプロキシモジュールとして機能することができる）。

【0010】

[0049] いくつかの実施形態では、ゲストマシンは、サービスマシンまたはノードではない任意のマシンである。ゲストマシンは、マルチテナントデータセンタ内のテナントのマシンにすることはできるが、必ずしもする必要はない。いくつかの実施形態におけるゲストマシンは、ゲスト仮想マシンまたはゲストコンテナである。いくつかの実施形態におけるサービスノードは、サービス仮想マシン、サービスコンテナ、またはサービスアプライアンスである。いくつかの実施形態では、サービスノードは、ファイアウォール、侵入検知システム、侵入防御システム、ロードバランサ、暗号化器、メッセージモニタ、メッセージコレクタ、または任意の数の他のミドルボックスサービスなどのミドルボックスサービス動作を実行する。したがって、本書で使用されるサービスは、いくつかの実施形態における任意のタイプのミドルボックスサービス動作である。

【0011】

[0050] また、本書で使用されているように、データメッセージは、ネットワークを介して送信される特定の形式のビットの集合を指す。当業者は、データメッセージという用語が、ネットワークを介して送信されるビットの様々な定式化された集合を指すために本書で使用されることを認識するであろう。これらのビットのフォーマットは、標準化されたプロトコルまたは標準化されていないプロトコルによって指定することができる。標準化されたプロトコルに従ったデータメッセージの例としては、イーサネットフレーム、IPパケット、TCPセグメント、UDPデータグラムなどがある。また、本明細書で使用するL2、L3、L4、L7レイヤ（またはレイヤ2、レイヤ3、レイヤ4、レイヤ7）は、OSI (Open System Interconnection)レイヤモデルの第2データリンクレイヤ、第3ネットワークレイヤ、第4トランスポートレイヤ、第7レイヤプリケーションレイヤをそれぞれ参照している。

【0012】

[0051] 図１は、２つの論理転送要素（ＬＦＥ）１３０および１３２によっていくつかの実施形態で実施される分離ゲストおよびサービスプレーンの例を示す。図に示すように、２つのゲストマシン１０２および１０４と３つのサービスマシン１０６、１０８および１１０は、３つのソフトウェア転送要素１２０、１２２および１２４と共に、３つのホストコンピュータ１１２、１１４および１１６上で実行される。この例では、ゲストマシンおよびサービスマシンはゲスト仮想マシン（ＧＶＭ）およびサービス仮想マシン（ＳＶＭ）であるが、他の実施形態では、これらのマシンは、コンテナなどの他のタイプのマシンであってもよい。

【0013】

[0052] また、この例では、各論理転送要素は、複数のホストコンピュータに複数のソフトウェア転送要素（ＳＦＥ）を設定することによって実装される分散転送要素である。これを行うために、いくつかの実施形態では、各ＳＦＥまたはＳＦＥに関連するモジュールは、オーバーレイネットワークに関連する仮想ネットワーク識別子（ＶＮＩ）を含むオーバーレイネットワークヘッダでＬＦＥのデータメッセージをカプセル化するように構成される。このように、ＬＦＥは、以下の議論において、複数のホストコンピュータにまたがるオーバーレイネットワーク構造であると言われる。

【0014】

[0053] ＬＦＥはまた、いくつかの実施形態では、構成されたハードウェア転送要素（例えば、ラックスイッチの上）にまたがる。いくつかの実施形態では、各ＬＦＥは、複数のソフトウェアスイッチ（仮想スイッチまたはｖｓｗｉｔｃｈと呼ばれる）または関連モジュールを複数のホストコンピュータ上に構成することによって実現される論理スイッチである。他の実施形態では、ＬＦＥは、他のタイプの転送要素（例えば、論理ルーター）、または論理ネットワークまたはその部分を形成する転送要素（例えば、論理スイッチおよび／または論理ルーター）の任意の組合せであることができる。現在、ＬＦＥ、論理スイッチ、分散論理ルーター、および論理ネットワークの多くの例が存在する。これには、ＶＭｗａｒｅのＮＳＸネットワークおよびサービス仮想化プラットフォームによって提供されるものも含まれる。

【0015】

[0054] 図に示すように、ＬＦＥ １３０は、これらのＧＶＭ間でデータメッセージを転送するために、ＧＶＭ１０２および１０４を接続するゲスト転送プレーンを定義する。いくつかの実施形態では、このＬＦＥは、論理ルーターに接続する論理スイッチであり、この論理ルーターは、ＧＶＭを、直接又は論理ゲートウェイを介して、論理スイッチの論理ネットワーク外のネットワークに接続する。ＬＦＥ１３０は、第１の分散論理スイッチを実装するために、ホストコンピュータ１１２および１１４上でソフトウェアスイッチ１２０および１２２および／またはそれらの関連モジュール（例えば、関連するポート／ＶＮＩＣフィルタモジュール）を構成することによって、いくつかの実施形態で実装される。

【0016】

[0055] 以下で説明する図１およびその他の図は、送信元ＧＶＭと宛先ＧＶＭが同じ論理ネットワーク上にあり、同じＬＦＥに接続されていることを示している。当業者は、いくつかの実施形態のサービス動作は、送信元および宛先マシンが同一のＬＦＥに接続されることを必要とせず、あるいは同一のネットワークまたは同一のデータセンタにあることさえ必要としないことを認識するであろう。これらのサービス動作は、送信元マシンのネットワークを終了するか、送信元マシンのネットワークに入るデータメッセージに対して実行される。図は、サービスプレーン１３２が、ゲストマシンに関連するデータメッセージを転送する論理ネットワークとは別の論理ネットワークによって実装されることを強調するために、同一のＬＦＥに接続されたものとしての送信元および宛先マシンを示す。

【0017】

[0056] ＬＦＥ１３２は、ＳＶＭを含むサービスパスを介してＧＶＭに関連付けられたデータメッセージを転送するために、ＳＶＭ１０６、１０８、１１０を接続するサービス転送プレーンを定義する。いくつかの実施形態では、ＬＦＥ１３２はまた、第２の分散論理スイッチを実装するためにホストコンピュータ１１２、１１４および１１６上でソフトウェアスイッチ１２０、１２２および１２４および／またはそれらの関連モジュールを構成することによって実装される論理スイッチである。ゲストおよびサービス転送プレーン（すなわち、ゲストおよびサービスＬＦＥ）の両方を実装するために同じＳＦＥのセットを構成する代わりに、他の実施形態は、サービス転送プレーンを実装するために、ゲスト転送プレーンおよびホストコンピュータのセット上の別のＳＦＥのセットを実装するために、ホストコンピュータのセット上の１つのＳＦＥのセットを構成する。例えば、いくつかの実施形態では、各ホストコンピュータは、ゲストソフトウェアスイッチおよびサービスソフトウェアスイッチを実行し、これら２つのスイッチおよび／またはそれらの関連モジュールは、ゲスト論理スイッチおよびサービス論理スイッチを実装するように構成されることができる。

【0018】

[0057] いくつかの実施形態では、ソフトウェアスイッチ１２０、１２２および１２４および／またはそれらの関連モジュールは、複数のゲスト転送プレーン（例えば、ゲストＬＦＥ）および複数のサービス転送プレーン（例えば、サービスＬＦＥ）を複数のマシンのグループに対して実装するように構成されることができる。例えば、マルチテナントデータセンタの場合、いくつかのこのような実施形態は、少なくとも１つのサービスチェーンが実装される必要がある各テナントに対して、ゲストＬＦＥおよびサービスＬＦＥを定義する。関連するマシンの各グループ（例えば、各テナントのマシン）に対して、いくつかの実施形態は、２つの異なる転送プレーン、すなわち、ゲスト転送プレーンおよびサービス転送プレーンを実装するためのソフトウェア転送要素（例えば、ソフトウェアスイッチ）の共有セットを構成するために、２つの仮想ネットワーク識別子（ＶＮＩ）を定義する。これらの２つのＶＮＩは、以下ではゲストVNI(GVNI)およびサービスVNI(SVNI)と呼ばれる。図１では、図に示すように、ゲストＬＦＥポート１５０と１５２はＧＶＮＩに関連付けられ、サービスＬＦＥポート１５４、１５６、および１５８はＳＶＮＩに関連付けられている。

【0019】

[0058] いくつかの実施形態では、サービスプレーン１３２は、ＳＦＥ１２０または１２２との間のＧＶＭの出入口のデータパスの入出力（ＩＯ）チェーンにモジュールを挿入することによっても実現される。この実装では、サービスプレーン１３２は、ＧＶＭから送信された、またはＧＶＭのために受信されたデータメッセージを識別し、データメッセージ上でサービスのチェーンを実行するためにデータメッセージをＳＶＭのセットに転送し、次にデータメッセージをＧＶＭのデータパスに戻して、データメッセージがソフトウェアスイッチまたはＧＶＭへのデータパスに沿って進むことができるようにする（すなわち、送信元ＧＶＭによって指定された宛先ネットワークアドレスに基づいてデータメッセージを処理できるようにする）。このようなＧＶＭは、サービスノードによって処理されているデータメッセージがＧＶＭの出口または入口パス上で識別されるデータメッセージであるため、送信元ＧＶＭとして以下で参照される。いくつかの実施形態では、ＧＶＭの出口／入口ＩＯチェーンは、ＧＶＭのＶＮＩＣ(仮想ネットワークインターフェースカード）１８０内のフック（関数呼び出し）のセット、またはＧＶＭのＶＮＩＣに関連するＳＦＥポート（例えば、ＧＶＭのＶＮＩＣと通信するＳＦＥポート）として実装される。

【0020】

[0059] サービスプレーンを実装するいくつかの実施形態のＩＯチェーンコンポーネントの例を提供する前に、図２は、２つのサービス動作のチェーンを実行するＳＶＭ１０８および１１０によってデータメッセージを処理できるように、サービスプレーン１３２に沿ってリダイレクトされるＧＶＭ１０２からＧＶＭ１０４へのデータメッセージ２０２の例を示す。図に示すように、サービスＬＦＥ１３２は、まずデータメッセージをＳＶＭ１０８に転送し、次にデータメッセージをＳＶＭ１１０に転送してから、データメッセージをＧＶＭ１０２の出口パスに戻し、送信元ＧＶＭ１０２によって指定された宛先ネットワークアドレスに基づいてデータメッセージを処理できるようにする。

【0021】

[0060] いくつかの実施形態におけるサービスＬＦＥは、サービスＬＦＥのためのＳＶＮＩを格納するオーバーレイカプセル化ヘッダを使用することによって、ホスト１１２、１１４、１１６の間でデータメッセージを転送する。また、サービスＬＦＥがサービス論理スイッチであるとき、いくつかの実施形態におけるサービス転送プレーンは、ＳＶＭに関連するＭＡＣアドレス（例えば、ＳＶＭ ＶＮＩＣのＭＡＣアドレス）を使用して、サービス論理スイッチのポート間でデータメッセージを転送する。いくつかの実施形態では、このＧＶＭはサービスプレーンに直接接続せず、代わりにポートプロキシを介してサービスプレーンに接続するが、後述するように、ＭＡＣ転送は送信元ＧＶＭに関連するサービスプレーンＭＡＣアドレスも使用する。

【0022】

[0061] データメッセージ２０２がＧＶＭ１０２の出口パスに戻ると、ゲストＬＦＥ１３０はデータメッセージをその宛先（例えば、データメッセージのヘッダ内の宛先ネットワークアドレスによって指定される）、これはＧＶＭ１０４である、に転送する。いくつかの実施形態におけるゲストＬＦＥ１３０は、ゲストＬＦＥのためのＧＶＮＩを格納するオーバーレイカプセル化ヘッダを使用することによって、ホスト１１２と１１４との間でデータメッセージを転送する。また、ゲストＬＦＥが論理スイッチであるとき、いくつかの実施形態におけるゲスト転送プレーンは、ＧＶＭ１０２および１０４に関連するゲストプレーンＭＡＣアドレスを使用して、データメッセージを転送する（例えば、ＧＶＭ１０４のゲストプレーンＭＡＣアドレスを使用して、このＧＶＭに関連するゲスト転送ポート１５２にデータメッセージを転送する）。図２のサービスプレーンは、ＧＶＭの出口パスを通過するデータメッセージを捕捉するが、いくつかの実施形態では、サービスプレーンは、ＧＶＭのＶＮＩＣに到達する前に、ＧＶＭの入口パスを通過するときに、データメッセージを捕捉することもできる。

【0023】

[0062] いくつかの実施形態では、サービス動作のチェーンは、サービスチェーンと呼ばれる。いくつかの実施形態におけるサービスチェーンは、サービスパスを定義するサービスノードの各セットと共に、サービスノードの１つ以上のセット（例えば、サービスマシンまたはアプライアンス）を用いて実現することができる。したがって、いくつかの実施形態では、サービスチェーンは、１つ以上のサービスパスのそれぞれによって実現することができる。いくつかの実施形態における各サービスパスは、サービスチェーンの１つ以上のサービスのセットと、これらのノードを介した特定の順序とを実行するための１つ以上のサービスノードを含む。

【0024】

[0063] 図３は、サービスチェーン３０２と、サービスチェーンを実装する１つ以上のサービスパス３０４のセットとの間の関係を示すオブジェクト図を示す。各サービスチェーンにはサービスチェーン（ＳＣ）識別子３０６があり、各サービスパスにはサービスパス識別子（ＳＰＩ）３０８がある。各サービスパスは、示されるように、サービスインスタンスエンドポイント３１０に関して識別されるｍ個のサービスノードのセットに関連付けられる。いくつかの実施形態におけるサービスインスタンスエンドポイントは、トラフィックがサービスプレーンに接続されたサービスノードを行き来することができる、またはサービスプレーンから来ることができる、ネットワーク内の論理的な位置である。いくつかの実施形態では、サービスインスタンスエンドポイントは、サービスノード（例えば、ＳＶＭのＶＮＩＣ）に関連する１つのＬＦＥポート（例えば、ＳＦＥポート）である。これらまたは他の実施形態では、サービスインスタンスエンドポイントは、ＧＲＥカプセル化を使用する実施形態のために、以下にさらに説明するように、サービスノードに使用される２つのＬＦＥポートに関連付けられることができる。また、いくつかの実施形態におけるサービスエンドポイントは、ＬＦＥポートに関連するＭＡＣアドレス、または（例えば、これらのＬＦＥポートと通信する）関連するSVM VNICを通してアドレス指定可能である。

【0025】

[0064] いくつかの実施形態では、各サービスチェーン３０２は、１つ以上のサービスプロファイル３１２への参照によって定義され、各サービスプロファイルは、チェーン内のサービス動作に関連付けられる。以下に説明するように、いくつかの実施形態におけるサービスノードは、（１）サービスマネージャから、サービスチェーン識別子の、それが実装しなければならないサービスプロファイルへのマッピングを受信し、（２）データメッセージと共に、それが実行しなければならないサービス動作を決定するためにサービスプロファイルにマッピングするサービスチェーン識別子を受信する。いくつかの実施形態では、受信されたマッピングは、サービスチェーン識別子（ＳＣＩ）に基づくだけでなく、サービスインデックス値（サービスパス内のサービスノードの位置を指定する）およびサービスチェーンを介した方向（サービスチェーンによって指定されたサービスのシーケンスを実行するための順序を指定する）にも基づく。いくつかの実施形態におけるサービスプロファイルは、サービスノードが実行しなければならないサービス動作を記述する。いくつかの実施形態では、サービスプロファイルは、検査するサービスノードのためのルールのセットを識別することができる。

【0026】

[0065] また、いくつかの実施形態では、サービス挿入ルール３１４は、ＧＶＭに関連するサービス挿入モジュールのためのサービスチェーン識別３０６への参照によって定義される。このようなサービス挿入モジュールは、これらのサービス挿入ルール３１４を使用して、送信元ＧＶＭに関連するデータメッセージを処理するために使用するサービスチェーンを識別する。前述したように、データメッセージは、送信元ＧＶＭからのものとして、そして、サービスチェーンによって処理されるデータメッセージが、ＧＶＭからの出口パスまたはＧＶＭへの入口パスで識別されるものとして、以下で参照される。

【0027】

[0066] 以下でさらに説明するように、サービス挿入（ＳＩ）ルールは、フロー識別子をサービスチェーン識別子に関連付ける。言い換えると、いくつかの実施形態は、データメッセージのフロー属性をサービス挿入ルールのフロー識別子（以下、ＳＩルールのルール識別子と呼ぶ）に一致させることを試み、一致するサービス挿入ルール（すなわち、データメッセージのフロー属性に一致するフロー識別子の設定を有するルール）を識別し、この一致ルールの指定されたサービスチェーンをデータメッセージのサービスチェーンとして割り当てる。特定のフロー識別子（例えば、５つのタプル識別子への参照によって定義されるもの）は、１つの特定のデータメッセージフローを識別することができ、一方、より一般的なフロー識別子（例えば、５つのタプルより小さい参照によって定義されるもの）は、より一般的なフロー識別子と一致するいくつかの異なるデータメッセージフローのセットを識別することができる。そのため、一致するデータメッセージフローは、サービス挿入ルールのルール識別子に一致する共通の属性セットを持つ任意のデータメッセージセットである。

【0028】

[0067] 以下にさらに説明するように、他の実施形態は、データメッセージフローに関連するコンテキスト属性を使用して、データメッセージをサービス挿入ルールに関連付ける。転送およびサービス動作を実行するためのコンテキスト属性を捕捉および使用するための多くの技術は、本明細書に組み込まれる米国特許出願第１５／６５０，２５１号に記載されている。これらの技術のいずれも、本明細書に記載する実施形態と共に使用することができる。

【0029】

[0068] いくつかの実施形態におけるネクストホップ転送ルール３１６は、ＳＰＩ値３０８およびサービスインスタンスエンドポイント３１０を参照することによって定義される。具体的には、いくつかの実施形態では、データメッセージに対して識別されたサービスチェーンに対してサービスパスが選択される。各ホップで、これらの実施形態は、転送ルール３１４を使用して、サービスパス内のホップの位置を識別する現在のサービスインデックス（ＳＩ）値と共に、このサービスパスのＳＰＩ値に基づいて次のサービスインスタンスエンドポイントを識別する。言い換えると、いくつかの実施形態における各転送ルールは、ＳＰＩ／ＳＩ値に関して定義された一致基準のセットを有し、これらのＳＰＩ／ＳＩ値に関連するネクストホップサービスインスタンスエンドポイントのネットワークアドレスを指定する。第１ホップのネクストホップルックアップを最適化するために、いくつかの実施形態は、サービスパス選択プロセスの一部として、ＳＰＩと共にネクストホップネットワークアドレスを送信元ＧＶＭのサービス挿入モジュールに提供する。

【0030】

[0069] 図４は、サービスチェーンとそれに関連するサービスパスの例を示す。図示のように、いくつかの実施形態における各サービスチェーン４０５は、サービスプロファイル４１０のシーケンシャルリストとして定義され、この例における各プロファイルは、異なるミドルボックスサービス（ファイアウォール、ロードバランサ、侵入検知器、データメッセージ監視など）に関連する。また、この例では、各Ｍプロファイルは、ＶＭのクラスタｍ内の１つのＳＶＭによって実装できる。図に示すように、プロファイルごとに異なるクラスタには、異なる数のＳＶＭを設定できる。また、いくつかの実施形態では、１つのサービスプロファイルが１つのサービスノードによって実装される（すなわち、いくつかのサービスノードのクラスタは、サービスプロファイルを実装するために必要とされない）。

【0031】

[0070] クラスタ内の複数のＳＶＭは特定のサービスを提供できるため、いくつかの実施形態では、特定のサービスチェーンに対して、複数の異なるＳＶＭの組み合わせを介した複数のサービスパスを定義し、各クラスタの１つのＳＶＭが各組み合わせで使用される。図４の例では、サービスチェーン４０５に関連するＮ個のサービスパスがあり、それらのサービスパスは、ＧＶＭ４０４への経路上のＧＶＭ４０２で発信されるデータメッセージによって横断される。各サービスパスは、この図の異なる破線のセットで識別される。

【0032】

[0071] 具体的には、第１のサービスパスは、転送するサービスチェーン４０５の第１のサービスを実装するために第１のサービスプロファイルのクラスタの第１のＳＶＭ １，１、転送するサービスチェーン４０５の第２のサービスを実装するために第２のサービスプロファイルのクラスタの第１のＳＶＭ ２，１、および転送するサービスチェーン４０５のＭ番目のサービスを実装するためにＭ番目のサービスプロファイルのクラスタの第３のＳＶＭ Ｍ,３を通過する。第２のサービスパスは、転送サービスチェーン４０５の第１のサービスを実装するために第１のサービスプロファイルのクラスタの第２のＳＶＭ １，２を通過し、転送サービスチェーン４０５の第２のサービスを実装するために第２のサービスプロファイルのクラスタの第１のＳＶＭ ２，１と、転送サービスチェーン４０５のＭ番目のサービスを実装するためにＭ番目のサービスプロファイルのクラスタの第１のＳＶＭ Ｍ,１を通過する。

【0033】

[0072] ３番目のサービスパスは、転送サービスチェーン４０５の第１のサービスを実装するために、第１のサービスプロファイルのクラスタの３番目のＳＶＭ １，３を通過し、転送サービスチェーン４０５の２番目のサービスを実装するために、２番目のサービスプロファイルのクラスタの２番目のＳＶＭ ２，２を通過し、転送サービスチェーン４０５のＭ番目のサービスを実装するために、Ｍ番目のサービスプロファイルのクラスタの２番目のＳＶＭ Ｍ,２を通過する。Ｎ番目のサービスパスは、転送サービスチェーン４０５の第１のサービスを実装するために、第１のサービスプロファイルのクラスタの３番目のＳＶＭ １，３を通過し、転送サービスチェーン４０５の２番目のサービスを実装するために、２番目のサービスプロファイルのクラスタの２番目のＳＶＭ ２，２を通過し、転送サービスチェーン４０５のＭ番目のサービスを実装するために、Ｍ番目のサービスプロファイルのクラスタの４番目のＳＶＭ Ｍ,４を通過する。この例で説明するように、サービスパスが異なると、特定のサービス動作に同じＳＶＭが使用される場合がある。ただし、特定のデータメッセージが通過するサービスパスに関係なく、同じサービスチェーンと同じサービス方向に関連付けられているパスに対して、同じサービス動作のセットが同じシーケンスで実行される。

【0034】

[0073] いくつかの実施形態では、サービスチェーンは、第１のＧＶＭから第２のＧＶＭへのデータメッセージに対して順方向に実行され、次に第２のＧＶＭから第１のＧＶＭへのデータメッセージに対して逆方向に実行されなければならない。いくつかのこのような実施形態では、サービスプレーンは、第１のＧＶＭから第２のＧＶＭへのフロー内の第１のデータメッセージを処理するときに、順方向（フォワード）のサービスパスと逆方向（リバース）のサービスパスの両方を選択する。また、これらの実施形態のいくつかでは、フォワードおよびリバースサービスパスは、サービスノードの同じセットによって実装されるが、逆の順序で実装される。

【0035】

[0074] 図５は、図４に示すフォワードサービスパスのリバースサービスパスの例を示す。フォワードサービスパスは、ＧＶＭ４０２からＧＶＭ４０４へのデータメッセージに対してＭサービスを実行するためのものであるが、リバースサービスパスは、ＧＶＭ４０４からＧＶＭ４０２へのデータメッセージに対してＭサービスを実行するためのものである。また、図５のサービスパスがサービスプロファイルＭ～１を実行するのに対して、図４のサービスパスがサービスプロファイル１～Ｍを実行すると、これらのサービスの順序が逆になる。

【0036】

[0075] また、図４および図５の例では、各リバースサービスパスは、サービスパスの凡例およびこれらの図の同様の破線によって示されるように、まったく同じＳＶＭのセットによって実装されるが逆の順序で実装される、１つの対応するフォワードサービスパスを有する。たとえば、順方向、第２のサービスパスは、第１のプロファイルに関連付けられた第１のサービスについてはＳＶＭ １，２を通過し、第２のプロファイルに関連付けられた第２のサービスについてはＳＶＭ ２，１を通過し、Ｍ番目のサービスプロファイルに関連付けられたＭ番目のサービスについてはＳＶＭ Ｍ,１を通過する。一方、第２のサービスパスは、Ｍ番目のサービスプロファイルに関連付けられた第１のサービスについてはＳＶＭ Ｍ,１を通過し、第２のプロファイルに関連付けられた第２のサービスについてはＳＶＭ ２，１を通過し、第１のプロファイルに関連付けられた第２のサービスについてはＳＶＭ １，２を通過する。

【0037】

[0076] いくつかの実施形態では、サービスプロファイルの１つを実装するサービスノード（例えば、ファイアウォールＳＶＭ）の少なくとも１つが、２つのデータエンドポイント（例えば、２つのＧＶＭＳ）間の双方向のデータトラフィックを見る必要があるため、フォワードパスとリバースパスに同じサービスノードが使用される。他の実施形態では、同じサービス動作のセットが反対の順序で実行される限り、２つのデータエンドポイント間のデータメッセージフローの両方向に同じサービスノードを使用する必要はない。

【0038】

[0077] 図６は、いくつかの実施形態におけるサービスプレーンを実装するＩＯチェーンコンポーネントの例を示す。図に示すように、サービスプレーン１３２は、ホストコンピュータ上で実行されるソフトウェアスイッチ１２０、１２２、１２４と、これらのコンピュータ上で実行される２組のモジュール６１０、６１２、６１４、６２０、６２４、６２６、および６２８によって実現される。この例に実装されているサービスプレーンと、後続のいくつかの図に示されているいくつかの他の実施形態は、オーバーレイ論理Ｌ２サービスプレーンである。当業者は、他の実施形態が、オーバーレイＬ３サービスプレーン、または複数のＬ２論理スイッチおよび１つ以上の論理Ｌ３ルーターを備えたオーバーレイネットワークなどの他のタイプのサービスプレーンによって実現されることを理解するであろう。

【0039】

[0078] 図６では、ソフトウェアスイッチ１２０、１２２、１２４、およびモジュール６１０、６１２、６１４、６２０、６２４、６２６、および６２８は、サービス挿入レイヤ６０２およびサービストランスポートレイヤ６０４であるサービスプレーンの２つの異なるレイヤを実装する。サービス挿入レイヤ６０２は、（１）データメッセージのサービスチェーンを識別し、（２）サービスチェーンのサービス動作を実行するために使用するサービスパスを選択し、（３）選択されたサービスパス内の各ホップにあるネクストホップサービスノードを識別し（サービスチェーンの完了時にデータメッセージが戻されるべき送信元ホストコンピュータの識別を含む）、（４）サービスパスに対して、データメッセージのサービスメタデータ（ＳＭＤ）ヘッダ属性を指定する。いくつかの実施形態におけるＳＭＤ属性は、ＩＥＴＦ(Internet Engineering Task Force)のＲＦＣ(Request for Comments)８３００によるネットワークサービスヘッダ（ＮＳＨ）属性を含む。

【0040】

[0079] 一方、サービストランスポートレイヤ６０４は、サービスオーバーレイカプセル化ヘッダを定式化し、サービスホップ間を通過できるように、このヘッダでデータメッセージをカプセル化する。いくつかの実施形態では、サービストランスポートレイヤ６０４は、サービスオーバーレイカプセル化ヘッダを生成するようにＳＭＤヘッダを修正する。例えば、これらの実施形態のいくつかでは、オーバーレイカプセル化ヘッダは、ＧｅｎｅｖｅヘッダのTLV(タイプ、長さ、値）セクションに格納されたＳＭＤ属性をもつＧｅｎｅｖｅヘッダである。他の実施形態では、サービストランスポートレイヤ６０４は、サービスオーバーレイカプセル化ヘッダを、データメッセージをカプセル化するために最初に使用されるＳＭＤヘッダに追加する。また、同じホストコンピュータ上で実行される２つのホップ間（例えば、２つのサービスノード間）を横断する場合、以下に説明するいくつかの実施形態におけるサービストランスポートレイヤは、いくつかの実施形態において、オーバーレイカプセル化ヘッダでデータメッセージをカプセル化しない。他の実施形態では、同じホストコンピュータ上の２つのホップ間を横断する場合でも、サービストランスポートレイヤはオーバーレイカプセル化ヘッダでデータメッセージをカプセル化する。

【0041】

[0080] いくつかの実施形態では、サービス挿入（ＳＩ）レイヤ６０２は、ＳＩプリプロセッサ６１０とＳＩポストプロセッサ６１２とを含み、各２つのＩＯチェーン６５０および６５２（すなわち、１つ以上のサービスチェーンが定義されているＧＶＭの出口ＩＯチェーン６５０および入口ＩＯチェーン６５２）内に含まれる。ＳＩレイヤ６０２はまた、サービスプレーンに接続された各サービスノードのためのサービスプロキシ６１４を含む（例えば、サービスプレーンＬＦＥポートと対になったＶＮＩＣを有する各ＳＶＭのため）。サービストランスポートレイヤ６０４は、１つ以上のサービスチェーンが定義されている１つ以上の可能な送信元ＧＶＭを有する各ホストコンピュータ上に、１つのＳＴＬポートプロキシ６２０を含む。また、ＳＴレイヤ６０４は、（１）各送信元ＧＶＭの各ＩＯチェーン内のＳＴＬ呼出元６２４、（２）各ＳＶＭのＩＯチェーン内のＳＴＬモジュール６２６、および（３）１つ以上のカプセル化プロセッサ６２８を有する。

【0042】

[0081] ＧＶＭの入口または出口データパスを通過するデータメッセージの場合、このデータパス上のＳＩプリプロセッサ６１０は、いくつかの動作を実行する。データメッセージのサービスチェーンを識別し、識別されたサービスチェーンのサービスパスを選択する。また、プリプロセッサは、選択されたサービスパス内の第１ホップサービスノードのネットワークアドレスを識別し、データメッセージのＳＭＤ属性を指定する。ＳＭＤ属性は、いくつかの実施形態では、サービスチェーン識別子（ＳＣＩ）、ＳＰＩおよびＳＩ値、およびサービスチェーンのサービス動作を処理するための方向（例えば、順方向または逆方向）を含む。いくつかの実施形態では、ＳＰＩ値はサービスパスを識別し、ＳＩ値はサービスノードの数を指定する。

【0043】

[0082] ＳＩプリプロセッサがその動作を完了した後、同じデータパス内のＳＴＬ呼出元６２４は、ＳＴＬポートプロキシ６２０を呼び出して、プリプロセッサが識別したＳＭＤ属性と第１ホップのネットワークアドレスを中継し、それにより、ポートプロキシは、サービスプレーンを介してＳＭＤ属性を第１ホップに転送することができる。ポートプロキシは、第１サービスノードに転送するためにデータメッセージを定式化する。いくつかの実施形態では、この定式化は、データメッセージ内のオリジナルの送信元および宛先ＭＡＣアドレスを、送信元ＧＶＭ１０２および第１ホップサービスノードのＭＡＣアドレスに関連するサービスプレーンＭＡＣアドレスに置き換えることを含む。この定式化は、同じホストコンピュータ上の他のサービストランスポートレイヤモジュール（例えば、他のＳＴＬモジュールなど）によって処理されるべきデータメッセージのための属性の集合も格納する。これらのデータメッセージ属性には、オリジナルの送信元と宛先のＭＡＣアドレスだけでなく、ＳＭＤ属性も含まれる。

【0044】

[0083] ＳＴＬポートプロキシ６２０は、定式化されたデータメッセージをその記憶された属性と共にソフトウェアスイッチ１２０に渡す。定式化されたデータメッセージの宛先ＭＡＣアドレス（つまり、第１ホップＭＡＣアドレス）に基づいて、ソフトウェアスイッチは、第１ホップＳＶＭに関連付けられたスイッチポートにデータメッセージを配信する。第１ホップがポートプロキシ６２０と同じホストコンピュータ上にあるとき、データメッセージは、同じホストコンピュータ上の第１ホップのサービスノードの入口ＩＯチェーン内のＳＴＬモジュール６２６に提供される。第１ホップが同じホストコンピュータ上にないとき、データメッセージはカプセル化ヘッダでカプセル化され、後述するように、次のホップに転送される。

【0045】

[0084] 各ホップのＳＴＬモジュール６２６は、サービスプレーンの送信元ＭＡＣアドレスおよびサービスプレーンの宛先ＭＡＣアドレス（すなわち、そのサービスノードのＭＡＣアドレス）をデータメッセージの元の送信元および宛先ＭＡＣアドレスに置き換えることによって、データメッセージを再定式化する。次に、この再定式化されたデータメッセージを、それに付随するＳＭＤ属性と共に、そのホップのサービスプロキシ６１４に渡す。このサービスプロキシは、ＧＶＭの入口データパスのＩＯチェーンにある。図６の図が不要に詳細で複雑すぎることを防ぐために、この例の各ＳＶＭの入口パスと出口パスは、ＧＶＭ１０２の入口パスと出口パス６５０および６５２とは異なり、この図で結合されている。

【0046】

[0085] サービスプロキシ６１４は、データメッセージのＳＭＤ属性を格納するカプセル化ＮＳＨヘッダを用いて受信データメッセージをカプセル化し、サービスノードがＮＳＨヘッダをサポートできるとき、このカプセル化データメッセージをサービスノードに提供する。サービスノードがＳＶＭである場合、以下にさらに説明するように、いくつかの実施形態では、サービスプロキシは、ＶＮＩＣインジェクション処理を通じて、データメッセージとそのＮＳＨヘッダをＳＶＭのＶＮＩＣに供給する。サービスノードがＮＳＨヘッダを処理できないとき、サービスプロキシ６１４はＳＭＤ属性をレガシーＱｉｎＱカプセル化ヘッダまたはＧＲＥカプセル化ヘッダに格納し、カプセル化されたデータメッセージをＳＶＭのＶＮＩＣに渡す。これらのヘッダについては、以下でさらに説明する。

【0047】

[0086] いくつかの実施形態では、各サービスホップのサービスプロキシ６１４は、サービストランスポートレイヤからそのホップのサービスノードを分離する。この分離により、ＳＶＭとサービストランスポートレイヤの両方のセキュリティが向上する。また、サービスプロキシは、ＳＶＭに提供されるデータメッセージが適切に定式化されていることを確認できる。これは、新しいＮＳＨ形式をサポートしていない従来のＳＶＭでは特に重要である。

【0048】

[0087] いくつかの実施形態におけるサービスプロキシ６１４は、サービスノードが動作可能であることを保証するために、そのサービスノードと共にライブネス検出シグナリングも実行する。いくつかの実施形態では、サービスプロキシは、それぞれの反復時間周期に少なくとも１回、そのサービスノードにライブネス値（liveness value）をもつデータメッセージを送信する。これを行うために、サービスプロキシはタイマーを設定し、リセットして、サービスノードに期間ごとにライブネス信号を送信したことを確認する。各ライブネス値には、サービスプロキシがＳＶＭから提供されたライブネス応答を追跡できるようにするライブネスシーケンス番号が付随する。サービスノードは、ライブネス信号に応答するたびに、いくつかの実施形態では応答データメッセージ内の同一のライブネス値、または他の実施形態では応答データメッセージ内の対応する値をサービスプロキシに提供する。また、各ライブネス応答データメッセージと共に、サービスノードは、いくつかの実施形態では同じシーケンス番号、または他の実施形態ではサービスプロキシによって提供されるシーケンス番号のインクリメントされたバージョンを提供する。

【0049】

[0088] 以下にさらに説明するように、いくつかの実施形態のサービスプロキシは、サービスフォワーディングプレーンからそのサービスノードに渡す各データメッセージ上で、そのライブネス検出シグナリングの一部をピギーバックする。サービスプロキシは、サービスノードにライブネス信号を送信するたびに、そのライブネスタイマーをリセットする。サービスノードは、データメッセージを処理するたびに、応答ライブネス値および関連するシーケンス番号（いくつかの実施形態ではインクリメントされるか、または上述のように他の実施形態ではインクリメントされない）をサービスノードに提供する。

【0050】

[0089] いくつかの実施形態では、サービスプロキシは、サービスノードが特定の時間内（例えば、０．３秒以内）にそのライブネス信号に応答しないとき、ライブネス検出障害を登録する。２つの連続したライブネス検出障害を登録した後、いくつかの実施形態のサービスプロキシは、ＳＶＭが障害を起こしたホスト上で実行しているローカル制御プレーン（ＬＣＰ）モジュールに通知し、ＬＣＰが中央制御プレーン（ＣＣＰ）サーバに通知できるようにする。このような通知に応じて、ＣＣＰはＳＶＭとＳＶＭが存在するサービスパスをデータプレーンの転送ルールとパス選択ルールから削除し、必要に応じて、障害が発生したＳＶＭの関連サービスチェーンに追加のサービスパスを生成する。また、いくつかの実施形態では、サービスプロキシは、故障したサービスノードが存在するサービスパスを選択しないようにその分類器をプログラムするために、帯域内データメッセージを送信元ＧＶＭに送り返す。

【0051】

[0090] いくつかの実施形態では、サービスプロキシはまた、そのサービスノードの最上位でフロープログラミングを実行する。いくつかの実施形態におけるこのフロープログラムは、送信元ＧＶＭのＩＯチェーンがサービスパスに沿ってサービスチェーン、サービスパス、および／またはデータメッセージフローを選択する方法を修正することを含む。他の実施形態では、このフロープログラムは、データメッセージフローがサービスプレーンによって処理される方法に対する他の修正を含む。以下、フロープログラムについてさらに説明する。

【0052】

[0091] データメッセージとそのＳＭＤ属性（カプセル化ＮＳＨヘッダまたは他のカプセル化ヘッダ）を受信すると、ＳＶＭはサービス動作を実行する。いくつかの実施形態では、ＳＶＭは、サービスマネージャから受信したマッピングレコードを使用して、ＳＭＤ属性内のＳＣＩ、ＳＩ、および方向の値をサービスプロファイルにマッピングし、このサービスプロファイルをそのルールセットの１つにマッピングし、次に、このサービスプロファイルを調べて、処理する１つ以上のサービスルールを識別する。いくつかの実施形態では、各サービスルールは、データメッセージ属性（例えば、送信元および宛先ＩＰアドレス、送信元および宛先ポートアドレスおよびプロトコルである５つのタプル属性）に関して定義されるルール識別子を有する。いくつかの実施形態におけるＳＶＭは、ルールの識別子をデータメッセージの属性と比較して、一致するルールを識別する。１つ以上の一致ルールを識別すると、いくつかの実施形態では、ＳＶＭは、最高優先度の一致ルールによって指定されたアクションを実行する。たとえば、ファイアウォールＳＶＭは、データメッセージの通過を許可するか、ドロップするか、またはリダイレクトするかを指定し得る。

【0053】

[0092] ＳＶＭがサービス動作を完了すると、ＳＶＭはその出口データパスに沿ってデータメッセージを転送する。次に、出口データパスのＩＯチェーンのサービスプロキシは、このデータメッセージをキャプチャし、このデータメッセージについて、サービスパス内のネクストホップのネットワークアドレスを識別する。これを行うために、いくつかの実施形態におけるサービスプロキシは、ＳＩ値をデクリメントし、次いで、データメッセージの記憶された属性セット内のＳＰＩ値と共に、このデクリメントされた値を使用して、ネクストホップネットワークアドレスを識別する完全一致転送ルールを識別する。実施形態によっては、ＳＶＭはＳＩ値をデクリメントすることができる。このような場合、いくつかの実施形態のサービスプロキシは、対応するＳＶＭがＳＩ値をデクリメントしたときにＳＩ値をデクリメントしないように構成されることができる。

【0054】

[0093] どちらの構成でも、サービスプロキシは適切なＳＰＩ／ＳＩ値を使用して、データメッセージに適用可能なネクストホップ転送ルールを識別することで、ネクストホップネットワークアドレスを識別する。プロキシのサービスノードが複数のサービスパスにある場合、プロキシの転送ルール記憶装置には、異なるサービスパスに関連付けられた異なるＳＰＩ／ＳＩ値に異なるネクストホップネットワークアドレスを指定できる複数の完全一致転送ルールが格納される。デクリメントされたＳＩ値がゼロでないと仮定すると、サービスパスのネクストホップは別のサービスノードになる。それゆえ、いくつかの実施形態におけるプロキシは、ＳＶＭの出口データパスにおいて、ネクストホップのＭＡＣアドレスをプロキシの関連するＳＴＬモジュール６２６に提供する。次に、このモジュールは、ＳＶＭのＭＡＣアドレスとネクストホップのＭＡＣアドレスを送信元と宛先のＭＡＣアドレスとして指定し、データメッセージに格納されている属性セットにデータメッセージの元の(original)送信元と宛先のＭＡＣアドレスを格納することによって、データメッセージを再定式化する。次に、ＳＴＬモジュール６２６は、データメッセージを出口パスに沿って転送し、そこでソフトウェアスイッチに到達し、そこで、データメッセージとその格納された属性をネクストホップサービスノードに転送しなければならない。

【0055】

[0094] ネクストホップが同じホストコンピュータ上にある場合、ソフトウェアスイッチは、前述のように、データメッセージとその属性を、ネクストホップのサービスノードのＳＴＬモジュールに接続するポートに渡す。一方、ネクストホップサービスノードが別のホストコンピュータ上にある場合、ソフトウェアスイッチは、他のホストコンピュータ上のＶＴＥＰとオーバーレイネットワークトンネルを介して通信するVTEP(VXLAN Tunnel Endpoint)に接続するアップリンクポートにデータメッセージを提供する。次に、カプセル化プロセッサ６２８は、このポートの出口パスに沿ってこのデータメッセージを捕捉し、このデータメッセージのカプセル化オーバーレイヘッダを定義し、このオーバーレイヘッダでデータメッセージをカプセル化する。いくつかの実施形態では、オーバーレイヘッダは、ＳＭＤ属性とＳＴＬ属性の両方を格納する単一のヘッダである。例えば、いくつかの実施形態では、オーバーレイヘッダは、１つ以上のＴＬＶにＳＭＤおよびＳＴＬ属性を格納するＧｅｎｅｖｅヘッダである。

【0056】

[0095] 上述したように、いくつかの実施形態におけるＳＭＤ属性は、ＳＣＩ値、ＳＰＩ値、ＳＩ値、およびサービス方向を含む。また、いくつかの実施形態では、ＳＴＬ属性は、オリジナルＬ２送信元ＭＡＣアドレス、オリジナルＬ２宛先ＭＡＣアドレス、データメッセージ方向、および送信元ＧＶＭのサービスプレーン送信元ＭＡＣアドレスを含む。いくつかの実施形態では、サービス方向およびサービスプレーン送信元ＭＡＣアドレスは、すでにＳＭＤ属性の一部である。いくつかの実施形態でのサービストランスポートレイヤは、サービスパスの終わりに元のデータメッセージとその後を再作成するため、データパスに沿って戻るようにデータメッセージを元のホストに戻すために、処理された各データメッセージと共にこれらの属性を必要とする。

【0057】

[0096] カプセル化されたデータメッセージがネクストホップのホストコンピュータで受信されると、データメッセージは、前ホップのＶＴＥＰからデータメッセージを受信したＶＴＥＰに接続するソフトウェアスイッチのダウンリンクポートのカプセル化（encap）プロセッサ６２８によってキャプチャされる。このカプセル化プロセッサは、データメッセージからカプセル化ヘッダを除去し、ＳＴＬ属性とＳＭＤ属性をデータメッセージの属性のセットとして格納する。その後、カプセル解除されたメッセージをダウンリンクポートに渡し、ソフトウェアスイッチに渡してネクストホップのスイッチポートに転送する。そこから、データメッセージは、前述のように、サービスノードに到達する前に、ＳＴＬモジュールとサービスプロキシによって処理される。

【0058】

[0097] サービスプロキシがデクリメントされたＳＩ値がゼロであると判断すると、サービスプロキシはデクリメントされたＳＩ 値と埋め込みＳＰＩ値を照合し、ネクストホップを送信元ＧＶＭのサービスプレーンＭＡＣアドレスとして識別するようにサービスプロキシに指示するルールを使用する。いくつかの実施形態では、この判定は、転送テーブルの転送エントリによって指定されず、むしろサービスプロキシのロジックにハードコーディングされる。したがって、ＳＩ値がゼロであるとき、プロキシは、データメッセージをＧＶＭのホストコンピュータに転送するために使用するために、送信元ＧＶＭのサービスプレーンＭＡＣアドレスを、その関連するＳＴＬモジュール６２６に提供する。次に、ＳＴＬモジュールは、メッセージの送信先ＭＡＣ(DMAC)アドレスを送信元ＧＶＭのサービスプレーンＭＡＣアドレスとして定義し、一方、メッセージの送信元ＭＡＣ(SMAC)アドレスをそのサービスノードに関連付けられたサービスプレーンＭＡＣアドレスとして定義する（たとえば、サービスノードに関連付けられたソフトウェアスイッチのポートのサービスプレーンＭＡＣ）。また、データメッセージのオリジナルのＳＭＡＣとＤＭＡＣをデータメッセージの属性セットに格納する。

【0059】

[0098] ＳＴＬモジュールは、定式化されたデータメッセージとその属性を出口パスに沿って渡し、そこで関連するソフトウェアスイッチポートに到達する。その後、ソフトウェアスイッチはこのメッセージをアップリンクポートに渡す。次に、このポートのカプセル化プロセッサ６２８は、このデータメッセージを捕捉し、このデータメッセージのカプセル化オーバーレイヘッダを定義し、このオーバーレイヘッダでデータメッセージをカプセル化する。前述したように、このオーバーレイヘッダは、１つ以上のＴＬＶにＳＭＤおよびＳＴＬ属性を格納するＧｅｎｅｖｅヘッダである。このカプセル化されたデータメッセージは、次にオーバーレイネットワークを通過して送信元ＧＶＭのホストコンピュータに到達し、そこでこのデータメッセージはダウンリンクポートのカプセル化プロセッサによりカプセル解除され、その後ソフトウェアスイッチに提供され、その後ポートプロキシに転送される。

【0060】

[0099] ポートプロキシ６２０は、カプセル解除されたデータメッセージを受信すると、カプセル解除されたデータメッセージの記憶された属性の一部となっているオリジナルの宛先ＭＡＣアドレスから、このデータメッセージに関連するＧＶＭを識別する。いくつかの実施形態では、ポートプロキシは、受信データのＳＭＤ属性におけるオリジナルの送信元ＭＡＣアドレスとサービス方向を、そのホスト上のＧＶＭ（例えば、ゲスト転送プレーンと関連付けられたソフトウェアスイッチポートとそのホスト上のＧＶＭ）にマッピングするレコードを有する。次に、ポートプロキシは、オリジナルのＳＭＡＣとＤＭＡＣを含むようにデータメッセージを定式化し、データメッセージを送信元ＧＶＭのＩＯチェーンに戻す。次に、このＩＯチェーン内のＳＩポストプロセッサ６１２は、このデータメッセージを処理してから、このデータメッセージをＧＶＭの出口データパスに戻す。このポストプロセッサの動作については、以下にさらに説明する。

【0061】

[00100] 当業者は、他の実施形態におけるサービス挿入レイヤおよびサービストランスポートレイヤが、上述の例示的な実施形態とは異なるように実装されることを認識するであろう。例えば、異なるサービスホップを横断するためにＭＡＣアドレスに依存するＬ２オーバーレイ（Ｌ２トランスポートレイヤ）を使用する代わりに、他の実施形態は、Ｌ３および／またはＬ４ネットワークアドレスを使用して連続するサービスホップを識別するＬ３オーバーレイ（Ｌ３トランスポートレイヤ）を使用する。また、上記のサービス挿入および／またはトランスポートモジュールは、異なった動作をするように構成されることができる。

【0062】

[00101] サービス挿入レイヤおよびサービストランスポートレイヤの動作のより詳細な例を、図７－１９を参照して説明する。図７は、いくつかの実施形態のＳＩプリプロセッサ６１０およびＳＴＬ呼出元６２４によって実行される処理７００を示す。このプロセスは、図８に示されているデータフローの例を参照することによって以下に説明される。プロセス７００は、ＳＩプリプロセッサ６１０が呼び出されて、ＧＶＭの入口または出口データパスに沿って送信されるデータメッセージを分析するときに開始される。

【0063】

[00102] 図に示すように、処理７００は、最初に、（７０５において）プリプロセッサ６１０がデータメッセージのフローのためのサービスチェーンおよびサービスパスを事前に選択し、選択されたサービスチェーンおよびパスのためのＳＭＤ属性を記憶しているか否かを判定する。いくつかの実施形態では、処理７００は、データメッセージの属性（例えば、その５つのタプル属性）を使用して、サービスチェーンとパスが以前に選択されたメッセージフローのレコードを格納する接続トラッカーでメッセージのフローのレコードを識別しようとすることによって、この判定を行い、ＳＭＤ属性は、接続トラッカーレコードでこれらのチェーンとパスに対して以前に格納される。

【0064】

[00103] 図８は、プリプロセッサ６１０がＧＶＭ １０２の出口データパスに沿ってデータメッセージ８０２を受信する様子を示す。また、受信したデータメッセージの属性のセット（例えば、５つのタプル属性）に一致するフロー識別子（例えば、５つのタプル識別子）を有する接続レコードを見つけようとするために、プリプロセッサが最初に接続追跡記憶装置８０４をチェックすることを示す。この例では、受信されたデータメッセージがそのフローのための最初のデータメッセージであるため、プリプロセッサ６１０はそのような接続レコードを見つけることができない。

【0065】

[00104] 処理７００が、（７０５において）接続記憶装置８０４が、受信されたデータメッセージと一致する接続レコードを有することを判定すると、処理は、このレコードから、または一致する接続レコードによって参照される別のレコードからＳＭＤ属性を検索する（７１０において）。いくつかの実施形態におけるＳＭＤ属性は、ＳＣＩ、ＳＰＩ、ＳＩおよび方向値を含む。７１０から、プロセスは、後述する７４０に遷移する。

【0066】

[00105] 一方、処理７００が（７０５において）、接続記憶装置８０４が、受信されたデータメッセージと一致する接続レコードを持たないことを判定すると、処理は、図８に記憶装置８０６として示されているＳＩルール記憶装置内のサービス挿入ルールにデータメッセージを一致させようとする分類動作を（７１５において）実行する。いくつかの実施形態において、ＳＩルール記憶装置８０６は、１つ以上のデータメッセージフロー属性（例えば、５つのタプル属性の１つ以上またはそれらの部分）に関して定義されたルール識別子を有するサービス挿入ルール８２２を記憶する。各サービスルールは、サービスルールのルール識別子に一致するデータメッセージフローに適用可能なサービスチェーンを識別するＳＣＩも指定する。

【0067】

[00106] ７２０において、プロセスは、分類動作がデータメッセージの属性と、データメッセージ上で実行されるサービスチェーンを必要とするサービス挿入ルールのルール識別子とが一致するか否かを判定する。分類動作が、データメッセージに対してサービスチェーンを実行することを要求するサービス挿入ルールを識別しない場合、処理７００は終了する。いくつかの実施形態では、ＳＩルール保管８０６は、データメッセージの属性が任意のより高い優先度ＳＩルールに一致しないときに、任意のデータメッセージに一致するデフォルトの低優先度ルールを有し、このデフォルトの低優先度ルールは、データメッセージのフローに対してサービスチェーンが定義されていないことを指定する。データメッセージフローに対してサービス動作を実行する必要がない場合、いくつかの実施形態では、データメッセージフローに対してサービスチェーンは定義されない。

【0068】

[00107] 一方、分類動作が、データメッセージ上でサービスチェーンを実行することを要求するサービス挿入ルールのルール識別子にデータメッセージの属性が一致する場合、処理７００は、（７２５）パス選択動作を実行して、７１５で識別されるサービス挿入ルールによって指定されるサービスチェーンのサービスパスを選択する。図８に示すように、プリプロセッサ６１０は、サービスチェーン識別子ごとに１つ以上のサービスパスを識別するパス記憶テーブル８０８を調べることによって、パス選択動作を実行する。

【0069】

[00108] 各サービスパスは、そのＳＰＩ値で指定される。サービスチェーンに複数のサービスパスが指定されている場合、パス記憶装置８０８は、利用可能なＳＰＩから１つのＳＰＩを選択するための一連の選択指標８２０をサービスチェーンごとに格納する。様々な実施形態は、異なる選択指標を使用する。例えば、いくつかの実施形態は、サービスパスのサービスノードが実行されるホストの数に基づいてサービスパスをコストとする選択指標を使用する。他の実施形態では、これらの選択指標は、これらの重み値によって向けられるロードバランシングの態様で、プリプロセッサがサービスチェーンのＳＰＩを選択することを可能にする重み値である。例えば、いくつかの実施形態では、これらの重み値は、サービスパス内のサービスノードのそれぞれの負荷に基づいて、および／または他のコスト（サービスパスによって横断されるホストの数など）に基づいて、中央制御プレーンによって生成される。

【0070】

[00109] これらの実施形態のいくつかでは、プリプロセッサは、特定のサービスチェーンに対して行った以前の選択のレコードを維持し、これらの以前の選択に基づいて後続のサービスパスを選択する。たとえば、４つのサービスパスの場合、重み値は１、２、２、１となる。これは、サービスチェーンに対して６回連続してＳＰＩを選択する場合、最初のＳＰＩを１回選択し、次に２番目と３番目のＳＰＩをそれぞれ２回選択し、４番目のＳＰＩを１つ選択することを特定する。このサービスチェーンの次のＳＰＩ選択では、選択メカニズムがラウンドロビンであるため、最初のＳＰＩが選択される。

【0071】

[00110] 他の実施形態では、重み値は、数値範囲（例えば、ハッシュ値の範囲）に関連付けられ、データメッセージフローを数値範囲およびそれによってその関連ＳＰＩにマッピングするために、各データメッセージフローに対してランダムにまたは決定論的に生成される。さらに他の実施形態では、ホストＬＣＰは、利用可能なサービスパスのプールから各サービスチェーン識別子に対して１つのサービスパスを選択し、そのため、各ＳＣＩに対して１つのＳＰＩのみをパステーブル８０８に格納する。これらの実施形態におけるＬＣＰは、コスト（各サービスパスによって横断されるホストの数および／またはサービスパスのサービスノード上の負荷など）に基づいて、各サービスチェーンのサービスパスを選択する。

【0072】

[00111] 識別されたサービスチェーンについてのサービスパスを識別した後、プロセス７００は次に、選択されたサービスパスの最初のホップのためのネットワークアドレスを（７３０において）識別する。いくつかの実施形態では、このホップのためのＭＡＣアドレスは、選択されたパスのＳＰＩと同じレコードに格納される。したがって、これらの実施形態では、このＭＡＣアドレスは、選択されたＳＰＩと共にパス選択記憶装置８０８から取り出される。他の実施形態では、プリプロセッサは、図８に示すように、ＳＰＩ／ＳＩ値の関連するペアのネクストホップネットワークアドレスを格納する完全一致転送テーブル８１０からファーストホップのＭＡＣアドレスを取り出す。いくつかの実施形態では、サービスチェーンの初期ＳＩ値は、ＳＩルール記憶装置８０６のＳＩルールに格納され、一方、他の実施形態では、これらの最初のＳＩ値は、そのパステーブル８０８内のＳＰＩ値と共に格納される。

【0073】

[00112] ７３５において、処理７００は、データメッセージのＳＭＤ属性を指定し、これらの属性をデータメッセージに関連付ける。上述したように、ＳＭＤ属性は、いくつかの実施形態では、ＳＣＩ、ＳＰＩ、ＳＩおよび方向値を含む。サービスパスのサービス方向は、サービスチェーンを通る方向がサービスパスに依存するので、パステーブル８０８内のＳＰＩ値と共に格納される。また、以下に述べるように、いくつかの実施形態におけるサービスチェーンは、第１のＧＶＭから第２のＧＶＭへのデータメッセージに対して順方向に実行され、次いで、第２のＧＶＭから第１のＧＶＭへのデータメッセージに対して逆方向に実行されなければならない。このようなサービスチェーンの場合、プリプロセッサ６１０は、第１のＧＶＭから第２のＧＶＭへのフロー内の最初のデータメッセージを処理するときに、順方向のサービスパスと逆方向のサービスパスの両方を選択する。

【0074】

[00113] ＳＩプリプロセッサがその動作を完了した後、ポートプロキシがサービスプレーンを介して最初のホップにＳＭＤ属性を転送できるように、ＳＴＬポートプロキシ６２０は、同じデータパス内のＳＴＬ呼出元６２４が、ＳＭＤ属性と、プリプロセッサが識別した最初のホップのネットワークアドレスとを中継する（７４０において）。サービス挿入レイヤおよびサービストランスポートレイヤにおけるポートプロキシ６２０および他のモジュールの動作は、図９－１９を参照して説明される。これらの図は、ＳＶＭ１０６、次にＳＶＭ１０８、次にＳＶＭ１１０を含むサービスパスを介してＧＶＭ１０２からのデータメッセージを処理する例を説明する。

【0075】

[00114] これらの図では、各ＧＶＭはマルチテナントデータセンタのテナントのコンピューティングマシンであり、テナントのゲストVNI (GVNI)に関連付けられたスイッチポートを介してソフトウェアスイッチに接続する。また、これらの図では、各ＳＶＭは、ＧＶＭメッセージトラフィックを処理するためのサービスマシンであり、テナントのサービスVNI (SVNI)に関連付けられたスイッチポートを介してソフトウェアスイッチに接続されている。上記および以下にさらに説明するように、いくつかの実施形態は、テナントのためのサービス論理転送動作（すなわち、サービス論理転送要素、例えば、論理スイッチまたはルーター、またはサービス論理ネットワークを確立するため）を実行するためにＳＶＮＩを使用しながら、テナントのためのゲスト論理転送動作（すなわち、ゲスト論理転送要素、例えば、論理スイッチまたはルーター、またはゲスト論理ネットワークを確立するため）を実行するためにＧＶＮＩを使用する。

【0076】

[00115] これらの論理ネットワーク識別子（すなわち、ＧＶＮＩおよびＳＶＮＩ）の両方は、いくつかの実施形態において、管理プレーンまたは制御プレーンによってテナントのために生成される。いくつかの実施形態の管理または制御プレーンは、異なるテナントに対して異なるＧＶＮＩおよびＳＶＮＩを生成し、２つのテナントが同じＧＶＮＩまたはＳＶＮＩを持たないようにする。いくつかの実施形態では、各ＳＶＭは、１つのテナント専用であり、一方、他の実施形態では、１つのＳＶＭは、複数のテナントによって使用され得る。マルチテナントの状況では、各ＳＶＭは、テナントごとに異なるサービスプレーンの異なるポート（異なる論理スイッチなど）に接続できる。

【0077】

[00116] 図９に示すように、ポートプロキシ６２０は、データメッセージ内のオリジナルの送信元および宛先ＭＡＣアドレスを、送信元ＧＶＭ１０２および第１ホップサービスノードのＭＡＣアドレスに関連付けられたサービスプレーンＭＡＣアドレスに置き換えることによって、第１のサービスノードに転送するためのデータメッセージを定式化する。この動作は、図１０のプロセス１０００における動作１００５として描かれている。このプロセス１０００は、ＳＩモジュール（ＳＩプリプロセッサ６１０またはＳＩプロキシ６１４など）がデータメッセージを処理するときに、ポートプロキシ６２０またはＳＴＬモジュール６２６が必ず開始するプロセスである。

【0078】

[00117] このプロセス１０００では、ポートプロキシは、同じホストコンピュータ上の他のサービストランスポートレイヤモジュール（例えば、ｖｓｗｉｔｃｈ、他のＳＴＬモジュール、カプセル化プロセッサなど）によって処理されるべきデータメッセージのための属性のセットに、データメッセージのオリジナルの送信元および宛先ＭＡＣアドレスも（１０１０において）追加する。再定式化されたデータメッセージ９０２および拡張属性セット９０４は、図９に描かれている。

【0079】

[00118] データメッセージを再定式化し、その属性セットを増強した後、ポートプロキシ６２０は、定式化されたデータメッセージを、その格納された属性セットと共に、ソフトウェアスイッチ１２０に到達する出口パスに沿って（１０１５において）渡す。定式化されたデータメッセージの宛先ＭＡＣアドレス（例：ファーストホップＭＡＣアドレス）に基づいて、ソフトウェアスイッチは（１０２０で）ネクストホップのポートがローカルかどうかを判定する。これは、図９に示す例の場合であるため、ソフトウェアスイッチは（１０２５で）データメッセージを第１ホップのＳＶＭ１０６に関連付けられたスイッチポートに配信する。次に、このポートは、ＳＶＭの入口パスに沿ってデータメッセージを送信し、図９に示すように、データメッセージ９０２とその拡張属性セット９０４は、第１ホップのＳＶＭの入口ＩＯチェーンの関数呼び出しを通じてＳＴＬモジュール６２６によって識別される。

【0080】

[00119] 次に、このＳＴＬモジュール６２６は、ＧＶＭのサービスプレーンＭＡＣアドレスおよび第１ホップＭＡＣアドレス（すなわち、ＳＶＭ１０６のＭＡＣアドレス）を、拡張属性セット９０４から取得するデータメッセージの元の送信元および宛先ＭＡＣアドレスに置き換えることによって、データメッセージを（１０３０において）再定式化する。オリジナルのＳＭＡＣおよびＤＭＡＣアドレスを検索する際に、ＳＴＬモジュール６２６は、データメッセージの属性セットを変更する。再定式化されたデータメッセージ９０６および修正された属性セット９０８は、図９に描かれている。ＳＴＬモジュールは、次に、この再定式化されたデータメッセージを、それに付随するＳＭＤ属性と共に、ＳＶＭの入口パスに沿って渡し、これは、このホップの入口サービスプロキシ６１４によって次に処理される。

【0081】

[00120] 図１１は、サービスプロキシ６１４が、サービスノードの入口パスに沿って横断するデータメッセージを受信するたびに、いくつかの実施形態において実行する処理１１００を示す。図に示すように、サービスプロキシは、必要に応じて、最初に（１１０５において）データメッセージのコピーを作成する。例えば、いくつかの実施形態では、サービスノードは、その動作を実行するためにデータメッセージのコピーを受信するだけでよい。このようなサービスノードの一例は、メッセージ監視またはミラーリング動作のためにデータメッセージコピーを取得する必要がある監視ＳＶＭを提供する。

【0082】

[00121] これらの実施形態では、サービスプロキシは、データメッセージをコピーし、このコピーに関して残りの操作１１１０～１１２５を実行する一方で、元のデータメッセージを次のサービスホップに渡すか、または送信元ＧＶＭに戻す。元のデータメッセージをネクストサービスホップに転送するか、ＧＶＭに戻すには、サービスプロキシは、ＳＰＩ／ＳＩ値に基づいてネクストホップルックアップを実行し、次に転送するＳＴＬモジュールにネクストホップアドレス（たとえば、ネクストサービスホップのアドレスまたは送信元ＧＶＭのサービスプレーンＭＡＣ）を提供する必要がある。これらのルックアップおよび転送動作は、図１５－１７を参照して後述するものと同様である。

【0083】

[00122] 次に、１１１０において、サービスプロキシは、データメッセージの記憶されたＳＭＤ属性セット（いくつかの実施形態では、この時点でのデータメッセージコピーであってもよい）にライブネス属性を設定する。このライブネス属性は、データメッセージを処理した後に、応答ライブネス値（同じ値または関連する値）をデータメッセージとともに提供するようにサービスノードに指示する値である。このライブネス属性を使用すると、サービスプロキシはシーケンス番号も提供する。サービスノードは、前述のように、応答性のあるライブネス値を使用して、サービスノードを戻すか、インクリメントしてから戻る必要がある。

【0084】

[00123] １１１５において、サービスプロキシは、必要に応じて、データメッセージを定式化して、サービスノードによって処理可能な形式にする。例えば、サービスノードがデータメッセージの宛先ＭＡＣとして設定されている現在のネクストホップＭＡＣを知らない場合、サービスプロキシはメッセージの宛先ＭＡＣをサービスノードに関連付けられた宛先ＭＡＣに変更する。

【0085】

[00124] サービスノードに転送するためにデータメッセージをサニタイズするように定式化した後、サービスプロキシ６１４は、使用するように構成できる３つのカプセル化ヘッダのうちの１つでデータメッセージを（１１２０において）カプセル化し、サービスノードの入口パスに沿ってカプセル化されたメッセージを（１１２５において）サービスノードに転送できるように通過させる。図９は、サービスプロキシからネイティブＮＳＨカプセル化ヘッダを使用してＳＶＭ１０６に渡されるカプセル化されたデータメッセージ９２０を示す。図に示すように、カプセル化ヘッダ９２２は、サービスチェーン識別子、サービスインデックス、サービスチェーン方向およびライブネス信号を含む。

【0086】

[00125] 図１２は、（１）ＮＳＨをサポートするサービスノードのネイティブＮＳＨカプセル化ヘッダ１２０５、（２）ＮＳＨをサポートしないレガシーサービスノードのＧＲＥカプセル化ヘッダ１２１０、（３）ＮＳＨをサポートしないレガシーサービスノードのＱｉｎＱカプセル化ヘッダ１２１５である、いくつかの実施形態の３つのカプセル化ヘッダを図示する。ネイティブＮＳＨヘッダは、サービスメタデータを、図２１および図２２を参照して以下に記述されるフォーマットで格納する。ＧＲＥヘッダフォーマットについては、図２５－２６を参照して以下でさらに説明する。ＧＲＥとＱｉｎＱの両方のフォーマットでは、サービスメタデータの一部はＧＲＥとＱｉｎＱヘッダフィールドに格納されるが、サービスメタデータはネイティブＮＳＨヘッダに格納されているほど豊富に格納することはできない。ＱｉｎＱヘッダは、あまりサービスメタデータを必要としない単純なレガシーサービスノードに使用される。たとえば、単にサービスチェーン識別子とサービス方向、またはサービスチェーン識別子とサービスインデックスを必要とするだけである。このサービスメタデータは、ＱｉｎＱヘッダのＶＬＡＮヘッダフィールドに格納される。

【0087】

[00126] 図１２は、カプセル化ヘッダ１２０５、１２１０、１２１５の３つの異なるタイプに加えて、いくつかの実施形態のＳＶＭのｖｍｘｎｅｔ３準仮想化（paravirtualized）ＮＩＣ１２４０も示す。図に示すように、このネットワークインタフェースカードは、カプセル化されたデータメッセージを、ＳＶＭのＤＰＤＫドライバ１２０４のポーリングモードドライバ１２０２、または割り込みモードドライバ１２０４に提供することができる。具体的には、ｖｍｘｎｅｔ３準仮想化ネットワークインタフェースカードは、ＳＶＭ内部でどのドライバが使用されているかに応じて、異なる動作モードで動作するように構成されることができる。ポーリングモードドライバ１２０２は、ＤＰＤＫ(データプレーン開発キット）ドライバ１２０６のバックエンドとして見ることができる。ポーリングモードドライバは、データメッセージを取得するためにＶＮＩＣを定期的にポーリングし、一方、ＶＮＩＣは割り込みを生成して、割り込みベースドライバ１２０４にデータメッセージを取得させる。

【0088】

[00127] ポーリングモードドライバは、データメッセージをＤＰＤＫドライバ１２０６に渡し、その後、フローが最初に受信されると、それをユーザ空間内のメッセージ処理モジュールに渡す。一方、割り込みベースのドライバ１２０４は、カーネル内またはユーザ空間内のいずれかで、データメッセージをメッセージ処理モジュール１２１２に提供する。次に、ＳＶＭのメッセージ処理モジュールは、カプセル化されたデータメッセージをカプセル解除し、ＳＶＭのサービス動作を実行する。いくつかの実施形態では、異なるＳＶＭは、データメッセージで受信するＳＣＩ、ＳＩおよびサービス方向値に基づいて異なるサービス動作を実行する。

【0089】

[00128] 図１３は、サービスプロキシから処理するデータメッセージを受信するたびにＳＶＭがいくつかの実施形態で実行する１つの例示的なプロセス１３００を示す。他の実施形態では、ＳＶＭは、ＳＣＩ、ＳＩおよびサービス方向値を異なる方法で使用して、その動作を実行することができる。示されるように、処理１００は、最初に（１３０５において）カプセル化ヘッダを除去し、そこからＳＣＩ、ＳＩ、方向およびライブネスパラメータを取得する。次に、プロセスは、サービスマネージャから受信した（１３１０での）マッピングレコードを使用して、ＳＣＩ、ＳＩ、および方向の値をサービスプロファイルにマッピングし、次に（１３１５で）このサービスプロファイルをそのルールセットの１つにマッピングし、次にそれを調べて、処理する１つ以上のサービスルールを識別する（１３２０で）。

【0090】

[00129] 図１４は、ＳＶＭの第１のマッピングテーブル１４０５を示す。図に示すように、このテーブルの各レコードは、ＳＣＩ、ＳＩ、および方向の値をサービスプロファイルにマップする。この図は、ＳＶＭの第２のマッピングテーブル１４１０も示しており、このテーブルは、サービスプロファイルを、サービスルールテーブル１４１５内のいくつかのルールを識別するルールセット識別子にマッピングする。図１４に示すように、いくつかの実施形態のサービス挿入マネージャは、第１のテーブル１４０５のレコードを提供し（例えば、ＳＩネットワークマネージャは、ＳＶＭのサービスマネージャにこれらのレコードを提供し、ＳＶＭはＳＶＭにそれらのレコードを提供する）、一方、ＳＶＭのサービスマネージャは、第２および第３のテーブル１４１０および１４１５のレコードを提供する。いくつかの実施形態では、これら２つのサービスマネージャは、２つの異なるエンティティ、例えば、データセンタ管理者とサードパーティ管理者、またはテナント管理者とデータセンタ管理者によって管理される２つの異なる管理プレーンである。

【0091】

[00130] いくつかの実施形態では、サービスルールテーブル１４５内の各サービスルール１４２０は、データメッセージ属性（例えば、５つのタプル属性）に関して定義されるルール識別子を有する。ＳＶＭは、（１３２０で）ルールの識別子をデータメッセージの属性と比較して、一致するルールを識別する。１つ以上の一致ルールを識別すると、いくつかの実施形態のＳＶＭは、最高優先度の一致ルールによって指定されたアクションを（１３２５において）実行する。たとえば、ファイアウォールＳＶＭは、データメッセージの通過を許可するか、ドロップするか、またはリダイレクトするかを指定できる。

【0092】

[00131] ＳＶＭがサービス動作を完了すると、ＳＶＭはデータメッセージをカプセル化ヘッダで（１３３０で）カプセル化する。これは、サービス動作によってデータメッセージがドロップされないことを前提としている。このカプセル化ヘッダは、ＳＶＭが受信したデータメッセージと同じ形式（ＮＳＨヘッダ、ＧＲＥヘッダ、ＱｉｎＱヘッダなど）である。このカプセル化ヘッダでは、いくつかの実施形態のＳＶＭは、（１）サービスプロキシのライブネス値に応答するライブネス値と（２）ライブネス値の適切なシーケンス番号（例えば、調整されていないか、またはインクリメントされたシーケンス番号）を設定する。

【0093】

[00132] いくつかの実施形態では、一部のサービスノードは、それらが受信するＳＩ値をデクリメントするように構成され、一方、他のサービスノードはＳＩ値をデクリメントするように構成されない。サービスノードがＳＩ値をデクリメントするように設定されている場合、１３３０でカプセル化ヘッダにデクリメントされたＳＩ値を挿入する前に、ＳＩ値をデクリメントする。いくつかの実施形態におけるＳＶＭはまた、カプセル化ヘッダにＳＭＤ属性（ＳＣＩ、ＳＩおよびサービス方向）を設定するが、他の実施形態では、出口パスにおけるサービスプロキシは、データメッセージをＳＶＭに渡す前にサービスプロキシが作成した以前のレコードからこれらの値を取得する。

【0094】

[00133] いくつかの実施形態では、ＳＶＭはまた、カプセル化ヘッダにフロープログラム属性を設定して、データメッセージのフローのサービス処理を変更するようにサービスプロキシに指示することができる。この流れプログラムについては、以下にさらに説明する。データメッセージをカプセル化した後、ＳＶＭはその出口パスに沿ってデータメッセージを転送する。図１５は、ＳＶＭ１０６がカプセル化されたデータメッセージ１５０２を、そのカプセル化ヘッダ１５０４内のＳＭＤおよびライブネス属性と共に返す例を示す。

【0095】

[00134] 図１６は、サービスプロキシ６１４が、そのサービスノードの出口パスに沿って横断するデータメッセージを受信するたびに、いくつかの実施形態において実行する処理１６００を示す。示されているように、いくつかの実施形態におけるサービスプロキシは、最初に（１６０５において）データメッセージからカプセル化ヘッダを除去し、このヘッダからＳＭＤ属性を除去し、データメッセージのために作成する属性セットにこれらの属性を格納する。いくつかの実施形態では、サービスプロキシは、データメッセージを入口パスに沿ってサービスノードに与える前にサービスプロキシが作成した以前のレコードから、ＳＭＤ属性の一部または全部（例えば、ＳＰＩ値、送信元ＧＶＭのサービスプレーンＭＡＣアドレス）を（１６０５において）取得する。図１５は、サービスプロキシ６１４がカプセル解除されたデータメッセージ１５０７に対して作成する属性セット１５０６の例を示す。

【0096】

[00135] 次に、１６１０のプロセスは、サービスノードから受信したライブネス値を考慮して保持するライブネスタイマー（例えば、０．２５秒ごとに期限切れになるタイマー）をリセットする。これは、このノードがまだ動作可能であることを意味する。このライブネス値を使用すると、サービスプロキシはサービスノードからシーケンス番号を受信する。このシーケンス番号は、受信する必要がある次のライブネス値であることを確認するためにプロセスによって検証される。

【0097】

[00136] １６１５で、プロセスは、ＳＶＭが任意のフロープログラム属性を指定したかどうかを判定する。この属性は、送信元ＧＶＭがフロープログラムを実行するために、サービスプロキシがＳＩポストプロセッサ６１２にインバンドデータメッセージをポストプロセッサ６１２に送信することを要求する。いくつかの実施形態では、サービスプロキシは、送信元ＧＶＭに送り返すために生成する別のデータメッセージと共に帯域内フロープログラミング制御信号を送信し、そこでポストプロセッサ６１２によって傍受される。

【0098】

[00137] 送信元ＧＶＭがフロープログラミング制御信号と共にデータメッセージを受信すると、そのポストプロセッサは、このフローに固有のフロー識別子を使用することによって、適用先のデータメッセージフローを一意に識別することができる。以下でさらに説明するように、このフロー識別子は、送信元ＧＶＭの一意の識別子に部分的に基づいて導出される。一意のフロー識別子により、サービスノード、サービスプロキシ、ＳＴＬモジュールなどの他のサービスプレーンモジュールも、各データメッセージフローを一意に識別できる。いくつかの実施形態におけるこのユニークなフロー識別子は、サービスパスのサービスホップ間で渡され、送信元ＧＶＭに戻されるＳＭＤ属性の一部である。

【0099】

[00138] しかしながら、いくつかの実施形態では、サービスプロキシは、処理中の現在のデータメッセージと共に帯域内フロープログラミング制御信号を送信する。これらの実施形態のいくつかでは、サービスプロキシは、その関連サービスノードがサービスパスの最終ホップのサービスノードである場合にのみこれを行い、一方、他の実施形態では、そのサービスノードが最終ホップのサービスノードでない場合でもこれを行う。サービスノードがサービスパスの最終ホップのサービスノードでないとき、サービスプロキシはデータメッセージのＳＭＤ属性にフロープログラムを埋め込み、これは、いくつかの実施形態では、最終ホップのサービスが実行されるとき、データメッセージカプセル化ヘッダの一部として最終的に送信元ＧＶＭのＳＩポストプロセッサに転送される。この状況でも、他の実施形態における最終ホップのサービスプロキシは、フロープログラミング信号を別個のメッセージとして送信する。

【0100】

[00139] フロープログラム信号については、図２０を参照して以下にさらに説明する。また、以下にさらに説明するように、サービスプロキシは、送信元ＧＶＭの分類器が現在のデータメッセージフローと同様に他のデータメッセージフローのために別のサービスパスを選択できるように、サービスノードが故障したことを検出したときに、フロープログラム信号を送信元ＧＶＭに送り返す。このような状況では、サービスプロキシはホストコンピュータ上のＬＣＰ にも通知するため、ＬＣＰ はＣＣＰ に通知でき、ＣＣＰ は障害が発生したサービスノードを使用するサービスチェーンに指定されたサービスパスを変更できる。

【0101】

[00140] １６２０において、処理１６００は、そのサービスノードがデータメッセージをドロップすべきであると指定したか否かを決定する。その場合、プロセスはデータメッセージをドロップしてから終了する。さもなければ、データメッセージはドロップされるべきではなく、そのサービスパスに沿って継続すべきであると仮定すると、いくつかの実施形態では、サービスプロキシは、サービスノードがＳＩ値をデクリメントしていない場合にＳＩ値を（１６２５において）デクリメントし、次いで、（１６３０において）このデクリメントされた値をデータメッセージの記憶された属性セット内のＳＰＩ値と共に使用して、ネクストホップネットワークアドレスを識別する完全一致転送ルールを識別する。プロキシのサービスノードが複数のサービスパスにある場合、プロキシの転送ルール記憶装置には、異なるＳＰＩ／ＳＩ値に異なるネクストホップネットワークアドレスを指定できる複数の完全一致転送ルールが格納される。

【0102】

[00141] 減少したＳＩ値がゼロであるとき、いくつかの実施形態では、サービスプロキシは、減少したＳＩ値と、サービスプロキシに送信元ＧＶＭのサービスプレーンＭＡＣアドレスとしてネクストホップを識別するように指示するルールをもつ埋め込みＳＰＩ値とを照合する。いくつかの実施形態におけるこのルールは、ＭＡＣアドレスを提供せず、むしろ、データメッセージのために記憶されたＳＭＤ属性セットの一部であるサービスプレーンＭＡＣアドレスを参照する。いくつかの実施形態では、ＳＩ値がゼロであるときにデータメッセージを送信元ＧＶＭのサービスプレーンＭＡＣアドレスに戻すためのこの命令は、転送テーブルの転送エントリによって指定されず、むしろサービスプロキシのロジックにハードコーディングされる。

【0103】

[00142] １６３０において、サービスプロキシは、データメッセージのために格納される属性セットにネクストホップネットワークアドレス（例えば、ＭＡＣアドレス）を格納する。図１５は、カプセル解除されたデータメッセージ１５０７のアトリビュートセット１５０６内の次のサービスノードに関連するネクストホップＭＡＣアドレスを記憶するサービスプロキシ６１４の例を示す。ネクストホップネットワークアドレスを識別した後、サービスプロキシはそのサービスノードの出口パスにデータメッセージを（１６３５において）返し、処理１６００は終了する。

【0104】

[00143] サービスプロキシがデータメッセージをサービスノードの出口パスに戻すと、ＳＴＬモジュール６２６はこのデータメッセージを受信し、図１０のプロセス１０００を開始する。ＳＴＬモジュール６２６は、サービス挿入レイヤからデータメッセージを受信するたびに、このプロセスの最初の３つの動作１００５～１０１５を実行する。具体的には、ＳＴＬモジュールは、データメッセージ内の元の送信元および宛先ＭＡＣアドレスを、現在のサービスホップおよびネクストサービスホップのサービスプレーンＭＡＣアドレス（すなわち、図１５に示される例ではｈｏｐ１ｍａｃおよびｈｏｐ２ｍａｃアドレス）に置き換えることによって、ネクストホップサービスノードに転送するためのデータメッセージを（１００５において）定式化する。

【0105】

[00144] １０１０において、ＳＴＬモジュールは、同じホストコンピュータ上の他のサービストランスポートレイヤモジュール（例えば、ｖｓｗｉｔｃｈ、カプセル化プロセッサ等）によって処理されるべきデータメッセージのための属性のセットに、データメッセージの元の(original)送信元および宛先ＭＡＣアドレスも追加する。再定式化されたデータメッセージ１５０８および拡張属性セット１５１０は、図１５に描かれている。データメッセージを再定式化し、その属性セットを拡張した後、ＳＴＬモジュール６２６は、出口パスに沿って定式化されたデータメッセージを（１０１５において）通過させ、そこで次にソフトウェアスイッチ１２０に到達する。

【0106】

[00145] 定式化されたデータメッセージの宛先ＭＡＣアドレス（すなわち、ネクストホップＭＡＣアドレス）に基づいて、ソフトウェアスイッチは、（１０２０において）ネクストホップのポートがローカルでないことを決定する。したがって、ソフトウェアスイッチは、図１５の例に示すように、ホスト１１４上のＶＴＥＰ２とオーバーレイネットワークトンネルを介して通信するＶＴＥＰ１に接続するアップリンクポート１５５０にデータメッセージを（１０３５で）提供し、このアップリンクポート（１０４０で）の出口パスに沿うＳＴＬカプセル化プロセッサ６２８は、このデータメッセージを受信し（例えば、アップリンクポートに指定されたフックの１つとして呼び出される）、このデータメッセージのためのカプセル化オーバーレイヘッダ１５４０を定義し、このオーバーレイヘッダでデータメッセージをカプセル化する。

【0107】

[00146] いくつかの実施形態では、オーバーレイヘッダは、ＳＭＤおよびＳＴＬ属性をその１つ以上のＴＬＶに格納するＧｅｎｅｖｅヘッダである。上述したように、いくつかの実施形態におけるＳＭＤ属性は、ＳＣＩ値、ＳＰＩ値、ＳＩ値、およびサービス方向を含む。また、いくつかの実施形態では、ＳＴＬ属性は、オリジナルのＬ２送信元ＭＡＣアドレスとオリジナルのＬ２宛先ＭＡＣアドレスを含む。図１５は、このカプセル化ヘッダの例を示しており、これについては、図２８を参照して以下でさらに説明する。

【0108】

[00147] カプセル化されたデータメッセージがネクストホップのホストコンピュータ１１４で受信されると、データメッセージは、オーバーレイネットワークトンネルを介して前ホップのＶＴＥＰに接続するＶＴＥＰに接続するダウンリンクポート１５５２のＳＴＬカプセル化プロセッサ６２８によってキャプチャされる（例えば、フックとして定義される）。図１７は、コンピュータ上で実行されるＳＶＭによって処理される必要があるカプセル化されたデータメッセージを受信するネクストホップコンピュータ上のカプセル化プロセッサ６２８によって開始されるプロセス１７００を示す。

【0109】

[00148] 図に示すように、このカプセル化プロセッサは、（１７０５において）カプセル化ヘッダをデータメッセージから除去し、（１７０５において）ＳＴＬおよびＳＭＤ属性をデータメッセージの関連する属性セットとして格納する。次に、カプセル解除されたメッセージをダウンリンクポートに（１７１０で）渡し、それからソフトウェアスイッチに渡して（１７１５で）、ネクストホップＳＶＭに接続されているポート（つまり、宛先ＭＡＣアドレスに関連付けられているポート）に転送する。次に、このポートは、ＳＶＭ１０８の図１５の例に示すように、データメッセージ１５０８と属性セット１５１０をネクストホップＳＶＭの入口パスに渡す。

【0110】

[00149] 次に、この入口パス上のＳＴＬモジュール６２６は、前および現在のホップサービスプレーンＭＡＣアドレス（すなわち、ｈｏｐ１ｍａｃおよびｈｏｐ２ｍａｃ）を、データメッセージ属性セットから取得するデータメッセージの元の送信元および宛先ＭＡＣアドレスに置き換えることによって、データメッセージを（１７２０において）再定式化する。オリジナルのＳＭＡＣおよびＤＭＡＣアドレスを検索する際に、ＳＴＬモジュール６２６は、データメッセージの属性セットを変更する。再定式化されたデータメッセージ１５３０および修正された属性セット１５３２は、図１５に描かれている。次に、ＳＴＬモジュールは、この再定式化されたデータメッセージを、それに付随するＳＭＤ属性と共に、ＳＶＭの入口パスに沿って渡し、そこで、このホップの入口サービスプロキシ６１４によって次に処理される。

【0111】

[00150] このサービスプロキシの動作は、図９および図１１を参照して上述したようになる。図１５は、カプセル化されたデータメッセージをＳＶＭに渡すホスト１１４上のＳＶＭ１０８のサービスプロキシを示す。このデータメッセージのカプセル化ヘッダは、ＳＶＭ１０８によってサポートされ、ＳＣＩ、ＳＩ、サービス方向およびライブネス値を格納する。いくつかの実施形態では、同じサービスパスの一部であるＳＶＭは、異なるカプセル化ヘッダをサポートする。これらの実施形態のいくつかでは、サービスパスに沿ったサービスプロキシは、データメッセージをそれらの関連ＳＶＭに渡す前に、異なるカプセル化ヘッダでデータメッセージをカプセル化することができる。たとえば、１つのケースでは、最初のホップサービスプロキシはＮＳＨカプセル化ヘッダを含むデータメッセージをＳＶＭ１０６に渡し、２番目ホップサービスプロキシはＱｉｎＱカプセル化ヘッダを含むデータメッセージをＳＶＭ１０８に渡す。

【0112】

[00151] ＳＶＭ１０８がデータメッセージ（図１３のプロセス１３００など）に対してサービス動作を実行すると、ＳＶＭは、図１８に示すように、処理されたデータメッセージを出口データパスに沿って送信する。次に、サービスプロキシは、次のサービスホップのＭＡＣアドレスを識別し、このＭＡＣアドレスをデータメッセージに設定されている保存済み属性に追加する。この時点で、ネクストホップは３番目のサービスホップで、ＳＶＭ１１０に対応する。このプロキシは、ＳＩ値をデクリメントして（ＳＶＭ１０８がＳＩ値をデクリメントしなかった場合）、次に埋め込まれたＳＰＩ値とデクリメントしたＳＩ値を使用して、ネクストホップのＭＡＣアドレスを提供する転送ルールを検索することによって、このＭＡＣを識別する。次に、この出口パス内のＳＴＬモジュールは、データメッセージ内のオリジナルのＳＭＡＣおよびＤＭＡＣを現在のホップおよびネクストホップＭＡＣアドレス（すなわち、図１８の例ではｈｏｐ２ｍａｃおよびｈｏｐ３ｍａｃ）に置き換え、オリジナルのＳＭＡＣおよびＤＭＡＣをデータメッセージの格納された属性セットに格納し、その後、ソフトウェアスイッチ１２２によって受信される出口パスに沿ってデータメッセージを渡す。

【0113】

[00152] 次に、ソフトウェアスイッチは、ネクストホップがそのアップリンクポート１５５２に関連付けられていると判断し、データメッセージをこのポートに渡す。図１８に示すように、このポートの出口パス上のカプセル化プロセッサ６２８は、次いで、ＳＭＤおよびＳＴＬ属性を１つ以上のＴＬＶに格納するＧｅｎｅｖｅヘッダと共にデータメッセージをカプセル化し、データメッセージが、ホスト１１６のポート１５５４に関連するこのポートの関連するＶＴＥＰ２からＶＴＥＰ３へ横断することを指定する。

【0114】

[00153] 次に、ポート１５５４の入口パス内のＳＴＬカプセル化プロセッサ６２８は、データメッセージからカプセル化ヘッダを除去し、ＳＴＬおよびＳＭＤ属性をデータメッセージの関連する属性セットとして格納する。次に、カプセル解除されたメッセージをポート１５５４に渡し、その後、それをソフトウェアスイッチ１２４に渡して、ネクストホップＳＶＭ １１０に接続されているそのポート（すなわち、サービスプレーンＤＭＡＣに関連付けられているそのポート）に転送する。次に、このポートは、図１８に示すように、このＳＶＭの入口パスに設定されたデータメッセージと属性を渡す。

【0115】

[00154] この入口パスのＳＴＬモジュール６２６は、前および現在のホップサービスプレーンＭＡＣアドレス（すなわち、ｈｏｐ２ｍａｃおよびｈｏｐ３ｍａｃ）を、データメッセージ属性セットから取得するデータメッセージの元の送信元および宛先ＭＡＣアドレスに置き換える。ＳＴＬモジュール６２６はまた、元のＳＭＡＣおよびＤＭＡＣアドレスを除去することによってデータメッセージの属性セットを修正し、次いで、このホップの入口サービスプロキシ６１４が処理するために、ＳＶＭの入口パスに沿って、その付随するＳＭＤ属性と共に再定式化されたデータメッセージを渡す。このサービスプロキシは、ＳＶＭ１１０によってサポートされるカプセル化ヘッダを持ち、ＳＣＩ、ＳＩ、サービス方向、およびライブネス値を格納したカプセル化されたデータメッセージをＳＶＭ１１０に渡す。

【0116】

[00155] ＳＶＭ１１０がこのデータメッセージに対してサービス動作を実行すると（例：図１３のプロセス１３００ごと）、ＳＶＭは、図１９に示すように、その出口データパスに沿って処理されたデータメッセージを送信する。サービスプロキシは、ＳＶＭ１１０がまだ実行していないと仮定した場合、ＳＩ値をデクリメントする。この例では、デクリメントされたＳＩ値はゼロになる。いくつかの実施形態では、サービスプロキシは、次いで、このＳＩ値とＳＰＩ値とを、送信元ＧＶＭのサービスプレーンMAC (spmac)をネクストホップＭＡＣアドレスとして選択すべきであることを指定する転送ルールのルール識別子と照合する。他の実施形態では、サービスプロキシのハードコードされたロジックは、送信元ＧＶＭのサービスプレーンＭＡＣをネクストホップＭＡＣとして識別するようにそれに向ける。いずれの場合も、サービスプロキシは送信元ＧＶＭ のサービスプレーンＭＡＣ をデータメッセージの属性セットに追加する。

【0117】

[00156] ＳＴＬモジュールは、次に、データメッセージ内のオリジナルのＳＭＡＣおよびＤＭＡＣを、第３ホップＭＡＣアドレスおよび送信元ＧＶＭのサービスプレーンＭＡＣで置き換え、オリジナルのＳＭＡＣおよびＤＭＡＣをデータメッセージの格納された属性セットに格納し、その後、そのデータメッセージをそのソフトウェアスイッチ１２４に渡す。次に、ソフトウェアスイッチは、ネクストホップがそのポート１５５４に関連付けられていると判断し、データメッセージをこのポートに渡す。図１９に示すように、このポートの出口パス上のカプセル化プロセッサ６２８は、次に、ＳＭＤおよびＳＴＬ属性を１つ以上のＴＬＶに格納するＧｅｎｅｖｅヘッダでデータメッセージをカプセル化し、データメッセージが、ホスト１１２のポート１５５０に関連付けられているこのポートの関連するＶＴＥＰ３からＶＴＥＰ１に通過することを指定する。

【0118】

[00157] 次に、ポート1550の入口パス内のＳＴＬカプセル化プロセッサ６２８は、データメッセージからカプセル化ヘッダを除去し、ＳＴＬおよびＳＭＤ属性をデータメッセージの関連する属性セットとして格納する。次に、カプセル解除されたメッセージをポート１５５０に渡し、その後、それをソフトウェアスイッチ１２０に渡して、ポートプロキシ６２０に接続されたそのポートに転送する。次に、このポートは、図１９に示すように、データメッセージと属性セットをポートプロキシ６２０に渡す。

【0119】

[00158] 次に、ポートプロキシ６２０は、前および現在のホップサービスプレーンＭＡＣアドレス（すなわち、ｈｏｐ３ｍａｃおよびｓｐｍａｃ）を、データメッセージの元の送信元および宛先ＭＡＣアドレスに置き換え、これは、データメッセージ属性セットから取得する。また、ポートプロキシ６２０は、データメッセージの属性セットを修正して、オリジナルのＳＭＡＣおよびＤＭＡＣを除去し、その後、この再定式化されたデータメッセージを、それに付随するＳＭＤ属性と共に、最初にそれを呼び出したＳＴＬ呼出元６２４に戻す。いくつかの実施形態では、ポートプロキシは、ＳＴＬ呼出元が最初にそれを呼び出したときに作成した接続レコードを使用して、コールバックするＳＴＬ呼出元を識別する。他の実施形態では、ポートプロキシは、各サービスプレーンＭＡＣをＧＶＭのＳＴＬ呼出元とマップするマッピングテーブルを使用する。いくつかの実施形態におけるマッピングテーブルは、サービスプレーンＭＡＣおよびサービス方向を、ＧＶＭに関連するゲスト転送プレーンポート識別子に関連付けるレコードを有する。

【0120】

[00159] 一旦呼び出されると、ＳＴＬ呼出元はデータメッセージをＧＶＭ １０２の出口パスに沿って渡し、そこで次にＳＩポストプロセッサ６１２に転送される。図２０は、いくつかの実施形態においてＳＩポストプロセッサ６１２が実行する処理２０００を示す。ポストプロセッサは、ＧＶＭのＩＯチェーンに沿って渡されるデータメッセージを受信するたびに、この処理２０００を実行する。図示のように、いくつかの実施形態におけるポストプロセッサ６１２は、最初に、ＳＩポスト処理のために受信データメッセージを検査する必要があるかどうかを（２００５で）判定する。これは、ＧＶＭのＩＯチェーンに沿ったモジュールとして、ポストプロセッサがこのＩＯチェーンを通過するすべてのデータメッセージフローに対して呼び出され、これらのデータメッセージの一部が、それらに対してサービス挿入操作を実行する必要があるＳＩルールと一致しない可能性があるためである。いくつかの実施形態では、プロセス２０００は、データメッセージが関連するサービスメタデータを有するか否かを決定することによって、データメッセージを処理する必要があるか否かを（２００５で）決定する。そうでない場合、プロセスは２０２０に遷移し、以下で説明する。

【0121】

[00160] ＳＩポストプロセッサ６１２がデータメッセージを処理する必要があると判断すると、プロセスは、データメッセージに関連するＳＭＤメタデータがフロープログラミング動作を実行することをポストプロセッサに要求するフロープログラムタグを指定するかどうかを（２０１０で）判定する。いくつかの実施形態では、このようなフロープログラムタグは、送信元ＧＶＭでのサービスパス処理を変更するためにサービスノードによって、またはサービスノードの障害を検出したときと同じ理由のためにサービスプロキシによって、データメッセージのＳＭＤ属性で指定されるであろう。フロープログラムタグがフロープログラムを指定しない場合、プロセスは以下で説明する２０２０に遷移する。

【0122】

[00161] そうでない場合、フロープログラムタグがフロープログラミング動作を指定すると、処理２０００はこの動作を実行した後、２０２０に遷移する。フロープログラミング動作は、いくつかの実施形態において、コネクション追跡記憶装置８０４内のコネクションレコードを修正して、データメッセージのフローに対する所望の動作および／またはＳＭＤ属性（例えば、許可、ドロップなど）を指定することを伴う。接続トラッカー８０４へのポストプロセッサの書き込みは、図１９に示されている。上述し、さらに後述するように、処理されたデータメッセージのためのＳＭＤメタデータは、送信元ＧＶＭの一意のサービスプレーン識別子から少なくとも部分的に導出されることによってデータメッセージのフローを一意に識別するフロー識別子を含む。ポストプロセッサ６１２は、このフロー識別子を使用して、いくつかの実施形態における接続トラッカーにおけるデータメッセージのフローを照合する。

【0123】

[00162] いくつかの実施形態では、フロープログラムタグは、次の動作、（１)アクションが不要な場合（フロープログラム操作が実行されない）に何もしない（NONE）、（２）このフローのそれ以上のデータメッセージがサービスチェーンに沿って転送されず、代わりに送信元ＧＶＭでドロップされる必要がある場合にドロップする（DROP）、（３）このフローのそれ以上のデータメッセージがサービスチェーンに沿って転送されず、代わりにフローが送信元ＧＶＭで受け入れられる必要がある場合、アクセプトする（ACCEPT）ことを指定することができる。いくつかの実施形態では、フロープログラムはＤＲＯＰ＿ＭＥＳＳＡＧＥを指定することもできる。ＤＲＯＰ＿ＭＥＳＳＡＧＥは、サービスノードがプロキシと通信する必要があり（ｐｉｎｇ 要求に応答する場合など）、送信元でのフロープログラムが必要ないにもかかわらず、ユーザーデータメッセージ（存在する場合）をドロップする必要がある場合に使用される。

【0124】

[00163] いくつかの実施形態では、サービスプロキシがＳＶＭの障害を内部的に通信するために、追加のアクションが利用可能である。この動作は、いくつかの実施形態では、ＳＩポストプロセッサに、データメッセージのフローのための別のサービスパス（例えば、別のＳＰＩ）を選択するように指示する。いくつかの実施形態におけるこのアクションは、いくつかの実施形態における適切なメタデータフィールドを設定することによって、ユーザデータメッセージと共にバンド内で運ばれる。たとえば、以下でさらに説明するように、サービスプロキシは、データプレーンを介した帯域内データメッセージトラフィックを介して、ＮＳＨ属性のOAM(Operation, Administration, and Maintenance)メタデータを介して送信元ＧＶＭのポストプロセッサと通信する。設計フロープログラムアクションが信号遅延の影響を受け、損失の対象となることを考慮すると、ＳＶＭまたはサービスプロキシは、フロープログラムアクションをプロキシに通信した後、しばらくの間、送信元でドロップ、アクセプト、またはリダイレクトされると予測されるフローに属するデータメッセージを引き続き表示する場合がある。この場合、サービスプレーンは、送信元でドロップ、許可、またはリダイレクトするアクションを引き続き設定する必要がある。

【0125】

[00164] 処理２０００は、フロープログラミング動作完了後、２０２０に遷移する。また、（２００５で）データメッセージに対してＳＩポスト処理を実行する必要がないと判断するか、このデータメッセージに対してフロープログラムを実行する必要がないと判断すると、２０２０に移行する。２０２０では、処理２０００は、データメッセージをＧＶＭ１０２の出口パスを通過させてから、終了する。

【0126】

[00165] 図８、９、１５、１８、および１９を参照して前述した例は、送信元ＧＶＭの出口パスに沿って識別されるデータメッセージ上で実行されるサービスプレーン動作を示す。これらのサービスプレーン動作（図７、１０－１４、１６、１７、および２０を参照して説明）は、送信元ＧＶＭの入口パスに沿って通過すると識別されるデータメッセージにも同様に適用可能である。これらの入口側動作を実行するために、入口パス上のＳＩプリプロセッサおよびポストプロセッサ６１０および６１２は、出口パス上のこれら２つのプロセッサの位置と比較して反転される。具体的には、図６に示すように、プリプロセッサ６１０は、このＧＶＭのＶＮＩＣに関連するソフトウェアスイッチポートからＧＶＭの入口パスに入るデータメッセージを受信する一方、ポストプロセッサ６１２は、入口ＩＯチェーンに沿って処理されたデータメッセージをＧＶＭのＶＮＩＣに渡す。

【0127】

[00166] しかしながら、入口側処理のためのサービス挿入とサービス転送動作は、特定のＧＶＭとの間のデータメッセージの出口側処理に類似している。場合によっては、このＧＶＭは別のＧＶＭとデータメッセージを交換する。図４および５を参照して上述したように、サービスプレーンは、各方向のデータメッセージ上で同じサービスチェーンを実行するように向けることができるが、逆の順序で行うことができる。このような場合、入口側のサービスパスのサービスノードは、他のＧＶＭが特定のＧＶＭ に送信するデータメッセージのサービスチェーンの第１の方向に対して一連のサービス動作を実行する。一方、出口側のサービスパスのサービスノードは、同じ一連のサービス動作を実行するが、サービスチェーンを介して反対の第２の方向に実行する。また、上述したように、順方向および逆方向のためのサービスノードの２つのセットは、いくつかの実施形態において同じサービスノードを含む。

【0128】

[00167] いくつかの実施形態で使用されるヘッダフォーマットは、次に、図２１、２２、および２５～２８を参照して説明される。図２１は、いくつかの実施形態におけるサービスプロキシのいくつかが、データメッセージをそれらの関連するサービスノードに提供する前にデータメッセージをカプセル化するために使用するＮＳＨヘッダ２１００を示す。これらの実施形態のいくつかでは、サービスノードは、このようなＮＳＨヘッダでカプセル化された処理されたデータメッセージを返す。いくつかの実施形態では、ＮＳＨヘッダは、ホストコンピュータのサービスプレーンモジュールによって、二重にカプセル化されたデータメッセージを他のホストコンピュータに転送するためにも使用され、第１のカプセル化ヘッダはＮＳＨヘッダであり、第２のカプセル化ヘッダはサービストランスポートヘッダである。しかしながら、他の実施形態では、サービス挿入およびサービストランスポート属性は、後述するように、１つのカプセル化ヘッダに配置される。また、上記および以下にさらに説明するように、いくつかの実施形態におけるサービスプロキシおよびサービスノードは、それらが交換するデータメッセージをカプセル化するためにＮＳＨヘッダを使用しない。

【0129】

[00168] 示されているように、ＮＳＨヘッダの最初の８バイトのすべてのフィールドは、ＲＦＣ ８３００に準拠して使用される。このヘッダは、いくつかの実施形態では、固定長メタデータコンテンツヘッダ２１１０を含む。また、いくつかの実施形態では、（１）１にセットされるＭＤタイプ、（２）イーサネット通信を示すために３である次のプロトコル値、および（３）ＭＤコンテンツヘッダ２１１０が固定長であるために６であるレングス値を含む。また、いくつかの実施形態では、ＳＰＩおよびＳＩフィールド２１２２および２１２４は、送信元ＧＶＭのプリプロセッサ６１０がそれを定義するときの初期ＳＩ値（すなわち、サービスホップの初期数）である、選択されたパスのサービスパス識別子および現在のサービスインデックス値で埋められる。

【0130】

[00169] いくつかの実施形態では、サービス挿入モジュールは、データメッセージと共に運ばれるＮＳＨヘッダを除き、メタデータを記憶またはキャッシュメモリしない。このモデルでは、サービスノードは変更する予定のないメタデータフィールドを保持する。いくつかの実施形態では、特定のメタデータフィールドは、サービスプロキシ／ノードと送信元ＧＶＭのサービスモジュールとの間のデータプレーン仲介シグナリングのための通信メカニズムとして使用される。いくつかの実施形態では、データメッセージメタデータは、ＮＳＨ固定長コンテキストヘッダ２１１０において、線上で符号化される。いくつかの実施形態では、この固定サイズのヘッダは、合計１６バイトの情報を提供する。いくつかの実施形態では、各サービス挿入配置は、独自のＭＤコンテンツフォーマットを自由に定義することができる。

【0131】

[00170] 図２２は、サービスホップ、サービスノード、および／またはサービスプロキシにサービスメタデータを送信するために、いくつかの実施形態においてＭＤコンテンツヘッダ２１１０に格納されるメタデータコンテンツの例を示す。示されているように、このヘッダには、多数のフィールドを含む１６バイトがある。１つのフィールド２２０２は、Ｆビットを含み、これは、ＭＤコンテンツヘッダ内のコンテンツのタイプ、例えば、サービスメタデータコンテンツ、フロープログラムコンテンツなどを区別するために使用される。いくつかの実施形態では、サービスメタデータコンテンツのＦビットはｂ００である。別のフィールド２２０４は、Ｐビットを格納し、これを１にセットして、サービスノードによるデータメッセージへの応答を強制することができる。いくつかの実施形態では、応答は、Ｐビットも１にセットされた要求と同じシーケンス番号を含むＮＳＨヘッダを伴わなければならない。

【0132】

[00171] 送信元ノード識別子（ＩＤ）フィールド２２０６は、サービスプレーンについて、データメッセージの送信元またはシンクであるデータ計算ノード（例えば、ＧＶＭ）を明確に識別する。いくつかの実施形態では、送信元ノードＩＤは、データメッセージがサービスプレーンに挿入されたこの送信元データ計算ノード（ＤＣＮ）のサービスプレーンＭＡＣアドレスを含む。ＭＤコンテンツヘッダはまた、ライブネス検出の目的のためにデータメッセージを識別する不透明な６ビット値であるシーケンス番号２２０８を含む。この値は、サービスプロキシが、そのライブネス検出の一部としてそのサービスノードにデータメッセージを転送する前にいっぱいになった場合を除き、通常ゼロである。

【0133】

[00172] ＭＤ コンテンツヘッダには、マルチテナントデータセンタのテナントを一意に識別するテナントＩＤ２２１２も含まれている。いくつかの実施形態におけるテナントＩＤは、テナントに関連するＶＮＩである。ＭＤコンテンツヘッダ２２００は、さらに、フローＩＤ２２１５およびフローＩＤ有効ビット２２２２を含む。いくつかの実施形態では、フローＩＤの残りの部分（フロータグとも呼ばれる）が存在するとき、フローＩＤ有効性ビットは１に設定される。フローＩＤ２２１５は、フローおよび送信元ＤＣＮ毎に（すなわち、フローおよび送信元ノードＩＤ ２２０６毎に）固有の識別子である。いくつかの実施形態では、フローＩＤは、送信元ＤＣＮの分類器（例えば、分類動作を実行するＳＩプリプロセッサ６１０）によって設定される。

【0134】

[00173] いくつかの実施形態では、フローＩＤは、データメッセージがネイティブモードでない（すなわち、サービスがサービスプレーンを認識していない）サービスを横断するときに破棄されてもよい。この場合、以下で説明する互換モードヘッダでフローＩＤ を運ぶのに十分なビットがない場合、フローＩＤ は破棄される。また、フローＩＤは、ネイティブサービス（すなわち、サービスプレーン認識サービスノード）がフローＩＤを無意味にする方法でデータメッセージを修正するとき、例えば、サービスが複数のフローから単一のＩＰｓｅｃトンネルへのトラフィックを暗号化するとき、に破棄される可能性がある。この場合、内部データメッセージのフロータグを保持しても意味がない。いくつかの実施形態では、サービスノードは、この場合、Ａビットをゼロに設定する。

【0135】

[00174] ＭＤコンテンツヘッダ２２００はまた、サービスプロキシによるフロープログラムに使用されるアクションフィールド２２３０を含む。いくつかの実施形態では、アクションは、送信元ＤＣＮのポストプロセッサ６１２がフロー上で実行すべきアクションを指定する。フロープログラムの場合、いくつかの実施形態では、アクションフィールドは非ゼロでなければならない。さらに、フロープログラムのために、Ｆビット２２０２も１０にセットされ、Ｐビット２２０４はプロキシで０にセットされ、分類器によって無視され、フロー有効性ビット２２２２およびフロータグ２２１５が有効でなければならない。

【0136】

[00175] 以下は、アクションフィールド２２３０の値の１つの例示的なセットであるが、当業者は、他の実施形態では他の値が指定されていることを認識するであろう。アクションビットの値０は、フロープログラミングアクションが指定されないことを指定する。値１ は、データメッセージのフローのすべてのメッセージが送信元でドロップされる必要があり、このフローのそれ以上のデータメッセージはサービスプレーンに転送されないことを示す。代わりに、データメッセージは分類後に送信元でドロップする必要がある。

【0137】

[00176] アクションフィールドの値２は、データメッセージが送信元で受け入れられ、いくつかの実施形態では、同じフローのそれ以上のデータメッセージはサービス機能に転送されないことを指定する。代わりに、サービス関数をスキップし、チェーン内の次のサービスを直接呼び出す必要がある。アクションフィールドの値３は、このデータメッセージのみをドロップすることを指定し、同じフローの他のデータメッセージに対して実行する必要があるアクションを示すものではない。いくつかの実施形態では、このアクションは、サービスノードがサービスプロキシと通信し（例えば、ｐｉｎｇ要求に応答するため）、フロープログラムが起こるべきではないにもかかわらず、データメッセージがドロップされることを望むときに使用される。

【0138】

[00177] ＭＤコンテンツヘッダ２２００はまた、送信元ＤＣＮからネットワークの観点へのデータメッセージの方向を指定する方向フィールド２２１４を含む（例えば、ＤＣＮからネットワークへの方向は出口方向であり、ネットワークからＤＣＮへの方向は入口方向である）。方向フィールドの値０は、方向が不明でない場合に方向または不明な方向を示す。いくつかの実施形態では、値１は、データメッセージが入口方向に移動している（すなわち、データメッセージは、データメッセージの宛先である送信元ＤＣＮのために処理されている）ことを示し、例えば、データメッセージは、ＶＴＥＰからその対応するＤＣＮへのその途中にある。いくつかの実施形態における値２は、出口方向を示す（例えば、データメッセージは、データメッセージの送信元である送信元ＤＣＮに対して処理されている）。

【0139】

[00178] いくつかの実施形態では、値３は、データメッセージが単に転送中であり、入口と出口の両方に適用されることを示す。ルールを定義するために使用される場合、これは、いくつかの実施形態において、ルールが一方向または任意の方向のデータメッセージに一致する必要があることを示す。サービスの観点から、方向フィールドの値３は、このトラフィックが、いくつかの実施形態において、このトラフィックを供給することも同期することもない中継装置によってサービスプレーンに転送されたことを示す。いくつかの実施形態では、通過指示は、ルータを通過しているトラフィックに使用される。

【0140】

[00179] ＭＤコンテンツヘッダ２２００は、さらに、データメッセージが流れるべきサービスチェーンを指定するサービスチェーンＩＤ２２１６を含む。いくつかの実施形態は、ＳＣＩをＮＳＨヘッダに埋め込まず、代わりにＳＰＩ値を格納するだけである。しかしながら、多くのＳＰＩは同じサービスチェーンに対応することができ、ＳＰＩも永続的ではないので、他の実施形態は、ＳＣＩをファイル２２１６に格納する。言い換えると、いくつかの実施形態は、サービスチェーンＩＤを埋め込むが、これは、ＳＣＩが、サービスノードが、それらが処理するデータメッセージに一致するサービスルールを識別するために使用する、より安定した識別子をサービスノードに提供するためである。

【0141】

[00180] いくつかの実施形態では、サービスプロキシと送信元ＤＣＮのサービスポストプロセッサとの間でデータプレーンシグナリングを実行するために、サービスノードにさらされることなく、サービスプレーンによって内部的に他のメタデータコンテンツフォーマットが使用される。これらの実施形態のいくつかでは、他のメタデータコンテンツフォーマットが使用されるとき、ＮＳＨヘッダのＯＡＭビット（図２１のＯビット２１７０）がセットされ、ユーザペイロードは運ばれない（または、ＮＳＨによって必要とされるものがあれば、宛先では無視される）。いくつかの実施形態では、ＮＳＨ次のプロトコルフィールドは、この場合０に設定される。

【0142】

[00181] いくつかの実施形態では、サービスプレーン非認識サービスノードは、サービスノードと通信するためにサービスプロキシによって使用される非ＮＳＨヘッダのタイプに依存して、メタデータのサブセットのみを受信する。前述したように、いくつかの実施形態のサービスノードは、サービスノードがＮＳＨヘッダを処理できない場合に、ＧＲＥヘッダまたはＱｉｎＱヘッダでサービスメタデータを受信できる。ＧＲＥおよびＱｉｎＱヘッダは、一部の既存のサービスノードがサポートするヘッダであるため、以下では互換モードヘッダと呼ぶ。このような互換モードカプセル化ヘッダは、異なるサービス処理の対象となるデータメッセージフローを区別し、競合するＬ３アドレスを持つフローを分離するために（単一のサービスノードが複数のテナントネットワークのような複数のネットワークのデータメッセージ上でサービスを実行する場合）、いくつかの実施形態で必要とされる。

【0143】

[00182] いくつかの実施形態では、ＧＲＥ互換モードのサービスノードは、２つのＶＮＩＣを介してそのサービスプロキシに接続し、ｂｕｍｐ－ｉｎ－ｔｈｅ－ｗｉｒｅモードで設定される。また、いくつかの実施形態では、ＶＮＩＣはｖｍｘｎｅｔ３デバイスであり、それらのＭＡＣアドレスは変化せず、それらのために使用されるＭＴＵサイズは固定サイズ（例えば、２０４８バイト）に設定される。サービスノードの１つのＶＮＩＣは、送信側トラフィックを受信し、送信元ＤＣＮの入口側トラフィックを供給するための保護されていない側として定義され、もう１つのＶＮＩＣは、入口側トラフィックを受信し、送信元ＤＣＮの出口側トラフィックを供給するための保護されている側として定義される。いくつかの実施形態では、この情報は、ＯＶＦ(Open Virtual Format)パラメータを介してサービスマネージャまたはサービスノードに伝えられ、ここでＯＶＦは、製品およびプラットフォーム間での仮想アプライアンスの交換をサポートするファイルフォーマットである。

【0144】

[00183] ｂｕｍｐ－ｉｎ－ｔｈｅ－ｗｉｒｅモードをサポートするために２つのＶＮＩＣが存在する場合でも、いくつかの実施形態では、互換モードＶＮＩＣのペアごとに１つのサービスプロキシインスタンスのみを使用し、インターフェースのペアを参照するためにサービスプレーンで１つのエンドポイントのみを使用する。図２３および２４は、ＧＲＥヘッダをカプセル化したＧＶＭ２３１５のＳＶＭ２３１０出口側および入口側データメッセージに転送するサービスプロキシ２３０５の例を示す。これを行うために、サービスプロキシはＳＶＭ ２３１０の保護および非保護ＶＮＩＣ用にいくつかの仮想ＧＲＥトンネルエンドポイント２３２０を作成する。

【0145】

[00184] 保護された各仮想トンネルエンドポイントには、対応する保護されていない仮想トンネルエンドポイントがある。各仮想トンネルエンドポイントは、仮想ＩＰアドレス、仮想ＭＡＣアドレス、およびＧＲＥパラメータに関連付けられる。サービスプロキシは、ＧＲＥヘッダを持つデータメッセージをカプセル化して、サービスノードを介してエンドポイントの対応するペア間を移動する。このノードは、ＧＲＥヘッダを変更しないｂｕｍｐ－ｉｎ－ｔｈｅ－ｗｉｒｅモードで動作する。以下でさらに説明するように、サービスプロキシはＧＲＥヘッダにサービスメタデータを埋め込み、サービスノードにデータメッセージを処理するために必要なサービスメタデータを提供する。また、いくつかの実施形態では、異なるトンネル端点の対が異なるフローに対して使用される。

【0146】

[00185] いくつかの実施形態では、サービス挿入プラットフォームは、ＲＦＣ２７８４で定義されているＧＲＥカプセル化を、ＲＦＣ２８９０で定義されている鍵拡張と共にサポートする。いくつかの実施形態では、ＧＲＥトンネルはＩＰｖ４アドレスを使用し、ＧＲＥプロトコルタイプはＲＦＣ１７０１に従ってトランスペアレントイーサネットブリッジングに設定される。ＧＲＥ互換モードでは、サービス挿入レイヤ（例えば、サービスプロキシ）はフローごとにタプル（例えば、送信元ＩＰ、宛先ＩＰ、ＧＲＥ鍵）を生成する。いくつかの実施形態では、このプロセスは決定論的であり、ＳＭＤヘッダの内容に基づいており、ＳＭＤヘッダは、次いで、除去され、ＩＰおよびＧＲＥスタックに置き換えられてもよい。いくつかの実施形態では、このプロセスによって生成されるＩＰアドレスは仮想であり、サービスプロキシとその関連ＳＶＭ以外のいかなるネットワークエンティティにも設定されず、その結果、それらの範囲はサービスプロキシとそのサービスノードとの間のローカルリンクに制限される。

【0147】

[00186] サービスノードがＧＲＥをサポートしていない場合でも、データメッセージとともにメタデータを伝送するために、ＩＰアドレスとＧＲＥ鍵が生成される。いくつかの実施形態では、サービスノードとサービスプロキシの両方が、そのメタデータを消費する。さらに、サービスノードは、いくつかの実施形態において、変更なしに、外部ヘッダをそのまま保持することが期待される。いくつかの実施形態では、各フローは、同一のＧＲＥトンネル内に一貫してカプセル化され、トンネル内にＩＰアドレスの競合がない可能性がある。また、方向（入口と出口）だけが異なるデータメッセージは、スワップされた送信元ＩＰと宛先ＩＰを持つ同じＧＲＥ鍵でカプセル化され、適切な（保護されていない、または保護されていない）方向でＧＲＥトンネルエンドポイントを通過する。

【0148】

[00187] いくつかの実施形態では、送信元／宛先ＩＰアドレス、およびＧＲＥ鍵は、適切なデータメッセージ処理を実行するために、必要に応じてサービスノードによって検査することができる。図２５と２６は、送信元と宛先のＩＰアドレスとＧＲＥ鍵フィールドの代わりに、サービスメタデータがＧＲＥカプセル化ヘッダでどのようにエンコードされるかを示す。図２５は、出口方向（例えば、ＧＶＭからスイッチへ）のサービスデータを記憶するためにいくつかの実施形態で使用されるＧＲＥヘッダフォーマットを示し、一方、図２６は、入口方向（例えば、ソフトウェアスイッチから送信元ＧＶＭへ）のサービスデータを記憶するためにいくつかの実施形態で使用されるＧＲＥヘッダフォーマットを示す。

【0149】

[00188] これらの図では、すべてのフィールドがネットワークバイト順である。パスＩＤは、いくつかの実施形態において、サービスパスと共に生成され、サービス毎のグローバル値を有する。図２５および２６に示すように、ＩＰアドレスフィールドは、いくつかの実施形態において、出口側および入口側データメッセージに対して逆転される。ネイティブモードと同様に、ＧＲＥ互換モードのサービスプレーンは、サービスプロキシに到達したときに有効なカプセル化がある限り、任意のトラフィックを変更または生成できる。いくつかの実施形態では、これは、サービスノードが関連するフローのために受信したＩＰおよびＧＲＥスタックのうちの１つを再利用することを意味する。

【0150】

[00189] いくつかの実施形態では、サービスチェーンに沿ったフロータグ情報は、最初のＧＲＥ互換モードサービスに入るときに破棄され、下流に復元されない。これにより、後続のサービスがフローアクションを宣言できなくなる可能性がある。したがって、フロープログラムは、いくつかの実施形態のＧＲＥ互換モードのサービスノードには提供されない。更に、ライブネス検出は、信頼されたインターフェースと信頼されていないインターフェースとの間でBFD(双方向転送検出）メッセージを通過させることによって、いくつかの実施形態においてサポートされる。いくつかの実施形態では、これらのデータメッセージは、サービスプロキシによって信頼された側と信頼されない側から注入される。サービスノードは、ＧＲＥにカプセル化されていないため、このトラフィックを認識できる。いくつかの実施形態では、サービスノードは、このトラフィック（および実際にはＧＲＥではないカプセル化トラフィック）を仮想ワイヤの反対側にブリッジすることによって変更されずに転送することが期待される。また、いくつかの実施形態では、ＢＦＤの実インスタンスが利用できない場合、データメッセージをハードコーディングすることができる。

【0151】

[00190] いくつかの実施形態におけるスペース制約のために、特定のヘッダフィールドは要約されたバージョンで符号化される。いくつかの実施形態では、サービスチェーンタグ、ＳＰＩおよびＳＩは、単一の４ビットフィールドに要約される。したがって、いくつかの実施形態では、各互換モードのサービスノードは、最大１６のサービスチェーンホップ上に存在することができる。サービスチェーン内にサービスが存在するたびに、１つのサービスパスＩＤ が消費される。サービスが複数のチェーンに存在する場合、複数のサービスパスＩＤが消費される。さらに、サービスチェーンの２ つの方向にサービスが存在するたびに、２ つのサービスパスＩＤ が消費される。

【0152】

[00191] いくつかの実施形態では、関連する外部ヘッダスタック（ＧＲＥまで、およびそれを含む）が使用される限り、ローカルに生成されたトラフィックは、互換モードでサポートされる。いくつかの実施形態では、（１）オプションで外側のイーサネット宛先アドレスをブロードキャストに置き換えること、（２）ＩＰ合計サイズフィールドとＩＰチェックサムを更新すること、（３）ＧＲＥチェックサムは無視されるが、ＧＲＥ鍵が存在しなければならないこと、を除いて外部ヘッダスタックに対する修正は許されない。

【0153】

[00192] 図２７および２８は、少なくとも１つのサービスノード（例えば、あるホストコンピュータから）に関連する１つのＶＴＥＰから別のサービスノード（例えば、別のホストコンピュータ）に関連する別のＶＴＥＰにデータメッセージを送信するために、いくつかの実施形態で使用されるカプセル化ヘッダの例を示す。これらの例はどちらもＧｅｎｅｖｅカプセル化ヘッダで、１つ以上のGeneve TLVでサービスメタデータ（ＳＭＤ メタデータなど）を伝送する。Ｇｅｎｅｖｅ ヘッダは論理Ｌ２オーバーレイトランスポートをサポートし、サービスメタデータを伝送するための可変ＴＬＶ空間を備えている。従って、異なるサービス挿入プラットフォームは、連続ホップ間で運ばれる異なる量のサービスメタデータを指定することができる。

【0154】

[00193] 図２７は、２つのGeneveカプセル化ヘッダ、サービストランスポートレイヤデータを運ぶための外側のＧｅｎｅｖｅヘッダ２７０５、およびサービス挿入レイヤメタデータを運ぶための内側のＧｅｎｅｖｅヘッダ２７１０の使用を示す。図に示すように、サービスメタデータはSMD TLV２７１５に保存される。いくつかの実施形態では、このＴＬＶ ２７１５は、図２１のＮＳＨヘッダフォーマットを有する。したがって、このＴＬＶは、サービスメタデータを上述のように固定長ヘッダ２１１０に格納し、ＳＰＩおよびＳＩ値をヘッダ２１００のＳＰＩおよびＳＩフィールド２１２２および２１２４に格納する。

【0155】

[00194] 効率のために、いくつかの実施形態は、これらの２つのヘッダを図２８の単一のＧｅｎｅｖｅヘッダ２８０５に結合する。これを行うために、これらの実施形態は、データメッセージのオリジナルの送信元および宛先ＭＡＣアドレスを、現在および次のホップのサービスプレーンＭＡＣに置き換え、オリジナルの送信元および宛先ＭＡＣを、サービス方向、送信元ＧＶＭのサービスプレーンＭＡＣ、および他のＳＭＤメタデータ（サービスチェーン識別子、ＳＰＩ値、ＳＩ値、フロープログラミング値、テナントタグ、フロータグなど）と共に、新しいGeneve TLVに格納する。いくつかの実施形態におけるこの新しいGeneve TLVは、２４バイトのＳＭＤメタデータフィールドと、オリジナルの送信元および宛先ＭＡＣアドレスのようなＳＴＬデータを格納するための１２バイトとを有する。いくつかの実施形態において、１２バイトのＳＴＬデータは、２４バイトのＳＭＤメタデータに先行し、これは、いくつかの実施形態において図２１および２２に示されるメタデータを含む。

【0156】

[00195] 図２７と図２８の両方の実装において、Ｇｅｎｅｖｅカプセル化ヘッダは、サービスプレーンのＳＶＮＩを格納し、これは、複数のサービスプレーンを定義することを可能にする。例えば、上述のように、いくつかの実施形態は、異なるＳＶＮＩを使用して、マルチエンティティまたはマルチテナントデータセンタ内の異なるエンティティまたはテナントに対して異なるサービスプレーンを定義する。異なるエンティティまたはテナントの異なるサービスプレーンを、エンティティまたはテナントのデータメッセージタイプの同じまたは異なるＱｏＳ および／またはＳＬＡ保証に関連付けることができる。他の実施形態は、同一のエンティティまたはテナントのための異なるサービスプレーン、例えば、同一のエンティティまたはテナントのための異なるデータメッセージタイプのための異なるＱｏＳおよび／またはＳＬＡ保証に関連する異なるサービスプレーンに対して、複数のＳＶＮＩを使用する。また、両方のヘッダには、送信元および宛先ＶＴＥＰのＭＡＣアドレスと、ＵＤＰおよびＩＰの送信元および宛先アドレスが格納される。

【0157】

[00196] 図２９は、いくつかの実施形態のオブジェクトデータモデル２９００を示す。このモデルでは、実線で表示されるオブジェクトはユーザによって提供され、破線で表示されるオブジェクトはサービスプレーンマネージャとコントローラによって生成される。示されるように、これらのオブジェクトは、サービスマネージャ２９０２、サービス２９０４、サービスプロファイル２９０６、ベンダーテンプレート２９０７、サービスアタッチメント２９０８、サービスインスタンス２９１０、サービス配置２９１３、サービスインスタンスランタイム（ＳＩＲ）２９１２、インスタンスエンドポイント２９１４、インスタンスランタイムポート２９１６、サービスチェーン２９１８、サービス挿入ルール２９２０、サービスパス２９２２、およびサービスパスホップ２９２４を含む。

【0158】

[00197] いくつかの実施形態では、サービスマネージャオブジェクト２９０２は、サービスオブジェクト２９０４の作成の前または後に作成することができる。管理者またはサービス管理システムは、サービスマネージャＡＰＩを呼び出してサービスマネージャを作成できる。サービスマネージャ２９０２は、任意の時点でサービスに関連付けることができる。いくつかの実施形態では、サービスマネージャ２９０２は、ベンダ名、ベンダ識別子、ｒｅｓｔＵｒｌ（コールバック用）および認証／証明書情報などのサービスマネージャ情報を含む。

【0159】

[00198] 上述したように、サービスプレーンは、サービスノードがゼロ認識モードで動作できる（すなわち、サービスプレーンをゼロ認識する）ため、サービスマネージャの存在または使用を必要としない。いくつかの実施形態では、ゼロ認識モードは、基本的な操作（例えば、サービスのＳＶＭに向けてトラフィックをリダイレクトすること）のみを可能にする。このようないくつかの実施形態では、オブジェクト情報（サービスチェーン情報、サービスプロファイルなど）をサービスマネージャサーバに配布するための統合は提供されない。代わりに、これらのサーバーは、ネットワークマネージャーに関心のあるオブジェクトをポーリングすることができる。

【0160】

[00199] サービスオブジェクト２９０４は、サービスノードによって提供されるサービスのタイプを表す。サービスオブジェクトには、サービスメタデータを受信するための機構（ＮＳＨ、ＧＲＥ、ＱｉｎＱなど）を指定するトランスポートタイプ属性がある。また、各サービスオブジェクトには、サービスマネージャから返される状態属性（有効または無効にできる）と、イベントを通信してＡＰＩ コールを実行するためにREST APIエンドポイントを公開するために使用できるサービスマネージャへの参照がある。また、サービスのインスタンスのデプロイに使用されるＯＶＡ／ＯＶＦ属性への参照も含まれる。

【0161】

[00200]ベンダテンプレートオブジェクト２９０７は、１つ以上のサービスプロファイルオブジェクト２９０６を含む。いくつかの実施形態では、サービスマネージャはベンダーテンプレートを登録することができ、サービスプロファイルは、サービスごとに、および潜在的に特殊化されたパラメータをもつベンダーテンプレートに基づいて定義することができる。サービスチェーンは、１つ以上のサービスプロファイルへの参照によって定義できる。いくつかの実施形態では、サービスプロファイルはタグを割り当てられず、回線上で明示的に識別されない。トラフィックに適用する機能を決定するために、サービスノードは、適用可能なサービスプロファイルを識別するためにルックアップを実行する（例えば、上記のように、サービスチェーン識別子、サービスインデックス、およびサービス方向に基づく）。このルックアップのマッピングは、サービスチェーンが変更されて作成されるたびに、管理プレーンによってサービスマネージャに提供される。

【0162】

[00201] いくつかの実施形態におけるサービスプロファイルオブジェクト２９０６は、（１）その関連するベンダーテンプレートを識別するためのベンダーテンプレート属性、（２）テンプレートがサービスプロファイルを通じて構成可能な値を公開するときに１つ以上のカスタム属性、および（３）サービスノードが最終ホップであるときに受信データメッセージを次のサービスホップに転送する間、または元の送信元ＧＶＭに戻すために、受信データメッセージのコピーをサービスノードに転送するか、またはサービスノードに転送するようにサービスプロキシに指示する、順方向アクションまたはコピーアンドリダイレクトなどのアクション属性、を含む。

【0163】

[00202] サービスアタッチメントオブジェクト２９０８は、サービスプレーンを表す（すなわち、マルチテナントデータセンタにおけるテナントのネットワーク管理者、またはプライベートデータセンタにおけるネットワーク管理者など、ユーザの視点のサービスプレーンの表現である）。このサービス接続オブジェクトは、サービスプレーンの任意の数の異なる実装（例えば、論理Ｌ２オーバーレイ、論理Ｌ３オーバーレイ、論理ネットワークオーバーレイなど）をサポートする抽象概念である。いくつかの実施形態では、サービスプレーンを介して通信する（ＳＩＲまたはＧＶＭ上の）各エンドポイントは、サービスアタッチメントを指定する。サービスアタッチメントは通信ドメインである。そのため、サービス添付外のサービスまたはＧＶＭ は、互いに通信できない場合がある。

【0164】

[00203] いくつかの実施形態では、サービスアタッチメントを使用して、それらの間にハードアイソレーションを有する複数のサービスプレーンを作成することができる。サービスアタッチメントは、以下の属性、（１）サービスアタッチメントのためのトラフィックを運ぶ論理ネットワークまたは論理転送要素を識別する論理識別子（例えば、論理スイッチのＳＶＮＩ）、（２）サービスアタッチメントのタイプ（例えば、Ｌ２アタッチメント、Ｌ３アタッチメントなど）、および（３）サービスアタッチメントの範囲を指定するａｐｐｌｉｅｄ＿Ｔｏ識別子（例えば、ノース－サウス動作のためのトランスポートノード０とトランスポートノード１、およびイースト－ウェスト動作のためのクラスタまたはホストのセット）を有する。いくつかの実施形態では、制御プレーン（例えば、中央制御プレーン）は、管理プレーンから受信したサービスアタッチメント表現を、ネットワーク管理者（例えば、プライベートまたはパブリッククラウドのデータセンタ管理者、またはパブリッククラウドのネットワーク仮想化プロバイダ）によって指定されたパラメータに基づいて、特定のＬＦＥまたは論理ネットワーク配置に変換する。

【0165】

[00204] サービスインスタンスオブジェクト２９１０は、サービスの実際にデプロイされたインスタンスを表す。したがって、このような各オブジェクトは、サービスオブジェクト２９０４とサービスインスタンスオブジェクト２９１０との間の関係を指定するサービス配置オブジェクト２９１３を介して、１つのサービスオブジェクト２９０４に関連付けられる。配置されたサービスインスタンスは、スタンドアロンサービスノード（スタンドアロンＳＶＭなど）でも、高可用性（ＨＡ）サービスノードクラスタでもかまわない。いくつかの実施形態では、サービス配置オブジェクト２９１３は、サービスインスタンスタイプ、例えば、スタンドアロンまたはＨＡを記述する。以下に説明するように、サービス配置オブジェクトのＡＰＩをいくつかの実施形態で使用して、サービスのいくつかのサービスインスタンスを配置することができる。

【0166】

[00205] サービスインスタンスランタイム（ＳＩＲ）オブジェクト２９１２は、スタンドアロンモードで動作する実際のランタイムサービスノード、またはＨＡクラスタの実際のランタイムサービスノードを表す。いくつかの実施形態におけるサービスインスタンスオブジェクトは、以下の属性、（１）サービスインスタンスがスタンドアロンモード、アクティブ／スタンバイモード、またはアクティブ／アクティブモデルのいずれで動作しているかを指定する配置モード属性、（２）インスタンスが有効か無効かを指定する状態属性、および（３）ノース-サウス動作の場合にサービス添付識別子への参照を含むｄｅｐｌｏｙｅｄ＿ｔｏ属性を含む。

【0167】

[00206] いくつかの実施形態では、ＳＶＭのプロビジョニングは手動で開始される。この目的のために、管理プレーンは、いくつかの実施形態において、（１）既存のサービスのサービスインスタンスを作成する、（２）サービスインスタンスを削除する、（３）ＳＩＲを追加することによってすでに高可用性クラスタとして構成されているサービスインスタンスを増やす、および（４）そのＳＩＲの１つを削除することによってサービスインスタンスを縮小する、ためのＡＰＩを提供する。既存のサービスのサービスインスタンスを作成するとき、サービスインスタンスは、いくつかの実施形態において、サービスに含まれるテンプレートに基づいて作成されてもよい。呼出元は、スタンドアロンインスタンスまたはＨＡクラスタの間で選択できる。この場合、ＨＡクラスタ内のすべてのＶＭがプロビジョニングされる。ここでも、いくつかの実施形態では、サービスインスタンス配置のためのＡＰＩは、複数のサービスインスタンス（例えば、ＨＡクラスタのため）がただ１つのＡＰＩコールを通して配置されることを可能にする。

【0168】

[00207] いくつかの実施形態では、１つ以上のＳＶＭを作成するＡＰＩは、ＳＶＭが配置されるべき１つ以上の論理的な位置（例えば、クラスタ、ホスト、リソースプール）を指定する。いくつかの実施形態では、管理プレーンは、可能な限り、同じサービスインスタンスに属するＳＶＭを異なるホスト上に配置しようとする。非アフィニティルールは、移行イベント（ＶＭｗａｒｅ、Ｉｎｃ.の動的リソーススケジューラでサポートされるＶＭｏｔｉｏｎイベントなど）間でのＳＶＭの分散を維持するために、適切に構成されることもできる。同様に、管理プレーンは、利用可能な場合は特定のホスト（またはホストのグループ）とのアフィニティルールを設定したり、サービスインスタンスをプロビジョニングするユーザがホストまたはクラスタを明示的に選択したりすることがある。

【0169】

[00208] 上述したように、サービスインスタンスランタイムオブジェクト２９１２は、サービスを実装するためにホスト上で実行される実際のＳＶＭを表す。ＳＩＲはサービスインスタンスの一部である。各ＳＩＲ には、サービスプレーントラフィック専用の１つ以上のトラフィックインターフェイスを含めることができる。いくつかの実施形態では、少なくとも１つのサービスプロキシインスタンスがＳＩＲ毎に実行され、ＳＩＲのためのデータプレーンシグナリングおよびデータメッセージフォーマット変換を必要に応じて処理する。サービスインスタンスが配置されると、いくつかの実施形態では、サービスインスタンスに関連付けられたすべてのＳＶＭに対してＳＩＲが作成される。ネットワークマネージャは、イースト－ウェストサービス挿入におけるすべてのサービスインスタンスのインスタンスエンドポイントも作成する。各ＳＩＲオブジェクト２９１２は、いくつかの実施形態において、以下の属性、（１）理由にかかわらず、トラフィックを処理することができるＳＶＭに対してアクティブであり、他のすべてに対して非アクティブである状態属性、および（２）データプレーンのライブネス検出がＳＩＲがアップまたはダウンしていることを検出するかどうかを指定するランタイム状態、を含む。

【0170】

[00209] インスタンスランタイムインターフェース２９１６は、サービスインスタンスエンドポイント２９１４のエンドポイントごとのバージョンである。いくつかの実施形態では、インスタンスランタイムインターフェース２９１６は、送信元またはシンクサービスプレーントラフィックであり得るＳＩＲまたはＧＶＭのためのインターフェースを識別するために使用される。イースト－ウェストサービス挿入では、いくつかの実施形態におけるインスタンスランタイムインタフェースのライフサイクルは、サービスインスタンス実行時のライフサイクルにリンクされる。いくつかの実施形態では、インスタンスランタイムインターフェースを構成するためにユーザアクションは必要ない。

【0171】

[00210] いくつかの実施形態において、インスタンス実行時インターフェース２９１６は、以下の属性、エンドポイント識別子、タイプ、サービスアタッチメントへの基準、および位置を有する。エンドポイント識別子は、SIR VNICのデータプレーン識別子である。エンドポイント識別子は、ＳＩＲまたはＧＶＭ がサービストランスポートレイヤに登録されるときに生成され、ＭＡＣアドレスまたはＭＡＣアドレスの一部である場合がある。タイプ(ｔｙｐｅ)属性は、共有または専用にすることができる。SIR VNICは専用であり、すなわち、サービスプレーントラフィックに到達できるのはサービスプレーントラフィックのみであるが、GVM VNICは共有される。つまり、サービスプレーントラフィックと通常のトラフィックの両方を送受信する。サービスアタッチメント基準は、サービスプレーントラフィックの送受信に使用されるサービスプレーンを実装するサービスアタッチメントへの基準である。いくつかの実施形態におけるこの基準は、サービスプレーンのＳＶＮＩに関するものである。いくつかの実施形態における位置(ｌｏｃａｔｉｏｎ)属性は、インスタンスランタイムインターフェースの位置を指定する。これは、インスタンスランタイムインターフェースが現在位置しているホストのＵＵＩＤである。

【0172】

[00211] いくつかの実施形態では、ユーザは、サービスプロファイル２９０６の順序付けられたリストに関して、サービスチェーンオブジェクト２９１８を定義する。いくつかの実施形態では、各サービスチェーンは、順方向および逆方向のトラフィック方向に対して、概念的に別々のパスを提供するが、作成時に一方向のみが提供される場合、もう一方は、サービスプロファイル順序を逆にすることによって自動的に生成される。サービスチェーンのどちらの方向（および両方向）も空にすることができる。つまり、どのサービスもその方向のトラフィックを処理しない。いくつかの実施形態では、データプレーンは、空のサービスチェーンに対してもルックアップを実行する。

【0173】

[00212] サービスチェーンは、抽象的な概念である。これらは、特定のサービスノードのセットを指していない。むしろ、サービスプレーンプラットフォームの一部であるネットワークコントローラは、サービスチェーンのサービスノードのシーケンスを指すサービスパスを自動的に生成し、生成されたサービスパスに沿ってメッセージ／フローを指示する。いくつかの実施形態では、サービスチェーンは、サービスチェーンの一意の識別子であるＵＵＩＤによって、管理プレーンまたは制御プレーンで識別される。サービスノードには、サービスマネージャを介して受信した管理プレーンＡＰＩを介して、サービスチェーンＩＤの意味が提供される。この一例は、図１４を参照して上述した。

【0174】

[00213] いくつかの実施形態におけるサービスチェーンタグは、ＵＵＩＤが長すぎてカプセル化ヘッダにおいて運ばれないので、データプレーンにおけるサービスチェーンを識別するために使用されてもよい。いくつかの実施形態におけるサービスチェーンＩＤは、ルールＩＤのような符号なし整数である。サービスにリダイレクトされる各データメッセージは、トラバースしているサービスチェーンのサービスチェーンタグを伝送する。管理プレーンは、サービスチェーンが作成または変更されると、ＵＵＩＤ をサービスチェーンタグマッピングにアドバタイズする。サービスチェーンタグには、サービスチェーンＵＵＩＤとの１対１のマッピングがあるが、１つのサービスチェーンには０から多数のサービスパスインデックスを含めることができる。

【0175】

[00214] サービスチェーンＩＤに加えて、いくつかの実施形態におけるサービスチェーンは、（１）すべての計算されたサービスパスへの基準、（２）障害ポリシー、および（３）サービスプロファイルへの基準、の属性を有する。計算されたサービスパスへの参照は、上述した。障害ポリシーは、サービスチェーンに対して選択されたサービスパスをトラバースできない場合に適用される。いくつかの実施形態では、障害ポリシーは、PASS(フォワードトラフィック）およびFAIL(ドロップトラフィック）であってもよい。サービスチェーンのサービスプロファイルへの参照は、出口トラフィック（例えば、ＧＶＭからスイッチに移動するデータメッセージ）が横断しなければならないサービスプロファイルの出口リストと、入口トラフィック（例えば、スイッチからＧＶＭに移動するデータメッセージ）が横断しなければならないサービスプロファイルの入口リストを含んでもよい。いくつかの実施形態では、入口リストは、デフォルトで、出口リストの逆として初期化される。

【0176】

[00215] サービスチェーンのサービスパスを定義するために、いくつかの実施形態において異なる技法を使用することができる。例えば、いくつかの実施形態では、サービスチェーンは、関連する負荷分散戦略を有することができ、これは、以下の戦略のうちの１つであり得る。ロードバランシング戦略は、サービスチェーンの異なるサービスパス間でトラフィックをロードバランシングする役割を果たす。ＡＮＹ戦略によると、サービスフレームワークは、負荷分散の考慮やフローのピンニングに関係なく、任意のサービスパスにトラフィックを自由にリダイレクトでくる。別の戦略は、ローカルサービスインスタンス（例えば、送信元ＧＶＭと同じホストコンピュータ上で実行されるＳＶＭ）がリモートサービスインスタンス（例えば、他のホストコンピュータや外部サービス装置上で実行されるＳＶＭ）よりも優先されることを規定するＬＯＣＡＬ戦略である。

【0177】

[00216] いくつかの実施形態は、ローカルであるＳＩＲの数に基づいてサービスパスのスコアを生成し、負荷に関係なく最高スコアが選択される。別の戦略は、クラスタ戦略である。クラスタ戦略は、同じホスト上に共存するＶＭによって実装されるサービスインスタンスが優先されることを指定する。そのホストがローカルインスタンスであるか、別のホストであるかは関係ない。ＲＯＵＮＤ＿ＲＯＢＩＮ戦略は、すべてのアクティブなサービスパスが、同じ確率で、または一連の重み値で指定された確率に基づいてヒットするように指示する。

【0178】

[00217] ＳＩルールオブジェクト２９２０は、データメッセージ属性のセットを、サービスチェーンオブジェクト２９１８によって表されるサービスチェーンに関連付ける。サービスチェーンは、１つ以上のサービスパスによって実装され、各サービスパスは、サービスパスオブジェクト２９２２によって定義される。各サービスパスは、１つ以上のサービスホップを有し、各ホップが１つのインスタンスランタイムインターフェース２９１６に関連付けられている１つ以上のサービスパスホップオブジェクト２９２４によって表される。また、各サービスホップは、いくつかの実施形態において、関連するサービスプロファイル、関連するサービスパス、およびネクストホップＳＩＲエンドポイント識別子を参照する。

【0179】

[00218] いくつかの実施形態では、サービスパスオブジェクトは、いくつかの属性を有し、そのいくつかは、基礎となる条件が変化したときに、管理または制御プレーンによって更新されてもよい。これらのプロパティには、サービスパスインデックス、状態（例えば、有効または無効）、サービスパスを手動で無効にしなければならないときに使用される管理モード（例えば、デバッグの理由で）、ホストクロスカウント（サービスパスを通過するデータメッセージがホストを通過する回数を示す）、ローカルカウント（このパスに沿っているＳＩＲの数を示す）、バックアップサービスパスのリスト、サービスパスの長さ、リバースパス（リバースパスの同じＳＩＲのセットを逆順にリストする）、メンテナンスモードインジケータ（いくつかの実施形態では、サービスパスのいずれかのホップがメンテナンスモードにある場合に真を示すビット）が含まれる。

【0180】

[00219] ホストクロスカウントは整数で、サービスパスを通過するデータメッセージをＰＮＩＣから送信する必要がある回数を示す。いくつかの実施形態では、ローカルまたは中央制御プレーンは、複数の利用可能な代替が存在する場合に、この指標を使用して、好ましいパスを決定する。この値は、管理プレーンまたは制御プレーンによって入口され、サービスパスを使用する各ホストで同じである。いくつかの実施形態におけるローカルカウントは、管理プレーンまたは制御プレーンによって初期化されず、サービスパスが作成または更新されるときにローカル制御プレーンによって計算される。各ＬＣＰは、異なる数値を計算する可能性がある。この値は、複数の利用可能な代替が存在する場合に好ましいパスを識別するために、ローカル制御プレーンによって使用される。サービスパスの長さは、サービスプレーンが初期サービスインデックスを設定するために使用する１つのパラメータである。

【0181】

[00220] いくつかの実施形態では、バックアップサービスパスのリストは、同じサービスチェーンに対するすべてのサービスパスのソートされたリストへのポインタである。パスに沿った特定のＳＩＲがダウンしたときに試行される可能性のあるすべての選択肢が一覧表示される。このリストには、サービスパスによってトラバースされる各ＨＡクラスタ内のＳＶＭのすべての可能な順列のサービスパスが含まれている場合がある。いくつかの実施形態では、リストは、異なるＨＡクラスタに属するＳＩＲを含まない。

【0182】

[00221] いくつかの実施形態では、サービスパスは、少なくとも１つのサービスホップが非アクティブであるとき、無効にされる。このような状態は一時的なものであり、サービスライブネス検出障害によってトリガーされる。サービスパスは、この方法でいつでも無効にできる。いくつかの実施形態では、サービスパスは、少なくとも１つのサービスホップが一致するＳＩＲを持たない場合にも無効化される。参照しているＳＩＲ が消えても、オブジェクトモデルにサービスパスがまだ存在する場合、サービスホップはこの状態になる。

【0183】

[00222] サービスプレーンは、各ＳＰＩを一意に識別できる必要がある。いくつかの実施形態では、生成された制御プレーンＵＵＩＤは、サービスパスごとに送信される。サービスプレーンにおけるデータメッセージヘッダの制限のために、いくつかの実施形態では、大きなＩＤは各データメッセージと共に送信されない。いくつかの実施形態では、制御プレーンが各サービスパスに対してＵＵＩＤを生成すると、それに対して小さな固有ＩＤも生成し、このＩＤは、これらの実施形態では各データメッセージと共に送信される。

【0184】

[00223] 図３０は、サービス挿入、ネクストサービスホップ転送、およびサービス処理のためのルールを定義するために、ネットワークマネージャおよびコントローラがいくつかの実施形態において実行するいくつかの動作を概念的に示す。図示されているように、これらの動作は、サービス登録者３００４、サービスチェーン生成器３００６、サービスルール生成器３００８、サービスパス生成器３０１０、サービスプレーンルール生成器３０１２、およびルール分配器３０１４によって実行される。いくつかの実施形態では、これらのオペレータのそれぞれは、ネットワークマネージャまたはコントローラの１つ以上のモジュールによって実現することができ、および／または１つ以上のスタンドアロンサーバによって実現することができる。

【0185】

[00224] サービスパートナーインターフェース３００２（例えば、一組のＡＰＩまたはパートナーユーザーインターフェース（ＵＩ）ポータル）を介して、サービス登録者３００４は、異なるサービスパートナーが実行するサービスを指定するベンダーテンプレート３００５を受信する。これらのテンプレートは、サービスプロファイルを含む１つ以上のサービス記述子でパートナーサービスを定義する。登録者３００４は、サービスチェーンを定義するために使用するサービスチェーン生成器３００６のために、サービスプロファイルをプロファイル記憶３００７に格納する。

【0186】

[00225] 具体的には、ユーザインターフェース３０１８（例えば、一組のＡＰＩまたはＵＩポータル）を介して、サービスチェーン生成器３００６は、ネットワーク管理者（例えば、データセンタ管理者、テナント管理者など）から１つ以上のサービスチェーン定義を受信する。いくつかの実施形態では、各サービスチェーン定義は、サービスチェーンを識別したサービスチェーン識別子を、１つ以上のサービスプロファイルの順序付けられたシーケンスに関連付ける。定義されたサービスチェーン内の各サービスプロファイルは、サービスノードによって実行される必要があるサービス動作に関連付けられる。サービスチェーン生成器３００６は、各サービスチェーンの定義をサービスチェーン記憶装置３０２０に格納する。

【0187】

[00226] ユーザインターフェース３０１８（例えば、一組のＡＰＩまたはＵＩポータル）を通して、サービスルール生成器３００８は、ネットワーク管理者（例えば、データセンタ管理者、テナント管理者等）から１つ以上のサービス挿入ルールを受信する。いくつかの実施形態では、各サービス挿入ルールは、データメッセージフロー属性のセットをサービスチェーン識別子に関連付ける。いくつかの実施形態におけるフロー属性は、Ｌ２属性またはＬ３／Ｌ４属性（例えば、５つのタプル属性）のようなフローヘッダ属性である。これらまたは他の実施形態では、フロー属性はコンテキスト属性（例えば、ＡｐｐＩＤ、プロセスＩＤ、アクティブディレクトリＩＤなど）である。転送およびサービス動作を実行するためのコンテキスト属性を捕捉および使用するための多くの技術は、本明細書に組み込まれる米国特許出願第１５／６５０，２５１号に記載されている。これらの技術のいずれも、本明細書に記載する実施形態と共に使用することができる。

【0188】

[00227] サービスルール生成器３００８は、１つ以上のサービス挿入ルールを生成し、これらのルールをＳＩルール記憶装置３０２２に記憶する。いくつかの実施形態では、各サービス挿入ルールは、ルール識別子およびサービスチェーン識別子を有する。いくつかの実施形態におけるルール識別子は、ＳＩルールが適用可能なデータメッセージフローを識別するフロー識別子（例えば、ヘッダ属性、コンテキスト属性など）に関して定義することができる。一方、各ＳＩルールのサービスチェーン識別子は、ＳＩルールのルール識別子に一致する任意のデータメッセージフローに対してサービスプレーンによって実行される必要があるサービスチェーンを識別する。

【0189】

[00228] サービスルールの一部であるサービスチェーンごとに、サービスパス生成器３０１２は、１つ以上のサービスパスを生成し、各パスは、チェーンのサービスプロファイルのシーケンスによって指定されたサービス動作を実行するために、１つ以上のサービスノードの１つ以上のサービスインスタンスエンドポイントを識別する。いくつかの実施形態では、サービスチェーンのためのサービスパスを生成するプロセスは、（１）サービスパスの候補となるサービスノード（例えば、ＳＶＭ）上のデータメッセージ処理負荷、（２）各候補サービスパスを横断するフローのデータメッセージによって横断されるホストコンピュータの数など、１つ以上の基準を説明する。

【0190】

[00229] これらのサービスパスの生成は、基準によって本明細書に組み込まれる米国特許出願第１６／２８２，８０２号にさらに記載されている。この特許出願に記載されているように、いくつかの実施形態は、ホストクロスカウント（サービスパスを横断するデータメッセージがホストを何回横断するかを示す）、ローカルカウント（このパスに沿ったＳＩＲの何個がローカルホスト上に位置するかを示す）などの１つ以上の指標に基づいて、特定のホスト上の特定のＧＶＭに対して使用するサービスパスを識別する。他の実施形態は、ファイナンシャルおよびライセンス指標などの他の指標に基づいて、サービスパスを識別する（すなわち、サービスパスのためのサービスノードを選択する）。

【0191】

[00230] サービスパス生成器３０１２は、生成されたサービスパスのアイデンティティをサービスパス記憶装置３０２４に記憶する。いくつかの実施形態では、この記憶装置は、各サービスチェーン識別子を１つ以上のサービスパス識別子に関連付け、各サービスパス（すなわち、各ＳＰＩ）に対して、サービスパスを定義するサービスインスタンスエンドポイントのリストを提供する。いくつかの実施形態は、サービスパス定義を１つのデータ記憶装置に記憶する一方で、サービスチェーンとそのサービスパスとの間の関連を別のデータ記憶装置に記憶する。

【0192】

[00231] 次に、サービスルール生成器３０１０は、記憶装置３０２０、３０２２および３０２４に記憶されたルールから、サービス挿入、ネクストホップ転送、およびサービス処理のためのルールを生成し、これらのルールをルール記憶装置３０２６、３０２８および３０３０に記憶し、そこからルール分配機３０１４がこれらのルールを検索し、ＳＩプリプロセッサ、サービスプロキシおよびサービスノードに配布することができる。分配器３０１４はまた、いくつかの実施形態において、サービスパス記憶装置３０２４からのパス定義を分配する。いくつかの実施形態におけるパス定義は、各パスに沿った第１ホップの第１ホップネットワークアドレス（例えば、ＭＡＣアドレス）を含む。いくつかの実施形態では、サービスルール生成器３０１０および／またはルール分配器３０１４は、異なるサービスパスのセットが異なるホストコンピュータにとって最適であるまたは好ましいため、異なるホストコンピュータに、同じサービスチェーンに対する異なるサービスパスのセットを指定して分配する。

【0193】

[00232] いくつかの実施形態では、ルール記憶装置３０２６に記憶されるＳＩ分類ルールは、フロー識別子をサービスチェーン識別子に関連付ける。したがって、いくつかの実施形態では、ルール生成器３０１０は、記憶装置３０２２からこれらのルールを取得し、分類ルール記憶装置３０２６に格納する。いくつかの実施形態では、ルール分配器３０１４は、ＳＩルール記憶装置３０２２から分類ルールを直接取り出す。これらの実施形態について、ＳＩ分類ルール記憶装置３０２６の説明は、ネクストホップ転送ルールおよびサービスノードルールと共に、分散ルールの３つのタイプを強調するためのより概念的な説明である。

【0194】

[00233] いくつかの実施形態では、サービスルール生成器３０１０は、各サービスチェーンの各サービスパスの各ホップのサービスプロキシのネクストホップ転送ルールを生成する。上述したように、いくつかの実施形態における各サービスプロキシの転送テーブルは、プロキシの関連するサービスノードが存在する各サービスパスのネクストホップネットワークアドレスを識別する転送ルールを有する。このような各転送ルールは、現在ＳＰＩ／ＳＩ値をネクストホップネットワークアドレスにマッピングする。サービスルール生成器３０１０は、これらのルールを生成する。ＳＩプリプロセッサがファーストホップネットワークアドレスを検索しなければならない実施形態について、サービスルール生成器は、ＳＩプリプロセッサのファーストホップルックアップルールも生成する。

【0195】

[00234] また、いくつかの実施形態では、サービスルール生成器３０１０は、サービスノードに対して、サービスチェーン識別子、サービスインデックス値およびサービス方向をサービスノードのサービスプロファイルにマップするサービスルールを生成する。これを行うために、サービスルール生成器は、サービスプロファイル記憶装置３００７からのサービスプロファイル定義と同様に、記憶装置３０２０および３０２４からのサービスチェーンおよびサービスパス定義を使用する。いくつかの実施形態では、ルール分配器は、このようなサービスマネージャが存在する場合、サービスノードのサービスマネージャを介してサービスノードルールをサービスノードに転送する。サービスプロファイル定義はまた、いくつかの実施形態では、分配器３０１４によってホストコンピュータ（例えば、ＬＣＰ）に分配され、それにより、これらのホストコンピュータ（例えば、ＬＣＰ）は、これらのサービスプロファイルを使用して、サービスプロキシを構成することができ、例えば、受信したデータメッセージをサービスノードに転送するようにサービスプロキシを構成したり、受信したデータメッセージをコピーしたり、コピーをサービスノードに転送したりし、オリジナルの受信したデータメッセージを次のサービスノードホップに転送したり、最終ホップであるときに送信元のＧＶＭに戻したりするようにサービスプロキシを構成したりすることができる。

【0196】

[00235] いくつかの実施形態では、管理および制御プレーンは、サービスパスのサービスノードのステータスおよびこれらのサービスノード上のデータメッセージ処理負荷に基づいて、サービスチェーンのサービスパスを動的に変更する。図３１は、いくつかの実施形態において、サービスパスがどのように動的に修正されるかを示す。これらの実施形態では、中央制御プレーン３１００は、ホストコンピュータ３１２０上のローカル制御プレーン３１１０と動作して、サービスチェーンのサービスパスを定義し、これらのサービスパスを修正する。いくつかの実施形態におけるＣＣＰ３１００は、管理動作を提供する管理サーバのクラスタを介して、ネットワーク管理者によって指定されたサービスルールに基づいて構成を定義するための制御プレーン動作を提供するサーバのクラスタ（例えば、３つのサーバ）である。

【0197】

[00236] 図に示すように、ＣＣＰは、ホストコンピュータ３１２０上のステータスパブリッシャ３１０３からサービスノードステータスデータを受信するステータスアップデータ３１０２を有する。上述したように、サービスプロキシは、その関連するサービスノードが故障したと判断するたびに（例えば、サービスノードがサービスプロキシのライブネス信号に連続して２回応答することに失敗するたびに）、そのホストをＬＣＰ３１１０に通知する。そして、ＬＣＰは、そのステータスパブリッシャ３１０３が、サービスノードの障害をＣＣＰのステータスアップデータ３１０２に通知する。

【0198】

[00237] ステータスアップデータ３１０２は、サービスノードの障害をサービスパス生成器３０１２に中継する。サービスパス生成器は、いくつかの実施形態では、ＳＰルール生成器３０１０および統計コレクタ３１０４と共にＣＣＰの一部である。サービスノードに障害が発生するたびに、サービスパス生成器は、このサービスノードを使用する以前に定義されたサービスパスをサービスパス記憶装置３０２４から除去する。除去された各サービスパスに対して、サービスパス生成器３０１２は、対応するサービスチェーンのサービスチェーン識別子に対する除去されたパスのＳＰＩ値を削除または非活性化する。

【0199】

[00238] いくつかの実施形態では、除去された各サービスパスは、このサービスパスのためであった転送ルールまたはパス定義を以前に受信したすべてのホストのレコードから除去される（例えば、削除または非活性化される）。いくつかの実施形態では、ＣＣＰ(例えば、サービスパス生成器３０１０またはルール分配器３０１４）は、これらのホストに、それらの転送ルール記憶装置３１２８およびパス定義記憶装置８０８の転送およびパス定義ルールからサービスパスを除去するように指示する。いくつかの実施形態では、故障したサービスノードのＬＣＰは、その転送およびパス定義規則からサービスパスを除去し、一方、他の実施形態では、このＬＣＰは、ＣＣＰからの命令を待つ。

【0200】

[00239] 各ホスト３１２０はまた、いくつかの実施形態において、サービスプロキシがサービスノードのために生成するデータメッセージ負荷統計を発行する統計パブリッシャ３１０５を有する。サービスプロキシがそのサービスノードによって処理されたデータメッセージを受信するたびに、いくつかの実施形態におけるサービスプロキシは、そのサービスノードの統計記憶装置３１０７に記憶する統計（例えば、データメッセージカウント、バイトカウントなど）をインクリメントする。いくつかの実施形態では、統計パブリッシャ３１０５は、周期的またはオンデマンドで、記憶装置３１０７から収集された統計を検索し、これらの統計をＣＣＰの統計コレクタ３１０４に転送する。いくつかの実施形態では、統計コレクタ３１０４は、サービスノードのサービスマネージャがサービスノードから受信する統計を（管理プレーンを通して）受信する。

【0201】

[00240] 統計コレクタ３１０４は、収集された統計をサービスパス生成器３０１２に中継する。上述したように、いくつかの実施形態におけるサービスパス生成器は、サービスノード上のデータメッセージ負荷に部分的に基づいて、サービスノードを介したサービスパスを定義する。例えば、サービスノード上のデータメッセージ負荷が閾値を超えると、サービスパス生成器は、いくつかの実施形態において１つ以上のアクションを実行して、このサービスノード上の負荷を軽減する。例えば、いくつかの実施形態では、それは、それが定義することができる任意の新しいサービスパスへのサービスノードの追加を停止する。これらまたは他の実施形態では、ディストリビュータ３０１４に、このサービスノードを使用するサービスパスをホストの一部またはすべてから除去するように指示する。

【0202】

[00241] 連結的に、または代替的に、サービスパス生成器は、ＣＣＰモジュール（例えば、分配器３０１４）に１つ以上のホストコンピュータのＬＣＰに指示させ、１つ以上のホストコンピュータのＬＣＰは、ＳＩプリプロセッサがそのパス選択をどのように実行するかを制御するため、ＬＣＰが生成するサービスパスを選択するために使用される選択基準８２０を調整する。他の実施形態では、サービスパス生成器または別のＣＣＰモジュールは、各サービスノードの負荷統計を集約し、集約された負荷をそれらの関連するＳＰＩ値と共にホストＬＣＰに分散して、ＬＣＰがこれらの統計を分析し、それらが生成するパス選択基準を調整できるようにする。いくつかの実施形態では、各ＬＣＰは、サービスノード統計に基づいて、および／または各サービスパスによって横断されるホストの数のような他の基準に基づいて、パスを評価および選択するためのパス選択基準を生成するために、パス評価器３１１５を使用するか、または有する。

【0203】

[00242] いくつかの実施形態では、管理プレーン、制御プレーン、サービスマネージャを実装するサーバは、ゲストおよびサービスマシンおよびモジュール（例えば、ＧＶＭ、ＳＶＭ、サービスプロキシ、ポートプロキシ、ＳＴＬモジュール、ＳＦＥなど）が実行されるホストコンピュータと同じデータセンタにある。これらの実施形態では、管理プレーンサーバ、制御プレーンサーバ、サービスマネージャおよびホストコンピュータモジュール（例えば、ＬＣＰ、ＳＶＭ、ＧＶＭ、ハイパーバイザモジュールなど）は、データセンタの共有ネットワークインフラストラクチャ（例えば、スイッチ、ルータ、有線および無線リンクなど）を介して互いに通信する。

【0204】

[00243] 他の実施形態では、管理プレーンサーバ、制御プレーンサーバ、サービスマネージャおよび／またはホストコンピュータは、異なるデータセンタ（例えば、企業プライベートデータセンタおよびパブリッククラウドデータセンタ）で動作する。一部のこのような実施形態では、管理プレーンサーバ、制御プレーンサーバ、サービスマネージャおよび／またはホストコンピュータモジュール（例えば、ＬＣＰ、ＳＶＭ、ＧＶＭ、ハイパーバイザモジュールなど）は、それぞれのデータセンタの外部のネットワークインフラストラクチャを介して互いに通信する。また、いくつかのそのような実施形態は、サービストランスポートレイヤを、複数のデータセンタ（例えば、複数のプライベートデータセンタ、複数のパブリックデータセンタ、複数のプライベート／パブリックデータセンタ）にまたがる分散論理Ｌ３ルーターおよび／またはネットワークとして実装する。

【0205】

[00244] 図３２は、いくつかの実施形態が、マルチテナントデータセンタ内のテナントのためのサービスプレーンおよびその関連サービスノードを定義するために実行する処理３２００を示す。このプロセスは、ただ１つの例示的な一連の動作を提示するだけであり、動作に求められる順序を示すことを意図していない。図に示すように、このプロセスは、サービスプレーンを確立するためのサービスアタッチメントを最初に（３２０５において）指定する。サービス接続構造は、サービスプレーンの実装に依存しない。いくつかの実施形態では、サービスアタッチメントは論理スイッチとして実装されるが、上述のように、サービスアタッチメントは、他の実施形態では異なる方法（例えば、論理ルーター、論理ネットワークなど）で実装される。

【0206】

[00245] サービスプレーンは、いくつかの実施形態において、あるテナントのデータトラフィックに対するサービス処理を、他のテナントのデータトラフィックに対するサービス処理から分離するために使用される。これらまたは他の実施形態では、異なるサービスプレーンが、異なるタイプのトラフィックに対して異なるＱｏＳまたはＳＬＡ保証を提供するために使用される。例えば、いくつかの実施形態は、異なるサービスプレーンを使用して、異なるテナントの異なるデータ計算エンドポイント間のトラフィックに対して異なるＱｏＳまたはＳＬＡ保証を提供するか、または同じテナントまたは異なるテナントの異なるデータメッセージフローによって運ばれる異なるタイプのコンテンツに対して異なるＱｏＳまたはＳＬＡ保証を提供する。

【0207】

[00246] サービスアタッチメントを作成した後、プロセスは、サービスプレーンによって提供されるサービスのサービスインスタンスを（３２１０で）作成する。配置されたサービスインスタンスごとに、プロセスは、サービスインスタンスを高可用性クラスタによって提供するか、スタンドアロンサービスノードによって提供するかを指定する。また、サービスインスタンスに関連付けられたサービスアタッチメントを識別するサービスアタッチメント識別子も提供する。また、配置仕様書とインスタンスの配置構成も提供する。

【0208】

[00247] 次に、３２１５で、プロセスは、３２１０で作成されたサービスインスタンスごとに各サービスインスタンスランタイムを配置する。サービスインスタンスランタイムごとに、サービスアタッチメントにインスタンスエンドポイントを作成する必要がある。サービス接続が論理スイッチの場合、作成されるインスタンスエンドポイントは論理スイッチの論理ポートである。いくつかの実施形態では、論理スイッチポートは、ＳＶＭ(サービスインスタンスランタイムとして機能する）が論理スイッチにアタッチされると自動作成される。いくつかの実施形態では、サービスインスタンスエンドポイントは、サービスインスタンスが配置されるたびに管理プレーンによって作成される。また、いくつかの実施形態では、サービスのサービスインスタンスおよびサービスインスタンスランタイムは、１つのサービス配置オブジェクトＡＰＩを呼び出すことによって配置されることができる。前述のように、この単一のＡＰＩを使用すると、複数のサービスインスタンスとサービスインスタンスランタイムをデプロイするために１つのＡＰＩを複数回繰り返し呼び出す必要性が大幅に軽減される。

【0209】

[00248] ３２２０で、プロセスは１つ以上のサービスチェーンを作成する。各サービスチェーンは、サービスプロファイルの順序付きリストとして作成される。各サービスチェーンには、順処理方向と逆処理方向がある。サービスチェーンごとに、前述のように障害ポリシーが定義される。また、上述したように、いくつかの実施形態における負荷分散基準は、各サービスチェーンに対して、任意、ローカル、サービスクラスタまたはラウンドロビンのタイプの１つとして定義される。最後に、３２２５で、サービスルールのセクションがテナントに対して定義され、１つ以上のサービスルールがこれらのセクションで定義される。各サービスルールは、指定されたフロー属性セットに一致するデータメッセージに対して実行する必要があるサービスチェーンを指定するために、一連のデータメッセージフロー属性をサービスチェーン識別子と相関させる。

【0210】

[00249] いくつかの実施形態は、１つ以上のデータセンタで動作するホスト間で、サービスプレーンに関連するマシンを移行するための新しい方法を提供する。例えば、いくつかの実施形態は、（１）送信元ホストのマシンに関するサービスプレーンデータを収集する、（２）データを宛先ホストに送信する、（３）宛先ホストにマシンを配置する、および（４）送信元ホストからマシンを削除する、ことによって、サービスプレーンに関連付けられたサービスマシン（例えば、ＳＶＭ）またはゲストマシン（例えば、ＧＶＭ）のいずれかを移行（migrate）する。

【0211】

[00250] マシンに新しいサービスプレーンネットワークアドレスを新しい位置に割り当てる代わりに、マシンは送信元ホストと同じ宛先ホストの同じサービスプレーンネットワークアドレスでアドレス指定できる。例えば、いくつかの実施形態では、サービスプレーンＭＡＣ(ＳＰＭＡＣ)アドレスによってアドレス指定可能なゲストマシンは、異なるホストへの移行後に同じＳＰＭＡＣによってアドレス指定可能である。同様に、いくつかの実施形態において、特定のネクストホップＭＡＣアドレスに関連するサービスマシンが移行されるとき、サービスマシンは、移行の前後の両方で、同じネクストホップＭＡＣアドレスによってアドレス指定可能である。このようないくつかの実施形態では、移行されたサービスマシンを参照するネクストホップ転送ルールは、マシン移行後のサービスマシン位置の変化に基づいて更新される必要はない。したがって、ネクストホップ転送は移行に依存しない。

【0212】

[00251] 代わりに、いくつかの実施形態では、サービスプレーンそれ自体が、移行されたマシンの位置を追跡する責任を負う。いくつかの実施形態では、サービスプレーン（例えば、サービスプレーンを構成する一組のコントローラ）は、サービスプレーンＭＡＣアドレスのＶＴＥＰへのマッピングを維持および更新して、マシン位置を追跡し、ＭＡＣアドレス宛てのメッセージが、マシンへの配信のために正しいトンネルエンドポイントに転送されることを保証する。

【0213】

[00252] いくつかの実施形態では、移行されたマシンは、そのマシンと共に移行されなければならないローカルに維持されたデータと関連づけられる。例えば、いくつかの実施形態におけるゲストマシンのＩＯチェーンのプリプロセッサは、フローを識別し、ゲストマシンのホストで維持される動的状態（例えば、コネクション追跡）に基づいてサービスプレーン転送のためのサービスメタデータ（ＳＭＤ）を提供する。また、いくつかの実施形態では、ホストは、ゲストマシンに適用可能なＳＩルールや、ＳＩルールで識別されるサービスチェーンのサービスパスなど、ゲストマシンに固有の静的データを格納する。いくつかの実施形態では、この情報の一部または全部は、サービス挿入プラットフォームの他の位置で維持されない。

【0214】

[00253] ゲストマシン移行の動作のより詳細な例を、図３３～図３５を参照して説明する。図３３は、移行されるＧＶＭの送信元ホスト（source host）によって実行される処理３３００と、移行されたＧＶＭの宛先ホスト（destination host）によって実行される処理３３０５を示す。このプロセスは、図３４Ａ～３４Ｃに示されるＧＶＭ移行の例を参照することによって、以下に記述される。図３４Ａ～３４Ｃは、ＧＶＭ ＶＮＩＣごとに１つのＩＯチェーンのみを示すが、ＧＶＭ ＶＮＩＣは、一般に、２つのＩＯチェーンを有し、１つは、スイッチからＶＮＩＣへの入口用であり、もう１つは、ＶＮＩＣからスイッチへの出口用であることに留意されたい。いくつかの実施形態では、出口ＩＯチェーンは、入口ＩＯチェーンと同じモジュールを含むが、ＶＮＩＣとスイッチとの間に逆の順序で配置される。図３４Ａは、ＧＶＭ３４０２を移行する前の送信元ホスト１１２および宛先ホスト１１４を示す。処理３３００は、送信元ホスト１１２が、ＧＶＭ３４０２を宛先ホスト１１４に移行する必要があると判断したときに開始される。

【0215】

[00254] 図に示すように、プロセス３３００は、最初に（３３１０において）、ＧＶＭ３４０２の移行に関するＧＶＭデータを収集し、保存する。いくつかの実施形態では、ＧＶＭデータは、宛先ホスト１１４上にＧＶＭ３４０２のインスタンスを配置またはインスタンス化するためのＧＶＭ配置データを含む。また、いくつかの実施形態では、ＧＶＭデータは、サービス挿入モジュールによって、サービスメタデータをＧＶＭに関連するデータメッセージに割り当てるために使用される動的状態データおよび静的ルールデータを含む。ホスト１１２は、収集されたＧＶＭデータ３４９０を（３３２０において）送信する。ＧＶＭデータは、ＧＶＭ３４０２を配置するためのＧＶＭ配置データのセットを含む。この例では、ＧＶＭデータ３４９０はまた、コネクション追跡記憶装置８０４から収集されたコネクション追跡データ（サービスメタデータ（ＳＭＤ）のフロー識別子へのマッピングのような動的状態データを含む）、ＳＩルール記憶装置８０６からＧＶＭ３０４２に関連するサービス挿入ルール、およびパステーブル８０８からのＳＩルールによって識別されるサービスチェーンのためのＧＶＭ３４０２に関連するサービスパスを含む。いくつかの実施形態では、ＧＶＭデータは、仮想マシンモビリティ管理サービス、例えばＶＭｗａｒｅ Ｉｎｃ．のエンタープライズモビリティ管理を介して送られる。また、いくつかの実施形態では、ＴＬＶヘッダは、ＧＶＭデータを送信するときに、ＧＶＭ配置データ、接続データ、ＳＩルール、およびサービスパスのそれぞれに対して定義される。

【0216】

[00255] いくつかの実施形態では、サービスパス選択指標とネクストホップアドレスの両方がパステーブルから収集され、ＧＶＭデータと共に送信される。他の実施形態では、サービスパスの第１ホップＭＡＣアドレスは、別個の転送テーブル（例えば、図８の転送テーブル８１０）に格納され、そこから収集される。いくつかの実施形態では、サービスパスおよびサービスパス選択指標は、ＧＶＭデータと共に収集されず、送信されない。そのようないくつかの実施形態は、代わりに、ＣＣＰから分配されたすべてのサービスパスを各ホストに格納するか、またはＣＣＰによって特定のホストに分配された各特定のホストサービスパスにのみ格納する。

【0217】

[00256] ＧＶＭデータが送信元ホスト１１２から送信された後、処理３３０５は、宛先ホスト１１４におけるＧＶＭデータを開始し、（３３２５において）受信する。いくつかの実施形態では、ＧＶＭデータは、マシン移行の宛先ホストに警告する。このプロセスでは、ＧＶＭデータを使用して、宛先ホスト１１４でＧＶＭ３４０２を（３３３５で）移行する。図３４Ｂは、ＧＶＭ３４０２がホスト１１４上に配置された後の送信元ホスト１１２および宛先ホスト１１４を示す。３３３５において、プロセスはまた、新たに配置されたＧＶＭ３４０２のために、ポート３４５２および入口および出口ＩＯチェーンを配置する。ＧＶＭ３４０２は、ＩＯチェーンに接続し、これらを介して、ホスト１１４上のスイッチ１２２のポート３４５２に接続する。この例では、配置された入口ＩＯチェーンは、ＳＩプリプロセッサ３４１１、ＳＴＬ呼出元３４２５、およびＳＩポストプロセッサ３４１３を含む。いくつかの実施形態では、ポートプロキシ３４２０は、ＧＶＭ３４０２の新しい位置へのマッピングを格納する。いくつかの実施形態では、ポートプロキシ３４２０は、ＧＶＭ ＳＰＭＡＣアドレスをＳＴＬ呼出元３４２５にマッピングする。また、いくつかの実施形態では、ＧＶＭ３４０２は、送信元ホスト１１２と宛先ホスト１１４の両方で同じＳＰＭＡＣを有する。

【0218】

[00257] ＧＶＭ３４０２およびそのＩＯチェーンが配置されると、処理３３０５は、受信したＧＶＭデータ３４９０からＧＶＭ３４０２の動的状態および静的ルールデータの復元を開始する。いくつかの実施形態において、ＳＩプリプロセッサ３４１１は、ＧＶＭ３４０２の状態およびルールデータの少なくとも一部が宛先ホスト１１４上に復元され、ＳＩプリプロセッサにアクセス可能になるまで、移行されたＧＶＭ３４０２のためのフローを処理することができない。３３４５において、プロセスは、ＧＶＭ３４０２のためのコネクションデータを復元し、受信したコネクションデータをコネクション追跡記憶装置３４０４に記憶する。いくつかの実施形態において、ＳＩプリプロセッサ３４１１は、接続追跡記憶装置がサービスプレーン転送に十分なサービスメタデータ（例えば、ＳＰＩ、ＳＩ、Ｄｉｒｅｃｔｉｏｎ、第１のネクストホップアドレスなど）を含む既存のデータフローの処理をすぐに開始してもよい。この場合、プリプロセッサ３４１１は、サービス挿入ルールおよびＧＶＭ３４０２のパスが復元される前に、フロー処理を再開することができる。いくつかの実施形態では、新しいデータフローは、サービス挿入ルールおよびサービスパスデータが復元されるまで保持される（例えば、ＳＩプリプロセッサで）。他の実施形態では、サービス挿入ルールに一致しない新しいフローは、それらの宛先に転送される。

【0219】

[00258] ３３５５において、処理３３０５は、受信したＧＶＭデータ３４９０に基づいて、ＧＶＭ３４０２のＳＩルールを復元する。ＳＩルールは、ＳＩルール記憶装置３４０６に記憶される。この例では、ＳＩルール記憶装置は、ＧＶＭ３４０２とＧＶＭ３４０２のＳＩルールを異なるセクションに記憶する。他の実施形態では、各ＧＶＭは、独自のルール記憶装置を有する。全てのＧＶＭに対するルールは、いくつかの実施形態において、単一記憶装置の単一セクションに格納される。ＧＶＭ３４０２のＳＩルールの復元に続いて、プロセスは、パステーブル３４０８内の受信されたパスおよびパスデータ（例えば、選択基準、ファーストホップＭＡＣアドレスなど）を（３３６５において）復元する。この例では、ＧＶＭ１０４およびＧＶＭ３４０２は、パステーブル３４０８を共有するが、同じホスト上のゲストマシンは、いくつかの実施形態において、単一のセクションを共有するか、または独自の記憶装置を有することも可能である。いくつかの実施形態では、プリプロセッサ３４１１は、パステーブルが復元されると、新しいフローの処理を開始する。しかしながら、他の実施形態では、プリプロセッサは、パステーブルが制御プレーンによって更新されるまで、新しいフローの処理を開始しない。このような場合には、プリプロセッサは新しいデータフローに属するデータメッセージを保持し続ける。いったんパステーブルが復元されると、処理３３０５は、（３３６５において）制御位置（例えば、ＣＣＰ）に、ＧＶＭの配置およびデータ復元が完了し、終了することを通知する。

【0220】

[00259] ホスト１１２が、ＧＶＭ ３４０２がホスト１１４上に配置され、ＧＶＭ３４０２の状態およびルールが復元されたという確認通知を受信すると、処理３３００は、３３３０において、ホスト１１２からのＧＶＭ３４０２の破棄を開始する。いくつかの実施形態では、送信元ホスト１１２はＣＣＰから確認応答を受信するが、他の実施形態では、確認応答は宛先ホスト１１４それ自体から受信される。いくつかの実施形態では、ＧＶＭ３４０２は、まずホスト１１４でそのＩＯチェーンから切断され、次に除去される。

【0221】

[00260] ３３３０において、ホスト１１２はまた、ＳＩプリプロセッサ３４１０、ＳＴＬ呼出元３４２４、およびＳＩポストプロセッサ３４１２を含む、ＧＶＭ３４０２がｖｓｗｉｔｃｈ１２０に接続するＧＶＭ ＩＯチェーンおよびポート３４５０を破棄する。いくつかの実施形態では、ＩＯチェーンは、ホスト１１２から取り外される前に、ポート３４５０から切断される。いくつかの実施形態では、処理３３００は、ホスト１１２から、移行されたＧＶＭ３４０２の固有のデータを除去する。この場合、ホスト１１２は、接続追跡保管８０４、Ｓ．Ｉ．ルール記憶装置８０６、およびパステーブル８０８からＧＶＭ３４０２データを除去する。ポートプロキシ６２０は、ＧＶＭ３４０２のＳＰＭＡＣへのマッピングも除去する。ＧＶＭ３４０２、ＧＶＭ３４０２ＩＯチェーン、およびその関連データがホスト１１２から除去されると、処理３３００は、ＧＶＭ３４０２が送信元ホスト１１２から切断されて終了したことを制御プレーン（例えばＣＣＰ）に（３３４０において）通知する。図３４Ｃは、ＧＶＭ３４０２の移行が完了した後のホスト１１２およびホスト１１４を示す。

【0222】

[00261] いくつかの実施形態では、制御プレーンは、マシンの移行を検出し、それに応じてサービスプレーンを更新する責任を負う。ＧＶＭ移行後に実行される制御プレーン動作は、いくつかの実施形態において制御プレーンによって実行される処理３５００を示す図３５を参照してさらに説明される。このプロセスは、図３４Ａ～３４Ｃを参照して、以下に説明される。

【0223】

[00262] 図に示すように、処理３５００は、ＧＶＭ３４０２が送信元ホスト１１２から宛先ホスト１１４に移行したことを制御ペインが（３５１０において）判定すると、開始される。いくつかの実施形態では、制御プレーンは、ＣＣＰで受信された１つ以上の通知に基づいて、ゲストマシンがホストを移行したと決定する。いくつかの実施形態では、制御プレーンは、宛先ホストからのゲストマシンが配置されたことの第１の通知と、送信元ホストからのゲストマシンが切断されたことの第２の通知とを受信する。いくつかの実施形態では、第１の通知は宛先ホストのＬＣＰによって送信され、第２の通知は送信元ホストのＬＣＰによって送信される。

【0224】

[00263] 制御プレーンが、ＧＶＭ３４０２が移行されたことを決定すると、プロセスは（３５２０において）、移行されたＧＶＭの新しい位置を公開する。いくつかの実施形態では、制御プレーンは、ＧＶＭに到達可能なＶＴＥＰへのＧＶＭ ＳＰＭＡＣ(これは、以前と同じである）のマッピングを公開する。いくつかの実施形態では、ＶＴＥＰは、データフローがサービスパスを完了した後、データフローをその送信元ＧＶＭ ＩＯチェーンに戻すために使用される。いくつかの実施形態では、ＶＴＥＰは、サービスプレーン（例えば、ポートプロキシ３４２０）との間でＧＶＭに関連するデータフローを挿入する、新しいホスト上のポートプロキシのためのＶＴＥＰである。

【0225】

[00264] いくつかの実施形態では、ＶＴＥＰからＳＰＭＡＣへのマッピングは、サービスプレーンによって維持されるグローバル転送テーブルに公開され、そこでは、ＳＰＭＡＣから送信元ホストのＶＴＥＰへのマッピングを置き換える。いくつかの実施形態では、マッピングは、サービスプレーンの各転送要素のホストにおいて、ＣＣＰからＬＣＰに公開される。

【0226】

[00265] いくつかの実施形態では、移行されたＧＶＭの新しい位置は、ＧＶＭ ＩＯチェーンからサービスプレーンに挿入されたデータフローに基づく送信元学習によって、サービスプレーンによっても学習される。このようないくつかの実施形態では、挿入されたトラフィックには、トラフィックがＧＶＭから転送される送信元ＶＴＥＰを識別するＶＴＥＰ送信元ラベルが付加される。ＶＴＥＰ送信元ラベルは、サービスプレーンを通過する各ホップに沿って伝送される。いくつかの実施形態では、ＶＴＥＰ送信元ラベルは、データフローのデータメッセージのサービスメタデータに追加される。いくつかのこのような実施形態では、データメッセージは、ＳＰＭＡＣおよびＶＴＥＰラベルの各ホップで検査される。送信元ラベルのＳＰＭＡＣとＶＴＥＰは、データメッセージのサービスメタデータから取得され、ＳＰＭＡＣとＶＴＥＰのマッピングが学習される。いくつかの実施形態では、マッピングは、サービスパスのエンドにあるデータメッセージを、データメッセージがサービスプレーンに挿入された送信元ＧＶＭ ＩＯチェーンに戻すために使用することができる。

【0227】

[00266] 必要に応じて、制御プレーンは、移行されたＧＶＭの宛先ホスト１１４の新しいサービスパスを（３５３０において）生成する。いくつかの実施形態では、サービスパスは、サービスパスが選択されるホストに相対的な（例えば、サービスパスが実行されるためにデータメッセージがサービスプレーンに挿入される）サービスパスのＳＶＭの位置に少なくとも部分的に基づいて、サービスチェーンに対して選択される。そのため、ＧＶＭ移行の送信元ホスト１１２に対して生成されたサービスパスは、宛先ホスト１１４にとって最適ではない可能性がある。いくつかの実施形態では、新しいサービスパスは、サービスパスのＳＶＭに相対的な宛先ホストの位置に基づいて選択された最適なサービスパスである。新しいサービスパスは、ＧＶＭの宛先ホストに配信され、パステーブルに保存される。いくつかの実施形態では、新しいサービスパスがＣＣＰで生成され、宛先ホストのＬＣＰを介して宛先ホストに分配される。いくつかの実施形態は、各サービスチェーンに対して単一のサービスパスのみを各ホストに配信する。他の実施形態は、ホスト毎にサービスチェーン毎に複数のサービスパスを分配する。いくつかのそのような実施形態では、各ホストのＬＣＰは、選択基準に基づいて、複数の受信されたサービスパスから記憶するために、サービスチェーンごとに１つのサービスパスを選択する。他のこのような実施形態では、受信されたサービスパスはそれぞれ記憶され、ＬＣＰは受信されたサービスパスのための選択指標を生成する。サービスパスは、例えば、重み付きラウンドロビン選択に基づいて、いくつかのそのような実施形態におけるサービスパス選択指標を使用するフローベースによるサービスチェーンに対して選択される。

【0228】

[00267] いくつかの実施形態では、サービスパス選択は、サービスパスのＧＶＭホスト相対ＳＶＭの位置に依存しない。たとえば、サービスパスの選択は、ＳＶＭの相対的な位置に依存する場合があるが、ＧＶＭのホストとの相対的な関係には依存しない場合がある。このような場合、ＧＶＭの移行はサービスパスの選択に影響しない。このような場合、新しいサービスパスの生成は、ＧＶＭの移行後は不要であり、スキップすることができる。いくつかの実施形態では、サービスルールおよび／またはサービスパスは、マシンの移行中には移行されず、ＧＶＭのための古いサービスルールおよび／またはサービスパスは、代わりにＣＣＰによって宛先ホスト（例えば、ホスト１１４）に分配される。

【0229】

[00268] ３５４０において、必要であれば、制御プレーンは、宛先ホスト１１４におけるパステーブル３４０８のサービスパスのための新しいサービスパス選択指標を計算する。いくつかの実施形態では、サービスパス選択指標は、中央制御プレーンから受信された新しいサービスパスに対して常に計算される。また、いくつかの実施形態では、サービスパスは、サービスパス選択指標なしに移行され、サービスパス選択指標は、受信されたサービスパスについて計算される。サービスパス選択指標が、少なくとも部分的に、ＧＶＭホストに相対的なサービスパスＳＶＭの位置に基づいている場合、移行されたサービスパス選択指標は、もはや正確ではなく、新しいサービスパス選択指標が、移行されたサービスパス選択指標に代わるいくつかの実施形態において計算される。いくつかの実施形態では、移行されたＧＶＭがホスト上の最初のＧＶＭであるとき、ホストは移行前に記憶されたサービスパスを持たない。このようないくつかの実施形態では、移行後に宛先ホストに記憶されたすべてのサービスパスは、送信元ホストから移行されたサービスパスである。他の実施形態では、サービスパスは、ＧＶＭと共にまったく移行されない。

【0230】

[00269] いくつかの実施形態では、サービスパス選択指標は、ＧＶＭ自体の位置に依存せず、むしろ選択指標を生成するホストの位置に依存する。このような場合、宛先ホストのパステーブルにすでに保存されているサービスパスについて、サービスパス選択指標を計算する必要がないことがある。このような実施形態では、サービスパス選択指標は、サービスプレーンにおける他の変更に起因して、依然として計算されてもよい。他の実施形態では、サービスパス選択指標がＧＶＭホストの位置に依存しない場合、すでに選択指標を有する任意のサービスパスに対するサービスパス選択指標を計算することは不要であり、スキップすることができる。必要なサービスパス選択指標が計算されると、処理３５００は終了する。

【0231】

[00270] いくつかの実施形態はまた、１つ以上のデータセンタで動作するホスト間でサービスマシン（例えば、ＳＶＭ）を移行するための新しい方法を提供する。たとえば、１台以上のサービスマシンをホストする第１のホストコンピュータをメンテナンスのために停止する必要がある場合、第１のホストコンピュータで動作しているサービスマシンを第２のホストコンピュータに移行できる。場合によっては、サービスマシンをホストマシン間で移行して、ワークロードのバランスを取ったり、権限やファイアウォールの実装を簡素化したり、改善されたサービスパスを提供したりすることがある。

【0232】

[00271] このようないくつかの実施形態では、ＳＶＭは、ホストコンピュータの共有メモリ（例えば、VMware ESXホストの共有メモリ）内で実行される。一部のこのような実施形態では、ファイルに対してサービス動作を実行するために、ＳＶＭは、サービス動作を実行する前に、共有メモリ内のファイルの保存場所を探し、カーネル空間内のファイルを開く。このようないくつかの実施形態では、ＳＶＭは、同じＥＳＸに格納されたファイルに対してのみサービス動作を実行することができる。このようないくつかの実施形態では、ホスト間でＳＶＭを移行するには、ＶＭに関連付けられたフィルタモジュール（例えば、ｄｖＦｉｌｔｅｒ）の移行が必要である。他のこのような実施形態では、ＳＶＭは、代わりに、共有メモリ内で動作しないＭＡＣアドレス指定可能エンティティである。ＭＡＣアドレス指定可能なサービスマシン移行の動作のより詳細な例を、図３６～３９を参照して説明する。

【0233】

[00272] 図３６は、移行元のＳＶＭ３７０６の移行元ホスト１１２で実行される処理３６００と、移行先のＳＶＭの宛先ホスト１１４で実行される処理３６０５を示す。このプロセスは、図３７Ａ－３７Ｃに示されているＳＶＭ移行の例を参照して、以下で説明されている。図３７Ａは、ＳＶＭ３７０６の移行前のホスト１１２とホスト１１４を示す。処理３６００は、送信元ホスト１１２が、ＳＶＭ３７０６を宛先ホスト１１４に移行する必要があると判断したときに開始される。

【0234】

[00273] 図に示すように、プロセス３６００は、最初に、ＳＶＭ３７０６に関するＳＶＭデータを（３６１０において）保存する。いくつかの実施形態では、ＳＶＭデータは、ホスト１１４上にＳＶＭ３７０６を配置するためのデータを含む。いくつかの実施形態では、ＳＶＭデータは、データメッセージフロー上でサービスを識別し実行するためにＳＶＭ３７０６によって使用される動的状態ＳＶＭデータおよび静的ルールＳＶＭデータも含む。

【0235】

[00274] いくつかの実施形態では、ＳＶＭルールデータは、データメッセージフロー上でサービスを実行するためのサービスルールセットへのサービスメタデータ（例えば、ＳＣＩ、ＳＩ、および宛先）のマッピングを含む。また、いくつかの実施形態では、ＳＶＭ状態データは、データメッセージフロー上で実行するためのサービス動作へのフロー識別子のマッピングを含む。いくつかの実施形態では、状態データは、サービスルールセット内のデータフロー識別子に対するルックアップに基づくデータフロー識別子への決定のマッピングを含む。また、ＳＶＭデータは、いくつかの実施形態では、ＳＶＭ ＩＯチェーンのためのＳＩプロキシ（例えば、ＳＩプロキシ３７１５）およびＳＩプロキシによって使用される任意の状態データを構成するためのデータを含む。いくつかの実施形態では、ＳＩプロキシデータは、移行されたＳＶＭが属するサービスパスのネクストホップ転送ルールのセットを含む。また、いくつかの実施形態では、ＳＩプロキシ状態データは、ＳＩプロキシで維持される指標および統計、例えば、トラフィック量レコードを含む。

【0236】

[00275] 送信元ホスト１１１２は、保存されたＳＶＭデータ３７９０を宛先ホスト１１４に（３６２０で）送信する。いくつかの実施形態では、ＳＶＭデータ３７９０は、仮想マシンモビリティ管理サービス、例えばＶＭｗａｒｅ Ｉｎｃ．のエンタープライズモビリティ管理を介して送られる。いくつかの実施形態では、任意のＳＶＭルールデータ、ＳＶＭ状態データ、およびＳＩプロキシデータを含むすべてのＳＶＭデータは、移行されたＳＶＭ３７０６と共に移動される。他の実施形態では、ＳＶＭルールデータ、ＳＶＭ状態データ、およびＳＩプロキシデータの一部またはすべてが、仮想マシン移行フレームワークを介して個別に移行される。

【0237】

[00276] ＳＶＭデータ３７９０が送信元ホスト１１２から送信された後、処理３６０５は、宛先ホスト１１４のＳＶＭデータを開始し、（３６２５で）受信する。いくつかの実施形態では、ＳＶＭデータは、マシン移行の宛先ホストに警告する。このプロセスでは、ＳＶＭデータ３７９０を使用して、宛先ホスト１１４にＳＶＭ３７０６を（３６３５に）配置する。図３７Ｂは、ホスト２にＳＶＭ３７０６が配置された後のホスト１１２とホスト１１４を示す。いくつかの実施形態では、移行されたＳＶＭ３７０６は、移行されたＳＶＭデータ３７９０を使用して、移行されたＳＶＭ状態およびＳＶＭルールの一部または全部と共に配置される。他の実施形態では、ＳＶＭ状態およびルールデータの一部または全部は、例えば、別々に移行されたＳＶＭデータ（例えば、ＳＩプロキシ状態）を復元する、導入後に復元される。

【0238】

[00277] ３６３５において、処理３６０５はまた、ポート３７５５および入口及び出口ＩＯチェーンを配置する。このプロセスでは、ＳＶＭ３７０６をＩＯチェーンに接続し、それらを介して宛先ホスト１１４のスイッチ１２２のポート３７５５に接続する。この例では、配置されたＩＯチェーンは、ＳＩプロキシ３７１５およびＳＴＬモジュール３７２７を含む。いくつかの実施形態では、移行されたネクストホップ転送ルールは、ＳＩプロキシ３７１５の配置中に消費され、ＳＩプロキシは、すでに構成されたネクストホップ転送ルールと共に配置される。他の実施形態では、ネクストホップ転送ルールはグローバルに記憶され、サービスプレーンによってＳＩプロキシ３７１５に提供される。さらに別の実施形態では、ネクストホップ転送ルールは、配置後にＣＣＰによって提供される。いくつかの実施形態では、ＩＯチェーンの配置中に、移行されたＳＶＭ３７０６のネクストホップアドレスがサービスプレーンによって保存される。また、いくつかの実施形態では、移行されたＳＶＭは、送信元ホストと同じ宛先ホストの同じネクストホップアドレスによってアドレス指定可能である。この例では、サービスプレーンは、ホスト１１２のＳＶＭ３７０６に割り当てられたのと同じホスト１１４のネクストホップＭＡＣアドレスである宛先ホスト１１４のポート３７５５を介して、ＳＶＭ３７０６に到達できるＶＴＥＰへのＳＶＭ３７０６のマッピングを格納する。

【0239】

[00278] いくつかの実施形態では、ＳＶＭ３７０６およびそのＩＯチェーンが一旦配置されると、プロセス３６０５は、受信されたＳＶＭデータ３７９０からＳＶＭ３７０６の動的状態および静的ルールデータを復元する（３６４５で）。一部のこのような実施形態では、静的ルールが復元される前に、復元された状態を使用して、以前に処理されたフローのデータメッセージを処理することができる。移行されたＳＶＭが移行先ホストの最初のＳＶＭである場合、いくつかの実施形態では、移行先ホストにネクストホップ転送ルールもＶＴＥＰからＭＡＣアドレスへのマッピングもない。いくつかのこのような実施形態では、処理３６０５は、移行されたＳＶＭデータ３７９０からのＭＡＣマッピングにネクストホップ転送ルールおよび／またはＶＴＥＰを復元する。また、処理３６０５は、ＣＣＰが非アクティブであるか、またはサービスプレーン情報を分配することができない場合に、ネクストホップ転送ルールおよび／またはＶＴＥＰからＭＡＣアドレスマッピングをいくつかの実施形態で復元する。他の実施形態では、移行されたすべてのＳＶＭデータは、代わりに、移行されたＳＶＭの配置時に消費される。このような場合、配置後のＳＶＭ状態の復元は不要であり、スキップされる可能性がある。必要な状態および／またはルールが回復されると、処理３６０５は終了する。

【0240】

[00279] ホスト１１２が、ＳＶＭ３７０６がホスト１１４上に配置され、設定されたという確認通知を受信すると、プロセス３６００は、ホスト１１２から（３６３０で）ＳＶＭ３７０６の破棄を開始する。いくつかの実施形態では、送信元ホストはＣＣＰから確認応答を受信するが、他の実施形態では、確認応答は宛先ホスト自体から受信される。いくつかの実施形態では、ＳＶＭ３７０６は、まず、そのＩＯチェーンから切断され、次に、除去される。

【0241】

[00280] ３６３０で、プロセスはまた、ＳＶＭ３７０６のＩＯチェーンと、ＳＩプロキシ３７１４およびＳＴＬモジュール３７２６を含むＳＶＭ３７０６がｖｓｗｉｔｃｈ１２０に接続するポート３７５４を破棄する。いくつかの実施形態では、ＩＯチェーンは、ホスト１１２から除去される前に、ポート３７５４から切断される。いくつかの実施形態では、送信元ホストは、移行されたＳＶＭに固有のデータを除去する。いくつかの実施形態におけるサービスプレーンはまた、ホスト１１２におけるその位置への移行されたＳＶＭ３７０６のマッピングを除去する。ＳＶＭ３７０５、ＳＶＭ３７０６のＩＯチェーン、およびそれらに関連するデータが送信元ホスト１１２から除去されると、処理３６００は終了する。図３７Ｃは、ＳＶＭ３７０６の移行が完了した後のホスト１１２とホスト１１４を示す。

【0242】

[00281] いくつかの実施形態では、制御プレーンは、ＳＶＭの移行を検出し、それに応じてサービスおよび転送プレーンを更新する責任を負う。ＳＶＭ移行後に実行される制御プレーン動作は、いくつかの実施形態において制御プレーンによって実行される処理３８００を示す図３８を参照してさらに説明される。このプロセスは、図３７Ａ～３７Ｃを参照して、以下に記述される。

【0243】

[00282] 図に示すように、処理３８００は、制御ペインが、ＳＶＭ３７０６が送信元ホスト１１２から宛先ホスト１１４に移行したことを（３８１０において）決定したときに開始する。いくつかの実施形態では、制御プレーンは、ＣＣＰで受信した１つ以上の通知に基づいて、ＳＶＭがホストを移行したと判断する。いくつかの実施形態では、制御プレーンは、ＳＶＭ３７０６が配置されたことの宛先ホスト１１４から第１の通知と、ＳＶＭ３７０６が切断されたことの送信元ホスト１１２から第２の通知とを受信する。いくつかの実施形態では、第１の通知は宛先ホストのＬＣＰによって送信され、第２の通知は送信元ホストのＬＣＰによって送信される。

【0244】

[00283] 制御プレーンがＳＶＭ３７０６の移行を決定すると、プロセスは（３８２０で）移行されたＳＶＭ３７０６の新しい位置を公開し、ＳＶＭ３７０６宛てのメッセージを送信元ホスト１１２ではなく宛先ホスト１１４に転送するようにサービスプレーンを構成する。いくつかの実施形態では、制御プレーンは、ＳＶＭネクストホップＭＡＣアドレス（これは、以前と同じである）のＶＴＥＰへのマッピングを公開し、これによりＳＶＭに到達できる。いくつかの実施形態では、マッピングは、サービスプレーンで維持されるグローバル転送テーブルに公開され、そこでは、送信元ホストに関連するＶＴＥＰへのＳＶＭの以前のマッピング（例えば、１１２）を置き換える。このようないくつかの実施形態では、マッピングは、サービスプレーンを実装する各転送要素のホストにおいて、ＣＣＰからＬＣＰに公開される。この例では、カプセル化モジュール６２８および３４２８は、ホスト１１２のＶＴＥＰの代わりにホスト１１４のＶＴＥＰでＳＶＭ３７０６のＭＡＣアドレス宛てのパケットをカプセル化するように構成される。

【0245】

[00284] 必要に応じて、制御プレーンは、ＳＶＭ３７０６の移行に基づいて（３８３０で）新しいサービスパスを生成する。いくつかの実施形態では、サービスパス選択指標は、サービスパス内のサービスノードの相対的な位置に、少なくとも部分的に、互いに比較して依存する。このようないくつかの実施形態では、ＳＶＭが別のホストに移行されると、ＳＶＭを構成するサービスパスは最適化されなくなる。いくつかの実施形態では、移行されたＳＶＭ３７０６を含むサービスパスを置き換えるために、新しいサービスパスが生成され、その中で、ＳＶＭ３７０６は、同じサービスを実行する異なるＳＶＭによって置き換えられる。いくつかの実施形態では、ＳＶＭの移行により、サービスチェーンの以前のサービスパスよりも最適な、移行されたＳＶＭを構成する新しいサービスパスが生成されることが可能になる。

【0246】

[00285] ３８４０で、プロセスはサービスパスを分配する。いくつかの実施形態では、サービスパスは、ネクストホップ転送ルールの形成において送信される。いくつかの実施形態では、制御プレーン（例えば、ＣＣＰ）は、移行されたＳＶＭ３７０６を構成する任意のサービスパスを宛先ホスト１１４に分配する。他の実施形態では、ネクストホップ転送ルールはサービスプレーン内でグローバルに維持され、宛先ホスト１１４は、移行されたＳＶＭ３７０６を含むサービスパスに対するネクストホップ転送ルールをすでに有するであろう。いくつかの実施形態では、受信されたサービスパスは、サービスパス（例えば、ＳＩプロキシ３７１５）のサービスノードのサービスプロキシによって記憶される。

【0247】

[00286] いくつかの実施形態では、サービスパスはＣＣＰで生成され、各ホストのＬＣＰを介してホストに分配される。いくつかの実施形態では、ＣＣＰは、サービスプレーンのＳＶＭをホストする各ホストに新しいサービスパスのネクストホップ転送ルールを分配し、一方、他の実施形態では、各特定のサービスパスのネクストホップ転送ルールは、特定のサービスパスによってスパンされるホストに分配される。

【0248】

[00287] いくつかの実施形態では、新しく生成されたサービスパスは、サービスパスが生成されるサービスチェーンに関連するＧＶＭを実行するホストの少なくともサブセットに分散される。いくつかの実施形態では、各ホストは、各サービスチェーンに対して１つのサービスパスを受信するが、他の実施形態では、各ホストは、各サービスチェーンに対して複数のサービスパスを受信する。いくつかの実施形態では、ホストは、それらのＧＶＭが関連付けられているサービスチェーンのためのサービスパスを受信するが、他の実施形態では、各ホストは、すべての分散サービスパスを受信する。いくつかの実施形態では、受信されたサービスパスは、それぞれのホストのサービスパステーブルに格納される。また、いくつかの実施形態では、各ＧＶＭホストのＬＣＰは、各サービスチェーンに対して記憶する１つのサービスパスを選択する。

【0249】

[00288] ３８５０で、制御プレーンは、特定のパステーブルのサービスパスのための新しいサービスパス選択指標を計算する。いくつかの実施形態では、新しいサービスパス選択指標は、移行されたＳＶＭ３７０６を含む各サービスパスに対して計算される。新しいサービスパスが生成されるとき、いくつかの実施形態において、サービスパス選択指標は、各新しいサービスパスに対して生成される。いくつかの実施形態では、サービスパス選択指標は、ホストのＬＣＰによって各ホストのパステーブルに対して計算される。サービスパス選択指標が計算されると、処理３８００は終了する。サービスチェーンごとに１つのサービスパスのみが格納される場合、いくつかの実施形態では、サービスパス選択指標は、サービスパスと共に格納されない。

【0250】

[00289] いくつかの実施形態は、同じホストコンピュータのディスク割り当ての間でサービスマシンを移行するための新しい方法も提供する。たとえば、ユーザまたは管理者は、ＳＶＭをプライベートディスク割り当てから共有ディスク割り当てに、またはその逆に移行することを望む場合がある。いくつかの実施形態では、第１および第２のディスク割り当ては、同じホストコンピュータ上の別々のデータストア（例えば、２つのVMware NFSデータストア）に関連付けられる。いくつかの実施形態では、ディスク割り当ては、同じディスク記憶装置の第１および第２の割り当てである。他の実施形態では、ディスク割り当ては、別個の第１および第２のディスク記憶装置である。このようないくつかの実施形態では、同じホストコンピュータのハードウェアディスク記憶装置間でＳＶＭを移行して、ワークロードのバランスを取ることができる。ディスク割り当ての間でＳＶＭを移行するプロセスは、図３６に示す同じ一連の動作に従う。ただし、ホスト内ＳＶＭ移行の場合、プロセス３６００は移行元のディスク割り当てによって実行され、プロセス３６０５は移行先のディスク割り当てによって実行される。このプロセスは、図３９に示されているホスト内ＳＶＭ移行例を参照することによって以下に説明される。プロセス３６００は、ホスト１１２の第１のディスク割り当て上のＮＦＳデータストア３９１０上のＳＶＭ３９０６を、ホスト１１２上の第２のディスク割り当て上のＮＦＳデータストア３９２０にも移行する必要があると判断されたときに開始される。３９０１は、移行前のホスト１１２を示す。

【0251】

[00290] 図に示すように、処理３６００は、最初に、ＳＶＭ３９０６に関するＳＶＭデータを（３６１０で）保存する。送信元ＮＦＳ３９１０は、（３６２０で）保存されたＳＶＭデータ３９９０を宛先ＮＦＳ３９２０に送信する。いくつかの実施形態では、ＳＶＭデータ３９９０は、ホストコンピュータ間のＳＶＭ移行中に収集されるＳＶＭデータ（例えば、ＳＶＭデータ３７９０）の少なくともサブセットを含む。いくつかの実施形態では、ＳＶＭデータ３９９０は、ホスト１１２上の仮想マシンモビリティ管理サービス（例えば、ＶＭｗａｒｅ Ｉｎｃ．のエンタープライズモビリティ管理）を介して送信される。ＳＶＭデータ３９９０が送信元ＮＦＳ３９１０から送信された後、プロセス３６０５は、宛先ＮＦＳ３９２０でＳＶＭデータ３９９０を開始し、（３６２５で）受信する。いくつかの実施形態では、ＳＶＭデータ３９９０は、マシン移行のＮＦＳ３９２０に警告する。

【0252】

[00291] 処理３６０５は、ＳＶＭデータ３９９０を使用して、宛先ＮＦＳ３９２０上に（３６３５で)ＳＶＭ３９０６を配置する。いくつかの実施形態では、ＳＶＭ３９０６は、移行されたＳＶＭデータ３９９０を使用して、移行されたＳＶＭ状態およびルールの一部または全部と共に配置される。他の実施形態では、ＳＶＭ状態およびルールデータの一部または全部が、代わりに配置後に復元される。３６３５では、プロセスはポート３９５５と入口および出口ＩＯチェーンも配置する。ＳＶＭ３９０６ は、ＩＯチェーンと接続され、それらを通じて、スイッチ１２０のポート３９５５に接続される。この例では、配置されたＩＯチェーンは、ＳＩプロキシ3915およびＳＴＬモジュール3927を含む。

【0253】

[00292] ３９０２で、ＳＶＭ ＩＯチェーンの２つのインスタンスがホスト１１２で実行される。いくつかの実施形態では、ＳＶＭ３９０６の２つのインスタンスのＩＯチェーンは、同じＶＮＩＣ ＭＡＣアドレスによって宛先指定可能である。また、いくつかの実施形態では、ポート３９５４およびポート３９５５は、異なるポートＩＤを有する。いくつかの実施形態では、配置の一部として（３６３５において）、プロセスは、ＮＦＳ３９２０上に配置されたＳＩプロキシ３９１５に対するハンドルのマッピングを、ＭＡＣアドレスおよびポート３９５５ポートＩＤ(例えば、ポートテーブルまたはハンドルテーブル内）に保存する。

【0254】

[00293] いくつかの実施形態では、一旦ＳＶＭ３９０６とそのＩＯチェーンがＮＦＳ３９２０上に配置されると、処理３６０５は、受信したＳＶＭデータ３９９０からＮＦＳ３９２０でＳＶＭ３９０６の動的状態と静的ルールデータを復元する（３６４５で）。他の実施形態では、代わりに、配置が不要になりスキップされ得る後に、移行されたすべてのＳＶＭデータは、ＳＶＭ３９０６の配置中およびＳＶＭ状態とルールの復元で消費される。必要な状態および／またはルールが回復されると、処理３６０５は終了する。

【0255】

[00294] ＮＦＳ３９１０が、ＳＶＭ３９０６がＮＦＳ３９２０に配置され、設定されたという確認通知を受信すると、処理３６００は、ＮＦＳ３９２０からＳＶＭ３９０６の破棄を開始する（３６３０で）。いくつかの実施形態では、送信元ＮＦＳはＣＣＰから確認応答を受信するが、他の実施形態では、確認応答はＬＣＰまたは宛先ＮＦＳそれ自体から受信される。いくつかの実施形態では、ＳＶＭ３９０６は、まずそのＩＯチェーンから切断され、次にＮＦＳ ３９２０から除去される。

【0256】

[00295] ３６３０において、このプロセスは、ＮＦＳ３９１０およびＳＶＭ３９０６がＮＦＳ３９１０（ＳＩプロキシ３９１４およびＳＴＬモジュール３９２６を含む）からｖＳｗｉｔｃｈ１２０に接続するポート３９５４のＳＶＭ３９０６ＩＯチェーンも破棄する。いくつかの実施形態では、ＩＯチェーンは、ＮＦＳ３９１０から除去される前に、ポート３９５４から切断される。いくつかの実施形態では、送信元ＮＦＳ３９１０は、移行されたＳＶＭ３９０６に固有のデータを除去する。いくつかの実施形態におけるサービスプレーンは、ＳＶＭ３９０６のポート３９５４へのマッピングも除去する。ＳＶＭ３９０６、ＳＶＭ ＩＯチェーン、およびその関連データがＮＦＳ３９１０から除去されると、処理３６００は終了する。３９０３は、ＳＶＭ３９０６のホスト内移行が完了した後のＮＦＳ３９１０とＮＦＳ３９２０を示す。

【0257】

[00296] 上述したように、いくつかの実施形態では、ホスト内移行中に、ＳＶＭ ＩＯチェーンが同じＭＡＣアドレスを持つ同じホスト上の第１および第２のディスク割り当ての両方で実行される間隔がある。いくつかの実施形態では、これは、ＳＶＭ ＩＯチェーンが第２のディスク割り当て（３６３５）に配置された後、ＳＶＭ ＩＯチェーンが第１のディスク割り当て（３６３０）から除去される前に発生する。例えば、３９０２において、ＮＦＳ ３９１０におけるＳＩプロキシ３９１４およびＮＦＳ３９２０におけるＳＩプロキシ３９１５は、両方ともホスト１１２上で実行される。いくつかの実施形態では、これにより、制御プレーンとＳＩプロキシとの間の通信に問題が生じる可能性がある。例えば、いくつかの実施形態では、ＬＣＰ ３９３０がＳＩプロキシ３９１５にメッセージを送信する必要があるとき、ＬＣＰは、ＳＶＭ３９０６のＭＡＣアドレスに基づいてＳＩプロキシ３９１５のハンドルを検索する。ただし、同じＭＡＣアドレスを持つ２つのＳＩプロキシが同じホストで動作する場合、ＭＡＣアドレスのみに基づくルックアップで２つのＳＩプロキシハンドルが識別される。したがって、ＭＡＣアドレスルックアップは、ＳＩプロキシ３９１４とＳＩプロキシ３９１５の両方のハンドルを返す。

【0258】

[00297] いくつかの実施形態では、正しいハンドルを選択するために、所望のＳＩプロキシのポートＩＤを使用して、第２のルックアップが実行される。この例では、ＳＩプロキシ３９１５のハンドルを識別するために、ＬＣＰ３９３０は、ポート３９５５のポートＩＤを使用して第２のルックアップを実行する。この２回目のルックアップでは、ＳＩプロキシ３９１５ のハンドルが返される。他の実施形態では、最初のルックアップは、代わりに、ＳＩプロキシのＭＡＣアドレスとポートＩＤの両方を使用して実行され、単一の検索で正しいハンドルを識別する。いくつかの実施形態では、ＬＣＰは、ハンドルを使用して、ＳＩプロキシを構成するための構成メッセージを送信する。

【0259】

[0001] いくつかの実施形態では、ライブネススレッド３９４０は、ＳＶＭ ３９０６のライブネス時間タイマーが経過したと判断すると、ＳＶＭ３９０６プロキシにメッセージを送信して、ＳＶＭ３９０６にメッセージを送信する。ライブネスタイマーメッセージが３９１４の代わりにＳＩプロキシ３９１５に送信されることを保証するために、ライブネススレッド３９４０は、ＭＡＣアドレスを使用する第１のルックアップと、ポートＩＤを使用する第２のルックアップ、またはＭＡＣアドレスとポートＩＤの両方を使用する単一のルックアップを実行して、ＳＩプロキシ３９１５の処理を識別する。また、いくつかの実施形態では、サービスプレーンは、ポートＩＤとＭＡＣアドレスとの関連付けを自動的に保存し、データプレーン転送中に宛先マシンの関連するポートＩＤとＭＡＣアドレスの両方を使用してＳＶＭ ＩＯチェーンを識別する。

【0260】

[00298] 上述の特徴およびアプリケーションの多くは、コンピュータ可読記憶媒体（コンピュータ可読媒体とも呼ばれる）に記録された命令のセットとして規定されるソフトウェアプロセスとして実施される。これらの命令が、１つ以上の処理ユニット（例えば、１つ以上のプロセッサ、プロセッサのコア、または他の処理ユニット）によって実行されるとき、それらは、処理ユニットに、命令に示されたアクションを実行させる。コンピュータ可読媒体の例としては、ＣＤ－ＲＯＭ、フラッシュドライブ、ＲＡＭチップ、ハードドライブ、ＥＰＲＯＭ等があるが、これらに限定されない。コンピュータ可読媒体は、有線で又は有線接続を介して通過する搬送波及び電気信号を含まない。

【0261】

[00299] この明細書において、「ソフトウェア」という用語は、プロセッサによって処理するためにメモリに読み込むことができる、読み取り専用メモリに存在するファームウェア、または磁気記憶装置に記憶されたアプリケーションを含むことを意味する。また、いくつかの実施形態において、複数のソフトウェア発明は、別個ソフトウェア発明を残しつつ、より大きなプログラムのサブパートとして実施することができる。いくつかの実施形態において、複数のソフトウェア発明は、別個のプログラムとして実施することもできる。最後に、ここに記載されるソフトウェア発明を共に実施する別個のプログラムの任意の組合せは、本発明の範囲内である。いくつかの実施形態では、ソフトウェアプログラムは、１つ以上の電子システム上で動作するようにインストールされると、ソフトウェアプログラムの動作を実行し実行する１つ以上の特定のマシン実装を定義する。

【0262】

[00300] 図４０は、本発明のいくつかの実施形態が実施されるコンピュータシステム４０００を概念的に示す。コンピュータシステム４０００は、上述のホスト、コントローラ、およびマネージャのいずれかを実装するために使用することができる。したがって、上記のプロセスのいずれかを実行するために使用することができる。このコンピュータシステムは、様々なタイプの一時的でない機械可読媒体と、様々な他のタイプの機械可読媒体のためのインタフェースとを含む。コンピュータシステム４０００は、バス４００５、処理部４０１０、システムメモリ４０２５、読み出し専用メモリ４０３０、永続的記憶装置４０３５、入力装置４０４０、および出力装置４０４５を含む。

【0263】

[00301] バス４００５は、コンピュータシステム４０００の多数の内部装置を通信的に接続するすべてのシステム、周辺装置、およびチップセットバスを総称して表す。例えば、バス４００５は、処理部４０１０を読み出し専用メモリ４０３０、システムメモリ４０２５、および永続的記憶装置４０３５と通信可能に接続する。

【0264】

[00302] これらの様々なメモリユニットから、処理部４０１０は、本発明のプロセスを実行するために、実行する命令と処理するデータを検索する。処理部は、様々な実施形態において、単一プロセッサまたはマルチコアプロセッサであってもよい。読み出し専用メモリ（ＲＯＭ）４０３０は、処理部４０１０およびコンピュータシステムの他のモジュールによって必要とされる静的データおよび命令を格納する。一方、永続的記憶装置４０３５は、読み書き可能な記憶デバイスである。この装置は、コンピュータシステム４０００がオフであっても命令及びデータを記憶する不揮発性メモリユニットである。本発明のいくつかの実施形態は、永続的記憶装置４０３５として大容量記憶装置（磁気または光ディスクおよびその対応するディスクドライブなど）を使用する。

【0265】

[00303] 他の実施形態は、永続的記憶装置としてリムーバブル記憶装置（フラッシュドライブ等）を使用する。永続的記憶装置４０３５と同様に、システムメモリ４０２５は、読み書き可能な記憶デバイスである。しかしながら、記憶デバイス４０３５とは異なり、システムメモリは、ランダムアクセスメモリのような揮発性の読み出し／書き込みメモリである。システムメモリには、プロセッサが実行時に必要とする命令とデータの一部が格納される。いくつかの実施形態では、本発明のプロセスは、システムメモリ４０２５、永続的記憶装置４０３５、および／または読み出し専用メモリ４０３０に記憶される。これらの様々なメモリユニットから、処理部４０１０は、いくつかの実施形態のプロセスを実行するために、実行する命令および処理するデータを検索する。

【0266】

[00304] バス４００５は、入出力装置４０４０および４０４５にも接続する。入力装置は、ユーザが情報を伝達し、コンピュータシステムにコマンドを選択することを可能にする。入力装置４０４０は、英数字キーボード及びポインティングデバイス（「カーソル制御デバイス」とも呼ばれる）を含む。出力装置４０４５は、コンピュータシステムによって生成された画像を表示する。出力装置には、陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）などのプリンタおよび表示装置が含まれる。いくつかの実施形態は、入力装置および出力装置の両方として機能するタッチスクリーンなどの装置を含む。

【0267】

[00305] 最後に、図４０に示すように、バス４００５は、ネットワークアダプタ（図示せず）を介して、コンピュータシステム４０００をネットワーク４０６５に結合する。このようにして、コンピュータは、コンピュータのネットワーク（ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、またはイントラネットの一部、あるいはインターネットのようなネットワークのネットワークであってもよい。コンピュータシステム４０００の任意のまたはすべての構成要素を、本発明と併せて使用することができる。

【0268】

[00306] いくつかの実施形態は、コンピュータプログラム命令を、機械可読又はコンピュータ可読媒体（代替的には、コンピュータ可読記憶媒体、機械可読媒体、又は機械可読記憶媒体と称される）に記憶するマイクロプロセッサ、記憶装置及びメモリ等の電子コンポーネントを含む。このようなコンピュータ可読媒体のいくつかの例としては、ＲＡＭ、ＲＯＭ、読取り専用コンパクトディスク（ＣＤ－ＲＯＭ）、記録可能コンパクトディスク（ＣＤ－Ｒ）、書き換え可能コンパクトディスク（ＣＤ－ＲＷ）、読取り専用デジタル汎用ディスク（例えば、ＤＶＤ－ＲＯＭ、デュアルレイヤＤＶＤ－ＲＯＭ）、様々な記録可能／書き換え可能ＤＶＤ（例えば、ＤＶＤ－ＲＡＭ、ＤＶＤ－ＲＷ、ＤＶＤ＋ＲＷ等）、フラッシュメモリ（例えば、ＳＤカード、ｍｉｎｉ－ＳＤカード、マイクロＳＤカード等）、磁気および／またはソリッドステートハードドライブ、読取り専用および記録可能なＢｌｕ－Ｒａｙ（登録商標）ディスク、超密度光ディスク、および他の任意の光または磁気媒体がある。コンピュータ可読媒体は、少なくとも１つの処理ユニットによって実行可能であり、様々な動作を実行するための命令のセットを含むコンピュータプログラムを記憶することができる。コンピュータプログラムまたはコンピュータコードの例としては、コンパイラによって生成されるようなマシンコードと、インタープリタを使用してコンピュータ、電子コンポーネント、またはマイクロプロセッサによって実行される上位レベルのコードを含むファイルがある。

【0269】

[00307] 上記の議論は、主に、ソフトウェアを実行するマイクロプロセッサまたはマルチコアプロセッサを指すが、いくつかの実施形態は、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のような、１つ以上の集積回路によって実行される。いくつかの実施形態では、このような集積回路は、回路自体に記憶された命令を実行する。

【0270】

[00308] 本明細書で使用される「コンピュータ」、「サーバ」、「プロセッサ」、「メモリ」という用語は、すべて電子的またはその他の技術的デバイスを指す。これらの用語は、人または人のグループを除く。明細書の目的上、表示または表示手段の用語は、電子デバイス上に表示することを意味する。本明細書で使用されるように、「コンピュータ可読媒体」（複数）、「コンピュータ可読媒体」、および「マシン読み取り可能媒体」という用語は、コンピュータが読み取り可能な形式で情報を格納する有形の物理オブジェクトに全体として限定される。これらの用語は、ワイヤレス信号、有線ダウンロード信号、およびその他の一時的または一時的な信号を除外する。

【0271】

[00309] 本発明は、多くの特定の詳細を参照して説明されてきたが、当業者は、本発明の意図から離れることなく、本発明が他の特定の形態で実施可能であることを認識するであろう。例えば、いくつかの図は、プロセスを概念的に示している。これらのプロセスの特定の操作は、示され、説明されている正確な順序では実行されない場合がある。特定の動作は、１つの連続した一連の動作で実行されなくてもよく、異なる特定の動作が様々な実施形態で実行されてもよい。さらに、プロセスは、いくつかのサブプロセスを使用して、またはより大きなマクロプロセスの一部として実装することができる。

【0272】

[00310] 上述のいくつかの例におけるサービス挿入ルールはサービスチェーン識別子を提供するが、本明細書に記載する発明のいくつかは、サービス挿入ルールがサービス挿入ルールによって指定される異なるサービスのサービス識別子（例えば、ＳＰＩ）を提供することによって実施することができる。同様に、上述の実施形態のいくつかは、ＳＰＩ／ＳＩ値に基づいて完全一致を実行することによって、次のサービスホップを識別する各サービスホップに依存する分散サービスルーティングを実行する。しかしながら、本明細書に記載する発明のいくつかは、サービス挿入プリプロセッサに、すべてのサービスホップ識別子（例えば、サービスホップＭＡＣアドレス）をデータメッセージのサービス属性セットおよび／またはデータメッセージのカプセル化サービスヘッダに埋め込むことによって実施することができる。

【0273】

[00311] さらに、いくつかの実施形態は、上記のアプローチとは異なるように（例えば、異なる時間に）ＳＩ値をデクリメントする。また、ＳＰＩ値とＳＩ値だけに基づいてネクストホップルックアップを実行する代わりに、いくつかの実施形態は、ＳＰＩ、ＳＩおよびサービス方向値に基づいてこのルックアップを実行し、これらの実施形態は、２つのマシン間を流れるデータメッセージの順方向と逆方向の両方に共通のＳＰＩ値を使用する。

【0274】

[00312] 上記の方法論は、単一テナント環境におけるパス情報を表現するために、いくつかの実施形態において使用される。したがって、本発明のいくつかの実施形態は、単一テナントのデータセンタに等しく適用可能であることを、当業者は理解するであろう。逆に、いくつかの実施形態では、上述の方法論は、１つのエンティティ（例えば、１つの企業）が異なるプロバイダの複数の異なるデータセンタ内のテナントであるとき、異なるデータセンタプロバイダの異なるデータセンタ間でパス情報を運ぶために使用される。これらの実施形態では、トンネルヘッダに埋め込まれるテナント識別子は、データセンタ全体で一意であるか、またはデータセンタ間を横断するときに置き換えらればならない。したがって、当業者であれば、本発明は、上述の例示的な詳細によって限定されるものではなく、むしろ、添付のクレームによって定義されるものであることが理解されるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34A】

【図34B】

【図34C】

【図35】

【図36】

【図37A】

【図37B】

【図37C】

【図38】

【図39】

【図40】