(57)【要約】  異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切に提供できるようにする技術が開示され、その技術によればモバイルノード（ＭＮ）１１０が、Ｍｏｎａｍｉ６プロトコルを実装しており、Ｍｏｎａｍｉ６プロトコルのサービスをリクエストするバインディングアップデートメッセージを送信したとする。一方、ネットワークには、Ｍｏｎａｍｉ６プロトコルを実装しているホームエージェント（ＭＣＨＡ）と、実装していないホームエージェント（ＭＳＨＡ）が協働してＨＡの機能を動作させるオーバレイネットワークが存在している。この場合、例えば、モバイルノードからのメッセージをパス１１２経由で受信したＭＳＨＡ１５０は、Ｍｏｎａｍｉ６プロトコルを実装しているＭＣＨＡ（例えば、ＭＣＨＡ１３０）に、このリクエストを渡して処理させる。
2008114498.tif 000002
【特許請求の範囲】
【請求項１】
所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
当該オーバレイネットワークノードがサポートしていないサービスを受けようとしているモバイルノードを識別する識別手段と、
前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有するオーバレイネットワークノード。
【請求項２】
前記モバイルノードが受けようとしている前記サービスが、複数の気付アドレスの登録、フローフィルタリングルールの登録、Ｍｏｎａｍｉ６プロトコルに基づく動作のいずれかである請求項１に記載のオーバレイネットワークノード。
【請求項３】
前記サービスを受けようとしている前記モバイルノードに関して、前記サービスを受けようとしていることを示す情報と、前記特定のオーバレイネットワークノードの識別情報とを関連付けて記憶する情報記憶手段を有する請求項１に記載のオーバレイネットワークノード。
【請求項４】
前記サービスを受けようとしている前記モバイルノードから前記サービスのリクエストを直接受信した場合に、前記転送手段が、前記特定のオーバレイネットワークノードに前記リクエストを転送するように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項５】
前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットが、前記サービスをサポートしている任意のオーバレイネットワークノードで処理されたか否かを判断する処理判断手段を有し、
前記転送手段は、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されている場合には、前記データパケットを前記モバイルノードに転送する一方、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されていない場合には、前記データパケットを前記特定のオーバレイネットワークノードに転送するように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項６】
前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットに関するフローフィルタリングルールが存在しているか否かを確認するルールチェック手段を有し、
前記データパケットに関するフローフィルタリングルールが存在している場合には、前記転送手段が、前記フローフィルタリングルールに基づく前記データパケットの転送を行うように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項７】
所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
特定のサービスを提供するサービス提供手段と、
前記特定のサービスの提供を行う状態と、前記特定のサービスの提供を行わない状態とを切り換えるサービス提供状態切り換え手段と、
前記サービスを受けようとしているモバイルノードを識別する識別手段と、
前記特定のサービスの提供を行わない状態の場合に、前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有するオーバレイネットワークノード。
【請求項８】
前記サービス提供状態切り換え手段で前記状態の切り換えが行われる場合に、前記状態の切り換えに応じて、前記オーバレイネットワークで共有されている前記サービスをサポートしているオーバレイネットワークノードのリストのアップデートを行うリストアップデート手段を有する請求項７に記載のオーバレイネットワークノード。
【請求項９】
前記リストアップデート手段が、前記状態の切り換えに応じて、前記リストにおける当該オーバレイネットワークノードの追加又は削除を示すアップデートメッセージを送信するように構成されている請求項８に記載のオーバレイネットワークノード。
【請求項１０】
前記モバイルノードが前記サービスを適切に受けられるか否かを判断するサービス判断手段と、
前記サービス判断手段において前記サービスを適切に受けられないと判断された場合に、前記モバイルノードが前記サービスを適切に受けられない旨を示す通知メッセージを生成する通知メッセージ生成手段と、
前記通知メッセージを前記モバイルノードに送信する通知メッセージ送信手段とを、
有する請求項１に記載のオーバレイネットワークノード。
【請求項１１】
前記通知メッセージ生成手段が、前記モバイルノードが前記サービスを適切に受けられるようにするための情報を前記通知メッセージに挿入するように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項１２】
ネットワークに接続し、前記ネットワークの上位に形成されているオーバレイネットワークが提供する特定のオーバレイネットワークサービスに係る機能を利用した通信を行うモバイルノードであって、
前記ネットワークに対して、前記特定のオーバレイネットワークサービスに係る機能の利用をリクエストするサービスリクエスト手段と、
前記オーバレイネットワークサービスを適切に受けられない旨を示す通知メッセージを前記ネットワークから受信する通知メッセージ受信手段と、
前記通知メッセージを受信した場合に、前記オーバレイネットワークサービスを受ける方法を変更するサービス利用変更手段とを、
有するモバイルノード。
【請求項１３】
前記ネットワークに接続するための複数のインタフェースを有し、前記サービス利用変更手段が、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている請求項１２に記載のモバイルノード。
【請求項１４】
前記オーバレイネットワークサービスを適切に受けられるようにするための情報としてインタフェースタイプ情報が前記通知メッセージに含まれており、前記サービス利用変更手段が、前記インタフェースタイプ情報に基づいて、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている請求項１３に記載のモバイルノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol：インターネットプロトコル）ネットワークなどのパケット交換型データ通信ネットワークを抽象化するオーバレイネットワーク（overlay network）のノードとして機能するオーバレイネットワークノード及びモバイルノードに関する。
【背景技術】
【０００２】
現在、ユーザにとって、移動しながらインターネットへの接続性を維持できることが重要な要件となってきている。特に、ユーザがどのような場所に移動しても、常にインターネットに接続できる状態が求められている。ユーザがネットワーク間を移動する際にはＩＰアドレスを変更しなければならないが、このアドレス変更に係る課題は、モバイルＩＰの導入によって解決されている。【０００３】
また、ＩＥＴＦ（Internet Engineering Task Force）のＭｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）ワーキンググループでは、マルチインタフェースのモバイルノードに対して、そのマルチモードの特性を十分に活用できるような機能を提供するための議論が進められている。【０００４】
マルチインタフェースのモバイルノードは、そのインタフェースで取得した複数の気付アドレスをホームエージェントに登録することが可能である。複数の気付アドレス登録によって、ホームエージェントは、モバイルノードが複数のルートを経由して到達可能であることを把握できるようになる。【０００５】
この技術を実現することによって、モバイルノードは、データパケットを受信したい場所を指定することができるようになる。また、データパケットのストリーム（フローと呼ばれる）に関して、送信すべきあて先となる気付アドレスを指定したルールを定めることも可能である。【０００６】
また、ＩＥＴＦでは並行して、モバイルＩＰを使用したモバイルノードの移動に伴って、データパケットの伝送経路を最適化する手法を提供するための議論も進められている。なお、この最適化とは、様々なレベルや様々な形式に従って行われるものであり、例えば、送信者と受信者との間のエンドトゥーエンドの最適化に関しては、モバイルＩＰの基本的な標準規格において既に議論されている。一方、例えば、モバイルルータ又はモバイルノードとホームエージェントとの間の最適化に関しては、ＩＥＴＦの様々なワーキンググループにおいて議論が進められている。【０００７】
また、下記の非特許文献１には、オーバレイネットワーク内で行われる最適化に関する手法（グローバルＨＡＨＡと呼ばれる技術）が提案されている。非特許文献１で提案されている手法では、地理的に分散して配置されている協働ルータのネットワークを使用して、エンドユーザに透過（transparent）な経路最適化が実現される。【０００８】
まず、ユーザのモバイルノードが、ホームエージェントにバインディング情報の登録を行う。そして、ホームエージェントは、地理的に分散して配置されたオーバレイネットワーク内の他のホームエージェントに対して、このバインディング情報を配信し、その結果、他のホームエージェントもモバイルノードのプロキシホームエージェントとして機能できるようになる。【０００９】
モバイルノードから送受信されるデータパケットは、送信元ノードに最も近いプロキシホームエージェントによって受信（intercept）され、カプセル化又はデカプセル化された後、あて先ノードに最も近い別のプロキシホームエージェントにトンネルされる。このように、送信元ノードからオリジナルのホームエージェント（モバイルノードがバインディング情報の登録を行ったホームエージェント）を経由してあて先ノードに届く経路とは対照的に、送信元ノードとあて先ノードとの間において、データパケットのパスは最適化される。【００１０】
また、下記の特許文献１には、ホームエージェント、ホームエージェントのコントローラ及びバックアップ装置によって構成されたシステムにおいて、すべてのコントローラやバックアップ装置（バックアップのホームエージェント）に対して、ホームエージェントが有する情報がマルチキャスティングされることによって、バックアップのホームエージェントに動作をシームレスに切り換えられるようにする技術が開示されている。【００１１】
また、下記の特許文献２には、仮想ホームエージェントアドレスが使用されて、クライアントが透過的（トランスペアレント）に複数のホームエージェントに登録される方法について記載されている。ここでは、ホームエージェント間で“ハートビート”メッセージのシステムを利用して情報の同期処理が行われたり、マルチキャスト情報の同期処理が行われたりする。
【特許文献１】米国特許第７０８０１５１号
【特許文献２】米国特許第６４３０６９８号
【非特許文献１】P. Thubert, et al., "Global HA to HA protocol", Internet Engineering Task Force Internet Draft: draft-thubert-nemo-global-haha-01.txt, Work-In-Progress, 15 Oct 2005.
【００１２】
しかしながら、オーバレイネットワークの範囲には限度があり、例えば国境や大陸を越えるようなオーバレイネットワークが必要とされる範囲及びスケールでは、実際には、多数のサービスプロバイダが協力してオーバレイネットワークを実現することになると考えられる。【００１３】
一方、各地の各プロバイダはそれぞれ異なるため、オーバレイネットワークを形成するオーバレイネットワークノードは、それぞれの機能が一致していないことが予想される。例えば、プロトコルが十分に確立されていない場合や、プロトコルを使用した場合のライセンスに要する費用などを始めとする様々な理由によって、特定のプロトコル（例えば、Ｍｏｎａｍｉ６プロトコルスタック）を実装しないように選択するサービスプロバイダが現れる可能性もある。【００１４】
オーバレイネットワークにＭｏｎａｍｉ６機能を有さないレガシのホームエージェントが混在している場合には、このＭｏｎａｍｉ６機能のサービスを受けようとしているサービス加入者が、複数のインタフェースを有するノードの動作に対して、その対価を支払う際に問題が生じる。このような状況では、レガシのホームエージェントを通るデータストリームは、ユーザの好みに応じたフィルタリングを受けられず、レガシのホームエージェントにインストールされている既存エントリによって適当に処理されてしまうことになる。すなわち、Ｍｏｎａｍｉ６機能のサービスを受けようとしているサービス加入者に対して、Ｍｏｎａｍｉ６機能のサービスが十分に提供されないという問題が生じる。現在、オーバレイネットワークを最適化する動作に関して様々な手法が存在しているが、上述のような異なる機能を有するオーバレイネットワークノードが混在する状況において生じる問題の解決方法は存在していない。【００１５】
また、特許文献１に開示されている技術は、オーバレイネットワークの動作にとっては有益であるが、加入者に対するサービスの保証を維持する間は、異なる能力を有するホームエージェントを動作させることはできないという問題がある。【００１６】
また、特許文献２に開示されている技術においても、ホームエージェント間で、サポートされているプロトコルにおける機能が異なる場合における明確な解決方法が存在していないという問題がある。
【発明の開示】
【００１７】
上記の問題を解決するため、本発明は、例えば、異なるインターネットサービスプロバイダが協働してオーバレイネットワークを形成する場合のように、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切に提供することを可能にするオーバレイネットワークノード及びモバイルノードを提供することを目的とする。
【００１８】
上記の目的を達成するため、本発明のオーバレイネットワークノードは、所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
当該オーバレイネットワークノードがサポートしていないサービスを受けようとしているモバイルノードを識別する識別手段と、
前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有する。
この構成により、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切にモバイルノードに提供することが可能となる。
【００１９】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記モバイルノードが受けようとしている前記サービスが、複数の気付アドレスの登録、フローフィルタリングルールの登録、Ｍｏｎａｍｉ６プロトコルに基づく動作のいずれかである。
この構成により、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、複数の気付アドレスの登録、フローフィルタリングルールの登録、Ｍｏｎａｍｉ６プロトコルに基づく動作などの各サービスを適切にモバイルノードに提供することが可能となる。
【００２０】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードに関して、前記サービスを受けようとしていることを示す情報と、前記特定のオーバレイネットワークノードの識別情報とを関連付けて記憶する情報記憶手段を有する。
この構成により、オーバレイネットワークノードは、モバイルノードを確実に特定して、特定のオーバレイネットワークノードに対して、モバイルノードへのサービスの提供を依頼することが可能となる。
【００２１】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードから前記サービスのリクエストを直接受信した場合に、前記転送手段が、前記特定のオーバレイネットワークノードに前記リクエストを転送するように構成されている。
この構成により、モバイルノードから受信したサービスのリクエストを、そのサービスを提供することが可能な特定のオーバレイネットワークノードに確実に渡すことが可能となる。
【００２２】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットが、前記サービスをサポートしている任意のオーバレイネットワークノードで処理されたか否かを判断する処理判断手段を有し、
前記転送手段は、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されている場合には、前記データパケットを前記モバイルノードに転送する一方、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されていない場合には、前記データパケットを前記特定のオーバレイネットワークノードに転送するように構成されている。
この構成により、モバイルノードあてのデータパケットに対して、モバイルノードが受けようとしているサービスがまだ提供されていない場合には、そのサービスを提供することが可能な特定のオーバレイネットワークノードに、そのデータパケットを確実に渡すことが可能となる。
【００２３】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットに関するフローフィルタリングルールが存在しているか否かを確認するルールチェック手段を有し、
前記データパケットに関するフローフィルタリングルールが存在している場合には、前記転送手段が、前記フローフィルタリングルールに基づく前記データパケットの転送を行うように構成されている。
この構成により、転送すべきパケットに関して、当該オーバレイネットワークノードがフローフィルタリングルールに基づくパケット転送を行うことで、サービスをサポートしている特定のオーバレイネットワークノードへのパケット転送が行われず、ネットワークのリソースを節約することが可能となる。
【００２４】
また、上記の目的を達成するため、本発明のオーバレイネットワークは、所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
特定のサービスを提供するサービス提供手段と、
前記特定のサービスの提供を行う状態と、前記特定のサービスの提供を行わない状態とを切り換えるサービス提供状態切り換え手段と、
前記サービスを受けようとしているモバイルノードを識別する識別手段と、
前記特定のサービスの提供を行わない状態の場合に、前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有する。
この構成により、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切にモバイルノードに提供することが可能となる。また、特に、何らかのポリシに基づいて、当該オーバレイネットワークノードが特定のサービスを提供するか否かを切り換えることが可能であり、上記の構成によって、当該オーバレイネットワークノードが特定のサービスを提供していない場合であっても、モバイルノードが受けようとしている特定のサービスが適切にモバイルノードに提供されるようになる。
【００２５】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービス提供状態切り換え手段で前記状態の切り換えが行われる場合に、前記状態の切り換えに応じて、前記オーバレイネットワークで共有されている前記サービスをサポートしているオーバレイネットワークノードのリストのアップデートを行うリストアップデート手段を有する。
この構成により、オーバレイネットワークにおいて集中管理又は分散管理されている、サービスをサポートしているオーバレイネットワークノードのリストにおいて、当該オーバレイネットワークにおけるサービスの提供状態を示すことが可能となる。
【００２６】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記リストアップデート手段が、前記状態の切り換えに応じて、前記リストにおける当該オーバレイネットワークノードの追加又は削除を示すアップデートメッセージを送信するように構成されている。
この構成により、当該オーバレイネットワークがサービスの提供状態を切り換える場合にアップデートメッセージを送信することによって、リストのアップデートが行われるようになる。
【００２７】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記モバイルノードが前記サービスを適切に受けられるか否かを判断するサービス判断手段と、
前記サービス判断手段において前記サービスを適切に受けられないと判断された場合に、前記モバイルノードが前記サービスを適切に受けられない旨を示す通知メッセージを生成する通知メッセージ生成手段と、
前記通知メッセージを前記モバイルノードに送信する通知メッセージ送信手段とを、
有する。
この構成により、モバイルノードが特定のサービスを適切に受けられない状態が、モバイルノードに通知されるようになる。
【００２８】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記通知メッセージ生成手段が、前記モバイルノードが前記サービスを適切に受けられるようにするための情報を前記通知メッセージに挿入するように構成されている。
この構成により、より適切にサービスを受けるための情報が、モバイルノードに通知されるようになる。
【００２９】
また、上記の目的を達成するため、本発明のモバイルノードは、ネットワークに接続し、前記ネットワークの上位に形成されているオーバレイネットワークが提供する特定のオーバレイネットワークサービスに係る機能を利用した通信を行うモバイルノードであって、
前記ネットワークに対して、前記特定のオーバレイネットワークサービスに係る機能の利用をリクエストするサービスリクエスト手段と、
前記オーバレイネットワークサービスを適切に受けられない旨を示す通知メッセージを前記ネットワークから受信する通知メッセージ受信手段と、
前記通知メッセージを受信した場合に、前記オーバレイネットワークサービスを受ける方法を変更するサービス利用変更手段とを、
有する。
この構成により、モバイルノードが特定のサービスを適切に受けられない状態がモバイルノードに通知され、モバイルノードは、サービスを受ける方法を変更することが可能となる。
【００３０】
さらに、本発明のモバイルノードは、上記の構成に加えて、前記ネットワークに接続するための複数のインタフェースを有し、前記サービス利用変更手段が、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている。
この構成により、モバイルノードは、サービスをより適切に受けることができるように、サービスを受けるインタフェースを切り換えることが可能となる。
【００３１】
さらに、本発明のモバイルノードは、上記の構成に加えて、前記オーバレイネットワークサービスを適切に受けられるようにするための情報としてインタフェースタイプ情報が前記通知メッセージに含まれており、前記サービス利用変更手段が、前記インタフェースタイプ情報に基づいて、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている。
この構成により、より適切にサービスを受けるためのインタフェースタイプ情報が、モバイルノードに通知され、モバイルノードは、このインタフェースタイプ情報に基づいてサービスを受けるインタフェースを切り換えることが可能となる。
【００３２】
本発明は、上記の構成を有しており、例えば、異なるインターネットサービスプロバイダが協働してオーバレイネットワークを形成する場合のように、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切に提供できるようになるという効果を有している。
【図面の簡単な説明】
【００３３】
【図１】本発明の実施の形態におけるネットワーク構成の一例を示す図
【図２】本発明の実施の形態におけるＭＳＨＡが保持するバインディングキャッシュエントリに追加される情報要素の一例を示す図
【図３】本発明の実施の形態におけるＭＳＨＡに必要な機能を実現するための構成の一例を示すブロック図
【図４】本発明の実施の形態におけるＭＳＨＡに必要な機能を実現するための構成の別の一例を示すブロック図
【図５】本発明の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャート
【図６】本発明の別の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャート
【図７】本発明のさらに別の実施の形態におけるＭＳＨＡに必要な機能を実現するための構成の別の一例を示すブロック図
【図８】本発明のさらに別の実施の形態におけるＭＳＨＡから送信されるアップデートメッセージに含まれる情報要素の一例を示す図
【図９】本発明のさらに異なる実施の形態におけるＭＳＨＡから送信される通知メッセージに含まれる情報要素の一例を示す図
【図１０】本発明のさらに異なる実施の形態におけるＭＳＨＡの動作の一例を示すフローチャート
【図１１】本発明のさらに異なる実施の形態におけるＭＮの拡張機能を模式的に示す図
【発明を実施するための最良の形態】
【００３４】
以下、図面を参照しながら、本発明の実施の形態について説明する。【００３５】
本発明によれば、サービスプロバイダが、完全なＭｏｎａｍｉ６プロトコルの実装は行わない一方、Ｍｏｎａｍｉ６機能をサポートするオーバレイネットワークに参加して相互動作が可能となるように、Ｍｏｎａｍｉ６はサポートしているものの、Ｍｏｎａｍｉ６機能が完全には実装されていない拡張ホームエージェントが提供される。【００３６】
まず、図１を参照しながら、本発明が前提とするオーバレイネットワークの構成の一例について説明する。図１に図示されているネットワーク構成において、モバイルノード１１０は、オーバレイネットワークサービスに加入している。また、オーバレイネットワークは、複数のホームエージェント（ＭＣＨＡ１２０、１３０、１４０、ＭＳＨＡ１５０、１６０）により構成されている。【００３７】
ＭＣＨＡ（Monami6-Capable Home Agent：Ｍｏｎａｍｉ６実装ホームエージェントと記載する）は、オーバレイネットワーク最適化機能に加えて、複数の気付アドレスの登録機能やデータフローのフィルタリング機能などを含む完全なＭｏｎａｍｉ６プロトコルスタックを実装しているホームエージェントである。【００３８】
一方、ＭＳＨＡ（Monami6-Support Home Agent：Ｍｏｎａｍｉ６サポートホームエージェントと記載する）は、オーバレイネットワーク最適化機能のみを実装しているが、本発明に係る解決方法を使用して、Ｍｏｎａｍｉ６の動作をサポートすることが可能なホームエージェントである。【００３９】
図１では、モバイルノード１１０は、３つのコレスポンデントノードＣＮ１７０、１８０、１９０からデータストリームを受信しているとする。モバイルノード１１０は、Ｍｏｎａｍｉ６プロトコルスタックを用いて、パス１１１、１１２を使用するインタフェースを登録することが可能である。さらに、モバイルノード１１０は、ＣＮ１７０、１８０、１９０からのデータストリームの転送方法を指定することが可能である。【００４０】
従来の技術において、例えば、図１に図示されているＭＳＨＡ１５０、１６０がレガシのホームエージェントの場合（すなわち、ＭＳＨＡ１５０、１６０の設置箇所に、Ｍｏｎａｍｉ６をまったく理解できないホームエージェントが存在している場合）、これらのレガシのホームエージェントは、複数の気付アドレスの登録を行うことができないので、モバイルノード１１０に関する複数エントリを有するバインディングキャッシュを構成することはできない。【００４１】
例えば、これらのレガシのホームエージェントは、オーバレイネットワークで通知されるアップデートに複数の気付アドレスが含まれている場合でも、通常のモバイルＩＰにおける動作を行って、単に、その最初のオプションに含まれる値をモバイルノード１１０の現在の気付アドレスとして登録する可能性がある。【００４２】
さらに、レガシのホームエージェントは、別のパスを使用してモバイルノード１１０にパケットを発送するということが分からないため、モバイルノード１１０からのフローフィルタリングルールを理解できなかったり、モバイルノード１１０からのフローフィルタリングルールに基づいて動作できなかったりする。【００４３】
例えば、ＭＳＨＡ１５０がレガシのホームエージェントの機能しかもっておらず、ＣＮ１９０からのデータストリームがこのレガシのホームエージェントを経由する場合には、たとえこのデータストリームをパス１１１経由で受信するようにＭＮ１１０がフローフィルタリングルールを設定したとしても、このレガシのホームエージェントは、単にデータストリームを最短パス１１２経由で送信し、ＭＮ１１０によって定義されたフローフィルタリングルールは無視されることになる。【００４４】
一方、本発明によれば、オーバレイネットワーク内に存在し得るＭＣＨＡ以外のホームエージェント（従来の技術におけるレガシのホームエージェント）は、少なくともＭｏｎａｍｉ６機能を理解することができるＭＳＨＡであり、Ｍｏｎａｍｉ６機能に係るサービス（Ｍｏｎａｍｉ６サービス）に登録しているモバイルノードあてのパケットを正しく取り扱うことができるようになる。【００４５】
例えば、ＭＳＨＡは、複数の気付アドレスの登録は行わないものの、Ｍｏｎａｍｉ６サービスをリクエストしているモバイルノードに関しては、そのバインディングキャッシュエントリの追加フィールドに目印を付け、このモバイルノードあてのデータパケットを適切なＭＣＨＡに渡すことによって、ＭＣＨＡで更なる処理（Ｍｏｎａｍｉ６機能に係る正常な処理）が行われるようにする。なお、ＭＳＨＡは、ＭＣＨＡから発送されたり転送されたりしていないパケット（ＭＣＨＡで処理されていないパケット）に関して、モバイルノードあてのすべてのパケットに対して上記の処理を行うことが望ましい。【００４６】
例えば、図１に図示されているネットワーク構成において、ＭＳＨＡ１５０が、Ｍｏｎａｍｉ６のバインディングアップデートメッセージをＭＮ１１０からパス１１２経由で受信したとする。この場合、ＭＳＨＡ１５０は、まず、モバイルＩＰｖ６（ＭＩＰｖ６）に従ってバインディングキャッシュのアップデートを行い、その後、Ｍｏｎａｍｉ６サービスをリクエストしているＭＮ１１０を識別するフラグをバインディングキャッシュエントリに追加する必要がある。さらに、ＭＮ１１０に対して機能するＭＣＨＡ（すなわち、Ｍｏｎａｍｉ６に係るパケット処理を担うＭＣＨＡ）も記載されることが望ましい。なお、ＭＣＨＡの候補は、各バインディングキャッシュエントリで同一であってもよく、あるいは異なるものであってもよい。また、ＭＣＨＡの候補は、各バインディングキャッシュエントリに静的に割り当てられてもよく、あるいは動的に割り当てられてもよい。さらには、ＭＣＨＡの候補は、例えば、パケットの転送パスが最短となるものが選択されてもよく、その他の任意のポリシに基づいて設定されてもよい。【００４７】
図２には、ＭＳＨＡにおいて、バインディングキャッシュエントリに追加される情報要素が図示されている。本発明では、例えば、Ｍｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０がバインディングキャッシュエントリに追加される。Ｍｏｎａｍｉ６フラグフィールド２００には、このバインディングキャッシュエントリに関連したモバイルノードがＭｏｎａｍｉ６サービスをリクエストしているか否かを示す値が設定される。また、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０には、このバインディングキャッシュエントリに関連したモバイルノードに関するパケットの転送先となるＭＣＨＡの識別情報が設定される。【００４８】
例えば、ＭＳＨＡ１５０がＭｏｎａｍｉ６のバインディングアップデートメッセージをＭＮ１１０からパス１１２経由で受信した場合、ＭＳＨＡ１５０は、バインディングキャッシュをアップデートした後に、ＭＮ１１０に関するバインディングキャッシュエントリのターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡ（例えば、ＭＣＨＡ１３０）に、バインディングアップデートメッセージ全体を転送する。したがって、ＭＳＨＡ１５０は、パス１０５経由でバインディングアップデートをＭＣＨＡ１３０に転送し、ＭＣＨＡ１３０で更なる処理が行われる。【００４９】
ＭＣＨＡ１３０は、ＭＮ１１０のバインディングアップデートメッセージを受信すると、ＭＩＰｖ６、Ｍｏｎａｍｉ６、オーバレイネットワークプロトコルなどの各機能に関する通常の動作を実行する。【００５０】
また、ＭＳＨＡ１６０も、ＭＮ１１０で生成されたＭｏｎａｍｉ６のバインディングアップデートメッセージをオーバレイネットワークを経由して受信する。なお、このとき、オーバレイネットワークのプロトコルに適した形式にフォーマットが変更されていてもよい。【００５１】
このように、ＭＮ１１０のバインディングアップデートメッセージは、オーバレイネットワークに属するホームエージェントに分配される必要があるが、ＭＳＨＡ１６０は、このバインディングアップデートメッセージが、Ｍｏｎａｍｉ６実装オーバレイネットワークノードによって既に処理済であると認識できることが望ましい。【００５２】
ＭＳＨＡ１６０は、例えば、ＭＳＨＡ１５０と同様にバインディングキャッシュのアップデートを行うが、ＭＳＨＡ１６０は、ＭＮ１１０のフローを処理するターゲットＭｏｎａｍｉ６実装ホームエージェントとして、ＭＣＨＡ１４０をセットする。すなわち、ＭＳＨＡ１６０は、ＭＮ１１０に関するバインディングキャッシュエントリにおいて、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０にＭＣＨＡ１４０を記載するアップデートを行う。さらに、ＭＳＨＡ１６０は、別のプロトコルによる要請がない限り、バインディングアップデートメッセージをＭＣＨＡ１４０に再転送しないようにする。これによって、ＭＳＨＡからＭＣＨＡに転送されたバインディングアップデートメッセージが、ＭＣＨＡによって冗長な処理となることを防ぐことが可能となる。【００５３】
つまり、ＭＮから直接受信したバインディングアップデートメッセージの場合は、ターゲットＭｏｎａｍｉ６実装ホームエージェントにより正しく解釈される必要があるが、オーバレイネットワークを経由して受信したバインディングアップデートメッセージの場合は、既にＭｏｎａｍｉ６実装ホームエージェントにより適切に解釈されているとみなせるのでターゲットＭｏｎａｍｉ６実装ホームエージェントにより再解釈される必要はない。それゆえ、ＭＳＨＡは、オーバレイネットワークを経由して受信したバインディングアップデートメッセージは、ＭＣＨＡに転送する必要はない。【００５４】
ＭＮ１１０あてのパケットがＣＮ１７０からパス１７１を経由してＭＳＨＡ１６０に到達した場合には、ＭＳＨＡ１６０は、そのバインディングキャッシュを調べ、ＭＮ１１０に関連するエントリを参照する。ＭＳＨＡ１６０は、ＭＮ１１０がＭｏｎａｍｉ６サービスをリクエストしていることを把握すると、ＭＮ１１０のバインディングキャッシュエントリに存在するターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡ１４０に対して、パケットを転送する。【００５５】
ＭＣＨＡ１４０は、ＣＮ１７０からＭＮ１１０へのパケットを受信すると、ＭＮ１１０が規定したフローフィルタリングルールに基づくあて先にパケットを転送する。すなわち、ＣＮ１７０からＭＮ１１０へのパケットは、フローフィルタリングルールに基づく処理を実行できないＭＳＨＡ１６０から、フローフィルタリングルールに基づく処理を実行できるＭＣＨＡ１４０に転送された後、ＭＣＨＡ１４０でフローフィルタリングルールが適用される。【００５６】
また、ＭＮ１１０あてのパケットがＣＮ１８０からパス１８１を経由してＭＣＨＡ１３０に到達した場合には、ＭＣＨＡ１３０は、ＭＮ１１０によって構成されたフローフィルタリングルールを使用して、パケットをそのあて先に転送する。例えば、ＣＮ１８０からのパケットはパス１１２を経由して伝送されるようにＭＮ１１０がリクエストしている場合には、ＭＣＨＡ１３０はＭＳＨＡ１５０にパケットをトンネルする。【００５７】
ＭＳＨＡ１５０は、パケットのデカプセル化の際に、そのパケットのあて先が、Ｍｏｎａｍｉ６サービスをリクエストしているＭＮ１１０であることに気付く。しかしながら、オリジナルのパケットはＭｏｎａｍｉ６実装ノード（ＭＣＨＡ１３０）からトンネルされてきているので、ＭＣＨＡ１３０で既にフローフィルタリングルールに基づく処理が実行されており、ＭＳＨＡ１５０は、通常通り、パス１１２経由でＭＮ１１０にパケットを転送する。なお、ここでは、トンネルパケットの送信元とターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されている特定のホームエージェント（ＭＣＨＡ１３０）とは同一であるが、必ずしも同一である必要はなく、トンネルの送信元はＭｏｎａｍｉ６実装ノードであればよい。【００５８】
また、ＭＮ１１０あてのパケットがＣＮ１９０からパス１９１を経由してＭＳＨＡ１５０に到達した場合には、ＭＳＨＡ１５０は、そのバインディングキャッシュを調べ、ＭＮ１１０に関連するエントリを参照する。ＭＳＨＡ１５０は、ＭＮ１１０がＭｏｎａｍｉ６サービスをリクエストしていることを把握すると、ＭＮ１１０のバインディングキャッシュエントリに存在するターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡ１３０に対して、パケットを転送する。【００５９】
ＭＣＨＡ１３０は、ＣＮ１９０からＭＮ１１０へのパケットを受信すると、ＭＮ１１０が設定したフローフィルタリングルールを適用して、正しいあて先にパケットを転送する。ここで、ＭＮ１１０がＣＮ１９０からのパケットをパス１１２経由で送信されるように転送し、ＭＣＨＡ１３０がＭＳＨＡ１５０にパケットをトンネルする場合を考える。【００６０】
ＭＳＨＡ１５０は、パケットのデカプセル化の際に、パケットのあて先が、Ｍｏｎａｍｉ６サービスをリクエストしているＭＮ１１０であることを把握する。しかしながら、オリジナルのパケットはＭｏｎａｍｉ６実装ノード（ＭＣＨＡ１３０）からトンネルされてきているので、ＭＳＨＡ１５０は、通常通り、パス１１２経由でＭＮ１１０にパケットを転送する。【００６１】
また、図３には、本発明の実施の形態におけるＭＳＨＡ１５０に必要な機能を実現するための構成の一例が図示されている。図３に図示されているＭＳＨＡ１５０は、下位レイヤインタフェース３００、サポートマネージャ３１０、オーバレイネットワークプロトコル処理部３２０、モバイルＩＰｖ６処理部３３０、情報サービス３４０を有している。【００６２】
下位レイヤインタフェース３００は、物理的なネットワークアクセスハードウェアやドライバ、ソフトウェアＡＰＩ（Application Programming Interface：アプリケーションプログラミングインタフェース）を有している。なお、下位レイヤインタフェース３００は、オーバレイネットワークプロトコル処理部３２０やモバイルＩＰｖ６処理部３３０で処理されるすべてのパケットを、パス３０１を通じてサポートマネージャ３１０に渡す。【００６３】
サポートマネージャ３１０は、本発明において要求される動作を実行する。サポートマネージャ３１０は、モバイルＩＰｖ６のバインディングアップデートメッセージを受信すると、そのメッセージを調べて、Ｍｏｎａｍｉ６機能に関する要素が含まれているか否かを判断する。Ｍｏｎａｍｉ６機能に関する要素が含まれている場合には、サポートマネージャ３１０は、例えば複数の気付アドレスやフローフィルタリングルールなどの関連情報を抽出してから、パス３１３を通じてモバイルＩＰｖ６処理部３３０にメッセージを渡し、モバイルＩＰｖ６処理部３３０で通常の処理が行われる。【００６４】
また、サポートマネージャ３１０は抽出された情報を使用して、関連するバインディングキャッシュエントリのＭｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０をアップデートする。このバインディングキャッシュエントリは、モバイルＩＰｖ６処理部３３０と共有されてもよいが、モバイルＩＰｖ６の動作に関してデータ同期が行われ、データ損失や不正を防ぐようにする必要がある。【００６５】
また、サポートマネージャ３１０は、パス３１２を経由して情報サービス３４０に対して問い合わせを行う。例えば、サポートマネージャ３１０は、ターゲットＭｏｎａｍｉ６実装ホームエージェントを選択する際に、情報サービス３４０に問い合わせを行う。また、モバイルノードから受信したバインディングアップデートメッセージは、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されるＭＣＨＡに送信される必要がある。なお、オーバレイネットワークプロトコル処理部３２０において、このバインディングアップデートに含まれる情報に関するアップデートが行われない場合には、ＭＳＨＡは、関連するプロトコルスタックにメッセージを渡し、その関連するプロトコルスタックにおいて通常通りの処理が行われる。【００６６】
また、情報サービス３４０は、本発明において必要となる情報を始めとして、様々な情報を提供することが可能なエンティティである。なお、情報サービス３４０は、図３に図示されているようにＭＳＨＡ１５０内に配置されていてもよく、また、離れた場所に配置されていてもよい。【００６７】
サポートマネージャ３１０は、モバイルノードあてのデータパケットを受信すると、パケットがＭＣＨＡから送信又はトンネルされたものであるか否かをチェックする。パケットがＭＣＨＡから送信又はトンネルされたものである場合には、サポートマネージャ３１０は、関連するプロトコルスタックにパケットを渡す。例えば、パケットは、パス３１１を経由してオーバレイネットワークプロトコル処理部３２０に渡されるか、あるいはパス３１３を経由してモバイルＩＰｖ６処理部３３０に渡され、通常の処理が行われる。【００６８】
一方、パケット送信者又はトンネルの送信元がＭＣＨＡではない場合には、サポートマネージャ３１０はバインディングキャッシュをチェック（例えば、Ｍｏｎａｍｉ６フラグフィールド２００の値をチェック）して、モバイルノード（パケットのあて先）がＭｏｎａｍｉ６サービスをリクエストしているか否かを判断する必要がある。このモバイルノードがＭｏｎａｍｉ６サービスをリクエストしている場合には、サポートマネージャ３１０は、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡに対して、パケットを転送する必要がある。【００６９】
一方、モバイルノードがＭｏｎａｍｉ６サービスをリクエストしていない場合には、サポートマネージャ３１０は、関連するプロトコルスタックにパケットを渡して、通常の処理が行われる。なお、パケット発信者又はトンネルの送信元がＭＣＨＡか否かに関する情報は、パス３１２を通じて情報サービス３４０に問い合わせを行ってもよい。【００７０】
また、図４には、本発明の実施の形態におけるＭＳＨＡ１５０に必要な機能を実現するための構成の別の一例が図示されている。図４に図示されている構成では、サポートマネージャ３１０は、オーバレイネットワークプロトコル処理部３２０とモバイルＩＰｖ６処理部３３０の両方のプロトコルの上位に位置している。なお、機能に関しては上述のものと同様であるが、サポートマネージャ３１０は、本発明に係る特有のメッセージを受信できるようにするため、オーバレイネットワークプロトコル処理部３２０及びモバイルＩＰｖ６処理部３３０に対して登録を行っておく必要がある。【００７１】
なお、サポートマネージャ３１０、オーバレイネットワークプロトコル処理部３２０、モバイルＩＰｖ６処理部３３０の配置は任意であってよい。すなわち、例えば、サポートマネージャ３１０が、モバイルＩＰｖ６処理部３３０の上位であって、かつオーバレイネットワークプロトコル３２０の下位に位置してもよく、また、その逆でもよい。【００７２】
また、図５には、本発明の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャートが図示されている。図５において、ＭＳＨＡはパケットを受信すると、まず、メッセージのパケットのタイプを判断する（ステップＳ５００）。なお、ここでは、受信パケットがモバイルノードからのバインディングアップデートの場合（遷移Ｔ５０５）、受信パケットがモバイルノードあてのデータパケットの場合（遷移Ｔ５０６）、受信パケットがその他のタイプのパケットの場合（遷移Ｔ５０７）について説明する。【００７３】
受信したメッセージがモバイルノードからのバインディングアップデートの場合（遷移Ｔ５０５、ステップＳ５１０）には、ＭＳＨＡは、そのモバイルノードがＭｏｎａｍｉ６機能をリクエストしているか否かをチェックする（ステップＳ５２０）。なお、このチェックは、モバイルノードや情報サービス３４０、あるいはその他のＭＣＨＡなどに問い合わせるなど、任意の方法で実現可能である。【００７４】
ステップＳ５２０でモバイルノードがＭｏｎａｍｉ６機能をリクエストしている場合には、ＭＳＨＡは、Ｍｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェント２１０の設定を行って、そのモバイルノードのバインディングキャッシュエントリのアップデートを行う（ステップＳ５３０）。そして、ＭＳＨＡは、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されるＭＣＨＡに対して、このメッセージのパケットを転送する処理を行う（ステップＳ５５０）。【００７５】
一方、ステップＳ５２０でモバイルノードがＭｏｎａｍｉ６機能をリクエストしていない場合には、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なる処理が行われる（ステップＳ５４０）。【００７６】
また、ＭＳＨＡがモバイルノードあてのデータパケットを受信した場合（遷移Ｔ５０６、ステップＳ５６０）には、まずＭＳＨＡは、パケット発信者又はトンネルの送信元がＭＣＨＡか否かをチェックする（ステップＳ５７０）。ステップＳ５７０でパケット発信者又はトンネルの送信元がＭＣＨＡの場合には、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なるパケット処理が行われる（ステップＳ５４０）。【００７７】
しかしながら、ステップＳ５７０でパケット発信者又はトンネルの送信元がＭＣＨＡではない場合には、ＭＳＨＡは、そのモバイルノードのバインディングキャッシュエントリをチェックし、モバイルノードがＭｏｎａｍｉ６機能をリクエストしているか否かを判断する（ステップＳ５８０）。モバイルノードがＭｏｎａｍｉ６機能をリクエストしている旨がＭｏｎａｍｉ６フラグフィールド２００にセットされている場合には、ＭＳＨＡは、バインディングキャッシュエントリのターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡに、このパケットを転送する（ステップＳ５９０）。【００７８】
一方、Ｍｏｎａｍｉ６フィールド２００がセットされていない場合（すなわち、モバイルノードがＭｏｎａｍｉ６機能をリクエストしていない場合）には、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なるパケット処理が行われる（ステップＳ５４０）。また、ＭＳＨＡが受信したパケットがその他のタイプのパケットである場合においても、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なるパケット処理が行われる（ステップＳ５４０）。【００７９】
なお、上述の実施の形態とは異なる別の好適な実施の形態において、ＭＳＨＡがＭｏｎａｍｉ６プロトコルスタックを実装していないが、フローフィルタリングプロトコルを理解することができる場合も考えられる。このような場合においても、オーバレイネットワークにおける最適化が実現可能である。【００８０】
図６には、本発明の別の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャートが図示されている。なお、図６には、上述のように、フローフィルタリングプロトコルを理解することができるが、Ｍｏｎａｍｉ６プロトコルスタックを実装していないＭＳＨＡの動作の一例が図示されている。以下、図１に図示されているＭＳＨＡ１５０が、図６に係る動作を行うＭＳＨＡである場合を例示しながら説明する。【００８１】
図１に図示されているネットワーク構成において、ＭＮ１１０は、ＣＮ１９０からのデータパケットがパス１１２経由で送信されるように規定するフローフィルタリングルールの動作をリクエストしているとする。ＭＳＨＡ１５０は、ＣＮ１９０からのＭＮ１１０あてのデータパケットを受信した場合（ステップＳ５００、遷移Ｔ５０６、ステップＳ５６０）には、そのデータパケットに一致するフローフィルタリングルールが存在するか否かをチェックする（ステップＳ６００）。【００８２】
ステップＳ６００でフローフィルタリングルールが存在している場合には、ＭＳＨＡ１５０は、関連するプロトコル（この場合は、フローフィルタリングプロトコル）にパケットを渡し、更なる処理が行われる（ステップＳ５４０）。【００８３】
しかしながら、ステップＳ６００で一致するフローフィルタリングルールが見つからなかった場合にはステップＳ５７０に進み、このパケットのパケット送信者又はトンネルの送信元がＭＣＨＡか否かのチェックが行われる。なお、図６に示されているその他の動作は、基本的に図５に示されている動作と同一であり、ここでは説明を省略する。【００８４】
図６に示す動作で追加されたチェックを実行した場合、データパケットがフローフィルタリングに関連している場合には、ＭＳＨＡはこのパケットをＭＣＨＡに転送する必要はないという利点がある。これにより、不要な待ち時間や、帯域幅の無駄な消費が起こらないようにすることが可能となる。【００８５】
さらに別の好適な実施の形態において、ＭＳＨＡ１５０は、図７に図示されているように、Ｍｏｎａｍｉ６プロトコルスタックであるＭｏｎａｍｉ６プロトコル処理部７００を実装している場合も考えられる。なお、図７に図示されている構成では、モバイルＩＰ処理部３３０の上位にＭｏｎａｍｉ６プロトコル処理部７００が配置されているが、どの位置に配置される構成であっても、本発明の基本的な概念は適用される。【００８６】
Ｍｏｎａｍｉ６プロトコル処理部７００が設けられている構成だけでは、Ｍｏｎａｍｉ６機能を実装するＭＣＨＡと同一になると考えられるが、しかしながら、サービスプロバイダが動的にＭｏｎａｍｉ６サービスを有効／無効にするオプションを必要としている場合があり、図７に図示されている構成は、このオプションを実現するために、サポートマネージャ３１０（図３、４を参照）に代わって、スイッチサポートマネージャ７１０が設けられている。このスイッチサポートマネージャ７１０は、サポートマネージャ３１０のすべての機能に加えて、Ｍｏｎａｍｉ６機能の動作の有効／無効の切り換えを行う機能を有している。なお、このＭｏｎａｍｉ６機能の動作の有効／無効の状態は、任意のポリシに基づいて適宜動的に切り換えられてもよい。【００８７】
なお、図７に図示されているＭＳＨＡ１５０は、Ｍｏｎａｍｉ６機能の動作が無効になった場合には、『ＭＳＨＡ』と呼ぶことはできるが、Ｍｏｎａｍｉ６機能の動作が有効になった場合には、Ｍｏｎａｍｉ６を完全に実装した構成（すなわち、ＭＣＨＡ）となり、『ＭＳＨＡ』と呼ぶことはできない。しかしながら、以下では、説明を容易にするため、常にＭｏｎａｍｉ６機能の動作が有効なＭＣＨＡに対して、図７に図示されている構成を有するＨＡをＭＳＨＡと呼ぶことにする。【００８８】
以下、図７に図示されているＭＳＨＡ１５０を含むオーバレイネットワークシステムについて説明する。図７に図示されているＭＳＨＡ１５０が存在するオーバレイネットワークシステムでは、例えば、オーバレイネットワークシステム全体において、ＭＳＨＡ１５０のＭｏｎａｍｉ６機能の動作状態が有効か、あるいは無効かを把握できるようにすればよい。これを実現するためには、Ｍｏｎａｍｉ６機能が現在動作しているオーバレイネットワークノードが記載されたグローバルリストを設ければよい。なお、このグローバルリストは、オーバレイネットワークシステム全体の情報の集中管理を行うセントラル情報サービスで管理されてもよく、あるいは、オーバレイネットワーク内のすべてのノードがそれぞれ管理してもよい。【００８９】
図８には、Ｍｏｎａｍｉ６機能が現在動作しているオーバレイネットワークノードすべてが記載されるグローバルリストをアップデートするために使用されるアップデートメッセージが図示されている。グローバルリストをアップデートするためのアップデートメッセージは、セントラル情報サービスに送信されてもよく、オーバレイネットワーク内のすべてのノードにブロードキャストされてもよい。【００９０】
なお、図８に図示されているアップデートメッセージは一例であって、適用されるシステムや実施条件によって適宜変更可能である。また、このアップデートメッセージは、例えば、モバイルＩＰやＩＣＭＰ（Internet Control and Management Protocol：インターネット制御管理プロトコル）などの既存のプロトコルのメッセージによって統合されるか、あるいは置き換えられてもよい。【００９１】
図８に図示されているアップデートメッセージは、タイプフィールド８００、追加フラグフィールド８１０、ホームエージェント識別子フィールド８２０を有している。【００９２】
図８において、タイプフィールド８００は、このメッセージがアップデートメッセージであることを識別可能とするために使用される。なお、このタイプフィールド８００には、送信者ノード及び受信者ノードの両方によって理解される値が設定される。また、追加フラグフィールド８１０は、このアップデートメッセージの送信者ノードが、グローバルリストに自身をＭＣＨＡとして追加するように、あるいはグローバルリストから削除するようにリクエストしていることを示すために使用される。また、ホームエージェント識別子フィールド８２０には、グローバルリストに追加又はグローバルリストから削除されるべきオーバレイネットワークノード（ＭＳＨＡ１５０自身）を特定するためのホームエージェント識別子やアドレス情報などが含まれる。【００９３】
スイッチサポートマネージャ７１０は、当該ＭＳＨＡ１５０をＭｏｎａｍｉ６有効状態からＭｏｎａｍｉ６無効状態に切り換えるように指示を受けた場合には、Ｍｏｎａｍｉ６機能が現在動作しているオーバレイネットワークノードのグローバルリストから自身を削除するために、まず、グローバルリストからの削除をリクエストするアップデートメッセージの送信を行う。なお、アップデートメッセージの送信によるグローバルリストからの削除は、オーバレイネットワークシステムにおいて迅速かつ確実に行われる。【００９４】
さらに、ＭＳＨＡ１５０では、Ｍｏｎａｍｉ６機能をリクエストしているモバイルノードに関するバインディングキャッシュに含まれるすべてのエントリを検査して、例えばＭｏｎａｍｉ６機能をリクエストしているモバイルノードのパケットを適切なＭＣＨＡに転送できるようにするなど、Ｍｏｎａｍｉ６フラグフィールド２００やターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に適切な値を付与する必要がある。この結果、Ｍｏｎａｍｉ６サービスはシームレスに無効化される。【００９５】
一方、スイッチサポートマネージャ７１０は、当該ＭＳＨＡ１５０をＭｏｎａｍｉ６無効状態からＭｏｎａｍｉ６有効状態に切り換えるように指示を受けた場合には、まず、ホームエージェントに管理されているモバイルノードがＭｏｎａｍｉ６機能をリクエストしているか否かを特定する必要がある。これは、スイッチサポートマネージャ７１０が、Ｍｏｎａｍｉ６フラグフィールド２００がセットされているモバイルノードすべてのバインディングキャッシュエントリを検査することによって実現される。【００９６】
そして、Ｍｏｎａｍｉ６機能をリクエストしているモバイルノードが特定されると、スイッチサポートマネージャ７１０は、これらのモバイルノードの関連するエントリにおいて、例えば、他のＭＣＨＡではなく、当該ＭＳＨＡ１５０自身でパケットの処理を行う旨を記載する。このバインディングキャッシュエントリのアップデートは、通常の周期的なアップデートを待って行われてもよく、情報サービス３４０のエンティティによって行われてもよい。なお、情報サービス３４０のエンティティから取得できる情報は、クエリ／レスポンスのメカニズムによって様々である。そして、すべての関連エントリがアップデートされると、スイッチサポートマネージャ７１０は、図８に図示されているアップデートメッセージをグローバルネットワーク１００に送信し、グローバルリストに自身を追加する。この結果、Ｍｏｎａｍｉ６サービスはシームレスに有効化される。【００９７】
さらに、この切り換えは、当該ＭＳＨＡの管理するすべてのＭＮ登録について一括にＭｏｎａｍｉ６サービスの有効化／無効化を設定するだけでなく、部分的に一部のＭＮ登録に関しては有効、他のＭＮ登録に関しては無効とすることもできる。これは、複数ＣｏＡの登録領域やフローの管理が当該のＭＳＨＡにおいて肥大化したときに、他のＭＣＨＡに対して、処理負荷が多い分だけの管理を依頼する形となるため、受け入れるＭＣＨＡ側において自身の処理負荷が突然処理限界に達してしまうというようなことを避けることができる。【００９８】
上述の本発明の各実施の形態では、ネットワーク上に配置されている装置（主にＭＳＨＡ）に機能が追加されることで本発明の動作が実現されているが、さらにモバイルノードの機能を拡張することによって、本発明の動作がシームレスに行われるようにすることも可能である。【００９９】
図１において、モバイルノードは、複数の気付アドレスを登録するバインディングアップデートメッセージを送信し、このバインディングアップデートメッセージは、ＭＳＨＡによって受信（intercept）される。このとき、ＭＳＨＡは、上述の動作（図５に図示）に加えて、モバイルノードがＭｏｎａｍｉ６のサービスを最適なインタフェースで受けているか否か（例えば、ＭＣＨＡではなくＭＳＨＡに接続しているためにパケットがいったんＭＣＨＡに転送される場合があることなど）を判断し、最適なインタフェースが使用されていない場合には、その旨を通知するための通知メッセージをモバイルノードに送信する付加的な動作を行うことが可能である。【０１００】
また、モバイルノードは、この通知メッセージを受信した際に、この通知メッセージを理解してＭｏｎａｍｉ６のサービスを最適なインタフェースで受けていない旨を把握する拡張機能を有している。モバイルノードは、通知メッセージによってＭｏｎａｍｉ６のサービスを最適なインタフェースで受けていない旨を把握した場合には、別のネットワーク（別のインタフェース）を選択してＭｏｎａｍｉ６のサービスをリクエストしてもよい。なお、このリクエストは、（別のインタフェースから再度送信される）複数の気付アドレスを登録するバインディングアップデートメッセージの送信により行われてもよいし、Ｍｏｎａｍｉ６のサービスを最適な状態で提供してほしい旨のリクエストを明示的に送信してもよい。【０１０１】
なお、ＭＳＨＡは、任意の判断基準を通知メッセージの送信トリガとすることが可能であり、また、通知メッセージを任意のモバイルノードに送信してもよい。例えば、ＭＳＨＡの管理者があらかじめポリシを設定しておき、このポリシに従って、ＭＳＨＡは、通知メッセージの送信を行うようにしてもよい。【０１０２】
また、ＭＳＨＡは、通知メッセージの送信を決定する前に、そのモバイルノードの複数の気付アドレスの登録をチェックして、接続の切り換えが可能な代替ドメイン（最適なネットワーク）が存在するか否かを確認してもよい。このとき、例えばサポートマネージャ３１０は、必要な情報を取得するため、ローカル又はリモートの情報サービス３４０に問い合わせを行ってもよい。また、モバイルノードに適したＭＣＨＡに関する問い合わせを情報サービス３４０に行ってもよく、この場合、問い合わせに対する応答によって提供されるＭＣＨＡは、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡとは異なるＭＣＨＡとなる場合もある。【０１０３】
また、ＭＳＨＡのサポートマネージャ３１０は、モバイルノードがバインディングメッセージを送信する際に使用すべきインタフェースを示す推奨情報を通知メッセージによって送ってもよい。【０１０４】
また、ＭＳＨＡは、モバイルノードがネットワークに接続する際のＡＡＡ（Authentication, Authorization and Accounting：認証、認可、課金）の処理を行う段階で、モバイルノードが所望する複数の気付アドレスの登録方法を聞くことも可能である。この場合、ＭＳＨＡはすぐに通知メッセージを送信し、このネットワークにおけるＭｏｎａｍｉ６サービスが最適な状態ではないことをモバイルノードに通知することが可能であり、これによって、モバイルノードは、必要に応じて、バインディングアップデートメッセージの送信を行わずに別のネットワークへの切り換えを即座に行うことが可能となる。【０１０５】
また、図９には、ＭＳＨＡからモバイルノードに送信される通知メッセージが図示されている。なお、図９に図示されている通知メッセージは一例であって、適用されるシステムや実施条件によって適宜変更可能である。【０１０６】
図９に図示されている通知メッセージは、この通知メッセージを受信したインタフェースにおいては、Ｍｏｎａｍｉ６のサービスが最適ではないことをモバイルノードに通知するために使用される。【０１０７】
図９に図示されている通知メッセージは、タイプフィールド９００、代替推奨フィールド９１０、付加情報フィールド９２０を有している。【０１０８】
図９において、タイプフィールド９００は、このメッセージが通知メッセージであることを識別可能とするために使用される。なお、このタイプフィールド９００には、送信者ノード及び受信者ノードの両方によって理解される値が設定される。また、代替推奨フィールド９１０には、最適なＭｏｎａｍｉ６のサービスに使用されるべき代替インタフェースを示すことが可能である。また、付加情報フィールド９２０には、モバイルノードがより良いＭｏｎａｍｉ６のサービスを得られるようにするための付加情報を含ませることが可能である。例えば、付加情報フィールド９２０に挿入される付加情報としては、ＭＣＨＡを見つけることが可能なネットワークインタフェースのタイプ、モバイルノードの最も近くに存在するＭＣＨＡのＧＰＳ位置情報やアドレス情報などの様々な情報を用いることが可能である。【０１０９】
また、通知メッセージは、例えば、バインディングアップデートメッセージに対して返信するバインディングアクノレッジメッセージに挿入されたモビリティオプションの形式で伝搬可能である。この場合には、通知メッセージのタイプフィールド９００は、モバイルＩＰｖ６の規定に従って、８ビットのオプションタイプ識別子の値と８ビットのオプション長の値とを有する。また、代替推奨フィールド９１０には、複数の気付アドレスの登録を送信する際に使用されるべきモバイルノードのインタフェースの気付アドレスが含まれる。また、付加情報フィールド９２０には、モバイルノードで利用可能な他のインタフェースの気付アドレスが含まれていてもよい。【０１１０】
また、通知メッセージは、例えばＩＥＥＥ８０２．２１に規定されている異種ネットワーク間のハンドオーバを可能とするＭＩＦメディア独立ハンドオーバ機能（ＭＩＨＦ：Media Independent Handover Function）などのような、より低いレイヤの機能によって伝搬されてもよい。この場合には、通知メッセージは、ＩＥＥＥ８０２．２１に定義されている各サービスに基づくイベントやコマンドの形式で送信されてもよい。例えば、通知メッセージが伝搬される形式の一例としては、リンク検出イベントやＭＩＨスイッチコマンドなどが挙げられる。また、この場合には、代替推奨フィールド９１０には、ＩＥＥＥ ＭＡＣ ＩＤのようなインタフェースのレイヤ２における特定の識別子の値が挿入される。【０１１１】
また、通知メッセージは、アプリケーションレイヤにおいて伝搬されてもよい。この場合には、例えば、モバイルノード及びＭＳＨＡは、通知メッセージ内の各情報フィールドの値を適切な方法で通信することができるカスタマイズされたソフトウェアを実行する。【０１１２】
また、図１０には、本発明のさらに異なる実施の形態におけるＭＳＨＡの通知メッセージを用いる際の動作の一例を示すフローチャートが図示されている。なお、図５に示すフローチャートと図１０に示すフローチャートとを比較すれば分かるように、図１０に示すフローチャートに係る動作は、図５に示すフローチャートに係る動作に対して、ステップＳ１０１０、Ｓ１０２０の２つのステップのみが追加されたものである。以下では、主に、図１０に示すフローチャートに係る動作で追加されたステップについて説明する。【０１１３】
ステップＳ５２０でモバイルノードがＭｏｎａｍｉ６機能をリクエストしている場合には、ＭＳＨＡは、通知メッセージを送信すべきか否かの判断を行う（ステップＳ１０１０）。ここでは例えば、モバイルノードが、Ｍｏｎａｍｉ６のサービスを最適な状態で（例えば、適切なネットワークインタフェースを使用して）受けているか否かの判断が行われる。なお、通知メッセージの送信を行う判断基準（送信トリガ）に関しては、任意の条件を用いることが可能である。【０１１４】
ステップＳ１０１０で通知メッセージを送信する必要がないと判断された場合には、ＭＳＨＡは、ステップＳ５３０に進み、Ｍｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェント２１０の設定を行って、そのモバイルノードのバインディングキャッシュエントリのアップデートを行う（ステップＳ５３０）。【０１１５】
一方、ステップＳ１０１０で通知メッセージを送信する必要があると判断された場合には、ＭＳＨＡは、ステップＳ１０２０に進み、ステップＳ５３０におけるバインディングキャッシュエントリのアップデートを行う前に、Ｍｏｎａｍｉ６のサービスが最適ではないことをモバイルノードに通知するための通知メッセージを適切な方法で生成し、モバイルノードに送信する処理を行う。【０１１６】
なお、モバイルノードへの通知メッセージは、実際には、ＭＳＨＡではなく、グローバルＨＡＨＡ内の別のエンティティ（グローバルＨＡＨＡネットワークに属する任意のノード）から送信されてもよい。例えば、モバイルノードに通知メッセージを送信するＭＳＨＡとしては、例えば、ネットワークトポロジに関する包括的な知識を持つセントラルエンティティや、グローバルＨＡＨＡで定義されているモバイルノードのプライマリホームエージェントなどが挙げられる。この場合、ＭＳＨＡは、通知メッセージの送信元となるエンティティに対して、必要な情報（モバイルノードの識別子及びモバイルノードから送信された登録データ）を通知する必要がある。この通知方法は任意であるが、例えば、図９に図示されている通知メッセージを拡張したメッセージを用いることが可能である。【０１１７】
また、図１１には、本発明に係る拡張機能を有するモバイルノードの機能（主に追加された機能）が模式的に図示されている。図１１に図示されているモバイルノードは、Ｍｏｎａｍｉ６のサービスなどを始めとするオーバレイネットワークサービスに係る機能の利用をネットワークにリクエストするサービスリクエスト部１１０１と、このオーバレイネットワークサービスを適切に受けられない旨を示す通知メッセージをネットワークから受信する通知メッセージ受信部１１０２と、通知メッセージを受信した場合にオーバレイネットワークサービスを受ける方法を変更するサービス利用変更部１１０３とを有している。【０１１８】
なお、モバイルノードが、ネットワークに接続するための複数のインタフェースを有している場合には、サービス利用変更手段は、ネットワークに接続するためのインタフェースを切り換えることによって、サービスをより適切に受けられるようにすることが可能である。また、通知メッセージの代替推奨フィールド９１０や付加情報フィールド９２０に、モバイルノードがオーバレイネットワークサービスを適切に受けられるようにするための情報が含まれている場合には、サービス利用変更手段は、この情報に基づいて、ネットワークに接続するためのインタフェースを切り換えることが可能である。【０１１９】
また、モバイルノードがＭＳＨＡに接続していることをオーバレイネットワーク内のノードに通知することにより、ＭＳＨＡの転送先となるターゲットＭＣＨＡを設定する動作を補助することもできる。この場合、モバイルノードがＭＳＨＡから最適なサービス利用ができない旨を通知されることにより、サービスリクエストを送信する。サービスリクエストにはどのＭＳＨＡに対してターゲットＭＣＨＡを設定してほしいかの情報が含まれていることが望ましい。この場合のサービスリクエストは、ＭＣＨＡに接続しているインタフェース（もし存在していれば）から送信されたり、別の方法（ネームサービス、インフォメーションサービス、事前設定など）で知ることのできたセントラルエンティティやプライマリホームエージェントへ送信されたりしてもよく、また、より低いレイヤのメッセージで通知されてもよい。この通知によりオーバレイネットワーク内のどのＭＳＨＡがどのモバイルノードに対してのターゲットＭＣＨＡを必要としているかをオーバレイネットワーク内の他のノードが把握しやすくなる。【０１２０】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、サポートマネージャ３１０やその他の構成要素に係る設計やパラメータの詳細において、例えば、Ｍｏｎａｍｉ６やフローフィルタリングの機能をＱｏＳ（Quality of Service：サービス品質）保証の機能に置き換えるなど、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。【０１２１】
また、本明細書では、モバイルノードのネットワークインタフェースが複数であることを前提に説明を行っているが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り換えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。【０１２２】
また、上述の実施の形態では、オーバレイネットワークがグローバルな構成であることが仮定されているが、ローカルモビリティ管理（Local Mobility Management）の環境に本発明を適用することも可能である。例えば、ローカルモビリティ管理方法の１つであるＰＭＩＰ（Proxy Mobile IP）はＭＡＧ（Mobile Access Gateway）がＬＭＡ（Local Mobility Anchor）に移動端末の移動登録を行うことにより、移動端末に対するモビリティサポートを提供しているが、本明細書におけるＭＣＨＡやＭＳＨＡがＭＡＧに対応する形で適用可能である。この場合、モバイルノードの移動の起点（ある時点を基準とするものであったり（相対的）、ネットワークオペレータへの登録の状態（確定的）であったり、様々な場合があり得る）となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはＬＭＡに対応すると考えることができる。【０１２３】
また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【０１２４】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。【０１２５】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１２６】
本発明は、例えば、異なるインターネットサービスプロバイダが協働してオーバレイネットワークを形成する場合のように、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切に提供できるようになるという効果を有しており、ＩＰネットワークなどのパケット交換型データ通信ネットワークを抽象化するオーバレイネットワークに関する技術分野に適用可能であり、また、フローフィルタリング技術やＭｏｎａｍｉ６に関する技術に適用可能である。
【図１】
2008114498.tif 000003
【図２】
2008114498.tif 000004
【図３】
2008114498.tif 000005
【図４】
2008114498.tif 000006
【図５】
2008114498.tif 000007
【図６】
2008114498.tif 000008
【図７】
2008114498.tif 000009
【図８】
2008114498.tif 000010
【図９】
2008114498.tif 000011
【図１０】
2008114498.tif 000012
【図１１】
2008114498.tif 000013
【手続補正書】
【提出日】平成21年9月10日(2009.9.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
当該オーバレイネットワークノードがサポートしていないサービスを受けようとしているモバイルノードを識別する識別手段と、
前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有するオーバレイネットワークノード。
【請求項２】
前記モバイルノードが受けようとしている前記サービスが、複数の気付アドレスの登録、フローフィルタリングルールの登録、Ｍｏｎａｍｉ６プロトコルに基づく動作のいずれかである請求項１に記載のオーバレイネットワークノード。
【請求項３】
前記サービスを受けようとしている前記モバイルノードに関して、前記サービスを受けようとしていることを示す情報と、前記特定のオーバレイネットワークノードの識別情報とを関連付けて記憶する情報記憶手段を有する請求項１に記載のオーバレイネットワークノード。
【請求項４】
前記サービスを受けようとしている前記モバイルノードから前記サービスのリクエストを直接受信した場合に、前記転送手段が、前記特定のオーバレイネットワークノードに前記リクエストを転送するように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項５】
前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットが、前記サービスをサポートしている任意のオーバレイネットワークノードで処理されたか否かを判断する処理判断手段を有し、
前記転送手段は、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されている場合には、前記データパケットを前記モバイルノードに転送する一方、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されていない場合には、前記データパケットを前記特定のオーバレイネットワークノードに転送するように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項６】
前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットに関するフローフィルタリングルールが存在しているか否かを確認するルールチェック手段を有し、
前記データパケットに関するフローフィルタリングルールが存在している場合には、前記転送手段が、前記フローフィルタリングルールに基づく前記データパケットの転送を行うように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項７】
所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
特定のサービスを提供するサービス提供手段と、
前記特定のサービスの提供を行う状態と、前記特定のサービスの提供を行わない状態とを切り換えるサービス提供状態切り換え手段と、
前記サービスを受けようとしているモバイルノードを識別する識別手段と、
前記特定のサービスの提供を行わない状態の場合に、前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有するオーバレイネットワークノード。
【請求項８】
前記サービス提供状態切り換え手段で前記状態の切り換えが行われる場合に、前記状態の切り換えに応じて、前記オーバレイネットワークで共有されている前記サービスをサポートしているオーバレイネットワークノードのリストのアップデートを行うリストアップデート手段を有する請求項７に記載のオーバレイネットワークノード。
【請求項９】
前記リストアップデート手段が、前記状態の切り換えに応じて、前記リストにおける当該オーバレイネットワークノードの追加又は削除を示すアップデートメッセージを送信するように構成されている請求項８に記載のオーバレイネットワークノード。
【請求項１０】
前記モバイルノードが前記サービスを適切に受けられるか否かを判断するサービス判断手段と、
前記サービス判断手段において前記サービスを適切に受けられないと判断された場合に、前記モバイルノードが前記サービスを適切に受けられない旨を示す通知メッセージを生成する通知メッセージ生成手段と、
前記通知メッセージを前記モバイルノードに送信する通知メッセージ送信手段とを、
有する請求項１に記載のオーバレイネットワークノード。
【請求項１１】
前記通知メッセージ生成手段が、前記モバイルノードが前記サービスを適切に受けられるようにするための情報を前記通知メッセージに挿入するように構成されている請求項１に記載のオーバレイネットワークノード。
【請求項１２】
ネットワークに接続し、前記ネットワークの上位に形成されているオーバレイネットワークが提供する特定のオーバレイネットワークサービスに係る機能を利用した通信を行うモバイルノードであって、
前記ネットワークに対して、前記特定のオーバレイネットワークサービスに係る機能の利用をリクエストするサービスリクエスト手段と、
前記オーバレイネットワークサービスを適切に受けられない旨を示す通知メッセージを前記ネットワークから受信する通知メッセージ受信手段と、
前記通知メッセージを受信した場合に、前記オーバレイネットワークサービスを受ける方法を変更するサービス利用変更手段とを、
有するモバイルノード。
【請求項１３】
前記ネットワークに接続するための複数のインタフェースを有し、前記サービス利用変更手段が、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている請求項１２に記載のモバイルノード。
【請求項１４】
前記オーバレイネットワークサービスを適切に受けられるようにするための情報としてインタフェースタイプ情報が前記通知メッセージに含まれており、前記サービス利用変更手段が、前記インタフェースタイプ情報に基づいて、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている請求項１３に記載のモバイルノード。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol：インターネットプロトコル）ネットワークなどのパケット交換型データ通信ネットワークを抽象化するオーバレイネットワーク（overlay network）のノードとして機能するオーバレイネットワークノード及びモバイルノードに関する。
【背景技術】
【０００２】
現在、ユーザにとって、移動しながらインターネットへの接続性を維持できることが重要な要件となってきている。特に、ユーザがどのような場所に移動しても、常にインターネットに接続できる状態が求められている。ユーザがネットワーク間を移動する際にはＩＰアドレスを変更しなければならないが、このアドレス変更に係る課題は、モバイルＩＰの導入によって解決されている。
【０００３】
また、ＩＥＴＦ（Internet Engineering Task Force）のＭｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）ワーキンググループでは、マルチインタフェースのモバイルノードに対して、そのマルチモードの特性を十分に活用できるような機能を提供するための議論が進められている。
【０００４】
マルチインタフェースのモバイルノードは、そのインタフェースで取得した複数の気付アドレスをホームエージェントに登録することが可能である。複数の気付アドレス登録によって、ホームエージェントは、モバイルノードが複数のルートを経由して到達可能であることを把握できるようになる。
【０００５】
この技術を実現することによって、モバイルノードは、データパケットを受信したい場所を指定することができるようになる。また、データパケットのストリーム（フローと呼ばれる）に関して、送信すべきあて先となる気付アドレスを指定したルールを定めることも可能である。
【０００６】
また、ＩＥＴＦでは並行して、モバイルＩＰを使用したモバイルノードの移動に伴って、データパケットの伝送経路を最適化する手法を提供するための議論も進められている。なお、この最適化とは、様々なレベルや様々な形式に従って行われるものであり、例えば、送信者と受信者との間のエンドトゥーエンドの最適化に関しては、モバイルＩＰの基本的な標準規格において既に議論されている。一方、例えば、モバイルルータ又はモバイルノードとホームエージェントとの間の最適化に関しては、ＩＥＴＦの様々なワーキンググループにおいて議論が進められている。
【０００７】
また、下記の非特許文献１には、オーバレイネットワーク内で行われる最適化に関する手法（グローバルＨＡＨＡと呼ばれる技術）が提案されている。非特許文献１で提案されている手法では、地理的に分散して配置されている協働ルータのネットワークを使用して、エンドユーザに透過（transparent）な経路最適化が実現される。
【０００８】
まず、ユーザのモバイルノードが、ホームエージェントにバインディング情報の登録を行う。そして、ホームエージェントは、地理的に分散して配置されたオーバレイネットワーク内の他のホームエージェントに対して、このバインディング情報を配信し、その結果、他のホームエージェントもモバイルノードのプロキシホームエージェントとして機能できるようになる。
【０００９】
モバイルノードから送受信されるデータパケットは、送信元ノードに最も近いプロキシホームエージェントによって受信（intercept）され、カプセル化又はデカプセル化された後、あて先ノードに最も近い別のプロキシホームエージェントにトンネルされる。このように、送信元ノードからオリジナルのホームエージェント（モバイルノードがバインディング情報の登録を行ったホームエージェント）を経由してあて先ノードに届く経路とは対照的に、送信元ノードとあて先ノードとの間において、データパケットのパスは最適化される。
【００１０】
また、下記の特許文献１には、ホームエージェント、ホームエージェントのコントローラ及びバックアップ装置によって構成されたシステムにおいて、すべてのコントローラやバックアップ装置（バックアップのホームエージェント）に対して、ホームエージェントが有する情報がマルチキャスティングされることによって、バックアップのホームエージェントに動作をシームレスに切り換えられるようにする技術が開示されている。
【００１１】
また、下記の特許文献２には、仮想ホームエージェントアドレスが使用されて、クライアントが透過的（トランスペアレント）に複数のホームエージェントに登録される方法について記載されている。ここでは、ホームエージェント間で“ハートビート”メッセージのシステムを利用して情報の同期処理が行われたり、マルチキャスト情報の同期処理が行われたりする。
【特許文献１】米国特許第７０８０１５１号
【特許文献２】米国特許第６４３０６９８号
【非特許文献１】P. Thubert, et al., "Global HA to HA protocol", Internet Engineering Task Force Internet Draft: draft-thubert-nemo-global-haha-01.txt, Work-In-Progress, 15 Oct 2005.
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、オーバレイネットワークの範囲には限度があり、例えば国境や大陸を越えるようなオーバレイネットワークが必要とされる範囲及びスケールでは、実際には、多数のサービスプロバイダが協力してオーバレイネットワークを実現することになると考えられる。
【００１３】
一方、各地の各プロバイダはそれぞれ異なるため、オーバレイネットワークを形成するオーバレイネットワークノードは、それぞれの機能が一致していないことが予想される。例えば、プロトコルが十分に確立されていない場合や、プロトコルを使用した場合のライセンスに要する費用などを始めとする様々な理由によって、特定のプロトコル（例えば、Ｍｏｎａｍｉ６プロトコルスタック）を実装しないように選択するサービスプロバイダが現れる可能性もある。
【００１４】
オーバレイネットワークにＭｏｎａｍｉ６機能を有さないレガシのホームエージェントが混在している場合には、このＭｏｎａｍｉ６機能のサービスを受けようとしているサービス加入者が、複数のインタフェースを有するノードの動作に対して、その対価を支払う際に問題が生じる。このような状況では、レガシのホームエージェントを通るデータストリームは、ユーザの好みに応じたフィルタリングを受けられず、レガシのホームエージェントにインストールされている既存エントリによって適当に処理されてしまうことになる。すなわち、Ｍｏｎａｍｉ６機能のサービスを受けようとしているサービス加入者に対して、Ｍｏｎａｍｉ６機能のサービスが十分に提供されないという問題が生じる。現在、オーバレイネットワークを最適化する動作に関して様々な手法が存在しているが、上述のような異なる機能を有するオーバレイネットワークノードが混在する状況において生じる問題の解決方法は存在していない。
【００１５】
また、特許文献１に開示されている技術は、オーバレイネットワークの動作にとっては有益であるが、加入者に対するサービスの保証を維持する間は、異なる能力を有するホームエージェントを動作させることはできないという問題がある。
【００１６】
また、特許文献２に開示されている技術においても、ホームエージェント間で、サポートされているプロトコルにおける機能が異なる場合における明確な解決方法が存在していないという問題がある。
【００１７】
上記の問題を解決するため、本発明は、例えば、異なるインターネットサービスプロバイダが協働してオーバレイネットワークを形成する場合のように、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切に提供することを可能にするオーバレイネットワークノード及びモバイルノードを提供することを目的とする。
【課題を解決するための手段】
【００１８】
上記の目的を達成するため、本発明のオーバレイネットワークノードは、所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
当該オーバレイネットワークノードがサポートしていないサービスを受けようとしているモバイルノードを識別する識別手段と、
前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有する。
この構成により、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切にモバイルノードに提供することが可能となる。
【００１９】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記モバイルノードが受けようとしている前記サービスが、複数の気付アドレスの登録、フローフィルタリングルールの登録、Ｍｏｎａｍｉ６プロトコルに基づく動作のいずれかである。
この構成により、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、複数の気付アドレスの登録、フローフィルタリングルールの登録、Ｍｏｎａｍｉ６プロトコルに基づく動作などの各サービスを適切にモバイルノードに提供することが可能となる。
【００２０】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードに関して、前記サービスを受けようとしていることを示す情報と、前記特定のオーバレイネットワークノードの識別情報とを関連付けて記憶する情報記憶手段を有する。
この構成により、オーバレイネットワークノードは、モバイルノードを確実に特定して、特定のオーバレイネットワークノードに対して、モバイルノードへのサービスの提供を依頼することが可能となる。
【００２１】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードから前記サービスのリクエストを直接受信した場合に、前記転送手段が、前記特定のオーバレイネットワークノードに前記リクエストを転送するように構成されている。
この構成により、モバイルノードから受信したサービスのリクエストを、そのサービスを提供することが可能な特定のオーバレイネットワークノードに確実に渡すことが可能となる。
【００２２】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットが、前記サービスをサポートしている任意のオーバレイネットワークノードで処理されたか否かを判断する処理判断手段を有し、
前記転送手段は、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されている場合には、前記データパケットを前記モバイルノードに転送する一方、前記データパケットが前記サービスをサポートしている任意のオーバレイネットワークノードで処理されていない場合には、前記データパケットを前記特定のオーバレイネットワークノードに転送するように構成されている。
この構成により、モバイルノードあてのデータパケットに対して、モバイルノードが受けようとしているサービスがまだ提供されていない場合には、そのサービスを提供することが可能な特定のオーバレイネットワークノードに、そのデータパケットを確実に渡すことが可能となる。
【００２３】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービスを受けようとしている前記モバイルノードあてのデータパケットを受信した場合に、前記データパケットに関するフローフィルタリングルールが存在しているか否かを確認するルールチェック手段を有し、
前記データパケットに関するフローフィルタリングルールが存在している場合には、前記転送手段が、前記フローフィルタリングルールに基づく前記データパケットの転送を行うように構成されている。
この構成により、転送すべきパケットに関して、当該オーバレイネットワークノードがフローフィルタリングルールに基づくパケット転送を行うことで、サービスをサポートしている特定のオーバレイネットワークノードへのパケット転送が行われず、ネットワークのリソースを節約することが可能となる。
【００２４】
また、上記の目的を達成するため、本発明のオーバレイネットワークは、所定のネットワークの上位に形成されているオーバレイネットワークに属しており、特定のオーバレイネットワークサービスに係る機能を有するオーバレイネットワークノードであって、
特定のサービスを提供するサービス提供手段と、
前記特定のサービスの提供を行う状態と、前記特定のサービスの提供を行わない状態とを切り換えるサービス提供状態切り換え手段と、
前記サービスを受けようとしているモバイルノードを識別する識別手段と、
前記特定のサービスの提供を行わない状態の場合に、前記モバイルノードが受けようとしている前記サービスをサポートしている特定のオーバレイネットワークノードから前記モバイルノードに対して前記サービスの提供が行われるように、前記サービスをサポートしている前記特定のオーバレイネットワークノードに対して、前記モバイルノードからの前記サービスをリクエストする情報、及び前記モバイルノードあてのデータパケットを転送する転送手段とを、
有する。
この構成により、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切にモバイルノードに提供することが可能となる。また、特に、何らかのポリシに基づいて、当該オーバレイネットワークノードが特定のサービスを提供するか否かを切り換えることが可能であり、上記の構成によって、当該オーバレイネットワークノードが特定のサービスを提供していない場合であっても、モバイルノードが受けようとしている特定のサービスが適切にモバイルノードに提供されるようになる。
【００２５】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記サービス提供状態切り換え手段で前記状態の切り換えが行われる場合に、前記状態の切り換えに応じて、前記オーバレイネットワークで共有されている前記サービスをサポートしているオーバレイネットワークノードのリストのアップデートを行うリストアップデート手段を有する。
この構成により、オーバレイネットワークにおいて集中管理又は分散管理されている、サービスをサポートしているオーバレイネットワークノードのリストにおいて、当該オーバレイネットワークにおけるサービスの提供状態を示すことが可能となる。
【００２６】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記リストアップデート手段が、前記状態の切り換えに応じて、前記リストにおける当該オーバレイネットワークノードの追加又は削除を示すアップデートメッセージを送信するように構成されている。
この構成により、当該オーバレイネットワークがサービスの提供状態を切り換える場合にアップデートメッセージを送信することによって、リストのアップデートが行われるようになる。
【００２７】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記モバイルノードが前記サービスを適切に受けられるか否かを判断するサービス判断手段と、
前記サービス判断手段において前記サービスを適切に受けられないと判断された場合に、前記モバイルノードが前記サービスを適切に受けられない旨を示す通知メッセージを生成する通知メッセージ生成手段と、
前記通知メッセージを前記モバイルノードに送信する通知メッセージ送信手段とを、
有する。
この構成により、モバイルノードが特定のサービスを適切に受けられない状態が、モバイルノードに通知されるようになる。
【００２８】
さらに、本発明のオーバレイネットワークノードは、上記の構成に加えて、前記通知メッセージ生成手段が、前記モバイルノードが前記サービスを適切に受けられるようにするための情報を前記通知メッセージに挿入するように構成されている。
この構成により、より適切にサービスを受けるための情報が、モバイルノードに通知されるようになる。
【００２９】
また、上記の目的を達成するため、本発明のモバイルノードは、ネットワークに接続し、前記ネットワークの上位に形成されているオーバレイネットワークが提供する特定のオーバレイネットワークサービスに係る機能を利用した通信を行うモバイルノードであって、
前記ネットワークに対して、前記特定のオーバレイネットワークサービスに係る機能の利用をリクエストするサービスリクエスト手段と、
前記オーバレイネットワークサービスを適切に受けられない旨を示す通知メッセージを前記ネットワークから受信する通知メッセージ受信手段と、
前記通知メッセージを受信した場合に、前記オーバレイネットワークサービスを受ける方法を変更するサービス利用変更手段とを、
有する。
この構成により、モバイルノードが特定のサービスを適切に受けられない状態がモバイルノードに通知され、モバイルノードは、サービスを受ける方法を変更することが可能となる。
【００３０】
さらに、本発明のモバイルノードは、上記の構成に加えて、前記ネットワークに接続するための複数のインタフェースを有し、前記サービス利用変更手段が、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている。
この構成により、モバイルノードは、サービスをより適切に受けることができるように、サービスを受けるインタフェースを切り換えることが可能となる。
【００３１】
さらに、本発明のモバイルノードは、上記の構成に加えて、前記オーバレイネットワークサービスを適切に受けられるようにするための情報としてインタフェースタイプ情報が前記通知メッセージに含まれており、前記サービス利用変更手段が、前記インタフェースタイプ情報に基づいて、前記ネットワークに接続するための前記インタフェースを切り換えるように構成されている。
この構成により、より適切にサービスを受けるためのインタフェースタイプ情報が、モバイルノードに通知され、モバイルノードは、このインタフェースタイプ情報に基づいてサービスを受けるインタフェースを切り換えることが可能となる。
【発明の効果】
【００３２】
本発明は、上記の構成を有しており、例えば、異なるインターネットサービスプロバイダが協働してオーバレイネットワークを形成する場合のように、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切に提供できるようになるという効果を有している。
【発明を実施するための最良の形態】
【００３３】
以下、図面を参照しながら、本発明の実施の形態について説明する。
【００３４】
本発明によれば、サービスプロバイダが、完全なＭｏｎａｍｉ６プロトコルの実装は行わない一方、Ｍｏｎａｍｉ６機能をサポートするオーバレイネットワークに参加して相互動作が可能となるように、Ｍｏｎａｍｉ６はサポートしているものの、Ｍｏｎａｍｉ６機能が完全には実装されていない拡張ホームエージェントが提供される。
【００３５】
まず、図１を参照しながら、本発明が前提とするオーバレイネットワークの構成の一例について説明する。図１に図示されているネットワーク構成において、モバイルノード１１０は、オーバレイネットワークサービスに加入している。また、オーバレイネットワークは、複数のホームエージェント（ＭＣＨＡ１２０、１３０、１４０、ＭＳＨＡ１５０、１６０）により構成されている。
【００３６】
ＭＣＨＡ（Monami6-Capable Home Agent：Ｍｏｎａｍｉ６実装ホームエージェントと記載する）は、オーバレイネットワーク最適化機能に加えて、複数の気付アドレスの登録機能やデータフローのフィルタリング機能などを含む完全なＭｏｎａｍｉ６プロトコルスタックを実装しているホームエージェントである。
【００３７】
一方、ＭＳＨＡ（Monami6-Support Home Agent：Ｍｏｎａｍｉ６サポートホームエージェントと記載する）は、オーバレイネットワーク最適化機能のみを実装しているが、本発明に係る解決方法を使用して、Ｍｏｎａｍｉ６の動作をサポートすることが可能なホームエージェントである。
【００３８】
図１では、モバイルノード１１０は、３つのコレスポンデントノードＣＮ１７０、１８０、１９０からデータストリームを受信しているとする。モバイルノード１１０は、Ｍｏｎａｍｉ６プロトコルスタックを用いて、パス１１１、１１２を使用するインタフェースを登録することが可能である。さらに、モバイルノード１１０は、ＣＮ１７０、１８０、１９０からのデータストリームの転送方法を指定することが可能である。
【００３９】
従来の技術において、例えば、図１に図示されているＭＳＨＡ１５０、１６０がレガシのホームエージェントの場合（すなわち、ＭＳＨＡ１５０、１６０の設置箇所に、Ｍｏｎａｍｉ６をまったく理解できないホームエージェントが存在している場合）、これらのレガシのホームエージェントは、複数の気付アドレスの登録を行うことができないので、モバイルノード１１０に関する複数エントリを有するバインディングキャッシュを構成することはできない。
【００４０】
例えば、これらのレガシのホームエージェントは、オーバレイネットワークで通知されるアップデートに複数の気付アドレスが含まれている場合でも、通常のモバイルＩＰにおける動作を行って、単に、その最初のオプションに含まれる値をモバイルノード１１０の現在の気付アドレスとして登録する可能性がある。
【００４１】
さらに、レガシのホームエージェントは、別のパスを使用してモバイルノード１１０にパケットを発送するということが分からないため、モバイルノード１１０からのフローフィルタリングルールを理解できなかったり、モバイルノード１１０からのフローフィルタリングルールに基づいて動作できなかったりする。
【００４２】
例えば、ＭＳＨＡ１５０がレガシのホームエージェントの機能しかもっておらず、ＣＮ１９０からのデータストリームがこのレガシのホームエージェントを経由する場合には、たとえこのデータストリームをパス１１１経由で受信するようにＭＮ１１０がフローフィルタリングルールを設定したとしても、このレガシのホームエージェントは、単にデータストリームを最短パス１１２経由で送信し、ＭＮ１１０によって定義されたフローフィルタリングルールは無視されることになる。
【００４３】
一方、本発明によれば、オーバレイネットワーク内に存在し得るＭＣＨＡ以外のホームエージェント（従来の技術におけるレガシのホームエージェント）は、少なくともＭｏｎａｍｉ６機能を理解することができるＭＳＨＡであり、Ｍｏｎａｍｉ６機能に係るサービス（Ｍｏｎａｍｉ６サービス）に登録しているモバイルノードあてのパケットを正しく取り扱うことができるようになる。
【００４４】
例えば、ＭＳＨＡは、複数の気付アドレスの登録は行わないものの、Ｍｏｎａｍｉ６サービスをリクエストしているモバイルノードに関しては、そのバインディングキャッシュエントリの追加フィールドに目印を付け、このモバイルノードあてのデータパケットを適切なＭＣＨＡに渡すことによって、ＭＣＨＡで更なる処理（Ｍｏｎａｍｉ６機能に係る正常な処理）が行われるようにする。なお、ＭＳＨＡは、ＭＣＨＡから発送されたり転送されたりしていないパケット（ＭＣＨＡで処理されていないパケット）に関して、モバイルノードあてのすべてのパケットに対して上記の処理を行うことが望ましい。
【００４５】
例えば、図１に図示されているネットワーク構成において、ＭＳＨＡ１５０が、Ｍｏｎａｍｉ６のバインディングアップデートメッセージをＭＮ１１０からパス１１２経由で受信したとする。この場合、ＭＳＨＡ１５０は、まず、モバイルＩＰｖ６（ＭＩＰｖ６）に従ってバインディングキャッシュのアップデートを行い、その後、Ｍｏｎａｍｉ６サービスをリクエストしているＭＮ１１０を識別するフラグをバインディングキャッシュエントリに追加する必要がある。さらに、ＭＮ１１０に対して機能するＭＣＨＡ（すなわち、Ｍｏｎａｍｉ６に係るパケット処理を担うＭＣＨＡ）も記載されることが望ましい。なお、ＭＣＨＡの候補は、各バインディングキャッシュエントリで同一であってもよく、あるいは異なるものであってもよい。また、ＭＣＨＡの候補は、各バインディングキャッシュエントリに静的に割り当てられてもよく、あるいは動的に割り当てられてもよい。さらには、ＭＣＨＡの候補は、例えば、パケットの転送パスが最短となるものが選択されてもよく、その他の任意のポリシに基づいて設定されてもよい。
【００４６】
図２には、ＭＳＨＡにおいて、バインディングキャッシュエントリに追加される情報要素が図示されている。本発明では、例えば、Ｍｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０がバインディングキャッシュエントリに追加される。Ｍｏｎａｍｉ６フラグフィールド２００には、このバインディングキャッシュエントリに関連したモバイルノードがＭｏｎａｍｉ６サービスをリクエストしているか否かを示す値が設定される。また、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０には、このバインディングキャッシュエントリに関連したモバイルノードに関するパケットの転送先となるＭＣＨＡの識別情報が設定される。
【００４７】
例えば、ＭＳＨＡ１５０がＭｏｎａｍｉ６のバインディングアップデートメッセージをＭＮ１１０からパス１１２経由で受信した場合、ＭＳＨＡ１５０は、バインディングキャッシュをアップデートした後に、ＭＮ１１０に関するバインディングキャッシュエントリのターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡ（例えば、ＭＣＨＡ１３０）に、バインディングアップデートメッセージ全体を転送する。したがって、ＭＳＨＡ１５０は、パス１０５経由でバインディングアップデートをＭＣＨＡ１３０に転送し、ＭＣＨＡ１３０で更なる処理が行われる。
【００４８】
ＭＣＨＡ１３０は、ＭＮ１１０のバインディングアップデートメッセージを受信すると、ＭＩＰｖ６、Ｍｏｎａｍｉ６、オーバレイネットワークプロトコルなどの各機能に関する通常の動作を実行する。
【００４９】
また、ＭＳＨＡ１６０も、ＭＮ１１０で生成されたＭｏｎａｍｉ６のバインディングアップデートメッセージをオーバレイネットワークを経由して受信する。なお、このとき、オーバレイネットワークのプロトコルに適した形式にフォーマットが変更されていてもよい。
【００５０】
このように、ＭＮ１１０のバインディングアップデートメッセージは、オーバレイネットワークに属するホームエージェントに分配される必要があるが、ＭＳＨＡ１６０は、このバインディングアップデートメッセージが、Ｍｏｎａｍｉ６実装オーバレイネットワークノードによって既に処理済であると認識できることが望ましい。
【００５１】
ＭＳＨＡ１６０は、例えば、ＭＳＨＡ１５０と同様にバインディングキャッシュのアップデートを行うが、ＭＳＨＡ１６０は、ＭＮ１１０のフローを処理するターゲットＭｏｎａｍｉ６実装ホームエージェントとして、ＭＣＨＡ１４０をセットする。すなわち、ＭＳＨＡ１６０は、ＭＮ１１０に関するバインディングキャッシュエントリにおいて、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０にＭＣＨＡ１４０を記載するアップデートを行う。さらに、ＭＳＨＡ１６０は、別のプロトコルによる要請がない限り、バインディングアップデートメッセージをＭＣＨＡ１４０に再転送しないようにする。これによって、ＭＳＨＡからＭＣＨＡに転送されたバインディングアップデートメッセージが、ＭＣＨＡによって冗長な処理となることを防ぐことが可能となる。
【００５２】
つまり、ＭＮから直接受信したバインディングアップデートメッセージの場合は、ターゲットＭｏｎａｍｉ６実装ホームエージェントにより正しく解釈される必要があるが、オーバレイネットワークを経由して受信したバインディングアップデートメッセージの場合は、既にＭｏｎａｍｉ６実装ホームエージェントにより適切に解釈されているとみなせるのでターゲットＭｏｎａｍｉ６実装ホームエージェントにより再解釈される必要はない。それゆえ、ＭＳＨＡは、オーバレイネットワークを経由して受信したバインディングアップデートメッセージは、ＭＣＨＡに転送する必要はない。
【００５３】
ＭＮ１１０あてのパケットがＣＮ１７０からパス１７１を経由してＭＳＨＡ１６０に到達した場合には、ＭＳＨＡ１６０は、そのバインディングキャッシュを調べ、ＭＮ１１０に関連するエントリを参照する。ＭＳＨＡ１６０は、ＭＮ１１０がＭｏｎａｍｉ６サービスをリクエストしていることを把握すると、ＭＮ１１０のバインディングキャッシュエントリに存在するターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡ１４０に対して、パケットを転送する。
【００５４】
ＭＣＨＡ１４０は、ＣＮ１７０からＭＮ１１０へのパケットを受信すると、ＭＮ１１０が規定したフローフィルタリングルールに基づくあて先にパケットを転送する。すなわち、ＣＮ１７０からＭＮ１１０へのパケットは、フローフィルタリングルールに基づく処理を実行できないＭＳＨＡ１６０から、フローフィルタリングルールに基づく処理を実行できるＭＣＨＡ１４０に転送された後、ＭＣＨＡ１４０でフローフィルタリングルールが適用される。
【００５５】
また、ＭＮ１１０あてのパケットがＣＮ１８０からパス１８１を経由してＭＣＨＡ１３０に到達した場合には、ＭＣＨＡ１３０は、ＭＮ１１０によって構成されたフローフィルタリングルールを使用して、パケットをそのあて先に転送する。例えば、ＣＮ１８０からのパケットはパス１１２を経由して伝送されるようにＭＮ１１０がリクエストしている場合には、ＭＣＨＡ１３０はＭＳＨＡ１５０にパケットをトンネルする。
【００５６】
ＭＳＨＡ１５０は、パケットのデカプセル化の際に、そのパケットのあて先が、Ｍｏｎａｍｉ６サービスをリクエストしているＭＮ１１０であることに気付く。しかしながら、オリジナルのパケットはＭｏｎａｍｉ６実装ノード（ＭＣＨＡ１３０）からトンネルされてきているので、ＭＣＨＡ１３０で既にフローフィルタリングルールに基づく処理が実行されており、ＭＳＨＡ１５０は、通常通り、パス１１２経由でＭＮ１１０にパケットを転送する。なお、ここでは、トンネルパケットの送信元とターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されている特定のホームエージェント（ＭＣＨＡ１３０）とは同一であるが、必ずしも同一である必要はなく、トンネルの送信元はＭｏｎａｍｉ６実装ノードであればよい。
【００５７】
また、ＭＮ１１０あてのパケットがＣＮ１９０からパス１９１を経由してＭＳＨＡ１５０に到達した場合には、ＭＳＨＡ１５０は、そのバインディングキャッシュを調べ、ＭＮ１１０に関連するエントリを参照する。ＭＳＨＡ１５０は、ＭＮ１１０がＭｏｎａｍｉ６サービスをリクエストしていることを把握すると、ＭＮ１１０のバインディングキャッシュエントリに存在するターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡ１３０に対して、パケットを転送する。
【００５８】
ＭＣＨＡ１３０は、ＣＮ１９０からＭＮ１１０へのパケットを受信すると、ＭＮ１１０が設定したフローフィルタリングルールを適用して、正しいあて先にパケットを転送する。ここで、ＭＮ１１０がＣＮ１９０からのパケットをパス１１２経由で送信されるように転送し、ＭＣＨＡ１３０がＭＳＨＡ１５０にパケットをトンネルする場合を考える。
【００５９】
ＭＳＨＡ１５０は、パケットのデカプセル化の際に、パケットのあて先が、Ｍｏｎａｍｉ６サービスをリクエストしているＭＮ１１０であることを把握する。しかしながら、オリジナルのパケットはＭｏｎａｍｉ６実装ノード（ＭＣＨＡ１３０）からトンネルされてきているので、ＭＳＨＡ１５０は、通常通り、パス１１２経由でＭＮ１１０にパケットを転送する。
【００６０】
また、図３には、本発明の実施の形態におけるＭＳＨＡ１５０に必要な機能を実現するための構成の一例が図示されている。図３に図示されているＭＳＨＡ１５０は、下位レイヤインタフェース３００、サポートマネージャ３１０、オーバレイネットワークプロトコル処理部３２０、モバイルＩＰｖ６処理部３３０、情報サービス３４０を有している。
【００６１】
下位レイヤインタフェース３００は、物理的なネットワークアクセスハードウェアやドライバ、ソフトウェアＡＰＩ（Application Programming Interface：アプリケーションプログラミングインタフェース）を有している。なお、下位レイヤインタフェース３００は、オーバレイネットワークプロトコル処理部３２０やモバイルＩＰｖ６処理部３３０で処理されるすべてのパケットを、パス３０１を通じてサポートマネージャ３１０に渡す。
【００６２】
サポートマネージャ３１０は、本発明において要求される動作を実行する。サポートマネージャ３１０は、モバイルＩＰｖ６のバインディングアップデートメッセージを受信すると、そのメッセージを調べて、Ｍｏｎａｍｉ６機能に関する要素が含まれているか否かを判断する。Ｍｏｎａｍｉ６機能に関する要素が含まれている場合には、サポートマネージャ３１０は、例えば複数の気付アドレスやフローフィルタリングルールなどの関連情報を抽出してから、パス３１３を通じてモバイルＩＰｖ６処理部３３０にメッセージを渡し、モバイルＩＰｖ６処理部３３０で通常の処理が行われる。
【００６３】
また、サポートマネージャ３１０は抽出された情報を使用して、関連するバインディングキャッシュエントリのＭｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０をアップデートする。このバインディングキャッシュエントリは、モバイルＩＰｖ６処理部３３０と共有されてもよいが、モバイルＩＰｖ６の動作に関してデータ同期が行われ、データ損失や不正を防ぐようにする必要がある。
【００６４】
また、サポートマネージャ３１０は、パス３１２を経由して情報サービス３４０に対して問い合わせを行う。例えば、サポートマネージャ３１０は、ターゲットＭｏｎａｍｉ６実装ホームエージェントを選択する際に、情報サービス３４０に問い合わせを行う。また、モバイルノードから受信したバインディングアップデートメッセージは、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されるＭＣＨＡに送信される必要がある。なお、オーバレイネットワークプロトコル処理部３２０において、このバインディングアップデートに含まれる情報に関するアップデートが行われない場合には、ＭＳＨＡは、関連するプロトコルスタックにメッセージを渡し、その関連するプロトコルスタックにおいて通常通りの処理が行われる。
【００６５】
また、情報サービス３４０は、本発明において必要となる情報を始めとして、様々な情報を提供することが可能なエンティティである。なお、情報サービス３４０は、図３に図示されているようにＭＳＨＡ１５０内に配置されていてもよく、また、離れた場所に配置されていてもよい。
【００６６】
サポートマネージャ３１０は、モバイルノードあてのデータパケットを受信すると、パケットがＭＣＨＡから送信又はトンネルされたものであるか否かをチェックする。パケットがＭＣＨＡから送信又はトンネルされたものである場合には、サポートマネージャ３１０は、関連するプロトコルスタックにパケットを渡す。例えば、パケットは、パス３１１を経由してオーバレイネットワークプロトコル処理部３２０に渡されるか、あるいはパス３１３を経由してモバイルＩＰｖ６処理部３３０に渡され、通常の処理が行われる。
【００６７】
一方、パケット送信者又はトンネルの送信元がＭＣＨＡではない場合には、サポートマネージャ３１０はバインディングキャッシュをチェック（例えば、Ｍｏｎａｍｉ６フラグフィールド２００の値をチェック）して、モバイルノード（パケットのあて先）がＭｏｎａｍｉ６サービスをリクエストしているか否かを判断する必要がある。このモバイルノードがＭｏｎａｍｉ６サービスをリクエストしている場合には、サポートマネージャ３１０は、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡに対して、パケットを転送する必要がある。
【００６８】
一方、モバイルノードがＭｏｎａｍｉ６サービスをリクエストしていない場合には、サポートマネージャ３１０は、関連するプロトコルスタックにパケットを渡して、通常の処理が行われる。なお、パケット発信者又はトンネルの送信元がＭＣＨＡか否かに関する情報は、パス３１２を通じて情報サービス３４０に問い合わせを行ってもよい。
【００６９】
また、図４には、本発明の実施の形態におけるＭＳＨＡ１５０に必要な機能を実現するための構成の別の一例が図示されている。図４に図示されている構成では、サポートマネージャ３１０は、オーバレイネットワークプロトコル処理部３２０とモバイルＩＰｖ６処理部３３０の両方のプロトコルの上位に位置している。なお、機能に関しては上述のものと同様であるが、サポートマネージャ３１０は、本発明に係る特有のメッセージを受信できるようにするため、オーバレイネットワークプロトコル処理部３２０及びモバイルＩＰｖ６処理部３３０に対して登録を行っておく必要がある。
【００７０】
なお、サポートマネージャ３１０、オーバレイネットワークプロトコル処理部３２０、モバイルＩＰｖ６処理部３３０の配置は任意であってよい。すなわち、例えば、サポートマネージャ３１０が、モバイルＩＰｖ６処理部３３０の上位であって、かつオーバレイネットワークプロトコル３２０の下位に位置してもよく、また、その逆でもよい。
【００７１】
また、図５には、本発明の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャートが図示されている。図５において、ＭＳＨＡはパケットを受信すると、まず、メッセージのパケットのタイプを判断する（ステップＳ５００）。なお、ここでは、受信パケットがモバイルノードからのバインディングアップデートの場合（遷移Ｔ５０５）、受信パケットがモバイルノードあてのデータパケットの場合（遷移Ｔ５０６）、受信パケットがその他のタイプのパケットの場合（遷移Ｔ５０７）について説明する。
【００７２】
受信したメッセージがモバイルノードからのバインディングアップデートの場合（遷移Ｔ５０５、ステップＳ５１０）には、ＭＳＨＡは、そのモバイルノードがＭｏｎａｍｉ６機能をリクエストしているか否かをチェックする（ステップＳ５２０）。なお、このチェックは、モバイルノードや情報サービス３４０、あるいはその他のＭＣＨＡなどに問い合わせるなど、任意の方法で実現可能である。
【００７３】
ステップＳ５２０でモバイルノードがＭｏｎａｍｉ６機能をリクエストしている場合には、ＭＳＨＡは、Ｍｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェント２１０の設定を行って、そのモバイルノードのバインディングキャッシュエントリのアップデートを行う（ステップＳ５３０）。そして、ＭＳＨＡは、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されるＭＣＨＡに対して、このメッセージのパケットを転送する処理を行う（ステップＳ５５０）。
【００７４】
一方、ステップＳ５２０でモバイルノードがＭｏｎａｍｉ６機能をリクエストしていない場合には、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なる処理が行われる（ステップＳ５４０）。
【００７５】
また、ＭＳＨＡがモバイルノードあてのデータパケットを受信した場合（遷移Ｔ５０６、ステップＳ５６０）には、まずＭＳＨＡは、パケット発信者又はトンネルの送信元がＭＣＨＡか否かをチェックする（ステップＳ５７０）。ステップＳ５７０でパケット発信者又はトンネルの送信元がＭＣＨＡの場合には、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なるパケット処理が行われる（ステップＳ５４０）。
【００７６】
しかしながら、ステップＳ５７０でパケット発信者又はトンネルの送信元がＭＣＨＡではない場合には、ＭＳＨＡは、そのモバイルノードのバインディングキャッシュエントリをチェックし、モバイルノードがＭｏｎａｍｉ６機能をリクエストしているか否かを判断する（ステップＳ５８０）。モバイルノードがＭｏｎａｍｉ６機能をリクエストしている旨がＭｏｎａｍｉ６フラグフィールド２００にセットされている場合には、ＭＳＨＡは、バインディングキャッシュエントリのターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡに、このパケットを転送する（ステップＳ５９０）。
【００７７】
一方、Ｍｏｎａｍｉ６フィールド２００がセットされていない場合（すなわち、モバイルノードがＭｏｎａｍｉ６機能をリクエストしていない場合）には、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なるパケット処理が行われる（ステップＳ５４０）。また、ＭＳＨＡが受信したパケットがその他のタイプのパケットである場合においても、ＭＳＨＡは、関連するプロトコルにパケットを渡し、そのプロトコルに係る更なるパケット処理が行われる（ステップＳ５４０）。
【００７８】
なお、上述の実施の形態とは異なる別の好適な実施の形態において、ＭＳＨＡがＭｏｎａｍｉ６プロトコルスタックを実装していないが、フローフィルタリングプロトコルを理解することができる場合も考えられる。このような場合においても、オーバレイネットワークにおける最適化が実現可能である。
【００７９】
図６には、本発明の別の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャートが図示されている。なお、図６には、上述のように、フローフィルタリングプロトコルを理解することができるが、Ｍｏｎａｍｉ６プロトコルスタックを実装していないＭＳＨＡの動作の一例が図示されている。以下、図１に図示されているＭＳＨＡ１５０が、図６に係る動作を行うＭＳＨＡである場合を例示しながら説明する。
【００８０】
図１に図示されているネットワーク構成において、ＭＮ１１０は、ＣＮ１９０からのデータパケットがパス１１２経由で送信されるように規定するフローフィルタリングルールの動作をリクエストしているとする。ＭＳＨＡ１５０は、ＣＮ１９０からのＭＮ１１０あてのデータパケットを受信した場合（ステップＳ５００、遷移Ｔ５０６、ステップＳ５６０）には、そのデータパケットに一致するフローフィルタリングルールが存在するか否かをチェックする（ステップＳ６００）。
【００８１】
ステップＳ６００でフローフィルタリングルールが存在している場合には、ＭＳＨＡ１５０は、関連するプロトコル（この場合は、フローフィルタリングプロトコル）にパケットを渡し、更なる処理が行われる（ステップＳ５４０）。
【００８２】
しかしながら、ステップＳ６００で一致するフローフィルタリングルールが見つからなかった場合にはステップＳ５７０に進み、このパケットのパケット送信者又はトンネルの送信元がＭＣＨＡか否かのチェックが行われる。なお、図６に示されているその他の動作は、基本的に図５に示されている動作と同一であり、ここでは説明を省略する。
【００８３】
図６に示す動作で追加されたチェックを実行した場合、データパケットがフローフィルタリングに関連している場合には、ＭＳＨＡはこのパケットをＭＣＨＡに転送する必要はないという利点がある。これにより、不要な待ち時間や、帯域幅の無駄な消費が起こらないようにすることが可能となる。
【００８４】
さらに別の好適な実施の形態において、ＭＳＨＡ１５０は、図７に図示されているように、Ｍｏｎａｍｉ６プロトコルスタックであるＭｏｎａｍｉ６プロトコル処理部７００を実装している場合も考えられる。なお、図７に図示されている構成では、モバイルＩＰ処理部３３０の上位にＭｏｎａｍｉ６プロトコル処理部７００が配置されているが、どの位置に配置される構成であっても、本発明の基本的な概念は適用される。
【００８５】
Ｍｏｎａｍｉ６プロトコル処理部７００が設けられている構成だけでは、Ｍｏｎａｍｉ６機能を実装するＭＣＨＡと同一になると考えられるが、しかしながら、サービスプロバイダが動的にＭｏｎａｍｉ６サービスを有効／無効にするオプションを必要としている場合があり、図７に図示されている構成は、このオプションを実現するために、サポートマネージャ３１０（図３、４を参照）に代わって、スイッチサポートマネージャ７１０が設けられている。このスイッチサポートマネージャ７１０は、サポートマネージャ３１０のすべての機能に加えて、Ｍｏｎａｍｉ６機能の動作の有効／無効の切り換えを行う機能を有している。なお、このＭｏｎａｍｉ６機能の動作の有効／無効の状態は、任意のポリシに基づいて適宜動的に切り換えられてもよい。
【００８６】
なお、図７に図示されているＭＳＨＡ１５０は、Ｍｏｎａｍｉ６機能の動作が無効になった場合には、『ＭＳＨＡ』と呼ぶことはできるが、Ｍｏｎａｍｉ６機能の動作が有効になった場合には、Ｍｏｎａｍｉ６を完全に実装した構成（すなわち、ＭＣＨＡ）となり、『ＭＳＨＡ』と呼ぶことはできない。しかしながら、以下では、説明を容易にするため、常にＭｏｎａｍｉ６機能の動作が有効なＭＣＨＡに対して、図７に図示されている構成を有するＨＡをＭＳＨＡと呼ぶことにする。
【００８７】
以下、図７に図示されているＭＳＨＡ１５０を含むオーバレイネットワークシステムについて説明する。図７に図示されているＭＳＨＡ１５０が存在するオーバレイネットワークシステムでは、例えば、オーバレイネットワークシステム全体において、ＭＳＨＡ１５０のＭｏｎａｍｉ６機能の動作状態が有効か、あるいは無効かを把握できるようにすればよい。これを実現するためには、Ｍｏｎａｍｉ６機能が現在動作しているオーバレイネットワークノードが記載されたグローバルリストを設ければよい。なお、このグローバルリストは、オーバレイネットワークシステム全体の情報の集中管理を行うセントラル情報サービスで管理されてもよく、あるいは、オーバレイネットワーク内のすべてのノードがそれぞれ管理してもよい。
【００８８】
図８には、Ｍｏｎａｍｉ６機能が現在動作しているオーバレイネットワークノードすべてが記載されるグローバルリストをアップデートするために使用されるアップデートメッセージが図示されている。グローバルリストをアップデートするためのアップデートメッセージは、セントラル情報サービスに送信されてもよく、オーバレイネットワーク内のすべてのノードにブロードキャストされてもよい。
【００８９】
なお、図８に図示されているアップデートメッセージは一例であって、適用されるシステムや実施条件によって適宜変更可能である。また、このアップデートメッセージは、例えば、モバイルＩＰやＩＣＭＰ（Internet Control and Management Protocol：インターネット制御管理プロトコル）などの既存のプロトコルのメッセージによって統合されるか、あるいは置き換えられてもよい。
【００９０】
図８に図示されているアップデートメッセージは、タイプフィールド８００、追加フラグフィールド８１０、ホームエージェント識別子フィールド８２０を有している。
【００９１】
図８において、タイプフィールド８００は、このメッセージがアップデートメッセージであることを識別可能とするために使用される。なお、このタイプフィールド８００には、送信者ノード及び受信者ノードの両方によって理解される値が設定される。また、追加フラグフィールド８１０は、このアップデートメッセージの送信者ノードが、グローバルリストに自身をＭＣＨＡとして追加するように、あるいはグローバルリストから削除するようにリクエストしていることを示すために使用される。また、ホームエージェント識別子フィールド８２０には、グローバルリストに追加又はグローバルリストから削除されるべきオーバレイネットワークノード（ＭＳＨＡ１５０自身）を特定するためのホームエージェント識別子やアドレス情報などが含まれる。
【００９２】
スイッチサポートマネージャ７１０は、当該ＭＳＨＡ１５０をＭｏｎａｍｉ６有効状態からＭｏｎａｍｉ６無効状態に切り換えるように指示を受けた場合には、Ｍｏｎａｍｉ６機能が現在動作しているオーバレイネットワークノードのグローバルリストから自身を削除するために、まず、グローバルリストからの削除をリクエストするアップデートメッセージの送信を行う。なお、アップデートメッセージの送信によるグローバルリストからの削除は、オーバレイネットワークシステムにおいて迅速かつ確実に行われる。
【００９３】
さらに、ＭＳＨＡ１５０では、Ｍｏｎａｍｉ６機能をリクエストしているモバイルノードに関するバインディングキャッシュに含まれるすべてのエントリを検査して、例えばＭｏｎａｍｉ６機能をリクエストしているモバイルノードのパケットを適切なＭＣＨＡに転送できるようにするなど、Ｍｏｎａｍｉ６フラグフィールド２００やターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に適切な値を付与する必要がある。この結果、Ｍｏｎａｍｉ６サービスはシームレスに無効化される。
【００９４】
一方、スイッチサポートマネージャ７１０は、当該ＭＳＨＡ１５０をＭｏｎａｍｉ６無効状態からＭｏｎａｍｉ６有効状態に切り換えるように指示を受けた場合には、まず、ホームエージェントに管理されているモバイルノードがＭｏｎａｍｉ６機能をリクエストしているか否かを特定する必要がある。これは、スイッチサポートマネージャ７１０が、Ｍｏｎａｍｉ６フラグフィールド２００がセットされているモバイルノードすべてのバインディングキャッシュエントリを検査することによって実現される。
【００９５】
そして、Ｍｏｎａｍｉ６機能をリクエストしているモバイルノードが特定されると、スイッチサポートマネージャ７１０は、これらのモバイルノードの関連するエントリにおいて、例えば、他のＭＣＨＡではなく、当該ＭＳＨＡ１５０自身でパケットの処理を行う旨を記載する。このバインディングキャッシュエントリのアップデートは、通常の周期的なアップデートを待って行われてもよく、情報サービス３４０のエンティティによって行われてもよい。なお、情報サービス３４０のエンティティから取得できる情報は、クエリ／レスポンスのメカニズムによって様々である。そして、すべての関連エントリがアップデートされると、スイッチサポートマネージャ７１０は、図８に図示されているアップデートメッセージをグローバルネットワーク１００に送信し、グローバルリストに自身を追加する。この結果、Ｍｏｎａｍｉ６サービスはシームレスに有効化される。
【００９６】
さらに、この切り換えは、当該ＭＳＨＡの管理するすべてのＭＮ登録について一括にＭｏｎａｍｉ６サービスの有効化／無効化を設定するだけでなく、部分的に一部のＭＮ登録に関しては有効、他のＭＮ登録に関しては無効とすることもできる。これは、複数ＣｏＡの登録領域やフローの管理が当該のＭＳＨＡにおいて肥大化したときに、他のＭＣＨＡに対して、処理負荷が多い分だけの管理を依頼する形となるため、受け入れるＭＣＨＡ側において自身の処理負荷が突然処理限界に達してしまうというようなことを避けることができる。
【００９７】
上述の本発明の各実施の形態では、ネットワーク上に配置されている装置（主にＭＳＨＡ）に機能が追加されることで本発明の動作が実現されているが、さらにモバイルノードの機能を拡張することによって、本発明の動作がシームレスに行われるようにすることも可能である。
【００９８】
図１において、モバイルノードは、複数の気付アドレスを登録するバインディングアップデートメッセージを送信し、このバインディングアップデートメッセージは、ＭＳＨＡによって受信（intercept）される。このとき、ＭＳＨＡは、上述の動作（図５に図示）に加えて、モバイルノードがＭｏｎａｍｉ６のサービスを最適なインタフェースで受けているか否か（例えば、ＭＣＨＡではなくＭＳＨＡに接続しているためにパケットがいったんＭＣＨＡに転送される場合があることなど）を判断し、最適なインタフェースが使用されていない場合には、その旨を通知するための通知メッセージをモバイルノードに送信する付加的な動作を行うことが可能である。
【００９９】
また、モバイルノードは、この通知メッセージを受信した際に、この通知メッセージを理解してＭｏｎａｍｉ６のサービスを最適なインタフェースで受けていない旨を把握する拡張機能を有している。モバイルノードは、通知メッセージによってＭｏｎａｍｉ６のサービスを最適なインタフェースで受けていない旨を把握した場合には、別のネットワーク（別のインタフェース）を選択してＭｏｎａｍｉ６のサービスをリクエストしてもよい。なお、このリクエストは、（別のインタフェースから再度送信される）複数の気付アドレスを登録するバインディングアップデートメッセージの送信により行われてもよいし、Ｍｏｎａｍｉ６のサービスを最適な状態で提供してほしい旨のリクエストを明示的に送信してもよい。
【０１００】
なお、ＭＳＨＡは、任意の判断基準を通知メッセージの送信トリガとすることが可能であり、また、通知メッセージを任意のモバイルノードに送信してもよい。例えば、ＭＳＨＡの管理者があらかじめポリシを設定しておき、このポリシに従って、ＭＳＨＡは、通知メッセージの送信を行うようにしてもよい。
【０１０１】
また、ＭＳＨＡは、通知メッセージの送信を決定する前に、そのモバイルノードの複数の気付アドレスの登録をチェックして、接続の切り換えが可能な代替ドメイン（最適なネットワーク）が存在するか否かを確認してもよい。このとき、例えばサポートマネージャ３１０は、必要な情報を取得するため、ローカル又はリモートの情報サービス３４０に問い合わせを行ってもよい。また、モバイルノードに適したＭＣＨＡに関する問い合わせを情報サービス３４０に行ってもよく、この場合、問い合わせに対する応答によって提供されるＭＣＨＡは、ターゲットＭｏｎａｍｉ６実装ホームエージェントフィールド２１０に記載されているＭＣＨＡとは異なるＭＣＨＡとなる場合もある。
【０１０２】
また、ＭＳＨＡのサポートマネージャ３１０は、モバイルノードがバインディングメッセージを送信する際に使用すべきインタフェースを示す推奨情報を通知メッセージによって送ってもよい。
【０１０３】
また、ＭＳＨＡは、モバイルノードがネットワークに接続する際のＡＡＡ（Authentication, Authorization and Accounting：認証、認可、課金）の処理を行う段階で、モバイルノードが所望する複数の気付アドレスの登録方法を聞くことも可能である。この場合、ＭＳＨＡはすぐに通知メッセージを送信し、このネットワークにおけるＭｏｎａｍｉ６サービスが最適な状態ではないことをモバイルノードに通知することが可能であり、これによって、モバイルノードは、必要に応じて、バインディングアップデートメッセージの送信を行わずに別のネットワークへの切り換えを即座に行うことが可能となる。
【０１０４】
また、図９には、ＭＳＨＡからモバイルノードに送信される通知メッセージが図示されている。なお、図９に図示されている通知メッセージは一例であって、適用されるシステムや実施条件によって適宜変更可能である。
【０１０５】
図９に図示されている通知メッセージは、この通知メッセージを受信したインタフェースにおいては、Ｍｏｎａｍｉ６のサービスが最適ではないことをモバイルノードに通知するために使用される。
【０１０６】
図９に図示されている通知メッセージは、タイプフィールド９００、代替推奨フィールド９１０、付加情報フィールド９２０を有している。
【０１０７】
図９において、タイプフィールド９００は、このメッセージが通知メッセージであることを識別可能とするために使用される。なお、このタイプフィールド９００には、送信者ノード及び受信者ノードの両方によって理解される値が設定される。また、代替推奨フィールド９１０には、最適なＭｏｎａｍｉ６のサービスに使用されるべき代替インタフェースを示すことが可能である。また、付加情報フィールド９２０には、モバイルノードがより良いＭｏｎａｍｉ６のサービスを得られるようにするための付加情報を含ませることが可能である。例えば、付加情報フィールド９２０に挿入される付加情報としては、ＭＣＨＡを見つけることが可能なネットワークインタフェースのタイプ、モバイルノードの最も近くに存在するＭＣＨＡのＧＰＳ位置情報やアドレス情報などの様々な情報を用いることが可能である。
【０１０８】
また、通知メッセージは、例えば、バインディングアップデートメッセージに対して返信するバインディングアクノレッジメッセージに挿入されたモビリティオプションの形式で伝搬可能である。この場合には、通知メッセージのタイプフィールド９００は、モバイルＩＰｖ６の規定に従って、８ビットのオプションタイプ識別子の値と８ビットのオプション長の値とを有する。また、代替推奨フィールド９１０には、複数の気付アドレスの登録を送信する際に使用されるべきモバイルノードのインタフェースの気付アドレスが含まれる。また、付加情報フィールド９２０には、モバイルノードで利用可能な他のインタフェースの気付アドレスが含まれていてもよい。
【０１０９】
また、通知メッセージは、例えばＩＥＥＥ８０２．２１に規定されている異種ネットワーク間のハンドオーバを可能とするＭＩＦメディア独立ハンドオーバ機能（ＭＩＨＦ：Media Independent Handover Function）などのような、より低いレイヤの機能によって伝搬されてもよい。この場合には、通知メッセージは、ＩＥＥＥ８０２．２１に定義されている各サービスに基づくイベントやコマンドの形式で送信されてもよい。例えば、通知メッセージが伝搬される形式の一例としては、リンク検出イベントやＭＩＨスイッチコマンドなどが挙げられる。また、この場合には、代替推奨フィールド９１０には、ＩＥＥＥ ＭＡＣ ＩＤのようなインタフェースのレイヤ２における特定の識別子の値が挿入される。
【０１１０】
また、通知メッセージは、アプリケーションレイヤにおいて伝搬されてもよい。この場合には、例えば、モバイルノード及びＭＳＨＡは、通知メッセージ内の各情報フィールドの値を適切な方法で通信することができるカスタマイズされたソフトウェアを実行する。
【０１１１】
また、図１０には、本発明のさらに異なる実施の形態におけるＭＳＨＡの通知メッセージを用いる際の動作の一例を示すフローチャートが図示されている。なお、図５に示すフローチャートと図１０に示すフローチャートとを比較すれば分かるように、図１０に示すフローチャートに係る動作は、図５に示すフローチャートに係る動作に対して、ステップＳ１０１０、Ｓ１０２０の２つのステップのみが追加されたものである。以下では、主に、図１０に示すフローチャートに係る動作で追加されたステップについて説明する。
【０１１２】
ステップＳ５２０でモバイルノードがＭｏｎａｍｉ６機能をリクエストしている場合には、ＭＳＨＡは、通知メッセージを送信すべきか否かの判断を行う（ステップＳ１０１０）。ここでは例えば、モバイルノードが、Ｍｏｎａｍｉ６のサービスを最適な状態で（例えば、適切なネットワークインタフェースを使用して）受けているか否かの判断が行われる。なお、通知メッセージの送信を行う判断基準（送信トリガ）に関しては、任意の条件を用いることが可能である。
【０１１３】
ステップＳ１０１０で通知メッセージを送信する必要がないと判断された場合には、ＭＳＨＡは、ステップＳ５３０に進み、Ｍｏｎａｍｉ６フラグフィールド２００及びターゲットＭｏｎａｍｉ６実装ホームエージェント２１０の設定を行って、そのモバイルノードのバインディングキャッシュエントリのアップデートを行う（ステップＳ５３０）。
【０１１４】
一方、ステップＳ１０１０で通知メッセージを送信する必要があると判断された場合には、ＭＳＨＡは、ステップＳ１０２０に進み、ステップＳ５３０におけるバインディングキャッシュエントリのアップデートを行う前に、Ｍｏｎａｍｉ６のサービスが最適ではないことをモバイルノードに通知するための通知メッセージを適切な方法で生成し、モバイルノードに送信する処理を行う。
【０１１５】
なお、モバイルノードへの通知メッセージは、実際には、ＭＳＨＡではなく、グローバルＨＡＨＡ内の別のエンティティ（グローバルＨＡＨＡネットワークに属する任意のノード）から送信されてもよい。例えば、モバイルノードに通知メッセージを送信するＭＳＨＡとしては、例えば、ネットワークトポロジに関する包括的な知識を持つセントラルエンティティや、グローバルＨＡＨＡで定義されているモバイルノードのプライマリホームエージェントなどが挙げられる。この場合、ＭＳＨＡは、通知メッセージの送信元となるエンティティに対して、必要な情報（モバイルノードの識別子及びモバイルノードから送信された登録データ）を通知する必要がある。この通知方法は任意であるが、例えば、図９に図示されている通知メッセージを拡張したメッセージを用いることが可能である。
【０１１６】
また、図１１には、本発明に係る拡張機能を有するモバイルノードの機能（主に追加された機能）が模式的に図示されている。図１１に図示されているモバイルノードは、Ｍｏｎａｍｉ６のサービスなどを始めとするオーバレイネットワークサービスに係る機能の利用をネットワークにリクエストするサービスリクエスト部１１０１と、このオーバレイネットワークサービスを適切に受けられない旨を示す通知メッセージをネットワークから受信する通知メッセージ受信部１１０２と、通知メッセージを受信した場合にオーバレイネットワークサービスを受ける方法を変更するサービス利用変更部１１０３とを有している。
【０１１７】
なお、モバイルノードが、ネットワークに接続するための複数のインタフェースを有している場合には、サービス利用変更手段は、ネットワークに接続するためのインタフェースを切り換えることによって、サービスをより適切に受けられるようにすることが可能である。また、通知メッセージの代替推奨フィールド９１０や付加情報フィールド９２０に、モバイルノードがオーバレイネットワークサービスを適切に受けられるようにするための情報が含まれている場合には、サービス利用変更手段は、この情報に基づいて、ネットワークに接続するためのインタフェースを切り換えることが可能である。
【０１１８】
また、モバイルノードがＭＳＨＡに接続していることをオーバレイネットワーク内のノードに通知することにより、ＭＳＨＡの転送先となるターゲットＭＣＨＡを設定する動作を補助することもできる。この場合、モバイルノードがＭＳＨＡから最適なサービス利用ができない旨を通知されることにより、サービスリクエストを送信する。サービスリクエストにはどのＭＳＨＡに対してターゲットＭＣＨＡを設定してほしいかの情報が含まれていることが望ましい。この場合のサービスリクエストは、ＭＣＨＡに接続しているインタフェース（もし存在していれば）から送信されたり、別の方法（ネームサービス、インフォメーションサービス、事前設定など）で知ることのできたセントラルエンティティやプライマリホームエージェントへ送信されたりしてもよく、また、より低いレイヤのメッセージで通知されてもよい。この通知によりオーバレイネットワーク内のどのＭＳＨＡがどのモバイルノードに対してのターゲットＭＣＨＡを必要としているかをオーバレイネットワーク内の他のノードが把握しやすくなる。
【０１１９】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、サポートマネージャ３１０やその他の構成要素に係る設計やパラメータの詳細において、例えば、Ｍｏｎａｍｉ６やフローフィルタリングの機能をＱｏＳ（Quality of Service：サービス品質）保証の機能に置き換えるなど、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。
【０１２０】
また、本明細書では、モバイルノードのネットワークインタフェースが複数であることを前提に説明を行っているが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り換えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。
【０１２１】
また、上述の実施の形態では、オーバレイネットワークがグローバルな構成であることが仮定されているが、ローカルモビリティ管理（Local Mobility Management）の環境に本発明を適用することも可能である。例えば、ローカルモビリティ管理方法の１つであるＰＭＩＰ（Proxy Mobile IP）はＭＡＧ（Mobile Access Gateway）がＬＭＡ（Local Mobility Anchor）に移動端末の移動登録を行うことにより、移動端末に対するモビリティサポートを提供しているが、本明細書におけるＭＣＨＡやＭＳＨＡがＭＡＧに対応する形で適用可能である。この場合、モバイルノードの移動の起点（ある時点を基準とするものであったり（相対的）、ネットワークオペレータへの登録の状態（確定的）であったり、様々な場合があり得る）となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはＬＭＡに対応すると考えることができる。
【０１２２】
また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１２３】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１２４】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１２５】
本発明は、例えば、異なるインターネットサービスプロバイダが協働してオーバレイネットワークを形成する場合のように、異なる機能のオーバレイネットワークノードが混在して存在する環境であっても、モバイルノードが受けようとしている特定のサービスを適切に提供できるようになるという効果を有しており、ＩＰネットワークなどのパケット交換型データ通信ネットワークを抽象化するオーバレイネットワークに関する技術分野に適用可能であり、また、フローフィルタリング技術やＭｏｎａｍｉ６に関する技術に適用可能である。
【図面の簡単な説明】
【０１２６】
【図１】本発明の実施の形態におけるネットワーク構成の一例を示す図
【図２】本発明の実施の形態におけるＭＳＨＡが保持するバインディングキャッシュエントリに追加される情報要素の一例を示す図
【図３】本発明の実施の形態におけるＭＳＨＡに必要な機能を実現するための構成の一例を示すブロック図
【図４】本発明の実施の形態におけるＭＳＨＡに必要な機能を実現するための構成の別の一例を示すブロック図
【図５】本発明の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャート
【図６】本発明の別の実施の形態におけるＭＳＨＡの動作の一例を示すフローチャート
【図７】本発明のさらに別の実施の形態におけるＭＳＨＡに必要な機能を実現するための構成の別の一例を示すブロック図
【図８】本発明のさらに別の実施の形態におけるＭＳＨＡから送信されるアップデートメッセージに含まれる情報要素の一例を示す図
【図９】本発明のさらに異なる実施の形態におけるＭＳＨＡから送信される通知メッセージに含まれる情報要素の一例を示す図
【図１０】本発明のさらに異なる実施の形態におけるＭＳＨＡの動作の一例を示すフローチャート
【図１１】本発明のさらに異なる実施の形態におけるＭＮの拡張機能を模式的に示す図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008114498.tif 000014
【図２】
2008114498.tif 000015
【図３】
2008114498.tif 000016
【図４】
2008114498.tif 000017
【図５】
2008114498.tif 000018
【図６】
2008114498.tif 000019
【図７】
2008114498.tif 000020
【図８】
2008114498.tif 000021
【図９】
2008114498.tif 000022
【図１０】
2008114498.tif 000023
【図１１】
2008114498.tif 000024
【国際調査報告】
2008114498.tif 000025
2008114498.tif 000026
2008114498.tif 000027
2008114498.tif 000028
2008114498.tif 000029
2008114498.tif 000030