JP4452727B2 - ＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法及びそのシステム - Google Patents

Description

本発明は、ＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法及びそのシステムに関する。

インターネットは、２１世紀情報化社会の核心のインフラとして位置付けられており、インターネットを介して転送されるトラフィックも過去のテキストモードのトラフィックから、音声、イメージ及び映像を含むマルチメディアトラフィックに変化し、このようなＶｏＩＰとInternet ＴＶのような高品質の実時間処理を要求するマルチメディアトラフィックが爆発的に増加する傾向にある。

マルチメディアトラフィックは、既存のテキストモードのトラフィックに比べてデータの量が膨大し、また、遅延とジッター（jitter）に敏感であるという特徴を有している。したがって、いわゆるトリプルプレイサービス（Triple Play Service；ＴＰＣ）といった音声、ビデオ及びデータのような異なる特徴を有するトラフィックが要求するＱｏＳ（Quality of Service）を、現在のインターネットで提供し得るようにするための努力が続いている。

インターネットの使用の普遍化に伴って、マルチメディアトラフィックが増加することによって、インターネットを介して転送されるトラフィックの量は、６ケ月毎に２倍ずつ増加しており、このような増加傾向は、今後も持続する展望である。したがって、インターネットトラフィックの急激な増加を効率的に収容できるインターネットインフラの構築が必須であるといえる。

現在のインターネットは、ＩＰｖ４を基盤としている。ＩＰｖ４において、ソースは、トラフィックを目的地に転送するために、パケットにソースアドレス及び目的地アドレスを書き込み、インターネットを介して転送する。このようなインターネットは、大きく、ルータからなるネットワークであるといえ、ルータがこのパケットを受信すれば、自身のルーティングテーブルを用いてパケットを転送するインタフェースを決定する。

そして、パケットの長さと当該インタフェースの最大転送単位（Maximum Transmission Unit:ＭＴＵ）とを比較し、仮にパケットの長さがＭＴＵより大きければ、ルータは、パケットを分割（fragmentation）する。また、ルータは、パケットにオプションが存在するか否かを確認し、適切な動作をとる。しかしながら、このような分割（fragmentation）やオプション確認／処理などは、ルータの性能を低下させる重大な要因として作用し、インターネットの全体の性能を低下させる。

また、ＩＰｖ４で使われるアドレスは、３２ビットからなるので、最大約４０億個のホストがインターネットに接続することが可能である。しかしながら、特殊アドレスの使用とサブネッティング（subnetting）、そしてネットワークアドレスの割当による非効率的なアドレス割当に起因して、実際にインターネットに接続し得るホストの数は、極めて少ない。

これに対し、インターネットの普遍化とマルチメディアトラフィックの増加によって、従来とは異なり、コンピュータのみならず、移動通信端末や、情報家電なども現在のインターネットに接続しようとする努力が続いている。このような移動通信端末とテレビ及び冷蔵庫のような情報家電の数は、非常に多く、このような装置をインターネットに接続するには、ＩＰｖ４アドレスが極めて不足している。

したがって、ほぼ無限の端末を接続することができ、また、ＩＰｖ４の非効率性を補完し、全体としてのインターネットの性能を向上させるために、ＩＰｖ６技術が提案された。

ＩＰｖ６は、ソースから目的地の間に存在する全ての経由ルータが全てのオプション検査をしなければならないし、また、分割（fragmentation）を行うことによって発生し得るＩＰｖ４の短所によるインターネットの性能低下を防止することができ、リアルタイム転送を必要とするマルチメディアトラフィックを効率的に収容することができるプロトコルである。

ＩＰｖ６は、この他にも１２８ビットのアドレス体系を有していて、ほぼ無限の端末機を収容することができる。アドレス体系が３２ビットから１２８ビットに増加すれば、ルータにおいて経路を決定するための必須事項であるルーティングテーブルの内容が増加するが、ＩＰｖ６のアドレス体系は、ＩＰｖ４の場合より多い階層構造からなるので、ルーティングテーブルから適切な経路を探すために必要とされる時間を短縮できるという長所を有している。

すなわち、ＩＰｖ６の向上した機能は、現在のインターネットトラフィックの急激な増加とマルチメディアトラフィックの普遍的使用による現在のインターネットの性能問題を解決することができる。

このようなＩＰｖ６は、ＩＰｖ４に比べて非常に向上した機能を有しているが、現在のインターネットは、ＩＰｖ４を基盤としており、ＩＰｖ４とＩＰｖ６は、直接的な互換関係にはない。また、現在のインターネットを構成している全てのルータとホストのＩＰ機能を短時間に変えることは不可能である。

したがって、ＩＰｖ４からＩＰｖ６への遷移は、漸進的に行われ、このような漸進的な遷移がかなり長期間続くはずである。また、ＩＰｖ６の初期には、大部分のインターネットは、ＩＰｖ４であり、特定の企業や研究所の一部では、ＩＰｖ６網が使われながら順次ＩＰｖ６網の大きさが拡張され且つＩＰｖ４網の大きさが縮小され、自然にＩＰｖ６への遷移が起こると考えられるので、ＩＰｖ６網に接続されているホストとＩＰｖ４網に接続されているホストとの間に情報を伝達できるメカニズムを提供することが、ＩＰｖ６を成功させる重要な要素となる。

したがって、ＩＰｖ６網とＩＰｖ４網との間に位置するホストが互いにトラフィックを交換できるように、相互の互換性を提供できる切換メカニズムが必須である。

このような切換メカニズムとして、ＩＥＴＦでは、ＮＡＴ−ＰＴのような変換メカニズム（translation mechanism）と、ＤＳＴＭ（Dual Stack Transition Mechanism）のようなトンネリングメカニズムが提案された。ＮＡＴ−ＰＴは、ＳＩＩＴプロトコル変換と、ＮＡＴ及びＤＮＳ ＡＬＧなど適切なＡＬＧの動的アドレス変換とを組み合わせて、ＩＰｖ６専用ノードとＩＰｖ４専用ノードとの間で相互の通信を可能にする。

すなわち、ＮＡＴ−ＰＴは、ＩＰｖ６−ＩＰｖ４網の境界でＩＰｖ４アドレスプールを使用して動的にＩＰｖ４アドレスを割り当てるようにする。ＮＡＴ−ＰＴは、ＩＰｖ６ネットワークのアドレスとＩＰｖ４ネットワークアドレスとを互いにバインディングし、各アドレス領域間を行き来するデータグラムに透明なルーティングを提供する。

言い換えれば、ＮＡＴ−ＰＴメカニズムを用いた端末ノードで変更されることはなく、ＩＰパケットルーティングは、端末ノードにおいて完全に透明になる。しかしながら、ＮＡＴ−ＰＴ変換方式の適用に制約がある。１つのセッションに対する全ての応答及び要請は、同一のＮＡＴ−ＰＴルータを経てルーティングされなければならない。

また、ＩＰｖ４フィールドの内容の相当数は、ＩＰｖ６フィールドの内容と異なるので、直接的に変換できないという短所を有している。そして、ＮＡＴ−ＰＴは、ＩＰ階層でアドレス変換を行うので、上位階層でＩＰアドレスを使用するアプリケーションは、正常に動作しない。これを解決するために、ＡＬＧを使用するが、現在使われる全てのアプリケーションと新しく開発される全てのアプリケーションを予測してＡＬＧを作ることは、本質的に不可能なので、アドレス変換の影響は、解決することができない問題点と言える。

また、ＮＡＴ−ＰＴの最も重要な問題の１つは、終端間ネットワーク階層保安が不可能である点である。また、ＩＰアドレスをアプリケーション階層で使用する場合において、転送及びアプリケーション階層保安もやはり不可能である。これは、ＮＡＴ機能自体の限界である。これとは別に、ＩＰＳｅｃ保安は、異なるアドレス領域間では不可能なので、ＩＰＳｅｃネットワークレベル保安を望む終端ノードは、両方共にＩＰｖ４またはＩＰｖ６のいずれかをサポートしなければならない。そして、ＤＮＳ−ＳＥＣを適用しないという短所を有している。

これに対し、ＤＳＴＭは、ＩＰｖ６網に位置する端末がＩＰｖ４及びＩＰｖ６の２つのプロトコルスタックを具現していて、この端末がＩＰｖ６ノードと接続する場合には、ＩＰｖ６スタックを利用し、ＩＰｖ４ノードと接続する場合には、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングメカニズムを用いてＩＰｖ４スタックを使用して通信できるようにする構造である。

ＤＳＴＭは、臨時のグローバルＩＰｖ４アドレスをＩＰｖ６ノードに提供する方法と、ＩＰｖ６ネットワーク内で動的トンネルを用いてＩＰｖ４パケットを転送する方法を提供する。ＤＳＴＭは、この切換メカニズムに必須なサポートインフラに対して定義された一連のプロセスとアーキテクチャーを提供する。

ＤＳＴＭは、必要に応じて、ＩＰｖ４アドレスをデュアルＩＰ階層ホストに指定する。すると、ＩＰｖ６ホストがＩＰｖ４専用ホストと通信できるようになり、又は、ＩＰｖ４専用アプリケーションがＩＰｖ６ホストで修正されずに、実行されることができる。

すなわち、ＤＳＴＭは、ＤＳＴＭサーバ、ＴＥＰ（Tunnel End Point）、及びＤＳＴＭクライアントで構成され、ＤＳＴＭクライアントがＩＰｖ４網に存在するＩＰｖ４ノードと接続しようとする場合には、臨時のグローバルＩＰｖ４アドレスをＤＳＴＭサーバから割り当てられる。

そして、この情報を用いてＤＳＴＭクライアントがＩＰｖ４ノードと通信するために、ＩＰｖ４パケットを生成すれば、そのノードは、ＩＰｖ４パケットを自身のＩＰｖ６アドレス及びＴＥＰのＩＰｖ６アドレス情報を用いてカプセル化した後、このパケットを転送する。このパケットは、ＩＰｖ６パケットであり、したがって、ＤＳＴＭノードが存在するネットワークの内部では、ＴＥＰにネットワーク内部のルーティングアルゴリズムによって転送される。

ＴＥＰがこのパケットを受信すれば、ＩＰｖ６ヘッダーに存在するアドレスとＩＰｖ６パケットのペイロードに存在するＩＰｖ４パケットのソースＩＰｖ４アドレスとを用いてマッピングテーブルを構成し、ＩＰｖ６ヘッダーを削除した後に、ＩＰｖ４パケットをＩＰｖ４ノードに転送する。すると、ＩＰｖ４ノードは、受信したトラフィックに対する応答パケットを転送し、このパケットをＴＥＰが受信し、元来のＩＰｖ６ノードにトンネリングを用いて転送する。

一方、ＩＰ階層で異なるＱｏＳを要求するトラフィックを収容するために、リソース予約方式であるＲＳＶＰ（Resource Reservation Protocol）が定義された。ＲＳＶＰ方式は、ＱｏＳ基盤の連結のために、ネットワークリソースを予約し、仮に予約できなければ、リソース予約を拒否する方式である。

このようなＲＳＶＰ方式は、１つのユーザがソースから目的地まで一種の仮想回線であるフローを開設するために、ソースと目的地との間に全てのルータの所要の資源を予約し、ＱｏＳを保証する技術であって、フロー基盤のモデルであるといえる。

すなわち、ＲＳＶＰは、フロー基盤のＱｏＳを保証するための信号プロトコルであるといえ、この信号プロトコルによって、ソースノードと目的地ノードとの間に存在するルータは、自身のリソースを予約する。

ソースノードが属しているネットワークがＩＰｖ６網であり、目的地ノードが属しているネットワークがＩＰｖ４網である場合には、ＩＰｖ６網とＩＰｖ４網との間にＱｏＳ保証のためにＩＰｖ６網で駆動されるＲＳＶＰと、ＩＰｖ４網で駆動されるＲＳＶＰとの連動が必須であるといえる。しかしながら、現在のＲＳＶＰは、ＩＰｖ４基盤のネットワーク内、またはＩＰｖ６基盤のネットワーク内のように、単一ネットワーク内でのリソース予約のみが定義されている。

このように、現在のＲＳＶＰサポートメカニズムは、ＩＰｖ４網内、またはＩＰｖ６網内のように、単一ネットワーク内でＱｏＳを提供するためのセッションを開設できるようにしているだけで、ＩＰｖ６網とＩＰｖ４網とが結合したＩＰｖ６−ＩＰｖ４統合網の環境では、サポートしないという短所を有している。

また、現在のインターネットは、ＩＰｖ４を基盤としており、ストリーミングサーバのように実時間処理を要するトラフィックを格納し転送するサーバは、一般的にＩＰｖ４網内に位置しているので、ＩＰｖ６網内に存在するデュアルスタックホストがＩＰｖ４網内に位置するサーバとＱｏＳセッションを結ぶための一連の過程がないのが実情である。
韓国特許出願第１０−２００３−０１０１６１２号明細書

従って、本発明の目的は、前述のような問題点を解決するためになされたもので、ＩＰｖ４とＩＰｖ６とが混在したＩＰｖ４／ＩＰｖ６統合網において、ＩＰｖ４網にマルチメディアトラフィックのためのサーバが位置する場合に、サーバからＩＰｖ６網内に位置するデュアルスタックホストに転送されるトラフィックがＱｏＳを提供され得るようにするために、終端間ＲＳＶＰ連結を設定することを可能としたＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法及びそのシステムを提供することにある。

上記目的を達成するために、本発明のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法は、ＩＰｖ６網内のデュアルスタックホストがＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間ＱｏＳセッション連結要請メッセージを転送する段階と、ＩＰｖ４サーバがＤＳＴＭ ＴＥＰを介してデュアルスタックホストに終端間経路メッセージを転送する段階と、ＤＳＴＭ ＴＥＰがデュアルスタックホストにＩＰｖ６網内でのリソース予約のための経路メッセージを転送する段階と、デュアルスタックホストがＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間リソース予約要請メッセージを転送し、ＩＰｖ４網内でのリソース予約を設定する段階と、デュアルスタックホストがＤＳＴＭ ＴＥＰにリソース予約要請メッセージを転送し、ＩＰｖ６網内でのリソース予約を設定する段階と、を備える。

ＩＰｖ６網内のデュアルスタックホストがＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間ＱｏＳセッション連結要請メッセージを転送する段階で、ＱｏＳセッション連結要請メッセージは、ＩＰｖ４ヘッダーを有し、ＩＰｖ６にカプセル化され、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてＤＳＴＭ ＴＥＰに転送される。

ＤＳＴＭ ＴＥＰは、デュアルスタックホストから転送されたメッセージに含まれるソースＩＰｖ６アドレス及び内部に存在するソースＩＰｖ４アドレスに関するマッピング情報をテーブルに格納した後に、ＩＰｖ６ヘッダーを除去したＩＰｖ４パケットをＩＰｖ４サーバに転送する。

ＩＰｖ４サーバがＤＳＴＭ ＴＥＰを介してデュアルスタックホストに終端間経路メッセージを転送する段階で、ＤＳＴＭ ＴＥＰに転送される経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、を含む構造を有する。

