JP4938891B2 - ネットワークベース・ローカル移動管理 - Google Patents

Description

本発明は、ネットワークベース・ローカル移動管理（ＮｅｔＬＭＭ）を提供するネットワーク・アーキテクチュアに関し、特に、アクセスルータとしてホスト識別プロトコル（ＨＩＰ）プロキシを使用するネットワーク・アーキテクチュアに関する。

図１は移動体機器５との無線通信を可能にするネットワーク１の概要を例示している。その移動体機器は、例えば、移動電話機またはブラックベリー（登録商標）デバイスのような移動無線機器であり、一般的に“移動体ノード（ＭＮ）”と呼ばれる。

よく知られるように、移動体ノード５は複数のアクセスポイント４（“ＡＰ”）を介しネットワーク１に接続できる。各アクセスポイントは地理的カバレッジの定義エリヤを持ち、移動体ノード５が移動すると、移動体ノードが、あるアクセスポイントがサービスを提供する地理的エリヤから別のアクセスポイントがサービスを提供する地理的エリヤへ移ると、あるアクセスポイントから別のアクセスポイントへ移動体ノードを“ハンドオフ”する。あるアクセスポイントから別のアクセスポイントへ移動体ノードをハンドオフするとき、その移動体ノードのユーザが通信の切断または中断を経験しないことが望ましい。

ネットワークベース・ローカル移動管理（ＮｅｔＬＭＭ）はＩＥＴＦが保証する手法であり、移動体ノードに拡張レイヤ２リンクの錯覚を与えるかもしれない。ＮｅｔＬＭＭの問題への１つの具体的な解決策はＩＥＴＦのＮＥＴＬＭＭ作業部会において現在標準化作業が進められている（http://www.ietf.org./html.charters/NetLMMcharter.htmlを参照されたい）。ＩＥＴＦで作業中であるように、その基本的なアーキテクチュアは、非特許文献１に記載されている。図１は、非特許文献１で定義するようなＮｅｔＬＭＭの基本的なアーキテクチュアを示す。

図１のネットワークでは、モビリティアクセスゲートウェイ（ＭＡＧ）とも呼ばれる幾つかのアクセスルータ（ＡＲ）３ａ、３ｂ、３ｃがＮｅｔＬＭＭドメインに関与している。ＮｅｔＬＭＭドメインのアクセスルータはローカルモビリティアンカー（ＬＭＡ）２ａ、２ｂと関連している。図１の例では、アクセスルータ３ａ、アクセスルータ３ｂは１つのローカルモビリティアンカー２ａと関連する１つＮｅｔＬＭＭドメインに関与するが、アクセスルータ３ｃは別のローカルモビリティアンカー２ｂと関連する異なるＮｅｔＬＭＭドメインに関与する。１つのＮｅｔＬＭＭドメインのアクセスルータは全て、その隣接発見プロトコル（ＮＤＰ）ルータ・アドバタイズメント（ＲＡ）メッセージにおいて同一ＩＰｖ６ルーティングプレフィックスを通知する。これは、同じＩＰｖ６リンクがこれらＡＲの間にも拡張され、それ故、移動体ノードがそのＮｅｔＬＭＭドメインに留まる限り移動体ノードとＮｅｔＬＭＭドメインとの間の明示的なモビリティ・シグナリングの必要を回避するという錯覚を生じさせるものとなる。換言すれば、移動体ノードはその移動がＮｅｔＬＭＭドメイン内に制限されている限り、そのＩＰアドレスを保存するのである。

図１で、アクセスルータにより制御される１つのアクセスポイントと（図１で“リンク内モビリティ”により表わされる）同じアクセスルータにより制御される別のアクセスポイントとの間を移動する移動体ノード、または、アクセスルータにより制御される１つのアクセスポイントと、別の、しかし、（図１で“ローカルモビリティ”により表わされる）第１のアクセスルータと同じローカルモビリティアンカーと関連するアクセスルータにより制御される別のアクセスポイントとの間を移動する移動体ノードは、１つのＮｅｔＬＭＭドメインに留まる。しかしながら、１つのローカルモビリティアンカーと関連するアクセスルータにより制御される１つのアクセスポイントから（図１で“グローバルモビリティ”により表わされる）別のローカルモビリティアンカーと関連するアクセスルータにより制御される別のアクセスポイントへと移動する移動体ノードは、あるＮｅｔＬＭＭドメインから別のＮｅｔＬＭＭドメインへと変化する。

Ｈ．レフコべッツ他、編著（H. Levkowetz Editor, et al）、ＮｅｔＬＭＭプロトコル（The NetLMM Protocol）、作業進行中のインターネット草案、draft-giaretta-NetLMM-dt-protocol-02、２００６年１０月 Ｒ．モスコビッツ（R. Moskowitz）及びＰ．ニカンダ（P. Nikander）著、ホスト識別プロトコルアーキテクチュア（Host Identity Protocol Architecture）、作業進行中のインターネット草案、２００５年８月 Ｒ．モスコビッツ（R. Moskowitz）、Ｐ．ニカンダ（P. Nikander）、Ｐ．ヨーケラ（P. Jokela）、及びＴ．ヘンダーソン（T. Henderson）著、ホスト識別プロトコル（Host Identity Protocol）、作業進行中のインターネット草案、２００５年１０月 Ｐ．ヨーケラ他（P. Jokela et al）著、ＨＩＰサービス発見（HIP Service Discovery）、作業進行中のインターネット草案、draft-jokela-hip-service-discovery-00、２００６年６月 Ｊ．ラガニエ他（J. Laganier et al）著、ホスト識別プロトコル（ＨＩＰ）の登録拡張（Host Identity Protocol (HIP) Registration Extension）、作業進行中のインターネット草案、draft-ietf-hip-registration-02、２００６年６月 ブルームフィルタ（Bloom Filters）「http://en.wikipedia.org/wiki/Bloom filter」 Ｊ．ラガニエ（J. Laganier）、Ｓ．ナラヤナン（S. Narayanan）、及び、Ｆ．テンプリン（F. Templin）著、移動体ノードとアクセスルータ間ネットワークベース・ローカル移動管理インタフェース（Network-based Localized Mobility Management Interface between Mobile Node and Access rounter）、作業進行中のインターネット草案、draft-ietf-NetLMM-mn-ar-if-01、２００６年６月 Ｊ．ラガニエ（J. Laganier）、及び、Ｌ．エッガート（L. Eggert）著、ホスト識別プロトコル（ＨＩＰ）ランデブー拡張（Host Identity Protocol (HIP) Rendezvous Extension）、作業進行中のインターネット草案、draft-ietf-hip-rvs-05、２００６年７月

本発明の１つの側面は、１つ以上のアクセスポイントに結合し、使用する場合、アクセスルータとして動作する少なくとも１つのホスト識別プロトコルプロキシを有するＮｅｔＬＭＭドメインを含むネットワークを提供することである。

本発明に従えば、図１のネットワークのＮｅｔＬＭＭ・モビリティアクセスゲートウェイ／アクセスルータには、ＨＩＰ（ホスト識別プロトコル）機能が備えられる、即ち、ＨＩＰプロキシとして実施される。ＨＩＰの典型的な利点の全ては、ＮｅｔＬＭＭドメインをより柔軟にするために利用可能である点にある。

本発明は既存の解決策に比較して以下の追加的な利点を提供する。即ち、
１． 基礎をなすインフラストラクチャに関して、これがＮｅｔＬＭＭの機能には見えることなく、アクセスルータ／モビリティアクセスゲートウェイが、それぞれのアクセスポインと共に移動するという意味で、アクセスルータ／モビリティアクセスゲートウェイはそれ自体、移動体でありうる。その例には、アクセスポイントとアクセスルータを有したバスがありえ、その乗客のラップトップが移動体ノードである。バスルート全体は種々のパーティ（例えば、インターネット運用者／市民など）が提供するネットワークカバレッジを有する。アクセスルータは利用可能なアクセスネットワークの１つに常に接続し、従って移動体ノードにアクセスルータがその時点で接続するネットワークへのアクセスを提供することになろう。移動体ノードは移動を検出せず、アクセスネットワークの変更回数や誰がアクセスネットワークをするのかに関わらず、そのＩＰアドレスを維持することになろう。
２． アクセスルータはＩＰｖ４ネットワークに常駐することができ、ＮＡＴ（ネットワークアドレス変換）ボックスの背後にさえ存在しうる。
３． 機密保護されたチャネルをアクセスルータとＬＭＡとの間に設け、機密保護されていないネットワークにおける移動体アクセスルータの展開を容易にすることができる。

各ドメインは、そのドメインにおける前記ＨＩＰプロキシ或いは各ＨＩＰプロキシに結合される各ローカルモビリティアンカーを含むことができる。このようなケースでは、ＨＩＰプロキシに基づく解決策のネットワーク・アーキテクチュアは、従来のＮｅｔＬＭＭのようなネットワーク・アーキテクチュアでも良い。ここで、ローカルモビリティアンカー（ＬＭＡ）は、必要であれば、中央ハブおよびインターネットへのＨＩＰトラフィックの終端の双方として作用する。ＬＭＡ自体はＨＩＰ機能を備えると良い。

あるいは、そのドメインのアクセスルータ（複数）に代わり、ＮｅｔＬＭＭドメインのＬＭＡはＨＩＰ機能を備えても良い。

あるいは、ドメインの２つ以上のＨＩＰプロキシを、例えば、本願と同時出願で係属中の国際出願ＰＣＴ／ＥＰ２００７／０５５９３０（代理人であるマークスおよびクラークの参照番号Ｐ５４２８４ＷＯ）に記載されるように分散配置することができる。ネットワーク・アーキテクチュアは外部への必要なゲートウェイを備え、完全に分散することができる。２つの発明を組み合わせることにより特別なインフラストラクチャを必要とせずに移動体ＮｅｔＬＭＭアクセスルータを相互接続することが可能になる。

