特許 6857248 ＴＣＰ接続の確立を加速する方法及びシステム

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

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

(11)【特許番号】6857248

(24)【登録日】2021年3月23日

(45)【発行日】2021年4月14日

(54)【発明の名称】ＴＣＰ接続の確立を加速する方法及びシステム

(51)【国際特許分類】

   H04L 12/70 20130101AFI20210405BHJP

   H04L 12/893 20130101ALI20210405BHJP

【ＦＩ】

   H04L12/70 A

   H04L12/893

【請求項の数】14

【全頁数】16

(21)【出願番号】特願2019-538559(P2019-538559)

(86)(22)【出願日】2016年10月12日

(65)【公表番号】特表2019-530390(P2019-530390A)

(43)【公表日】2019年10月17日

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

(87)【国際公開番号】WO2018068848

(87)【国際公開日】20180419

【審査請求日】2019年4月3日

(73)【特許権者】

【識別番号】517451940

【氏名又は名称】エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー

(74)【代理人】

【識別番号】100124811

【弁理士】

【氏名又は名称】馬場 資博

(74)【代理人】

【識別番号】100088959

【弁理士】

【氏名又は名称】境 廣巳

(74)【代理人】

【識別番号】100097157

【弁理士】

【氏名又は名称】桂木 雄二

(74)【代理人】

【識別番号】100187724

【弁理士】

【氏名又は名称】唐鎌 睦

(72)【発明者】

【氏名】ビフルコ ロベルト

(72)【発明者】

【氏名】シュナイダー ファビアン

【審査官】 野元 久道

(56)【参考文献】

【文献】 山口 一郎，石川 雄一，地引 昌弘，ＴＣＰ無終端中継によるファイアウォール越え通信方式の検討，電子情報通信学会技術研究報告，日本，電子情報通信学会，２００８年 １月２７日，Vol.107 No.448，P.39-43

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

Ｈ０４Ｌ １２／７０

Ｈ０４Ｌ １２／８９３

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

【請求項1】

ネットワーク内でクライアント（６）とサーバ（７）との間のＴＣＰ接続の確立を加速する方法であって、
前記ネットワーク内にパケット生成能力を持つ少なくとも１つのステートフルスイッチ（５）を配備し、
前記少なくとも１つのステートフルスイッチ（５）が
前記クライアント（６）からTCP SYNセグメントを受信し、
前記サーバ（７）と連係してシーケンスナンバーを生成し、前記サーバ（７）は、サーバ（７）とステートフルスイッチ（５）との間で合意されたシーケンスナンバー生成方法を用いて前記シーケンスナンバーが生成されている、または、ステートフルスイッチ（５）から受信した情報に基づいて、生成された前記シーケンスナンバーを示す情報を取得し、
前記サーバ（７）の代わりに、前記シーケンスナンバーを含む対応するSYN ACKセグメントを生成し、生成した前記SYN ACKセグメントを用いて前記TCP SYNセグメントに応答し、
前記クライアント（６）から受信した前記TCP SYNセグメントを前記サーバ（７）に転送し、
一旦ＴＣＰ接続が確立されると、前記クライアント（６）と前記サーバ（７）との間でやりとりされるセグメント群のための単なる転送要素として機能する
ように構成されることを含む、方法。

【請求項2】

前記少なくとも１つのステートフルスイッチ（５）は、前記クライアント（６）から受信したTCP SYNセグメントに対し対応するSYN ACKセグメントで応答するために、
前記クライアント（６）から受信した前記TCP SYNセグメントを新しいセグメントにコピーし、
生成した前記シーケンスナンバーを前記新しいセグメントに含め、
前記新しいセグメントを前記クライアント（６）に転送する各ステップを実行する、請求項１に記載の方法。

【請求項3】

前記サーバ（７）は前記サーバ（７）のSYN ACKセグメントを生成するために前記少なくとも１つのステートフルスイッチ（５）により生成された前記シーケンスナンバーを用いる、請求項１または請求項２に記載の方法。

【請求項4】

サーバ（７）とステートフルスイッチ（５）との間で合意されたシーケンスナンバー生成方法を用いる場合、
前記サーバ（７）は前記サーバ（７）のSYN ACKセグメントを生成するために任意のシーケンスナンバーを用い、
前記少なくとも１つのステートフルスイッチ（５）は前記サーバ（７）の代わりに前記任意のシーケンスナンバーと前記少なくとも１つのステートフルスイッチ（５）により生成された前記シーケンスナンバーとの間で変換を実行する、請求項１または請求項２に記載の方法。

【請求項5】

前記少なくとも１つのステートフルスイッチ（５）は、前記クライアント（６）から受信した前記TCP SYNセグメントから前記シーケンスナンバーをコピーすることにより前記シーケンスナンバーを生成する、請求項１〜４のいずれかに記載の方法。

【請求項6】

前記少なくとも１つのステートフルスイッチ（５）は、前記少なくとも１つのステートフルスイッチ（５）に格納されたカウンターから前記シーケンスナンバーを引き出すことにより前記シーケンスナンバーを生成する、請求項１〜４のいずれかに記載の方法。

【請求項7】

前記少なくとも１つのステートフルスイッチ（５）は任意のアルゴリズムを実行することにより前記シーケンスナンバーを生成する、請求項１〜４のいずれかに記載の方法。

【請求項8】

前記少なくとも１つのステートフルスイッチ（５）は、前記クライアント（６）から受信したTCP SYNセグメント群を前記サーバ（７）に転送する前に、前記クライアント（６）から受信した前記TCP SYNセグメント群に、加速が提供されたか否かを示す情報を付与する、請求項１〜７のいずれかに記載の方法。

【請求項9】

前記少なくとも１つのステートフルスイッチ（５）はステートフルＳＤＮスイッチである、請求項１〜８のいずれかに記載の方法。

【請求項10】

好ましくは請求項１〜１０のいずれかに記載の方法を実行するための、ネットワーク内でクライアント（６）とサーバ（７）との間のＴＣＰ接続の確立を加速するシステムであって、前記システムは
パケット生成能力を持ち、入力／アウトプットポート（８ａ，８ｂ）、状態テーブル（１）、有限状態機械（ＦＳＭ）テーブル（２）、及び前記状態テーブル（１）と前記ＦＳＭテーブル（２）との間に実装されるフィードバックループ（９）を含む少なくとも１つのステートフルスイッチ（５）と、
前記少なくとも１つのステートフルスイッチ（５）の前記状態テーブル（１）及び前記ＦＳＭテーブル（２）にルール群を設定するためのコントローラー（４）とを含み、
前記少なくとも１つのステートフルスイッチ（５）が
前記クライアント（６）からTCP SYNセグメントを受信し、
前記サーバ（７）と連係してシーケンスナンバーを生成し、前記サーバ（７）は、サーバ（７）とステートフルスイッチ（５）との間で合意されたシーケンスナンバー生成方法を用いて前記シーケンスナンバーが生成されている、または、ステートフルスイッチ（５）から受信した情報に基づいて、生成された前記シーケンスナンバーを示す情報を取得し、
前記サーバ（７）の代わりに、前記シーケンスナンバーを含む対応するSYN ACKセグメントを生成し、生成した前記SYN ACKセグメントを用いて前記TCP SYNセグメントに応答し、
前記クライアント（６）から受信した前記TCP SYNセグメントを前記サーバ（７）に転送し、
一旦ＴＣＰ接続が確立されると前記ＴＣＰ接続に関連するいかなる状態も前記少なくとも１つのステートフルスイッチ（５）により保持されないように前記クライアント（６）と前記サーバ（７）との間でやりとりされるセグメント群のための単なる転送要素として機能する
ように構成される、システム。

【請求項11】

前記少なくとも１つのステートフルスイッチ（５）は、前記クライアント（６）から受信したTCP SYNセグメントに対して対応するSYN ACKセグメントで応答するために、
前記クライアント（６）から受信した前記TCP SYNセグメントを新しいセグメントにコピーし、
生成した前記シーケンスナンバーを前記新しいセグメントに含め、
前記新しいセグメントを前記クライアント（６）に転送する各ステップを実行する、請求項１０に記載のシステム。

【請求項12】

前記コントローラー（４）は、選択的確認応答、ウィンドウスケーリング、又は最大セグメントサイズ通知群のためのＴＣＰオプション群の少なくとも１つを含む、SYN ACKパケット生成のためのＴＣＰオプション群の承認又は許可について前記少なくとも１つのステートフルスイッチ（５）を設定するように構成された、請求項１０又は１１に記載のシステム。

【請求項13】

請求項１〜１２のいずれかに記載の方法及び／又はシステムで採用されるように構成された、フローベースのプログラマブルネットワーク装置、特にステートフルスイッチ（５）。

【請求項14】

請求項１〜１２のいずれかに記載の方法及び／又はシステムで採用されるように構成された、コントローラー実体、特にＳＤＮコントローラー（４）。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワーク内のクライアント、サーバ間のTCP接続の確立を加速する方法及びシステムに関する。

【背景技術】

【0002】

短いＴＣＰフロー、すなわち、ＴＣＰセッションの確立後に短いラウンドトリップタイム （round trip time：RTT）を終了させるフローは今日のウェブサービスにおいて普及しているフローである。 このようなＴＣＰフローでは、Sivasankar Radhakrishnan, Yuchung Cheng, Jerry Chu, Arvind Jain, and Barath Raghavan: “TCP Fast Open”, in Proceedings of the 7th International Conference on emerging Networking EXperiments and Technologies （CoNEXT ‘11）, ACM, New York, NY, USA, Article 21に記載されているように、３ウェイハンドシェイクとも呼ばれるＴＣＰセッションの確立に必要な時間が接続時間全体のかなりの部分を占めることがある。また、ＴＣＰセッションの確立に必要な時間は、（一般にクライアント及びサーバと呼ばれる）通信に関わる２者間のＲＴＴに依存する。これはどのような場合でも２者間の移動には３つのＴＣＰセグメントが必要だからである。

【発明の概要】

【発明が解決しようとする課題】

【0003】

Abhinav Pathak, Y. Angela Wang, Cheng Huang, Albert Greenberg, Y. Charlie Hu, Randy Kern, Jin Li, and Keith W. Ross: “Measuring and evaluating TCP splitting for cloud services”, in Proceedings of the 11th International Conference on Passive and Aactive Measurement (PAM ’10), Arvind Krishnamurthy and Bernhard Plattner (Eds.). Springer-Verlag, Berlin, Heidelberg, 41-50に記載されているように、最新の技術においてこの問題は接続のTCPクライアント（すなわち、ＴＣＰ接続の開始者）に近いＴＣＰプロキシをデプロイすることにより解決されてきた。クライアントはこのプロキシと新しい接続を確立する。基本的には、このような確立はプロキシに対するクライアントの近接性により短いネットワークディレイを保証する高速動作である。しかしながら、このソリューションにはプロキシがＴＣＰ接続の宛先サーバへの常時のかつ事前確立された接続を有するという欠点が伴う。

【0004】

ＴＣＰ接続の確立に必要な時間の短縮を達成する第２の方法は、接続確立のために送られるＴＣＰセグメントに対し早期応答を提供するＴＣＰプロキシをデプロイすることである。プロキシがクライアントとサーバ間のパス上にある、理想的にはパスディレイ的な真ん中にある場合、接続は有効に加速される。この手法はプロキシにTCP SYN及びTCP SYN ACKセグメントが受信され次第それらに応答することを求める。また、プロキシはTCP SYNを可能な限り早くＴＣＰ宛先サーバに転送しなければならない。この方法の詳細は、Giuseppe Siracusano, Roberto Bifulco, Simon Kuenzer, Stefano Salsano, Nicola Blefari Melazzi, Felipe Huici: “On-the-Fly TCP Acceleration with Miniproxy”, in ACM SIGCOMM HotMiddlebox, 2016, and in Sameer Ladiwala, Ramaswamy Ramaswamy, and Tilman Wolf: “Transparent TCP acceleration”, in Comput. Commun. 32, Issue 4, March 2009, 691-702に記載されている。

