JP4937270B2 - 通信経路最適化方法及び通信経路最適化制御装置 - Google Patents

Description

本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に関し、特に、モバイルＩＰｖ６において規定されている経路最適化（ＲＯ：Route Optimization）に係る技術に関する。

現在、多数のデバイスが、ＩＰネットワークを使用して、相互に通信を行っている。モバイル機器にモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）では、ＩＰｖ６におけるモビリティサポート（ＭＩＰｖ６：Mobile IPv6）の開発が進められている。モバイルＩＰでは、各モバイルノードは、永続的なホームドメインを持っている。モバイルノードが、自身のホームネットワークに接続している場合、モバイルノードには、ホームアドレス（ＨｏＡ：Home Address）として知られるプライマリグローバルアドレスが割り当てられる。一方、モバイルノードがホームネットワークから離れている場合、すなわち、他のフォーリンネットワークに接続している場合には、通常、モバイルノードには、気付アドレス（ＣｏＡ：Care-of Address）として知られる一時的なグローバルアドレスが割り当てられる。モビリティサポートの考えは、モバイルノードが他のフォーリンネットワークに接続している場合でも、自身のホームアドレスで、そのモバイルノードまで到達可能となるようにするものである。

このような考えは、下記の非特許文献１において、ホームエージェント（ＨＡ：Home Agent）として知られるエンティティを、ホームネットワークに導入することによって実践されている。モバイルノードは、バインディングアップデート（ＢＵ：Binding Update）として知られるメッセージを使用して、ホームエージェントへの気付アドレスの登録を行う。これにより、ホームエージェントは、モバイルノードのホームアドレスと気付アドレスとの間のバインディングを生成することが可能となる。ホームエージェントは、モバイルノードのホームアドレスに向けられたメッセージを受信（intercept）し、パケットのカプセル化（あるパケットを新たなパケットのペイロードとすることであり、パケットトンネリングとしても知られている）を用いて、そのパケットをモバイルノードの気付アドレスに転送する機能を担っている。

一方、無線デバイスの台数の増加はさらに加速しており、モビリティ技術において、新たな技術分野（class）が現れるであろうことが予想される。その１つが、ノードを含むネットワーク全体が、そのまま接続ポイントを変えるネットワークモビリティ（すなわち、ＮＥＭＯ）である。これは、個々のホスト用のモビリティサポートの概念を、ノードを含むネットワーク用のモビリティサポートに拡張した場合に、移動を行うネットワークに係る解決策として、モバイルネットワークがインターネットに対してどの接続ポイントで接続している場合でも、プライマリグローバルアドレスでモバイルネットワーク内のノードに到達可能とすることができる機構の提供を目的としている。

ＩＥＴＦでは、現在、下記の非特許文献２に記載されているように、ネットワークモビリティに対する解決策が提案されている。ここでは、モバイルルータがホームエージェントに対してＢＵを送信する際に、モバイルルータによって、モバイルネットワーク内のノードが使用しているネットワークプリフィックスが指定される。このネットワークプリフィックスは、ＢＵに挿入されるネットワークプリフィックスオプションとして知られる特別なオプションを使用して指定される。これにより、ホームエージェントは、プリフィックスに基づくルーティングテーブルを構築し、その結果、ホームエージェントは、こうしたプリフィックスを有する送信先に送信されるパケットを、モバイルルータの気付アドレスに転送することが可能となる。

また、トンネリング技術を使用することによって、ホームエージェントを利用したホスト及びネットワークモビリティサポートが提供される。しかしながら、これによって、準最適化（サブオプティマル）として知られる問題が生じることとなる。この問題は、モバイルノードが通信相手ノードであるコレスポンデントノード（ＣＮ：Correspondent Node）と通信を行う際、それらの間において送信されるパケットが、モバイルノードからコレスポンデントノードへのダイレクトな経路を経由するのではなく、ホームエージェントを経由しなければならないことにより生じる。モバイルノードがそのホームエージェントから遠く離れている場合には、このような準最適化によって、通信は非効率となり、パケットの遅延が増大する。

上述の状況に基づいて、非特許文献１には、モバイルノードがＢＵをコレスポンデントノードに送信することができる旨が記載されている。コレスポンデントノードが、モバイルノードのホームアドレスと気付アドレスとのバインディングを把握した場合、それらの間で伝送されるパケットは、モバイルノードの気付アドレスに直接送受信される（ホームエージェントを経由せずに）。しかし、これには、コレスポンデントノードによって、モバイルＩＰが理解されてサポートされる必要がある。さらに、モバイルノードが、多数のコレスポンデントノードと通信を行う必要がある場合には、その実行が必要となるバインディングアップデートの回数は、飛躍的に増大する。なお、コレスポンデントノードに対してＢＵを送信するためには、モバイルノードは、ＢＵメッセージの送信に先立って、モバイルノードとコレスポンデントノードとの間で２つの特別なパケット交換を伴うリターンルータビリティ（ＲＲ：Return Routability）処理を実行する必要がある。送信される特別なパケットは、モバイルノードからコレスポンデントノードに送信されるホームテストイニット（ＨｏＴＩ）メッセージ、及び、気付テストイニット（ＣｏＴＩ）メッセージと、ＨｏＴＩメッセージ及びＣｏＴＩメッセージのそれぞれの応答としてコレスポンデントノードから送信されるホームテスト（ＨｏＴ）メッセージ、及び、気付テスト（ＣｏＴ）メッセージである。

上述の問題を解決するため、例えば、下記の特許文献１及び特許文献２には、モバイルＩＰｖ４で定義されているフォーリンエージェントとして知られるエンティティが記載されている。これらの解決策では、コレスポンデントノード自体がモバイルであることが前提とされ、その結果、コレスポンデントノードがフォーリンエージェントの配下に接続する。そして、経路最適化を達成するために、モバイルノードのフォーリンエージェントと、コレスポンデントノードのフォーリンエージェントとの間でトンネルが確立される。しかしながら、これらの解決策はモバイルＩＰｖ４に特有である。モバイルＩＰｖ６では、フォーリンエージェントの概念は存在せず、モバイルＩＰｖ６やネットワークモビリティへのこれらの解決策の適用方法は不明瞭であるが、おそらく、フォーリンエージェントのように機能するエンティティを設ける必要が生じることになる。また、下記の特許文献３や非特許文献３に開示されている解決策も、上述の解決策と類似している。

下記の特許文献３には、モバイルノードがコレスポンデントノードに対して送信したＨｏＴＩメッセージ及びＣｏＴＩメッセージを受信（intercept）するルーティング最適化プロキシが開示されている。ルーティング最適化プロキシは、コレスポンデントノードに代わって、リターンルータビリティ処理を遂行する。

また、非特許文献３には、コレスポンデントルータ（ＣＲ：Correspondent Router）が記載されている。モバイルノードがコレスポンデントノードとの間で経路最適化を実行しようとした場合に、モバイルノードは、最初に、対象となるコレスポンデントノードを取り扱っている（代理している）適切なコレスポンデントルータの発見を試みる。コレスポンデントルータが決定された場合には、モバイルノードは、バインディングアップデートをコレスポンデントルータに送信する。これ以降は、モバイルノードからコレスポンデントノードに送信されるパケットは、コレスポンデントルータにトンネルされ、コレスポンデントルータは、パケットのデカプセル化（decapsulate）を行って、そのパケットをコレスポンデントノードに転送する。また同様に、コレスポンデントノードからモバイルノードに送信されるパケットも、コレスポンデントルータによって受信（intercept）され、コレスポンデントルータは、そのパケットをモバイルノードにトンネルする。なお、非特許文献３で言及されている解決方法は、コレスポンデントルータがトップレベルモバイルルータ（ＴＬＭＲ：Top Level Mobile Router）の位置でリフレクティブＢＵ（reflective BU）を実行することによって、ネスト(nest：入れ子）状態のＭＲに係る問題の解決も試みている。

また、下記の非特許文献４では、ＭＲからＣＲへの経路最適化（ＲＯ）の問題、ネスト状態のＭＲからＣＲへのＲＯの問題、ＭＲが訪問ドメインに存在する場合のＭＲ間のＲＯの問題に関して言及されている。ここでは、経路制御ヘッダ（ＰＣＨ：Path Control Header）がパケットのホップバイホップオプションに挿入されることによって問題の解決が図られている。

非特許文献４に記載の解決方法によれば、トンネルの終点（ＨＡ）が、デカプセル化を行った後、ホップバイホップオプションとしてトンネルの始点のアドレスをパケットに挿入する。ＣＲは、トンネルの始点のアドレスを含むＰＣＨホップバイホップオプションを受信すると、例えばネスト状態のＭＲの場合には、ＰＣＨの最も内側のＭＲのＣｏＡに対してバインディング要求を始動する。

この方法は、ＭＲによる明示的なＣＲの探索が行われず、ＭＲとＣＲとの間で標準のＲＲは実行されないので、非特許文献３に記載の方法とは異なっている。また、この方法では、インフラストラクチャに固定されたＣＲ及びモバイルのＣＲ（ＭＲ）が、ＣＲとして動作してＰＣＨオプションの解釈を行うように構成されている。

また、下記の非特許文献５では、ＭＲは、ＭＲの配下に接続されているローカル固定ノード（ＬＦＮ：Local Fix Node）のプロキシとして動作し、ＣＮとＬＦＮとの間にＲＯを実現するために、ＭＲとＣＮとの間でＭＩＰｖ６に基づくシグナリングが行われる。ここで、ＣＮが、ＭＩＰｖ６に基づくＲＯプロトコルを理解すると仮定すると、ＭＲは、あて先アドレスとしてＣＮのアドレスを使用し、送信元アドレスとしてＭＲのＣｏＡを使用して、ＨｏＴＩメッセージ及びＣｏＴＩメッセージをＣＮに送信する。この解決策は、訪問ドメインに存在するＬＦＮとホームドメインに位置するＣＮとの間に完全な最適化を行うことを目的としている。

また、特許文献４には、少なくとも最初の上流ＭＲを経由して、ＭＮＮとＣＮとの間の通信を最適化する方法が説明されている。この特許文献４には、ＭＲが標準のＲＲ及びＭＲ−ＣＮ間のＢＵ（ＰＳＢＵを用いる）の使用を選択した場合に、ＣＮがＰＳＢＵの検証を行うことが困難であることが記載されている。したがって、この方法では、ＭＮＮが認知することなく透過的な方法で、ＭＲからのバインディングが、ＭＮＮごとにＣＮに行われる。そのため、ＭＲ自身及び接続されているＭＮＮのために、ＭＲが拡張されたＲＲを行い、２つの異なる鍵を統合して、ＭＲからＣＮにＢＵが実行される。ＭＲは、標準ＲＲのホームキー生成トークン、気付アドレスキー生成トークン、ＭＮＮキー生成トークンを含む３つのキー生成トークンによって新たなキーを生成し、このキーをＣＮに対するＢＵによるＭＮＮのアドレス登録のために使用する。なお、標準ＲＲのキー生成トークンは、上述のようなＢＵメッセージの登録用の新たなキーに加えて、標準のキーを生成するために使用される。さらに、この方法は、ネスト状態のＭＲをサポートするために拡張される。その結果、ネスト状態のすべてのＭＲがＣＮへのＢＵを行って、ＣＮはＭＮＮへのツリー経路を推測することが可能となる。また、この方法では、フローごとにＭＮＮからＣＮへのＲＯを実現する方法も示されている。

また、特許文献５には、ＭＲとＣＲとの間の経路最適化が説明されている。なお、特許文献５に開示されている技術は、非特許文献３に記載の技術と同様であるが、ＣＲの探索を行う場合に、より信頼性の高い正式なネームサーバが使用される。このサーバは、ＭＲから要求された特定のＣＮのアドレス用のＣＲを決定する際の支援を行う。その後、ＭＲは、決定されたＣＲに対してＲＲ及びＢＵを行う。ＣＲは、トンネルを設定する前に、サーバを利用して、ＭＲが実際にこのプレフィックスを所有しているか、あるいはプレフィックスの集合を所有していることをチェックする。また、特許文献５に開示されている技術は、システムの動作のために公開鍵暗号化方式（ＰＫＩ：public Key Infrastructure)が必要とされる。基本的に、信頼のあるキーはＣＲとネームサーバとの間や、ＭＲとネームサーバとの間で確立される必要がある。また、ＣＲはシステムのインフラストラクチャにおいては、固定ノードとみなされる。

一方、無線通信の重要性が増しており、今後、数多くのエンドノードがモバイルになることが予想される。例えばＭＨは各自が移動を行い、ＬＦＮはモバイルネットワークに常に接続された状態で移動を行う。このとき、エンドノードは、インターネットのドメイン／サイト／リンクに位置している場合に最適な経路を経由して到達可能となることが要求される。

ホームリンクに存在しながら相互に通信を行う２つのモバイルノードや、ホームリンク／ホームサイト／ホームドメインに位置しながら相互に通信を行う２つの固定ノードに関しては、標準ＩＰｖ６ルーティングによって、最適化された経路を経由するパケット配送が行われるようになるので、特別な問題は生じない。しかしながら、一方又は両方のエンドノードが訪問リンク／訪問サイト／訪問ドメインに位置している場合には、経路最適化方法によって到達可能な状態にすることが必要となり、その処理が行われる必要がある。

また、両方のエンドノードが、ネストが１段階のＶＭＮ（Visiting Mobile Node：訪問モバイルノード）又はモバイルホスト（ＭＨ)の場合には、ＭＩＰｖ６に基づく双方向のＲＲ及びＢＵ／ＢＡによって双方向のＲＯが実現される。なお、２つのエンドノードの両方が１段階のネスト状態にある場合は双方向のＲＯは部分的に行われる。なお、１段階のネスト状態のＶＭＮは、例えば、ＭＲがインターネットに直接接続されている訪問リンク（visited link）上に存在する場合において、このＭＲの配下に接続されているＶＭＮである。

図１には、例えばＮＥＭＯベーシックサポートのような従来の標準プロトコルによってサポートされている経路を経由して、データが発送される場合のフォールバックがついて図示されている。ここでは、訪問ドメイン（visited domain）に存在するＬＦＮ１５０及びＬＦＮ１５１の２つのピアノードが、相互に通信を行おうとしており、他方のピアノードの位置を知らないか、あるいは、お互いがインターネットトポロジ（グローバル通信ネットワーク１００）に対して移動していることを知らないとする。

ここで、ＬＦＮ１５０は、リンク１０３を通じてＭＲ１４０に接続されており、ＭＲ１４０は、アクセスネットワーク１０１を通じてＡＲ（Access Router：アクセスネットワーク）１３０に接続されている。同様に、ＬＦＮ１５１は、リンク１０４を通じてＭＲ１４１に接続されており、ＭＲ１４１は、アクセスネットワーク１０２を通じてＡＲ１３１に接続されている。また、ＡＲ１３０及びＡＲ１３１は、グローバル通信ネットワーク１００（例えばインターネット）に接続されている。また、ＨＡ１２０はＭＲ１４０のホームエージェントであり、ＨＡ１２１はＭＲ１４１のホームエージェントである。

ＬＦＮ１５０がＬＦＮ１５１とデータ通信セッションを開始する場合、ＬＦＮ１５０は、データグラムのあて先アドレスをＬＦＮ１５１のＨｏＡに設定する。ＬＦＮ１５０は単純リンク１６１を通じてＭＲ１４０に接続されているので、パケットは、ＭＲ１４０経由で発送される。

ＭＲ１４０はＮＥＭＯベーシックプロトコルを実装しているので、パケットはカプセル化されて、経路（双方向トンネル）１６０を通じてトンネルされる。そして、ＨＡ１２０においてパケットはデカプセル化され、あて先がＬＦＮ１５１なので、経路（拡張リンク）１６３を経由してＭＲ１４１のホームドメインに発送される。ここで、ＨＡ１２１はパケットを受信（intercept）し、経路（双方向トンネル）１６２を通じてＭＲ１４１のＣｏＡにトンネルする。ＭＲ１４１は、パケットを受信してデカプセル化し、ＬＦＮ１５１に送信する。また、ＬＦＮ１５１がＬＦＮ１５０に応答を送信する場合も、同様の処理が行われる。

この図１に示すシナリオでは、データ経路が長く歪曲しており、さらに、データパケットの経路上の２箇所のインスタンスでトンネリングが行われて、パケットの平均サイズが増加する。したがって、最適化が行われることが望ましいことは明らかである。

また、図２には、本発明が有用である別のシナリオが図示されている。なお、図２には、このようなシナリオにおける従来のプロトコルの欠点が示されている。なお、ここでも、説明のために標準化プロトコルのみに焦点を当てる。

ここでは、ＭＨ１７０がＭＩＰｖ６ ＲＯプロトコルを実装しており、さらに、ＬＦＮ１５１が、ＢＣＥ（Binding Cache Entry：バインディングキャッシュエントリ）を生成してＨｏＴ及びＣｏＴメッセージを送信することによってＲＲをサポートできると仮定する。また、ＭＲ１４１にはＮＥＭＯベーシックサポートプロトコルが実装されていると仮定する。また、このシナリオでは、ＭＨ１７０及びＭＲ１４１は訪問リンクに接続されている。また、このシナリオでは、ＡＲ１３０に直接接続されているピアノード（ＭＨ１７０）が、ＭＲ１４１に接続されているＬＦＮ１５１と通信を行おうとしている。また、このシナリオでは、ＨＡ１２０はＭＨ１７０のホームエージェントであり、ＨＡ１２１はＭＲ１４１のホームエージェントであると仮定する。

ＭＨ１７０がＭＩＰｖ６ ＲＯモジュールを実装していると仮定しているので、ＭＨ１７０は、まずＬＦＮ１５１に対してＲＲ処理を始動する。ＬＦＮ１５１はこのＲＲ処理を部分的にサポートしており、ＭＨ１７０のＣｏＡ及びＨｏＡはＬＦＮ１５１に登録される。ここでＭＨ１７０がデータ通信を開始した場合、ＭＨ１７０は、自身のＣｏＡを使用し、ＨＡ１２０へのトンネルの使用を避ける。しかしながら、ＭＨ１７０は、ピアノード（ＬＦＮ１５１）の位置を把握していないので、パケットはＬＦＮ１５１のホームドメインに発送され、ＨＡ１２１がパケットを受信（intercept）してＭＲ１４１のＣｏＡにトンネルする。そして、ＭＲ１４１はデカプセル化を行って、パケットをＬＦＮ１５１に転送する。

また、ＬＦＮ１５１は、応答データパケットを送信しようとする場合には、自身のＢＣＥをチェックしてＭＨ１７０のＣｏＡを特定する。そして、ＬＦＮ１５１は、ルーティングヘッダタイプ２（ＲＨ２）を使用して、ソースルーティングを行う。ここで、ＭＲ１４１はあて先アドレスを参照する。ＢＣＥ内にＮＥＭＯベーシックサポートユニットをサポートしているエントリ又はＩＰｖ６ルーティングテーブルが存在しないので、ＭＲ１４１は、自身のＨＡ１２１にパケットをトンネルする。ＨＡ１２１はデカプセル化を行って正しいゲートウェイに発送し、最終的に、パケットは標準ＩＰｖ６ルーティングメカニズムによってＭＨ１７０に発送される。

ここで見られる問題は、経路が長く歪曲しており、さらに、パケットの平均サイズを増加させるトンネルが１つ存在しているという点である。

また、図３には、ネストが存在するシナリオが示されている。なお、図３では、従来の標準プロトコルに関する問題が説明される。図３において、ＶＭＮ１７１はＭＲ１４０の配下でネスト状態にあり、ＶＭＮ１７２はＭＲ１４１の配下でネスト状態にある。これら２つのＶＭＮ１７１、１７２が、相互にデータ通信を行おうとしている。ここで、両方のＶＭＮ１７１、１７２にＭＩＰｖ６ ＲＯプロトコルが実装されていると仮定する。また、両方のＭＲ１４０、１４１には、ＮＥＭＯベーシックサポートプロトコルが実装されていると仮定する。また、ＨＡ１２０はＭＲ１４０のＨＡであり、ＨＡ１２１はＭＲ１４１のＨＡである。また、ＭＲ１４０はＡＲ１３０を通じてグローバル通信ネットワーク１００に接続されており、ＭＲ１４１はＡＲ１３１を通じてグローバル通信ネットワーク１００に接続されている。

まず、ＶＭＮ１７１及びＶＭＮ１７２は、標準の双方向のＲＲ、ＢＵ及びＢＡを行い、また、正当な方法によって互いのＨｏＡ及びＣｏＡのバインディングを把握していると仮定する。最初のシグナリングの後、相互にデータを送信する場合には、ＲＨ２が使用される。ＭＲ１４０及びＭＲ１４１は、バインディングキャッシュ又はバインディングリスト（ＢＬ：Binding List）にＶＭＮ１７１、１７２から送信されるデータパケットのあて先アドレスを保持しておらず、それぞれパケットを各自のＨＡ１２０、１２１にトンネルする。その結果、ＶＭＮ１７１から送信されたデータパケットは、単純リンク１６５、双方向トンネル１６６、拡張リンク１６７、別の双方向トンネル１６８、単純リンク１６９を通って、最終的にＶＭＮ１７２に配送される。

双方向のＲＲ、ＢＵ及びＢＡは、プロトコルのシグナリングコストを増大させるので、かなりの量のシグナリングが発生することになる。また、パケットは、一部が最適化された経路を通るので、経路当たりのパケットの平均サイズは、トンネリングによるカプセル化によって増加する。

さらに別のシナリオにおいて、従来の技術に係るプロトコルの問題を理解するため、図４を参照しながら、ネスト状態にあるＶＭＮ１７３が、訪問ドメインに存在するＬＦＮ１５１と通信を行おうとしているシナリオについて説明する。図４において、ＭＲ１４０及びＭＲ１４１はＮＥＭＯベーシックプロトコルを実装しており、エンドホストがＭＩＰｖ６ ＲＯを使用すると仮定する。

片方向のＲＲ、ＢＵ及びＢＡがＶＭＮ１７３とＬＦＮ１５１との間で行われた場合、ＶＭＮ１７３は、自身のＨＡ１２２にデータパケットをトンネルする必要がなくなり、代わって、自身のＣｏＡをすぐに使用することができる。しかしながら、ＭＲ１４０のＢＣＥ、ＢＬ又はルーティングテーブルには、あて先アドレスであるＬＦＮ１５１のアドレスに関するエントリは保持されておらず、データは経路１０を経由してＭＲ１４０のＨＡ１２０にトンネルされる。データはＨＡ１２０でデカプセル化されて、ＭＲ１４１のホームドメインに発送され、経路１１を経由してＭＲ１４１に再びトンネルされる。そして、最終的に、データパケットはＭＲ１４１でデカプセル化されて、ＬＦＮ１５１に到達する。

また同様に、ＬＦＮ１５１は、応答メッセージを送信しようとする場合には、直接ＶＭＮ１７３のＣｏＡに向けて発送する。ＭＲ１４１における経路関連テーブルのエントリでは、あて先アドレスは特定されないので、パケットはＨＡ１２１を経由してトンネルされた後、最終のあて先であるＶＭＮ１７３に到達する。

このシナリオでは、ＭＩＰｖ６ ＲＯプロトコル及びＮＥＭＯベーシックサポートプロトコルを使用した場合に、データパケットの経路が長く歪曲することが示される。
Keiichi Shimizu and Yusuke Kinoshita, “Route Optimization Method and Agent Apparatus”, US Patent Application 20020009066A1, 29 May 2001. Jarno Rajahalme, “Route Optimizing Mobile IP Providing Location Privacy”, WO 2004/010668, 19 July 2002. Cedric Westphal, “Routing Optimization Proxy in IP Networks”, US Patent Application 20040095913A1, 20 Nov 2002. Alexis Oliverau, Christophe Janneteau and Alexandru Petrescu "A Method of Validated Communication", WO 2005/015853 A1, 17 Feb 2005. Marco Molteni, Pascal Thubert and Patrick Wetterwald "Arrangement for Retrieving Routing Information for Establishing a Bidirectional Tunnel between a Mobile Router and a Correspondent Router", WO 2004/104740 A2, 2 Dec 2004. Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force (IETF) Request For Comments (RFC) 3775, June 2004. Devarapalli, V., et. al., "NEMO Basic Support Protocol", Internet Engineering Task Force (IETF) Request For Comments (RFC) 3963, January 2005. Ryuji Wakikawa and Masafumi Watari, "Optimized Route Cache Protocol", IETF Internet Draft: draft-wakikawa-nemo-orc-00.txt, Work-In-Progress, July 2004. J. Na, S. Cho, C. Kim, S. Lee, H. Kang and C. Koo, "Route Optimization Scheme based on Path Control Header", IETF Internet Draft: draft-na-nemo-path-control-header-00.txt, April 2004. C. Bernardos, M. Bagnulo, M. Calderon and I. Soto, "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", IETF Internet Draft: draft-bernardos-nemo-miron-00.txt, Expires January 12, 2006. C. Ng and J. Hirano, "Securing Nested Tunnels Optimization with Access Router Option", IETF Internet Draft: draft-ng-nemo-access-router-option-01.txt, Expired January 10, 2005.

しかしながら、上述した特許文献３に開示されている解決策は、コレスポンデントノードが送信先アドレスの変更を行う必要があり、現在のモバイルＩＰｖ６の仕様において、どのように動作するかが不明瞭である。すなわち、ここでは、コレスポンデントノードは、依然として、例えばバインディングキャッシュエントリ（ＢＣＥ）などの必要なデータ構造と共に、経路最適化手続きの機能性を実現していなければならないことが暗示されている。また、コレスポンデントノード自体がモバイルな場合に、この開示されている解決策がどのように動作するかに関しても不明瞭である。

また、上述した非特許文献３に開示されている解決策は、簡単な方法で経路最適化を提供するものであるが、考慮すべき問題がいくつか存在する。第１に、ここでは、モバイルノードがコレスポンデントルータを発見する必要があるので、モバイルノードの負荷が増大するという問題がある。第２に、モバイルノードがマルチキャストアドレスを使用してコレスポンデントルータを発見するため、最適なコレスポンデントルータが選択される保証がないという問題がある。第３に、モバイルノードが、選択されたコレスポンデントルータが悪意あるノードではなく、本当に、正当なコレスポンデントルータであることをどのようにして検証するかに関して、全く言及されていないという問題がある。第４に、コレスポンデントルータは、コレスポンデントノードのホームアドレスと共通するプレフィックスを有しているので、コレスポンデントノードがホームリンクに存在しない場合は、この最適化の解決方法は有効ではないという問題がある。なお、ほとんどホームリンクに位置しているコレスポンデントノードに関しては、この解決方法は適切である。

また、非特許文献４に開示されている解決策では、ＰＣＨを使用することでＭＲ間のＲＯが行われるが、いくつかの問題が存在する。第１に、このプロトコルは必要時に動作するオンデマンドプロトコルであるが、経路上に存在する多数のＣＲによって、このオプションを検出してオプションに含まれるＣｏＡとの間でＲＯトンネルが生成される。しかしながら、ＣＲドメイン内のすべてのノードがＭＲ配下のモバイルネットワークノード（ＭＮＮ）との通信を必要としているわけではないので、この処理が無駄な場合もあるという問題がある。第２に、ＭＲからＣＲへのバインディングには、ＲＲや同様のセキュアな方法は使用されないという問題がある。第３に、ＰＣＨによるトンネルの始点のアドレスの伝送は、すべてのフローごとにパケット単位で行われ、その結果、多大なシグナリングのコストを要することになるという問題がある。第４に、非特許文献３と同様、ＭＲはＣＲに対してプレフィックス範囲バインディングアップデート（ＰＳＢＵ：prefix scoped binding update）を使用するが、ＣＲは、ＭＲが本当にこのプレフィックスを所有しているか否かを把握できないので、セキュリティ上の問題が発生する可能性がある。第５に、経路上のすべてのルータやノードがＰＣＨホップバイホップオプションを調べるので、処理コストや処理遅延が増大するという問題がある。

また、非特許文献５に開示されている解決策に関しても、下記のような問題がいくつか存在する。第１に、ＭＲがＬＦＮから送信されるすべてのデータパケットを検査して、送信元アドレスをＭＲのＣｏＡに変更する必要があるという問題がある。第２に、ＭＲはＬＦＮへのすべてのデータパケットを受信及び検査して、あて先アドレスをＬＦＮのホームアドレスに変更するとともに、ＣＮで付加されたＲＨタイプ２（ルーティングヘッダタイプ２）を除去する必要があるという問題がある。第３に、この方法は、ＣＮがホームドメインに存在する場合にのみ完全な経路最適化が行われるという問題がある。第４に、このＲＯはＬＦＮのためだけに行われるものであり、ＭＲは、ＬＦＮとＶＭＮとを区別する必要があるという問題がある。

また、特許文献４に開示されている技術では、ＣＮがホームドメインに存在しないときに双方向のＲＲが必要となり得るケースに関しては精査されていない。また、特許文献４に開示されている技術では、ＣＮが、拡張されたＲＲを実行するために複雑な機能を実装する必要があるという問題もある。

また、特許文献５に開示されている技術では、ＣＮが訪問ドメインに存在する場合には、正式なネームサーバがＣＮ用のＣＲを決定することが不可能であるという問題がある。さらに、関連するルータと正式なネームサーバとの間でセキュリティのあるインフラストラクチャが設定されるように、多量のシグナリングや手動設定が前もって行われる必要があるという問題がある。

また、上述のように、図１〜図４には、ピアノードがネストのレベルが小さい状態で訪問ドメインに存在している場合において、標準のモビリティ関連ＲＯプロトコルやモビリティベーシックサポートプロトコルが使用された場合の経路最適化に係る基本的な問題が示されている。

従来の技術によれば、一方のエンドノードが訪問リンク／訪問サイト／訪問ドメインに位置しており、他方のエンドノードがホームリンク／ホームサイト／ホームドメインに存在している場合に、ＲＯが行われる場合の解決策は多数提案されている。しかしながら、両方のエンドノードが訪問リンク／訪問サイト／訪問ドメインに位置する場合や、エンドノードの一方がローカルに固定されたノード（ＬＦＮ：Local Fixed node）（なお、ＭＲの配下に接続が固定されているローカルモバイルノード（ＬＭＮ：Local Mobile Node）もＬＦＮに含まれるものとする）の場合に生じ得る、セキュアな双方向のＲＯを実現しようとするときの課題に言及している解決策は存在しない。

上述の問題に鑑み、本発明は、自身のホームを離れている２つのエンドノードがデータ通信を行う場合に、このデータ通信の経路を最適化できるようにすることを目的とする。

上記の目的を達成するため、本発明の通信経路最適化方法は、第１通信ノードと、モバイルルータの配下に存在する第２通信ノードとの間で行われる通信の経路を最適化する通信経路最適化方法であって、
前記第１通信ノードが、前記第２通信ノードに送信するパケットのヘッダに、前記通信の経路を最適化するために使用される情報を含む所定のあて先オプションを挿入するステップと、
前記モバイルルータのホームエージェントが、前記第１通信ノードから前記第２通信ノードに送信される前記パケットを受信するステップと、
前記モバイルルータの前記ホームエージェントが、前記パケットを前記モバイルルータにトンネルするために前記パケットのカプセル化を行うとともに、前記所定のあて先オプションをコピーして、トンネルパケットヘッダに前記所定のあて先オプションを挿入するステップとを、
有する。
これにより、モバイルルータは、第１通信ノードが第２通信ノードとの間で経路最適化を行おうとしていることを把握し、第１通信ノードとモバイルルータとの間において経路最適化処理の実行が可能となる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記モバイルルータが、前記トンネルパケットヘッダに前記所定のあて先オプションが存在している前記パケットを検出するステップと、
前記モバイルルータが前記第１通信ノードに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報が含まれる応答メッセージを送信するステップと、
前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うステップと、
前記第１通信ノード又は前記モバイルルータは、前記第１通信ノードと前記モバイルルータとの間で送信される前記パケットを、前記経路最適化によって最適化された経路を通るように発送するステップとを、
有する。
これにより、第１通信ノードとモバイルルータとの間の経路が最適化されるようになる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記第１通信ノードが、前記モバイルルータとは異なる別のモバイルルータであって、前記第２通信ノードと通信を行う配下の第３通信ノードを検出した場合に、前記第２通信ノードと前記第３通信ノードとの間の通信経路を最適化するために、前記モバイルルータとの間で経路最適化を行う。
これにより、第２通信ノードと第３通信ノードとの間の通信経路を、それぞれの上位に存在するモバイルルータのホームエージェントに転送されないように最適化することが可能となる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記第１通信ノードが、前記所定のあて先オプションが挿入される前記パケットとして、前記第２通信ノードとの間で経路最適化を行うためのメッセージに係るパケットを使用する。
これにより、従来のＲＲ処理で使用されているメッセージを利用して、シグナリングメッセージの増加を抑えることが可能となる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記モバイルルータが前記第１通信ノードに対して、前記第２通信ノードとの間で経路最適化を行うための前記メッセージに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報が含まれる応答メッセージを送信するステップを有する。
これにより、第１通信ノードから第２通信ノードに対して送信されたメッセージの受信時に、モバイルルータが第１通信ノードとの間の通信経路の最適化を行うための応答メッセージを送信することが可能となる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記第１通信ノードが、自身のホームから離れているモバイルノードであって、前記所定のあて先オプションに自身のホームアドレスを挿入するとともに、前記所定のあて先オプションが挿入される前記パケットの送信元アドレスに自身の気付アドレスを設定する。
これにより、モバイルルータは、パケットのあて先アドレスから第２通信ノードのアドレスを把握するとともに、所定のあて先オプションから第１通信ノードのホームアドレスを把握できるようになる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記第１通信ノードが、自身のホームから離れているモバイルノードであって、前記所定のあて先オプションに暗号鍵を挿入するとともに、前記所定のあて先オプションが挿入されるパケットの送信元アドレスに自身のホームアドレスを設定する。
これにより、モバイルルータは、パケットのあて先アドレスから第２通信ノードのアドレスを把握するとともに、パケットのあて先アドレスから第１通信ノードのホームアドレスを把握し、さらに、所定のあて先オプションから暗号鍵を取得できるようになる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記モバイルルータが、前記トンネルパケットヘッダに前記所定のあて先オプションが存在しているパケットを検出するステップと、
前記モバイルルータが、前記暗号鍵を用いて検証用情報を生成するステップと、
前記モバイルルータが前記第１通信ノードに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報及び前記検証用情報が含まれる応答メッセージを送信するステップとを、
有する。
これにより、暗号鍵及びその暗号鍵を利用した検証用情報の伝送によって、よりセキュアな経路最適化処理を実現することが可能となる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記モバイルルータは、ホームリンクに接続されている場合には、自身が管理するモバイルネットワークの外部から到来するパケットの所定のあて先オプションを調べるステップと、
前記パケットの前記所定のあて先オプション内に含まれているアドレスのプレフィックスが前記モバイルルータの管理するプレフィックスと一致した場合には、前記モバイルルータが前記応答メッセージを送信するステップとを、
有する。
これにより、モバイルルータがホームリンク上に存在する場合であっても、第１通信ノードと第２通信ノードとの間の経路最適化が適切に行われるようになる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記パケットを転送するすべてのモバイルルータが、前記所定のあて先オプションを含む前記パケットを転送する際に、前記第１通信ノードに対して応答メッセージを送信するステップと、
前記第１通信ノードが各モバイルルータからの前記応答メッセージに基づいて、前記第２通信ノードまでの経路を推測するステップとを、
有する。
これにより、第１通信ノードは、第２通信ノードまでのツリー経路上に存在するモバイルルータを把握できるようになる。