分散配置する複数のＨＩＰプロキシの１つから、１つ以上のさらなるＨＩＰプロキシを階層的に配置することができる。

そのドメインは１つ以上のブルームフィルタ（Bloom filter）を含むルーティングテーブルを含むことができる。

少なくとも１つのＨＩＰプロキシは移動体プロキシであると良い。

本発明の第２の側面は、１つ以上のホスト識別プロトコル（ＨＩＰ）プロキシをＮｅｔＬＭＭドメインの各アクセスルータとして割り当てる工程を有する方法を提供することである。

その方法は、ホスト識別プロトコル（ＨＩＰ）プロキシをドメインのローカルモビリティアンカーとして割り当てる工程を付加的に、或いは、代替的に有すると良い。

その方法がさらに、
ａ） ＨＩＰプロキシとＮｅｔＬＭＭドメインとの間におけるホスト識別プロトコル（ＨＩＰ）の関連性を生成する工程と、
ｂ） 新規プロキシ・サービス・プロバイダとして前記ＨＩＰプロキシを前記ドメインに登録する工程と、
ｃ） 前記登録の受け入れの是非を判断する工程と、
ｄ） 前記登録が受け入れられるならば、前記ドメインのアクセスルータとして前記ＨＩＰプロキシを使用する工程と
を有すると良い。

前記工程（ａ）は、ＨＩＰプロキシとドメインのローカルモビリティアンカーとの間におけるＨＩＰの関連性を生成する工程を有しても良い。その代替として、前記工程（ａ）は、ＨＩＰプロキシとドメインの既存ＨＩＰプロキシとの間におけるＨＩＰの関連性を生成する工程を有しても良い。

この方法は、ＮｅｔＬＭＭドメインの識別情報によりＨＩＰプロキシを構成設定するさらなる工程と，その後に、ＨＩＰプロキシとＮｅｔＬＭＭドメインとの間におけるＨＩＰの関連性を生成する工程とを有していても良い。

この方法は、その登録が受け入れられるなら、前記ＨＩＰプロキシに登録応答を送信する工程をさらに有していても良い。

この方法は、ＮｅｔＬＭＭドメインにＨＩＰプロキシを分散配置する工程を有していても良い。

この方法は、その登録が受け入れられるならば、ドメインの少なくとも１つの他のアクセスルータに登録の詳細を送信する工程をさらに有していても良い。

この方法は、ホスト識別プロトコル（ＨＩＰ）プロキシをＮｅｔＬＭＭドメインのローカルモビリティアンカーとして割り当てる工程を有していても良い。

少なくとも１つのＨＩＰプロキシは移動体ＨＩＰプロキシであると良い。

本発明のさらなる側面は、ホスト識別プロトコルプロキシにより構成設定される、ＮｅｔＬＭＭドメインのアクセスルータまたはＮｅｔＬＭＭドメインのローカルモビリティアンカーを提供することにある。

そのアクセスルータは、これを使用する場合、
ａ） ＮｅｔＬＭＭドメインとのホスト識別プロトコル（ＨＩＰ）関連性の生成し、
ｂ） 新規プロキシ・サービス・プロバイダとして前記ドメインへ登録し、
ｃ） その登録が受け入れられるならば、ドメインのアクセスルータとしての動作する
工程を実行するように適合されていると良い。

アクセスルータは、ＨＩＰプロキシとＮｅｔＬＭＭドメインのローカルモビリティアンカーとの間におけるＨＩＰの関連性を生成するように適合されると良い。

アクセスルータは、ＨＩＰプロキシとＮｅｔＬＭＭドメインの既存ＨＩＰプロキシとの間におけるＨＩＰの関連性を生成するように適合されると良い。

アクセスルータは、ＮｅｔＬＭＭドメインの識別情報によりＨＩＰプロキシを構成設定し、その後、ＨＩＰプロキシとＮｅｔＬＭＭドメインとの間におけるＨＩＰの関連性を生成するさらなる工程を実行するように適合されると良い。

アクセスルータは、その登録が受け入れられたことを示す登録応答を受信するように適合されると良い。

アクセスルータまたはローカルモビリティアンカーは、移動体ＨＩＰプロキシにより構成設定されると良い。

本発明のさらなる側面は、前述した側面であるアクセスルータまたはローカルモビリティアンカーを含むネットワークを提供することである。

次に、添付図面を参照して、本発明の好適な実施例について説明する。