【0005】

ＴＣＰ接続を「再確立」する場合、上記方法の代わりに別の種類の最適化を適用することができる。特に、同一のサーバに対し２回目の接続を確立する場合、クライアントは１回目の接続の確立中に生成されたＴＣＰセッションクッキーを含めることができる。そのようなクッキーによりクライアントは完全な３ウェイハンドシェイクを実行しなくてもサーバに対し直接データ送信を実行できるようになる。この方法は通常、（上記の引用文献『ＴＣＰファストオープン』に記載される）ＴＣＰファストオープンと呼ばれる。

【0006】

以上の観点から、本発明の目的は、容易に実装可能かつ少ない手間で動作可能な手段を採用することによりＴＣＰ接続の確立に必要な時間の大幅な短縮が達成されるようにネットワーク内のクライアントとサーバとの間のＴＣＰ接続の確立を加速する方法及びシステムを改善及び発展させることである。

【課題を解決するための手段】

【0007】

本発明によれば、上記目的はネットワーク内でクライアントとサーバとの間のＴＣＰ接続の確立を加速する方法により達成される。前記方法は、
前記ネットワーク内にパケット生成能力を持つ少なくとも１つのステートフルスイッチをデプロイし、
前記少なくとも１つのステートフルスイッチが
前記クライアントからTCP SYNセグメントを受信し、
前記サーバと連係してシーケンスナンバーを生成し、
前記サーバの代わりに前記TCP SYNセグメントに対し前記シーケンスナンバーを含む対応するSYN ACKセグメントで応答し、
前記クライアントから受信した前記TCP SYNセグメントを前記サーバに転送し、
一旦ＴＣＰ接続が確立されると前記ＴＣＰ接続に関連するいかなる状態も前記少なくとも１つのステートフルスイッチにより保持されないように前記クライアントと前記サーバとの間でやりとりされるセグメント群のための単なる転送要素として機能する
ように構成されることを含む。

【0008】

また、上記目的はネットワーク内でクライアントとサーバとの間のＴＣＰ接続の確立を加速するシステムにより達成される。前記システムは
パケット生成能力を持ち、入力／アウトプットポート、状態テーブル、有限状態機械（ＦＳＭ）テーブル、及び前記状態テーブルと前記ＦＳＭテーブルとの間に実装されるフィードバックループを含む少なくとも１つのステートフルスイッチと、
前記少なくとも１つのステートフルスイッチの前記状態テーブル及び前記ＦＳＭテーブルにルール群を設定するためのコントローラーとを含み、
前記少なくとも１つのステートフルスイッチが
前記クライアントからTCP SYNセグメントを受信し、
前記サーバと連係してシーケンスナンバーを生成し、
前記サーバの代わりに前記TCP SYNセグメントに対し前記シーケンスナンバーを含む対応するSYN ACKセグメントで応答し、
前記クライアントから受信した前記TCP SYNセグメントを前記サーバに転送し、
一旦ＴＣＰ接続が確立されると前記ＴＣＰ接続に関連するいかなる状態も前記少なくとも１つのステートフルスイッチにより保持されないように前記クライアントと前記サーバとの間でやりとりされるセグメント群のための単なる転送要素として機能する
ように構成される。

【0009】

本発明によれば、TCP接続の確立に必要な時間の大幅な短縮は、ＴＣＰハンドシェイクアクセラレータとして機能するように構成された、スイッチ内パケット生成能力を持つ中間ステートフルスイッチ（例えば、ステートフルＳＤＮスイッチ）を用いることにより達成可能であることが認識された。実施形態によれば、ステートフルスイッチにおいてＴＣＰの３ウェイハンドシェイク加速を扱う状態機械が構成される。具体的に、このようなステートフルスイッチはSYN-ACK TCPセグメントの早期生成を実行するためにＴＣＰサーバと連係する。本発明の実施形態によれば、上記の方法／システムは、スイッチに、TCP SYNセグメントに対し対応するSYN ACKで応答させ、他方、当該SYNはまた最終ＴＣＰ宛先サーバに転送される。このスイッチは、一方がクライアントとの接続の確立、他方がサーバとの接続の確立である２つの並立したＴＣＰ接続の確立を実行する。この文脈において、本発明に従ってこのステートフルスイッチが完全なＴＣＰ接続のために状態を内部的に扱っていないことに注目することが重要である。その代わりに、当該ステートフルスイッチは３ウェイハンドシェイクを実行するために必要な最小限の状態を単に保存する。そのため、一旦ＴＣＰ接続が確立されると、このスイッチは「通常の」スイッチとして機能するように構成される、すなわち、ＴＣＰクライアントとＴＣＰサーバ間でやりとりされるセグメントを転送する単なる中間要素になることが可能である。

【0010】

従って、本発明は本格的なＴＣＰプロキシをデプロイするのではなく３ウェイハンドシェイク中に単に状態を維持する中間ノードを用いることによりＴＣＰ接続の確立を加速する。具体的に、ＴＣＰ接続に関する状態は当該スイッチに保存されず又は保存する必要がなく、接続の確立後ＳＤＮスイッチはＴＣＰ接続に関与しない。また、バッファの必要もＴＣＰ接続を閉じる又は開ける必要もない。実施形態によれば、シーケンスナンバー生成手順はＴＣＰサーバからステートフル（例えば、ＳＤＮ）スイッチに肩代わりされる。

【0011】

本発明の実施形態は、以下のステップを含む、ＴＣＰ接続をプロキシせずにＴＣＰサーバの代わりにTCP SYN-ACKセグメントを生成する方法に関する。
１）ネットワーク内に１つ又は複数のＳＤＮスイッチをデプロイする。これらのスイッチはステートフル転送とスイッチ内パケット生成をサポートする必要がある。
２）これらのスイッチをSYN-ACKパケットを生成するように構成する。
３）ＴＣＰサーバをこのスイッチにより生成されたＴＣＰシーケンスナンバーを用いるように構成する。

【0012】

本発明の実施形態は、高度なSDNソリューションの一部となってＳＤＮスイッチとコントローラーの両方の高度化を提供することが可能である。本発明は一般に、高度ＴＣＰ加速サービスとして通信事業者のデプロイメントにおいて用いることができる。その意味で、本発明は次世代ＳＤＮ強化ＴＭＳの一部になる可能性がある。

【0013】

一実施形態によれば、クライアントから受信したTCP SYNセグメントに対し対応するSYN ACKセグメントで応答するため、上記ステートフルスイッチは前記クライアントから受信したTCP SYNセグメントを新しいセグメントにコピーし、生成された前記シーケンス（確認）ナンバーを前記新しいセグメントに含め、前記新しいセグメントを前記クライアントに転送する各ステップを実行してもよい。本発明の実施形態によれば、前記スイッチはスイッチ内パケット生成の原則に従ってSYN ACKセグメントを生成してもよい。

【0014】

一実施形態によれば、前記ステートフルスイッチは生成された前記シーケンスナンバーを前記サーバに伝えるように構成されてもよい。例えば、前記シーケンスナンバーを前記ＴＣＰサーバに伝えるため、前記ステートフルスイッチは、前記TCP SYNセグメントを前記サーバに転送する前に前記シーケンスナンバーを前記クライアントから受信した前記TCP SYNセグメントに加えられたカスタム追加ＴＣＰオプションに含めてもよい。或いは、前記ステートフルスイッチはパケットのヘッダーフィールド内で前記シーケンスナンバーをコード化してもよい。

【0015】

前記サーバが前記ステートフルスイッチにより生成された前記シーケンスナンバーの知識を得られるようにする別の方法が、前記サーバと前記ステートフルスイッチとの連係が前記サーバがシーケンスナンバーを生成するための共通のスキームにおいて前記ステートフルスイッチと合意するメカニズムを含むことであってもよい。換言すれば、前記ステートフルスイッチは前記サーバと共同で前記シーケンスナンバーを生成する。例えば、直接的な実装において、前記サーバと前記ステートフルスイッチは指定された順番に従って採用されるシーケンスナンバーのリストについて事前に合意してもよい。

【0016】

既に述べたように、前記ステートフルスイッチは前記ＴＣＰサーバの代わりにシーケンスナンバーの生成を担当し（前記ＴＣＰサーバは合意された生成スキームにより又は前記スイッチからの明白な情報により生成されたシーケンスナンバーの知識を有する）。従って、一実施形態によれば、前記サーバは、新たに開始されたTCP接続のために、すなわち、前記サーバのSYN ACKセグメントを生成するために、前記ステートフルスイッチにより生成されたシーケンスナンバーを用いるべきであるとしてもよい。通常、この実施形態は加速を実行する前記TCPサーバとステートフルネットワークスイッチとの合意を必要とする。

【0017】

或いは、前記サーバは前記サーバのSYN ACKセグメントを生成するために任意のシーケンスナンバーの使用を可能にされてもよい。この場合、前記ＳＤＮスイッチは、各ＴＣＰ接続において前記クライアントとサーバにより交換される残りの全セグメントについてシーケンスナンバー間の（すなわち、この任意のシーケンスナンバーと前記サーバの代わりに前記ＳＤＮスイッチにより生成されたシーケンスナンバーとの間の）変換を実行するように構成されてもよい。

【0018】

前記ＳＤＮスイッチにより生成されたシーケンスナンバーに関して、いくつかの異なる実装を実現してもよい。例えば、一実施形態によれば、前記ＳＤＮスイッチは前記クライアントから受信したTCP SYNセグメントからシーケンスナンバーをコピーすることによりシーケンスナンバーを生成してもよい。この実装は、生成された前記シーケンスナンバーは前記サーバに個別に伝達されなくてもよいという利点をもたらす。これは、実際、前記サーバはＳＹＮパケットから直接前記シーケンスナンバーを読み取ることができるからである。

【0019】

代替の実施形態によれば、前記シーケンスナンバーは前記ＳＤＮスイッチに格納されたカウンターから引き出されてもよく、又は前記ＳＤＮスイッチが実行する任意のアルゴリズムにより生成されてもよい。更に別の実施形態によれば、前記シーケンスナンバーは生成用のパケットテンプレートにより決定されてもよい。当業者には容易に理解されるように、上に列挙したものは網羅的なものではなく、前記SDNスイッチがシーケンスナンバーを生成する更に別の方法が構想されてもよい。ただし、いずれの場合でも、前記スイッチは生成されたシーケンスナンバーを前記サーバに伝える、又は前記サーバとスイッチはそれぞれに適用されるシーケンスナンバー生成メカニズムについて（前記サーバがこの生成メカニズムからシーケンスナンバーを引き出すことができるように）事前に合意している。

【0020】

その接続確立手順が加速された前記ＴＣＰサーバは、接続の確立がそのようなプロセスを経ていることを認識していなければならない。実際、ＴＣＰクライアントから受信したSYNについて、当該SYNがパス内のＳＤＮステートフルスイッチのいずれかにより生成されたSYN-ACKを起動した場合、前記サーバがそのようなスイッチにより生成されたシーケンスナンバーを用いることは有利である。前述のように、シーケンスナンバーの生成とサーバへの伝達の手順は上記の方法のいずれであってもよい。

【0021】

前記サーバにより受信された新しいＴＣＰ接続確立の内のサブセットだけが実際に加速された場合、前記サーバは（新しいシーケンスナンバーは前記ＴＣＰクライアントとＴＣＰサーバの間のパス上のＳＤＮステートフルスイッチのいずれかにより既に生成されているため）新しいシーケンスナンバーを生成する必要があるTCP SYNセグメントとそうではないTCP SYNセグメントとを区別できなくてはならない。一実施形態によれば、これは加速が提供された際TCP SYNセグメントにタグを付けることにより端的に実現可能である、すなわち、前記SDNスイッチが、前記クライアントから受信したTCP SYNセグメントを前記サーバに転送する前にそれらにタグを挿入する。そのために、任意の公知のタグ付け手法を用いてもよい。

【0022】

前記ＴＣＰサーバの代わりにシーケンスナンバーを生成する場合と同様、前記スイッチはSYN-ACKパケットを生成するために適切な追加情報を用いてもよい。このため、一実施形態によれば、前記ＳＤＮコントローラーはSYN ACKパケット生成のためのＴＣＰオプションの承認又は許可について前記ステートフルＳＤＮスイッチを設定するように構成されてもよい。例えば、この設定は、（IETF RFC 2018: “TCP Selective Acknowledgment Options”, October 1996に示されるように）許可された選択的確認応答のための種類４ＴＣＰオプションを加えること（又は加えないこと）に関するものであってよい。このＴＣＰオプションはSYNパケットにおいてのみ認められ、送り手が“選択的確認応答”を処理できることを示す。このオプションを加えるかどうかは要求されたサーバ次第で前記ＳＤＮコントローラーにより設定されてもよい、又は前記スイッチにより過去のSYN-ACKから探査／学習されてもよい。

【0023】

加えて又はその代わりに、この設定は、（IETF RFC 7323: “TCP Selective Acknowledgment Options”, October 2014に示されるように）ウィンドウスケーリング用の種類３ＴＣＰオプションを加えること（又は加えないこと）に関するものであってよい。このＴＣＰオプションは、SYN-ACKの中に正確なウィンドウスケーリング情報、すなわち、ＴＣＰサーバウィンドウスケーリングファクターにマッチする情報を持つことが要求される。これはそうでないと信頼できるTCP移転が確保されないからである。前記と同様、このオプションを加えるかどうかは、要求されたサーバ次第で前記SDNコントローラーにより設定されてもよい、又は前記スイッチにより過去のSYN-ACKから探査／学習されてもよい。

【0024】

更に別の実施形態によれば、この設定は、（IETF RFC 793: “TRANSMISSION CONTROL PROTOCOL−DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”, September 1981に示されるように）最大セグメントサイズ通知のための種類２ＴＣＰオプションを加えること（又は加えないこと）に関するものであってよい。このオプションは、接続に役立つと期待される最大ＴＣＰセグメントサイズの他の側を通知するために用いられる。ただし、このオプションを持つことが決定的に重要というわけではない。前記と同様、このオプションを加えるかどうかは、要求されたサーバ次第で前記ＳＤＮコントローラーにより設定してもよい、又は前記スイッチにより過去のSYN-ACKから探査／学習されてもよい。

【0025】

本発明の内容を有利なやり方で設計し発展させる方法がいくつもある。このため、従属する請求項、及び図示された、例としての本発明の好適な実施形態についての以下の説明を参照されたい。図に補助された本発明の好適な実施形態の説明と関連して、本発明の内容の一般的に好適な実施形態及び更なる進展が説明されよう。

【図面の簡単な説明】

【0026】

【図1】図１は２相ポートノッキングアプリケーションＦＳＭを示す概略図である。

【図2】図２は図１のポートノッキングアプリケーションを実装するステートフルスイッチングアーキテクチャを示す概略図である。

【図3】図３は従来技術によるＴＣＰプロキシを用いたＴＣＰ接続確立の加速を示す概略図である。

【図4】図４は本発明の一実施形態によるＴＣＰ接続確立の加速を示す概略図である。

【図5】図５は本発明の実施形態によるTCP SYNセグメントに応答するＳＤＮスイッチを用いたＴＣＰ接続確立の加速を示す図である。

【図6】図６は本発明の実施形態によるＳＤＮステートフルスイッチを用いたＴＣＰ接続確立加速プロキシの実装を示す概略図である。

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

【0027】

以下に詳細に説明される本発明の実施形態はOpenFlow及びOpenStateというソフトウェアデファインドネットワーキング（Software-Defined Networking：SDN）のコンセプトに依存するので、理解を容易にするために、まずこれらのコンセプトのいくつかの基本的な態様を簡単に要約するが、当業者はそれらの技術に十分精通しているものと概して仮定する。

【0028】

（https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN-ARCH-Overview-1.1-11112014.02.pdfに示されるような）ソフトウェアデファインドネットワーキング（SDN）パラダイムは、パケット転送（データプレーン）とコントロールプレーンの機能の分離をもたらす。

【0029】

広く採用されているOpenFlowプロトコルは、中央コントローラーからのスイッチのデータプレーンの遠隔設定のためにフローレベルの抽象化を提供する。コントローラーは特定のFlow_Modメッセージにより基礎となるスイッチにフロー毎のルールを教える。このようなメッセージは、マッチするパケットヘッダーを特定するマッチ部と指定されたフローに属する全てのパケットに対し特定の処理判断を適用するアクション部を含んでいる。これらの転送ルールは、転送テーブルステートメントに翻訳されテーブルパイプラインの１つ又はいくつかのテーブルの中に挿入される（https://www.opennetworking.org/technical-communities/areas/specificationを参照）。

【0030】

このような転送抽象化はテーブルパイプライン内でのステートレスのパケット処理を示し、特定フローの考えられるいずれの状態遷移もコントローラー側でのみ実行可能であることを意味している。これは、ステートフルパケット処理を必要とするどのような転送ロジックもスイッチとコントローラー間のいくらかの対話を要求することを意味している。このような対話を伴う場合のあるステートフル処理アプリケーションの例として、トラフィック異常検出、ファイアウォール状のプリミティブ（例えば、リフレキシブＡＣＬ）、適応ＱｏＳ執行などがあげられる。

【0031】

（例えば、Giuseppe Bianchi, Marco Bonola, Antonio Capone, and Carmelo Cascone: “OpenState: programming platform-independent stateful openflow applications inside the switch”, in SIGCOMM Comput. Commun. Rev. 44, 2 （April 2014）, 44-51に記載されるような）OpenStateは拡張有限状態機械（Extended Finite State Machine：XFSM）で転送エンジンを向上させるフロー志向のステートレス処理の拡張を可能にする。この拡張は、ステートレス転送アーキテクチャに状態テーブル及びＸＦＳＭテーブルという２つのテーブルを加えることによりスイッチングパイプラインにおける各フローの状態の記録と状態の遷移の実行を可能にする。図１、２はこの方法を示している。

【0032】

図１は、状態テーブルに加えてＦＳＭ（有限状態機械）テーブルを実装することによりフロー志向のステートレス処理の拡張を提供するステートフルＳＤＮ（ソフトウェアデファインドネットワーク）スイッチのコンセプトを概略的に示す。この拡張は、スイッチングパイプラインにおける各フローの状態の記録及びこの状態の遷移の実行を可能にする。

【0033】

具体的に、図１は「ポートノッキング」として知られる単純なステートフルパケット処理アプリケーションの例を示す（Giuseppe Bianchi, Marco Bonola, Antonio Capone, and Carmelo Cascone: “OpenState: Programming Platform-independent Stateful OpenFlow Applications Inside the Switch”, in SIGCOMM Comput. Commun. Rev. 44, 2 （April 2014）, 44-51を参照）。このアプリケーションは、インカミングフローのパケットが所定のポートシーケンスに向けられた後、特定の遠隔ホストのためにシステム内のトランスポートポート（例えば、ＳＳＨ接続用のＴＣＰポート）を開ける。ポートシーケンスが（図示の例では、ＴＣＰ宛先ポート = [P1, P2]のシーケンスである）ＦＳＭ内の所定のものとマッチする場合、接続はある確立状態（すなわち、A/Drop）から別の確立状態（すなわち、B/Fwd）に移動する、すなわち、同じ接続のその後の全てのパケットが転送される。

【0034】

詳細には、ポートP1上のマッチMが失敗した場合、各パケットはドロップされ、システムは状態Aにとどまる。このマッチが成功した場合、各パケットは引き続きドロップするが、システムは状態Bへの切り替えを行う。状態BにおいてポートP2上のマッチが成功した場合、システムは状態Bにとどまり、各接続のその後の全てのパケットは転送される。ポートP２上のマッチMが失敗するとすぐに各パケットはドロップされ、システムは状態Aに戻る。

【0035】

上記のロジックをコンパイルするには、スイッチングパイプラインを図２に示されるように修正する必要がある。ここで、状態テーブル１はアーキテクチャの２つのテーブルのうちの第１のテーブルである。キー値第１マッチルックアップテーブルである状態テーブル１において、第１マッチルックアップを実行してこのフローに関連する状態に対しインカミングフローのパケットヘッダー（群）をマッチさせる。テーブル１内の記録は、例えば、OpenFlowの優先属性によって順序付けられる。例えば、図１のポートノッキングの例において、そのようなフィールドは接続を開始する各遠隔ホストのソースＩＰアドレスに対してマッチすることがある。ルックアップは、インカミングフロー（ホスト）に関連する状態、又はワイルドカードマッチ（OpenFlow用語のMATCH_ALL）に関連するデフォルト状態値である値を戻す。この状態はその後対応するパケットヘッダーとともに第２段階であるＦＳＭテーブル２に渡される。スイッチングパイプラインのテーブル１、２間の状態移転は、メタデータフィールドを用いて実行されてもよい。

【0036】

ＦＳＭテーブル２において、パケットヘッダーと移転された状態の組み合わせは次のルックアップのキーである。この文脈において、（図２及びその後の全ての図で「Match*」で示される）ＦＳＭテーブル２のマッチフィールドは一般に（「Match」で示される）状態テーブル１のマッチフィールド（群）から独立していることに注意されたい。ポートノッキングの例において、ＦＳＭテーブル２内のマッチフィールドはＴＣＰ宛先ポートである。状態とMatch*フィールドの組み合わせによっては、図１との関連で説明されたＦＳＭに従うフロー処理及び（必要であれば）その状態更新のためのアクションがとられる。フローの状態更新が必要な場合、フィードバックループが２つのテーブル１、２の間に関わり、特定のフローの更新を持つset_state: pkt_headers+next_stateメッセージを通過させる。キーエクストラクタモジュール３は、パケットヘッダーから状態テーブル１のマッチフィールド（群）のための特定の値（群）を引き出し、それをnext_stateとともに状態テーブル１に渡して既存の記録を更新する、又は新しい記録を挿入する。テーブル１、２の初期設定は、図２で点線で示すように、中央コントローラー４によりState_mod及びFlow_modメッセージを用いて行われる。これに関して、本例では状態テーブル１は（状態テーブルの底部に示される）デフォルトのマッチ／状態判断を持った単一のState_modメッセージのみを必要とし、他方、その後の全ての更新はフィードバックループを介して行われることに留意されたい。

【0037】

図３は従来技術によるTCPプロキシ10を用いたTCP接続確立の加速を示す概略図である。ＴＣＰプロキシ１０はクライアント５により開始された３ウェイハンドシェイクを実行した後、サーバ７との３ウェイハンドシェイクを開始する。両動作において、ＴＣＰプロキシ１０は、ＴＣＰの有限状態機械トラッキング、タイマー、バッファなど、接続に関連する状態を生成する。このような状態は、図３の中でボックス「ＴＣＰセッション状態」１１により示される。ＴＣＰセッション状態１１は確立されたＴＣＰセッションの全期間にわたって維持されることに留意されたい。

【0038】

図４は本発明の一実施形態によるＴＣＰ接続確立の加速を示す概略図である。ここで、中間ボックス１２、例えば、ステートフルＳＤＮスイッチ５はクライアント６により開始された３ウェイハンドシェイクを実行し、それと平行してサーバ７とも３ウェイハンドシェイクを実行する。上記の方法を考慮して、中間ボックス１２はこの状態をクライアント６及びサーバ７との３ウェイハンドシェイクの終了までに必要なだけ維持する。このＴＣＰ３ウェイハンドシェイク状態は、図４において参照符号１３により示される。このような状態は最低限のものであり、主に接続確立部分のためのＴＣＰの有限状態機械トラッキングを含む。すなわち、中間ボックス１２は３ウェイハンドシェイクにより使用されるSYN、SYNACK、ACK TCPフレームの取り扱いを監視するが、例えば、バッファの生成及び／又は維持は行わない。一旦ＴＣＰセッション確立が終了すると、確立されたＴＣＰセッション中にセッション期間から独立して中間ボックス１２に維持される状態はない。

