JP4344745B2 - 動的ネットワーク管理システム及び動的ネットワーク管理装置 - Google Patents

Description

本発明は、モバイルネットワークに対して、グローバルな接続性を提供するための通信ネットワークに係る技術に関する。

インターネットは、現在、固定ネットワークノードを含むシステムを中心として、多数のデータ通信ネットワークが配置される段階にまで発達している。これらのデータ通信ネットワークは、エッジネットワークとして知られており、また、これらのエッジネットワークによって取り囲まれている固定ネットワークノードを含むシステムは、コア（core）ネットワークとして知られている。無線技術の出現及び発展によって、これらのエッジネットワークの中には、無線通信による方法を利用するものがますます増加してきており、モバイルネットワークと呼ばれる特別なエッジネットワーク、すなわち、移動を行うネットワークを形成している（下記の非特許文献１を参照）。

モバイルネットワークは、基本的には、ネットワーク全体がインターネットへの接続点を変更するノードのネットワークである。モバイルネットワークは、通常、モバイルルータ（モバイルネットワークをインターネットに接続するルータ）を必要とし、モバイルルータによって、異なるアクセスルータ（アクセスルータそのものが移動可能であってもよい）間におけるインターネットへの接続点の変更が行われる。モバイルネットワークの例としては、人間に付随したネットワーク（パーソナルエリアネットワーク、又は、ＰＡＮとして知られている）や、自動車、列車、船、航空機のような乗り物に配置されたセンサを含むネットワークなどが挙げられる。また、飛行機、列車、バスなどのような大量輸送システムでは、乗客は、ラップトップやパーソナル・デジタル・アシスタンス（ＰＤＡ）、携帯電話などを用いてリモートホストにアクセスすることによって、乗り物内からインターネットへのアクセスが実現されるようにすることも可能である。このようなモバイルネットワーク内の各ノードは、通常、中央の装置（すなわち、モバイルルータ）に接続されており、ネットワークが移動する場合でも、各ノードは、その接続点の変更を行わない。その代わり、ネットワーク全体が移動するように、モバイルルータによって接続点の変更が行われる。

基本的には、ネットワーク全体が移動する場合に、そのネットワーク内のノードに対して、インターネット接続性を途切れることなく提供することが、移動を行うネットワークにおける課題である。移動するネットワーク内に存在するノードは、ネットワークがインターネットへの接続点を変更していることに気付かない可能性がある。この点に関しては、モビリティサポートの古典的問題に言及しているインターネットプロトコルバージョン４（ＩＰｖ４）（下記の非特許文献３を参照）におけるモバイルＩＰｖ４（下記の非特許文献２を参照）や、インターネットプロトコルバージョン６（ＩＰｖ６）（下記の非特許文献５を参照）におけるモバイルＩＰｖ６（下記の非特許文献４を参照）では、取り扱われていない。なお、非特許文献２、４では、ネットワーク全体に対してではなく、個々のホストに対してモビリティサポートを提供することが、主要な目的とされている。

モバイルＩＰでは、各モバイルノードは不変のホームドメインを有している。モバイルノードが、自身のホームネットワークに接続されている状態では、そのモバイルノードには、ホームアドレスとして知られる不変のプライマリグローバルアドレスが割り当てられる。一方、モバイルノードが自身のホームネットワークから離れている状態、すなわち、他のフォーリンネットワークに接続されている状態では、モバイルノードには、通常、気付アドレス（care-of-address）として知られる一時的なグローバルアドレスが割り当てられる。モビリティサポートのアイデアは、たとえモバイルノードが他のフォーリンネットワークに接続されている状態でも、モバイルノードがホームアドレスで到達可能となるようにするものである。このアイデアは、非特許文献２、４において、ホームエージェントとして知られるホームネットワークのエンティティの導入によって実現されている。モバイルノードは、バインディングアップデートとして知られるメッセージを使用して、ホームエージェントに対して、気付アドレスの登録を行う。ホームエージェントは、モバイルノードのホームアドレスあてのメッセージを受信（intercept）し、IP-in-IPトンネリング（下記の非特許文献６、７を参照）を使用して、モバイルノードの気付アドレスにパケットを転送する機能を有している。IP-in-IPトンネリングでは、オリジナルのＩＰパケットが別のパケットでカプセル化される。なお、オリジナルのパケットはインナパケット（inner packet）と呼ばれることがあり、インナパケットをカプセル化する新たなパケットはアウタパケット（outer packet）と呼ばれることがある。

各ホストのためのモビリティサポートの概念をネットワークのためのモビリティサポートに拡張して、モバイルネットワークが接続するインターネット上の位置に依存せずに、プライマリグローバルアドレスによって、モバイルネットワーク内に存在するノードを到達可能状態とすることが、解決すべき問題である。これに対し、移動するネットワークの問題を解決するための主要な試みがいくつか存在している。これらはすべて、モバイルＩＰ（非特許文献２、４を参照）に基づくものである。

移動を行うネットワークにおける解決方法の１つが、下記の特許文献１によって提案されている。ここでは、モバイルネットワークをコントロールするモバイルルータは、ホームドメインに存在する状態においては、あるルーティングプロトコルを用いて、モバイルネットワークによって送受信されるパケットのルーティングを行う。一方、モバイルルータ及びそのモバイルネットワークがフォーリンドメインに移動した場合には、モバイルルータは、ホームエージェントに対して、その気付アドレスの登録を行う。その後、モバイルルータとホームエージェントとの間でIP-in-IPトンネルがセットアップされ、ホームドメインに存在していたときに使用されていたルーティングプロトコルが、再度、IP-in-IPトンネル上で実行される。すなわち、これによって、モバイルネットワークに向かうすべてのパケットは、ホームエージェントによって受信（intercept）された後、IP-in-IPトンネルを通じて、モバイルルータに転送されるようになり、モバイルルータから、モバイルネットワーク内のホストに向けて、パケットが転送される。また、モバイルネットワーク内に存在するノードが、ネットワーク外に向けてパケットを送信する場合には、モバイルルータが、そのパケットを受信（intercept）した後、IP-in-IPトンネルを通じて、ホームエージェントにパケットを送信し、ホームエージェントから所定の受信者に向けて、パケットが送信される。

また、上述の解決方法とほぼ同様の解決方法が、下記の特許文献２にも開示されている。なお、特許文献２では、特に、ＩＰｖ６（非特許文献５を参照）に対するサポートについてのみ言及されている。

様々な無線技術（すなわち、ブルートゥース、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ、ウルトラワイドバンド、赤外波、一般的なパケット無線サービス）が存在する状況では、入れ子状態のモバイルネットワーク（すなわち、別のモバイルネットワーク内に存在するモバイルネットワーク）が存在するようになることも考えられる。この入れ子状態によって、ピンポンルーティングとして知られている問題が発生するが、これに対して、特許文献１では、入れ子トンネル（nested tunnel）による解決方法が提案されている。入れ子トンネルは、あるモバイルルータと、そのモバイルルータのホームエージェントとの間で確立されたトンネルが、別のモバイルルータと、その別のモバイルルータのホームエージェントとの間で確立された別のトンネルによってカプセル化された状態である。しかしながら、このトンネルの入れ子化では、パケットが最終的な送信先に到達するまでの間に、１つ以上のホームエージェントを経由することになるので、パケットの伝送時間は増加することとなる。さらに、複数のカプセル化によって、パケットサイズも増大し、不要なパケットの断片化が生じる可能性もある。

この問題を解決するために、下記の非特許文献８において、別の解決方法が提案されている。この解決方法は、リバースルーティングヘッダを使用することによって、モバイルネットワークが入れ子状態となる場合（すなわち、モバイルネットワークが別のモバイルネットワークに接続する場合）に、過度のカプセル化による多重が起こらないようにするものである。ここでは、最も低次のモバイルネットワークが、そのホームエージェントへのトンネルパケットに、リバースルーティングヘッダをセットする。このパケットの経路上に存在する高次のモバイルルータは、このパケットを受信（intercept）した場合でも、別のIP-in-IPトンネルにおけるカプセル化を行わず、その代わりに、パケットのソースアドレスをリバースルーティングヘッダにコピーするとともに、ソースアドレスに自身の気付アドレスを挿入する。この方法によって、最初のモバイルルータのホームエージェントは、パケットを受信した場合に、最初のモバイルルータとの間の経路に存在するモバイルルータを把握することができるようになる。さらに、ホームエージェントが、最初のモバイルルータに向けて、受信（intercept）したパケットを転送する場合には、拡張タイプ２ルーティングヘッダを利用することによって、パケットが、他の高次のモバイルルータを経由して最初のモバイルルータに直接送られるようになる。

一方、非特許文献８におけるリバースルーティングによる解決方法では、セキュリティが重要な問題の１つであるが、下記の非特許文献９において、入れ子トンネルを最適化するための問題の解決方法が提案されている。この解決方法は、アクセスルータオプション（ＡＲＯ：Access Router Option）による解決方法（ＡＲＯソリューション）として知られており、ここでは、モバイルＩＰｖ６で明記されているモビリティヘッダに新たなオプションが定義される。送信者（すなわち、モバイルルータ又はモバイルホスト）から受信者（すなわち、ホームエージェント又は通信相手ノード）に対して、この新たなオプション（アクセスルータオプション）によって、送信者が接続されているアクセスルータのプライマリグローバルアドレスが通知される。アクセスルータオプションを有するバインディングアップデートメッセージを送信した後、モバイルノード（モバイルルータ又はモバイルホスト）は、「direct-forwarding-request（ダイレクトフォワーディングリクエスト：直接転送要求）」信号と呼ばれる特別な信号を、送出するデータパケット内に挿入する。この信号によって、上流のモバイルアクセスルータは、その送信先アドレスに向けて、自らのバインディングアップデートを送信する。このプロセスは、最上層のモバイルルータに到るまで繰り返し行われ、すべての上流のモバイルアクセスルータが、送信先に向けてバインディングアップデートを送信することによって、その送信先は、モバイルノードが接続されている一連のモバイルアクセスルータを把握することが可能となる。また、この方法では、拡張タイプ２ルーティングヘッダの構築も可能であり、送信先のノードが、モバイルノードに対してパケットを送り返す場合に、パケットにルーティングヘッダを埋め込み、一連のモバイルアクセスルータを経由して、パケットを直接モバイルノードにルーティングすることも可能である。
Devarapalli, V., et. al., "NEMO Basic Support Protocol", IETF Internet Draft: draft-ietf-nemo-basic-02.txt, Dec 2003. Perkins, C. E. et. al., "IP Mobility Support", IETF RFC 2002, Oct 1996. DARPA, "Internet Protocol", IETF RFC 791, Sep 1981. Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-18.txt, Work In Progress, June 2002. Deering, S., and Hinden, R., "Internet Protocol Version 6 (IPv6) Specification", IETF RFC 2460, Dec 1998. Simpson, W., "IP in IP Tunneling", IETF RFC 1853, Oct 1995. Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6", IETF RFC 2473, Dec 1998. Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and Its Application to Mobile Networks", Internet Draft: draft-thubert-nemo-reverse-routing-header-04.txt, Work In Progress, Feb 2004. Ng, C. W., and Tanaka, T., "Securing Nested Tunnel Optimization with Access Router Option", Internet Draft: draft-ng-nemo-access-router-option-00.txt, Work In Progress, Oct 2002. Narten, T., Nordmark, E., and Simpson, W., "Neighbour Discovery for IPv6", IETF RFC 2461, Dec 1998. Patridge, C., and Jackson, A., "IPv6 Router Alert Option", IETF RFC 2711, Oct 1999. Leung, K. K., "Mobile IP mobile router", US Patent 6,636,498, Oct 2003. Markki, O. E., et. al., "Mobile Router Support for IPv6", US Patent Application US20030117965A1, Mar 2002.

送信者は、アクセスルータによってブロードキャストされるルータ通知メッセージを通じて、アクセスルータのプライマリグローバルアドレスを知ることが可能である。なお、ルータ通知に関しては、非特許文献１０に明記されている。また、非特許文献９では、その解決方法をサポートするアクセスルータは、能動的に、その内側（下流）ネットワーク向きのインタフェースであるイングレスインタフェース（ingress interface）から送信するルータ通知によって、外側（上流）ネットワーク向きのインタフェースであるイグレスインタフェース（egress interface）のプライマリグローバルアドレスを能動的にブロードキャストする必要がある。なお、以降、プライマリグローバルアドレスを含むルータ通知内の情報を「アクセスルータアドレス情報（Access-Router-Address-Information）」、又は、略して「ＡＲＡ−Ｉｎｆｏ」と呼ぶことにする。このように、アクセスルータのイングレスインタフェースに接続されたモバイルノードは、アクセスルータのプライマリグローバルアドレスを知るとともに、アクセスルータがＡＲＯによる解決方法をサポートしていることを把握する。

しかしながら、内側のモバイルノードと外側のモバイルルータとの間に、ローカルルータが介入している配置状態では、問題が生じる。これは、例えば図１に例示されているように、モバイルノード１０００−１が、ローカル固定ルータ１１００−１に接続されている状態である。ローカル固定ルータ１１００−１は、移動せずに、モバイルアクセスルータ１２００−１に接続されている。このような配置例は、一般的に、列車や船のような大きな輸送体に例えられる。ここでは、モバイルアクセスルータを利用して、列車／船に対するグローバルなインターネットへのアクセスが提供される一方、モバイルアクセスルータに接続されているローカル固定ルータが、列車／船の各車両／各船室に配置され、このローカル固定ルータによって、各車両／各船室における無線接続が提供される。モバイルホストとして動作するラップトップ（あるいは、無線ＰＡＮ内のＰＤＡ、無線ＰＡＮにおけるモバイルルータなど）は、これらのローカル固定ルータのうちの１つに接続可能である。

このような配置例では、モバイルノード１０００−１とモバイルアクセスルータ１２００−１との間にローカル固定ルータ１１００−１が存在する状況も起こり得る。ローカル固定ルータ１１００−１は、移動することなくモバイルアクセスルータ１２００−１に接続されているので、モビリティプロトコルを有する必要もなく、また、理解する必要もない。ローカル固定ルータ１１００−１は、モバイルノード１０００−１及びモバイルアクセスルータ１２００−１との間で、単にパケットの送受信を行うものである。したがって、ローカル固定ルータ１１００−１はモビリティに関連したプロトコルを使用せず、ローカル固定ルータ１１００−１から送信されるルータ通知には、それ自身のプライマリグローバルアドレスは、必然的に含まれないことになる。

このネットワーク配置の構成では、ローカル固定ルータ１１００−１によってブロードキャストされるルータ通知にはＡＲＡ−Ｉｎｆｏが全く含まれないので、ＡＲＯによる解決方法は、正常に機能しない。さらに、モバイルアクセスルータ１２００−１によって送信されるルータ通知には、ＡＲＡ−Ｉｎｆｏ内のプライマリグローバルアドレスが含まれるかもしれないが、ルータ通知は、１ホップの設定で送信されるものに過ぎず、ＩＰｖ６プロトコルを動作させるルータは、ルータ通知を転送することはできないため、モバイルノード１０００−１は、このモバイルアクセスルータ１２００−１によって送信されたルータ通知を受け取ることはできない。

上記の問題に関する非常に簡単な解決方法としては、モバイルネットワーク内のすべてのローカル固定ルータを、モバイルルータと同様にＡＲＯによる解決方法をサポートできるものとすることが挙げられる。しかしながら、この解決方法では、第１に、レガシルータ（従来のルータ）との互換性がなくなるという問題があり、第２に、接続点を変えないルータ上でＡＲＯによる解決方法 （モビリティプロトコル）を可能とする完全なプロトコル群をサポートさせると、システムが無駄に複雑さを増すことになるという問題がある。これは、結果的に、開発費及び維持費の増加をもたらすことになる。

本発明によれば、後述の４つの異なる方法（アプローチ）を有する実施の形態に記載されているように、ＡＲＯによる解決方法に係る改良が行われた動的ネットワーク管理システム及び動的ネットワーク管理装置並びに動的ネットワーク管理方法が提供される。第１の方法では、モバイルノード１０００−１が、送信するバインディングアップデートメッセージに、特別なマークを埋め込む。モバイルアクセスルータ１２００−１は、この信号（特別なマーク）をスキャンし、送信者（モバイルノード１０００−１）がモバイルアクセスルータ１２００−１を発見しようとしていることを把握して、送信者に対して、自身のプライマリグローバルアドレスを通知する。

第２の方法では、モバイルアクセスルータ１２００−１が、すべての入力パケットに関してスキャンを行い、モバイルノード１０００−１によって送信されたバインディングアップデートメッセージを探索する。モバイルノード１０００−１は、ＡＲＯによる解決方法を使用しているので、バインディングアップデートメッセージには、特別なビットが設定されている。モバイルアクセスルータ１２００−１は、送信者がＡＲＯによる解決方法をサポートしている一方、そのアクセスルータのプライマリグローバルアドレスを知らないことを把握して、送信者に対して、自身のプライマリグローバルアドレスを通知する。

