[要約] RFC 6301は、インターネットにおける移動性サポートに関する調査をまとめたものです。このRFCの目的は、現在の移動性サポートの状況を把握し、将来の改善に向けた方向性を提供することです。
Internet Engineering Task Force (IETF) Z. Zhu
Request for Comments: 6301 UCLA
Category: Informational R. Wakikawa
ISSN: 2070-1721 Toyota ITC
L. Zhang
UCLA
July 2011
A Survey of Mobility Support in the Internet
インターネットでのモビリティサポートの調査
Abstract
概要
Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale.
過去20年にわたって、グローバルなインターネットを介したモビリティサポートのソリューションの開発に多くの努力が費やされており、さまざまな提案されたソリューションが生まれました。モビリティサポートのソリューションスペースについて全体的な理解を得るための以前の取り組みの体系的な調査を実施しました。このドキュメントは、私たちの調査結果を報告し、世界規模でユビキタスで効率的なインターネットモビリティサポートを提供する際の残りの問題を特定します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6301.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6301で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Components in Mobility Support Protocols . . . . . . . . 4
4. Existing Mobility Support Protocols . . . . . . . . . . . . . 5
4.1. Columbia Protocol . . . . . . . . . . . . . . . . . . . . 6
4.2. VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Loose Source Routing (LSR) Protocol . . . . . . . . . . . 9
4.4. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. HMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. FMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Mobility Support Using Multicast in IP (MSM-IP) . . . . . 13
4.9. Cellular IP, HAWAII, and TIMIP . . . . . . . . . . . . . . 14
4.10. E2E and M-SCTP . . . . . . . . . . . . . . . . . . . . . . 15
4.11. Host Identity Protocol . . . . . . . . . . . . . . . . . . 16
4.12. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.13. Connexion and WINMO . . . . . . . . . . . . . . . . . . . 17
4.14. ILNPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.15. Global HAHA . . . . . . . . . . . . . . . . . . . . . . . 18
4.16. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 19
4.17. Back to My Mac . . . . . . . . . . . . . . . . . . . . . . 20
4.18. LISP-Mobility . . . . . . . . . . . . . . . . . . . . . . 21
5. Different Directions towards Mobility Support . . . . . . . . 21
5.1. Routing-Based Approach versus Mapping-Based Approach . . . 22
5.2. Mobility-Aware Entities . . . . . . . . . . . . . . . . . 23
5.3. Operator-Controlled Approach versus User-Controlled
Approach . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Local and Global-Scale Mobility . . . . . . . . . . . . . 25
5.5. Other Mobility Support Efforts . . . . . . . . . . . . . . 26
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Deployment Issues . . . . . . . . . . . . . . . . . . . . 27
6.2. Session Continuity and Simultaneous Movements . . . . . . 28
6.3. Trade-Offs of Design Choices on Mobility Awareness . . . . 29
6.4. Interconnecting Heterogeneous Mobility Support Systems . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. Informative References . . . . . . . . . . . . . . . . . . . . 30
This document reports our findings from a historical survey of the Internet mobility research and standardization efforts since the early 1990s. Our survey was motivated by two factors. First, supporting mobility over the Internet has been an active research area and has produced a variety of solutions, some of which have become the Internet standards. Yet, new issues continue to arise and new solutions continue to be developed to address them, making one wonder how much more we have yet to discover about the problem space as well as the solution space. The second factor is the rapid growth in Internet access via mobile devices in recent years, which will inevitably lead to new Internet application development in the coming years and further underscore the importance of Internet mobility support. We believe that a historical review of all the proposed solutions on the table can help us not only identify their commonalities and differences but also clarify remaining issues and shed insight on future efforts.
この文書は、1990年代初頭以来のインターネットモビリティ調査と標準化の取り組みに関する歴史的調査からの調査結果を報告しています。私たちの調査は、2つの要因によって動機付けられました。第一に、インターネット上のモビリティをサポートすることは積極的な研究分野であり、さまざまなソリューションを生み出しており、その一部はインターネット標準になっています。しかし、新しい問題が発生し続け、それらに対処するために新しいソリューションが開発され続け、問題のスペースとソリューションスペースについてまだどれだけ発見していないか疑問に思います。2番目の要因は、近年のモバイルデバイスを介したインターネットアクセスの急速な成長であり、今後数年間で必然的に新しいインターネットアプリケーション開発につながり、インターネットモビリティサポートの重要性をさらに強調します。私たちは、テーブル上のすべての提案されたソリューションの歴史的レビューは、それらの共通性と違いを特定するだけでなく、残りの問題を明確にし、将来の努力に関する洞察を明らかにするのに役立つと考えています。
In this document, we provide an overview of mobility support solutions from the early results to the most recent proposals. In the process, we also discuss the essential components in mobility support and analyze the design space. Through sharing our understanding of the current stage of the art, we aim to initiate an open discussion about the general direction for future mobility support.
このドキュメントでは、初期の結果から最新の提案まで、モビリティサポートソリューションの概要を説明します。その過程で、モビリティサポートの重要なコンポーネントについても説明し、設計スペースを分析します。アートの現在の段階についての理解を共有することで、将来のモビリティサポートの一般的な方向性についてのオープンな議論を開始することを目指しています。
Note that the solutions discussed in this document are proposed designs. They have been implemented in many cases, but only a few have been widely deployed in the Internet.
このドキュメントで説明されているソリューションは、提案された設計であることに注意してください。多くの場合に実装されていますが、インターネットに広く展開されているのはごくわずかです。
This document uses the following terms to refer to the entities or functions that are required in mobility support. Readers are expected to be familiar with RFC 3753 "Mobility Related Terminology" [RFC3753] before reading this document.
このドキュメントでは、次の用語を使用して、モビリティサポートに必要なエンティティまたは機能を参照します。読者は、このドキュメントを読む前に、RFC 3753「モビリティ関連用語」[RFC3753]に精通していることが期待されています。
Identifier: A stable value that can be used to identify a mobile node. Any unique value can be used as an Identifier as long as it is topologically and geographically independent, i.e., remains unchanged when the mobile node roams around.
識別子：モバイルノードの識別に使用できる安定した値。一意の値は、トポロジー的および地理的に独立している限り、識別子として使用できます。つまり、モバイルノードが周りを歩き回っている場合は変更されません。
Locator: The IP address that indicates the mobile node's current attachment point to the Internet. It could be the IP address of the mobile node itself or the IP address of the network entity that is currently serving the mobile node.
ロケーター：モバイルノードの現在の添付ファイルポイントをインターネットに示すIPアドレス。これは、モバイルノード自体のIPアドレス、または現在モバイルノードにサービスを提供しているネットワークエンティティのIPアドレスである可能性があります。
Mapping: In this document, mapping specifically means the mapping between a mobile's Identifier and its Locator.
マッピング：このドキュメントでは、マッピングは特にモバイルの識別子とそのロケーター間のマッピングを意味します。
Rendezvous Point (RP): The place where the mapping is held. Some other functions such as data forwarding may also be co-located on the rendezvous point.
Rendezvous Point（RP）：マッピングが保持される場所。データ転送などの他のいくつかの機能は、Rendezvousポイントにも共同で開催される場合があります。
Global Mobility Management: A system that keeps track of each mobile's reachability when the mobile is moving, either geographically or topologically, on a global scale.
グローバルモビリティ管理：地理的またはトポロジー的にモバイルが移動しているときに、各モバイルの到達可能性を追跡するシステム。
Local Mobility Management: A system that keeps track of each mobile's reachability within a topologically scoped local domain. It keeps the mobile's local movements transparent to all entities that are outside of the local scope.
ローカルモビリティ管理：トポロジカルスコープされたローカルドメイン内の各モバイルの到達可能性を追跡するシステム。これにより、モバイルのローカルムーブメントは、ローカルスコープの外側にあるすべてのエンティティに対して透明になります。
Operator-Controlled Mobility Management: The mobile node itself is unaware of mobility management. Instead, certain network entities, which are controlled by the network operators, perform all the mobility-related signaling job on behalf of the mobile node.
オペレーター制御モビリティ管理：モバイルノード自体は、モビリティ管理を認識していません。代わりに、ネットワークオペレーターによって制御される特定のネットワークエンティティは、モバイルノードに代わってすべてのモビリティ関連のシグナリングジョブを実行します。
User-Controlled Mobility Management: The mobile node participates in the mobility management. Typically, the mobile updates its reachability information after it changes locations and refreshes its reachability at a user-defined frequency.
ユーザー制御モビリティ管理：モバイルノードは、モビリティ管理に参加します。通常、モバイルは、場所を変更した後に到達可能性情報を更新し、ユーザー定義の頻度でその到達可能性を再表示します。
The basic question in Internet mobility support is how to send data to a moving receiver (a mobile, in short). Note that here we do not distinguish between mobile nodes and mobile subnets. We call the host that sends data to a mobile the Correspondent Node (CN). To send data to a moving receiver M, the CN must have means to obtain M's latest IP address (solution type-1) or be able to reach M using a piece of stable information, where "stable" means that the information does not change as the mobile moves (solution type-2).
インターネットモビリティサポートの基本的な質問は、移動する受信機にデータを送信する方法です（要するに、モバイル）。ここでは、モバイルノードとモバイルサブネットを区別しないことに注意してください。データをモバイルに送信するホストを呼び出します。動いている受信機Mにデータを送信するには、CNにはMの最新のIPアドレス（ソリューションタイプ-1）を取得するための手段が必要です。モバイルが動くと（ソリューションタイプ-2）。
Among the existing solutions, a few fall under type-1, and most of them use DNS as the means to provide the CN with the mobile's most current IP address information. The rest of the existing solutions fall under type-2, which must provide the function to reach the mobile's dynamically changing location by using that unchanged Identifier of the mobile known to the CN. We can summarize all the mobility support solutions as essentially involving three basic components: o a stable Identifier for a mobile; o a Locator, which is usually an IP address representing the mobile's current location; and o a mapping between the two.
既存のソリューションの中で、いくつかはタイプ1に該当し、それらのほとんどはDNSを使用して、CNにモバイルの最新のIPアドレス情報を提供する手段として使用しています。既存のソリューションの残りの部分はタイプ2に該当し、CNに知られているモバイルの変更されていない識別子を使用して、モバイルの動的に変化する位置に到達するための関数を提供する必要があります。すべてのモビリティサポートソリューションを、本質的に3つの基本コンポーネントを含むものとして要約できます。Oモバイル用の安定した識別子。oロケーター。これは通常、モバイルの現在の場所を表すIPアドレスです。o 2つの間のマッピング。
We show in the next section that different mobility support designs are merely different approaches to provide mapping between the Identifiers and the mobiles' current IP addresses. In type-1 solutions, the stable Identifier of a mobile is its DNS name, the Locator is its current IP address, and the DNS server provides the mapping function. In type-2 solutions, because the CN must be able to reach the mobile using the stable Identifier, the Identifier itself is typically an IP address; either the network can dynamically find a path to reach the mobile or the IP address leads to the "home" of the mobile that knows the mobile's current Locator and can thus forward the CN's packets to the mobile. All the type-2 solutions face two common issues. One issue is how to carry out this forwarding task, given the original packet sent by the CN has the mobile's "home address" as the destination; the other issue is how to avoid triangle routing between the CN, the home location, and the mobile.
次のセクションでは、さまざまなモビリティサポートデザインが、識別子とモバイルの現在のIPアドレスの間でマッピングを提供するための異なるアプローチにすぎないことを示します。タイプ1ソリューションでは、モバイルの安定した識別子はDNS名、ロケーターは現在のIPアドレスであり、DNSサーバーはマッピング機能を提供します。タイプ2ソリューションでは、CNは安定した識別子を使用してモバイルに到達できる必要があるため、識別子自体は通常IPアドレスです。ネットワークがモバイルに到達するパスを動的に見つけるか、IPアドレスがモバイルの現在のロケーターを知っているモバイルの「ホーム」につながるため、CNのパケットをモバイルに転送できます。すべてのType-2ソリューションは、2つの一般的な問題に直面しています。1つの問題は、CNから送信された元のパケットにモバイルの「ホームアドレス」が目的地としてあることを考えると、この転送タスクを実行する方法です。もう1つの問題は、CN、ホームロケーション、モバイル間の三角形のルーティングを回避する方法です。
In this section, we review the existing mobility support protocols roughly in the time order, with a few exceptions where we grouped closely related protocols together for writing clarity. We briefly describe each design and point out how it implements the three basic mobility support components defined in the last section.
このセクションでは、既存のモビリティサポートプロトコルを時間順でおおよそレビューしますが、密接に関連するプロトコルを一緒にグループ化して明確にするためにグループ化したいくつかの例外を除きます。各設計について簡単に説明し、最後のセクションで定義されている3つの基本的なモビリティサポートコンポーネントをどのように実装するかを指摘します。
Figure 1 shows a list of mobility support protocols and the time they were first proposed.
図1は、モビリティサポートプロトコルのリストと、最初に提案された時間を示しています。
+----------------+-----+---------------+-----+
| Protocol Name |Year | Protocol Name |Year |
+----------------+-----+---------------+-----+
| Columbia |1991 | TIMIP |2001 |
+----------------+-----+---------------+-----+
| VIP |1991 | M-SCTP |2002 |
+----------------+-----+---------------+-----+
| LSR |1993 | HIP |2003 |
+----------------+-----+---------------+-----+
| Mobile IP |1996 | MOBIKE |2003 |
+----------------+-----+---------------+-----+
| MSM-IP |1997 | Connexion |2004 |
+----------------+-----+---------------+-----+
| Cellular IP |1998 | ILNPv6 |2005 |
+----------------+-----+---------------+-----+
| HMIP |1998 | Global HAHA |2006 |
+----------------+-----+---------------+-----+
| FMIP |1998 | PMIP |2006 |
+----------------+-----+---------------+-----+
| HAWAII |1999 | BTMM |2007 |
+----------------+-----+---------------+-----+
| NEMO |2000 | WINMO |2008 |
+----------------+-----+---------------+-----+
| E2E |2000 | LISP-Mobility |2009 |
+----------------+-----+---------------+-----+
Figure 1
図1
This protocol [Columbia] was originally designed to provide mobility support on a campus. A router called Mobile Support Station (MSS) is set up in each wireless cell and serves as the default access router for all mobile nodes in that cell. The Identifier for a mobile node is an IP address derived from a special IP prefix, and the mobile node uses this IP address regardless of the cell to which it belongs.
このプロトコル[コロンビア]は、もともとキャンパスでモビリティサポートを提供するように設計されていました。モバイルサポートステーション（MSS）と呼ばれるルーターが各ワイヤレスセルにセットアップされ、そのセル内のすべてのモバイルノードのデフォルトアクセスルーターとして機能します。モバイルノードの識別子は、特別なIPプレフィックスから派生したIPアドレスであり、モバイルノードは、属するセルに関係なくこのIPアドレスを使用します。
Each MSS keeps a tracking list of mobile nodes that are currently in its cell by periodically broadcasting beacons. The mobile replies to the MSS with a message containing its stable Identifier and its previous MSS when it receives the beacon from a new MSS. The new MSS is responsible to notify the old MSS that a mobile has left its cell. Each MSS also knows how to reach other MSSs (e.g., all MSSs could be in one multicast group, or a list of IP addresses of all MSSs could be statically configured for each MSS).
各MSSは、定期的に放送するビーコンによって現在セルにあるモバイルノードの追跡リストを保持しています。モバイルは、新しいMSSからビーコンを受信したときに、安定した識別子と以前のMSSを含むメッセージを使用してMSSに返信します。新しいMSSは、モバイルがセルを離れたことを古いMSSに通知する責任があります。また、各MSSは他のMSSSに到達する方法を知っています（たとえば、すべてのMSSSは1つのマルチキャストグループにある可能性があります。または、すべてのMSSSのIPアドレスのリストを各MSSに対して静的に構成できます）。
When a CN sends a packet to a mobile node, the packet goes to the MSS nearest to the CN (MC), which either has the mobile node in the same cell and can deliver directly or broadcasts a query to all other MSSs and gets a reply from the MSS (MM) with the mobile node. If it is the latter case, MC tunnels the packet to MM, which will finally deliver the packet to the mobile node.
CNがパケットをモバイルノードに送信すると、パケットはCN（MC）に最も近いMSSに移動します。これは、同じセルにモバイルノードがあり、直接配信するか、他のすべてのMSSSにクエリをブロードキャストして取得できます。モバイルノードを使用してMSS（MM）から返信します。後者の場合、MCはパケットをMMにトンネルし、最終的にパケットをモバイルノードに配信します。
Hence, in this scheme, CN uses the Identifier to reach the mobile. It largely avoids triangle routing because the router next to CN is mobility-aware and can intercept CN's data destined to the mobile and forward to destination MSS. Since a mobile keeps the same IP address independent from its movement, mobility does not affect TCP connections.
したがって、このスキームでは、CNは識別子を使用してモバイルに到達します。CNの隣のルーターはモビリティ認識であり、モバイルに向けて宛先MSSに転送されるCNのデータを傍受できるため、主に三角形のルーティングを回避します。モバイルは同じIPアドレスをその動きから独立しているため、モビリティはTCP接続に影響しません。
An illustration of the Columbia Protocol is shown in Figure 2.
コロンビアプロトコルの図を図2に示します。
+---------+
| |
.------>| MSS |
| | |
| +---------+
| query
|
+--------+ query +--------+
| | -------------->| |
| MSS | <------------- | MSS |
| | reply | |
+--------+ ==============>+--------+
/\ data ||
|| ||
|| \/
+--------+ +---------+
| | | |
| CN | | MN |
| | | |
+--------+ +---------+
===>: data packets
--->: signaling packets
Figure 2
図2
Virtual Internet Protocol [VIP] has two basic ideas. First, a packet carries both Identifier and Locator; second, the Identifier is an IP address that leads to the home network where the mapping is kept.
仮想インターネットプロトコル[VIP]には2つの基本的なアイデアがあります。まず、パケットには識別子とロケーターの両方が搭載されています。第二に、識別子は、マッピングが保持されるホームネットワークにつながるIPアドレスです。
The IP header is modified to allow packets sent by a mobile to carry two IP addresses: a Virtual IP address (Identifier) and a regular IP address (Locator). Every time the mobile node changes its location, it notifies the home network with its latest IP address. A mobile's virtual address never changes and can be used to support TCP connections independent of mobility.
IPヘッダーは、モバイルから送信されたパケットが2つのIPアドレス（仮想IPアドレス（識別子）と通常のIPアドレス（ロケーター））を運ぶことができるように変更されています。モバイルノードがその場所を変更するたびに、最新のIPアドレスでホームネットワークに通知します。モバイルの仮想アドレスは変更されず、モビリティとは無関係にTCP接続をサポートするために使用できます。
To deliver data to a mobile, the CN first uses the mobile's Virtual IP address as the destination IP address, i.e., the Locator is set to be the same as the Identifier. As a result, the packet goes to the home network and the Home Agent redirects the packet to mobile's current location by replacing the regular IP destination address field with the mobile's current address.
モバイルにデータを配信するために、CNはまずモバイルの仮想IPアドレスを宛先IPアドレスとして使用します。つまり、ロケーターは識別子と同じに設定されています。その結果、パケットはホームネットワークに送られ、ホームエージェントは通常のIP宛先アドレスフィールドをモバイルの現在のアドレスに置き換えることにより、パケットをモバイルの現在の場所にリダイレクトします。
To reduce triangle routing, the design lets CNs and routers learn and cache the Identifier-Locator mapping carried in the packets from mobile nodes. When a CN receives a packet from the mobile, it learns the mobile's current location from the regular IP source address field. The CN keeps the mapping and uses the Locator as the destination in future exchanges with the mobile. Similarly, if a router along the data path to a mobile finds out that the mapping carried in the packet differs from the mapping cached by the router, it changes the destination IP address field to its cached value. This router-caching solution is expected to increase the chance that packets destined to the mobile get forwarded to the mobile's current location directly, by paying a cost of having all routers examine and cache all the mobile's Identifier-Locator mappings.
三角形のルーティングを減らすために、設計により、CNSとルーターがモバイルノードからパケットに携帯される識別子ロケーターマッピングを学習およびキャッシュできます。CNがモバイルからパケットを受信すると、通常のIPソースアドレスフィールドからモバイルの現在の場所を学習します。CNはマッピングを維持し、モバイルとの将来の交換の目的地としてロケーターを使用します。同様に、モバイルへのデータパスに沿ったルーターが、パケットに搭載されているマッピングがルーターによってキャッシュされたマッピングとは異なることを発見した場合、宛先IPアドレスフィールドがキャッシュ値に変更されます。このルーターキャッシングソリューションは、すべてのルーターにすべてのモバイルの識別子ロケーターマッピングを調べてキャッシュするコストを支払うコストを支払うことにより、モバイルに向けたパケットがモバイルの現在の場所に直接転送される可能性を高めることが期待されています。
Figure 3 shows how the VIP Protocol works.
図3は、VIPプロトコルの仕組みを示しています。
,---. +-------+
/ \ | CN |
( Router)<====| |
+---------+ // \ / | |
| | // `---' +-------+
| | ,---. //
| | / \ //
| Home |<--+ Router)
| Network | \ /
| | `-+-'\\
| | | \\ ,---. +-------+
| | | \\ / \=======>| |
| | +------( Router)<------+ MN |
| | \ / | |
| | `---' +-------+
+---------+
===>: data packet
--->: location update message
Figure 3
図3
In the Loose Source Routing (LSR) Protocol [LSR], each mobile has a designated router, called a Mobile Router, that manages its mobility. The Mobile Router assigns an IP address (used as an Identifier) for each mobile it manages and announces reachability to those IP addresses. Another network entity in the LSR design is Mobile Access Station (MAS), through which a mobile gets its connectivity to the Internet. The mobile node reports the IP address of its current serving MAS (Locator) to its Mobile Router.
ルーズソースルーティング（LSR）プロトコル[LSR]では、各モバイルには、モバイルルーターと呼ばれる指定ルーターがあり、そのモビリティを管理しています。モバイルルーターは、管理する各モバイルにIPアドレス（識別子として使用）を割り当て、それらのIPアドレスに到達可能性を発表します。LSR設計のもう1つのネットワークエンティティは、モバイルアクセスステーション（MAS）であり、モバイルはインターネットに接続されます。モバイルノードは、現在のサービングMAS（ロケーター）のIPアドレスをモバイルルーターに報告します。
The CN uses the Identifier to reach the mobile node in the first place. If the CN and the mobile node are attached to the same MAS, the MAS simply forwards packets between the two (in this case CN is also mobile); otherwise, the packet from CN is routed to the Mobile Router of the mobile. The Mobile Router looks up the mappings to find the serving MAS of the mobile node and inserts the loose source routing (LSR) option into the IP header of the packet with the IP address of the MAS on it. In this way, the packet is redirected to the MAS, which then delivers the packet to the mobile. To this point, the Locator of the mobile node is already included in the LSR option, and the two parties can communicate directly by reversing the LSR option in the incoming packet. Hence, the path for the first packet from CN to the mobile is CN->Mobile Router->MAS->mobile node, and then the bidirectional path for the following packets is mobile node <->MAS<->CN.
CNは識別子を使用して、そもそもモバイルノードに到達します。CNとモバイルノードが同じMASに接続されている場合、MASは単に2つの間にパケットを転送します（この場合、CNもモバイルです）。それ以外の場合、CNからのパケットはモバイルのモバイルルーターにルーティングされます。モバイルルーターは、マッピングを検索してモバイルノードのサービングMASを見つけ、MASのIPアドレスを使用してパケットのIPヘッダーにルーズソースルーティング（LSR）オプションを挿入します。このようにして、パケットはMASにリダイレクトされ、パケットがモバイルに配信されます。この時点で、モバイルノードのロケーターはすでにLSRオプションに含まれており、2つのパーティは、着信パケットのLSRオプションを逆にすることで直接通信できます。したがって、CNからモバイルへの最初のパケットのパスはCN->モバイルルーター - > MAS->モバイルノードであり、次のパケットの双方向パスはモバイルノード<-> MAS <-> CNです。
Triangle routing is avoided by revealing the mobile's Locator to the CN in the LSR option.
Triangleルーティングは、LSRオプションでモバイルのロケーターをCNに明らかにすることで回避されます。
Figure 4 shows the basic operation of the LSR Protocol.
図4は、LSRプロトコルの基本操作を示しています。
+---------+
| |
___________________| CN |
| | |
| +---------+
V /\
+-------+ ||
|Mobile | ||
|Router | ||
| | || Reversing LSR
+---+---+ ||
| \/
| +---------+ +----------+
| LSR Inserted | |<====>| |
+------------------->| MAS | | MN |
| |----->| |
+---------+ +----------+
-->: first data packet
==>: following data packets
Figure 4
図4
The IETF began standards development in mobility support soon after the above three protocols. The first version of the Mobile IP standard was developed in 1996. Later, the IETF developed the Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] standards in 2002 and 2004, respectively. In 2010, the Mobile IPv4 standard was revised [RFC5944]. In 2009, Dual-Stack Mobile IPv4 [RFC5454] was standardized to allow a dual-stack node to use IPv4 and IPv6 home addresses and to move between IPv4 and dual-stack network infrastructures.
IETFは、上記の3つのプロトコルの直後にモビリティサポートの標準開発を開始しました。モバイルIP標準の最初のバージョンは1996年に開発されました。その後、IETFは、それぞれ2002年と2004年にモバイルIPv4 [RFC3344]およびモバイルIPv6 [RFC3775]標準を開発しました。2010年には、モバイルIPv4標準が改訂されました[RFC5944]。2009年、デュアルスタックモバイルIPv4 [RFC5454]が標準化され、デュアルスタックノードがIPv4およびIPv6ホームアドレスを使用し、IPv4とデュアルスタックネットワークインフラストラクチャ間を移動できるようにしました。
Although the three documents differ in details, the high-level design is similar. Here we use Mobile IPv6 as an example. Each mobile node has a Home Agent (HA), from which it acquires its Home Address (HoA), the Identifier. The mobile node also obtains its Locator, a Care-of Address (CoA), from its current access router. Whenever the mobile node gets a new CoA, it sends a Binding Update message to notify the Home Agent. Conceptually, Mobile IPv6 design looks similar to the VIP Protocol, with the mobile's HoA corresponding to the Virtual IP Address in VIP and the CoA corresponding to the regular IP address.
3つのドキュメントの詳細は異なりますが、高レベルの設計は似ています。ここでは、モバイルIPv6を例として使用します。各モバイルノードにはホームエージェント（HA）があり、そこから識別子であるホームアドレス（HOA）を取得します。モバイルノードは、現在のアクセスルーターからロケーターであるケアオブアドレス（COA）も取得します。モバイルノードが新しいCOAを取得するたびに、ホームエージェントに通知するバインディングアップデートメッセージを送信します。概念的には、モバイルIPv6設計はVIPプロトコルに似ており、モバイルのHOAはVIPの仮想IPアドレスに対応し、通常のIPアドレスに対応するCOAに対応しています。
The CN uses the mobile's HoA as the destination IP address when sending data to a mobile. The packets are forwarded to the Home Agent, which then encapsulates the packets to mobile node's CoA according to the mapping.
CNは、モバイルにデータを送信する際に、モバイルのHOAを宛先IPアドレスとして使用します。パケットはホームエージェントに転送され、マッピングに応じてパケットをモバイルノードのCOAにカプセル化します。
To alleviate triangle routing, the CN, if it supports Route Optimization, also keeps the mapping between the mobile's HoA and CoA. Thus, the CN can encapsulate packets to the mobile directly, without going through the Home Agent. Note that in this case, the mobile needs to update its CoA to CNs as well.
トライアングルルーティングを軽減するために、CNはルートの最適化をサポートする場合、モバイルのHOAとCOAの間のマッピングも保持します。したがって、CNは、ホームエージェントを通過することなく、パケットをモバイルに直接カプセル化できます。この場合、モバイルもCOAをCNSに更新する必要があることに注意してください。
Figure 5 illustrates the data path of Mobile IPv6 without Route Optimization.
図5は、ルートの最適化なしにモバイルIPv6のデータパスを示しています。
+---+-----+
|HoA|DATA |
+---+-----+ +-------+
+----------------------| CN |
| +------------------->| |
| | +-------+
| |
V |
+--------+
| Home | Mapping: HoA <=> CoA
| Agent |
| |
+--------+
|| /\
|| || +-------+
|| +====================| |
|| | MN |
+=======================>| |
+-----+---+---+ +-------+
|DATA |HoA|CoA|
+-----+---+---+
==>: Tunnel
-->: regular IP
Figure 5
図5
Hierarchical Mobile IP (HMIP) [RFC5380] is a simple extension to Mobile IP. It aims to improves the performance of Mobile IP by handling mobility within a local region locally. A level of hierarchy is added to Mobile IP in the following way. A Mobility Anchor Point (MAP) is responsible for handling the movements of a mobile in a local region. Simply speaking, MAP is the local Home Agent for the mobile node. The mobile node, if it supports HMIP, obtains a Regional CoA (RCoA) and registers it with its Home Agent as its current CoA; while RCoA is the Locator for the mobile in Mobile IP, it is also its regional Identifier used in HMIP. At the same time, the mobile obtains a Local CoA (LCoA) from the subnet to which it attaches. When roaming within the region, a mobile only updates the MAP with the mapping between its RCoA and LCoA. In this way, the handoff performance is usually better due to the shorter round-trip time between the mobile and the MAP, as compared to the delay between the mobile and its HA. It also reduces the burden of the Home Agents by reducing the frequency of sending updates to Home Agents.
階層モバイルIP（HMIP）[RFC5380]は、モバイルIPの単純な拡張機能です。ローカル地域内のモビリティをローカルで処理することにより、モバイルIPのパフォーマンスを向上させることを目的としています。次の方法で、モバイルIPに階層のレベルが追加されます。モビリティアンカーポイント（MAP）は、ローカル地域のモバイルの動きを処理する責任があります。簡単に言えば、MAPはモバイルノードのローカルホームエージェントです。モバイルノードは、HMIPをサポートする場合、地域COA（RCOA）を取得し、現在のCOAとしてホームエージェントとともに登録します。RCOAはモバイルIPのモバイルのロケーターですが、HMIPで使用される地域識別子でもあります。同時に、モバイルは、サブネットからアタッチされたサブネットからローカルCOA（LCOA）を取得します。地域内をローミングするとき、モバイルはRCOAとLCOAの間のマッピングでマップを更新します。このようにして、モバイルとそのHAの間の遅延と比較して、モバイルとマップの間の往復時間が短いため、ハンドオフパフォーマンスは通常より良くなります。また、ホームエージェントに更新を送信する頻度を減らすことにより、ホームエージェントの負担を軽減します。
Fast Handover for Mobile IPv6 (FMIPv6) [RFC5568] is another extension to Mobile IP, which reduces the Binding Update latency as well as the IP connectivity latency. It is not a fully fledged mobility support protocol; rather, its only purpose is to optimize the performance of Mobile IP.
モバイルIPv6（FMIPV6）[RFC5568]の高速ハンドオーバーは、モバイルIPのもう1つの拡張機能であり、IP接続レイテンシだけでなく、バインディングアップデートのレイテンシを削減します。これは、本格的なモビリティサポートプロトコルではありません。むしろ、その唯一の目的は、モバイルIPのパフォーマンスを最適化することです。
This goal is achieved by three mechanisms. First, it enables a mobile node to detect that it has moved to a new subnet while it is still connected to the current subnet by providing the new access point and the corresponding subnet prefix information. Second, a mobile node can also formulate a prospective New Care-of Address (NCoA) when it is still present on the previous link so that this address can be used immediately after it attaches to the new subnet link. Third, to reduce the Binding Update interruption, FMIP specifies a tunnel between the Previous Care-of Address (PCoA) and the NCoA. The mobile node sends a Fast Binding Update to the previous access router (PAR) after the handoff, and PAR begins to tunnel packets with PCoA as the destination to NCoA. These packets would have been dropped if the tunnel were not established. In the reverse direction, the mobile node also tunnels packets to PAR until it finishes the Binding Update process (the mobile node can only use PCoA now because the binding in HA or the correspondent nodes may have not been updated yet).
この目標は、3つのメカニズムによって達成されます。まず、モバイルノードは、新しいアクセスポイントと対応するサブネットプレフィックス情報を提供することにより、現在のサブネットに接続されている間に新しいサブネットに移動したことを検出できます。第二に、モバイルノードは、前のリンクにまだ存在する場合、前向きな新しいケアオブアドレス（NCOA）を作成することもできます。これにより、このアドレスは新しいサブネットリンクに接続した直後に使用できます。第三に、バインディングアップデートの中断を減らすために、FMIPは前の住所（PCOA）とNCOAの間のトンネルを指定します。モバイルノードは、ハンドオフ後に以前のアクセスルーター（PAR）に高速バインディングアップデートを送信し、PARはNCOAの宛先としてPCOAでトンネルパケットをトンネルし始めます。トンネルが確立されていない場合、これらのパケットはドロップされていました。逆方向には、モバイルノードはバインディングアップデートプロセスが完了するまでPARにパケットをトンネルします（モバイルノードは、HAまたは特派員ノードのバインディングがまだ更新されていないため、PCOAを使用できます）。
It is conceivable to have a group of hosts moving together. Consider vehicles such as ships, trains, or airplanes that may host a network with multiple hosts. Because Mobile IP handles mobility per host, it is not efficient when handling such mobility scenarios. Network Mobility (NEMO) [RFC3963], as a backward-compatible extension to Mobile IP, was introduced in 2000 to provide efficient support for network mobility.
ホストのグループを一緒に動かすことは考えられます。複数のホストを持つネットワークをホストする可能性のある船、電車、飛行機などの車両を検討してください。モバイルIPはホストあたりのモビリティを処理するため、このようなモビリティシナリオを処理するときは効率的ではありません。ネットワークモビリティの後方互換拡張機能として、ネットワークモビリティの後方互換拡張機能として、ネットワークモビリティ（NEMO）[RFC3963]は、ネットワークモビリティを効率的にサポートするために2000年に導入されました。
NEMO introduces a new entity called a Mobile Router (note that this is different from the "Mobile Router" in the LSR Protocol). Every mobile network has at least one Mobile Router. A Mobile Router is similar to a mobile node in Mobile IP, but instead of having a single HoA, it has one or more IP prefixes as the Identifier. After establishing a bidirectional tunnel with the Home Agent, the Mobile Router distributes its mobile network's prefixes (namely, Mobile Prefixes) through the tunnel to the Home Agent. The Mobile Prefix of a mobile network is not leaked to its access router (i.e., the access router never knows that it can reach the Mobile Prefixes via the Mobile Router). The Home Agent in turn announces the reachability to the Mobile Prefix. Packets to and from the mobile network flow through the bidirectional tunnel between the Mobile Router and the Home Agent to their destinations. Note that mobility is transparent to the nodes in the moving network.
NEMOは、モバイルルーターと呼ばれる新しいエンティティを導入します（これは、LSRプロトコルの「モバイルルーター」とは異なることに注意してください）。すべてのモバイルネットワークには、少なくとも1つのモバイルルーターがあります。モバイルルーターはモバイルIPのモバイルノードに似ていますが、単一のHOAを持つ代わりに、識別子として1つ以上のIPプレフィックスがあります。ホームエージェントとの双方向トンネルを確立した後、モバイルルーターは、モバイルネットワークのプレフィックス（つまり、モバイルプレフィックス）をトンネルからホームエージェントに配布します。モバイルネットワークのモバイルプレフィックスは、アクセスルーターに漏れていません（つまり、アクセスルーターは、モバイルルーターを介してモバイルプレフィックスに到達できることを知りません）。ホームエージェントは、モバイルプレフィックスへの到達可能性を順番に発表します。モバイルネットワークとの間のパケットは、モバイルルーターとホームエージェントの間の双方向トンネルを通って目的地に流れます。モビリティは、移動ネットワーク内のノードに対して透過的であることに注意してください。
MSM-IP [MSM-IP] stands for Mobility Support using Multicast in IP. As one can see from its name, MSM-IP leverages IP multicast routing for mobility support. In IP multicast, a host can join a group regardless of the network to which it attaches and receive packets sent to the group after its join. Thus, mobility is naturally supported in the domains where IP multicast is deployed. Note that MSM-IP does not address the issue of the feasibility of supporting mobility through IP multicast; rather, it simply shows the possibility of using IP multicast to provide mobility support once/if IP multicast is universally deployed.
MSM-IP [MSM-IP]は、IPのマルチキャストを使用してモビリティサポートを略します。その名前からわかるように、MSM-IPはモビリティサポートのためにIPマルチキャストルーティングを活用しています。IPマルチキャストでは、ホストは、結合後にグループに送信されたパケットを添付して受信するネットワークに関係なく、グループに参加できます。したがって、IPマルチキャストが展開されているドメインでは、モビリティが自然にサポートされています。MSM-IPは、IPマルチキャストを介したモビリティをサポートする可能性の問題に対処していないことに注意してください。むしろ、IPマルチキャストを使用してモビリティサポートを1回/普遍的に展開している場合、単にモビリティサポートを提供する可能性を示しています。
MSM-IP [MSM-IP] assigns each mobile node a unique multicast IP address as the Identifier. When the mobile node moves into a new network, it initiates a join to its own address, which makes the multicast router in that subnet join the multicast distribution tree. Whoever wants to communicate with the mobile node can just send the data to the mobile's multicast IP address, and the multicast routing will take care of the rest.
MSM-IP [MSM-IP]は、各モバイルノードに一意のマルチキャストIPアドレスを識別子として割り当てます。モバイルノードが新しいネットワークに移動すると、独自のアドレスへの結合を開始し、そのサブネットのマルチキャストルーターがマルチキャスト配布ツリーに結合します。モバイルノードと通信したい人は誰でも、モバイルのマルチキャストIPアドレスにデータを送信するだけで、マルチキャストルーティングが残りを処理します。
Note that, due to the nature of multicast routing, the mobile node can have the new multicast router join the group to cache packets in advance before it detaches the old one, resulting in smoother handoff.
マルチキャストルーティングの性質により、モバイルノードは、新しいマルチキャストルーターが古いものを剥離する前に事前にグループに参加して、よりスムーズなハンドオフをもたらすことができることに注意してください。
This is a group of protocols that share the common idea of setting up a host route for each mobile in the local domain. The mobile retains a stable IP address as long as it is within the local domain, and this IP address is used as a regional Identifier. The gateway router of the local domain will use this Identifier to reach the mobile node. All three protocols are intended to work with Mobile IP as a local mobility management protocol. By describing them together, we can more easily show the differences by comparison.
これは、ローカルドメイン内の各モバイルのホストルートをセットアップするという一般的なアイデアを共有するプロトコルのグループです。モバイルは、ローカルドメイン内にある限り、安定したIPアドレスを保持し、このIPアドレスは地域識別子として使用されます。ローカルドメインのゲートウェイルーターは、この識別子を使用してモバイルノードに到達します。3つのプロトコルはすべて、ローカルモビリティ管理プロトコルとしてモバイルIPを使用することを目的としています。それらを一緒に説明することで、比較すると違いをより簡単に表示できます。
Cellular IP [CIP] handles the local mobility in a network consisting of Cellular IP routers. A mobile reports the IP address of the gateway for the local network as the RCoA to its Home Agent and retains its locally assigned IP address (the regional Identifier) when it roams within the Cellular IP network. The routers in the network monitor the packets originating from mobile nodes and maintain a distributed, hop-by-hop reverse path for each mobile node. Cellular IP utilizes the paging technique from the cellular network to track the location of each mobile: idle mobile nodes send dummy packets to the gateway router with a relatively low frequency to update their reverse paths in the routers. The outdated path will not be cleared explicitly after the mobile changes its location; instead, it will be flushed by the routers if the paging timer expires before the next dummy packet comes. To reduce the paging cost, only a subset of the routers would set up a reverse path for the idle mobile nodes.
Cellular IP [CIP]は、セルラーIPルーターで構成されるネットワーク内のローカルモビリティを処理します。モバイルは、ローカルネットワークのゲートウェイのIPアドレスをホームエージェントにRCOAとして報告し、セルラーIPネットワーク内でローミングするときにローカルに割り当てられたIPアドレス（リージョナル識別子）を保持します。ネットワーク内のルーターは、モバイルノードから発生するパケットを監視し、各モバイルノードの分散型ホップバイホップリバースパスを維持します。Cellular IPは、セルラーネットワークからのページング技術を利用して各モバイルの位置を追跡します。アイドルモバイルノードは、比較的低い周波数でダミーパケットをゲートウェイルーターに送信して、ルーターの逆パスを更新します。モバイルがその位置を変更した後、時代遅れのパスは明示的にクリアされません。代わりに、次のダミーパケットが来る前にページングタイマーが期限切れになった場合、ルーターによってフラッシュされます。ページングコストを削減するために、ルーターのサブセットのみがアイドルモバイルノードの逆パスを設定します。
When a packet from the CN arrives at the gateway, the gateway initiates a controlled flooding query. If a router knows where to forward a packet, it forwards it immediately; otherwise, it forwards the packet to all its interfaces except the one from which the packet came. Due to the paging technique, this will not become a broadcast. Once the mobile receives the query, it replies with a route-update message to the gateway, and a much more precise reverse path is then maintained by all the routers along the data path, via which the gateway router forwards packets from CN to the mobile. Note that the timer value for the precise data path is much smaller than the paging timer value, in order to avoid sending duplicate data packets to multiple places if the mobile moves during the data communication.
CNからのパケットがゲートウェイに到着すると、ゲートウェイは制御された洪水クエリを開始します。ルーターがパケットをどこに転送するかを知っている場合、すぐに転送します。それ以外の場合は、パケットが来たインターフェイスを除くすべてのインターフェイスにパケットを転送します。ページングテクニックにより、これは放送にはなりません。モバイルがクエリを受信すると、ゲートウェイへのルートアップデートメッセージで返信され、データパスに沿ったすべてのルーターによってより正確な逆パスが維持され、ゲートウェイルーターはパケットをCNからモバイルに転送します。。データ通信中にモバイルが移動する場合、複数の場所に重複したデータパケットを送信しないように、正確なデータパスのタイマー値はページングタイマー値よりもはるかに小さいことに注意してください。
Similarly, Handoff-Aware Wireless Access Internet Infrastructure (HAWAII) [HAWAII] also aims to provide efficient local mobility support. Unlike Cellular IP, the route between the gateway router and the mobile is always maintained. When the mobile moves, HAWAII dynamically modifies the route to the mobile by installing a host-based forwarding entry on the routers located along the shortest path between the old and new base stations of the mobile. It is possible that a longer suboptimal routing path will be constructed (e.g., gateway router->old base station->new base station->mobile). Alternatively, a new sub-path between the mobile and the cross-over router can be established. Here, the cross-over router is the router at the intersection of two paths, one between the gateway and the old base station and the second between the old base station and the new base station. In HAWAII, the mobile only periodically sends refresh messages to the base station, and the base station along with other routers take care of the path maintenance.
同様に、ハンドオフウェアワイヤレスアクセスインターネットインフラストラクチャ（ハワイ）[ハワイ]は、効率的なローカルモビリティサポートを提供することも目指しています。セルラーIPとは異なり、ゲートウェイルーターとモバイルの間のルートは常に維持されます。モバイルが移動すると、ハワイは、モバイルの古いベースステーションと新しいベースステーションの間の最短経路に沿って位置するルーターにホストベースの転送エントリをインストールすることにより、モバイルへのルートを動的に変更します。より長い最適なルーティングパスが構築される可能性があります（たとえば、ゲートウェイルーター - >古いベースステーション - >新しいベースステーション - >モバイル）。あるいは、モバイルとクロスオーバールーターの間の新しいサブパスを確立することができます。ここでは、クロスオーバールーターは、2つのパスの交差点にあるルーターです。1つはゲートウェイと古いベースステーションの間で、2つ目は古いベースステーションと新しいベースステーションの間です。ハワイでは、モバイルは定期的にリフレッシュメッセージをベースステーションに送信し、ベースステーションと他のルーターとともにパスメンテナンスを処理します。
TIMIP [TIMIP], which stands for Terminal Independent Mobile IP, integrated the design of Cellular IP and HAWAII. On one hand, it refreshes the routing paths with dummy packets if the mobile node is idle. On the other hand, handoff within a domain results in the changes of routing tables in the routers. Besides, the IP layer is coupled with layer 2 handoff mechanisms, and special nodes can work as Mobile IP proxies for legacy mobiles that do not support Mobile IP. Thus, as long as the mobile roams within the domain, the legacy node has the same degree of mobility support as a Mobile-IP-capable node.
Timip [Timip]は、ターミナルに独立したモバイルIPを表し、Cellular IPとHawaiiの設計を統合しました。一方では、モバイルノードがアイドル状態にある場合、ダミーパケットでルーティングパスを再表示します。一方、ドメイン内のハンドオフは、ルーター内のルーティングテーブルの変更をもたらします。また、IPレイヤーはレイヤー2ハンドオフメカニズムと結合されており、特別なノードはモバイルIPをサポートしていないレガシーモバイルのモバイルIPプロキシとして機能します。したがって、モバイルがドメイン内でローミングする限り、レガシーノードはモバイルIP対応ノードと同じ程度のモビリティサポートを持っています。
E2E (End-to-End) communication [E2E] gets its name from its end-to-end architecture and is the first proposal that utilizes existing DNS service to track a mobile node's current location. The stable Identifier here is the domain name of the mobile. The mobile uses Dynamic DNS to update its current IP address in DNS servers. To keep the ongoing TCP connection unaffected by mobility, a TCP Migrate option is introduced to allow both ends to replace the IP addresses and ports in TCP 4-tuple on the fly. Thus, the CN can query DNS to obtain the current Locator of the mobile, and after the TCP connection is established, the mobile will be responsible for updating its Locator for this session.
E2E（エンドツーエンド）通信[E2E]は、エンドツーエンドアーキテクチャからその名前を取得し、既存のDNSサービスを利用してモバイルノードの現在の場所を追跡する最初の提案です。ここの安定した識別子は、モバイルのドメイン名です。モバイルは動的DNSを使用して、DNSサーバーの現在のIPアドレスを更新します。進行中のTCP接続をモビリティの影響を受けないようにするために、TCP移行オプションが導入され、両端がTCP 4タプルのIPアドレスとポートをその場で置き換えることができます。したがって、CNはDNSをクエリしてモバイルの現在のロケーターを取得でき、TCP接続が確立された後、モバイルはこのセッションのロケーターの更新を担当します。
Inspired by E2E, Mobile Stream Control Transmission Protocol (M-SCTP) [M-SCTP] was proposed in 2002. Similarly, it uses Dynamic DNS to track the mobile nodes and allows both ends to add/delete IP addresses used in Stream Control Transmission Protocol (SCTP) associations during the move.
E2Eに触発されたモバイルストリーム制御伝送プロトコル（M-SCTP）[M-SCTP]は2002年に提案されました。同様に、動的DNSを使用してモバイルノードを追跡し、ストリーム制御伝送で使用されるIPアドレスを追加/削除できるようになります。移動中のプロトコル（SCTP）関連。
The Host Identify Protocol (HIP) [RFC5201] assigns each host an Identifier made of cryptographic keys and adds a new Host Identity layer between the transport and network layers. Host Identities, which are essentially public keys, are used to identify the mobile nodes, and IP addresses are used only for routing purposes. In order to reuse the existing code, a Host Identity Tag (HIT), which is a 128-bit hash value of the Host Identity, is used in transport and other upper-layer protocols.
ホスト識別プロトコル（HIP）[RFC5201]は、各ホストが暗号化キーで作られた識別子を割り当て、輸送層とネットワーク層の間に新しいホストIDレイヤーを追加します。本質的にパブリックキーであるホストIDは、モバイルノードを識別するために使用され、IPアドレスはルーティングの目的でのみ使用されます。既存のコードを再利用するために、ホストIDの128ビットハッシュ値であるホストIDタグ（HIT）が輸送およびその他の上層層プロトコルで使用されます。
HIP can use DNS as the rendezvous point that holds the mappings between HITs and IP addresses. However, HIP by default uses its own static infrastructure Rendezvous Servers in expectation of better rendezvous service. Each mobile node has a designated Rendezvous Server (RVS), which tracks the current location of the mobile node. When a CN wants to communicate with mobile node, it queries DNS with a mobile node's HIT to obtain the IP address of the mobile node's RVS and sends out the first packet. After receiving this first packet, RVS relays it to the mobile node. The mobile node and correspondent node can then start communication on the direct path. If the mobile node moves to a new address, it notifies the CN by sending HIP UPDATE with LOCATOR parameter indicating its new IP address (Locator). Meanwhile, it also updates the mapping in RVS.
HIPは、ヒットとIPアドレスの間のマッピングを保持するランデブーポイントとしてDNSを使用できます。ただし、HIPはデフォルトで独自の静的インフラストラクチャランデブーサーバーを使用して、より良いランデブーサービスを期待しています。各モバイルノードには、モバイルノードの現在の場所を追跡する指定されたRendezvousサーバー（RVS）があります。CNがモバイルノードと通信したい場合、モバイルノードのヒットでDNSをクエリして、モバイルノードのRVのIPアドレスを取得し、最初のパケットを送信します。この最初のパケットを受信した後、RVSはモバイルノードにリレーします。モバイルノードと特派員ノードは、直接パスで通信を開始できます。モバイルノードが新しいアドレスに移動すると、新しいIPアドレス（ロケーター）を示すロケーターパラメーターでヒップアップデートを送信することにより、CNに通知されます。一方、RVのマッピングも更新します。
IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] is an extension to Internet Key Exchange (IKEv2) to support mobility and multihoming. The main purpose of MOBIKE is to allow roaming devices to keep the existing IKE and IPsec Security Associations (SAs) despite IP address changes. The mobility support in MOBIKE allows both parties to move, but it does not provide a rendezvous mechanism. In other words, simultaneous movement of both parties is not supported.
IKEV2モビリティとマルチホームプロトコル（Mobike）[RFC4555]は、モビリティとマルチホームをサポートするインターネットキーエクスチェンジ（IKEV2）の拡張です。Mobikeの主な目的は、IPアドレスの変更にもかかわらず、ローミングデバイスが既存のIKEおよびIPSECセキュリティ協会（SAS）を維持できるようにすることです。Mobikeのモビリティサポートにより、両当事者は移動できますが、ランデブーメカニズムは提供されません。言い換えれば、両当事者の同時動きはサポートされていません。
MOBIKE allows both parties to have a set of addresses, and the party that initiated the IKE_SA is responsible for deciding which pair of addresses to use. During the communication session, if the initiator wishes to change the addresses due to movement, it updates the IKE_SA with new IP addresses and also updates the IPsec SAs associated with this IKE_SA. Then it sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification to the other party. The responder then checks the local policy and updates the IP addresses in the IKE_SA with the values from the IP header. It replies to the initiator with an INFORMATIONAL response, initiates a return routability check if it wants to, and updates the IPsec SAs associated with this IKE_SA.
Mobikeは、両当事者が一連のアドレスを持つことを許可し、IKE_SAを開始した当事者は、使用するアドレスのペアを決定する責任があります。通信セッション中、イニシエーターが移動のためにアドレスを変更したい場合、新しいIPアドレスでIKE_SAを更新し、このIKE_SAに関連付けられたIPSEC SASも更新します。次に、update_sa_addresses通知を含む情報リクエストを相手に送信します。その後、Responderはローカルポリシーをチェックし、IKE_SAのIPアドレスをIPヘッダーの値で更新します。情報応答でイニシエーターに返信し、必要かどうかを返すルーティング可能性チェックを開始し、このIKE_SAに関連付けられたIPSEC SASを更新します。
MOBIKE is not a fully fledged mobility protocol, and it does not intend to be one. Nevertheless, through the use of IPsec tunnel mode, MOBIKE partially supports mobility as it can dynamically update the tunnel endpoint addresses.
Mobikeは、本格的なモビリティプロトコルではなく、1つになるつもりはありません。それにもかかわらず、IPSECトンネルモードを使用することにより、Mobikeはトンネルエンドポイントアドレスを動的に更新できるため、モビリティを部分的にサポートします。
Connexion [Boeing] was a mobility support service provided by Boeing that uses BGP to support network mobility. Every mobile network is assigned a /24 IP address prefix (stable Identifier), and the CN uses this Identifier to reach the moving network, which means that the global routing system is responsible for finding a path to the mobile network. When an airplane moves between its access routers on the ground, it withdraws its prefix from the previous access router and announces the prefix via the new access point. As a result, the location change of the plane is effectively propagated to the rest of the world. However, if the number of moving networks becomes large, the amount of BGP updates will also increase proportionally, resulting in severe global routing dynamics.
Connexion [Boeing]は、BGPを使用してネットワークモビリティをサポートするボーイングが提供するモビリティサポートサービスでした。すべてのモバイルネットワークにはA /24 IPアドレスプレフィックス（Stable Identifier）が割り当てられ、CNはこの識別子を使用して移動ネットワークに到達します。つまり、グローバルルーティングシステムはモバイルネットワークへのパスを見つける責任があります。飛行機が地面のアクセスルーター間を移動すると、以前のアクセスルーターからプレフィックスを引き出し、新しいアクセスポイントを介してプレフィックスを発表します。その結果、飛行機の位置変更は、世界の他の地域に効果的に伝播されます。ただし、移動ネットワークの数が大きくなった場合、BGP更新の量も比例して増加し、その結果、深刻なグローバルルーティングダイナミクスが生じます。
WINMO [WINMO] (which stands for Wide-Area IP Network Mobility) was introduced in 2008 to address the routing update overhead problem of Connexion. Like Connexion, WINMO also assigns each mobile network a stable prefix. However, through two new approaches, WINMO can reduce the BGP updates overhead for mobile networks by orders of magnitude lower than those of Connexion. First, WINMO uses various heuristics to reduce the propagation scope of routing updates caused by mobile movements. Consequently, not every router may know all the mobiles' current locations. Handling this issue led to the second and more fundamental approach taken by WINMO: it adopts the basic idea from Mobile IP by assigning each mobile network a "home" in the following way. WINMO assigns each mobile network a prefix out of a small set of well-defined Mobile Prefixes. These Mobile Prefixes are announced by a small set of Aggregation Routers, which also keep track of the mobile network's current locations. Therefore, these Aggregation Routers play a similar role to Home Agents in Mobile IP and can be counted on as a last resort to reach mobile networks globally.
WINMO [WINMO]（幅広いエリアIPネットワークモビリティの略）は、2008年に導入され、接続のルーティングアップデートの問題に対処しました。Connexionと同様に、Winmoは各モバイルネットワークに安定したプレフィックスを割り当てます。ただし、2つの新しいアプローチにより、WINMOはモバイルネットワークのBGP更新を継続的に削減することができます。まず、Winmoはさまざまなヒューリスティックを使用して、モバイルの動きによって引き起こされるルーティング更新の伝播範囲を削減します。その結果、すべてのルーターがすべてのモバイルの現在の場所を知っているわけではありません。この問題を処理することで、Winmoが取った2番目のより基本的なアプローチにつながりました。各モバイルネットワークを次の方法で「ホーム」に割り当てることにより、モバイルIPから基本的なアイデアを採用します。Winmoは、各モバイルネットワークに、明確に定義されたモバイルプレフィックスの小さなセットから接頭辞を割り当てます。これらのモバイルプレフィックスは、モバイルネットワークの現在の場所を追跡する小さな集約ルーターのセットによって発表されます。したがって、これらの集約ルーターは、モバイルIPのホームエージェントと同様の役割を果たし、グローバルにモバイルネットワークに到達するための最後の手段として期待できます。
To prevent frequent Interior Border Gateway Protocol (iBGP) routing updates due to the movement of mobile networks within an Autonomous System (AS), WINMO also introduces a Home Agent for the Mobile Prefixes: only a Designated BGP-speaking Router (DBR) acts as the origin of Mobile Prefixes, and mobile networks always update the addresses of their access routers (intra-AS Locators) with DBR, which resembles the binding updates in Mobile IP. Thus, packets destined to mobile networks are forwarded to DBR after they enter the border of an AS, and DBR will tunnel them to the current locations of mobile networks.
頻繁な内部境界ゲートウェイプロトコル（IBGP）ルーティングの更新を防ぐために、自律システム内のモバイルネットワークの動き（AS）の移動により、Winmoはモバイルプレフィックスのホームエージェントも導入します。モバイルプレフィックスの起源とモバイルネットワークは、モバイルIPのバインディングアップデートに似たDBRを使用して、アクセスルーター（ASロケーター内）のアドレスを常に更新します。したがって、モバイルネットワークに向けたパケットは、ASの境界に入るとDBRに転送され、DBRはモバイルネットワークの現在の場所にトンネルします。
A new BGP community attribute, which includes the mobile network's intra-AS Locator in each packet, is also defined to eliminate the triangle-routing problem caused by DBR. The border routers of the AS can tunnel packets directly to the mobile network based on the new attribute.
各パケットのモバイルネットワークのASロケーターを含む新しいBGPコミュニティ属性も、DBRによって引き起こされる三角形のルーティング問題を排除するために定義されています。ASの境界線は、新しい属性に基づいてモバイルネットワークに直接トンネルパケットをトンネルします。
ILNPv6 [ILNP] stands for Identifier-Locator Network Protocol for IPv6. The ILNPv6 packet header was deliberately made similar to the IPv6 header. Essentially, it breaks an IPv6 address into two components: high-order 64 bits as a Locator and low-order 64 bits as an Identifier. The Identifier identifies a host, instead of an interface, and is used in upper-layer protocols (e.g., TCP, FTP); on the other hand, the Locator changes with the movement of the mobile node, and a set of Locators can be associated with a single Identifier. Several new DNS resource records (RRs) are required, among which I (Identifier Record) and L (Locator Record) are most important. As in current Internet, the CN will query the DNS about the mobile's domain name to determine where to send the packet. During the movement, the mobile node uses Secure Dynamic DNS update to ensure that the Locator values stored in DNS are up to date. It also sends Locator Update messages to the CNs that are currently communicating with it. As an optimization, ILNPv6 supports soft-handoff, which allows the use of multiple Locators simultaneously to achieve smooth transition. ILNPv6 also supports mobile networks.
ILNPV6 [ILNP]は、IPv6の識別子ロケーターネットワークプロトコルの略です。ILNPV6パケットヘッダーは、IPv6ヘッダーと同様に意図的に作成されました。基本的に、IPv6アドレスを2つのコンポーネントに分割します：ロケーターとしての高次64ビットと識別子としての低次64ビット。識別子は、インターフェイスの代わりにホストを識別し、上層層プロトコル（TCP、FTPなど）で使用されます。一方、ロケーターはモバイルノードの動きとともに変化し、ロケーターのセットは単一の識別子に関連付けることができます。いくつかの新しいDNSリソースレコード（RRS）が必要であり、そのうちI（識別子レコード）とL（ロケーターレコード）が最も重要です。現在のインターネットと同様に、CNはモバイルのドメイン名に関するDNSを照会して、パケットの送信先を決定します。移動中、モバイルノードは安全な動的DNSアップデートを使用して、DNSに保存されているロケーター値が最新であることを確認します。また、現在通信しているCNSにロケーター更新メッセージを送信します。最適化として、ILNPV6はソフトハンドオフをサポートします。これにより、複数のロケーターを同時に使用してスムーズな移行を実現できます。ILNPV6はモバイルネットワークもサポートしています。
Global Home Agent to Home Agent (HAHA) [HAHA], first proposed in 2006 as an extension to Mobile IP, aims to eliminate the triangle-routing problem in Mobile IP and NEMO by distributing multiple Home Agents globally. All the Home Agents join an IP anycast group and form an overlay network. The same home prefix is announced by all the Home Agents from different locations. Each mobile node can register with any Home Agent that is closest to it. A Home Agent H that accepts the binding request of a mobile node M becomes the primary Home Agent for M and notifies all other Home Agents of the binding [M, H] so that the binding information databases for all the mobiles in all Home Agents are always synchronized. When a mobile moves, it may switch its primary Home Agent to another one that becomes closest to the mobile.
2006年にモバイルIPの拡張として最初に提案されたグローバルホームエージェント（ハハ）[ハハ]は、複数のホームエージェントをグローバルに配布することにより、モバイルIPとNEMOの三角形のルーティング問題を排除することを目指しています。すべてのホームエージェントがIP Anycastグループに参加し、オーバーレイネットワークを形成します。同じホームプレフィックスは、さまざまな場所のすべてのホームエージェントによって発表されます。各モバイルノードは、最も近いホームエージェントに登録できます。モバイルノードMのバインディングリクエストを受け入れるホームエージェントHは、Mの主要なホームエージェントになり、すべてのホームエージェントのすべての携帯電話のバインディング情報データベースが拘束力のある他のホームエージェント[M、H]に通知します。常に同期します。モバイルが移動すると、主要なホームエージェントをモバイルに最も近い別のホームエージェントに切り替えることができます。
A correspondent node sends packets to a mobile's Home Address. Because of anycast routing, the packets are delivered to the nearest Home Agent. This Home Agent then encapsulates the packets to the IP address of the primary Home Agent that is currently serving the mobile node, which will finally deliver the packets to the mobile node after striping off the encapsulation headers. In the reverse direction, this approach works exactly the same as Mobile IP. If the Home Agents are distributed widely, the triangle-routing problem is naturally alleviated without Route Optimization.
特派員ノードは、パケットをモバイルの自宅住所に送信します。Anycastルーティングのため、パケットは最寄りのホームエージェントに配信されます。このホームエージェントは、現在モバイルノードを提供しているプライマリホームエージェントのIPアドレスにパケットをカプセル化し、最終的にカプセル化ヘッダーを縞模様にした後にモバイルノードにパケットを配信します。逆方向には、このアプローチはモバイルIPとまったく同じように機能します。ホームエージェントが広く分布している場合、トライアングルルーティングの問題は、ルートの最適化なしに自然に緩和されます。
The data flow in Global HAHA is shown in Figure 6.
グローバルハハのデータフローを図6に示します。
+------+ +------+ +-----+
| HA |-------------| HA | | |
| | | | | CN |
+--+---+ +------+++----+ +-----+
| | || /\
| | || ||
| | || ||
| | || ||
+--+---+------+ || ||
| |<==============+ ||
| HA |==============================+
+-++---+
|| /\
\/ ||
+---++-+ ===>: data flow
| | ----: HA overlay network
| MN |
+------+
Figure 6
図6
Proxy Mobile IP (PMIP) [RFC5213] was proposed in 2006 to meet the interest of mobile network operators who desire to support mobility in a network rather than on mobile devices and to have tighter control on mobility support. Mobility is completely transparent to the mobile devices and is provided to legacy IP devices. PMIP introduces two new types of network nodes, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG), which together can support mobility within an operator's network without any action taken by the mobile node. LMA serves as a local Home Agent and assigns a local Home Network Prefix for each mobile node. This prefix is the Identifier for the mobile node within the PMIP domain. MAGs monitor the attaching and detaching events of the mobile node and generate Proxy Binding Update to LMA on behalf of the mobile node during handoff. After the success of binding, LMA updates the mobile node's Proxy-CoA (Locator in PMIP domain) with the IP address of the MAG that is currently serving the mobile node. The MAG then emulates the mobile node's local Home Link by advertising the mobile node's local Home Network Prefix in Router Advertisement. When roaming in the PMIP domain, the mobile node always obtains its local Home Prefix and believes that it is on a local Home Link. Within the domain, the mobile node is reached by the Identifier, and LMA tunnels packets to the mobile node according to the mapping.
Proxy Mobile IP（PMIP）[RFC5213]は、モバイルデバイスではなくネットワークでのモビリティをサポートし、モビリティサポートをより厳密に制御することを望んでいるモバイルネットワークオペレーターの関心を満たすために、2006年に提案されました。モビリティはモバイルデバイスに対して完全に透過的であり、レガシーIPデバイスに提供されています。PMIPでは、2つの新しいタイプのネットワークノード、ローカルモビリティアンカー（LMA）とモバイルアクセスゲートウェイ（MAG）を導入します。これは、モバイルノードが実行するアクションなしでオペレーターのネットワーク内でモビリティをサポートできます。LMAはローカルホームエージェントとして機能し、各モバイルノードにローカルホームネットワークプレフィックスを割り当てます。このプレフィックスは、PMIPドメイン内のモバイルノードの識別子です。MAGSは、モバイルノードのアタッチングおよびデタッチイベントを監視し、ハンドオフ中にモバイルノードに代わってLMAにプロキシバインディングアップデートを生成します。バインディングが成功した後、LMAはモバイルノードのプロキシCOA（PMIPドメインのロケーター）を、現在モバイルノードにサービスを提供しているMAGのIPアドレスで更新します。MAGは、モバイルノードのローカルホームネットワークのプレフィックスをルーター広告で宣伝することにより、モバイルノードのローカルホームリンクをエミュレートします。PMIPドメインをローミングするとき、モバイルノードは常にローカルホームプレフィックスを取得し、ローカルホームリンクにあると考えています。ドメイン内では、識別子によってモバイルノードが到達し、LMAトンネルパケットはマッピングに従ってモバイルノードに到達します。
Back to My Mac (BTMM) [RFC6281] is an engineering approach to mobility support and has been deployed since 2007 with Mac OS Leopard release. Each user gets a MobileMe account (which includes BTMM service), and Apple, Inc. provides DNS service for all BTMM users. The reachability information of the user's machine is published in DNS.
私のMACに戻る（BTMM）[RFC6281]は、モビリティサポートへのエンジニアリングアプローチであり、2007年からMac OS Leopardのリリースで展開されています。各ユーザーはMobileMeアカウント（BTMMサービスを含む）を取得し、Apple、Inc。はすべてのBTMMユーザーにDNSサービスを提供します。ユーザーマシンの到達可能性情報は、DNSで公開されています。
A mobile uses secure DNS update to dynamically refresh its current location. Each host generates an IPv6 Unique Local Address (ULA) [RFC4193] at boot time, which is stored in the DNS database as its topologically independent Identifier. The host's current IPv4 address (which is the IPv4 address of the NAT box if the host is behind a NAT) is stored in a SRV resource record [RFC2782] together with a transport port number needed for NAT traversal. Every node establishes a long-lived query (LLQ) session with the DNS server so that the DNS server can immediately notify each node when the answer to its query has changed. A host uses its Identifier in transport protocols and applications and uses UDP/IPv4 encapsulation to deliver data packets using information learned from the SRV RR. Note that the Locator here is the IPv4 address plus the transport port number and that the IPv6 address is only for identification purposes. In fact, it could be any form of Identifier (e.g., domain name); BTMM chose to use IPv6 addresses so that its implementation can reuse existing code.
モバイルは、安全なDNSアップデートを使用して、現在の場所を動的に更新します。各ホストは、Boot TimeでIPv6一意のローカルアドレス（ULA）[RFC4193）を生成します。これは、DNSデータベースにトポロジカルに独立した識別子として保存されます。ホストの現在のIPv4アドレス（ホストがNATの背後にある場合はNATボックスのIPv4アドレスです）は、SRVリソースレコード[RFC2782]とNATトラバーサルに必要な輸送ポート番号に保存されます。すべてのノードは、DNSサーバーとの長寿命クエリ（LLQ）セッションを確立し、DNSサーバーがクエリへの回答が変更されたときに各ノードを直ちに通知できるようにします。ホストは、輸送プロトコルとアプリケーションでその識別子を使用し、UDP/IPv4カプセル化を使用して、SRV RRから学習した情報を使用してデータパケットを提供します。ここのロケーターはIPv4アドレスと輸送ポート番号であり、IPv6アドレスは識別目的のみを目的としていることに注意してください。実際、それはあらゆる形態の識別子（例：ドメイン名）である可能性があります。BTMMは、IPv6アドレスを使用して、その実装が既存のコードを再利用できるようにすることを選択しました。
BTMM is currently used by millions of subscribers. It is simple and easy to deploy. However, the current applications use BTMM service in a "stop-and-reconnect" fashion. It remains to be seen how well BTMM can support continuous communications while hosts are on the move, for example, as needed for voice calls.
BTMMは現在、数百万人の加入者が使用しています。シンプルで展開しやすいです。ただし、現在のアプリケーションでは、「ストップアンドリコネクト」ファッションでBTMMサービスを使用しています。たとえば、音声通話に必要に応じて、ホストが移動している間、BTMMが継続的な通信をどれだけうまくサポートできるかはまだ不明です。
Figure 7 shows the basic architecture of BTMM.
図7は、BTMMの基本アーキテクチャを示しています。
DDNS update +--------+ DDNS update
+--------------->| |<-------+
| | DNS | |
| LLQ | | LLQ |
| +---------->| |<----+ |
| | | | | |
| | +--------+ | |
| | | | +---------+
| V +---+--+----+ | |
++-------+ | +-------| |
|Endhost1| Tunnel | NAT +------>|Endhost2 |
| |<=====================================>| |
+--------+ | | | |
+-----------+ +---------+
Figure 7
図7
LISP-Mobility [LISP-Mobility] is a relatively new design. Its designers hope to utilize functions and services provided by Locator/ID Separation Protocol (LISP) [LISP], which is designed for Internet routing scalability, to support mobility as well. Conceptually, LISP-Mobility may seem similar to some protocols we have mentioned so far, such as ILNPv6 and Mobile IP. Lightweight Ingress Tunnel Router and Egress Tunnel Router functions are implemented on each mobile node, and all the packets to and from the mobile node are processed by the two router functions (so the mobile node looks like a LISP site). Each mobile node is assigned a static Endpoint ID, as well as a preconfigured Map-Server. When a mobile node roams into a network and obtains a new Routing Locator, it updates its Routing Locator set in the Map-Server, and it also clears the cached Routing Locator in the Ingress Tunnel Routers or Proxy Tunnel Routers of the CNs. Thus, the CN can always learn the up-to-date location of the mobile node by the resolution of the mobile node's Endpoint ID, either issued by itself or issued after receiving the notification from the mobile node about the staled cache. The data would always travel through the shortest path. Note that both Endpoint IDs and Routing Locators are essentially IP addresses.
Lisp-Mobility [Lisp-Mobility]は比較的新しいデザインです。その設計者は、モビリティをサポートするために、インターネットルーティングのスケーラビリティ向けに設計されたロケーター/ID分離プロトコル（LISP）[LISP]によって提供される機能とサービスを利用したいと考えています。概念的には、LISPモビリティは、ILNPv6やモバイルIPなど、これまでに言及した一部のプロトコルに似ているように見えるかもしれません。軽量のイングレストンネルルーターと出口トンネルルーター機能は、各モバイルノードに実装されており、モバイルノードのすべてのパケットが2つのルーター機能によって処理されます（モバイルノードはLISPサイトのように見えます）。各モバイルノードには、静的エンドポイントIDと、事前に設定されたマップサーバーが割り当てられます。モバイルノードがネットワークにローミングして新しいルーティングロケーターを取得すると、マップサーバーに設定されたルーティングロケーターを更新し、CNSのイングレストンネルルーターまたはプロキシトンネルルーターのキャッシュされたルーティングロケーターもクリアします。したがって、CNは、モバイルノードのエンドポイントIDの解像度によって、モバイルノードの解像度によって常にモバイルノードの最新の場所を常に学習できます。これは、スターレッドキャッシュに関するモバイルノードから通知を受信した後に発行されるか、発行されます。データは常に最短パスを通過します。エンドポイントIDとルーティングロケーターの両方が本質的にIPアドレスであることに注意してください。
After studying various existing protocols, we identified several different directions for mobility support.
さまざまな既存のプロトコルを研究した後、モビリティサポートのためのいくつかの異なる方向を特定しました。
All existing mobility support designs can be broadly classified into two basic approaches. The first one is to support mobility through dynamic routing. In such designs, a mobile keeps its IP address regardless of its location changes; thus, the IP address can be used both to identify the mobile and to deliver packets to it. As a result, these designs do not need an explicit mapping function. Rather, the routing system must continuously keep track of a mobile's movements and reflect its current position in the network on the routing table so that at any given moment packets carrying the (stable) receiver's IP address can be delivered to the right place.
既存のすべてのモビリティサポート設計は、2つの基本的なアプローチに広く分類できます。1つ目は、動的ルーティングを通じてモビリティをサポートすることです。このような設計では、モバイルは場所の変更に関係なくIPアドレスを保持します。したがって、IPアドレスを使用して、モバイルを識別し、パケットを配信するために使用できます。その結果、これらの設計では明示的なマッピング機能は必要ありません。むしろ、ルーティングシステムは、モバイルの動きを継続的に追跡し、ルーティングテーブルのネットワーク内の現在の位置を反映する必要があります。これにより、（安定した）レシーバーのIPアドレスを運ぶパケットを適切な場所に配信できるようにします。
It is also worthwhile to identify two sub-classes in routing-based approaches. One is broadcast based, and the other is path based. In the former case, either the mobile's location information is actively broadcasted to the whole network or a proactive broadcast query is needed to obtain the location information of a mobile (e.g., Columbia and Connexion); in the latter case, on the other hand, a host-based path is maintained by the routing system instead (e.g., Cellular IP, HAWAII, and TIMIP).
また、ルーティングベースのアプローチで2つのサブクラスを特定することも価値があります。1つは放送ベースで、もう1つはパスベースです。前者の場合、モバイルの位置情報がネットワーク全体に積極的にブロードキャストされるか、モバイルの位置情報（コロンビアや接続など）を取得するためにプロアクティブなブロードキャストクエリが必要です。一方、後者の場合、代わりにルーティングシステムによってホストベースのパスが維持されます（たとえば、Cellular IP、Hawaii、Timip）。
Supporting mobility through dynamic routing is conceptually simple; it can also provide robust and efficient data delivery, assuming that the routing system can keep up with the mobile movements. However, because either the whole network must be informed of every movement by every mobile or a host-based path must be maintained for every mobile host, this approach is feasible only in small-scale networks with a small number of mobiles; it does not scale well in large networks or for a large number of mobiles.
動的ルーティングによるモビリティをサポートすることは、概念的に簡単です。また、ルーティングシステムがモバイルの動きに追いつくことができると仮定して、堅牢で効率的なデータ配信を提供することもできます。ただし、ネットワーク全体にすべてのモバイルまたはホストベースのパスがすべてのモバイルホストに対して維持される必要があるため、このアプローチは少数のモバイルを持つ小規模ネットワークでのみ実行可能です。大規模なネットワークや多数の携帯電話では十分に拡張されません。
The second approach to mobility support is to provide a mapping between a mobile's stable Identifier and its dynamically changing IP address. Instead of notifying the world on every movement, a mobile only needs to update a single binding location about its location changes. In this approach, if one level of indirection at IP layer is used, as in the case of Mobile IP, it has a potential side effect of introducing triangle routing; otherwise, if the two end nodes are aware of each other's movement, it means that both ends have to support the same mobility protocol.
モビリティサポートへの2番目のアプローチは、モバイルの安定した識別子と動的に変化するIPアドレスとの間のマッピングを提供することです。すべてのムーブメントで世界に通知する代わりに、モバイルは、その場所の変更に関する単一のバインディング場所を更新するだけでいいです。このアプローチでは、モバイルIPの場合のように、IPレイヤーでの1つのレベルの間接が使用される場合、三角形ルーティングを導入する潜在的な副作用があります。それ以外の場合、2つのエンドノードが互いの動きを認識している場合、それは両端が同じモビリティプロトコルをサポートする必要があることを意味します。
Yet, there is the third case in which the protocols combine the above approaches in the hope of keeping the pros and eliminating some cons of the two. WINMO is a typical protocol in this case.
しかし、プロトコルが上記のアプローチを組み合わせて、長所を維持し、2つの短所を排除することを期待して、上記のアプローチを組み合わせる3番目のケースがあります。この場合のWinmoは典型的なプロトコルです。
In Figure 8, we show the classification of the existing protocols according to the above analysis.
図8では、上記の分析に従って既存のプロトコルの分類を示しています。
+---------------+-------------------------------------------+
| | VIP, LSR, Mobile IP, HMIP, NEMO, E2E, |
| Mapping-based | M-SCTP, ILNPv6, HIP, FMIP, PMIP, |
| | BTMM, GLOBAL HAHA, LISP-Mobility |
+---------------+-------------------------------------------+
| | Columbia, Connexion |
| Routing-based +-------------------------------------------+
| | Cellular IP, HAWAII, TIMIP, MSM-IP |
+---------------+-------------------------------------------+
| Combination | WINMO |
+---------------+-------------------------------------------+
Figure 8
図8
Among the various design choices, a critical one is how many entities are assumed to be mobility-aware. There are four parties that may be involved during a conversation with a mobile: the mobile itself, CN, the network, and the Home Agent or its equivalent (additional component to the existing IP network that holds the mapping). We mainly focus our discussion on the mapping-based approach here.
さまざまな設計の選択肢の中で、重要なものは、モビリティが認識されると想定されるエンティティの数です。モバイルとの会話中に関与する可能性のある4つのパーティーがあります：モバイル自体、CN、ネットワーク、ホームエージェントまたはその同等の（マッピングを保持する既存のIPネットワークの追加コンポーネント）。ここでは、主にマッピングベースのアプローチに関する議論を焦点を当てています。
The first design choice is to hide the mobility from the CN, based on the assumption that the CN may be the legacy node that does not support mobility. In this approach, the IP address that is used as the mobile's Identifier points to the Home Agent or its equivalent that keeps track of the mobile's current location. If a correspondent node wants to send packets to a mobile node, it sets in the destination field of IP header an IP address, which is a mobile's Identifier. The packets will be delivered to the location where the mapping information of the mobile is kept, and later they will be forwarded to the mobile's current location via either encapsulation or destination address translation. Mobile IP and most of its extensions, as well as several other protocols fall into this design.
最初の設計の選択は、CNがモビリティをサポートしないレガシーノードである可能性があるという仮定に基づいて、CNからモビリティを隠すことです。このアプローチでは、モバイルの識別子として使用されるIPアドレスは、モバイルの現在の場所を追跡するホームエージェントまたはその同等物を指します。特派員ノードがパケットをモバイルノードに送信する場合、IPヘッダーの宛先フィールドにIPアドレスを設定します。これはモバイルの識別子です。パケットは、モバイルのマッピング情報が保持される場所に配信され、後でカプセル化または宛先アドレスの翻訳を介してモバイルの現在の場所に転送されます。モバイルIPとその拡張機能のほとんど、および他のいくつかのプロトコルはこの設計に分類されます。
The second design choice is to hide the mobility from the mobile and CN, which is based on a more conservative assumption that both the mobile and the CN do not support mobility. Protocols like PMIP and TIMIP adopt this design. The protocol operations in this design resemble those in the first category, but a significant difference is that here the mobility-related signaling (e.g., the update Locator to the Home Agent) is handled by the entities in the network rather than by the mobile itself. Hence, the mobile blissfully assumes that it is always in the same subnet.
2番目の設計の選択は、モバイルとCNからモビリティを隠すことです。これは、モバイルとCNの両方がモビリティをサポートしていないというより保守的な仮定に基づいています。PMIPやTIMIPなどのプロトコルは、この設計を採用しています。この設計のプロトコル操作は、最初のカテゴリのプロトコル操作に似ていますが、ここでは、モビリティ関連のシグナリング（ホームエージェントへの更新ロケーター）がモバイル自体ではなくネットワーク内のエンティティによって処理されることです。。したがって、モバイルは、それが常に同じサブネットにあると至福に想定しています。
The third one is to let both the mobile and the CN be mobility-aware. As a result, the network is not aware of the mobility, and no additional component is required. As an increasing number of mobile devices are connected to the Internet (Why hide mobility from them?), this design choice seems to be more and more appealing. One common approach taken by this design is to use DNS to keep track of mobiles' current locations. Mobiles use dynamic DNS updates to keep their DNS servers updated with their current locations. This approach re-utilizes the DNS infrastructure, which is ubiquitous and quite reliable, and makes the mobility support protocol simple and easy to deploy. Protocols like E2E, ILNP, and BTMM fall into this design. Although HIP adds special-purpose rendezvous servers to the network to replace the role of DNS, both mobile and CN are still mobility-aware; hence, it is also classified in this category.
3番目は、モバイルとCNの両方をモビリティアウェアにすることです。その結果、ネットワークはモビリティを認識しておらず、追加のコンポーネントは必要ありません。ますます多くのモバイルデバイスがインターネットに接続されているため（なぜモビリティを隠すのか？）、この設計の選択はますます魅力的であるようです。この設計で取られた一般的なアプローチの1つは、DNSを使用して、モバイルの現在の場所を追跡することです。モバイルは動的なDNSアップデートを使用して、現在の場所でDNSサーバーを更新し続けます。このアプローチは、ユビキタスで非常に信頼性が高いDNSインフラストラクチャを再利用し、モビリティサポートプロトコルをシンプルで展開しやすくします。E2E、ILNP、BTMMなどのプロトコルは、この設計に分類されます。HIPはDNSの役割を置き換えるために特別な目的のランデブーサーバーをネットワークに追加しますが、モバイルとCNの両方が依然としてモビリティ認識です。したがって、このカテゴリにも分類されています。
Figure 9 shows the three categories of protocols.
図9は、プロトコルの3つのカテゴリを示しています。
+-------------+----------------------------------+
| Design 1 | VIP, LSR, Mobile IP, HMIP, NEMO, |
| | Global HAHA |
+-------------+----------------------------------+
| Design 2 | PMIP, TIMIP |
+-------------+----------------------------------+
| Design 3 | E2E, M-SCTP, ILNPv6, HIP, |
| | BTMM, LISP-Mobility |
+-------------+----------------------------------+
Figure 9
図9
At the time of this writing, cellular networks are providing the largest operational global mobility support, using a service model that bundles together device control, network access control, and mobility support. The tremendous success of the cellular market speaks loudly that the current cellular service model is a viable one and is likely to continue into the foreseeable future. Consequently, there is a strong advocate in the IETF that we continue the cellular way of handling mobility, i.e., instead of letting mobile devices participate in the mobility-related signaling themselves, the network entities deployed by the operators should take care of any and all signaling processes of mobility support. A typical example along this direction is Proxy Mobile IP, in which LMA works together with MAGs to assure the reachability to the mobile using its Home Prefixes, as long as the mobile roams within the same provider's domain.
この執筆時点で、セルラーネットワークは、デバイス制御、ネットワークアクセス制御、モビリティサポートをまとめるサービスモデルを使用して、最大の運用上のグローバルモビリティサポートを提供しています。セルラー市場の途方もない成功は、現在の携帯電話サービスモデルが実行可能なモデルであり、近い将来に続く可能性が高いことを大声で語っています。その結果、IETFには、モビリティの処理方法を継続すること、つまりモバイルデバイスがモビリティ関連のシグナリングに参加できるようにする代わりに、オペレーターが展開するネットワークエンティティがすべての世話をする必要があるという強力な支持者がいます。モビリティサポートのシグナリングプロセス。この方向に沿った典型的な例は、モバイルIPのプロキシモバイルIPです。LMAはMAGと協力して、同じプロバイダーのドメイン内でモバイルがローミングする限り、自宅の接頭辞を使用してモバイルへの到達可能性を保証します。
One main reason for this approach is perhaps backward compatibility. By not requiring the participation of mobiles in the control-signaling process, it avoids any changes to the mobile nodes so that the mobile nodes can stay simple and all the legacy nodes can obtain the same level of mobility services as the latest mobile devices. According to the claim of 3G vendors and operators, transparent mobility support is a key aspect for success as they learn from their deployment experience.
このアプローチの主な理由の1つは、おそらく後方互換性です。制御シグナル伝達プロセスへの携帯電話の参加を必要としないことにより、モバイルノードの変更を回避して、モバイルノードがシンプルであり、すべてのレガシーノードが最新のモバイルデバイスと同じレベルのモビリティサービスを取得できるようにします。3Gベンダーとオペレーターの主張によれば、透明なモビリティサポートは、展開の経験から学ぶための成功の重要な側面です。
On the other hand, most of the mobility support protocols surveyed in this document focus on mobility support only, assuming mobiles already obtained network access. Mobile nodes typically update their locations themselves to the rendezvous points chosen by the users, and, of course, only the nodes implementing one of these solutions can benefit from mobility support. However, this class of protocols does offer users and mobile devices more flexibility and freedom, e.g., they can choose whatever mobility services are available as long as their software supports that protocol, and they can also tune the parameters to get the services that are most suitable to them.
一方、このドキュメントで調査されたモビリティサポートプロトコルのほとんどは、モバイルがすでにネットワークアクセスを取得していると仮定して、モビリティサポートのみに焦点を当てています。通常、モバイルノードは、ユーザーが選択したランデブーポイントにロケーション自体を更新し、もちろん、これらのソリューションの1つを実装するノードのみがモビリティサポートから利益を得ることができます。ただし、このクラスのプロトコルは、ユーザーとモバイルデバイスにより柔軟性と自由度を高めます。たとえば、ソフトウェアがそのプロトコルをサポートする限り、利用可能なモビリティサービスを選択できます。また、パラメーターを調整して最も多くのサービスを取得することもできます。彼らに適しています。
The work done on mobility management can also be divided into two categories according to scale: local mobility management and global mobility management.
モビリティ管理で行われた作業は、スケールに応じて2つのカテゴリに分類することもできます。ローカルモビリティ管理とグローバルモビリティ管理です。
Global mobility management is typically supposed to support mobility of an unlimited number of nodes in a geographically as well as topologically large area. Consequentially, it pays a lot of attention to scalability issues. For the availability concern, it also tries to avoid failure of single point.
グローバルモビリティ管理は、通常、地理的にもトポロジカルな領域でも、無制限の数のノードのモビリティをサポートすることになっています。その結果、スケーラビリティの問題に多くの注意を払っています。可用性の懸念のために、単一ポイントの失敗を避けようとします。
Local mobility management, on the other hand, is designed to work together with global mobility management and thus focuses more on performance issues, such as handoff delay, handoff loss, local data path, etc. Since it is typically used on a small scale with a not-so-large number of mobile nodes, sometimes the designers can use some fine-tuned mechanisms that are not scaled with a large network (such as host route) to improvement performance. As a side effect of local mobility management, the number of location updates sent by mobile nodes to their global rendezvous points is substantially reduced. Thus, the existence of local mobility management also contributes to the scalability of global mobility management.
一方、ローカルモビリティ管理は、グローバルモビリティ管理と協力するように設計されているため、ハンドオフ遅延、ハンドオフ損失、ローカルデータパスなどのパフォーマンスの問題に焦点を当てています。それほど大きくない数のモバイルノードである場合、設計者は、大規模なネットワーク（ホストルートなど）でスケーリングされていない微調整されたメカニズムを使用して、パフォーマンスを改善できる場合があります。ローカルモビリティ管理の副作用として、モバイルノードからグローバルなランデブーポイントに送信される場所の更新の数が大幅に削減されます。したがって、ローカルモビリティ管理の存在は、グローバルモビリティ管理のスケーラビリティにも貢献しています。
One problem of local mobility management is that it often requires infrastructure support, such as MAGs in PMIP or MAPs in HMIP. These kinds of local devices are essentially required in all small domains, which can be a huge investment.
ローカルモビリティ管理の問題の1つは、PMIPのMagsやHMIPのマップなど、インフラストラクチャサポートが必要になることが多いことです。これらの種類のローカルデバイスは、すべての小さなドメインで本質的に必要であり、膨大な投資になる可能性があります。
Nevertheless, mobility management in two scales make it possible for designers to design protocols that fit into specific user requirements; it also enables the gradual deployment of local enhancement while not losing the ability of global roaming. The coexistence of the two seems to be a right choice in the foreseeable future.
それにもかかわらず、2つのスケールのモビリティ管理により、設計者は特定のユーザー要件に適合するプロトコルを設計することができます。また、グローバルなローミングの能力を失わずに、ローカル強化の徐々に展開することができます。2つの共存は、近い将来に正しい選択のようです。
Figure 10 shows the classification of the studied protocols according to their serving scale.
図10は、サービングスケールに従って、調査されたプロトコルの分類を示しています。
+-----------+-----------------------------------------+
| | VIP, LSR, Mobile IP, NEMO, E2E, M-SCTP, |
| Global | HIP, ILNPv6, Connexion, WIMO, BTMM, |
| | MSM-IP, Global HAHA, LISP-Mobility |
+-----------+-----------------------------------------+
| Local | Columbia, HMIP, FMIP, Cellular IP, |
| | HAWAII, TIMIP, PMIP |
+-----------+-----------------------------------------+
Figure 10
図10
Despite the wide spectrum of mobility solutions covered by this survey, the list of mobility protocols is not exhaustive.
この調査でカバーされている幅広いモビリティソリューションにもかかわらず、モビリティプロトコルのリストは網羅的ではありません。
The General Packet Radio Service (GPRS) Tunneling Protocol [GTP] is a network-based mobility support solution widely used in cellular networks. Its implementation only involves Gateway GPRS Support Node (GGSN) and Serving GPRS Support Node (SGSN). It allows end users of a Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS) network to move from place to place while remaining connected to the Internet as if from on location at the GGSN. It does this by carrying the subscriber's data from the subscriber's current SGSN to the GGSN that is handling the subscriber's session. To some extent, it is the non-IETF variant of PMIP, with GGSN resembling LMA and SGSN resembling MAG, respectively.
General Packet Radio Service（GPRS）Tunneling Protocol [GTP]は、セルラーネットワークで広く使用されているネットワークベースのモビリティサポートソリューションです。その実装では、GATEWAY GPRSサポートノード（GGSN）とGPRSサポートノード（SGSN）のサービングのみが含まれます。これにより、モバイルコミュニケーション（GSM）またはユニバーサルモバイルテレコミュニケーションシステム（UMTS）ネットワークのグローバルシステムのエンドユーザーが、GGSNの場所からインターネットに接続されたまま、場所から場所に移動できます。これは、サブスクライバーの現在のSGSNからサブスクライバーのセッションを処理しているGGSNにサブスクライバーのデータを運ぶことで行います。ある程度、それはPMIPの非IITFバリアントであり、GGSNはそれぞれLMAとSGSNに似ているMAGに似ています。
There is also work on application-layer mobility support, most notably SIP-based mobility support [ALM-SIP]. SIP was initially designed as an application signaling protocol for multimedia, and later researchers noticed its potential capability for mobility support. When the mobile initiates a session with CN, normal SIP-signaling procedure is performed to establish the session. When the mobile moves to a new network while the session is ongoing, it send a RE-INVITE message with the existing session but reveals the new IP address to the CN. The home SIP server is also updated with the latest location information of the mobile after the move. However, the SIP-based approach cannot maintain TCP connections when the mobile's IP address changes.
アプリケーション層のモビリティサポート、特にSIPベースのモビリティサポート[ALM-SIP]に関する作業もあります。SIPは当初、マルチメディア向けのアプリケーションシグナリングプロトコルとして設計されており、後に研究者はモビリティサポートの潜在的な能力に気付きました。モバイルがCNとのセッションを開始すると、セッションを確立するために通常のSIP署名手順が実行されます。セッションが継続中にモバイルが新しいネットワークに移動すると、既存のセッションで再入力メッセージが送信されますが、CNに新しいIPアドレスが表示されます。Home SIPサーバーは、移動後にモバイルの最新の位置情報で更新されます。ただし、SIPベースのアプローチでは、モバイルのIPアドレスが変更された場合、TCP接続を維持できません。
A lot of enhancements to Mobile IPv6 Route Optimization have also been developed. A comprehensive taxonomy and analysis of these efforts can be found in [RFC4651].
モバイルIPv6ルートの最適化の多くの強化も開発されています。これらの取り組みの包括的な分類法と分析は、[RFC4651]に記載されています。
In the last section, we discussed the different directions towards mobility support. We now turn our attention to identify both new opportunities and remaining open issues in providing global-scale mobility support for an unlimited number of online mobility devices. We are not trying to identify the solutions to these issues, but rather, the goal is to share our opinions and to initiate an open discussion.
最後のセクションでは、モビリティサポートに向けたさまざまな方向について説明しました。現在、私たちは、無制限の数のオンラインモビリティデバイスに対してグローバルなモビリティサポートを提供する際に、新しい機会と残りの問題の両方を特定することに注意を向けています。私たちはこれらの問題の解決策を特定しようとするのではなく、目標は意見を共有し、オープンな議論を開始することです。
Among the various protocols we discussed in this document, few have been deployed in commercial networks. There are several reasons to explain this situation.
このドキュメントで説明したさまざまなプロトコルの中で、商用ネットワークに展開されている人はほとんどいません。この状況を説明する理由はいくつかあります。
First, although the research community started to develop mobility support protocols 20 years ago, only in recent years has the number of mobiles soared. Hence, operators did not see the incentive of deploying mobility support protocols several years back. As of today, the number of mobiles is still growing by leaps and bounds, and there is enough user demand for the operators to seriously consider the deployment of mobility support protocols.
第一に、研究コミュニティは20年前にモビリティサポートプロトコルの開発を開始しましたが、近年の携帯電話の数が急増しています。したがって、オペレーターは、数年前にモビリティサポートプロトコルを展開するインセンティブを見ていませんでした。今日の時点で、携帯電話の数はまだ飛躍的に増加しており、オペレーターがモビリティサポートプロトコルの展開を真剣に検討するのに十分なユーザーの需要があります。
Second, the complexity of most mobility support protocols impedes the implementation and hence the deployment in commercial networks. The complexity arises from multiple aspects. One is the optimizations on performance. The other is the problem with the use of security protocols such as IPsec and IKE. The discussions regarding to these two problems are still ongoing in the MEXT Working Group. Some researchers argue that the research community should design a "barely work" version of a mobility support protocol first, without considering nice performance features and complex security mechanisms, roll it out in the real world, and improve it thereafter. However, there are different views on what the essential features are and which security mechanisms are better.
第二に、ほとんどのモビリティサポートプロトコルの複雑さは、実装を妨げ、したがって商業ネットワークでの展開を妨げます。複雑さは複数の側面から生じます。1つは、パフォーマンスの最適化です。もう1つは、IPSECやIKEなどのセキュリティプロトコルの使用に関する問題です。これら2つの問題に関する議論は、MEXTワーキンググループでまだ進行中です。一部の研究者は、研究コミュニティは、優れたパフォーマンス機能や複雑なセキュリティメカニズムを考慮せずに、最初にモビリティサポートプロトコルの「かろうじて作業」バージョンを設計する必要があると主張しています。ただし、重要な機能が何であるか、どのセキュリティメカニズムが優れているかについては、さまざまな見解があります。
Third, almost all the mobility support protocols assume that the mobile nodes have network connectivity anywhere, anytime. In reality, however, this is not always the case. Nevertheless, wireless access is available in more and more places, and it is foreseeable that in the near future, the coverage of wireless access in different forms (WiFi, Wimax, 3G/4G) will be ubiquitous.
第三に、ほとんどすべてのモビリティサポートプロトコルは、モバイルノードにいつでもネットワーク接続があると想定しています。ただし、実際には、これは必ずしもそうではありません。それにもかかわらず、ワイヤレスアクセスはますます多くの場所で利用可能であり、近い将来、さまざまな形式（WiFi、Wimax、3G/4G）でのワイヤレスアクセスのカバレッジが遍在することが予見可能です。
In order for users to benefit from mobility support, it is important to keep the TCP sessions uninterrupted by the mobility. If the durations of the sessions are short (e.g., web browsing), the probability is high that the TCP sessions finish before the handover happens; even if the TCP session is interrupted by the handover, the cost is usually low (e.g., refresh the web page). However, if the TCP sessions are typically long (e.g., downloading large files and voice calls), the interruptions during the handover would become unacceptable.
ユーザーがモビリティサポートから利益を得るためには、モビリティによってTCPセッションを途切れることなく保つことが重要です。セッションの期間が短い場合（例：Webブラウジング）、ハンドオーバーが発生する前のTCPセッションが終了する確率は高いです。TCPセッションがハンドオーバーによって中断されたとしても、コストは通常低くなります（たとえば、Webページを更新します）。ただし、TCPセッションが通常長い場合（たとえば、大きなファイルや音声通話のダウンロードなど）、ハンドオーバー中の中断は受け入れられません。
It is hard to predict tomorrow's applications, but most mobility support protocols try to keep the sessions up during movements. For routing-based protocols, session continuity is not a problem since the IP address of the mobile never changes. For other protocols, either a stable IP address (e.g., HoA) or an equivalent (e.g., HIT) is used in the transport layer so that the mobility is hidden, or TCP is modified so that both ends can change IP addresses while keeping the established session (e.g., E2E).
明日のアプリケーションを予測することは困難ですが、ほとんどのモビリティサポートプロトコルは、動きの間にセッションを維持しようとします。ルーティングベースのプロトコルの場合、モバイルのIPアドレスが変更されないため、セッションの継続性は問題ではありません。他のプロトコルの場合、安定したIPアドレス（HOAなど）または同等の（ヒットなど）のいずれかが輸送層で使用され、モビリティが隠されるか、TCPが変更され、両端がIPアドレスを変更しながらIPアドレスを変更できるようにすることができます。確立されたセッション（E2Eなど）。
Another concern is the support of simultaneous movements. In some scenarios, only one end is mobile, and the other end is always static; moreover, the communication between the two is always initiated by the mobile end. A lot of applications as of today fall into this category. Typically, the server side is static, and the client is mobile; usually, the client would contact the server first. Hence, in these scenarios, the support of simultaneous movements is not a requirement. However, in other scenarios, both ends may be moving at the same time. For example, during a voice call, two mobile nodes may experience handovers simultaneously. In this case, a rendezvous point is necessary to keep the current locations of the mobiles so that they can find each other after a simultaneous movement. Besides, if a static server wants to push information to a mobile client, a rendezvous point is also required.
別の懸念は、同時動きのサポートです。一部のシナリオでは、一方の端のみがモバイルで、もう一方の端は常に静的です。さらに、2つの間の通信は常にモバイルエンドによって開始されます。今日の多くのアプリケーションは、このカテゴリに分類されています。通常、サーバー側は静的で、クライアントはモバイルです。通常、クライアントは最初にサーバーに連絡します。したがって、これらのシナリオでは、同時動きのサポートは要件ではありません。ただし、他のシナリオでは、両端が同時に動いている可能性があります。たとえば、音声通話中に、2つのモバイルノードが同時にハンドオーバーが発生する場合があります。この場合、モバイルの現在の場所を保持するために、同時動きの後に互いに見つけることができるように、ランデブーポイントが必要です。また、静的サーバーがモバイルクライアントに情報をプッシュしたい場合、ランデブーポイントも必要です。
It is clear that the number of mobile devices is rapidly growing, and more mobiles are going to provide content in the near future. Hence, the simultaneous-movements scenarios are considered important. In fact, almost all the mobility support protocols are equipped with rendezvous points, either by adding dedicated components or by leveraging the existing DNS systems.
モバイルデバイスの数が急速に増加しており、近い将来にコンテンツを提供するモバイルが増えていることは明らかです。したがって、同時モーブメントシナリオは重要と見なされます。実際、ほとんどすべてのモビリティサポートプロトコルには、専用コンポーネントを追加するか、既存のDNSシステムを活用することにより、ランデブーポイントが装備されています。
The mobility awareness at two communicating ends is closely related to the backward-compatibility problem. The Internet has been running for more than two decades, and the scale of the Internet gets so large that it is impossible to upgrade the whole system overnight. As a result, it is also not possible for a mobility support system designer to overlook this problem: how does one decide the mobility awareness in the protocol design, and how important is backward compatibility?
2つの通信端でのモビリティ認識は、後方互換性の問題に密接に関連しています。インターネットは20年以上にわたって実行されており、インターネットの規模は非常に大きくなるため、システム全体を一晩アップグレードすることは不可能です。その結果、モビリティサポートシステム設計者がこの問題を見落とすこともできません。プロトコル設計におけるモビリティ認識をどのように決定し、後方互換性はどの程度重要ですか？
In the following text, we discuss the trade-offs of the design choices mentioned in Section 5.2.
次のテキストでは、セクション5.2に記載されているデザインの選択肢のトレードオフについて説明します。
The advantage of the first design choice is that the mobile does not lose the ability to communicate with legacy nodes while roaming around, i.e., the mobile can benefit from unilateral deployment of mobility support. Another potential advantage is that the static nodes do not need to be bothered by the mobility of the mobiles, which saves resources and could be desirable if the CN is a busy server. The disadvantage of this design is also well known: it introduces triangle routing, which significantly increases the delays in the worst cases. There are means to remedy the problem, e.g., Route Optimization in Mobile IP if a CN is mobility-capable and distribution of Home Agents as Global HAHA does, at the expense of increasing complexity.
最初の設計選択の利点は、ローミング中にモバイルがレガシーノードと通信する能力を失わないことです。つまり、モバイルはモビリティサポートの一方的な展開から利益を得ることができます。もう1つの潜在的な利点は、静的ノードがモバイルのモビリティに悩まされる必要がないことです。これは、リソースを節約し、CNがビジーサーバーである場合に望ましい可能性があります。この設計の欠点もよく知られています。三角形のルーティングを導入し、最悪の場合に遅延が大幅に増加します。CNがモバイルIPのルート最適化を修正する手段があります。CNが複雑さを犠牲にして、グローバルなHAHAが行うようにホームエージェントの分布である場合、モバイルIPのルート最適化。
The second design caters to the inertness of the Internet (and the users) by keeping everything status quo from the user's point of view. It is like the cellular network, with the smart network and dumb terminals. The advantage is that the legacy nodes can benefit from the mobility support without upgrade. However, the cost is also not trivial: the users lose the freedom of control in terms of mobility management, and a large number of entities in the network need to be upgraded.
2番目のデザインは、ユーザーの観点からすべての現状を維持することにより、インターネット（およびユーザー）の不活性に対応しています。これは、スマートネットワークとダム端子を備えたセルラーネットワークのようなものです。利点は、レガシーノードがアップグレードせずにモビリティサポートの恩恵を受けることができることです。ただし、コストも些細なことではありません。ユーザーはモビリティ管理の点で制御の自由を失い、ネットワーク内の多数のエンティティをアップグレードする必要があります。
The third design assumes that the other end is likely also mobility-capable (as of today, more people are accessing the Internet via mobile devices than a desktop) and thus does not provide backward compatibility at all; however, as a trade-off, the system design becomes much simpler, and the data path is always the shortest one.
3番目の設計では、もう一方の端がモビリティ対応である可能性が高いと仮定しています（今日の時点で、デスクトップよりもモバイルデバイスを介してインターネットにアクセスしている人が多く、したがって、後方互換性をまったく提供していません。ただし、トレードオフとして、システム設計ははるかに簡単になり、データパスは常に最短です。
We all know that backward compatibility is important in system design. But how important is it? How much effort should we make for this issue? At least for now, the answer is not yet clear.
私たちは皆、システム設計において後方互換性が重要であることを知っています。しかし、それはどれほど重要ですか？この問題にどの程度の努力をするべきですか？少なくとも今のところ、答えはまだ明確ではありません。
As our survey suggests, multiple solutions for mobility support are already exist, and it is almost for sure that the mobility support systems in the future are going to be heterogeneous. However, as of today, the interoperation between different protocols is still problematic. For example, when a mobile node supporting Mobile IP only wants to communicate with another mobile with only HIP support, neither of them can benefit from mobility support.
私たちの調査が示唆しているように、モビリティサポートのための複数のソリューションはすでに存在しており、将来のモビリティサポートシステムが不均一になることはほぼ確実です。ただし、今日の時点で、異なるプロトコル間の相互操作には依然として問題があります。たとえば、モバイルIPをサポートするモバイルノードが、ヒップサポートのみで別のモバイルとのみ通信したい場合、どちらもモビリティサポートの恩恵を受けることはできません。
This situation reminds us the days before IP was adopted. In that time, the hosts in different networks were not able to communicate with each other. IP merged the networks and created the Internet, where each host can freely communicate with any other host. Is it necessary to introduce something like IP to mobility support in the future? Is it possible to design an architecture so that it glues all the mobility support systems together? We believe the answers to both of these questions are "yes".
この状況は、IPが採用される数日前を思い出させます。その間、異なるネットワークのホストは互いに通信することができませんでした。IPはネットワークをマージし、各ホストが他のホストと自由に通信できるインターネットを作成しました。将来、IPのようなものをモビリティサポートに導入する必要がありますか？すべてのモビリティサポートシステムを接着するように、アーキテクチャを設計することは可能ですか？これらの質問の両方に対する答えは「はい」であると考えています。
The basic idea for the solution is simple. As the famous quote says, "Every problem in Computer Science can be solved by adding a level of indirection". However, the devil is in the details, and we still need to figure that out.
ソリューションの基本的なアイデアは簡単です。有名な引用が言っているように、「コンピューターサイエンスのすべての問題は、間接的なレベルを追加することで解決できます」。しかし、悪魔は詳細にあり、私たちはまだそれを理解する必要があります。
Since mobility means that the location of a mobile may change at any time, how to secure such dynamic location updates is a very important consideration for all mobility support solutions. However, this document examines a wide range of solution proposals, so the security aspects also vary greatly. For example, Home-Agent-based solutions call for secure communications between the mobile and its Home Agent(s). On the other hand, for routing-based solutions, such as Connexion, the issue becomes one of global-routing security. Similarly, for those solutions that use DNS to provide mapping between Identifiers and Locators, the issue is essentially converted to how to secure DNS dynamic updates as well as queries. To keep this survey document both comprehensive as well as reasonably sized, we chose to focus the survey on describing and comparing the solutions to the center piece of all mobility supports -- the resolution between Identifiers and Locators.
モビリティとは、モバイルの場所がいつでも変更される可能性があるため、このような動的な場所の更新を保護する方法は、すべてのモビリティサポートソリューションにとって非常に重要な考慮事項です。ただし、このドキュメントでは、幅広いソリューションの提案を検討しているため、セキュリティの側面も大きく異なります。たとえば、ホームエージェントベースのソリューションでは、モバイルとそのホームエージェントとの間の安全な通信が必要です。一方、Connexionなどのルーティングベースのソリューションの場合、この問題はグローバルルーティングセキュリティの1つになります。同様に、DNSを使用して識別子とロケーター間のマッピングを提供するソリューションの場合、問題は基本的にDNSの動的更新とクエリを保護する方法に変換されます。この調査を維持するために、包括的および合理的なサイズの両方のドキュメントを維持するために、識別子とロケーター間の解像度であるすべてのモビリティサポートの中心部分のソリューションの説明と比較に調査に焦点を当てることを選択しました。
[ALM-SIP] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility Using SIP", Mobile Computing and Communications Review, 2010.
[ALM-SIP] Schulzrinne、H。およびE. Wedlund、「SIPを使用したアプリケーションレイヤーモビリティ」、モバイルコンピューティングおよびコミュニケーションレビュー、2010年。
[Boeing] Andrew, L., "A Border Gateway Protocol 4 (BGP-4)", Boeing White Paper, 2006.
[ボーイング]アンドリュー、L。、「ボーダーゲートウェイプロトコル4（BGP-4）」、ボーイングホワイトペーパー、2006年。
[CIP] Valko, A., "Cellular IP: A New Approach to Internet Host Mobility", ACM SIGCOMM, 1999.
[CIP] Valko、A。、「Cellular IP：インターネットホストモビリティへの新しいアプローチ」、ACM Sigcomm、1999。
[Columbia] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-based Protocols for Mobile Internetworking", ACM SIGCOMM CCR, 1991.
[コロンビア] Ioannidis、J.、Duchamp、D。、およびG. Maguire、「モバイルインターネットワーク用のIPベースのプロトコル」、ACM Sigcomm CCR、1991。
[E2E] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to Host Mobility", ACM Mobicom, 2000.
[E2E] Snoeren、A。およびH. Balakrishnan、「ホストモビリティへのエンドツーエンドのアプローチ」、ACM Mobicom、2000。
[GTP] "GPRS Tunneling Protocol Across Gn and Gp Interface", 3G TS 29.060 v3.5.0.
[GTP]「GNおよびGPインターフェイスを介したGPRSトンネルプロトコル」、3G TS 29.060 V3.5.0。
[HAHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home Agents Towards Internet-scale Mobility Deployment", ACM CoNEXT, 2006.
[ハハ]ワキカワ、R。、ヴァラドン、G。、およびJ.ムライ、「インターネット規模のモビリティ展開に在宅エージェントを移行する」、ACM Conext、2006。
[HAWAII] Ramjee, R., Varadhan, K., and L. Salgarelli, "HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless Networks", IEEE/ACM Transcations on Networking, 2002.
[ハワイ] Ramjee、R.、Varadhan、K。、およびL. Salgarelli、「Hawaii：広い地域のワイヤレスネットワークでのモビリティをサポートするためのドメインベースのアプローチ」、NetworkingのIEEE/ACM Transcations、2002。
[ILNP] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, and Security", MobiWAC 2007.
[ILNP] Atkinson、R.、Bhatti、S。、およびS. Hailes、「マルチホミング、NAT、およびセキュリティによるモビリティを統一する提案」、Mobiwac 2007。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, March 2009.
[lisp] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator/ID Separation Protocol（LISP）」、2009年3月、Work in Progress。
[LISP-Mobility] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, May 2011.
[Lisp-Mobility] Farinacci、D.、Lewis、D.、Meyer、D.、およびC. White、「Lisp Mobile Node」、2011年5月の作業。
[LSR] Bhagwat, P. and C. Perkins, "A Mobile Networking System Based on Internet Protocol (IP)", Mobile and Location-Independent Computing Symposium, 1993.
[LSR] Bhagwat、P。およびC. Perkins、「インターネットプロトコル（IP）に基づくモバイルネットワークシステム」、モバイルおよびロケーションに依存しないコンピューティングシンポジウム、1993。
[M-SCTP] Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and Prototypical Implementation of An End-to-End Mobility Concept", 5th Intl. Workshop on the Internet Challenge, 2002.
[M-SCTP] Xing、W.、Karl、H。、およびA. Wolisz、「M-SCTP：エンドツーエンドモビリティコンセプトの設計とプロトタイプの実装」、5th Intl。インターネットチャレンジに関するワークショップ、2002年。
[MSM-IP] Mysore, J. and V. Bharghavan, "A New Multicast-based Architecture for Internet Host Mobility", ACM Mobicom, 1997.
[MSM-IP] MySore、J。およびV. Bharghavan、「インターネットホストモビリティのための新しいマルチキャストベースのアーキテクチャ」、ACM Mobicom、1997。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] MANER、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、2005年1月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P。、「IKEV2モビリティおよびマルチホームプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[RFC4651] Vogt、C。およびJ. Arkko、「モバイルIPv6ルート最適化の強化の分類と分析」、RFC 4651、2007年2月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380] Soliman、H.、Castelluccia、C.、Elmalki、K。、およびL. Bellier、「階層モバイルIPv6（HMIPV6）モビリティ管理」、RFC 5380、2008年10月。
[RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC5454] Tsirtsis、G.、Park、V。、およびH. Soliman、「デュアルスタックモバイルIPv4」、RFC 5454、2009年3月。
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R。、「モバイルIPv6高ファストハンドオーバー」、RFC 5568、2009年7月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944] Perkins、C。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年11月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281] Cheshire、S.、Zhu、Z.、Wakikawa、R。、およびL. Zhang、「AppleのBack to My Mac（BTMM）サービスを理解する」、RFC 6281、2011年6月。
[TIMIP] Grilo, A., Estrela, P., and M. Nunes, "Terminal Independent Mobility For IP (TIMIP)", IEEE Communications Magazine, 2001.
[Timip] Grilo、A.、Estrela、P。、およびM. Nunes、「IP（TIMIP）のターミナル独立モビリティ」、IEEE Communications Magazine、2001。
[VIP] Teraoka, F., Yokote, Y., and M. Tokoro, "A Network Architecture Providing Host Migration Transparency", ACM SIGCOMM CCR, 1991.
[VIP] Teraoka、F.、Yokote、Y。、およびM. Tokoro、「ホスト移行の透明性を提供するネットワークアーキテクチャ」、ACM Sigcomm CCR、1991。
[WINMO] Hu, X., Li, L., Mao, Z., and Y. Yang, "Wide-Area IP Network Mobility", IEEE INFOCOM, 2008.
[Winmo] Hu、X.、Li、L.、Mao、Z。、およびY. Yang、「ワイドエリアIPネットワークモビリティ」、IEEE Infocom、2008。
Authors' Addresses
著者のアドレス
Zhenkai Zhu UCLA 4805 Boelter Hall, UCLA Los Angeles, CA 90095 USA
Zhenkai Zhu UCLA 4805 Boelter Hall、UCLA Los Angeles、CA 90095 USA
Phone: +1 310 993 7128
EMail: zhenkai@cs.ucla.edu
Ryuji Wakikawa Toyota ITC 465 Bernardo Avenue Mountain View, CA 94043 USA
ワキカワトヨタITC 465ベルナルドアベニューマウンテンビュー、カリフォルニア州94043 USA
EMail: ryuji.wakikawa@gmail.com
Lixia Zhang UCLA 3713 Boelter Hall, UCLA Los Angeles, CA 90095 USA
Lixia Zhang UCLA 3713 BOELTER HALL、UCLA LOS ANGELES、CA 90095 USA
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.edu