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

Abstract

【解決手段】 ネスト状態の移動ネットワーク内の移動ホスト又は移動ルータが複数のモビリティ・アンカー・ポイントを含むドメイン内でローミングしている際に、ネスト状態の移動ネットワーク・ツリーパス内の移動ホスト又は移動ルータが、そのリージョナル気付アドレスを得るために異なるモビリティ・アンカー・ポイントを選択する場合、ルーティングの準最適性が発生する。このようなルーティングの準最適性を克服するため、本発明は２つの主要な方法を提示する。第１の方法では、そのツリーパス内の下流ノードが別のモビリティ・アンカー・ポイントからリージョナル気付アドレスを得たことを移動ルータが検出し、その他のモビリティ・アンカー・ポイントで適切なオンデマンド二重登録を行う。第２の方法では、移動ルータが他のモビリティ・アンカー・ポイント・アドレスを自身のモビリティ・アンカー・ポイントに知らせ、それにより、移動ルータのモビリティ・アンカー・ポイントは移動ルータの位置エントリを他のモビリティ・アンカー・ポイントへ転送する。

Description

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

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

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

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

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

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

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

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

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

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

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

今後、ＡＲＯプロトコルと、あるＨＭＩＰｖ６に関係のあるプロトコル（純粋なＨＭＩＰｖ６又はＲＯを備えたＨＭＩＰｖ６）の両方がＭＮ、ＭＲに実装されることも有り得る。さらに、そのような異種のプロトコルを実装するノードは、複数のモビリティ・アンカー・ポイント又はローカル・モビリティ管理アンカー（ＬＭＡ）を有するローカル・モビリティ管理ドメイン内でローミングする可能性がある。上記ＬＭＡは、ネットワーク・ベースのローカル・モビリティ管理（ＮｅｔＬＭＭ）ＩＥＴＦワーキング・グループにおける明確な用語であり、ＭＩＰｖ６のホーム・エージェント機能又はＨＭＩＰｖ６のＭＡＰ機能を有し得る。ＬＭＡの詳細については、非特許文献６に記載されている。上記の通り異種のプロトコルが実装されたネスト状態のＮＥＭＯが、ＮｅｔＬＭＭドメイン内でローミングしている場合、ネスト状態のＮＥＭＯ内のＭＮ、ＭＲのいずれも、アーキテクチャ内の利用可能なローカル・モビリティ管理機能を知ることはなく、ネスト状態のＮＥＭＯ内のすべてのＭＮ、ＭＲは、ＨＭＩＰｖ６関連のスタックをトリガーすることはなく、ＣＮとの通信にＡＲＯメカニズムのみを使用する。ＮｅｔＬＭＭドメインではなく、ＭＡＰが得られるドメインでは、前述の異種プロトコルを有する、ネスト状態のＮＥＭＯのＭＮ及びＭＲが、フローのＱｏＳニーズ、ＭＮ／ＭＲの電力状態、ネットワークのトラフィック状態に応じて、ＡＲＯ及び／又はＨＭＩＰｖ６関連のスタックをトリガーする。ネットワークのトラフィック状態は、ネットワーク帯域幅の利用状態又はネットワーク輻輳状態を示している。

複数のＭＡＰを有する上記ローカル・モビリティ管理ドメインでは、さらに、これらすべてのＭＡＰが、ローミングするＭＮ及びＭＲと同じＨＭＩＰｖ６機能を有するとされている。これは、つまり、ドメイン内のＭＡＰはすべて、同一のＨＭＩＰｖ６のＲＯ機能を有することを意味している。上記ＨＭＩＰｖ６のＲＯ機能としては、ＡＲＯ対応のＨＭＩＰｖ６機能、特許文献３に簡潔に記載されたプレフィックス・デレゲーション・ベースのＨＭＩＰｖ６機能、又は、非特許文献５に開示されたようなＰＳＢＵベースのＨＭＩＰｖ６機能が用いられる。

上記ＡＲＯ対応のＨＭＩＰｖ６機能は、ＭＡＰが、そのホーム・アドレスがＭＡＰオプションとして付与され、ＭＮ及びＭＲがこのアドレスのプレフィックスからＲＣｏＡを導き出し、ＭＡＰにてローカル登録を行うことができる、純粋なＨＭＩＰｖ６のＭＡＰと同様のものである。また、このＡＲＯ対応のＨＭＩＰｖ６のＭＡＰは、ローカル・バインディング・アップデート内のＡＲＯオプションとして送信されたアドレスもサポートし、非特許文献４に概要が示された同様のＡＲＯベースのトレースを実行する。ＡＲＯオプションのＭＡＰに送信されたパラメータとしては、移動アクセス・ルータのホーム・アドレス又は移動アクセス・ルータのリージョナル気付アドレスを使うことができる。ＡＲＯ対応のＨＭＩＰｖ６のＭＡＰでのトレースは、ＭＮ又はＭＲに関連するＲＣｏＡのためのものである。最適にこのＲＣｏＡへ到達するのに必要なすべてのＬＣｏＡは、ＭＡＰにて登録された一つ又は複数のＡＲＯパラメータによりトレースされる。これについては、本明細書の他のセクションにてさらに詳しく説明する。

上記プレフィックス・デレゲーション・ベースのＨＭＩＰｖ６機能とは、ＭＡＰがＲＯに対応しており、要求に応じてプレフィックスをＭＲに委譲し、ＭＲは、プレフィックス・オプションのこの委譲されたプレフィックスを用いてＭＡＰによりローカルＰＳＢＵを行う。ＭＲに接続されたＭＮ及びＭＲは、このＭＡＰから委譲されたプレフィックスを用いてそのＬＣｏＡを得るものとする。ＭＡＰは上記ローカルＰＳＢＵをそのまま受け入れる。このプレフィックスがＭＡＰ自身によって与えられたものであるため、ＭＡＰは、ＲＣｏＡ、ＬＣｏＡ、プレフィックス間の配置テストを行う必要がない。ＣＮからのパケットがＭＡＰに届くと、ＭＡＰは初めにＲＣｏＡエントリを探し、対応するＬＣｏＡを見つける。その後、ＬＣｏＡのプレフィックスと一致するものをプレフィックス欄で探す。プレフィックス・エントリが見つかると、トレース機構が上記の見つけられたプレフィックスに関連するＬＣｏＡエントリを探し、一致するプレフィックスが見つからなくなるまでそのような検索を続ける。このほかのやり方では、ある特定のＭＮ／ＭＲの上流のＭＲに対応付けられているＬＣｏＡがすべて見つかると、トレースが終了するものとする。

上記ＰＳＢＵベースのＨＭＩＰｖ６のＭＡＰ機能とは、上記プレフィックスがそのホーム・ネットワークからＭＲに与えられるＭＡＰにて、ＭＲがＰＳＢＵを行うものである。この場合、ＭＡＰは、上記ローカルＰＳＢＵを受け取る前に、ＲＣｏＡ、ＬＣｏＡ、プレフィックスの配置テストを行わなければならない。これについては、非特許文献５の説明の際に、本明細書内ですでに詳細に説明されている。

さらに、前述の異種プロトコルを有するネスト状態のＮＥＭＯノードが、アーキテクチャに複数のＭＡＰが存在するドメイン内でローミングしているものとする。複数のＭＡＰがドメインに実装されるのは、通常、ロードバランシングのためである。例えば、ドメイン内にＭＡＰが一つであり、それがネットワーク・アーキテクチャのかなり上方でネットワークの大部分をカバーした状態で配置されている場合、ローカル・モビリティ管理ドメインは大きなものとなり、多数のＭＮ及びＭＲが、ローカル・モビリティ管理サービスのためにこのＭＡＰの使用を要求することになる。これにより、ＭＡＰの負荷が増大する。ＭＡＰは、通常、ＭＮ及びＭＲがホーム・リンク・プレフィックスから得るＲＣｏＡ値に対して、近隣探索（ＮＤ）プロキシ・シグナリングを行う。多数のＭＮ及びＭＲに対してこのＮＤプロキシ・シグナリングが行われると、ＭＡＰからかなりの量の電力が流出することとなり、ＭＡＰにかかる処理負荷が増大する。さらに、ＭＡＰで登録された多くのＲＣｏＡ値にやって来る大量のパケットのトンネリングを、たった一つのＭＡＰで行わなければならず、その結果、ＭＡＰにかかる処理負荷がさらに増大する。また、ローカル・モビリティ管理ドメインに多くのノードが存在し、アーキテクチャにはＭＡＰが一つしかない場合、この一つのＭＡＰでのＢＣＥは消耗的で、ＭＡＰはそのＢＣＥのためにそのメモリのかなり大きな部分を使用するので、ＭＡＰのリソースが浪費されてしまう。上記一つのＭＡＰには、送信トラフィックのための大量のデトンネリング処理も行われ、これによってもＭＡＰの処理負荷はさらに増大する。このような単一ＭＡＰアーキテクチャは、多数のＭＮ及びＭＲを収容しなければならないローカル・モビリティ管理ドメインにとって好ましいものではないということが、単一ＭＡＰに関連するこれらすべての不具合により示唆されている。単一のＭＡＰを使用すると、多数のノードがＭＡＰ機能を利用した場合にＭＡＰの不具合を生じる可能性が高い。このため、ロードバランシングのためには、ローカル・モビリティ・ドメインに複数のＭＡＰ、ＮｅｔＬＭＭドメインに複数のＬＭＡ、又はプロキシ・モバイルＩＰ（ＰＭＩＰ）ドメインに複数のプロキシ・ホーム・エージェントが必要であることは明らかである。ＰＭＩＰ及びプロキシ・ホーム・エージェントについては、非特許文献７にさらに詳細に説明されているので、本明細書では簡潔に後述する。

前述したアーキテクチャの単一ＭＡＰに関連するすべての問題を解決するためには、非特許文献２にも概説されているように、複数のＭＡＰを配備するのがごく一般的である。非特許文献２では、これらのＭＡＰをドメイン内に階層的に配置し得ることが概説されている。ドメイン内のＭＡＰ配置の階層とは、一つ又は複数のルートＭＡＰが存在し、ドメインにはモザイク式にＭＡＰの階層がｎ層（ｎ＞１）存在し得るということを意味している。その他の階層式の配置としては、ドメイン内のすべてのＭＡＰをたった一つの層に配置することも可能である。複数ＭＡＰアーキテクチャの配置方法には、基準となる方法又は必須の方法というものはない。

ＭＡＰの階層的配置では、ＭＮ及びＭＲは、それらのデフォルト・ルーティング経路上のＭＡＰに関連するＭＡＰオプションを受信する。場合によっては、複数のデフォルト・ルーティング経路が存在することもあり、その場合ＭＮ及びＭＲが多くのＭＡＰオプションを利用可能となる。ＭＮ及びＭＲが高速で移動している場合、グローバル登録を頻繁に行わなくていいように、より遠いＭＡＰを選んでもよいが、その場合、遠く離れたＭＡＰから終端のＭＮ／ＭＲまでのトンネルが長く、そのため、さらなるデータ・パケット遅延が生じる。一方、低速で移動するＭＮ及びＭＲについては、下層のＭＡＰを選ぶことができる。下層ＭＡＰの利点としては、トンネルの長さが短いことにある。さらに、下層ＭＡＰが、低速で移動するＭＮ及びＭＲに適している理由としては、ＲＣｏＡ率の変化がそれほど高くなく、よってグローバル登録の頻度が所望の制限内であるということがある。非特許文献２では、ＭＡＰ間のロードバランシング機構として、基準となるものはない。一つの方法としては、ＭＡＰが、非常に過負荷な状態であると認識した場合、そのＭＡＰオプションの優先値を「ゼロ」に設定する。この場合、ＭＮ／ＭＲは、そのＭＡＰを絶対に使用してはいけない。しかしながら、他のあらゆる場合においては、ＭＮ／ＭＲが利用可能ないくつかのＭＡＰから、任意のＭＡＰを選択可能である。非特許文献２の先行技術によって、ローミングしているＭＮ／ＭＲのみ、複数ＭＡＰの利用の可能性が公開されており、複数ＭＡＰシナリオにおいてローミングしているネスト状態のＮＥＭＯに対してなされた分析や研究は存在しない。次に、そのような分析がなされ、経路最適化の問題点が特定された図１について検証する。

図１では、ＶＭＮ１０がＭＲ２０に直接接続され、これらのノードはいずれも、ＭＡＰ３０とＭＡＰ３１の２つのＭＡＰを有するローカル・モビリティ管理ドメイン１０１内でローミングしている。ローカル・モビリティ管理ドメインは、インターネット１００に接続されている。図１では、さらに、ＶＭＮ１０がＣＮ５０とデータ通信セッション中であるものとする。ＶＭＮ１０、ＭＲ２０のホーム・エージェントは、それぞれＨＡ４０、ＨＡ４１である。また、ＭＡＰ３０とＭＡＰ３１は、前述のＡＲＯ対応のＨＭＩＰｖ６機能を有し、ＶＭＮ１０とＭＲ２０は、ＡＲＯ及び純粋なＨＭＩＰｖ６プロトコルを実装する。固定アクセス・ルータ（ＡＲ）に加えて、ＭＲも、受信した全ＭＡＰオプションのリレーを行うものとする。このシナリオでは、ＭＲ２０は、受信したＲＡのＭＡＰオプション内のＭＡＰ３０のアドレスとＭＡＰ３１のアドレスを受信し、自身のＲＡ内の両ＭＡＰオプションをさらにリレーするものとする。ＶＭＮ１０は、ＡＲＯオプションと上記両ＭＡＰオプションとを受信する。ＭＲ２０は上記両ＭＡＰオプションのみを受信する。ＶＭＮ１０は、そのＲＣｏＡを得るのにＭＡＰ３１のオプションのみを選択し、ＡＲＯオプションの処理も行うものとする。ＶＭＮ１０がＣＮ５０と通信するために同じＭＡＰドメインから２つのＲＣｏＡを取得しなければならない理由など一切ないことが当業者には理解可能であろう。さらに、ＭＲ２０は、ＭＡＰオプションの処理を行うだけであり（ＭＡＰオプションを受信するだけなので）、ＭＡＰ３０のオプションを利用してＲＣｏＡ値を得る。ＶＭＮ１０及びＭＲ２０は、ＭＡＰオプションに与えられる優先値が「ゼロ」よりも高い限り、ローカル・モビリティ管理ドメイン内のどのＭＡＰを使ってもよいことを理解することが重要である。トラフィック要求がドメイン内に一様に分布している非階層的ＭＡＰアーキテクチャでは、ＭＡＰ３０及びＭＡＰ３１から受信したＭＡＰオプションは、それらの使用量が同じ量であるため、同様の優先値を有する可能性が非常に高い。一方、階層的アーキテクチャでは、ＭＡＰ３０又はＭＡＰ３１のどちらかが階層の上方に存在する場合、アーキテクチャ内で上位にあるＭＡＰの方が低い優先値をとる可能性が高い。なぜなら、そのＭＡＰの方がわずかに他方よりも過負荷状態にある、若しくは、その使用頻度が他方よりもわずかに高いからである。しかしながら、ＶＭＮ１０及びＭＲ２０によるＭＡＰ選択は全くの任意であり、それらは、利用したいＭＡＰをどれでも選ぶことができる。

ＭＲ２０は、ＭＡＰ３０のオプションを処理すると、ＭＡＰ３０のアドレス・プレフィックスによりＲＣｏＡ値を取得し、ＭＡＰ３０にてローカル登録を行う。上記登録値は、図１にＢＣＥ６１によって示される。この登録に続いて、ＶＭＮ１０は、その対応するＭＡＰ、すなわち、ＭＡＰ３１にてローカル登録を行う。ＶＭＮ１０は、ＡＲＯとＭＡＰ３１の両オプションを処理したので、ＡＲＯオプションを添付することでそのＭＡＰ３１にてローカル登録を行う。このＡＲＯオプションは、その中にＭＲ２０のグローバル・ホーム・アドレスを有することが好ましい。上記ＭＡＰ３１での登録により、ＢＣＥ６２の第１行目のエントリが作成される。ＭＡＰ３１は、確認応答（ＡＣＫ）を上記ローカル登録に送信する場合、このＡＣＫをＭＲ２０のホーム・アドレスを介してＶＭＮ１０へソース・ルーティングする。このＡＣＫパケットは、ＶＭＮ１０のＬＣｏＡへとさらにルーティングされる前に、まず、ＭＲ２０に到達する。ＭＲ２０は、このＡＣＫを受信後、ＭＡＰ３１にてＡＲＯ登録を行う。この登録は、非特許文献４に概説されているような通常のＲＲ及びＭＩＰｖ６登録であるが、ＭＲ２０のＲＣｏＡを気付アドレスとして使用している。上記ＡＲＯ登録値は、ＢＣＥ６２の第２行目のエントリによって示されている。ＭＲ２０は、そのＨＭＩＰｖ６スタックがトリガーされ、その気付アドレスがそのＲＣｏＡであるため、ＲＣｏＡによりＭＡＰ３１でのＡＲＯ登録を行うことが当業者により十分理解されるであろう。

ＭＡＰ３１でのローカル登録が完了すると、ＶＭＮ１０は、そのＨＡ４０とＣＮ５０のそれぞれで、適切なグローバル登録を行う。ここで、ＶＭＮ１０は、ＲＲを実行後、ＣＮ５０にて、そのＲＣｏＡをその気付アドレスとして使用して、ＭＩＰｖ６ベースのＡＲＯ登録を行うものとする。ＢＣＥ６０の第１行目のエントリには、ＶＭＮ１０のグローバル登録値が示されている。ＢＣＥ６０の第３列目には、ＶＭＮ１０によって与えられたＡＲＯ値が示されている。ＣＮ５０は、ＡＣＫをＭＲ２０のホーム・アドレスを介して明確にソース・ルーティングすることで、ＶＭＮ１０のＲＣｏＡへＡＣＫを送信することもできる。ＣＮ５０から上記ＡＣＫを受信すると、ＭＲ２０は、そのＲＣｏＡをその気付アドレスとして使用して、その適切なＡＲＯ登録をＣＮ５０へ送信する。上記登録値は、ＢＣＥ６０の第２行目のエントリにより示されている。

ＣＮがＶＭＮ１０へデータ・パケットを送信する場合、宛先アドレスがＭＲ２０のＲＣｏＡに設定される。このような宛先アドレスは、ＢＣＥ６０を利用したＡＲＯトレースを行うことで設定される。このパケットは、パス１２０を移動し、ＭＡＰ３０に到達した後、ＭＲ２０に到達する。ＭＡＰ３０は、ＭＲ２０のＲＣｏＡへの経路を有しているため、ＣＮ５０から送られてきたデータ・パケットは、ＭＡＰ３０にて、ＭＲ２０のＬＣｏＡへとさらにトンネリングされる。パス１２０を経由して到達したパケットがＭＲ２０により処理されると、次に到達予定のアドレスがＶＭＮ１０のＲＣｏＡとなり、ＭＲ２０によって設定される。ＭＲ２０はＶＭＮ１０のＲＣｏＡへの経路を有していないため、パケットは、ＭＡＰ３０とＭＲ２０のホーム・エージェントとを経由して、ＶＭＮ１０のＲＣｏＡへ送信される。これらの経路は、パス・セグメント１２１、１２２としてそれぞれ示されている。ＨＡ４１では、パス１２２を介して移動したパケットがデカプセル化されると、宛先がＶＭＮ１０のＲＣｏＡとして見つかり、パケットがこのＲＣｏＡが得られたＭＡＰ３１へ送信される。ＭＡＰ３１は、ＢＣＥ６２からも分かるように、ＶＭＮ１０のＲＣｏＡへのルーティング・パスを有する。次にＶＭＮ１０のＲＣｏＡに到達するホップは、ＭＲ２０のＲＣｏＡである。このため、パケットは、パス１２４を経由してさらにルーティングされ、ＭＡＰ３０に到達する。ＭＡＰ３０では、ＭＲ２０のＲＣｏＡに達する経路が得られ、パケットはパス１２５に沿ってＭＲ２０を経由し、最終的にＶＭＮ１０に到達する。

ＣＮ５０からＶＭＮ１０までのルーティング・パスは、非常に長く、曲折しており、準最適であることがはっきりと見て取れる。この複数のＭＡＰを経由した長いピンポン・ルーティングは、主に、ＶＭＮ１０及びＭＲ２０のローカル登録（ＬＣｏＡ登録）が異なるＭＡＰにて行われることに起因している。ネスト状態のＮＥＭＯに接続されたＭＮ又はＭＲのＲＣｏＡに最適に到達するのに必要なすべてのＬＣｏＡをトレースするためには、該ＭＮ又はＭＲの上流のすべてのＭＲが、上記ＲＣｏＡが得られるＭＡＰで何らかの形式の永続的若しくは半永続的な登録を必要とすることが好ましい。図１では、ＶＭＮ１０の上流のＭＲが、ＶＭＮ１０のＭＡＰとは異なる他のＭＡＰに接続されているので、ＶＭＮ１０のＲＣｏＡは、ＭＡＰ３１にて最適なトレースを行うことができない。ＭＡＰ３１ではＭＲ２０のＬＣｏＡ登録が行われておらず、それが上記のＭＡＰ間ピンポン・ルーティングの根本的な原因である。そのため、パケットはＭＡＰ間を行ったり来たりせねばならず、これにより過剰なルーティング遅延が生じる。過剰なルーティング遅延は、リアルタイムかつタイム・クリティカルなアプリケーションに大きな悪影響を及ぼすものである。

上記ルーティング問題についてさらに理解を深めるため、次に、図２について検証する。図２には、図１で示したルーティングの準最適性問題についてさらに詳しく示されている。図２は、ルーティング遅延について示すだけでなく、図１に示したシナリオに関連する過度のトンネリングについてもさらに詳しく示されている。ＣＮ５０がＶＭＮ１０のＨｏＡにデータ・パケットを送信したい場合、ＢＣＥ６０（図１参照）はＡＲＯメカニズムによりトレースされ、そのようなトレースによって得られるアドレスは、ＭＲ２０のＲＣｏＡとＶＭＮ１０のＲＣｏＡである。このため、図２のパケット構造２０８で示されるように、ＣＮ５０は、宛先アドレスがＭＲ２０のＲＣｏＡに設定されるデータ・パケットを作成し、このルーティング・ヘッダのアドレスがＶＭＮ１０のＲＣｏＡやＨｏＡであるＲＨ２を挿入する。このパケット２０８は、インターネットを介してルーティングされ、ＭＲ２０のＲＣｏＡが得られたＭＡＰ３０に到達する。ＣＮ５０からＭＡＰ３０へのルーティング・パスは、図２の２００により示される。ＭＡＰ３０は、このパケット２０８を受信し、宛先アドレス、すなわち、ＭＲ２０のＲＣｏＡへの適切な経路を探す。ＭＡＰ３０は、ＭＲ２０のＲＣｏＡへの経路を有するため、パケット２０８をトンネルにカプセル化する。このカプセル化されたパケットは、図２の２０９により示される。トンネル・ヘッダは、送信元アドレスをＭＡＰ３０のアドレスに設定し、宛先アドレスをＭＲ２０のＬＣｏＡに設定していることが分かる。このＭＡＰ３０にてカプセル化されたパケットは、パス２０１を介して移動し、宛先アドレス、すなわち、ＭＲ２０のＬＣｏＡに到達する。

ＭＲ２０は、パケット２０９をデカプセル化し、そのパケットがそれ自身に宛てられていると認識する（内部パケット宛先アドレスがＭＲ２０のＲＣｏＡである）。そのような場合、ＭＡＰ３０は、ＲＨ２を確認することでパケットをさらに調べ、次のアドレスがＶＭＮ１０のＲＣｏＡであることを認識する。ＭＲ２０は、その後、パケットの宛先アドレスをＶＭＮ１０のＲＣｏＡに設定し、ＲＨ２にＭＲ２０のＲＣｏＡを付加する。パケット２１０の最も内側のパケットに、このパケット構造を示す。ＭＲ２０は、ＶＭＮ１０のＲＣｏＡへの経路を有していないので、イングレスフィルタリングを避けるため、２つのトンネルにパケットをカプセル化する。直近のトンネルはそのホーム・エージェント、すなわち、ＨＡ４１につながり、最も外側のトンネルはそのＭＡＰ、すなわち、ＭＡＰ３０へとつながる。この二重にカプセル化されたパケット２１０は、まず、パス２０２を介してＭＡＰ３０へ送信される。そこで、最も外側のトンネルが除去され、一重にカプセル化されたパケットは、パス２０３を介してＭＲのＨＡ、すなわち、ＨＡ４１へとさらにルーティングされる。

ＨＡ４１では、単一のトンネルが完全に除去され、最も内側のパケットがようやくＭＡＰ３１に到達する。ＨＡ４１にて完全にデカプセル化されたパケットは、ＶＭＮ１０のＲＣｏＡへ宛てられ、パス２０４を介して移動し、ＭＡＰ３１に受信される。ＭＡＰ３１は、図１に示すようにＢＣＥ６２を利用し、トンネル・ルーティング・ヘッダに関連するアドレスを見つけ出す。上記ＢＣＥ６２のエントリを使ったＡＲＯトレースにより、以下のトンネル・アドレスが得られる。得られたトンネル・アドレスは、ＭＲ２０のＲＣｏＡとＶＭＮ１０のＬＣｏＡである。これはパケット２１１に示されている。２１１に示すように、トンネル宛先アドレスは、ＭＲ２０のＲＣｏＡに設定され、トンネルＲＨ２は、ＶＭＮ１０のＬＣｏＡを有する。このカプセル化されたパケットは、パス２０５を介して移動し、ＭＡＰ３０により受信される。ＭＡＰ３０は、パケット２１１を調査し、まずは宛先アドレスを調べる。宛先アドレスがＭＲ２０のＲＣｏＡであり、さらに、ＭＡＰ３０はＭＲ２０のＲＣｏＡへの経路を有しているため、ＭＡＰ３０はトンネルにパケットをさらにカプセル化する。この二重にカプセル化されたパケットは、図２の２１２により示される。パケット２１２に関連付けられている最も外側のトンネルの宛先アドレスはＭＲ２０のＬＣｏＡなので、パケット２１２はパス２０６を介してＭＲ２０に到達する。パケットは、ＭＲ２０で一旦デカプセル化される。最も外側のトンネルを取り除いた後、ＭＲ２０は、再度、宛先がＭＲ２０のＲＣｏＡに設定されていると認識する。その場合、ＭＲ２０は、ＲＨ２を調べ、そこでＶＭＮ１０のＬＣｏＡを見つける。その場合、ＭＲ２０は、宛先アドレスをＶＭＮ１０のＬＣｏＡに変更し、さらにパケット２１３を、パス２０７を介してルーティングする。ＶＭＮ１０では、パケット２１３が完全にデカプセル化され処理される。

図２から、パス・セグメント２００〜２０７から成るルーティング・パスが明らかに準最適なものであることがはっきりと見て取れる。また、図２からは、この準最適ルーティング・パスでは様々なレベルのカプセル化が施されていることも見て取れる。従って、平均パケット・サイズは、ＣＮ５０で発生したパケット２０８よりもかなり大きい。これらはすべて、カプセル化及びデカプセル化処理を実行するルータに関連する、過度の遅延や大きな処理負荷につながる。

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

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

これまでの説明からも分かるように、大きなローカル・モビリティ管理ドメインは、ロードバランシングのために多数のＭＡＰを有することが不可欠である。そのような場合、ネスト状態のＮＥＭＯ内のＭＮ又はＭＲは、ＭＡＰ間のロードバランスをサポートするため、それらのデフォルト・ルーティング・パス上のすべてのＭＡＰアドレスを受信することが好ましい。ロードバランシングのためそのような設計を取り入れる場合、前述の問題解析にも見られるように、ＭＮ／ＭＲ及びその上流のＭＲは、そのＲＣｏＡを得てローカル登録を行うのにそれぞれ異なるＭＡＰを選択してしまう可能性がある。ネスト状態のＮＥＭＯツリーパス内のＭＮ及びＭＲがそれぞれ異なるＭＡＰを選択し、ネスト状態のＮＥＭＯ内の上記ＭＮ又はＭＲがＲＣｏＡによりＣＮとグローバルＭＩＰｖ６登録を行う場合、すでに説明したように、明らかなルーティングの準最適性が発生する。

そこで、本発明は、上記先行技術の不具合や欠点を克服する、若しくは、大幅に改善することを目的とする。具体的には、本発明は、アーキテクチャに複数のＭＡＰが存在する、上記のＡＲＯ及びＨＭＩＰｖ６の混在するシナリオにおいて、２つの目的を有する。第１の目的は、ＮＥＭＯにネストされたＭＮ又はＭＲにローカル・モビリティ管理サービスを提供し、複数のＭＡＰシナリオのロードバランスを犠牲にせずに、ＣＮとの最適なルーティングを実現することにある。つまり、上記目的は、上記ＭＮ／ＭＲが、理想的には利用可能なｎ個のＭＡＰの内一つのＭＡＰのみからそのＲＣｏＡを設定することで、経路の準最適性の問題を解消するということである。第２の目的は、無線ドメインを介した過度のシグナリング、又は、ローカル・モビリティ管理ネットワークドメインにおける過度のシグナリングを行わずに、複数のＭＡＰシナリオにおいて上記経路最適化を可能とすることにある。

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

本発明は、ＶＭＮ、ＭＲ，ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムを提供し、ＶＭＮ及びＭＲは、ＡＲＯとあるＨＭＩＰｖ６のＲＯ対応プロトコルとを実装しているものとする。また、このシステムでは、ローカル・モビリティ管理ドメイン・アーキテクチャ内に複数のＭＡＰが存在し、それらのＭＡＰには、上記ＶＭＮ、ＭＲと同様に、あるＨＭＩＰｖ６のＲＯ機能が実装されているものと考える。このようなシステムにおいて、ネスト状態のＮＥＭＯ内のＭＲは、それが接続されているＭＡＰに関係なく、ネスト状態のＮＥＭＯツリーパス内のその下流のＭＲ及びＶＭＮのＭＡＰにて登録を行う。この他のＭＡＰでの代替の二重登録は、他のＭＡＰから新しいリージョナル気付アドレスを設定せずに行われる。

本発明は、ＶＭＮ、ＭＲ，ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムを提供し、ＶＭＮ及びＭＲは、ＡＲＯとあるＨＭＩＰｖ６のＲＯ対応プロトコルとを実装しているものとする。また、このシステムでは、ローカル・モビリティ管理ドメイン・アーキテクチャ内に複数のＭＡＰが存在し、それらのＭＡＰには、上記ＶＭＮ、ＭＲと同様に、あるＨＭＩＰｖ６のＲＯ機能が実装されているものとする。このようなシステムにおいて、ネスト状態のＮＥＭＯ内のＭＲは、そのネスト状態のＮＥＭＯツリーパス内のＭＮ及びＭＲが利用可能なすべてのＭＡＰオプションに関する情報を有しており、そのローカル・バインディング・アップデート内のその他のＭＡＰアドレスを、選択したＭＡＰに添付する。さらに、ネスト状態のＮＥＭＯツリーパス内のすべてのＭＮ及びＭＲは、ネスト状態のＮＥＭＯが利用可能ないくつかのＭＡＰの内一つのＭＡＰに接続するものとする。

本発明によれば、上記システムの各ノードにより用いられる方法及び装置も提供される。

本発明は、ＡＲＯやＨＭＩＰｖ６が混在する環境下でも有用な機構を提供することができるという利点を有する。

図１は、従来技術のプロトコルが用いられ、アーキテクチャに複数のＭＡＰが存在する場合のＡＲＯ及びＨＭＩＰｖ６の統合シナリオを示すネットワーク図である。 図２は、図１に示す従来技術と同一のシナリオにおける、ＣＮ−ＶＭＮ間のデータ・トラフィックを示すメッセージ・シーケンス・チャートである。 図３は、本発明の好適な実施形態に係る第１の主要な発明における、ＭＲが他のＭＡＰで適切な登録を行う際のメッセージ・シーケンス・チャートである。 図４Ａは、本発明の好適な実施形態に係る図３に示す主要な発明を示すネットワーク図であり、ＭＡＰが図３に示すものとは異なるＲＯ機構を有する場合を示している。 図４Ｂは、本発明の好適な実施形態に係る図３及び図４Ａで説明されたＭＲの機能アーキテクチャを示す図である。 図４Ｃは、本発明の好適な実施形態に係る図３及び図４Ａに示すＭＲの動作に対応するフローチャートである。 図５Ａは、本発明の好適な実施形態に係る第２の主要な発明を示すネットワーク図であり、ＭＡＰ間位置登録の内容を端末のサポートにより転送する様子を示している。 図５Ｂは、本発明の好適な実施形態に係る図５Ａで説明されたＭＡＰの機能アーキテクチャを示す図である。 図５Ｃは、本発明の好適な実施形態に係る図５Ａに示すＭＡＰの動作に対応するフローチャートである。 図６は、本発明の好適な実施形態に係る主要な発明の変更例を示すネットワーク図であり、ＭＲがＭＡＰオプションの送信についての判断を下す様子を示している。 図７は、本発明の好適な実施形態に係る主要な発明の他の変更例を示すネットワーク図であり、ＭＡＰ間位置登録の内容を転送する様子を示している。 図８は、本発明の好適な実施形態に係るＬＭＡ間位置登録の内容の転送がロードバランシングのために行われるＮｅｔＬＭＭシナリオを示すネットワーク図である。 図９は、本発明の好適な実施形態に係るＬＭＡ間位置登録の内容の転送が信頼性を得る目的で行われるＮｅｔＬＭＭシナリオを示すネットワーク図である。 図１０は、本発明の好適な実施形態に係るモビリティ・アクセス・ゲートウェイ（ＭＡＧ）がリンク障害状態では他のＬＭＡと接続するＮｅｔＬＭＭシナリオを示すネットワーク図である。

本発明では、主に２つの方法を提示する。第１の方法としては、ネスト状態のＮＥＭＯ内のＭＮ／ＭＲに対して、複数ＭＡＰシナリオにおけるロードバランシングの原理を侵害することなく、ローカル・モビリティ管理ベースの経路最適化（すなわち、ＲＣｏＡをＣＮに対する気付アドレスとして使用）を実行するために、ＭＲは、自身のＭＡＰとは異なる他のＭＡＰにその下流のＭＮ／ＭＲが接続されていると認識した場合、他のＭＡＰにて適切な位置登録を行う。ＭＲによりそのような登録が行われることにより、下流のＭＮ／ＭＲが上記ＭＲのＮＥＭＯから移動するまでその他のＭＡＰにて半永続的な登録が実現される。また、経路の準最適性問題を解決するために上記ＭＲはその他のＭＡＰでの別のＲＣｏＡ取得しないため、ロードバランシングが達成される。上記ＭＲがその他のＭＡＰから別のＲＣｏＡを取得する場合、その他のＭＡＰはこのアドレスに対しＮＤプロキシ・シグナリングを行わなければならず、その結果、上記その他のＭＡＰにかかる負荷が増大する。

第２の方法としては、ここでも、複数ＭＡＰシナリオにおけるロードバランシングの原理を侵害することなく、ネスト状態のＮＥＭＯ内のＭＮ／ＭＲに対して、ローカル・モビリティ管理ベースの経路最適化（すなわち、ＲＣｏＡを気付アドレスとして使用）を実行するために、上記ＭＮ／ＭＲがそのＲＣｏＡを得たＭＡＰへ、ＭＮ又はＭＲの上流のＭＲのＬＣｏＡ登録が転送される。ＭＲは、つまり、そのＲＣｏＡを得たＭＡＰに、利用可能なその他のＭＡＰアドレスを通知し、この情報により、固定ネットワークリンクを介してＭＡＰ間で適切なＭＡＰ転送が行われる。

第１の方法と比較した場合、第２の方法は以下の利点を有する。第１の方法では、不十分な無線帯域幅により無線ドメインを介しオンデマンドの登録が行われるのに対し、第２の方法では、固定ネットワーク内で転送が行われる。しかしながら、第２の方法では、この方法を実施するためＭＡＰにさらなる変更を加えなければならず、そのような転送を行うためＭＡＰにより大きな処理負荷をかける必要があり、そして、ＭＡＰのバインディング・キャッシュにその他のＭＡＰアドレスを記憶するためより大きな記憶容量が必要である。

第１の好適な実施形態では、上記第１の方法が開示されている。図３は、任意のＶＭＮ１０と任意のＣＮ５０がこれまでに概説した第１の方法により通信を行っている場合のメッセージ・シーケンス・チャートである。ＶＭＮ１０はＭＲ２０に直接接続され、ＭＲ２０はＡＲ２５に直接接続される。ＶＭＮ１０とＭＲ２０は、ＭＡＰ３０とＭＡＰ３１を含むローカル・モビリティ管理ドメイン内でローミングしている。ＶＭＮ１０、ＭＲ２０のホーム・エージェントは、それぞれＨＡ４０、ＨＡ４１である。ここでは、ＶＭＮ１０とＣＮ５０が互いにデータ通信セッション中であるものとする。また、ＶＭＮ１０とＭＲ２０は、ＡＲＯ及び純粋なＨＭＩＰｖ６プロトコルを実装し、ＭＡＰ３０とＭＡＰ３１は、ＡＲＯ対応ＨＭＩＰｖ６タイプのＭＡＰであるものとする。さらに、ＨＡ４０、ＨＡ４１、ＣＮ５０もＡＲＯ対応のものであると想定する。

ＭＲ２０は、ＡＲ２５がそのデフォルト・ルータであるサブネットワーク内へローミングする。レイヤ２にて適切な認証・接続を行った後、ＭＲ２０は、ＭＡＰ３０とＭＡＰ３１の存在を示すＭＡＰオプションを含むＲＡ３００を受信する。ＭＡＰオプションで得られる優先値は「ゼロ」より大きく、ＭＲ２０はそのＲＣｏＡを設定するためＭＡＰ３０のみを用いることを決めるものとする。そのＬＣｏＡとＲＣｏＡを設定後、ＭＲ２０は、ＭＡＰ３０を用いて、３０１で示されるローカル登録を行う。上記登録が完了すると、３０２に示すようなＢＣＥがＭＡＰ３０にて得られる。

このローカル登録に続いて、ＭＲ２０は、次に、ＢＵメッセージ３０３を送信することで、そのホーム・エージェントＨＡ４１にてグローバル登録を実行する。ＢＣＥ３０４は、登録３０３の結果ＨＡ４１にて作成されるＢＣＥを示している。次に、ＭＲ２０は、そのＮＥＭＯリンク内のＭＡＰ３０、ＭＡＰ３１、及びＡＲＯオプションを含むＲＡ３０５を送信する。ＶＭＮ１０は、ＡＲＯオプションとＭＡＰ３１オプションを処理することを決めた状態であってもよい。ＶＭＮ１０は、ＭＡＰオプションの内一つだけを選択するものとする。上述したように、ＣＮ５０と通信するために両方の利用可能なＭＡＰオプションを処理しなければならない理由など一切ない。

ＬＣｏＡとＲＣｏＡを設定後、ＶＭＮ１０は、ＭＡＰ３１にてローカル登録を行う。このローカルＢＵは、メッセージ・セグメント３０６、３０７、３０８、３０９により示される。ＭＲ２０はＭＡＰ３１に対し登録を行っていないため、上記メッセージ・セグメントには、様々なレベルのトンネリングが行われることが当業者により理解されるであろう。ＭＡＰ３１にてＶＭＮ１０によるローカル登録が完了すると、ＭＡＰ３１には、ＢＣＥ３１０に示すようなエントリが含まれる。ＶＭＮ１０によりＡＲＯ及びＭＡＰ３１オプションが処理されるので、ＡＲＯオプションはローカルＢＵに付与される。ＡＲＯ対応ＭＡＰであるＭＡＰ３１は、次に、ＡＣＫをこのローカル登録へと送信する。このＡＣＫは、第１宛先アドレスとして、ＭＲ２０のホーム・アドレスを含み、このＡＣＫメッセージは、図３では、３１１により示されている。メッセージ３１１に関しては、詳細なトンネリングやルーティング・パスは図示されていないが、当業者であれば容易に想到しうる。

ＶＭＮ１０は、ローカルＢＵの送信後直ちに、グローバルＢＵをそのＨＡ４０に送信することが可能である。このことは、メッセージ・セグメント３１２、３１３、３１４、３１５、３１６によって示されている。ここでも、ＭＲ２０がＭＡＰ３１、ＨＡ４０にて登録を行なっていないため、このグローバル登録メッセージには様々なレベルのカプセル化が行われることが分かる。ＨＡ４０にてＶＭＮ１０によるグローバル登録が完了すると、ＨＡ４０にはＢＣＥ３１７が作成される。ＨＡ４０は、ＡＲＯに対応しているため、ＡＣＫの第１宛先アドレスがＭＲ２０のホーム・アドレスであるＡＣＫを送信する。図３では、このＡＣＫメッセージは３１８で示されている。ここでも、やはり、メッセージ３１８に関連する詳細なトンネリングやルーティングは、便宜上説明を省く。

ＭＲ２０は、ＡＣＫ３１１を受信すると、メッセージがドメイン内の別のＭＡＰから送信されたものであると認識する。本発明によると、ＭＲ２０は、それ自身のＭＡＰ若しくはＣＮではないことを認識しているので、このＭＡＰでは登録を行う必要がない。たとえＭＲ２０が登録を行うとしても、その気付アドレスとしてＲＣｏＡを取得しているので、ＭＡＰ３１では、通常、ＨｏＡやＲＣｏＡの登録を行う。その代わりに、ＭＡＰ３１がＶＭＮ１０のＬＣｏＡやＭＲ２０のＬＣｏＡをトレースすることができるよう、ＭＲ２０は、ＭＡＰ３１にてＨｏＡやＬＣｏＡ登録を行う。この登録は、第１の主要な発明であり、メッセージ３１９により示されている。ＭＡＰ３１にて作成された登録は、ＢＣＥ３２０の第２行目のエントリによって示されている。ここでもまた、上述したように、メッセージ３１９に関連している全トンネリングや全ルーティング・パスについては便宜上説明を省く。メッセージ３１９に関連するＨｏＡやＬＣｏＡ登録は、ＲＲ処理も含む必要があることは容易に理解し得るであろう。また、ＶＭＮ１０のＲＣｏＡは、ＢＣＥ３２０やＡＲＯトレース機構により完全にトレース可能であることは当業者であれば十分に理解し得るものである。ＡＲＯトレース後は、ＭＡＰ３１にて十分な登録エントリが入手できるので、ＭＲ２０やＶＭＮ１０のＬＣｏＡが取得可能である。そのような登録３１９が終了すると、ＭＲ２０は、次に、ＨＡ４０から受信したＡＣＫに応答し、適切な登録メッセージ３２１をＨＡ４０に送信する。ＭＲ２０は、その状態表にＨＡ４０に対する特別な分類が何もないので、ＨＡ４０を通常のＣＮと見なす。

ローカル及びグローバル位置登録シグナリングが完了すると、ＶＭＮ１０は、ＣＮ５０とのローカル・モビリティ管理に関連するＲＯの実行を要求し、ＣＮ５０とＲＲやＭＩＰｖ６ＢＵを行い、そのＲＣｏＡをその気付アドレスとして開示する。このようなＣＮ５０に対する登録や、その結果ＣＮ５０に作成されるＢＣＥは、それぞれ、３２２、３２３で示されている。ＣＮ５０は、ＶＭＮ１０へデータを送信したい時は、ＶＭＮ１０のＲＣｏＡへパケットを送信する。この場合、パケットはＭＡＰ３１のホーム・リンクに到達し、ＭＡＰ３１に受信される。ＭＡＰ３１は、ＶＭＮ１０のＲＣｏＡに最適に到達するのに必要なすべてのＬＣｏＡを有する（ＢＣＥ３２０）。これにより、上記データ・パケットはトンネルに挿入され、トンネル宛先アドレスはＭＲ２０のＬＣｏＡに設定される。トンネルＲＨ２は、ＶＭＮ１０のＬＣｏＡとＶＭＮ１０のＲＣｏＡを有する。これが最適なパスとなり、このような双方向データ・メッセージは、図３のメッセージ・セグメント３２４、３２５により示されている。ＶＭＮ１０で作成され、ＣＮ５０に送られるデータ・パケットも、トンネルに挿入される。トンネルの送信元アドレスは、ＶＭＮ１０のＬＣｏＡであり、宛先アドレスはＭＡＰ３１のアドレスであり、ＮＥＭＯ転送ホップバイホップ・オプションがトンネルに挿入される。ＭＲ２０は、このオプションを調査し、送信元アドレスをそのＬＣｏＡに変更し、さらに、パケットをルーティングする。そして、このトンネルは、ＭＡＰ３１により完全に除去される。上記トンネルをデカプセル化した後、内部パケットは、標準ＩＰｖ６ルーティング機構により、さらにＣＮ５０に向かってルーティングされる。

上記方法は、要するに、ＭＲ２０はＶＭＮ１０が接続されるまでその他のＭＡＰにて繰り返し登録しさえすればよいといったオンデマンド登録方法の概要を示したものである。この方法の唯一の欠点は、ネスト状態のＮＥＭＯ内に多数のＭＮやＭＲがあり、利用可能なＭＡＰが多数存在する場合、上記他のＭＡＰの登録によって、シグナリング負荷が大幅に増大し、ネスト状態のＮＥＭＯ内のデータ・トラフィックに対し利用可能な帯域幅が縮小してしまうことである。しかしながら、実際のシナリオの多くでは、ネスト状態のＮＥＭＯはそれほど大きくはなく、この方法が、従来技術で述べられたようなルーティングの準最適性問題を解消するのに非常に有用であることが証明されている。また、このオンデマンド方式で他のＭＡＰを登録する方法では、ネスト状態のＮＥＭＯ内のＭＮやＭＲは、そのデフォルト・ルーティング・パスにおけるＭＡＰからいずれかのＭＡＰをランダムに選択することができ、それにより、ある特定の一つのＭＡＰが過負荷となる可能性が非常に低くなる。

本発明の別の好適な実施形態では、図３に示すのと同様のシナリオについて、図３に示された主要な発明についてさらに詳しく説明する。図４Ａは、上述の主要な発明が作用している別のシナリオを示している。図４Ａでは、ＶＭＮ４１０とＭＲ４２０が、ＡＲＯ及びいくつかのＨＭＩＰｖ６ＲＯ機能を有するものとする。このシナリオでは、さらに、ＶＭＮ４１０、ＭＲ４２０、ＭＡＰ４３０、ＭＡＰ４３１が、図３に示すものとは異なるＨＭＩＰｖ６ＲＯ機能を有するものとする。また、これらはすべて、プレフィックス・デレゲーション／ＰＳＢＵタイプのＨＭＩＰｖ６ＲＯ機能又は改良されたＡＲＯ対応ＨＭＩＰｖ６機能を有し、その自身のＭＡＰでローカル登録を行う際、移動アクセス・ルータのＲＣｏＡがＡＲＯパラメータとして付与される。

システム・ノード（ＶＭＮ４１０、ＭＲ４２０、ＭＡＰ４３０、ＭＡＰ４３１）がプレフィックス・デレゲーション・ベースの、若しくは、ＰＳＢＵベースのＨＭＩＰｖ６ＲＯ機能を有する場合、ＭＡＰ４３０とＭＡＰ４３１で作成されたバインディング・キャッシュは、それぞれ、ＢＣＥ４６１とＢＣＥ４６３により示される。一方、システム・ノード（ＶＭＮ４１０、ＭＲ４２０、ＭＡＰ４３０、ＭＡＰ４３１）が、移動アクセス・ルータのＲＣｏＡをＡＲＯパラメータとしてそのＭＡＰに付与する、改良されたＡＲＯ対応ＨＭＩＰｖ６機能を有する場合、ＭＡＰ４３０とＭＡＰ４３１で作成されたバインディング・キャッシュは、それぞれ、ＢＣＥ４６２とＢＣＥ４６４により示される。

まずは、ＶＭＮ４１０、ＭＲ４２０、ＭＡＰ４３０、ＭＡＰ４３１がプレフィックス・デレゲーション・ベースの、若しくは、ＰＳＢＵベースのＨＭＩＰｖ６ＲＯ機能を有するサブシナリオについて考えてみよう。ＶＭＮ４１０はＭＲ４２０に直接接続されている。ＭＲ４２０はＭＡＰ４３０を用いてそのＲＣｏＡを設定し、ＶＭＮ４１０はＭＡＰ４３１を用いてそのＲＣｏＡを設定する。ＶＭＮ４１０とＭＲ４２０のホーム・エージェントは、それぞれ、ＨＡ４４０、ＨＡ４４１である。ＶＭＮ４１０はＣＮ４５０とデータ通信セッション中であるものとする。上記二つのＭＡＰはＭＡＰドメイン４７１に強固に設置されており、ＭＡＰドメイン４７１はインターネット４７０に接続されている。

ＭＲ４２０は、ＭＡＰ４３０にてプレフィックス指向のローカル登録を行うことが可能である。そのような登録後作成されたエントリはＢＣＥ４６１により示されている。ＭＲ４２０のＲＣｏＡはＭＡＰ４３０から得られ、ＭＡＰ４３０に登録されたプレフィックスはＭＡＰ４３０又はＨＡ４４１から委譲されたプレフィックスであってもよい。続いて、ＶＭＮ４１０は、自身のＭＡＰであるＭＡＰ４３１にてローカル登録を行うことが可能である。このようなＶＭＮ４１０による登録後にＭＡＰ４３１に作成されたエントリは、ＢＣＥ４６３の第１行目のエントリによって示されている。ＢＣＥ４６３内のＶＭＮ４１０のＬＣｏＡは、ＢＣＥ４６１に示されるプレフィックス・パラメータから得られる。ＭＡＰ４３１がそのＡＣＫをＶＭＮ４１０のＬＣｏＡへ送信する場合、このＡＣＫは、ホーム・エージェントＨＡ４４１からトンネリングされる、及び／若しくは、ＭＡＰ４３０からトンネリングされる必要がある。この場合、もともとＭＡＰ４３１から送信されたこのＡＣＫをデトンネリングした後、ＭＲ４２０は、ＭＡＰ４３１と接続されておらず（ＡＣＫパケットがＭＲ４２０のホーム・エージェント及び／若しくはＭＡＰ４３０からトンネリングされたため）、さらに、下流のＭＮ／ＭＲがこの別のＭＡＰに接続されていることを認識する。このような場合、図３に示す第１の主要な発明を利用することで、ＭＲ４２０は、このデトンネリング後に入手したアドレス（ＭＡＰ４３１）が他のＭＡＰアドレスであることをチェックし、ＭＡＰ４３１にてまた別の登録を行う。この登録後、作成されたエントリは、ＢＣＥ４６３の第２行目のエントリとなる。上記ＢＣＥ４６３の第２行目のエントリはＢＣＥ４６１のエントリと同一である。ＭＲ４２０はそのＭＡＰ４３１での登録のためにＭＡＰ４３１で別のＲＣｏＡを入手しているわけではないことを理解することが重要である。別のＲＣｏＡが入手されると、それによりＭＡＰ４３１でのＮＤプロキシ・シグナリングが増大し、そこにさらなるメモリ資源が費やされてしまうので、問題が一層複雑になってしまう。さらに、ＶＭＮ４１０のＬＣｏＡは、この別のＭＡＰからＭＲ４２０へと委譲されたプレフィックスから入手しなければならず、これによりＲＡシグナリング負荷が増大してしまう。ＭＲ４２０が自身のＭＡＰ４３０で使用した同じ位置登録値（すなわち、ＢＣＥ４６１のエントリ）を使ってＭＡＰ４３１にて二重登録を行うことがより良い解決法であることが、上記考察から十分理解されるであろう。

前述の考察から、ＭＡＰ４３１にて登録されたＭＲ４２０のＲＣｏＡが、ＭＡＰ４３０から得られたものであることは明らかである。さらに、ＢＣＥ４６３で登録されたプレフィックス・エントリは、ＭＡＰ４３０によりＭＲ４２０へ委譲されたプレフィックス、若しくは、ＨＡ４４１からＭＲ４２０へ与えられたプレフィックスであってもよい。このように、ＭＡＰ４３０にてＭＲ４２０が行った同様の登録が、単純にＭＡＰ４３１にて繰り返されている。このような二重登録方法では、ＭＲ４２０は、共通の信頼できるキーを使ってそのＭＡＰ４３０にて設定したローカル登録値を非常に容易にパスすることができる。ＭＡＰ４３０とＭＡＰ４３１は共通の信頼できるキーをあらかじめ決めることができ、このキーは、ＭＡＰ４３０と良好なローカル登録を確立する際、ＭＲ４２０へ手渡すことが可能である。このような鍵は、ＭＲ４２０がＭＡＰ４３１にて別のＭＡＰ二重登録を行う際、適切な認証ヘッダ（ＡＨ）、証明書、若しくは、カプセル化セキュリティペイロード（ＥＳＰ）を作成するのに利用できる。ＭＡＰ４３１が、ＭＲ４２０による上記登録に対してアドレスの有効性をチェックする必要がないことは当業者により十分理解されるであろう。なぜなら、ＭＡＰ４３０がもうすでに行ったと信用しているからである。

さらに、ＶＭＮ４１０のＲＣｏＡに最適に到達するために必要なすべてのＬＣｏＡが本実施形態に開示される主要な発明に関連する方法によりＭＡＰ４３１で手に入れることができるので、ＶＭＮ４１０はそのＲＣｏＡをＲＲとＭＩＰｖ６登録を介してＣＮ４５０に渡すことが可能である。このような登録がＣＮ４５０で行われる場合、ＢＣＥはＢＣＥ４６０に示されたようになる。ＣＮ４５０がデータ・パケットをＶＭＮ４１０へ送信すると、宛先アドレスがＶＭＮ４１０のＲＣｏＡに設定され、パケットはＭＡＰ４３１で受信される。ＭＡＰ４３１は、ＶＭＮ４１０のこのＲＣｏＡへの経路を探す。ＭＡＰ４３１は、ＬＣｏＡプレフィックスをプレフィックス・エントリに一致させるプレフィックス・マッチング法を用いてＲＣｏＡに最適に到達するのに必要なすべてのＬＣｏＡを見つける。このような方法を使って、ＭＡＰ４３１は、ＭＲ４２０のＬＣｏＡやＶＭＮ４１０のＬＣｏＡを容易にトレースすることができる。そのため、上記データ・パケットはトンネルにカプセル化され、最適なパスを介してＶＭＮ４１０へ送信される。このような最適ルーティング経路は、図４Ａのメッセージ・セグメント４８０、４８１により示されている。要約すると、他のＭＡＰで適切なオンデマンド二重登録を行うことで、ローカル・モビリティ管理ベースのＲＯがＶＭＮ４１０とＣＮ４５０との間で実現される。このようなローカル・モビリティ管理ベースのＲＯはＶＭＮ４１０のバッテリー電力を節約し、ＶＭＮ４１０によるネットワーク接続における変更ごとにネットワークに投入される平均位置管理シグナリングを軽減するのに非常に効果的である。

次に、ＶＭＮ４１０、ＭＲ４２０、ＭＡＰ４３０、ＭＡＰ４３１が、そのＭＡＰでの登録の際に移動アクセス・ルータのＲＣｏＡをＡＲＯパラメータとして付与する、改良されたＡＲＯ対応ＨＭＩＰｖ６機能を有するサブシナリオについて考察する。この場合でも、ＭＲ４２０はＭＡＰ４３０からＲＣｏＡを設定し、ＭＡＰ４３０にてローカル登録を行う。このように登録されたエントリはＢＣＥ４６２により示されている。ＶＭＮ４１０は、ＲＡから受信するＡＲＯオプションを介して入手可能なＭＲ４２０のＲＣｏＡを有するものとする。このＭＲ４２０のＲＣｏＡはＭＡＰ４３０から得られる。この場合、ＶＭＮ４１０は、自身のＭＡＰ４３１にて登録を行う際このＡＲＯパラメータを利用できることが好ましい。このように作成されたエントリはＢＣＥ４６４の第１行目のエントリによって示されている。ＭＡＰ４３１は、ＭＲ４２０のＲＣｏＡに設定された第１宛先アドレスを持つＡＣＫを送信する。この場合、ＭＲ４２０は、この他のＭＡＰ４３１にてＲＣｏＡやＬＣｏＡ登録を行う。このＭＡＰ４３１でのＭＲ４２０による登録によって、ＢＣＥ４６４の第２行目のエントリに示されるようなエントリが作成される。ＢＣＥ４６４の第２行目のエントリは、ＢＣＥ４６２のエントリと同一である。ＡＲＯの通常動作では、ＭＲ４２０は、そのグローバル・ホーム・アドレスに宛てられたＡＣＫを受信した場合のみ上記のような繰り返し登録を行う。しかし、ＭＲ４２０の新しい機能を使うことで、そのＲＣｏＡに送信されたＡＣＫを受信した場合でも、その二重登録を送信するものとする。ここでも、ＶＭＮ４１０のＲＣｏＡに最適な形で到達するのに必要なすべてのＬＣｏＡを見つけるのにＢＣＥ４６４を利用可能なのは当業者により容易に理解されるであろう。また、前述したように、ＭＲ４２０はすでにＭＡＰ４３１に接続されているので他のＭＡＰにて別の登録を行う必要がないことは理解されるであろう。しかし、下流のＭＮ／ＭＲへの経路最適化を可能とするため、ＶＭＮ４１０のＭＡＰにてそのような二重登録が行われる。

本発明の別の好適な実施形態では、前述の二重オンデマンド登録方法を実施する、ＭＲの機能アーキテクチャを開示する。図４Ｂにこの機能アーキテクチャを示す。プロトコル・スタック４８２は、他のピア・ノードとの通信に参加するのに必要なすべてのソフトウェア及びハードウェアを備えている。ＭＲは、いくつかのＣＮと通信したい場合に、ＭＮとして動作することもあると想定する。下層プロトコル・モジュール４８３は、物理層及びデータリンク層の機能を実装するのに必要なすべてのソフトウェア及びハードウェアを備えている。モジュール４８４は、すべてのルーティングに関連するソフトウェア及びハードウェア機能を備えている。モジュール４８５は、上層プロトコル機能を実装するのに必要なすべてのソフトウェア及びハードウェアを備えている。この上層プロトコル４８５は、トランスポート層プロトコル、ソケット層プロトコル、アプリケーション層プロトコルであってもよい。図４Ｂでは、信号経路４８６がモジュール４８３、４８４間のインターフェースを示し、信号経路４８７がモジュール４８４、４８５間のインターフェースを示す。これらのインターフェースは、その終点として形成されるモジュール間でパケットを転送するのに必要なハードウェア及びソフトウェアを備えている。

ルーティング・モジュール４８４は、複数のサブモジュールとして実装可能であることが好ましい。これらのサブモジュールは、ＩＰｖ６モジュール４８８、ＭＩＰｖ６モジュール４８９、ＮＥＭＯ基本モジュール４９０、ＡＲＯモジュール４９１、ＨＭＩＰｖ６ＲＯモジュール４９２である。また、純粋にサブモジュールに関係するコードのみがそのサブモジュールに実装されるものとする。他のいくつかのサブモジュールに実装された、いくつかのコードは、サブモジュール間をインターフェースで適切に接続することで、サブモジュールにより再利用が可能である。従ってこれらのサブモジュールがさらに相互接続されているとみなすことができる。なお、本発明の要旨から逸脱することなく、ルーティング層機能を実装する方法は一つだけではないことが当業者により十分理解されるであろう。

ＩＰｖ６サブモジュール４８８は、ＭＩＰｖ６サブモジュール４８９と、インターフェース４９４を介して相互接続されている。ＭＩＰｖ６サブモジュール４８９は、ＮＥＭＯ基本４９０、ＡＲＯモジュール４９１、ＨＭＩＰｖ６ＲＯモジュール４９２と、それぞれインターフェース４９５、４９７、４９６を介して相互接続されている。ＮＥＭＯ基本サブモジュール４９０は、サブモジュール４９２、４９１と、それぞれインターフェース４９９、４９８を介して相互接続されている。ＡＲＯサブモジュール４９１は、インターフェース４９９Ａを介してＨＭＩＰｖ６ＲＯモジュールと相互作用している。このアーキテクチャでは、ＭＲは、すべてのサブモジュールが同時にトリガーされる、若しくは、サブモジュールの一部のみがトリガーされる状態であってもよいものとする。ＭＲがＭＡＰドメイン内でローミングしている場合、すべてのＭＡＰに関連する機能は、ＨＭＩＰｖ６ＲＯサブモジュール４９２により処理されるものとする。ＨＭＩＰｖ６ＲＯサブモジュール４９２は、ＭＡＰ登録を行うのに必要なプロトコルを備えている。このＭＡＰ登録は、前述の実施形態で説明されたようなＲＯパラメータを用いて行われる。このサブモジュール４９２には、小型のサブモジュール４９３がさらに埋め込まれている。具体的には、このモジュール４９３は、他のＭＡＰ（ＭＲ自身のＭＡＰではない）にて二重登録を行うためのものである。

ＩＰｖ６ルーティング・モジュール４８８は、ＲＡの生成・処理、リンク・ローカル・ルーティングの実行、インターネット制御メッセージプロトコル（ＩＣＭＰｖ６）メッセージの送受信、ＩＰｖ６ヘッダの形成、ＩＰｖ６ヘッダの処理、アドレス設定、近隣探索、などを行うものである。ＭＩＰｖ６モジュール４８９は、ＭＩＰｖ６機能を実装するのに必要なすべてのソフトウェア及びハードウェアを司るものである。これは移動ルータであるが、ＭＩＰｖ６機能は二つの目的で利用される。ＭＩＰｖ６機能は、ＭＲがＭＮとして機能する場合に利用することができ、また、他の高度な機能を入手するのに利用することができる。つまり、ＭＩＰｖ６は基本クラスとして利用することが可能で、その他のＮＥＭＯ基本、ＡＲＯ、ＨＭＩＰｖ６ＲＯなどの導出クラスはそこから導出することができる。パケットが、サブモジュール４８８で処理された後、インターフェース４８６を介してＩＰｖ６モジュールに到着すると、そのパケットは、ＩＰｖ６モジュール４８８では処理不可能な未知のパラメータ（モビリティ・ヘッダ）がある場合、ＭＩＰｖ６モジュールに送信される。そうでなければ、ＩＰｖ６モジュールは、パケットをある程度処理した後インターフェース４８７を介して上層プロトコルに渡す。若しくは、パケットを完全に処理し消費する。パケットがインターフェース４８７を介してＩＰｖ６モジュールに到着した場合、これらのパケットは、ＭＲがホーム・リンクにある場合に限り、モジュール４８８のみにより処理される。そうでなければ、パケットはＭＩＰｖ６モジュール４８９に送信され、さらに処理される。制御パケットなどのパケットがルーティング・モジュール４８４にて作成された場合、ＩＰｖ６はそのパケットをその性質に応じて形成する。例えば、ＩＣＭＰｖ６パケットはＩＰｖ６モジュール４８８により形成される。

インターフェース４９４を介して到着する全てのパケットは、前述のサブモジュールへと送られ、パケット及びＭＲに処理されるオプションに見られるパラメータ（例えば、パケットの宛先アドレス）に基づきさらに処理される。上記オプションは、前述の実施形態で説明したＭＡＰオプション、ＡＲＯオプション、プレフィックス・オプションである。

本発明のさらに別の好適な実施形態では、ルーティング層４８４でパケットを処理する際のＭＲの動作をさらに理解するため、次に、ＭＲのフローチャートを示す。図４Ｃに示すフローチャートは、主に、図４Ｂのモジュール４８４でのパケット処理を示す。ＲＡが受信されると、ステップ４０１Ａがトリガーされる。ステップ４０１Ａでは、ＭＡＰオプションを処理するか否かが判断される。ＭＡＰオプションを処理すると判断された場合、ステップ４０２Ａが実行される。このステップ４０２Ａは、複数のＭＡＰオプションの内の一つのＭＡＰオプションの処理に関係する方法に関与する。具体的には、ＬＣｏＡやＲＣｏＡを設定し、選択されたＭＡＰにてローカル登録を行い、一つ又は複数のＭＲのホーム・エージェント及び（もしあれば）ＭＲのＣＮにてグローバル登録を行う。ステップ４０２Ａを実行後、制御はステップ４０３Ａへと進む。このステップ４０３Ａでは、受信したすべてのＭＡＰオプションがＲＡに組み込まれ、送信される。このステップ４０３Ａ後、制御はステップ４０４Ａへと続く。このステップ４０４Ａでは、ＭＡＰアドレス以外のアドレスとのイングレス・インターフェースにパケットがあるかどうかを判断する。若しくは、ＭＲに作成されたパケットをＭＲが持っているかどうかを判断する。ステップ４０４Ａで「ｙｅｓ」と判定された場合、ステップ４０５Ａが実行される。パケットはその他のアドレス（ＭＡＰアドレス以外）に宛てられたものである場合、ＭＲはそのＨＡを介してパケットをトンネリングしてもよい。ステップ４０５Ａでは、ＭＲのレイヤ３にてトリガーされる標準スタックに応じて従う標準ルーティング機構を示す。当業者であれば、このステップ４０５Ａの機能を、ＭＲに実装されたモビリティ・ルーティング機構に基づき、容易に解釈することができるであろう。

ステップ４０１Ａで「ｆａｌｓｅ（偽）」又は「ｎｏ」と判定された場合、ステップ４０４Ａが再度実行され、ステップ４０４Ａで「ｙｅｓ」と判定されると、前述のステップ４０５Ａが行われる。

ステップ４０５Ａで「ｎｏ」と判定された場合、ステップ４０６Ａが実行される。このステップ４０６Ａでは、パケットがイングレス・インターフェースを介して到着したか否か、また、宛先アドレスが（ＲＡを介して受信した）ＭＲの知っているＭＡＰアドレスに設定されているか否かを判断する。ステップ４０６Ａで「ｙｅｓ」と判定された場合、ステップ４０７Ａが実行される。このステップ４０７Ａでは、パケットの宛先アドレスが、ＭＲがそのＲＣｏＡを導出したＭＡＰアドレスと同じであるか否かを判断する。もしそうである場合、ＭＲは、そのＭＡＰアドレスで登録があることを把握し、ステップ４０８Ａを実行する。ステップ４０８Ａは、パケットをＭＲのＭＡＰにトンネリングする、若しくは、送信元アドレスをＭＲのＬＣｏＡに変更し、パケットをさらにルーティングする方法に関連する。このステップ４０８Ａ後、制御はステップ４０１Ａへ戻る。

ステップ４０７Ａで「ｎｏ」と判断された場合、イングレス・インターフェースでパケットに関連する宛先アドレスが他のＭＡＰアドレスと同じであることを意味する。このため、次に、ステップ４１１Ａが実行され、ＭＲがこのＭＡＰで登録があるか否かを判断する。ステップ４１１Ａで「ｎｏ」と判断された場合、ステップ４１４Ａが実行される。これは、他のＭＡＰで登録がない場合、ＭＲは他のＭＡＰで適切な登録を行うことを意味している。前述の実施形態でも説明したように、他のＭＡＰでの登録パラメータの種類は、ドメイン内のＭＡＰのＨＭＩＰｖ６ＲＯ機構に依存する。この他のＭＡＰでの登録を行った後、制御はステップ４０５Ａへと進み、そこで通常の操作によりパケットが正常にルーティングされる。若しくは、パケットをしばらくの間バッファリングし、他のＭＡＰでの登録により作成された最適経路を介して送信することができる。ステップ４１１Ａを行った時に、他のＭＡＰにてもうすでに登録が行われていることが分かった場合、ステップ４１２Ａが実行される。このような場合、パケットは他のＭＡＰにトンネリングされるか、送信元アドレスがＬＣｏＡに変更され、さらに他のＭＡＰへと送信される。

ステップ４０６Ａで「ｎｏ」と判断された場合、制御はステップ４０９Ａへと進む。このステップ４０９Ａは、パケットがエグレス・インターフェースを介して到着したか否か、かつ、パケットがＭＲに宛てられたものであるか否かを判断する方法である。ステップ４０９Ａで「ｙｅｓ」と判断された場合、ステップ４１０Ａが実行される。ステップ４１０Ａを実行すると、パケットはＭＲによって消費される。このパケットは、ＭＲのレイヤ３にて完全に処理される、若しくは、ＭＲの上層へと送信される。ステップ４０９Ａで「ｙｅｓ」と判断された場合、パケットがまずデカプセル化されることを意味し、その後、ステップ４１３Ａが行われる。このステップ４１３Ａでは、デカプセル化後、内部パケット送信元アドレスが他のＭＡＰアドレスと同じであるか否かを判断する。この場合、ＭＲは、他のＭＡＰで登録がないことを把握しているので、制御はステップ４１４Ａへと進む。他のＭＡＰにて再度適切な登録が行われ、パケットがステップ４０５Ａへと引き渡され、そこで通常の機構を用いてパケットをさらにルーティングする。ステップ４０５Ａを行った後、制御はステップ４０１Ａへと戻る。ステップ４１３Ａで「ｎｏ」と判断された場合、パケットは再度ステップ４０５Ａへと送信され、さらにルーティングされる。

本発明のさらに別の好適な実施形態では、主要な発明の第２の方法、いうなれば第２の主要な発明が開示される。この第２の主要な発明とは、ここでもロードバランシング機能を犠牲にせずに、複数ＭＡＰ環境下のＶＭＮ−ＣＮ間のデータ・トラフィックを行うように、ローカル・モビリティ管理ベースのＲＯを備えるものである。しかし第２の主要な発明では、最適経路を介してＶＭＮのＲＣｏＡに達するために必要なＬＣｏＡ登録が、固定ネットワークを介して、一つ又は複数のＭＡＰから、ＲＣｏＡが導出されたＭＡＰへと転送されている。これにより、前述の実施形態の第１方法と比べ、無線ドメインにかかるシグナリング負荷が少なくなる。この第２の発明は、この第２の方法を示した関連する図５Ａ乃至図５Ｃを把握することで、さらに明確に理解されるであろう。

図５Ａでは、ＶＭＮ５１０はＭＲ５２０に直接接続され、ＭＲ５２０はＭＲ５２１に直接接続され、ＭＲ５２１にルートされたネスト状態のＮＥＭＯはローカル・モビリティ管理ドメイン５７１に接続されている。ＭＡＰドメイン５７１はインターネット５７０に接続されているものとする。また、ＶＭＮ５１０はＣＮ５５０とデータ通信セッション中であり、ＣＮ５５０はインターネット５７０に接続されているものとする。このシナリオでは、ＶＭＮ５１０、ＭＲ５２０、ＭＲ５２１は２つのＭＡＰオプション、すなわち、ＭＡＰ５３０に由来するＭＡＰオプションとＭＡＰ５３１に由来するＭＡＰオプションとを受信するものとする。

図５Ａに示す第２の方法の主要なポイントとしては、ネスト状態のＮＥＭＯツリーパス内のＭＮ及びＭＲは、利用可能なＭＡＰオプションの内の任意の一つのＭＡＰオプションを選択してそのＲＣｏＡを設定することができ、かつ、ＭＮ又はＭＲのＲＣｏＡに到達するのに必要なすべてのＬＣｏＡが、ＭＡＰ間の転送を介してＲＣｏＡが導出されるＭＡＰにて入手可能であるということである。従って、この方法では、ＭＲは、選択したＭＡＰへローカル登録を送信する場合、そのＲＡで確認したその他のＭＡＰアドレスを送信するものとする。要するに、ＭＲは、ネスト状態のＮＥＭＯツリーパス内のＭＮ／ＭＲがそれらのローカル登録を行うその他のＭＡＰについての「ヒント」を自身のＭＡＰに与える。ＭＡＰは、この（その他のＭＡＰアドレスを介して与えられる）「ヒント」を用いて自身の位置登録エントリをその他のＭＡＰに渡す。それにより、それらのＭＡＰは、上記ＭＡＰから一意的に導出されたＲＣｏＡに達するのに必要なすべてのＬＣｏＡをトレースすることができる。

このような方法が実施されている場合、図５Ａでは、ＭＲ５２１はＭＡＰ５３１オプションを処理してそのＲＣｏＡを設定するものとする。その後、ＭＲ５２１はＭＡＰ５３１にてローカル登録を行い、作成されたエントリはＢＣＥ５６２の第１行目に示されている。ＭＲ５２１は、ローカル登録を行う際、そのＢＵモビリティ・ヘッダ内のオプションとしてのＭＡＰ５３０アドレスである、その他のＭＡＰアドレスを付加することが好ましい。ＢＣＥ５６２に示すＲＯパラメータは、システムに実装されたＨＭＩＰｖ６関連のＲＯ機構を反映する。これらの図示のＲＯパラメータとしては、上流の移動アクセス・ルータのＨｏＡ、上流の移動アクセス・ルータのＲＣｏＡ、又は、自身のＭＡＰ若しくは自身のＨＡに委譲されたプレフィックスが挙げられる。これらのＲＯパラメータは、最適にＲＣｏＡに達するのに必要なすべてのＬＣｏＡをトレースするために必須のパラメータであることは当業者により理解されるであろう。さらに、前述の実施形態では、これらのＲＯパラメータをどのように利用して関連するＬＣｏＡを見つけ出すかや、トレース機構について、詳細かつ明確な説明がなされた。本実施形態での説明を簡潔なものとするため、上記についてのさらなる詳細な説明はしない。

次に、選択したＭＡＰにて適切なローカル登録が行われた後、ＭＲ５２１はそのＲＡを送信し、ＭＲ５２０はＭＡＰ５３１オプションを処理してローカル登録を行うものとする。ＭＲ５２０によりローカル登録が完了すると、作成されたエントリがＢＣＥ５６２の第２行目のエントリによって示される。ここでも、ＭＲ５２０は、ＢＵを行う際、ＭＡＰ５３０アドレスを付与する。これは、ＭＲ５２１やＭＲ５２０に関連付けられた同じネスト状態のＮＥＭＯツリーパス内の他のＭＮ又はＭＲがこのＭＡＰ５３０に接続されている可能性があり、ＭＡＰ５３０にて登録されたＲＣｏＡをトレースするためにＭＲ５２１やＭＲ５２０エントリが必要となる可能性がある、というＭＡＰ５３１に対する「ヒント」である。ＭＲ５２０がそのＲＡを送信する場合、ＶＭＮ５１０はＭＡＰ５３０アドレスによりローカル登録を行うものとする。ＶＭＮ５１０は、移動ノードであってルータではないので、そのＢＵ内のその他のＭＡＰアドレスを送信する必要はない。このことは当業者であれば容易に理解し得ることである。なぜなら、他のどのＭＡＰもＲＣｏＡに達するのにこのＶＭＮ５１０のＬＣｏＡ（ＶＭＮ５１０のＬＣｏＡはリーフ・アドレスである）を必要とはしていないからである。このＭＡＰ５３０での登録後に作成されたローカル登録エントリがＢＣＥ５６１に示されている。

ＭＡＰ５３１は、新しいエントリを手に入れるたび、又は、古いエントリがリフレッシュされた時は、第２の主要な発明に関連する機構をトリガーする。この機構は、ＭＡＰ５３１が同じ他のＭＡＰアドレスを有するエントリを検索するためのものである。これらのエントリが新しいエントリ又はリフレッシュされたばかりのエントリである場合、ＭＡＰ５３１はこれらのエントリをすべてその他のＭＡＰアドレスに転送する。つまり、このシナリオでは、ＭＡＰ５３１はＢＣＥ５６２に示す（他のＭＡＰアドレスを除く）すべての登録エントリをＭＡＰ５３０に転送する。この転送後、ＢＣＥ５６３は、ＭＡＰ５３０にて作成された新しいエントリを与える。上記ＭＡＰ間転送は、ＭＡＰドメイン５７１内のＭＡＰ間で相互に受諾されたセキュリティ・キーにより安全に行われる。ＢＣＥ５６２の第４列目に他のＭＡＰアドレスが複数存在する場合、２行分のエントリがそのすべての他のＭＡＰアドレスに転送されなければならないということが当業者により容易に理解されるであろう。ＢＣＥ５６３はＶＭＮ５１０のＲＣｏＡに最適に到達するのに必要なすべてのエントリを有しているので、ＶＭＮ５１０とＣＮ５５０の間の双方向データ通信は、図示のパス・セグメント５８１、５８２に示されるような最適経路を介して行われるということが容易に理解されるであろう。

本実施形態に記載される方法と、無線ドメインを介して行われるオンデマンド二重登録の相違点を理解することが重要である。二重エントリは、ネスト状態のＮＥＭＯ内の他のノードからの要求に応じてのみ、必要なＭＡＰにて作成されるという点では、二つの方法は同様の効果を有する。それらの方法の優れた特徴は、ほかに、ロードバランスが犠牲になることはなく、ネスト状態のＮＥＭＯ内の任意のＭＮ／ＭＲは、利用可能なｎ個のＭＡＰの中からいずれかのＭＡＰを１／ｎの確率で選択することができるという点である。その結果、上記ｎ個のＭＡＰがすべて均等に使用され、過負荷によるＭＡＰの不具合を回避することができる。

本発明の別の好適な実施形態では、図５Ａに対応する実施形態でのＭＡＰ動作についての理解をさらに深めるため、ＭＡＰの機能アーキテクチャを説明する。図５Ｂにこの機能アーキテクチャを示す。図５Ｂでは、５００Ａは、プロトコル機能を実装するのに必要なすべてのソフトウェア及びハードウェアを含むＭＡＰプロトコル・スタックを示す。下層プロトコル・モジュール５０２Ａは、すべての物理層及びデータリンク層のプロトコルから成る。モジュール５０１Ａは、ルーティング層プロトコル機能を示す。ＭＡＰは、主に固定ルータであるので、上層のプロトコル層がない。ルーティング層５０１Ａは、ＩＰｖ６モジュール５０４Ａと、ＨＭＩＰｖ６ＲＯモジュール５０５Ａと、新しい高度処理モジュール５０６Ａとをさらに備えている。ＩＰｖ６モジュールは、標準のＩＰｖ６機構に対応するすべての機能を実装する。ＨＭＩＰｖ６ＲＯモジュールは、すでに概説された特別なＨＭＩＰｖ６ＲＯ機構を実装する。このＨＭＩＰｖ６ＲＯモジュールの内部には、モジュールに対応するバインディング・キャッシュも存在することとする。上記の新しい高度処理モジュール５０６Ａは、モジュール５０５Ａ内のＢＣエントリを定期的に監視し、ＢＣエントリを特定された一つ又は複数のＭＡＰに関連性を持って転送する機能を備えている。ＩＰｖ６モジュール５０４Ａは、５０８Ａを介してＨＭＩＰｖ６ＲＯモジュール５０５Ａと接続されている。ＨＭＩＰｖ６ＲＯモジュール５０５Ａは、インターフェース５０７Ａを介して新しい高度処理モジュール５０６Ａと接続されている。下層プロトコル・モジュール５０２Ａは、インターフェース５０３Ａを介してルーティング・モジュール５０１Ａと接続されている。

パケットは、インターフェース５０３Ａを介してルーティング・モジュール５０１Ａに到達すると、ＩＰｖ６モジュールにより完全に処理されるか、ＨＭＩＰｖ６ＲＯモジュールに転送される。要するに、ＩＰｖ６モジュールがそのようなパケットを完全に処理することができるのであれば、そのパケットはそこで処理される。そうでなければ、ＨＭＩＰｖ６ＲＯモジュールがそのパケットを処理する。

本発明のさらに好適な実施形態では、図５Ｂのモジュール５０１ＡでのＭＡＰパケット処理方法について説明する。図５Ｃに上記層でのＭＡＰ処理を示す。ＭＡＰでは、初めに、ステップ５００Ｂが行われる。ステップ５００Ｂでは、まず、パケットがエグレス・インターフェースに到着したか否かを判断する。ステップ５００Ｂで「ｙｅｓ」と判断された場合、制御はステップ５０１Ｂへ移動する。ここで、パケットの宛先アドレスが、前述の実施形態で説明したＨＭＩＰｖ６ＲＯモジュールのＢＣ内のエントリを有しているか否かを判断する。ステップ５０１Ｂで「ｙｅｓ」と判断された場合、ステップ５０２Ｂが実行される。このステップ５０２Ｂでは、宛先アドレスに到達するのに必要なすべてのＬＣｏＡを見つけるために、ＢＣのトレースが行われる。必要なＬＣｏＡが見つかったら、ステップ５０３Ｂが行われる。このステップ５０３Ｂでは、ステップ５０２Ｂで特定されたＬＣｏＡを用いてパケットをトンネルにカプセル化し、さらにルーティングされる。このステップ５０２Ｂ終了後、制御は（初めに処理されるべきイベントの時間に応じて）ステップ５００Ｂ又は５１２Ｂに移動する。ステップ５０１Ｂで「ｎｏ」と判断された場合、パケットは通常の機構に従って正常にルーティングされる。つまり、ＭＡＰは宛先アドレスに対するＢＣエントリを持っていないので、パケットのルーティングはＩＰｖ６ルーティング機構により行う必要がある。

ステップ５００Ｂで「ｎｏ」と判断された場合、ステップ５０５Ｂが実行される。ステップ５０５Ｂでは、パケットがイングレス・インターフェースを介して到着したか否かを判断する。ステップ５０５Ｂで「ｎｏ」と判断された場合、パケットはＭＡＰから発信され、ステップ５０６Ｂが実行される。ステップ５０６Ｂでは、パケットは通常の機構と同様にして構築され、ルーティングされる。一方、ステップ５０５Ｂで「ｙｅｓ」と判断された場合、制御部はステップ５０７Ｂへと移行する。ステップ５０７Ｂでは、イングレス・インターフェースに到着したパケットがそのＭＡＰ宛てのものであるか否かを判断する。ステップ５０７Ｂで「ｙｅｓ」と判断された場合、ステップ５０８Ｂが実行される。ステップ５０８Ｂでは、このパケットがローカルＢＵであるか否か、かつ、他のＭＡＰアドレスが添付されているか否かを判断する。ステップ５０８Ｂで「ｙｅｓ」と判断された場合、ステップ５０９Ｂが実行される。ステップ５０９Ｂでは、その他のＭＡＰアドレスが、ＲＣｏＡ値に対応するメモリの位置に配置される。ステップ５０８Ｂで「ｎｏ」と判断された場合、ステップ５１０Ｂが実行される。ステップ５１０Ｂでは、通常通りにローカルＢＵエントリが配置される。

イベント・スケジューラにおける現在のイベントが、ステップ５１２Ｂに対応するものである場合、そのステップ５１２Ｂがトリガーされる。ステップ５１２Ｂでは、新しくＢＣエントリが作成されたか否か、若しくは、エントリの更新又はリフレッシュが行われたか否かが判断される。ステップ５１２Ｂで「ｙｅｓ」と判断された場合、ステップ５１３Ｂが実行される。ステップ５１３Ｂは、共通の他のＭＡＰアドレスを持つＢＣエントリをまとめてグループ化する機能を有する。ステップ５１３Ｂの処理が終了すると、制御はステップ５１４Ｂへと移行する。ここでは、変更されたＢＣエントリ又は新しいＢＣエントリを、ステップ５１３Ｂで特定された他のＭＡＰに通知する。ステップ５１４Ｂが完了すると、制御はメインループへと移動する。それはイベント・スケジューラにおける最初のイベント次第で５００Ｂ、又は５１２Ｂとなる。

本発明のさらに別の好適な実施形態では、図５ＡのＭＲ５２１は、受信したＲＡに複数のＭＡＰオプションがあった場合、得られたすべてのＭＡＰオプションの中から、ある一定の数のＭＡＰだけを選択することが好ましい。また、ＭＲ５２１は、その優先レベルがある程度の閾値よりも大きいＭＡＰオプションを選択することが好ましい。ここで、優先レベルは、通常、ＭＡＰが過負荷状態でない場合に、高く設定されるものであると理解することが重要である。ＭＲ５２１がこのようにＭＡＰオプションのフィルタリング又は選択処理を行うことで、ＭＡＰ間の転送シグナリングの軽減、及び、ＭＡＰドメインにおける輻輳の軽減を図ることができる。つまり、ＭＲにより登録される他のＭＡＰアドレスの数が少ないと、この登録を行うＭＡＰからエントリが転送されてくるＭＡＰドメイン内のＭＡＰの数も少なくなる。その結果、ＭＡＰドメイン内のネットワーク・トラフィックが縮小する。また、すでにかなりの負荷がかけられているＭＡＰにこれ以上の負荷をかけることはしない上記のフィルタリング方法によって、より良いロードバランスを実現することが可能である。ＭＲ５２１によっていくつかのＭＡＰオプションを除去するという判断は、ＭＡＰクラウドの他のＭＡＰにより行われる。

本発明の好適な実施形態では、ＭＲ５２１及びＭＲ５２０は、選択したＭＡＰにて登録を行う場合、他のＭＡＰアドレスを送信する必要がない。ＭＡＰは、そこに登録されたＲＣｏＡに到達するのに必要なすべてのＬＣｏＡが存在するかどうかを判断するために、ＢＣＥのセルフチェックを行うことができる。例えば、図５ＡのＲＯパラメータが上流の移動アクセス・ルータのＲＣｏＡである場合、ＢＣＥ５６１のＲＯパラメータ・エントリにはＭＲ５２０のＲＣｏＡが含まれる。ＭＡＰ５３０は、セルフチェックを行うことで、ＢＣＥ５６１にはＭＲ５２０のＲＣｏＡに対応するものが見当たらないため、ＢＣＥ５６１にはこれ以上ＶＭＮ５１０のＲＣｏＡをトレースするためのエントリが存在しないということを確認することができる。この場合、ＭＡＰ５３０は、ＭＲ５２０のＲＣｏＡを調べることで、このアドレスが別のＭＡＰから得られたものであることをインテリジェントに把握することができる。ＭＡＰ５３０は、ドメイン内のすべてのＭＡＰアドレスに関する情報を有することが好ましく、それにより、ＭＲ５２０アドレス・プレフィックスのＲＣｏＡと一致する適切なＭＡＰアドレス・プレフィックスを見つけることができる。ＭＡＰ５３０が上述のマッチング方法を使ってＭＡＰ５３１アドレスを決定すると、ＭＡＰ５３０は、ＭＲ５２０のＲＣｏＡを添付したクエリーをＭＡＰ５３１に送信する。そして、ＭＡＰ５３１は、このクエリーを理解し、ＭＲ５２０のＲＣｏＡを用いて、ＭＡＰ５３０に転送すべき必要なエントリをトレースする。このように、ＭＡＰ５３１はまず、そのＢＣＥ５６２においてＭＲ５２０のＲＣｏＡを見つけ出し、その後トレースを行って、ＢＣＥ５６２の２行のエントリを転送する必要があると判断し、それらをＭＡＰ５３０へ転送する。

この方法は、オプションで他のＭＡＰアドレスを送信する前述の方法と、以下の点で異なる。つまり、この方法では、ＢＣＥエントリを得るには「クエリー」と「応答」が必要であり、これはむしろ反応型の転送であるのに対し、前者の方法は、先行型の転送である。別の方法では、ＭＡＰ５３０は他のＭＡＰ情報を持っていなくてもよく、ＭＲ５２０のＲＣｏＡのプレフィックスにより構成されたエニキャスト・メッセージを送信して対応するＭＡＰをトレースすることができる。そのＭＡＰ５３１にはエニキャスト・アドレス値を割り当てなければならないことは言うまでもない。当業者にとっては、これらの方法以外にも、本実施形態に記載されたクエリーメッセージを送信するためにＭＡＰをトレースする方法はいくらでもある。システムがプレフィックス・デレゲーション・ベースの、若しくは、ＰＳＢＵベースのＨＭＩＰｖ６ＲＯ機構を有する場合、ＭＡＰ５３０は、単にＢＣＥ５６１のＶＭＮ５１０のＬＣｏＡのエントリを調べるだけで、他のエントリが入手可能なＭＡＰを見つけ出すことができるということを理解することも重要である。これは当業者であれば容易に理解し得ることである。

本発明のさらに別の好適な実施形態では、ＭＲが、何らかの方法で、ＭＡＰオプションが下流のＭＲ又はＭＮにより処理される（例えば、ＭＲ５２０とＶＭＮ５１０はＭＲ５２１の下流側にある）ということを知っている場合、ＭＲは、自身のＭＡＰに行う登録の際、ＭＡＰアドレスを下流のＭＲやＭＮに送信しさえすればよい。なぜなら、ある特定のＭＲの位置登録値は、下流のＭＲやＭＮのＭＡＰにおいてのみ必要とされるからである。上流のＭＲやＭＡＰは、下流のＭＲの登録を必要としない。これにより、図５Ａで説明した前記実施形態のように、すべてのＭＡＰアドレスを送信しなくてもよくなる。従って、本実施形態の方法は、図５Ａに示された第２の主要な発明の最適化である。

本発明のさらに別の好適な実施形態では、主要な発明の変更例を説明する。図６にこの変更例を示す。この変更例では、オンデマンド二重登録は行われない。一方、ドメイン内で同じ優先レベルを有するＭＡＰに対し、この方法では、いくつかのＭＡＰに負担をかけ過ぎるかもしれない。図６の詳細な分析によりさらに詳しく説明する。

図６では、ＶＭＮ６１０がＭＲ６２０に直接接続され、ＭＲ６２０がＡＲ６２５に直接接続される。ＡＲ６２５はＭＡＰクラウド６７１に接続される。クラウド６７１には、ＭＡＰ６３０とＭＡＰ６３１の２つのＭＡＰが配置されているものとする。また、ＡＲ６２５は、受信するＲＡメッセージ６８１内の２つのＭＡＰオプションを受信する。ＡＲ６２５は、受信したＲＡの処理を行い、パケット６８１と同じ構造の新しいＲＡ６８２を送信する。ＶＭＮ６１０はＣＮ６５０とデータ通信セッション中であるとする。本実施形態の発明が実施されている時、ＣＮ６５０のＢＣＥは６６０によって示される。

システム（ＶＭＮ６１０、ＭＲ６２０、ＭＡＰ６３０、ＭＡＰ６３１）が、移動アクセス・ルータのＲＣｏＡをＡＲＯパラメータとする、ＡＲＯ対応ＨＭＩＰｖ６機能を有する場合（サブシナリオ１）、本実施形態の発明が実施されている時、ＭＡＰ６３０にてＢＣＥ６６１が作成されるものとする。また、システム（ＶＭＮ６１０、ＭＲ６２０、ＭＡＰ６３０、ＭＡＰ６３１）が、移動アクセス・ルータのＨｏＡといくつかのＭＡＰ知能をＡＲＯパラメータとするＡＲＯ対応ＨＭＩＰｖ６機能を有する場合（サブシナリオ２）、本実施形態の発明が実施されている時、ＭＡＰ６３０にてＢＣＥ６６２が作成されるものとする。さらに、システム（ＶＭＮ６１０、ＭＲ６２０、ＭＡＰ６３０、ＭＡＰ６３１）が、移動アクセス・ルータのＨｏＡをＡＲＯパラメータとするＡＲＯ対応ＨＭＩＰｖ６機能を有する場合（サブシナリオ３）、本実施形態の発明が実施されている時、ＭＡＰ６３０にてＢＣＥ６６３が作成されるものとする。

従来技術の問題を分析すると、複数のＭＡＰオプションを持つ複数ＭＡＰシナリオでは、ネスト状態のＮＥＭＯツリーパス内のＭＮとＭＲは、ＲＣｏＡを設定するのに異なるＭＡＰを選択してしまう可能性があり、その結果、経路の準最適性が生じてしまう。この問題を解消するため、ＭＲ６２０は、ＲＡ６８２を受信し、複数のＭＡＰそれぞれにそれほど負荷がかけられていない、又は、複数のＭＡＰが同等の優先値を有することを認識した場合、一つのＭＡＰ（この場合、ＭＡＰ６３０）で登録を行うことを決め、作成するＲＡ内でＭＡＰ６３０オプションのみを送信する。これが本実施形態の発明の主要なポイントである。ＭＲ６２０は、ＭＡＰ６３０にてローカル登録を行う。このことは、ＢＣＥ６６１、ＢＣＥ６６２、ＢＣＥ６６３の第１行目のエントリにて示されている。その後、ＭＲ６２０はＲＡ６８３を送信するが、このＲＡ６８３では、ＭＡＰ６３０オプションのみを送信する。このことはパケット６８０から見て取れる。このパケット６８０は、ＡＲＯパラメータ及び／又はいくつかのプレフィックス・パラメータを有していてもよい。

そのようなＲＡ６８３を受信する際、サブシナリオ１のＶＭＮ６１０は、まず、ＭＡＰ６３０オプションを処理し、ＢＣＥ６６１にてローカル登録を行う。ここで作成されたエントリは、ＢＣＥ６６１の第２行目のエントリにより示されている。ＢＣＥ６６１から、ＶＭＮ６１０のＲＣｏＡはＡＲＯ機構により容易にトレース可能であることが分かる。そのため、ＣＮ６５０から受信するデータ・パケットは、ＭＡＰ６３０にて一つのトンネルにカプセル化される。トンネルの第１宛先アドレスは、ＭＲ６２０のＬＣｏＡとなり、その最終的なアドレスは、ＶＭＮ６１０のＬＣｏＡとなる。

