JP2010504047A - マルチパス環境におけるトランスポートプロトコルの性能を改善するシステムおよび方法 - Google Patents

Abstract

マルチパス環境におけるトランスポートプロトコルの性能を改善するデバイス、システム、および方法が開示される。一ネットワークデバイスは、トランスポート層プロキシと、トランスポート層プロキシに連結されたマルチパストラフィックディストリビュータとを備える。トランスポート層プロキシは、トランスポート層接続にそれぞれ関連付けられたパケットを、トランスポート層エンドポイントから受信するように構成される。該プロキシは、受信されパケットの少なくとも一部を、マルチパストラフィックディストリビュータへ配信するようにさらに構成される。マルチパストラフィックディストリビュータは、配信されたパケットのそれぞれを、複数のデータフローの１つに割り当て、かつ、配信されたパケットのそれぞれを、割り当てられたデータフローに関連付けられた送信パス上で送信するように構成される。

Description

（関連出願の参照）
本出願は、米国仮特許出願第６０／８４４，２２６号（２００６年９月１３日出願）の利益を主張し、該仮特許出願は、本明細書において参考として援用される。

（技術分野）
本開示は、データ通信に関し、より詳細には、複数の並列データ通信パス上のデータ通信に関する。

送信制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ；ＴＣＰ）として知られているトランスポートプロトコルは、過去２０年間にわたって、インターネット上における信頼できるデータ配信のための事実上のトランスポートプロトコルとして好成果を上げてきた。ＴＣＰによって使用されるアルゴリズムは、インターネット上における安定性、信頼性、および公平性を推進するように設計されたものであったが、これらの同じアルゴリズムが、通信システム間のエンドツーエンドパスに沿った一定の条件の存在下で、ＴＣＰ性能の低下をもたらした。広帯域、大きな遅延、および／または著しい損失率を含むこれらの特性は、現在のインターネットにおいてますます一般的なものとなりつつある。ＴＣＰによって使用される基本アルゴリズムは、長年にわたって修正されてきたが、ＴＣＰを使用するシステムの、非常に大きなインストールされた基盤が存在するために、これらのアルゴリズムに対する著しい変化は起こりそうにない。

さらに、ほとんどのネットワークでは広大なリソースがあるにもかかわらず、大多数は、データを、２つのネットワークエンティティの間でシーケンシャルに通信している。例えば、広く利用されているインターネットプロトコル（ＩＰ）は、任意の２つのエンティティの間の単一パスルーティングのみをサポートする。したがって、概して、データネットワークは、また、特に、インターネットは、シーケンシャルなデータ通信プロパティを超越することによって、性能、コスト、機能性、および柔軟性の改善を潜在的に可能にする、本来的な特徴を有する。すなわち、並列のデータ通信の実行が、多くのパケットデータネットワークの機能に根本的な改善をもたらす。したがって、これらの、およびその他の課題に取り組む必要性が存在する。

（概要）
マルチパス環境におけるトランスポートプロトコル性能を改善するためのデバイス、システム、および方法が開示される。一ネットワークデバイスは、トランスポート層プロキシと、トランスポート層プロキシに結合されたマルチパストラフィックディストリビュータとを含む。トランスポート層プロキシは、れぞれトランスポート層接続に関連付けられたパケットを、トランスポート層エンドポイントから受信するように構成される。プロキシは、さらに、受信されたパケットの少なくとも一部分を、マルチパストラフィックディストリビュータへ配信するように構成される。マルチパストラフィックディストリビュータは、配信されたパケットのそれぞれを、複数のデータフローの１つに割り当て、さらに、配信されたパケットのそれぞれを、割り当てられたデータフローに関連付けられた送信パス上で送信するように構成される。

本開示の多くの局面が、以下の図面を参照してよりよく理解され得る。図面中の構成要素は必ずしも縮尺通りではなく、むしろ、本開示の原理を明瞭に示すために強調されている。

図１は、トランスポートプロトコルの性能を改善するためのシステムおよび方法の一実施形態が置かれる環境のブロック図である。 図２は、図１のトランスポートプロトコルの性能を改善するためのロジックの、選択された構成要素を図示するブロック図である。 図３Ａ〜図３Ｃは、図１のネットワークデバイスの様々な実施形態のブロック図である。 図３Ａ〜図３Ｃは、図１のネットワークデバイスの様々な実施形態のブロック図である。 図３Ａ〜図３Ｃは、図１のネットワークデバイスの様々な実施形態のブロック図である。 図４は、図１のトランスポートプロトコルの性能を改善するためのロジックの、選択された構成要素をさらに詳細に示すブロック図である。 図５は、図１のトランスポートプロトコルの性能を改善するための様々なロジックの、構成要素の間の相互作用を示す、データフロー図である。 図６は、図１のトランスポートプロトコルの性能を改善するためのロジックによって、バッファが管理される様態を示す、データフロー図である。 図７は、図１のシステムの一実施形態における輻輳制御を示す、データフロー図である。 図８は、図１のシステムの一実施形態におけるフロー制御を示す、データフロー図である。 図９は、システム１００の一実施形態の信頼性（ＱｏＳ）処理を示す、データフロー図である。 図１０は、図１のネットワークデバイスのハードウェアブロック図である。

（詳細な説明）
マルチパス環境におけるトランスポートプロトコルの性能を改善するシステムおよび方法が開示される。全体のシステムアーキテクチャは、ローカルＡＣＫ、フロー制御、および接続管理の組み合わせによってＴＣＰ接続を促進するように構成されるトランスポート層プロキシ、およびマルチパスリソースの集約を実行するように構成されるマルチパストラフィックディストリビュータを含む。これらの構成要素は、以下でさらに詳細に説明される。

これらの２つの構成要素を統合するためのいくつかの発明技術が、本明細書において開示される。一発明技術は、データパケットおよび閉接続パケット（例えば、ＴＣＰ「ＦＩＮ」制御パケット）が、トランスポート層プロキシからマルチパストラフィックディストリビュータへ送信され、複数のワイドエリアネットワーク（ＷＡＮ）パス内に配信されるというものである。別の発明技術は、マルチパストラフィックディストリビュータが、トランスポート層プロキシに、ＷＡＮパス特徴を通信するというものである。トランスポート層プロキシが、異なるパス上のＷＡＮ条件に基づいて適切なフロー制御を実行できるように、これらの特徴がトランスポート層プロキシフローコントローラモジュールに提供される。さらに別の発明的特徴はトリガマネージャを含み、トリガマネージャは、トランスポート層プロキシによって最適化されるように接続を選択する統一メカニズム、さらに、マルチパストラフィックディストリビュータによって最適化されるように接続を選択する統一メカニズムを提供する。

図１は、トランスポートプロトコル１００の性能を改善するためのシステムおよび方法の一実施形態が置かれる環境のブロック図である。エンドポイントデバイス１１０は、トランスポート層（第４層）プロトコル１２０を使用し、ネットワーク１３０上で互いに通信を行う。本開示は、例示的なトランスポート層プロトコルとしてＴＣＰについて考察するが、当業者は、本明細書において開示されるトランスポートプロトコルの性能を改善するための原理が、その他のトランスポート層プロトコルにも当てはまることを認識するはずである。ルータ１４０は、ネットワーク１３０を越えてトラフィックを運搬し、これは、インターネットプロトコル（ＩＰ）等のネットワーク層（第３層）プロトコルの使用を含み得る。本明細書において「ルータ」という用語が使用されるが、当業者は、ルータ１４０は代わりに第３層スイッチの形態を取り得ることを認識するはずである。

ネットワークデバイス１５０は、（論理的に）エンドポイント１１０とルータ１４０との間に置かれる。各ネットワークデバイス１５０は、トランスポートプロトコル１６０の性能を改善するためのロジックを含み、これは、ネットワークデバイス１５０が拡張トランスポートプロトコル１７０を使用してピアネットワークデバイス１５０と通信を行うことを可能にする。したがって、一対のエンドポイント１１０は、一対のネットワークデバイス１５０を介して通信を行う。

このために、システム１００は、２つのエンドポイント１１０および２つのネットワークデバイス１５０を含む。エンドツーエンドの接続は、次の３つの区間、つまり、近端エンドポイント１１０Ｎとローカルネットワークデバイス１５０Ｌとの間の、第１のまたは近端の区間１７５、ローカルネットワークデバイス１５０Ｌとそのピアのリモートネットワークデバイス１５０Ｒとの間の、中間区間１８０、およびリモートネットワークデバイス１５０Ｒと遠端エンドポイント１１０Ｆとの間の、最後のまたは遠端の区間１８５、に分割され得る。

図１では、ネットワークデバイス１５０はエンドポイント１１０とルータ１４０との間に表示されるが、これは物理的表現ではなく論理的表現であり、パケットがネットワークデバイス１５０を通過することを示しているに過ぎない。以下で説明するように、ネットワークデバイス１５０の一部の実施形態は、実際にはエンドポイント１１０とルータ１４０との間にインラインに設置されておらず、代わりに、ルータ１４０にぶら下がるオフラインデバイスとして動作する。

当業者は、トランスポートプロトコル１６０の性能を改善するためのロジックが、いくつかの異なる手法でインスタンス化され得ることを理解するはずである。一実施例は、ＴＣＰ通信端末デバイス１１０とアクセスルータ１４０との間に位置しているスタンドアロンデバイス１５０内に、ロジック１６０を実装する。トランスポートプロトコル１６０の性能を改善するためのロジックのもう１つのインスタンス化は、例えばカーネルドライバがＴＣＰとカーネルプロトコルスタックのＩＰ層との間に位置している場合には、エンドポイント１１０内で行われる。さらに別の実施例として、トランスポートプロトコル１６０の性能を改善するためのロジックは、ＴＣＰをエンドポイント１１０のプロトコルスタック内のトランスポート層として置換することができる。本明細書においては、スタンドアロンネットワークデバイス１５０のみが特に考察されるが、すべてのそのようなインスタンス化が、本開示の範囲内に含まれることが意図される。

ネットワークデバイス１５０の一部の実施形態において、拡張トランスポート層プロトコル１７０は、エンドポイント１１０によって使用されるトランスポート層プロトコル１２０とは異なる。ここで、エンドポイント１１０とその対応するネットワークデバイス１５０との間で使用されるプロトコルが、元のトランスポート層プロトコル１２０であり、ピアネットワークデバイス１５０の間で使用されるプロトコルが、拡張トランスポート層プロトコル１７０である。そのような実施形態において、ネットワークデバイス１５０は、エンドポイント１１０用のトランスポート層プロキシとして作用する。一部のプロキシ実施形態において、エンドポイント１１０は、当該ネットワークデバイス１５０が異なるトランスポート層プロトコルを使用していることに気付かず、この場合、ネットワークデバイス１５０は、エンドポイント１１０に対して透過性の（ｔｒａｎｓｐａｒｅｎｔ）トランスポート層プロキシである。以下でさらに詳細に説明されるように、ネットワークデバイス１５０は、エンドポイントが、実際の受信者としてではなく、他の通信中のエンドポイントとしてのプロキシにのみ気付いているような手法で、ＴＣＰエンドポイントによって送信されたパケットに応答することによって、透過性を保持する。

一部の実施形態において、ネットワーク１３０内のリンクは、エンドポイント１１０へのリンクとは異なる性能特性を呈する。例えば、エンドポイント１１０へのリンクは、比較的高速の有線接続（例えば、１００メガビットイーサネット（登録商標））を提供し得、一方では、ネットワーク１３０内のリンクは、低速の有線または無線接続（例えば、Ｔ１、ＷｉＦｉ）を提供し得る。拡張トランスポート層プロトコル１６５は、ネットワークデバイス１５０の間のリンクの性能特性に合わせて設計される。

これ以後、拡張トランスポートプロトコル１７０によって使用されるパケットに言及するときには、「拡張トランスポート層パケット」という用語が使用される。当業者は、そのようなプロトコルは、一般に、データを搬送するパケット（データパケット）と、データに確認応答するパケット（確認応答パケット）と、接続の設定／終了処理を行うために使用される制御パケットとを含むことを認識するはずである。したがって、本明細書においては、「拡張トランスポート層データパケット」と、「拡張トランスポート層確認応答パケット」と、「拡張トランスポート層制御パケット」とに言及する。これらのパケットは、元のトランスポート層プロトコルに対応するものであるが、それとは異なる。例えば、ＴＣＰデータパケットおよび拡張トランスポート層データパケットは、いずれもデータを搬送するが、ＴＣＰデータパケットはＴＣＰエンドポイント１１０に由来し、またはそこへ配信されるものであり、一方では、拡張トランスポート層データパケットは、トランスポート層プロキシピア１５０の間で伝達される。

一部の実施形態において、拡張トランスポート層パケットは、元のトランスポート層プロトコルパケットにトレーラフィールドを追加することによって形成される。例えば、ＴＣＰデータパケットは、「拡張トランスポート層データ」の「プロトコルタイプ」フィールドを付加することによって拡張トランスポート層データパケットに変換され、一方では、ＴＣＰ制御パケットは、「拡張トランスポート層制御パケット」の「プロトコルタイプ」フィールドを付加することによって拡張トランスポート層制御パケットに変換される。これは、カプセル化の一形態とみなされ得るが、しかし、エンドポイントに対して透過的であるという利点を有する。一部の場合において、拡張トランスポート層パケットは、カプセル化することなく、単独で伝達される。これらの場合において、ＩＰヘッダ中のプロトコルタイプ（Ｐｒｏｔｏｃｏｌ Ｔｙｐｅ）フィールドは、拡張トランスポート層プロトコルの存在を示す特殊な値に設定され得る。すなわち、拡張トランスポート層プロトコル１７０は、ＩＰまたはネットワーク層によって、ＴＣＰまたはＵＤＰのようなプロトコルタイプとして見なされる。

図１に示されていないが、一対のエンドポイント１１０は、ピア間に複数の接続を含み得、これらの接続のそれぞれは、改善されたネットワークデバイス１５０Ｌおよび１５０Ｒを通過する。この場合、ネットワークデバイス１５０は、接続ごとに、ネットワークデバイス１５０の間の接続の区間に対して、拡張トランスポート層プロトコル１６５を使用するか元のトランスポート層プロトコル１２０を使用するかを決定する。一部の実施形態において、ユーザ（例えば、システム管理者）は、どの接続がどのトランスポート層プロトコルを使用するかを決定し、それに従ってネットワークデバイス１５０を構成する。

いくつかの構成例は、特定のエンドポイント１１０からのすべての接続が拡張トランスポート層プロトコル１６５を使用する；特定のエンドポイント１１０からの接続がいずれも拡張トランスポート層プロトコル１６５を使用しない；ヘッダフィールドの特定の組み合わせによって識別された特定のエンドポイント１１０からのそれらの接続が、拡張トランスポート層プロトコル１６５を使用する；ヘッダフィールドの特定の組み合わせによって識別されない特定のエンドポイント１１０からのそれらの接続が、拡張トランスポート層プロトコル１６５を使用しない；というものである。当業者は、これらは単なる例示に過ぎず、どの接続が拡張トランスポート層プロトコル１６５を使用するかを判断するための、その他の技術がまた可能であることを、認識するはずである。

図２は、図１のトランスポートプロトコル１６０の性能を改善するためのロジックの、選択された構成要素を図示するブロック図である。トランスポート層プロキシ２１０は、ローカルＡＣＫ、フロー制御、および接続管理のような特徴を用いて、ＴＣＰ接続を改善または促進するために、トランスポート層プロトコルエンドポイント１１０Ｓおよびピアネットワークデバイス１５０Ｐと相互に作用する。これらの特徴の一部が、同一人に譲渡され同時係属中の特許出願第８２０１２３−１０１０号に記載されている。マルチパストラフィックディストリビュータ２２０が、パケットを、ピアネットワークデバイス１５０Ｐに配信し、ローカルネットワークデバイス１５０によって提供される複数のパス２３０Ａ〜２３０Ｃ上のリソースを集約する。バッファ２４０が、ローカルトランスポート層プロキシ２１０が（近端）ＴＣＰエンドポイント１１０Ｎから受信するデータの、送信に使用される。このデータは、最終的に（遠端）ＴＣＰエンドポイント１１０Ｆへ配信するために、ピアネットワークデバイス１５０Ｐ内のピアトランスポート層プロキシ（図示せず）へ送信される。バッファ２５０が、トランスポート層プロキシ２１０がピアトランスポート層プロキシから受信する、エンドポイント１１０Ｆから発するデータの、送信に使用される。このデータは（近端）ＴＣＰエンドポイント１１０Ｎ上に送信される。トランスポートプロトコル１６０の性能を改善するためのロジックの一部の実施形態は、バッファ２４０および２５０の状態についての情報がトランスポート層プロキシ２１０とマルチパストラフィックディストリビュータ２２０との間で共有され、このバッファ情報がフロー制御および輻輳制御に影響を及ぼすために使用されるという、発明的特徴を含む。この特徴が、以下でさらに詳細に説明される。

図３Ａ〜図３Ｃは、ネットワークデバイス１５０の様々な実施形態のブロック図である。上述のように、トランスポート層プロキシ２１０は、（近端）ＴＣＰエンドポイント１１０Ｎ（図示せず）との相互作用に集中し、一方で、マルチパストラフィックディストリビュータ２２０は、遠方のネットワーク１３０に配置されているピアネットワークデバイス１５０とインタフェースをとる。これらの実施形態のそれぞれにおいて、マルチパストラフィックディストリビュータ２２０は、トランスポート層プロキシ２１０とインタフェースをとるコアエンジン３１０と、送信パス２３０とインタフェースをとる複数のパスエンジン３２０とにパーティション分割される。コアエンジン３１０は各最適化されたＴＣＰ接続３２５を１つ以上のデータフロー３３０に多重化し、これらのフローデータフロー３３０をパスエンジン３２０に分配する。各パスエンジン３２０は、特定のパス２３０に関連付けられたパイプ３４０を保持し、ここで、パイプ３４０はパス２３０の特性および状態情報を格納するために使用されるデータ構造である。

図３Ａの実施形態は、単一の遠端物理的パス２３０をサポートする（遠端とは、近端ＴＣＰエンドポイント１１０Ｎから離れた端である）。典型的には、遠端パスはワイドエリアネットワーク（ＷＡＮ）リンクであるが、当業者は、同じ原理がローカルエリアネットワーク（ＬＡＮ）リンクに適用され得ることを理解するはずである。

これらの構成要素によるパケット処理の概要が以下に説明され、パケット処理の詳細は図４および図５に関連して後に記載される。パケットが受信されると、ネットワークデバイス１５０は、まず、パケットが最適化されたＴＣＰ接続３２５に属しているかどうかを判断する。このパケットが最適化接続３２５上にある場合には、トランスポート層プロキシ２１０は、パケットが属する特定のＴＣＰ接続３２５を識別し、パケットがシーケンスで並んでいるかどうかを判断する。シーケンスで並んでいる場合には、トランスポート層プロキシ２１０はパケットをコアエンジン３１０に受け渡す。コアエンジン３１０は、パケットをバッファし、送信パス２３０への送信のために、パスエンジン３２０の１つに受け渡す。

図３Ａの実施形態は、単一の物理的送信パス２３０のみを含むために、すべてのパスエンジン３２０は（パイプ３４０を経由して）同じ単一の送信パス２３０に送出する。しかしながら、各パイプ３４０に沿った送信レートは、パイプデータ構造で保持されている、輻輳制御の現在の状態に依存する。各パスエンジン３２０はまた、送信パス２３０からの確認応答の受信を処理し、その各仮想パス上のレート制御を実行する。単一の物理的リンク上における複数のパイプ使用の一つの利点は、輻輳制御に関するものである。複数のパイプなしで、輻輳が発生するときには、単一のリンク上の送信者データレートは、例えば、５０％減少する。しかしながら、同じデータが１０個のパイプの間に分散され、損失がパイプの間に無作為に分配されるときには、各パイプ上の送信者データレートは、例えば、５０／１０＝５％だけ減少する。

図３Ｂの実施形態は、複数の送信パス２３０をサポートする。ＴＣＰ接続３５０および非ＴＣＰ接続３４５に到達するデータパケットは、まず、トリガマネージャによって分類および処理され（図９および図１０を参照）、次に、トランスポート層プロキシ２１０によって、さらに次に、コアエンジン３１０によって分類および処理される。かくして、一部のＴＣＰ接続がトランスポート層プロキシ２１０によって最適化されていなくても、コアエンジン３１０はすべてのパケット、つまり、最適化されたＴＣＰ接続３２５、ならびに、最適化されていないＴＣＰ接続、および接続３４５のような非ＴＣＰ接続を処理する。かくして、この実施形態は、すべてのタイプのパケットにおいてパスレベルの最適化を実行することができる。

受信されたパケットが最適化接続上にある場合には、トランスポート層プロキシ２１０はパケットを処理し、受信されたパケットが最適化接続上にない場合には、パケットはトランスポート層プロキシ２１０をバイパスして、コアエンジン３１０によって直接処
理される。トランスポート層プロキシ２１０はパケットが属する特定のＴＣＰ接続３２５を識別し、パケットがシーケンスで並んでいるかどうかを判断する。シーケンスで並んでいる場合には、トランスポート層プロキシ２１０は、パケットをコアエンジン３１０に受け渡す。

コアエンジン３１０は、パスエンジン３２０と協力して行われるスケジューリングの決定に基づいて、各パケットをデータフロー３３０の１つに割り当てる。各パスエンジン３２０は送信パス２３０に送出し、２つ以上のパスエンジン３２０が同じ送信パス２３０に送出することが可能である。各送信パス２３０に沿った輻輳制御が、関連付けられた送信者のパスエンジン３２０によって実行され、これは、次に、対応するピア受信側のパスエンジン（図示せず）から受信される確認応答によってアシストされる。複数のパイプ３４０が、送信のために各送信パス２３０によって集められ、逆多重化される。

図３Ｃの実施形態は、複数の送信パス２３０と、サービス品質（ＱｏＳ）とをサポートする。ＱｏＳマネージャ３６０は、異なるフローの間で使用可能なリソースを調停し、コアエンジン３１０とインタフェースを取る。フローまたはトラフィッククラスに対してＱｏＳを適用するために、ＱｏＳマネージャ３６０によって使用されるプライマリ「制御ノブ」は、使用されるデータフロー３３０の数である。つまり、ＱｏＳマネージャ３６０は、任意の時点において使用されるデータフロー３３０の数を、規定されたＱｏＳルールに収束するように、動的に適合させることによって動作する。

図３Ａおよび図３Ｂの実施形態と同様に、ＴＣＰ接続３５０および非ＴＣＰ接続３４５に到達するデータパケットは、まず、トリガマネージャによって分類および処理され（図９および図１０を参照）、次に、トランスポート層プロキシ２１０によって、さらに次に、コアエンジン３１０によって分類および処理される。しかしながら、図３Ｃの実施形態においては、ＱｏＳマネージャ３６０は、コアエンジン３１０と協力して動作し、異なるＱｏＳクラスに属する、個々のＴＣＰ接続３５０によって実現されるサービスに応じて、動的に、作成されるデータフロー３３０の数を判断する。各パスエンジン３２０は、各送信パス２３０に沿って輻輳制御を実行する一方で、その関連する送信パス２３０によって実現される帯域幅をまた保持する。ＱｏＳマネージャ３６０およびコアエンジン３１０を含む制御ループを実装することによって、各パスエンジン３２０は、そのフローの定常状態のリソース割り当てに到達することができる。送信パス２３０からの確認応答の到達がまた、関連するパスエンジン３２０に対して、受信者によるデータパケットの正常な受信を示し、信頼性処理をトリガするために使用される（以下で説明される）。

図４は、トランスポートプロトコル１６０の性能を改善するためのロジックの、選択された構成要素をさらに詳細に示す、ブロック図である。パケット分類子４１０は、トランスポート層パケットを、ＤＡＴＡ、ＡＣＫおよびその他の制御パケットに分類し、受信されパケットの性質に従って適切な処置を行う。トランスポート層プロキシ２１０内の接続マネージャ４１５、およびコアエンジン３１０内の接続マネージャ４１７は、接続に関連付けられた受信パケットに基づいて、接続状態を作成、保持および削除する。確認応答ジェネレータ／ターミネータ４２０は、ＴＣＰ送信者エンドポイント１１０へ確認応答を送信し、ＴＣＰ受信者エンドポイント１１０から確認応答を得る。プロキシフローコントローラ４２５は、マルチパストラフィックディストリビュータ２２０からの入力に基づいてＴＣＰ送信者エンドポイント１１０上でフロー制御を実行する。信頼性マネージャ４３０は、受信デバイス１５０と遠端ＴＣＰ受信者エンドポイント１１０Ｆとの間の損失検出および回復を実行する。トリガマネージャ４４０は、トランスポート層プロキシ２１０によって最適化されるこれらの接続、およびマルチパストラフィックディストリビュータ２２０によって分配されるこれらの接続を規定するために、インタフェースを提供する。このようにして、ネットワークデバイス１５０は、一部のＴＣＰ接続に影響するように、かつその他の接続には影響しないように構成され得る。

パスコントローラ４３５は、そのパスの特性、および輻輳および信頼性メカニズムからの情報に基づいて、任意の所定のパスの未処理のパケットの数を判断する。パスモニタ４５０は、パスの帯域幅、損失および遅延（例えば、平均および分散）を計算する。一部の実施形態において、これらの２つの機能は、パスエンジン３２０にパッケージング（図３）され、その他の機能はコアエンジン３１０にパッケージング（図３）される。ピア検出装置４６０は、構成されたピアデバイス１５０がアクティブであるかどうか、およびピアがオーバーレイパスのリフレクタとして使用可能であるかどうかを検出する。バッファマネージャ４５５は、送信バッファおよび受信バッファ（図２の２４０および２５０）を提供する。ディストリビュータフローコントローラ４６５は、バッファマネージャ４５５からの入力に基づいて、送信パス２３０上でフロー制御を実行する。バッファマネージャ４５５からの情報はまた、プロキシフローコントローラ４２５を制御する。送信スケジューラ４７０は、パス２３０に沿って、送信バッファ２４０およびその他の内部バッファからのパケットを送信する。一部の実施形態において、この送信機能はパスストライピングを含む。このストライピング機能についてのさらなる詳細、およびパスコントローラ４３５およびパスモニタ４５０のその他の機能は、２００５年２月２２日出願の、同一人に譲渡され同時係属中の特許出願第１１／０６３，２８４号（「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｐａｒａｌｌｅｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」）に記載されている。

図５は、トランスポートプロトコル１６０の性能を改善するためのロジックの、様々な構成要素の間の相互作用を示すデータフロー図である。トリガマネージャ４４０は、受信パケットの事前分類を実行し、様々なその他の構成要素とインタフェースをとる。トリガマネージャ４４０は、特定の設定トリガと一致するパケットの到達時に、新しい接続の作成（５０５）を接続マネージャ４１５に示す。トリガマネージャ４４０はまた、トリガ内で作成された任意の新しいＱｏＳクラスの作成（５１０）を、ＱｏＳマネージャ３６０に伝達する。パケット分類に際して、トリガマネージャ４４０は、信頼性マネージャ５３０および輻輳コントローラ５３５に対して、それぞれ、データの確認応答（５１５）および輻輳制御メッセージ（５２０）の到達を示す。トリガマネージャからの新しい接続メッセージを受信すると、接続マネージャ４１５は、新しい接続状態を作成し、さらに、バッファ状態（５４０）を作成するためにバッファマネージャ４５５を呼び出す。このバッファ状態は、接続マネージャ４１５が接続を終了し、状態を削除するまで保持される。接続マネージャ４１５は、上述したように、ＴＣＰ接続、およびパスオプティマイザ接続の両方の作成、保持、および終了を管理することに留意されたい。近端送信ネットワークデバイス１５０において、バッファマネージャ４５５は、バッファ占有率をモニタし、かつプロキシフローコントローラ４２５とインタフェースをとり、プロキシフローコントローラ４２５に、バッファ占有率が特定の高い閾値を超えているかどうか、またはいつそれが低い閾値よりも低くなるかを示すことによって（５４５）、近端ＴＣＰ送信者エンドポイント１１０Ｎ上でレート制御を実行する。遠端受信ネットワークデバイス１５０において、バッファマネージャ４５５は、送信側のトランスポート層プロキシ２１０のレートを制御するために、ディストリビュータフローコントローラ４６５と協調する。ＱｏＳマネージャ３６０は、必要なサービス割り当てを実現するために使用されるデータパスの数を含むＱｏＳクラスを構成するために（５５０）、輻輳コントローラ５３５とインタフェースをとる。この数は、動的に増減され得る。輻輳コントローラ５３５は、各サービスクラスで実現されるサービス割り当てを制御するために（５５５）、ＱｏＳマネージャ３６０とインタフェースをとる。輻輳コントローラ５３５はまた、トリガマネージャ４４０から輻輳制御メッセージ（５２０）を通じて受信された最大ウィンドウを、プロキシフローコントローラ４２５に示す（５６０）。

図６は、トランスポートプロトコル１６０の性能を改善するための、ロジックによってバッファを管理する方法を示すデータフロー図である。送信側のトランスポート層プロキシ２１０Ｓは、近端ＴＣＰ送信者エンドポイント１１０Ｎから第１の区間１７５上で受信されたアウトオブオーダー（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）・パケットを格納するための、接続専用の送信バッファ６１０を保持する。送信側のトランスポート層プロキシ２１０Ｓは、次に、シーケンスで並んだパケット（６２０）を、送信側のマルチパストラフィックディストリビュータ２２０Ｓに受け渡し、それは、パケットをその非結合バッファ６３０に格納する。非結合バッファ６３０は、中間区間１８０上の任意の特定のパスに割り当てられていない、それ故に送信されていないパケットを含む。

送信側のマルチパストラフィックディストリビュータ２２０Ｓは、そのスケジューリングアルゴリズムを使用して、非結合バッファ内のパケットが送信される時期、および同パケットが送信されるパスを判断する。送信側のマルチパストラフィックディストリビュータ２２０Ｓがこのスケジューリングの決定を行うと、それは、非結合バッファ６３０から結合バッファ６４０へ特定のパケットを送信する。結合バッファ６４０のパケットは、受信側のマルチパストラフィックディストリビュータ２２０Ｒにおける正常受信を伝達する確認応答が到達すると、削除される（６５０）。一部の実施形態において、送信側のマルチパストラフィックディストリビュータ２２０Ｓはまた、中間区間１８０上の異なるパスに割り当てられるパケットの、パケットシーケンス番号を含む仮想バッファ（図示せず）を保持する。これらの仮想バッファは、中間区間１８０における輻輳制御および信頼できる配信の実行に役立つ。

受信側のマルチパストラフィックディストリビュータ２２０Ｒは、送信側のマルチパストラフィックディストリビュータ２２０Ｓから受信されたインオーダー（ｉｎ−ｏｒｄｅｒ）・パケット（６６０）を、受信側のトランスポート層プロキシ２１０Ｒに受け渡す。受信側のマルチパストラフィックディストリビュータ２２０Ｒは、シーケンスに並んでないパケットをアウトオブオーダー・受信バッファ６７０内に格納し、それは、遠端ＴＣＰ受信者エンドポイント１１０Ｆへのデータのインオーダー配信を確実にする。インオーダー・パケットを受信すると、マルチパストラフィックディストリビュータ２２０Ｒは、トランスポート層プロキシ２１０Ｒへ受け渡し可能なさらなるパケット（６８０）がないか、アウトオブオーダー・バッファ６７０をチェックする。これらのパケットは、対応するＴＣＰ接続がアクティブである限り、受け渡しが行われる。

受信側のトランスポート層プロキシ２１０Ｒは、接続専用の受信バッファ６９０に、マルチパストラフィックディストリビュータ２２０Ｒから受信したパケットを格納する。受信側のトランスポート層プロキシ２１０Ｒは、最終区間の輻輳制御およびフロー制御（以下に記載される）と協力して行われるスケジューリング決定に基づいて、最終区間１８５上で遠端ＴＣＰ受信者エンドポイント１１０Ｆへ向けて、これらのパケットを送信する。

図７は、システム１００の一実施形態の輻輳制御を示すデータフロー図である。３つの区間の輻輳制御は３つの異なるエンティティによって実行される。第１の区間１７５上の輻輳制御は、近端ＴＣＰ送信者エンドポイント１１０Ｎによって処理される。中間区間１８０上の輻輳制御は、送信側のマルチパストラフィックディストリビュータ２２０Ｓによって実行され、最終区間１８５上の輻輳制御は、受信側のトランスポート層プロキシ２１０Ｒによって実行される。

システム１００の一部の実施形態の発明的特徴は、送信側のトランスポート層プロキシ２１０Ｓが、近端ＴＣＰ送信者エンドポイント１１０Ｎに中間区間ループ輻輳制御情報を返信することに関して、間接的に関与するということである。この返信は、２つの輻輳制御ループ（第１の区間ループおよび中間区間ループ）のバランスを取り、定常状態の送信レートに到達するうえで役立つ。送信側のトランスポート層プロキシ２１０Ｓは、ＴＣＰウィンドウメッセージ７１０を使用して、近端ＴＣＰ送信者エンドポイント１１０Ｎへ中間区間の輻輳情報を伝達する。送信側のトランスポート層プロキシ２１０Ｓによるこの中間区間輻輳制御情報の送信は、送信側のデバイス１５０Ｓの送信バッファ２４０が閾値に到達する（７２０）と、トリガされる。

同様に、受信側のマルチパストラフィックディストリビュータ２２０Ｒは、中間区間および最終区間の輻輳制御ループを安定化させるために、送信側のマルチパストラフィックディストリビュータ２２０Ｓへと最終区間１８５の輻輳制御情報（７３０）を返信する。一部の実施形態において、この輻輳制御情報は、最終区間１８５をまたぐマルチパスディストリビュータ（２２０Ｓ、２２０Ｒ）の間の、独自のフロー制御メッセージの中で伝達される。中間区間の輻輳制御の場合と同様に、受信側のデバイス１５０Ｒの受信バッファ２５０が閾値に到達する（７４０）と、受信側のマルチパストラフィックディストリビュータ２２０Ｒによるこの最終区間の輻輳制御情報の送信が、トリガされる。

図８は、システム１００の一実施形態における、フロー制御を示すデータフロー図である。エンドツーエンド通信パスの３つの区間は、それぞれ制御ループを形成する送信者および受信者の３つの異なるペアによって特徴付けられる。これらの制御ループが次に説明される。

第１の区間１７５において、近端ＴＣＰ送信者エンドポイント１１０Ｎは送信エンティティであり、送信側のトランスポート層プロキシ２１０Ｓは受信エンティティである。第１の区間１７５の受信者バッファ２５０は、送信側のマルチパストラフィックディストリビュータ２２０Ｓによるデータの送信（８２０）によってドレインされる（８１０）。これは、次に、上述したように中間区間１８０上の輻輳制御によって駆動される。このため、第１の区間１７５上のフロー制御は、送信側のデバイス１５０Ｓ上の受信バッファ２５０の占有率（８４０）に基づいて、送信側のトランスポート層プロキシ２１０Ｓによって、ＴＣＰウィンドウメッセージ（８３０）を使用して達成される。

中間区間１８０は、送信側および受信側のマルチパストラフィックディストリビュータ２２０Ｓおよび２２０Ｓにまたがっており、この受信バッファは、受信側のトランスポート層プロキシ２１０Ｒによる最終区間１８５上のパケットの送信（８６０）によってドレインされる（８５０）。受信側のマルチパストラフィックディストリビュータ２２０Ｒは、受信側のマルチパストラフィックディストリビュータ２２０Ｓへバッファ状態情報を伝達する（８７０）ことによって、中間区間１８０のフロー制御を処理する。

最後に、最終区間１８５は、送信者として受信側のトランスポート層プロキシ２１０Ｒを有し、受信エンティティとして遠端ＴＣＰ受信者エンドポイント１１０Ｆを有する。ＴＣＰ受信者エンドポイント１１０Ｆは、受信側のトランスポート層プロキシ２１０Ｒへ受信者バッファウィンドウを通知し（８８０）、受信側のトランスポート層プロキシ２１０Ｒによって、最終区間１８５上のパケット送信レートを制御する。

図９は、システム１００の一実施形態における信頼性（ＱｏＳ）処理を示すデータフロー図である。信頼性のあるパケット配信を実現するための責任は、３つの異なる論理的エンティティの間で共有される。第１の区間１７５上の信頼性は、近端ＴＣＰ送信者エンドポイント１１０Ｎによって、中間区間１８０上の信頼性は、送信側および受信側のマルチパストラフィックディストリビュータ（２２０Ｓおよび２２０Ｒ）によって、および最終区間１８５上の信頼性は、トランスポート層プロキシ２１０によって処理される。

近端ＴＣＰ送信者エンドポイント１１０Ｎは、データを送信側のトランスポート層プロキシ２１０Ｓへ送信する（９１０）。このデータに応答して、送信側のトランスポート層プロキシ２１０Ｓによって近端ＴＣＰ送信者エンドポイント１１０Ｎへ送信されるＤＵＰＡＣＫおよびＳＡＣＫ（９２０）は、第１の区間１７５上の信頼性を提供する。ＴＣＰ送信者エンドポイント１１０Ｎは、送信側のトランスポート層プロキシ２１０Ｓへ損失パケットを再送信する（９３０）。トランスポート層プロキシ２１０Ｓは、次に、送信側のマルチパストラフィックディストリビュータ２２０Ｓへ、ＴＣＰ送信者１１０Ｎからシーケンスに並んで到達するパケットを送信する。マルチパストラフィックディストリビュータ２２０Ｓは、次に、これらのパケットを中間区間１８０上に送信する。

送信側および受信側のマルチパストラフィックディストリビュータ２２０は、受信側のマルチパストラフィックディストリビュータ２２０Ｒから送信側のマルチパストラフィックディストリビュータ２２０Ｓへ送信されるＳＡＣＫメッセージ（９４０）を使用して、中間区間１８０上のパケットの信頼できる配信を実現する責任を有する。（一部の実施形態において、これらのＳＡＣＫメッセージはマルチレベルである。）送信側のマルチパストラフィックディストリビュータ２２０Ｓは、確認応答メッセージ９４０によって示される損失に応答して、結合バッファ６４０から受信側のマルチパストラフィックディストリビュータ２２０Ｒへパケットを再送信する（９５０）。

一部の実施形態において、マルチパストラフィックディストリビュータ２２０は、選択的な信頼性機能を含み、それは、トリガフィールドに一致する接続パケットのみに対して信頼性を提供するように、トリガが規定されるようにする。パス最適化に分類されるが、しかし信頼できる配信には分類されないその他のパケットが、結合バッファ６４０にコピーを格納することなく、非結合バッファ６３０から中間区間１８０に直接送信される。