ＩＥＴＦのＮｅｔＬＭＭ作業部会が提案するネットワーク・アーキテクチュアのブロック概要図である。 本発明のネットワーク・アーキテクチュアのブロック概要図である。 本発明の別のネットワーク・アーキテクチュアのブロック概要図である。 本発明の別のネットワーク・アーキテクチュアのブロック概要図である。 本発明の別のネットワーク・アーキテクチュアのブロック概要図である。 本発明の方法のブロックフローチャートである。 本発明の別のネットワーク・アーキテクチュアのブロック概要図である。

図２は移動体機器５との無線通信を可能にするネットワーク１０のブロック概要図である。ＨＩＰ（ホスト識別プロトコル）プロキシにＨＩＰ機能を設けるＨＩＰとして各アクセスルータ／移動体アクセスゲートウェイ３ａ、３ｂ、３ｃを実施することを除いて、ネットワーク１０の構成は図１のＮｅｔＬＭＭネットワークの構成に類似している。

既知のごとく、ホスト識別プロトコルはエンドポイントの識別子情報の役割とＩＰ（インターネットプロトコル）アドレスのロケータの役割とを分離する。ホスト識別プロトコルは新規のグローバルインターネットの名称の空間を定義し、これがエンドポイントの識別子情報の役割とロケータの役割とを分離する。ＨＩＰにより、トランスポート層はエンドポイントの名称としてＩＰアドレスを使用するよりむしろホスト識別情報において動作する一方、ネットワーク層は純粋なロケータとしてＩＰアドレスを使用する。

ＨＩＰを用いる場合、識別子は公開−秘密鍵のペアの公開鍵である。ＨＩＰホスト識別情報（ＨＩ）は、公開鍵であり、極めて長い可能性があり、それ故に、全ての状況において実用的でない。ＨＩＰでは、ＨＩをハッシュすることによりＨＩから生成する１２８ビット長のホスト識別タグ（ＨＩＴ）によりＨＩを表す。従って、ＨＩＴはＨＩを特定する。ＨＩＴは１２８ビット長であり、ＩＰｖ６アドレスと正確に同じ長さであるので、ＨＩＴをＩＰｖ６アプリケーションに直接使用することができる。

ホスト識別情報の別の表現は、ローカル範囲識別情報（ＬＳＩ：Local Scope Identifier）であり、これはホスト識別情報の３２ビット表現である。ＬＳＩの目的は、既存プロトコルにおけるホスト識別情報とアプリケーションプログラムインタフェース（ＡＰＩ）の使用を容易にすることである。例えば、そのＬＳＩはＩＰｖ４アドレスと同じ長さであるので、ＬＳＩはＩＰｖ４アプリケーションに直接使用することができる。

ＨＩＰを使用する場合、アプリケーションを含む上位層は最早ＩＰアドレスを見ない。代わって、上位層は宛先ホストの“アドレス”としてＨＩＴ（またはＬＳＩ）を見る。ロケーション情報を新規レイヤでは隠す。これは以下に説明する。そのＩＰアドレスは、最早ノードを特定しない。即ち、ＩＰアドレスはネットワークにおけるパケットをルーティングすることにのみ使用される。

ＨＩＰプロトコルの更なる詳細は、例えば、非特許文献２、或いは、非特許文献３に見ることができる。

図２の実施例では、アクセスルータ１３ａ〜１３ｃは複数のＮｅｔＬＭＭドメインに再配置される。これら各ドメインは、それぞれのローカルモビリティアンカー１２ａ、１２ｂを含む。図２に示す第１のＮｅｔＬＭＭドメインは、２つのアクセスルータ１３ａ、１３ｂを含み、（図２に完全には図示していないが）アクセスルータ１３ｃは第２のドメインに属する。しかしながら、本発明は図２に示すアクセスルータとアクセスポートの具体的な構成に限定されるものではない。

本発明のネットワークアーキテクチュアは図１に示すＩＥＴＦ構成によって提供される全ての特徴を備えることができる。さらに、本発明のネットワークアーキテクチュアは、ＮｅｔＬＭＭインフラストラクチャ内におけるモビリティサポートの改善を行うことができ、従って、移動体アクセスルータとともに固定アクセスルータを容易にサポートすることができる。しかしながら、図１に示すＩＥＴＦアーキテクチュアは、移動体アクセスルータをサポートすることができない。アクセスルータが、例えば、バスに配置され、従ってＨＩＰが提供するモビリティとルート最適化の利益を得ることができる都市に無線ネットワークを展開するという環境において、例えば、本発明は適用される。

移動体アクセスルータに伴う１つの問題はセキュリティである。アクセスルータが移動体であれば、アクセスネットワークの利用可能なセキュリティレベルはアクセスルータが移動する場合、おそらく変動する。ＨＩＰ移動体プロキシは、アクセスルータと関連するＬＭＡとの間に機密保護されたチャネルを確立することができるので、本発明は移動体アクセスルータに高いセキュリティを提供することができ、それにより接続のハイジャックや移動体ノードの追跡を防ぎ、（移動体ノードのアクセスネットワークは保護されないままであるが）機密保護されていないネットワークにおける移動体アクセスルータの展開を容易にできる。

さらにＨＩＰの典型的な利点の全ては、ＩＰｖ４（ＩＰバージョン４）とＩＰｖ６（ＩＰバージョン６）の双方への容易な展開とアクセスルータ間のルート最適化とを含むＮｅＴＬＭＭドメインをさらに柔軟にするのに利用可能である点である。その上、ＮＡＴ（ネットワークアドレス変換）ボックスをアクセスルータとアクセスルータが登録されるＬＭＡとの間に設けられれば、そのアクセスルータはＮＡＴボックスの背後にさえ置かれる。

本発明のさらなる実施例では、ローカルモビリティアンカーはまた、そのローカルモビリティアンカーにＨＩＰ機能を提供するＨＩＰプロキシとして、実施される。この実施例を図３に概略的に示されている。ローカルモビリティアンカーにＨＩＰ機能を提供することは別にして、図３の実施例は図２の実施例に対応する。

本発明のさらなる実施例では、アクセスルータに代わりＮｅＴＬＭＭドメインのローカルモビリティアンカーにＨＩＰ機能を提供するＨＩＰプロキシとして、ＮｅＴＬＭＭドメインのローカルモビリティアンカーが実施される。この実施例は図７に概略的に示されており、その図によれば、図示される両方のＮｅＴＬＭＭドメインのローカルモビリティアンカー１２ａ、１２ｂをＨＩＰプロキシとして実施される。図７で、１方のローカルモビリティアンカー１２ａの背後にある何らかの移動体ノードは、他方のローカルモビリティアンカー１２ｂの背後にある何らかの移動体ノードと接続することができる。しかしながら注意すべきは、ＨＩＰを意識しない従来のホストは、移動体ローカルモビリティアンカーに接続できないことである。ＨＩＰを意識しない従来のホストに接続することが望ましい場合、ネットワーク階層の最上位のエンティティは静的なものでなければならない。（図７で、その図に示す両方のＮｅＴＬＭＭドメインのローカルモビリティアンカーはＨＩＰプロキシとして実施されるが、一般にはＮｅＴＬＭＭドメインが移動可能であり、そのドメインにおいて少なくとも１つのＨＩＰが可能なホストがある必要がある場合、ＨＩＰプロキシとして実施されるローカルモビリティアンカーを、全てではないが幾つかのドメインが有することは、原理上可能であろう）。

図２、図３、及び図７のネットワーク・アーキテクチュアは階層構造のアーキテクチュアであり、必要であれば、各ドメインには中央ハブとインターネットへのＨＩＰトラフィックの終端の両方として動作するそれぞれのローカルモビリティアンカーが備えられる。しかしながら、本発明は階層構造のアーキテクチュアに限定されるものではなく、ドメインのアクセスルータが分散構成を有し、ローカルモビリティアンカーを持たないアーキテクチュアに適用しても良い。このような実施例は図４に概略的に示されており、ここでは、アクセスルータ１３ａ〜１３ｅは、１つのＮｅｔＬＭＭドメインに属し、アクセスルータ１３ｆは（図４で完全には示されていない）別のＮｅｔＬＭＭドメインに属している。図４の分散アクセスルータのアーキテクチュアは、係属中の国際出願ＰＣＴ／ＥＰ２００７／０５５９３０（代理人であるマークスおよびクラークの参照番号Ｐ５４２８４ＷＯ）に詳細に記載されており、これに注意を向けると、要約するなら、ＮｅＴＬＭＭドメインの各ルータ１３ａ〜１３ｅには、ブルームフィルタ（Bloom Filter）のようなルーティング情報が提供され、そのルーティング情報はどの移動体ノードがそのＮｅＴＬＭＭドメインの他のアクセスルータ夫々の背後に現在存在しているのかをリストするというものである。この実施例では、本発明は１つのアクセスルータと別のアクセスルータとの間の機密保護されたチャネルの確立を可能にし、それによってまた、接続のハイジャックや移動体ノードの追跡を防ぎ、機密保護されていないネットワークにおける移動体アクセスルータの展開を容易にしている。

また本発明は、例えば、図５に示すように部分的分散構成にも適用することができる。図５の部分的分散構成では、アクセスルータ１３ａ〜１３ｄは上記のように分散構成を有する。しかしながら、アクセスルータ１３ｄは、ここでは２つのアクセスルータ１３ｅ、１３ｆにより表わされているアクセスルータの階層を表現している。アクセスルータ１３ｄによりドメインの他のアクセスルータ１３ａ〜１３ｃに提供されるルーティング情報は（いずれかのアクセスポイントがアクセスルータ１３ｄに直接接続する場合では）アクセスルータ１３ｅの背後、アクセスルータ１３ｆの背後、及び、アクセスルータ１３ｄの背後に位置する移動体ノードに関する情報を含んでいる。アクセスルータ１３ｄ、１３ｅ、または１３ｆのいずれかの背後の移動体ノードに宛てた入力パケットが、例えば、アクセスルータ１３ａにおいて受信される場合、アクセスルータ１３ａはそのルーティング情報を調べ、そのパケットがアクセスルータ１３ｄに送信されるべきであると判断し、そのパケットをアクセスルータ１３ｄに送信するであろう。

アクセスルータ１３ｄはその下位にあるアクセスルータ１３ｅ、１３ｆの個々のルーティング情報（例えば、ブルームフィルタ）とともに、それ自体のローカルなルーティング情報（ブルームフィルタ）を維持する。パケットがアクセスルータ１３ｄに着信すると、アクセスルータ１３ｄはルーティング情報を調べ、パケットが宛先とする移動体ノードがアクセスルータ１３ｄそれ自体の背後にあるか、アクセスルータ１３ｅの背後にあるか、またはアクセスルータ１３ｆの背後にあるかを判断し、その判断に従いパケットをルーティングする。

図２、図３、図４、及び図５の実施例では、移動体ノードまたはアクセスポイントへの変更の必要はない。

次に、本発明のネットワークアーキテクチュアのＮｅＴＬＭＭドメインの維持における種々のステップについて説明する。ＨＩＰプロキシの動的追加または除去が「ドメインの維持」を意味する。最上位レベルでは、このことは、アクセスルータ／移動体アクセスゲートウェイの追加または除去に関して、他のＮｅｔＬＭＭ構成に必要な手順とは大きく違わない。しかしながら、全てのインフラストラクチャノード（アクセスルータ／移動体アクセスゲートウェイ、及び、あるとすればローカルモビリティアンカー）がＨＩＰを実現することを想定すると、現行ＩＥＴＦの文献より、より詳細な解決策を記述することが可能である。

ＮｅＴＬＭＭドメインに新規ＨＩＰプロキシを追加し、アクセスルータ／モビリティアクセスゲートウェイとしての役目を果たすために、図６に概略的に示されている以下の手順が想定される。
１． 新規ＨＩＰプロキシを（ＬＭＡのホスト識別タグ（ＨＩＴ）のような）ドメイン
識別情報で構成設定するか（ステップ１）、または新規ＨＩＰプロキシがＨＩＰ
サービス発見プロトコル（非特許文献４）のような他の手段によりドメインを
発見するかのいずれかを行う；
２． 新規ＨＩＰプロキシがドメインとのＨＩＰ関連性を生成する（ステップ２）；
ａ． ネットワークアーキテクチュアが従来のものであれば、ＨＩＰ関連性は
ＬＭＡで生成される；
ｂ． ネットワークアーキテクチュアが分散するものであれば、ＨＩＰ関連性は
複数の既存ＨＩＰプロキシ（ＡＲ／ＭＡＧ）のいずれかで生成される；
３． 新規ＨＩＰプロキシがＨＩＰ登録プロトコル（非特許文献５）を使用し、新規の
プロキシ・サービス・プロバイダとして自分自身をドメインに登録する
（ステップ３）；
４． ドメイン（ＬＭＡまたはＭＡＧ）は構成設定される機密保護のポリシーに依存し
登録の受諾または拒否のいずれかを行う（ステップ４）。分散アーキテクチュア
のケースでは、そのポリシーは既に関与しているＨＩＰプロキシの間で形成され
る会議、或いは、他の分散決定形成手順を必要とする。登録が拒否されれば、
その手順は失敗に終わる
ａ． ドメインが分散構成で実施されれば、登録は他の関与するプロキシへ分散
される必要があるか，または
ｂ． 決定形成に関与する複数のプロキシが、新規プロキシがドメインにおいて
サービスを提供することを認可する証明書に共に署名することができるか
のいずれかである。
５． 登録要求の受諾に際し送信される登録応答（ステップ５）で、ＨＩＰプロキシは
ＮｅｔＬＭＭドメインで使用されるルーティングプレフィックスのような、
必要な構成設定パラメータを受信する。分散アーキテクチュアのケースでは、
プロキシはまた（例えば、非特許文献６を使用して）ネットワークアーキテク
チュアについての情報も受信する。
６． 一度登録すると、プロキシは移動体ノードにサービスを提供する準備が整う。

上記のＨＩＰ登録手順を使用して、ドメインに加われば、更新しない限り登録と発行された証明書の内の少なくともいずれかの有効期限切れに際し、プロキシはドメインから自動的に削除されるであろう。

ＨＩＰプロキシはその背後にある移動体ノード全てを単に除去することにより、ドメインにおけるサービス提供を早めに停止することができる。登録の有効期限が切れるや否や他のプロキシで情報は自動的に除去されるであろうから、その他の動作は不要である。

代替として、ＬＭＡに送信される、或いは、関与する全てのＡＲ／ＭＡＧに分配される別の署名した停止メッセージがあっても良い。

新規の移動体ノードがあるＨＩＰプロキシに到着すると、その移動体ノードはＩＰｖ６アドレスの割り当てを受ける必要がある。このアドレスは非特許文献７で定義されているように、ドメインに割り当てられたルーティングプレフィックスから割り当てられる。

本発明のＨＩＰプロキシベース・アーキテクチュアとその他のＮｅｔＬＭＭアーキテクチュアとの間においてドメイン内のノードモビリティに本質的相違はない。同様に、本発明のＨＩＰプロキシベース・アーキテクチュアとその他のＮｅｔＬＭＭ構成との間で消滅する移動体ノードに関する本質的相違はない。

本発明のＨＩＰプロキシベース・アーキテクチュアとその他のＮｅｔＬＭＭアーキテクチュアとの間で接続の確立に本質的相違はない。しかしながら、両方の移動体ノードが同一ＮｅｔＬＭＭドメイン内に存在するケースでは、ＨＩＰプロキシベース・アーキテクチュアによりルート最適化が可能になる。

図４に示すように、分散ＨＩＰプロキシベースのアーキテクチュアのケースでは、ＮｅｔＬＭＭドメインのＡＲ／ＭＡＧ全ては、ＮｅｔＬＭＭドメイン内のピアＡＲ／ＭＡＧにパケットをルーティングするのに必要な（ブルームフィルタを使用する）情報を持つ。

図２または図３におけるように、従来の階層構造のアーキテクチュアの場合には、ピアが同一ＮｅｔＬＭＭドメイン内に存在する場合、送信側クライアントのＡＲ／ＭＡＧは宛先アドレスにより気付くであろう。それにより、関係するＡＲ／ＭＡＧ間で直接接続を確立することにより、階層アーキテクチュアにおけるルーティングを最適化することが可能である。これは、例えば、非特許文献８が提案するように、ランデブーサーバをＬＭＡに統合することにより実施されよう。

なお、本発明は、図２〜図５、及び図７に示された具体的な構成及びアクセスポイントとアクセスルータとの数に限定されるものではなく、その構成やアクセスポイントとアクセスルータの数は図２〜図５、及び図７に示すものから変更されても良い。

Claims (25)

1. １つ以上のアクセスポイントに結合し、使用する場合、アクセスルータとして動作する１つ或は複数のホスト識別プロトコル（ＨＩＰ）プロキシを有するＮｅｔＬＭＭドメインを有し、
   １つ或は複数のＨＩＰプロキシは移動体プロキシであることを特徴とするネットワーク。
2. 前記ドメインは、前記ドメインにおける前記ＨＩＰプロキシ、或いは、各プロキシに結合されたローカルモビリティアンカーを有することを特徴とする請求項１に記載のネットワーク。
3. 前記ローカルモビリティアンカーは、ＨＩＰローカルモビリティアンカーであることを特徴とする請求項２に記載のネットワーク。
4. ドメイン内の前記複数のＨＩＰプロキシは分散配置されることを特徴とする請求項１に記載のネットワーク。
5. ドメイン内の前記複数のＨＩＰプロキシの内の２つ以上のプロキシは分散配置され、
   ドメイン内の前記複数のＨＩＰプロキシの内のさらに１つ以上のプロキシは前記分散配置された前記複数のＨＩＰプロキシの内の１つに対して階層的に配置されることを特徴とする請求項１に記載のネットワーク。
6. 前記ドメインは１つ以上のブルームフィルタを含むルーティングテーブルを有することを特徴とする請求項４又は５に記載のネットワーク。
7. ドメインに対するローカルモビリティアンカーとして使用され動作する少なくとも１つのホスト識別プロトコル（ＨＩＰ）プロキシを有するＮｅｔＬＭＭドメインを有し、
   少なくとも１つのＨＩＰプロキシは移動体プロキシであることを特徴とするネットワーク。
8. ＮｅｔＬＭＭドメインの各アクセスルータとして１つ以上のホスト識別プロトコル（ＨＩＰ）プロキシを割当てる工程と、
   前記ＮｅｔＬＭＭドメインの識別情報で前記ＨＩＰプロキシを構成設定する工程と、
   ａ） ＨＩＰプロキシと前記ＮｅｔＬＭＭドメインとの間におけるホスト識別プロトコル（ＨＩＰ）の関連性を生成する工程と、
   ｂ） 新規プロキシ・サービス・プロバイダとして、ＨＩＰプロキシを前記ドメインに登録する工程と、
   ｃ） 前記登録の受け入れの是非を判断する工程と、
   ｄ） 前記登録を受け入れるならば、前記ドメインのアクセスルータとしてＨＩＰプロキシを使用する工程と、
   を有することを特徴とする方法。
9. 前記ドメインのローカルモビリティアンカーとして更なるホスト識別プロトコル（ＨＩＰ）プロキシを割当てる工程をさらに有することを特徴とする請求項８に記載の方法。
10. 前記ａ）の前記ＨＩＰの関連性を生成する工程は、前記ＨＩＰプロキシと前記ドメインのローカルモビリティアンカーとの間における前記ＨＩＰの関連性を生成する工程を有することを特徴とする請求項８に記載の方法。
11. 前記ａ）の前記ＨＩＰの関連性を生成する工程は、前記ＨＩＰプロキシと前記ドメインの既存のＨＩＰプロキシとの間における前記ＨＩＰの関連性を生成する工程を有することを特徴とする請求項８に記載の方法。
12. 前記登録を受け入れれば、前記ＨＩＰプロキシに登録応答を送信する工程をさらに有することを特徴とする請求項８乃至１１のいずれか１項に記載の方法。
13. 前記ＮｅｔＬＭＭドメインに前記ＨＩＰプロキシを分散配置する工程をさらに有することを特徴とする請求項８に記載の方法。
14. 前記登録を受け入れれば、前記ドメインの少なくとも１つの他のアクセスルータに前記登録の詳細を送信する工程をさらに有することを特徴とする請求項８乃至１３のいずれか１項に記載の方法。
15. ＮｅｔＬＭＭドメインのローカルモビリティアンカーとして、ホスト識別プロトコル（ＨＩＰ）プロキシを割り当てる工程と、
    前記ＮｅｔＬＭＭドメインの識別情報で前記ＨＩＰプロキシを構成設定する工程と、
    ａ） ＨＩＰプロキシと前記ＮｅｔＬＭＭドメインとの間におけるホスト識別プロトコル（ＨＩＰ）の関連性を生成する工程と、
    ｂ） 新規プロキシ・サービス・プロバイダとして、ＨＩＰプロキシを前記ドメインに登録する工程と、
    ｃ） 前記登録の受け入れの是非を判断する工程と、
    ｄ） 前記登録を受け入れるならば、前記ドメインのローカルモビリティアンカーとしてＨＩＰプロキシを使用する工程と、
    を有することを特徴とする方法。
16. 少なくとも１つのＨＩＰプロキシは移動体ＨＩＰプロキシであることを特徴とする請求項８乃至１５のいずれか１項に記載の方法。
17. ホスト識別プロトコル（ＨＩＰ）プロキシにより構成されるＮｅｔＬＭＭドメインのアクセスルータであって、
    前記アクセスルータは、
    ａ） ＮｅｔＬＭＭドメインとのホスト識別プロトコル（ＨＩＰ）の関連性を生成し、
    ｂ） 新規プロキシ・サービス・プロバイダとして、前記ドメインへ登録し、
    ｃ） 前記登録が受け入れられれば、前記ドメインのアクセスルータとしての動作する工程を実行するように使用され、
    前記ＮｅｔＬＭＭドメインの識別情報により前記ＨＩＰプロキシを構成設定し、その後に前記ＨＩＰプロキシと前記ＮｅｔＬＭＭドメインとの間における前記ＨＩＰの関連性を生成するように適合されていることを特徴とする記載のアクセスルータ。
18. 前記ＨＩＰプロキシと前記ＮｅｔＬＭＭドメインのローカルモビリティアンカーとの間における前記ＨＩＰの関連性を生成するように適合されていることを特徴とする請求項１７に記載のアクセスルータ。
19. 前記ＨＩＰプロキシと前記ＮｅｔＬＭＭドメインの既存ＨＩＰプロキシとの間における前記ＨＩＰの関連性を生成するように適合されていることを特徴とする請求項１７に記載のアクセスルータ。
20. 前記登録が受け入れられたことを示す登録応答を受信するよう適合されていることを特徴とする請求項１７に記載のアクセスルータ。
21. 移動体ＨＩＰプロキシにより構成設定されることを特徴とする請求項１７乃至２０のいずれか１項に記載のアクセスルータ。
22. ホスト識別プロトコル（ＨＩＰ）プロキシにより構成されるＮｅｔＬＭＭドメインのローカルモビリティアンカーであって、
    前記ローカルモビリティアンカーは、
    ａ） ＮｅｔＬＭＭドメインとのホスト識別プロトコル（ＨＩＰ）の関連性を生成し、
    ｂ） 新規プロキシ・サービス・プロバイダとして、前記ドメインへ登録し、
    ｃ） 前記登録が受け入れられれば、前記ドメインのローカルモビリティアンカーとしての動作することを実行するように使用され、
    前記ＮｅｔＬＭＭドメインの識別情報により前記ＨＩＰプロキシを構成設定し、その後に前記ＨＩＰプロキシと前記ＮｅｔＬＭＭドメインとの間における前記ＨＩＰの関連性を生成するように適合されていることを特徴とするローカルモビリティアンカー。
23. 移動体ＨＩＰプロキシにより構成設定されることを特徴とする請求項２２に記載のローカルモビリティアンカー。
24. 請求項１７乃至２１のいずれか１項に記載のアクセスルータを有するネットワーク。
25. 請求項２２又は２３に記載のローカルモビリティアンカーを有するネットワーク。