JP2010541302A - 移動ネットワークにネストされた移動ノードが最適経路通信を行うためのシステム、方法及び装置 - Google Patents

Abstract

【解決手段】 本発明は、アクセス・ルータ・オプション・プロトコルや階層モビリティ管理プロトコルなどのエンド・ツー・エンド経路最適化プロトコルが移動ホストや移動ルータに実装される異種プロトコルシナリオにおいて発生するルーティングの準最適性問題を克服するため、３つの方法を提供する。第１の方法は、訪問移動ノード又は移動ルータがアクセス・ルータ・オプション・ベースの経路最適化を他のノードと行いたい場合、そのローカル気付アドレスをその気付アドレスとして使用する。第２の方法は、訪問移動ノードや移動ルータが他のノードと階層モビリティ管理を行うことを決定する場合、そのリージョナル気付アドレスをその気付アドレスとして使用する。第３の方法は、アーキテクチャ内にレガシー・モビリティ・アンカー・ポイントが存在する場合、移動ルータはそのルータ通知内において、モビリティ・アンカー・ポイント・オプションを送信しない。

Description

本発明は、パケット交換データ通信ネットワークにおける電気通信分野に関し、特に、エンド・ツー・エンド型経路最適化プロトコル及び階層化モビリティ管理プロトコルが実装された、単一のモビリティ・アンカー・ポイントが存在するシステムにて動作する移動ノードに最適経路を提供することに関する。

今日、多くのデバイスは、インターネット・プロトコル・バージョン６（ＩＰｖ６）を用いて相互に通信を行っている。モバイル機器のモビリティ・サポートを提供するために、インターネット技術調査会（ＩＥＴＦ）は、「ＩＰｖ６でのモビリティ・サポート（ＭＩＰｖ６）」[非特許文献１]を作成した。[非特許文献１]におけるモビリティ・サポートは、ホーム・エージェント（ＨＡ）と呼ばれるホーム・ネットワークにおけるエンティティの導入により行われる。移動ノード（ＭＮ）は、バインディング・アップデート（ＢＵ）と呼ばれるメッセージにより、ホーム・エージェントに、外部リンク内でＭＮが入手する自身の気付アドレスを登録する。これにより、ホーム・エージェントは、ホーム・リンク内で入手した長期アドレスであるホーム・アドレスと、移動ノードの気付アドレス間でバインディングを生成できる。ホーム・エージェントは、移動ノードのホーム・アドレス（ＨｏＡ）宛てのメッセージを受信し、パケットのカプセル化（すなわち、１つのパケットを新しいパケットのペイロードにすることであり、パケット・トンネリングとも呼ばれる）により、移動ノードの気付アドレスにパケットを転送する。また、ＭＩＰｖ６は、通信相手ノード（ＣＮ）との通信の際の経路最適化（ＲＯ）方法を定める。このＲＯメカニズムにより、ＭＮとＣＮがホーム・エージェントを経由せずにＭＮの気付アドレスにより相互に通信を行うことができるよう、ＭＮはＣＮにおいてその気付アドレスの有効な登録を行うことができる。ＣＮでは、ＭＮによって開始されるリターン・ルータビリティ（ＲＲ）テストにより、ＭＮの気付アドレスの有効な登録が行われる。このリターン・ルータビリティ・テストにより、ＣＮは、ＭＮの気付アドレスとＭＮのホーム・アドレスとが結び付けられているという証明を得ることができる。上記ＲＯメカニズムは任意のものであり、ＣＮがＲＯメカニズムをサポートする何らかの機能性を有する場合にのみその利点が発揮されることとなる。

ＭＩＰｖ６の問題点の一つとして、ＭＮは、ネットワーク接続におけるたった一つの変更に対し、一つ又は複数のホーム・エージェント及び一つ又は複数の通信相手ノードを更新しなければならないということが挙げられる。これにより、高速で移動しているＭＮのためにネットワークへ投入されるシグナリング負荷が増大する。また、ネットワーク接続における一つ一つの変更がＲＲ及びＢＵメッセージの送信を伴うため、ネットワーク接続における変更ごとのＣＮとの平均ハンドオフ確立時間は長くなる。そのため、フロー又は接続に関連するセッション中は、かなりの時間がハンドオフの確立に割り当てられ、それによりジッターやパケット・ロスが生じることとなる。上記ジッターは、ボイス・オーバーＩＰ（ＶｏＩＰ）、マルチメディア、ビデオ・ストリーミングなどのアプリケーションに弊害をもたらすものであり、また、上記パケット・ロスは、重要なテキスト情報を運ぶフローに弊害をもたらすものである。さらに、パケット・ロスは、伝送制御プロトコル（ＴＣＰ）を情報重要データ・アプリケーションに利用する場合、ＴＣＰスループットを低下させる。

そのようなＭＩＰｖ６の問題に対処するため、ＩＥＴＦは、[非特許文献２]に開示されている階層化モビリティ管理プロトコル・バージョン６（ＨＭＩＰｖ６）と呼ばれるプロトコルの標準化を行った。ＨＭＩＰｖ６は、二種類の気付アドレスと、モビリティ・アンカー・ポイント（ＭＡＰ）と呼ばれる新しいノードとを用いる。その基本原理としては、ＭＮは、それが接続されている新しいネットワークにおいて、二つの気付アドレスを取得する。その二つの気付アドレスの内の一方は、ローカル気付アドレス（ＬＣｏＡ）と呼ばれ、ＭＮが直接接続されているネットワークから入手したアドレスである。また、その他方のアドレスは、リージョナル気付アドレス（ＲＣｏＡ）と呼ばれ、ＭＡＰのネットワーク・プレフィックスから得られる。ＲＣｏＡは、ＭＮがＣＮ及びＨＡと通信する際に気付アドレスとして用いるアドレスである。ＭＡＰは好ましくはルーティング階層の上位に置かれる固定ルータであるので、このＲＣｏＡは頻繁に変更されることはない。ＭＡＰ情報が入手可能なネットワーク・セグメント内でＭＮがローミングする限り、リージョナル気付アドレスが変更されることはない。このプロトコルでは、ネットワーク接続におけるすべての変更についてのハンドオフ確立処理には、主に、ＬＣｏＡが登録されているＭＡＰが用いられる。ＭＮがＭＡＰ外へ移動し、それによりＲＣｏＡが変更される時にのみ、ＭＡＰ、ＣＮ、ＨＡに対して更新又はハンドオフ確立が同時に行われる。従って、ネットワーク接続における変更ごとのネットワークへのシグナリング負荷は、平均して、ＭＩＰｖ６に比べてかなり低い。さらに、ネットワーク接続におけるすべての変更についてのハンドオフ確立時間は、平均して短い。これは、大抵の場合、ハンドオフが、ローミングＭＮにごく接近したところに位置するＭＡＰでの単純なＬＣｏＡ登録だけで済まされるためである。このため、前述のジッターやパケット・ロスなどの問題はここではずっと少ない。このプロトコルは、フローに省電力化を必要とするノード、及び、厳しいＱｏＳパラメータを求めるフローを運ぶノードに使用される、広く認められた標準プロトコルである。

無線デバイスがますます普及する中、複数のノードからなるネットワーク全体がその接続点を変えるネットワークモビリティ、すなわちＮＥＭＯのような 新しいタイプのモビリティ技術が出現することが予見される。ＩＥＴＦは、[非特許文献３]に開示されている基本的なネットワーク・モビリティ・サポートに対する解決法を開発した。この場合、移動ルータ（ＭＲ）は、ＢＵをホーム・エージェントに送信する際、移動ネットワーク内のノードが使用しているネットワーク・プレフィックスを指定するよう規定されている。これらは、ＢＵ内に挿入するネットワーク・プレフィックス・オプションと呼ばれる特別なオプションにより指定される。これらにより、ホーム・エージェントは、ホーム・エージェントが、これらのプレフィックスと共に宛て先に送信された任意のパケットを移動ルータの気付アドレスへトンネルするように、プレフィックス・ベースのルーティング・テーブルを作成できる。

ＭＮがＮＥＭＯに深くネストされると、二種類の問題が発生する。一つ目の問題としては、多重カプセル化のオーバーヘッドや、データ・パケットの準最適ルーティングが挙げられる。これは、ネスト状態のＮＥＭＯにおける、ネスト状態のトンネリングによるものである。多重カプセル化は、パケット・サイズの増大に起因するデータ・パケットの遅延を引き起こし、さらに、パケット・フラグメンテーションを招くこともある。さらに、パケット・フラグメンテーションは、データ・パケット・ロスを引き起こすこともある。準最適ルーティングは、データ・パケットの遅延、ネットワーク負荷の増大、ＨＡの処理負荷増大につながる。

二つ目の問題としては、深くネストされたＭＮに対するレイヤ３ハンドオフ確立の大幅な遅延や、ＲＲ及びＢＵストリームのシグナリング・オーバーヘッドに起因してネットワークへ投入される高いシグナリング負荷が挙げられる。これは、ＭＮが深くネストされ、ネットワーク接続に変更があったため、新しい気付アドレスがＣＮ又はＨＡにて更新する必要がある場合、このような登録には、ハンドオフ登録に関与するパケットが多重にカプセル化され、大幅な遅延が発生するからである。前述のように、ハンドオフ遅延時間の増加は、高速で移動するＭＮによって運ばれるフローの全セッション又は接続時間に大きく関係し、それによりジッターやパケット・ロスが生じることとなる。さらにまた、一定期間内でのＭＮによる過度のハンドオフ確立シグナリングは、ネットワーク内で運ばれるその他のフローにも影響を及ぼすことになる。

一つ目の問題を解決するため、関連技術分野における、いわゆるネスト状態のトンネルの最適化に関して様々な提案がなされている。具体的には、[非特許文献４]には、アクセス・ルータ・オプション（ＡＲＯ）と呼ばれる解決法が開示されている。送信者（すなわち、移動ルータ又は移動ホスト）は、このアクセス・ルータ・オプションと呼ばれる新しいオプションを使って、受信者（例えば、ホーム・エージェント又は通信相手ノード）に、該送信者が接続されているアクセス・ルータの一次グローバルアドレスを知らせる。移動ノードは、アクセス・ルータ・オプションと共にバインディング・アップデート・メッセージを送信後、送信するデータ・パケットに「直接転送要求」シグナルと呼ばれる特別なシグナルを挿入できる。このシグナルにより、上流の移動ルータは自身のバインディング・アップデートを宛先アドレスに送信する。この処理は、最上流の移動アクセス・ルータに達するまで繰り返される。上流のすべての移動アクセス・ルータがバインディング・アップデートを宛先に送信することで、宛先では、移動ノードが接続されている移動ルータの連鎖を形成できる。これは、拡張タイプ２ルーティングヘッダ（ＲＨ２）の作成に利用できるため、宛先ノードがパケットを移動ノードに送り返したい場合、ルーティング・ヘッダを有するパケットを埋め込むことができ、パケットが移動アクセス・ルータの連鎖を介して移動ノードへ直接転送される。この方法は、エンド・ツー・エンド型経路最適化を、セキュリティーを犠牲にせずに実現するのに適した方法であると考えられる。

二つ目の問題を解決し、一つ目の問題を部分的に解決するため、[非特許文献５]には、ネスト状態のトンネリングやレイヤ３（Ｌ３）ハンドオフ確立の遅延などの問題へ対処する設計が開示されている。この方法では、ハンドオフ効率及びシグナリング・オーバーヘッドの改善、ＭＡＰ環境においてネストされたＭＮのエンド・ツー・エンド型経路最適化の適切な実行を図る。この方法において、すべてのＭＮ（本稿では移動ホストとする）は、ＨＭＩＰｖ６で規定された通りに動作する。ＭＮは、ローカル・ネットワーク接続におけるそれぞれの変更については、そのＬＣｏＡをＭＡＰにて更新し、ＲＣｏＡ又はＭＡＰドメインにおけるそれぞれの変更については、そのＣＮとＨＡに対してＲＣｏＡを更新する。この方法では、ＭＲは、ＭＮに対し、ＨＭＩＰｖ６プロトコルで規定された通りに動作するが、若干の変更も伴うものとする。ＭＲは、ルータ・モードで動作する場合、そのルータ通知（ＲＡ）におけるＭＡＰオプションを通知し、それに接続されているＭＮへとＭＡＰサービスを拡大する。さらに、ＭＡＰがＭＮのＬＣｏＡに到達する最適経路をトレースするのを助けるため、ＭＲは、純粋なＨＭＩＰｖ６タイプの登録の代わりに、ＭＡＰにてプレフィックス・スコープ・バインディング・アップデート（ＰＳＢＵ）を行う。ＭＮがいくつかのＭＲの配下に深くネストされているとすると、ＭＡＰのバインディング・キャッシュは、ＭＮのＬＣｏＡとＲＣｏＡのほかに上流のＭＲのＬＣｏＡ、ＲＣｏＡ、ＭＲのプレフィックスも有することとなる。ＭＡＰが、ＭＮの上流のＭＲに関連するすべてのＬＣｏＡの位置を特定するのに、このプレフィックスをいかに利用可能であるかは当業者には公知である。このようなトレースが可能であるのは、ＭＮ又はＭＲのＬＣｏＡがそのアクセス・ルータのプレフィックスから得られているからである。

ＭＮに関連するＲＣｏＡのＭＡＰにデータ・パケットが到着すると、ＭＡＰは、まず、このＲＣｏＡの位置を特定し、その後、バインディング・キャッシュ・エントリ（ＢＣＥ）からそのＲＣｏＡに関連する対応ＬＣｏＡを見つけ出す。続いて、ＭＡＰは、このＭＮのＬＣｏＡに一致するプレフィックスを検索する。これにより、ＭＡＰは、ＭＮの直結する移動アクセス・ルータの位置パラメータを見つけ、上流のすべてのＭＲのＬＣｏＡが得られるまで上記処理を繰り返すことができる。そのようにＭＡＰにてトレースが繰り返し行われると、上流のすべてのＭＲのＬＣｏＡから成るトンネルにルーティング・ヘッダを挿入することで、データ・パケットがＭＮにトンネルされる。ＨＭＩＰｖ６と同様、パケットをＣＮへ送信する場合、ＭＮは、まず、ＭＡＰへと続くトンネルにパケットをカプセル化する。ＭＮの上流のすべてのＭＲは、ＭＡＰにバインディングを有するので、ＭＡＰへと続く別々のトンネルにさらにパケットをカプセル化する。この方法によって最終的に得られる効果としては、受信データ・パケットには、拡張ルーティング・ヘッダを有するＭＡＰからのトンネルが単一となるということである。送信データ・パケットには、無線ドメインにおいてＭＮ／ＭＲからＭＡＰへ多重カプセル化が行われる。このプロトコルは、主に、ＮＥＭＯに深くネストされたＭＮに対するハンドオフやシグナリングの向上を図るものであることを理解することが重要である。この方法を[非特許文献４]に開示されているようなＡＲＯ方式と比較する場合、ＡＲＯ方式は、より優れたエンド・ツー・エンドＲＯを実現することを理解することが重要である。これは、ＡＲＯでは、無線ドメインには逆方向にトンネルが存在しないのに対し、[非特許文献５]の無線ドメインには複数のトンネルが存在するためである。また、ＡＲＯでは、順方向にトンネルが存在しない。

上記から予見し得るのは、データ・フロー、端子、ネットワークの目的を達成するためには、今後、複数の異なるタイプのプロトコルをシステムに実装する必要がある可能性があるということである。データ・フローについて言えば、その主な目的は、遅延、ジッター、パケット・ロスを軽減することである。ネットワークにより認識されるＱｏＳに関する主な目的は、ネットワーク負荷、もっと正確には、ネットワークへのシグナリング負荷を軽減することである。ＭＮに関する目的は、省電力化である。従って、これらのすべての目的を一つの目標として組み合わせるためには、複数のプロトコルをシステムに実装する必要がある可能性が非常に高い。ＭＮは、今後、異なるＱｏＳニーズを持つ異なるタイプのフローをサポートすることが必要になるかもしれない。例えば、ＭＮは、厳しいエンド・ツー・エンドＲＯを必要とするいくつかのフローと、それほど厳しいエンド・ツー・エンドＲＯを必要としないいくつかのフローとを運ぶ必要が生じる可能性ある。それほど厳しいエンド・ツー・エンドＲＯを必要としないフローについては、ＭＮは、ネットワークに投入されるシグナリング負荷の向上を考慮し、頻繁に行われるバインディング・アップデートを軽減し省電力化を図ることが必要になるかもしれない。このように、ＭＮ、ＭＲ、いくつかの主要なルータ、ＣＮには、今後、異なるタイプの複数のプロトコルを実装する必要があるということが予見し得る。

今後出現し得るシナリオとしては、ＡＲＯ及びＨＭＩＰｖ６プロトコルの両方が一つのＭＮ／ＭＲに実装され、これらのノードが異なる種類のＭＡＰが存在するグローバル通信ネットワークにおいてローミングするというシナリオがある。上記ＭＡＰは、[非特許文献２]に開示されているようなレガシーＨＭＩＰｖ６タイプのＭＡＰであってもよいし、[特許文献３]に説明されているようないくつかのＲＯ機能を有するＭＡＰであってもよい。次に、このようなシナリオにおいて、ＭＮ及びＭＲがそれらに実装されているＡＲＯ及びＨＭＩＰｖ６プロトコルに関連する標準メカニズムに従って動作する場合のシステム内でのシグナリング及びデータ・パケット・ルーティングについて分析する。図１では、このシナリオについてさらに詳しく説明する。

ネットワーク・アーキテクチャ内に一つのモビリティ・アンカー・ポイントＭＡＰ４０が存在するシステムを図１に示す。このＭＡＰは、レガシーＨＭＩＰｖ６タイプのＭＡＰ、ＡＲＯ対応ＭＡＰなどのＲＯ機能を有するＭＡＰ、プレフィックスを委譲しプレフィックス・スコープ・バインディング・アップデートを処理するＭＡＰ、若しくは、プレフィックスは委譲しないが、適切な検証によりＰＳＢＵを処理するＭＡＰであってもよい。このシナリオでは、ＭＡＰに関連するＲＯ処理機能の詳細に注目せずに、レガシーＭＡＰやＲＯ機能を有するＭＡＰにおける、ルーティングの準最適性問題やその他の問題について分析する。

訪問移動ノード（ＶＭＮ）１０は、ＮＥＭＯ１０１内に位置し、無線リンクを介してＭＲ２０に接続されている。ＭＲ２０は、ＮＥＭＯ１０２内に位置し、無線リンクを介してＭＲ２１に接続されている。ＭＲ２１は、無線アクセスネットワーク１０３内に位置し、無線リンクを介してＡＲ３０に接続されている。ＡＲ３０は、固定アクセスネットワーク１０４内に位置し、有線リンクを介してＭＡＰ４０に接続されている。ＭＡＰ４０は、有線リンクにより固定アクセスネットワークを介してグローバル通信ネットワーク１００（インターネット）に接続されている。ＭＲ２０とＭＲ２１のホーム・エージェントは、それぞれ、ＨＡ５１、ＨＡ５０である。ＶＭＮ１０のホーム・エージェントは、明確には図示されていない。ＶＭＮ１０は、グローバル通信ネットワーク１００に接続されているＣＮ６０と、データ通信セッションを行っている。

このシナリオでの問題点を明らかにするために、まず、レガシーＨＭＩＰｖ６タイプのＭＡＰを考察する。このようなシナリオでは、ＶＭＮ１０やＭＲ２０は、受信するルータ通知内のＡＲＯオプションとＭＡＰオプションの両方を入手する。ＭＲ２１はＭＡＰオプションのみを入手する。ＶＭＮとＭＲは、そのような異なる種類の処理オプションを入手可能である場合、いずれかのオプション又はオプションの組み合わせを選択できる。ここでは、このシナリオで生じる特定の事例を用いて問題を明らかにするが、同様の問題がこのシナリオの他の事例でも生じることは当業者であれば容易に理解し得ることである。ＶＭＮ１０がＡＲＯオプションとＭＡＰオプションの両方を処理し、ＭＲ２０がＡＲＯオプションのみを処理し、ＭＲ２１がＭＡＰオプションのみを処理するものとする。本シナリオのこのような事例では、ＭＲ２１は、ＭＡＰオプションを処理して、ＲＣｏＡとＬＣｏＡを入手し、ＭＡＰ４０にてローカル・バインディング登録を行う。このことは、図１のＭＡＰ４０のバインディング・キャッシュ（ＢＣ）７１に詳しく例示されている。問題点を明らかにするために、まずレガシーＭＡＰを考察する。そこで、ＭＡＰではＲＯトレース・パラメータを許容又は利用するための方法が得られないことから、ＢＣ７１の第３列は空欄になっている。ＭＲ２０は、ＡＲＯオプションを処理するだけなので、ＭＡＰ４０では一切登録を行わない。ＶＭＮ１０は、ＡＲＯオプションとＭＡＰオプションとを処理した後、ＲＣｏＡとＬＣｏＡを設定する。ＶＭＮ１０は、次に、ＡＲＯオプションを用いてＭＡＰでのローカル登録を試みる。上記ＡＲＯオプション内の値は、ＲＣｏＡに関連するＬＣｏＡを最適にトレースするのに有用であり得る値であればよい。ＭＡＰは、レガシータイプのＭＡＰなので、ＡＲＯオプションを理解せず、そのオプションを無視し、そのＢＣ７１内で通常のＨＭＩＰｖ６登録を行う。このＶＭＮ１０によってＭＡＰ４０で行われた登録をＢＣ７１の第２行に示す。ＶＭＮ１０は、ＭＡＰ４０にて適切に登録を行った後、そのホーム・エージェントにて登録を行うが、経路最適化を達成するためにＣＮ６０とＡＲＯメカニズムを実行することが可能である。ＶＭＮ１０がＣＮとＡＲＯを実行するのは、ＶＭＮが初めにＭＡＰオプションを処理し、その後ＡＲＯオプションを処理するためである。また、ＶＭＮ１０は、初めにＭＡＰオプションを処理し、その後ＡＲＯオプションを処理するので、ＣＮ６０とＡＲＯを実行する際、ＲＣｏＡをそのＣｏＡとして利用する。ＣＮ６０にて上記ＡＲＯバインディングが行われると、ＢＣ７０の第１行目に示すようなエントリが表示される。ＢＣ７０は、ＣＮ６０でのバインディング・キャッシュである。ＣＮ６０は、ＲＨ２にＭＲ２０のＨｏＡを含む確認応答（ＡＣＫ）を送信する。ＭＲ２０は、ＡＣＫを受信すると、ＣＮ６０がそのＨｏＡとのバインディングを有していないことを知り、ＣＮ６０にてＡＲＯメカニズムを開始する。ＣＮ６０にて良好にＡＲＯメカニズムが行われると、ＭＲ２０のパラメータを有する第２行目のエントリがＢＣ７０に表示される。ＭＲ２０は、ＡＲＯオプションのみを処理するので、ＣＮ６０との通信にはそのＣｏＡとしてＬＣｏＡのみを使用することを理解することが重要である。それに続いて、ＣＮ６０は、再度、ＲＨ２にＭＲ２１のＨｏＡを含むＡＣＫを送信する。ＭＲ２１は、このパケットを受信すると、そのＲＣｏＡを用いてＣＮ６０でＡＲＯ登録を行う。ＭＲ２１がＲＣｏＡを用いてＡＲＯ登録を行うのは、ＭＲ２１は、ＭＡＰオプションを処理することでＲＣｏＡを設定したが、ＡＲＯスタックによりＭＲ２０に送信されたＡＣＫを処理するためである。この登録をＢＣ７０の第３エントリで示す。ＣＮ６０がＢＣ７０を使ってデータ・パケット８０をＶＭＮ１０に送信する場合、そのデータ・パケットは深刻な経路の準最適性問題に直面する。

ＣＮ６０からのデータ・パケット８０は、宛先アドレスとしてＭＲ２１のＲＣｏＡを有する。ルーティング・ヘッダ２には、ＭＲ２０のＬＣｏＡ、ＶＭＮ１０のＲＣｏＡ、ＶＭＮ１０のＨｏＡが含まれる。このパケット８０は、まず、パス１１０を介して送信される。パケットは、最初にＭＡＰ４０に受信される。ＭＡＰ４０には、ＭＲ２１のＲＣｏＡの登録がされているため、このパケットをＭＲ２１のＬＣｏＡへのトンネルにカプセル化する。このトンネルは明確には図示されていない。トンネルされたパケットは、再度パス１１０を介して、ＭＲ２１に到達する。ＭＲ２１は、デカプセル化を行った後、宛先アドレスをＭＲ２０のＬＣｏＡへ変更する。ＭＲ２１は、パケット８０に付加されたＲＨ２から、この次の宛先アドレスを入手する。こうして、パケットは１１０を介してＭＲ２０に到達する。ＭＲ２０は、宛先をＶＭＮ１０のＲＣｏＡに再度変更する。ＭＲ２０にはＶＭＮ１０のＲＣｏＡに最適に到達するための登録がされていないため、パケットはＭＲ２０のホーム・エージェントＨＡ５１を介してトンネルされる。このパケットは、パス１１１を移動し、再びＭＲ２１にてＭＡＰ４０及びＭＲ２１のホーム・エージェントＨＡ５０を介してさらにトンネルされる。この多重カプセル化されたパケットは、ＭＡＰ４０にてデカプセル化され、ＨＡ５０でも再びデカプセル化され、最後にＨＡ５１にてデカプセル化され、最終的にはＭＡＰ４０に受信される。ここで留意すべき重要な点は、これらすべての手順がパス１１１により明らかにされているということである。このことは、図１が複雑になるのを抑えるため明確には図示されていないが、当業者にとってはこれらのルーティング処理はごく単純な処理である。ＭＡＰ４０は、このパケット８０を受け取ると、ＶＭＮ１０のＲＣｏＡへの登録がないことを認識する。このパケットは１１２を介してＭＲ２０のホーム・エージェント、すなわちＨＡ５１へと移動する。そこでパケット８０はＭＲ２０のＬＣｏＡへさらにカプセル化される。このパケットは、その後、パス１１３を移動してＭＲ２１のホーム・エージェントであるＨＡ５０に到達する。ここで、パケットはＭＲ２１のＲＣｏＡへさらにカプセル化される。こうして、多重カプセル化されたパケットはパス１１４を移動しＭＡＰ４０に到達する。ここで、パケットはＭＲ２１のＬＣｏＡへさらにカプセル化され、その後パス１１５を移動する。このパケットをデカプセル化しＭＲ２１にデカプセル化され、ＭＲ２０のＬＣｏＡへ到達する。そこでパケットは再びデカプセル化され、ＶＭＮ１０のＬＣｏＡに到達する。パケットは再度ＶＭＮ１０にてデカプセル化され、最終的にはＶＭＮ１０に消費される。

