(57)【特許請求の範囲】
【請求項１】
マルチホーミング・サポートを提供するためのネットワークベースのＩＰモビリティ管理プロトコルを拡張する方法であって、マルチホーミング・グループ情報に基づいてマルチホーミング・サポートを提供するステップを含み、前記情報は、同じモビリティ・セッションの下でモバイルアクセス・ゲートウェイ（Ｍｏｂｉｌｅ  Ａｃｃｅｓｓ  Ｇａｔｅｗａｙ）ＭＡＧの要求に応じてローカルモビリティ・アンカー（Ｌｏｃａｌ  Ｍｏｂｉｌｉｔｙ  Ａｎｃｈｏｒ）ＬＭＡにより管理されるべきモバイルノードＭＮのインターフェイスのグループを識別する方法。
【請求項２】
ＭＮが接続すると、ＭＡＧが、前記マルチホーミング・グループ情報を搬送するマルチホーミング・オプションを含むプロキシバインディング更新ＰＢＵをＬＭＡに送信するステップを含む請求項１に記載の方法。
【請求項３】
ＭＮが接続すると、ＭＡＧが、ＭＮがマルチホーミング・サービスを提供されるかどうか決定し、提供される場合、前記マルチホーミング・グループ情報を搬送するマルチホーミング・オプションを含むプロキシバインディング更新ＰＢＵをＬＭＡに送信するステップを含む請求項１に記載の方法。
【請求項４】
ＭＮが接続すると、ＭＡＧが、マルチホーミング・オプションおよびフロー識別子オプション（複数可）を含むプロキシバインディング更新ＰＢＵをＬＭＡに送信するステップを含む請求項２または３に記載の方法。
【請求項５】
マルチホーミング・グループ情報を含むプロキシバインディング更新ＰＢＵをＭＡＧから受信すると、ＬＭＡが、バインディングキャッシュ・ルックアップを実行して、見出されたバインディングキャッシュ・エントリＢＣＥに前記情報を付加するステップを含む請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
マルチホーミング・グループの識別子ＭＨＧＩＤの選択が、同じホームネットワーク・プレフィックスおよびＭＨＧＩＤ値を持つＭＡＧによってＬＭＡに送信されたすべてのプロキシバインディング更新ＰＢＵが、ＬＭＡの観点から同じモビリティ・セッションに属するように行なわれる請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
デフォルトのマルチホーミング・グループ（ｉｄ＝０）が、ＭＮのすべてのインターフェイスを表すように定義される請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
ＭＮのグループエンティティでの基本操作のサポートを提供する手段を含む請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記基本操作は、初期マルチホーミング・セットアップ、マルチホーミング更新、マルチホーミング・フィルタ変更、マルチホーミング・インターフェイス除去、マルチホーミング・インターフェイス追加のうちの少なくとも１つを含む請求項８に記載の方法。
【請求項１０】
請求項１乃至９のいずれか１項に記載の方法を実行する手段を備えるモバイルアクセス・ゲートウェイＭＡＧ。
【請求項１１】
請求項１乃至９のいずれか１項に記載の方法を実行する手段を備えるローカルモビリティ・アンカーＬＭＡ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、移動体通信ネットワークおよびシステムに関し、そのようなネットワークおよびシステムにおけるモビリティ管理プロトコルに関する。
【背景技術】
【０００２】
移動体通信ネットワークおよびシステム、ならびにそのようなネットワークおよびシステムのモビリティ管理プロトコルの詳細な説明は、特にＩＰモビリティ管理のＩＥＴＦのような標準化機関により発行される文献のような、文献に見出すことができる。
【０００３】
特にＰｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６、ＰＭＩＰｖ６（ＲＦＣ５２１３で規定される）のようなネットワークベースのＩＰモビリティ管理プロトコルは、Ｍｏｂｉｌｅ  ＩＰｖ６のようなホストベースのＩＰモビリティ管理と比較すると、多くの利点を有している。しかし、特にＰＭＩＰｖ６のような、現在規定されているネットワークベースのＩＰモビリティ管理プロトコルは、十分なマルチホーミング・サポートを提供することができない。
【０００４】
そのようなマルチホーミング・サポートを、特にＰＭＩＰｖ６に対して提供する必要性がある。さらに一般的には、ネットワークベースのＩＰモビリティ管理プロトコルを改善する必要性がある。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】２００９年３月の、ＩＥＴＦ  ＮＥＴＥＸＴワーキンググループ「Ｍｕｌｔｉｐｌｅ  Ｉｎｔｅｒｆａｃｅ  Ｓｕｐｐｏｒｔ  ｗｉｔｈ  Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６」
【非特許文献２】２００９年４月のＩＥＴＦ  ＭＥＸＴワーキンググループ「Ｆｌｏｗ  ｂｉｎｄｉｎｇｓ  ｉｎ  Ｍｏｂｉｌｅ  ＩＰｖ６  ａｎｄ  Ｎｅｍｏ  Ｂａｓｉｃ  Ｓｕｐｐｏｒｔ」
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、特にそのような必要性に対応する。
【課題を解決するための手段】
【０００７】
これらのおよびその他の目的は、１つの態様において、１つの実施形態において、マルチホーミング・サポートを提供するためのネットワークベースのＩＰモビリティ管理プロトコルを拡張する方法により達成され、前記方法は、マルチホーミング・グループ情報に基づいてマルチホーミング・サポートを提供するステップを含み、前記情報は、同じモビリティ・セッションの下でモバイルアクセス・ゲートウェイ（Ｍｏｂｉｌｅ  Ａｃｃｅｓｓ  Ｇａｔｅｗａｙ）ＭＡＧの要求に応じてローカルモビリティ・アンカー（Ｌｏｃａｌ  Ｍｏｂｉｌｉｔｙ  Ａｎｃｈｏｒ）ＬＭＡにより管理されるべきモバイルノードＭＮのインターフェイスのグループを識別する。
【０００８】
それらのおよびその他の目的は、もう１つの態様において、そのような方法を実行するための、特にモバイルアクセス・ゲートウェイＭＡＧおよびローカルモビリティ・アンカーＬＭＡのようなエンティティにより達成される。
【０００９】
それらのおよびその他の目的は、付属の図面と併せて以下の説明を読めばさらに十分に明らかとなろう。
【図面の簡単な説明】
【００１０】
【図１】ＰＭＩＰｖ６拡張によりマルチホーミングされるモバイルノードを概略的に示す図である。
【図２】マルチホーミングのために拡張されたモビリティ・セッションを概略的に示す図である。
【図３】初期マルチホーミングのセットアップを概略的に示す図である。
【図４】マルチホーミングの更新を概略的に示す図である。
【図５】マルチホーミングのフィルタの変更を概略的に示す図である。
【図６】マルチホーミングのインターフェイスの除去を概略的に示す図である。
【図７】マルチホーミングのインターフェイスの追加を概略的に示す図である。
【図８】マルチホーミングのオプションを概略的に示す図である。
【図９】ＦＩＤオプションアクション値を概略的に示す図である。
【発明を実施するための形態】
【００１１】
１つの態様において、本発明は、マルチホーミングされるモバイルノード（ＭＮ）をサポートするためにＰｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６に拡張を提供する。これらの拡張は、そのようなモバイルノードが、ＰＭＩＰｖ６ドメインに接続されるときに同時および場合により弁別的な方法で、複数のインターフェイス上でＩＰパケットを送信および受信できるようにすることを目的としている。それらの拡張の標準的な使用法は、フィルタリング規則に基づいて複数のインターフェイスを経由するダウンリンク・フロー弁別を実行することである（たとえば、１つのＭＮインターフェイスをＶＯＩＰトラフィックに、別のＭＮインターフェイスをＨＴＴＰトラフィック専用にする）。
【００１２】
ＰＭＩＰｖ６への提案される拡張は、現在のＰＭＩＰｖ６仕様を、下位互換性のある方法で増強しようと試みる。
【００１３】
［ＲＦＣ５２１３］で規定されるＰｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６（ＰＭＩＰｖ６）は、ＰＭＩＰｖ６ドメインに接続するホストにネットワークベースのモビリティ管理をもたらす。ＰＭＩＰｖ６は、ローカルモビリティ・アンカー（ＬＭＡ）およびモビリティアクセス・ゲートウェイ（ＭＡＧ）という２つの機能エンティティを導入する。ＭＡＧは、ＭＮ接続を検出してＩＰ接続を提供する最初のレイヤ３ホップである。ＬＭＡは、１つまたは複数のＨＮＰをＭＮに割り当てるエンティティであり、ＭＮとの間のすべてのトラフィックに対するトポロジーのアンカーである。ＰＭＩＰｖ６により、ＭＮは、複数のインターフェイスを通じて同じＰＭＩＰｖ６ドメインに接続することができる（そのようなＭＮはマルチホーミングされるＭＮと呼ばれる）。しかし、そのような場合、ＰＭＩＰｖ６は、各インターフェイスが別個のＩＰｖ６アドレスを割り当てられることを要求するので、マルチホーミング機能を妨げる。２００９年３月の、ＩＥＴＦ  ＮＥＴＥＸＴワーキンググループ「Ｍｕｌｔｉｐｌｅ  Ｉｎｔｅｒｆａｃｅ  Ｓｕｐｐｏｒｔ  ｗｉｔｈ  Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６」では、ＰＭＩＰｖ６のマルチホーミングをサポートする方法について検討し、ＩＰｖ６アドレス管理に関して３つの可能なモデルを識別する。
−  インターフェイスごとに一意のプレフィックス
−  インターフェイスごとに一意のアドレス
−  インターフェイスにわたる共有アドレス
ここではさらに、各モデル、特にハンドオーバー動作およびセキュリティの側面に関連するトピックを説明する。
【００１４】
本発明の実施形態についての後段の説明において、インターフェイス・モデルにわたる共用アドレスが一例として検討される。この例において、マルチホーミングされるＭＮが、同じアドレスの下でそのインターネットピアにより認識され、その間、ＭＮが接続されるＰＭＩＰｖ６ドメインが、独自の基準で適したＭＮインターフェイスを通じてパケット搬送を実行することができる事例と適合させることに重点が置かれている。結果として、ＰＭＩＰｖ６ドメインにおいて、単一のホームネットワーク・プレフィックス（ＨＮＰ：Ｈｏｍｅ  Ｎｅｔｗｏｒｋ  Ｐｒｅｆｉｘ）しか、マルチホーミングされるＭＮに関連しない。その他の例が想定されてもよい。
【００１５】
本発明の実施形態についての後段の説明において、（ＭＮインターフェイスが同時に使用される場合）マルチホーミングのコンテキストにおいて紛らわしいと考えられる可能性のあるインターフェイスの「ハンドオーバー」または「モビリティ」という用語が再使用されることはない。代わりに、マルチホーミング・グループ（ＭＮのインターフェイスの論理セット）の概念が導入され、ＭＮのグループエンティティでの基本操作（追加、変更、削除）のサポートが提供される。そのような用語は、一般的なマルチホーミングのパラダイムにさらに適していると期待される。本発明の実施形態についての後段の説明において、例として、所与のＭＮのすべてのインターフェイスを表すようにデフォルトのマルチホーミング・グループ（ｉｄ＝０）が定義される。
【００１６】
ＰＭＩＰｖ６ドメインにおけるマルチホーミングＭＮ機能の機能的な使用法が、柔軟で汎用的に定義される。そうすることで、トラフィック・ブロッキング、トラフィック負荷平準化、またはトラフィック散布のような（これらに限定されない）、マルチホーミングされるＭＮとのＰＭＩＰｖ６ドメインにおけるさまざまなトラフィック処理が可能になる。この柔軟性を達成するため、「フィルタ」の概念が使用されて、ＭＮインターフェイスに関連してＭＡＧとＬＭＡとの間で管理されうる単一の基準を指示する。単一のフィルタは、マルチホーミング・グループごとに追加、削除、および変更することができる。柔軟性は、２００９年４月のＩＥＴＦ  ＭＥＸＴワーキンググループ「Ｆｌｏｗ  ｂｉｎｄｉｎｇｓ  ｉｎ  Ｍｏｂｉｌｅ  ＩＰｖ６  ａｎｄ  Ｎｅｍｏ  Ｂａｓｉｃ  Ｓｕｐｐｏｒｔ」で提案されるように、任意のフィルタ構文（または文法）を許容することにより達成される。フィルタ構文は、ＭＡＧとＬＭＡエンティティとの合意の問題である。
【００１７】
図１は、本発明の実施形態において提案されるマルチホーミング・サポートのためのＰＭＩＰｖ６拡張の一般的原理を示す。
【００１８】
ＭＮがｉｆ１をアクティブ化すると、ＭＡＧ１はデフォルトのマルチホーミング・グループを選択して、ＬＭＡに向けてプロキシ登録を実行する。ＭＡＧ１は、登録中にフィルタ（ｆｌｏｗ１）を提供する。ＬＭＡは、ＭＡＧ１からのプロキシ登録を受け入れ、共用アドレスモデルに従ってＭＮ  ａｄｄｒを割り振る。プロキシ登録はマルチホーミング・サポートを要求しているので、ＬＭＡは、ｐＣｏＡ１への搬送に付随するＭＡＧ１フィルタを格納する。
【００１９】
ＭＮがｉｆ２をアクティブ化すると、ＭＡＧ２はデフォルトのマルチホーミング・グループを選択して、ＬＭＡに向けてプロキシ登録を実行する。ＭＡＧ２は、登録中にフィルタ（ｆｌｏｗ２）を提供する。ＬＭＡは、ＭＡＧ２からのプロキシ登録を受け入れ、共用アドレスモデルに従ってＭＮ  ａｄｄｒを割り振る。ＬＭＡは、ｐＣｏＡ２への搬送に付随するＭＡＧ２フィルタを格納する。
【００２０】
後に、ＬＭＡは、ＭＮ  ａｄｄｒに宛てられたＩＰパケットを受信する。ＬＭＡは、各ＩＰパケットを、ＭＮ  ａｄｄｒに格納されているフィルタ（ｆｌｏｗ１、ｆｌｏｗ２）と適合させるよう試みる。フィルタが適合する場合（ｆｌｏｗ１またはｆｌｏｗ２）、ＬＭＡは、適合するフローのコンテキストにおけるＩＰパケットのアクションを実行する。特に、ＩＰパケットが搬送されるべきである場合、ＬＭＡは、フィルタに関連するｐＣｏＡを使用して（ｆｌｏｗ１でｐＣｏＡ１、またはｆｌｏｗ２でｐＣｏＡ２）搬送を実行する。
【００２１】
ＬＭＡの動作は、複数のインターフェイスにわたりモバイルノードへのダウンリンク（ＤＬ）パケットの同時伝送を可能にするように拡張される。ＭＮがどのようにアップリンク（ＵＬ）パケット伝送を行なうかについては、推測されない。ＭＮは、ＵＬの単一のインターフェイスを使用するか、またはＩＥＴＦ  ＭＩＦワーキンググループにより定義されている機構のような既存または新しい機構に従ってインターフェイスを選択してもよい。
【００２２】
ＬＭＡおよびＭＡＧ動作はいずれも、マルチホーミングされるＭＮに対し拡張プロキシバインディング管理を提供するように拡張される。ＬＭＡは、マルチホーミング・タイプのバインディングコントロール・エントリ（ＢＣＥ：Ｂｉｎｄｉｎｇ  Ｃｏｎｔｒｏｌ  Ｅｎｔｒｙ）をサポートするものとする。これは、ＢＣＥ内のマルチホーミング・グループｉｄ（ｍｈｇｉｄ）およびフィルタのセットを参照する機能を含む。これはまた、マルチホーミングが使用される場合、ＭＮごとに一意のＨＮＰを割り振る機構も含む。ＬＭＡは、フロー仕様に従ってダウンリンク・パケット処理および搬送をサポートまたは代行するものとする。ＭＡＧおよびＬＭＡはいずれも、マルチホーミングされるＭＮ単位でフローを管理することができるものとする。ダウンリンク・フローは、ＰＢＵ／ＰＢＡ交換を使用してＭＡＧ要求に応じてＬＭＡレベルで作成／削除／変更される。
【００２３】
１つの実施態様において、場合によってはフローの概念を使用してダウンリンク伝送基準に関連付けられているモビリティ・セッションごとに複数のプロキシＣｏＡをサポートするようにＰＭＩＰｖ６を拡張することが提案される。
【００２４】
ＭＮが接続すると、ＭＡＧは、ＭＮがマルチホーミング・サービスを提供されるべきであるかどうかを決定し、提供されるべきである場合、自身を通じて搬送するために導入されるべきフロー構成を選択する。ＭＡＧは、この情報を、たとえばポリシーストアを通じて、または接続固有のシグナリングを使用して知ることができる。ＭＡＧは、ＭＮがマルチホーミング・サービスを使用することができると決定する場合、［ＲＦＣ５２１３］によりＰＢＵを形成し、マルチホーミング・オプション（本発明の実施形態において提案される）および場合によっては上記で参照されるＭＥＸＴ文献で定義される１つまたは複数のフロー識別子オプション（Ｆｌｏｗ  Ｉｄｅｎｔｉｆｉｅｒ  ｏｐｔｉｏｎ）を追加する。マルチホーミング・オプションは、ＭＡＧの要求に応じてＬＭＡにより管理（作成／更新／削除）されるべきマルチホーミング・グループを識別して（ＭＨＧＩＤ）パラメータ化することを目指している。マルチホーミング・グループの識別の選択は、同じＨＮＴおよびＭＨＧＩＤ値を持つすべてのＰＢＵが、ＬＭＡの観点から同じモビリティ・セッションに属する、という規則に従うことができる。
【００２５】
図２は、モビリティ・セッションが、複数のインターフェイスにわたり同じＨＮＰに及ぶように拡張される方法を示す。これは、単一インターフェイスが各々異なるモビリティ・セッションの下に管理されるという［ＲＦＣ５２１３］のテキストを更新する。ＭＮの接続時にＭＡＧ１（ＰＣｏＡ１に対応）によって選択されたＭＨＧＩＤは、ＬＭＡにおいて格納される。ＭＮがＭＡＧ２（ＰＣｏＡ２に対応）に接続すると、ＭＡＧ２はそのＭＨＧＩＤ値を選択する。ＭＡＧ１およびＭＡＧ２のＭＧＨＩＤおよびＨＮＰ値が適合する場合、ＬＭＡはｐＣｏＡ２−ＭＨＧＩＤ０を既に存在するモビリティ・セッションに追加する。
【００２６】
ＭＡＧは、ある場合フローをＰＢＵに追加する明示的な指示としてマルチホーミングの指示を処理する。そのようなフローは、たとえばネットワークへのＭＮアクセス中に知ることができる。
【００２７】
マルチホーミングの指示を含むＰＢＵを受信すると、ＬＭＡはバインディングキャッシュ・ルックアップを実行して、見出されたＢＣＥに情報を付加する必要がある。フィルタが、存在する場合は、ＰＢＵから抽出されて、ＬＭＡによって処理される。フィルタ処理の結果は、個別にＬＭＡによってＰＢＡで返される。
【００２８】
これ以降、マルチホーミングのセットアップ、更新、フィルタ変更、およびインターフェイスの除去／追加について流れ図の例を説明する。
【００２９】
図３は、初期マルチホーミングのセットアップを示す。図３は、ＩＦ１の接続、続いてＩＦ２の接続を示す。ＩＦ１およびＩＦ２は、同じマルチホーミング・グループＩＤ（すなわち、デフォルトのマルチホーミング・グループｉｄ  ０）に属する。
【００３０】
図４は、マルチホーミングの更新を示す。図４は、存続期間の満了時にバインディング更新がどのように行なわれるかを示す。
【００３１】
図５は、マルチホーミングのフィルタの変更を示す。フィルタはまた、図５の内部または外部ＭＡＧトリガの受信時に変更されてもよい。ＰＭＩＰｖ６の観点からは、フィルタの変更は、バインディング更新構文（ＨＩ＝５）により搬送される。ターゲットのマルチホーミング・グループは、マルチホーミング・オプション（ＭＨＧＩＤフィールド）でＭＡＧにより設定される。これにより、ＭＡＧは、責任を負っているダウンリンクフィルタをいつでも変更できるようになる。
【００３２】
図６は、マルチホーミングのインターフェイスの除去を示す。図６は、所与のＭＮのＭＡＧにより管理されるマルチホーミング・グループからインターフェイスを除去する方法を示す。ターゲットのマルチホーミング・グループは、マルチホーミング・オプション（ＭＨＧＩＤフィールド）のＭＡＧにより設定される。
【００３３】
図７は、マルチホーミングのインターフェイスの追加を示す。図７は、ＭＮが、第３のインターフェイスを所与のＭＮの同じマルチホーミング・グループに追加する場合を扱う。ターゲットのマルチホーミング・グループは、マルチホーミング・オプション（ＭＨＧＩＤフィールド）でＭＡＧにより設定される。
【００３４】
これ以降、本発明の実施形態で提供される、［ＲＦＣ５２１３］に定義されたプロトコルオプションへの以下の拡張について説明する。
【００３５】
図８は、マルチホーミングのオプションを示す。以下のフィールドが提供される。
Ｔｙｐｅ
未定
Ｌｅｎｇｔｈ
（タイプおよび長さフィールドを除く）オプションの長さをオクテット単位で示す８ビットの符号なし整数。このフィールドは、２に設定する必要がある。
ＭＨＧＩＤ
この８ビットフィールドは、ＰＢＵ／ＰＢＡが参照するマルチホーミング・グループを識別する。値０は、ＭＮのすべてのインターフェイスを含むデフォルトのマルチホーミング・グループに予約済みである。値０だけがサポートされうる。
ＡＣＴ
この３ビットフィールドは、インターフェイスがマルチホーミング・グループから除去されるときに、ＬＭＡによって実行されるべきオプションのアクションを提供するために使用される。フィールドは、ＰＢＵのＨＩ値が４に設定される場合に限りＭＡＧにより設定されるものとし、それ以外の場合、フィールドは０に設定されるものとする。
以下のビット値が現在定義されている。
０００：  Ｒｅｓｅｒｖｅｄ（予約済み）
００１：  フィルタを除去
０１０：  フィルタを保持
ＲＦＵ（将来の使用に備えて予約される）
この５ビットのフィールドは、現在未使用である。値は送信者により０に初期化される必要があり、受信者に無視される必要がある。
【００３６】
ＡＣＴフィールドについて以下の考慮が適用されてもよい。００１（フィルタを除去）がインターフェイス除去時に設定される場合、ＬＭＡは現在構成されているすべてのフィルタを除去するものとする。その結果、ダウンリンク・トラフィックの混乱をもたらすこともある。０１０（フィルタを保持）がインターフェイス除去時に設定される場合、ＬＭＡは、マルチホーミング・グループの他のインターフェイスがあればその既存のフィルタ（ある場合）に、除去されるインターフェイスで構成されたフィルタを再インスタンス化するよう手配するものとする。それにより、ダウンリンク・トラフィックの混乱を回避することができる。ＬＭＡレベルにおけるこのアクションの実施態様は、規定されてもよい。しかし、インターフェイスで再インスタンス化されたフィルタは、ＭＡＧがインターフェイスでフィルタ操作を実行するごとに、フロー識別子オプションの特定のステータスでＬＭＡによってアドバタイズされるべきである。
【００３７】
図９は、フロー識別子オプションを示す。上記で参照されるＭＥＸＴ文献で定義されるＦＩＤオプションは、マルチホーミングされるＭＮのインターフェイスにわたりダウンリンク・パケット搬送を管理するために使用されてもよい。このオプションは、ＭＮの特定のマルチホーミング・グループに対してＬＭＡでフィルタ（複数可）を作成／変更／削除するためにＭＡＧに使用されてもよい。ＬＭＡレベルにおいてフィルタ（複数可）の処理およびインストールが正常に行なわれると、個々のステータス（Ｓｔａｔｕｓフィールド）は、ＬＭＡによりＭＡＧに返されるものとする。ＬＭＡは後に、同じモビリティ・セッションの下にＭＮの代理となるＭＡＧ（複数可）によりインストールされたフィルタを通じてＭＮに宛てられたパケットを評価する必要がある。ＬＭＡは、適合するフィルタ（複数可）に関連するアクション（複数可）を実行することができる。
【００３８】
ＬＭＡが、所与のＭＮについてＭＡＧに向かうマルチホーミング・インターフェイス・グループでフローを再インスタンス化する場合、ＬＭＡは以下の処理を実行することができる。
−  ターゲットＬＭＡに向かうＭＮのマルチホーミング・グループに対する既存フィルタのコンテキスト内で再インスタンス化されたフィルタに一意のＦＩＤを割り振る。
−  ＰＲＯフィールドを、現在の仕様により提案される［ＭＥＸＴ］の新しい予約済み値（２：ＬＭＡにより再インスタンス化されるフローバインディング）に設定する。
−  元のフィルタからそこで再インスタンス化されたフィルタにＦＩＤ−ＰＲＩおよびＡｃｔｉｏｎフィールドをコピーする。
【００３９】
［ＲＦＣ５２１３］においてＭＡＧおよびＬＭＡ間で通知機構が現在定義されていないので、再インスタンス化されたフィルタ（複数可）はＭＡＧの要求に応じてのみＬＭＡにより返される。これは、ＭＡＧがＰＢＵを更新するか、またはそれ自身のフィルタを作成／変更／削除するときに生じる場合がある。
【００４０】
これ以降、オプションのフォーマットを簡単に参照する。実施形態において、事前定義済みの値（２：ＬＭＡにより再インスタンス化されるフローバインディング）を追加するためにＰＲＯフィールド値を拡張することが提案される。オプションの仕様全体は、上記で参照されるＭＥＸＴ文献に見出される。
【００４１】
これ以降、本発明の実施形態におけるＭＡＧの動作について説明する。
【００４２】
ＭＡＧは、ＭＮが接続すると、「ＲＦＣ５２１３］に従ってすべてのステップを実行する。このことに加えて、ＭＡＧは以下の確認を実行する。ＭＡＧは、ＭＮが新しいモビリティ・セッションの一環としてＨＮＰを要求しているかどうか、またはＭＮが既に存在するモビリティ・セッションの一環として新しいインターフェイスを接続するよう要求しているかどうか知る。ＭＡＧは、たとえばＭＮのプロファイルおよびフィルタからＭＨＧＩＤを取り出す。ＭＡＧは、たとえばアクセス固有の方法で、またはその他のインフラストラクチャのサポートを介して、フィルタを知ることができる。いかなる場合においても、ＭＡＧは、少なくとも以前規定されたマルチホーミング・オプション、および場合によっては１つまたは複数のＦＩＤオプションを含むＰＢＵをエンコードする。
【００４３】
ＭＡＧは、実行されるべきフィルタ操作（複数可）を搬送するＰＢＵを送信することによりマルチホーミング・グループに接続されたフィルタを変更または削除することができる。これは、ＬＭＡによって何が返されるかに応じて、個々の結果を分析するものとする。加えて、ＭＡＧは、ＭＮが同じマルチホーミング・グループに属するインターフェイスを切断したときに、ＬＭＡによって再インスタンス化されたフィルタを処理する準備ができている必要がある。
【００４４】
ＭＮが関連するインターフェイスを切り離したことをＭＮの代理をするＭＡＧが検出する場合、ＭＡＧは存続期間を０に設定したＰＢＵを送信することによりＭＮの代理をやめ、切り離したインターフェイスのターゲットのマルチホーミング・グループを識別するマルチホーミング・オプション、ならびにフィルタに関する除去動作を含む。ＭＡＧは、正常なＰＢＡがＭＮアクセスを解放するのを待つ。
【００４５】
これ以降、本発明の実施形態におけるＬＭＡの動作について説明する。
【００４６】
ＬＭＡは、ＢＣＥおよび概念的データ構造において変更されるべきである。ＢＣＥの変更：ＬＭＡバインディングキャッシュ・ルックアップの方法は、マルチホーミングのサポートに対応するように拡張される必要がある。ＬＭＡは、マルチホーミング・オプションを処理する場合、「ＲＦＣ５２１３］に定義されるように既存のモビリティ・セッションを更新する必要がある。このことに加えて、ＭＡＧは以下の確認を実行する。
【００４７】
マルチホーミング・オプションがＰＢＵに存在する場合、ＬＭＡは、モビリティ・セッションおよびそれが参照するマルチホーミング・グループＩＤを割り振る／更新する／削除する。ＰＢＵで受信されたフローフィルタは、ターゲットのマルチホーミング・グループＩＤに対して作成される／変更される／削除され、結果は個々のフィルタごとに返されるものとする。
【００４８】
加えて、ＬＭＡは、ＭＡＧの指示に従ってマルチホーミング・グループからのインターフェイスの除去を処理する。特に、ＭＡＧが、マルチホーミング・グループからインターフェイスを除去するがフィルタは保持するようＬＭＡに指示する場合、ＬＭＡは、各自の機構に従ってマルチホーミング・グループの既存のインターフェイス（複数可）でフィルタを再インスタンス化する必要がある。
【００４９】
ＬＭＡが、本文書の実施形態によって提案される、マルチホーミング拡張（全体として）または特定のマルチホーミング・オプションをサポートしない場合、ＬＭＡは「ＲＦＣ５２１３］に定義されるようにＰＢＡでステータスコードを返すことができる。後の仕様は、以下のようなマルチホーミング固有のステータスを含むように拡張されてもよい。
ＭＨ＿ＮＯＴ＿ＳＵＰＰＯＲＴＥＤ＿ＢＹ＿ＬＭＡ
ＭＨ＿ＦＩＬＴＥＲＳ＿ＲＥＩＮＳＴＡＮＣＩＡＴＩＯＮ＿ＮＯＴ＿ＳＵＰＰＯＲＴＥＤ＿ＢＹ＿ＬＭＡ
【００５０】
１つの態様において、１つの実施形態において、本発明は、ネットワークベースのＩＰモビリティ管理プロトコルを改善する方法を提供し、前記プロトコルはモバイルアクセス・ゲートウェイＭＡＧとローカルモビリティ・アンカーＬＭＡとの間で実行し、前記方法は、ＭＡＧとＬＭＡ間で交換されるマルチホーミング・グループ情報に基づいてマルチホーミング・サポートを提供するステップを含み、前記情報は、同じモビリティ・セッションの下でＭＡＧの要求に応じてＬＭＡにより管理されるべきモバイルノードＭＮのインターフェイスのグループを識別する。
【００５１】
１つの実施形態において、前記方法は、
−  ＭＮが接続すると、ＭＡＧが、前記マルチホーミング・グループ情報を搬送するマルチホーミング・オプションを含むプロキシバインディング更新ＰＢＵをＬＭＡに送信するステップを備える。
【００５２】
１つの実施形態において、前記方法は、
−  ＭＮが接続すると、ＭＡＧが、ＭＮがマルチホーミング・サービスを提供されるかどうか決定し、提供される場合、前記マルチホーミング・グループ情報を搬送するマルチホーミング・オプションを含むプロキシバインディング更新ＰＢＵをＬＭＡに送信するステップを備える。
【００５３】
１つの実施形態において、前記方法は、
−  ＭＮが接続すると、ＭＡＧが、マルチホーミング・オプションおよびフロー識別子オプション（複数可）を含むプロキシバインディング更新ＰＢＵをＬＭＡに送信するステップを備える。
【００５４】
１つの実施形態において、前記方法は、
−  マルチホーミング・グループ情報を含むプロキシバインディング更新ＰＢＵをＭＡＧから受信すると、ＬＭＡが、バインディングキャッシュ・ルックアップを実行して、見出されたバインディングキャッシュ・エントリＢＣＥに情報を付加するステップを備える。
【００５５】
１つの実施形態において、マルチホーミング・グループの識別子ＭＨＧＩＤの選択は、同じホームネットワーク・プレフィックスおよびＭＨＧＩＤ値を持つＭＡＧによってＬＭＡに送信されたすべてのプロキシバインディング更新ＰＢＵが、ＬＭＡの観点から同じモビリティ・セッションに属するように行なわれる。
【００５６】
１つの実施形態において、デフォルトのマルチホーミング・グループ（ｉｄ＝０）は、ＭＮのすべてのインターフェイスを表すように定義される。
【００５７】
１つの実施形態において、前記方法は、ＭＮのグループエンティティでの基本操作のサポートを提供するステップを備える。
【００５８】
１つの実施態様において、前記基本操作は、初期マルチホーミング・セットアップ、マルチホーミング更新、マルチホーミング・フィルタ変更、マルチホーミング・インターフェイス除去、マルチホーミング・インターフェイス追加のうちの少なくとも１つを含む。ネットワークベースのＩＰモビリティ管理プロトコルの改善のための方法（その例は上記で説明されている）に加えて、本発明はまた、１つの実施形態においてそのような方法を行なうための手段を備える、特にモバイルアクセス・ゲートウェイＭＡＧ、およびローカルモビリティ・アンカーＬＭＡのようなさまざまなエンティティをその目的とする。
【００５９】
１つの実施態様において、以下のものを備えるモバイルアクセス・ゲートウェイＭＡＧが提供される。
−  ＭＮが接続すると、マルチホーミング・グループ情報を搬送するマルチホーミング・オプションを含むプロキシバインディング更新ＰＢＵをＬＭＡに送信する手段であって、前記情報は、同じモビリティ・セッションの下でモバイルアクセス・ゲートウェイＭＡＧの要求に応じてローカルモビリティ・アンカーＬＭＡにより管理されるべきモバイルノードＭＮのインターフェイスのグループを識別する手段。
【００６０】
１つの実施態様において、前記モバイルアクセス・ゲートウェイＭＡＧは、以下のものを備える。
−  ＭＮが接続すると、ＭＮがマルチホーミング・サービスを提供されるかどうか決定し、提供される場合、マルチホーミング・グループ情報を搬送するマルチホーミング・オプションを含むプロキシバインディング更新ＰＢＵをＬＭＡに送信する手段であって、前記情報は、同じモビリティ・セッションの下でモバイルアクセス・ゲートウェイＭＡＧの要求に応じてローカルモビリティ・アンカーＬＭＡにより管理されるべきモバイルノードＭＮのインターフェイスのグループを識別する手段。
【００６１】
１つの実施態様において、前記モバイルアクセス・ゲートウェイは、以下のものを備える。
−  ＭＮが接続すると、マルチホーミング・オプションおよびフロー識別子オプション（複数可）を含むプロキシバインディング更新ＰＢＵをＬＭＡに送信する手段。
【００６２】
１つの実施形態において、マルチホーミング・グループの識別子ＭＨＧＩＤの選択は、同じホームネットワーク・プレフィックスおよびＭＨＧＩＤ値を持つＭＡＧによってＬＭＡに送信されたすべてのプロキシバインディング更新ＰＢＵが、ＬＭＡの観点から同じモビリティ・セッションに属するように行なわれる。
【００６３】
１つの実施形態において、デフォルトのマルチホーミング・グループ（ｉｄ＝０）は、ＭＮのすべてのインターフェイスを表すように定義される。
【００６４】
１つの実施形態において、前記モバイルアクセス・ゲートウェイは、ＭＮのグループエンティティでの基本操作のサポートを提供する手段を備える。
【００６５】
１つの実施態様において、前記基本操作は、初期マルチホーミング・セットアップ、マルチホーミング更新、マルチホーミング・フィルタ変更、マルチホーミング・インターフェイス除去、マルチホーミング・インターフェイス追加のうちの少なくとも１つを含む。
【００６６】
１つの実施態様において、以下のものを備えるローカルモビリティ・アンカーＬＭＡが提供される。
−  マルチホーミング・グループ情報を含むプロキシバインディング更新ＰＢＵをＭＡＧから受信すると、バインディングキャッシュ・ルックアップを実行して、見出されたバインディングキャッシュ・エントリＢＣＥに情報を付加する手段であって、前記情報は、同じモビリティ・セッションの下でモバイルアクセス・ゲートウェイＭＡＧの要求に応じてローカルモビリティ・アンカーＬＭＡにより管理されるべきモバイルノードＭＮのインターフェイスのグループを識別する手段。
【００６７】
１つの実施形態において、マルチホーミング・グループの識別子ＭＨＧＩＤの選択は、同じホームネットワーク・プレフィックスおよびＭＨＧＩＤ値を持つＭＡＧによってＬＭＡに送信されたすべてのプロキシバインディング更新ＰＢＵが、ＬＭＡの観点から同じモビリティ・セッションに属するように行なわれる。
【００６８】
１つの実施形態において、デフォルトのマルチホーミング・グループ（ｉｄ＝０）は、ＭＮのすべてのインターフェイスを表すように定義される。
【００６９】
１つの実施形態において、前記ローカルモビリティ・アンカーＬＭＡは、ＭＮのグループエンティティでの基本操作のサポートを提供する手段を備える。
【００７０】
１つの実施態様において、前記基本操作は、初期マルチホーミング・セットアップ、マルチホーミング更新、マルチホーミング・フィルタ変更、マルチホーミング・インターフェイス除去、マルチホーミング・インターフェイス追加のうちの少なくとも１つを含む。
【００７１】
前述の手段の詳細な実施態様は、当業者にはなんら特別な問題を提起することはなく、それゆえそのような手段は、当業者に対して、それらの機能により上記で行なわれているよりもさらに詳細に開示される必要はない。
【００７２】
当業者であれば、前述のさまざまな方法のステップがプログラムされたコンピュータによって実行されてもよいことを容易に理解するであろう。本明細書において、一部の実施形態はまた、たとえばデジタルデータストレージ媒体のような、機械またはコンピュータ可読であり、機械実行可能またはコンピュータ実行可能な命令のプログラムをエンコードするプログラムストレージデバイスを網羅することも意図され、前記命令は前記上記の方法のステップの一部または全部を実行する。プログラムストレージ媒体は、たとえばデジタルメモリ、磁気ディスクおよび磁気テープのような磁気ストレージ媒体、ハードドライブ、または光学式読み取り可能デジタルデータストレージ媒体であってもよい。実施形態はまた、上記の方法の前記のステップを実行するようにプログラムされるコンピュータを網羅することも意図される。
【図１】
0005674778.tif 000002
【図２】
0005674778.tif 000003
【図３】
0005674778.tif 000004
【図４】
0005674778.tif 000005
【図５】
0005674778.tif 000006
【図６】
0005674778.tif 000007
【図７】
0005674778.tif 000008
【図８】
0005674778.tif 000009
【図９】
0005674778.tif 000010