第３の方法では、モバイルノード１０００−１が、その上流のすべてのルータに対して、特別なパケットを送信する。ＡＲＯによる解決方法をサポートしているルータは、このパケットを受け取った場合に、自身のプライマリグローバルアドレスを有する応答を行う。

第４の方法では、ローカル固定ルータ１１００−１が、送信するルータ通知メッセージ内に、ローカル固定ルータ１１００−１が接続されているモバイルアクセスルータ１２００−１のプライマリグローバルアドレスを含むＡＲＡ−Ｉｎｆｏを付加するように構成される。

本発明によれば、モバイルネットワークを形成するモバイルアクセスルータと、このモバイルネットワークに接続されているモバイルノードとの間に、ローカル固定ルータが配置されている構成においても、モバイルノード及びモバイルネットワークに対して、グローバルな接続性を提供することが可能となる。

本明細書では、レガシルータを含むモバイルネットワークにグローバルな接続性を提供するためのシステムと、それに関連した装置及び方法が開示される。以下、本発明の理解を容易にするため、用語の定義を行う。

（i）「パケット」は、データネットワーク上で伝送可能な、任意のフォーマットのデータの独立した（self-contained）ユニットである。通常、「パケット」は「ヘッダ」部分と「ペイロード」部分の２つの部分により構成される。「ペイロード」部分には、伝送されるデータが含まれており、「ヘッダ」部分には、パケットの伝送を支援するための情報が含まれている。なお、「ヘッダ」部分には、「パケット」の送信者及び受信者のそれぞれを識別するために、送信元アドレス及び送信先アドレスが含まれる必要がある。

（ii）「パケットトンネリング」は、別のパケットをカプセルに入れたパケットに関連するものである。「パケットトンネリング」の動作は、パケットの「カプセル化」とも呼ばれ、カプセル化されたパケットは、「トンネル化されたパケット」又は「インナパケット」と呼ばれ、「インナパケット」をカプセル化するパケットは「トンネリングパケット」又は「アウタパケット」とも呼ばれる。なお、カプセル化されたパケットでは、「インナパケット」全体が、「アウタパケット」のペイロード部分を形成する。

（iii）「モバイルノード」は、グローバルデータ通信ネットワークへの接続ポイントを変更するネットワークエレメントである。この「モバイルノード」は、エンドユーザ端末、ゲートウェイやルータなどの中継端末、グローバルデータ通信ネットワークへの接続ポイントを変更することが可能なインテリジェントネットワークハブを示す用語として使用する場合もある。また、「モバイルノード」がエンドユーザ端末の場合には、より明確に「モバイルホスト」と呼ばれ、「モバイルノード」が、ゲートウェイ、ルータ、インテリジェントネットワークハブなどとして機能する中間的なネットワークエレメントの場合には、より明確に「モバイルルータ」と呼ばれる。

（iv）ネットワークエレメントの「デフォルトルータ」とは、そのネットワークエレメントと同一のリンク上に存在するルータであり、この「デフォルトルータ」には、リンク上のネットワークエレメントから送信された、送信先までの転送ルートが不明であるすべてのパケットが転送される。

（v）モバイルノードの「アクセスルータ」とは、モバイルノードがデータ通信ネットワークに接続するために通信を行うルータであり、通常は、モバイルノードのデフォルトルータである。なお、モバイルノードのアクセスルータ自身が、移動可能であってもよく、このような移動可能なアクセスルータは、「モバイルアクセスルータ」として知られている。

（vi）「ホームアドレス」は、モバイルノードに割り当てられている基本的なグローバルアドレスであり、モバイルノードが接続しているグローバルデータ通信ネットワークの接続ポイントによらずに、モバイルノードの位置を特定するために利用可能である。なお、本明細書では、ホームアドレス（home-address）を簡略化して、ＨｏＡと呼ぶことがある。

（vii）グローバルデータ通信ネットワークに接続されたモバイルノードに関し、そのモバイルノードのホームアドレスが、接続ポイントの周辺領域で使用されているアドレスと一致するトポロジを有している場合、このモバイルノードは「ホームに存在する（at home）」と呼ばれる。また、この接続ポイントの近隣領域は、唯一の管理権限者によって制御されており、モバイルノードの「ホームドメイン」と呼ばれる。

（viii）グローバルデータ通信ネットワークに接続されたモバイルノードに関し、そのモバイルノードのホームアドレスが、接続ポイントの周辺領域で使用されているアドレスと一致しないトポロジを有している場合、このモバイルノードは「ホームから離れている（away）」と呼ばれる。また、この場合の接続ポイントの周辺領域は、「フォーリンドメイン」と呼ばれる。

（ix）「気付アドレス」は、ホームから離れた状態にあるモバイルノードに対して割り当てられる一時的なグローバルアドレスであり、割り当てられた「気付アドレス」は、モバイルノードがグローバルデータ通信ネットワークに接続する接続ポイントの周辺領域で使用されているアドレスと、同一のトポロジを有している。なお、本明細書では、気付アドレス（care-of-address）を簡略化して、ＣｏＡと呼ぶことがある。

（x）「ホームエージェント」は、モバイルノードのホームドメインに存在するネットワークエンティティである。「ホームエージェント」は、モバイルノードがホームから離れている場合の気付アドレスの登録サービスを行うものであり、モバイルノードのホームアドレスが送信先に設定されているパケットを、モバイルノードの気付アドレスに転送することが可能である。なお、ホームエージェントは、ルータでもある。

（xi）「バインディングアップデート」は、モバイルノードから、そのホームエージェントに対して送られるメッセージであり、ホームエージェントに対して、モバイルノードが現在使用している気付アドレスの通知を行うためのメッセージである。これによって、ホームエージェントは、モバイルノードのホームアドレスと気付アドレスとの間の関係を「バインディング」することが可能となる。なお、本明細書では、「バインディングアップデート（Binding Update）」を簡略化して、ＢＵと呼ぶことがある。

なお、以下の説明では、本発明を詳細に理解できるように、特定の数、時間、構造、その他のパラメータなどが詳しく説明されるが、こうした詳細な設定は一例であり、当業者は、こうした特定の詳細な設定を行わなくても、本発明を実行できることは明白である。

＜第１の実施の形態＞
本発明の第１の実施の形態では、モバイルノードがバインディングアップデートメッセージを送出する場合に、パケットヘッダに特別なマークを埋め込む場合について説明する。ここでは、上流のモバイルアクセスルータは、この特別なマークを検出した場合に、モバイルノードに対して、そのＨｏＡを通知する。

図１には、本発明の適用が可能なモバイルノードのシステム及びグローバル通信ネットワークが図示されている。モバイルノード１０００−１は、ローカル固定ルータ１１００−１に接続されており、ローカル固定ルータ１１００−１は、モバイルアクセスルータ１２００−１に接続されている。なお、ここでは、単純化のため、モバイルアクセスルータ１２００−１にはローカル固定ルータ１１００−１が１台のみ接続されており、ローカル固定ルータ１１００−１には、モバイルノード１０００−１が１台のみ接続されている場合が示されているが、実際には、モバイルアクセスルータ１２００−１には、任意の台数のローカル固定ルータ１１００−１が接続可能であり、これらのローカル固定ルータ１１００−１のそれぞれには、任意の台数のモバイルノード１０００−１が接続可能である。なお、当業者とっては、このような任意の台数のローカル固定ルータ１１００−１及びモバイルノード１０００−１が接続されている場合にも、本発明が適用されることは明らかである。

さらに、モバイルノード１０００−１がモバイルホスト又はモバイルルータのどちらであるかに関しては、特に限定されるものではなく、モバイルノード１０００−１は、実際には、モバイルアクセスルータ１２００−１そのものであってもよい。なお、ここではモバイルノードという用語を使用するが、これによって、上述のような一般性が失われることはなく、モバイルノードという用語は、モバイルホストやモバイルルータなどを包含したものを表している。なお、当業者にとっては、モバイルノード１０００−１がモバイルホストである場合と、モバイルノード１０００−１がモバイル（アクセス）ルータである場合の両方において、本発明の適用が可能であることは明らかである。

さらに、１台のローカル固定ルータ１１００−１が、モバイルノード１０００−１とモバイルアクセスルータ１２００−１との間の経路上に図示されているが、実際には、モバイルノード１０００−１とモバイルアクセスルータ１２００−１との間に、こうしたローカル固定ルータ１１００−１が複数並んで接続されていてもよい。なお、当業者にとっては、モバイルノード１０００−１とモバイルアクセスルータ１２００−１との間に１台以上のローカル固定ルータ１１００−１が存在する場合でも、同様にして、本発明が適用されることは明らかである。

また、モバイルアクセスルータ１２００−１は、グローバルデータ通信ネットワーク１６００−１に接続されている。このネットワーク１６００−１は、任意のパケット交換ネットワーク網であり、また、インターネットそのものであってもよい。また、グローバルデータ通信ネットワーク１６００−１には、ホームエージェント１４００−１、１４００−２が接続されており、それぞれ、モバイルノード１０００−１とモバイルアクセスルータ１２００−１のホームエージェントとしての機能を有している。なお、モバイルアクセスルータ１２００−１に常に接続されているローカル固定ルータ１１００−１は、モビリティプロトコルを持たず、したがって、ホームエージェントを必要とはしない。また、通信相手ノード（コレスポンデントノード）１５００−１は、モバイルノード１０００−１（あるいは、モバイルノード１０００−１がモバイルアクセスルータである場合には、モバイルノード１０００−１の配下に存在する任意のモバイルノード）との間のトラフィックセッションを継続しているグローバルデータ通信ネットワーク１６００−１上の任意のノードである。

モバイルノード１０００−１は、最初の起動時に、ローカル固定ルータ１１００−１からルータ通知メッセージを受け取り、ルータ通知によって報じられるプリフィックス情報に基づいて、自らＣｏＡを構成する。続いて、モバイルノード１０００−１は、そのＨｏＡとの関連付けがなされるように、ホームエージェント１４００−１及び通信相手ノード１５００−１に対して、ＢＵメッセージを送信して、新たなＣｏＡを通知する必要がある。ローカル固定ルータ１１００−１によって送られたルータ通知には、ＡＲＡ−Ｉｎｆｏが含まれていないので、モバイルノード１０００−１は、送信するＢＵメッセージ内にアクセスルータオプションを含ませることはできない。そこで、代わりに、モバイルノード１０００−１は、ＢＵメッセージのパケットヘッダに、上流に並ぶモバイルアクセスルータが各ＨｏＡの応答を行うように指示するための特別なマークを埋め込む。なお、説明を簡単にするため、以降、このようなマークを「アクセスルータアドレス要求（Access-Router-Address-Request）」信号、又は、その略語である「ＡＲＡ−Ｒｅｑ」と呼ぶことにする。ＡＲＡ-Ｒｅｑは、特定のビットやビットのストリームによって表すことが可能である。例えば、ＩＰｖ６では、ルータ警告オプションとして知られているホップバイホップオプションが存在しており（非特許文献１１を参照）、上述した特別なマークは、ルータ警告オプションにおける特定の値によって表わされてもよい。

ローカル固定ルータ１１００−１はパケットを受け、そのパケットの妥当性について検証した後、モバイルアクセスルータ１２００−１に向けて、パケットを上流へ転送する。モバイルアクセスルータ１２００−１は、そのイングレスインタフェースにおける入力パケットをチェックして、何らかの信号（例えば、ＡＲＡ−Ｒｅｑ）が埋め込まれていないかの確認を行う。ＡＲＡ−Ｒｅｑが検出された場合には、モバイルアクセスルータ１２００−１は、入力パケットに関する通常の処理に加えて、特別な動作を行う必要がある。まず始めに、モバイルアクセスルータ１２００−１は、モバイルノード１０００−１（ＡＲＡ−Ｒｅｑ信号を有する入力パケットのソースアドレスフィールドによって特定可能）に対して、自身のＨｏＡを通知するための新たなパケットを生成しなければならない。なお、以降、このパケットを「アクセスルータアドレス応答（Access-Router-Address-Response）」信号、又は、その略語である「ＡＲＡ−Ｒｅｓ」と呼ぶことにする。続いて、モバイルアクセスルータ１２００−１は、ＡＲＡ−Ｒｅｑ信号を有する入力パケットを削除するか、あるいは、再びマーク付けを行って、上流に並ぶルータが、ＡＲＡ−Ｒｅｑへの応答を行わないようにすることで、最初に、パケット内のＡＲＡ−Ｒｅｑ信号を検出したモバイルアクセスルータ１２００−１のみから、モバイルノード１０００−１に対して、ＡＲＡ−Ｒｅｓが送信されるようにすることも可能である。また、モバイルアクセスルータ１２００−１が、ＡＲＡ−Ｒｅｑ信号を有する入力パケットをそのまま上流に転送することで、さらに上流にモバイルアクセスルータ１２００−１が存在する場合には、その上流に存在するモバイルアクセスルータ１２００−１からも、モバイルノード１０００−１に対して、ＡＲＡ−Ｒｅｓが送信されるようにすることも可能である。

モバイルアクセスルータ１２００−１がモバイルノード１０００−１に対して送信するＡＲＡ−Ｒｅｓパケットには、以下の情報が含まれる必要がある。（１）このパケットがＡＲＡ−Ｒｅｑに対する応答であることを示す情報、（２）モバイルアクセスルータ１２００−１のＨｏＡを特定する値。また、オプションとして、モバイルノード１０００−１が、有効な応答であることを検証することができるように、ＡＲＡ−Ｒｅｓパケットに、オリジナルのパケット（ＡＲＡ−Ｒｅｑを有するパケット）の一部が含まれるようにすることも可能である。

また、ＡＲＡ−Ｒｅｑがどのようにして実現されているかによって、ＡＲＡ−Ｒｅｑを削除するための的確な方法も異なってくる。ＡＲＡ−Ｒｅｑがパケットヘッダ内のビットである場合には、モバイルアクセスルータ１２００−１は、単にそのビットを取り除くことによって、ＡＲＡ−Ｒｅｑを削除することが可能である。また、ＡＲＡ−Ｒｅｑがルータ警告オプション内の値として実現されている場合には、単にルータ警告オプションが除去されるか、あるいは、別の値に置き換えられることによって、上流に並ぶルータによって、ルータ警告オプションが無視されるようにすることが可能である。

モバイルアクセスルータ１２００−１のＨｏＡを含むＡＲＡ−Ｒｅｓパケットを受けた場合には、モバイルノード１０００−１は、ホームエージェント１４００−１及び／又は通信相手ノード１５００−１に対して、モバイルアクセスルータ１２００−１のＨｏＡを含むアクセスルータオプションを有する新たなＢＵメッセージの送信処理を行うようにすることが可能である。この段階では、モバイルノード１０００−１は、ＡＲＡ−Ｒｅｑを挿入する必要はなく、ＡＲＯによる解決方法で規定されている振る舞いを行うべきである。

すなわち、モバイルノード１０００−１は、ＢＵメッセージを送信する場合に、図２に示されるアルゴリズムに従うこととなる。ステップＳ１１０００において、モバイルノード１０００−１は、自身のアクセスルータのＨｏＡを知っているかどうかをチェックする。アクセスルータのＨｏＡを知っている（ルータ通知メッセージから抽出されたＡＲＡ−Ｉｎｆｏ、又は、以前に受信したＡＲＡ−Ｒｅｓメッセージによって知っている）場合には、ステップＳ１１１００に示されているように、モバイルノード１０００−１は、アクセスルータのＨｏＡに等しい値を有するアクセスルータオプションを、ＢＵ内に挿入する。一方、アクセスルータのＨｏＡを知らない場合には、ステップＳ１１２００に示されているように、モバイルノード１０００−１は、ＡＲＡ−Ｒｅｑ信号をＢＵメッセージのパケットヘッダに挿入する。

また、モバイルアクセスルータ１２００−１に関しては、本発明では、そのイングレスインタフェースのうちの１つから入ってくる入力パケットに係る処理方法について、わずかな変更が必要とされる。図３には、この変更が図示されている。まず、ステップＳ１２０００において、モバイルアクセスルータ１２００−１は、パケットにＡＲＡ−Ｒｅｑ信号が存在しているかどうかをチェックする。ＡＲＡ−Ｒｅｑ信号が発見されない場合には、ステップＳ１２３００に進み、モバイルアクセスルータ１２００−１は、通常の入力パケットの処理を行う。一方、パケットにＡＲＡ−Ｒｅｑ信号が含まれている場合には、ステップＳ１２１００及びＳ１２２００の処理を行った後に、ステップＳ１２３００に進む。すなわち、ステップＳ１２１００において、モバイルアクセスルータ１２００−１は、入力パケットに記載されているソースアドレスに対して、そのＨｏＡを含むＡＲＡ−Ｒｅｓパケットを送信し、ステップＳ１２２００において、入力パケットからＡＲＡ−Ｒｅｑ信号を削除した後に、ステップＳ１２３００における通常の入力パケットの処理を行う。

なお、モバイルアクセスルータ１２００−１のＨｏＡを格納する場合、モバイルノード１０００−１は、現在のデフォルトルータ（すなわち、ローカル固定ルータ１１００−１）に関する情報と共に、モバイルアクセスルータ１２００−１のＨｏＡの格納を行う必要がある。これにより、モバイルノード１０００−１が新たな位置に移動した場合には、そのデフォルトルータの変更に伴って、格納されているモバイルアクセスルータ１２００−１のＨｏＡも除去されるようになる。

以上のように、本発明の第１の実施の形態によれば、モバイルノードは、モバイルノードとモバイルアクセスルータとの間に他のルータが存在する場合でも、上流のモバイルアクセスルータのＨｏＡを知ることができるようになる。これによって、モバイルノードは、バインディングアップデートメッセージにアクセスルータオプションを埋め込むことが可能となり、その結果、ＡＲＯによる解決方法を、標準として機能させることが可能となる。

＜第２の実施の形態＞
本発明の第２の実施の形態では、モバイルアクセスルータ１２００−１が、モバイルノード１０００−１によって送信されるバインディングアップデートメッセージを探索するために、イングレスインタフェースを通じて入ってくるすべての入力パケットをスキャンする場合について説明する。ここでは、モバイルノード１０００−１がＡＲＯによる解決方法を使用しており、バインディングアップデートメッセージ内に特別なビットが設定される。モバイルアクセスルータ１２００−１は、送信者がＡＲＯによる解決方法をサポートしているが、そのアクセスルータのＨｏＡに関しては把握していないことを知ることとなり、モバイルアクセスルータ１２００−１から送信者に対して、そのＨｏＡが通知される。

第２の実施の形態においても、図１に図示される本発明の配置例が参照される。モバイルノード１０００−１は、最初の起動時に、ローカル固定ルータ１１００−１からルータ通知メッセージを受け取り、ルータ通知によって報じられるプリフィックス情報に基づいて、自らＣｏＡを構成する。続いて、モバイルノード１０００−１は、そのＨｏＡとの関連付けがなされるように、ホームエージェント１４００−１及び通信相手ノード１５００−１に対して、ＢＵメッセージを送信して、新たなＣｏＡを通知する必要がある。ローカル固定ルータ１１００−１によって送られたルータ通知には、ＡＲＡ−Ｉｎｆｏが含まれていないので、モバイルノード１０００−１は、送信するＢＵメッセージ内にアクセスルータオプションを含ませることはできない。

一方、モバイルノード１０００−１は、オプションとして、アクセスルータオプション内に、あらかじめ規定された値（例えば、すべて０又はすべて１のアドレス）を使用することによって、ＡＲＯによる解決方法を使用することは可能ではあるが、そのアクセスルータのＨｏＡを（まだ）知らないことを表すことが可能である。なお、ＡＲＯによる解決方法では、モバイルノード１０００−１が、ＢＵメッセージに特別なビットを設定して、ＡＲＯによる解決方法を使用することを示すように要請される可能性もあり、上述したビット設定は、必ずしも必要とされない場合もある。また、上述のビットを設定する一方、アクセスルータオプションを欠如させることにより、モバイルノード１０００−１がアクセスルータのＨｏＡを知らないことを十分に表すことができる。

ローカル固定ルータ１１００−１はパケットを受け、そのパケットの妥当性について検証した後、モバイルアクセスルータ１２００−１に向けて、パケットを上流へ転送する。モバイルアクセスルータ１２００−１は、そのイングレスインタフェースにおける入力パケットをチェックして、ＢＵメッセージに係るパケットかどうかの確認を行う。ＢＵメッセージが検出された場合には、モバイルアクセスルータ１２００−１は、入力パケットに関する通常の処理に加えて、さらに、送信者がＡＲＯによる解決方法を使用していることがＢＵによって示されているかどうかを確認する必要がある。

モバイルアクセスルータ１２００−１がモバイルノード１０００−１に対して送信するＡＲＡ−Ｒｅｓパケットには、以下の情報が含まれる必要がある。（１）このパケットがモバイルアクセスルータ１２００−１のＨｏＡを通知するメッセージであることを示す情報、（２）モバイルアクセスルータ１２００−１のＨｏＡを特定する値。また、オプションとして、モバイルノード１０００−１が、有効な応答であることを検証することができるように、ＡＲＡ−Ｒｅｓパケットに、オリジナルのパケット（ＢＵメッセージを有するパケット）の一部が含まれるようにすることも可能である。

モバイルアクセスルータ１２００−１のＨｏＡを含むＡＲＡ−Ｒｅｓパケットを受けた場合には、モバイルノード１０００−１は、ホームエージェント１４００−１及び／又は通信相手ノード１５００−１に対して、モバイルアクセスルータ１２００−１のＨｏＡを含むアクセスルータオプションを有する新たなＢＵメッセージの送信処理を行うようにすることが可能である。この段階では、モバイルノード１０００−１は、ＡＲＯによる解決方法によって規定されている振る舞いを行うべきである。

すなわち、モバイルノード１０００−１は、ＢＵメッセージを送信する場合に、図４に示されるアルゴリズムに従うこととなる。ステップＳ２１０００において、モバイルノード１０００−１は、自身のアクセスルータのＨｏＡを知っているかどうかをチェックする。アクセスルータのＨｏＡを知っている（ルータ通知メッセージから抽出されたＡＲＡ−Ｉｎｆｏ、又は、以前に受信したＡＲＡ−Ｒｅｓメッセージによって知っている）場合には、ステップＳ２１１００に示されているように、モバイルノード１０００−１は、アクセスルータのＨｏＡに等しい値を有するアクセスルータオプションを、ＢＵ内に挿入する。一方、アクセスルータのＨｏＡを知らない場合には、モバイルノード１０００−１は、ステップＳ２１２００に示されているように、モバイルノード１０００−１がＡＲＯによる解決方法を使用しているものの、アクセスルータのＨｏＡは知らないということが、ＢＵメッセージを検証するすべてのノードに分かるように、ＢＵメッセージの送信を行う。すなわち、ステップＳ２１２００において、モバイルノード１０００−１は、アクセスルータオプションを有さず、かつ、ＡＲＯによる解決方法の使用を示す情報を有するＢＵの送信を行う。

また、モバイルアクセスルータ１２００−１に関しては、本発明では、そのイングレスインタフェースのうちの１つから入ってくる入力パケットに係る処理方法について、わずかな変更が必要とされる。図５には、この変更が図示されている。まず、ステップＳ２２０００において、モバイルアクセスルータ１２００−１は、入力パケットがＢＵメッセージであるかどうかをチェックする。ＢＵメッセージではない場合には、ステップＳ２２３００に示すように、通常の入力パケットの処理が行われる。一方、入力パケットがＢＵメッセージの場合には、ステップＳ２２１００において、モバイルアクセスルータ１２００−１は、さらに、ＢＵメッセージの送信者が、ＡＲＯによる解決方法を使用しようとしている一方、アクセスルータのＨｏＡを知らないことがＢＵメッセージによって示されているかどうかを確認する。なお、ＡＲＯによる解決方法の使用を示すビットが設定され、かつ、アクセスルータオプションが存在しない場合や、アクセスルータオプションが特別に記載されたアドレス（例えば、すべて０のアドレス、又は、すべて１のアドレス）を含んでいる場合などに、ＢＵメッセージの送信者が、ＡＲＯによる解決方法を使用しようとしている一方、アクセスルータのＨｏＡを知らないと推定することが可能となる。

ＢＵメッセージの送信者が、ＡＲＯによる解決方法を使用しようとしている一方、アクセスルータのＨｏＡを知らないことが確認されなかった場合には、ステップＳ２２３００に進み、モバイルアクセスルータ１２００−１は、ＡＲＯによる解決方法で規定されている通常の入力パケットの処理を行う。一方、ＢＵメッセージの送信者が、ＡＲＯによる解決方法を使用しようとしている一方、アクセスルータのＨｏＡを知らないことが確認された場合には、ステップＳ２２２００に進み、モバイルアクセスルータ１２００−１は、入力パケットに記載されているソースアドレスに対して、そのＨｏＡを含むＡＲＡ−Ｒｅｓパケットを送信し、ステップＳ２２３００において、通常の入力パケットの処理を行う。

なお、上述の第１の実施の形態と同様に、モバイルアクセスルータ１２００−１のＨｏＡを格納する場合、モバイルノード１０００−１は、現在のデフォルトルータ（すなわち、ローカル固定ルータ１１００−１）に関する情報と共に、モバイルアクセスルータ１２００−１のＨｏＡの格納を行う必要がある。これにより、モバイルノード１０００−１が新たな位置に移動した場合には、そのデフォルトルータの変更に伴って、格納されているモバイルアクセスルータ１２００−１のＨｏＡも除去されるようになる。

以上のように、本発明の第２の実施の形態によれば、モバイルノードは、モバイルノードとモバイルアクセスルータとの間に他のルータが存在する場合でも、上流のモバイルアクセスルータのＨｏＡを知ることができるようになる。これによって、モバイルノードは、バインディングアップデートメッセージにアクセスルータオプションを埋め込むことが可能となり、その結果、ＡＲＯによる解決方法を、標準として機能させることが可能となる。

＜第３の実施の形態＞
本発明の第３の実施の形態では、モバイルノードが、その上流のすべてのルータに対して、特別なパケットを送信する場合について説明する。ここでは、ＡＲＯによる解決方法をサポートするルータが、それぞれのホームアドレスを応答する。

第３の実施の形態においても、図１に図示される本発明の配置例が参照される。モバイルノード１０００−１は、最初の起動時に、ローカル固定ルータ１１００−１からルータ通知メッセージを受け取り、ルータ通知によって報じられるプリフィックス情報に基づいて、自らＣｏＡを構成する。続いて、モバイルノード１０００−１は、そのＨｏＡとの関連付けがなされるように、ホームエージェント１４００−１及び通信相手ノード１５００−１に対して、ＢＵメッセージを送信して、新たなＣｏＡを通知する必要がある。ローカル固定ルータ１１００−１によって送られたルータ通知には、ＡＲＡ−Ｉｎｆｏが含まれていないので、モバイルノード１０００−１は、送信するＢＵメッセージ内にアクセスルータオプションを含ませることはできない。

このような状況が生じた場合には、モバイルノード１０００−１は、ＢＵメッセージの発信を遅らせ、その代わりに、すべての上流のルータに対して、各ルータのＨｏＡの取得を要求するための特別なパケットを送信する。この特別なパケットは、アクセスルータのアドレス要求であることを示す特定のタイプを有するＩＣＭＰ（インターネット制御メッセージプロトコル：Internet Control Message Protocol ）の形式を取ることも可能であり、あるいは、受信者がルータ通知の応答にホームアドレスを含ませるように指示する特別なオプションを有する通常のルータ要請メッセージ（非特許文献１０を参照）としてもよい。なお、説明を簡単にするため、以降、このパケットを「アクセスルータアドレス調査メッセージ（Access Router Address Probe message）」、又は、略して「ＡＲＡ−Ｐｒｏｂｅ」と呼ぶことにする。

モバイルノード１０００−１は、上流のモバイルアクセスルータ１２００−１の存在を知らないので、ＡＲＡ−Ｐｒｏｂｅの送信先フィールド内に、ブロードキャストアドレス又はマルチキャストアドレスを使用する必要がある。ＩＰｖ６では、すべてのルータに関連付けられたオールルータマルチキャストアドレス（all-router multicast address）が定義されており、モバイルノード１０００−１は、このオールルータマルチキャストアドレスを送信先アドレスとして使用することが可能である。また、あるいは、上流ルータのみに関連付けられた特別なマルチキャストアドレスが定義されてもよい。なお、以降、このマルチキャストアドレスを「上流ルータマルチキャストアドレス（upstream-router multicast address）」と呼ぶことにする。すなわち、これは、すべてのルータが、それらのイグレスインタフェースから受信する上流ルータマルチキャストアドレスに関連するパケットを暗黙のうちに無視する一方、イングレスインタフェースからイグレスインタフェース方向に受信する上流ルータマルチキャストアドレスに関連するパケットの転送を行うことを意味している。

マルチキャストアドレスによるパケットの分散量を制限するために、ＩＰｖ６には、パケットを転送することができる回数を制限するホップリミットフィールドが設けられている。モバイルノード１０００−１は、パケットの分散を抑制するために、小さなホップリミット値（例えば、２又は３）を使用することが可能である。

また、ローカル固定ルータ１１００−１も、ＡＲＡ−Ｐｒｏｂｅを受信することになるが、このパケットを理解することはほとんど不可能であり、上流（すなわち、モバイルアクセスルータ１２００−１）に向けて、このパケットの転送を行うことになる。そして、モバイルアクセスルータ１２００−１が、このパケットを受信した場合には、本発明の第１の実施の形態で説明したように、このＡＲＡ−Ｐｒｏｂｅ の送信者（すなわち、モバイルノード１０００−１）に向けて、ＡＲＡ−Ｒｅｓを送信することとなる。

モバイルアクセスルータ１２００−１がモバイルノード１０００−１に対して送信するＡＲＡ−Ｒｅｓパケットには、以下の情報が含まれる必要がある。（１）このパケットがＡＲＡ−Ｐｒｏｂｅに対する応答であることを示す情報、（２）モバイルアクセスルータ１２００−１のＨｏＡを特定する値。また、オプションとして、モバイルノード１０００−１が、有効な応答であることを検証することができるように、ＡＲＡ−Ｒｅｓパケットに、オリジナルのＡＲＡ−Ｐｒｏｂｅメッセージの一部が含まれるようにすることも可能である。なお、モバイルアクセスルータ１２００−１は、ＡＲＡ−Ｒｅｓによって応答を行うので、ＡＲＡ−Ｐｒｏｂｅをさらに上流に転送する必要がない場合には、ＡＲＡ−Ｐｒｏｂｅを含むパケットを破棄する処理を行うか、あるいは、ＡＲＡ−Ｐｒｏｂｅメッセージを削除又は無効化して、通常のパケットと同様の処理を行うことも可能である。

モバイルノード１０００−１は、このＡＲＡ−Ｒｅｓを受信した後に、アクセスルータオプションが挿入されたＢＵメッセージを送信することが可能となる。その後のモバイルノード１０００−１及びモバイルアクセスルータ１２００−１の動作は、オリジナルのＡＲＯソリューションで規定されているものが行われることになる。なお、ブロードキャスト方法を使用した場合、モバイルノード１０００−１が１つ以上のＡＲＡ−Ｒｅｓを受信する可能性がある。この場合には、最も早く戻ってくる応答を行った者が最も近くに存在していることが示唆されるので、モバイルノード１０００−１は、最初に受信したＡＲＡ−Ｒｅｓを使用することが望ましい。

すなわち、モバイルノード１０００−１は、ＢＵメッセージを送信する場合に、図６に示されるアルゴリズムに従うこととなる。ステップＳ３１０００において、モバイルノード１０００−１は、自身のアクセスルータのＨｏＡを知っているかどうかをチェックする。アクセスルータのＨｏＡを知っている（ルータ通知メッセージから抽出されたＡＲＡ−Ｉｎｆｏ、又は、以前に受信したＡＲＡ−Ｒｅｓメッセージによって知っている）場合には、ステップＳ３１１００に示されているように、モバイルノード１０００−１は、アクセスルータのＨｏＡに等しい値を有するアクセスルータオプションを、ＢＵ内に設定する。一方、アクセスルータのＨｏＡを知らない場合には、ステップＳ３１２００に進み、ＡＲＡ−Ｐｒｏｂｅを送信する。そして、ステップＳ３１３００に示されているように、モバイルノード１０００−１は、有効なＡＲＡ−Ｒｅｓの受信、又は、タイムアウトの待機状態となる。有効なＡＲＡ−Ｒｅｓを受信した場合には、モバイルノード１０００−１は、ステップＳ３１１００に進み、アクセスルータオプションが挿入されたＢＵを送信する。なお、アクセスルータのＨｏＡの値には、ＡＲＡ−Ｒｅｓから抽出されたＨｏＡの値に等しい値が利用される。一方、タイムアウトになった場合には、モバイルノード１０００−１の上流には、モバイルアクセスルータ１２００−１は存在しないとみなされて、ステップＳ３１４００に示されているように、アクセスルータオプションを有さないＢＵの送信処理が行われる。

また、モバイルアクセスルータ１２００−１に関しては、本発明では、そのイングレスインタフェースのうちの１つから入ってくる入力パケットに係る処理方法について、わずかな変更が必要とされる。図７には、この変更が図示されている。まず、ステップＳ３２０００において、モバイルアクセスルータ１２００−１は、入力パケットがＡＲＡ−Ｐｒｏｂｅかどうかをチェックする。ＡＲＡ−Ｐｒｏｂｅではない場合には、ステップＳ３２１００に進み、モバイルアクセスルータ１２００−１は、通常の入力パケットの処理を行う。一方、パケットがＡＲＡ−Ｐｒｏｂｅの場合には、ステップＳ３２２００に進み、モバイルアクセスルータ１２００−１は、入力パケットに記載されているソースアドレスに対して、そのＨｏＡを含むＡＲＡ−Ｒｅｓパケットを送信する。

なお、上述の第１の実施の形態と同様に、モバイルアクセスルータ１２００−１のＨｏＡを格納する場合、モバイルノード１０００−１は、現在のデフォルトルータ（すなわち、ローカル固定ルータ１１００−１）に関する情報と共に、モバイルアクセスルータ１２００−１のＨｏＡの格納を行う必要がある。これにより、モバイルノード１０００−１が新たな位置に移動した場合には、そのデフォルトルータの変更に伴って、格納されているモバイルアクセスルータ１２００−１のＨｏＡも除去されるようになる。

以上のように、本発明の第３の実施の形態によれば、モバイルノードは、モバイルノードとモバイルアクセスルータとの間に他のルータが存在する場合でも、上流のモバイルアクセスルータのＨｏＡを知ることができるようになる。これによって、モバイルノードは、バインディングアップデートメッセージにアクセスルータオプションを埋め込むことが可能となり、その結果、ＡＲＯによる解決方法を、標準として機能させることが可能となる。

＜第４の実施の形態＞
本発明の第４の実施の形態では、ローカル固定ルータ自身が送信するルータ通知メッセージ内に、ローカル固定ルータが接続されているモバイルアクセスルータのプライマリグローバルアドレスを加えることができるように、ローカル固定ルータを構成する場合について説明する。

第４の実施の形態においても、図１に図示される本発明の配置例が参照される。ここでは、ローカル固定ルータ１１００−１が、そのイグレスインタフェースから、デフォルトルータ（すなわち、モバイルアクセスルータ１２００−１）によって送信されたルータ通知を聞くことができるように構成されている。

ルータ通知内にＡＲＡ−Ｉｎｆｏが含まれていることを検出した場合には、ローカル固定ルータ１１００−１は、ＡＲＡ−Ｉｎｆｏから抽出されるアドレスを格納する。続いて、ローカル固定ルータ１１００−１は、そのデフォルトルータのＨｏＡを含むＡＲＡ−Ｉｎｆｏを、ルータ通知に挿入して、そのイングレスインタフェースへのルータ通知の送信を行う。これにより、モバイルノード１０００−１にとっては、ローカル固定ルータ１１００−１が、あたかもＡＲＯによる解決方法をサポートしているモバイルアクセスルータであるかのように見える。しかしながら、実際には、ローカル固定ルータ１１００−１は、ＡＲＯによる解決方法の主要部分を理解する必要はなく、単に、モバイルアクセスルータ１２００−１から受信したルータ通知からモバイルアクセスルータ１２００−１のＨｏＡを抽出する方法や、ローカル固定ルータ１１００−１自身が送信するルータ通知に、モバイルアクセスルータ１２００−１のＨｏＡを挿入する方法を知っておくだけでよい。

モバイルアクセスルータ１２００−１のＨｏＡを格納する場合、ローカル固定ルータ１１００−１は、現在のデフォルトルータ（すなわち、モバイルアクセスルータ１２００−１）に関する情報と共に、モバイルアクセスルータ１２００−１のＨｏＡの格納を行う必要がある。これにより、モバイルノード１０００−１が新たな位置に移動した場合には、そのデフォルトルータの変更に伴って、格納されているモバイルアクセスルータ１２００−１のＨｏＡも除去されるようになる。

したがって、本発明の第４の実施の形態では、オリジナルのＡＲＯによる解決方法を行うために、ローカル固定ルータ１１００−１だけが修正される。また、モバイルノード１０００−１及びモバイルアクセスルータ１２００−１は、両方ともオリジナルのＡＲＯソリューションで規定される処理に従う。図８には、ローカル固定ルータ１１００−１のイグレスインタフェースから入ってくる入力パケットの通常の処理への変更が図示されている。ステップＳ４１０００において、ローカル固定ルータ１１００−１は、まず、イグレスインタフェースから入ってくる入力パケットがルータ通知であるかどうかをチェックする。入力パケットがルータ通知ではない場合には、ステップＳ４１１００が行われ、パケットに係る通常の処理（一般のＩＰルータで可能な処理）が実行される。一方、入力パケットがルータ通知の場合には、ステップＳ４１２００に示されるように、ルータ通知に係る通常の処理が実行される。なお、この処理によって、ローカル固定ルータ１１００−１は、デフォルトルータの構成を変更する可能性もある。

この処理（ステップＳ４１２００の処理）の後に、ステップＳ４１３００に示されるように、ルータ通知のチェックが行われ、ルータ通知がローカル固定ルータ１１００−１のデフォルトルータから来たものであるかどうかが確認される。デフォルトルータからのルータ通知ではない場合には、特に、処理が行われる必要はないが、一方、デフォルトルータからのルータ通知である場合には、次に、ステップＳ４１４００において、ルータ通知のチェックが行われ、ルータ通知がＡＲＡ−Ｉｎｆｏを含んでいるかどうかがチェックされる。そして、ＡＲＡ−Ｉｎｆｏが含まれていない場合には、ステップＳ４１５００に示されるように、デフォルトルータのＨｏＡを格納する内部変数がクリアされ、また、ルータ通知がＡＲＡ−Ｉｎｆｏ（デフォルトルータのＨｏＡ）を含んでいる場合には、ステップＳ４１６００において、このアドレスが前述の内部変数に格納される（デフォルトルータのＨｏＡを格納）。

また、次に説明するローカル固定ルータ１１００−１の動作の変更は、イングレスインタフェースにルータ通知を送出する場合のものである。図９には、この変更が図示されている。ステップＳ４２０００において、まず、ローカル固定ルータ１１００−１は、以前に格納されたそのデフォルトルータ（すなわち、モバイルアクセスルータ１２００−１）のＨｏＡを保持している（知っている）かどうかのチェックを行う。ＨｏＡを保持していない場合には、ステップＳ４２１００が行われ、ローカル固定ルータ１１００−１は、ＡＲＡ−Ｉｎｆｏを有さないルータ通知を送信する。一方、以前に格納されたそのデフォルトルータのＨｏＡを保持している場合には、ローカル固定ルータ１１００−１は、ステップＳ４２２００に示されるように、デフォルトルータのＨｏＡを含むＡＲＡ−Ｉｎｆｏをルータ通知内に挿入する。

以上のように、本発明の第４の実施の形態によれば、モバイルノードは、モバイルノードとモバイルアクセスルータとの間に完全にはＡＲＯによる解決方法をサポートしていないルータが存在する場合でも、上流のモバイルアクセスルータのＨｏＡを知ることができるようになる。これによって、モバイルノードは、バインディングアップデートメッセージにアクセスルータオプションを埋め込むことが可能となり、その結果、ＡＲＯによる解決方法を、標準として機能させることが可能となる。

本発明は、モバイルネットワークを形成するモバイルアクセスルータと、このモバイルネットワークに接続されているモバイルノードとの間に、ローカル固定ルータが配置されている構成においても、モバイルノード及びモバイルネットワークに対して、グローバルな接続性を提供することが可能であり、モバイルネットワークに対して、グローバルな接続性を提供するための通信ネットワークに係る技術に適用され、特に、ＩＰを利用した通信に係る技術に適用される。

本発明の第１〜第４の実施の形態に共通して適用可能なシステム構成例を示す図 本発明の第１の実施の形態における、モバイルノードがバインディングアップデートメッセージを送信する際のアルゴリズムを示すフローチャート 本発明の第１の実施の形態における、モバイルアクセスルータがイングレスインタフェースから受信した入力パケットの処理方法を示すフローチャート 本発明の第２の実施の形態における、モバイルノードがバインディングアップデートメッセージを送信する際のアルゴリズムを示すフローチャート 本発明の第２の実施の形態における、モバイルアクセスルータがイングレスインタフェースから受信した入力パケットの処理方法を示すフローチャート 本発明の第３の実施の形態における、モバイルノードがバインディングアップデートメッセージを送信する際のアルゴリズムを示すフローチャート 本発明の第３の実施の形態における、モバイルアクセスルータがイングレスインタフェースから受信した入力パケットの処理方法を示すフローチャート 本発明の第４の実施の形態における、ローカル固定ルータがイグレスインタフェースから受信した入力パケットの処理方法を示すフローチャート 本発明の第４の実施の形態における、ローカル固定ルータがイングレスインタフェースからルータ通知を送信する方法を示すフローチャート

Claims (22)

1. モバイルネットワークを形成するモバイルアクセスルータと、前記モバイルネットワークに属するローカル固定ルータと、前記ローカル固定ルータに接続することによって、前記モバイルネットワークに参加するモバイルノードとを有する通信システムにおける動的ネットワーク管理システムであって、
   前記モバイルノードから、前記モバイルアクセスルータに関する情報を要求する情報が送信されることによって、前記ローカル固定ルータを介して前記モバイルノードから前記情報を受信した前記モバイルアクセスルータから、前記モバイルノードに対して、前記モバイルアクセスルータに関する情報が通知されるように構成されている動的ネットワーク管理システム。
2. 前記モバイルアクセスルータに関する情報が、前記モバイルアクセスルータのグローバルアドレスである請求項１に記載の動的ネットワーク管理システム。
3. モバイルネットワークを形成するモバイルアクセスルータと、前記モバイルネットワークに属するローカル固定ルータと、前記ローカル固定ルータに接続することによって、前記モバイルネットワークに参加するモバイルノードとを有する通信システムにおける動的ネットワーク管理システムであって、
   前記モバイルアクセスルータのグローバルアドレスを把握していない前記モバイルノードから、前記モバイルアクセスルータの前記グローバルアドレスを把握していない旨を示す情報が送信されることによって、前記ローカル固定ルータを介して前記モバイルノードから前記情報を受信した前記モバイルアクセスルータから、前記モバイルノードに対して、前記モバイルアクセスルータの前記グローバルアドレスが通知されるように構成されている動的ネットワーク管理システム。
4. モバイルネットワークを形成するモバイルアクセスルータと、前記モバイルネットワークに属するローカル固定ルータと、前記ローカル固定ルータに接続することによって、前記モバイルネットワークに参加するモバイルノードとを有する通信システムにおける動的ネットワーク管理システムであって、
   前記モバイルアクセスルータのグローバルアドレスを含む情報を受信した前記ローカル固定ルータ内の所定の情報格納手段に、前記モバイルアクセスルータの前記グローバルアドレスが格納されるとともに、前記ローカル固定ルータから前記モバイルノードに対して、前記所定の情報格納手段に格納されている前記モバイルアクセスルータの前記グローバルアドレスが通知されるように構成されている動的ネットワーク管理システム。
5. モバイルネットワークを形成することが可能なモバイルアクセスルータ内に配置される動的ネットワーク管理装置であって、
   前記モバイルネットワークに属するローカル固定ルータに接続するための接続手段と、
   前記モバイルネットワークに参加する任意のモバイルノードから送信され、前記ローカル固定ルータによって前記モバイルアクセスルータに転送されてくる前記モバイルアクセスルータに関する情報を要求する情報を検出する情報検出手段と、
   前記情報検出手段によって前記情報が検出された場合には、前記モバイルアクセスルータに関する情報を通知するために、前記ローカル固定ルータを介して前記情報を送信した前記モバイルノードに向けて転送される前記モバイルアクセスルータに関する情報を含む応答情報を送信する応答情報送信手段とを、
   有する動的ネットワーク管理装置。
6. 前記モバイルアクセスルータに関する情報が、前記モバイルアクセスルータのグローバルアドレスである請求項５に記載の動的ネットワーク管理装置。
7. モバイルネットワークを形成することが可能なモバイルアクセスルータ内に配置される動的ネットワーク管理装置であって、
   前記モバイルネットワークに属するローカル固定ルータに接続するための接続手段と、
   前記モバイルネットワークに参加しており前記モバイルアクセスルータのグローバルアドレスを把握していないモバイルノードから送信され、前記ローカル固定ルータによって前記モバイルアクセスルータに転送されてくる前記モバイルアクセスルータの前記グローバルアドレスを把握していない旨を示す情報を検出する情報検出手段と、
   前記情報検出手段によって前記情報が検出された場合には、前記モバイルアクセスルータの前記グローバルアドレスを通知するために、前記ローカル固定ルータを介して前記情報を送信した前記モバイルノードに向けて転送される前記モバイルアクセスルータの前記グローバルアドレスを含む応答情報を送信する応答情報送信手段とを、
   有する動的ネットワーク管理装置。
8. 前記情報検出手段によって前記情報が検出された場合には、前記情報を含むパケットから前記情報を削除する情報削除手段と、
   前記情報削除手段による前記情報の削除後のパケットを、前記パケットに設定されている所定の送信先に向けて転送する転送手段とを、
   有する請求項６又は７に記載の動的ネットワーク管理装置。
9. 前記情報を含むパケットに設定されている所定の送信先に向けて、前記パケットを転送する転送手段を有する請求項６又は７に記載の動的ネットワーク管理装置。
10. 前記情報を含むパケットを破棄する破棄手段を有する請求項６又は７に記載の動的ネットワーク管理装置。
11. モバイルアクセスルータが形成するモバイルネットワークに参加することが可能なモバイルノード内に配置される動的ネットワーク管理装置であって、
    前記モバイルネットワークに属する任意のルータに接続するための接続手段と、
    前記モバイルアクセスルータに関する情報を把握していない場合に、前記接続手段によって接続されている前記ルータによって前記モバイルアクセスルータに転送される前記モバイルアクセスルータに関する情報を要求する情報を、前記ルータに送信する送信手段と、
    前記送信手段によって送信された前記情報の応答として、前記モバイルアクセスルータによって送信された前記モバイルアクセスルータに関する情報を含む応答情報を、前記ルータから受信する応答情報受信手段とを、
    有する動的ネットワーク管理装置。
12. 前記モバイルアクセスルータに関する情報が、前記モバイルアクセスルータのグローバルアドレスである請求項１１に記載の動的ネットワーク管理装置。
13. モバイルアクセスルータが形成するモバイルネットワークに参加することが可能なモバイルノード内に配置される動的ネットワーク管理装置であって、
    前記モバイルネットワークに属する任意のルータに接続するための接続手段と、
    前記モバイルアクセスルータのグローバルアドレスを把握していない場合に、前記接続手段によって接続されている前記ルータによって前記モバイルアクセスルータに転送される前記モバイルアクセスルータの前記グローバルアドレスを把握していない旨を示す情報を、前記ルータに送信する送信手段と、
    前記送信手段によって送信された前記情報の応答として、前記モバイルアクセスルータによって送信された前記モバイルアクセスルータの前記グローバルアドレスを含む応答情報を、前記ルータから受信する応答情報受信手段とを、
    有する動的ネットワーク管理装置。
14. 所定の通信装置に対して送信するバインディングアップデートメッセージに係るパケットのヘッダに、前記情報を挿入する情報挿入手段を有しており、
    前記送信手段が、前記情報挿入手段によって前記情報が埋め込まれた前記バインディングアップデートメッセージに係る前記パケットを送信するように構成されている請求項１２又は１３に記載の動的ネットワーク管理装置。
15. 前記送信手段が、前記情報の送信と共に、アクセスルータオプションの使用が可能である旨を示す情報を送信するように構成されている請求項１２又は１３に記載の動的ネットワーク管理装置。
16. 前記情報を示す特別なパケットを生成するパケット生成手段を有し、
    前記送信手段が、前記パケット生成手段によって生成された前記特別なパケットを送信するように構成されている請求項１２又は１３に記載の動的ネットワーク管理装置。
17. モバイルネットワークを形成するモバイルアクセスルータに固定的に接続されるローカル固定ルータ内に配置される動的ネットワーク管理装置であって、
    前記モバイルアクセスルータに関する情報を含む情報を受信する受信手段と、
    前記受信手段によって受信された前記モバイルアクセスルータに関する情報を格納する情報格納手段とを、
    有する動的ネットワーク管理装置。
18. 前記モバイルアクセスルータに関する情報が、前記モバイルアクセスルータのグローバルアドレスである請求項１７に記載の動的ネットワーク管理装置。
19. 前記情報格納手段に格納されている前記モバイルアクセスルータの前記グローバルアドレスを、前記ローカル固定ルータの配下に接続されているノードに通知する通知手段を有する請求項１８に記載の動的ネットワーク管理装置。
20. 前記受信手段によって受信された前記情報が、前記モバイルネットワークのデフォルトルータから送られてきたものか否かを判断する判断手段と、
    前記判断手段によって前記デフォルトルータから送られてきたものであると判断された場合にのみ、前記情報格納手段に前記デフォルトルータの前記グローバルアドレスの格納を行うように制御する格納制御手段とを、
    有する請求項１８に記載の動的ネットワーク管理装置。
21. 前記受信手段によって受信される前記情報が、前記モバイルアクセスルータのルータ通知メッセージである請求項１８に記載の動的ネットワーク管理装置。
22. 前記通知手段が、前記モバイルアクセスルータの前記グローバルアドレスを含むルータ通知によって前記ノードへの通知を行うように構成されている請求項１９に記載の動的ネットワーク管理装置。

Images