JP2006319979A - ＩＰｖ４／ＩＰｖ６統合ネットワークのパケット処理方法及びそのシステム - Google Patents

Abstract

【課題】 各パケットのトンネルセッションを区別できるＩＰｖ４／ＩＰｖ６統合ネットワークのパケット処理方法及びそのシステムを提供する。
【解決手段】 ＲＳＶＰによって転送すべきパケットが存在する場合、送信ホストと、ＩＰｖ４網とＩＰｖ６網との境界に位置し、前記送信ホストに設定される前記終端セッションにマッピングされるトンネルセッションを設定し、前記各セッションを区別できる識別情報が含まれるトンネル経路メッセージを、トンネルセッションが設定された第２のノードへ転送する第１のノードと、前記第１のノードと前記トンネルセッションを設定し、前記トンネル経路メッセージに含まれた前記識別情報を把握し、マッピングされる終端セッションへ転送する第２のノードと、前記送信ホストから前記各ノードを介して前記経路メッセージが受信された場合には、予約メッセージを前記送信ホストへ転送する受信ホストと、を備える。
【選択図】 図１４

Description

本発明は、ＩＰｖ４／ＩＰｖ６統合ネットワークのパケット処理方法及びそのシステムに関し、より詳細には、ＩＰｖ４／ＩＰｖ６統合網でパケットを転送するとき、トンネルセッションを区別するためのＩＰ／ＵＤＰヘッダーのカプセル化で発生するオーバーヘッドを最小化するＩＰｖ４／ＩＰｖ６統合ネットワークのパケット処理方法及びそのシステムに関する。

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

このようなマルチメディアトラフィックは、ネットワーク上で発生する転送遅延やジッター（Ｊｉｔｔｅｒ）に大きな影響を受けるという特徴がある。

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

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

しかしながら、現在のインターネットは、ＩＰｖ４網で構築されて広く運用されているため、一度にＩＰｖ６網へ転換することは、現実的に不可能なので、現在はＩＰｖ４網とＩＰｖ６網が共存し、次第にＩＰｖ６網に転換されている。

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

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

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

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

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

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

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

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

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

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

以下、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）について簡略に説明する。

ＲＳＶＰは、特定のアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）フローが要求するＱｏＳを提供するために提案されたＩｎｔＳｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ）モデルにおいて終端間のパケットを転送するためのリソースを予約するために設計されたプロトコルである。

ＲＳＶＰは、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ルーティングプロトコルなどと同様に、インターネットプロトコル（ＩＰ）上で動作する。

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

フローの送信終端は、このようなセッションとサブフローを初期化した後、目的地までリソースが予約される経路を設定するために、経路（Ｐａｔｈ）メッセージを転送する。

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

このようなＰａｔｈメッセージは、Ｒｏｕｔｅ Ａｌｅｒｔ ＩＰオプションを含んで目的地である受信終端に向かって転送されるので、送信終端から受信終端までの経路上の全てのノードを経由してＲＳＶＰを支援するノードにより処理される。

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

受信終端は、Ｐａｔｈメッセージが受信されれば、フローに対する経路を設定した後、要求するＱｏＳに対するリソースを要請する予約（Ｒｅｓｖ）メッセージをＰａｔｈメッセージを通じて設定された経路情報に応じてホップ−バイ−ホップで送信終端に転送する。

Ｒｅｓｖメッセージには、‘ＳＥＳＳＩＯＮオブジェクト’、‘ＲＳＶＰ＿ＨＯＰオブジェクト’、要求するＱｏＳを定義する‘Ｆｌｏｗ ｓｐｅｃ’、及びサブ−フローを区別するための‘Ｆｉｌｔｅｒ ｓｐｅｃ’などが含まれる。

ＲＳＶＰを支援するノード、すなわち、Ｐａｔｈメッセージを通じて経路が設定される全てのノードは、ホップ−バイ−ホップで転送されるＲｅｓｖメッセージにより要請されるリソース予約要請を承諾／拒絶するようになる。ノードがリソース予約要請を承諾する場合には、Ｐａｔｈメッセージにより設定された経路に沿って次のノードにＲｅｓｖメッセージを転送し、拒絶する場合には、受信終端に予約エラー（Ｒｅｓｖ Ｅｒｒ）メッセージを転送することによって、リソース予約要請に失敗したことを知らせる。

現在ＲＳＶＰでは、セッションとサブフローとを区別するために、ＩＰアドレス情報とポート情報を使用し、保安などのような理由でポート情報を使用しがたい場合には、ＩＰｖ６ヘッダーのＩＰアドレス情報とフローレベル（ｆｌｏｗ ｌａｂｅｌ）フィールドを用いてサブ−フィールドを区別する‘ＦＩＬＴＥＲ＿ＳＰＥＣ’または‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’形式を別途に定義している。

そして、‘ＲＦＣ ２７４６’には、トンネルが設定された経路上で終端間のＲＳＶＰを支援するメカニズムについて定義している。このようなメカニズムの基本的な方式は、ＲＳＶＰメッセージ、すなわちＰａｔｈメッセージ及びＲｅｓｖメッセージを繰り返し転送することである。

言い換えれば、終端間のＲＳＶＰメッセージの転送だけでなく、トンネル区間のためのＲＳＶＰメッセージを別々に転送することによって、トンネル区間内に経路設定とリソース予約を行い、トンネル区間内に設定されたリソース予約とトンネル区間以外に設定されたリソース予約とをマッピングすることによって、トンネルを含む終端間にリソース予約を行う。‘ＲＦＣ ２７４６’では、このようなメカニズムのために、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ’と‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’を新しく定義した。

‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’は、トンネルセッションと終端間のセッションとをマッピングするためのものである。

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

図１に示されるように、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’には、長さ情報を有する長さ（Ｌｅｎｇｔｈ）フィールドと、種類情報を有するクラス（Ｃｌａｓｓ）フィールドと、タイプ情報を有するタイプフィールドと、終端間のセッション情報を有する‘ＳＥＳＳＩＯＮオブジェクト’フィールドと、トンネルセッション情報を有する‘ＦＩＬＴＥＲ＿ＳＰＥＣ情報’フィールドとを含む。

このような‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’は、送信終端から受信終端へ転送されるＰａｔｈメッセージに含まれる。

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

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

図２に示されるように、トンネル区間の最後のノードがトンネルＲＳＶＰメカニズムを支援できる場合には、受信終端から送信終端へ転送されるＲｅｓｖメッセージの‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’に、ＲＳＶＰを支援できるか否かを知らせる‘Ｔ ｂｉｔ’を設定し、転送する。

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

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

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

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

送信終端１０（Ｓ１）は、ＩＰヘッダーのソースアドレス情報を自分のＩＰアドレス情報‘Ｓ＿ＩＰ’として設定し、目的地アドレス情報を受信終端（Ｄ１）２０のＩＰアドレス情報‘Ｄ＿ＩＰ’として設定する。

そして、送信終端（Ｓ１）１０は、終端間のＰａｔｈメッセージの‘ＳＥＳＳＩＯＮオブジェクト’に、目的地アドレス情報‘Ｄ＿ＩＰ’、目的地ポート情報‘Ｄ＿Ｐｏｒｔ’を設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’のソースアドレス情報を自分のアドレス情報‘Ｓ＿ＩＰ’として設定し、ソースポート情報を自分のポート情報‘Ｓ＿Ｐｏｒｔ’として設定する。

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

そして、トンネルの開始ノードであるＲｅｎｔｒｙ３１は、Ｐａｔｈメッセージが受信されれば、トンネルの最後のノードであるＲｅｘｉｔ３２がＲＳＶＰメカニズムを支援できるかについて認識することができず、終端間のセッションに対する経路状態を格納し、Ｐａｔｈメッセージをカプセル化し、Ｒｅｘｉｔ３２へ転送する。

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

