JP4347316B2 - ＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるセッションリソースの予約方法及びそのシステム - Google Patents

Description

本発明は、ＩＰｖ４／ＩＰｖ６統合ネットワークシステムでのセッションリソース（経路資源）の予約方法及びそのシステムに関し、より詳細には、４ｔｏ６−ＤＳＴＭ環境でＲＳＶＰメカニズムによって資源を予約する際に、ＤＳＴＭに従ってＩＰｖ６ホストにＩＰｖ４アドレス情報を割り当てながらトンネルセッションの開始ノードに最終ノードのＲＳＶＰ支援が可能であるか否かをあらかじめ知らせることが可能な、ＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおけるセッションリソース（経路資源）の予約方法及びそのシステムに関する。

インターネットは、情報化社会の核心的なインフラとして位置付けられ、ＶｏＩＰ（Ｖｏｉｃｅ ｏｆ ＩＰ）及びインターネットテレビのようなリアルタイム且つ高品質のサービスの発展に伴って、インターネットを介して交換されるトラフィックが、テキスト情報を含むトラフィックから音声情報、イメージ情報及び映像情報を含むマルチメディアトラフィックに変化し、トラフィックの量も爆発的に増加していることが現状である。

現在構築されているＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ４）基盤のインターネットは、急激に増加するホストとマルチメディアトラフィックを受け入れるために、小さいアドレス情報と複雑なヘッダー構造を使用している。このため、トラフィックを処理するルータ及びノードの処理速度が遅れて、全体としてのインターネットの性能を低下させるという問題点がある。

このようなＩＰｖ４基盤のインターネットの問題点を解決するために提案されたＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６）は、１２８ビットの拡張したアドレス体系と、単純化されたヘッダー構造、向上したＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）及び強化されたセキュリティなどの特徴を有している。

しかし、現在のインターネットは、ＩＰｖ４網に構築されて広く運用されているため、短期間にＩＰｖ６網に完全に切り替えることは、現実的に不可能なので、当分の間ＩＰｖ４網とＩＰｖ６網が共存し、次第にＩＰｖ６網に変換されるだろう。

したがって、ＩＰｖ６網の構築ためには、ＩＰｖ６ホストやルータが、現在構築されているＩＰｖ４網のＩＰｖ４ホスト及びルータと共存することが不可欠となる。

したがって、トラフィックの急激な増加に効率的に対応するためには、音声、ビデオ及びデータのような異なる特徴を有するトラフィックに、各トラフィックが要求するＱｏＳを提供できるインターネットインフラを構築することが必要であり、ＩＰｖ４網とＩＰｖ６網が混在したＩＰｖ４／ＩＰｖ６統合網においてマルチメディアトラフィックのためのＱｏＳを終端間に提供できるモデルの定義が要求される。

ＩＰｖ４ホスト及びルータと、ＩＰｖ６ホスト及びルータとが混在したＩＰｖ４／ＩＰｖ６統合網においてパケットを処理する方法は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）により提案された。この方法は、二重スタック（ｄｕａｌ ｓｔａｃｋ）を用いた方法、ヘッダー変換（ｈｅａｄｅｒ ｔｒａｎｓｌａｔｉｏｎ）方法、トンネリング（ｔｕｎｎｅｌｉｎｇ）方法などを含んでいる。

二重スタックを用いた方法は、ＩＰｖ６網に完全に移行する前に、全てのホスト及びルータが二重スタックプロトコルを有することを意味する。すなわち、インターネットの全てのシステムがＩＰｖ６を使用するまでＩＰｖ４とＩＰｖ６を同時に運用する方法である。

ヘッダー変換方法は、大部分のインターネットがＩＰｖ６を使用するが、未だ一部のシステムがＩＰｖ４を使用する場合に有用な方法である。すなわち、送信者は、ＩＰｖ６を使用することを希望するが、受信者がＩＰｖ６を理解しない場合（ＩＰｖ６に対応できない場合）、送信者がＩＰｖ６パケットのヘッダーをＩＰｖ４ヘッダーに変換して転送する方法である。

トンネリング方法は、ＩＰｖ６を使用する２つのホストが相互に通信を行う場合であって、ＩＰｖ４を使用する領域を通過しなければならない場合に使われる方法である。すなわちＩＰｖ６パケットが、ＩＰｖ４を使用する領域に入る際に、ＩＰｖ６パケットをＩＰｖ４パケット内にカプセル化し、ＩＰｖ４領域から出る際に、脱カプセル化する方法である。

ＩＰｖ４／ＩＰｖ６統合網でパケットを処理するトンネリング方法のうち１つの規約であるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）は、異なるＱｏＳを要求するトラフィックをＩＰ階層に収容するために予めネットワーク資源を予約するプロトコルである。

ＲＳＶＰは、１つのユーザが送信地から目的地まで一種の仮想回線であるフロー（ｆｌｏｗ）を開設し、送信地と目的地との間の全てのルータがフロー毎に必要な資源を予約することによって、ＱｏＳを保障するフロー基盤のモデルであると言える。

ここで、フローは、同じソース（ｓｏｕｒｃｅ）アドレス情報及び目的地（ｄｅｓｔｉｎａｔｉｏｎ）アドレス情報と、同じソースポート情報及び目的地ポート情報と、同じセッション識別（ＩＤｅｎｔｉｆｉｅｒ）情報を有するパケットの集り（集合）を意味する。

現在ＲＳＶＰでは、トンネルを含む経路上で終端間のＲＳＶＰを支援するために、１つのフローに対するＲＳＶＰセッションを終端−対−終端（ｅｎｄ−ｔｏ−ｅｎｄ）セッションとトンネルセッションとに分け、２つのセッションを相互にマッピングし、各セッションに対する資源予約を別々に行うことによって、トンネル内においても終端間のセッションと同じ資源を予約できるようにした。

そして、ＩＥＴＦ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｔｒａｎｓｉｔｉｏｎ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ（Ｎｇｔｒａｎｓ ＷＧ）を中心として提案された変換メカニズムのうち、ＮＡＴ−ＰＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｔｒａｎｓｌａｔｉｏｎ）のようなＩＰｖ６変換（Ｔｒａｎｓｌａｔｉｏｎ）メカニズムは、ＩＰｖ６ホストとＩＰｖ４ホストとの間に通信を可能にするためのプロトコルスタック変換を提供する。

しかし、このような変換メカニズムは、ＩＰｖ６パケットをＩＰｖ４パケットに、またはＩＰｖ４パケットをＩＰｖ６パケットに変換するので、ネットワーク階層とトランスポート階層での終端間のセキュリティを支援することができず、ＩＰｖ６ヘッダーとＩＰｖ４ヘッダーを完璧に変換できないという問題点を有する。

また、アプリケーション階層プロトコルが自分のデータにＩＰアドレスを含む場合には、変換を支援せず、このようなアプリケーション階層プロトコルを収容するためには、該当するアプリケーション階層プロトコルに対するアプリケーション階層ゲートウエー（Ａｐｐｌｉｃａｔｉｏｎ Ｌｅｖｅｌ Ｇａｔｅｗａｙ：ＡＬＧ）を有しなければならないという問題点を有する。

これに対し、トンネリングと同様にＩＰｖ４スタックとＩＰｖ６スタックを共に有するデュアルスタックを使用するＤＳＴＭ（Ｄｕａｌ Ｓｔａｃｋ Ｔｒａｎｓｉｔｉｏｎ Ｍｅｃｈａｎｉｓｍ）は、プロトコル変換による問題が生じることなく、デュアルスタックホストとＩＰｖ４ホストとの間の透明な連結（Ｔｒａｎｓｐａｒｅｎｔ ｃｏｎｎｅｃｔｉｏｎ）を支援する。

しかしながら、ＤＳＴＭでは、デュアルスタックホストからＩＰｖ４ホストへの連結についての初期設定（初期化）だけを考慮していて、ＩＰｖ４ノードからＩＰｖ６網内のデュアルスタックホストに連結を設定する場合には、連結を提供できないという問題点を有する。

このようなＤＳＴＭの問題点を解決するために、ＩＰｖ４ホストがＩＰｖ６網内のデュアルスタックホストへの連結を設定する場合にも、ＩＰｖ４ホストとＩＰｖ６網内のデュアルスタックホストとの間に透明な連結を提供できる４ｔｏ６ ＤＳＴＭ（ＩＰｖ４ｔｏＩＰｖ６ ＤＳＴＭ）変換メカニズムが提案された。

しかしながら、４ｔｏ６ ＤＳＴＭには、ＱｏＳが考慮されていないことから、４ｔｏ６ ＤＳＴＭ環境で終端間のＱｏＳを提供するために、トンネル区間を含んでいる終端間の経路資源を予約できるトンネルＲＳＶＰメカニズムが使用される。

‘ＲＦＣ ２７４６（Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）２７４６）’では、トンネル上にＲＳＶＰを支援できるメカニズムを定義しているが、トンネルの開始ノードがトンネルの最終のノードから「ＮＯＤＥ＿ＣＨＡＲオブジェクト」を含む予約（Ｒｅｓｖ）メッセージを受信した後でなければ、トンネル上のＲＳＶＰセッションを設定できないという制限を有している。

このような制限は、トンネルの最終のノードがトンネルＲＳＶＰメカニズムを支援できるか否かについて、開始ノードがあらかじめ知ることができないために生じている。

図１は、一般的なＤＳＴＭメカニズムを説明するためのブロック図である。

図１に示すように、ＤＳＴＭ（Ｄｕａｌ Ｓｔａｃｋ Ｔｒａｎｓｉｔｉｏｎ Ｍｅｃｈａｎｉｓｍ）は、ＩＰｖ６網内に存在するデュアルスタックホスト（ＤＳＴＭホスト）１０が、外部のＩＰｖ４網に存在するホスト（ＩＰｖ４ホスト）２０とトラフィックを交換できるようにするメカニズムである。

このようなＤＳＴＭホスト１０とＤＳＴＭサーバー４０は、ＩＰｖ６網に属していて、ＩＰｖ４ホスト２０は、ＩＰｖ４網に属している。ＤＳＴＭ ＴＥＰ（ＤＳＴＭｔｕｎｎｅｌ ｅｎｄ ｐｏｉｎｔｓ）３０は、ＩＰｖ６網とＩＰｖ４網との間の境界に位置する。

ＤＳＴＭホスト１０がＩＰｖ４ホスト２０とトラフィックを交換しようとする場合、ＤＳＴＭサーバー４０に、当該ＤＳＴＭホスト１０自身が使用すべきＩＰｖ４アドレス情報の割り当てを要請する。

ＤＳＴＭサーバー４０は、ＤＳＴＭホスト１０からＩＰｖ４アドレス情報割当を要請を受信した場合には、一時的ＩＰｖ４アドレス情報とＤＳＴＭ ＴＥＰ３０のＩＰｖ６アドレス情報をＤＳＴＭホスト１０に伝送する。

ＤＳＴＭホスト１０は、割り当てられたＩＰｖ４アドレス情報とＤＳＴＭ ＴＥＰ３０のＩＰｖ６アドレス情報を用いて、ＩＰｖ６パケットをＩＰｖ４パケットにカプセル化し、ＤＳＴＭ ＴＥＰ３０にＩＰｖ４−ｏｖｅｒ−ＩＰｖ６トンネリングし、ＤＳＴＭ ＴＥＰ３０は、トンネリングされたＩＰｖ４パケットをＩＰｖ４網へ伝送する。

ＤＳＴＭ ＴＥＰ３０は、ＤＳＴＭホスト１０のＩＰｖ４アドレス情報とＩＰｖ６アドレス情報に関するマッピング情報を格納し、このマッチング情報に応じてＩＰｖ４ホスト２０から受信されるＩＰｖ４パケットをＤＳＴＭホスト１０にトンネリングする。

このようなＤＳＴＭは、トンネリング方法によりデュアルスタックホスト、すなわち、ＤＳＴＭホスト１０とＩＰｖ４ホスト２０との間に透明な経路を提供するので、ＮＡＴ−ＰＴのようなプロトコル変換による問題点が発生しないという長所がある。

しかし、ＤＳＴＭは、ＩＰｖ６網内のＤＳＴＭホスト１０からＩＰｖ４網内のＩＰｖ４ホストへの連結を設定する場合にだけ当該連結を支援し、ＩＰｖ４網内のＩＰｖ４ホスト２０からＩＰｖ６網内のＤＳＴＭホスト１０に連結を設定する場合には、連結を支援できないという問題点を有する。

このようなＤＳＴＭの問題点を解決するために、ＩＰｖ４ホスト２０がＩＰｖ６網内のＤＳＴＭホスト１０に連結を設定する場合にも、ＩＰｖ４ホスト２０とＤＳＴＭホスト１０との間に透明な連結を提供するための４ｔｏ６ ＤＳＴＭメカニズムが提案された。

図２は、一般的な４ｔｏ６ ＤＳＴＭメカニズムを説明するためのブロック図である。

図２を参照すれば、４ｔｏ６ ＤＳＴＭメカニズムは、ＤＳＴＭサーバー４０、ＤＳＴＭ ＴＥＰ３０、デュアルスタックであるＤＳＴＭホスト１０及びＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバー５１、５２で構成され、ＤＳＴＭサーバー４０は、ＤＮＳ−ＡＬＧ（ＤＮＳ−Ａｐｐｌｉｃａｔｉｏｎ Ｌｅｖｅｌ Ｇａｔｅｗａｙ）４１、ＤＳＴＭマネジャー４２及びマッピングテーブル４３で構成される。

ＤＳＴＭサーバー４０は、ＤＳＴＭホスト１０に一時的ＩＰｖ４アドレス情報を割り当て、割り当てられたＩＰｖ４アドレス情報とＤＳＴＭホスト１０のＩＰｖ６アドレス情報に関するマッピング情報をマッピングテーブル４３で管理する。

ＤＳＴＭ ＴＥＰ３０は、ＩＰｖ６網とＩＰｖ４網との境界に位置し、且つパケットをＤＳＴＭホスト１０にトンネリングしたり、ＩＰｖ４ホスト２０へ伝送する。

ＤＮＳサーバー５１、５２は、ＤＮＳ問い合わせメッセージを受信すると、ＩＰアドレス情報が含まれるＤＮＳ応答メッセージを提供する。

ＩＰｖ４ホスト２０は、ＩＰｖ６網に属しているＤＳＴＭホスト１０に接続してパケットを伝送するためには、ＤＳＴＭホスト１０のＩＰｖ４アドレス情報を把握しなければならない。一般的に、ＩＰｖ４ホスト２０は、ＩＰｖ４網内のＩＰｖ４ ＤＮＳサーバー５１に、ＤＳＴＭホスト１０のＩＰｖ４アドレス情報を得るために、当該ＤＳＴＭホスト１０のＩＰｖ４アドレス情報を問い合わせするＡタイプ（Ａ：ＩＰｖ４アドレスに対するＤＮＳレコードタイプ）のＤＮＳ問い合わせメッセージを伝送する（ステップＳ１）。

ＩＰｖ４ ＤＮＳサーバー５１は、ＤＳＴＭホスト１０に関するＤＮＳ情報を格納していないため、ＤＳＴＭホスト１０のＩＰｖ４アドレス情報を管理しているＩＰｖ６網内のＩＰｖ６ ＤＮＳサーバー５２へＤＮＳ問い合わせメッセージを伝送する（ステップＳ２）。

ＩＰｖ４ ＤＮＳサーバー５１が転送したＤＮＳ問い合わせメッセージは、ＩＰｖ６網とＩＰｖ４網との境界に存在するＤＳＴＭ ＴＥＰ３０へ伝送される。ＤＳＴＭ ＴＥＰ３０は、受信したＤＮＳ問い合わせメッセージの目的地アドレス情報がＤＳＴＭサーバー４０のアドレス情報であることから、当該ＤＮＳ問い合わせメッセージをＤＳＴＭサーバー４０へ伝送する。

ＤＳＴＭサーバー４０のＤＮＳ−ＡＬＧ４１は、受信したＡタイプのＤＮＳ問い合わせメッセージを、ＩＰｖ４アドレス情報とＩＰｖ６アドレス情報を共に要請するＡＡＡＡタイプ（ＡＡＡＡ：ＩＰｖ６アドレスに対するＤＮＳレコードタイプ）のＤＮＳ問い合わせメッセージに変換し、ＩＰｖ６ ＤＮＳサーバー５２へ伝送する（ステップＳ３）。

ＤＳＴＭサーバー４０は、ＩＰｖ６ ＤＮＳサーバー５２からＤＳＴＭホスト１０のＩＰｖ４アドレスとＩＰｖ６アドレス情報が共に含まれるＡＡＡＡタイプのＤＮＳ応答メッセージを受信すると（ステップＳ４）、そのＡＡＡＡタイプのＤＮＳ応答メッセージをＩＰｖ４アドレス情報だけを含むＡタイプのＤＮＳ応答メッセージに変換する。

そして、ＤＮＳ−ＡＬＧ４１は、ＡタイプのＤＮＳ応答メッセージをＩＰｖ４ ＤＮＳサーバー５１へ伝送する。なお、ＤＮＳ−ＡＬＧ４１は、受信したＡＡＡＡタイプのＤＮＳ応答メッセージにＩＰｖ６アドレス情報だけが含まれている場合には、ＤＳＴＭマネジャー４２に一時的（臨時の）ＩＰｖ４アドレス情報の割り当てを要請する（ステップＳ５）。

ＤＳＴＭマネジャー４２は、自分のＩＰｖ４アドレスプール（ＩＰｖ４ ａｄｄｒｅｓｓ ｐｏｏｌ）から臨時の１つのＩＰｖ４アドレス情報をＤＳＴＭホスト１０に割り当てる（ステップＳ６）。

ＤＳＴＭマネジャー４２は、マッピングテーブル４３に、ＤＳＴＭホスト１０のＩＰｖ６アドレス情報及び割り当てられたＩＰｖ４アドレス情報と、割り当てられたＩＰｖ４アドレス情報が有効に使用できる時間を示す有効時間（ｌｉｆｅｔｉｍｅ）情報などのようなマッピング情報とを格納し、有効時間情報に関するタイマーを設定する。

そして、ＤＳＴＭマネジャー４２は、割り当てたＩＰｖ４アドレス情報をＩＰｖ６ ＤＮＳサーバー５２に動的（ｄｙｎａｍｉｃ）に登録する（ステップＳ７）。

ＤＳＴＭマネジャー４２は、ＤＳＴＭホスト１０にＤＳＴＭアドレス割当メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ａｌｌｏｃａｔｉｏｎ Ｍｅｓｓａｇｅ）を伝送し、トンネリングに使用される、一時的に割り当てられたＩＰｖ４アドレス情報とＤＳＴＭ ＴＥＰ３０のＩＰｖ６アドレス情報及び有効時間情報を伝送する（ステップＳ８）。

ＤＳＴＭホスト１０は、ＤＳＴＭマネジャー４２からＤＳＴＭアドレス割当メッセージを受信したならば、ＩＰｖ４アドレス情報とＤＳＴＭ ＴＥＰ３０のＩＰｖ６アドレス情報をキャッシュ（ｃａｃｈｅ）に格納し、有効時間情報に関するタイマーを設定する。

そして、ＤＳＴＭホスト１０は、ＤＳＴＭアドレス割当確認応答メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ａｌｌｏｃａｔｉｏｎ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｍｅｓｓａｇｅ）をＤＳＴＭサーバー４０へ伝送し、アドレス割当が成功的に処理されたことを知らせる（ステップＳ９）。

ＤＳＴＭサーバー４０は、ＤＳＴＭホスト１０からＤＳＴＭアドレス割当応答メッセージを受信すると、ＤＮＳ−ＡＬＧ４１へＤＳＴＭホスト１０に割り当てられたＩＰｖ４アドレス情報を伝送する（ステップＳ１０）。

ＤＮＳ−ＡＬＧ４１は、ＤＳＴＭマネジャー４２から受信したＩＰｖ４アドレス情報が含まれるＡタイプのＤＮＳ応答メッセージをＩＰｖ４ ＤＮＳサーバー５１へ伝送し（ステップＳ１１）、ＩＰｖ４ ＤＮＳサーバー５１は、ＩＰｖ４ホスト２０へＤＮＳ応答メッセージを伝送する（ステップＳ１２）。

その後、ＩＰｖ４ホスト２０は、受信したＤＮＳ応答メッセージから得られるＤＳＴＭホスト１０のＩＰｖ４アドレス情報を用いて、ＤＳＴＭホスト１０へＩＰｖ４パケットを伝送する（ステップＳ１３）。

ＤＳＴＭ ＴＥＰ３０は、ＩＰｖ４ホスト２０から受信したＩＰｖ４パケットをＩＰｖ４−ｏｖｅｒ−ＩＰｖ６トンネリングを用いてＤＳＴＭホスト１０へ伝送する。

なお、受信したＩＰｖ４パケットの目的地アドレス情報に関するＩＰｖ６アドレス情報が当該ＩＰｖパケットから検索されない場合には、ＤＳＴＭ ＴＥＰ３０は、 ＤＳＴＭサーバー４０へＤＳＴＭバインディング要請メッセージＤＳＴＭ（Ｂｉｎｄｉｎｇ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）を転送し、ＩＰｖ４パケットの目的地アドレス情報にマッピングされるＩＰｖ６アドレス情報を要請する（ステップ１４）。

ＤＳＴＭサーバー４０は、ＤＳＴＭ ＴＥＰ３０からＤＳＴＭバインディング要請メッセージを受信すると、マッピングテーブル４３からＩＰｖ４アドレス情報にマッピングされるマッピング情報、すなわちＩＰｖ６アドレス情報及び有効時間情報を検索し、ＤＳＴＭバインディング更新メッセージ（ＤＳＴＭ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ Ｍｅｓｓａｇｅ）を通じてＤＳＴＭ ＴＥＰ３０へ転送する（ステップＳ１５）。

ＤＳＴＭ ＴＥＰ３０は、ＤＳＴＭサーバー４０からＤＳＴＭバインディング更新メッセージを受信すると、ＤＳＴＭ ＴＥＰ３０自身のマッピングテーブルにＤＳＴＭホスト１０のＩＰｖ４アドレス情報にマッピングされたＩＰｖ６アドレス情報及び有効時間情報を格納し、有効時間情報に関するタイマーを設定する。

ＤＳＴＭ ＴＥＰ３０は、格納したマッピング情報を用いてＩＰｖ４ホスト２０から受信されるＩＰｖ４パケットをＤＳＴＭホスト１０にＩＰｖ４−ｏｖｅｒ−ＩＰｖ６トンネリングする。

ＤＳＴＭホスト１０は、ＤＳＴＭ ＴＥＰ３０からトンネリングされたパケットを受信すると、脱カプセル化し、ＩＰｖ４ホスト２０が伝送したオリジナルのＩＰｖ４パケットを受信する。

ＤＳＴＭホスト１０は、ＤＳＴＭサーバー４０によって割り当てられたＩＰｖ４アドレス情報とＤＳＴＭ ＴＥＰ３０のＩＰｖ６アドレス情報とを用いてＤＳＴＭ ＴＥＰ３０にＩＰｖ４パケットをＩＰｖ４−ｏｖｅｒ−ＩＰｖ６トンネリングし（ステップＳ１７）、ＤＳＴＭ ＴＥＰ３０が、受信したＩＰｖ４パケットを脱カプセル化し、ＩＰｖ４網へ伝送する（ステップＳ１８）。

ＤＳＴＭマネジャー４２は、マッピングテーブル４３のエントリー毎に設定しておいたタイマーが満了した場合（すなわち、ＤＳＴＭホスト１０に割り当てたＩＰｖ４アドレスに対する有効時間が経過した場合）、マッピングテーブル４３から該当するエントリーを削除する。そして、ＤＳＴＭマネジャー４２は、ＩＰｖ６ ＤＮＳサーバー５２からＩＰｖ４アドレス割り当ての際に登録されたＤＳＴＭホスト１０のＩＰｖ４アドレス情報の削除要請をし、ＤＳＴＭホスト１０に割り当てられたＩＰｖ４アドレスを回収する。

ＤＳＴＭホスト１０は、割り当てられたＩＰｖ４アドレス情報を、有効時間が経過した後も継続して使用するために、有効時間が満了する前（経過する前）に、ＤＳＴＭサーバー４０へＤＳＴＭアドレス延長要請メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ｅｘｔｅｎｓｉｏｎ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）を伝送し、割り当てられたＩＰｖ４アドレス情報の有効時間情報を延長する。

ＤＳＴＭサーバー４０は、ＤＳＴＭホスト１０からＤＳＴＭアドレス延長メッセージを受信すると、マッピングテーブル４３から該当するエントリーを探し出し、有効時間を延長し、該当するタイマーを再設定する。

そして、ＤＳＴＭサーバー４０は、ＤＳＴＭホスト１０にＤＳＴＭアドレス延長応答メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ｅｘｔｅｎｓｉｏｎ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｍｅｓｓａｇｅ）を伝送する。ＤＳＴＭ ＴＥＰ３０は、自身のマッピングテーブルのエントリー毎に設定しておいたタイマーが満了するまで、該当するマッピング情報が使用されていない場合には、当該マッピングテーブルからエントリーを削除する。

ＤＳＴＭ ＴＥＰ３０は、タイマーが満了する前に、該当マッピング情報が使われた場合には、タイマーの満了前にＤＳＴＭサーバー４０へＤＳＴＭバインディング要請メッセージ（ＤＳＴＭ Ｂｉｎｄｉｎｇ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）を伝送し、マッピング情報を更新し、該当タイマーを再設定する。

このような４ｔｏ６ ＤＳＴＭメカニズムにおいてＤＳＴＭサーバー４０とＤＳＴＭホスト１０との間にＩＰｖ４アドレスを割り当てるためのＤＳＴＭメッセージ（ＤＳＴＭアドレス割当メッセージ、ＤＳＴＭアドレス割当確認応答メッセージ）と、ＤＳＴＭサーバー４０とＤＳＴＭ ＴＥＰ３０との間にバインディング情報更新のために必要なＤＳＴＭメッセージ（ＤＳＴＭバインディング更新メッセージ、ＤＳＴＭバインディング要請メッセージ）を定義している。

図３は、一般的な４ｔｏ６ ＤＳＴＭメカニズムにおいて定義されたＤＳＴＭメッセージのフォーマット（形式）を説明するための図である。

図３に示すように、ＤＳＴＭメッセージは、タイプ（Ｔｙｐｅ）フィールド、長さ（Ｌｅｎｇｔｈ）フィールド、コード（Ｃｏｄｅ）フィールド、ＤＳＴＭとして定義されたメッセージのフォーマットを一致させるためのフィールドである８ビット予備フィールド、識別子（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）フィールド、有効時間（Ｌｉｆｅｔｉｍｅ）フィールド、ＩＰｖ４アドレス（ａｄｄｒｅｓｓ）フィールド及びＩＰｖ６アドレスフィールドを含んでいる。

タイプフィールドは、ＤＳＴＭメッセージのタイプを示し、長さフィールドは、バイト単位のＤＳＴＭメッセージ長さを示す。

コードフィールドは、ＤＳＴＭメッセージの処理結果を表示し、識別子フィールドは、ＤＳＴＭ要請メッセージと応答メッセージとを一致させるための識別子を示す。

そして、有効時間フィールドは、ＩＰｖ４アドレスフィールドとＩＰｖ６アドレスフィールドの情報が有効に使用できる時間を示し、ＩＰｖ４アドレスフィールドは、ＤＳＴＭホスト１０のＩＰｖ４アドレス情報を示し、ＩＰｖ６アドレスフィールドは、ＤＳＴＭホスト１０のＩＰｖ６アドレス情報またはＤＳＴＭ ＴＥＰ３０のＩＰｖ６アドレス情報を示す。

一方、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メカニズムは、特定のアプリケーションフローが要求するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を提供するために提案されたＩｎｔＳｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ）モデルにおいて、終端間資源を予約するために設計されたメカニズムである。

このようなＲＳＶＰは、ユニキャスト又はマルチキャストデータフローに対して資源を予約するために、目的地ＩＰアドレス情報、トランスポート（Ｔｒａｎｓｐｏｒｔ）階層プロトコル及び目的地ポート情報を選択的に利用して各パケット流れに対するセッションを定義し、ソースアドレス情報及びソースポート情報を選択的に利用して各セッションのサブフロー（ｓｕｂ−ｆｌｏｗ）を定義する。

パケットを送信する送信終端は、セッションとサブフローとを初期化した後に、受信終端までの資源予約のための経路を設定するために、経路（Ｐａｔｈ）メッセージを伝送する。

Ｐａｔｈメッセージには、セッション情報を伝達する‘ＳＥＳＳＩＯＮオブジェクト’、インタフェースのＩＰアドレス情報を伝達する‘ＲＳＶＰ＿ＨＯＰオブジェクト’、サブフローを定義する‘Ｓｅｎｄｅｒ＿Ｔｅｍｐｌｅａｔｅ’、及びフローのトラフィック特性を定義する‘ＳｅｎｄｅｒＴ ｓｐｅｃ’などが含まれる。

このようなＰａｔｈメッセージは、‘Ｒｏｕｔｅ Ａｌｅｒｔ ＩＰ Ｏｐｔｉｏｎ’を含んで受信終端に向かって伝送されるので、経路上にＲＳＶＰを支援するノードは、Ｐａｔｈメッセージを処理する。

なお、経路上のノードに経路設定に対するエラーが発生すれば、Ｐａｔｈメッセージを除去し、エラーが発生したことを知らせる経路エラー（ＰａｔｈＥｒｒ）メッセージを以前のノード（前のノード）へ伝送する。一方、エラーが発生していなければ、フローに対する経路を設定した後、Ｐａｔｈメッセージを次のノードに伝送する。

Ｐａｔｈメッセージが受信終端まで到達すると、受信終端は、フローに対する経路を設定した後、所望のＱｏＳに対する資源を要請する予約（Ｒｅｓｖ）メッセージを、設定された経路情報に応じてホップ−バイ−ホップ方式で伝送する。

Ｒｅｓｖメッセージには、‘ＳＥＳＳＩＯＮオブジェクト’、‘ＲＳＶＰ＿ＨＯＰオブジェクト’、所望のＱｏＳを定義する‘Ｆｌｏｗ ｓｐｅｃ’、及びサブフローを区別（識別）するための‘Ｆｉｌｔｅｒ ｓｐｅｃ’などを含み、ホップ−バイ−ホップ方式で送信終端へ伝送され、経路上のＲＳＶＰを支援するノードは、Ｒｅｓｖメッセージを受信して、該当するフローに対する資源を予約する。

そして、ノードは、資源予約要請が承諾された場合に、Ｐａｔｈメッセージにより設定された経路に沿って次のノードへＲｅｓｖメッセージを伝送し、資源予約要請が拒絶される場合には、受信終端へ予約エラー（ＲｅｓｖＥｒｒ）メッセージを伝送することによって、資源予約要請に失敗したことを知らせる。

現在、‘ＲＦＣ２７４６’には、トンネルを含む経路上における終端間ＲＳＶＰを支援するメカニズムについて定義している。このようなメカニズムの基本方式は、ＲＳＶＰメッセージを繰り返して伝送することである。すなわち、終端間ＲＳＶＰメッセージの伝送だけでなく、トンネル区間のためのＲＳＶＰメッセージを別々に伝送することによって、トンネル区間内に経路設定と資源予約を行い、トンネル区間内に設定された資源予約とトンネル区間以外に設定された資源予約とをマッピングすることによって、トンネルを含む終端間に資源予約を行う。

終端間ＲＳＶＰメッセージは、既存のＲＳＶＰと同様の方式で伝送され、トンネル区間では、一般のデータパケットと同様に、ＩＰカプセル化して転送されることによって、トンネル区間を除いた終端間の資源予約を設定する。そして、トンネル内では、トンネルの開始ノードと最終のノードがトンネルセッションのトンネル（Ｔｕｎｎｅｌ）ＲＳＶＰメッセージを別々に伝送することによって、トンネル内に経路設定と資源予約を行う。

このように設定されたトンネルセッションと終端間セッションは、‘ＲＦＣ２７４６’で定義された‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’を用いてマッピングされることによって、トンネルを含む終端間のＲＳＶＰが透明で且つ一貫性をもって支援される。‘ＲＦＣ２７４６’には、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’以外にも、‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’が定義されている。

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

