(57)【要約】  【解決手段】  アクセス・ルータ・オプション・プロトコル及び階層モビリティ管理プロトコルなどのエンド・ツー・エンド経路最適化プロトコルが訪問移動ノード、移動ルータ、モビリティ・アンカー・ポイントに実装される将来的なシナリオにおいて、ネストされた訪問移動ノードが通信相手ノードと通信を行おうとする場合にルーティング準最適性が生じる。本発明は、そのような異種プロトコルシナリオにおいて発生するルーティング準最適性問題を克服するため、訪問移動ノードに関連するローカル気付アドレスと訪問移動ノードの上流移動ルータに関連するローカル気付アドレスとが、一回のアクセス・ルータ・オプション・プロトコルタイプの再帰的トレースメカニズムにより得られるよう、モビリティ・アンカー・ポイントにて登録が行われる、主要なメカニズムを提供する。そのようなトレースは、モビリティ・アンカー・ポイントでのアクセス・ルータ・オプションベースのバインディング登録に異なる種類のアドレスを組み込むことで達成される。
2010541304.tif 000002
【特許請求の範囲】
【請求項１】
ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを備える通信ノードのシステムであって、
ＶＭＮ、ＭＲ、ＨＡはＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡはＡＲＯプロトコルを実装し、
ＭＲにより送信されるルータ通知には２種類のＡＲＯオプションが含まれ、一つはＭＲのホーム・アドレスが送られるＡＲＯオプションであり、もう一つはＭＲがそのＲＣｏＡを送信するＡＲＯオプションであり、
ＶＭＮとＭＲはさらに処理を行うためＲＣｏＡを含むＡＲＯオプションを利用するシステム。
【請求項２】
ＶＭＮとＭＲがＭＡＰに登録を行う際、ＡＲＯオプション内のＲＣｏＡ値を使用する請求項１に記載のシステム。
【請求項３】
請求項１に記載のＶＭＮに使用される装置。
【請求項４】
請求項１に記載のＭＲに使用される装置。
【請求項５】
請求項１に記載のＭＡＰに使用される装置。
【請求項６】
ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを備える通信ノードのシステムであって、
ＶＭＮ、ＭＲ、ＨＡはＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡはＡＲＯプロトコルを実装し、
ＭＲにより送信されるルータ通知には１種類のＡＲＯオプションしか含まれず、そのＡＲＯオプションは移動アクセス・ルータのホーム・アドレスを定義し、
ＶＭＮとＭＲとがＢＣＥのエントリを用いてＡＲＯオプションとＭＡＰオプションの両方を処理する場合、ＭＡＰは一段階のトレースによってＶＭＮのＲＣｏＡに関連するＬＣｏＡが得られるようなインテリジェント・トレースを行うシステム。
【請求項７】
ＭＡＰがインテリジェント・トレースを行うためのインテリジェント・トレース部を実装する請求項６に記載のＭＡＰに使用される装置。
【請求項８】
請求項６に記載のＭＡＰがインテリジェント・トレースを行うために使用する方法。
【請求項９】
請求項６に記載のＭＲがデータ・パケットを逆方向に送る際、ＲＣｏＡではなくＬＣｏＡにアドレス・スワップを行うために使用する代替方法であって、
ＭＲはＮＥＭＯ−ＦＷＤオプションを見つけた場合にそのようなスワップを行う代替方法。
【請求項１０】
請求項６に記載のＭＡＰがイングレス・インターフェースを介して受信するパケットのデトンネリングを行うために使用する代替方法であって、
トンネル除去処理を行うためにインテリジェント・トレース・メカニズムが拡張される代替方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換データ通信ネットワークにおける電気通信分野に関し、特に、エンド・ツー・エンド型経路最適化プロトコル及び階層化モビリティ管理プロトコルが実装された移動ノードに最適経路を提供することに関する。
【背景技術】
【０００２】
今日、多くのデバイスは、インターネット・プロトコル・バージョン６（ＩＰｖ６）を用いて相互に通信を行っている。モバイル機器のモビリティ・サポートを提供するために、インターネット技術調査会（ＩＥＴＦ）は、「ＩＰｖ６でのモビリティ・サポート（ＭＩＰｖ６）」[非特許文献１]を作成した。[非特許文献１]におけるモビリティ・サポートは、ホーム・エージェント（ＨＡ）と呼ばれるホーム・ネットワークにおけるエンティティの導入により行われる。移動ノード（ＭＮ）は、バインディング・アップデート（ＢＵ）と呼ばれるメッセージにより、ホーム・エージェントに、外部リンク内でＭＮが入手する自身の気付アドレスを登録する。このＢＵにより、ホーム・エージェントは、ホーム・リンク内で入手した長期アドレスであるホーム・アドレスと、移動ノードの気付アドレス間でバインディングを生成できる。ホーム・エージェントは、移動ノードのホーム・アドレス宛てのメッセージを受信し、パケットのカプセル化（すなわち、１つのパケットを新しいパケットのペイロードにすることであり、パケット・トンネリングとも呼ばれる）により、移動ノードの気付アドレスにパケットを転送する。また、ＭＩＰｖ６は、通信相手ノード（ＣＮ）との通信の際の経路最適化（ＲＯ）方法を定める。このＲＯメカニズムにより、ＭＮとＣＮがＭＮのホーム・エージェントを経由せずにＭＮの気付アドレスにより相互に通信を行うことができるよう、ＭＮはＣＮにおいてその気付アドレスの有効な登録を行うことができる。ＣＮでは、ＭＮによって開始されるリターン・ルータビリティ（ＲＲ）テストにより、ＭＮの気付アドレスの有効な登録が行われる。このリターン・ルータビリティ・テストにより、ＣＮは、ＭＮの気付アドレスとＭＮのホーム・アドレスとが結び付けられているという証明を得ることができる。上記ＲＯメカニズムは任意のものであり、ＣＮがＲＯメカニズムをサポートする何らかの機能性を有する場合にのみその利点が発揮されることとなる。
【０００３】
ＭＩＰｖ６の問題点の一つとして、ＭＮは、ネットワーク接続におけるたった一つの変更に対し、一つ又は複数のホーム・エージェント及び一つ又は複数の通信相手ノードを更新しなければならないということが挙げられる。これにより、高速で移動しているＭＮのためにネットワークへ投入されるシグナリング負荷が増大する。また、ネットワーク接続における一つ一つの変更がＲＲ及びＢＵメッセージの送信を伴うため、ネットワーク接続における変更ごとのＣＮとの平均ハンドオフ確立時間は長くなる。そのため、フロー又は接続に関連するセッション中は、かなりの時間がハンドオフの確立に割り当てられ、それによりジッターやパケット・ロスが生じることとなる。上記ジッターは、ボイス・オーバーＩＰ（ＶｏＩＰ）、マルチメディア、ビデオ・ストリーミングなどのアプリケーションに弊害をもたらすものであり、また、上記パケット・ロスは、重要なテキスト情報を運ぶフローに弊害をもたらす。さらに、パケット・ロスは、伝送制御プロトコル（ＴＣＰ）を情報重要データ・アプリケーションに利用する場合、ＴＣＰスループットを低下させる。
【０００４】
そのようなＭＩＰｖ６の問題に対処するため、ＩＥＴＦは、[非特許文献２]に開示されている階層化モビリティ管理プロトコル・バージョン６（ＨＭＩＰｖ６）と呼ばれるプロトコルの標準化を行った。ＨＭＩＰｖ６は、二種類の気付アドレスと、モビリティ・アンカー・ポイント（ＭＡＰ）と呼ばれる新しいノードとを用いる。その基本原理としては、ＭＮは、それが接続されている新しいネットワークにおいて、二つの気付アドレスを取得する。その二つの気付アドレスの内の一方は、ローカル気付アドレス（ＬＣｏＡ）と呼ばれ、ＭＮが直接接続されているネットワークから入手したアドレスである。また、その他方のアドレスは、リージョナル気付アドレス（ＲＣｏＡ）と呼ばれ、ＭＡＰのホーム・ネットワーク・プレフィックスから得られる。ＲＣｏＡは、ＭＮがＣＮ及びＨＡと通信する際に気付アドレスとして用いるアドレスである。ＭＡＰは好ましくはルーティング階層の上位に置かれる固定ルータであるので、このＲＣｏＡは頻繁に変更されることはない。ＭＡＰオプションに組み込まれているＭＡＰアドレスなどのＭＡＰ情報が入手可能なネットワーク・セグメント内でＭＮがローミングする限り、リージョナル気付アドレスが変更されることはない。このプロトコルでは、ネットワーク接続におけるすべての変更についてのハンドオフ確立処理には、主に、ＬＣｏＡが登録されているＭＡＰが用いられる。ＭＮがＭＡＰ外へ移動し、それによりＲＣｏＡが変更される時にのみ、ＭＡＰ、ＣＮ、ＨＡに対して更新又はハンドオフ確立が同時に行われる。従って、ネットワーク接続における変更ごとのネットワークへのシグナリング負荷は、平均して、純粋なＭＩＰｖ６に比べてかなり低い。さらに、ネットワーク接続におけるすべての変更についてのハンドオフ確立時間は、平均して短い。これは、大抵の場合、ハンドオフが、ローミングＭＮにごく接近したところに位置するＭＡＰでの単純なＬＣｏＡ登録だけで済まされるためである。このため、前述のジッターやパケット・ロスなどの問題はここではずっと少ない。このプロトコルは、フローに省電力化を必要とするノード、及び、厳しいクオリティオブサービス（ＱｏＳ）パラメータを求めるフローを運ぶノードに使用される、広く認められた標準プロトコルである。
【０００５】
無線デバイスがますます普及する中、複数のノードからなるネットワーク全体がその接続点を変えるネットワークモビリティ、すなわちＮＥＭＯのような 新しいタイプのモビリティ技術が出現することが予見される。ＩＥＴＦは、[非特許文献３]に開示されている基本的なネットワーク・モビリティ・サポートに対する解決法を開発した。この場合、移動ルータ（ＭＲ）は、ＢＵをホーム・エージェントに送信する際、移動ネットワーク内のノードが使用しているネットワーク・プレフィックスを指定するよう規定されている。これらのネットワーク・プレフィックスは、ＢＵ内に挿入するネットワーク・プレフィックス・オプションと呼ばれる特別なオプションにより指定される。これらにより、ホーム・エージェントは、ホーム・エージェントが、これらのプレフィックスと共に宛て先に送信された任意のパケットを移動ルータの気付アドレスへトンネルするように、プレフィックス・ベースのルーティング・テーブルを作成できる。
【０００６】
ＭＮがＮＥＭＯに深くネストされると、二種類の問題が発生する。一つ目の問題としては、データ多重カプセル化のオーバーヘッドや、データの準最適ルーティングが挙げられる。これは、ネスト状態のＮＥＭＯにおける、ネスト状態のトンネリングに起因する。多重カプセル化は、パケット・サイズの増大に起因するデータ・パケットの遅延を引き起こし、さらに、パケット・フラグメンテーションを招くこともある。さらに、パケット・フラグメンテーションは、データ・パケット・ロスを引き起こすこともある。準最適ルーティングは、データ・パケットの遅延、ネットワーク負荷の増大、ＨＡの処理負荷増大につながる。
【０００７】
二つ目の問題としては、深くネストされたＭＮに対するレイヤ３ハンドオフ確立の大幅な遅延や、ＲＲ及びＢＵストリームのシグナリング・オーバーヘッドに起因してネットワークへ投入される高いシグナリング負荷が挙げられる。これは、ＭＮが深くネストされ、ネットワーク接続に変更があった場合ため、入手した新しい気付アドレスはがＣＮ又はＨＡにて更新する必要があるからである。場合、このような登録には、ハンドオフ登録に関与するパケットが多重にカプセル化され、上流のすべてのＭＲ及びそれらのホーム・エージェントを含むピンボール・ルーティング・パスを移動することにより、大幅な遅延が発生することとなるからである。前述のように、ハンドオフ遅延時間の増加は、高速で移動するＭＮによって運ばれるフローの全セッション又は接続時間に大きく関係し、それによりジッターやパケット・ロスが生じることとなる。さらにまた、一定期間内でのＭＮによる過度のハンドオフ確立シグナリングは、ネットワーク内で運ばれるその他のフローにも影響を及ぼすことになる。
【０００８】
一つ目の問題を解決するため、関連技術分野における、いわゆるネスト状態のトンネルの最適化に関して様々な提案がなされている。具体的には、[非特許文献４]には、アクセス・ルータ・オプション（ＡＲＯ）と呼ばれる解決法が開示されている。送信者（すなわち、移動ルータ又は移動ホスト）は、このアクセス・ルータ・オプションと呼ばれる新しいオプションを使って、受信者（例えば、ホーム・エージェント又は通信相手ノード）に、該送信者が直接接続されているアクセス・ルータの一次グローバルアドレスを知らせる。移動ノードは、アクセス・ルータ・オプションと共にバインディング・アップデート・メッセージを送信後、送信するデータ・パケットに「直接転送要求」シグナルと呼ばれる特別なシグナルを挿入できる。このシグナルにより、上流の移動アクセス・ルータは自身のバインディング・アップデートを宛先アドレスに送信する。この処理は、最上流の移動アクセス・ルータ（通常、アクセス・ネットワークの固定ルータ）に達するまで繰り返される。上流のすべての移動アクセス・ルータがバインディング・アップデートを宛先に送信することで、宛先では、移動ノードが接続されている移動ルータの連鎖を形成できる。これは、拡張タイプ２ルーティングヘッダ（ＲＨ２）の作成に利用できるため、宛先ノードがパケットを移動ノードに送り返したい場合、ルーティング・ヘッダを有するパケットを埋め込むことができ、パケットが移動アクセス・ルータの連鎖を介して移動ノードへ直接転送される。この方法は、エンド・ツー・エンド型経路最適化を、セキュリティーを犠牲にせずに実現するのに適した方法であると考えられる。
【０００９】
二つ目の問題を解決し、一つ目の問題を部分的に解決するため、[非特許文献５]には、ネスト状態のトンネリングやレイヤ３（Ｌ３）ハンドオフ確立の遅延などの問題への対処法する設計が開示されている。この方法では、ハンドオフ効率及びシグナリング・オーバーヘッドの改善、ＭＡＰ環境においてネストされたＭＮのエンド・ツー・エンド型経路最適化の適切な実行を図る。この方法において、すべてのＭＮ（本稿では移動ホストとする）は、ＨＭＩＰｖ６で規定された通りに動作する。ＭＮは、ローカル・ネットワーク接続におけるそれぞれの変更については、そのＬＣｏＡをＭＡＰにて更新し、ＲＣｏＡ又はＭＡＰドメインにおけるそれぞれの変更については、そのＣＮとＨＡに対してＲＣｏＡを更新する。この方法では、ＭＲは、ＭＮに対し、ＨＭＩＰｖ６プロトコルで規定された通りに動作するが、若干の変更も伴うものとする。ＭＲは、ルータ・モードで動作する場合、そのルータ通知（ＲＡ）におけるＭＡＰオプションを通知し、それに接続されているＭＮやＭＲへとＭＡＰサービスを拡大する。さらに、ＭＡＰがＭＮのＬＣｏＡに到達する最適経路をトレースするのを助けるため、ＭＲは、純粋なＨＭＩＰｖ６タイプの登録の代わりに、ＭＡＰにてプレフィックス・スコープ・バインディング・アップデート（ＰＳＢＵ）を行う。ＭＮがいくつかのＭＲの配下に深くネストされているとすると、ＭＡＰのバインディング・キャッシュは、ＭＮのＬＣｏＡとＲＣｏＡのほかに上流のＭＲのＬＣｏＡ、ＲＣｏＡ、ＭＲのプレフィックスも有することとなる。ＭＡＰが、ＭＮの上流のＭＲに関連するすべてのＬＣｏＡの位置を特定するのに、このプレフィックスをいかに利用可能であるかは当業者には公知である。このようなトレースが可能であるのは、ＭＮ又はＭＲのＬＣｏＡがそのアクセス・ルータのプレフィックスから得られているからである。
【００１０】
宛先アドレスが、ＭＮに関連するＲＣｏＡであるのＭＡＰにデータ・パケットが到着すると、ＭＡＰは、まず、そのバインディング・キャッシュ（ＢＣ）内でのこのＲＣｏＡの位置を特定し、その後、バインディング・キャッシュ・エントリ（ＢＣＥ）からそのＲＣｏＡに関連する対応ＬＣｏＡを見つけ出す。続いて、ＭＡＰは、このＭＮのＬＣｏＡに一致するプレフィックスを検索する。これにより、ＭＡＰは、ＭＮの直結する移動アクセス・ルータの位置パラメータを見つけ、上流のすべてのＭＲのＬＣｏＡが得られるまで上記処理を繰り返すことができる。そのようにＭＡＰにてトレースが繰り返し行われると、上流のすべてのＭＲのＬＣｏＡから成るトンネルにルーティング・ヘッダを挿入することで、データ・パケットがＭＮにトンネルされる。ＨＭＩＰｖ６と同様、パケットをＣＮへ送信する場合、ＭＮは、まず、ＭＡＰへと続くトンネルにパケットをカプセル化する。ＭＮの上流のすべてのＭＲは、ＭＡＰにバインディングを有するので、ＭＡＰへと続く別々のトンネルにさらにパケットをカプセル化する。この方法によって最終的に得られる効果としては、受信データ・パケットには、拡張ルーティング・ヘッダを有するＭＡＰからのトンネルが単一となるということである。送信データ・パケットには、無線ドメインにおいてＭＮ／ＭＲからＭＡＰへ多重カプセル化が行われる。このプロトコルは、主に、ＮＥＭＯに深くネストされたＭＮに対するハンドオフやシグナリングの向上を図るということを理解することが重要である。この方法を[非特許文献４]に開示されているようなＡＲＯ方式と比較する場合、ＡＲＯ方式は、より優れたエンド・ツー・エンドＲＯを実現することを理解することが重要である。これは、ＡＲＯでは、無線ドメインには逆方向にトンネルが存在しないのに対し、[非特許文献５]の無線ドメインには複数のトンネルが存在するためである。また、ＡＲＯでは、順方向にトンネルが存在しない。
【００１１】
上記から予見し得るのは、データ・フロー、端子、ネットワークの目的を達成するためには、今後、複数の異なるタイプのプロトコルをシステムに実装する必要がある可能性があるということである。データ・フローについて言えば、その主な目的は、遅延、ジッター、パケット・ロスを軽減することである。ネットワークにより認識されるＱｏＳに関する主な目的は、ネットワーク負荷、もっと正確には、ネットワークへのシグナリング負荷を軽減することである。ＭＮに関する目的は、省電力化である。従って、これらのすべての目的を一つの目標として組み合わせるためには、複数のプロトコルをシステムに実装する必要がある可能性が非常に高い。ＭＮは、今後、異なるＱｏＳニーズを持つ異なるタイプのフローをサポートすることが必要になるかもしれない。例えば、ＭＮは、厳しいエンド・ツー・エンドＲＯを必要とするいくつかのフローと、それほど厳しいエンド・ツー・エンドＲＯを必要としないいくつかのフローとを運ぶ必要が生じる可能性ある。それほど厳しいエンド・ツー・エンドＲＯを必要としないフローについては、ＭＮは、ネットワークに投入されるシグナリング負荷の向上を考慮し、頻繁に行われるバインディング・アップデートを軽減し省電力化を図ることが必要になるかもしれない。このように、ＭＮ、ＭＲ、いくつかの主要なルータ、ＣＮには、今後、異なるタイプの複数のプロトコルを実装する必要があるということが予見し得る。
【００１２】
このような異種プロトコル動作の重要性をさらに詳しく説明するため、図１には、いくつかのインターネット・サービス・プロバイダ（ＩＳＰｓ）はＭＡＰ機能を実装し、他のいくつかはしないものがあるという将来的なシナリオを示す。このような場合、異なるタイプのプロトコルが必要とされるのは明らかである。訪問移動ノード（ＶＭＮ）１０は、初めは位置Ａにあり、その後位置Ｂへ移動するものとする。位置Ａでは、ＶＭＮ１０は、自身が置かれているＩＳＰがＭＡＰ機能を実装していないことから、ＭＡＰサービスを利用することができない。ＶＭＮ１０はＡＲＯプロトコルを実装しているものとする。ＶＭＮ１０は無線リンク６０を介してＭＲ２０に直接接続され、ＭＲ２０は無線リンク６１を介してＭＲ２１に直接接続され、さらにＭＲ２１は無線リンク６２を介してＡＲ３０に接続されている。また、ＶＭＮ１０はモバイルネットワーク（ＮＥＭＯ）１０６内に位置し、ＭＲ２０はＮＥＭＯ１０７内に位置し、ＭＲ２１は無線アクセス・ネットワーク１０８内に位置するものとする。ＡＲ３０はグローバル通信ネットワーク１００に接続されている。ホーム・エージェント５０、５１、５２はそれぞれ、ＶＭＮ１０、ＭＲ２０、ＭＲ２１のホーム・エージェントを示す。ＶＭＮ１０はＣＮ７０と通信しているものとする。さらに、ＣＮ７０はＡＲＯ対応ノードであり、ＭＲ２０、ＭＲ２１も同様であるものとする。位置Ａでは、ＶＭＮ１０から始まる、又はＶＭＮ１０で終わるすべてのフローが双方向ＲＯを享受できる。この場合、ＡＲＯメカニズムは、完全なエンド・ツー・エンドＲＯを提供するため、非常に有用である。その唯一の短所と言えば、ＶＭＮ１０若しくは上流ＭＲの移動の毎に、ＣＮに入手した新しい気付アドレスを更新する必要があるという事である。これにより、端末からかなりの電力が失われ、ネットワークへのシグナリング負荷が増大することもある。
【００１３】
次に、ＶＭＮ１０が位置Ｂへ移動する場合を想定する。位置Ｂにおいて、ＶＭＮ１０はアクセス・ネットワーク１０５を介してＡＲ３１に直接接続し、無線リンク６３を使ってＡＲ３１とつながっている。この位置では、無線アクセス・ネットワーク１０５にてＭＡＰ４０の情報を取得できる。しかしながら、主な問題は、ＶＭＮ１０がＨＭＩＰｖ６プロトコルを実装していないことである。位置Ｂでのネットワーク・トポロジーはネスト型ではないので、ＡＲＯメカニズムはトリガーされず、ＶＭＮ１０はただＭＩＰｖ６だけを用いてＣＮ７０と通信する。ＶＭＮ１０においてＡＲＯプロトコルはＭＩＰｖ６プロトコルへの拡張機能として実装されるということは当業者であれば理解し得ることである。ＶＭＮ１０がＭＩＰｖ６モードで動作しているため、本稿で前述したような数多くの問題が間違いなく存在する。ＡＲＯのみ実装されたＶＭＮ１０の位置Ａから位置Ｂへの移動を通じて、一つのノードへのＡＲＯ及びＨＭＩＰｖ６の異種実装が有用であるシナリオがはっきりと見て取れる。
【００１４】
次に、ノードＶＭＮ１１について考える。このノードはＨＭＩＰｖ６プロトコルのみを実装しているものとする。ＶＭＮ１１は、図１の位置Ｃに示すようなネスト状態のＮＥＭＯシナリオ内へと移動し、ＣＮ７０と通信する。このシナリオでは、ＶＭＮ１１は無線リンク６４を介してＭＲ２２に直接接続し、ＮＥＭＯ１０４に組み込まれる。ＭＲ２２は無線リンク６５を介してＭＲ２３に直接接続し、ＮＥＭＯ１０３に組み込まれ、ＭＲ２３は無線リンク６６を介してＡＲ３２に直接接続し、無線アクセス・ネットワーク１０２内に位置している。ＡＲ３２は、ルータ階層の上位に位置し、ネットワーク１０１に配置されるＭＡＰ４１から発信されるＭＡＰオプションを入手できる。さらに、ＶＭＮ１１、ＭＲ２２、ＭＲ２３のＨＡは、それぞれ、ＨＡ５３、ＨＡ５４、ＨＡ５５であるものとする。
【００１５】
ＶＭＮ１１の上流ＭＲにはＨＭＩＰｖ６機能しか実装されていないと仮定すると、自身のＲＡ内のＭＡＰオプションを送信しない可能性がある。このため、ＶＭＮ１１はＨＭＩＰｖ６サービスを享受できず、ＭＩＰｖ６モードで動作しなければならない。また、ＭＲ２２は、[非特許文献３]に開示されているＮＥＭＯ基本モード通りに動作しなければならない。この場合、極度の準最適ルーティングや非効率的な所在管理が生じることは当業者には周知のことである。ＶＭＮ１１の上流ＭＲがそれらのルータ通知内のＭＡＰオプションを転送する場合、ＶＭＮ１１は効率的なＨＭＩＰｖ６を享受できるが、ルーティング非効率問題は残ったままである。これは、ＭＡＰ４１のＢＣＥにはＶＭＮ１１の上流ＭＲのＬＣｏＡをトレースするためのパラメータがないからである。ＭＡＰ４１でのエントリは単純なＲＣｏＡ及びＬＣｏＡエントリのみである。従って、ＣＮ７０からのパケットはＭＡＰ４１に到着し、初めに、ＭＲ２２のホーム・エージェントにより割り当てられたプレフィックスから得られたＬＣｏＡへトンネルされる。このため、ＭＡＰ４１でカプセル化されたパケットはインターネット内のＭＲ２２のＨＡに到達し、さらにＭＡＰ４１へトンネルされる。このようなＭＡＰへの／からのトンネリングは、ＭＡＰ４１にて構成されたパケットの宛先がＭＲ２３のＬＣｏＡを示すまで行われる。これは順方向における非効率的なルーティングをはっきりと示す。[非特許文献５]に開示されているようなＮＥＭＯ−ＨＭＩＰのＲＯメカニズムが位置Ｃシナリオ内におけるＭＡＰ４１及びＭＲに実装される場合、シグナリング効率及びＲＯの向上を図ることができる。しかしながら、ＶＭＮ１１のフローの遅延要が厳しい場合、トンネリング手順を全く有さないＡＲＯタイプのエンド・ツー・エンド・プロトコルを実装することは、ＶＭＮ１１にとって非常に重要なことである。また、ＭＡＰ４１に不具合が生じた場合、[非特許文献５]に開示されているようなＮＥＭＯ−ＨＭＩＰｖ６のＲＯメカニズムはそのようなＭＡＰの不具合が発生した時にＶＭＮ１１のフローに対しＲＯを提供できないので、ＶＭＮ１１や上流ＭＲにＡＲＯメカニズムを実装することが重要である。上記考察から分かることは、今後、ＡＲＯ及びＨＭＩＰｖ６スキームがシステムに実装される可能性が高いことが予見し得るということである。
【００１６】
ＭＮ及びＭＲにＡＲＯプロトコルとＨＭＩＰｖ６プロトコルの両方が実装され、それらノードがＭＡＰドメイン内でローミングしている場合、ＡＲＯ及びＨＭＩＰｖ６の両方の実装が移動端末にてトリガーされる際にデータ・トラフィックがどのようになるかを確かめることが重要である。図２は、将来的なＡＲＯ＋ＨＭＩＰｖ６シナリオのデータ及びシグナリング・ストリームを示すメッセージ・シーケンス・チャート（ＭＳＣ）である。図２では、ＶＭＮ１２はＭＲ２４の配下にネストされ、ＭＲ２４はＡＲ３３に直接接続される。また、ＡＲ３３は直接的に、又は間接的にＭＡＰ４２に接続されるものとする。ホーム・エージェントＨＡ５６はＭＲ２４のホーム・エージェントであり、ＨＡ５７はＶＭＮ１２のホーム・エージェントである。さらに、ＶＭＮ１２はＣＮ７１と通信を行っているものとする。ＶＭＮ１２、ＭＲ２４、ＭＡＰ４２、ＨＡ５６、ＨＡ５７、ＣＮ７１はすべてＡＲＯ対応であるとする。また、ＶＭＮ１２、ＭＲ２４、ＭＡＰ４２はＡＲＯ＋ＨＭＩＰｖ６に対応し、両方のプロトコル・スタックが実装されているものとする。相互動作の問題をさらに詳しく見ていくために、シグナリングの詳細について以下にさらに詳しく説明する。
【００１７】
ＭＲ２４は、ＡＲ３３のネットワーク内に入ると、ＭＡＰオプションを含むＲＡ２００を受信し、ＬＣｏＡ及びＲＣｏＡを設定し、ＭＡＰ４２へ登録シグナリング２０１を送信する。そのような双方向ローカル登録を行った後、ＭＡＰ４２は２０２に示すようなＢＣＥを得る。続いて、ＭＲ２４は図２のメッセージ２０３を利用したＮＥＭＯ基本タイプの登録によりＨＡ５６を更新する。そのような双方向登録及び確認応答シグナリングを行った後、ＨＡ５６は２０５に示すようなＢＣＥを得る。このＨＡ５６への登録メッセージ２０３はＭＲ２４にてＭＡＰ４２へカプセル化され、ＭＡＰ４２にてデカプセル化され、デカプセル化されたメッセージ２０４はＨＡ５６に到達する。
【００１８】
上記登録後、ＭＲ２４はさらにＮＥＭＯリンク内にＲＡ２０６を送信する。このＲＡはＡＲＯオプション及びＭＡＰオプションを含む。ＡＲＯオプションはＭＲ２４のホーム・アドレスを運び、ＭＡＰオプションはＭＡＰ４２のグローバルアドレスを運ぶ。ＶＭＮ１２は、最初にＭＡＰオプションを処理する場合、その後２つの気付アドレスを設定する。一つはＭＡＰアドレス・プレフィックスからのＲＣｏＡであり、もう一つはＭＲ２４のホーム・エージェントから得られ、ＭＲ２４により通知されたプレフィックスからのＬＣｏＡである。その後、ＶＭＮ１２がその後、ＡＲＯオプションを処理する場合、一連のシグナリングの初めに、ＭＡＰ４２であるローカル・ホーム・エージェントに登録してもよい。ＡＲＯオプションの処理後にＶＭＮ１２にてＡＲＯプロトコルがトリガーされるので、ＶＭＮ１２はＭＡＰへＢＵを送信する際ＡＲＯオプションを利用する。このＡＲＯオプションは、ＢＵメッセージを構成するモビリティ・ヘッダへ挿入される。
【００１９】
このことはメッセージ２０７に示される。このメッセージ２０７はさらに、ＭＲ２４にて、ＭＡＰへのトンネルにカプセル化され、カプセル化されたＢＵ２０８はＭＡＰ４２に到達する。さらに、ＭＡＰ４２はＶＭＮ１２のエントリでバインディング・キャッシュ（ＢＣ）エントリ２０９を更新する。また、ＭＡＰ４２もＡＲＯ対応のものとするので、ＶＭＮ１２へバインディング確認応答（ＢＡ）を送信する。ＭＡＰからのＢＡはＭＲ２４のホーム・アドレス宛てであり、ＲＨ２も含んでいる。ＲＨ２は、ＶＭＮ１２のＬＣｏＡとＶＭＮ１２のＲＣｏＡとを含む。ＢＡメッセージ２１０は、まずＨＡ５６に到達する。そこで、ＢＡメッセージはＭＲ２４のＲＣｏＡへトンネルされる。このカプセル化されたメッセージ２１１は、図２に示すように、ＭＡＰ４２に到達する。そして、ＭＡＰ４２は、ＭＲ２４のＲＣｏＡである宛先アドレスを確認する。ＭＡＰ４２は、この２０９に示すようなＲＣｏＡに対するエントリを有するので、ＢＡパケットをＭＲ２４のＬＣｏＡへさらにトンネルする。このトンネルされたメッセージ２１２はＭＲ２４に到達する。ここで、メッセージ２１２は２回デカプセル化される。
【００２０】
デカプセル化後、ＭＲ２４は、最も内側のパケットが宛先アドレスをＭＲ２４のホーム・アドレスとして有することを認識する。その場合、ＭＲ２４はＲＨ２を調べ、宛先をＶＭＮ１２のＬＣｏＡに変更し、ＢＡメッセージ２１３を望ましい受信者へ送る。その後、ＡＲＯプロトコル仕様に示されるように、ノードからのＢＡがノードのホーム・アドレス宛てであるので、ＭＡＰ４２ではＭＲ２４のホーム・アドレスに対するバインディングが得られないことは明らかである。この場合、ＭＲ２４は、ＭＡＰ４２にてそのホーム・アドレスとＲＣｏＡとをバインディングするため、ＭＡＰ４２とＲＲ処理を開始する。ＡＲＯ実装においては、一旦ＭＲ２４により両方のプロトコルが起動されると、そのＲＣｏＡをすべてのＨＡ及びＣＮに開示する外部アドレスと見なすことは当業者であれば容易に理解し得ることである。ＭＲ２４はＭＡＰ４２にてＭＲ２４のＨｏＡ登録を行っていないので、ＲＲ及びＢＵがＭＲ２４によってトリガーされる。
【００２１】
ＭＲ２４は、送信元アドレスがＭＲ２４のホーム・アドレスであるホームテスト開始メッセージ（ＨｏＴＩ）を作成する。そして、ＨｏＴＩパケットをそのＨＡ５６へのトンネルにカプセル化する。このときのトンネル送信元アドレスは、ＭＲ２４のＲＣｏＡである。アクセス・ネットワーク内のイングレス・フィルタリングを避けるため、このＨｏＴＩはＭＲ２４によりＭＡＰ４２へさらにトンネルされる。この二重にカプセル化されたＨｏＴＩパケット２１４はＭＡＰ４２に到達し、単一段階のトンネルデカプセル化処理を受ける。その後、一重にカプセル化されたパケット２１５がＨＡ５６に到達する。そこで、ＨｏＴＩパケットはさらにデカプセル化され、最終的にＨｏＴＩメッセージ２１６が対象となる最終受信者であるＭＡＰ４２に到達する。ＭＲ２４は、ＨｏＴＩパケットを送信すると同時にＭＡＰ４２へ気付テスト開始（ＣｏＴＩ）メッセージ２１７を送信する。ＣｏＴIメッセージには、送信元アドレスとしてＭＲ２４のＲＣｏＡが含まれる。こうして、このＣｏＴIメッセージはＭＡＰ４２へトンネルされる。このことはメッセージ２１７に示される。ＭＡＰ４２は、これらの２つのＨｏＴＩメッセージとＣｏＴIメッセージを受信すると、ＭＲ２４へホームテスト（ＨｏＴ）メッセージと気付テスト（ＣｏＴ）メッセージを送信する。ＨｏＴメッセージには、送信元がＭＡＰ４２として、宛先がＭＲ２４のホーム・アドレスとして含まれる。このＨｏＴメッセージ２１８はＨＡ５６に到達し、そこでＨｏＴはＭＲ２４のＲＣｏＡへトンネルされる。このトンネルされたＨｏＴメッセージ２１９はＭＡＰ４２に到達し、ＭＡＰはさらにＢＣエントリ２０９を参照してそのＨｏＴメッセージをさらにＭＲ２４のＬＣｏＡへトンネルする。この二重にカプセル化されたＨｏＴメッセージ２２０はＭＲ２４へ到達しそこで処理される。
【００２２】
次に、ＭＡＰ４２はＭＲ２４へＣｏＴメッセージを送信する。このＣｏＴメッセージは、送信元アドレスがＭＡＰアドレスとなり、宛先アドレスがＭＲ２４のＲＣｏＡとなるよう構成されている。このメッセージはさらにＭＲ２４のＬＣｏＡへの単一のトンネルへカプセル化される。このメッセージ２２１はＭＲ２４に到達する。ＭＲ２４は、関連するＲＲトークンを取得すると、署名鍵を作成し、ＭＡＰ４２へＢＵ登録メッセージを送信する。このＢＵ登録メッセージには、送信元アドレスがＭＲ２４のＲＣｏＡとして、宛先アドレスがＭＡＰ４２のアドレスとして含まれている。このＢＵパケットは宛先オプションヘッダにＭＲ２４のホーム・アドレスを含んでいる。このような双方向登録及び確認応答は、メッセージ２２２に示される。上記ＢＵ登録がＭＡＰ４２に受諾されると、ＭＡＰ４２によりＢＣエントリが更新され、ＭＡＰ４２でのＢＣＥが２２３に示されるようになる。
【００２３】
ＶＭＮ１２は、ＭＡＰ４２でのＢＵ登録完了後、自身のホーム・エージェントＨＡ５７に登録してもよい。この場合、ＶＭＮ１２はＲＣｏＡを送信元アドレスとしてＨＡ５７に登録を行う。ＡＲＯオプションはＢＵを構成するモビリティ・ヘッダに挿入される。このＢＵメッセージはさらにＭＡＰ４２へのトンネルにカプセル化される。ＶＭＮ１２は、ＭＡＰ４２にてＡＲＯバインディングを行ったので、ＮＥＭＯ転送ホップバイホップ・オプション（ＮＥＭＯ‐ＦＷＤ）をトンネルヘッダに挿入する。ＭＲ２４は、このメッセージ２２４を受信しホップバイホップ・オプションを調べると、送信元アドレスを自身のＲＣｏＡに変更し、さらにＭＡＰ４２へパケットをトンネルする。このＭＲ２４により挿入された２番目のトンネルには、ＭＲ２４のＬＣｏＡが送信元アドレスとして、ＭＡＰ４２のアドレスが宛先アドレスとして含まれている。この二重にカプセル化されたメッセージ２２５はＭＡＰ４２に到達し、２段階のデカプセル化が施される。最終的に、内部メッセージ２２６はＨＡ５７へ送られる。
【００２４】
上記登録はＡＲＯオプションがＭＲ２４のＨｏＡを含むＡＲＯタイプの登録であるため、ＨＡ５７のＢＣＥは２２７に示すようなものとなる。ＨＡ５７は、ＶＭＮ１２からＢＵを取得すると、宛先がＭＲ２４のホーム・アドレスに設定されたＢＡを送信する。このメッセージ２２８はＭＲ２４のホーム・ネットワークへ送信され、パケットがＨＡ５６に受信され、ＭＲ２４のＲＣｏＡへトンネルされる。このトンネルされたメッセージ２２９はＭＡＰ４２に送られる。ＭＡＰ４２はＢＣＥ２２３によりパケットをＭＲ２４のＬＣｏＡへトンネルする。この二重にカプセル化されたメッセージ２３０はＭＲ２４へと送られ、２段階のデカプセル化が施される。そのようなデカプセル化が行われた後、ＭＲ２４は最も内側のパケットの宛先アドレスを調べる。そのアドレスがＭＲ２４のホーム・アドレスであるので、ＭＲ２４はさらにＲＨ２を調べる。ＲＨ２での次のエントリはＶＭＮ１２のＲＣｏＡであるので、ＭＲ２４はさらにパケットを自信のＨＡ５６へトンネルし、同様にＭＡＰ４２へとトンネルする。この二重にカプセル化されたパケット２３１はＭＡＰ４２へ到達すると、１回デカプセル化される。その後、メッセージ２３２はＭＲ２４のホーム・エージェントへと送られ、さらに１回デカプセル化処理を施される。そのようなデカプセル化処理後、ＢＡメッセージ２３３はＭＡＰ４２へと送られ、ＭＡＰ４２はＢＣＥ２２３を調べてパケットを送るために最適なエントリを探し出す。ＭＡＰ４２はＡＲＯトレースメカニズムによりＶＭＮ１２のＲＣｏＡに到達するためのエントリを探し出す。ＡＲＯトレースにより得られたエントリはＶＭＮ１２のＬＣｏＡとＭＲ２４のＲＣｏＡであるので、ＭＡＰ４２はパケットを宛先アドレスがＭＲ２４のＲＣｏＡであるトンネルに組み込む。トンネルは、ＶＭＮ１２のＬＣｏＡとＶＭＮ１２のＲＣｏＡを含むＲＨを有する。
【００２５】
上記のような単一段階のトンネル形成が行われると、ＭＡＰ４２はパケットの宛先アドレスを調べてルーティングパスを決定する。宛先がＭＲ２４のＲＣｏＡであるので、さらにＢＣＥ２２３をチェックして関連するＭＲ２４のＬＣｏＡを探し出す。そしてパケットはＭＡＰ４２にて２回カプセル化され、このＢＡメッセージ２３４はＭＲ２４へと送られる。ＭＲ２４はこのＢＡメッセージ２３４をデカプセル化し、ＲＨ２を調べる。ＭＲ２４は宛先アドレスをＶＭＮ１２のＬＣｏＡへと変更し、さらにこのＢＡメッセージをＶＭＮ１２のＬＣｏＡへ送る。この一重カプセル化されたメッセージ２３５はＶＭＮ１２に到達する。ＭＲ２４は、ＢＡメッセージ２３０から、ＨＡ５７には自信のホームアドレスエントリ登録されていないことを把握し、ＨＡ５７に対し通常のＲＲ、ＢＵ処理をトリガーする。このことはメッセージ２３６に示される。このメッセージ２３６に関して、シグナリング・パケット構造の詳細及びルーティングパスの詳細について詳しく説明しないが、当業者であれば容易に推論・理解し得ることである。
【００２６】
上記登録が行われた後、ＨＡ５７のＢＣＥは２３７に示すようになる。興味深いことにＨＡ５７のエントリはすべてＲＣｏＡであり、ＡＲＯとＨＭＩＰｖ６とが組み合わされた操作によりＬＣｏＡではなくＲＣｏＡが登録されることが分かる。このようにＨＡ５７にてバインディングが確立された後、ＶＭＮ１２はＣＮ７１との最適経路を確立するために、ＲＲ処理をトリガーする。ＶＭＮ１２が自信のホーム・アドレスを送信元アドレスとして作成したＨｏＴIメッセージは前述したように２回カプセル化される。この二重にカプセル化されたメッセージ２３８は、さらにＭＲ２４によりＭＡＰ４２へとトンネルされ、このメッセージ２３９はＭＡＰ４２に到達する。このメッセージにはＭＡＰ４２により２段階のデカプセル化が施され、一重カプセル化されたメッセージ２４０はＶＭＮのホーム・エージェント、すなわちＨＡ５７へと送られる。ＨＡ５７では、ＨｏＴIが完全にデカプセル化され、ＨｏＴIメッセージ２４１がＣＮ７１へと送られる。続いて、ＶＭＮ１２はＣＮ７１へＣｏＴIメッセージを送信する。ＣｏＴIメッセージ内のパケットには、ＶＭＮ１２のＲＣｏＡが送信元アドレスとして含まれる。このＣｏＴIメッセージはＭＡＰ４２へとトンネルされる。この場合も先と同様に、ＮＥＭＯ−ＦＷＤオプションが外部トンネルに存在する。この一重カプセル化されたメッセージ２４２はさらにＭＲ２４によりカプセル化され、この二重にカプセル化されたメッセージ２４３はＭＡＰ４２へ送られる。このメッセージには、ＭＡＰ４２にて、２段階のデカプセル化が施され、最終的にＣｏＴIメッセージ２４４がＣＮ７１へと送られる。ＶＭＮ１２からＨｏＴIとＣｏＴIを良好に受信すると、ＣＮ７１はＨｏＴメッセージとＣｏＴメッセージをそれぞれ送信する。これらのＨｏＴメッセージ及びＣｏＴメッセージ、ＢＵ／ＢＡはメッセージ２４５に示される。先と同様に、説明を簡素化するため、これらのメッセージの詳細については省略する。
【００２７】
上記登録後のＣＮ７１のＢＣＥが２４６に示される。ＭＲ２４は、そのホーム・アドレス宛てのＢＡを受信すると、ＣＮ７１とのＡＲＯタイプのＢＵ確立をトリガーする。そのＲＲ、ＢＵ、ＢＡは図中のメッセージ２４７に示される。このようなシグナリング後のＣＮ７１でのＢＣＥは２４８により示される。ＶＭＮ１２は、ＣＮ７１へデータ・パケットを送信したい場合、バインディング・リストをチェックする。バインディング・リストは、ＲＣｏＡがＣＮ７１に公開され、ＣＮ７１にてＡＲＯタイプの登録が行われたことを示す。ＶＭＮ１２ではＨＭＩＰｖ６スタックも作動中であるため、ＶＭＮ１２で作成されたデータ・パケットはさらにＭＡＰ４２へとトンネルされる。このようなＶＭＮ１２でのデータ・パケットの構造を２５２に示す。外部トンネルには、送信元アドレスがＶＭＮ１２のＬＣｏＡとして、宛先アドレスがＭＡＰ４２のアドレスとして含まれる。外部トンネルには、ＮＥＭＯ−ＦＷＤホップバイホップ・オプションが含まれ、またＶＭＮ１２のＲＣｏＡである宛先オプションも含まれる。この一重カプセル化されたメッセージ２４９はＭＲ２４によりさらに調べられる。ＭＲ２４はＮＥＭＯ−ＦＷＤオプションを参照し、宛先にてホームアドレス（ＨｏＡ）によるＡＲＯタイプの登録が行われたか否かを判別する。ＭＲ２４は、ＭＡＰ４２にて上記ＨｏＡ登録を行ったので、送信元アドレスをＲＣｏＡへと変更する。この場合もＨＭＩＰｖ６に従い、ＭＲ２４はパケットをＭＡＰ４２へとトンネルするので、データ・パケットには２回目のカプセル化が行われる。２５３は、ＭＲ２４にて再構成されたデータ・パケットのパケット構造を示す。この二重にカプセル化されたパケット２５０はＭＡＰ４２へと送られ、ＭＡＰ４２は最初に最も外側のトンネルをデカプセル化する。ＭＡＰ４２は、２番目のトンネルをデカプセル化する際、ＡＲＯトレースを行い、内部トンネル内の送信元アドレス（ＭＲ２４のＲＣｏＡ）が関連するか否かを調べる。ＶＭＮ１２のＲＣｏＡに対してトレースを行う場合と同様、アドレスが関連するアドレスであるため、ＭＡＰ２４この内部トンネルも除去し、メッセージ２５１を宛先へと送る。
【００２８】
次に、ＣＮ７１からＶＭＮ１２へと送信されるデータ・パケットについて考えると、そのようなデータ・パケットは、ＣＮ７１にて、宛先アドレスがＭＲ２４のＲＣｏＡとなるよう構成される。ＣＮ７１でのＲＨ２には、ＶＭＮ１２のＲＣｏＡとＶＭＮ１２のホームアドレス（ＨｏＡ）とが含まれる。このデータメッセージ２５４はＭＡＰ４２に受信されトンネルされる。ＭＡＰ４２はＢＣＥ２２３を利用してパケットをＭＲ２４のＬＣｏＡへトンネルする。このトンネルされたメッセージ２５５はＭＲ２４へと送られ、デカプセル化される。ＭＲ２４は宛先アドレスをＲＨ２内のＶＭＮ１２のＲＣｏＡと交換し、さらにＨＡ５６を介してパケットをトンネルし、ＨＭＩＰｖ６に従ってそのパケットをさらにトンネルする。この二重にカプセル化されたメッセージ２５６は、ＭＡＰ４２にて単一レベルのデカプセル化が施される。その後、メッセージ２５７はＨＡ５６へ送られ、デカプセル化された後、先と同様にＭＡＰ４２へと送られる。ＭＡＰ４２は、前述と同様にＢＣＥ２２３を利用し２段階のトレースを行って、データ・パケットをＭＲ２４のＬＣｏＡへ送信する。メッセージ２５９に対する第１トンネルには、ＭＲ２４のＲＣｏＡが宛先として含まれ、ルーティング・ヘッダにはＶＭＮ１２のＬＣｏＡとＶＭＮ１２のＲＣｏＡが含まれる。また、メッセージ２５９に対する第２トンネルには、ＭＲ２４のＬＣｏＡが宛先として含まれる。このデータメッセージはＭＲ２４へと送られ、そこで一度デカプセル化され、ＭＲ２４は宛先アドレスをＶＭＮ１２のＬＣｏＡと交換する。最後に、カプセル化されたデータ・パケット２６０はＶＭＮ１２へと送られ、そこでデカプセル化され、上層へ送信される。
【先行技術文献】
【特許文献】
【００２９】
【特許文献１】Ｈｉｒａｎｏ，Ｊ．、Ｎｇ，Ｃ．Ｗ．他、「パケット転送の制御方法及び装置、ならびに通信ノード」、ＷＩＰＯ特許国際公開ＷＯ０６１２９８６３Ａ１号、２００６年１２月
【特許文献２】Ｈｉｒａｎｏ，Ｊ．、Ｎｇ，Ｃ．Ｗ．他、「パケット転送の制御方法及び装置」、ＷＩＰＯ特許国際公開ＷＯ０６１２９８５８Ａ１号、２００６年１２月
【特許文献３】Ｈｉｒａｎｏ，Ｊ．、Ｎｇ，Ｃ．Ｗ．他、「パケット転送の制御方法及び装置」、ＷＩＰＯ特許国際公開ＷＯ０６１２９８５５Ａ１号、２００６年１２月
【非特許文献】
【００３０】
【非特許文献１】Ｊｏｈｎｓｏｎ，Ｄ．Ｂ．、Ｐｅｒｋｉｎｓ，Ｃ．Ｅ．及びＡｒｋｋｏ，Ｊ．、”Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  Ｉｎ  Ｉｐｖ６”  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｅｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  Ｒｅｑｕｅｓｔｓ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ  ３７７５  Ｊｕｎｅ  ２００４
【非特許文献２】Ｓｏｌｉｍａｎ，Ｈ．他、"Ｈｉｅｒａｒａｃｈｉｃａｌ  Ｍｏｂｉｌｅ  ＩＰｖ６  Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  （ＨＭＩＰｖ６）” Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｅｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  （ＩＥＴＦ）  Ｒｅｑｕｅｓｔｓ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ（ＲＦＣ）４１４０、Ａｕｇｕｓｔ  ２００５
【非特許文献３】Ｄｅｖａｒａｐａｌｌｉ，Ｖ．他、”ＮＥＭＯ  Ｂａｓｉｃ  Ｓｕｐｐｏｒｔ  Ｐｒｏｔｏｃｏｌ”  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｅｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  Ｒｅｑｕｅｓｔｓ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ  ３７７５  Ｊｕｎｕａｒｙ  ２００４
【非特許文献４】Ｃ．Ｎｇ、Ｊ．Ｈｉｒａｎｏ、"Ｓｅｃｕｒｅｄ  Ｎｅｓｔｅｄ  Ｔｕｎｎｅｌｓ  Ｏｐｔｏｍｉｚａｔｉｏｎ  ｗｉｔｈ  Ｒｏｕｔｅｒ  Ａｃｃｅｓｓ  Ｏｐｔｉｏｎ”ＩＥＴＦ  Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ：ｄｒａｆｔ−ｎｇ−ｎｅｍｏ−ａｃｃｅｓｓ−ｒｏｕｔｅｒ−ｏｐｔｉｏｎ−０１．ｔｘｔ、Ｅｘｐｉｒｅｄ  Ｊａｎｕａｒｙ  １０，  ２００４
【非特許文献５】Ｏｈｎｉｓｈｉ，Ｈ．、Ｓａｋｉｔａｎｉ，Ｋ．、Ｔａｋａｇｉ，Ｙ．、"ＨＭＩＰ  ｂａｓｅｄ  Ｒｏｕｔｅ  Ｏｐｔｉｍｉｚａｔｉｏｎ  Ｍｅｔｈｏｄ  ｉｎ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ”ＩＥＴＦＩｎｔｅｒｎｅｔ  Ｄｒａｆｔ：ｄｒａｆｔ−ｏｈｎｉｓｈｉ−ｎｅｍｏ−ｒｏ−ｈｍｉｐ−００．ｔｘｔ、Ａｐｒｉｌ  ２００３
【発明の概要】
【００３１】
上記の将来的なシナリオにおける異種プロトコルの動作から、ＶＭＮとＭＲとがＡＲＯオプション及びＭＡＰオプションを処理する場合、データ・パケットのルーティングが確実に準最適であることは明白である。このことは、ＣＮ７１からＶＭＮ１２へのデータ・パケット・ルーティングを示すデータメッセージ２５４乃至２６０からもはっきりと見て取れる。このような極度のルーティング準最適性は２つの理由によって生じる。一つ目は、ＶＭＮ１２とＭＲ２４がＲＣｏＡを用いてＣＮ７１にてＡＲＯタイプの登録を行う場合にＣＮ７１でのバインディング・キャッシュ・エントリが理想的なものではないという理由である。ＲＣｏＡベースのＢＣＥがＣＮ７１にて作成されるので、ＶＭＮ１２のＲＣｏＡに到達する前にすべての上流ＭＲのＲＣｏＡに到達する必要がある。これがピンポンルーティングを引き起こす一因となる。二つ目の理由としては、ＭＡＰでの非理想的なＢＣＥやトレースメカニズムによりＲＣｏＡに最適に到達できないということである。ＭＡＰでの理想的なエントリやメカニズムとは、ＲＣｏＡに関連する特定のＬＣｏＡに到達するためのすべての上流ＭＲのＬＣｏＡが存在し、それらがＭＡＰにて一度のトレース処理によりトレース可能であることを意味する。残念なことに、上記ＡＲＯとＭＡＰの統合に起因して、ＭＡＰ４２ではそのような理想的なエントリが作成されず、単純なＡＲＯタイプのトレースを実施するＭＡＰ４２にはそのような理想的なトレースメカニズムが備えられていない。図２から明らかなのは、ＣＮ７１からＶＭＮ１２へのデータ・パケットはＭＡＰへの又はＭＡＰからのピンポンルーティングの影響を受けやすく、また多重トンネリング処理を受けるということである。同様に、ＶＭＮ１２からＣＮ７１へのデータ・パケットは、長く曲折したルートは通過しないが、メッセージ２４９、２５０に示されるように多重にカプセル化される。このことは、ＭＡＰがＡＲＯ対応のものであり、ＡＲＯオプションとＭＡＰオプションがいずれも移動ホストや移動ルータにより同時に処理される環境においてＡＲＯプロトコルやＨＭＩＰｖ６プロトコルが実装され操作される動作する場合に生じるルーティングの非効率問題を浮き彫りにしている。
【００３２】
図３は、ＡＲＯ及びＨＭＩＰｖ６の異種シナリオで、単純なＭＩＰｖ６タイプのノードであるＣＮとより深いネスト状態の環境におけるルーティング問題を示す。図３に示すシナリオでは、ＶＭＮ１２がＭＲ２４及びＭＲ２５の配下にネストされる。ＭＲ２５はＡＲ３４に直接接続され、階層にはＭＡＰが一つだけ、すなわちＭＡＰ４３が含まれる。ＶＭＮ１２、ＭＲ２４、ＭＲ２５のホーム・エージェントはそれぞれ、ＨＡ５８、ＨＡ５７、ＨＡ５６である。ＶＭＮ１２は、ＭＩＰｖ６対応のＣＮ７２とデータ通信セッションを行っている。また、ＶＭＮとＭＲにはＡＲＯ及びＨＭＩＰｖ６スタックが実装され、ＭＡＰにはＡＲＯ及びＨＭＩＰｖ６機能が実装されているものとする。さらに、ホーム・エージェントにはＡＲＯ機能が実装されているものとする。
【００３３】
まず、ＭＲ２５はＡＲ３４に接続されたネットワークに進入し、ＲＡメッセージ３００を取得する。その後、ＭＲ２５はＭＡＰ４３にて登録３０１を行う。その登録後のＭＡＰ４３でのＢＣＥを３０２で示す。ＭＡＰ４３での登録に続き、ＭＲ２５はそのホーム・エージェント、すなわちＨＡ５６に登録を行う。この登録メッセージが３０３に示される。そのメッセージ３０３に続いて、ＨＡ５６のＢＣＥが更新され３０４に示される。図３のメッセージ３００乃至３２７には、説明を簡素化するため、トンネリング処理のすべてや完全なルーティングパスは示されていないが、当業者であれば完全なルーティングパスやパケット構造を容易に想到し得るであろう。ＭＲ２５は、ＨＡ５６への登録を行った後、ＲＡ３０５を送信する。このＲＡには、ＡＲＯオプション及びＭＡＰオプションが含まれる。その後、ＭＲ２４によりＭＡＰオプション及びＡＲＯオプションが処理され、ＭＡＰ４３にてＡＲＯベースのＢＵ登録が開始される。このことがメッセージ３０６に示される。このＭＡＰ４３での登録により、ＭＡＰ４３でのＢＣＥがさらに更新されることとなり、３０７に示されるようになる。ＭＡＰ４３によってＢＡがＭＲ２４へ送信されると、ＭＲ２５はＭＡＰ４３とのＲＲ及びＢＵをトリガーし、ＢＵのＡＲＯオプションを利用してＭＡＰ５３にてＨｏＡ、ＲＣｏＡバインディング登録を図る。この登録はメッセージ３０８に示され、ＭＡＰ４３にて更新されたＢＣＥは３０９に示される。ここで理解すべき重要な点は、ＭＡＰ４３のＢＣＥは、ＡＲＯテーブルのＨｏＡ列に正確なホーム・アドレスならびに移動ホスト及び移動ルータのＲＣｏＡが含まれるエントリを有するということである。さらに、ＡＲＯテーブルのＬＣｏＡ列には、正確なＬＣｏＡ及びＲＣｏＡが含まれる。このようなＡＲＯタイプのＢＣエントリに挿入される異なる種類のアドレスは、上記異種動作における問題の根本的原因である。
【００３４】
ＭＡＰ４３での登録後、ＭＲ２４はそのホーム・エージェント、すなわちＨＡ５７にてＡＲＯタイプの登録を開始する。このＡＲＯタイプのＢＵはメッセージ３１０に示され、ＨＡ５７のＢＣＥは３１１により示される。この場合も先と同様に理解すべき重要な点は、ＨＡ５７のＢＣＥにはＲＣｏＡエントリのみが含まれているということである。ＨＡ５７がＢＡをＭＲ２４へ送信すると、ＭＲ２５はＨＡ５７にてＡＲＯタイプのバインディングを開始し、このことがメッセージ３１２に示される。このメッセージ３１２がＨＡ５７に到達すると、ＨＡ５７のＢＣＥエントリがさらに更新され３１３に示される。ＭＲ２４は、ＨＡでの登録を行うと、ＮＥＭＯリンク内にＲＡを送信する。このＲＡメッセージ３１４には、先と同様に、ＡＲＯオプションとＭＡＰオプションがいずれも含まれる。ＶＭＮ１２は、上記オプションを確認すると、ＲＣｏＡ及びＬＣｏＡを設定し、ここでもＭＡＰ４３にてＡＲＯタイプの登録を実行する。この登録メッセージは３１５に示される。上記登録後、ＭＡＰ４３のＢＣＥはＶＭＮ１２のエントリによりさらに更新され、３１６に示される。ＶＭＮ１２へＭＲ２４のホーム・アドレスが組み込まれる確認応答がＭＡＰ４３により送信されると、ＭＲ２４はそのＨｏＡとＲＣｏＡを登録するためＭＡＰ４３にてＡＲＯタイプの再帰的シグナリングを開始する。この再帰的シグナリングは３１７に示される。この再帰的シグナリングが終了すると、ＭＡＰ４３のＢＣＥはさらに更新され、３１８に示される。ＭＲ２５のＨｏＡの登録がＭＡＰ４３にて行われているため、ＭＡＰ４３はＭＲ２５のＨｏＡをＭＲ２４への応答メッセージ（メッセージ３１７）には組み込まない。このＭＲ２５のＨｏＡがＭＡＰ４３により組み込まれた場合、ＭＲ２５はもうすでにメッセージ３０８を介してＨｏＡ及びＲＣｏＡ登録を送信済みなので、さらなる登録の送信を行う必要がない。
【００３５】
ＶＭＮ１２は、ＭＡＰ４３での登録後、そのホーム・エージェント、すなわちＨＡ５８にてＡＲＯタイプの登録を行う。その登録メッセージ３１９がＨＡ５８に到達すると、ＢＣＥが更新され３２０に示される。ここで留意すべき重要な点は、ＲＣｏＡがそこで登録されるということである。同様に、ＭＲ２４はＨＡ５８にて再帰的なＡＲＯタイプの登録を行い、このことがメッセージ３２１に示される。このメッセージがＨＡ５８に受信されると、ＢＣＥはさらに更新され、更新されたＢＣＥが３２２に示される。その後しばらくすると、ＭＲ２５はＨＡ５８にて再帰的ＢＵを開始し、そのメッセージが３２３に示される。このメッセージ３２３がＨＡ５８に到達すると、ＢＣＥは３２４に示されるようになる。ＨＡ５８はＢＣＥ３２４を用いてＶＭＮ１２のＨｏＡに到達するためＡＲＯタイプのトレースを行うが、ここでの主要な問題は、ＨＡ５８にてＶＭＮ１２のＨｏＡに対して行われるトレースにより得られるエントリはすべてＲＣｏＡであり、これがピンポンルーティングを引き起こす一因となるということである。
【００３６】
ＶＭＮ１２は、そのホーム・エージェントへの登録後、ＣＮ７２にてＡＲＯタイプの登録を行う。この登録メッセージが３２５に示される。ＣＮ７２は普通のＭＩＰｖ６タイプのノードであるので、ＣＮ７２はＡＲＯオプションを無視する。このようにＣＮ７２にてＢＵが実行されると、ＣＮ７２のＢＣＥは３２６に示されるようになる。ＣＮ７２により通常のＭＩＰｖ６タイプのＡＣＫが送信されるので、ＶＭＮ１２の上流ＭＲはＣＮ７２にてこれ以上ＡＲＯタイプの再帰的登録を行わない。
【００３７】
次に、普通のＭＩＰｖ６ノードであるＣＮ７２からのデータ・パケットのルーティングに関する問題について詳しく説明する。ＣＮ７２は、ＶＭＮ１２へデータ・パケットを送信する際、宛先アドレスをＶＭＮ１２のＲＣｏＡに設定し、パケットにはＶＭＮ１２のＨｏＡが組み込まれるＲＨ２が含まれる。ＭＡＰ４３はＶＭＮ１２のＲＣｏＡを用いてＡＲＯタイプの再帰的トレースによりＢＣＥ３１８をトレースする。ＭＡＰ４３は、ＶＭＮ１２のＲＣｏＡを探す際、エントリを探し出してもよく、関連する気付アドレスをテンポラリ構造に組み込むことが好ましい。そのようにして得られた第１のアドレスはＶＭＮ１２のＬＣｏＡである。次に、再帰的ＡＲＯ検索メカニズムにより、ＡＲＯフィールド内の値、すなわちＭＲ２４のＨｏＡを調べる。ＭＡＰ４３の再帰的メカニズムは引き続き検索を行い、ＭＲ２４のＨｏＡのアドレスを利用してさらにＢＣＥ３１８を検索する。検索メカニズムは容易にエントリを探し出し、ＭＲ２４のＲＣｏＡを一時変数に入れる。この検索処理では、次にＭＲ２５のＨｏＡをＡＲＯフィールドから取得する。検索処理を引き続き実行し、ＭＲ２５のＨｏＡを検索する。検索メカニズムは、その後、ＢＣＥからＭＲ２５のＲＣｏＡエントリを入手する。このＭＲ２５のＨｏＡエントリにはＡＲＯフィールドが付加されていないので、検索はここでストップし、ＭＡＰ４３はＣＮ７２のデータ・パケットを単一のトンネルへカプセル化する。これがトンネル１として３３０に示される。３３０に示すように、このトンネル１にはＭＲ２５のＲＣｏＡが宛先アドレスとして含まれ、ＲＨ２にはＭＲ２４のＲＣｏＡとＶＭＮ１２のＬＣｏＡが含まれる。ＲＨ２の最後のエントリはＶＭＮ１２のＲＣｏＡである。これはパケット構造３３０には明示されていないが、当業者にとっては暗黙の了解であろう。次に、ＭＡＰ４３はルーティング・テーブルを検索し、ＭＲ２５のＲＣｏＡへの経路を探し出す。ＭＡＰ４３は、ＢＣＥからＭＲ２５のＲＣｏＡのエントリを探し出すことができるので、パケットをＭＲ２５のＬＣｏＡへの別のトンネルにカプセル化する。これが３３０内のトンネル２として示される。この二重にカプセル化されたパケット３２９がＭＲ２５に送られ、ＭＲ２５は第１トンネルを除去した後、内部トンネルの宛先アドレスを調べる。内部トンネルの宛先アドレスはＭＲ２５のＲＣｏＡであるので、ＭＲ２５は次に宛先アドレスを次のＲＨ２のエントリと交換し、ＭＲ２４のＲＣｏＡを宛先アドレスに設定する。ＭＲ２５はＭＲ２４のＲＣｏＡへの経路を有していないので、パケットはさらにＭＲ２５のホーム・エージェントへトンネルされ、ＭＲ２５にてＭＡＰ４３へとさらにトンネルされる。説明を簡素化するため、このようなシグナリングは図示されていない。最後に、このＭＲ２４のＲＣｏＡ宛てのパケットがＭＡＰ４３に到達する。基本的には、図３のメッセージ３３１には、これ以上のカプセル化やルーティングパスは明示されていない。メッセージ３３１がＭＡＰに到達したときのデータ・パケットのパケット構造が３３２に示されている。ＭＡＰ４３にてパケット３３２が調べられると、検索メカニズムはＢＣＥ３１８からＭＲ２４のＲＣｏＡエントリを検索する。このようにＡＲＯタイプの再帰的検索を行いＭＲ２４のＲＣｏＡを検索することで、ＭＲ２４のＬＣｏＡとＭＲ２５のＲＣｏＡを得ることができる。
【００３８】
ＭＡＰ４３は上記エントリを利用して第２トンネルを構築する。この第２トンネルは３３４内にトンネル２として示される。次に、ＭＡＰ４３は、パケット３３４内のトンネル２の宛先アドレスであるＭＲ２５のＲＣｏＡに到達するためのルーティングエントリを探す。検索メカニズムは、ＭＡＰ４３のＢＣＥエントリを調べてＭＲ２５のＲＣｏＡを検索すると、該当するエントリを探し出すことができ、さらにそのパケットを第３トンネルにカプセル化する。これが３３４内のトンネル３として示される。この三重にカプセル化されたパケットはＭＲ２５のＬＣｏＡへ送信され、メッセージ３３３として示される。
【００３９】
ＭＲ２５は、このパケット３３３を取得すると、第１トンネルをデカプセル化し、宛先アドレスをＭＲ２４のＬＣｏＡと交換する。パケット３３５はＭＲ２４のＬＣｏＡへと送られる。ＭＲ２４は、このパケットを受信すると、パケットをデカプセル化し、宛先アドレスをＶＭＮ１２のＬＣｏＡに設定する。カプセル化されたパケット３３７は最終的にＶＭＮ１２に到達する。順方向のデータ・トラフィックに関しては、ルーティングの準最適性が発生していることがはっきりと見て取れる。このシナリオでは、ＣＮ７２のＢＣＥが理想的である。そこにはエントリが一つしか含まれておらず、それが好ましいエントリであるＶＭＮ１２のＲＣｏＡである。このシナリオでは、準最適性は主に、ＭＡＰ４３の非理想的なエントリやトレースメカニズムにより引き起こされている。再帰的ＡＲＯトレースをたった一回行っただけでは、ＶＭＮ１２のＲＣｏＡに関連するＬＣｏＡとすべての上流ＭＲのＬＣｏＡを取得することはできない。これは主に、ＡＲＯタイプのＢＣＥの気付アドレス列内でＲＣｏＡとＬＣｏＡエントリが混在していることに起因する。さらに、ＡＲＯタイプのトレースメカニズムは、ＢＣＥの全エントリからＶＭＮ１２のＲＣｏＡに到達するための関連ＬＣｏＡエントリを選択するのに十分なほどインテリジェントではない。
【００４０】
次に、ＶＭＮ１２は、データ・パケットをＣＮ７２へ送信する際、送信元アドレスをＶＭＮ１２のＲＣｏＡに設定し、宛先アドレスをＣＮ７２のアドレスに設定する。このパケットにはＮＥＭＯ‐ＦＷＤオプションは含まれない。このデータ・パケットはさらにＭＡＰ４３へのトンネルにカプセル化される。トンネルパケットでは、送信元アドレスがＶＭＮ１２のＬＣｏＡに設定され、宛先アドレスがＭＡＰ４３のアドレスである。このトンネルパケット構造は３４０に示される。トンネルはＮＥＭＯ‐ＦＷＤオプションを有し、さらにＶＭＮ１２のＲＣｏＡを含む宛先オプションも有する。この一重にカプセル化されたデータメッセージ３３９はＭＲ２４に送られ、ＭＲ２４により調査される。ＭＲ２４はＮＥＭＯ‐ＦＷＤオプションを調べることでトンネルの送信元アドレスをＭＲ２４のＲＣｏＡに変更する。これは、ＭＲ２４はＲＣｏＡを用いてＭＡＰ４３でＡＲＯタイプの再帰的バインディングを行ったためである。そのような変更を行った後、ＭＲ２４はさらにパケットをＭＡＰ４３へのトンネル２にカプセル化する。パケット構造３４２によりトンネル２のパラメータが示される。トンネル２もまた、ＮＥＭＯ‐ＦＷＤオプションを有する。この二重にカプセル化されたメッセージ３４１がＭＲ２５に到達する。
【００４１】
ＭＲ２５は、このパケットを調べる際、ここでも先と同様に、送信元アドレスをＭＲ２５のＲＣｏＡに変更し、さらにデータ・パケットをトンネル３にカプセル化する。このことはパケット構造３４４に示されている。この三重にカプセル化されたデータメッセージ３４３はＭＡＰ４３に送られる。ＭＡＰ４３はパケットをデカプセル化し、トンネル３を除去する。トンネル２を除去するため、ＭＡＰはまずＡＲＯタイプの再帰的トレースを行って、トンネル２内のホーム・アドレス宛先オプションにあるＭＲ２４のＲＣｏＡに到達する。ＭＲ２４のＲＣｏＡに到達するためにＡＲＯトレースを行うことで、ＭＡＰ４３はＭＲ２５のＲＣｏＡを取得することができ、適切にトンネル２をデカプセル化できる。同様に、ＭＡＰ４３は同様のＡＲＯタイプのトレースや検証を行うことでトンネル１をデカプセル化できる。最後に、完全にデカプセル化されたパケットがＣＮ７２へ送信される。逆方向では準最適ルーティング問題が軽減される。入り組んだルーティングは行われないが、前述したような多重カプセル化によりルーティング準最適性は生じている。
【００４２】
そこで、本発明は、先行技術の不具合や欠点を克服する、若しくは、大幅に改善することを目的とする。具体的には、本発明の主要な目的は、ＶＭＮとＭＲがいずれもＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＭＡＰがＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装するＡＲＯ及びＨＭＩＰｖ６の異種シナリオにおいて、ＭＡＰドメイン内でネストされたＶＭＮとＣＮ間での最適な経路を利用したデータ・パケットのやり取りを可能とするメカニズムを提供することにある。
【００４３】
上記目的を達成するため、本発明は、以下のシステム、方法及び装置を提供する。
【００４４】
本発明は、ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムを提供し、ＶＭＮ、ＭＲ、ＨＡはＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡはＡＲＯプロトコルを実装しているものとする。また、このシステムでは、ＭＲにより送信されるルータ通知には２種類のＡＲＯオプションが含まれるものとする。一つはＭＲのホーム・アドレスが送られるＡＲＯオプションであり、もう一つはＭＲがそのＲＣｏＡを送信するＡＲＯオプションである。ＶＭＮとＭＲは上記環境においてさらに処理を行うためＲＣｏＡを含むＡＲＯオプションを利用する。
【００４５】
本発明は、ＶＭＮとＭＲがＭＡＰに登録を行う際、ＡＲＯオプション内のＲＣｏＡ値を使用する上記システムにおいて採用される方法を提供する。
【００４６】
本発明は、上記システム及び方法を実施するＶＭＮに使用される装置を提供する。
【００４７】
本発明は、上記システム及び方法に記載される方法を実施するＭＲに使用される装置を提供する。
【００４８】
本発明は、上記システム及び方法に記載される方法を実施するＭＡＰに使用される装置を提供する。
【００４９】
本発明は、ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを含む通信ノードのシステムを提供し、ＶＭＮ、ＭＲ、ＨＡはＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡはＡＲＯプロトコルを実装しているものとする。また、このシステムでは、ＭＲにより送信されるルータ通知には１種類のＡＲＯオプションしか含まれないものとし、そのＡＲＯオプションは移動アクセス・ルータのホーム・アドレスを定義するものとする。このような環境下で、ＶＭＮとＭＲとがＢＣＥのエントリを用いてＡＲＯオプションとＭＡＰオプションの両方を処理する場合、ＭＡＰは一段階のトレースによってＶＭＮのＲＣｏＡに関連するＬＣｏＡが得られるようなインテリジェント・トレースを行う。
【００５０】
本発明は、インテリジェント・トレース部を実装する、上記システムのＭＡＰの装置を提供する。
【００５１】
本発明は、上記システムのＭＡＰがトレースを行うために利用する方法を提供する。
【００５２】
本発明は、上記システムのＭＲがデータ・パケットを逆方向に送る際、ＲＣｏＡではなくＬＣｏＡにアドレス・スワップを行うために使用する代替方法を提供する。ＭＲはＮＥＭＯ−ＦＷＤオプションを見つけた場合にそのようなスワップを行う。
【００５３】
本発明は、上記システムのＭＡＰがイングレス・インターフェースを介して受信するパケットのデトンネリングを行うために利用する代替方法を提供する。この方法により、トンネル除去処理を行うためにインテリジェント・トレース・メカニズムが拡張される。
【００５４】
本発明は、ＡＲＯやＨＭＩＰｖ６が混在する環境下でも有用な機構を提供できるという利点を有する。
【図面の簡単な説明】
【００５５】
【図１】図１は、従来技術のプロトコルが用いられ、アーキテクチャに複数のＭＡＰが存在する場合のＡＲＯ及びＨＭＩＰｖ６の統合シナリオを示すネットワーク図である。
【図２】図２は、ＶＭＮ、ＭＲ、ＭＡＰがすべてＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡ、ＣＮがＡＲＯプロトコルを実装する場合の従来技術の動作を示すメッセージ・シーケンス・チャートである。
【図３】図３は、ＶＭＮが深くネストされたシナリオにおいて、ＶＭＮ、ＭＲ、ＭＡＰがすべてＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡがＡＲＯプロトコルを実装し、ＣＮがＭＩＰｖ６プロトコルを実装する場合の従来技術の動作を示すメッセージ・シーケンス・チャートである。
【図４】図４は、本発明の好適な実施形態に係るＡＲＯオプションにある特別なアドレスを使ってＭＡＰエントリを更新する方法を利用する主要な発明を示すメッセージ・シーケンス・チャートである。
【図５】図５は、本発明の好適な実施形態に係る図４に示す主要な発明を実施するＶＭＮの機能アーキテクチャを示す図である。
【図６】図６は、本発明の好適な実施形態に係る図４に示す主要な発明を実施するＭＡＰの機能アーキテクチャを示す図である。
【図７】図７は、本発明の好適な実施形態に係るＭＡＰのインテリジェント・トレース部により最適なルーティングを可能とする主要な発明の第２変形例を示すメッセージ・シーケンス・チャートである。
【図８】図８は、本発明の好適な実施形態に係るＭＡＰにてインテリジェント・トレース・メカニズムを設計する主要な発明の第２変形例を実施するＭＡＰの機能アーキテクチャを示す図である。
【図９】図９は、本発明の好適な実施形態に係る主要な発明の第２変形例を実施する場合のＭＡＰの動作を示すフローチャートである。
【発明を実施するための形態】
【００５６】
本発明では、ＡＲＯ及びＨＭＩＰｖ６の統合シナリオにおいて経路最適化を達成するための２つの方法を提示する。なおこのシナリオでは、ＶＭＮ、ＭＲ、ＭＡＰにＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルが実装され、ホーム・エージェントにＡＲＯプロトコルが実装され、ＣＮにＡＲＯプロトコル若しくはＭＩＰｖ６プロトコルが実装されている。また、ＶＭＮは深くネストされたシナリオ内に存在することが好ましい。第１の方法では、上記ＣＮ及び深くネストされたＶＭＮからの最適経路が得られるよう様々なパラメータを使ってＭＡＰにＡＲＯ関連のＢＣＥを追加するために改良されたＡＲＯメカニズムが採用される。第２の方法では、端末のＡＲＯメカニズムに何ら変更を加えない代わりに、一般的なＡＲＯトレースメカニズムとは異なるＢＣＥトレースメカニズムを利用することで最適な経路を実現する。
【００５７】
第１の好適な実施形態では、主要な発明が開示されている。この主要な発明によれば、ＶＭＮとＭＲは、ＭＡＰにて登録を行う際、ＡＲＯオプション内の移動アクセス・ルータのＲＣｏＡを利用する。このようなＡＲＯオプション及びＭＡＰオプションがいずれも利用可能な異種環境では、ＡＲＯオプションにおいて、従来のＡＲＯメカニズムのように移動アクセス・ルータのＨｏＡを利用するのではなくＲＣｏＡを利用する。これは、ＭＡＰにてＶＭＮのＲＣｏＡに対し一般的なＡＲＯトレースが行われた場合に、ＶＭＮのＲＣｏＡに到達するために関連するＬＣｏＡを探し出すのに役立つ。ＭＡＰ登録に関して言えば、ＭＡＰはＲＣｏＡによりＡＲＯ登録テーブルのホーム・アドレス列を更新する。そのため、一般的なＡＲＯ操作と同様にＭＡＰを効率的にトレースするため、ＡＲＯ登録テーブルのＡＲＯオプション列にはＲＣｏＡを使用しなければならない。ＲＣｏＡがＡＲＯ登録テーブルのホーム・アドレス列に位置するＭＡＰにてこの一般的なＡＲＯトレースメカニズムを実現するため、移動端末は、ＡＲＯオプション内の移動アクセス・ルータのＲＣｏＡを含むバインディング登録を送信する。
【００５８】
これについて図４を用いて詳しく説明する。図４では、ＶＭＮ１２はＭＲ２４及びＭＲ２５の配下にネストされ、ＭＲ２５はＡＲ３３に直接接続されている。アクセス・ネットワークにはＭＡＰは一つしかなく、それがＭＡＰ４２である。ＨＡ５８はＶＭＮ１２のホーム・エージェントであり、ＶＭＮ１２はＣＮ７３とデータ通信セッションを行っている。説明を簡素化し、かつ、発明の核となる特徴を提示するという目的から逸脱しないため、図４ではＭＲのホーム・エージェントを明示しない。ＣＮ７３はＡＲＯ対応のものとする。ここでも先と同様に、ＶＭＮとＭＲはＡＲＯ及びＨＭＩＰｖ６対応のものであり、ＭＡＰも同様である。さらに、ＨＡもＡＲＯ対応のものとし、移動ホストと移動ルータはすべて、それらのアクセス・ルータからＲＡを受信すると、ＡＲＯオプション及びＭＡＰオプションの両方を処理する。この主要な発明の核となる特徴は、ＢＣＥテーブルに理想的なエントリを投入することで理想的なテーブルを実現することである。すなわち、ＶＭＮのＲＣｏＡに対しトレースを行うことで、ＶＭＮのすべての上流ＭＲのＬＣｏＡとＶＭＮのＬＣｏＡとを正しい順番で取得する必要がある。図３のＢＣＥテーブル３１８からも分かるように、そのようなＬＣｏＡをすべて取得するという目的を達成することは不可能である。ＢＣＥ３１８では、第１列のエントリがホーム・アドレスのエントリであり、第２列のエントリが気付アドレスのエントリであり、第３列のエントリが再帰的ＡＲＯトレースメカニズムに役立つＡＲＯオプションのエントリである。
【００５９】
現在、従来技術の問題は、ＭＡＰでのＢＵ登録の最中に移動アクセス・ルータのホーム・アドレスがＡＲＯオプションで送信され、その結果、ＨｏＡとＲＣｏＡを備える移動アクセス・ルータにより開始される通常の再帰的ＡＲＯタイプのＢＵ登録が行われるという点にある。この再帰的ＡＲＯ登録は、ＭＡＰがＭＲのＨｏＡをそのＡＣＫに組み込むことで発生する。ＭＡＰは、ＢＣＥから、ＡＲＯオプションで送られたＨｏＡを探し出せないので、ＡＣＫにそれを組み込む。これにより、ＡＲＯテーブルの気付アドレス列にＲＣｏＡとＬＣｏＡとが混在してしまう。主要な発明ではこのような事態が発生することを防ぐことで上流ＭＲからの再帰的ＡＲＯ更新がそれ以上行われないようにする。これについては、図４のメッセージ・シーケンスを詳しく見ていくことで説明する。
【００６０】
ＭＲ２５はＲＡ４００からＭＡＰオプションを受信する。ＭＲ２５は、ＲＡを受信すると、ＲＣｏＡ及びＬＣｏＡを設定し、メッセージ４０１によってＭＡＰ４２で登録を行う。この登録後のＭＡＰ４２でのＢＣＥを４０２に示す。その後、ＭＲ２５はローカルＮＥＭＯネットワークにＲＡを配信する。このＲＡ４０３には、ＭＡＰオプションが含まれ、２つのＡＲＯオプションが付加されている。そのＡＲＯオプションの内の一つはＭＲ２５のホーム・アドレスであり、もう一つはＭＲ２５のＲＣｏＡである。主要な発明によれば、ＭＡＰがＡＲＯ対応である異種環境において、ＭＲはＲＡにより２つのＡＲＯオプションを送信する。ＭＡＰがＡＲＯ対応であるか否かは、ＭＡＰオプション内に確保されたフィールドにより判別することが可能である。
【００６１】
ＭＲ２４は、このＲＡ４０３を受信すると、ＭＡＰ４２とのバインディングの際にＭＲ２５のＲＣｏＡをＡＲＯオプションとして用いる。ＲＡ４０３を受信後、ＭＲ２４は登録メッセージ４０４によりＭＡＰ４２との登録を行う。この登録メッセージはＭＡＰ４２に送られる前にＭＲ２５によってカプセル化される。これにより、ＭＡＰ４２のＢＣＥがさらに更新され、そのＢＣＥが４０５に示される。ここでＭＡＰ４２は、ＭＲ２５のＲＣｏＡであるＢＵのＡＲＯオプションフィールドを調べる。ＭＡＰ４２は、もうすでにこのアドレスに対してバインディングを持っているので、ＭＲ２４にＢＡを送る時にその値を送信しない。４０５の気付アドレスのエントリはすべてローカル気付アドレスであり、この列ではＲＣｏＡとＬＣｏＡとは混在しないことは当業者であれば理解し得ることである。
【００６２】
ＭＲ２４は、ＭＡＰ４２にて適切に登録を行うと、同様にＭＡＰオプションと２種類のＡＲＯオプションを含むＲＡ４０６を送信する。ＶＭＮ１２はこれらすべてのオプションを受信し、同様にＭＡＰオプションとＭＲ２４のＲＣｏＡを含むＡＲＯオプションとを処理する。気付アドレスを設定後、ＶＭＮ１２はＭＡＰ４２にて登録を行う。これはメッセージ４０７に示される。この登録後、ＭＡＰ４２のＢＣＥはさらに更新され、４０８に示されるようになる。次に、ＶＭＮ１２はそのＨＡ、すなわちＨＡ５８との登録を行う。ＨＡ５８へのＢＵはＡＲＯオプションを持たない普通のＭＩＰｖ６タイプのＢＵである。ＶＭＮ１２は、単純なＨＭＩＰｖ６処理によって上記ＨＡ５８での登録を行う。これは、ＶＭＮ１２はＭＡＰオプションとＡＲＯオプションの両方を処理するが、方法における変更点である。登録メッセージは４０９に示され、ＶＭＮ１２によりトンネルされる。ＨＡ５８は、この登録メッセージ４０９を適切に処理すると、応答メッセージ４１１を送信する。これはＢＡメッセージであり、このメッセージはＭＡＰ４２に受信され、ＶＭＮ１２へトンネルされる。ＭＡＰ４２にてさらに送られる前のＢＡのパケット構造が４１３に示される。ＭＡＰ４２は、ＡＲＯの再帰的検索メカニズムを利用してＶＭＮ１２のＲＣｏＡを探す。ＭＡＰ４２はＢＣＥ４０８を利用する。上記検索後、ＭＡＰ４２は、ＶＭＮ１２のＬＣｏＡ、ＭＲ２４のＬＣｏＡ、ＭＲ２５のＬＣｏＡなどのアドレスを取得する。これらのアドレスの順番を逆にしても、ＭＡＰ４２は、ピンポンルーティングを完全に解消し、理想的なトンネルを構築できる。このトンネルされたＢＡメッセージ４１２はＶＭＮ１２へと送られる。
【００６３】
ＨＡ５８での登録に続いて、ＶＭＮ１２はＣＮ７３とのバインディングを開始する。図２に示す従来技術のシナリオでも説明したように、ＲＣｏＡを用いてＣＮにてＡＲＯを行う場合、極度のルーティング準最適性が生じる。主要な発明では、この準最適性を避け、ＣＮ７３と通常のＨＭＩＰｖ６タイプの登録を行う。このことはメッセージ４１４に示される。上記登録が行われた後、ＣＮ７３のＢＣＥは４１５に示されるようになる。なお、ＢＣＥ４１５にはＡＲＯフィールドが存在しない。次に、ＣＮ７３はＶＭＮ１２へのデータ・パケットの送信を開始する。このデータ・パケットの宛先アドレスはＶＭＮ１２のＲＣｏＡである。このデータメッセージをメッセージ４１６に示す。このメッセージはＭＡＰ４２にてさらにカプセル化される。カプセル化されたパケットの構造を４１８に示す。ＭＡＰ４２は、ＡＲＯタイプの再帰的トレースを一回行うだけでＬＣｏＡを容易に取得できる。どのようにしてＭＡＰ４２のＢＣＥエントリをＲＣｏＡベースのＡＲＯオプションを用いてより理想的なものとするかは当業者であれば容易に理解するであろう。カプセル化されたメッセージ４１７は最終的にＶＭＮ１２に到達する。このように、図２及び図３で説明した従来技術のルーティング問題と比較すると、主要な発明は上記シナリオにおいてより最適化された経路を実現する。また、最適化ルーティングのみならず、この方法によれば所在管理効率も達成される。ここで唯一非効率なことと言えば、ＲＡが２種類のＡＲＯオプションを送信しなければならないということであり、それによって無線帯域幅がある程度消費されることとなる。
【００６４】
次に、ＶＭＮ１２はデータをＣＮ７３へ送信する。ＶＭＮ１２は、送信元アドレスがＶＭＮ１２のＲＣｏＡであり、宛先アドレスがＣＮ７３のアドレスであるデータ・パケットを作成する。ＶＭＮ１２はこのパケットをＭＡＰ４２へのトンネルにカプセル化する。ＶＭＮ１２は、ＭＡＰ４２にてＡＲＯタイプのＢＵを有するので、ＮＥＭＯ−ＦＷＤオプションをトンネルへ挿入する。ここでのパケット構造を４２１に示す。トンネルには、ホーム・アドレス宛先オプションとしてＶＭＮ１２のＲＣｏＡも含まれる。ＭＲ２４は、このカプセル化されたメッセージ４１９を受信すると、ＮＥＭＯ−ＦＷＤオプションを処理し、単に送信元アドレスをＭＲ２４のＬＣｏＡに変更する。ここでも同様に、上記処理を行うにはＭＲに変更を加える必要がある。ＭＡＰ４２にてＡＲＯタイプの再帰的バインディングを一度も行っていないにもかかわらず、ＭＲ２４は上記送信元アドレスの変更を行わなければならない。このような送信元アドレス変更後のＭＲ２４でのパケット構造を４２２に示す。ＭＲ２５は、このパケットを処理する際、トンネルの送信元アドレスを自身のＬＣｏＡに変更する。ＭＲ２５でのパケット構造を４２３に示す。最後に、ＭＡＰ４２は、このパケットを受信すると、ＶＭＮ１２のＲＣｏＡを用いて再帰的トレースを行い、ＭＲ２５のＬＣｏＡが得られるか否かを判定する。ＭＡＰ４２のトレースメカニズムは新しい発明のキャッシュ４０８を用いてＭＲ２５のＬＣｏＡを入手することができ、このアドレスはトンネルの送信元アドレスと一致するので、ＭＡＰ４２は適切にトンネリングを解除し、パケットをＣＮ７３へ送ることができる。このＣＮ７３へのデカプセル化されたデータメッセージはメッセージ４２０で示される。
【００６５】
本発明の別の好適な実施形態では、図４に示す主要な発明を実施する移動ホスト（ＶＭＮ）の機能アーキテクチャを説明する。図５は、図４に示すＶＭＮ１２の好ましい機能アーキテクチャ５００を示す。機能アーキテクチャ５００は、物理層、メディア・アクセス制御層、データリンク層などの下層プロトコル機能を実装するために必要なすべてのソフトウェア及びハードウェアから構成される下層プロトコルモジュール５０１を備えている。機能アーキテクチャ５００はさらにルーティング層５０２を備えている。このルーティング層は、図４に示す主要な発明で概説されたようなルーティングを行うために必要なすべてのソフトウェア及びハードウェアから構成されている。機能アーキテクチャ５００の最上層は、上位層プロトコル５０３を含む。この層は、トランスポート・プロトコル、セッション・プロトコル、アプリケーション・プロトコルを実装するために必要なすべてのソフトウェア及びハードウェアから構成されている。
【００６６】
ルーティング層５０２はさらに、ＩＰｖ６処理モジュール５０６、ＡＲＯモジュール５０８、ＨＭＩＰｖ６モジュール５０９、ＭＩＰｖ６モジュール５１０、新しい発明のモジュールであるＡＲＯ＋ＨＭＩＰ相互作用モジュール５０７を備えている。ＩＰｖ６処理モジュール５０６が担う処理操作としては、ＲＡの処理、リンク・ローカル・ルーティングの実行、ＩＣＭＰｖ６メッセージの送信・処理、ＩＰｖ６ヘッダの作成、アドレス設定、などが挙げられる。ＡＲＯモジュール５０８は、通常のＡＲＯメカニズムを実現するために必要なすべての機能を備えている。ＡＲＯモジュールには、ＡＲＯバインディング・リスト５１１が備え付けられている。このリストは通常のＡＲＯ操作が行われる際に更新される。そのような操作はＶＭＮがＭＡＰオプションもＲＣｏＡベースのＡＲＯオプションフィールドも処理しない場合に実行される。ＡＲＯバインディング・リスト５１１には、ＣＮのエントリや、ＣＮと通常のＡＲＯを確立するのに用いられるＡＲＯパラメータが含まれる。
【００６７】
ＨＭＩＰｖ６モジュール５０９は、一般的なＨＭＩＰｖ６プロトコルのすべての機能を実装している。この機能はＶＭＮがＭＡＰオプションしか処理しない場合に利用される。このような事態が起こり得るのは、ＶＭＮのアクセス・ルータがＡＲＯ対応のものでない場合、若しくは、ＶＭＮの何らかのポリシーセッティングによりそれが行われる場合である。ＨＭＩＰｖ６モジュール５０９には、先と同様に、ＨＭＩＰｖ６バインディング・リスト５１２が備え付けられている。このリストには、ＶＭＮがＣＮと完全なＨＭＩＰｖ６スタックを用いて行うすべての登録が含まれている。そのような通常のＨＭＩＰｖ６スタック操作は、ＲＡからＡＲＯオプションが一つも受信されず、ＭＡＰオプションのみが受信された場合に実行される。ＭＩＰｖ６モジュール５１０は、ＶＭＮでのＭＩＰｖ６の実装を示す。利用可能なＡＲＯオプションやＭＡＰオプションがないようなシナリオでは、モジュール５１０のみを起動することが有用である。さらに、このモジュール５１０のコードは、主要な発明で説明したようにＶＭＮがＣＮとＡＲＯを実行したくない場合に有用であり、また、ＨＭＩＰｖ６に関連する登録メカニズムに有用である。ここでも同様に、ＭＩＰｖ６モジュール５１０はそれに関連するバインディング・リスト５１３を備えている。このバインディング・リストには、ＶＭＮがＣＮと単純なＭＩＰｖ６登録を行うために用いるすべてのＣＮエントリや登録パラメータが含まれる。
【００６８】
このＡＲＯ及びＨＭＩＰｖ６の異種シナリオにおける中央コーディネーターとして機能する新しいモジュールが５０７で示される。このモジュールにも関連するバインディング・リストが備えられており、そのリストはＡＲＯ＋ＨＭＩＰバインディング・リスト５１４と呼ばれる。バインディング・リスト５１４には、ＡＲＯオプションとＭＡＰオプションがいずれもＶＭＮによって処理される場合のすべてのＣＮ登録及びＭＡＰ登録が含まれる。モジュール５０７は、ＡＲＯ及びＨＭＩＰｖ６の異種シナリオではより活動的であるが、どの時点にどのスタックをトリガーするかを決定するなど、その他のシナリオでもある程度活動的で・BR> る。モジュール５０７は、基本的に、インテリジェント・ユニットとして働き、ＶＭＮで行われるフローのニーズに応じて好適な処理を決定できる。このモジュール５０７の詳細ならびにこのモジュールがどのように他のモジュールと相互に作用するのかについて説明する前に、インターフェースについて以下に説明する。下層プロトコルモジュール５０１はインターフェース５０４を介してルーティング層モジュール５０２と通信を行う。このインターフェースはすべてのデータ・パケットを転送し、ルーティング層５０２と下層５０１の間のパケットを制御するのに用いられる。ルーティング層５０２と上位層５０３とはインターフェース５０５を介して通信を行う。このインターフェースは、ルーティング層５０２と上位層５０３との間でデータ・パケットをやり取りするのに用いられる。
【００６９】
ＩＰｖ６処理モジュール５０６は、インターフェース５１５を介してＡＲＯ＋ＨＭＩＰ相互作用モジュール５０７と通信を行う。ＡＲＯ＋ＨＭＩＰ相互作用モジュール５０７は、インターフェース５１９、５１８、５１６それぞれを介して、ＭＩＰｖ６モジュール５１０、ＨＭＩＰｖ６モジュール５０９、ＡＲＯモジュール５０８と通信を行う。ＭＩＰｖ６モジュール５１０とＨＭＩＰｖ６モジュール５０９は、インターフェース５２０を介して互いに通信を行う。同様に、ＭＩＰｖ６モジュール５１０はインターフェース５１７を介してＡＲＯモジュール５０８と通信を行う。なぜそのようなインターフェース５２０、５１７が存在するのかは当業者であれば容易に理解し得ることである。ＨＭＩＰｖ６やＡＲＯは基本的なＭＩＰｖ６プロトコルから派生する機能であるので、そのようなインターフェース５２０、５１７を備える機能アーキテクチャが存在するのは当然のことである。
【００７０】
ＡＲＯ＋ＨＭＩＰモジュール５０７は主要な機能を担い、ＲＡオプションを処理する役割を担う。これらのオプションはインターフェース５１５を介してＩＰｖ６ルーティングモジュール５０６から転送されることが好ましい。ＡＲＯ＋ＨＭＩＰモジュール５０７はオプションを監視し、トリガーする必要があるモジュールはどのモジュールか、又は、複数のモジュールをトリガーする必要があるか否かを決定する。利用可能なＡＲＯオプション及びＭＡＰオプションがある場合、相互作用モジュール５０７はＡＲＯモジュール、ＨＭＩＰｖ６モジュールと通信を行い、前述の主要な発明で概説されたような必要な処理を行う。
【００７１】
本発明のまた別の好適な実施形態では、図４に示す主要な発明を実施する移動ルータの機能アーキテクチャを説明する。図４のＭＲ２４及びＭＲ２５は図５に説明したものとほぼ同一のアーキテクチャや機能を有する。唯一の相違点は、図５に示したすべてのモジュールに加えて、ＭＲはＮＥＭＯ基本モジュールも備えているということである。ＡＲＯモジュールはこのＮＥＭＯ基本モジュールと相互に作用し、ＡＲＯ＋ＨＭＩＰモジュールもこのＮＥＭＯ基本モジュールと相互に作用する。また、ＭＲのＡＲＯ＋ＨＭＩＰモジュールは、ＲＡ内の別のＡＲＯオプションとしてのＲＣｏＡを送信するタイミングを決定するメカニズムを有することが好ましい。
【００７２】
本発明のさらに好適な実施形態では、図４に示す主要な発明を実施するＭＡＰの機能アーキテクチャを説明する。図４のＭＡＰ４２は、図６に示すような機能アーキテクチャを有することが好ましい。ＭＡＰの機能アーキテクチャは図６では６００で示される。このアーキテクチャ６００は、図４で説明した主要な発明に示されるようなＭＡＰ機能を行うために必要なすべてのソフトウェア及びハードウェアから構成されている。ＭＡＰは主にルータなので、下層プロトコルと中間層プロトコルしか実装されていない。ここでも先と同様に、下層プロトコル６０１は、物理層、メディア・アクセス制御層、データリンク層の機能を実装するために必要なすべてのソフトウェア及びハードウェアから構成される。ルーティング層６０２は、異種のルーティングモジュールやバインディング・キャッシュ・エントリ・テーブルから構成される。ルーティング層６０２は、インターフェース６０９を介して下層プロトコル６０１と通信を行う。このインターフェース６０９は、層６０１と６０２の間でのデータの転送や、パケットの制御に用いられる。
【００７３】
ルーティング層６０２はさらに、ＩＰｖ６ルーティングモジュール６０３、決定部６０４、ＮＥＭＯ基本＋ＨＭＩＰｖ６統合モジュール６０５、ＡＲＯモジュール６０７の４つの主要なルーティング機能モジュールを備えている。ＡＲＯモジュール６０７には登録テーブル６０８と呼ばれるバインディング・キャッシュ・テーブルが備え付けられ、ＮＥＭＯ基本＋ＨＭＩＰｖ６統合モジュール６０５にも同様に登録テーブル６０６と呼ばれるバインディング・キャッシュ・エントリ・テーブルが備え付けられている。主要な発明を実施するＭＡＰはそのアーキテクチャに多くの変更を加える必要がないことは当業者であれば十分に理解し得ることである。しかしながら、決定部６０４が、処理及び組織化を簡素化するために新たにアーキテクチャに組み込まれる。モジュール６０３に関連するＩＰｖ６ルーティングは、全リンクローカルタイプのルーティングや、一般的なＩＰｖ６ルーティング動作に定められたようなデフォルト・ルータを介したルーティングにも対応する。ＡＲＯモジュール６０７は、すべてのＡＲＯタイプの登録受諾決定を行い、かつ、パケットがＭＡＰのイングレス及びエグレス・インターフェースにて受信した際、特定のＲＣｏＡをトレースする。このＲＣｏＡは関連するテーブル６０８にて登録される。ＡＲＯモジュールのＢＣＥ６０８は、ＭＡＰドメイン内のノードがＡＲＯオプションとＭＡＰオプションの両方を処理し、ＭＡＰにて適切な登録を行う場合に追加されるエントリから構成される。ＮＥＭＯ基本＋ＨＭＩＰｖ６統合モジュール６０５は基本的に一般的なＨＭＩＰｖ６のＭＡＰ機能モジュールと類似している。ＭＡＰがＰＳＢＵタイプの登録を受諾し、必要な場合はそれらを処理できるよう、ＮＥＭＯ基本コード又は機能はこのモジュールに組み込まれる。
【００７４】
決定部６０４の主要な機能は、モジュール６０３から転送されたパケットを調べた後にトリガーする必要があるモジュールはどのモジュールか決定することである。登録にＡＲＯオプションが含まれる場合、決定部６０４はその登録パケットをＡＲＯモジュール６０７へ転送し、それ以外の場合は、パケットをモジュール６０５に転送する。場合によってはテーブル６０６からの登録が最終的にテーブル６０８へ転送されることもある。例えば、最上位の移動ルータからの登録が最初は登録テーブル６０６へと転送され、ＡＲＯモジュール６０７に送り返される場合もある。ＩＰｖ６ルーティングモジュール６０３と決定部６０４の相互作用はインターフェース６１０を介して行われることが好ましい。モジュール６０５、６０７と決定モジュール６０４の間の相互作用はインターフェース６１２、６１３それぞれを介して行われることが好ましい。図６では、ＨＭＩＰｖ６モジュール６０５とＡＲＯモジュール６０７との間にインターフェースが存在する。このインターフェースは現時点ではそんなに利用されていないが、将来的にモジュール間の通信を高速化するために進化したシステムに利用可能である。
【００７５】
本発明の別の好適な実施形態では、ＨＭＩＰｖ６及びＡＲＯの異種シナリオにおいて、移動端末や移動ルータに変更を加えずに、ＶＭＮとＣＮの間で経路最適化を達成するための方法が提供される。その代わりに、ＭＡＰ機能に変更が加えられる。この場合も先と同様に、ＶＭＮ、ＭＲ、ＭＡＰにはＡＲＯ及びＨＭＩＰｖ６の両方の機能が実装されるものとする。また、ＶＭＮとＭＲはＡＲＯオプション及びＭＡＰオプションの両方を処理し、ＨＡはＡＲＯ対応のものとする。ＭＡＰが一般的なＡＲＯトレースとは異なるトレースメカニズムを用いて、再帰的検索を一回行うことにより、好ましくは一つのトンネルを介して最適にＶＭＮのＲＣｏＡに到達するのに必要なすべてのＬＣｏＡを取得できるよう、インテリジェント・トレース・メカニズムをＭＡＰにて設計し実装する。これらはすべてシステム内の一般的なＡＲＯ又はＨＭＩＰｖ６動作に何ら変更を加えずに実現される。この方法については、図７のメッセージ・シーケンス・チャートを用いてさらに詳しく説明する。
【００７６】
図７では、ＶＭＮ１２がＭＲ２４及びＭＲ２５の配下にネストされる。ＭＲ２５はＡＲ３４に直接接続され、アーキテクチャ内にはＭＡＰは一つしかなく、それがＭＡＰ４３である。ＶＭＮ１２、ＭＲ２４、ＭＲ２５のホーム・エージェントはそれぞれ、ＨＡ５８、ＨＡ５７、ＨＡ５６である。この図７では、すべてのシグナリングは明示されていない。シグナリングの詳細な説明については、同様のシナリオを説明した図３を参照されたい。ＭＲ２５はＡＲ３４からＲＡ７００を受信する。このＲＡにはＭＡＰオプションしか含まれない。その後、ＭＲ２５はＲＣｏＡ及びＬＣｏＡを得てＭＡＰ４３に登録する。この登録メッセージ７０１を図７に示す。上記登録後、ＭＲ２５は登録メッセージ７０２を用いてＨＡ５６に登録を行う。ここではトンネリング手順やルーティングパスは完全には図示されていない。この場合も先と同様に、ＭＲ２５はＲＡ７０３を送信することでＭＡＰオプション及びＡＲＯオプションを送信する。ＡＲＯオプションは一つしかなく、その値はＭＲ２５のＨｏＡである。両オプションを受信後、ＭＲ２４は両オプションを処理し、ＭＡＰ４３にＡＲＯタイプの登録を送信する。このことはメッセージ７０４に示される。ここでもトンネリング手順やルーティングパスは完全には図示されていない。
【００７７】
ＭＲ２５は、ＭＲ２５のＨｏＡが組み込まれているＭＡＰ４３からのＡＣＫを受信すると、ＭＲ２５がＨｏＡとＲＣｏＡを登録するＭＡＰとＡＲＯタイプの再帰的登録を行う。この再帰的登録はメッセージ７０５に示される。ＭＡＰ４３との登録を行った後、ＭＲ２４はＨＡ５７との登録を行う。これも同様にメッセージ７０６に示され、ここでもトンネリング手順やルーティングパスは完全には図示されていない。この場合も先と同様に、ＭＲ２５のＨｏＡがＨＡ５７から送信されたＡＣＫに組み込まれているので、ＭＲ２５はＭＡＰにてＡＲＯタイプの再帰的登録を行う。この再帰的登録メッセージは７０７に示される。ルーティング非効率を解消するため、ＭＲとＶＭＮは、ＨＡ及びＣＮと通信を行う際、ＡＲＯオプションを使わなくてもよい。上記方法は図４に示す主要な発明において採用されている。同様のメカニズムをこの主要な発明の変形例でも採用できる。
【００７８】
ＨＡ５７とのバインディング登録後、ＭＲ２４はＲＡメッセージ７０８を送信する。ここでも同様に、ＡＲＯオプションとＭＡＰオプションはいずれもＶＭＮ１２によって処理される。その後、ＶＭＮ１２はＡＲＯオプションを用いてＭＡＰ４３との登録を開始する。このメッセージは７０９に示され、ここでもトンネリング手順やルーティングパスは完全には図示されていない。ＡＲＯオプション値はＭＲ２４のＨｏＡである。ＭＡＰ４３は、ＭＲ２４のＨｏＡに対するエントリを持っていないので、このＡＣＫに組み込まれた値をＶＭＮ１２に送信する。これにより、ＭＲ２４は、ＨｏＡとＲＣｏＡをＭＡＰ４３に登録するための、ＭＡＰ４３にてＡＲＯタイプの再帰的バインディングを行うことになる。このメッセージは７１０に示され、ここでもトンネリング手順やルーティングパスは完全には図示されていない。最終的に、ＭＡＰ４３のＢＣＥは７１１に示されるようになる。このＢＣＥを注意深く見てみると、このキャッシュにはＶＭＮ１２のＲＣｏＡに到達するのに必要なすべてのＬＣｏＡが存在し、必要なのはＭＡＰ４３でのより高度なトレースだけであることは当業者には明らかである。
【００７９】
上記登録後、ＶＭＮ１２はＣＮ７４との登録を行う。ＶＭＮ１２はＣＮ７４にてＨＭＩＰｖ６タイプの登録のみを行う。それにより、そこではＶＭＮ１２のＲＣｏＡとＶＭＮ１２のＨｏＡが登録される。この登録は図７には図示されていない。その後、ＣＮ７４はデータ・パケットをＶＭＮ１２に送信し、これがメッセージ７１２に示される。ＭＡＰ４３はこのパケットを受信し、インテリジェント・トレースによりＶＭＮ１２のＲＣｏＡに到達するのに必要なＬＣｏＡを得る。インテリジェント・トレースでは、ＡＲＯタイプの再帰的トレースがまずは行われる。例えば、ＭＡＰ４３がＶＭＮ１２のＲＣｏＡに対してそのようなＡＲＯタイプのトレースを実行する場合、得られるアドレスは、ＶＭＮ１２のＬＣｏＡ、ＭＲ２４のＲＣｏＡ、ＭＲ２５のＲＣｏＡである。そのような基本的なトレースの後、ＭＡＰは上記得られたエントリがＡＲＯバインディング・キャッシュの第１列若しくはＨｏＡ列にあるか否かを調べる。もしあれば、ＭＡＰはさらにＲＣｏＡに関連する気付アドレスを調べ、ＲＣｏＡを得られた関連するＬＣｏＡと交換する。例えば、ＡＲＯトレース後ＢＣＥ７１１がトレースされる場合、インテリジェント検索メカニズムは、ＭＲ２４のＲＣｏＡやＭＲ２５のＲＣｏＡに対するエントリを探し出すことができる。
【００８０】
その後、インテリジェント・トレースにより、ＭＲ２４のＬＣｏＡ、ＭＲ２５のＬＣｏＡが得られ、ＭＲ２５のＬＣｏＡを宛先アドレスとして用い、またＭＲ２４のＬＣｏＡ、ＶＭＮ１２のＬＣｏＡ、ＶＭＮ１２のＲＣｏＡをＲＨ２コンテンツとして用いて、トンネル構造を形成する。これはパケット構造７１４により示される。最終的に、一重にカプセル化されたデータメッセージ７１３はＶＭＮ１２に到達する。ＭＡＰ４３にてインテリジェント・トレースを行うことで、ＭＡＰ４３のエントリを利用するだけで、順方向の最適化経路が得られる。ＶＭＮ１２は、ＣＮ７４へデータ・パケットを送信する際、先と同様に、送信元アドレスがＶＭＮ１２のＲＣｏＡであり、宛先アドレスがＣＮ７４のアドレスであるパケットを作成する。このパケットはＭＡＰ４３へのトンネルにカプセル化され、７１７に示されるようなパケット構造となる。トンネルの送信元アドレスがＶＭＮ１２のＬＣｏＡであり、宛先アドレスがＭＡＰ４３のアドレスである。ＭＲ２４は、このメッセージ７１５を受け取ると、ＮＥＭＯ‐ＦＷＤオプションも調べる。
【００８１】
理想的には、この発明の第２変形例ではＭＲの機能に変更を加えなくてもよく、図３の従来技術のシナリオで説明したように、送信元アドレスをＲＣｏＡに変更すればよい。しかしながら、ＭＲの実装に小さい変更を加え、代わりにＬＣｏＡを組み込むことが好ましい。これにより、図３で説明した従来技術のシナリオと比べて性能がさらに向上する。そのようにＭＲ機能に小さい変更を加えることで、ＭＲ２４では７１８に示すパケット構造が得られる。この場合も先と同様に、パケットはＭＲ２５に到達し、ＭＲ２５も送信元アドレスをＭＲ２５のＬＣｏＡに変更する。最後に、ＭＡＰ４３はデトンネリングを実行する。ここで、ＭＡＰ４３は、トンネル内にホーム・アドレス宛先オプションとして付加されたＶＭＮ１２のＲＣｏＡに対してトレースを行う場合にＭＲ２５のＬＣｏＡを得られるか否かを判別する必要がある。前述のインテリジェント・トレース・メカニズムを利用することで、ＭＡＰ４３は上記アドレスを入手し、トンネルを容易に確認し、トンネルを適切に除去し、さらにデータ・パケットをＣＮ７４へ送ることが可能である。このトンネリングを伴わずにＭＡＰ４３からさらに送られるメッセージを７１６に示す。他の方法では、ＭＲに変更を加えずにインテリジェント・トレース設備を配置した場合、ＶＭＮ１２とＣＮ７４との間の最適化経路は逆方向に得られる。これらのメッセージを７２０、７２１、７２２、７２３に示す。このような場合、ＭＡＰ４３は通常のＡＲＯトレースによりトンネルの確認・除去を行わなければならないが、トンネル除去にインテリジェント・トレースを行わなくてもよい。パケット構造の詳細は図３に示す従来技術のシナリオで説明したものと同じなので、これ以上説明しない。パケット構造７２４、７２５、７２６は、それぞれ、図３の３４０、３４２、３４４に示されるものと同一である。
【００８２】
主要な発明の第２変形例では、ＭＡＰにて重要な変更がなされる。このため、ＭＡＰには図６とは異なる新しい機能が必要である。図７に示した主要な発明の第２変形例を実施する新しいＭＡＰ機能を図８に示す。図８において、８００はこの高度なＭＡＰの機能アーキテクチャを示す。その機能アーキテクチャは、下層プロトコルモジュール８０１とルーティング層モジュール８０２とを備えている。ルーティング層モジュール８０２は、ＩＰｖ６ルーティングモジュール８０３、決定部８０４、ＡＲＯモジュール８０７、ＮＥＭＯ＋ＨＭＩＰｖ６統合モジュール８０５をさらに備えている。これらのモジュールは、インターフェース８１１、８１２、８１３、８１４、８１５を介して互いに通信を行う。ＮＥＭＯ基本＋ＨＭＩＰｖ６統合モジュール８０５は登録部８０６を備え、ＡＲＯモジュール８０７も登録部８０８を備える。これらのモジュールの機能や各インターフェースは図６で詳しく説明したものと同一である。唯一の新しいユニットはインテリジェント処理部８０９であり、ＡＲＯモジュール８０７の内部に実装される。このインテリジェント処理部８０９はＡＲＯ検索結果を用いてさらに登録テーブル８０８にクエリーを行ってＬＣｏＡのエントリを入手する。インテリジェント・トレース部は、ＡＲＯ検索から得られたエントリを調べ、特定のＡＲＯ検索エントリがＲＣｏＡであるかＬＣｏＡであるかをチェックする。ＲＣｏＡの場合、インテリジェント処理部８０９はＡＲＯ登録テーブル８０８のホーム・アドレス列を調べて関連するＬＣｏＡを取得し、ＡＲＯ検索から得られたＲＣｏＡ値を、取得したＬＣｏＡ値と交換する。アドレスがＲＣｏＡであるか否かは、プレフィックスにより、若しくは、テーブル８０８を調べてＡＲＯテーブルのホーム・アドレス列にエントリが存在するか否かをチェックすることにより判定する。要約すれば、インテリジェント処理部８０９が行うことは、８０８を調べてＲＣｏＡとＬＣｏＡの値を交換することだけである。
【００８３】
本発明の別の好適な実施形態では、図７に示すＭＡＰ４３の動作について、図９のフローチャートを用いてさらに詳しく説明する。パケットがＭＡＰ４３に届くと、ステップ９００を実行して、まず、パケットがイングレス・インターフェースに届いたのか、それともエグレス・インターフェースに届いたのかを判別する。パケットがエグレス・インターフェースを介して届いている場合、ステップ９０１を実行する。このステップでは、宛先アドレス・プレフィックスとＭＡＰのアドレス・プレフィックスとが同じであるか否かを判定する。ステップ９０１でｆａｌｓｅ（偽）と判定された場合、ステップ９０２を行い、図８の８０３に示すようなＩＰｖ６ルーティングメカニズムによってパケットが通常通りに送られる。宛先アドレス・プレフィックスがＭＡＰアドレス・プレフィックスと同一である場合、ステップ９０３が実行される。ステップ９０３では、パケット宛先アドレスがＡＲＯモジュール内の登録部８０８に属するか否かを判定する。そのような判定は決定部８０４によって行われる。ステップ９０３でｆａｌｓｅ（偽）と判定された場合、パケットはインターフェース８１４を介してＨＭＩＰ部８０５に送られる。反対にステップ９０３でｔｒｕｅ（真）と判定された場合、パケットはＡＲＯモジュール８０７へ転送される。その直後のステップであるステップ９０４では、ＡＲＯタイプの再帰的トレースが行われる。基本的なＡＲＯトレースステップに続いて、ステップ９０５が行われ、ＡＲＯトレースにより得られた検索内容がインテリジェント・トレース部８０９へ転送される。インテリジェント・トレース部で実行されるステップを９０６で示す。このステップ９０６では、ＲＣｏＡとＬＣｏＡとの交換が行われる。この交換の後、インテリジェント・トレース部は内容をＡＲＯモジュールに送り返し、ＲＨ２を作成する。これをステップ９０７に示す。
【００８４】
ステップ９００でパケットがイングレス・インターフェースに届いた場合、ステップ９０８が実行され、宛先アドレスがＭＡＰであるか否かを判定する。ステップ９０８でｆａｌｓｅ（偽）と判定された場合、パケットはＩＰｖ６ルーティングモジュール８０３によって処理される。そのような処理がステップ９０９に示される。ステップ９０８でｔｒｕｅ（真）と判定された場合、ステップ９１０が実行され、ＮＥＭＯ‐ＦＷＤオプションが存在するか否かを判定する。ステップ９１０でｆａｌｓｅ（偽）と判定された場合、ステップ９１１が行われ、パケットはＨＭＩＰｖ６モジュール８０５へ引き渡される。ステップ９１０でｔｒｕｅ（真）と判定された場合、ステップ９１２が実行される。この処理はＡＲＯモジュール８０７により行われる。このステップ９１２は、ＡＲＯメカニズムが利用する有効なトンネル除去手順である。
【００８５】
以上、本発明を最も実用的で好適と思われる実施形態で説明したが、当業者であれば、本発明の要旨及び範囲から逸脱することなく、設計の詳細及びパラメータに種々の変更がなし得ることを理解できるだろう。例えば、本発明は、ネストされた状態の移動ネットワークにおいて使用される経路最適化メカニズムとしてＡＲＯスキームを採用している。本発明は、何らかの方法で移動アクセス・ルータのアドレスを利用して経路最適化を達成するものなど、他の経路最適化メカニズムにも適用可能であることは当業者により理解されるであろう。また、本発明は、ローカル・モビリティ管理プロトコルとして、ＨＭＩＰｖ６を採用している。本発明は、その他のローカル・モビリティ管理プロトコルにも適用可能であることは当業者により理解されるであろう。さらに、本発明では、ＭＡＰを含むローカル・モビリティ管理ドメイン、複数のＬＭＡを含むＮｅｔＬＭＭドメイン、複数のプロキシ・ホーム・エージェントを含むプロキシ・モバイルＩＰｖ６ドメインにおけるローミングについて論じている。本発明は、異なるタイプのモビリティ管理アンカーから成る他のローカル・モビリティ管理ドメインにも適用可能であることは当業者により理解されるであろう。
【産業上の利用可能性】
【００８６】
本発明は、ＡＲＯやＨＭＩＰｖ６が混在する環境下でも有用な機構を提供できるという利点を有し、パケット交換通信の分野に適用可能である。 
【図１】
2010541304.tif 000003
【図２】
2010541304.tif 000004
【図３】
2010541304.tif 000005
【図４】
2010541304.tif 000006
【図５】
2010541304.tif 000007
【図６】
2010541304.tif 000008
【図７】
2010541304.tif 000009
【図８】
2010541304.tif 000010
【図９】
2010541304.tif 000011
【手続補正書】
【提出日】平成21年8月14日(2009.8.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを備える通信ノードのシステムであって、
ＶＭＮ、ＭＲ、ＭＡＰはＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡはＡＲＯプロトコルを実装し、
ＭＲにより送信されるルータ通知には２種類のＡＲＯオプションが含まれ、一つはＭＲのホーム・アドレスが組み込まれたＡＲＯオプションであり、もう一つはＭＲのＲＣｏＡが組み込まれたＡＲＯオプションであり、
ＶＭＮ、ＭＡＰ、ＭＲはさらに処理を行うためＲＣｏＡを含むＡＲＯオプションを利用するシステム。
【請求項２】
ＶＭＮとＭＲがＭＡＰに登録を行う際、ＡＲＯオプション内のＲＣｏＡ値を使用する請求項１に記載のシステム。
【請求項３】
請求項１に記載のＶＭＮに使用される装置。
【請求項４】
請求項１に記載のＭＲに使用される装置。
【請求項５】
ＬＣｏＡを特定するためのトレースを行って、ＢＣＥ内のＡＲＯオプションエントリに基づく任意のＲＣｏＡに到達することを特徴とする請求項１に記載のＭＡＰに使用される装置。
【請求項６】
ＶＭＮ、ＭＲ、ＭＡＰ、ＨＡ、ＣＮを備える通信ノードのシステムであって、
ＶＭＮ、ＭＲ、ＨＡ、ＭＡＰ、はＡＲＯプロトコル及びＨＭＩＰｖ６プロトコルを実装し、ＨＡはＡＲＯプロトコルを実装し、
ＭＲにより送信されるルータ通知には１種類のＡＲＯオプションしか含まれず、そのＡＲＯオプションは移動アクセス・ルータのホーム・アドレスを定義し、
ＶＭＮとＭＲとがＢＣＥのエントリを用いてＡＲＯオプションとＭＡＰオプションの両方を処理する場合、ＭＡＰは一段階のトレースによってＶＭＮのＲＣｏＡに関連するＬＣｏＡが得られるようなインテリジェント・トレースを行うシステム。
【請求項７】
ＭＡＰがインテリジェント・トレースを行うためのインテリジェント・トレース部を実装する、ことを特徴とする請求項６に記載のＭＡＰに使用される装置。
【請求項８】
請求項６に記載のＭＡＰがインテリジェント・トレースを行うために使用する方法であって、
ＡＲＯ方法を用いたトレースで得られたアドレスがＲＣｏＡであるかＬＣｏＡであるかを確認する工程と、
ＡＲＯ方法により得られたアドレスがＲＣｏＡである場合に、ＢＣＥからＲＣｏＡに対応するＬＣｏＡを特定する工程と、
を含む方法。
【請求項９】
請求項６に記載のＭＲがデータ・パケットを逆方向に送る際、ＲＣｏＡではなくＬＣｏＡにアドレス・スワップを行うために使用する方法であって、
ＭＲはＮＥＭＯ−ＦＷＤオプションを見つけた場合にそのようなスワップを行う方法。
【請求項１０】
請求項６に記載のＭＡＰがイングレス・インターフェースを介して受信するパケットのデトンネリングを行うために使用する方法であって、  トンネル除去処理を行うためにインテリジェント・トレース・メカニズムが拡張される方法。
【国際調査報告】
2010541304.tif 000012
2010541304.tif 000013