受信終端２０は、Ｐａｔｈメッセージを受信されれば、Ｒｅｓｖメッセージをホップ−バイ−ホップで送信終端（Ｓ１）１０へ転送する。

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

図４を参照すれば、受信終端（Ｄ１）２０は、ＩＰヘッダーＨｄｒのソースアドレス情報を‘Ｄ＿ＩＰ’として設定し、目的地アドレス情報をＲＳＶＰメカニズムを支援するアップストリームノードＮｅｘｔ＿ＨｏｐであるＲｅｘｉｔ３２のＩＰアドレス情報として設定し、ＲＳＶＰメッセージの‘ＳＥＳＳＩＯＮオブジェクト’は、Ｐａｔｈメッセージと同じ情報を含み、‘ＦＩＬＴＥＲＳＰＥＣオブジェクト’は、Ｐａｔｈメッセージの‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’と同じ情報を含めてＲｅｘｉｔ３２へ転送する。

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

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

このとき、Ｒｅｎｔｒｙ３１がトンネルＲＳＶＰメカニズムを支援できれば、Ｒｅｎｔｒｙ３１は、Ｒｅｓｖメッセージをアップリンクで送信終端（Ｓ１）１０へ転送しながら、トンネルＰａｔｈメッセージをＲｅｘｉｔ３２へ転送する。

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

図５を参照すれば、トンネルの開始ノードであるＲｅｎｔｒｙ３１は、Ｒｅｓｖメッセージが受信されれば、終端間のセッションにマッピングされるトンネルセッションを生成し、トンネル内のリソースを予約できるように、トンネルＰａｔｈメッセージ（Ｔｕｎｎｅｌ Ｐａｔｈ ｍｅｓｓａｇｅ）と、経路上の変更情報を知らせるための終端間のＰａｔｈメッセージ（Ｅ ｔｏ Ｅ Ｐａｔｈ ｍｅｓｓａｇｅ）をＲｅｘｉｔ３２へ転送する。

トンネルＰａｔｈメッセージの送信ノードは、Ｒｅｎｔｒｙ３１であり、受信ノード３２は、Ｒｅｘｉｔであることから、ＩＰヘッダーのソースアドレス情報は、Ｒｅｎｔｒｙ３１のアドレス情報‘Ｅｎｔｒｙ＿ＩＰ’、目的地アドレス情報は、‘Ｅｘｉｔ＿ＩＰ’として設定され、‘ＳＥＳＳＩＯＮオブジェクト’の目的地アドレス情報は、‘Ｅｘｉｔ＿ＩＰ’として設定され、目的地ポート情報は、一例として、‘３６３’が設定される。

そして、トンネルＰａｔｈメッセージの‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’のソースアドレス情報は、‘Ｅｎｔｒｙ＿ＩＰ’となり、ソースポート情報は、トンネル内で各フローを区別するためにＲｅｎｔｒｙ３１が割り当てた特定の値となる。

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

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

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

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

図６を参照すれば、トンネルＲｅｓｖメッセージのＩＰヘッダーに含まれるソースアドレス情報は、‘Ｅｘｉｔ＿ＩＰ’として設定し、目的地アドレス情報は、ＲＳＶＰを支援するＲｅｘｉｔ３２のアップストリームノードＮｅｘｔ＿ｈｏｐのアドレス情報として設定される。

そして、トンネルＲｅｓｖメッセージにおいて‘ＳＥＳＳＩＯＮオブジェクト’の目的地アドレス情報は、‘Ｅｘｉｔ＿ＩＰ’として設定され、目的地ポート情報は、‘３６３’として設定され、‘ＦＩＬＴＥＲ ＳＰＥＣオブジェクト’のソースアドレス情報は、‘Ｅｎｔｒｙ＿ＩＰ’として設定され、ソースポート情報は、Ｒｅｎｔｒｙが終端間のセッションに該当するトンネルセッションのために割り当てた値２００として設定される。

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

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

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

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

Ｒｅｎｔｒｙ３１は、第１の送信終端１０からパケットが受信されれば、パケットのＩＰヘッダーとＵＤＰヘッダーをカプセル化し、Ｒｅｘｉｔ３２へ転送する。

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

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

このような‘ＲＦＣ ２７４６’に定義されているＲＳＶＰメカニズムは、トンネル区間の開始ノードと最後のノードが終端間のホストに代えて、トンネル区間でリソースを予約できるトンネルＲＳＶＰメッセージを転送し、終端間のセッションとトンネルセッションをマッピングすることで、トンネルを含む経路で終端間のＲＳＶＰを支援できるようにしている。

しかしながら、ＲＳＶＰメカニズムでは、トンネルセッションの送信終端１０のＩＰアドレス情報、目的地ＩＰアドレス情報及び目的地ポート情報が全て同一なので、トンネルセッションのソースポート情報を用いてトンネルセッションを区別している。

したがって、トンネル区間を通る全てのパケットがトンネル区間で所望のリソースを割り当てられるためには、ＩＰ／ＵＤＰヘッダーをカプセル化しなければならないが、ＩＰ／ＵＤＰカプセル化は、ＩＰカプセル化に比べてオーバーヘッドが多く発生し、ネットワークリソースを浪費する。

従って、本発明は、前述のような問題点を解決するためになされたもので、本発明の目的は、ＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰメカニズムに応じてパケットをトンネリングするとき、各トンネルセッションを区別するために、ＩＰ／ＵＤＰカプセル化を行うことなく、各パケットのトンネルセッションを区別できるＩＰｖ４／ＩＰｖ６統合ネットワークのパケット処理方法及びそのシステムを提供することにある。

上記目的を達成するために、本発明の一態様に係るＩＰｖ４／ＩＰｖ６統合網は、ＩＰｖ４網とＩＰｖ６網との境界に位置し、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によってパケットを転送するために設定されるトンネルセッションにマッピングされる終端セッションを管理し、前記パケットが前記トンネルセッションを介して受信される場合、前記トンネルセッションにマッピングされる終端セッションへ前記パケットを転送し、前記パケットが前記終端セッションを介して受信される場合、前記終端セッションにマッピングされる前記トンネルセッションを介して転送する多数のノードを備える。

本発明の他の態様に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステムは、ＲＳＶＰによって転送すべきパケットが存在する場合、セッションのリソースを要請する経路メッセージを受信ホストへ転送し、設定される終端セッションへ前記パケットを転送する送信ホストと、ＩＰｖ４網とＩＰｖ６網との境界に位置し、前記送信ホストに設定される前記終端セッションにマッピングされるトンネルセッションを設定し、前記各セッションを区別できる識別情報が含まれるトンネル経路メッセージを、トンネルセッションが設定された第２のノードへ転送し、前記終端セッションを介して受信されるパケットを、マッピングされるトンネルセッションへ転送する第１のノードと、前記第１のノードと前記トンネルセッションを設定し、前記トンネル経路メッセージに含まれた前記識別情報を把握し、前記トンネルセッションを介して受信されるパケットを、マッピングされる終端セッションへ転送する第２のノードと、前記送信ホストから前記各ノードを介して前記経路メッセージが受信された場合には、前記各セッションが設定されるように予約メッセージを前記送信ホストへ転送する受信ホストと、を備える。

また、本発明の他の態様に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステムは、第１のノードと第２のノードとの間に位置し、パケットのヘッダーに含まれた識別情報に相当するトンネルセッションへパケットを転送する少なくとも１つのノードをさらに備える。

また、本発明のさらに他の態様に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステムは、ＲＳＶＰに応じてパケットを転送すべきセッションのリソースを要請する経路メッセージを提供し、リソースが予約されれば、トンネルセッションの識別情報が含まれるトンネル経路メッセージを提供し、トンネルセッションを介してパケットを転送する送信ホストと、送信ホストに設定されるトンネルセッションの識別情報と、マッピングされる終端セッションの情報を管理しながら、パケットが受信されるトンネルセッションにマッピングされる終端セッションへパケットを転送するノードと、ノードを介して受信される経路メッセージに応じて予約メッセージを転送し、終端セッションを設定し、パケットを受信する受信ホストと、を備える。

また、本発明のさらに他の態様に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法は、少なくとも１つのノードを備えたＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法であって、送信ホストが各ノードを介してＲＳＶＰに依存する経路メッセージを受信ホストへ転送する段階と、受信ホストが経路メッセージに応じて少なくとも１つの終端セッションを設定し、予約メッセージを各ノードを介して送信ホストへ転送する段階と、少なくとも１つのノードの開始ノードである第１のノードが、予約メッセージを受信すれば、各終端セッションにマッピングされる各トンネルセッションを設定し、各トンネルセッションの識別情報が含まれるトンネル経路メッセージを少なくとも１つのノードの最後のノードである第２のノードへ転送する段階と、第１のノードが、送信ホストからパケットが受信された終端セッションにマッピングされるトンネルセッションの識別情報をパケットに含めて該当トンネルセッションを介して第２のノードへ転送する段階と、第２のノードが、パケットの識別情報に応じてトンネルセッションにマッピングされる終端セッションを介してパケットを受信ホストへ送する段階と、を備える。

また、本発明のさらに他の態様に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法は、第１のノードが、受信される経路メッセージをカプセル化し、第２のノードへ転送する段階と、第２のノードが、経路メッセージを脱カプセル化し、受信ホストへ転送する段階と、受信ホストが、経路メッセージに応じて終端セッションを設定し、予約メッセージを第２のノードへ転送する段階と、第２のノードが、予約メッセージにＲＳＶＰ支援可能情報を含めた後、カプセル化し、第１のノードへ転送する段階と、第１のノードが、予約メッセージに含まれたＲＳＶＰ支援可能情報に応じて終端セッションにマッピングされるトンネルセッションの識別情報が含まれるトンネル経路メッセージを第２のノードへ転送する段階と、第２のノードが、トンネル経路メッセージに応じてトンネルセッションを設定し、トンネル予約メッセージを第１のノードへ転送する段階と、をさらに備える。

また、本発明のさらに他の態様に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法は、少なくとも１つのノードを備えたＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法において、送信ホストが、ノードを介してＲＳＶＰに依存する経路メッセージを受信ホストへ転送する段階と、受信ホストが、経路メッセージに応じてノードと終端セッションを設定し、予約メッセージをノードを介して送信ホストへ転送する段階と、送信ホストが、予約メッセージが受信されれば、終端セッションにマッピングされるトンネルセッションをノードと設定した後、トンネルセッションの識別情報が含まれるトンネル経路メッセージをノードへ転送する段階と、送信ホストが、パケットに識別情報を含めて該当トンネルセッションを介してパケットをノードへ転送する段階と、ノードが、パケットの識別情報に応じてトンネルセッションにマッピングされる終端セッションを介してパケットを受信ホストへ転送する段階と、を備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法は、送信ホストが、経路メッセージにヘッダーをカプセル化し、ノードへ転送する段階と、ノードが、経路メッセージのヘッダーを脱カプセル化し、受信ホストへ転送する段階と、ノードが、受信ホストから受信される予約メッセージにヘッダーをカプセル化し、送信ホストへ転送する段階と、をさらに備える。

また、本発明に係るＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法は、ノードが、各トンネルセッションの識別情報を管理する段階と、送信ホストから受信されるパケットのヘッダーに含まれた識別情報に相当するトンネルセッションを介してパケットを転送する段階と、を備える。

本発明によれば、ＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰに応じてトンネリング方法でパケットを転送する場合に、トンネル区間でＩＰｖ６ヘッダーのＦｌｏｗ Ｌａｂｅｌフィールドを通じてトンネルセッションを区別することによって、パケットのオーバーヘッドを小さくすることできるという効果がある。

以下、添付の図面を参照して、本発明の実施形態のＩＰｖ４／ＩＰｖ６統合ネットワークのパケット処理方法及びそのシステムを詳細に説明する。

図８は、本発明の好ましい実施形態のＲＳＶＰの経路メッセージの転送フローを説明するための図である。

図８を参照して、送信終端（Ｓｏｕｒｃｅ１）１００と受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００がＩＰｖ４ホストであり、トンネルの開始ノードである第１のノード（ＴＥＰ１）３１０と最後のノードである第２のノード（ＴＥＰ２）３２０は、デュアルスタック、すなわちＩＰｖ４／ＩＰｖ６スタックをサポートする場合について説明する。

そして、送信終端（Ｓｏｕｒｃｅ１）１００から第１のノード３１０まで、第１のノード３１０から第２のノード３２０まで、第２のノード３２０から受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００まで経路上の中間ノードは省略していると仮定する。

送信終端（Ｓｏｕｒｃｅ１）１００は、ＩＰヘッダー（ＩＰｖ４ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰアドレス情報‘Ｓ＿ＩＰｖ４’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）を受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００のＩＰアドレス情報‘Ｄ＿ＩＰｖ４’として設定する。

そして、送信終端（Ｓｏｕｒｃｅ１）１００は、ＲＳＶＰメッセージ（ＲＳＶＰ Ｍｓｇ）の‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）に目的地アドレス情報（ＤｓｔＡｄｄｒ）‘Ｄ＿ＩＰｖ４’として設定し、目的地ポート情報（Ｄｓｔ Ｐｏｒｔ）‘Ｄ＿Ｐｏｒｔ’を設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’（ＳＥＮＤＥＲ Ｄｉｓｃ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のアドレス情報‘Ｓ＿ＩＰｖ４’として設定し、ソースポート情報（Ｓｒｃ Ｐｏｒｔ）を自分のポート情報‘Ｓ＿Ｐｏｒｔ’として設定することによって、終端間の経路メッセージ（Ｅ ｔｏ Ｅ Ｐａｔｈ Ｍｅｓｓａｇｅ）を生成する。

送信終端（Ｓｏｕｒｃｅ１）１００で生成された終端間のＰａｔｈメッセージは、‘Ｒｏｕｔｅｒ Ａｌｅｒｔ ＩＰオプション’を含んで転送されるため、送信終端（Ｓｏｕｒｃｅ１）１００と受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００間のＲＳＶＰを支援する全てのルータにより処理される。

そして、トンネルの開始ノードである第１のノード（ＴＥＰ１）３１０は、終端間のＰａｔｈメッセージを受信されれば、トンネルの最後のノードである第２のノード（ＴＥＰ２）３２０が、ＲＳＶＰメカニズムを支援できるかについて認識できないため、終端間のセッションに対する経路状態を格納し、終端間のＰａｔｈメッセージをカプセル化し、第２のノード（ＴＥＰ２）３２０へ転送する。

このとき、第１のノード（ＴＥＰ１）３１０は、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰｖ６アドレス情報‘ＴＥＰ１＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）を第２のノード（ＴＥＰ２）３２０のＩＰｖ６アドレス情報‘ＴＥＰ２＿ＩＰｖ６’として設定する。

第２のノード（ＴＥＰ２）３２０は、受信されるカプセル化した終端間のＰａｔｈメッセージを脱カプセル化し、終端間のセッションに対する経路を設定した後、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００へ転送する。

受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００は、終端間のＰａｔｈメッセージを受信されれば、終端間のＲｅｓｖメッセージをホップ−バイ−ホップで送信終端（Ｓｏｕｒｃｅ１）１００に転送する。

図９は、本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰの予約メッセージフローを説明するための図である。

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

第２のノード（ＴＥＰ２）３２０は、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００からＲｅｓｖメッセージが受信されれば、終端間のセッションに対するリソースを予約し、終端間のセッションにマッピングされるトンネルセッションがないので、第１のノード（ＴＥＰ１）３１０にトンネルＲＳＶＰを支援できることを知らせるために、‘Ｔ ｂｉｔ’が設定された‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’（ＮＯＤＥ ＣＨＡＲ）をＲｅｓｖメッセージに追加した後、Ｒｅｓｖメッセージをカプセル化し、第１のノード（ＴＥＰ１）３１０へ転送する。

第１のノード（ＴＥＰ１）３１０は、Ｒｅｓｖメッセージを脱カプセル化し、‘ＮＯＤＥ＿ＣＨＡＲ’を除去した後、終端間のセッションに対するリソースを予約する。そして、第１のノード（ＴＥＰ１）３１０は、‘ＮＯＤＥ＿ＣＨＡＲ’が除去されたＲｅｓｖメッセージをトンネルの送信終端（Ｓｏｕｒｃｅ１）１００へ転送する。

第１のノード（ＴＥＰ１）３１０は、‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’（ＮＯＤＥ ＣＨＡＲ）のＴビットが特定の値、例えば、‘１’として設定されたＲｅｓｖメッセージが受信されれば、トンネルの最後のノードである第２のノード（ＴＥＰ２）３２０がトンネルＲＳＶＰメカニズムをサポートできると判断し、Ｒｅｓｖメッセージをアップリンクで送信終端（Ｓｏｕｒｃｅ１）１００へ転送すると共に、終端間のセッションにマッピングされるトンネルセッションを形成し、トンネルＰａｔｈメッセージを第２のノード（ＴＥＰ２）３２０へ転送する。

この際、第１のノード（ＴＥＰ１）３１０は、終端間のセッションと、終端間のセッションにマッピングされるトンネルセッションの情報をマッピングテーブルを用いて管理できる。

図１０は、本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル経路メッセージフローを説明するための図である。

図１０を参照すれば、第１のノード（ＴＥＰ１）３１０は、トンネルＰａｔｈメッセージのＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を‘ＴＥＰ１＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）を第２のノード（ＴＥＰ２）３２０のＩＰｖ６アドレス‘ＴＥＰ２＿ＩＰｖ６’として設定する。

そして、第１のノード（ＴＥＰ１）３１０は、‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）には、目的地情報である目的地ＩＰアドレス情報（ＤｓｔＡｄｄｒ）Ｄ＿ＩＰｖ４と、目的地ポート情報（Ｄｓｔ Ｐｏｒｔ）Ｄ＿Ｐｏｒｔを設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’（ＳＥＮＤＥＲ Ｄｉｓｃ）の‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を設定する。

すなわち、第１のノード（ＴＥＰ１）３１０は、‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）には、第２のノード（ＴＥＰ２）３２０のＩＰｖ６アドレス情報である目的地アドレス情報（ＤｓｔＡｄｄｒ）を設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’（ＳＥＮＤＥＲ Ｄｉｓｃ）には、ソースアドレス情報（ＳｒｃＡｄｄｒ）を、‘ＴＥＰ１＿ＩＰｖ６’として設定し、‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値をトンネルセッションを区別できる特定の値として設定することによって、第２のノード（ＴＥＰ２）３２０までの経路上の、ＲＳＶＰを支援するノードが該当フローに対する経路状態を設定できるようにする。

また、第１のノード（ＴＥＰ１）３１０は、第２のノード（ＴＥＰ２）３２０が終端間のセッションと、終端間のセッションにマッピングされるトンネルセッションとをマッピングし得るように、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００のＩＰアドレスとポート情報を格納した終端間のセッションの‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）と、第１のノード３１０のＩＰアドレス情報と、‘ｆｌｏｗ ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を格納したトンネルセッションの‘ＦＩＬＴＥＲ＿ＳＰＥＣオブジェクト’（ＦＩＬＴＥＲ ＳＰＥＣ）とを含む‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）を終端間のＰａｔｈメッセージに追加し、第２のノード（ＴＥＰ２）３２０へ転送する。

図１１は、本発明の好ましい実施形態のＩＰｖ６ヘッダーを説明するための図である。

図１１を参照すれば、ＩＰｖ６ヘッダーは、バージョン（Ｖｅｒｓｉｏｎ）フィールド、トラフィッククラス（Ｔｒａｆｆｉｃ Ｃｌａｓｓ）フィールド、フローラベル（Ｆｌｏｗ Ｌａｂｅｌ）フィールド、ペイロード長さ（Ｐａｙｌｏａｄ Ｌｅｎｇｔｈ）フィールド、ネクストヘッダー（Ｎｅｘｔ Ｈｅａｄｅｒ）フィールド、ホップリミット（Ｈｏｐ Ｌｉｍｉｔ）フィールド、ソースアドレス（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）フィールド及び目的地アドレス（Ｄｅｓｔｉｎａｔｉｏｎ）フィールドで構成される。

バージョンフィールドは、ＩＰバージョンナンバー情報を含み、トラフィッククラスフィールドは、送信デバイスのパケット優先順位を決定する。

フローラベルフィールドは、パケット構造を識別するためのレイブルフィールドであり、ペイロード長さフィールドは、符号無しの整数（Ｕｎｓｉｇｎｅｄ Ｉｎｔｅｒｇｅｒ）タイプであり、ＩＰｖ６ヘッダーの残りの数字情報を含む。

すなわち、フローラベルフィールドは、ＩＰｖ６に新しく追加されたフィールドであり、特定のパケットフローに特別なサービスを提供するために追加されたフィールドである。

ネクストヘッダーフィールドは、ＩＰヘッダーに引き続くヘッダーのタイプを定義する。このようなネクストヘッダーフィールド値は、‘ＲＦＣ１７００’に定義されている。

ホップリミットフィールドは、ホップの最大経路数を定義し、符号無しの整数型であり、パケットが転送されるとき、各々のノードにより１ずつ減少する。ホップリミットフィールド値が‘０’となれば、パケットは無視される。

ソースアドレスフィールドは、１２８ビットの送信ノードのアドレス情報であり、目的地アドレスフィールドは、１２８ビットのパケット受信ノードのアドレス情報である。

したがって、第１のノード（ＴＥＰ１）３１０は、トンネルＰａｔｈメッセージの‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’（ＳＥＮＤＥＲ Ｄｉｓｃ）には、ソースアドレス情報（ＳｒｃＡｄｄｒ）を設定し、各フローにマッピングされるトンネルセッションを識別できる特定の値、例えば‘２００’を‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値として設定することによって、受信されるパケットを転送するトンネルセッションを区別できるようにする。

そして、第２のノード（ＴＥＰ２）３２０は、カプセル化したトンネルＰａｔｈメッセージが受信されれば、脱カプセル化し、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）を用いて終端間のセッションとトンネルセッションとをマッピングする。

すなわち、第２のノード（ＴＥＰ２）３２０は、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）のトンネル‘ＦＩＬＴＥＲ＿ＳＰＥＣオブジェクト’（ＦＩＬＴＥＲ ＳＰＥＣ）に該当する情報を用いてトンネルセッションを形成し、トンネルセッションと、終端間の‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）に定義された終端間のセッションとをマッピングする。

そして、第２のノード（ＴＥＰ２）３２０は、終端間のＰａｔｈメッセージの‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）を除去した後、目的地である受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００に向かってダウンストリーム方式で転送する。

また、第２のノード（ＴＥＰ２）３２０がトンネルセッションに対するトンネルＰａｔｈメッセージを受信されれば、トンネルセッションに対する経路を設定し、終端間のセッションとトンネルセッションのマッピング情報を用いて終端間のセッションに該当するリソースをトンネルセッションで予約するためのトンネルＲｅｓｖメッセージをアップストリーム方式で第１のノード（ＴＥＰ１）３１０へ転送する。

図１２は、本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル予約メッセージフローを説明するための図である。

図１２を参照すれば、第２のノード（ＴＥＰ２）３２０は、ソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰｖ６アドレス情報‘ＴＥＰ２＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）をＲＳＶＰを支援するアップストリームノードのアドレスＮｅｘｔ＿Ｈｏｐとして設定する。

そして、第２のノード３２０（ＴＥＰ２）は、‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）の目的地アドレス情報（ＤｓｔＡｄｄｒ）を‘ＴＥＰ２＿ＩＰｖ６’として設定し、‘ＦＩＬＴＥＲ ＳＰＥＣオブジェクト’（ＦＩＬＴＥＲ ＳＰＥＣ）は、ソースアドレス情報（ＳｒｃＡｄｄｒ）を‘ＴＥＰ１＿ＩＰｖ６’として設定し、‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を特定の値‘２００’に設定する。

このようなトンネルＲｅｓｖメッセージは、ホップ−バイ−ホップで転送され、トンネル内の経路上の、ＲＳＶＰを支援するノードがトンネルセッションリソースを予約できるようにし、第１のノード（ＴＥＰ１）３１０は、トンネルＲｅｓｖメッセージが受信されれば、終端間のセッションにマッピングされるトンネルセッションのためのリソースを予約する。

送信終端（Ｓｏｕｒｃｅ１）１００は、パケットを転送するためのセッションのリソースが予約されれば、パケットを第１のノード（ＴＥＰ１）３１０及び第２のノード（ＴＥＰ２）３２０を介して受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００へ転送する。

図１３は、本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でパケットのフローを説明するための図である。

図１３を参照すれば、送信終端（Ｓｏｕｒｃｅ１）１００は、生成されるパケットを第１のノード（ＴＥＰ１）３１０へ転送し、第１のノード（ＴＥＰ１）３１０は、受信されるパケットを終端間のセッションにマッピングされるトンネルセッション情報を用いてＩＰｖ６ヘッダーにカプセル化する。

第１のノード３１０（ＴＥＰ１）は、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰｖ６アドレス情報‘ＴＥＰ１＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）を第２のノードのＩＰｖ６アドレス情報‘ＴＥＰ２＿ＩＰｖ６’として設定し、‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を特定の値‘２００’として設定する。

そして、トンネルの経路上の、ＲＳＶＰを支援するノードは、受信されるパケットのＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）の‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値に該当するトンネルセッションを介してパケットを転送する。

この際、トンネル区間を通る全てのパケットのソースアドレス情報（ＳｒｃＡｄｄｒ）と目的地アドレス情報（ＤｓｔＡｄｄｒ）は、各々‘ＴＥＰ１＿ＩＰｖ６’と‘ＴＥＰ２＿ＩＰｖ６’であって、全て同一であり、各セッションによって異なる‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値が設定されるので、ＲＳＶＰを支援する各ノードは、ＩＰヘッダーの‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値によって異なるセッションを介してパケットを転送できる。

すなわち、ＩＰｖ４／ＩＰｖ６統合網で１つ以上のセッションリソースが予約された状態でトンネルセッションの開始ノード（ＴＥＰ１）３１０が、パケットが受信される終端間のセッションにマッピングされるトンネルセッションを介してパケットを転送するために、パケットが受信された終端間のセッションによって異なる特定の値を‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値として設定することによって、各々異なるトンネルセッションを介してパケットが転送されることができる。

図１４は、本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰメッセージのフローを説明するためのフローチャートである。

図１４を参照すれば、送信終端（Ｓｏｕｒｃｅ１）１００は、終端間のＰａｔｈメッセージ（Ｅ ｔｏ Ｅ Ｐａｔｈ Ｍｅｓｓａｇｅ）をトンネルセッションの開始ノードである第１のノード（ＴＥＰ１）３１０へ転送する（ステップＳ１０。なお、図中ではステップをＳと略す。）。

送信終端（Ｓｏｕｒｃｅ１）１００は、終端間のＰａｔｈメッセージの‘ＳＥＳＳＩＯＮオブジェクト’に、目的地アドレス情報‘Ｄ＿ＩＰｖ４’、及び目的地ポート情報‘Ｄ＿Ｐｏｒｔ’を設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’のソースアドレス情報を、自分のアドレス情報‘Ｓ＿ＩＰｖ４’として設定し、ソースポート情報を自分のポート情報‘Ｓ＿Ｐｏｒｔ’として設定する。

第１のノード（ＴＥＰ１）３１０は、終端間のＰａｔｈメッセージが受信されれば、終端間のセッションに対する経路状態を格納し、終端間のＰａｔｈメッセージをカプセル化し、第２のノード（ＴＥＰ２）３２０へ転送する（ステップＳ２０）。

第２のノード（ＴＥＰ２）３２０は、受信されるカプセル化した終端間のＰａｔｈメッセージを脱カプセル化し、終端間のセッションに対する経路を設定した後、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００へ転送する（ステップＳ３０）。

受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００は、終端間のＰａｔｈメッセージが受信されれば、終端間の予約メッセージをホップ−バイ−ホップ方式で第２のノード（ＴＥＰ２）３２０へ転送する（ステップＳ４０）。

このとき、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００は、終端間のＲｅｓｖメッセージの‘ＳＥＳＳＩＯＮオブジェクト’は、終端間のＰａｔｈメッセージと同じ情報を含み、‘ＦＩＬＴＥＲ ＳＰＥＣオブジェクト’は、終端間のＰａｔｈメッセージの‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’と同じ情報を含めて第２のノード（ＴＥＰ２）３２０へ転送する。

第２のノード（ＴＥＰ２）３２０は、終端間のＲｅｓｖメッセージが受信されれば、終端間のセッションに対するリソースを予約し、終端間のセッションにマッピングされるトンネルセッションがないので、トンネルＲＳＶＰメカニズムを支援できることを 第１のノード（ＴＥＰ１）３１０に知らせるために、‘Ｔ ｂｉｔ’が設定された‘ＮＯＤＥ＿ＣＡＨＲオブジェクト’を終端間のＲｅｓｖメッセージに追加した後、カプセル化し、第１のノード（ＴＥＰ１）３１０へ転送する（ステップＳ５０）。

第１のノード（ＴＥＰ１）３１０は、終端間のＲｅｓｖメッセージを脱カプセル化し、‘ＮＯＤＥ＿ＣＨＡＲ’を除去した後、終端間のセッションに対するリソースを予約する。そして、第１のノード（ＴＥＰ１）３１０は、‘ＮＯＤＥ＿ＣＨＡＲ’が除去された終端間のＲｅｓｖメッセージを送信終端（Ｓｏｕｒｃｅ１）１００へ転送する（ステップＳ６０）。

このとき、第１のノード（ＴＥＰ１）３１０は、‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’のＴビットが、特定の値、例えば、‘１’として設定された終端間のＲｅｓｖメッセージが受信されれば、第２のノード（ＴＥＰ２）３２０がトンネルＲＳＶＰメカニズムを支援できると判断し、終端間のＲｅｓｖメッセージを送信終端（Ｓｏｕｒｃｅ１）１００へ転送すると共に、終端間のセッションにマッピングされるトンネルセッションを形成し、トンネルＰａｔｈメッセージを第２のノード（ＴＥＰ２）３２０へ転送する（ステップＳ７０）。

そして、第１のノード（ＴＥＰ１）３１０は、‘ＳＥＳＳＩＯＮオブジェクト’には、目的地情報である目的地ＩＰアドレス情報Ｄ＿ＩＰｖ４と、目的地ポート情報Ｄ＿Ｐｏｒｔを設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’には、‘Ｆｌｏｗ Ｌａｂｅｌ’値を設定する。