終端間経路メッセージのＩＰｖ４パケットの目的地アドレスは、デュアルスタックホストのＩＰｖ４アドレスである。

ＤＳＴＭ ＴＥＰは、ＩＰｖ４パケットの目的地アドレスに存在するＩＰｖ４アドレスにマッピングされる当該ＩＰｖ６アドレスをマッピングテーブルから抽出し、ＩＰｖ６パケットにカプセル化した後、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてデュアルスタックホストに転送する。

ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングされた経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

ＤＳＴＭ ＴＥＰがデュアルスタックホストにＩＰｖ６網内でのリソース予約のための経路メッセージを転送する段階で、経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

デュアルスタックホストがＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間リソース予約要請メッセージを転送し、ＩＰｖ４網内でのリソース予約を設定する段階で、終端間リソース予約要請メッセージは、ＩＰｖ４ヘッダーを有し、ＩＰｖ６にカプセル化され、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてＤＳＴＭ ＴＥＰに転送される。

ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、リソース予約要請データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

ＤＳＴＭ ＴＥＰは、デュアルスタックホストから転送されたリソース予約要請メッセージからＩＰｖ６ヘッダーを除去したＩＰｖ４パケットをＩＰｖ４サーバに転送する。

ＩＰｖ４サーバに転送されるＩＰｖ４パケットは、ホップバイホップ（hop-by-hop）の形態で転送されながら各ルータにリソースを予約設定する。

デュアルスタックホストがＤＳＴＭ ＴＥＰにリソース予約要請メッセージを転送し、ＩＰｖ６網内でのリソース予約を設定する段階で、リソース予約要請メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、ホップバイホップの形態で転送されながら各ルータにリソースを予約設定する。

また、本発明のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステムは、ＩＰｖ６網内のデュアルスタックホストと、ＩＰｖ４網内のＩＰｖ４サーバと、デュアルスタックホストとＩＰｖ４サーバとを接続するＤＳＴＭ ＴＥＰと、を有するＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステムであって、デュアルスタックホストが、ＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間ＱｏＳセッション連結要請メッセージを転送し、ＩＰｖ４サーバが、ＤＳＴＭ ＴＥＰを介してデュアルスタックホストに終端間経路メッセージを転送し、ＤＳＴＭ ＴＥＰが、デュアルスタックホストにＩＰｖ６網内でのリソース予約のための経路メッセージを転送し、デュアルスタックホストが、ＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間リソース予約要請メッセージを転送し、ＩＰｖ４網内でのリソース予約を設定し、デュアルスタックホストが、ＤＳＴＭ ＴＥＰにリソース予約要請メッセージを転送し、ＩＰｖ６網内でのリソース予約を設定することを特徴とする。

ＤＳＴＭ ＴＥＰに転送される終端間経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、を含む構造を有する。

終端間経路メッセージのＩＰｖ４パケットの目的地アドレスは、デュアルスタックホストのＩＰｖ４アドレスである。

ＤＳＴＭ ＴＥＰは、ＩＰｖ４パケットの目的地アドレスに存在するＩＰｖ４アドレスにマッピングされる当該ＩＰｖ６アドレスをマッピングテーブルから抽出し、ＩＰｖ６パケットにカプセル化した後に、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてデュアルスタックホストに転送する。

ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングされた経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

ＤＳＴＭ ＴＥＰは、ＩＰｖ６網内でのリソース予約のための経路メッセージをデュアルスタックホストに転送する。

ＩＰｖ６網内でのリソース予約のための経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

ＤＳＴＭ ＴＥＰに転送される終端間リソース予約要請メッセージは、ＩＰｖ４ヘッダーを有し、ＩＰｖ６にカプセル化され、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてＤＳＴＭ ＴＥＰに転送される。

ＤＳＴＭ ＴＥＰに転送される終端間リソース予約要請メッセージは、リソース予約要請データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

ＤＳＴＭ ＴＥＰは、デュアルスタックホストから転送された終端間リソース予約要請メッセージからＩＰｖ６ヘッダーを除去したＩＰｖ４パケットをＩＰｖ４サーバに転送する。

ＩＰｖ４サーバに転送されるＩＰｖ４パケットは、ホップバイホップの形態で転送されながら各ルータにリソースを予約設定する。

ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有する。

ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、ホップバイホップの形態で転送されながら各ルータにリソースを予約設定する。

本発明によれば、ＩＰｖ４とＩＰｖ６が混在したＩＰｖ４／ＩＰｖ６統合網においてＩＰｖ４網にマルチメディアトラフィックのためのサーバが位置する場合に、サーバからＩＰｖ６網内に位置するデュアルスタックホストに転送されるトラフィックがＱｏＳを提供され得るようにすることで、終端間のＲＳＶＰ連結を設定することが可能となり、ＱｏＳを保証することが可能となる。

以下、添付の図面を参照して、本発明の好ましい実施形態を詳細に説明する。なお、図面で、同じ参照番号は、同じ構成要素を示す。本発明を説明するにあたって、関連する公知の機能または構成についての具体的な説明が本発明の要旨を不明確にすることがあると判断される場合には、その詳細な説明を省略する。

図１は、一般的なＲＳＶＰのＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクトを説明する図である。

図１に示すように、「ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト」には、長さ情報を有する「長さ（Length）」フィールドと、種類情報を有する「クラス（Class）」フィールドと、タイプ情報を有する「タイプ（Ｃ−タイプ）」フィールドと、終端間セッション情報を有する「ＳＥＳＳＩＯＮオブジェクト」フィールドと、トンネルセッション情報を有する「送信機ＦＩＬＴＥＲ＿ＳＰＥＣ」フィールドと、を含む。

このような「ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト」は、送信終端から受信終端に転送される経路メッセージに含まれる。

図２は、一般的なＲＳＶＰのＮＯＤＥ＿ＣＨＡＲオブジェクトを説明する図である。

「ＮＯＤＥ＿ＣＨＡＲオブジェクト」は、トンネル区間の最終ノードがトンネル区間の開始ノードに「ＲＦＣ２７４６」で定義されたトンネルＲＳＶＰメカニズムをサポートすることができるか否かに関する情報を伝達するためのものである。

図２に示すように、トンネル区間の最終ノードがトンネルＲＳＶＰメカニズムをサポートすることができる場合には、受信終端から送信終端に転送される予約メッセージ（Resv message）の「ＮＯＤＥ＿ＣＨＡＲオブジェクト」内に、ＲＳＶＰをサポートすることができるか否かを通知する「Ｔ」ｂｉｔを設定して転送する。

図３は、一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰの経路メッセージフローを説明する図である。

図３に示す送信終端（Ｓ１）１０及び受信終端（Ｄ１）２０は、ＩＰｖ４網に含まれる。開始ノードであるＲｅｎｔｒｙ３１と最終ノードであるＲｅｘｉｔ３２との間に設定されるトンネルは、ＩＰｖ６網に含まれる。

そして、送信終端（Ｓ１）１０とＲｅｎｔｒｙ３１との間、Ｒｅｎｔｒｙ３１とＲｅｘｉｔ３２との間、そしてＲｅｘｉｔ３２と受信終端（Ｄ１）２０との間の経路上のルータ及びノードは、省略されていると仮定する。

例えば、送信終端（Ｓ１）１０は、受信終端（Ｄ１）２０に１０Ｍｂｐｓでトラフィックを転送しようとする場合には、終端間に１０Ｍの帯域幅を予約するために、ＲＳＶＰに応じた終端間経路メッセージを受信終端（Ｄ１）２０に転送する。

送信終端（Ｓ１）１０は、ＩＰヘッダー（ＩＰ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自身のＩＰアドレス情報である「Ｓ＿ＩＰ」に設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）を受信終端（Ｄ１）２０のＩＰアドレス情報である「Ｄ＿ＩＰ」に設定する。

送信終端（Ｓ１）１０は、終端間経路メッセージ（ＲＳＶＰ Ｍｓｇ）の「ＳＥＳＳＩＯＮオブジェクト（ＳＥＳＳＩＯＮ Ｏｂｊ）」の、目的地アドレス情報（ＤｓｔＡｄｄｒ）を「Ｄ＿ＩＰ」に設定し、目的地ポート情報（Ｄｓｔ ｐｏｒｔ）を「Ｄ＿Ｐｏｒｔ」に設定する。また、送信終端（Ｓ１）１０は、「ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト（ＳＥＮＤＥＲ Ｄｉｓｃ）」の、ソースアドレス情報（ＳｒｃＡｄｄｒ）を自身のアドレス情報である「Ｓ＿ＩＰ」に設定し、ソースポート情報（Ｓｒｃ Ｐｏｒｔ）を自身のポート情報である「Ｓ＿Ｐｏｒｔ」に設定する。

このような終端間経路メッセージは、「Ｒｏｕｔｅｒ Ａｌｅｒｔ ＩＰオプション」を含んで転送されるので、送信終端（Ｓ１）１０と受信終端（Ｄ１）２０との間のＲＳＶＰをサポートする全てのルータにより処理される。

そして、トンネルの開始ノードであるＲｅｎｔｒｙ３１は、経路メッセージが受信された場合には、トンネルの最終ノードであるＲｅｘｉｔ３２がＲＳＶＰメカニズムをサポートすることができるか否かについて把握することができないので、終端間セッションに対する経路状態を格納し、経路メッセージをカプセル化し、Ｒｅｘｉｔ３２に転送する。

Ｒｅｘｉｔ３２は、受信されたカプセル化した経路メッセージを脱カプセル化し、終端間セッションに対する経路を設定した後、経路メッセージを受信終端（Ｄ１）２０に転送する。

受信終端（Ｄ１）２０は、経路メッセージが受信された場合には、予約メッセージをホップ−バイ−ホップで送信終端（Ｓ１）１０に転送する。

図４は、一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰの予約メッセージのフローを説明する図である。

図４を参照すれば、受信終端（Ｄ１）２０は、ＩＰヘッダー（ＩＰ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を「Ｄ＿ＩＰ」に設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）をＲＳＶＰメカニズムをサポートするアップストリームノードであるＲｅｘｉｔ３２のＩＰアドレス情報（Ｎｅｘｔ＿Ｈｏｐ）に設定する。受信終端（Ｄ１）２０は、経路メッセージと同じ情報を含む「ＳＥＳＳＩＯＮオブジェクト（ＳＥＳＳＩＯＮ Ｏｂｊ）」と、経路メッセージの「ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト（ＳＥＮＤＥＲ Ｄｉｓｃ）」と同じ情報を含む「ＦＩＬＴＥＲＳＰＥＣオブジェクト（ＦＩＬＴＥＲ ＳＰＥＣ）」と、を含むＲＳＶＰメッセージ（ＲＳＶＰ Ｍｓｇ）を、Ｒｅｘｉｔ３２に転送する。

Ｒｅｘｉｔ３２は、受信終端（Ｄ１）２０から予約メッセージが受信された場合には、終端間セッションに対するリソース状態を予約し、終端間セッションにマッピングされるトンネルセッションがないので、Ｒｅｎｔｒｙ３１にトンネルＲＳＶＰをサポートすることができることを通知するために、「Ｔ」ｂｉｔが設定された「ＮＯＤＥ＿ＣＨＡＲオブジェクト（ＮＯＤＥ＿ＣＨＡＲ）」を予約メッセージに追加した後に、予約メッセージをカプセル化し、Ｒｅｎｔｒｙ３１に転送する。

Ｒｅｎｔｒｙ３１は、受信された予約メッセージを脱カプセル化し、「ＮＯＤＥ＿ＣＨＡＲ」を除去した後に、終端間セッションに対するリソースを予約する。Ｒｅｎｔｒｙ３１は、「ＮＯＤＥ＿ＣＨＡＲ」が除去された予約メッセージを送信終端（Ｓ１）１０に転送する。

このとき、Ｒｅｎｔｒｙ３１がトンネルＲＳＶＰメカニズムをサポートすることができる場合には、Ｒｅｎｔｒｙ３１は、予約メッセージをアップリンクで送信終端（Ｓ１）１０に転送しながら、トンネル経路メッセージをＲｅｘｉｔ３２に転送する。

図５は、一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰのトンネル経路メッセージフローを説明する図である。

図５を参照すれば、トンネルの開始ノードであるＲｅｎｔｒｙ３１は、予約メッセージが受信された場合には、終端間セッションにマッピングされるトンネルセッションを生成し、トンネル内のリソースを予約できるように、トンネル経路メッセージ（Tunnel Path message）と、経路上の変更された情報を通知するための終端間経路メッセージ（E to E Path message）とを、Ｒｅｘｉｔ３２に転送する。

トンネル経路メッセージの送信ノードは、Ｒｅｎｔｒｙ３１であり、受信ノード３２は、Ｒｅｘｉｔ３２であるから、ＩＰヘッダー（ＩＰ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）は、Ｒｅｎｔｒｙ３１のアドレス情報である「Ｅｎｔｒｙ＿ＩＰ」に設定され、目的地アドレス情報（ＤｓｔＡｄｄｒ）は、「Ｅｘｉｔ＿ＩＰ」に設定され、「ＳＥＳＳＩＯＮオブジェクト（ＳＥＳＳＩＯＮ Ｏｂｊ）」の目的地アドレス情報（ＤｓｔＡｄｄｒ）は、「Ｅｘｉｔ＿ＩＰ」に設定され、目的地ポート情報（Ｄｓｔ ｐｏｒｔ）は、例えば、「３６３」が設定される。

トンネル経路メッセージの「ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト（ＳＥＮＤＥＲ Ｄｉｓｃ）」のソースアドレス情報（ＳｒｃＡｄｄｒ）は、「Ｅｎｔｒｙ＿ＩＰ」に設定され、ソースポート情報（Ｓｒｃ Ｐｏｒｔ）は、トンネル内で各フローを区別するために、Ｒｅｎｔｒｙ３１が割り当てた特定値（２００）に設定される。

このようなトンネル経路メッセージは、Ｒｅｎｔｒｙ３１とＲｅｘｉｔ３２との間に設定されるトンネル内に存在するＲＳＶＰをサポートすることができるノードが、トンネルセッションに対する経路を設定できるようにする。

また、終端間セッションとトンネルセッションとのマッピング情報を伝達する「ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）」を含む終端間経路メッセージは、Ｒｅｘｉｔ３２がトンネルセッションと終端間セッションとをマッピングさせることができるようにする。

そして、Ｒｅｘｉｔ３２は、終端間経路メッセージが受信された場合には、終端間経路メッセージの「ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）」に該当するマッピング情報を設定し、「ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）」を除去した後に、受信終端（Ｄ１）２０に向かってトンネル内に設定された経路に沿って終端間セッションにマッピングされるトンネルセッションのリソースを要請するために、トンネル予約メッセージをＲｅｎｔｒｙ３１に転送する。

図６は、一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰのトンネル予約メッセージフローを説明する図である。

図６を参照すれば、トンネル予約メッセージ（ＲＳＶＰ Ｍｓｇ）のＩＰヘッダー（ＩＰ Ｈｄｒ）に含まれるソースアドレス情報（ＳｒｃＡｄｄｒ）は、「Ｅｘｉｔ＿ＩＰ」、目的地アドレス情報（ＤｓｔＡｄｄｒ）は、ＲＳＶＰをサポートするＲｅｘｉｔ３２のアップストリームノード「Ｎｅｘｔ＿ｈｏｐ」のアドレス情報に設定される。

そして、トンネル予約メッセージ（ＲＳＶＰ Ｍｓｇ）で「ＳＥＳＳＩＯＮオブジェクト（ＳＥＳＳＩＯＮ Ｏｂｊ）」の目的地アドレス情報（ＤｓｔＡｄｄｒ）は、「Ｅｘｉｔ＿ＩＰ」に設定され、目的地ポート情報（Ｄｓｔ ｐｏｒｔ）は、「３６３」に設定される。「ＦＩＬＴＥＲＳＰＥＣオブジェクト（ＦＩＬＴＥＲ ＳＰＥＣ）」のソースアドレス情報（ＳｒｃＡｄｄｒ）は、「Ｅｎｔｒｙ＿ＩＰ」に設定され、ソースポート情報（Ｓｒｃ Ｐｏｒｔ）は、Ｒｅｎｔｒｙが終端間セッションに該当するトンネルセッションのために割り当てた値「２００」に設定される。

トンネル予約メッセージは、ホップ−バイ−ホップ方式で、Ｒｅｘｉｔ３２とＲｅｎｔｒｙ３１との間に設定されるトンネル内のＲＳＶＰをサポートすることができるノードに転送され、各ノードがトンネルリソースを予約できるようにする。

図７は、一般的なＩＰｖ４／ＩＰｖ６統合網における多数のトンネルを介してパケットを転送する場合を説明する図である。

図７を参照すれば、第１の送信終端（Ｓ１）１０が、第１の受信終端（Ｄ１）２０に１０Ｍｂｐｓの速度でパケットを転送するリソースを予約し、第２の送信終端（Ｓ２）１０’が第２の受信終端（Ｄ２）２０’に２０Ｍｂｐｓの速度でパケットを転送するリソースを予約する場合について説明する。

Ｒｅｎｔｒｙ３１は、確立されたトンネル内でセッションを区別するためのソースポート情報として、第１の送信終端（Ｓ１）１０及び第２の送信終端（Ｓ２）１０’に、２００及び２０１を各々割り当てる。

Ｒｅｎｔｒｙ３１は、第１の送信終端（Ｓ１）１０からパケットが受信された場合には、パケットのＩＰヘッダー（ＩＰ Ｈｄｒ）及びＵＤＰヘッダー（ＵＤＰ Ｈｄｒ）をカプセル化し、Ｒｅｘｉｔ３２に転送する。

この際、カプセル化されるパケットのＩＰヘッダー（ＩＰ Ｈｄｒ）及びＵＤＰヘッダー（ＵＤＰ Ｈｄｒ）の目的地ポート情報（Ｄ＿Ｐｏｒｔ）は、全てのセッションに対して同一であり、ＵＤＰヘッダー（ＵＤＰ Ｈｄｒ）のソースポート情報（Ｓ＿Ｐｏｒｔ）が各終端間に設定されたセッションによって異なる値が設定されて転送されることによって、トンネル内のＲＳＶＰをサポートできるノードが受信されるパケットのソースポート情報を用いて各セッションに区別して各セッションに要求するＱｏＳを提供することができる。

Ｒｅｘｉｔ３２は、受信されたパケットのＩＰヘッダー（ＩＰ Ｈｄｒ）及びＵＤＰヘッダー（ＵＤＰ Ｈｄｒ）を脱カプセル化し、第１の受信終端（Ｄ１）２０に転送する。

図８は、本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステムの構成を示す図である。

図８に示すように、本実施形態は、大きく、デュアルスタックホスト（ＩＰｖ６ノード）１００と、ＤＳＴＭサーバ２００と、ＤＳＴＭ ＴＥＰ３００と、ＤＮＳサーバ４００と、ＩＰｖ４−ｏｎｌｙサーバ５００とで構成される。

デュアルスタックホスト１００は、ＩＰｖ６網内に位置するデュアルスタックホストであって、Ｉｐｖ４網内に存在するＩＰｖ４−ｏｎｌｙサーバ５００からマルチメディアトラフィックを受信しようとし、このトラフィックにＱｏＳを保証しようとする場合に、まず、サーバのドメインネームに対するＩＰアドレスを得るために、ＤＮＳに質問（query）メッセージを転送する。

質問の結果、ＤＮＳサーバ４００からＩＰｖ４−ｏｎｌｙサーバ５００のドメインネームに該当するＩＰｖ４アドレスが含まれた応答メッセージを伝送された場合には、デュアルスタックホスト１００は、ＩＰｖ４−ｏｎｌｙサーバ５００がＩＰｖ４網に位置していることを確認する。

これにより、デュアルスタックホスト１００は、ＩＰｖ４プロトコルを用いてＩＰｖ４−ｏｎｌｙサーバ５００に接続するために、ＤＳＴＭサーバ２００に臨時のＩＰｖ４アドレスを得るためのアドレス要請メッセージを転送する。

すなわち、アドレス要請メッセージの転送の結果、デュアルスタックホスト１００は、ＤＳＴＭサーバ２００から１つの臨時のグローバルＩＰｖ４アドレスを割り当てられ、且つ、ＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報をも提供される。

これにより、デュアルスタックホスト１００は、ＩＰｖ４−ｏｎｌｙサーバ５００からＱｏＳ基盤のマルチメディアトラフィックを受信しようとするメッセージをＤＳＴＭ ＴＥＰ３００に転送する。

この際、ＤＳＴＭ ＴＥＰ３００に転送されるメッセージは、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて転送される。すなわち、このメッセージは、ＩＰｖ４ヘッダーを有し、さらにＩＰｖ６にカプセル化される。

また、デュアルスタックホスト１００は、マルチメディアトラフィックを受信しようとするメッセージを転送した後に、ＤＳＴＭ ＴＥＰ３００から経路メッセージを受信した場合には、ＩＰｖ４網内でのリソース予約のために予約メッセージを生成し、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて転送する。

この際、ＤＳＴＭ ＴＥＰ３００に転送される予約メッセージは、リソース予約要請データ（Resv data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）とを含む構造を有する。

また、デュアルスタックホスト１００は、別の予約メッセージを生成し、このメッセージにＩＰｖ６ヘッダーを付けた後、ＤＳＴＭ ＴＥＰ３００を目的地アドレスにしてＩＰｖ６スタックを用いて転送する。

すなわち、ＤＳＴＭ ＴＥＰ３００に転送される予約メッセージは、経路データ（Path data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）とを含む構造を有する。

この際、このメッセージは、ホップバイホップ（hop-by-hop）の形態でＤＳＴＭ ＴＥＰ３００に伝達され、伝達されながらＩＰｖ６網内の各々のルータにリソースを予約する。仮に、このパケットがＤＳＴＭ ＴＥＰ３００に到達すれば、デュアルスタックホスト１０とＤＳＴＭ ＴＥＰ３００との間にＱｏＳ連結が設定される。

ＤＳＴＭサーバ２００は、デュアルスタックホスト１００から転送されるアドレス要請メッセージを受信した場合には、デュアルスタックホスト１００に１つの臨時のグローバルＩＰｖ４アドレスを割り当てるようになり、且つ、ＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報をも提供する。

ＤＳＴＭ ＴＥＰ３００は、デュアルスタックホスト１００からＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いたマルチメディアトラフィック受信要請メッセージが転送された場合には、先に受信したパケットの外部ヘッダーに存在するソースＩＰｖ６アドレス及びパケットの内部ヘッダーに存在するソースＩＰｖ４アドレスに関するマッピング情報をテーブルに格納した後に、ＩＰｖ６ヘッダーを除去し、ＩＰｖ６ヘッダーが除去されたＩＰｖ４パケットをＩＰｖ４−ｏｎｌｙサーバ５００に転送する。

また、ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ４−ｏｎｌｙサーバ５００にＩＰｖ６ヘッダーが除去されたＩＰｖ４パケットを転送した後に、ＩＰｖ４−ｏｎｌｙサーバ５００からＲＳＶＰ（Resource Reservation Protocol）で定義された経路メッセージ（path message）を受信する。

これにより、ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ４−ｏｎｌｙサーバ５００から転送されたパケットの目的地アドレスに存在するＩＰｖ４アドレスを用いて自身のマッピングテーブルから該当ＩＰｖ６アドレスを抽出する。

すなわち、ＤＳＴＭ ＴＥＰ３００は、マッピングテーブルから抽出したＩＰｖ６アドレス情報を用いてＩＰｖ６パケットにカプセル化した後、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてデュアルスタックホスト１００に転送する。

ここで、ＤＳＴＭ ＴＥＰ３００がデュアルスタックホスト１００に転送する経路メッセージは、経路データ（Path data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）とを含む構造を有する。

また、ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ６網内でのリソース予約のためにＲＳＶＰの経路メッセージを作り、ＩＰｖ６ヘッダーを追加した後、デュアルスタックホスト１００に転送する。

この際、前記デュアルスタックホスト１００に転送される経路メッセージは、経路データ（Path data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）とを含む構造を有する。

また、ＤＳＴＭ ＴＥＰ３００は、デュアルスタックホスト１００からＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングされた予約メッセージを受信する場合には、転送されたパケットのＩＰｖ６ヘッダーを除去した後に、予約メッセージが含まれているＩＰｖ４パケットをＩＰｖ４−ｏｎｌｙサーバ５００に転送する。ここで、パケットは、ホップバイホップ（hop-by-hop）の形態で伝達される。

すなわち、ＩＰｖ４−ｏｎｌｙサーバ５００に転送されるパケットは、リソース予約要請データ（Resv data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）とを含む構造を有する。

この際、メッセージが伝達されながら各々のルータにリソースを予約するようになり、仮に、このパケットがＩＰｖ４−ｏｎｌｙサーバ５００に到達すれば、ＤＳＴＭ ＴＥＰ３００とＩＰｖ４−ｏｎｌｙサーバ５００との間にＱｏＳ連結が設定される。

ＤＮＳサーバ４００は、デュアルスタックホスト１００の質問要請によって、ＩＰｖ４−ｏｎｌｙサーバ５００のドメインネームに該当するアドレスがＩＰｖ４アドレスであることを確認し、タイプを“Ａ”に設定した後、デュアルスタックホスト１００にＩＰｖ４−ｏｎｌｙサーバ５００のドメインネームに該当するＩＰｖ４アドレスが含まれた応答メッセージを転送する。

ＩＰｖ４−ｏｎｌｙサーバ５００は、ＩＰｖ４網内に位置し、かつデュアルスタックホスト１００にマルチメディアトラフィックを提供するためのサーバであって、ＤＳＴＭ ＴＥＰ３００から脱カプセル化したＱｏＳセッション要請メッセージが転送された場合には、ＲＳＶＰ（Resource Reservation Protocol）で定義された経路メッセージ（path message）をデュアルスタックホスト１００に転送する。

すなわち、ＩＰｖ４−ｏｎｌｙサーバ５００から転送される経路メッセージ（path message）は、まずＤＳＴＭ ＴＥＰ３００に転送される。この際、経路メッセージは、経路データ（Path data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）とを含む構造を有する。

ここで、前記経路メッセージ（path message）に含まれたＩＰｖ４パケットの目的地アドレスは、デュアルスタックホスト１００のＩＰｖ４アドレスであり、このパケットは、ＤＳＴＭ ＴＥＰ３００に転送される。

図９は、本実施形態のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法を示す図である。図１０は、本実施形態のＩＰｖ４／ＩＰｖ６統合網における終端間経路メッセージ転送過程を示す図である。図１１は、本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＩＰｖ６網におけるリソース予約のためのメッセージ転送過程を示す図である。図１２は、本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＩＰｖ４網におけるリソース予約過程を示す図である。図１３は、本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＩＰｖ６網におけるリソース予約過程を示す図である。

図９に示すように、ＩＰｖ６網内に存在するデュアルスタックホスト（Ｈ１＿ＩＰｖ６）１００が、Ｉｐｖ４網内に存在するＩＰｖ４−ｏｎｌｙサーバ（Ｈ２＿ＩＰｖ４）５００からマルチメディアトラフィックを受信しようとし、このトラフィックがＱｏＳ保証を受けようとする場合には、まず、デュアルスタックホスト１００は、ＩＰｖ４−ｏｎｌｙサーバ５００のドメインネームに対するＩＰアドレスを得るために、ＤＮＳサーバ４００に質問（query）メッセージ（Asks DNS for A RR for “H2”）を転送（ステップＳ１０。図ではステップをＳと略する。）する。

次に、ＤＮＳサーバ４００は、ＩＰｖ４−ｏｎｌｙサーバ５００のドメインネームに該当するアドレスがＩＰｖ４アドレスであることを確認し、タイプを、ＩＰｖ４アドレスを意味する“Ａ”にした後、デュアルスタックホスト１００に応答メッセージ（Answer is 192.5.5.1）を転送（ステップＳ２０）する。

次に、ＤＮＳサーバ４００から応答メッセージを受信したデュアルスタックホスト１００は、ＩＰｖ４−ｏｎｌｙサーバ５００がＩＰｖ４網に位置していることを確認し、ＩＰｖ４プロトコルを用いて接続するために、自身も一つの臨時ＩＰｖ４アドレスを得るために、ＤＳＴＭサーバ２００にアドレス要請メッセージ（Request DSTM Server for an IPv4 address）を転送（ステップＳ３０）する。

デュアルスタックホスト１００からアドレス要請メッセージを受信したＤＳＴＭサーバ５００は、デュアルスタックホスト１００に一つの臨時のグローバルＩＰｖ４アドレスを割当（Provides a temporary IPv4 global address(H1_IPv4), TEP’s IPv6 address(TEP_IPv6)（ステップＳ４０）する。

デュアルスタックホスト１００は、ＩＰｖ４−ｏｎｌｙサーバ５００に、ＱｏＳ基盤のマルチメディアトラフィックを受信しようとするメッセージを転送（To request end-to-end QoS session）（ステップＳ５０）する。このメッセージは、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて転送される。すなわち、このメッセージは、ＩＰｖ４ヘッダーを有し、さらにＩＰｖ６にカプセル化される。

このパケットがＤＳＴＭ ＴＥＰ３００に到達した場合には、ＤＳＴＭ ＴＥＰ３００は、このパケットに存在するソースＩＰｖ６アドレス及び内部に存在するソースＩＰｖ４アドレスに対するマッピング情報をテーブルに格納（Cache association Hi_IPv6-H1_IPv4）し、ＩＰｖ６ヘッダーを除去した後、ＩＰｖ４パケットをＩＰｖ４−ｏｎｌｙサーバ５００に転送（ステップＳ６０）する。

ＩＰｖ４−ｏｎｌｙサーバ５００は、ＲＳＶＰで定義された経路メッセージ（path message）をデュアルスタックホスト１００に転送（Send EtoE Path message）（ステップＳ７０）する。ここで、このメッセージに含まれたＩＰｖ４パケットの目的地アドレスは、デュアルスタックホスト１００のＩＰｖ４アドレスであり、このパケットは、ＤＳＴＭ ＴＥＰ３００に伝達される。

すなわち、図１０のように、ＩＰｖ４−ｏｎｌｙサーバ５００から転送される経路メッセージ（path message）は、まず、ＤＳＴＭ ＴＥＰ３００に転送される。この際、経路メッセージは、経路データ（Path data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）とを含む構造を有する。

ここで、経路メッセージ（path message）に含まれたＩＰｖ４パケットの目的地アドレスは、デュアルスタックホスト１００のＩＰｖ４アドレスであり、このパケットは、ＤＳＴＭ ＴＥＰ３００に転送される。

ＤＳＴＭ ＴＥＰ３００は、このパケットの目的地アドレスに存在するＩＰｖ４アドレスを用いて自身のマッピングテーブルから該当ＩＰｖ６アドレスを抽出した後、この情報を用いてＩＰｖ６パケットにカプセル化した後、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてデュアルスタックホスト１００に転送（Send EtoE Path message(IPv4-in-IPv6)）（ステップＳ８０）する。

すなわち、図１０のように、ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ４−ｏｎｌｙサーバ５００から転送されたパケットの目的地アドレスに存在するＩＰｖ４アドレスを用いて自身のマッピングテーブルから該当するＩＰｖ６アドレスを抽出する。

ＤＳＴＭ ＴＥＰ３００は、マッピングテーブルで抽出したＩＰｖ６アドレス情報を用いてＩＰｖ６パケットにカプセル化した後、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いてデュアルスタックホスト１００に転送する。

ここで、ＤＳＴＭ ＴＥＰ３００がデュアルスタックホスト１００に転送する経路メッセージは、経路データ（Path data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）とを含む構造を有する。

次に、ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ６網内でのリソース予約のために、ｒｓｖｐの経路メッセージを生成し、ＩＰｖ６ヘッダーを追加した後、デュアルスタックホスト１００に転送（ステップＳ９０）する。

すなわち、図１１のように、ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ６網内でのリソース予約のためにＲＳＶＰの経路メッセージを生成し、ＩＰｖ６ヘッダーを追加した後に、デュアルスタックホスト１００に転送する。

この際、デュアルスタックホスト１００に転送される経路メッセージは、経路データ（Path data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）とを含む構造を有する。

ＩＰｖ４−ｏｎｌｙサーバ５００から経路メッセージを受信したデュアルスタックホスト１００は、ＩＰｖ４網内でのリソース予約のために予約メッセージを生成し、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて転送（Send EtoE Resv message(IPv4-in-IPv6)）（ステップＳ１００）する。

すなわち、図１２に示されたように、デュアルスタックホスト１００は、マルチメディアトラフィックを受信しようとするメッセージを転送した後に、ＤＳＴＭ ＴＥＰ３００から経路メッセージを受信した場合には、ＩＰｖ４網内でのリソース予約のために予約メッセージを生成し、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて転送する。

この際、ＤＳＴＭ ＴＥＰ３００に転送される予約メッセージは、リソース予約要請データ（Resv data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）とを含む構造を有する。

このパケットは、ＤＳＴＭ ＴＥＰ３００に転送されることによって、ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ６ヘッダーを除去した後に、予約メッセージに含まれているＩＰｖ４パケットをＩＰｖ４−ｏｎｌｙサーバ５００に転送（Decapsulate IPv6 and Sends EtoE Resv message）（ステップＳ１１０）する。ここで、このパケットは、ホップバイホップ（hop-by-hop）の形態でサーバに伝達される。

すなわち、図１２に示すように、ＩＰｖ４−ｏｎｌｙサーバ５００に転送されるパケットは、リソース予約要請データ（Resv data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）とを含む構造を有する。

この際、メッセージが伝達されながら各々のルータにリソースを予約し、仮に、このパケットがＩＰｖ４−ｏｎｌｙサーバ５００に到達すれば、ＤＳＴＭ ＴＥＰ３００とＩＰｖ４−ｏｎｌｙサーバ５００との間には、ＱｏＳ連結が設定される。しかしながら、これだけで終端間ＱｏＳ連結が設定されるわけではない。

すなわち、終端間ＱｏＳ連結が設定されるためには、ＩＰｖ６網内でもリソース予約がなされなければならない。このために、デュアルスタックホスト１００は、別の予約メッセージを生成し、このメッセージにＩＰｖ６ヘッダーを付けた後に、ＤＳＴＭ ＴＥＰ３００を目的地アドレスにしてＩＰｖ６スタックを用いて転送（Sends Resv message（ＩＰｖ６））（ステップＳ１２０）する。

すなわち、図１３に示されたように、ＤＳＴＭ ＴＥＰ３００に転送される予約メッセージは、リソース予約要請データ（Resv data）と、ＲＳＶＰヘッダー（ＲＳＶＰ Ｈｄｒ）と、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）と、を含む構造を有する。

この際、このメッセージは、ホップバイホップ（hop-by-hop）の形態でＤＳＴＭ ＴＥＰ３００に伝達され、伝達されながら各々のルータにリソースを予約する。このパケットがＤＳＴＭ ＴＥＰ３００に到達した場合には、デュアルスタックホスト１００とＤＳＴＭ ＴＥＰ３００との間にＱｏＳ連結が設定される。

つまり、デュアルスタックホスト１００とＤＳＴＭ ＴＥＰ３００との間、そしてＤＳＴＭ ＴＥＰ３００とＩＰｖ４−ｏｎｌｙサーバ５００との間にＱｏＳ連結が設定された場合に、終端間ＱｏＳ連結が設定される。

以上において説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施例及び添付された図面に限定されるものではない。

一般的なＲＳＶＰのＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクトを説明する図である。 一般的なＲＳＶＰのＮＯＤＥ＿ＣＨＡＲオブジェクトを説明する図である。 一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰの経路メッセージフローを説明する図である。 一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰの予約メッセージフローを説明する図である。 一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰのトンネル経路メッセージフローを説明する図である。 一般的なＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰのトンネル予約メッセージフローを説明する図である。 一般的なＩＰｖ４／ＩＰｖ６統合網における多数のトンネルを介してパケットを転送することを説明する図である。 本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステムの構成を示す図である。 本実施形態のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法を示す図である。 本実施形態のＩＰｖ４／ＩＰｖ６統合網における終端間経路メッセージ転送過程を示す図である。 本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＩＰｖ６網におけるリソース予約のためのメッセージ転送過程を示す図である。 本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＩＰｖ４網におけるリソース予約過程を示す図である。 本実施形態のＩＰｖ４／ＩＰｖ６統合網におけるＩＰｖ６網におけるリソース予約過程を示す図である。

符号の説明

１００ デュアルスタックホスト
２００ ＤＳＴＭサーバ
３００ ＤＳＴＭ ＴＥＰ
４００ ＤＮＳサーバ
５００ ＩＰｖ４−ｏｎｌｙサーバ

Claims (27)

1. ＤＳＴＭ ＴＥＰにより結合するＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポート方法であって、
   ＩＰｖ６網内のデュアルスタックホストが、前記ＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間ＱｏＳセッション連結要請メッセージを転送する段階と、
   前記ＩＰｖ４サーバが、前記ＤＳＴＭ ＴＥＰを介して前記デュアルスタックホストに終端間経路メッセージを転送する段階と、
   前記ＤＳＴＭ ＴＥＰが、前記デュアルスタックホストにＩＰｖ６網内でのリソース予約のための経路メッセージを転送する段階と、
   前記デュアルスタックホストが、前記ＤＳＴＭ ＴＥＰを介して前記ＩＰｖ４サーバに終端間リソース予約要請メッセージを転送し、ＩＰｖ４網内でのリソース予約を設定する段階と、
   前記デュアルスタックホストが、前記ＤＳＴＭ ＴＥＰにリソース予約要請メッセージを転送し、ＩＰｖ６網内でのリソース予約を設定する段階と、
   を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