さらに、本発明の通信経路最適化方法は、上記の通信経路最適化方法に加えて、前記第１通信ノードが、前記パケットのヘッダに、前記所定のあて先オプションを１回コピーすることが可能な旨を示す情報を挿入するステップと、
前記パケットを最初に受信した任意のモバイルルータのホームエージェントが、前記パケットを前記任意のモバイルルータにトンネルするために前記パケットのカプセル化を行うとともに、前記所定のあて先オプションをコピーして、トンネルパケットヘッダに前記所定のあて先オプションを挿入し、さらに前記トンネルパケットヘッダに前記所定のあて先オプションのコピーを禁止する旨を示す情報を挿入するステップと、
デカプセル化の後に、前記所定のあて先オプションを１回コピーすることが可能な旨を示す情報が前記ヘッダに挿入された前記パケットを転送する前記モバイルルータが、前記第１通信ノードに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報が含まれる応答メッセージを送信するステップとを、
有する。
これにより、第１通信ノードは、任意の通信相手ノードの最も近くに存在する上流モバイルルータから応答メッセージを受信して、この上流モバイルルータの存在を把握することが可能となる。

また、上記の目的を達成するため、本発明の通信経路最適化制御装置は、モバイルノードに実装される通信経路最適化制御装置であって、
通信相手ノードとの間で経路最適化を行うためのメッセージに係るパケットのヘッダに、前記通信ノードと前記通信ノードとの間で行われる通信の経路を最適化するために使用される情報として、前記モバイルノード自身のホームアドレス又は暗号鍵を含む所定のあて先オプションを挿入するように構成されている。
この構成により、モバイルノードは、例えば、通信相手ノードがモバイルネットワーク内の通信ノードであっても、通信相手ノードの上位のモバイルルータとの間で経路最適化を実行することが可能となる。

また、上記の目的を達成するため、本発明の通信経路最適化制御装置は、モバイルルータに実装される通信経路最適化制御装置であって、
前記モバイルルータ自身の配下に接続されている通信ノードと通信相手ノードとの間の通信を検出し、前記通信相手ノードとの間で経路最適化を行うためのメッセージに係るパケットのヘッダに、前記通信ノードと前記通信ノードとの間で行われる通信の経路を最適化するために使用される情報として、前記モバイルルータ自身のホームアドレス又は暗号鍵を含む所定のあて先オプションを挿入するように構成されている。
この構成により、モバイルルータは、例えば、通信相手ノードがモバイルネットワーク内の通信ノードであっても、配下のモバイルネットワーク内の通信ノードと通信相手ノードとの間の通信の経路を最適化するために、通信相手ノードの上位のモバイルルータとの間で経路最適化を実行することが可能となる。

さらに、本発明の通信経路最適化制御装置は、上記の通信経路最適化制御装置に加えて、
前記所定のあて先オプションが挿入された前記パケットを前記通信相手ノードに送信し、前記通信相手ノードに前記パケットが到達するまでに経由するモバイルルータから、前記パケットに対する応答メッセージを受信することによって、前記第２通信ノードまでの経路を推測するように構成されている。
この構成により、モバイルノードは、任意の通信相手ノードまでのツリー経路上に存在するモバイルルータを把握できるようになる。

さらに、本発明の通信経路最適化制御装置は、上記の通信経路最適化制御装置に加えて、
前記所定のあて先オプションが挿入された前記パケットのヘッダに、前記パケットをカプセル化する際にカプセル化ヘッダに前記所定のあて先オプションを１回のみコピーすることが可能な旨を示す情報を付加して、前記通信相手ノードに送信するように構成されている。
この構成により、モバイルノードは、任意の通信相手ノードの最も近くに存在する上流モバイルルータから応答メッセージを受信して、この上流モバイルルータの存在を把握することが可能となる。

また、上記の目的を達成するため、本発明の通信経路最適化制御装置は、モバイルルータに実装される通信経路最適化制御装置であって、
前記モバイルルータ配下の通信ノードに転送すべきカプセル化されたパケットのトンネルパケットヘッダに、経路最適化に使用される情報を含む所定のあて先オプションが挿入されている場合には、前記パケットの送信元に対して、前記モバイルルータ自身のホームアドレス、及び、前記モバイルルータ配下の前記通信ノードのアドレスを含む応答パケットを送信するように構成されている。
この構成により、モバイルルータは、所定のあて先オプションが挿入されているパケットを検出した場合、このパケットの送信者との間で経路最適化を実行することが可能となる。

さらに、本発明の通信経路最適化制御装置は、上記の通信経路最適化制御装置に加えて、
前記モバイルルータ自身がホームリンクに接続されている場合には、前記モバイルルータ自身が管理するモバイルネットワークの外部から到来するパケットに含まれる所定のあて先オプションを調べ、前記パケットの前記所定のあて先オプション内に含まれているアドレスのプレフィックスが前記モバイルルータの管理するプレフィックスと一致した場合には、前記応答メッセージを送信するように構成されている。
この構成により、モバイルルータがホームリンク上に存在する場合であっても、第１通信ノード（モバイルネットワークの外部に存在）と第２通信ノード(モバイルネットワークの内部に存在)との間の経路最適化が適切に行われるようになる。

さらに、本発明の通信経路最適化制御装置は、上記の通信経路最適化制御装置に加えて、
前記所定のあて先オプションを含む前記パケットを転送する際に、前記パケットの送信元に対して応答メッセージを送信するように構成されている。
この構成により、モバイルノードは、任意の通信相手ノードまでのツリー経路上に存在するモバイルルータを把握できるようになる。

また、上記の目的を達成するため、本発明の通信経路最適化制御装置は、モバイルルータのホームエージェントに実装される通信経路最適化制御装置であって、
前記モバイルルータにトンネルすべきパケットのヘッダに、経路最適化に使用される情報を含む所定のあて先オプションが挿入されている場合には、前記モバイルルータにトンネルするために前記パケットのカプセル化を行うとともに、前記所定のあて先オプションをコピーして、トンネルパケットヘッダに前記所定のあて先オプションを挿入するように構成されている。
この構成により、パケットのカプセル化が行われた場合でも、第１通信ノードによって挿入された所定のあて先オプションがトンネルパケットヘッダに配置されるようになり、トンネルの出口に位置するモバイルルータは、第１通信ノードが第２通信ノードとの間で経路最適化を行おうとしていることを把握することが可能となる。

さらに、本発明の通信経路最適化制御装置は、上記の通信経路最適化制御装置に加えて、
前記所定のあて先オプションと共に、前記所定のあて先オプションを１回のみコピーすることが可能な旨を示す情報が付加されているパケットを受信した場合、前記パケットをカプセル化する際に、前記トンネルパケットヘッダに前記所定のあて先オプションをコピーするとともに、前記トンネルパケットヘッダに前記所定のあて先オプションのコピーを禁止する旨を示す情報を付加するように構成されている。
この構成により、モバイルノードによってパケットに付加された所定のあて先オプションは、任意の通信相手ノードの最も近くに存在する上流モバイルルータに対してのみ伝送され、この上流モバイルルータからの応答メッセージを受信することによって、この上流モバイルルータの存在を把握することが可能となる。

本発明は、上記の構成を有しており、自身のホームを離れている２つのエンドノードがデータ通信を行う場合に、このデータ通信の経路を最適化することができるという効果を有している。

以下、図面を参照しながら、本発明の実施の形態において説明する。なお、以下に説明する本発明の実施の形態では、本発明を開示するために最良と思われるいくつかのシナリオについて説明を行う。

本発明は、基本的に、訪問リンク／サイト／ドメインに存在している２つのエンドノード間で通信が行われる場合の双方向のＲＯに関する技術である。なお、エンドノードがＶＭＮである場合に、ネストが発生していないか、ネストが１段階であることが望ましいが、より高次のネストが発生している場合においても、本発明に係る適切なＣＲの特定及び経路の最適化という特徴は実現可能である。

まず、図５を参照しながら、本発明を実現するＭＨの機能アーキテクチャについて説明する。図５には、スタックのレイヤ３のプロトコルを実現する新たなルーティングユニットモジュールが図示されている。この新たなルーティングユニットモジュールを、可動ＣＲ−ＲＯモジュール（Movable CR-RO module）３０５と呼ぶことにする。なお、新たなＲＯプロトコルに関しては、別の実施の形態において詳細に説明を行う。

ここで、新たなＲＯユニットは、主に、ピアノードが訪問ドメインに存在する場合にＲＯを提供するように設計されているとする。この機能アーキテクチャでは、上位レイヤプロトコル３０１は、ユーザアプリケーション、セッション及びトランスポートプロトコルを有している。

プロトコルの中間レイヤには、インターネットワーキングプロトコル３０６が存在する。インターネットワーキングプロトコル３０６は、例えば、ＩＰｖ６ルータ探索プロトコルを実施するＩＰｖ６ルータ探索モジュール３０２、ＩＰｖ６近隣探索プロトコルを実施するＩＰｖ６近隣探索モジュール３０３と、その他のプロトコルを実施するモジュールをいくつか有している。

上記のその他のプロトコルとしては、例えば、アドレス自動構成プロトコルや、ＭＩＰｖ６に基づくモビリティサポート関連プロトコルが挙げられる。図５には、ＩＰｖ６に基づくモビリティサポート関連プロトコルを実施するモジュールとして、ＭＩＰｖ６に基づくモビリティサポートプロトコル及びＲＯを実施するモバイルＩＰｖ６＋ＲＯモジュール３０４と、新たなＲＯプロトコルである可動ＣＲ−ＲＯプロトコルを実施する可動ＣＲ−ＲＯモジュール３０５とが図示されている。なお、この図５には、インターネットワーキングレイヤのすべての機能が図示されているわけではない。また、図５に図示されている機能アーキテクチャはＭＨであり、アドホックネットワークが形成される必要がない場合には、スタックにドメイン内ルーティングプロトコル（intra domain routing protocol）がサポートされる必要はない。

モビリティ関連ルーティングモジュールであるモバイルＩＰｖ６＋ＲＯモジュール３０４及び可動ＣＲ−ＲＯモジュール３０５は両方共、ルーティングの機能をサポートするために、自身に関連するＢＣＥ及びＢＬを有している。

ホームドメインに存在するＭＨは、ＭＩＰｖ６ ＲＯを利用するＢＣＥが生成されない場合には標準ＩＰｖ６メカニズムを利用して通信を行う。ここで、ＭＨがホームリンクに存在し、そのピアノードが訪問ドメインに存在すると仮定する。このとき、ＭＨは、ＭＩＰｖ６ ＲＯを利用して通信を行う。したがって、ＭＨは、ホームに存在する場合には可動ＣＲ−ＲＯモジュール３０５を除くすべてのモジュールを動作させる必要がある。

一方、ＭＨが訪問ドメインに存在する場合には、ＨＡへの登録が不可欠である。これは、モバイルＩＰｖ６＋ＲＯモジュール３０４によってサポートされる。また、ＭＨは、新たなＲＯユニット（可動ＣＲ−ＲＯモジュール３０５）を有しており、訪問ドメインに存在する場合には常にこのＲＯ用のプロトコルの使用を開始する。新たなＲＯプロトコルでサポートされている望ましい応答メッセージが得られない場合には、ＭＨは、ＲＯを行うか又はＨＡ経由のトンネルを行うためにＭＩＰｖ６ ＲＯを利用する。

また、図５には、下位レイヤプロトコル３０８が図示されている。下位レイヤプロトコル３０８は、データリンクレイヤ関連プロトコル及び物理レイヤプロトコルを有している。また、データパス３００は、上位レイヤプロトコル３０１とインターネットワーキングレイヤプロトコル３０６との間のインタフェースを示しており、データパス３０７は、下位レイヤプロトコル３０８とインターネットワーキングプロトコル３０６との間のインタフェースを示している。

なお、この機能アーキテクチャは、各レイヤの機能モジュールの変更が、スタックの他のレイヤのプロトコルの実現に影響することなく独立して行われるか、あるいは、変更のあったスタックに存在する他の機能エンティティ内で行われるように構成されている。

また、図６には、この新たな可動ＣＲ−ＲＯモジュールを実装するＭＲの好適な機能アーキテクチャが図示されている。ＭＲはルータなので、ＭＲのルーティングユニットはＭＨより複雑である。

ＭＲは、ドメイン内又はＩＰｖ６ルーティングプロトコルをサポートするＩＰｖ６ルーティングプロトコルモジュール２０２、モバイルＩＰｖ６＋ＲＯモジュール２０３、ＮＥＭＯベーシックサポートプロトコルを実施するＮＥＭＯベーシックモジュール２０４をサポートする必要がある。また、これらに加えて、ＭＲは、特に自身の配下に接続されているモビリティ非対応ＬＦＮノードのために必要なＲＯを実現するとともに、ＭＲに接続されているＶＭＮのために更なる最適化を提供するために、可動ＣＲ−ＲＯモジュール２０５をサポートする必要がある。

また、通常の機能アーキテクチャと同様に、経路管理やルーティング、ルーティング関連シグナリングに係る処理を行うインターネットワーキングレイヤプロトコル２０６は、上位レイヤプロトコル２０１と下位レイヤプロトコル２０８との間に存在する。ここでは、主要なプロトコル機能は、互いにインタフェース２００及びインタフェース２０７を通じて通信を行う。

上述の構成においては、ＭＨ、ＶＭＮ、ＭＲのいずれかが訪問ドメインに存在している場合にのみ、新しいＲＯモジュールが始動するか、あるいはＲＯ処理が開始される。また、データ通信を行っている２つのピアノードが訪問ドメインに存在している場合は、本発明は完全に実施される。

また、図７には、一方のピアノード（イニシエータノード１７４と呼ぶことにする）が訪問ドメインに存在しておりＲＯ処理を開始し、他方のピアノード（ＬＦＮ１５１）がＭＲ１４１の配下の別の訪問ドメインに存在しているシナリオが図示されている。一般的には、イニシエータノード１７４は、ＬＦＮ１５１とデータ通信を開始しようとしているか、自身の配下のモバイルネットワークに接続されている別のノードのためにＲＯの手助けを行おうとしているシナリオが考えられる。ここでは、イニシエータノード１７４がＬＦＮ１５１とデータ通信を行おうとしているシナリオについて説明する。

イニシエータノード１７４は、ＬＦＮ１５１とデータ通信を行おうとしており、ＬＦＮ１５１にテストメッセージを送信する（経路２８０）。テストメッセージを構築する際には、あて先拡張ヘッダ（destination extension header）にＭＣＲＤｓｔＯｐｔ（Movable CR Destination Option）を使用する。図７に図示される例では、イニシエータノード１７４は、送信元アドレスとして自身のＣｏＡを使用する。また、イニシエータノード１７４は、最初のテストメッセージのＭＣＲＤｓｔＯｐｔで自身のＨｏＡを送信する。このテストメッセージはあて先ノードのホームドメインに向けて経路２８３経由で発送され、ＭＲ１４１のＨＡであるＨＡ１２１によって受信（intercept）される。

ＨＡ１２１は、テストメッセージをトンネルにカプセル化し、さらに、あて先拡張ヘッダ内のＭＣＲＤｓｔＯｐｔを調べて、ＭＣＲＤｓｔＯｐｔをトンネルヘッダにコピーする。なお、標準ＩＰｖ６トンネリング仕様によれば、トンネルエントリポイント（例えば、ＨＡ１２１）は、パケットのカプセル化を行う前にあて先拡張ヘッダを参照するように要請されている。ＨＡ１２１は、ＭＣＲＤｓｔＯｐｔを特定すると、トンネルヘッダ内に生成するあて先拡張ヘッダに、ＭＣＲＤｓｔＯｐｔをコピーする。このトンネルメッセージは、経路２８２経由で伝送されてＭＲ１４１に到達する。

ＭＲ１４１は、あて先拡張ヘッダのＭＣＲＤｓｔＯｐｔを理解するための動作を行う必要がある。ＭＲ１４１は、ＬＦＮ１５１の支援エージェントとして動作し、ＲＯの支援を行うことが可能である。最初のテストメッセージは、経路２８４を経由してＬＦＮ１５１に渡されるが、通常のＩＰｖ６ノードであるＬＦＮ１５１は、本発明の実施に関連するオプション又はメッセージを破棄する。なお、オプションのタイプの最初のビットは、このオプションを解釈することができない受信者が、メッセージではなくオプションを無視するように設定されることが望ましい。

ＭＲ１４１は、このＭＣＲＤｓｔＯｐｔを受信すると、イニシエータノード１７４に何らかの応答シグナリングを行うことによって、自身のホームアドレス及びＬＦＮ１５１のアドレスを伝える。イニシエータノード１７４は、応答を受信した後、最適化された方法でＬＦＮ１５１に到達可能となるようにＭＲ１４１とＲＯを行う必要があることを把握する。さらに、イニシエータノード１７４は、応答によって、ピアノード（ＬＦＮ１５１）が訪問ドメインに存在していることを把握する。したがって、応答後に、イニシエータノード１７４及びＭＲ１４１は、ＭＩＰｖ６の方法を利用して双方向のＲＲ、ＢＵ及びＢＡを行う。

イニシエータノード１７４とＭＲ１４１との間でトンネル確立処理が完了した後、イニシエータノード１７４は、ＬＦＮ１５１にデータを送信しようとする場合には、データをＭＲ１４１へのトンネルにカプセル化する。このとき、トンネルヘッダにＲＨ２拡張ヘッダを使用することが望ましい。イニシエータノード１７４からのデータパケットは、経路２８５を経由してＭＲ１４１にトンネルされる。ＭＲ１４１は、データのデカプセル化を行い、経路２８６経由でＬＦＮ１５１にデータを送信する。

ＬＦＮ１５１はイニシエータノード１７４と通信を行おうとする場合には、ＬＦＮ１５１はＲＯを実施できない（もっとも起こり得るケースである）ので、そのあて先をイニシエータノード１７４のＨｏＡに設定する。ＭＲ１４１は、上述の新たなルーティングモジュールに関連するＢＣＥをチェックし、そこに存在するノード（イニシエータノード１７４）のＨｏＡを特定することができる。さらに、ＭＲ１４１は、ＬＦＮ１５１のアドレスも、ＢＣＥ内のこのエントリに関連付けられていることを把握する。したがって、ＭＲ１４１は、トンネルのあて先アドレスとしてイニシエータノード１７４のＣｏＡを使用して、ＲＯのトンネル（経路２８５）にパケットをカプセル化する。

なお、この実施の形態では、本発明の基本的な部分及び簡単なシナリオのみが説明されている。さらに複雑なシナリオに関しては他の具体例で説明され、より詳細に本発明が説明される。

また、ＬＦＮ１５１はＭＩＰｖ６ ＲＯをサポートしていないと仮定しているが、ＬＦＮ１５１はＭＩＰｖ６ ＲＯをサポートしている場合であっても、このシステムに存在することが可能である。これを実現する方法について、以下に説明する。

ＭＣＲＤｓｔＯｐｔが任意のテストメッセージではなく、イニシエータノード１７４によって開始されたＲＲストリームで送信された場合には、ＬＦＮ１５１（ＭＩＰｖ６ ＲＯが実装されている）は、ＭＣＲＤｓｔＯｐｔを無視することができる。そして、ＬＦＮ１５１はＲＲを実行して、最終的に、データ伝送のあて先アドレスとしてイニシエータノード１７４のＣｏＡを使用する。

一方、ＭＲ１４１は、この新しいプロトコルに関連するあて先（イニシエータノード１７４）のＣｏＡをＢＣＥ内に有しているかをチェックすることができる。その結果、ＭＲ１４１は、テストメッセージの送信による新しいＲＯ処理を開始せず、代わりに経路２８５を通じたトンネリングを行う。したがって、基本的に、イニシエータノード１７４とＬＦＮ１５１との間の片方向のＲＲは無駄となり、これを避けるようにすることが好適である。これは、イニシエータノード１７４自身が行うことが可能である。

すなわち、ＭＲ１４１から可動ＣＲ−ＲＯに関連した応答を受信し、ＬＦＮ１５１から標準ＲＲに関連した応答を（ＭＩＰｖ６ ＲＯで）受信した場合、イニシエータノード１７４は、２つの応答を区別することが可能であり、ＬＦＮ１５１との間における更なるＲＲ及びＢＵを中止することが可能である。その結果、ＬＦＮ１５１ではＢＣＥは形成されない。あるいは、別の方法として、ＭＲ１４１がＬＦＮ１５１とＶＭＮとを区別することが可能であれば、ＭＲ１４１は、ＬＦＮ１５１に対してＲＲを実行しないように通知することも可能である。

なお、上記の問題は実際の実施に依存するものである。また、ＬＦＮ１５１がＭＩＰｖ６ ＲＯを実装しているというシナリオはあまり頻繁に生じるものではなく、実際には、非常に稀なシナリオである。

次に、以下の具体例において、ＬＦＮ１５１が単にＩＰｖ６ノードである場合について考察する。図８には、本発明が使用されている場合のデータ経路及びシグナリング経路について、より詳細に示されている。なお、イニシエータノード１７４のＨＡはＨＡ１２０であり、ＭＲ１４１のＨＡはＨＡ１２１である。

イニシエータノード１７４は、自身のＨＡ１２０へのトンネルでカプセル化されたＭＣＲＤｓｔＯｐｔを有するテストメッセージを作成する。このトンネルメッセージ１８０は、ＨＡ１２０に送信される。ＨＡ１２０は、このトンネルメッセージ１８０のデカプセル化を行い、ＬＦＮ１５１のホームドメインに、デカプセル化されたテストメッセージ１８１を発送する。

ＨＡ１２１は、元のテストメッセージ１８１を受信（intercept）し、テストメッセージ１８１をＭＲ１４１あてのトンネルパケット１８２にカプセル化する。さらに、ＨＡ１２１は、テストメッセージ１８１のＭＣＲＤｓｔＯｐｔをトンネルヘッダにコピーする。トンネルパケット１８２はＭＲ１４１でデカプセル化される。そして、ＭＲ１４１は、自身のメモリに、ＭＣＲＤｓｔＯｐｔの内容及びＬＦＮ１５１のアドレスを格納する。また、元のテストメッセージ１８３は、ＬＦＮ１５１に渡される。ＬＦＮ１５１は、単なるＩＰｖ６ノードであり、上述のような本発明に係る動作を行うことはない。すなわち、ＬＦＮ１５１は、テストメッセージ１８３に対する応答を行わない。

一方、ＭＣＲＤｓｔＯｐｔを取得したＭＲ１４１は、送信元アドレスとして自身のＨｏＡを有し、メッセージパラメータとしてＬＦＮ１５１のアドレスのみが含まれる応答メッセージを開始する。これにより、イニシエータノード１７４は、このＭＲ１４１のＨｏＡが所望のあて先と同一のプレフィックスを有していることをチェックできるようにする。

そして、ＭＲ１４１は、自身のＨＡ１２１に応答メッセージ１８４をトンネルする。応答メッセージ１８４を受信したＨＡ１２１は、デカプセル化を行って、応答メッセージ１８５をイニシエータノード１７４のホームドメインに送信する。この応答メッセージ１８５を受信（intercept）したＨＡ１２０は、応答メッセージをカプセル化し、イニシエータノード１７４のＣｏＡあてにトンネルされる応答メッセージ１８６を送信する。応答メッセージ１８６を受信したイニシエータノード１７４は、デカプセル化を行って、応答メッセージ１８６から必要なパラメータ（ＭＲ１４１のＨｏＡ及びＬＦＮ１５１のアドレス）を取得する。応答メッセージ１８６を受信した後、イニシエータノード１７４及びＭＲ１４１は、図８のブロック１８７に示されているように、双方向のＲＲ、ＢＵ及びＢＡを実行する。

双方向のバインディング処理が成功した後、イニシエータノード１７４は、ＭＲ１４１のＣｏＡに向かうトンネルにＬＦＮ１５１へのデータをカプセル化し、トンネルパケット１８８を送信する。ＭＲ１４１はトンネルパケット１８８のデカプセル化を行って、データパケット１８９をＬＦＮ１５１に送信する。また、同様に、ＬＦＮ１５１がイニシエータノード１７４にデータパケット１９０を送信する場合、データパケット１９０は、ＭＲ１４１でカプセル化されて、図８に示すように、トンネルパケット１９１によってイニシエータノード１７４のＣｏＡに送信される。なお、イニシエータノード１７４がＭＨの場合には、図７及び図８で説明される処理が行われる。

一方、図９には、本発明の実施の形態において、図４に図示されている従来のプロトコルを使用するシナリオと比較して、ルーティングの経路が確実に少なくなるシナリオが図示されている。この具体例では、図７に示すイニシエータノード１７４がＶＭＮ１７３であり、訪問ドメインに存在するＭＲ１４０の配下でネスト状態となっている場合に係る本発明が説明される。

図９には、ＶＭＮ１７３がＭＲ１４０の配下に接続されており、ＭＲ１４１の配下に接続されているＬＦＮ１５１とデータ通信を開始しようとしているシナリオが図示されている。ここで、ＭＲ１４１は訪問リンクを通じてＡＲ１３１の配下に接続されており、ＭＲ１４０は訪問リンクを通じてＡＲ１３０の配下に接続されている。なお、ＶＭＮ１７３、ＭＲ１４０、ＭＲ１４１には、可動ＣＲ−ＲＯモジュールが実装されている。また、ＨＡ１２０はＭＲ１４０のＨＡであり、ＨＡ１２１はＭＲ１４１のＨＡであり、ＨＡ１２２はＶＭＮ１７３のＨＡである。ＨＡ１２０、ＨＡ１２１、ＨＡ１２２は、あて先拡張ヘッダのＭＣＲＤｓｔＯｐｔを識別して、ＭＣＲＤｓｔＯｐｔをトンネルヘッダにコピーする処理を行う必要がある。

まず、ＶＭＮ１７３が、テストメッセージをＬＦＮ１５１に送信する（経路３８０）。このテストメッセージは、ＭＲ１４０でＨＡ１２０に向かうトンネルにカプセル化され、経路３８１を通じて送信される。ＨＡ１２０において、テストメッセージはデカプセル化されて、ＬＦＮ１５１のホームドメインに経路３８２を通じて発送される。ここで、テストメッセージは、ＨＡ１２１によって受信（intercept）され、ＭＣＲＤｓｔＯｐｔがトンネルヘッダにコピーされてカプセル化され、経路３８３のトンネルを通じて発送される。このメッセージは、トンネル出口ポイント（ＭＲ１４１）に到達する。

ＭＲ１４１は、上述の動作と同様に、デカプセル化を行って内部パラメータを調べる。そして、ＭＲ１４１はＶＭＮ１７３にその応答を送信し、その後、ＶＭＮ１７３とＭＲ１４１との間で、ＲＲに関連するシグナリングによって双方向トンネルが確立される。なお、テストメッセージは経路３８４を通じてＬＦＮ１５１に渡されてもよいが、ＬＦＮ１５１はこのテストメッセージを理解せず、テストメッセージは破棄される。

ここで、ＶＭＮ１７３は、ＬＦＮ１５１のＢＣＥを有していないことから、あて先（通信相手）がＬＦＮであることを把握する。したがって、ＶＭＮ１７３は、ＭＲ１４１によるトンネリングによって、ＬＦＮ１５１へのデータパケットをトンネルする。すなわち、トンネルヘッダにおいて、あて先アドレスはＭＲ１４１のＣｏＡに設定される。ＶＭＮ１７３からトンネルされるデータパケットは、まず経路３８５を通じてＭＲ１４０に到達し、ＭＲ１４０で更にカプセル化されて、経路３８６経由でＨＡ１２０に送信される。ここで、データパケットはデカプセル化されて、経路３８７を通じてＭＲ１４１のＣｏＡに送信される。ＭＲ１４１はそのデータパケットをデカプセル化し、データパケットは経路３８８を通じてＬＦＮ１５１に到達する。

また、ＭＲ１４０は、ＭＲ１４１のＣｏＡのバインディングを有していないことに気が付き、通常のテストメッセージ処理（ＲＲ処理）が開始される。そして、最終的に、ＭＲ１４０及びＭＲ１４１は、バインディングキャッシュエントリに互いのＨｏＡ及びＣｏＡを有することになる。このＲＲ処理により、ＶＭＮ１７３がＬＦＮ１５１にトンネルされるデータパケットを送信する場合には、ＭＲ１４０がＭＲ１４１へのトンネルを行い、その結果、パケットはより最適化された経路３８９を通じて伝送されるようになる。これを実現するためのより良い方法も存在する。

例えば、イングレスフィルタリングを通過できるようにするとともに、完全なトンネルを実現する際のオーバヘッドを低減するために、ＭＲ１４０は、ＭＲ１４１にトンネルすることが可能であるか、あるいは非特許文献６に開示されている技術のように、自身のＣｏＡに送信元アドレスを変更できることが望ましい。ＭＲ１４０は、ＶＭＮ１７３によって生成されたトンネルのあて先アドレス（ＭＲ１４１のＣｏＡ）を調べることにより、このアドレスがＭＲ１４１のＣｏＡに対応していることを把握する（なお、ＭＲ１４０は、ＭＲ１４１のＨｏＡ及びＣｏＡを有している）。そして、ＭＲ１４０は、トンネルの送信元（ＶＭＮ１７３）がＬＦＮではないことを把握し、その結果、非特許文献６に開示されている技術のように、容易に送信元アドレスを変更することが可能となる。

また、上述のＲＯが完全に確立された後、ＬＦＮ１５１がデータパケットをＶＭＮ１７３に送信する際に、ＭＲ１４１は同様の方法を用いて、ＢＣＥをチェックしてあて先アドレス（ＶＭＮ１７３のＨｏＡ）及びＬＦＮ１５１の送信元アドレスを探し、ＶＭＮ１７３にパケットをトンネルする。なお、トンネルヘッダはあて先がＭＲ１４０のＣｏＡであり、ＶＭＮ１７３のＣｏＡ及びＨｏＡのエントリが含まれているＲＨ２を有することが望ましい。

従来の技術に係る図４と図９とを比較した場合、本発明によって最適化された経路が提供されることは明らかである。

また、図１０には、図７に示すイニシエータノード１７４がＭＲであるシナリオが図示されている。ここで、ＬＦＮ１５０及びＬＦＮ１５１は両方共、訪問ドメインに存在しており、相互に通信を行おうとしている。また、ＨＡ１２０はＭＲ１４０のＨＡであり、ＨＡ１２１はＭＲ１４１のＨＡである。

ＬＦＮ１５０がデータ通信を開始するとき、ＭＲ１４０はＬＦＮ１５１との経路最適化のために、可動ＣＲ−ＲＯモジュールを始動する。上述の具体例で説明したように、テストメッセージは、経路４８０、４８３、４８２を通じて伝送され、ＭＲ１４１に到達する。なお、ここでは、ＭＲ１４０のＣｏＡがテストメッセージの送信元アドレスとして使用されるものとする。

テストメッセージを受信した後、ＭＲ１４０及びＭＲ１４１は、ＭＲ１４１が応答処理を完了して双方向トンネルを確立する。トンネル形成後にＬＦＮ１５０がデータパケットを送信した場合、ＭＲ１４０は、そのあて先がＬＦＮ１５１であることを見つけてＢＣＥをチェックし、ＬＦＮ１５１と同一のプレフィックスを有するＭＲ１４０のアドレスを特定する。そして、ＭＲ１４０は、上記のトンネルにパケットをカプセル化することによって、パケットは経路４８５を経由して伝送されるようになる。また、ＬＦＮ１５１がデータパケットを送信した場合も、相手側（ＭＲ１４１）において同様の処理が行われる。

従来の技術に係る図１と図１０とを比較した場合、本発明の利点は明らかである。

また、図１１には、２つのＶＭＮ１７３及びＶＭＮ１７４が訪問ドメインに位置しており、それぞれＭＲ１４０及びＭＲ１４１の配下でネスト状態にあり、相互にデータ通信を行うシナリオが図示されている。さらに、ＭＲ１４０及びＭＲ１４１も訪問ドメインに存在する。なおＨＡ１２０はＭＲ１４０のＨＡであり、ＨＡ１２１はＭＲ１４１のＨＡである。また、ＨＡ１２３はＶＭＮ１７３のＨＡであり、ＨＡ１２２はＶＭＮ１７４のＨＡである。

ＶＭＮ１７３がＶＭＮ１７４とデータ通信を行おうとする場合、ＶＭＮ１７３は、まず、自身のＨｏＡを含むＭＣＲＤｓｔＯｐｔを有し、ＶＭＮ１７４のＨｏＡをあて先とするテストメッセージを構成する。なお、このシナリオでは、テストメッセージを構成する際に、ＶＭＮ１７３のＣｏＡが送信元アドレスとして使用される。

このメッセージは経路５８０を通じてＭＲ１４０に渡される。そして、ＭＲ１４０でカプセル化されて経路５８１を通じて伝送され、ＨＡ１２０でデカプセル化される。次に、このメッセージは、経路５８２を通じてＶＭＮ１７４のホームドメインに発送される。そして、ＨＡ１２２によって受信（intercept）され、ＭＣＲＤｓｔＯｐｔがトンネルヘッダにコピーされてトンネルされる。そして、トンネルパケットは経路５８３を通じてＨＡ１２１に到達し、ＨＡ１２１において、ＭＣＲＤｓｔＯｐｔが再びトンネルヘッダにコピーされて、ＭＲ１４１のＣｏＡに更にトンネルされる。

メッセージが経路５８４を通じてＭＲ１４１に到達すると、ＭＲ１４１は、ＶＭＮ１７３のＨｏＡを取得するとともに、インナパケットのあて先が、自身のメモリ内に存在するＶＭＮ１７４のＣｏＡであることに気が付く。そして、テストメッセージは、経路５８５を通じてＶＭＮ１７４に到達し、ＶＭＮ１７４はデカプセル化を行うとともに、ＭＣＲＤｓｔＯｐｔ（ＶＭＮ１７３のＨｏＡ）を取得する。また、ＭＲ１４１及びＶＭＮ１７４の両方共、それぞれＶＭＮ１７３に対してテストメッセージへの応答を送信することになる。

ＶＭＮ１７３は、これら（ＭＲ１４１及びＶＭＮ１７４）のＨｏＡを含む応答を受信すると、これらのエンティティのそれぞれとの間で、ＲＲ処理、ＢＵ及びＢＡを開始する。双方向のＲＲ、ＢＵ及びＢＡの処理後、最終的にＶＭＮ１７３は、ＶＭＮ１７４のＨｏＡ及びＣｏＡを保持し、さらに新たなルーティングモジュールに関連するＢＣＥ内に、ＭＲ１４１のＨｏＡ及びＣｏＡを保持する。したがって、このＢＣＥから、ＶＭＮ１７３は、プレフィックスのマッチングによって、ＶＭＮ１７４のＣｏＡに到達可能となるためにはＭＲ１４１に到達する必要があることが発見可能となる。そして、ＶＭＮ１７３は、データをＶＭＮ１７４に送信する際には、あて先をＭＲ１４１のＣｏＡとし、ＲＨ２の最後のスロットをＶＭＮ１７４のＨｏＡとする。

このパケットが経路５８６を通じてＭＲ１４０に到達した場合、ＭＲ１４０は、ＭＲ１４１のＣｏＡを含むＢＣＥを有していないので、パケットを自身のＨＡ１２０にトンネルし、その結果、パケットは経路５８７経由で発送されることになる。ＨＡ１２０はパケットのデカプセル化を行い、内部のデータパケットは経路５８８を通じて送信され、最終的に経路５８９を通じてＶＭＮ１７４に到達する。ＶＭＮ１７４が応答データパケットを即座に送信する場合には、ＶＭＮ１７４は、ＶＭＮ１７３へのツリー経路上に存在する他のＭＲを知らないので、ＶＭＮ１７３のＣｏＡをあて先とし、ＲＨ２のスロットとしてＶＭＮ１７３のＨｏＡのみを含むデータパケットを構築する。

ＭＲ１４１は、このデータパケットを取得した場合には、あて先アドレスがＢＣＥに含まれているＶＭＮ１７３のＣｏＡであることに気が付く。したがって、ＭＲ１４１は、このデータパケットをＶＭＮ１７３あてのトンネルにカプセル化するか、あるいは、送信元アドレスを自身のＣｏＡに変更して、メッセージを送信する。最終的に、メッセージは、ＭＲ１４０のＨＡ１２０を経由して発送され、ＶＭＮ１７３に到達する。その後、任意の時間経過後に、上述の具体例で説明したように、ＭＲ１４０は、可動ＣＲ−ＲＯモジュールを始動して、ＭＲ１４１にテストメッセージを送信し、最終的にＭＲ１４１との間で双方向トンネルを確立する。この後、ＶＭＮ１７３によって生成されたデータパケットは、経路５９０を通じて発送される。この場合、パケットはＭＲ１４０からＭＲ１４１にトンネルされ、これによって、ルーティングの経路は短くなる。

上述のシナリオと同様に、このシナリオは、ネストのレベルが小さい場合における本発明の動作を示している。しかし、この具体例によれば、本発明は、ネスト状態の場合における最適化を目的としていない場合であっても、ネスト状態の場合において動作することが明らかとなる。また、図３に図示されている従来の技術の場合に比べて、本発明によれば、経路に関しては確実に最適化が行われることが示される。

また、図１２には、本発明に関連するシグナリングや、このシグナリングが最適化可能であることが分かるように、２つのＬＦＮ１５０及びＬＦＮ１５１が訪問ドメインに存在し、データ通信を行う場合におけるシグナリングが明らかにされている。以下、図１２を参照しながら、この具体例について説明する。ここで説明するシグナリングを実現する方法は多数存在しているが、この具体例では、最適化は行わず、こうした方法の１つについてのみ説明する。

ここでは、テストメッセージとして、ＭＲ１４０が可動ＣＲ−ＲＯモジュールを始動した場合に生成するＨｏＴＩメッセージを用いることにする（したがって、テストメッセージを追加する必要がない）。なお、ＨｏＴＩメッセージをテストメッセージとして使用する長所に関しては、別の具体例において説明する。

図１２において、ＭＣＲＤｓｔＯｐｔを有するＨｏＴＩメッセージ１１００が、ＨＡ１２０あてにトンネルされ、ＨＡ１２０においてデカプセル化される。デカプセル化されたＨｏＴＩメッセージ１１０２はＨＡ１２１に発送される。ＨＡ１２１では、ＨｏＴＩメッセージはカプセル化され、カプセル化されたＨｏＴＩメッセージ１１０３はＭＲ１４１に到達する。

ＭＲ１４１はデカプセル化を行って、ＨｏＴＩメッセージ１１０３から、上述の具体例で説明した必要なパラメータ（ＭＲ１４０のＨｏＡ及びＬＦＮ１５１のアドレス）と、ホームイニットクッキー（home init cookie）とを取得する。なお、ホームイニットクッキーがＭＲ１４１あてではない場合でも、この処理が行われ、本発明を実施するための不要なシグナリングが低減される。そして、最終的に、ＨｏＴＩメッセージ１１０５がＬＦＮ１５１に送信され、ＬＦＮ１５１において破棄される（ただし、ＬＦＮ１５１がいかなる種類のＲＯも理解しないと仮定する）。

また同時に、ＭＲ１４０は、送信元アドレスとして自身のＣｏＡを使用して、ＬＦＮ１５１をあて先とするＣｏＴＩメッセージ１１０１を送信する。このＣｏＴＩメッセージ１１０１の送信は、エンドノード（通信相手）がＶＭＮ又はＭＨの場合もあり、この場合には、ＲＯを遅延なく確立することができるためである。ＣｏＴＩメッセージ１１０１はＭＲ１４０で生成され、ＨＡ１２１に発送される。そして、ＨＡ１２１でトンネルにカプセル化され、カプセル化されたＣｏＴＩメッセージ１１０４がＭＲ１４１に送信される。ＭＲ１４１は単にＣｏＴＩメッセージ１１０４をデカプセル化し、通常のメッセージとしてＣｏＴＩメッセージ１１０６をＬＦＮ１５１に送信する。なお、このＣｏＴＩメッセージにはＭＣＲＤｓｔＯｐｔが存在していないので、ＭＲ１４１は、基本的にこのＣｏＴＩメッセージ１１０６を無視して、単に正しいあて先（ＬＦＮ１５１）に送信する処理のみを行う。

ここで、ＭＲ１４１は、上述のＨｏＴＩメッセージに基づいて、応答メッセージを構成する。応答メッセージは、モビリティヘッダに埋め込むことが可能である。ＭＲ１４１は、ＩＰｖ６ヘッダに送信元アドレスとして自身のＨｏＡを有するメッセージを構築する。ＭＲ１４１は、モビリティヘッダのモビリティオプションにＬＦＮ１５１のアドレスを挿入して、自身のＨＡ１２１に応答メッセージ１１０７をトンネルする。ＨＡ１２１では、応答メッセージ１１０７はデカプセル化され、デカプセル化された応答メッセージ１１０８がＭＲ１４０のＨＡ１２０に発送される。ＨＡ１２０では、応答メッセージ１１０８はカプセル化されて、カプセル化された応答メッセージ１１０９がＭＲ１４０にトンネルされる。なお、応答メッセージ１１０９は、ＭＲ１４０のＨｏＡあてに送信される。

この応答メッセージ１１０９を受信したＭＲ１４０は、双方向トンネルを始動させることを決定し、ＭＲ１４１にＣｏＴＩメッセージ１１１０を送信する。なお、既に、ホームイニットクッキーは送信されており、したがって、更なる送信を行う必要はない。この具体例に係る動作は、シグナリングストームを抑えるように最適化が行われている点において進歩性を有していると言える。ＭＲ１４０のＣｏＴＩメッセージ１１１０は、ＭＲ１４１のＨｏＡあてに送信される。その結果、ＣｏＴＩメッセージ１１１０は、ＨＡ１２１においてカプセル化され、カプセル化されたＣｏＴＩメッセージ１１１１はＭＲ１４１に送信される。このＣｏＴＩメッセージ１１１１を受信したＭＲ１４１は、ＣｏＴＩメッセージ１１１１から気付イニットクッキー（care-of init cookie）を取得する。そして、ＭＩＰｖ６ ＲＲ処理と同様に、ＭＲ１４１は、ホームキー生成トークン（home key generation token）及び気付キー生成トークン（care-of key generation token）を生成する。

なお、当業者であれば、ホームキー生成トークンが、ホームイニットクッキー、ＲＲを開始したイニシエータノードのＨｏＡ、nonceを使用して作成され、気付キー生成トークンが、気付イニットクッキー、ＲＲを開始したイニシエータノードの気付アドレス、nonceを使用して作成されることは明らかである。

これらのトークンの生成後、ＭＲ１４１は、ＨｏＴメッセージ１１１２をＭＲ１４０のＨｏＡに送信する。ＨｏＴメッセージには、ホームキー生成トークン、nonceインデックス、ホームイニットクッキーが含まれている。また、ＨｏＴメッセージ１１１２の送信元アドレスには、自身のＨｏＡが使用される。上記のカプセル化されたＨｏＴメッセージ１１１２はＨＡ１２１に送信される。ＨＡ１２１では、ＨｏＴメッセージ１１１２はデカプセル化され、ＨｏＴメッセージ１１１３がＨＡ１２０に発送される。ＨＡ１２０では、ＨｏＴメッセージ１１１３はカプセル化され、その結果、ＨｏＴメッセージ１１１４がＭＲ１４０に到達する。ＭＲ１４０はＨｏＴメッセージ１１１４をデカプセル化して、必要なコンテンツを取得する。

また同様に、ＭＲ１４１は、送信元アドレスとして自身のＨｏＡを使用したＣｏＴメッセージを送信する。なお、ここでは、ＭＲ１４１は、あて先アドレスとしてＭＲ１４０のＣｏＡを使用する。気付イニットクッキー、気付キー生成トークン、nonceインデックスを有するＣｏＴメッセージがカプセル化されて、カプセル化されたＣｏＴメッセージ１１１５がＨＡ１２１にトンネルされる。ＨＡ１２１はＣｏＴメッセージ１１１５のデカプセル化を行って、ＭＲ１４０のＣｏＡにＣｏＴメッセージ１１１６を発送する。ＣｏＴメッセージ１１１６を受信したＭＲ１４０は、ＭＲ１４１にＢＵを登録するために使用するバインディングキーを計算する処理を開始する。

また、ＭＲ１４１は自身あてのＣｏＴＩメッセージ１１１１の受信とほぼ同時に、ＭＲ１４０あてのＨｏＴＩメッセージを始動する。このＨｏＴＩメッセージはＭＲ１４０のＨｏＡあてに送信される。また、送信元アドレスはＭＲ１４１のＨｏＡとなる。その結果、ＨｏＴＩメッセージ１１１７がカプセル化され、ＨＡ１２１に送信される。ＨＡ１２１では、ＨｏＴＩメッセージ１１１７はデカプセル化されて、ＨｏＴＩメッセージ１１１８がＨＡ１２０に送信される。ＨＡ１２０では、ＨｏＴＩメッセージ１１１８がカプセル化されて、ＨｏＴＩメッセージ１１１９がＭＲ１４０に送信される。

また、ほぼ同時に、ＭＲ１４１はＣｏＴＩメッセージをＭＲ１４０に送信する。このＣｏＴＩメッセージでは、送信元アドレスとしてＭＲ１４１のＣｏＡが使用され、あて先アドレスとしてＭＲ１４０のＨｏＡが使用される。このＣｏＴＩメッセージ１１２０は、ＨＡ１２０に送信され、ＨＡ１２０においてカプセル化されて、ＣｏＴＩメッセージ１１２１としてＭＲ１４０にトンネルされる。

また、同様に、ＭＲ１４０は送信元アドレスとして自身のＨｏＡを使用し、あて先アドレスとしてＭＲ１４１のＨｏＡを使用したＨｏＴメッセージを送信することが可能である。そして、このＨｏＴメッセージ１１２２はＨＡ１２０にトンネルされ、ＨＡ１２０においてデカプセル化され、ＨｏＴメッセージ１１２３がＨＡ１２１に発送される。そして、ＨＡ１２１において、ＨｏＴメッセージ１１２３はカプセル化されて、カプセル化されたＨｏＴメッセージ１１２４がＭＲ１４１に到達する。

一方、ＭＲ１４０は、送信元アドレスとして自身のＨｏＡを使用し、あて先アドレスとしてＭＲ１４１のＣｏＡを使用したＣｏＴメッセージを再び送信する。ＣｏＴメッセージ１１２５はＨＡ１２０にトンネルされ、その後、デカプセル化されたＣｏＴメッセージ１１２６がＭＲ１４１に到達する。なお、ＭＲ１４１も、自身に必要なバインディングキーの計算を行ってもよい。

そして、ＭＲ１４０は、自身のＢＵメッセージ１１２７をＭＲ１４１に送信する。なお、ＭＲ１４０は、ＢＵメッセージ１１２７の送信元アドレスとして自身のＣｏＡを使用し、また、あて先アドレスとしてＭＲ１４１のＣｏＡを使用する。また、同様に、ＭＲ１４１も、ＢＵメッセージ１１２８を送信する。これによって、ＭＲ１４０及びＭＲ１４１におけるＢＵは完了する。なお、ＢＵに対する応答であるＢＡが送信されるが、ここでは説明を省略する。

以上の動作により、ＬＦＮ１５０から送信されたデータパケット１１２９は、ＭＲ１４０においてＭＲ１４１にトンネルされ、トンネルデータパケット１１３０はＭＲ１４１に到達する。そして、ＭＲ１４１において、トンネルデータパケット１１３０は、デカプセル化され、元のデータパケット１１３１がＬＦＮ１５１に到達する。

なお、ＬＦＮ１５１ではなくＶＭＮの場合には、ＭＲ１４１によって生成された応答に加えて、ＶＭＮ自身による応答も始動される。また、ＶＭＮが送信するＣｏＴメッセージに、応答に必要なパラメータが埋め込まれてもよい。また、図１３には、図１２に示すシナリオに関し、シグナリングのストリームが最適化可能であることが示されている。

なお、図１２に示すシナリオと同一ではあるが、図１３には、シグナリングに関して可能な最適化の具体例が図示されている。図１２と比較することによって、図１３に示すシナリオにおいてシグナリングストームを抑えるという利点が明らかとなる。

図１３においても、ＭＲ１４０がＨｏＴＩメッセージ１０００を送信し、ＨＡ１２０によるＨｏＴＩメッセージ１１０２の転送を経て、ＨｏＴＩメッセージ１００３がＭＲ１４１に到達する。ＭＲ１４１は、ＨｏＴＩメッセージをデカプセル化した際に、ホームイニットクッキー、ＭＣＲＤｓｔＯｐｔ、ＬＦＮ１５１のアドレスを取得する。また、ＭＲ１４１は、ＣｏＴＩメッセージから気付イニットクッキーを取得するために、ＬＦＮ１５１のアドレスに送信されるＣｏＴＩメッセージを探索する状態となる。そして、ＭＲ１４１は、ＣｏＴＩメッセージ１００４を検出し、ＣｏＴＩメッセージ１００４から気付イニットクッキーを取得する。

ここで、ＭＲ１４０に別々の応答メッセージ（ＭＲ１４０への独立したＨｏＴメッセージと、ＭＲ１４０への独立したＨｏＴＩメッセージ）を送信する代わりに、ここでは、これらすべてのメッセージが、１つの応答メッセージ１００７に結合される。なお、応答メッセージ１００７には、送信元アドレスとしてＭＲ１４１のＨｏＡが使用されるので、ＨｏＴＩメッセージとしての有用性が実現される。また、この応答メッセージ１００７には、あて先アドレスとしてＭＲ１４０のＨｏＡが使用されるので、ＨｏＴメッセージとしての有用性が実現される。さらに、この応答メッセージ１００７にはＬＦＮ１５１のアドレスが格納されるので、応答メッセージとしての有用性が実現される。

応答メッセージ１００７には、ＬＦＮ１５１のアドレスに加えて、自身のホームイニットクッキー、ＭＲ１４０から送信されたホームイニットクッキーを使用して生成されたホームキー生成トークン、nonceインデックス、ＭＲ１４０から送信されたホームイニットクッキーが含まれる必要がある。なお、応答メッセージ１００７がモビリティヘッダメッセージとして送信される場合には、上述のパラメータは、モビリティオプションとして挿入されてもよい。これは、実際の実施に応じて定められる。

その結果、結合された応答メッセージ１００７が送信され、最終的に応答メッセージ１００９がＭＲ１４０に到達する。ＭＲ１４０では、メッセージ１００９はデカプセル化されて、必要なパラメータが取得される。ここで、この受信した応答メッセージ１００９から、ＭＲ１４０は、ＢＵメッセージを送信するためのホームキー生成トークンや、ＭＲ１４１に送信するＨｏＴメッセージを準備するためのいくつかのパラメータを把握する。さらに、応答メッセージの送信元アドレスとのトンネルを通じてＬＦＮ１５１に到達可能であることから、ＭＲ１４０は、可動ＣＲ−ＲＯモジュールが利用可能であることを把握する。なお、ここでは、単に組み合わされたメッセージによって最適化が行われるスキームに関して説明する。すなわち、応答メッセージ１００９を送信した後に、さらに、ＭＲ１４１は別の組み合わされたメッセージを送信する。

このメッセージは、ＭＲ１４１がＭＲ１４０に送信しようとするＣｏＴメッセージとＣｏＴＩメッセージとを組み合わせたメッセージである。ＭＲ１４１は、組み合わされたメッセージのあて先を、ＣｏＴＩメッセージ１００１から把握されるＭＲ１４０のＣｏＡに設定する。また、ＭＲ１４１は、組み合わされたメッセージによって、ＭＲ１４０に対して自身のＣｏＡを明示する。したがって、組み合わされたメッセージでは、基本的に、ＣｏＴＩメッセージ及びＣｏＴメッセージの機能の有効性が組み合わされる。また、この組み合わされたメッセージによって、ＭＲ１４１が生成した気付イニットクッキー、ＭＲ１４１が生成した気付キー生成トークン、このトークンを生成するために使用される気付イニットクッキー、nonceインデックスが運ばれる必要がある。なお、上記の組み合わされたメッセージは、図１３のメッセージ１０１０である。このメッセージ１０１０は、上述と同様にモビリティヘッダを使用して構築されてもよい。なお、当業者であれば、それぞれ異なるメッセージに関して、モビリティヘッダのタイプが異なることは容易に分かることは明らかである。

この組み合わされたメッセージ１０１０を受信した後、ＭＲ１４０は、ＨｏＴメッセージ１０１１をＭＲ１４１に送信する。なお、ＭＲ１４０は、ＨｏＴメッセージのあて先をＭＲ１４１のＨｏＡに設定する必要がある。一方、最適化を行うため、ＭＲ１４０は、送信元アドレスとして自身のＣｏＡを使用することも可能である。このＨｏＴメッセージ１０１１は、ＨＡ１２１によって転送され、ＨｏＴメッセージ１０１２としてＭＲ１４１に到達する。また、同様に、ＭＲ１４０はＣｏＴメッセージ１０１３を送信する。ＣｏＴメッセージに関しては、あて先がＭＲ１４１のＣｏＡに設定されることが重要である。

ＭＲ１４０からのＨｏＴメッセージは、ＭＩＰｖ６ ＲＲと同様に通常のパラメータを有している。また、ＭＲ１４０からのＣｏＴメッセージも同様である。そして、最終的に、ＲＲに関連するすべての最適化シグナリングが完了し、ＭＲ１４０はＢＵメッセージ１０１４を送信する。なお、ＭＲ１４１も同様にＢＵメッセージ１０１５を送信する。なお、図１３では、ＢＵストリームのみが図示されているが、実際には、各ＢＵに伴ってＢＡが送信される。

また、図１４には、本発明が完全には成功しないシナリオが図示されている。上述のように、本発明は、主にピアノードが訪問ドメインに存在する場合（理想的なシナリオ）に最適化される。しかしながら、以下には、理想的なシナリオとは異なり、本発明で提供されるＲＯが行われない場合（本発明が完全には成功しないシナリオ）が示される。ここでも同様に、ピアノードは、ＬＦＮ１５０及びＬＦＮ１５１である。また、ＭＲ１４０のＨＡはＨＡ１２０であり、ＭＲ１４１のＨＡはＨＡ１２１である。また、ＭＲ１４０が訪問ドメインに存在し、ＬＦＮ１５１がホームドメインに存在すると仮定する。

ＬＦＮ１５０がＬＦＮ１５１とデータ通信を開始した場合、ＭＲ１４０は訪問リンクに存在するので、上述の具体例で説明したように、テストメッセージ処理が開始される。このテストメッセージは、トンネルによって経路１２００を通じて発送される。ＨＡ１２０は、このテストメッセージのデカプセル化を行って、ＬＦＮ１５１のホームドメインに、経路１２０１を通じてテストメッセージを発送する。ＨＡ１２１は、バインディングを有していないのでプロキシとして機能できず、テストメッセージを受信（intercept）しない。その結果、ＨＡ１２１は、ＭＲ１４１へのトンネルを行わない。したがって、ＭＣＲＤｓｔＯｐｔを有するメッセージは、ＭＲ１４１ではなくＬＦＮ１５１に到達する。

しかしながら、ＭＲ１４１はモバイルであり、ほとんどの場合はホームドメインから離れている。したがって、ＭＲ１４１がホームドメインに存在する状態は頻繁に起こるものではなく、本発明では、ＭＲ１４１がホームドメインに存在しないシナリオに焦点を当てることにする。なお、ＭＲ１４１がホームに存在する場合には、図１と比較した場合、経路の半分は部分的に最適化が行われている。したがって、最適化が行われない場合でも大きな問題はない。

上述の動作において、ＭＣＲＤｓｔＯｐｔを送信する方法が多数存在することを述べたが、それぞれの方法には、長所及び問題が存在する。

任意のテストメッセージが使用される場合には、どの場合においても、帯域幅を浪費する付加的なＲＲシグナリングが行われる必要があり、最適化経路の確立に遅延がもたらされる可能性がある。したがって、本発明に係る好適な方法は、テストメッセージとしてＣｏＴＩメッセージを使用するものである。図１５において、テストメッセージとしてＣｏＴＩメッセージを使用できることを示す。

図１５には、テストメッセージとして使用されるＣｏＴＩメッセージ５００のメッセージ構造の一例が図示されている。これはＣｏＴＩメッセージであり、ＩＰｖ６ヘッダ５０１の送信元アドレスは、メッセージを送信するイニシエータノードのＣｏＡである。また、あて先は、イニシエータノードがトンネルの確立を望んでいる受信者となる。

さらに、あて先拡張ヘッダに挿入されるＭＣＲＤｓｔＯｐｔ（可動ＣＲあて先オプション）５０２が図示されている。ＣｏＴＩメッセージでは、テストメッセージのイニシエータノードのＨｏＡは明らかにされないので、イニシエータノードのＨｏＡは、ＭＣＲＤｓｔＯｐｔに挿入される。また、通常と同様に、ＣｏＴＩメッセージは気付イニットクッキー５０４を伝送する必要がある。これは、モビリティヘッダ５０３のデータセクションに付加される。

テストメッセージとしてＣｏＴＩメッセージを使用する利点は、ＣｏＴＩメッセージの送信元アドレスにＣｏＡが使用されるので、ＣｏＴＩメッセージはトンネルされずに、より迅速にあて先に到達することにある。

また、本発明の別の好適な方法として、テストメッセージとしてＨｏＴＩメッセージを使用することも可能である。図１６には、テストメッセージ４０３として機能するＨｏＴＩメッセージが図示されている。このＨｏＴＩメッセージでは、テストメッセージのイニシエータノードのＨｏＡは、ＩＰｖ６ヘッダ４０４の送信元アドレスとなる必要がある。したがって、このテストメッセージは、トンネルにカプセル化される必要があり、トンネルパケットはパケット４００のようになる。

トンネルＩＰｖ６ヘッダ４０１を有するトンネルパケット４００には、送信元アドレスとしてイニシエータノードのＣｏＡが設定される。また、このトンネルパケット４００は、イニシエータノードのＨＡへのトンネルなので、トンネルヘッダはトンネル認証ヘッダ（トンネルＡＨ：Authentication Header）４０２を有している。なお、このテストメッセージはモビリティメッセージであり、非特許文献１によれば、あて先拡張ヘッダにトンネルホームアドレスあて先オプション（tunnel home address destination option）は挿入されない。

テストメッセージとしてＨｏＴＩメッセージを使用する場合には、送信元アドレスとしてＨｏＡが使用されるので、さらにＭＣＲＤｓｔＯｐｔにＨｏＡを挿入する必要はない。なお、オプションの実際の内容は空であってもよく、また、オプションに暗号鍵が挿入されてもよい。オプションのタイプによって、これがどのタイプのオプションであるかが明らかにされる必要があり、受信者は、関連する情報の取得方法をこのメッセージから把握する。一方、通常のＨｏＴＩメッセージと同様に、モビリティ拡張ヘッダ（モビリティヘッダ）４０６によってＨｏＴＩメッセージが構成され、このメッセージ内にホームイニットクッキー４０７が存在する。

このモビリティ拡張ヘッダ４０６を使用する利点は、ＨｏＡをＭＣＲＤｓｔＯｐｔで送信する必要はなく、代わりに、例えばＭＣＲＤｓｔＯｐｔを用いて暗号鍵を送信することができるという点である。さらに、イニシエータノードのＨＡにトンネルされるので、メッセージは、よりセキュリティが強化された状態となる。暗号鍵を使用することによる利点は、応答メッセージの送信元が応答の際にこの鍵を送信することができ、イニシエータノードは、テストメッセージが正しい場所に送信されたという確証を得ることができることにある。

しかしながら、この解決方法をネスト構造のＣＮ環境で適切に動作させる必要がある場合には、ＨｏＴＩメッセージのＭＣＲＤｓｔＯｐｔ内にイニシエータノードのＨｏＡを使用することが望ましい。これにより、ＭＲが、内部のＨｏＴＩパケットまで詳細に調べる処理負荷を避けることが可能となる。

また、図１７には、本発明の好適な具体例における応答メッセージの一例が図示されている。上述の具体例では、シグナリングを最適化するため、応答メッセージが、ＲＲに関連するパラメータを含む多数のパラメータを有する方法に関して説明した。ここでは、応答メッセージの基本的な構造が明らかにされる。

応答メッセージのあて先アドレスは、テストメッセージのイニシエータノードのＨｏＡであると考えられる。また、応答メッセージの送信元アドレスは応答メッセージのイニシエータのＨｏＡであるか、あるいは別の方法では、ＭＣＲＤｓｔＯｐｔを取得したノードのＨｏＡが挿入される。応答メッセージ６０３の送信元アドレス及びあて先アドレスは、ＩＰｖ６ヘッダ６０４内に格納される。また、ＩＰｖ６ヘッダ６０４は、応答メッセージの送信元アドレスフィールド６０５及びあて先アドレスフィールドを有している。送信元アドレスフィールド６０５には、例えば応答メッセージの送信元のＨｏＡが含まれ、あて先アドレスフィールド６０６には、テストメッセージのイニシエータノードのＨｏＡが含まれる。

また、応答メッセージは、いくつかの新たなタイプのモビリティ拡張ヘッダとして構成することも可能である。応答メッセージは、ＭＲが代わりに応答を行っており、テストメッセージがあて先としているＬＦＮのアドレス６０８を有している。また、テストメッセージによって暗号鍵が送信された場合には、応答メッセージの受信者がメッセージの妥当性をチェックできるように、この暗号鍵６０９が送信されてもよい。なお、この暗号鍵６０９には、テストメッセージで送信された暗号鍵を使用して、応答メッセージに暗号化関数を適用した結果が用いられることが望ましい。これにより、受信者は、応答メッセージの真正性を検証することが可能となる。

また、通常と同様に、応答メッセージのイニシエータノードのＨｏＡが送信元アドレスとして使用されるので、この応答メッセージはトンネル内にカプセル化される。カプセル化応答パケット６００を構築する際には、トンネルＩＰｖ６ヘッダ６０１と共にトンネルＡＨ６０２がトンネルヘッダとして使用される。

また、図１８には、相互に通信を行おうとしているＬＦＮ１５０及びＬＦＮ１５１が訪問ドメインに存在しており、ネストが３段階である場合のシナリオが図示されている。ＬＦＮ１５０は、ＭＲ１４０、ＭＲ１４１、ＭＲ１４２の下でネスト状態にある。なお、ＨＡ１２０、ＨＡ１２１、ＨＡ１２２は、それぞれＭＲ１４０、ＭＲ１４１、ＭＲ１４２のホームエージェントである。また、ＬＦＮ１５１は、ＭＲ１４３、ＭＲ１４４、ＭＲ１４５の下でネスト状態にある。なお、ＨＡ１２３、ＨＡ１２４、ＨＡ１２５は、それぞれＭＲ１４３、ＭＲ１４４、ＭＲ１４５のホームエージェントである。

本発明によれば、このような状況下においても最適化が提供される。この具体例では、このような状況下において本発明が実施された場合に、シグナリングの負荷を低減するための更なる最適化の実行が望ましいことが示される。まず、以下に、本発明を使用して最適化が実現される方法について説明し、続いて、より良い最適化を行うためには更なる拡張が必要であることを説明する。

ＬＦＮ１５０がＬＦＮ１５１とデータ通信処理を開始する場合、ＭＲ１４２は可動ＣＲ−ＲＯモジュールを始動し、ＭＣＲＤｓｔＯｐｔを有するテストメッセージがＬＦＮ１５１に送信される。このテストメッセージは、ＨＡ１２０、ＨＡ１２１、ＨＡ１２２を通過した後、ＨＡ１２５に発送される。ＨＡ１２５はトンネルエントリポイントなので、ＭＣＲＤｓｔＯｐｔが+トンネルヘッダにコピーされる。テストパケットがＨＡ１２４に届いた場合も同様の処理が行われ、最終的にＨＡ１２３に到達する。そして最後に、多重カプセル化されたテストパケットはＭＲ１４３に到達する。

ここで、テストパケットが送信された場合には、すべての上流ルータ（ＭＲ１４３、１４４、１４５）は、インナパケットのあて先アドレスに加えてＭＣＲＤｓｔＯｐｔの値に着目する。そして、これらの各ＭＲ１４３、１４４、１４５は、テストメッセージの発信者であるＭＲ１４２に対して、それぞれ応答メッセージを送信する。ＭＲ１４２は、各応答の受信後に、ＭＲ１４３、ＭＲ１４４、ＭＲ１４５のそれぞれと双方向ＲＲ、ＢＵ及びＢＡを開始する。そして、３つの双方向トンネル確立処理を完了した後、ＭＲ１４２は、ＬＦＮ１５０からＬＦＮ１５１に送信されるデータパケットに関して、ＭＲ１４５へのトンネルのＲＨ２にＭＲ１４３、ＭＲ１４４、ＭＲ１４５のＣｏＡを挿入することによって、最適化されたデータ通信を開始する。

そして、ＭＲ１４２がＭＲ１４５との間で最適化されたデータ通信を開始した後、ＭＲ１４１は、ＲＯを行うためにＭＲ１４３（ＴＬＭＲ）へのテストメッセージを始動する。この処理は先に説明したものであり、ＭＲ１４１が参照するあて先アドレスがＭＲ１４３のＣｏＡであることに起因して行われる。このように、ＭＲ１４２のすべての上流ＭＲ（ＭＲ１４０及びＭＲ１４１）が、それぞれＭＲ１４３と双方向トンネルを確立する。したがって、すべての上流ＭＲ（ＭＲ１４０及びＭＲ１４１）は各自のＨＡにトンネルを行う代わりにＭＲ１４３にトンネルを行うことが可能となる。

以上のことから、ネスト状態にあるＣＮのＲＯに関する問題を解決するためには、シグナリングが多数行われる必要があることが分かる。なお、当業者であれば、ＲＯを行う場合にはバインディングストームが伴うことが分かる。ＭＲ１４２は、最適かつセキュアな方法で大量のシグナリングを行うことなく、ＭＲ１４３、ＭＲ１４４、ＭＲ１４５のそれぞれのＣｏＡを把握する必要がある。さらに、ＭＲ１４５は、最適かつセキュアな方法でＭＲ１４２、ＭＲ１４１、ＭＲ１４０のそれぞれのＣｏＡを把握する必要がある。したがって、本発明を拡張する場合には、上述の目的を実現されることが望ましい。

次に、図１９〜２６を参照しながら、本発明の別の実施の形態について説明する。この本発明の別の実施の形態では、上述の実施の形態で着目された障害のあるシナリオ（本発明が完全には成功しないシナリオ）に係る課題を解決するための解決策が説明される。

図１９に詳細に示されている具体例では、訪問ドメイン内で深いネスト状態にあるＬＦＮ１５２が、ホームリンク上に存在するＭＲ１４０に接続されている相手ノードＬＦＮ１５０との間で、低減されたシグナリングによって経路最適化されたパス（経路最適化パス：RO path）を実現するための方法が示されている。以下、図１９を参照しながら、この具体例について説明する。

この経路最適化パスは、ピアノードであるＬＦＮに透過的に取得される。ＬＦＮ１５２はＭＲ１４２に接続されており、さらにＭＲ１４２はＭＲ１４３に接続されている。なお、ＭＲ１４２及びＭＲ１４３は、訪問リンクに接続されており、ＭＲ１４２及びＭＲ１４３のそれぞれのＨＡはＨＡ１２２及びＨＡ１２３である。

一方、ＬＦＮ１５０はＭＲ１４０に接続されており、ＭＲ１４０は自身のホームリンク上に存在している。ホームリンク上に存在するＭＲ１４０のホームエージェントの１つはＨＡ１２０である。

図１９では、ＭＲ１４２は、ＬＦＮ１５２が通信を行っているあて先に対して、テストメッセージ１４００を送信する。このとき、ＭＲ１４２は、このメッセージのヘッダにＭＣＲＤｓｔＯｐｔを付加する。このＭＣＲＤｓｔＯｐｔは、ＭＲ１４２のＨｏＡ及び識別子の２つの属性を含んでいる。なお、以降、ＭＣＲＤｓｔＯｐｔの属性の１つである識別子をＩＤ（このトンネル確立手続きを識別するＩＤ）と呼ぶ。

なお、このテストメッセージ１４００は、上述の実施の形態と同様に、ＨｏＴＩであってもよく、したがって、ＨＡ１２２へのトンネルでカプセル化が可能である。このカプセル化されたテストメッセージ１４００は、さらにＭＲ１４３においてＨＡ１２３へのトンネルでカプセル化される。そして、２重にカプセル化されたメッセージ１４０１の一部がＨＡ１２３でデカプセル化され、カプセル化されたメッセージ１４０２がＨＡ１２２に送信される。そして、ＨＡ１２２において、テストメッセージは完全にデカプセル化され、メッセージ（ＭＣＲＤｓｔＯｐｔを有するメッセージ）１４０３がＬＦＮ１５０に到達する。

本発明によれば、ＭＲは、ホームリンク上に存在している際には、すべてのあて先オプション（自身をあて先とはしないものも含む）の検査を行う。なお、ＭＲは、ホームではデカプセル化処理を行う必要はなく、この監視による処理の複雑さや処理時間は、全体的にＭＲにとってコストが高いものではないので、このような特徴は、ＭＲの処理負荷を増大させるものではない。

ＬＦＮ１５０は、経路最適化処理をサポートしていない場合が多く、この場合には、ＬＦＮ１５０では、このメッセージ１４０３は無視されることになる。ＭＲ１４０は、ＭＣＲＤｓｔＯｐｔを検査して、テストメッセージ１４０３のあて先アドレスのプレフィックスが、自身が所有するプレフィックスであることを確認した後、テストメッセージの送信元に対して応答メッセージ１４０４を送信するか、あるいは、単にこのテストメッセージを転送して、応答メッセージの生成を行わない。

また、本発明によれば、応答メッセージのあて先（ＭＲ１４２）へのツリー経路上のＭＲを発見／特定するため、ＭＲ１４０は、応答メッセージ１４０４を生成する際に、自身のＨｏＡと、テストメッセージで受信したＩＤとを、ＲＥＳＤｓｔＯｐｔ（ＲｅｓｐｏｎｓｅＤｓｔＯｐｔ、なお、図１９では単にＤｓｔＯｐｔと記載）と呼ばれる新たなあて先オプション内に挿入する。この応答メッセージは、トンネル確立手続きを最適化するため、ＲＲに関連するパラメータが挿入されているモビリティヘッダを有している。また、応答メッセージは、さらにＬＦＮ１５０のアドレスを有している。

このメッセージ１４０４は、ＨＡ１２２に到達する。ここで、ＨＡ１２２は、このメッセージ１４０４をＭＲ１４２へのトンネルでカプセル化する。さらに、ＨＡ１２２は、トンネルエントリポイントなので、トンネリング仕様に従って、ＲＥＳＤｓｔＯｐｔを精査する。本発明によれば、ＨＡ１２２は、このオプションを理解し、このオプションのタイプが２つのパラメータのみを有していることを把握する。そして、ＨＡ１２２は、生成したトンネルヘッダ（外側のトンネル）に、単にオプション（ＲＥＳＤｓｔＯｐｔ）をコピーする。

このメッセージ１４０５はＨＡ１２３に到達し、ＨＡ１２３において、さらにＭＲ１４３にトンネルされる。ここではさらに、ＨＡ１２３は、ＨＡ１２３が生成したトンネルヘッダ（外側のトンネル）にＲＥＳＤｓｔＯｐｔをコピーする。この２重にカプセル化されたメッセージ１４０６はＭＲ１４３に到達し、ＭＲ１４３においてデカプセル化される。デカプセル化の際に、ＭＲ１４３は応答あて先オプションを取得する。また、ＭＲ１４３はデカプセル化後のあて先アドレスに注目する。

ここでは、デカプセル化にＭＲ１４３が注目したあて先アドレスは、ＭＲ１４２のＣｏＡである。デカプセル化後、１回カプセル化されているメッセージ１４０７が、ＭＲ１４２に到達する。ＭＲ１４２は応答メッセージの所望の受信者であり、ＲＥＳＤｓｔＯｐｔからパラメータを取得し、さらにモビリティヘッダからパラメータを取得する。ＭＲ１４２は、ＬＦＮ１５０の値及びＩＤの値をチェックし、正しい応答を受信した旨を確認する。なお、ここで、何らかのメカニズムを用いて、ＭＲ１４２が、ＬＦＮ／ＬＭＮとＶＭＮとを区別できるようにすることも可能である。理想的には、ＭＲ１４２は、ＬＦＮ／ＬＭＮに対してのみ、テストメッセージを送信する必要がある。なお、ＶＭＮは、自身のテストメッセージを送信することが可能である。

また、ＭＲ１４２は、媒体アクセス制御（ＭＡＣ：Media Access Control）識別子を保持し、これによって自身が送信したテストメッセージへの応答メッセージを特定することが可能である。また、ＭＲ１４２が、自身が送信していないテストメッセージに対する応答を受信した場合には、その応答メッセージから１ホップ下流のアドレスを特定して、この応答メッセージがＶＭＮ又はＭＲのどちらによるものかを特定することも可能である。

本発明によれば、ＭＲ１４３は、受信した応答メッセージを特定し、自身のＣｏＡ、ＨｏＡ、１ホップ下流のアドレス（ＭＲ１４２のＣｏＡ）、ＭＲ１４０から受信したＩＤを明らかにする別の応答メッセージ１４０８をＭＲ１４０に送信する。このメッセージ１４０８はＨＡ１２３にトンネルされ、ＨＡ１２３において、メッセージ１４０９が転送される。なお、ここで言及されているパラメータは、あて先オプションではなく、モビリティヘッダによって送信される。これは、応答−応答メッセージ（応答に対する応答メッセージ）によって、あて先へのツリー経路上の上流ＭＲを特定する必要がないことによる。最終的に、このメッセージ１４０９はＭＲ１４０に到達する。そして、ＭＲ１４０は、ＩＤを確認し、トレースを所望していたツリー経路を把握して、メッセージ１４０９からパラメータを取得する。

ＭＲ１４２は、ＭＲ１４０から応答を受けるとすぐに、上述の実施の形態で説明したように、ＲＲ（すなわち、ＭＲ１４０との最適化ＲＲ）を開始する。セキュアなトンネル確立シグナリングのストリーム１４１０によって、ＭＲ１４０は、ＭＲ１４２のＣｏＡを把握し、ＭＲ１４３から得られる応答メッセージを使用して、ＭＲ１４２に到達するツリー経路を推測することが可能となる。ＭＲ１４３は、ＭＲ１４０に対して、応答メッセージによってＭＲ１４２のＣｏＡを明らかにする。さらに、ＭＲ１４０は、ＲＲに関連するシグナリングから、ＭＲ１４２のＣｏＡを取得し、ＭＲ１４２へのツリー経路を推測する。本発明によれば、ＭＲ１４０は、ツリー経路を推測するとすぐに、このツリー経路の推測結果をＲＲに関連するシグナリングに利用して、シグナリングのルートを少なくすることが可能となる。

なお、ＲＲ及びトンネル確立の後、ＭＲ１４２は、ＭＲ１４０のＨｏＡのみを有し、ＭＲ１４０へのツリー経路を有さないことになる。ＭＲ１４０から受信する応答ではＣｏＡは明らかにはならないので、ＭＲ１４２は、ＭＲ１４０から受信する応答から、このツリー経路をすぐに予測することが可能である。さらに、ＭＲ１４２は、同一ＩＤを含む最初の応答として、所望の受信者（ＭＲ１４０）から応答を受信するので、ＭＲ１４０がホーム上に存在することを把握する。また、ＭＲ１４０は、ＭＲ１４２とのトンネル確立の後、ＭＲ１４３のＣｏＡ、ＭＲ１４２のＣｏＡ、ＭＲ１４２のＨｏＡがトンネル経路であるツリー経路を有する。ＬＦＮ１５０がデータパケット１４１１をＬＦＮ１５２に送信する場合、ＭＲ１４０は、データパケット１４１１が新しいＢＣＥ内のあて先と同一であるプレフィックスを有しているか否かをチェックする。同一のプレフィックスを有する場合には、さらにＭＲ１４０は、それに関連したツリー経路が見つかるか否かをチェックする。そして、もし見つかった場合には、ＭＲ１４０は、最初のあて先としてＭＲ１４３のＣｏＡを設定して、ＭＲ１４２にトンネルする。このトンネルされたパケット１４１２はＭＲ１４２に到達し、ＭＲ１４２はデカプセル化を行って、データパケット１４１３がＬＦＮ１５２に伝送される。

また、図２０には、ユニキャスト通信の両端が共に訪問ドメインに存在しており、一方が深いネスト状態にあるシナリオにおいて、ＲＲ及びＢＵシグナリングが低減された経路最適化を実現するために、本発明を活用するための方法が示されている。

図２０において、イニシエータノード（イニシエータ）１８０は、訪問リンク（外部アクセスネットワーク）に接続されている。また、ＬＦＮ１５１は、ＭＲ１４１に接続されており、ＭＲ１４１は、さらにＭＲ１４２に接続されている。なお、ＭＲ１４１及びＭＲ１４２は両方共、訪問リンク上に存在しており、これらのＨＡは、それぞれＨＡ１２１とＨＡ１２２である。

イニシエータ１８０はテストメッセージを送信し、このメッセージはＬＦＮ１５１に到達する。このメッセージが取る経路は、経路１５００、１５０１（トンネル）、１５０２（２重トンネル）、１５０３（デカプセル化後の単一のトンネル）、１５０４であり、ＬＦＮ１５１に到達する。ＭＲ１４２及びＭＲ１４１は、受信したトンネルヘッダからＭＣＲＤｓｔＯｐｔを受信し、関連する応答（図１９で説明されている上述の別の実施の形態で言及されたものと同一の応答）を送信する。なお、ＭＲ１４１は、自身が訪問リンク上に存在していることを把握して、自身のＣｏＡを応答メッセージのモビリティヘッダ内に挿入する点が、唯一異なっている。

また、この場合、本発明では、ＨＡがトンネリングを行ってＭＣＲＤｓｔＯｐｔの属性を自身が生成したトンネルヘッダにコピーする際、ＨＡは、ＭＣＲＤｓｔＯｐｔにカウント属性と呼ばれる新たな属性の生成を行う（ただし、この属性が存在しない場合）。図２０に示されているシナリオでは、ＨＡ１２１は、カウント属性を生成して値１を設定し、このカウント属性をＭＣＲＤｓｔＯｐｔの属性として、自身が生成したトンネルヘッダに挿入する。ＨＡ１２２において更なるカプセル化が行われた場合には、このカウント属性の値は、ＨＡ１２２によって２にインクリメントされる。そして、ＨＡ１２２は、自身が生成したトンネルヘッダのＭＣＲＤｓｔＯｐｔのカウント属性に値２を設定する。

ＭＣＲＤｓｔＯｐｔを取得したとき、ＭＲ１４２は、２のカウント値を受信し、ＭＲ１４１は、１のカウント値を受信する。ＭＲ１４２は、このようにカウント値２を受けるので、自身が所望の受信者の上流ＭＲであり、テストメッセージが対象とする受信者ではないことを把握する。その結果、ＭＲ１４２は、応答メッセージを構成する際、例えば自身のＣｏＡ、ＩＤ、１ホップアドレスなどのキーパラメータを、あて先オプション内ではなくモビリティヘッダ内に挿入する。なお、これは、ＭＲ１４２が、応答メッセージを送信するためにあて先（イニシエータノード１８０）へのツリー経路上の上流ＭＲを必要としないゆえに行われる。

一方、本発明は、不要なシグナリングを低減させるという目的を有しているが、ＭＲ１４１は所望の受信者であり、テストメッセージの送信者（イニシエータ１８０）へのツリー経路上に上流ルータの発見を必要としているので、ＭＲ１４１によって送信される応答メッセージには、あて先オプション内にＨｏＡ及びＩＤが含まれる。

ＭＲ１４２の応答メッセージの経路は、経路１５０５（単一トンネル）、１５０６（トンネルなし）である。また、ＭＲ１４１の応答メッセージの経路は、経路１５０７（単一トンネル）、１５０８（２重トンネル）、１５０９（単一トンネル）、そして最後に１５１０（トンネルなし）である。

この図から、ＭＲ１４１の応答メッセージに比べて、ＭＲ１４２からの応答メッセージが、最初にイニシエータ１８０に到着することは明らかである。最初の応答から得られるキーパラメータはＩＤ、ＭＲ１４２のＨｏＡ、ＭＲ１４２のＣｏＡ、ＭＲ１４１のＣｏＡ（ＭＣＲＤｓｔＯｐｔを有する最初のテストメッセージをデカプセル化した際に得られる）である。一方、２番目の応答メッセージ（ＭＲ１４１からの応答メッセージ）のパラメータは、ＩＤ、ＭＲ１４１のＨｏＡ、ＭＲ１４１のＣｏＡ、ＬＦＮ１５１のアドレスである。

イニシエータ１８０は、最初の応答を取得すると、ＬＦＮ１５１の値が存在しないので、この応答が所望の受信者からではないことを認識する。また、イニシエータ１８０は、ＩＤから、ＬＦＮ１５１の上流のツリー経路上に、何らかのＭＲが存在することを把握する。イニシエータ１８０は、２つの応答パラメータを分析することによって、同一のＩＤ及び所望の応答であることから、ツリー経路としてＭＲ１４２のＣｏＡ、ＭＲ１４１のＣｏＡ、ＭＲ１４１のＨｏＡ、ＬＦＮ１５１のアドレスを推測することが可能である。したがって、このような応答（単一のテストメッセージに対して、異なる各ＭＲからの複数の応答）からツリー経路を推測した後、本発明では、ＭＲ１４１への双方向トンネルを確立する際にこれらの結果が用いられる。

また、ＬＦＮ１５１にデータを送信する場合に、このトンネルが使用される。トンネルヘッダでは、あて先アドレスはＭＲ１４２のＣｏＡになり、ＲＨ２には、ＭＲ１４１のＣｏＡとＭＲ１４１のＨｏＡとが含まれる。経路最適化パスを、図２６に図示されている従来の技術のものと比較した場合、このメカニズムの利点が明瞭に示される。最適化された経路は、多数のＲＲ及びＢＵシグナリングを用いることなく形成され、必要不可欠なＲＲ及びＢＵのみが、イニシエータ及び所望の受信者の間で行われる。なお、ＭＲは、関連するＭＣＲあて先オプションを取得した後に、カウント属性やあて先アドレスを見て、直接接続されているＬＦＮ及びＶＭＮ／ＭＲを特定することが可能である。

上述のように、ＭＲは、関連するＭＣＲＤｓｔＯｐｔを取得した後に、カウント属性やあて先アドレスを参照して、直接接続されているＬＦＮ及びＶＭＮ／ＭＲを特定することが可能である。例えば、ＭＲ１４２は、カウント値２を受けるので、ＭＲ１４１のＣｏＡがＶＭＮ又はＭＲのどちらかに属し、ＬＦＮには属さないことを把握する。この場合、ＭＲ１４２は、ＭＲ１４１のＣｏＡに対して、テストメッセージ処理を開始すべきではない。

図１９、２０を用いて説明される解決策では、ＩＤを使用することによって、より簡単にツリー経路手続きの推測を行うことが可能となる一方、ツリー経路を探すノード内の状態管理アルゴリズムは、非常に複雑となり得る。また、トンネル確立のストリームのほとんどすべてにおいてＩＤの送信が行われる必要があり、帯域が浪費されるので、このメカニズムが不利な場合も存在する。さらに、完全な経路が推測されるまでノードはＩＤに関連するパラメータを保持する必要があって煩雑となる可能性があり、また、応答を受信した際にＩＤの値がチェックされる必要があって処理の複雑さが増加することになるので、ＩＤを用いた場合には状態管理が複雑となってしまう。

図２１及び本発明の実施の形態で説明されているように、本発明によれば、このようなＩＤや複雑な状態管理アルゴリズムを使用せずに、あて先のツリー経路を取得する別の方法が示される。なお、この別の方法では、あて先のツリー経路を発見する際にわずかな遅延が生じ、シグナリングがわずかながら増大するという犠牲が生じる。これは、図２０で説明されている方法（単一のテストメッセージに対して複数の応答が発生する）とは異なり、単一のテストメッセージに対して単一の応答が生成され、その結果、ツリー経路の探索時に、複数のテストメッセージ及び同数の応答が生じる。

図２１において、イニシエータ１８０は訪問リンク上に存在している。また、ＭＲ１４２及びＭＲ１４１は訪問ドメイン内に存在し、ＬＦＮ１５１はＭＲ１４２及びＭＲ１４１の下でネスト状態にある。また、ＨＡ１２１はＭＲ１４１のＨＡであり、ＨＡ１２２はＭＲ１４２のＨＡである。

イニシエータ１８０は、ＭＣＲＤｓｔＯｐｔを有するテストメッセージ１６００を送信する（ここで、例えば、ＭＣＲＤｓｔＯｐｔを付加するためにＣｏＴＩが使用される）。イニシエータ１８０は、このＭＣＲＤｓｔＯｐｔをコピー１タイプに分類し、これを識別するための適切なタイプ値（コピーフラグ）を設定する。このメッセージ１６００はＨＡ１２１に到達する。ＨＡ１２１は、自身が生成したトンネルヘッダにＭＣＲＤｓｔＯｐｔをコピーし、トンネルヘッダ内のＭＣＲＤｓｔＯｐｔのオプションタイプをコピー０タイプに設定したメッセージ１６０１を送信する。なお、コピー１タイプは、このオプションをトンネルヘッダに１回コピーすることが可能なことを意味しており、コピー０タイプは、あらゆるトンネルエントリポイントが、それぞれにおいて生成されたトンネルヘッダにこのオプションをコピーしてはならないことを意味している。

ＨＡ１２２は、カプセル化されたメッセージ１６０１を受信し、さらにパケットをトンネルする。しかし、メッセージ１６０１に含まれるコピー０タイプのＭＣＲＤｓｔＯｐｔに基づいて、ＨＡ１２２は、あて先オプションをトンネルヘッダにコピーしない。このパケット１６０２はＭＲ１４２に到達するが、トンネルヘッダにはＭＣＲＤｓｔＯｐｔが存在しないので、ＭＲ１４２は関連するパラメータを取得せず、単にデカプセル化を行い、パケット１６０３がＭＲ１４１に送信される。ＭＲ１４１は、コピー０タイプのＭＣＲＤｓｔＯｐｔを取得する。これにより、ＭＲ１４１は、イニシエータ１８０のＨｏＡのみを受信する（イニシエータ１８０によってＩＤは送信されない）。

ここで、ＭＲ１４１は、図２１で説明される別の実施の形態に示されているように、通常の応答メッセージ１６０５を送信する。この応答メッセージ１６０５はＨＡ１２２及びＨＡ１２１を通じて、それぞれ応答メッセージ１６０６、１６０７として伝送され、最終的に、応答メッセージ１６０８がイニシエータ１８０に到達する。

イニシエータ１８０は、応答メッセージ１６０８のパラメータからＭＲ１４１のＣｏＡを取得し、その後、ＬＦＮ１５１への経路上の任意の上流ＭＲの探索を試みる。このために、イニシエータ１８０は、別のテストメッセージ１６０９をＭＲ１４１のＣｏＡに送信する。その結果、ＭＲ１４２は、パケット１６１１を受信したコピー０タイプのＭＣＲＤｓｔＯｐｔを取得し、パケット１６１２、１６１３で示される応答を行う。この応答を受信すると、イニシエータ１８０は、続いてＭＲ１４２のＣｏＡに対する別のテストメッセージに係る処理を開始する（図２１には不図示）。そして、イニシエータ１８０は、あるタイムアウト期間内に応答を受信することができないので、ＬＦＮ１５１に到達可能なツリー経路を推測することができるようになる。すなわち、イニシエータ１８０は、最初の応答から、ＭＲ１４１のＨｏＡ、ＭＲ１４１のＣｏＡ、ＬＦＮ１５１のアドレスの各パラメータを取得する。また、２番目の応答から、イニシエータ１８０は、ＭＲ１４２のＨｏＡ、ＭＲ１４２のＣｏＡ、ＭＲ１４１のＣｏＡなどの各パラメータを取得する。これによって、イニシエータ１８０は、ツリー経路を推測することが可能となる。

ツリー経路を推測した後、イニシエータ１８０及びＭＲ１４１は相互に双方向トンネルを確立する。このとき、シグナリングストリーム１６１４が使用される。また、ツリー経路情報が、トンネル確立処理においても利用される。ＭＲ１４１とのトンネル確立の後に、イニシエータ１８０は、ＢＣＥ内に、ＭＲ１４２のＣｏＡ、ＭＲ１４１のＣｏＡ、ＭＲ１４１のＨｏＡ、ＬＦＮ１５１のアドレスを有することになる。トンネルされたデータメッセージ１６１５はＭＲ１４１に到達する。ＭＲ１４１は、デカプセル化を行って、ＬＦＮ１５１にデータメッセージ１６１６を伝送する。なお、このシナリオでは、ＭＲ１４２のＣｏＡがトンネルのあて先アドレスとなる。

また、図２２には、ＩＤを用いた方法を利用した場合において、最初のトンネルエントリポイントによってカプセル化された後のテストメッセージのパケット構造が示されている。パケット２０００はカプセル化されたテストメッセージのパケットを示している。

テストメッセージのパケットはカプセル化されており、テストメッセージのパケットは、ＩＰｖ６ヘッダ２００８、あて先拡張ヘッダ２００９、ＭＣＲＤｓｔＯｐｔ２０１０を有している。このＭＣＲＤｓｔＯｐｔ２０１０は、“属性１（２０１１）：テストメッセージ２０１１の送信者のＨｏＡ”、“属性２（２０１２）：ＩＤ”の２つの属性を有している。なお、属性２（２０１２）のＩＤには、例えば、シーケンスナンバー、乱数、チェックサムなどを使用することが可能である。

シーケンスナンバーの場合にはＩＤの生成は容易であるが、参照可能であるとともに、攻撃者がシーケンスを予測して攻撃に着手することが可能であるため、セキュリティ上のリスクが存在する。また、乱数の場合には、セキュリティ上のリスクはより少なくなるが、メッセージごとに乱数が生成される必要がある。また、チェックサムが使用される場合には、ＩＤの生成にハッシュアルゴリズムが使用される必要がある。なお、このチェックサム方法では、リプレイアタックが困難になるとともに、攻撃者がＩＤを予測することも困難である。したがって、チェックサム方法によれば、より強固なセキュリティが提供される。

また、これはＣｏＴＩに基づくメッセージなので、テストメッセージのモビリティヘッダ２０１３は、気付イニットクッキー２０１４を有している。また、トンネルヘッダは、トンネルＩＰｖ６ヘッダ２００１、トンネルＡＨ（Authentication Header：認証ヘッダ）２００２、トンネルあて先拡張ヘッダ２００３を有しており、トンネルあて先拡張ヘッダ２００３は、ＭＣＲＤｓｔＯｐｔ２００４を有している。さらに、トンネルのＭＣＲＤｓｔＯｐｔ２００４は、送信者のＨｏＡ（２００５：２０１１と同一）、ＩＤ（２００６：２０１２と同一）、カウント値（２００７）の３つの属性を有している。トンネルエントリポイントは、内部のＭＣＲＤｓｔＯｐｔを参照することができないので、このカウント値を生成する。

また、図２３には、ＩＤを用いないメカニズムを利用した場合において、最初のトンネルエントリポイントでトンネルされた後のテストメッセージのパケットの構造が示されている。図２３において、オリジナルのテストパケットのＭＣＲＤｓｔＯｐｔ５００８には、コピー１タイプが記載される。したがって、このパケットを受信する最初のトンネルエントリポイントは、ＭＣＲＤｓｔＯｐｔ５００８の内容を、自身が生成するトンネルヘッダにコピーして、トンネルヘッダ内のＭＣＲＤｓｔＯｐｔにコピー０タイプを記載するので、他のすべてのトンネルエントリポイントはトンネリングを行う場合に、このオプションのコピーを行わない。なお、トンネルのＭＣＲＤｓｔＯｐｔ５００４内の属性値は、内部のオリジナルのＭＣＲＤｓｔＯｐｔ５００８と同一である。

また、図２５には、ＩＤを用いた方法を利用した場合において、所望の受信者からの最初のテストパケットに対する応答パケット４０００が示されている。図２５において、応答メッセージには、（上述の別の実施の形態で説明したように）送信元アドレスとして、応答の送信者のＨｏＡが使用され、図２５に示すような構造を有している場合が多い。応答の送信者は、自身のＨＡへのトンネルによってメッセージをカプセル化する。トンネルフィールドは、トンネルＩＰｖ６ヘッダ４００１及びトンネル認証ヘッダ（トンネルＡＨ）４００２であり、実際の応答メッセージは、ＩＰｖ６ヘッダ４００３及びあて先拡張ヘッダ４００４を有している。あて先拡張ヘッダ４００４には、いくつかの応答パラメータが含まれている。あて先拡張ヘッダ４００４内の属性の１つは、応答の送信者のＨｏＡ（属性１）４００６であり、他の属性はテストメッセージで送信されたＩＤ（属性２）４００７である。

また、応答メッセージ４０００は、モビリティヘッダ４００８を有している。このタイプのモビリティヘッダ４００８には、３つのオプションが付加されている。オプション４００９は、ホームイニットクッキー（ＨｏＴＩクッキー）やホームキー生成トークンなどのＲＲ実行や最適化ＲＲに必要なオプション値を示している。また、オプション４０１０は、最初にテストメッセージが送信されたＬＦＮのアドレスを示している。また、オプション４０１１は、応答を生成しているモバイルノード（すなわち、送信者）のＣｏＡを示している。

また、図２４には、テストメッセージのあて先に設定された理想的な所望のＭＲの上流ＭＲであるＭＣＲＤｓｔＯｐｔの受信者によって生成された応答メッセージが示されている。この上流ＭＲは、上述の別の実施の形態で説明されているような更なる応答を行う必要がないので、図２５に示されているようにあて先オプション（ＲＥＳＤｓｔＯｐｔ）内にパラメータを入れる必要はない。したがって、この上流ＭＲは、すべてのパラメータをオプションとしてモビリティヘッダ３００７に挿入する。また、この応答は、送信元アドレスとしてＨｏＡが設定される。したがって、この応答は、自身のＨＡにトンネルされる必要がある。また、モビリティヘッダ３００７はオプション３００８を有している。オプション３００８には、１ホップ下流のＭＲのＣｏＡが設定される。また、オプション３００９には、送信者（当該上流ＭＲ）のＣｏＡが設定される。また、オプション３０１０には、テストメッセージで送信されたＩＤが設定される。

なお、ここでは、本発明は、最も実用的かつ好適であると考えられる実施の形態で開示及び説明されているが、当業者であれば、本発明の範囲から逸脱しない程度において、設計事項やパラメータの詳細に関して様々な変更が加えられてもよいことが分かることは明白である。

また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、自身のホームを離れている２つのエンドノードがデータ通信を行う場合に、このデータ通信の経路を最適化することができるという効果を有しており、インターネットプロトコルを利用した通信技術に適用可能であり、特に、モバイルＩＰｖ６において規定されている経路最適化に係る技術に適用可能である。

従来の技術に係るシナリオの第１の例を模式的に示すネットワーク構成図 従来の技術に係るシナリオの第２の例を模式的に示すネットワーク構成図 従来の技術に係るシナリオの第３の例を模式的に示すネットワーク構成図 従来の技術に係るシナリオの第４の例を模式的に示すネットワーク構成図 本発明の実施の形態におけるＭＨの機能アーキテクチャの一例を示すブロック図 本発明の実施の形態におけるＭＲの機能アーキテクチャの一例を示すブロック図 本発明の実施の形態におけるシナリオの第１の例を模式的に示すネットワーク構成図 図７に図示されているシナリオにおけるメッセージシーケンスの一例を示すシーケンスチャート 本発明の実施の形態におけるシナリオの第２の例を模式的に示すネットワーク構成図 本発明の実施の形態におけるシナリオの第３の例を模式的に示すネットワーク構成図 本発明の実施の形態におけるシナリオの第４の例を模式的に示すネットワーク構成図 図１０に図示されているシナリオにおいて、ＲＲ処理に係るメッセージを利用したメッセージシーケンスの第１の例を示すシーケンスチャート 図１０に図示されているシナリオにおいて、ＲＲ処理に係るメッセージを利用したメッセージシーケンスの第２の例を示すシーケンスチャート 本発明の実施の形態におけるシナリオの第５の例を模式的に示すネットワーク構成図 本発明の実施の形態において、テストメッセージとして利用されるＣｏＴＩメッセージの構造の一例を示す図 本発明の実施の形態において、テストメッセージとして利用されるＨｏＴＩメッセージの構造の一例を示す図 本発明の実施の形態における応答メッセージの構造の一例を示す図 本発明の実施の形態におけるシナリオの第６の例を模式的に示すネットワーク構成図 本発明の別の実施の形態において、ＭＲが自身のホームドメイン上に存在する場合のメッセージシーケンスの一例を示すシーケンスチャート 本発明の別の実施の形態において、ユニキャスト通信の両端が共に訪問ドメインに存在しており、一方が深いネスト状態にあるシナリオの一例を示すネットワーク構成図 本発明の別の実施の形態において、ＩＤや複雑な状態管理アルゴリズムを使用しない方法に係るメッセージシーケンスの一例を示すシーケンスチャート 本発明の別の実施の形態に係るＩＤを用いる方法を利用した場合において、最初のトンネルエントリポイントによってカプセル化された後のテストメッセージのパケット構造の一例を示す図 本発明の別の実施の形態に係るＩＤを用いないメカニズムを利用した場合において、最初のトンネルエントリポイントでトンネルされた後のテストメッセージのパケットの構造の一例を示す図 本発明の別の実施の形態において、テストメッセージのあて先に設定された理想的な所望のＭＲの上流ＭＲであるＭＣＲＤｓｔＯｐｔの受信者によって生成された応答メッセージの構造の一例を示す図 本発明の別の実施の形態に係るＩＤを用いる方法を利用した場合において、所望の受信者からの最初のテストパケットに対する応答パケットの構造の一例を示す図 従来の技術に係るシナリオの別の一例を模式的に示すネットワーク構成図

符号の説明

１００ グローバル通信ネットワーク（インターネット）
１０１、１０２ アクセスネットワーク
１０５ ホームネットワーク
１２０、１２１、１２２、１２３、１２４、１２５ ＨＡ（Home Agent：ホームエージェント）
１３０、１３１ ＡＲ（Access Router：アクセスルータ）
１４０、１４１、１４２、１４３、１４４、１４５ ＭＲ（Mobile Router：モバイルルータ）
１５０ １５１ ＬＦＮ（Local Fixed Node：ローカル固定ノード）
１７０ ＭＨ（Mobile Host：モバイルホスト）
１７１、１７２、１７３、１７４ ＶＭＮ（Visited Mobile Node：訪問モバイルノード）
１７４、１８０ イニシエータノード（イニシエータ）
２０１、３０１ 上位レイヤプロトコル
２０２ ＩＰｖ６ルーティングプロトコルモジュール
２０３、３０４ モバイルＩＰｖ６＋ＲＯモジュール
２０４ ＮＥＭＯベーシックサポートモジュール
２０５、３０５ 可動ＣＲ−ＲＯモジュール
２０６、３０６ インターネットワーキングプロトコル
３０２ ＩＰｖ６ルータ探索モジュール
３０３ ＩＰｖ６近隣探索モジュール
２０８、３０８ 下位レイヤプロトコル

Claims (20)

1. 第１通信ノードと、モバイルルータの配下に存在する第２通信ノードとの間で行われる通信の経路を最適化する通信経路最適化方法であって、
   前記第１通信ノードが、前記第２通信ノードに送信するパケットのヘッダに、前記通信の経路を最適化するために使用される情報を含む所定のあて先オプションを挿入するステップと、
   前記モバイルルータのホームエージェントが、前記第１通信ノードから前記第２通信ノードに送信される前記パケットを受信するステップと、
   前記モバイルルータの前記ホームエージェントが、前記パケットを前記モバイルルータにトンネルするために前記パケットのカプセル化を行うとともに、前記所定のあて先オプションをコピーして、トンネルパケットヘッダに前記所定のあて先オプションを挿入するステップとを、
   有する通信経路最適化方法。
2. 前記モバイルルータが、前記トンネルパケットヘッダに前記所定のあて先オプションが存在している前記パケットを検出するステップと、
   前記モバイルルータが前記第１通信ノードに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報が含まれる応答メッセージを送信するステップと、
   前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うステップと、
   前記第１通信ノード又は前記モバイルルータは、前記第１通信ノードと前記モバイルルータとの間で送信される前記パケットを、前記経路最適化によって最適化された経路を通るように発送するステップとを、
   有する請求項１に記載の通信経路最適化方法。
3. 前記第１通信ノードが、前記モバイルルータとは異なる別のモバイルルータであって、前記第２通信ノードと通信を行う配下の第３通信ノードを検出した場合に、前記第２通信ノードと前記第３通信ノードとの間の通信経路を最適化するために、前記モバイルルータとの間で経路最適化を行う請求項１に記載の通信経路最適化方法。
4. 前記第１通信ノードが、前記所定のあて先オプションが挿入される前記パケットとして、前記第２通信ノードとの間で経路最適化を行うためのメッセージに係るパケットを使用する請求項１に記載の通信経路最適化方法。
5. 前記モバイルルータが前記第１通信ノードに対して、前記第２通信ノードとの間で経路最適化を行うための前記メッセージに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報が含まれる応答メッセージを送信するステップを有する請求項４に記載の通信経路最適化方法。
6. 前記第１通信ノードが、自身のホームから離れているモバイルノードであって、前記所定のあて先オプションに自身のホームアドレスを挿入するとともに、前記所定のあて先オプションが挿入される前記パケットの送信元アドレスに自身の気付アドレスを設定する請求項１に記載の通信経路最適化方法。
7. 前記第１通信ノードが、自身のホームから離れているモバイルノードであって、前記所定のあて先オプションに暗号鍵を挿入するとともに、前記所定のあて先オプションが挿入されるパケットの送信元アドレスに自身のホームアドレスを設定する請求項１に記載の通信経路最適化方法。
8. 前記モバイルルータが、前記トンネルパケットヘッダに前記所定のあて先オプションが存在しているパケットを検出するステップと、
   前記モバイルルータが、前記暗号鍵を用いて検証用情報を生成するステップと、
   前記モバイルルータが前記第１通信ノードに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報及び前記検証用情報が含まれる応答メッセージを送信するステップとを、
   有する請求項１に記載の通信経路最適化方法。
9. 前記モバイルルータは、ホームリンクに接続されている場合には、自身が管理するモバイルネットワークの外部から到来するパケットの所定のあて先オプションを調べるステップと、
   前記パケットの前記所定のあて先オプション内に含まれているアドレスのプレフィックスが前記モバイルルータの管理するプレフィックスと一致した場合には、前記モバイルルータが前記応答メッセージを送信するステップとを、
   有する請求項２に記載の通信経路最適化方法。
10. 前記パケットを転送するすべてのモバイルルータが、前記所定のあて先オプションを含む前記パケットを転送する際に、前記第１通信ノードに対して応答メッセージを送信するステップと、
    前記第１通信ノードが各モバイルルータからの前記応答メッセージに基づいて、前記第２通信ノードまでの経路を推測するステップとを、
    有する請求項１に記載の通信経路最適化方法。
11. 前記第１通信ノードが、前記パケットのヘッダに、前記所定のあて先オプションを１回コピーすることが可能な旨を示す情報を挿入するステップと、
    前記パケットを最初に受信した任意のモバイルルータのホームエージェントが、前記パケットを前記任意のモバイルルータにトンネルするために前記パケットのカプセル化を行うとともに、前記所定のあて先オプションをコピーして、トンネルパケットヘッダに前記所定のあて先オプションを挿入し、さらに前記トンネルパケットヘッダに前記所定のあて先オプションのコピーを禁止する旨を示す情報を挿入するステップと、
    デカプセル化の後に、前記所定のあて先オプションを１回コピーすることが可能な旨を示す情報が前記ヘッダに挿入された前記パケットを転送する前記モバイルルータが、前記第１通信ノードに対して、前記第１通信ノードと前記モバイルルータとの間で経路最適化を行うための情報が含まれる応答メッセージを送信するステップとを、
    有する請求項１に記載の通信経路最適化方法。
12. モバイルノードに実装される通信経路最適化制御装置であって、
    通信相手ノードとの間で経路最適化を行うためのメッセージに係るパケットのヘッダに、前記通信ノードと前記通信ノードとの間で行われる通信の経路を最適化するために使用される情報として、前記モバイルノード自身のホームアドレス又は暗号鍵を含む所定のあて先オプションを挿入するように構成されている通信経路最適化制御装置。
13. モバイルルータに実装される通信経路最適化制御装置であって、
    前記モバイルルータ自身の配下に接続されている通信ノードと通信相手ノードとの間の通信を検出し、前記通信相手ノードとの間で経路最適化を行うためのメッセージに係るパケットのヘッダに、前記通信ノードと前記通信ノードとの間で行われる通信の経路を最適化するために使用される情報として、前記モバイルルータ自身のホームアドレス又は暗号鍵を含む所定のあて先オプションを挿入するように構成されている通信経路最適化制御装置。
14. 前記所定のあて先オプションが挿入された前記パケットを前記通信相手ノードに送信し、前記通信相手ノードに前記パケットが到達するまでに経由するモバイルルータから、前記パケットに対する応答メッセージを受信することによって、前記第２通信ノードまでの経路を推測するように構成されている請求項１２又は１３に記載の通信経路最適化制御装置。
15. 前記所定のあて先オプションが挿入された前記パケットのヘッダに、前記パケットをカプセル化する際にカプセル化ヘッダに前記所定のあて先オプションを１回のみコピーすることが可能な旨を示す情報を付加して、前記通信相手ノードに送信するように構成されている請求項１２又は１３に記載の通信経路最適化制御装置。
16. モバイルルータに実装される通信経路最適化制御装置であって、
    前記モバイルルータ配下の通信ノードに転送すべきカプセル化されたパケットのトンネルパケットヘッダに、経路最適化に使用される情報を含む所定のあて先オプションが挿入されている場合には、前記パケットの送信元に対して、前記モバイルルータ自身のホームアドレス、及び、前記モバイルルータ配下の前記通信ノードのアドレスを含む応答パケットを送信するように構成されている通信経路最適化制御装置。
17. 前記モバイルルータ自身がホームリンクに接続されている場合には、前記モバイルルータ自身が管理するモバイルネットワークの外部から到来するパケットに含まれる所定のあて先オプションを調べ、前記パケットの前記所定のあて先オプション内に含まれているアドレスのプレフィックスが前記モバイルルータの管理するプレフィックスと一致した場合には、前記応答メッセージを送信するように構成されている請求項１６に記載の通信経路最適化制御装置。
18. 前記所定のあて先オプションを含む前記パケットを転送する際に、前記パケットの送信元に対して応答メッセージを送信するように構成されている請求項１６に記載の通信経路最適化制御装置。
19. モバイルルータのホームエージェントに実装される通信経路最適化制御装置であって、
    前記モバイルルータにトンネルすべきパケットのヘッダに、経路最適化に使用される情報を含む所定のあて先オプションが挿入されている場合には、前記モバイルルータにトンネルするために前記パケットのカプセル化を行うとともに、前記所定のあて先オプションをコピーして、トンネルパケットヘッダに前記所定のあて先オプションを挿入するように構成されている通信経路最適化制御装置。
20. 前記所定のあて先オプションと共に、前記所定のあて先オプションを１回のみコピーすることが可能な旨を示す情報が付加されているパケットを受信した場合、前記パケットをカプセル化する際に、前記トンネルパケットヘッダに前記所定のあて先オプションをコピーするとともに、前記トンネルパケットヘッダに前記所定のあて先オプションのコピーを禁止する旨を示す情報を付加するように構成されている請求項１９に記載の通信経路最適化制御装置。

Images