Ｈｉｒａｎｏ，Ｊ．、Ｎｇ，Ｃ．Ｗ．他、「パケット転送の制御方法及び装置、ならびに通信ノード」、ＷＩＰＯ特許国際公開ＷＯ０６１２９８６３Ａ１号、２００６年１２月 Ｈｉｒａｎｏ，Ｊ．、Ｎｇ，Ｃ．Ｗ．他、「パケット転送の制御方法及び装置」、ＷＩＰＯ特許国際公開ＷＯ０６１２９８５８Ａ１号、２００６年１２月 Ｈｉｒａｎｏ，Ｊ．、Ｎｇ，Ｃ．Ｗ．他、「パケット転送の制御方法及び装置」、ＷＩＰＯ特許国際公開ＷＯ０６１２９８５５Ａ１号、２００６年１２月

Ｊｏｈｎｓｏｎ，Ｄ．Ｂ．、Ｐｅｒｋｉｎｓ，Ｃ．Ｅ．及びＡｒｋｋｏ，Ｊ．、"Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ Ｉｎ Ｉｐｖ６" Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｒｅｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ Ｒｅｑｕｅｓｔｓ Ｆｏｒ Ｃｏｍｍｅｎｔｓ ３７７５ Ｊｕｎｅ ２００４ Ｓｏｌｉｍａｎ，Ｈ．他、"Ｈｉｅｒａｒａｃｈｉｃａｌ Ｍｏｂｉｌｅ ＩＰｖ６ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ （ＨＭＩＰｖ６）" Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ （ＩＥＴＦ） Ｒｅｑｕｅｓｔｓ Ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）４１４０、Ａｕｇｕｓｔ ２００５ Ｄｅｖａｒａｐａｌｌｉ，Ｖ．他、"ＮＥＭＯ Ｂａｓｉｃ Ｓｕｐｐｏｒｔ Ｐｒｏｔｏｃｏｌ" Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ Ｒｅｑｕｅｓｔｓ Ｆｏｒ Ｃｏｍｍｅｎｔｓ ３７７５ Ｊｕｎｕａｒｙ ２００４ Ｃ．Ｎｇ、Ｊ．Ｈｉｒａｎｏ、"Ｓｅｃｕｒｅｄ Ｎｅｓｔｅｄ Ｔｕｎｎｅｌｓ Ｏｐｔｏｍｉｚａｔｉｏｎ ｗｉｔｈ Ｒｏｕｔｅｒ Ａｃｃｅｓｓ Ｏｐｔｉｏｎ"ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ：ｄｒａｆｔ−ｎｇ−ｎｅｍｏ−ａｃｃｅｓｓ−ｒｏｕｔｅｒ−ｏｐｔｉｏｎ−０１．ｔｘｔ、Ｊｕｌｙ １２， ２００４ Ｏｈｎｉｓｈｉ，Ｈ．、Ｓａｋｉｔａｎｉ，Ｋ．、Ｔａｋａｇｉ，Ｙ．、"ＨＭＩＰ ｂａｓｅｄ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｍｅｔｈｏｄ ｉｎ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ"ＩＥＴＦＩｎｔｅｒｎｅｔ Ｄｒａｆｔ：ｄｒａｆｔ−ｏｈｎｉｓｈｉ−ｎｅｍｏ−ｒｏ−ｈｍｉｐ−００．ｔｘｔ、Ｏｃｔｏｂｅｒ ２００３

上記パケットルーティング処理の詳細な説明から、問題は多種多様にわたることが明らかである。それらの問題を以下にさらに詳しく見てみる。一つ目の重大な問題としては、ＶＭＮ１０は、両方のタイプのオプションを取得しＭＡＰ４０がレガシータイプのＭＡＰであることを知らないので、ＭＡＰ４０に対してＡＲＯバインディングを行うが、それはＭＡＰ４０（レガシーＭＡＰ）には認識されない。これにより、ＶＭＮ１０のアクセスネットワークにおける帯域幅が浪費され、ＶＭＮ１０の消費電力が増大する。二つ目の問題としては、ＣＮ６０のバインディング・キャッシュ７０が、ＭＡＰ４０とＭＲの間のピンポンタイプのルーティング問題を引き起こす。例えば、ＣＮ６０からのデータ・パケット８０の最終目的地は、ＶＭＮ１０のＨｏＡであるが、ここに到達するには異種のアドレス（ＭＲ２１のＲＣｏＡ、ＭＲ２０のＬＣｏＡ、ＶＭＮ１０のＲＣｏＡ）を介してパケットを送信しなければならない。この文脈における「異種」とは、ＲＣｏＡ及びＬＣｏＡのエントリが混在している状態を意味する。最終目的地に至るまでにこれらの各エントリに到達しなければならない。そのため、データ・パケットが異なる種類のアドレスを含む場合、ＲＣｏＡに関連するＬＣｏＡに到達後、若しくは、直接ＬＣｏＡに到達後、ＲＣｏＡである可能性があるＲＨ内の次のエントリに到達しなければならない場合もある。ＭＲはある特定のＲＣｏＡへの経路を有していないので、このパケットは、適切なルーティングを行うため、ＭＡＰに到達する必要がある。これがピンポン・ルーティングであり、パス１１０、１１１、１１５に示されている。さらに、ＶＭＮ１０へのデフォルト・パス上の移動ルータはどんな種類のオプションでも処理することが可能であり、従ってＶＭＮ１０の上流ＭＲはＭＡＰでは登録を行わないこともあるので、上記シナリオではこのピンポン・ルーティングが深刻である。このため、ＭＡＰドメインにおいてＭＲからＭＡＰ４０に到達するには、ＭＲがＡＲＯオプションのみを処理した場合、上流ＭＲはそのホーム・エージェントを介してパケットをトンネルしなければならない場合がある。これらすべてのことは、ＣＮ６０からのデータ・パケット８０に異なる種類の気付アドレスが存在することに直接付随するルーティングの準最適性を示している。

次に、このシナリオでの三つ目の問題を検証する。この問題は、ＭＡＰにて最適にＲＣｏＡをトレースすることに関連する。このシナリオでは、ＭＡＰ４０は、レガシーＭＡＰであるので、最適にＲＣｏＡに到達するのに必要なＬＣｏＡをトレースするためのＲＯメカニズムを持っていない。上記ＬＣｏＡには、ＲＣｏＡに直接関連するＬＣｏＡと、上記ＲＣｏＡに到達するために通過する必要のある上流ＭＲのＬＣｏＡとが含まれる。この問題をさらに詳しく説明するため、ＢＣ７１を考察する。例えば、ＲＣｏＡをトレースできるトレース機構が存在しない。レガシーＭＡＰシナリオでは、第３列が空欄となっているものとする。この場合、ＲＣｏＡに関連するＬＣｏＡに最適に到達するためのトレース機構がないことから、パケットは、固定インフラにおける、ホーム・エージェント間でトンネルされ受信されなければならない。これにより、固定インフラ内でピンボール・ルーティングが生じる。これは図１中にパス１１３により示されている。このルーティングパスの準最適性に加えて、上述のパケットパスについての詳しい説明から、パケットは多重カプセル化処理される必要があることが明らかである。これにより平均パケット・サイズが増大し、それが四つ目の問題を引き起こす一因となる。また、パケット８０はシステム内の多数のルータによりデカプセル化されることも示唆した。これが処理遅延やルータにおける処理負担を引き起こし、五つ目の問題となる。これらすべての不具合が示すものは、ＡＲＯやＨＭＩＰｖ６などの異種プロトコルが動作し、一つのＭＡＰがレガシータイプである場合におけるシステムの非効率性である。

次に、図１のＭＡＰ４０があるＲＯ機能を有する場合のシナリオを考える。ＭＡＰ４０がレガシーＭＡＰではなく（あるＲＯ機能を有し）、ノードがＭＡＰ４０にてＡＲＯ登録を実行する場合、前述と同様の問題が生じるが、ルーティングの準最適性の度合いは小さい。そのように準最適性が軽減される理由としては、ＭＡＰ４０は、そのＲＯ機能により、ＭＡＰにて適切な登録が行われている場合、いくつかのＲＣｏＡへ最適に到達するのに必要なＬＣｏＡをトレースできるからである。すでに説明したインフラに関連したピンボール・ルーティング問題の発生はＲＯ対応のＭＡＰの場合では確率的に低い。しかしながら、ＶＭＮやＶＭＮのデフォルト・モバイル・アクセス・ルータは異なる複数種類の処理オプション（ＡＲＯオプション、ＭＡＰオプション）を利用可能であるため、すべての登録がＭＡＰにていつでも行われているわけではない。これはいくつかのノードがＡＲＯオプションしか処理しない場合に発生する。そのため、これら異種の処理オプションに起因して、ＲＯ対応のＭＡＰはピンボール・ルーティング問題を完全には解消できない可能性がある。ＭＡＰ４０がＡＲＯに対応し、ＭＮがＡＲＯオプションに組み込まれている適当なトレース・パラメータを用いて適切なＭＡＰ登録を行う場合、ＡＲＯオプションは受諾される。一方、ＭＡＰ４０がプレフィックス・デレゲーション・ベースの、又は、ＰＳＢＵベースのＲＯメカニズムを有する場合、ＭＡＰ４０はＶＭＮ／ＭＲからのＢＵにあるＡＲＯオプションを受諾しない。しかしながら、ＰＳＢＵにより与えられるプレフィックスは、ある程度ＲＯを実行するには十分なものである。プレフィックス対応のＲＯのＭＡＰ４０のシナリオでは、ＶＭＮ／ＭＲで作成されたＢＵ内のＡＲＯオプションは無駄になる。

上記問題解析から次のことが理解できる。すなわち、ＡＲＯ及びＨＭＩＰｖ６の異種シナリオにおいてＭＡＰがレガシーＭＡＰである場合、たとえＶＭＮやＶＭＮのすべての上流ＭＲがＭＡＰオプションを処理しＭＡＰにて登録を行ったとしても、ＭＡＰには利用できるＲＯメカニズムがないため、ＣＮとのネスト状態のＮＥＭＯの経路最適化には全く適さない。従って、そのようなシナリオにはＭＡＰを使用しないメカニズムが好ましい。ＡＲＯ及びＨＭＩＰｖ６の異種シナリオにおいて、ＭＡＰがＲＯ対応である場合、そのメカニズムによってＣＮでの異種アドレスの形成及びＭＡＰでの対象とするＲＣｏＡに対するトレースの欠落が防止される限り、ＭＡＰを経路最適化処理に利用することが可能である。さらに、ＲＯ対応のＭＡＰシナリオにおいても、ノードがＣＮと完全なエンド・ツー・エンドＡＲＯタイプのＲＯを実行したい場合がある。このようなことは、従来技術の問題解析にも示したように、ノードがＭＡＰオプションの後にＡＲＯオプションを処理する場合には不可能である。ノードは、それらの２つのオプションを上記の順で処理する場合、結局ＲＣｏＡを用いてＡＲＯを実行することになり、完全なＡＲＯ効果を得ることができなくなる。従って、ＭＡＰドメインにおいて、ＭＡＰを伴わずしてＣＮとの完全なエンド・ツー・エンドＡＲＯタイプのＲＯを達成するためのメカニズムが必要である。

そこで、本発明は、上記先行技術の不具合や欠点を克服する、若しくは、大幅に改善することを目的とする。具体的には、本発明は、ＡＲＯ及びＨＭＩＰｖ６の異種シナリオにおいて、アーキテクチャにＭＡＰが一つしか存在しない場合における、２つの目的を有する。第１の目的は、ＡＲＯ及びＨＭＩＰｖ６の異種シナリオにおいて、ＣＮとの経路の最適化を達成するためのメカニズムを提供することにある。ここで、ＡＲＯ及びＨＭＩＰｖ６の異種シナリオでは、ＶＭＮとＭＲはいずれもＡＲＯ及びＨＭＩＰｖ６プロトコルを実装し、階層における一つのＭＡＰはＲＯ機能を有する、若しくは、ＲＯ機能を有しない。第２の目的は、優れたＲＯ機能がＶＭＮのフローに必要な場合にＡＲＯタイプのＲＯを実現できるようにして、ＣＮとの経路の最適化を可能とすることにある。

上記目的を達成するため、本発明は、以下のシステム、方法及び装置を提供する。

本発明は、ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムを提供し、ＶＭＮ及びＭＲは、ＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装しているものとする。また、このシステムでは、ドメイン・アーキテクチャ内に一つのＭＡＰが存在し、そのＭＡＰにはＲＯ機能が実装され、ＨＡにはＡＲＯプロトコルが実装されているものとする。このようなシステムにおいて、任意の第１ノードは、該任意の第１ノードに処理されたオプションに関係なく、任意の第２ノードとＡＲＯを実行したい場合、そのＬＣｏＡを気付アドレスとして使用するものとする。

本発明は、上記システムにおける任意の第１ノードはＶＭＮであり、そのＬＣｏＡをＣｏＡとして用いてそのＣＮの内の一つ又は複数とＡＲＯを行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＭＲであり、そのＬＣｏＡを気付アドレスとして用いてＶＭＮのＣＮ若しくは他のＭＲのＣＮとＡＲＯを行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＶＭＮであり、そのＬＣｏＡをＣｏＡとして用いてその一つ又は複数のＨＡとＡＲＯを行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＭＲであり、そのＬＣｏＡをＣｏＡとして用いてその一つ又は複数のＨＡとＡＲＯを行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意のノードはＭＲであり、そのＬＣｏＡをＣｏＡとして用いてその一つ又は複数のＣＮとＡＲＯを行う上記システムにおいて採用される方法を提供する。

本発明は、ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムを提供し、ＶＭＮ及びＭＲは、ＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装しているものとする。また、このシステムでは、ドメイン・アーキテクチャ内に一つのＭＡＰが存在し、そのＭＡＰにはＲＯ機能が実装され、ＨＡにはＡＲＯプロトコルが実装されているものとする。このようなシステムにおいて、任意の第１ノードは、該任意の第１ノードが処理中のオプションに関係なく、任意の第２ノードとＨＭＩＰｖ６を実行したい場合、そのＲＣｏＡを気付アドレスとして使用するものとする。

本発明は、上記システムにおける任意の第１ノードはＶＭＮであり、そのＲＣｏＡを用いてそのＣＮの内の一つ又は複数とＨＭＩＰｖ６を行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＶＭＮであり、そのＲＣｏＡを用いてその一つ又は複数のＨＡとＨＭＩＰｖ６を行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＭＲであり、そのＲＣｏＡを用いてそのＣＮの内の一つ又は複数とＨＭＩＰｖ６を行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＭＲであり、そのＲＣｏＡを用いてその一つ又は複数のＨＡとＨＭＩＰｖ６を行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＶＭＮであり、そのＲＣｏＡをローカルホームアドレスとして、及び、そのＬＣｏＡを気付アドレスとして使用して、ＭＡＰにてＲＯベースのローカル登録を行う上記システムにおいて採用される方法を提供する。

本発明は、上記システムにおける任意の第１ノードはＭＲであり、そのＲＣｏＡをローカルホームアドレスとして、そのＬＣｏＡを気付アドレスとして使用して、ＭＡＰにてＲＯベースのローカル登録を行う上記システムにおいて採用される方法を提供する。

本発明は、ＭＲがＭＡＰオプションを処理しておらず、それに直接接続されたＶＭＮ又はＭＲがＭＡＰにてもうすでにＲＯベースのローカル登録を行っている場合、ＭＲはＭＡＰオプションを処理してＲＣｏＡを取得し、ＭＡＰにてＲＯベースのローカル登録を行う上記システムにおいて採用される方法を提供する。

上記方法に記載されているＲＯ登録は、前述のＲＣｏＡに到達するのに必要なＬＣｏＡが最適な方法で取得できるよう、ＭＡＰにてＲＯパラメータを用いてＲＣｏＡをホーム・アドレスとして登録する方法である。

本発明は、ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムを提供し、ＶＭＮ及びＭＲは、ＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装しているものとする。また、このシステムでは、ドメイン・アーキテクチャ内に一つのＭＡＰが存在し、このＭＡＰがレガシーＨＭＩＰｖ６タイプのものであり、ＨＡにはＡＲＯプロトコルが実装されているものとする。このようなシステムにおいて、ＭＲは、ＭＡＰがレガシータイプであることを知っている場合、そのＲＡ内のＭＡＰオプションを送信しないということを決定する。

本発明は、ＭＲがＭＡＰタイプの識別に、ＲＡに付加された新しいＭＡＰオプションを利用する上記システムにおいて採用される方法を提供する。

上記方法に記載されているタイプ情報は、ＭＡＰに関連するＲＯスキームのタイプに関する情報であってもよいし、レガシーＭＡＰに関する情報であってもよい。

本発明は、ＭＲがＭＡＰタイプの識別に、ＲＡに付加された新しいオプションを利用する上記システムにおいて採用される方法を提供する。

上記方法に記載されているタイプ情報は、ＭＡＰに関連するＲＯスキームのタイプに関する情報であってもよいし、レガシーＭＡＰに関する情報であってもよい。

本発明は、ＭＲがＭＡＰタイプの識別に、明示的シグナリングを利用する上記システムにおいて採用される方法を提供する。

上記方法における明示的シグナリングは、ＡＲＯオプション内のアドレスはＭＲのローカル気付アドレスであるＭＡＰにて行われるＡＲＯタイプのＢＵであってもよい。

上記方法における明示的シグナリングは、プレフィックス・デレゲーション要求タイプのメッセージであってもよい。

上記システムでＭＡＰオプションを送信しないと決定したＭＲは、そのＬＣｏＡを用いて、それに直接接続されているＶＭＮの若しくはＭＲのＨＡ又はＣＮとＡＲＯを実行してもよい。

上記システムでＭＡＰオプションを送信しないと決定したＭＲは、そのＲＣｏＡを用いて、それに直接接続されているＶＭＮの若しくはＭＲのＨＡ又はＣＮとＡＲＯを実行してもよい。

本発明は、上記システム及び方法に記載したようなシステムにおけるＶＭＮと関連する装置を提供する。

本発明は、上記システム及び方法に記載したようなシステムにおけるＭＲと関連する装置を提供する。

本発明は、ＡＲＯやＨＭＩＰｖ６の混在する環境下でも有用なメカニズムを提供できるという利点を有する。

図１は、従来技術のプロトコルが配置され、アーキテクチャに一つのＭＡＰが存在する場合のＡＲＯ及びＨＭＩＰｖ６の統合シナリオを示すネットワーク図である。 図２は、本発明の好適な実施形態に係るＲＯ対応ＭＡＰシナリオにおいてＶＭＮがＣＮとＡＲＯを実行することを決定した場合の主要な発明を示すメッセージ・シーケンス・チャートである。 図３は、本発明の好適な実施形態に係るＲＯ対応ＭＡＰシナリオにおいてＶＭＮがＣＮとＨＭＩＰｖ６を実行することを決定した場合の主要な発明を示すメッセージ・シーケンス・チャートである。 図４は、本発明の好適な実施形態に係るＶＭＮでの処理に関連するフローチャートである。 図５は、本発明の好適な実施形態に係るＭＲでの処理に関連するフローチャートである。 図６は、本発明の好適な実施形態に係るＲＯ対応ＭＡＰシナリオにおける解決法の効果を示すネットワーク図である。 図７は、本発明の好適な実施形態に係るレガシーＨＭＩＰｖ６ＭＡＰシナリオにおける解決法の効果を示すネットワーク図である。

本発明では、ＡＲＯ及びＨＭＩＰｖ６の統合シナリオにおいて経路最適化を達成するための３つの方法を提示する。そのシナリオでは、ＶＭＮ及びＭＲにＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルが実装され、ホーム・エージェントにＡＲＯプロトコルが実装され、ＣＮにＡＲＯが実装される。アーキテクチャ内の一つのＭＡＰはレガシータイプのＭＡＰ若しくはＲＯ対応ＭＡＰであってもよい。第１の方法としては、処理されるオプション（ＡＲＯ、ＭＡＰ若しくはＡＲＯとＭＡＰ）に関係なく、ＶＭＮ／ＭＲは、自身のＣＮ、ＨＡ又は他のノードのＣＮとＡＲＯを実行したい場合、ＶＭＮ／ＭＲがそのフローに対して最大のＡＲＯ効果を得ることができるメカニズムを利用する。第２の方法としては、ここでもまた、処理されるオプション（ＡＲＯ、ＭＡＰ若しくはＡＲＯとＭＡＰ）に関係なく、ＶＭＮ／ＭＲが一つ又は複数のＣＮとＨＭＩＰｖ６を実行したい場合、若しくは、ＭＲに直接接続されたＶＭＮ／ＭＲがＣＮとＨＭＩＰｖ６を実行したい場合、ＶＭＮ／ＭＲは、効率的な所在管理と共に経路最適化を実現できる第２の方法を採用する。第３の方法としては、アーキテクチャにレガシーＭＡＰが存在する場合、ＭＲは、ＶＭＮとＭＲとがＣＮ又はＨＡとの間に最適な経路を持つことができるよう決定を下す。

第１の好適な実施形態では、上記第１の方法が開示されている。この方法は本発明の２つの目的を達成するためである。一つは、ＲＯ対応ＭＡＰ環境下においてＲＯを実現することであり、もう一つは、ノードが厳しい遅延要件を有するフローにおいて完全なＡＲＯタイプのエンド・ツー・エンドＲＯを実行させることができるようにすることである。この方法において、ＶＭＮ／ＭＲは、自身のＣＮ、ＨＡ又は他のノードのＣＮとＡＲＯを実行したい場合、ＶＭＮ／ＭＲがそのフローにおいて最大のＡＲＯ効果を得ることができるよう、自身のローカル気付アドレスを気付アドレスとして使用する。

これについて図２を用いて詳しく説明する。図２では、ＶＭＮ２１０はＭＲ２２０に直接接続され、ＭＲ２２０はＭＲ２２１に直接接続され、ＭＲ２２１はＡＲ２３０に直接接続される。つまり、図２では深いネスト状態のシナリオを示す。ＡＲ２３０はＭＡＰ２４０に直接接続される。このＭＡＰ２４０は、ＲＯ対応のものとする。ＨＡ２５０、ＨＡ２５１、ＨＡ２５２は、それぞれ、ＭＲ２２１、ＭＲ２２０、ＶＭＮ２１０のホーム・エージェントである。ＶＭＮ及びＭＲは、ＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装しているものとする。また、ＶＭＮ２１０はＡＲＯ対応のＣＮ２６０とデータ通信セッションを行っているものとする。

ＭＲ２２１は、ＡＲ２３０からＭＡＰオプションを含むＲＡ２６１を受信する。この場合、ＨＭＩＰｖ６スタックがトリガーされ、ＭＲ２２１とＭＡＰ２４０はローカル登録を行う。このことがメッセージ２６２に示されている。上記登録が終了すると、ＭＡＰ２４０はＢＣ２６３に示すようなエントリを得る。ＭＡＰ２４０はＲＯ対応であるので、ＭＲ２２１はその登録の際にＲＯパラメータを与える。このＲＯパラメータはプレフィックスであってもよいし、ＡＲＯアドレスであってもよい。続いて、ＭＲ２２１は、自身のホーム・エージェント、すなわち、ＨＡ２５０にて登録を行う。このＢＵ及びバインディング確認応答（ＢＡ）手順は、メッセージ２６４、２６５に示される。上記登録後、ＨＡ２５０は２６７に示すようなバインディング・キャッシュを得る。ＭＲ２２１はＭＡＰオプションのみを処理するので、ＨＡ２５０での登録はＨＭＩＰｖ６タイプの登録と同様になるが、ＢＣ２６７にはＭＲ２２１のモバイル・ネットワーク・プレフィックス（ＭＮＰ）も含まれることになる。このプレフィックスはＨＡ２５０によりＭＲ２２１へ委譲される。

