(57)【要約】【課題】受信ホストがＲＳＶＰに対応していないことを自動的に検出して代理でＲＳＶＰ手順を実行可能なＲＳＶＰ代理応答ルータを提供する。【解決手段】Ｐａｔｈメッセージ記憶部１７はＲＳＶＰ制御部１６が扱ったＰａｔｈメッセージを記憶する。ＩＣＭＰ検出部１９はルーティング部１８に入力されるデータパケットを監視し、パケットの中にＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」を発見した場合、そのＩＣＭＰメッセージに含まれるＩＰヘッダ情報とＰａｔｈメッセージ記憶部１７の記録値とを比較し、一致するものがあると、当該ＩＣＭＰメッセージを破棄し、代わりに代理ＲＳＶＰ制御部２０に受信ホストの代わりにＲＳＶＰの手順を実行するように依頼する。代理ＲＳＶＰ制御部２０は指定されたＰａｔｈメッセージに対して本来の受信ホストの代わりにＲＳＶＰの手順を実行する。【選択図】　　　図２
2004104544.tif 000002
【特許請求の範囲】
【請求項１】
送信ホストから受信ホストにデータパケットを送信する際に、送信経路でのサービス品質の保証を得るために前記送信ホストから送信される確認メッセージを前記受信ホストに転送するＲＳＶＰ代理応答ルータであって、
前記確認メッセージに対する前記受信ホストからの応答メッセージを監視しかつ当該応答メッセージを基に前記受信ホストがＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に対応する機器か否かを判別する判別手段と、前記ＲＳＶＰに対応しない機器と判別された受信ホストの代理で前記ＲＳＶＰの手順を実行して前記送信ホストとの間の経路上の資源を予約する代理ＲＳＶＰ制御手段とを有することを特徴とするＲＳＶＰ代理応答ルータ。
【請求項２】
前記判別手段は、前記確認メッセージとして送信される前記ＲＳＶＰのＰａｔｈメッセージに対する前記受信ホストからの前記応答メッセージでありかつ対応していないプロトコルのパケットを受信した際に当該パケットの送信元に送信されるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージを監視し、そのＩＣＭＰメッセージから前記ＲＳＶＰに対応する機器か否かを判別することを特徴とする請求項１記載のＲＳＶＰ代理応答ルータ。
【請求項３】
前記代理ＲＳＶＰ制御手段は、前記受信ホストの代わりに前記Ｐａｔｈメッセージに対しかつ前記送信経路でのサービス品質を示すＲｅｓｖメッセージを生成して前記送信ホストに向かう経路上に送信することを特徴とする請求項２記載のＲＳＶＰ代理応答ルータ。
【請求項４】
前記ＲＳＶＰに対応していない受信ホストと前記ＲＳＶＰに対応している受信ホストとが多数混在するネットワークに対応して配設されたことを特徴とする請求項１から請求項３のいずれか記載のＲＳＶＰ代理応答ルータ。
【請求項５】
前記ＲＳＶＰに対応していない受信ホストと前記ＲＳＶＰに対応している受信ホストとが多数混在するネットワーク内に配設されたことを特徴とする請求項１から請求項３のいずれか記載のＲＳＶＰ代理応答ルータ。
【請求項６】
前記ＲＳＶＰに対応していない受信ホストからなるネットワークと前記ＲＳＶＰに対応している受信ホストからなるネットワークとにそれぞれ対応して配設されたことを特徴とする請求項１から請求項３のいずれか記載のＲＳＶＰ代理応答ルータ。
【請求項７】
送信ホストから受信ホストにデータパケットを送信する際に、送信経路でのサービス品質の保証を得るために前記送信ホストから送信される確認メッセージを前記送信ホストと前記受信ホストとの間に配設されたＲＳＶＰ代理応答ルータによって前記受信ホストに転送するＲＳＶＰ代理応答システムであって、
前記確認メッセージに対する前記受信ホストからの応答メッセージを監視しかつ当該応答メッセージを基に前記受信ホストがＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に対応する機器か否かを判別する判別手段と、前記ＲＳＶＰに対応しない機器と判別された受信ホストに代わって前記ＲＳＶＰの手順を実行して前記送信ホストとの間の経路上の資源を予約する代理ＲＳＶＰ制御手段とを前記ＲＳＶＰ代理応答ルータに有することを特徴とするＲＳＶＰ代理応答システム。
【請求項８】
前記判別手段は、前記確認メッセージとして送信される前記ＲＳＶＰのＰａｔｈメッセージに対する前記受信ホストからの前記応答メッセージでありかつ対応していないプロトコルのパケットを受信した際に当該パケットの送信元に送信されるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージを監視し、そのＩＣＭＰメッセージから前記ＲＳＶＰに対応する機器か否かを判別することを特徴とする請求項７記載のＲＳＶＰ代理応答システム。
【請求項９】
前記代理ＲＳＶＰ制御手段は、前記受信ホストの代わりに前記Ｐａｔｈメッセージに対しかつ前記送信経路でのサービス品質を示すＲｅｓｖメッセージを生成して前記送信ホストに向かう経路上に送信することを特徴とする請求項８記載のＲＳＶＰ代理応答システム。
【請求項１０】
前記ＲＳＶＰ代理応答ルータを、前記ＲＳＶＰに対応していない受信ホストと前記ＲＳＶＰに対応している受信ホストとが多数混在するネットワークに対応して配設したことを特徴とする請求項７から請求項９のいずれか記載のＲＳＶＰ代理応答システム。
【請求項１１】
前記ＲＳＶＰ代理応答ルータを、前記ＲＳＶＰに対応していない受信ホストと前記ＲＳＶＰに対応している受信ホストとが多数混在するネットワーク内に配設したことを特徴とする請求項７から請求項９のいずれか記載のＲＳＶＰ代理応答システム。
【請求項１２】
前記ＲＳＶＰ代理応答ルータを、前記ＲＳＶＰに対応していない受信ホストからなるネットワークと前記ＲＳＶＰに対応している受信ホストからなるネットワークとにそれぞれ対応して配設したことを特徴とする請求項７から請求項９のいずれか記載のＲＳＶＰ代理応答システム。
【請求項１３】
送信ホストから受信ホストにデータパケットを送信する際に、送信経路でのサービス品質の保証を得るために前記送信ホストから送信される確認メッセージを前記送信ホストと前記受信ホストとの間に配設されたＲＳＶＰ代理応答ルータによって前記受信ホストに転送するＲＳＶＰ代理応答方法であって、前記ＲＳＶＰ代理応答ルータが、前記確認メッセージに対する前記受信ホストからの応答メッセージを監視し、当該応答メッセージを基に前記受信ホストがＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に対応しない機器であると判別された時に前記受信ホストに代わって前記ＲＳＶＰの手順を実行して前記送信ホストとの間の経路上の資源を予約することを特徴とするＲＳＶＰ代理応答方法。
【請求項１４】
前記ＲＳＶＰ代理応答ルータが、前記確認メッセージとして送信される前記ＲＳＶＰのＰａｔｈメッセージに対する前記受信ホストからの前記応答メッセージでありかつ対応していないプロトコルのパケットを受信した際に当該パケットの送信元に送信されるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）メッセージを監視し、そのＩＣＭＰメッセージから前記ＲＳＶＰに対応する機器か否かを判別することを特徴とする請求項１３記載のＲＳＶＰ代理応答方法。
【請求項１５】
前記ＲＳＶＰ代理応答ルータが、前記受信ホストの代わりに前記Ｐａｔｈメッセージに対しかつ前記送信経路でのサービス品質を示すＲｅｓｖメッセージを生成して前記送信ホストに向かう経路上に送信することを特徴とする請求項１４記載のＲＳＶＰ代理応答方法。
【請求項１６】
前記ＲＳＶＰ代理応答ルータを、前記ＲＳＶＰに対応していない受信ホストと前記ＲＳＶＰに対応している受信ホストとが多数混在するネットワークに対応して配設したことを特徴とする請求項１３から請求項１５のいずれか記載のＲＳＶＰ代理応答方法。
【請求項１７】
前記ＲＳＶＰ代理応答ルータを、前記ＲＳＶＰに対応していない受信ホストと前記ＲＳＶＰに対応している受信ホストとが多数混在するネットワーク内に配設したことを特徴とする請求項１３から請求項１５のいずれか記載のＲＳＶＰ代理応答方法。
【請求項１８】
前記ＲＳＶＰ代理応答ルータを、前記ＲＳＶＰに対応していない受信ホストからなるネットワークと前記ＲＳＶＰに対応している受信ホストからなるネットワークとにそれぞれ対応して配設したことを特徴とする請求項１３から請求項１５のいずれか記載のＲＳＶＰ代理応答方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はＲＳＶＰ代理応答ルータ、ＲＳＶＰ代理応答システム及びそれに用いるＲＳＶＰ代理応答方法に関し、特にＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）保証のために用いられるＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）のネットワークに関する。
【０００２】
【従来の技術】
近年、ラストワンマイルと呼ばれていたアクセス回線の高速化が急速に進み、一般家庭においてもＣＡＴＶ（ＣＡｂｌｅ　ＴｅｌｅＶｉｓｉｏｎ），ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ），ＦＴＴＨ（Ｆｉｂｅｒ　Ｔｏ　Ｔｈｅ　Ｈｏｍｅ）等の高速なアクセス回線を容易に利用可能となってきている。多くのユーザが高速なアクセス回線を利用可能となったことで、従来の低速な回線では不可能だった映像の配信サービスを提供するサービス事業者も登場している。
【０００３】
このような映像配信サービスでは、現在、インタネットの高速なバックボーンに任せてベストエフォートによって提供されているが、高画質映像配信を実用化するためには、配信経路におけるＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）保証（帯域確保、遅延保証）が必要である。また、ビジネスとして映像配信をユーザに提供するためにも、映像配信時におけるＱｏＳ保証は不可欠である。
【０００４】
現在、インタネットにおいてＱｏＳ保証のために用いられるプロトコルとしてＲＳＶＰが標準化されている。ＲＳＶＰではデータを送受信する両ホスト間でＲＳＶＰメッセージをやりとりすることで、ＲＳＶＰメッセージが通過するルータの資源を次々に予約していくプロトコルである。
【０００５】
上記のＲＳＶＰの手順を図１５に示す。ＲＳＶＰ手順においては、図１５に示すように、ＲＳＶＰ認識ソースホスト３４がトラヒック特性を示すＰａｔｈメッセージをＲＳＶＰ認識宛先ホスト３１に送信する。Ｐａｔｈメッセージは経路上のスイッチ３３，３２（ＲＳＶＰ対応ルータ）及びバックボーンネットワーク（ＲＳＶＰネットワーク）２００を経由してＲＳＶＰ認識宛先ホスト３１に到達する。
【０００６】
ＲＳＶＰ認識宛先ホスト３１はＰａｔｈメッセージを受信すると、所望のＱｏＳを示すＲｅｓｖ（ｒｅｓｅｒｖｅ）メッセージを上記の経路上の直前のスイッチ３２に送信する。スイッチ３２はＲｅｓｖメッセージに示されたＱｏＳを保証するために、スイッチ３２内の資源を予約し、さらにＲｅｓｖメッセージを上記の経路上の前段のスイッチ３３に転送する。このスイッチ３３でもＲｅｓｖメッセージに示されたＱｏＳを保証するために、スイッチ３３内の資源を予約し、さらにＲｅｓｖメッセージをＲＳＶＰ認識ソースホスト３４に転送する。ＲｅｓｖメッセージがＲＳＶＰ認識ソースホスト３４に到達した時点で、Ｒｅｓｖメッセージに示されたＱｏＳを保証するための経路上の資源がすべて予約される。
【０００７】
ＲＳＶＰ認識宛先ホスト３１に対しては、ＲＳＶＰ認識ソースホスト３４から高画質映像等のデータが上述した処理で予約された資源を用いて送られるが、それらのデータの送信が終了すると、Ｐａｔｈ　Ｔｅａｒメッセージが上記の経路上のスイッチ３３，３２及びバックボーンネットワーク２００を経由してＲＳＶＰ認識宛先ホスト３１に送られることで、スイッチ３３，３２において上記の予約された資源が解放される。尚、ＲＳＶＰ認識ソースホスト３４からはＰａｔｈメッセージが予め設定された所定間隔で送られており、それに応じてＲＳＶＰ認識宛先ホスト３１からＲｅｓｖメッセージが所定間隔で返送される。したがって、上記のＰａｔｈ　Ｔｅａｒメッセージが途中で失われた場合、スイッチ３３，３２では所定間隔を過ぎてもＰａｔｈメッセージが送られてこなければ、予約解除と判断して上記の予約された資源を解放する。
【０００８】
しかしながら、ＲＳＶＰは処理負荷の大きなプロトコルであり、インタネット上のルータでは、一般に、ＲＳＶＰがサポートされていない。また、インタネット上でＲＳＶＰがサポートされていないために、既存の通信ホストにはＲＳＶＰが実装されていない場合が多い。但し、今後は、上述した映像配信に代表されるＱｏＳ保証を必要とするアプリケーションをサービスするために、特定の範囲［１つのＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）内部等］においてＲＳＶＰルータが配置されることが予想される。この時、問題となるのがＲＳＶＰに対応していない通信ホストである。
【０００９】
ＲＳＶＰルータがネットワーク上に配置されても、データを送受信する通信ホストがＲＳＶＰを実装していなければ、ＲＳＶＰの効果を得ることができない。ＲＳＶＰに対応していない通信ホストでも、ＲＳＶＰネットワークのＱｏＳ保証効果を得られる手法が望まれている。ＲＳＶＰに対応していない通信ホストでも、ＲＳＶＰネットワークのＱｏＳ保証効果を得られるシステム例としては、ＲＳＶＰプロキシサービスのシステムがある（例えば、特許文献１参照）。
【００１０】
上記のＲＳＶＰプロキシサービスは、図１６に示すように、ＲＳＶＰ非認識宛先ホスト３５と、スイッチ３２，３３と、ＲＳＶＰ認識ソースホスト３４と、バックボーンネットワーク（ＲＳＶＰネットワーク）２００とから構成されている。このような構成のＲＳＶＰプロキシサービスでは、ＲＳＶＰ認識ソースホスト３４がデータパケットの送信経路のＱｏＳを確保するために、ＲＳＶＰのＰａｔｈメッセージをＲＳＶＰ非認識宛先ホスト３５に向けて送信する。
【００１１】
ＲＳＶＰ認識ソースホスト３４から送信されたＰａｔｈメッセージは、まずスイッチ３３に転送され、さらにバックボーンネットワーク（ＲＳＶＰネットワーク）２００を介してスイッチ３２に転送される。この時、スイッチ３２には予め特定の宛先に対するＰａｔｈメッセージを受信した場合に、ＲＳＶＰ受信側ホストプロキシ機能が動作するように設定されている。
【００１２】
Ｐａｔｈメッセージを受信したスイッチ３２はＰａｔｈメッセージの宛先を確認し、スイッチ３２のＲＳＶＰ受信側ホストプロキシ機能を動作させるかどうかを判断する。ＲＳＶＰ受信側ホストプロキシ機能を動作させると判断された場合、スイッチ３２はＰａｔｈメッセージをＲＳＶＰ非認識宛先ホスト３５に転送することなく、代わりにスイッチ３２がＲＳＶＰ認識ソースホスト３４側に向かってＲｅｓｖメッセージを送信することで、ＲＳＶＰ認識ソースホスト３４までの経路の資源を予約し、ＲＳＶＰ認識ソースホスト３４から送信されるデータパケットのＱｏＳを保証している。
【００１３】
【特許文献１】
特開２００１−３５２３４７号公報（第４−５頁、図１）
【００１４】
【発明が解決しようとする課題】
しかしながら、上述した従来のＲＳＶＰのネットワークでは、ＲＳＶＰ受信側ホストプロキシ機能を動作させるための条件として宛先アドレスを使用しているので、予め対象となるアドレスをスイッチ３２に登録する必要がある。
【００１５】
そのため、従来のＲＳＶＰのネットワークでは、データ受信側ネットワークにＲＳＶＰに対応していない通信ホストと、ＲＳＶＰに対応している通信ホストとが多数混在している場合、スイッチ３２に登録すべき宛先アドレスが増大し、管理が煩雑になるという問題がある。特に、配置換え等で通信ホストのアドレスが変更になる場合には、その都度、スイッチ３２に登録しているアドレスも変更しなければならない。
【００１６】
そこで、本発明の目的は上記の問題点を解消し、受信ホストがＲＳＶＰに対応していないことを自動的に検出して代理でＲＳＶＰ手順を実行することができるＲＳＶＰ代理応答ルータ、ＲＳＶＰ代理応答システム及びそれに用いるＲＳＶＰ代理応答方法を提供することにある。
【００１７】
【課題を解決するための手段】
本発明によるＲＳＶＰ代理応答ルータは、送信ホストから受信ホストにデータパケットを送信する際に、送信経路でのサービス品質の保証を得るために前記送信ホストから送信される確認メッセージを前記受信ホストに転送するＲＳＶＰ代理応答ルータであって、
前記確認メッセージに対する前記受信ホストからの応答メッセージを監視しかつ当該応答メッセージを基に前記受信ホストがＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に対応する機器か否かを判別する判別手段と、前記ＲＳＶＰに対応しない機器と判別された受信ホストの代理で前記ＲＳＶＰの手順を実行して前記送信ホストとの間の経路上の資源を予約する代理ＲＳＶＰ制御手段とを備えている。
【００１８】
本発明によるＲＳＶＰ代理応答システムは、送信ホストから受信ホストにデータパケットを送信する際に、送信経路でのサービス品質の保証を得るために前記送信ホストから送信される確認メッセージを前記送信ホストと前記受信ホストとの間に配設されたＲＳＶＰ代理応答ルータによって前記受信ホストに転送するＲＳＶＰ代理応答システムであって、
前記確認メッセージに対する前記受信ホストからの応答メッセージを監視しかつ当該応答メッセージを基に前記受信ホストがＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒ　Ｖａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に対応する機器か否かを判別する判別手段と、前記ＲＳＶＰに対応しない機器と判別された受信ホストに代わって前記ＲＳＶＰの手順を実行して前記送信ホストとの間の経路上の資源を予約する代理ＲＳＶＰ制御手段とを前記ＲＳＶＰ代理応答ルータに備えている。
【００１９】
本発明によるＲＳＶＰ代理応答方法は、送信ホストから受信ホストにデータパケットを送信する際に、送信経路でのサービス品質の保証を得るために前記送信ホストから送信される確認メッセージを前記送信ホストと前記受信ホストとの間に配設されたＲＳＶＰ代理応答ルータによって前記受信ホストに転送するＲＳＶＰ代理応答方法であって、前記ＲＳＶＰ代理応答ルータが、前記確認メッセージに対する前記受信ホストからの応答メッセージを監視し、当該応答メッセージを基に前記受信ホストがＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）に対応しない機器であると判別された時に前記受信ホストに代わって前記ＲＳＶＰの手順を実行して前記送信ホストとの間の経路上の資源を予約している。
【００２０】
すなわち、本発明のＲＳＶＰ代理応答システムは、ＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）ネットワークにおいてＲＳＶＰに対応していない通信ホストを自動的に検出し、当該ホストの代わりにＲＳＶＰ手順を実行して経路上の資源を予約することができる構成を提供するものである。
【００２１】
より具体的に説明すると、本発明のＲＳＶＰ代理応答システムでは、ＲＳＶＰ代理応答ルータが、上述した一般のＲＳＶＰ手順を実行するＲＳＶＰ制御部と、代理でＲＳＶＰ手順を実行する代理ＲＳＶＰ制御部と、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）の「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅ（宛先到達不能）メッセージ」を検出し、送信したＰａｔｈメッセージに対するＩＣＭＰメッセージであるかどうかを判断するＩＣＭＰ検出部とを有している。
【００２２】
ＲＳＶＰ送信ホストが非ＲＳＶＰ受信ホスト（ＲＳＶＰに対応していない受信ホスト）に対してデータパケットを送信する場合、ＲＳＶＰ送信ホストは非ＲＳＶＰ受信ホストに向かってＲＳＶＰのＰａｔｈメッセージを送信する。ＰａｔｈメッセージはＲＳＶＰネットワークを経由してＲＳＶＰ代理応答ルータに到達し、ＲＳＶＰ制御部によって通常のＲＳＶＰの処理を実施された後、非ＲＳＶＰルータ経由で非ＲＳＶＰ受信ホストに到達する。
【００２３】
非ＲＳＶＰ受信ホストはＲＳＶＰに対応していないため、受信したＰａｔｈメッセージに対してＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅ」メッセージをＰａｔｈメッセージの送信元であるＲＳＶＰ送信ホストに送信する。送信されたＩＣＭＰメッセージはＲＳＶＰ代理応答ルータを経由する際に、ＩＣＭＰ検出部によって捕捉されて、ＲＳＶＰ代理応答ルータが送信したＰａｔｈメッセージに対するＩＣＭＰメッセージであるかどうかが判断される。
【００２４】
Ｐａｔｈメッセージに対するＩＣＭＰメッセージであった場合、ＩＣＭＰ検出部は非ＲＳＶＰ受信ホストがＲＳＶＰに対応していなかったと判断し、代理ＲＳＶＰ制御部にＲＳＶＰ手順の代理実行を指示する。代理ＲＳＶＰ制御部は受信ホストの代わりにＰａｔｈメッセージに対するＲｅｓｖメッセージを生成し、ＲＳＶＰ送信ホストに向かう経路上の次ホップルータに送信する。
【００２５】
ＲｅｓｖメッセージはＲＳＶＰネットワークの経路上の資源を予約してＲＳＶＰ送信ホストに到達する。この時点で、ＲＳＶＰ送信ホストが非ＲＳＶＰ受信ホストにデータパケットを送信するための、ＲＳＶＰ代理応答ルータからＲＳＶＰ送信ホストまでの経路上の資源が予約できたことになる。
【００２６】
このようにして、本発明のＲＳＶＰ代理応答システムでは、ＲＳＶＰ代理応答ルータ上に非ＲＳＶＰ受信ホストのアドレスを明示的に設定することなく、自動的に非ＲＳＶＰ受信ホストの存在を検出し、非ＲＳＶＰ受信ホストの代わりにＲＳＶＰ手順を実行して経路上の資源を予約することが可能となる。
【００２７】
つまり、本発明のＲＳＶＰ代理応答システムでは、通信ホストから送信されるＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」をＲＳＶＰ代理応答ルータで検出することで、通信ホストがＲＳＶＰに対応しているか否かを自動的に検出しているため、データ受信側ネットワークにＲＳＶＰに対応していない通信ホストと、ＲＳＶＰに対応している通信ホストとが多数混在している場合に、ＲＳＶＰ代理応答ルータ自身に個々の通信ホストのアドレスを登録しなくても、ＲＳＶＰに対応していない通信ホストに対してのみ代理でＲＳＶＰ手順が実行可能となる。
【００２８】
【発明の実施の形態】
次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例によるＲＳＶＰ（ＲｅＳｏｕｒｃｅ　ｒｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）代理応答システムの構成を示すブロック図である。図１において、本発明の一実施例によるＲＳＶＰ代理応答システムはＲＳＶＰ代理応答ルータ１と、非ＲＳＶＰ／ＲＳＶＰ混在ネットワーク２と、ＲＳＶＰ送信ホスト３と、ＲＳＶＰネットワーク１００とから構成されている。
【００２９】
ＲＳＶＰ代理応答ルータ１はルータ装置であり、ＲＳＶＰを使用可能なＲＳＶＰネットワーク１００と、ＲＳＶＰ／非ＲＳＶＰ混在ネットワーク２とに接続されている。ＲＳＶＰ送信ホスト３はＲＳＶＰに対応しているパーソナルコンピュータ（以下、パソコンとする）やサーバ等であり、ＲＳＶＰネットワーク１００に接続されている。
【００３０】
ＲＳＶＰ／非ＲＳＶＰ混在ネットワーク２はＲＳＶＰに対応してないパソコン等の非ＲＳＶＰ受信ホスト２１と、ＲＳＶＰに対応していないルータ装置である非ＲＳＶＰルータ２３と、ＲＳＶＰに対応しているパソコン等のＲＳＶＰ受信ホスト２２と、ＲＳＶＰに対応しているルータ装置であるＲＳＶＰルータ２４とから構成されている。
【００３１】
非ＲＳＶＰ受信ホスト２１は非ＲＳＶＰルータ２３に接続されており、ＲＳＶＰ受信ホスト２２はＲＳＶＰ受信ルータ２４に接続されている。また、非ＲＳＶＰルータ２３、ＲＳＶＰルータ２４、ＲＳＶＰ代理応答ルータ１はそれぞれ共通の物理リンクによって互いに接続されている。
【００３２】
図２は図１のＲＳＶＰ代理応答ルータ１の構成を示すブロック図である。図２において、ＲＳＶＰ代理応答ルータ１はインタフェース部１１，１２と、ＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御部１３と、ＲＳＶＰ制御部１６と、Ｐａｔｈメッセージ記憶部１７と、ルーティング部１８と、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）検出部１９と、代理ＲＳＶＰ制御部２０とから構成されている。
【００３３】
インタフェース部１１はＲＳＶＰネットワーク１００との間でデータパケットやＲＳＶＰメッセージの送受信を行う。インタフェース部１２はＲＳＶＰ／非ＲＳＶＰ混在ネットワーク２との間でデータパケットやＲＳＶＰメッセージ、ＩＣＭＰメッセージの送受信を行う。
【００３４】
ＱｏＳ制御部１３はＱｏＳの対象となるデータパケットを分類するクラシファイア１４と、指定されたＱｏＳを実現するためにデータパケットの送信順序を制御するパケットスケジューラ１５とから構成されている。このＱｏＳ制御部１３はインタフェース部１１及びインタフェース部１２経由で送受信されるデータパケットに、指定されたＱｏＳを適用する。
【００３５】
ＲＳＶＰ制御部１６は通常のＲＳＶＰ手順を実行する。Ｐａｔｈメッセージ記憶部１７はＲＳＶＰ制御部１６によって設定されて受信したＰａｔｈメッセージの内容を記憶しておく。ルーティング部１８は受信したデータパケットの転送経路を決定する。
【００３６】
ＩＣＭＰ検出部１９はＩＣＭＰメッセージを捕捉してＲＳＶＰ制御部１６が転送したＰａｔｈメッセージに対するＩＣＭＰメッセージかどうかを判断する。代理ＲＳＶＰ制御部２０はＩＣＭＰ検出部１９の指示によってＰａｔｈメッセージに対するＲｅｓｖメッセージを受信ホストの代わりに生成する。
【００３７】
上記のＲＳＶＰ代理応答ルータ１はＩＣＭＰ検出部１９を有する点で、従来のＲＳＶＰルータと異なる。ＩＣＭＰ検出部１９はＩＣＭＰメッセージの内容を解析して動作するが、通常のＲＳＶＰルータはＩＣＭＰメッセージを最終宛先に転送するのみで、その内容まで解析することはない。
【００３８】
上記の構成要素はそれぞれ以下のように動作する。まず、インタフェース部１１はＲＳＶＰネットワーク１００から受信したデータパケットやＲＳＶＰメッセージをＱｏＳ制御部１３に転送する。また、インタフェース部１１はＱｏＳ制御部１３から渡されたデータパケットやＲＳＶＰメッセージをＲＳＶＰネットワーク１００に送信する。
【００３９】
インタフェース部１２は非ＲＳＶＰ／ＲＳＶＰ混在ネットワーク２から受信したデータパケットやＲＳＶＰメッセージをＱｏＳ制御部１３に転送する。また、インタフェース部１２はＱｏＳ制御部１３から渡されたデータパケットやＲＳＶＰメッセージを非ＲＳＶＰ／ＲＳＶＰ混在ネットワーク２に送信する。
【００４０】
ＱｏＳ制御部１３はインタフェース部１１及びインタフェース部１２から受信したデータパケットやＲＳＶＰメッセージをルーティング部１８に転送する。また、ＱｏＳ制御部１３はルーティング部１８から各インタフェース部１１，１２宛てに転送されたデータパケットやＲＳＶＰメッセージに対して必要に応じてＱｏＳ制御を実施し、各インタフェース部１１，１２に転送する。さらに、ＱｏＳ制御部１３はＲＳＶＰ制御部１６及び代理ＲＳＶＰ制御部２０からＱｏＳ制御の指示を受けて、適用するＱｏＳ制御の内容を変更する。
【００４１】
クラシファイア１４はＱｏＳ制御部１３を構成する要素であり、ＱｏＳ制御部１３に入力されるデータパケットやＲＳＶＰメッセージをＱｏＳクラスに分類する。ＱｏＳクラスの分類の方法はＲＳＶＰ制御部１６及び代理ＲＳＶＰ制御部２０から指示される。
【００４２】
パケットスケジューラ１５もＱｏＳ制御部１３を構成する要素であり、クラシファイア１４でＱｏＳクラスに分類されたデータパケットやＲＳＶＰメッセージが、指定されたＱｏＳにしたがってＱｏＳ制御部１３から出力されるように、パケットの送信順序を管理する。適用すべきＱｏＳはＲＳＶＰ制御部１６及び代理ＲＳＶＰ制御部２０から指示される。
【００４３】
ＲＳＶＰ制御部１６はルーティング部１８を介してＲＳＶＰメッセージの送受信を行い、上述した従来のＲＳＶＰの手順、つまり一般的なＲＳＶＰの手順を実行する。ＲＳＶＰ制御部１６はＰａｔｈメッセージを受信した場合、受信したＰａｔｈメッセージの内容をＰａｔｈメッセージ記憶部１７に記録したうえで、本来の宛先である受信ホストにＰａｔｈメッセージを転送する。尚、ＲＳＶＰ制御部１６はＰａｔｈメッセージをＰａｔｈメッセージ記憶部１７に記録する際に、Ｐａｔｈメッセージの内容だけでなく、Ｐａｔｈメッセージの配送に使用されているＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）ヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、送信元アドレスフィールド、宛先アドレスフィールドをも合わせて記録する。
【００４４】
また、ＲＳＶＰ制御部１６はＲｅｓｖメッセージを受信した場合、Ｒｅｓｖメッセージによって示されるＱｏＳを実現するために資源の予約を行う。すなわち、ＲＳＶＰ制御部１６はＱｏＳ制御部１３にＱｏＳクラスの分類と適用するＱｏＳを指示する。ＲＳＶＰ制御部１６はＱｏＳ制御部１３への指示が完了したら、次ホップルータでの資源を予約するためにＲｅｓｖメッセージを次ホップルータに送信する。
【００４５】
Ｐａｔｈメッセージ記憶部１７はＲＳＶＰ制御部１６が扱ったＰａｔｈメッセージを記憶しておく。Ｐａｔｈメッセージ記憶部１７はＰａｔｈメッセージと同時に、Ｐａｔｈメッセージを配送する際に使用されていたＩＰヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、送信元アドレスフィールド、宛先アドレスフィールドの値も記憶する。
【００４６】
ＩＰヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドはＩＰパケットが途中経路で分割された場合に、分割されたそれぞれのパケットを識別するために使用される値であり、ＩＰパケットを送信したホストによって設定される。ＩＰパケットの送信ホストは同一の宛先に送信する際に異なるパケットに同じ値が設定されないように、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎの値を設定するため、ＩＰパケットの送信元アドレス、宛先アドレス、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎの値を用いれば、ＩＰパケットを一意に識別することができる。
【００４７】
これによって、後述するＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」の受信時に、ＩＣＭＰメッセージに含まれるＩＰヘッダ情報とＰａｔｈメッセージ記憶部１７に記録しておいた値とを比較することで、どのＰａｔｈメッセージに対するＩＣＭＰメッセージなのかを判断することができる。
【００４８】
ルーティング部１８はデータパケットやＲＳＶＰメッセージ等を受け取って、その宛先アドレスや宛先ポートにしたがって適切な宛先（インタフェース部１１やインタフェース部１２、及びＲＳＶＰ制御部１６、ＩＣＭＰ検出部１９等）に配送する。
【００４９】
ＩＣＭＰ検出部１９はルーティング部１８に入力されるデータパケットを監視する。ＩＣＭＰ検出部１９は入力されるパケットの中にＩＣＭＰメッセージの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」を発見した場合、そのＩＣＭＰメッセージに含まれるＩＰヘッダ情報と、Ｐａｔｈメッセージ記憶部１７に記録してあるＩｄｅｎｔｉｆｉｃａｔｉｏｎ、送信元アドレス、宛先アドレスの値とを比較して一致したものを探す。
【００５０】
ＩＣＭＰ検出部１９は一致したものがなかった場合、無関係と判断してＩＣＭＰメッセージを処理をルーティング部１８に戻し、そのまま当該ＩＣＭＰメッセージの処理をルーティング部１８に任せる。ＩＣＭＰ検出部１９は一致するものがあった場合、ＲＳＶＰ制御部１６が送信したＰａｔｈメッセージに対してＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」が返されたことになり、受信ホストがＲＳＶＰに対応していないことがわかる。
【００５１】
この場合、ＩＣＭＰ検出部１９は当該ＩＣＭＰメッセージを破棄し、代わりに当該Ｐａｔｈメッセージ情報を代理ＲＳＶＰ制御部２０に通知し、代理ＲＳＶＰ制御部２０に対して受信ホストの代わりに、上記のＲＳＶＰの手順を実行するように依頼する。
【００５２】
代理ＲＳＶＰ制御部２０はＩＣＭＰ検出部１９からの指示で、指定されたＰａｔｈメッセージに対して本来の受信ホストの代わりに、上記のＲＳＶＰの手順を実行し、ＲｅｓｖメッセージをＲＳＶＰ送信ホスト３までの経路上の次ホップルータに送信する。同時に、代理ＲＳＶＰ制御部２０はＱｏＳ制御部１３に当該通信に対して適用すべきＱｏＳを通知し、ＲＳＶＰ代理応答ルータ１内の資源をも確保する。
【００５３】
上記の図１を参照して本発明の一実施例によるＲＳＶＰ代理応答システムの動作について説明する。まず、ＲＳＶＰ送信ホスト３は非ＲＳＶＰ受信ホスト２１にデータパケットを送信する際に、送信経路でのＱｏＳの保証を得るためにＲＳＶＰのＰａｔｈメッセージを非ＲＳＶＰ受信ホスト２１宛に送信する。ＲＳＶＰ送信ホスト３から送信されたＰａｔｈメッセージはＲＳＶＰネットワーク１００を経由してＲＳＶＰ代理応答ルータ１に到達する。ここまでは標準のＲＳＶＰの動作と同じである。
【００５４】
ＲＳＶＰ代理応答ルータ１はＰａｔｈメッセージを受信すると、当該メッセージを非ＲＳＶＰルータ２３に転送する。非ＲＳＶＰルータ２３はさらにそのＰａｔｈメッセージを最終的な宛先である非ＲＳＶＰ受信ホスト２１に転送する。非ＲＳＶＰ受信ホスト２１はＲＳＶＰに対応していないため、ＲＳＶＰのＰａｔｈメッセージを受信することができない。
【００５５】
ＩＰでは対応していないプロトコルのＩＰパケットを受信した場合に、ＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」の「Ｐｒｏｔｏｃｏｌ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」をオリジナルのメッセージの送信元に送信するように定められているため、非ＲＳＶＰ受信ホスト２１はＲＳＶＰ送信ホスト３に対してＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」を送信する。
【００５６】
非ＲＳＶＰ受信ホスト２１から送信されたＩＣＭＰメッセージは非ＲＳＶＰルータ２３を経由してＲＳＶＰ代理応答ルータ１に到達する。この時、仮にＲＳＶＰ代理応答ルータ１が通常のＲＳＶＰルータであった場合には、ＩＣＭＰメッセージをさらにＲＳＶＰネットワーク１００に転送するので、ＩＣＭＰメッセージが最終的にＲＳＶＰ送信ホスト３にまで到達し、ＲＳＶＰネットワーク１００上の資源の予約が行われない。
【００５７】
これに対し、ＲＳＶＰ代理応答ルータ１は自装置が非ＲＳＶＰ受信ホスト２１に転送したＰａｔｈメッセージに対するＩＣＭＰメッセージを受信すると、そのＩＣＭＰメッセージから非ＲＳＶＰ受信ホスト２１がＲＳＶＰに対応していないと判断し、ＲＳＶＰ代理応答ルータ１自身が非ＲＳＶＰ受信ホスト２１の代わりにＲＳＶＰのＲｅｓｖメッセージを生成してＲＳＶＰネットワーク１００に送信する。
【００５８】
送信されたＲｅｓｖメッセージはＲＳＶＰネットワーク１００を経由してＲＳＶＰ送信ホスト３に到達する。Ｒｅｓｖメッセージは経路上の資源を予約するためのメッセージなので、ＲｅｓｖメッセージがＲＳＶＰ送信ホスト３に到達した時点で、ＲＳＶＰ代理応答ルータ１からＲＳＶＰ送信ホスト３までの区間における経路上の資源を予約することができたことになる。
【００５９】
ＲＳＶＰ送信ホスト３はＲｅｓｖメッセージを受信することで、経路上の資源が予約されたことを知ることができる。これ以降、ＲＳＶＰ送信ホスト３が非ＲＳＶＰ受信ホスト２１に送信するデータパケットは、ＲＳＶＰ送信ホスト３からＲＳＶＰ代理応答ルータ１までの区間においては他の通信の影響を受けることなく、安定して送信することができる。
【００６０】
図３は図１のＲＳＶＰ送信ホスト３が非ＲＳＶＰ受信ホスト２１にＲＳＶＰのＰａｔｈメッセージを送信した場合の動作を示すシーケンスチャートである。これら図１及び図３を参照してＲＳＶＰ送信ホスト３が非ＲＳＶＰ受信ホスト２１にＲＳＶＰのＰａｔｈメッセージを送信した場合の動作について説明する。
【００６１】
ＲＳＶＰ送信ホスト３から送信されたＰａｔｈメッセージはＲＳＶＰネットワーク１００、ＲＳＶＰ代理応答ルータ１，非ＲＳＶＰルータ２３を経由して非ＲＳＶＰ受信ホスト２１に到達する。その後、非ＲＳＶＰルータ２１からＩＣＭＰメッセージが送信され、非ＲＳＶＰルータ２３を経由してＲＳＶＰ代理応答ルータ１に到達する。ここで、ＲＳＶＰ代理応答ルータ１がＲｅｓｖメッセージを送信するため、それ以降の経路の資源が予約され、最終的にはＲＳＶＰ送信ホスト３からＲＳＶＰ代理応答ルータ１までの区間においてのＱｏＳが保証される。
【００６２】
続いて、ＲＳＶＰ送信ホスト３がＲＳＶＰ受信ホスト２２にデータパケットを送信する場合の動作について図１を用いて説明する。ＲＳＶＰ送信ホスト３が送信したＰａｔｈメッセージがＲＳＶＰ代理応答ルータ１に到達するまでの手順は、上記の場合と同様に、標準のＲＳＶＰの動作と同じ動作となる。
【００６３】
ＲＳＶＰ代理応答ルータ１はＰａｔｈメッセージを受信すると、当該Ｐａｔｈメッセージをその宛先にしたがってＲＳＶＰルータ２４に転送する。ＲＳＶＰルータ２４はさらにそのＰａｔｈメッセージを最終的な宛先であるＲＳＶＰ受信ホスト２２に転送する。ＲＳＶＰ受信ホスト２２はＲＳＶＰに対応しているため、Ｐａｔｈメッセージを受信すると、自らＲｅｓｖメッセージを送信することで、経路上の資源の予約を実行する。ＲＳＶＰ受信ホスト２２から送信されたＲｅｓｖメッセージはＲＳＶＰルータ２４に到達する。
【００６４】
ＲＳＶＰルータ２４はＲｅｓｖメッセージを受信すると、Ｒｅｓｖメッセージに示されるＱｏＳを実現するために、自ルータ内の資源を確保し、ＲｅｓｖメッセージをＲＳＶＰ代理応答ルータ１に転送する。ＲＳＶＰ代理応答ルータ１は上記のＲＳＶＰルータ２４と同様に、Ｒｅｓｖメッセージに示されるＱｏＳを実現するための資源を確保し、ＲｅｓｖメッセージをＲＳＶＰネットワーク１００に転送する。
【００６５】
これ以降の動作は上述した非ＲＳＶＰ受信ホスト２１における動作と同じである。すなわち、ＲｅｓｖメッセージはＲＳＶＰネットワーク１００を経由しながらその中の資源を予約し、最終的にＲＳＶＰ送信ホスト３に到達する。この時点で、ＲＳＶＰ送信ホスト３からＲＳＶＰ受信ホスト２２に至る経路上のすべての資源が予約され、経路上のすべての区間でＱｏＳが保証される。
【００６６】
図４は図１のＲＳＶＰ送信ホスト３がＲＳＶＰ受信ホスト２２にＲＳＶＰのＰａｔｈメッセージを送信した場合の動作を示すシーケンスチャートである。これら図１及び図４を参照してＲＳＶＰ送信ホスト３がＲＳＶＰ受信ホスト２２にＲＳＶＰのＰａｔｈメッセージを送信した場合の動作について説明する。
【００６７】
ＲＳＶＰ送信ホスト３から送信されたＰａｔｈメッセージはＲＳＶＰネットワーク１００、ＲＳＶＰ代理応答ルータ１、ＲＳＶＰルータ２４を経由してＲＳＶＰ受信ホスト２２に到達する。その後、ＲＳＶＰルータ２２からＲｅｓｖメッセージが送信され、ＲＳＶＰルータ２４、ＲＳＶＰ代理応答ルータ１、ＲＳＶＰネットワーク１００のそれぞれの資源を予約しながら、ＲＳＶＰ送信ホスト３に到達する。したがって、この場合にはＲＳＶＰ送信ホスト３からＲＳＶＰ受信ホスト２２までのすべての区間においてのＱｏＳが保証される。
【００６８】
このように、本発明のＲＳＶＰ代理応答システムでは、個々の受信ホストがＲＳＶＰに対応しているか否かを明示的にＲＳＶＰ代理応答ルータ１に登録することなく、ＲＳＶＰ代理応答ルータ１で自動的にＲＳＶＰに対応しているか否かを検出し、ＲＳＶＰに対応していなかった場合にのみＲＳＶＰに代理応答機能を動作させることが可能である。
【００６９】
図５（ａ）はＩＰヘッダのフォーマットを示す図であり、図５（ｂ）はＲＳＶＰプロトコルのフォーマットを示す図である。これら図５（ａ），（ｂ）に示すＩＰヘッダ及びＲＳＶＰプロトコルのフォーマットはそれぞれＲＦＣ（Ｒｅｑｕｅｓｔ　Ｆｏｒ　Ｃｏｍｍｅｎｔｓ）７９１，ＲＦＣ２２０５によって定義されている。
【００７０】
図６は図１のＲＳＶＰ送信ホスト３が非ＲＳＶＰ受信ホスト２１に送信したＰａｔｈメッセージの構成例を示す図である。図６において、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、Ｐｒｏｔｏｃｏｌフィールド、送信元アドレス、宛先アドレス、Ｍｅｓｓａｇｅ　Ｔｙｐｅが本発明に関連する部分である。
【００７１】
ＩＰヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドには「１２３４５」が設定されている。このＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドはパケットの転送中にパケットの分割が発生した場合に、分割されたそれぞれのパケットを識別するために使用される値であり、ＩＰパケットを送信したホストによって設定される。
【００７２】
ＰｒｏｔｏｃｏｌフィールドにはＲＳＶＰを示す「４６」が設定されており、送信元アドレス、宛先アドレスにはそれぞれＲＳＶＰ送信ホスト３、非ＲＳＶＰ受信ホスト２１のアドレスが設定されている。また、ＲＳＶＰプロトコルヘッダ部のＭｅｓｓａｇｅ　ＴｙｐｅにはＰａｔｈメッセージを示す「１」が設定されている。
【００７３】
図７は図２のＰａｔｈメッセージ記憶部１７にＰａｔｈメッセージを記録した後の構成例を示す図である。図７において、Ｐａｔｈメッセージ記憶部１７には上記のように、Ｐａｔｈメッセージと、ＩＰヘッダの送信元アドレス「ＲＳＶＰ送信ホスト３のアドレス」、宛先アドレス「非ＲＳＶＰ受信ホスト２１のアドレス」、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールドの値「１２３４５」が記憶されている。
【００７４】
図８はＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」における「Ｐｒｏｔｏｃｏｌ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」のフォーマットを示す図である。図８において、ＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」にはＴｙｐｅ（＝３）、Ｃｏｄｅ（＝２）、チェックサムと、オリジナルのＩＰヘッダの内容と、オリジナルのデータグラムの先頭の８バイトとが含まれる。
【００７５】
図９は図１の非ＲＳＶＰ受信ホスト２１から送信されるＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」の構成例を示す図である。図９において、Ｔｙｐｅフィールド、Ｃｏｄｅフィールド、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、Ｐｒｏｔｏｃｏｌフィールド、送信元アドレス、宛先アドレス、Ｍｅｓｓａｇｅ　Ｔｙｐｅが本発明に関連する部分である。
【００７６】
ＩＣＭＰのＴｙｐｅフィールドには「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」を示す「３」、Ｃｏｄｅフィールドには「Ｐｒｏｔｏｃｏｌ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」を示す「２」がそれぞれ設定される。オリジナルＩＰヘッダの部分はＰａｔｈメッセージのＩＰヘッダがそのまま設定される。また、オリジナルのペイロード部分にはＲＳＶＰプロトコルの先頭８バイトが設定される。尚、上記の例はＩＰｖ４の例を示しているが、ＩＰｖ６ではメッセージの名称が異なっているが、本発明を適用することは可能である。
【００７７】
図１０は図２のＲＳＶＰ代理応答ルータ１のＰａｔｈメッセージ受信処理を示すフローチャートであり、図１１は図２のＲＳＶＰ代理応答ルータ１のＩＣＭＰメッセージ受信処理を示すフローチャートである。これら図２と図５〜図１１とを参照してＲＳＶＰ代理応答ルータ１の動作について説明する。
【００７８】
送信ホスト３から送信されたＲＳＶＰのＰａｔｈメッセージはＲＳＶＰネットワーク１００を経由して、ＲＳＶＰ代理応答ルータ１のインタフェース部１１に到達する。インタフェース部１１に到達したＰａｔｈメッセージはＱｏＳ制御部１３を経由してルーティング部１８に転送され、さらにＲＳＶＰ制御部１６に渡される。
【００７９】
ＲＳＶＰ制御部１６は図６に示すＰａｔｈメッセージを受信すると（図１０ステップＳ１）、通常のＲＳＶＰの手順にしたがって処理した後（図１０ステップＳ２）、受信したＰａｔｈメッセージをＰａｔｈメッセージ記憶部１７に記録する（図１０ステップＳ３）。この時、Ｐａｔｈメッセージの転送に使用されていたＩＰヘッダの送信元アドレス、宛先アドレス、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎフィールドの値も同時に記録する。
【００８０】
ＲＳＶＰ制御部１６はＰａｔｈメッセージ記憶部１７にＰａｔｈメッセージの内容を記録すると、Ｐａｔｈメッセージをルーティング部１８に転送する。ルーティング部１８はＰａｔｈメッセージをその宛先アドレスにしたがって、インタフェース部１２に転送し、Ｐａｔｈメッセージが非ＲＳＶＰ／ＲＳＶＰ混在ネットワーク２に送出される（図１０ステップＳ４）。
【００８１】
Ｐａｔｈメッセージが非ＲＳＶＰ受信ホスト２１に到達すると、非ＲＳＶＰ受信ホスト２１がＲＳＶＰに対応していないため、上述したように、非ＲＳＶＰ受信ホスト２１からＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」が送信される。
【００８２】
非ＲＳＶＰ受信ホスト２１から送信されたＩＣＭＰメッセージは、非ＲＳＶＰルータ２３を経由してＲＳＶＰ代理応答ルータ１のインタフェース部１２に到達する（図１１ステップＳ１１）。インタフェース部１２に到達したＰａｔｈメッセージはＱｏＳ制御部１３を経由してルーティング部１８に転送される。
【００８３】
ＩＣＭＰメッセージがルーティング部１８に到達すると、ＩＣＭＰ検出部１９によってＩＣＭＰメッセージ内のオリジナルＩＰヘッダの部分とＰａｔｈメッセージ記憶部１７に記録されている値とが比較される（図１１ステップＳ１２）。図７及び図９を参照すると、当該ＩＣＭＰメッセージに含まれるＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールド、送信元アドレスフィールド、宛先アドレスフィールドの値が、Ｐａｔｈメッセージ記憶部１７に記録されているそれぞれの値と一致している。したがって、当該ＩＣＭＰメッセージはＲＳＶＰ代理応答ルータ１が転送したＰａｔｈメッセージに対応していることがわかる。
【００８４】
ＩＣＭＰ検出部１９は本来の受信ホストがＲＳＶＰに対応していないと判断し（図１１ステップＳ１３，Ｓ１４）、当該ＩＣＭＰメッセージを破棄し（図１１ステップＳ１５）、対応するＰａｔｈメッセージ情報を代理ＲＳＶＰ制御部２０に通知して本来の受信ホストの代わりにＲＳＶＰの手順を実行するように依頼する（図１１ステップＳ１６）。
【００８５】
代理ＲＳＶＰ制御部２０はＩＣＭＰ検出部１９からＰａｔｈメッセージ情報が通知されると、本来の受信ホストの代わりにＲＳＶＰの手順を実行する。この時、代理ＲＳＶＰ制御部２０はＲＳＶＰ代理応答ルータ１内の資源を確保するために、ＱｏＳ制御部１３に、ＱｏＳの対象となる通信と、当該通信に適用すべきＱｏＳとを通知する。ＱｏＳ制御部１３では代理ＲＳＶＰ制御部２０からＱｏＳの対象となる通信と当該通信に適用すべきＱｏＳとの通知を受けると、当該通信が適切なＱｏＳクラスに分類されるようにクラシファイア１４の設定を変更し、当該ＱｏＳクラスに対して適切なＱｏＳが適用されるようにパケットスケジューラ１５の設定を変更する（図１１ステップＳ１７）。
【００８６】
これによって、送信ホスト３から受信ホスト２１に送信されるデータパケットはＱｏＳ制御部１３を通過する際にクラシファイア１４によって適切なＱｏＳクラスに分類され、パケットスケジューラ１５によってＱｏＳが保証されながら送信される。
【００８７】
ＲＳＶＰの手順を実行した代理ＲＳＶＰ制御部２０はＲｅｓｖメッセージをＲＳＶＰ送信ホスト３までの経路上の次ホップルータに送信するために、同メッセージをルーティング部１８に転送する。ルーティング部１８は宛先にしたがってＲｅｓｖメッセージをインタフェース部１１に転送する。Ｒｅｓｖメッセージはインタフェース部１１からＲＳＶＰネットワーク１００上に送信され、ＲＳＶＰ送信ホスト３までの経路上の資源を予約していく（図１１ステップＳ１８）。
【００８８】
したがって、ＲＳＶＰ代理応答ルータ１は受信したＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」によって受信ホストがＲＳＶＰに対応していないことを検出し、自動的にＲＳＶＰ代理応答処理を実施することができる。
【００８９】
一方、ＩＣＭＰ検出部１９は上記の比較で一致したものがなかった場合（図１１ステップＳ１３，Ｓ１４）、無関係と判断してＩＣＭＰメッセージをルーティング部１８に戻し、そのまま当該ＩＣＭＰメッセージの処理をルーティング部１８に任せる。ルーティング部１８はＩＣＭＰメッセージをその宛先アドレスにしたがって、インタフェース部１１に転送し、ＩＣＭＰメッセージがＲＳＶＰネットワーク１００に送出され、本来の宛先に向けて転送される（図１１ステップＳ１９）。
【００９０】
尚、図１に示す非ＲＳＶＰ／ＲＳＶＰ混在ネットワーク２は非ＲＳＶＰ受信ホスト２１、非ＲＳＶＰルータ２３、ＲＳＶＰ受信ホスト２２、ＲＳＶＰルータ２４をそれぞれ１台ずつで構成しているが、それぞれ複数台で構成していても構わない。
【００９１】
また、図２に示すＲＳＶＰ代理応答ルータ１では、説明を容易にするために、インタフェース部１１を送信ホスト側、インタフェース部１２を受信ホスト側にそれぞれ対応させて設置しているが、これらインタフェース部１１，１２がそれぞれ受信ホストと送信ホストとを同時に扱っても構わない。さらに、ＲＳＶＰ代理応答ルータ１においてはインタフェースの数を２個以上としてもよい。
【００９２】
このように、本実施例では、受信ホストから送信されるＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」をＲＳＶＰ代理応答ルータ１で検出することによって、受信ホストがＲＳＶＰに対応しているか否かを自動的に検出することができる。したがって、本実施例では、データ受信側ネットワークにＲＳＶＰに対応していない非ＲＳＶＰ受信ホスト２１と、ＲＳＶＰに対応しているＲＳＶＰ受信ホスト２２とが多数混在している場合に、ＲＳＶＰ代理応答ルータ１自身に個々の受信ホストのアドレスを登録しなくても、ＲＳＶＰに対応していない非ＲＳＶＰ受信ホスト２１に対してのみ、代理でＲＳＶＰの手順を実行することができる。
【００９３】
図１２は本発明の他の実施例によるＲＳＶＰ代理応答システムの構成を示すブロック図である。図１２において、本発明の他の実施例によるＲＳＶＰ代理応答システムは非ＲＳＶＰルータ２３をＲＳＶＰ代理応答ルータ１ａに置換えた以外は図１に示す本発明の一実施例によるＲＳＶＰ代理応答システムと同様の構成となっており、同一構成要素には同一符号を付してある。
【００９４】
図１３は図１２のＲＳＶＰ送信ホスト３が非ＲＳＶＰ受信ホスト２１に対してＰａｔｈメッセージを送信した場合の動作を示すシーケンスチャートである。これら図１２及び図１３を参照してＲＳＶＰ送信ホスト３が非ＲＳＶＰ受信ホスト２１に対してＰａｔｈメッセージを送信した場合の動作について説明する。
【００９５】
ＲＳＶＰ送信ホスト３から送信されたＰａｔｈメッセージは、ＲＳＶＰネットワーク１００、ＲＳＶＰ代理応答ルータ１、ＲＳＶＰ代理応答ルータ１ａを経由して非ＲＳＶＰ受信ホスト２１に到達する。非ＲＳＶＰ受信ホスト２１はＲＳＶＰに対応していないため、ＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」をＲＳＶＰ送信ホスト３に対して送信する。
【００９６】
ＩＣＭＰメッセージを受信したＲＳＶＰ代理応答ルータ１ａは非ＲＳＶＰ受信ホスト２１の代わりにＲＳＶＰの手順を実行し、Ｒｅｓｖメッセージを送信する。Ｒｅｓｖメッセージを受信したＲＳＶＰ代理応答ルータ１は通常のＲＳＶＰルータとして動作し、ＲｅｓｖメッセージをＲＳＶＰネットワーク１００に送信する。ＲｅｓｖメッセージはＲＳＶＰ送信ホスト３に到達し、最終的には送信ホスト３からＲＳＶＰ代理応答ルータ１ａまでの区間においてＱｏＳが保証されることとなる。
【００９７】
本実施例では、図１３に示すように、ＲＳＶＰ送信ホスト３からのＰａｔｈメッセージに対して非ＲＳＶＰ受信ホスト２１に近いＲＳＶＰ代理応答ルータ１ａで代理応答が実施されており、その結果、より広範囲な区間でＱｏＳを保証することができる。
【００９８】
このように、本実施例では、ＲＳＶＰ代理応答ルータ１を多段に接続することで、より最終的な受信ホストに近い位置での代理応答が可能となり、広範囲な区間でＱｏＳを保証することができる。
【００９９】
図１４は本発明の別の実施例によるＲＳＶＰ代理応答システムの構成を示すブロック図である。図１４において、本発明の他の実施例によるＲＳＶＰ代理応答システムはプロバイダネットワーク４にＲＳＶＰ非対応ユーザネットワーク５とＲＳＶＰ対応ユーザネットワーク６とが接続されて構成されている。尚、図１４においては上記のＲＳＶＰ対応ユーザネットワーク６及びＲＳＶＰ非対応ユーザネットワーク５がそれぞれ１個ずつプロバイダネットワーク４に接続されているが、同様の形態で、プロバイダネットワーク４に複数接続してもよい。
【０１００】
ＲＳＶＰ非対応ユーザネットワーク５はＲＳＶＰに対応していない非ＲＳＶＰ受信ホスト２１及び非ＲＳＶＰルータ２３等の機器で構成されたネットワークであり、ＲＳＶＰの手順を実行することができない。
【０１０１】
一方、ＲＳＶＰ対応ユーザネットワーク６はＲＳＶＰに対応しているＲＳＶＰ受信ホスト２２及びＲＳＶＰルータ２４等の機器で構成されたネットワークであり、ＲＳＶＰの手順を実行することができるネットワークである。
【０１０２】
プロバイダネットワーク４はＲＳＶＰネットワーク１００と、ＲＳＶＰ送信ホスト３と、ＲＳＶＰ代理応答ルータ１ｂ，１ｃとから構成されている。ＲＳＶＰ代理応答ルータ１ｂはＲＳＶＰ非対応ユーザネットワーク５とＲＳＶＰネットワーク１００とを接続しており、ＲＳＶＰ代理応答ルータ１ｃはＲＳＶＰ対応ユーザネットワーク６とＲＳＶＰネットワーク１００とを接続している。また、ＲＳＶＰ送信ホスト３は動画や音声等を配信するコンテンツサーバ等であり、ＲＳＶＰネットワーク１００に接続されている。
【０１０３】
この図１４を参照して、ＲＳＶＰ送信ホスト３がＲＳＶＰ非対応ユーザネットワーク５及びＲＳＶＰ対応ユーザネットワーク６にデータパケットを送信する場合の動作について説明する。
【０１０４】
ＲＳＶＰ送信ホスト３がＲＳＶＰ非対応ユーザネットワーク５に向かってデータパケットを送信する場合、ＲＳＶＰ送信ホスト３はＲＳＶＰ非対応ユーザネットワーク５に存在する非ＲＳＶＰ受信ホスト２１に向かってＰａｔｈメッセージを送信する。ＰａｔｈメッセージはＲＳＶＰネットワーク１００及びＲＳＶＰ代理応答ルータ１ｂを経由してＲＳＶＰ非対応ユーザネットワーク５内の非ＲＳＶＰ受信ホスト２１に届けられる。
【０１０５】
ＲＳＶＰ非対応ユーザネットワーク５はＲＳＶＰに対応していない機器で構成されているため、非ＲＳＶＰ受信ホスト２１もＲＳＶＰには対応しておらず、非ＲＳＶＰ受信ホスト２１からＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」がＲＳＶＰ送信ホスト３宛に送信される。
【０１０６】
ＩＣＭＰメッセージがＲＳＶＰ代理応答ルータ１ｂに到達することで、ＲＳＶＰ代理応答ルータ１ｂは受信ホストがＲＳＶＰに対応していないことを検出し、受信ホストの代わりにＲＳＶＰの処理を実施してＲｅｓｖメッセージを送信する。ＲｅｓｖメッセージがＲＳＶＰネットワーク１００を経由してＲＳＶＰ送信ホスト３に到達した時点で、ＲＳＶＰ送信ホスト３からＲＳＶＰ代理応答ルータ１ｂまでの経路においてＱｏＳが保証されたことになる。
【０１０７】
ＲＳＶＰ送信ホスト３がＲＳＶＰ対応ユーザネットワーク６に向かってデータパケットを送信する場合も、ＲＳＶＰ送信ホスト３はＲＳＶＰ対応ユーザネットワーク６に存在するＲＳＶＰ受信ホスト２２に向かってＰａｔｈメッセージを送信する。ＰａｔｈメッセージはＲＳＶＰネットワーク１００及びＲＳＶＰ代理応答ルータ１ｃを経由してＲＳＶＰ対応ユーザネットワーク６内のＲＳＶＰ受信ホスト２２に届けられる。
【０１０８】
ＲＳＶＰ対応ユーザネットワーク６はＲＳＶＰに対応している機器で構成されているため、Ｐａｔｈメッセージを受信したＲＳＶＰ受信ホスト２２は自らＲｅｓｖメッセージを送信して経路上の資源の予約を行う。ＲｅｓｖメッセージがＲＳＶＰ代理応答ルータ１ｃに到達した場合、ＲＳＶＰ代理応答ルータ１ｃは通常のＲＳＶＰルータと同様にＲｅｓｖメッセージを扱い、ＲＳＶＰネットワーク１００の次ホップルータにＲｅｓｖメッセージを送信する。ＲｅｓｖメッセージがＲＳＶＰネットワーク１００を経由してＲＳＶＰ送信ホスト３に到達した時点で、ＲＳＶＰ送信ホスト３からＲＳＶＰ受信ホスト２２までの経路においてＱｏＳが保証されたことになる。
【０１０９】
したがって、プロバイダネットワーク４はユーザネットワークがＲＳＶＰに対応していない場合に、最低でもプロバイダネットワーク４内でのＱｏＳを保証し、ユーザネットワークがＲＳＶＰに対応している場合、ＲＳＶＰ受信ホスト２２までのＱｏＳを保証することができる。また、ＲＳＶＰに対応していないＲＳＶＰ非対応ユーザネットワーク５がＲＳＶＰに対応した場合、プロバイダネットワーク４の環境や設定を変更することなく、自動的にＱｏＳの保証範囲を受信ホストまで拡張することができる。
【０１１０】
このように、本実施例では、プロバイダネットワーク４において設定の変更をすることなく、ユーザネットワーク環境に応じて適切な範囲でのＱｏＳを保証することができる。
【０１１１】
【発明の効果】
以上説明したように本発明の装置及び方法は、送信ホストから受信ホストにデータパケットを送信する際に、送信経路でのサービス品質の保証を得るために送信ホストから送信される確認メッセージを送信ホストと受信ホストとの間に配設されたＲＳＶＰ代理応答ルータによって受信ホストに転送するＲＳＶＰ代理応答システムにおいて、ＲＳＶＰ代理応答ルータが、確認メッセージに対する受信ホストからの応答メッセージを監視し、当該応答メッセージを基に受信ホストがＲＳＶＰに対応しない機器であると判別した時に受信ホストに代わってＲＳＶＰ手順を実行して送信ホストとの間の経路上の資源を予約することによって、受信ホストがＲＳＶＰに対応していないことを自動的に検出して代理でＲＳＶＰ手順を実行することができるという効果が得られる。
【図面の簡単な説明】
【図１】本発明の一実施例によるＲＳＶＰ代理応答システムの構成を示すブロック図である。
【図２】図１のＲＳＶＰ代理応答ルータの構成を示すブロック図である。
【図３】図１のＲＳＶＰ送信ホストが非ＲＳＶＰ受信ホストにＲＳＶＰのＰａｔｈメッセージを送信した場合の動作を示すシーケンスチャートである。
【図４】図１のＲＳＶＰ送信ホストがＲＳＶＰ受信ホストにＲＳＶＰのＰａｔｈメッセージを送信した場合の動作を示すシーケンスチャートである。
【図５】（ａ）はＩＰヘッダのフォーマットを示す図、（ｂ）はＲＳＶＰプロトコルのフォーマットを示す図である。
【図６】図１のＲＳＶＰ送信ホストが非ＲＳＶＰ受信ホストに送信したＰａｔｈメッセージの構成例を示す図である。
【図７】図２のＰａｔｈメッセージ記憶部にＰａｔｈメッセージを記録した後の構成例を示す図である。
【図８】ＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」の「Ｐｒｏｔｏｃｏｌ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」のフォーマットを示す図である。
【図９】図１の非ＲＳＶＰ受信ホストから送信されるＩＣＭＰの「Ｄｅｓｔｉｎａｔｉｏｎ　Ｕｎｒｅａｃｈａｂｌｅメッセージ」の構成例を示す図である。
【図１０】図２のＲＳＶＰ代理応答ルータのＰａｔｈメッセージ受信処理を示すフローチャートである。
【図１１】図２のＲＳＶＰ代理応答ルータのＩＣＭＰメッセージ受信処理を示すフローチャートである。
【図１２】本発明の他の実施例によるＲＳＶＰ代理応答システムの構成を示すブロック図である。
【図１３】図１２のＲＳＶＰ送信ホストが非ＲＳＶＰ受信ホストに対してＰａｔｈメッセージを送信した場合の動作を示すシーケンスチャートである。
【図１４】本発明の別の実施例によるＲＳＶＰ代理応答システムの構成を示すブロック図である。
【図１５】従来のＲＳＶＰの手順を示す図である。
【図１６】従来のＲＳＶＰプロキシサービスのシステム構成を示すブロック図である。
【符号の説明】
１，１ａ〜１ｃ　ＲＳＶＰ代理応答ルータ
２　非ＲＳＶＰ／ＲＳＶＰ混在ネットワーク
３　ＲＳＶＰ送信ホスト
４　プロバイダネットワーク
５　ＲＳＶＰ非対応ユーザネットワーク
６　ＲＳＶＰ対応ユーザネットワーク
１１，１２　インタフェース部
１３　ＱｏＳ制御部
１４　クラシファイア
１５　パケットスケジューラ
１６　ＲＳＶＰ制御部
１７　Ｐａｔｈメッセージ記憶部
１８　ルーティング部
１９　ＩＣＭＰ検出部
２０　代理ＲＳＶＰ制御部
２１　非ＲＳＶＰ受信ホスト
２２　ＲＳＶＰ受信ホスト
２３　非ＲＳＶＰルータ
２４　ＲＳＶＰルータ
１００　ＲＳＶＰネットワーク
【図１】
2004104544.tif 000003
【図２】
2004104544.tif 000004
【図３】
2004104544.tif 000005
【図４】
2004104544.tif 000006
【図５】
2004104544.tif 000007
【図６】
2004104544.tif 000008
【図７】
2004104544.tif 000009
【図８】
2004104544.tif 000010
【図９】
2004104544.tif 000011
【図１０】
2004104544.tif 000012
【図１１】
2004104544.tif 000013
【図１２】
2004104544.tif 000014
【図１３】
2004104544.tif 000015
【図１４】
2004104544.tif 000016
【図１５】
2004104544.tif 000017
【図１６】
2004104544.tif 000018