JP7154739B2 - ＩＰｖ６ ＴＣＰ／ＩＰネットワークを介する高度な大規模データ伝送および致命的輻輳回避 - Google Patents

Description

関連出願の相互参照
[0001]本出願は、各内容が本明細書において完全に記載されたかのように参照によって本明細書に組み込まれている、２０１３年９月１９日に出願した米国仮出願第６１／８８０，０７０号の優先権を同様に主張する、２０１４年９月１９日に出願した米国非仮出願第１４／４９１，８４３号の一部継続出願であり、その優先権を主張するものである。

[0002]本発明の例示的実施形態は、概してネットワーク通信に関し、より詳細には、ＴＣＰ／ＩＰネットワークを介して大きなデータセットを送信するときに致命的な輻輳障害および資源の無駄を避けるシステムおよび方法に関する。

[0003]インターネットおよび他の同様のネットワークで使用される最も重要な通信プロトコルのうちの２つは、伝送制御プロトコル（ＴＣＰ）およびインターネットプロトコル（ＩＰ）である。ＴＣＰおよびＩＰプロトコルは、ともに、パケット交換ネットワークで使用されるより大きなインターネットプロトコル群のコアプロトコルを形成する。そのプロトコル群は、ＴＣＰおよびＩＰプロトコルが広く採用および実装されていることから、一般にＴＣＰ／ＩＰプロトコルと称される。

[0004]ＴＣＰ／ＩＰプロトコルは、米国高等研究計画局（ＡＲＰＡ：Ａｄｖａｎｃｅｄ Ｒｅｓｅａｒｃｈ Ｐｒｏｊｅｃｔｓ Ａｇｅｎｃｙ）のために開発された。ＴＣＰ／ＩＰプロトコルは、異なるタイプのネットワーク対応デバイスまたはネットワーク接続されたデバイスが互いに通信することを可能にするルールのセットである。それらのネットワークデバイスは、ＴＣＰ／ＩＰ標準またはフォーマットを使用してデータを転送または共有することによって通信する。ＴＣＰ／ＩＰルールは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）によって確立され、維持される。ＩＥＴＦは、インターネットのアーキテクチャおよび運営に関わるネットワーク設計者、オペレータ、ベンダー、および研究者の国際的団体である。ＩＥＴＦの使命は、インターネットの運用および効率の改善を目的として、人々がインターネットを設計、使用および管理する方法に影響を与える技術的および工学的文書を作り出すことである。これらの文書は、プロトコル標準、最良の現行実施例、および様々な種類の最新情報を含み、一般に、リクエストフォーコメント（ＲＦＣ：Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）と称される。

[0005]ＴＣＰは、２つのクライアントの間の双方向接続を確立するために使用され得、そこでは、１つのクライアントによって別のクライアントに対して行われる情報の要求から活動が始まる。「クライアント」は、あるリモートロケーションから別のリモートロケーションへの情報の要求を開始するかまたはそのような情報を送る任意のプログラムまたはアプリケーションである。本明細書で用いられる場合、「クライアント」という用語は、これらに限定されないが、ウェブブラウザ、ウェブサーバ、ファイル転送プロトコル（ＦＴＰ）プログラム、電子メールプログラム、プリンタエミュレータとしても知られるラインプリンタ（ＬＲＰ）プログラム、携帯電話アプリ、およびターミナルエミュレータとしても知られるテルネットプログラムを含む、そのようなアプリケーションを指し得、それらはすべて概念的にはアプリケーション層で動作する。

[0006]ＴＣＰプロトコルは、通常は、プロトコル層のＴＣＰ／ＩＰスタックの一部である「デーモン」として実装される。デーモンは、しばしば同義的にサーバーまたはサービスとも称され、一般に、バックグラウンドプロセスを実行する、デバイスのソフトウェア構成要素である。本明細書でＴＣＰプロトコルの動作に関連して用いられる場合、「デーモン」という用語は、ＴＣＰ標準に従ってリモートクライアント間の通信を送信（ソースデーモン）または受信（宛先デーモン）してそれを処理する、ネットワークデバイスの構成要素を指すために使用される。

[0007]ホストは、ＴＣＰ／ＩＰデーモンを実行または遂行するデバイスまたはシステムである。本明細書で用いられる場合、「ホスト」という用語は、これらに限定されないが、サーバープラットフォーム、パーソナルコンピュータ（ＰＣ）、および、ＴＣＰソフトウェアを実装または実行する任意の他のタイプのコンピュータもしくは周辺デバイスを含む、任意のそのようなデバイスまたはシステムを指す。一般に、ホストは、物理的に、クライアントおよびデーモンをＴＣＰ／ＩＰネットワークに接続およびリンクし、それによってクライアント間の通信を可能にする。

[0008]ＴＣＰソフトウェアは、接続がアクティブである時間の間、クライアントおよび他のデーモンから要求およびデータストリームを直接受け付け、ストリーム中で、バイトまたはオクテットに連続して番号を付ける。必要なときには、ＴＣＰソフトウェアは、要求クライアントに送信するために、データストリームを、セグメントと称される（時には概してデータグラムまたはパケットと称される）より小さい個片に分ける。プロトコルは、信頼できるデータ伝送を確保するために、チェックサム、連続番号、タイムスタンプ、タイムアウトカウンタ、および再送アルゴリズムの使用を必要とする。［ＲＦＣ７９３、１９８１］

[0009]ＩＰ層は、実際に、２つのネットワークホストの間で通信機能を実行する。ＩＰソフトウェアは、ＴＣＰ層からデータセグメントを受信し、セグメントが伝送パスおよび物理アダプタ（イーサネット（登録商標）およびＣＴＣなど）の要件を満たすように適切にサイズ指定されることを確保する。ＩＰは、必要に応じて、セグメントをより小さいＩＰデータグラムに分けることによってセグメントサイズを変更し、データをホストの物理ネットワークインターフェースまたは層に送信する。［ＲＦＣ７９１、１９８１］

[0010]ＩＰ（および他の同様のインターネット層プロトコル）ソフトウェアは、信頼性のためには設計されない。ＴＣＰは、ＩＰがデータを直ちに送信することを期待し、したがって、ＩＰは、さらなるチェックなしにデータを送る。実際の伝送が遅れたかまたは不完全である場合、データは破棄される。送信が成功したデータは、受信ホストＴＣＰソフトウェアに渡されるが、受信ホストＴＣＰソフトウェアは、その検証および受信確認システムを使用して、要求されたデータが要求クライアントによって受信されることを確保する。送信ホストＴＣＰソフトウェアが、完全な伝送の受信確認を受信しない場合、それは、データを再送信する。このシステムの１つの帰結は、物理通信パスが飽和したまたは他の形で使用不可能になったときに再送信が増えることであり、それは、ひいてはＣＰＵおよびネットワーク容量の消費を増加させる。

[0011]大規模システム影響は、有限サイズおよび複雑性をもつ特定の条件のセットに対処するように設計された処理システムで生じる。期待よりも大きく複雑な条件を提示されたとき、それらのシステムは、もはや効率的にまたは全く動作しなくなる。この影響を説明するために、期待されるトラフィック量のサイズに基づいて効率的なトラフィックの流れを可能にするために、１分間隔で変わるように時間設定された停止信号を有する交差点にある１つの主要交差道路を有する小さな町を想像する。通常の動作条件では、任意の所与の方向からその街に入り、その街を去る車の数が、設計パラメータ内に収まる量であるとき、その設計は効率的に機能する。しかしながら、交差道路を使用するトラフィックが、１分のトラフィック停止の間に処理され得る量を超えて増加すると、混雑が生じることになる。過剰なトラフィック量が、１分のウィンドウの間に交差点を通過することができる車の最大数未満に減らない場合、混雑は悪化し続けることになる。したがって、町に入る新たな車が、期待される設計容量を超え続ける場合、トラフィックシステムは、最終的に破綻することになる。この形でのシステムの破綻は、大規模システム影響による。

[0012]このタイプのシステム的問題は、秩序のある動作からカオスへと移る非線形システムと称され得る。前の例では、トラフィックの増加は非線形であり、システム動作の進捗は、反復的であり、非線形条件の変化を補正しないので、システムは、秩序のある動作からカオスへと移った。システムが多数の変化し拡大する基準に対処するように設計され得ることを人は望むであろうが、システムは、実際合理的に想定され得ることに対処するようにしか設計できないため、現実は遥かに不確定である。

[0013]大規模システム影響によって生み出されるカオス的動作は、秩序からカオスへの円滑なまたは増加する動きとして生じることはあまりない。カオス的秩序は、システム挙動における致命的な崩壊として生じる傾向がある。システムの制御パラメータのゆっくりとした変化であっても、壊滅的状態への突然の移行をもたらし得る。この種の現象は、海面気圧における水と氷の遷移において生じる。すなわち、温度が氷点を下回ると、水は固体状態への遷移を示す。そのような大規模システム影響を潜在的に経験し得るシステムは、観測可能な円滑な遷移なしに、間隔をおいて突然の致命的な挙動を示し得る。

[0014]小さい構成または低いトランザクション速度では効率的であるが、大きな構成または高いトランザクション速度では非効率的であるアルゴリズムが使用されるときに、大規模なシステム影響が、コンピュータネットワークシステム、プロトコル、および実装形態において生じ得る。ＴＣＰ／ＩＰおよびネットワーク通信に関連して、ＴＣＰ標準は、接続されたクライアントの間のデータストリームの伝送速度を制御する。ネットワークホストの処理能力およびストレージがさらに豊富になると、クライアントが要求し送信するデータの量も同様に増える。特に、ネットワーク接続された「スマート」デバイスの数の急速な増加およびＰＣの普及を考慮するとき、今日のクライアントの多くは、ネットワークの輻輳への傾向を増大させる、ますます高いデータ転送速度を必要とする。

[0015]現在のＴＣＰ実装形態は、送信デーモンが、受信デーモンが着信ストリームを処理し得るよりも速くデータを送信しないことを確保するために、フロー制御機構を使用する。標準は、受信デーモンが受け付ける用意のあるデータの量を送信デーモンに指示する、各受信確認に含まれるアドバタイズされたウィンドウサイズ（advertized window size）を定義する。ＴＣＰの「アドバタイズされたウィンドウ」は一部には、任意の所与の時間の伝送において未処理のＴＣＰセグメントの数を制限するために受信デーモンによって使用される論理ウィンドウを説明するために使用される用語であり、リモート送信クライアントがＴＣＰプロトコルを使用してＩＰ接続を介して送ることを承認されたバイトの数を表す。アドバタイズされたウィンドウは、受信デーモンが送信デーモンにセグメント／受信確認を送るたびに受信デーモンが自身のバッファーサイズを指定することを可能にする。アドバタイズされたウィンドウおよび受信確認された最も大きいシーケンス番号はともに、ウィンドウエンドポイント、すなわち、受信デーモンのウィンドウ内で最後の位置に続くバイトのシーケンス番号、を生じさせる。

[0016]ルールの１つは、このエンドポイントは決して逆行する方に移動すべきではないということである（縮小するウィンドウ）。通常の状況では、データが受信されると、データは受信確認され、アドバタイズされたウィンドウはさらに拡張される。データが、それが収容され得るよりも速く到達する場合でも、データはやはりタイムリーに受信確認される必要があるが、ウィンドウのエンドポイントは繰り上げられない。最終的に、アドバタイズされたウィンドウ内のすべてのデータが送信され、エンドポイントに達し、ウィンドウが閉じられる。ウィンドウが閉じられた後は、それが再度開かれるまで、それ以上のデータは受け付けられないことになる。ルールの１つは、ウィンドウが再び開かれるとき、ウィンドウはその最大サイズまで完全に再び開かれなければならないということである。

[0017]ＴＣＰ送信デーモンはまた、送信を許可されたデータストリーム内のバイト（送られたバイトおよび送られていないバイトを含む）をカバーする「再送信ウィンドウ」と称される論理ウィンドウを使用する。通常の状況で動作するＴＣＰ再送信ウィンドウサイズは、アドバタイズされたウィンドウサイズに設定され、それによって定義される。全体的な伝送速度を上げるために、ＴＣＰは、ウィンドウサイズを遥かに超えてバッファリングし、あらゆる受信確認でアドバタイズされたウィンドウをその最大値に維持する。これは、データ送信の増加を促すが、一方ではまた、ＴＣＰプロトコルを大規模システム影響にさらす。

[0018]送信されるデータストリームのフローレートは増大したが、一方で、ＩＰネットワークで送信される情報の実際のパケット、たとえば共通物理イーサネットハードウェア層のサイズ要件は増えていない。ＴＣＰ最大セグメントサイズ（ＭＳＳ：Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）のオプションは、好ましくは、ネットワークの最も小さい最大伝送単位（ＭＴＵ：Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）より大きくならないようにセグメントサイズを設定するために使用される。したがって、より大きいウィンドウサイズは、データストリームのより大きいシーケンス範囲の伝送を可能にするので、送信されるデータの特定のウィンドウは、確立されたＭＳＳより大きくない、より多数のセグメントに分けられる必要がある。ＴＣＰは、肯定的な累積受信確認プロトコル（positive cumulative acknowledgement protocol）であり、したがって、受信確認が、受信された各セグメントについて送られる場合、大きなウィンドウにおいて送信されるより多数のセグメントは、潜在的に未処理の受信確認の数を増やすことによって、さらに多くのネットワークトラフィックを生成する。

[0019]さらに、受信確認の過剰送信を避けるために行われるＴＣＰ実装形態への調整は、ネットワーク内の輻輳がデータの単一セグメントの損失を引き起こす場合、ストリーム全体への損傷を修復するために、しばしばウィンドウ全体が再送信される必要があることを意味する。［ＲＦＣ８１３］この再送信は、ネットワーク内のトラフィックの非線形の拡張を引き起こし、したがって、追加のパケット損失およびその後の追加の再送信をもたらす。ＴＣＰは、最終的に必要とされるよりも多くのデータが再送信されることを必要とするので、この致命的な挙動が引き起こされ、輻輳崩壊を引き起こす。この大規模システム影響は、ＩＰバージョン６（ＩＰｖ６）で提示されたＩＰへの付加的な機能強化によっては訂正されない。

[0020]ＴＣＰ／ＩＰネットワークにおけるそのような潜在的輻輳障害を訂正する試みが行われた。ＴＣＰ仕様自体は、固有の輻輳制御機構を規定しないが、実装形態では、ＴＣＰ機能を使用して、そのような機構を実現することができる。たとえば、多数のＴＣＰ実装形態は、送信デーモンが受信確認されていないセグメントを自身の再送信ウィンドウ内で再送信するまでの時間周期を変更するために、適応型再送信アルゴリズムの使用を含む。

[0021]輻輳のためにネットワーク待機時間が増え始めると、より最近のＴＣＰ標準では、再送信を遅らせることに加えて、スロースタートな追加回復および乗法減少輻輳回避アルゴリズムを含む、輻輳回避のいくつかの方法を含む。［ＲＦＣ２２０１］受信デーモンのアドバタイズされたウィンドウサイズよりも小さいサイズが、送られるシーケンス範囲を制限するために使用される場合、これらのアルゴリズムが、輻輳ウィンドウサイズを追跡するために送信デーモンによって使用される。しかしながら、これらのおよび他の同様のアルゴリズムの実装は、保守的な輻輳推定アルゴリズムであるので、再送信ウィンドウを不必要に限定することによってデータ転送速度を大きく低下させ得る。

[0022]選択的な受信確認オプションなどの他のオプションのＴＣＰ機能が、重複したデータ再送信の確率を下げるために導入される。選択的な受信確認オプションは、受信されていない１つまたは複数のセグメント内のシーケンス番号より大きいシーケンス番号で受信された非連続データのいくつかのブロックを、受信デーモンが指定することを可能にする。送信デーモンは、次いで、順序に反して受信されたブロック内のデータを含まない再送信を構築することができる。［ＲＦＣ２０１８］選択的な受信確認オプションは有用であるが、３２ビットシーケンス番号の境界を付けること、実際には３つまたは４つの非連続ブロックのデータにこのオプションを制限すること、によって非連続データブロックを受信確認する必要があるという事実によって、選択的な受信確認オプションは制限される。したがって、ウィンドウ伝送における最初の３つまたは４つの失われたセグメントを超えてのデータの再送信は、重複することになる。

