(57)【特許請求の範囲】
【請求項１】
第１のネットワークに接続されたトンネル終端装置が、前記第１のネットワークに接続された装置から送信されたパケットにヘッダを付加し、前記第１のネットワークとは異なる第２のネットワークを介して、前記第１，２のネットワークとは異なる第３のネットワークのトンネル終端装置へ送信する送信方法であって、
前記第１のネットワークに接続された装置から送信されたパケットを受信手段が受信する受信工程と、
前記受信されたパケットに含まれるヘッダ情報に設定されている該パケットのプロトコルをプロトコル判定手段が判定するプロトコル判定工程と、
前記第２のネットワークの品質を品質判定手段が判定する品質判定工程と、
前記判定されたプロトコルと品質との組み合わせに対して予め設定されたプロトコルを、前記受信されたパケットを送信するためのプロトコルとして決定手段が決定する決定工程と、
前記受信されたパケットに前記決定工程で決定されたプロトコルに応じたヘッダを付加した該パケットを、送信手段が前記第２のネットワークを介して前記第３のネットワークのトンネル終端装置へ送信する送信工程と
を備えることを特徴とする送信方法。
【請求項２】
前記品質判定工程では輻輳の発生の有無を判定し、
前記決定工程では、
前記輻輳が発生していないと前記品質判定工程で判定された場合、前記受信工程で受信したＵＤＰパケットの少なくとも一部をＴＣＰプロトコルで送信すると決定し、
前記輻輳が発生していると前記品質判定工程で判定された場合、前記受信工程で受信したＵＤＰパケットの少なくとも一部をＵＤＰプロトコルで送信すると決定する
ことを特徴とする請求項１記載の送信方法。
【請求項３】
前記決定工程では、
ＵＤＰパケットを送信するためのプロトコルとして前記決定工程でＵＤＰプロトコルを決定した後に前記品質判定工程で判定した前記第２のネットワークの品質に応じて、ＵＤＰパケットを送信するためのプロトコルとしてＴＣＰプロトコルを決定した後に受信した複数のＵＤＰパケットのうち、第１のＵＤＰパケットがＴＣＰプロトコルで送信され、第２のＵＤＰパケットがＵＤＰプロトコルで送信されるように、パケットを送信するためのプロトコルを決定することを特徴とする請求項２記載の送信方法。
【請求項４】
前記品質判定工程では前記第２のネットワークにおけるパケット誤り率を判定し、
前記決定工程では、
前記輻輳が発生していないと判定され、且つ、前記パケット誤り率が閾値よりも低いと判定された場合、前記受信工程で受信したＵＤＰパケットの少なくとも一部をＵＤＰプロトコルで送信すると決定し、
前記輻輳が発生していないと判定され、且つ、前記パケット誤り率が前記閾値以上であると判定された場合、前記受信工程で受信したＵＤＰパケットの少なくとも一部をＴＣＰプロトコルで送信すると決定する
ことを特徴とする請求項１記載の送信方法。
【請求項５】
前記品質判定工程では、前記第３のネットワークへ送信されたパケットの再送率を判定し、
前記決定工程では、
前記再送率が閾値よりも低いと判定された場合、前記受信工程で受信したＴＣＰパケットの少なくとも一部をＴＣＰプロトコルで送信すると決定し、
前記再送率が前記閾値以上であると判定された場合、前記受信工程で受信したＴＣＰパケットの少なくとも一部をＵＤＰプロトコルで送信すると決定する
ことを特徴とする請求項１記載の送信方法。
【請求項６】
第１のネットワークに接続された装置から送信されたパケットにヘッダを付加し、前記第１のネットワークとは異なる第２のネットワークを介して、前記第１，２のネットワークとは異なる第３のネットワークのトンネル終端装置へ送信する、前記第１のネットワークに接続されているトンネル終端装置であって、
前記第１のネットワークに接続された装置から送信されたパケットを受信する受信手段と、
前記受信されたパケットに含まれるヘッダ情報に設定されている該パケットのプロトコルを判定するプロトコル判定手段と、
前記第２のネットワークの品質を判定する品質判定手段と、
前記判定されたプロトコルと品質との組み合わせに対して予め設定されたプロトコルを、前記受信されたパケットを送信するためのプロトコルとして決定する決定手段と、
前記受信されたパケットに前記決定手段が決定したプロトコルに応じたヘッダを付加した該パケットを、前記第２のネットワークを介して前記第３のネットワークのトンネル終端装置へ送信する送信手段と
を備えることを特徴とするトンネル終端装置。
【請求項７】
前記品質判定手段は輻輳の発生の有無を判定し、
前記決定手段は、
前記輻輳が発生していないと前記品質判定手段で判定された場合、前記受信手段で受信したＵＤＰパケットの少なくとも一部をＴＣＰプロトコルで送信すると決定し、
前記輻輳が発生していると前記品質判定手段で判定された場合、前記受信手段で受信したＵＤＰパケットの少なくとも一部をＵＤＰプロトコルで送信すると決定する
ことを特徴とする請求項６記載のトンネル終端装置。
【請求項８】
前記決定手段は、
ＵＤＰパケットを送信するためのプロトコルとして前記決定手段でＵＤＰプロトコルを決定した後に前記品質判定手段で判定した前記第２のネットワークの品質に応じて、ＵＤＰパケットを送信するためのプロトコルとしてＴＣＰプロトコルを決定した後に受信した複数のＵＤＰパケットのうち、第１のＵＤＰパケットがＴＣＰプロトコルで送信され、第２のＵＤＰパケットがＵＤＰプロトコルで送信されるように、パケットを送信するためのプロトコルを決定することを特徴とする請求項７記載のトンネル終端装置。
【請求項９】
前記品質判定手段は前記第２のネットワークにおけるパケット誤り率を判定し、
前記決定手段は、
前記輻輳が発生していないと判定され、且つ、前記パケット誤り率が閾値よりも低いと判定された場合、前記受信手段で受信したＵＤＰパケットの少なくとも一部をＵＤＰプロトコルで送信すると決定し、
前記輻輳が発生していないと判定され、且つ、前記パケット誤り率が前記閾値以上であると判定された場合、前記受信手段で受信したＵＤＰパケットの少なくとも一部をＴＣＰプロトコルで送信すると決定する
ことを特徴とする請求項６記載のトンネル終端装置。
【請求項１０】
前記品質判定手段は、前記第３のネットワークへ送信されたパケットの再送率を判定し、
前記決定手段は、
前記再送率が閾値よりも低いと判定された場合、前記受信手段で受信したＴＣＰパケットの少なくとも一部をＴＣＰプロトコルで送信すると決定し、
前記再送率が前記閾値以上であると判定された場合、前記受信手段で受信したＴＣＰパケットの少なくとも一部をＵＤＰプロトコルで送信すると決定する
ことを特徴とする請求項６記載のトンネル終端装置。
【請求項１１】
コンピュータを、請求項６乃至１０の何れか１項に記載のトンネル終端装置が有する各手段として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークの分野に関する。
【０００２】
本発明は、特に、通信ネットワークを通過するトンネルにおけるデータパケット（データグラムとも呼ばれる）の送信技術に関する。
【背景技術】
【０００３】
一方では高ビットレートインターネットの大衆化及び他方ではネットワーク接続性を有する消費者向け音声映像機器の普及により、ユーザは新しい形態の行動を取るだろう。これらの新しい形態の行動は、「永続リンク」グループと呼ぶ共通の関心（余暇、家族等）を有する人達のグループに属する個人の登場に確実に関係する。これらグループは、同一の関心分野の他の個人との略永続的な接続をセットアップすることにより、音声及び／又は映像通信をセットアップし、全ての種類の情報（音声、映像、写真、テキスト等）を共有する。
【０００４】
仮想プライベートネットワーク（ＶＰＮ）の技術は、この期待に対する価値ある解決策を提供している。ＶＰＮにより、同一の関心分野を共有する個人間でセキュリティ保護された方法でリアルタイムの透過的な通信が可能になるが、それと同時にＶＰＮは、信頼性が低いが安価なインターネットインフラストラクチャを使用する。
【０００５】
透過的に通信し、転送不可能なアドレスの必要性を克服するために、ＶＰＮは、トンネルと呼ばれるものを作成するトンネリングとして周知の特定の種類のカプセル化を使用する。この動作は、カプセル化プロトコルＣを使用してＢレベルのプロトコル（転送プロトコル）にＡレベルのプロトコル（パッセンジャープロトコル）をカプセル化することから成る。Ｂは、各層及びそれらの対話により提供されるサービスを記述するＩＳＯモデル等の階層モデルにおけるＡの層以上の層（レベル）のプロトコルである。
【０００６】
従って、転送プロトコルは、パッセンジャープロトコルをペイロードデータであるかのように処理する。以下に詳細に説明する図２ｂは、レベル２のＶＰＮ、すなわちレベル２トンネル（レベル２トンネルは、パッセンジャープロトコルがＩＳＯモデルのレイヤ２のプロトコルであることを意味する）におけるカプセル化の一例を示す。
【０００７】
トンネリングは、ネットワークプロトコルをサポートしないネットワーク上でネットワークプロトコルを転送するために使用されてもよい。また、トンネリングは、プライベートアドレス指定等の種々のＶＰＮ機能を提供するために使用される。
【０００８】
トンネリング技術は、リモートアクセスを伴う消費者機能及びホームローカルエリアネットワーク（ＬＡＮ）により益々使用されるようになってきている。
【０００９】
本明細書の以下の説明において、トランスポート層のレベルが４（すなわち、少なくともＩＳＯモデルにおけるトランポート層のレベル）以上であるレベル２又はレベル３トンネルを一例として個別に考慮する。
【００１０】
２つの元のＬＡＮの結合により形成される仮想ローカルエリアネットワークを作成するために、ＶＰＮは２つのＬＡＮを相互接続するのによく使用される。セキュリティ保護されたＶＰＮは、転送データの秘密性を保証するための暗号化／認証アルゴリズムを含む。トンネリング技術に基づく通常のＶＰＮ構成を図１ａ（以下に詳細に説明する）に示す。この例において、トンネル終端はゲートウェイに組み込まれない。トンネルは、２つのトンネル終端間にセットアップされ、リモートＬＡＮに接続される装置に送出される各パケット（フレームとも呼ばれる）は、ローカルトンネル終端によりカプセル化され、リモートトンネル終端に送出される。リモートトンネル終端はそれを非カプセル化し、リモートＬＡＮ上に送出する。装置は、仮想的に同一のＬＡＮに接続される。トンネルを介する２つの装置間の通信は終端間通信と呼ばれる。
【００１１】
２つのトンネル終端間のトンネルをセットアップする場所を決定する場合に発生する最初の課題の１つは、そのトンネルの転送プロトコルとなるべきものを認識することである。
【００１２】
従来技術において、使用されるのは、主にレイヤ３ＩＰ（インターネットプロトコル）又はレイヤ４ＴＣＰ／ＵＤＰ（伝送制御プロトコル／ユーザデータグラムプロトコル）である。ＩＰを使用するトンネリング技術がネットワークアドレス変換（ＮＡＴ）機構を考慮できず、それら技術が図１の通常のトンネリング構成に完全に準拠しないため、以下の説明においては、レイヤ４（トランスポート層）、すなわちＴＣＰ又はＵＤＰに基づく解決策を考慮する（単なる一例として）。
【００１３】
ＴＣＰプロトコルは、送信者のデータが有効に受信され（肯定応答の管理）且つ全てのフレームが所定の順番で受信されることを送信者に対して保証する接続指向高信頼プロトコルである。ＴＣＰは、効率的な輻輳制御機構を適用する。
【００１４】
ＵＤＰプロトコルは、フレームの順番を考慮せず且つ肯定応答を管理しない非常に単純で高速なプロトコルである。
【００１５】
この特定の例（単に一例として示す）においては、上述の課題は、トンネルに対する転送プロトコルとしてＴＣＰプロトコル及びＵＤＰプロトコルのいずれを使用すべきかを認識することになる。
【００１６】
課題は、パッセンジャープロトコルにおいて使用されるデータに対応するプロトコルがトンネルの転送プロトコルにおいて実現される機構を干渉する可能性があることである。例えば、ＴＣＰを転送（トランスポート）プロトコルとし、ＴＣＰをパッセンジャープロトコルのペイロードデータに対応するプロトコルとする（TCP over TCPとして周知の組合せ）場合、２つのＴＣＰ輻輳制御機構間の非建設的な対話に直面する。更なる詳細については、特に「Understanding TCP over TCP: effects of TCP tunnelling on end-to-end throughput and latency (O Honda, H Ohsaki, M. Imase, M. Ishizuka, J. Murayama).  (Proceedings of the SPIE, volume 6011, pp 138-146 (Oct 2005))」を参照してもよい。
【００１７】
最初の反応は、TCP over TCPの組合せは適切な解決策ではない、というものだろう。しかし、特定の状況において、この種のトンネリングが終端間の性能を低下することが周知であるとしても、他の状況下では同一の組合せが終端間性能を向上する（例えば、上述の文献及び文献「Avoiding congestion collapse on the Internet using TCP tunnels (B.P. Lee, R.K. Balan, L. Jacob, W.K.G Seah, A.L Ananda) (Computer Networks 39 (2002) pages 207-219, Dec 2002)」を参照）。「UDP over UDP」の組合せ、すなわちＵＤＰプロトコルを転送プロトコルとし、ＵＤＰプロトコルをパッセンジャープロトコルとする場合にも同一の課題が発生する。
【００１８】
従って、このことは実質的に以下の３つの要因に依存するため、上述の課題（すなわち、トンネルにおいて使用される転送プロトコルはどちらか）に対する絶対的な対応はない：
−トンネルを介して送信されるデータの種類（パッセンジャープロトコルのペイロードデータに対応するプロトコル、アプリケーションの種類（ファイル、音声及び／又は映像ストリームの転送等））
−２つのトンネル終端間のネットワークの品質（フレーム損失又は破損、輻輳等に対する）
−ユーザ及び／又は管理者の基本設定（帯域幅、信頼性、ジッタ等に対する）
現在、２つのトンネル終端間にトンネルをセットアップすることを決定した場合、全ての状況において最適であるわけではないが、転送プロトコルの所定の選択（すなわち、各チャネルが別個の転送プロトコルを使用する場合にはトンネルにおけるチャネルの所定の選択）を必ず行なう必要がある。
【００１９】
２つの仮想プライベートネットワーク（ＶＰＮ）、すなわち制御データに対する第１のトンネル（２つのＩＰアドレス間の）及びペイロードデータに対する第２のパネル（２つの他のＩＰアドレス間の）の２つのトンネルを使用する周知の方法が存在し、それは米国特許第６，６１４，８００号公報において説明される。この技術により、制御データに対する第１の転送プロトコル及びペイロードデータに対する第２の転送プロトコルの選択が可能になる。２種類のデータは２つの別個のトンネルを通過する。従って、転送プロトコルの選択は２つのチャネルの各々において最適化されてもよい。
【００２０】
しかし、この技術は２つの主な欠点を有する。すなわち、この技術は２つのトンネル（２組のＩＰアドレス）を必要とし、各種類のデータ（制御データ及びペイロードデータ）は常に同一の転送プロトコルを使用することである。従って、考慮されるデータの種類に対して、選択が全ての状況において最適化されるわけではない（以下において、説明に戻る）。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明の目的は、少なくとも１つの実施形態において、特に従来技術の種々の欠点を克服することである。
【００２２】
より詳細には、本発明の目的は、本発明の少なくとも１つの実施形態において、転送チャネルの選択が最適化されるトンネルにおけるデータパケット送信の技術を提供することである。
【００２３】
本発明の別の目的は、少なくとも１つの実施形態において、トンネルのチャネルにおける送信の劣化の原因となる可能性のあるそのチャネル上で送信されるデータの品質の突然の変化を防止することである。
【００２４】
本発明の少なくとも１つの実施形態の目的は、実現するのが容易で且つコストが安価なその種の技術を提供することである。
【００２５】
本発明の少なくとも１つの実施形態の更に別の目的は、トンネル終端において実現され且つそれ故に発信機器及び宛先機器に対して透過的であるその種の技術を提供することである。
【課題を解決するための手段】
【００２６】
本発明の目的を達成するために、例えば、本発明の送信方法は以下の構成を備える。即ち、第１のネットワークに接続されたトンネル終端装置が、前記第１のネットワークに接続された装置から送信されたパケットにヘッダを付加し、前記第１のネットワークとは異なる第２のネットワークを介して、前記第１，２のネットワークとは異なる第３のネットワークのトンネル終端装置へ送信する送信方法であって、前記第１のネットワークに接続された装置から送信されたパケットを受信手段が受信する受信工程と、前記受信されたパケットに含まれるヘッダ情報に設定されている該パケットのプロトコルをプロトコル判定手段が判定するプロトコル判定工程と、前記第２のネットワークの品質を品質判定手段が判定する品質判定工程と、前記判定されたプロトコルと品質との組み合わせに対して予め設定されたプロトコルを、前記受信されたパケットを送信するためのプロトコルとして決定手段が決定する決定工程と、前記受信されたパケットに前記決定工程で決定されたプロトコルに応じたヘッダを付加した該パケットを、送信手段が前記第２のネットワークを介して前記第３のネットワークのトンネル終端装置へ送信する送信工程とを備えることを特徴とする。
【００２７】
本発明の目的を達成するために、例えば、本発明のトンネル終端装置は以下の構成を備える。即ち、第１のネットワークに接続された装置から送信されたパケットにヘッダを付加し、前記第１のネットワークとは異なる第２のネットワークを介して、前記第１，２のネットワークとは異なる第３のネットワークのトンネル終端装置へ送信する、前記第１のネットワークに接続されているトンネル終端装置であって、前記第１のネットワークに接続された装置から送信されたパケットを受信する受信手段と、前記受信されたパケットに含まれるヘッダ情報に設定されている該パケットのプロトコルを判定するプロトコル判定手段と、前記第２のネットワークの品質を判定する品質判定手段と、前記判定されたプロトコルと品質との組み合わせに対して予め設定されたプロトコルを、前記受信されたパケットを送信するためのプロトコルとして決定する決定手段と、前記受信されたパケットに前記決定手段が決定したプロトコルに応じたヘッダを付加した該パケットを、前記第２のネットワークを介して前記第３のネットワークのトンネル終端装置へ送信する送信手段とを備えることを特徴とする。
【００２８】
このように、使用される有効チャネル（及び従って転送プロトコル）は常に最適である。
【００２９】
尚、有効伝送チャネルを選択するステップは、発信元から到着するデータパケットの種類（すなわち、そのパケットに含まれるペイロードデータのプロトコル）及びネットワーク上での送信の品質に関する返信情報の双方に基づく。
【００３０】
現在の送信状態に関連する転送品質に関する前記情報は、以下を含むグループに属するのが有利である：
−前記伝送チャネルの輻輳に関する情報（ＥＣＮ）；
−前記伝送チャネルに対するパケット誤り率（ＰＥＲ）に関する情報；
−前記伝送チャネルの再送率（ＴＣＰチャネル再送率）に関する情報。
【００３１】
チャネルの選択の基準は、このリストの１つ以上の組み合わされた要素に基づいてもよい。このリストは網羅的ではない。
【００３２】
ネットワークの輻輳に関する情報に対しては、例えば、特に「RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP」に説明されるようなＥＣＮ（明示的輻輳通知）を使用する。
【００３３】
パケット誤り率は、ＰＥＲとしても周知である。
【００３４】
有効チャネルを選択する前記ステップｂ）は以下のステップを含むのが有利である：
ｉ）パケットの各種類がパケットの前記種類を処理するパケットに含まれるペイロードデータに関係する別個のプロトコルにより規定され、前記受信したパケットと関連するパケットの種類を判定するステップ；
ｉｉ）前記トンネル入力終端により送信され且つ前記受信したパケットと同一の種類である先に送信されたパケットに対して、前記先に送信されたパケットに対して取得される前記伝送チャネルに関する送信状態に関連する転送の品質に関する１つの情報の作用として最適な送信を可能にする先の優先チャネルと呼ばれる優先チャネルを判定するステップ；
ｉｉｉ）前記伝送チャネル上の現在の送信状態に関連する転送の品質に関する前記情報を取得するステップ；
ｉｖ）前記受信したパケットと関連するパケットの種類及び現在の送信状態に関連する転送の品質に関する少なくとも１つの情報の作用として前記受信したパケットの最適な送信を可能にする新しい優先チャネルと呼ばれるチャネルを選択するステップ；
ｖ）先の優先チャネル、新しい優先チャネル及び前記受信したパケットに関連するパケットの種類の作用として前記有効チャネルを選択するステップ。
【００３５】
有効伝送チャネルが新しい優先チャネルとは瞬間的に異なってもよいことが重要である（例えば、ネットワーク上での送信状態の変更後に優先チャネルの変更があった場合）。
【００３６】
例えば、受信パケットがＩＰデータグラムである場合、用語「パケットに含まれるペイロードデータに関連付けられるプロトコル」は、このＩＰデータグラムのペイロードデータと関連付けられるＩＳＯモデルのトランスポート層（レベル）プロトコル（ＴＣＰ又はＵＤＰ等）を意味すると理解される。ペイロードデータと関連付けられるこのＩＳＯモデルのトランスポート層（又はレベル）プロトコルは、トンネルの各伝送チャネルと関連付けられる転送（トランスポート）プロトコルと間違われるべきではない。
【００３７】
有利な特徴によると、前記受信したパケットに関連するデータの種類に対して、先の優先チャネルが新しい優先チャネルと異なる場合、有効チャネルの選択は、前記先の優先チャネルから前記受信したパケットに関連するパケットの種類に対する前記新しい優先チャネルへの円滑な切り替えの機構の結果として行なわれる。
【００３８】
円滑な切り替えの機構は、送信の劣化の原因となるチャネル上で送信されるデータの品質の突然の変動を防止する。
【００３９】
例えば、ＵＤＰチャネルからＴＣＰチャネルへの切り替え中（すなわち、転送プロトコルがＴＣＰプロトコルであるチャネルから転送プロトコルがＵＤＰプロトコルであるチャネルへの切り替え中）、ＴＣＰチャネル上の全てのパケットがＴＣＰチャネルのＴＣＰ（輻輳）ウィンドウに準拠することを考慮せずに即座に切り替えられると、即座に送信されないパケットは遅延（又はバッファリング）され、それらパケットのＲＴＴ（ラウンドトリップタイム）を人為的に増加する。その結果、パッセンジャープロトコルがＴＣＰプロトコルである場合、破局的影響を有する特定のパケットの再送信を必然的に伴う。ＵＤＰチャネルからＴＣＰチャネルへの切り替えの予測される全ての利点が失われ、人為的な妨害を与えることにより、行なわれる全てのことが問題を悪化させることは明らかである。
【００４０】
同様に、種々の伝送チャネルがインターネットへの同一の物理アクセスを共有することを忘れるべきではないため、無制御のＴＣＰチャネルからＵＤＰチャネルへの切り替えは伝送媒体を輻輳させる。ＴＣＰチャネルからＵＤＰチャネルへの変更の場合、ＴＣＰチャネル上にバッファリングされ且つＴＣＰチャネルで送出されるように設計されたパケットは、ＵＤＰチャネル上のスループットの急な増加により非常に不利な状態になる。従って、ＴＣＰチャネルによる帯域幅の使用をＵＤＰチャネルに移すための漸進的なシステムをセットアップする必要がある。全てのパケットが新しいチャネル（ＵＤＰチャネル）で送信される時に不利な状態になるパケットがないように、そのようなシステムを使用することにより、ＴＣＰチャネル上にバッファリングされたパケットは流されるのに十分な時間を有する。
【００４１】
前記円滑な切り替え機構は、前記チャネルの各々に対する最大送信ウィンドウを管理するステップをパケットの種類毎に含み、所定の時間間隔の間に前記チャネルで送信される最大データ量を示すのが有利である。
【００４２】
従って、トンネルの各伝送チャネルは、所定の時間間隔の間にトンネル終端によりそのチャネルで送信される最大データ量を規定するための送信ウィンドウを有する。
【００４３】
有利な特徴によると、所定の時間間隔の終了後、新しい優先チャネルの最大送信ウィンドウが増加し、先の優先チャネルの最大送信ウィンドウは漸減し、新しい所定の時間間隔の間に前記チャネルで送信される新しい最大データ量を示す。
【００４４】
従って、これにより、１つのチャネル（先の優先チャネル）から別のチャネル（新しい優先チャネル）への円滑な切り替えを一般に保証するように、伝送チャネルで送信される最大データ量が時間と共に変化することが保証される。
【００４５】
優先特徴によると、有効チャネルは以下のいずれかである：
−受信パケットと関連するパケットの種類に対する前記新しい優先チャネルと関連付けられる送信ウィンドウの範囲内の前記新しい優先チャネル
−受信パケットと関連するパケットの種類に対する前記新しい優先チャネルと関連付けられる前記送信ウィンドウの範囲を超えた場合は先の優先チャネル。
【００４６】
各チャネルは、それと関連付けられる転送プロトコルにより一意に識別されるのが有利である。
【００４７】
例えば、ＴＣＰ転送プロトコル及びＵＤＰ転送プロトコルによりそれぞれ識別されるＴＣＰチャネル及びＵＤＰチャネルがある。
【００４８】
有利な変形例において、各チャネルは、それに関連付けられる転送プロトコル、並びに前記転送プロトコルの入力ポート及び出力ポートにより一意に識別される。
【００４９】
従って、いくつかのチャネルの各々を通過するパケットに対して同一の転送プロトコルと例えば種々のサービスとを使用して、それらチャネルを明確に管理できる。
【００５０】
一実施形態において、有効チャネルを選択する前記ステップは、以下の２つのチャネル間で行なわれる：
−関連する転送プロトコルがＴＣＰプロトコルであるＴＣＰチャネルと呼ばれる第１のチャネル；
−関連する転送プロトコルがＵＤＰプロトコルであるＵＤＰチャネルと呼ばれる第２のチャネル。
【００５１】
第１の特定の実施形態において、受信したパケットがＵＤＰ型のパケットである時、現在の送信状態に関連する転送の品質に関する前記情報が前記伝送チャネルの輻輳を示す場合、前記受信したパケットに対する前記新しい優先チャネルはＵＤＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が前記伝送チャネルの輻輳を示さない場合、前記受信したパケットに対する新しい優先チャネルはＴＣＰチャネルである。
【００５２】
第２の特定の実施形態において、受信したパケットがＵＤＰ型のパケットである時、現在の送信状態に関連する転送の品質に関する前記情報が前記伝送チャネルの輻輳を示す場合、前記受信したパケットの新しい優先チャネルはＵＤＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が判定された閾値（Pth）を下回るパケット誤り率（ＰＥＲ）を示す場合、前記受信したパケットに対する新しい優先チャネルはＴＣＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が前記判定された閾値（Pth）以上の前記伝送チャネルのパケット誤り率（ＰＥＲ）を示す場合、前記受信したパケットに対する新しい優先チャネルはＵＤＰチャネルである。
【００５３】
第３の特定の実施形態において、受信したパケットがＴＣＰ型のパケットである時、現在の送信状態に関連する転送の品質に関する前記情報が判定された閾値（Rth）を上回る前記伝送チャネルの再送率を示す場合、前記受信したパケットに対する新しい優先チャネルはＵＤＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が前記判定された閾値（Rth）以下の前記伝送チャネルの送信率を示す場合、前記受信したパケットに対する新しい優先チャネルはＴＣＰチャネルである。
【００５４】
新しい優先チャネルを選択するステップの他の実施形態が、本発明の範囲から逸脱せずに考えられることは明らかである。例えば、ネットワーク上での送信の品質の他の基準及び／又は上述の第１の実施形態、第２の実施形態及び第３の実施形態において使用される基準の他の組合せを使用できる。
【００５５】
別の実施形態において、本発明は、通信ネットワークからダウンロード可能であり且つ／又はコンピュータ可読媒体に記録され且つ／又はプロセッサにより実行可能であるコンピュータプログラム製品に関する。前記コンピュータプログラム製品は、前記プログラムがコンピュータ上で実行された時に、上述の方法（少なくとも１つの実施形態における）を実現するためのプログラムコード命令を含む。
【００５６】
別の実施形態において、本発明は、前記プログラムがコンピュータ上で実行された時に上述の方法（少なくとも１つの実施形態における）を実現するために前記コンピュータにより実行可能な命令の集合を格納する、全体的又は部分的に取り外し可能でありコンピュータにより読み出し可能な記憶手段に関する。
【００５７】
別の実施形態において、本発明は、総合通信ネットワークを形成するために２つのサブネットワークを相互接続するトンネルにおけるデータパケットの送信を可能にするトンネル入力終端に関する。前記トンネルは前記トンネル入力終端とトンネル出力終端との間に実現され、前記サブネットワークの各々は前記トンネル終端のうち別個のトンネル終端を含み、前記トンネルは少なくとも２つの伝送チャネルを実現する。トンネル入力終端は以下を具備する：
−トンネル入力終端と同一サブネットワークに属する発信装置から到着するデータパケットを受信する手段；
−前記受信したパケットに含まれるペイロードデータと関連するプロトコル、及び前記伝送チャネルの現在の送信状態に関連する転送の品質に関する１つの情報の作用として、伝送チャネルの中から有効チャネルを選択する手段；
−送出されるパケットを取得するために使用される有効チャネルと関連する転送プロトコルに従って前記受信したパケットをカプセル化する手段；
−選択された有効チャネルにおけるトンネルで送出されるパケットを送信する手段。
【００５８】
現在の送信状態に関連する転送の品質に関する前記情報は、以下を含むグループに属するのが有利である：
−前記伝送チャネルの輻輳に関する情報；
−前記伝送チャネルに対するパケット誤り率（ＰＥＲ）に関する情報；
−前記伝送チャネルの再送率に関する情報。
【００５９】
有効チャネルを選択する前記手段は以下を含むのが有利である：
−パケットの各種類がパケットの前記種類を処理する前記パケットに含まれるペイロードデータに関係する別個のプロトコルにより規定され、前記受信したパケットと関連するパケットの種類を判定する手段；
−トンネル入力終端により送信され且つ前記受信したパケットと同一の種類である先に送信されたパケットに対して、前記先に送信されたパケットに対して取得される前記伝送チャネルに関する送信状態に関連する転送の品質に関する１つの情報の作用として最適な送信を可能にする先の優先チャネルと呼ばれる優先チャネルを判定する手段；
−前記伝送チャネル上の現在の送信状態に関連する転送の品質に関する前記情報を取得する手段；
−前記受信したパケットと関連するパケットの種類及び現在の送信状態に関連する転送の品質に関する前記少なくとも１つの情報の作用として前記受信したパケットの最適な送信を可能にする新しい優先チャネルと呼ばれるチャネルを選択する手段；
−先の優先チャネル、新しい優先チャネル及び前記受信したパケットに関連するパケットの種類の作用として前記有効チャネルを選択する手段。
【００６０】
有利な特徴によると、有効チャネルを選択する前記手段は以下を含む：
−前記受信パケットに関連するパケットの種類に対する前記先の優先チャネルから前記新しい優先チャネルへの円滑な切り替えの機構を実現する手段；
−前記受信パケットと関連するパケットの種類に対して、先の優先チャネルが新しい優先チャネルと異なる場合、円滑な切り替え機構を実現する前記手段を起動する手段。
【００６１】
円滑な切り替え機構を実現する前記手段は、前記チャネルの各々に対する最大送信ウィンドウを管理するステップをパケットの種類毎に含み、所定の時間間隔の間に前記チャネルで送信される最大データ量を示すのが有利である。
【００６２】
有利な特徴によると、前記ウィンドウ管理手段は、所定の時間間隔終了後、新しい優先チャネルの最大送信ウィンドウが増加し、先の優先チャネルの最大送信ウィンドウが漸減し、新しい所定の時間間隔の間に前記チャネルで送信される新しい最大データ量を示すような手段である。
【００６３】
好適な特徴によると、円滑な切り替え機構を実現する前記手段は、有効チャネルが以下のいずれかのチャネルである手段である：
−受信パケットと関連するパケットの種類に対する新しい優先チャネルと関連付けられる送信ウィンドウの範囲内の前記新しい優先チャネル
−受信パケットと関連するパケットの種類に対する前記新しい優先チャネルと関連付けられる前記送信ウィンドウの範囲を超えた場合は先の優先チャネル。
【００６４】
各チャネルは、それと関連付けられる転送プロトコルにより一意に識別されるのが有利である。
【００６５】
有利な変形例によると、各チャネルは、関連する転送プロトコル、並びに前記転送プロトコルの入力ポート及び出力ポートにより一意に識別される。
【００６６】
一実施形態において、有効チャネルの選択が行なわれる前記伝送チャネルは以下の２つのチャネルを含む：
−関連する転送プロトコルがＴＣＰプロトコルであるＴＣＰチャネルと呼ばれる第１のチャネル；
−関連する転送プロトコルがＵＤＰプロトコルであるＵＤＰチャネルと呼ばれる第２のチャネル。
【００６７】
第１の特定の実施形態において、有効チャネルを選択する前記手段は、受信したパケットがＵＤＰ型のパケットである時、現在の送信状態に関連する転送の品質に関する前記情報が前記伝送チャネルの輻輳を示す場合に前記受信したパケットに対する新しい優先チャネルがＵＤＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が前記伝送チャネルの輻輳を示さない場合に前記受信したパケットに対する新しい優先チャネルがＴＣＰチャネルであるような手段である。
【００６８】
第２の特定の実施形態において、有効チャネルを選択する前記手段は、前記受信したパケットがＵＤＰ型のパケットである時、現在の送信状態に関連する転送の品質に関する前記情報が前記伝送チャネルの輻輳を示す場合に前記受信したパケットの新しい優先チャネルがＵＤＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が判定された閾値を下回るパケット誤り率を示す場合に前記受信したパケットに対する新しい優先チャネルがＴＣＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が前記判定された閾値以上の前記伝送チャネルのパケット誤り率を示す場合に前記受信したパケットに対する新しい優先チャネルがＵＤＰチャネルであるような手段である。
【００６９】
第３の特定の実施形態において、有効チャネルを選択する前記手段は、受信パケットがＴＣＰ型のパケットである時、現在の送信状態に関連する転送の品質に関する前記情報が判定された閾値を上回る前記伝送チャネルの再送率を示す場合には前記受信パケットに対する新しい優先チャネルがＵＤＰチャネルであり、現在の送信状態に関連する転送の品質に関する前記情報が前記判定された閾値以下の前記伝送チャネルの送信率を示す場合には前記受信パケットに対する新しい優先チャネルがＴＣＰチャネルであるような手段である。
【００７０】
本発明の実施形態の他の特徴及び利点は、以下の限定しない例として示される以下の説明（本発明の全ての実施形態が以下に説明される実施形態の特徴及び利点に限定されるわけではない）及び添付の図面から明らかとなるだろう。
【発明を実施するための最良の形態】
【００７１】
本明細書の全ての図面において、同一の要素及びステップは同一の参照番号により示される。
【００７２】
本発明は、第１のＬＡＮに接続される複数の機器と第２のＬＡＮに接続される複数の機器との間の通信を改善するために、第１のＬＡＮ及び第２のＬＡＮのそれぞれに接続される２つのトンネル終端において実現される技術に関する。
【００７３】
本発明の一般的な原理は、トンネルを介して送信される各データパケットに対して、使用するのに最適なチャネル（通常、その転送プロトコルにより特徴付けられる）を選択することから成る。その選択は、送信されるデータの種類（そのパケットに含まれるペイロードデータのプロトコル、アプリケーションの種類等）及びネットワーク上の送信状態（２つのトンネル終端間）に基づく。
【００７４】
図１ａは、通信ネットワーク１０７（例えば、インターネット）を介するローカルトンネル終端１０１とリモートトンネル終端１０２との間のトンネル１００を実現する仮想プライベートネットワーク（ＶＰＮ）の一般的な構成を示す。このトンネル１００は、ＬＡＮ Ａ１０３及びＬＡＮ Ｂ１０４の２つのローカルネットワークを接続する。ＬＡＮ１０３及び１０４の各々は、高ビットレートインターネットアクセス装置（ファイアウォールを組み込み可能なホームゲートウェイ）１０５及び１０６、ＰＣ型装置１０９及び１１１、デジタルメディア（音声、映像及び写真の）を格納及び配信するためのサーバ１１０及び１１３、並びにデジタルメディア復元装置１０８及び１１２を有する。トンネル終端は、デジタルテレビセット等の音声映像装置に組み込まれてもよい。また、トンネル終端は、関連する機能を実行するプログラムの形式でＰＣ型装置に提供されてもよい。
【００７５】
トンネル１００がセットアップされると、ＬＡＮ Ａ１０３に接続された装置１０８、１０９及び１１０は、ＬＡＮ Ｂ１０４に接続された装置１１１、１１２及び１１３と通信できる。例えば、ＬＡＮ Ａ１０３に接続された顧客１０８は、ネットワークＬＡＮ Ｂ１０４に接続されたサーバ１１３と通信できる。
【００７６】
図１ａは、トンネルを１つのみ有する単純な通信ネットワークを示すが、同一のトンネル終端が第１のＬＡＮをいくつかの他のＬＡＮに相互接続するようにいくつかのトンネル（同数のトンネル終端につながる）を管理する必要があることが理解される。更に、簡単にするために、図はインターネットルータ等のインターネットにおけるインフラストラクチャ装置を示さない。
【００７７】
装置１０８、１０９、１１０（ＬＡＮ Ｂ１０３に接続される）の１つから到着し且つトンネル１００に入るイーサネット（登録商標）フレームのルーティングについて、図１ｂを参照して説明する。その目的のために、階層モデルが使用される。この階層モデルにより、トンネル１００の実現に必要とされるプロトコル層を説明する。このモデルにおいて、トンネルを使用すること以外の機能に必要なプロトコル要素は表されない。例えば、トンネル終端１０１がＵＰＮｐ装置に組み込まれる場合、ＵＰｎＰアーキテクチャと関連するプロトコル要素は示さない。
【００７８】
トンネル終端１０１は、装置１０８、１０９、１１０から到着するイーサネットフレームをルーティングするためにリンク層２０７に与えるイーサネット物理インタフェース２０８を有する。このルーティングは、トンネル終端を含む装置用のイーサネットフレームの場合にはネットワーク層２０６に向けて行なわれ、他のイーサネットフレームの場合にはブリッジ層２０９に向けて行なわれる。ブリッジ層２０９は、イーサネットフレームのフィルタリング及び１つ以上の適切なイーサネット出力ポートへのそれらフレームの中継等のイーサネットブリッジの従来の動作を実行する。ブリッジは、イーサネットインタフェース２０７及び少なくとも１つの仮想インタフェース２１０を有し、接続されたイーサネット制御器をシミュレートする。仮想インタフェース２１０は、インスタンス化された各トンネルを通過中に移動する必要のあるイーサネットフレームを与えられるアプリケーション２００によりインスタンス化されたトンネル毎に作成される。一般に、アプリケーション２００により表されるトンネルのカプセル化のプロトコルは、各トンネルを実現するのに必要な動作、その中でも特に構成、フィルタリング及びカプセル化（トンネルパケットの形成）、並びにフレームの抽出を実行する。
【００７９】
仮想インタフェース２１０から受信されたフレームは、アプリケーション２００により処理された後、ＳＳＬプロトコル２０２及びＤＴＬＳプロトコル２０４によりそれぞれセキュリティ保護される高信頼ＴＣＰ転送（トランスポート）プロトコル２０３又は低信頼ＵＤＰ転送プロトコル２０５にアプリケーションインタフェース又はソケット２０１を介してパケットの形式で渡される。それは、トンネルパケット２５０（図２ａ）を形成するために転送（トランスポート）プロトコルにより処理された後、ネットワーク層２０６に渡される。そのようにトンネルパケットにより形成されたＩＰデータグラムは、この時点でリンク層２０７及び物理層２０８を介してＬＡＮに送信される。
【００８０】
フレームの受信は、トンネル終端において、上述で提示された経路とは逆の経路を利用する。
【００８１】
図２ａは、レベル２トンネルパケットを搬送するイーサネットフレーム（参照番号２６０で示す）の形式の一例を示す。
【００８２】
この形式は、トンネル終端１０１とホームゲートウェイ１０５との間の図１ａのＬＡＮ Ａ１０３等で移動し（インターネットで送出されるか又はインターネットから受信されることが意図される）且つイーサネットヘッダ３２６１、レベル２トンネルパケット（参照番号２５０で示す）を搬送する第１のＩＰデータグラム及びＦＣＳ（「フレームチェックシーケンス」）フィールドを含むフレームに対応する。
【００８３】
トンネルパケット２５０は以下の４つの部分を有する：
−転送（トランスポート）プロトコル２５１のヘッダフィールド（すなわち、この例においてはＴＣＰ ＵＤＰ）
−カプセル化プロトコル２５２のヘッダフィールド（すなわち、この例においてはＬ２ＴＰ又はＴＬＳであり、特にJ. Lau他の文献IETF RFC3931「Layer two tunneling protocol - version 3 (L2TPv3)」２００５年３月及び文献IETF RFC2246「The TLS Protocol Version 1.0」において説明される）
−パッセンジャープロトコル２５３のヘッダフィールド（すなわち、この例においてはイーサネット）
−発信機器からの通過中にフラグメンテーションが起こらなかった場合に完全である第２のＩＰデータグラムを含むユーザデータフィールド２５４
本発明の方法の特定の一実施形態に従ってトンネル終端（例えば、図１ａの参照番号１０１により示されるトンネル終端）により実行されるＬＡＮアウトバウンドアルゴリズムについて、図２ｂを参照して説明する。この図は、トンネル１００を介して他方のトンネル終端１０２に送出されるデータの一般的な処理を説明する。
【００８４】
ステップ１において、ネットワークインタフェースをリスンし、ＬＡＮ Ｂ１０４に接続された少なくとも１つの装置用のＩＰ又はイーサネットデータパケットを取り込む。これは、いくつかの仮想ネットワークデバイス（ＴＵＮ／ＴＡＰ等）がブリッジに追加された状態でそのブリッジを使用することにより行なわれる。
【００８５】
ステップ２において、パケットがＬＡＮ Ｂに対して送信されることを許可されるかを判定する。例えば、ＬＡＮ Ｂから受信されるパケットはこの同一ＬＡＮに対して送信されない。
【００８６】
ステップ３において、ＬＡＮ Ｂ１０４にデータパケットを送信するために使用するのに最適なチャネルを選択する。他の図と関連してこのステップ３を以下に詳細に説明する。
【００８７】
ステップ４（オプションのステップ）において、ユーザデータの秘密性を保証するために、暗号化がデータに対して実行されてもよい。このステップは、例えばＡＥＳ（新暗号規格）等の周知の暗号化アルゴリズムを使用して行なわれる。
【００８８】
ステップ５において、受信パケットは、ステップ３の結果に基づいてステップ３で選択されたチャネルと関連するカプセル化プロトコル（トンネリングプロトコルとも呼ばれる）を使用してカプセル化される。このカプセル化プロトコルは、特定の情報（ヘッダ）を追加し、オプションとして追加データを追加して、チャネルが依然として有効であるか、すなわち送信が依然として可能であるか）を双方のトンネル終端が認識することを可能にするトンネルの機能（例えば、「キープアライブ」機構等）に特有の特徴を提供できる。それら追加の機能はチャネルに依存してもよい。例えば、従来、任意のＲＴＴ測定機構を与えないＵＤＰチャネルのＲＴＴ（ラウンドトリップタイム）を測定するために追加のデータを追加することは有用だろう。これは、カプセル化データにおける迅速な応答（識別子を含む）に対する要求を追加することにより行なわれる。リモートトンネルヘッダはこの種の要求を受信すると、迅速に応答する。ローカルトンネルヘッダは、応答を受信すると、ＲＴＴを判定してもよい。そのような機構は、当然、ＲＴＴ評価機構を既に実現しているチャネル（これは、例えばＴＣＰを使用するチャネルの場合）において実現される必要はない（Stevens, Wright, Addison-Wesleyの「TCP／IP illustrated, Volumes 1, 2, and 3」１９９４年、１９９５年及び１９９６年を参照）。
【００８９】
ステップ６において、カプセル化の結果として得られるパケットは、ステップ３で選択されたチャネルで送信される。これは、パケットをトンネルで送出するように構成される接続インタフェース（ソケット）にデータを書き込むことにより行なわれる。このステップの後、パケットは、最終的に図２ａの参照番号２５０で示されるパケットの形式を有する。更にこのステップは、チャネル統計（再送、送信されるデータの種類等）を更新する。
【００９０】
本発明の方法の特定の一実施形態に従って、トンネル終端（例えば、図１ａの参照番号１０２により示されるトンネル終端）により実行されるＬＡＮにおけるインバウンドアルゴリズムについて、図２ｃを参照して説明する。この図は、他方のトンネル終端１０１から到着し且つトンネル１００を介して受信されるデータの処理全体を説明する。
【００９１】
ステップ７において、各チャネルに対応する特定の各接続インタフェース（ソケット）においてリスンしてパケットを受信する。
【００９２】
ステップ８において、受信が行なわれるチャネルのネットワーク品質（再送、ＲＴＴ、ＰＥＲ、輻輳等）に関する情報を更新する。
【００９３】
ステップ９において、復号化アルゴリズム及びステップ４で使用された鍵と互換性のある関連する鍵を使用する際、ペイロードデータは復号化される（図２ｂのステップ４が実行された場合）。
【００９４】
ステップ１０において、データパケットは非カプセル化され、元のデータパケット（トンネル終端１０１によりＬＡＮ Ａ１０３において予備的に取り込まれた）を検索する。このステップにおいて、オプションの追加の機構に関連する追加のデータがある場合はその追加のデータを処理する（ステップ５の説明を参照）。
【００９５】
ステップ１１において、非カプセル化の結果として得られるパケットが許可されるか否かが判定される。例えば、復号化又は非カプセル化が満足のいく結果を与えられないパケットは、ＬＡＮ Ａに接続された装置の動作を妨害しないようにそのＬＡＮにおける送信に対して許可されない。
【００９６】
ステップ１２において、チャネル統計（帯域幅、送信されるデータの種類等に対する）が更新される。
【００９７】
ステップ１３において、非カプセル化の結果として得られるパケットは、ＬＡＮ Ｂ１０４において送出される。これは、ＴＵＮ／ＴＡＰ等の仮想ネットワークデバイスを使用することにより行なわれる。
【００９８】
以下において、本発明の方法の特定の一実施形態に従って有効チャネルを選択するためのアルゴリズム（図２ｂのステップ３の詳細）について、図３を参照して説明する。
【００９９】
ステップ２（図２ｂ）から受信されるパケットがＩＰパケットであるか否かを判定するために（本実施形態において、ＩＰパケットのみが考慮されるため）、そのパケットはステップ３１において解析される。これは、パケットのコンテンツ（ＬＬＣヘッダ等）を解析することにより行なわれる。ＩＰパケットでない場合、デフォルトのチャネルを選択するステップ３７に進む。このデフォルトのチャネルは、ユーザにより判定され、例えばＴＣＰチャネルである。ＩＰパケットである場合、ステップ３２に進む。
【０１００】
このステップ３２において、パケットは分類される（最適なチャネルを選択するために後で使用されるパケットに関する全ての情報が抽出される）。一般に、パケットの種類（分類の結果）をそのペイロードデータの機能として判定するために、ペイロードデータ転送（トランスポート）プロトコル（ＩＰにおける転送（トランスポート）プロトコル）を判定する。この情報は、ＩＰヘッダの８ビットの予約ビットに符号化される。以下の説明において、ペイロードデータ転送プロトコルをパケットの種類の識別子として使用する（ＴＣＰ、ＵＤＰ、ＳＣＴＰ、ＤＣＣＰ等）。
【０１０１】
ステップ３３において、ステップ３２で判定されたパケットの種類が以下のステップ３５により管理されるかを判定する。管理されない場合、ステップ３７に進む。管理される場合、ステップ３４に進む。
【０１０２】
例えば、本明細書で説明される特定の実施形態において、ＴＣＰ及びＵＤＰは、以下のステップ３５により管理されるパッセンジャープロトコルである。他のパッセンジャープロトコルに対しては、ステップ３７においてデフォルトのチャネルが選択される。そのようなプロトコルは、例えばＤＣＣＰ（「データグラム輻輳制御プロトコル」）又はＳＣＴＰ（ストリーム制御伝送プロトコル）である転送プロトコル、あるいはＲＳＶＰ（「リソース予約プロトコル」）であるリソース予約プロトコル、並びにＩＣＭＰ（「インターネット制御メッセージプロトコル」）又はＩＧＭＰ（インターネットグループマルチキャストプロトコル）等の非レイヤ４（ＩＳＯモデルにおいて）プロトコルである。そのような種類のパッセンジャープロトコルのパケットは、単一のチャネルを有するトンネルで送信される。非ＩＰパケットに関しては、デフォルトのチャネルがユーザにより設定されてもよく、あるいは事前設定されたデフォルト値で構成されてもよい。尚、上述のパッセンジャープロトコル（ステップ３５により管理されない）に対するデフォルトのチャネルとしてＴＣＰチャネルを規定することにより、従来の方法の適用が可能になる。
【０１０３】
ステップ３４において、ＱｏＥ（「体感品質」）を判定する。このために、ネットワークの品質（輻輳、ＰＥＲ、帯域幅、ＲＴＴ、再送率等）に関する全てのデータが検索される。全てのデータは、パケットがトンネルにより送出又は受信されると常に評価される（ステップ８、ステップ１２、ステップ３８４及びステップ３８７）。
【０１０４】
ステップ３５において、可能な限り効率的にペイロードデータをリモートＬＡＮに送信するために使用するのに優先チャネル（及び従って優先転送（トランスポート）プロトコル）を判定する。チャネルは転送プロトコルにより別個に特徴付けられてもよいが、ＴＯＳ（サービスの種類）パラメータ等の他の特徴が使用されてもよい。優先チャネルを判定する３つの可能な方法を以下に例として与える（図４のステップ３５ａ、図５のステップ３５ｂ及び図６のステップ３５ｃ）。
【０１０５】
ステップ３６において、処理されるパケット（以下において「処理パケット」と呼ぶ）の種類に対する転送モードを判定する。転送モードは、所定の種類のパケットの送信を管理する方法に対応する。このモードは、固定（例えば、ＴＣＰ又はＵＤＰ）であってもよく、あるいは過渡的（例えば、ＴＣＰ−ＵＤＰ又はＵＤＰ−ＴＣＰ）であってもよい。
【０１０６】
ステップ３６の可能な実現例を図７ａ、図８ａ及び図８ｂに示す。本実現例において、転送（トランスポート）プロトコル（図４、図５及び図６に準拠する）により特徴付けられるチャネルの例を考慮する。優先転送（トランスポート）プロトコル及び処理されるパケットの種類に対する現在の転送モードに依存して、ステップ３６において転送モードの進捗はパケットの種類毎（種類はステップ３２で判定される）に管理される（ＴＣＰ及びＵＤＰの２つの固定モード、並びにＴＣＰ−ＵＤＰ及びＵＤＰ−ＴＣＰの２つの過渡モードの４つの可能なモード間で）。例えば、ステップ３５において、ＵＤＰパケットとも呼ばれるＵＤＰ型のパケット（すなわち、ＵＤＰがパッセンジャープロトコルのペイロードデータプロトコルであるパケット）に対して、優先転送プロトコルはＴＣＰである（すなわち、優先チャネルはＴＣＰチャネルである）が、ＵＤＰパケットに対する現在の転送モードはＵＤＰモードであると判定される場合、ステップ３６において、ＵＤＰ−ＴＣＰ過渡モードに入り、処理パケットに対する有効伝送チャネルは優先ＴＣＰチャネルであってもよく又はＵＤＰチャネルであってもよい（図７ａ、図７ｂ、図８ａ、図８ｂ及び図８ｃの以下の詳細な説明を参照）。
【０１０７】
ステップ３８において、有効チャネルは、処理されるパケットの種類に対する送信ウィンドウパラメータ（以下の説明を参照）及び現在の転送モードの優先チャネル（ステップ３５を参照）の作用として選択される。このステップ３８の可能な実現例を図８ｃに示す。これは、所定の種類のパケットに対して、１つの転送モードから別の転送モードへ円滑に渡すために使用される選択機構である。トンネルの「人為的な」輻輳を回避するために、この機構は重要である。
【０１０８】
例えば、ある種類のパケットに対する優先転送プロトコルがＵＤＰからＴＣＰに切り替えられる場合、ＴＣＰチャネルで送信されるパケット数が突然増加することによりＴＴＰ輻輳ウィンドウの超過を徐々に引き起こすため、その種の全てのパケットをＴＣＰチャネルで直接送出できない。その結果、実際に利用可能な帯域幅が十分に大きい場合でも、パケットはＴＣＰスタックによりバッファリングされるか又は遅延される。それらバッファリングされたパケットは終端間通信の測定されたＲＴＴを延長し、ＴＣＰパケットの場合に（ＴＣＰの場合にＲＴＯ（「再送タイムアウト」）と呼ばれる再送タイムアウトの終了に伴って）不必要な再送を引き起こす可能性がある。
【０１０９】
ＴＣＰ転送モードからＵＤＰ転送モードへ切り替える場合、ＴＣＰ送信を突然減速させ、また問題を引き起こす可能性があるＵＤＰチャネルのサイズの突然の増加を監視する必要がある。
【０１１０】
図４は、チャネルを選択するため、すなわち優先転送プロトコルを選択するための優先アルゴリズムの第１の例を示す（図３のステップ３５の詳細であり、参照番号３５ａで示される）。この第１の例において、ＥＣＮ通知機構のみが使用される。
【０１１１】
この第１の例において選択される方法は、ネットワークの輻輳がない場合にのみ、ＵＤＰチャネルでＴＣＰパケットを送出し（「TCP over TCP」の組合せの問題を防止するため）且つＴＣＰチャネルでＵＤＰパケットを送出する（ＬＡＮと同様の信頼性を提供するため）方法である。ネットワークの輻輳が発生した場合、ＵＤＰパケットはＵＤＰチャネルで送出される（いくつかのパケットが除去されても、ＵＤＰの速度を保持するため）。
【０１１２】
ステップ３５２において、処理されるパケットの種類、すなわちその処理パケットに含まれるペイロードデータの転送のためのプロトコルが判定される。
【０１１３】
パケットがＴＣＰパケットの場合、ステップ３５９が実行される。このステップにおいて、ＵＤＰチャネルが処理パケットに対する優先チャネルとして選択される。
【０１１４】
パケットがＵＤＰパケットである場合、ステップ３５３が実行される。このステップにおいて、ネットワークの輻輳がＥＣＮ通知機構を介して検出されたか（ステップ８において）が判定される。
【０１１５】
輻輳が検出されなかった場合、ステップ３５８が実行される。このステップにおいて、ＴＣＰチャネルが処理パケットに対する優先チャネルとして選択される。輻輳が検出された場合、ステップ３５９が実行される。このステップにおいて、ＵＤＰチャネルが処理パケットに対する優先チャネルとして選択される。
【０１１６】
図５は、優先チャネル、すなわち優先転送プロトコルを選択するためのアルゴリズムの第２の例を示す（図３のステップ３５の詳細であり、参照番号３５ｂで示される）。この第２の例において、ＥＣＮ通知機構及びパケット誤り率（ＰＥＲ）が共に使用される。
【０１１７】
この第２の例において、ネットワークのＰＥＲは、判定された閾値Pth（例えば、ユーザにより選択される）と新しいステップ３５４で比較される。
【０１１８】
この場合、ステップ３５３が輻輳を検出しなければ、ステップ３５４に進む（図４のようにステップ３５８を直接実行せずに）。
【０１１９】
ステップ３５４において、ＰＥＲが大きい（閾値Pth以上である）が、輻輳がないことをステップ３５３が示す場合、終端間の信頼性を増加するために処理パケットに対する優先チャネルとしてＴＣＰチャネルを選択するのが有用である。ＰＥＲが大きくない（ＰＥＲが閾値Pthを下回る）場合、ＵＤＰチャネルが処理パケットに対する優先チャネルとして選択される。
【０１２０】
図６は、優先チャネル、すなわち優先転送プロトコルを選択するためのアルゴリズムの第３の例を示す（図３のステップ３５の詳細であり、参照番号３５ｃで示される）。この第３の例において、ＥＣＮ通知機構、パケット誤り率（ＰＥＲ）及びＴＣＰチャネルにおける再送率が共に使用される。
【０１２１】
ＴＣＰパケットに対して、トンネルにおける多くの再送が終端から終端へのＴＣＰ通信における再送を引き起こし、不必要な再送を引き起こすことが周知である（上述の文献「Understanding TCP over TCP (...)」を参照）。そのような状況を防止するために、ＴＣＰパケットをＵＤＰチャネルで送出することが先に提案された（図４及び図５を参照）。しかし、トンネルの信頼性を保証するために、トンネルがパケットを再送することを許可するのは有用であろう。これを達成するために、この第３の例は、ＴＣＰチャネルでの再送を考慮する。ＴＣＰチャネルにおける再送率が閾値Rth（例えば１０％）を下回る場合、ＴＣＰパケットをＴＣＰチャネルで送出するのは有用である。ＴＣＰチャネルにおける再送率が閾値Rth以上である場合、ＴＣＰパケットはＵＤＰチャネルで送出される。
【０１２２】
従って、図５と比較すると、ＴＣＰチャネルにおける再送率が閾値Rthを下回るかを検出するためのチェックが行なわれる追加のステップ３５７が存在する（ステップ３５２の出力において）。閾値を下回る場合、ステップ３５８に進み、ＴＣＰチャネルが処理パケットの優先チャネルとして選択される。閾値を下回らない場合、ステップ３５９に進み、ＵＤＰチャネルが処理パケットに対する優先チャネルとして選択される。
【０１２３】
図７ａを参照すると、本発明の方法の好適な一実施形態に従ってある種類のパケットに対する送信ウィンドウ及び現在の転送モードを管理するためのアルゴリズムが示される（図３のステップ３６の詳細を参照）。
【０１２４】
従って、パケットの種類毎に、転送モード及び２つの送信ウィンドウ（トンネルの伝送チャネル毎に１つ）を管理する。所定のチャネルに関連する送信ウィンドウは、判定された期間（ＲＴＴに対応する）に所定のチャネルで送信されるデータの最大量を規定するために使用されるパラメータの集合（図７ｂを参照）により規定される。所定の種類のパケットに対して、１つのチャネルから別のチャネルへ円滑に切り替えるために、転送モードに依存して２つのウィンドウが増加又は減少する。
【０１２５】
処理されているパケット（又は処理パケット）の種類は、図３の分類ステップ３２の間に判定されることが思い出されるだろう。
【０１２６】
この例は、ＴＣＰパケット又はＵＤＰパケットの２種類のパケットを考慮する。それら２種類のパケットの各々に対して、１つの転送モード及び２つの送信ウィンドウが管理される。それら送信ウィンドウは、以下において「ＴＣＰ送信ウィンドウ」及び「ＵＤＰ送信ウィンドウ」と呼ばれる。
【０１２７】
尚、所定の種類のパケットについて図７ａを以下に説明し、転送モード又はウィンドウパラメータ（Wtcp、Stcp、Wtcp_max、Wudp、Sudp、Wudp_max）について説明する場合は、それは常に前記所定の種類のパケットに適切な変数の集合に属するウィンドウパラメータ又は転送モード（図７ｂを参照）であることが理解されるべきであることが重要である。同一のことが以下に説明する図８ａ、図８ｂ及び図８ｃにも当てはまる。
【０１２８】
所定の種類の処理パケットに対して、ステップ３５（図３）（例えば、図４、図５及び図６のいずれか１つに従って実現される）で優先伝送チャネルを判定した後、ステップ３６０に到達する。
【０１２９】
ステップ３６０において、優先チャネルに応じて切り替えが行なわれる。すなわち、優先チャネルがＴＣＰチャネルである場合（すなわち、優先転送プロトコルがＴＣＰである場合）にステップ３６１に進み、優先チャネルがＵＤＰチャネルである場合（すなわち、優先転送プロトコルがＵＤＰである場合）にステップ３６２に進む。
【０１３０】
ステップ３６２において（優先チャネルがＵＤＰチャネルである場合）、切り替えは、現在の転送モード（処理されるパケットの種類に対する）の機能として行なわれる。
【０１３１】
ステップ３６２において現在のモードが固定ＴＣＰモード（これはＴＣＰチャネルである先の優先チャネルと関連付けられる）である場合、システムは、ステップ２６３でセットアップされるＴＣＰ−ＵＤＰ過渡モードに入る必要がある。準備段階としてステップ３６９に進む。ステップ３６９において、ウィンドウパラメータは処理されるパケットの種類に対して初期化される：
−処理されるパケットの種類（Sudp）に対してＵＤＰチャネルで既に送信されたデータ量が０に設定される（Sudp = 0）；
−ＵＤＰウィンドウのサイズ（Wudp）（ＵＤＰチャネルで送信され得る最大データ量）がTCP over TCPチャネル接続の最大セグメントサイズ（MSS）に設定される（Wudp = MSS）；
−ＴＣＰウィンドウの最大サイズに対応する停止条件（Wudp_max）がＴＣＰ輻輳ウィンドウの現在の値（Cwnd）に設定される（Wudp_max = Cwnd）。この停止条件はＴＣＰ−ＵＤＰ過渡モードの出力を判定する。
【０１３２】
ステップ３６２において現在のモードがＵＤＰ−ＴＣＰ過渡モード（これはＴＣＰチャネルである優先先のチャネルと関連付けられる）である場合、システムは、ここでもステップ２６３でセットアップされるＴＣＰ−ＵＤＰ過渡モードに入る必要がある。既に再設定された処理されるパケットの種類に対するウィンドウパラメータを保存できる（図８ａを参照）。
【０１３３】
ステップ３６２において現在のモードが固定ＵＤＰモード（これはＵＤＰチャネルである先の優先チャネルと関連付けられる）又はＴＣＰ−ＵＤＰ過渡モード（これはＵＤＰチャネルである先の優先チャネルと関連付けられる）である場合、動作は必要ない。
【０１３４】
ステップ３６３の後、ステップ３６６に進み、ＴＣＰ−ＵＤＰ過渡モードを管理するためのアルゴリズム（図８ｂを参照して以下に説明する）の実行が開始される。この開始後、図３のステップ３８に進む。
【０１３５】
ステップ３６１において（優先チャネルがＴＣＰチャネルである場合）、切り替えは現在の転送モード（処理されるパケットの種類に対して）の機能として行なわれる。
【０１３６】
ステップ３６１において現在のモードが固定ＵＤＰモード（これはＵＤＰチャネルである先の優先チャネルと関連付けられる）である場合、システムはステップ３６４でセットアップされるＵＤＰ−ＴＣＰ過渡モードに入る必要がある。準備段階として、ステップ２６８に進み、処理されるパケットの種類に対するウィンドウパラメータが初期化される：
−処理されるパケットの種類に対してＴＣＰチャネルで既に送信されたデータ量（Stcp）は０に設定される（Stcp = 0）；
−ＴＣＰウィンドウのサイズ（Wtcp）（ＴＣＰチャネルで送信され得る最大データ量）がＴＣＰ輻輳ウィンドウの現在のサイズ（Cwnd）に設定される（Wtcp = Cwnd）。従って、最初に２つのウィンドウ（Wtcp及びCwnd）は同一サイズを有する；
−ＴＣＰウィンドウの最大サイズに対応する停止条件（Wtcp_max）がＵＤＰウィンドウ（Wudp）の現在の値に設定される。この停止条件はＵＤＰ−ＴＣＰ過渡モードの出力を判定する。
【０１３７】
ステップ３６１において現在のモードがＴＣＰ−ＵＤＰ過渡モード（これはＵＤＰチャネルである先の優先チャネルと関連付けられる）である場合、システムはここでもステップ３６４でセットアップされるＵＤＰ−ＴＣＰ過渡モードに入る必要がある。処理されるパケットの種類に対して既に初期化されたウィンドウパラメータ（図８ｂを参照）を保持できる。
【０１３８】
ステップ３６１において現在のモードが固定ＴＣＰモード（これはＴＣＰチャネルである先の優先チャネルと関連付けられる）又はＵＤＰ−ＴＣＰ過渡モード（これはＴＣＰチャネルである先の優先チャネルと関連付けられる）である場合、動作は必要ない。
【０１３９】
ステップ３６４の後、ＵＤＰ−ＴＣＰ過渡モードを管理するためのアルゴリズム（図８ａを参照して以下に説明する）の実行を開始するステップ３６５に進む。この開始後、図３のステップ３８に進む。
【０１４０】
図７ｂは、本発明の方法の特定の一実施形態に係るパケットの種類の表を示す。この表４０００は、パケットの種類毎に考慮される変数の集合を示す。
【０１４１】
より詳細には、表４０００はパケットの種類毎（例えば、ＴＣＰパケット又はＵＤＰパケット）に１行含む。列４００２は、パケットのその種類に対する現在の転送モードを示す。列４００３〜４００５は、パケットのその種類に対してＴＣＰ送信ウィンドウを規定する変数（それぞれ既に上述したWtcp、Stcp及びWtcp_max）の値を与える。列４００６〜４００８は、ＵＤＰ送信ウィンドウを規定する変数（それぞれ既に上述したWudp、Sudp及びWudp_max）の値を与える。
【０１４２】
２つの追加の変数Nudp_tcp及びNtcp_udpは、ＵＤＰ−ＴＣＰ過渡モード及びＴＣＰ−ＵＤＰ過渡モードの各々におけるパケットの種類の数に関する知識を常に与える。それら２つの変数は、送信ウィンドウを増分するステップを判定するのに重要である（図８ａのステップ３６５４及び図８ｂのステップ３６６４を参照）。実際には、輻輳ウィンドウのサイズ（Cwnd）の自然な進捗に追従するように、ＵＤＰ−ＴＣＰ過渡モードにおける送信ウィンドウ及びＴＣＰ−ＵＤＰ過渡モードにおける送信ウィンドウの各々が進捗することは、当該過渡モードにより考慮されるパケットの全ての種類を考慮する必要がある。考慮しない場合、すなわち各種類のパケットが別個に考慮される場合、ＵＤＰ−ＴＣＰ過渡モードにおける送信ウィンドウ及びＴＣＰ−ＵＤＰ過渡モードにおける送信ウィンドウの各々の進捗は、輻輳ウィンドウのサイズ（Cwnd）の自然な進捗に追従せず、ＵＤＰ−ＴＣＰ過渡モードにおけるＴＣＰ転送プロトコルにより受け入れ可能なデータ量及びＴＣＰ−ＵＤＰ過渡モードにおけるＵＤＰ転送プロトコルにより受け入れ可能なデータ量の閾値を超える危険性がある。
【０１４３】
図８ａは、本発明に係る方法の特定の一実施形態に従って、ＵＤＰ−ＴＣＰ過渡モードを管理するためのアルゴリズムを示す。
【０１４４】
この図は、所定のパケットに対して、ＴＣＰ送信ウィンドウ及びＵＤＰ送信ウィンドウ（この所定の種類のパケットに対する）のパラメータが固定ＵＤＰ転送モードから固定ＴＣＰ転送モードへの円滑な切り替えを可能にするように展開される方法を説明する。
【０１４５】
サイズ（Cwnd）と比較して過度に大量のパケットをＴＣＰチャネルで送出することにより発生する問題を回避するために、本発明はＴＣＰチャネルで計画された機構を考慮して輻輳を防止し、ＴＣＰ（仮想）送信ウィンドウのサイズ（Wtcp）は輻輳ウィンドウのサイズ（Cwnd）の自然な進捗に適合するように増加する。
【０１４６】
ステップ３６５９において、ＵＤＰ−ＴＣＰモードにおけるパケットの種類の数（Nudp_tcp）は１ずつ増分される。
【０１４７】
ＴＣＰ送信ウィンドウのサイズ（Wtcp）を管理するために、ステップ３６５１でタイムアウトが開始され（パケットが受信されると更新されるＴＣＰチャネルのＲＴＴに対応する。ステップ１２を参照）、ステップ３６５２においてそのタイムアウトが終了するのを待つ。
【０１４８】
その間（ステップ３６５１とステップ３６５２との間）、パケットはステップ３８に従って送出される（ステップ３８はパケット毎に１回実行される）。
【０１４９】
タイムアウトの終了後、転送（トランスポート）モードが変更されたか（ステップ３５における優先チャネルの変更に後続し、ＵＤＰ−ＴＣＰ過渡モードからＴＣＰ−ＵＤＰ過渡モードへ転送モードを変更することをステップ３６において決定してもよい）を調査するために、ステップ３６５３においてテストが行なわれる。
【０１５０】
転送モードが変更された場合、終了前にステップ３６５７に進み、ＵＤＰ−ＴＣＰモードにおけるパケットの種類の数（Nudp_tcp）が減分される。
【０１５１】
転送モードが変更されなかった場合、アルゴリズムは、ＴＣＰ（仮想）送信ウィンドウの進捗を管理し続けるように実行し続ける。ステップ３６５４に進み、ＴＣＰ送信ウィンドウのサイズ（Wtcp）はMSS／Nudp_tcpだけ増加される。従って、輻輳を回避する際及びNudp_tcp個の種類のパケットがＵＤＰ−ＴＣＰ過渡モードにおいて同時に存在することを考慮する際に、ＴＣＰ輻輳ウィンドウのサイズ（Cwnd）の増加は最大となる。更にステップ３６５４において、１つ前のＲＴＴの間に処理されるパケットの種類（Stcp）に対してＴＣＰチャネルで既に送信されたデータ量は０に設定される（Stcp = 0）。
【０１５２】
ステップ３６５５において、ＵＤＰ−ＴＣＰ過渡モードにおける過渡段階が終了したかを決定する。このために、ＴＣＰ送信ウィンドウのサイズ（Wtcp）が十分に増加したか（Wtcp ＞ Wtcp_max?）及び処理されるパケットの種類に対してＵＤＰチャネルで送出されるデータがそれ以上存在しないか（Sudp = 0?）を確認するためのチェックが行なわれる。
【０１５３】
過渡段階が終了した場合、ステップ３６５６に進み、固定ＴＣＰモードがセットアップされる。終了前にステップ３６５７に進み、ＵＤＰ−ＴＣＰモードにおけるパケットの種類の数（Nudp_tcp）は減分される。
【０１５４】
過渡段階が終了していない場合、ステップ３６５８に進み、処理されるパケットの種類に対してＵＤＰチャネルで既に送信されたデータ量が０に設定される（Sudp = 0）。ステップ３６５１に戻り、新しいタイムアウトが開始される。
【０１５５】
図８ｂは、本発明の方法の特定の一実施形態に従って、ＴＣＰ−ＵＤＰ過渡モードを管理するためのアルゴリズムを示す。
【０１５６】
この図は、所定の種類のパケットに対して、ＴＣＰ送信ウィンドウ及びＵＤＰ送信ウィンドウ（その所定の種類のパケットに対する）のパラメータが固定ＴＣＰ転送モードから固定ＵＤＰ転送モードへの円滑な切り替えを可能にするように展開される方法を説明する。
【０１５７】
このＵＤＰ送信ウィンドウを管理する機構は、ＴＣＰ送信ウィンドウに対する図８ａを参照して上述した機構に類似する。ＵＤＰ送信ウィンドウのサイズ（Wudp）は、期間RTTuにおいてＵＤＰチャネルで送信され得る最大データ量を示す。この期間RTTuは、システムにより算出される値であり、ＴＣＰに対して説明したようなラウンドトリップタイムに対応する（この値は、一方のトンネル終端から他方のトンネル終端に特定の制御要求を周期的に送出することにより算出され、その他方のトンネル終端はその要求に即時に従う）。
【０１５８】
過度に大量のパケットをＵＤＰチャネルで送出することにより発生する輻輳を回避するために（ＴＣＰチャネルがバッファを空にするのを終了する前に）、ＴＣＰ送信全体をＵＤＰ送信全体に突然切り替えることはできない。従って、図８Ｂの機構（図８ａの機構に類似する）が使用される。
【０１５９】
従って、ステップ３６６９において、ＴＣＰ−ＵＤＰモードにおけるパケットの種類の数（Ntcp_udp）は１ずつ増分される。
【０１６０】
その後、ＵＤＰ送信ウィンドウのサイズ（Wudp）を管理するために、タイムアウトはステップ３６６１において開始され（上述のRTTuに対応する）、ステップ３６６２においてそのタイムアウトの終了を待つ。
【０１６１】
その間（ステップ３６６１とステップ３６６２との間）、パケットはステップ３８に従って送出される（このステップ３８はパケット毎に１回実行される）。
【０１６２】
タイムアウトの終了後、転送（トランスポート）モードが変更されたか（ステップ３５における優先チャネルの変更に後続し、ＴＣＰ−ＵＤＰ過渡モードからＵＤＰ−ＴＣＰ過渡モードへ転送モードを変更することをステップ３６において決定してもよい）を調査するために、ステップ３６６３においてテストが行なわれる。
【０１６３】
転送モードが変更された場合、終了前にステップ３６６７に進み、ＴＣＰ−ＵＤＰモードにおけるパケットの種類の数（Ntcp_udp）が減分される。
【０１６４】
転送モードが変更されなかった場合、アルゴリズムは、ＵＤＰ（仮想）送信ウィンドウの進捗を管理し続けるように実行し続ける。ステップ３６６４に進み、ＵＤＰ送信ウィンドウのサイズ（Wudp）はMSS／Ntcp_udpだけ増加される。更にステップ３６６４において、１つ前のＲＴＴの間に処理されるパケットの種類に対してＵＤＰチャネルで既に送信されたデータ量（Sudp）は０に設定される（Sudp = 0）。
【０１６５】
ステップ３６６５において、ＴＣＰ−ＵＤＰ過渡モードにおける過渡段階が終了したかを決定する。このために、ＵＤＰ送信ウィンドウのサイズ（Wudp）が十分に増加したか（Wudp ＞ Wudp_max?）及び処理されるパケットの種類に対してＴＣＰチャネルで送出されるデータがそれ以上存在しないか（Stcp = 0?）を確認するためのチェックが行なわれる。
【０１６６】
過渡段階が終了した場合、ステップ３６６６に進み、固定ＵＤＰモードがセットアップされる。終了前にステップ３６６７に進み、ＴＣＰ−ＵＤＰモードにおけるパケットの種類の数（Ntcp_udp）は減分される。
【０１６７】
過渡段階が終了していない場合、ステップ３６６８に進み、処理されるパケットの種類に対してＴＣＰチャネルで既に送信されたデータ量が０に設定される（Stcp = 0）。その後ステップ３６６１に戻り、新しいタイムアウトが開始される。
【０１６８】
次に図８ｃを参照して、本発明の方法の特定の一実施形態に従って、パケットの種類に対する有効チャネルを選択するためのアルゴリズム（図３のステップ３８の詳細）を示す。
【０１６９】
ステップ３８０において、切り替えが現在の転送（トランスポート）モード（処理されるパケットの種類）に従って実行される。
【０１７０】
ステップ３８０において現在のモードが固定ＴＣＰモードである場合、ステップ３８３に進み、ＴＣＰチャネルが有効伝送チャネルとして選択される。その後ステップ３８４に進み、ＴＣＰチャネルのパラメータが評価される（例えば、平均スループット、輻輳ウィンドウ等）。
【０１７１】
ステップ３８０において現在のモードが固定ＵＤＰモードである場合、ステップ３８６に進み、ＵＤＰチャネルが有効伝送チャネルとして選択される。その後ステップ３８７に進み、ＵＤＰチャネルのパラメータが評価される（例えば、平均スループット、輻輳ウィンドウ等）。
【０１７２】
ステップ３８０において現在のモードが過渡モード（ＴＣＰ−ＵＤＰ又はＵＤＰ−ＴＣＰ）のうちの１つである場合、ステップ３８１に進み、パケットの送出先のチャネルが判定される。そのために、優先チャネルで送信される最大データ量に到達するか否かを確認するためのチェックが行なわれる（ＵＤＰ−ＴＣＰ過渡モードの場合は「Stcp ＞ Wtcp-max」であると確認され、ＴＣＰ−ＵＤＰ過渡モードの場合は「Sudp ＞ Wudp-max」であると確認される）。この最大量に到達していない場合、優先チャネルが処理パケットを送信するために使用される。到達した場合、処理パケットは先の優先チャネルで送信される。
【０１７３】
ＵＤＰ−ＴＣＰモードの場合：
−処理されるパケットの種類に対してステップ３６６８（Stcpをゼロに再設定する）の前回の実行以降にＴＣＰチャネルで送信されたデータ量（Stcp）が許可される最大値（Wtcp-max）を上回る場合（ステップ３８１のテストに対する応答がｙｅｓの場合）、優先チャネルがＴＣＰチャネルであっても、処理パケットはＵＤＰチャネルで送信される（ステップ３８５の後、ステップ３８６及びステップ３８７に進む）。ステップ３８５において、処理されるパケットの種類に対してステップ３６５８（Sudpの再設定）の前回の実行以降にＵＤＰチャネルで送信されたデータ量（Sudp）は、処理されるパケットのサイズ分だけ増加される（Sudp = Sudp + PacketSize）；
−処理されるパケットの種類に対してステップ３６６８（Stcpの再設定）の前回の実行以降にＴＣＰチャネルで送信されたデータ量（Stcp）が許可される最大値（Wtcp-max）以下である場合（ステップ３８１のテストに対する応答が否定である場合）、処理パケットはＴＣＰチャネルで送信される（ステップ３８２が実行された後、ステップ３８３及びステップ３８４に進む）。ステップ３８２において、処理パケットに対してＴＣＰチャネルで既に送信されたデータ量（Stcp）は処理パケットのサイズ分だけ増加される（Stcp = Stcp + PacketSize）。
【０１７４】
ＴＣＰ−ＵＤＰモードの場合：
−処理されるパケットの種類に対してステップ３６５８（Sudpの再設定）の前回の実行以降にＵＤＰチャネルで送信されたデータ量（Sudp）が許可される最大値（Wudp-max）以下である場合（ステップ３８１のテストに対する応答がｙｅｓの場合）、優先チャネルがＴＣＰチャネルであっても、処理パケットはＵＤＰチャネルで送信される（ステップ３８５が実行された後、ステップ３８６及びステップ３８７に進む）；
−処理されるパケットの種類に対してステップ３６５８（Sudpの再設定）の前回の実行以降にＵＤＰチャネルで送信されたデータ量（Sudp）が許可される最大値（Wudp-max）を上回る場合（ステップ３８１のテストに対する応答が否定である場合）、処理パケットはＴＣＰチャネルで送信される（ステップ３２が実行された後、ステップ３８３及びステップ３８４に進む）。
【０１７５】
図９は、本発明の教示を実現するように構成される通信装置１０００（図１ａのトンネル終端１０１又は１０２）の概略的な構成を示す。通信装置１０００は、中央処理装置（ＣＰＵ）１００１の主メモリ、作業領域等として動作するＲＡＭ１００２を具備する。そのメモリ容量は、拡張ポートに接続されるオプションのＲＡＭ（不図示）により拡張されてもよい。中央処理装置１００１は、通信装置の電源が投入されると、プログラムのＲＯＭ１００３からの命令を実行できる。電源投入後、中央処理装置１００１は、命令が例えばプログラムＲＯＭ１００３又はハードディスクドライブ（ＨＤＤ）１００６からロードされた後、ソフトウェアアプリケーションに関連する主メモリ１００２からの命令を実行できる。そのようなソフトウェアアプリケーションは、中央処理装置１００１により実行されるが、図２ｂ、図２ｃ、図３、図４、図５、図６、図７ａ、図８ａ、図８ｂ及び図８ｃに示されるフローチャートの全て又は一部のステップの実行を指示する。
【図面の簡単な説明】
【０１７６】
【図１ａ】トンネルを使用する一般的な仮想プライベートネットワーク（ＶＰＮ）構成を示す図である。
【図１ｂ】本発明の方法が実現されるトンネル終端の従来の階層モデルの一例を示す図である。
【図２ａ】レベル２トンネルパケットを搬送するイーサネットフレームの形式の一例を示す図である。
【図２ｂ】本発明に係る方法の特定の一実施形態において、トンネルを介して送信するトンネル終端により実行されるアウトバウンドアルゴリズムを示すフローチャートである。
【図２ｃ】本発明に係る方法の特定の一実施形態に従って、トンネルを介して受信するトンネル終端により実行されるインバウンドアルゴリズムを示すフローチャートである。
【図３】本発明に係る方法の特定の一実施形態に従って、有効チャネルを選択するためのアルゴリズム（図２ｂのステップ３の詳細）を示すフローチャートである。
【図４】本発明に係る方法の特定の一実施形態に従って、優先チャネルを選択するための３つの別個のアルゴリズム（図３のステップ３５の詳細）を示すフローチャートである。
【図５】本発明に係る方法の特定の一実施形態に従って、優先チャネルを選択するための３つの別個のアルゴリズム（図３のステップ３５の詳細）を示すフローチャートである。
【図６】本発明に係る方法の特定の一実施形態に従って、優先チャネルを選択するための３つの別個のアルゴリズム（図３のステップ３５の詳細）を示すフローチャートである。
【図７ａ】本発明に係る方法の特定の一実施形態に従って、ある種類のパケットに対する送信ウィンドウ及び現在の転送モードを管理するためのアルゴリズム（図３のステップ３６の詳細）を示すフローチャートである。
【図７ｂ】本発明の方法の特定の一実施形態に係るパケットの種類を示す表である。
【図８ａ】本発明の特定の一実施形態に係るＵＤＰ−ＴＣＰ過渡モードを管理するためのアルゴリズムを示すフローチャートである。
【図８ｂ】本発明の特定の一実施形態に係るＴＣＰ−ＵＤＰ過渡モードを管理するためのアルゴリズムを示すフローチャートである。
【図８ｃ】本発明に係る方法の特定の一実施形態に従って、ある種類のパケットに対する有効チャネルを選択するためのアルゴリズム（図３のステップ３８の詳細）を示すフローチャートである。
【図９】本発明の特定の一実施形態に係る通信装置（トンネル終端）の構成を示す図である。
【図１ａ】
0004669536.tif 000002
【図２ａ】
0004669536.tif 000003
【図２ｂ】
0004669536.tif 000004
【図２ｃ】
0004669536.tif 000005
【図３】
0004669536.tif 000006
【図４】
0004669536.tif 000007
【図５】
0004669536.tif 000008
【図６】
0004669536.tif 000009
【図７ａ】
0004669536.tif 000010
【図７ｂ】
0004669536.tif 000011
【図８ａ】
0004669536.tif 000012
【図８ｂ】
0004669536.tif 000013
【図８ｃ】
0004669536.tif 000014
【図９】
0004669536.tif 000015
【図１ｂ】
0004669536.tif 000016