上記ＲＡ６８３を受信する際、サブシナリオ２のＶＭＮ６１０は、まず、ＭＡＰ６３０オプションを処理し、ＢＣＥ６６２にてローカル登録を行う。ここで作成されたエントリは、ＢＣＥ６６２の第２行目のエントリにより示されている。第２行目のエントリを作成後、ＭＡＰ６３０は、ＭＲ６２０のＨｏＡに対する登録を行っていないので、ＡＣＫをＶＭＮ６１０に送信するが、第１宛先アドレスをＭＲ６２０のＨｏＡに設定する。ＭＲ６２０は、これを受信すると、その気付アドレスがＲＣｏＡに設定されているため、ＲＣｏＡによりＡＲＯ登録を送信する。このＡＲＯ再帰エントリは、ＢＣＥ６６２の第３行目のエントリにより示されている。ＭＡＰ６３０は、最適にＶＭＮ６１０のＲＣｏＡに到達するのに必要なすべてのＬＣｏＡを見つけ出すためにインテリジェントなトレースを利用することも可能である。

上記ＲＡ６８３を受信する際、サブシナリオ３のＶＭＮ６１０は、まず、ＭＡＰ６３０オプションを処理し、ＢＣＥ６６３にてローカル登録を行う。この登録により作成されたエントリは、ＢＣＥ６６３の第２行目のエントリにより示されている。第２行目のエントリを作成後、ＭＡＰ６３０は、ＭＲ６２０のＨｏＡに対する登録を行っていないので、ＡＣＫをＶＭＮ６１０に送信するが、第１宛先アドレスをＭＲ６２０のＨｏＡに設定する。ＭＲ６２０は、これを受信すると、登録されたアドレスがＶＭＮ６１０のＨｏＡとＬＣｏＡであるＡＲＯ登録を送信する。このＡＲＯ再帰エントリは、ＢＣＥ６６３の第３行目のエントリにより示されている。ＭＡＰ６３０は、最適にＶＭＮ６１０のＲＣｏＡに到達するのに必要なすべてのＬＣｏＡを見つけ出すために通常のＡＲＯトレース処理を行うことも可能である。

ネスト状態のＮＥＭＯツリーパス内のすべてのＭＮ及びＭＲを一つのＭＡＰに接続することで、ネスト状態のＮＥＭＯツリーパス内のＭＮ又はＭＲに対応するＲＣｏＡに最適に到達するのに必要なすべてのＬＣｏＡをトレースすることができる（分割キャッシュ問題なし）ことは当業者であれば十分に理解し得るものである。そのため、ＣＮ６５０からのデータ・パケットは、図６にメッセージ・セグメント６８５、６８４で示される最適経路を介して移動する。

図３、図４Ａ乃至図４Ｃ、図５Ａ乃至図５Ｃに示す方法と比較すると、本実施形態の方法の主な問題は、ネスト状態のＮＥＭＯ（単一のルートＭＲを持つネスト状態のＮＥＭＯを想定）内のすべてのＭＮ及びＭＲは、一つのＭＡＰを選択し、ネスト状態のＮＥＭＯのノード（ネスト状態のＮＥＭＯの多数のノード）の分布がＭＡＰドメイン内でローミングしているＮＥＭＯの間で一様ではない。そのため、ＭＡＰクラウド６７１内のいくつかのＭＡＰが酷使されてしまう場合があり、ＭＡＰ障害が発生することもある。一方、ＭＡＰにかかる負荷が非常に軽い場合（場合によっては、優先値によりＭＲ６２０に通知される）、本実施形態の方法は有用である。

ネスト状態のＮＥＭＯが非常に輻輳した状態である場合、ＭＲは、図３又は図４Ａ乃至図４Ｃに示す方法から、図６に示す方法へ、モードを切り替えてもよい。この場合、ＭＲには２つの機構が実装されることになる。ネスト状態のＮＥＭＯが輻輳状態である場合、無線ドメインを介したオンデマンド二重登録はあまり効率的ではなく、図６に示す方法が有用である。

本発明のさらに別の好適な実施形態では、図６のＭＲ６２０は、（おそらく同一ＭＡＰドメイン内の）別のＭＡＰに向かって移動していると認識した場合、ＭＡＰ６３０であるその現在のＭＡＰにヒントを与えることができる。このような場合、ＭＡＰ６３０は、ＭＲ６２０にルートされたネスト状態のＮＥＭＯのノードに対応するすべてのＲＣｏＡ値を転送し、新しいＭＡＰに、そのＲＣｏＡ値に対して二重アドレス検出（ＤＡＤ）を行うよう要求する。新しいＭＡＰは、ＤＡＤを実行する前に、明らかに、上記ＲＣｏＡプレフィックスを、自身のアドレス・プレフィックスへと変更する必要がある。新しいＭＡＰリンクにアドレス・クラッシュが存在しない場合、これをＭＡＰ６３０に通知する。ＭＲ６２０にルートされたネスト状態のＮＥＭＯに対応するすべてのＢＣＥは、ＭＡＰ６３０から新しいＭＡＰへと転送することができる。ＭＲ６２０にルートされたネスト状態のＮＥＭＯのノードは、新しいＭＡＰでさらなるローカル登録を行わなくてもよい。それらは新しいＭＡＰアドレス・プレフィックスさえ分かればよく、新しいＭＡＰには今後のＬＣｏＡの変更のみが登録されればよい。このような転送は、ＭＡＰ６３０が過負荷の状態でも行うことができる。ネスト状態のＮＥＭＯに対してＭＡＰが変更されると、ＭＮのＬＣｏＡとネスト状態のＮＥＭＯのＭＲが変更されなくても、多くの新しいローカル登録を行わなければならないので、この方法は有用である。この方法は、このようなローカル登録の集中発生も防止する。この方法では、新しいＭＡＰへの転送を行う前のＭＡＰによりローカル登録が行われ、ＭＡＰの変更はネスト状態のＮＥＭＯのノードに通知される。

本発明のさらに別の好適な実施形態では、主要な発明の変更例を説明する。この変更例を、図７を参照してさらに詳しく説明する。図３、図４Ａ乃至図４Ｃにて説明した主要な発明では、オンデマンド二重登録は、非常に混雑したネスト状態のＮＥＭＯにおいて、シグナリング負荷を大幅に増大させることが分かった。図５Ａ乃至図５Ｃに示すネットワーク・サポート解決法でさえ、ＭＲは、その選択したＭＡＰに、ローカルＢＵ内のＭＡＰアドレスを付与する必要があることが明らかとなった。このネットワーク・サポート解決法はまた、無線帯域幅の相当部分を占有する。本実施形態では、従来技術で概説された経路の準最適性問題に対する完全なネットワーク・ベースの解決法を説明する。

図７では、ＶＭＮ７１０がＭＲ７２０に接続され、ＭＲ７２０がＭＲ７２１に接続される。ＭＲ７２１は、ローカル・モビリティ管理ドメイン７７１に接続され、ローカル・モビリティ管理ドメイン７７１はインターネット７７０に接続される。ＭＡＰクラウド又はローカル・モビリティ管理ドメイン７７１は、複数のＭＡＰを有するとする。ＭＲ７２１は、ＲＡを介して、ＭＡＰ７３０とＭＡＰ７３１からＭＡＰオプションを受信する。こうして受信したＲＡパケットは７８１に示される。ＭＲ７２１はＭＡＰ７３１オプションを利用してそのＲＣｏＡを設定し、ＭＡＰ７３１にてローカル登録を行う。ＢＣＥ７６２に、ＭＡＰ７３１のバインディング・キャッシュを示す。ＭＡＰ７３１で行われる上記ローカル登録は、ＢＣＥ７６２の第１行目のエントリにより示される。次に、ＭＲ７２１は、そのＲＡ７８２を送信する。このＲＡ７８２は、７８０で示されるようなパケット構造を有している。ＭＲ７２０はこのＲＡを受信し、ＭＡＰ７３１を利用してそのＲＣｏＡを設定ものとする。ＭＲ７２０は、ＬＣｏＡとＲＣｏＡを得ると、ＭＡＰ７３１にてローカル登録を行う。この登録エントリは、ＢＣＥ７６２の第２行目のエントリにて示される。このようなローカル登録の後、ＭＲ７２０はＲＡ７８３を送信する。このＲＡは７８０に示すものと同様の構造を有している。ＶＭＮ７１０は、ＭＡＰ７３０オプションを処理し、そのローカル登録をＭＡＰ７３０に送信する。本実施形態では、ホーム・エージェントで行われるグローバル登録については明記しないが、当業者であれば容易に理解し得るものである。

ＶＭＮ７１０がＭＡＰ７３０でローカル登録を行うと、ＭＡＰ７３０で作成されたエントリがＢＣＥ７６１に示される。ＶＭＮ７１０は、ＣＮ７５０と、ローカル・モビリティ管理ベースのＲＯを行っているものとする。従って、ＶＭＮ７１０は、ＣＮ７５０と、ＲＣｏＡをその気付アドレスとして、ＲＲ及びＭＩＰｖ６ＢＵを実行するものとする。ＣＮ７５０におけるＢＣＥはＢＣＥ７６０である。

本実施形態では、ＭＡＰクラウド７７１の任意のＭＡＰには、そのバインディング・キャッシュが十分なものであるか否か、若しくは、対応するエントリを得るにはどのＭＡＰにクエリーを行えばよいかを調べる機能が備わっていないものとする。また、各ＭＡＰはドメイン内の他のすべてのＭＡＰを把握しているものとする。この方法では、新しい、又は、更新されたバインディング・キャッシュ・エントリが、各ＭＡＰからドメイン内のその他すべてのＭＡＰに送信されるものとする。このＢＣＥ転送のフラッディングは、シグナリング・メッセージ７８６により示される。このような転送７８６の後、すべてのＭＡＰのバインディング・キャッシュ・エントリが同じになる。転送７８６の後、ＢＣＥ７６１が確実にＭＲ７２０とＭＲ７２１のすべてのエントリを持つことは容易に理解し得る。このような場合、ＶＭＮ７１０のＲＣｏＡがＭＡＰ７３０にて完全にトレース可能であることは当業者にも明らかである。しかし、この方法では、ノードがドメイン内（ドメインそのものが大きく多くのＭＮ及びＭＲを含む可能性がある）でローミングを行う間、ＭＡＰには不要な二重の永続的なエントリが作成されるということも明らかである。これがこの方法の欠点である。ＣＮ７５０がＶＭＮ７１０にデータ・パケットを送信すると、パケットはＭＡＰ７３０で受信され、ＶＭＮ７１０への単一のトンネルにカプセル化される。ＶＭＮ７１０とＣＮ７５０の間の経路最適化データパスは、図７のパス・セグメント７８４、７８５により示されている。

本発明のさらに別の好適な実施形態では、図７の方法に加えられる小さな変更について説明する。ＭＡＰクラウド７７１のすべてのＭＡＰは、最初は、ＭＡＰドメイン内のすべてのＭＡＰのすべてのＲＣｏＡエントリを持っている。すべてのＭＡＰは、ＲＣｏＡをトンネリングするのに使われるバインディング・キャッシュ・エントリを特定・分類できる機能を利用し、特定されたこれらのエントリを転送したＭＡＰを見つけ出す。使われていない、若しくは、使われることのないエントリについては、ＭＡＰは、そのような未使用のエントリを転送したＭＡＰに、しばらくはエントリを転送しないように要求する。ＭＡＰは、そのような要求シグナリングを行うため、どのエントリがどのＭＡＰによって転送されたかを監視する必要がある。ＭＡＰは、メッセージ７８６の送信元アドレスを監視することで、未使用エントリを送信したのはどのＭＡＰであるかを把握することができる。

本発明の別の好適な実施形態では、ネスト状態のＮＥＭＯツリーパス内のＭＮ及びＭＲがｎ個のＭＡＰの中から一つのＭＡＰを選択し、選択したＭＡＰにて登録を行う方法を開示する。本実施形態では、図７に示すようなＭＡＰ間におけるＢＣＥのフラッディングが発生しないが、それぞれのＭＡＰは、ＭＡＰで処理されたパケットの送信元アドレスを調べることでどのＭＡＰエントリが必要かを監視する。ＭＡＰの持つエントリが、そこから得られたＲＣｏＡに対応するＬＣｏＡを見つけるのに不適切である場合、パケットが他のＭＡＰからそのＭＡＰに届く（ＭＡＰ間ピンポン）。他のＭＡＰからそのＭＡＰへパケットが届くと、そのＭＡＰはその他のＭＡＰに、それぞれの登録エントリを送信するよう要求するものとする。こうして、上記ＭＡＰは、そこから得られたＲＣｏＡをトレースするためのすべてのエントリを手に入れることができ、ＭＡＰ間のピンポン準最適経路を除去することができる。本実施形態に概説された方法を用いることで、図７に示すような永久的な二重登録を生じさせずに、上記準最適ルーティングを解消することができる。別の方法では、ＭＲは、ＭＡＰを選択し、選択したことを、ＲＡを介してそのＭＡＰに通知することができる。ネスト状態のＮＥＭＯツリーパス内の下流のＭＲは、この情報を受け取ると、上流のＭＲのＭＡＰを見つけ、この情報（上流のＭＲのＭＡＰアドレス）を自身のＭＡＰへ送信できる。下流のＭＲのＭＡＰは、上流のＭＲのＭＡＰに、（ＭＡＰアドレスを知っているため）それらのエントリを転送するよう要求することができる。こうして、ＭＡＰ間のピンポン準最適ルーティングが解消される。

以上、複数ＭＡＰシナリオでのネスト状態のＮＥＭＯにおける経路の準最適性問題を解消するための主要な発明及びその変更例を説明してきた。実施形態で説明された２つの主要な方法において、第１の方法は、端末（ＭＲ）の登録の他のＭＡＰでの二重登録であり、第２の方法は、ネットワークドメインで行われる転送による二重登録であることが分かる。次に、別のシナリオでの特定の問題解決に上記のような二重登録が有用であるいくつかのシナリオを見てみよう。

現在、ローカル・モビリティ管理では、ＮｅｔＬＭＭドメインが注目を集めている。ＮｅｔＬＭＭドメインでは、ローカル・モビリティ管理シグナリングが完全に固定ネットワークを介して行われており、ローミングするＭＮ／ＭＲは、その気付アドレスの変更どころかＮｅｔＬＭＭドメイン内で移動していることも認識していない。このようなドメインでは、ロードバランシングのため、複数のローカル・モビリティ・アンカー（ＬＭＡｓ）を配備するのが一般的である。非特許文献７に開示されているようなプロキシ・モバイルＩＰｖ６ドメインと呼ばれる別のドメインでは、プロキシ・モバイル・アンカー（ＰＭＡ）は、ローミングしているＭＮ／ＭＲ／ＩＰｖ６ホストの代わりに、プロキシＭＩＰｖ６シグナリングをプロキシ・ホーム・エージェント（ＰＨＡ）へ送信する。このようなプロキシＭＩＰｖ６ドメインでも、ロードバランシングのために、複数のプロキシ・ホーム・エージェントを配置することができる。プロキシ・モバイル・ＩＰｖ６ドメインは、ＮｅｔＬＭＭドメインに類似したドメインであるが、その主な目的は、ホーム・ドメイン内でローミングするＩＰｖ６ホストへモビリティ・サービスを拡大することにある。次に、ＭＲから始まる上記二重位置登録と、前述の実施形態に説明された位置登録のＭＡＰ間転送とが、ＮｅｔＬＭＭドメインやプロキシＭＩＰｖ６ドメインのいくつかの問題解決にどのように有用であるかを考察してみる。

