JP2009529266A

JP2009529266A - Mobile IPv6 optimized reverse tunneling for multihomed terminals

Info

Publication number: JP2009529266A
Application number: JP2008557644A
Authority: JP
Inventors: キリアンウェニゲール; イェンスバッフマン
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2006-03-08
Filing date: 2007-03-02
Publication date: 2009-08-13
Anticipated expiration: 2027-03-02
Also published as: JP4990920B2

Abstract

本発明は、複数のモバイル・ネットワークを備える移動通信システムにおける、マルチホームの移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための方法に関する。この方法は、通信相手ノードとの通信に使用されるそのホーム・アドレスのうちの１つを、移動ノードによって選択するステップを含む。移動ノードは、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録する。通信相手ノードのホーム・エージェント及び移動ノードのホーム・エージェントは、候補となるプロキシ・ホーム・エージェント・アドレスを受信し、格納する。通信相手ノードのホーム・エージェントは、通信相手ノードに要求を送信する。通信相手ノードは、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、通信相手ノードのホーム・エージェントに、気付アドレスとして登録する。プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つが、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントの両方で選択され、トンネルの２つのエンド・ポイントが、選択されたプロキシ・ホーム・エージェント・アドレス及び選択された移動ノードの気付アドレスのうちの１つであるように、トンネルを切り替えるために、移動ノードは移動ノードのホーム・エージェントによってトリガされ、通信相手ノードは通信相手ノードのホーム・エージェントによってトリガされる。
【選択図】図２The present invention relates to a method for packet-switched data transmission between a multi-homed mobile node and a correspondent node in a mobile communication system comprising a plurality of mobile networks. The method includes the step of selecting by the mobile node one of its home addresses used for communication with the correspondent node. The mobile node registers at least one of a plurality of addresses assigned to the target network interface as a care-of address with the home agent of the mobile node responsible for the selected home address. . The home agent of the correspondent node and the home agent of the mobile node receive and store candidate proxy home agent addresses. The home agent of the correspondent node sends a request to the correspondent node. The correspondent node registers at least one of a plurality of addresses assigned to the target network interface as a care-of address in the home agent of the correspondent node. At least one of the proxy home agent address, one of the care-of address of the mobile node, and one of the care-of address of the correspondent node are the home agent of the mobile node and the home of the correspondent node. To switch tunnels so that the two endpoints of the tunnel selected by both agents are one of the selected proxy home agent address and the care-of address of the selected mobile node The mobile node is triggered by the mobile node's home agent, and the correspondent node is triggered by the correspondent node's home agent.
[Selection] Figure 2

Description

本発明は移動通信システムに関する。より詳細には、本発明は、モバイル・インターネット・プロトコル（モバイルＩＰ）又は同様のプロトコルに基づいた移動通信向けの位置プライバシー及びルート最適化に関する。 The present invention relates to a mobile communication system. More particularly, the present invention relates to location privacy and route optimization for mobile communications based on the Mobile Internet Protocol (Mobile IP) or similar protocol.

本発明について、モバイル・インターネット・プロトコル・バージョン６（モバイルＩＰｖ６）の例に関して説明する。しかし、本発明は、説明されるモバイルＩＰのエンティティに対応する等価のエンティティを定義する他のプロトコルにも適用可能である。 The present invention will be described with reference to the Mobile Internet Protocol version 6 (Mobile IPv6) example. However, the present invention is also applicable to other protocols that define equivalent entities corresponding to the described Mobile IP entities.

モバイルＩＰｖ６は、現在、双方向トンネリング及びルート最適化という、２つの動作モードを定義している。前者のモードでは、すべてのデータ・パケットが送信側移動ノードのホーム・エージェントを介してルーティングされる必要があるが、後者は、移動ノードと通信相手ノードとの間で直接パスを使用する。 Mobile IPv6 currently defines two modes of operation: bidirectional tunneling and route optimization. In the former mode, all data packets need to be routed through the home agent of the sending mobile node, whereas the latter uses a direct path between the mobile node and the correspondent node.

移動ノード（ＭＮ）は、サブネット間を移動する場合、そのＩＰアドレスをトポロジー的に正しいものに変更しなければならない。その理由は、インターネットの階層的ルーティング構造によるものであり、すなわち、ＩＰアドレスは識別の目的で働くだけではなく、位置情報も含む。しかし、ＴＣＰなどの上位レイヤでの接続は通信ノードのＩＰアドレス（及びポート）によって定義されるため、例えば、移動によって、ノードのうちの１つがそのＩＰアドレスを変更した場合、この接続は切断される。 When a mobile node (MN) moves between subnets, its IP address must be changed to a topologically correct one. The reason is due to the hierarchical routing structure of the Internet, i.e. the IP address not only serves for identification purposes but also contains location information. However, since the connection in the upper layer such as TCP is defined by the IP address (and port) of the communication node, for example, when one of the nodes changes its IP address due to movement, this connection is disconnected. The

モバイルＩＰｖ６（Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、「ＭｏｂｉｌｉｔｙＳｕｐｐｏｒｔｉｎＩＰｖ６」、ＩＥＴＦＲＦＣ３７７５、２００４年６月）は、移動ノード（ＭＮ）が上位レイヤに対してトランスペアレントに、すなわち上位レイヤ接続を切断することなく、サブネット間を移動できるようにする、レイヤ３モビリティ・プロトコルである。このためＭＮは、気付アドレス（ＣｏＡ）及びホーム・アドレス（ＨｏＡ）という、２つのＩＰアドレスを使用する。ＭＮの上位レイヤは、通信相手ノード（ＣＮ）との通信にＨｏＡを使用する。このアドレスは変更されず、ＭＮを識別するために働く。このアドレスはトポロジー的には、ＭＮのホーム・ネットワーク（ＨＮ）に属する。これに対してＣｏＡは、結果としてサブネットが変更されるあらゆる移動で変更され、ルーティング・インフラストラクチャに関するロケータとして使用される。これはトポロジー的には、ＭＮが現在訪問しているネットワークに属する。ホーム・リンク上に配置されたホーム・エージェント（ＨＡ）のセットのうちの１つが、ＭＮのＣｏＡのＭＮのＨｏＡへのマッピングを維持し、ＭＮに関する着信トラフィックをその現在の位置にリダイレクトする。冗長性及びロード・バランシングのために、１つのＨＡではなくＨＡのセットを使用することができる。 Mobile IPv6 (D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004) is a mobile node (MN) that is transparent to the upper layer, that is, upper layer connection Layer 3 mobility protocol that allows movement between subnets without disconnecting. Therefore, the MN uses two IP addresses, a care-of address (CoA) and a home address (HoA). The upper layer of the MN uses HoA for communication with the correspondent node (CN). This address is not changed and serves to identify the MN. Topologically, this address belongs to the home network (HN) of the MN. In contrast, the CoA changes with every move that results in a subnet change and is used as a locator for the routing infrastructure. Topologically, this belongs to the network that the MN is currently visiting. One of the set of home agents (HA) located on the home link maintains a mapping of the MN's CoA to the MN's HoA and redirects incoming traffic for the MN to its current location. Instead of a single HA, a set of HAs can be used for redundancy and load balancing.

モバイルＩＰｖ６は、現在、双方向トンネリング及びルート最適化という、２つの動作モードを定義する。双方向トンネリングが使用される場合、ＣＮによって送信され、ＭＮのＨｏＡにアドレス指定されたデータ・パケットは、ホーム・ネットワーク内のＨＡによってインターセプトされ、ＭＮのＣｏＡへとトンネリングされる。ＭＮによって送信されたデータ・パケットは、パケットをデカプセル化（ｄｅｃａｐｓｕｌａｔｅ）してそれらをＣＮへと送信するＨＡへ、リバース・トンネリングされる。この動作のために、ＭＮのＣｏＡに関しては、ＨＡのみに通知しなければならない。したがって、ＭＮは、バインディング・アップデート（ＢＵ）メッセージをＨＡに送信する。これらのメッセージは、ＩＰｓｅｃセキュリティ関係を介して送信され、認証される。ＣＮはＭＮのＣｏＡを認識しないため、ＭＮの位置を導出することはできず、位置プライバシーが与えられる。しかし、ＭＮがホーム・ネットワークから遠く離れており、ＣＮがＭＮに近い場合、通信パスは不必要に長くなり、結果として非効率的なルーティング及び大きなパケット遅延が生じることになる。 Mobile IPv6 currently defines two modes of operation: bidirectional tunneling and route optimization. If bi-directional tunneling is used, data packets sent by the CN and addressed to the MN's HoA are intercepted by the HA in the home network and tunneled to the MN's CoA. Data packets sent by the MN are reverse-tunneled to the HA that decapsulates the packets and sends them to the CN. For this operation, the MN's CoA must be notified only to the HA. Therefore, the MN sends a binding update (BU) message to the HA. These messages are sent and authenticated via an IPsec security relationship. Since the CN does not recognize the MN's CoA, it cannot derive the location of the MN and is given location privacy. However, if the MN is far away from the home network and the CN is close to the MN, the communication path becomes unnecessarily long, resulting in inefficient routing and large packet delay.

様々なタイプの位置プライバシーが区別できることに留意されたい。本発明が目標とする１つは、ＣＮに対してＭＮの位置（及び、それ故、ＣｏＡ）を隠すことである。他のタイプは、盗聴者に対して位置を隠すこと、又はＭＮの位置の追跡を防止することである。 Note that different types of location privacy can be distinguished. One goal of the present invention is to hide the location of MN (and hence CoA) from CN. Another type is to hide the location from the eavesdropper or prevent tracking of the location of the MN.

ルート最適化モードは、ＣＮとＭＮの間で直接パスを使用することによって、上述の非効率性を防止することができる。したがって、ＭＮはＣＮにＢＵメッセージを送信し、その後ＣＮは、ＭＮにパケットを直接トンネリングできるようになる（実際には、ＩＰ−ｉｎ−ＩＰトンネルではなくタイプ２ルーティング・ヘッダが使用される）。もちろん、ＣＮは、モバイルＩＰｖ６ルート最適化をサポートしなければならない。ＢＵメッセージを認証するために、ＭＮ及びＣＮは、ＨｏＡ及びＣｏＡでＭＮの到達可能性をテストし、共有セッション・キーを生成する、いわゆるリターン・ルータビリティ・プロシージャを実行する。しかし、ＣＮはＢＵメッセージを利用してＭＮのＣｏＡを習得するため、その位置を導出することが可能であり、すなわち位置プライバシーは与えられない。 The route optimization mode can prevent the above-described inefficiency by using a direct path between the CN and the MN. Thus, the MN sends a BU message to the CN, which can then tunnel the packet directly to the MN (actually a type 2 routing header is used rather than an IP-in-IP tunnel). Of course, the CN must support mobile IPv6 route optimization. In order to authenticate the BU message, the MN and CN perform a so-called return routability procedure that tests the reachability of the MN with the HoA and CoA and generates a shared session key. However, since CN learns the MN's CoA using the BU message, its location can be derived, i.e., location privacy is not given.

ＶｏＩＰなどの対話型アプリケーションはパケット遅延がわずかであることを要求するため、位置プライバシー及びルート最適化の両方を提供するメカニズムが間違いなく望ましい。この目標を達成するために様々な手法が使用可能であり、その一部は他の目的で設計されている。しかし、それらはすべて、訪問したネットワークに新しいインフラストラクチャ構成要素を導入するものである（又は既存の構成要素の変更を必要とする）。現在訪問しているネットワークがこうした構成要素を提供しない場合、位置プライバシー及びルート最適化は使用不能であり、プライバシー保護された対話型通信ができない可能性があることを意味する。こうした新しい構成要素のグローバルな配置は、すなわち各アクセス・ネットワークにおいて、長時間を要するか、又は決して実施できない可能性さえある。他のソリューションは、一方向の位置プライバシーしか提供せず、すなわち両方の通信パートナが移動体である場合、位置情報が少なくとも１つのノードにしか明らかにされない。一部の他のソリューションは、大規模に配置された場合、スケーラビリティの問題を有する。訪問したネットワークにおいて新しいか又は修正された構成要素の導入を必要とせず、両方の通信パートナが移動体である場合にも動作し、配置に関してスケーラブルである、ソリューションが望ましい。本発明は、こうしたソリューションについて説明する。 Because interactive applications such as VoIP require low packet delay, a mechanism that provides both location privacy and route optimization is definitely desirable. Various approaches can be used to achieve this goal, some of which are designed for other purposes. However, they all introduce new infrastructure components (or require changes to existing components) in the visited network. If the currently visited network does not provide such components, location privacy and route optimization are disabled, meaning that privacy-protected interactive communication may not be possible. This global placement of new components may take a long time or even never be implemented in each access network. Other solutions only provide one-way location privacy, i.e. if both communication partners are mobile, the location information is only revealed to at least one node. Some other solutions have scalability issues when deployed on a large scale. A solution that does not require the introduction of new or modified components in the visited network, works even when both communication partners are mobile, and is scalable with respect to deployment is desirable. The present invention describes such a solution.

新しいインフラストラクチャ構成要素を導入する手法は、階層化モバイルＩＰｖ６（ＨＭＩＰ）、アクセス・ルータカプセル化キャッシュ（ＡｃｃｅｓｓＲｏｕｔｅｒＥｎｃａｐｓｕｌａｔｉｏｎＣａｃｈｅｓ）（ＡＲＥＣ）、最適化ルート・キャッシュ（ＯｐｔｉｍｉｚｅｄＲｏｕｔｅＣａｃｈｅｓ）（ＯＲＣ）、グローバル・ホーム・エージェント対ホーム・エージェント・プロトコル（ＧｌｏｂａｌＨｏｍｅＡｇｅｎｔｔｏＨｏｍｅＡｇｅｎｔＰｒｏｔｏｃｏｌ）（ＧｌｏｂａｌＨＡＨＡ）、ＷＯ０３０４１３５８、ＷＯ２００４０１０６６８、及びＵＳ２００５０４１６７５である。これらの手法について、以下で簡単に説明する。 Techniques for introducing new infrastructure components include Hierarchical Mobile IPv6 (HMIP), Access Router Encapsulation Cache (AREC), Optimized Route Cache (ORC), Global • Home Agent to Home Agent Protocol (GlobalHAHA), WO03031358, WO2004010668, and US2005041675. These methods are briefly described below.

ＨＭＩＰ（ＨｅｓｈａｍＳｏｌｉｍａｎ、ＣｌａｕｄｅＣａｔｅｌｌｕｃｃｉａ、ＫａｒｉｍＥｌＭａｌｋｉ、ＬｕｄｏｖｉｃＢｅｌｌｉｅｒ、「ＨｉｅｒａｒｃｈｉｃａｌＭｏｂｉｌｅＩＰｖ６ｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔ（ＨＭＩＰｖ６）」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔｉｅｔｆ−ｍｉｐｓｈｏｐ−ｈｍｉｐｖ６−０４．ｔｘｔ、２００４年１２月）は、（潜在的に遠隔にある）ＨＡに送信されたＢＵメッセージによって生じるレイテンシ及びシグナリング・オーバヘッドを減らすために開発された。したがって、訪問したネットワーク内にモビリティ・アンカー・ポイント（ＭＡＰ）の階層を導入することによる、ローカル・モビリティ処理が提案される。ＭＮは、ローカルＭＡＰにそのＣｏＡを登録するだけでよい。ＭＡＰのサブネットから追加のＣｏＡ、いわゆる領域ＣｏＡ（ＲＣｏＡ）が取得され、ＭＡＰの領域内でのＭＮの移動性をＨＡ（又はルート最適化の場合はＣＮ）から隠すためにＭＡＰによって使用される。ＨＡ又はＣＮには依然としてＲＣｏＡがわかるため、完全な位置プライバシー・サポートは与えられない。しかし、ＲＣｏＡから導出可能な地理的領域は、実際のＣｏＡから導出可能な領域よりも大きいため、これは、制限付きの位置プライバシー・サポートとみなすことができる。 HMIP (Hesham Soliman, Claud Catcelluccia, Karim El Malki, Ludovic Bellier, “Herarchical Mobile IPv6 mobility management (HMIPv6)”, IETF i. Developed to reduce latency and signaling overhead caused by BU messages sent to the HA (remotely). Therefore, local mobility processing is proposed by introducing a hierarchy of mobility anchor points (MAPs) in the visited network. The MN only needs to register its CoA with the local MAP. An additional CoA, the so-called region CoA (RCoA), is obtained from the MAP subnet and is used by the MAP to hide the mobility of the MN within the MAP region from the HA (or CN for route optimization). Since the HA or CN still knows the RCoA, full location privacy support is not given. However, since the geographical area derivable from RCoA is larger than the area derivable from actual CoA, this can be considered as limited location privacy support.

ＡＲＥＣ（ＷＯ２００４０５５９９３）（Ｇ．Ｋｒｉｓｈｎａｍｕｒｔｈｉ、Ｈ．Ｃｈａｓｋａｒ、Ｒ．Ｓｉｒｅｎ、「ＰｒｏｖｉｄｉｎｇＥｎｄ−ｔｏ−ＥｎｄＬｏｃａｔｉｏｎＰｒｉｖａｃｙｉｎＩＰ−ｂａｓｅｄＭｏｂｉｌｅＣｏｍｍｕｎｉｃａｔｉｏｎ」、ＩＥＥＥＷＣＮＣ、２００４年３月）は、訪問したあらゆるネットワークのあらゆるアクセス・ルータ（ＡＲ）において修正を必要とする。ＣＮ及びＭＮの現在のＡＲに、それぞれバインディング情報が提供されると想定すると、データ・パケットは、ＨＡ、ＣＮ、又はＭＮの関与なしに、両方のＡＲ間でトンネリング可能である。このようにして、ＭＮとＣＮの間で直接、すなわち最短ルートが使用され、位置プライバシーがサポートされる。非常に似た手法が、ＷＯ２００４０１０６６８で提示されている。 AREC (WO 2004055533) (G. Krishnamurthi, H. Chaskar, R. Siren, “Providing End-to-End Location Privacy in IP-based Mobile Communication”, IEEE WCNC, 2004, Visited WCNC, 2004 Requires modification at the access router (AR). Assuming that binding information is provided to the CN and MN's current AR, respectively, data packets can be tunneled between both ARs without the involvement of the HA, CN or MN. In this way, the direct or shortest route is used between the MN and the CN to support location privacy. A very similar approach is presented in WO2004010668.

ＯＲＣ（ＲｙｕｊｉＷａｋｉｋａｗａ、「ＯｐｔｉｍｉｚｅｄＲｏｕｔｅＣａｃｈｅＰｒｏｔｏｃｏｌ（ＯＲＣ）」、ＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｗａｋｉｋａｗａ−ｎｅｍｏ−ｏｒｃ−０１．ｔｘｔ、２００４年１０月）が、モバイル・ネットワーク（ＮＥＭＯ）におけるルート最適化のために開発され、バインディング情報の提供を含む、訪問したネットワークのエッジ・ルータへの修正を必要とする。ＭＮは、ＣＮの現在のネットワーク（ＣＮがモバイルであると想定する）のエッジ・ルータにデータ・パケットをトンネリングし、ＣＮは、ＭＮの現在の訪問したネットワークのエッジ・ルータにデータ・パケットをトンネリングすることができる。エッジ・ルータへのパケットのトンネリングを可能にするために、各ノードは対応するエッジ・ルータのＩＰアドレスを知っている必要があり、これにより、対応するＭＮに関する位置情報が再度明らかにされる。 ORC (Ryuji Wakikawa, “Optimized Route Cache Protocol (ORC)”, Internet Draft draft-wakikawa-nemo-orc-01.txt, October 2004 for development in mobile network (NEMO) And requires modification to the edge routers of the visited network, including providing binding information. MN tunnels data packet to edge router of CN's current network (assuming CN is mobile), CN tunnels data packet to edge router of MN's current visited network can do. In order to allow tunneling of packets to the edge router, each node needs to know the IP address of the corresponding edge router, which again reveals location information about the corresponding MN.

ＧｌｏｂａｌＨＡＨＡ（Ｐ．Ｔｈｕｂｅｒｔ、Ｒ．Ｗａｋｉｋａｗａ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、「ＧｌｏｂａｌＨＡｔｏＨＡｐｒｏｔｏｃｏｌ」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｔｈｕｂｅｒｔ−ｎｅｍｏ−ｇｌｏｂａｌ−ｈａｈａ−００、２００４年１０月）は、複数のＨＡに、異なるトポロジー的位置からのホーム・ネットワーク・プレフィックスへのルートを通知させることにより、通常はホーム・リンクにバインドされたインターネット内のＨＡを分散させる。ＭＮは、プロキシＨＡとして働く最も近いＨＡにバインドすることが可能であり、その結果、最適化されたルートが生じる。双方向トンネリングが使用された場合、位置プライバシーが与えられる。しかし、訪問したあらゆるネットワークが他のすべての（いくつかのＭＮにとってホーム・ネットワークであるすべての）ネットワークへのルートを通知した場合、アドレス階層がそれ以上与えられないため、ルーティング・スケーラビリティの問題が生じる可能性がある。さらに、分散ホーム・ネットワークも同様に手操作で構成しなければならない。セキュアなオンデマンド構成はサポートされない。 Global HAHA (P.Thubert, R. Wakikawa, V. Devapalli, “Global HA to HA protocol”, IETF Internet Draft draft-thumb-a-200 Distributing the HA in the Internet, usually bound to the home link, by letting it know the route from the topological location to the home network prefix. The MN can bind to the closest HA that acts as a proxy HA, resulting in an optimized route. Location privacy is provided when bi-directional tunneling is used. However, if every visited network advertises routes to all other networks (all that are home networks for some MNs), there is no further routing hierarchy, because no more address hierarchies are given. It can happen. In addition, distributed home networks must be configured manually as well. Secure on-demand configuration is not supported.

ＷＯ０３０４１３５８では、あらゆるネットワークに、いわゆる位置プライバシー・エージェント（ＬＰＡ）及び位置プライバシー・サーバ（ＬＰＳ）が導入される。ＭＮは位置プライバシー要求メッセージをそのＬＰＡに送信し、次いでこれがＣＮに近いＬＰＡを選択する。次にこのＬＰＡのアドレスがＭＮに与えられ、次いでこれがＢＵメッセージをこのＬＰＡに送信する。したがって、この手法はＯＲＣ手法と同様であり、ＬＰＡがＣＮのネットワークに近いため、ＣＮの位置がある程度わかり、ＣＮが移動体である場合、位置プライバシー・サポートが中断される。 In WO03031358, a so-called location privacy agent (LPA) and location privacy server (LPS) are introduced in every network. The MN sends a location privacy request message to its LPA, which then selects an LPA that is close to the CN. This LPA's address is then given to the MN, which then sends a BU message to this LPA. Therefore, this approach is similar to the ORC approach, since the LPA is close to the CN's network, the location of the CN is known to some extent, and if the CN is a mobile, location privacy support is interrupted.

ＵＳ２００５０４１６７５及びＷＯ２００４０４３０１０では、ＩＰアドレスの暗号的に修正されたプレフィックスによって位置プライバシーが達成される。プレフィックスは通常、ルータがＩＰパケットをルーティングするために使用するため、この手法はインターネット内のすべてのルータを修正する必要がある。 In US2005041675 and WO2004043010, location privacy is achieved by a cryptographically modified prefix of the IP address. Since prefixes are typically used by routers to route IP packets, this approach requires modification of all routers in the Internet.

ＷＯ０３０４４６２６では、マルチキャスト・アドレスがＣｏＡとして使用される。それらはいかなる位置情報も含まないため、ルート最適化モードでさえも位置プライバシー・サポートが与えられる。しかし、このソリューションは、大規模な配置の結果、インターネットにおいてフラット・ルーティングが生じることになるため、ＭＮの数に応じてスケーリングされない。 In WO03044626, a multicast address is used as CoA. Since they do not contain any location information, location privacy support is provided even in route optimization mode. However, this solution does not scale with the number of MNs because large routing results in flat routing in the Internet.

ＭＮがマルチホームの場合、複数のネットワーク・インターフェース、ＨｏＡ、ＨＡ、及びＣｏＡを有することが可能である。異なるネットワーク・インターフェースにわたる複数のパスが、ＭＮとＣＮの間に存在する可能性がある（図１４を参照のこと）。最適なシステム性能の場合、使用可能なすべてのインターフェース及びパスの中から最良を選択し、ルート最適化通信に使用すべきである。「最良パス」は、例えば、最短パス、又は最小遅延のパスとすることができる。このパスの選択及びセットアップが、解決すべき主要な問題である。使用されるパスに関して決定する単一の中央エンティティが存在しない（ＭＮ及びＣＮは、例えば、異なるローミング協定を有することが可能な、異なる管理ドメインに登録することが可能である）ため、この問題は分散方式で実施しなければならない。 If the MN is multihomed, it can have multiple network interfaces, HoA, HA, and CoA. Multiple paths across different network interfaces may exist between MN and CN (see FIG. 14). For optimal system performance, the best of all available interfaces and paths should be selected and used for route optimized communication. The “best path” can be, for example, the shortest path or the path with the minimum delay. This path selection and setup is the main problem to be solved. Since there is no single central entity to decide on the path to be used (MNs and CNs can register with different administrative domains, for example, which can have different roaming agreements) Must be implemented in a distributed manner.

ネットワーク内の２つのノード間の複数のパスの中から最良を見つけることは、ネットワーキングにおける古典的な問題としてみなすことができる。ＲＩＰ（ルーティング情報プロトコル）又はＯＳＰＦ（ＯｐｅｎＳｈｏｒｔｅｓｔＰａｔｈＦｉｒｓｔ）などの分散ルーティング・プロトコルは、インターネットのドメイン内で最短パスを見つけるために使用される。しかし、それらのプロトコルは、以下のいくつかの理由により、開発中のシステムに適用することができない。
・ネットワークは、ネットワーク・ノードがモバイルＩＰｖ６であり、ＨＡ及びホストがマルチホーム・モバイルＩＰｖ６ＭＮである、オーバレイ・ネットワークである
・リンクはマルチホップ（すなわちオーバレイ）リンクである
・リンクのコストは部分的に未知である
・位置プライバシーを保持するために、ＣＮ及びＭＮには、他のＭＮまでの距離及び（トポロジー的に正しい）そのアドレスがわかってはならない
・このソリューションは、効率的であり、ＯＲＴ及びモバイルＩＰｖ６プロトコルと互換性があるものとする。これは、これらのプロトコルに対してわずかな変更のみが行われるものであることを示唆する。 Finding the best among multiple paths between two nodes in a network can be viewed as a classic problem in networking. Distributed routing protocols such as RIP (Routing Information Protocol) or OSPF (Open Shortest Path First) are used to find the shortest path in the Internet domain. However, those protocols cannot be applied to systems under development for several reasons:
The network is an overlay network where the network node is Mobile IPv6 and the HA and host are multihomed Mobile IPv6 MNs. The link is a multi-hop (ie overlay) link. The cost of the link is partial. In order to preserve location privacy, CNs and MNs must not know the distance to other MNs and their (topologically correct) addresses. This solution is efficient and ORT And compatible with the Mobile IPv6 protocol. This suggests that only minor changes are made to these protocols.

考察する他の問題は、ホーム・リンクが分散可能であること、すなわち、異なるリンク上の複数のＨＡが同じマルチホーム・ホストに関するバインディングを管理することであり、このバインディングは同じＨｏＡを有するが、ＣｏＡは異なる。これはモバイルＩＰｖ６（ＭＩＰｖ６）によってサポートされないが、このケースをサポートする（ＨＡＨＡ）などの拡張が存在する。
ＷＯ０３０４１３５８ＷＯ２００４０１０６６８ＵＳ２００５０４１６７５ＷＯ２００４０５５９９３ＷＯ２００４０４３０１０ＷＯ０３０４４６２６Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、「ＭｏｂｉｌｉｔｙＳｕｐｐｏｒｔｉｎＩＰｖ６」、ＩＥＴＦＲＦＣ３７７５、２００４年６月ＨｅｓｈａｍＳｏｌｉｍａｎ、ＣｌａｕｄｅＣａｔｅｌｌｕｃｃｉａ、ＫａｒｉｍＥｌＭａｌｋｉ、ＬｕｄｏｖｉｃＢｅｌｌｉｅｒ、「ＨｉｅｒａｒｃｈｉｃａｌＭｏｂｉｌｅＩＰｖ６ｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔ（ＨＭＩＰｖ６）」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔｉｅｔｆ−ｍｉｐｓｈｏｐ−ｈｍｉｐｖ６−０４．ｔｘｔ、２００４年１２月Ｇ．Ｋｒｉｓｈｎａｍｕｒｔｈｉ、Ｈ．Ｃｈａｓｋａｒ、Ｒ．Ｓｉｒｅｎ、「ＰｒｏｖｉｄｉｎｇＥｎｄ−ｔｏ−ＥｎｄＬｏｃａｔｉｏｎＰｒｉｖａｃｙｉｎＩＰ−ｂａｓｅｄＭｏｂｉｌｅＣｏｍｍｕｎｉｃａｔｉｏｎ」、ＩＥＥＥＷＣＮＣ、２００４年３月ＲｙｕｊｉＷａｋｉｋａｗａ、「ＯｐｔｉｍｉｚｅｄＲｏｕｔｅＣａｃｈｅＰｒｏｔｏｃｏｌ（ＯＲＣ）」、ＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｗａｋｉｋａｗａ−ｎｅｍｏ−ｏｒｃ−０１．ｔｘｔ、２００４年１０月Ｐ．Ｔｈｕｂｅｒｔ、Ｒ．Ｗａｋｉｋａｗａ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、「ＧｌｏｂａｌＨＡｔｏＨＡｐｒｏｔｏｃｏｌ」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｔｈｕｂｅｒｔ−ｎｅｍｏ−ｇｌｏｂａｌ−ｈａｈａ−００、２００４年１０月Ａｕｒａ，Ｔ．、「ＣｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙＧｅｎｅｒａｔｅｄＡｄｄｒｅｓｓｅｓ（ＣＧＡ）」、Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｃｇａ−０６、２００４年４月Ｊ．Ａｒｋｋｏ、Ｊ．Ｋｅｍｐｆ、Ｂ．Ｓｏｍｍｅｒｆｅｌｄ、Ｂ．Ｚｉｌｌ、Ｐ．Ｎｉｋａｎｄｅｒ、「ＳＥｃｕｒｅＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙ（ＳＥＮＤ）」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｎｄｏｐｔ−０６、２００４年７月Ｍ．Ｌｉｅｂｓｃｈ、Ａ．Ｓｉｎｇｈ、Ｈ．Ｃｈａｓｋａｒ、Ｄ．Ｆｕｎａｔｏ、Ｅ．Ｓｈｉｍ、「ＣａｎｄｉｄａｔｅＡｃｃｅｓｓＲｏｕｔｅｒＤｉｓｃｏｖｅｒｙ」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｉｅｔｆ−ｓｅａｍｏｂｙ−ｃａｒｄ−ｐｒｏｔｏｃｏｌ−０８．ｔｘｔ、２００４年９月Ｎｉｋａｎｄｅｒ，Ｐ．、「ＭｏｂｉｌｅＩＰｖｅｒｓｉｏｎ６ＲｏｕｔｅＯｐｔｉｍｉｚａｔｉｏｎＳｅｃｕｒｉｔｙＤｅｓｉｇｎＢａｃｋｇｒｏｕｎｄ」、２００４年１０月 Another issue to consider is that the home links are distributable, ie multiple HAs on different links manage bindings for the same multihomed host, which bindings have the same HoA, CoA is different. This is not supported by Mobile IPv6 (MIPv6), but there are extensions such as (HAHA) that support this case.
WO03041358 WO2004010668 US2005041675 WO2004055993 WO2004043010 WO03044626 D. Johnson, C.I. Perkins, J.M. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004 Hesham Soliman, Claud Cataluccicia, Karim El Maker, Ludobi Bellier, “Herarchical Mobile IPv6 mobility management (HMIPv6)”, IETF Internet. txt, December 2004 G. Krishnamurthi, H .; Chaskar, R.A. Siren, “Providing End-to-End Location Privacy in IP-based Mobile Communication”, IEEE WCNC, March 2004 Ryuji Wakikawa, “Optimized Route Cache Protocol (ORC)”, Internet Draft draft-wakikawa-nemo-orc-01. txt, October 2004 P. Thubert, R.A. Wakikawa, V.A. Devapalli, “Global HA to HA protocol”, IETF Internet Draft draft-hubert-nemo-global-haha-00, October 2004. Aura, T .; , “Cryptographically Generated Addresses (CGA)”, Internet-Draft draft-ietf-send-cga-06, April 2004. J. et al. Arkko, J. et al. Kempf, B.M. Somerfeld, B.M. Zill, P.A. Nikander, “SECure Neighbor Discovery (SEND)”, IETF Internet Draft draft-ietf-send-ndopt-06, July 2004 M.M. Liebsch, A.M. Singh, H .; Chaskar, D.C. Funato, E .; Shim, “Candidate Access Router Discovery”, IETF Internet Draft draft-ietf-samoby-card-protocol-08. txt, September 2004 Nikander, P.A. , "Mobile IP version 6 Route Optimization Security Design Background", October 2004

本発明の目的は、訪問したあらゆるネットワークにおいて新しいか又は修正されたインフラストラクチャ構成要素の導入を必要とすることなく、モバイルＩＰｖ６などのパケット交換プロトコルに対して位置プライバシー及びルート最適化を提供することである。このソリューションは、両方の通信パートナが移動体である場合にも機能するものとし、配置、すなわちこのソリューションを使用するＭＮの数に関してスケーラブルであるものとする。また、標準のモバイルＩＰｖ６と同じレベルのセキュリティも提供し、マルチホーム端末に適用可能であるものとする。 The object of the present invention is to provide location privacy and route optimization for packet switched protocols such as Mobile IPv6 without requiring the introduction of new or modified infrastructure components in every visited network. It is. This solution shall also work when both communication partners are mobile and shall be scalable with respect to deployment, ie the number of MNs using this solution. It is also assumed that the same level of security as that of standard mobile IPv6 is provided, and that it can be applied to multi-home terminals.

これらの目的は、独立請求項の主題によって解決される。本発明の有利な実施形態は、従属請求項に対する主題である。 These objects are solved by the subject matter of the independent claims. Advantageous embodiments of the invention are the subject matter for the dependent claims.

これらの目的を達成するために、本発明は、複数のモバイル・ネットワークを備える移動通信システムにおいて、マルチホーム・移動ノードと通信相手ノードとの間でのパケット交換データ伝送のための方法、システム、装置、及びコンピュータ読み取り可能媒体を提供する。移動ノードは、そのホーム・アドレスの中から通信相手ノードと通信するために使用される１つを選択し、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録する。通信相手ノードのホーム・エージェント及び移動ノードのホーム・エージェントは、候補となるプロキシ・ホーム・エージェント・アドレスを受信し、格納する。通信相手ノードのホーム・エージェントは、通信相手ノードに要求を送信する。通信相手ノードは、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、通信相手ノードのホーム・エージェントに、気付アドレスとして登録する。次に移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントは、格納されたプロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択する。トンネルの２つのエンド・ポイントが、選択されたプロキシ・ホーム・エージェント・アドレス及び選択された移動ノードの気付アドレスのうちの１つであるように、移動ノードのホーム・エージェントは、トンネルを切り替えるために移動ノードをトリガする。トンネルの２つのエンド・ポイントが、選択されたプロキシ・ホーム・エージェント・アドレス及び選択された移動ノードの気付アドレスのうちの１つとなるように、通信相手ノードのホーム・エージェントは、トンネルを切り替えるために通信相手ノードをトリガする。 To achieve these objectives, the present invention provides a method, system, and method for packet-switched data transmission between a multi-homed mobile node and a correspondent node in a mobile communication system comprising a plurality of mobile networks. An apparatus and a computer readable medium are provided. The mobile node selects one of its home addresses used to communicate with the correspondent node, and selects at least one of a plurality of addresses assigned to the target network interface. Register as a care-of address with the home agent of the mobile node that is responsible for the given home address. The home agent of the correspondent node and the home agent of the mobile node receive and store candidate proxy home agent addresses. The home agent of the correspondent node sends a request to the correspondent node. The correspondent node registers at least one of a plurality of addresses assigned to the target network interface as a care-of address in the home agent of the correspondent node. Next, the home agent of the mobile node and the home agent of the correspondent node are at least one of the stored proxy home agent addresses, one of the care-of addresses of the mobile node, and the correspondent node Select one of the care-of addresses. The mobile node's home agent switches the tunnel so that the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the selected mobile node. Trigger the mobile node to The home agent of the correspondent node switches the tunnel so that the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the selected mobile node. Trigger the correspondent node.

有利な実施形態では、要求は最適化リバース・トンネリング開始要求である。 In an advantageous embodiment, the request is an optimized reverse tunneling start request.

他の実施形態では、移動ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップと、通信相手ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップとが、通信相手ノードが、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、通信相手ノードのホーム・エージェントに、気付アドレスとして登録する前に、実行される。 In another embodiment, the address of the candidate proxy home agent stored at the mobile node is transmitted to the home agent of the mobile node and the home agent of the correspondent node; and stored at the correspondent node. Transmitting the address of the proxy home agent as a candidate to the home agent of the mobile node and the home agent of the correspondent node, and the correspondent node is assigned to the target network interface. This is executed before registering at least one of the addresses as a care-of address with the home agent of the correspondent node.

有利な実施形態では、移動ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを含む最適化リバース・トンネリング開始要求を、移動ノードによって、そのホーム・エージェントに送信するステップと、最適化リバース・トンネリング開始要求を移動ノードのホーム・エージェントによって受信し、新しい候補となるプロキシ・ホーム・エージェント・アドレスを格納するステップと、通信相手ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを、移動ノードのホーム・エージェントによって見つけるステップと、移動ノードのホーム・エージェントによって、最適化リバース・トンネリング要求を見つけられた通信相手ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスを通信相手ノードのホーム・エージェントに提案するステップとを含む。 In an advantageous embodiment, the step of sending the address of the candidate proxy home agent stored at the mobile node to the home agent of the mobile node and the home agent of the correspondent node is a candidate proxy home. Sending an optimized reverse tunneling start request including the agent's address by the mobile node to its home agent; and receiving an optimized reverse tunneling start request by the mobile node's home agent A proxy home agent address of the mobile node, a home agent of the mobile node that finds a home agent that manages the binding for the home address of the correspondent node, The node's home agent sends an optimized reverse tunneling request to the partner node's home agent where it was found, and proposes a candidate proxy home agent address to the node's home agent. Including.

他の有利な実施形態では、通信相手ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを含む最適化リバース・トンネリング開始応答を、通信相手ノードによって、そのホーム・エージェントに送信するステップと、最適化リバース・トンネリング開始応答を通信相手ノードのホーム・エージェントによって受信し、候補となるプロキシ・ホーム・エージェント・アドレスを格納するステップと、通信相手ノードのホーム・エージェントによって、最適化リバース・トンネリング応答を移動ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスを移動ノードのホーム・エージェントに提案するステップとを含む。 In another advantageous embodiment, the step of sending the address of the candidate proxy home agent stored at the correspondent node to the home agent of the mobile node and the home agent of the correspondent node is a candidate. Sending an optimized reverse tunneling start response containing the address of the proxy home agent to its home agent by the correspondent node and receiving an optimized reverse tunneling start response by the correspondent node home agent The candidate proxy home agent address is stored, and the home node of the correspondent node sends an optimized reverse tunneling response to the home agent of the mobile node. And a step of proposing a home agent address to the home agent of the mobile node.

前述の実施形態の変形形態では、移動ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードによって、そのホーム・エージェントに送信するステップと、移動ノードのホーム・エージェントによって、候補となるプロキシ・ホーム・エージェント・アドレスを受信及び格納するステップと、通信相手ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを、移動ノードによって見つけるステップと、移動ノードによって、最適化リバース・トンネリング要求を見つけられた通信相手ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスを通信相手ノードのホーム・エージェントに提案するステップとを含む。 In a variation of the previous embodiment, the step of sending the address of the candidate proxy home agent stored at the mobile node to the home agent of the mobile node and the home agent of the correspondent node is a candidate. Sending a proxy home agent address by the mobile node to the home agent; receiving and storing a candidate proxy home agent address by the mobile node home agent; and The step of finding the home agent that manages the binding related to the home address of the partner node by the mobile node, and the home agent of the correspondent node that has found the optimized reverse tunneling request by the mobile node Sent to preparative, and a step of proposing a proxy home agent addresses that are candidates to the home agent of the correspondent node.

他の有利な実施形態では、通信相手ノードで格納された候補となるプロキシ・ホーム・エージェントのアドレスを、移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントに送信するステップは、候補となるプロキシ・ホーム・エージェントのアドレスを、通信相手ノードによって、そのホーム・エージェントに送信するステップと、通信相手ノードのホーム・エージェントによって、候補となるプロキシ・ホーム・エージェント・アドレスを受信及び格納するステップと、移動ノードのホーム・アドレスに関するバインディングを管理するホーム・エージェントを、通信相手ノードによって見つけるステップと、通信相手ノードによって、最適化リバース・トンネリング応答を移動ノードのホーム・エージェントに送信し、候補となるプロキシ・ホーム・エージェント・アドレスとして周知のホーム・エージェントを、移動ノードのホーム・エージェントに提案するステップとを含む。 In another advantageous embodiment, the step of sending the address of the candidate proxy home agent stored at the correspondent node to the home agent of the mobile node and the home agent of the correspondent node is a candidate. Transmitting the address of the proxy home agent by the correspondent node to the home agent; receiving and storing candidate proxy home agent addresses by the home agent of the correspondent node; , Finding a home agent that manages the binding for the mobile node's home address by the correspondent node, and the correspondent node to send an optimized reverse tunneling response to the mobile node's home agent. And Shin, comprising the steps of a known home agent as a proxy home agent addresses that are candidates to propose a home agent of the mobile node.

本発明の他の有利な実施形態では、格納されたプロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントの両方での通信相手ノードの気付アドレスのうちの１つを選択するステップが、最短パスを見つけるために実行される。 In another advantageous embodiment of the invention, at least one of the stored proxy home agent addresses, one of the mobile node's care-of address, and the mobile node's home agent and correspondent node The step of selecting one of the care-of addresses of correspondent nodes at both of the home agents is performed to find the shortest path.

上記に関する変形形態では、格納されたプロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び移動ノードのホーム・エージェント及び通信相手ノードのホーム・エージェントの両方での通信相手ノードの気付アドレスのうちの１つを選択するステップが、最小遅延のパスを選択するために実行される。 In a variation on the above, at least one of the stored proxy home agent addresses, one of the mobile node's care-of address, and the home agent of the mobile node and the home agent of the correspondent node. The step of selecting one of the care-of addresses of the correspondent nodes at both is performed to select the path with the least delay.

他の有利な実施形態では、通信相手ノードのホーム・アドレスのうちの１つが、通信相手ノードのホーム・エージェントが通信相手ノードに要求を送信する前に選択される。 In another advantageous embodiment, one of the correspondent node's home addresses is selected before the correspondent node's home agent sends a request to the correspondent node.

他の有利な実施形態では、移動ノードのホーム・エージェントが、信頼できないプロキシ・ホーム・エージェントを拒否する。 In another advantageous embodiment, the mobile node's home agent rejects untrusted proxy home agents.

他の有利な実施形態では、通信相手ノードのホーム・エージェントが、信頼できないプロキシ・ホーム・エージェントを拒否する。 In another advantageous embodiment, the correspondent node's home agent rejects untrusted proxy home agents.

本発明の他の実施形態は、通信相手ノードと通信するために使用されるホーム・アドレスのうちの１つを選択するように適合された選択手段と、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、選択されたホーム・アドレスに対して責務を負う移動ノードのホーム・エージェントに、気付アドレスとして登録するように適合された格納手段とを備える移動ノードに関する。 Another embodiment of the invention is assigned to a selection means adapted to select one of the home addresses used for communicating with the correspondent node and to the target network interface. A mobile node comprising storage means adapted to register at least one of a plurality of addresses as a care-of address with a home agent of a mobile node responsible for a selected home address.

本発明の他の実施形態は、開始要求を通信相手ノードに送信するように適合された伝送手段と、プロキシ候補となるホーム・エージェント・アドレスを受信するように適合された受信手段と、プロキシ候補となるホーム・エージェント・アドレスを格納するように適合された格納手段と、プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するように適合された選択手段と、トンネルの２つのエンド・ポイントが選択されたプロキシ・ホーム・エージェント・アドレス及び通信相手ノードの気付アドレスのうちの１つであるように、トンネルを切り替えるために通信相手ノードをトリガするように適合されたトリガ手段とを備える通信相手ノードのホーム・エージェントに関する。 Another embodiment of the invention comprises a transmission means adapted to send a start request to a correspondent node, a receiving means adapted to receive a home agent address that is a proxy candidate, and a proxy candidate Storage means adapted to store the home agent address to be, at least one of the proxy home agent address, one of the mobile node's care-of address, and the correspondent node's care-of The selection means adapted to select one of the addresses, and the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the correspondent node Trigger means adapted to trigger the correspondent node to switch tunnels About the home agent of the correspondent node to obtain.

本発明の他の実施形態は、対象とするネットワーク・インターフェースに割り当てられた複数のアドレスのうちの少なくとも１つを、通信相手ノードのホーム・エージェントに、気付アドレスとして登録するように適合された格納手段を備える通信相手ノードに関する。 Another embodiment of the present invention is a storage adapted to register at least one of a plurality of addresses assigned to a target network interface with a home agent of a correspondent node as a care-of address. The present invention relates to a communication partner node having means.

本発明の他の実施形態は、プロキシ・ホーム・エージェント・アドレスのうちの少なくとも１つ、移動ノードの気付アドレスのうちの１つ、及び通信相手ノードの気付アドレスのうちの１つを選択するように適合された選択手段と、トンネルの２つのエンド・ポイントが選択されたプロキシ・ホーム・エージェント・アドレス及び通信相手ノードの気付アドレスのうちの１つであるように、トンネルを切り替えるために移動ノードをトリガするように適合されたトリガ手段とを備える移動ノードのホーム・エージェントに関する。 Another embodiment of the invention selects at least one of the proxy home agent address, one of the mobile node's care-of address, and one of the correspondent nodes' care-of address. And a mobile node to switch the tunnel so that the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the correspondent node. A mobile node home agent comprising trigger means adapted to trigger

他の有利な実施形態では、移動ノード、通信相手ノードのホーム・エージェント、通信相手ノード、及び移動ノードのホーム・エージェントが、命令を格納したコンピュータ読み取り可能媒体を備える。 In another advantageous embodiment, the mobile node, the correspondent node's home agent, the correspondent node, and the mobile node's home agent comprise a computer readable medium having instructions stored thereon.

添付の図面は、本発明の原理を説明するために本明細書に組み込まれ、その一部を形成する。この図面は、本発明がどのように作成及び使用できるかについて図示及び説明された例に本発明を限定するものと解釈されるべきではない。添付の図面に示された他の特徴及び利点は、本発明の以下のさらに特定の説明から明らかとなるだろう。 The accompanying drawings are incorporated into and form a part of the specification to illustrate the principles of the invention. This drawing should not be construed to limit the invention to the examples shown and described as to how the invention can be made and used. Other features and advantages illustrated in the accompanying drawings will become apparent from the following more specific description of the invention.

本発明の例示的実施形態について図面を参照しながら説明するが、この図面では、類似の要素及び構造は類似の参照番号で示されている。 Exemplary embodiments of the invention are described with reference to the drawings, in which like elements and structures are indicated with like reference numerals.

最適化リバース・トンネリング（ＯＲＴ）は、第１に、ＭＮ及びＣＮのプライバシー並びにルート最適化の要件をネゴシエートするために、ＭＮ又はＭＮのＨＡとＣＮ又はＣＮのＨＡとの間にいくつかの初期シグナリングを必要とする。このシグナリング及び追加の距離情報に基づいて、候補となるシナリオ及びそれに続く候補となるプロキシＨＡが決定される。個々の候補となるプロキシＨＡを介するルート長さが決定された後、プロキシＨＡトンネルが切り替えられるかどうか、及びどのプロキシＨＡトンネルに切り替えられるかが決定される。その後バインディング情報が送信され、トンネルは選択されたターゲット・プロキシＨＡに切り替えられる。移動性によりルート長さは動的であり、プロセスは特定の時間的インスタンスで繰り返さなければならない。 Optimized reverse tunneling (ORT), first, involves several initial steps between MN or MN HA and CN or CN HA to negotiate MN and CN privacy and route optimization requirements. Requires signaling. Based on this signaling and additional distance information, candidate scenarios and subsequent candidate proxy HAs are determined. After the route length through each candidate proxy HA is determined, it is determined whether the proxy HA tunnel is switched and which proxy HA tunnel is switched to. Binding information is then sent and the tunnel is switched to the selected target proxy HA. Due to mobility, the route length is dynamic and the process must be repeated at specific temporal instances.

以下では、個々のプロシージャ、すなわち要求条件及び候補となるシナリオのネゴシエーション、候補となるプロキシＨＡの発見、距離情報／ルート長さに基づくターゲット・プロキシＨＡの決定、ターゲット・プロキシＨＡにおけるバインディング情報のセキュアな確立、並びに、トンネルの切り替えについて説明する。プロシージャは、ＭＮ制御又はＨＡ制御のいずれかで実現することができる。最後に、移動性が存在する場合にどのようにルートを適合できるかについて説明する。 In the following, individual procedures, ie negotiation of requirements and candidate scenarios, discovery of candidate proxy HAs, determination of target proxy HA based on distance information / route length, secure binding information in target proxy HA Establishment and tunnel switching will be described. The procedure can be realized by either MN control or HA control. Finally, how the route can be adapted when mobility exists is described.

ＣＮが移動体であるか、又はＣＮがたとえホームにある場合であってもＯＲＴをサポートするためにＨＡに登録するかのいずれかによって、ＨＡがＣＮに割り当てられることが想定される。そうでない場合、初期ネゴシエーション段階でＯＲＴは拒否される。 It is assumed that the HA is assigned to the CN either by the CN being mobile or by registering with the HA to support ORT even if the CN is at home. Otherwise, the ORT is rejected during the initial negotiation phase.

要件及び候補となるシナリオのネゴシエーション
開始のシナリオは、常に双方向トンネリング・モードの標準モバイルＩＰである。図１及び図４は、どちらも外部ネットワーク１０７及び１０８内にあるＭＮ１０１とＣＮ１０２との間の、このモードでのデータ・パスを示す。ＭＮは、そのＨＡ１０３へのＣＮのＨｏＡにアドレス指定されたすべてのデータ・パケットをリバース・トンネリングし、それらをデカプセル化及び転送する。ルーティング・インフラストラクチャは、パケットをＣＮのホーム・ネットワーク１０６にルーティングし、そこでＣＮのＨＡ（ＣＨＡ）１０４がそれらをインターセプトし、ＣＮのＣｏＡへとトンネリングする。他方向のデータ・パケットは、それに応じて処理される。 Negotiation of requirements and candidate scenarios The starting scenario is always standard Mobile IP in bidirectional tunneling mode. FIGS. 1 and 4 show the data path in this mode between the MN 101 and the CN 102, both in the external networks 107 and 108. FIG. The MN reverse tunnels all data packets addressed to CN's HoA to its HA 103 and decapsulates and forwards them. The routing infrastructure routes the packets to CN's home network 106 where CN's HA (CHA) 104 intercepts them and tunnels to CN's CoA. Data packets in the other direction are processed accordingly.

図１及び図４は、それぞれのネットワーク間の異なる距離に対して同じルーティング構成を示す。図１では、ＭＮの訪問ネットワーク１０７からそのホーム・ネットワーク１０５の方が、ＣＮの訪問ネットワーク１０８からＣＮのホーム・ネットワーク１０６よりも近い。図４では、ＭＮ及びＣＮのどちらも、それぞれのホーム・ネットワークまでよりも、相互間の方が近い。さらに、訪問ネットワークは、特別な場合にホーム・ネットワークと同一である可能性があることにも留意されたい。１つのＭＮについてこれが当てはまる場合、図１に示されたような状況になる。ＭＮ及びＣＮがどちらもそれぞれのホーム・ネットワークにある場合、ＯＲＴは従来のモバイルＩＰルーティングよりも短いルーティングを提供することができない。しかし、位置プライバシーの目的で、少なくともＭＮ及びＣＮの見地から、全体のルーティング・プロシージャはすべてのケースで同一でなければならない。 1 and 4 show the same routing configuration for different distances between the respective networks. In FIG. 1, the home network 105 from the MN visit network 107 is closer than the CN visit network 108 to the CN home network 106. In FIG. 4, both MN and CN are closer to each other than to their home networks. It should also be noted that the visited network may be identical to the home network in special cases. If this is the case for one MN, the situation is as shown in FIG. If both MN and CN are in their home networks, ORT cannot provide shorter routing than traditional Mobile IP routing. However, for location privacy purposes, at least from the MN and CN perspective, the entire routing procedure must be the same in all cases.

ＭＮ又はＨＡがＯＲＴを要求する場合、プロセスは、ルート最適化及びプライバシー要件のネゴシエーションで開始される。前者は、例えば、ホップにおける最大ルート長さを指定することが可能であり、後者はプライバシーが必要であるかどうか及びどの種類のプライバシーが必要であるかを指定することができる（ＭＮの位置をＣＮ又は盗聴者に隠すか、あるいは位置追跡を防ぐ）。この情報及び追加の距離情報に基づいて、ＣＮ及びＭＮのオリジナルＨＡは、ルート最適化のための候補となるシナリオを選択する。全体としての概念をこれらのシナリオに制限するわけではないが、次に、異なるプロキシＨＡ位置の以下のシナリオについて考察する。
ａ）それぞれＭＮ１０１及びＣＮ１０２のホーム・ネットワーク１０５及び１０６内に配置された２つの単方向トンネリング・プロキシＨＡ１０３及び１０４（図２を参照のこと）
ｂ）それぞれＭＮ１０１又はＣＮ１０２のホーム・ネットワーク１０５又は１０６内に配置された１つの双方向トンネリング・プロキシＨＡ１０３又は１０４（図３を参照のこと）
ｃ）それぞれＭＮ１０１及びＣＮ１０２の現在の訪問ネットワーク１０７及び１０８に配置された２つの双方向トンネリング・プロキシＨＡ５０１及び５０２（図５を参照のこと）
ｄ）それぞれＭＮ１０１又はＣＮ１０２の現在の訪問ネットワーク１０７又は１０８内の１つの共通双方向トンネリング・プロキシＨＡ６０１（図６を参照のこと）
ｅ）ＭＮ１０１とＣＮ１０２の間のネットワーク７０２内の１つの共通双方向トンネリング・プロキシＨＡ７０１（図７を参照のこと） If the MN or HA requests an ORT, the process begins with route optimization and negotiation of privacy requirements. The former can, for example, specify the maximum route length in hops, and the latter can specify whether privacy is required and what kind of privacy is required (the location of the MN). Hide to CN or eavesdropper or prevent location tracking). Based on this information and the additional distance information, the CN and MN's original HA selects a scenario that is a candidate for route optimization. Without limiting the overall concept to these scenarios, consider the following scenarios for different proxy HA locations:
a) Two unidirectional tunneling proxies HA 103 and 104 located in the home networks 105 and 106 of the MN 101 and CN 102, respectively (see FIG. 2)
b) One bidirectional tunneling proxy HA 103 or 104 (see FIG. 3) located in the home network 105 or 106 of the MN 101 or CN 102, respectively.
c) Two bi-directional tunneling proxies HA 501 and 502 (see FIG. 5) located in the current visited networks 107 and 108 of MN 101 and CN 102, respectively.
d) One common bidirectional tunneling proxy HA 601 in the current visited network 107 or 108 of the MN 101 or CN 102, respectively (see FIG. 6)
e) One common bidirectional tunneling proxy HA 701 in the network 702 between the MN 101 and the CN 102 (see FIG. 7)

