JP4990920B2 - マルチホーム端末のためのモバイルＩＰｖ６の最適化リバース・トンネリング - Google Patents

マルチホーム端末のためのモバイルＩＰｖ６の最適化リバース・トンネリング Download PDF

Info

Publication number
JP4990920B2
JP4990920B2 JP2008557644A JP2008557644A JP4990920B2 JP 4990920 B2 JP4990920 B2 JP 4990920B2 JP 2008557644 A JP2008557644 A JP 2008557644A JP 2008557644 A JP2008557644 A JP 2008557644A JP 4990920 B2 JP4990920 B2 JP 4990920B2
Authority
JP
Japan
Prior art keywords
home agent
node
address
mobile node
correspondent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008557644A
Other languages
English (en)
Other versions
JP2009529266A (ja
Inventor
キリアン ウェニゲール
イェンス バッフマン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP06004770A external-priority patent/EP1739901B1/en
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority claimed from PCT/EP2007/001828 external-priority patent/WO2007101628A1/en
Publication of JP2009529266A publication Critical patent/JP2009529266A/ja
Application granted granted Critical
Publication of JP4990920B2 publication Critical patent/JP4990920B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は移動通信システムに関する。より詳細には、本発明は、モバイル・インターネット・プロトコル（モバイルＩＰ）又は同様のプロトコルに基づいた移動通信向けの位置プライバシー及びルート最適化に関する。
本発明について、モバイル・インターネット・プロトコル・バージョン６（モバイルＩＰｖ６）の例に関して説明する。しかし、本発明は、説明されるモバイルＩＰのエンティティに対応する等価のエンティティを定義する他のプロトコルにも適用可能である。
モバイルＩＰｖ６は、現在、双方向トンネリング及びルート最適化という、２つの動作モードを定義している。前者のモードでは、すべてのデータ・パケットが送信側移動ノードのホーム・エージェントを介してルーティングされる必要があるが、後者は、移動ノードと通信相手ノードとの間で直接パスを使用する。
移動ノード（ＭＮ）は、サブネット間を移動する場合、そのＩＰアドレスをトポロジー的に正しいものに変更しなければならない。その理由は、インターネットの階層的ルーティング構造によるものであり、すなわち、ＩＰアドレスは識別の目的で働くだけではなく、位置情報も含む。しかし、ＴＣＰなどの上位レイヤでの接続は通信ノードのＩＰアドレス（及びポート）によって定義されるため、例えば、移動によって、ノードのうちの１つがそのＩＰアドレスを変更した場合、この接続は切断される。
モバイルＩＰｖ６（Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、「Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６」、ＩＥＴＦ ＲＦＣ３７７５、２００４年６月）は、移動ノード（ＭＮ）が上位レイヤに対してトランスペアレントに、すなわち上位レイヤ接続を切断することなく、サブネット間を移動できるようにする、レイヤ３モビリティ・プロトコルである。このためＭＮは、気付アドレス（ＣｏＡ）及びホーム・アドレス（ＨｏＡ）という、２つのＩＰアドレスを使用する。ＭＮの上位レイヤは、通信相手ノード（ＣＮ）との通信にＨｏＡを使用する。このアドレスは変更されず、ＭＮを識別するために働く。このアドレスはトポロジー的には、ＭＮのホーム・ネットワーク（ＨＮ）に属する。これに対してＣｏＡは、結果としてサブネットが変更されるあらゆる移動で変更され、ルーティング・インフラストラクチャに関するロケータとして使用される。これはトポロジー的には、ＭＮが現在訪問しているネットワークに属する。ホーム・リンク上に配置されたホーム・エージェント（ＨＡ）のセットのうちの１つが、ＭＮのＣｏＡのＭＮのＨｏＡへのマッピングを維持し、ＭＮに関する着信トラフィックをその現在の位置にリダイレクトする。冗長性及びロード・バランシングのために、１つのＨＡではなくＨＡのセットを使用することができる。
モバイルＩＰｖ６は、現在、双方向トンネリング及びルート最適化という、２つの動作モードを定義する。双方向トンネリングが使用される場合、ＣＮによって送信され、ＭＮのＨｏＡにアドレス指定されたデータ・パケットは、ホーム・ネットワーク内のＨＡによってインターセプトされ、ＭＮのＣｏＡへとトンネリングされる。ＭＮによって送信されたデータ・パケットは、パケットをデカプセル化（ｄｅｃａｐｓｕｌａｔｅ）してそれらをＣＮへと送信するＨＡへ、リバース・トンネリングされる。この動作のために、ＭＮのＣｏＡに関しては、ＨＡのみに通知しなければならない。したがって、ＭＮは、バインディング・アップデート（ＢＵ）メッセージをＨＡに送信する。これらのメッセージは、ＩＰｓｅｃセキュリティ関係を介して送信され、認証される。ＣＮはＭＮのＣｏＡを認識しないため、ＭＮの位置を導出することはできず、位置プライバシーが与えられる。しかし、ＭＮがホーム・ネットワークから遠く離れており、ＣＮがＭＮに近い場合、通信パスは不必要に長くなり、結果として非効率的なルーティング及び大きなパケット遅延が生じることになる。
様々なタイプの位置プライバシーが区別できることに留意されたい。本発明が目標とする１つは、ＣＮに対してＭＮの位置（及び、それ故、ＣｏＡ）を隠すことである。他のタイプは、盗聴者に対して位置を隠すこと、又はＭＮの位置の追跡を防止することである。
ルート最適化モードは、ＣＮとＭＮの間で直接パスを使用することによって、上述の非効率性を防止することができる。したがって、ＭＮはＣＮにＢＵメッセージを送信し、その後ＣＮは、ＭＮにパケットを直接トンネリングできるようになる（実際には、ＩＰ−ｉｎ−ＩＰトンネルではなくタイプ２ルーティング・ヘッダが使用される）。もちろん、ＣＮは、モバイルＩＰｖ６ルート最適化をサポートしなければならない。ＢＵメッセージを認証するために、ＭＮ及びＣＮは、ＨｏＡ及びＣｏＡでＭＮの到達可能性をテストし、共有セッション・キーを生成する、いわゆるリターン・ルータビリティ・プロシージャを実行する。しかし、ＣＮはＢＵメッセージを利用してＭＮのＣｏＡを習得するため、その位置を導出することが可能であり、すなわち位置プライバシーは与えられない。
ＶｏＩＰなどの対話型アプリケーションはパケット遅延がわずかであることを要求するため、位置プライバシー及びルート最適化の両方を提供するメカニズムが間違いなく望ましい。この目標を達成するために様々な手法が使用可能であり、その一部は他の目的で設計されている。しかし、それらはすべて、訪問したネットワークに新しいインフラストラクチャ構成要素を導入するものである（又は既存の構成要素の変更を必要とする）。現在訪問しているネットワークがこうした構成要素を提供しない場合、位置プライバシー及びルート最適化は使用不能であり、プライバシー保護された対話型通信ができない可能性があることを意味する。こうした新しい構成要素のグローバルな配置は、すなわち各アクセス・ネットワークにおいて、長時間を要するか、又は決して実施できない可能性さえある。他のソリューションは、一方向の位置プライバシーしか提供せず、すなわち両方の通信パートナが移動体である場合、位置情報が少なくとも１つのノードにしか明らかにされない。一部の他のソリューションは、大規模に配置された場合、スケーラビリティの問題を有する。訪問したネットワークにおいて新しいか又は修正された構成要素の導入を必要とせず、両方の通信パートナが移動体である場合にも動作し、配置に関してスケーラブルである、ソリューションが望ましい。本発明は、こうしたソリューションについて説明する。
新しいインフラストラクチャ構成要素を導入する手法は、階層化モバイルＩＰｖ６（ＨＭＩＰ）、アクセス・ルータカプセル化キャッシュ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｃａｃｈｅｓ）（ＡＲＥＣ）、最適化ルート・キャッシュ（Ｏｐｔｉｍｉｚｅｄ Ｒｏｕｔｅ Ｃａｃｈｅｓ）（ＯＲＣ）、グローバル・ホーム・エージェント対ホーム・エージェント・プロトコル（Ｇｌｏｂａｌ Ｈｏｍｅ Ａｇｅｎｔ ｔｏ Ｈｏｍｅ Ａｇｅｎｔ Ｐｒｏｔｏｃｏｌ）（ＧｌｏｂａｌＨＡＨＡ）、ＷＯ０３０４１３５８、ＷＯ２００４０１０６６８、及びＵＳ２００５０４１６７５である。これらの手法について、以下で簡単に説明する。
ＨＭＩＰ（Ｈｅｓｈａｍ Ｓｏｌｉｍａｎ、Ｃｌａｕｄｅ Ｃａｔｅｌｌｕｃｃｉａ、Ｋａｒｉｍ Ｅｌ Ｍａｌｋｉ、Ｌｕｄｏｖｉｃ Ｂｅｌｌｉｅｒ、「Ｈｉｅｒａｒｃｈｉｃａｌ Ｍｏｂｉｌｅ ＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ（ＨＭＩＰｖ６）」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔｉｅｔｆ−ｍｉｐｓｈｏｐ−ｈｍｉｐｖ６−０４．ｔｘｔ、２００４年１２月）は、（潜在的に遠隔にある）ＨＡに送信されたＢＵメッセージによって生じるレイテンシ及びシグナリング・オーバヘッドを減らすために開発された。したがって、訪問したネットワーク内にモビリティ・アンカー・ポイント（ＭＡＰ）の階層を導入することによる、ローカル・モビリティ処理が提案される。ＭＮは、ローカルＭＡＰにそのＣｏＡを登録するだけでよい。ＭＡＰのサブネットから追加のＣｏＡ、いわゆる領域ＣｏＡ（ＲＣｏＡ）が取得され、ＭＡＰの領域内でのＭＮの移動性をＨＡ（又はルート最適化の場合はＣＮ）から隠すためにＭＡＰによって使用される。ＨＡ又はＣＮには依然としてＲＣｏＡがわかるため、完全な位置プライバシー・サポートは与えられない。しかし、ＲＣｏＡから導出可能な地理的領域は、実際のＣｏＡから導出可能な領域よりも大きいため、これは、制限付きの位置プライバシー・サポートとみなすことができる。
ＡＲＥＣ（ＷＯ２００４０５５９９３）（Ｇ．Ｋｒｉｓｈｎａｍｕｒｔｈｉ、Ｈ．Ｃｈａｓｋａｒ、Ｒ．Ｓｉｒｅｎ、「Ｐｒｏｖｉｄｉｎｇ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｌｏｃａｔｉｏｎ Ｐｒｉｖａｃｙ ｉｎ ＩＰ−ｂａｓｅｄ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、ＩＥＥＥ ＷＣＮＣ、２００４年３月）は、訪問したあらゆるネットワークのあらゆるアクセス・ルータ（ＡＲ）において修正を必要とする。ＣＮ及びＭＮの現在のＡＲに、それぞれバインディング情報が提供されると想定すると、データ・パケットは、ＨＡ、ＣＮ、又はＭＮの関与なしに、両方のＡＲ間でトンネリング可能である。このようにして、ＭＮとＣＮの間で直接、すなわち最短ルートが使用され、位置プライバシーがサポートされる。非常に似た手法が、ＷＯ２００４０１０６６８で提示されている。
ＯＲＣ（Ｒｙｕｊｉ Ｗａｋｉｋａｗａ、「Ｏｐｔｉｍｉｚｅｄ Ｒｏｕｔｅ Ｃａｃｈｅ Ｐｒｏｔｏｃｏｌ（ＯＲＣ）」、Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｗａｋｉｋａｗａ−ｎｅｍｏ−ｏｒｃ−０１．ｔｘｔ、２００４年１０月）が、モバイル・ネットワーク（ＮＥＭＯ）におけるルート最適化のために開発され、バインディング情報の提供を含む、訪問したネットワークのエッジ・ルータへの修正を必要とする。ＭＮは、ＣＮの現在のネットワーク（ＣＮがモバイルであると想定する）のエッジ・ルータにデータ・パケットをトンネリングし、ＣＮは、ＭＮの現在の訪問したネットワークのエッジ・ルータにデータ・パケットをトンネリングすることができる。エッジ・ルータへのパケットのトンネリングを可能にするために、各ノードは対応するエッジ・ルータのＩＰアドレスを知っている必要があり、これにより、対応するＭＮに関する位置情報が再度明らかにされる。
ＧｌｏｂａｌＨＡＨＡ（Ｐ．Ｔｈｕｂｅｒｔ、Ｒ．Ｗａｋｉｋａｗａ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、「Ｇｌｏｂａｌ ＨＡ ｔｏ ＨＡ ｐｒｏｔｏｃｏｌ」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｔｈｕｂｅｒｔ−ｎｅｍｏ−ｇｌｏｂａｌ−ｈａｈａ−００、２００４年１０月）は、複数のＨＡに、異なるトポロジー的位置からのホーム・ネットワーク・プレフィックスへのルートを通知させることにより、通常はホーム・リンクにバインドされたインターネット内のＨＡを分散させる。ＭＮは、プロキシＨＡとして働く最も近いＨＡにバインドすることが可能であり、その結果、最適化されたルートが生じる。双方向トンネリングが使用された場合、位置プライバシーが与えられる。しかし、訪問したあらゆるネットワークが他のすべての（いくつかのＭＮにとってホーム・ネットワークであるすべての）ネットワークへのルートを通知した場合、アドレス階層がそれ以上与えられないため、ルーティング・スケーラビリティの問題が生じる可能性がある。さらに、分散ホーム・ネットワークも同様に手操作で構成しなければならない。セキュアなオンデマンド構成はサポートされない。
ＷＯ０３０４１３５８では、あらゆるネットワークに、いわゆる位置プライバシー・エージェント（ＬＰＡ）及び位置プライバシー・サーバ（ＬＰＳ）が導入される。ＭＮは位置プライバシー要求メッセージをそのＬＰＡに送信し、次いでこれがＣＮに近いＬＰＡを選択する。次にこのＬＰＡのアドレスがＭＮに与えられ、次いでこれがＢＵメッセージをこのＬＰＡに送信する。したがって、この手法はＯＲＣ手法と同様であり、ＬＰＡがＣＮのネットワークに近いため、ＣＮの位置がある程度わかり、ＣＮが移動体である場合、位置プライバシー・サポートが中断される。
ＵＳ２００５０４１６７５及びＷＯ２００４０４３０１０では、ＩＰアドレスの暗号的に修正されたプレフィックスによって位置プライバシーが達成される。プレフィックスは通常、ルータがＩＰパケットをルーティングするために使用するため、この手法はインターネット内のすべてのルータを修正する必要がある。
ＷＯ０３０４４６２６では、マルチキャスト・アドレスがＣｏＡとして使用される。それらはいかなる位置情報も含まないため、ルート最適化モードでさえも位置プライバシー・サポートが与えられる。しかし、このソリューションは、大規模な配置の結果、インターネットにおいてフラット・ルーティングが生じることになるため、ＭＮの数に応じてスケーリングされない。
ＭＮがマルチホームの場合、複数のネットワーク・インターフェース、ＨｏＡ、ＨＡ、及びＣｏＡを有することが可能である。異なるネットワーク・インターフェースにわたる複数のパスが、ＭＮとＣＮの間に存在する可能性がある（図１４を参照のこと）。最適なシステム性能の場合、使用可能なすべてのインターフェース及びパスの中から最良を選択し、ルート最適化通信に使用すべきである。「最良パス」は、例えば、最短パス、又は最小遅延のパスとすることができる。このパスの選択及びセットアップが、解決すべき主要な問題である。使用されるパスに関して決定する単一の中央エンティティが存在しない（ＭＮ及びＣＮは、例えば、異なるローミング協定を有することが可能な、異なる管理ドメインに登録することが可能である）ため、この問題は分散方式で実施しなければならない。
ネットワーク内の２つのノード間の複数のパスの中から最良を見つけることは、ネットワーキングにおける古典的な問題としてみなすことができる。ＲＩＰ（ルーティング情報プロトコル）又はＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）などの分散ルーティング・プロトコルは、インターネットのドメイン内で最短パスを見つけるために使用される。しかし、それらのプロトコルは、以下のいくつかの理由により、開発中のシステムに適用することができない。
・ネットワークは、ネットワーク・ノードがモバイルＩＰｖ６であり、ＨＡ及びホストがマルチホーム・モバイルＩＰｖ６ ＭＮである、オーバレイ・ネットワークである
・リンクはマルチホップ（すなわちオーバレイ）リンクである
・リンクのコストは部分的に未知である
・位置プライバシーを保持するために、ＣＮ及びＭＮには、他のＭＮまでの距離及び（トポロジー的に正しい）そのアドレスがわかってはならない
・このソリューションは、効率的であり、ＯＲＴ及びモバイルＩＰｖ６プロトコルと互換性があるものとする。これは、これらのプロトコルに対してわずかな変更のみが行われるものであることを示唆する。
考察する他の問題は、ホーム・リンクが分散可能であること、すなわち、異なるリンク上の複数のＨＡが同じマルチホーム・ホストに関するバインディングを管理することであり、このバインディングは同じＨｏＡを有するが、ＣｏＡは異なる。これはモバイルＩＰｖ６（ＭＩＰｖ６）によってサポートされないが、このケースをサポートする（ＨＡＨＡ）などの拡張が存在する。
ＷＯ０３０４１３５８ ＷＯ２００４０１０６６８ ＵＳ２００５０４１６７５ ＷＯ２００４０５５９９３ ＷＯ２００４０４３０１０ ＷＯ０３０４４６２６ Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、「Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６」、ＩＥＴＦ ＲＦＣ３７７５、２００４年６月 Ｈｅｓｈａｍ Ｓｏｌｉｍａｎ、Ｃｌａｕｄｅ Ｃａｔｅｌｌｕｃｃｉａ、Ｋａｒｉｍ Ｅｌ Ｍａｌｋｉ、Ｌｕｄｏｖｉｃ Ｂｅｌｌｉｅｒ、「Ｈｉｅｒａｒｃｈｉｃａｌ Ｍｏｂｉｌｅ ＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ（ＨＭＩＰｖ６）」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔｉｅｔｆ−ｍｉｐｓｈｏｐ−ｈｍｉｐｖ６−０４．ｔｘｔ、２００４年１２月 Ｇ．Ｋｒｉｓｈｎａｍｕｒｔｈｉ、Ｈ．Ｃｈａｓｋａｒ、Ｒ．Ｓｉｒｅｎ、「Ｐｒｏｖｉｄｉｎｇ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｌｏｃａｔｉｏｎ Ｐｒｉｖａｃｙ ｉｎ ＩＰ−ｂａｓｅｄ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、ＩＥＥＥ ＷＣＮＣ、２００４年３月 Ｒｙｕｊｉ Ｗａｋｉｋａｗａ、「Ｏｐｔｉｍｉｚｅｄ Ｒｏｕｔｅ Ｃａｃｈｅ Ｐｒｏｔｏｃｏｌ（ＯＲＣ）」、Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｗａｋｉｋａｗａ−ｎｅｍｏ−ｏｒｃ−０１．ｔｘｔ、２００４年１０月 Ｐ．Ｔｈｕｂｅｒｔ、Ｒ．Ｗａｋｉｋａｗａ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、「Ｇｌｏｂａｌ ＨＡ ｔｏ ＨＡ ｐｒｏｔｏｃｏｌ」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｔｈｕｂｅｒｔ−ｎｅｍｏ−ｇｌｏｂａｌ−ｈａｈａ−００、２００４年１０月 Ａｕｒａ，Ｔ．、「Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓｅｓ（ＣＧＡ）」、Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ ｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｃｇａ−０６、２００４年４月 Ｊ．Ａｒｋｋｏ、Ｊ．Ｋｅｍｐｆ、Ｂ．Ｓｏｍｍｅｒｆｅｌｄ、Ｂ．Ｚｉｌｌ、Ｐ．Ｎｉｋａｎｄｅｒ、「ＳＥｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ（ＳＥＮＤ）」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｎｄｏｐｔ−０６、２００４年７月 Ｍ．Ｌｉｅｂｓｃｈ、Ａ．Ｓｉｎｇｈ、Ｈ．Ｃｈａｓｋａｒ、Ｄ．Ｆｕｎａｔｏ、Ｅ．Ｓｈｉｍ、「Ｃａｎｄｉｄａｔｅ Ａｃｃｅｓｓ Ｒｏｕｔｅｒ Ｄｉｓｃｏｖｅｒｙ」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｉｅｔｆ−ｓｅａｍｏｂｙ−ｃａｒｄ−ｐｒｏｔｏｃｏｌ−０８．ｔｘｔ、２００４年９月 Ｎｉｋａｎｄｅｒ，Ｐ．、「Ｍｏｂｉｌｅ ＩＰ ｖｅｒｓｉｏｎ ６ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｓｅｃｕｒｉｔｙ Ｄｅｓｉｇｎ Ｂａｃｋｇｒｏｕｎｄ」、２００４年１０月
本発明の目的は、訪問したあらゆるネットワークにおいて新しいか又は修正されたインフラストラクチャ構成要素の導入を必要とすることなく、モバイルＩＰｖ６などのパケット交換プロトコルに対して位置プライバシー及びルート最適化を提供することである。このソリューションは、両方の通信パートナが移動体である場合にも機能するものとし、配置、すなわちこのソリューションを使用するＭＮの数に関してスケーラブルであるものとする。また、標準のモバイルＩＰｖ６と同じレベルのセキュリティも提供し、マルチホーム端末に適用可能であるものとする。
これらの目的は、独立請求項の主題によって解決される。本発明の有利な実施形態は、従属請求項に対する主題である。
これらの目的を達成するために、本発明は、複数のモバイル・ネットワークを備える移動通信システムにおいて、マルチホーム・移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための方法、システム、装置、及びコンピュータ読み取り可能媒体を提供する。移動ノードは、そのホーム・アドレスの中から通信相手ノードと通信するために使用される１つを選択し、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録する。通信相手ノードのホーム・エージェント及び移動ノードのホーム・エージェントは、候補となるプロキシ・ホーム・エージェント・アドレスを受信し、格納する。通信相手ノードのホーム・エージェントは、通信相手ノードに要求を送信する。通信相手ノードは、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、通信相手ノードのホーム・エージェントに、気付アドレスとして登録する。次に移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントは、格納されたプロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択する。トンネルの２つのエンド・ポイントが、選択されたプロキシ・ホーム・エージェント・アドレス及び選択された移動ノードの気付アドレスのうちの１つであるように、移動ノードのホーム・エージェントは、トンネルを切り替えるために移動ノードをトリガする。トンネルの２つのエンド・ポイントが、選択されたプロキシ・ホーム・エージェント・アドレス及び選択された移動ノードの気付アドレスのうちの１つとなるように、通信相手ノードのホーム・エージェントは、トンネルを切り替えるために通信相手ノードをトリガする。
有利な実施形態では、要求は最適化リバース・トンネリング開始要求である。
他の実施形態では、移動ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップと、通信相手ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップとが、通信相手ノードが、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、通信相手ノードのホーム・エージェントに、気付アドレスとして登録する前に、実行される。
有利な実施形態では、移動ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを含む最適化リバース・トンネリング開始要求を、移動ノードによって、そのホーム・エージェントに送信するステップと、最適化リバース・トンネリング開始要求を移動ノードのホーム・エージェントによって受信し、新しい候補となるプロキシ・ホーム・エージェント・アドレスを格納するステップと、通信相手ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを、移動ノードのホーム・エージェントによって見つけるステップと、移動ノードのホーム・エージェントによって、最適化リバース・トンネリング要求を見つけられた通信相手ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスを通信相手ノードのホーム・エージェントに提案するステップとを含む。
他の有利な実施形態では、通信相手ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを含む最適化リバース・トンネリング開始応答を、通信相手ノードによって、そのホーム・エージェントに送信するステップと、最適化リバース・トンネリング開始応答を通信相手ノードのホーム・エージェントによって受信し、候補となるプロキシ・ホーム・エージェント・アドレスを格納するステップと、通信相手ノードのホーム・エージェントによって、最適化リバース・トンネリング応答を移動ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスを移動ノードのホーム・エージェントに提案するステップとを含む。
前述の実施形態の変形形態では、移動ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードによって、そのホーム・エージェントに送信するステップと、移動ノードのホーム・エージェントによって、候補となるプロキシ・ホーム・エージェント・アドレスを受信及び格納するステップと、通信相手ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを、移動ノードによって見つけるステップと、移動ノードによって、最適化リバース・トンネリング要求を見つけられた通信相手ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスを通信相手ノードのホーム・エージェントに提案するステップとを含む。
他の有利な実施形態では、通信相手ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを、通信相手ノードによって、そのホーム・エージェントに送信するステップと、通信相手ノードのホーム・エージェントによって、候補となるプロキシ・ホーム・エージェント・アドレスを受信及び格納するステップと、移動ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを、通信相手ノードによって見つけるステップと、通信相手ノードによって、最適化リバース・トンネリング応答を移動ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスとして周知のホーム・エージェントを、移動ノードのホーム・エージェントに提案するステップとを含む。
本発明の他の有利な実施形態では、格納されたプロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントの両方での通信相手ノードの気付アドレスのうちの１つを選択するステップが、最短パスを見つけるために実行される。
上記に関する変形形態では、格納されたプロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントの両方での通信相手ノードの気付アドレスのうちの１つを選択するステップが、最小遅延のパスを選択するために実行される。
他の有利な実施形態では、通信相手ノードのホーム・アドレスのうちの１つが、通信相手ノードのホーム・エージェントが通信相手ノードに要求を送信する前に選択される。
他の有利な実施形態では、移動ノードのホーム・エージェントが、信頼できないプロキシ・ホーム・エージェントを拒否する。
他の有利な実施形態では、通信相手ノードのホーム・エージェントが、信頼できないプロキシ・ホーム・エージェントを拒否する。
本発明の他の実施形態は、通信相手ノードと通信するために使用されるホーム・アドレスのうちの１つを選択するように適合された選択手段と、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録するように適合された格納手段とを備える移動ノードに関する。
本発明の他の実施形態は、開始要求を通信相手ノードに送信するように適合された伝送手段と、プロキシ候補となるホーム・エージェント・アドレスを受信するように適合された受信手段と、プロキシ候補となるホーム・エージェント・アドレスを格納するように適合された格納手段と、プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するように適合された選択手段と、トンネルの２つのエンド・ポイントが選択されたプロキシ・ホーム・エージェント・アドレス及び通信相手ノードの気付アドレスのうちの１つであるように、トンネルを切り替えるために通信相手ノードをトリガするように適合されたトリガ手段とを備える通信相手ノードのホーム・エージェントに関する。
本発明の他の実施形態は、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、通信相手ノードのホーム・エージェントに、気付アドレスとして登録するように適合された格納手段を備える通信相手ノードに関する。
本発明の他の実施形態は、プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するように適合された選択手段と、トンネルの２つのエンド・ポイントが選択されたプロキシ・ホーム・エージェント・アドレス及び通信相手ノードの気付アドレスのうちの１つであるように、トンネルを切り替えるために移動ノードをトリガするように適合されたトリガ手段とを備える移動ノードのホーム・エージェントに関する。
他の有利な実施形態では、移動ノード、通信相手ノードのホーム・エージェント、通信相手ノード、及び移動ノードのホーム・エージェントが、命令を格納したコンピュータ読み取り可能媒体を備える。
添付の図面は、本発明の原理を説明するために本明細書に組み込まれ、その一部を形成する。この図面は、本発明がどのように作成及び使用できるかについて図示及び説明された例に本発明を限定するものと解釈されるべきではない。添付の図面に示された他の特徴及び利点は、本発明の以下のさらに特定の説明から明らかとなるだろう。
本発明の例示的実施形態について図面を参照しながら説明するが、この図面では、類似の要素及び構造は類似の参照番号で示されている。
最適化リバース・トンネリング（ＯＲＴ）は、第１に、ＭＮ及びＣＮのプライバシー並びにルート最適化の要件をネゴシエートするために、ＭＮ又はＭＮのＨＡとＣＮ又はＣＮのＨＡとの間にいくつかの初期シグナリングを必要とする。このシグナリング及び追加の距離情報に基づいて、候補となるシナリオ及びそれに続く候補となるプロキシＨＡが決定される。個々の候補となるプロキシＨＡを介するルート長さが決定された後、プロキシＨＡトンネルが切り替えられるかどうか、及びどのプロキシＨＡトンネルに切り替えられるかが決定される。その後バインディング情報が送信され、トンネルは選択されたターゲット・プロキシＨＡに切り替えられる。移動性によりルート長さは動的であり、プロセスは特定の時間的インスタンスで繰り返さなければならない。
以下では、個々のプロシージャ、すなわち要求条件及び候補となるシナリオのネゴシエーション、候補となるプロキシＨＡの発見、距離情報／ルート長さに基づくターゲット・プロキシＨＡの決定、ターゲット・プロキシＨＡにおけるバインディング情報のセキュアな確立、並びに、トンネルの切り替えについて説明する。プロシージャは、ＭＮ制御又はＨＡ制御のいずれかで実現することができる。最後に、移動性が存在する場合にどのようにルートを適合できるかについて説明する。
ＣＮが移動体であるか、又はＣＮがたとえホームにある場合であってもＯＲＴをサポートするためにＨＡに登録するかのいずれかによって、ＨＡがＣＮに割り当てられることが想定される。そうでない場合、初期ネゴシエーション段階でＯＲＴは拒否される。
要件及び候補となるシナリオのネゴシエーション
開始のシナリオは、常に双方向トンネリング・モードの標準モバイルＩＰである。図１及び図４は、どちらも外部ネットワーク１０７及び１０８内にあるＭＮ１０１とＣＮ１０２との間の、このモードでのデータ・パスを示す。ＭＮは、そのＨＡ１０３へのＣＮのＨｏＡにアドレス指定されたすべてのデータ・パケットをリバース・トンネリングし、それらをデカプセル化及び転送する。ルーティング・インフラストラクチャは、パケットをＣＮのホーム・ネットワーク１０６にルーティングし、そこでＣＮのＨＡ（ＣＨＡ）１０４がそれらをインターセプトし、ＣＮのＣｏＡへとトンネリングする。他方向のデータ・パケットは、それに応じて処理される。
図１及び図４は、それぞれのネットワーク間の異なる距離に対して同じルーティング構成を示す。図１では、ＭＮの訪問ネットワーク１０７からそのホーム・ネットワーク１０５の方が、ＣＮの訪問ネットワーク１０８からＣＮのホーム・ネットワーク１０６よりも近い。図４では、ＭＮ及びＣＮのどちらも、それぞれのホーム・ネットワークまでよりも、相互間の方が近い。さらに、訪問ネットワークは、特別な場合にホーム・ネットワークと同一である可能性があることにも留意されたい。１つのＭＮについてこれが当てはまる場合、図１に示されたような状況になる。ＭＮ及びＣＮがどちらもそれぞれのホーム・ネットワークにある場合、ＯＲＴは従来のモバイルＩＰルーティングよりも短いルーティングを提供することができない。しかし、位置プライバシーの目的で、少なくともＭＮ及びＣＮの見地から、全体のルーティング・プロシージャはすべてのケースで同一でなければならない。
ＭＮ又はＨＡがＯＲＴを要求する場合、プロセスは、ルート最適化及びプライバシー要件のネゴシエーションで開始される。前者は、例えば、ホップにおける最大ルート長さを指定することが可能であり、後者はプライバシーが必要であるかどうか及びどの種類のプライバシーが必要であるかを指定することができる（ＭＮの位置をＣＮ又は盗聴者に隠すか、あるいは位置追跡を防ぐ）。この情報及び追加の距離情報に基づいて、ＣＮ及びＭＮのオリジナルＨＡは、ルート最適化のための候補となるシナリオを選択する。全体としての概念をこれらのシナリオに制限するわけではないが、次に、異なるプロキシＨＡ位置の以下のシナリオについて考察する。
ａ）それぞれＭＮ１０１及びＣＮ１０２のホーム・ネットワーク１０５及び１０６内に配置された２つの単方向トンネリング・プロキシＨＡ１０３及び１０４（図２を参照のこと）
ｂ）それぞれＭＮ１０１又はＣＮ１０２のホーム・ネットワーク１０５又は１０６内に配置された１つの双方向トンネリング・プロキシＨＡ１０３又は１０４（図３を参照のこと）
ｃ）それぞれＭＮ１０１及びＣＮ１０２の現在の訪問ネットワーク１０７及び１０８に配置された２つの双方向トンネリング・プロキシＨＡ ５０１及び５０２（図５を参照のこと）
ｄ）それぞれＭＮ１０１又はＣＮ１０２の現在の訪問ネットワーク１０７又は１０８内の１つの共通双方向トンネリング・プロキシＨＡ ６０１（図６を参照のこと）
ｅ）ＭＮ１０１とＣＮ１０２の間のネットワーク７０２内の１つの共通双方向トンネリング・プロキシＨＡ ７０１（図７を参照のこと）
シナリオａ）及びｂ）は、図１に示されるような距離状況において最も有利に適用可能である。図４に示されたような状況では、シナリオｃ）、ｄ）、及びｅ）がより短いルートにつながる可能性がある。
候補となるシナリオの順序付けられたリストは、距離情報及び他の情報に基づいて構築することができる。以下の原理を使用して、ターゲット・シナリオを選択することが可能である。シナリオａ）及びｂ）は、ＭＮ及びＣＮの両方がホームから遠い場合、最適なルート長さが達成できない場合がある。シナリオａ）及びｂ）が望ましいルート最適化の程度を達成しない場合、シナリオｃ）及びｄ）を考慮の対象とすることができる。しかし、それらは、訪問ネットワークがこのソリューションをサポートしている場合にのみ使用可能である。シナリオｄ）は、ノードのうちの一方（そのネットワーク内に共通プロキシが配置されているノード）が、他方のノードには、受信したトンネリングされたパケットからこのネットワークのプレフィックスがわかることから、プライバシー要件を有さない場合にのみ使用可能である。シナリオｅ）は、両方の訪問ネットワークがＯＲＴをサポートしておらず、ＭＮ及びＣＮの両方がプライバシー要件を有する場合にのみ使用可能である。しかし、問題は、プロキシＨＡを提供することが可能な訪問ネットワーク間のネットワークを決定することである。
シナリオｂ）、ｄ）、及びｅ）は、それぞれのシナリオが現在アクティブであることをＭＮ及びＣＮが知っている場合、完全な位置プライバシーを達成できない場合があることに留意されたい。例えば、図３では、ＣＮ１０２はＭＮ１０１に関する何らかの位置情報を有し、ＣＮは、ＭＮのＨＡ１０３を介するパスがＣＮのＨＡ１０４を介するパスよりも短くなければならないことを知っており、さらにＭＮのＨＡ及びＣＮのＨＡまでの距離を知っている。それ故、ＭＮがＭＮのＨＡ又はＣＮのＨＡのいずれに近いかを結論付けることができる。解決策としては、ＭＮ及びＣＮの両方がどのシナリオが現在アクティブであるかを知ってはならないか、又はパス上の追加のプロキシＨＡを中継として使用しなければならないかのいずれかである。
ＨＭＩＰをサポートするネットワーク内のモビリティ・アンカー・ポイント（ＭＡＰ）は、プロキシＨＡを同一場所に設置できることにも留意されたい。
ＨＡ制御及びＭＮ制御の変形例における初期ネゴシエーションの例が、それぞれ図８及び図９に示されている。
どちらの場合も、各移動ノードとそのＨＡとの間にすでにセキュリティ関係８０１、８０２が存在している。
図８に示されたＨＡ制御の変形例では、ＭＮ１０１はオプションでＯＲＴ初期化要求８０３をそのＨＡに送信することができる。この要求は、ＭＮ及びＣＮのホーム・アドレスを備える。その後、ＭＮのＨＡ１０３は、ＭＮのプライバシー及びルート最適化（すなわち最大ルート長さ）要件を伴う両方の移動ノードのホーム・アドレスと、ＩＰアドレスなどのＭＮのＨＡの識別子と、そのネットワーク内でＨＡとして動作することが許可されていることを証明するための許可証明とを備える署名付きＯＲＴ要求８０４をＣＮのＨＡ１０４に送信する。この要求を受信すると、ＣＮのＨＡ１０４はオプションで、ＯＲＴ初期化要求８０５をＣＮ１０２に送信し、状況コードを含むＯＲＴ初期化応答８０６をＣＮ１０２から受信する。次にＣＮのＨＡ１０４は、要求８０４に対するＯＲＴ応答８０７を、ＭＮのＨＡ１０３に返送する。この応答も署名付きであり、ＣＮのＨＡ１０４の識別子及び許可証明と共に、ＣＮのプライバシー及びルート最適化要件を備える。ＭＮがＯＲＴ初期化要求８０３を送信した場合、次に状況コードを含む応答８０８をそのＨＡ１０３から受信する。ＨＡ１０３と１０４両方の間にセキュリティ関係８１０が存在しない場合、例えば、インターネット鍵交換（ＩＫＥ）並びに両方のエンティティの秘密鍵及び公開鍵を使用して、ステップ８０９で確立される。ステップ８１１における両方のＨＡの間でのバインディング・アップデート情報の保全性保護交換には、何らかの種類のセキュリティ関係１１０が必要である。これは、ＢＵメッセージに、対応する公開鍵で直接署名することによっても達成可能である。次に、各ＨＡ１０３、１０４はステップ８１２及び８１３で、それぞれの他方のＨＡまでの距離、並びにＭＮ１０１及びＣＮ１０２の両方までの距離を決定し、ステップ８１４及び８１５で、その結果をそれぞれ他方のＨＡに報告する。この情報は、ステップ８１６でＨＡの候補となるシナリオを決定するために使用される。
図９のＭＮ制御の変形例では、両方の移動ノードのホーム・アドレスを含むＯＲＴ要求９０１が必須である。これは、ＭＮのＨＡを通してＣＮのＨＡへとリバース・トンネリングされる。ＣＮのＨＡ１０４及びＣＮ１０２は、ＯＲＴ初期化要求８０５、及びオプションでそれへの応答８０６を交換することができる。いずれの場合も、次にＣＮのＨＡ１０４は、ＣＮのＨＡ１０４の識別子と、許可証明と、要求が受け入れられたかどうかの状況情報とを含むＯＲＴ要求９０１への応答９０２を、ＭＮ１０１に戻す。この要求が受け入れられた場合、ＭＮ１０１及びＣＮのＨＡ１０４はリターン・ルータビリティ・プロシージャ９０３を実行する。その後、セキュリティ関係９０４がＭＮ１０１とＣＮのＨＡ１０４との間に存在する。ＭＮは、プライバシー及びルート最適化要件９０５、並びにＢＵ情報９０６をＣＮのＨＡに送信する。ＣＮからＭＮのＨＡへのデータ・パケットのルーティングの場合、ステップ９０１〜９０６と対称のステップ９０７〜９１２が実行される。ＭＮ制御の場合、ＭＮ１０１及びＣＮ１０２は、ステップ９１３及び９１４で、ＨＡ１０３及び１０４の両方へのルーティング距離をそれぞれ決定し、ステップ９１５〜９１８で、この情報を両方のＨＡに報告する。この情報は、ステップ８１６で、ＨＡにおいて候補となるシナリオを決定するために使用される。
候補となるプロキシＨＡの発見
候補となるシナリオが決定された後、候補となるプロキシＨＡが発見される。第１に、これらのＨＡのプレフィックスがわからなければならない。シナリオａ）及びｂ）では、プレフィックスはＭＮ及びＣＮのＨｏＡから導出することが可能であり、シナリオｃ）及びｄ）では、ＭＮ及びＣＮのＣｏＡから導出することが可能である。シナリオｅ）では、プレフィックスを決定するのはさらに困難である。１つのオプションは、中間ネットワークのプレフィックスを発見するために、ＭＮ内のＨＡとＣＮの訪問ネットワークとの間でトレースルート・プロシージャをトリガすることである。他のオプションは、各ＨＡ内で候補となるプロキシＨＡプレフィックスのリストを構成し、このリストから好適な候補を見つけ出すことである。これにはかなり量のシグナリングが必要であり、成功しない確率が高いため、シナリオｅ）は、他のすべてのシナリオが適用できない場合にのみ使用するべきである。
プレフィックスがわかった場合、特定の候補となるプロキシＨＡのＩＰアドレスを決定しなければならない。プレフィックスが現在の訪問ネットワークと一致するという特殊なケースでは、プロキシＨＡは、例えば、ルータ通知（ＲＡ）メッセージに含まれる情報を利用する、ローカル手段によって発見することができる。その他の方法では、ＤＮＳを使用することができるが、これはすべてのＨＡアドレスを必要とするため、それらのプレフィックスがＤＮＳに格納される。現在では、このケースは当てはまらない。他のオプションは、エニーキャスト（ａｎｙｃａｓｔｉｎｇ）を使用する、ＲＦＣ３７７５に記載されたＤｙｎａｍｉｃ Ｈｏｍｅ Ａｇｅｎｔ Ａｄｄｒｅｓｓ Ｄｉｓｃｏｖｅｒｙ（ＤＨＡＡＤ）の修正バージョンを使用することである。複数のＨＡがリンク上に存在する場合、そのリンク上で、現在では特定のＭＮ又はＣＮのトンネルの宛先である、特定のＨＡを見つけなければならないことに留意されたい。シナリオａ）及びｂ）では、これは、例えば、ＣＮのＨｏＡに要求メッセージを送信すること、及びＣＮのＨＡの要求のインターセプトを可能にすることにより達成することができる。
ターゲット・プロキシＨＡの選択
候補となるプロキシＨＡが決定された後、特定のターゲット・プロキシＨＡを選択しなければならない。これは、例えば、２つのプロキシを使用するシナリオから、１つのプロキシを使用するシナリオに変更する場合、距離情報に基づいて実行することが可能であり、より短いルートを提供するものが選択される。したがって、ｐＨＡ１及びｐＨＡ２が候補となるプロキシＨＡである場合に、距離ＭＮ＜−＞ｐＨＡ１、ＣＮ＜−＞ｐＨＡ１、ＭＮ＜−＞ｐＨＡ２、及びＣＮ＜−＞ｐＨＡ２が、ＭＮ、ＣＮ、及びＨＡによって測定される。距離はホップ数で表すことができるが、パケット遅延などの他の測定基準で定義することもできる。ホップ数は、シグナリング・メッセージ又はトンネリングされたデータ・パケットのＩＰヘッダ内のホップ制限フィールドから受動的に導出するか、又はプローブ・メッセージを送信することによって能動的に測定することができる。受動的な手法の場合、例えば、新しいモビリティ・オプションとして、送信側によって使用された初期のホップ制限値が受信側にとって未知である可能性があるため、この値をメッセージに含めることが必要な場合がある。プローブ・メッセージは、ＭＮ及び／又はＨＡによって送信可能である。しかし、ＣＮに関与する距離によって、ＭＮがＣＮの位置をある程度導出できるようにすることから、この距離はＭＮに対して明らかでないはずであることを考慮しなければならない。ＭＮ及びＣＮ（オリジナル）のＨＡはすべての距離情報を収集し、どのｐＨＡがより短いルートを提供するかを決定するが、（ＭＮ＜−＞ｐＨＡ１）＋（ｐＨＡ１＜−＞ＣＮ）＜（ＭＮ＜−＞ｐＨＡ２）＋（ｐＨＡ２＜−＞ＣＮ）の場合、ルート最適化に関してはｐＨＡ１の方が好ましく、そうでない場合はｐＨＡ２の方が好ましい。距離情報は、将来の他のノードのＯＲＴセッションでのシグナリング作業を節約するために、ＨＡにキャッシュすることも可能である。
距離情報を収集するためのシグナリング流れの例は、図８及び図９の初期ネゴシエーション流れに示されており、上記で説明している。
ターゲット・プロキシＨＡにおけるバインディング情報の確立
ターゲット・プロキシＨＡのアドレスがわかると、ＭＮ制御の変形例ではＭＮによって、又はＨＡ制御の変形例ではそのＨＡによって、バインディング・アップデート（ＢＵ）メッセージをこのアドレスに送信することができる。バインディング情報を受信した後、プロキシＨＡはＭＮに関するプロキシ隣接通知を送信しないことに留意されたい。プロキシ機能は、ＭＮのオリジナルＨＡに代わるトンネリングのみを言い表す。
バインディング情報をセキュアに送信するためには、様々な問題を考慮しなければならない。第１に、悪意あるノードによるインターネット・ルータ（ここでは、プロキシＨＡ）へのルートの投入を防止しなければならない。そうでない場合、このノードは、例えば、トラフィックを分析又は改ざんし、これを被害者に返送するために、トラフィックを他の悪意あるノードにリダイレクトする可能性がある。攻撃者は、例えば、低帯域インターネット接続を有することから、大量のトラフィックを処理できない被害者に、トラフィックをリダイレクトする可能性もある。
これを防ぐために、ＢＵの送信側はプロキシＨＡで認証し、ＭＮ制御の変形例の場合、これが実際に請求されたＨｏＡを所有していることを証明しなければならない。ＭＮが実際に請求されたＣｏＡを所有しているかどうかをチェックするために、追加の到達可能性テストを実施することができる。認証及び送信側アドレス所有証明は、公開／秘密鍵及びＩＤ証明によって達成可能であり、ＩＤ証明は公開鍵を送信側アドレスにバインドし、ＢＵは秘密鍵を使用して署名される。ＩＤ証明の代替は、公開鍵を送信側のアドレスにバインドする、Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓｅｓ（ＣＧＡ）（Ａｕｒａ，Ｔ．、「Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓｅｓ（ＣＧＡ）」、Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ ｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｃｇａ−０６、２００４年４月）である。ＣＧＡは、ＨｏＡのインターフェース識別子を認証するのみであるため、アドレスのプレフィックスが正しいことを証明するために追加の到達可能性テストを実施するべきである。鍵及び証明の割り振りには、割り振り数に応じて増加する、大量の管理作業を必要とするため、この手法は、ＨＡ制御の変形例にのみ適用するべきである。この場合、鍵及び証明は、すべてのＭＮではなくＨＡにのみ割り振ればよい。
ＭＮ制御の変形例の場合、ＣｏＡ及びＨｏＡのチェック並びにＢＵメッセージの認証は、ＲＦＣ３７７５に記載されたルート最適化モードで使用されるリターン・ルータビリティ・プロシージャを利用することによって達成可能である。しかし、ＲＦＣ３７７５におけるリターン・ルータビリティ・プロシージャが、ＭＮ−ＣＮ及びＭＮ−ＨＡ−ＣＮの両方のパスを盗聴できる攻撃者に対する耐性がないことは周知である。ＲＦＣ３７７５では、ＭＮとＨＡの間のパスはＩＰＳｅｃ ＳＡによって保護される。それ故、ＨＡとＣＮの間のパスのみが重要である。さらに、ルーティング・インフラストラクチャはネットワーク・オペレータによって良好に機密保護されているため、通常、攻撃者はネットワークの端部にいる。それ故、攻撃者にとっての重要ポイントは、ＣＮの接続ポイントである。ルートはホスト（例えば、ＣＮ）だけではなく、インターネット・ルータ（ここでは、プロキシＨＡ）にも投入されることから、攻撃者にさらにオプションを与えるため、本発明ではこの問題は特に課題となる。幸いなことに、ＲＦＣ３７７５とは対照的に、本発明におけるプロシージャはＭＮとＣＮの間ではなく、ＭＮと、通常はネットワーク又はルーティング・インフラストラクチャ内に配置されるプロキシＨＡとの間で、実行される。したがって、（本発明で実行されるような）プロキシＨＡをターゲットとするリターン・ルータビリティ・プロシージャの方が、（ＲＦＣ３７７５で実行されるような）ＣＮをターゲットとするよりも、よりセキュアであるとみなされる。
他の課題は、ＭＮにとって、他のＭＮのＣｏＡ（及びその位置）を見つけ出すために、プロキシＨＡであるように首尾よく見せかけることは不可能なはずである、ということである。このため、ＢＵメッセージの受信側は、ネットワーク・オペレータの有効な（プロキシ）ＨＡであることを証明しなければならない。これは、ネットワーク・オペレータによって発行される許可証明を使用して達成可能である。こうした証明は、（Ｊ．Ａｒｋｋｏ、Ｊ．Ｋｅｍｐｆ、Ｂ．Ｓｏｍｍｅｒｆｅｌｄ、Ｂ．Ｚｉｌｌ、Ｐ．Ｎｉｋａｎｄｅｒ、「ＳＥｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ（ＳＥＮＤ）」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｎｄｏｐｔ−０６、２００４年７月）又は（Ｍ．Ｌｉｅｂｓｃｈ、Ａ．Ｓｉｎｇｈ、Ｈ．Ｃｈａｓｋａｒ、Ｄ．Ｆｕｎａｔｏ、Ｅ．Ｓｈｉｍ、「Ｃａｎｄｉｄａｔｅ Ａｃｃｅｓｓ Ｒｏｕｔｅｒ Ｄｉｓｃｏｖｅｒｙ」、ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｄｒａｆｔ−ｉｅｔｆ−ｓｅａｍｏｂｙ−ｃａｒｄ−ｐｒｏｔｏｃｏｌ−０８．ｔｘｔ、２００４年９月）でも使用される。２つの証明、許可及びＩＤ証明は、ネットワーク・オペレータ用のＨＡとして働くことをＨＡに許可し、公開鍵をＨＡアドレスにバインドすることができる。公開鍵を使用して、ＨＡ制御の変形例におけるＢＵ情報の交換を機密保護するために、ＨＡ間のＩＰｓｅｃセキュリティ関係を初期化することができる。ＩＰｓｅｃセキュリティ関係を確立する代わりに、秘密鍵を使用してシグナリング・メッセージに直接署名することもできる。
これらのメッセージは、その時だけノンス（ｎｏｎｃｅ）及び／又はタイムスタンプをＯＲＴ要求／応答メッセージに追加することによって、攻撃の制限を防ぐことができる。リソースを枯渇させるＤｏＳ攻撃は、もう１つのセキュリティ問題である。メモリの枯渇を防ぐために、ＯＲＴのイニシエータが認証されていることを証明する前に、ＨＡには何の状態も確立されていてはならない。ＨＡ制御の変形例では、ＯＲＴ要求は署名され、この証拠を提供できる証明を含む。ＭＮ制御の変形例では、ＯＲＴ要求はＨＡ内に状態を確立しない。状態は、この証拠を提供するリターン・ルータビリティ・プロシージャ後にのみ確立される。しかし、証明の検証及び公開鍵の署名には、大量のＣＰＵリソースが必要であり、ＣＰＵを枯渇される攻撃に活用される可能性がある。ＭＮ制御の変形例では、ＭＮは要求メッセージを送信した後に証明を検証するだけでよいため、この攻撃はＨＡ制御の変形例におけるＨＡにのみ影響を与える。実際にターゲット・アドレスが、受信側ＨＡによって管理されるＣＮのアドレスであるかどうかを、ＯＲＴ要求の受信時に最初にチェックするという対策が可能である。これに当てはまらない場合、証明をチェックすることなく要求を拒否することができる。この方法では、攻撃者は第１に、被害者のバインディング・キャッシュに関するある程度の知識を有する必要がある。ＯＲＴ応答メッセージは、有効な証明を備えた対応する（連続番号で示された）要求があらかじめ送信されている場合にのみ、処理されるものとする。他の対策は、ＯＲＴ要求メッセージの受信側が検証に使用するリソースの量に制限を設定することである。この手法は、モバイルＩＰｖ６ルート最適化モードに対する同様の攻撃（「不必要なバインディング・アップデート攻撃」）に対する対策としても使用される（Ｎｉｋａｎｄｅｒ，Ｐ．、「Ｍｏｂｉｌｅ ＩＰ ｖｅｒｓｉｏｎ ６ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｓｅｃｕｒｉｔｙ Ｄｅｓｉｇｎ Ｂａｃｋｇｒｏｕｎｄ」、２００４年１０月を参照のこと）。
増幅を利用する反射攻撃は、応答／肯定応答が常にほぼ同じか又は小さいサイズの単一のパケットで応答され、要求の送信側アドレスに送信されることを確実にすることによって防止される。
ＭＮとプロキシＨＡとの間で送信されるいかなるシグナリング・メッセージ、例えば、移動後のＢＵメッセージも、以前に確立されたセキュリティ関係を使用することによって認証されて送信されるべきであることに留意されたい。ＭＮ制御の変形例では、ＭＮ及びプロキシＨＡは直接セキュリティ関係を有するが、ＨＡ制御の変形例ではこれは当てはまらない。したがって、すべてのシグナリング・メッセージはＭＮのオリジナルＨＡを通して現在のプロキシＨＡに進まなければならない。またＭＮが移動する場合も、依然としてＢＵをそのオリジナルＨＡに送信する。ＨＡ制御の変形例では、その後オリジナルＨＡはＢＵをプロキシＨＡに転送する。ＭＮ制御の変形例では、ＭＮ自体がＢＵをそのオリジナルとそのプロキシの両方のＨＡに送信する。
ＨＡ制御及びＭＮ制御の変形例で、シナリオｃ）〜ｅ）を達成するためのシグナリング流れの例は、図１１及び図１２に示される。ターゲットのシナリオがａ）又はｂ）の場合、バインディング情報は初期ネゴシエーション時にすでにプロキシＨＡに送信されている。
トンネル・エンド・ポイントのターゲット・プロキシＨＡとの間での切り替え
バインディング情報がターゲット・プロキシＨＡ内で確立された後、パスの最適化のために、トンネル・エンド・ポイントをこのターゲット・プロキシに切り替えることができる。個々のＩＰ−ｉｎ−ＩＰトンネルは常に単方向であるため、入口ポイント又はソースと、出口ポイント又は宛先とを有する。ＩＰ−ｉｎ−ＩＰトンネルの確立又は削除には、通常、トンネルの入口ポイントでのアクションのみが必要である。しかし、トンネリングされたパケットのソースと予想されるトンネル入口ポイントとを比較することができるため、出口ポイントに通知するべきである。ＩＰｖ６のトンネリングに関する一般的なメカニズムは、ＲＦＣ２４７３に指定されている。
以下の２つのタイプのトンネル切り替えを区別することができる。
１）トンネルのソースが１つのプロキシＨＡから他方へ移動される
２）トンネルの宛先が１つのプロキシＨＡから他方へ移動される
トンネル確立要求メッセージはトンネルの新しいソースに送信され、トンネル削除要求メッセージはトンネルの現在のソースに送信される。さらに、トンネル切り替え通知メッセージは新しいトンネルの宛先に送信される。すべてのトンネル要求メッセージは、トンネルの対応するエンド・ポイントのアドレスを含む。通常、プロキシＨＡは、１つのノードのトンネルのソース及び他方のノードのトンネルの宛先である。可能であれば、メッセージは他のメッセージと集合することができる。ＭＮ−ＣＮパス全体のパケット損失を防ぐために、トンネルのあらゆる切り替え（例えば、ＭＮ−ｐＨＡ）は、通信相手ノードのトンネルの切り替え（例えば、ｐＨＡ−ＣＮ）と同期されるべきである。したがって、あらゆる要求／通知メッセージには、状況コードを含む肯定応答メッセージで応答しなければならない。この状況コードは、プロキシＨＡの着信トンネル及び発信トンネルの両方がセットアップされた場合、成功したトンネル確立のみを示すことができる。さらに、ＭＮ及びＣＮは、状況がＭＮ−ＣＮパス全体の成功したセットアップを示す前に、それらの発信トンネルを切り替えてはならない。
他のノードから着信するか又は他のノードへ送信されるデータ・パケットは、デフォルトでは、依然としてオリジナルのＨＡを通してルーティングされることに留意されたい。トンネル切り替えは特定のＭＮ−ＣＮ通信セッションのみに適用されるため、プロキシＨＡの転送機能は、ＩＰヘッダ内のソース・アドレスも考慮すべきである。
ＨＡ制御及びＭＮ制御の変形例に関するシグナリング流れの例は、シナリオａ）及びｂ）については図１０に、シナリオｃ）〜ｅ）については図１１及び図１２に、それぞれ示されている。
移動性が存在する場合のパスの適合
一般にＯＲＴは、常時バックグラウンドで実行することができる。接続確立直後に通信パートナによって、又は後にオンデマンドでトリガすることができる。ＭＮは移動体である可能性があるため、しばらく後に最適化ルート長さは最適でなくなる可能性があり、ＯＲＴの再実行が必要になる。しかし、何らかのシグナリングが必要であるため、プロシージャの反復はできる限り頻度を少なく、通信セッションが長い期間続く場合のみとすべきである。さらに、恩恵が少ない場合、すなわちパスが短くならないか又はわずかに短くなるだけの場合は、プロシージャを実行すべきではない。
恩恵は、候補となるプロキシＨＡを通してルート長さを測定するプロシージャを反復することによって決定することができる。潜在的に、ターゲット・シナリオも変更しなければならない。１つの手法は、上記で詳細に説明した距離測定プロシージャを定期的に反復することである。これは、両方のＭＮが絶えず移動している場合、及び現在のパスと最適化されたパスとの差がほぼ直線的に増加する場合、効率的であるとみなされる。他の方法は、ハンドオーバごと、又はＮ回のハンドオーバごとに、再実行をトリガすることである。これは、移動性が低い場合、及びハンドオーバが稀である場合に、効率的であるとみなされる。
図１３は、パケット交換移動通信システムにおいてＭＮのホーム・エージェントとして働くように構成可能なネットワーク・サーバ１３００の基本構造を示す。これはさらに、（第１の）ＭＮのＨＡ、ＣＮのＨＡとして、又は任意のプロキシＨＡとして、前述の方法ステップを実行するように構成することも可能である。非常に一般的な実装では、サーバは、前述のタスク及び代替のうちのいくつか又はすべてをサポートするように構成される。
ネットワーク・サーバ１３００は、処理ユニット１３０１、ランダム・アクセス・メモリ１３０２、及び、パケット交換ネットワークに接続するための少なくとも１つのネットワーク・インターフェース１３０３を備える。さらに、不揮発性半導体メモリ１３０４及び／又は、磁気又は光ハード・ディスク・ドライブ１３０５を備えることもできる。オプションで、初期プログラムのローディング又はプログラム更新のために、任意の種類の磁気、光、又は半導体の記憶媒体用の読取装置を含めることができる。ネットワーク・サーバ１３００は、ディスプレイ・スクリーン又はキーボードなどの、ここでは示されていないオプションの構成要素をさらに備えることができる。
ＭＮのＨｏＡとＣｏＡの間のバインディングを格納するためのバインディング・キャッシュ１３０７、１３０８、及び１３０９は、ＲＡＭ１３０２、ＮＶＭ１３０４、及びハード・ディスク１３０５のうちの１つ又はいくつかにおける、予約メモリ・スペースとすることができる。
ネットワーク・サーバ１３００は、そのＣＰＵ１３０１上で、ＲＡＭ１３０２、ＮＶＭ１３０４、及び／又はハード・ディスク１３０５に格納されたプログラム命令を実行することによって、前述の方法ステップを実行するように構成することができる。これらの命令は、媒体読取装置１３０６によって読み取り可能な任意の他のコンピュータ読み取り可能記憶媒体１３１０上のこれらのメモリ位置にダウンロードするために格納することができる。こうした媒体は、ＣＤ（コンパクト・ディスク）、ＤＶＤ（デジタル多用途ディスク）、フロッピー（登録商標）・ディスク、又は半導体メモリ・カードとすることができる。
本発明は、データ・パケットが、ＭＮのロケータを永続識別子にマッピングするための責務を負う何らかの種類のモビリティ・エージェントを介してルーティングされる、他の移動性管理プロトコル及びシステムに適用することもできる。
マルチホーム端末
以下では、ＯＲＴのＨＡ制御及びＭＮ制御の変形例に関するマルチホーム・サポートについて詳細に説明する。ＭＮが複数のＨｏＡ及びＣｏＡを有し、ＣＮが複数のＣｏＡ及び１つのＨｏＡを有する場合に、可能なデータ・パスのサブセットを使用するシナリオの例が図１４に示される。
ＯＲＴ／ＲＯＴＡに関する複雑さは、ロード・バランシング及び冗長性の理由でリンク上に複数のＨＡが存在する可能性があること、並びに、（すべてのトンネル・セグメントが接続されるように）それらのうちの１つだけがパス上にあるものとして選択できることである。そうでなければ、（ＨｏＡのプレフィックスはリンクのプレフィックスのうちの１つと一致しないことから）プロキシＨＡはプロキシされたＨｏＡに対してプロキシの隣接発見を実行しないため、データ・パケットはその宛先への最適化ルートを使用しないことになる。例えば、ＭＮがｐＨＡ１をプロキシＨＡとして選択し、ＣＮが、同じリンク上に配置されたｐＨＡ１以外の他のＨＡであるｐＨＡ２をプロキシＨＡとして選択する場合、ＣＮはデータ・パケットをｐＨＡ２へとリバース・トンネリングするが、ｐＨＡ１だけはパケットをＭＮへとトンネリングすることができる。したがって、パケットは非最適化パスを介してＭＮのＨＡにルーティングされることになる。ｐＨＡ１は、ＭＮのＨｏＡに対してプロキシの隣接発見を実行できない（アドレスがオンリンク・プレフィックスを持たない）ため、パケットはｐＨＡ１によってインターセプトされないことに留意されたい。
主な考え方は、ＭＮ及びＣＮがそれぞれ、それらのＨｏＡのうちの１つを選択し、使用されるインターフェースごとに少なくとも１つのＣｏＡを対応するＨＡに登録することである（これは、１つのＨＡのバインディング・キャッシュにおいて、複数のＣｏＡを１つのＨｏＡに割り当て可能であることを示唆する）。さらに、ＭＮ及びＣＮは、候補となるプロキシＨＡとみなされる既知の（例えば、他のインターフェースに割り当てられた）ＨＡについて、ＨＡに通知する。次にＭＮ及びＣＮのＨＡは、最良のパスを提供するＣｏＡとプロキシＨＡとの組み合わせを別個に選択し、その後、共通ソリューションに達するようにネゴシエートすることができる。選択アルゴリズムは、受信したパケットから受動的に、又はプロービングによって能動的に決定することが可能な、距離情報に基づくものとすることができる。
第１のステップでは、ＭＮは、ＣＮとの通信に使用されるそのＨｏＡのうちの１つを選択し、ＣＮがマルチホームでありＭＮがＣＮの複数のＨｏＡを認識した場合、宛先アドレスとしてＣＮのＨｏＡのうちの１つを選択する。ＨｏＡに対応する（主）ＨＡは、以下で、ＭＮのＨＡ及びＣＮのＨＡと呼ばれる。
ＨＡへのリバース・トンネルを使用して特定のインターフェース上でデータを送信及び受信できるようにするために、ＭＮは、このインターフェースに割り当てられたアドレスのうちの少なくとも１つをＭＮのＨＡにＣｏＡとして登録する。
次にＭＮは、ＭＮのＨｏＡ及びＣＮのＨｏＡを含むＭＮのＨＡにＯＲＴ初期化要求を送信することによって、ＯＲＴ（最適化リバース・トンネリング）を開始する。加えて、移動ノードは、登録されているＨＡのすべて又はサブセットを候補となるプロキシＨＡとしてＭＮのＨＡに対して提案することができる。この情報は、例えば、それらのアドレスを、バインディング・アップデートメッセージ又はＯＲＴ初期化要求メッセージによって実行可能な新しい「候補となるプロキシＨＡモビリティ・オプション」に含めることにより送達される。
ＭＮのＨＡはＯＲＴ初期化要求を受信すると、候補となるプロキシＨＡアドレスを格納することができる。候補となるプロキシＨＡのうちの一部が信頼できない場合、対応するアドレスが選別され、そのようにマーク付けされるはずである。次に、ＭＮのＨＡは、例えば、拡張ＤＨＡＡＤプロシージャを使用して、ＣＮのＨｏＡに関するバインディングを管理するＨＡを発見する。ＣＮのホーム・ネットワークが分散型である場合、この発見の結果、複数のＨＡが生じる可能性がある。この場合、ＭＮのＨＡはそれらのうちの１つを選択し、このＨＡ（以下、ＣＮのＨＡと呼ぶ）にＯＲＴ要求を送信する。さらに、（例えば、ＯＲＴ要求によって実行される候補となるプロキシＨＡオプションを使用して）候補となるプロキシＨＡをＣＮのＨＡに提案し、これによって信頼できない候補を選別することができる。
ＣＮのＨＡは、ＯＲＴ初期化要求をＣＮに送信する。この要求を受信すると、ＣＮは、ＣＮのＨＡにＣｏＡとして使用されるインターフェースごとに少なくとも１つのアドレスを登録する。次に、ＣＮが登録されているＨＡのすべて又はサブセットを（例えば、ＯＲＴ初期化応答によって実行される候補となるプロキシＨＡオプションを使用して）候補となるプロキシＨＡとしてＣＮのＨＡに対して提案することができる。信頼できない候補となるプロキシＨＡを選別した後、次にＣＮのＨＡは、それらのすべて又はサブセットを（例えば、ＯＲＴ応答によって実行される候補となるプロキシＨＡオプションを使用して）追加の候補となるプロキシＨＡとしてＭＮのＨＡに提案することが可能であり、これによって信頼できない候補を再度選別することができる。
次に、プロキシＨＡ及びＣｏＡ選択プロシージャがＭＮ及びＣＮのＨＡ上で別個に実行される。この選択は、他の情報の中でも特に距離情報に基づくものとすることができる。何らかの距離情報を、以前のセッションから事前構成又はキャッシュすることが可能であり、一部は、例えば、受信したＯＲＴ又はモバイルＩＰｖ６のシグナリング・メッセージに基づいて受動的に測定することができる。例えば、ＭＮからＣＮのＨＡまで、又はＭＮ／ＣＮからＭＮ／ＣＮのＨＡまでの距離は、受信したパケットのホップ制限フィールドをピークする（ｐｅｅｋｉｎｇ）ことで、すでに知られている可能性がある。一部のシナリオではこの情報で十分な可能性があり、例えば、ＭＮ又はＣＮのＨＡが、プロキシＨＡとして働いている際にすでに十分短いパスを提供している場合、それ以上の距離情報は不要である。
他のケースでは、ＭＮのＨＡ、ＣＮのＨＡ、及び候補となるプロキシＨＡの間で、ＢＵ情報を交換することが可能であり、距離情報は能動的に測定すること、又は他のノードに要求することが可能である。候補となるプロキシＨＡ間、及び候補となるプロキシＨＡとＭＮ又はＣＮのＣｏＡとの間のリンク・コストは、能動的プロービングを使用して測定することができる。最適なルートが見つかった場合、すべてのパス・セグメントの長さ、すなわち、すべてのプロキシＨＡ間及びすべてのＭＮ／ＣＮのＣｏＡまでの長さを知らなければならない。パス長さ要件がわかった場合、すべての可能なパスについて考慮する前に、要件を満たす（準最適）パスが見つかれば、プロキシＨＡ及びＣｏＡの選択を打ち切ることができる。また、選択においてパス上の１つのプロキシＨＡを使用するシナリオが考慮の対象とされる場合、プロキシＨＡ間の距離を測定する必要はない。
いずれの場合も、選択プロシージャがどちらのＨＡでも同じ結果で終わる必要がある。１つのオプションは、両方のＨＡがその選択に対して同じ入力（アドレス及び距離情報）を有し、この要件を満たすために同じ選択アルゴリズムを使用するように確保することである。しかし、両方のＨＡが、選択プロシージャにおいてポリシー情報などのローカル情報をさらに考慮の対象としなければならない場合（すなわち、両方のＨＡで出力が異なる場合）、又は、両方のＨＡで選択アルゴリズムが異なる可能性がある場合、合意結果に達するために、ＭＮとＣＮのＨＡとの間で追加のネゴシエーションが必要である。これは、ＨＡ間での追加のＯＲＴ要求／応答交換によって実現可能である。それらの交換は、それらとセッション開始交換とを区別するために、特別なフラグ（例えば、「ネゴシエーション」フラグ）でマーク付けしなければならない。各交換において、パス（すなわち、プロキシＨＡアドレスとＣｏＡの組み合わせ）が要求メッセージで他のＨＡに提案され、応答メッセージでこのパスを受け入れるか又は拒否する。要求メッセージにパスのランク付けリストを含め、受信側が応答メッセージでパスのうちの１つを選択できるようにすることも可能である。
すべての可能なパスが提案された後に、合意される結果が見つけられなかった場合、又は許可された交換の事前に定義されたしきい値を超えた場合、ＯＲＴは打ち切られ、標準の双方向トンネリングが使用される。他方で、選択プロシージャが首尾よく終了し、共通の結果が見つかった場合、トンネル・エンド・ポイントは最終的に前述のように切り替えられ、データ通信に最適化ルートを使用することができる。
図１５は、ＨＡ制御の変形例におけるマルチホームのＭＮ及びＣＮに関する初期シグナリング流れを示す図である。
図１９ａ、図１９ｂ、及び図１９ｃでは、ＨＡ制御の変形例が流れ図の形で示される。ステップ１９０２では、ＭＮが、ＣＮとの通信に使用するためにそのＨｏＡのうちの１つを選択する。１９０４でＣＮがマルチホームである場合、１９０６でＭＮはＣＮに関する複数のＨｏＡを認識し、その後ＭＮはステップ１９０８で、ＣＮのＨｏＡのうちの１つを選択する。
移動ノードは、ステップ１９１０で、対象とするインターフェースに割り当てられたアドレスのうちの少なくとも１つをＣｏＡとしてＭＮのＨＡに登録する。ＭＮがステップ１９１８で、候補となるプロキシＨＡとしてそのＨＡに登録されたＨＡのすべて又はサブセットを提案できるより前に、ＭＮはステップ１９１２で、ＯＲＴ初期化要求をＭＮのＨＡに送信する。
ステップ１９２０で、ＭＮのＨＡは、ＯＲＴ初期化要求を受信し、候補となるプロキシＨＡを格納する。１９２２で、ＣＮのホーム・ネットワークが分散型である場合、ＭＮのＨＡは、１９２４でＣＮのＨｏＡに関するバインディングを管理する複数のＨＡを発見し、ＭＮはステップ１９２６で、複数のＨＡのうちの１つを選択する。ＣＮのホーム・ネットワークが分散型でない場合、ＭＮのＨＡはステップ１９２８で、ＣＮのＨｏＡに関するバインディングを管理するＨＡを発見する。
ステップ１９３０で、ＭＮのＨＡはＯＲＴ要求をＣＮのＨＡに送信し、候補となるプロキシＨＡとしてＣＮのＨＡに対してＨＡを提案することができる。ＣＮのＨＡがＭＮのＨＡからＯＲＴ要求を受信した場合、ＣＮのＨＡは信頼できないプロキシＨＡを選別しなければならない。ＣＮのＨＡはステップ１９３２で、ＯＲＴ初期化要求をＣＮに送信した後、ＣＮはステップ１９３４で、ＣＮのＨＡにＣｏＡとして使用されるインターフェースごとに少なくとも１つのアドレスを登録する。
ステップ１９３６で、ＣＮはＯＲＴ初期化応答を送信し、ＣＮのＨＡに対して候補となるプロキシＨＡを提案することができる。ステップ１９３８で、ＣＮのＨＡはＯＲＴ応答を送信し、信頼できないＨＡを選別する追加の候補となるプロキシＨＡをＭＮのＨＡに対して提案することができる。ステップ１９４４でＯＲＴ初期化応答は、ＭＮのＨＡによってＭＮに送信される。
１９４８で、ＭＮのＨＡに関するＢＵ情報、ＣＮのＨＡ、及び候補となるプロキシＨＡが以前のセッションからわからない場合、ステップ１９５０で、ＭＮのＨＡ、ＣＮのＨＡ、及び候補となるプロキシＨＡの間でＢＵ情報が交換される。ステップ１９５２で、ＭＮのＨＡ及びＣＮのＨＡから候補となるプロキシＨＡ及びＣｏＡまでのパス・セグメントの長さを確立することを含み、パス・セグメントの長さが確立される。ステップ１９５３で、プロキシＨＡ及びＣｏＡの選択が、ＭＮのＨＡ及びＣＮのＨＡ上で別個に実行される。
ステップ１９５４で、ＭＮのＨＡ及びＣＮのＨＡ上で同じ入力及び同じ選択アルゴリズムが使用された場合、ステップ１９５８でトンネル・エンド・ポイント切り替えが開始され、そうでない場合、ステップ１９５６で追加のネゴシエーションが実行される。
それに応じてＭＮ制御の変形例におけるプロシージャが実行されるが、ＭＮとＣＮのＨＡ又はＣＮとＭＮのＨＡの間でそれぞれＯＲＴ要求／応答が交換されるという相違点がある。ＨＡ制御の変形例の場合と同様、候補となるプロキシＨＡに、ＯＲＴ要求／応答メッセージによって実行されるモビリティ・オプションを提案することができる。加えて、ＭＮ及びＣＮは、例えば、ＢＵメッセージによって実行されるモビリティ・オプションを使用して、候補となるプロキシＨＡをそれら独自のＨＡに送信する。
図１６は、ＭＮ制御の変形例におけるマルチホームのＭＮ及びＣＮに関する初期シグナリング流れを示し、図１７は、距離情報報告を候補となるプロキシＨＡに要求するためのシグナリング流れを示す。
移動性の場合、最良のパスを提供するＣｏＡとプロキシＨＡとの特定の組み合わせは変更される可能性がある。したがって、選択プロシージャは反復すべきである。これには、プロキシＨＡにおけるバインディング情報の更新と、新しい距離測定を含むことができる。
このプロシージャの反復頻度は、前述のように選択することができる。マルチホーミングの結果として生じるオーバヘッドが増加することにより、反復頻度に応じた措置を講じなければならない。インターフェースのサブセットのみが使用される場合、又は十分良好なパスが見つかるとプロキシＨＡ選択が打ち切られる場合、シグナリングのさらなる削減を達成することができる。
本発明は、モバイルＩＰｖ６及びＯＲＴと同様の特性を備えた、他の移動性管理プロトコル及び位置プライバシー・プロトコルに（ある程度の変更と共に）適用可能である。
図１８は、ＭＮが２つのインターフェース（ＩＦ）、２つのＨｏＡ、及び３つのＣｏＡを有する、シナリオの例を示す。ＣＮは３つのインターフェース、２つのＨｏＡ、及び３つのＣｏＡを有する。ホーム・リンクは分散型ではない。このシナリオで、ＨＡ制御の変形例を使用して最適なパスを見つけるためのプロシージャの例を、以下で説明する。
・ＭＮはＣＮとの通信用に、ソースとしてＨｏＡ２MNを、宛先アドレスとしてＨｏＡ２CNを選択する。
・ＭＮはＨＡ２に＜ＨｏＡ２MN，ＣｏＡ１MN，ＣｏＡ２MN＞を登録し、ＯＲＴ初期化要求メッセージを使用して通信セッション＜ＨｏＡ２MN，ＨｏＡ２CN＞に対してＨＡ２にＯＲＴを要求し、候補となるプロキシＨＡオプションを使用して候補となるプロキシＨＡアドレスとしてＨＡ１アドレスに関してＨＡ２に通知する。
・ＨＡ２は、例えば、前述のメカニズムを使用して、ＨｏＡ２CNに関するバインディングを管理するＨＡを発見する。この結果、ＨＡ４アドレスが生じる。
・ＨＡ２はＯＲＴ要求メッセージを使用してＨＡ４にＯＲＴを要求し、候補となるプロキシＨＡオプションを使用して、候補となるプロキシＨＡとしてＨＡ１に関してＨＡ４に通知する。
・ＨＡ４は、ＯＲＴ初期化要求メッセージを使用してＣＮにＯＲＴを要求する。
・ＣＮは、ＨＡ４に＜ＨｏＡ２CN，ＣｏＡ１CN，ＣｏＡ２CN，ＣｏＡ３CN＞を登録し、ＯＲＴ初期化応答メッセージを使用してＨＡ４に応答し、候補となるプロキシＨＡオプションを使用して、候補となるプロキシＨＡとしてＨＡ３に関してＨＡ４に通知する。
・ＨＡ４はＨＡ２にＯＲＴ応答を送信し、候補となるプロキシＨＡオプションを使用して、候補となるプロキシＨＡとしてＨＡ３に関してＨＡ２に通知する。
・ＨＡ２は、ＨＡ４にバインディング情報＜ＨｏＡ２MN，ＣｏＡ１MN，ＣｏＡ２MN＞を送信する。
・ＨＡ４は、ＨＡ２にバインディング情報＜ＨｏＡ２CN，ＣｏＡ１CN，ＣｏＡ２CN，ＣｏＡ３CN＞を送信する。
・ＨＡ２は、ＣｏＡまで（ＣｏＡ１CN，ＣｏＡ２CN，ＣｏＡ３CN，ＣｏＡ１MN，ＣｏＡ２MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ４、ＨＡ３、ＨＡ１）の距離を測定し、ＨＡ１に距離情報を要求する。
・ＨＡ１は、ＣｏＡまで（ＣｏＡ１CN，ＣｏＡ２CN，ＣｏＡ３CN，ＣｏＡ１MN，ＣｏＡ２MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ４、ＨＡ３、ＨＡ２）の距離を測定し、ＨＡ２に距離情報報告を送信する。
・ＨＡ４は、ＣｏＡまで（ＣｏＡ１CN，ＣｏＡ２CN，ＣｏＡ３CN，ＣｏＡ１MN，ＣｏＡ２MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ３、ＨＡ１、ＨＡ２）の距離を測定し、ＨＡ３に距離情報を要求する。
・ＨＡ３は、ＣｏＡまで（ＣｏＡ１CN，ＣｏＡ２CN，ＣｏＡ３CN，ＣｏＡ１MN，ＣｏＡ２MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ４、ＨＡ１、ＨＡ２）の距離を測定し、ＨＡ４に距離情報報告を送信する。
・ＨＡ２及びＨＡ４は距離情報を交換し、最短パスを提供するプロキシＨＡ及びＣｏＡの組み合わせを決定するための選択プロシージャを開始する。
・ＨＡ４及びＨＡ２はトンネル確立要求／通知をＭＮ／ＣＮに送信する。
次に、ＯＲＴ方法についても説明する。
複数のモバイル・ネットワーク（１０５、１０６、１０７、１０８）を備える移動通信システムにおける、第１の移動ノード（１０１）と通信相手移動ノード（１０２）との間でのパケット交換データ伝送のための方法であって、
ａ）第１の移動ノード及び通信相手移動ノードのそれぞれに、それぞれのホーム・ネットワーク（１０５、１０６）を割り振るステップと、
ｂ）第１の移動ノード及び通信相手移動ノードのそれぞれに、それぞれのホーム・ネットワーク内のホーム・エージェントとしてネットワーク・サーバ（１０３、１０４）を提供するステップと、
ｃ）第１の移動ノードからホーム・エージェントのうちの任意の第１の１つへの第１のデータ・トンネル（２０１、３０１）を介して、及び、ホーム・エージェントのうちの上記第１の１つから通信相手移動ノードへの第２のデータ・トンネル（２０２、３０２）を介して、それぞれ他のホーム・エージェントを通過せずに、第１の移動ノードから通信相手移動ノードへとデータ・パケットをルーティングするステップと、
を含む方法。
第１のホーム・エージェントが第１の移動ノード（１０１）のホーム・エージェント（１０３）であり、
ｄ）通信相手移動ノードから通信相手移動ノードのホーム・エージェント（１０４）への第３のデータ・トンネル（２０３）を介して、及び、通信相手移動ノードのホーム・エージェントから第１の移動ノードへの第４のデータ・トンネル（２０４）を介して、第１の移動ノードのホーム・エージェント（１０３）を通過せずに、通信相手移動ノード（１０２）から第１の移動ノード（１０１）へとデータ・パケットをルーティングするステップをさらに含む上記の方法。
第１のホーム・エージェントが第１の移動ノード（１０１）のホーム・エージェント（１０３）であり、第１（３０１）及び第２（３０２）のデータ・トンネルが双方向トンネルであり、
ｅ） 通信相手移動ノード（１０２）から第１の移動ノード（１０１）へと、第２のデータ・トンネル及び第１のデータ・トンネルを介してデータ・パケットをルーティングするステップ
をさらに含む上記の方法。
ステップｃ）に先立って、
ｆ）第１の移動ノードのホーム・エージェント（１０３）から第１の移動ノード（１０１）まで、及び通信相手移動ノード（１０２）までの距離を決定するステップ（８１２）と、
ｇ）通信相手移動ノードのホーム・エージェント（１０４）から第１の移動ノード（１０１）まで、及び通信相手移動ノード（１０２）までの距離を決定するステップ（８１３）と、
ｈ）決定された距離を使用して、第１のトンネルのエンド・ポイントとして、及び第２のトンネルのスタート・ポイントとして、２つのホーム・エージェントのうちの１つを選択するステップ（８１７）と、
を含む上記の方法。
ステップｇ）の後、及びステップｈ）の前に、両方のホーム・エージェント間で距離情報を交換するステップ（８１４、８１５）をさらに含む上記の方法。
ステップｆ）からｈ）までが、所定の時間間隔で、又は所定回数のハンドオーバ後に反復される上記の方法。
ステップｈ）後に、トンネル確立要求又は通知メッセージ（１００１）を、第１の移動ノードのホーム・エージェントから第１の移動ノードへと送信するステップをさらに含む上記の方法。
ステップｃ）に先立って、及び適用可能であればステップｆ）に先立って、
ｊ）第１の移動ノードのホーム・エージェント（１０３）から通信相手移動ノードのホーム・エージェント（１０４）へとメッセージ（８０４）を送信するステップであって、このメッセージは、第１の移動ノード及び通信相手移動ノードのホーム・アドレスを備えるステップと、
ｋ）通信相手移動ノードのホーム・エージェント（１０４）から第１の移動ノードのホーム・エージェント（１０３）へと署名付き応答（８０７）を送信するステップであって、この応答は、通信相手移動ノードのホーム・エージェントの認証識別子及び許可証明を備えるステップと、
ｌ）第１の移動ノードのホーム・エージェントと通信相手移動ノードのホーム・エージェントとの間にセキュリティ関係（８１０）を確立するステップ（８０９）と、
ｍ）上記セキュリティ関係を使用して、第１の移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報（８１１）を、第１の移動ノードのホーム・エージェントから通信相手移動ノードのホーム・エージェントへと送信するステップと、通信相手移動ノードのホーム・エージェントにバインディング・アップデート情報を格納するステップと、
をさらに含む上記の方法。
ステップｃ）に先立って、及び適用可能であればステップｆ）に先立って、
ｎ）第１の移動ノード（１０１）から通信相手移動ノードのホーム・エージェント（１０４）へとメッセージ（９０１）を送信するステップであって、このメッセージは、第１の移動ノード及び通信相手移動ノードのホーム・アドレスを備えるステップと、
ｏ）通信相手移動ノードのホーム・エージェントから第１の移動ノードへと署名付き応答（９０２）を送信するステップであって、この応答は、通信相手移動ノードのホーム・エージェントの認証識別子及び許可証明を備えるステップと、
ｐ）第１の移動ノードと通信相手移動ノードのホーム・エージェントとの間にセキュリティ関係（９０４）を確立するステップと、
ｑ）ステップｐ）で確立した上記セキュリティ関係を使用して、第１の移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報（９０６）を、第１の移動ノードから通信相手移動ノードのホーム・エージェントへと送信するステップと、通信相手移動ノードのホーム・エージェントにバインディング・アップデート情報を格納するステップと、
をさらに含む上記の方法。
ステップｐ）の前に、第１の移動ノード（１０１）と通信相手移動ノードのホーム・エージェント（１０４）との間でリターン・ルータビリティ・プロシージャ（９０３）を実行するステップをさらに含む上記の方法。
ｕ）それぞれのプロキシ・ホーム・エージェントのネットワークとは異なるネットワークにそれぞれが割り振られた移動ノードのバインディング情報を格納するプロキシ・ホーム・エージェントを使用して、第１の移動ノードと通信相手移動ノードとの間に、及びその逆に、パケット交換データ伝送に関する、
ｉ）第１の移動ノードから、第１の移動ノードの訪問ネットワーク内のプロキシ・ホーム・エージェントへ、通信相手移動ノードの訪問ネットワーク内のプロキシ・ホーム・エージェントへ、及び通信相手移動ノードへの、第１の移動ノード及び通信相手移動ノードのいずれのホーム・エージェントも通過しない、双方向データ・トンネルであって、プロキシ・ホーム・エージェントのうちの少なくとも１つはアクセス・ルータでない、双方向データ・トンネルと、
ｉｉ）第１の移動ノードから、第１の移動ノード又は通信相手移動ノードのいずれかの訪問ネットワーク内のプロキシ・ホーム・エージェントへ、及び通信相手移動ノードへの、第１の移動ノード及び通信相手移動ノードのいずれのホーム・エージェントも通過しない、双方向データ・トンネルと、
ｉｉｉ）第１の移動ノードから、第１の移動ノードの訪問ネットワークと通信相手移動ノードの訪問ネットワークとの間に配置されたネットワーク内のプロキシ・ホーム・エージェントへ、及び通信相手移動ノードへの、第１の移動ノード及び通信相手移動ノードのいずれのホーム・エージェントも通過しない、双方向データ・トンネルとの、
ルーティング・オプションのうちの少なくとも１つを提供するステップと、
ｖ）上記及びサブステップｉ）からｉｉｉ）に記載されたルーティング・オプションのうちの少なくとも２つの間で選択するステップ（８１６）と、
をさらに含む上記の方法。
ステップｖ）及びｆ）からｈ）までが、所定の時間間隔で、又は所定回数のハンドオーバ後に、反復される、上記の方法。
複数のモバイル・ネットワーク（１０５、１０６、１０７、１０８）を備える移動通信システムにおいて、通信相手移動ノード（１０２）へとデータ・パケットを送信する第１の移動ノード（１０１）に対するホーム・エージェント（１０３）として働くことを実行するように構成されたネットワーク・サーバ（１３００）であって、さらにこのサーバは、上記第１の移動ノードから受信したデータ・パケットを上記通信相手移動ノードへと転送するために、上記通信相手移動ノードのホーム・エージェント（１０４）を通過せずに、上記通信相手移動ノードへ直接、データ・トンネル（２０２、３０２）を確立することを実行するように構成されるネットワーク・サーバ。
さらに、上記データ・トンネルを双方向データ・トンネル（２０２）として確立すること、上記データ・トンネルを介して上記通信相手移動ノード（１０２）からデータ・パケットを受信すること、及び上記受信したデータ・パケットを上記第１の移動ノード（１０１）へと転送することを確立するように構成された上記のネットワーク・サーバ（１３００）。
さらに、
上記第１の移動ノード（１０１）まで、及び上記通信相手移動ノード（１０２）までの距離を決定し、
通信相手移動ノードのホーム・エージェントから通信相手移動ノードまで、及び第１の移動ノードまでの距離に関する情報を、通信相手移動ノードのホーム・エージェント（１０４）から受信し、
決定された距離を使用して、上記データ・パケットを転送するための２つのホーム・エージェントのうちの１つを選択する、
ように構成された上記のネットワーク・サーバ（１３００）。
バインディング・キャッシュ（１３０７、１３０８、１３０９）を備え、
さらに、
通信相手移動ノードのホーム・エージェント（１０４）へメッセージを送信し、このメッセージは第１の移動ノード（１０１）及び通信相手移動ノード（１０２）のホーム・アドレスを備え、
通信相手移動ノードのホーム・エージェントから署名付き応答を受信し、この応答は通信相手移動ノードのホーム・エージェントの認証識別子及び許可証明を備え、
通信相手移動ノードのホーム・エージェントに対するセキュリティ関係を確立し、
通信相手移動ノードのホーム・エージェントから、上記セキュリティ関係を使用して、通信相手移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報を受信し、及びバインディング・アップデート情報をバインディング・キャッシュに格納する、
ように構成された上記のネットワーク・サーバ（１３００）。
さらに、トンネル確立要求又は通知メッセージを第１の移動ノード（１０１）に送信することを実行するように構成された上記のネットワーク・サーバ（１３００）。
さらに、
通信相手移動ノードのホーム・エージェント（１０４）からメッセージを受信し、このメッセージは第１の移動ノード（１０１）及び通信相手移動ノード（１０２）のホーム・アドレスを備え、
通信相手移動ノードのホーム・エージェントへ署名付き応答を送信し、この応答は通信相手移動ノードのホーム・エージェントの識別子及び許可証明を備え、
通信相手移動ノードのホーム・エージェントに対するセキュリティ関係を確立し、
通信相手移動ノードのホーム・エージェントへ、上記セキュリティ関係を使用して、通信相手移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報を送信する、
ように構成された上記のネットワーク・サーバ（１３００）。
バインディング・キャッシュ（１３０７、１３０８、１３０９）を備え、
さらに、
通信相手移動ノード（１０２）とのセキュリティ関係を確立し、
通信相手移動ノードから、上記セキュリティ関係を使用して、通信相手移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報を受信し、及びバインディング・アップデート情報をバインディング・キャッシュに格納する、
ように構成された上記のネットワーク・サーバ（１３００）。
さらに、通信相手移動ノード（１０２）を使用してリターン・ルータビリティ・プロシージャを実行するように構成された上記のネットワーク・サーバ（１３００）。
ネットワーク・サーバ（１３００）のプロセッサ（１３０１）上で実行された場合に、複数のモバイル・ネットワーク（１０５、１０６、１０７、１０８）を備える移動通信システムにおいて、通信相手移動ノード（１０２）へとデータ・パケットを送信する第１の移動ノード（１０１）に対するホーム・エージェント（１０３）として働くこと、及び、上記第１の移動ノードから受信したデータ・パケットを上記通信相手移動ノードへと転送するために、上記通信相手移動ノードのホーム・エージェント（１０４）を通過せずに、上記通信相手移動ノードへ直接、データ・トンネルを確立することを、ネットワーク・サーバに実行させる命令を格納した、コンピュータ読み取り可能記憶媒体（１３０４、１３０５、１３１０）。
略語リスト
ＡＲ アクセス・ルータ
ＢＵ バインディング・アップデート
ＣＮ 通信相手ノード
ＣｏＡ 気付アドレス
ＣＨＡ 通信相手ノードのホーム・エージェント
ＣＧＡ Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓｅｓ
ＤＨＡＡＤ Ｄｙｎａｍｉｃ Ｈｏｍｅ Ａｇｅｎｔ Ａｄｄｒｅｓｓ Ｄｉｓｃｏｖｅｒｙ
ＤＮＳ ドメイン・ネーム・システム
ＨＡ ホーム・エージェント
ＨＭＩＰ 階層化モバイル・インターネット・プロトコル・バージョン６
ＨＮ ホーム・ネットワーク
ＨｏＡ ホーム・アドレス
ＩＫＥ インターネット鍵交換
ＬＰＡ 位置プライバシー・エージェント
ＬＣＳ 位置プライバシー・サーバ
ＭＡＰ モビリティ・アンカー・ポイント
ＭＮ 移動ノード
ＯＲＣ 最適化ルート・キャッシュ・プロトコル
ＯＲＴ 最適化リバース・トンネリング
ｐＨＡ プロキシ・ホーム・エージェント
ＲＡ ルータ通知
ＲＣｏＡ 領域気付アドレス
ＲＯ ルート最適化
ＳＥＮＤ Ｓｅｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ
ＶｏＩＰ ボイス・オーバ・インターネット・プロトコル
双方向トンネリング・モードにおける、プロキシＨＡなしのＭＮとＣＮとの間のデータ・パスを示す図 ホーム・ネットワーク内に２つの単方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオａ） ＭＮのホーム・ネットワーク内に１つの双方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｂ） エンティティ間の距離が異なる、図１と同じシナリオを示す図である。 ＭＮ及びＣＮの訪問ネットワーク内に２つの単方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｃ） ＭＮの訪問ネットワーク内に１つの共通双方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｄ） ＭＮ及びＣＮの訪問ネットワーク間のネットワーク内に１つの共通双方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｅ） ＨＡ制御の変形例における、シナリオａ）〜ｅ）での初期ネゴシエーションに関するシグナリング流れを示す図 ＭＮ制御の変形例における、シナリオａ）〜ｅ）での初期ネゴシエーションに関するシグナリング流れを示す図 ＨＡ制御及びＭＮ制御の、シナリオａ）及びｂ）でのトンネル切り替えに関するシグナリング流れを示す図 ＨＡ制御の、シナリオｃ）〜ｅ）でのＢＵ交換及びトンネル切り替えに関するシグナリング流れを示す図 ＭＮ制御の、シナリオｃ）〜ｅ）でのＢＵ交換及びトンネル切り替えに関するシグナリング流れを示す図 ＨＡとして使用可能なネットワーク・サーバの構造を示す図 ＭＮが複数のＨｏＡ及びＣｏＡを有し、ＣＮが複数のＣｏＡ及び１つのＨｏＡを有する場合の、可能なデータ・パスのサブセットを備える例示的シナリオを示す図 ＨＡ制御の変形例における、マルチホームのＭＮ及びＣＮに関するシグナリング流れを示す図（本発明の新しい部分はイタリック体である） ＭＮ制御の変形例における、マルチホームのＭＮ及びＣＮに関するシグナリング流れを示す図（本発明の新しい部分はイタリック体である） 候補となるプロキシＨＡに距離情報レポートを要求するためのシグナリング流れを示す図である。 ＭＮが非分散ホーム・リンクを備えた２つのＨｏＡを有し、ＣＮが分散ホーム・リンクを備えた１つのＨｏＡ及び複数のＣｏＡを有する、シナリオ例を示す図（バインディング・キャッシュ内のイタリック体エントリは新しいエントリである） マルチホーム端末のための最適化リバース・トンネリングのプロセスを示す流れ図 マルチホーム端末のための最適化リバース・トンネリングのプロセスを示す流れ図 マルチホーム端末のための最適化リバース・トンネリングのプロセスを示す流れ図

Claims (24)

  1. 複数のモバイル・ネットワークを備える移動通信システムにおける、マルチホームの移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための方法であって、
    ａ）前記移動ノードによって、前記通信相手ノードとの通信に使用されるそのホーム・アドレスのうちの１つを選択するステップ（１９０２）と、
    ｂ）前記移動ノードによって、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、前記選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録するステップ（１９１０）と、
    ｃ）通信相手ノードのホーム・エージェント及び前記移動ノードのホーム・エージェントによって、候補となるプロキシ・ホーム・エージェント・アドレスを受信及び格納するステップと、
    ｄ）前記通信相手ノードのホーム・エージェントによって、前記通信相手ノードに要求を送信するステップ（１９３２）と、
    ｅ）前記通信相手ノードによって、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、前記通信相手ノードのホーム・エージェントに、気付アドレスとして登録するステップ（１９３４）と、
    ｆ）前記移動ノードのホーム・エージェント及び前記通信相手ノードのホーム・エージェントの両方で、前記格納されたプロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、前記移動ノードの気付アドレスのうちの１つ、及び前記通信相手ノードの気付アドレスのうちの１つを選択するステップ（１９４６）と、
    ｇ）トンネルの２つのエンド・ポイントが、ステップｆ）で選択された前記選択されたプロキシ・ホーム・エージェント・アドレス及び前記選択された移動ノードの気付アドレスのうちの１つとなるように、前記移動ノードのホーム・エージェントによって、前記トンネルを切り替えるために前記移動ノードをトリガするステップ（１９５８）と、
    ｈ）トンネルの２つのエンド・ポイントが、ステップｆ）で選択された前記選択されたプロキシ・ホーム・エージェント・アドレス及び前記選択された移動ノードの気付アドレスのうちの１つとなるように、前記通信相手ノードのホーム・エージェントによって、前記トンネルを切り替えるために通信相手ノードをトリガするステップ（１９５８）と、
    を含む方法。
  2. ステップｄ）における前記要求が、最適化リバース・トンネリング開始要求である請求項１に記載の方法。
  3. ステップｄ）の前に、
    ｉ）前記移動ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップが実行される請求項１又は２に記載の方法。
  4. ステップｄ）の前に、
    ｊ）前記通信相手ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップが実行される請求項１又は２に記載の方法。
  5. ステップｉ）が、
    前記移動ノードによって、最適化リバース・トンネリング開始要求を、そのホーム・エージェントに送信するステップ（１９１２）と、
    前記移動ノードのホーム・エージェントによって、前記最適化リバース・トンネリング開始要求を受信し、候補となるプロキシ・ホーム・エージェント・アドレスを格納するステップ（１９２０）と、
    前記移動ノードのホーム・エージェントによって、通信相手ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを見つけるステップ（１９２４，１９２６，１９２８）と、
    前記移動ノードのホーム・エージェントによって、前記見つけられた通信相手ノードのホーム・エージェントに最適化リバース・トンネリング要求を送信するステップ（１９３０）とを、
    含む請求項３に記載の方法。
  6. ステップｊ）が、
    前記通信相手ノードによって、最適化リバース・トンネリング開始応答を、そのホーム・エージェントに送信するステップ（１９１２）と、
    前記通信相手ノードのホーム・エージェントによって、前記最適化リバース・トンネリング開始応答を受信し、候補となるプロキシ・ホーム・エージェント・アドレスを格納するステップ（１９２０）と、
    前記通信相手ノードのホーム・エージェントによって、最適化リバース・トンネリング応答を前記移動ノードのホーム・エージェントに送信するステップ（１９３０）とを、
    含む請求項４に記載の方法。
  7. ステップｉ）が、
    前記移動ノードによって、候補となるプロキシ・ホーム・エージェントのアドレスをそのホーム・エージェントに送信するステップ（１９１２）と、
    前記移動ノードのホーム・エージェントによって、候補となるプロキシ・ホーム・エージェント・アドレスを受信及び格納するステップ（１９２０）と、
    前記移動ノードによって、前記通信相手ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを見つけるステップ（１９２４，１９２６，１９２８）と、
    前記移動ノードによって、前記見つけられた通信相手ノードのホーム・エージェントに最適化リバース・トンネリング要求を送信するステップ（１９３０）とを、
    含む請求項３に記載の方法。
  8. ステップｊ）が、
    前記通信相手ノードによって、候補となるプロキシ・ホーム・エージェントのアドレスをそのホーム・エージェントに送信するステップ（１９１２）と、
    前記通信相手ノードのホーム・エージェントによって、候補となるプロキシ・ホーム・エージェント・アドレスを受信（１９２０）及び格納するステップと、
    前記通信相手ノードによって、移動ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを見つけるステップ（１９２４，１９２６，１９２８）と、
    前記通信相手ノードによって、最適化リバース・トンネリング応答を前記移動ノードのホーム・エージェントに送信するステップ（１９３０）とを、
    含む請求項４に記載の方法。
  9. 最適化トンネリング要求又は応答を送信する前記ステップに続いて、候補となるプロキシ・ホーム・エージェント・アドレスを前記それぞれのホーム・エージェントに提案する請求項５から８のいずれか１つに記載の方法。
  10. ステップｆ）が、最短パスを選択するために実行される請求項１から９のいずれか１つに記載の方法。
  11. ステップｆ）が、最小遅延のパスを選択するために実行される請求項１から９のいずれか１つに記載の方法。
  12. ステップｄ）の前に、
    前記移動ノードによって、前記通信相手ノードのホーム・アドレスのうちの１つを宛先アドレスとして選択するステップ（１９０８）をさらに含む、請求項１から１１のいずれか１つに記載の方法。
  13. 前記移動ノードのホーム・エージェントによって、信頼できないプロキシ・ホーム・エージェントを拒否するステップをさらに含む、請求項１から１２のいずれか１つに記載の方法。
  14. 前記通信相手ノードのホーム・エージェントによって、信頼できないプロキシ・ホーム・エージェントを拒否するステップをさらに含む、請求項１から１３のいずれか１つに記載の方法。
  15. マルチホームの移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための移動通信システムの移動ノードであって、
    前記通信相手ノードとの通信に使用されるそのホーム・アドレスのうちの１つを選択するように適合された選択手段と、
    対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、前記選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録するように適合された格納手段と、
    を備える移動ノード。
  16. マルチホームの移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための移動通信システムの通信相手ノードのホーム・エージェントであって、
    要求を前記通信相手ノードに送信するように適合された伝送手段と、
    プロキシ候補となるホーム・エージェント・アドレスを受信するように適合された受信手段と、
    プロキシ候補となるホーム・エージェント・アドレスを格納するように適合された格納手段と、
    プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するように適合された選択手段と、
    トンネルの２つのエンド・ポイントが、前記選択されたプロキシ・ホーム・エージェント・アドレス及び前記通信相手ノードの気付アドレスのうちの１つであるように、前記トンネルを切り替えるために前記通信相手ノードをトリガするように適合されたトリガ手段とを、
    備える通信相手ノードのホーム・エージェント。
  17. マルチホームの移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための移動通信システムの通信相手ノードであって、
    対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、前記通信相手ノードのホーム・エージェントに、気付アドレスとして登録するように適合された格納手段を備える通信相手ノード。
  18. マルチホームの移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための移動通信システムの移動ノードのホーム・エージェントであって、
    プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するように適合された選択手段と、
    トンネルの２つのエンド・ポイントが、前記選択されたプロキシ・ホーム・エージェント・アドレス及び前記通信相手ノードの気付アドレスのうちの１つであるように、前記トンネルを切り替えるために、前記移動ノードをトリガするように適合されたトリガ手段とを、
    備える移動ノードのホーム・エージェント。
  19. マルチホームの移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための移動通信システムであって、前記移動通信システムが、
    請求項１５に記載の移動ノードと、請求項１７に記載の通信相手ノードと、請求項１６に記載の通信相手ノードのホーム・エージェントと、請求項１８に記載の移動ノードのホーム・エージェントとを備える移動通信システム。
  20. 請求項２から１４に記載の方法を実行するように適合される請求項１９に記載の移動通信システム。
  21. 移動ノードのプロセッサによって実行された場合、
    前記通信相手ノードとの通信に使用されるそのホーム・アドレスのうちの１つを選択するステップと、
    対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、前記選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録するステップとにより、
    マルチホーム端末のための最適化リバース・トンネリングを前記移動ノードに行わせる命令を格納するコンピュータ読み取り可能媒体。
  22. 通信相手ノードのホーム・エージェントのプロセッサによって実行された場合、
    前記通信相手ノードに要求を送信するステップと、
    プロキシ候補となるホーム・エージェント・アドレスを受信するステップと、
    プロキシ候補となるホーム・エージェント・アドレスを格納するステップと、
    前記プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するステップと、
    トンネルの２つのエンド・ポイントが、前記選択されたプロキシ・ホーム・エージェント・アドレス及び前記通信相手ノードの気付アドレスのうちの１つであるように、前記トンネルを切り替えるために前記通信相手ノードをトリガするステップとにより、
    マルチホーム端末のための最適化リバース・トンネリングを前記通信相手ノードのホーム・エージェントに行わせる命令を格納するコンピュータ読み取り可能媒体。
  23. 通信相手ノードのプロセッサによって実行された場合、
    対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、前記通信相手ノードのホーム・エージェントに、気付アドレスとして登録するステップにより、マルチホーム端末のための最適化リバース・トンネリングを前記通信相手ノードに行わせる命令を格納するコンピュータ読み取り可能媒体。
  24. 移動ノードのホーム・エージェントのプロセッサによって実行された場合、
    プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するステップと、
    トンネルの２つのエンド・ポイントが、前記選択されたプロキシ・ホーム・エージェント・アドレス及び前記通信相手ノードの気付アドレスのうちの１つであるように、前記トンネルを切り替えるために前記移動ノードをトリガするステップとにより、
    マルチホーム端末のための最適化リバース・トンネリングを前記移動ノードのホーム・エージェントに行わせる命令を格納するコンピュータ読み取り可能媒体。
JP2008557644A 2006-03-08 2007-03-02 マルチホーム端末のためのモバイルＩＰｖ６の最適化リバース・トンネリング Expired - Fee Related JP4990920B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP06004770.1 2006-03-08
EP06004770A EP1739901B1 (en) 2005-06-30 2006-03-08 Mobile IPv6 optimised reverse tunnelling for multi-homed terminals
PCT/EP2007/001828 WO2007101628A1 (en) 2006-03-08 2007-03-02 Mobile ipv6 optimised reverse tunnelling for multi-homed terminals

Publications (2)

Publication Number Publication Date
JP2009529266A JP2009529266A (ja) 2009-08-13
JP4990920B2 true JP4990920B2 (ja) 2012-08-01

Family

ID=41037638

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008557644A Expired - Fee Related JP4990920B2 (ja) 2006-03-08 2007-03-02 マルチホーム端末のためのモバイルＩＰｖ６の最適化リバース・トンネリング

Country Status (1)

Country Link
JP (1) JP4990920B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10797955B2 (en) 2016-01-08 2020-10-06 Nec Corporation System and method for operating a network

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020055971A1 (en) * 1999-11-01 2002-05-09 Interdigital Technology Corporation Method and system for a low-overhead mobility management protocol in the internet protocol layer
AU2002319563A1 (en) * 2002-07-19 2004-02-09 Nokia Corporation Route optimizing in mobile ip providing location privacy
JP2004112727A (ja) * 2002-09-20 2004-04-08 Ntt Docomo Inc 移動通信制御システム、移動通信制御方法、これらに用いて好適なルータ装置、サーバ装置及びデータ構造
US7793098B2 (en) * 2003-05-20 2010-09-07 Nokia Corporation Providing privacy to nodes using mobile IPv6 with route optimization
FI20031258A0 (fi) * 2003-09-04 2003-09-04 Nokia Corp Sijainnin yksityisyys viestintäjärjestelmässä

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10797955B2 (en) 2016-01-08 2020-10-06 Nec Corporation System and method for operating a network

Also Published As

Publication number Publication date
JP2009529266A (ja) 2009-08-13

Similar Documents

Publication Publication Date Title
US8031674B2 (en) Optimized reverse tunnelling for packet switched mobile communication systems
US11477634B2 (en) Home agent discovery upon changing the mobility management scheme
JP5205468B2 (ja) ネットワーク・ベース・モビリティからホスト・ベース・モビリティへのハンドオーバ時におけるルート最適化の継続性
Soliman et al. Hierarchical mobile IPv6 (HMIPv6) mobility management
JP5238029B2 (ja) 通信ネットワーク間でのローミングの方法および装置
US8724553B2 (en) Route optimization with location privacy support
JP5048761B2 (ja) 通信セッションのためのロケーション・プライバシーとルート最適化とを同時に実施する方法及び装置
JP5102372B2 (ja) 通信ネットワークにおいて使用する方法および装置
WO2009116246A1 (ja) 通信方法、通信システム、モバイルノード及びアクセスルータ
JP4990920B2 (ja) マルチホーム端末のためのモバイルＩＰｖ６の最適化リバース・トンネリング
Soliman et al. Rfc 5380: Hierarchical mobile ipv6 (hmipv6) mobility management
WO2007101628A1 (en) Mobile ipv6 optimised reverse tunnelling for multi-homed terminals
Bauer et al. Infrastructure-based route optimization for NEMO based on combined local and global mobility
So et al. Secure Mobile IP with HIP Style Handshaking and Readdressing for public-key based IP network
Bauer et al. MIPv6/NEMO Route Optimization based on Local and Global Mobility Interworking
Iapichino et al. Combination of ad hoc mobility with IPv6 mobility mechanisms report
Ahmed et al. Binding update schemes for inter-domain mobility management in hierarchical mobile IPv6: A survey
ElMalki et al. Network Working Group H. Soliman Request for Comments: 5380 Elevate Technologies Obsoletes: 4140 C. Castelluccia Category: Standards Track INRIA

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101124

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120410

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120502

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4990920

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150511

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees