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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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年代初頭以来、インターネットモビリティ研究と標準化の取り組みの歴史的調査から、我々の調査結果を報告します。私たちの調査では、二つの要因が動機とされました。まず、インターネット上での移動をサポートすることは、アクティブな研究領域であったとのインターネット標準となっているそのうちのいくつかのさまざまなソリューションを、生産しています。しかし、新たな問題が発生し続け、新しいソリューションは、私たちが問題空間だけでなく、解空間について発見してまだ持っているどのくらいのより多くの1つの不思議を作り、それらに対処するために開発され続けています。第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.
ランデブーポイント（RP）：マッピングが保持されている場所。このようなデータ転送のようないくつかの他の機能もランデブーポイントで同じ場所に配置することができます。
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).
インターネットモビリティサポートにおける基本的な質問は、（要するに、モバイル）移動受信機にデータを送信する方法です。ここでは、モバイルノードとモバイルサブネットを区別しないことに注意してください。私たちは、モバイル通信相手ノード（CN）にデータを送信するホストを呼び出します。移動受信機Mにデータを送信するために、CNはMの最新のIPアドレス（溶液タイプ-1）を取得したり、安定した情報の一部を使用してMに到達できるようにする手段を持っている必要があります。ここで、「安定な」情報が変更されないことを意味し移動体が移動する（溶液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の下で、いくつかの秋、そしてそれらのほとんどは、モバイルの最新のIPアドレス情報をCNに提供する手段として、DNSを使用しています。既存のソリューションの残りの部分は、タイプ2、CNに知られているモバイルの不変の識別子を使用して移動局の動的に変化する位置に到達する機能を提供しなければならない該当します。私たちは、基本的に3つの基本的な構成要素を含むものとして、すべてのモビリティサポート・ソリューションをまとめることができます。モバイル用の安定識別子oを。通常、移動体の現在位置を示すIPアドレスであるロケータ、O。二つの間のマッピングO。
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サーバは、マッピング機能を提供します。 CNは、安定した識別子を用いてモバイルに到達することができなければならないので、2型ソリューションでは、識別子自体は、典型的には、IPアドレスです。いずれかのネットワークは、動的に携帯電話やIPアドレスが、モバイルの現在のロケータを知っているので、携帯にCNのパケットを転送することができ、モバイルの「ホーム」につながる到達するためのパスを見つけることができます。すべてのタイプ2のソリューションは、2つの一般的な問題に直面しています。 1つの問題は、CNにより送信された元のパケットが送信先として、携帯の「ホーム・アドレス」を持っている与えられた、この転送タスクを実行する方法です。他の問題は、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は、他のMSSに到達する方法を知っている（例えば1つのマルチキャストグループ、またはすべてのMSSのIPアドレスのリストで静的に各MSSのために構成することができ、すべての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がモバイルノードにパケットを送信する場合、パケットは、同じセル内の移動ノードがあり、直接届けることができますまたは他のすべてのMSSにクエリをブロードキャストし、取得するいずれかのCNへMSS最も近い（MC）、に行きますモバイルノードと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への次のルータは移動性を意識しているので、三角形のルーティングを回避し、モバイル宛てのCNのデータを傍受し、先MSSに転送することができます。モバイルはその動きから独立して、同じ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]は二つの基本的な考え方を持っています。まず、パケットは、識別子及びロケータの両方を運びます。二、識別子は、マッピングが保たれているホームネットワークにつながる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の設計におけるもう一つのネットワークエンティティは、モバイルは、インターネットへの接続を取得し、それを通して、モバイルアクセス局（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は、単に、（この場合、CNがモバイルである）は、2つの間でパケットを転送します。それ以外の場合は、CNからのパケットは、モバイルのモバイルルータにルーティングされます。モバイルルータは、モバイルノードのサービングMASを見つけるために、マッピングを検索し、その上にMASのIPアドレスを持つパケットのIPヘッダにルーズソースルーティング（LSR）オプションを挿入します。このように、パケットは、モバイルにパケットを提供MASにリダイレクトされます。この時点まで、モバイルノードのロケータは既にLSRオプションに含まれ、両者は、着信パケット内のLSRオプションを逆にすることによって、直接通信することができます。従って、CNからモバイルへの最初のパケットのパスがCN->モバイルRouter-> MAS->移動ノードであり、その後、次のパケットの双方向パスがモバイルノードである< - > MAS < - > CN。
Triangle routing is avoided by revealing the mobile's Locator to the CN in the LSR option.
トライアングルルーティングは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
3つの文書は細部が異なるものの、高レベルのデザインが似ています。ここでは、例として、モバイルIPv6を使用しています。各モバイルノードは、そのホームアドレス（HoA）、識別子を取得し、そこからホームエージェント（HA）を、持っています。モバイルノードは、その現在のアクセスルータから、そのロケータ、気付アドレス（CoA）を取得します。モバイルノードが新たなCoAを取得するたびに、それが通知するバインディング更新メッセージを送信します
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.
ホームエージェント。概念的には、モバイルIPv6のデザインは、モバイルのHoAは、VIPでの仮想IPアドレスに対応するCoAが正規のIPアドレスに対応して、VIPプロトコルに似ています。
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は、宛先IPアドレスとして、モバイルのHoAを使用しています。パケットは、マッピングに係る移動ノードの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は、ホームエージェントを経由せず、直接、モバイルにパケットをカプセル化することができます。この場合には、モバイルも同様のCNへのCoAを更新する必要があることに注意してください。
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間の遅延に比べて、このように、ハンドオフの性能は、通常、より良いモバイルとMAP間の短い往復時間によるものです。また、ホームエージェントへの更新を送信する頻度を減らすことによって、ホームエージェントの負担を軽減します。
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接続の待ち時間を短縮モバイル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]は、モバイルIPの下位互換性拡張機能として、ネットワークモビリティのための効率的なサポートを提供するために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マルチキャストを使用してモビリティサポートの略です。 1は、その名前からわかるように、MSM-IPは、モビリティサポートのためにIPマルチキャストルーティングを活用しています。 IPマルチキャストでは、ホストに関係なく、それと接続しているネットワークのグループに参加し、その参加した後、グループに送信されたパケットを受信することができます。このように、移動度が自然にIPマルチキャストが展開されているドメインでサポートされています。 MSM-IPはIPマルチキャストによるモビリティをサポートすることの実現可能性の問題に対処しないことに注意してください。むしろ、それは単にIPマルチキャストが普遍的に展開されている場合は、一度/モビリティサポートを提供するために、IPマルチキャストを使用する可能性を示しています。
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.
セルラIPは[CIP]セルラIPルータからなるネットワーク内のローカルモビリティを取り扱います。モバイルレポートそのホームエージェントへのRCoAとしてローカルネットワークのゲートウェイのIPアドレスと、それがセルラーIPネットワーク内でローミングするときに、ローカルに割り当てられたIPアドレス（地域Identifier）を保持します。ネットワーク内のルータは、移動ノードからの発信パケットを監視し、各モバイルノードのための分散、ホップバイホップ逆の経路を維持します。セルラ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からのパケットがゲートウェイに到着すると、ゲートウェイは、制御されたフラッディングクエリーを開始します。ルータは、パケットの転送先を知っている場合、それはすぐにそれを転送します。それ以外の場合は、パケットが来たから1を除くすべてのインターフェイスにパケットを転送します。ページング技術に、これは放送になることはありません。モバイルは、クエリを受信すると、それがゲートウェイにルーティング更新メッセージで応答し、そして、はるかに正確な逆の経路は、ゲートウェイルータがモバイルに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.
同様に、ハンドオフ-Awareの無線アクセスインターネットインフラストラクチャ（HAWAII）[HAWAII]も、効率的なローカルモビリティサポートを提供することを目的とします。セルラIPとは異なり、ゲートウェイルータとモバイルとの間の経路が常に維持されます。モバイル移動は、HAWAII動的移動の古いものと新しい基地局との間の最短経路に沿って位置するルータのホストベースの転送エントリをインストールすることにより、モバイルへのルートを変更したとき。より長い準最適ルーティングパス（例えば、ゲートウェイrouter->旧基地局 - >新たな基地局 - >モバイル）を構築することが可能です。代替的に、モバイル及びクロスオーバールータとの間の新たなサブパスを確立することができます。ここで、クロスオーバールータは、二つの経路、ゲートウェイと旧基地局と旧基地局と新しい基地局との間の第二の間の1つの交点におけるルータです。 HAWAIIでは、モバイルは、定期的に基地局にリフレッシュメッセージを送信し、他のルータと一緒に基地局は、パス保守の世話をします。
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.
ターミナル独立したモバイルIPの略TIMIP [TIMIP]は、セルラー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サーバに現在のIPアドレスを更新するために、ダイナミックDNSを使用しています。モビリティの影響を受けない継続的な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の層を追加します。本質的に、公開鍵であるホストアイデンティティは、モバイルノードを識別するために使用され、IPアドレスは、ルーティングの目的で使用されています。既存のコードを再利用するためには、ホストIDの128ビットのハッシュ値であるホストアイデンティティタグ（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は、より良いランデブーサービスを期待して、独自の静的なインフラランデブーサーバを使用しています。各モバイルノードは、モバイルノードの現在の位置を追跡し、指定ランデブーサーバ（RVS）を有します。 CNは、モバイルノードと通信したいとき、それは、モバイルノードのRVSのIPアドレスを取得するために、モバイルノードのHITでDNSを照会し、最初のパケットを送信します。この最初のパケットを受信した後、RVSは、モバイルノードに中継します。モバイルノードとコレスポンデントノードは、直接経路で通信を開始することができます。モバイルノードが新しいアドレスに移動した場合、その新たなIPアドレス（ロケータ）を示すLOCATORパラメータでHIPの更新を送信することによりCNに通知します。一方、それはまた、RVSでマッピングを更新します。
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セキュリティアソシエーション（SA）を維持できるようにすることです。 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 SAを更新します。そして、それは相手にUPDATE_SA_ADDRESSES通知を含む情報要求を送信します。レスポンダは、ローカルポリシーをチェックし、IPヘッダからの値でIKE_SAでIPアドレスを更新します。それは、INFORMATIONAL応答して、イニシエータに応答することがしたい場合は、リターン・ルータビリティチェックを開始し、このIKE_SAに関連したIPSec SAを更新します。
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の[ボーイング]はネットワークモビリティをサポートするために、BGPが使用するボーイングが提供するモビリティサポートサービスでした。すべてのモバイルネットワークは/ 24 IPアドレス・プレフィクス（安定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.
（広域IPネットワークモビリティの略）Windows Mobile搭載[Windows Mobile搭載]はConnexionののルーティング更新のオーバーヘッドの問題に対処するために2008年に導入されました。 Connexionのと同様に、Windows Mobile搭載は、各モバイルネットワークに安定したプレフィックスが割り当てられます。しかし、2つの新たなアプローチを通じて、Windows Mobile搭載のConnexionののものより数桁低いことにより、モバイルネットワークのためのBGPアップデートのオーバーヘッドを減らすことができます。まず、Windows Mobile搭載の携帯動きによって引き起こされるルーティング更新の伝播範囲を減少させるために種々のヒューリスティックを使用しています。そのため、必ずしもすべてのルータは、全ての移動体の現在の場所を知っているかもしれません。この問題を処理するWindows Mobile搭載で撮影した第二ともっと根本的なアプローチにつながった：それは、各モバイルネットワーク、次のように「ホーム」を割り当てることによって、モバイルIPからの基本的な考え方を採用しています。 Windows Mobile搭載は、明確に定義されたモバイル・プレフィックスの小さなセットから各モバイルネットワークにプレフィックスを割り当てます。これらのモバイルプレフィックスは、モバイルネットワークの現在の位置を追跡する集約ルータの小さなセットで発表しています。したがって、これらの集約ルータは、モバイル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）内のモバイルネットワークの動きにルーティング更新を防止するために、Windows Mobile搭載もモバイルプレフィックスのためのホームエージェントが導入されています唯一のBGPスピーキングルータ（DBR）は、として機能し、指定しますモバイルプレフィックス、およびモバイルネットワークの起源は、常に、モバイル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ヘッダに類似しました。高次Locatorおよび下位識別子として64ビットと64ビット：本質的に、これは、2つの成分にIPv6アドレスを破ります。識別子は代わりインタフェース、ホストを識別し、上位層プロトコル（例えば、TCP、FTP）で使用されています。一方、ロケータモバイルノードの移動に伴って変化し、ロケータのセットは、単一の識別子に関連付けることができます。いくつかの新しいDNSリソースレコード（RR）は、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.
ホームエージェント（HAHA）にグローバルホームエージェント[HAHA]、最初のモバイルIPの拡張として、2006年に提案されているが、世界的に複数のホームエージェントを配布することによって、モバイルIPおよびNEMOにおける三角ルーティングの問題を解消することを目指しています。すべてのホームエージェントはIPエニーキャストグループに参加し、オーバーレイネットワークを形成します。同じホームプレフィックスが異なる場所からすべてのホームエージェントが発表されます。各モバイルノードはそれに最も近い任意のホームエージェントに登録することができます。モバイルノードMの結合要求を受け付けるホームエージェントHはMのプライマリホームエージェントになり、すべてのホーム・エージェント内のすべての移動局のためのバインディング情報のデータベースであるように結合[M、H]の他のすべてのホームエージェントの通知します常に同期。ときにモバイルが移動すると、それはモバイルに最も近くなる別の1にその主要なホームエージェントを切り換えることができます。
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.
コレスポンデントノードは、モバイルのホームアドレスにパケットを送信します。そのためエニーキャストルーティングのため、パケットは、最寄のホームエージェントに配信されます。このホームエージェントは、現在、最終的にはカプセル化ヘッダーをオフにストライピングした後、モバイルノードにパケットを配信しますモバイルノードを、提供しているプライマリ・ホームエージェントのIPアドレスにパケットをカプセル化します。逆方向では、このアプローチはモバイルIPとまったく同じように動作します。ホームエージェントが広く分布している場合は、三角ルーティングの問題は自然にルート最適化せずに軽減されます。
The data flow in Global HAHA is shown in Figure 6.
グローバルHAHAのデータフローは、図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
プロキシモバイルIP（PMIP）[RFC5213]はネットワークではなく、モバイルデバイス上のモビリティをサポートするためのモビリティサポートの厳密な制御を持つことを望むモバイルネットワーク事業者の興味を満たすために、2006年に提案されました。モビリティは、モバイルデバイスに対して完全に透過的であり、従来のIPデバイスに提供されます。 PMIPは一緒にモバイルノードによって取られるアクションなしオペレータのネットワーク内のモビリティをサポートすることができるネットワーク・ノード、ローカル・モビリティ・アンカー（LMA）とモバイル・アクセス・ゲートウェイ（MAG）、の二つの新しいタイプを導入します。 LMAは、ローカルホームエージェントとして機能し、各モバイルノードのローカルホームネットワークプレフィックスを割り当てます。このプレフィックスは、PMIPドメイン内の移動ノードの識別子です。 MAGは、モバイルノードの着脱イベントを監視し、ハンドオフ中、移動ノードに代わってLMAに結合更新プロキシを生成します。結合の成功の後、LMAは現在、モバイルノードにサービスを提供しているMAGのIPアドレスを持つモバイルノードのプロキシCoAを（PMIPドメイン内Locator）を更新します。 MAGはその後、ルータ広告でモバイルノードのローカルホームネットワークプレフィックスを広告することにより、モバイルノードのローカルホームリンクをエミュレートします。でローミングする場合
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.
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.
どこでもMy Macの（BTMM）[RFC6281]には、モビリティサポートへの工学的アプローチであるとMac OS Leopardのリリースを2007年から展開されています。各ユーザーは、（BTMMサービスを含みます）のMobileMeアカウントを取得し、アップル社は、すべての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更新を使用しています。各ホストは、そのトポロジー的に独立した識別子としてDNSデータベースに格納されたブート時、でのIPv6ユニークローカルアドレス（ULA）[RFC4193]を生成します。 （ホストはNATの背後にある場合、NATボックスのIPv4アドレスである）ホストの現在のIPv4アドレスは、NATトラバーサルのために必要なトランスポートのポート番号と一緒にSRVリソースレコード[RFC2782]に格納されています。そのクエリに対する答えが変更されたときにDNSサーバーはすぐに各ノードに通知することができるようにすべてのノードがDNSサーバーとの長命のクエリ（LLQ）セッションを確立します。ホストは、トランスポートプロトコルとアプリケーションでその識別子を使用し、SRV RRとから学習した情報を用いてデータパケットを配信するためにUDP / IPv4のカプセル化を使用します。ここロケータは、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-モビリティ[LISP-モビリティ]は比較的新しいデザインです。その設計者は、同様のモビリティをサポートするために、インターネットルーティングのスケーラビリティのために設計されているロケータ/ ID分離プロトコル（LISP）[LISP]、提供する機能やサービスを利用したいと考えています。概念的には、LISP-モビリティは、このようなILNPv6とモバイルIPなど、我々はこれまでに述べてきたいくつかのプロトコルに似て見えるかもしれません。軽量入力トンネルルータおよび出力トンネルルータの機能は、各移動ノードに実装されている、とすると、移動ノードからのすべてのパケットが2つのルータの機能（そのモバイルノードは、LISPサイトのように見える）によって処理されています。各モバイルノードは、静的なエンドポイントIDと同様に、事前設定された地図・サーバーが割り当てられます。モバイルノードがネットワークにローミングして、新しいルーティングロケータを取得すると、それはそのルーティングロケータ地図・サーバーに設定された更新され、それはまた、CNSの入力トンネルルータまたはプロキシトンネルルータにキャッシュされたルーティングロケータをクリアします。このように、CNは常にstaledキャッシュについては、モバイルノードから通知を受けた後、それ自体によって発行または発行のいずれか、モバイルノードのエンドポイント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つの基本的なアプローチに分類することができます。最初のものはダイナミックルーティングを介して移動性をサポートすることです。このような設計では、モバイルは関係なく、その場所の変更のその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).
ルーティングベースのアプローチでは二つのサブクラスを識別するためにも価値があります。一つはベースのブロードキャスト、およびその他のは、パスベースです。前者の場合、いずれかの移動局の位置情報を積極的にネットワーク全体にブロードキャストされるか、または積極的なブロードキャストクエリ（例えば、コロンビアとConnexionの）移動体の位置情報を取得するために必要とされます。後者の場合、一方、ホストベースのパスではなく、ルーティングシステムによって維持されている（例えば、セルラ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の場合と同様に、使用されている場合は、このアプローチでは、それは三角形のルーティングを導入する可能性のある副作用を有します。 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.
しかし、プロトコルは長所を維持し、両者のいくつかの短所を除去するのを期待して、上記のアプローチを組み合わせた第3の場合があります。 Windows Mobile搭載は、この場合の典型的なプロトコルです。
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.
様々なデザインの選択肢の中で、重要な一つは、モビリティを意識すると想定されているどのように多くのエンティティです。モバイル自体、CN、ネットワーク、およびホーム・エージェントまたはそれと同等（マッピングを保持している既存のIPネットワークへの追加コンポーネント）：モバイルとの会話中に関与している可能性がある4人の当事者があります。私たちは、主にここにマッピングベースのアプローチに議論の焦点を合わせます。
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などのプロトコルは、この設計を採用しています。この設計では、プロトコルの動作は、第1のカテゴリのものに似ているが、有意差は、ここでは、モビリティ関連のシグナリング（例えば、ホームエージェントへの更新ロケータ）は、ネットワーク内のエンティティではなく、モバイル自体によって処理されていることです。したがって、モバイルは、穏やかに、それは同じサブネット内に常にあることを前提としています。
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は、プロトコルの三つのカテゴリーを示します。
+-------------+----------------------------------+
| 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、すなわちに強い提唱者であり、代わりに、モバイルデバイスはモビリティ関連自身のシグナリングに参加させることを、事業者によって展開されたネットワークエンティティは、任意およびすべての世話をする必要がありますモビリティサポートのプロセスを知らせます。この方向に沿った典型的な例は、LMAは、同じプロバイダのドメイン内のモバイルローミング限り、そのホームプレフィックス使用してモバイルへの到達性を確保するためのMAGと一緒に働いているプロキシモバイルIP、です。
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.
このアプローチの一つの主な理由は、おそらく、下位互換性があります。モバイルノードは、単純な滞在することができ、すべてのレガシーノードが最近の携帯デバイスなどのモビリティサービスの同じレベルを得ることができるように制御シグナリングプロセスにおけるモバイルの参加を必要としないことにより、モバイルノードへの変更を回避することができます。彼らは彼らの展開の経験から学ぶと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.
一方、既にネットワークへのアクセスを取得した携帯電話を想定し、唯一のモビリティサポートに、このドキュメントの焦点で調査モビリティサポートプロトコルのほとんど。モバイルノードは、典型的には、ユーザによって選択されたランデブーポイントにそれらの位置自体を更新し、そして、もちろん、これらのソリューションのいずれかを実施する唯一のノードは、移動性サポートから利益を得ることができます。しかし、プロトコルのこのクラスは、ユーザーやモバイルデバイス、より多くの柔軟性と自由、例えばを提供し、彼らはサービスがいる限り彼らのソフトウェアは、そのプロトコルをサポートして利用できるものは何でもモビリティ選択することができます、と彼らはまた、チューニングパラメータは、ほとんどのあるサービスを取得することができますそれらに適しています。
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つの問題は、多くの場合、このようなHMIPにおけるPMIPまたはマップでのMAGとして、インフラのサポートを必要とすることです。ローカルデバイスのこれらの種類は、基本的に莫大な投資することができ、すべての小さなドメインで必要とされています。
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つのスケールでのモビリティ管理は、それが可能な設計者は、特定のユーザー要件に適合したプロトコルを設計するために作ります。グローバルローミングの能力を失っていないながらも、地元の充実の漸進的な導入を可能にします。両者の共存は、予見可能な将来において正しい選択であるように思われます。
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.
汎用パケット無線サービス（GPRS）トンネリングプロトコル[GTP]は広くセルラーネットワークで使用されるネットワーク・ベースのモビリティ・サポート・ソリューションです。その実装はゲートウェイGPRSサポートノード（GGSN）及びサービングGPRSサポートノード（SGSN）を必要とします。これは、モバイル通信用グローバルシステム（GSM）またはユニバーサル・モバイル・テレコミュニケーション・システムのエンドユーザ（UMTS）ネットワークは、GGSNにおける位置での場合と同様、インターネットに接続されたまま場所から場所へ移動することを可能にします。これは、加入者のセッションを処理しているGGSNに加入者の現在のSGSNから加入者のデータを搬送することにより、これを行います。ある程度までは、GGSNは、それぞれ、MAGに似LMAとSGSNに類似して、PMIPの非IETF変異体です。
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シグナリング手順は、セッションを確立するために行われます。セッションが継続している間、ときに新しいネットワークへのモバイル移動は、それが既存のセッションにRE-INVITEメッセージを送信するが、CNに新しいIPアドレスを明らかにします。ホーム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.
第二に、ほとんどのモビリティサポートプロトコルの複雑さを実現、ひいては商用ネットワークでの展開を妨げます。複雑さは、複数の側面から生じます。一つは、パフォーマンス上の最適化です。他には、IPsecとIKEなどのセキュリティプロトコルの使用に問題があります。この2つの問題に係る議論が文部科学省作業部会ではまだ進行中です。一部の研究者は、研究コミュニティは、素敵なパフォーマンス機能と複雑なセキュリティメカニズムを考慮せずに、最初のモビリティサポートプロトコルの「やっと仕事」バージョンを設計し、現実の世界でそれをロールアウトし、その後それを改善すべきであると主張しています。しかし、本質的な特徴があり、どのセキュリティメカニズムが優れているかについて異なる見解があります。
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.
第三に、ほぼすべてのモビリティサポートプロトコルは、モバイルノードは、いつでもどこでもネットワークに接続されていることを前提としています。しかし実際には、これは必ずしもそうではありません。それにも関わらず、無線アクセスは、より多くの場所で利用可能であり、近い将来には、さまざまな形態（無線LAN、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セッションを維持することが重要です。セッションの継続時間は、（例えば、ウェブブラウジング）短い場合、確率は、ハンドオーバーが発生する前にTCPセッションが終了していることに高いです。 TCPセッションがハンドオーバによって中断された場合でも、コストが（例えば、ウェブページをリフレッシュします）通常は低いです。 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アドレスを変更できるように、他のプロトコルのために、移動度が隠されているように、安定したIPアドレス（例えば、HoAを）または同等の（例えば、HIT）のいずれかは、トランスポート層で使用され、またはTCPが変更され確立されたセッション（例えば、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年以上にわたって実行されている、およびインターネットの規模は、一晩中、システム全体をアップグレードすることは不可能であるほど大きくなります。その結果、移動支援システムの設計者は、この問題を見落とすすることも可能ではありません。どのように1は、プロトコル設計におけるモビリティ意識を決めず、下位互換性はどのように重要なのですか？
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.
最初の設計上の選択の利点は、モバイルは、すなわち、モバイルは、モビリティサポートの一方的な展開から利益を得ることができ、周りにローミングしながら、従来のノードと通信する能力を失わないということです。別の潜在的な利点は、静的なノードがリソースを節約し、CNがビジー状態のサーバであれば望ましいかもしれない携帯電話の移動性、に悩まされる必要はありませんということです。この設計の欠点はまた、よく知られている：それはかなり最悪ケースの遅延を増大させる三角形のルーティングを導入します。グローバルHAHAが行うようにCNが複雑になるのを犠牲にし、モビリティ対応のホームエージェントの分布であれば、問題を解決するための手段は、モバイル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の設計は、もう一方の端は（より多くの人々がデスクトップよりもモバイルデバイスを介してインターネットにアクセスしている、今日のような）ので、全くの下位互換性を提供していません。また、モビリティ対応の可能性があることを想定しています。しかし、トレードオフとして、システムの設計が非常に簡単になり、データ・パスは、常に最短1です。
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をサポートする移動体ノードのみだけでHIPをサポートして別の携帯と通信したいとき、例えば、それらのいずれもモビリティサポートの恩恵を受けることができます。
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のようなルーティングベースのソリューションのために、問題は、グローバルルーティングセキュリティの一つとなります。同様に、識別子とロケータとの間のマッピングを提供するために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.、 "携帯IP：インターネットホストモビリティへの新しいアプローチ"、ACM SIGCOMM、1999。
[Columbia] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-based Protocols for Mobile Internetworking", ACM SIGCOMM CCR, 1991.
[コロンビア] Ioannidis、J.、デュシャン、D.、およびG.マグワイア、 "モバイルインターネットワーキングのための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.バラクリシュナン、「モビリティをホストするためのエンドツーエンドのアプローチ」、ACMモビコム、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.
[HAHA] Wakikawa、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.
[HAWAII] Ramjee、R.、Varadhan、K.、およびL. Salgarelli、 "HAWAII：広域無線ネットワークにおけるモビリティをサポートするためのドメインベースのアプローチ"、ネットワーキング、2002年IEEE / ACM Transcations。
[ILNP] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, and Security", MobiWAC 2007.
[ILNP]アトキンソン、R.、Bhattiさん、S.、およびS.ヘイルズ、 "マルチホーミング、NAT、およびセキュリティが強化された統一モビリティの提案"、MobiWAC 2007。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, March 2009.
[LISP]ファリナッチ、D.、フラー、V.、マイヤー、D.、およびD.ルイス、 "ロケータ/ ID分離プロトコル（LISP）"、進歩、2009年3月に作業。
[LISP-Mobility] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, May 2011.
[LISP-モビリティ]ファリナッチ、D.、ルイス、D.、マイヤー、D.、およびC.ホワイト、 "LISPモバイルノード"、進歩、2011年5月での作業。
[LSR] Bhagwat, P. and C. Perkins, "A Mobile Networking System Based on Internet Protocol (IP)", Mobile and Location-Independent Computing Symposium, 1993.
、モバイルと場所に依存しないコンピューティングシンポジウム1993「インターネットプロトコル（IP）に基づいたモバイルネットワークシステム」[LSR] Bhagwat、P.とC.パーキンス、。
[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]興、W.、カール、H.、およびA. Wolisz、 "M-SCTP：デザインとエンドツーエンドモビリティコンセプトのプロトタイプ実装"、第5回国際空港。インターネットの挑戦、2002年ワークショップ。
[MSM-IP] Mysore, J. and V. Bharghavan, "A New Multicast-based Architecture for Internet Host Mobility", ACM Mobicom, 1997.
[MSM-IP]マイソール、J.およびV. Bharghavan、 "インターネットホストモビリティのための新しいマルチキャストベースのアーキテクチャ"、ACMモビコム、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]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.、ペトレスク、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.ハーバーマン、 "ユニークローカル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]フォークト、C.とJ. Arkko、RFC 4651 "モバイルIPv6経路最適化の機能強化の分類と分析"、2007年2月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]ソリマン、H.、カステルッシア、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.、公園、V.、およびH.ソリマン、 "デュアルスタックモバイル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]パーキンス、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]チェシャー、S.、朱、Z.、Wakikawa、R.、およびL.チャン、RFC 6281、2011年6月、 "どこでもMy Mac（BTMM）サービスにAppleのバックを理解します"。
[TIMIP] Grilo, A., Estrela, P., and M. Nunes, "Terminal Independent Mobility For IP (TIMIP)", IEEE Communications Magazine, 2001.
【TIMIP】グリロ、A.、エストレラ、P.、およびM.ヌネス、 "IP用端子独立モビリティ（TIMIP）"、IEEE通信雑誌、2001。
[VIP] Teraoka, F., Yokote, Y., and M. Tokoro, "A Network Architecture Providing Host Migration Transparency", ACM SIGCOMM CCR, 1991.
[VIP]寺岡、F.、横手、Y.、およびM.所、 "ネットワークアーキテクチャ提供するホスト移行透明"、ACM SIGCOMM CCR、1991。
[WINMO] Hu, X., Li, L., Mao, Z., and Y. Yang, "Wide-Area IP Network Mobility", IEEE INFOCOM, 2008.
[Windows Mobile搭載]胡、X.、李、L.、真央、Z.、およびY.ヤン、 "広域IPネットワークモビリティ"、IEEE INFOCOM、2008。
Authors' Addresses
著者のアドレス
Zhenkai Zhu UCLA 4805 Boelter Hall, UCLA Los Angeles, CA 90095 USA
Zhenkai朱UCLA 4805 Boelterホール、UCLAロサンゼルス、CA 90095 USA
Phone: +1 310 993 7128 EMail: zhenkai@cs.ucla.edu
電話：+1 310 993 7128 Eメール：zhenkai@cs.ucla.edu
Ryuji Wakikawa Toyota ITC 465 Bernardo Avenue Mountain View, CA 94043 USA
りゅじ わきかわ とよた いＴＣ ４６５ べｒなｒど あゔぇぬえ もうんたいん ゔぃえｗ、 か ９４０４３ うさ
EMail: ryuji.wakikawa@gmail.com
メールアドレス：ryuji.wakikawa@gmail.com
Lixia Zhang UCLA 3713 Boelter Hall, UCLA Los Angeles, CA 90095 USA
L I老人張UCLA 3713 BOEホール、UCLAロサンゼルス、CA 90095 USA
Phone: +1 310 825 2695 EMail: lixia@cs.ucla.edu
電話：+1 310 825 2695 Eメール：lixia@cs.ucla.edu