JP2001352347A

JP2001352347A - 通信ネットワークのためのｒｓｖｐプロキシサービス

Info

Publication number: JP2001352347A
Application number: JP2001103403A
Authority: JP
Inventors: Christopher Martin; クリストフアー・マーテイン; D Brian Edginton; デイ・ブライアン・エジントン
Original assignee: Alcatel Internetworking Inc
Current assignee: Nokia of America Corp
Priority date: 2000-04-12
Filing date: 2001-04-02
Publication date: 2001-12-21

Abstract

(57)【要約】【課題】ＲＳＶＰの通知によるＱｏＳの実現を１つま
たは複数のＲＳＶＰ非認識ホストを含むフローに拡大す
るための、ＲＳＶＰホストプロキシサービスを提供する
こと。【解決手段】ＲＳＶＰ送信側ホストプロキシサービス
では、ＲＳＶＰ非認識ソースホストがネットワークにア
クセスする際に経由するスイッチが、ソースホストに対
してＲＳＶＰ送信側ホストプロキシとして機能する。Ｒ
ＳＶＰ受信側ホストプロキシサービスでは、ＲＳＶＰ非
認識宛先ホストがネットワークにアクセスする際に経由
するスイッチは、宛先ホストに対してＲＳＶＰ受信側ホ
ストプロキシとして機能する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この出願は、１９９９年１０
月２０日に出願された、「ＱＵＡＬＩＴＹＯＦＳＥＲ
ＶＩＣＥＰＯＬＩＣＹＭＡＮＡＧＥＲ」と題する米
国特許仮出願第６０／１６０、５６０号の利益を主張す
るものである。

【０００２】

【従来の技術】データ通信スイッチは、より一層インテ
リジェント化している。従来のデータ通信スイッチは、
無差別な先入れ先出し方式でパケットの中継を提供して
いるが、最近のデータ通信スイッチは、サービス品質
（ＱｏＳ）ラベルのもとでフロー特性に基づいて異なる
パケット中継をサポートとしている。このＱｏＳに向か
う流れは、最初にセル交換のＡＴＭネットワークにおい
て始まったが、ブリッジング（レイヤ２または「Ｌ
２］）、ルーティング（レイヤ３または「Ｌ３」）およ
びトランスポート（レイヤ４または「Ｌ４」）プロトコ
ルを含むパケット交換ネットワークおよびプロトコルに
も移行してきている。

【０００３】標準的なＱｏＳエレメントは、パケット交
換ネットワークにおいて使用され始めている。１つの標
準エレメントは、通知プロトコルで、これを介して、Ｑ
ｏＳを１つのエンドツーエンドのフローに対して提供す
ることができる。この通知プロトコルは、リソース予約
プロトコル（ＲＳＶＰ）と呼ばれている。従来のＲＳＶ
Ｐの通知によるＱｏｓの実現では、「送信側」と呼ばれ
るＲＳＶＰ認識ソースホストは、「受信側」と呼ばれる
ＲＳＶＰ認識宛先ホストへのフローを開始するにあた
り、申し込んだフローに対するパラメータを指定するＲ
ＳＶＰＰａｔｈメッセージをあて先に向かって伝送す
る。フローパスに沿うスイッチは、ＲＳＶＰＰａｔｈ
メッセージを見て、そのフローに対してＱｏＳサービス
を実施するための機能の限界および条件を示すために必
要に応じて特定のメッセージフィールドを変更する。Ｒ
ＳＶＰ認識宛先ホストは、ＲＳＶＰＰａｔｈメッセー
ジを受信し、この情報を使用して、ＲＳＶＰＲｅｓｖ
メッセージを生成し、発信元に向かって返送し、指定し
たフローに対するＱｏＳがフローパスに沿う各スイッチ
で実現されることを要求する。各スイッチは、要求され
るＱｏＳを提供するために使用可能な十分のリソースを
有しているかどうかに基づいてその要求を受け入れるか
どうか、およびそのフローに要求されたＱｏＳを与える
かどうかを決定する。予約が受け入れられる場合、スイ
ッチは、パケットをＱｏＳを満たすフローの中で中継す
るように設定される。このようにして、ＲＳＶＰ通知に
よるフローに対するＱｏＳは、フローパスに沿ってエン
ドツーエンドで実現される。

【０００４】上部で概説したような、標準的なＲＳＶＰ
の通知によるＱｏＳは、ネットワーク内でエンドツーエ
ンドにＱｏＳを実現する手段を提供するが、ＲＳＶＰ認
識ホスト間でのフローに対してのみ使用可能であること
が知られている。ＲＳＶＰ通知によるＱｏＳの利点を、
ＲＳＶＰ非認識ホストを含むフローに拡大する必要があ
る。

【０００５】

【発明が解決しようとする課題】本発明は、ＲＳＶＰの
通知によるＱｏＳの実現を、ＲＳＶＰ認識ではないホス
トを含むフローに拡大するためのＲＳＶＰホストプロキ
シサービスを提供するものである。

【０００６】

【課題を解決するための手段】ＲＳＶＰ送信側ホストプ
ロキシサービスに従って、第１ホストがネットワークに
アクセスするのに経由するスイッチが、第１ホストに対
して、ＲＳＶＰ送信側ホストプロシキとして動作する。
新しいフロー用のデータパケットを第１ホストから受信
し、ＲＳＶＰ送信側ホストプロキシサービスが第１ホス
トに対して使用状態であることが判定されると、スイッ
チは、ＲＳＶＰＰＡＴＨメッセージを生成し、第２ホス
トへのフローパスに伝送する。ＲＳＶＰに従って、ＲＳ
ＶＰＰＡＴＨメッセージは、第２ホストに、ＲＳＶＰＲ
ｅｓｖメッセージを生成し、フローパスを通じて返送す
るように要求する。

【０００７】ＲＳＶＰ受信側ホストプロキシサービスに
従って、第１ホストがネットワークにアクセスするのに
経由するスイッチは、第１ホストに対して、ＲＳＶＰ受
信側ホストプロシキとして動作する。第２ホストで生成
され、送信されたＲＳＶＰＰａｔｈメッセージを受信
し、ＲＳＶＰ受信側ホストプロキシサービスが第１ホス
トで使用状態であると判定すると、スイッチは、ＲＳＶ
ＰＲｅｓｖメッセージを生成し、第２ホストへのフロー
パスに返送する。

