JP2007527170A - 並列通信のためのシステムおよび方法 - Google Patents

Abstract

複数の並列通信経路上でのデータの通信のためのシステムおよび方法が提供される。該並列通信システムと方法の実施形態は、ネットワークアプリケーションに所望される通信目的および性能のレベルを与えるために多様なネットワークエレメント内の多数のリソースを発見してよく、特徴付けてよく、または利用してよい。該システムおよび方法は、該所望される通信性能を連続的に提供するために該ネットワークリソースでの変化に動的に適応してよい。

Description

本発明は概してデータ通信のためのシステムおよび方法に関し、さらに詳細には複数の並列データ通信経路上でのデータの通信のためのシステムおよび方法に関する。

インターネット等のパケットベースのデータネットワークが将来果たすと想像されている極めて重要な役割を考えて、よりよく、より安く、そしてより速く動作するために膨大な量の研究がこれらのネットワークに向けられてきた。しかしながら、大部分のネットワークの膨大なリソースにも関わらず、大多数は２つのネットワーク間でデータをシーケンシャルに通信する。例えば、幅広く使用されているインターネットプロトコル（ＩＰ）はあらゆる２つのエンティティ間のシングルパスルーティングのみをサポートする。

したがって、一般的にはパケットデータネットワーク、および特にインターネットは、シーケンシャルデータ通信特性に勝ることによって性能、コスト、機能性および柔軟性の改善を潜在的に可能にする固有の特徴を有する。すなわち、データ通信を並列化することにより、多くのパケットデータネットワークの機能性の根本的な改善がもたらされている。

並列データ通信の形式が試みられてきたが、概して多くの欠陥に遭遇している。例えば、単純な集約演算、リンクバンドリング、およびチャネルボンディング等の並列データ通信システムの形式は暗に同質のネットワークリソースがうまく機能することを必要とする。したがって、これらの技術は、一般的には集められたリソースに一貫性があり、予測可能な性能特徴を提供すると仮定している。したがって受信端での適切なバッファリングにより複数のリソース上でデータを分割する単純なレバレッジ導入方式では動的ネットワーク環境で効果的な集約演算を達成できない。ネットワークの同質性および／または一貫性が存在しないとき、利用されている単純化した戦略は所望される性能をもたらさない可能性がある。

特許文献１は、単純な集約演算の１つの変形物を使用する通信システムを開示している。具体的には、特許文献１は単一の高帯域通信チャネルをエミュレートするために複数の並列通信チャネルを結合するためのシステムを目的としている。パケットの連続ストリームは、トラフィックが集まるにつれグループ化され、複数の並列通信チャネルと関連付けられた待ち行列に割り当てられる。トラフィックの集合体の待ち行列への割り当ておよび再割り当ては、並列通信チャネルの各々について待ち行列の長さに関連する待ち行列負荷比率を計算することに基づいて動的に実行される。トラフィックが集まるにつれ、既存のパケットおよび将来のパケットのグループ化は共通ソースアドレスと宛先ＩＰアドレス等のパケットにより共用される共通の属性に基づいている。

しかしながら、他の集約演算技法のように、特許文献１のシステムも多くの欠陥に遭遇している。例えば、パケットは受信端で再構築されるために、集約演算の性能は最低性能の経路に左右されている。

最低の経路性能の欠陥の例は、第１の経路が第２の経路より大きい帯域幅を有する２つの経路を有する単純な集約演算システムを用いて例示されてよい。１０個のパケットの内の８個が第１の経路に沿って配信され、１ｍｓの内に宛先に達する。通信全体が受信されていないため、これらの８個のパケットは残りの２個のパケットが到達するまで受信機でバッファに格納される。該残りの２個のパケットは第２の経路に沿って配信されるが、該残りの２個のパケットが宛先に到達するには５００ｍｓを要する。したがって、少なくとも５００ｍｓの場合、宛先は通信全体を利用できない。したがって、いくつかの場合、特に経路が類似のネットワーク特徴を有さない状況では、単純な集約演算は総合的なネットワーク性能を改善しない。

さらに、簡略な集約演算システムは、一般的には通信経路に沿って変化するネットワーク状態を適切に処理することを目的としておらず、既存のネットワーク内でシームレスに動作しない可能性がある。

したがって、必要とされることは、（個々のネットワークリソースの性能特徴の多様性を有する、あるいは有しない）同質または異質の双方のネットワークエレメントを使って作業できる、変化するネットワーク環境に適応することができる、既存のネットワークに対するオーバレイとして配備でき、利点を実現するためにネットワークアプリケーションの変更を必要としない並列通信システムである。
米国特許第６，６２５，１６１号明細書

複数の並列通信経路上でのデータの通信のためのシステムおよび方法が提供されている。

並列データ経路上でデータを通信するための方法の実施形態は、経路特性を繰り返し決定することにより複数の並列データ経路の各々を特徴付けることを含み、該複数の並列データ経路が送信側ノードと受信側ノード間の単一の仮想接続を形成し、目的関数を満たすために複数の並列データ経路全体でのデータの送信のスケジューリングを行い、該スケジューリングは該経路特性に基づいている。

並列データ経路上でデータを通信するためのシステムの１つの実施形態は、命令実行システムからの命令をフェッチし、実行するように構成されるプロセッサを含む。該実行可能な命令は、経路特性を繰り返し決定することにより複数の並列データ経路の各々を特徴付け、該複数の並列データ経路が送信側ノードと受信側ノード間の単一の仮想接続を形成してよい。該命令は目的関数を満たすために該複数の並列データ全体でデータの送信のスケジューリングを行うための命令をさらに含んでよく、該スケジューリングは該経路特性に基づいている。

データの送信のスケジューリングを行うための命令は、宛先で受信される複数の並列データ通信経路の最終的な経路に沿ってデータの第１の送信のスケジューリングを行うための命令と、該複数の並列データ通信経路の第２の経路に沿ってデータの第２の送信のスケジューリングを行うための命令とをさらに含んでよく、データの該第２の送信は第１のパケットに関して所定の順序で、受信側ノードで受信されるようにスケジューリングされている。

並列データ経路上でデータを通信するためのシステムの別の例示的な実施形態は、経路特性を繰り返し決定することによって、送信側ノードと受信側ノードとの間に単一の仮想接続を規定する複数の並列データ経路の各々を特徴付けるための手段と、目的関数を満たすために該複数の並列データ経路全体でデータの送信のスケジューリングを行うための手段とを含み、該スケジューリングは経路特性に基づいている。

他のシステム、方法、特徴および／または優位性は、添付図面および詳細な説明を検討することで当業者に明らかになるであろう。または明らかになる場合がある。すべてのこのような追加のシステム、方法、特徴、および／または優位性は本発明の中に含まれ、添付請求項によって保護されることが意図される。

図面中の構成要素は必ずしも互いに関して縮尺どおりではない。同様の参照番号は複数の図全体で対応するパーツを示す。

複数の並列通信経路上でのデータの通信のためのシステムおよび方法が開示されている。並列通信システムおよび方法は、ネットワークアプリケーションに求められる通信の目的および性能のレベルを提供するために通信システムの多様なネットワークエレメント内で多数のリソースを発見し、特徴付け、そして利用してよい。該システムおよび方法は所望される通信性能を連続的に提供するためにネットワークリソースの変化に動的に適応してよい。

システムおよび方法は、国際標準化機構の開放型システム間相互接続（ＩＳＯ／ＯＳＩ）の７つのネットワーク層のいずれかの上でまたは間で実現されてよいが、並列通信システムの一実施形態は多数のネットワークリソースを利用するためにＩＰトラフィック上で動作する第４層（トランスポート）プロトコル技術として実現されている。

図１は、例示的な並列通信システム２０を描いている。並列通信システム２０を通って通信されるデータはデータパケットの中でカプセル化されていると呼ばれる場合がある。しかしながら、データは特定の形式を取る必要はなく、代わりに例えばセグメント、フレーム、バイト、またはビットの形を採ってよい。

並列通信システム２０の一実施形態は、送信機並列通信トランシーバ２２と、受信機並列通信トランシーバ２４とを含んでよい。並列通信トランシーバ２２と２４の各々は、その上で多数が利用されなければならないネットワーク２６のセクションのいずれかの側に配備されてよい、ルータと無関係なスタンドアロン装置内に常駐してよい。

ネットワーク２６は、例えばローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）またはインターネットであってよい。図１の中で中黒円として描かれているレガシーネットワークノード２８は、例えばルータ等の既存のネットワーク化された演算装置であってよい。いくつかの実施形態では、レガシーネットワークノード２８は並列通信トランシーバ２２と２４に特定の知能を提供するように修正されてよい。しかしながら、一般的にはレガシーネットワークノード２８はシステムで使用するために修正を必要としない。したがって、ネットワーク２６内の既存のインフラストラクチャに対する変更は必要とされていない。

図１に描かれている実施形態は、各々接続３４と３６を通して並列通信トランシーバ２２と通信するソース演算装置３０と宛先演算装置３２を描いている。ソース演算装置３０と宛先演算装置３２は総称的に通信エンドポイントと呼ばれる場合があり、多数のネットワーク２６を活用するために並列通信トランシーバ２２と２４を使用してよい任意の数の演算装置を表す。接続３４と３６は任意の数の有線接続または無線接続を表してよく、多くの他のネットワーク化された通信装置も含んでよい１つ以上のネットワークを表してよい。

本例では、送信機並列通信トランシーバ２２は、ソース演算装置３０から発信されるデータパケットを、ネットワーク２６を横切って受信機並列通信トランシーバ２４に送信する役割を担う。受信機並列通信トランシーバ２４は送信機並列通信トランシーバ２２によって送信されたパケットを受信し、それらを宛先演算装置３２に転送する役割を担う。トランシーバ２２と２４は各々送信機および受信機と呼ばれているが、各トランシーバは並列通信データの送信機と受信機の両方として同等に動作するように構成されてよいことが理解されなければならない。しかしながら、簡単にするために、例１の具体的な例は、ネットワーク２６を横切る単一方向（左から右へ）のデータパケットの転送を描き、反対方向（右から左へ）の肯定応答（ＡＣＫ）パケットの転送を描いている。したがって、いくつかの実施形態では、データパケットと肯定応答パケットはネットワーク３６を横切る反対方向で送信されてよく、トランシーバ２４が送信機の機能を果たし、トランシーバ２２が受信機の機能を果たす。

さらに明確にするために、並列通信トランシーバ、接続およびエンドポイントが２セットだけ描かれている。しかしながら、任意の数の通信トランシーバが関連通信エンドポイントのためにネットワーク２６を活用する目的でネットワーク２６に接続されてよい。

ソース演算装置３０と宛先演算装置３２は、装置間でパケットデータを転送するためにネットワーク２６を使用する多くのアプリケーションを含んでよい。例えば、ソース演算装置３０は宛先演算装置３２上のクライアントアプリケーションにデータを送信するためのサーバアプリケーションを含んでよい。レガシーネットワークノード２８と同様に、ソース演算装置３２と宛先演算装置３４に関連するアプリケーション（複数の場合がある）は、並列通信トランシーバ２２と２４に気付いておらず、設計または動作で変更を必要としない可能性がある。

接続は、パケットが宛先にどのようにして到達するのかに関係なく２つのネットワークエンティティ間のエンドツーエンド通信リンクとして説明されてよい。例えば、接続３８は並列通信トランシーバ２２と２４間のエンドツーエンド通信リンクを表す。実際には、接続はエンドツーエンドリンクを形成する多くの経路を表してよいため、接続はここで「仮想」接続と呼ばれる場合がある。

したがって、経路は、データパケットが２つのエンティティの間（つまり仮想接続上で）で移動してよい多くのルートの内の１つを記述してよい。例えば経路４０（実線）はデータパケットが接続３８に沿って移動する第１の経路を表す。同様に、経路４２（点線）と経路４４（破線）は、データパケットが接続３８に沿って移動してよい第２の経路と第３の経路を表す。経路４０、４２、および４４は、それらが、パケットデータが同時にネットワーク２６を通って伝播するための３つの別のルートを表すことができる点で並列経路と呼ばれる場合がある。図１には３つの経路だけしか描かれていないが、パケットが接続上で移動してよい任意の数のノードによって形成される多くの経路があってよい。さらに、経路は単一のポイントツーポイントリンクを備えてよく、単一の物理接続上で複数の仮想回線を含んでよい。いくつかの実施形態では、仮想回線は例えばポート番号またはマルチプルプロトコルラベルスイッチング（ＭＰＬＳ）ラベルを通してアドレス指定されてよい。

並列通信トランシーバ２２と２４は、１つ以上の目的関数各々のためのサービスのレベルをエンドポイントに提供するために並列経路を利用するように構成される。例示的な目的関数は帯域幅、遅延、ジッタ、損失率、セキュリティ、障害許容力、およびコストの尺度であってよい。サービスのレベルは所望される量の帯域幅、つまり許容遅延、ジッタ、損失率、セキュリティ、障害許容力、またはコストを指してよいが、これらに限定されない。

例えば、所望される量の帯域幅は、いったん並列で結合されると該所望される帯域幅を有する経路を求め、集めることによって対処されてよい。対照的に、さらに少ない帯域幅を必要としてよいアプリケーションもあるが、遅延とジッタの性能の改善を必要とする。例えばボイスオーバーインターネットプロトコル（ＶｏＩＰ）は主に１００Ｋｂｐｓ未満の帯域幅を有する接続を必要とするが、遅延、ジッタおよびデータ損失のさらに厳しい制御を必要とする。さらに、高価な３Ｇデータ経路と安価な８０２．１１データ経路がＶｏＩＰ呼に役立つ場合には、コストの最小化が優先されてよい。したがって、目的関数は、所望されるサービスのレベルを満たし、次に、選択された経路全体でのデータパケットの送信のスケジュールを適切に決めるために最も好ましい特徴を有する多くの並列経路を選択する並列通信トランシーバ２２と２４によって対処されてよい。

図２は、並列通信システムおよび方法を実現するために送信機並列通信トランシーバ２２内で実行されてよい並列通信トランシーバ４６の実施形態のアーキテクチャのブロック図を描いている。ここでは描かれていないが、受信機並列通信トランシーバ２４は同じアーキテクチャ、または類似のアーキテクチャを使用してよい。

一般的には、並列通信トランシーバ２２は、ラップトップコンピュータ、ＰＤＡ、ハンドヘルドコンピュータ、またはペンベースコンピュータ、デスクトップコンピュータ、専用サーバコンピュータ、マルチプロセッサ演算装置、内蔵機器、ルータ、ネットワーキング装置等の種々の有線演算装置および／または無線演算装置の内の１つを備えてよい。その特殊な配列に関係なく、並列通信トランシーバは、例えばディスプレイ、メモリ、大量記憶装置、ネットワークインタフェース,処理装置および入力インタフェース／出力インタフェースを接続してよいバスを備える。

関連する処理装置は、並列通信トランシーバ、（マイクロチップの形を取る）半導体ベースのマルチプロセッサ、マクロプロセッサ、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、複数の適切に構成されたデジタル論理ゲート、およびコンピューティングシステムの総合的な動作を調整するために個々にまたは多様な組み合わせによる場合の両方で個別のエレメントを備える他の周知の電気的構成の中に、任意のカスタムメイドのまたは市販のプロセッサ、中央演算処理装置（ＣＰＵ）または補助プロセッサを含むこともできる。

入力／出力インタフェースは、データの入力と出力に任意の数のインタフェースを提供する。例えばこれらの構成要素は、キーボードまたはマウス、ボタン、タッチセンシティブスクリーン、スタイリスト等であってよいユーザ入力装置と接続してよい。ディスプレイは、例えばコンピュータモニタまたはＰＣ用プラズマスクリーン、またはハンドヘルドデバイス上の液晶ディスプレイ（ＬＣＤ）を備えることができる。

メモリは、揮発性メモリエレメント（例えば、（ＤＲＡＭ等のＲＡＭおよびＳＲＡＭ等）ランダムアクセスメモリ等）と不揮発性メモリエレメント（例えば、ＲＯＭ、ハードドライブ、テープ、ＣＤＲＯＭ等）のいずれか１つを含むことができる。メモリはネイティブオペレーティングシステム、１つ以上のネイティブアプリケーション、エミュレーションシステム、または種々のオペレーティングシステムおよび／またはエミュレートされたハードウェアプラットホーム、エミュレートされたオペレーティングシステム等のエミュレートされたアプリケーションも備えてよい。

説明されたモジュール、およびサブモジュールの各々は、論理関数を実現するための実行可能な命令の順序付けられたリスティングを備えてよい。実行可能なモジュールがソフトウェアで実現されるとき、システムが任意のコンピュータ関連システムまたは方法による、あるいは任意のコンピュータ関連システムと関連して使用するために任意のコンピュータ読取可能媒体に記憶できることに留意しておかなければならない。本書の文脈では、コンピュータ読取可能媒体は、コンピュータ関連のシステムまたは方法によって、またはコンピュータ関連のシステムまたは方法と組み合わせて使用するためにコンピュータプログラムを含むまたは記憶することができる電子、磁気、光学または他の物理的なデバイスまたは装置である。実行可能なモジュールは、コンピュータベースのシステム、プロセッサを具備するシステム、あるいは命令実行システム、装置またはデバイスから命令をフェッチし、命令を実行できる他のシステム等の命令実行システム、装置またはデバイスによって、または命令実行システム、装置またはデバイスと組み合わせて使用するための任意のコンピュータ読取可能媒体で具現化できる。

この文書の文脈では、「コンピュータ読取可能媒体」は、基本的には、命令実行システム、装置またはデバイスによって、または命令実行システム、装置またはデバイスと関連して使用するためのプログラムを記憶、通信、伝播またはトランスポートを行うもののいずれかとすることができる。コンピュータ読取可能媒体は、例えば、電子、磁気、光学、電磁、赤外線または半導体のシステム、装置、デバイスまたは伝播媒体とする場合があるが、これらに限定されない。コンピュータ読取可能媒体のさらなる具体例（網羅的ではないリスト）は以下を含むことになる。つまり１本または複数のワイヤを有する電気的接続（電子）、携帯コンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（電子）、読み取り専用メモリ（ＲＯＭ）（電子）、消去可能ＰＲＯＭ（ＥＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュメモリ）（電子）、光ファイバ（光学）およびデジタル多用途ディスク（ＤＶＤ）またはコンパクトディスク読み取り専用メモリ（ＣＤＲＯＭ）等の光学媒体である。コンピュータ読取可能媒体は、紙または別の適切な媒体であり、プログラムが紙または他の媒体のオプティカルスキャニングを介して電子的に捕捉されると、その上でプログラムが印字され、次にコンパイルされ、翻訳される、あるいはそれ以外の場合必要な場合に適切な方法で処理され、それからコンピュータメモリに記憶される場合さえもあることに注意する。

並列通信モジュール４６は２つの主要なサブモジュール、つまりコアエンジン４８と経路エンジン５０を含んでよい。コアエンジン４８はおもに接続ごとの機能性に関与し、経路エンジン５０はおもに経路ごとの機能性と状態に関与する。これらのモジュールの２分法が、経路と接続の機能性を区別しない既存の技術に優る１つの潜在的な優位性を生じさせるために役立つ。

機能性はシステムにより利用される「動作」または「アルゴリズム」を指すが、このような動作またはアルゴリズムはここでは「状態」と呼ばれる場合があるデータ構造に作用し、維持してよい。したがって、複数の接続の状態が単一の接続のために作成されてよい。同様に、輻輳制御等の経路レベルで維持される機能性の場合、複数の状態（例えば、使用可能な測度）が経路ごとに維持されてよい。

ＴＣＰ等の従来の第４層技術は接続管理、輻輳制御、信頼性、フロー制御等の機能性という点で統合された設計を有している。しかしながら、このような設計は、統合された動作が経路ごとの特徴および接続ごとの特徴を区別しないために効果的な並列通信のために本質的に欠陥がある。

しかしながら、ＴＣＰとは異なり、並列通信トランシーバ２２と２４は多様な機能性を経路ごとの機能性および接続ごとの機能性に分断する。例えば、記述の並列通信システムはフロー制御、接続管理、および接続信頼性を接続レベルの機能性として処理してよく、経路管理、輻輳制御、スループット推定、損失推定、遅延推定、および経路機能性ごとの他のネットワークパラメータの推定を関連付けてよい。

リソースの並列使用のために、ネットワーク機能性を経路ごとの機能性および接続ごとの機能性（および関連状態）に分断することの潜在的な優位性の一例は、２つの並列経路Ｐ１とＰ２を有するネットワークの関連で例示されてよい。経路Ｐ１とＰ２は、例えば、各々５０ユニットと１００ユニットという使用可能なスループットを有してよい。この例で、接続は両方の経路をその最大の可用性まで使用する。したがって、接続の総レートは１５０ユニットで動作できる。

線形増加／乗法減少（ｍｕｌｔｉｐｌｉｃａｔｉｖｅ ｄｅｃｒｅａｓｅ）（ＬＩＭＤ）として公知のＴＣＰ輻輳管理機構を使用すると、経路Ｐ１が損失を経験する場合、（分断された状態を維持しない、あるいは分断された機能性を実行しない）ＴＣＰが、接続全体の率を２分の１、削減するように設計されている。したがって、接続の合計率は７５ユニットに引き下げられる。

しかしながら、該２つの経路がベストエフォート方式のネットワーク（その場合には、率を半分削減することが「正しい」動作である）で使用されていると仮定しても、理想的な反応は接続全体よりむしろ損失のある経路でのみ率を半分にすることになる。

したがって、個々の経路の機能性（および関連状態）を接続から分断することによって、各経路は個別に維持されてよい。したがって、この例では、Ｐ１のレートは２５ユニットに半減されてよく、Ｐ２に沿った率（１００ユニット）を、影響を及ぼさずに残し、合計率１２５ユニットとしてよい。このようにして、性能の有意な改善は、接続の中の各経路から接続を分断しない従来の手法に比較して達成されてよい。別の言い方をすると、この改善は個々の経路を独立したエンティティと知覚し、このようにしてそれらを処理することによって達成される。

ここまで、接続と経路のコンセプトを全体として説明してきたので、並列通信セッションのコンセプトについて説明する。具体的には、各並列通信セッションは並列通信モジュール４６と関連付けられてもよく、構成されたトリガに基づいて作成されるその関連経路エンジン５０インスタンス（複数の場合がある）とともにコアエンジン４８インスタンスの具体的なセットを説明する。該トリガは、例えばユーザインタフェースを通して構成されてよい。

トリガは例えば特定のアプリケーション、アプリケーションタイプ、ソースアドレス−宛先アドレス、ソース宛先アドレスおよびポートに基づいて構成されてよい。並列通信トランシーバが構成されたトリガに一致するパケットを受信し、通信セッションが一致するトリガについて設定されている場合、新しいセッションが例証されてよい。各セッションインスタンスは独自のコアエンジン４８および関連するデータ構造を含んでよいため、各セッションは他のセッションのインスタンスとは無関係な固有の目的関数を有する場合がある。

トリガは、例えば、ＶｏＩＰトラフィックまたはｆｔｐトラフィック等の特定のアプリケーションに基づいてよい。したがって、コアエンジン４８は、部分的には、セッションインスタンスに一致する１つ以上の目的関数を満たすことに基づいて受信されるパケットのスケジューリングを行うように構成されてよい。ＶｏＩＰの場合、目的関数はジッタを削減するものであってよく、ｆｔｐトラフィックの場合スループットを最大化するものであってよい。したがって、送信側通信トランシーバは、多くのコアエンジン４８インスタンスによって送信のためにスケジューリングが行われるパケットを受信してよい。いくつかの場合では、たとえ宛先エンドポイントが同じであってよいとしても、経路とスケジューリングの異なるセットは各セッションの目的関数に基づいて使用されてよい。

トリガは、例えば宛先アドレスに基づいてよい。一実施形態では、トリガ構成は検出される新しい宛先ＩＰアドレスごとに新しいセッションを作成するために設定されてよい。宛先ＩＰアドレス「Ｘ」の付いた新しいパケットが並列通信トランシーバによって受信されると、新しい並列通信セッションは「Ｘ」に対応して作成される。宛先アドレス「Ｘ」が付いたより多くのパケットが受信される場合、これらのパケットは、それ自体のコアエンジン４８と経路エンジン５０のインスタンス（複数の場合がある）を含むそのセッションによってサービスを提供されてよい。

これまで並列通信セッションのコンセプトを説明してきたので、その構成要素、つまり経路エンジン５０とコアエンジン５８に関する詳細をさらに詳しく説明する。一般的には、経路５０は、経路の特徴付けを含む経路ごとの機能性を追跡調査すること、および経路内のパケットの信頼できる配信を確実にすることに関与する。経路エンジン５０と対照的に、コアエンジン４８は、接続管理、接続信頼性、フロー制御およびスケジューリング等の接続ごとの動作に関与してよい。コアエンジン４８は特定の接続のための並列経路についての情報も維持してよい。コアエンジン４８は、ネットワークトラフィックのための一次インタフェースとして構成されてよい。例えば、図２の実施形態では、コアエンジン４８は、各々パケットを送信し、受信するために、並列通信送信機モジュール６４および並列通信受信機モジュール６４を通して下にあるＩＰ層６２に接続する。コアエンジン４８は、接続プロセッサ６９、ディスパッチャモジュール６８、データプロセッサモジュール７０、送信バッファ６１、損失公表モジュール７４、並列通信ＡＣＫ送信機モジュール７６、ＬＩＭＤエミュレータモジュール７８、リソース発見モジュール７９、およびスケジューラモジュール８０を含む数多くのモジュールを含んでよい。これらのおよび他のモジュールの機能性は、コアエンジン４８に関して、および経路エンジン５０の相互作用の関連でさらに詳しく説明する。

経路エンジン４８に関して、図２は、ネットワーク内で使用されるあらゆる経路について作成されてよい多くの経路エンジン５０インスタンスを描いている。さらに、所与の経路のための経路エンジンインスタンスは、例えば経路を使用することになるあらゆる新しい接続（または、システムの中に構成されるトラフィック分離の細かさ(granularity)に応じてセッション、アプリケーション等）のために作成されてよい。経路エンジン５０のインスタンスは、例えば接続の第１のパケットが並列通信トランシーバに到達すると作成されてよい。

経路エンジン５０の各インスタンスは、経路特性を決定するために関連付けられた経路を特徴付けるために経路特徴付けモジュール５２を含んでよい。より具体的には、経路特徴付けモジュール５２は多くの他の機能を扱ってよいが、一般的には経路特徴付けモジュール５２は、それらが経時的に変化するにつれて経路特性を繰り返し決定してよい。経路特性の例は、特定の経路上で送信されるデータについて、スループット、帯域幅、遅延、ジッタ、損失率、コスト、およびセキュリティの瞬間（値）、平均（値）、および分散（値）を含んでよい。実際には、多くのネットワーク経路は、例えば異なるスループットの期間、帯域幅、遅延、データ損失、ジッタ、データフロー、コストおよび／またはセキュリティ等を有する動的な条件を有する。したがって、経路特性は、動的経路条件が捕捉されるように、繰り返して（例えば、周期的に、動的に、連続的におよび／または無作為に等）決定される。

経路特徴付けは能動的または受動的であってよい。能動的な特徴付けは、（例えばタイムスタンプ等の）特性を演繹的に決定するために使用されてよい情報を含むパケットにヘッダを追加することを含んでよい。対照的に、受動的な特徴付けは特性を演繹的に決定するために（例えばＴＣＰヘッダの中に等）データの中にすでに埋め込まれている情報を使用してよい、あるいはパケットの受信またはパケットの受信の欠如から経路特性を演繹してよい。例えば、ＴＣＰ肯定応答を観察することによって、システムは損失の発生またはその欠如を推論してよい。

受動的特徴付けは多様な経路に沿って配信されるデータパケットの特徴をモニタすることを含んでよい。いくつかの実施形態は経路特徴付けを実行するために既存の第４層の技術プロトコル動作を再利用する能力を含んでよい。したがって、トランスポートプロトコル動作（例えばＴＣＰ）の理解を通して、システムは経路特徴付けを実行するためにトランスポートプロトコルの機構を積極的に再利用するように構成されてよい。したがって、経路特徴付けは、ＴＣＰトランスポート層等の高位の層のプロトコルに関するこの認識を利用してよい。

モジュールが、経路の特性のすべてを決定する必要はない。むしろ、特定の目的（例えば、帯域幅の量、ジッタまたはコスト）に必要とされるそれらの特性のみを収集する必要がある。例えば、図２の実施形態では、１つの目的関数は帯域幅を最大化している。したがって、本実施形態では、経路特徴付けモジュール５２は一般的には経路ごとの帯域幅を特徴付けるために使用されてよい。特に、経路特徴付けモジュール５２は、特定の経路を通ってどれほど多くのデータが送信されるべきかを判断する目的で対応する経路全体でどれほど多くのデータが送信されるのかを決定し、連続的に追跡調査してよい。したがって、輻輳制御（経路関連機能性）は、接続信頼性（接続関連機能性）から分断される。

経路の輻輳制御は、経路を通して送信されるデータの量を決定することに関する。いくつかの実施形態では、少なくとも、各経路が異なる帯域幅特徴を有し、各経路がそれを通って流れる異なったトラフィックを有する可能性があるという理由から、場合によっては経路ごとの機能性として輻輳制御を処理することが有利である。したがって輻輳制御を分断することによって、異質の特徴（例えば異なる帯域幅、ジッタ、コスト、セキュリティ等）をもつ経路がより効果的に利用されてよい。したがって、経路特徴付けモジュール５２は、いつ特定の経路がデータの送信のために使用可能であるのかをコアエンジン４８に知らせる目的でコアエンジン４８と通信するように構成されてよい。

一実施形態では、各経路エンジン５０インスタンスはＴＣＰによって使用される輻輳ウィンドウベースの帯域幅推定機構を使用してよい。特に、帯域幅推定器は経路エンジンの対応する経路の帯域幅遅延積（容量）の近似値として輻輳ウィンドウを使用してよい。輻輳ウィンドウは、ＴＣＰ輻輳制御機構によって使用されるように、線形増加／乗法減少（ＬＩＭＤ）ポリシーに基づいて維持されてよい。ＬＩＭＤはレガシーインターネットフローの間の経路帯域幅の公平な共用を達成する。

経路エンジン５０は、使用可能な帯域幅を探るためにＴＣＰ輻輳制御機構のスロースタートフェーズを使用してもよい。スロースタートフェーズでは、経路特徴付けモジュール５２は受信されたＡＣＫパケットごとに、輻輳ウィンドウを増加してよい。輻輳ウィンドウのスレッショルド値はスロースタートから輻輳回避への遷移点を決定するために使用されてよい。スレッショルド値は、損失が発生する場合、輻輳ウィンドウ値の半分である。輻輳回避フェーズでは、経路特徴付けモジュール５２は、例えば受信されたＡＣＫパケットごとに１ずつ輻輳ウィンドウサイズを増分してよい。

経路特徴付けモジュール５２が第３の連続重複ＡＣＫパケットの受信を通して損失を検出すると、経路特徴付けモジュール５２は輻輳ウィンドウを半分削減し、輻輳回避段階を続行するように構成されてよい。経路特徴モジュール５２がＡＣＫパケットを待機するタイマの時間切れを通して損失を検出する場合は、経路特徴付けモジュール５２は輻輳ウィンドウサイズを１に削減し、スロースタートフェーズを進めるように構成されてよい。

経路特徴付けモジュールは、帯域幅、損失、遅延、ジッタ等であるが、これらに限定されないパラメータを含んでよい経路特性の推定を、ＴＣＰにフレンドリなレート制御（ＴＣＰ）、保証済みＴＣＰ（ＧＴＣＰ）、２項式輻輳制御（ＢＣＣ）等の機構を明示的に使用して実行してもよい。いくつかの実施形態では、経路特徴付けモジュールは、例えばパラメータの各々の平均値および偏差値を維持してよいカスタム推定手法を使用して経路特性の推定を実行してよい。推定手法は、受信された各ＡＣＫから学習される情報を使用して適切な重み付け平均化技法を通してパラメータを更新することをさらに含んでよい。例えば、ＡＣＫが時間Ｔ_tで送信されたデータパケットについて時間Ｔ_rで達すると、平均遅延値は以下のように更新されてよい。

Ｄｅｌａｙ_avg＝ｋ＊Ｄｅｌａｙ_avg＋（１−ｋ）＊（Ｔ_r−Ｔ_t） （式１）
この場合ｋは１未満で、０より大きい定数である。例えば、ｋは０．７５と１．０の間の値に設定されてよく、ネットワーク過渡現象に対する急激な反応を回避してよい。

一般的には、ヘッダジェネレータモジュール５６は、コアエンジン４８に送信される経路ヘッダを生成する。経路ヘッダは、最新ラウンドトリップタイム（ＲＴＴ）推定値、経路レベルシーケンス番号、ポート情報、チェックサム、経路レベルＡＣＫシーケンス番号、フロー制御情報、および、前記フィールドのいずれが有効であるのかを示すためのフラグ等であるが、これらに限定されない経路情報を含んでよい。コアエンジン４８は並列通信ヘッダを形成するためにこの経路ヘッダと組み合わされてよい接続ヘッダを生成する。接続ヘッダは、接続識別子、データパケットの接続シーケンス番号、接続レベルＡＣＫシーケンス番号、使用されている送信経路の数、および使用されている受信経路の数等であるが、これらに限定されない接続情報を含んでよい。並列通信ヘッダは、コアエンジン４８に関してさらに詳細に説明するように、パケットとともに送信されてよい。

ヘッダジェネレータモジュール５６は、経路特徴付けモジュール５２から要求に応じてデータパケットのために経路ヘッダを作成するように構成されてよい。経路特徴付けモジュール５２からの要求は、ヘッダジェネレータモジュール５６に作成されるヘッダ内に含まれる情報を提供してよい。例えば、経路特徴付けモジュール５２は経路レベルシーケンス番号および最新のラウンドトリップタイム（ＲＴＴ）推定値等を提供してよい。

経路特徴付けモジュール５２は、ｓｅｎｄ＿ｄａｔａ（）呼を介してインタフェース５６を通るコアエンジン４８にヘッダジェネレータモジュール５６によって作成される経路ヘッダを送信するように構成されてよい。特に、ｓｅｎｄ＿ｄａｔａ（）呼は、データパケットが発呼する経路エンジン５０インスタンスと関連する経路全体で送信されてよいことを、（コアエンジン４８の）スケジューラモジュール８０に示してよい。経路ヘッダ内の情報は、特定される経路全体でパケットの配信のスケジューリングを行うために（コアエンジン４８内の）スケジューラモジュール８０によって使用されてよい。経路全体でデータパケットの配信のスケジューリングを行うための例示的なアルゴリズムは、以下のスケジューラモジュール８０に関してさらに詳細に説明する。

経路特徴付けモジュール５２は、種々の条件下で新しいパケットを送信する能力を示すことによって使用可能な帯域幅を暗示的に推定してよい。例えば、一実施形態では、経路特徴付けモジュール５２は、以下の条件下でスケジューラモジュール８０にｓｅｎｄ＿ｄａｔａ（）呼を送信してよい。

（ｉ）（例えば、過去に送信されたパケットからのＡＣＫの受信等）過去に送信されたパケットが無事に受信されたことの表示
（ｉｉ）（例えば帯域幅プロービングまたは通常の動作等の）経路特徴付けモジュール５２のフェーズ、および／または
（ｉｉｉ）送信されることが決定された追加のパケットの数が端数である場合、以後の増加によりパケット全体の送信が可能になるまで、１未満の任意の値が蓄積される。

コアエンジン４８は並列通信経路４０、４２および４４上で送信される多くの標準パケットを保持するために使用されてよい送信バッファ６１を含んでよい。標準パケットは、一般的なＴＣＰパケットまたはＵＤＰパケット等の並列通信ヘッダを含まないパケットであってよい。例えば、標準パケットは、例えばソース演算装置３０から送信機並列通信トランシーバ２２に、あるいは受信機通信トランシーバ２４から宛先演算装置３２に送信されるものである場合がある。したがって、経路特徴付けモジュール５２から経路ヘッダを受信すると、コアエンジン４８は、あらゆるデータパケットが送信バッファ６１内で送信される多数のデータパケットについてチェックすることにより送信される準備ができているか否かを判断してよい。

データパケットが送信バッファ６１に存在する場合、コアエンジン４８は次の解放されたパケット（結合性データ構造で結合性を有さないバッファ内のパケット）を選び、経路特徴付けモジュール５２によって送信されるヘッダに該パケットを結合し、それを並列通信送信機６４を通して送出する。

しかしながら、データパケットが送信バッファ６１に存在しない場合、コアエンジン４８は、送信されるデータパケットの不在の表示で（例えばインタフェース６０上で）経路特徴付けモジュール５２に応答してよい。この表示は、ＦＲＥＥＺＥ（フリーズ）コマンドと呼ばれる場合がある。ＦＲＥＥＺＥコマンドをコアエンジン５０から受信すると、経路特徴付けモジュール５２は帯域幅推定を非アクティブにするように構成されてよく、コアエンジン４８が送信バッファ６１内にパケットを有さないことを経路ヘッダジェネレータモジュール５６に知らせてもよい。経路エンジン５０は、データパケットが送信バッファ６１内で待ち行列に入れられる旨のコアエンジン４８からの表示の受信時に、帯域幅推定とヘッダ生成の機能を再びアクティブにするように構成されてよい。この表示はコアエンジン４８により送信されるＲＥＳＵＭＥ（再開）コマンドと呼ばれる場合がある。

経路特徴付けモジュール５２は、インタフェース５８を通して帯域幅推定の変化をコアエンジン４８に知らせるように構成されてもよい。例えば、経路特徴付けモジュール５２は、経路特徴付けモジュール５２が過去に送信されたパケットからＡＣＫパケットを受信すると帯域幅推定値を更新するように構成されてよい。このＡＣＫパケットは、例えば、さらに詳しく後述する、コアエンジン４８の中に位置するディスパッチャモジュール６８から渡されてよい。

一般的には、信頼性モジュール５４は、経路エンジン５０インスタンスと関連する、関連付けられた経路に沿ったパケットの信頼できる配信を保証してよい。経路信頼性を、各接続の信頼性から効果的に分断するために、コアエンジン５０が接続信頼性を処理するように構成されてよいことを理解すべきである。したがって、接続信頼性は以下のコアエンジン４８に関してさらに詳しく説明される。

経路信頼性に関して、信頼性モジュール５４は、ディスパッチャ６８からＡＣＫを受信し、パケットが適切に受信されたか否かを判断するために累積的で、選択的なＡＣＫを活用するように構成されてよい。例えば、累積肯定応答が使用されるとき、所定数の複製の肯定応答を受信するとパケット損失が推論される。例えば、３つの複製のＡＣＫが連続して同じシーケンス番号を提供する場合、そのシーケンス番号に対応するパケットが失われた（したがって再送信されなければならない）ことが推論される。

選択的なＡＣＫが使用されると、どのパケットが失われているのかを特定するために、さらに特定の情報が受信機によって送信機に与えられる。例えば、受信機は、パケット５〜１１、１３〜２９、および３１〜４８の受信を送信機に示してよい。このようにして送信機は、パケット１２と３０が失われた（したがって再送信されなければならない）ことを推論してよい。

さらに、供給される接続がＴＣＰフローである場合、信頼性モジュール５４はＴＣＰヘッダを再利用するように構成されてよい。特に、ＴＣＰヘッダ内のＡＣＫシーケンス番号は、前述のように失われたパケットについての情報を交換するためにシステムによって使用されてよい。

ここまで経路エンジン５０の一般的な機能性を説明してきたので、コアエンジンについてさらに詳しく説明する。前述のように、コアエンジン４８は、接続管理、接続信頼性、フロー制御およびスケジューリング等であるが、これらに限定されない接続ごとの動作に関与してよい。コアエンジン４８のいくつかの実施形態がこれらの特徴のすべてを含まなくてよく、他の実施形態が種々の他の機能を含んでよいことが理解される必要がある。

いくつかの実施形態では、宛先によって維持されるバッファの量がフロー制御を実行する上での決定要因であってよいために、フロー制御が必要ではない可能性がある。したがって、宛先トランシーバはソーストランシーバに使用可能な受信バッファの量を知らせるように構成されてよい。このようにして、ソースはこの情報を使用して、宛先バッファのオーバフローを回避するためにその送信率を適応させてよい。したがって、一実施形態では、送信側並列通信トランシーバで使用されるバッファサイズは、受信側バッファのオーバフローのためのドロップ（ｄｒｏｐｓ）通信を回避するために宛先並列通信トランシーバで使用されるバッファサイズと同じである。

図２の実施形態では、コアエンジン４８は、並列通信受信機モジュール６６とのインタフェースを通してＩＰ層６２から受信される入信パケットを分類するためのディスパッチャモジュール６８を含んでよい。具体的には、ディスパッチャモジュール６８はコンテンツタイプ（例えば、データまたはＡＣＫ）を決定するために入信パケットのヘッダを調べてよい。したがって、データパケットはデータプロセッサモジュール７０に転送され、ＡＣＫパケットはＡＣＫプロセッサモジュール７２に転送される。

しかしながら、接続プロセッサ６９は、データプロセッサモジュール７０またはＡＣＫプロセッサモジュール７２のいずれかにパケットを転送する前に、パケットが公知の接続と関連しているか否かを特定するためにパケットを調べてよい。接続が公知ではない場合、接続プロセッサ６９は新規に発見された接続について適切なデータ構造を作成してよい。

一般的には、データプロセッサモジュール７０は、ディスパッチャモジュール６８から受信されるデータパケットを処理してよい。データプロセッサモジュール７０は、受信されるパケットのタイプに基づいて多くの動作を実行するように構成されてよい。特に、データプロセッサモジュール７０は、受信されたパケットが並列通信ヘッダを含むか否かを検出するように構成されてよい。

例えば、図１を振り返ると、送信機並列通信トランシーバ２２は、ソース演算装置３０からの並列通信ヘッダを有さない標準データパケットを受信する。したがって、データプロセッサモジュール７０は、ネットワーク全体２６での最終的な送信のために送信バッファ６１内で受信されたデータパケットをバッファに入れる。

対照的に、並列通信トランシーバ２４は、並列経路４０、４２および４４の任意の組み合わせ上で並列通信トランシーバ２２から並列通信データパケット（例えば、並列通信ヘッダ内にカプセル化されているもの）を受信する。並列通信トランシーバが並列通信データパケットを受信すると、データプロセッサモジュール７０は、データパケットから接続ヘッダを削除し、ヘッダから接続情報を抽出してよい。コアエンジン４８は、接続ヘッダからの対応する接続変数とデータ構造を更新してよい。例えば、コアエンジン４８はＲＴＴ値を更新し、ＡＣＫ（肯定応答）されたパケットの送信バッファをパージし、さらに詳しく後述するランクデータ構造を更新してよい。

データプロセッサモジュール７０は、データパケットから経路ヘッダを削除し、インタフェース６０を通る対応する経路に関連する経路エンジン５０に経路ヘッダを転送してよい。対応する経路は、例えば経路シーケンス番号および／または経路ヘッダの中のソースアドレスと宛先アドレスから決定されてよい。経路エンジン５０は、次にＡＣＫを送信側並列通信トランシーバに送り返してよい。ＡＣＫは、データパケットが無事受信されたことを示してよく、データパケットからコピーされたＲＴＴ値等のデータパケット送信についての情報を含んでよい。

データプロセッサモジュール７０は、宛先エンドポイント装置への最終的な配信のために受信されたデータパケットの集約演算に関与してよい。いったん並列通信ヘッダが削除されると、データプロセッサモジュール７０は、並列通信送信機インタフェース６４を通してＩＰ層に、標準ＴＣＰデータパケットであってよい結果として生じる標準的なデータパケットを送信してよい。一実施形態では、データプロセッサモジュール７０は、条件付きで再構築を実行するように構成されてよい。すなわち、データプロセッサモジュール７０は、受信されたデータが再同期を必要とする条件を満たすときにのみ受信されたデータを順序付けし直すように構成されてよい。条件付き再構築プロセスは、例えば、スケジューリングモジュール８０によってスケジューリングが行われたように、それらが受信されるべきであった所定のシーケンスに受信されたデータを順序付けし直してよい。

例えば、データプロセッサモジュール７０は、以下の２つの条件の内の１つの下においてのみＩＰ層にパケットを送信してよい。つまり（ｉ）高位の層のプロトコルがイン−シーケンス（ｉｎ−ｓｅｑｕｅｎｃｅ）配信（例えばＴＣＰ）を必要とするプロトコルであり、データパケットがイン−シーケンスパケットである、あるいは（ｉｉ）高位の層のプロトコルがイン−シーケンス配信を必要とするプロトコルではない。標準的なデータパケットは、次にエンドツーエンド接続の最終的な宛先、ここでは宛先演算装置３２に送信されてよい。条件の両方が満たされると、データパケットは、新しいデータパケットが到達するまでデータバッファの中に保持される。受信されたあらゆるデータパケットについて、コアエンジンは、前記条件に基づいて可能な限り多くのバッファ化されたパケットを使い果たしてよい。

ＡＣＫパケットの受信時に、ディスパッチャモジュール６８はパケットをＡＣＫプロセッサモジュール７２に転送する。一般的には、ＡＣＫプロセッサモジュール７２は接続ヘッダと経路ヘッダを処理し、関連する接続ごと、および経路ごとのフィードバックを提供することにより信頼性と輻輳の制御を実現する。

より具体的には、ＡＣＫプロセッサモジュール７２は、受信されたパケットのタイプに基づいて多くの動作も実行してよい。例えば、ＡＣＫプロセッサモジュール７２が（例えば、並列通信ヘッダを検出することにより）受信されたＡＣＫパケットが並列通信ＡＣＫパケットであると検出すると、ＡＣＫプロセッサモジュール７２はデータパケットから接続ヘッダを削除し、ヘッダから接続情報を抽出する。さらに承認信号を受信すると、送信バッファ６１から対応するデータパケットを削除するように構成されてよい。

ＡＣＫプロセッサモジュール７２は、並列通信ＡＣＫパケットから経路ヘッダを削除し、インタフェース６０を通して経路ヘッダを経路エンジン５０に転送してもよい。ＡＣＫプロセッサモジュール７２は、ＴＣＰ ＡＣＫパケットであってよい標準ＡＣＫパケットを損失公表モジュール７４に転送してもよい。

一般的には、損失公表モジュール７４は、ソース演算装置３０が複数の経路の総計の帯域幅への適応を支援する。より具体的には、損失公表モジュール７４はソースを経路の総計レートに適応させ、データのソースによる利用不足またはオーバーシューティングの可能性を回避することを最終目的としてデータのソース（例えばソース演算装置３０）にパケットデータの損失を選択的に公表する。

ＬＩＭＤエミュレータモジュール７８は、線形増加／乗法減少（ＬＩＭＤ）送信ポリシーを順守するＴＣＰ送信機の動作をエミュレートするために損失公表モジュール７４とともに使用されてよい。ＬＩＭＤエミュレータモジュール７８は、ＴＣＰ送信機が同数のＡＣＫパケットを受信すると実行することになる同じ輻輳制御機構をエミュレートしてよい。図２の実施形態では、ＬＩＭＤエミュレータモジュール７８は、例えばｅｍｕｌ＿ａｃｋ（）呼を通して損失公表モジュール７４によって受信されたＡＣＫ送信について通知されてよい。さらにＬＩＭＤエミュレータモジュール７８は、送信されたパケット数をゼロにリセットし、それが対応する問合せを損失公表モジュール７４から受信すると、送信されたパケット数を戻すように構成されてよい。例えば、送信されたパケット数を突き止めるためのＬＩＭＤエミュレータモジュール７８に対する問合せは、損失が送信側ＴＣＰに公表されるべきか否かを判断するために使用されてよい。したがって、損失が公表される場合、リセット問合せはＬＩＭＤエミュレータモジュール７８の動作をリセットするために使用される。

一実施形態では、損失公表モジュール７４は、損失を示すそれらのＡＣＫパケットを除きすべてのＡＣＫパケットをソースに転送してよい。損失を示すＡＣＫパケットの受信時に、損失公表モジュール７４はｐｋｔｓ＿ｓｅｎｔとＴｎを比較してよい。ｐｋｔｓ＿ｓｅｎｔ変数およびＴｎは、各々並列通信送信機６４とＬＩＭＤエミュレータ７８によって送信されるパケット数に相当してよい。Ｔｎの値は、例えばＬＩＭＤエミュレータ７８のｅｍｕｌ＿ｎｕｍ（）関数を呼び出す損失公表モジュール７４によって得られてよい。

Ｔｎ−ｐｋｔｓ＿ｓｅｎｔ＞μであり、μが設定可能である定数スレッショルドである場合には、損失公表モジュールはＩＰ層にＡＣＫパケットを転送し、ｐｋｔｓ＿ｓｅｎｔ変数を０にリセットし、ＬＩＭＤエミュレータモジュール７８のｅｍｕｌ＿ｒｅｓｅｔ（）関数を呼び出し、ＬＩＭＤエミュレータから送信されたパケット数を０にリセットしてよい。それ以外の場合、Ｔｎ−ｐｋｔｓ＿ｓｅｎｔ＜μの場合、損失公表モジュール７４はＡＣＫパケットを中断する（ｄｒｏｐ）ように構成されてよい。損失公表モジュール７４はまた、ＬＩＭＤエミュレータモジュール７８に、ＡＣＫパケット各々をＩＰ層に転送するように通知してよい。この通知は、例えばｅｍｕｌ＿ａｃｋ（）呼を通して発生してよい。

ＡＫＣパケットが宛先から受信され、並列通信ヘッダが欠如していることを示されると、ＡＣＫプロセッサモジュールは並列通信ＡＣＫ送信機モジュール７６にパケットを転送する。並列通信ＡＣＫ送信機モジュール７６は標準ＡＣＫパケットをＡＣＫプロセッサモジュール７２から受信すると、ａｃｋ＿ｍａｐｐｉｎｇデータ構造を要求し、対応する経路エンジンを決定し、対応する経路エンジン５０から経路ヘッダを要求する。ａｃｋ＿ｍａｐｐｉｎｇデータ構造は、例えば特定の経路に沿って到達したパケットの適切なシーケンス番号を維持してよい。シーケンス番号および関連経路を維持することによって、パケットに対応するＡＣＫが同じ経路に沿って送信されてよい。

通信経路エンジン５０は、識別されたＡＣＫパケットのための対応する経路ヘッダを返す。次に、並列通信ＡＣＫ送信機モジュール７６は、経路ヘッダと接続ヘッダを含む並列通信ヘッダで受信されたＡＣＫパケットをカプセル化してよい。ＡＣＫ送信機モジュール７６は、その後、送信機並列通信トランシーバへのＡＣＫパケットの配信のために、並列通信送信機６４を通して、構築された並列通信ＡＣＫパケットをＩＰ層６２に送信してよい。

リソース発見モジュール７９は、ネットワーク２６全体でデータを送信するために使用可能なリソースを受動的にまたは能動的に発見してよい。図１の実施形態では、例えば、リソースはノード２８、および経路４０、４２および４４を形成するために接続する他の並列通信トランシーバ２２と２４であってよい。トラフィックを受動的にモニタするとき、リソース配信モジュール７９はＩＰ層６２からデータパケットを受信し、各ネットワークパケットのソースノードと宛先ノードを決定するために各パケットからＩＰヘッダを抽出する。したがって、パケット内でソースノードと宛先ノードを決定することにより、経路はこれらのノードの間に存在すると推論されてよい。

発見されたソースノードおよび／または宛先ノードは潜在的な並列通信トランシーバであってよい。例えば、リソース発見モジュールは、受信されたパケットが並列通信ヘッダを含む場合に、ソースおよび／または宛先が並列通信トランシーバであると推論してよい。

潜在的な並列通信トランシーバを発見すると、リソース発見モジュール７９は、その後、例えば並列通信ヘッダを含んでよいネットワークリソースに発見パケット（例えば、「ピング」）を送信することによって、発見されたリソースを確認してよい。このピングを受信する他の並列通信トランシーバは、並列通信ヘッダでカプセル化されたＡＣＫパケットで該ピングを肯定応答することによって応答するように構成されてよい。いくつかの実施形態では、応答側並列通信トランシーバは、公知の経路、経路特徴、および他の公知の並列通信トランシーバ間の並列通信トランシーバによって供給される接続についての情報を供給するように構成されてよい。

したがって、リソース発見モジュール７９は、他のネットワークリソース（例えば、並列通信トランシーバ、ルータ等）から、または（グラフィックユーザインタフェースを通して表示されてよい）構成インタフェースを通して等、外部でリソースのアイデンティティを提供されることによってリソースを「発見」してもよい。リソース発見モジュール７９は、前記のように、例えば並列通信ヘッダを含んでよいネットワークリソースに発見パケット（例えば「ピング」）を送信することによって可用性発見リソースを確認してよい。

リソース「発見」モジュール７９は、示されたピングに対照的に、ネットワーク内の他の並列通信トランシーバを知るために発見パケットのネットワーク全体でのブロードキャストも実行してよい。この場合、ブロードキャスト発見パケットを受信するすべての並列通信トランシーバはその存在を示すために適切なＡＣＫメッセージで応答するように構成されてよい。

さらに、リソース発見モジュールは、経路上でデータを受信し、おそらく再送信するためのノードの可用性を決定する目的で、並列通信トランシーバ等の公知のノードに発見パケットを繰り返し送信することによって発見されたリソースのステータスを維持してよい。

いったんリソースが発見されると、中間リソース間の個々のリンクは２つの並列通信トランシーバ間の１つ以上の経路を要約する（ａｂｓｔｒａｃｔ）ために使用される。図１を見ると、各ノード２８の間のリンクは、単一の仮想接続３８を形成する経路４０，４２および４４の各々に要約され、単一の仮想接続３８を形成する。いったん経路が要約されると、コアエンジン４８は接続上でデータを送信するために潜在的なリソースとして経路を記憶する。経路エンジンの新しいインスタンスは、経路を使用できる新しい接続が発見されると作成されてよい。

複数の並列通信トランシーバまたはレガシーノードを通してルーティングデータを含んでよい、経路に沿ったデータの実際の配向は、ＩＰ−ｉｎ−ＩＰカプセル化、最小ＩＰカプセル化、またはソースルーティング等であるが、これらに限定されない幅広く採用されているルーティング規格を使用して実行されてよい。これらの技法はある特定のデータを通してデータを押し進めるために幅広く採用されているので、経路内の中間ノードは他の並列通信トランシーバであることを必要とされず、実際には単に採用されたルーティング規格をサポートするレガシールータである場合がある。しかしながら、いくつかの実施形態では、サポートされるルーティング規格を（例えば外部構成を通して）サポートするレガシールータの識別で並列通信トランシーバを供給することが必要であってよい。

一般的には、スケジューラモジュール８０は、（例えば、帯域幅最大化／スループット、遅延の最小化、ジッタ削減、コスト削減、セキュリティ、信頼性の向上（および損失率）、および／または弾力性（ｒｅｓｉｌｉｅｎｃｙ）の）目的関数を達成する目的で送信されるパケットのスケジューリングをインテリジェントに行う。目的関数が関数の組み合わせ（例えば、帯域幅を増加することとジッタの削減）であってよいことが理解されるべきである。さらにスケジューラモジュール８０は、目的関数の所望されるサービスのレベル（例えば、帯域幅の量、許容できるジッタ、コストレベル等）を満たすように構成されてよく、パケットスケジューリングは、公知の経路のアイデンティティ、経路の動的に更新された特徴、経路および／または接続についての記憶されている状態情報であるが、これらに限定されない情報に、および高位のレベル（例えばＴＣＰ）動作の認識を利用することによって基づいてよい。

例えば、言及されたように、目的関数はある特定の接続上で帯域幅を最大限にするため、あるいはジッタを削減するためであってよい。したがって、ソース演算装置３０から送信機並列通信トランシーバ２２に到達するパケットは各々、宛先並列通信トランシーバで必要とされる同期と実質的に同じ順序で、および／または宛先並列通信トランシーバで必要とされる同期の程度の範囲内で宛先並列通信トランシーバ２４に到達するために発信経路４０、４２、および４４に割り当てられている。

データは、スケジューリングが行われている他のデータに関連して所定のシーケンスで宛先において受信されるようにスケジューリングが行われてよい。例えば、所定のシーケンスは、データがスケジューラで受信される順序、データがソース演算装置３０によって送信される順序、データシーケンス情報（例えば、データパケットヘッダの中に埋め込まれている数列等のデータ通信の中のパケットの特定の順序を表すために使用されるデータ）、あるいはデータが並列通信送信機から宛先エンドポイントに送信されなければならない順序に対応してよい。

したがって、パケットは実際には宛先トランシーバ２４で順序が狂って受信されてよいが、該パケットは、順序が狂った受信が最小限に抑えられるように送信されるスケジュールとなり、このようにしてジッタを減少し、帯域幅を改善する。

他の情報の中では、スケジューラモジュール８０はパケットのスケジュールを連続的に適切に決定するために経路の動的な特徴付けを使用する。例えば、経路特徴付けモジュール５２は、１つの経路の使用可能な帯域幅が減少したと判断すると、スケジューラモジュール８０は、適応させ、影響を受けた経路全体で送信されるより少ないパケットのスケジューリングを行うためにこの特徴付け情報を使用してよい。同様に、経路が完全に壊されると判断される場合、パケットは他の経路上で送信されるようにスケジューリングされてよい。

したがって、経路の各々で送信されるデータを効果的に同期させるために、スケジューラモジュール８０は各経路上で送信される各パケットの到着時刻を予測するように構成されてよい。例えば、到着時刻は、経路特徴付けモジュール５２によって提供されるＲＴＴ推測値に少なくとも部分的に基づいてよい。さらに、いくつかの実施形態では、スケジューラモジュール８０は各経路上で送信されるデータの到着確率を検討するように構成されてよい。到着確率は、例えばある特定の経路の損失率のような経路特性から引き出されてよい。したがって、パケットは経路の動的特徴に基づいて再分散される。

図２を見直すと、動作中、スケジューラモジュール８０は経路エンジン５０のインスタンスから経路ヘッダを要求してよい。スケジューラモジュール８０は、経路ヘッダを受信すると、送信バッファ６１からの送信のためにデータパケットを選択してよい。スケジューラモジュール８０は、経路エンジン５０からの経路ヘッダと、接続情報を含む接続ヘッダとを含む並列通信ヘッダで選択されたデータパックをカプセル化する。スケジューラモジュール８０は、送信機インタフェース６４を通してＩＰ層６２に、並列通信ヘッダでカプセル化されたデータパケットを送信してよい。スケジューラモジュール８０は該適切なデータ構造を更新してもよい。

スケジューラ８０によって使用される例示的なアルゴリズムの詳細を説明する前に、スケジューラモジュール８０によって使用されてよい多くのデータ構造がさらに詳しく説明する。結合性データ構造８２は、対応する経路のために、経路単位で維持され、一般的には接続シーケンス番号と対応する経路シーケンス番号のマッピングを記憶するために使用されてよい。具体的にはスケジューラ８０によってＩＰ層に送信されるデータパケットごとに、コアエンジン４８は、関連経路のローカルシーケンス番号と結合性データ構造８２での接続シーケンス番号の間のマッピングを維持する。

同様に、コアエンジン４８は、データパケットが受信されるときに同じ構造を維持する。特に、データプロセッサモジュールは、ＰＶＮ送信機からのデータパケットの受信時に、対応する経路のための結合性データ構造の中に接続シーケンス番号と、対応する経路シーケンス番号とのマッピングを挿入してよい。

アクティブデータ構造８４は、データの送信に使用可能な経路のアイデンティティを記憶してよい。例えば、データが関連する経路全体で送信されてよいと判断すると、特定の経路のための経路エンジン５０のインスタンスが、スケジューラ８０にｓｅｎｄ＿ｄａｔａ（）呼を送信することによってこの準備が完了していることを示してよい。しかしながら、データパケットが送信バッファで使用できない場合には、コアエンジン４８はＦＲＥＥＺＥ（フリーズ）関数を呼び出し、スケジューラモジュールは対応する経路をアクティブデータ構造８４に追加してよい。データパケットが送信バッファ６１内に格納されると、スケジューラ８０はアクティブデータ構造８４内で識別される経路の各々に対応する経路エンジン５０インスタンスに対してＲＥＳＵＭＥ（再開）呼を発行してよい。

ランクデータ構造８６は、送信バッファ内で送信されるデータパケットのランクを決定するために使用される情報を記憶してよい。特に、経路ｊを通して送信されるあらゆる送信済みデータパケットｉの場合、並列通信送信機６４は、Ｔ_i＋２＊ＲＴＴ_jのタイムスタンプでランクデータ構造８６の中にエレメントを挿入し、この場合Ｔ_iはデータパケットが送信された時刻であり、ＲＴＴ_jは経路ｊを通って遭遇したラウンドトリップタイムである。ＲＴＴ値は、例えばＲＴＴデータ構造から取り出されてよい。

ＲＴＴデータ構造８８は、特定の経路のためのラウンドトリップタイム推定値を記憶してよい。特に、スケジューラモジュール８０は、経路エンジン５０からｓｅｎｄ＿ｄａｔａ（）呼を介して特定の経路のＲＴＴ推定値を受信すると、ＲＴＴデータ構造の中の対応するエントリを更新（または挿入）してよい。

未決データ構造９０は、送信または再送信の準備ができた接続シーケンス番号を記憶するために使用される。

ここまでスケジューラモジュール８０によって使用されるデータ構造が説明してきたので、スケジューラモジュール８０によって使用されるアルゴリズムについてさらに詳細に説明する。（経路エンジン５０の）経路特徴付けモジュール５２は、特定の経路を通って送信されるデータの量を決定してよいが、スケジューラモジュール８０は、パケットを相応させて結合することにより、送信バッファ６１の中の特定のパケットのいずれが経路の各々を通して送信されるべきか否かを決定することを理解すべきである。

このようにして、送信バッファ６１の中の特定のパケットのいずれが経路の各々を通して送信されるべきかを判断するために、経路ｊに対応する経路エンジン５０が時間Ｔで経路シーケンス番号ｓが付いた経路ヘッダを送信する場合を考える。スケジューラモジュール８０はｓｅｎｄ＿ｄａｔａ（）呼を通して経路ヘッダを受け取り、ランクデータ構造から対応するパケットのランクを決定する。

パケットのランクは、ランクデータ構造８６の中で値がＴ＋ＲＴＴ_j／２未満であるエントリの数をカウントすることによって決定される。スケジューラモジュール８０は未決データ構造９０の中で送信するｋ番目のパケットとして接続シーケンス番号ｉの付いたパケットを検出する。

前述のように、未決データ構造９０は、まだ送信または再送信されていないパケットの接続シーケンス番号を含んでよい。未決データ構造９０の中の特定のパケットを検出した後に、スケジューラ８０は（ｊ，ｓ）が付いた結合データ構造８２の中のパケットｉのエントリを更新し、ランクデータ構造８６にエントリ（ｉ，Ｔ＋３／２＊ＲＴＴ_j）を挿入する。最終的には、スケジューラ８０は接続ヘッダからシーケンス番号ｉを使用し、接続ヘッダおよび受信された経路ヘッダをデータパケットに取り付け、並列通信送信機６４を通してそれをＩＰ層に送信する。ＡＣＫパケットが受信されると、ランクデータ構造８６の中の対応するエントリが削除される。

接続内でのパケットの確実な配信は、スケジューラモジュール８０によっても処理されてよい。特に、スケジューラモジュール８０は、前述のように、スケジューリングポリシーに基づいて送信バッファからパケットを送信してよい。さらに、スケジューラモジュール８０は（パケットが宛先並列通信トランシーバで無事に受信されたことを示す）ＡＣＫが到達したパケットを削除してよい。

したがって、（経路エンジン５０の中の信頼性モジュール５４によって処理される）経路信頼性と対照的に、接続を介したパケットの確実な配信はコアエンジン４８のスケジューラモジュール８０によって保証されてよい。別の言い方をすると、パケットが受信側並列通信トランシーバまで採る特定の経路には関係なく、送信側並列トランシーバのコアエンジン４８は、接続上でデータパケットの確実な配信の役割を担うように構成されてよい。

ここまで経路エンジン４８とコアエンジン５０を説明してきたので、説明したシステムおよび方法を用いて利用されてよい多くの例示的な機能を説明する。例えば、動的再割り当て機能は、対応する経路エンジンによる任意の経路の容量の不正確な推定のためにパケットの損失を妨げるために使用されてよい。例えば、経路特徴付けモジュール５２は、例えば経路の中で輻輳が発生する直前に、経路の容量を過度に見積る可能性がある。この過度の見積りは、輻輳ウィンドウが最近削減された経路内のデータの望ましくない低速化につながる場合がある。

例えば、経路ｐ_iの輻輳ウィンドウはｃｗｎｄ_iとして表現されてよい。ｃｗｎｄ_iの価値があるデータが経路ｐ_iに割り当てられ、輻輳ウィンドウサイズがｐ_iの輻輳ウィンドウの範囲外になるｃｗｎｄ_i／２の価値があるデータまで削減されると、データの送信は、輻輳ウィンドウｃｗｎｄ_iが開くまでブロックされる。したがって、他の経路の送信は、経路ｐ_iの中のパケットの送達の遅延のために低速化する可能性がある。

しかしながら、経路輻輳制御と接続信頼性の間に存在する分断を利用することによって、この問題は緩和される可能性がある。特に経路が輻輳を経験する場合、経路エンジン５０の経路特徴付けモジュール５２は（例えば、それが複製肯定応答によって検出される場合には半分、およびタイムアウトがある場合には１に）輻輳ウィンドウを削減してよい。

前述のように、対応する経路のための経路特徴付けモジュール５２が輻輳ウィンドウを削減する場合、経路特徴付けモジュール５２は削減についてスケジューラモジュール８０に知らせてよい。スケジューラモジュール８０は、次に輻輳ウィンドウの範囲外になる関連する経路のシーケンス番号に結合されるデータパケットを解放してよい。

したがって、別の経路がその輻輳ウィンドウ内に空間を有し、ｓｅｎｄ＿ｄａｔａ（）呼を送信する場合、解放されたデータはその経路に再割り当てされてよい。オリジナルの経路が輻輳から回復後にｓｅｎｄ＿ｄａｔａ（）を呼び出すと、スケジューラモジュール８０は送信バッファ内に記憶される新しいデータパケットを経路エンジン５０によって送信される経路ヘッダに結合してよい。したがって、この動的な再割り当てアルゴリズムは、個々の経路の変化するネットワーク条件によって生じる問題を緩和するために並列通信の性能を改善するために使用されてよい。

説明されているシステムおよび方法と利用されてよい別の例示的な機能は、冗長なストライピングと呼ばれる場合がある。前述の動的再割り当て戦略はある特定の経路の輻輳ウィンドウの範囲外であるパケットを再割り当てするが、動的再割り当て戦略は経路の状態に関係なく輻輳ウィンドウから外れない可能性がある第１のパケットを効果的に対処することはできない。

残念なことに、経路を通って第１のパケットを配信できないと、パケットは順序付けられた配信で到着しないことになるために、潜在的に、集約接続を通るデータフローが行き詰まる可能性がある。これは、例えば関連する経路が、多くの複数のタイムアウト、あるいは各々の経路を通るデータフローの完全な停止によって影響を受ける場合に考えられる。

幸いなことに、冗長ストライピングポリシーを使用することにより、これらの問題は軽減することができる。特に、冗長ストライピングポリシーの一実施形態に従って、スケジューラモジュール８０は、別の経路上に、タイムアウトを被った経路の輻輳ウィンドウ内の第１のデータパケットを冗長にストライピングするように構成されてよい。したがって、（旧い経路にも送信用のデータパケットが割り当てられているが）データパケットの結合は新しい経路に変更される。（例えば単純な再割り当ての代わりに）旧い経路の中のデータパケットのコピーを残すことによって、旧い経路は少なくとも１つのパケットをタイムアウトから回復するために送信することを必要とする。

（例えばリソースの可用性、リソースの特徴付け、目的機能性等）インテリジェンスのすべてまたはほとんどすべてが送信側並列通信トランシーバ内に常駐する実施形態が説明されてきた。しかしながら、インテリジェンスの大半の部分が、受信側並列通信トランシーバに、またはあらゆる中間ノードの中で分散されてよい。例えば、経路に沿った中間ネットワークリソース（例えば、ノード、レガシールータ、または別の並列通信トランシーバ）は、経路特性を直接的にまたは間接的に使用されてよい、ノードが認識する他のネットワークリソースについての情報を供給してよい。さらに、受信側並列通信トランシーバは、経路発見および経路特徴付けのタスクを実行してよく、送信側並列通信トランシーバは所望される目的を達成するために提供されている経路上で効果的にデータを送信するために、受信側並列通信トランシーバからの必要な情報をスケジューラモジュールに与えるために周期的に情報を要求してよい。したがって、要求されている演算能力とインプリメンテーションのための設置面積はネットワーク全体で分散されてよい。

図１は並列通信トランシーバ、接続およびエンドポイントの２つのセットを描いてきたが、関連する通信エンドポイントのためにネットワーク２６を利用する目的で、任意の数の通信トランシーバをネットワーク２６に組み合わせてよい。例えば、図３に描かれているように、企業ＷＡＮ１００のようなネットワークは、各々サンフランシスコ、アトランタ、シカゴおよびシアトルに位置する４つの遠隔オフィスサイト１０２、１０４、１０６および１０８によって代表されてよい。

該４つの遠隔オフィスサイト１０２、１０４、１０６および１０８は、各々並列通信トランシーバ１１０、１１２、１１４および１１６を含んでよい。さらに、該４つの遠隔オフィスサイト１０２、１０４、１０６および１０８の各々は、多くの通信エンドポイント（不図示）を接続するために、１つ以上のサブネットワーク１１８、１２０、１２２および１２４（例えばＬＡＮまたはＷＡＮ）を含んでよい。

各々のサイトのための並列通信トランシーバ１１０、１１２、１１４および１１６の各々は、通信リンク１１０、１１２、１１４、１１６、１１８および１２０によって表現される他のサイトへの直接的な接続を有してよい。通信リンク１１０から１２０の各々は、図１と図２に関して説明された実施形態に従って利用されてきた任意の数のネットワークリソースを備えてよい、トランシーバ１１０、１１２、１１４および１１６の各々の間のエンドツーエンド通信接続を表現してよい。

図３の例では、ネットワークリソースを集約しない既存のネットワーク管理技法は、特定のトラフィックノードに応じるためにネットワークのトポロジーを動的に改変する能力に欠けている。例えば、説明された実施形態のシステムおよび方法が使用されず、サイトの内の任意の２つの間のピーク帯域幅使用率が１００Ｍｂｐｓである場合を考える。並列通信トランシーバ１１０、１１２、１１４および１１６を使用しない場合は、リンク１２６から１３６にはピーク帯域幅要件を達成するために各サイト間で１００Ｍｂｐｓという帯域幅が与えられなければならない。

対照的に、各遠隔サイトに並列通信トランシーバ１１０、１１２、１１４、および１１６を設置することによって、サイト間で通路の各々を利用する能力が実現される。したがって、前記例では、完全に接続されたネットワークトポロジの場合、任意の２つのサイトの間に少なくとも３つの接続があるため、３３．３Ｍｂｐｓという帯域幅をサイトツーサイトリンクに与えるので十分である。

したがって、例示的な企業ＷＡＮは、並列通信トランシーバ１１０、１１２、１１４および１１６の間に多くの経路を備える個々のリンクを、新しい単一の接続にさらに要約することによって複数の単一の仮想接続がさらに利用されてよいことを描いている。例えば、リンク１２６と１２８、１３２、および１３４と１３６によって形成される経路が、並列通信トランシーバ１１２と１１４の間の単一な仮想接続の中に分離されてよい３つの経路を形成する。リンク１２６、１３０、１３６および／または１３４、１３０、および１２８によって形成される経路等の他の経路も使用可能であってよいことが理解されなければならない。

例示的な企業ＷＡＮ１００は、リソース発見モジュール７９（図２）によって発見された可能性がある中間並列通信トランシーバが、該中間並列通信トランシーバが送信側トランシーバによって公知の潜在的な要約経路のいずれかに沿ってパケットを再送信するように命令されてよいという点で特に貴重であることを描いている。これらの中間並列通信トランシーバは、要約経路に沿って「反射ポイント」として記述されてよい。例えば、トランシーバ１１２からトランシーバ１１４へデータを送信する際に、中間トランシーバ１１０と１１６は、トランシーバ１１４に直接的に、または他の中間トランシーバを通して（例えば経路１２６、１３０および１３６に沿って順次に、および中間トランシーバ１１０と１１６を通して）のいずれかでデータを通信するように命令されてよい。このルート命令は、例えば並列通信ヘッダに含まれてよい。

送信側並列通信トランシーバは（例えばＩＰ−ｉｎ−ＩＰカプセル化、最小ＩＰカプセル化、またはソースルーティングを使用して）中間並列通信トランシーバに、他の中間または宛先並列通信トランシーバであってよい他の公知の並列通信トランシーバにパケットを向けるように命令してよい。

並列通信の実施形態は、送信側並列通信トランシーバと受信側並列通信トランシーバの両方を有するとして概して説明されてきた。しかしながら、いくつかの実施形態では、受信側ノードに配信されるデータが並列通信トランシーバによって受信されることは必要ではない。むしろ、送信側並列通信トランシーバは目的関数を達成するために複数の経路上で受信側ノードで受信されるデータの送信のスケジューリングを行ってよく、この場合受信側ノードは宛先エンドポイント自体である。このような実施形態では、送信側並列通信トランシーバはそのリソース特徴付け方法で宛先エンドポイントと協調できない可能性があるため、経路特性は外部手段を通して（例えば外部構成を通して）送信側並列通信トランシーバによって学習されてよい。

説明されている並列通信の実施形態は並列データ経路上でデータを通信するための方法として説明されてよく、説明されたシステムの機能は並列データ経路上で効果的にデータを通信するために実行されてよい多くのステップを提供すると見なされてよい。

しかしながら、特に並列通信方法１３８のような方法は、ネットワーク２６全体でデータを送信するために使用可能なリソースを発見するステップ１４０を含んでよい。例えば、リソースはノード、レガシールータ、または経路を形成してよい並列通信トランシーバ等の種々のネットワークエンティティであってよい。発見ステップ１４０は、受信側ノードに肯定応答パケットを送信するようにとの要求を備えるデータパケットをブロードキャストすることと、並列通信トランシーバであってよい受信側ノードから肯定応答パケットを受信することとを含んでよい。リソースは、外部ソースから提供される（例えば、ネットワークリソースから、または他の外部構成を通して送信される）リソース情報によって発見されてもよい。リソースはさらに、並列通信トランシーバであってよい送信側ノードと受信側ノードを発見するためにデータトラフィックをモニタすることによって発見されてよい。

リソースの発見時、これらの公知のリソースは該公知リソースにパケットを繰り返し送信することによって維持されてよい。したがって、公知の並列トランシーバのデータの送信を受信するための可用性が維持されてよい。該繰り返される送信は連続的に、周期的に、または任意の時間間隔で無作為に発生してよい。

ステップ１４２は、受信されたデータパケットからルート情報を収集することと、該抽出されたノード情報から送信側ノードと該受信側ノードの間の少なくとも１つの経路を要約することとを含んでよい。複数の要約された並列データ経路は送信側ノードと受信側ノードの単一の仮想接続を定めてよい。中間並列通信トランシーバはＩＰ−ｉｎ−ＩＰカプセル化、最小カプセル化、またはソースルーティング等のルーティング規格を使用して経路に沿って他の公知の並列通信トランシーバにデータパケットを向けるように命令されてよい。

ステップ１４４は、経路ごとの機能性と接続ごとの機能性にネットワーク機能性を分断することを含んでよい。経路ごとの機能性は使用可能レート、遅延の推定、損失の推定、および輻輳制御を含んでよく、接続ごとの機能性はフロー制御、接続管理、および接続信頼性を含んでよい。分断はトリガに基づいてセッションを作成することも含んでよく、該セッションは経路ごとの機能性を維持するためのコアエンジンと、経路ごとの機能性を維持するための少なくとも１つの経路エンジンとを含む。データ構造は経路および接続ごとに維持されてよい。

ステップ１４６は、経路特性を繰り返し決定することによって複数の並列経路の各々を特徴付けることを含んでよい。特に、経路特性はある特定の経路で送信されるデータのために、帯域幅、遅延、ジッタ、損失率、コストおよびセキュリティの瞬間、平均、分散のいずれか１つの測定値であってよい。

ステップ１４８は、目的関数を達成するために複数の並列データ経路全体でデータの送信のスケジューリングを行うことを含んでよく、このスケジューリングは経路特性、高位の層のプロトコルまたは特定のアプリケーションに基づいてよい。目的関数は、帯域幅、遅延、ジッタ、損失、セキュリティ、障害許容力またはコストのレベルを接続に与えることを含んでよい。

スケジューリングステップは、複数の並列データ通信経路の各々で送信されるデータの到着時刻および／または到着確率を予測することと、次に所定の同期の程度の範囲内で受信側ノードのデータの到着時刻を同期させることも含んでよい。例えば、スケジューリングステップは、宛先で受信される複数の並列データ通信経路の第１の経路に沿ってデータの送信のスケジューリングを行うことを含んでよい。スケジューリングステップは、複数の並列データ通信経路の第２の経路に沿ってデータの第２の送信のスケジューリングを行うことも含んでよい。データの該第２の送信は、第１のパケットに関して所定のシーケンスで受信側ノードで受信されるようにスケジューリングされてよい。

ステップ１５０では、並列経路上で送信されるデータは、受信側ノードでは例えばオリジナルのデータ通信を形成するために集約演算され、再構築されてよい。例えば、データの受信された第１の送信と第２の送信は、所定のシーケンスから外れて第１の送信と第２の送信を受信したとき、および高位の層のプロトコルが、第１の送信と第２の送信が所定のシーケンスで配信されることを必要とすると判断したときにのみ再構築されてよい。

ステップ１５２では、受信された（および場合によっては再構築された）データが次に宛先エンドポイントに送信されてよい。

説明された並列通信システムおよび方法の実施形態は、多くの方法で配備されてよい。例えば、システムおよび方法は、エンドポイントクライアントとサーバ上のクライアントとサーバカーネルスペースソフトウェア上のユーザスペースライブラリとして、スタンドアロンネットワークエレメントとして、または埋め込まれたネットワークエレメントとして実現されてよい。

図１から図３の並列通信システムの実施形態はスタンドアロンネットワークエレメントを備える並列通信トランシーバの中のインプリメンテーションの例である。説明された並列通信システムのこの配備は、それが（利用されるネットワークリソースのいずれかの側でスタンドアロンネットワークエレメントを物理的に挿入するため以外）通信エンドポイントまたはレガシーネットワークインフラストラクチャに対する変更を必要としないという点で有利である場合がある。システムおよび方法は、中間並列通信トランシーバを有する通信エンドポイント間に存在する多数の経路を利用する。リソースを集める、および各エンドポイントで実行されるアプリケーションに単一のリソースの要約を実現する並列通信トランシーバの機能のために、既存のネットワークエレメントは再構成される、あるいは並列通信トランシーバの存在を認識することを必要とされない。

説明されたシステムおよび方法は、使用される特殊ネットワーク技術を選ばず、設置されている既存のネットワークアプリケーションに変更を必要としない。該システムおよび方法は、規定のネットワーク環境で可能な並列処理の程度を動的に特徴付けてよく、ネットワークを使用するアプリケーションに並列処理性能を届ける。該システムおよび方法は設定された目的関数に適応することができ、ネットワーク内のエンドシステムでの単純なソフトウェアダウンロードから、ネットワークエレメント自体と完全に統合されることに及ぶ柔軟な配備戦略を含む。

多くの変形および変型が前述の実施形態になされてよいことが強調される必要がある。すべてのこのような変型および変形は、本開示の範囲内でここに含まれ、以下の請求項によって保護されることを目的とする。
（関連出願の相互参照）
本願は、その全体として参照することにより組み込まれている、出願番号第６０／５４６，０３４号を割り当てられ、２００４年２月１９日に出願された「通信システムの中の並列リソースを動的に発見し、特徴付けし、集約するための手法（Ａｐｐｒｏａｃｈｅｓ ｔｏ Ｄｙｎａｍｉｃａｌｌｙ Ｄｉｓｃｏｖｅｒ，Ｃｈａｒａｃｔｅｒｉｚｅ，ａｎｄ Ａｇｇｒｅｇａｔｅ Ｐａｒａｌｌｅｌ Ｒｅｓｏｕｒｃｅｓ Ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍｓ）」と題される米国仮特許出願に対する優先権およびその利点を主張する。

複数の並列通信経路上でのデータの通信を行うことができる例示的な並列通信システムの実施形態を描く。 図１のネットワーク内で並列通信を提供するために使用される並列ネットワーキングトランシーバの実施形態のブロック図を描く。 複数の並列通信経路を活用するために、図２に描かれているように複数の並列ネットワーキングトランシーバを有する複数の遠隔オフィスサイトに及ぶ企業ＷＡＮの実施形態を描く。 複数の並列通信経路上でデータを通信するためのステップを含む例示的な方法の実施形態を描く。

Claims (51)

1. 並列データ経路上でデータを通信する方法であって、
   経路特性を繰り返し決定することによって複数の並列データ経路の各々を特徴付け、前記複数の並列データ経路が送信側ノードと受信側ノードの単一の仮想接続を定めており、
   目的関数を達成するために前記複数の並列データ経路のデータ送信のスケジューリングを行い、前記スケジューリングが前記経路特性に基づいている、
   並列データ経路上でデータを通信する方法。
2. データ送信のスケジューリングを行うことは、
   前記受信側ノードで受信される前記複数の並列データ通信経路の第１の経路に沿ってデータの第１の送信のスケジューリングを行い、
   前記複数の並列データ通信経路の第２の経路に沿ってデータの第２の送信のスケジューリングを行い、データの前記第２の送信が、前記第１のパケットに関連して所定のシーケンスで前記受信側ノードで受信されるようにスケジューリングされる、
   ことをさらに含む、
   請求項１に記載の方法。
3. 前記所定のシーケンスから外れて前記第１の送信と第２の送信を受信するとき、および、
   前記第１の送信と第２の送信が前記所定のシーケンスで配信されることを、高位の層のプロトコルが必要とすると判断するとき、
   にのみ前記受信側ノードでデータの前記受信された第１の送信と第２の送信を再構築する、
   ことをさらに含む請求項１に記載の方法。
4. 前記複数の並列データ通信経路の各々で送信されるデータの到着時刻を予測する、
   ことをさらに含む請求項１に記載の方法。
