JP2020205590A - ネットワーク制御システムのパブリッククラウドへの拡張 - Google Patents

ネットワーク制御システムのパブリッククラウドへの拡張 Download PDF

Info

Publication number
JP2020205590A
JP2020205590A JP2020130708A JP2020130708A JP2020205590A JP 2020205590 A JP2020205590 A JP 2020205590A JP 2020130708 A JP2020130708 A JP 2020130708A JP 2020130708 A JP2020130708 A JP 2020130708A JP 2020205590 A JP2020205590 A JP 2020205590A
Authority
JP
Japan
Prior art keywords
data
network
logical
gateway
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2020130708A
Other languages
English (en)
Other versions
JP7009014B2 (ja
Inventor
ガネサン チャンドラシェカー，
Chandrashekhar Ganesan
ガネサン チャンドラシェカー，
ムケシュ ヒラ，
Hira Mukesh
ムケシュ ヒラ，
アクシェイ カットリーカー，
Katrekar Akshay
アクシェイ カットリーカー，
スー ワン，
Su Wang
スー ワン，
ジア ユー，
Jia Yu
ジア ユー，
サウラブ シャー，
Shah Saurabh
サウラブ シャー，
サナル ピルライ，
Pillai Sanal
サナル ピルライ，
ジャヤント ジャン，
Jian Jayant
ジャヤント ジャン，
ロンフア ツァン，
Ronghua Zhang
ロンフア ツァン，
ヴァイハヴ クルカルニ，
Kulkarni Vaibhav
ヴァイハヴ クルカルニ，
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nicira Inc
Original Assignee
Nicira Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/253,832 external-priority patent/US10193749B2/en
Priority claimed from US15/367,157 external-priority patent/US10333959B2/en
Application filed by Nicira Inc filed Critical Nicira Inc
Publication of JP2020205590A publication Critical patent/JP2020205590A/ja
Priority to JP2022001263A priority Critical patent/JP7190595B2/ja
Application granted granted Critical
Publication of JP7009014B2 publication Critical patent/JP7009014B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/044—Network management architectures or arrangements comprising hierarchical management structures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Abstract

【課題】第１のネットワーク制御器がアクセスできない転送要素を含むデータセンタにおいて実現される論理ネットワークを管理する第１のネットワーク制御器に対する方法を提供する。【解決手段】階層型ネットワーク制御システムにおいて、第２のネットワーク制御器を実行するデータセンタ内の第１のデータ計算ノード（ＤＣＮ）を識別する。論理ネットワークを定義する構成データを第１のＤＣＮに配布する。第２のネットワーク制御器は、論理ネットワークを介してメッセージを送受信するデータセンタ内の更なるＤＣＮ上で実行するローカルエージェントに構成データのセットを配布する。被管理転送要素及びローカルエージェントの双方は、更なるＤＣＮの各々において実行する。【選択図】図４

Description
一般的なデータセンタの設定は、仮想マシン又は他のデータ計算ノードをホストする多くのサーバを含み、サーバの仮想化ソフトウェア内の転送要素（例えば、ソフトウェア仮想スイッチ）は、それらのデータ計算ノードに対するパケット転送及びネットワークセキュリティを処理する。プライベートデータセンタ（例えば、企業ネットワーク）には、データセンタの所有者がホストサーバのハイパーバイザを制御することにより、自身のセキュリティ規則及びパケット転送規則を実現できるようにする技術が存在する。
パブリックデータセンタは、企業の自社プライベートデータセンタからネットワークを拡張又は移行することにより、企業が物理サーバのコスト及び他の負担と物理サーバに必要な定期的維持費とを軽減できるようにする。しかし、パブリックデータセンタには仮想化ソフトウェアを制御するそれ自体の所有者が存在し、また、堅牢又は透過的なセキュリティ機能を有さない場合がある。そのため、セキュリティ制御を直接実行できないことを理由に、自社ネットワークをこれらのパブリックデータセンタに移行することに躊躇する企業がある。
本発明のいくつかの実施形態は、（ｉ）ネットワーク管理／制御システムが転送要素にアクセス及び制御できるプライベートデータセンタと、（ｉｉ）システムが転送要素にアクセスできない１つ以上のパブリックマルチテナントデータセンタとにまたがる論理ネットワークを管理する機能を有するネットワーク管理／制御システムを提供する。いくつかの実施形態のプライベートデータセンタでは、ネットワーク管理／制御システム（本明細書中、ネットワーク制御システムと呼ぶ）は、ホストマシンの仮想化ソフトウェア（例えば、ハイパーバイザ）内で実行するソフトウェア転送要素を管理し、従って、管理者の所望のネットワーク転送ポリシー及びセキュリティポリシーを実現できる。しかし、パブリックデータセンタでは、ネットワーク制御システムは仮想化ソフトウェアにアクセスできず、従って、パブリックデータセンタ内で動作するワークロードに対して同一のネットワークポリシーを実現できない場合がある。
いくつかの実施形態は、プライベートデータセンタの管理及び制御をパブリックデータセンタに拡張するために階層型ネットワーク制御システムを使用する。詳細には、いくつかの実施形態は、データ計算ノード（ＤＣＮ）との間で送受信されるパケットに対するネットワークセキュリティ規則及び転送規則を実施するために、パブリックデータセンタ内で動作する仮想マシン（ＶＭ）又は他のＤＣＮ内のネットワーク制御器及び被管理転送要素を動作させる。いくつかの実施形態において、パブリックデータセンタは、テナントが制御できる１つ以上の隔離されたリソース（すなわち、データ計算ノード）セットをテナントに提供する。これを仮想プライベートクラウド（ＶＰＣ）とも呼ぶ。一部のクラウドプロバイダでは、テナントはネットワークサブネット及びルーティングテーブルを用いて仮想ネットワークを定義すること及び／又はパブリッククラウドプロバイダにより定義されたセキュリティグループに自身のＤＣＮを入れることが可能である。
階層型ネットワーク制御システムを実現するために、いくつかの実施形態は、各ＶＰＣ内の第１のＤＣＮ（又は、各ＶＰＣ内のアクティブ／スタンバイゲートウェイ制御器としてのＤＣＮのセット）において第１のレベルのネットワーク制御器（ゲートウェイ制御器と呼ぶ）を実現する。また、これらのゲートウェイＤＣＮは、いくつかの実施形態において、同じデータセンタの他のＶＰＣ又は他のデータセンタ（プライベートデータセンタ又は別のパブリックデータセンタ）内の論理ネットワークとの通信及び外部ネットワークと通信のためにゲートウェイデータパスを動作させる。各ワークロードＤＣＮ（すなわち、ウェブサーバ、アプリケーションサーバ、データベースサーバ等のワークロードアプリケーションを実行するＤＣＮ）内で、被管理転送要素（ＭＦＥ）がワークロードアプリケーションとＤＣＮのネットワークインタフェースとの間のデータパスに挿入される。更に、各ＭＦＥを構成するために、ローカル制御エージェントが各ワークロードＤＣＮ上で実行する。
プライベートデータセンタ（又は、別個のＶＰＣ）内で動作する中央制御プレーンクラスタは、構成規則の範囲に基づいて、プライベートデータセンタ内のホストマシン上で動作するローカル制御器に（すなわち、規則の種類及び規則が適用される論理ポートに基づいて、規則を実施する必要があるＭＦＥに）構成規則を配布する。パブリックデータセンタＶＰＣ内で動作する制御システムに当該規則を配布する場合、中央制御器は、ＶＰＣ内のＤＣＮに対応する全ての論理ポートがゲートウェイ制御器により制御されるＭＦＥに接続されていると見なす。そのため、当該規則は全て、中央制御器によりゲートウェイ制御器に出力される。
次に、ゲートウェイ制御器は、中央制御器から受信した各規則を必要とするＶＰＣ内のＭＦＥを識別するために、独自の別個の適用範囲の計算を行い、ＭＦＥを制御するように動作するローカル制御エージェントに当該規則を配布する。ローカル制御エージェントは、規則を受信すると、ＤＣＮで動作するＭＦＥに特有のフォーマットに規則を変換する。例えばいくつかの実施形態は、パブリックデータセンタＶＰＣ内のＤＣＮ上で実行するＯｐｅｎ ｖＳｗｉｔｃｈ（ＯＶＳ）インスタンス等のフローベースＭＦＥを使用し、その場合、ローカル制御エージェントは、ＯＶＳインスタンスに対するフローエントリ及び／又は他の構成データに規則を変換する。
いくつかの実施形態において、ゲートウェイ制御器は、ＶＰＣ内のオーバーレイトンネルを管理する責任も有する。中央制御器は、ＶＰＣ全体を単一のＭＦＥと見なすため、ゲートウェイ制御器ノードに対するトンネルエンドポイント（すなわち、ゲートウェイＤＣＮ上に構成されたデータパス）のみを構成する。しかし、ＶＰＣ内のワークロードアプリケーション間（及びワークロードアプリケーションとゲートウェイデータパスとの間）の通信に対して、中央制御器はオーバーレイを構成しない。そのため、ゲートウェイ制御器は、ＭＦＥ毎にＭＡＣから仮想トンネルエンドポイント（ＶＴＥＰ）へのＩＰバインディングを構成することにより、これらのＤＣＮの間にトンネル（例えば、ＳＴＴ、ＧＥＮＥＶＥ等のトンネル）を設定する。当該情報はワークロードＤＣＮ上の種々のローカル制御エージェントにも渡されるため、各ＭＦＥは同じＶＰＣ内の他のＭＦＥにパケットをトンネリングすることができる。
上述したように、ゲートウェイＤＣＮはゲートウェイ制御器とデータパスとを含む。いくつかの実施形態において、データパスは、（ｉ）他のＶＰＣ及び他のデータセンタ内で動作し且つ論理ネットワークに接続されたワークロード及び（ｉｉ）外部ネットワークに自身のＶＰＣ内のワークロードを接続するゲートウェイとして動作する。いくつかの実施形態において、ゲートウェイＤＣＮは、３つのネットワークインタフェース、すなわち、外部ネットワークとの間で（クラウドプロバイダインターネットゲートウェイを介して）パケットを送受信するアップリンクインタフェースと、ローカルＶＰＣサブネット上のアドレスを有するＶＴＥＰインタフェースと、制御トラフィック専用の制御インタフェースとを含む。データパス及びゲートウェイ制御器に加えて、いくつかの実施形態は、ＶＰＣ内のＭＦＥ（場合によっては、ゲートウェイデータパスを含む）によるトラフィックをセキュリティ保護するために使用される暗号鍵を処理するための分散型ネットワーク暗号化（ＤＮＥ）マネージャと、ＶＰＣ内のＤＨＣＰを処理するためのＤＨＣＰモジュールと、管理プレーン及びゲートウェイ制御器がパブリッククラウド管理システムと対話できるようにするパブリッククラウドマネージャ（ＰＣＭ）とを含んでもよい。
例えばＰＣＭは、パブリッククラウドマネージャをポーリングして、ＤＣＮが属することになる論理スイッチ及び／又はセキュリティグループを示すＤＣＮに関連するタグを含めて新しいＤＣＮを識別する機能を有する。更に、いくつかの実施形態のＰＣＭは、パブリッククラウド管理システムと対話して、ＤＣＮが不正アクセスされたという通知を受信した場合にＤＣＮを隔離できる。例えば、ＭＦＥを実行するＤＣＮへのアクセスをハッカーが取得した場合、ハッカーは、（ｉ）ローカル制御エージェント及び／又はＭＦＥをアンインストールするか、（ｉｉ）ＭＦＥを介してトラフィックを送信しない新しいインタフェースを作成するか、（ｉｉｉ）既存のインタフェースをＭＦＥから切断するか、又は（ｉｖ）ＭＦＥをローカル制御エージェントから切断することによりＭＦＥを直接リプログラミングすることができる。インタフェースが編集された場合又は制御エージェントがＭＦＥから切断された場合、エージェントは変更を検出し、ゲート制御器に問題を通知する。エージェント自体が削除された場合、ゲートウェイ制御器はエージェントへの接続が失われたことを検出し、ＤＣＮが不正アクセスされたことを識別する。いずれの場合も、ゲートウェイ制御器は不正アクセスされたＤＣＮをＰＣＭに通知する。ＰＣＭは、不正アクセスされたＤＣＮを隔離セキュリティグループに入れるためにパブリッククラウド管理システムと対話する機能を有し、それにより（例えば、ホストマシンのハイパーバイザ内の）パブリッククラウド転送要素は不正アクセスされたＤＣＮからのトラフィックを遮断できる。
階層型ネットワーク制御システムは、プライベートデータセンタからパブリックデータセンタまたがる論理ネットワークの実現を可能にする。異なる実施形態において、異なる論理トポロジがデータセンタにまたがり異なる方法で実現されてもよい。例えばいくつかの実施形態は、所定の論理スイッチに接続されたＤＣＮをプライベートデータセンタ内の単一のＶＰＣに制限するか又は単一のＶＰＣと同様に動作するためにピア接続される同じデータセンタ内の複数のＶＰＣに制限する（当該論理スイッチは、論理ルータを介して、別のＶＰＣ又は別のデータセンタ内で実現される論理スイッチに論理的に接続されてもよい）。他の実施形態において、単一の論理スイッチは、同じパブリックデータセンタの複数のピア接続されていないＶＰＣ内のＤＣＮ、複数のパブリックデータセンタの複数のＶＰＣ内のＤＣＮ、並びに／又はパブリックデータセンタとプライベートデータセンタの双方のＤＣＮを有してもよい。
以上、ＶＰＣへの制御プレーンの拡張及び当該拡張を可能にするゲートウェイ制御器を説明したが、いくつかの実施形態において、ＶＰＣ内のこれらの種々の構成要素は初期構成され且つ管理プレーン及び中央制御プレーンと共に搭載される必要がある。いくつかの実施形態において、パブリッククラウドにおけるネットワーク及び制御システムの初期設定は運用マネージャ（ライフサイクルマネージャ又はＬＣＭとも呼ばれる）により管理される。ネットワーク管理者は、ネットワーク管理者のパブリッククラウド資格情報を使用する当該ＬＣＭと対話して（例えば、ユーザインタフェースを介して）ＬＣＭにアクセスし、ＶＰＣ内の種々のＶＭを初期構成する。
ＬＣＭは、管理者が論理ネットワークを実現したい各ＶＰＣを識別し、これらのＶＰＣの各々においてゲートウェイＤＣＮ（又はアクティブ／スタンバイゲートウェイＤＣＮセット）を自動的にインスタンス化する。いくつかの実施形態において、ゲートウェイＤＣＮは、特定のパブリッククラウドプロバイダ用にフォーマットされたプリパッケージインスタンスとして提供される。更に、いくつかの実施形態のＬＣＭは、ネットワーク制御システムにより管理される必要があるＶＰＣ内の既存のＤＣＮに関する情報を管理者から受信し、それらのＤＣＮに関する論理スイッチ及びセキュリティグループ情報を管理プレーンに提供する。
初期構成の一部として、ゲートウェイ制御器は管理プレーンに認定され（且つ管理プレーンアプリケーションが有効であることを検証し）、ゲートウェイ制御器が対話する中央制御器アプリケーションに同様に認定される必要がある。更に、ワークロードＤＣＮのうちの１つにおいて動作する各ローカル制御エージェントは、構成規則を配布する場合と同様の階層的方法でゲートウェイ制御器に自身を検証させる。
上記の段落における説明は、制御器が動作するＶＭが既に存在すると仮定する。場合によっては、ユーザ（例えば、非管理者ユーザ）は、パブリックデータセンタＶＰＣ内に新規のワークロードＤＣＮを作成し、正確な構成規則セットがＤＣＮ上のＭＦＥに提供されることを保証する必要がある。これはいつでも生じ得るため、従って、理想的には、その時点でネットワーク管理者による作業又は認可を必要としないようにするべきである。そのため、いくつかの実施形態において、ネットワーク制御システムは、これらの新規のワークロードＤＣＮのＭＦＥを自動的に提供するように構成される。
ＤＣＮを起動する前に、ユーザは、ワークロードが接続することになる論理スイッチ（及び／又はセキュリティグループ）に対するトークンと、インスタンスにインストールする制御エージェントパッケージとを管理者から受け取る。ＤＣＮを設定する際、ユーザは、論理スイッチ及び／又はセキュリティグループに対するトークンをインスタンスのラベルとして追加する。いくつかの実施形態において、ユーザがクラウドプロバイダユーザインタフェースを介してインスタンスを作成する場合、インタフェースは、ＶＭインスタンスに関するデータとしてパブリッククラウドデータリポジトリに格納されているタグをＶＭに追加する機能を含む。例えばタグは、ＶＭがセキュリティグループＳＧ１に属し且つ論理スイッチＬＳ１に接続する必要があることを示すために、「ｔｏｋｅｎ‐ｌｓ１」及び「ｔｏｋｅｎ‐ｓｇ１」というラベルが付けられてもよい。これらのタグは、何らかのアウトオブバンド機構を介して（例えば、口頭で、電子メール又はメッセージ送信等で）ネットワーク制御システム管理者からユーザに提供されてもよい。
いくつかの実施形態のＰＣＭは、当該データリポジトリを定期的にポーリングして、そのＶＰＣ内に作成された何らかの新規のＤＣＮを識別する。新規のＤＣＮがＶＰＣ内に作成されたという判定に応答して、ＰＣＭはいくつかの動作を実行する。ＰＣＭは、管理プレーンのインベントリに新規のＤＣＮを追加し、ＤＣＮに対する管理プレーン内に作成されたオブジェクトにＤＣＮの種々のパブリッククラウドプロバイダ属性（ＶＭ識別子、ＶＰＣ識別子、インタフェースＩＤ等）の全てをタグとして追加する。これにより、ネットワーク管理者はＤＣＮ及びその属性を管理プレーンインベントリで閲覧できる。また、ＰＣＭは、クラウドプロバイダＡＰＩを使用して論理スイッチ及び／又はセキュリティグループのタグを読み出す。ＰＣＭは論理スイッチタグを使用して、新規のポートを作成する論理スイッチを判定する。ＰＣＭは新規のポートを作成し、ＤＣＮのインタフェースを当該論理ポートに接続する（例えば、クラウドプロバイダからのインタフェース識別子を使用して）。更にＰＣＭは、インタフェースのＩＰアドレス及びＭＡＣアドレスを読み出し、これらを新規に作成された論理ポート上のＭＡＣ／ＩＰバインディングとして構成する。また、いくつかの実施形態は、要望に応じて、論理ポートに対してＤＦＷ規則を設定できるように、何らかの必要な特徴を有効にする。更に、ＰＣＭはセキュリティグループタグに基づいて新規のＤＣＮのセキュリティグループを識別し、管理プレーンを介して当該セキュリティグループに論理ポートを追加する。
上述したように、いくつかの実施形態のＭＦＥはＯＶＳインスタンス等のフローベースＭＦＥである。異なる実施形態において、これらのＯＶＳインスタンスは、非オーバーレイモード、別個の内部ＩＰアドレスと外部ＩＰアドレスとを使用する第１のオーバーレイモード又はそのＶＴＥＰ及び内部ワークロードアプリケーションに同じＩＰアドレスを使用する第２のオーバーレイモードのいずれで設定されてもよい。３つの場合の全てにおいて２つのブリッジがＯＶＳインスタンスに設定されるが、３つのオプションに対して３つの異なる方法がある。ワークロードアプリケーションは、ネットワークセキュリティ及び／又は論理転送動作を実行する統合ブリッジの内部ポートに接続する。物理インタフェース（ＰＩＦ）ブリッジは、ＭＦＥが動作するＤＣＮの仮想ネットワークインタフェース制御器（ＶＮＩＣ）に接続する。
いくつかの実施形態の非オーバーレイモードにおいて、ワークロードアプリケーションのＩＰアドレスは、クラウドプロバイダネットワーク（本明細書中、アンダーレイネットワークと呼ぶ）に対するＶＭネットワークインタフェースのＩＰアドレス（クラウドプロバイダにより割り当てられる）と同じである。この場合、ＭＦＥはパケット転送を一切実行せず、その代わりに、マイクロセグメンテーション及び／又は分散型ファイアウォール規則処理等のネットワークセキュリティ処理を実行するように構成される。このネットワークセキュリティ処理は統合ブリッジにより実行され、パケットはデフォルトで２つのブリッジ間のパッチポートを介してＰＩＦブリッジへ送信される。
他の実施形態において、ＭＦＥは、ワークロードアプリケーションが接続する内部インタフェース（例えば、統合ブリッジ上）が外部インタフェース（ＰＩＦブリッジ上）と異なるＩＰアドレスを有するように構成される。この場合、ＭＦＥ（例えば、統合ブリッジ）は、何らかのネットワークセキュリティ又は他の処理に加えて、論理ネットワーク構成に従ってパケット転送を実行する。パケットは、ワークロードＤＣＮが接続する論理スイッチポートにマッピングされる第１の内部ＩＰアドレスを使用してワークロードアプリケーションにより送信され、その後、クラウドプロバイダにより割り当てられたＩＰアドレス（すなわち、ＶＮＩＣのＩＰアドレス）を使用してカプセル化される。いくつかの実施形態において、統合ブリッジはカプセル化を実行し、第２のネットワークスタックを介してＰＩＦブリッジ上のＶＴＥＰへパケットを送信する。
最後に、ネットワーク管理者は、既存のワークロードに対して同じＩＰアドレスを保持したいが、パケット処理、トンネリング等のために論理ネットワークを利用したい場合がある。この第３の場合では、ＭＦＥはアプリケーションとは別個のワークロードＶＭの名前空間内に構成される。これにより、ワークロードアプリケーションは、既存のＩＰアドレスを有する名前空間のインタフェースに接続し、次にｖｅｔｈペアを使用して、当該ＶＴＥＰに同じＩＰアドレスを使用する別個の名前空間内のＭＦＥに当該インタフェースを接続できる。いくつかの実施形態において、ワークロードアプリケーションとＭＦＥとに別個の名前空間を使用することにより、別個のネットワークスタックが同じＩＰアドレスを使用できる。
上述したオーバーレイカプセル化の使用は、主に、パブリッククラウドＶＰＣ内のワークロードＤＣＮ間のイースト／ウエストトラフィックに対して行われる。しかし、多くの論理ネットワークは、外部クライアントがアクセスできる必要のあるワークロードを含む。例えば、一般的な３層（ウェブサーバ、アプリケーションサーバ、データベースサーバ）設定では、少なくともウェブサーバがインターネットを介してクライアントに接続できる必要がある。通常、ＶＰＣサブネットは、異なるテナントの多くのＶＰＣにより再利用され（且つ種々の異なるデータセンタにおいて再利用され）てもよいプライベートＩＰアドレスであるため、発信パケットの送信元ＩＰアドレス（及び、それに対応して着信パケットの宛先ＩＰアドレス）を内部使用されるプライベートＩＰアドレスからパブリックＩＰアドレスに変更するために、ネットワークアドレス変換（ＮＡＴ）が一般に使用される。
更に、論理ネットワークがパブリックデータセンタ内で少なくとも部分的に実現される場合、パブリックＩＰアドレスへの実際の変換は、ネットワーク制御システムにより管理される何れかのＭＦＥではなく、クラウドプロバイダのインターネットゲートウェイにより実行される必要がある場合がある。しかし、クラウドプロバイダはオーバーレイモードで使用される内部ＩＰアドレスを割り当てていないため、パケットはこれらの内部アドレスを使用してプロバイダのゲートウェイへ送信されるべきでない。その代わりに、いくつかの実施形態のＭＦＥは、内部ＩＰアドレスをクラウドプロバイダに登録されているアドレスに変換するために独自のＮＡＴを実行する。
異なる実施形態は、このアドレス変換を異なる方法で実現してもよい。いくつかの実施形態は、ゲートウェイデータパスの一部としてＮＡＴを適用する。この場合、ノースバウンドパケットは送信元ＭＦＥからゲートウェイにトンネリングされ、そこでＩＰアドレスは一貫した方法で２次ＩＰアドレスに変換される。いくつかの実施形態は、各内部ワークロードＩＰアドレスをクラウドプロバイダに登録されている２次ＩＰアドレスにマッピングするＮＡＴテーブルを使用する。その後、これらの２次ＩＰアドレスは全て、ゲートウェイのノースバウンドインタフェースに関連付けられ、クラウドプロバイダのゲートウェイはこれらの２次ＩＰアドレスからパブリックＩＰアドレスへの変換を実行する。集中型の場合、サービスチェイニング（種々のミドルボックス処理のための第３者サービスアプライアンスへのパケットの送信）、侵入検出、ノース／サウスファイアウォール、ＶＰＮ、監査ロギング等の他のネットワークサービスがゲートウェイで更に適用されてもよい。更に、ゲートウェイがＮＡＴを実行する場合、何らかの負荷分散がゲートウェイにおいて更に実行される必要がある（この場合、プロバイダのゲートウェイが関係する限り、全てのトラフィックがゲートウェイインタフェースへ送信されるため、クラウドプロバイダが負荷分散を実行できない場合がある）。
他の実施形態は、送信元ＤＣＮ（着信トラフィックの場合は宛先ＤＣＮ）上で動作するＭＦＥにおいて、第１のレベルのＮＡＴを分散して実行する。この場合、発信パケットに対して、送信元ＤＣＮのＭＦＥはアドレス変換を実行し、変換されたパケットをゲートウェイを経由せずにクラウドプロバイダゲートウェイへ直接送信する。そのため、送信元ＭＦＥは、自身のＶＴＥＰ ＩＰを使用してカプセル化するオーバーレイトラフィックと、カプセル化せずにクラウドプロバイダアンダーレイネットワークへ送信する（いくつかの実施形態において、ＶＴＥＰと同じＩＰアドレスを使用して）ノース／サウストラフィックとを区別する。このトラフィックは（両方向で）ゲートウェイを通過しないため、何らかのサービスチェイニンング、侵入検出、ノース／サウスファイアウォール規則、ロギング等はワークロードＶＭ上で動作するＭＦＥにおいて実行される。
負荷分散のために、分散型内部ＮＡＴはクラウドプロバイダの既存の負荷分散特徴を使用できるようにする。複数のパブリックＩＰアドレスを使用する代わりに、単一のパブリックＩＰアドレス（又は少数のアドレスのみ）を使用することができ、全ての着信接続は当該アドレスへ送信される。クラウドプロバイダのインターネットゲートウェイ（又は特別な負荷分散アプライアンス）は負荷分散を実行し、これらの接続を異なるワークロードＶＭ（依然として独自の内部ＮＡＴを実行する必要がある）に均等に分散する。
論理ネットワークワークロード間で送信されるパケットに対して、いくつかの実施形態は、ネットワーク制御システムにより管理される分散型ネットワーク暗号化（ＤＮＥ）を使用することを可能にする。いくつかの実施形態において、パブリックデータセンタ内のＤＣＮに対するＤＮＥは同じＶＰＣ内又はピア接続されたＶＰＣ内で動作するＤＣＮ間でのみ可能であるが、他の実施形態において、ＤＮＥは論理ネットワークの論理ポートに接続されたいずれか２つのＤＣＮ間で可能である（ワークロードＤＣＮとゲートウェイとの間を含む）。
いくつかの実施形態において、分散型ネットワーク暗号化は、ネットワーク制御システム管理者がパケットに対する暗号化規則及び／又は整合性規則を設定できるようにする。これらの規則は、（ｉ）規則が適用されるパケットと、（ｉｉ）それらのパケットに対する暗号化要件及び／又は整合性要件とを定義する。いくつかの実施形態は、規則が適用されるパケットをパケットの送信元及び宛先に関して定義する。これらの送信元エンドポイント及び宛先エンドポイントは、ＩＰアドレス又はアドレスの範囲、ＭＡＣアドレス、論理スイッチポート、仮想インタフェース、Ｌ４ポート番号及びその範囲等、並びにそれらの組み合わせに基づいて定義されてもよい。
更に、各規則は、送信元及び宛先の特徴に合致するパケットが暗号化（認証を伴う）を必要とするか、認証のみを必要とするか、あるいはプレーンテキスト（ブロードキャストパケットを許可するための設定として使用されてもよい）を必要とするかを指定する。暗号化は、パケットの一部分又は全部（例えば、内部パケット全体、Ｌ４以上のヘッダのみ、トンネリングされるパケットの場合の内部／外部パケット全体等）を暗号化するために鍵を使用する必要があるが、認証はパケットを暗号化せず、送信中にパケットが改竄されていないことを検証するために宛先が使用できる認証データを作成するために鍵を使用する。
ネットワーク内のＭＦＥにＤＮＥ規則を実現させるために、ネットワーク制御システムはＭＦＥに鍵をセキュアに配布する必要がある。いくつかの実施形態は、ネットワーク制御システムのＤＮＥ態様と通信し且つそのＶＰＣ内のワークロードＤＣＮ内で動作するＭＦＥに鍵を配布するために、ゲートウェイＤＣＮ内のＤＮＥモジュールを使用する。暗号鍵の使用を必要とする規則毎に、ＤＮＥモジュールは中央制御器から鍵に対するチケットを受信する。ＤＮＥモジュールはチケットを使用してセキュア鍵管理記憶装置に鍵を要求する。これは、チケットが本物であることを検証して、マスタ鍵を返す。いくつかの実施形態のＤＮＥモジュールは、規則により指定された接続毎にセッション鍵を計算し（例えば、ＶＰＣ内の２つのワークロード間の単一の接続、ＶＰＣ内の複数の接続、ワークロードとゲートウェイとの間の接続等）、これらの鍵を適切なローカル制御エージェントに配布する。
前述の「発明の概要」は、本発明のいくつかの実施形態の簡単な紹介として用いられることを意図する。それは、本明細書において開示される全ての発明の主題の紹介又は概説であることを意味しない。以下の「発明を実施するための形態」及び「発明を実施するための形態」において参照される図面は、「発明の概要」で説明した実施形態及び他の実施形態を更に説明する。従って、本明細書で説明する全ての実施形態を理解するために、「発明の概要」、「発明を実施するための形態」及び図面を全体的に検討することが必要である。更に、特許請求される主題は主題の主旨から逸脱することなく他の特定の形態で実施可能であるため、特許請求される主題は、「発明の概要」、「発明を実施するための形態」及び図面における例示的な詳細により限定されるべきでなく、添付の請求項により定義されるべきである。
本発明の新規の特徴は添付の請求項に記載される。しかし、説明のために、本発明のいくつかの実施形態を以下の図面に記載する。
図１は、プライベートデータセンタ及びパブリックデータセンタの双方の転送要素を管理するいくつかの実施形態の階層型ネットワーク制御システムを概念的に示す図である。 図２は、図１のネットワーク制御システムを通る制御データの流れを概念的に示す図である。 図３は、プライベートデータセンタ及びパブリックデータセンタの双方に位置する被管理転送要素に構成データを配布するいくつかの実施形態の処理を概念的に示す図である。 図４は、ＶＰＣ内のＭＦＥに論理ネットワーク構成データを配布するためのいくつかの実施形態の処理を概念的に示す図である。 図５は、パブリックデータセンタ内で完全に実現される論理ネットワークに対するネットワーク制御システムの一例を概念的に示す図である。 図６は、論理ネットワークを複数のパブリックデータセンタに拡張するいくつかの実施形態のネットワーク制御システムを概念的に示す図である。 図７は、いくつかの実施形態のゲートウェイＶＭのアーキテクチャを概念的に示す図である。 図８は、プライベートデータセンタを管理するネットワーク制御システムをパブリックデータセンタの１つ以上のＶＰＣに初期拡張するいくつかの実施形態の処理を概念的に示す図である。 図９は、管理プレーン及び制御プレーンにゲートウェイを認定させるためのいくつかの実施形態の処理を概念的に示す図である。 図１０は、パブリッククラウドＶＰＣ内のＤＣＮ上で動作するローカル制御エージェントが当該ＶＰＣに対するゲートウェイ制御器に自身を認定させるために実行するいくつかの実施形態の処理を概念的に示す図である。 図１１は、新規のワークロードＶＭが既存の被管理ＶＰＣ内に作成される場合のいくつかの実施形態のネットワーク制御システムにおけるデータの流れを概念的に示す図である。 図１２は、管理者が管理プレーンに論理トポロジを入力してもよい場合のいくつかの実施形態の論理トポロジを概念的に示す図である。 図１３は、単一のパブリッククラウドプロバイダの単一のＶＰＣ内に実現される場合の論理スイッチに接続された４つのＶＭの一例を示す図である。 図１４は、論理スイッチが単一のデータセンタ内の（すなわち、同じクラウドプロバイダの）２つの別個のＶＰＣにまたがる一例を示す図である。 図１５は、論理スイッチが２つの全く異なるクラウドプロバイダのデータセンタに位置するＶＰＣにまたがる一例を示す図である。 図１６は、非オーバーレイモードで構成された被管理転送要素を有するＶＭを概念的に示す図である。 図１７は、非オーバーレイモードで動作するＭＦＥによるＶＰＣを介するパケット処理の一例を示し、同じＶＰＣ上の別のワークロードアプリケーションへパケットを送信する第１のワークロードアプリケーションを示す図である。 図１８は、（ｉ）アプリケーションにより使用される内部ポートと（ｉｉ）同じＶＰＣ上の他のＶＭへ送信されるパケットをカプセル化するＶＴＥＰとに対して異なるＩＰアドレスを有するオーバーレイモードで構成された被管理転送要素を有するＶＭを概念的に示す図である。 図１９は、オーバーレイモードで動作するＭＦＥによるＶＰＣを介するパケット処理の一例を示し、詳細には、同じＶＰＣ上の別のワークロードアプリケーションへパケットを送信する第１のワークロードアプリケーションを示す図である。 図２０は、ＶＰＣ外部の論理ネットワーク宛先へ送信されるパケットに対するオーバーレイモードのＭＦＥによるＶＰＣを介するパケット処理の一例を示す図である。 図２１は、オーバーレイモードで構成されるが同じＩＰアドレスを内部ポートに使用する被管理転送要素を有するＶＭを概念的に示す図である。 図２２は、ワークロードアプリケーションから論理ネットワーク外部の宛先へ送信されるノースバウンドパケットに対するクラウドプロバイダネットワークを介するパケット処理の一例を概念的に示す図である。 図２３は、着信パケットが外部送信元からテナントのＶＰＣに関連付けられたパブリックＩＰアドレスのうちの１つへ送信される場合のパブリッククラウドゲートウェイ内の処理を示す図である。 図２４は、図２２のワークロードアプリケーションと同じＶＰＣ上の異なるワークロードアプリケーションから送信されるパケットに対する図２２のクラウドプロバイダネットワークを介するパケット処理を示す図である。 図２５は、異なるＩＰアドレスを用いてオーバーレイモードで構成され、ノース／サウストラフィックに対するＮＡＴを更に実行する被管理転送要素を有するＶＭを概念的に示す図である。 、 図２６及び図２７は、分散型ＮＡＴ設定におけるノースバウンド及びサウスバウンドに対するクラウドプロバイダネットワークを介するパケット処理の例を示す図である。 図２８は、ワークロードＶＭ上のＭＦＥがオーバーレイモードで動作し且つ分散型ＮＡＴを実行するように構成される場合に、発信パケットを処理するためにＭＦＥにより実行される処理を概念的に示す図である。 図２９は、ワークロードＶＭ内で動作するＭＦＥによる分散型ＮＡＴと共にパブリッククラウドゲートウェイにおける負荷分散の使用を示す図である。 図３０は、いくつかの実施形態のＤＮＥ規則／鍵配布システムと、パブリックデータセンタ内のＭＦＥ上でＤＮＥ規則を実現するためのデータの流れとを概念的に示す図である。 図３１は、パブリックデータセンタＶＰＣのゲートウェイにおいてＤＮＥ鍵を管理するためのいくつかの実施形態の処理を概念的に示す図である。 図３２は、不正アクセスされたＶＭを処理するためにＰＣＭにより実行されるいくつかの実施形態の処理を概念的に示す図である。 、 図３３及び図３４は、パブリックデータセンタＶＰＣ内の不正アクセスされたＶＭを識別するゲートウェイ制御器と、不正アクセスされたＶＭをパブリックデータセンタプロバイダと共に隔離するＰＣＭとの例を示す図である。 図３５は、本発明のいくつかの実施形態が実現される電子システムを概念的に示す図である。
以下の本発明の詳細な説明において、本発明の多くの詳細、例及び実施形態が記載され且つ説明される。しかし、本発明は記載される実施形態に限定されず、本発明は説明される特定の詳細及び例のうちのいくつかを用いずに実施されてもよいことが理解されるべきである。
本発明のいくつかの実施形態は、（ｉ）ネットワーク管理／制御システムが転送要素にアクセス及び制御できるプライベートデータセンタと、（ｉｉ）システムが転送要素にアクセスできない１つ以上のパブリックマルチテナントデータセンタとにまたがる論理ネットワークを管理する機能を有するネットワーク管理／制御システムを提供する。いくつかの実施形態のプライベートデータセンタでは、ネットワーク管理／制御システム（本明細書中、ネットワーク制御システムと呼ぶ）は、ホストマシンの仮想化ソフトウェア（例えば、ハイパーバイザ）内で実行するソフトウェア転送要素を管理し、従って、管理者の所望のネットワーク転送ポリシー及びセキュリティポリシーを実現できる。しかし、パブリックデータセンタでは、ネットワーク制御システムは仮想化ソフトウェアにアクセスできず、従って、パブリックデータセンタ内で動作するワークロードに対して同一のネットワークポリシーを実現できない場合がある。
いくつかの実施形態は、プライベートデータセンタの管理及び制御をパブリックデータセンタに拡張するために階層型ネットワーク制御システムを使用する。詳細には、いくつかの実施形態は、データ計算ノード（ＤＣＮ）との間で送受信されるパケットに対するネットワークセキュリティ規則及び転送規則を実施するために、パブリックデータセンタ内で動作する仮想マシン（ＶＭ）又は他のＤＣＮ内のネットワーク制御器及び被管理転送要素を動作させる。いくつかの実施形態において、パブリックデータセンタは、テナントが制御できる１つ以上の隔離されたリソース（すなわち、データ計算ノード）セットをテナントに提供する。これを仮想プライベートクラウド（ＶＰＣ）とも呼ぶ。一部のクラウドプロバイダでは、テナントはネットワークサブネット及びルーティングテーブルを用いて仮想ネットワークを定義すること及び／又はパブリッククラウドプロバイダにより定義されたセキュリティグループに自身のＤＣＮを入れることが可能である。
階層型ネットワーク制御システムを実現するために、いくつかの実施形態は、各ＶＰＣ内の第１のＤＣＮ（又は、各ＶＰＣ内のアクティブ／スタンバイゲートウェイ制御器としてのＤＣＮのセット）において第１のレベルのネットワーク制御器（ゲートウェイ制御器と呼ぶ）を実現する。また、これらのゲートウェイＤＣＮは、いくつかの実施形態において、同じデータセンタの他のＶＰＣ又は他のデータセンタ（プライベートデータセンタ又は別のパブリックデータセンタ）内の論理ネットワークとの通信及び外部ネットワークと通信のためにゲートウェイデータパスを動作させる。各ワークロードＤＣＮ（すなわち、ウェブサーバ、アプリケーションサーバ、データベースサーバ等のワークロードアプリケーションを実行するＤＣＮ）内で、被管理転送要素（ＭＦＥ）がワークロードアプリケーションとＤＣＮのネットワークインタフェースとの間のデータパスに挿入される。更に、各ＭＦＥを構成するために、ローカル制御エージェントが各ワークロードＤＣＮ上で実行する。
プライベートデータセンタ（又は、別個のＶＰＣ）内で動作する中央制御プレーンクラスタは、構成規則の範囲に基づいて、プライベートデータセンタ内のホストマシン上で動作するローカル制御器に（すなわち、規則の種類及び規則が適用される論理ポートに基づいて、規則を実施する必要があるＭＦＥに）構成規則を配布する。パブリックデータセンタＶＰＣ内で動作する制御システムに当該規則を配布する場合、中央制御器は、ＶＰＣ内のＤＣＮに対応する全ての論理ポートがゲートウェイ制御器により制御されるＭＦＥに接続されていると見なす。そのため、当該規則は全て、中央制御器によりゲートウェイ制御器に出力される。
次に、ゲートウェイ制御器は、中央制御器から受信した各規則を必要とするＶＰＣ内のＭＦＥを識別するために、独自の別個の適用範囲の計算を行い、ＭＦＥを制御するように動作するローカル制御エージェントに当該規則を配布する。ローカル制御エージェントは、規則を受信すると、ＤＣＮで動作するＭＦＥに特有のフォーマットに規則を変換する。例えばいくつかの実施形態は、パブリックデータセンタＶＰＣ内のＤＣＮ上で実行するＯｐｅｎ ｖＳｗｉｔｃｈ（ＯＶＳ）インスタンス等のフローベースＭＦＥを使用し、その場合、ローカル制御エージェントは、ＯＶＳインスタンスに対するフローエントリ及び／又は他の構成データに規則を変換する。
いくつかの実施形態において、ゲートウェイ制御器は、ＶＰＣ内のオーバーレイトンネルを管理する責任も有する。中央制御器は、ＶＰＣ全体を単一のＭＦＥと見なすため、ゲートウェイ制御器ノードに対するトンネルエンドポイント（すなわち、ゲートウェイＤＣＮ上に構成されたデータパス）のみを構成する。しかし、ＶＰＣ内のワークロードアプリケーション間（及びワークロードアプリケーションとゲートウェイデータパスとの間）の通信に対して、中央制御器はオーバーレイを構成しない。そのため、ゲートウェイ制御器は、ＭＦＥ毎にＭＡＣから仮想トンネルエンドポイント（ＶＴＥＰ）へのＩＰバインディングを構成することにより、これらのＤＣＮの間にトンネル（例えば、ＳＴＴ、ＧＥＮＥＶＥ等のトンネル）を設定する。当該情報はワークロードＤＣＮ上の種々のローカル制御エージェントにも渡されるため、各ＭＦＥは同じＶＰＣ内の他のＭＦＥにパケットをトンネリングすることができる。
上述したように、ゲートウェイＤＣＮはゲートウェイ制御器とデータパスとを含む。いくつかの実施形態において、データパスは、（ｉ）他のＶＰＣ及び他のデータセンタ内で動作し且つ論理ネットワークに接続されたワークロード及び（ｉｉ）外部ネットワークに自身のＶＰＣ内のワークロードを接続するゲートウェイとして動作する。いくつかの実施形態において、ゲートウェイＤＣＮは、３つのネットワークインタフェース、すなわち、外部ネットワークとの間で（クラウドプロバイダインターネットゲートウェイを介して）パケットを送受信するアップリンクインタフェースと、ローカルＶＰＣサブネット上のアドレスを有するＶＴＥＰインタフェースと、制御トラフィック専用の制御インタフェースとを含む。データパス及びゲートウェイ制御器に加えて、いくつかの実施形態は、ＶＰＣ内のＭＦＥ（場合によっては、ゲートウェイデータパスを含む）によるトラフィックをセキュリティ保護するために使用される暗号鍵を処理するための分散型ネットワーク暗号化（ＤＮＥ）マネージャと、ＶＰＣ内のＤＨＣＰを処理するためのＤＨＣＰモジュールと、管理プレーン及びゲートウェイ制御器がパブリッククラウド管理システムと対話できるようにするパブリッククラウドマネージャ（ＰＣＭ）とを含んでもよい。
例えばＰＣＭは、パブリッククラウドマネージャをポーリングして、ＤＣＮが属することになる論理スイッチ及び／又はセキュリティグループを示すＤＣＮに関連するタグを含めて新しいＤＣＮを識別する機能を有する。更に、いくつかの実施形態のＰＣＭは、パブリッククラウド管理システムと対話して、ＤＣＮが不正アクセスされたという通知を受信した場合にＤＣＮを隔離できる。例えば、ＭＦＥを実行するＤＣＮへのアクセスをハッカーが取得した場合、ハッカーは、（ｉ）ローカル制御エージェント及び／又はＭＦＥをアンインストールするか、（ｉｉ）ＭＦＥを介してトラフィックを送信しない新しいインタフェースを作成するか、（ｉｉｉ）既存のインタフェースをＭＦＥから切断するか、又は（ｉｖ）ＭＦＥをローカル制御エージェントから切断することによりＭＦＥを直接リプログラミングすることができる。インタフェースが編集された場合又は制御エージェントがＭＦＥから切断された場合、エージェントは変更を検出し、ゲート制御器に問題を通知する。エージェント自体が削除された場合、ゲートウェイ制御器はエージェントへの接続が失われたことを検出し、ＤＣＮが不正アクセスされたことを識別する。いずれの場合も、ゲートウェイ制御器は不正アクセスされたＤＣＮをＰＣＭに通知する。ＰＣＭは、不正アクセスされたＤＣＮを隔離セキュリティグループに入れるためにパブリッククラウド管理システムと対話する機能を有し、それにより（例えば、ホストマシンのハイパーバイザ内の）パブリッククラウド転送要素は不正アクセスされたＤＣＮからのトラフィックを遮断できる。
階層型ネットワーク制御システムは、プライベートデータセンタからパブリックデータセンタにまたがる論理ネットワークの実現を可能にする。異なる実施形態において、異なる論理トポロジがデータセンタにまたがり異なる方法で実現されてもよい。例えばいくつかの実施形態は、所定の論理スイッチに接続されたＤＣＮをプライベートデータセンタ内の単一のＶＰＣに制限するか又は単一のＶＰＣと同様に動作するためにピア接続される同じデータセンタ内の複数のＶＰＣに制限する（当該論理スイッチは、論理ルータを介して、別のＶＰＣ又は別のデータセンタ内で実現される論理スイッチに論理的に接続されてもよい）。他の実施形態において、単一の論理スイッチは、同じパブリックデータセンタの複数のピア接続されていないＶＰＣ内のＤＣＮ、複数のパブリックデータセンタの複数のＶＰＣ内のＤＣＮ、並びに／又はパブリックデータセンタとプライベートデータセンタの双方のＤＣＮを有してもよい。
以上、ＶＰＣへの制御プレーンの拡張及び当該拡張を可能にするゲートウェイ制御器を説明したが、いくつかの実施形態において、ＶＰＣ内のこれらの種々の構成要素は初期構成され且つ管理プレーン及び中央制御プレーンと共に搭載される必要がある。いくつかの実施形態において、パブリッククラウドにおけるネットワーク及び制御システムの初期設定は運用マネージャ（ライフサイクルマネージャ又はＬＣＭとも呼ばれる）により管理される。ネットワーク管理者は、ネットワーク管理者のパブリッククラウド資格情報を使用する当該ＬＣＭと対話して（例えば、ユーザインタフェースを介して）ＬＣＭにアクセスし、ＶＰＣ内の種々のＶＭを初期構成する。
ＬＣＭは、管理者が論理ネットワークを実現したい各ＶＰＣを識別し、これらのＶＰＣの各々においてゲートウェイＤＣＮ（又はアクティブ／スタンバイゲートウェイＤＣＮセット）を自動的にインスタンス化する。いくつかの実施形態において、ゲートウェイＤＣＮは、特定のパブリッククラウドプロバイダ用にフォーマットされたプリパッケージインスタンスとして提供される。更に、いくつかの実施形態のＬＣＭは、ネットワーク制御システムにより管理される必要があるＶＰＣ内の既存のＤＣＮに関する情報を管理者から受信し、それらのＤＣＮに関する論理スイッチ及びセキュリティグループ情報を管理プレーンに提供する。
初期構成の一部として、ゲートウェイ制御器は管理プレーンに認定され（且つ管理プレーンアプリケーションが有効であることを検証し）、ゲートウェイ制御器が対話する中央制御器アプリケーションに同様に認定される必要がある。更に、ワークロードＤＣＮのうちの１つにおいて動作する各ローカル制御エージェントは、構成規則を配布する場合と同様の階層的方法でゲートウェイ制御器に自身を検証させる。
上記の段落における説明は、制御器が動作するＶＭが既に存在すると仮定する。場合によっては、ユーザ（例えば、非管理者ユーザ）は、パブリックデータセンタＶＰＣ内に新規のワークロードＤＣＮを作成し、正確な構成規則セットがＤＣＮ上のＭＦＥに提供されることを保証する必要がある。これはいつでも生じ得るため、従って、理想的には、その時点でネットワーク管理者による作業又は認可を必要としないようにするべきである。そのため、いくつかの実施形態において、ネットワーク制御システムは、これらの新規のワークロードＤＣＮのＭＦＥを自動的に提供するように構成される。
ＤＣＮを起動する前に、ユーザは、ワークロードが接続することになる論理スイッチ（及び／又はセキュリティグループ）に対するトークンと、インスタンスにインストールする制御エージェントパッケージとを管理者から受け取る。ＤＣＮを設定する際、ユーザは、論理スイッチ及び／又はセキュリティグループに対するトークンをインスタンスのラベルとして追加する。いくつかの実施形態において、ユーザがクラウドプロバイダユーザインタフェースを介してインスタンスを作成する場合、インタフェースは、ＶＭインスタンスに関するデータとしてパブリッククラウドデータリポジトリに格納されているタグをＶＭに追加する機能を含む。例えばタグは、ＶＭがセキュリティグループＳＧ１に属し且つ論理スイッチＬＳ１に接続する必要があることを示すために、「ｔｏｋｅｎ‐ｌｓ１」及び「ｔｏｋｅｎ‐ｓｇ１」というラベルが付けられてもよい。これらのタグは、何らかのアウトオブバンド機構を介して（例えば、口頭で、電子メール又はメッセージ送信等で）ネットワーク制御システム管理者からユーザに提供されてもよい。
いくつかの実施形態のＰＣＭは、当該データリポジトリを定期的にポーリングして、そのＶＰＣ内に作成された何らかの新規のＤＣＮを識別する。新規のＤＣＮがＶＰＣ内に作成されたという判定に応答して、ＰＣＭはいくつかの動作を実行する。ＰＣＭは、管理プレーンのインベントリに新規のＤＣＮを追加し、ＤＣＮに対する管理プレーン内に作成されたオブジェクトにＤＣＮの種々のパブリッククラウドプロバイダ属性（ＶＭ識別子、ＶＰＣ識別子、インタフェースＩＤ等）の全てをタグとして追加する。これにより、ネットワーク管理者はＤＣＮ及びその属性を管理プレーンインベントリで閲覧できる。また、ＰＣＭは、クラウドプロバイダＡＰＩを使用して論理スイッチ及び／又はセキュリティグループのタグを読み出す。ＰＣＭは論理スイッチタグを使用して、新規のポートを作成する論理スイッチを判定する。ＰＣＭは新規のポートを作成し、ＤＣＮのインタフェースを当該論理ポートに接続する（例えば、クラウドプロバイダからのインタフェース識別子を使用して）。更にＰＣＭは、インタフェースのＩＰアドレス及びＭＡＣアドレスを読み出し、これらを新規に作成された論理ポート上のＭＡＣ／ＩＰバインディングとして構成する。また、いくつかの実施形態は、要望に応じて、論理ポートに対してＤＦＷ規則を設定できるように、何らかの必要な特徴を有効にする。更に、ＰＣＭはセキュリティグループタグに基づいて新規のＤＣＮのセキュリティグループを識別し、管理プレーンを介して当該セキュリティグループに論理ポートを追加する。
上述したように、いくつかの実施形態のＭＦＥはＯＶＳインスタンス等のフローベースＭＦＥである。異なる実施形態において、これらのＯＶＳインスタンスは、非オーバーレイモード、別個の内部ＩＰアドレスと外部ＩＰアドレスとを使用する第１のオーバーレイモード又はそのＶＴＥＰ及び内部ワークロードアプリケーションに同じＩＰアドレスを使用する第２のオーバーレイモードのいずれで設定されてもよい。３つの場合の全てにおいて２つのブリッジがＯＶＳインスタンスに設定されるが、３つのオプションに対して３つの異なる方法がある。ワークロードアプリケーションは、ネットワークセキュリティ及び／又は論理転送動作を実行する統合ブリッジの内部ポートに接続する。物理インタフェース（ＰＩＦ）ブリッジは、ＭＦＥが動作するＤＣＮの仮想ネットワークインタフェース制御器（ＶＮＩＣ）に接続する。
いくつかの実施形態の非オーバーレイモードにおいて、ワークロードアプリケーションのＩＰアドレスは、クラウドプロバイダネットワーク（本明細書中、アンダーレイネットワークと呼ぶ）に対するＶＭネットワークインタフェースのＩＰアドレス（クラウドプロバイダにより割り当てられる）と同じである。この場合、ＭＦＥはパケット転送を一切実行せず、その代わりに、マイクロセグメンテーション及び／又は分散型ファイアウォール規則処理等のネットワークセキュリティ処理を実行するように構成される。このネットワークセキュリティ処理は統合ブリッジにより実行され、パケットはデフォルトで２つのブリッジ間のパッチポートを介してＰＩＦブリッジへ送信される。
他の実施形態において、ＭＦＥは、ワークロードアプリケーションが接続する内部インタフェース（例えば、統合ブリッジ上）が外部インタフェース（ＰＩＦブリッジ上）と異なるＩＰアドレスを有するように構成される。この場合、ＭＦＥ（例えば、統合ブリッジ）は、何らかのネットワークセキュリティ又は他の処理に加えて、論理ネットワーク構成に従ってパケット転送を実行する。パケットは、ワークロードＤＣＮが接続する論理スイッチポートにマッピングされる第１の内部ＩＰアドレスを使用してワークロードアプリケーションにより送信され、その後、クラウドプロバイダにより割り当てられたＩＰアドレス（すなわち、ＶＮＩＣのＩＰアドレス）を使用してカプセル化される。いくつかの実施形態において、統合ブリッジはカプセル化を実行し、第２のネットワークスタックを介してＰＩＦブリッジ上のＶＴＥＰへパケットを送信する。
最後に、ネットワーク管理者は、既存のワークロードに対して同じＩＰアドレスを保持したいが、パケット処理、トンネリング等のために論理ネットワークを利用したい場合がある。この第３の場合では、ＭＦＥはアプリケーションとは別個のワークロードＶＭの名前空間内に構成される。これにより、ワークロードアプリケーションは、既存のＩＰアドレスを有する名前空間のインタフェースに接続し、次にｖｅｔｈペアを使用して、当該ＶＴＥＰに同じＩＰアドレスを使用する別個の名前空間内のＭＦＥに当該インタフェースを接続できる。いくつかの実施形態において、ワークロードアプリケーションとＭＦＥとに別個の名前空間を使用することにより、別個のネットワークスタックが同じＩＰアドレスを使用できる。
上述したオーバーレイカプセル化の使用は、主に、パブリッククラウドＶＰＣ内のワークロードＤＣＮ間のイースト／ウエストトラフィックに対して行われる。しかし、多くの論理ネットワークは、外部クライアントがアクセスできる必要のあるワークロードを含む。例えば、一般的な３層（ウェブサーバ、アプリケーションサーバ、データベースサーバ）設定では、少なくともウェブサーバがインターネットを介してクライアントに接続できる必要がある。通常、ＶＰＣサブネットは、異なるテナントの多くのＶＰＣにより再利用され（且つ種々の異なるデータセンタにおいて再利用され）てもよいプライベートＩＰアドレスであるため、発信パケットの送信元ＩＰアドレス（及び、それに対応して着信パケットの宛先ＩＰアドレス）を内部使用されるプライベートＩＰアドレスからパブリックＩＰアドレスに変更するために、ネットワークアドレス変換（ＮＡＴ）が一般に使用される。
更に、論理ネットワークがパブリックデータセンタ内で少なくとも部分的に実現される場合、パブリックＩＰアドレスへの実際の変換は、ネットワーク制御システムにより管理される何れかのＭＦＥではなく、クラウドプロバイダのインターネットゲートウェイにより実行される必要がある場合がある。しかし、クラウドプロバイダはオーバーレイモードで使用される内部ＩＰアドレスを割り当てていないため、パケットはこれらの内部アドレスを使用してプロバイダのゲートウェイへ送信されるべきでない。その代わりに、いくつかの実施形態のＭＦＥは、内部ＩＰアドレスをクラウドプロバイダに登録されているアドレスに変換するために独自のＮＡＴを実行する。
異なる実施形態は、このアドレス変換を異なる方法で実現してもよい。いくつかの実施形態は、ゲートウェイデータパスの一部としてＮＡＴを適用する。この場合、ノースバウンドパケットは送信元ＭＦＥからゲートウェイにトンネリングされ、そこでＩＰアドレスは一貫した方法で２次ＩＰアドレスに変換される。いくつかの実施形態は、各内部ワークロードＩＰアドレスをクラウドプロバイダに登録されている２次ＩＰアドレスにマッピングするＮＡＴテーブルを使用する。その後、これらの２次ＩＰアドレスは全て、ゲートウェイのノースバウンドインタフェースに関連付けられ、クラウドプロバイダのゲートウェイはこれらの２次ＩＰアドレスからパブリックＩＰアドレスへの変換を実行する。集中型の場合、サービスチェイニング（種々のミドルボックス処理のための第３者サービスアプライアンスへのパケットの送信）、侵入検出、ノース／サウスファイアウォール、ＶＰＮ、監査ロギング等の他のネットワークサービスがゲートウェイで更に適用されてもよい。更に、ゲートウェイがＮＡＴを実行する場合、何らかの負荷分散がゲートウェイにおいて更に実行される必要がある（この場合、プロバイダのゲートウェイが関係する限り、全てのトラフィックがゲートウェイインタフェースへ送信されるため、クラウドプロバイダが負荷分散を実行できない場合がある）。
他の実施形態は、送信元ＤＣＮ（着信トラフィックの場合は宛先ＤＣＮ）上で動作するＭＦＥにおいて、第１のレベルのＮＡＴを分散して実行する。この場合、発信パケットに対して、送信元ＤＣＮのＭＦＥはアドレス変換を実行し、変換されたパケットをゲートウェイを経由せずにクラウドプロバイダゲートウェイへ直接送信する。そのため、送信元ＭＦＥは、自身のＶＴＥＰ ＩＰを使用してカプセル化するオーバーレイトラフィックと、カプセル化せずにクラウドプロバイダアンダーレイネットワークへ送信する（いくつかの実施形態において、ＶＴＥＰと同じＩＰアドレスを使用して）ノース／サウストラフィックとを区別する。このトラフィックは（両方向で）ゲートウェイを通過しないため、何らかのサービスチェイニンング、侵入検出、ノース／サウスファイアウォール規則、ロギング等はワークロードＶＭ上で動作するＭＦＥにおいて実行される。
負荷分散のために、分散型内部ＮＡＴはクラウドプロバイダの既存の負荷分散特徴を使用できるようにする。複数のパブリックＩＰアドレスを使用する代わりに、単一のパブリックＩＰアドレス（又は少数のアドレスのみ）を使用することができ、全ての着信接続は当該アドレスへ送信される。クラウドプロバイダのインターネットゲートウェイ（又は特別な負荷分散アプライアンス）は負荷分散を実行し、これらの接続を異なるワークロードＶＭ（依然として独自の内部ＮＡＴを実行する必要がある）に均等に分散する。
論理ネットワークワークロード間で送信されるパケットに対して、いくつかの実施形態は、ネットワーク制御システムにより管理される分散型ネットワーク暗号化（ＤＮＥ）を使用することを可能にする。いくつかの実施形態において、パブリックデータセンタ内のＤＣＮに対するＤＮＥは同じＶＰＣ内又はピア接続されたＶＰＣ内で動作するＤＣＮ間でのみ可能であるが、他の実施形態において、ＤＮＥは論理ネットワークの論理ポートに接続されたいずれか２つのＤＣＮ間で可能である（ワークロードＤＣＮとゲートウェイとの間を含む）。
いくつかの実施形態において、分散型ネットワーク暗号化は、ネットワーク制御システム管理者がパケットに対する暗号化規則及び／又は整合性規則を設定できるようにする。これらの規則は、（ｉ）規則が適用されるパケットと、（ｉｉ）それらのパケットに対する暗号化要件及び／又は整合性要件とを定義する。いくつかの実施形態は、規則が適用されるパケットをパケットの送信元及び宛先に関して定義する。これらの送信元エンドポイント及び宛先エンドポイントは、ＩＰアドレス又はアドレスの範囲、ＭＡＣアドレス、論理スイッチポート、仮想インタフェース、Ｌ４ポート番号及びその範囲等、並びにそれらの組み合わせに基づいて定義されてもよい。
更に、各規則は、送信元及び宛先の特徴に合致するパケットが暗号化（認証を伴う）を必要とするか、認証のみを必要とするか、あるいはプレーンテキスト（ブロードキャストパケットを許可するための設定として使用されてもよい）を必要とするかを指定する。暗号化は、パケットの一部分又は全部（例えば、内部パケット全体、Ｌ４以上のヘッダのみ、トンネリングされるパケットの場合の内部／外部パケット全体等）を暗号化するために鍵を使用する必要があるが、認証はパケットを暗号化せず、送信中にパケットが改竄されていないことを検証するために宛先が使用できる認証データを作成するために鍵を使用する。
ネットワーク内のＭＦＥにＤＮＥ規則を実現させるために、ネットワーク制御システムはＭＦＥに鍵をセキュアに配布する必要がある。いくつかの実施形態は、ネットワーク制御システムのＤＮＥ態様と通信し且つそのＶＰＣ内のワークロードＤＣＮ内で動作するＭＦＥに鍵を配布するために、ゲートウェイＤＣＮ内のＤＮＥモジュールを使用する。暗号鍵の使用を必要とする規則毎に、ＤＮＥモジュールは中央制御器から鍵に対するチケットを受信する。ＤＮＥモジュールはチケットを使用してセキュア鍵管理記憶装置に鍵を要求する。これは、チケットが本物であることを検証して、マスタ鍵を返す。いくつかの実施形態のＤＮＥモジュールは、規則により指定された接続毎にセッション鍵を計算し（例えば、ＶＰＣ内の２つのワークロード間の単一の接続、ＶＰＣ内の複数の接続、ワークロードとゲートウェイとの間の接続等）、これらの鍵を適切なローカル制御エージェントに配布する。
以上、いくつかの実施形態のネットワーク管理／制御システムを説明した。以下の節では、システムのパブリックデータセンタへの拡張の様々な態様を更に詳細に説明する。第Ｉ節では、いくつかの実施形態の階層型ネットワーク制御システムを説明し、第ＩＩ節では、ゲートウェイＤＣＮのアーキテクチャを説明する。次に、第ＩＩＩ節では、パブリッククラウドＶＰＣの初期構成を説明する。第ＶＩ節では、論理トポロジの様々な物理的実現例、複数のＶＰＣ及び／又はデータセンタにまたがるトポロジの拡張を説明する。第Ｖ節では、ワークロードＤＣＮ内で動作するＭＦＥの様々な構成を説明し、第ＶＩ節では、集中型及び分散型の双方でのＮＡＴ及び他のサービスの提供を説明する。次に、第ＶＩＩ節では、パブリックデータセンタにおける分散型ネットワーク暗号化の実現を説明し、第ＶＩＩＩ節では、脅威の検出及び処理を説明する。最後に、第ＩＸ節では、本発明のいくつかの実施形態が実現される電子システムを説明する。
Ｉ． 階層型ネットワーク制御システム
上述したように、いくつかの実施形態は、プライベートデータセンタの管理をＡｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ等のパブリックマルチテナントデータセンタ（「パブリッククラウド」）に拡張するために階層型ネットワーク制御システムを使用する。図１は、プライベートデータセンタ１０５及びパブリックデータセンタ１１０の双方の転送要素を管理するいくつかの実施形態のそのような階層型ネットワーク制御システム１００を概念的に示す。データセンタ１０５及び１１０の双方は、仮想マシン（ＶＭ）又は他のデータ計算ノード（ＤＣＮ）をホストするためのホストマシンを含む。プライベートデータセンタ１０５において、ネットワーク制御システムは、ハイパーバイザ（仮想化ソフトウェア）及びそれらのハイパーバイザと統合される転送要素を管理する機能を有する。しかし、パブリックデータセンタ１１０において、ハイパーバイザはデータセンタの所有者により制御されるため、ネットワーク制御システムはハイパーバイザにアクセスできない。
示されるように、プライベートデータセンタ内のネットワーク制御システムは、管理プレーン／中央制御プレーン（ＭＰ／ＣＣＰ）クラスタ１１５と、多くのホストマシン１２５の各々におけるローカル制御器１２０とを含む。ローカル制御器１２０は、ホストマシン上の被管理転送要素（ＭＦＥ）セット１３０を直接制御する。示されるように、ホストマシン上のＶＭ（又は他のデータ計算ノード）は、データトラフィックを送受信するためにＭＦＥセット１３０に接続する（例えば、仮想ネットワークインタフェース制御器（ＶＮＩＣ）を介して）。ネットワーク制御システムを介して受信した転送／構成データに基づいて、ＭＦＥセット１３０は、これらのＶＭとの間で送受信されるデータパケットに対して転送動作及びネットワークセキュリティ（例えば、分散型ファイアウォール（ＤＦＷ）規則、アクセス制御リスト（ＡＣＬ）規則等）動作を実行する。ＭＦＥセットは、いくつかの実施形態では単一の被管理転送要素（例えば、Ｌ２、Ｌ３及び更なる処理を実行する単一の仮想スイッチ）であってもよく、あるいは種々の被管理転送要素及びセキュリティ要素の組み合わせ（例えば、全てが仮想化ソフトウェア内で動作するフィルタ、Ｌ２スイッチ、Ｌ３ルータ等のセット）であってもよい。
本明細書で説明するように、ＭＰ／ＣＣＰクラスタ１１５は、異なる特徴を有する管理プレーン（ＭＰ）と中央制御プレーン（ＣＣＰ）とを含む。いくつかのそのような実施形態において、ＭＰ及びＣＣＰは、同じ物理マシン又は異なる物理マシン上で動作してもよい別個のアプリケーションである。更に、いくつかの実施形態のＭＰ／ＣＣＰクラスタ１１５は、単一の管理プレーンアプリケーション及び単一の中央制御プレーンアプリケーション、管理プレーンアプリケーションのクラスタ及び中央制御プレーンアプリケーションのクラスタ、単一の管理プレーンアプリケーション及び中央制御プレーンアプリケーションのクラスタ、あるいは単一の中央制御プレーンアプリケーション及び管理プレーンアプリケーションのクラスタを含んでもよい。他の実施形態において、本発明から逸脱することなく、これらのアプリケーションの種々の特徴を単一のマネージャ又は制御器アプリケーション（又はそのようなアプリケーションのクラスタ）に組み合わせることができることが理解されるべきである。
いくつかの実施形態において、管理プレーンは、プライベートデータセンタ１０５の管理者が（例えば、クラウド管理アプリケーションを介して）プライベートデータセンタ１０５及び／又は１つ以上のパブリックデータセンタ内で実現されるべき１つ以上の論理ネットワークを構成するための構成データを入力するアプリケーションプログラミングインタフェース（ＡＰＩ）を提供する。管理者からの論理ネットワーク構成は、論理Ｌ２スイッチ及び論理Ｌ３ルータのネットワークを含んでもよい（論理ルータは、論理ネットワーク外部の他の論理ルータ及び／又はサブネットへの接続を含む場合がある（例えば、インターネットに接続するために））。論理ネットワーク構成データは、ネットワークアドレス変換（ＮＡＴ）規則、負荷分散規則、第３者サービスへパケットを送信するための規則、ネットワークセキュリティ規則（例えば、ＤＦＷ規則）等を更に含んでもよい。
いくつかの実施形態の管理プレーンは、論理転送要素（例えば、論理スイッチ及び論理ルータ）、論理転送要素に対する論理ポート、論理ポートに対するセキュリティ規則及び暗号化規則等を定義する規則に論理ネットワーク構成を変換する。いくつかの実施形態の中央制御プレーンは、これらの規則の適切なＭＦＥへの配布を処理する。いくつかの実施形態において、中央制御プレーンは、各論理ポートの物理ネットワーク内の位置及び当該論理ポートのファーストホップ被管理転送要素を追跡する。特定の論理ポート及び／又は論理転送要素に対する規則を受信すると、中央制御プレーンは当該規則の適用範囲（すなわち、論理ネットワークを適切に実現するために規則を受信する必要があるＭＦＥ）を識別し、それぞれのホストマシン１２５上のＭＦＥ１３０と直接対話するローカル制御器１２０に規則を配布する。論理ポートに関する規則の適用範囲は、当該論理ポートが存在するホスト上のＭＦＥ（すなわち、論理ポートに接続されたＤＣＮをホストするホストマシン上のＭＦＥセット）のみであってもよく、あるいは多くのＭＦＥ（例えば、当該論理ポートと同じ論理ネットワークに接続されたＤＣＮをホストするホストマシン上の全てのＭＦＥ）であってもよい。
以上、ネットワーク制御システムがホストマシンの仮想化ソフトウェアにアクセスでき、従って単一のホストマシン上の多くのＤＣＮのネットワーク接続を制御できる（仮想化ソフトウェアにおいてＭＦＥを制御することにより）データセンタに対するいくつかの実施形態のネットワーク制御システムを説明した。しかし、論理ネットワークをパブリッククラウドに拡張すると、パブリッククラウドプロバイダのネットワーク管理システムがホストマシンを管理するため、ネットワーク制御システムは仮想化ソフトウェアにアクセスできなくなる。パブリッククラウドプロバイダにより提供されるネットワーク接続及びセキュリティは、テナント予定者にとって十分な場合もあれば、十分でない場合もあるが、いずれの場合も、当該テナントの直接管理下になく、テナントのオンプレミスネットワーク（プライベートデータセンタ内の）と適切に連携しない場合がある。
従って、図１は、パブリックデータセンタ内のホストマシンの仮想化ソフトウェアに対する制御を必要とせずにネットワーク制御システム１００をパブリックデータセンタ１１０に拡張するいくつかの実施形態の技術を示す。図１は、プライベートデータセンタ１０５の所有者（本明細書中、パブリックデータセンタのテナントと呼ぶ）のためにパブリックデータセンタ１１０内に作成された仮想プライベートクラウド（ＶＰＣ）１３５を示す。仮想プライベートクラウド１３５（又はパブリッククラウドプロバイダに応じて、同様の構造）は、テナントが制御できるパブリックデータセンタ１１０の論理的に隔離されたリソースのセットである。一部のクラウドプロバイダでは、テナントはネットワークサブネット及びルーティングテーブルを使用して仮想ネットワークを定義すること及び／又は自身のＶＭをセキュリティグループ（パブリッククラウドプロバイダにより定義される）に入れることができる。しかし、テナントはクラウドプロバイダ内の転送要素を直接制御することができず、自身のネットワークセキュリティ特徴を要望どおり構成できない場合がある。
図１は、ゲートウェイ制御器１５０を有するＶＭ１４５をホストする第１のホストマシン１４０と、ワークロードアプリケーション１６５を有するＶＭ１６０をホストする更なるホストマシン１５５のセットとをＶＰＣ内に示す。ホストマシン１４０及び１５５はＶＰＣの一部として示されるが、いくつかの実施形態において、これらのホストマシンは（同じ又は他のテナントの）異なるＶＰＣに属する更なるＶＭをホストしてもよいことが理解されるべきである。示されるように、ホストマシン１４０及び１５５の各々は転送要素１７０を含む。いくつかの実施形態において、ホストマシンは、パブリッククラウドプロバイダにより管理される自身の仮想化ソフトウェア内に転送要素を含む。しかし、これらの転送要素がクラウドプロバイダネットワークの一部であるため、ネットワーク制御システム１００は当該転送要素にアクセスできない。
ここでは単一のＶＭ１４５として示されるが、いくつかの実施形態において、ゲートウェイ制御器を有する少なくとも２つのＶＭがＶＰＣ１３５内でインスタンス化される。アクティブ制御器が機能停止した（例えば、それが動作しているホストマシンの機能停止、ＶＭの機能停止又は再起動が必要である等により）場合、ゲートウェイ制御器のうちの一方がアクティブ制御器として動作し、他方がスタンバイ制御器として動作する。いくつかの実施形態において、ゲートウェイＶＭの他の態様（後述する）も同様にアクティブ／スタンバイモードで動作する。すなわち、いくつかの実施形態において、アクティブゲートウェイＶＭ及びスタンバイゲートウェイＶＭがインスタンス化される。
いくつかの実施形態において、ＶＭ１４５は、ゲートウェイ制御器１５０を含むプリパッケージマシンイメージである。ゲートウェイ制御器１５０は、ＶＰＣ１３５内で実現された全ての論理ポートについて、ＭＰ／ＣＣＰクラスタ１１５から（例えば、中央制御プレーンアプリケーションから）データを受信する。いくつかの実施形態において、ＭＰ／ＣＣＰクラスタ１１５の観点では、ゲートウェイ制御器は多くの論理ポートが接続されたＭＦＥに対するローカル制御器１２０と等価である（ＶＰＣ１３５内で動作するＶＭにマッピングされた多くの論理ポートが存在すると仮定する）。そのため、ＭＰ／ＣＣＰクラスタ１１５は、ＶＰＣ１３５内の論理ポートのいずれかに必要な構成規則を全て受信するのはゲートウェイ制御器１５０であると識別する。ここでは示さないが、いくつかの実施形態において、ゲートウェイＶＭ１４５は、集中型サービス（例えば、ＮＡＴ、負荷分散等）を提供し且つＶＭ１６０と外部送信元との間で送信される（例えば、インターネットを介して）パケットを処理／ルーティングするためのゲートウェイデータパスを更に動作させる。いくつかの実施形態において、当該データパスが必要とする規則もゲートウェイ制御器１５０に配布される。図７を参照して、いくつかの実施形態のゲートウェイＶＭを以下に更に詳細に説明する。
ＶＭ１６０はワークロードＶＭであり、各々がワークロードアプリケーション１６５（例えば、ウェブサーバ、アプリケーションサーバ、データベースサーバ等）を実行する。更に、ネットワーク制御システム１００により構成可能なファーストホップ処理を可能にするために、これらのＶＭの各々は、制御エージェント１７０及び被管理転送要素１７５（例えば、Ｏｐｅｎ ｖＳｗｉｔｃｈ等の仮想スイッチ）を更に動作させる。構成規則を受信すると、ゲートウェイ制御器１５０はＶＰＣ１３５内での当該規則の適用範囲（すなわち、規則を必要とする種々のＭＦＥ１７５）を識別し、それらの構成規則を適切な制御エージェント１７０に渡す。制御エージェント１７０は、当該データを使用して、ローカル制御器１２０がＭＦＥ１３０を構成する方法と同様に、ワークロードアプリケーション１６５との間で送受信されるパケットにネットワーク接続及び／又はセキュリティ規則を適用するようにＭＦＥ１７５を構成する。
図２は、ネットワーク制御システム１００を通る制御データの流れを概念的に示す。ＭＰ／ＣＣＰクラスタ１１５は、新規の構成規則を生成する（例えば、ネットワーク内の変更、管理者が論理ネットワークを変更する際に管理プレーンが受信した構成データ等に基づいて）。いくつかの実施形態において、管理プレーンは当該規則を生成して中央制御プレーンに提供し、中央制御プレーンは構成規則の適用範囲を判定する。示されるように、ＭＰ／ＣＣＰクラスタ１１５は、当該データを必要とするプライベートデータセンタ１０５内のローカル制御器１２０にデータ２０５を渡す。プライベートデータセンタ内では、情報は制御チャネルを介して配布される。当該データ２０５を受信したローカル制御器は、そのホストマシンに存在するＭＦＥの特定の種類に適したフォーマットにデータを変換する。いくつかの実施形態において、データセンタは、ＥＳＸハイパーバイザ等の特徴ベース転送要素、Ｏｐｅｎ ｖＳｗｉｔｃｈ（ＯＶＳ）を実行するカーネル仮想マシン（ＫＶＭ）ハイパーバイザ等のフローベース転送要素又は他の種類のソフトウェア転送要素を使用するホストマシンを含む場合がある。ローカル制御器１２０は構成データ２０５を受信し、それを適切なフォーマット（例えば、ＯＶＳ用のフローエントリ）に変換し、当該構成データ２１０をローカルＭＦＥ１３０に配布する。
適用範囲がパブリックデータセンタ１１０内のＶＰＣ１３５を含む構成規則の場合、ＭＰ／ＣＣＰクラスタ１１５はゲートウェイ制御器１５０へ構成データ２１５を送信する。ＭＰ／ＣＣＰクラスタはゲートウェイ制御器を単に別のローカル制御器であると見なすため、いくつかの実施形態において、構成データ２１５は構成データ２０５と同じフォーマットである。しかし、ゲートウェイ制御器１５０へ構成データ２１５を送信するために、いくつかの実施形態はプライベートデータセンタ１０５とＶＰＣ１３５との間の仮想プライベートネットワーク（ＶＰＮ）設定を使用する。いくつかの実施形態は、プライベートデータセンタとＶＰＣとの間の論理ネットワークデータトラフィックと同じＶＰＮを制御トラフィックに使用し、他の実施形態は別個のデータを使用する。クラウドプロバイダの転送要素には、制御トラフィックはＶＰＮを介して送信されている他の何らかのデータと同じように見える。ゲートウェイ制御器１５０は構成データ２１５を受信し、規則毎にＶＰＣ１３５内での適用範囲を計算する。ＶＰＣ１３５内の各ＭＦＥ１７５に対して、ゲートウェイ制御器１５０は、ＭＦＥと同じＶＭ上で動作するローカル制御エージェント１７０へ適切な構成データ２２０を送信する。当該構成データ２２０は、クラウドプロバイダのネットワークを介して（例えば、転送要素１７０を介して）制御エージェント１７０へ送信される。
更に、いくつかの実施形態において、ゲートウェイ制御器１５０は、ＶＰＣ１３５内のオーバーレイネットワークを管理する責任を有する。ＭＰ／ＣＣＰクラスタ１１５は単一の被管理転送要素を有するものとしてＶＰＣ全体を見なすため、クラスタはゲートウェイ制御器ノードに対するトンネルエンドポイント（すなわち、ゲートウェイＶＭ１４５上に構成されたデータパス）のみを構成する。しかし、ＶＰＣ内のワークロードアプリケーション間（及びワークロードアプリケーションとゲートウェイデータパスとの間）の通信に対して、ＭＰ／ＣＣＰクラスタはオーバーレイを構成しない。そのため、ゲートウェイ制御器１５０は、ＭＡＣ：ＶＴＥＰ ＩＰバインディング等を構成することにより、これらのＶＭの間にトンネル（例えば、ＳＴＴ、ＧＥＮＥＶＥ等のトンネル）を設定する。過剰なデータ（例えば、ＭＡＣ：ＶＴＥＰ ＩＰバインディング）も構成データ２２０の一部として種々の制御エージェント１７０に渡される。
制御エージェント１７０が構成データを受信すると、制御エージェント１７０は当該データをＭＦＥ１７５に特有のフォーマットに変換し、ＭＦＥに特有の構成データ２２５をＭＦＥ１７５に提供する。いくつかの実施形態において、この構成データ２２５は、フローベースＭＦＥに対するフローエントリ及び／又はＭＦＥ構成データベースに対するデータベースエントリを含む。例えばいくつかの実施形態において、ＭＦＥがＯＶＳインスタンスである場合、制御エージェント１７０はＯｐｅｎＦｌｏｗ及び／又はＯＶＳＤＢプロトコルを使用してＭＦＥ１７５と通信する。
一例として、ＭＰ／ＣＣＰクラスタ１１５からゲートウェイ制御器へ送信される初期構成データは、新規の論理ポートが論理スイッチに追加されたこと及び当該論理ポートがＶＰＣ内で動作するＭＦＥに接続されることを指定してもよい。本例において、同じ論理スイッチの少なくとも１つの論理ポートは、ＶＰＣ内で動作する異なるＭＦＥに既に接続されている。ＣＣＰにとって論理ポートはゲートウェイに接続するため、ゲートウェイ制御器１５０により受信される構成データは特定の位置を特定しない。
ゲートウェイ制御器１５０は、同じ論理スイッチ上の更なる論理ポートの全てが接続するＶＰＣ内のＭＦＥとして当該構成データの適用範囲を計算する。これらのＭＦＥは、新規の論理ポートに対応するワークロードアプリケーションにパケットを適切に転送できるように情報を必要とし、従って、ゲートウェイ制御器１５０は、これらの識別されたＭＦＥの各々に対するローカル制御エージェント１７０に当該データを配布する。また、ゲートウェイ制御器１５０は、新規の論理ポートが接続するＭＦＥに対するオーバーレイ情報（例えば、ＭＡＣ：ＶＴＥＰ ＩＰバインディング）を識別された各ＭＦＥに配布し、これらの他の識別されたＭＦＥに対するオーバーレイ情報を新規の論理ポートが接続するＭＦＥに配布する。
特定のＭＦＥ１７５に対する制御エージェント１７０は、当該情報を使用して論理転送フローエントリを生成し（すなわち、論理ポートに関連付けられたＭＡＣアドレスにアドレス指定されたパケットが当該論理ポートに論理的に転送されることを指定し）、そのＭＦＥに対する出口マッピング／物理的転送（トンネリング）フローエントリを更に生成する（すなわち、論理ポートを物理的宛先にマッピングし、パケットを他のＭＦＥへ送信するためにカプセル化情報を付加する）。同様に、新規の論理ポートが接続するＭＦＥ１７５に対する制御エージェント１７０は、他の論理ポートの位置に関する情報を受信し、対応するＭＦＥとの間でパケットを送受信できるように、対応するフローエントリを生成する。
図３は、プライベートデータセンタ及びパブリックデータセンタの双方に位置する被管理転送要素に構成データを配布するいくつかの実施形態の処理３００を概念的に示す。いくつかの実施形態において、処理３００は、管理プレーンアプリケーションから受信した構成データに基づいて中央制御器（すなわち、中央制御プレーンアプリケーション）により実行される。いくつかの実施形態において、クラスタ内の異なる制御器が異なる転送要素への配布を処理してもよいため、構成データの配布が実際はクラスタ内の複数の中央制御器により実行されてもよいことが理解されるべきである。更に、本処理は、管理プレーン及び中央制御プレーンがプライベート（企業）データセンタに位置すると仮定する。ＭＰ／ＣＣＰクラスタがパブリックデータセンタのＶＰＣ内で動作している場合、これは構成データ毎に同様の適用範囲の計算を実行し、論理ネットワークが動作する各ＶＰＣに対するゲートウェイ制御器にデータを配布する。
示されるように、処理３００は、論理ネットワーク構成データを受信する（３０５において）ことにより開始する。上記で説明したように、いくつかの実施形態において、管理プレーンは、管理者から受信した（例えば、クラウド管理アプリケーションを介して）入力に基づいて、論理ネットワークに対する構成規則を生成する。管理プレーンは、これらの規則を中央制御プレーンに提供する。この構成データは、論理転送要素又はこれらの論理転送要素の論理ポートの作成又は削除、これらの論理エンティティのうちの１つに関する新規の構成データ、新規のセキュリティグループ定義又は分散型ファイアウォール規則等に関係してもよい。
次に、処理は、アトミックデータ毎（例えば、規則毎）に、当該データを受信するべきＭＦＥのセットを識別する（３１０において）。中央制御器は、論理ネットワークのトポロジ及びその物理的実現と、規則の種類及び規則が関係する論理エンティティ（例えば、論理転送要素及び論理ポート）とに基づいて、各規則の適用範囲を判定する。例えば、２つの論理ポート間の通信に対する分散型ネットワーク暗号化規則は、それらの論理ポートが直接接続するＭＦＥに配布するだけでよいだろう。一方、論理ポートからＭＡＣアドレスへのバインディングに関する規則は、論理ポートが接続するＭＦＥだけでなく、論理ポートを宛先とするパケットを処理している可能性のある他の何らかのＭＦＥ（例えば、論理ポートが接続し且つパケットの集中型処理を必要とせずに特定の論理ポートへパケットを送信できる何らかのＭＦＥ）にも配布される。
構成データの各アトミックデータの適用範囲を判定した後、処理は、プライベートクラウド内の識別されたＭＦＥに対するローカル制御器へ構成データを送信する（３１５において）。すなわち、中央制御プレーンは、同じデータセンタ内の適切なローカル制御器にデータを配布する。
処理は、いずれかのデータの適用範囲がパブリッククラウドに位置する論理ポートを含むかを更に判定する（３２０において）。上述したように、中央制御プレーンは、パブリッククラウドＶＰＣ内の全ての論理ポートが単一のＭＦＥに接続されていると見なす。本処理は、図１に示すように、単一のパブリックデータセンタに単一のＶＰＣが存在すると仮定する。以下に説明するように、いくつかの実施形態では、１つ以上のパブリックデータセンタに複数のＶＰＣが存在することが可能であり、その場合、ＶＰＣ毎に同様の判定を行う必要がある。データをパブリッククラウド内のＭＦＥへ送信する必要がある場合、処理はパブリッククラウド内で動作するゲートウェイ制御器へ当該データを送信する（３２５において）。いくつかの実施形態において、データは、中央制御器とゲートウェイが動作するＤＣＮとの間のＶＰＮ接続を使用して配布される。
図４は、ＶＰＣ内のＭＦＥに論理ネットワーク構成データを配布するためのいくつかの実施形態の処理４００を概念的に示す。いくつかの実施形態において、処理４００は、データを必要とするＶＰＣ内のＭＦＥに当該データを配布するために、ゲートウェイ制御器４００により実行される。示されるように、処理は、中央制御器から論理ネットワーク構成データを受信する（４０５において）ことにより開始する。この中央制御器は、パブリックデータセンタのテナントが管理するプライベートデータセンタに位置してもよく、ゲートウェイ制御器と同じパブリックデータセンタの別のＶＰＣに位置してもよく、あるいは別のパブリックデータセンタに位置してもよい。
アトミックデータ毎（例えば、規則毎）に、処理４００は、データを受信するべきＶＰＣ内のデータ計算ノードを識別する（４１０において）。図３に関して説明したように、各規則は、論理ネットワークのトポロジ及びその物理的実現と、規則の種類及び規則が関係する論理エンティティ（例えば、論理転送要素及び論理ポート）とに基づいて、適用範囲（すなわち、規則を必要とするＭＦＥ）を有する。従って、ＶＰＣ内では、各規則がゲートウェイ制御器により全ての制御エージェントに配布される必要がない場合がある。次に、処理は、規則に対して識別されたデータ計算ノード上のローカル制御エージェントへ各構成規則を送信する（４１５において）。いくつかの実施形態において、構成データは、標準的なデータパケットと同じ方法でパブリッククラウドプロバイダの物理ネットワークを介して送信される。
また、処理４００は、ＶＰＣ内の各データ計算ノードに対するローカルオーバーレイデータを生成する（４２０において）。中央制御器はＶＰＣ全体が単一のＭＦＥに接続されていると見なすため、中央制御器はゲートウェイＶＭに対する仮想トンネルエンドポイント（ＶＴＥＰ）のみを定義する。しかし、ＶＰＣ内の通信では、種々のＭＦＥはオーバーレイネットワークも使用する。従って、ゲートウェイ制御器は、これらのＶＴＥＰに対するＭＡＣ：ＩＰバインディングを定義する（ＶＰＣ内のＶＭに対してテナントにより構成されたプライベートＩＰアドレス（又は、構成に応じて、パブリックＩＰアドレス）に基づいて判定されたＩＰアドレスを用いて）。これらのオーバーレイの設定は、以下の第ＩＶ節及び第Ｖ節で更に詳細に説明する。
次に、処理は、ＶＰＣ内のデータ計算ノード間にトンネルを作成するために、ＶＰＣ内の各データ計算ノードへローカルオーバーレイデータを送信する（４２５において）。これにより、これらのデータ計算ノードの各々におけるＭＦＥは、自身のＶＴＥＰからＶＰＣ内の他のＭＦＥのＶＴＥＰへ送信されるパケットを適切にカプセル化できる（以下に更に詳細に説明するように、パブリックデータセンタの設定に応じて、これらのパケットはホストマシン上のプロバイダにより制御される転送要素により再度カプセル化される）。
処理４００は概念的な処理であり、ゲートウェイ制御器は例示された直線的な方法でこれらの動作を実行しなくてもよいことが理解されるべきである。例えばいくつかの実施形態は、新規のデータ計算ノードがＶＰＣ内に作成される場合は常に動作４２０及び４２５を実行し、新規の構成規則を中央制御器から受信した（新規のデータ計算ノードが作成される場合に受信されるが、他の構成の態様が変更される場合にも常に受信される）場合は常に動作４０５〜４１５を実行する。
図１及び図２に示す例は、論理ネットワークがプライベートデータセンタ１０５とパブリックデータセンタ内の単一のＶＰＣ１３５との双方にまたがる場合を示す。他の実施形態では異なる変形も可能であることが理解されるべきである。例えば図５は、パブリックデータセンタ５００内で完全に実現される論理ネットワークに対するネットワーク制御システムの一例を概念的に示す。この場合、ＭＰ／ＣＣＰクラスタ５０５は、第１のＶＰＣ５１５内のホストマシン５１０上で動作する。ゲートウェイ制御器と同様に、管理プレーン及び／又は中央制御プレーンアプリケーションは、パブリックデータセンタ５００内でインスタンス化可能な事前に構成されたＶＭイメージの一部として提供され得る。いくつかの実施形態において、管理プレーン及び／又は中央制御プレーンアプリケーションは、同じ１つ又は複数のＶＭ上で又は別個のＶＭ上で動作することができ、各々が複数のホストマシン上の複数のＶＭのクラスタとして動作できる。ＶＰＣ５２０は図１に示すＶＰＣ１３５と同様に構成され、第１のＶＭ５２５（又はアクティブ／スタンバイ構成では２つのＶＭ）がゲートウェイ制御器５３０をホストし、制御エージェント５３５がワークロードＶＭ５４５上のＭＦＥ５４０を管理する。
図６は、論理ネットワークを複数のパブリックデータセンタ６１０及び６１５に拡張するいくつかの実施形態のネットワーク制御システム６００を概念的に示す。図６に示すように、ＭＰ／ＣＣＰクラスタ６２０はプライベートデータセンタ６０５内で動作し、上述したようにローカル制御器を介してデータセンタ内のＭＦＥを管理する。本例では、論理ネットワークは第１のパブリックデータセンタ６１０及び第２のパブリックデータセンタ６１５に拡張され、各パブリックデータセンタは、ゲートウェイＶＭインスタンス（又はアクティブ／スタンバイ対）を有するＶＰＣと、図１を参照して説明したように構成される複数のホストマシンとを含む。ＭＰ／ＣＣＰクラスタ６２０は、これらのゲートウェイ制御器の各々を単一のローカル制御器と同様であると見なし、従って、各ＶＰＣ内のワークロードに対する構成データの全てを各ゲートウェイ制御器へ送信する。
図１、図５及び図６におけるこれらの異なるアーキテクチャは、多くの可能なアーキテクチャのうちの３つにすぎないことが理解されるべきである。例えばネットワーク制御システムは、各ＶＰＣに１つのゲートウェイ制御器（又はアクティブ／スタンバイ対）を用いて、あるいは全てのＶＰＣを管理するためにＶＰＣのうちの１つ（又は別個のＶＰＣ）内の単一のゲートウェイ制御器（又はアクティブ／スタンバイ対）を使用して、１つのクラウドプロバイダ内の複数のＶＰＣにわたり延在することができる。
ＩＩ． ゲートウェイＶＭのアーキテクチャ
上記の節では、いくつかの実施形態のゲートウェイＶＭのネットワーク制御器機能（適用範囲の計算及びオーバーレイ管理）を説明した。いくつかの実施形態において、これらのゲートウェイＶＭは、パブリッククラウドＡＰＩとのインタフェース、ＤＨＣＰ、ＤＮＥ管理、並びにＶＰＣ内のＤＣＮとの間で送受信されるデータパケットに対するゲートウェイを含むいくつかの他の機能を更に実行する。
図７は、いくつかの実施形態のそのようなゲートウェイＶＭ７００のアーキテクチャを概念的に示す。上述したように、いくつかの実施形態において、ゲートウェイＶＭは、論理ネットワークの管理者がパブリックデータセンタＶＰＣ内のＶＭのうちの１つとしてインスタンス化することができる特定のクラウドプロバイダに対する事前に構成されたＶＭイメージ（例えば、Ａｍａｚｏｎ Ｍａｃｈｉｎｅ Ｉｍａｇｅ）としてパッケージ化される。示されるように、ゲートウェイＶＭ７００は、ゲートウェイ制御器７０５、パブリッククラウドマネージャ（ＰＣＭ）７１０、ゲートウェイデータパス７１５、ＤＮＥ管理モジュール７２０及びＤＨＣＰモジュール７２５を含む。異なる実施形態において、ゲートウェイＶＭは、これらのモジュールの異なる組み合わせ、並びにこれらのモジュールの全部又は一部と他のモジュールとの組み合わせを含んでもよいことが理解されるべきである。
更に、ゲートウェイＶＭは、制御ＶＮＩＣ７３０、アップリンクＶＮＩＣ７３５及びローカルオーバーレイＶＮＩＣ７４０である３つのインタフェースを含む。いくつかの実施形態において、制御ＶＮＩＣ７３０は、ＶＰＣ内の他のホスト上のローカルエージェントとゲートウェイ制御器７０５との間の制御パス通信及びＭＰ／ＣＣＰクラスタとゲートウェイ制御器７０５との間の制御パス通信（並びにＤＮＥマネージャ７２０又はＰＣＭの何らかの通信）にのみ使用される。いくつかの実施形態は、ＶＰＣ内の不正アクセスされたＶＭからのサービス拒否（ＤｏＳ）攻撃を防止するために、クラウドプロバイダ内のセキュリティグループがＣＣＰ及びローカルエージェントからの特定のトラフィックのみを当該インタフェース上で許可するようにプログラムする。更に、悪意のあるＶＭがゲートウェイデータパス７１５に大量のトラフィックを送信している場合でも制御チャネルが実行し続けることを保証するために、いくつかの実施形態は、ゲートウェイ制御器処理（及びＶＰＣ内の他のＶＭ内で動作するエージェント）をデータプレーン処理を実行しない特定の仮想ＣＰＵに固定する。アップリンクＶＮＩＣ７３５は、ゲートウェイデータパス７１５から外部の宛先に向けて送信される（及びそれら外部の宛先から受信される）ノース／サウスパケットを処理する。一般に、そのようなパケットはデータパスによりカプセル化されない。ローカルオーバーレイＶＮＩＣ７４０は、ＶＰＣ内のワークロードアプリケーションと他のＶＰＣ、他のパブリックデータセンタ及び／又はオンプレミスデータセンタ内のデータ計算ノードとの間でパケットを送信するためにゲートウェイデータパスが処理するイースト／ウエストデータパケットを処理する。
いくつかの実施形態のゲートウェイ制御器７０５は、上記の第Ｉ節で説明した機能を実行する。制御ＶＮＩＣ７３５を介して、ゲートウェイ制御器７０５の中央制御プレーンインタフェース７４５は中央制御器から構成規則を受信し、中央制御器に情報を提供する（例えば、新規のＶＭが作成されたため、新規の論理ポートをゲートウェイに関連付ける必要がある場合）。エージェントインタフェース７５０は、ＶＰＣ内のデータ計算ノード上で動作するローカルエージェントに構成データを配布し、データ計算ノード上でイベント（例えば、データ計算ノード上でのインタフェースの作成等）が発生した場合にこれらのローカルエージェントから更新を受信する。いくつかの実施形態において、これらのインタフェース７４５及び７５０の双方は、ゲートウェイＶＭ上で動作するｎｅｔｃｐａエージェントの一部である。
ゲートウェイ制御器７０５は、適用範囲マネージャ７５５及びローカルオーバーレイマネージャ７６０を更に含む。適用範囲マネージャは、中央制御器から送信された構成規則を受信し（ＣＣＰインタフェース７４５を介して）、ＶＰＣ内のデータ計算ノード上で実行するＭＦＥ（場合によっては、ゲートウェイデータパス７１５を含む）を判定し、これらの構成規則をＶＰＣ内の適切なエージェントへ送信する。いくつかの実施形態は、ＶＰＣ内の各エージェントに対して異なるアダプタ及び／又は異なるキューを使用し、受信した各規則を１つ以上のそのようなキューに入れる。
ローカルオーバーレイマネージャ７６０は、ＶＰＣ内のオーバーレイネットワークの管理を処理する（第Ｖ節で後述するように、オーバーレイモードで動作するＭＦＥに対して）。いくつかの実施形態において、ＶＰＣ内のＭＦＥがオーバーレイモードで動作していると仮定した場合、ＶＰＣ内のＶＭ上の各エージェント（及びゲートウェイデータパス７１５）は、自身のＶＴＥＰ ＩＰアドレス及び当該ＶＴＥＰ ＩＰアドレスにバインディングされたＭＡＣアドレスを制御器に提供する。いくつかの実施形態のローカルオーバーレイマネージャ７６０は、提供された各バインディングを必要とするＶＰＣ内のＭＦＥを識別し、ＭＡＣアドレスへ送信されるデータパケットを対応するＶＴＥＰ ＩＰアドレスを使用してカプセル化できるように、ＶＰＣ内のＭＦＥへの当該情報の提供を処理する。第１のＭＦＥに接続されたワークロードアプリケーションが、データパケットにゲートウェイデータパス７１５を通過させる必要なく第２のＭＦＥに接続されたワークロードアプリケーションにデータパケットを送信する可能性がある場合、第１のＭＦＥは第２のＭＦＥのＭＡＣ：ＶＴＥＰ ＩＰバインディングを必要とする。
いくつかの実施形態のパブリッククラウドマネージャ（ＰＣＭ）７１０は、ネットワーク制御システムがパブリッククラウドプロバイダの計算管理システムと対話できるようにする。詳細には、いくつかの実施形態のＰＣＭはパブリッククラウドＡＰＩを使用して、パブリッククラウドプロバイダからインベントリ情報、構成情報、状態情報及び統計情報を検索する。ここで示す例では、ＰＣＭ７１０はゲートウェイＶＭ上で動作するが、他の実施形態において、ＰＣＭはＭＰ／ＣＣＰクラスタ（例えば、プライベートデータセンタ内の）で動作してもよい。
示されるように、ＰＣＭは、パブリッククラウドＡＰＩ７６５と、エージェント及びＭＰ／ＣＣＰクラスタと通信するためのインタフェース７７０及び７７５とを含む。いくつかの実施形態において、ＰＣＭは管理プレーンとのみ直接通信し、エージェントとの間のあらゆる通信はゲートウェイ制御器を通過する。パブリッククラウドＡＰＩ７６５は、パブリッククラウドの計算マネージャと通信するために使用される。
例えばいくつかの実施形態のＰＣＭ７１０は、パブリッククラウドマネージャからインベントリ情報を取り出し、変更が検出された場合にこれらの更新を管理プレーンへ送信する。管理プレーンは、当該情報を使用して、論理ネットワークが実現される１つ以上のパブリックデータセンタ及び／又はプライベートデータセンタ内のデータ計算ノードのインベントリを保持する。いくつかの実施形態において、パブリッククラウドからの当該インベントリは、サブネット、セキュリティグループ、データ計算ノード（例えば、ＶＭ）及びネットワークインタフェースのうちのいくつか又は全てを含んでもよい。
更に、いくつかの実施形態において、ＰＣＭ７１０は、パブリッククラウド内のＶＭ上に構成されたタグを使用して、これらのＶＭのネットワーク及びセキュリティ設定を管理プレーンに指定する（例えば、ＶＭを追加する必要がある論理スイッチ及びセキュリティグループ）。ローカルエージェント及びＭＦＥがインストールされていないＶＭがＶＰＣにおいて起動される場合、いくつかの実施形態のＰＣＭは、これらのパッケージのＶＭへのインストールも処理する。ＰＣＭは更に、そのＶＰＣ内のＶＭが不正アクセスされた場合に通知され、パブリッククラウドＡＰＩ７６５を使用してパブリッククラウドマネージャを介して当該ＶＭを隔離セキュリティグループに入れることができる。
ゲートウェイデータパス７１５は、いくつかの実施形態ではデータ処理ゲートウェイとして動作し、（ｉ）ローカルＶＰＣ内のデータ計算ノードと、同じクラウドプロバイダの異なるＶＰＣ、異なるクラウドプロバイダの異なるＶＰＣ及び／又はプライベートデータセンタに位置する同じ論理ネットワークの他のデータ計算ノードとの間、並びに（ｉｉ）ローカルＶＰＣ内のデータ計算ノードと論理ネットワーク外部の送信元／宛先（例えば、インターネットを介してデータ計算ノードにアクセスするクライアント）との間のデータパケットに対するパケット処理を処理する。データパス７１５は、データパス内のサービスルータ７８０（いくつかの実施形態の論理ルータの集中型ルーティング構成要素）を示すが、データパスはＶＰＣ内で実現される１つ以上の論理スイッチ及び１つ以上の分散型ルーティング構成要素の構成を更に含んでもよいことが理解されるべきである。
異なる実施形態において、データパス７１５は、データパス開発キット（ＤＰＤＫ）ベースのデータパス、いくつかの実施形態のデータ計算ノードで使用されるようなＯＶＳデータパス又はＶＭ内で実現可能な別の種類のデータパスであってもよい。ＯＶＳデータパスが実現される場合、いくつかの実施形態は、論理スイッチ及び／又は分散型ルータ処理のためにＯＶＳデータパスを使用し、集中型ルーティング構成要素処理を処理するために別個の名前空間を実現する。一方、ＤＰＤＫベースのデータパスを使用するいくつかの実施形態は、同じデータパス内の全ての論理転送要素構成要素に対する構成を実現する。いくつかの実施形態のゲートウェイデータパスの更なる説明は、本明細書に参考として取り入れられる米国特許出願公開第２０１６／０２２６７５９号明細書に記載される。
示されるように、データパス７１５は、ローカルオーバーレイＶＮＩＣ７４０に接続するＶＴＥＰポート７８５及びアップリンクＶＮＩＣ７３５に接続するアップリンクポート７９０である２つのポートを使用する。ゲートウェイデータパス７１５は、ＶＰＣサブネット上の（すなわち、ＶＰＣ内の他のＶＭに割り当てられたアドレスと同じサブネット上の）クラウドプロバイダにより割り当てられたＩＰアドレスを使用するＶＴＥＰ７８５を介してＶＰＣ内のローカルワークロードから送信されたパケットを受信する。いくつかの実施形態では全てのトラフィックが論理に対してカプセル化されるため、当該ＶＴＥＰポート７８５は、プライベートデータセンタ内のデータ計算ノードとの間、並びに同じパブリックデータセンタ又は他のパブリックデータセンタ内の他のＶＰＣ内のデータ計算ノードとの間で送受信されるパケットにも使用される。
アップリンクポート７９０は、ＶＰＣ内のワークロードと外部の送信元／宛先との間でノース／サウスデータトラフィックを送受信するためにデータパス７１５により使用される。これらのデータパケットは、カプセル化されずにアップリンクポートから送信される（但し、クラウドプロバイダネットワーク上でクラウドプロバイダゲートウェイに別個にトンネリングされてもよい）。更に、これらのパケットは、ＮＡＴ、ノース／サウストラフィックに対する分散型ファイアウォール規則、サービスチェイニング等の集中型サービスを必要とする場合がある。
複数のＶＰＣ及び／又はデータセンタにまたがる論理Ｌ２スイッチの場合、ゲートウェイデータパス７１５は、別のＶＰＣの同様に構成されたゲートウェイに又はプライベートデータセンタ内の宛先転送要素に（ＶＰＮを介して）パケットを単にトンネリングする（ＶＴＥＰ７８５を使用して）中間転送要素として機能する。いくつかの実施形態は、セキュリティ動作（例えば、そのようなパケットに対する分散型ファイアウォール規則の適用）を更に実行し、暗号化を必要とする２つのエンドポイント間で送信されるパケットを復号化してから再暗号化する（検査し、場合によっては処理するために）。２つの異なる論理スイッチ間で送信されるパケットは、集中型サービス（ＮＡＴ、負荷分散等）がそのようなパケットに必要とされる場合、サービスルータ処理７８０を更に必要としてもよい。
ネットワーク内に位置するデータ計算ノードに対する暗号化規則及び鍵を管理するために、ＤＮＥマネージャ７２０はネットワーク制御システムと対話する。ローカルＶＰＣ内で動作するワークロードのいずれかとの間で送受信されるパケットに対する暗号化及び／又は認証の要件を指定する規則を中央制御プレーンが受信すると、中央制御器はこれらの規則をＤＮＥマネージャ７２０に配布する（直接又はゲートウェイ制御器７０５を介して）。以下及び参考として本明細書に取り入れられる米国特許出願第６２／３８０，３３８号で更に詳細に説明されるように、いくつかの実施形態の暗号化規則は、多くの場合はプライベートデータセンタに位置する鍵記憶装置（鍵マネージャとも呼ばれる）から鍵を取得するために制御器（この場合は、ＤＮＥマネージャ）により使用されるチケットを含む。
ＤＮＥマネージャ７２０は、このチケットを使用して鍵マネージャに鍵を要求し、鍵マネージャは暗号化規則に対するマスタ鍵を提供する。ＤＮＥマネージャ７２０はマスタ鍵を受信し、この鍵を使用して規則に対するセッション鍵を生成する。いくつかの実施形態において、セッション鍵は、マスタ鍵と暗号化を実行する２つのエンドポイントに特有の１つ以上の更なるパラメータとの関数として生成される。ＤＮＥマネージャは、生成されたセッション鍵を適切なエンドポイントに配布する（例えば、ゲートウェイ制御器７０５を介して）。
最後に、ＤＨＣＰモジュール７２５はＶＰＣ内でＩＰアドレス管理を実行するためのＤＨＣＰサーバとして機能する。いくつかの実施形態は、複数の論理スイッチがＶＰＣ内で実現される場合、複数のサブネットに対して同一のＤＨＣＰモジュール７２５を使用する。ＶＰＣ内のＶＭが起動すると、いくつかの実施形態では、ＶＭはネットワークアドレスを受信するためにローカルゲートウェイ内のＤＨＣＰサーバを使用する。
ＩＩＩ． 初期ＶＰＣ構成
上記の節では、ＶＰＣへの制御プレーンの拡張及び当該拡張を可能にするゲートウェイ制御器を説明したが、いくつかの実施形態において、ＶＰＣ内のこれらの種々の構成要素は最初に構成され且つ管理プレーン及び中央制御プレーンと共に搭載される必要がある。いくつかの実施形態において、パブリッククラウドにおけるネットワーク及び制御システムの初期設定は、運用マネージャ（ライフサイクルマネージャ又はＬＣＭとも呼ばれる）により管理される。ネットワーク管理者は、ネットワーク管理者のパブリッククラウド資格情報を使用する当該ＬＣＭと対話して（例えば、ユーザインタフェースを介して）ＬＣＭにアクセスし、ＶＰＣ内の種々のＶＭを初期構成する。
図８は、プライベートデータセンタを管理するネットワーク制御システムをパブリックデータセンタの１つ以上のＶＰＣに初期拡張するいくつかの実施形態の処理８００を概念的に示す。いくつかの実施形態において、処理８００は、この初期設定を実行するためにプライベートデータセンタ管理システムと（例えば、計算マネージャと）対話するライフサイクルマネージャ（ＬＣＭ）により実行される。ＬＣＭはパブリックデータセンタ内のＤＣＮ（ＰＣＭが実行するゲートウェイＤＣＮを含む）の初期構成を処理するがＰＣＭはパブリックデータセンタ管理システムとの継続的対話を処理するという点で、ＬＣＭは上述のＰＣＭと異なる。処理８００は、ＬＣＭの１つの可能なワークフローにすぎず、ＤＣＮがパブリックデータセンタ内で既にインスタンス化されていると仮定されることが理解されるべきである。いくつかの実施形態において、例えばＶＰＣは定義されているがＤＣＮがこれらのＶＰＣにまだ存在していない場合、他のワークフローが存在するだろう。
示されるように、処理８００は、ネットワークを構成しようとするデータセンタのパブリッククラウドプロバイダに対する管理者資格情報を受信する（８０５において）ことにより開始される。資格情報は、ユーザ名及びパスワードを含んでもよく、場合によっては、データセンタが必要とする他の資格情報を含んでもよい。いくつかの実施形態のＬＣＭは、ユーザがＡｍａｚｏｎ、Ｇｏｏｇｌｅ、Ｍｉｃｒｏｓｏｆｔ等の複数のパブリッククラウドプロバイダと統一された方法で対話することを可能にし且つそれを介してユーザがこれらの資格情報を入力することを可能にする単一のインタフェースを提供してもよい。次に処理は、これらの資格情報を使用して、ユーザに登録されているパブリッククラウド内のＶＰＣのリストを検索する（８１０において）。このために、ＬＣＭはこれらの資格情報をパブリッククラウド管理システムのインタフェースに提供し、ユーザのＶＰＣに関する要求したデータを提供される。いくつかの実施形態において、ユーザは、割り当てられたサブネット等を用いてパブリッククラウド内に多くのＶＰＣを既に構成している。
次に、処理８００は、ネットワーク制御システムにより管理しようとするＶＰＣに関する識別を管理者／ユーザから受信する（８１５において）。いくつかの実施形態において、これらは論理ネットワークが拡張されることになるＶＰＣである。いくつかの実施形態において、ＬＣＭはユーザインタフェースを介して管理者にリストを提示し、管理者はインタフェースを介して利用可能なＶＰＣのうちのいくつか又は全てを選択する。処理は、識別されたＶＰＣの各々にゲートウェイインスタンスを自動的に配置する（８２０において）。いくつかの実施形態において、ゲートウェイインスタンスは、第ＩＩ節で上述した構成要素を有するＶＭである。説明したように、いくつかの実施形態において、各ゲートウェイＶＭは、ゲートウェイＶＭがデータセンタ内に配置されるパブリッククラウドプロバイダ専用に設計されたプリパッケージマシンイメージのインスタンスである。
更に、処理８００は、管理者により識別されたＶＰＣ内のＤＣＮ（例えば、ＶＭ）のリストを検索する（８２５において）。ＶＰＣの検索と同様に、いくつかの実施形態において、ＬＣＭはこの情報をパブリッククラウド管理システムに問い合わせる。処理は、既存のＤＣＮのうちネットワーク制御システムにより管理するべきＤＣＮに関する管理者からの指示と、当該ＤＣＮに対する論理スイッチ及び／又はセキュリティグループの指定とを受信する（８３０において）。この場合、論理ネットワークトポロジ及びセキュリティグループの定義は既に構成されており、パブリッククラウド内のＤＣＮはこれらのエンティティにマッピングされる。処理８００は、これらのＤＣＮとの間で送受信されるパケットを処理するための適切な構成規則が生成され且つネットワーク制御システムを介して配布されるように、論理スイッチ及びセキュリティグループのマッピングを管理プレーンに提供する（８３５において）。
上記の処理は、ＬＣＭがゲートウェイＤＣＮをパブリッククラウド内でインスタンス化すると説明する。しかし、いくつかの実施形態において、そのゲートウェイＤＣＮ上のゲートウェイ制御器も、中央制御器からデータを受信するためにＭＰ／ＣＣＰクラスタに認定される必要がある。図９は、管理プレーン及び制御プレーンにゲートウェイ制御器を認定させるためのいくつかの実施形態の処理９００を概念的に示す。処理９００は、ゲートウェイ制御器を含むゲートウェイＤＣＮをインスタンス化する際にゲートウェイ制御器により実行される。
示されるように、処理９００は、管理プレーン証明書及びＩＰアドレスを識別する（９０５において）ことにより開始する。いくつかの実施形態において、管理プレーン証明書は、特定の管理プレーンインスタンス又はインスタンスのクラスタに対するゲートウェイＤＣＮのインスタンス化と共に提供される。いくつかの実施形態において、当該情報はゲートウェイＤＣＮに提供される（例えば、ゲートウェイ制御器がアクセスできる構成ファイルにおいて）。また、処理は、管理プレーンとのセキュアな通信チャネルに使用される共有シークレットを生成する（９１０において）。いくつかの実施形態は、管理者又はＬＣＭにより入力されるコマンドラインインタフェース（ＣＬＩ）コマンドに基づいて、この共有シークレットを生成する。
次に、共有シークレット及び管理プレーンのＩＰアドレスを使用して、処理９００は管理プレーンに接続し（９１５において）、管理プレーンの真正性を検証する（すなわち、認可されている管理プレーンアプリケーションに接続したことを確認する）。いくつかの実施形態において、管理プレーンアプリケーションは自身の証明書（又は証明書から生成されたハッシュ等の値）を提供し、ゲートウェイは証明書が一致することを検証する。また、処理は、自身の証明書を管理プレーンに登録する（９２０において）。いくつかの実施形態において、この証明書は管理プレーンにより同様に検証される。この時点で、ゲートウェイは管理プレーンクラスタに接続しているが、中央制御プレーンに接続していないため、構成規則を受信できない。
次に、処理９００は、設定された管理プレーンとの通信チャネルを介して管理プレーンから中央制御プレーン証明書を受信する（９２５において）。中央制御プレーン証明書を使用して、処理は中央制御プレーンとのチャネルを有効にする（９３０において）。管理プレーンは中央制御プレーンにゲートウェイ証明書を提供し、中央制御プレーンはゲートウェイから受信した証明書が当該証明書と一致するかを検証する。同様に、ゲートウェイ制御器は、中央制御プレーンから受信した証明書が管理プレーンから受信した証明書と一致するかを検証する。このチャネル設定により、中央制御プレーンがゲートウェイ制御器に配布する構成データを判定すると、ゲートウェイ制御器は中央制御プレーンから構成データを受信することを開始できる。
ゲートウェイが管理プレーン及び中央制御プレーンと共に搭載されると、ＶＰＣのＤＣＮ内のエージェントも同様に搭載できる。しかし、プライベートデータセンタ内のゲートウェイ又はローカル制御器と異なり、これらのエンティティはゲートウェイ制御器がこれらの論理ポートの全てに対する制御器であると見なすため、これらのローカルエージェントはプライベートデータセンタで動作するＭＰ／ＣＣＰクラスタと通信しない。従って、これらのエージェントはゲートウェイ制御器に対してのみ自身を検証する。
図１０は、パブリッククラウドＶＰＣ内のＤＣＮで実行するローカル制御エージェントが当該ＶＰＣに対するゲートウェイ制御器に自身を認定させるために実行するいくつかの実施形態の処理１０００を概念的に示す。示されるように、処理１０００は、ゲートウェイ名及び証明書を識別する（１００５において）ことにより開始する。いくつかの実施形態において、ゲートウェイ名は、制御エージェントに対する構成ファイル内のＵＲＬとして提供される（例えば、ｎｓｘ‐ｇｗ．ａｗｓ．ｃｏｍ）。いくつかの実施形態において、この構成ファイルは、インタフェース及びそれらの種類（例えば、オーバーレイ又は非オーバーレイ）のリストを更に含む。処理は、ゲートウェイ名に基づいてゲートウェイＩＰアドレスを分析する（１０１０において）。例えばいくつかの実施形態は、データセンタ内のＤＮＳサーバを使用して、ゲートウェイ名をＶＰＣ内でのＩＰアドレスに分析する。
次に、処理１０００は、ゲートウェイ制御器への制御チャネルを開始する（１０１５において）。当該制御チャネルを介して、処理はゲートウェイへエージェント証明書を送信し（１０２０において）、ゲートウェイからゲートウェイ証明書を受信する。いくつかの実施形態において、ゲートウェイは、各エージェントの証明書がゲートウェイに事前登録されていることを必要とせずに、初回使用時にエージェント証明書を信頼することを認可される。しかし、エージェントにおける処理１０００は、ゲートウェイから受信した証明書を検証し（１０２５において）、有効なゲートウェイ制御器に接続したことを確認する。
上記の処理は、ネットワーク制御システムを介して構成データを受信するためにパブリックデータセンタ内の種々のネットワーク制御システムエンティティ（すなわち、ゲートウェイ制御器及び制御エージェント）を認定することに関する。更に、これらの処理は、制御器が動作するＶＭが既に存在すると仮定する。場合によっては、ユーザ（例えば、非管理者ユーザ）は、パブリックデータセンタＶＰＣ内に新規のワークロードＶＭを作成し、ＶＭ上のＭＦＥが正しい構成規則セットを提供されることを保証する必要がある。これはいつでも発生する可能性があり、従って、理想的には、その時点でネットワーク管理者による作業又は認可を必要としないようにする必要がある。そのため、いくつかの実施形態において、ネットワーク制御システムは、これらの新規のワークロードＶＭを自動的に提供するように構成される。
図１１は、新規のワークロードＤＣＮ（本例では、ＶＭ）が既存の被管理ＶＰＣ内に作成される場合のいくつかの実施形態のネットワーク制御システム１１００におけるデータの流れを概念的に示す。示されるように、図１１は、ＶＰＣ内のゲートウェイＶＭ１１００及び（新規の）ワークロードＶＭ１１０５と、ＶＰＣ外のパブリッククラウドデータリポジトリ１１１０（例えば、パブリッククラウドを管理するためにパブリッククラウド管理者により使用される計算管理システム）とを含む。更に、図１１は、ネットワーク制御システムの管理プレーン１１１５及び中央制御プレーン１１２０を含み、これらは異なるＶＰＣ、プライベートデータセンタ等に位置してもよい。パブリッククラウドマネージャ１１２５及びゲートウェイ制御器１１３０がゲートウェイＶＭ１１００の構成要素として示されるが、いくつかの実施形態のゲートウェイＶＭは、図７を参照して上述した他の機能（例えば、ゲートウェイデータパス、ＤＮＥマネージャ等）を更に含んでもよい。
ＶＭを起動する前に、ユーザは、（ｉ）ゲートウェイＩＰアドレス及びトークン／証明書（いくつかの実施形態では、エージェント構成ファイル内に事前に構成されてもよい）、（ｉｉ）ワークロードが接続することになる論理スイッチ及び／又はワークロードが属することになるセキュリティグループに対するトークン、並びに（ｉｉｉ）インスタンスにインストールする制御エージェントパッケージのうちのいくつか又は全てを管理者から受け取る。ＶＭを設定する場合、ユーザはＶＭがゲートウェイＩＰ及び証明書を有することを確認する。それらは、構成ファイル及びエージェント設定において（図１０を参照して上述したように）又はパブリッククラウドプロバイダのＡＰＩを使用して提供され得る。また、ユーザは、論理スイッチ及び／又はセキュリティグループに対するトークンをインスタンスのラベルとして追加する。いくつかの実施形態において、ユーザがクラウドプロバイダユーザインタフェースを介してインスタンスを作成する場合、インタフェースは、ＶＭインスタンスに関するデータとしてパブリッククラウドデータリポジトリ１１１０に格納されているタグをＶＭに追加する機能を含む。例えばタグは、ＶＭがセキュリティグループＳＧ１に属し且つ論理スイッチＬＳ１に接続する必要があることを示すために、「ｔｏｋｅｎ‐ｌｓ１」及び「ｔｏｋｅｎ‐ｓｇ１」というラベルが付けられてもよい。これらのタグは、何らかのアウトオブバンド機構を介して（例えば、口頭で、電子メールを介して又はメッセージ送信等で）ネットワーク制御システム管理者からユーザに提供されてもよい。
この時点で、ＶＭデータはパブリッククラウドデータリポジトリ１１１０に格納される。当該データは、ＶＭ１１０５が特定のＶＰＣ（すなわち、ゲートウェイＶＭ１１００のＶＰＣ）内でインスタンス化されることを示し、ユーザにより入力された論理スイッチ及びセキュリティグループタグを含むＶＭに関する他のデータを更に含んでもよい。パブリッククラウドリポジトリはタグとこれらのエンティティとを関連付けないが、ＶＭに添付されたものとしてこれらのタグを格納する。丸囲み文字１で示すように、ＰＣＭ１１２５は、この新規のＶＭに関する情報をパブリッククラウドデータリポジトリ１１１０から検索する。この情報は、新規のＶＭの存在と、そのクラウドプロバイダ識別子、それが関連付けられるＶＰＣ等のクラウドプロバイダに関連する種々の属性と、地域及び／又はユーザの情報を含む。いくつかの実施形態において、ＰＣＭ１１２５は、ポーリング機構又はパブリッククラウドリポジトリ１１１０との通知チャネルを使用して、新規のインスタンスがＶＰＣ内に作成されたと判定する。
新規のＶＭがＶＰＣ内に作成されたという判定に応答して、ＰＣＭ１１２５はいくつかの動作を行う。丸囲み文字２で示すように、ＰＣＭは、管理プレーン１１１５のインベントリに新規のＶＭを追加し（例えば、新規のＶＭオブジェクトを作成するためのＡＰＩコールを介して）、ＶＭに対する管理プレーン内に作成されたオブジェクトにＶＭの種々のパブリッククラウドプロバイダ属性（ＶＭ識別子、ＶＰＣ識別子、インタフェースＩＤ等）の全てをタグとして追加する。これにより、ネットワーク管理者はＶＭ及びその属性を管理プレーンインベントリで閲覧できる。
また、ＰＣＭ１１２５は、クラウドプロバイダＡＰＩを使用して論理スイッチ及び／又はセキュリティグループのタグを読み出す。ＰＣＭ１１２５は論理スイッチタグを使用して、管理プレーンにおいて新規のポートを作成する論理スイッチを判定する（例えば、管理プレーンＡＰＩを介して）。丸囲み文字３で示すように、ＰＣＭ１１２５は新規のポートを作成し、ＶＭのインタフェースを当該論理ポートに接続する（例えば、クラウドプロバイダからのインタフェース識別子を使用して）。更にＰＣＭは、インタフェースのＩＰアドレス及びＭＡＣアドレスを読み出し、これらを新規に作成された論理ポート上のＭＡＣ／ＩＰバインディングとして構成する。また、いくつかの実施形態は、要望に応じて、論理ポートに対してＤＦＷ規則を設定できるように、何らかの必要な特徴を有効にする。更に、丸囲み文字３で更に示すように、ＰＣＭ１１２５はセキュリティグループタグに基づいて新規のＶＭ１１０５のセキュリティグループを識別し、管理プレーン１１１５を介して論理ポートを当該セキュリティグループに追加する。
ＶＭ１１０５が最初に電源投入されると（エージェント１１３５が既にインストールされていると仮定する）、当該エージェントはゲートウェイＩＰを読み出し、ゲートウェイとの接続を確立する（例えば、上述した処理１０００を介して）。接続が確立されると、丸囲み文字４Ａで示すように、エージェント１１３５はゲートウェイに接続要求を送信する。これは、ＶＭのインタフェースを論理ネットワークに接続することを要求するが、エージェントはインタフェースが接続することになる論理スイッチに関する情報をまだ有さない場合がある。いくつかの実施形態において、接続要求はクラウドプロバイダインタフェース識別子を使用して、論理スイッチに接続されるべきインタフェースを指定する。丸囲み文字４Ｂで示すように、ゲートウェイ制御器１１３０は当該要求を中央制御プレーン１１２０に転送する。
ＣＣＰは、インタフェースに対する論理ポートの作成に関する情報をＭＰから受信している。要求内の識別子は操作２でＰＣＭにより提供されたクラウドプロバイダ識別子と一致する必要があるため、ＣＣＰは要求内で使用される識別子に基づいて正確な論理ポートを識別できる。ＣＣＰはゲートウェイ制御器１１３０が論理ポートの位置であると見なし、丸囲み文字５Ａで示すように、論理ポート情報及び何らかの関連するポリシー規則をゲートウェイ制御器１１３０に提供する。丸囲み文字５Ｂで示すように、ゲートウェイ制御器は当該データをエージェント１１３５に渡し、それにより、エージェント１１３５は、ワークロードＶＭ１１０５上で動作するＭＦＥに対する構成データを生成し、ワークロードアプリケーションとの間で送受信されるパケットの処理を開始することができる。ゲートウェイ制御器も当該データをキャッシュするため、ＶＭ１１０５が再起動した場合、以降の接続要求を中央制御プレーンに転送する必要はない。更に、論理ポート及びそのポリシー規則に関する情報は、必要に応じてゲートウェイ制御器１１３０によりＶＰＣ内の他のエージェントへ送信される。また、ゲートウェイ制御器１１３０は、上述したようにＶＭ１１０５に対するオーバーレイ設定を実行し、オーバーレイ情報をエージェント１１３５に配布し（丸囲み文字６で示すように）、ＶＰＣ内の他のＶＭ上のエージェントにも配布する。
このワークフローは、ユーザがＤＣＮを手動で作成する場合を説明するが、自動スケーリングされたＤＣＮの場合も同様の処理が行われる。いくつかの実施形態において、管理者は、使用を監視される特定のＤＣＮ（例えば、ウェブサーバ等の同一又は同様のワークロードのグループ）を設定でき（クラウドプロバイダインタフェースを介して）、ＤＣＮが過負荷になった場合にクラウドプロバイダ管理システムに更なるインスタンスを自動的に作成させることができる。この場合、新規のＤＣＮはクラウドプロバイダシステムによりパブリッククラウドデータリポジトリ１１１０に自動的に追加され、図に示すようにデータフローが行われる。更に、いくつかの実施形態のＰＣＭ１１２５は、クラウドプロバイダデータリポジトリ１１１０を定期的にポーリングし、インタフェースの作成／削除／修正を含むＶＰＣ内の既存のＤＣＮに対する変更（例えば、ＩＰアドレス及び／又はＭＡＣアドレスの変更）及びＤＣＮのタグの変更を識別する。これらの変更が生じた場合、ＰＣＭ１１２５はそれらを管理プレーン１１１５に伝搬する。
いくつかの実施形態において、ユーザは、ネットワーク制御システムに転送を実行させるのではなく、マイクロセグメンテーション及び／又は分散型ファイアウォール規則の施行のみを実行させたい場合がある。この非オーバーレイモードも以下の第Ｖ．Ａ節で更に詳細に説明する。いくつかのそのような実施形態において、管理プレーンは、同じ論理スイッチに対して作成された全ての添付ファイルを用いてフラット論理スイッチ（実際はスイッチングを全く含まない）を作成する。この場合、クラウドプロバイダインタフェースを介して新規のＤＣＮを指定する際に、ユーザは特定の論理スイッチタグではなくネットワークのデフォルトタグを入力する。その後、ユーザはサブネット（すなわち、ＶＰＣ）内に新規のＤＣＮを作成し、クラウドプロバイダはインスタンスに対するＩＰアドレスを提供する。新規のＤＣＮがインスタンス化されると、ＰＣＭはＶＰＣ内の新規のＤＣＮを識別し、新規のＤＣＮがこのフラット論理スイッチに接続できるようにデータをＭＰに提供する。その後、ネットワーク制御システムは、必要に応じて、新規のＤＣＮ上で動作するＭＦＥにセキュリティ規則をプッシュダウンできる。
ＩＶ． 論理トポロジの物理的実現
上述したように、論理ネットワークを１つ以上のパブリックデータセンタに拡張することにより、論理トポロジがこれらのデータセンタにまたがり拡張されてもよい。いくつかの実施形態は、所定の論理スイッチに接続されるＶＭを１つのＶＰＣ（又はプライベートデータセンタ）に限定し、他の実施形態は、単一の論理スイッチでも複数のＶＰＣ又は複数のデータセンタにまたがることを可能にする。
図１２は、管理者が管理プレーンに論理トポロジを入力してもよい場合のいくつかの実施形態の論理トポロジ１２００を概念的に示す。示されるように、論理トポロジ１２００は、論理ルータ１２０５と２つの論理スイッチ１２１０及び１２１５とを含む。４つの仮想マシンが論理スイッチ１２１０に接続され、論理ルータは外部ネットワークへのアップリンクポートを含む。この場合、１層の論理ルータのみが論理ネットワーク内に示されるが、いくつかの実施形態は複数層の論理ルータを含むこともできる。更に、いくつかの実施形態の管理プレーンは、論理ルータ１２０５に対して複数の論理ルーティング構成要素（例えば、分散型ルータ及び１つ以上の集中型サービスルータ）を定義してもよい。複数層の論理ルータ及び論理ルータに対する複数のルーティング構成要素の作成は、本明細書に参考として取り入れられる米国特許出願公開第２０１６／０２２６７５４号明細書に更に詳細に記載される。
いくつかの実施形態において、論理ルータに接続された論理スイッチ１２１０及び１２１５の各々にサブネットが割り当てられ、従って、特定の論理スイッチに接続するように作成されたワークロードＶＭに適切なサブネットにおけるＩＰアドレスを割り当てる必要がある。しかし、以下の第Ｖ．Ｂ節で更に詳細に説明するように、いくつかの実施形態において、クラウドプロバイダネットワークに対するＩＰアドレスはＶＭ上で動作するＭＦＥに対して作成されたトンネルエンドポイントのＩＰアドレスであるため、クラウドプロバイダに関するＶＭのＩＰアドレスは当該ＶＭにマッピングされる論理ポートのＩＰアドレスと異なる。この場合、論理スイッチ１２１０はサブネット１９２．１６８．１．０／２４を割り当てられる。更に、４つのＶＭが論理スイッチ１２１０に接続されると示される。
図１３は、単一のパブリッククラウドプロバイダの単一のＶＰＣ１３００内に実現される場合の論理スイッチ１２１０に接続された４つのＶＭ１３０５〜１３２０の一例を示す。本例において、論理スイッチ１２１０に接続された全てのＶＭは同じＶＰＣ内でインスタンス化され、当該論理スイッチに接続されたＶＭのみがＶＰＣ内でインスタンス化される。このＶＰＣ１３００にはサブネット１０．１.０．０／１６が割り当てられる。これは、管理者がパブリッククラウドでＶＰＣを構成した方法に応じて、パブリックサブネットであってもよく、プライベートサブネットであってもよい。本例（及び本節の他の例）において、ＭＦＥは全てオーバーレイモードで動作しているため、ＶＭ ＩＰアドレスはワークロードアプリケーションＩＰアドレス（すなわち、論理スイッチポートに関連付けられたＩＰアドレス）と異なる。
示されるように、各ＶＭには、１９２．１６８．１．０／２４サブネットにおける異なるワークロードＩＰ（１９２．１６８．１．１、１９２．１６８．１．２、１９２．１６８．１．３及び１９２．１６８．１．４）が割り当てられる。ワークロードアプリケーションがパケットを送信する場合、このＩＰアドレスが当該パケットのヘッダで使用される送信元ＩＰになる。しかし、これらのＶＭで動作するＭＦＥは、１０．１.０．０／１６サブネットにおける異なるＩＰアドレス（１０．１.０．１、１０．１.０．２、１０．１.０．３及び１０．１.０．４）を有するＶＴＥＰを有する。従って、ＶＰＣ内の他の宛先へ送信するためには、ＶＭから送信されるパケットは当該ＶＴＥＰ ＩＰアドレスを送信元ＩＰアドレスとして使用してカプセル化される（論理処理が送信元ＶＭ内のＭＦＥにより実行された後に）。
図１３は、これら４つのＭＦＥとＶＰＣ内のゲートウェイ１３２５との間のトンネルを更に示す。これらのトンネルは、パブリッククラウドプロバイダの下層ネットワーク（本明細書中、「アンダーレイ」と呼ぶ）を通過する。更に、簡潔にするため図示しないが、ＶＭ１３０５〜１３２０上で動作するＭＦＥの各対の間にトンネルが作成される（アンダーレイネットワークを介して）。
ゲートウェイは、オンプレミスプライベートデータセンタ１３３０内の宛先にパケットを送信する（及び当該宛先からパケットを受信する）こともできる。これらのパケットを送信するためにゲートウェイ１３２５は自身のＶＴＥＰ ＩＰ（１０．１．０．５）を使用してパケットをカプセル化するため、宛先は受信パケットを論理ネットワークパケットとして識別する。いくつかの実施形態において、ＶＰＣ１３００内のゲートウェイ１３２５とプライベートデータセンタ１３３０内の宛先（例えば、論理スイッチ１２１５に接続されたＶＭ）との間のトラフィックをセキュリティ保護するために、パケットはＶＰＮトンネル１３３５を介して送信される。本例では、外部ネットワークへのゲートウェイの接続を図示しない。これについては、集中型及び分散型のネットワークアドレス変換及び他のサービスに関する以下の節で更に詳細に説明する。
図１４は、論理スイッチ１２１０が単一のデータセンタ内の（すなわち、同じクラウドプロバイダの）２つの別個のＶＰＣ１４００及び１４０５にまたがる一例を示す。この場合、４つのＶＭ１４１０〜１４２５は、単一のサブネット上のワークロードアプリケーションに対して同じＩＰアドレスを有する（１９２．１６８.１．０／２４）。しかし、２つのＶＰＣは異なるサブネットを有するため（第１のＶＰＣは１０．１.０．０／１６が割り当てられ、第２のＶＰＣは１０．２.０．０／１６が割り当てられる）、ＭＦＥのＶＴＥＰの全てが同じサブネット上に存在するわけではない。従って、第１のＶＰＣ１４００内の２つのＶＭ１４１０及び１４１５上のＶＴＥＰはＩＰアドレス１０．１．０．１及び１０．１．０．２が割り当てられ、第２のＶＰＣ１４０５内の２つのＶＭ１４２０及び１４２５上のＶＴＥＰはＩＰアドレス１０．２．０．１及び１０．２．０．２が割り当てられる。
ゲートウェイ１４３５及び１４４０も各ＶＰＣ内でインスタンス化され、各々が各自のＶＰＣのサブネット上のＶＴＥＰを有する。ＶＰＣがピア接続されていない状況では、２つのゲートウェイ間で送信されるパケットはＶＰＮ接続を使用して送信される（すなわち、ＶＰＣは別個のデータセンタに位置してもよい）。しかし、一部のクラウドプロバイダではＶＰＣのピア接続が可能であり、その場合、一方のＶＰＣの１つのエンドポイントから別のピア接続ＶＰＣの第２のエンドポイントへパケットを直接送信できる。従って、２つのＶＰＣ１４００及び１４０５がピア接続される場合、ＶＭ１４１０及び１４１５の一方からＶＭ１４２０及び１４２５の一方へ送信されるパケットはＶＰＮ１４３０を介して送信される必要はない。実際、いくつかの実施形態は、これらのパケットがゲートウェイ１４３５及び１４４０を介して送信されることさえ必要せず、プロバイダネットワークを介して一方のＶＭから他方のＶＭに直接トンネリングすることができる。しかし、ＶＰＣ１４００及び１４０５がピア接続されない場合、そのようなＶＰＣ間パケットは、ＶＭからＶＰＣ内トンネルを介してゲートウェイへ送信され、第１のゲートウェイからＶＰＮを介して宛先ＶＰＣ内の第２のゲートウェイへ送信され、第２のゲートウェイから宛先ＶＭへ送信される必要がある。
プライベートデータセンタ１４４５に接続する（例えば、第２の論理スイッチ１２１５に接続されたＶＭに到達するために）場合、ゲートウェイはＶＰＮ１４３０を使用する。このＶＰＮ１４３０は、プライベートデータセンタと１つ以上のクラウドプロバイダにおける１つ以上のＶＰＣとをリンクするために使用される種々の可能なＶＰＮ構成を表す。例えば、いくつかの実施形態は各宛先との間にフルメッシュのＶＰＮトンネルを使用するが、他の実施形態はハブアンドスポークＶＰＮ又はそれら２つの組み合わせを使用する。更に、異なる実施形態は、パブリッククラウドプロバイダ又はネットワーク制御システムにより提供されるＶＰＮ、あるいはそれらの組み合わせ（例えば、ＶＰＮのメッシュを使用する場合）を使用してもよい。
図１５は、図１４と同様の構成を示すが、ＶＭ１５１０〜１５２５は２つの全く異なるクラウドプロバイダのデータセンタに位置するＶＰＣ１５００及び１５０５にまたがる論理スイッチ１２１０に接続される。この状況は、一般に２つの異なるデータセンタ（特に、異なるクラウドプロバイダの２つの異なるデータセンタ）間でＶＰＣをピア接続することができないためデータセンタ内のワークロード間のあらゆる通信がＶＰＮ１５３０を介して送信される点において、図１４と異なる。図１４で説明したように、いくつかの実施形態は、マルチパブリッククラウド構成においてハブアンドスポークＶＰＮを使用してもよく、他の実施形態は、（ｉ）各パブリッククラウドと他のパブリッククラウドとの接続及び（ｉｉ）各パブリッククラウドとプライベートデータセンタとの接続に対して別個のＶＰＮ接続を使用する。
これらの図に示される例に加えて、他の構成も可能であることが理解されるべきである。例えば単一の論理スイッチは、プライベートデータセンタと１つ以上のパブリックデータセンタ間にまたがることができる。図１３〜図１５のいずれにおいても、論理スイッチに接続された１つ以上のＶＭはパブリッククラウドＶＰＣのうちの１つではなくオンプレミスデータセンタにおいて実現可能である。
Ｖ． ワークロードＶＭにおけるＭＦＥの構成
上述したように、ネットワーク制御システムがパブリッククラウド内のワークロードＤＣＮとの間で送受信されるデータトラフィックに対するパケット処理規則を構成できるようにするために、いくつかの実施形態は、被管理転送要素とＭＦＥを構成するローカル転送エージェントとをワークロードＤＣＮにインストールする。このＭＦＥはＤＣＮのネットワークインタフェースに接続されるため、これらのＤＣＮで実行するワークロードアプリケーションとの間で送受信される全てのパケットは、ローカル制御エージェントによりインストールされた構成データに従ってＭＦＥを通過する（且つＭＦＥにより処理される）。
本発明の異なる実施形態において、これらのＭＦＥは異なる方法で構成されてもよい。例えばいくつかの実施形態は、ワークロードアプリケーションのＩＰアドレスがＤＣＮのネットワークインタフェースのＩＰアドレスと同じである非オーバーレイモードでＭＦＥを構成する。この場合、ＭＦＥはパケット処理を実行せず、代わりに、マイクロセグメンテーション及び／又は分散型ファイアウォール規則処理等のネットワークセキュリティ処理を実行するように構成される。他の実施形態において、ＭＦＥは、ワークロードアプリケーションが接続するインタフェースがＶＴＥＰに使用されるＤＣＮの外部インタフェースと異なるＩＰアドレスを有するように構成される。この場合、ＭＦＥは、何らかのネットワークセキュリティ又は他の処理に加えて、論理ネットワーク構成に従ってパケット転送を実行する。最後に、管理者は、既存のワークロードに対して同じＩＰアドレスを保持したいがパケット処理、トンネリング等のために論理ネットワークを利用したい場合がある。この第３の例では、ＭＦＥはワークロードアプリケーションとは別のＤＣＮの名前空間に構成される。これにより、ワークロードアプリケーションは、既存のＩＰアドレスを有するインタフェースに接続した後、ｖｅｔｈペアを使用して、ＶＴＥＰに対して同じＩＰアドレスを使用する別の名前空間内のＭＦＥに当該インタフェースを接続することができる。
Ａ． 非オーバーレイモードのＭＦＥ
図１６は、非オーバーレイモードで構成された被管理転送要素１６００を有するＶＭ１６０５を概念的に示す。本例において、ＭＦＥはＯｐｅｎ ｖＳｗｉｔｃｈ（ＯＶＳ）インスタンスである。これら例の全てにおいて、ＭＦＥは２つのブリッジを含むように構成され、すなわち、統合ブリッジ（アプリケーションワークロードがＶＭのネットワークスタックを介して接続する）とＶＭの仮想ネットワークインタフェース制御器（ＶＮＩＣ）に接続する物理インタフェース（ＰＩＦ）ブリッジとを含むように構成される。
図１６に示すように、ＶＭ１６０５上で動作するワークロードアプリケーション１６１０（例えば、ウェブサーバ、アプリケーションサーバ等）は、内部ポートを介してＭＦＥの統合ブリッジ１６１５に接続する。この内部ポートはＶＭのネットワークスタックに関連付けられ、従って、パブリッククラウドプロバイダにより提供されるＶＭのＩＰアドレス（例えば、図１３の例では１０．１．０．０／２４のＩＰアドレス）を有する。いくつかの実施形態において、統合ブリッジ１６１５は転送及びカプセル化を実行しない。その代わりに、統合ブリッジ１６１５は、何らかのセキュリティ処理を実行した後に（パケットが破棄又は拒否されないと仮定する）、パッチポートを介して全てのパケットをＰＩＦブリッジ１６２０に自動的に転送する。
また、統合ブリッジは、何らかのネットワークセキュリティ又は他の非転送ポリシーを実現するフローエントリを使用して、アプリケーション１６１０から受信した（又はＰＩＦブリッジから受信してアプリケーション１６１０へ送信する）パケットを処理する。例えば統合ブリッジは、ＶＭ１６０５が接続する論理ポートに適用されるＤＦＷ規則を実現する。いくつかの実施形態において、これらの規則は、送信元及び／又は宛先ＭＡＣアドレスに関して指定されてもよく、これらの指定されたアドレスとの間で及び／又は特定の条件下（例えば、接続開始）で送信されるパケットを許可、破棄、拒否等してもよい。更に、異なる実施形態は、ロギング、分散型暗号化規則（発信パケットの暗号化及び着信パケットの復号化の双方）、並びに第３者サービスアプライアンス（例えば、ミドルボックスアプライアンス）へのトンネリングの組み合わせを実現してもよい。
図１７は、非オーバーレイモードで動作するＭＦＥによるＶＰＣを介するパケット処理の一例を示し、詳細には、同じＶＰＣ上の別のワークロードアプリケーション１７１０へパケットを送信する第１のワークロードアプリケーション１７０５を示す。図１７は、パブリックデータセンタ内の同じＶＰＣ内でＶＭを動作する２つのホストマシン１７１５及び１７２０を含む。第１のＶＭ１７２５は第１のホストマシン１７１５上で動作し、ワークロードアプリケーション１７０５及びＭＦＥ１７３５は第１のＶＭ内で実行する。第２のＶＭ１７３０は第２のホストマシン１７２０上で動作し、ワークロードアプリケーション１７１０及びＭＦＥ１７４０は第２のＶＭ内で実行する。この場合、双方のＭＦＥが非オーバーレイモードで動作する。更に、ホストマシン１７１５及び１７２０はそれぞれ、各々のＶＭが接続する各々のパブリッククラウド転送要素１７４５及び１７５０を含む。これらのパブリッククラウド転送要素は、ソフトウェア仮想スイッチであってもよい（実際は、ＭＦＥ１７３５及び１７４０と同じ種類の仮想スイッチであり得る）。しかし、ＭＦＥ１７３５及び１７４０と異なり、これらの転送要素はパブリッククラウドプロバイダにより制御されるため、ネットワーク制御システムはこれらの転送要素にアクセスできない。
示されるように、第１のワークロードアプリケーション１７０５は、ＶＭ１７２５上のＭＦＥ１７３５へパケット１７５５を送信する。パケット１７５５は、送信元ＩＰアドレス及び宛先ＩＰアドレスと、種々のヘッダ（例えば、ＴＣＰ／ＵＤＰ、ＩＰ、イーサネット等）と、ペイロードとを含む。本明細書中で使用される場合、パケットは、ネットワークを介して送信される特定のフォーマットのビットの集合を示す。本明細書において、用語「パケット」は、イーサネットフレーム、ＩＰパケット、ＴＣＰセグメント、ＵＤＰデータグラム等のネットワークを介して送信されてもよい種々のフォーマットのビットの集合を示すために使用されてもよいことが理解されるべきである。以下の例はパケットを示すが、本発明は何らかの特定のフォーマット又は種類のデータメッセージに限定されるべきではないことが理解されるべきである。
パケット１７５５を受信すると、ＭＦＥ１７３５は、それがローカル制御エージェント（不図示）により構成される際に用いられた何らかの適用可能なセキュリティポリシー（例えば、ファイアウォール規則）又は他の非転送ポリシーを適用する。パケットが破棄されないと仮定して、ＭＦＥ１７３５は、パブリッククラウド転送要素１７４５に接続するＶＭインタフェースからパケット１７５５を出力する。パブリッククラウドネットワークがホストマシン間のトンネリングを使用すると仮定して、パブリッククラウド転送要素１７４５は、独自のアンダーレイカプセル化を用いてパケットをカプセル化し、このカプセル化されたパケット１７６０を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、第１のホストマシン１７１５のインタフェースのＩＰを送信元アドレスとして使用し、宛先ホストマシン１７２０のインタフェースのＩＰを宛先アドレスとして使用する。
その後、パケット１７６０はホストマシン１７２０により受信され、パブリッククラウド転送要素１７５０によりカプセル解除される。転送要素１７５０は宛先アドレスに基づいてワークロードＶＭ１７３０のインタフェースにパケット１７５５を送信し、ＭＦＥ１７４０は当該パケットを処理する。ＭＦＥ１７４０はネットワークセキュリティ処理を実行し、そしてワークロードアプリケーション１７１０にパケットを出力する。いくつかの実施形態において、送信元ＶＭ及びそのＭＦＥが攻撃者により不正アクセスされる場合、送信元及び宛先の双方におけるＭＦＥがネットワークセキュリティを実行する。
ネットワーク制御システムは転送を提供しないため、いくつかの実施形態において、論理スイッチは２つ以上のＶＰＣにまたがることができない（Ｌ２ドメインは下層ＶＰＣサブネットに制限される）。更に、Ｌ３転送は、ピア接続又はＶＰＮを使用するＶＰＣ内又はＶＰＣ間のルーティングに限定される。しかし、非オーバーレイモードを使用すると、アプリケーションはクラウドプロバイダからのＩＰアドレスで動作し続けることができるため、ストレージ又は負荷分散サービス等にクラウドプロバイダにより提供される他のサービスとのシームレスな統合が容易になる。ノース／サウストラフィックは、ゲートウェイデータパスをデフォルトゲートウェイとして使用する。この場合、クラウドプロバイダにより提供され且つゲートウェイのノースバウンドインタフェースに接続される別個のルーティングテーブルは、クラウドプロバイダのインターネットゲートウェイをデフォルトゲートウェイとして指す。
Ｂ． オーバーレイモードのＭＦＥ
図１８は、（ｉ）アプリケーションにより使用される内部ポートと（ｉｉ）同じＶＰＣ上の他のＶＭへ送信されるパケットをカプセル化するＶＴＥＰとに対して異なるＩＰアドレスを有するオーバーレイモードで構成された被管理転送要素１８００を有するＶＭ１８０５を概念的に示す。図１６と同様に、ＭＦＥ１８００は、統合ブリッジ１８１５及びＰＩＦブリッジ１８２０を用いて構成されたＯＶＳインスタンスである。ＶＭ１８０５上で動作するワークロードアプリケーション１８１０（例えば、ウェブサーバ、アプリケーションサーバ等）は、内部ポートを介してＭＦＥの統合ブリッジ１８１５に接続する。しかし、この場合、内部ポートは、ワークロードが接続される論理ポートに対応するＩＰアドレスに対するネットワークスタックに関連付けられ、従って、論理ポートが関連付けられる論理スイッチのサブネットに属する（例えば、図１３の１９２．１６８.１．０／２４アドレス）。
この場合、統合ブリッジ１８１５は、ワークロードアプリケーション１８１０との間で送受信されるパケットに対して論理Ｌ２及び／又はＬ３処理を実行する。これは、論理トポロジ内の各論理転送要素に対する入力／出力コンテキストマッピング及び入力／出力ＡＣＬと論理スイッチング及び／又はルーティングとを含んでもよい。更に、いくつかの実施形態において、統合ブリッジは、非オーバーレイＭＦＥの場合と同様に、分散型ファイアウォール、分散型暗号化、第３者サービスアプライアンスへのトンネリング等を実行する。
ＭＦＥ１６００と異なり、ＭＦＥ１８００は、２つのブリッジ間でパケットを送信するためのパッチポートを用いて構成されない。その代わりに、統合ブリッジ１８１５は、ＰＩＦブリッジ１８２０上のＶＴＥＰに接続するオーバーレイポートを含む（例えば、クラウドプロバイダＩＰアドレスに対する第２のネットワークスタックを介して）。このＶＴＥＰは、統合ブリッジ１８１５がＶＭ１８０５から送信されるパケットをカプセル化するために使用し且つゲートウェイデータパスを含む同じＶＰＣ内の他のＭＦＥがワークロードアプリケーションに対するパケットをＭＦＥ１８００にトンネリングするために使用するクラウドプロバイダＩＰアドレス（例えば、図１３の１０．１．０．０／１６アドレス）を有する。ＶＴＥＰのＩＰアドレスへ送信される（クラウドプロバイダＩＰアドレスを有するＶＭ１８０５のＶＮＩＣを介して）これらのパケットは、ワークロードアプリケーション１８１０に出力される前に統合ブリッジ１８１５によりカプセル解除される。
図１９は、オーバーレイモードで動作するＭＦＥによるＶＰＣを介するパケット処理の一例を示し、詳細には、同じＶＰＣ上の別のワークロードアプリケーション１９１０へパケットを送信する第１のワークロードアプリケーション１９０５を示す。図１９は、パブリックデータセンタ内の同じＶＰＣ内でＶＭを動作させる２つのホストマシン１９１５及び１９２０を含む。第１のＶＭ１９２５は第１のホストマシン１９１５上で動作し、ワークロードアプリケーション１９０５及びＭＦＥ１９３５は第１のＶＭ内で実行する。第２のＶＭ１９３０は第２のホストマシン１９２０上で動作し、ワークロードアプリケーション１９１０及びＭＦＥ１９４０は第２のＶＭ内で実行する。この場合、双方のＭＦＥがオーバーレイモードで動作し、内部ＩＰは論理スイッチポートに関連付けられ、ＶＴＥＰ ＩＰはクラウドプロバイダのＶＰＣサブネットに関連付けられる。更に、ホストマシン１９１５及び１９２０はそれぞれ、各々のＶＭが接続する各々のパブリッククラウド転送要素１９４５及び１９５０を含む。これらのパブリッククラウド転送要素は、ソフトウェア仮想スイッチであってもよい（実際は、ＭＦＥ１９３５及び１９４０と同じ種類の仮想スイッチであり得る）。しかし、ＭＦＥ１９３５及び１９４０と異なり、これらの転送要素はパブリッククラウドプロバイダにより制御されるため、ネットワーク制御システムはこれらの転送要素にアクセスできない。
示されるように、第１のワークロードアプリケーション１９０５は、ＶＭ１９２５上のＭＦＥ１９３５へパケット１９５５を送信する。パケット１９５５は、送信元ＩＰアドレス及び宛先ＩＰアドレスと、種々のヘッダ（例えば、ＴＣＰ／ＵＤＰ、ＩＰ、イーサネット等）と、ペイロードとを含む。この場合、送信元ＩＰアドレスはワークロードアプリケーションの内部ＩＰアドレスである（ＶＭインタフェースのＩＰアドレスではない）。
パケット１９５５を受信すると、ＭＦＥ１９３５は、ローカル制御エージェントによる構成に従って、何らかのアプリケーションセキュリティポリシー（例えば、ファイアウォール規則）に加えて論理転送を実行する。パケットの宛先ＭＡＣアドレスが送信側ワークロードと同じ論理スイッチ上にある場合、トポロジを介する処理は当該論理スイッチに対するＬ２処理のみを含む。宛先が異なる論理スイッチ上にある場合、複数のルーティング構成要素が関係する場合は、論理処理は、送信元論理スイッチに対する処理と、少なくとも１つの分散型論理ルータに対する処理と、宛先ＭＡＣアドレスが属する論理スイッチに対する処理とを含む（場合によっては、論理ルーティング構成要素間の何らかの遷移論理スイッチに加えて）。
パケットが破棄されないと仮定して、ＭＦＥ１９３５は、パケットを宛先にトンネリングするようにパケット１９５５をカプセル化し（例えば、ＧＥＮＥＶＥ、ＳＴＴ等を使用して）、このカプセル化パケット１９６０をパブリッククラウド転送要素１９４５に接続するＶＭインタフェースから出力する。パブリッククラウドネットワークがホストマシン間のトンネリングを使用する場合、パブリッククラウド転送要素１９４５は、独自のアンダーレイカプセル化を用いてパケットの２回目のカプセル化を行い、この二重カプセル化パケット１９６５を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、第１のホストマシン１９１５のインタフェースのＩＰアドレスを送信元アドレスとして使用し、宛先ホストマシン１９２０のインタフェースのＩＰアドレスを宛先アドレスとして使用する。
アンダーレイ（クラウドプロバイダ）ネットワークを通過した後、パケット１９６５はホストマシン１９２０により受信され、パブリッククラウド転送要素１９５０は外側（アンダーレイ）カプセル化を除去する。転送要素１９５０は、宛先ＶＴＥＰアドレスに基づいて、単カプセル化パケット１９６０をワークロードＶＭ１９３０のインタフェースへ送信し、ＭＦＥ１９４０は当該パケットを処理する。ＭＦＥ１９４０は、オーバーレイカプセル化を除去し、何らかの更なる論理処理及びネットワークセキュリティ処理を実行し、内部パケット１９５５をワークロードアプリケーション１９１０に出力する。
また、ワークロードアプリケーションは、論理ネットワーク上であるがＶＰＣの外側（例えば、同じデータセンタの異なるＶＰＣ、同じ又は異なるクラウドプロバイダの異なるパブリックデータセンタ、あるいはテナント自身のプライベートデータセンタ）に位置する宛先へパケットを送信してもよい。いくつかの実施形態において、これらのパケットはＶＰＣ内のゲートウェイにトンネリングされ、ＶＰＮ（又は別のセキュアな方法）を介して別のデータセンタにおける宛先へ送信される。宛先は、同じ論理スイッチ上であるか（上記の第ＩＶ節で示した例のように）、あるいは別の論理スイッチ上である（その場合、ゲートウェイは必要に応じて集中型ルータ処理を提供してもよい）ことができる。
図２０は、ＶＰＣ外部の論理ネットワーク宛先へ送信されるパケットに対するオーバーレイモードのＭＦＥによるＶＰＣを介するパケット処理の一例を示す。図２０は、パブリックデータセンタ内の同じＶＰＣ内でＶＭを動作させる２つのホストマシン２０１５及び２０２０を含む。ワークロードＶＭ２０２５は第１のホストマシン２０１５上で動作し、ワークロードアプリケーション２００５及びＭＦＥ２０３５（オーバーレイモード）はワークロードＶＭ内で実行する。ゲートウェイＶＭ２０３０は第２のホストマシン２０２０上で動作し、ゲートウェイデータパス２０１０はＶＭ上で実行する（パケット処理に関係しないため、ここでは不図示の制御器、ＰＣＭ等に加えて）。前述のように、ＭＦＥ２０３５はオーバーレイモードで動作し、ワークロードが接続する論理スイッチポートに関連付けられた内部ＩＰアドレスと、クラウドプロバイダのＶＰＣサブネットに関連付けられたＶＴＥＰ ＩＰアドレスとを用いる。更に、ホストマシン２０１５及び２０２０はそれぞれ、各々のＶＭが接続する各々のパブリッククラウド転送要素２０４５及び２０５０を含む。上記の場合と同様に、これらのパブリッククラウド転送要素はソフトウェア仮想スイッチであってもよく、ネットワーク制御システムはこれらにアクセスできない。
示されるように、ワークロードアプリケーション２００５は、ＶＭ２０２５上のＭＦＥ２０３５へパケット２０４０を送信する。前述のパケットと同様に、このパケット２０４０は、送信元ＩＰアドレス及び宛先ＩＰアドレス（並びに、送信元ＭＡＣアドレス及び宛先ＭＡＣアドレス）と、種々のヘッダと、ペイロードとを含む。図１９と同様に、送信元ＩＰアドレスはワークロードアプリケーション２００５の内部ＩＰアドレスである（ＶＭインタフェースのＩＰアドレスではない）。パケットの宛先ＩＰアドレスは、ＶＰＣの外側（及び同じデータセンタ内のピア接続ＶＰＣの外側）に位置する論理ネットワーク宛先に対応する。これは、プライベートデータセンタ、（同じ又は異なるプロバイダからの）異なるパブリックデータセンタ等に位置するＤＣＮであり得る。宛先がワークロードアプリケーションと同じ論理スイッチ上にある場合、パケット２０４０内の宛先ＭＡＣアドレスも当該宛先のアドレスである。一方、宛先が異なる論理スイッチ上にある場合、宛先ＭＡＣはワークロードの論理スイッチが接続する論理ルータポートのアドレスである。
パケット２０４０を受信すると、ＭＦＥ２０３５は、ローカル制御エージェントによる構成に従って、何らかのアプリケーションセキュリティポリシー（例えば、ファイアウォール規則）に加えて論理転送を実行する。パケットの宛先ＭＡＣアドレスが送信側ワークロードと同じ論理スイッチ上にある場合、トポロジを介する処理は当該論理スイッチに対する論理スイッチ処理のみを含む。宛先が異なる論理スイッチ上にある場合、論理処理は、（ワークロードアプリケーション２００５が）接続する送信元論理スイッチに対する処理と、少なくとも１つの分散型ルータに対する処理と、宛先ＭＡＣアドレスが属する論理スイッチに対する処理とを含む。いずれの場合も、ＭＦＥは宛先論理スイッチポートがゲートウェイＶＴＥＰにマッピングされていると識別する（ＶＰＣの外部の全ての論理ポートはゲートウェイにマッピングされるため）。
パケットが破棄されないと仮定して（例えば、分散型ファイアウォール規則に基づいて）、ＭＦＥ２０３５は、パケットをゲートウェイにトンネリングするようにパケット２０４０をカプセル化し（例えば、ＧＥＮＥＶＥ、ＳＴＴ等を使用して）、このカプセル化されたパケット２０５５パブリッククラウド転送要素２０４５に接続するＶＭインタフェースからを出力する。示されるように、このカプセル化に対する送信元ＩＰアドレスはＭＦＥ２０３５のＶＴＥＰのアドレス（すなわち、ＶＭインタフェースのアドレス）であり、宛先ＩＰアドレスはゲートウェイデータパス２０１０のＶＴＥＰのアドレス（すなわち、トンネルトラフィックに使用されるゲートウェイＶＭインタフェースのアドレス）である。
パブリッククラウド転送ネットワークがホストマシン間のトンネリングを使用すると仮定して、パブリッククラウド転送要素２０４５は、独自のアンダーレイカプセル化を用いてパケットの２回目のカプセル化を行い、この二重カプセル化パケット２０６０を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、ホストマシン２０１５のインタフェースのＩＰアドレスを送信元ＩＰアドレスとして使用し、ホストマシン２０２０のインタフェースのＩＰアドレスを宛先ＩＰアドレスとして使用する。
アンダーレイ（クラウドプロバイダ）ネットワークを通過した後、パケット２０６５はホストマシン２０２０により受信され、パブリッククラウド転送要素２０５０はアンダーレイカプセル化を除去する。転送要素２０５０は、オーバーレイカプセル化の宛先ＩＰアドレスに基づいて、トンネリングされるトラフィックに対するゲートウェイＶＭのインタフェースを介して、まだカプセル化されているパケット２０５５をゲートウェイＶＭ２０３０へ送信する。ゲートウェイデータパス２０１０は、カプセル化を除去し、内部パケット２０４０の宛先論理ポートを識別し、当該ポートを宛先トンネルエンドポイントにマッピングすることにより、当該パケット２０５５を処理する。この特定の例において、宛先はオンプレミスＭＦＥ（すなわち、テナント自身のプライベートデータセンタ内の）にマッピングされる。いくつかの実施形態はこれをトンネルエンドポイントとして使用するが、他の実施形態はプライベートデータセンタに対するゲートウェイにパケットをトンネリングする。示されるように、新規のカプセル化パケット２０６５について、送信元ＩＰアドレスはゲートウェイＶＴＥＰのアドレス（すなわち、元のカプセル化パケット２０５５の宛先アドレス）であり、宛先はオンプレミスＭＦＥのＶＴＥＰである。更に、パケットが宛先データセンタに到達するためにインターネットを通過する必要がある場合があるため、プライベートデータセンタにおける宛先に到達するためにカプセル化パケット２０６５はセキュアなＶＰＮトンネルを介して送信される。このＶＰＮトンネルは、いくつかの実施形態ではゲートウェイにおいて適用されてもよく、あるいはパブリッククラウドプロバイダにより提供される別個のＶＰＮゲートウェイにより適用されてもよい。その後、ＶＰＮトンネリングパケット２０７０はデータセンタから送信される。
Ｃ． 単一のＩＰを用いるオーバーレイモードのＭＦＥ
場合によっては、データセンタのテナントは、ワークロードのＩＰアドレスを変更せずに、パブリックデータセンタ内で動作する既存のＤＣＮのセットに自身のネットワーク制御システムを適用させたい場合がある。この要求に応えるために、いくつかの実施形態は、パブリックデータセンタＤＣＮ内のＭＦＥ及びワークロードアプリケーション（例えば、ウェブサーバ、アプリケーションサーバ等）がＤＣＮの異なる名前空間において動作することを可能にする。これにより、同じＩＰアドレスに関連付けられた独立したネットワークスタックを２つの名前空間が有することができるようになる（同じ名前空間内で動作する２つのネットワークスタックを同じＩＰアドレスに関連付けるができない第Ｂ節で上述した標準的なオーバーレイモードと異なる）。
図２１は、オーバーレイモードで構成されるがＶＴＥＰポートと同じＩＰアドレスを内部ポートに使用する被管理転送要素を有するＶＭ２１００を概念的に示す。前述の例と同様に、ＭＦＥは、統合ブリッジ２１１５及びＰＩＦブリッジ２１２０を用いて構成されたＯＶＳインスタンスである。しかし、この場合、ＶＭ２１００は、ルート名前空間２１０５と第２の名前空間２１１０との双方を含む。ＭＦＥブリッジが第２の名前空間内でインスタンス化されるため、第２の名前空間２１１０をＭＦＥ名前空間と呼ぶ。
ＶＭ２１０５上で動作するワークロードアプリケーション２１２５は名前空間２１０５内で実行する。ＶＭのユーザがＶＭにログインする場合、通常はこのように見える（ネットワーク管理者と異なり）。ＭＦＥ名前空間２１１０は統合ブリッジ２１１５及びＰＩＦブリッジ２１２０を含み、それらは上述したＭＦＥ１８００の場合と同様に動作する。すなわち、統合ブリッジ２１１５は、ワークロードアプリケーション２１２５との間で送受信されるパケットに対して論理Ｌ２／Ｌ３処理を実行する。これは、論理トポロジ内の各論理転送要素に対する入力／出力ＡＣＬと論理スイッチング及び／又はルーティングとを含んでもよい。更に、統合ブリッジ２１１５は、ＭＦＥの他のモードと同様に、分散型ファイアウォール、分散型暗号化、第３者サービスアプライアンスへのトンネリング等を実行する。更に、この場合、２つのブリッジ２１１５及び２１２０の間でパケットを送信するように構成されたパッチポートは存在しない。その代わりに、統合ブリッジ２１１５は、ＰＩＦブリッジ２１２０上のＶＴＥＰに接続するオーバーレイポートを含む。
しかし、２つの異なる名前空間を使用することにより、ＰＩＦブリッジ上のＶＴＥＰ及びアプリケーション２１２５の双方がクラウドプロバイダからの同一のＩＰアドレス（すなわち、ＶＭ２１００のＶＮＩＣ２１３０に関連付けられたＩＰアドレス）を使用できる。２つの名前空間の各々において実行する異なるネットワークスタックの双方に同一のクラウドプロバイダＩＰアドレスを関連付けることができる。これら２つの名前空間２１０５及び２１１０は、２つの名前空間の各々に構成されるｖｅｔｈインタフェースを接続するｖｅｔｈ（仮想ネットワークインタフェース）ペアにより接続される。
従って、ワークロードアプリケーションが論理ネットワーク宛先（同じＶＰＣ内又は異なるＶＰＣ／データセンタ内）へパケットを送信する場合、パケット（クラウドプロバイダＩＰを送信元ＩＰとして有する）はｖｅｔｈペアを介して統合ブリッジ２１１５へ送信され、統合ブリッジ２１１５は必要な論理ネットワーク処理をパケットに実行する。また、統合ブリッジ２１１５は、ＶＰＣ上の別のＶＭ（ワークロードＶＭ又はゲートウェイＶＭ）へ送信されるパケットをカプセル化する。カプセル化ヘッダ内の送信元ＩＰは内部パケットの送信元ＩＰと同じである。しかし、いくつかの実施形態の論理ネットワークが更なるコンテキスト情報（例えば、統合ブリッジにより実行される論理処理に関する）を搬送するためにカプセル化ヘッダを使用するため、カプセル化が依然として使用される。同様に、ワークロードアプリケーションへ送信されるパケット（ＶＰＣ内のゲートウェイ又は他のＭＦＥから）は、内部ヘッダ及び外部ヘッダの双方に同じ宛先ＩＰアドレスを有する状態でＰＩＦブリッジ２１２０において受信される。統合ブリッジは、外側（カプセル化）ヘッダを除去し、何らかの論理コンテキストを識別し、ｖｅｔｈペアを介してワークロードアプリケーション（すなわち、ルート名前空間内のネットワークスタック）にパケットを出力する。従って、ＭＦＥ、パブリッククラウド転送要素、ゲートウェイ等によるパケット処理は、図１９及び図２０に示す種々の構成要素からの入力及び出力に関して図１９及び図２０に示すパケット処理と同様である。但し、ＭＦＥの内部動作は異なる。
ＶＩ． ＮＡＴ及び他のサービス
上記の第Ｖ節において、パケット処理の例は全て、パブリッククラウドＶＰＣ内のワークロードＤＣＮから発信されるイースト／ウエストトラフィック（ＶＰＣ又は異なるデータセンタ内であるが依然として論理ネットワークに接続する別のワークロードへ送信される）に関し、これらのワークロードＤＣＮ内で動作するＭＦＥにより実行される様々な種類の処理を中心に説明された。しかし、多くの論理ネットワークは、外部クライアントがアクセスできる必要があるワークロードを含む。例えば一般的な３層（ウェブサーバ、アプリケーションサーバ、データベースサーバ）設定では、少なくともウェブサーバがインターネットを介してクライアントに接続できる必要がある。通常、ＶＰＣサブネットはデータセンタ内の異なるテナントの多くのＶＰＣにより再利用されてもよい（及び種々の異なるデータセンタにおいて再利用されてもよい）プライベートＩＰアドレスであるため、発信パケットの送信元ＩＰアドレス（及びそれに対応して着信パケットの宛先ＩＰアドレス）を内部使用プライベートＩＰアドレスからパブリックＩＰアドレスに変更するために、ネットワークアドレス変換（ＮＡＴ）が一般に使用される。
更に、論理ネットワークがパブリックデータセンタ内で少なくとも部分的に実現される場合、パブリックＩＰアドレスへの実際の変換は、何れかの被管理転送要素ではなく、クラウドプロバイダのインターネットゲートウェイにより実行される必要がある場合がある。クラウドプロバイダゲートウェイは、データセンタ内でのパケットのラストホップであり、データセンタ内部にある間、パケットはプライベートＩＰアドレスを有する必要がある。しかし、クラウドプロバイダはワークロードアプリケーションが使用する内部ＩＰアドレス（論理スイッチポートに対応するアドレス）を割り当てていないため、パケットはこれらのアドレスを使用してプロバイダのゲートウェイへ送信されるべきでない。その代わりに、いくつかの実施形態のネットワーク制御システムにより管理されるＭＦＥは、内部ＩＰアドレスをクラウドプロバイダに登録されているアドレスに変換するために独自のＮＡＴを実行する。
異なる実施形態は、このネットワークアドレス変換を異なる方法で実現してもよい。いくつかの実施形態は、ゲートウェイデータパスの一部としてＮＡＴを適用する。この場合、ノースバウンドパケットは送信元ＭＦＥからゲートウェイにトンネリングされ、そこでＩＰアドレスは一貫した方法で２次ＩＰアドレスに変換される。いくつかの実施形態は、各内部ワークロードＩＰアドレスをクラウドプロバイダに登録されている２次ＩＰアドレスにマッピングするＮＡＴテーブルを使用する。その後、これら２次ＩＰアドレスは全て、ゲートウェイのノースバウンドインタフェースに関連付けられ、クラウドプロバイダのゲートウェイはこれら２次ＩＰアドレスからパブリックＩＰアドレスへの変換を実行する。集中型の場合、サービスチェイニンング（種々のミドルボックス処理のための第３者サービスアプライアンスへのパケットの送信）、侵入検出、ノース／サウスファイアウォール、ＶＰＮ、監査ロギング等の他のネットワークサービスがゲートウェイで更に適用されてもよい。更に、ゲートウェイがＮＡＴを実行する場合、何らかの負荷分散がゲートウェイにおいて更に実行される必要がある（この場合、プロバイダのゲートウェイが関係する限り、全てのトラフィックがゲートウェイインタフェースへ送信されるため、クラウドプロバイダが負荷分散を実行できない場合がある）。
他の実施形態は、送信元ＶＭ（着信トラフィックの場合は宛先ＶＭ）上で動作するＭＦＥにおいて、第１のレベルのＮＡＴを分散して実行する。この場合、発信パケットに対して、送信元ＭＦＥはアドレス変換を実行し、変換されたパケットをゲートウェイを経由せずにクラウドプロバイダゲートウェイへ直接送信する。そのため、送信元ＭＦＥは、自身のＶＴＥＰ ＩＰを使用してカプセル化するオーバーレイトラフィックと、カプセル化せずにクラウドプロバイダアンダーレイネットワークへ送信するノース／サウストラフィックとを区別する。このトラフィックは（両方向で）ゲートウェイを通過しないため、何らかのサービスチェイニング、侵入検出、ノース／サウスファイアウォール規則、ロギング等はワークロードＶＭ上で動作するＭＦＥにおいて実行される。
負荷分散のために、分散型内部ＮＡＴはクラウドプロバイダの既存の負荷分散特徴を使用できるようにする。複数のパブリックＩＰアドレスを使用する代わりに、単一のアドレス（又は少数のアドレスのみ）を使用することができ、全ての着信接続は当該アドレスへ送信される。クラウドプロバイダのインターネットゲートウェイ（又は特別な負荷分散アプライアンス）は負荷分散を実行し、これらの接続を異なるワークロードＶＭ（依然として独自の内部ＮＡＴを実行する必要がある）に均等に分散する。
Ａ． 集中型ＮＡＴ
集中型ＮＡＴの場合、ワークロードＶＭ内で動作するＭＦＥは、第Ｖ．Ｂ節において上述したのと同じオーバーレイモード方式で構成される。非オーバーレイモード又は移行されたＩＰアドレスを使用するオーバーレイモードでは、パケットの送信に使用されるＩＰアドレスがＶＭのネットワークインタフェースのＩＰアドレスと一致するため、ＮＡＴの内部レイヤは不要である。しかし、オーバーレイモードの場合、前述のように、ＮＡＴの内部レイヤは、送信元（又は着信パケットの場合は宛先）のＶＰＣ内のゲートウェイＶＭで動作するゲートウェイデータパスにより実行される。
図２２は、ワークロードアプリケーションから論理ネットワーク外部の宛先（例えば、インターネットクライアント、完全に別個の論理ネットワーク上の宛先等）へ送信されるノースバウンドパケットに対するクラウドプロバイダネットワークを介するパケット処理の一例を概念的に示す。図２２は、パブリックデータセンタ内の同じＶＰＣ内でＶＭを動作させる２つのホストマシン２２０５及び２２１０と、同じＶＰＣ内ではないが同じパブリックデータセンタ内で動作するパブリッククラウドゲートウェイ２２１５とを含む。ワークロードＶＭ２２２０は第１のホストマシン２２２０上で動作し、ワークロードアプリケーション２２２５及びＭＦＥ２２３０（オーバーレイモード）はワークロードＶＭ内で実行する。ゲートウェイＶＭ２２３５は第２のホストマシン２２１０上で動作し、ゲートウェイデータパス２２４０はＶＭ上で実行する（ここでは不図示の制御器、ＰＣＭ等に加えて）。前述のように、ＭＦＥ２２３０はオーバーレイモードで動作し、ワークロードが接続する論理スイッチポートに関連付けられた内部ＩＰアドレスＡと、クラウドプロバイダのＶＰＣサブネットに関連付けられたＶＴＥＰ ＩＰアドレスとを用いる。更に、ホストマシン２２０５及び２２１０はそれぞれ、各々のＶＭが接続する各々のパブリッククラウド転送要素２２４５及び２２５０を含む。上記の場合と同様に、これらのパブリッククラウド転送要素はソフトウェア仮想スイッチであってもよく、ネットワーク制御システムはこれらにアクセスできないよい。パブリッククラウドゲートウェイ２２１５は、別個の物理アプライアンス、ＶＭ又は他の何らかのフォームファクタとして動作してもよい。このゲートウェイ２２１５は、パブリックデータセンタ内に位置するＶＰＣとパブリックデータセンタの外側のマシンとの間の非ＶＰＮトラフィックを処理する。
示されるように、ワークロードアプリケーション２２２５は、ＶＭ２２２０上のＭＦＥ２２３０へパケット２２４５を送信する。前述の例のパケットと同様に、このパケット２２４５は、送信元ＩＰアドレス及び宛先ＩＰアドレス（並びに、各ＭＡＣアドレス）と、種々のヘッダと、ペイロードとを含む。送信元ＩＰアドレスＡは、ワークロードアプリケーション２２２５の内部ＩＰアドレスであり（ＶＭインタフェースＩＰアドレスと異なる）、宛先ＩＰアドレスＱは論理ネットワーク外部の宛先のアドレスである。
この時点で、ＭＦＥ２２３０は、論理スイッチ及び論理ルータ処理を実行し（単層論理ルータトポロジを仮定して）、パケットを論理ルータのアップリンクポートへ送信する必要があると判定する。このアップリンクポートはゲートウェイデータパス２２４０にマッピングされるため、ＭＦＥ２２３０はゲートウェイのＶＴＥＰにトンネリングされるパケット２２４５をカプセル化する。ＭＦＥ２２３０は、このカプセル化されたパケット２２５０をパブリッククラウド転送要素２２３５に接続するＶＭインタフェースから出力する。示されるように、このカプセル化に対する送信元ＩＰアドレスはＭＦＥのＶＴＥＰのアドレス（すなわち、ＶＭインタフェースのアドレス）であり、宛先ＩＰアドレスはゲートウェイデータパス２２４０のＶＴＥＰのアドレス（すなわち、トンネルトラフィックに使用されるゲートウェイＶＭインタフェースのアドレス）である。
パブリッククラウド転送ネットワークがホストマシン間のトンネリングを使用すると仮定して、パブリッククラウド転送要素２２３５は、独自のアンダーレイカプセル化を用いてパケット２２５０の２回目のカプセル化を行い、この二重カプセル化パケット２２５５を物理クラウドプロバイダネットワークを介して送信する。アンダーレイカプセル化は、ホストマシン２２０５のインタフェースのＩＰアドレスを送信元ＩＰアドレスとして使用し、ホストマシン２２１０のインタフェースのＩＰアドレスを宛先ＩＰアドレスとして使用する。
アンダーレイネットワークを通過した後、パケット２２５５はホストマシン２２１０により受信され、パブリッククラウド転送要素２２４０はアンダーレイカプセル化を除去する。転送要素２２４０は、オーバーレイカプセル化の宛先ＩＰアドレスに基づいて、トンネリングされるトラフィックに対するゲートウェイＶＭのインタフェースを介して、まだカプセル化されているパケット２２５０をゲートウェイＶＭ２２３５へ送信する。ゲートウェイデータパス２２４０は、カプセル化を除去し且つ宛先ＩＰアドレスが自身のアップリンクポートに対応することを識別することにより、当該パケット２０５５を処理する。
次に、ゲートウェイデータパス２２４０（例えば、データパス内の集中型ルーティング構成要素）は、パケットが論理ネットワークからその宛先Ｑへ送信されるためには、パケットにネットワークアドレス変換が必要であると判定する。そのため、ゲートウェイデータパスは、ＮＡＴテーブルを使用して、送信元アドレスＡがマッピングされるパブリッククラウドプロバイダにより提供されたＩＰアドレスを識別する。ゲートウェイ２２４０が負荷分散を実行していない場合、いくつかの実施形態はワークロードアプリケーション毎に１つのＩＰアドレスを割り当てる。集中型ＮＡＴの場合、着信パケットはパブリッククラウドゲートウェイ２２１５からワークロードＶＭに直接向けられるのではなくゲートウェイ２２４０に向けられるべきであるため、いくつかの実施形態はＶＭインタフェースＩＰを使用しない。その代わりに、テナントはパブリッククラウドプロバイダから割り当てられた多くの「２次」ＩＰアドレスを有する。これらは全て、ゲートウェイデータパス２２４０のアップリンクインタフェースにマッピングされる。この場合、ゲートウェイはＮＡＴを実行して、パケット２２４５の送信元ＩＰアドレスをＡからＢ１に変更し、宛先ＩＰアドレスをＱのまま変更しない。
ゲートウェイは、この変換されたパケット２２６０をパブリッククラウド転送要素２２４０に出力し、パブリッククラウド転送要素２２４０は、パブリッククラウドプロバイダアンダーレイトンネルのためにパケット２２６０をカプセル化し、クラウドプロバイダネットワークを介してパブリッククラウドゲートウェイ２２１５へカプセル化パケット２２６５を送信する。ここで、パブリッククラウドゲートウェイ２２１５は、種々の２次ＩＰアドレスをパブリックＩＰアドレスに（例えば、動的に割り当て可能なエラスティックＩＰに）マッピングする別個のＮＡＴテーブルを使用して独自のＮＡＴを実行する。この場合、パブリッククラウドゲートウェイのＮＡＴテーブルは、２次ＩＰアドレスＢ１をパブリックＩＰアドレスＣ１にマッピングするように指定する。その後、パブリッククラウドゲートウェイは、この新しい変換されたパケット２２７０をその宛先Ｑに向けて外部ネットワーク（例えば、インターネット）へ送信する。
図２３は、着信パケット２３００が送信元ＱからテナントのＶＰＣに関連付けられたパブリックＩＰアドレス（Ｃ１）のうちの１つへ送信される場合のパブリッククラウドゲートウェイ内の処理を示す。図２３では、パケットは前述の図２２に示した経路と逆の経路を通る。すなわち、パケット２３００は、パブリッククラウドゲートウェイ２２１５により受信され、パブリッククラウドゲートウェイ２２１５は、自身のＮＡＴテーブルに従って宛先アドレスに対してＮＡＴを実行する。いくつかの実施形態において、このＮＡＴテーブルは静的（例えば、２次ＩＰとパブリックＩＰとの間の１：１静的マッピング）である。
パブリッククラウドゲートウェイは、宛先ＩＰアドレスＣ１をＢ１に変換し、変換されたパケットをアンダーレイに出力し、アドレスＢ１に関連付けられたゲートウェイＶＭ２２３５へカプセル化パケット２３０５を送信する。パブリッククラウド転送要素２２４０は、アンダーレイカプセル化を除去し、このパケット２３１０をゲートウェイのアップリンクインタフェースへ送信する。ゲートウェイデータパス２２４０は、それ独自の内部ＮＡＴ処理を実行して、２次ＩＰアドレスＢ１を新しい宛先アドレスＡに変換する。更に、ゲートウェイデータパス２２４０は、論理ネットワーク処理を実行して宛先アドレスＡがＭＦＥ２２２０に位置する論理スイッチポートにマッピングされることを識別し、従って、独自のサウスバウンドインターフェースを送信元ＩＰとして使用し且つＭＦＥ２２２０のＶＴＥＰ ＩＰアドレスを宛先ＩＰとして使用して、変換されたパケットをカプセル化する。その後、このパケットは何らかのＶＰＣ内パケットの経路を通り、ホストマシン２２１０上のパブリッククラウド転送要素２２４０により再度カプセル化され、ホストマシン２２０５上のパブリッククラウド転送要素２２３５によりカプセル解除され、ＭＦＥ２２２０に出力され、ＭＦＥ２２２０はオーバーレイカプセル化をカプセル解除し、何らかの必要なセキュリティ処理を実行して、パケットをワークロードアプリケーションに出力する。
図２４は、ワークロードアプリケーション２２２５と同じＶＰＣ上の異なるワークロードアプリケーションから送信されるパケットに対する図２２のクラウドプロバイダネットワークを介するパケット処理を示す。図２４は、ゲートウェイＶＭ２２３５を有するホストマシン２２１０と、パブリッククラウドゲートウェイ２２１５と、ＶＭ２４０５が動作するホストマシン２４００とを含む。ワークロードアプリケーション２４１０及びＭＦＥ２４１５はＶＭ２４０５上で実行する。ワークロードアプリケーション２４１０は、それが接続する論理スイッチに関連付けられた内部ＩＰアドレスＤを有し、ＭＦＥ２４１５のＶＴＥＰは異なるＩＰアドレスを有する。
本例において、ワークロードアプリケーション２４１０は送信元アドレスＤを用いてパケット２４２０を送信する。このパケットは、ゲートウェイデータパス２２４０に到達するまで、図２２のパケット２２４５と同様の経路を通る。当該データパス２２４０は、送信元ＮＡＴがパケット２２４５に必要であると識別し、従って、自身の内部ＮＡＴテーブルを調べて、ＩＰアドレスＡがマッピングされるアドレスとは異なる２次ＩＰアドレスＢ２にアドレスＤをマッピングする必要があると判定する。ゲートウェイデータパスは、前述の例とは異なるＩＰアドレスを使用して、変換されたパケット２４２５を同じアップリンクインタフェースから送信する。その結果、変換されたパケット２４２５が送信元アドレスＢ２を用いてパブリッククラウドゲートウェイ２２１５に到達すると、パブリッククラウドゲートウェイ２２１５はこの送信元アドレスを異なるパブリックＩＰアドレスＣ２に変換し、パケット２４３０を外部ネットワークへ送信する。
上記の図は、少なくともいくつかのクラウドプロバイダの場合と同様に、パブリッククラウドプロバイダがＤＣＮの単一のインタフェースに対して複数のＩＰアドレスを許可すると仮定する。クラウドプロバイダがこの特徴を有効にしない場合、集中型ＮＡＴを使用する際に１つのパブリックＩＰアドレスしか使用できない。この場合、アウトバウンド接続のみが開始された場合、複数の内部ＩＰアドレスが使用されてもよく、ゲートウェイのＮＡＴテーブルはステートフル変換規則を使用して戻りトラフィックに正確な宛先ＩＰアドレスを割り当てる。インバウンド接続の発信の場合、異なるワークロードアプリケーションが異なるＬ４ポートで実行する限り、トラフィックを正確なアプリケーション／ＶＭに転送するようにＬ４ポートベースのＤＮＡＴ規則をゲートウェイにおいて構成できる。
Ｂ． 分散型ＮＡＴ
いくつかの実施形態の分散型ＮＡＴの場合、ワークロードＤＣＮ内で動作するＭＦＥも上記と同じオーバーレイモードで構成されているが、これらのＭＦＥはノース／サウスパケットに対するＮＡＴを更に実行する。その結果、ＶＰＣ内で動作するゲートウェイにノース／サウストラフィックを送信する必要がない。図２５は、別々のＩＰアドレスを用いてオーバーレイモードで構成され、ノース／サウストラフィックに対するＮＡＴを更に実行する被管理転送要素２５００を有するＶＭ２５０５を概念的に示す。ＭＦＥ２５００は図１８に示すＭＦＥ１８００と同様に構成され、ワークロードアプリケーション２５１０は内部ＩＰアドレスを有する内部インタフェースを介して統合ブリッジ２５１５に接続され、統合ブリッジはパケットがＰＩＦブリッジ２５２０上のＶＴＥＰへ送信されるオーバーレイポートを有する。ＶＴＥＰは、クラウドプロバイダにより提供される別個のＩＰアドレス有し、これはＶＭのインタフェースに関連付けられる。
この場合、パッチポートが統合ブリッジ２５１５とＰＩＦブリッジ２５２０との間に更に構成される点が異なる。統合ブリッジは、発信パケットに対して論理処理を実行し、イースト／ウエストトラフィックの場合（例えば、宛先が論理ルータのアップリンクポート以外の論理ポートに対応すると識別される場合）、パケットをカプセル化してオーバーレイポートから送信する。一方、ノース／サウスパケット（論理ルータのアップリンクポートにマッピングされる）の場合、統合ブリッジ２５１５は代わりに、これらのパケットに対して送信元ＮＡＴを実行し、カプセル化せずにパッチポートを介してＰＩＦブリッジ２５２０へ直接送信する（非オーバーレイの場合のトラフィックと同様に）。いくつかの実施形態において、ＭＦＥは更に、接続に対する戻りトラフィックを処理するためのステートフル規則を作成する。他の実施形態において、単一の内部ＩＰアドレスからクラウドプロバイダにより割り当てられたＩＰアドレスへの単独マッピングが全ての接続に対して使用されるため、ステートフル規則は不要である。いくつかの実施形態において、ＮＡＴアドレスはＶＴＥＰ ＩＰアドレスと同じであってもよく、そのため、テナントは、クラウドプロバイダに複数のＩＰアドレスを割り当てさせる必要がない。他の実施形態において、２つのＩＰアドレスは異なり、その場合、ＶＭは複数のインタフェースを有するか又は同じインタフェースに対して複数のＩＰアドレスを有する。
着信トラフィックの場合、ＰＩＦブリッジ２５２０は、パケットがトンネルトラフィックであるか又は外部送信元からのサウスバウンドトラフィックであるかを識別する。いくつかの実施形態は、ゲートウェイを含むＶＰＣ内の他のＶＴＥＰに対応する限定されたＩＰアドレスセットの中の宛先ＩＰアドレスをパケットが有するかを識別して、着信トラフィックをＶＰＣ内オーバーレイトラフィックとして分類する。オーバーレイトラフィックは、統合ブリッジ２５１５がトラフィックをオーバーレイポートで受信してパケットをカプセル解除するようにＶＴＥＰへ送信され、サウスバウンドトラフィックは、パッチポートを介して統合ブリッジ２５１５へ送信される。このサウスバウンドトラフィックの場合、統合ブリッジ２５１５は、格納状態（例えば、戻りトラフィックの場合、状態が格納されているか）に基づいて又は自身のＮＡＴ規則を使用して（例えば、新規に開始された着信接続の場合又はステートフルＮＡＴルールが格納されていない場合）、宛先ＮＡＴを実行する。
図２６及び図２７は、分散型ＮＡＴ設定におけるノースバウンド及びサウスバウンドに対するクラウドプロバイダネットワークを介するパケット処理の例を示す。詳細には、図２６は、ワークロードアプリケーションから論理ネットワーク外部の宛先（例えば、インターネットクライアント、完全に別個の論理ネットワーク上の宛先等）へ送信されるノースバウンドパケットに対するパケット処理の一例を示す。図２６は、ＶＰＣ内で動作するＶＭをホストする単一のホストマシン２６０５のみを含む。ワークロードＶＭ２６１０はホストマシン２６０５上で動作し、ワークロードアプリケーション２６１５（内部ＩＰアドレスＡを有する）及びＭＦＥ２６２０はワークロードＶＭ内で実行する。前述の例と同様に、ホストマシン２６０５はパブリッククラウド転送要素２６２５を更に含み、これは、ネットワーク制御システムがアクセスできないソフトウェア仮想スイッチであってもよい。更に、図２６は、パブリックデータセンタ内に位置するＶＰＣとデータセンタ外のマシンとの間の非ＶＰＮトラフィックを処理するための別個の物理アプライアンス、ＶＭ等として動作してもよいパブリッククラウドゲートウェイ２６３０を示す。
示されるように、ワークロードアプリケーション２６１５は、ＶＭ２６０５上のＭＦＥ２６２０へパケット２６３５を送信する。このパケットは、送信元ＩＰアドレスＡ（論理スイッチポートに関連付けられたワークロードアプリケーションの内部ＩＰアドレス）とリモートの外部の宛先の宛先ＩＰアドレスＱとを有する。ＭＦＥ２６２０は論理スイッチ／ルータ処理を実行し、この宛先アドレスをアップリンク論理ルータポートにマッピングする。この場合、ＭＦＥは当該論理ポートへ送信されるパケットに対してＮＡＴを実行するように構成され、従って、ＮＡＴ設定に従って送信元ＩＰアドレスをＡからＮに変換する。上述したように、ＩＰアドレスＮは、ＶＰＣ内のトンネリングに使用されるＶＴＥＰアドレスと同じでもよく、あるいはクラウドプロバイダにより同様に割り当てられた異なるＩＰアドレスであってもよい。
次に、ＭＦＥ２６２０は、この変換されたパケット２６４０をカプセル化せずにパブリッククラウド転送要素２６２５へ送信する。当該パケットは転送要素２６２５によりカプセル化され、アンダーレイ（パブリッククラウド）ネットワーク上でパブリッククラウドゲートウェイ２６３０へ直接送信され、それにより、集中型ＮＡＴの場合にノース／サウストラフィックに必要なＶＰＣゲートウェイをスキップする。パブリッククラウドゲートウェイ２６３０は独自のＮＡＴテーブルを有し、アンダーレイカプセル化を除去した後、送信元ＩＰアドレスをＮからテナントに登録されているパブリックＩＰアドレスであるＭに変換する。
図２７は、パブリッククラウドゲートウェイ２６３０を介してＩＰアドレスＱを有する外部送信元からワークロードアプリケーション２６１５へ送信されたサウスバウンドパケットに対する処理を示す。図２７において、パブリッククラウドゲートウェイ２６３０は、送信元ＩＰアドレスＱと、上述したように）ワークロードＶＭ２６１０に関連付けられたパブリックＩＰアドレスである宛先ＩＰアドレスＭとを有するパケット２７０５を受信する。このパケットは、図２６で説明したパケットと反対の経路を通る。パブリッククラウドゲートウェイ２６３０は、ＮＡＴを実行して宛先ＩＰアドレスをプライベートＩＰアドレスＮに変換し、パケットをＶＭ２６１０に転送する（プロバイダアンダーレイネットワーク上で）。パブリッククラウド転送要素２６２５がアンダーレイカプセル化を除去した後、ＭＦＥ２６２０はパケットがカプセル化されていないサウスバウンドパケットであることを識別し、パケットに論理ルータ／論理スイッチ処理を実行する。論理ルータ処理の一部として、ＭＦＥ２６２０は宛先ＩＰアドレスをＮからワークロードアプリケーション２６１５のＩＰアドレスであるＡに変換する。その後、ＭＦＥ２６２０は当該パケットをワークロードアプリケーション２６１５に出力する。
図２８は、ワークロードＶＭ上のＭＦＥがオーバーレイモードで動作し且つ分散型ＮＡＴを実行するように構成される場合に、発信パケットを処理するためにＭＦＥにより実行される処理２８００を概念的に示す。そのようなＭＦＥの一例は、図２５に示すＭＦＥ２５００である。処理２５００は概念的な処理であり、ＭＦＥ（特に、フローベースＭＦＥ）が図示されるような判定を行わなくてもよいことが理解されるべきである。その代わりに、そのようなＭＦＥは自身のフローテーブルを介してパケットを処理し、一致したフローエントリに従って動作を実行する。すなわち、特定の動作を行うかに関するイエス／ノーの決定をＭＦＥが評価するのではなく、行うべき動作又は動作セットは処理の結果により指示される。しかし、処理２８００は、与えられた異なる種類のパケットに対してＭＦＥが実行する異なる動作を表す。
示されるように、処理２８００は、ローカルワークロードアプリケーションからパケットを受信する（２８０５において）ことにより開始する。ＭＦＥがオーバーレイモードで動作しているため、このパケットは送信元アドレスとして内部ＩＰアドレスを有する（ＭＦＥは不正アクセスされていないと仮定する）。次に、処理は、自身の構成（すなわち、ローカル制御エージェントによりプッシュダウンされた構成規則）に従って論理ネットワーク／セキュリティ処理を実行する（２８１０において）。これは、論理スイッチ及び／又は論理ルータ処理、分散型ファイアウォール処理等を含んでもよい。
処理２８００は、パケットの宛先がＭＦＥが動作するＶＭと同じＶＰＣ内であるかを判定する（２８１５において）。パケットの宛先が同じＶＰＣ内である場合、処理は、カプセル化に対する送信元ＩＰアドレスにローカルＶＴＥＰ ＩＰアドレスを用い且つ宛先ＩＰアドレスにＶＰＣ内の宛先ＭＦＥのＶＴＥＰを用いてパケットをカプセル化する（２８２０において）。本処理の一例は、上述した図１９に示される。
宛先が同じＶＰＣ内でない場合、処理２８００は、宛先が外部の宛先であるか（すなわち、パケットがノースバウンドパケットであるか）を判定する（２８２５において）。宛先が外部の宛先でない場合、パケットは異なるＶＰＣ又はデータセンタ内に位置する論理ポートにアドレス指定され、処理は、カプセル化に対する送信元ＩＰアドレスにローカルＶＴＥＰ ＩＰアドレスを用い且つ宛先ＩＰアドレスにＶＰＣ内のゲートウェイのＶＴＥＰを用いてパケットをカプセル化する（２８３０において）。そのような処理の一例は、同様に上述した図２０に示される。いずれの状況においても、ＭＦＥは、論理ネットワーク内の論理スイッチポート（必ずしもローカルワークロードアプリケーションと同じ論理スイッチ上にあるとは限らない）をパケットの宛先として識別し、パケットを別のローカルＶＭ又はゲートウェイにトンネリングする（後者の場合、それにより、ゲートウェイはパケットを最終的な宛先に向けて送信できる）。
しかし、宛先が外部の宛先である場合（例えば、宛先ＩＰアドレスがアップリンク論理ルータポートにマッピングされる場合）、処理は、送信元ＩＰアドレスを内部ワークロードアプリケーションＩＰアドレスからクラウドプロバイダにより割り当てられたＩＰアドレスに変更するためにＮＡＴを実行する（２８３５において）。このＩＰアドレスは、ローカルＶＴＥＰ ＩＰアドレスと同じであってもよいが、この場合、ＧＥＮＥＶＥ、ＳＴＴ等のトンネルヘッダにおける送信元ＩＰアドレスとしてではなく、内部パケットの送信元ＩＰアドレスとして（カプセル化せずに）使用される。本処理の一例は、図２６に示される。最後に、処理は、ホストマシン上のクラウドプロバイダ転送要素へパケットを送信し（２８４０において）、パケットはクラウドプロバイダのネットワーク上で送信される。
ここで示されるように、分散型ＮＡＴを使用することにより、いくつかの実施形態において、ストレージサービス等の外部クラウドプロバイダサービスとのシームレスな統合が可能になる。これらの外部リソースは、自身にアクセスしているＶＰＣ上のＤＣＮを容易に判定できるため、識別に基づくポリシーを使用してこれらのリソースへのアクセスを制御できる。集中型ＮＡＴの場合、ワークロードＤＣＮのインタフェースに対応しないＩＰアドレスを使用して、そのようなリソースの全てにゲートウェイを介してアクセスできる。更に、分散型ＮＡＴを使用することにより、多くのクラウドプロバイダにより提供される負荷分散サービスと容易に統合できる。
図２９は、ワークロードＶＭ内で動作するＭＦＥによる分散型ＮＡＴと共にパブリッククラウドゲートウェイ２９００における負荷分散の使用を示す。図２９は、ＶＰＣ内でＶＭを動作させる２つのパブリッククラウドホストマシン２９０５及び２９１０を示す。詳細には、第１のＶＭ２９１５は第１のホストマシン２９０５上で動作し、第２のＶＭ２９２０は第２のホストマシン２９１０上で動作する。第１のＶＭ２９１５は内部ＩＰアドレスＡを有するワークロードアプリケーション２９２５を実行し、第２のＶＭ２９２０は内部ＩＰアドレスＢを有するワークロードアプリケーション２９３０を実行する。本例において、２つのワークロードアプリケーションは同一の外部アクセス可能アプリケーションのインスタンスである（例えば、複数のウェブサーバーインスタンス）。更に、ＭＦＥ２９３５及び２９４０がそれぞれ２つのＶＭ２９１５及び２９２０上で実行され、ホストマシン２９０５及び２９１０はそれぞれパブリッククラウド転送要素２９４５及び２９５０を含む。
パブリッククラウドゲートウェイ２９００（又はＶＰＣに対するサウスバウンドトラフィックを誘引するためにパブリッククラウドにより提供される別個の負荷分散アプライアンス）は、２つのパケット２９５５及び２９６０を受信する。これらのパケットの双方は宛先ＩＰアドレスＸ（ワークロードアプリケーション２９２５及び２９３０に関連付けられたパブリックＩＰアドレス）を有するが、異なる送信元Ｑ及びＲからのパケットである。従って、パブリッククラウドゲートウェイ２９００が受信すると、当該ゲートウェイは、これら２つのワークロード間（及び場合によっては更なるＶＭ上の更なるインスタンス間）でトラフィックを分散させるために負荷分散／宛先ネットワークアドレス変換動作を実行する。
種々の要因（ＩＰアドレス及び／又は他のヘッダのハッシュ、異なるワークロードにおける現在のトラフィック負荷の監視等）に基づいて、パブリッククラウドゲートウェイ２９００は第１のパケット２９５５に対する宛先ＩＰアドレスＹ及び第２のパケット２９６０に対する宛先ＩＰアドレスＺを選択する。これら２つのＩＰはそれぞれ、ＶＭ２９１５及び２９２０のクラウドプロバイダ割り当てＶＭインタフェースに対応し、従って、ゲートウェイは２つのホストマシン２９０５及び２９１０にパケットをトンネリングする。これらが接続における最初のパケットであると仮定した場合、ゲートウェイは更に、接続に対する何らかの発信トラフィックが同じワークロードアプリケーションへ送信されるように、接続及びＮＡＴマッピングを格納する（いくつかの実施形態において、それらが最初のパケットでない場合、ゲートウェイは以前に格納された状態に従ってパケットを処理する）。
ＭＦＥ２９３５及び２９４０がパケットを受信すると、それらはトラフィックをカプセル化されていないサウスバウンドトラフィックと認識し、従って、パケットに対して独自のＮＡＴを実行する。これらのＮＡＴ動作は、第１のＭＦＥ２９３５において第１のパケットの宛先ＩＰアドレスＹをＡに変換し、第２のＭＦＥ２９４０の第２のパケットに対して宛先ＩＰアドレスＺをＢに変換する。
負荷分散をこのように使用することにより、クラウドプロバイダによりサポートされている場合に新規のワークロードＶＭの自動スケーリングも可能になる。自動スケーリングでは、ワークロードの負荷が高すぎると、クラウドプロバイダは同じアプリケーションを実行する新規のインスタンスを自動的に作成し、プロバイダの負荷分散器は、負荷分散を決定する際に新規のインスタンスを考慮し始める。第ＩＩ節で上述したように、新規のＶＭがクラウドプロバイダインベントリに現れると、ＰＣＭはその存在を識別し、ネットワーク制御システムが新規のインスタンスに必要な構成データを配布できるように、ネットワーク制御システムに通知する。
ＶＩＩ． 分散型ネットワーク暗号化
いくつかの実施形態は、パブリックデータセンタ内において、ネットワーク制御システムにより管理される分散型ネットワーク暗号化（ＤＮＥ）を使用することを可能にする。いくつかの実施形態において、ＤＮＥは同じＶＰＣ内又はピア接続されたＶＰＣ内で動作するＤＣＮ間でのみ可能であるが、他の実施形態において、ＤＮＥは論理ネットワークの論理ポートに接続されたいずれか２つのＤＣＮ間で可能である（ワークロードＤＣＮとゲートウェイとの間を含む）。
いくつかの実施形態において、分散型ネットワーク暗号化は、ネットワーク制御システム管理者がパケットに対する暗号化規則及び／又は整合性規則を設定できるようにする。これらの規則は、（ｉ）規則が適用されるパケットと、（ｉｉ）それらのパケットに対する暗号化要件及び／又は整合性要件とを定義する。いくつかの実施形態は、規則が適用されるパケットをパケットの送信元及び宛先に関して定義する。これらの送信元エンドポイント及び宛先エンドポイントは、ＩＰアドレス又はアドレスの範囲、ＭＡＣアドレス、論理スイッチポート、仮想インタフェース、Ｌ４ポート番号及びその範囲等、並びにそれらの組み合わせに基づいて定義されてもよい。
更に、各規則は、送信元及び宛先の特徴に合致するパケットが暗号化（場合によっては認証を伴う）を必要とするか、認証のみを必要とするか、あるいはプレーンテキスト（ブロードキャストパケットを許可するための設定として使用されてもよい）を必要とするかを指定する。暗号化は、パケットの一部分又は全部（例えば、内部パケット全体、Ｌ４以上のヘッダのみ、トンネリングされるパケットの場合の内部／外部パケット全体等）を暗号化するために鍵を使用する必要があるが、認証はパケットを暗号化せず、送信中にパケットが改竄されていないことを検証するために宛先が使用できる認証データを生成するために鍵を使用する（例えば、パケット又はその一部分のハッシュ）。
ネットワーク内のＭＦＥにＤＮＥ規則を実現させるために、ネットワーク制御システムはＭＦＥに鍵をセキュアに配布する必要がある。いくつかの実施形態は、ネットワーク制御システムのＤＮＥ態様と通信し且つそのＶＰＣ内のワークロードＤＣＮ内で動作するＭＦＥに鍵を配布するために、ゲートウェイＤＣＮ内のＤＮＥモジュールを使用する。図３０は、いくつかの実施形態のそのようなＤＮＥ規則／鍵配布システム３０００と、パブリックデータセンタ内のＭＦＥ上でＤＮＥ規則を実現するためのデータの流れとを概念的に示す。
ＤＮＥ規則／鍵配布システム３０００は、管理プレーン３００５、中央制御プレーン３０１０及び鍵マネージャ３０１５をプライベートデータセンタ内に含む。これらの構成要素は、パブリックデータセンタの別個のＶＰＣ（又は同じＶＰＣ）に位置することもできるが、ＤＮＥシステムにおいて使用するために鍵マネージャ３０１５がマスタ鍵をセキュアに格納するため、ネットワーク管理者は一般に、これらの構成要素を自身のプライベートデータセンタに保持することを望む。これらの構成要素の動作の簡単な説明を本明細書に示すが、チケット及び鍵配布処理は、参考として上記に取り入れられる米国特許仮出願第６２／３８０，３３８号に更に詳細に記載されている。
管理プレーン３００５及び中央制御プレーン３０１０は、ネットワーク転送規則及びセキュリティ規則を配布する際のそれらの動作に関連して上記で説明された。転送構成と同様に、管理プレーン３００５がＤＮＥ規則を受信する（例えば、管理プレーンＡＰＩを用いて構成されたクラウド管理プラットフォームから）と、それは当該規則をフォーマットし、規則を中央制御プレーン３０１０に渡す。中央制御プレーン３０１０は、規則を必要とするパブリックデータセンタＶＰＣ内の何らかのゲートウェイ制御器を含むローカル制御器を識別するために、規則の適用範囲の計算を実行する。
いくつかの実施形態の鍵マネージャ３０１５は、ネットワーク制御システム３０００により管理されるＭＦＥにより使用される暗号鍵を格納するセキュアな記憶装置である。いくつかの実施形態において、鍵マネージャ３０１５は、ハードウェアアプライアンス、プライベートデータセンタ内でセキュアに動作するＶＭ等である。いくつかの実施形態において、鍵マネージャは、管理容易性のために、構造及び機構を指定して鍵のグループを定義し、鍵にアクセスするための種々のセキュリティ制御（例えば、アクセス制御及び認証）を提供する。いくつかの実施形態において、認証機構は、公開鍵基盤（ＰＫＩ）証明書、ユーザ資格情報及び／又は共有シークレットを含む。また、いくつかの実施形態の鍵マネージャは、悪意のある要求者の脅威に対処するために要求者の認証を強化する。
鍵マネージャ３０１５は管理プレーン３００５に登録し、管理プレーン３００５、中央制御プレーン３０１０（すなわち、中央制御プレーンクラスタ内の１つ以上の制御器）及びローカル制御器（何らかのゲートウェイ制御器を含む）の証明書を取得する。登録時に鍵マネージャ３０１５にこれらの証明書を取得させることにより、ネットワーク制御システム３０００は、ローカル制御器が特定のＤＮＥ規則のための鍵を要求する際の重複した通信（すなわち、鍵を要求するローカル制御器が有効な制御器であることを検証するための通信）を回避する。
いくつかの実施形態において、鍵マネージャ３０１５は、鍵の要求に基づいて生成された鍵を格納することに加えて、鍵の要求に基づいて鍵を生成する。同一の鍵に対する後続の要求が必要である場合（例えば、鍵を必要とするＶＭの電源が切られて再度投入される場合又は再起動する場合）、格納された鍵が使用されてもよい。いくつかの実施形態は、パスワード保護された読み出し専用ファイルにおいてセキュリティ保護され且つ管理者からの入力を用いる初期段階において鍵マネージャ３０１５のメモリにロードされる鍵用暗号鍵を用いて暗号化された鍵マネージャ３０１５に鍵を格納する。
パブリックデータセンタＶＰＣ内において、システム３０００は、ゲートウェイ制御器３０２５及びＤＮＥモジュール３０３０を有するゲートウェイＶＭ３０２０と、ワークロードＶＭ３０３５とを含む。ゲートウェイＶＭ３０２０及びそのゲートウェイ制御器３０２５は上記で詳細に説明された。また、ゲートウェイＶＭ３０２０は、第ＩＩ節で上述したゲートウェイデータパス、パブリッククラウドマネージャ等の種々の他の特徴を更に実行してもよいことが理解されるべきである。
ＤＮＥモジュール３０３０は、ゲートウェイＶＭ３０２０のＶＰＣ内の何らかのＭＦＥが必要とする何らかの鍵を処理する責任を有する。ＤＮＥモジュール３０３０は、ＶＰＣ内のＭＦＥに対する暗号鍵を管理するために鍵マネージャ３０１５と対話する。中央制御プレーン３０１０がＶＰＣ内で動作する何らかのワークロードとの間で送受信されるパケットに対する暗号化及び／又は認証の要件を指定する規則を受信すると、中央制御器はこれらの規則をゲートウェイ制御器３０３５に配布する）。いくつかの実施形態の暗号化規則は、鍵マネージャ３０１５から鍵を取得するために制御器により使用されるチケットを含む。ＤＮＥモジュール３０３０又はゲートウェイ制御器３０２５は、このチケットを使用して鍵マネージャ３０１５に鍵を要求し、鍵マネージャ３０１５は暗号化規則に対するマスタ鍵を提供する。ＤＮＥモジュール３０３０はマスタ鍵を受信し、この鍵を使用して規則に対するセッション鍵を生成する。いくつかの実施形態において、セッション鍵は、マスタ鍵と暗号化を実行することになる２つのエンドポイントに特有の１つ以上の更なるパラメータとの関数として生成される。ＤＮＥモジュール３０３０は（例えば、ゲートウェイ制御器３０２５を介して）、生成されたセッション鍵を適切なエンドポイントに配布する。
ワークロードＶＭ３０３５は、パブリックデータセンタの同一のＶＰＣ内で動作する複数のワークロードＶＭのうちの１つである。ＶＭは、ローカル制御エージェント３０４０と、ＤＮＥ規則を実際に実現するＭＦＥ及びワークロードアプリケーション等（不図示）とを含む。
システム３０００の構成要素の動作について説明したので、次に図３０に示すデータフローの例を説明する。丸囲み文字１Ａで示すように、管理プレーン３００５は中央制御プレーン３０１５にＤＮＥ規則３０５０を渡す。このＤＮＥ規則３０５０は、管理プレーンのＡＰＩを介して入力として（例えば、おそらくクラウド管理インタフェースを介してネットワーク管理者から）受信されたものである。ＤＮＥ規則３０５０は、上述したように、規則が適用されるパケットと、（ｉｉ）それらのパケットに対する暗号化要件及び／又は整合性要件とを指定する。いくつかの実施形態において、規則は、使用する暗号化の種類、使用時に鍵を回転させる（すなわち、特定の方法で変更する）頻度、特定の時間が経過後に鍵を無効にするか等のポリシーを更に含んでもよい。
中央制御プレーン３０１０は当該規則３０５０を受信し、その適用範囲を判定する。規則が特定の送信元エンドポイント及び宛先エンドポイントを有する場合、適用範囲はそれらのエンドポイントの２つのファーストホップＭＦＥのみであってもよい。一方、規則は暗号化される特定の論理ポートから送受信される全てのトラフィックを指定してもよく、その場合、特定の論理ポートと通信している可能性のある全てのエンドポイントに対するファーストホップＭＦＥが規則を受信する必要がある。本例では、少なくともＶＭ３０３５上で動作しているアプリケーションが規則のエンドポイントであるため、中央制御プレーンは、その規則の適用範囲がゲートウェイ制御器３０２５を含むと判定する。丸囲み文字１Ｂで示すように、中央制御プレーン３０１０は当該ＤＮＥ規則３０５０をゲートウェイ制御器３０２５に配布する。ゲートウェイ制御器３０２５は、そのＶＰＣにおける規則の適用範囲を判定し、当該規則を必要とする１つのＭＦＥとしてワークロードＶＭ３０３５上のＭＦＥを識別し（ＶＰＣ内の暗号化の場合、少なくとも１つの更なるエンドポイントが規則を必要とし、ＶＰＣ外の暗号化の場合、ゲートウェイＶＭ上のデータパスが規則を必要とする）、丸囲み文字１Ｃで示すように、ＶＭ３０３５上のローカル制御エージェント３０４０に規則３０５０を配布する。
規則自体に加えて、いくつかの実施形態では、丸囲み文字２で示すように、ＣＣＰはゲートウェイ制御器３０２５にチケット３０５５を配布する。いくつかの実施形態において、暗号鍵チケットは、鍵識別子及びセキュリティパラメータインデックス（ＳＰＩ）に基づいてゲートウェイ制御器に対して生成される。いくつかの実施形態において、セキュリティパラメータインデックスは、鍵長、暗号化アルゴリズム等のＤＮＥが使用される接続（例えば、２つのエンドポイント間の）のセキュリティ性を識別する。当該チケット３０５５は、鍵マネージャ３０１５から鍵を検索するためのセキュリティトークンとして機能する。いくつかの実施形態において、チケットは、鍵識別子、ローカル制御器識別子、有効期限及び署名を含む。
チケット３０５５を受信すると、ゲートウェイ制御器はＤＮＥモジュール３０３０にチケット（不図示）を渡し、ＤＮＥモジュール３０３０は、丸囲み文字３で示すように、鍵マネージャ３０１５へ鍵要求３０６０を送信する。いくつかの実施形態において、実際はゲートウェイ制御器３０２５が鍵マネージャ自体へ鍵要求を送信する。要求は、ゲートウェイ制御器が中央制御プレーンにより鍵の受信を認可されていることを認定するチケット又はチケットからの情報を含む。鍵マネージャ３０１５は、当該要求を検証し、丸囲み文字４で示すように、ゲートウェイＶＭ３０２０へマスタ鍵３０６５を送信する。図３０では、ＤＮＥモジュール３０３０が当該マスタ鍵３０６５を受信する。いくつかの実施形態では、マスタ鍵３０６５はゲートウェイ制御器３０２５へ送信され、ゲートウェイ制御器３０２５がＤＮＥモジュール３０３０に鍵を渡す。
ＤＮＥモジュール３０３０は、マスタ鍵を使用して、ＶＭ３０３５（及び鍵を使用する予定の他の何らかのＶＭ）におけるＭＦＥに対するセッション鍵を生成する。いくつかの実施形態において、セッション鍵は、マスタ鍵と、接続の２つのエンドポイントに関連するＳＰＩ及び／又は２つのエンドポイントのＶＴＥＰ ＩＰアドレスと、乱数との関数である。いくつかの実施形態において、規則が複数の接続（例えば、送信元Ａから宛先Ｂ又は宛先Ｃのいずれかへ）を指定する場合、ＤＮＥモジュール３０３０は、２つのエンドポイント間の各接続に対して異なるセッション鍵を生成する。すなわち、上記の例では、ＡとＢとの間の接続及びＡとＣとの間の接続に対する２つのセッション鍵が生成される。いくつかの実施形態は対称鍵暗号化を使用し、その場合、同一のセッション鍵が接続の各エンドポイントに配布される。丸囲み文字５で示すように、ＤＮＥモジュール３０３０は、ローカル制御エージェント３０４０にセッション鍵３０７０を配布する（直接又はゲートウェイ制御器を介して）。
いくつかの実施形態において、エージェント上での暗号化はＭＦＥ自体により（すなわち、統合ブリッジ又はＰＩＦブリッジにより）実行されない。その代わりに、ワークロードＶＭ上で動作するＤＮＥモジュールがネットワークスタック（すなわち、ＶＭインタフェースのＩＰアドレスに対して、統合ブリッジとＰＩＦブリッジとの間のネットワークスタック）と統合する。ネットワークスタックのＩＰｓｅｃ機能性は適切なセッション鍵を使用して、発信パケットの整合性情報を暗号化及び／又は生成し、着信パケットを復号化及び／又は認証する。ＭＦＥにおけるフローエントリは、暗号化／復号化及び／又は認証を所定のパケットに対して実行する必要があるかを示す。
図３１は、パブリックデータセンタＶＰＣのゲートウェイにおいてＤＮＥ鍵を管理するためのいくつかの実施形態の処理３１００を概念的に示す。いくつかの実施形態において、処理３１００は、ＶＰＣ内のゲートウェイＶＭにより（例えば、ゲートウェイＶＭのゲートウェイ制御器及び／又はＤＮＥモジュールにより）実行される。いくつかの実施形態において、ゲートウェイＶＭは、受信したＤＮＥ規則毎に当該処理又は同様の処理を実行する。
示されるように、処理３１００は、ＶＰＣ内の少なくとも１つの論理ポートに対するＤＮＥ規則を指定する中央制御器から規則を受信する（３１０５において）ことにより開始する。上述したように、中央制御器はゲートウェイ制御器がＶＰＣ内で動作する全てのワークロードに対するローカル制御器であると見なす。ＤＮＥ規則は、ＶＰＣ内の２つのエンドポイント間の接続、ＶＰＣ内の複数のエンドポイント間の複数の接続、ＶＰＣ内のエンドポイントと他の場所に位置する論理ネットワークエンドポイントとの間の接続、ゲートウェイデータパスとＶＰＣ内の別のエンドポイントとの間の接続、あるいはそれらの組合せに関係してもよい。いくつかの実施形態のＤＮＥ規則は、指定された接続のエンドポイント間のパケットの暗号化及び／又は認証も要求する。
更に、処理３１００は、暗号化及び／又は認証処理で使用するための鍵に対するチケットを中央制御器から受信する（３１１０において）。いくつかの実施形態において、当該チケットは、鍵識別子及び／又はＳＰＩに基づいて中央制御器により生成される。チケットは、ネットワーク暗号化システムの鍵マネージャから鍵を検索するためのセキュリティトークンとして機能する。いくつかの実施形態において、チケットは、鍵識別子、ローカル制御器識別子、有効期限及び署名を含む。
次に、処理は、チケットを使用して鍵マネージャへ鍵の要求を送信する（３１１５において）。いくつかの実施形態はチケット自体を送信し、他の実施形態はチケットから導出されたデータを送信する。鍵マネージャは、チケット又は要求内の他の情報を使用して、必要な鍵を識別し、ゲートウェイ制御器が鍵を受信することを認可されていることを検証する。
鍵マネージャが要求を検証したと仮定した場合、処理は鍵マネージャからマスタ鍵を受信する（３１２０において）。マスタ鍵は、要求時に鍵マネージャにより生成される。次に、処理は、受信したマスタ鍵に基づいて１つ以上のセッション鍵を計算する（３１２５において）。規則により統制される複数の可能な接続を規則が指定する場合、いくつかの実施形態は、そのような接続毎にマスタ鍵から異なるセッション鍵を生成する。いくつかの実施形態は、マスタ鍵、特定の接続の２つのエンドポイントに関する特徴（例えば、ＶＴＥＰラベル、ＶＴＥＰ ＩＰアドレス、エンドポイントに関連するＳＰＩ等）及び／又はランダムに生成された数の関数としてセッション鍵を計算する。
次に、処理は、鍵を必要とする何らかのＭＦＥに対するローカル制御エージェント（すなわち、各接続の両端に存在するＭＦＥに対するエージェント）へセッション鍵を送信する（３１３０において）。これは、必要に応じて鍵をゲートウェイデータパスへ送信することを更に含んでもよい。更に、いくつかの実施形態において、ワークロードＶＭ又はそのエージェントが再起動され且つエージェントが以前に配布された情報を必要とする場合に鍵を再配布できるように、ゲートウェイ上のＤＮＥモジュールは鍵をセキュアに格納する。
ＶＩＩＩ． 脅威の検出及び処理
特に、パブリッククラウド内で動作するＤＣＮワークロード及びそれらのＤＣＮ上で動作するＭＦＥの場合、セキュリティが問題となり得る。セキュリティポリシーはＤＣＮが動作するマシンの仮想化ソフトウェア内ではなくＤＣＮ自体で動作するＭＦＥにより実施されるため、ハッカーがＤＣＮへのルートアクセスを取得した場合、ハッカーはネットワークセキュリティポリシーの実施を回避できる（従って、これらのポリシーに反してトラフィックを送信できる）可能性がある。
不正アクセスされたＤＣＮ上のハッカー（又は他の不正ユーザ）は、いくつかの異なる方法のうちの１つでネットワークセキュリティポリシーを回避する可能性がある。例えばユーザは、（ｉ）ローカル制御エージェントを除去すること（例えば、アンインストールすること）、（ｉｉ）セキュリティポリシーの実施を回避するために、ネットワークインタフェースをＭＦＥから切断し、ネットワークスタックをインタフェース上で直接実行すること、あるいは（ｉｉｉ）ローカル制御エージェントが（例えば、セキュリティポリシーを実施する統合ブリッジの）ＭＦＥの制御器でなくなるように構成を修正することにより、ＭＦＥを直接構成する（例えば、新規のフローエントリをインストールする）。
しかし、いくつかの実施形態のパブリッククラウドマネージャは、不正アクセスされたＤＣＮをパブリッククラウドに関して隔離することにより、ネットワーク制御システムがこれらの状況を処理できるようにする。従って、ＤＣＮが接続するパブリッククラウド転送要素（例えば、ホストマシン内の仮想スイッチ）は、不正アクセスされたＤＣＮがデータトラフィックを送信するのを防止する。ＰＣＭは、影響を受けたＤＣＮのＶＰＣ内のゲートウェイ制御器により、影響を受けたＤＣＮを通知され、パブリッククラウドマネージャＡＰＩを使用して、不正アクセスされたＤＣＮをパブリッククラウドの管理システム内の隔離セキュリティグループに入れることができる。
不正アクセスされたＤＣＮ上のローカル制御エージェントは、上記に列挙した第２の状況及び第３の状況を検出し、ゲートウェイ制御器に通知できる。エージェントが除去された場合、ゲートウェイ制御器は当該制御器への接続が存在しないことを認識する。いずれの場合も、ＤＣＮが不正アクセスされたとゲートウェイ制御器が判定すると、ゲートウェイ制御器はＰＣＭに通知し、それによりＰＣＭは不正アクセスされたＤＣＮを隔離できる。
図３２は、不正アクセスされたＤＣＮを処理するためにＰＣＭにより実行されるいくつかの実施形態の処理３２００を概念的に示す。示されるように、処理は、ＶＰＣ内のデータ計算ノードが不正アクセスされたらしいという通知をゲートウェイ制御器から受信する（３２０５において）ことにより開始する。これは、不正ユーザ又はハッカーがＭＦＥからネットワークインタフェースを切断した場合、ＭＦＥに接続されない新規のネットワークインタフェースを追加した場合、又はＭＦＥの制御器としてのエージェントを切断した場合のＤＣＮ上のローカル制御エージェントからのメッセージに基づいて発生する。ＭＦＥエージェント自体がアンインストール又は除去された場合、ゲートウェイ制御器はエージェントとの接続が失われた時にエラーを検出する。
次に、処理３２００は、不正アクセスされたＤＣＮを再分類するためのパブリッククラウドプロバイダのセキュリティグループを判定する（３２１０において）。いくつかの実施形態において、パブリッククラウドプロバイダは、自身がホストするＤＣＮの例えば隔離、開放、カプセル化トラフィックの許可を含む分類を行うことができるセキュリティグループのセットを有する。隔離されると、ＤＣＮの制御を取り戻すための特定のトラフィックを除いて、ＤＣＮはホストマシン上のクラウドプロバイダ転送要素を介してトラフィックを送受信することを許可されない。従って、処理３２００は、パブリッククラウドプロバイダのＡＰＩを使用して、不正アクセスされたＤＣＮを識別されたセキュリティグループ（例えば、隔離グループ）に追加する（３２１５において）。いくつかの実施形態において、ＰＣＭは、これらのＡＰＩを使用して、ＤＣＮに対する新規のセキュリティグループを指定するパブリッククラウド管理システムへコマンドを送信する。脅威が除去され且つＤＣＮが正常な状態に回復すると、いくつかの実施形態のＰＣＭは、ＤＣＮを以前のセキュリティグループに戻す同様のコマンドを送信する。
図３３及び図３４は、パブリックデータセンタＶＰＣ内の不正アクセスされたＶＭを識別するゲートウェイ制御器３３３０と、不正アクセスされたＶＭをパブリックデータセンタプロバイダと共に隔離するＰＣＭ３３２５の例を示す。詳細には、図３３は、エージェントがアンインストールされる場合を４つの段階３３０５〜３３２０で示す。第１の段階に示されるように、ゲートウェイＶＭ３３００はゲートウェイ制御器３３３０及びＰＣＭ３３２５を含み（他の構成要素に加えて）、ＶＰＣ内のＶＭ３３３５はエージェント３３４０を実行する（ワークロードアプリケーションとエージェントにより制御されるＭＦＥとに加えて）。第１の段階３３０５では、ゲートウェイ制御器３３３０とエージェント３３４０との間に接続が存在する。
しかし、この第１の段階３３０５において、ＶＭが不正アクセスされ、ＶＭにログインしたユーザがエージェント３３４０を削除（例えば、アンインストール）したため、ＶＭ上のＭＦＥはセキュリティポリシーを受信できない。しかし、第２の段階３３１０に示すように、これによりエージェントとゲートウェイ制御器３３３０との間の接続が除去されたため、ゲートウェイ制御器はエージェントが動作していないことを検出する。尚、これは、ＶＭが不正アクセスされたのではなくエージェントが再起動又は故障した場合に起こり得るが、いくつかの実施形態は、いずれにしても、これらの場合はエージェントがバックアップされるまでＶＭを隔離する。
第３の段階３３１５において、ゲートウェイ制御器３３３０はエージェントが停止していることをＰＣＭ３３２５に通知する。いくつかの実施形態はＰＣＭに特定の問題（エージェントの停止、無認可のインタフェース等）を通知し、他の実施形態は単に特定のＶＭが不正アクセスされたことをＰＣＭに通知する。いずれの場合も、第４の段階３３２０は、不正アクセスされたＶＭを隔離する（例えば、不正アクセスされたＶＭを隔離セキュリティグループに入れることにより）ために、ＰＣＭがクラウドプロバイダ管理システム３３４５へメッセージを送信することを示す。
本例はエージェントが完全にアンインストールされた場合を示すが、ハッカーが異なる制御器（すなわち、ハッカーによる１つの制御器）から構成規則を受信するようにエージェントの構成を単に変更した場合も同様の接続の消失が生じる。エージェントがゲートウェイ制御器から構成を受信するように構成されなくなるため、エージェントはゲートウェイ制御器との通信を切断し、ゲートウェイ制御器にはエージェントが削除されたように見える。
図３４は、攻撃者が不正アクセスされたＶＭ３４００上に新規のインタフェースを作成する場合を４つの段階３４０５〜３４２０で示す。ＶＭ３４００は、その上で実行するエージェント３４２５を有し、ゲートウェイＶＭ３３００と同じＶＰＣ内で動作する。第１の段階３４０５において、新規のインタフェースがＶＭ３４００上に作成されており、当該インタフェースは非セキュアデータを送信するために使用されている。インタフェースはＭＦＥに接続されていないため、ＶＭ上のアプリケーションは、何らかの種類のセキュリティ処理を行うことなく、ネットワークスタックを介してインタフェースへパケットを直接送信できる。
しかし、第２の段階３４１０において、エージェントは新規のインタフェースの存在を検出し、ゲートウェイ制御器３３３０に当該インタフェースを報告する。いくつかの実施形態において、新規のインタフェースは、エージェントにより管理されるデータベース（例えば、ＯＶＳＤＢデータベース）に自動的にポピュレートされるため、エージェントはこの変更を検出する。インタフェースはＭＦＥに接続されていないため、エージェントは当該インタフェースを信頼できないインタフェースとしてゲートウェイ制御器に報告する。同様に、既存のインタフェースがＭＦＥの仲介処理なしにワークロードアプリケーションからパケットを直接受信するように変更された場合、エージェントはゲートウェイ制御器に通知する。
第３の段階３４１５において、ゲートウェイ制御器３３３０は、ＶＭ３４００が不正アクセスされていることをＰＣＭ３３２５に報告する。前述の例と同様に、ＰＣＭは、不正アクセスされたＶＭを隔離する（例えば、ＶＭを隔離セキュリティグループに入れることにより）ためにクラウドプロバイダ管理システム３３４５へメッセージを送信する。
ＩＸ． 電子システム
上述した特徴及びアプリケーションの多くは、コンピュータ可読記憶媒体（コンピュータ可読媒体とも呼ばれる）に記録された命令のセットとして指定されるソフトウェア処理として実現される。これらの命令が１つ以上の処理装置（例えば、１つ以上のプロセッサ、プロセッサのコア又は他の処理装置）により実行される場合、それらは命令において示される動作を処理装置に実行させる。コンピュータ可読媒体の例は、ＣＤ‐ＲＯＭ、フラッシュドライブ、ＲＡＭチップ、ハードドライブ、ＥＰＲＯＭ等を含むが、それらに限定されない。コンピュータ可読媒体は、無線又は有線接続を介する搬送波及び電子信号を含まない。
本明細書において、用語「ソフトウェア」は、プロセッサによる処理のためにメモリに読み込むことができる読み出し専用メモリに常駐するファームウェア又は磁気記憶装置に格納されたアプリケーションを含むことを意味する。また、いくつかの実施形態において、個別のソフトウェア発明を残しつつ、複数のソフトウェア発明をより大きなプログラムの一部として実現することができる。いくつかの実施形態において、複数のソフトウェア発明を別個のプログラムとして実現することもできる。最後に、本明細書に記載のソフトウェア発明を共に実現する別個のプログラムの何らかの組み合わせは本発明の範囲内である。いくつかの実施形態において、ソフトウェアプログラムは、１つ以上の電子システム上で動作するようにインストールされた場合、ソフトウェアプログラムの動作を遂行及び実行する１つ以上の特定のマシン実現例を定義する。
図３５は、本発明のいくつかの実施形態が実現される電子システム３５００を概念的に示す。電子システム３５００を使用して、上述した制御、仮想化又はオペレーティングシステムアプリケーションのいずれも実行することができる。電子システム３５００は、コンピュータ（例えば、デスクトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ、サーバコンピュータ、メインフレーム、ブレードコンピュータ等）、電話、ＰＤＡ又は他の何らかの種類の電子装置であってもよい。そのような電子システムは、様々な種類のコンピュータ可読媒体及び様々な他の種類のコンピュータ可読媒体に対するインタフェースを含む。電子システム３５００は、バス３５０５、処理装置３５１０、システムメモリ３５２５、読み出し専用メモリ３５３０、永久記憶装置３５３５、入力装置３５４０及び出力装置３５４５を含む。
バス３５０５は、電子システム３５００の多くの内部装置を通信可能に接続するシステムバス、周辺バス及びチップセットバスの全てを一括して表す。例えばバス３５０５は、処理装置３５１０を読み出し専用メモリ３５３０、システムメモリ３５２５及び永久記憶装置３５３５に通信可能に接続する。
これらの種々のメモリ装置から、処理装置３５１０は、本発明の処理を実行するために実行する命令及び処理するデータを検索する。異なる実施形態において、処理装置は単一のプロセッサ又はマルチコアプロセッサであってもよい。
読み出し専用メモリ（ＲＯＭ）３５３０は、処理装置３５１０及び電子システムの他のモジュールにより必要とされる静的データ及び命令を格納する。一方、永久記憶装置３５３５は読み出し／書き込みメモリ素子である。当該装置は、電子システム３５００の電源が入っていない場合でも命令及びデータを格納する不揮発性メモリ装置である。本発明のいくつかの実施形態は、永久記憶装置３５３５として大容量記憶装置（磁気ディスク又は光ディスク及び対応するディスクドライブ等）を使用する。
他の実施形態は、永久記憶装置として取り外し可能記憶装置（フロッピディスク、フラッシュドライブ等）を使用する。永久記憶装置３５３５と同様に、システムメモリ３５２５は読み出し／書き込みメモリ素子である。しかし、記憶装置３５３５と異なり、システムメモリはランダムアクセスメモリ等の揮発性読み出し／書き込みメモリである。システムメモリは、プロセッサが実行時に必要とする命令及びデータの一部を格納する。いくつかの実施形態において、本発明の処理は、システムメモリ３５２５、永久記憶装置３５３５及び／又は読み出し専用メモリ３５３０に格納される。これらの種々のメモリ装置から、処理装置３５１０は、いくつかの実施形態の処理を実行するために実行する命令及び処理するデータを検索する。
バス３５０５は、入力装置３５４０及び出力装置３５４５に更に接続する。入力装置により、ユーザは電子システムに対して情報を伝達し且つコマンドを選択することができる。入力装置３５４０は、英数字キーボード及びポインティング装置（「カーソル制御装置」とも呼ばれる）を含む。出力装置３５４５は、電子システムにより生成された画像を表示する。出力装置は、プリンタとブラウン管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）等の表示装置とを含む。いくつかの実施形態は、入力装置及び出力装置の双方として機能するタッチスクリーン等の装置を含む。
最後に、図３５に示すように、バス３５０５は、ネットワークアダプタ（不図示）を介して電子システム３５００をネットワーク３５６５に更に結合する。このように、コンピュータは、コンピュータのネットワーク（ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）又はイントラネット等）又はインターネット等のネットワークのネットワークの一部となり得る。電子システム３５００のいずれか又は全ての構成要素が本発明と関連して使用されてもよい。
いくつかの実施形態は、マイクロプロセッサ、機械可読媒体又はコンピュータ可読媒体（又はコンピュータ可読記憶媒体、機械可読媒体又は機械可読記憶媒体とも呼ばれる）にコンピュータプログラム命令を格納する記憶装置及びメモリ等の電子部品を含む。そのようなコンピュータ可読媒体のいくつかの例は、ＲＡＭ、ＲＯＭ、読み出し専用コンパクトディスク（ＣＤ‐ＲＯＭ）、記録可能コンパクトディスク（ＣＤ‐Ｒ）、書き換え可能コンパクトディスク（ＣＤ‐ＲＷ）、読み出し専用デジタル多用途ディスク（例えば、ＤＶＤ‐ＲＯＭ、２層ＤＶＤ‐ＲＯＭ）、種々の記録可能／書き換え可能ＤＶＤ（例えば、ＤＶＤ‐ＲＡＭ、ＤＶＤ‐ＲＷ、ＤＶＤ＋ＲＷ等）、フラッシュメモリ（例えば、ＳＤカード、ｍｉｎｉ‐ＳＤカード、ｍｉｃｒｏ‐ＳＤカード等）、磁気ハードドライブ及び／又はソリッドステートハードドライブ、読み出し専用Ｂｌｕ‐Ｒａｙ（登録商標）ディスク及び記録可能Ｂｌｕ‐Ｒａｙ（登録商標）ディスク、超高密度光ディスク、他の何らかの光媒体又は磁気媒体、並びにフロッピディスク等を含む。コンピュータ可読媒体は、少なくとも１つの処理装置により実行可能であり且つ種々の動作を実行するための命令のセットを含むコンピュータプログラムを格納してもよい。コンピュータプログラム又はコンピュータコードの例は、コンパイラにより生成されるようなマシンコードと、インタプリタを使用してコンピュータ、電子構成要素又はマイクロプロセッサにより実行される高水準コードを含むファイルとを含む。
上記の説明はソフトウェアを実行するマイクロプロセッサ又はマルチコアプロセッサを主に参照するが、いくつかの実施形態は、特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）等の１つ以上の集積回路により実行される。いくつかの実施形態において、そのような集積回路は、回路自体に格納されている命令を実行する。
本明細書中で使用される場合、用語「コンピュータ」、「サーバ」、「プロセッサ」及び「メモリ」は全て、電子装置又は他の技術的装置を示す。これらの用語は、人間又は人間のグループを含まない。本明細書の目的のために、用語「表示する」は、電子装置上に表示することを意味する。本明細書中で使用される場合、用語「コンピュータ可読媒体」及び「機械可読媒体」は、コンピュータが読み出し可能な形態で情報を格納する有形物理物体に完全に限定される。これらの用語は、何らかの無線信号、有線ダウンロード信号及び他の何らかの一時的信号を含まない。
本明細書は、全体を通して、仮想マシン（ＶＭ）を含む計算環境及びネットワーク環境を参照する。しかし、仮想マシンは、アドレス指定可能ノードとも呼ばれるデータ計算ノード（ＤＮＣ）又はデータ計算エンドノードの一例にすぎない。ＤＣＮは、非仮想化物理ホスト、仮想マシン、ハイパーバイザ又は別個のオペレーティングシステムを必要とせずにホストオペレーティングシステム上で実行するコンテナ、並びにハイパーバイザーカーネルネットワークインターフェイスモジュール等を含んでもよい。
いくつかの実施形態において、ＶＭは、仮想化ソフトウェア（例えば、ハイパーバイザ、仮想マシンモニタ等）により仮想化されたホストのリソースを使用して、ホスト上の自身のゲストオペレーティングシステムと共に動作する。テナント（すなわち、ＶＭの所有者）は、ゲストオペレーティングシステム上で動作させるアプリケーションを選択できる。一方、一部のコンテナは、ハイパーバイザ又は別個のゲストオペレーティングシステムを必要とせずにホストオペレーティングシステム上で実行する構造である。いくつかの実施形態において、ホストオペレーティングシステムは、異なるテナントに対するコンテナを分離し、従って、異なるコンテナ内で動作する異なるアプリケーショングループのオペレーティングシステムレベルでの分離を提供する。この分離は、ハイパーバイザ仮想化環境において提供されるＶＭの分離と類似するため、異なるコンテナ内で動作する異なるアプリケーショングループを分離する仮想化の一形態であると見なすことができる。そのようなコンテナはＶＭより軽量である。
いくつかの実施形態において、ハイパーバイザカーネルネットワークインタフェースモジュールは、ハイパーバイザカーネルネットワークインターフェースと受信／送信スレッドとを有するネットワークスタックを含む非ＶＭ ＤＣＮである。ハイパーバイザカーネルネットワークインターフェイスモジュールの一例は、ＶＭｗａｒｅ ＩｎｃのＥＳＸハイパーバイザの一部であるｖｍｋｎｉｃモジュールである。
本明細書はＶＭを参照するが、記載された例は、物理ホスト、ＶＭ、非ＶＭコンテナ及びハイパーバイザカーネルネットワークインターフェースモジュールを含む何らかの種類のＤＣＮであり得ることが当業者には認識されるだろう。実際、いくつかの実施形態において、例示的なネットワークは異なる種類のＤＣＮの組み合わせを含むことができる。
多くの特定の詳細を参照して本発明を説明したが、本発明の主旨から逸脱することなく本発明を他の特定の形態で実現できることが当業者には認識されるだろう。更に、多くの図面（図３、図４、図８〜図１０、図２８、図３１及び図３２を含む）は処理を概念的に示す。これらの処理の特定の動作は、図示及び説明された正確な順序で実行されなくてもよい。特定の動作は、一連の動作で連続して実行されなくてもよく、異なる実施形態では異なる特定の動作が実行されてもよい。更に、処理は、いくつかのサブ処理を使用して又はより大きいマクロ処理の一部として実現され得る。従って、本発明は前述の例示的な詳細により限定されるべきでなく、むしろ添付の特許請求の範囲により定義されるべきであることが当業者には理解されるだろう。

Claims (68)

  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. 前記暗号化規則は、特定の送信元と特定の宛先との間で送信されるパケットが暗号化されることを指定し、前記特定の送信元及び前記特定の宛先の各々は、ネットワークアドレス、ネットワークアドレスの範囲、１つ以上のＭＡＣアドレス、論理スイッチポート、仮想インタフェース、トランスポート層ポート番号、並びにトランスポート層ポート番号の範囲のうちの少なくとも１つに基づいて定義されることを特徴とする請求項２６記載の方法。
  34. 前記第３のデータ計算ノードは前記第１のデータ計算ノードであることを特徴とする請求項２６記載の方法。
  35. 前記セキュア記憶装置に前記第１の鍵を要求することは、前記ネットワーク制御器から前記暗号化規則と共に受信されるチケットを前記セキュア鍵記憶装置へ送信することを備えることを特徴とする請求項２６記載の方法。
  36. 前記チケットは、鍵識別子と接続のセキュリティ性を識別するセキュリティパラメータインデックスとの少なくとも一方に基づいて前記ネットワーク制御器により生成されることを特徴とする請求項３５記載の方法。
  37. 前記チケットは、前記第１のデータ計算ノードにより要求される鍵の種類を指定する鍵識別子、前記第１のデータ計算ノード上で動作する制御器を識別するローカル制御器識別子、有効期限、並びに前記チケットが前記ネットワーク制御器から受信されることを有効にする署名を含むことを特徴とする請求項３５記載の方法。
  38. 前記第１の鍵はマスタ鍵であり、前記第２の鍵及び前記第３の鍵はセッション鍵であることを特徴とする請求項２６記載の方法。
  39. 前記更なるパラメータは、前記第２のデータ計算ノード及び前記第３のデータ計算ノードに関する情報を含むことを特徴とする請求項２６記載の方法。
  40. 前記第２の鍵及び前記第３の鍵を生成するために前記第１の鍵及び更なるパラメータを使用することは、前記第２の鍵及び前記第３の鍵を生成するために一方向性関数を使用することを備えることを特徴とする請求項２６記載の方法。
  41. 前記第２のデータ計算ノード及び前記第３のデータ計算ノードに前記暗号化規則を配布することを更に備えることを特徴とする請求項２６記載の方法。
  42. 前記第２のデータ計算ノード及び前記第３のデータ計算ノードは、前記第２の鍵及び前記第３の鍵を使用して、前記暗号化規則に合致するデータパケットを暗号化することを特徴とする請求項４１記載の方法。
  43. 前記第２のデータ計算ノード上で実行する被管理転送要素は、発信データパケットが前記暗号化規則に合致すると識別し、前記データパケットにＩＰＳｅｃ暗号化を適用するために前記データ計算ノード上のネットワークスタックに前記データパケットを提供することを特徴とする請求項４２記載の方法。
  44. ネットワーク制御器がアクセスできない転送要素を備えるデータセンタ内で実現される論理ネットワークを管理する前記ネットワーク制御器に対して、
    前記論理ネットワークに接続するために、前記データセンタ内のホストマシン上で動作し、前記データセンタの管理システムにより提供される第１のネットワークアドレスを用いるネットワークインタフェースを有し且つ（ｉ）ワークロードアプリケーション及び（ｉｉ）被管理転送要素を実行するデータ計算ノードを識別することと、
    前記データ計算ノード上の前記ワークロードアプリケーションから送信されるデータパケットを受信し且つ前記データパケットにネットワークセキュリティ／転送処理を実行するように前記被管理転送要素を構成するための構成データを配布することとを備え、前記ワークロードにより送信される前記データパケットは、前記被管理転送要素により受信される際に第２のネットワークアドレスを送信元アドレスとして有し、前記データ計算ノードから送信される前に前記被管理転送要素により前記第１のネットワークアドレスを使用して暗号化されることを特徴とする方法。
  45. 前記第２のネットワークアドレスは、前記データ計算ノードが接続される論理スイッチの論理ポートにマッピングされ、前記論理スイッチは、前記論理ネットワークの複数の論理転送要素のうちの１つであることを特徴とする請求項４４記載の方法。
  46. 前記被管理転送要素はフローベースソフトウェア転送要素であることを特徴とする請求項４４記載の方法。
  47. 前記被管理転送要素は、内部ポートを介して前記ワークロードアプリケーションに接続する第１のブリッジと、前記データ計算ノードの前記ネットワークインタフェースに接続する第２のブリッジとを備えることを特徴とする請求項４４記載の方法。
  48. 前記第１のブリッジは、前記ワークロードアプリケーションとの間で送受信されるデータパケットに対してネットワークセキュリティ処理及び論理転送を実行するように構成されることを特徴とする請求項４７記載の方法。
  49. 前記ネットワークセキュリティ処理は分散型ファイアウォール規則の適用を含むことを特徴とする請求項４８記載の方法。
  50. 前記論理転送は、各データパケットに対する論理出口ポートを識別するために少なくとも１つの論理スイッチに対する転送規則を適用することを含むことを特徴とする請求項４８記載の方法。
  51. 前記論理転送は、論理ルータに対する転送規則を適用することを更に含むことを特徴とする請求項５０記載の方法。
  52. 前記第１のブリッジは、前記ワークロードアプリケーションからデータパケットを受信し、前記データパケットに対する論理出口ポートを識別し、前記データパケットをカプセル化し且つ前記カプセル化されたデータパケットを前記第２のブリッジの仮想トンネルエンドポイント（ＶＴＥＰ）へ送信するように構成されることを特徴とする請求項４７記載の方法。
  53. 前記データパケットは前記第２のネットワークアドレスに関連付けられた第１のネットワークスタックを介して前記ワークロードアプリケーションから受信され、前記カプセル化されたデータパケットは、前記第１のネットワークアドレスに関連付けられた第２のネットワークスタックを介して前記第２のブリッジの前記ＶＴＥＰへ送信されることを特徴とする請求項５２記載の方法。
  54. 前記第１のネットワークアドレスは、前記第１のブリッジにより適用されるカプセル化ヘッダに対する前記送信元ネットワークアドレスとして使用されることを特徴とする請求項５３記載の方法。
  55. 前記第２のブリッジは、前記第１のネットワークアドレスを宛先アドレスとして用いてカプセル化された着信パケットを前記ＶＴＥＰを介して前記第１のブリッジのオーバーレイポートへ送信するように構成されることを特徴とする請求項５２記載の方法。
  56. 前記第１のブリッジは、前記オーバーレイポートを介して受信した前記着信パケットをカプセル解除するように構成されることを特徴とする請求項５５記載の方法。
  57. 前記データ計算ノードは、前記配布された構成データに従って前記被管理転送要素を直接構成するためのローカル制御エージェントを更に実行することを特徴とする請求項４４記載の方法。
  58. 前記ワークロードアプリケーションは第１のワークロードアプリケーションであり、前記データ計算ノードは第１のデータ計算ノードであり、前記ワークロードにより前記データセンタ内の第２のデータ計算ノード上で実行する第２のワークロードアプリケーションへ送信されるデータパケットはカプセル化され、前記データ計算ノードの前記ネットワークインタフェースから前記データセンタ管理システムにより制御される転送要素へ送信されることを特徴とする請求項４４記載の方法。
  59. 前記データセンタ管理システムにより制御される前記転送要素は、前記データ計算ノードが動作するホストマシンの物理ネットワークインタフェースに関連付けられた第３のネットワークアドレスを使用して、前記発信データパケットの２回目のカプセル化を行うことを特徴とする請求項５８記載の方法。
  60. 前記ネットワーク制御器は第１のネットワーク制御器であり、前記データ計算ノードは第１のデータ計算ノードであり、前記第１のデータ計算ノードを識別することは、前記データセンタ内の第２のデータ計算ノード上で動作する第２のネットワーク制御器から接続要求を受信することを備えることを特徴とする請求項４４記載の方法。
  61. 前記接続要求は、前記第１のデータ計算ノードから接続要求を受信した後に前記第２のネットワーク制御器により転送されることを特徴とする請求項６０記載の方法。
  62. 前記構成データを配布することは、前記第２のネットワーク制御器に前記構成データを配布することを備え、前記第２のネットワーク制御器は、前記第２のデータ計算ノードに前記構成データを配布することを特徴とする請求項６０記載の方法。
  63. 前記第１のデータ計算ノード及び前記第２のデータ計算ノードは前記データセンタの同一の仮想プライベートクラウド内で動作することを特徴とする請求項６０記載の方法。
  64. 前記データセンタは第１のパブリックマルチテナントデータセンタであり、前記ネットワーク制御器は第２のプライベートデータセンタ内で動作することを特徴とする請求項４４記載の方法。
  65. 前記ワークロードアプリケーションは、前記被管理転送要素により実現される論理ネットワークを介してデータパケットを送受信し、前記ワークロードアプリケーションにより送信されるデータパケットが前記論理ネットワークに関連付けられない宛先アドレスを有する場合、前記被管理転送要素はネットワークアドレス変換（ＮＡＴ）を実行して前記第２のネットワークアドレスを第３のネットワークアドレスに変換することを特徴とする請求項４４記載の方法。
  66. 少なくとも１つの処理装置により実行するためのプログラムであり、請求項１から６５のいずれかに記載の方法を実現するための命令のセットを備える前記プログラムを格納することを特徴とする機械可読媒体。
  67. 処理装置のセットと、
    前記処理装置のうちの少なくとも１つにより実行するためのプログラムであり、請求項１から６５のいずれかに記載の方法を実現するための命令のセットを備える前記プログラムを格納する機械可読媒体と、
    を備えることを特徴とする電子装置。
  68. 請求項１から６５のいずれか１項に記載の方法を実現する手段を備えることを特徴とする装置。
JP2020130708A 2016-08-27 2020-07-31 ネットワーク制御システムのパブリッククラウドへの拡張 Active JP7009014B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022001263A JP7190595B2 (ja) 2016-08-27 2022-01-06 ネットワーク制御システムのパブリッククラウドへの拡張

Applications Claiming Priority (24)

Application Number Priority Date Filing Date Title
US201662380411P 2016-08-27 2016-08-27
US62/380,411 2016-08-27
US15/253,832 US10193749B2 (en) 2016-08-27 2016-08-31 Managed forwarding element executing in public cloud data compute node without overlay network
US15/253,833 US10484302B2 (en) 2016-08-27 2016-08-31 Managed forwarding element executing in public cloud data compute node with different internal and external network addresses
US15/253,829 US10367757B2 (en) 2016-08-27 2016-08-31 Extension of network control system into public cloud
US15/253,832 2016-08-31
US15/253,829 2016-08-31
US15/253,833 2016-08-31
US15/253,834 US10397136B2 (en) 2016-08-27 2016-08-31 Managed forwarding element executing in separate namespace of public cloud data compute node than workload application
IN201641029739 2016-08-31
US15/253,834 2016-08-31
IN201641029739 2016-08-31
US15/279,382 US10135675B2 (en) 2016-08-27 2016-09-28 Centralized processing of north-south traffic for logical network in public cloud
US15/279,394 US11018993B2 (en) 2016-08-27 2016-09-28 Distributed network encryption for logical network implemented in public cloud
US15/279,382 2016-09-28
US15/279,394 2016-09-28
US15/279,403 US10812413B2 (en) 2016-08-27 2016-09-28 Logical network domains stretched between public and private datacenters
US15/279,403 2016-09-28
US15/279,409 US10924431B2 (en) 2016-08-27 2016-09-28 Distributed processing of north-south traffic for logical network in public cloud
US15/279,409 2016-09-28
US15/367,157 US10333959B2 (en) 2016-08-31 2016-12-01 Use of public cloud inventory tags to configure data compute node for logical network
US15/367,157 2016-12-01
US15/367,155 US10341371B2 (en) 2016-08-31 2016-12-01 Identifying and handling threats to data compute nodes in public cloud
US15/367,155 2016-12-01

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2019510301A Division JP6744985B2 (ja) 2016-08-27 2017-01-17 ネットワーク制御システムのパブリッククラウドへの拡張

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022001263A Division JP7190595B2 (ja) 2016-08-27 2022-01-06 ネットワーク制御システムのパブリッククラウドへの拡張

Publications (2)

Publication Number Publication Date
JP2020205590A true JP2020205590A (ja) 2020-12-24
JP7009014B2 JP7009014B2 (ja) 2022-01-25

Family

ID=61301454

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2019510301A Active JP6744985B2 (ja) 2016-08-27 2017-01-17 ネットワーク制御システムのパブリッククラウドへの拡張
JP2020130708A Active JP7009014B2 (ja) 2016-08-27 2020-07-31 ネットワーク制御システムのパブリッククラウドへの拡張
JP2022001263A Active JP7190595B2 (ja) 2016-08-27 2022-01-06 ネットワーク制御システムのパブリッククラウドへの拡張
JP2022194408A Pending JP2023036622A (ja) 2016-08-27 2022-12-05 ネットワーク制御システムのパブリッククラウドへの拡張

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2019510301A Active JP6744985B2 (ja) 2016-08-27 2017-01-17 ネットワーク制御システムのパブリッククラウドへの拡張

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2022001263A Active JP7190595B2 (ja) 2016-08-27 2022-01-06 ネットワーク制御システムのパブリッククラウドへの拡張
JP2022194408A Pending JP2023036622A (ja) 2016-08-27 2022-12-05 ネットワーク制御システムのパブリッククラウドへの拡張

Country Status (6)

Country Link
EP (2) EP3731463B1 (ja)
JP (4) JP6744985B2 (ja)
CN (3) CN114697189A (ja)
AU (4) AU2017321075B2 (ja)
CA (3) CA3207315A1 (ja)
WO (1) WO2018044341A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022137733A1 (ja) 2020-12-24 2022-06-30 国立大学法人神戸大学 紫外線照射を用いたウイルス不活化方法

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9571331B1 (en) * 2012-11-21 2017-02-14 Amazon Technologies, Inc. Techniques for accessing local networks via a virtualized gateway
US9225638B2 (en) 2013-05-09 2015-12-29 Vmware, Inc. Method and system for service switching using service tags
US9935827B2 (en) 2014-09-30 2018-04-03 Nicira, Inc. Method and apparatus for distributing load among a plurality of service nodes
US11296930B2 (en) 2014-09-30 2022-04-05 Nicira, Inc. Tunnel-enabled elastic service model
US10594743B2 (en) 2015-04-03 2020-03-17 Nicira, Inc. Method, apparatus, and system for implementing a content switch
US9923811B2 (en) 2015-06-27 2018-03-20 Nicira, Inc. Logical routers and switches in a multi-datacenter environment
US10341371B2 (en) 2016-08-31 2019-07-02 Nicira, Inc. Identifying and handling threats to data compute nodes in public cloud
US10367757B2 (en) 2016-08-27 2019-07-30 Nicira, Inc. Extension of network control system into public cloud
US10491516B2 (en) 2017-08-24 2019-11-26 Nicira, Inc. Packet communication between logical networks and public cloud service providers native networks using a single network interface and a single routing table
US10567482B2 (en) 2017-08-24 2020-02-18 Nicira, Inc. Accessing endpoints in logical networks and public cloud service providers native networks using a single network interface and a single routing table
EP3673627B1 (en) 2017-08-27 2023-09-13 Nicira, Inc. Performing in-line service in public cloud
US10805181B2 (en) 2017-10-29 2020-10-13 Nicira, Inc. Service operation chaining
US10601705B2 (en) 2017-12-04 2020-03-24 Nicira, Inc. Failover of centralized routers in public cloud logical networks
US10862753B2 (en) 2017-12-04 2020-12-08 Nicira, Inc. High availability for stateful services in public cloud logical networks
US10805192B2 (en) 2018-03-27 2020-10-13 Nicira, Inc. Detecting failure of layer 2 service using broadcast messages
JP6669807B2 (ja) * 2018-05-30 2020-03-18 株式会社日立製作所 計算機システムおよび計算機
US11343229B2 (en) 2018-06-28 2022-05-24 Vmware, Inc. Managed forwarding element detecting invalid packet addresses
US11115327B2 (en) * 2018-08-24 2021-09-07 Oracle International Corporation Methods, systems, and computer readable media for providing mobile device connectivity
CN116032836A (zh) * 2018-08-24 2023-04-28 Vm维尔股份有限公司 在公共云中智能地使用对等
US11196591B2 (en) 2018-08-24 2021-12-07 Vmware, Inc. Centralized overlay gateway in public cloud
US10491466B1 (en) 2018-08-24 2019-11-26 Vmware, Inc. Intelligent use of peering in public cloud
US11374794B2 (en) 2018-08-24 2022-06-28 Vmware, Inc. Transitive routing in public cloud
US11595250B2 (en) 2018-09-02 2023-02-28 Vmware, Inc. Service insertion at logical network gateway
US11258635B2 (en) 2018-12-28 2022-02-22 Alibaba Group Holding Limited Overlay network routing using a programmable switch
US11074097B2 (en) 2019-02-22 2021-07-27 Vmware, Inc. Specifying service chains
US10972386B2 (en) * 2019-03-29 2021-04-06 Juniper Networks, Inc. Scalable multi-tenant underlay network supporting multi-tenant overlay network
US11140218B2 (en) 2019-10-30 2021-10-05 Vmware, Inc. Distributed service chain across multiple clouds
US11659061B2 (en) 2020-01-20 2023-05-23 Vmware, Inc. Method of adjusting service function chains to improve network performance
US11930394B2 (en) 2020-03-24 2024-03-12 Nokia Technologies Oy Overload control information from a network function service consumer in 5G core network (5GC) service based architecture (SBA)
CN115380514B (zh) * 2020-04-01 2024-03-01 威睿有限责任公司 为异构计算元件自动部署网络元件
US11088919B1 (en) 2020-04-06 2021-08-10 Vmware, Inc. Data structure for defining multi-site logical network
US11394634B2 (en) 2020-04-06 2022-07-19 Vmware, Inc. Architecture for stretching logical switches between multiple datacenters
US11528219B2 (en) 2020-04-06 2022-12-13 Vmware, Inc. Using applied-to field to identify connection-tracking records for different interfaces
US11088902B1 (en) 2020-04-06 2021-08-10 Vmware, Inc. Synchronization of logical network state between global and local managers
US11777793B2 (en) 2020-04-06 2023-10-03 Vmware, Inc. Location criteria for security groups
US11683233B2 (en) 2020-04-06 2023-06-20 Vmware, Inc. Provision of logical network data from global manager to local managers
CN111585800B (zh) * 2020-04-29 2022-06-28 平安科技（深圳）有限公司 基于虚拟私有云的网关节点的配置方法、装置和介质
CN111953804B (zh) * 2020-07-09 2022-09-20 北京火山引擎科技有限公司 一种网络数据传输的方法、装置、介质和电子设备
CN111565142B (zh) * 2020-07-15 2020-11-03 鹏城实验室 报文处理方法、装置及计算机可读存储介质
CN112000540A (zh) * 2020-07-20 2020-11-27 中国建设银行股份有限公司 分布式部署产品的监控处理方法、系统、设备和存储介质
US11757940B2 (en) 2020-09-28 2023-09-12 Vmware, Inc. Firewall rules for application connectivity
US11310732B1 (en) * 2020-11-23 2022-04-19 At&T Intellectual Property I, L.P. Facilitation of fast aiding radio access network intelligent controllers for 5G or other next generation network
US11734043B2 (en) 2020-12-15 2023-08-22 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
US11611625B2 (en) * 2020-12-15 2023-03-21 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
CN113098780B (zh) * 2021-02-22 2023-04-28 网宿科技股份有限公司 虚拟网络的报文处理方法、电子设备及存储介质
US20220329576A1 (en) * 2021-04-09 2022-10-13 Hewlett Packard Enterprise Development Lp Securing communication between a cloud platform and an application hosted on an on-premise private network
US11652825B2 (en) * 2021-08-09 2023-05-16 International Business Machines Corporation Packet authentication in a VXLAN system
US11902245B2 (en) 2022-01-14 2024-02-13 VMware LLC Per-namespace IP address management method for container networks
CN115051948B (zh) * 2022-05-19 2023-10-13 天翼云科技有限公司 一种vpc分布式网元数据传输方法及装置、电子设备
CN116095145B (zh) * 2023-01-04 2023-08-04 北京志凌海纳科技有限公司 一种vpc集群的数据控制方法和系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014075731A (ja) * 2012-10-05 2014-04-24 Hitachi Solutions Ltd クラウド間通信設定システム
WO2015068255A1 (ja) * 2013-11-08 2015-05-14 株式会社 日立製作所 ネットワークシステム、通信制御装置、及び通信方法
US20150172331A1 (en) * 2013-12-16 2015-06-18 Vmware, Inc. Mapping virtual machines from a private network to a multi-tenant public datacenter
JP2015165700A (ja) * 2008-12-10 2015-09-17 アマゾン テクノロジーズ インコーポレイテッド 遠隔サービスへのローカル安全なネットワークアクセスを提供する方法

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8428057B2 (en) * 2007-03-14 2013-04-23 Cisco Technology, Inc. Optimizing return traffic paths using network address translation
WO2010115060A2 (en) * 2009-04-01 2010-10-07 Nicira Networks Method and apparatus for implementing and managing virtual switches
US8861368B2 (en) * 2009-11-19 2014-10-14 Qualcomm Incorporated Method and apparatus for handling stale PDN context
US9680750B2 (en) * 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
US8661120B2 (en) * 2010-09-21 2014-02-25 Amazon Technologies, Inc. Methods and systems for dynamically managing requests for computing capacity
CN102104525B (zh) * 2011-03-16 2013-04-24 华为技术有限公司 媒体网关设备及转发数据帧的方法
US9288081B2 (en) * 2011-08-17 2016-03-15 Nicira, Inc. Connecting unmanaged segmented networks by managing interconnection switching elements
US8966024B2 (en) * 2011-11-15 2015-02-24 Nicira, Inc. Architecture of networks with middleboxes
US20130152076A1 (en) * 2011-12-07 2013-06-13 Cisco Technology, Inc. Network Access Control Policy for Virtual Machine Migration
US9331938B2 (en) * 2012-04-13 2016-05-03 Nicira, Inc. Extension of logical networks across layer 3 virtual private networks
US9699034B2 (en) * 2013-02-26 2017-07-04 Zentera Systems, Inc. Secure cloud fabric to connect subnets in different network domains
US9392050B2 (en) * 2013-03-15 2016-07-12 Cisco Technology, Inc. Automatic configuration of external services based upon network activity
CN104104534A (zh) * 2013-04-12 2014-10-15 中兴通讯股份有限公司 一种虚拟网络管理的实现方法和系统
US9432215B2 (en) * 2013-05-21 2016-08-30 Nicira, Inc. Hierarchical network managers
US9503371B2 (en) * 2013-09-04 2016-11-22 Nicira, Inc. High availability L3 gateways for logical networks
US8724626B1 (en) * 2013-10-07 2014-05-13 tw telecom holdings inc. Redirecting network traffic based on content
US20150098455A1 (en) * 2013-10-09 2015-04-09 Darren William Fritsch WiFi Enabled Wide Area Automation System
US9785455B2 (en) * 2013-10-13 2017-10-10 Nicira, Inc. Logical router
US9124536B2 (en) * 2013-12-12 2015-09-01 International Business Machines Corporation Managing data flows in overlay networks
US9356866B1 (en) * 2014-01-10 2016-05-31 Juniper Networks, Inc. Receive packet steering for virtual networks
US9647883B2 (en) * 2014-03-21 2017-05-09 Nicria, Inc. Multiple levels of logical routers
US9794186B2 (en) * 2014-03-27 2017-10-17 Nicira, Inc. Distributed network address translation for efficient cloud service access
CN105099953B (zh) * 2014-04-28 2018-06-19 华为技术有限公司 云数据中心虚拟网络的隔离方法与装置
US9547516B2 (en) * 2014-08-22 2017-01-17 Nicira, Inc. Method and system for migrating virtual machines in virtual infrastructure
US9723065B2 (en) 2014-10-13 2017-08-01 Vmware, Inc. Cross-cloud object mapping for hybrid clouds
US9787605B2 (en) 2015-01-30 2017-10-10 Nicira, Inc. Logical router with multiple routing components
WO2016159113A1 (ja) * 2015-03-31 2016-10-06 日本電気株式会社 制御装置、制御方法及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015165700A (ja) * 2008-12-10 2015-09-17 アマゾン テクノロジーズ インコーポレイテッド 遠隔サービスへのローカル安全なネットワークアクセスを提供する方法
JP2014075731A (ja) * 2012-10-05 2014-04-24 Hitachi Solutions Ltd クラウド間通信設定システム
WO2015068255A1 (ja) * 2013-11-08 2015-05-14 株式会社 日立製作所 ネットワークシステム、通信制御装置、及び通信方法
US20150172331A1 (en) * 2013-12-16 2015-06-18 Vmware, Inc. Mapping virtual machines from a private network to a multi-tenant public datacenter

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022137733A1 (ja) 2020-12-24 2022-06-30 国立大学法人神戸大学 紫外線照射を用いたウイルス不活化方法

Also Published As

Publication number Publication date
AU2017321075B2 (en) 2020-03-05
CA3034809A1 (en) 2018-03-08
EP3485610B1 (en) 2020-06-10
AU2021212107B2 (en) 2023-02-16
JP6744985B2 (ja) 2020-08-19
CN109863720B (zh) 2022-05-13
JP7190595B2 (ja) 2022-12-15
EP3485610A1 (en) 2019-05-22
AU2017321075A1 (en) 2019-04-11
AU2023203037A1 (en) 2023-06-08
WO2018044341A1 (en) 2018-03-08
CN109863720A (zh) 2019-06-07
JP2019525669A (ja) 2019-09-05
CN114697189A (zh) 2022-07-01
AU2020203719A1 (en) 2020-06-25
EP3731463A1 (en) 2020-10-28
CA3119423A1 (en) 2018-03-08
CN114760183A (zh) 2022-07-15
AU2021212107A1 (en) 2021-08-26
JP7009014B2 (ja) 2022-01-25
JP2023036622A (ja) 2023-03-14
AU2020203719B2 (en) 2021-07-15
CA3034809C (en) 2021-07-06
CN114697190A (zh) 2022-07-01
CA3207315A1 (en) 2018-03-08
EP3731463B1 (en) 2022-03-30
JP2022058523A (ja) 2022-04-12
CA3119423C (en) 2023-09-19

Similar Documents

Publication Publication Date Title
JP7009014B2 (ja) ネットワーク制御システムのパブリッククラウドへの拡張
US10805330B2 (en) Identifying and handling threats to data compute nodes in public cloud
US11792138B2 (en) Centralized processing of north-south traffic for logical network in public cloud
CN114697190B (zh) 网络控制系统到公共云中的扩展

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200831

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200831

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210708

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210827

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211125

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20211213

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220106

R150 Certificate of patent or registration of utility model

Ref document number: 7009014

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150