【0039】

図５は本発明の一実施形態によるＳＤＮスイッチ５を用いて加速されたＴＣＰ接続確立のメッセージフロー図を示す。ＴＣＰ接続がＳＤＮスイッチ５を挟んでクライアント６とサーバ７との間で確立され、ＳＤＮスイッチ５はクライアント６とサーバ７の両方と通信を行う。

【0040】

図示された実施形態において、ＳＤＮスイッチ５は、（図５の中で遅れ「X1」で示される）クライアント６とＳＤＮスイッチ５の間の遅れが（遅れ「X2」で示される）ＳＤＮスイッチ５とサーバ７の間の遅れとほぼ同じ大きさである、すなわち、数１（Dはクライアント６とサーバ７の間の遅れ全体を表す）であるように配置されているものとする。これは達成可能な加速量の観点から最も望ましい状況であるが、当業者によって容易に理解されるように、この方法は（例えば、ＳＤＮスイッチ５がクライアント６又はサーバ７にトポロジー的により近いことにより）X1≠X2である状況にも同様に適用可能である。

【数1】

【0041】

基本的に、図５の実施形態において、パケット生成能力を有するステートフルＳＤＮスイッチであるＳＤＮスイッチ５は、ＴＣＰ接続確立アクセラレータとして機能するように構成されている。加速の基本原則は、図５に示されるように、ＳＤＮスイッチ５に、TCP SYNセグメントに対して対応するSYN ACKで応答させ、他方、当該SYNはまた最後のＴＣＰ宛先サーバ７に転送される。ＳＤＮスイッチ５はその後、一方はクライアント５との接続確立でありもう一方はサーバ７との接続確立である２つの平行したＴＣＰ接続確立を実行する。一旦確立が実行されると、ＳＤＮスイッチ５はクライアント６とサーバ７の間の単なる中間転送要素である通常のスイッチとして動作する。

【0042】

詳細には、図５に図示された手順は以下のように展開される。

【0043】

ＴＣＰ接続を開始するため、ステップ３００に示されるように、クライアント６はTCP SYNセグメントを送る。

【0044】

このTCP SYNセグメントを受信次第、ＳＤＮスイッチ５は以下のアクションを実行する。

【0045】

図６との関連で以下により詳細に説明するが、ＳＤＮスイッチ５はサーバ側用のシーケンス（確認）ナンバーを生成する。また、ステップ３１０に示されるように、ＳＤＮスイッチ５は、クライアント６に、生成されたシーケンスナンバーを確認ナンバーとして含むTCP SYN ACKで応答する。また、ステップ３２０に示すように、ＳＤＮスイッチ５はクライアント６のシーケンスナンバー（すなわち、クライアント６のTCP SYNセグメントに含まれるシーケンスナンバー）を用いてTCP SYNをサーバに転送する。最後に、ＳＤＮスイッチ５はサーバ７に、サーバ７が新しく開始されたＴＣＰ接続のために使用しなければならない生成されたシーケンスナンバーを通知する。

【0046】

次に、ステップ３３０に示すように、サーバ７はSYN-ACKを送る。本発明の一実施形態によれば、このステップは任意のステップとして実行されてもよい、すなわち、省略可能である。サーバ７がSYN-ACKを送るように構成される場合、ＳＤＮスイッチ５はこのSYN-ACKを単純にドロップしてもよい。

【0047】

ＳＤＮスイッチ５からTCP SYN ACKを受信次第、クライアント６は、ステップ３４０に示すように、ACK（及び第１のデータセグメント）を送る。図示された実施形態では、ACKは第１のデータセグメントとして、相応にACK + Reqで表されるメッセージである内容要求を含むと仮定されることに留意されたい。

【0048】

ステップ３５０に示されるように、ＳＤＮスイッチ５はクライアント６からのACK及びクライアント６により送られた他のＴＣＰセグメントをサーバ７に転送する。

【0049】

このTCP ACKセグメントのやりとりを持ってＴＣＰハンドシェイクは終了する、すなわち、ＴＣＰ接続は無事に確立される。以後、ステップ３６０に１つのデータセグメントについて典型的に示されるように、ＳＤＮスイッチ５はクライアント６とサーバ７との間の単なるセグメント転送者になる。

【0050】

上記図２と同様の参照符号は同様の部品／構成要素を表す図６は、本発明の実施形態によるＴＣＰ接続確立アクセラレータとしてデプロイされるように構成されたOpenStateベースのＳＤＮステートフルスイッチ５を示す概略図である。このスイッチ５の一般的な構成（すなわち、インプット／アウトプットポート８ａ／ｂ、コントローラー４により設定可能な状態テーブル１及びＦＳＭテーブル２、及びキーエクストラクタモジュール３が２つのテーブル１、２間に実装されたフィードバックループ９からなる構成）は、図２と関連して上述したスイッチと同じである。しかしながら、以下で詳細に説明するように、スイッチ５の構成／設定は異なる。

【0051】

図6は、フロー１及びフロー２で表される２つのフローが現在スイッチ５によって処理されていると仮定される時点でのＳＤＮスイッチ５を示すスナップショットである。これらのフローは状態テーブル１内に対応するフローテーブルエントリー（flow table entry：FTE）を持ち、フロー１はその現在の関連状態としてSYNACKを、フロー２はその現在の関連状態としてESTBを有する。デフォルトで、状態テーブル１にはワイルドカードマッチを持ちその関連状態がDEFである別の記録も含まれる。以下の記述から明らかになるように、状態「SYNACK」は一般にＴＣＰハンドシェイク手順中にフローを扱うために用いられ、（「確立された」を意味する）状態「ESTB」は一般にＴＣＰハンドシェイク手順が無事に終了しそれによりＴＣＰ接続が確立された後にフローを扱うために用いられ、（「デフォルト」を意味する）状態「DEF」は一般に新しいフローを扱うために用いられる。

【0052】

