JP6511194B2 - 高速且つスケーラブルなデータベースクラスタ通信経路 - Google Patents

Description

［関連出願への相互参照］
この出願は、2015年9月21日に出願された「Fast and Scalable Database Cluster Path」という名称の米国仮特許出願第62/221,458号の優先権及び利益を主張し、この出願が参照により援用される。

［背景技術］
インターネットを通じて安全な方式でエンタープライズネットワーク上のネットワークノード／デバイス（例えば、ルータ／スイッチ等）を接続及び管理するために、ノード／デバイスが提供しているサービスの種類に依存して複数の安全なセッションが生成されなければならない。ノード／デバイスがネットワークアドレス変換（network address translation, NAT）／ファイアウォールの背後に位置するときに、ノード／デバイスを接続及び管理することを取り巻く問題は、ますます解決困難になる。エンタープライズNAT／ファイアウォールは、セッションのそれぞれを許可するために複数のポートを開くことを必要とする。セッションの数が増加すると共に、ポートの数も増加する。

一実施例において、ネットワーク内でアプリケーションペイロードを伝送する方法が存在し、クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するステップであり、アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成されるステップと、トランスポートレイヤプロトコルを終端し、現在のセッションに関連するアプリケーションペイロードを読み取るステップと、アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するステップと、単一の仮想通信リンクを介してネットワーク内で伝送するために、ヘッダ情報を含むアプリケーションペイロードを暗号化するステップとを含む。

他の実施例において、ネットワーク内でアプリケーションペイロードを伝送するためのコンピュータ命令を記憶した非一時的なコンピュータ読み取り可能媒体が存在し、コンピュータ命令は、１つ以上のプロセッサにより実行されたときに、１つ以上のプロセッサに対して、クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するステップであり、アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成されるステップと、トランスポートレイヤプロトコルを終端し、現在のセッションに関連するアプリケーションペイロードを読み取るステップと、アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するステップと、単一の仮想通信リンクを介してネットワーク内で伝送するために、ヘッダ情報を含むアプリケーションペイロードを暗号化するステップとを実行させる。

更に他の実施例では、アプリケーションコンテナが直接通信リンクを介して通信するための方法が存在し、１つ以上の第１アプリケーションコンテナの間の直接のアプリケーションコンテナレベルの通信のための１つ以上の第１専用仮想リンクを構築するステップと、対応する１つ以上の第１専用仮想リンクを介して１つ以上の第１アプリケーションコンテナの間でデータを通信するステップであり、１つ以上の第１専用仮想リンクのそれぞれは、第１端で１つ以上の第１アプリケーションコンテナのそれぞれに接続され、第２端でそれぞれの仮想入力／出力（virtual input/output, VIO）に接続されるステップとを含む。

更に他の実施例では、仮想入力／出力を介して直接のデータベース対アプリケーションレベルの通信を提供するための方法が存在し、１つ以上の第１データベースインスタンスの間の直接のアプリケーションレベルの通信のための１つ以上の第１専用仮想リンクを構築するステップと、対応する１つ以上の第１専用仮想リンクを介して１つ以上の第１データベースインスタンスの間でデータを通信するステップであり、１つ以上の第１専用仮想リンクのそれぞれは、第１端で１つ以上の第１データベースインスタンスのそれぞれに接続されるステップとを含む。

この概要は、簡略化された形式で、以下に詳細な説明において更に説明する概念の選択したものを紹介するために提供されている。この概要は、特許請求の範囲の対象物の主な特徴又は本質的な特徴を識別することを意図するものではなく、特許請求の範囲の対象物の範囲を決定する助けとして使用されることを意図するものでもない。特許請求の範囲の対象物は、背景に記載のいずれかの欠点又は全ての欠点を解決することを実現することに限定されない。

本開示の態様は、例により示されており、添付の図面により限定されない。添付の図面では、同様の参照符号は、同様の要素を示す。
開示の様々な実施例が実現され得る例示的なネットワーク環境を示す。 アプリケーションペイロードが多重され得る仮想通信リンク環境を示す。 図２によるアプリケーション暗号多重（application crypto multiplexing, ACM）環境におけるクライアント及びサーバプロキシを示す。 仮想通信リンクを通じてペイロードを送信及び受信するためのフロー図を示す。 仮想通信リンクを通じてペイロードを送信及び受信するためのフロー図を示す。 アプリケーションクライアント又はアプリケーションサーバのペイロードに追加されるシム（shim）レイヤを示す。 図５のACMヘッダの例を示す。 ACMデータセッション状態機械の状態図を示す。 ネットワーク内でアプリケーションペイロードを伝送する例示的なフロー図を示す。 ネットワーク内でアプリケーションペイロードを伝送する例示的なフロー図を示す。 開示が実現され得る例示的なネットワークを示す。 ホスト内通信のための仮想入力／出力インタフェースを使用した例示的なコンテナパケット通信を示す。 ホスト間通信のための仮想入力／出力インタフェースを使用した例示的なコンテナパケット通信を示す。 TCP及び関係するソケットを消費する必要なくVIOを使用した直接のデータベース／アプリケーションレベルの通信の様々な実施例を示す。 TCP及び関係するソケットを消費する必要なくVIOを使用した直接のデータベース／アプリケーションレベルの通信の様々な実施例を示す。 コンテナ及びデータベースインスタンスのための仮想リンクを構築する例示的なフロー図を示す。 コンテナ及びデータベースインスタンスのための仮想リンクを構築する例示的なフロー図を示す。 開示の実施例によるノードの実施例を示す。 様々な実施例を実現するために使用できるネットワークシステムのブロック図である。 開示の技術によるブロック図を示す。

開示は、ネットワーク内でアプリケーションペイロードを伝送するための技術に関する。クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードが受信され、アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成される。トランスポートレイヤプロトコルが終端され、現在のセッションに関連するアプリケーションペイロードが読み取られる。アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報が準備される。単一の仮想通信リンクを介してネットワーク内で伝送するために、ヘッダ情報を含むアプリケーションペイロードが暗号化される。

本対象物は、多くの異なる形式に具現されてもよく、ここに示す実施例に限定されるものとして解釈されるべきでないことが理解される。むしろ、これらの実施例は、この対象物が徹底的且つ完全であり、開示を当業者に十分に伝えるために提供される。実際に、対象物は、これらの実施例の代案、変更及び等価物をカバーすることを意図しており、これらは、添付の特許請求の範囲により規定される対象物の範囲及び真意内に含まれる。さらに、本対象物の以下の詳細な説明において、本対象物の徹底的な理解を提供するために、複数の具体的な詳細が示されている。しかし、本対象物がこれらの具体的な詳細なしに実施されてもよいことは、当業者に明らかになる。

開示の技術は、アプリケーションペイロードと伝送制御プロトコル（transmission control protocol, TCP）／セキュアソケットレイヤ（secure socket layer, SSL）ヘッダとの間にシムレイヤを追加する「多対１」の統合プロキシ及びトンネル解決策を概して提供し、状態機械がセッションを制御するために構成されてもよい。

このような統合プロキシ及びトンネル解決策は、ネットワークノード／デバイスの位置に基づいてクライアント又はサーバを使用して実現されてもよい。ネットワークノード／デバイスの例は、ルータ、スイッチ、WIFIデバイス、モノのインターネット（Internet-of-things, IOT）デバイス、又はこの開示を考察することで当業者により認識されるいずれかの物理及び仮想デバイスを含むが、これらに限定されない。

以下の説明から明らかになるように、開示の技術は、セキュリティサービスのための単一ポイントを提供し得る。例えば、アプリケーションは、暗号責任をデバイスに委任してもよく、デバイスは、チャネルを設定してデバイスとコントローラとの間で暗号データを交換してもよく、それにより、デバイスの間に安全な接続を提供する。サーバ側で開示の技術を実現することは、暗号サーバを提供し、クライアント側で開示の技術を実現することは、暗号クライアント機能を提供する。通信チャネルは、メッセージ完全性、ユーザ認証及び機密性を認証及び提供してもよい。通信チャネルはまた、標準的な対称／非対称暗号機能をサポートしてもよく、NAT／ファイアウォールの背後に安全なチャネルを設定できてもよい。

図１は、開示の様々な実施例が実現され得る例示的なネットワーク環境を示す。ネットワーク環境100は、例えば、クライアント102と、サーバ104と、SDNコントローラ112と、管理者114とを含む。概して、SDNは、一式のネットワークデバイスのための制御機能を実行するスタンドアローンコントローラの使用を伴う。ソフトウェアデファインドネットワーキングの例として、ルーティングの場合、ルータがネットワークを通じたルートを決定するために個別の分析を実行するのではなく、コントローラは、ルートを決定し、コントローラにより行われた決定に従って振る舞うようにネットワーク内の他のデバイスをプログラムできる。OpenFlowのようなオープンなプロトコル及びネットワークベンダからの独自のプロトコルを含み、異なるプロトコルがソフトウェアデファインドネットワーキングを実現するために使用されてもよい。

図示の実施例では、SDN106は、ネットワークノード108及び110と、サービスデバイス116とを含む。ネットワークノード108及び110は、スイッチ及び他のデバイス（図示せず）を含んでもよい。これらのネットワークノード108及び110は、概してネットワークを転送する役目をする物理インスタンス化又は仮想インスタンス化とすることができる。図示しないが、SDN106はまた、他のネットワークデバイスの中でもルータ、ロードバランサ又は様々なL4-L7ネットワークデバイスのような他の種類のデバイスを含んでもよい。

SDN106は、クライアント102及びサーバ104のような様々なエンドポイントデバイスを接続してもよい。さらに、SDN106は、クライアントデバイス102とサーバデバイス104との間に流れるネットワークトラヒックに対するサービスを提供してもよい。一実施例では、管理者114は、クライアント102のためのネットワークトラヒックをサービスデバイス116の１つ以上に向けるようにSDN106のネットワークデバイスをプログラムするために、SDNコントローラ112を使用してもよい。

サービスデバイス116は、例えば、侵入検知サービス（intrusion detection service, IDS）デバイス、侵入防止システム（intrusion prevention system, IPS）デバイス、ウェブプロキシ、ウェブサーバ、ウェブ−アプリケーションファイアウォール等を含んでもよい。他の例では、サービスデバイス116は、さらに或いは代替として、例えば、サービス拒否（denial of service, DoS）保護、分散サービス拒否（distributed denial of service, DDoS）保護、トラヒックフィルタリング、広域ネットワーク（wide area network, WAN）アクセラレーション、又は他のこのようなサービスのようなサービスを提供するためのデバイスを含んでもよい。

個別のデバイスとして示されているが、サービスデバイス116は、物理デバイス、マルチテナントデバイス又は仮想サービス（例えば、クラウドに基づくサービス）でもよく、物理デバイスに加えて或いはその代替として、仮想デバイス及びクラウドに基づくアプリケーションに容易に適用されてもよいことが理解されるべきである。

図２は、アプリケーションペイロードが多重され得る仮想通信リンク環境を示す。ここではアプリケーション暗号多重（application crypto multiplexing, ACM）環境200と呼ばれる環境200は、例えば、仮想通信リンク202と、クライアントプロキシ204と、アプリケーションクライアント206と、サーバプロキシ208と、アプリケーションサーバ210とを含む。

仮想通信リンク（例えば、仮想トンネル）は、そうでなければ直接的に相互にアドレス指定できない２つのコンピュータプログラム（例えば、クライアント及びサーバアプリケーション）を許容する。例えば、アプリケーションクライアント206のクライアントアプリケーションがリモート側のアプリケーションサーバ210のサーバアプリケーションに接続する必要があるときである。サーバアプリケーション210は、顧客又はパートナーのアドレス指定不可能なローカルネットワーク上（例えば、ファイアウォールの背後）のコンピュータ上にあってもよい。したがって、アプリケーションクライアント206は、アプリケーションサーバ210を直接的にアドレス指定できない。したがって、仮想通信リンクは、アプリケーションサーバ210に対するアプリケーションクライアント206のアクセスを提供し、逆も同様である。

開示の技術の実施例では、仮想通信リンク202は、同じデバイスからのサービスについてアプリケーションクライアント206及び／又はアプリケーションサーバ210に存在するアプリケーションのペイロードを多重及び／又は多重分離することにより、アプリケーションクライアント206及び／又はアプリケーションサーバ210に存在する１つ以上のアプリケーションが単一の通信チャネル（例えば、仮想通信リンク又はトンネル）を共有することを許容する。

より具体的には、クライアントプロキシ204及びサーバプロキシ208（図３を参照して以下に説明する）並びに仮想通信リンク202は、暗号仮想トンネル（virtual tunnel, VT）のような仮想通信リンク202を介して通信するためにアプリケーションクライアント206及びアプリケーションサーバ210のペイロードを多重及び／又は多重分離することにより、単一のソケットインタフェースを形成するようにチャネルのそれぞれの端で統合又は結合されてもよい。

一実施例では、多重及び／又は多重分離は、アプリケーション特有情報を搬送する特定のアプリケーションのペイロードにACMヘッダを追加することによって実現されてもよい。ヘッダについて、図５及び６を参照して以下により詳細に説明する。

アプリケーションクライアント206は、ネットワークコンフィグレーションプロトコル（network configuration protocol, NETCONF）プラグインのような第１クライアントアプリケーション206A、簡易ネットワーク管理プロトコル（simple network management protocol, SNMP）プラグインのような第２クライアントアプリケーション206B、及び／又はワイヤレスアクセスポイント制御及びプロビジョニング（control and provisioning of wireless access points, CAPWAP）プラグインのような第３クライアントアプリケーション206Cを含んでもよい。これらのプラグインは、デバイスのリモートコンフィグレーションのために使用され、トラヒックパターンがネットワークを形成する既存のネットワークデバイスにシームレスに注入されることを許容する。すなわち、トラヒックパターンをネットワークの様々なポイントに戦略的に導入するためにトラヒック生成器を配置するのではなく、所望のトラヒックパターンは、そうでなければネットワークデバイスのコンフィグレーションデータを操作するために使用されていたプラグインを介してカプセル化され、ネットワークの既存のネットワークデバイスに通信される。

例えば、NETCONFは、ネットワークデバイスを構成するための機構を提供し、ポリシーデータを含んでもよいコンフィグレーションデータのための拡張可能マークアップ言語（Extensible Markup Language, XML）に基づくデータ符号化を使用する。SNMPは、デバイス管理システムが管理されたエレメント内のコンフィグレーションデータを記憶する管理情報ベース（management information base, MIB）をトラバース（traverse）及び変更することを許容する。CAPWAPは、仮想通信リンクを介していずれかのメッシュノードとコントローラとの間でメッセージを交換するために使用されるプロトコルであり、元々はいわゆるライトウェイト（lightweight）アクセスポイントのために設計されたものである。

クライアントプロキシ204は、それぞれソケット（図３を参照して説明する）を介して第１、第２及び第３クライアントアプリケーション206A、206B及び206Cに動作可能に結合された暗号クライアント204Aを含む。

アプリケーションクライアント206と同様のアプリケーションサーバ210は、ソケットを介してアプリケーション暗号サーバに動作可能に結合されたNETCONFプラグインのような第１サーバアプリケーション210A、SNMPプラグインのような第２サーバアプリケーション210B及び／又はCAPWAPプラグインのような第３サーバアプリケーションのうち１つ以上を含んでもよい。

サーバプロキシ208は、それぞれソケット（図３を参照して説明する）を介して第１、第２及び第３クライアントアプリケーション210A、210B及び210Cに動作可能に結合された暗号サーバ208Aを含む。

したがって、ACM環境200は、SDNコントローラ112のようなSDNコントローラがパブリッククラウド又はインターネットのようなネットワークを使用してネットワークノード108及び110のようなネットワークデバイスと通信してネットワークデバイスを管理することを許容する。開示のACM環境200を使用することにより、ファイアウォールは、複数のアプリケーションをサポートするために複数のポートを開く必要はなくてもよい。むしろ、ACM環境200は、SDNコントローラ112が複数のアプリケーションを容易に管理することを許容する。ACM環境200はまた、TCPプロキシセッションオーバーヘッド及びトンネルペイロードオーバーヘッドを低減してもよく、同じデバイス上で実行する異なるアプリケーションとの制御プレーントラヒックのために使用されてもよい。

ACM環境200は、他の暗号技術とは異なる。例えば、インターネット鍵交換（Internet key exchange, IKE）／インターネットプロトコルセキュリティ（Internet protocol security, IPSEC）のような他の技術は、レイヤ3に基づくトンネリングを使用し、SSL技術はレイヤ4を使用する。これらの技術は、各アプリケーションについて１つのセッションを使用する。

図３は、図２によるACM環境におけるクライアント及びサーバプロキシを示す。ACM環境300は、例えば、クライアントプロキシ204及びサーバプロキシ208を通信可能に結合する暗号仮想トンネルのような仮想通信リンク202を含む。

クライアントプロキシ204は、セッションマネージャ302Aと、MUX／DEMUX306Aと、トランスポートレイヤセキュリティ（transport layer security, TLS）／データグラムTLS（datagram TLS, DTLS）クライアント304Aと、NETCONFクライアント（セッション1）310Aと、SNMPクライアント（セッション2）312Aとを含む。同様に、サーバプロキシ208は、セッションマネージャ302Bと、MUX／DEMUX306Bと、トランスポートレイヤセキュリティ（transport layer security, TLS）／データグラムTLS（datagram TLS, DTLS）クライアント304Bと、NETCONFクライアント（セッション1）310Bと、SNMPクライアント（セッション2）312Bとを含む。

セッションマネージャ302Aは、アプリケーションクライアント206（図２）とクライアントプロキシ204との間のトランスペアレントな安全且つオープンな通信を有効にする。一実施例では、セッションマネージャ302Aは、暗号化されたセッションハンドシェイクの管理、鍵の管理、証明書、認証、許可等を含む暗号化されたセッション処理を実行してもよい。さらに、一実施例では、セッションマネージャ302Aは、暗号化されたセッション及び／又は接続を確立すること、暗号化されたセッション及び／又は接続を終端すること、暗号化されたセッション及び／又は接続の中間者（man-in-the-middle）として自身を確立すること等を行ってもよい。

NETCONFクライアント1（セッション1）310A及びSNMPクライアント2（セッション2）312Aは、ソケットを介してセッションマネージャ302Aに通信可能に結合される。同様に、NETCONFクライアント1（セッション1）310B及びSNMPサーバ2（セッション2）312Bは、ソケットを介してセッションマネージャ302Bに通信可能に結合される。

クライアントプロキシ204A上のMUX／DEMUX306Aは、アプリケーションペイロードを多重することにより、アプリケーションクライアント206上の複数のソケットからのアプリケーションペイロードをクライアントプロキシ204上の単一のソケットにルーティングするように構成されてもよい。多重されたアプリケーションペイロードは、仮想通信リンク202を通じてプロキシサーバ208に搬送され、次に、アプリケーションサーバ210に配信されてもよい。一実施例では、MUX／DEMUX306Aは、単一の安全な接続（例えば、仮想通信リンク202）上で、クライアントプロキシ204から（サーバプロキシ208での多重分離後に）アプリケーションサーバ210上の対応する複数のソケットにアプリケーションペイロードを伝送するように構成される。

同様に、クライアントプロキシ204上のMUX／DEMUX306Aは、クライアントプロキシ204上の単一のソケットを使用して仮想通信リンク202からアプリケーションペイロードを受信するように構成されてもよい。アプリケーションサーバ210から受信したアプリケーションペイロードは、MUX／DEMUX306Aにより別個のアプリケーションペイロードに多重分離されてもよく、それぞれの別個のアプリケーションペイロードは、アプリケーションクライアント206上の１つ以上の対応するソケットに搬送されてもよい。一実施例では、MUX／DEMUX306Aは、単一の安全な接続（例えば、仮想通信リンク202）上で、サーバプロキシ204からアプリケーションクライアント206上の対応する複数のソケットへのアプリケーションペイロードを受信するように構成される。

以下に説明するように、MUX／DEMUX306Aはまた、ACMヘッダ情報を準備してアプリケーションペイロードに追加する役目をする。

ここで使用されるソケットという用語は、ネットワーク接続を介してリモートデバイスからHTTPフォーマットのようないずれかのフォーマットのデータを受信するように構成されたポート、バッファ、論理ノード又はオブジェクトを示す。MUX／DEMUX306Bも同様に構成されてもよい。

仮想通信リンク202Aを通じた通信を安全にするために、TLS／DTLSクライアント304A（クライアントプロキシ）及び304B（サーバプロキシ）が使用されてもよい。TLS／DTLSクライアント304A及び304Bは、多重／多重分離されたアプリケーションペイロードを暗号化／解読する役目をする。TLSプロトコルは、２つの通信するコンピュータアプリケーションの間でプライバシー及びデータ完全性を主に提供することを目的とする。TLSは、TCPのようなトランスポートプロトコルの上、且つHTTPのようなアプリケーションレイヤの下で動作するように設計されたものである。暗号的に安全なデータチャネルを確立するために、接続ピアは、どの暗号スイート（ciphersuite）が使用されるかと、データを暗号化するために使用される鍵とを合意しなければならない。TLSはまた、ユーザデーグラムプロトコル（user datagram protocol, UDP）のようなデータグラムプロトコル上で実行するように適合されている。データグラムTLS（datagram TLS, DTLS）は、UDPのようなデータグラム搬送を安全にできるTLSに基づくプロトコルであり、アプリケーションをトンネリングすること、例えば、メッシュネットワーク内のコントローラへのCAPWAPトンネルに良く適している。

図４Ａ及び４Ｂは、仮想通信リンクを通じてペイロードを送信及び受信するためのフロー図を示している。ここに記載の処理は、例えば、図３に示すクライアントプロキシ204及びサーバプロキシ208を使用して実現される。しかし、いずれかのネットワークコンポーネント又はエレメントは、このような実現の役目をしてもよく、開示の実施例は非限定的な例であることが認識される。

特に、図４Ａは、クライアントデータをサーバに送信するためのフローチャートを示す。クライアント310A及び／又は312Aは、TCP／UDPクライアント要求を生成し、アプリケーションデータ（例えば、ペイロード）をクライアントプロキシ204に送信する。402Aにおいて、アプリケーションデータは、クライアントプロキシ204によりセッションマネージャ302Aを介して受信される。ここで、セッションマネージャ302Aは、TCP接続を終端し、ローカルセッションからアプリケーションデータを読み取り、セッション情報を獲得する。状態（図７）及びセッションは管理され、セッションの詳細は、MUX／DEMUX306Aに送信される。

404Aにおいて、MUX／DEMUX306Aは、ACMヘッダを準備し、ACMヘッダをアプリケーションデータ（ペイロード）に追加する。ACMヘッダ及びアプリケーションペイロードについて、以下に図５及び６を参照して詳細に説明する。

406Aにおいて、TLS／DTLSクライアント304Aは、データ（アプリケーションデータ＋ACMヘッダ）を暗号化／解読し、仮想通信リンク202を介してアプリケーションデータをアプリケーションサーバ210に送信する役目をする。

412Aにおいて、暗号化／解読されたデータ（アプリケーション＋ACMヘッダ）は、仮想通信リンク202を介してサーバプロキシ208により受信され、410Aにおいて、MUX／DEMUX306Bは、ペイロードに対してACMヘッダを追加／削除する。

次に、408Aにおいて、サーバプロキシ208のセッションマネージャ302Bは、MUX／DEMUX306Bからアプリケーションデータを読み取り、アプリケーションサーバ210とのローカルセッションを生成／管理する。次に、アプリケーションデータは、セッションのセキュアソケットを介してアプリケーションサーバ210に送信され、クライアント310B及び／又は312Bは、要求を読み取り、アプリケーション応答を準備する。

図４Ｂは、サーバデータをクライアントに送信するためのフローチャートを示す。サーバ1 310B及び／又はサーバ2 312Bは、図４Ａのクライアント要求に応じてアプリケーション応答を準備する。402Bにおいて、セッションマネージャ302Bは、アプリケーションサーバ210からアプリケーションデータ（例えば、ペイロード）を読み取り、セッション情報のためのレコードを生成／管理する。次に、セッションマネージャ302Bは、セッション情報及びアプリケーションデータをMUX／DEMUX306Bに送信する。

404Bにおいて、MUX／DEMUX306は、セッション情報及びアプリケーションデータを読み取り、ACMヘッダからアプリケーションデータ（ペイロード）に追加／削除されるACMヘッダを準備する。406Bにおいて、TLS／DTLSサービス304Bは、アプリケーションデータ（アプリケーション＋ACMヘッダ）を暗号化し、クライアントプロキシ204及び仮想トンネルリンク202を介して暗号化されたアプリケーションデータをアプリケーションクライアント206に送信する。

暗号化されたアプリケーションデータがプロキシクライアント204のTLS／DTLSクライアント304Aにより受信されると、408Bにおいて、アプリケーションデータ（アプリケーション＋ACMヘッダ）が解読され、410Bにおいて、MUX／DEMUX306Aは、アプリケーションデータ（ペイロード）からACMヘッダを削除し、解読されたアプリケーションデータをセッションマネージャ302Aに送信する。次に、セッションマネージャ302Aは、MUX／DEMUX306Aからアプリケーションデータを読み取り、アプリケーションデータをクライアント1 310A及び／又はクライアント 312Aのためのそれぞれのソケットに送信し、応答は、アプリケーションサーバ210から受信される。

図５は、アプリケーションクライアント又はアプリケーションサーバのペイロードに追加されるシムレイヤを示す。シムレイヤは、オープンシステム間相互接続（open systems interconnection, OSI）レイヤ502のレイヤ4及び7の間に追加されるものとして示されている。図面はまた、NETCONFペイロード502Aと、SNMPペイロード502Bと、CAPWAPペイロード502Cとを含む３つのペイロードを示す。

図示のように、レイヤ3（IP）は、アドレッシング、ルーティング及びトラヒック制御を含む、マルチノードネットワークを構築及び管理するパケットレイヤである。レイヤ4（TCP／UDP）は、セグメント化、送達確認及び多重を含む、ネットワーク上のポイント間でのデータセグメントの伝送の役目をするトランスポートレイヤである。レイヤ5及び／又は6は、プレゼンテーション（レイヤ6）の一部として追加されたシムレイヤと、２つのノードの間での複数の行ったり来たりの伝送の形式での情報の継続交換のような通信セッションを管理するセッション（レイヤ5）とを含んでもよい。レイヤ7（NETCONF／SNMP／CAPWAP）は、リソース共有及びリモートファイルアクセスを含む、ハイレベルAPIを含むアプリケーションレイヤである。

図６は、図５のACMヘッダの例を示す。ACMヘッダは、例えば、ACMバージョンフィールドと、ACM動作（Op）タイプフィールドと、セキュリティセッション制御フィールドと、アプリケーションセッション／送信元ポートフィールドと、アプリケーション識別子（ID）フィールドと、ペイロード長フィールドとを含む。図示のヘッダは、ヘッダコンフィグレーションの非限定的な例であり、いずれかの数の変更が実現されてもよいことが認識される。

ACMヘッダ内に規定されたフィールドは、サイズ及び情報のタイプで変化してもよい。例として、１つの非限定的な実施例では、ACMバージョンフィールドは4ビットでもよく、初期バージョンを示してもよく、ACM Opタイプフィールドは4ビットでもよく、動作タイプを示してもよく、セキュリティセッション制御フィールドは2バイトでもよく、セキュリティセッション制御タイプを示してもよく、アプリケーションセッション／送信元ポートフィールドは2バイトでもよく、セッションID又は送信元ポートを示してもよく、アプリケーションIDフィールドは2バイトでもよく、アプリケーションTCP、UDP ID又は宛先ポートを示してもよく、ペイロード長は2バイトでもよく、ペイロードのサイズを示してもよい。

ペイロードは、ACMハロー要求、ACMハロー応答、ACM送達確認、ACMデータ又はデータ転送、ACMサービス更新、ACMサービス更新送達確認、ACMヘルス統計要求、ACMヘルス統計応答、ACM制御／アラート／エラー、ACMハートビート要求及び／又はACMハートビート応答のうちいずれか１つ以上になるように構成されてもよい。

図７は、ACMデータセッション状態機械の状態図を示す。ACMデータセッション状態機械は、初期状態702と、データ書き込み状態704／710と、データ読み取り状態706／712と、セッションクローズ状態708とを含む。以下の図７に示すように、データ動作状態は、セッション開始イベント（CE）-11、データ読み取り／データ書き込みイベント（DRWS）-01、データ読み取り／データ書き込み終了イベント（DRWE）-10及びセッションクローズイベント（CT）-00に従って規定されてもよい。

図８Ａ及び８Ｂは、ネットワーク内でアプリケーションペイロードを伝送する例示的なフロー図を示す。図８Ａを参照すると、802において、アプリケーションクライアント206に存在する１つ以上のアプリケーション206A、206B及び206Cにそれぞれ対応する１つ以上のアプリケーションペイロード502A、502B及び502Cが、例えば、プロキシクライアント204により受信される。アプリケーションペイロードは、TCP又はUDPのようなトランスポートレイヤプロトコルを含むクライアント要求から形成される。

804において、プロキシクライアント204により受信されたアプリケーションペイロードは、例えば、セッションマネージャ302Aにより終端され、アプリケーションペイロードは、現在のセッションのために読み取られる。

806において、MUX／DEMUX306Aは、アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備し、808において、TLS／DTLSクライアント304Aは、単一の仮想通信リンク202を介してネットワーク内で伝送するために、ヘッダ情報を含むアプリケーションペイロードを暗号化する。

図８Ｂを参照すると、単一の通信チャネル（すなわち、仮想通信リンク）を通じて共有するために、アプリケーションペイロードに挿入されるヘッダ情報を含む１つ以上のアプリケーションペイロードは多重されてもよい。

812において、多重されたアプリケーションペイロードは、共有された通信リンクを介して伝送される。エンドポイント（例えば、サーバプロキシ208）に到達したときに、814において、アプリケーションペイロードは、アプリケーションサーバ210がクライアントからの要求に応答し得るように多重分離（及び解読）される。

図９は、開示が実現され得る例示的なネットワークを示す。ネットワーク900は、クラウド902と、ネットワーク906と、クラウドプロバイダ908と、クライアント914A、914B〜914Nとを含む。

クラウド902は、１つ以上のホスト904〜904N（併せて904N）を含み、各ホスト904Nは、１つ以上のノード904N1を含む。一実施例では、ノード904N1は、ホスト904〜ホスト904Nのような物理マシン上にホストされる仮想マシン（virtual machine, VM）である。他の実施例では、ホストマシン904Nは、データセンタに位置してもよい。例えば、１つ以上のノード904N1は、クラウドプロバイダ908により提供されるクラウド902内の物理マシン904N上にホストされる。ホストマシン904N上にホストされるときに、ユーザは、クライアント914A、914B〜914Nのようなクライアントコンピュータシステムを使用して１つ以上のノード904N1上で実行するアプリケーション904N1-2及び904N1-3のような１つ以上のアプリケーションと相互作用できる。一実施例では、アプリケーション904N1-2及び904N1-3は、VMを使用せずにホスト904N上にホストされてもよい。

前述のように、１つ以上のノード904N1は、異なるユーザ及び／又は組織により所有又は管理され得る１つ以上のアプリケーション904N1-2及び904N1-3を実行する。例えば、顧客は、第１顧客のアプリケーションをホストしている同じノード又は異なるノード904N上に、他の顧客のアプリケーションと共存し得るアプリケーション904N1-2及び904N1-3を配置してもよい。一実施例では、一部又は別々のアプリケーション904N1-2及び904N1-3が異なるノード904N上で実行する。

一実施例では、当業者により認識されるように、アプリケーション904N1-2及び904N1-3の実行に使用されるデータは、予め存在するアプリケーションコンポーネントから構築されたアプリケーションイメージと、アプリケーション904N1-2及び904N1-3を管理するユーザのソースコードとを含む。SDN及びコンテナネットワーキングの状況におけるイメージは、アプリケーションの実行時インスタンスのための機能を配置するために使用されるアプリケーションの実行形式及びファイルを表すデータを示す。一例では、イメージは、Dockerツールを使用して構築され、Dockerイメージと呼ばれる。以下に説明するように、ドケットブリッジは、本発明の様々な実施例を実現する際に必要ではないが、このようなdockerブリッジは使用から排除されない。

１つ以上のノード904N1-2及び904N1-3は、ノード904N1-2及び904N1-3の１つ以上の中のコンテナ904N1-2A、904N1-2B、904N1-3A及び904N1-3Bとしてアプリケーションイメージのインスタンスを起動することにより、アプリケーションを実行してもよい。ノード904N1-2及び904N1-3の１つ以上の中のコンテナ904N1-2A、904N1-2B、904N1-3A及び904N1-3Bは、アプリケーション904N1-2及び904N1-3の機能を実現してもよい。

コンテナ904N1-2A、904N1-2B、904N1-3A及び904N1-3Bは、オペレーティングシステムレベルの仮想化を実現してもよく、抽象レイヤは、ホストコンピュータ（図示せず）上のオペレーティングシステムのカーネルの上に提供される。抽象レイヤは、例えば、アプリケーション及びその依存関係をそれぞれ含む複数のコンテナをサポートする。各コンテナは、オペレーティングシステム上の隔離されたプロセスとして実行してもよく、他のコンテナとカーネルを共有する。コンテナは、リソース隔離（CPU、メモリ、ブロックI/O、ネットワーク等）を利用してネーム空間を分離し、動作環境のアプリケーションのビューを完全に隔離するために、カーネルの機能に依存する。コンテナを使用することにより、リソースは隔離でき、サービスは制限でき、プロセスは、自分のプロセスID空間、ファイルシステム構成及びネットワークインタフェースを用いてオペレーティングシステムのプライベートビューを有するように提供できる。複数のコンテナは、同じカーネルを共有できるが、各コンテナは、CPU、メモリ及びI/Oのような規定された量のリソースのみを使用することに制限できる。

クライアント914A、914B〜914Nは、ネットワーク906を介してクラウドプロバイダ908によりクラウド902内のホスト904Nに接続されてもよく、ネットワーク906は、プライベートネットワーク（例えば、ローカルエリアネットワーク（local area network, LAN）、広域ネットワーク（wide area network, WAN）、イントラネット又は他の同様のプライベートネットワーク）又はパブリックネットワーク（例えば、インターネット）でもよい。各クライアント914A、914B〜914Nは、モバイルデバイス、PDA、ラップトップ、デスクトップコンピュータ、タブレットコンピューティングデバイス、サーバデバイス又は他のコンピューティングデバイスでもよい。各ホスト904Nは、サーバコンピュータシステム、デスクトップコンピュータ又は他のコンピューティングデバイスでもよい。

様々な実施例は、前述のネットワークに関して記載されているが、当業者は、そのネットワークが非限定的な例であり、単一のモノリシックコンピュータシステム及び様々な方法で接続されたコンピュータシステム又は同様のデバイスの様々な他の組み合わせを含む様々な他のコンフィグレーションで実現されてもよいことを認識する。

図１０は、ホスト内通信のための仮想入力／出力インタフェースを使用した例示的なコンテナパケット通信を示す。従来のSDNでは、コンテナは、例えば、指定のレジストリから収集されたアプリケーションイメージから生成される。コンテナが（典型的には、デーモンにより）インスタンス化されるときに、コンテナは、コンテナをdockerブリッジのような仮想イーサーネットブリッジに接続する固有のネットワークアドレスを割り当てられる。システム内の全てのコンテナは、パケットをdockerブリッジに向けることにより相互に通信し、次に、これは、コンテナネットワークを通じてこれらのパケットを転送する。しかし、コンテナは、重いブリッジポート上で相互に通信し、オープンvSwitch（OVS）及び／又はlinuxカーネルブリッジ機構を利用する。

他の実施例では、コンテナ1002、1004及び1006は、オペレーティングシステムレベルの仮想化のようなサーバ仮想化方法を活用してもよく、オペレーティングシステムのカーネルは、複数の隔離されたユーザ空間インスタンスを許容する。このいくつかのインスタンスは、コンテナ、仮想化エンジン（virtualization engine, VE）、仮想プライベートサーバ（virtual private server, VPS）、jail若しくはゾーン及び／又はこれらのいずれかのハイブリッド結合を含んでもよいが、これらに限定されない。コンテナ1002、1004及び1006のためのいくつかの例示的な利用可能な技術は、chroot, Linux-VServer、lmctfy（「let me contain that for you」）、LXC（Linuxコンテナ）、OpenVZ（オープンVirtuozzo）、Parallels Virtuozzoコンテナ、Solarisコンテナ（及びSolarisゾーン)、FreeBSD Jail、sysjail、WPAR（ワークロードパーティション）HP-UXコンテナ（SRP, セキュアリソースパーティション）、iCore仮想アカウント及びSandboxieを含む。

開示の技術によって、直接のコンテナレベルの通信が仮想入力／出力（virtual input/output, VIO）1010A／B（又は入力／出力仮想化（input/output virtualization（IOV））を介して可能になる。VIOでは、単一の物理アダプタカードは、複数の仮想ネットワークインタフェースカード（network interface card, NIC）及び仮想ホストバスアダプタ（host bus adapter, HBA）として動作する。これらのVIO1010A／Bは、ホスト1008（図１０に示す）にロードされ、専用リンクのような通信リンク1-6を介してコンテナ1002、1004及び1006に入力してこれらから出力するデータパケットを制御するために使用できるVIOソフトウェア及び／又はハードウェアを含んでもよい。各VIO1010A／Bは、直接的に他のデータコンテナ1002、1004及び1006へのデータパケットを多重及び多重分離でき、それにより、ホスト内コンテナ通信の制限を解決する。このようなコンフィグレーションは、容易な配置、スケーラビリティ及び小さい通信オーバーヘッドを許容し得る。

図１０を参照すると、直接のコンテナレベルの通信は、コンテナ1002、1004及び1006が、ホスト1008とインタフェースするVIO1010A／Bを介して通信リンク1-6を使用して相互に通信可能に結合されることにより実現される。一実施例では、各コンテナ1002、1004及び1006は、その間の通信をサポートするブリッジを必要とすることなく、VIO1010A／Bのそれぞれ１つ以上に接続された仮想ネットワークインタフェースカード（virtual network interface card, vNIC）を含んでもよい。VIO1010A／Bは、ブリッジ又はOVSを使用してパケットを送信してもよいこともまた認識される。

例として、コンテナ1002、1004及び1006が専用リンク1、2、3及び6を含むことを仮定する（説明の目的で、リンク4及び5が存在しないことを仮定する）。コンテナ1002、1004及び1006のそれぞれは、各コンテナとVIOとの間に専用仮想リンクを生成する。したがって、コンテナ1002は、コンテナ1002とVIO1010Aとの間のリンク（1）と、コンテナ1002とVIO1010Bとの間のリンク（6）とを形成し、コンテナ1004は、コンテナ1004とVIO1010Aとの間のリンク（2）を形成し、コンテナ1006は、コンテナ1006とVIO1010Bとの間のリンク（3）を形成する。

図１１は、ホスト間通信のための仮想入力／出力インタフェースを使用した例示的なコンテナパケット通信を示す。ホスト間インスタンスは、それぞれのホスト1114及びホスト1116内のVIO1122A／Bに通信可能に結合されたコンテナ1102、1104、1106、1108、1110及び1112を含む。図１０の説明と同様に、コンテナは、VIO1122A／Bを介した直接のアプリケーションレベルの通信のための専用仮想リンクを生成する。専用仮想リンクは、例えば、入力キューを使用して、直接的に１つ又は複数の物理リンク1120に多重されてもよい。

物理リンク1120は、ホスト1114及びホスト1116のようなホストのそれぞれを有効にする。物理ネットワークインタフェース1120は、ハードウェア、ソフトウェア又はこれらの組み合わせでいずれかの形式のI/O仮想化（IOV）のためのサポートを提供するネットワークI/Oデバイスでもよい。IOVデバイスの例は、PCI-SIG準拠のSR-IOVデバイス及び非SR-IOVデバイス、PCI-SIG準拠のMR-IOVデバイス、マルチキューNIC、I/Oアダプタ、集合NIC及び集合ネットワークアダプタ（converged network adapter, CAN）を含むが、これらに限定されない。

一例の実施例では、３つの専用仮想リンクがコンテナとVIOとの間にそれぞれのホスト1114及びホスト1116に存在することを仮定する。ホスト1114では、コンテナ1102はリンク1を生成し、コンテナ1104はリンク2を生成し、コンテナ1106はリンク3を生成する。ホスト1116では、コンテナ1108はリンク4を生成し、コンテナ1110はリンク5を生成し、コンテナ1112はリンク6を生成する。ホスト1114内で、コンテナ1102、1104及び1106からVIO1122A／Bへの情報は、ホスト1116への伝送のために、１つ以上の物理リンク1120に多重されてもよい。コンテナ情報のいずれか１つ以上が多重されてもよく、及び／又は１つ以上の物理リンクを通じて伝送されてもよいことが認識される。ホスト1116において受信したときに、伝送は多重分離され、コンテナ1108、1110及び1112のそれぞれ１つ以上に送信されてもよい。

図１２及び１３は、TCP及び関係するソケットを消費する必要なくVIOを使用した直接のデータベース／アプリケーションレベルの通信の様々な実施例を示す。１つ以上の実施例は、データベース（database, DB）の使用のための共通のアプリケーションプログラミングインタフェース（application programming interface, API）のために標準化されてもよい。VIOを介した直接のDB／アプリケーションレベルの通信は、容易な使用、スケーラビリティ及び小さい通信オーバーヘッドを許容する。

開示の技術によって、直接のDBインスタンスレベルの通信が仮想入力／出力（virtual input/output, VIO）1210A／B（又は入力／出力仮想化）を介して可能になる。VIOでは、単一の物理アダプタカードは、複数の仮想ネットワークインタフェースカード（network interface card, NIC）及び仮想ホストバスアダプタ（host bus adapter, HBA）として動作する。これらのVIO1210A／Bは、ホスト1208にロードされ、専用リンクのような通信リンク1-6を介してDBインスタンス1202、1204及び1206に入力してこれらから出力するデータパケットを制御するために使用できるVIOソフトウェア及び／又はハードウェアを含んでもよい。各VIO1210A／Bは、直接的に他のDBインスタンス1202、1204及び1206へのデータパケットを多重及び多重分離でき、それにより、ホスト内インスタンス通信の制限を解決する。このようなコンフィグレーションは、容易な配置、スケーラビリティ及び小さい通信オーバーヘッドを許容し得る。

特に、図１２は、ホスト内通信のための仮想入力／出力インタフェースを使用して通信する例示的なデータベースインスタンスを示す。認識できるように、データベース（database, DB）インスタンスは、一式のデータベースファイルにアクセスする一式のメモリ構成及びバックグラウンド処理である。処理は、ユーザの全てにより共有できる。

直接のDBインスタンスレベルの通信は、DBインスタンス1202、1204及び1206が、ホスト1208とインタフェースするVIO1210A／Bを介して通信リンク1-6を使用して相互に通信可能に結合されることにより実現される。一実施例では、各コンテナ1202、1204及び1206は、その間の通信をサポートするブリッジを必要とすることなく、VIO1210A／Bのそれぞれ１つ以上に接続された仮想ネットワークインタフェースカード（virtual network interface card, vNIC）を含んでもよい。VIO1210A／Bは、ブリッジ又はOVSを使用してパケットを送信してもよいこともまた認識される。

例として、コンテナ1202、1204及び1206が専用リンク1、2、3及び6を含むことを仮定する（説明の目的で、リンク4及び5が存在しないことを仮定する）。DBインスタンス1202、1204及び1206のそれぞれは、各コンテナとVIOとの間に専用仮想リンクを生成する。したがって、DBインスタンス1202は、DBインスタンス1202とVIO1210Aとの間のリンク（1）と、DBインスタンス1202とVIO1210Bとの間のリンク（6）とを形成し、DBインスタンス1204は、DBインスタンス1204とVIO1210Aとの間のリンク（2）を形成し、DBインスタンス1206は、DBインスタンス1206とVIO1210Bとの間のリンク（3）を形成する。

図１３は、ホスト間通信のための仮想入力／出力インタフェースを使用した例示的なDBインスタンスパケット通信を示す。ホスト間インスタンスは、それぞれのホスト1314及びホスト1316内のVIO1322A／Bに通信可能に結合されたインスタンス1302、1304、1306、1308、1310及び1312を含む。図１２の説明と同様に、DBインスタンスは、VIO1322A／Bを介した直接のアプリケーションレベルの通信のための専用仮想リンクを生成する。専用仮想リンクは、例えば、TCPソケットに依存せずに、入力キューを使用して、直接的に１つ又は複数の物理リンク1320に多重されてもよい。

物理リンク1320は、ホスト1314及びホスト1316のようなホストのそれぞれを有効にする。物理ネットワークインタフェース1320は、ハードウェア、ソフトウェア又はこれらの組み合わせでいずれかの形式のI/O仮想化（IOV）のためのサポートを提供するネットワークI/Oデバイスでもよい。IOVデバイスの例は、PCI-SIG準拠のSR-IOVデバイス及び非SR-IOVデバイス、PCI-SIG準拠のMR-IOVデバイス、マルチキューNIC、I/Oアダプタ、集合NIC及び集合ネットワークアダプタ（converged network adapter, CAN）を含むが、これらに限定されない。

一例の実施例では、３つの専用仮想リンクがDBインスタンスとVIOとの間にそれぞれのホスト1314及びホスト1316に存在することを仮定する。ホスト1314では、DBインスタンス1302はリンク1を生成し、DBインスタンス1304はリンク2を生成し、DBインスタンス1306はリンク3を生成する。ホスト1316では、DBインスタンス1308はリンク4を生成し、DBインスタンス1310はリンク5を生成し、DBインスタンス1312はリンク6を生成する。ホスト1314内で、DBインスタンス1302、1304及び1306からVIO1322A／Bへの情報は、ホスト1316への伝送のために、１つ以上の物理リンク1320に多重されてもよい。DBインスタンス情報のいずれか１つ以上が多重されてもよく、及び／又は１つ以上の物理リンクを通じて伝送されてもよいことが認識される。ホスト1116において受信したときに、伝送は多重分離され、DBインスタンス1308、1310及び1312のそれぞれ１つ以上に送信されてもよい。

図１４Ａ及び１４Ｂは、コンテナ及びデータベースインスタンスのための仮想リンクを構築する例示的なフロー図を示す。図１４Ａを参照すると、フロー図は、直接通信リンクを介して通信するアプリケーションコンテナに関する。1402において、１つ以上の第１専用仮想リンク1-6は、１つ以上の第１アプリケーションコンテナの間の直接のアプリケーションコンテナレベルの通信のために（例えば、個別のコンテナ1002、1004及び1006により）構築される。次に、1404において、データは、対応する１つ以上の第１専用通信リンク1-6を介して１つ以上の第１アプリケーションコンテナ1002、1004及び1006の間で通信されてもよく、１つ以上の第１専用仮想リンク1-6のそれぞれは、第１端で１つ以上の第１アプリケーションコンテナ1002、1004及び1006のそれぞれに接続され、第２端でそれぞれの仮想入力／出力（virtual input/output, VIO）に接続される。

図１４Ｂを参照すると、フロー図は、仮想入力／出力（virtual input/output, VIO）を介して直接のデータベース対アプリケーションレベルの通信を提供することに関する。1406において、１つ以上の第１専用仮想リンク1-6は、１つ以上の第１DBインスタンス1202、1204及び1206の間の直接のアプリケーションコンテナレベルの通信のために（例えば、個別のDBインスタンス1202、1204及び1206により）構築される。次に、1408において、データは、対応する１つ以上の第１専用通信リンク1-6を介して１つ以上の第１DBインスタンス1202、1204及び1206の間で通信されてもよく、１つ以上の第１専用仮想リンク1-6のそれぞれは、第１端で１つ以上の第１DBインスタンス1202、1204及び1206のそれぞれに接続され、第２端でそれぞれの仮想入力／出力（virtual input/output, VIO）に接続される。

図１５は、開示の実施例によるノードの実施例を示す。ノードは、例えば、ノード108及び110（図１）又はネットワーク内の前述のような他のノード若しくはルータでもよい。ノード1500は、他のノードからのデータを受信及び伝送するための複数の入力／出力ポート15110／1530及び／又は受信機（Rx）1512及び送信機（Tx）1532、データを処理してどのノードがデータを送信するかを決定するための、記憶装置1522及びプログラム可能コンテンツ転送プレーン1528を含む処理システム又はプロセッサ1520（又はコンテンツアウェアユニット）を含んでもよい。ノード1500はまた、前述のようなアプリケーションデータ（ペイロード）を受信してもよい。