シナリオａ）及びｂ）は、図１に示されるような距離状況において最も有利に適用可能である。図４に示されたような状況では、シナリオｃ）、ｄ）、及びｅ）がより短いルートにつながる可能性がある。 Scenarios a) and b) are most advantageously applicable in distance situations as shown in FIG. In the situation as shown in FIG. 4, scenarios c), d), and e) may lead to shorter routes.

候補となるシナリオの順序付けられたリストは、距離情報及び他の情報に基づいて構築することができる。以下の原理を使用して、ターゲット・シナリオを選択することが可能である。シナリオａ）及びｂ）は、ＭＮ及びＣＮの両方がホームから遠い場合、最適なルート長さが達成できない場合がある。シナリオａ）及びｂ）が望ましいルート最適化の程度を達成しない場合、シナリオｃ）及びｄ）を考慮の対象とすることができる。しかし、それらは、訪問ネットワークがこのソリューションをサポートしている場合にのみ使用可能である。シナリオｄ）は、ノードのうちの一方（そのネットワーク内に共通プロキシが配置されているノード）が、他方のノードには、受信したトンネリングされたパケットからこのネットワークのプレフィックスがわかることから、プライバシー要件を有さない場合にのみ使用可能である。シナリオｅ）は、両方の訪問ネットワークがＯＲＴをサポートしておらず、ＭＮ及びＣＮの両方がプライバシー要件を有する場合にのみ使用可能である。しかし、問題は、プロキシＨＡを提供することが可能な訪問ネットワーク間のネットワークを決定することである。 An ordered list of candidate scenarios can be constructed based on distance information and other information. The following principle can be used to select a target scenario. Scenarios a) and b) may not achieve optimal route length if both MN and CN are far from home. If scenarios a) and b) do not achieve the desired degree of route optimization, scenarios c) and d) can be considered. However, they can only be used if the visiting network supports this solution. Scenario d) is a privacy requirement because one of the nodes (a node with a common proxy in the network) knows the prefix of this network from the tunneled packet received by the other node. It can be used only when it does not have. Scenario e) can only be used if both visiting networks do not support ORT and both MN and CN have privacy requirements. However, the problem is to determine the network between visited networks that can provide a proxy HA.

シナリオｂ）、ｄ）、及びｅ）は、それぞれのシナリオが現在アクティブであることをＭＮ及びＣＮが知っている場合、完全な位置プライバシーを達成できない場合があることに留意されたい。例えば、図３では、ＣＮ１０２はＭＮ１０１に関する何らかの位置情報を有し、ＣＮは、ＭＮのＨＡ１０３を介するパスがＣＮのＨＡ１０４を介するパスよりも短くなければならないことを知っており、さらにＭＮのＨＡ及びＣＮのＨＡまでの距離を知っている。それ故、ＭＮがＭＮのＨＡ又はＣＮのＨＡのいずれに近いかを結論付けることができる。解決策としては、ＭＮ及びＣＮの両方がどのシナリオが現在アクティブであるかを知ってはならないか、又はパス上の追加のプロキシＨＡを中継として使用しなければならないかのいずれかである。 Note that scenarios b), d), and e) may not achieve full location privacy if the MN and CN know that the respective scenario is currently active. For example, in FIG. 3, CN 102 has some location information about MN 101, and CN knows that the path through MN's HA 103 must be shorter than the path through CN's HA 104, and MN's HA and Know the distance of CN to HA. It can therefore be concluded whether the MN is closer to the MN's HA or the CN's HA. The solution is either that both the MN and the CN must not know which scenario is currently active, or an additional proxy HA on the path must be used as a relay.

ＨＭＩＰをサポートするネットワーク内のモビリティ・アンカー・ポイント（ＭＡＰ）は、プロキシＨＡを同一場所に設置できることにも留意されたい。 Note also that a mobility anchor point (MAP) in a network that supports HMIP can place a proxy HA in the same location.

ＨＡ制御及びＭＮ制御の変形例における初期ネゴシエーションの例が、それぞれ図８及び図９に示されている。 Examples of initial negotiation in the modified examples of HA control and MN control are shown in FIGS. 8 and 9, respectively.

どちらの場合も、各移動ノードとそのＨＡとの間にすでにセキュリティ関係８０１、８０２が存在している。 In either case, security relationships 801 and 802 already exist between each mobile node and its HA.