図４は、一般的なＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクトを説明するための図であり、図５は、ＮＯＤＥ＿ＣＨＡＲオブジェクトを説明するための図である。

図４に示すように、トンネルセッションと終端間セッションのマッピングを定義するための‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’は、終端間セッションの‘ＳＥＳＳＩＯＮオブジェクト’とトンネルセッションの‘ＦＩＬＴＥＲ＿ＳＰＥＣ’情報を含み、トンネルの最終のノードがトンネルＲＳＶＰメカニズムを支援する場合、トンネルの開始ノードは、Ｐａｔｈメッセージに‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’を含んでトンネルの最終のノードにトンネリングする。図４に示す長さ（Ｌｅｎｇｔｈ）フィールドは、バイト単位の‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’のサイズを含み、クラス（Ｃｌａｓｓ）フィールドは１９２として、Ｃ−ｔｙｐｅフィールドは受信とは関係無しにゼロとして送信される。

そして、図５に示すように、トンネル区間の最終のノードがトンネル区間の開始ノードにトンネルＲＳＶＰメカニズムを支援可能であるか否かに関する情報を伝達するための‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’は、トンネル区間の最終のノードがトンネルＲＳＶＰメカニズムを支援できる場合に、Ｒｅｓｖメッセージに‘Ｔ ｂｉｔ’が設定された‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’を追加した後、トンネル区間の開始ノードにトンネリングする。図５に示す長さ（Ｌｅｎｇｔｈ）フィールドは、バイト単位の‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’のサイズを含み、クラス（Ｃｌａｓｓ）フィールドは１２８としてセットされ、受信とは関係無しにＣ−ｔｙｐｅフィールドはゼロとして送信される。そして、Ｔビットは、ノードがＲＳＶＰトンネル可能なノードであることを表すフィールドである。

図６は、一般的なＲＳＶＰメカニズムによるメッセージフローを説明するための図である。

図６に示すように、送信終端（Ｓｏｕｒｃｅ）６０は、パケットを伝送するための資源を予約するためのＰａｔｈメッセージをホップ−バイ−ホップ方式で受信終端（ｄｅｓｔｉｎａｔｉｏｎ）６６へ伝送し、受信終端６６は、Ｐａｔｈメッセージを受信して、予約（Ｒｅｓｖ）メッセージをホップ−バイ−ホップ方式で送信終端６０へ伝送し、資源を予約する。そして、送信終端６０と受信終端６６との間に位置する各ノード６１乃至６５は、Ｒｅｓｖメッセージに応じて資源を予約してセッションを設定し、トンネルセッションの開始ノードは、Ｒｅｎｔｒｙ６２であり、最終のノードは、Ｒｅｘｉｔ６４である。

送信終端（Ｓｏｕｒｃｅ）６０が、パケットを伝送するための経路資源を予約するために、受信終端６６に向かってＰａｔｈメッセージを伝送すると（ステップＳ２０）、トンネル区間の開始ノードであるＲｅｎｔｒｙ６２は、トンネルの最終のノードであるＲｅｘｉｔ６４がトンネルＲＳＶＰメカニズムを支援できるか否かに関する情報を有していないため、Ｐａｔｈメッセージをカプセル化し、Ｒｅｘｉｔ６４へ伝送する（ステップＳ２１）。

このようなＰａｔｈメッセージは、‘Ｒｏｕｔｅｒ Ａｌｅｒｔ ＩＰオプション’を含んでいるので、送信終端６０と受信終端６６間の経路上のＲＳＶＰを支援する各ノード６２乃至６５で処理される。

Ｒｅｘｉｔ６４は、カプセル化したＰａｔｈメッセージを受信すると、脱カプセル化し、受信終端６６へ伝送する（ステップＳ２２）。

受信終端６６が、Ｐａｔｈメッセージを受信した場合、終端間経路上に資源予約を要請するための予約（Ｒｅｓｖ）メッセージを送信終端６０に向かってホップ−バイ−ホップ方式で伝送する（ステップＳ２３）。

Ｒｅｘｉｔ６４がＲｅｓｖメッセージを受信すると、当該Ｒｅｘｉｔ６４がトンネルＲＳＶＰメカニズムを支援できる場合には、‘Ｔ ｂｉｔ’を設定した‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’をＲｅｓｖメッセージに追加した後、カプセル化し、Ｒｅｎｔｒｙ６２にトンネリングする（ステップＳ２４）。

Ｒｅｎｔｒｙ６２は、受信したＲｅｓｖメッセージを脱カプセル化した後、‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’を除去し、送信終端６０へ伝送する（ステップＳ２５）。

そして、Ｒｅｎｔｒｙ６２は、終端間セッションに該当するトンネルセッションを初期化し、終端間セッションとトンネルセッションのマッピング情報を伝達する‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’をＰａｔｈメッセージに含めてＲｅｘｉｔ６４にトンネリングする（ステップＳ２６）。

また、Ｒｅｎｔｒｙ６２は、トンネルセッションの経路を設定するためのトンネルＰａｔｈメッセージをＲｅｘｉｔ６４へ転送する（ステップＳ２７）。

Ｒｅｘｉｔ６４は、終端間セッションに該当するトンネルセッションの情報を含む‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’が含まれたＰａｔｈメッセージを受信すると、脱カプセル化し、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’を除去した後に、受信終端６６へ伝送する（ステップＳ２８）。

そして、Ｒｅｘｉｔ６４は、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’に含まれているマッピング情報を用いて終端間セッションに該当するトンネルセッションを初期化し、トンネルＰａｔｈメッセージを受信すると、トンネルセッションに対する経路を設定した後、トンネル区間内に資源予約を要請するトンネルＲｅｓｖメッセージをＲｅｎｔｒｙ６２に向かって伝送する（ステップＳ２９）。

しかし、現在‘ＲＦＣ２７４６’に定義されているトンネル上のＲＳＶＰ支援メカニズムは、トンネル区間のｅｎｄ−ｐｏｉｎｔ、すなわち、トンネル区間の開始ノードと最終のノードが終端間ホストに代わってトンネル区間で資源を予約できるトンネルＲＳＶＰメッセージを伝送し、終端間セッションとトンネルセッションをマッピングすることによって、トンネルを含む経路で終端間ＲＳＶＰを支援できるようにしている。

したがって、ＲＳＶＰメカニズムでは、トンネルセッションが終端間セッションと共に設定されず、最初のＲｅｓｖメッセージが転送され、トンネルの開始ノードに伝送された後に、トンネルセッションに対する設定が行われる。

本発明は、前述のような問題点を解決するためになされたもので、その目的は、４ｔｏ６ ＤＳＴＭ環境でＲＳＶＰメカニズムによって資源を予約する場合に、トンネルセッションの開始ノードが最終のノードのＲＳＶＰ支援可能可否をあらかじめ把握できるようにし、トンネルセッションと終端間セッションが同時に設定されることができるようにする、ＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおける経路資源の予約方法及びそのシステムを提供することにある。

前記目的を達成するために、本発明の一態様に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムは、ＤＳＴＭ（Ｄｕａｌ Ｓｔａｃｋ ＴｒａｎｓｉｔｉｏｎＭｅｃｈａｎｉｓｍ）によってＩＰｖ６網に接続されたホストにＩＰｖ４アドレス情報を割り当てつつ、前記各ホストのＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の支援情報を把握し、ＲＳＶＰによってパケットを交換するノードから要請がある場合に、前記各ホストのＲＳＶＰの支援可否を通知するＤＳＴＭサーバーと、送信ホストから前記ＲＳＶＰによる予約メッセージを受信した場合に、前記ＤＳＴＭサーバーから受信ホストがＲＳＶＰを支援するか否かを確認し、前記受信ホストがＲＳＶＰを支援する場合、トンネル予約メッセージとカプセル化された終端間予約メッセージとをDSTMホストに伝送し、端末間セッションとトンネルセッションのマッピング情報を格納するノードと、を備える。

本発明の他の態様に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムは、ＲＳＶＰメカニズムによって経路資源を予約するＩＰｖ４／ＩＰｖ６統合ネットワークシステムであって、ＩＰｖ６網に接続しつつ、ＩＰｖ４網へパケットを伝送すべき場合、前記ＲＳＶＰによる経路メッセージを、ＩＰｖ４網に接続する第２のホストへ伝送する第１のホストと、前記第１のホストから前記経路メッセージを受信した場合に、ＲＳＶＰによる予約メッセージを前記ＩＰｖ６網と前記ＩＰｖ４網との境界に位置するノードへ伝送する第２のホストと、ＤＳＴＭ（Ｄｕａｌ Ｓｔａｃｋ ＴｒａｎｓｉｔｉｏｎＭｅｃｈａｎｉｓｍ）によってＩＰｖ６網に接続された前記第１のホストにＩＰｖ４アドレス情報を割り当てつつ、前記第１のホストのＲＳＶＰ支援情報を把握し、前記ノードの要請に応じて前記第１のホストの前記ＲＳＶＰ支援情報を提供するＤＳＴＭサーバーと、前記第２のホストから前記予約メッセージを受信した場合に、前記ＤＳＴＭサーバーから前記第１のホストのＲＳＶＰ支援情報を把握し、前記１のホストの前記ＲＳＶＰ支援情報に応じて、トンネル予約メッセージとカプセル化された終端間予約メッセージとをDSTMホストに伝送し、端末間セッションとトンネルセッションのマッピング情報を格納するノードと、を備える。

また、本発明のさらに他の態様に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムは、ＤＳＴＭによってＩＰｖ６網に接続された第１のホストにＩＰｖ４アドレス情報を割り当てる割当メッセージを伝送した後に、受信される割当応答メッセージからＲＳＶＰ支援情報を取得し、ノードからＩＰｖ４アドレス情報のマッピング情報を要請する要請メッセージを受信した場合に、マッピング情報及びＲＳＶＰ支援情報が含まれる更新メッセージを提供するＤＳＴＭサーバーと、ＤＳＴＭサーバーから割当メッセージを受信した場合に、ＲＳＶＰ支援情報が含まれる割当応答メッセージをＤＳＴＭサーバーへ伝送し、割当メッセージを通じて割り当てられたＩＰｖ４アドレス情報を用いてＩＰｖ４網に属している第２のホストへパケットを伝送する第１のホストと、ＤＳＴＭサーバーから第１のホストに割り当てられるＩＰｖ４アドレス情報を用いてパケットを前記第１のホストへ伝送する第２のホストと、前記第２のホストから受信される前記パケットの目的地アドレス情報のマッピング情報を要請する要請メッセージを前記ＤＳＴＭサーバーへ伝送し、前記ＤＳＴＭサーバーから受信される更新メッセージに含まれた前記第１のホストのＲＳＶＰ支援情報に応じて、端末間セッションとトンネルセッションのマッピング情報を格納することによりセッションを設定した後に、前記マッピング情報に応じて前記パケットを第１のホストへ伝送するノードと、を備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムは、前記第２のホストから受信される第１のホストのＩＰｖ４アドレス情報を問い合わせする第１のタイプの問い合わせメッセージを前記ＤＳＴＭサーバーへ伝送し、前記第１のホストのＩＰｖ４アドレス情報を第２のホストへ提供する第１のＤＮＳサーバーと、ＤＳＴＭサーバーから受信される第２のタイプの問い合わせメッセージに応じて第１のホストのＩＰｖ４アドレス情報及びＩＰｖ６アドレス情報が含まれる応答メッセージを提供する第２のＤＮＳサーバーとをさらに備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおいて、ＤＳＴＭサーバーは、第１のＤＮＳサーバーから受信される第１のタイプの問い合わせメッセージを第２のタイプの問い合わせメッセージに変換し、第２のＤＮＳサーバーへ伝送し、第２のＤＮＳサーバーから受信される第２のタイプの応答メッセージを第１のタイプの応答メッセージに変換し、第１のＤＮＳサーバーへ転送するＤＮＳゲートウエーと、第１のホストにＩＰｖ４アドレス情報を割り当てた後に、第２のＤＮＳサーバーに登録し、ＩＰｖ４アドレス情報が含まれる割当メッセージを第１のホストへ伝送するＤＳＴＭマネジャー部と、第１のホストのマッピング情報を格納するマッピングテーブルと、を備える。