上記ＨＡ２５０での登録に続き、ＭＲ２２１はＲＡ２６８を送信する。このＲＡにはＡＲＯオプションとＭＡＰオプションの両方が含まれる。このＡＲＯオプションにはＭＲ２２１のホーム・アドレスが含まれており、さらにＭＲ２２１のＲＣｏＡも含まれていてもよい。ＭＡＰオプションにはＭＡＰ２４０のアドレスが含まれる。ＭＲ２２０は、これらのオプションを受信すると、このシナリオでは、ＡＲＯオプションのみを処理することを決定するものとする。この場合、気付アドレスが一つだけ、すなわち、ＬＣｏＡが設定されることとなる。ＭＲ２２０は、その後、そのホーム・エージェント、すなわち、ＨＡ２５１にＢＵを送信する。ＭＲ２２０はＡＲＯオプションを含むＢＵを作成する。このＭＲ２２０により送信されたＢＵは、メッセージ２６９に示される。このメッセージ２６９はＭＲ２２１のホーム・エージェントとＭＡＰ２４０へトンネルされる。この二重カプセル化されたメッセージが２７０に示される。そのようなトンネリングが行われた後、ＭＡＰ２４０にてメッセージがデカプセル化され、単一レベルにトンネルされたメッセージ２７１がＨＡ２５０へ送信される。ＨＡ２５０では、ＢＵメッセージがさらにデカプセル化され、デカプセル化されたメッセージ２７２がＨＡ２５１へ送信される。ＨＡ２５１にて良好に登録が行われると、ＢＣ２７３はＡＲＯパラメータとＭＮＰパラメータを入手する。ＭＲ２２０のＬＣｏＡがＢＣ２７３に登録されることが分かる。良好に登録が行われると、ＨＡ２５１はＭＲ２２０にＢＡを送信する。このＢＡにはＭＲ２２１のＨｏＡが宛先アドレスとして含まれる。こうしてＨＡ２５１により送信されたＢＡメッセージ、すなわち、２７４は、まず、ＨＡ２５０に受信される。その後、このメッセージは、図２のメッセージ２７５に示されるように、ＭＲ２２１のＲＣｏＡへトンネルされる。このトンネルされたメッセージ２７５はさらにＭＡＰ２４０により受信される。ＭＡＰ２４０はＭＲ２２１のＲＣｏＡに関連するＬＣｏＡを有する。こうして、ＭＡＰ２４０はこのメッセージをトンネルする。このトンネルされたメッセージは２７６に示される。ＭＲ２２１は、このメッセージ２７６を受け取ると、トンネルを２回デカプセル化し、宛先アドレスをＭＲ２２０のＬＣｏＡへと変更し、パケットをさらにルーティングする。こうしてルーティングされたＢＡメッセージ２７７は最終的にＭＲ２２０に到達する。ＭＲ２２１は、ＭＲ２２１のＨｏＡに送信されたＡＣＫを受信すると、ＨＡ２５１とのＡＲＯメカニズムを開始する。このことがメッセージ２７８に示される。メッセージ２７８に関連するシグナリング及びルーティングパスの詳細は明示されていないが、当業者であれば容易に想到し得ることである。上記ＡＲＯ登録が完了すると、ＨＡ２５１のバインディング・キャッシュがＢＣ２７９に示されているようになる。通常動作時、ＭＲ２２１は、ＭＡＰオプションを処理してＲＣｏＡを設定すると、ＣＮ２６０にだけそのＲＣｏＡを公開する。しかしながら、本発明の第１の方法を取り上げた本実施形態では、ＭＲ２２１がＣＮ（自身の若しくは他のノードのＣＮ）とＡＲＯを行う場合、そのＬＣｏＡを気付アドレスとして使用する。こうして、ＢＣ２７９には、そのようなローカル気付アドレスのエントリが含まれることとなる。

上記登録が完了すると、ＭＲ２２０は場合によってＲＡ２８０を送信する。このＲＡ２８０にもＡＲＯオプションとＭＡＰオプションとが含まれる。ＶＭＮ２１０は、ＡＲＯオプション、ＭＡＰオプション、若しくは、ＡＲＯオプションとＭＡＰオプションの両方を処理する。ＶＭＮは、ＭＡＰオプションとＡＲＯオプションの両方を処理する場合、結局そのＣＮとＲＣｏＡベースのＡＲＯを実行することになるということが従来技術の問題解析にも見られた。本実施形態に概説された方法の主要なポイントは、ＶＭＮにＣＮとＲＣｏＡベースのＡＲＯを実行させないようにすることである。

ＶＭＮ２１０は、上記方法を利用する場合、そのホーム・エージェントへの登録がまだであれば、まずは登録を行う。ここで理解すべき重要な点は、ＶＭＮ２１０がさらにＭＡＰ２４０に登録を行い、いくつかのフローにおいてＲＣｏＡを利用できるということである。しかしながら、ＶＭＮ２１０がＣＮとＡＲＯを行いたいということであれば、この方法に従うべきである。

ＨＡ２５２へのＢＵメッセージが２８１に示される。このメッセージは、ＭＲ２２０のホーム・エージェント、すなわち、ＨＡ２５１を介してトンネルされる。ＭＲ２２０は、ＨＡ２５１とＡＲＯを行ったので、ＮＥＭＯ−ＦＷＤオプションをこのメッセージに挿入する。ＭＲ２２１は、このトンネルされたメッセージ２８２を処理する場合、ＨＡ２５１とのＡＲＯバインディングを有するため、送信元アドレスをそのＬＣｏＡに変更し、さらにメッセージ２８２をルーティングする。このＢＵメッセージ２８２はＨＡ２５１にてデカプセル化され、そのデカプセル化されたＢＵメッセージ２８４が最終的にＨＡ２５２に到達する。ＨＡ２５２でのバインディング・キャッシュは、ＢＣ２８３に示される。

ここで理解すべき重要な点は、ＶＭＮ２１０がすでにＭＡＰオプションのみを処理し、ＨＡ２５２にて適切な登録を行っている場合、ＶＭＮは再度そのような登録を行う必要がないということである。本実施形態では、登録が行われておらず、ＬＣｏＡを用いてＡＲＯ登録を行うことを決定するものとする。そのような登録が行われた後、ＨＡ２５２はＭＲ２２０のＨｏＡへＡＣＫを送信する。このメッセージは２８５に示される。このメッセージはＨＡ２５１に到達し、ＭＲ２２０のＬＣｏＡへトンネルされる。このトンネルされたメッセージ２８６の宛先アドレスは、ＭＲ２２１のＬＣｏＡとなる。ＭＲ２２１はＢＡ２８６を受信し、宛先アドレスをＭＲ２２０のＬＣｏＡへと変更し、ＢＡメッセージをさらにルーティングする。このメッセージ２８６はＭＲ２２０に送信され、そこで完全にデカプセル化される。このデカプセル化されたメッセージ２８７は最終的にＶＭＮ２１０に到達する。その後、ＭＲ２２０はＨＡ２５２とＡＲＯを行う。このＡＲＯシグナリングメッセージは２８８に示され、ＨＡ２５２にて作成されたＢＣは２８９に示される。ここでも、ＭＲ２２０は、ＡＲＯオプションのみを処理するので、ＨＡ２５２とＡＲＯを行う際は単にそのＬＣｏＡを登録するだけであることが分かる。続いて、ＭＲ２２１はＨＡ２５２とＡＲＯを行い、それがメッセージ２９０に示される。ＨＡ２５２でのバインディング・キャッシュはＢＣ２９１に示される。ここでも、前に述べたように、ＭＲ２２１はＭＡＰオプションのみを処理したが、そのＡＲＯスタックがトリガーされると、ＭＲ２２１はＣＮ（ＨＡ２５２）でのＡＲＯ登録の際、ＬＣｏＡを用いる。ＢＣ２９１にはＨＡ２５２から最適にＶＭＮ２１０をトレースするための関連するすべてのパラメータが含まれることは当業者であれば理解し得ることである。

次に、ＶＭＮ２１０はＣＮ２６０とＡＲＯを行い、メッセージ２９２にそれを示す。そして、ＣＮ２６０でのバインディング・キャッシュはＢＣ２９３に示される。ＲＣｏＡを処理したか否かに関係なく、ＶＭＮ２１０がＬＣｏＡだけを用いて、ＣＮとＡＲＯを行うことが分かる。ＶＭＮ２１０はＲＣｏＡにより他のＣＮと通信を行うことが可能である。このことは次の実施形態でさらに詳しく説明する。ＶＭＮ２１０とＣＮ２６０間でＡＲＯ登録が良好に行われると、ＭＲ２２０はＣＮ２６０とＡＲＯを行う。ＭＲ２２０は再び自身のＬＣｏＡだけを用いてＣＮ２６０とＡＲＯを行い、このＡＲＯ登録がメッセージ２９４に示される。このＭＲ２２０によるＡＲＯは、ＶＭＮ２１０のデータ・パケットに含まれるＮＥＭＯ−ＦＷＤオプション又は、ＣＮ２６０から送信されたＡＣＫによりトリガーされている。ＭＲ２２０がＣＮ２６０にてＡＲＯを行うと、ＣＮ２６０でのバインディング・キャッシュはＢＣ２９５のようになる。その後、ＭＲ２２１はＣＮ２６０とＡＲＯを行い、このＡＲＯ確立メッセージが２９６に示される。そのように登録が良好に行われた後、ＣＮ２６０でのバインディング・キャッシュはＢＣ２９７のようになる。ＢＣ２９７から、ＣＮ２６０はＶＭＮ２１０に最適に到達するのに必要なすべてのＬＣｏＡをトレースすることが可能であることが分かる。これに続いて、ＶＭＮ２１０とＣＮ２６０は２９８に示すような双方向データ通信を行うことができる。この通信パス及び構造は純粋なＡＲＯタイプである。このように、ＶＭＮ／ＭＲは、複数種類のオプションを処理するが、ＣＮとのＡＲＯの際にはＬＣｏＡを使用することで完全なＲＯを達成し、従来技術の解析にも示したようなルーティングの準最適性を解消する。また、このメカニズムにより、すでに処理されたものがＭＡＰオプションのみであったとしても、任意のＶＭＮは厳しい遅延要件を有するフローに対して完全なＡＲＯを実行することを決定できる。このため、レイヤ３はアプリケーションから送られるフローに関するいくつかの要件を必要とする。これは、ソケットを実装する際にフラグを付加するなど、様々な方法で行うことができる。

本発明の別の好適な実施形態では、本発明の第２の方法を説明する。第２の方法では、ＶＭＮ／ＭＲがＡＲＯオプションとＭＡＰオプションの両方を処理可能な状況を取り扱う。しかしながら、ＶＭＮ／ＭＲは、所在管理効率に関係するＲＯのためにＣＮとＨＭＩＰｖ６を行いたい場合、そのＣｏＡとしてＲＣｏＡを用いてＭＡＰと通常のＨＭＩＰｖ６登録を行い、ＣＮとのバインディングを登録する際にはそのＲＣｏＡを用いる。ＭＡＰへのＲＯ関連のローカルＢＵのタイプは、ＭＡＰのＲＯ機能によって決まる。従来技術のシナリオでは、ＶＭＮが両オプションを処理する場合、ＶＭＮは結局ＲＣｏＡを用いてＣＮとＡＲＯを実行することになり、それにより前述のすべての問題が引き起こされる。第２の方法ではまた、ＭＲはＡＲＯオプションのみを処理するが、それに直接接続されているＶＭＮ又はＭＲがＭＡＰオプションを処理しＭＡＰに接続されている場合に、ＭＡＰオプションを処理して適切なＭＡＰ登録を行う場合も取り扱う。この第２の方法の目的は、ＶＭＮとＭＲがＡＲＯオプションとＭＡＰオプションの両方を処理する場合にも、フローに対してＲＣｏＡベースのＲＯを行うことである。ＲＣｏＡベースのＲＯは、より少ないジッターが要求されるフローや、電力が制限されたＶＭＮや、ネットワークシグナリング負荷を軽減することが好ましい場合に有用である。

この方法は、図３に示すようなシグナリング及びデータ・パケット・ルーティング処理を検討することでさらに詳しく説明する。ＶＭＮ３１０はＭＲ３２０に直接接続され、ＭＲ３２０はＭＲ３２１に直接接続され、ＭＲ３２１はＡＲ３３０に直接接続され、ＡＲ３３０はＭＡＰ３４０に直接接続される。ＭＡＰ３４０はＲＯ対応のものとする。また、ＨＡ３５０、ＨＡ３５１、ＨＡ３５２は、それぞれ、ＭＲ３２１、ＭＲ３２０、ＶＭＮ３１０のホーム・エージェントである。ＶＭＮ３１０はＡＲＯ対応のＣＮ３６０とデータ通信セッションを行っているものとする。

ＭＲ３２１は、ＲＡ３６１とＭＡＰオプションを受信し、その後、ＭＡＰ３４０にてローカルＢＵを行う。これをメッセージ３６２に示す。続いて、ＭＲ３２１はホーム・エージェントＨＡ３５０に対しＢＵ登録を行う。これらの登録を図３のメッセージ３６４、３６５に示す。ＨＡ３５０は、その後、ＢＣ３６７に示すようなバインディング・キャッシュを得る。適切な登録を行った後、ＭＲ３２１はＡＲＯオプションとＭＡＰオプションの両方を含むＲＡ３６８を送信する。このシナリオでは、ＭＲ３２０はＡＲＯオプションのみを処理するものとする。このような場合、ＭＲはＬＣｏＡを用いてＡＲＯオプションを含むＢＵメッセージ３６９をホーム・エージェントＨＡ３５１に送信する。このメッセージは、メッセージ３７０に示されるように、ＭＲ３２１により二重にカプセル化される。この場合も先と同様に、ＭＡＰ３４０はこのメッセージをデカプセル化し、デカプセル化されたメッセージ３７１はＨＡ３５０に送られる。ＨＡ３５０はそのメッセージをさらにデカプセル化し、メッセージをＨＡ３５１へルーティングする。このＨＡ３５０を介してルーティングされたＢＵメッセージを３７２に示す。

ＨＡ３５１でこの登録が行われると、バインディング・キャッシュはＢＣ３７３に示されているようになる。この登録ではＭＲ３２０のＬＣｏＡを気付アドレスとして用いることに留意する。前述の実施形態でも述べたように、ＨＡ３５１からのＡＣＫは様々なパスを通り及びトンネリングをされる。このことは図３のメッセージ３７４、３７５、３７６、３７７に示される。ＭＲ３２１は、ＨＡ３５１からＭＲ３２１のＨｏＡ宛てのＡＣＫを受信すると、ＨＡ３５１とＡＲＯを行う。これをメッセージ３７８に示す。ＭＲ３２１は、前述の実施形態に開示された発明の方法に従ってＡＲＯのＢＵ登録を行うものとする。すなわち、ＭＲ３２１は、ＭＲ３２０のホーム・エージェントとＡＲＯを行う場合、ＬＣｏＡを用いてＡＲＯを行う。上記ＡＲＯ登録が行われた後の、ＨＡ３５１でのバインディング・キャッシュはＢＣ３７９に示される。そこでのエントリはＭＲ３２０に最適に到達するのに十分であることが分かる。そのような登録が完了すると、ＭＲ３２０は両オプションを含むＲＡ３８０を送信する。ＶＭＮ３１０がＣＮ３６０とＲＣｏＡベースのＲＯを行うことを決定したと仮定すると、ＶＭＮ３１０はＲＣｏＡだけを用いてＨＭＩＰｖ６スタックを起動する。この場合でも同様に、ＭＡＰ３４０にてＲＯパラメータを有する適切なローカルＢＵを登録する必要がある。このローカルＢＵメッセージを３８１に示す。ＭＲ３２０はＭＡＰ３４０とのバインディングを持たないため、そのホーム・エージェント、すなわちＨＡ３５１を介してパケットをトンネルすることが可能である。これを図３のトンネルされたメッセージ３８２として示す。

ＭＲ３２０は、このＮＥＭＯ−ＦＷＤオプションを含むメッセージ３８２を受信すると、ＨＡ３５１とのＡＲＯバインディングをもうすでに実行しているので、単に送信元アドレスをＬＣｏＡへ変更し、パケットをさらにルーティングする。ローカル登録メッセージはＨＡ３５１にてデカプセル化され、ＭＡＰ３４０へと送られる。このデカプセル化されたメッセージを３８３に示す。この登録がＭＡＰ３４０により受諾されると、バインディング・キャッシュはＢＣ３８４に示されているようになる。ここで理解すべき重要な点は、ＭＡＰ３４０での登録は標準のＨＭＩＰｖ６におけるものとは異なる。ここでは、ローカルＢＵは、ＲＣｏＡに到達するのに必要な上流ＭＲのＬＣｏＡを入手できるよう、ＲＯパラメータを含む必要がある。ＭＡＰ３４０はＶＭＮ３１０に応答を送る。このＡＣＫメッセージを３８５に示す。このメッセージはＶＭＮ３１０のＬＣｏＡへ送信され、ＭＲ３２０のホーム・エージェントに到達する。そこでメッセージ３８６としてＭＲ３２１を介してＭＲ３２０のＬＣｏＡへとトンネルされる。このメッセージ３８６は最終的にＭＲ３２０にてデカプセル化され、ＭＡＰ３４０からのＢＡメッセージ３８７はＶＭＮ３１０に到達する。ＭＲ３２０は、メッセージ３８６をデカプセル化する時、メッセージがホーム・エージェントから来ていることを認識するので、パケットの送信元アドレスでは登録を行わない。さらに、ＭＲ３２０は、デカプセル化されたパケットの送信元アドレスがＭＡＰアドレスであるかどうかを調べる。ＭＡＰアドレスである場合、ＭＲ３２０はＭＡＰオプションを処理し（次にＲＡを受信する、若しくは、記憶されたＭＡＰオプション値を使用する時）、ＭＡＰ３４０にて登録を行う。この登録は図３の３８８、３８９に示される。ＭＲ３２０はＭＡＰ３４０にてＲＯパラメータを組み込んだローカルＢＵを行う。この登録後のＭＡＰ３４０でのバインディング・キャッシュはＢＣ３９０に示される。

その後、ＶＭＮ３１０は、ＭＩＰｖ６方法により、ＣＮ３６０にてそのＨｏＡをＲＣｏＡに結合する。ここで理解すべき重要な点は、この時、ＶＭＮ３１０はＡＲＯオプションを処理したかもしれないが、他のフローに対するＲＯにそれを利用しているかもしれないということである。ＭＩＰｖ６方法によりＣＮ３６０にてそのようなＨｏＡ−ＲＣｏＡバインディング登録を行う前に、ＶＭＮ３１０はそのホーム・エージェントＨＡ３５２に登録する必要がある。この登録は図３には明示されていない。ＶＭＮ３１０はＨＡ３５２に登録する際ＲＣｏＡを用いることができる。若しくは、ＶＭＮ３１０は、すでにＡＲＯオプションを処理している場合、ＬＣｏＡを用いてＨＡ３５２にてＡＲＯ登録を行っていた可能性もある。これらは図３には明示されていない。ＨＡ３５２では登録タイプ（ＲＣｏＡベースのＭＩＰｖ６登録又はＬＣｏＡベースのＡＲＯ登録）に関係なく、ＶＭＮ３１０はＲＣｏＡを用いることができ、ＭＩＰｖ６方法によりＣＮ３６０にてＨｏＡ−ＲＣｏＡバインディングを行うことができる。

ＭＩＰｖ６方法によるＣＮ３６０でのＨｏＡ−ＲＣｏＡバインディング登録はメッセージ３９１に示される。そのような登録後のＣＮ３６０でのＢＣは３９２に示される。次に、ＶＭＮ３１０はＣＮ３６０にデータ・パケットを送信する。ＶＭＮ３１０は、ＭＩＰｖ６方法によりＣＮ３６０にてＨｏＡ−ＲＣｏＡバインディング登録を行ったので、そのパケットを、ＭＡＰ３４０を介してトンネルする。ＶＭＮ３１０は、ＭＡＰ３４０にてＡＲＯタイプのローカル登録を行った場合、ＮＥＭＯ−ＦＷＤオプションを外部トンネルヘッダに組み込む。このＣＮ３６０へトンネルされたデータは３９３に示される。このメッセージ３９３はＭＡＰ３４０にてデカプセル化され、内部メッセージ３９４がＣＮ３６０へ送信される。ＣＮ３６０は、データ・パケットをＶＭＮ３１０へ送信する場合、そのパケットをＶＭＮ３１０のＲＣｏＡへ送信する。このメッセージ３９５はＭＡＰ３４０に受信される。ＭＡＰはＢＣ３９０を使ってＶＭＮ３１０のＲＣｏＡへ到達するのに必要なすべてのＬＣｏＡを見つけ出し、パケットを宛先アドレス及びＲＨ２に存在するすべてのＬＣｏＡと共にトンネルにカプセル化する。このカプセル化されたメッセージ３９６は最終的にＶＭＮ３１０に到達する。ＭＡＰ３４０では、ＢＣ３９０に示されるＲＯパラメータがＡＲＯパラメータである場合、トレース機構がＶＭＮ３１０のＲＣｏＡに関連するＲＯパラメータと、ＢＣ３９０のＲＣｏＡの列エントリとの間で一致するものを見つけ出す。ＶＭＮ３１０のＲＣｏＡに関連するＲＯパラメータがプレフィックスである場合、このプレフィックスと一致するプレフィックスをＢＣ３９０のＬＣｏＡの列エントリから検索する。このＭＡＰ３４０でのＲＯトレース機構により、一回のトレースループ後、ＭＲ３２１のＬＣｏＡ、ＭＲ３２０のＬＣｏＡ、ＶＭＮ３１０のＬＣｏＡが得られる。

前述の実施形態に記載された方法をさらに理解するため、本実施形態では、前述の方法を実施するＶＭＮの動作について説明する。ＶＭＮプロトコルスタックのレイヤ３には、インターネット・プロトコル・バージョン６（ＩＰｖ６）ルーティング・モジュール、ＭＩＰｖ６ルーティング・モジュール、ＭＩＰｖ６から導出されたＡＲＯルーティング・モジュール、同様にＭＩＰｖ６から導出されたＨＭＩＰｖ６ルーティング・モジュールが含まれるものとする。上記ＨＭＩＰｖ６モジュールは、通常のＨＭＩＰｖ６モジュールよりも多くの機能を有する。上記追加機能は、ＭＡＰのタイプに関連するＲＯパラメータによりＭＡＰにてローカルＢＵを行うための方法であることが好ましい。さらに、ＶＭＮは、レイヤ３にて図２、図３に概略的に示される機能を組み込んだ新しい処理モジュールを有するものとする。その処理モジュールは、その状態によって、ＡＲＯ、ＨＭＩＰｖ６、標準ＩＰｖ６などの異なるルーティング・モジュールを起動する。この新しい処理モジュールは図４を用いてさらに詳しく説明する。ＶＭＮがＣＮ、ＨＡ又はＭＡＰと通信するために適切なルーティング・プロトコルを選択できるよう、図４のフローチャートに示されるような処理のインスタンスが一定の間隔をおいて作成される。

図４において、ＶＭＮの新しい処理モジュールに関連する第１ステップは、ＶＭＮがＣＮ若しくは一つ又は複数のホーム・エージェントとＡＲＯを行いたいか否かを判断するステップ４００である。ＡＲＯを実行するか否かは完全にＶＭＮ次第である。フローにおけるより良いＲＯのために実行してもよい。ＶＭＮが実行すると決定した場合、ステップ４０１がトリガーされる。ステップ４０１では、ＶＭＮがそのＬＣｏＡをＣｏＡとして使用し、ＣＮ若しくは一つ又は複数のホーム・エージェントとＡＲＯバインディングを行う方法が示される。ステップ４００にてＶＭＮがＡＲＯを実行すると決定した場合、ステップ４０２がトリガーされる。このステップでは、ＶＭＮがＭＩＰｖ６方法によりＣＮにてＨｏＡ−ＲＣｏＡバインディング登録を行いたいか否かについてクエリーを行う。ステップ４０２でｙｅｓと判定された場合、ステップ４０３が実行される。ステップ４０３では、ＶＭＮがＲＣｏＡを使ってＭＡＰにてＲＯ登録を行い、ＭＩＰｖ６方法によりＣＮにてＨｏＡ−ＲＣｏＡバインディング登録を行う方法の概要が示されている。ステップ４０３を行うために、処理の制御が前述のＨＭＩＰｖ６スタックに切り替えられる。ステップ４０２でｎｏと判定された場合、処理はステップ４０４へ進む。ステップ４０４では、ＶＭＮが一つ又は複数のＨＡにてＲＣｏＡを用いて登録を行いたいか否か、かつ、ＭＡＰにてＲＯベースのＨＭＩＰｖ６登録を行いたいか否かを判定する。ステップ４０４でｙｅｓと判定された場合、処理モジュール４０６が起動される。このモジュールは、ＶＭＮがＲＣｏＡを用いてＭＡＰにてＨＭＩＰｖ６関連のＲＯ登録を行い、一つ又は複数のＨＡにてＭＩＰｖ６登録を行う機能を持つ。一方、ステップ４０４でｎｏと判定された場合、処理は、ステップ４０５に示すように、モジュールＭＩＰｖ６又はＩＰｖ６モジュールに移行する。

ここで理解すべき重要な点として、制御は、ステップ４０１を実行する時はＡＲＯスタックへ移り、ステップ４０３、４０６を実行する時は、ＭＡＰにてＲＯベースの登録を行うためのサポートコードを有するＨＭＩＰｖ６スタックへ移る。そしてまた、ステップ４０５を実行する時は、制御はＩＰｖ６又はＭＩＰｖ６へと移る。