[0023]特にＩＰｖ６に関して、新しいＩＰプロトコルは、パス上の中間ノードからすべてのＩＰレベル断片化を取り除く。このレベルでの断片化は、ソースでのみ実行され得る。ＩＰ層が上位層（たとえば、ＴＣＰ）からデータのパケットを受信した後、ＩＰ層は、パケットサイズが、イーサネットまたは他のハードウェアインターフェースなどの伝送パスおよび物理アダプタの要件を満たすことを確保する。必要に応じて、ソースＩＰデーモンは、リモートホスト間のネットワークパスのリンク層を介する伝送に先立ってデータグラムを断片化することによって、パケットサイズを低減する。重要な点として、ＩＰｖ６断片化プロトコルは、受信ホストがある期間にわたってデータグラム断片を保持することを必要とし、すべての断片が再構築時間内に受信されない場合、それらの断片は破棄され、エラーメッセージが発送され、データグラム全体が再送信されることを必要とする。

[0024]ＩＰｖ６は、既存のＩＰｖ４ネットワークを置き換えるために設計されたので、以前のネットワーク定義に関して、新しいＩＰｖ６実装形態の効率に重大な影響を有する、歴史的な副産物が存在する。任意のネットワーク内で、データ伝送のサイズは、最終的には、通信ノード間のすべての電気経路によって受け付けられ得る最小の伝送サイズに制限される。たとえば、サーバーからコンピュータへのネットワークパスがイーサネットセグメントを含む場合は、ネットワーク経路の大部分のサイズ能力がどのくらいロバストであるかにかかわらず、すべての伝送はイーサネットによって課される１５００バイトの制限内に収まる必要がある。ＩＰデータグラムのデータペイロードの長さは、単に、送られる上位層データペイロードの量ではなく、ＩＰｖ４またはＩＰｖ６のデータグラムヘッダー情報の長さも含んでいる。ＩＰｖ６のデータグラムヘッダーは、より古いＩＰｖ４プロトコルのデータグラムヘッダーよりかなり長いので、ＩＰｖ４のために構成されたネットワークは、かなりの量のデータグラム断片化を課し得る。言い換えれば、ＩＰｖ６ヘッダーの長さは、ＩＰｖ４のヘッダーより長いので、ＩＰｖ４データトラフィックを運ぶために定義されたネットワークは、断片化の回避を優先するにもかかわらず、より大きいＩＰｖ６データグラムが定常的に断片化されることになる。この問題は、エンドユーザーには見えず、ネットワーク輻輳およびそれから生じる付随する大きな計算需要によってのみ認識される。

[0025]ＩＰｖ６は、完全なデータグラムをいくつかの個片に断片化する能力を有し、いくつかの個片は、関与するソフトウェアの実際の構造によってのみ制限される。したがって、断片化されるＩＰｖ６データグラムは、かなりの数の個片に上手く分けられ得る。元のＩＰｖ６データグラムのこれらの断片化された部分は、最終的な宛先によってのみ再構築される必要がある。断片化のＩＰｖ４実装形態では、データグラムは、パス全体について最小単位への断片化を必要とするのではなく、伝送を処理する能力を有さなかったネットワークの部分で提示されるときにのみ断片化された。この変更により、送信されるデータ全体に最大量の断片化が適用されることになり、それによって、データパス全体の短いセグメントのみに露出を制限するのではなく、可能な最大量の露出にパケット損失脆弱性の問題を拡大した。

[0026]たとえば、伝送が、その最終的な宛先に到達するために５０個のゲートウェイを通過する必要がある場合、ＩＰｖ６伝送は、ネットワークパスの５１個のセグメントすべてに収まるサイズに断片化されなければならない。しかしながら、ＩＰｖ４では、この断片化問題は、単に、制限を必要とした５１個のセグメントのうちのいずれかの問題であった。ＩＰｖ６は、ネットワークパス全体に断片化を強制するので、５１個のセグメント内のどこにおけるどのパケット損失でも、伝送全体に影響を及ぼす。

[0027]パケット損失が、より大きいＩＰｖ６データグラムの断片化された個片に生じるとき、このプロトコルは、単一の断片化された部分の損失を補正するために、ＩＰｖ６データグラム全体が再送信されることを必要とする。［ＲＦＣ２４６０］この再送信は、いくつかの事例において６０秒後に再構築の完了に失敗した後にのみ生じるので、有意の時間が、伝送プロセス全体で失われる。これは、データ再送信の増加を促し、そしてまた、ＩＰｖ６プロトコルを大規模システムの影響にさらす。送信されるデータの量が増えた一方で、送信される情報の実際のパケットのサイズ要件は増えなかった。さらに、ネットワーク内の輻輳が、単一のデータの損失を引き起こす場合、ストリーム全体への損傷を修復するために、データグラム全体が再送信されなければならない。この再送信は、ネットワーク内のトラフィックの非線形の拡張を引き起こし、それによって、追加のパケット損失およびその後の追加の再送信をもたらす。ＩＰｖ６は、必要とされるより多くのデータが再送信されることを必要とするので、この致命的挙動が、引き起こされる。

[0028]したがって、大規模なシステム影響を回避するために、中間ノードにおける断片化を限定するプロトコルのための断片化ルールを改善するニーズが先行技術に存在する。

[0029]ＩＰｖ６ネットワーク内の致命的なネットワーク輻輳障害を解消することによって有意の改善が獲得され得る。この改善は、ＩＰｖ６断片化情報の再送信を特定的に対処するプロセスを改善することによって、実装され得る。グリッドマップ（grid map）へのパケット損失を減らすことによって、およびデータグラム全体ではなくＩＰｖ６データグラムにおいて失われた断片のみを再送信することによって、輻輳が解消され得る。ＩＰｖ６の一実装形態では、データが移動する電気ネットワークによって伝送サイズが順守されることを可能にするために、データグラムが断片に分けられる必要があり得るが、パケット損失がこの断片化プロセスに関連して生じると、データグラム全体が再送信を必要とする。本方法は、失われたパケットのみが再送信されるようにし、適切に届いたが、失われたデータも含んでいたより大きいグループの一部に過ぎないデータは再送信されないことを可能にすることによって、このプロセスを改善する。