以下の実施形態では、ＮｅｔＬＭＭドメインにおいて、ＭＮの代わりに、通常ＡＲに実装されるＭＡＧ機能により、位置管理シグナリングを行うこととする。非特許文献６に開示されるようなＭＡＧ機能は、ＰＭＩＰクライアントの中心に位置することもできる。このような場合、ＰＭＩＰクライアントは、ローカルＢＵをＬＭＡに送信し、ＭＮ識別子又はＭＮの気付アドレスを、（そのＭＮが現在接続されている）ＡＲのアドレスに結合する。ローカルＢＵは、ＰＭＩＰクライアント機能を有するＡＲによっても送信できることは当業者であれば十分理解し得る。非特許文献７に開示されているプロキシＭＩＰｖ６ドメインでは、ＭＡＧ機能を、プロキシＭＩＰｖ６エージェントに配置することができる。ここでは、上記エージェントは、プロキシ・ホーム・エージェントにてプロキシ登録を行う。このプロキシ・ホーム・エージェントは、ＮｅｔＬＭＭドメインのＬＭＡに類似している。

本発明のさらに別の好適な実施形態では、ロードバランシングのため、ＬＭＡ間で位置エントリ転送を行う方法を開示する。この方法は図８を参照しさらに詳しく説明する。図８では、ＭＮ８１０がＮｅｔＬＭＭドメイン８４１内でローミングしている。ＮｅｔＬＭＭドメイン８４１はさらにインターネット８４０に接続されていることとする。ＭＮ８１０は、モビリティ・アクセス・ゲートウェイ（ＭＡＧ）８２０に直接接続されている状態である。ＭＡＧ８２０は、ローミングしているＭＮ８１０がリンクやサブネットワークにおける変更に気付かないようにする特別な機能を有するＡＲである。ＮｅｔＬＭＭドメイン８４１はＬＭＡ８３０、ＬＭＡ８３１、ＬＭＡ８３２をそのアーキテクチャに備え、これらすべてのＬＭＡは固定リンク８６０により接続されていることとする。また、ＭＡＧ８２０は、固定リンク８６１、８６２それぞれを介してＬＭＡ８３０、ＬＭＡ８３１に直接接続されており、ＭＡＧ８２１は固定リンク８６３を介してＬＭＡ８３１に接続されていることとする。さらに、ＭＡＧ８２０は、ＬＭＡ８３０、ＬＭＡ８３１の両方からプレフィックスを受信するが、そのＲＡ８７０での送信用にはＬＭＡ８３１からのプレフィックスを選択することを決定する。この場合、ＭＮ８１０はＬＭＡ８３１のプレフィックスから気付アドレスを設定する。さらに、ＭＡＧ８２０はＬＭＡ８３１にてローカル登録を行い、これが図８の８７１で示される。この登録により、ＭＮ８１０の気付アドレスがＭＡＧ８２０のアドレスと結合する。

このようなシナリオでは、ＬＭＡ８３１は、ＬＭＡ８３０の使用法についての情報を持っており、それがあまり使用されていないことを把握できることもある。この情報を得るためデータベースにクエリーを行うことが好ましい。このような場合、ＬＭＡ８３１は、（ロードバランシングのために）ＭＡＧ８２０からのエントリを含むそのエントリのいくつかをＬＭＡ８３０へ転送してもよい。この転送は、図８のメッセージ８７２に示されている。上記転送は、ＬＭＡ８３１がそのエントリを削除し、転送又はエントリのコピーをとり、その後転送を行うといった完全な転送であってもよい。ＭＮ８１０の関連性のための、ＭＡＧ８２０及びＬＭＡ８３１に対応するセキュリティ・キーもＬＭＡ８３０に転送されることとする。この場合、ＬＭＡ８３０は、ＬＭＡ８３１に送信されるパケットを捕まえるためにいくつかの経路を投入しなければならない、若しくは、それがデフォルトパス内にある場合、転送されたアドレスに届いたパケットを調べ、それらのパケットをＭＡＧ８２０へとトンネリングすることもできる。捕獲されたパケットがＬＭＡ８３０にとって興味のあるものでない場合（宛先アドレスは転送されたエントリと同じではない）、パケットはＬＭＡ８３１へとルーティングされる。このことは当業者であれば容易に理解し得ることである。

ＭＮ８１０がＣＮ８５０にてＭＩＰｖ６登録を行ったものとする。ＣＮ８５０は、ＭＮ８１０にデータ・パケットを送信し、宛先アドレスを、ＬＭＡ８３１のプレフィックスから導出した値に設定する。ＬＭＡ８３０は、このデータ・パケットを捕獲し、ＭＡＧ８２０へのトンネルにカプセル化する。ＭＡＧ８２０は、このデータ・パケットをデカプセル化し、ＭＮ８１０へパケットを転送する。固定ＮｅｔＬＭＭリンクを介してＬＭＡ８３１及びＬＭＡ８３０に作成した二重エントリにより、ロードバランスを保つことができ、また、ＬＭＡ８３１は膨大な量のデータ・パケットに対してトンネリングを行う必要がなく、その結果処理負荷を軽減することができるということを理解することは重要である。ＬＭＡ８３１−ＬＭＡ８３０間の転送後のデータ・パケット・ルーティング・パスは、図８の８７３にて示される。

図８では、ＮｅｔＬＭＭドメインはプロキシＭＩＰｖ６ドメインであってもよく、ＬＭＡはプロキシ・ホーム・エージェントであってもよく、ＭＡＧはＰＭＡであってもよい。本実施形態のそのようなＬＭＡ間転送は、同様の目的で（ＰＨＡ間のロードバランス）、プロキシＭＩＰｖ６ドメインでのプロキシ・ホーム・エージェント間転送にも適用可能であることは容易に理解し得る。

本発明のさらに別の好適な実施形態では、重要性の高いデータの転送の信頼性を上げる目的で、ＮｅｔＬＭＭ固定リンクを介して、複数のＬＭＡにおいて二重登録が行われている。この二重登録は、バイキャスティング目的で行われ、ＮｅｔＬＭＭドメインの固定リンクが輻輳している場合、バイキャスティングは重要なデータの転送に欠かせないものであることは当業者にも十分理解されるであろう。このことは図９を参照してさらに詳しく説明する。図９では、ＭＮ９１０がＭＡＧ９２０に接続され、ＭＡＧ９２０が固定リンク９６０を介してＬＭＡ９３０及びＬＭＡ９３１に直接接続されている。ＭＮ９１０は、ＣＮ９５０とデータ通信セッション中であり、このデータ情報は非常に重要であり、パケット・ロスは最小限で、データ配信がタイムリーであることが必須であることとする。

このようなシナリオでも、ＭＡＧ９２０はＬＭＡ９３０のプレフィックスをＲＡ９７０で送信する。さらに、ＭＡＧ９２０は、ＬＭＡ９３０にてローカル登録を行い、これが図９のメッセージ９７１にて示されている。信頼性のためにＭＮ９１０に関連する内容をＬＭＡ９３１に転送する必要があるといったいくつかのヒントは（９７１を介して）ＬＭＡ９３０に転送され、それによりデータ・トラフィックのバイキャスティングが達成される。ＬＭＡ９３０は、そのような転送又は二重登録を行い、これがメッセージ９７２により示される。ＬＭＡ９３０は、バイキャスティングを実現可能なように、ＬＭＡ９３１への転送後もエントリを保持する。

ＣＮ９５０がデータ・パケットをＭＮ９１０に送信すると、このデータ・パケットは、ルーティング階層の上部にあるため、若しくは、パケットを得るため経路を投入したため、最初にＬＭＡ９３１に到達する。いずれの場合も、ＬＭＡ９３１はパケットを複製し、そのパケットをＬＭＡ９３０へさらにルーティングする。続いて、データ・パケットの一つのバージョンはＬＭＡ９３１からＭＡＧ９２０へとトンネリングされ、ＬＭＡ９３０に送信された他のバージョンは、ＬＭＡ９３０からＭＡＧ９２０へとトンネリングされる。このバイキャスティングは、図９の９７５及び９７４に示されている。ＭＡＧ９２０はトンネリングされたパケットをデカプセル化し、それをさらに９７６を介してＭＮ９１０へとルーティングし、そこでパケットはＭＮ９１０により処理される。

本発明のさらに別の好適な実施形態では、ＮｅｔＬＭＭドメインに固定リンクの不具合がある場合でもデータ・パケットを取得する目的で、二重登録が複数のＬＭＡで行われる。図１０にこの方法を示し、本実施形態でさらに詳しく説明する。図１０では、ＭＮ１０１０は、ＭＡＧ１０２０に接続され、ＭＡＧ１０２０は、固定リンク１０６１、１０６２それぞれを介してＬＭＡ１０３０、ＬＭＡ１０３１に接続される。ＮｅｔＬＭＭドメイン１０４１には、ＬＭＡ１０３０、ＬＭＡ１０３１、ＬＭＡ１０３２の３つのＬＭＡがある。これらのＬＭＡは固定リンク１０６０により相互に接続されている。

ＭＡＧ１０２０は、ＲＡ１０７０でＬＭＡ１０３０のプレフィックスを送信し、ＭＮ１０１０は、ＬＭＡ１０３０のプレフィックスを使って気付アドレスを設定する。続いて、ＭＡＧ１０２０は、ＬＭＡ１０３０でＭＮ１０１０の代わりにローカル登録を行う。しばらくしてから、ＭＡＧ１０２０は（リンクの断絶若しくは輻輳により）リンク１０６１からのパケットの取得を停止する。ＭＡＧは、そのＲＡ内のＬＭＡ１０３０のプレフィックスを使用し続けることを判断するが、ＬＭＡ１０３１を介してＬＭＡ１０３０にてローカル登録を行う。ＭＡＧ１０２０は、リンク１０６１が断絶又は輻輳状態にあるといったヒントをＬ２から取得し、この別の方法を使うことを決定してもよい。ＬＭＡ１０３０へのローカル登録は、ＬＭＡ１０３１を介してトンネリングされ、これが図１０のメッセージ１０７１に示されている。ＬＭＡ１０３１は、このローカル登録メッセージにデトンネリングを行い、好ましくは、登録パラメータのコピーを取った上で、ＬＭＡ１０３０へメッセージをルーティングする。さらにルーティングされたメッセージは、図１０の１０７２に示されている。ＬＭＡ１０３０は、転送されたエントリに対しＤＡＤを実行し、ローカルＡＣＫをＬＭＡ１０３１へ送信することができ、ＬＭＡ１０３１はこれをＭＡＧ１０２０に転送する。このメッセージは、ＭＡＧ１０２０へ送信されるようＬＭＡ１０３１にトンネリングされる、若しくは、ＡＣＫの内容がＬＭＡ１０３１に送信され、ＬＭＡ１０３１はローカルＡＣＫを設定する。上記処理を行う方法は数多くあり、当業者であれば容易に想到しうる。二重登録は、両方のＬＭＡ（ＬＭＡ１０３０及びＬＭＡ１０３１）にて行われる。将来的には、エントリの更新の際、ＬＭＡ１０３１はＬＭＡ１０３０に要求する必要がなくなり、ただ単に、ＬＭＡ１０３０の代わりにＡＣＫを送信すればよい。

本実施形態では、ＬＭＡ１０３０は、過負荷状態ではないものとされるので、ＣＮ１０５０から送信されてくるデータ・パケットを受信し続けることができる。さらに、ＬＭＡ１０３１は、ＬＭＡ１０３０のプレフィックスから導出したパケットを捕獲するために経路を投入する必要がないものとする。

さらに、ＭＮ１０１０は、ＣＮ１０５０にてＲＲ及びＭＩＰｖ６登録を行うものとする。データ・パケットはＬＭＡ１０３０に到達し、このメッセージが図１０の１０７３に示されている。ＬＭＡ１０３０は、ＬＭＡ１０３１への次のホップを設定し、データ・パケットをトンネリングする。このメッセージは１０７４により示される。ＬＭＡ１０３１は、デトンネリングを行い、パケットをＭＡＧ１０２０へ送信する。ＬＭＡ１０３１は、ＭＮ１０１０に対応するエントリを持っているので、そのＢＣエントリをパケットのトンネリングに利用することができるということは容易に理解し得る。従って、リンクが断絶又は輻輳状態であっても、二重エントリを維持することで、ＭＮ１０１０はパケットを受信し続けることができる。

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

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

Claims (4)

1. ＶＭＮ、ＭＲ，ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムであって、
   前記ＶＭＮ及びＭＲは、ＡＲＯとあるＨＭＩＰｖ６のＲＯ対応プロトコルとを実装しており、
   ローカル・モビリティ管理ドメイン・アーキテクチャ内に複数のＭＡＰが存在し、前記ＭＡＰには、前記ＶＭＮ、ＭＲと同様に、あるＨＭＩＰｖ６のＲＯ機能が実装されており、
   ネスト状態のＮＥＭＯ内のＭＲは、それが接続されているＭＡＰに関係なく、ネスト状態のＮＥＭＯツリーパス内のその下流のＭＲ及びＶＭＮのＭＡＰにて登録を行うシステム。
2. ＶＭＮ、ＭＲ，ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムであって、
   前記ＶＭＮ及びＭＲは、ＡＲＯとあるＨＭＩＰｖ６のＲＯ対応プロトコルとを実装しており、
   ローカル・モビリティ管理ドメイン・アーキテクチャ内に複数のＭＡＰが存在し、前記ＭＡＰには、前記ＶＭＮ、ＭＲと同様に、あるＨＭＩＰｖ６のＲＯ機能が実装されており、
   ネスト状態のＮＥＭＯ内のＭＲは、そのネスト状態のＮＥＭＯツリーパス内のＭＮ及びＭＲが利用可能なすべてのＭＡＰオプションに関する情報を有しており、そのローカル・バインディング・アップデート内のその他のＭＡＰアドレスを、選択したＭＡＰに添付するシステム。
3. ＡＲＯとあるＨＭＩＰｖ６のＲＯ対応プロトコルとを実装した移動ルータであって、
   ローカル・モビリティ管理ドメイン・アーキテクチャ内に複数のＭＡＰが存在し、前記ＭＡＰには前記移動ルータと同様に、あるＨＭＩＰｖ６のＲＯ機能が実装されているネットワークに接続可能な上流ネットワーク・インターフェースと、
   ネスト状態のＮＥＭＯツリーパス内の、ＡＲＯといくつかのＨＭＩＰｖ６のＲＯ対応プロトコルとを実装した下流のＭＲ及びＶＭＮに接続可能な下流ネットワーク・インターフェースと、
   前記移動ルータが接続されているＭＡＰに関係なく、ネスト状態のＮＥＭＯツリーパス内における自身の下流のＭＲ及びＶＭＮのＭＡＰにて登録を行う登録部とを具備する移動ルータ。
4. ＡＲＯとあるＨＭＩＰｖ６のＲＯ対応プロトコルとを実装した移動ルータであって、
   ローカル・モビリティ管理ドメイン・アーキテクチャ内に複数のＭＡＰが存在し、前記ＭＡＰには前記移動ルータと同様に、あるＨＭＩＰｖ６のＲＯ機能が実装されているネットワークに接続可能な上流ネットワーク・インターフェースと、
   そのネスト状態のＮＥＭＯツリーパスが利用可能なすべてのＭＡＰオプションに関する情報を記憶する情報記憶部と、
   そのローカル・バインディング・アップデート内のその他のＭＡＰアドレスを、選択したＭＡＰに添付する情報添付部とを具備する移動ルータ。

Images