図８に示されたＨＡ制御の変形例では、ＭＮ１０１はオプションでＯＲＴ初期化要求８０３をそのＨＡに送信することができる。この要求は、ＭＮ及びＣＮのホーム・アドレスを備える。その後、ＭＮのＨＡ１０３は、ＭＮのプライバシー及びルート最適化（すなわち最大ルート長さ）要件を伴う両方の移動ノードのホーム・アドレスと、ＩＰアドレスなどのＭＮのＨＡの識別子と、そのネットワーク内でＨＡとして動作することが許可されていることを証明するための許可証明とを備える署名付きＯＲＴ要求８０４をＣＮのＨＡ１０４に送信する。この要求を受信すると、ＣＮのＨＡ１０４はオプションで、ＯＲＴ初期化要求８０５をＣＮ１０２に送信し、状況コードを含むＯＲＴ初期化応答８０６をＣＮ１０２から受信する。次にＣＮのＨＡ１０４は、要求８０４に対するＯＲＴ応答８０７を、ＭＮのＨＡ１０３に返送する。この応答も署名付きであり、ＣＮのＨＡ１０４の識別子及び許可証明と共に、ＣＮのプライバシー及びルート最適化要件を備える。ＭＮがＯＲＴ初期化要求８０３を送信した場合、次に状況コードを含む応答８０８をそのＨＡ１０３から受信する。ＨＡ１０３と１０４両方の間にセキュリティ関係８１０が存在しない場合、例えば、インターネット鍵交換（ＩＫＥ）並びに両方のエンティティの秘密鍵及び公開鍵を使用して、ステップ８０９で確立される。ステップ８１１における両方のＨＡの間でのバインディング・アップデート情報の保全性保護交換には、何らかの種類のセキュリティ関係１１０が必要である。これは、ＢＵメッセージに、対応する公開鍵で直接署名することによっても達成可能である。次に、各ＨＡ１０３、１０４はステップ８１２及び８１３で、それぞれの他方のＨＡまでの距離、並びにＭＮ１０１及びＣＮ１０２の両方までの距離を決定し、ステップ８１４及び８１５で、その結果をそれぞれ他方のＨＡに報告する。この情報は、ステップ８１６でＨＡの候補となるシナリオを決定するために使用される。 In the HA control variant shown in FIG. 8, the MN 101 can optionally send an ORT initialization request 803 to the HA. This request comprises the home address of the MN and CN. The MN's HA 103 then sends both the mobile node's home address with the MN's privacy and route optimization (ie, maximum route length) requirements, the MN's HA identifier, such as an IP address, and the HA in its network. To the CN's HA 104 with a signed ORT request 804 with authorization credentials to prove that it is authorized to act as CN. Upon receiving this request, CN's HA 104 optionally sends an ORT initialization request 805 to CN 102 and receives an ORT initialization response 806 including a status code from CN 102. The CN's HA 104 then returns an ORT response 807 to the request 804 to the MN's HA 103. This response is also signed and comprises CN privacy and route optimization requirements, along with CN HA 104 identifier and authorization credentials. When the MN transmits the ORT initialization request 803, the response 808 including the status code is received from the HA 103 next. If the security relationship 810 does not exist between both HA 103 and 104, it is established at step 809 using, for example, Internet Key Exchange (IKE) and the private and public keys of both entities. Some kind of security relationship 110 is required for the integrity protection exchange of binding update information between both HAs in step 811. This can also be achieved by directly signing the BU message with the corresponding public key. Next, each HA 103, 104 determines the distance to each other HA, as well as the distance to both MN 101 and CN 102, in steps 812 and 813, and in 814 and 815, the results are sent to the other HA, respectively. Report. This information is used in step 816 to determine a scenario that is a candidate for HA.

図９のＭＮ制御の変形例では、両方の移動ノードのホーム・アドレスを含むＯＲＴ要求９０１が必須である。これは、ＭＮのＨＡを通してＣＮのＨＡへとリバース・トンネリングされる。ＣＮのＨＡ１０４及びＣＮ１０２は、ＯＲＴ初期化要求８０５、及びオプションでそれへの応答８０６を交換することができる。いずれの場合も、次にＣＮのＨＡ１０４は、ＣＮのＨＡ１０４の識別子と、許可証明と、要求が受け入れられたかどうかの状況情報とを含むＯＲＴ要求９０１への応答９０２を、ＭＮ１０１に戻す。この要求が受け入れられた場合、ＭＮ１０１及びＣＮのＨＡ１０４はリターン・ルータビリティ・プロシージャ９０３を実行する。その後、セキュリティ関係９０４がＭＮ１０１とＣＮのＨＡ１０４との間に存在する。ＭＮは、プライバシー及びルート最適化要件９０５、並びにＢＵ情報９０６をＣＮのＨＡに送信する。ＣＮからＭＮのＨＡへのデータ・パケットのルーティングの場合、ステップ９０１〜９０６と対称のステップ９０７〜９１２が実行される。ＭＮ制御の場合、ＭＮ１０１及びＣＮ１０２は、ステップ９１３及び９１４で、ＨＡ１０３及び１０４の両方へのルーティング距離をそれぞれ決定し、ステップ９１５〜９１８で、この情報を両方のＨＡに報告する。この情報は、ステップ８１６で、ＨＡにおいて候補となるシナリオを決定するために使用される。 In the variant of MN control in FIG. 9, an ORT request 901 that includes the home addresses of both mobile nodes is mandatory. This is reverse tunneled through the MN's HA to the CN's HA. The CN's HA 104 and CN 102 may exchange an ORT initialization request 805 and optionally a response 806 thereto. In either case, CN's HA 104 then returns to MN 101 a response 902 to ORT request 901 that includes CN's HA 104 identifier, authorization credentials, and status information as to whether the request has been accepted. If this request is accepted, the HA 104 of the MN 101 and CN executes a return routability procedure 903. Thereafter, a security relationship 904 exists between the MN 101 and the CN's HA 104. The MN sends privacy and route optimization requirements 905 and BU information 906 to the CN's HA. For the routing of data packets from the CN to the MN's HA, steps 907 to 912 that are symmetrical to steps 901 to 906 are performed. For MN control, MN 101 and CN 102 determine the routing distance to both HAs 103 and 104 at steps 913 and 914, respectively, and report this information to both HAs at steps 915-918. This information is used at step 816 to determine candidate scenarios in the HA.

候補となるプロキシＨＡの発見
候補となるシナリオが決定された後、候補となるプロキシＨＡが発見される。第１に、これらのＨＡのプレフィックスがわからなければならない。シナリオａ）及びｂ）では、プレフィックスはＭＮ及びＣＮのＨｏＡから導出することが可能であり、シナリオｃ）及びｄ）では、ＭＮ及びＣＮのＣｏＡから導出することが可能である。シナリオｅ）では、プレフィックスを決定するのはさらに困難である。１つのオプションは、中間ネットワークのプレフィックスを発見するために、ＭＮ内のＨＡとＣＮの訪問ネットワークとの間でトレースルート・プロシージャをトリガすることである。他のオプションは、各ＨＡ内で候補となるプロキシＨＡプレフィックスのリストを構成し、このリストから好適な候補を見つけ出すことである。これにはかなり量のシグナリングが必要であり、成功しない確率が高いため、シナリオｅ）は、他のすべてのシナリオが適用できない場合にのみ使用するべきである。 Discovery of candidate proxy HAs After candidate scenarios are determined, candidate proxy HAs are discovered. First, you must know these HA prefixes. In scenarios a) and b), the prefix can be derived from the MN and CN's HoA, and in scenarios c) and d) it can be derived from the MN and CN's CoA. In scenario e), it is more difficult to determine the prefix. One option is to trigger a traceroute procedure between the HA in the MN and the CN's visited network to discover the intermediate network prefix. Another option is to construct a list of candidate proxy HA prefixes within each HA and find a suitable candidate from this list. Since this requires a significant amount of signaling and has a high probability of not succeeding, scenario e) should be used only when all other scenarios are not applicable.

プレフィックスがわかった場合、特定の候補となるプロキシＨＡのＩＰアドレスを決定しなければならない。プレフィックスが現在の訪問ネットワークと一致するという特殊なケースでは、プロキシＨＡは、例えば、ルータ通知（ＲＡ）メッセージに含まれる情報を利用する、ローカル手段によって発見することができる。その他の方法では、ＤＮＳを使用することができるが、これはすべてのＨＡアドレスを必要とするため、それらのプレフィックスがＤＮＳに格納される。現在では、このケースは当てはまらない。他のオプションは、エニーキャスト（ａｎｙｃａｓｔｉｎｇ）を使用する、ＲＦＣ３７７５に記載されたＤｙｎａｍｉｃＨｏｍｅＡｇｅｎｔＡｄｄｒｅｓｓＤｉｓｃｏｖｅｒｙ（ＤＨＡＡＤ）の修正バージョンを使用することである。複数のＨＡがリンク上に存在する場合、そのリンク上で、現在では特定のＭＮ又はＣＮのトンネルの宛先である、特定のＨＡを見つけなければならないことに留意されたい。シナリオａ）及びｂ）では、これは、例えば、ＣＮのＨｏＡに要求メッセージを送信すること、及びＣＮのＨＡの要求のインターセプトを可能にすることにより達成することができる。 If the prefix is known, the IP address of a specific candidate proxy HA must be determined. In the special case where the prefix matches the current visited network, the proxy HA can be discovered by local means, for example using information contained in router advertisement (RA) messages. Other methods can use DNS, but since this requires all HA addresses, their prefixes are stored in the DNS. Currently this is not the case. Another option is to use a modified version of Dynamic Home Agent Address Discovery (DHAAD) described in RFC 3775, which uses anycasting. Note that if multiple HAs exist on a link, a specific HA must be found on that link that is currently the destination of the tunnel for the specific MN or CN. In scenarios a) and b), this can be achieved, for example, by sending a request message to the CN's HoA and allowing the CN's HA request to be intercepted.

ターゲット・プロキシＨＡの選択
候補となるプロキシＨＡが決定された後、特定のターゲット・プロキシＨＡを選択しなければならない。これは、例えば、２つのプロキシを使用するシナリオから、１つのプロキシを使用するシナリオに変更する場合、距離情報に基づいて実行することが可能であり、より短いルートを提供するものが選択される。したがって、ｐＨＡ１及びｐＨＡ２が候補となるプロキシＨＡである場合に、距離ＭＮ＜−＞ｐＨＡ１、ＣＮ＜−＞ｐＨＡ１、ＭＮ＜−＞ｐＨＡ２、及びＣＮ＜−＞ｐＨＡ２が、ＭＮ、ＣＮ、及びＨＡによって測定される。距離はホップ数で表すことができるが、パケット遅延などの他の測定基準で定義することもできる。ホップ数は、シグナリング・メッセージ又はトンネリングされたデータ・パケットのＩＰヘッダ内のホップ制限フィールドから受動的に導出するか、又はプローブ・メッセージを送信することによって能動的に測定することができる。受動的な手法の場合、例えば、新しいモビリティ・オプションとして、送信側によって使用された初期のホップ制限値が受信側にとって未知である可能性があるため、この値をメッセージに含めることが必要な場合がある。プローブ・メッセージは、ＭＮ及び／又はＨＡによって送信可能である。しかし、ＣＮに関与する距離によって、ＭＮがＣＮの位置をある程度導出できるようにすることから、この距離はＭＮに対して明らかでないはずであることを考慮しなければならない。ＭＮ及びＣＮ（オリジナル）のＨＡはすべての距離情報を収集し、どのｐＨＡがより短いルートを提供するかを決定するが、（ＭＮ＜−＞ｐＨＡ１）＋（ｐＨＡ１＜−＞ＣＮ）＜（ＭＮ＜−＞ｐＨＡ２）＋（ｐＨＡ２＜−＞ＣＮ）の場合、ルート最適化に関してはｐＨＡ１の方が好ましく、そうでない場合はｐＨＡ２の方が好ましい。距離情報は、将来の他のノードのＯＲＴセッションでのシグナリング作業を節約するために、ＨＡにキャッシュすることも可能である。 Selection of Target Proxy HA After a candidate proxy HA is determined, a specific target proxy HA must be selected. This can be done based on distance information, for example, when changing from a scenario with two proxies to a scenario with one proxy, and the one that provides the shorter route is selected . Thus, when pHA1 and pHA2 are candidate proxy HAs, the distances MN <-> pHA1, CN <-> pHA1, MN <-> pHA2, and CN <-> pHA2 are determined by MN, CN, and HA. Measured. The distance can be expressed in number of hops, but can also be defined by other metrics such as packet delay. The number of hops can be passively derived from a hop limit field in the IP header of a signaling message or tunneled data packet, or can be actively measured by sending a probe message. In the case of a passive approach, for example, as a new mobility option, the initial hop limit value used by the sender may be unknown to the receiver, so this value needs to be included in the message There is. The probe message can be sent by the MN and / or HA. However, it must be taken into account that this distance should not be obvious to the MN, since the distance involved in the CN allows the MN to derive some CN location. The MN and CN (original) HAs collect all distance information and determine which pHA provides the shorter route, but (MN <-> pHA1) + (pHA1 <-> CN) <(MN In the case of <-> pHA2) + (pHA2 <-> CN), pHA1 is preferred for route optimization, and pHA2 is preferred otherwise. The distance information can also be cached in the HA to save signaling work in future ORT sessions of other nodes.

距離情報を収集するためのシグナリング流れの例は、図８及び図９の初期ネゴシエーション流れに示されており、上記で説明している。 An example of a signaling flow for collecting distance information is shown in the initial negotiation flow of FIGS. 8 and 9 and described above.

ターゲット・プロキシＨＡにおけるバインディング情報の確立
ターゲット・プロキシＨＡのアドレスがわかると、ＭＮ制御の変形例ではＭＮによって、又はＨＡ制御の変形例ではそのＨＡによって、バインディング・アップデート（ＢＵ）メッセージをこのアドレスに送信することができる。バインディング情報を受信した後、プロキシＨＡはＭＮに関するプロキシ隣接通知を送信しないことに留意されたい。プロキシ機能は、ＭＮのオリジナルＨＡに代わるトンネリングのみを言い表す。 Establishing binding information in the target proxy HA Once the address of the target proxy HA is known, the binding update (BU) message is sent to this address by the MN in the MN control variant or by the HA in the HA control variant. Can be sent. Note that after receiving the binding information, the proxy HA does not send a proxy neighbor notification for the MN. The proxy function only describes tunneling instead of the MN's original HA.

バインディング情報をセキュアに送信するためには、様々な問題を考慮しなければならない。第１に、悪意あるノードによるインターネット・ルータ（ここでは、プロキシＨＡ）へのルートの投入を防止しなければならない。そうでない場合、このノードは、例えば、トラフィックを分析又は改ざんし、これを被害者に返送するために、トラフィックを他の悪意あるノードにリダイレクトする可能性がある。攻撃者は、例えば、低帯域インターネット接続を有することから、大量のトラフィックを処理できない被害者に、トラフィックをリダイレクトする可能性もある。 In order to transmit the binding information securely, various problems must be considered. First, it is necessary to prevent a malicious node from injecting a route to the Internet router (here, the proxy HA). Otherwise, this node may redirect the traffic to other malicious nodes, for example, to analyze or tamper with the traffic and send it back to the victim. An attacker, for example, has a low-bandwidth Internet connection and may redirect traffic to a victim who cannot handle a large amount of traffic.

これを防ぐために、ＢＵの送信側はプロキシＨＡで認証し、ＭＮ制御の変形例の場合、これが実際に請求されたＨｏＡを所有していることを証明しなければならない。ＭＮが実際に請求されたＣｏＡを所有しているかどうかをチェックするために、追加の到達可能性テストを実施することができる。認証及び送信側アドレス所有証明は、公開／秘密鍵及びＩＤ証明によって達成可能であり、ＩＤ証明は公開鍵を送信側アドレスにバインドし、ＢＵは秘密鍵を使用して署名される。ＩＤ証明の代替は、公開鍵を送信側のアドレスにバインドする、ＣｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙＧｅｎｅｒａｔｅｄＡｄｄｒｅｓｓｅｓ（ＣＧＡ）（Ａｕｒａ，Ｔ．、「ＣｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙＧｅｎｅｒａｔｅｄＡｄｄｒｅｓｓｅｓ（ＣＧＡ）」、Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｃｇａ−０６、２００４年４月）である。ＣＧＡは、ＨｏＡのインターフェース識別子を認証するのみであるため、アドレスのプレフィックスが正しいことを証明するために追加の到達可能性テストを実施するべきである。鍵及び証明の割り振りには、割り振り数に応じて増加する、大量の管理作業を必要とするため、この手法は、ＨＡ制御の変形例にのみ適用するべきである。この場合、鍵及び証明は、すべてのＭＮではなくＨＡにのみ割り振ればよい。 To prevent this, the BU sender must authenticate with the proxy HA, and in the case of the MN controlled variant, it must prove that it actually owns the claimed HoA. Additional reachability tests can be performed to check if the MN actually owns the claimed CoA. Authentication and sender address ownership proof can be achieved by public / private key and ID certificate, where the ID certificate binds the public key to the sender address and the BU is signed using the private key. An alternative to ID proof is Cryptographically Generated Addresses (CGA) (Aura, T., “Cryptographically Generated Addresses (CGA)”, Internet-Draft Draft-Draft-Draft-Draft0-Fraction-Draft-Draft-Draft0 , April 2004). Since the CGA only authenticates the HoA interface identifier, additional reachability tests should be performed to prove that the address prefix is correct. Since the allocation of keys and certificates requires a large amount of management work that increases with the number of allocations, this approach should only be applied to the HA control variant. In this case, the key and certificate need only be allocated to the HA, not to all MNs.

ＭＮ制御の変形例の場合、ＣｏＡ及びＨｏＡのチェック並びにＢＵメッセージの認証は、ＲＦＣ３７７５に記載されたルート最適化モードで使用されるリターン・ルータビリティ・プロシージャを利用することによって達成可能である。しかし、ＲＦＣ３７７５におけるリターン・ルータビリティ・プロシージャが、ＭＮ−ＣＮ及びＭＮ−ＨＡ−ＣＮの両方のパスを盗聴できる攻撃者に対する耐性がないことは周知である。ＲＦＣ３７７５では、ＭＮとＨＡの間のパスはＩＰＳｅｃＳＡによって保護される。それ故、ＨＡとＣＮの間のパスのみが重要である。さらに、ルーティング・インフラストラクチャはネットワーク・オペレータによって良好に機密保護されているため、通常、攻撃者はネットワークの端部にいる。それ故、攻撃者にとっての重要ポイントは、ＣＮの接続ポイントである。ルートはホスト（例えば、ＣＮ）だけではなく、インターネット・ルータ（ここでは、プロキシＨＡ）にも投入されることから、攻撃者にさらにオプションを与えるため、本発明ではこの問題は特に課題となる。幸いなことに、ＲＦＣ３７７５とは対照的に、本発明におけるプロシージャはＭＮとＣＮの間ではなく、ＭＮと、通常はネットワーク又はルーティング・インフラストラクチャ内に配置されるプロキシＨＡとの間で、実行される。したがって、（本発明で実行されるような）プロキシＨＡをターゲットとするリターン・ルータビリティ・プロシージャの方が、（ＲＦＣ３７７５で実行されるような）ＣＮをターゲットとするよりも、よりセキュアであるとみなされる。 For the MN controlled variant, CoA and HoA checks and BU message authentication can be achieved by utilizing the return routability procedure used in the route optimization mode described in RFC3775. However, it is well known that the return routability procedure in RFC 3775 is not resistant to attackers who can eavesdrop on both MN-CN and MN-HA-CN paths. In RFC3775, the path between MN and HA is protected by IPSec SA. Therefore, only the path between HA and CN is important. In addition, the attacker is usually at the edge of the network because the routing infrastructure is well secured by the network operator. Therefore, the important point for the attacker is the connection point of CN. Since the route is not only entered into the host (eg CN) but also into the Internet router (here, the proxy HA), this problem is particularly problematic in the present invention to give the attacker more options. Fortunately, in contrast to RFC 3775, the procedure in the present invention is not performed between the MN and the proxy HA, usually located in the network or routing infrastructure, rather than between the MN and the CN. The Therefore, return routability procedures targeting proxy HA (as implemented in the present invention) are more secure than targeting CN (as implemented in RFC3775). It is regarded.

他の課題は、ＭＮにとって、他のＭＮのＣｏＡ（及びその位置）を見つけ出すために、プロキシＨＡであるように首尾よく見せかけることは不可能なはずである、ということである。このため、ＢＵメッセージの受信側は、ネットワーク・オペレータの有効な（プロキシ）ＨＡであることを証明しなければならない。これは、ネットワーク・オペレータによって発行される許可証明を使用して達成可能である。こうした証明は、（Ｊ．Ａｒｋｋｏ、Ｊ．Ｋｅｍｐｆ、Ｂ．Ｓｏｍｍｅｒｆｅｌｄ、Ｂ．Ｚｉｌｌ、Ｐ．Ｎｉｋａｎｄｅｒ、「ＳＥｃｕｒｅＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙ（ＳＥＮＤ）」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｎｄｏｐｔ−０６、２００４年７月）又は（Ｍ．Ｌｉｅｂｓｃｈ、Ａ．Ｓｉｎｇｈ、Ｈ．Ｃｈａｓｋａｒ、Ｄ．Ｆｕｎａｔｏ、Ｅ．Ｓｈｉｍ、「ＣａｎｄｉｄａｔｅＡｃｃｅｓｓＲｏｕｔｅｒＤｉｓｃｏｖｅｒｙ」、ＩＥＴＦＩｎｔｅｒｎｅｔＤｒａｆｔｄｒａｆｔ−ｉｅｔｆ−ｓｅａｍｏｂｙ−ｃａｒｄ−ｐｒｏｔｏｃｏｌ−０８．ｔｘｔ、２００４年９月）でも使用される。２つの証明、許可及びＩＤ証明は、ネットワーク・オペレータ用のＨＡとして働くことをＨＡに許可し、公開鍵をＨＡアドレスにバインドすることができる。公開鍵を使用して、ＨＡ制御の変形例におけるＢＵ情報の交換を機密保護するために、ＨＡ間のＩＰｓｅｃセキュリティ関係を初期化することができる。ＩＰｓｅｃセキュリティ関係を確立する代わりに、秘密鍵を使用してシグナリング・メッセージに直接署名することもできる。 Another challenge is that it should not be possible for a MN to successfully masquerade as a proxy HA to find another MN's CoA (and its location). For this reason, the receiver of the BU message must prove that it is a valid (proxy) HA of the network operator. This can be accomplished using authorization credentials issued by the network operator. Such proofs are (J. Arkko, J. Kempf, B. Somerfeld, B. Zill, P. Nikander, “SECure Neighbor Discovery (SEND)”, IETF Internet Draft Draft-det-det-6-dend-6-dent-det-6-send-det-6-sent-4 Month) or (M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim, "Candidate Access Router Discovery", IETF Internet Draft draft-ietf-samobi-card-ro. (September). Two certificates, an authorization and an ID certificate, allow the HA to act as the HA for the network operator and bind the public key to the HA address. In order to secure the exchange of BU information in a variant of HA control using a public key, an IPsec security relationship between HAs can be initialized. Instead of establishing an IPsec security relationship, the signaling message can also be signed directly using a private key.

これらのメッセージは、その時だけノンス（ｎｏｎｃｅ）及び／又はタイムスタンプをＯＲＴ要求／応答メッセージに追加することによって、攻撃の制限を防ぐことができる。リソースを枯渇させるＤｏＳ攻撃は、もう１つのセキュリティ問題である。メモリの枯渇を防ぐために、ＯＲＴのイニシエータが認証されていることを証明する前に、ＨＡには何の状態も確立されていてはならない。ＨＡ制御の変形例では、ＯＲＴ要求は署名され、この証拠を提供できる証明を含む。ＭＮ制御の変形例では、ＯＲＴ要求はＨＡ内に状態を確立しない。状態は、この証拠を提供するリターン・ルータビリティ・プロシージャ後にのみ確立される。しかし、証明の検証及び公開鍵の署名には、大量のＣＰＵリソースが必要であり、ＣＰＵを枯渇される攻撃に活用される可能性がある。ＭＮ制御の変形例では、ＭＮは要求メッセージを送信した後に証明を検証するだけでよいため、この攻撃はＨＡ制御の変形例におけるＨＡにのみ影響を与える。実際にターゲット・アドレスが、受信側ＨＡによって管理されるＣＮのアドレスであるかどうかを、ＯＲＴ要求の受信時に最初にチェックするという対策が可能である。これに当てはまらない場合、証明をチェックすることなく要求を拒否することができる。この方法では、攻撃者は第１に、被害者のバインディング・キャッシュに関するある程度の知識を有する必要がある。ＯＲＴ応答メッセージは、有効な証明を備えた対応する（連続番号で示された）要求があらかじめ送信されている場合にのみ、処理されるものとする。他の対策は、ＯＲＴ要求メッセージの受信側が検証に使用するリソースの量に制限を設定することである。この手法は、モバイルＩＰｖ６ルート最適化モードに対する同様の攻撃（「不必要なバインディング・アップデート攻撃」）に対する対策としても使用される（Ｎｉｋａｎｄｅｒ，Ｐ．、「ＭｏｂｉｌｅＩＰｖｅｒｓｉｏｎ６ＲｏｕｔｅＯｐｔｉｍｉｚａｔｉｏｎＳｅｃｕｒｉｔｙＤｅｓｉｇｎＢａｃｋｇｒｏｕｎｄ」、２００４年１０月を参照のこと）。 These messages can prevent attack limitations by adding a nonce and / or timestamp to the ORT request / response message only then. DoS attacks that exhaust resources are another security issue. To prevent memory exhaustion, no state should be established in the HA before proving that the initiator of the ORT is authenticated. In a variant of HA control, the ORT request is signed and includes a proof that can provide this evidence. In a variant of MN control, the ORT request does not establish a state in the HA. The state is established only after a return routability procedure that provides this evidence. However, the verification of the proof and the signature of the public key require a large amount of CPU resources, which may be used for attacks that exhaust the CPU. In the MN control variant, this attack only affects the HA in the HA control variant, since the MN only needs to verify the proof after sending the request message. It is possible to take a measure of first checking whether the target address is the address of the CN managed by the receiving side HA when the ORT request is received. If this is not the case, the request can be rejected without checking the proof. In this method, the attacker must first have some knowledge of the victim's binding cache. The ORT response message shall be processed only if the corresponding request (indicated by the serial number) with a valid certificate has been sent beforehand. Another measure is to set a limit on the amount of resources that the recipient of the ORT request message uses for verification. This technique is also used as a countermeasure against a similar attack on the Mobile IPv6 route optimization mode (“Unnecessary Binding Update Attack”) (Nikander, P., “Mobile IP version 6 Route Optimization Design Background Backround”, (See October 2004).

増幅を利用する反射攻撃は、応答／肯定応答が常にほぼ同じか又は小さいサイズの単一のパケットで応答され、要求の送信側アドレスに送信されることを確実にすることによって防止される。 Reflex attacks utilizing amplification are prevented by ensuring that the response / acknowledgement is always responded with a single packet of approximately the same or small size and sent to the requesting sender's address.

ＭＮとプロキシＨＡとの間で送信されるいかなるシグナリング・メッセージ、例えば、移動後のＢＵメッセージも、以前に確立されたセキュリティ関係を使用することによって認証されて送信されるべきであることに留意されたい。ＭＮ制御の変形例では、ＭＮ及びプロキシＨＡは直接セキュリティ関係を有するが、ＨＡ制御の変形例ではこれは当てはまらない。したがって、すべてのシグナリング・メッセージはＭＮのオリジナルＨＡを通して現在のプロキシＨＡに進まなければならない。またＭＮが移動する場合も、依然としてＢＵをそのオリジナルＨＡに送信する。ＨＡ制御の変形例では、その後オリジナルＨＡはＢＵをプロキシＨＡに転送する。ＭＮ制御の変形例では、ＭＮ自体がＢＵをそのオリジナルとそのプロキシの両方のＨＡに送信する。 It is noted that any signaling message sent between the MN and the proxy HA, for example, the moved BU message, should be authenticated and sent using a previously established security relationship. I want. In the MN control variant, the MN and the proxy HA have a direct security relationship, but this is not the case in the HA control variant. Thus, all signaling messages must go through the MN's original HA to the current proxy HA. If the MN moves, it still sends the BU to its original HA. In a variant of HA control, the original HA then forwards the BU to the proxy HA. In a variant of MN control, the MN itself sends a BU to both its original and its proxy HA.

ＨＡ制御及びＭＮ制御の変形例で、シナリオｃ）〜ｅ）を達成するためのシグナリング流れの例は、図１１及び図１２に示される。ターゲットのシナリオがａ）又はｂ）の場合、バインディング情報は初期ネゴシエーション時にすでにプロキシＨＡに送信されている。 Examples of signaling flows for achieving scenarios c) -e) with variations of HA control and MN control are shown in FIGS. If the target scenario is a) or b), the binding information has already been sent to the proxy HA during the initial negotiation.

トンネル・エンド・ポイントのターゲット・プロキシＨＡとの間での切り替え
バインディング情報がターゲット・プロキシＨＡ内で確立された後、パスの最適化のために、トンネル・エンド・ポイントをこのターゲット・プロキシに切り替えることができる。個々のＩＰ−ｉｎ−ＩＰトンネルは常に単方向であるため、入口ポイント又はソースと、出口ポイント又は宛先とを有する。ＩＰ−ｉｎ−ＩＰトンネルの確立又は削除には、通常、トンネルの入口ポイントでのアクションのみが必要である。しかし、トンネリングされたパケットのソースと予想されるトンネル入口ポイントとを比較することができるため、出口ポイントに通知するべきである。ＩＰｖ６のトンネリングに関する一般的なメカニズムは、ＲＦＣ２４７３に指定されている。 Switching between the tunnel end point and the target proxy HA After the binding information is established in the target proxy HA, switch the tunnel end point to this target proxy for path optimization be able to. Since an individual IP-in-IP tunnel is always unidirectional, it has an entry point or source and an exit point or destination. Establishing or deleting an IP-in-IP tunnel typically requires only action at the tunnel entry point. However, the egress point should be notified because the source of the tunneled packet can be compared with the expected tunnel entry point. The general mechanism for IPv6 tunneling is specified in RFC 2473.

以下の２つのタイプのトンネル切り替えを区別することができる。
１）トンネルのソースが１つのプロキシＨＡから他方へ移動される
２）トンネルの宛先が１つのプロキシＨＡから他方へ移動される Two types of tunnel switching can be distinguished:
1) Tunnel source is moved from one proxy HA to the other 2) Tunnel destination is moved from one proxy HA to the other

トンネル確立要求メッセージはトンネルの新しいソースに送信され、トンネル削除要求メッセージはトンネルの現在のソースに送信される。さらに、トンネル切り替え通知メッセージは新しいトンネルの宛先に送信される。すべてのトンネル要求メッセージは、トンネルの対応するエンド・ポイントのアドレスを含む。通常、プロキシＨＡは、１つのノードのトンネルのソース及び他方のノードのトンネルの宛先である。可能であれば、メッセージは他のメッセージと集合することができる。ＭＮ−ＣＮパス全体のパケット損失を防ぐために、トンネルのあらゆる切り替え（例えば、ＭＮ−ｐＨＡ）は、通信相手ノードのトンネルの切り替え（例えば、ｐＨＡ−ＣＮ）と同期されるべきである。したがって、あらゆる要求／通知メッセージには、状況コードを含む肯定応答メッセージで応答しなければならない。この状況コードは、プロキシＨＡの着信トンネル及び発信トンネルの両方がセットアップされた場合、成功したトンネル確立のみを示すことができる。さらに、ＭＮ及びＣＮは、状況がＭＮ−ＣＮパス全体の成功したセットアップを示す前に、それらの発信トンネルを切り替えてはならない。 A tunnel establishment request message is sent to the new source of the tunnel, and a tunnel delete request message is sent to the current source of the tunnel. Further, the tunnel switch notification message is transmitted to the new tunnel destination. All tunnel request messages include the address of the corresponding end point of the tunnel. Usually, the proxy HA is the source of the tunnel of one node and the destination of the tunnel of the other node. If possible, messages can be aggregated with other messages. To prevent packet loss across the MN-CN path, every tunnel switch (eg, MN-pHA) should be synchronized with the correspondent node tunnel switch (eg, pHA-CN). Therefore, every request / notification message must be responded with an acknowledgment message containing a status code. This status code can only indicate a successful tunnel establishment if both the incoming and outgoing tunnels of the proxy HA are set up. Furthermore, the MN and CN must not switch their outgoing tunnels before the situation indicates a successful setup of the entire MN-CN path.

他のノードから着信するか又は他のノードへ送信されるデータ・パケットは、デフォルトでは、依然としてオリジナルのＨＡを通してルーティングされることに留意されたい。トンネル切り替えは特定のＭＮ−ＣＮ通信セッションのみに適用されるため、プロキシＨＡの転送機能は、ＩＰヘッダ内のソース・アドレスも考慮すべきである。 Note that data packets that arrive from or are sent to other nodes are still routed through the original HA by default. Since tunnel switching applies only to a specific MN-CN communication session, the forwarding function of the proxy HA should also consider the source address in the IP header.

ＨＡ制御及びＭＮ制御の変形例に関するシグナリング流れの例は、シナリオａ）及びｂ）については図１０に、シナリオｃ）〜ｅ）については図１１及び図１２に、それぞれ示されている。 An example of the signaling flow for a variation of HA control and MN control is shown in FIG. 10 for scenarios a) and b) and in FIGS. 11 and 12 for scenarios c) -e), respectively.

移動性が存在する場合のパスの適合
一般にＯＲＴは、常時バックグラウンドで実行することができる。接続確立直後に通信パートナによって、又は後にオンデマンドでトリガすることができる。ＭＮは移動体である可能性があるため、しばらく後に最適化ルート長さは最適でなくなる可能性があり、ＯＲＴの再実行が必要になる。しかし、何らかのシグナリングが必要であるため、プロシージャの反復はできる限り頻度を少なく、通信セッションが長い期間続く場合のみとすべきである。さらに、恩恵が少ない場合、すなわちパスが短くならないか又はわずかに短くなるだけの場合は、プロシージャを実行すべきではない。 Path adaptation in the presence of mobility In general, ORT can always run in the background. It can be triggered immediately after the connection is established by the communication partner or later on demand. Since the MN may be a mobile, the optimized route length may not be optimal after a while, and the ORT needs to be re-executed. However, because some signaling is required, the procedure should be repeated as often as possible and only if the communication session lasts for a long period of time. Furthermore, if the benefit is low, i.e. the path is not shortened or only slightly shortened, the procedure should not be executed.

恩恵は、候補となるプロキシＨＡを通してルート長さを測定するプロシージャを反復することによって決定することができる。潜在的に、ターゲット・シナリオも変更しなければならない。１つの手法は、上記で詳細に説明した距離測定プロシージャを定期的に反復することである。これは、両方のＭＮが絶えず移動している場合、及び現在のパスと最適化されたパスとの差がほぼ直線的に増加する場合、効率的であるとみなされる。他の方法は、ハンドオーバごと、又はＮ回のハンドオーバごとに、再実行をトリガすることである。これは、移動性が低い場合、及びハンドオーバが稀である場合に、効率的であるとみなされる。 Benefits can be determined by iterating the procedure of measuring route length through candidate proxy HAs. Potentially, the target scenario must also change. One approach is to periodically repeat the distance measurement procedure described in detail above. This is considered efficient if both MNs are constantly moving and if the difference between the current path and the optimized path increases almost linearly. Another method is to trigger a re-execution every handover or every N handovers. This is considered efficient when mobility is low and handovers are rare.

図１３は、パケット交換移動通信システムにおいてＭＮのホーム・エージェントとして働くように構成可能なネットワーク・サーバ１３００の基本構造を示す。これはさらに、（第１の）ＭＮのＨＡ、ＣＮのＨＡとして、又は任意のプロキシＨＡとして、前述の方法ステップを実行するように構成することも可能である。非常に一般的な実装では、サーバは、前述のタスク及び代替のうちのいくつか又はすべてをサポートするように構成される。 FIG. 13 shows the basic structure of a network server 1300 that can be configured to act as a home agent for an MN in a packet-switched mobile communication system. It can also be configured to perform the above-described method steps as the (first) MN HA, CN HA, or any proxy HA. In a very common implementation, the server is configured to support some or all of the aforementioned tasks and alternatives.

ネットワーク・サーバ１３００は、処理ユニット１３０１、ランダム・アクセス・メモリ１３０２、及び、パケット交換ネットワークに接続するための少なくとも１つのネットワーク・インターフェース１３０３を備える。さらに、不揮発性半導体メモリ１３０４及び／又は、磁気又は光ハード・ディスク・ドライブ１３０５を備えることもできる。オプションで、初期プログラムのローディング又はプログラム更新のために、任意の種類の磁気、光、又は半導体の記憶媒体用の読取装置を含めることができる。ネットワーク・サーバ１３００は、ディスプレイ・スクリーン又はキーボードなどの、ここでは示されていないオプションの構成要素をさらに備えることができる。 The network server 1300 comprises a processing unit 1301, a random access memory 1302, and at least one network interface 1303 for connecting to a packet switched network. Further, a non-volatile semiconductor memory 1304 and / or a magnetic or optical hard disk drive 1305 may be provided. Optionally, a reader for any type of magnetic, optical, or semiconductor storage medium can be included for initial program loading or program update. The network server 1300 may further comprise optional components not shown here, such as a display screen or a keyboard.

ＭＮのＨｏＡとＣｏＡの間のバインディングを格納するためのバインディング・キャッシュ１３０７、１３０８、及び１３０９は、ＲＡＭ１３０２、ＮＶＭ１３０４、及びハード・ディスク１３０５のうちの１つ又はいくつかにおける、予約メモリ・スペースとすることができる。 Binding caches 1307, 1308, and 1309 for storing bindings between the MN's HoA and CoA are reserved memory spaces in one or several of RAM 1302, NVM 1304, and hard disk 1305. be able to.

ネットワーク・サーバ１３００は、そのＣＰＵ１３０１上で、ＲＡＭ１３０２、ＮＶＭ１３０４、及び／又はハード・ディスク１３０５に格納されたプログラム命令を実行することによって、前述の方法ステップを実行するように構成することができる。これらの命令は、媒体読取装置１３０６によって読み取り可能な任意の他のコンピュータ読み取り可能記憶媒体１３１０上のこれらのメモリ位置にダウンロードするために格納することができる。こうした媒体は、ＣＤ（コンパクト・ディスク）、ＤＶＤ（デジタル多用途ディスク）、フロッピー（登録商標）・ディスク、又は半導体メモリ・カードとすることができる。 The network server 1300 can be configured to perform the above-described method steps by executing program instructions stored on the RAM 1302, NVM 1304, and / or hard disk 1305 on its CPU 1301. These instructions can be stored for download to these memory locations on any other computer readable storage medium 1310 readable by the media reader 1306. Such a medium can be a CD (compact disc), a DVD (digital versatile disc), a floppy disk, or a semiconductor memory card.

本発明は、データ・パケットが、ＭＮのロケータを永続識別子にマッピングするための責務を負う何らかの種類のモビリティ・エージェントを介してルーティングされる、他の移動性管理プロトコル及びシステムに適用することもできる。 The present invention can also be applied to other mobility management protocols and systems in which data packets are routed through some kind of mobility agent that is responsible for mapping the MN's locator to a persistent identifier. .

マルチホーム端末
以下では、ＯＲＴのＨＡ制御及びＭＮ制御の変形例に関するマルチホーム・サポートについて詳細に説明する。ＭＮが複数のＨｏＡ及びＣｏＡを有し、ＣＮが複数のＣｏＡ及び１つのＨｏＡを有する場合に、可能なデータ・パスのサブセットを使用するシナリオの例が図１４に示される。 Multi-Home Terminal In the following, multi-home support related to a modification of ORT HA control and MN control is described in detail. An example scenario using a subset of possible data paths is shown in FIG. 14, where the MN has multiple HoAs and CoAs, and the CN has multiple CoAs and one HoA.

ＯＲＴ／ＲＯＴＡに関する複雑さは、ロード・バランシング及び冗長性の理由でリンク上に複数のＨＡが存在する可能性があること、並びに、（すべてのトンネル・セグメントが接続されるように）それらのうちの１つだけがパス上にあるものとして選択できることである。そうでなければ、（ＨｏＡのプレフィックスはリンクのプレフィックスのうちの１つと一致しないことから）プロキシＨＡはプロキシされたＨｏＡに対してプロキシの隣接発見を実行しないため、データ・パケットはその宛先への最適化ルートを使用しないことになる。例えば、ＭＮがｐＨＡ１をプロキシＨＡとして選択し、ＣＮが、同じリンク上に配置されたｐＨＡ１以外の他のＨＡであるｐＨＡ２をプロキシＨＡとして選択する場合、ＣＮはデータ・パケットをｐＨＡ２へとリバース・トンネリングするが、ｐＨＡ１だけはパケットをＭＮへとトンネリングすることができる。したがって、パケットは非最適化パスを介してＭＮのＨＡにルーティングされることになる。ｐＨＡ１は、ＭＮのＨｏＡに対してプロキシの隣接発見を実行できない（アドレスがオンリンク・プレフィックスを持たない）ため、パケットはｐＨＡ１によってインターセプトされないことに留意されたい。 The complexity of ORT / ROTA is that there can be multiple HAs on the link for load balancing and redundancy reasons, and of them (as all tunnel segments are connected) Only one of the can be selected as being on the path. Otherwise, because the proxy HA does not perform proxy neighbor discovery for the proxied HoA (since the HoA prefix does not match one of the link prefixes), the data packet is destined for that destination. The optimized route will not be used. For example, if the MN selects pHA1 as the proxy HA and the CN selects pHA2, which is another HA other than pHA1 located on the same link, as the proxy HA, the CN reverses the data packet to pHA2. Although tunneling, only pHA1 can tunnel packets to the MN. Thus, the packet will be routed to the MN's HA via a non-optimized path. Note that the packet is not intercepted by pHA1 because pHA1 cannot perform proxy neighbor discovery to the MN's HoA (the address does not have an on-link prefix).

主な考え方は、ＭＮ及びＣＮがそれぞれ、それらのＨｏＡのうちの１つを選択し、使用されるインターフェースごとに少なくとも１つのＣｏＡを対応するＨＡに登録することである（これは、１つのＨＡのバインディング・キャッシュにおいて、複数のＣｏＡを１つのＨｏＡに割り当て可能であることを示唆する）。さらに、ＭＮ及びＣＮは、候補となるプロキシＨＡとみなされる既知の（例えば、他のインターフェースに割り当てられた）ＨＡについて、ＨＡに通知する。次にＭＮ及びＣＮのＨＡは、最良のパスを提供するＣｏＡとプロキシＨＡとの組み合わせを別個に選択し、その後、共通ソリューションに達するようにネゴシエートすることができる。選択アルゴリズムは、受信したパケットから受動的に、又はプロービングによって能動的に決定することが可能な、距離情報に基づくものとすることができる。 The main idea is that each MN and CN choose one of their HoAs and register at least one CoA with the corresponding HA for each interface used (this is one HA This suggests that multiple CoAs can be assigned to one HoA in the binding cache of In addition, the MN and CN notify the HA about known HAs (eg, assigned to other interfaces) that are considered candidate proxy HAs. The MN and CN HAs can then separately select the CoA and proxy HA combination that provides the best path and then negotiate to reach a common solution. The selection algorithm can be based on distance information that can be determined passively from received packets or actively by probing.

第１のステップでは、ＭＮは、ＣＮとの通信に使用されるそのＨｏＡのうちの１つを選択し、ＣＮがマルチホームでありＭＮがＣＮの複数のＨｏＡを認識した場合、宛先アドレスとしてＣＮのＨｏＡのうちの１つを選択する。ＨｏＡに対応する（主）ＨＡは、以下で、ＭＮのＨＡ及びＣＮのＨＡと呼ばれる。 In the first step, the MN selects one of its HoAs used for communication with the CN, and if the CN is multihomed and the MN recognizes multiple HoAs of the CN, the CN as the destination address Select one of the HoAs. The (primary) HAs corresponding to HoA are referred to below as MN HA and CN HA.

ＨＡへのリバース・トンネルを使用して特定のインターフェース上でデータを送信及び受信できるようにするために、ＭＮは、このインターフェースに割り当てられたアドレスのうちの少なくとも１つをＭＮのＨＡにＣｏＡとして登録する。 In order to be able to send and receive data on a particular interface using a reverse tunnel to the HA, the MN may use at least one of the addresses assigned to this interface as a CoA to the MN's HA. sign up.

次にＭＮは、ＭＮのＨｏＡ及びＣＮのＨｏＡを含むＭＮのＨＡにＯＲＴ初期化要求を送信することによって、ＯＲＴ（最適化リバース・トンネリング）を開始する。加えて、移動ノードは、登録されているＨＡのすべて又はサブセットを候補となるプロキシＨＡとしてＭＮのＨＡに対して提案することができる。この情報は、例えば、それらのアドレスを、バインディング・アップデートメッセージ又はＯＲＴ初期化要求メッセージによって実行可能な新しい「候補となるプロキシＨＡモビリティ・オプション」に含めることにより送達される。 The MN then initiates ORT (optimized reverse tunneling) by sending an ORT initialization request to the MN's HA including the MN's HoA and CN's HoA. In addition, the mobile node can propose to the MN's HA all or a subset of the registered HAs as candidate proxy HAs. This information is delivered, for example, by including their addresses in a new “candidate proxy HA mobility option” that can be executed by a binding update message or an ORT initialization request message.

ＭＮのＨＡはＯＲＴ初期化要求を受信すると、候補となるプロキシＨＡアドレスを格納することができる。候補となるプロキシＨＡのうちの一部が信頼できない場合、対応するアドレスが選別され、そのようにマーク付けされるはずである。次に、ＭＮのＨＡは、例えば、拡張ＤＨＡＡＤプロシージャを使用して、ＣＮのＨｏＡに関するバインディングを管理するＨＡを発見する。ＣＮのホーム・ネットワークが分散型である場合、この発見の結果、複数のＨＡが生じる可能性がある。この場合、ＭＮのＨＡはそれらのうちの１つを選択し、このＨＡ（以下、ＣＮのＨＡと呼ぶ）にＯＲＴ要求を送信する。さらに、（例えば、ＯＲＴ要求によって実行される候補となるプロキシＨＡオプションを使用して）候補となるプロキシＨＡをＣＮのＨＡに提案し、これによって信頼できない候補を選別することができる。 Upon receiving the ORT initialization request, the MN's HA can store candidate proxy HA addresses. If some of the candidate proxy HAs are unreliable, the corresponding address should be screened and marked as such. The MN's HA then discovers the HA that manages the binding for the CN's HoA using, for example, an extended DHAAD procedure. If the CN's home network is distributed, this discovery can result in multiple HAs. In this case, the MN's HA selects one of them and sends an ORT request to this HA (hereinafter referred to as the CN's HA). In addition, candidate proxy HAs can be proposed to the CN's HA (eg, using a candidate proxy HA option to be executed by an ORT request), thereby selecting untrusted candidates.

ＣＮのＨＡは、ＯＲＴ初期化要求をＣＮに送信する。この要求を受信すると、ＣＮは、ＣＮのＨＡにＣｏＡとして使用されるインターフェースごとに少なくとも１つのアドレスを登録する。次に、ＣＮが登録されているＨＡのすべて又はサブセットを（例えば、ＯＲＴ初期化応答によって実行される候補となるプロキシＨＡオプションを使用して）候補となるプロキシＨＡとしてＣＮのＨＡに対して提案することができる。信頼できない候補となるプロキシＨＡを選別した後、次にＣＮのＨＡは、それらのすべて又はサブセットを（例えば、ＯＲＴ応答によって実行される候補となるプロキシＨＡオプションを使用して）追加の候補となるプロキシＨＡとしてＭＮのＨＡに提案することが可能であり、これによって信頼できない候補を再度選別することができる。 The CN's HA sends an ORT initialization request to the CN. Upon receiving this request, the CN registers at least one address for each interface used as CoA in CN's HA. Next, all or a subset of the HA with which the CN is registered is proposed to the CN's HA as a candidate proxy HA (eg, using the candidate proxy HA option performed by the ORT initialization response) can do. After screening untrusted candidate proxy HAs, the CN HA then makes all or a subset of them additional candidates (eg, using candidate proxy HA options performed by the ORT response). It is possible to propose to the MN's HA as a proxy HA, which makes it possible to re-select untrusted candidates.

次に、プロキシＨＡ及びＣｏＡ選択プロシージャがＭＮ及びＣＮのＨＡ上で別個に実行される。この選択は、他の情報の中でも特に距離情報に基づくものとすることができる。何らかの距離情報を、以前のセッションから事前構成又はキャッシュすることが可能であり、一部は、例えば、受信したＯＲＴ又はモバイルＩＰｖ６のシグナリング・メッセージに基づいて受動的に測定することができる。例えば、ＭＮからＣＮのＨＡまで、又はＭＮ／ＣＮからＭＮ／ＣＮのＨＡまでの距離は、受信したパケットのホップ制限フィールドをピークする（ｐｅｅｋｉｎｇ）ことで、すでに知られている可能性がある。一部のシナリオではこの情報で十分な可能性があり、例えば、ＭＮ又はＣＮのＨＡが、プロキシＨＡとして働いている際にすでに十分短いパスを提供している場合、それ以上の距離情報は不要である。 Next, the proxy HA and CoA selection procedures are performed separately on the MN and CN HAs. This selection can be based on distance information, among other information. Some distance information can be pre-configured or cached from previous sessions, and some can be passively measured based on, for example, received ORT or Mobile IPv6 signaling messages. For example, the distance from the MN to the CN's HA or from the MN / CN to the MN / CN's HA may already be known by peaking the hop limit field of the received packet. This information may be sufficient in some scenarios, for example if the MN or CN's HA is already providing a sufficiently short path when acting as a proxy HA, no further distance information is needed It is.

他のケースでは、ＭＮのＨＡ、ＣＮのＨＡ、及び候補となるプロキシＨＡの間で、ＢＵ情報を交換することが可能であり、距離情報は能動的に測定すること、又は他のノードに要求することが可能である。候補となるプロキシＨＡ間、及び候補となるプロキシＨＡとＭＮ又はＣＮのＣｏＡとの間のリンク・コストは、能動的プロービングを使用して測定することができる。最適なルートが見つかった場合、すべてのパス・セグメントの長さ、すなわち、すべてのプロキシＨＡ間及びすべてのＭＮ／ＣＮのＣｏＡまでの長さを知らなければならない。パス長さ要件がわかった場合、すべての可能なパスについて考慮する前に、要件を満たす（準最適）パスが見つかれば、プロキシＨＡ及びＣｏＡの選択を打ち切ることができる。また、選択においてパス上の１つのプロキシＨＡを使用するシナリオが考慮の対象とされる場合、プロキシＨＡ間の距離を測定する必要はない。 In other cases, BU information can be exchanged between the MN's HA, the CN's HA, and the candidate proxy HA, and the distance information is actively measured or requested by other nodes. Is possible. Link costs between candidate proxy HAs and between a candidate proxy HA and a MN or CN CoA can be measured using active probing. If an optimal route is found, it must know the length of all path segments, i.e. the length between all proxy HAs and to the CoA of all MN / CN. Once the path length requirements are known, the proxy HA and CoA selection can be aborted if a path that meets the requirements (sub-optimal) is found before considering all possible paths. Also, if a scenario using one proxy HA on the path in the selection is considered, there is no need to measure the distance between proxy HAs.

いずれの場合も、選択プロシージャがどちらのＨＡでも同じ結果で終わる必要がある。１つのオプションは、両方のＨＡがその選択に対して同じ入力（アドレス及び距離情報）を有し、この要件を満たすために同じ選択アルゴリズムを使用するように確保することである。しかし、両方のＨＡが、選択プロシージャにおいてポリシー情報などのローカル情報をさらに考慮の対象としなければならない場合（すなわち、両方のＨＡで出力が異なる場合）、又は、両方のＨＡで選択アルゴリズムが異なる可能性がある場合、合意結果に達するために、ＭＮとＣＮのＨＡとの間で追加のネゴシエーションが必要である。これは、ＨＡ間での追加のＯＲＴ要求／応答交換によって実現可能である。それらの交換は、それらとセッション開始交換とを区別するために、特別なフラグ（例えば、「ネゴシエーション」フラグ）でマーク付けしなければならない。各交換において、パス（すなわち、プロキシＨＡアドレスとＣｏＡの組み合わせ）が要求メッセージで他のＨＡに提案され、応答メッセージでこのパスを受け入れるか又は拒否する。要求メッセージにパスのランク付けリストを含め、受信側が応答メッセージでパスのうちの１つを選択できるようにすることも可能である。 In either case, the selection procedure should end with the same result on either HA. One option is to ensure that both HAs have the same inputs (address and distance information) for their selection and use the same selection algorithm to meet this requirement. However, if both HAs have to consider more local information such as policy information in the selection procedure (ie if both HAs have different outputs), or both HAs may have different selection algorithms If so, additional negotiation is required between the MN and the CN's HA to reach an agreement result. This can be achieved by an additional ORT request / response exchange between HAs. Those exchanges must be marked with a special flag (eg, a “negotiation” flag) to distinguish them from session initiation exchanges. In each exchange, a path (ie, a combination of proxy HA address and CoA) is proposed to the other HA in a request message and accepts or rejects this path in a response message. It is also possible to include a ranked list of paths in the request message so that the recipient can select one of the paths in the response message.

すべての可能なパスが提案された後に、合意される結果が見つけられなかった場合、又は許可された交換の事前に定義されたしきい値を超えた場合、ＯＲＴは打ち切られ、標準の双方向トンネリングが使用される。他方で、選択プロシージャが首尾よく終了し、共通の結果が見つかった場合、トンネル・エンド・ポイントは最終的に前述のように切り替えられ、データ通信に最適化ルートを使用することができる。 If no agreed outcome is found after all possible paths have been proposed, or if a predefined threshold of allowed exchanges is exceeded, the ORT is aborted and the standard bidirectional Tunneling is used. On the other hand, if the selection procedure is successfully completed and a common result is found, the tunnel end point is finally switched as described above and the optimized route can be used for data communication.

図１５は、ＨＡ制御の変形例におけるマルチホームのＭＮ及びＣＮに関する初期シグナリング流れを示す図である。 FIG. 15 is a diagram illustrating an initial signaling flow regarding multi-homed MN and CN in a modified example of HA control.

図１９ａ、図１９ｂ、及び図１９ｃでは、ＨＡ制御の変形例が流れ図の形で示される。ステップ１９０２では、ＭＮが、ＣＮとの通信に使用するためにそのＨｏＡのうちの１つを選択する。１９０４でＣＮがマルチホームである場合、１９０６でＭＮはＣＮに関する複数のＨｏＡを認識し、その後ＭＮはステップ１９０８で、ＣＮのＨｏＡのうちの１つを選択する。 In Fig. 19a, Fig. 19b and Fig. 19c, a variant of HA control is shown in the form of a flowchart. In step 1902, the MN selects one of its HoAs to use for communication with the CN. If the CN is multihomed at 1904, the MN recognizes multiple HoAs for the CN at 1906, and then the MN selects one of the CN's HoAs at step 1908.

移動ノードは、ステップ１９１０で、対象とするインターフェースに割り当てられたアドレスのうちの少なくとも１つをＣｏＡとしてＭＮのＨＡに登録する。ＭＮがステップ１９１８で、候補となるプロキシＨＡとしてそのＨＡに登録されたＨＡのすべて又はサブセットを提案できるより前に、ＭＮはステップ１９１２で、ＯＲＴ初期化要求をＭＮのＨＡに送信する。 In step 1910, the mobile node registers at least one of the addresses assigned to the target interface as CoA in the MN's HA. Before the MN can propose all or a subset of the HAs registered with that HA as candidate proxy HAs at step 1918, the MN sends an ORT initialization request to the MN's HA at step 1912.

ステップ１９２０で、ＭＮのＨＡは、ＯＲＴ初期化要求を受信し、候補となるプロキシＨＡを格納する。１９２２で、ＣＮのホーム・ネットワークが分散型である場合、ＭＮのＨＡは、１９２４でＣＮのＨｏＡに関するバインディングを管理する複数のＨＡを発見し、ＭＮはステップ１９２６で、複数のＨＡのうちの１つを選択する。ＣＮのホーム・ネットワークが分散型でない場合、ＭＮのＨＡはステップ１９２８で、ＣＮのＨｏＡに関するバインディングを管理するＨＡを発見する。 In step 1920, the MN's HA receives the ORT initialization request and stores the candidate proxy HA. At 1922, if the CN's home network is distributed, the MN's HA discovers multiple HAs that manage bindings on CN's HoA at 1924, and the MN at step 1926 selects one of the multiple HAs. Select one. If the CN's home network is not distributed, the MN's HA discovers, in step 1928, the HA that manages the binding for CN's HoA.

ステップ１９３０で、ＭＮのＨＡはＯＲＴ要求をＣＮのＨＡに送信し、候補となるプロキシＨＡとしてＣＮのＨＡに対してＨＡを提案することができる。ＣＮのＨＡがＭＮのＨＡからＯＲＴ要求を受信した場合、ＣＮのＨＡは信頼できないプロキシＨＡを選別しなければならない。ＣＮのＨＡはステップ１９３２で、ＯＲＴ初期化要求をＣＮに送信した後、ＣＮはステップ１９３４で、ＣＮのＨＡにＣｏＡとして使用されるインターフェースごとに少なくとも１つのアドレスを登録する。 In step 1930, the MN's HA can send an ORT request to the CN's HA and propose the HA to the CN's HA as a candidate proxy HA. If the CN's HA receives an ORT request from the MN's HA, the CN's HA must screen for untrusted proxy HAs. After the CN's HA sends an ORT initialization request to the CN at step 1932, the CN registers at least one address for each interface used as a CoA with the CN's HA at step 1934.

ステップ１９３６で、ＣＮはＯＲＴ初期化応答を送信し、ＣＮのＨＡに対して候補となるプロキシＨＡを提案することができる。ステップ１９３８で、ＣＮのＨＡはＯＲＴ応答を送信し、信頼できないＨＡを選別する追加の候補となるプロキシＨＡをＭＮのＨＡに対して提案することができる。ステップ１９４４でＯＲＴ初期化応答は、ＭＮのＨＡによってＭＮに送信される。 At step 1936, the CN may send an ORT initialization response to propose a candidate proxy HA for the CN's HA. At step 1938, the CN's HA may send an ORT response to propose additional candidate proxy HAs to the MN's HA to screen for untrusted HAs. In step 1944, the ORT initialization response is sent to the MN by the MN's HA.

１９４８で、ＭＮのＨＡに関するＢＵ情報、ＣＮのＨＡ、及び候補となるプロキシＨＡが以前のセッションからわからない場合、ステップ１９５０で、ＭＮのＨＡ、ＣＮのＨＡ、及び候補となるプロキシＨＡの間でＢＵ情報が交換される。ステップ１９５２で、ＭＮのＨＡ及びＣＮのＨＡから候補となるプロキシＨＡ及びＣｏＡまでのパス・セグメントの長さを確立することを含み、パス・セグメントの長さが確立される。ステップ１９５３で、プロキシＨＡ及びＣｏＡの選択が、ＭＮのＨＡ及びＣＮのＨＡ上で別個に実行される。 If the BU information about the MN's HA, the CN's HA, and the candidate proxy HA are not known from the previous session at 1948, the BU between the MN's HA, the CN's HA, and the candidate proxy HA at 1950 Information is exchanged. At step 1952, the path segment length is established, including establishing the path segment length from the MN HA and CN HA to the candidate proxy HA and CoA. At step 1953, proxy HA and CoA selection is performed separately on the MN's HA and CN's HA.

ステップ１９５４で、ＭＮのＨＡ及びＣＮのＨＡ上で同じ入力及び同じ選択アルゴリズムが使用された場合、ステップ１９５８でトンネル・エンド・ポイント切り替えが開始され、そうでない場合、ステップ１９５６で追加のネゴシエーションが実行される。 If the same input and same selection algorithm is used on the MN's HA and CN's HA at step 1954, tunnel end point switching is initiated at step 1958, otherwise additional negotiation is performed at step 1956 Is done.

それに応じてＭＮ制御の変形例におけるプロシージャが実行されるが、ＭＮとＣＮのＨＡ又はＣＮとＭＮのＨＡの間でそれぞれＯＲＴ要求／応答が交換されるという相違点がある。ＨＡ制御の変形例の場合と同様、候補となるプロキシＨＡに、ＯＲＴ要求／応答メッセージによって実行されるモビリティ・オプションを提案することができる。加えて、ＭＮ及びＣＮは、例えば、ＢＵメッセージによって実行されるモビリティ・オプションを使用して、候補となるプロキシＨＡをそれら独自のＨＡに送信する。 The procedure in the MN controlled variant is executed accordingly, with the difference that the ORT request / response is exchanged between the MN and CN HA or the CN and MN HA, respectively. As with the HA control variant, the mobility option performed by the ORT request / response message can be proposed to the candidate proxy HA. In addition, the MN and CN send candidate proxy HAs to their own HA, for example using mobility options performed by BU messages.

図１６は、ＭＮ制御の変形例におけるマルチホームのＭＮ及びＣＮに関する初期シグナリング流れを示し、図１７は、距離情報報告を候補となるプロキシＨＡに要求するためのシグナリング流れを示す。 FIG. 16 shows an initial signaling flow for multi-homed MNs and CNs in a variation of MN control, and FIG. 17 shows a signaling flow for requesting distance information reports from candidate proxy HAs.

移動性の場合、最良のパスを提供するＣｏＡとプロキシＨＡとの特定の組み合わせは変更される可能性がある。したがって、選択プロシージャは反復すべきである。これには、プロキシＨＡにおけるバインディング情報の更新と、新しい距離測定を含むことができる。 In the case of mobility, the specific combination of CoA and proxy HA that provides the best path may change. Therefore, the selection procedure should be repeated. This can include updating binding information at the proxy HA and new distance measurements.

このプロシージャの反復頻度は、前述のように選択することができる。マルチホーミングの結果として生じるオーバヘッドが増加することにより、反復頻度に応じた措置を講じなければならない。インターフェースのサブセットのみが使用される場合、又は十分良好なパスが見つかるとプロキシＨＡ選択が打ち切られる場合、シグナリングのさらなる削減を達成することができる。 The frequency of repetition of this procedure can be selected as described above. Due to the increased overhead resulting from multihoming, measures must be taken according to the repetition frequency. Further reduction in signaling can be achieved if only a subset of the interfaces are used, or if the proxy HA selection is aborted when a sufficiently good path is found.

本発明は、モバイルＩＰｖ６及びＯＲＴと同様の特性を備えた、他の移動性管理プロトコル及び位置プライバシー・プロトコルに（ある程度の変更と共に）適用可能である。 The present invention is applicable (with some changes) to other mobility management protocols and location privacy protocols with similar characteristics as Mobile IPv6 and ORT.

図１８は、ＭＮが２つのインターフェース（ＩＦ）、２つのＨｏＡ、及び３つのＣｏＡを有する、シナリオの例を示す。ＣＮは３つのインターフェース、２つのＨｏＡ、及び３つのＣｏＡを有する。ホーム・リンクは分散型ではない。このシナリオで、ＨＡ制御の変形例を使用して最適なパスを見つけるためのプロシージャの例を、以下で説明する。
・ＭＮはＣＮとの通信用に、ソースとしてＨｏＡ２_MNを、宛先アドレスとしてＨｏＡ２_CNを選択する。
・ＭＮはＨＡ２に＜ＨｏＡ２_MN，ＣｏＡ１_MN，ＣｏＡ２_MN＞を登録し、ＯＲＴ初期化要求メッセージを使用して通信セッション＜ＨｏＡ２_MN，ＨｏＡ２_CN＞に対してＨＡ２にＯＲＴを要求し、候補となるプロキシＨＡオプションを使用して候補となるプロキシＨＡアドレスとしてＨＡ１アドレスに関してＨＡ２に通知する。
・ＨＡ２は、例えば、前述のメカニズムを使用して、ＨｏＡ２_CNに関するバインディングを管理するＨＡを発見する。この結果、ＨＡ４アドレスが生じる。
・ＨＡ２はＯＲＴ要求メッセージを使用してＨＡ４にＯＲＴを要求し、候補となるプロキシＨＡオプションを使用して、候補となるプロキシＨＡとしてＨＡ１に関してＨＡ４に通知する。
・ＨＡ４は、ＯＲＴ初期化要求メッセージを使用してＣＮにＯＲＴを要求する。
・ＣＮは、ＨＡ４に＜ＨｏＡ２_CN，ＣｏＡ１_CN，ＣｏＡ２_CN，ＣｏＡ３_CN＞を登録し、ＯＲＴ初期化応答メッセージを使用してＨＡ４に応答し、候補となるプロキシＨＡオプションを使用して、候補となるプロキシＨＡとしてＨＡ３に関してＨＡ４に通知する。
・ＨＡ４はＨＡ２にＯＲＴ応答を送信し、候補となるプロキシＨＡオプションを使用して、候補となるプロキシＨＡとしてＨＡ３に関してＨＡ２に通知する。
・ＨＡ２は、ＨＡ４にバインディング情報＜ＨｏＡ２_MN，ＣｏＡ１_MN，ＣｏＡ２_MN＞を送信する。
・ＨＡ４は、ＨＡ２にバインディング情報＜ＨｏＡ２_CN，ＣｏＡ１_CN，ＣｏＡ２_CN，ＣｏＡ３_CN＞を送信する。
・ＨＡ２は、ＣｏＡまで（ＣｏＡ１_CN，ＣｏＡ２_CN，ＣｏＡ３_CN，ＣｏＡ１_MN，ＣｏＡ２_MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ４、ＨＡ３、ＨＡ１）の距離を測定し、ＨＡ１に距離情報を要求する。
・ＨＡ１は、ＣｏＡまで（ＣｏＡ１_CN，ＣｏＡ２_CN，ＣｏＡ３_CN，ＣｏＡ１_MN，ＣｏＡ２_MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ４、ＨＡ３、ＨＡ２）の距離を測定し、ＨＡ２に距離情報報告を送信する。
・ＨＡ４は、ＣｏＡまで（ＣｏＡ１_CN，ＣｏＡ２_CN，ＣｏＡ３_CN，ＣｏＡ１_MN，ＣｏＡ２_MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ３、ＨＡ１、ＨＡ２）の距離を測定し、ＨＡ３に距離情報を要求する。
・ＨＡ３は、ＣｏＡまで（ＣｏＡ１_CN，ＣｏＡ２_CN，ＣｏＡ３_CN，ＣｏＡ１_MN，ＣｏＡ２_MN）、及びオプションで候補となるプロキシＨＡまで（ＨＡ４、ＨＡ１、ＨＡ２）の距離を測定し、ＨＡ４に距離情報報告を送信する。
・ＨＡ２及びＨＡ４は距離情報を交換し、最短パスを提供するプロキシＨＡ及びＣｏＡの組み合わせを決定するための選択プロシージャを開始する。
・ＨＡ４及びＨＡ２はトンネル確立要求／通知をＭＮ／ＣＮに送信する。 FIG. 18 shows an example scenario where the MN has two interfaces (IF), two HoAs, and three CoAs. The CN has 3 interfaces, 2 HoAs, and 3 CoAs. Home links are not distributed. In this scenario, an example procedure for finding an optimal path using a variation of HA control is described below.
The MN selects HoA2 _MN as the source and HoA2 _CN as the destination address for communication with the CN.
The MN registers <HoA2 _MN , CoA1 _MN , CoA2 _MN > in HA2, requests an ORT from HA2 to the communication session <HoA2 _MN , HoA2 _CN > using the ORT initialization request message, and becomes a candidate Use the proxy HA option to notify HA2 about the HA1 address as a candidate proxy HA address.
• HA2 discovers the HA that manages the binding for HoA2 _CN using, for example, the mechanism described above. This results in an HA4 address.
HA2 requests ORT from HA4 using an ORT request message and informs HA4 about HA1 as a candidate proxy HA using a candidate proxy HA option.
• HA4 requests an ORT from the CN using an ORT initialization request message.
· CN registers the _{_{<HoA2 CN, CoA1 CN, CoA2}} CN, CoA3 CN> in HA4, in response to HA4 using ORT initialization response message and a proxy HA option as a candidate, the candidate and As a proxy HA, HA4 is notified of HA3.
HA4 sends an ORT response to HA2 and informs HA2 about HA3 as a candidate proxy HA using the candidate proxy HA option.
· HA2 transmits the binding information to _{_{HA4 <HoA2 MN, CoA1 MN,}} CoA2 MN>.
· HA4 sends binding information to _{_{HA2 <HoA2 CN, CoA1 CN,}} CoA2 CN, CoA3 CN>.
· HA2 until _{_{CoA (CoA1 CN, CoA2 CN,}} CoA3 CN, CoA1 MN, CoA2 MN), and measures the distance to the proxy HA as a candidate at option (HA4, HA3, HA1), the distance information HA1 Request.
· HA1 until _{_{CoA (CoA1 CN, CoA2 CN,}} CoA3 CN, CoA1 MN, CoA2 MN), and measures the distance to the proxy HA as a candidate at option (HA4, HA3, HA2), HA2 on the distance information report Send.
· HA4 until _{_{CoA (CoA1 CN, CoA2 CN,}} CoA3 CN, CoA1 MN, CoA2 MN), and the distance to the proxy HA as a candidate at option (HA3, HA1, HA2) were measured, the distance information to HA3 Request.
· HA3 measures the distance CoA to _{_{(CoA1 CN, CoA2 CN, CoA3}} CN, CoA1 MN, CoA2 MN), and a candidate Option to proxy HA (HA4, HA1, HA2), the distance information report to HA4 Send.
HA2 and HA4 exchange distance information and initiate a selection procedure to determine the proxy HA and CoA combination that provides the shortest path.
HA4 and HA2 send tunnel establishment request / notification to MN / CN.

次に、ＯＲＴ方法についても説明する。 Next, the ORT method will also be described.

複数のモバイル・ネットワーク（１０５、１０６、１０７、１０８）を備える移動通信システムにおける、第１の移動ノード（１０１）と通信相手移動ノード（１０２）との間でのパケット交換データ伝送のための方法であって、
ａ）第１の移動ノード及び通信相手移動ノードのそれぞれに、それぞれのホーム・ネットワーク（１０５、１０６）を割り振るステップと、
ｂ）第１の移動ノード及び通信相手移動ノードのそれぞれに、それぞれのホーム・ネットワーク内のホーム・エージェントとしてネットワーク・サーバ（１０３、１０４）を提供するステップと、
ｃ）第１の移動ノードからホーム・エージェントのうちの任意の第１の１つへの第１のデータ・トンネル（２０１、３０１）を介して、及び、ホーム・エージェントのうちの上記第１の１つから通信相手移動ノードへの第２のデータ・トンネル（２０２、３０２）を介して、それぞれ他のホーム・エージェントを通過せずに、第１の移動ノードから通信相手移動ノードへとデータ・パケットをルーティングするステップと、
を含む方法。 Method for packet-switched data transmission between a first mobile node (101) and a correspondent mobile node (102) in a mobile communication system comprising a plurality of mobile networks (105, 106, 107, 108) Because
a) allocating a respective home network (105, 106) to each of the first mobile node and the correspondent mobile node;
b) providing each of the first mobile node and the correspondent mobile node with a network server (103, 104) as a home agent in the respective home network;
c) via the first data tunnel (201, 301) from the first mobile node to any first one of the home agents and the first of the home agents The data from the first mobile node to the correspondent mobile node via the second data tunnel (202, 302) from one to the correspondent mobile node without passing through each other home agent. Routing packets,
Including methods.

第１のホーム・エージェントが第１の移動ノード（１０１）のホーム・エージェント（１０３）であり、
ｄ）通信相手移動ノードから通信相手移動ノードのホーム・エージェント（１０４）への第３のデータ・トンネル（２０３）を介して、及び、通信相手移動ノードのホーム・エージェントから第１の移動ノードへの第４のデータ・トンネル（２０４）を介して、第１の移動ノードのホーム・エージェント（１０３）を通過せずに、通信相手移動ノード（１０２）から第１の移動ノード（１０１）へとデータ・パケットをルーティングするステップをさらに含む上記の方法。 The first home agent is the home agent (103) of the first mobile node (101);
d) via the third data tunnel (203) from the correspondent mobile node to the home agent (104) of the correspondent mobile node and from the home agent of the correspondent mobile node to the first mobile node From the correspondent mobile node (102) to the first mobile node (101) without passing through the home agent (103) of the first mobile node via the fourth data tunnel (204) The above method further comprising the step of routing the data packet.

第１のホーム・エージェントが第１の移動ノード（１０１）のホーム・エージェント（１０３）であり、第１（３０１）及び第２（３０２）のデータ・トンネルが双方向トンネルであり、
ｅ）通信相手移動ノード（１０２）から第１の移動ノード（１０１）へと、第２のデータ・トンネル及び第１のデータ・トンネルを介してデータ・パケットをルーティングするステップ
をさらに含む上記の方法。 The first home agent is the home agent (103) of the first mobile node (101), the first (301) and second (302) data tunnels are bidirectional tunnels,
e) The above method further comprising routing the data packet from the correspondent mobile node (102) to the first mobile node (101) via the second data tunnel and the first data tunnel. .

ステップｃ）に先立って、
ｆ）第１の移動ノードのホーム・エージェント（１０３）から第１の移動ノード（１０１）まで、及び通信相手移動ノード（１０２）までの距離を決定するステップ（８１２）と、
ｇ）通信相手移動ノードのホーム・エージェント（１０４）から第１の移動ノード（１０１）まで、及び通信相手移動ノード（１０２）までの距離を決定するステップ（８１３）と、
ｈ）決定された距離を使用して、第１のトンネルのエンド・ポイントとして、及び第２のトンネルのスタート・ポイントとして、２つのホーム・エージェントのうちの１つを選択するステップ（８１７）と、
を含む上記の方法。 Prior to step c)
f) determining (812) the distances from the home agent (103) of the first mobile node to the first mobile node (101) and to the correspondent mobile node (102);
g) determining the distance from the home agent (104) of the correspondent mobile node to the first mobile node (101) and the correspondent mobile node (102) (813);
h) using the determined distance to select one of two home agents as an end point of the first tunnel and as a start point of the second tunnel (817); ,
Including the above method.

ステップｇ）の後、及びステップｈ）の前に、両方のホーム・エージェント間で距離情報を交換するステップ（８１４、８１５）をさらに含む上記の方法。 The above method, further comprising exchanging distance information (814, 815) between both home agents after step g) and before step h).

ステップｆ）からｈ）までが、所定の時間間隔で、又は所定回数のハンドオーバ後に反復される上記の方法。 The above method wherein steps f) to h) are repeated at predetermined time intervals or after a predetermined number of handovers.

ステップｈ）後に、トンネル確立要求又は通知メッセージ（１００１）を、第１の移動ノードのホーム・エージェントから第１の移動ノードへと送信するステップをさらに含む上記の方法。 The method as described above, further comprising, after step h), sending a tunnel establishment request or notification message (1001) from the home agent of the first mobile node to the first mobile node.

ステップｃ）に先立って、及び適用可能であればステップｆ）に先立って、
ｊ）第１の移動ノードのホーム・エージェント（１０３）から通信相手移動ノードのホーム・エージェント（１０４）へとメッセージ（８０４）を送信するステップであって、このメッセージは、第１の移動ノード及び通信相手移動ノードのホーム・アドレスを備えるステップと、
ｋ）通信相手移動ノードのホーム・エージェント（１０４）から第１の移動ノードのホーム・エージェント（１０３）へと署名付き応答（８０７）を送信するステップであって、この応答は、通信相手移動ノードのホーム・エージェントの認証識別子及び許可証明を備えるステップと、
ｌ）第１の移動ノードのホーム・エージェントと通信相手移動ノードのホーム・エージェントとの間にセキュリティ関係（８１０）を確立するステップ（８０９）と、
ｍ）上記セキュリティ関係を使用して、第１の移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報（８１１）を、第１の移動ノードのホーム・エージェントから通信相手移動ノードのホーム・エージェントへと送信するステップと、通信相手移動ノードのホーム・エージェントにバインディング・アップデート情報を格納するステップと、
をさらに含む上記の方法。 Prior to step c) and, if applicable, prior to step f),
j) sending a message (804) from the home agent (103) of the first mobile node to the home agent (104) of the correspondent mobile node, the message comprising the first mobile node and Providing the home address of the correspondent mobile node;
k) sending a signed response (807) from the home agent (104) of the correspondent mobile node to the home agent (103) of the first mobile node, the response being the correspondent mobile node Providing a home agent authentication identifier and authorization credentials;
l) establishing (809) a security relationship (810) between the home agent of the first mobile node and the home agent of the correspondent mobile node;
m) Using the above security relation, the binding update information (811) including the care-of address and home address of the first mobile node is sent from the home agent of the first mobile node to the home Transmitting to the agent, storing binding update information in the home agent of the correspondent mobile node, and
Further comprising the above method.

ステップｃ）に先立って、及び適用可能であればステップｆ）に先立って、
ｎ）第１の移動ノード（１０１）から通信相手移動ノードのホーム・エージェント（１０４）へとメッセージ（９０１）を送信するステップであって、このメッセージは、第１の移動ノード及び通信相手移動ノードのホーム・アドレスを備えるステップと、
ｏ）通信相手移動ノードのホーム・エージェントから第１の移動ノードへと署名付き応答（９０２）を送信するステップであって、この応答は、通信相手移動ノードのホーム・エージェントの認証識別子及び許可証明を備えるステップと、
ｐ）第１の移動ノードと通信相手移動ノードのホーム・エージェントとの間にセキュリティ関係（９０４）を確立するステップと、
ｑ）ステップｐ）で確立した上記セキュリティ関係を使用して、第１の移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報（９０６）を、第１の移動ノードから通信相手移動ノードのホーム・エージェントへと送信するステップと、通信相手移動ノードのホーム・エージェントにバインディング・アップデート情報を格納するステップと、
をさらに含む上記の方法。 Prior to step c) and, if applicable, prior to step f),
n) a step of transmitting a message (901) from the first mobile node (101) to the home agent (104) of the correspondent mobile node, the message comprising the first mobile node and the correspondent mobile node Providing a home address of
o) sending a signed response (902) from the home agent of the correspondent mobile node to the first mobile node, the response comprising the authentication identifier and authorization certificate of the home agent of the correspondent mobile node Comprising the steps of:
p) establishing a security relationship (904) between the first mobile node and the home agent of the correspondent mobile node;
q) Using the security relationship established in step p), the binding update information (906) including the care-of address and home address of the first mobile node is obtained from the first mobile node to the communication partner mobile node. Transmitting to the home agent; storing binding update information in the home agent of the correspondent mobile node; and
Further comprising the above method.

ステップｐ）の前に、第１の移動ノード（１０１）と通信相手移動ノードのホーム・エージェント（１０４）との間でリターン・ルータビリティ・プロシージャ（９０３）を実行するステップをさらに含む上記の方法。 The method as described above, further comprising the step of executing a return routability procedure (903) between the first mobile node (101) and the home agent (104) of the correspondent mobile node before step p) .

ｕ）それぞれのプロキシ・ホーム・エージェントのネットワークとは異なるネットワークにそれぞれが割り振られた移動ノードのバインディング情報を格納するプロキシ・ホーム・エージェントを使用して、第１の移動ノードと通信相手移動ノードとの間に、及びその逆に、パケット交換データ伝送に関する、
ｉ）第１の移動ノードから、第１の移動ノードの訪問ネットワーク内のプロキシ・ホーム・エージェントへ、通信相手移動ノードの訪問ネットワーク内のプロキシ・ホーム・エージェントへ、及び通信相手移動ノードへの、第１の移動ノード及び通信相手移動ノードのいずれのホーム・エージェントも通過しない、双方向データ・トンネルであって、プロキシ・ホーム・エージェントのうちの少なくとも１つはアクセス・ルータでない、双方向データ・トンネルと、
ｉｉ）第１の移動ノードから、第１の移動ノード又は通信相手移動ノードのいずれかの訪問ネットワーク内のプロキシ・ホーム・エージェントへ、及び通信相手移動ノードへの、第１の移動ノード及び通信相手移動ノードのいずれのホーム・エージェントも通過しない、双方向データ・トンネルと、
ｉｉｉ）第１の移動ノードから、第１の移動ノードの訪問ネットワークと通信相手移動ノードの訪問ネットワークとの間に配置されたネットワーク内のプロキシ・ホーム・エージェントへ、及び通信相手移動ノードへの、第１の移動ノード及び通信相手移動ノードのいずれのホーム・エージェントも通過しない、双方向データ・トンネルとの、
ルーティング・オプションのうちの少なくとも１つを提供するステップと、
ｖ）上記及びサブステップｉ）からｉｉｉ）に記載されたルーティング・オプションのうちの少なくとも２つの間で選択するステップ（８１６）と、
をさらに含む上記の方法。 u) using the proxy home agent storing the binding information of the mobile node each allocated to a network different from the network of each proxy home agent, and the first mobile node and the correspondent mobile node; During packet exchange and vice versa, for packet-switched data transmission,
i) from the first mobile node to the proxy home agent in the visited network of the first mobile node, to the proxy home agent in the visited network of the correspondent mobile node, and to the correspondent mobile node; A bidirectional data tunnel that does not pass through the home agent of either the first mobile node or the correspondent mobile node, wherein at least one of the proxy home agents is not an access router; Tunnel,
ii) the first mobile node and communication partner from the first mobile node to the proxy home agent in the visited network of either the first mobile node or the correspondent mobile node and to the correspondent mobile node A bidirectional data tunnel that does not pass through any of the mobile node's home agents;
iii) from the first mobile node to the proxy home agent in the network located between the visited network of the first mobile node and the visited network of the correspondent mobile node, and to the correspondent mobile node; With a bidirectional data tunnel that does not pass through the home agent of either the first mobile node or the correspondent mobile node
Providing at least one of the routing options;
v) selecting (816) between at least two of the routing options described above and in substeps i) to iii);
Further comprising the above method.

ステップｖ）及びｆ）からｈ）までが、所定の時間間隔で、又は所定回数のハンドオーバ後に、反復される、上記の方法。 The method as described above, wherein steps v) and f) to h) are repeated at predetermined time intervals or after a predetermined number of handovers.

複数のモバイル・ネットワーク（１０５、１０６、１０７、１０８）を備える移動通信システムにおいて、通信相手移動ノード（１０２）へとデータ・パケットを送信する第１の移動ノード（１０１）に対するホーム・エージェント（１０３）として働くことを実行するように構成されたネットワーク・サーバ（１３００）であって、さらにこのサーバは、上記第１の移動ノードから受信したデータ・パケットを上記通信相手移動ノードへと転送するために、上記通信相手移動ノードのホーム・エージェント（１０４）を通過せずに、上記通信相手移動ノードへ直接、データ・トンネル（２０２、３０２）を確立することを実行するように構成されるネットワーク・サーバ。 In a mobile communication system including a plurality of mobile networks (105, 106, 107, 108), a home agent (103) for a first mobile node (101) that transmits a data packet to a correspondent mobile node (102). A network server (1300) configured to perform the act of acting as a) to forward data packets received from the first mobile node to the correspondent mobile node A network configured to perform establishing a data tunnel (202, 302) directly to the correspondent mobile node without passing through the home agent (104) of the correspondent mobile node; server.

さらに、上記データ・トンネルを双方向データ・トンネル（２０２）として確立すること、上記データ・トンネルを介して上記通信相手移動ノード（１０２）からデータ・パケットを受信すること、及び上記受信したデータ・パケットを上記第１の移動ノード（１０１）へと転送することを確立するように構成された上記のネットワーク・サーバ（１３００）。 Furthermore, establishing the data tunnel as a bidirectional data tunnel (202), receiving a data packet from the correspondent mobile node (102) via the data tunnel, and receiving the received data The network server (1300) configured to establish forwarding a packet to the first mobile node (101).

さらに、
上記第１の移動ノード（１０１）まで、及び上記通信相手移動ノード（１０２）までの距離を決定し、
通信相手移動ノードのホーム・エージェントから通信相手移動ノードまで、及び第１の移動ノードまでの距離に関する情報を、通信相手移動ノードのホーム・エージェント（１０４）から受信し、
決定された距離を使用して、上記データ・パケットを転送するための２つのホーム・エージェントのうちの１つを選択する、
ように構成された上記のネットワーク・サーバ（１３００）。 further,
Determining the distance to the first mobile node (101) and to the correspondent mobile node (102);
Receiving information about the distance from the home agent of the correspondent mobile node to the correspondent mobile node and to the first mobile node from the home agent (104) of the correspondent mobile node;
Using the determined distance to select one of the two home agents for forwarding the data packet;
The network server (1300) configured as described above.

バインディング・キャッシュ（１３０７、１３０８、１３０９）を備え、
さらに、
通信相手移動ノードのホーム・エージェント（１０４）へメッセージを送信し、このメッセージは第１の移動ノード（１０１）及び通信相手移動ノード（１０２）のホーム・アドレスを備え、
通信相手移動ノードのホーム・エージェントから署名付き応答を受信し、この応答は通信相手移動ノードのホーム・エージェントの認証識別子及び許可証明を備え、
通信相手移動ノードのホーム・エージェントに対するセキュリティ関係を確立し、
通信相手移動ノードのホーム・エージェントから、上記セキュリティ関係を使用して、通信相手移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報を受信し、及びバインディング・アップデート情報をバインディング・キャッシュに格納する、
ように構成された上記のネットワーク・サーバ（１３００）。 A binding cache (1307, 1308, 1309),
further,
Sending a message to the home agent (104) of the correspondent mobile node, the message comprising the home addresses of the first mobile node (101) and the correspondent mobile node (102);
Receiving a signed response from the home agent of the correspondent mobile node, the response comprising the authentication identifier and authorization certificate of the home agent of the correspondent mobile node;
Establish a security relationship for the home agent of the correspondent mobile node,
From the home agent of the correspondent mobile node, the binding update information including the care-of address and home address of the correspondent mobile node is received using the above security relationship, and the binding update information is stored in the binding cache. To
The network server (1300) configured as described above.

さらに、トンネル確立要求又は通知メッセージを第１の移動ノード（１０１）に送信することを実行するように構成された上記のネットワーク・サーバ（１３００）。 Further, the network server (1300) above configured to perform sending a tunnel establishment request or notification message to the first mobile node (101).

さらに、
通信相手移動ノードのホーム・エージェント（１０４）からメッセージを受信し、このメッセージは第１の移動ノード（１０１）及び通信相手移動ノード（１０２）のホーム・アドレスを備え、
通信相手移動ノードのホーム・エージェントへ署名付き応答を送信し、この応答は通信相手移動ノードのホーム・エージェントの識別子及び許可証明を備え、
通信相手移動ノードのホーム・エージェントに対するセキュリティ関係を確立し、
通信相手移動ノードのホーム・エージェントへ、上記セキュリティ関係を使用して、通信相手移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報を送信する、
ように構成された上記のネットワーク・サーバ（１３００）。 further,
A message is received from the home agent (104) of the correspondent mobile node, the message comprising the home addresses of the first mobile node (101) and the correspondent mobile node (102),
Sending a signed response to the correspondent mobile node's home agent, the response comprising the identifier and authorization certificate of the correspondent mobile node's home agent;
Establish a security relationship for the home agent of the correspondent mobile node,
Sending the binding update information comprising the care-of address and home address of the correspondent mobile node to the home agent of the correspondent mobile node using the above security relationship.
The network server (1300) configured as described above.

バインディング・キャッシュ（１３０７、１３０８、１３０９）を備え、
さらに、
通信相手移動ノード（１０２）とのセキュリティ関係を確立し、
通信相手移動ノードから、上記セキュリティ関係を使用して、通信相手移動ノードの気付アドレス及びホーム・アドレスを備えるバインディング・アップデート情報を受信し、及びバインディング・アップデート情報をバインディング・キャッシュに格納する、
ように構成された上記のネットワーク・サーバ（１３００）。 A binding cache (1307, 1308, 1309),
further,
Establish a security relationship with the correspondent mobile node (102),
From the correspondent mobile node, using the above security relationship, receive binding update information comprising the care-of address and home address of the correspondent mobile node, and store the binding update information in the binding cache;
The network server (1300) configured as described above.

さらに、通信相手移動ノード（１０２）を使用してリターン・ルータビリティ・プロシージャを実行するように構成された上記のネットワーク・サーバ（１３００）。 Furthermore, the network server (1300) as described above, configured to execute a return routability procedure using the correspondent mobile node (102).

ネットワーク・サーバ（１３００）のプロセッサ（１３０１）上で実行された場合に、複数のモバイル・ネットワーク（１０５、１０６、１０７、１０８）を備える移動通信システムにおいて、通信相手移動ノード（１０２）へとデータ・パケットを送信する第１の移動ノード（１０１）に対するホーム・エージェント（１０３）として働くこと、及び、上記第１の移動ノードから受信したデータ・パケットを上記通信相手移動ノードへと転送するために、上記通信相手移動ノードのホーム・エージェント（１０４）を通過せずに、上記通信相手移動ノードへ直接、データ・トンネルを確立することを、ネットワーク・サーバに実行させる命令を格納した、コンピュータ読み取り可能記憶媒体（１３０４、１３０５、１３１０）。 When executed on the processor (1301) of the network server (1300), in a mobile communication system comprising a plurality of mobile networks (105, 106, 107, 108), data is transmitted to the correspondent mobile node (102). To act as a home agent (103) for the first mobile node (101) that transmits the packet and to forward the data packet received from the first mobile node to the correspondent mobile node Computer readable storing instructions that cause a network server to establish a data tunnel directly to the correspondent mobile node without passing through the home agent (104) of the correspondent mobile node Storage medium (1304, 1305, 1310).

略語リスト
ＡＲアクセス・ルータ
ＢＵバインディング・アップデート
ＣＮ通信相手ノード
ＣｏＡ気付アドレス
ＣＨＡ通信相手ノードのホーム・エージェント
ＣＧＡＣｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙＧｅｎｅｒａｔｅｄＡｄｄｒｅｓｓｅｓ
ＤＨＡＡＤＤｙｎａｍｉｃＨｏｍｅＡｇｅｎｔＡｄｄｒｅｓｓＤｉｓｃｏｖｅｒｙ
ＤＮＳドメイン・ネーム・システム
ＨＡホーム・エージェント
ＨＭＩＰ階層化モバイル・インターネット・プロトコル・バージョン６
ＨＮホーム・ネットワーク
ＨｏＡホーム・アドレス
ＩＫＥインターネット鍵交換
ＬＰＡ位置プライバシー・エージェント
ＬＣＳ位置プライバシー・サーバ
ＭＡＰモビリティ・アンカー・ポイント
ＭＮ移動ノード
ＯＲＣ最適化ルート・キャッシュ・プロトコル
ＯＲＴ最適化リバース・トンネリング
ｐＨＡプロキシ・ホーム・エージェント
ＲＡルータ通知
ＲＣｏＡ領域気付アドレス
ＲＯルート最適化
ＳＥＮＤＳｅｃｕｒｅＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙ
ＶｏＩＰボイス・オーバ・インターネット・プロトコル Abbreviation List AR Access Router BU Binding Update CN Communication Node CoA Care-of Address CHA Home Agent CGA Cryptographically Generated Addresses of Communication Node
DHAAD Dynamic Home Agent Address Discovery
DNS Domain Name System HA Home Agent HMIP Hierarchical Mobile Internet Protocol Version 6
HN Home Network HoA Home Address IKE Internet Key Exchange LPA Location Privacy Agent LCS Location Privacy Server MAP Mobility Anchor Point MN Mobile Node ORC Optimized Route Cache Protocol ORT Optimized Reverse Tunneling pHA Proxy Home Agent RA Router Notification RCoA Area Care-of Address RO Route Optimization SEND Secure Neighbor Discovery
VoIP Voice over Internet Protocol

双方向トンネリング・モードにおける、プロキシＨＡなしのＭＮとＣＮとの間のデータ・パスを示す図Diagram showing data path between MN and CN without proxy HA in bi-directional tunneling mode ホーム・ネットワーク内に２つの単方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオａ）Diagram showing a data path with two unidirectional tunneling proxies HA in the home network (Scenario a) ＭＮのホーム・ネットワーク内に１つの双方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｂ）Diagram showing a data path with one bi-directional tunneling proxy HA in the MN's home network (scenario b) エンティティ間の距離が異なる、図１と同じシナリオを示す図である。FIG. 2 is a diagram illustrating the same scenario as in FIG. 1 with different distances between entities. ＭＮ及びＣＮの訪問ネットワーク内に２つの単方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｃ）Diagram showing data path with two unidirectional tunneling proxies HA in MN and CN visiting networks (scenario c) ＭＮの訪問ネットワーク内に１つの共通双方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｄ）Diagram showing a data path with one common bidirectional tunneling proxy HA located in the visited network of the MN (scenario d) ＭＮ及びＣＮの訪問ネットワーク間のネットワーク内に１つの共通双方向トンネリング・プロキシＨＡが配置されたデータ・パスを示す図（シナリオｅ）Diagram showing data path with one common bidirectional tunneling proxy HA located in the network between the MN and CN visiting networks (scenario e) ＨＡ制御の変形例における、シナリオａ）〜ｅ）での初期ネゴシエーションに関するシグナリング流れを示す図The figure which shows the signaling flow regarding the initial negotiation in scenario a) -e) in the modification of HA control. ＭＮ制御の変形例における、シナリオａ）〜ｅ）での初期ネゴシエーションに関するシグナリング流れを示す図The figure which shows the signaling flow regarding the initial negotiation in scenarios a) -e) in the modification of MN control ＨＡ制御及びＭＮ制御の、シナリオａ）及びｂ）でのトンネル切り替えに関するシグナリング流れを示す図The figure which shows the signaling flow regarding the tunnel switch in scenario a) and b) of HA control and MN control ＨＡ制御の、シナリオｃ）〜ｅ）でのＢＵ交換及びトンネル切り替えに関するシグナリング流れを示す図The figure which shows the signaling flow regarding BU exchange and tunnel switching in scenario c) -e) of HA control ＭＮ制御の、シナリオｃ）〜ｅ）でのＢＵ交換及びトンネル切り替えに関するシグナリング流れを示す図The figure which shows the signaling flow regarding BU exchange and tunnel switching in scenario c) -e) of MN control ＨＡとして使用可能なネットワーク・サーバの構造を示す図The figure which shows the structure of the network server which can be used as HA ＭＮが複数のＨｏＡ及びＣｏＡを有し、ＣＮが複数のＣｏＡ及び１つのＨｏＡを有する場合の、可能なデータ・パスのサブセットを備える例示的シナリオを示す図FIG. 6 illustrates an example scenario with a subset of possible data paths when the MN has multiple HoAs and CoAs, and the CN has multiple CoAs and one HoA. ＨＡ制御の変形例における、マルチホームのＭＮ及びＣＮに関するシグナリング流れを示す図（本発明の新しい部分はイタリック体である）Diagram showing signaling flow for multihomed MN and CN in a variant of HA control (new part of the invention is italic) ＭＮ制御の変形例における、マルチホームのＭＮ及びＣＮに関するシグナリング流れを示す図（本発明の新しい部分はイタリック体である）Diagram showing signaling flow for multi-homed MN and CN in a variant of MN control (new part of the invention is italic) 候補となるプロキシＨＡに距離情報レポートを要求するためのシグナリング流れを示す図である。It is a figure which shows the signaling flow for requesting a distance information report from a proxy HA that is a candidate. ＭＮが非分散ホーム・リンクを備えた２つのＨｏＡを有し、ＣＮが分散ホーム・リンクを備えた１つのＨｏＡ及び複数のＣｏＡを有する、シナリオ例を示す図（バインディング・キャッシュ内のイタリック体エントリは新しいエントリである）Diagram showing an example scenario where the MN has two HoAs with non-distributed home links and the CN has one HoA with distributed home links and multiple CoAs (italicized entries in the binding cache) Is a new entry) マルチホーム端末のための最適化リバース・トンネリングのプロセスを示す流れ図Flow diagram showing the process of optimized reverse tunneling for multihomed terminals マルチホーム端末のための最適化リバース・トンネリングのプロセスを示す流れ図Flow diagram showing the process of optimized reverse tunneling for multihomed terminals マルチホーム端末のための最適化リバース・トンネリングのプロセスを示す流れ図Flow diagram showing the process of optimized reverse tunneling for multihomed terminals

Claims

A method for packet-switched data transmission between a multi-homed mobile node and a correspondent node in a mobile communication system comprising a plurality of mobile networks, comprising:
a) selecting by the mobile node one of its home addresses used for communication with the correspondent node (1902);
b) The mobile node is aware of at least one of a plurality of addresses assigned to the target network interface by the mobile node to the home agent of the mobile node responsible for the selected home address. Registering as an address (1910);
c) receiving and storing candidate proxy home agent addresses by the communicating node's home agent and the mobile node's home agent;
d) sending a request to the correspondent node by the home agent of the correspondent node (1932);
e) registering at least one of a plurality of addresses assigned to a target network interface by the correspondent node as a care-of address with the home agent of the correspondent node (1934);
f) At least one of the stored proxy home agent addresses and one of the mobile node's care-of addresses at both the mobile node's home agent and the correspondent node's home agent. And (1946) selecting one of the care-of addresses of the correspondent node,
g) The mobility so that the two end points of the tunnel are one of the selected proxy home agent address selected in step f) and the care-of address of the selected mobile node. Triggering (1958) the mobile node to switch the tunnel by a home agent of the node;
h) the communication so that the two end points of the tunnel are one of the selected proxy home agent address selected in step f) and the care-of address of the selected mobile node. Triggering (1958) the correspondent node to switch the tunnel by the home agent of the correspondent node;
Including methods.

The method of claim 1, wherein the request in step d) is an optimized reverse tunneling start request.

Before step d)
The step of i) transmitting the address of a candidate proxy home agent stored in the mobile node to the home agent of the mobile node and the home agent of the correspondent node is executed. the method of.

Before step d)
3) The step of transmitting the address of the candidate proxy home agent stored in the correspondent node to the home agent of the mobile node and the home agent of the correspondent node is executed. The method described.

Step i)
Sending (1912) an optimized reverse tunneling initiation request by the mobile node to its home agent;
Receiving the optimized reverse tunneling initiation request by the mobile node's home agent and storing a candidate proxy home agent address (1920);
The home agent of the mobile node finds a home agent that manages the binding related to the home address of the correspondent node (1924, 1926, 1928);
Sending (1930) an optimized reverse tunneling request by the mobile node's home agent to the home node of the found correspondent node;
The method of claim 3 comprising.

Step j)
Sending (1912) an optimized reverse tunneling start response to the home agent by the correspondent node;
Receiving the optimized reverse tunneling start response by the home agent of the correspondent node and storing a candidate proxy home agent address (1920);
Sending (1930) an optimized reverse tunneling response to the mobile node's home agent by the correspondent node's home agent;
The method of claim 4 comprising.

Step i)
Sending (1912) the address of a candidate proxy home agent to the home agent by the mobile node;
Receiving and storing candidate proxy home agent addresses by the mobile node's home agent (1920);
Finding (1924, 1926, 1928) a home agent that manages the binding related to the home address of the correspondent node by the mobile node;
Sending (1930) an optimized reverse tunneling request by the mobile node to a home agent of the found correspondent node;
The method of claim 3 comprising.

Step j)
Sending (1912) the address of a candidate proxy home agent to the home agent by the correspondent node;
Receiving (1920) and storing a candidate proxy home agent address by the home agent of the correspondent node;
Finding (1924, 1926, 1928) a home agent that manages the binding related to the home address of the mobile node by the correspondent node;
Sending (1930) an optimized reverse tunneling response to the mobile node's home agent by the correspondent node;
The method of claim 4 comprising.

9. A method as claimed in any one of claims 5 to 8 wherein, following the step of sending an optimized tunneling request or response, a candidate proxy home agent address is proposed to the respective home agent.

10. A method according to any one of claims 1 to 9, wherein step f) is performed to select the shortest path.

10. A method according to any one of the preceding claims, wherein step f) is performed to select the path with the least delay.

Before step d)
12. The method according to any one of claims 1 to 11, further comprising the step (1908) of selecting by the mobile node one of the home addresses of the correspondent nodes as a destination address.

13. The method according to any one of claims 1 to 12, further comprising the step of rejecting an untrusted proxy home agent by the mobile node's home agent.

14. The method according to any one of claims 1 to 13, further comprising the step of rejecting an untrusted proxy home agent by the correspondent node's home agent.

A mobile node of a mobile communication system for packet-switched data transmission between a multi-homed mobile node and a correspondent node,
Selecting means adapted to select one of its home addresses used for communication with said correspondent node;
Adapted to register at least one of a plurality of addresses assigned to the target network interface as a care-of address with the home agent of the mobile node responsible for the selected home address Stored means,
A mobile node comprising

A home agent of a correspondent node of a mobile communication system for packet-switched data transmission between a multi-homed mobile node and a correspondent node,
Transmission means adapted to send a request to the correspondent node;
A receiving means adapted to receive a home agent address as a proxy candidate;
Storage means adapted to store a home agent address as a proxy candidate;
Selection means adapted to select at least one of the proxy home agent address, one of the mobile node's care-of address, and one of the correspondent nodes' care-of address;
Trigger the correspondent node to switch the tunnel so that the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the correspondent node Trigger means adapted to
The home agent of the correspondent node provided.

A communication partner node of a mobile communication system for packet-switched data transmission between a multi-homed mobile node and a communication partner node,
A communicating party node comprising storage means adapted to register at least one of a plurality of addresses assigned to a target network interface as a care-of address in a home agent of the communicating node.

A mobile node home agent of a mobile communication system for packet-switched data transmission between a multi-homed mobile node and a correspondent node,
Selection means adapted to select at least one of the proxy home agent address, one of the mobile node's care-of address, and one of the correspondent nodes' care-of address;
Trigger the mobile node to switch the tunnel so that the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the correspondent node Trigger means adapted to
The mobile node's home agent.

A mobile communication system for packet-switched data transmission between a multi-homed mobile node and a correspondent node, the mobile communication system comprising:
A mobile node according to claim 15, a correspondent node according to claim 17, a home agent of the correspondent node according to claim 16, and a home agent of the mobile node according to claim 18. A mobile communication system provided.

20. A mobile communication system according to claim 19 adapted to perform the method according to claims 2-14.

When executed by the mobile node processor:
Selecting one of its home addresses used for communication with the correspondent node;
Registering at least one of a plurality of addresses assigned to a target network interface as a care-of address with a home agent of a mobile node responsible for the selected home address. ,
A computer readable medium storing instructions for causing the mobile node to perform optimized reverse tunneling for a multihomed terminal.

When executed by the home agent processor of the correspondent node:
Sending a request to the correspondent node;
Receiving a home agent address as a proxy candidate;
Storing a home agent address as a proxy candidate;
Selecting at least one of the proxy home agent address, one of the care-of address of the mobile node, and one of the care-of address of the correspondent node;
Trigger the correspondent node to switch the tunnel so that the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the correspondent node And the steps to
A computer readable medium storing instructions for causing the home agent of the correspondent node to perform optimized reverse tunneling for a multihomed terminal.

When executed by the processor of the correspondent node,
Optimized reverse tunneling for multihomed terminals by registering at least one of a plurality of addresses assigned to a target network interface as a care-of address with a home agent of the correspondent node A computer-readable medium storing a command for causing the communication partner node to execute.

When executed by the mobile node's home agent processor:
Selecting at least one of the proxy home agent address, one of the mobile node's care-of address, and one of the correspondent nodes' care-of address;
Trigger the mobile node to switch the tunnel so that the two end points of the tunnel are one of the selected proxy home agent address and the care-of address of the correspondent node Step by step
A computer readable medium storing instructions for causing the mobile agent's home agent to perform optimized reverse tunneling for a multihomed terminal.