JP3545988B2

JP3545988B2 - 通信方法および通信装置

Info

Publication number: JP3545988B2
Application number: JP2000051869A
Authority: JP
Inventors: チューチュアームーイ; サンパスコディーラムムーラリッドハーラン; ヤンアンルー
Original assignee: ルーセントテクノロジーズインコーポレーテッド
Priority date: 1999-02-26
Filing date: 2000-02-28
Publication date: 2004-07-21
Anticipated expiration: 2020-02-28
Also published as: ES2234524T3; KR20000076719A; US6519254B1; DE60017622T2; JP2000253071A; DE60017622D1; EP1035688B1; EP1035688A3; EP1035688A2

Description

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

となる。
【００３４】
ｂ_２ ^Ｔが一定の場合、これはｄ_２に関して単調増大関数であり、
ｄ_２ ^Ｔ＜ｄ_１ ^Ｔ＋（ｄ_１ ^Ｔ−Ｄ_ｔｏｔ ^Ｔ）Ｃ_ｔｏｔ ^Ｔ／ｂ_２ ^Ｔ（７）
のとき、
Ｒ_ｇ ^Ｔ＜Ｒ_１ ^Ｔ＋Ｒ_２ ^Ｔ（８）
となる。
【００３５】
つまり、２つのトンネルを１つに合併することによって帯域幅が節約される。なお、ｄ_２ ^Ｔ＝ｄ_１ ^Ｔのとき、Ｒ_ｇ ^Ｔ−（Ｒ_１ ^Ｔ＋Ｒ_２ ^Ｔ）＝−Ｃ_ｔｏｔ ^Ｔ／（ｄ_１ ^Ｔ−Ｄ_ｔｏｔ ^Ｔ）＜０である。すなわち、同じ遅延要求のセッションを１つのトンネルにまとめることによって、常に帯域幅が節約される。この特殊な場合は、Ｓ．ＲａｍｐａｌａｎｄＲ．Ｇｕｅｒｉｎ， ”ＦｌｏｗＧｒｏｕｐｉｎｇｆｏｒＲｅｄｕｃｉｎｇＲｅｓｅｒｖａｔｉｏｎＲｅｑｕｉｒｅｍｅｎｔｓｆｏｒＧｕａｒａｎｔｅｅｄＤｅｌａｙＳｅｒｖｉｃｅ”，ｄｒａｆｔ−ｒａｍｐａｌ−ｆｌｏｗ−ｄｅｌａｙ−ｓｅｒｖｉｃｅ−０１．ｔｘｔ，Ｊｕｌｙ１９９７、で観察されたものである。
【００３６】
式（６）でｄ_２ ^Ｔ→∞とすると、
Ｒ_ｇ ^Ｔ−（Ｒ_１ ^Ｔ＋Ｒ_２ ^Ｔ）＝ｂ_２ ^Ｔ／（ｄ_１ ^Ｔ−Ｄ_ｔｏｔ ^Ｔ）＞０（９）
となる。
【００３７】
これはもう１つの極端な場合であり、ｄ_２ ^Ｔが十分に大きいとき、２つのトンネルを別々のままにしたほうが帯域効率が良いことを示している。
【００３８】
上記の考察からわかるように、使用される帯域を効率的にトンネルに分割する方法について決定するときに用いるのに、遅延は良好な指標となる可能性がある。これは実際その通りである。
【００３９】
パラメータセット（ｂ_ｉ，Ｒ_ｉ，ｄ_ｉ）（ｉ＝１，．．．，ｎ）を有するｎ個のＲＳＶＰセッションがある場合を考え、これらのセッションがｄ_ｉでソートされていると仮定する。トンネルが遅延ｄ^Ｔを保証するように設定された場合、ｄ^Ｔより小さい遅延要求のセッションはこのトンネルには入らない。他方、遅延要求ｄ^Ｔ′＜ｄ^Ｔのトンネルに、ｄ^Ｔより大きい遅延要求のセッションｉを入れるのは帯域効率が悪い。これは次のことから明らかである。すなわち、遅延保証ｄ^Ｔのトンネルにこのセッションを追加するのに要する追加帯域幅はΔＲ＝ｂ_ｉ／（ｄ^Ｔ−Ｄ_ｔｏｔ ^Ｔ）であり、帯域保証ｄ^Ｔ′のトンネルにこのセッションを追加するのに要する追加帯域幅はΔＲ′＝ｂ_ｉ／（ｄ^Ｔ′−Ｄ_ｔｏｔ ^Ｔ）＞ΔＲであるからである。
【００４０】
このことから次のことがわかる。与えられたセッションのセットに対して、さまざまな遅延保証ｄ_１ ^Ｔ＜ｄ_２ ^Ｔ＜．．．＜ｄ_ｎ ^Ｔを提供するようにトンネルが設定された場合、遅延要求ｄ_ｊ ^Ｔ≦ｄ_ｉ＜ｄ_ｊ＋１ ^Ｔのセッションをトンネルｊに入れると帯域効率がよい。従って、与えられたＲＳＶＰセッション統計に基づいてトンネルがあらかじめ構成されている場合、ＲＳＶＰセッションは、まずｄ_ｉでソートすべきである（詳細は後述）。
【００４１】
一般に、ＴＳＰは、トンネルがどのような種類のＴＳＰＥＣをサポートすることができるかを知らないため、できるだけ大きいＴＳＰＥＣとして知っていることを単に送信する。具体的には、ＴＳＰは、ｂ^Ｔがそのバッファサイズであり、ｐ^Ｔが入力リンク速度の和（または無限大）であり、ｒ^Ｔが出力リンク速度であり、Ｍ^Ｔが出力インタフェースによってサポートされる最大パケットサイズであり、ｍ^ＴがＴＳＰによってサポートされる最小の課金単位であるとして、送信する。
【００４２】
また、ＴＳＰは、設定するトンネルの適当な個数を知らないため、トンネル設定期間中に、ＴＳＰがサポート可能なトンネルの数と同数以上のＴＵＮＮＥＬ＿ＰＡＴＨメッセージを送信する。過剰のＴＵＮＮＥＬ＿ＰＡＴＨメッセージは、必要であればパラメータ補間をサポートするために使用可能であり、対応するＴＵＮＮＥＬ＿ＲＥＳＶメッセージがタイムアウト期間内に受信されないときにはルータから消去される。
【００４３】
トンネルの適当な個数とＴＵＮＮＥＬ＿ＴＳＰＥＣの値はＴＤＰによって計算される。その後、ＴＤＰは、ＴＵＮＮＥＬ＿ＦＬＯＷＳＰＥＣ内のＴＵＮＮＥＬ＿ＴＳＰＥＣとともにＴＵＮＮＥＬ＿ＲＥＳＶメッセージをＴＳＰへ送る。このＴＵＮＮＥＬ＿ＲＥＳＶメッセージは、ＦｉｌｔｅｒｓｐｅｃがＴＳＰのＩＰアドレスとＵＤＰデスティネーションポート番号を指定するＦＦ予約スタイルを使用すべきである。
【００４４】
受信側主導トンネル割当て／受付制御
ＲＳＶＰは受信側主導のプロトコルである。アプリケーションの遅延要求と、エンドツーエンドＲＳＶＰＰＡＴＨメッセージ内のＴＳＰＥＣおよびＡＤＳＰＥＣで受信されるパラメータに基づいて、受信側は、所望の帯域幅Ｒ、スラック項Ｓ、および所望のＴＳＰＥＣを計算し、それらをＦＬＯＷＳＰＥＣでアップストリームへ送信する。
【００４５】
本発明によれば、ＴＤＰは、カプセル化されたＲＳＶＰＰＡＴＨメッセージをＴＳＰから受信した後、それをカプセル化解除し、ＡＤＳＰＥＣを変更する。ＴＤＰは常に、トンネルについてＣ＝０およびＤ＝ｄ_１ ^Ｔ（最小遅延）であると（たとえそのトンネルにもう空き容量がなくても）公示する。ＴＤＰは、受信側から返されたＲＥＳＶメッセージを受信すると、スラック項の一部０≦Ｓ_０≦Ｓをオプションとして使用して、このセッションを、ｄ_１ ^Ｔ＋Ｓ_０より小さい遅延を保証するトンネルｉにマッピングする。その後、ＴＤＰは、Ｓをｄ_ｉ ^Ｔ−ｄ_１ ^Ｔだけ小さくする。このセッションに関して、資格のあるいずれのトンネルにも十分な容量がない場合でも、遅延保証に違反することなくこのセッションを別のトンネルにマッピングすることは可能である。これについて以下で詳述する。
【００４６】
トンネルについてできるだけ小さい単一の遅延値ｄ_１ ^Ｔを公示することにより、プロトコルは単純かつスケーラブルになる。すなわち、ＴＤＰは、受信側のさまざまな相異なる遅延保証要求を知る必要がなく、単に、なし得る最善のことを公示する。なお、ＲＳＶＰプロトコルの受信側主導性により、ＴＤＰは、送信側からのＡＤＳＰＥＣを処理するときに、ＲＳＶＰセッションの遅延要求を知ることさえもない。
【００４７】
受信側が、より多くの遅延を許容することができる場合、第１の選択肢として、スラック項Ｓに過剰な値を入れることがある。この場合、ＴＤＰは、この過剰値を用いて、上記のように、より緩い遅延保証のトンネルにセッションをマッピングすることができる。受信側の第２の選択肢は、単に、より小さい帯域幅を予約することである。ほとんどの受信側が第２の選択肢を選ぶ場合、最小の遅延を提供するトンネルは、より大きい帯域幅のシェアを必要とする。この問題点についてはさらに後述する。
【００４８】
上記の説明からわかるように、トンネルはＲＳＶＰセッション要求の前に確立されるが、ＴＤＰは、受信側からのＲＥＳＶおよびＴＳＰＥＣメッセージを使用することによって、トンネルを最大限に利用（すなわち、セッションをトンネルにマッピングする）しようとする。
【００４９】
各ＲＳＶＰトンネルごとに、ＴＤＰは、パラメータのセット（ｂ^Ｔ，Ｒ^Ｔ，ｄ^Ｔ，ｐ^Ｔ，Ｍ^Ｔ）を管理する。ＴＤＰは、以下の条件がすべて成立する場合に、新しいＲＳＶＰセッションをトンネルに受け付ける（図５のステップ２２５および２３０）。
【数２】

【００５０】
なお、ｐ^Ｔは、トンネルの入力リンク速度の総和と設定され、Ｍ^Ｔは、トンネルのＭＴＵと設定されるため、式（１２）および（１３）で表される条件は常に真になるはずである。
【００５１】
トンネル構成
トンネルを確立する前に、ＴＳＰとＴＤＰの間でのＲＳＶＰセッションについての統計が存在すると仮定する。具体的には、各セッションｉ＝１，．．．，Ｎごとに、（ｂ_ｉ，Ｒ_ｉ，Ｓ_ｉ）が記録される。ただし、ｂ_ｉは最大バーストサイズであり、Ｒ_ｉは予約される帯域幅であり、Ｓ_ｉはスラック項である。このような統計が典型的なトラフィックパターンを表すと仮定した場合に、帯域を効率的に利用するようにトンネルを構成する方法を見つけることが望ましい。Ｓ_ｉのうち、Ｓ_ｉ ^０がトンネルによって使用されると仮定する。トラフィックプロファイルに基づくトンネル構成アルゴリズム（Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇ（ｂ，Ｒ，Ｓ^０，Ｎ））は次の通りである。
【００５２】
１．ｄ_ｉ＝（ｂ_ｉ＋Ｃ_ｔｏｔ ^Ｔ）／Ｒ_ｉ＋Ｄ_ｔｏｔ ^Ｔとおく。
２．ｄ_ｉ＋Ｓ_ｉ ^０（ｉ＝１，．．．，Ｎ）をキーとして用いて、ベクトル（Ｒ_ｉ，ｂ_ｉ，ｄ_ｉ＋Ｓ_ｉ ^０）をソートする。
３．ｎ＝１，．．．，Ｎのそれぞれについて、次式を計算する。
【数３】

４．ｎ_０＝ａｒｇｍｉｎ｛Ｒ_１，ｎ０ ^ｇ＋Ｒ_２，ｎ０ ^ｇ｝を求める。
５．ｎ_０＝１の場合、ｄ^Ｔ＝ｄ_１＋Ｓ_１ ^０、ｂ^Ｔ＝Σ_ｉ ^Ｎｂ_ｉ、およびＲ^Ｔ＝（ｂ^Ｔ＋Ｃ_ｔｏｔ ^Ｔ）／（ｄ^Ｔ−Ｄ_ｔｏｔ ^Ｔ）としてトンネルが構成され、Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇは終了する。
６．ｎ_０＞１の場合、
Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇ（（ｂ_１，．．．，ｂ_ｎ０−１），（Ｒ_１，．．．，Ｒ_ｎ０−１），（Ｓ^０ _１，．．．，Ｓ^０ _ｎ０−１），ｎ_０−１）、および、
Ｔｕｎｎｅｌ＿Ｃｏｎｆｉｇ（（ｂ_ｎ０，．．．，ｂ_Ｎ），（Ｒ_ｎ０，．．．，Ｒ_Ｎ），（Ｓ^０ _ｎ０，．．．，Ｓ^０ _Ｎ），Ｎ−ｎ_０−１）
を実行する。
【００５３】
トンネル構成プロセスは、ステップ１で、ｄ_ｉを計算することから開始する。ｄ_ｉは、トンネルがセッションｉのみに対して作成された場合にこのセッションが受ける遅延である。次に、ステップ２で、ｄ_ｉ＋Ｓ_ｉ ^０をキーとして用いて、ベクトル（Ｒ_ｉ，ｂ_ｉ，ｄ_ｉ＋Ｓ_ｉ ^０）をソートする。次に、ステップ３で、セッションを２つのグループに分割し、各グループについて帯域幅を計算する。全帯域幅の最も少ない分割を固定し、プロセスは、ステップ４、５、および６で、この分割のそれぞれの部分について再帰的に実行される。さらに分割をしても帯域幅要求がもはや減少しなくなったら、再帰的実行を終了する。
【００５４】
トンネルチューニング
ＲＳＶＰセッションのパス上のトンネルの存在は、送信側および受信側の双方にとってトランスペアレントである。前述のように、ＴＤＰは常に、提供可能な最もきつい遅延保証を公示する。その結果、受信側に見えるのは、パス上の最小のＤ_ｔｏｔの値である。受信側のアプリケーションがより大きな遅延を許容することができる場合、予約メッセージにおいて、スラック項を入れるか、それとも、単により小さい帯域幅を要求するかを決定することは受信側に任される。
【００５５】
前述のように、ＴＤＰでスラック項Ｓ＞０が見える場合、ＴＤＰは、オプションとして、その一部を使用することができる。他方、Ｓ＝０である場合、ＴＤＰは、最もきつい遅延保証のトンネルにＲＳＶＰセッションを入れるしかない。その結果、このトンネルは、他のトンネルよりもずっと急速に満たされる可能性が高い。一般に、トンネルはあらかじめ分割されているため、トンネルが分割される際に基づくパラメータにトラフィックパターンが一致する可能性は少ない。そのような場合、トンネルパラメータを動的に調整してトラフィックパターンに合わせることができる。
【００５６】
前掲のＧｕｅｒｉｎｅｔａｌ．， ”ＡｇｇｒｅｇａｔｉｎｇＲＳＶＰ−ｂａｓｅｄＱｏＳＲｅｑｕｅｓｔｓ”の論文に記載されているように、トンネルによって提供される遅延保証は、バーストサイズｂ^Ｔおよび帯域幅Ｒ^Ｔの関数である。なお、セッションが遅延保証を必要とする場合、ｄよりも小さい遅延保証のすべてのトンネルが満たされているときにのみ、ｄ_ｊ ^Ｔ＞ｄのトンネルｊを使用することが必要となる。すなわち、ｄ_ｊ ^Ｔは、ｄ_{ｊ，ｎｅｗ} ^Ｔ＜ｄ_{ｊ，ｏｌｄ} ^Ｔとなるように調整されるべきである。これは、既存のトンネルの帯域幅を増大させなければならないか、または、ｄ^Ｔ＞ｄのトンネルで許容されるバーストサイズを減少させなければならないかのいずれかであることを意味する。いずれの場合でも、トンネルパラメータの変更を通知するためにＴＵＮＮＥＬ＿ＦＬＯＷＳＰＥＣがＴＤＰからＴＳＰへ送られる。
【００５７】
トンネル帯域幅Ｒ_ｊ ^Ｔを増大させる要求は、利用可能な帯域幅に依存して受け入れられない可能性があるが、バーストサイズｂ_ｊ ^Ｔを減少させる要求はそのような可能性はない。従って、バーストサイズを減少させることが、トンネルを動的に調整する好ましい方法である。
【００５８】
トンネルが新しい遅延保証ｄ_ｎｅｗ ^Ｔを提供するためには、新しい許容バーストサイズは、
ｂ_ｎｅｗ ^Ｔ＝（ｄ_ｎｅｗ ^Ｔ−Ｄ_ｔｏｔ ^Ｔ）×Ｒ^Ｔ−Ｃ_ｔｏｔ ^Ｔ（１５）
である。
【００５９】
バーストサイズの減少を要求する決定をする前に、ＴＤＰはまず、新しいトンネルに対しても受付基準（前述）が成り立つことを確認しなければならない。
【００６０】
トンネル調整は、一時的に行うことも可能である。すなわち、小さい遅延要求のセッションが終了した後、トンネルは、ＴＤＰからＴＳＰへＴＵＮＮＥＬ＿ＦＬＯＷＳＰＥＣを送ることによって、下のパラメータに戻すことが可能である。
【００６１】
動的なトンネル調整は、トンネルパラメータを現在のトラフィックの需要に合わせるように変化させるのに有用であるが、同様の遅延保証を有する複数のトンネルが生じることもある。前述のように、このような場合、これらのトンネルをまとめるほうが帯域効率がよい可能性がある。一般に、トラフィックパターンは、はじめにトンネルを分割するために使用されたものと一致しないことがあるため、利用可能な帯域を効率的に使用するためには、トンネル分割は、時間が経つにつれて変更しなければならないことがある。そこで、トンネルチューニング手続きにより、受け付けられるエンドツーエンドＲＳＶＰセッションの一部のトンネル再割当てが起こることがある。
【００６２】
トラフィックプロファイルもまた、ベクトル（ｂ_ｉ，Ｒ_ｉ，Ｓ_ｉ）のセットによって記述され、ＴＤＰによって記録される。しかし、前述の例とは異なり、遅延保証値は別の方法で計算される。
【００６３】
トンネルは各セッションｉごとに遅延値ｄ^Ｔを公示しているため、遅延ｄ^Ｔ＋Ｓ_ｉ ^０を保証しなければならない。ただし、０≦Ｓ_ｉ ^０≦Ｓ_ｉは、トンネルが使用することに決めたスラック値である。トンネルチューニングアルゴリズムは、遅延を計算する方法を除いては、トンネル構成アルゴリズム（前述）と同様である。トンネルチューニングアルゴリズム（Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇ（ｂ，Ｒ，Ｓ^０，Ｎ））は次の通りである。
１．ｄ_ｉ＝ｄ^Ｔとおく。
２．ｄ_ｉ＋Ｓ_ｉ ^０（ｉ＝１，．．．，Ｎ）をキーとして用いて、ベクトル（Ｒ_ｉ，ｂ_ｉ，ｄ_ｉ＋Ｓ_ｉ ^０）をソートする。
３．ｎ＝１，．．．，Ｎのそれぞれについて、次式を計算する。
【数４】