受信側のマルチパストラフィックディストリビュータ２２０Ｒは、遠端ＴＣＰ受信者エンドポイント１１０Ｆへ、信頼できるパケット配信を実行する。マルチパストラフィックディストリビュータ２２０Ｒは、ＴＣＰ受信者エンドポイント１１０Ｆから受信されたＵＰＡＣＫおよびＳＡＣＫパケット（９６０）を認識し、失われたパケットを適切に再送信（９７０）し、信頼性を達成する。

拡張トランスポート層プロトコル１６５のいくつかの特徴が、以下で説明される。透過性のトランスポート層プロキシの実施形態において、ネットワークデバイス１５０は、ＴＣＰエンドポイントから受信されるパケットに追加されるトレーラの追加および処理に基づいて、それらの動作を実行する。したがって、２つのネットワークデバイス１５０間を流れるパケットは、元の通信エンドポイントによって送信されたパケットと同様である。現存するネットワーク構成要素は、パケットを識別および処理するためにヘッダを使用するために、本発明の特徴は（上述したブリッジ機能性とともに）、拡張トランスポート層プロトコル１６５がその他のネットワーク構成要素に対して透過性を有することを可能にする。

トランスポートプロトコル１６０の性能を改善するためのロジックの動作全般について説明してきたが、ここで、いくつかの構成要素の特徴が、さらに詳細に説明される。トランスポート層プロキシ２１０および／またはマルチパストラフィックディストリビュータ２２０の両方は、異なる粒度（ｇｒａｎｕｌａｒｉｔｙ）で接続の状態を保持する。一部の実施形態において、トランスポート層プロキシ２１０は、送信元および送信先のＩＰアドレスおよび送信元および送信先のポートから成る、一意的な４タプルとしてＴＣＰ接続を識別する。パケットが第１の区間１７５上で近端ＴＣＰ送信者エンドポイント１１０Ｎから到達すると、送信側のトランスポート層プロキシ２１０Ｓは、パケットの上記の４タプルをハッシュし、これが属する接続を識別する。接続状態は、近端ＴＣＰ送信者エンドポイント１１０Ｎまたは遠端ＴＣＰ受信者エンドポイント１１０ＦからのＴＣＰ ＳＹＮ−ＡＣＫパケットの到達をうけて、トランスポート層プロキシ２１０によって作成および保持される。

パスオプティマイザは、ユーザ構成トリガとのパケット一致に基づいて接続を保持する。トリガは、５タプル、つまり、送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ポート、送信先ポート、およびプロトコルの任意の組み合わせであり得る。ＯＵＴＢＯＵＮＤ区間の両側のパスオプティマイザは、トリガに基づく接続にパケットを分類し、接続ごとに上記のバッファを保持する。このために、ＴＣＰオプティマイザおよびパスオプティマイザ構成要素によって保持される接続は、パケットの同じセットの到達によって判断されるものの、パケット内の異なるフィールドに基づくものであることがわかる。

トリガマネージャ４４０は、トランスポート層プロキシ２１０および／またはマルチパストラフィックディストリビュータ２２０によって最適化されるように、接続を選択する統一メカニズムを提供する。トリガマネージャ４４０は、トランスポート層プロキシ２１０および／またはマルチパストラフィックディストリビュータ２２０の間の制御面において動作するが、それは、パケット分類がこれらの２つの構成要素によって最適化されるように、入力および分類子の異なるセットを取り得る。トリガマネージャ４４０はまた、各パケットが属する接続を判断することに対して責任を有する。この判断は、接続の作成、管理、および終了のためにパケットのフィールドの固定セットをチェックする接続マネージャ４１５と協力して行われる。

ＱｏＳマネージャ３６０は、異なる接続が受信する効率的なサービスを制御する。図４および図５に関連して上述されたトリガはまた、最小の帯域幅、優先度、および重みを有するように構成される。利用可能な帯域幅が最小帯域幅の合計よりも大きい場合には、帯域幅は重みの割合で共有される。ＱｏＳマネージャ３６０は、マルチパストラフィックディストリビュータ２２０と協力して動作し、異なるフローの間のサービスの差別化を実現する。ＱｏＳマネージャ３６０によって達成されるサービスの差別化の２つのタイプは、相対的なサービスの差別化と絶対的なサービスの差別化とである。

相対的なサービスの差別化において、トリガの重みは「ｗ」であり、各エンドツーエンドパスのトリガのために「ｗ」パイプが作成される。同じパスを通過する「ｗ」パイプのすべてのパラメータは、パイプ番号以外は同じである。このようにして、各パス帯域幅は、各トリガが得る仮想パイプの数の比率で共有される。

絶対的なサービスの差別化において、利用可能な帯域幅が最小帯域幅の合計未満である場合には、絶対的な帯域幅差別化は、自動的にキックイン（ｋｉｃｋ ｉｎ）する。最高の優先度を持つトリガがチェックされ、その構成された「ｍｉｎ＿ｂｗ」が利用可能であるかどうかを判断する。この最小帯域幅が利用可能である場合には、最小帯域幅に達していない、最大の優先度を持つトリガ（ｔｍａｘ）を優先的に見つけるために、トリガが処理される。次に、ゼロでない帯域幅を有する優先度の最も低いトリガ（ｔｍｉｎ）を見つけるために、トリガが処理される。このとき、トリガｔｍａｘの重みが１だけ増加され、トリガｔｍｉｎの重みが１だけ減少され、この手順が続けられる。

一部の実施形態において、トランスポート層プロキシ２１０、マルチパストラフィックディストリビュータ２２０、またはその両方に、性能モニタリングが実装される。トランスポート層プロキシ２１０のモニタは、ＴＣＰ最適化のために構成されるトリガに基づいて作成および保持される、これらのＴＣＰセッションによって生じる性能特性（例えば、スループット、損失および遅延）を追跡する。このモニタリングは、以下のような異なるフィルタ粒度、すなわち、事前構成されたフィルタ、静的フィルタ、動的フィルタ、および強力モニタリングフィルタ、で実行され得る。

トランスポートプロトコル１６０の性能を改善するためのロジックの動作全般について説明してきたが、ここで、このプロトコルのいくつかの特徴がさらに詳細に説明される。当業者は、これらの特徴は概して互いに独立しており、その結果として、拡張トランスポート層プロトコル１６５の特定の実施形態は、これらの特徴の一部の組み合わせを含み得ることを理解するはずである。拡張トランスポート層プロトコル１６５は、ＴＣＰとは異なり、その他のアプリケーションおよびサービスとメモリを共有することを要求されない。デバイスのメモリ全体が、アクティブな接続のパケットのバッファリングのために専用され得る。さらに、この大きいバッファは、接続のためのいかなる固定割り当てをも含まずに、複数のアクティブなエンドツーエンド接続の間で柔軟に共有される。ネットワーク内の最大未処理パケットに課される制限による、大きな帯域幅遅延結果を有するネットワークにおいて、ＴＣＰ性能は制約を受ける。拡張トランスポート層プロトコルは、小型ウィンドウの制限事項を排除し、アクティブな接続のパケットをバッファするためのシステムに利用可能なメモリ全体の完全な共有を達成することによって、大きな帯域幅遅延結果を有するネットワークにおけるエンドツーエンド接続の性能を改善する。

上述のように、パケットは、処理のために様々な構成要素間で受け渡しされる。一部の実施形態において、メモリ使用の効率を増大させるゼロコピー技術が使用される。ゼロコピーパケット処理は、パケットにアクセスする構成要素の数を追跡するために、内部パケット表現の中の数参照（ＮｕｍＲｅｆｅｒｅｎｃｅｓ）フィールドを使用する。構成要素がパケットを処理するときはいつでも、それは数参照フィールドを増加させる。構成要素が処理を終了するときには、それはｎｕｍ＿ｒｅｆｅｒｅｎｃｅｓ値を減少させる。これによって、構成要素間でパケットを渡すときのコピーの必要性が回避される。

上述のように、送信側のマルチパストラフィックディストリビュータ２２０Ｓにおける確認応答の到達が、結合バッファ６４０からパケットの削除をもたらす。確認応答パケットは複数のパケットの正常受信を示すことができるので、これは、大量のパケット数のためのメモリをただちに空の状態にすることができ、この割り当て解除は、システム上でのドレインとなり得る。これを避けるために、トランスポートプロトコル１６０の性能を改善するためのロジックの一部の実施形態は、レイジーな（ｌａｚｙ）メモリ割り当て解除メカニズムを含む。このメカニズムは、確認応答の到達時に空になるパケットのシーケンス番号を格納し、次に、大量のメモリの割り当て解除を一時に行うのではなく、以降のパケット送信サイクルの間に、パケットメモリの実際の割り当て解除を拡大する。

トランスポート層プロキシ２１０とマルチパストラフィックディストリビュータ２２０との統合は、最終区間１８５上を移動するパケットの中で伝達される情報量を増加させる。これは、次いでは、各パケットの中で伝達され得るエンドユーザデータの量を減少させる。従来のソリューションは、元のパケットへ拡張トランスポートプロトコルヘッダを追加し、次に、従来のフラグメンテーションおよび再構成メカニズムを介して、中間区間１８０内のＩＰ層に増加したセグメントサイズを引き受けさせる。インライン速度でのＩＰパケットのフラグメント化および再アセンブリに関するオーバーヘッドを考慮すれば、この従来のアプローチは非効率的である。本明細書で開示される方法およびシステムは、中間区間１８０上でサポートされるＭＴＵを示す送信者へのＩＣＭＰメッセージの返信を含み、この値は、中間区間１８０上の移動のためにパケットに追加される拡張トランスポートプロトコルのサイズだけ減少された、実際のＭＴＵである。このＩＣＭＰメッセージは、送信者に最適セグメントサイズを知らせ、中間区間１８０上のフラグメンテーションおよび再アセンブリのオーバーヘッドを減少させる。

一部の実施形態はまた、ピアおよびこれらのピアによってサポートされる機能を識別することに役立つ、自動検出機能を含む。一部の実施形態は、特定の選択された機能の有効化をサポートし、この場合には、ピアネットワークデバイス１５０は、どの機能が他のピアで有効化されるかを判断する。この機能判断は、任意の未知のホストへの制御メッセージ（「Ａｒｅ ｙｏｕ ｔｈｅｒｅ？」）の送信を含む。ホストへのパスに沿ってネットワークデバイス１５０が存在する場合には、ネットワークデバイス１５０は、ネットワークデバイス１５０の存在、さらに、そこにおいて有効化されている機能を示す、別の制御メッセージ（「Ｉ ａｍ ｈｅｒｅ」）を用いて応答する。

一部の実施形態は、ネットワークアドレス変換（ＮＡＴ）デバイスを通過するためのメカニズムとして、ハートビートを使用する。従来のＮＡＴ通過は、ＮＡＴデバイスの後ろに配置されているピアの間の通信を調整する、セントラルサーバを使用する。本明細書で開示されるシステムおよび方法は、ネットワークデバイス１５０に、プライベートネットワーク内からのハートビートを送信させることによって、ＮＡＴ通過を達成する。これらのハートビートは、ＮＡＴデバイス内に「穴」を開け、その結果として、ピアネットワークデバイス１５０からの以降のハートビートメッセージ（およびプロトコルパケット）が、状態作成の結果として配信され得る。

図１０は、本明細書において開示されるトランスポート層プロトコルの性能を改善するための、本システムおよび方法の一実施形態に従った、ネットワークデバイス１５０のハードウェアブロック図である。ネットワークデバイス１５０は、プロセッサ１０１０、ローカルネットワークインタフェース１０２０、リモートローカルインタフェース１０３０、メモリ１０４０、および非揮発性ストレージ１０５０を含む、データ通信の当該分野では周知の多数の構成要素を含む。不揮発性ストレージの例は、例えば、ハードディスク、フラッシュＲＡＭ、フラッシュＲＯＭ、ＥＥＰＲＯＭ、などを含む。これらの構成要素は、バス１１６０を介して連結される。メモリ１１４０は、図１のトランスポートプロトコル１６０の性能を改善するためのロジックを含む。

ネットワークデバイス１５０は、２つのネットワークインタフェースとともに示されている。ローカルネットワークインタフェース１０２０はエンドポイント１１０と通信し、リモートローカルインタフェース１０３０はネットワークデバイス１５０と通信する。当業者は、ネットワークインタフェースが、異なるタイプのものであり、異なる媒体および速度に対応し得ることを理解するはずである。当業者には公知の、ネットワークデバイス１５０の動作について説明するために必ずしも必要でない多数の従来の構成要素が、図１０から省略されている。

フローチャート内の任意のプロセス記述またはブロックは、当該プロセスにおける特定の論理的機能またはステップを実装するための、１つ以上の実行可能命令を含むモジュール、セグメント、またはコードの部分を表すものとして理解されるべきである。ソフトウェア開発分野の当業者によって理解されるように、代替的実装がまた、本開示の範囲内に含まれる。これらの代替的実装において、機能は、含まれる機能性に応じて、実質的に同時または逆の順序を含む、図示または考察されているものとは異なる順序で実行され得る。

本明細書において開示されるシステムおよび方法は、命令実行システム、装置、もしくはデバイスによって使用するための、またはそれらと接続して使用するための任意のコンピュータ可読媒体において具現化され得る。そのような命令実行システムは、任意のコンピュータベースのシステム、プロセッサ包含システム、または、命令実行システムからの命令をフェッチおよび実行し得るその他のシステムを含む。本開示の文脈において、「コンピュータ可読媒体」は、命令実行システムによって使用するための、またはそれと接続して使用するためのプログラムを包含、格納、通信、伝搬、または運搬し得る任意の手段であり得る。コンピュータ可読媒体は、これらに限定するものではないが、例えば、電子、磁気、光学、電磁気、赤外線、または半導体技術に基づくシステムまたは伝搬媒体であり得る。

電子技術を使用するコンピュータ可読媒体の具体例は、（これらに限定するものではないが）１本以上のワイヤを有する電気的接続（電子）、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能リードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）を含み得る。磁気技術を使用する具体例は、（これに限定するものではないが）ポータブルコンピュータディスケットを含む。光学技術を使用する具体例は、（これらに限定するものではないが）光ファイバおよびポータブルコンパクトディスクリードオンリメモリ（ＣＤ−ＲＯＭ）を含む。

前述の記述は、図示および説明を目的として提示されたものである。それは、網羅的であることも、開示されている厳密な形態に本開示を限定することも意図していない。上記の教示に鑑みて、明らかな修正形態または変形形態が可能である。しかしながら、考察された実装は、本開示の原理およびその実践的応用を説明し、それによって当業者が、種々の実装において、および意図される特定の使用に適した種々の修正形態とともに、本開示を利用することを可能にするように、選択および説明されたものである。すべてのそのような修正形態および変形形態は、添付の請求項が公正かつ合法的に権利を与えられた範囲にしたがって解釈されるときの、特許請求の範囲によって決定される本開示の範囲内に含まれる。

Claims (20)

1. トランスポート層プロキシと、
   該トランスポート層プロキシに連結された、マルチパストラフィックディストリビュータと、
   を備える、ネットワークデバイスであって、
   該トランスポート層プロキシは、
   トランスポート層接続にそれぞれ関連付けられたパケットを、トランスポート層エンドポイントから受信し、
   かつ、該受信されたパケットの少なくとも一部を、該マルチパストラフィックディストリビュータへ配信するように構成され、
   該マルチパストラフィックディストリビュータは、
   該配信されたパケットのそれぞれを、複数のデータフローの１つに割り当て、
   かつ、該割り当てられたデータフローに関連付けられた送信パス上で、該配信されたパケットのそれぞれを送信するように構成される、
   ネットワークデバイス。
2. 前記送信パスは、複数の送信パスの１つである、請求項１に記載のネットワークデバイス。
3. 前記送信パスは、前記データフローのすべてに関連付けられた単一の送信パスである、請求項１に記載のネットワークデバイス。
4. 前記受信されたパケットに対応するトランスポート層接続上で使用されるトラフィックのクラスによって規定されるサービス品質を達成するために、前記複数のデータフロー内のデータフローの数を設定するように構成されたサービス品質（ＱｏＳ）マネージャをさらに備える、請求項１に記載のネットワークデバイス。
5. 前記ＱｏＳマネージャは、相対的なサービスの差別化を図るために、データフローの前記数を設定するようにさらに構成される、請求項４に記載のネットワークデバイス。
6. 前記ＱｏＳマネージャは、絶対的なサービスの差別化を図るために、データフローの前記数を設定するようにさらに構成される、請求項４に記載のネットワークデバイス。
7. 前記送信パスは、複数の送信パスの１つである、請求項１に記載のネットワークデバイスであって、
   所望のサービス品質に基づいて、該複数の送信パスのそれぞれと関連付けられた多数のデータフローを制御するように構成された、サービス品質（ＱｏＳ）マネージャをさらに備える、ネットワークデバイス。
8. トランスポート層プロキシと、
   該トランスポート層プロキシに連結された、マルチパストラフィックディストリビュータと、
   を備える、ネットワークデバイスであって、
   該トランスポート層プロキシは、
   トランスポート層接続にそれぞれ関連付けられたパケットを、トランスポート層エンドポイントから受信し、
   該受信されたパケットを、対応する接続に関連付けられたバッファに格納するように構成され、
   該マルチパストラフィックディストリビュータは、
   パケットを、該バッファから送信パスへ送信し、
   該送信パス上の輻輳を示す、輻輳制御情報を、ピアマルチパストラフィックディストリビュータから受信するように構成され、
   該トランスポート層プロキシは、さらに、
   該バッファの占有率に基づいて制御パケットを、該トランスポート層エンドポイントへ送信するように構成され、該制御パケットは、該輻輳制御情報を示す、
   ネットワークデバイス。
9. 前記マルチパストラフィックディストリビュータは、
   前記ピアマルチパストラフィックディストリビュータと第２のトランスポート層エンドポイントとの間のパス上の輻輳を示す情報を、該ピアマルチパストラフィックディストリビュータから受信するようにさらに構成され、該情報の受信は、該ピアマルチパストラフィックディストリビュータ内のバッファの占有率に基づく、
   請求項８に記載のネットワークデバイス。
10. トランスポート層プロキシと、
    該トランスポート層プロキシに連結された、マルチパストラフィックディストリビュータと、
    を備える、ネットワークデバイスであって、
    該トランスポート層プロキシは、
    トランスポート層接続にそれぞれ関連付けられたパケットを、トランスポート層エンドポイントから受信し、
    かつ、該受信されたパケットを、該対応する接続に関連付けられたバッファに格納するように構成され、
    該マルチパストラフィックディストリビュータは、
    送信パス上の輻輳を示す、ピアマルチパストラフィックディストリビュータから受信された輻輳制御情報に応答して、パケットを該バッファから該送信パスへ送信するように構成され、
    該トランスポート層プロキシは、さらに、
    該バッファの占有率に基づいてフロー制御パケットを、該トランスポート層エンドポイントへ送信するように構成される、
    ネットワークデバイス。
11. 前記マルチパストラフィックディストリビュータは、
    前記ピアマルチパストラフィックディストリビュータ内の受信バッファ占有率を示す情報を、該ピアマルチパストラフィックディストリビュータから受信し、
    かつ、該受信バッファ占有率を示す情報に応答して、パケットを該バッファから送信パスへ送信するように、さらに構成される、
    請求項８に記載のネットワークデバイス。
12. トランスポート層プロキシと、
    該トランスポート層プロキシに連結された、マルチパストラフィックディストリビュータと、
    を備える、ネットワークデバイスであって、
    該トランスポート層プロキシは、
    トランスポート層接続にそれぞれ関連付けられたパケットを、トランスポート層エンドポイントから受信し、
    該受信されたパケットが欠落または誤パケットを含むかどうかに基づいて、再送信制御パケットを、該トランスポート層エンドポイントへ送信し、
    かつ、該受信されたパケットの少なくとも一部を、該マルチパストラフィックディストリビュータへ配信するように構成され、
    該マルチパストラフィックディストリビュータは、
    該配信された各パケットを、送信パス上で送信し、
    かつ、該制御パケットによって指示されるように、該配信されたパケットを再送信することによって、ピアマルチパストラフィックディストリビュータから受信された再送信制御パケットに応答するように構成される、
    ネットワークデバイス。
13. 前記トランスポート層プロキシおよび前記マルチパストラフィックディストリビュータは、それぞれ、トランスポート層接続に関連付けられた状態情報を、独立して維持するようにさらに構成される、請求項１２に記載のネットワークデバイス。
14. トランスポート層プロキシと、
    該トランスポート層プロキシに連結された、マルチパストラフィックディストリビュータと、
    を備える、ネットワークデバイスであって、
    該トランスポート層プロキシは、
    トランスポート層接続にそれぞれ関連付けられたパケットを、トランスポート層エンドポイントから受信し、
    かつ、該パケットがシーケンスで並んでいる場合には、該受信されたパケットのそれぞれを、該マルチパストラフィックディストリビュータへ配信するように構成され、
    該マルチパストラフィックディストリビュータは、
    該配信されたパケットのそれぞれを、送信パスに割り当てられていない非結合バッファに格納し、
    かつ、該配信されたパケットのそれぞれを、送信パス上で送信するように構成される、
    ネットワークデバイス。
15. 前記マルチパストラフィックディストリビュータは、さらに、
    パケットを、ピアマルチパストラフィックディストリビュータから受信し、
    シーケンスで並んでいない受信されたパケットを、アウトオブオーダー・バッファに格納し、
    かつ、インオーダー・シーケンスを生成するために、前記ピアからさらなるパケットが受信されると、パケットを、該アウトオブオーダー・バッファから前記トランスポート層プロキシへ配信するように構成され、
    該トランスポート層プロキシは、さらに、
    アウトオブオーダー・バッファから配信されたパケットを、受信バッファに格納し、
    かつ、該受信バッファに格納されたパケットを、前記トランスポート層エンドポイントへ送信するように構成される、
    請求項１４に記載のネットワークデバイス。
16. 前記受信されたパケットの１つを格納するために使用されるパケットデータ構造は、各構成要素が該パケットの処理を開始すると増加し、各構成要素が該パケットの処理を完了すると減少する参照数フィールドを含む、請求項１４に記載のネットワークデバイス。
17. 送信されたパケットの確認応答を受信するように構成されたロジックであって、該確認応答は該送信されたパケットのシーケンス番号を含む、ロジックと、
    該受信された確認応答に応答して、該シーケンス番号を格納するように構成されたロジックと、
    該送信されたパケットに関連したメモリを空にすることを、該受信された確認応答よりも後の時点へと遅延させるように構成されたロジックと、
    をさらに備える、請求項１４に記載のネットワークデバイス。
18. 前記マルチパストラフィックディストリビュータは、
    前記送信パスに対する最大送信単位（ＭＴＵ）を決定し、
    ローカルＭＴＵを、該マルチパストラフィックディストリビュータによって使用される拡張トランスポート層プロトコルヘッダのサイズ分だけ縮小された、該送信パスに対するＭＴＵとなるように設定し、
    かつ、該送信パス上のピアネットワークデバイスに、該ローカルＭＴＵを通知するように、
    さらに構成される
    請求項１４に記載のネットワークデバイス。
19. 前記ネットワークデバイスは、前記送信パス上のピアネットワークデバイスの存在および機能を検出するように構成されたロジックをさらに備える
    請求項１４に記載のネットワークデバイス。
20. 前記ネットワークデバイスは、前記送信パス上のピアネットワークデバイスへ、ハートビートメッセージを送信するように構成されたロジックをさらに備える、
    請求項１４に記載のネットワークデバイス。

Images