状態テーブル１にきめの細かい関連記録を持たない新しいフローがＳＤＮスイッチ５で受信されると、デフォルト記録により扱われ、状態「ＤＥＦ」と関連付けられる。そのため、ＦＳＭテーブル２に転送されると、当該フローはワイルドカードマッチを含むＦＳＭテーブル２の第１のエントリーによって扱われる。TCP SYNセグメントだけがＳＤＮスイッチ５に向けられると仮定される場合、これは適切である。しかしながら、ＳＤＮスイッチ５が他のパケットも受信する場合がある構成では、ＦＳＭテーブル２の各エントリーは個別にSYNパケットにマッチするように設計されてもよい。

【0053】

ＦＳＭテーブル２の第１のエントリーは、そのアクションフィールドに「Set SYNACK, gen SYN-ACK, fwd」を示す。従って、ＳＤＮスイッチ５においてクライアント６から新しいTCP SYNセグメントを受信した場合、以下のセットのアクションがＳＤＮスイッチ５により実行される。

【0054】

まず、「Set SYNACK」アクションを実行することにより、対応するフローの状態が「DEF」から「SYNACK」に切り替わる。これは、キーエクストラクタモジュール３を介してset_state: pkt_headers+next_stateメッセージを通過させる２つのテーブル１、２間のフィードバックループにより行われる。その結果、新しい記録が、対応するフローを状態「SYNACK」に関連付ける状態テーブル１に入力される。更に、「gen SYN-ACK’」が実行される。このアクションはスイッチ内パケット生成アクションに対応し以下に詳細に説明される。最後に、アクション「fwd」の実行はTCP SYNセグメントがサーバ７に転送されることを意味し、図５のステップ３２０に対応する。

【0055】

アクション「gen SYN-ACK」の説明に戻る。このアクションは以下の動作を含む。

【0056】

まず、クライアント６のTCP SYNセグメントが新しいセグメントSにコピーされる。
その後、サーバ側ＴＣＰ接続のためのシーケンスナンバーが生成され、生成されたシーケンスナンバーは新しいセグメントSに含められる。最後に、新しいセグメントSはクライアント６に転送される。

【0057】

基本的に、アクション「gen SYN-ACK」は、（Roberto Bifulco, Julien Boite, Mathieu Bouet, and Fabian Schneider: “Improving SDN with InSPired Switches”, in Proceedings of the Symposium on SDN Research （SOSR '16）.ACM, New York, NY, USA, Article 11に記載されるように）スイッチ内パケット生成に対応する。この文脈において、スイッチ内パケット生成（In-Switch Packet generation：InSP）アプリケーションプログラミングインターフェース（Application Programming Interface：API）によりＳＤＮコントローラー４はスイッチ５に自立的なパケット生成を設定できるようになる。パケット生成動作は、トリガー、内容、及びアクションという３つの情報を提供することにより指定できる。トリガーはスイッチ５にパケットを生成すべき時期を示し、内容はパケットのヘッダーとペイロードを指定し、アクションはスイッチ５がどのようにパケットを使用すべきかを指定する。ＡＰＩのOpenFlowベースの実装はフローテーブルやフローテーブルエントリー（Flow Table Entry：FTE）などのOpenFlowの抽象化をてこ入れし、トリガー、内容、及びアクションの情報の指定をサポートするために新しい抽象化を定義する。特に、ＡＰＩのOpenFlowベースの実装は、スイッチ５によって生成されるパケットの内容を保存するためにパケットテンプレートテーブルを定義する。各パケットテンプレートテーブルエントリー（Packet Template Table Entry：PTE）は１つのパケットの内容を指定し、ＡＰＩの他の部分で基準として用いられる一意の識別子を有する。第２に、この実装は、標準的なOpenFlowアクションを用いてアクションを指定するInSP命令という新しいOpenFlow命令を加える。最後に、トリガーはInSP命令を含むＦＴＥを定義することにより提供される。実際は、InSP命令は対応するＰＴＥを示すＰＴＥの識別子も含む。パケットがＦＴＥにマッチするたびにInSP命令が起動され、示されたＰＴＥを用いて命令のアクションが適用されるパケットが生成される。

【0058】

各フローの次のパケットがＳＤＮスイッチ５に達すると、このパケットは状態「SYNACK」と関連付けられるのでＦＳＭテーブル２の第２又は第３のエントリーにより扱われる。このパケットがサーバ７からのSYNACKセグメントである場合（図５のステップ３３０を参照）、図5と関連して上述したように、ＦＳＭテーブル２の第２のエントリーが適用され、対応するアクションはこのパケットを単にドロップすることである。他方、次のパケットがクライアント６により送られたACKセグメントである場合（図５のステップ３４０を参照）、ＦＳＭテーブル２の第３のエントリーのワイルドカードマッチがこのパケットにマッチする。そのため、対応するアクションは（ACKセグメントの受信後ＴＣＰ接続が確立されるので）「Set ESTB」、すなわち、フローの状態を「SYNACK」から「ESTB」に切り替えること、及び図５のステップ３５０に対応して「fwd」、すなわち、ACKセグメントをサーバ７に転送することである。

【0059】

その後の全てのパケットは、ＳＤＮスイッチ５に達し次第、状態テーブル１で状態「ESTB」と関連付けられるのでＦＳＭテーブル２の第４及び／又は第５のエントリーにより扱われる。第５のエントリーは図５のステップ３６０を表す、すなわち、ＳＤＮスイッチ５は単にクライアント６とスイッチ７との間の中間転送要素として機能する。第４のエントリーは、サーバ７からのSYNACKがＳＤＮスイッチ５において受信される前にクライアント６からのACKがＳＤＮスイッチ５において受信される状況を考慮する。このエントリーにより、サーバ７からのSYNACKがクライアント６へのパケットの一般的な転送から除外され、その代わりにこのパケットがドロップされる。

【0060】

ここで説明した本発明の変形例や他の実施形態が、本発明が関係し上記の説明や添付の図面に示された内容の恩恵を受ける当業者により想到されよう。従って、本発明は開示された特定の実施形態に限定されるべきではなく、変形例や他の実施形態が添付の特許請求の範囲に含まれることが意図されていると理解すべきである。ここでは特定の用語が使われているが、それらは限定する目的ではなく一般的及び説明的意味で使われている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】