5. 前記複数の並列データ通信経路の各々で送信されるデータの到着確率を予測する、
   ことをさらに含む請求項４に記載の方法。
6. 所定の同期の程度の範囲内で前記受信側ノードでデータの前記到着時刻を同期させる、
   ことをさらに含む請求項４に記載の方法。
7. 受信側並列通信トランシーバが肯定応答パケットを送信するための要求を備えるデータパケットをブロードキャストし
   前記受信された並列通信トランシーバから肯定応答パケットを受信する、
   ことをさらに含む請求項１に記載の方法。
8. 前記受信側並列通信トランシーバへの少なくとも１つの経路を要約する、
   ことをさらに含む請求項７に記載の方法。
9. 送信側並列通信トランシーバと受信側並列通信トランシーバを発見するためにデータトラフィックをモニタし、
   前記送信側並列通信トランシーバと前記受信側並列通信トランシーバの間で少なくとも１つの経路を要約する、
   ことをさらに含む請求項１に記載の方法。
10. ネットワーク機能性を経路ごとの機能性と接続ごとの機能性に要約する、
    ことをさらに含む請求項１に記載の方法。
11. トリガに基づいてセッションを作成し、前記セッションが、前記経路ごとの機能性を維持するコアエンジンと、前記経路ごとの機能性を維持する少なくとも１つの経路エンジンを含む、
    ことをさらに含む請求項１０に記載の方法。
12. 前記複数の並列データ経路各々のためのデータ構造を維持する、
    ことをさらに含む請求項１０に記載の方法。
13. 前記経路ごとの機能性が、使用可能レートの推定、遅延の推定、損失の推定、および輻輳制御から成るグループより選択される、
    請求項１０に記載の方法。
14. 前記接続ごとの機能性は、フロー制御、接続管理および接続信頼性から成るグループより選択される、
    請求項１０に記載の方法。
15. 前記目的関数は、スループット、帯域幅、遅延、ジッタ、損失率、セキュリティ、信頼性、障害許容力、またはコストの１つ以上のレベルとの仮想接続を提供している、
    請求項１に記載の方法。
16. 前記経路特性が、特定の経路上で送信されるデータのスループット、帯域幅、遅延、ジッタ、損失率、コスト、セキュリティ、信頼性、障害許容力、またはコストの瞬間、平均および分散の１つ以上の測定値である、
    請求項１に記載の方法。
17. スケジューリングを行うことが、さらに高位の層のネットワークプロトコルまたはアプリケーションの認識にさらに基づく、
    請求項１に記載の方法。
18. 複数の既知の並列通信トランシーバにパケットを繰り返し送信し、前記データの送信を受信するために前記既知の並列通信トランシーバの可用性を決定する、
    ことをさらに含む請求項１に記載の方法。
19. 中間並列通信トランシーバに、ＩＰ−ｉｎ−ＩＰカプセル化、最小ＩＰカプセル化、およびソースルーティングから成るグループより選択されるルーティング規格を使用して他の既知の並列通信トランシーバにデータパケットを向けるように命令する、
    ことをさらに含む請求項１に記載の方法。
20. 前記複数の並列データ経路のデータ送信のスケジューリングを行うことは、
    前記受信側ノードへの送信のためにデータのスケジューリングを行い、前記受信側ノードが並列通信トランシーバと宛先エンドポイントから成るグループより選択される、
    ことをさらに含む請求項１に記載の方法。
21. 並列データ経路上でデータを通信するシステムであって、
    経路特性を繰り返し決定することにより複数の並列データ経路の各々を特徴付ける手段であって、前記複数の並列データ経路が、送信側ノードと受信側ノードの間の単一仮想接続を定める、手段と、
    目的関数を成立させるために前記複数の並列データ経路全体でデータの前記送信のスケジューリングを行う手段であって、前記スケジューリングが前記経路特性に基づく手段と、
    を備えるシステム。
22. 前記送信データのスケジューリングを行う手段が、
    前記受信側ノードで受信される前記複数の並列データ通信経路の第１の経路に沿ってデータの第１の送信のスケジューリングを行う手段と、
    前記複数の並列データ通信経路の内の第２の経路に従ってデータの第２の送信のスケジューリングを行う手段であって、データの前記第２の送信が、前記第１のパケットに関連して所定のシーケンスで前記受信側ノードで受信されるようにスケジューリングを行う、手段と、
    をさらに含む請求項２１に記載のシステム。
23. 前記所定のシーケンスから外れて前記第１の送信および第２の送信を受信するとき、および、
    高位の層のプロトコルが、前記第１の送信と第２の送信が、前記所定のシーケンスで配送されると判断するとき、
    にのみ前記受信側ノードでデータの前記受信された第１の送信と第２の送信を再構築する手段、
    をさらに含む請求項２１に記載のシステム。
24. 前記複数の並列データ通信経路の各々で送信されるデータの到着時刻を予測する手段、
    をさらに含む請求項２１に記載のシステム。
25. 前記複数の並列データ通信経路の各々で送信されるデータの到着確率を予測する手段、
    をさらに含む請求項２４に記載のシステム。
26. 所定の程度の同期範囲内で前記受信側ノードの前記到着時刻を同期させる手段、
    をさらに含む請求項２４に記載のシステム。
27. 受信側並列通信トランシーバが肯定応答パケットを送信するための要求を備えるデータパケットをブロードキャストする手段と、
    前記受信側並列通信トランシーバから肯定応答パケットを受信する手段と、
    をさらに含む請求項２１に記載のシステム。
28. 前記受信側並列通信トランシーバへの少なくとも１つの経路を要約する手段、
    をさらに含む請求項２７に記載のシステム。
29. 送信側並列通信トランシーバと受信側並列通信トランシーバを発見するためにデータトラフィックをモニタする手段と、
    前記送信側並列通信トランシーバと前記受信側並列通信トランシーバの間で少なくとも１つの経路を要約する手段と、
    をさらに含む請求項２１に記載のシステム。
30. 経路ごとの機能性および接続ごとの機能性にネットワーク機能性を分断する手段、
    をさらに含む請求項２１に記載のシステム。
31. トリガに基づいてセッションを作成する手段をさらに含み、
    前記セッションが前記経路ごとの機能性を維持するコアエンジンと、前記経路ごとの機能性を維持する少なくとも１つの経路エンジンと、を含む、
    請求項３０に記載のシステム。
32. 前記複数の並列データ経路の各々のためにデータ構造を維持する手段、
    をさらに含む請求項３０に記載のシステム。
33. スケジューリングを行う手段が、さらに高位の層のネットワークプロトコルまたはアプリケーションに関する認識に基づいている請求項２２に記載のシステム。
34. 複数の既知の並列通信トランシーバにパケットを繰り返し送信し、前記データの前記送信を受信するために、前記既知の並列通信トランシーバの可用性を決定する手段、
    をさらに含む請求項２１に記載のシステム。
35. 中間並列通信トランシーバに、ＩＰ−ｉｎ−ＩＰカプセル化、最小カプセル化、およびソースルーティングから成るグループより選択されるルーティング規格を使用して他の既知の並列通信トランシーバに、データパケットを向けるように命令する手段、
    をさらに含む請求項２１に記載のシステム。
36. 前記複数の並列データ経路全体でデータの前記送信のスケジューリングを行う前記手段が、
    前記受信側ノードへの送信のために前記データのスケジューリングを行う手段、
    をさらに含み、
    前記受信側ノードが、並列通信トランシーバと宛先エンドポイントから成る前記グループより選択される、
    請求項２０に記載のシステム。
37. 並列データ経路上でデータを通信するシステムであって、
    命令実行システムから命令をフェッチし、実行するように構成されるプロセッサを備え、
    前記命令が、
    経路特性を繰り返し決定することによって複数の並列データ経路の各々を特徴付ける命令であって、前記複数の並列データ経路が送信側ノードと受信側ノードの間で単一の仮想接続を定める、命令と、
    目的関数を達成するために前記複数の並列データ経路全体でデータの前記送信のスケジューリングを行う命令であって、前記スケジューリングが前記経路特性に基づく、命令と、
    を含み、
    前記送信のスケジューリングを行う前記命令が、
    前記受信側ノードで受信される前記複数の並列データ通信経路の内の第１の経路に沿ってデータの第１の送信のスケジューリングを行う命令と、
    前記複数の並列データ通信経路の第２の経路に沿ってデータの第２の送信のスケジューリングを行う命令であって、データの前記第２の送信が前記第１のパケットに関連して所定のシーケンスで前記受信側ノードで受信される、命令と、
    をさらに含む、
    システム。
38. 前記命令が、
    前記所定のシーケンスから外れて前記第１の送信と第２の送信を受信するとき、および、
    高位の層のプロトコルが、前記第１の送信と第２の送信が前記所定のシーケンスで送達されることを必要とすると判断するとき、
    にのみ前記受信側ノードでデータの前記受信された第１の送信と第２の送信を再構築する命令、
    をさらに含む、
    請求項３７に記載のシステム。
39. 前記命令が、
    前記複数の並列データ通信経路の各々で送信されるデータの到着時刻を予測する命令、
    をさらに含む
    請求項３７に記載のシステム。
40. 前記命令が、
    前記複数の並列データ通信経路の各々で送信されるデータの到着確率を予測する命令、
    をさらに含む、
    請求項３９に記載のシステム。
41. 前記命令が、
    所定の同期程度の範囲内で前記受信側ノードでデータの前記到着時刻を同期する命令、
    をさらに含む、
    請求項３９に記載のシステム。
42. 前記命令が、
    受信側並列通信トランシーバが肯定応答パケットを送信するための要求を備えるデータパケットをブロードキャストする命令と、
    前記受信側並列通信トランシーバから肯定応答パケットを受信する命令と、
    をさらに含む、
    請求項３７に記載のシステム。
43. 前記命令が、
    前記受信側並列通信トランシーバへの少なくとも１つの経路を要約する命令、
    をさらに含む、
    請求項４２に記載のシステム。
44. 前記命令が、
    送信側並列通信トランシーバと受信側並列通信トランシーバを発見するためにデータトラフィックをモニタする命令と、
    前記送信側並列通信トランシーバと前記受信側並列通信トランシーバの間の少なくとも１つの経路を要約する命令と、
    をさらに含む、
    請求項３７に記載のシステム。
45. 前記命令が、
    ネットワーク機能性を経路ごとの機能性と接続ごとの機能性に分断する命令、
    をさらに含む、
    請求項３７に記載のシステム。
46. 前記命令が、
    トリガに基づいてセッションを作成する命令、
    をさらに含み、
    前記セッションが前記経路ごとの機能性を維持するコアエンジンと、前記経路ごとの機能性を維持する少なくとも１つの経路エンジンと、を含む、
    請求項４５に記載のシステム。
47. 前記命令が、
    前記複数の並列データ経路の各々のためのデータ構造を維持する命令、
    をさらに含む、
    請求項４５に記載のシステム。
48. 前記複数の並列データ経路全体でデータの送信のスケジューリングを行う前記命令が、高位の層のネットワークプロトコルまたはアプリケーションの認識にさらに基づく請求項３７に記載のシステム。
49. 前記命令が、
    複数の既知の並列通信トランシーバに繰り返しパケットを送信する命令、
    をさらに含み、
    前記データの前記送信を受信するために前記既知の並列通信トランシーバの可用性を決定する、
    請求項３７に記載のシステム。
50. 前記命令が、
    ＩＰ−ｉｎ−ＩＰカプセル化、最小ＩＰカプセル化、およびソースルーティングから成るグループより選択されるルーティング規格を使用して他の既知の並列通信トランシーバにデータパケットを向ける命令、
    をさらに含む、
    請求項３７に記載のシステム。
51. 前記複数のデータ経路全体でデータの前記送信のスケジューリングを行う前記命令が、
    前記受信側ノードへの送信のために前記データのスケジューリングを行う命令、
    をさらに含み、
    前記受信側ノードが並列通信トランシーバと宛先エンドポイントとから成る前記グループより選択される、
    請求項３７に記載のシステム。

Images