単一のプロセッサとして示されているが、プロセッサ1520はこれに限定されず、複数のプロセッサを含んでもよい。プロセッサ1520は、１つ以上の中央処理装置（central processing unit, CPU）チップ、コア（例えば、マルチコアプロセッサ）、フィールドプログラマブルゲートアレイ（field-programmable gate array, FPGA）、特定用途向け集積回路（application specific integrated circuit, ASIC）及び／又はデジタルシグナルプロセッサ（digital signal processor, DSP）として実現されてもよく、及び／又は１つ以上のASICの一部でもよい。プロセッサ1520は、実施例に記載のステップのうちいずれか１つ又は組み合わせを使用して、図４Ａ／Ｂ、８及び１４に示す処理のような、ここに記載の方式のいずれかを実現するように構成されてもよい。さらに、プロセッサ1520は、ハードウェア、ソフトウェア又は双方を使用して実現されてもよい。

記憶装置1522（又はメモリ）は、キャッシュ1524と、長期記憶装置1526と、データベースクラスタ通信モジュール1528とを含んでもよく、ルーティングテーブル、転送テーブル又はここに開示された他のテーブル若しくは情報を記憶するように構成されてもよい。単一の記憶装置として示されているが、記憶装置1522は、読み取り専用メモリ（read only memory, ROM）、ランダムアクセスメモリ（random access memory, RAM）又は２次記憶装置（例えば、データの不揮発性記憶に使用される１つ以上のディスクドライブ又はテープドライブ）の組み合わせとして実現されてもよい。

データベースクラスタ通信モジュール1528の包含は、ノード1500の機能に対する改善を提供する。データベースクラスタ通信モジュール1528はまた、異なる状態へのノード1500の変換を行う。或いは、データベースクラスタ通信モジュール1528は、プロセッサ1520に記憶された命令として実現される。

図１６は、様々な実施例を実現するために使用できるネットワークシステムのブロック図である。具体的なデバイスは、図示のコンポーネントの全て又はコンポーネントのサブセットのみを利用してもよく、統合のレベルは、デバイス毎に変化してもよい。さらに、デバイスは、複数の処理ユニット、プロセッサ、メモリ、送信機、受信機等のようなコンポーネントの複数のインタフェースを含んでもよい。ネットワークシステムは、ネットワークインタフェース、記憶インタフェース等のような１つ以上の入力／出力デバイスを備えた処理ユニット1601を含んでもよい。処理ユニット1601は、バスに接続された中央処理装置（central processing unit, CPU）1610と、メモリ1620と、大容量記憶デバイス1630と、I/Oインタフェース1660とを含んでもよい。バスは、メモリバス又はメモリコントローラ、周辺機器バス等を含むいずれかの種類の複数のバスアーキテクチャのうち１つ以上でもよい。

CPU1610は、いずれかの種類の電子データプロセッサを含んでもよい。メモリ1620は、スタティックランダムアクセスメモリ（static random access memory, SDRAM）、ダイナミックランダムアクセスメモリ（dynamic random access memory, DRAM）、シンクロナスDRAM（synchronous DRAM, SDRAM）、読み取り専用メモリ（read-only memory, ROM）、これらの組み合わせ等のようないずれかの種類のシステムメモリを含んでもよい。実施例では、メモリ1620は、ブートアップ時に使用するROMと、プログラムを実行する間に使用するプログラム及びデータ記憶のためのDRAMとを含んでもよい。実施例では、メモリ1620は非一時的である。大容量記憶デバイス1630は、データ、プログラム及び他の情報を記憶し、バスを介してデータ、プログラム及び他の情報をアクセス可能にするように構成されたいずれかの種類の記憶デバイスを含んでもよい。大容量記憶デバイス1630は、例えば、ソリッドステートドライブ、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ等のうち１つ以上を含んでもよい。

処理ユニット1601はまた、１つ以上のネットワークインタフェース1650を含み、これは、ノード又は１つ以上のネットワーク1680にアクセスするために、イーサーネットケーブル等のような有線リンクを含んでもよい。ネットワークインタフェース1650は、処理ユニット1601がネットワーク1680を介してリモートユニットと通信することを許容にする。例えば、ネットワークインタフェース1650は、１つ以上の送信機／送信アンテナ及び１つ以上の受信機／受信アンテナを介して無線通信を提供してもよい。実施例では、処理ユニット1601は、他の処理ユニット、インターネット、リモート記憶施設等のようなリモートデバイスとの通信及びデータ処理のために、ローカルエリアネットワーク又は広域ネットワークに結合される。

図１７は、開示の技術によるブロック図を示す。受信機／送信機モジュール1702は、クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信及び送信する。終端モジュール1704は、トランスポートレイヤプロトコルを終端し、現在のセッションに関連するアプリケーションペイロードを読み取る。準備器モジュール1706は、アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備する。暗号化／解読モジュール1708は、単一の仮想通信リンクを介してネットワーク内で伝送するために、ヘッダ情報を含むアプリケーションペイロードを暗号化／解読する。多重／多重分離モジュール1710は、単一の通信チャネル（仮想通信リンク）を通じて伝送され得るように、アプリケーションペイロードを多重／多重分離する。最後に、仮想I/Oモジュール1712は、アプリケーションコンテナがホストに存在する仮想入力／出力（virtual input/output, VIO）を使用して直接的に相互に通信することを許容する。

開示の技術は、単一の暗号チャネルを通じて多重／多重分離及び搬送されたアプリケーションペイロードを有する同じデバイスからの複数の安全なアプリケーションを提供する。セッション確立オーバーヘッド及びトンネルオーバーヘッドがないこと、TCPプロキシセッションのオーバーヘッド及びトンネルペイロードオーバーヘッドを低減すること、同じデバイス上で実行する異なるアプリケーションとの制御プレーントラヒックのために使用できること、安全なセッション確立（非対称及び対称）の数を低減すること、パブリッククラウド又はインターネットを通じたSDNコントローラからネットワークデバイスの通信、単一の暗号セッションを通じて複数のアプリケーションを多重すること、ファイアウォールが複数のアプリケーションのためのサポートのために複数のポートを開く必要がないこと、インターネット／クラウドを通じてネットワーキングデバイス（ルータ／スイッチ／WIFI／IOT）を管理すること、並びにNetconf、SNMP及びCapwapのような複数のアプリケーションの容易な管理を含み、１つ以上の利点がこの技術から生じる。

開示の技術の他の実施例は、以下の非限定的な利点を有利に提供する。VIOは、エンドツーエンドの通信経路を短縮するため、通信待ち時間を低減し、そのため、データベースの全体性能を改善する。VIOは、データベースインタフェースの間の同時接続の総数を低減でき、通常では、１つのサーバが設定してデータメッセージを送信できるTCP接続の数に厳しい制限が存在する。これは、データベースクラスタのスケーラビリティを改善し、これは、より多くのデータベースインタフェースがデータベースクラスタに入れられることができ、より多くのクエリがデータベースクラスタにより同時に処理できることを意味する。これはまた、全体のデータベースシステム性能を改善する。

本開示の様々な実施例によれば、ここに記載の方法は、ソフトウェアプログラムを実行するハードウェアコンピュータシステムを使用して実現されてもよい。さらに、非限定的な実施例では、実現は、分散処理、コンポーネント／オブジェクト分散処理及び並列処理を含むことができる。仮想コンピュータシステム処理は、ここに記載の方法又は機能のうち１つ以上を実現するように構築でき、ここに記載のプロセッサは、仮想処理環境をサポートするために使用されてもよい。

本開示の態様は、開示の実施例による方法、装置（システム）及びコンピュータプログラムプロダクトのフローチャート図及び／又はブロック図を参照してここに記載している。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図のブロックの組み合わせは、コンピュータプログラム命令により実現できることが理解される。これらのコンピュータプログラム命令は、汎用コンピュータ、特殊目的コンピュータ又は他のプログラム可能データ処理装置のプロセッサに提供され、命令がコンピュータ又は他のプログラム可能命令実行装置を介して実行するときに、フローチャート及び／又はブロック図のブロックに指定された機能／動作を実現するための機構を生成するような機械を生成してもよい。

ここで使用される用語は、特定の態様を説明するための目的のみのためであり、開示の限定であることを意図しない。ここで使用される単数形は、文脈がそうでないことを明らかに示さない限り、複数形も同様に含むことを意図する。「含む」及び／又は「含んでいる」という用語は、この明細書で使用されるときに、言及した特徴、整数、ステップ、動作、エレメント及び／又はコンポーネントの存在を指定するが、１つ以上の他の特徴、整数、ステップ、動作、エレメント、コンポーネント及び／又はこれらのグループの存在又は追加を除外しないことが更に理解される。

本開示の説明は、例示及び説明の目的で提示されており、網羅的であること又は開示の形式の開示に限定されることを意図しない。多くの変更及び変形は、開示の範囲及び真意を逸脱することなく、当業者に明らかになる。ここでの開示の態様は、開示の原理及び実際の適用を最も良く説明し、当業者が考えられる特定の使用に適した様々な変更を有する開示を理解可能とするために選択及び記載されている。

この文献の目的で、開示の技術に関連する各処理は、１つ以上のコンピューティングデバイスにより連続的に実行されてもよい。処理の各ステップは、他のステップで使用されるものと同じ或いは異なるコンピューティングデバイスにより実行されてもよく、各ステップは、必ずしも単一のコンピューティングデバイスにより実行される必要はない。

対象物は、構造的な特徴及び／又は方法論的な動作に特有の言語で記載されているが、添付の特許請求の範囲に規定される対象物は、前述の具体的な特徴又は動作に必ずしも限定されないことが理解される。むしろ、前述の具体的な特徴及び動作は、特許請求の範囲を実現する例示的な形式として開示される。

Claims (12)

1. ネットワーク内でアプリケーションペイロードを伝送する方法であって、
   クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するステップであり、前記アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成されるステップと、
   前記トランスポートレイヤプロトコルを終端し、現在のセッションに関連する前記アプリケーションペイロードを読み取るステップと、
   前記アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するステップと、
   単一の仮想通信リンクを介して前記ネットワーク内で伝送するために、前記ヘッダ情報を含む前記アプリケーションペイロードを暗号化するステップと
   を含み、
   シムレイヤが、アプリケーションペイロードと伝送制御プロトコル（transmission control protocol, TCP）／セキュアソケットレイヤ（secure socket layer, SSL）ヘッダとの間に前記ヘッダ情報として追加される方法。
2. ネットワーク内でアプリケーションペイロードを伝送する方法であって、
   クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するステップであり、前記アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成されるステップと、
   前記トランスポートレイヤプロトコルを終端し、現在のセッションに関連する前記アプリケーションペイロードを読み取るステップと、
   前記アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するステップと、
   単一の仮想通信リンクを介して前記ネットワーク内で伝送するために、前記ヘッダ情報を含む前記アプリケーションペイロードを暗号化するステップと
   を含み、
   前記仮想通信リンクは、前記クライアントに存在する前記アプリケーションのうち１つ以上が前記アプリケーションペイロードを多重することにより単一の通信チャネルを共有することを許容する方法。
3. 前記１つ以上のアプリケーションは、NETCONF、SNMP及びCAPWAPのうち１つを含む、請求項１又は２に記載の方法。
4. 前記ヘッダ情報は、バージョンフィールドと、動作タイプフィールドと、セキュリティセッション制御フィールドと、アプリケーションセッションフィールドと、アプリケーションIDフィールドと、ペイロード長とのうち少なくとも１つを含む、請求項１乃至３のうちいずれか１項に記載の方法。
5. 仮想通信リンクは、暗号化された仮想トンネルである、請求項１乃至４のうちいずれか１項に記載の方法。
6. ネットワーク内でアプリケーションペイロードを伝送するためのコンピュータ命令を記憶した非一時的なコンピュータ読み取り可能媒体であって、
   前記コンピュータ命令は、１つ以上のプロセッサにより実行されたときに、前記１つ以上のプロセッサに対して、
   クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するステップであり、前記アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成されるステップと、
   前記トランスポートレイヤプロトコルを終端し、現在のセッションに関連する前記アプリケーションペイロードを読み取るステップと、
   前記アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するステップと、
   単一の仮想通信リンクを介して前記ネットワーク内で伝送するために、前記ヘッダ情報を含む前記アプリケーションペイロードを暗号化するステップと
   を実行させ、
   シムレイヤが、アプリケーションペイロードと伝送制御プロトコル（transmission control protocol, TCP）／セキュアソケットレイヤ（secure socket layer, SSL）ヘッダとの間に前記ヘッダ情報として追加される非一時的なコンピュータ読み取り可能媒体。
7. ネットワーク内でアプリケーションペイロードを伝送するためのコンピュータ命令を記憶した非一時的なコンピュータ読み取り可能媒体であって、
   前記コンピュータ命令は、１つ以上のプロセッサにより実行されたときに、前記１つ以上のプロセッサに対して、
   クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するステップであり、前記アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成されるステップと、
   前記トランスポートレイヤプロトコルを終端し、現在のセッションに関連する前記アプリケーションペイロードを読み取るステップと、
   前記アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するステップと、
   単一の仮想通信リンクを介して前記ネットワーク内で伝送するために、前記ヘッダ情報を含む前記アプリケーションペイロードを暗号化するステップと
   を実行させ、
   前記仮想通信リンクは、前記クライアントに存在する前記アプリケーションのうち１つ以上が前記アプリケーションペイロードを多重することにより単一の通信チャネルを共有することを許容する非一時的なコンピュータ読み取り可能媒体。
8. ネットワーク内でアプリケーションペイロードを伝送するための装置であって、
   クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するための受信機／送信機モジュールであり、前記アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成される受信機／送信機モジュールと、
   前記トランスポートレイヤプロトコルを終端し、現在のセッションに関連する前記アプリケーションペイロードを読み取るための終端モジュールと、
   前記アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するための準備器モジュールと、
   単一の仮想通信リンクを介して前記ネットワーク内で伝送するために、前記ヘッダ情報を含む前記アプリケーションペイロードを暗号化するための暗号化／解読モジュールと
   を含み、
   シムレイヤが、アプリケーションペイロードと伝送制御プロトコル（transmission control protocol, TCP）／セキュアソケットレイヤ（secure socket layer, SSL）ヘッダとの間に前記ヘッダ情報として追加される装置。
9. ネットワーク内でアプリケーションペイロードを伝送するための装置であって、
   クライアントに存在する１つ以上のアプリケーションに対応する１つ以上のアプリケーションペイロードを受信するための受信機／送信機モジュールであり、前記アプリケーションペイロードは、トランスポートレイヤプロトコルを含むクライアント要求から形成される受信機／送信機モジュールと、
   前記トランスポートレイヤプロトコルを終端し、現在のセッションに関連する前記アプリケーションペイロードを読み取るための終端モジュールと、
   前記アプリケーションペイロードの対応するものに挿入するために、受信したアプリケーションのそれぞれのためのアプリケーション特有情報を含むヘッダ情報を準備するための準備器モジュールと、
   単一の仮想通信リンクを介して前記ネットワーク内で伝送するために、前記ヘッダ情報を含む前記アプリケーションペイロードを暗号化するための暗号化／解読モジュールと
   を含み、
   前記仮想通信リンクは、前記クライアントに存在する前記アプリケーションのうち１つ以上が前記アプリケーションペイロードを多重することにより単一の通信チャネルを共有することを許容する装置。
10. 前記１つ以上のアプリケーションは、NETCONF、SNMP及びCAPWAPのうち１つを含む、請求項８又は９に記載の装置。
11. 前記ヘッダ情報は、バージョンフィールドと、動作タイプフィールドと、セキュリティセッション制御フィールドと、アプリケーションセッションフィールドと、アプリケーションIDフィールドと、ペイロード長とのうち少なくとも１つを含む、請求項８乃至１０のうちいずれか１項に記載の装置。
12. 仮想通信リンクは、暗号化された仮想トンネルである、請求項８乃至１１のうちいずれか１項に記載の装置。

Images