(57)【特許請求の範囲】
【請求項１】
トンネルデスティネーションポイントとして作用するパケットサーバにおいて使用される通信方法において、
１つまたは複数のエンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージを受信するステップと、
前記１つまたは複数のエンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージで運ばれた情報を用いて、エンドツーエンドＲＳＶＰセッションをトンネルにマッピングするステップとを有する通信方法。
【請求項２】
カプセル化された１つまたは複数のエンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージをトンネルソースポイントへ送るステップをさらに有し、
前記カプセル化された１つまたは複数のエンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージは、前記トンネルおよび前記マッピングされるエンドツーエンドＲＳＶＰセッションについてのマッピング情報を含む請求項１に記載の方法。
【請求項３】
前記マッピング情報は、前記カプセル化された１つまたは複数のエンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージに添付されたTUNNEL_BINDINGオブジェクトにより送信される請求項２に記載の方法。
【請求項４】
前記マッピングするステップは、前記受信した１つまたは複数のエンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージから抽出されるスラック時間値と、最小トンネル遅延値との関数として、前記エンドツーエンドＲＳＶＰセッションを前記トンネルに割り当てる請求項１に記載の方法。
【請求項５】
前記受信するステップの前に、受信側へ送信されるＡＤＳＰＥＣオブジェクトで単一の遅延値を公示するステップをさらに有する請求項１に記載の方法。
【請求項６】
バーストサイズのような少なくとも１つのトンネルパラメータを調整することによって、確立されたトンネルをチューニングするステップをさらに有する請求項１に記載の方法。
【請求項７】
確立されたトンネルを再構成し、必要であれば、エンドツーエンドＲＳＶＰセッションを再割当てすることによって、前記確立されたトンネルをチューニングするステップをさらに有する請求項１に記載の方法。
【請求項８】
トンネルデスティネーションポイントとして作用する通信装置において、
（ａ）１つまたは複数のＲＳＶＰ  ＲＥＳＶメッセージを受信し、かつ、（ｂ）前記１つまたは複数のＲＳＶＰ  ＲＥＳＶメッセージで運ばれた情報を用いて、エンドツーエンドＲＳＶＰセッションをトンネルにマッピングするパケットサーバを有する通信装置。
【請求項９】
前記パケットサーバは、カプセル化された１つまたは複数のＲＳＶＰ  ＲＥＳＶメッセージをトンネルソースポイントへ送り、
前記カプセル化された１つまたは複数のＲＳＶＰ  ＲＥＳＶメッセージは、前記トンネルおよび前記マッピングされるエンドツーエンドＲＳＶＰセッションについてのマッピング情報を含む請求項８に記載の装置。
【請求項１０】
前記マッピング情報は、前記カプセル化された１つまたは複数のＲＳＶＰ  ＲＥＳＶメッセージに添付されたTUNNEL_BINDINGオブジェクトにより送信される請求項９に記載の装置。
【請求項１１】
前記パケットサーバは、前記受信した１つまたは複数のＲＳＶＰ  ＲＥＳＶメッセージから抽出されるスラック時間値と、最小トンネル遅延値との関数として、前記エンドツーエンドＲＳＶＰセッションを前記トンネルにマッピングする請求項８に記載の装置。
【請求項１２】
前記パケットサーバは、前記１つまたは複数のＲＳＶＰ  ＲＥＳＶメッセージを受信する前に、受信側へ送信されるＡＤＳＰＥＣオブジェクトで単一の遅延値を公示する請求項８に記載の装置。
【請求項１３】
前記パケットサーバは、バーストサイズのような少なくとも１つのトンネルパラメータを調整することによって、確立されたトンネルをチューニングする請求項８に記載の装置。
【請求項１４】
前記パケットサーバは、確立されたトンネルを再構成し、必要であれば、エンドツーエンドＲＳＶＰセッションを再割当てすることによって、前記確立されたトンネルをチューニングする請求項８に記載の装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信に関し、特に、パケット通信システムに関する。
【０００２】
【従来の技術】
以前は、インターネットを用いたすべてのデータトラフィックは平等に扱われ、「ベスト・エフォート」メカニズムを用いてトランスポートされた。しかし、時が経つにつれて、インターネットを通じてのリアルタイムアプリケーション（例えば、オーディオ／ビデオ会議ツール、ゲームアプリケーションなど）をサポートすることへの需要から、何らかの形の差別化されたサービス（ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  ｓｅｒｖｉｃｅ）提供の必要性が生じた。そこで、当業者は、サービス品質（ＱｏＳ）をインターネットユーザに提供する新たなプロトコルを提案している。
【０００３】
ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  ＲｅＳｅｒＶａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）はそのようなプロトコルの１つである。ＲＳＶＰは、受信側ホストがデータフローパスを通じてネットワークエレメントへ所望のサービスを通知するために使用される受信側主導のエンドツーエンドプロトコルである。ＲＳＶＰでは、ＱｏＳ要求の粒度（グラニュラリティ：ｇｒａｎｕｌａｒｉｔｙ）は、パケットフローごとに決定される（例えば、Ｂ．  Ｂｒａｄｅｎ，  Ｌ．  Ｚｈａｎｇ，  Ｓ．  Ｂｅｒｓｏｎ，  Ｓ．  Ｈｅｒｚｏｇ，  Ｓ．  Ｊａｍｉｎ，  ”Ｒｅｓｏｕｒｃｅ  ＲｅＳｅｒＶａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  （ＲＳＶＰ）  −  Ｖｅｒｓｉｏｎ  Ｉ  Ｆｕｎｃｔｉｏｎａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ”，  ＲＦＣ  ２２０５、を参照）。
【０００４】
しかし、パケットフローごとにＱｏＳ保証を提供することは、バックボーンルータにスケーラビリティの問題点を生じる（例えば、Ｒ．  Ｇｕｅｒｉｎ，  Ｓ．  Ｂｌａｋｅ，  Ｓ．  Ｈｅｒｚｏｇ，  ”Ａｇｇｒｅｇａｔｉｎｇ  ＲＳＶＰ−ｂａｓｅｄ  ＱｏＳ  Ｒｅｑｕｅｓｔｓ”，  ｄｒａｆｔ−ｇｕｅｒｉｎ−ａｇｇｒｅｇ−ｒｓｖｐ−００．ｔｘｔ，  Ｎｏｖ．  １９９７、を参照）。例えば、ルータにおいて各パケットフロー（本明細書では、「ＴＣＰ／ＩＰセッション」ともいう）ごとに、例えばＴＣＰ／ＩＰソース、ＴＣＰ／ＩＰデスティネーション、およびＴＣＰ／ＩＰプロトコル番号を含む予約状態がある。このため、ルータが各ＴＣＰ／ＩＰセッションを追跡することが必要であることにより、多くのルータメモリと処理リソースを消費する。さらに、ＲＳＶＰのエンドツーエンド性により、ネットワークを通じて仮想パイプを予約するために使用することは不適当になる。
【０００５】
上記の問題点に対する１つの解決法は、パケットフローをまとめて２つのルータの間にＲＳＶＰトンネルを設けることである。この解決法については、
・Ｒ．  Ｇｕｅｒｉｎ，  Ｓ．  Ｂｌａｋｅ，  Ｓ．  Ｈｅｒｚｏｇ，  ”Ａｇｇｒｅｇａｔｉｎｇ  ＲＳＶＰ−ｂａｓｅｄ  ＱｏＳ  Ｒｅｑｕｅｓｔｓ”，  ｄｒａｆｔ−ｇｕｅｒｉｎ−ａｇｇｒｅｇ−ｒｓｖｐ−００．ｔｘｔ，  Ｎｏｖ．  １９９７・Ａ．  Ｔｅｒｚｉｓ，  Ｊ．  Ｋｒａｗｃｚｙｋ，  Ｊ．  Ｗｒｏｃｌａｓｋｉ，  Ｌ．  Ｚｈａｎｇ，  ”ＲＳＶＰ  Ｏｐｅｒａｔｉｏｎ  ｏｖｅｒＩＰ  ｔｕｎｎｅｌｓ”，  ｄｒａｆｔ−ｉｅｔｆ−ｒｓｖｐ−ｔｕｎｎｅｌ−０３．ｔｘｔ，  Ａｕｇ．  １９９８に記載されている。ここで、一対のトンネルエンドポイントを通るＲＳＶＰセッションは、相異なるサービス（例えば、保証付きサービス（ｇｕａｒａｎｔｅｅｄ  ｓｅｒｖｉｃｅ：最悪の遅延を保証する）や負荷制御サービス（ｃｏｎｔｒｏｌｌｅｄ  ｌｏａｄ  ｓｅｒｖｉｃｅ：最低帯域幅を保証する））を提供することが可能であり、同じサービスが相異なるパラメータ（例えば、保証付きサービスにおける相異なる遅延要求）を有し、あるいは、類似のサービスが相異なるポリシを有する。こうして、一対のトンネルエンドポイントの間に複数の異なるトンネルが存在することが可能となる。
【０００６】
【発明が解決しようとする課題】
上記のような、ＲＳＶＰベースのＱｏＳ要求をまとめる修正された形式のＲＳＶＰはこの問題点に対する１つの解決法ではあるが、このような修正された形式のＲＳＶＰはもはや純粋に受信側指向ではない。特に、エンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージ（受信側から送信側へ）で運ばれる情報は、トンネルソースポイントがセッションからトンネルへのマッピングについて決定する際には使用されない。これは、ＲＳＶＰの受信側指向パラダイムに違反するのみならず、帯域幅の利用が非効率になる可能性がある。
【０００７】
【課題を解決するための手段】
そこで、本発明において、トンネルソースポイント（ＴＳＰ：ｔｕｎｎｅｌ  ｓｏｕｒｃｅ  ｐｏｉｎｔ）とトンネルデスティネーションポイント（ＴＤＰ：ｔｕｎｎｅｌ  ｄｅｓｔｉｎａｔｉｏｎ  ｐｏｉｎｔ）の間のパケットトンネルを通じて、ＲＳＶＰの受信側主導パラダイムと整合性のある方法でエンドツーエンドＲＳＶＰセッションを確立する新規なＲＳＶＰベースのトンネルプロトコルを開発した。特に、エンドツーエンドＲＳＶＰセッションは、受信側指向ＲＳＶＰタイプのシグナリングを用いて、ＴＤＰがトンネルマッピングを決定するようにマッピングされる。このように、この新しいＲＳＶＰタイプのプロトコルは、ＲＳＶＰの受信側主導性と整合性があるため、既存のＲＳＶＰプロトコルを変更する必要がない。
【０００８】
本発明の実施例では、ＲＳＶＰプロトコルは、エンドツーエンドＲＳＶＰセッションから、ＴＳＰとＴＤＰの間のトンネルへの受信側指向マッピングをサポートするように変更される。特に、ＴＤＰは、エンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージで運ばれる情報を使用して、セッションからトンネルへのマッピングを決定する。このマッピングは、新しいＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトを通じてＴＳＰへ送信される。
【０００９】
本発明の別の特徴によれば、保証付きサービスを提供する際に、ＴＤＰは動的にＴＳＰへのトンネルを構成し、確立されたトンネルに対するトンネル調整（チューニング）を実行する。後者の特徴により、帯域効率を改善するために、トラフィック条件に既存のトンネルを動的に適応させることが可能となる。トンネルチューニング手続きは、受け付けられたエンドツーエンドＲＳＶＰセッションの一部のトンネル再割当てを引き起こすこともある。
【００１０】
【発明の実施の形態】
以下の説明は大きくいくつかの部分に分かれる。最初の部分では、高水準の背景知識について簡単に説明した後、新しいＲＳＶＰベースのトンネルプロトコルの概観を行う。概観のセクションに続いて、トンネル管理、受信側主導トンネル割当て／受付制御、トンネル設定、およびトンネルチューニングについてさらに詳細なセクションがある。
【００１１】
概観
背景知識として、保証付きサービスのＲＳＶＰセッションに加入するための、例示的なエンドツーエンドＲＳＶＰメッセージトランザクションの一部を図１に示す。送信側は、ＲＳＶＰ  ＰＡＴＨメッセージを（ユニキャスト、またはマルチキャストのＩＰアドレスによって識別される）受信側へ送る。ＲＳＶＰ  ＰＡＴＨメッセージには、ＳＥＮＤＥＲ  ＴＳＰＥＣオブジェクトおよびＡＤＳＰＥＣオブジェクトが添付される。ＳＥＮＤＥＲ  ＴＳＰＥＣオブジェクトは、送信側が送信することが可能なフロー特性を指定し、ＡＤＳＰＥＣオブジェクトは、受信側へのパスにあるルータによる変更を受けるパラメータを含む。受信側は、予約を行うとき、その遅延要求と、ＡＤＳＰＥＣオブジェクトに含まれるパラメータ（これは、前述のように、上記のルータ（図示せず）によって変更されている可能性がある）とに従って、必要とする帯域幅を計算する。その後、受信側は、ＲＳＶＰ  ＰＡＴＨメッセージがたどったパスに沿って帯域を予約するために、ＲＳＶＰ  ＲＥＳＶメッセージをアップストリームへ送信する。これらの動作の詳細は、
・Ｓ．  Ｓｈｅｎｋｅｒ，  Ｃ．  Ｐａｒｔｒｉｄｇｅ  ａｎｄ  Ｒ．  Ｇｕｅｒｉｎ，  ”Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  Ｇｕａｒａｎｔｅｅｄ
Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ”，  ＲＦＣ  ２２１２
・Ｊ．  Ｗｒｏｃｌａｗｓｋｉ，  ”Ｔｈｅ  Ｕｓｅ  ｏｆ  ＲＳＶＰ  ｗｉｔｈ  ＩＥＴＦ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ”，  ＲＦＣ  ２２１０
に記載されている。
【００１２】
上記のように、ＲＳＶＰトンネルを通じてエンドツーエンドＲＳＶＰセッションを運ぶことが可能である。ＲＳＶＰトンネルは、ＴＳＰを送信側としＴＤＰを受信側とするＲＳＶＰセッションにほかならない。エンドツーエンドＲＳＶＰセッションがＴＳＰとＴＤＰの間に形成されるとき、ＴＳＰは、このエンドツーエンドセッションを、これらの間のｍ個のＲＳＶＰトンネルのうちの１つにマッピングする。このｍ個のトンネルのセットは、例えば、当業者に周知のポリシング（監視）サーバあるいはＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｚａｔｉｏｎ  ａｎｄ  Ａｃｃｏｕｎｔｉｎｇ：認証許可課金）サーバを使用することによって、ＴＳＰとＴＤＰの間にあらかじめ確立される。その結果、ＴＳＰとＴＤＰの間のフローごとに１つのＲＳＶＰセッションを使う代わりに、複数のフローが単一のＲＳＶＰトンネルにまとめられるため、中間ルータで保持される状態数を大幅に削減することが可能となる。エンドツーエンドフローのデータがＴＳＰに到着すると、このデータは、同じトンネルに属するさまざまなフローを中間ルータが差別しないように、カプセル化される。相異なるＲＳＶＰトンネルを区別するため、ＩＰ−ｉｎ−ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）カプセル化が用いられる。このカプセル化については、前掲のＴｅｒｚｉｓ  ｅｔ  ａｌ．，  ”ＲＳＶＰ  Ｏｐｅｒａｔｉｏｎｓ  ｏｖｅｒ  ＩＰ  ｔｕｎｎｅｌｓ”の論文に記載されている。このカプセル化方式（この論文にはタイプ２トンネル（Ｔｙｐｅ  ２  ｔｕｎｎｅｌ）として記載されている）では、ＵＤＰデスティネーションポート番号がトンネル識別子として用いられる。１つのトンネルにまとめられた後、ここのフローは、同じトンネル内の他のフローと帯域を共有しなければならない。従って、前掲のＧｕｅｒｉｎ  ｅｔ  ａｌ．，  ”Ａｇｇｒｅｇａｔｉｎｇ  ＲＳＶＰ−ｂａｓｅｄ  ＱｏＳ  Ｒｅｑｕｅｓｔｓ”の論文に記載されているように、トンネルは、エンドツーエンドフローのＡＤＳＰＥＣを更新するときには、純粋な遅延ネットワークエレメントとして扱わなければならない。トンネルを通じてエンドツーエンドＲＳＶＰセッションを確立するための従来のメッセージトランザクションの一部を図２に示す。前述のように、上記の修正された形式のＲＳＶＰ（図２に示したもの）は、ＲＳＶＰの受信側主導パラダイムと整合しない。ＴＳＰが、受信側に関する情報なしで、トンネルマッピングと、エンドツーエンドＲＳＶＰセッションについてのマッピング情報を決定するからである。
【００１３】
そこで、本発明において、ＴＳＰとＴＤＰの間のパケットトンネルを通じて、ＲＳＶＰの受信側主導パラダイムと整合性のある方法でエンドツーエンドＲＳＶＰセッションを確立する新規なＲＳＶＰベースのトンネルプロトコルを開発した。特に、エンドツーエンドＲＳＶＰセッションは、ＴＤＰがエンドツーエンドＲＳＶＰメッセージ内の情報を用いてトンネルマッピングを決定するように、受信側指向ＲＳＶＰタイプのシグナリングを用いてマッピングされる。
【００１４】
本発明の原理による例示的なネットワーク１０を図３に示す。図３において、本発明の概念に関するもの以外の要素は周知であり、詳細には説明しない。例えば、インターネットサービスプロバイダ（ＩＳＰ）１５は、単一ブロックのエレメントとして示されているが、蓄積プログラム制御プロセッサ、メモリ、およびルータ／サーバ（例えば、ＰＯＰ（ｐｏｉｎｔ−ｏｆ−ｐｒｅｓｅｎｃｅ、アクセスポイント）ルータ、ネットワークアクセスサーバ（ＮＡＳ：Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｓｅｒｖｅｒ）など）を含む（図示せず）。ネットワーク１０は、インターネット５０を通じて接続された、ＩＳＰ１５およびＩＳＰ２５で表されるような複数のＩＳＰを含む。インターネット５０は、インターネットプロトコル（ＩＰ）に基づくネットワークインフラストラクチャを表し、パケットエンドポイントどうしの間でＩＰパケットを通信するためのルータなどのような他のコンポーネント（図示せず）を含む。同様に、ネットワーク１０のエレメントどうしの間の実線は、それぞれのエンドポイントどうしの間の周知の通信設備を表す。例えば、ＩＳＰ１５とインターネット５０の間のコネクション（ライン２２で示す）は、ＳＯＮＥＴ（光同期網：ｓｙｎｃｈｒｏｎｏｕｓ  ｏｐｔｉｃａｌ  ｎｅｔｗｏｒｋ）上の非同期転送モード（ＡＴＭ）によってサポートされる、などである。同様に、ライン１１および２１は、それぞれＩＳＰ１５およびＩＳＰ２５を通じて、ネットワーク１０に出入りする任意の個数および種類の通信設備（例えば、複数のＴ１／Ｅ１回線（それぞれの方向に対して）を表す。（このトラフィックの送信側および受信側は簡単のため図示しない。）さらに、上記のＲＳＶＰプロトコルについては周知であると仮定する。ＲＳＶＰは、統合サービス（例えば、保証付きサービスまたは負荷制御サービス）をサポートするが、ここでの説明は例として保証付きサービスを使用する。また、ここでの説明の目的では、ＩＳＰ１５およびＩＳＰ２５の動作は相補的であって、ＩＳＰ１５はＴＳＰであり、ＩＳＰ２５はＴＤＰであると仮定する。このように、本明細書では、ＴＳＰとＴＤＰは固定され、互いを知っている（例えば、相手のアドレスを知っている）と仮定する。さらに、ＴＳＰは、どのトラフィックフローを、ＴＤＰを通じてルーティングしなければならないかを知っているとする。この場合、以下でさらに説明するように、ＲＳＶＰトンネル６０（破線）は、ＩＳＰ１５をＩＳＰ２５に接続するように設定され、ＲＳＶＰトンネル６０を通じてルーティングされる必要のあるトラフィックは、対応するトラフィックのデスティネーションサブネットアドレスによって識別される。
【００１５】
本明細書の残りの部分では、トンネルに関するＲＳＶＰメッセージをエンドツーエンドフローのものから区別するために、トンネルに関するＲＳＶＰメッセージに”ＴＵＮＮＥＬ＿”というプレフィクスを付加する。さらに、エンドツーエンドフローのデータがＴＳＰに到着した場合、前掲のＴｅｒｚｉｓ  ｅｔ  ａｌ．，  ”ＲＳＶＰ  Ｏｐｅｒａｔｉｏｎｓ  ｏｖｅｒ  ＩＰ  ｔｕｎｎｅｌｓ”の論文に記載されているように、タイプ２トンネルがカプセル化のために使用されると仮定する。同様に、各トンネルは、前掲のＧｕｅｒｉｎ  ｅｔ  ａｌ．，  ”Ａｇｇｒｅｇａｔｉｎｇ  ＲＳＶＰ−ｂａｓｅｄ  ＱｏＳ  Ｒｅｑｕｅｓｔｓ”の論文に記載されているように、純粋な遅延ネットワークエレメントとして扱われる。
【００１６】
まず、ｍ個のトンネル６０のセットが、ＴＳＰとＴＤＰの間に存在すると仮定する。本発明による、例示的なＲＳＶＰエンドツーエンドメッセージトランザクションの一部を図４に示す。また、図５には、ＴＤＰにおいて使用される、本発明の原理による例示的な流れ図を示す。ＴＤＰは、通常のプログラミング技術を用いて下記の方法を実行するように適切にプログラムされると仮定し、そのようなプログラミング技術についてはここでは説明しない。ＲＳＶＰは受信側主導のプロトコルであるため、新しいエンドツーエンドＲＳＶＰ  ＰＡＴＨメッセージがＴＳＰに到着すると、ＴＳＰは単にそのエンドツーエンドＲＳＶＰ  ＰＡＴＨメッセージをカプセル化してＴＤＰへ送る。（これは、トンネルは事前に静的に構成されていないことを仮定している。）ＴＤＰは、カプセル化されたエンドツーエンドＲＳＶＰ  ＰＡＴＨメッセージを受信すると（図５のステップ２０５）、そのカプセル化を解除し、ＡＤＳＰＥＣを更新し（図５のステップ２１０）、ＲＳＶＰエンドツーエンドシグナリングに従って、対応する受信側（図示せず）へ転送する（図５のステップ２１５）。受信側（図示せず）はＲＳＶＰ  ＰＡＴＨメッセージを受信した後、このＲＳＶＰセッションに必要なパラメータを（従来技術と同様に）計算し、エンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージを返送する。ＴＤＰは、このＲＳＶＰ  ＲＥＳＶメッセージを受信すると（図５のステップ２２０）、本発明に従って、受信側主導のトンネル割当て／受付制御手続きを実行することによってこのエンドツーエンドＲＳＶＰセッションのための適当なＲＳＶＰトンネルを決定し（図５のステップ２２５、詳細は後述）、受け付けられた場合（図５のステップ２３０）、セッションからトンネルへのバインディングをＴＳＰに通知するためにＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトを形成する。（受け付けられない場合、図５のステップ２３５でセッションは拒否される。）次に、ＴＤＰは、エンドツーエンドＲＳＶＰ  ＲＥＳＶメッセージを（添付されたＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトとともに）カプセル化してＴＳＰへ送り（図５のステップ２４０）、ＴＳＰはそれをカプセル化解除する。ＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトを受信した場合、ＴＳＰは、エンドツーエンドＲＳＶＰセッションのために、ＴＤＰによって割り当てられたトンネルを使用する。ＴＳＰは、ＲＳＶＰ  ＲＥＳＶメッセージの残りの部分をアップストリームの送信側（図示せず）へ転送する。その結果、この修正されたシグナリングにより、ＴＤＰは、トンネルのパラメータおよびエンドツーエンドＲＥＳＶメッセージに基づいてエンドツーエンドＲＳＶＰセッションにトンネルを割り当てることが可能となる。
【００１７】
上記のメッセージに関して、ＲＳＶＰ  ＰＡＴＨメッセージフォーマットを図６に示す。ＲＳＶＰ  ＡＤＳＰＥＣオブジェクトを図７および図８に示す。図９に、ＲＳＶＰ  ＲＥＳＶメッセージを、ＳＥＳＳＩＯＮオブジェクトおよびＦＬＯＷＳＰＥＣオブジェクトとともに示す。（なお、本発明の概念以外については、これらのフォーマットはＲＳＶＰで定義されている通りである。）本発明による、ＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトの例示的なフォーマットを図１０に示す。（認識されるように、ＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトフォーマットは、前掲のＴｅｒｚｉｓ  ｅｔ  ａｌ．，  ”ＲＳＶＰ  Ｏｐｅｒａｔｉｏｎｓ  ｏｖｅｒ  ＩＰ  ｔｕｎｎｅｌｓ”の論文に記載されているＳＥＳＳＩＯＮオブジェクトに類似している。）
【００１８】
その後、ＴＳＰは、データトラフィックを受信すると、セッション−トンネルバインディングに基づいて、適当なＩＰ−ｉｎ−ＵＤＰヘッダとともにパケットをカプセル化する。また、ＴＳＰは、個々のＴＳＰＥＣに従わない各フローからのデータトラフィックをマークしなければならない。このことは、ＴＳＰが、当業者に周知のように各フローに対するポリシング（監視）機能を備える必要があることを意味する。
【００１９】
なお、トンネルは、はじめに仮定したように事前に構成されている必要はない。特に、ＴＤＰは、ＴＳＰへのトンネルを動的に構成することが可能である（詳細は後述）。このタイプのメッセージトランザクションを図１１に示す。（なお、ＴＤＰにおいてトンネルを動的に構成する機能以外の点では、このタイプのメッセージフロートランザクションは従来技術と同一である。すなわち、あらかじめ構成されたトンネルの場合でも、このタイプのメッセージフローは生じる。）図１１に関して、ＲＳＶＰトンネルを確立するため、ＴＳＰは送信側（すなわちデータソース）として作用し、ＴＤＰのユニキャストアドレスへＴＵＮＮＥＬ＿ＰＡＴＨメッセージを送る。このＴＵＮＮＥＬ＿ＰＡＴＨメッセージには、ＴＵＮＮＥＬ＿ＡＤＳＰＥＣオブジェクトが添付される。本発明の特徴によれば（後述）、ＴＤＰは、受信したＴＵＮＮＥＬ＿ＡＤＳＰＥＣオブジェクトに含まれるパラメータに基づいて、確立するトンネルの個数と、それらのトンネルの間でどのようにリソースを割り当てるかを決定する。その後、ＴＤＰは、トンネルを確立するために、ＴＳＰへＴＵＮＮＥＬ＿ＲＥＳＶメッセージを送る。
【００２０】
上記の各トンネル設定は、Ｓ．  Ｓｈｅｎｋｅｒ  ａｎｄ  Ｊ．  Ｗｒｏｃｌａｗｓｋｉ，  ”Ｇｅｎｅｒａｌ  Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ  Ｐａｒａｍｅｔｅｒｓ  ｆｏｒ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔｓ”，  ＲＦＣ  ２２１５、の論文で定義されている制御負荷サービスあるいは保証付きサービスのいずれも提供することが可能である。以下のセクションでは、保証付きサービスを提供するトンネルを管理するための追加のアルゴリズムについて説明する。
【００２１】
保証付きサービスのためのトンネル管理
ＴＤＰで実行される受信側主導割当て／受付制御、トンネル構成、およびトンネルチューニング手続きの説明に進む前に、トンネルに関する以下の情報について説明する。
【００２２】
相異なるエンドツーエンドＲＳＶＰセッションは相異なる遅延要求を有することがある。従って、各トンネルごとに異なる遅延保証を有することが有効である。ＴＳＰとＴＤＰの間にｎ個のトンネルがあり、各トンネルの遅延保証がｄ１Ｔ＜ｄ２Ｔ＜．．．＜ｄｎＴであると仮定する。その場合、ＴＳＰとＴＤＰの間で遅延保証ｄを要求するエンドツーエンドＲＳＶＰセッションは、トンネルｉが十分な容量を有すると仮定して、ｄｉＴ＜ｄ＜ｄｉ＋１Ｔである場合にトンネルｉにマッピングされることになる。
【００２３】
そこで、トンネルｉのＴＳＰＥＣをベクトルＴＳｉＴ＝（ｂｉＴ，ｒｉＴ，ｐｉＴ，ＭｉＴ，ｍｉＴ）で表す。ただし、ｂｉＴはバーストサイズであり、ｒｉＴは平均レートであり、ｐｉＴはピークレートであり、ＭｉＴはトンネルメッセージ転送ユニット（ＭＴＵ：ｍｅｓｓａｇｅ  ｔｒａｎｓｆｅｒ  ｕｎｉｔ）であり、ｍｉＴは課金ユニット（例えば、前掲のＳｈｅｎｋｅｒ  ｅｌ  ａｌ．，  ”Ｇｅｎｅｒａｌ  Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ  Ｐａｒａｍｅｔｅｒｓ  ｆｏｒ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔｓ”の論文を参照）である。一般に、トンネルｉに関連するＣおよびＤの値（前掲のＳｈｅｎｋｅｒ  ｅｔ  ａｌ．，  ”Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  Ｇｕａｒａｎｔｅｅｄ  Ｑｕａｌｉｔｙｏｆ  Ｓｅｒｖｉｃｅ”の論文を参照）（Ｃｔｏｔ，ｉＴおよびＤｔｏｔ，ｉＴで表す）はＴＳｉＴの関数であり、従って、各トンネルごとに異なることがある。（なお、保証付きサービスの場合、Ｄｔｏｔ，ｉＴは更新されるがＣｔｏｔ，ｉＴは更新されない。）
【００２４】
一般性を失うことなく、それぞれ遅延ｄ１Ｔおよびｄ２Ｔを保証する２つのトンネルを考える。遅延保証ｄは次式により計算される。
ｄ＝（ｂ＋Ｃ）／Ｒ＋Ｄ    （１）
ただし、ｂはバーストサイズであり、Ｒは予約される帯域幅であり、ＣおよびＤは前掲のＳｈｅｎｋｅｒ  ｅｔ  ａｌ．，  ”Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  Ｇｕａｒａｎｔｅｅｄ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ”の論文で定義される通りである。
【００２５】
各トンネルは、次の帯域幅を要求することになる。
ＲｉＴ＝（ｂｉＴ＋Ｃｔｏｔ，ｉＴ）／（ｄｉＴ−Ｄｔｏｔ，ｉＴ）    （２）
ただし、ｉ＝１，２である。２つのトンネルをまとめた（グループ化した）場合、保証遅延ｄ１Ｔがなければならず、新しいＴＳＰＥＣはＴＳｇＴ＝（ｂ１Ｔ＋ｂ２Ｔ，ｒ１Ｔ＋ｒ２Ｔ，ｐ１Ｔ＋ｐ２Ｔ，ｍａｘ｛Ｍ１Ｔ，Ｍ２Ｔ｝，ｍｉｎ｛ｍ１Ｔ，ｍ２Ｔ｝）となる。対応して、このトンネルは、Ｃｔｏｔ，ｇＴおよびＤｔｏｔ，ｇＴを有することになり、次の帯域幅を要求する。
ＲｇＴ＝（ｂ１Ｔ＋ｂ２Ｔ＋Ｃｔｏｔ，ｇＴ）／（ｄ１Ｔ−Ｄｔｏｔ，ｇＴ）    （３）
【００２６】
明らかに、ＲｇＴ≦Ｒ１Ｔ＋Ｒ２Ｔの場合、２個ではなく１個のトンネルを設定するほうが有利である。
【００２７】
中間ルータが、ＴＳＰから送信されるＴＵＮＮＥＬ＿ＴＳＰＥＣに部分的に基づいて、ＴＵＮＮＥＬ＿ＡＤＳＰＥＣ内のＣｔｏｔおよびＤｔｏｔを更新するため、ＴＤＰが別のＴＵＮＮＥＬ＿ＴＳＰＥＣを使用することを決定する場合、ＣｔｏｔＴ＝ｆ（ＴＵＮＮＥＬ＿ＴＳＰＥＣ）およびＤｔｏｔＴ＝ｈ（ＴＵＮＮＥＬ＿ＴＳＰＥＣ）もまた異なることがある。ただし、ｆおよびｈは、ＴＳＰおよびＴＤＰには未知の関数である。その結果、ＴＤＰは一般に、ＲＴを正しく計算するために、関数ｆおよびｈを知る必要がある。
【００２８】
関数ｆおよびｈを求めるため、ＴＳＰは、相異なるＴＵＮＮＥＬ＿ＴＳＰＥＣを有するいくつかのＴＵＮＮＥＬ＿ＰＡＴＨメッセージを送出することができる。ＴＤＰは、これらのＴＵＮＮＥＬ＿ＴＳＰＥＣを、対応するＴＵＮＮＥＬ＿ＡＤＳＰＥＣとともに受信すると、ｆおよびｈを補間により評価することができる。トンネル予約に使用されないＴＵＮＮＥＬ＿ＰＡＴＨメッセージはタイムアウトすることになる。
【００２９】
実際には、ｆおよびｈは、複雑な関数である可能性は少ない。例えば、中間ルータがすべてＷＦＱ（重み付き公平キューイング：ｗｅｉｇｈｔｅｄ  ｆａｉｒ  ｑｕｅｕｅｉｎｇ）を実装している場合、ＣｔｏｔＴ＝（ｋ−１）ＭＴ、および、ＤｔｏｔＴ＝ΣｊｋＭＴ／Ｃｊである。ただし、ｋは、トンネル内のホップ数であり、Ｃｊは、各ホップのリンク速度である。この場合、ＴＳＰは、ＴＵＮＮＥＬ＿ＴＳＰＥＣ内の他のすべての成分を固定したままＭＴの値を変えていくつかのＴＵＮＮＥＬ＿ＰＡＴＨメッセージを送信する。すると、ＴＤＰは、ＴＵＮＮＥＬ＿ＴＳＰＥＣおよびＴＵＮＮＥＬ＿ＡＤＳＰＥＣからデータ（ＭｊＴ，ＣｊＴ，ＤｊＴ）のセットを収集し、これらを、それぞれＣｊＴおよびＤｊＴの上限である、ＭＴの１次関数に当てはめる。
【００３０】
ＴＳＰとＴＤＰの間に複数のパスが存在する場合、ＣｔｏｔＴおよびＤｔｏｔＴの値は、異なるパスでは非常に異なることがある（そうでなければ、これらのパスを区別する必要がない）。このような場合、ＴＤＰは、まず、データを分類してクラスタに分けてから、補間に進む。あるいは、ＴＤＰは、すべてのクラスタに対するＣＴおよびＤＴの単一の上限を求めることも可能であるが、これは控えめすぎることがある。
【００３１】
トンネル管理を簡単にするため、トンネルＭＴＵが、すべてのトンネルに対するＭＴとして常に使用される。さらに、与えられたＭＴに対して、ＣＴおよびＤＴはいずれも定数であると仮定する。これは、ＷＦＱルータからエクスポートされる値と整合する。明らかに、ＲＳＶＰもまたこの仮定を暗黙のうちにしている。その理由は、受信側は、送信側から受信したのとは異なるＴＳＰＥＣを指定することがあるが、それでも依然として、帯域幅要求を計算するためにＰＡＴＨメッセージ内のＴＳＰＥＣに対応する同じＣおよびＤの値を使用するからである。この仮定が成り立たない場合、上記の補間法を使用することが可能であり、計算の複雑さ（計算量）はｆおよびｈの形に依存することになる。
【００３２】
上記の仮定の下で、
Ｒ１Ｔ＋Ｒ２Ｔ＝（ｂ１Ｔ＋ＣｔｏｔＴ）／（ｄ１Ｔ−ＤｔｏｔＴ）＋（ｂ２Ｔ＋ＣｔｏｔＴ）／（ｄ２Ｔ−ＤｔｏｔＴ）    （４）
であり、２つのトンネルを１つに合併した場合、要求される帯域幅は、
ＲｇＴ＝（ｂ１Ｔ＋ｂ２Ｔ＋ＣｔｏｔＴ）／（ｄ１Ｔ−ＤｔｏｔＴ）    （５）
である。
【００３３】
従って、
【数１】
0003545988.tif 000002
となる。
【００３４】
ｂ２Ｔが一定の場合、これはｄ２に関して単調増大関数であり、
ｄ２Ｔ＜ｄ１Ｔ＋（ｄ１Ｔ−ＤｔｏｔＴ）ＣｔｏｔＴ／ｂ２Ｔ    （７）
のとき、
ＲｇＴ＜Ｒ１Ｔ＋Ｒ２Ｔ    （８）
となる。
【００３５】
つまり、２つのトンネルを１つに合併することによって帯域幅が節約される。なお、ｄ２Ｔ＝ｄ１Ｔのとき、ＲｇＴ−（Ｒ１Ｔ＋Ｒ２Ｔ）＝−ＣｔｏｔＴ／（ｄ１Ｔ−ＤｔｏｔＴ）＜０である。すなわち、同じ遅延要求のセッションを１つのトンネルにまとめることによって、常に帯域幅が節約される。この特殊な場合は、Ｓ．  Ｒａｍｐａｌ  ａｎｄ  Ｒ．Ｇｕｅｒｉｎ，  ”Ｆｌｏｗ  Ｇｒｏｕｐｉｎｇ  ｆｏｒ  Ｒｅｄｕｃｉｎｇ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｆｏｒ  Ｇｕａｒａｎｔｅｅｄ  Ｄｅｌａｙ  Ｓｅｒｖｉｃｅ”，  ｄｒａｆｔ−ｒａｍｐａｌ−ｆｌｏｗ−ｄｅｌａｙ−ｓｅｒｖｉｃｅ−０１．ｔｘｔ，  Ｊｕｌｙ  １９９７、で観察されたものである。
【００３６】
式（６）でｄ２Ｔ→∞とすると、
ＲｇＴ−（Ｒ１Ｔ＋Ｒ２Ｔ）＝ｂ２Ｔ／（ｄ１Ｔ−ＤｔｏｔＴ）＞０    （９）
となる。
【００３７】
これはもう１つの極端な場合であり、ｄ２Ｔが十分に大きいとき、２つのトンネルを別々のままにしたほうが帯域効率が良いことを示している。
【００３８】
上記の考察からわかるように、使用される帯域を効率的にトンネルに分割する方法について決定するときに用いるのに、遅延は良好な指標となる可能性がある。これは実際その通りである。
【００３９】
パラメータセット（ｂｉ，Ｒｉ，ｄｉ）（ｉ＝１，．．．，ｎ）を有するｎ個のＲＳＶＰセッションがある場合を考え、これらのセッションがｄｉでソートされていると仮定する。トンネルが遅延ｄＴを保証するように設定された場合、ｄＴより小さい遅延要求のセッションはこのトンネルには入らない。他方、遅延要求ｄＴ′＜ｄＴのトンネルに、ｄＴより大きい遅延要求のセッションｉを入れるのは帯域効率が悪い。これは次のことから明らかである。すなわち、遅延保証ｄＴのトンネルにこのセッションを追加するのに要する追加帯域幅はΔＲ＝ｂｉ／（ｄＴ−ＤｔｏｔＴ）であり、帯域保証ｄＴ′のトンネルにこのセッションを追加するのに要する追加帯域幅はΔＲ′＝ｂｉ／（ｄＴ′−ＤｔｏｔＴ）＞ΔＲであるからである。
【００４０】
このことから次のことがわかる。与えられたセッションのセットに対して、さまざまな遅延保証ｄ１Ｔ＜ｄ２Ｔ＜．．．＜ｄｎＴを提供するようにトンネルが設定された場合、遅延要求ｄｊＴ≦ｄｉ＜ｄｊ＋１Ｔのセッションをトンネルｊに入れると帯域効率がよい。従って、与えられたＲＳＶＰセッション統計に基づいてトンネルがあらかじめ構成されている場合、ＲＳＶＰセッションは、まずｄｉでソートすべきである（詳細は後述）。
【００４１】
一般に、ＴＳＰは、トンネルがどのような種類のＴＳＰＥＣをサポートすることができるかを知らないため、できるだけ大きいＴＳＰＥＣとして知っていることを単に送信する。具体的には、ＴＳＰは、ｂＴがそのバッファサイズであり、ｐＴが入力リンク速度の和（または無限大）であり、ｒＴが出力リンク速度であり、ＭＴが出力インタフェースによってサポートされる最大パケットサイズであり、ｍＴがＴＳＰによってサポートされる最小の課金単位であるとして、送信する。
【００４２】
また、ＴＳＰは、設定するトンネルの適当な個数を知らないため、トンネル設定期間中に、ＴＳＰがサポート可能なトンネルの数と同数以上のＴＵＮＮＥＬ＿ＰＡＴＨメッセージを送信する。過剰のＴＵＮＮＥＬ＿ＰＡＴＨメッセージは、必要であればパラメータ補間をサポートするために使用可能であり、対応するＴＵＮＮＥＬ＿ＲＥＳＶメッセージがタイムアウト期間内に受信されないときにはルータから消去される。
【００４３】
トンネルの適当な個数とＴＵＮＮＥＬ＿ＴＳＰＥＣの値はＴＤＰによって計算される。その後、ＴＤＰは、ＴＵＮＮＥＬ＿ＦＬＯＷＳＰＥＣ内のＴＵＮＮＥＬ＿ＴＳＰＥＣとともにＴＵＮＮＥＬ＿ＲＥＳＶメッセージをＴＳＰへ送る。このＴＵＮＮＥＬ＿ＲＥＳＶメッセージは、ＦｉｌｔｅｒｓｐｅｃがＴＳＰのＩＰアドレスとＵＤＰデスティネーションポート番号を指定するＦＦ予約スタイルを使用すべきである。
【００４４】
受信側主導トンネル割当て／受付制御
ＲＳＶＰは受信側主導のプロトコルである。アプリケーションの遅延要求と、エンドツーエンドＲＳＶＰ  ＰＡＴＨメッセージ内のＴＳＰＥＣおよびＡＤＳＰＥＣで受信されるパラメータに基づいて、受信側は、所望の帯域幅Ｒ、スラック項Ｓ、および所望のＴＳＰＥＣを計算し、それらをＦＬＯＷＳＰＥＣでアップストリームへ送信する。
【００４５】
本発明によれば、ＴＤＰは、カプセル化されたＲＳＶＰ  ＰＡＴＨメッセージをＴＳＰから受信した後、それをカプセル化解除し、ＡＤＳＰＥＣを変更する。ＴＤＰは常に、トンネルについてＣ＝０およびＤ＝ｄ１Ｔ（最小遅延）であると（たとえそのトンネルにもう空き容量がなくても）公示する。ＴＤＰは、受信側から返されたＲＥＳＶメッセージを受信すると、スラック項の一部０≦Ｓ０≦Ｓをオプションとして使用して、このセッションを、ｄ１Ｔ＋Ｓ０より小さい遅延を保証するトンネルｉにマッピングする。その後、ＴＤＰは、ＳをｄｉＴ−ｄ１Ｔだけ小さくする。このセッションに関して、資格のあるいずれのトンネルにも十分な容量がない場合でも、遅延保証に違反することなくこのセッションを別のトンネルにマッピングすることは可能である。これについて以下で詳述する。
【００４６】
トンネルについてできるだけ小さい単一の遅延値ｄ１Ｔを公示することにより、プロトコルは単純かつスケーラブルになる。すなわち、ＴＤＰは、受信側のさまざまな相異なる遅延保証要求を知る必要がなく、単に、なし得る最善のことを公示する。なお、ＲＳＶＰプロトコルの受信側主導性により、ＴＤＰは、送信側からのＡＤＳＰＥＣを処理するときに、ＲＳＶＰセッションの遅延要求を知ることさえもない。
【００４７】
受信側が、より多くの遅延を許容することができる場合、第１の選択肢として、スラック項Ｓに過剰な値を入れることがある。この場合、ＴＤＰは、この過剰値を用いて、上記のように、より緩い遅延保証のトンネルにセッションをマッピングすることができる。受信側の第２の選択肢は、単に、より小さい帯域幅を予約することである。ほとんどの受信側が第２の選択肢を選ぶ場合、最小の遅延を提供するトンネルは、より大きい帯域幅のシェアを必要とする。この問題点についてはさらに後述する。
【００４８】
上記の説明からわかるように、トンネルはＲＳＶＰセッション要求の前に確立されるが、ＴＤＰは、受信側からのＲＥＳＶおよびＴＳＰＥＣメッセージを使用することによって、トンネルを最大限に利用（すなわち、セッションをトンネルにマッピングする）しようとする。
【００４９】
各ＲＳＶＰトンネルごとに、ＴＤＰは、パラメータのセット（ｂＴ，ＲＴ，ｄＴ，ｐＴ，ＭＴ）を管理する。ＴＤＰは、以下の条件がすべて成立する場合に、新しいＲＳＶＰセッションをトンネルに受け付ける（図５のステップ２２５および２３０）。
【数２】
0003545988.tif 000003
【００５０】
なお、ｐＴは、トンネルの入力リンク速度の総和と設定され、ＭＴは、トンネルのＭＴＵと設定されるため、式（１２）および（１３）で表される条件は常に真になるはずである。
【００５１】
トンネル構成
トンネルを確立する前に、ＴＳＰとＴＤＰの間でのＲＳＶＰセッションについての統計が存在すると仮定する。具体的には、各セッションｉ＝１，．．．，Ｎごとに、（ｂｉ，Ｒｉ，Ｓｉ）が記録される。ただし、ｂｉは最大バーストサイズであり、Ｒｉは予約される帯域幅であり、Ｓｉはスラック項である。このような統計が典型的なトラフィックパターンを表すと仮定した場合に、帯域を効率的に利用するようにトンネルを構成する方法を見つけることが望ましい。Ｓｉのうち、Ｓｉ０がトンネルによって使用されると仮定する。トラフィックプロファイルに基づくトンネル構成アルゴリズム（Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇ（ｂ，Ｒ，Ｓ０，Ｎ））は次の通りである。
【００５２】
１．ｄｉ＝（ｂｉ＋ＣｔｏｔＴ）／Ｒｉ＋ＤｔｏｔＴ  とおく。
２．ｄｉ＋Ｓｉ０（ｉ＝１，．．．，Ｎ）をキーとして用いて、ベクトル（Ｒｉ，ｂｉ，ｄｉ＋Ｓｉ０）をソートする。
３．ｎ＝１，．．．，Ｎのそれぞれについて、次式を計算する。
【数３】
0003545988.tif 000004
４．ｎ０＝ａｒｇｍｉｎ｛Ｒ１，ｎ０ｇ＋Ｒ２，ｎ０ｇ｝を求める。
５．ｎ０＝１の場合、ｄＴ＝ｄ１＋Ｓ１０、ｂＴ＝ΣｉＮｂｉ、およびＲＴ＝（ｂＴ＋ＣｔｏｔＴ）／（ｄＴ−ＤｔｏｔＴ）としてトンネルが構成され、Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇは終了する。
６．ｎ０＞１の場合、
Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇ（（ｂ１，．．．，ｂｎ０−１），（Ｒ１，．．．，Ｒｎ０−１），（Ｓ０１，．．．，Ｓ０ｎ０−１），ｎ０−１）、および、
Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇ（（ｂｎ０，．．．，ｂＮ），（Ｒｎ０，．．．，ＲＮ），（Ｓ０ｎ０，．．．，Ｓ０Ｎ），Ｎ−ｎ０−１）
を実行する。
【００５３】
トンネル構成プロセスは、ステップ１で、ｄｉを計算することから開始する。ｄｉは、トンネルがセッションｉのみに対して作成された場合にこのセッションが受ける遅延である。次に、ステップ２で、ｄｉ＋Ｓｉ０をキーとして用いて、ベクトル（Ｒｉ，ｂｉ，ｄｉ＋Ｓｉ０）をソートする。次に、ステップ３で、セッションを２つのグループに分割し、各グループについて帯域幅を計算する。全帯域幅の最も少ない分割を固定し、プロセスは、ステップ４、５、および６で、この分割のそれぞれの部分について再帰的に実行される。さらに分割をしても帯域幅要求がもはや減少しなくなったら、再帰的実行を終了する。
【００５４】
トンネルチューニング
ＲＳＶＰセッションのパス上のトンネルの存在は、送信側および受信側の双方にとってトランスペアレントである。前述のように、ＴＤＰは常に、提供可能な最もきつい遅延保証を公示する。その結果、受信側に見えるのは、パス上の最小のＤｔｏｔの値である。受信側のアプリケーションがより大きな遅延を許容することができる場合、予約メッセージにおいて、スラック項を入れるか、それとも、単により小さい帯域幅を要求するかを決定することは受信側に任される。
【００５５】
前述のように、ＴＤＰでスラック項Ｓ＞０が見える場合、ＴＤＰは、オプションとして、その一部を使用することができる。他方、Ｓ＝０である場合、ＴＤＰは、最もきつい遅延保証のトンネルにＲＳＶＰセッションを入れるしかない。その結果、このトンネルは、他のトンネルよりもずっと急速に満たされる可能性が高い。一般に、トンネルはあらかじめ分割されているため、トンネルが分割される際に基づくパラメータにトラフィックパターンが一致する可能性は少ない。そのような場合、トンネルパラメータを動的に調整してトラフィックパターンに合わせることができる。
【００５６】
前掲のＧｕｅｒｉｎ  ｅｔ  ａｌ．，  ”Ａｇｇｒｅｇａｔｉｎｇ  ＲＳＶＰ−ｂａｓｅｄ  ＱｏＳ  Ｒｅｑｕｅｓｔｓ”の論文に記載されているように、トンネルによって提供される遅延保証は、バーストサイズｂＴおよび帯域幅ＲＴの関数である。なお、セッションが遅延保証を必要とする場合、ｄよりも小さい遅延保証のすべてのトンネルが満たされているときにのみ、ｄｊＴ＞ｄのトンネルｊを使用することが必要となる。すなわち、ｄｊＴは、ｄｊ，ｎｅｗＴ＜ｄｊ，ｏｌｄＴとなるように調整されるべきである。これは、既存のトンネルの帯域幅を増大させなければならないか、または、ｄＴ＞ｄのトンネルで許容されるバーストサイズを減少させなければならないかのいずれかであることを意味する。いずれの場合でも、トンネルパラメータの変更を通知するためにＴＵＮＮＥＬ＿ＦＬＯＷＳＰＥＣがＴＤＰからＴＳＰへ送られる。
【００５７】
トンネル帯域幅ＲｊＴを増大させる要求は、利用可能な帯域幅に依存して受け入れられない可能性があるが、バーストサイズｂｊＴを減少させる要求はそのような可能性はない。従って、バーストサイズを減少させることが、トンネルを動的に調整する好ましい方法である。
【００５８】
トンネルが新しい遅延保証ｄｎｅｗＴを提供するためには、新しい許容バーストサイズは、
ｂｎｅｗＴ＝（ｄｎｅｗＴ−ＤｔｏｔＴ）×ＲＴ−ＣｔｏｔＴ    （１５）
である。
【００５９】
バーストサイズの減少を要求する決定をする前に、ＴＤＰはまず、新しいトンネルに対しても受付基準（前述）が成り立つことを確認しなければならない。
【００６０】
トンネル調整は、一時的に行うことも可能である。すなわち、小さい遅延要求のセッションが終了した後、トンネルは、ＴＤＰからＴＳＰへＴＵＮＮＥＬ＿ＦＬＯＷＳＰＥＣを送ることによって、下のパラメータに戻すことが可能である。
【００６１】
動的なトンネル調整は、トンネルパラメータを現在のトラフィックの需要に合わせるように変化させるのに有用であるが、同様の遅延保証を有する複数のトンネルが生じることもある。前述のように、このような場合、これらのトンネルをまとめるほうが帯域効率がよい可能性がある。一般に、トラフィックパターンは、はじめにトンネルを分割するために使用されたものと一致しないことがあるため、利用可能な帯域を効率的に使用するためには、トンネル分割は、時間が経つにつれて変更しなければならないことがある。そこで、トンネルチューニング手続きにより、受け付けられるエンドツーエンドＲＳＶＰセッションの一部のトンネル再割当てが起こることがある。
【００６２】
トラフィックプロファイルもまた、ベクトル（ｂｉ，Ｒｉ，Ｓｉ）のセットによって記述され、ＴＤＰによって記録される。しかし、前述の例とは異なり、遅延保証値は別の方法で計算される。
【００６３】
トンネルは各セッションｉごとに遅延値ｄＴを公示しているため、遅延ｄＴ＋Ｓｉ０を保証しなければならない。ただし、０≦Ｓｉ０≦Ｓｉは、トンネルが使用することに決めたスラック値である。トンネルチューニングアルゴリズムは、遅延を計算する方法を除いては、トンネル構成アルゴリズム（前述）と同様である。トンネルチューニングアルゴリズム（Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇ（ｂ，Ｒ，Ｓ０，Ｎ））は次の通りである。
１．ｄｉ＝ｄＴ  とおく。
２．ｄｉ＋Ｓｉ０（ｉ＝１，．．．，Ｎ）をキーとして用いて、ベクトル（Ｒｉ，ｂｉ，ｄｉ＋Ｓｉ０）をソートする。
３．ｎ＝１，．．．，Ｎのそれぞれについて、次式を計算する。
【数４】
0003545988.tif 000005
４．ｎ０＝ａｒｇｍｉｎ｛Ｒ１，ｎ０ｇ＋Ｒ２，ｎ０ｇ｝を求める。
５．ｎ０＝１の場合、ｄＴ＝ｄ１＋Ｓ１０、ｂＴ＝ΣｉＮｂｉ、およびＲＴ＝（ｂＴ＋ＣｔｏｔＴ）／（ｄＴ−ＤｔｏｔＴ）としてトンネルが構成され、Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇは終了する。
６．ｎ０＞１の場合、
Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇ（（ｂ１，．．．，ｂｎ０−１），（Ｒ１，．．．，Ｒｎ０−１），（Ｓ０１，．．．，Ｓ０ｎ０−１），ｎ０−１）、および、
Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇ（（ｂｎ０，．．．，ｂＮ），（Ｒｎ０，．．．，ＲＮ），（Ｓ０ｎ０，．．．，Ｓ０Ｎ），Ｎ−ｎ０−１）
を実行する。
【００６４】
プロトコルパフォーマンスに影響を及ぼすもう１つの重要なファクタは、公示されるトンネル遅延値（すべてのトンネルのうちで最小のもの）である。この値が大きすぎる場合、いくつかの受信側では遅延が許容できず、ＲＳＶＰセッションは失敗することになる。他方、この値が小さすぎて、しかも、受信側はスラック項を与えない場合（または、スラックが、ＴＤＰと受信側の間のルータで使い尽くされてしまった場合）、トンネル帯域幅に対する過大な要求になる可能性がある。
【００６５】
適当な公示遅延値を見つけるため、ＴＤＰは、小さい公示値から開始して、失敗するＲＳＶＰセッションが大幅に増大するまで、（この場合も、動的調整よりもずっと長い時間スケールで）次第に公示値を増大させる。
【００６６】
上記のことからわかるように、本発明による新規なＲＳＶＰベースのトンネルプロトコルは、以下の顕著な特徴を有する。
・ＴＤＰは、どのエンドツーエンドセッションがどのトンネルに割り当てられるかについて、トンネルのパラメータと、受信側からのエンドツーエンドＲＥＳＶメッセージとに基づいて、決定する。
・ＴＤＰは、ＴＳＰとＴＤＰの間のすべてのトンネルに対する単一の遅延値を公示する。これにより、プロトコルは単純かつスケーラブルになる。
・トラフィックプロファイルに基づいて、ＴＤＰは、帯域を効率的に使用するようにトンネルを分割する。
・ＴＤＰは、トラフィックダイナミクスに応じてトンネルを調整する。
・ＴＤＰは、プロトコルパフォーマンスを改善するために、長い時間スケールでトンネルを調整する。
・ＣおよびＤが、ＴＳＰＥＣ内のいくつかのパラメータの未知関数である場合、さまざまなパラメータ値の複数のＴＳＰＥＣメッセージを送信して、関数を補間により推定することができる。
【００６７】
最初の特徴により、プロトコルはＲＳＶＰの受信側主導性と整合性のあるものとなり、残りの特徴により、プロトコルは、単純で、スケーラブルで、フレキシブルになるとともに、トンネル帯域を効率的に利用することになる。
【００６８】
図１２に、簡単に、本発明の原理による代表的なＴＤＰの高水準ブロック図を示す。ＴＤＰは、蓄積プログラム制御方式のプロセッサアーキテクチャであり、プロセッサ６５０、メモリ６６０（プログラム命令およびデータ（例えば、上記の新規なＲＳＶＰベースのトンネルプロトコルにより通信するためのものなど）を格納する）、および、パス６６６で表されるような通信設備に接続するための通信インタフェース６６５を有する。
【００６９】
以上、本発明の実施例について説明したが、当業者であれば、上記の説明に基づいて、本発明の技術的範囲から離れることなく、さまざまな変形例を考えることが可能である。例えば、本発明の概念は、モバイルＩＰサービスの上でＱｏＳ保証を提供するために使用することも可能である。この場合、ホームエージェントから外部エージェントへのＩＰトンネルが設定され、このようなトンネルは、本発明の原理によるＲＳＶＰを使用して、まとめられたトラフィックのＱｏＳ要求を通知し、各フローごとのＱｏＳ要求が満たされるようにされる。
【００７０】
【発明の効果】
以上述べたごとく、本発明によれば、トンネルソースポイント（ＴＳＰ）とトンネルデスティネーションポイント（ＴＤＰ）の間のパケットトンネルを通じて、ＲＳＶＰの受信側主導パラダイムと整合性のある方法でエンドツーエンドＲＳＶＰセッションを確立する新規なＲＳＶＰベースのトンネルプロトコルが実現される。特に、エンドツーエンドＲＳＶＰセッションは、受信側指向ＲＳＶＰタイプのシグナリングを用いて、ＴＤＰがトンネルマッピングを決定するようにマッピングされる。このように、この新しいＲＳＶＰタイプのプロトコルは、ＲＳＶＰの受信側主導性と整合性があるため、既存のＲＳＶＰプロトコルを変更する必要がない。
【図面の簡単な説明】
【図１】従来技術のエンドツーエンドＲＳＶＰメッセージトランザクションの一部を示す図である。
【図２】従来技術のエンドツーエンドＲＳＶＰメッセージトランザクションの一部を示す図である。
【図３】本発明の原理によるネットワークを示す図である。
【図４】本発明の原理によるエンドツーエンドＲＳＶＰベースのメッセージトランザクションの一部を示す図である。
【図５】本発明の原理による例示的な流れ図である。
【図６】ＴＳＰＥＣを含むＲＳＶＰ  ＰＡＴＨメッセージフォーマットの図である。
【図７】保証付きサービスのＲＳＶＰ  ＡＤＳＰＥＣオブジェクトを示す図である。
【図８】保証付きサービスのＲＳＶＰ  ＡＤＳＰＥＣオブジェクトを示す図である。
【図９】ＳＥＳＳＩＯＮオブジェクトおよびＦＬＯＷＳＰＥＣオブジェクトを含むＲＳＶＰ  ＲＥＳＶメッセージフォーマットの図である。
【図１０】本発明の原理による例示的なＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトを示す図である。
【図１１】トンネルメッセージトランザクションの一部を示す図である。
【図１２】トンネルデスティネーションポイントの例示的な高水準ブロック図である。
【符号の説明】
１０  ネットワーク
１５  インターネットサービスプロバイダ（ＩＳＰ）
２５  ＩＳＰ
５０  インターネット
６０  ＲＳＶＰトンネル
６５０  プロセッサ
６６０  メモリ
６６５  通信インタフェース
６６６  パス
【図１】
0003545988.tif 000006
【図２】
0003545988.tif 000007
【図３】
0003545988.tif 000008
【図４】
0003545988.tif 000009
【図５】
0003545988.tif 000010
【図６】
0003545988.tif 000011
【図７】
0003545988.tif 000012
【図８】
0003545988.tif 000013
【図９】
0003545988.tif 000014
【図１０】
0003545988.tif 000015
【図１１】
0003545988.tif 000016
【図１２】
0003545988.tif 000017