【０００８】ホストに対して、ＲＳＶＰホストプロキシ
として機能するスイッチは、ホストに対してＲＳＶＰル
ータとしても継続的に動作することができる。

【０００９】本発明のこれらおよび他の動作は、以下で
簡単に記載されている添付図面に関連して行う、以下の
詳細な説明を参照することによって、より良く理解され
ることになろう。

【００１０】

【発明の実施の形態】図１では、本発明に適したＲＳＶ
Ｐ送信側ホストプロキシサービスの動作するネットワー
クを示している。ネットワークには、エッジスイッチ１
４０を介してバックボーンネットワーク１３０にアクセ
スするＲＳＶＰ非認識ソースホスト１１０が含まれてい
る。エッジスイッチ１４０は、バックボーンネットワー
ク１３０で動作している１つまたは複数のコアスイッチ
（図示せず）を介してバックボーンネットワーク１３０
を通してエッジスイッチ１６０と、結合されている。エ
ッジスイッチ１６０は、ＲＳＶＰ認識宛先ホスト１２０
と結合されている。エッジスイッチ１４０、１６０は、
それぞれポリシーサーバ１５０、１７０とも結合されて
いる。

【００１１】ホスト１１０、１２０は、ＰＣ、ワークス
テーション、またはサーバなどのエンドステーション
で、他のホストと、それぞれエッジスイッチ１４０、１
６０を介するパケット通信のためのネットワークインタ
ーフェイスをそれぞれ有するものが好ましい。エッジス
イッチ１４０、１６０は、ハブ、ブリッジ、またはルー
タなどのゲートウェイデバイスで、ホストで作成された
パケット通信を中継するために対応するネットワークイ
ンターフェイスを複数有するものが好ましい。ポリシー
サーバ１５０、１７０は、フロー特性に基づいて、夫々
エッジスイッチ１４０、１６０に適用されるサービス品
質（ＱｏＳ）ルールを保有する。ホスト１１０、１２
０、エッジスイッチ１４０、１６０、およびポリシーサ
ーバ１５０、１７０は、ケーブルまたは他の伝送媒体を
介して相互に接続され、イーサネット（登録商標）、イ
ンターネットプロトコル（ＩＰ）、非同期伝送モード
（ＡＴＭ）などの種々のデータ通信プロトコルをサポー
トすることができる。エッジスイッチ１４０、１６０
は、ＲＳＶＰ（ＲｅｓｏｕｒｃｅＲｅｓａｖａｔｉｏ
ｎＰｒｏｔｏｃｏｌ）のルータ機能をサポートするこ
とが好ましい。これは１９９７年９月、「Ｒｅｓｏｕｒ
ｃｅＲｅＳｅｒＶａｔｉｏｎＰｒｏｔｏｃｏｌ−Ｖ
ｅｒｓｉｏｎ１ＦｕｎｃｔｉｏｎａｌＳｐｅｃｉ
ｆｉｃａｔｉｏｎ（リソース予約プロトコル−バージョ
ン１機能仕様）」と題する、ＩｎｔｅｒｎｅｔＥｎｇ
ｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅＲｅｑｕｅ
ｓｔＦｏｒＣｏｍｍｅｎｔ２２０５（インターネ
ットエンジニアリングタスクフォースＲＦＣ２２０５）
（これ以降は、ＲＦＣ２２０５）で述べられ、本明細書
でも参照している、宛先ホスト１２０は、ＲＦＣ２２０
５で述べられているＲＳＶＰ受信側ホスト機能をサポー
トすることが好ましいが、ソースホスト１１０は、ＲＦ
Ｃ２２０５で述べられているＲＳＶＰ送信側ホスト機能
をサポートしない。その代わり、ソースホスト１１０と
宛先ホスト１２０間のデータフローに対するＲＳＶＰの
通知によるエンドツーエンドＱｏＳの実現は、エッジス
イッチ１４０に実装されるＲＳＶＰ送信側ホストプロキ
シエージェントという方策で確立される。

【００１２】ＲＳＶＰ送信側ホストプロキシサービスの
最も基本的な機能について、図１に関連して述べる。Ｒ
ＳＶＰ非認識ソースホスト１１０は、ソースホスト１１
０とエッジスイッチ１４０とを接続する伝送媒体にデー
タパケットを伝送することによって、データフローを開
始する。このデータパケットは、ソースホスト１１０の
アドレスをソースアドレスとして、そして宛先ホスト１
２０のアドレスを宛先アドレスとして有している。エッ
ジスイッチ１４０は、データパケットを受信し、データ
パケットがＲＳＶＰ送信側ホストプロキシ基準を満たし
ていることを確認し、ＲＳＶＰＰａｔｈメッセージを
ＲＳＶＰ送信側ホスト機能に従って生成し、必要な場合
には、ＲＳＶＰルータ機能に従ってＲＳＶＰＰａｔｈ
メッセージの特定のフィールドを変更し、ＲＳＶＰＰ
ａｔｈメッセージをバックボーンネットワーク１３０に
伝送する。ＲＳＶＰＰａｔｈメッセージは、バックボ
ーンネットワーク１３０およびソースホスト１１０と宛
先ホスト１２０間のフローパスに沿ったエッジスイッチ
１６０を通る。この際メッセージの特定のフィールド
は、ＲＳＶＰルータ機能に従って各「ホップ（ｈｏ
ｐ）」で変更され、最終的にＲＳＶＰ認識宛先ホスト１
２０に着信する。宛先ホスト１２０は、ＲＳＶＰＰａｔ
ｈメッセージに応答して、ＲＳＶＰ受信側ホスト機能に
よるＱｏＳの予約を要求するＲＳＶＰＲｅｓｖメッセー
ジを生成し、ＲＳＶＰＲｅｓｖメッセージを宛先ホスト
１２０およびエッジスイッチ１６０とを接続する伝送媒
体に伝送する。エッジスイッチ１６０は、ＲＳＶＰＲｅ
ｓｖメッセージを受信し、ポリシーサーバ１７０、ＲＳ
ＶＰルータ機能と連携して、その予約を受け入れるかど
うかを決定する。前記のＲＳＶＰＲｅｓｖメッセージ
は、フローパスに沿ってバックボーンネットワーク１３
０およびエッジスイッチ１４０を通る。この際各「ホッ
プ」で、ＲＳＶＰルータ機能に従って、予約を受け入れ
るかどうかが決定され、エッジスイッチ１４０に関して
は、ポリシーサーバ１５０と連携して決定を行う。

【００１３】この基本的なＲＳＶＰ送信側ホストプロキ
シサービスには、種々の操作が以下で述べるように可能
である。しかし、基本的なレベルでは、この基本的なプ
ロキシサービスは、簡単明快であるにもかかわらず、Ｒ
ＳＶＰの通知によるＱｏＳ実現の範囲をＲＳＶＰ非認識
のソースホストを含むフローに拡大することによって、
従来の技術に比較すると大幅な進歩を提供するものと考
えられる。

【００１４】次に図２で、好ましいＲＳＶＰ送信側ホス
トプロキシサービスを、エッジスイッチ１４０の「スイ
ッチ上での」処理を参照することで、よりいっそう詳細
に述べることにする。エッジスイッチ１４０には、ネッ
トワークインターフェイス２１０、２２０、２３０、お
よびデータバス２５０によってリンクされているマネー
ジメントインターフェイス２４０がある。ネットワーク
インターフェイス２１０、２２０、２３０は、ＲＳＶＰ
非認識ソースホスト１１０、バックボーンネットワーク
１３０のスイッチ、およびポリシーサーバ１５０と異な
るインターフェイスを介して相互に接続する。マネージ
メントインターフェイス２４０は、ＱｏＳマッパ／クラ
シファイア（ｍａｐｐｅｒ／ｃｌａｓｓｉｆｉｅｒ）２
４１、ＱｏＳマネージャ２４２、ポリシーマネージャ２
４３、ＱｏＳドライバ２４４、ソースラーニング（ｓｏ
ｕｒｃｅｌｅａｒｎｉｎｇ）２４５、およびＲＳＶＰ
２４６を含む種々のモジュールをサポートしている。Ｒ
ＳＶＰ２４６には、ＲＳＶＰルータエージェント２４７
およびＲＳＶＰ送信側ホストプロキシエージェント２４
８が含まれている。マネージメントインターフェイス２
４０およびネットワークインターフェイス２１０、２２
０、２３０は、マネージメントバス２６０でリンクさ
れ、種々のフローに対するＱｏＳ情報を含むマネージメ
ント情報を送受信する。

【００１５】エッジスイッチ１４０は、以下のようにＲ
ＳＶＰ処理をサポートする。エッジスイッチ１４０で受
信されるＲＳＶＰメッセージパケットは、データバス２
５０からマネージメントインターフェイス１４０によっ
て収集される。ＲＳＶＰメッセージパケットは、ＲＳＶ
Ｐ２４６に中継され、ＲＳＶＰルーティングエージェン
ト２４７により、ＲＳＶＰルータ機能に従って処理され
る。ＲＳＶＰＰａｔｈメッセージパケットのＲＳＶＰ
ルータ機能処理には、必要に応じて特定のメッセージフ
ィールドを変更し、ＱｏＳサービスをフローに対して実
施するために、スイッチ１４０の機能の限界および条件
を示すことが含まれている。ＲＳＶＰＲｅｓｖメッセー
ジパケットのＲＳＶＰルータ機能処理には、スイッチ１
４０が要求されるＱｏＳを提供するために使用可能な十
分のリソースを有しているかどうかに基づいて要求され
ているＱｏＳ予約を受け入れるかどうか、および該フロ
ーに要求されたＱｏＳを与えるかどうかを決定すること
が含まれている。ＱｏＳ予約を受け入れるかどうかの決
定は、ＱｏＳマネージャ２４２およびポリシーマネージ
ャ２４３も関与して行われる。適用可能なＱｏＳの限界
および条件を定義するルールは、ポリシーサーバ１５０
からポリシーマネージャ２４３に「プルダウン（ｐｕｌ
ｌｅｄｄｏｗｎ）」され、決定に適用される。ＲＳＶ
Ｐルータ機能は、何らかの変更を含むＲＳＶＰＰａｔ
ｈメッセージパケットをネットワークの「次のホップ」
に中継し、何らかの変更を含むＲＳＶＰＲｅｓｖメッセ
ージパケットをネットワークの「前のホップ」に中継す
る。

【００１６】ＱｏＳマネージャ２４２は、受け入れたＱ
ｏＳ予約に従ってスイッチ１４０でのＱｏＳ確立を促進
する。予約が受け入れられたフローのために、ＱｏＳマ
ネージャ２４２は、ポリシーマネージャ２４３からＱｏ
Ｓポリシーを受け取り、ＱｏＳポリシーをフロー識別子
およびＱｏＳ部分に分割し、そのＱｏＳ部分をＱｏＳマ
ッパ／クラシファイア２４１に中継する。マッパ／クラ
シファイア２４１は、フロー識別子とＱｏＳをサポート
する待ち行列とを関連付け、その関連付けをＱｏＳドラ
イバ２４４へ中継し、ＱｏＳドライバ２４４は、マネー
ジメントバス２６０を介しネットワークインターフェイ
ス２１０、２２０、２３０上でフロー識別子／待ち行列
の関連付けを確立し、スイッチ１４０でＱｏＳポリシー
を実装する。

【００１７】上述のＲＳＶＰ処理に加えて、エッジスイ
ッチ１４０は、新規のＲＳＶＰ送信側ホストプロキシ機
能を以下のようにサポートする。スイッチ１４０で受信
されるデータパケットで、未知のソースアドレスを有す
るものが、データバス２５０からマネージメントインタ
ーフェイス１４０により収集される。未知のソースアド
レスデータパケットは、ソースラーニング２４５に中継
され、スイッチ１４０で、ソースアドレスとソースアド
レスが着信したネットワークインターフェイス間の関連
付けが確立される。未知のソースアドレスデータパケッ
トは、ＱｏＳマネージャ２４２にも中継され、ＲＳＶＰ
送信側ホストプロキシ機能を該当するソースに対して稼
動するかどうかが判定される。稼動する場合、未知のソ
ースアドレスデータパケットは、ＲＳＶＰ送信側ホスト
プロキシエージェント２４８に中継され、ＲＳＶＰ送信
側ホスト機能に従って処理される。ＲＳＶＰ送信側ホス
ト機能処理には、該フロー用のパラメータを指定するＲ
ＳＶＰＰａｔｈメッセージパケットを生成し、ＲＳＶ
ＰＰａｔｈメッセージパケットを中継することが含ま
れ、これはルーティングエージェント２４７で、既に述
べたようにＲＳＶＰルータ機能に従って処理される。

【００１８】図３ａでは、ＲＳＶＰＰａｔｈメッセー
ジパケットの一般的なフォーマットを示している。この
ようなパケットのフォーマットおよび内容は、良く知ら
れており、ＲＦＣ２２０５に記載されている。通常、そ
のようなパケットには、一般にレイヤ２のヘッダ３１
０、それに続いて、レイヤ３のヘッダ３２０およびＲＳ
ＶＰＰａｔｈメッセージ３３０が含まれている。レイ
ヤ２のヘッダ３１０には、ソースおよび宛先のアドレス
指定情報が含まれている。レイヤ３のヘッダ３２０は、
一般にＩＰヘッダで、ソースおよび宛先のアドレス指定
情報を含み、プロトコル番号「４６」を指定するもので
ある。ＲＳＶＰＰａｔｈメッセージ３３０には、メッ
セージをＰａｔｈメッセージとして識別するＲＳＶＰ共
通ヘッダおよびＰａｔｈメッセージの内容を含むＲＳＶ
Ｐオブジェクトが含まれている。Ｐａｔｈメッセージの
内容には、送信側が生成すると考えられるフローを記述
する送信側ＴＳＰＥＣおよびＡＤＳＰＥＣが含まれてい
る。送信側ＴＳＰＥＣは、フローパスをＲＳＶＰ送信側
からＲＳＶＰ受信側へ変更なしで通るが、ＡＤＳＰＥＣ
は、フローパスに沿ったスイッチで変更され、ＱｏＳ制
御サービスの可用性および正常に動作するためにＱｏＳ
制御サービスで必要とされるパラメータを示すことがで
きる。

【００１９】図３ｂでは、ＲＳＶＰＲｅｓｖメッセージ
パケットの一般的なフォーマットを示している。そのよ
うなパケットのフォーマットおよび内容は、良く知られ
ており、ＲＦＣ２２０５に記載されている。通常、その
ようなパケットには、一般にレイヤ２のヘッダ３４０、
それに続いて、レイヤ３のヘッダ３５０およびＲＳＶＰ
Ｒｅｓｖメッセージ３６０が含まれている。レイヤ２の
ヘッダ３４０には、ソースおよび宛先のアドレス指定情
報が含まれている。レイヤ３のヘッダ３４０は、一般に
ＩＰヘッダで、ソースおよび宛先のアドレス指定情報を
含み、プロトコル番号「４６」を指定するものである。
ＲＳＶＰＰａｔｈメッセージ３５０には、メッセージ
をＲＳＶＰＲｅｓｖメッセージとして識別するＲＳＶＰ
共通ヘッダおよびＲｅｓｖメッセージの内容を含むＲＳ
ＶＰオブジェクトが含まれている。Ｒｅｓｖメッセージ
の内容には、要求されたＱｏＳ制御サービス、リソース
が予約されるべきフローについて記載する受信側ＴＳＰ
ＥＣ、要求されたＱｏＳ制御サービスで指示される場合
には、要求されているサービスのレベルを記載する受信
側ＲＳＰＥＣが含まれている。これらの内容は、ともに
ＦＬＯＷＳＰＥＣを形成し、ＲＳＶＰ受信側からＲＳＶ
Ｐ送信側へのフローパスを通り、フローパスに沿ったス
イッチで変更することができる。

【００２０】次に図４では、本発明による好ましいＲＳ
ＶＰ受信側ホストプロキシサービスが動作するネットワ
ークを示している。そのネットワークには、バックボー
ンネットワーク４３０に、エッジスイッチ４４０を介し
てアクセスしているＲＳＶＰ非認識宛先ホスト４１０が
含まれている。エッジスイッチ４４０は、エッジスイッ
チ４６０と、バックボーンネットワーク４３０の１つま
たは複数のコアスイッチ（図示せず）を介して結合され
ている。エッジスイッチ４６０は、ＲＳＶＰ認識ソース
ホスト４２０と結合されている。エッジスイッチ４４
０、４６０は、ポリシーサーバ４５０、４７０ともそれ
ぞれ結合されている。

【００２１】ホスト４１０、４２０は、ＰＣ、ワークス
テーション、またはサーバなどのネットワークエンドス
テーションで、他のホストとエッジスイッチ４４０、４
６０をそれぞれ介するパケット通信のためのネットワー
クインターフェイスをそれぞれ有するものが好ましい。
エッジスイッチ４４０、４６０は、ハブ、ブリッジ、ま
たはルータなどのゲートウェイデバイスで、ホストから
発信されたパケット通信を中継するためのそれぞれのネ
ットワークインターフェイスを複数有するものが好まし
い。ポリシーサーバ４５０、４７０は、フロー特性に基
づいて、スイッチ４４０、４６０に適用されるサービス
品質（ＱｏＳ）ルールをそれぞれ保有する。ホスト４１
０、４２０、スイッチ４４０、４６０、およびポリシー
サーバ４５０、４７０は、ケーブルまたは他の伝送媒体
を介して相互に接続され、イーサネット、ＩＰ、ＡＴＭ
などの種々のプロトコルをサポートすることができる。
エッジスイッチ４４０、４６０は、ＲＦＣ２２０５で述
べられているＲＳＶＰルータ機能をサポートすることが
好ましい。ソースホスト４２０は、ＲＦＣ２２０５で述
べられているＲＳＶＰ送信側ホスト機能をサポートする
ことが好ましいが、宛先ホスト４１０は、ＲＦＣ２２０
５で述べられているＲＳＶＰ受信側ホスト機能をサポー
トしない。したがって、ソースホスト４２０と宛先ホス
ト４１０間のデータフローに対するエンドツーエンドＱ
ｏＳの実現は、エッジスイッチ４４０に実装されるＲＳ
ＶＰ受信側ホストプロキシエージェントという方策で確
立される。

【００２２】ＲＳＶＰ受信側ホストプロキシサービスの
最も基本的な機能について、図４に関連して述べること
ができる。ＲＳＶＰ認識ソースホスト４２０は、ＲＳＶ
Ｐ送信側ホスト機能に従って、ＲＳＶＰ非認識宛先ホス
ト４１０のアドレスを宛先アドレスとして有するＲＳＶ
ＰＰａｔｈメッセージを生成し、ＲＳＶＰＰａｔｈ
メッセージをソースホスト４２０とスイッチ４６０相互
に接続している伝送媒体に伝送する。スイッチ４６０
は、ＲＳＶＰＰａｔｈメッセージを受信し、必要な場
合には、ＲＳＶＰルータ機能に従ってメッセージの特定
のフィールドを変更し、ＲＳＶＰＰａｔｈメッセージ
をバックボーンネットワーク４３０に伝送する。ＲＳＶ
ＰＰａｔｈメッセージは、バックボーンネットワーク
４３０のフローパスに沿ったスイッチを次々に（ホップ
バイホップ）通り、この時メッセージの特定のフィール
ドはＲＳＶＰルータ機能に従って変更され、最終的にス
イッチ４４０に着信する。スイッチ４４０は、ＲＳＶＰ
ルータ機能に従ってメッセージの特定のフィールドを変
更し、ＲＳＶＰＰａｔｈメッセージパケットが、ＲＳ
ＶＰ受信側ホストプロキシ基準を満たしていることを確
認し、それに応答し、ＲＳＶＰＲｅｓｖメッセージをＲ
ＳＶＰ受信側ホスト機能に従って生成する。スイッチ４
４０は、ポリシーサーバ４５０と連携し、ＲＳＶＰルー
タ機能に従って、その予約自体を受け入れるかどうを決
定し、その後にＲＳＶＰＲｅｓｖメッセージをバックボ
ーンネットワーク４３０のフローパスに返送する。その
ＲＳＶＰＲｅｓｖメッセージは、バックボーンネットワ
ーク４３０のスイッチおよびスイッチ４６０を通るが、
この際、ＲＳＶＰルータ機能に従って、ポリシーサーバ
４７０と連携して決定を行うエッジスイッチ４６０とと
もに予約を受け入れるかどうかをホップバイホップに決
定する。

【００２３】この基本的なＲＳＶＰ受信側ホストプロキ
シサービスには、種々の操作が以下で述べるように可能
である。しかし、基本的なレベルでこの基本的なプロキ
シサービスは、簡単明快であるにもかかわらず、ＲＳＶ
Ｐの範囲を拡大し、ＲＳＶＰ非認識の宛先ホストを含む
フローに対してエンドツーエンドのＱｏＳの実現を可能
にするものであり、従来の技術に比較すると大幅な進歩
を提供するものと考えられる。

【００２４】次に図５では、ＲＳＶＰ受信側ホストプロ
キシサービスを選び、エッジスイッチ４４０の「スイッ
チ上での」処理を参照することにより、よりいっそう詳
細に述べることにする。スイッチ４４０には、ネットワ
ークインターフェイス５１０、５２０、５３０、および
データバス５５０によってリンクされているマネージメ
ントインターフェイス５４０がある。ネットワークイン
ターフェイス５１０、５２０、５３０は、宛先ホスト４
１０、バックボーンネットワーク４３０のスイッチ、お
よびポリシーサーバ４５０を異なるインターフェイスを
介して相互に接続している。マネージメントインターフ
ェイス５４０は、ＱｏＳマッパ／クラシファイア５４
１、ＱｏＳマネージャ５４２、ポリシーマネージャ５４
３、ＱｏＳドライバ５４４、ソースラーニング５４５、
およびＲＳＶＰ５４６を含む種々のモジュールをサポー
トしている。ＲＳＶＰ５４６には、ＲＳＶＰルータエー
ジェント５４７およびＲＳＶＰ受信側ホストプロキシエ
ージェント５４８が含まれている。マネージメントイン
ターフェイス５４０およびネットワークインターフェイ
ス５１０、５２０、５３０は、マネージメントバス５６
０でリンクされ、種々のフローについてのＱｏＳ情報を
含むマネージメント情報を送受信する。

【００２５】スイッチ４４０は、以下のようにＲＳＶＰ
処理をサポートする。スイッチ４４０で受信されるＲＳ
ＶＰメッセージパケットは、データバス５５０からマネ
ージメントインターフェイス５４０によって収集され
る。ＲＳＶＰメッセージパケットは、ＲＳＶＰ５４６に
中継され、ＲＳＶＰルーティングエージェント５４７
で、ＲＳＶＰルータ機能に従い、処理されるが、本明細
書で指定されている例外を含む。ＲＳＶＰＰａｔｈメ
ッセージパケットの場合、ＲＳＶＰルータ機能処理に
は、必要に応じてＰａｔｈメッセージの特定のフィール
ドを変更し、ＱｏＳサービスをフローに対し実施するた
めに、スイッチ５４０の機能の限界および条件を示すこ
とが含まれている。ＲＳＶＰＲｅｓｖメッセージパケッ
トの場合、ＲＳＶＰルータ機能処理には、スイッチ４４
０が要求されるＱｏＳを提供するために使用可能な十分
のリソースを有しているかどうかに基づいて要求されて
いるＱｏＳ予約を受け入れるかどうか、および該フロー
に要求されたＱｏＳを与えるかどうかを決定することが
含まれる。ＱｏＳ予約を受け入れるかどうかの決定は、
ＱｏＳマネージャ５４２およびポリシーマネージャ５４
３も関与して行われる。適用可能なＱｏＳの限界および
条件を定義するルールは、ポリシーサーバ４５０からポ
リシーマネージャ５４３に「プルダウン」され、決定に
適用される。ＲＳＶＰルータ機能は、いずれかの変更も
含むＲＳＶＰＲｅｓｖメッセージパケットをネットワー
クの「前のホップ」に中継する。ＲＳＶＰルータ機能
は、またいずれかの変更も含むＲＳＶＰＰａｔｈメッ
セージパケットをネットワークの「次のホップ」に中継
するが、ＲＳＶＰ受信側ホストプロキシ機能が、該当す
る宛先に対して使用可能である場合は別である。使用可
能な場合、ＲＳＶＰＰａｔｈメッセージは、ネットワ
ークの「次のホップ」に中継されない。

【００２６】上述のＲＳＶＰ処理に加えて、スイッチ４
４０は、新規のＲＳＶＰ受信側ホストプロキシ機能を以
下のようにサポートする。ＲＳＶＰＰａｔｈメッセー
ジパケットは、ＱｏＳマネージャ５４２に中継され、Ｒ
ＳＶＰ受信側ホストプロキシ機能が該当する宛先に対し
て使用可能かどうかが判定される。使用可能な場合、Ｒ
ＳＶＰＰａｔｈメッセージパケットは、ＲＳＶＰ受信
側ホストプロキシエージェント５４８に中継され、ＲＳ
ＶＰ受信側ホスト機能に従って処理される。ＲＳＶＰ受
信側ホスト機能には、ＲＳＶＰＰａｔｈメッセージパ
ケットに応答してＲＳＶＰＲｅｓｖメッセージパケット
を生成し、ＲＳＶＰＲｅｓｖメッセージパケットを中継
することが含まれ、それはＲＳＶＰルーティングエージ
ェント５４７で、既に述べたようにＲＳＶＰルータ機能
に従って処理される。

【００２７】図６の流れ図は、ＲＳＶＰ送信側ホストプ
ロキシ機能を本発明の好ましい一実施形態に従ってサポ
ートするスイッチでの、ＲＳＶＰパケットの処理を例示
している。パケットがスイッチで受信され（６１０）、
そのパケットがＲＳＶＰメッセージパケットかどうかの
判定が行われる（６２０）。そのパケットがＲＳＶＰメ
ッセージパケットの場合、パケットは、ＲＳＶＰルータ
機能に従って処理される（６５０）。パケットがＲＳＶ
Ｐメッセージパケットではない場合、パケットには、ス
イッチには未知の、つまりＱｏＳがまだ実現されていな
い新しいフローであることを示すソースアドレスがある
どうかが判定される（６３０）。パケットに未知のソー
スアドレスがある場合、ＲＳＶＰ送信側ホストプロキシ
サービスがそのソースに対して使用可能かどうかが判定
される（６４０）。ＲＳＶＰ送信側ホストプロキシサー
ビスがソースに対して使用可能の場合、ＲＳＶＰＰａ
ｔｈメッセージパケットが生成される（６５０）。ＲＳ
ＶＰＰａｔｈメッセージは、スイッチにより、ＲＳＶ
Ｐルータ機能に従って処理される（６６０）。しかし、
（ステップ６３０の判定に従って）ソースアドレスがス
イッチに未知の場合、または（ステップ６４０の判定に
従って）ＲＳＶＰ送信側ホストプロキシサービスがソー
スに対して使用可能ではない場合、受信したパケットの
ＲＳＶＰ処理は終了する。

【００２８】図７の流れ図は、ＲＳＶＰ受信側ホストプ
ロキシ機能を本発明の好ましい一実施形態に従ってサポ
ートするスイッチでの、ＲＳＶＰパケットの処理を例示
している。パケットがスイッチで受信され（７１０）、
そのパケットがＲＳＶＰメッセージパケットかどうかの
判定が行われる（７２０）。そのパケットがＲＳＶＰメ
ッセージパケットの場合、そのパケットはＲＳＶＰＰ
ａｔｈメッセージパケットかどうかが判定される（７３
０）。パケットがＲＳＶＰＰａｔｈメッセージパケッ
トではない場合、受信したパケットのＲＳＶＰ処理は、
ＲＳＶＰルータ機能に従って進められる（７４０）。し
かし、パケットがＲＳＶＰＰａｔｈメッセージパケッ
トの場合、ＲＳＶＰ受信側ホストプロキシサービスがそ
の宛先に対して使用可能かどうかが判定される（７５
０）。ＲＳＶＰ受信側ホストプロキシサービスが宛先に
対して使用可能ではない場合、受信したパケットのＲＳ
ＶＰ処理は、ＲＳＶＰルータ機能に従って進められる
（７４０）。しかし、ＲＳＶＰ受信側ホストプロキシサ
ービスが宛先に対して使用可能な場合、受信したパケッ
トのＲＳＶＰ処理は、Ｐａｔｈメッセージがスイッチに
よってネットワークの「次のホップ」へ中継されない場
合を除いてＲＳＶＰルータ機能に従って進められ（７６
０）、そしてＲＳＶＰＲｅｓｖメッセージパケットが生
成される（７７０）。ＲＳＶＰＲｅｓｖメッセージは、
スイッチによりＲＳＶＰルータ機能に従って処理される
（７８０）。

【００２９】当技術分野の技術者によって、本発明は本
明細書の趣旨および基本的な特徴を逸脱することなく、
特定の他の形で実施できることは理解されよう。例え
ば、例示した実施形態は、ソースホストと単一の宛先ホ
スト間のユニキャストのフローに対するＲＳＶＰプロシ
キの通知によるエンドツーエンドＱｏＳの実現を述べて
きたが、本発明は、ソースホストと複数の宛先ホスト間
で、１つまたは複数のスイッチがソースホストおよび／
または１つまたは複数の宛先ホストに対して、ＲＳＶＰ
ホストプロシキとして機能する場合のマルチキャストフ
ローにも適用することができる。したがって、本発明の
説明は、すべての点で例示的なものであり、限定的なも
のではないものと見なされる。本発明の範囲は、添付す
る請求項により示されており、本発明と同等の意味およ
び範囲内で生じる変更すべては、本発明に含まれること
を意図するものである。

【図面の簡単な説明】

【図１】ＲＳＶＰ送信側ホストプロキシサービスが動作
するネットワークを示す図である。

【図２】図１によるネットワークのＲＳＶＰ送信側ホス
トプロキシ機能をサポートするスイッチを示す図であ
る。

【図３ａ】ＲＳＶＰＰａｔｈメッセージを含むパケッ
ト用の一般的なフォーマットを示す図である。

【図３ｂ】ＲＳＶＰＲｅｓｖメッセージを含むパケット
用の一般的なフォーマットを示す図である。

【図４】ＲＳＶＰ受信側ホストプロキシサービスが動作
するネットワークを示す図である。

【図５】図４によるネットワークのＲＳＶＰ受信側ホス
トプロキシ機能をサポートするスイッチを示す図であ
る。

【図６】ＲＳＶＰ送信側ホストプロキシ機能を本発明の
好ましい一実施形態に従ってサポートするスイッチで
の、ＲＳＶＰパケットの処理を示す流れ図である。

【図７】ＲＳＶＰ受信側ホストプロキシ機能を本発明の
好ましい一実施形態に従ってサポートするスイッチで
の、ＲＳＶＰパケットの処理を示す流れ図である。

【符号の説明】

１１０ＲＳＶＰ非認識ソースホスト１２０ＲＳＶＰ認識宛先ホスト１３０、４３０バックボーンネットワーク１４０、１６０エッジスイッチ１５０、１７０、４５０、４７０ポリシーサーバ２１０、２２０、２３０、５１０、５２０、５３０ネ
ットワークインターフェイス２４０、５４０マネージメントインターフェイス２４１、５４１マッパ／クラシファイア２４２、５４２ＱｏＳマネージャ２４３、５４３ポリシーマネージャ２４４、５４４ＱｏＳドライバ２４５、５４５ソースラーニング２４６、５４６ＲＳＶＰ２４７、５４７ＲＳＶＰルータエージェント２４８ＲＳＶＰ送信側ホストプロキシエージェント２５０、５５０データバス２６０、５６０マネージメントバス３１０、３４０レイヤ２のヘッダ３２０、３５０レイヤ３のヘッダ３３０ＲＳＶＰ共通ヘッダおよびＰａｔｈメッセージ
の内容を含むＲＳＶＰオブジェクト３６０ＲＳＶＰ共通ヘッダおよびＲｅｓｖメッセージ
の内容を含むＲＳＶＰオブジェクト４１０ＲＳＶＰ非認識宛先ホスト４２０ＲＳＶＰ認識ソースホスト４４０、４６０スイッチ５４８ＲＳＶＰ受信側ホストプロキシエージェント