2. 前記ＩＰｖ６網内のデュアルスタックホストが、前記ＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間ＱｏＳセッション連結要請メッセージを転送する段階で、
   前記ＱｏＳセッション連結要請メッセージは、ＩＰｖ４ヘッダーを有し、ＩＰｖ６にカプセル化され、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて前記ＤＳＴＭ ＴＥＰに転送されることを特徴とする請求項１に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
3. 前記ＤＳＴＭ ＴＥＰは、前記デュアルスタックホストから転送されたメッセージに含まれるソースＩＰｖ６アドレス及び内部に存在するソースＩＰｖ４アドレスに関するマッピング情報をテーブルに格納した後に、ＩＰｖ６ヘッダーを除去したＩＰｖ４パケットを前記ＩＰｖ４サーバに転送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
4. 前記ＩＰｖ４サーバが、前記ＤＳＴＭ ＴＥＰを介して前記デュアルスタックホストに終端間経路メッセージを転送する段階で、
   前記ＤＳＴＭ ＴＥＰに転送される経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、を含む構造を有することを特徴とする請求項１に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
5. 前記終端間経路メッセージのＩＰｖ４パケットの目的地アドレスは、前記デュアルスタックホストのＩＰｖ４アドレスであることを特徴とする請求項４に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
6. 前記ＤＳＴＭ ＴＥＰは、前記ＩＰｖ４パケットの目的地アドレスに存在するＩＰｖ４アドレスにマッピングされる当該ＩＰｖ６アドレスをマッピングテーブルから抽出し、ＩＰｖ６パケットにカプセル化した後、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて前記デュアルスタックホストに転送することを特徴とする請求項５に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
7. 前記ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングされた経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項６に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
8. 前記ＤＳＴＭ ＴＥＰが、前記デュアルスタックホストにＩＰｖ６網内でのリソース予約のための経路メッセージを転送する段階で、
   前記経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項１に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
9. 前記デュアルスタックホストが、前記ＤＳＴＭ ＴＥＰを介して前記ＩＰｖ４サーバに終端間リソース予約要請メッセージを転送し、ＩＰｖ４網内でのリソース予約を設定する段階で、
   前記終端間リソース予約要請メッセージは、ＩＰｖ４ヘッダーを有し、ＩＰｖ６にカプセル化され、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて前記ＤＳＴＭ ＴＥＰに転送されることを特徴とする請求項１に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
10. 前記ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、リソース予約要請データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項９に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
11. 前記ＤＳＴＭ ＴＥＰは、前記デュアルスタックホストから転送されたリソース予約要請メッセージからＩＰｖ６ヘッダーを除去したＩＰｖ４パケットを前記ＩＰｖ４サーバに転送することを特徴とする請求項１０に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
12. 前記ＩＰｖ４サーバに転送されるＩＰｖ４パケットは、ホップバイホップ（hop-by-hop）の形態で転送されながら各ルータにリソースを予約設定することを特徴とする請求項１１に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
13. 前記デュアルスタックホストが前記ＤＳＴＭ ＴＥＰにリソース予約要請メッセージを転送し、ＩＰｖ６網内でのリソース予約を設定する段階で、
    前記リソース予約要請メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項１に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
14. 前記ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、ホップバイホップの形態で転送されながら各ルータにリソースを予約設定することを特徴とする請求項１３に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるＲＳＶＰサポート方法。
15. ＩＰｖ６網内のデュアルスタックホストと、ＩＰｖ４網内のＩＰｖ４サーバと、前記デュアルスタックホストと前記ＩＰｖ４サーバとを接続するＤＳＴＭ ＴＥＰと、を有するＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステムであって、
    前記デュアルスタックホストが、前記ＤＳＴＭ ＴＥＰを介してＩＰｖ４サーバに終端間ＱｏＳセッション連結要請メッセージを転送し、
    前記ＩＰｖ４サーバが、前記ＤＳＴＭ ＴＥＰを介して前記デュアルスタックホストに終端間経路メッセージを転送し、
    前記ＤＳＴＭ ＴＥＰが、前記デュアルスタックホストにＩＰｖ６網内でのリソース予約のための経路メッセージを転送し、
    前記デュアルスタックホストが、前記ＤＳＴＭ ＴＥＰを介して前記ＩＰｖ４サーバに終端間リソース予約要請メッセージを転送し、前記ＩＰｖ４網内でのリソース予約を設定し、
    前記デュアルスタックホストが、前記ＤＳＴＭ ＴＥＰにリソース予約要請メッセージを転送し、前記ＩＰｖ６網内でのリソース予約を設定する
    ことを特徴とするＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
    
16. 前記ＤＳＴＭ ＴＥＰに転送される終端間経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、を含む構造を有することを特徴とする請求項１５に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
17. 前記終端間経路メッセージのＩＰｖ４パケットの目的地アドレスは、前記デュアルスタックホストのＩＰｖ４アドレスであることを特徴とする請求項１６に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
18. 前記ＤＳＴＭ ＴＥＰは、前記ＩＰｖ４パケットの目的地アドレスに存在するＩＰｖ４アドレスにマッピングされる当該ＩＰｖ６アドレスをマッピングテーブルから抽出し、ＩＰｖ６パケットにカプセル化した後、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて前記デュアルスタックホストに転送することを特徴とする請求項１７に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
19. 前記ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングされた経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項１８に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
20. 前記ＤＳＴＭ ＴＥＰは、前記ＩＰｖ６網内でのリソース予約のための経路メッセージを前記デュアルスタックホストに転送することを特徴とする請求項１５に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
21. 前記ＩＰｖ６網内でのリソース予約のための経路メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項２０に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
22. 前記ＤＳＴＭ ＴＥＰに転送される終端間リソース予約要請メッセージは、ＩＰｖ４ヘッダーを有し、ＩＰｖ６にカプセル化され、ＩＰｖ４−ｉｎ−ＩＰｖ６トンネリングを用いて前記ＤＳＴＭ ＴＥＰに転送されることを特徴とする請求項１５に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
23. 前記ＤＳＴＭ ＴＥＰに転送される終端間リソース予約要請メッセージは、リソース予約要請データと、ＲＳＶＰヘッダーと、ＩＰｖ４ヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項２２に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
24. 前記ＤＳＴＭ ＴＥＰは、前記デュアルスタックホストから転送された終端間リソース予約要請メッセージからＩＰｖ６ヘッダーを除去したＩＰｖ４パケットを前記ＩＰｖ４サーバに転送することを特徴とする請求項２３に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
25. 前記ＩＰｖ４サーバに転送されるＩＰｖ４パケットは、ホップバイホップの形態で転送されながら各ルータにリソースを予約設定することを特徴とする請求項２４に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
26. 前記ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、経路データと、ＲＳＶＰヘッダーと、ＩＰｖ６ヘッダーと、を含む構造を有することを特徴とする請求項1５に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。
27. 前記ＤＳＴＭ ＴＥＰに転送されるリソース予約要請メッセージは、ホップバイホップの形態で転送されながら各ルータにリソースを予約設定することを特徴とする請求項２６に記載のＩＰｖ４／ＩＰｖ６統合網におけるＲＳＶＰサポートシステム。