JP2000253052A - ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法 - Google Patents
ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法Info
- Publication number
- JP2000253052A JP2000253052A JP2000051866A JP2000051866A JP2000253052A JP 2000253052 A JP2000253052 A JP 2000253052A JP 2000051866 A JP2000051866 A JP 2000051866A JP 2000051866 A JP2000051866 A JP 2000051866A JP 2000253052 A JP2000253052 A JP 2000253052A
- Authority
- JP
- Japan
- Prior art keywords
- qos
- network
- session
- terminal
- message
- 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
- 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]
-
- 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]
-
- 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/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
(57)【要約】
【課題】 ＩＰ通信をサポートする異なるネットワーク
内の端末間にＱｏＳセッションを構築する方法を提供す
ること。 【解決手段】 本発明のＩＰ通信をサポートする異なる
ネットワーク内の端末間にＱｏＳセッションを構築する
方法は、複数のネットワークのうちの少なくとも１つの
ネットワーク内にそのネットワークの少なくとも１つの
端末に関連し、前記１つの端末と別のネットワーク内の
端末との間にＱｏＳセッションを構築する手段を具備す
るステップを有することを特徴とする。
内の端末間にＱｏＳセッションを構築する方法を提供す
ること。 【解決手段】 本発明のＩＰ通信をサポートする異なる
ネットワーク内の端末間にＱｏＳセッションを構築する
方法は、複数のネットワークのうちの少なくとも１つの
ネットワーク内にそのネットワークの少なくとも１つの
端末に関連し、前記１つの端末と別のネットワーク内の
端末との間にＱｏＳセッションを構築する手段を具備す
るステップを有することを特徴とする。
Description
【０００１】
【発明の属する技術分野】本発明は、インタネットプロ
トコール（Internet protocol＝ＩＰ）パケットルーテ
ィングにおけるクオリティオブサービス（quality of s
ervice＝ＱｏＳ）の要件をサポートする方法に関する。
トコール（Internet protocol＝ＩＰ）パケットルーテ
ィングにおけるクオリティオブサービス（quality of s
ervice＝ＱｏＳ）の要件をサポートする方法に関する。
【０００２】
【従来の技術】現在のＩＰ技術によりあるレベルのＱｏ
Ｓは、異なるネットワーク内の複数のホスト端末間でＩ
Ｐパケットを伝送する際維持される。通常ＱｏＳは、Ｉ
Ｐパケットから識別情報を抽出する交換機を経由するこ
とにより維持される。インタネット内で使用するよう提
案されているＱｏＳの条項は標準により規定され、Ｑｏ
Ｓの信号発信に関するＩＰ標準は、ＲＳＶＰ（Resource
Reservation Protocol・資源予約プロトコール）と称
する。
Ｓは、異なるネットワーク内の複数のホスト端末間でＩ
Ｐパケットを伝送する際維持される。通常ＱｏＳは、Ｉ
Ｐパケットから識別情報を抽出する交換機を経由するこ
とにより維持される。インタネット内で使用するよう提
案されているＱｏＳの条項は標準により規定され、Ｑｏ
Ｓの信号発信に関するＩＰ標準は、ＲＳＶＰ（Resource
Reservation Protocol・資源予約プロトコール）と称
する。
【０００３】このＲＳＶＰは、ＩＥＴＦで規定されるイ
ンテグレートサービスモデル（Integrated Services Mo
del＝ＩｎｔＳｅｒｖ）のＱｏＳのフレームワーク内で
使用される。このＩｎｔＳｅｒｖは、ある種類のトラフ
ィックに対する特別の処理を与えるよう規定され、その
トラフィックにデリバリサービスを行う複数のレベル間
でアプリケーションが選択されるようなメカニズムを提
供し、かつＯＳＩ ＲＭのレイヤー３におけるＱｏＳの
パラメータ用の信号処理技術を提供している。
ンテグレートサービスモデル（Integrated Services Mo
del＝ＩｎｔＳｅｒｖ）のＱｏＳのフレームワーク内で
使用される。このＩｎｔＳｅｒｖは、ある種類のトラフ
ィックに対する特別の処理を与えるよう規定され、その
トラフィックにデリバリサービスを行う複数のレベル間
でアプリケーションが選択されるようなメカニズムを提
供し、かつＯＳＩ ＲＭのレイヤー３におけるＱｏＳの
パラメータ用の信号処理技術を提供している。
【０００４】ＩｎｔＳｅｒｖは、２種類のサービスを定
義している。このControlled LoadClassは、ネットワー
クがロードされていないとき（最適のデリバリより良い
状態）と同様な方法でトラフィックのデリバリを提供し
ている。この補償されたＱｏＳサービスクラスは、バン
ド幅の補償と遅延限界をアプリケーション用のトラフィ
ックに分配している。ＩｎｔＳｅｒｖは、ＱｏＳがノー
ドと信号処理用プロトコールに対し、アプリケーション
とノードとの間および複数のノード間でＱｏＳ要件をや
り取りできるよう要求している。
義している。このControlled LoadClassは、ネットワー
クがロードされていないとき（最適のデリバリより良い
状態）と同様な方法でトラフィックのデリバリを提供し
ている。この補償されたＱｏＳサービスクラスは、バン
ド幅の補償と遅延限界をアプリケーション用のトラフィ
ックに分配している。ＩｎｔＳｅｒｖは、ＱｏＳがノー
ドと信号処理用プロトコールに対し、アプリケーション
とノードとの間および複数のノード間でＱｏＳ要件をや
り取りできるよう要求している。
【０００５】ＲＳＶＰは、ＩｎｔＳｅｒｖで使用される
ＱｏＳ信号処理プロトコールである。ＲＳＶＰは、受信
機に対しトラフィックの転送パスに沿って全てのルータ
ノードに対しＱｏＳ要求を与え、ソフト状態（パス／予
約状態）を維持し、その結果資源が各ルータ内で予約さ
れるようにしている。
ＱｏＳ信号処理プロトコールである。ＲＳＶＰは、受信
機に対しトラフィックの転送パスに沿って全てのルータ
ノードに対しＱｏＳ要求を与え、ソフト状態（パス／予
約状態）を維持し、その結果資源が各ルータ内で予約さ
れるようにしている。
【０００６】ＲＳＶＰ／ＩｎｔＳｅｒｖのＱｏＳが動作
できるようにフロー識別情報は、ＩＰパケットの一定場
所になければならない。ＲＳＶＰセッションは、データ
伝送する前にいわゆるパスメッセージと予約メッセージ
を交換するホスト端末により構成される。ＱｏＳが同等
レベルのホスト端末間の転送パスを制御できるようにす
るためには、各ホスト端末は必要なメッセージを構成す
る機能を有し、ＲＳＶＰセッションに対応するＱｏＳリ
クエストを認識しなければならない。
できるようにフロー識別情報は、ＩＰパケットの一定場
所になければならない。ＲＳＶＰセッションは、データ
伝送する前にいわゆるパスメッセージと予約メッセージ
を交換するホスト端末により構成される。ＱｏＳが同等
レベルのホスト端末間の転送パスを制御できるようにす
るためには、各ホスト端末は必要なメッセージを構成す
る機能を有し、ＲＳＶＰセッションに対応するＱｏＳリ
クエストを認識しなければならない。
【０００７】現在のＲＳＶＰの実行に際しての問題点
は、それらはプラットフォームとアプリケーションに対
し独立していることである。端末は、システムが特定し
たＲＳＶＰデモン（daemon）および／またはアプリケー
ションに組み込まれたＲＳＶＰＡＰＩを有している。現
在のＲＳＶＰの実行に際してのプラットフォームとアプ
リケーションの独立性により、あるオペレーティングシ
ステムにおいては、ＲＳＶＰの使用が限定され、これら
のアプリケーションではＲＳＶＰの実行が不可能とな
る。
は、それらはプラットフォームとアプリケーションに対
し独立していることである。端末は、システムが特定し
たＲＳＶＰデモン（daemon）および／またはアプリケー
ションに組み込まれたＲＳＶＰＡＰＩを有している。現
在のＲＳＶＰの実行に際してのプラットフォームとアプ
リケーションの独立性により、あるオペレーティングシ
ステムにおいては、ＲＳＶＰの使用が限定され、これら
のアプリケーションではＲＳＶＰの実行が不可能とな
る。
【０００８】
【発明が解決しようとする課題】本発明の目的は、異な
るネットワーク内の複数のホスト端末間で特定のＱｏＳ
セッションを設定するのに必要な要件を単純かつ幅広く
与えることができるような技術を提供することである。
具体的には、本発明はＩＰ通信をサポートできる異なる
ネットワーク内の複数の端末間でＱｏＳセッションを構
成する方法を提供することである。
るネットワーク内の複数のホスト端末間で特定のＱｏＳ
セッションを設定するのに必要な要件を単純かつ幅広く
与えることができるような技術を提供することである。
具体的には、本発明はＩＰ通信をサポートできる異なる
ネットワーク内の複数の端末間でＱｏＳセッションを構
成する方法を提供することである。
【０００９】
【課題を解決するための手段】本発明はの方法、請求項
１に記載した特徴を有する。本発明は、ＱｏＳセッショ
ンを構成する２つの端末間でのリクエストを用いメッセ
ージに応答するあらゆる種類のＱｏＳセッションに適用
できる。
１に記載した特徴を有する。本発明は、ＱｏＳセッショ
ンを構成する２つの端末間でのリクエストを用いメッセ
ージに応答するあらゆる種類のＱｏＳセッションに適用
できる。
【００１０】かくしてプラットフォームとアプリケーシ
ョンの両方が独立したＱｏＳセッションを構成できる。
ＱｏＳセッションを確立する専用手段を具備することに
より、現在および将来のＱｏＳ信号処理が可能なホスト
端末は、ＱｏＳセッションを設定でき、かくしてそのＱ
ｏＳの制御がそれらの通信相手に対し転送パスに亘って
可能となる。多くのＱｏＳ制御信号処理および制御メカ
ニズムで誘導される複雑かつ集約的なコンピューティン
グに対する要件およびワイアレス／モービル端末に対す
るバッテリパワーに対する依存性が回避される。
ョンの両方が独立したＱｏＳセッションを構成できる。
ＱｏＳセッションを確立する専用手段を具備することに
より、現在および将来のＱｏＳ信号処理が可能なホスト
端末は、ＱｏＳセッションを設定でき、かくしてそのＱ
ｏＳの制御がそれらの通信相手に対し転送パスに亘って
可能となる。多くのＱｏＳ制御信号処理および制御メカ
ニズムで誘導される複雑かつ集約的なコンピューティン
グに対する要件およびワイアレス／モービル端末に対す
るバッテリパワーに対する依存性が回避される。
【００１１】ＱｏＳセッションは少なくとの１つの端末
からのＱｏＳリクエストに応答して構築される。このＱ
ｏＳリクエストは、サポートされるべきＱｏＳを表す。
このＱｏＳリクエストは、サポートされるべきＱｏＳを
正確に特定する。ＱｏＳリクエストは、ＱｏＳセッショ
ンが確立されると送信されるべきデータの特性を示す。
このＱｏＳセッションは、ＲＳＶＰセッションでも良
く、パスメッセージは、ＱｏＳリクエストに応答した手
段により生成される。前記の少なくとも１つの端末は、
ＱｏＳセッションが構築されたことを示す手段から確認
信号を受信する。このＱｏＳセッションはＲＳＶＰセッ
ションで、前記手段がリザベーションメッセージ（Rese
rvation message）に応答する確認信号を生成する。
からのＱｏＳリクエストに応答して構築される。このＱ
ｏＳリクエストは、サポートされるべきＱｏＳを表す。
このＱｏＳリクエストは、サポートされるべきＱｏＳを
正確に特定する。ＱｏＳリクエストは、ＱｏＳセッショ
ンが確立されると送信されるべきデータの特性を示す。
このＱｏＳセッションは、ＲＳＶＰセッションでも良
く、パスメッセージは、ＱｏＳリクエストに応答した手
段により生成される。前記の少なくとも１つの端末は、
ＱｏＳセッションが構築されたことを示す手段から確認
信号を受信する。このＱｏＳセッションはＲＳＶＰセッ
ションで、前記手段がリザベーションメッセージ（Rese
rvation message）に応答する確認信号を生成する。
【００１２】ＱｏＳ指示信号は、ＱｏＳセッションの開
始に応答して少なくとも前記の１つの端末に対し生成さ
れる。この手段は、少なくとも１つの端末からのＱｏＳ
応答信号に応答するＱｏＳセッションの構築を完了させ
る。このＱｏＳセッションはＲＳＶＰセッションであ
り、ＱｏＳセッションの開始はパスメッセージにより指
示される。そしてＱｏＳセッションの構築は、リザベー
ションメッセージの受信により完了する。
始に応答して少なくとも前記の１つの端末に対し生成さ
れる。この手段は、少なくとも１つの端末からのＱｏＳ
応答信号に応答するＱｏＳセッションの構築を完了させ
る。このＱｏＳセッションはＲＳＶＰセッションであ
り、ＱｏＳセッションの開始はパスメッセージにより指
示される。そしてＱｏＳセッションの構築は、リザベー
ションメッセージの受信により完了する。
【００１３】本発明は、少なくとも１つの端末と別のネ
ットワーク内の端末との間でＱｏＳセッションを確立す
るために、ＩＰ通信をサポートできる少なくとも１つの
端末とこの端末に関連した手段とを有する。そしてこの
手段は、好ましくはプロキシサーバ（代理サーバ）であ
る。
ットワーク内の端末との間でＱｏＳセッションを確立す
るために、ＩＰ通信をサポートできる少なくとも１つの
端末とこの端末に関連した手段とを有する。そしてこの
手段は、好ましくはプロキシサーバ（代理サーバ）であ
る。
【００１４】
【発明の実施の形態】図１に複数のホスト端末間で、Ｑ
ｏＳをサポートする手段が本発明によりサポートされる
ネットワークの接続状態を示す。
ｏＳをサポートする手段が本発明によりサポートされる
ネットワークの接続状態を示す。
【００１５】第１ネットワーク２は複数のホスト端末４
０を有し、これらは全て第１ネットワークプロキシサー
バＦＮ ＰＳ４２に接続されている。第２ネットワーク
４もまた複数のホスト端末４４を有し、これらもまた第
２ネットワークプロキシサーバ４６に接続されている。
それぞれのネットワークのホスト端末間の通信は、複数
の相互接続を確立することにより行われる。第２ネット
ワークのホスト端末４４ａは、第２ネットワークプロキ
シサーバ４６にネットワークリンク６２を介して接続さ
れている。
０を有し、これらは全て第１ネットワークプロキシサー
バＦＮ ＰＳ４２に接続されている。第２ネットワーク
４もまた複数のホスト端末４４を有し、これらもまた第
２ネットワークプロキシサーバ４６に接続されている。
それぞれのネットワークのホスト端末間の通信は、複数
の相互接続を確立することにより行われる。第２ネット
ワークのホスト端末４４ａは、第２ネットワークプロキ
シサーバ４６にネットワークリンク６２を介して接続さ
れている。
【００１６】第１ネットワークのホスト端末４０ａは、
第１ネットワークプロキシサーバ４２にネットワークリ
ンク７２を介して接続されている。この第２ネットワー
クプロキシサーバ４６は、複数のルーティングスイッチ
１２ｂの１つにネットワークリンク６４を介して接続さ
れている。第１ネットワークプロキシサーバ４２はルー
ティングスイッチ１２ｃにネットワークリンク６８を介
して接続されている。ルーティングスイッチ１２ｂ，１
２ｃがネットワークリンク６６を介して接続されてい
る。
第１ネットワークプロキシサーバ４２にネットワークリ
ンク７２を介して接続されている。この第２ネットワー
クプロキシサーバ４６は、複数のルーティングスイッチ
１２ｂの１つにネットワークリンク６４を介して接続さ
れている。第１ネットワークプロキシサーバ４２はルー
ティングスイッチ１２ｃにネットワークリンク６８を介
して接続されている。ルーティングスイッチ１２ｂ，１
２ｃがネットワークリンク６６を介して接続されてい
る。
【００１７】特定のＱｏＳを必要とするネットワークシ
ステムにおいては、ＱｏＳセッションがＩＰパケットの
伝送が行われるように通信リンクの各端部のホスト端末
間で構築しなければならない。ＩＰパケットの一般的フ
ォーマットを図３（ａ）ないし（ｃ）に示す。ネットワ
ーク間で伝送されるＩＰデータパケットは、図３（ａ）
のＩＰデータパケット１４で示されている。このＩＰデ
ータパケットは、ＩＰヘッダ３０とＩＰペイロード２２
とを有する。
ステムにおいては、ＱｏＳセッションがＩＰパケットの
伝送が行われるように通信リンクの各端部のホスト端末
間で構築しなければならない。ＩＰパケットの一般的フ
ォーマットを図３（ａ）ないし（ｃ）に示す。ネットワ
ーク間で伝送されるＩＰデータパケットは、図３（ａ）
のＩＰデータパケット１４で示されている。このＩＰデ
ータパケットは、ＩＰヘッダ３０とＩＰペイロード２２
とを有する。
【００１８】ＩＰペイロード２２は、メッセージの情報
部分である。図２（ｂ）に示されているＩＰヘッダ３０
は、ソースアドレス１６と宛先アドレス１８とプロトコ
ールＩＤ２０とを有する。ＩＰヘッダ３０は、図３
（ｂ）に示されていない他のフィールドも含む。図３
（ｃ）において、ＩＰペイロード３２は、ソースポート
番号３４と宛先ポート番号３６とを含む。ＩＰペイロー
ド３２は、さらに別のフィールドも含む。
部分である。図２（ｂ）に示されているＩＰヘッダ３０
は、ソースアドレス１６と宛先アドレス１８とプロトコ
ールＩＤ２０とを有する。ＩＰヘッダ３０は、図３
（ｂ）に示されていない他のフィールドも含む。図３
（ｃ）において、ＩＰペイロード３２は、ソースポート
番号３４と宛先ポート番号３６とを含む。ＩＰペイロー
ド３２は、さらに別のフィールドも含む。
【００１９】ソースアドレス１６は、ＩＰデータパケッ
トが送信されてきたホスト端末（即ち、第２ネットワー
クのホスト端末４４ａ）のＩＰアドレスであり、宛先ア
ドレス１８はＩＰデータパケットがそこに送信されるホ
スト端末のアドレスである。ソースポート番号３４は、
ＩＰデータパケット１４に関連するソースホスト端末に
おけるアプリケーションで用いられるポート番号であ
る。宛先ポート番号は、ＩＰデータパケット１４が送信
される先の宛先ホスト端末のアプリケーションにより使
用されるポート番号である。
トが送信されてきたホスト端末（即ち、第２ネットワー
クのホスト端末４４ａ）のＩＰアドレスであり、宛先ア
ドレス１８はＩＰデータパケットがそこに送信されるホ
スト端末のアドレスである。ソースポート番号３４は、
ＩＰデータパケット１４に関連するソースホスト端末に
おけるアプリケーションで用いられるポート番号であ
る。宛先ポート番号は、ＩＰデータパケット１４が送信
される先の宛先ホスト端末のアプリケーションにより使
用されるポート番号である。
【００２０】他の使用例に加えて、プロトコールＩＤ２
０はソースアプリケーションから宛先アプリケーション
にＩＰパケットを送信する際にサポートされるべきＱｏ
Ｓを表すものの１つである。本明細書においては、宛先
アドレスとソースアドレスは、ＩＰデータパケットをそ
の宛先に経路指定するルーティングスイッチで用いられ
る。
０はソースアプリケーションから宛先アプリケーション
にＩＰパケットを送信する際にサポートされるべきＱｏ
Ｓを表すものの１つである。本明細書においては、宛先
アドレスとソースアドレスは、ＩＰデータパケットをそ
の宛先に経路指定するルーティングスイッチで用いられ
る。
【００２１】ルータあるいはルーティングスイッチがＱ
ｏＳをサポートする場合には、あるＱｏＳ制御条項（例
えば、ＲＳＶＰとＩｎｔＳｅｒｖ）においては、プロト
コールＩＤ２０は、必要なＱｏＳ制御を課し、フローを
区別するためにソースアドレス１６と宛先アドレス１８
とエンドアプリケーションの通信ポート番号（即ち、ソ
ースポート番号３４と宛先ポート番号３６）と共に用い
られる。
ｏＳをサポートする場合には、あるＱｏＳ制御条項（例
えば、ＲＳＶＰとＩｎｔＳｅｒｖ）においては、プロト
コールＩＤ２０は、必要なＱｏＳ制御を課し、フローを
区別するためにソースアドレス１６と宛先アドレス１８
とエンドアプリケーションの通信ポート番号（即ち、ソ
ースポート番号３４と宛先ポート番号３６）と共に用い
られる。
【００２２】中間のルータにおけるデータトラフィック
フローに課されるＱｏＳ制御は、システム独立性のもの
である。例えば、それはいわゆるＷＦＱ（Weighted Fai
r Queuing）あるいはＣＢＱ（Class Based Queuing）で
ある。これらは標準ではなく、実際のユーザのプロトコ
ールＩＤから通常独立したベンダー特有のものである。
フローに課されるＱｏＳ制御は、システム独立性のもの
である。例えば、それはいわゆるＷＦＱ（Weighted Fai
r Queuing）あるいはＣＢＱ（Class Based Queuing）で
ある。これらは標準ではなく、実際のユーザのプロトコ
ールＩＤから通常独立したベンダー特有のものである。
【００２３】ＩＥＦＴのＩｎｔＳｅｒｖ／ＲＳＶＰ標準
は、ＱｏＳ仕様とＱｏＳ制御メカニズム以外の信号処理
メカニズムを定義するために規定されている。ＩｎｔＳ
ｅｒｖ／ＲＳＶＰは、実際のＱｏＳ制御メカニズム（例
えば、ＷＦＱ，ＣＢＱ等）から独立している。ＱｏＳ制
御が行われるのに基づいた状態は、特定のＱｏＳ信号処
理プロトコール、例えば、ＲＳＶＰの手段によりデータ
伝送が行われる前に、ルーティングスイッチ内に設定さ
れる。
は、ＱｏＳ仕様とＱｏＳ制御メカニズム以外の信号処理
メカニズムを定義するために規定されている。ＩｎｔＳ
ｅｒｖ／ＲＳＶＰは、実際のＱｏＳ制御メカニズム（例
えば、ＷＦＱ，ＣＢＱ等）から独立している。ＱｏＳ制
御が行われるのに基づいた状態は、特定のＱｏＳ信号処
理プロトコール、例えば、ＲＳＶＰの手段によりデータ
伝送が行われる前に、ルーティングスイッチ内に設定さ
れる。
【００２４】以下の実施例においては、第２のネットワ
ークのホスト端末４４ａがホスト端末４０ａとの通信を
開始すると仮定する。この実施例においては、ステップ
５０において、ＱｏＳセッションを開始する第２ネット
ワークのホスト端末４４ａがＱｏＳリクエストをネット
ワークリンク６２を介して第２のプロキシサーバ４６に
送信する。
ークのホスト端末４４ａがホスト端末４０ａとの通信を
開始すると仮定する。この実施例においては、ステップ
５０において、ＱｏＳセッションを開始する第２ネット
ワークのホスト端末４４ａがＱｏＳリクエストをネット
ワークリンク６２を介して第２のプロキシサーバ４６に
送信する。
【００２５】ＱｏＳリクエストは、明示的あるいは非明
示的でも良い。ホスト端末からの明示的なＱｏＳリクエ
ストは、正確なＱｏＳ要件を規定する。かくして明示的
なＱｏＳリクエストは、特定のＱｏＳの明示的ステート
メントをサポートする機能を有するホスト端末によって
のみ提供される。ホスト端末からの非明示的なＱｏＳリ
クエストは、行われるべき伝送の特性のみを規定する。
例えば、非明示的なＱｏＳリクエストは、送信されるべ
きデータはあるビデオコーデックを用いて符号化された
ビデオデータであることを示す。そしてプロキシサーバ
が、この種のデータの指示に基づいて適宜のＱｏＳを決
定する。
示的でも良い。ホスト端末からの明示的なＱｏＳリクエ
ストは、正確なＱｏＳ要件を規定する。かくして明示的
なＱｏＳリクエストは、特定のＱｏＳの明示的ステート
メントをサポートする機能を有するホスト端末によって
のみ提供される。ホスト端末からの非明示的なＱｏＳリ
クエストは、行われるべき伝送の特性のみを規定する。
例えば、非明示的なＱｏＳリクエストは、送信されるべ
きデータはあるビデオコーデックを用いて符号化された
ビデオデータであることを示す。そしてプロキシサーバ
が、この種のデータの指示に基づいて適宜のＱｏＳを決
定する。
【００２６】このＱｏＳリクエストに応答して第２ネッ
トワークのプロキシサーバは、ステップ５２で標準のＲ
ＳＶＰパスメッセージを送信する。このパスメッセージ
は、第２ネットワークのホスト端末がルーティングスイ
ッチ１２ｂと１２ｃを介して通信しようとするホスト端
末に関連する第１ネットワークの宛先アドレス１８に通
信される。
トワークのプロキシサーバは、ステップ５２で標準のＲ
ＳＶＰパスメッセージを送信する。このパスメッセージ
は、第２ネットワークのホスト端末がルーティングスイ
ッチ１２ｂと１２ｃを介して通信しようとするホスト端
末に関連する第１ネットワークの宛先アドレス１８に通
信される。
【００２７】ＲＳＶＰセッションで用いられるメッセー
ジのＩＰパケットは図３（ａ）ないし（ｃ）に示された
フォーマットを有していない。図３（ａ）ないし（ｃ）
のＩＰパケットは、データメッセージのＩＰパケットで
ある。図４（ａ）に示されたパスメッセージ７０のＩＰ
パケットは、第２ネットワークのホスト端末４４ａのア
ドレスに対応するソースアドレス７８と、第１ネットワ
ークのホスト端末４０ａのアドレスに対応する宛先アド
レス８０（ホストターミナルホームアドレス）を有す
る。
ジのＩＰパケットは図３（ａ）ないし（ｃ）に示された
フォーマットを有していない。図３（ａ）ないし（ｃ）
のＩＰパケットは、データメッセージのＩＰパケットで
ある。図４（ａ）に示されたパスメッセージ７０のＩＰ
パケットは、第２ネットワークのホスト端末４４ａのア
ドレスに対応するソースアドレス７８と、第１ネットワ
ークのホスト端末４０ａのアドレスに対応する宛先アド
レス８０（ホストターミナルホームアドレス）を有す
る。
【００２８】パスメッセージのＩＰパケット（と他のＲ
ＳＶＰメッセージ）は、さらにＩＰパケット内のペイロ
ード内に他のフロー識別情報を含む。当業者には、この
他のフロー識別情報については公知である。
ＳＶＰメッセージ）は、さらにＩＰパケット内のペイロ
ード内に他のフロー識別情報を含む。当業者には、この
他のフロー識別情報については公知である。
【００２９】次に図２のフローチャートに戻って、この
パスメッセージは、第２ネットワークのプロキシサーバ
により送信される。図１の実施例においては、このパス
メッセージのＩＰパケットは、従来方法により（ソース
アドレスと宛先アドレスに基づいて）ルーティングスイ
ッチ１２ｂに経路指定される。
パスメッセージは、第２ネットワークのプロキシサーバ
により送信される。図１の実施例においては、このパス
メッセージのＩＰパケットは、従来方法により（ソース
アドレスと宛先アドレスに基づいて）ルーティングスイ
ッチ１２ｂに経路指定される。
【００３０】ルーティングスイッチ１２ｂ，１２ｃがＱ
ｏＳをサポートしている場合には、これらのスイッチ
は、ＩＰパスメッセージのＩＰパケットのＩＰペイロー
ド内のフロー識別情報を抽出し、このフロー識別情報を
記憶する。このフロー識別情報は、ソースアドレスと宛
先アドレスとソースポート番号と宛先ポート番号とプロ
トコールＩＤを含む。このプロトコールＩＤは、ＱｏＳ
セッションが設定された後、ソースから宛先に送信され
た全てのＩＰデータパケットに含まれる。
ｏＳをサポートしている場合には、これらのスイッチ
は、ＩＰパスメッセージのＩＰパケットのＩＰペイロー
ド内のフロー識別情報を抽出し、このフロー識別情報を
記憶する。このフロー識別情報は、ソースアドレスと宛
先アドレスとソースポート番号と宛先ポート番号とプロ
トコールＩＤを含む。このプロトコールＩＤは、ＱｏＳ
セッションが設定された後、ソースから宛先に送信され
た全てのＩＰデータパケットに含まれる。
【００３１】ルーティングスイッチ１２ｂ，１２ｃは、
パスメッセージのＩＰパケットを別のルーティングスイ
ッチに経路指定し、その後さらにＩＰパケットから抽出
されたフロー識別情報と、それがメッセージ（次のホッ
プ）に送信するルーティングスイッチのアドレスと、そ
れがメッセージを受信するルーティングスイッチのアド
レス（前のホップ）と共に記憶する。
パスメッセージのＩＰパケットを別のルーティングスイ
ッチに経路指定し、その後さらにＩＰパケットから抽出
されたフロー識別情報と、それがメッセージ（次のホッ
プ）に送信するルーティングスイッチのアドレスと、そ
れがメッセージを受信するルーティングスイッチのアド
レス（前のホップ）と共に記憶する。
【００３２】図１は、ＩＰパケットは第１ネットワーク
２にルーティングスイッチ１２ｂ，１２ｃを介して到着
するよう示されているが、実際にはＩＰパケットは、第
１ネットワークにより多くの数のルーティングスイッチ
を介して到着し、そして各ルーティングスイッチは、パ
スメッセージのＩＰパケットから抽出したフロー識別情
報を、ＩＰパケットが送信されたルーティングスイッチ
の識別子とＩＰパケットが到着するルーティングスイッ
チの識別子と共に記憶する。
２にルーティングスイッチ１２ｂ，１２ｃを介して到着
するよう示されているが、実際にはＩＰパケットは、第
１ネットワークにより多くの数のルーティングスイッチ
を介して到着し、そして各ルーティングスイッチは、パ
スメッセージのＩＰパケットから抽出したフロー識別情
報を、ＩＰパケットが送信されたルーティングスイッチ
の識別子とＩＰパケットが到着するルーティングスイッ
チの識別子と共に記憶する。
【００３３】かくしてパスメッセージのＩＣパケット
は、第２ネットワークホスト端末から第１ネットワーク
にルーティングネットワークを介して移動する。各ルー
ティングスイッチは、ＩＰパケットが送信された前のホ
ップのアドレスとＩＰパケットを受信する次のホップの
アドレスとＩＰパケットのフロー識別情報を記憶する。
ルーティングスイッチは、パスメッセージ内の他のトラ
フィック関連情報を処理するが、その特質は、本発明の
議論とは無関係であるので省略する。
は、第２ネットワークホスト端末から第１ネットワーク
にルーティングネットワークを介して移動する。各ルー
ティングスイッチは、ＩＰパケットが送信された前のホ
ップのアドレスとＩＰパケットを受信する次のホップの
アドレスとＩＰパケットのフロー識別情報を記憶する。
ルーティングスイッチは、パスメッセージ内の他のトラ
フィック関連情報を処理するが、その特質は、本発明の
議論とは無関係であるので省略する。
【００３４】ＱｏＳセッションが設定された後、別のＩ
Ｐパケットがルーティングスイッチメモリ内に記憶され
ていた同一のフロー識別情報を有する特定のルーティン
グスイッチに到着すると、このルーティングスイッチは
それを全く同一の次のホップに転送し、そのホップのア
ドレスをメモリに記憶する。データパケット用のフロー
識別情報は、図３（ａ）ないし（ｃ）に示されたＩＰデ
ータパケットのフィールドから抽出される。
Ｐパケットがルーティングスイッチメモリ内に記憶され
ていた同一のフロー識別情報を有する特定のルーティン
グスイッチに到着すると、このルーティングスイッチは
それを全く同一の次のホップに転送し、そのホップのア
ドレスをメモリに記憶する。データパケット用のフロー
識別情報は、図３（ａ）ないし（ｃ）に示されたＩＰデ
ータパケットのフィールドから抽出される。
【００３５】かくして連続するホップにおいて、各ルー
ティングスイッチ（ただし、それがＲＳＶＰのＱｏＳを
サポートするもの）は、パスメッセージのＩＰパケット
の固定位置からフロー識別情報を取り出し、それらを次
のホップと前のホップのアドレスと共にメモリに記憶す
る。かくして、ＩＰパケット内のフロー識別情報は、メ
ッセージフローを唯一に特定するのを補助し、かくして
そのメッセージフローに関連した全てのＩＰパケット
は、ソースから宛先に正確に同一のネットワークパスを
介して配送される。
ティングスイッチ（ただし、それがＲＳＶＰのＱｏＳを
サポートするもの）は、パスメッセージのＩＰパケット
の固定位置からフロー識別情報を取り出し、それらを次
のホップと前のホップのアドレスと共にメモリに記憶す
る。かくして、ＩＰパケット内のフロー識別情報は、メ
ッセージフローを唯一に特定するのを補助し、かくして
そのメッセージフローに関連した全てのＩＰパケット
は、ソースから宛先に正確に同一のネットワークパスを
介して配送される。
【００３６】第１ネットワークのプロキシサーバ４２
は、パスメッセージを受信し、ステップ５４において、
ＱｏＳ指示信号をネットワークリンク７２の上でホスト
端末４０ａに送り、第２ネットワークのホスト端末４４
ａにより要求されたＱｏＳを示す。このＱｏＳレベルが
ホスト端末４０ａにとって受け入れ可能なものである場
合には、ホスト端末４０ａはネットワークリンク７２上
にステップ５６で第１ネットワークのプロキシサーバ４
２に受領確認通知を出す方法でＱｏＳの応答を送信す
る。
は、パスメッセージを受信し、ステップ５４において、
ＱｏＳ指示信号をネットワークリンク７２の上でホスト
端末４０ａに送り、第２ネットワークのホスト端末４４
ａにより要求されたＱｏＳを示す。このＱｏＳレベルが
ホスト端末４０ａにとって受け入れ可能なものである場
合には、ホスト端末４０ａはネットワークリンク７２上
にステップ５６で第１ネットワークのプロキシサーバ４
２に受領確認通知を出す方法でＱｏＳの応答を送信す
る。
【００３７】ステップ５８においては、第１ネットワー
クのプロキシサーバは、リザベーションメッセージを第
２ネットワークのプロトコールＩＤ２０に送信し、Ｑｏ
Ｓセッションを確認する。このリサベーションメッセー
ジは、パスメッセージへの同一ルートを流れる（逆
に）。
クのプロキシサーバは、リザベーションメッセージを第
２ネットワークのプロトコールＩＤ２０に送信し、Ｑｏ
Ｓセッションを確認する。このリサベーションメッセー
ジは、パスメッセージへの同一ルートを流れる（逆
に）。
【００３８】第１ネットワークのプロキシサーバにより
戻されたリザベーションメッセージ７７の一般的フォー
マットを図４（ｂ）に示す。同図に示すように、ソース
アドレス１１５はホスト端末４０ａのアドレスで、宛先
アドレス１１７は第２ネットワークホスト端末４４ａの
アドレスで、ＲＳＶＰセッション内のパスメッセージと
リザベーションメッセージのソースアドレスと宛先アド
レスとの間の正確な関係が存在し、かくしてＲＳＶＰセ
ッションがサポートされる。
戻されたリザベーションメッセージ７７の一般的フォー
マットを図４（ｂ）に示す。同図に示すように、ソース
アドレス１１５はホスト端末４０ａのアドレスで、宛先
アドレス１１７は第２ネットワークホスト端末４４ａの
アドレスで、ＲＳＶＰセッション内のパスメッセージと
リザベーションメッセージのソースアドレスと宛先アド
レスとの間の正確な関係が存在し、かくしてＲＳＶＰセ
ッションがサポートされる。
【００３９】リザベーションメッセージ（Ｒｅｓｖ）の
ＩＰパケットが、ホップバイホップでパスメッセージの
ＩＰパケットと同一のネットワークパスを介して送信さ
れ戻される。かくしてリザベーションメッセージのＩＰ
パケットのソースアドレスと宛先アドレスは、正確に次
のホップと前のホップである。ソースアドレスと宛先ア
ドレスの値は、かくしてリザベーションメッセージがパ
スを通して転送されるに毎にダイナミックに決定され
る。
ＩＰパケットが、ホップバイホップでパスメッセージの
ＩＰパケットと同一のネットワークパスを介して送信さ
れ戻される。かくしてリザベーションメッセージのＩＰ
パケットのソースアドレスと宛先アドレスは、正確に次
のホップと前のホップである。ソースアドレスと宛先ア
ドレスの値は、かくしてリザベーションメッセージがパ
スを通して転送されるに毎にダイナミックに決定され
る。
【００４０】かくしてリザベーションメッセージ７７の
ＩＰパケットの構造は、図４（ｂ）に示す通りであり、
これはリザベーションメッセージのトランスポート層を
表す。かくして図４（ｂ）に示した構造は、リザベーシ
ョンメッセージの一般的概念を示し、これは発信された
ソースアドレスと最終的な宛先アドレスである。リザベ
ーションメッセージのこの解析は幾分人工的であるが、
本発明においては、ＲＳＶＰの原理を示す最適なものと
思われる。本明細書における例は、標準的なＲＳＶＰを
用いている。標準的なＲＳＶＰの変更は考えていないし
あるいは提案されていない。
ＩＰパケットの構造は、図４（ｂ）に示す通りであり、
これはリザベーションメッセージのトランスポート層を
表す。かくして図４（ｂ）に示した構造は、リザベーシ
ョンメッセージの一般的概念を示し、これは発信された
ソースアドレスと最終的な宛先アドレスである。リザベ
ーションメッセージのこの解析は幾分人工的であるが、
本発明においては、ＲＳＶＰの原理を示す最適なものと
思われる。本明細書における例は、標準的なＲＳＶＰを
用いている。標準的なＲＳＶＰの変更は考えていないし
あるいは提案されていない。
【００４１】リザベーションメッセージのＩＰパケット
内のフロー識別情報は、ルーティングスイッチに到着し
たＩＰパケットのような各ルーティングスイッチのメモ
リから取り出される。このルーティングスイッチは、特
定のメッセージフロー用のパス情報をそれらのメモリか
ら取り出し、このＩＰパケットを記憶されたホップ情報
に指示された前のホップに送る。かくしてリザベーショ
ンメッセージは、ライン６８，６６，６４を介してパス
メッセージへの同一のルートに従う（逆に）。
内のフロー識別情報は、ルーティングスイッチに到着し
たＩＰパケットのような各ルーティングスイッチのメモ
リから取り出される。このルーティングスイッチは、特
定のメッセージフロー用のパス情報をそれらのメモリか
ら取り出し、このＩＰパケットを記憶されたホップ情報
に指示された前のホップに送る。かくしてリザベーショ
ンメッセージは、ライン６８，６６，６４を介してパス
メッセージへの同一のルートに従う（逆に）。
【００４２】ＩＰパケット内のフロー識別情報を用いた
パスメッセージとリザベーションメッセージのルーティ
ングは、従来のＲＳＶＰと同じである。第２ネットワー
クのプロキシサーバは、リザベーションメッセージを受
信し、第２ネットワークの１４ａに受領確認通知を送る
方法によりネットワークリンク６２上にＱｏＳ確認情報
を送信し、ＱｏＳセッションが設定されたことを示す。
これは図２のステップ６０で示されている。
パスメッセージとリザベーションメッセージのルーティ
ングは、従来のＲＳＶＰと同じである。第２ネットワー
クのプロキシサーバは、リザベーションメッセージを受
信し、第２ネットワークの１４ａに受領確認通知を送る
方法によりネットワークリンク６２上にＱｏＳ確認情報
を送信し、ＱｏＳセッションが設定されたことを示す。
これは図２のステップ６０で示されている。
【００４３】ＱｏＳセッションが設定されると、ＩＰデ
ータパケット（データメッセージ内の）は、第２ネット
ワークプロキシサーバあるいは第１ネットワークプロキ
シサーバのいずれを介しては流れない。このＩＰパケッ
トは、第２ネットワークのホスト端末４４ａからホスト
端末４０ａにフロー識別情報により決定され、ＱｏＳセ
ッションが設定される間構築されたネットワークパスに
従うルーティングスイッチ１２を含むルーティングネッ
トワークを介して直接送られる（そしてその逆も行われ
る）。
ータパケット（データメッセージ内の）は、第２ネット
ワークプロキシサーバあるいは第１ネットワークプロキ
シサーバのいずれを介しては流れない。このＩＰパケッ
トは、第２ネットワークのホスト端末４４ａからホスト
端末４０ａにフロー識別情報により決定され、ＱｏＳセ
ッションが設定される間構築されたネットワークパスに
従うルーティングスイッチ１２を含むルーティングネッ
トワークを介して直接送られる（そしてその逆も行われ
る）。
【００４４】プロキシサーバは、このようなセッション
を容易にするような、それ自身では機能を有しないこれ
らの端末に対し、ＲＳＶＰパスメッセージとリザベーシ
ョンメッセージのようなＱｏＳセッションを提供する。
これらの端末は、ＱｏＳセッション機能が全くない端末
である。別の構成例としてこれらの端末は、ＱｏＳセッ
ション機能が制限された端末であり、プロキシサーバを
具備することにより、このような端末によりサポートさ
れるＱｏＳセッションが端末の機能とは独立できるよう
になる。広範なＱｏＳセッション機能を有するこれらの
端末に対しプロキシサーバを具備することにより端末は
処理タスクから開放される。
を容易にするような、それ自身では機能を有しないこれ
らの端末に対し、ＲＳＶＰパスメッセージとリザベーシ
ョンメッセージのようなＱｏＳセッションを提供する。
これらの端末は、ＱｏＳセッション機能が全くない端末
である。別の構成例としてこれらの端末は、ＱｏＳセッ
ション機能が制限された端末であり、プロキシサーバを
具備することにより、このような端末によりサポートさ
れるＱｏＳセッションが端末の機能とは独立できるよう
になる。広範なＱｏＳセッション機能を有するこれらの
端末に対しプロキシサーバを具備することにより端末は
処理タスクから開放される。
【００４５】ネットワーク内にＱｏＳを具備する必要の
ある各ホスト端末は、ネットワーク内のプロキシサーバ
の存在を認識していなければならない。即ち、ホスト端
末がプロキシサーバを発見できるプロセスがなければな
らない。これが行われるには２つの方法がある。第１の
方法は、ネットワーク内のホスト端末は、サーバソリシ
ケーティングメッセージ（server-soliciting message
＝ＳＳＭ）を放送する。ネットワ−ク内のプロキシサー
バは、サーバ応答メッセージ（server response messag
e＝ＳＲＭ）をホスト端末に送信して戻すことにより応
答する。
ある各ホスト端末は、ネットワーク内のプロキシサーバ
の存在を認識していなければならない。即ち、ホスト端
末がプロキシサーバを発見できるプロセスがなければな
らない。これが行われるには２つの方法がある。第１の
方法は、ネットワーク内のホスト端末は、サーバソリシ
ケーティングメッセージ（server-soliciting message
＝ＳＳＭ）を放送する。ネットワ−ク内のプロキシサー
バは、サーバ応答メッセージ（server response messag
e＝ＳＲＭ）をホスト端末に送信して戻すことにより応
答する。
【００４６】第２の方法は、ネットワーク内のプロキシ
サーバがクライアントリクエストメッセージ（client r
equest message＝ＣＲＱＭ）をローカルネットワークに
放送する。それに応答してホスト端末（これはプロキシ
サーバクライアントと見なされる）は、クライアント登
録メッセージ（client registration message＝ＣＲＧ
Ｍ）を送り戻す。このようにしてネットワーク内のプロ
キシサーバの存在がネットワーク内のホスト端末により
登録されるが、これはエージェント（ホームエージェン
ト，フォロインエージェント）の存在が標準の移動ＩＰ
により現在登録されるのと同じ方法で行われる。プロキ
シサーバにノードを登録する技術は、当業者に公知であ
る。
サーバがクライアントリクエストメッセージ（client r
equest message＝ＣＲＱＭ）をローカルネットワークに
放送する。それに応答してホスト端末（これはプロキシ
サーバクライアントと見なされる）は、クライアント登
録メッセージ（client registration message＝ＣＲＧ
Ｍ）を送り戻す。このようにしてネットワーク内のプロ
キシサーバの存在がネットワーク内のホスト端末により
登録されるが、これはエージェント（ホームエージェン
ト，フォロインエージェント）の存在が標準の移動ＩＰ
により現在登録されるのと同じ方法で行われる。プロキ
シサーバにノードを登録する技術は、当業者に公知であ
る。
【００４７】プロキシサーバは、１つのネットワーク内
のみに具備されるが、ホスト端末により具備されるＱｏ
Ｓセッションの設定は、１つあるいは複数のネットワー
ク内で行われる。かくして図１の実施例は、プロキシサ
ーバを含む第１ネットワークと第２ネットワークの両方
と、２つのそれぞれのプロキシサーバを用いて確立され
たＲＳＶＰセッションを示しているが、実際には２つの
プロキシサーバのうちの一方のみ（第１ネットワークプ
ロキシサーバまたは第２ネットワークプロキシサーバの
何れか）のみが具備され、プロキシ端末の１つと端末と
の間にＱｏＳセッションが確立される。ＱｏＳセッショ
ンを要求する端末の１つは、プロキシサーバを具備する
ことあるいはＱｏＳセッションに応答する端末の１つが
プロキシサーバを具備することは必ずしも必要ではな
い。
のみに具備されるが、ホスト端末により具備されるＱｏ
Ｓセッションの設定は、１つあるいは複数のネットワー
ク内で行われる。かくして図１の実施例は、プロキシサ
ーバを含む第１ネットワークと第２ネットワークの両方
と、２つのそれぞれのプロキシサーバを用いて確立され
たＲＳＶＰセッションを示しているが、実際には２つの
プロキシサーバのうちの一方のみ（第１ネットワークプ
ロキシサーバまたは第２ネットワークプロキシサーバの
何れか）のみが具備され、プロキシ端末の１つと端末と
の間にＱｏＳセッションが確立される。ＱｏＳセッショ
ンを要求する端末の１つは、プロキシサーバを具備する
ことあるいはＱｏＳセッションに応答する端末の１つが
プロキシサーバを具備することは必ずしも必要ではな
い。
【００４８】このプロキシサーバは、特定のネットワー
ク内のホスト端末の一部のみと関連している。数個のプ
ロキシサーバが異なるホスト端末をサポートするために
１つのネットワーク内に具備することもできる。
ク内のホスト端末の一部のみと関連している。数個のプ
ロキシサーバが異なるホスト端末をサポートするために
１つのネットワーク内に具備することもできる。
【００４９】このプロキシサーバは、ＩＥＴＦ ＲＦＣ
２２０５と他のＲＳＶＰ ＩｎｔＳｅｒｖ関連のＲＦＣ
と適合性を有し、現在入手可能なＲＳＶＰの実行と共に
内部動作する。プロキシサーバにより具備されるアプリ
ケ−ションとプラットフォームの独立性は、Sun Solari
s, Linux and Windows 95/NT を含む利用可能なオペレ
ーティングプラットフォーム上でライブビデオ／オーデ
ィオを含む全てのアプリケーションをサポートする。
２２０５と他のＲＳＶＰ ＩｎｔＳｅｒｖ関連のＲＦＣ
と適合性を有し、現在入手可能なＲＳＶＰの実行と共に
内部動作する。プロキシサーバにより具備されるアプリ
ケ−ションとプラットフォームの独立性は、Sun Solari
s, Linux and Windows 95/NT を含む利用可能なオペレ
ーティングプラットフォーム上でライブビデオ／オーデ
ィオを含む全てのアプリケーションをサポートする。
【００５０】ＲＳＶＰプロキシサーバにより具備される
アプリケーションとプラットフォームの独立性は、ノー
ド／端末そのもののＲＳＶＰ機能の除去に起因する。Ｒ
ＳＶＰ機能を有する端末は、ＲＳＶＰプロキシサーバと
共に動作して、アプリケーション／プラットフォームの
独立性を可能とし処理負荷を取り払うことができる。
アプリケーションとプラットフォームの独立性は、ノー
ド／端末そのもののＲＳＶＰ機能の除去に起因する。Ｒ
ＳＶＰ機能を有する端末は、ＲＳＶＰプロキシサーバと
共に動作して、アプリケーション／プラットフォームの
独立性を可能とし処理負荷を取り払うことができる。
【００５１】このプロキシサーバは、処理パワーおよび
／またはバッテリの寿命が限られているこれらの端末に
対するＲＳＶＰメッセージ処理に起因する計算負荷の問
題を解決する。このプロキシサーバは、フロントエンド
エージェントとして動作してＲＳＶＰが可能なネットワ
ークノードとＱｏＳ具備の要素と共に相互作用し、ＲＳ
ＶＰ信号処理をするために計算集約的な処理タスクを与
えることができる。
／またはバッテリの寿命が限られているこれらの端末に
対するＲＳＶＰメッセージ処理に起因する計算負荷の問
題を解決する。このプロキシサーバは、フロントエンド
エージェントとして動作してＲＳＶＰが可能なネットワ
ークノードとＱｏＳ具備の要素と共に相互作用し、ＲＳ
ＶＰ信号処理をするために計算集約的な処理タスクを与
えることができる。
【００５２】
【発明の効果】以上述べた本発明は、パスメッセージと
リザベーションメッセージを用いるＲＳＶＰ ＱｏＳセ
ッションの例を挙げて説明したが、本発明はＱｏＳセッ
ションを構築するために、２つの端末間でのリクエスト
メッセージとリプライメッセージを利用するいかなるＱ
ｏＳサービスセッションにも適用可能なものである。
リザベーションメッセージを用いるＲＳＶＰ ＱｏＳセ
ッションの例を挙げて説明したが、本発明はＱｏＳセッ
ションを構築するために、２つの端末間でのリクエスト
メッセージとリプライメッセージを利用するいかなるＱ
ｏＳサービスセッションにも適用可能なものである。
【図面の簡単な説明】
【図１】本発明によりプロキシサーバを具備したネット
ワークを設定した状態を表す図
ワークを設定した状態を表す図
【図２】図１のネットワーク内のＱｏＳセッションを設
定するための主要ステップを表すフローチャート図
定するための主要ステップを表すフローチャート図
【図３】ＩＰに従うメッセージパケットフォーマットを
表す図
表す図
【図４】（ａ） ＲＳＶＰ ＱｏＳセッションを構築す
るためのパスメッセージの一般的フォーマットを表す図 （ｂ） ＲＳＶＰ ＱｏＳセッションを構築するための
リザベーションメッセージの一般的フォーマットを表す
図
るためのパスメッセージの一般的フォーマットを表す図 （ｂ） ＲＳＶＰ ＱｏＳセッションを構築するための
リザベーションメッセージの一般的フォーマットを表す
図
２ 第１ネットワーク ４ 第２ネットワーク １２ ルーティングスイッチ １４ ＩＰデータパケット １６ ソースアドレス １８ 宛先アドレス ２０ プロトコールＩＤ ２２，３２ ＩＰペイロード ３０ ＩＰヘッダ ３４ ソースポート番号 ３６ 宛先ポート番号 ４０、４４ ホスト端末 ４２ 第１ネットワークプロキシサーバ（ＦＮ ＰＳ） ４６ 第２ネットワークプロキシサーバ（ＳＮ ＰＳ） ６２，６４，６６，６８，７２ ネットワークリンク ７０ パスメッセージ ７７ リザベーションメッセージ ７８，１１５ ソースアドレス ８０，１１７ 宛先アドレス
フロントページの続き (71)出願人 596077259 600 Ｍｏｕｎｔａｉｎ Ａｖｅｎｕｅ, Ｍｕｒｒａｙ Ｈｉｌｌ， Ｎｅｗ Ｊｅ ｒｓｅｙ 07974−0636Ｕ．Ｓ．Ａ. (72)発明者 シャアオバオ チェン グレイト ブリテン、ユナイテッド キン グダム、イーストリーズ、ゴールズボラフ クローズ 33
Claims (13)
- 【請求項１】 複数のネットワークのうちの少なくとも
１つのネットワーク内に、そのネットワークの少なくと
も１つの端末に関連し、前記１つの端末と前記別のネッ
トワーク内の端末との間にＱｏＳセッションを構築する
手段を具備するステップを有することを特徴とするＩＰ
通信をサポートする異なるネットワーク内の端末間にＱ
ｏＳセッションを構築する方法。 - 【請求項２】 前記ＱｏＳセッションは、前記少なくと
も１つの端末からＱｏＳリクエストに応答して構築され
ることを特徴とする請求項１記載の方法。 - 【請求項３】 前記ＱｏＳリクエストは、サポートされ
るべきＱｏＳを示すことを特徴とする請求項２記載の方
法。 - 【請求項４】 前記ＱｏＳリクエストは、サポートされ
るべきＱｏＳを正確に特定することを特徴とする請求項
２または３に記載の方法。 - 【請求項５】 前記ＱｏＳリクエストは、ＱｏＳセッシ
ョンが確立されると送信されるべきデータの特徴を示す
ことを特徴とする請求項２または３に記載の方法。 - 【請求項６】 前記ＱｏＳセッションは、ＲＳＶＰセッ
ションであり、パスメッセージは、ＱｏＳリクエストに
応答する手段により生成されることを特徴とする請求項
２ないし５の何れかに記載の方法。 - 【請求項７】 前記少なくとも１つの端末は、ＱｏＳセ
ッションが構築されたことを示す手段から確認信号を受
信することを特徴とする請求項２ないし６の何れかに記
載の方法。 - 【請求項８】 前記ＱｏＳセッションは、ＲＳＶＰセッ
ションであり、 前記手段は、リザベーションメッセージに応答して確認
信号を生成することを特徴とする請求項７記載の方法。 - 【請求項９】 前記ＱｏＳ指示信号は、ＱｏＳセッショ
ンの開始に応答して前記少なくとも１つの端末に対し生
成されることを特徴とする請求項１記載の方法。 - 【請求項１０】 前記手段は、前記少なくとも１つの端
末からのＱｏＳ応答信号に応じて、ＱｏＳセッションの
構築を完了することを特徴とする請求項９記載の方法。 - 【請求項１１】 前記ＱｏＳセッションは、ＲＳＶＰセ
ッションであり、 前記ＱｏＳセッションの開始は、パスメッセージにより
指示され、前記ＱｏＳセッションの構築は、リザベーシ
ョンメッセージの受領により完了することを特徴とする
請求項９記載の方法。 - 【請求項１２】 ＩＰ通信をサポートできる少なくとも
１つの端末と、請求項２ないし１１の何れかに記載の手
段とを有するネットワークにおいて、 前記少なくとも１つの端末に関連し、前記少なくとも１
つの端末と別のネットワークの端末との間にＱｏＳセッ
ションを構築することを特徴とする方法。 - 【請求項１３】 前記手段は、プロキシサーバであるこ
とを特徴とする請求項１ないし１２に記載の方法または
ネットワーク。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP99301429.9 | 1999-02-26 | ||
| EP99301429A EP1033848B1 (en) | 1999-02-26 | 1999-02-26 | Proxy server supporting IP quality of service |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000253052A true JP2000253052A (ja) | 2000-09-14 |
| JP3614744B2 JP3614744B2 (ja) | 2005-01-26 |
Family
ID=8241241
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000051866A Expired - Fee Related JP3614744B2 (ja) | 1999-02-26 | 2000-02-28 | ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法 |
Country Status (8)
| Country | Link |
|---|---|
| EP (1) | EP1033848B1 (ja) |
| JP (1) | JP3614744B2 (ja) |
| KR (1) | KR100387537B1 (ja) |
| CN (1) | CN1264978A (ja) |
| AU (1) | AU736987B2 (ja) |
| BR (1) | BR0000846A (ja) |
| CA (1) | CA2296944A1 (ja) |
| DE (1) | DE69940013D1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012175297A (ja) * | 2011-02-18 | 2012-09-10 | Nippon Telegr & Teleph Corp <Ntt> | ＱｏＳ制御システム、ＱｏＳ制御管理装置、及びＱｏＳ制御方法 |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020095400A1 (en) * | 2000-03-03 | 2002-07-18 | Johnson Scott C | Systems and methods for managing differentiated service in information management environments |
| CN1163029C (zh) * | 2001-08-03 | 2004-08-18 | 华为技术有限公司 | 数据网络用户进行数据交换的方法及其网络系统 |
| EP2129073B1 (en) * | 2003-09-02 | 2011-08-24 | Nokia Corporation | Transmission of embedded information relating to a quality of service |
| US7535484B2 (en) * | 2005-03-14 | 2009-05-19 | Sony Ericsson Mobile Communications Ab | Communication terminals that vary a video stream based on how it is displayed |
| US8159941B2 (en) * | 2008-08-28 | 2012-04-17 | Alcatel Lucent | In-band DPI media reservation modifications to RFC 3313 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6021263A (en) * | 1996-02-16 | 2000-02-01 | Lucent Technologies, Inc. | Management of ATM virtual circuits with resources reservation protocol |
| US5764645A (en) * | 1996-06-12 | 1998-06-09 | Microsoft Corporation | IP/ATM network adaptation |
| SE520563C2 (sv) * | 1997-10-22 | 2003-07-29 | Telia Ab | System och metod för resursreservering av genvägar, s.k. cut- through routing, i ATM-nät som överför IP-trafik |
-
1999
- 1999-02-26 DE DE69940013T patent/DE69940013D1/de not_active Expired - Lifetime
- 1999-02-26 EP EP99301429A patent/EP1033848B1/en not_active Expired - Lifetime
-
2000
- 2000-01-26 CA CA002296944A patent/CA2296944A1/en not_active Abandoned
- 2000-02-17 AU AU17551/00A patent/AU736987B2/en not_active Expired
- 2000-02-18 BR BR0000846-0A patent/BR0000846A/pt not_active IP Right Cessation
- 2000-02-24 KR KR10-2000-0008955A patent/KR100387537B1/ko not_active IP Right Cessation
- 2000-02-24 CN CN00102605A patent/CN1264978A/zh active Pending
- 2000-02-28 JP JP2000051866A patent/JP3614744B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012175297A (ja) * | 2011-02-18 | 2012-09-10 | Nippon Telegr & Teleph Corp <Ntt> | ＱｏＳ制御システム、ＱｏＳ制御管理装置、及びＱｏＳ制御方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2296944A1 (en) | 2000-08-26 |
| EP1033848A1 (en) | 2000-09-06 |
| DE69940013D1 (de) | 2009-01-15 |
| JP3614744B2 (ja) | 2005-01-26 |
| AU1755100A (en) | 2000-08-31 |
| EP1033848B1 (en) | 2008-12-03 |
| BR0000846A (pt) | 2000-12-19 |
| KR20010006684A (ko) | 2001-01-26 |
| CN1264978A (zh) | 2000-08-30 |
| KR100387537B1 (ko) | 2003-06-18 |
| AU736987B2 (en) | 2001-08-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3545987B2 (ja) | 通信方法及びモバイルｉｐ環境 | |
| US6765927B1 (en) | RSVP proxy service for communication network | |
| US6680943B1 (en) | Establishing bi-directional communication sessions across a communications network | |
| US7394811B2 (en) | Establishing connections across a communications network | |
| US6678264B1 (en) | Establishing connections with a pre-specified quality of service across a communication network | |
| EP1069742B1 (en) | Method and architecture to support multiple services in label switched networks | |
| JPH10150470A (ja) | ワールドワイドウェブの要求と応答における接続管理情報の転送方法 | |
| JP2003521199A (ja) | 通信ネットワークの方法、サーバ及び構成 | |
| JP3825693B2 (ja) | パケットデータ用のパケットデータ加入者コンテクストをアクチベートするための方法及びシステム | |
| JP3614744B2 (ja) | ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法 | |
| EP1047244A1 (en) | Mobile IP supporting quality of service for data sent from mobile node to correspondent node | |
| JP3710711B2 (ja) | 外部エージェントおよび複数のモバイル・ノードを備えた外部ネットワークに対するサービス品質をサポートする方法及びモバイルｉｐ環境 | |
| CN106302419B (zh) | 建立跨域会话连接的方法和装置 | |
| JP2001352347A (ja) | 通信ネットワークのためのｒｓｖｐプロキシサービス | |
| Gioacchino Cascella | Reconfigurable Application Networks through Peer Discovery and Handovers | |
| JP2001320409A (ja) | ネットワーク及びそれに用いる帯域保証方法 | |
| JPH1093627A (ja) | コネクション設定方法及びノード装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040419 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040716 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040917 |
|
| 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: 20041004 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041027 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3614744 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081112 Year of fee payment: 4 |
|
| 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: 20081112 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091112 Year of fee payment: 5 |
|
| 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: 20101112 Year of fee payment: 6 |
|
| 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: 20111112 Year of fee payment: 7 |
|
| 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: 20111112 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121112 Year of fee payment: 8 |
|
| 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: 20131112 Year of fee payment: 9 |
|
| 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 |
|
| 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 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |