JP3614744B2 - ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法 - Google Patents
ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法 Download PDFInfo
- Publication number
- JP3614744B2 JP3614744B2 JP2000051866A JP2000051866A JP3614744B2 JP 3614744 B2 JP3614744 B2 JP 3614744B2 JP 2000051866 A JP2000051866 A JP 2000051866A JP 2000051866 A JP2000051866 A JP 2000051866A JP 3614744 B2 JP3614744 B2 JP 3614744B2
- Authority
- JP
- Japan
- Prior art keywords
- qos
- network
- session
- proxy server
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 14
- 238000004891 communication Methods 0.000 title claims description 8
- 230000004044 response Effects 0.000 claims description 11
- 238000012790 confirmation Methods 0.000 claims description 7
- 238000012545 processing Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 235000008694 Humulus lupulus Nutrition 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
Images
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)
Description
【０００１】
【発明の属する技術分野】
本発明は、インタネットプロトコール（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ＝ＩＰ）パケットルーティングにおけるクオリティオブサービス（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ＝ＱｏＳ）の要件をサポートする方法に関する。
【０００２】
【従来の技術】
現在のＩＰ技術によりあるレベルのＱｏＳは、異なるネットワーク内の複数のホスト端末間でＩＰパケットを伝送する際維持される。通常ＱｏＳは、ＩＰパケットから識別情報を抽出する交換機を経由することにより維持される。インタネット内で使用するよう提案されているＱｏＳの条項は標準により規定され、ＱｏＳの信号発信に関するＩＰ標準は、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ・資源予約プロトコール）と称する。
【０００３】
このＲＳＶＰは、ＩＥＴＦで規定されるインテグレートサービスモデル（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｍｏｄｅｌ＝ＩｎｔＳｅｒｖ）のＱｏＳのフレームワーク内で使用される。このＩｎｔＳｅｒｖは、ある種類のトラフィックに対する特別の処理を与えるよう規定され、そのトラフィックにデリバリサービスを行う複数のレベル間でアプリケーションが選択されるようなメカニズムを提供し、かつＯＳＩ ＲＭのレイヤー３におけるＱｏＳのパラメータ用の信号処理技術を提供している。
【０００４】
ＩｎｔＳｅｒｖは、２種類のサービスを定義している。このＣｏｎｔｒｏｌｌｅｄ Ｌｏａｄ Ｃｌａｓｓは、ネットワークがロードされていないとき（最適のデリバリより良い状態）と同様な方法でトラフィックのデリバリを提供している。この補償されたＱｏＳサービスクラスは、バンド幅の補償と遅延限界をアプリケーション用のトラフィックに分配している。ＩｎｔＳｅｒｖは、ＱｏＳがノードと信号処理用プロトコールに対し、アプリケーションとノードとの間および複数のノード間でＱｏＳ要件をやり取りできるよう要求している。
【０００５】
ＲＳＶＰは、ＩｎｔＳｅｒｖで使用されるＱｏＳ信号処理プロトコールである。ＲＳＶＰは、受信機に対しトラフィックの転送パスに沿って全てのルータノードに対しＱｏＳ要求を与え、ソフト状態（パス／予約状態）を維持し、その結果資源が各ルータ内で予約されるようにしている。
【０００６】
ＲＳＶＰ／ＩｎｔＳｅｒｖのＱｏＳが動作できるようにフロー識別情報は、ＩＰパケットの一定場所になければならない。ＲＳＶＰセッションは、データ伝送する前にいわゆるパスメッセージと予約メッセージを交換するホスト端末により構成される。ＱｏＳが同等レベルのホスト端末間の転送パスを制御できるようにするためには、各ホスト端末は必要なメッセージを構成する機能を有し、ＲＳＶＰセッションに対応するＱｏＳリクエストを認識しなければならない。
【０００７】
現在のＲＳＶＰの実行に際しての問題点は、それらはプラットフォームとアプリケーションに対し独立していることである。端末は、システムが特定したＲＳＶＰデモン（ｄａｅｍｏｎ）および／またはアプリケーションに組み込まれたＲＳＶＰＡＰＩを有している。現在のＲＳＶＰの実行に際してのプラットフォームとアプリケーションの独立性により、あるオペレーティングシステムにおいては、ＲＳＶＰの使用が限定され、これらのアプリケーションではＲＳＶＰの実行が不可能となる。
【０００８】
【発明が解決しようとする課題】
本発明の目的は、異なるネットワーク内の複数のホスト端末間で特定のＱｏＳセッションを設定するのに必要な要件を単純かつ幅広く与えることができるような技術を提供することである。具体的には、本発明はＩＰ通信をサポートできる異なるネットワーク内の複数の端末間でＱｏＳセッションを構成する方法を提供することである。
【０００９】
【課題を解決するための手段】
本発明はの方法、請求項１に記載した特徴を有する。本発明は、ＱｏＳセッションを構成する２つの端末間でのリクエストを用いメッセージに応答するあらゆる種類のＱｏＳセッションに適用できる。
【００１０】
かくしてプラットフォームとアプリケーションの両方が独立したＱｏＳセッションを構成できる。ＱｏＳセッションを確立する専用手段を具備することにより、現在および将来のＱｏＳ信号処理が可能でないホスト端末が、ＱｏＳセッションを設定でき、かくしてそのＱｏＳの制御がそれらの通信相手に対し転送パスに亘って可能となる。多くのＱｏＳ制御信号処理および制御メカニズムで誘導される複雑かつ集約的なコンピューティングに対する要件およびワイアレス／モービル端末に対するバッテリパワーに対する依存性が回避される。
【００１１】
ＱｏＳセッションは少なくとの１つの端末からのＱｏＳリクエストに応答して構築される。このＱｏＳリクエストは、サポートされるべきＱｏＳを表す。このＱｏＳリクエストは、サポートされるべきＱｏＳを正確に特定する。ＱｏＳリクエストは、ＱｏＳセッションが確立されると送信されるべきデータの特性を示す。このＱｏＳセッションは、ＲＳＶＰセッションでも良く、パスメッセージは、ＱｏＳリクエストに応答した手段により生成される。前記の少なくとも１つの端末は、ＱｏＳセッションが構築されたことを示す手段から確認信号を受信する。このＱｏＳセッションはＲＳＶＰセッションで、前記手段がリザベーションメッセージ（Ｒｅｓｅｒｖａｔｉｏｎ ｍｅｓｓａｇｅ）に応答する確認信号を生成する。
【００１２】
ＱｏＳ指示信号は、ＱｏＳセッションの開始に応答して少なくとも前記の１つの端末に対し生成される。この手段は、少なくとも１つの端末からのＱｏＳ応答信号に応答するＱｏＳセッションの構築を完了させる。このＱｏＳセッションはＲＳＶＰセッションであり、ＱｏＳセッションの開始はパスメッセージにより指示される。そしてＱｏＳセッションの構築は、リザベーションメッセージの受信により完了する。
【００１３】
本発明は、少なくとも１つの端末と別のネットワーク内の端末との間でＱｏＳセッションを確立するために、ＩＰ通信をサポートできる少なくとも１つの端末とこの端末に関連した手段とを有する。そしてこの手段は、好ましくはプロキシサーバ（代理サーバ）である。
【００１４】
【発明の実施の形態】
図１に複数のホスト端末間で、ＱｏＳをサポートする手段が本発明によりサポートされるネットワークの接続状態を示す。
【００１５】
第１ネットワーク２は複数のホスト端末４０を有し、これらは全て第１ネットワークプロキシサーバＦＮ ＰＳ４２に接続されている。第２ネットワーク４もまた複数のホスト端末４４を有し、これらもまた第２ネットワークプロキシサーバ４６に接続されている。それぞれのネットワークのホスト端末間の通信は、複数の相互接続を確立することにより行われる。第２ネットワークのホスト端末４４ａは、第２ネットワークプロキシサーバ４６にネットワークリンク６２を介して接続されている。
【００１６】
第１ネットワークのホスト端末４０ａは、第１ネットワークプロキシサーバ４２にネットワークリンク７２を介して接続されている。この第２ネットワークプロキシサーバ４６は、複数のルーティングスイッチ１２ｂの１つにネットワークリンク６４を介して接続されている。第１ネットワークプロキシサーバ４２はルーティングスイッチ１２ｃにネットワークリンク６８を介して接続されている。ルーティングスイッチ１２ｂ，１２ｃがネットワークリンク６６を介して接続されている。
【００１７】
特定のＱｏＳを必要とするネットワークシステムにおいては、ＱｏＳセッションがＩＰパケットの伝送が行われるように通信リンクの各端部のホスト端末間で構築しなければならない。ＩＰパケットの一般的フォーマットを図３（ａ）ないし（ｃ）に示す。ネットワーク間で伝送されるＩＰデータパケットは、図３（ａ）のＩＰデータパケット１４で示されている。このＩＰデータパケットは、ＩＰヘッダ３０とＩＰペイロード２２とを有する。
【００１８】
ＩＰペイロード２２は、メッセージの情報部分である。図２（ｂ）に示されているＩＰヘッダ３０は、ソースアドレス１６と宛先アドレス１８とプロトコールＩＤ２０とを有する。ＩＰヘッダ３０は、図３（ｂ）に示されていない他のフィールドも含む。図３（ｃ）において、ＩＰペイロード３２は、ソースポート番号３４と宛先ポート番号３６とを含む。ＩＰペイロード３２は、さらに別のフィールドも含む。
【００１９】
ソースアドレス１６は、ＩＰデータパケットが送信されてきたホスト端末（即ち、第２ネットワークのホスト端末４４ａ）のＩＰアドレスであり、宛先アドレス１８はＩＰデータパケットがそこに送信されるホスト端末のアドレスである。ソースポート番号３４は、ＩＰデータパケット１４に関連するソースホスト端末におけるアプリケーションで用いられるポート番号である。宛先ポート番号は、ＩＰデータパケット１４が送信される先の宛先ホスト端末のアプリケーションにより使用されるポート番号である。
【００２０】
他の使用例に加えて、プロトコールＩＤ２０はソースアプリケーションから宛先アプリケーションにＩＰパケットを送信する際にサポートされるべきＱｏＳを表すものの１つである。本明細書においては、宛先アドレスとソースアドレスは、ＩＰデータパケットをその宛先に経路指定するルーティングスイッチで用いられる。
【００２１】
ルータあるいはルーティングスイッチがＱｏＳをサポートする場合には、あるＱｏＳ制御条項（例えば、ＲＳＶＰとＩｎｔＳｅｒｖ）においては、プロトコールＩＤ２０は、必要なＱｏＳ制御を課し、フローを区別するためにソースアドレス１６と宛先アドレス１８とエンドアプリケーションの通信ポート番号（即ち、ソースポート番号３４と宛先ポート番号３６）と共に用いられる。
【００２２】
中間のルータにおけるデータトラフィックフローに課されるＱｏＳ制御は、システム独立性のものである。例えば、それはいわゆるＷＦＱ（Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｉｎｇ）あるいはＣＢＱ（Ｃｌａｓｓ Ｂａｓｅｄ Ｑｕｅｕｉｎｇ）である。これらは標準ではなく、実際のユーザのプロトコールＩＤから通常独立したベンダー特有のものである。
【００２３】
ＩＥＦＴのＩｎｔＳｅｒｖ／ＲＳＶＰ標準は、ＱｏＳ仕様とＱｏＳ制御メカニズム以外の信号処理メカニズムを定義するために規定されている。ＩｎｔＳｅｒｖ／ＲＳＶＰは、実際のＱｏＳ制御メカニズム（例えば、ＷＦＱ，ＣＢＱ等）から独立している。ＱｏＳ制御が行われるのに基づいた状態は、特定のＱｏＳ信号処理プロトコール、例えば、ＲＳＶＰの手段によりデータ伝送が行われる前に、ルーティングスイッチ内に設定される。
【００２４】
以下の実施例においては、第２のネットワークのホスト端末４４ａがホスト端末４０ａとの通信を開始すると仮定する。この実施例においては、ステップ５０において、ＱｏＳセッションを開始する第２ネットワークのホスト端末４４ａがＱｏＳリクエストをネットワークリンク６２を介して第２のプロキシサーバ４６に送信する。
【００２５】
ＱｏＳリクエストは、明示的あるいは非明示的でも良い。ホスト端末からの明示的なＱｏＳリクエストは、正確なＱｏＳ要件を規定する。かくして明示的なＱｏＳリクエストは、特定のＱｏＳの明示的ステートメントをサポートする機能を有するホスト端末によってのみ提供される。ホスト端末からの非明示的なＱｏＳリクエストは、行われるべき伝送の特性のみを規定する。例えば、非明示的なＱｏＳリクエストは、送信されるべきデータはあるビデオコーデックを用いて符号化されたビデオデータであることを示す。そしてプロキシサーバが、この種のデータの指示に基づいて適宜のＱｏＳを決定する。
【００２６】
このＱｏＳリクエストに応答して第２ネットワークのプロキシサーバは、ステップ５２で標準のＲＳＶＰパスメッセージを送信する。このパスメッセージは、第２ネットワークのホスト端末がルーティングスイッチ１２ｂと１２ｃを介して通信しようとするホスト端末に関連する第１ネットワークの宛先アドレス１８に通信される。
【００２７】
ＲＳＶＰセッションで用いられるメッセージのＩＰパケットは図３（ａ）ないし（ｃ）に示されたフォーマットを有していない。図３（ａ）ないし（ｃ）のＩＰパケットは、データメッセージのＩＰパケットである。図４（ａ）に示されたパスメッセージ７０のＩＰパケットは、第２ネットワークのホスト端末４４ａのアドレスに対応するソースアドレス７８と、第１ネットワークのホスト端末４０ａのアドレスに対応する宛先アドレス８０（ホストターミナルホームアドレス）を有する。
【００２８】
パスメッセージのＩＰパケット（と他のＲＳＶＰメッセージ）は、さらにＩＰパケット内のペイロード内に他のフロー識別情報を含む。当業者には、この他のフロー識別情報については公知である。
【００２９】
次に図２のフローチャートに戻って、このパスメッセージは、第２ネットワークのプロキシサーバにより送信される。図１の実施例においては、このパスメッセージのＩＰパケットは、従来方法により（ソースアドレスと宛先アドレスに基づいて）ルーティングスイッチ１２ｂに経路指定される。
【００３０】
ルーティングスイッチ１２ｂ，１２ｃがＱｏＳをサポートしている場合には、これらのスイッチは、ＩＰパスメッセージのＩＰパケットのＩＰペイロード内のフロー識別情報を抽出し、このフロー識別情報を記憶する。このフロー識別情報は、ソースアドレスと宛先アドレスとソースポート番号と宛先ポート番号とプロトコールＩＤを含む。このプロトコールＩＤは、ＱｏＳセッションが設定された後、ソースから宛先に送信された全てのＩＰデータパケットに含まれる。
【００３１】
ルーティングスイッチ１２ｂ，１２ｃは、パスメッセージのＩＰパケットを別のルーティングスイッチに経路指定し、その後さらにＩＰパケットから抽出されたフロー識別情報と、それがメッセージ（次のホップ）に送信するルーティングスイッチのアドレスと、それがメッセージを受信するルーティングスイッチのアドレス（前のホップ）と共に記憶する。
【００３２】
図１は、ＩＰパケットは第１ネットワーク２にルーティングスイッチ１２ｂ，１２ｃを介して到着するよう示されているが、実際にはＩＰパケットは、第１ネットワークにより多くの数のルーティングスイッチを介して到着し、そして各ルーティングスイッチは、パスメッセージのＩＰパケットから抽出したフロー識別情報を、ＩＰパケットが送信されたルーティングスイッチの識別子とＩＰパケットが到着するルーティングスイッチの識別子と共に記憶する。
【００３３】
かくしてパスメッセージのＩＣパケットは、第２ネットワークホスト端末から第１ネットワークにルーティングネットワークを介して移動する。各ルーティングスイッチは、ＩＰパケットが送信された前のホップのアドレスとＩＰパケットを受信する次のホップのアドレスとＩＰパケットのフロー識別情報を記憶する。ルーティングスイッチは、パスメッセージ内の他のトラフィック関連情報を処理するが、その特質は、本発明の議論とは無関係であるので省略する。
【００３４】
ＱｏＳセッションが設定された後、別のＩＰパケットがルーティングスイッチメモリ内に記憶されていた同一のフロー識別情報を有する特定のルーティングスイッチに到着すると、このルーティングスイッチはそれを全く同一の次のホップに転送し、そのホップのアドレスをメモリに記憶する。データパケット用のフロー識別情報は、図３（ａ）ないし（ｃ）に示されたＩＰデータパケットのフィールドから抽出される。
【００３５】
かくして連続するホップにおいて、各ルーティングスイッチ（ただし、それがＲＳＶＰのＱｏＳをサポートするもの）は、パスメッセージのＩＰパケットの固定位置からフロー識別情報を取り出し、それらを次のホップと前のホップのアドレスと共にメモリに記憶する。かくして、ＩＰパケット内のフロー識別情報は、メッセージフローを唯一に特定するのを補助し、かくしてそのメッセージフローに関連した全てのＩＰパケットは、ソースから宛先に正確に同一のネットワークパスを介して配送される。
【００３６】
第１ネットワークのプロキシサーバ４２は、パスメッセージを受信し、ステップ５４において、ＱｏＳ指示信号をネットワークリンク７２の上でホスト端末４０ａに送り、第２ネットワークのホスト端末４４ａにより要求されたＱｏＳを示す。このＱｏＳレベルがホスト端末４０ａにとって受け入れ可能なものである場合には、ホスト端末４０ａはネットワークリンク７２上にステップ５６で第１ネットワークのプロキシサーバ４２に受領確認通知を出す方法でＱｏＳの応答を送信する。
【００３７】
ステップ５８においては、第１ネットワークのプロキシサーバは、リザベーションメッセージを第２ネットワークのプロトコールＩＤ２０に送信し、ＱｏＳセッションを確認する。このリサベーションメッセージは、パスメッセージへの同一ルートを流れる（逆に）。
【００３８】
第１ネットワークのプロキシサーバにより戻されたリザベーションメッセージ７７の一般的フォーマットを図４（ｂ）に示す。同図に示すように、ソースアドレス１１５はホスト端末４０ａのアドレスで、宛先アドレス１１７は第２ネットワークホスト端末４４ａのアドレスで、ＲＳＶＰセッション内のパスメッセージとリザベーションメッセージのソースアドレスと宛先アドレスとの間の正確な関係が存在し、かくしてＲＳＶＰセッションがサポートされる。
【００３９】
リザベーションメッセージ（Ｒｅｓｖ）のＩＰパケットが、ホップバイホップでパスメッセージのＩＰパケットと同一のネットワークパスを介して送信され戻される。かくしてリザベーションメッセージのＩＰパケットのソースアドレスと宛先アドレスは、正確に次のホップと前のホップである。ソースアドレスと宛先アドレスの値は、かくしてリザベーションメッセージがパスを通して転送されるに毎にダイナミックに決定される。
【００４０】
かくしてリザベーションメッセージ７７のＩＰパケットの構造は、図４（ｂ）に示す通りであり、これはリザベーションメッセージのトランスポート層を表す。かくして図４（ｂ）に示した構造は、リザベーションメッセージの一般的概念を示し、これは発信されたソースアドレスと最終的な宛先アドレスである。リザベーションメッセージのこの解析は幾分人工的であるが、本発明においては、ＲＳＶＰの原理を示す最適なものと思われる。本明細書における例は、標準的なＲＳＶＰを用いている。標準的なＲＳＶＰの変更は考えていないしあるいは提案されていない。
【００４１】
リザベーションメッセージのＩＰパケット内のフロー識別情報は、ルーティングスイッチに到着したＩＰパケットのような各ルーティングスイッチのメモリから取り出される。このルーティングスイッチは、特定のメッセージフロー用のパス情報をそれらのメモリから取り出し、このＩＰパケットを記憶されたホップ情報に指示された前のホップに送る。かくしてリザベーションメッセージは、ライン６８，６６，６４を介してパスメッセージへの同一のルートに従う（逆に）。
【００４２】
ＩＰパケット内のフロー識別情報を用いたパスメッセージとリザベーションメッセージのルーティングは、従来のＲＳＶＰと同じである。第２ネットワークのプロキシサーバは、リザベーションメッセージを受信し、第２ネットワークの１４ａに受領確認通知を送る方法によりネットワークリンク６２上にＱｏＳ確認情報を送信し、ＱｏＳセッションが設定されたことを示す。これは図２のステップ６０で示されている。
【００４３】
ＱｏＳセッションが設定されると、ＩＰデータパケット（データメッセージ内の）は、第２ネットワークプロキシサーバあるいは第１ネットワークプロキシサーバのいずれを介しては流れない。このＩＰパケットは、第２ネットワークのホスト端末４４ａからホスト端末４０ａにフロー識別情報により決定され、ＱｏＳセッションが設定される間構築されたネットワークパスに従うルーティングスイッチ１２を含むルーティングネットワークを介して直接送られる（そしてその逆も行われる）。
【００４４】
プロキシサーバは、このようなセッションを容易にするような、それ自身では機能を有しないこれらの端末に対し、ＲＳＶＰパスメッセージとリザベーションメッセージのようなＱｏＳセッションを提供する。これらの端末は、ＱｏＳセッション機能が全くない端末である。別の構成例としてこれらの端末は、ＱｏＳセッション機能が制限された端末であり、プロキシサーバを具備することにより、このような端末によりサポートされるＱｏＳセッションが端末の機能とは独立できるようになる。広範なＱｏＳセッション機能を有するこれらの端末に対しプロキシサーバを具備することにより端末は処理タスクから開放される。
【００４５】
ネットワーク内にＱｏＳを具備する必要のある各ホスト端末は、ネットワーク内のプロキシサーバの存在を認識していなければならない。即ち、ホスト端末がプロキシサーバを発見できるプロセスがなければならない。これが行われるには２つの方法がある。第１の方法は、ネットワーク内のホスト端末は、サーバソリシケーティングメッセージ（ｓｅｒｖｅｒ−ｓｏｌｉｃｉｔｉｎｇ ｍｅｓｓａｇｅ＝ＳＳＭ）を放送する。ネットワ−ク内のプロキシサーバは、サーバ応答メッセージ（ｓｅｒｖｅｒ ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ＝ＳＲＭ）をホスト端末に送信して戻すことにより応答する。
【００４６】
第２の方法は、ネットワーク内のプロキシサーバがクライアントリクエストメッセージ（ｃｌｉｅｎｔ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ＝ＣＲＱＭ）をローカルネットワークに放送する。それに応答してホスト端末（これはプロキシサーバクライアントと見なされる）は、クライアント登録メッセージ（ｃｌｉｅｎｔ ｒｅｇｉｓｔｒａｔｉｏｎ ｍｅｓｓａｇｅ＝ＣＲＧＭ）を送り戻す。このようにしてネットワーク内のプロキシサーバの存在がネットワーク内のホスト端末により登録されるが、これはエージェント（ホームエージェント，フォロインエージェント）の存在が標準の移動ＩＰにより現在登録されるのと同じ方法で行われる。プロキシサーバにノードを登録する技術は、当業者に公知である。
【００４７】
プロキシサーバは、１つのネットワーク内のみに具備されるが、ホスト端末により具備されるＱｏＳセッションの設定は、１つあるいは複数のネットワーク内で行われる。かくして図１の実施例は、プロキシサーバを含む第１ネットワークと第２ネットワークの両方と、２つのそれぞれのプロキシサーバを用いて確立されたＲＳＶＰセッションを示しているが、実際には２つのプロキシサーバのうちの一方のみ（第１ネットワークプロキシサーバまたは第２ネットワークプロキシサーバの何れか）のみが具備され、プロキシ端末の１つと端末との間にＱｏＳセッションが確立される。ＱｏＳセッションを要求する端末の１つは、プロキシサーバを具備することあるいはＱｏＳセッションに応答する端末の１つがプロキシサーバを具備することは必ずしも必要ではない。
【００４８】
このプロキシサーバは、特定のネットワーク内のホスト端末の一部のみと関連している。数個のプロキシサーバが異なるホスト端末をサポートするために１つのネットワーク内に具備することもできる。
【００４９】
このプロキシサーバは、ＩＥＴＦ ＲＦＣ ２２０５と他のＲＳＶＰ ＩｎｔＳｅｒｖ関連のＲＦＣと適合性を有し、現在入手可能なＲＳＶＰの実行と共に内部動作する。プロキシサーバにより具備されるアプリケ−ションとプラットフォームの独立性は、Ｓｕｎ Ｓｏｌａｒｉｓ， Ｌｉｎｕｘ ａｎｄ Ｗｉｎｄｏｗｓ ９５／ＮＴ を含む利用可能なオペレーティングプラットフォーム上でライブビデオ／オーディオを含む全てのアプリケーションをサポートする。
【００５０】
ＲＳＶＰプロキシサーバにより具備されるアプリケーションとプラットフォームの独立性は、ノード／端末そのもののＲＳＶＰ機能の除去に起因する。ＲＳＶＰ機能を有する端末は、ＲＳＶＰプロキシサーバと共に動作して、アプリケーション／プラットフォームの独立性を可能とし処理負荷を取り払うことができる。
【００５１】
このプロキシサーバは、処理パワーおよび／またはバッテリの寿命が限られているこれらの端末に対するＲＳＶＰメッセージ処理に起因する計算負荷の問題を解決する。このプロキシサーバは、フロントエンドエージェントとして動作してＲＳＶＰが可能なネットワークノードとＱｏＳ具備の要素と共に相互作用し、ＲＳＶＰ信号処理をするために計算集約的な処理タスクを与えることができる。
【００５２】
【発明の効果】
以上述べた本発明は、パスメッセージとリザベーションメッセージを用いるＲＳＶＰ ＱｏＳセッションの例を挙げて説明したが、本発明はＱｏＳセッションを構築するために、２つの端末間でのリクエストメッセージとリプライメッセージを利用するいかなるＱｏＳサービスセッションにも適用可能なものである。
【図面の簡単な説明】
【図１】本発明によりプロキシサーバを具備したネットワークを設定した状態を表す図
【図２】図１のネットワーク内のＱｏＳセッションを設定するための主要ステップを表すフローチャート図
【図３】ＩＰに従うメッセージパケットフォーマットを表す図
【図４】（ａ） ＲＳＶＰ ＱｏＳセッションを構築するためのパスメッセージの一般的フォーマットを表す図
（ｂ） ＲＳＶＰ ＱｏＳセッションを構築するためのリザベーションメッセージの一般的フォーマットを表す図
【符号の説明】
２ 第１ネットワーク
４ 第２ネットワーク
１２ ルーティングスイッチ
１４ ＩＰデータパケット
１６ ソースアドレス
１８ 宛先アドレス
２０ プロトコールＩＤ
２２，３２ ＩＰペイロード
３０ ＩＰヘッダ
３４ ソースポート番号
３６ 宛先ポート番号
４０、４４ ホスト端末
４２ 第１ネットワークプロキシサーバ（ＦＮ ＰＳ）
４６ 第２ネットワークプロキシサーバ（ＳＮ ＰＳ）
６２，６４，６６，６８，７２ ネットワークリンク
７０ パスメッセージ
７７ リザベーションメッセージ
７８，１１５ ソースアドレス
８０，１１７ 宛先アドレス
【発明の属する技術分野】
本発明は、インタネットプロトコール（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ＝ＩＰ）パケットルーティングにおけるクオリティオブサービス（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ＝ＱｏＳ）の要件をサポートする方法に関する。
【０００２】
【従来の技術】
現在のＩＰ技術によりあるレベルのＱｏＳは、異なるネットワーク内の複数のホスト端末間でＩＰパケットを伝送する際維持される。通常ＱｏＳは、ＩＰパケットから識別情報を抽出する交換機を経由することにより維持される。インタネット内で使用するよう提案されているＱｏＳの条項は標準により規定され、ＱｏＳの信号発信に関するＩＰ標準は、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ・資源予約プロトコール）と称する。
【０００３】
このＲＳＶＰは、ＩＥＴＦで規定されるインテグレートサービスモデル（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｍｏｄｅｌ＝ＩｎｔＳｅｒｖ）のＱｏＳのフレームワーク内で使用される。このＩｎｔＳｅｒｖは、ある種類のトラフィックに対する特別の処理を与えるよう規定され、そのトラフィックにデリバリサービスを行う複数のレベル間でアプリケーションが選択されるようなメカニズムを提供し、かつＯＳＩ ＲＭのレイヤー３におけるＱｏＳのパラメータ用の信号処理技術を提供している。
【０００４】
ＩｎｔＳｅｒｖは、２種類のサービスを定義している。このＣｏｎｔｒｏｌｌｅｄ Ｌｏａｄ Ｃｌａｓｓは、ネットワークがロードされていないとき（最適のデリバリより良い状態）と同様な方法でトラフィックのデリバリを提供している。この補償されたＱｏＳサービスクラスは、バンド幅の補償と遅延限界をアプリケーション用のトラフィックに分配している。ＩｎｔＳｅｒｖは、ＱｏＳがノードと信号処理用プロトコールに対し、アプリケーションとノードとの間および複数のノード間でＱｏＳ要件をやり取りできるよう要求している。
【０００５】
ＲＳＶＰは、ＩｎｔＳｅｒｖで使用されるＱｏＳ信号処理プロトコールである。ＲＳＶＰは、受信機に対しトラフィックの転送パスに沿って全てのルータノードに対しＱｏＳ要求を与え、ソフト状態（パス／予約状態）を維持し、その結果資源が各ルータ内で予約されるようにしている。
【０００６】
ＲＳＶＰ／ＩｎｔＳｅｒｖのＱｏＳが動作できるようにフロー識別情報は、ＩＰパケットの一定場所になければならない。ＲＳＶＰセッションは、データ伝送する前にいわゆるパスメッセージと予約メッセージを交換するホスト端末により構成される。ＱｏＳが同等レベルのホスト端末間の転送パスを制御できるようにするためには、各ホスト端末は必要なメッセージを構成する機能を有し、ＲＳＶＰセッションに対応するＱｏＳリクエストを認識しなければならない。
【０００７】
現在のＲＳＶＰの実行に際しての問題点は、それらはプラットフォームとアプリケーションに対し独立していることである。端末は、システムが特定したＲＳＶＰデモン（ｄａｅｍｏｎ）および／またはアプリケーションに組み込まれたＲＳＶＰＡＰＩを有している。現在のＲＳＶＰの実行に際してのプラットフォームとアプリケーションの独立性により、あるオペレーティングシステムにおいては、ＲＳＶＰの使用が限定され、これらのアプリケーションではＲＳＶＰの実行が不可能となる。
【０００８】
【発明が解決しようとする課題】
本発明の目的は、異なるネットワーク内の複数のホスト端末間で特定のＱｏＳセッションを設定するのに必要な要件を単純かつ幅広く与えることができるような技術を提供することである。具体的には、本発明はＩＰ通信をサポートできる異なるネットワーク内の複数の端末間でＱｏＳセッションを構成する方法を提供することである。
【０００９】
【課題を解決するための手段】
本発明はの方法、請求項１に記載した特徴を有する。本発明は、ＱｏＳセッションを構成する２つの端末間でのリクエストを用いメッセージに応答するあらゆる種類のＱｏＳセッションに適用できる。
【００１０】
かくしてプラットフォームとアプリケーションの両方が独立したＱｏＳセッションを構成できる。ＱｏＳセッションを確立する専用手段を具備することにより、現在および将来のＱｏＳ信号処理が可能でないホスト端末が、ＱｏＳセッションを設定でき、かくしてそのＱｏＳの制御がそれらの通信相手に対し転送パスに亘って可能となる。多くのＱｏＳ制御信号処理および制御メカニズムで誘導される複雑かつ集約的なコンピューティングに対する要件およびワイアレス／モービル端末に対するバッテリパワーに対する依存性が回避される。
【００１１】
ＱｏＳセッションは少なくとの１つの端末からのＱｏＳリクエストに応答して構築される。このＱｏＳリクエストは、サポートされるべきＱｏＳを表す。このＱｏＳリクエストは、サポートされるべきＱｏＳを正確に特定する。ＱｏＳリクエストは、ＱｏＳセッションが確立されると送信されるべきデータの特性を示す。このＱｏＳセッションは、ＲＳＶＰセッションでも良く、パスメッセージは、ＱｏＳリクエストに応答した手段により生成される。前記の少なくとも１つの端末は、ＱｏＳセッションが構築されたことを示す手段から確認信号を受信する。このＱｏＳセッションはＲＳＶＰセッションで、前記手段がリザベーションメッセージ（Ｒｅｓｅｒｖａｔｉｏｎ ｍｅｓｓａｇｅ）に応答する確認信号を生成する。
【００１２】
ＱｏＳ指示信号は、ＱｏＳセッションの開始に応答して少なくとも前記の１つの端末に対し生成される。この手段は、少なくとも１つの端末からのＱｏＳ応答信号に応答するＱｏＳセッションの構築を完了させる。このＱｏＳセッションはＲＳＶＰセッションであり、ＱｏＳセッションの開始はパスメッセージにより指示される。そしてＱｏＳセッションの構築は、リザベーションメッセージの受信により完了する。
【００１３】
本発明は、少なくとも１つの端末と別のネットワーク内の端末との間でＱｏＳセッションを確立するために、ＩＰ通信をサポートできる少なくとも１つの端末とこの端末に関連した手段とを有する。そしてこの手段は、好ましくはプロキシサーバ（代理サーバ）である。
【００１４】
【発明の実施の形態】
図１に複数のホスト端末間で、ＱｏＳをサポートする手段が本発明によりサポートされるネットワークの接続状態を示す。
【００１５】
第１ネットワーク２は複数のホスト端末４０を有し、これらは全て第１ネットワークプロキシサーバＦＮ ＰＳ４２に接続されている。第２ネットワーク４もまた複数のホスト端末４４を有し、これらもまた第２ネットワークプロキシサーバ４６に接続されている。それぞれのネットワークのホスト端末間の通信は、複数の相互接続を確立することにより行われる。第２ネットワークのホスト端末４４ａは、第２ネットワークプロキシサーバ４６にネットワークリンク６２を介して接続されている。
【００１６】
第１ネットワークのホスト端末４０ａは、第１ネットワークプロキシサーバ４２にネットワークリンク７２を介して接続されている。この第２ネットワークプロキシサーバ４６は、複数のルーティングスイッチ１２ｂの１つにネットワークリンク６４を介して接続されている。第１ネットワークプロキシサーバ４２はルーティングスイッチ１２ｃにネットワークリンク６８を介して接続されている。ルーティングスイッチ１２ｂ，１２ｃがネットワークリンク６６を介して接続されている。
【００１７】
特定のＱｏＳを必要とするネットワークシステムにおいては、ＱｏＳセッションがＩＰパケットの伝送が行われるように通信リンクの各端部のホスト端末間で構築しなければならない。ＩＰパケットの一般的フォーマットを図３（ａ）ないし（ｃ）に示す。ネットワーク間で伝送されるＩＰデータパケットは、図３（ａ）のＩＰデータパケット１４で示されている。このＩＰデータパケットは、ＩＰヘッダ３０とＩＰペイロード２２とを有する。
【００１８】
ＩＰペイロード２２は、メッセージの情報部分である。図２（ｂ）に示されているＩＰヘッダ３０は、ソースアドレス１６と宛先アドレス１８とプロトコールＩＤ２０とを有する。ＩＰヘッダ３０は、図３（ｂ）に示されていない他のフィールドも含む。図３（ｃ）において、ＩＰペイロード３２は、ソースポート番号３４と宛先ポート番号３６とを含む。ＩＰペイロード３２は、さらに別のフィールドも含む。
【００１９】
ソースアドレス１６は、ＩＰデータパケットが送信されてきたホスト端末（即ち、第２ネットワークのホスト端末４４ａ）のＩＰアドレスであり、宛先アドレス１８はＩＰデータパケットがそこに送信されるホスト端末のアドレスである。ソースポート番号３４は、ＩＰデータパケット１４に関連するソースホスト端末におけるアプリケーションで用いられるポート番号である。宛先ポート番号は、ＩＰデータパケット１４が送信される先の宛先ホスト端末のアプリケーションにより使用されるポート番号である。
【００２０】
他の使用例に加えて、プロトコールＩＤ２０はソースアプリケーションから宛先アプリケーションにＩＰパケットを送信する際にサポートされるべきＱｏＳを表すものの１つである。本明細書においては、宛先アドレスとソースアドレスは、ＩＰデータパケットをその宛先に経路指定するルーティングスイッチで用いられる。
【００２１】
ルータあるいはルーティングスイッチがＱｏＳをサポートする場合には、あるＱｏＳ制御条項（例えば、ＲＳＶＰとＩｎｔＳｅｒｖ）においては、プロトコールＩＤ２０は、必要なＱｏＳ制御を課し、フローを区別するためにソースアドレス１６と宛先アドレス１８とエンドアプリケーションの通信ポート番号（即ち、ソースポート番号３４と宛先ポート番号３６）と共に用いられる。
【００２２】
中間のルータにおけるデータトラフィックフローに課されるＱｏＳ制御は、システム独立性のものである。例えば、それはいわゆるＷＦＱ（Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｉｎｇ）あるいはＣＢＱ（Ｃｌａｓｓ Ｂａｓｅｄ Ｑｕｅｕｉｎｇ）である。これらは標準ではなく、実際のユーザのプロトコールＩＤから通常独立したベンダー特有のものである。
【００２３】
ＩＥＦＴのＩｎｔＳｅｒｖ／ＲＳＶＰ標準は、ＱｏＳ仕様とＱｏＳ制御メカニズム以外の信号処理メカニズムを定義するために規定されている。ＩｎｔＳｅｒｖ／ＲＳＶＰは、実際のＱｏＳ制御メカニズム（例えば、ＷＦＱ，ＣＢＱ等）から独立している。ＱｏＳ制御が行われるのに基づいた状態は、特定のＱｏＳ信号処理プロトコール、例えば、ＲＳＶＰの手段によりデータ伝送が行われる前に、ルーティングスイッチ内に設定される。
【００２４】
以下の実施例においては、第２のネットワークのホスト端末４４ａがホスト端末４０ａとの通信を開始すると仮定する。この実施例においては、ステップ５０において、ＱｏＳセッションを開始する第２ネットワークのホスト端末４４ａがＱｏＳリクエストをネットワークリンク６２を介して第２のプロキシサーバ４６に送信する。
【００２５】
ＱｏＳリクエストは、明示的あるいは非明示的でも良い。ホスト端末からの明示的なＱｏＳリクエストは、正確なＱｏＳ要件を規定する。かくして明示的なＱｏＳリクエストは、特定のＱｏＳの明示的ステートメントをサポートする機能を有するホスト端末によってのみ提供される。ホスト端末からの非明示的なＱｏＳリクエストは、行われるべき伝送の特性のみを規定する。例えば、非明示的なＱｏＳリクエストは、送信されるべきデータはあるビデオコーデックを用いて符号化されたビデオデータであることを示す。そしてプロキシサーバが、この種のデータの指示に基づいて適宜のＱｏＳを決定する。
【００２６】
このＱｏＳリクエストに応答して第２ネットワークのプロキシサーバは、ステップ５２で標準のＲＳＶＰパスメッセージを送信する。このパスメッセージは、第２ネットワークのホスト端末がルーティングスイッチ１２ｂと１２ｃを介して通信しようとするホスト端末に関連する第１ネットワークの宛先アドレス１８に通信される。
【００２７】
ＲＳＶＰセッションで用いられるメッセージのＩＰパケットは図３（ａ）ないし（ｃ）に示されたフォーマットを有していない。図３（ａ）ないし（ｃ）のＩＰパケットは、データメッセージのＩＰパケットである。図４（ａ）に示されたパスメッセージ７０のＩＰパケットは、第２ネットワークのホスト端末４４ａのアドレスに対応するソースアドレス７８と、第１ネットワークのホスト端末４０ａのアドレスに対応する宛先アドレス８０（ホストターミナルホームアドレス）を有する。
【００２８】
パスメッセージのＩＰパケット（と他のＲＳＶＰメッセージ）は、さらにＩＰパケット内のペイロード内に他のフロー識別情報を含む。当業者には、この他のフロー識別情報については公知である。
【００２９】
次に図２のフローチャートに戻って、このパスメッセージは、第２ネットワークのプロキシサーバにより送信される。図１の実施例においては、このパスメッセージのＩＰパケットは、従来方法により（ソースアドレスと宛先アドレスに基づいて）ルーティングスイッチ１２ｂに経路指定される。
【００３０】
ルーティングスイッチ１２ｂ，１２ｃがＱｏＳをサポートしている場合には、これらのスイッチは、ＩＰパスメッセージのＩＰパケットのＩＰペイロード内のフロー識別情報を抽出し、このフロー識別情報を記憶する。このフロー識別情報は、ソースアドレスと宛先アドレスとソースポート番号と宛先ポート番号とプロトコールＩＤを含む。このプロトコールＩＤは、ＱｏＳセッションが設定された後、ソースから宛先に送信された全てのＩＰデータパケットに含まれる。
【００３１】
ルーティングスイッチ１２ｂ，１２ｃは、パスメッセージのＩＰパケットを別のルーティングスイッチに経路指定し、その後さらにＩＰパケットから抽出されたフロー識別情報と、それがメッセージ（次のホップ）に送信するルーティングスイッチのアドレスと、それがメッセージを受信するルーティングスイッチのアドレス（前のホップ）と共に記憶する。
【００３２】
図１は、ＩＰパケットは第１ネットワーク２にルーティングスイッチ１２ｂ，１２ｃを介して到着するよう示されているが、実際にはＩＰパケットは、第１ネットワークにより多くの数のルーティングスイッチを介して到着し、そして各ルーティングスイッチは、パスメッセージのＩＰパケットから抽出したフロー識別情報を、ＩＰパケットが送信されたルーティングスイッチの識別子とＩＰパケットが到着するルーティングスイッチの識別子と共に記憶する。
【００３３】
かくしてパスメッセージのＩＣパケットは、第２ネットワークホスト端末から第１ネットワークにルーティングネットワークを介して移動する。各ルーティングスイッチは、ＩＰパケットが送信された前のホップのアドレスとＩＰパケットを受信する次のホップのアドレスとＩＰパケットのフロー識別情報を記憶する。ルーティングスイッチは、パスメッセージ内の他のトラフィック関連情報を処理するが、その特質は、本発明の議論とは無関係であるので省略する。
【００３４】
ＱｏＳセッションが設定された後、別のＩＰパケットがルーティングスイッチメモリ内に記憶されていた同一のフロー識別情報を有する特定のルーティングスイッチに到着すると、このルーティングスイッチはそれを全く同一の次のホップに転送し、そのホップのアドレスをメモリに記憶する。データパケット用のフロー識別情報は、図３（ａ）ないし（ｃ）に示されたＩＰデータパケットのフィールドから抽出される。
【００３５】
かくして連続するホップにおいて、各ルーティングスイッチ（ただし、それがＲＳＶＰのＱｏＳをサポートするもの）は、パスメッセージのＩＰパケットの固定位置からフロー識別情報を取り出し、それらを次のホップと前のホップのアドレスと共にメモリに記憶する。かくして、ＩＰパケット内のフロー識別情報は、メッセージフローを唯一に特定するのを補助し、かくしてそのメッセージフローに関連した全てのＩＰパケットは、ソースから宛先に正確に同一のネットワークパスを介して配送される。
【００３６】
第１ネットワークのプロキシサーバ４２は、パスメッセージを受信し、ステップ５４において、ＱｏＳ指示信号をネットワークリンク７２の上でホスト端末４０ａに送り、第２ネットワークのホスト端末４４ａにより要求されたＱｏＳを示す。このＱｏＳレベルがホスト端末４０ａにとって受け入れ可能なものである場合には、ホスト端末４０ａはネットワークリンク７２上にステップ５６で第１ネットワークのプロキシサーバ４２に受領確認通知を出す方法でＱｏＳの応答を送信する。
【００３７】
ステップ５８においては、第１ネットワークのプロキシサーバは、リザベーションメッセージを第２ネットワークのプロトコールＩＤ２０に送信し、ＱｏＳセッションを確認する。このリサベーションメッセージは、パスメッセージへの同一ルートを流れる（逆に）。
【００３８】
第１ネットワークのプロキシサーバにより戻されたリザベーションメッセージ７７の一般的フォーマットを図４（ｂ）に示す。同図に示すように、ソースアドレス１１５はホスト端末４０ａのアドレスで、宛先アドレス１１７は第２ネットワークホスト端末４４ａのアドレスで、ＲＳＶＰセッション内のパスメッセージとリザベーションメッセージのソースアドレスと宛先アドレスとの間の正確な関係が存在し、かくしてＲＳＶＰセッションがサポートされる。
【００３９】
リザベーションメッセージ（Ｒｅｓｖ）のＩＰパケットが、ホップバイホップでパスメッセージのＩＰパケットと同一のネットワークパスを介して送信され戻される。かくしてリザベーションメッセージのＩＰパケットのソースアドレスと宛先アドレスは、正確に次のホップと前のホップである。ソースアドレスと宛先アドレスの値は、かくしてリザベーションメッセージがパスを通して転送されるに毎にダイナミックに決定される。
【００４０】
かくしてリザベーションメッセージ７７のＩＰパケットの構造は、図４（ｂ）に示す通りであり、これはリザベーションメッセージのトランスポート層を表す。かくして図４（ｂ）に示した構造は、リザベーションメッセージの一般的概念を示し、これは発信されたソースアドレスと最終的な宛先アドレスである。リザベーションメッセージのこの解析は幾分人工的であるが、本発明においては、ＲＳＶＰの原理を示す最適なものと思われる。本明細書における例は、標準的なＲＳＶＰを用いている。標準的なＲＳＶＰの変更は考えていないしあるいは提案されていない。
【００４１】
リザベーションメッセージのＩＰパケット内のフロー識別情報は、ルーティングスイッチに到着したＩＰパケットのような各ルーティングスイッチのメモリから取り出される。このルーティングスイッチは、特定のメッセージフロー用のパス情報をそれらのメモリから取り出し、このＩＰパケットを記憶されたホップ情報に指示された前のホップに送る。かくしてリザベーションメッセージは、ライン６８，６６，６４を介してパスメッセージへの同一のルートに従う（逆に）。
【００４２】
ＩＰパケット内のフロー識別情報を用いたパスメッセージとリザベーションメッセージのルーティングは、従来のＲＳＶＰと同じである。第２ネットワークのプロキシサーバは、リザベーションメッセージを受信し、第２ネットワークの１４ａに受領確認通知を送る方法によりネットワークリンク６２上にＱｏＳ確認情報を送信し、ＱｏＳセッションが設定されたことを示す。これは図２のステップ６０で示されている。
【００４３】
ＱｏＳセッションが設定されると、ＩＰデータパケット（データメッセージ内の）は、第２ネットワークプロキシサーバあるいは第１ネットワークプロキシサーバのいずれを介しては流れない。このＩＰパケットは、第２ネットワークのホスト端末４４ａからホスト端末４０ａにフロー識別情報により決定され、ＱｏＳセッションが設定される間構築されたネットワークパスに従うルーティングスイッチ１２を含むルーティングネットワークを介して直接送られる（そしてその逆も行われる）。
【００４４】
プロキシサーバは、このようなセッションを容易にするような、それ自身では機能を有しないこれらの端末に対し、ＲＳＶＰパスメッセージとリザベーションメッセージのようなＱｏＳセッションを提供する。これらの端末は、ＱｏＳセッション機能が全くない端末である。別の構成例としてこれらの端末は、ＱｏＳセッション機能が制限された端末であり、プロキシサーバを具備することにより、このような端末によりサポートされるＱｏＳセッションが端末の機能とは独立できるようになる。広範なＱｏＳセッション機能を有するこれらの端末に対しプロキシサーバを具備することにより端末は処理タスクから開放される。
【００４５】
ネットワーク内にＱｏＳを具備する必要のある各ホスト端末は、ネットワーク内のプロキシサーバの存在を認識していなければならない。即ち、ホスト端末がプロキシサーバを発見できるプロセスがなければならない。これが行われるには２つの方法がある。第１の方法は、ネットワーク内のホスト端末は、サーバソリシケーティングメッセージ（ｓｅｒｖｅｒ−ｓｏｌｉｃｉｔｉｎｇ ｍｅｓｓａｇｅ＝ＳＳＭ）を放送する。ネットワ−ク内のプロキシサーバは、サーバ応答メッセージ（ｓｅｒｖｅｒ ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ＝ＳＲＭ）をホスト端末に送信して戻すことにより応答する。
【００４６】
第２の方法は、ネットワーク内のプロキシサーバがクライアントリクエストメッセージ（ｃｌｉｅｎｔ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ＝ＣＲＱＭ）をローカルネットワークに放送する。それに応答してホスト端末（これはプロキシサーバクライアントと見なされる）は、クライアント登録メッセージ（ｃｌｉｅｎｔ ｒｅｇｉｓｔｒａｔｉｏｎ ｍｅｓｓａｇｅ＝ＣＲＧＭ）を送り戻す。このようにしてネットワーク内のプロキシサーバの存在がネットワーク内のホスト端末により登録されるが、これはエージェント（ホームエージェント，フォロインエージェント）の存在が標準の移動ＩＰにより現在登録されるのと同じ方法で行われる。プロキシサーバにノードを登録する技術は、当業者に公知である。
【００４７】
プロキシサーバは、１つのネットワーク内のみに具備されるが、ホスト端末により具備されるＱｏＳセッションの設定は、１つあるいは複数のネットワーク内で行われる。かくして図１の実施例は、プロキシサーバを含む第１ネットワークと第２ネットワークの両方と、２つのそれぞれのプロキシサーバを用いて確立されたＲＳＶＰセッションを示しているが、実際には２つのプロキシサーバのうちの一方のみ（第１ネットワークプロキシサーバまたは第２ネットワークプロキシサーバの何れか）のみが具備され、プロキシ端末の１つと端末との間にＱｏＳセッションが確立される。ＱｏＳセッションを要求する端末の１つは、プロキシサーバを具備することあるいはＱｏＳセッションに応答する端末の１つがプロキシサーバを具備することは必ずしも必要ではない。
【００４８】
このプロキシサーバは、特定のネットワーク内のホスト端末の一部のみと関連している。数個のプロキシサーバが異なるホスト端末をサポートするために１つのネットワーク内に具備することもできる。
【００４９】
このプロキシサーバは、ＩＥＴＦ ＲＦＣ ２２０５と他のＲＳＶＰ ＩｎｔＳｅｒｖ関連のＲＦＣと適合性を有し、現在入手可能なＲＳＶＰの実行と共に内部動作する。プロキシサーバにより具備されるアプリケ−ションとプラットフォームの独立性は、Ｓｕｎ Ｓｏｌａｒｉｓ， Ｌｉｎｕｘ ａｎｄ Ｗｉｎｄｏｗｓ ９５／ＮＴ を含む利用可能なオペレーティングプラットフォーム上でライブビデオ／オーディオを含む全てのアプリケーションをサポートする。
【００５０】
ＲＳＶＰプロキシサーバにより具備されるアプリケーションとプラットフォームの独立性は、ノード／端末そのもののＲＳＶＰ機能の除去に起因する。ＲＳＶＰ機能を有する端末は、ＲＳＶＰプロキシサーバと共に動作して、アプリケーション／プラットフォームの独立性を可能とし処理負荷を取り払うことができる。
【００５１】
このプロキシサーバは、処理パワーおよび／またはバッテリの寿命が限られているこれらの端末に対するＲＳＶＰメッセージ処理に起因する計算負荷の問題を解決する。このプロキシサーバは、フロントエンドエージェントとして動作してＲＳＶＰが可能なネットワークノードとＱｏＳ具備の要素と共に相互作用し、ＲＳＶＰ信号処理をするために計算集約的な処理タスクを与えることができる。
【００５２】
【発明の効果】
以上述べた本発明は、パスメッセージとリザベーションメッセージを用いるＲＳＶＰ ＱｏＳセッションの例を挙げて説明したが、本発明はＱｏＳセッションを構築するために、２つの端末間でのリクエストメッセージとリプライメッセージを利用するいかなるＱｏＳサービスセッションにも適用可能なものである。
【図面の簡単な説明】
【図１】本発明によりプロキシサーバを具備したネットワークを設定した状態を表す図
【図２】図１のネットワーク内のＱｏＳセッションを設定するための主要ステップを表すフローチャート図
【図３】ＩＰに従うメッセージパケットフォーマットを表す図
【図４】（ａ） ＲＳＶＰ ＱｏＳセッションを構築するためのパスメッセージの一般的フォーマットを表す図
（ｂ） ＲＳＶＰ ＱｏＳセッションを構築するためのリザベーションメッセージの一般的フォーマットを表す図
【符号の説明】
２ 第１ネットワーク
４ 第２ネットワーク
１２ ルーティングスイッチ
１４ ＩＰデータパケット
１６ ソースアドレス
１８ 宛先アドレス
２０ プロトコールＩＤ
２２，３２ ＩＰペイロード
３０ ＩＰヘッダ
３４ ソースポート番号
３６ 宛先ポート番号
４０、４４ ホスト端末
４２ 第１ネットワークプロキシサーバ（ＦＮ ＰＳ）
４６ 第２ネットワークプロキシサーバ（ＳＮ ＰＳ）
６２，６４，６６，６８，７２ ネットワークリンク
７０ パスメッセージ
７７ リザベーションメッセージ
７８，１１５ ソースアドレス
８０，１１７ 宛先アドレス
Claims (3)
- １つのネットワーク内に、そのネットワークの第１の端末にリンクされ、該第１の端末と別のネットワーク内の端末との間にクオリティオブサービス（ＱｏＳ）セッションを構築するプロキシサーバを提供するステップを有し、前記ＱｏＳセッションは、前記第１の端末からのＱｏＳリクエストに応答して構築され、前記第１の端末はＱｏＳセッションを構築することができないものであり、前記ＱｏＳリクエストは、ＱｏＳセッションが確立されると送信されるべきデータの特徴を示し、前記ＱｏＳセッションはＲＳＶＰセッションであり、パスメッセージは、ＱｏＳリクエストに応答するプロキシサーバにより生成されることを特徴とするＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法。
- 前記第１の端末は、ＱｏＳセッションが構築されたことを示すプロキシサーバから確認信号を受信することを特徴とする請求項１に記載の方法。
- 前記ＱｏＳセッションはＲＳＶＰセッションであり、前記プロキシサーバは、リザベーションメッセージに応答して確認信号を生成することを特徴とする請求項２に記載の方法。
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 JP2000253052A (ja) | 2000-09-14 |
| JP3614744B2 true 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) |
Families Citing this family (7)
| 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 | 华为技术有限公司 | 数据网络用户进行数据交换的方法及其网络系统 |
| US20050068924A1 (en) * | 2001-11-12 | 2005-03-31 | Jan Lindskog | System and method for providing quality of service in ieee 802.11 systems |
| DE602004025590D1 (de) * | 2003-09-02 | 2010-04-01 | Nokia Corp | Übertragung eingebetteter Informationen bezüglich einer Dienstqualität |
| 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 |
| JP5511709B2 (ja) * | 2011-02-18 | 2014-06-04 | 日本電信電話株式会社 | ＱｏＳ制御システム、ＱｏＳ制御管理装置、及びＱｏＳ制御方法 |
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 EP EP99301429A patent/EP1033848B1/en not_active Expired - Lifetime
- 1999-02-26 DE DE69940013T patent/DE69940013D1/de 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 CN CN00102605A patent/CN1264978A/zh active Pending
- 2000-02-24 KR KR10-2000-0008955A patent/KR100387537B1/ko not_active Expired - Fee Related
- 2000-02-28 JP JP2000051866A patent/JP3614744B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| AU1755100A (en) | 2000-08-31 |
| KR20010006684A (ko) | 2001-01-26 |
| JP2000253052A (ja) | 2000-09-14 |
| KR100387537B1 (ko) | 2003-06-18 |
| EP1033848B1 (en) | 2008-12-03 |
| EP1033848A1 (en) | 2000-09-06 |
| BR0000846A (pt) | 2000-12-19 |
| CA2296944A1 (en) | 2000-08-26 |
| DE69940013D1 (de) | 2009-01-15 |
| AU736987B2 (en) | 2001-08-09 |
| CN1264978A (zh) | 2000-08-30 |
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 | |
| EP1488605B1 (en) | Method of data transfer in mobile and fixed telecommunications systems | |
| JP5048684B2 (ja) | 通信ネットワークに対する選択的なサービス更新方法 | |
| JPH10150470A (ja) | ワールドワイドウェブの要求と応答における接続管理情報の転送方法 | |
| JP2003521199A (ja) | 通信ネットワークの方法、サーバ及び構成 | |
| JP3614744B2 (ja) | ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法 | |
| EP1047244A1 (en) | Mobile IP supporting quality of service for data sent from mobile node to correspondent node | |
| JP3710711B2 (ja) | 外部エージェントおよび複数のモバイル・ノードを備えた外部ネットワークに対するサービス品質をサポートする方法及びモバイルｉｐ環境 | |
| CN103931218B (zh) | 用于数据传输的方法和本地网络实体 | |
| JP7709664B2 (ja) | 負荷分散装置、負荷分散システム、負荷分散方法、および、負荷分散プログラム | |
| Gioacchino Cascella | Reconfigurable Application Networks through Peer Discovery and Handovers | |
| JP2001320409A (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 |