本発明の別の好適な実施形態では、ＭＲの動作を説明し、図５のフローチャートによりさらに詳しく説明する。本実施形態では、ＲＯ対応ＭＡＰシナリオ及びレガシーＭＡＰシナリオにおけるＭＲの動作を説明する。本実施形態では、図２、図３に示された方法に加えて、レガシーＭＡＰシナリオにおいてＶＭＮ／ＭＲが一つ又は複数のＣＮ若しくはＨＡとＲＯを実行できるよう適切な判断をＭＲが下す本発明の第３の方法の概要を示す。上記第３の方法では、ＭＲは、ＭＡＰがＲＯ機能を持たないレガシータイプのＭＡＰであることを知っている場合、ＲＡ内のＭＡＰオプションを送信しない。

ＭＲのプロトコル・アーキテクチャのレイヤ３は、ＡＲＯルーティング・モジュール、ＨＭＩＰｖ６ルーティング・モジュール、ＮＥＭＯ基本ルーティング・モジュール、ＩＰｖ６ルーティング・モジュール、ＭＩＰｖ６ルーティング・モジュール、新しい処理モジュールから構成される。上記ＨＭＩＰｖ６ルーティング・モジュールは標準のＨＭＩＰｖ６ルーティング・モジュールとは少し異なる。主な違いは、ＭＡＰでのローカルＢＵにＲＯパラメータが付加されていることである。また、ＭＲは、ＲＯ対応ＭＡＰシナリオにおいて、ＲＡ内のＭＡＰオプションを通知する。これは通常のＨＭＩＰｖ６動作では行われない。ＭＡＰでのＲＯ登録は、ＲＯタイプのＭＡＰに沿って行われるものとする。すなわち、ＨＭＩＰｖ６ルーティング・モジュールは、ＭＡＰのＲＯスキームタイプに応じて、ＭＡＰと様々なタイプのＲＯを実行することが可能であるものとする。

次に、図５を参照して、上記新しい処理モジュールに関連する工程を説明する。まず、ステップ５００を実行してＭＡＰがレガシーＭＡＰであるか否かを判断し、レガシーＭＡＰでない場合、ＭＡＰがどんなタイプのＲＯスキーム（ＡＲＯ対応タイプ、プレフィックス・デレゲーションタイプなど）を有するかが判定される。この判断を行うには、受信したＲＡに付加された新しいタイプのＭＡＰオプションを使う方法、受信したＲＡに付加された新しいオプションを使う方法、ＭＲからＭＡＰへのテスト信号を使う方法など、様々な方法がある。例えば、ＭＲは、新しいＭＡＰオプション、又は、ＭＡＰのタイプ（レガシー、ＭＡＰのＲＯタイプ）を通知するＲＡに付加された新しいオプションを受信すると、ＭＡＰのタイプを知り適宜行動する。この方法の利点としては、ＭＲが明示的シグナリングを行う必要がなく、電力を浪費しないで済む。一方、この方法の問題点は、固定ルータがこれらの特別なオプションを把握し、ＲＡで再送しなければならないことである。これにはシステムに大幅な変更を加える必要があり、スケーラビリティに問題が生じる。ＭＲは、外部シグナリングによりＭＡＰタイプをテストする場合、ＭＡＰに対しＡＲＯタイプのＢＵテスト、又はプレフィックス・デレゲーション要求テストを利用する。こうして、双方向の要求・応答シグナリングによって、システムにはさらにシグナリングが投入されることになる。ＭＡＰがシグナリングのタイプを把握した場合のみＭＡＰからの応答が発生するということは容易に理解し得ることである。例えば、ＡＲＯタイプのＢＵがレガシーＭＡＰにて行われた場合、ＭＡＰからは何の応答も送信されない。また、明示的テストシグナリングが行われる第２の方法では、ＭＲの電力は同様に浪費される。さらに、正確なＭＡＰタイプを知るため異なるタイプのテストシグナリングが行われることもあり、それによりシグナリング負荷がさらに増大し、ＭＲの電力がさらに浪費されることとなる。この第２の方法の利点は、固定ルータに変更を加える必要がないということである。ＡＲＯタイプのＢＵテストが行われると、ＡＲＯオプションが受信されなかった場合、ＡＲＯオプションにはＭＲの気付アドレスが含まれる。そのようなアドレスが使われるのは、ＭＲが最上位移動ルータになった場合、ＡＲＯオプションが受信されないからである。ここで理解すべき重要な点は、ＭＡＰがレガシーＭＡＰであるか否かを把握することに加えて、ＭＲがＭＡＰにてＲＯに関連するローカル登録を適切に行うことができるよう、ＭＡＰが使用しているＲＯスキームのタイプを知ることも重要である。

ステップ５００でｙｅｓと判定された場合、前述したような従来技術の問題を解消するためステップ５０１が実行される。このステップでは、ＭＲは、ＭＡＰがレガシーＭＡＰであることを知っているため、ＲＡにおけるＭＡＰオプションの通知を停止することを決定する。ＭＲがレガシーＭＡＰシナリオにてそのような決断を下すのは、ＭＡＰにはＲＯトレース機構が組み込まれておらず、ネスト状態のＮＥＭＯのＡＲＯ及びＨＭＩＰｖ６シナリオに対するサービスを提供するのに全く役に立たないためである。そのため、ＭＮ（ＶＭＮ／ＭＲ）がネストされている限りＭＡＰはＲＯに利用することができない。ステップ５０１が完了すると、制御はステップ５０２へ移動できる、若しくは、ＭＲはステップ５０２乃至５１２を行わずに、標準のＡＲＯ及びＨＭＩＰｖ６動作を行うことができる。図５にはステップ５０１の後のステップが明示されていないのはこのためである。これについては、以下の他の実施形態にてさらに詳しく説明する。

ステップ５００でｎｏと判定された場合、ステップ５０２が実行される。このステップでは、ＭＲに直接接続されたＶＭＮ／ＭＲがＡＲＯを使って自身のＣＮと通信しているか否かが判定される判定処理が行われる。ステップ５０２でｙｅｓと判定された場合、ＭＲで処理されたオプションのタイプに関係なく、ステップ５０３が実行される。ステップ５０３では、ＭＲがＬＣｏＡを使って、それに直接接続されたＶＭＮ／ＭＲのＣＮとＡＲＯを確立する。ステップ５０２でｎｏと判定された場合、ステップ５０４で示されるようなテストをさらに実施する。これにより、ＭＲが一つ又は複数のＨＡ若しくはＣＮとＡＲＯを行いたいか否かが判定される。ステップ５０４でｙｅｓと判定された場合、再度ステップ５０３が実行される。ステップ５０４でｎｏと判定された場合、ステップ５０５が実行される。このステップでは、このＭＲに直接接続されたＶＭＮ／ＭＲがＭＡＰと通信しているか否かが判定される。ステップ５０５でｙｅｓと判定された場合、ステップ５０６が実行される。ここではＭＲがＭＡＰオプションを処理したか否かが判定される。ステップ５０６でｎｏと判定された場合、ステップ５０７が実行される。ステップ５０７では、ＭＡＰオプションが処理され、ＭＲがＭＡＰにて適切なＲＯベースの登録を行う。ステップ５０６でｙｅｓと判定された場合は何も行われない。ステップ５０５でｎｏと判定された場合、ステップ５０８が実行される。ここでは、ＭＲが、ＭＮとして、ＭＩＰｖ６方法により自身のＣＮにてＨｏＡ−ＲＣｏＡバインディング登録を行いたいか否かがテストされる。ステップ５０８でｙｅｓと判定された場合、ステップ５１０が実行される。ステップ５１０では、ＭＡＰオプションが処理されたか否かが判定される。ステップ５１０でｎｏと判定された場合、ステップ５１１が実行される。ステップ５１１は、ＭＲがＭＡＰオプションを処理し、ＭＡＰにて適切なＲＯ登録を行い、ＭＩＰｖ６方法により一つ又は複数のＣＮにてＨｏＡ−ＲＣｏＡバインディング登録を行う手順に関する。ステップ５１０でｙｅｓと判定された場合、ステップ５１２が実行される。ステップ５１２では、ＭＲがＭＩＰｖ６方法により一つ又は複数のＣＮにてＨｏＡ−ＲＣｏＡバインディング登録を適切に確立する。ステップ５０８でｎｏと判定された場合、ステップ５０９が実行され、標準ＮＥＭＯ基本、ＭＩＰｖ６又はＩＰｖ６動作が行われる。

本発明のさらに別の好適な実施形態では、ＶＭＮ／ＭＲがＡＲＯオプション、ＭＡＰオプション、若しくはＡＲＯオプションとＭＡＰオプションの両方を処理できるＲＯ対応ＭＡＰシナリオにおける主要な発明の効果を十分に理解するため、ＶＭＮとＣＮとの間で確定される最終的なデータパスを説明する。上記解決法の効果は、図６に示すネットワーク図により説明する。

図６では、ＶＭＮ６１０がＭＲ６２０に接続され、ＭＲ６２０がＭＲ６２１に接続され、ＭＲ６２１がＡＲ６３０に接続され、ＡＲ６３０がＭＡＰ６４０に接続され、ＭＡＰ６４０がグローバル通信ネットワーク６００に接続されている。ＶＭＮ６１０は、ＣＮ６５０とＣＮ６５１の２つのＣＮと同時に通信しているものとする。図６では、ＭＡＰ６４０でのバインディング・キャッシュはＢＣ６６２で示され、ＣＮ６５０でのバインディング・キャッシュはＢＣ６６０で示され、ＣＮ６５１でのバインディング・キャッシュはＢＣ６６１で示される。さらに、ＶＭＮ６１０は、ＣＮ６５０とＡＲＯタイプのＲＯを行うことを決定し、ＭＩＰｖ６方法によりＣＮ６５１にてＨｏＡ−ＲＣｏＡバインディング登録を行うことを決定するものとする。本発明に係る方法を採用することにより、ＶＭＮ６１０が処理するオプションに関係なく、ＣＮ６５０とＡＲＯを行うことが決定したなら、ＬＣｏＡを用いてＡＲＯを確立する。また、ＭＲ６２０とＭＲ６２１もまた、ＬＣｏＡを使ってＣＮ６５０とのＡＲＯを確立する。そのため、図６からも分かるように、ＢＣ６６０には、ＶＭＮ６１０に最適に到達するのに必要なすべてのＬＣｏＡが含まれる。また、この解決法によれば、従来技術に記載されていたようなバインディング・キャッシュに関連する異種アドレス問題が解消される。ＶＭＮ６１０がＣＮ６５０とＡＲＯを実行する場合の最適ルートパスを図６の６７０に示す。パスはトンネリングを伴わずに完全に最適化されていることが分かる。

ＶＭＮ６１０がＲＣｏＡを用いてＣＮ６５１と所在管理ベースのＲＯを確立することを決定した場合、ＶＭＮ６１０はＲＣｏＡを用いてＭＡＰ６４０にて適切にＲＯベースのローカルＢＵ登録を行い、ＭＩＰｖ６方法によりＣＮ６５１にてＨｏＡ−ＲＣｏＡベースのバインディング登録を行う。ＭＩＰｖ６方法によるＣＮ６５１でのＨｏＡ−ＲＣｏＡバインディング登録をＢＣ６６１で示す。ＢＣ６６２の第３行には、ＶＭＮ６１０により作成されたエントリが表示される。ここでも同様に、本発明の方法を採用することにより、ＭＲ６２１とＭＲ６２０は、処理したオプションに関係なく、ＭＡＰ６４０にて適切なＲＯ登録を行う。ＢＣ６６２にはＶＭＮ６１０のＲＣｏＡを正確にトレースするのに必要なすべてのパラメータが含まれることは当業者であれば理解し得ることである。従って、ＶＭＮ６１０とＣＮ６５１は所在管理効率ベースのＲＯを互いに実行できる。このメッセージを６７１に示す。ＶＭＮ６１０からＣＮ６５１へのデータ・パケットは、ＶＭＮ６１０とＭＡＰ６４０間のトンネルにカプセル化される。移動ルータＭＲ６２０、ＭＲ６２１は、パケットが逆方向に送信された場合にパケットを、パス６７１を介してルーティングする際、単に送信元アドレスをＬＣｏＡに変更する。順方向では、ＣＮ６５１からのパケットはＭＡＰ６４０に受信され、トンネルにカプセル化される。ＭＡＰ６４０はＶＭＮ６１０のＲＣｏＡに到達するためのエントリを検索する。ＢＣ６６２には、ＶＭＮ６１０のＲＣｏＡに到達するためのすべてのエントリが含まれていることが分かる。ＭＡＰ６４０でのＲＯメカニズムはどんなタイプのもの（ＡＲＯ、ＰＳＢＵを伴うプレフィックス・デレゲーション、検証を伴うＰＳＢＵなど）であってもよい。

図６に示す解決法の効果から、ＶＭＮ６１０はそのフローやアプリケーションで使用したいＲＯスキームのタイプを選択し、選択したＲＯスキームに対して適当なＣｏＡを選択することが可能であることがはっきりと見て取れる。ＶＭＮ６１０は、ＣＮ６５０とＡＲＯを行う際、ＭＩＰｖ６方法によりＨＡにてＨｏＡ−ＲＣｏＡバインディング登録を行うことができるということを理解することも重要である。さらに、ＶＭＮ６１０は、ＭＩＰｖ６方法によりＣＮ６５１にてＨｏＡ−ＲＣｏＡバインディング登録を行う際、ＨＡとＡＲＯタイプの登録を行ってもよい。

本発明のさらに別の好適な実施形態では、レガシーＭＡＰシナリオにおける主要な発明の効果を十分に理解するため、ＶＭＮとＣＮとの間で確定される最終的なデータパスを説明する。上記解決法の効果は、図７に示すネットワーク図により説明する。

図７では、ＶＭＮ７１０がＭＲ７２０に接続され、ＭＲ７２０がＭＲ７２１に接続され、ＭＲ７２１がＡＲ７３０に接続され、ＡＲ７３０がＭＡＰ７４０に接続され、ＭＡＰ７４０がグローバル通信ネットワーク７００に接続されている。ＶＭＮ７１０は２つのＣＮと同時に通信しているものとする。上述の通信相手ノードは、ＣＮ７５０、ＣＮ７５１である。さらに、図７では、ＭＡＰ７４０、ＣＮ７５０、ＣＮ７５１でのバインディング・キャッシュは、それぞれ、ＢＣ７６２、ＢＣ７６０、ＢＣ７６１で示される。

このシステムでは、ＭＲ７２１は、ＭＡＰ７４０がＨＭＩＰｖ６レガシータイプのＭＡＰであることを確認し、ＲＡのＭＡＰオプションを通知しないものとする。そのため、ＶＭＮ７１０とＭＲ７２０はＡＲＯオプションのみを有し、それらのネットワーク内にＭＡＰが存在することに気付かない。このような環境下では、ＶＭＮ７１０はＣＮとの通信の際ＡＲＯオプションのみを処理する。

まず、ＶＭＮ７１０とＣＮ７５０間のデータ通信を詳しく見てみる。ＶＭＮ７１０はＣＮ７５０とＡＲＯを行う。同様に、ＭＲ７２０は、ＣＮ７５０から適当なＡＣＫを取得した場合、若しくは、ＮＥＭＯ−ＦＷＤオプションを見つけた場合、ＣＮ７５０とＡＲＯを行う。ＭＲ７２０は処理するオプションとしてＡＲＯオプションしか有していないので、前述の実施形態で概説され図５にて説明された新しい処理部は実行されない。ＭＲ７２１は、ＣＮ７５０とＡＲＯを確立する場合、単にＲＣｏＡを用いてＡＲＯを確立できる。ＭＲは、ＲＡのＭＡＰオプションの送信を停止する場合、標準メカニズムを使用できる。若しくは、図５に概説した新しい処理部を使用する決定をできることが前述の実施形態にも説明されている。この事例に限って言えば、ＭＲ７２１は図５に概説した新しい処理部を実行しないが、その代わり、標準のＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを利用するものとする。これはパス７７０に示される。ＢＣ７６０のエントリは、ＣＮ７５０のエントリである。ＭＲ７２１のＲＣｏＡ、ＭＲ７２０のＬＣｏＡ、ＶＭＮ７１０のＬＣｏＡに到達することで、ＶＭＮ７１０のＨｏＡに到達できる。ＣＮ７５０がＶＭＮ７１０へデータ・パケットを送信する場合、宛先アドレスがＭＲ７２１のＲＣｏＡに設定され、ＲＨにはＭＲ７２０のＬＣｏＡ、ＶＭＮ７１０のＬＣｏＡ、ＶＭＮ７１０のＨｏＡが含まれる。そのようなパケットがＣＮ７５０にて作成された場合、データパスは７７０に示すようになる。ＭＡＰ７４０とＭＲ７２１との間には、一つのトンネルが存在する。パス７７０は、一つのトンネルを有する最適ルートパスである。このパスの利点としては、ＲＣｏＡがＣＮ７５０に与えられたものでありＬＣｏＡほど頻繁には変更されないことから、ＭＲ７２１からのＡＲＯタイプの再帰的シグナリングが軽減されるということである。

次に、ＶＭＮ７１０とＣＮ７５１間のデータ通信パス７７１を詳しく見てみる。ここでも同様に、ＶＭＮ７１０とＭＲ７２０は処理するオプションとしてＡＲＯオプションしか有していないことが分かる。ＶＭＮ７１０がＣＮ７５１とのＡＲＯバインディングを開始する場合、ＶＭＮ７１０とＭＲ７２１間の登録は純粋なＡＲＯタイプである。このような場合、ＭＲ７２１は、図５に示す新しい処理モジュール、又は通常のメカニズムを利用できる。データパス７７１では、ＭＲ７２１は、ＣＮ７５１とＡＲＯを行う際、新しい処理アルゴリズムとＬＣｏＡとを使用するものとする。その結果、ＣＮ７５１でのバインディング・キャッシュが、すべてのＬＣｏＡエントリを表示するＢＣ７６１に示される。ＢＣ７６１から、ＶＭＮ７１０とＣＮ７５１が互いに通信する際に完全なＡＲＯ効果が得られることが分かる。パス７７１にはトンネリングが生じない。その点では、パス７７１はパス７７０よりも大きな利点を有する。しかしながら、この場合、ＡＲＯシグナリングが若干高くなる。これは、すべてのＬＣｏＡ登録がＢＣ７６１に存在し、高いモビリティ環境下では、ＬＣｏＡは頻繁に変更され、一定期間内でＣＮ７５１にてより多くのＡＲＯ登録が行われるからである。

以上、本発明を最も実用的で好適と思われる実施形態で説明したが、当業者であれば、本発明の要旨及び範囲から逸脱することなく、設計の詳細及びパラメータに種々の変更がなし得ることを理解できるであろう。例えば、本発明は、ネスト状態の移動ネットワークにおいて使用される経路最適化メカニズムとしてＡＲＯスキームを採用している。本発明は、何らかの方法で移動ルータのアドレスを利用して経路最適化を達成するものなど、他の経路最適化メカニズムにも適用可能であることは当業者により理解されるであろう。また、本発明は、ローカル・モビリティ管理プロトコルとして、ＨＭＩＰｖ６を採用している。本発明は、その他のローカル・モビリティ管理プロトコルにも適用可能であることは当業者により理解されるであろう。

本発明は、ＡＲＯやＨＭＩＰｖ６が混在する環境下でも有用な機構を提供できるという利点を有し、パケット交換通信の分野に適用可能である。

Claims (31)

1. ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムであって、
   ＶＭＮ及びＭＲは、ＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、
   ドメイン・アーキテクチャ内に一つのＭＡＰが存在し、そのＭＡＰにはＲＯ機能が実装され、ＨＡにはＡＲＯプロトコルが実装され、
   任意の第１ノードは、該任意の第１ノードが処理したオプションに関係なく、任意の第２ノードとＡＲＯを実行したい場合、そのＬＣｏＡを気付アドレスとして使用するシステム。
2. 前記任意の第１ノードはＶＭＮであり、そのＬＣｏＡをＣｏＡとして用いてそのＣＮの内の一つ又は複数とＡＲＯを行う請求項１に記載のシステム。
3. 任意の第１ノードはＭＲであり、そのＬＣｏＡを気付アドレスとして用いてＶＭＮのＣＮ若しくは他のＭＲのＣＮとＡＲＯを行う請求項１に記載のシステム。
4. 任意の第１ノードはＶＭＮであり、そのＬＣｏＡをＣｏＡとして用いてその一つ又は複数のＨＡとＡＲＯを行う請求項１に記載のシステム。
5. 任意の第１ノードはＭＲであり、そのＬＣｏＡをＣｏＡとして用いてその一つ又は複数のＨＡとＡＲＯを行う請求項１に記載のシステム。
6. 任意のノードはＭＲであり、そのＬＣｏＡをＣｏＡとして用いてその一つ又は複数のＣＮとＡＲＯを行う請求項１に記載のシステム。
7. ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムであって、
   ＶＭＮ及びＭＲは、ＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、
   ドメイン・アーキテクチャ内に一つのＭＡＰが存在し、そのＭＡＰにはＲＯ機能が実装され、ＨＡにはＡＲＯプロトコルが実装され、
   任意の第１ノードは、前記任意の第１ノードが処理中のオプションに関係なく、任意の第２ノードとＨＭＩＰｖ６を実行したい場合、そのＲＣｏＡを気付アドレスとして使用するシステム。
8. 前記任意の第１ノードはＶＭＮであり、そのＲＣｏＡを用いてそのＣＮの内の一つ又は複数とＨＭＩＰｖ６を行う請求項７に記載のシステム。
9. 前記任意の第１ノードはＶＭＮであり、そのＲＣｏＡを用いてその一つ又は複数のＨＡとＨＭＩＰｖ６を行う請求項７に記載のシステム。
10. 前記任意の第１ノードはＭＲであり、そのＲＣｏＡを用いてそのＣＮの内の一つ又は複数とＨＭＩＰｖ６を行う請求項７に記載のシステム。
11. 前記任意の第１ノードはＭＲであり、そのＲＣｏＡを用いてその一つ又は複数のＨＡとＨＭＩＰｖ６を行う請求項７に記載のシステム。
12. 前記任意の第１ノードはＶＭＮであり、そのＲＣｏＡをローカルホームアドレスとして、及び、そのＬＣｏＡを気付アドレスとして使用して、ＭＡＰにてＲＯベースのローカル登録を行う請求項７に記載のシステム。
13. 前記任意の第１ノードはＭＲであり、そのＲＣｏＡをローカルホームアドレスとして、及び、そのＬＣｏＡを気付アドレスとして使用して、ＭＡＰにてＲＯベースのローカル登録を行う請求項７に記載のシステム。
14. ＭＲがＭＡＰオプションを処理しておらず、それに直接接続されたＶＭＮ又はＭＲがＭＡＰにてもうすでにＲＯベースのローカル登録を行っている場合、ＭＲは前記ＭＡＰオプションを処理してＲＣｏＡを取得し、前記ＭＡＰにてＲＯベースのローカル登録を行う請求項７に記載のシステムにおいて採用される方法。
15. 前記ＲＣｏＡに到達するのに必要なＬＣｏＡが最適な方法で取得できるよう、ＭＡＰにてＲＯパラメータを用いてそのＲＣｏＡをホーム・アドレスとして登録する請求項１４に記載の方法。
16. ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムであって、
    ＶＭＮ及びＭＲは、ＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、
    ドメイン・アーキテクチャ内に一つのＭＡＰが存在し、このＭＡＰがレガシーＨＭＩＰｖ６タイプのものであり、ＨＡにはＡＲＯプロトコルが実装され、
    ＭＲは、ＭＡＰがレガシータイプであると知っている場合、そのＲＡ内のＭＡＰオプションを送信しないと決定するシステム。
17. ＭＲがＭＡＰタイプの識別にＲＡに付加された新しいＭＡＰオプションを利用する請求項１６に記載のシステム。
18. ＭＡＰのタイプに関する情報は、ＭＡＰに関連するＲＯスキームのタイプに関する情報、又は、レガシーＭＡＰに関する情報である請求項１７に記載のシステム。
19. ＭＲがＭＡＰタイプの識別に、ＲＡに付加された新しいオプションを利用する請求項１６に記載のシステム。
20. ＭＡＰのタイプに関する情報は、ＭＡＰに関連するＲＯスキームのタイプに関する情報、又は、レガシーＭＡＰに関する情報である請求項１９に記載のシステム。
21. ＭＲがＭＡＰタイプの識別に、明示的シグナリングを利用する請求項１６に記載のシステム。
22. 前記明示的シグナリングは、ＡＲＯオプション内のアドレスはＭＲのローカル気付アドレスであるＭＡＰにて行われるＡＲＯタイプのＢＵである請求項２１に記載のシステム。
23. 前記明示的シグナリングは、プレフィックス・デレゲーション要求タイプのメッセージである請求項２１に記載のシステム。
24. ＭＡＰオプションを送信しないと決定したＭＲは、そのＬＣｏＡを用いて、それに直接接続されているＶＭＮの若しくはＭＲのＨＡ又はＣＮとＡＲＯを実行する請求項１６に記載のシステム。
25. ＭＡＰオプションを送信しないと決定したＭＲは、そのＲＣｏＡを用いて、それに直接接続されているＶＭＮの若しくはＭＲのＨＡ又はＣＮとＡＲＯを実行する請求項１６に記載のシステム。
26. 請求項１に記載のシステムにおけるＶＭＮと関連する装置。
27. 請求項７に記載のシステムにおけるＶＭＮと関連する装置。
28. 請求項１６に記載のシステムにおけるＶＭＮと関連する装置。
29. 請求項１に記載のシステムにおけるＭＲと関連する装置。
30. 請求項７に記載のシステムにおけるＭＲと関連する装置。
31. 請求項１６に記載のシステムにおけるＭＲと関連する装置。

Images