４．ｎ_０＝ａｒｇｍｉｎ｛Ｒ_１，ｎ０ ^ｇ＋Ｒ_２，ｎ０ ^ｇ｝を求める。
５．ｎ_０＝１の場合、ｄ^Ｔ＝ｄ_１＋Ｓ_１ ^０、ｂ^Ｔ＝Σ_ｉ ^Ｎｂ_ｉ、およびＲ^Ｔ＝（ｂ^Ｔ＋Ｃ_ｔｏｔ ^Ｔ）／（ｄ^Ｔ−Ｄ_ｔｏｔ ^Ｔ）としてトンネルが構成され、Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇは終了する。
６．ｎ_０＞１の場合、
Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇ（（ｂ_１，．．．，ｂ_ｎ０−１），（Ｒ_１，．．．，Ｒ_ｎ０−１），（Ｓ^０ _１，．．．，Ｓ^０ _ｎ０−１），ｎ_０−１）、および、
Ｔｕｎｎｅｌ＿Ｔｕｎｉｎｇ（（ｂ_ｎ０，．．．，ｂ_Ｎ），（Ｒ_ｎ０，．．．，Ｒ_Ｎ），（Ｓ^０ _ｎ０，．．．，Ｓ^０ _Ｎ），Ｎ−ｎ_０−１）
を実行する。
【００６４】
プロトコルパフォーマンスに影響を及ぼすもう１つの重要なファクタは、公示されるトンネル遅延値（すべてのトンネルのうちで最小のもの）である。この値が大きすぎる場合、いくつかの受信側では遅延が許容できず、ＲＳＶＰセッションは失敗することになる。他方、この値が小さすぎて、しかも、受信側はスラック項を与えない場合（または、スラックが、ＴＤＰと受信側の間のルータで使い尽くされてしまった場合）、トンネル帯域幅に対する過大な要求になる可能性がある。
【００６５】
適当な公示遅延値を見つけるため、ＴＤＰは、小さい公示値から開始して、失敗するＲＳＶＰセッションが大幅に増大するまで、（この場合も、動的調整よりもずっと長い時間スケールで）次第に公示値を増大させる。
【００６６】
上記のことからわかるように、本発明による新規なＲＳＶＰベースのトンネルプロトコルは、以下の顕著な特徴を有する。
・ＴＤＰは、どのエンドツーエンドセッションがどのトンネルに割り当てられるかについて、トンネルのパラメータと、受信側からのエンドツーエンドＲＥＳＶメッセージとに基づいて、決定する。
・ＴＤＰは、ＴＳＰとＴＤＰの間のすべてのトンネルに対する単一の遅延値を公示する。これにより、プロトコルは単純かつスケーラブルになる。
・トラフィックプロファイルに基づいて、ＴＤＰは、帯域を効率的に使用するようにトンネルを分割する。
・ＴＤＰは、トラフィックダイナミクスに応じてトンネルを調整する。
・ＴＤＰは、プロトコルパフォーマンスを改善するために、長い時間スケールでトンネルを調整する。
・ＣおよびＤが、ＴＳＰＥＣ内のいくつかのパラメータの未知関数である場合、さまざまなパラメータ値の複数のＴＳＰＥＣメッセージを送信して、関数を補間により推定することができる。
【００６７】
最初の特徴により、プロトコルはＲＳＶＰの受信側主導性と整合性のあるものとなり、残りの特徴により、プロトコルは、単純で、スケーラブルで、フレキシブルになるとともに、トンネル帯域を効率的に利用することになる。
【００６８】
図１２に、簡単に、本発明の原理による代表的なＴＤＰの高水準ブロック図を示す。ＴＤＰは、蓄積プログラム制御方式のプロセッサアーキテクチャであり、プロセッサ６５０、メモリ６６０（プログラム命令およびデータ（例えば、上記の新規なＲＳＶＰベースのトンネルプロトコルにより通信するためのものなど）を格納する）、および、パス６６６で表されるような通信設備に接続するための通信インタフェース６６５を有する。
【００６９】
以上、本発明の実施例について説明したが、当業者であれば、上記の説明に基づいて、本発明の技術的範囲から離れることなく、さまざまな変形例を考えることが可能である。例えば、本発明の概念は、モバイルＩＰサービスの上でＱｏＳ保証を提供するために使用することも可能である。この場合、ホームエージェントから外部エージェントへのＩＰトンネルが設定され、このようなトンネルは、本発明の原理によるＲＳＶＰを使用して、まとめられたトラフィックのＱｏＳ要求を通知し、各フローごとのＱｏＳ要求が満たされるようにされる。
【００７０】
【発明の効果】
以上述べたごとく、本発明によれば、トンネルソースポイント（ＴＳＰ）とトンネルデスティネーションポイント（ＴＤＰ）の間のパケットトンネルを通じて、ＲＳＶＰの受信側主導パラダイムと整合性のある方法でエンドツーエンドＲＳＶＰセッションを確立する新規なＲＳＶＰベースのトンネルプロトコルが実現される。特に、エンドツーエンドＲＳＶＰセッションは、受信側指向ＲＳＶＰタイプのシグナリングを用いて、ＴＤＰがトンネルマッピングを決定するようにマッピングされる。このように、この新しいＲＳＶＰタイプのプロトコルは、ＲＳＶＰの受信側主導性と整合性があるため、既存のＲＳＶＰプロトコルを変更する必要がない。
【図面の簡単な説明】
【図１】従来技術のエンドツーエンドＲＳＶＰメッセージトランザクションの一部を示す図である。
【図２】従来技術のエンドツーエンドＲＳＶＰメッセージトランザクションの一部を示す図である。
【図３】本発明の原理によるネットワークを示す図である。
【図４】本発明の原理によるエンドツーエンドＲＳＶＰベースのメッセージトランザクションの一部を示す図である。
【図５】本発明の原理による例示的な流れ図である。
【図６】ＴＳＰＥＣを含むＲＳＶＰＰＡＴＨメッセージフォーマットの図である。
【図７】保証付きサービスのＲＳＶＰＡＤＳＰＥＣオブジェクトを示す図である。
【図８】保証付きサービスのＲＳＶＰＡＤＳＰＥＣオブジェクトを示す図である。
【図９】ＳＥＳＳＩＯＮオブジェクトおよびＦＬＯＷＳＰＥＣオブジェクトを含むＲＳＶＰＲＥＳＶメッセージフォーマットの図である。
【図１０】本発明の原理による例示的なＴＵＮＮＥＬ＿ＢＩＮＤＩＮＧオブジェクトを示す図である。
【図１１】トンネルメッセージトランザクションの一部を示す図である。
【図１２】トンネルデスティネーションポイントの例示的な高水準ブロック図である。
【符号の説明】
１０ネットワーク
１５インターネットサービスプロバイダ（ＩＳＰ）
２５ＩＳＰ
５０インターネット
６０ＲＳＶＰトンネル
６５０プロセッサ
６６０メモリ
６６５通信インタフェース
６６６パス