───────────────────────────────────────────────────── フロントページの続き (72)発明者デイ・ブライアン・エジントンアメリカ合衆国、ユタ・84084、ウエスト・ジヨーダン、2675・ウエスト・6865・サウスＦターム(参考） 5K030 HA08 HB13 HC14 HD06 JT06 MB01

Claims

【特許請求の範囲】

【請求項１】複数のノードを有する通信ネットワーク
のためのリソース予約プロトコル（ＲＳＶＰ）プロキシ
方法であって、第１ノードでデータパケットを生成すること、前記データパケットを第２ノードに伝送すること、前記データパケットに応答して、前記第２ノードで、前
記第２ノードが前記第１ノードのためのＲＳＶＰプロキ
シであるかどうかを判定すること、前記判定に応答して、ＲＳＶＰＰａｔｈメッセージを
生成すること、前記ＲＳＶＰＰａｔｈメッセージを第３ノードに伝送
することを含むリソース予約プロトコル（ＲＳＶＰ）プ
ロキシ方法。
【請求項２】第１ノードがホストであり、第２ノード
がスイッチである請求項１に記載の方法。
【請求項３】判定が、パケットのソースアドレスに従
って行われる請求項１に記載の方法。
【請求項４】複数のノードを有する通信ネットワーク
のためのリソース予約プロトコル（ＲＳＶＰ）プロキシ
方法であって、第１ノードでＲＳＶＰＰａｔｈメッセージを生成する
こと、前記ＲＳＶＰＰａｔｈメッセージを第２ノードに伝送
すること、前記ＲＳＶＰＰａｔｈメッセージに応答して、前記第
２ノードで、前記第２ノードが第３ノードのためのＲＳ
ＶＰプロキシであるかどうかを判定すること、前記判定に応答して、ＲＳＶＰＲｅｓｖメッセージを生
成すること、前記ＲＳＶＰＲｅｓｖメッセージを前記第１ノードに伝
送することを含むリソース予約プロトコル（ＲＳＶＰ）
プロキシ方法。
【請求項５】第１ノードおよび第３ノードがホストで
あり、第２ノードがスイッチである請求項４に記載の方
法。
【請求項６】判定が、パケットの宛先アドレスに従っ
て行われる請求項４に記載の方法。
【請求項７】複数のホストおよびスイッチを有する通
信ネットワークのためのＲＳＶＰプロキシ方法であっ
て、データパケットを第１ホストからスイッチへ伝送するこ
と、前記データパケットに応答して、前記スイッチでＲＳＶ
ＰＰａｔｈメッセージを作成すること、前記ＲＳＶＰＰａｔｈメッセージを前記スイッチから
第２ホストへ伝送すること、前記ＲＳＶＰＰａｔｈメッセージに応答してＲＳＶＰ
Ｒｅｓｖメッセージを前記第２ホストから前記スイッチ
へ伝送することを含むＲＳＶＰプロキシ方法。
【請求項８】第１ホストがＲＳＶＰ非認識である請求
項７に記載の方法。
【請求項９】ＲＳＶＰＲｅｓｖメッセージに応答し
て、第２ホストとスイッチ間のフローパスに沿ったリソ
ースを予約することをさらに含む請求項７に記載の方
法。
【請求項１０】複数のノードを有する通信ネットワー
クのためのＲＳＶＰプロキシ方法であって、ＲＳＶＰＰａｔｈメッセージを第１ホストからスイッ
チへ伝送すること、前記ＲＳＶＰＰａｔｈメッセージに応答して、前記ス
イッチでＲＳＶＰＲｅｓｖメッセージを作成すること、前記ＲＳＶＰＲｅｓｖメッセージを前記スイッチから前
記第１ホストへ伝送することを含むＲＳＶＰプロキシ方
法。
【請求項１１】第１ホストがＲＳＶＰ非認識である請
求項１０に記載の方法。
【請求項１２】ＲＳＶＰＲｅｓｖメッセージに応答し
て、第１ホストとスイッチ間のフローパスに沿ったリソ
ースを予約することをさらに含む請求項１１に記載の方
法。
【請求項１３】データパケットを伝送するためのホス
トと、前記データパケットを前記ホストから受信するためのエ
ッジスイッチと、前記データパケットに応答して、ＲＳＶＰＰａｔｈメ
ッセージを生成およびバックボーンネットワークに伝送
する、前記エッジスイッチのＲＳＶＰホストプロキシエ
ージェントとを備える通信ネットワークのためのＲＳＶ
Ｐプロキシサービス。
【請求項１４】ＲＳＶＰＰａｔｈメッセージを伝送
するためのホストと、前記ＲＳＶＰＰａｔｈメッセージをバックボーンネッ
トワークから受信するためのエッジスイッチと、前記ＲＳＶＰＰａｔｈメッセージに応答して、ＲＳＶ
ＰＲｅｓｖメッセージを生成および前記バックボーンネ
ットワークに伝送する、前記エッジスイッチのＲＳＶＰ
ホストプロキシエージェントとを備える通信ネットワー
クのためのＲＳＶＰプロキシサービス。
【請求項１５】エッジスイッチに接続されているホス
トと、前記ホストからバックボーンネットワークへのデ
ータパケットのフローを管理する前記エッジスイッチと
を備え、前記エッジスイッチが、データパケットを前記ホストか
ら受信し、それに応答して、ＲＳＶＰＰａｔｈメッセ
ージを生成し、バックボーンネットワークに伝送する通
信ネットワークのためのＲＳＶＰプロキシサービス。
【請求項１６】エッジスイッチに接続されているホス
トと、前記ホストからバックボーンネットワークへのデ
ータパケットのフローを管理する前記エッジスイッチと
を備え、前記エッジスイッチが、前記ホスト宛てのＲＳＶＰＰ
ａｔｈメッセージを前記バックボーンネットワークから
受信し、それに応答して、ＲＳＶＰＲｅｓｖメッセージ
を生成し、前記バックボーンネットワークに伝送する通
信ネットワークのためのＲＳＶＰプロキシサービス。
【請求項１７】第２ノードに接続されている第１ノー
ドと、前記第１ノードとバックボーンネットワーク間の
インターフェイスを提供する前記第２ノードとを備え、前記第２ノードが、データパケットを前記第１ノードか
ら受信し、それに応答して、ＲＳＶＰＰａｔｈメッセ
ージを生成し、前記バックボーンネットワークに伝送す
る通信ネットワークのためのＲＳＶＰプロキシサービ
ス。
【請求項１８】第２ノードに接続されている第１ノー
ドと、前記第１ノードとバックボーンネットワーク間の
インターフェイスを提供する前記第２ノードとを備え、前記第２ノードが、前記第１ノード宛てのＲＳＶＰＰ
ａｔｈメッセージを前記バックボーンネットワークから
受信し、それに応答して、ＲＳＶＰＲｅｓｖメッセージ
を生成し、前記バックボーンネットワークに伝送する通
信ネットワークのためのＲＳＶＰプロキシサービス。
【請求項１９】通信ネットワークのデータフローに対
し、通知プロキシを利用して、エンドツーエンドのサー
ビス品質（ＱｏＳ）を確立するための通知方法であっ
て、第１ノードでデータパケットを生成すること、前記データパケットを第２ノードに伝送すること、前記データパケットに応答して、前記第２ノードで、前
記第２ノードが前記第１ノードのためのＱｏＳ通知プロ
キシであるかどうかを判定すること、前記判定に応答して、ＱｏＳメッセージを生成するこ
と、前記ＱｏＳメッセージを第３ノードに伝送することを含
む、エンドツーエンドのサービス品質（ＱｏＳ）を確立
するための通知方法。
【請求項２０】第１のノードがホストであり、第２ノ
ードがスイッチである請求項１９に記載の方法。
【請求項２１】判定が、パケットのソースアドレスに
従って行われる請求項２０に記載の方法。
【請求項２２】ＱｏＳメッセージが、データフローの
ためのパラメータを指定する請求項２０に記載の方法。
【請求項２３】ＱｏＳメッセージが、第３ノードへの
ルートで変更される請求項２０に記載の方法。
【請求項２４】通信ネットワークのデータフローに対
し、通知プロキシを利用して、エンドツーエンドのサー
ビス品質（ＱｏＳ）を確立するための通知方法であっ
て、第１ノードで第１ＱｏＳメッセージを生成すること、前記第１ＱｏＳメッセージを第２ノードに伝送するこ
と、前記ＱｏＳメッセージに応答して、前記第２ノードで、
前記第２ノードが第３ノードのためのＱｏＳ通知プロキ
シであるかどうかを判定すること、前記判定に応答して、第２ＱｏＳメッセージを生成する
こと、前記第２ＱｏＳメッセージを前記第１ノードに伝送する
ことを含む、エンドツーエンドのサービス品質（Ｑｏ
Ｓ）を確立するための通知方法。
【請求項２５】第１のノードおよび第３ノードがホス
トであり、第２ノードがスイッチである請求項２４に記
載の方法。
【請求項２６】判定が、第１ＱｏＳメッセージの宛先
アドレスに従って行われる請求項２４に記載の方法。
【請求項２７】第１ＱｏＳメッセージが、データフロ
ーのためのパラメータを指定する請求項２４に記載の方
法。
【請求項２８】第１ＱｏＳメッセージが、第２ノード
へのルートで変更される請求項２４に記載の方法。
【請求項２９】第２ＱｏＳメッセージが、データフロ
ーのためのＱｏＳの確立を要求する請求項２４に記載の
方法。
【請求項３０】ＱｏＳが、第２ＱｏＳメッセージに応
答して第２ノードと第１ノードのフローパスに沿ったノ
ードでデータフローに対して確立される請求項２４に記
載の方法。
【請求項３１】エッジスイッチに接続されているホス
トと、前記ホストからバックボーンネットワークへのデ
ータパケットのフローを管理する前記エッジスイッチと
を備え、前記エッジスイッチが、データパケットを前記ホストか
ら受信し、それに応答して、ＱｏＳメッセージを生成
し、前記バックボーンネットワークに伝送する、通信ネ
ットワークにおいてエンドツーエンドのＱｏＳを確立す
るためのサービス。
【請求項３２】ＱｏＳメッセージが、データフローの
ためのパラメータを指定する請求項３１に記載のサービ
ス。
【請求項３３】エッジスイッチに接続されているホス
トと、前記ホストからバックボーンネットワークへのデ
ータパケットのフローを管理する前記エッジスイッチと
を備え、前記エッジスイッチが、前記ホスト宛ての第１ＱｏＳメ
ッセージを前記バックボーンネットワークから受信し、
それに応答して、第２ＱｏＳメッセージを生成し、前記
バックボーンネットワークに伝送する、通信ネットワー
クにおいてエンドツーエンドのＱｏＳを確立するための
サービス。
【請求項３４】第１ＱｏＳメッセージが、データフロ
ーのためのパラメータを指定する請求項３３に記載のサ
ービス。
【請求項３５】第２ＱｏＳメッセージが、データフロ
ーのためのＱｏＳの確立を要求する請求項３３に記載の
サービス。