[0030]これらのおよび他の利点は、以下でさらに詳しく説明され示される本発明によって提供される。
[0031]前述のものに加えて、本発明の新たな特徴および利点は、同一参照文字が同一部分を指す、以下のような添付の図面と併せて、以下の詳細な説明を読むことで当業者には明らかとなろう。

[0032]本発明の例示的実施形態のステップを実行するために対話する２つのリモートホストを示す概略図である。 [0033]例示的ＴＣＰヘッダーを表す図である。 [0034]本発明による送信デーモンの例示的動作を示す図である。 [0035]第１の例示的シナリオにおける本発明による受信デーモンの例示的動作を示す図である。 [0036]第２の例示的シナリオにおける本発明による受信デーモンの例示的動作を示す図である。 [0037]第３の例示的シナリオにおける本発明による送信デーモンの例示的動作を示す図である。 [0038]本発明による受信デーモンの例示的動作を示す図である。 [0039]例示的なＩＰｖ６データグラムを示す図である。 [0040]例示的なＩＰｖ６断片化ヘッダーを示す図である。 [0041]例示的なＩＣＭＰｖ６ペイロードを示す図である。

[0042]本発明の例示的実施形態は、２つのリモートホスト間のデータ伝送中のパケット損失を処理し、データ転送の速度を不必要に遅くすることなくネットワーク輻輳の増大を回避し、それによって接続中のデータ伝送の全体的速度および効率を上げるためのシステムおよび方法を対象とする。本発明の例示的実施形態は、好ましくは、ネットワークホストのトランスポート層内に実装される。図１は、１つまたは複数のネットワークデバイス１０８で構成されたパケット交換ネットワーク１０６を介して互いに通信する、第１のリモートホスト１０２および第２のリモートホスト１０４の典型的な構成を示す。物理構成、経路指定プロトコルなどは、本明細書で開示される本発明の範囲を逸脱することなく様々な形および組合せをとり得ることと、本明細書に記載されたいずれの特定のネットワーク構成要素も制限として理解されるべきではなく、例示のみを目的として提供されることとが、当業者には理解されよう。

[0043]たとえば、図１に関して示される物理ハードウェア層および論理層の表現では、ネットワーク１０６は、ＷｉＦｉ受信器およびリピータ、ルーター、およびスイッチなど、１つまたは複数のネットワークデバイス１０８から成るローカルエリアネットワークにおいて、あるいはともに同様にネットワーク接続された複数の公衆またはプライベートネットワークにおいて、実施され得る。いくつかの実施形態では、ネットワークデバイス１０８とリモートホスト１０２および１０４とは、イーサネットハードウェア、ＷｉＦｉ／無線、および他の知られているまたは後に開発される物理データ伝送仕様を使用して、ホスト間でデータを移動することになる通信ルート１１０を確立し得る。本発明は主として、通信プロトコルのセットにおける伝送層を対象とするため、同じことが、それぞれ、ネットワーク１０６と第１のホスト１０２および第２のホスト１０４との間の接続１１２および１１４の可変性に関して概して当てはまる。したがって、データ伝送作業全体には重要であるが、物理伝送構成要素の特定の実施形態は、範囲の制限として考えられるべきではない。

[0044]１０２および１０４などのリモートホストで実装され得る通信プロトコル群の共通の抽象概念も、図１に概して示される。たとえば、ホストは、アプリケーション層１１６および１２４と、トランスポート層１１８および１２６と、インターネット層１２０および１２８と、リンク層１２２および１３０とを含み得る。広く実装されるＴＣＰ／ＩＰ群およびその変形形態において、ヘッダーは、ホストのトランスポート層デーモン自体と他のネットワークホストとの間のデータ伝送を適切に円滑化するために、ホストのトランスポート層デーモンによって構築および解析される。典型的なＴＣＰヘッダー１４０が図２に示される。たとえば、シーケンス番号フィールド１４２は、送信される個々のセグメントの１番目のデータバイトの最初のまたは累積シーケンス番号を指示するために、送信デーモンによって使用され、受信確認番号フィールド１４４は、受信デーモンが期待する次の期待されるシーケンス番号を指示するために、受信デーモンによって使用され、ウィンドウフィールド１４６は、受信デーモンの受信ウィンドウの現在のサイズを定義するために使用される。以下でさらに詳しく説明されるように、一実施形態では、失われたまたは遅れたパケットによるデータ再送信のために使用されるビットマップは、オプションフィールド１４８に含まれる。

[0045]次に図３を見ると、リモートホスト内の送信デーモンのトランスポート層内（たとえば、図１に示された第１のリモートホスト１０２のトランスポート層１１８内）の伝送バッファー１５０の描写が示される。本明細書では、例示を目的として図１に関して示されたようなネットワークホストの例示的システムの対応する要素も、参照される。点線の輪郭は、再送信ウィンドウ１５２の位置を表し、この位置は、第２のリモートホストの受信デーモンが受信確認を待つ前に、どのくらいの量のデータが次の通信層に（たとえば、矢印１５４を介してインターネット層１２０に）そして最終的に第２のリモートホスト１０４のトランスポート層１２６に送られることになるかを決定する。アプリケーション層１１６からのデータストリームは、たとえば、開いたセッションの間にバッファリングされた伝送データストリームを維持するために、矢印１５６を介して送信デーモンのバッファー１５０に受信される。

[0046]示されたこの条件の下で、本発明によれば、ウィンドウ１５２における１０個のデータセグメントを表す１０ビットを有するビットマップが、各セグメントのＴＣＰヘッダーに添付される。簡潔にするために、これらの１０個のＴＣＰデータセグメントは、シーケンス番号１～１０を有して示される。ビットマップの１つの例示的実施形態では、アクティブビットは、受信確認されていないセグメントを表すために使用され、非アクティブビットは、受信確認されたセグメントを表すために使用される。別の例示的実施形態では、非アクティブビットは、受信確認されていないセグメントを表すために使用され、アクティブビットは、受信確認されたセグメントを表すために使用される。以下の開示は、前者を使用する例示的実施形態を参照するが、いずれの方法も、本発明の範囲を逸脱することなく使用され得ること、また、そのようなバイナリービットは概して、２つの値、すなわち、オンおよびオフ、アクティブおよび非アクティブ、デフォルトおよび受信されたものなどを有すると言えることが、当業者には理解されよう。一般に、ビットマップ内で運ばれる位置中心情報は、受信デーモンでアドバタイズされたウィンドウの位置と組み合わされて、送信デーモンの再送信ウィンドウ内でのセグメントの正確な受信確認を可能にする。送信デーモンは、受信デーモンによって受信確認されていない特定のセグメントのみを再送信するようになされ得、それによって、資源の無駄およびさらに悪化するネットワーク輻輳を減らすので、この特徴は有益である。

[0047]図４は、第２のリモートホスト１０４のトランスポート層１２６の受信デーモンの例示的条件を表す。受信デーモンの例示的実施形態は、一般に、下位通信層から（たとえば、インターネット層１２８から）矢印１６２を介してデータを受け付け、アプリケーション層に矢印１６４を介して、順序付けけられたデータを送信する、受信バッファー１６０を含むことになる。陰影を付けていないセグメント１６６は、リモートホスト１０４でアドバタイズされたウィンドウ１６８において受信されなかったセグメントを表す。このシナリオでは、受信デーモンは、送信デーモンによって送られたセグメント１および７～９を受信しておらず、したがって、第１、第７、第８、および第９のビットをアクティブにし、第２、第３、第４、第５、第６、および第１０のビットを非アクティブにしたビットマップを有する、１つまたは複数の受信確認を送ることになった。送信デーモンは、次いで、受信されたビットマップにおいて非アクティブビットに対応する、自身の再送信ウィンドウ１５２内の４つのセグメント（すなわち、１および７～９）、したがって、受信デーモンによって受信されなかったセグメントを再送信することになる。いくつかの実施形態では、再送信される各セグメントは、伝送時に受信デーモンから直前に受信された受信確認ビットマップをミラーリングするビットマップを含む。

[0048]図５には、第２の例示的条件が示され、ここでは、４つの欠落したまたは遅れたセグメントの再送信が、説明されたように行われており、第７、第８、および第９のセグメント７～９が、２回目の試行で受信デーモンによって受信された。第１のセグメントが再び失われた。受信デーモンは、受信確認ビットマップ中で第１のビットのみをアクティブにして送信デーモンに受信確認を送る。送信デーモンは、次いで、２度目に第１のセグメントを再送信し、それは受信デーモンによって受信され、受信確認され得る。

[0049]すべてのセグメントが、所与のウィンドウ位置のビットマップについて受信確認されると、第１のリモートホスト１０２の送信デーモンは、そのウィンドウ１５２をスライドして、第１１から第２０のセグメント内のデータストリームの部分を包含するようにする。この例示的条件は、図６に関して示される。１０ビットを有する新しい伝送ビットマップが構築され、それらのセグメントのＴＣＰヘッダーに添付され、その後、それらのセグメントは、第２のリモートホスト１０４の受信デーモンに送信される。図７に、受信デーモンのその後の例示的条件が示され、そこでは、空のセグメント位置１６７によって示されるように、第１１、第１４、および第１９のビットが、失われたかまたは遅れた。受信デーモンは、第１、第４、および第９のビットがアクティブである受信確認ビットマップを構築し、送信デーモンへの受信確認にそのビットマップを含め、このプロセスが繰り返される。

[0050]ＩＰｖ６プロトコルに固有のアドレス空間フィールドの有意に増やされたサイズを補償するために、主要ＩＰｖ６ヘッダーは、前のＩＰｖ４実装形態に対して大幅に簡略化された。図８は、典型的なＩＰｖ６データグラム１７０およびヘッダー１７１を示す。ＩＰｖ６ヘッダー１７１は、１２８ビットのソースアドレス１７２および宛先アドレス１７４と、ペイロード長１７６と、ＩＰｖ６ヘッダー１７１に続くペイロード１８０の先頭でデータグラムに添付された拡張ヘッダーにあるオプションのヘッダー情報の存在を指示するために使用される「次のヘッダー」フィールド１７８とを含む。１８０として図８に示されるように、任意の拡張ヘッダーを含む、ＩＰｖ６データグラムの実際の可変サイズのデータペイロードが、ＩＰｖ６ヘッダー１７１に添付される。

[0051]本開示に特に関連する１つのそのような拡張ヘッダーは、図９に関して示された例示的実施形態に示されるような、断片化ヘッダー１９０である。ＩＰｖ６プロトコルによれば、断片化は、元のデータグラムを断片化不可能な部分と断片化可能な部分とに分けることによって行われる。断片化可能な部分は、伝送経路内の中間ノードによって処理されず、代わりに、宛先ノードでのみ処理される。データグラムの断片化不可能な部分は、ＩＰｖ６ヘッダー、および、存在する場合には、断片化可能な部分に先行すべきいくつかのオプションの拡張ヘッダーを含む。