Claims

トンネルデスティネーションポイントとして作用するパケットサーバにおいて使用される通信方法において、
１つまたは複数のエンドツーエンドＲＳＶＰＲＥＳＶメッセージを受信するステップと、
前記１つまたは複数のエンドツーエンドＲＳＶＰＲＥＳＶメッセージで運ばれた情報を用いて、エンドツーエンドＲＳＶＰセッションをトンネルにマッピングするステップとを有する通信方法。
カプセル化された１つまたは複数のエンドツーエンドＲＳＶＰＲＥＳＶメッセージをトンネルソースポイントへ送るステップをさらに有し、
前記カプセル化された１つまたは複数のエンドツーエンドＲＳＶＰＲＥＳＶメッセージは、前記トンネルおよび前記マッピングされるエンドツーエンドＲＳＶＰセッションについてのマッピング情報を含む請求項１に記載の方法。
前記マッピング情報は、前記カプセル化された１つまたは複数のエンドツーエンドＲＳＶＰＲＥＳＶメッセージに添付されたTUNNEL_BINDINGオブジェクトにより送信される請求項２に記載の方法。
前記マッピングするステップは、前記受信した１つまたは複数のエンドツーエンドＲＳＶＰＲＥＳＶメッセージから抽出されるスラック時間値と、最小トンネル遅延値との関数として、前記エンドツーエンドＲＳＶＰセッションを前記トンネルに割り当てる請求項１に記載の方法。
前記受信するステップの前に、受信側へ送信されるＡＤＳＰＥＣオブジェクトで単一の遅延値を公示するステップをさらに有する請求項１に記載の方法。
バーストサイズのような少なくとも１つのトンネルパラメータを調整することによって、確立されたトンネルをチューニングするステップをさらに有する請求項１に記載の方法。
確立されたトンネルを再構成し、必要であれば、エンドツーエンドＲＳＶＰセッションを再割当てすることによって、前記確立されたトンネルをチューニングするステップをさらに有する請求項１に記載の方法。
トンネルデスティネーションポイントとして作用する通信装置において、
（ａ）１つまたは複数のＲＳＶＰＲＥＳＶメッセージを受信し、かつ、（ｂ）前記１つまたは複数のＲＳＶＰＲＥＳＶメッセージで運ばれた情報を用いて、エンドツーエンドＲＳＶＰセッションをトンネルにマッピングするパケットサーバを有する通信装置。
前記パケットサーバは、カプセル化された１つまたは複数のＲＳＶＰＲＥＳＶメッセージをトンネルソースポイントへ送り、
前記カプセル化された１つまたは複数のＲＳＶＰＲＥＳＶメッセージは、前記トンネルおよび前記マッピングされるエンドツーエンドＲＳＶＰセッションについてのマッピング情報を含む請求項８に記載の装置。
前記マッピング情報は、前記カプセル化された１つまたは複数のＲＳＶＰＲＥＳＶメッセージに添付されたTUNNEL_BINDINGオブジェクトにより送信される請求項９に記載の装置。
前記パケットサーバは、前記受信した１つまたは複数のＲＳＶＰＲＥＳＶメッセージから抽出されるスラック時間値と、最小トンネル遅延値との関数として、前記エンドツーエンドＲＳＶＰセッションを前記トンネルにマッピングする請求項８に記載の装置。
前記パケットサーバは、前記１つまたは複数のＲＳＶＰＲＥＳＶメッセージを受信する前に、受信側へ送信されるＡＤＳＰＥＣオブジェクトで単一の遅延値を公示する請求項８に記載の装置。
前記パケットサーバは、バーストサイズのような少なくとも１つのトンネルパラメータを調整することによって、確立されたトンネルをチューニングする請求項８に記載の装置。
前記パケットサーバは、確立されたトンネルを再構成し、必要であれば、エンドツーエンドＲＳＶＰセッションを再割当てすることによって、前記確立されたトンネルをチューニングする請求項８に記載の装置。