また、本発明のさらに他の態様に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法は、各々異なる網に属しているホストと、ＤＳＴＭサーバーと、ノードとを備えたＩＰｖ４／ＩＰｖ６統合ネットワークでＲＳＶＰメカニズムによって経路資源を予約する方法であって、ＤＳＴＭサーバーが第１のホストのＲＳＶＰ支援情報を把握し、ノードから要請メッセージを受信した場合に、ＲＳＶＰ支援情報が含まれる更新メッセージをノードへ転送する段階と、第１のホストがＲＳＶＰによる経路メッセージを第２のホストへ転送する段階と、第２のホストが、経路メッセージを受信した場合に、ＲＳＶＰによる予約メッセージをノードへ伝送する段階と、ノードが更新メッセージを通じて把握される第１のホストのＲＳＶＰ支援情報に応じて、第２のホストとの終端間セッションを設定するための予約メッセージと、第１のホストとのトンネルセッションを設定するためのトンネル予約メッセージとを同時に第１のホストへ伝送し、端末間セッションとトンネルセッションのマッピング情報を格納する段階と、を備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法は、ノードが、第１のホストからカプセル化した経路メッセージを受信した場合に、当該カプセル化された経路メッセージを脱カプセル化し、第２のホストへ伝送する段階と、第２のホストから予約メッセージを受信した場合に、予約メッセージをカプセル化し、第１のホストとのトンネルセッションを設定するためのトンネル予約メッセージと、カプセル化した予約メッセージとを同時に第１のホストへ伝送する段階と、第２のホストと設定される終端間セッション情報と、終端間セッション情報にマッピングされる第１のホストとのトンネルセッション情報とを管理する段階と、をさらに備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法は、ＤＳＴＭサーバーが、第１のホストに割り当てられるＩＰｖ４アドレス情報と、第１のホストのマッピング情報とを管理する段階と、第１のホストが、割当メッセージを通じて割り当てられた各アドレス情報を用いてパケットを伝送する段階と、第２のホストが、第１のホストに割り当てられるＩＰｖ４アドレス情報を用いてパケットを伝送する段階と、ノードが、第２のホストから受信されるパケットの目的地アドレス情報にマッピングされるマッピング情報を要請する要請メッセージをＤＳＴＭサーバーへ伝送する段階と、ＤＳＴＭサーバーが、要請メッセージを受信した場合に、目的地アドレス情報にマッピングされるマッピング情報と第１のホストのＲＳＶＰ支援情報とが含まれる更新メッセージを第２のホストへ伝送する段階、とをさらに備える。

また、本発明のさらに他の態様に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法は、各々異なる網に属しているホストと、ＤＳＴＭサーバーと、ノードとを備えたＩＰｖ４／ＩＰｖ６統合ネットワークシステムでＲＳＶＰメカニズムによって経路資源を予約する方法であって、ＤＳＴＭサーバーが、ＩＰｖ６網に接続された第１のホストにＩＰｖ４アドレス情報を割り当て、第１のホストのＲＳＶＰ支援情報を把握する段階と、ノードが、第２のホストからパケットを受信した場合に、パケットの目的地アドレス情報に対応するマッピング情報を要請する要請メッセージをＤＳＴＭサーバーへ伝送する段階と、ＤＳＴＭサーバーが、要請メッセージに応ずるマッピング情報と第１のホストのＲＳＶＰ支援情報とが含まれる更新メッセージをノードへ伝送する段階と、ノードが、更新メッセージから把握される第１のホストのＲＳＶＰ支援情報に応じて、トンネル予約メッセージとカプセル化された終端間予約メッセージとをDSTMホストに伝送し、端末間セッションとトンネルセッションのマッピング情報を格納する段階と、を備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法において、第１のホストのＲＳＶＰ支援情報を把握する段階は、ＤＳＴＭサーバーが、第１のホストにＩＰｖ４アドレス情報を割り当てる段階と、割り当てられたＩＰｖ４アドレス情報と、ノードのＩＰｖ６アドレス情報とが含まれる割当メッセージを第１のホストへ伝送する段階と、第１のホストが、割当メッセージから各アドレス情報を把握し、ＲＳＶＰ支援情報が含まれる応答メッセージをＤＳＴＭサーバーへ伝送する段階と、ＤＳＴＭサーバーが、応答メッセージに含まれた第１のホストのＲＳＶＰ支援情報を把握する段階と、を備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法は、ＤＳＴＭサーバーが、第１のホストのマッピング情報をテーブルで管理する段階と、ＤＳＴＭサーバーがノードから要請メッセージを受信した場合に、テーブルで管理される第１のホストのマッピング情報を検索し、マッピング情報及びＲＳＶＰ支援情報が含まれる更新メッセージをノードへ伝送する段階と、ノードが、第２のホストからＲＳＶＰによる予約メッセージを受信した場合に、第１のホストのＲＳＶＰ支援情報に応じてトンネルセッションを設定するためのトンネル予約メッセージと、終端セッションを設定するための終端間予約メッセージとを同時に第１のホストへ伝送する段階と、をさらに備える。

本発明によれば、４ｔｏ６ ＤＳＴＭ環境でＲＳＶＰメカニズムによって資源を予約する場合に、ＤＳＴＭによってＩＰｖ６ホストにＩＰｖ４アドレス情報を割り当てながら、トンネルセッションの開始ノードに最終のノードのＲＳＶＰ支援可能可否を予め知らせるため、トンネルセッションと終端間セッションを同時に設定することが可能になる。

以下、添付の図面を参照して、本発明に係るＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおける経路資源の予約方法及びそのシステムを詳細に説明する。

図７は、本発明の好適な実施形態における４ｔｏ６ ＤＳＴＭメカニズムを説明するためのブロック図である。

図７に示すように、本実施形態の４ｔｏ６ ＤＳＴＭメカニズムは、ＩＰｖ６網に属しているＤＳＴＭサーバー４００、デュアルスタックであるＤＳＴＭホスト（第１ホスト）１００及びＩＰｖ６ ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバー５２０と、ＩＰｖ４網に属しているＩＰｖ４ホスト（第２ホスト）２００及びＩＰｖ４ ＤＮＳサーバ５１０と、ＩＰｖ４網とＩＰｖ６網との境界に位置するＤＳＴＭ ＴＥＰ３００で構成される。

ＤＳＴＭサーバー４００は、ＤＳＴＭホスト１００からアドレス割当要請メッセージを受信すると、ＤＳＴＭホスト１００に一時的ＩＰｖ４アドレス情報（臨時ＩＰｖ４アドレス情報）を割り当て、割り当てられたＩＰｖ４アドレス情報とＤＳＴＭホスト１００のＩＰｖ６アドレス情報に関するマッピング情報をマッピングテーブル４３０で管理し、トンネルセッションの最終のノード、すなわちＤＳＴＭ ＴＥＰ３００のＲＳＶＰ支援情報、割り当てられたＩＰｖ４アドレス情報及びＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報が含まれるアドレス割当応答メッセージをＤＳＴＭホスト１００へ伝送する。

また、ＤＳＴＭサーバー４００は、ＤＳＴＭ ＴＥＰ３００から受信されるＩＰｖ４パケットの目的地アドレス情報にマッピングされたＩＰｖ６アドレス情報を要請するＤＳＴＭバインディング要請メッセージを受信すると、マッピングテーブル４３０からＩＰｖ４アドレス情報にマッピングされるマッピング情報を検索し、ＤＳＴＭホスト１００のＲＳＶＰ支援情報及びマッピング情報が含まれるＤＳＴＭバインディング更新メッセージをＤＳＴＭ ＴＥＰ３００へ伝送する。

ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ６網とＩＰｖ４網との境界に位置し、且つＩＰｖ４パケットをＤＳＴＭホスト１００にトンネリングする。

そして、トンネルＲＳＶＰメカニズムによってトンネルセッションを設定する場合には、ＤＳＴＭ ＴＥＰ３００がトンネルセッションの開始ノードに該当し、ＤＳＴＭホスト１００がトンネルセッションの最終のノードに該当する。

ＩＰｖ４ホスト２００は、ＩＰｖ６網に属しているＤＳＴＭホスト１００に接続するために、ＩＰｖ４ ＤＮＳサーバー５１０へＤＳＴＭホスト１００のＩＰｖ４アドレス情報を問い合わせするＡタイプ（Ａ：ＩＰｖ４アドレスに対するＤＮＳレコードタイプ）のＤＮＳ問い合わせメッセージを伝送する（ステップＳ１００）。

ＩＰｖ４ ＤＮＳサーバー５１０は、ＤＮＳ問い合わせメッセージを受信すると、ＤＳＴＭホスト１００のアドレス情報を管理しているＩＰｖ６網内のＩＰｖ６ ＤＮＳサーバー５２０へＤＮＳ問い合わせメッセージを伝送する（ステップＳ１１０）。

ＩＰｖ４ ＤＮＳサーバー５１０が伝送したＤＮＳ問い合わせメッセージは、ＩＰｖ６網とＩＰｖ４網との境界に存在するＤＳＴＭ ＴＥＰ３００へ伝送され、ＤＳＴＭ ＴＥＰ３００は、受信したＤＮＳ問い合わせメッセージの目的地アドレス情報がＤＳＴＭサーバー４００のアドレス情報であることから、ＤＮＳ問い合わせメッセージをＤＳＴＭサーバー４００へ伝送する。

ＤＳＴＭサーバー４００のＤＮＳ−ＡＬＧ４１０は、受信したＡタイプのＤＮＳ問い合わせメッセージをＩＰｖ４アドレス情報とＩＰｖ６アドレス情報を共に要請するＡＡＡＡタイプ（ＡＡＡＡ：ＩＰｖ６アドレスに対するＤＮＳレコードタイプ）のＤＮＳ問い合わせメッセージに変換し、ＩＰｖ６ ＤＮＳサーバー５２０へ伝送する（ステップＳ１２０）。

ＩＰｖ６ ＤＮＳサーバー５２０は、ＤＮＳ問い合わせメッセージを受信すると、ＤＳＴＭホスト１００のＩＰｖ４アドレス情報及びＩＰｖ６アドレス情報が含まれるＤＮＳ応答メッセージをＤＳＴＭサーバー４００へ伝送する（ステップＳ１３０）。

ＤＳＴＭサーバー４００は、ＩＰｖ６ ＤＮＳサーバー５２０からＤＳＴＭホスト１００のＩＰｖ４アドレス情報とＩＰｖ６アドレス情報を共に含むＡＡＡＡタイプのＤＮＳ応答メッセージを受信すると、ＩＰｖ４アドレス情報だけを含むＡタイプのＤＮＳ応答メッセージに変換する。

そして、ＤＳＴＭサーバー４００は、ＡタイプのＤＮＳ応答メッセージをＩＰｖ４ ＤＮＳサーバー５１０へ伝送する（ステップＳ２００）。

ＤＳＴＭサーバー４００は、例えば、受信したＤＮＳ応答メッセージにＩＰｖ６アドレス情報のみが含まれている場合、すなわち、ＩＰｖ６ ＤＮＳサーバー５２０からＤＳＴＭホスト１００のＩＰｖ６アドレス情報だけを含むＡＡＡＡタイプのＤＮＳ応答メッセージを受信した場合には、当該ＤＳＴＭサーバー４００は、ＩＰｖ４アドレスプール（ＩＰｖ４ ａｄｄｒｅｓｓ ｐｏｏｌ）から臨時ＩＰｖ４アドレス情報のうち１つをＤＳＴＭホスト１００に割り当てる。

ＤＮＳ−ＡＬＧ４１０は、受信したＤＮＳ応答メッセージにＩＰｖ６アドレス情報だけが含まれているか否かを判別し、ＤＮＳ応答メッセージにＩＰｖ６アドレス情報だけが含まれている場合には、ＤＳＴＭホスト１００にＩＰｖ４アドレス情報を割り当てるようにＤＳＴＭマネジャー４２０に要請する（ステップＳ１４０）。

ＤＳＴＭマネジャー４２０は、臨時のＩＰｖ４アドレス情報をＤＳＴＭホスト１００に割り当て、マッピングテーブル４３０に、ＤＳＴＭホスト１００のＩＰｖ６アドレス情報、臨時に割り当てたＩＰｖ４アドレス情報、及び臨時に割り当てられたＩＰｖ４アドレス情報が有効に使用できる時間を示す有効時間（ｌｉｆｅｔｉｍｅ）情報などのようなマッピング情報を格納し、有効時間情報に関するタイマーを設定する。

そして、ＤＳＴＭマネジャー４２０は、臨時に割り当てたＩＰｖ４アドレス情報をＩＰｖ６ ＤＮＳサーバー５２０に動的（ｄｙｎａｍｉｃ）に登録する（ステップＳ１６０）。

ＤＳＴＭマネジャー４２０は、臨時に割り当てられたＩＰｖ４アドレス情報、トンネリングに使用するＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報及び当該臨時に割り当てられたＩＰｖ４アドレス情報の有効時間情報が含まれるＤＳＴＭアドレス割当メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ａｌｌｏｃａｔｉｏｎ Ｍｅｓｓａｇｅ）をＤＳＴＭホスト１００へ伝送する（ステップＳ１７０）。

ＤＳＴＭホスト１００は、ＤＳＴＭマネジャー４２０からＤＳＴＭアドレス割当メッセージを受信すると、臨時に割り当てられたＩＰｖ４アドレス情報とＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報とをキャッシュ（ｃａｃｈｅ）に格納し、有効時間情報に関するタイマーを設定する。

そして、ＤＳＴＭホスト１００は、ＩＰｖ４アドレス情報及びＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報をキャッシュに格納し、ＲＳＶＰ支援情報が含まれるＤＳＴＭアドレス割当確認応答メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ａｌｌｏｃａｔｉｏｎ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｍｅｓｓａｇｅ）をＤＳＴＭサーバー４００へ伝送し、アドレス割当処理が成功したことを通知すると同時に、ＤＳＴＭホスト１００自身のＲＳＶＰ支援可否を通知する（ステップＳ１８０）。

すなわち、ＤＳＴＭホスト１００は、ＲＳＶＰメカニズムを支援する場合、ＤＳＴＭアドレス割当確認応答メッセージにＲＳＶＰ支援可能情報を含めてＤＳＴＭサーバー４００へ伝送する。

図８は、本実施形態のＤＳＴＭメッセージの形式（フォーマット）を説明するための図である。

図８に示すように、本実施形態のＤＳＴＭメッセージは、ＤＳＴＭメッセージのタイプを示すタイプ（Ｔｙｐｅ）フィールド、バイト単位のメッセージ長さを示す長さ（Ｌｅｎｇｔｈ）フィールド、ＤＳＴＭメッセージの処理結果を示すコード（Ｃｏｄｅ）フィールド、ＲＳＶＰ支援情報を示すＲＳＶＰフィールド、ＤＳＴＭ要請メッセージと応答メッセージとを一致（マッチング）させるための識別子（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）フィールド、有効時間（Ｌｉｆｅｔｉｍｅ）フィールド、ＩＰｖ４アドレス（ａｄｄｒｅｓｓ）フィールド及びＩＰｖ６アドレスフィールドを含む。

なお、ＲＳＶＰフィールドは、既存のＤＳＴＭメッセージの予備（Ｒｅｓｅｒｖｅｄ）フィールドのうち１バイトのフィールドを使用することが好ましい。

ＤＳＴＭマネジャー４２０は、ＤＳＴＭホスト１００からＤＳＴＭアドレス割当確認応答メッセージを受信すると、ＤＮＳ−ＡＬＧ４１０に、ＤＳＴＭホスト１００に割り当てられたＩＰｖ４アドレス情報を知らせ（ステップＳ１９０）、ＤＮＳ−ＡＬＧ４１０は、ＩＰｖ４アドレス情報を含むＡタイプのＤＮＳ応答メッセージをＩＰｖ４ ＤＮＳサーバー５１０へ伝送する（ステップＳ２００）。

ＩＰｖ４ ＤＮＳサーバー５１０は、受信したＤＮＳ応答メッセージをＩＰｖ４ホスト２００へ伝送し、ＩＰｖ６ホスト１００に割り当てられたＩＰｖ４アドレス情報を通知する（ステップＳ２１０）。

ＩＰｖ４ホスト２００は、受信したＤＮＳ応答メッセージから得られるＤＳＴＭホスト１００のＩＰｖ４アドレス情報を用いてＩＰｖ４パケットを伝送する（ステップＳ２２０）。

ＤＳＴＭ ＴＥＰ３００は、ＩＰｖ４パケットを受信すると、ＩＰｖ４パケットの目的地アドレス情報に該当するＩＰｖ６アドレス情報が含まれるマッピング情報を要請するＤＳＴＭバインディング要請メッセージ（ＤＳＴＭ Ｂｉｎｄｉｎｇ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）をＤＳＴＭサーバー４００へ伝送する（ステップＳ２３０）。

このとき、ＤＳＴＭ ＴＥＰ３００が受信したＩＰｖ４パケットは、トンネルＲＳＶＰメカニズムによってセッションを設定するためのＲＳＶＰメッセージのパケットに相当する。すなわち、ＩＰｖ４パケットは、ＤＳＴＭホスト１００とＩＰｖ４ホスト２００間のセッションを設定するためのＲＳＶＰ予約メッセージに相当する。

ＤＳＴＭサーバー４００は、ＤＳＴＭ ＴＥＰ３００からＤＳＴＭバインディング要請メッセージを受信すると、マッピングテーブル４３０からＩＰパケットの目的地アドレス情報であるＩＰｖ４アドレス情報に関するマッピング情報を検索する。

そして、ＤＳＴＭサーバー４００は、マッピングテーブル４３０から検索されたマッピング情報、すなわちＩＰｖ４アドレス情報にマッピングされるＩＰｖ６アドレス情報及びＩＰｖ４アドレス情報の有効時間情報などが含まれるマッピング情報と、ＤＳＴＭホスト１００のＲＳＶＰ支援情報が含まれるＤＳＴＭバインディング更新メッセージ（ＤＳＴＭ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ Ｍｅｓｓａｇｅ）をＤＳＴＭ ＴＥＰ３００へ伝送する（ステップＳ２４０）。

この際、ＤＳＴＭサーバー４００は、図８に示したようなＤＳＴＭメッセージ形式に基づいて、ＤＳＴＭバインディング更新メッセージのＲＳＶＰフィールドにＤＳＴＭホスト１００のＲＳＶＰ支援情報を含めてＤＳＴＭ ＴＥＰ３００へ伝送する。

すなわち、ＤＳＴＭサーバー４００は、ＤＳＴＭホスト１００から受信されるＤＳＴＭアドレス割当確認応答メッセージから得られたＲＳＶＰ支援情報をＤＳＴＭバインディング更新メッセージに含めてＤＳＴＭ ＴＥＰ３００へ伝送するので、トンネル区間の開始ノードであるＤＳＴＭ ＴＥＰ３００がトンネルの最終のノードであるＤＳＴＭホストのＲＳＶＰ支援情報を確認することが可能となる。

ＤＳＴＭ ＴＥＰ３００は、ＤＳＴＭサーバー４００からＤＳＴＭバインディング更新メッセージを受信すると、ＤＳＴＭ ＴＥＰ３００自身のマッピングテーブルにＤＳＴＭホスト１００のＩＰｖ４アドレス情報とＩＰｖ６アドレス情報及びＩＰｖ４アドレス情報の有効時間情報を格納し、有効時間情報に関するタイマーを設定する。

ＤＳＴＭ ＴＥＰ３００は、格納したマッピング情報を用いてＩＰｖ４ホスト２００から受信されるＩＰｖ４パケットをＤＳＴＭホスト１００にＩＰｖ４−ｏｖｅｒ−ＩＰｖ６トンネリングする。

ＤＳＴＭホスト１００は、ＤＳＴＭ ＴＥＰ３００からトンネリングされたパケットが受信した場合には、脱カプセル化し、ＩＰｖ４ホスト２００が伝送したオリジナルのＩＰｖ４パケットを受信する。

ＤＳＴＭホスト１００は、ＤＳＴＭサーバー４００から受信されるＤＳＴＭアドレス割当メッセージから得られた割り当てられたＩＰｖ４アドレス情報とＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報を用いてＤＳＴＭ ＴＥＰ３００にＩＰｖ４パケットをＩＰｖ４−ｏｖｅｒ−ＩＰｖ６トンネリングし（ステップＳ２６０）、ＤＳＴＭ ＴＥＰ３００は、ＤＳＴＭホスト１００から受信されるＩＰｖ４パケットを脱カプセル化し、ＩＰｖ４網へ伝送する（ステップＳ２７０）。

また、ＤＳＴＭマネジャー４２０は、マッピングテーブル４３０のエントリー毎に設定しておいたタイマーが満了した場合（すなわち、ＤＳＴＭホスト１００に割り当てたＩＰｖ４アドレスに対する有効時間が経過した場合）、マッピングテーブル４３０から該当するエントリーを削除する。そして、ＤＳＴＭマネジャー４２０は、ＩＰｖ６ ＤＮＳサーバー５２０からＩＰｖ４アドレス割当処理の際に登録したＤＳＴＭホスト１００のＩＰｖ４アドレス情報の削除要請を行い、ＤＳＴＭホスト１００から割り当てたＩＰｖ４アドレスを回収する。

なお、ＤＳＴＭホスト１００は、割り当てられたＩＰｖ４アドレス情報を、有効時間満了後にも継続して使用する場合には、有効時間が満了する前に、ＤＳＴＭサーバー４００にＤＳＴＭアドレス延長要請メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ｅｘｔｅｎｓｉｏｎ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）を伝送し、割り当てられたＩＰｖ４アドレス情報の有効時間情報を延長する。

ＤＳＴＭサーバー４００は、ＤＳＴＭホスト１００からＤＳＴＭアドレス延長メッセージを受信した場合には、マッピングテーブル４３０から該当するエントリーを探し出し、有効時間情報を延長し、該当するタイマーを再設定する。

そして、ＤＳＴＭサーバー４００は、ＤＳＴＭホスト１００にＤＳＴＭアドレス延長応答メッセージ（ＤＳＴＭ Ａｄｄｒｅｓｓ Ｅｘｔｅｎｓｉｏｎ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｍｅｓｓａｇｅ）を伝送する。ＤＳＴＭ ＴＥＰ３００は、ＤＳＴＭ ＴＥＰ３００自身のマッピングテーブルのエントリー毎に設定しておいたタイマーが満了するまでに当該マッピング情報が使用されなければ、マッピングテーブルから該当するエントリーを削除する。

なお、ＤＳＴＭ ＴＥＰ３００は、タイマーが満了する前に、該当するマッピング情報が使用された場合には、タイマーの満了前にＤＳＴＭサーバー４００にＤＳＴＭバインディング要請メッセージ（ＤＳＴＭ Ｂｉｎｄｉｎｇ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）を伝送し、マッピング情報を更新し、該当タイマーを再設定する。

図９は、本実施形態のＲＳＶＰメカニズムを説明するためのフローチャートである。

図９に示すように、送信終端（Ｓｏｕｒｃｅ）であるＤＳＴＭホスト１００がトンネルＲＳＶＰメカニズムを支援し、トンネルセッションの開始ノードがＤＳＴＭ ＴＥＰ３００であり、トンネルセッションの最終のノードがＤＳＴＭホスト１００である場合について説明する。

ＤＳＴＭホスト１００が、ＤＳＴＭサーバー４００からＤＳＴＭメカニズムによって割り当てられるＩＰｖ４アドレス情報と、ＤＳＴＭ ＴＥＰ３００のＩＰｖ６アドレス情報とが含まれるＤＳＴＭアドレス割当メッセージを受信した場合には、ＲＳＶＰ支援情報が含まれるＤＳＴＭアドレス割当確認応答メッセージをＤＳＲＭサーバー４００へ伝送し、ＲＳＶＰ支援可否をＤＳＴＭサーバー４００に通知する。

そして、ＤＳＴＭサーバー４００は、ＤＳＴＭ ＴＥＰ３００から受信されるＩＰｖ４パケットの目的地アドレス情報にマッピングされるマッピング情報を要請するＤＳＴＭバインディング要請メッセージを受信すると、目的地アドレス情報にマッピングされるマッピング情報と、ＤＳＴＭホスト１００のＲＳＶＰ支援情報が含まれるＤＳＴＭバインディング更新メッセージをＤＳＴＭ ＴＥＰ３００へ伝送するため、ＤＳＴＭ ＴＥＰ３００がＤＳＴＭホスト１００のＲＳＶＰ支援可否を確認することができる。

そして、ＤＳＴＭホスト１００は、ＲＳＶＰメカニズムによってパケットを伝送するための終端セッションを設定するための終端間Ｐａｔｈメッセージ及びトンネルセッションを設定するためのトンネルＰａｔｈメッセージをカプセル化し、ＤＳＴＭ ＴＥＰ３００へ伝送する（ステップＳ３００）。

ＤＳＴＭ ＴＥＰ３００は、終端間セッション情報と、トンネルセッション情報を格納し、終端間Ｐａｔｈメッセージを脱カプセル化し、受信終端であるＩＰｖ４ホスト（クライアント又は第２ホスト）２００へ伝送する（ステップＳ３１０）。

ＩＰｖ４ホスト２００は、終端間Ｐａｔｈメッセージを受信すると、終端間経路上の資源予約を要請する終端間予約（Ｒｅｓｖ）メッセージをＤＳＴＭ ＴＥＰ３００へ伝送転送する（ステップＳ３２０）。

ＤＳＴＭ ＴＥＰ３００は、トンネルの最終のノードであるＤＳＴＭホスト１００のＲＳＶＰ支援情報を、ＤＳＴＭサーバー４００から受信されるＤＳＴＭバインディング更新メッセージから確認したので、終端間Ｒｅｓｖメッセージをカプセル化し、ＤＳＴＭホスト１００へ伝送しながらトンネルＲｅｓｖメッセージを伝送する（ステップＳ３３０）。

そして、ＤＳＴＭ ＴＥＰ３００は、終端間セッションとトンネルセッションのマッピング情報を格納する。

このように本実施形態のＤＳＴＭ ＴＥＰ３００は、トンネルセッションの最終のノードであるＤＳＴＭホスト１００のＲＳＶＰ支援情報を確認したので、ＤＳＴＭホスト１００がＲＳＶＰを支援していれば、既存のトンネルセッションの最終のノードが、トンネルセッションの経路を設定するためのトンネルＰａｔｈメッセージにＲＳＶＰ支援情報を含めて開始ノードへ伝送し、当該開始ノードが、最終のノードのＲＳＶＰ支援情報を確認した後、トンネルＲｅｓｖメッセージを伝送する過程を要せずに、トンネルセッションと終端間セッションを同時に設定することが可能となる。

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

一般的なＤＳＴＭメカニズムを説明するためのブロック図である。 一般的な４ｔｏ６ ＤＳＴＭメカニズムを説明するためのブロック図である。 一般的な４ｔｏ６ ＤＳＴＭメカニズムで定義されたＤＳＴＭメッセージのフォーマットを説明するための図である。 一般的な「ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト」を説明するための図である。 「ＮＯＤＥ＿ＣＨＡＲオブジェクト」を説明するための図である。 一般的なＲＳＶＰメカニズムによるメッセージフローを説明するための図である。 本発明の好適な実施形態の４ｔｏ６ ＤＳＴＭメカニズムを説明するためのブロック図。 本発明の好適な実施形態のＤＳＴＭメッセージ及びフォーマットを説明するための図である。 本発明の好適な実施形態のＲＳＶＰメカニズムを説明するためのフローチャートである。

符号の説明

１０、１００ ＤＳＴＭ（Ｄｕａｌ Ｓｔａｃｋ Ｔｒａｎｓｉｔｉｏｎ Ｍｅｃｈａｎｉｓｍ）ホスト
２０、２００ ＩＰｖ４ホスト
３０、３００ ＤＳＴＭノード（ＴＥＰ）
４０、４００ ＤＳＴＭサーバー
４１、４１０ ＤＮＳ−ＡＬＧ（Ａｐｐｌｉｃａｔｉｏｎ Ｌｅｖｅｌ Ｇａｔｅｗａｙ）
４２、４２０ ＤＳＴＭマネジャー（Ｍａｎａｇｅｒ）
４３、４３０ マッピングテーブル（Ｍａｐｐｉｎｇ Ｔａｂｌｅ）

Claims (20)

1. ＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおいて、
   ＤＳＴＭ（Ｄｕａｌ Ｓｔａｃｋ ＴｒａｎｓｉｔｉｏｎＭｅｃｈａｎｉｓｍ）によってＩＰｖ６網に接続されたホストにＩＰｖ４アドレス情報を割り当てつつ、前記各ホストのＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の支援情報を把握し、ＲＳＶＰによってパケットを交換するノードから要請がある場合に、前記各ホストのＲＳＶＰの支援可否を通知するＤＳＴＭサーバーと、
   送信ホストから前記ＲＳＶＰによる予約メッセージを受信した場合に、前記ＤＳＴＭサーバーから受信ホストがＲＳＶＰを支援するか否かを確認し、前記受信ホストがＲＳＶＰを支援する場合、トンネル予約メッセージとカプセル化された終端間予約メッセージとをDSTMホストに伝送し、端末間セッションとトンネルセッションのマッピング情報を格納するノードと、を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
2. ＲＳＶＰメカニズムによって経路資源を予約するＩＰｖ４／ＩＰｖ６統合ネットワークシステムであって、
   ＩＰｖ６網に接続しつつ、ＩＰｖ４網へパケットを伝送すべき場合、前記ＲＳＶＰによる経路メッセージを、ＩＰｖ４網に接続する第２のホストへ伝送する第１のホストと、
   前記第１のホストから前記経路メッセージを受信した場合に、ＲＳＶＰによる予約メッセージを前記ＩＰｖ６網と前記ＩＰｖ４網との境界に位置するノードへ伝送する第２のホストと、
   ＤＳＴＭ（Ｄｕａｌ Ｓｔａｃｋ ＴｒａｎｓｉｔｉｏｎＭｅｃｈａｎｉｓｍ）によってＩＰｖ６網に接続された前記第１のホストにＩＰｖ４アドレス情報を割り当てつつ、前記第１のホストのＲＳＶＰ支援情報を把握し、前記ノードの要請に応じて前記第１のホストの前記ＲＳＶＰ支援情報を提供するＤＳＴＭサーバーと、
   前記第２のホストから前記予約メッセージを受信した場合に、前記ＤＳＴＭサーバーから前記第１のホストのＲＳＶＰ支援情報を把握し、前記１のホストの前記ＲＳＶＰ支援情報に応じて、トンネル予約メッセージとカプセル化された終端間予約メッセージとをDSTMホストに伝送し、端末間セッションとトンネルセッションのマッピング情報を格納するノードと、を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
3. 前記ノードは、前記第２のホストから受信される前記予約メッセージを受信した場合に、前記第１のホストのＲＳＶＰ支援情報に応じて前記第１のホストとのトンネルセッションを設定するためのトンネル予約メッセージとカプセル化された前記予約メッセージとを同時に前記第１のホストへ伝送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
4. 前記ノードは、前記第２のホストと設定される終端間セッション情報と、前記終端間セッション情報にマッピングされる前記第１のホストとのトンネルセッション情報を管理し、前記第２のホストからパケットが受信される終端間セッションにマッピングされるトンネルセッションを介して前記第１のホストへ前記パケットを伝送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
5. 前記要請メッセージは、前記ノードが、前記第２のホストからパケットを受信した場合に、前記パケットの目的地情報に相当するＩＰｖ４アドレス情報を要請するバインディング要請メッセージであることを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
6. 前記パケットは、前記ＲＳＶＰによってパケットを交換するためのセッションを設定するＲＳＶＰメッセージであることを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
7. ＲＳＶＰメカニズムによって経路資源を予約するＩＰｖ４／ＩＰｖ６統合ネットワークシステムであって、
   ＤＳＴＭによってＩＰｖ６網に接続された第１のホストにＩＰｖ４アドレス情報を割り当てる割当メッセージを伝送した後に、受信される割当応答メッセージからＲＳＶＰ支援情報を取得し、ノードからのＩＰｖ４アドレス情報のマッピング情報を要請する要請メッセージを受信した場合に、前記マッピング情報及び前記ＲＳＶＰ支援情報が含まれる更新メッセージを前記ノードに提供するＤＳＴＭサーバーと、
   該ＤＳＴＭサーバーから前記割当メッセージを受信した場合に、前記ＲＳＶＰ支援情報が含まれる割当応答メッセージを前記ＤＳＴＭサーバーへ伝送し、前記割当メッセージを通じて割り当てられた前記ＩＰｖ４アドレス情報を用いて前記ＩＰｖ４網に属している第２のホストへパケットを伝送する第１のホストと、
   該ＤＳＴＭサーバーによって前記第１のホストに割り当てられたＩＰｖ４アドレス情報を用いてパケットを前記第１のホストへ伝送する第２のホストと、
   該第２のホストから受信される前記パケットの目的地アドレス情報のマッピング情報を要請する要請メッセージを前記ＤＳＴＭサーバーへ伝送し、前記ＤＳＴＭサーバーから受信される前記更新メッセージに含まれた前記第１のホストのＲＳＶＰ支援情報に応じて、端末間セッションとトンネルセッションのマッピング情報を格納することによりセッションを設定した後に、前記マッピング情報に応じて前記パケットを第１のホストへ伝送するノードと、を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
8. 前記第１のホストのＩＰｖ４アドレス情報を問い合わせするための第１のタイプの問い合わせメッセージを前記第２のホストから前記ＤＳＴＭサーバーへ伝送し、前記第１のホストのＩＰｖ４アドレス情報を前記第２のホストへ提供する第１のＤＮＳサーバーと、
   該ＤＳＴＭサーバーから受信される第２のタイプの問い合わせメッセージに応じて前記第１のホストのＩＰｖ４アドレス情報及びＩＰｖ６アドレス情報が含まれる応答メッセージを提供する第２のＤＮＳサーバーとをさらに備えることを特徴とする請求項７に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
9. 前記ＤＳＴＭサーバーは、前記第１のＤＮＳサーバーから受信される第１のタイプの問い合わせメッセージを前記第２のタイプの問い合わせメッセージに変換して前記第２のＤＮＳサーバーへ伝送するとともに、前記第２のＤＮＳサーバーから受信される第２のタイプの応答メッセージを第１のタイプの応答メッセージに変換して前記第１のＤＮＳサーバーへ伝送するＤＮＳゲートウエーと、
   前記第１のホストにＩＰｖ４アドレス情報を割り当て、かつ割り当てられた前記ＩＰｖ４アドレス情報を前記第２のＤＮＳサーバーに登録し、前記ＩＰｖ４アドレス情報が含まれる割当メッセージを前記第１のホストへ伝送するＤＳＴＭマネジャー部と、
   前記第１のホストの前記マッピング情報を格納するマッピングテーブルと、を備えることを特徴とする請求項７に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
10. 前記ＤＳＴＭマネジャー部は、前記第１のホストから受信される前記割当応答メッセージに含まれたＲＳＶＰ支援情報を把握し、前記ノードから受信される要請メッセージに含まれた前記目的地アドレス情報にマッピングされるマッピング情報及び前記第１のホストのＲＳＶＰ支援情報が含まれる更新メッセージを、前記ノードへ伝送することを特徴とする請求項９に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
11. 前記マッピング情報は、前記第１のホストのＩＰｖ６アドレス情報、割り当てられる前記Ｐｖ４アドレス情報または前記ＩＰｖ４アドレス情報の有効時間情報のうち少なくとも１つ以上の情報を含むことを特徴とする請求項９に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
12. 前記各メッセージは、ＩＰｖ６ヘッダーの予備フィールドのうち所定のフィールドがＲＳＶＰ支援情報を示すＲＳＶＰフィールドに設定されることを特徴とする請求項７に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステム。
13. 各々異なる網に属するホストと、ＤＳＴＭサーバーと、ノードとを備えたＩＰｖ４／ＩＰｖ６統合ネットワークにおけるＲＳＶＰメカニズムによって経路資源を予約する方法であって、
    前記ＤＳＴＭサーバーが第１のホストのＲＳＶＰ支援情報を把握し、前記ノードからの要請メッセージを受信した場合に、前記ＲＳＶＰ支援情報が含まれる更新メッセージを前記ノードへ伝送する段階と、
    前記第１のホストが、ＲＳＶＰによる経路メッセージを第２のホストへ伝送する段階と、
    前記第２のホストが、前記経路メッセージを受信した場合に、ＲＳＶＰによる予約メッセージを前記ノードへ伝送する段階と、
    前記ノードが、前記更新メッセージを通じて把握される前記第１のホストのＲＳＶＰ支援情報に応じて、前記第２のホストとの終端間セッションを設定するための予約メッセージと、前記第１のホストとのトンネルセッションを設定するためのトンネル予約メッセージとを同時に前記第１のホストへ伝送し、端末間セッションとトンネルセッションのマッピング情報を格納する段階と、を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法。
14. 前記ノードが、前記第１のホストから受信したカプセル化した前記経路メッセージを受信した場合に、カプセル化された前記経路メッセージを脱カプセル化し、前記第２のホストへ伝送する段階と、
    前記第２のホストから予約メッセージを受信した場合に、前記予約メッセージをカプセル化し、前記第１のホストとのトンネルセッションを設定するためのトンネル予約メッセージと、前記カプセル化された予約メッセージとを同時に前記第１のホストへ伝送する段階と、
    前記第２のホストと設定される終端間セッション情報と、前記終端間セッション情報にマッピングされる前記第１のホストとのトンネルセッション情報とを管理する段階と、をさらに備えることを特徴とする請求項１３に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法。
15. 前記ＤＳＴＭサーバーが、前記第１のホストに割り当てられるＩＰｖ４アドレス情報と、前記第１のホストのマッピング情報とを管理する段階と、
    前記第１のホストが、前記割当メッセージを通じて割り当てられた前記各アドレス情報を用いてパケットを伝送する段階と、
    前記第２のホストが、前記第１のホストに割り当てられる前記ＩＰｖ４アドレス情報を用いてパケットを伝送する段階と、
    前記ノードが、前記第２のホストから受信される前記パケットの目的地アドレス情報にマッピングされるマッピング情報を要請する要請メッセージを前記ＤＳＴＭサーバーへ伝送する段階と、
    前記ＤＳＴＭサーバーが、前記要請メッセージを受信した場合に、前記目的地アドレス情報にマッピングされるマッピング情報と前記第１のホストのＲＳＶＰ支援情報とが含まれる更新メッセージを前記第２のホストへ伝送する段階、とをさらに備えることを特徴とする請求項１３に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法。
16. 各々異なる網に属しているホストと、ＤＳＴＭサーバーと、ノードとを備えたＩＰｖ４／ＩＰｖ６統合ネットワークシステムにおいてＲＳＶＰメカニズムによって経路資源を予約する方法であって、
    前記ＤＳＴＭサーバーが、ＩＰｖ６網に接続された第１のホストにＩＰｖ４アドレス情報を割り当てるとともに、前記第１のホストのＲＳＶＰ支援情報を把握する段階と、
    前記ノードが、前記第２のホストからパケットを受信した場合に、前記パケットの目的地アドレス情報に対応したマッピング情報を要請する要請メッセージを前記ＤＳＴＭサーバーへ伝送する段階と、
    前記ＤＳＴＭサーバーが、前記要請メッセージに対応したマッピング情報と、前記第１のホストのＲＳＶＰ支援情報とが含まれる更新メッセージを前記ノードへ伝送する段階と、
    前記ノードが、前記更新メッセージから把握される前記第１のホストのＲＳＶＰ支援情報に応じて、トンネル予約メッセージとカプセル化された終端間予約メッセージとをDSTMホストに伝送し、端末間セッションとトンネルセッションのマッピング情報を格納する段階と、を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合網で経路資源を予約する方法。
17. 前記第２のホストから受信されるパケットは、ＲＳＶＰメカニズムによってセッションを設定するための予約メッセージであることを特徴とする請求項１６に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法。
18. 前記第１のホストのＲＳＶＰ支援情報を把握する段階は、
    前記ＤＳＴＭサーバーが、前記第１のホストにＩＰｖ４アドレス情報を割り当てる段階と、
    前記割り当てられたＩＰｖ４アドレス情報、及び前記ノードのＩＰｖ６アドレス情報が含まれる割当メッセージを前記第１のホストへ伝送する段階と、
    前記第１のホストが、前記割当メッセージから前記各アドレス情報を把握し、前記ＲＳＶＰ支援情報が含まれる応答メッセージを前記ＤＳＴＭサーバーへ伝送する段階と、
    前記ＤＳＴＭサーバーが、前記応答メッセージに含まれた前記第１のホストの前記ＲＳＶＰ支援情報を把握する段階と、を備えることを特徴とする請求項１６に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法。
19. 前記ＤＳＴＭサーバーが、前記第１のホストのマッピング情報をテーブルで管理する段階と、
    前記ＤＳＴＭサーバーが、前記ノードから要請メッセージを受信した場合に、前記テーブルで管理される第１のホストのマッピング情報を検索し、前記マッピング情報及び前記ＲＳＶＰ支援情報が含まれる更新メッセージを前記ノードへ伝送する段階と、をさらに備えることを特徴とする請求項１６に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法。
20. 前記ノードが、前記第２のホストからＲＳＶＰによる予約メッセージを受信した場合に、前記第１のホストのＲＳＶＰ支援情報に応じてトンネルセッションを設定するためのトンネル予約メッセージと、終端セッションを設定するための終端間予約メッセージとを同時に前記第１のホストへ伝送する段階と、をさらに備えることを特徴とする請求項１６に記載のＩＰｖ４／ＩＰｖ６統合ネットワークシステムで経路資源を予約する方法。

Images