また、第１のノード（ＴＥＰ１）３１０は、第２のノード（ＴＥＰ２）３２０が、終端間のセッションと、終端間のセッションにマッピングされるトンネルセッションとをマッピングし得るように、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００のＩＰアドレスとポート情報を格納した終端間のセッションの‘ＳＥＳＳＩＯＮオブジェクト’と、第１のノード（ＴＥＰ１）３１０のＩＰアドレス情報と特定の値‘ｆｌｏｗ ｌａｂｅｌ’値を格納したトンネルセッションの‘ＦＩＬＴＥＲ＿ＳＰＥＣオブジェクト’とを含む‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’を、終端間のＰａｔｈメッセージに追加し、第２のノード（ＴＥＰ２）３２０へ転送する（ステップＳ８０）。

第２のノード（ＴＥＰ２）３２０は、カプセル化した終端間のＰａｔｈメッセージが受信されれば、脱カプセル化し、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’を用いて終端間のセッションとトンネルセッションとをマッピングする。

すなわち、第２のノード（ＴＥＰ２）３２０は、‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’のトンネル‘ＦＩＬＴＥＲ＿ＳＰＥＣオブジェクト’に該当する情報を用いてトンネルセッションを形成し、トンネルセッションと、終端間の‘ＳＥＳＳＩＯＮオブジェクト’に定義された終端間のセッションとをマッピングする。

そして、第２のノード（ＴＥＰ２）３２０は、終端間のＰａｔｈメッセージの‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’を除去した後、目的地である受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２００へ転送する（ステップＳ９０）。

また、第２のノード（ＴＥＰ２）３２０がトンネルセッションに対するトンネルＰａｔｈメッセージを受信されれば、トンネルセッションに対する経路を設定し、終端間のセッションとトンネルセッションのマッピング情報を用いて終端間のセッションに該当するリソースをトンネルセッションで予約するためのトンネルＲｅｓｖメッセージを第１のノード（ＴＥＰ１）３１０へ転送する（ステップＳ１００）。

そして、送信終端（Ｓｏｕｒｃｅ１）１００は、パケットを転送するためのセッションのリソースが予約されれば、パケットを第１のノード（ＴＥＰ１）３１０へ転送し、第１のノード（ＴＥＰ１）３１０は、パケットが受信される終端間のセッションにマッピングされるトンネルセッションを介してパケットを転送する。このとき、第１のノード（ＴＥＰ１）３１０は、受信されるパケットのＩＰｖ６ヘッダーをカプセル化する時、パケットが受信される終端間のセッションによって特定の値を‘Ｆｌｏｗ Ｌａｂｅｌ’値として設定し、フローによってリソースが予約されたセッションを介してパケットが転送されるようにする。

図１５は、本発明の好ましい他の実施形態のＩＰｖ４／ＩＰｖ６統合網の終端間の経路メッセージフローを説明するための図である。

図１５を参照すれば、送信終端（Ｓｏｕｒｃｅ１）及びノードがＩＰｖ４／ＩＰｖ６デュアルスタックであり、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）がＩＰｖ４ｖホストである場合について説明する。

そして、送信終端（Ｓｏｕｒｃｅ１）１１０からノード（ＴＥＰ１）３００まで、ノード（ＴＥＰ１）３００から受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２１０までの経路上の中間ノードは省略していると仮定する。

送信終端（Ｓｏｕｒｃｅ１）１１０は、ＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰアドレス情報‘Ｓ＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）をノード（ＴＥＰ１）３００のアドレス情報‘ＴＥＰ＿ＩＰｖ６’として設定する。そして、送信終端１１０は、ＩＰｖ４ヘッダー（ＩＰｖ４ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰｖ４アドレス情報‘Ｈ１＿ＩＰｖ４’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）を受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２１０のＩＰｖ４アドレス情報‘Ｈ２＿ＩＰｖ４’として設定する。

そして、送信終端（Ｓｏｕｒｃｅ１）１１０は、終端間のＰａｔｈメッセージの‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）に、目的地アドレス情報（ＤｓｔＡｄｄｒ）‘Ｈ２＿ＩＰｖ４’、及び目的地ポート情報（ＤｓｔＰｏｒｔ）‘Ｈ２＿Ｐｏｒｔ’を設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’（ＳＥＮＤＥＲ Ｄｉｓｃ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のアドレス情報‘Ｈ１＿ＩＰｖ４’として設定し、ソースポート情報（ＳｒｃＰｏｒｔ）を自分のポート情報‘Ｈ１＿Ｐｏｒｔ’として設定する。

送信終端（Ｓｏｕｒｃｅ１）１１０で生成された終端間のＰａｔｈメッセージは、‘Ｒｏｕｔｅｒ Ａｌｅｒｔ ＩＰオプション’を含んで転送されるので、送信終端（Ｓｏｕｒｃｅ１）１１０と受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２１０間のＲＳＶＰを支援する全てのルータにより処理される。

そして、ノード（ＴＥＰ１）３００は、受信される終端間のＰａｔｈメッセージを脱カプセル化し、終端間のセッションに対する経路を設定した後、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２１０へ転送する。

受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２１０は、終端間のＰａｔｈメッセージを受信されれば、Ｒｅｓｖメッセージをホップ−バイ−ホップで送信終端（Ｓｏｕｒｃｅ１）１１０へ転送する。

図１６は、本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰの予約メッセージフローを説明するための図である。

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

ノード（ＴＥＰ１）３００は、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２１０からＲｅｓｖメッセージが受信されれば、終端間のセッションに対するリソース状態を予約し、終端間のセッションにマッピングされるトンネルセッションがないので、トンネルＲＳＶＰを支援できることを送信終端（Ｓｏｕｒｃｅ１）１１０に知らせるために、‘Ｔ ｂｉｔ’が設定された‘ＮＯＤＥ＿ＣＡＨＲオブジェクト’（ＮＯＤＥ ＣＨＡＲ）をＲｅｓｖメッセージに追加した後、カプセル化し、送信終端（Ｓｏｕｒｃｅ１）１１０へ転送する。

送信終端（Ｓｏｕｒｃｅ１）１１０は、ノード（ＴＥＰ１）３００から受信されるＲｅｓｖメッセージにおいて‘ＮＯＤＥ＿ＣＨＡＲオブジェクト’（ＮＯＤＥ ＣＨＡＲ）のＴビットが特定の値、例えば、‘１’に設定されていれば、ノード（ＴＥＰ１）３００がトンネルＲＳＶＰメカニズムをサポートできると判断し、終端間のセッションにマッピングされるトンネルセッションを形成し、トンネルＰａｔｈメッセージをノード（ＴＥＰ１）３００へ転送する。

図１７は、本発明の好ましい他の実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル経路メッセージフローを説明するための図である。

図１７を参照すれば、送信終端（Ｓｏｕｒｃｅ１）１１０は、トンネルＰａｔｈメッセージにおいてＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を‘Ｈ１１＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）をノード（ＴＥＰ１）３００のＩＰｖ６アドレス‘ＴＥＰ＿ＩＰｖ６’として設定する。

そして、送信終端（Ｓｏｕｒｃｅ１）１１０は、トンネルＰａｔｈメッセージの‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）には、目的地情報（ＤｓｔＡｄｄｒ）である目的地ＩＰアドレス情報ＴＥＰ＿ＩＰｖ４を設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’（ＳＥＮＤＥＲ Ｄｉｓｃ）には、’Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を設定する。

すなわち、送信終端（Ｓｏｕｒｃｅ１）１１０は、‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）には、ノード（ＴＥＰ１）３００のＩＰｖ６アドレス情報である目的地アドレス情報（ＤｓｔＡｄｄｒ）を設定し、‘ＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥオブジェクト’（ＳＥＮＤＥＲ Ｄｉｓｃ）には、ソースアドレス情報（ＳｒｃＡｄｄｒ）を‘Ｈ１＿ＩＰｖ６’として設定し、‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を、トンネルセッションを区別できる特定の値、例えば‘５００’として設定することによって、送信終端（Ｓｏｕｒｃｅ１）１１０からノード（ＴＥＰ１）３００までの経路上の、ＲＳＶＰを支援するノードが該当フローに対する経路状態を設定できるようにする。

また、ノード（ＴＥＰ１）３００は、トンネルＰａｔｈメッセージが受信されれば、終端間のセッションにマッピングされるトンネルセッションをマッピングし得るように、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）のＩＰアドレスとポート情報を格納した終端間のセッションの‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）と、ノード（ＴＥＰ１）３００のＩＰアドレス情報と‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を格納したトンネルセッションの‘ＦＩＬＴＥＲ＿ＳＰＥＣオブジェクト’（ＦＩＬＴＥＲ ＳＰＥＣ）とを含む‘ＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクト’（ＳＥＳＳＩＯＮ＿ＡＳＳＯＣ Ｏｂｊ）を、終端間のＰａｔｈメッセージに追加し、受信終端（Ｄｅｓｔｉｎａｔｉｏｎ１）２１０へ転送する。

そして、ノード（ＴＥＰ１）３００がトンネルセッションに対するトンネルＰａｔｈメッセージを受信されれば、トンネルセッションに対する経路を設定し、終端間のセッションとトンネルセッションのマッピング情報を用いて終端間のセッションに該当するリソースをトンネルセッションで予約するためのトンネルＲｅｓｖメッセージを送信終端（Ｓｏｕｒｃｅ１）１１０へ転送する。

図１８は、本発明の好ましい他の実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル予約メッセージフローを説明するための図である。

図１８を参照すれば、ノード（ＴＥＰ）３００は、ソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰｖ６アドレス情報‘ＴＥＰ＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）を、ＲＳＶＰを支援するアップストリームノードのアドレスＮｅｘｔ＿Ｈｏｐ、すなわち送信終端（Ｓｏｕｒｃｅ１）１１０のＩＰｖ６アドレス情報として設定する。

そして、ノード（ＴＥＰ）３００は、‘ＳＥＳＳＩＯＮオブジェクト’（ＳＥＳＳＩＯＮ Ｏｂｊ）の目的地アドレス情報（ＤｓｔＡｄｄｒ）を‘ＴＥＰ＿ＩＰｖ６’として設定し、‘ＦＩＬＴＥＲ ＳＰＥＣオブジェクト’（ＦＩＬＴＥＲ ＳＰＥＣ）は、ソースアドレス情報を‘Ｈ１＿ＩＰｖ６’として設定し、‘Ｆｌｏｗ Ｌａｂｅｌ’値を特定の値‘５００’として設定する。

このようなトンネルＲｅｓｖメッセージは、ホップ−バイ−ホップでトンネル内の経路上の、ＲＳＶＰを支援するノードがトンネルセッションリソースを予約できるようにし、送信終端（Ｓｏｕｒｃｅ１）１１０は、トンネル予約メッセージが受信されれば、終端間のセッションにマッピングされるトンネルセッションのためのリソースを予約する。

図１９は、本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でパケットのフローを説明するための図である。

図１９を参照すれば、送信終端（Ｓｏｕｒｃｅ１）１１０は、生成されるパケットのＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）のソースアドレス情報（ＳｒｃＡｄｄｒ）を自分のＩＰｖ６アドレス情報‘Ｈ１＿ＩＰｖ６’として設定し、目的地アドレス情報（ＤｓｔＡｄｄｒ）をノードのＩＰｖ６アドレス情報‘ＴＥＰ＿ＩＰｖ６’として設定し、‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値を特定の値‘２００’として設定する。

そして、ノード（ＴＥＰ）３００は、受信されるパケットのＩＰｖ６ヘッダー（ＩＰｖ６ Ｈｄｒ）の‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値によって終端間のセッションにマッピングされるトンネルセッションを介してパケットを転送する。

このとき、トンネル区間を通る全てのパケットのソースアドレス情報（ＳｒｃＡｄｄｒ）及び目的地アドレス情報（ＤｓｔＡｄｄｒ）は、各々‘ＴＥＰ１＿ＩＰｖ６’及び‘ＴＥＰ２＿ＩＰｖ６’であって、全て同一であり、各セッションによって異なる‘Ｆｌｏｗ Ｌａｂｅｌ’値が設定されるので、ＲＳＶＰを支援する各ノードは、ＩＰヘッダーの‘Ｆｌｏｗ Ｌａｂｅｌ’（Ｆｌｏｗ Ｌａｂｅｌ）値によって異なるセッションを介してパケットを転送できる。

すなわち、ＩＰｖ４／ＩＰｖ６統合網で１つ以上のセッションリソースが予約された状態で、トンネルセッションの開始ノードが、パケットが受信される終端間のセッションにマッピングされるトンネルセッションを介してパケットを転送するために、パケットが受信された終端間のセッションによって異なる特定の値を‘Ｆｌｏｗ Ｌａｂｅｌ’値として設定することによって、各々異なるトンネルセッションを介してパケットが転送されることができる。

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

一般的なＲＳＶＰのＳＥＳＳＩＯＮ＿ＡＳＳＯＣオブジェクトを説明するための図である。 一般的なＲＳＶＰのＮＯＤＥ＿ＣＨＡＲオブジェクトを説明するための図である。 一般的なＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰの経路メッセージフローを説明するための図である。 一般的なＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰの予約メッセージフローを説明するための図である。 一般的なＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル経路メッセージフローを説明するための図である。 一般的なＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル予約メッセージフローを説明するための図である。 一般的なＩＰｖ４／ＩＰｖ６統合網で多数のトンネルを介してパケットを転送することを説明するための図である。 本発明の好ましい実施形態のＲＳＶＰの経路メッセージの転送フローを説明するための図である。 本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰの予約メッセージフローを説明するための図である。 本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル経路メッセージフローを説明するための図である。 本発明の好ましい実施形態のＩＰｖ６ヘッダーを説明するための図である。 本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル予約メッセージフローを説明するための図である。 本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でパケットのフローを説明するための図である。 本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰメッセージのフローを説明するためのフローチャートである。 本発明の好ましい他の実施形態のＩＰｖ４／ＩＰｖ６統合網の終端間の経路メッセージフローを説明するための図である。 本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰの終端間の予約メッセージフローを説明するための図である。 本発明の好ましい他の実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル経路メッセージフローを説明するための図である。 本発明の好ましい他の実施形態のＩＰｖ４／ＩＰｖ６統合網でＲＳＶＰのトンネル予約メッセージフローを説明するための図である。 本発明の好ましい実施形態のＩＰｖ４／ＩＰｖ６統合網でパケットのフローを説明するための図である。

符号の説明

１００、１１０ 送信終端
２００、２１０ 受信終端
３００、３１０、３２０ ノード

Claims (20)

1. ＩＰｖ４／ＩＰｖ６統合網において、
   ＩＰｖ４網とＩＰｖ６網との境界に位置し、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によってパケットを転送するために設定されるトンネルセッションにマッピングされる終端セッションを管理し、前記パケットが前記トンネルセッションを介して受信される場合、前記トンネルセッションにマッピングされる終端セッションへ前記パケットを転送し、前記パケットが前記終端セッションを介して受信される場合、前記終端セッションにマッピングされる前記トンネルセッションを介して転送する多数のノードを備えることを特徴とするＩＰｖ４／ＩＰｖ６統合網。
2. ＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステムであって、
   ＲＳＶＰによって転送すべきパケットが存在する場合、セッションのリソースを要請する経路メッセージを受信ホストへ転送し、設定される終端セッションへ前記パケットを転送する送信ホストと、
   ＩＰｖ４網とＩＰｖ６網との境界に位置し、前記送信ホストに設定される前記終端セッションにマッピングされるトンネルセッションを設定し、前記各セッションを区別できる識別情報が含まれるトンネル経路メッセージを、トンネルセッションが設定された第２のノードへ転送し、前記終端セッションを介して受信されるパケットを、マッピングされるトンネルセッションへ転送する第１のノードと、
   前記第１のノードと前記トンネルセッションを設定し、前記トンネル経路メッセージに含まれた前記識別情報を把握し、前記トンネルセッションを介して受信されるパケットを、マッピングされる終端セッションへ転送する第２のノードと、
   前記送信ホストから前記各ノードを介して前記経路メッセージが受信された場合には、前記各セッションが設定されるように予約メッセージを前記送信ホストへ転送する受信ホストと、を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
3. 前記第１のノードは、
   前記終端セッションにマッピングされるトンネルセッションの情報を管理しながら、前記受信されるパケットのソース情報及び目的地情報に相当する識別情報を前記パケットに含めて該当トンネルセッションへ転送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
4. 前記第１のノードは、
   前記受信ホストから前記予約メッセージが受信された場合には、前記トンネルセッションの識別情報を有する前記パケットのＩＰｖ６ヘッダーのＦｌｏｗ Ｌａｂｅｌフィールドに含ませて転送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
5. 前記第１のノードと前記第２のノードとの間に位置し、前記パケットのヘッダーに含まれた前記識別情報に相当するトンネルセッションへ前記パケットを転送する少なくとも１つのノードをさらに備えることを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
6. 前記第２のノードは、
   前記第１のノードから受信される前記経路メッセージを脱カプセル化し、前記トンネルセッションに相当する前記終端セッションを介して前記受信ホストへ転送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
7. 前記第１のノード及び前記第２のノードは、
   ＩＰｖ４スタック及びＩＰｖ６スタックを有するデュアルスタックノードであることを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
8. 前記第１のノードは、
   少なくとも１つの終端セッションが設定された場合には、前記各終端セッションにマッピングされる各トンネルセッションを前記第２のノードと設定し、前記送信ホスト及び前記受信ホストから受信されるパケットのソース情報または目的地情報に相当するトンネルセッションの識別情報を前記パケットに含めて該当トンネルセッションに転送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
9. 前記第２のノードは、
   前記ＲＳＶＰに依存するトンネルセッションを設定できた場合には、前記受信ホストから受信される前記予約メッセージにＲＳＶＰ支援情報を含めて転送することを特徴とする請求項２に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
10. ＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステムであって、
    ＲＳＶＰに応じてパケットを転送すべきセッションのリソースを要請する経路メッセージを提供し、リソースが予約された場合には、トンネルセッションの識別情報が含まれるトンネル経路メッセージを提供し、前記トンネルセッションを介してパケットを転送する送信ホストと、
    前記送信ホストに設定されるトンネルセッションの識別情報と、マッピングされる終端セッションの情報を管理しながら、前記パケットが受信されるトンネルセッションにマッピングされる前記終端セッションへパケットを転送するノードと、
    前記ノードを介して受信される経路メッセージに応じて予約メッセージを転送し、終端セッションを設定し、前記パケットを受信する受信ホストと、
    を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
11. 前記ノードは、
    前記送信ホストから受信されるパケットのＩＰｖ６ヘッダーを脱カプセル化し、前記受信ホストへ転送することを特徴とする請求項１０に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
12. 前記送信ホストは、
    前記パケットのＩＰｖ６ヘッダーにトンネルセッションの識別情報を含めてカプセル化することを特徴とする請求項１０に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理するシステム。
13. 複数のノードを備えたＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法であって、
    送信ホストが前記各ノードを介してＲＳＶＰに依存する経路メッセージを受信ホストへ転送する段階と、
    前記受信ホストが前記経路メッセージに応じて少なくとも１つの終端セッションを設定し、予約メッセージを前記各ノードを介して送信ホストへ転送する段階と、
    前記複数のノードの開始ノードである第１のノードが、前記予約メッセージを受信した場合には、各終端セッションにマッピングされる各トンネルセッションを設定し、前記各トンネルセッションの識別情報が含まれるトンネル経路メッセージを前記複数のノードの最後のノードである第２のノードへ転送する段階と、
    前記第１のノードが、前記送信ホストからパケットが受信された終端セッションにマッピングされるトンネルセッションの識別情報を前記パケットに含めて該当トンネルセッションを介して前記第２のノードへ転送する段階と、
    前記第２のノードが、前記パケットの識別情報に応じて前記トンネルセッションにマッピングされる前記終端セッションを介して前記パケットを前記受信ホストへ送する段階と、
    を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。
14. 前記トンネル経路メッセージは、
    前記第１のノードが、前記予約メッセージが受信された場合には、前記各トンネルセッションの識別情報が含まれるＩＰｖ６ヘッダーをカプセル化することによって生成されることを特徴とする請求項１３に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。
15. 前記パケットの転送は、
    前記各ノードが、前記各トンネルセッションの識別情報を管理しながら、受信されるパケットのヘッダーに含まれた前記識別情報に相当するトンネルセッションへ前記パケットを転送することによって行われることを特徴とする請求項１３に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。
16. 前記識別情報は、
    ＩＰｖ６ヘッダーのＦｌｏｗ Ｌａｂｅｌフィールドに設定されることを特徴とする請求項１３に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。
17. 前記第１のノードが、受信される前記経路メッセージをカプセル化し、前記第２のノードへ転送する段階と、
    前記第２のノードが、前記経路メッセージを脱カプセル化し、前記受信ホストへ転送する段階と、
    前記受信ホストが、前記経路メッセージに応じて終端セッションを設定し、予約メッセージを前記第２のノードへ転送する段階と、
    前記第２のノードが、前記予約メッセージにＲＳＶＰ支援可能情報を含めた後に、カプセル化し、前記第１のノードへ転送する段階と、
    前記第１のノードが、前記予約メッセージに含まれた前記ＲＳＶＰ支援可能情報に応じて前記終端セッションにマッピングされるトンネルセッションの識別情報が含まれるトンネル経路メッセージを前記第２のノードへ転送する段階と、
    前記第２のノードが、前記トンネル経路メッセージに応じてトンネルセッションを設定し、トンネル予約メッセージを前記第１のノードへ転送する段階と、
    をさらに備えることを特徴とする請求項１３に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。
18. 少なくとも１つのノードを備えたＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法において、
    送信ホストが、前記ノードを介してＲＳＶＰに依存する経路メッセージを受信ホストへ転送する段階と、
    前記受信ホストが、前記経路メッセージに応じて前記ノードと終端セッションを設定し、予約メッセージを前記ノードを介して前記送信ホストへ転送する段階と、
    前記送信ホストが、前記予約メッセージが受信されれば、前記終端セッションにマッピングされるトンネルセッションを前記ノードと設定した後に、トンネルセッションの識別情報が含まれるトンネル経路メッセージを前記ノードへ転送する段階と、
    前記送信ホストが、前記パケットに前記識別情報を含めて該当トンネルセッションを介して前記パケットを前記ノードへ転送する段階と、
    前記ノードが、前記パケットの識別情報に応じて前記トンネルセッションにマッピングされる前記終端セッションを介して前記パケットを前記受信ホストへ転送する段階と、
    を備えることを特徴とするＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。
19. 前記送信ホストが、前記経路メッセージにヘッダーをカプセル化し、前記ノードへ転送する段階と、
    前記ノードが、前記経路メッセージのヘッダーを脱カプセル化し、前記受信ホストへ転送する段階と、
    前記ノードが、前記受信ホストから受信される前記予約メッセージに前記ヘッダーをカプセル化し、前記送信ホストへ転送する段階と、
    をさらに備えることを特徴とする請求項１８に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。
20. 前記パケットの転送は、
    前記ノードが、前記各トンネルセッションの識別情報を管理する段階と、
    前記送信ホストから受信されるパケットのヘッダーに含まれた識別情報に相当するトンネルセッションを介して前記パケットを転送する段階と、を備えることを特徴とする請求項１８に記載のＩＰｖ４／ＩＰｖ６統合網でパケットを処理する方法。

Images