[0052]通常は、断片化可能な部分は、宛先ノードに再構築情報を提供する断片化ヘッダー１９０を含むことになる。ソースノードのみが、ペイロードを断片化し得る。断片化ヘッダー１９０に加えて、断片化可能な部分は、他のオプションの拡張ヘッダーと、元のペイロードの一部とを含み得る。断片化ヘッダー１９０は、通常は、元のデータグラムを識別する３２ビットの識別フィールド１９２を含むことになる。すなわち、断片化されたＩＰｖ６データグラムのすべての断片は、宛先ノードでの再構築時にそれらを互いに一致させるために、同一の識別値を運ぶことになる。宛先ノードは、１３ビットの断片オフセットフィールド１９４を使用して、シーケンス内のどこで、特定の断片が、元のペイロードにあったデータの最初のビットを含む第１の断片に対応する「０」に属し、それに設定されるかを決定する。追加の断片フィールド１９６は、データグラムの最後の断片が０に設定され、その断片が元のデータグラムペイロードの「最後」を運ぶことを意味する、バイナリーフィールドとして説明される。他のすべての断片では、追加の断片が期待されるべきことを宛先ノードに伝えるために、このフィールドが１に設定される。

[0053]インターネット制御メッセージプロトコルバージョン６（ＩＣＭＰｖ６）は、ＩＰｖ６のインターネット制御メッセージプロトコル（ＩＣＭＰ）の実装形態である。［ＲＦＣ４４４３］ＩＣＭＰｖ６は、ＩＰｖ６の不可欠な一部であり、エラー報告および診断機能を実行する。それは、たとえば、伝送中のＩＰｖ６データグラムの損失を伝えるために、宛先ノードによって使用される。宛先ノードが、タイムアウト条件が達せられたと判定すると、ＩＰｖ６プロトコルは、断片化されたＩＰｖ６データグラムの再構築状態を終了すること、および断片が破棄されることを必要とする。宛先ノードは、次いで、ＩＣＭＰｖ６エラーメッセージをソースノードに送信し、元のＩＰｖ６データグラム全体の再送信を実質的に要求する。

[0054]このプロセスのために使用されるＩＣＭＰｖ６パケット２００が、図１０に関して示される。通常は、これらのパケット２００は、ＩＰｖ６ヘッダー１７０に添付されたペイロード１８０であり、タイプフィールド２０２、コードフィールド２０４、およびチェックサムフィールド２０６を有するヘッダーを含むことになる。プロトコルペイロードは、メッセージ本文２０８に含まれる。タイプフィールド２０２およびコードフィールド２０４は、ＩＰｖ６プロトコルを介して通信するソースノードと宛先ノードの間で送信され得る様々なエラーおよび情報のメッセージを表す、８ビットのフィールドである。たとえば、３のタイプおよび１のコードを有するＩＣＭＰｖ６パケットが、宛先の断片化時間が超過されたことをソースに指示するために送られ得、その結果、送信が成功した断片がいずれも破棄され、それにより、元のＩＰｖ６データグラム全体の再送信をトリガーする。

[0055]本発明の１つの例示的実施形態では、新しい予約されていないコードが、中間再送信エラー状態に割り当てられる。たとえば、宛先ノードは、「３」に設定されたタイプフィールド２０２と、割り当てられていない値（たとえば「２」）に設定されたコードフィールド２０４と、送信される断片化データグラム内の分散した断片のうちどれがまだ受信されていないかを指示するビットマップを含むメッセージ本文２０８と、を有するＩＣＭＰｖ６部分的再送信要求パケットを送信することによって、任意の受信されていないデータグラム断片の再送信を実質的に要求するように構成される。受信すると、送信デーモンは、次いで、部分的な再送信要求パケットによって運ばれたビットマップ内で指示されるデータグラム断片のみを再送信することになる。

[0056]いくつかの実施形態では、宛先ノードは、タイムアウト条件が達せられたときに基本ＩＰｖ６プロトコルに従って宛先ＩＰデーモンにすべての断片を破棄させる第１の再構築タイマーをインクリメントすることができる。第１の再構築タイマーに加えて、宛先ノードは、第１の再構築タイマーに従ってインクリメントされるとともに、タイムアウト条件が第１の再構築タイマーによって達せられる前に１回または複数回にわたり適宜に部分的再送信要求パケットの作成および伝送をトリガーする、第２の再構築タイマーを含み得る。

[0057]ＩＰｖ６プロトコルのほとんどの実装形態は、存在する場合は末尾の最終断片に含まれる剰余を除いて、所与の元のペイロードのすべてのペイロード断片サイズは同じ数の８バイトグループで割り切れるという意味で規則的な方法で、ＩＰｖ６データグラムを断片化することになる。これらの状況では、単純なビットマップが、宛先デーモンによって、ペイロード長１７６、断片オフセット１９４、および、場合によりオプションで追加の断片１９６フィールドから容易に構築され得る。いくつかの例示的実施形態では、ビットマップは、別法として、宛先デーモンによって受信される元のペイロード内に存在する不連続性を指示する断片オフセットのリストまたは配列として表され得る。

[0058]ＩＣＭＰエラーメッセージにデータ個片ビットマップを追加し、最大再構築時間制限に達する前にそのメッセージを送信することにより、ＩＰｖ６は、大きく総体的な規模で機能するだけでなく、遥かに粒度の細かいレベルまでデータフローを統制する能力を有することになることが、当業者には理解されよう。

[0059]本発明のある種の態様は、本明細書では方法の形で説明されるプロセスステップおよび命令を含む。本発明のプロセスステップおよび命令は、ソフトウェア、ファームウェアまたはハードウェアにおいて実施することができ、ネットワーク対応ホストへの本発明の適用は、それによって制限されるべきではないことに留意されたい。

[0060]本発明の任意の実施形態は、本発明のその他の実施形態のオプションのまたは好ましい特徴のいずれをも含み得る。本明細書で開示される例示的実施形態は、包括的であることまたは本発明の範囲を不必要に制限することを意図されていない。例示的実施形態は、他の当業者が本発明を実施し得るように本発明の原理のいくつかを説明するために選択および説明された。本発明の例示的実施形態を示し、説明して、多数の変更および修正が、記載された発明に行われ得ることが、当業者には理解されよう。それらの変更および修正の多くは、同じ結果を実現することになり、特許請求されている本発明の趣旨内にある。したがって、ただ特許請求の範囲によって示されるようにのみ本発明を制限することが意図される。

１０２ 第１のリモートホスト
１０４ 第２のリモートホスト
１０６ パケット交換ネットワーク
１０８ ネットワークデバイス
１１０ 通信ルート
１１２ 接続
１１４ 接続
１１６ アプリケーション層
１１８ トランスポート層
１２０ インターネット層
１２２ リンク層
１２４ アプリケーション層
１２６ トランスポート層
１２８ インターネット層
１３０ リンク層
１４０ ＴＣＰヘッダー
１４２ シーケンス番号フィールド
１４４ 受信確認番号フィールド
１４６ ウィンドウフィールド
１４８ オプションフィールド
１５０ 伝送バッファー
１５２ 再送信ウィンドウ
１６０ 受信バッファー
１６６ セグメント
１６７ 空のセグメント位置
１６８ アドバタイズされたウィンドウ
１７０ ＩＰｖ６データグラム
１７１ ヘッダー
１７２ １２８ビットソースアドレス
１７４ 宛先アドレス
１７６ ペイロード長
１７８ 次のヘッダーフィールド
１８０ ペイロード
１９０ 断片化ヘッダー
１９２ ３２ビット識別フィールド
１９４ 断片オフセットフィールド
１９６ 追加の断片フィールド
２００ パケット
２０２ タイプフィールド
２０４ コードフィールド
２０６ チェックサムフィールド
２０８ メッセージ本文

Claims (2)

1. パケット交換ネットワークにおける輻輳回避の方法であって、
   断片化されたデータグラムの１つまたは複数の受信された断片を宛先ホストで受信するステップであって、前記断片化されたデータグラムは、前記１つまたは複数の受信された断片および１つまたは複数の失われた断片を含む合計数の断片に断片化された、ステップと、
   前記断片化されたデータグラムを識別する識別値、および、
   前記１つまたは複数の失われた断片を識別するビットマップ
   を備える断片化データ損失エラーメッセージを構築するステップであって、前記断片化されたデータグラムは、複数のビットを含むビットマップで表され、前記ビットマップにおいて、アクティブビットは受信確認されていないデータグラムを表し、非アクティブビットは受信確認されているデータグラムを表す、構築するステップと、
   前記断片化データ損失エラーメッセージをソースホストに送信するステップと、
   前記ソースホストにおいて、前記断片化データ損失エラーメッセージから、前記アクティブビットに対応する前記少なくとも１つの失われた断片を識別するステップと、
   前記ソースホストから前記宛先ホストへ、前記断片化されたデータグラムの識別された前記１つまたは複数の失われた断片のみと、前記断片化データ損失エラーメッセージの前記ビットマップをミラーリングする再送信ビットマップとを備える、限定再送を送信するステップであって、前記再送信ビットマップのアクティブビットは前記限定再送の前記１つまたは複数の識別された失われた断片を表し、前記再送信ビットマップの非アクティブビットは前記受信確認されているデータグラムを表す、送信するステップと
   を含む、方法。
2. パケット交換ネットワークにおける輻輳回避の方法であって、
   宛先ホストで伝送タイマーを初期化するステップと、
   断片化されたデータグラムの最初の受信された断片を前記宛先ホストで受信するステップと、
   前記最初の受信された断片を受信したときに前記伝送タイマーを始動するステップと、
   断片化されたデータグラムの少なくとも１つの受信された断片を前記宛先ホストで受信するステップであって、前記少なくとも１つの受信された断片が、前記最初の受信された断片を含み、前記断片化されたデータグラムが、前記少なくとも１つの受信された断片および少なくとも１つの失われた断片を含む合計数の断片に断片化された、ステップと、
   前記伝送タイマーで伝送時間をインクリメントするステップと、
   インクリメントした前記伝送時間が、伝送タイムアウト時間よりも短い場合に、
   前記断片化されたデータグラムを識別する識別値、および、
   前記少なくとも１つの失われた断片を識別するビットマップ
   を備える断片化データ損失エラーメッセージを構築するステップであって、前記断片化されたデータグラムは、複数のビットを備える前記ビットマップで表され、前記ビットマップにおいて、アクティブビットは受信確認されていないデータグラムを表し、非アクティブビットは受信確認されているデータグラムを表す、構築するステップと、
   前記断片化データ損失エラーメッセージをソースホストに送信するステップと、
   前記ソースホストにおいて、前記断片化データ損失エラーメッセージから、前記アクティブビットに対応する前記少なくとも１つの失われた断片を識別するステップと、
   前記ソースホストから前記宛先ホストへ前記断片化されたデータグラムの識別された前記少なくとも１つの失われた断片のみと、前記断片化データ損失エラーメッセージの前記ビットマップをミラーリングする再送信ビットマップとを備える、限定再送を送信するステップであって、前記再送信ビットマップのアクティブビットは前記限定再送の前記識別された前記少なくとも１つの失われた断片を表し、前記再送信ビットマップの非アクティブビットは前記受信確認されているデータグラムを表す、送信するステップと、
   前記断片化されたデータグラムの全ての断片が、前記伝送タイムアウト時間の前に受信されるように、前記宛先ホストにおいて前記識別された少なくとも１つの失われた断片を受信するステップと、
   を含む、方法。

Images