JP2000253071A - 通信方法および通信装置 - Google Patents
通信方法および通信装置Info
- Publication number
- JP2000253071A JP2000253071A JP2000051869A JP2000051869A JP2000253071A JP 2000253071 A JP2000253071 A JP 2000253071A JP 2000051869 A JP2000051869 A JP 2000051869A JP 2000051869 A JP2000051869 A JP 2000051869A JP 2000253071 A JP2000253071 A JP 2000253071A
- Authority
- JP
- Japan
- Prior art keywords
- tunnel
- rsvp
- session
- tdp
- mapping
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/825—Involving tunnels, e.g. MPLS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
Abstract
(57)【要約】
【課題】 トンネルソースポイント（ＴＳＰ）とトンネ
ルデスティネーションポイント（ＴＤＰ）の間のパケッ
トトンネルを通じて、ＲＳＶＰの受信側主導パラダイム
と整合性のある方法でエンドツーエンドＲＳＶＰセッシ
ョンを確立する新規なＲＳＶＰベースのトンネルプロト
コルを実現する。 【解決手段】 ＲＳＶＰプロトコルは、エンドツーエン
ドＲＳＶＰセッションから、ＴＳＰとＴＤＰの間のトン
ネルへの受信側指向マッピングをサポートするように変
更される。特に、ＴＤＰは、エンドツーエンドＲＳＶＰ
ＲＥＳＶメッセージで運ばれる情報を使用して、セッ
ションからトンネルへのマッピングを決定する。このマ
ッピングは、新しいTUNNEL_BINDINGオブジェクトを通じ
てＴＳＰへ送信される。また、保証付きサービスを提供
する際に、ＴＤＰは動的にＴＳＰへのトンネルを構成
し、確立されたトンネルに対するトンネル調整を実行す
る。
ルデスティネーションポイント（ＴＤＰ）の間のパケッ
トトンネルを通じて、ＲＳＶＰの受信側主導パラダイム
と整合性のある方法でエンドツーエンドＲＳＶＰセッシ
ョンを確立する新規なＲＳＶＰベースのトンネルプロト
コルを実現する。 【解決手段】 ＲＳＶＰプロトコルは、エンドツーエン
ドＲＳＶＰセッションから、ＴＳＰとＴＤＰの間のトン
ネルへの受信側指向マッピングをサポートするように変
更される。特に、ＴＤＰは、エンドツーエンドＲＳＶＰ
ＲＥＳＶメッセージで運ばれる情報を使用して、セッ
ションからトンネルへのマッピングを決定する。このマ
ッピングは、新しいTUNNEL_BINDINGオブジェクトを通じ
てＴＳＰへ送信される。また、保証付きサービスを提供
する際に、ＴＤＰは動的にＴＳＰへのトンネルを構成
し、確立されたトンネルに対するトンネル調整を実行す
る。
Description
【０００１】
【発明の属する技術分野】本発明は、通信に関し、特
に、パケット通信システムに関する。
に、パケット通信システムに関する。
【０００２】
【従来の技術】以前は、インターネットを用いたすべて
のデータトラフィックは平等に扱われ、「ベスト・エフ
ォート」メカニズムを用いてトランスポートされた。し
かし、時が経つにつれて、インターネットを通じてのリ
アルタイムアプリケーション（例えば、オーディオ／ビ
デオ会議ツール、ゲームアプリケーションなど）をサポ
ートすることへの需要から、何らかの形の差別化された
サービス(differentiated service)提供の必要性が生じ
た。そこで、当業者は、サービス品質（ＱｏＳ）をイン
ターネットユーザに提供する新たなプロトコルを提案し
ている。
のデータトラフィックは平等に扱われ、「ベスト・エフ
ォート」メカニズムを用いてトランスポートされた。し
かし、時が経つにつれて、インターネットを通じてのリ
アルタイムアプリケーション（例えば、オーディオ／ビ
デオ会議ツール、ゲームアプリケーションなど）をサポ
ートすることへの需要から、何らかの形の差別化された
サービス(differentiated service)提供の必要性が生じ
た。そこで、当業者は、サービス品質（ＱｏＳ）をイン
ターネットユーザに提供する新たなプロトコルを提案し
ている。
【０００３】ＲＳＶＰ(Resource ReSerVation Protoco
l)はそのようなプロトコルの１つである。ＲＳＶＰは、
受信側ホストがデータフローパスを通じてネットワーク
エレメントへ所望のサービスを通知するために使用され
る受信側主導のエンドツーエンドプロトコルである。Ｒ
ＳＶＰでは、ＱｏＳ要求の粒度（グラニュラリティ：gr
anularity）は、パケットフローごとに決定される（例
えば、B. Braden, L. Zhang, S. Berson, S. Herzog,
S. Jamin, "Resource ReSerVation Protocol (RSVP) -
Version I Functional Specification", RFC 2205、を
参照）。
l)はそのようなプロトコルの１つである。ＲＳＶＰは、
受信側ホストがデータフローパスを通じてネットワーク
エレメントへ所望のサービスを通知するために使用され
る受信側主導のエンドツーエンドプロトコルである。Ｒ
ＳＶＰでは、ＱｏＳ要求の粒度（グラニュラリティ：gr
anularity）は、パケットフローごとに決定される（例
えば、B. Braden, L. Zhang, S. Berson, S. Herzog,
S. Jamin, "Resource ReSerVation Protocol (RSVP) -
Version I Functional Specification", RFC 2205、を
参照）。
【０００４】しかし、パケットフローごとにＱｏＳ保証
を提供することは、バックボーンルータにスケーラビリ
ティの問題点を生じる（例えば、R. Guerin, S. Blake,
S.Herzog, "Aggregating RSVP-based QoS Requests",
draft-guerin-aggreg-rsvp-00.txt, Nov. 1997、を参
照）。例えば、ルータにおいて各パケットフロー（本明
細書では、「ＴＣＰ／ＩＰセッション」ともいう）ごと
に、例えばＴＣＰ／ＩＰソース、ＴＣＰ／ＩＰデスティ
ネーション、およびＴＣＰ／ＩＰプロトコル番号を含む
予約状態がある。このため、ルータが各ＴＣＰ／ＩＰセ
ッションを追跡することが必要であることにより、多く
のルータメモリと処理リソースを消費する。さらに、Ｒ
ＳＶＰのエンドツーエンド性により、ネットワークを通
じて仮想パイプを予約するために使用することは不適当
になる。
を提供することは、バックボーンルータにスケーラビリ
ティの問題点を生じる（例えば、R. Guerin, S. Blake,
S.Herzog, "Aggregating RSVP-based QoS Requests",
draft-guerin-aggreg-rsvp-00.txt, Nov. 1997、を参
照）。例えば、ルータにおいて各パケットフロー（本明
細書では、「ＴＣＰ／ＩＰセッション」ともいう）ごと
に、例えばＴＣＰ／ＩＰソース、ＴＣＰ／ＩＰデスティ
ネーション、およびＴＣＰ／ＩＰプロトコル番号を含む
予約状態がある。このため、ルータが各ＴＣＰ／ＩＰセ
ッションを追跡することが必要であることにより、多く
のルータメモリと処理リソースを消費する。さらに、Ｒ
ＳＶＰのエンドツーエンド性により、ネットワークを通
じて仮想パイプを予約するために使用することは不適当
になる。
【０００５】上記の問題点に対する１つの解決法は、パ
ケットフローをまとめて２つのルータの間にＲＳＶＰト
ンネルを設けることである。この解決法については、 ・R. Guerin, S. Blake, S. Herzog, "Aggregating RSV
P-based QoS Requests", draft-guerin-aggreg-rsvp-0
0.txt, Nov. 1997 ・A. Terzis, J. Krawczyk, J. Wroclaski, L. Zhang,
"RSVP Operation overIP tunnels", draft-ietf-rsvp-
tunnel-03.txt, Aug. 1998 に記載されている。ここで、一対のトンネルエンドポイ
ントを通るＲＳＶＰセッションは、相異なるサービス
（例えば、保証付きサービス（guaranteed service：最
悪の遅延を保証する）や負荷制御サービス（controlled
load service：最低帯域幅を保証する））を提供する
ことが可能であり、同じサービスが相異なるパラメータ
（例えば、保証付きサービスにおける相異なる遅延要
求）を有し、あるいは、類似のサービスが相異なるポリ
シを有する。こうして、一対のトンネルエンドポイント
の間に複数の異なるトンネルが存在することが可能とな
る。
ケットフローをまとめて２つのルータの間にＲＳＶＰト
ンネルを設けることである。この解決法については、 ・R. Guerin, S. Blake, S. Herzog, "Aggregating RSV
P-based QoS Requests", draft-guerin-aggreg-rsvp-0
0.txt, Nov. 1997 ・A. Terzis, J. Krawczyk, J. Wroclaski, L. Zhang,
"RSVP Operation overIP tunnels", draft-ietf-rsvp-
tunnel-03.txt, Aug. 1998 に記載されている。ここで、一対のトンネルエンドポイ
ントを通るＲＳＶＰセッションは、相異なるサービス
（例えば、保証付きサービス（guaranteed service：最
悪の遅延を保証する）や負荷制御サービス（controlled
load service：最低帯域幅を保証する））を提供する
ことが可能であり、同じサービスが相異なるパラメータ
（例えば、保証付きサービスにおける相異なる遅延要
求）を有し、あるいは、類似のサービスが相異なるポリ
シを有する。こうして、一対のトンネルエンドポイント
の間に複数の異なるトンネルが存在することが可能とな
る。
【０００６】
【発明が解決しようとする課題】上記のような、ＲＳＶ
ＰベースのＱｏＳ要求をまとめる修正された形式のＲＳ
ＶＰはこの問題点に対する１つの解決法ではあるが、こ
のような修正された形式のＲＳＶＰはもはや純粋に受信
側指向ではない。特に、エンドツーエンドＲＳＶＰ Ｒ
ＥＳＶメッセージ（受信側から送信側へ）で運ばれる情
報は、トンネルソースポイントがセッションからトンネ
ルへのマッピングについて決定する際には使用されな
い。これは、ＲＳＶＰの受信側指向パラダイムに違反す
るのみならず、帯域幅の利用が非効率になる可能性があ
る。
ＰベースのＱｏＳ要求をまとめる修正された形式のＲＳ
ＶＰはこの問題点に対する１つの解決法ではあるが、こ
のような修正された形式のＲＳＶＰはもはや純粋に受信
側指向ではない。特に、エンドツーエンドＲＳＶＰ Ｒ
ＥＳＶメッセージ（受信側から送信側へ）で運ばれる情
報は、トンネルソースポイントがセッションからトンネ
ルへのマッピングについて決定する際には使用されな
い。これは、ＲＳＶＰの受信側指向パラダイムに違反す
るのみならず、帯域幅の利用が非効率になる可能性があ
る。
【０００７】
【課題を解決するための手段】そこで、本発明におい
て、トンネルソースポイント（ＴＳＰ：tunnel sourcep
oint）とトンネルデスティネーションポイント（ＴＤ
Ｐ：tunnel destinationpoint）の間のパケットトンネ
ルを通じて、ＲＳＶＰの受信側主導パラダイムと整合性
のある方法でエンドツーエンドＲＳＶＰセッションを確
立する新規なＲＳＶＰベースのトンネルプロトコルを開
発した。特に、エンドツーエンドＲＳＶＰセッション
は、受信側指向ＲＳＶＰタイプのシグナリングを用い
て、ＴＤＰがトンネルマッピングを決定するようにマッ
ピングされる。このように、この新しいＲＳＶＰタイプ
のプロトコルは、ＲＳＶＰの受信側主導性と整合性があ
るため、既存のＲＳＶＰプロトコルを変更する必要がな
い。
て、トンネルソースポイント（ＴＳＰ：tunnel sourcep
oint）とトンネルデスティネーションポイント（ＴＤ
Ｐ：tunnel destinationpoint）の間のパケットトンネ
ルを通じて、ＲＳＶＰの受信側主導パラダイムと整合性
のある方法でエンドツーエンドＲＳＶＰセッションを確
立する新規なＲＳＶＰベースのトンネルプロトコルを開
発した。特に、エンドツーエンドＲＳＶＰセッション
は、受信側指向ＲＳＶＰタイプのシグナリングを用い
て、ＴＤＰがトンネルマッピングを決定するようにマッ
ピングされる。このように、この新しいＲＳＶＰタイプ
のプロトコルは、ＲＳＶＰの受信側主導性と整合性があ
るため、既存のＲＳＶＰプロトコルを変更する必要がな
い。
【０００８】本発明の実施例では、ＲＳＶＰプロトコル
は、エンドツーエンドＲＳＶＰセッションから、ＴＳＰ
とＴＤＰの間のトンネルへの受信側指向マッピングをサ
ポートするように変更される。特に、ＴＤＰは、エンド
ツーエンドＲＳＶＰ ＲＥＳＶメッセージで運ばれる情
報を使用して、セッションからトンネルへのマッピング
を決定する。このマッピングは、新しいTUNNEL_BINDING
オブジェクトを通じてＴＳＰへ送信される。
は、エンドツーエンドＲＳＶＰセッションから、ＴＳＰ
とＴＤＰの間のトンネルへの受信側指向マッピングをサ
ポートするように変更される。特に、ＴＤＰは、エンド
ツーエンドＲＳＶＰ ＲＥＳＶメッセージで運ばれる情
報を使用して、セッションからトンネルへのマッピング
を決定する。このマッピングは、新しいTUNNEL_BINDING
オブジェクトを通じてＴＳＰへ送信される。
【０００９】本発明の別の特徴によれば、保証付きサー
ビスを提供する際に、ＴＤＰは動的にＴＳＰへのトンネ
ルを構成し、確立されたトンネルに対するトンネル調整
（チューニング）を実行する。後者の特徴により、帯域
効率を改善するために、トラフィック条件に既存のトン
ネルを動的に適応させることが可能となる。トンネルチ
ューニング手続きは、受け付けられたエンドツーエンド
ＲＳＶＰセッションの一部のトンネル再割当てを引き起
こすこともある。
ビスを提供する際に、ＴＤＰは動的にＴＳＰへのトンネ
ルを構成し、確立されたトンネルに対するトンネル調整
（チューニング）を実行する。後者の特徴により、帯域
効率を改善するために、トラフィック条件に既存のトン
ネルを動的に適応させることが可能となる。トンネルチ
ューニング手続きは、受け付けられたエンドツーエンド
ＲＳＶＰセッションの一部のトンネル再割当てを引き起
こすこともある。
【００１０】
【発明の実施の形態】以下の説明は大きくいくつかの部
分に分かれる。最初の部分では、高水準の背景知識につ
いて簡単に説明した後、新しいＲＳＶＰベースのトンネ
ルプロトコルの概観を行う。概観のセクションに続い
て、トンネル管理、受信側主導トンネル割当て／受付制
御、トンネル設定、およびトンネルチューニングについ
てさらに詳細なセクションがある。
分に分かれる。最初の部分では、高水準の背景知識につ
いて簡単に説明した後、新しいＲＳＶＰベースのトンネ
ルプロトコルの概観を行う。概観のセクションに続い
て、トンネル管理、受信側主導トンネル割当て／受付制
御、トンネル設定、およびトンネルチューニングについ
てさらに詳細なセクションがある。
【００１１】概観 背景知識として、保証付きサービスのＲＳＶＰセッショ
ンに加入するための、例示的なエンドツーエンドＲＳＶ
Ｐメッセージトランザクションの一部を図１に示す。送
信側は、ＲＳＶＰ ＰＡＴＨメッセージを（ユニキャス
ト、またはマルチキャストのＩＰアドレスによって識別
される）受信側へ送る。ＲＳＶＰ ＰＡＴＨメッセージ
には、SENDER TSPECオブジェクトおよびADSPECオブジェ
クトが添付される。SENDER TSPECオブジェクトは、送信
側が送信することが可能なフロー特性を指定し、ADSPEC
オブジェクトは、受信側へのパスにあるルータによる変
更を受けるパラメータを含む。受信側は、予約を行うと
き、その遅延要求と、ADSPECオブジェクトに含まれるパ
ラメータ（これは、前述のように、上記のルータ（図示
せず）によって変更されている可能性がある）とに従っ
て、必要とする帯域幅を計算する。その後、受信側は、
ＲＳＶＰ ＰＡＴＨメッセージがたどったパスに沿って
帯域を予約するために、ＲＳＶＰ ＲＥＳＶメッセージ
をアップストリームへ送信する。これらの動作の詳細
は、 ・S. Shenker, C. Partridge and R. Guerin, "Specifi
cation of GuaranteedQuality of Service", RFC 2212 ・J. Wroclawski, "The Use of RSVP with IETF Integr
ated Services", RFC2210 に記載されている。
ンに加入するための、例示的なエンドツーエンドＲＳＶ
Ｐメッセージトランザクションの一部を図１に示す。送
信側は、ＲＳＶＰ ＰＡＴＨメッセージを（ユニキャス
ト、またはマルチキャストのＩＰアドレスによって識別
される）受信側へ送る。ＲＳＶＰ ＰＡＴＨメッセージ
には、SENDER TSPECオブジェクトおよびADSPECオブジェ
クトが添付される。SENDER TSPECオブジェクトは、送信
側が送信することが可能なフロー特性を指定し、ADSPEC
オブジェクトは、受信側へのパスにあるルータによる変
更を受けるパラメータを含む。受信側は、予約を行うと
き、その遅延要求と、ADSPECオブジェクトに含まれるパ
ラメータ（これは、前述のように、上記のルータ（図示
せず）によって変更されている可能性がある）とに従っ
て、必要とする帯域幅を計算する。その後、受信側は、
ＲＳＶＰ ＰＡＴＨメッセージがたどったパスに沿って
帯域を予約するために、ＲＳＶＰ ＲＥＳＶメッセージ
をアップストリームへ送信する。これらの動作の詳細
は、 ・S. Shenker, C. Partridge and R. Guerin, "Specifi
cation of GuaranteedQuality of Service", RFC 2212 ・J. Wroclawski, "The Use of RSVP with IETF Integr
ated Services", RFC2210 に記載されている。
【００１２】上記のように、ＲＳＶＰトンネルを通じて
エンドツーエンドＲＳＶＰセッションを運ぶことが可能
である。ＲＳＶＰトンネルは、ＴＳＰを送信側としＴＤ
Ｐを受信側とするＲＳＶＰセッションにほかならない。
エンドツーエンドＲＳＶＰセッションがＴＳＰとＴＤＰ
の間に形成されるとき、ＴＳＰは、このエンドツーエン
ドセッションを、これらの間のｍ個のＲＳＶＰトンネル
のうちの１つにマッピングする。このｍ個のトンネルの
セットは、例えば、当業者に周知のポリシング（監視）
サーバあるいはＡＡＡ（Authentication Authorization
and Accounting：認証許可課金）サーバを使用するこ
とによって、ＴＳＰとＴＤＰの間にあらかじめ確立され
る。その結果、ＴＳＰとＴＤＰの間のフローごとに１つ
のＲＳＶＰセッションを使う代わりに、複数のフローが
単一のＲＳＶＰトンネルにまとめられるため、中間ルー
タで保持される状態数を大幅に削減することが可能とな
る。エンドツーエンドフローのデータがＴＳＰに到着す
ると、このデータは、同じトンネルに属するさまざまな
フローを中間ルータが差別しないように、カプセル化さ
れる。相異なるＲＳＶＰトンネルを区別するため、ＩＰ
−ｉｎ−ＵＤＰ（User Datagram Protocol)カプセル化
が用いられる。このカプセル化については、前掲のTerz
is et al., "RSVP Operations over IP tunnels"の論文
に記載されている。このカプセル化方式（この論文には
タイプ２トンネル(Type 2 tunnel)として記載されてい
る）では、ＵＤＰデスティネーションポート番号がトン
ネル識別子として用いられる。１つのトンネルにまとめ
られた後、ここのフローは、同じトンネル内の他のフロ
ーと帯域を共有しなければならない。従って、前掲のGu
erin et al., "Aggregating RSVP-based QoS Requests"
の論文に記載されているように、トンネルは、エンドツ
ーエンドフローのADSPECを更新するときには、純粋な遅
延ネットワークエレメントとして扱わなければならな
い。トンネルを通じてエンドツーエンドＲＳＶＰセッシ
ョンを確立するための従来のメッセージトランザクショ
ンの一部を図２に示す。前述のように、上記の修正され
た形式のＲＳＶＰ（図２に示したもの）は、ＲＳＶＰの
受信側主導パラダイムと整合しない。ＴＳＰが、受信側
に関する情報なしで、トンネルマッピングと、エンドツ
ーエンドＲＳＶＰセッションについてのマッピング情報
を決定するからである。
エンドツーエンドＲＳＶＰセッションを運ぶことが可能
である。ＲＳＶＰトンネルは、ＴＳＰを送信側としＴＤ
Ｐを受信側とするＲＳＶＰセッションにほかならない。
エンドツーエンドＲＳＶＰセッションがＴＳＰとＴＤＰ
の間に形成されるとき、ＴＳＰは、このエンドツーエン
ドセッションを、これらの間のｍ個のＲＳＶＰトンネル
のうちの１つにマッピングする。このｍ個のトンネルの
セットは、例えば、当業者に周知のポリシング（監視）
サーバあるいはＡＡＡ（Authentication Authorization
and Accounting：認証許可課金）サーバを使用するこ
とによって、ＴＳＰとＴＤＰの間にあらかじめ確立され
る。その結果、ＴＳＰとＴＤＰの間のフローごとに１つ
のＲＳＶＰセッションを使う代わりに、複数のフローが
単一のＲＳＶＰトンネルにまとめられるため、中間ルー
タで保持される状態数を大幅に削減することが可能とな
る。エンドツーエンドフローのデータがＴＳＰに到着す
ると、このデータは、同じトンネルに属するさまざまな
フローを中間ルータが差別しないように、カプセル化さ
れる。相異なるＲＳＶＰトンネルを区別するため、ＩＰ
−ｉｎ−ＵＤＰ（User Datagram Protocol)カプセル化
が用いられる。このカプセル化については、前掲のTerz
is et al., "RSVP Operations over IP tunnels"の論文
に記載されている。このカプセル化方式（この論文には
タイプ２トンネル(Type 2 tunnel)として記載されてい
る）では、ＵＤＰデスティネーションポート番号がトン
ネル識別子として用いられる。１つのトンネルにまとめ
られた後、ここのフローは、同じトンネル内の他のフロ
ーと帯域を共有しなければならない。従って、前掲のGu
erin et al., "Aggregating RSVP-based QoS Requests"
の論文に記載されているように、トンネルは、エンドツ
ーエンドフローのADSPECを更新するときには、純粋な遅
延ネットワークエレメントとして扱わなければならな
い。トンネルを通じてエンドツーエンドＲＳＶＰセッシ
ョンを確立するための従来のメッセージトランザクショ
ンの一部を図２に示す。前述のように、上記の修正され
た形式のＲＳＶＰ（図２に示したもの）は、ＲＳＶＰの
受信側主導パラダイムと整合しない。ＴＳＰが、受信側
に関する情報なしで、トンネルマッピングと、エンドツ
ーエンドＲＳＶＰセッションについてのマッピング情報
を決定するからである。
【００１３】そこで、本発明において、ＴＳＰとＴＤＰ
の間のパケットトンネルを通じて、ＲＳＶＰの受信側主
導パラダイムと整合性のある方法でエンドツーエンドＲ
ＳＶＰセッションを確立する新規なＲＳＶＰベースのト
ンネルプロトコルを開発した。特に、エンドツーエンド
ＲＳＶＰセッションは、ＴＤＰがエンドツーエンドＲＳ
ＶＰメッセージ内の情報を用いてトンネルマッピングを
決定するように、受信側指向ＲＳＶＰタイプのシグナリ
ングを用いてマッピングされる。
の間のパケットトンネルを通じて、ＲＳＶＰの受信側主
導パラダイムと整合性のある方法でエンドツーエンドＲ
ＳＶＰセッションを確立する新規なＲＳＶＰベースのト
ンネルプロトコルを開発した。特に、エンドツーエンド
ＲＳＶＰセッションは、ＴＤＰがエンドツーエンドＲＳ
ＶＰメッセージ内の情報を用いてトンネルマッピングを
決定するように、受信側指向ＲＳＶＰタイプのシグナリ
ングを用いてマッピングされる。
【００１４】本発明の原理による例示的なネットワーク
１０を図３に示す。図３において、本発明の概念に関す
るもの以外の要素は周知であり、詳細には説明しない。
例えば、インターネットサービスプロバイダ（ＩＳＰ）
１５は、単一ブロックのエレメントとして示されている
が、蓄積プログラム制御プロセッサ、メモリ、およびル
ータ／サーバ（例えば、ＰＯＰ（point-of-presence、
アクセスポイント）ルータ、ネットワークアクセスサー
バ（ＮＡＳ：Network Access Server）など）を含む
（図示せず）。ネットワーク１０は、インターネット５
０を通じて接続された、ＩＳＰ１５およびＩＳＰ２５で
表されるような複数のＩＳＰを含む。インターネット５
０は、インターネットプロトコル（ＩＰ）に基づくネッ
トワークインフラストラクチャを表し、パケットエンド
ポイントどうしの間でＩＰパケットを通信するためのル
ータなどのような他のコンポーネント（図示せず）を含
む。同様に、ネットワーク１０のエレメントどうしの間
の実線は、それぞれのエンドポイントどうしの間の周知
の通信設備を表す。例えば、ＩＳＰ１５とインターネッ
ト５０の間のコネクション（ライン２２で示す）は、Ｓ
ＯＮＥＴ（光同期網：synchronous optical network）
上の非同期転送モード（ＡＴＭ）によってサポートされ
る、などである。同様に、ライン１１および２１は、そ
れぞれＩＳＰ１５およびＩＳＰ２５を通じて、ネットワ
ーク１０に出入りする任意の個数および種類の通信設備
（例えば、複数のＴ１／Ｅ１回線（それぞれの方向に対
して）を表す。（このトラフィックの送信側および受信
側は簡単のため図示しない。）さらに、上記のＲＳＶＰ
プロトコルについては周知であると仮定する。ＲＳＶＰ
は、統合サービス（例えば、保証付きサービスまたは負
荷制御サービス）をサポートするが、ここでの説明は例
として保証付きサービスを使用する。また、ここでの説
明の目的では、ＩＳＰ１５およびＩＳＰ２５の動作は相
補的であって、ＩＳＰ１５はＴＳＰであり、ＩＳＰ２５
はＴＤＰであると仮定する。このように、本明細書で
は、ＴＳＰとＴＤＰは固定され、互いを知っている（例
えば、相手のアドレスを知っている）と仮定する。さら
に、ＴＳＰは、どのトラフィックフローを、ＴＤＰを通
じてルーティングしなければならないかを知っていると
する。この場合、以下でさらに説明するように、ＲＳＶ
Ｐトンネル６０（破線）は、ＩＳＰ１５をＩＳＰ２５に
接続するように設定され、ＲＳＶＰトンネル６０を通じ
てルーティングされる必要のあるトラフィックは、対応
するトラフィックのデスティネーションサブネットアド
レスによって識別される。
１０を図３に示す。図３において、本発明の概念に関す
るもの以外の要素は周知であり、詳細には説明しない。
例えば、インターネットサービスプロバイダ（ＩＳＰ）
１５は、単一ブロックのエレメントとして示されている
が、蓄積プログラム制御プロセッサ、メモリ、およびル
ータ／サーバ（例えば、ＰＯＰ（point-of-presence、
アクセスポイント）ルータ、ネットワークアクセスサー
バ（ＮＡＳ：Network Access Server）など）を含む
（図示せず）。ネットワーク１０は、インターネット５
０を通じて接続された、ＩＳＰ１５およびＩＳＰ２５で
表されるような複数のＩＳＰを含む。インターネット５
０は、インターネットプロトコル（ＩＰ）に基づくネッ
トワークインフラストラクチャを表し、パケットエンド
ポイントどうしの間でＩＰパケットを通信するためのル
ータなどのような他のコンポーネント（図示せず）を含
む。同様に、ネットワーク１０のエレメントどうしの間
の実線は、それぞれのエンドポイントどうしの間の周知
の通信設備を表す。例えば、ＩＳＰ１５とインターネッ
ト５０の間のコネクション（ライン２２で示す）は、Ｓ
ＯＮＥＴ（光同期網：synchronous optical network）
上の非同期転送モード（ＡＴＭ）によってサポートされ
る、などである。同様に、ライン１１および２１は、そ
れぞれＩＳＰ１５およびＩＳＰ２５を通じて、ネットワ
ーク１０に出入りする任意の個数および種類の通信設備
（例えば、複数のＴ１／Ｅ１回線（それぞれの方向に対
して）を表す。（このトラフィックの送信側および受信
側は簡単のため図示しない。）さらに、上記のＲＳＶＰ
プロトコルについては周知であると仮定する。ＲＳＶＰ
は、統合サービス（例えば、保証付きサービスまたは負
荷制御サービス）をサポートするが、ここでの説明は例
として保証付きサービスを使用する。また、ここでの説
明の目的では、ＩＳＰ１５およびＩＳＰ２５の動作は相
補的であって、ＩＳＰ１５はＴＳＰであり、ＩＳＰ２５
はＴＤＰであると仮定する。このように、本明細書で
は、ＴＳＰとＴＤＰは固定され、互いを知っている（例
えば、相手のアドレスを知っている）と仮定する。さら
に、ＴＳＰは、どのトラフィックフローを、ＴＤＰを通
じてルーティングしなければならないかを知っていると
する。この場合、以下でさらに説明するように、ＲＳＶ
Ｐトンネル６０（破線）は、ＩＳＰ１５をＩＳＰ２５に
接続するように設定され、ＲＳＶＰトンネル６０を通じ
てルーティングされる必要のあるトラフィックは、対応
するトラフィックのデスティネーションサブネットアド
レスによって識別される。
【００１５】本明細書の残りの部分では、トンネルに関
するＲＳＶＰメッセージをエンドツーエンドフローのも
のから区別するために、トンネルに関するＲＳＶＰメッ
セージに"TUNNEL_"というプレフィクスを付加する。さ
らに、エンドツーエンドフローのデータがＴＳＰに到着
した場合、前掲のTerzis et al., "RSVP Operationsove
r IP tunnels"の論文に記載されているように、タイプ
２トンネルがカプセル化のために使用されると仮定す
る。同様に、各トンネルは、前掲のGuerin et al., "Ag
gregating RSVP-based QoS Requests"の論文に記載され
ているように、純粋な遅延ネットワークエレメントとし
て扱われる。
するＲＳＶＰメッセージをエンドツーエンドフローのも
のから区別するために、トンネルに関するＲＳＶＰメッ
セージに"TUNNEL_"というプレフィクスを付加する。さ
らに、エンドツーエンドフローのデータがＴＳＰに到着
した場合、前掲のTerzis et al., "RSVP Operationsove
r IP tunnels"の論文に記載されているように、タイプ
２トンネルがカプセル化のために使用されると仮定す
る。同様に、各トンネルは、前掲のGuerin et al., "Ag
gregating RSVP-based QoS Requests"の論文に記載され
ているように、純粋な遅延ネットワークエレメントとし
て扱われる。
【００１６】まず、ｍ個のトンネル６０のセットが、Ｔ
ＳＰとＴＤＰの間に存在すると仮定する。本発明によ
る、例示的なＲＳＶＰエンドツーエンドメッセージトラ
ンザクションの一部を図４に示す。また、図５には、Ｔ
ＤＰにおいて使用される、本発明の原理による例示的な
流れ図を示す。ＴＤＰは、通常のプログラミング技術を
用いて下記の方法を実行するように適切にプログラムさ
れると仮定し、そのようなプログラミング技術について
はここでは説明しない。ＲＳＶＰは受信側主導のプロト
コルであるため、新しいエンドツーエンドＲＳＶＰ Ｐ
ＡＴＨメッセージがＴＳＰに到着すると、ＴＳＰは単に
そのエンドツーエンドＲＳＶＰ ＰＡＴＨメッセージを
カプセル化してＴＤＰへ送る。（これは、トンネルは事
前に静的に構成されていないことを仮定している。）Ｔ
ＤＰは、カプセル化されたエンドツーエンドＲＳＶＰ
ＰＡＴＨメッセージを受信すると（図５のステップ２０
５）、そのカプセル化を解除し、ADSPECを更新し（図５
のステップ２１０）、ＲＳＶＰエンドツーエンドシグナ
リングに従って、対応する受信側（図示せず）へ転送す
る（図５のステップ２１５）。受信側（図示せず）はＲ
ＳＶＰ ＰＡＴＨメッセージを受信した後、このＲＳＶ
Ｐセッションに必要なパラメータを（従来技術と同様
に）計算し、エンドツーエンドＲＳＶＰ ＲＥＳＶメッ
セージを返送する。ＴＤＰは、このＲＳＶＰ ＲＥＳＶ
メッセージを受信すると（図５のステップ２２０）、本
発明に従って、受信側主導のトンネル割当て／受付制御
手続きを実行することによってこのエンドツーエンドＲ
ＳＶＰセッションのための適当なＲＳＶＰトンネルを決
定し（図５のステップ２２５、詳細は後述）、受け付け
られた場合（図５のステップ２３０）、セッションから
トンネルへのバインディングをＴＳＰに通知するために
TUNNEL_BINDINGオブジェクトを形成する。（受け付けら
れない場合、図５のステップ２３５でセッションは拒否
される。）次に、ＴＤＰは、エンドツーエンドＲＳＶＰ
ＲＥＳＶメッセージを（添付されたTUNNEL_BINDINGオ
ブジェクトとともに）カプセル化してＴＳＰへ送り（図
５のステップ２４０）、ＴＳＰはそれをカプセル化解除
する。TUNNEL_BINDINGオブジェクトを受信した場合、Ｔ
ＳＰは、エンドツーエンドＲＳＶＰセッションのため
に、ＴＤＰによって割り当てられたトンネルを使用す
る。ＴＳＰは、ＲＳＶＰ ＲＥＳＶメッセージの残りの
部分をアップストリームの送信側（図示せず）へ転送す
る。その結果、この修正されたシグナリングにより、Ｔ
ＤＰは、トンネルのパラメータおよびエンドツーエンド
ＲＥＳＶメッセージに基づいてエンドツーエンドＲＳＶ
Ｐセッションにトンネルを割り当てることが可能とな
る。
ＳＰとＴＤＰの間に存在すると仮定する。本発明によ
る、例示的なＲＳＶＰエンドツーエンドメッセージトラ
ンザクションの一部を図４に示す。また、図５には、Ｔ
ＤＰにおいて使用される、本発明の原理による例示的な
流れ図を示す。ＴＤＰは、通常のプログラミング技術を
用いて下記の方法を実行するように適切にプログラムさ
れると仮定し、そのようなプログラミング技術について
はここでは説明しない。ＲＳＶＰは受信側主導のプロト
コルであるため、新しいエンドツーエンドＲＳＶＰ Ｐ
ＡＴＨメッセージがＴＳＰに到着すると、ＴＳＰは単に
そのエンドツーエンドＲＳＶＰ ＰＡＴＨメッセージを
カプセル化してＴＤＰへ送る。（これは、トンネルは事
前に静的に構成されていないことを仮定している。）Ｔ
ＤＰは、カプセル化されたエンドツーエンドＲＳＶＰ
ＰＡＴＨメッセージを受信すると（図５のステップ２０
５）、そのカプセル化を解除し、ADSPECを更新し（図５
のステップ２１０）、ＲＳＶＰエンドツーエンドシグナ
リングに従って、対応する受信側（図示せず）へ転送す
る（図５のステップ２１５）。受信側（図示せず）はＲ
ＳＶＰ ＰＡＴＨメッセージを受信した後、このＲＳＶ
Ｐセッションに必要なパラメータを（従来技術と同様
に）計算し、エンドツーエンドＲＳＶＰ ＲＥＳＶメッ
セージを返送する。ＴＤＰは、このＲＳＶＰ ＲＥＳＶ
メッセージを受信すると（図５のステップ２２０）、本
発明に従って、受信側主導のトンネル割当て／受付制御
手続きを実行することによってこのエンドツーエンドＲ
ＳＶＰセッションのための適当なＲＳＶＰトンネルを決
定し（図５のステップ２２５、詳細は後述）、受け付け
られた場合（図５のステップ２３０）、セッションから
トンネルへのバインディングをＴＳＰに通知するために
TUNNEL_BINDINGオブジェクトを形成する。（受け付けら
れない場合、図５のステップ２３５でセッションは拒否
される。）次に、ＴＤＰは、エンドツーエンドＲＳＶＰ
ＲＥＳＶメッセージを（添付されたTUNNEL_BINDINGオ
ブジェクトとともに）カプセル化してＴＳＰへ送り（図
５のステップ２４０）、ＴＳＰはそれをカプセル化解除
する。TUNNEL_BINDINGオブジェクトを受信した場合、Ｔ
ＳＰは、エンドツーエンドＲＳＶＰセッションのため
に、ＴＤＰによって割り当てられたトンネルを使用す
る。ＴＳＰは、ＲＳＶＰ ＲＥＳＶメッセージの残りの
部分をアップストリームの送信側（図示せず）へ転送す
る。その結果、この修正されたシグナリングにより、Ｔ
ＤＰは、トンネルのパラメータおよびエンドツーエンド
ＲＥＳＶメッセージに基づいてエンドツーエンドＲＳＶ
Ｐセッションにトンネルを割り当てることが可能とな
る。
【００１７】上記のメッセージに関して、ＲＳＶＰ Ｐ
ＡＴＨメッセージフォーマットを図６に示す。ＲＳＶＰ
ADSPECオブジェクトを図７および図８に示す。図９
に、ＲＳＶＰ ＲＥＳＶメッセージを、SESSIONオブジ
ェクトおよびFLOWSPECオブジェクトとともに示す。（な
お、本発明の概念以外については、これらのフォーマッ
トはＲＳＶＰで定義されている通りである。）本発明に
よる、TUNNEL_BINDINGオブジェクトの例示的なフォーマ
ットを図１０に示す。（認識されるように、TUNNEL_BIN
DINGオブジェクトフォーマットは、前掲のTerzis et a
l., "RSVP Operations over IP tunnels"の論文に記載
されているSESSIONオブジェクトに類似している。）
ＡＴＨメッセージフォーマットを図６に示す。ＲＳＶＰ
ADSPECオブジェクトを図７および図８に示す。図９
に、ＲＳＶＰ ＲＥＳＶメッセージを、SESSIONオブジ
ェクトおよびFLOWSPECオブジェクトとともに示す。（な
お、本発明の概念以外については、これらのフォーマッ
トはＲＳＶＰで定義されている通りである。）本発明に
よる、TUNNEL_BINDINGオブジェクトの例示的なフォーマ
ットを図１０に示す。（認識されるように、TUNNEL_BIN
DINGオブジェクトフォーマットは、前掲のTerzis et a
l., "RSVP Operations over IP tunnels"の論文に記載
されているSESSIONオブジェクトに類似している。）
【００１８】その後、ＴＳＰは、データトラフィックを
受信すると、セッション−トンネルバインディングに基
づいて、適当なＩＰ−ｉｎ−ＵＤＰヘッダとともにパケ
ットをカプセル化する。また、ＴＳＰは、個々のＴＳＰ
ＥＣに従わない各フローからのデータトラフィックをマ
ークしなければならない。このことは、ＴＳＰが、当業
者に周知のように各フローに対するポリシング（監視）
機能を備える必要があることを意味する。
受信すると、セッション−トンネルバインディングに基
づいて、適当なＩＰ−ｉｎ−ＵＤＰヘッダとともにパケ
ットをカプセル化する。また、ＴＳＰは、個々のＴＳＰ
ＥＣに従わない各フローからのデータトラフィックをマ
ークしなければならない。このことは、ＴＳＰが、当業
者に周知のように各フローに対するポリシング（監視）
機能を備える必要があることを意味する。
【００１９】なお、トンネルは、はじめに仮定したよう
に事前に構成されている必要はない。特に、ＴＤＰは、
ＴＳＰへのトンネルを動的に構成することが可能である
（詳細は後述）。このタイプのメッセージトランザクシ
ョンを図１１に示す。（なお、ＴＤＰにおいてトンネル
を動的に構成する機能以外の点では、このタイプのメッ
セージフロートランザクションは従来技術と同一であ
る。すなわち、あらかじめ構成されたトンネルの場合で
も、このタイプのメッセージフローは生じる。）図１１
に関して、ＲＳＶＰトンネルを確立するため、ＴＳＰは
送信側（すなわちデータソース）として作用し、ＴＤＰ
のユニキャストアドレスへTUNNEL_PATHメッセージを送
る。このTUNNEL_PATHメッセージには、TUNNEL_ADSPECオ
ブジェクトが添付される。本発明の特徴によれば（後
述）、ＴＤＰは、受信したTUNNEL_ADSPECオブジェクト
に含まれるパラメータに基づいて、確立するトンネルの
個数と、それらのトンネルの間でどのようにリソースを
割り当てるかを決定する。その後、ＴＤＰは、トンネル
を確立するために、ＴＳＰへTUNNEL_RESVメッセージを
送る。
に事前に構成されている必要はない。特に、ＴＤＰは、
ＴＳＰへのトンネルを動的に構成することが可能である
（詳細は後述）。このタイプのメッセージトランザクシ
ョンを図１１に示す。（なお、ＴＤＰにおいてトンネル
を動的に構成する機能以外の点では、このタイプのメッ
セージフロートランザクションは従来技術と同一であ
る。すなわち、あらかじめ構成されたトンネルの場合で
も、このタイプのメッセージフローは生じる。）図１１
に関して、ＲＳＶＰトンネルを確立するため、ＴＳＰは
送信側（すなわちデータソース）として作用し、ＴＤＰ
のユニキャストアドレスへTUNNEL_PATHメッセージを送
る。このTUNNEL_PATHメッセージには、TUNNEL_ADSPECオ
ブジェクトが添付される。本発明の特徴によれば（後
述）、ＴＤＰは、受信したTUNNEL_ADSPECオブジェクト
に含まれるパラメータに基づいて、確立するトンネルの
個数と、それらのトンネルの間でどのようにリソースを
割り当てるかを決定する。その後、ＴＤＰは、トンネル
を確立するために、ＴＳＰへTUNNEL_RESVメッセージを
送る。
【００２０】上記の各トンネル設定は、S. Shenker and
J. Wroclawski, "General Characterization Paramete
rs for Integrated Service Network Elements", RFC 2
215、の論文で定義されている制御負荷サービスあるい
は保証付きサービスのいずれも提供することが可能であ
る。以下のセクションでは、保証付きサービスを提供す
るトンネルを管理するための追加のアルゴリズムについ
て説明する。
J. Wroclawski, "General Characterization Paramete
rs for Integrated Service Network Elements", RFC 2
215、の論文で定義されている制御負荷サービスあるい
は保証付きサービスのいずれも提供することが可能であ
る。以下のセクションでは、保証付きサービスを提供す
るトンネルを管理するための追加のアルゴリズムについ
て説明する。
【００２１】保証付きサービスのためのトンネル管理 ＴＤＰで実行される受信側主導割当て／受付制御、トン
ネル構成、およびトンネルチューニング手続きの説明に
進む前に、トンネルに関する以下の情報について説明す
る。
ネル構成、およびトンネルチューニング手続きの説明に
進む前に、トンネルに関する以下の情報について説明す
る。
【００２２】相異なるエンドツーエンドＲＳＶＰセッシ
ョンは相異なる遅延要求を有することがある。従って、
各トンネルごとに異なる遅延保証を有することが有効で
ある。ＴＳＰとＴＤＰの間にｎ個のトンネルがあり、各
トンネルの遅延保証がｄ1 T＜ｄ2 T＜...＜ｄn Tであると
仮定する。その場合、ＴＳＰとＴＤＰの間で遅延保証ｄ
を要求するエンドツーエンドＲＳＶＰセッションは、ト
ンネルｉが十分な容量を有すると仮定して、ｄi T＜ｄ＜
ｄi+1 Tである場合にトンネルｉにマッピングされること
になる。
ョンは相異なる遅延要求を有することがある。従って、
各トンネルごとに異なる遅延保証を有することが有効で
ある。ＴＳＰとＴＤＰの間にｎ個のトンネルがあり、各
トンネルの遅延保証がｄ1 T＜ｄ2 T＜...＜ｄn Tであると
仮定する。その場合、ＴＳＰとＴＤＰの間で遅延保証ｄ
を要求するエンドツーエンドＲＳＶＰセッションは、ト
ンネルｉが十分な容量を有すると仮定して、ｄi T＜ｄ＜
ｄi+1 Tである場合にトンネルｉにマッピングされること
になる。
【００２３】そこで、トンネルｉのＴＳＰＥＣをベクト
ルＴＳi T＝（ｂi T，ｒi T，ｐi T，Ｍ i T，ｍi T）で表す。
ただし、ｂi Tはバーストサイズであり、ｒi Tは平均レー
トであり、ｐi Tはピークレートであり、Ｍi Tはトンネル
メッセージ転送ユニット（ＭＴＵ：message transfer u
nit）であり、ｍi Tは課金ユニット（例えば、前掲のShe
nker el al., "General Characterization Parameters
for Integrated Service Network Elements"の論文を参
照）である。一般に、トンネルｉに関連するＣおよびＤ
の値（前掲のShenker et al., "Specification of Guar
anteed Qualityof Service"の論文を参照）（Ｃtot,i T
およびＤtot,i Tで表す）はＴＳi Tの関数であり、従っ
て、各トンネルごとに異なることがある。（なお、保証
付きサービスの場合、Ｄtot,i Tは更新されるがＣtot,i T
は更新されない。）
ルＴＳi T＝（ｂi T，ｒi T，ｐi T，Ｍ i T，ｍi T）で表す。
ただし、ｂi Tはバーストサイズであり、ｒi Tは平均レー
トであり、ｐi Tはピークレートであり、Ｍi Tはトンネル
メッセージ転送ユニット（ＭＴＵ：message transfer u
nit）であり、ｍi Tは課金ユニット（例えば、前掲のShe
nker el al., "General Characterization Parameters
for Integrated Service Network Elements"の論文を参
照）である。一般に、トンネルｉに関連するＣおよびＤ
の値（前掲のShenker et al., "Specification of Guar
anteed Qualityof Service"の論文を参照）（Ｃtot,i T
およびＤtot,i Tで表す）はＴＳi Tの関数であり、従っ
て、各トンネルごとに異なることがある。（なお、保証
付きサービスの場合、Ｄtot,i Tは更新されるがＣtot,i T
は更新されない。）
【００２４】一般性を失うことなく、それぞれ遅延ｄ1 T
およびｄ2 Tを保証する２つのトンネルを考える。遅延保
証ｄは次式により計算される。 ｄ＝（ｂ＋Ｃ）／Ｒ＋Ｄ （１） ただし、ｂはバーストサイズであり、Ｒは予約される帯
域幅であり、ＣおよびＤは前掲のShenker et al., "Spe
cification of Guaranteed Quality of Service"の論文
で定義される通りである。
およびｄ2 Tを保証する２つのトンネルを考える。遅延保
証ｄは次式により計算される。 ｄ＝（ｂ＋Ｃ）／Ｒ＋Ｄ （１） ただし、ｂはバーストサイズであり、Ｒは予約される帯
域幅であり、ＣおよびＤは前掲のShenker et al., "Spe
cification of Guaranteed Quality of Service"の論文
で定義される通りである。
【００２５】各トンネルは、次の帯域幅を要求すること
になる。 Ｒi T＝（ｂi T＋Ｃtot,i T）／（ｄi T−Ｄtot,i T） （２） ただし、ｉ＝１，２である。２つのトンネルをまとめた
（グループ化した）場合、保証遅延ｄ1 Tがなければなら
ず、新しいＴＳＰＥＣはＴＳg T＝（ｂ1 T＋ｂ2 T，ｒ1 T＋
ｒ2 T，ｐ1 T＋ｐ2 T，ｍａｘ｛Ｍ1 T，Ｍ2 T｝，ｍｉｎ｛ｍ
1 T，ｍ2 T｝）となる。対応して、このトンネルは、Ｃ
tot,g TおよびＤtot,g Tを有することになり、次の帯域幅
を要求する。 Ｒg T＝（ｂ1 T＋ｂ2 T＋Ｃtot,g T）／（ｄ1 T−Ｄtot,g T） （３）
になる。 Ｒi T＝（ｂi T＋Ｃtot,i T）／（ｄi T−Ｄtot,i T） （２） ただし、ｉ＝１，２である。２つのトンネルをまとめた
（グループ化した）場合、保証遅延ｄ1 Tがなければなら
ず、新しいＴＳＰＥＣはＴＳg T＝（ｂ1 T＋ｂ2 T，ｒ1 T＋
ｒ2 T，ｐ1 T＋ｐ2 T，ｍａｘ｛Ｍ1 T，Ｍ2 T｝，ｍｉｎ｛ｍ
1 T，ｍ2 T｝）となる。対応して、このトンネルは、Ｃ
tot,g TおよびＤtot,g Tを有することになり、次の帯域幅
を要求する。 Ｒg T＝（ｂ1 T＋ｂ2 T＋Ｃtot,g T）／（ｄ1 T−Ｄtot,g T） （３）
【００２６】明らかに、Ｒg T≦Ｒ1 T＋Ｒ2 Tの場合、２個
ではなく１個のトンネルを設定するほうが有利である。
ではなく１個のトンネルを設定するほうが有利である。
【００２７】中間ルータが、ＴＳＰから送信されるTUNN
EL_TSPECに部分的に基づいて、TUNNEL_ADSPEC内のＣtot
およびＤtotを更新するため、ＴＤＰが別のTUNNEL_TSPE
Cを使用することを決定する場合、Ｃtot T＝ｆ（TUNNEL_
TSPEC）およびＤtot T＝ｈ（TUNNEL_TSPEC）もまた異な
ることがある。ただし、ｆおよびｈは、ＴＳＰおよびＴ
ＤＰには未知の関数である。その結果、ＴＤＰは一般
に、ＲTを正しく計算するために、関数ｆおよびｈを知
る必要がある。
EL_TSPECに部分的に基づいて、TUNNEL_ADSPEC内のＣtot
およびＤtotを更新するため、ＴＤＰが別のTUNNEL_TSPE
Cを使用することを決定する場合、Ｃtot T＝ｆ（TUNNEL_
TSPEC）およびＤtot T＝ｈ（TUNNEL_TSPEC）もまた異な
ることがある。ただし、ｆおよびｈは、ＴＳＰおよびＴ
ＤＰには未知の関数である。その結果、ＴＤＰは一般
に、ＲTを正しく計算するために、関数ｆおよびｈを知
る必要がある。
【００２８】関数ｆおよびｈを求めるため、ＴＳＰは、
相異なるTUNNEL_TSPECを有するいくつかのTUNNEL_PATH
メッセージを送出することができる。ＴＤＰは、これら
のTUNNEL_TSPECを、対応するTUNNEL_ADSPECとともに受
信すると、ｆおよびｈを補間により評価することができ
る。トンネル予約に使用されないTUNNEL_PATHメッセー
ジはタイムアウトすることになる。
相異なるTUNNEL_TSPECを有するいくつかのTUNNEL_PATH
メッセージを送出することができる。ＴＤＰは、これら
のTUNNEL_TSPECを、対応するTUNNEL_ADSPECとともに受
信すると、ｆおよびｈを補間により評価することができ
る。トンネル予約に使用されないTUNNEL_PATHメッセー
ジはタイムアウトすることになる。
【００２９】実際には、ｆおよびｈは、複雑な関数であ
る可能性は少ない。例えば、中間ルータがすべてＷＦＱ
（重み付き公平キューイング：weighted fair queuein
g）を実装している場合、Ｃtot T＝（ｋ−１）ＭT、およ
び、Ｄtot T＝Σj kＭT／Ｃjである。ただし、ｋは、トン
ネル内のホップ数であり、Ｃjは、各ホップのリンク速
度である。この場合、ＴＳＰは、TUNNEL_TSPEC内の他の
すべての成分を固定したままＭTの値を変えていくつか
のTUNNEL_PATHメッセージを送信する。すると、ＴＤＰ
は、TUNNEL_TSPECおよびTUNNEL_ADSPECからデータ（Ｍj
T，Ｃj T，Ｄj T）のセットを収集し、これらを、それぞ
れＣj TおよびＤj Tの上限である、ＭTの１次関数に当て
はめる。
る可能性は少ない。例えば、中間ルータがすべてＷＦＱ
（重み付き公平キューイング：weighted fair queuein
g）を実装している場合、Ｃtot T＝（ｋ−１）ＭT、およ
び、Ｄtot T＝Σj kＭT／Ｃjである。ただし、ｋは、トン
ネル内のホップ数であり、Ｃjは、各ホップのリンク速
度である。この場合、ＴＳＰは、TUNNEL_TSPEC内の他の
すべての成分を固定したままＭTの値を変えていくつか
のTUNNEL_PATHメッセージを送信する。すると、ＴＤＰ
は、TUNNEL_TSPECおよびTUNNEL_ADSPECからデータ（Ｍj
T，Ｃj T，Ｄj T）のセットを収集し、これらを、それぞ
れＣj TおよびＤj Tの上限である、ＭTの１次関数に当て
はめる。
【００３０】ＴＳＰとＴＤＰの間に複数のパスが存在す
る場合、Ｃtot TおよびＤtot Tの値は、異なるパスでは非
常に異なることがある（そうでなければ、これらのパス
を区別する必要がない）。このような場合、ＴＤＰは、
まず、データを分類してクラスタに分けてから、補間に
進む。あるいは、ＴＤＰは、すべてのクラスタに対する
ＣTおよびＤTの単一の上限を求めることも可能である
が、これは控えめすぎることがある。
る場合、Ｃtot TおよびＤtot Tの値は、異なるパスでは非
常に異なることがある（そうでなければ、これらのパス
を区別する必要がない）。このような場合、ＴＤＰは、
まず、データを分類してクラスタに分けてから、補間に
進む。あるいは、ＴＤＰは、すべてのクラスタに対する
ＣTおよびＤTの単一の上限を求めることも可能である
が、これは控えめすぎることがある。
【００３１】トンネル管理を簡単にするため、トンネル
ＭＴＵが、すべてのトンネルに対するＭTとして常に使
用される。さらに、与えられたＭTに対して、ＣTおよび
ＤTはいずれも定数であると仮定する。これは、ＷＦＱ
ルータからエクスポートされる値と整合する。明らか
に、ＲＳＶＰもまたこの仮定を暗黙のうちにしている。
その理由は、受信側は、送信側から受信したのとは異な
るＴＳＰＥＣを指定することがあるが、それでも依然と
して、帯域幅要求を計算するためにＰＡＴＨメッセージ
内のＴＳＰＥＣに対応する同じＣおよびＤの値を使用す
るからである。この仮定が成り立たない場合、上記の補
間法を使用することが可能であり、計算の複雑さ（計算
量）はｆおよびｈの形に依存することになる。
ＭＴＵが、すべてのトンネルに対するＭTとして常に使
用される。さらに、与えられたＭTに対して、ＣTおよび
ＤTはいずれも定数であると仮定する。これは、ＷＦＱ
ルータからエクスポートされる値と整合する。明らか
に、ＲＳＶＰもまたこの仮定を暗黙のうちにしている。
その理由は、受信側は、送信側から受信したのとは異な
るＴＳＰＥＣを指定することがあるが、それでも依然と
して、帯域幅要求を計算するためにＰＡＴＨメッセージ
内のＴＳＰＥＣに対応する同じＣおよびＤの値を使用す
るからである。この仮定が成り立たない場合、上記の補
間法を使用することが可能であり、計算の複雑さ（計算
量）はｆおよびｈの形に依存することになる。
【００３２】上記の仮定の下で、 Ｒ1 T＋Ｒ2 T＝（ｂ1 T＋Ｃtot T）／（ｄ1 T−Ｄtot T）＋（ｂ2 T＋Ｃtot T）／（ ｄ2 T−Ｄtot T） （４） であり、２つのトンネルを１つに合併した場合、要求さ
れる帯域幅は、 Ｒg T＝（ｂ1 T＋ｂ2 T＋Ｃtot T）／（ｄ1 T−Ｄtot T） （５） である。
れる帯域幅は、 Ｒg T＝（ｂ1 T＋ｂ2 T＋Ｃtot T）／（ｄ1 T−Ｄtot T） （５） である。
【００３３】従って、
【数１】 となる。
【００３４】ｂ2 Tが一定の場合、これはｄ2に関して単
調増大関数であり、 ｄ2 T＜ｄ1 T＋（ｄ1 T−Ｄtot T）Ｃtot T／ｂ2 T （７） のとき、 Ｒg T＜Ｒ1 T＋Ｒ2 T （８） となる。
調増大関数であり、 ｄ2 T＜ｄ1 T＋（ｄ1 T−Ｄtot T）Ｃtot T／ｂ2 T （７） のとき、 Ｒg T＜Ｒ1 T＋Ｒ2 T （８） となる。
【００３５】つまり、２つのトンネルを１つに合併する
ことによって帯域幅が節約される。なお、ｄ2 T＝ｄ1 Tの
とき、Ｒg T−（Ｒ1 T＋Ｒ2 T）＝−Ｃtot T／（ｄ1 T−Ｄ
tot T）＜０である。すなわち、同じ遅延要求のセッショ
ンを１つのトンネルにまとめることによって、常に帯域
幅が節約される。この特殊な場合は、S. Rampal and R.
Guerin, "Flow Grouping for Reducing Reservation Re
quirements for Guaranteed Delay Service", draft-ra
mpal-flow-delay-service-01.txt, July 1997、で観察
されたものである。
ことによって帯域幅が節約される。なお、ｄ2 T＝ｄ1 Tの
とき、Ｒg T−（Ｒ1 T＋Ｒ2 T）＝−Ｃtot T／（ｄ1 T−Ｄ
tot T）＜０である。すなわち、同じ遅延要求のセッショ
ンを１つのトンネルにまとめることによって、常に帯域
幅が節約される。この特殊な場合は、S. Rampal and R.
Guerin, "Flow Grouping for Reducing Reservation Re
quirements for Guaranteed Delay Service", draft-ra
mpal-flow-delay-service-01.txt, July 1997、で観察
されたものである。
【００３６】式（６）でｄ2 T→∞とすると、 Ｒg T−（Ｒ1 T＋Ｒ2 T）＝ｂ2 T／（ｄ1 T−Ｄtot T）＞０ （９） となる。
【００３７】これはもう１つの極端な場合であり、ｄ2 T
が十分に大きいとき、２つのトンネルを別々のままにし
たほうが帯域効率が良いことを示している。
が十分に大きいとき、２つのトンネルを別々のままにし
たほうが帯域効率が良いことを示している。
【００３８】上記の考察からわかるように、使用される
帯域を効率的にトンネルに分割する方法について決定す
るときに用いるのに、遅延は良好な指標となる可能性が
ある。これは実際その通りである。
帯域を効率的にトンネルに分割する方法について決定す
るときに用いるのに、遅延は良好な指標となる可能性が
ある。これは実際その通りである。
【００３９】パラメータセット（ｂi，Ｒi，ｄi）（ｉ
＝１，...，ｎ）を有するｎ個のＲＳＶＰセッションが
ある場合を考え、これらのセッションがｄiでソートさ
れていると仮定する。トンネルが遅延ｄTを保証するよ
うに設定された場合、ｄTより小さい遅延要求のセッシ
ョンはこのトンネルには入らない。他方、遅延要求
ｄT′＜ｄTのトンネルに、ｄTより大きい遅延要求のセ
ッションｉを入れるのは帯域効率が悪い。これは次のこ
とから明らかである。すなわち、遅延保証ｄTのトンネ
ルにこのセッションを追加するのに要する追加帯域幅は
ΔＲ＝ｂi／（ｄT−Ｄto t T）であり、帯域保証ｄT′の
トンネルにこのセッションを追加するのに要する追加帯
域幅はΔＲ′＝ｂi／（ｄT′−Ｄtot T）＞ΔＲであるか
らである。
＝１，...，ｎ）を有するｎ個のＲＳＶＰセッションが
ある場合を考え、これらのセッションがｄiでソートさ
れていると仮定する。トンネルが遅延ｄTを保証するよ
うに設定された場合、ｄTより小さい遅延要求のセッシ
ョンはこのトンネルには入らない。他方、遅延要求
ｄT′＜ｄTのトンネルに、ｄTより大きい遅延要求のセ
ッションｉを入れるのは帯域効率が悪い。これは次のこ
とから明らかである。すなわち、遅延保証ｄTのトンネ
ルにこのセッションを追加するのに要する追加帯域幅は
ΔＲ＝ｂi／（ｄT−Ｄto t T）であり、帯域保証ｄT′の
トンネルにこのセッションを追加するのに要する追加帯
域幅はΔＲ′＝ｂi／（ｄT′−Ｄtot T）＞ΔＲであるか
らである。
【００４０】このことから次のことがわかる。与えられ
たセッションのセットに対して、さまざまな遅延保証ｄ
1 T＜ｄ2 T＜...＜ｄn Tを提供するようにトンネルが設定
された場合、遅延要求ｄj T≦ｄi＜ｄj+1 Tのセッション
をトンネルｊに入れると帯域効率がよい。従って、与え
られたＲＳＶＰセッション統計に基づいてトンネルがあ
らかじめ構成されている場合、ＲＳＶＰセッションは、
まずｄiでソートすべきである（詳細は後述）。
たセッションのセットに対して、さまざまな遅延保証ｄ
1 T＜ｄ2 T＜...＜ｄn Tを提供するようにトンネルが設定
された場合、遅延要求ｄj T≦ｄi＜ｄj+1 Tのセッション
をトンネルｊに入れると帯域効率がよい。従って、与え
られたＲＳＶＰセッション統計に基づいてトンネルがあ
らかじめ構成されている場合、ＲＳＶＰセッションは、
まずｄiでソートすべきである（詳細は後述）。
【００４１】一般に、ＴＳＰは、トンネルがどのような
種類のＴＳＰＥＣをサポートすることができるかを知ら
ないため、できるだけ大きいＴＳＰＥＣとして知ってい
ることを単に送信する。具体的には、ＴＳＰは、ｂTが
そのバッファサイズであり、ｐTが入力リンク速度の和
（または無限大）であり、ｒTが出力リンク速度であ
り、ＭTが出力インタフェースによってサポートされる
最大パケットサイズであり、ｍTがＴＳＰによってサポ
ートされる最小の課金単位であるとして、送信する。
種類のＴＳＰＥＣをサポートすることができるかを知ら
ないため、できるだけ大きいＴＳＰＥＣとして知ってい
ることを単に送信する。具体的には、ＴＳＰは、ｂTが
そのバッファサイズであり、ｐTが入力リンク速度の和
（または無限大）であり、ｒTが出力リンク速度であ
り、ＭTが出力インタフェースによってサポートされる
最大パケットサイズであり、ｍTがＴＳＰによってサポ
ートされる最小の課金単位であるとして、送信する。
【００４２】また、ＴＳＰは、設定するトンネルの適当
な個数を知らないため、トンネル設定期間中に、ＴＳＰ
がサポート可能なトンネルの数と同数以上のTUNNEL_PAT
Hメッセージを送信する。過剰のTUNNEL_PATHメッセージ
は、必要であればパラメータ補間をサポートするために
使用可能であり、対応するTUNNEL_RESVメッセージがタ
イムアウト期間内に受信されないときにはルータから消
去される。
な個数を知らないため、トンネル設定期間中に、ＴＳＰ
がサポート可能なトンネルの数と同数以上のTUNNEL_PAT
Hメッセージを送信する。過剰のTUNNEL_PATHメッセージ
は、必要であればパラメータ補間をサポートするために
使用可能であり、対応するTUNNEL_RESVメッセージがタ
イムアウト期間内に受信されないときにはルータから消
去される。
【００４３】トンネルの適当な個数とTUNNEL_TSPECの値
はＴＤＰによって計算される。その後、ＴＤＰは、TUNN
EL_FLOWSPEC内のTUNNEL_TSPECとともにTUNNEL_RESVメッ
セージをＴＳＰへ送る。このTUNNEL_RESVメッセージ
は、FilterspecがＴＳＰのＩＰアドレスとＵＤＰデステ
ィネーションポート番号を指定するＦＦ予約スタイルを
使用すべきである。
はＴＤＰによって計算される。その後、ＴＤＰは、TUNN
EL_FLOWSPEC内のTUNNEL_TSPECとともにTUNNEL_RESVメッ
セージをＴＳＰへ送る。このTUNNEL_RESVメッセージ
は、FilterspecがＴＳＰのＩＰアドレスとＵＤＰデステ
ィネーションポート番号を指定するＦＦ予約スタイルを
使用すべきである。
【００４４】受信側主導トンネル割当て／受付制御 ＲＳＶＰは受信側主導のプロトコルである。アプリケー
ションの遅延要求と、エンドツーエンドＲＳＶＰ ＰＡ
ＴＨメッセージ内のＴＳＰＥＣおよびＡＤＳＰＥＣで受
信されるパラメータに基づいて、受信側は、所望の帯域
幅Ｒ、スラック項Ｓ、および所望のＴＳＰＥＣを計算
し、それらをＦＬＯＷＳＰＥＣでアップストリームへ送
信する。
ションの遅延要求と、エンドツーエンドＲＳＶＰ ＰＡ
ＴＨメッセージ内のＴＳＰＥＣおよびＡＤＳＰＥＣで受
信されるパラメータに基づいて、受信側は、所望の帯域
幅Ｒ、スラック項Ｓ、および所望のＴＳＰＥＣを計算
し、それらをＦＬＯＷＳＰＥＣでアップストリームへ送
信する。
【００４５】本発明によれば、ＴＤＰは、カプセル化さ
れたＲＳＶＰ ＰＡＴＨメッセージをＴＳＰから受信し
た後、それをカプセル化解除し、ＡＤＳＰＥＣを変更す
る。ＴＤＰは常に、トンネルについてＣ＝０およびＤ＝
ｄ1 T（最小遅延）であると（たとえそのトンネルにもう
空き容量がなくても）公示する。ＴＤＰは、受信側から
返されたＲＥＳＶメッセージを受信すると、スラック項
の一部０≦Ｓ0≦Ｓをオプションとして使用して、この
セッションを、ｄ1 T＋Ｓ0より小さい遅延を保証するト
ンネルｉにマッピングする。その後、ＴＤＰは、Ｓをｄ
i T−ｄ1 Tだけ小さくする。このセッションに関して、資
格のあるいずれのトンネルにも十分な容量がない場合で
も、遅延保証に違反することなくこのセッションを別の
トンネルにマッピングすることは可能である。これにつ
いて以下で詳述する。
れたＲＳＶＰ ＰＡＴＨメッセージをＴＳＰから受信し
た後、それをカプセル化解除し、ＡＤＳＰＥＣを変更す
る。ＴＤＰは常に、トンネルについてＣ＝０およびＤ＝
ｄ1 T（最小遅延）であると（たとえそのトンネルにもう
空き容量がなくても）公示する。ＴＤＰは、受信側から
返されたＲＥＳＶメッセージを受信すると、スラック項
の一部０≦Ｓ0≦Ｓをオプションとして使用して、この
セッションを、ｄ1 T＋Ｓ0より小さい遅延を保証するト
ンネルｉにマッピングする。その後、ＴＤＰは、Ｓをｄ
i T−ｄ1 Tだけ小さくする。このセッションに関して、資
格のあるいずれのトンネルにも十分な容量がない場合で
も、遅延保証に違反することなくこのセッションを別の
トンネルにマッピングすることは可能である。これにつ
いて以下で詳述する。
【００４６】トンネルについてできるだけ小さい単一の
遅延値ｄ1 Tを公示することにより、プロトコルは単純か
つスケーラブルになる。すなわち、ＴＤＰは、受信側の
さまざまな相異なる遅延保証要求を知る必要がなく、単
に、なし得る最善のことを公示する。なお、ＲＳＶＰプ
ロトコルの受信側主導性により、ＴＤＰは、送信側から
のＡＤＳＰＥＣを処理するときに、ＲＳＶＰセッション
の遅延要求を知ることさえもない。
遅延値ｄ1 Tを公示することにより、プロトコルは単純か
つスケーラブルになる。すなわち、ＴＤＰは、受信側の
さまざまな相異なる遅延保証要求を知る必要がなく、単
に、なし得る最善のことを公示する。なお、ＲＳＶＰプ
ロトコルの受信側主導性により、ＴＤＰは、送信側から
のＡＤＳＰＥＣを処理するときに、ＲＳＶＰセッション
の遅延要求を知ることさえもない。
【００４７】受信側が、より多くの遅延を許容すること
ができる場合、第１の選択肢として、スラック項Ｓに過
剰な値を入れることがある。この場合、ＴＤＰは、この
過剰値を用いて、上記のように、より緩い遅延保証のト
ンネルにセッションをマッピングすることができる。受
信側の第２の選択肢は、単に、より小さい帯域幅を予約
することである。ほとんどの受信側が第２の選択肢を選
ぶ場合、最小の遅延を提供するトンネルは、より大きい
帯域幅のシェアを必要とする。この問題点についてはさ
らに後述する。
ができる場合、第１の選択肢として、スラック項Ｓに過
剰な値を入れることがある。この場合、ＴＤＰは、この
過剰値を用いて、上記のように、より緩い遅延保証のト
ンネルにセッションをマッピングすることができる。受
信側の第２の選択肢は、単に、より小さい帯域幅を予約
することである。ほとんどの受信側が第２の選択肢を選
ぶ場合、最小の遅延を提供するトンネルは、より大きい
帯域幅のシェアを必要とする。この問題点についてはさ
らに後述する。
【００４８】上記の説明からわかるように、トンネルは
ＲＳＶＰセッション要求の前に確立されるが、ＴＤＰ
は、受信側からのＲＥＳＶおよびＴＳＰＥＣメッセージ
を使用することによって、トンネルを最大限に利用（す
なわち、セッションをトンネルにマッピングする）しよ
うとする。
ＲＳＶＰセッション要求の前に確立されるが、ＴＤＰ
は、受信側からのＲＥＳＶおよびＴＳＰＥＣメッセージ
を使用することによって、トンネルを最大限に利用（す
なわち、セッションをトンネルにマッピングする）しよ
うとする。
【００４９】各ＲＳＶＰトンネルごとに、ＴＤＰは、パ
ラメータのセット（ｂT，ＲT，ｄT，ｐT，ＭT）を管理
する。ＴＤＰは、以下の条件がすべて成立する場合に、
新しいＲＳＶＰセッションをトンネルに受け付ける（図
５のステップ２２５および２３０）。
ラメータのセット（ｂT，ＲT，ｄT，ｐT，ＭT）を管理
する。ＴＤＰは、以下の条件がすべて成立する場合に、
新しいＲＳＶＰセッションをトンネルに受け付ける（図
５のステップ２２５および２３０）。
【数２】
【００５０】なお、ｐTは、トンネルの入力リンク速度
の総和と設定され、ＭTは、トンネルのＭＴＵと設定さ
れるため、式（１２）および（１３）で表される条件は
常に真になるはずである。
の総和と設定され、ＭTは、トンネルのＭＴＵと設定さ
れるため、式（１２）および（１３）で表される条件は
常に真になるはずである。
【００５１】トンネル構成 トンネルを確立する前に、ＴＳＰとＴＤＰの間でのＲＳ
ＶＰセッションについての統計が存在すると仮定する。
具体的には、各セッションｉ＝１，...，Ｎごとに、
（ｂi，Ｒi，Ｓi）が記録される。ただし、ｂiは最大バ
ーストサイズであり、Ｒiは予約される帯域幅であり、
Ｓiはスラック項である。このような統計が典型的なト
ラフィックパターンを表すと仮定した場合に、帯域を効
率的に利用するようにトンネルを構成する方法を見つけ
ることが望ましい。Ｓiのうち、Ｓi 0がトンネルによっ
て使用されると仮定する。トラフィックプロファイルに
基づくトンネル構成アルゴリズム（Tunnel_Config
（ｂ，Ｒ，Ｓ0，Ｎ））は次の通りである。
ＶＰセッションについての統計が存在すると仮定する。
具体的には、各セッションｉ＝１，...，Ｎごとに、
（ｂi，Ｒi，Ｓi）が記録される。ただし、ｂiは最大バ
ーストサイズであり、Ｒiは予約される帯域幅であり、
Ｓiはスラック項である。このような統計が典型的なト
ラフィックパターンを表すと仮定した場合に、帯域を効
率的に利用するようにトンネルを構成する方法を見つけ
ることが望ましい。Ｓiのうち、Ｓi 0がトンネルによっ
て使用されると仮定する。トラフィックプロファイルに
基づくトンネル構成アルゴリズム（Tunnel_Config
（ｂ，Ｒ，Ｓ0，Ｎ））は次の通りである。
【００５２】 １．ｄi＝（ｂi＋Ｃtot T）／Ｒi＋Ｄtot T とおく。 ２．ｄi＋Ｓi 0（ｉ＝１，...，Ｎ）をキーとして用い
て、ベクトル（Ｒi，ｂi，ｄi＋Ｓi 0）をソートする。 ３．ｎ＝１，...，Ｎのそれぞれについて、次式を計算
する。
て、ベクトル（Ｒi，ｂi，ｄi＋Ｓi 0）をソートする。 ３．ｎ＝１，...，Ｎのそれぞれについて、次式を計算
する。
【数３】 ４．ｎ0＝ａｒｇｍｉｎ｛Ｒ1,n0 g＋Ｒ2,n0 g｝を求め
る。 ５．ｎ0＝１の場合、ｄT＝ｄ1＋Ｓ1 0、ｂT＝Σi Nｂi、
およびＲT＝（ｂT＋Ｃtot T）／（ｄT−Ｄtot T）として
トンネルが構成され、Tunnel_Configは終了する。 ６．ｎ0＞１の場合、Tunnel_Config（（ｂ1，...，ｂ
n0-1），（Ｒ1，...，Ｒn0-1），（Ｓ0 1，...，
Ｓ0 n0-1），ｎ0−１）、および、Tunnel_Config（（ｂ
n0，...，ｂN），（Ｒn0，...，ＲN），（Ｓ0 n0，...，
Ｓ0 N），Ｎ−ｎ0−１）を実行する。
る。 ５．ｎ0＝１の場合、ｄT＝ｄ1＋Ｓ1 0、ｂT＝Σi Nｂi、
およびＲT＝（ｂT＋Ｃtot T）／（ｄT−Ｄtot T）として
トンネルが構成され、Tunnel_Configは終了する。 ６．ｎ0＞１の場合、Tunnel_Config（（ｂ1，...，ｂ
n0-1），（Ｒ1，...，Ｒn0-1），（Ｓ0 1，...，
Ｓ0 n0-1），ｎ0−１）、および、Tunnel_Config（（ｂ
n0，...，ｂN），（Ｒn0，...，ＲN），（Ｓ0 n0，...，
Ｓ0 N），Ｎ−ｎ0−１）を実行する。
【００５３】トンネル構成プロセスは、ステップ１で、
ｄiを計算することから開始する。ｄiは、トンネルがセ
ッションｉのみに対して作成された場合にこのセッショ
ンが受ける遅延である。次に、ステップ２で、ｄi＋Ｓi
0をキーとして用いて、ベクトル（Ｒi，ｂi，ｄi＋
Ｓi 0）をソートする。次に、ステップ３で、セッション
を２つのグループに分割し、各グループについて帯域幅
を計算する。全帯域幅の最も少ない分割を固定し、プロ
セスは、ステップ４、５、および６で、この分割のそれ
ぞれの部分について再帰的に実行される。さらに分割を
しても帯域幅要求がもはや減少しなくなったら、再帰的
実行を終了する。
ｄiを計算することから開始する。ｄiは、トンネルがセ
ッションｉのみに対して作成された場合にこのセッショ
ンが受ける遅延である。次に、ステップ２で、ｄi＋Ｓi
0をキーとして用いて、ベクトル（Ｒi，ｂi，ｄi＋
Ｓi 0）をソートする。次に、ステップ３で、セッション
を２つのグループに分割し、各グループについて帯域幅
を計算する。全帯域幅の最も少ない分割を固定し、プロ
セスは、ステップ４、５、および６で、この分割のそれ
ぞれの部分について再帰的に実行される。さらに分割を
しても帯域幅要求がもはや減少しなくなったら、再帰的
実行を終了する。
【００５４】トンネルチューニング ＲＳＶＰセッションのパス上のトンネルの存在は、送信
側および受信側の双方にとってトランスペアレントであ
る。前述のように、ＴＤＰは常に、提供可能な最もきつ
い遅延保証を公示する。その結果、受信側に見えるの
は、パス上の最小のＤtotの値である。受信側のアプリ
ケーションがより大きな遅延を許容することができる場
合、予約メッセージにおいて、スラック項を入れるか、
それとも、単により小さい帯域幅を要求するかを決定す
ることは受信側に任される。
側および受信側の双方にとってトランスペアレントであ
る。前述のように、ＴＤＰは常に、提供可能な最もきつ
い遅延保証を公示する。その結果、受信側に見えるの
は、パス上の最小のＤtotの値である。受信側のアプリ
ケーションがより大きな遅延を許容することができる場
合、予約メッセージにおいて、スラック項を入れるか、
それとも、単により小さい帯域幅を要求するかを決定す
ることは受信側に任される。
【００５５】前述のように、ＴＤＰでスラック項Ｓ＞０
が見える場合、ＴＤＰは、オプションとして、その一部
を使用することができる。他方、Ｓ＝０である場合、Ｔ
ＤＰは、最もきつい遅延保証のトンネルにＲＳＶＰセッ
ションを入れるしかない。その結果、このトンネルは、
他のトンネルよりもずっと急速に満たされる可能性が高
い。一般に、トンネルはあらかじめ分割されているた
め、トンネルが分割される際に基づくパラメータにトラ
フィックパターンが一致する可能性は少ない。そのよう
な場合、トンネルパラメータを動的に調整してトラフィ
ックパターンに合わせることができる。
が見える場合、ＴＤＰは、オプションとして、その一部
を使用することができる。他方、Ｓ＝０である場合、Ｔ
ＤＰは、最もきつい遅延保証のトンネルにＲＳＶＰセッ
ションを入れるしかない。その結果、このトンネルは、
他のトンネルよりもずっと急速に満たされる可能性が高
い。一般に、トンネルはあらかじめ分割されているた
め、トンネルが分割される際に基づくパラメータにトラ
フィックパターンが一致する可能性は少ない。そのよう
な場合、トンネルパラメータを動的に調整してトラフィ
ックパターンに合わせることができる。
【００５６】前掲のGuerin et al., "Aggregating RSVP
-based QoS Requests"の論文に記載されているように、
トンネルによって提供される遅延保証は、バーストサイ
ズｂ Tおよび帯域幅ＲTの関数である。なお、セッション
が遅延保証を必要とする場合、ｄよりも小さい遅延保証
のすべてのトンネルが満たされているときにのみ、ｄ j T
＞ｄのトンネルｊを使用することが必要となる。すなわ
ち、ｄj Tは、ｄj,new T＜ｄj,old Tとなるように調整され
るべきである。これは、既存のトンネルの帯域幅を増大
させなければならないか、または、ｄT＞ｄのトンネル
で許容されるバーストサイズを減少させなければならな
いかのいずれかであることを意味する。いずれの場合で
も、トンネルパラメータの変更を通知するためにTUNNEL
_FLOWSPECがＴＤＰからＴＳＰへ送られる。
-based QoS Requests"の論文に記載されているように、
トンネルによって提供される遅延保証は、バーストサイ
ズｂ Tおよび帯域幅ＲTの関数である。なお、セッション
が遅延保証を必要とする場合、ｄよりも小さい遅延保証
のすべてのトンネルが満たされているときにのみ、ｄ j T
＞ｄのトンネルｊを使用することが必要となる。すなわ
ち、ｄj Tは、ｄj,new T＜ｄj,old Tとなるように調整され
るべきである。これは、既存のトンネルの帯域幅を増大
させなければならないか、または、ｄT＞ｄのトンネル
で許容されるバーストサイズを減少させなければならな
いかのいずれかであることを意味する。いずれの場合で
も、トンネルパラメータの変更を通知するためにTUNNEL
_FLOWSPECがＴＤＰからＴＳＰへ送られる。
【００５７】トンネル帯域幅Ｒj Tを増大させる要求は、
利用可能な帯域幅に依存して受け入れられない可能性が
あるが、バーストサイズｂj Tを減少させる要求はそのよ
うな可能性はない。従って、バーストサイズを減少させ
ることが、トンネルを動的に調整する好ましい方法であ
る。
利用可能な帯域幅に依存して受け入れられない可能性が
あるが、バーストサイズｂj Tを減少させる要求はそのよ
うな可能性はない。従って、バーストサイズを減少させ
ることが、トンネルを動的に調整する好ましい方法であ
る。
【００５８】トンネルが新しい遅延保証ｄnew Tを提供す
るためには、新しい許容バーストサイズは、 ｂnew T＝（ｄnew T−Ｄtot T）×ＲT−Ｃtot T （１５） である。
るためには、新しい許容バーストサイズは、 ｂnew T＝（ｄnew T−Ｄtot T）×ＲT−Ｃtot T （１５） である。
【００５９】バーストサイズの減少を要求する決定をす
る前に、ＴＤＰはまず、新しいトンネルに対しても受付
基準（前述）が成り立つことを確認しなければならな
い。
る前に、ＴＤＰはまず、新しいトンネルに対しても受付
基準（前述）が成り立つことを確認しなければならな
い。
【００６０】トンネル調整は、一時的に行うことも可能
である。すなわち、小さい遅延要求のセッションが終了
した後、トンネルは、ＴＤＰからＴＳＰへTUNNEL_FLOWS
PECを送ることによって、下のパラメータに戻すことが
可能である。
である。すなわち、小さい遅延要求のセッションが終了
した後、トンネルは、ＴＤＰからＴＳＰへTUNNEL_FLOWS
PECを送ることによって、下のパラメータに戻すことが
可能である。
【００６１】動的なトンネル調整は、トンネルパラメー
タを現在のトラフィックの需要に合わせるように変化さ
せるのに有用であるが、同様の遅延保証を有する複数の
トンネルが生じることもある。前述のように、このよう
な場合、これらのトンネルをまとめるほうが帯域効率が
よい可能性がある。一般に、トラフィックパターンは、
はじめにトンネルを分割するために使用されたものと一
致しないことがあるため、利用可能な帯域を効率的に使
用するためには、トンネル分割は、時間が経つにつれて
変更しなければならないことがある。そこで、トンネル
チューニング手続きにより、受け付けられるエンドツー
エンドＲＳＶＰセッションの一部のトンネル再割当てが
起こることがある。
タを現在のトラフィックの需要に合わせるように変化さ
せるのに有用であるが、同様の遅延保証を有する複数の
トンネルが生じることもある。前述のように、このよう
な場合、これらのトンネルをまとめるほうが帯域効率が
よい可能性がある。一般に、トラフィックパターンは、
はじめにトンネルを分割するために使用されたものと一
致しないことがあるため、利用可能な帯域を効率的に使
用するためには、トンネル分割は、時間が経つにつれて
変更しなければならないことがある。そこで、トンネル
チューニング手続きにより、受け付けられるエンドツー
エンドＲＳＶＰセッションの一部のトンネル再割当てが
起こることがある。
【００６２】トラフィックプロファイルもまた、ベクト
ル（ｂi，Ｒi，Ｓi）のセットによって記述され、ＴＤ
Ｐによって記録される。しかし、前述の例とは異なり、
遅延保証値は別の方法で計算される。
ル（ｂi，Ｒi，Ｓi）のセットによって記述され、ＴＤ
Ｐによって記録される。しかし、前述の例とは異なり、
遅延保証値は別の方法で計算される。
【００６３】トンネルは各セッションｉごとに遅延値ｄ
Tを公示しているため、遅延ｄT＋Ｓ i 0を保証しなければ
ならない。ただし、０≦Ｓi 0≦Ｓiは、トンネルが使用
することに決めたスラック値である。トンネルチューニ
ングアルゴリズムは、遅延を計算する方法を除いては、
トンネル構成アルゴリズム（前述）と同様である。トン
ネルチューニングアルゴリズム（Tunnel_Tuning（ｂ，
Ｒ，Ｓ0，Ｎ））は次の通りである。 １．ｄi＝ｄT とおく。 ２．ｄi＋Ｓi 0（ｉ＝１，...，Ｎ）をキーとして用い
て、ベクトル（Ｒi，ｂi，ｄi＋Ｓi 0）をソートする。 ３．ｎ＝１，...，Ｎのそれぞれについて、次式を計算
する。
Tを公示しているため、遅延ｄT＋Ｓ i 0を保証しなければ
ならない。ただし、０≦Ｓi 0≦Ｓiは、トンネルが使用
することに決めたスラック値である。トンネルチューニ
ングアルゴリズムは、遅延を計算する方法を除いては、
トンネル構成アルゴリズム（前述）と同様である。トン
ネルチューニングアルゴリズム（Tunnel_Tuning（ｂ，
Ｒ，Ｓ0，Ｎ））は次の通りである。 １．ｄi＝ｄT とおく。 ２．ｄi＋Ｓi 0（ｉ＝１，...，Ｎ）をキーとして用い
て、ベクトル（Ｒi，ｂi，ｄi＋Ｓi 0）をソートする。 ３．ｎ＝１，...，Ｎのそれぞれについて、次式を計算
する。
【数４】 ４．ｎ0＝ａｒｇｍｉｎ｛Ｒ1,n0 g＋Ｒ2,n0 g｝を求め
る。 ５．ｎ0＝１の場合、ｄT＝ｄ1＋Ｓ1 0、ｂT＝Σi Nｂi、
およびＲT＝（ｂT＋Ｃtot T）／（ｄT−Ｄtot T）として
トンネルが構成され、Tunnel_Tuningは終了する。 ６．ｎ0＞１の場合、Tunnel_Tuning（（ｂ1，...，ｂ
n0-1），（Ｒ1，...，Ｒn0-1），（Ｓ0 1，...，
Ｓ0 n0-1），ｎ0−１）、および、Tunnel_Tuning（（ｂ
n0，...，ｂN），（Ｒn0，...，ＲN），（Ｓ0 n0，...，
Ｓ0 N），Ｎ−ｎ0−１）を実行する。
る。 ５．ｎ0＝１の場合、ｄT＝ｄ1＋Ｓ1 0、ｂT＝Σi Nｂi、
およびＲT＝（ｂT＋Ｃtot T）／（ｄT−Ｄtot T）として
トンネルが構成され、Tunnel_Tuningは終了する。 ６．ｎ0＞１の場合、Tunnel_Tuning（（ｂ1，...，ｂ
n0-1），（Ｒ1，...，Ｒn0-1），（Ｓ0 1，...，
Ｓ0 n0-1），ｎ0−１）、および、Tunnel_Tuning（（ｂ
n0，...，ｂN），（Ｒn0，...，ＲN），（Ｓ0 n0，...，
Ｓ0 N），Ｎ−ｎ0−１）を実行する。
【００６４】プロトコルパフォーマンスに影響を及ぼす
もう１つの重要なファクタは、公示されるトンネル遅延
値（すべてのトンネルのうちで最小のもの）である。こ
の値が大きすぎる場合、いくつかの受信側では遅延が許
容できず、ＲＳＶＰセッションは失敗することになる。
他方、この値が小さすぎて、しかも、受信側はスラック
項を与えない場合（または、スラックが、ＴＤＰと受信
側の間のルータで使い尽くされてしまった場合）、トン
ネル帯域幅に対する過大な要求になる可能性がある。
もう１つの重要なファクタは、公示されるトンネル遅延
値（すべてのトンネルのうちで最小のもの）である。こ
の値が大きすぎる場合、いくつかの受信側では遅延が許
容できず、ＲＳＶＰセッションは失敗することになる。
他方、この値が小さすぎて、しかも、受信側はスラック
項を与えない場合（または、スラックが、ＴＤＰと受信
側の間のルータで使い尽くされてしまった場合）、トン
ネル帯域幅に対する過大な要求になる可能性がある。
【００６５】適当な公示遅延値を見つけるため、ＴＤＰ
は、小さい公示値から開始して、失敗するＲＳＶＰセッ
ションが大幅に増大するまで、（この場合も、動的調整
よりもずっと長い時間スケールで）次第に公示値を増大
させる。
は、小さい公示値から開始して、失敗するＲＳＶＰセッ
ションが大幅に増大するまで、（この場合も、動的調整
よりもずっと長い時間スケールで）次第に公示値を増大
させる。
【００６６】上記のことからわかるように、本発明によ
る新規なＲＳＶＰベースのトンネルプロトコルは、以下
の顕著な特徴を有する。 ・ＴＤＰは、どのエンドツーエンドセッションがどのト
ンネルに割り当てられるかについて、トンネルのパラメ
ータと、受信側からのエンドツーエンドＲＥＳＶメッセ
ージとに基づいて、決定する。 ・ＴＤＰは、ＴＳＰとＴＤＰの間のすべてのトンネルに
対する単一の遅延値を公示する。これにより、プロトコ
ルは単純かつスケーラブルになる。 ・トラフィックプロファイルに基づいて、ＴＤＰは、帯
域を効率的に使用するようにトンネルを分割する。 ・ＴＤＰは、トラフィックダイナミクスに応じてトンネ
ルを調整する。 ・ＴＤＰは、プロトコルパフォーマンスを改善するため
に、長い時間スケールでトンネルを調整する。 ・ＣおよびＤが、ＴＳＰＥＣ内のいくつかのパラメータ
の未知関数である場合、さまざまなパラメータ値の複数
のＴＳＰＥＣメッセージを送信して、関数を補間により
推定することができる。
る新規なＲＳＶＰベースのトンネルプロトコルは、以下
の顕著な特徴を有する。 ・ＴＤＰは、どのエンドツーエンドセッションがどのト
ンネルに割り当てられるかについて、トンネルのパラメ
ータと、受信側からのエンドツーエンドＲＥＳＶメッセ
ージとに基づいて、決定する。 ・ＴＤＰは、ＴＳＰとＴＤＰの間のすべてのトンネルに
対する単一の遅延値を公示する。これにより、プロトコ
ルは単純かつスケーラブルになる。 ・トラフィックプロファイルに基づいて、ＴＤＰは、帯
域を効率的に使用するようにトンネルを分割する。 ・ＴＤＰは、トラフィックダイナミクスに応じてトンネ
ルを調整する。 ・ＴＤＰは、プロトコルパフォーマンスを改善するため
に、長い時間スケールでトンネルを調整する。 ・ＣおよびＤが、ＴＳＰＥＣ内のいくつかのパラメータ
の未知関数である場合、さまざまなパラメータ値の複数
のＴＳＰＥＣメッセージを送信して、関数を補間により
推定することができる。
【００６７】最初の特徴により、プロトコルはＲＳＶＰ
の受信側主導性と整合性のあるものとなり、残りの特徴
により、プロトコルは、単純で、スケーラブルで、フレ
キシブルになるとともに、トンネル帯域を効率的に利用
することになる。
の受信側主導性と整合性のあるものとなり、残りの特徴
により、プロトコルは、単純で、スケーラブルで、フレ
キシブルになるとともに、トンネル帯域を効率的に利用
することになる。
【００６８】図１２に、簡単に、本発明の原理による代
表的なＴＤＰの高水準ブロック図を示す。ＴＤＰは、蓄
積プログラム制御方式のプロセッサアーキテクチャであ
り、プロセッサ６５０、メモリ６６０（プログラム命令
およびデータ（例えば、上記の新規なＲＳＶＰベースの
トンネルプロトコルにより通信するためのものなど）を
格納する）、および、パス６６６で表されるような通信
設備に接続するための通信インタフェース６６５を有す
る。
表的なＴＤＰの高水準ブロック図を示す。ＴＤＰは、蓄
積プログラム制御方式のプロセッサアーキテクチャであ
り、プロセッサ６５０、メモリ６６０（プログラム命令
およびデータ（例えば、上記の新規なＲＳＶＰベースの
トンネルプロトコルにより通信するためのものなど）を
格納する）、および、パス６６６で表されるような通信
設備に接続するための通信インタフェース６６５を有す
る。
【００６９】以上、本発明の実施例について説明した
が、当業者であれば、上記の説明に基づいて、本発明の
技術的範囲から離れることなく、さまざまな変形例を考
えることが可能である。例えば、本発明の概念は、モバ
イルＩＰサービスの上でＱｏＳ保証を提供するために使
用することも可能である。この場合、ホームエージェン
トから外部エージェントへのＩＰトンネルが設定され、
このようなトンネルは、本発明の原理によるＲＳＶＰを
使用して、まとめられたトラフィックのＱｏＳ要求を通
知し、各フローごとのＱｏＳ要求が満たされるようにさ
れる。
が、当業者であれば、上記の説明に基づいて、本発明の
技術的範囲から離れることなく、さまざまな変形例を考
えることが可能である。例えば、本発明の概念は、モバ
イルＩＰサービスの上でＱｏＳ保証を提供するために使
用することも可能である。この場合、ホームエージェン
トから外部エージェントへのＩＰトンネルが設定され、
このようなトンネルは、本発明の原理によるＲＳＶＰを
使用して、まとめられたトラフィックのＱｏＳ要求を通
知し、各フローごとのＱｏＳ要求が満たされるようにさ
れる。
【００７０】
【発明の効果】以上述べたごとく、本発明によれば、ト
ンネルソースポイント（ＴＳＰ）とトンネルデスティネ
ーションポイント（ＴＤＰ）の間のパケットトンネルを
通じて、ＲＳＶＰの受信側主導パラダイムと整合性のあ
る方法でエンドツーエンドＲＳＶＰセッションを確立す
る新規なＲＳＶＰベースのトンネルプロトコルが実現さ
れる。特に、エンドツーエンドＲＳＶＰセッションは、
受信側指向ＲＳＶＰタイプのシグナリングを用いて、Ｔ
ＤＰがトンネルマッピングを決定するようにマッピング
される。このように、この新しいＲＳＶＰタイプのプロ
トコルは、ＲＳＶＰの受信側主導性と整合性があるた
め、既存のＲＳＶＰプロトコルを変更する必要がない。
ンネルソースポイント（ＴＳＰ）とトンネルデスティネ
ーションポイント（ＴＤＰ）の間のパケットトンネルを
通じて、ＲＳＶＰの受信側主導パラダイムと整合性のあ
る方法でエンドツーエンドＲＳＶＰセッションを確立す
る新規なＲＳＶＰベースのトンネルプロトコルが実現さ
れる。特に、エンドツーエンドＲＳＶＰセッションは、
受信側指向ＲＳＶＰタイプのシグナリングを用いて、Ｔ
ＤＰがトンネルマッピングを決定するようにマッピング
される。このように、この新しいＲＳＶＰタイプのプロ
トコルは、ＲＳＶＰの受信側主導性と整合性があるた
め、既存のＲＳＶＰプロトコルを変更する必要がない。
【図１】従来技術のエンドツーエンドＲＳＶＰメッセー
ジトランザクションの一部を示す図である。
ジトランザクションの一部を示す図である。
【図２】従来技術のエンドツーエンドＲＳＶＰメッセー
ジトランザクションの一部を示す図である。
ジトランザクションの一部を示す図である。
【図３】本発明の原理によるネットワークを示す図であ
る。
る。
【図４】本発明の原理によるエンドツーエンドＲＳＶＰ
ベースのメッセージトランザクションの一部を示す図で
ある。
ベースのメッセージトランザクションの一部を示す図で
ある。
【図５】本発明の原理による例示的な流れ図である。
【図６】ＴＳＰＥＣを含むＲＳＶＰ ＰＡＴＨメッセー
ジフォーマットの図である。
ジフォーマットの図である。
【図７】保証付きサービスのＲＳＶＰ ADSPECオブジェ
クトを示す図である。
クトを示す図である。
【図８】保証付きサービスのＲＳＶＰ ADSPECオブジェ
クトを示す図である。
クトを示す図である。
【図９】SESSIONオブジェクトおよびFLOWSPECオブジェ
クトを含むＲＳＶＰ ＲＥＳＶメッセージフォーマット
の図である。
クトを含むＲＳＶＰ ＲＥＳＶメッセージフォーマット
の図である。
【図１０】本発明の原理による例示的なTUNNEL_BINDING
オブジェクトを示す図である。
オブジェクトを示す図である。
【図１１】トンネルメッセージトランザクションの一部
を示す図である。
を示す図である。
【図１２】トンネルデスティネーションポイントの例示
的な高水準ブロック図である。
的な高水準ブロック図である。
１０ ネットワーク １５ インターネットサービスプロバイダ（ＩＳＰ） ２５ ＩＳＰ ５０ インターネット ６０ ＲＳＶＰトンネル ６５０ プロセッサ ６６０ メモリ ６６５ 通信インタフェース ６６６ パス
───────────────────────────────────────────────────── フロントページの続き (71)出願人 596077259 600 Ｍｏｕｎｔａｉｎ Ａｖｅｎｕｅ, Ｍｕｒｒａｙ Ｈｉｌｌ， Ｎｅｗ Ｊｅ ｒｓｅｙ 07974−0636Ｕ．Ｓ．Ａ. (72)発明者 ムーイ チュー チュアー アメリカ合衆国、07746 ニュージャージ ー、マールボロ、スカイラーク コート １ (72)発明者 ムーラリッドハーラン サンパス コディ ーラム アメリカ合衆国、07746 ニュージャージ ー、マールボロ、アリー ドライブ 17 (72)発明者 アンルー ヤン アメリカ合衆国、07724 ニュージャージ ー、イートンタウン、ウェッジウッド サ ークル 66
Claims (18)
- 【請求項１】 トンネルデスティネーションポイントと
して作用するパケットサーバにおいて使用される通信方
法において、 ＲＳＶＰベースのシグナリングを受信するステップと、 受信したＲＳＶＰベースのシグナリングに応答して、エ
ンドツーエンドＲＳＶＰセッションをトンネルにマッピ
ングするステップとを有することを特徴とする通信方
法。 - 【請求項２】 前記ＲＳＶＰベースのシグナリングは、
エンドツーエンドＲＳＶＰセッションの受信側によって
送信されるＲＳＶＰ ＲＥＳＶメッセージであることを
特徴とする請求項１に記載の方法。 - 【請求項３】 前記マッピングするステップは、ＲＳＶ
Ｐ ＲＥＳＶメッセージで運ばれた情報を用いてセッシ
ョンからトンネルへのマッピングを決定することを特徴
とする請求項２に記載の方法。 - 【請求項４】 前記方法は、カプセル化されたＲＳＶＰ
ＲＥＳＶメッセージをトンネルソースポイントへ送る
ステップをさらに有し、 前記カプセル化されたＲＳＶＰ ＲＥＳＶメッセージ
は、トンネルおよびマッピングされるエンドツーエンド
ＲＳＶＰセッションについてのマッピング情報を含むこ
とを特徴とする請求項１に記載の方法。 - 【請求項５】 前記マッピング情報は、前記カプセル化
されたＲＳＶＰ ＲＥＳＶメッセージに添付されたTUNN
EL_BINDINGオブジェクトにより送信されることを特徴と
する請求項４に記載の方法。 - 【請求項６】 前記マッピングするステップは、前記受
信したＲＳＶＰベースのシグナリングから抽出されるス
ラック時間値と、最小トンネル遅延値との関数として、
エンドツーエンドＲＳＶＰセッションをトンネルに割り
当てることを特徴とする請求項１に記載の方法。 - 【請求項７】 前記受信するステップの前に、受信側へ
送信されるＡＤＳＰＥＣオブジェクトで単一の遅延値を
公示するステップをさらに有することを特徴とする請求
項１に記載の方法。 - 【請求項８】 バーストサイズのような少なくとも１つ
のトンネルパラメータを調整することによって、確立さ
れたトンネルをチューニングするステップをさらに有す
ることを特徴とする請求項１に記載の方法。 - 【請求項９】 確立されたトンネルを再構成し、必要で
あれば、エンドツーエンドＲＳＶＰセッションを再割当
てすることによって、確立されたトンネルをチューニン
グするステップをさらに有することを特徴とする請求項
１に記載の方法。 - 【請求項１０】 トンネルデスティネーションポイント
として作用する通信装置において、 （ａ）ＲＳＶＰベースのシグナリングを受信し、（ｂ）
受信したＲＳＶＰベースのシグナリングに応答して、エ
ンドツーエンドＲＳＶＰセッションをトンネルにマッピ
ングするパケットサーバを有することを特徴とする通信
装置。 - 【請求項１１】 前記ＲＳＶＰベースのシグナリング
は、エンドツーエンドＲＳＶＰセッションの受信側によ
って送信されるＲＳＶＰ ＲＥＳＶメッセージであるこ
とを特徴とする請求項１０に記載の装置。 - 【請求項１２】 前記パケットサーバは、ＲＳＶＰ Ｒ
ＥＳＶメッセージで運ばれた情報を用いてセッションか
らトンネルへのマッピングを決定することを特徴とする
請求項１１に記載の装置。 - 【請求項１３】 前記パケットサーバは、カプセル化さ
れたＲＳＶＰ ＲＥＳＶメッセージをトンネルソースポ
イントへ送り、 前記カプセル化されたＲＳＶＰ ＲＥＳＶメッセージ
は、トンネルおよびマッピングされるエンドツーエンド
ＲＳＶＰセッションについてのマッピング情報を含むこ
とを特徴とする請求項１０に記載の装置。 - 【請求項１４】 前記マッピング情報は、前記カプセル
化されたＲＳＶＰＲＥＳＶメッセージに添付されたTUNN
EL_BINDINGオブジェクトにより送信されることを特徴と
する請求項１３に記載の装置。 - 【請求項１５】 前記パケットサーバは、前記受信した
ＲＳＶＰベースのシグナリングから抽出されるスラック
時間値と、最小トンネル遅延値との関数として、エンド
ツーエンドＲＳＶＰセッションをトンネルにマッピング
することを特徴とする請求項１０に記載の装置。 - 【請求項１６】 前記パケットサーバは、ＲＳＶＰベー
スのシグナリングを受信する前に、受信側へ送信される
ＡＤＳＰＥＣオブジェクトで単一の遅延値を公示するこ
とを特徴とする請求項１０に記載の装置。 - 【請求項１７】 前記パケットサーバは、バーストサイ
ズのような少なくとも１つのトンネルパラメータを調整
することによって、確立されたトンネルをチューニング
することを特徴とする請求項１０に記載の装置。 - 【請求項１８】 前記パケットサーバは、確立されたト
ンネルを再構成し、必要であれば、エンドツーエンドＲ
ＳＶＰセッションを再割当てすることによって、確立さ
れたトンネルをチューニングすることを特徴とする請求
項１０に記載の装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/259,170 US6519254B1 (en) | 1999-02-26 | 1999-02-26 | RSVP-based tunnel protocol providing integrated services |
| US09/259170 | 1999-02-26 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000253071A true JP2000253071A (ja) | 2000-09-14 |
| JP3545988B2 JP3545988B2 (ja) | 2004-07-21 |
Family
ID=22983820
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000051869A Expired - Fee Related JP3545988B2 (ja) | 1999-02-26 | 2000-02-28 | 通信方法および通信装置 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6519254B1 (ja) |
| EP (1) | EP1035688B1 (ja) |
| JP (1) | JP3545988B2 (ja) |
| KR (1) | KR20000076719A (ja) |
| DE (1) | DE60017622T2 (ja) |
| ES (1) | ES2234524T3 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6519254B1 (en) * | 1999-02-26 | 2003-02-11 | Lucent Technologies Inc. | RSVP-based tunnel protocol providing integrated services |
| JP2010088106A (ja) * | 2008-07-15 | 2010-04-15 | Intel Corp | プロトコルスタックのタイミングの管理 |
Families Citing this family (79)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9603582D0 (en) * | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
| US6760775B1 (en) * | 1999-03-05 | 2004-07-06 | At&T Corp. | System, method and apparatus for network service load and reliability management |
| US6876668B1 (en) * | 1999-05-24 | 2005-04-05 | Cisco Technology, Inc. | Apparatus and methods for dynamic bandwidth allocation |
| JP3685651B2 (ja) * | 1999-06-04 | 2005-08-24 | 沖電気工業株式会社 | 相互接続装置及びアクティブＱｏＳマッピング方法 |
| US6771661B1 (en) * | 1999-07-21 | 2004-08-03 | Cisco Technology, Inc. | Apparatus and methods for providing event-based data communications device configuration |
| JP4454072B2 (ja) * | 1999-08-03 | 2010-04-21 | 富士通株式会社 | ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 |
| EP1076441B1 (en) * | 1999-08-09 | 2009-04-15 | Alcatel Lucent | Method for transporting data, a related data transmitting element, a data receiving element and software module |
| US7532613B1 (en) * | 1999-10-14 | 2009-05-12 | Nortel Networks Limited | Establishing a communications session having a quality of service in a communications system |
| US6765927B1 (en) * | 1999-10-20 | 2004-07-20 | Alcatel | RSVP proxy service for communication network |
| US6665273B1 (en) * | 2000-01-11 | 2003-12-16 | Cisco Technology, Inc. | Dynamically adjusting multiprotocol label switching (MPLS) traffic engineering tunnel bandwidth |
| US7054938B2 (en) * | 2000-02-10 | 2006-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for network service reservations over wireless access networks |
| US6654792B1 (en) * | 2000-02-28 | 2003-11-25 | 3Com Corporation | Method and architecture for logical aggregation of multiple servers |
| DK1284091T3 (da) * | 2000-05-22 | 2012-12-17 | Ericsson Telefon Ab L M | Fremgangsmåde til en forbindelse via et kernenetværk |
| US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| US20020054405A1 (en) * | 2000-07-13 | 2002-05-09 | Duanyang Guo | Extensions to resource reservation protocol (RSVP) -traffic engineering (TE) for bi-directional optical path setup |
| US7774468B1 (en) | 2000-07-28 | 2010-08-10 | Siddhartha Nag | Network traffic admission control |
| US7013338B1 (en) * | 2000-07-28 | 2006-03-14 | Prominence Networks, Inc. | Multiplexing several individual application sessions over a pre-allocated reservation protocol session |
| US7788354B2 (en) * | 2000-07-28 | 2010-08-31 | Siddhartha Nag | End-to-end service quality in a voice over Internet Protocol (VoIP) Network |
| US7886054B1 (en) | 2000-10-11 | 2011-02-08 | Siddhartha Nag | Graphical user interface (GUI) for administering a network implementing media aggregation |
| US6920503B1 (en) * | 2000-10-28 | 2005-07-19 | Redback Networks Inc. | Tunnel interworking |
| US7123587B1 (en) * | 2000-11-22 | 2006-10-17 | Nortel Networks Limited | System, device and method for limiting tunnel traffic in an information communication network |
| US20050088977A1 (en) * | 2000-12-14 | 2005-04-28 | Nortel Networks Limited | Dynamic virtual private network (VPN) tunnel quality of service (QoS) treatment |
| US6931028B1 (en) * | 2000-12-28 | 2005-08-16 | Cisco Technology, Inc. | Scaleable RSVP signaling between VoIP dial-peers for tandem voice solutions |
| US6862628B2 (en) * | 2001-01-05 | 2005-03-01 | Microsoft Corporation | Enhancing application performance in dynamic networks |
| US7023879B1 (en) * | 2001-03-09 | 2006-04-04 | Cisco Technology, Inc. | Dynamic multi-hop ingress to egress L2TP tunnel mapping |
| US7664877B1 (en) * | 2001-03-19 | 2010-02-16 | Juniper Networks, Inc. | Methods and apparatus for using both LDP and RSVP in a communications systems |
| GB0108461D0 (en) * | 2001-04-04 | 2001-05-23 | Roke Manor Research | Automatic traffic engineering |
| JP4284009B2 (ja) * | 2001-05-18 | 2009-06-24 | 富士通株式会社 | インターネットにおける伝送帯域を確保する方法 |
| FR2825561B1 (fr) * | 2001-06-01 | 2005-04-15 | Nortel Networks Ltd | Procede de transmission de paquets ip a travers un systeme cellulaire de radiocommunication, et equipements du systeme cellulaire pour la mise en oeuvre de ce procede |
| US7339903B2 (en) | 2001-06-14 | 2008-03-04 | Qualcomm Incorporated | Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address |
| US7027400B2 (en) * | 2001-06-26 | 2006-04-11 | Flarion Technologies, Inc. | Messages and control methods for controlling resource allocation and flow admission control in a mobile communications system |
| US7474650B2 (en) * | 2001-06-26 | 2009-01-06 | Qualcomm Incorporated | Methods and apparatus for controlling resource allocation where tunneling and access link packet aggregation are used in combination |
| US8000241B2 (en) * | 2001-06-26 | 2011-08-16 | Qualcomm Incorporated | Methods and apparatus for controlling access link packet flow aggregation and resource allocation in a mobile communications system |
| FR2827727B1 (fr) * | 2001-07-23 | 2004-01-02 | 6Wind | Procede pour le fonctionnement simultane d'au moins deux tunnels sur au moins un reseau |
| ATE330393T1 (de) * | 2001-08-21 | 2006-07-15 | Ericsson Telefon Ab L M | Mehrfachsendung in paketvermittelten punkt-zu- punkt-netzwerken |
| KR20100071119A (ko) | 2001-11-02 | 2010-06-28 | 인터디지탈 테크날러지 코포레이션 | 양방향 및 역방향 자원 예약 셋업 프로토콜 |
| DE10160855A1 (de) * | 2001-12-12 | 2003-06-26 | Schumacher Umwelt Trenntech | Filterelement und Filtervorrichtung für die Cross-Flow-Filtration |
| US7356020B2 (en) * | 2002-04-08 | 2008-04-08 | Qualcomm Incorporated | Support of disparate addressing plans and dynamic HA address allocation in mobile IP |
| WO2003096588A2 (en) * | 2002-04-15 | 2003-11-20 | Flarion Technologies, Inc. | Methods and apparatus for extending mobile ip |
| AU2003221929A1 (en) * | 2002-04-15 | 2003-11-03 | Flarion Technologies, Inc. | Methods and apparatus for the utilization of multiple uplinks in reverse tunneling |
| US7623497B2 (en) * | 2002-04-15 | 2009-11-24 | Qualcomm, Incorporated | Methods and apparatus for extending mobile IP |
| US7869803B2 (en) * | 2002-10-15 | 2011-01-11 | Qualcomm Incorporated | Profile modification for roaming in a communications environment |
| US7882346B2 (en) | 2002-10-15 | 2011-02-01 | Qualcomm Incorporated | Method and apparatus for providing authentication, authorization and accounting to roaming nodes |
| WO2004057789A2 (en) * | 2002-12-18 | 2004-07-08 | Flarion Technologies, Inc. | Messages and control methods for controlling resource allocation and flow admission control in a mobile communications system |
| US7525994B2 (en) * | 2003-01-30 | 2009-04-28 | Avaya Inc. | Packet data flow identification for multiplexing |
| US7107354B2 (en) * | 2003-02-07 | 2006-09-12 | Avaya Technology Corp. | Multiplexer discovery and parameter exchange |
| US8005958B2 (en) | 2003-06-27 | 2011-08-23 | Ixia | Virtual interface |
| KR100849345B1 (ko) * | 2003-10-30 | 2008-07-29 | 삼성전자주식회사 | 고속 패킷 데이터 시스템에서의 서비스 품질 제공 방법 |
| US7613115B2 (en) * | 2003-10-31 | 2009-11-03 | International Business Machines Corporation | Minimal delay transmission of short messages |
| US7760636B1 (en) * | 2004-01-26 | 2010-07-20 | Cisco Technology, Inc. | Retransmission and flow control in a logical network tunnel |
| US7697501B2 (en) | 2004-02-06 | 2010-04-13 | Qualcomm Incorporated | Methods and apparatus for separating home agent functionality |
| US7447211B1 (en) | 2004-03-23 | 2008-11-04 | Avaya Inc. | Method and apparatus of establishing a communication channel using protected network resources |
| US7366182B2 (en) * | 2004-08-13 | 2008-04-29 | Qualcomm Incorporated | Methods and apparatus for efficient VPN server interface, address allocation, and signaling with a local addressing domain |
| US8189530B2 (en) * | 2004-08-13 | 2012-05-29 | Qualcomm Incorporated | Methods and apparatus for VPN support in mobility management |
| US7680100B1 (en) | 2004-09-30 | 2010-03-16 | Avaya Inc. | Internet protocol appliance manager |
| EP1662716A1 (en) * | 2004-11-30 | 2006-05-31 | Siemens Aktiengesellschaft | System, node and method for bandwidth allocation in a communications network |
| US7573887B2 (en) * | 2005-01-31 | 2009-08-11 | Cisco Technology, Inc. | System and method for providing RSVP reservations in a shared line environment |
| US8428074B2 (en) | 2005-04-29 | 2013-04-23 | Prom Ks Mgmt Limited Liability Company | Back-to back H.323 proxy gatekeeper |
| US7889636B2 (en) * | 2005-05-24 | 2011-02-15 | Cisco Technology, Inc. | System and method for implementing a mid-call policy in a RSVP environment |
| KR101265954B1 (ko) * | 2005-07-11 | 2013-05-23 | 더 트러스티이스 오브 콜롬비아 유니버시티 인 더 시티 오브 뉴욕 | 아이피 터널링 경로 상의 터널 시그널링을 수행하는 방법및 장치 |
| US7787414B2 (en) * | 2005-07-12 | 2010-08-31 | Cisco Technology, Inc. | Reserving network resources for a communication session |
| US7599302B2 (en) * | 2005-07-19 | 2009-10-06 | Cisco Technology, Inc. | Dynamic enforcement of MPLS-TE inter-domain policy and QoS |
| US9066344B2 (en) | 2005-09-19 | 2015-06-23 | Qualcomm Incorporated | State synchronization of access routers |
| KR101176383B1 (ko) | 2005-10-21 | 2012-08-23 | 더 트러스티이스 오브 콜롬비아 유니버시티 인 더 시티 오브 뉴욕 | 아이피 터널링 경로 상의 터널 시그널링을 수행하는 방법및 장치 |
| FR2894752B1 (fr) * | 2005-12-12 | 2008-01-11 | Alcatel Sa | Procede d'etablissement de connexion entre des portions d'une application distribuee dans des noeuds connectes a un reseau de communication a plan de controle gmpls |
| US8199642B2 (en) * | 2006-09-14 | 2012-06-12 | Cisco Technology, Inc. | Dynamically and efficiently forming hierarchical tunnels |
| US7933257B2 (en) * | 2006-09-20 | 2011-04-26 | Cisco Technology, Inc. | Using QoS tunnels for TCP latency optimization |
| US7551569B2 (en) * | 2006-10-31 | 2009-06-23 | Cisco Technology, Inc. | Efficient tunnel placement in a computer network using distributed synchronization |
| FR2920624B1 (fr) * | 2007-09-03 | 2010-03-12 | Alcatel Lucent | Procede d'etablissement d'une connexion bidirectionnelle point a multipoint |
| US8782772B2 (en) * | 2007-09-28 | 2014-07-15 | Microsoft Corporation | Multi-session secure tunnel |
| US20090112926A1 (en) * | 2007-10-25 | 2009-04-30 | Cisco Technology, Inc. | Utilizing Presence Data Associated with a Resource |
| US20090112996A1 (en) * | 2007-10-25 | 2009-04-30 | Cisco Technology, Inc. | Determining Presence Status of End User Associated with Multiple Access Terminals |
| US20090112997A1 (en) * | 2007-10-25 | 2009-04-30 | Cisco Technology, Inc. | Utilizing Presence Data Associated with Web Item |
| US8675630B2 (en) * | 2008-05-22 | 2014-03-18 | Qualcomm Incorporated | Systems and methods for multiplexing multiple connections in mobile IP network |
| US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
| US8724467B2 (en) | 2011-02-04 | 2014-05-13 | Cisco Technology, Inc. | System and method for managing congestion in a network environment |
| US8630247B2 (en) | 2011-02-15 | 2014-01-14 | Cisco Technology, Inc. | System and method for managing tracking area identity lists in a mobile network environment |
| US9198209B2 (en) * | 2012-08-21 | 2015-11-24 | Cisco Technology, Inc. | Providing integrated end-to-end architecture that includes quality of service transport for tunneled traffic |
| CN112787902B (zh) * | 2019-11-08 | 2023-11-21 | 中兴通讯股份有限公司 | 报文封装方法及装置、报文解封装方法及装置 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4119796A (en) | 1976-11-01 | 1978-10-10 | Versitron, Inc. | Automatic data synchronizer |
| US4604582A (en) | 1985-01-04 | 1986-08-05 | Lockheed Electronics Company, Inc. | Digital phase correlator |
| CA2001266C (en) | 1989-10-23 | 1996-08-06 | John Robert Long | Digital phase aligner and method for its operation |
| GB9108243D0 (en) | 1991-04-17 | 1991-06-05 | Ladha Nizar | Self synchronizing automatic correlator |
| US5577075A (en) | 1991-09-26 | 1996-11-19 | Ipc Information Systems, Inc. | Distributed clocking system |
| JPH0773598A (ja) | 1993-06-29 | 1995-03-17 | Hitachi Ltd | タイミング抽出回路とこれを用いた記録再生装置 |
| US5638410A (en) | 1993-10-14 | 1997-06-10 | Alcatel Network Systems, Inc. | Method and system for aligning the phase of high speed clocks in telecommunications systems |
| US5509037A (en) | 1993-12-01 | 1996-04-16 | Dsc Communications Corporation | Data phase alignment circuitry |
| US5673415A (en) | 1993-12-03 | 1997-09-30 | Unisys Corporation | High speed two-port interface unit where read commands suspend partially executed write commands |
| US5509038A (en) | 1994-04-06 | 1996-04-16 | Hal Computer Systems, Inc. | Multi-path data synchronizer system and method |
| US5592519A (en) | 1994-06-22 | 1997-01-07 | Alcatel Network Systems, Inc. | Dual frequency clock recovery using common multitap line |
| US5687202A (en) | 1995-04-24 | 1997-11-11 | Cyrix Corporation | Programmable phase shift clock generator |
| US5712882A (en) | 1996-01-03 | 1998-01-27 | Credence Systems Corporation | Signal distribution system |
| US5903559A (en) * | 1996-12-20 | 1999-05-11 | Nec Usa, Inc. | Method for internet protocol switching over fast ATM cell transport |
| US6937566B1 (en) * | 1997-07-25 | 2005-08-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic quality of service reservation in a mobile communications network |
| US6286052B1 (en) * | 1998-12-04 | 2001-09-04 | Cisco Technology, Inc. | Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows |
| US6182149B1 (en) * | 1999-01-11 | 2001-01-30 | 3Com Corporation | System for managing dynamic processing resources in a network |
| US6519254B1 (en) * | 1999-02-26 | 2003-02-11 | Lucent Technologies Inc. | RSVP-based tunnel protocol providing integrated services |
-
1999
- 1999-02-26 US US09/259,170 patent/US6519254B1/en not_active Expired - Lifetime
-
2000
- 2000-02-15 EP EP00301168A patent/EP1035688B1/en not_active Expired - Lifetime
- 2000-02-15 DE DE60017622T patent/DE60017622T2/de not_active Expired - Lifetime
- 2000-02-15 ES ES00301168T patent/ES2234524T3/es not_active Expired - Lifetime
- 2000-02-24 KR KR1020000008971A patent/KR20000076719A/ko not_active Application Discontinuation
- 2000-02-28 JP JP2000051869A patent/JP3545988B2/ja not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6519254B1 (en) * | 1999-02-26 | 2003-02-11 | Lucent Technologies Inc. | RSVP-based tunnel protocol providing integrated services |
| JP2010088106A (ja) * | 2008-07-15 | 2010-04-15 | Intel Corp | プロトコルスタックのタイミングの管理 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1035688A2 (en) | 2000-09-13 |
| DE60017622T2 (de) | 2006-03-23 |
| DE60017622D1 (de) | 2005-03-03 |
| ES2234524T3 (es) | 2005-07-01 |
| KR20000076719A (ko) | 2000-12-26 |
| EP1035688B1 (en) | 2005-01-26 |
| EP1035688A3 (en) | 2003-07-02 |
| JP3545988B2 (ja) | 2004-07-21 |
| US6519254B1 (en) | 2003-02-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3545988B2 (ja) | 通信方法および通信装置 | |
| JP4796157B2 (ja) | ネットワーク通信における資源配分を実施するためのシステム及び方法 | |
| US6556544B1 (en) | Method and system for provisioning network resources for dynamic multicast groups | |
| EP1401161B1 (en) | Method and network node for having Quality of service (QOS) mechanism in an internet protocol (IP) network | |
| US7801036B2 (en) | Fairness of capacity allocation for an MPLS-based VPN | |
| US7126918B2 (en) | Micro-flow management | |
| US8031603B1 (en) | Technique for reducing resources allocated to an existing reservation in a data network | |
| EP3664389B1 (en) | Resource reservation method and related apparatus | |
| US6975648B2 (en) | Network system and communication band control method thereof | |
| Terzis et al. | A prototype implementation of the two-tier architecture for differentiated services | |
| Rakocevic | Dynamic bandwidth allocation in multi-class IP networks using utility functions. | |
| Mehic et al. | Quality of service architectures of quantum key distribution networks | |
| Pan et al. | BGRP: A Tree-Based Aggregation Protocol for Inter-Domain Reservations | |
| WO2023279818A1 (zh) | 确定性流的转发方法及装置、存储介质及电子装置 | |
| Chen | A study of IPv6 labeling forwarding model supporting Diffserv | |
| Barenco et al. | An architecture of QoS services for a Core Internet Network over DTM | |
| Hunt | IP quality of service architectures | |
| EP1662716A1 (en) | System, node and method for bandwidth allocation in a communications network | |
| Chen | DiffServ operational model | |
| van der Zee et al. | Quality of Service over Specific Link Layers: state of the art report | |
| Jagadev et al. | Improvement of Bandwidth Allocation and Efficiency of Ad Hoc Networks Using Dynamic Resource Regulation Scheme | |
| Sérgio et al. | Quality of Service in IP Networks | |
| Bin-Abbas | Adaptive capacity allocation in MPLS networks | |
| Bharadwaj | Quality of Service in the Internet | |
| Smith et al. | Internet Engineering Task Force Anoop Ghanwani INTERNET DRAFT J. Wayne Pace Vijay Srinivasan (IBM) |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20031125 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040223 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040317 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040409 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080416 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110416 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130416 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130416 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140416 Year of fee payment: 10 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |