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
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
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.
在过去二十年中，许多人致力于开发全球互联网上的移动支持解决方案，并提出了各种解决方案。我们对之前的工作进行了系统调查，以全面了解机动性支持的解决方案空间。本文件报告了我们的调查结果，并确定了在全球范围内提供普遍有效的互联网移动支持方面存在的问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6301.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第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
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.
本文件报告了我们对自20世纪90年代初以来互联网移动性研究和标准化工作的历史调查结果。我们的调查是由两个因素推动的。首先，支持互联网上的移动一直是一个活跃的研究领域，并产生了多种解决方案，其中一些已成为互联网标准。然而，新的问题不断出现，新的解决方案不断被开发出来以解决这些问题，这让人不禁要问，关于问题空间和解决方案空间，我们还有多少东西有待发现。第二个因素是近年来通过移动设备接入互联网的快速增长，这将不可避免地导致未来几年新的互联网应用开发，并进一步强调互联网移动支持的重要性。我们认为，对摆在桌面上的所有拟议解决方案进行历史性审查，不仅有助于我们确定它们的共同点和差异，而且有助于澄清剩余的问题，并对未来的努力提供见解。
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.
在本文档中，我们概述了从早期结果到最新提案的移动支持解决方案。在此过程中，我们还讨论了移动性支持的基本组件，并分析了设计空间。通过分享我们对art当前阶段的理解，我们旨在就未来机动保障的总体方向展开公开讨论。
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.
定位器：表示移动节点当前连接到Internet的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:
在现有的解决方案中，有一些属于类型1，其中大多数使用DNS作为向CN提供移动设备最新IP地址信息的手段。其余的现有解决方案属于类型2，类型2必须提供通过使用CN已知的移动设备的未更改标识符到达移动设备动态变化的位置的功能。我们可以将所有移动性支持解决方案概括为基本上涉及三个基本组件：
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.
o 用于移动设备的稳定标识符；o定位器，通常是表示移动设备当前位置的IP地址；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地址之间映射的不同方法。在type-1解决方案中，移动设备的稳定标识符是其DNS名称，定位器是其当前IP地址，DNS服务器提供映射功能。在类型2解决方案中，由于CN必须能够使用稳定标识符到达移动设备，因此标识符本身通常是IP地址；网络可以动态地找到到达移动设备的路径，或者IP地址通向移动设备的“家”，该移动设备知道移动设备的当前定位器，因此可以将CN的分组转发给移动设备。所有2型解决方案都面临两个共同问题。一个问题是，如果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.
在本节中，我们大致按照时间顺序回顾了现有的移动性支持协议，但有几个例外，我们将密切相关的协议组合在一起，以便于编写清晰明了。我们简要描述每种设计，并指出其如何实现上一节中定义的三个基本移动支持组件。
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 |
+----------------+-----+---------------+-----+
+----------------+-----+---------------+-----+
| 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的IP地址列表）。
When a CN sends a packet to a mobile node, the packet goes to the MSS nearest to the CN (MC), which either has the mobile node in the same cell and can deliver directly or broadcasts a query to all other MSSs and gets a reply from the MSS (MM) with the mobile node. If it is the latter case, MC tunnels the packet to MM, which will finally deliver the packet to the mobile node.
当CN向移动节点发送数据包时，该数据包将发送到离CN（MC）最近的MSS，该移动节点或者在同一小区中具有移动节点，并且可以直接传送，或者向所有其他MSS广播查询，并通过移动节点从MSS（MM）获得回复。如果是后一种情况，MC通过隧道将数据包传送给MM，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发送到移动设备的数据并转发到目的地MS。由于移动设备保持相同的IP地址独立于其移动，因此移动不会影响TCP连接。
An illustration of the Columbia Protocol is shown in Figure 2.
图2显示了Columbia协议的示例。
+---------+
| |
.------>| MSS |
| | |
| +---------+
| query
|
+--------+ query +--------+
| | -------------->| |
| MSS | <------------- | MSS |
| | reply | |
+--------+ ==============>+--------+
/\ data ||
|| ||
|| \/
+--------+ +---------+
| | | |
| CN | | MN |
| | | |
+--------+ +---------+
+---------+
| |
.------>| MSS |
| | |
| +---------+
| query
|
+--------+ query +--------+
| | -------------->| |
| MSS | <------------- | MSS |
| | reply | |
+--------+ ==============>+--------+
/\ data ||
|| ||
|| \/
+--------+ +---------+
| | | |
| CN | | MN |
| | | |
+--------+ +---------+
===>: data packets
--->: signaling packets
===>: 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报头被修改为允许移动设备发送的数据包携带两个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 |
| | \ / | |
| | `---' +-------+
+---------+
,---. +-------+
/ \ | CN |
( Router)<====| |
+---------+ // \ / | |
| | // `---' +-------+
| | ,---. //
| | / \ //
| Home |<--+ Router)
| Network | \ /
| | `-+-'\\
| | | \\ ,---. +-------+
| | | \\ / \=======>| |
| | +------( Router)<------+ MN |
| | \ / | |
| | `---' +-------+
+---------+
===>: data packet
--->: location update message
===>: 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也是移动的）；否则，来自CN的分组被路由到移动设备的移动路由器。移动路由器查找映射以找到移动节点的服务MAS，并将松散源路由（loose source routing，LSR）选项插入数据包的IP报头中，其中包含MAS的IP地址。通过这种方式，数据包被重定向到MAS，MAS随后将数据包发送到移动设备。至此，移动节点的定位器已经包括在LSR选项中，并且双方可以通过在传入分组中反转LSR选项来直接通信。因此，从CN到移动设备的第一个分组的路径是CN->mobile Router->MAS->mobile node，随后的分组的双向路径是mobile node<->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 |
| |----->| |
+---------+ +----------+
+---------+
| |
___________________| CN |
| | |
| +---------+
V /\
+-------+ ||
|Mobile | ||
|Router | ||
| | || Reversing LSR
+---+---+ ||
| \/
| +---------+ +----------+
| LSR Inserted | |<====>| |
+------------------->| MAS | | MN |
| |----->| |
+---------+ +----------+
-->: first data packet
==>: following data packets
-->: 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在上述三个协议之后不久就开始了移动支持方面的标准开发。移动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
虽然这三个文档在细节上有所不同，但高层设计是相似的。这里我们以移动IPv6为例。每个移动节点都有一个归属代理（HA），从中获取其归属地址（HoA），即标识符。移动节点还从其当前接入路由器获得其定位器，即转交地址（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设计类似于VIP协议，移动设备的HoA对应于VIP中的虚拟IP地址，CoA对应于常规IP地址。
The CN uses the mobile's HoA as the destination IP address when sending data to a mobile. The packets are forwarded to the Home Agent, which then encapsulates the packets to mobile node's CoA according to the mapping.
CN在向移动设备发送数据时使用移动设备的HoA作为目标IP地址。这些包被转发到归属代理，归属代理然后根据映射将这些包封装到移动节点的CoA。
To alleviate triangle routing, the CN, if it supports Route Optimization, also keeps the mapping between the mobile's HoA and CoA. Thus, the CN can encapsulate packets to the mobile directly, without going through the Home Agent. Note that in this case, the mobile needs to update its CoA to CNs as well.
为了缓解三角路由问题，如果CN支持路由优化，它还保持移动设备的HoA和CoA之间的映射。因此，CN可以直接将分组封装到移动设备，而无需经过归属代理。注意，在这种情况下，移动设备也需要将其CoA更新为CNs。
Figure 5 illustrates the data path of Mobile IPv6 without Route Optimization.
图5显示了移动IPv6的数据路径，没有进行路由优化。
+---+-----+
|HoA|DATA |
+---+-----+ +-------+
+----------------------| CN |
| +------------------->| |
| | +-------+
| |
V |
+--------+
| Home | Mapping: HoA <=> CoA
| Agent |
| |
+--------+
|| /\
|| || +-------+
|| +====================| |
|| | MN |
+=======================>| |
+-----+---+---+ +-------+
|DATA |HoA|CoA|
+-----+---+---+
+---+-----+
|HoA|DATA |
+---+-----+ +-------+
+----------------------| CN |
| +------------------->| |
| | +-------+
| |
V |
+--------+
| Home | Mapping: HoA <=> CoA
| Agent |
| |
+--------+
|| /\
|| || +-------+
|| +====================| |
|| | MN |
+=======================>| |
+-----+---+---+ +-------+
|DATA |HoA|CoA|
+-----+---+---+
==>: Tunnel
-->: regular IP
==>: 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).
这一目标通过三种机制实现。首先，它通过提供新的接入点和相应的子网前缀信息，使移动节点能够在仍然连接到当前子网的情况下检测到它已移动到新的子网。第二，移动节点还可以在其仍然存在于前一链路上时制定预期的新转交地址（NCoA），以便在其连接到新的子网链路后立即使用该地址。第三，为了减少绑定更新中断，FMIP指定了先前转交地址（PCoA）和NCoA之间的隧道。移动节点在切换后向先前的接入路由器（PAR）发送快速绑定更新，PAR开始以PCoA为目的地向NCOA发送分组。如果不建立隧道，这些数据包将被丢弃。在相反的方向上，移动节点还将分组传输到PAR，直到完成绑定更新过程（移动节点现在只能使用PCOA，因为HA或对应节点中的绑定可能还没有被更新）。
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协议中的“移动路由器”不同）。每个移动网络至少有一个移动路由器。移动路由器类似于移动IP中的移动节点，但它不是具有单个HoA，而是具有一个或多个IP前缀作为标识符。在与归属代理建立双向隧道后，移动路由器通过隧道将其移动网络的前缀（即移动前缀）分发给归属代理。移动网络的移动前缀不会泄漏到其接入路由器（即，接入路由器永远不知道它可以通过移动路由器到达移动前缀）。归属代理依次宣布移动前缀的可达性。进出移动网络的数据包通过移动路由器和归属代理之间的双向隧道流向其目的地。注意，移动对移动网络中的节点是透明的。
MSM-IP [MSM-IP] stands for Mobility Support using Multicast in IP. As one can see from its name, MSM-IP leverages IP multicast routing for mobility support. In IP multicast, a host can join a group regardless of the network to which it attaches and receive packets sent to the group after its join. Thus, mobility is naturally supported in the domains where IP multicast is deployed. Note that MSM-IP does not address the issue of the feasibility of supporting mobility through IP multicast; rather, it simply shows the possibility of using IP multicast to provide mobility support once/if IP multicast is universally deployed.
MSM-IP[MSM-IP]代表在IP中使用多播的移动性支持。从其名称可以看出，MSM-IP利用IP多播路由实现移动性支持。在IP多播中，主机可以加入一个组，而不管它连接到哪个网络，并在加入后接收发送给该组的数据包。因此，在部署IP多播的域中自然支持移动性。请注意，MSM-IP并未解决通过IP多播支持移动性的可行性问题；相反，它只是展示了使用IP多播提供移动性支持的可能性，只要普遍部署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地址用作区域标识符。本地域的网关路由器将使用该标识符到达移动节点。这三个协议都旨在将移动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路由器组成的网络中的本地移动性。移动设备将本地网络网关的IP地址作为RCoA报告给其归属代理，并在其在蜂窝IP网络内漫游时保留其本地分配的IP地址（区域标识符）。网络中的路由器监控来自移动节点的数据包，并为每个移动节点维护分布式逐跳反向路径。蜂窝IP利用来自蜂窝网络的寻呼技术来跟踪每个移动设备的位置：空闲移动节点以相对较低的频率向网关路由器发送虚拟数据包，以更新其在路由器中的反向路径。移动设备改变位置后，过时路径不会被明确清除；相反，如果寻呼计时器在下一个虚拟数据包到来之前过期，它将被路由器刷新。为了降低寻呼成本，只有一部分路由器会为空闲的移动节点建立反向路径。
When a packet from the CN arrives at the gateway, the gateway initiates a controlled flooding query. If a router knows where to forward a packet, it forwards it immediately; otherwise, it forwards the packet to all its interfaces except the one from which the packet came. Due to the paging technique, this will not become a broadcast. Once the mobile receives the query, it replies with a route-update message to the gateway, and a much more precise reverse path is then maintained by all the routers along the data path, via which the gateway router forwards packets from CN to the mobile. Note that the timer value for the precise data path is much smaller than the paging timer value, in order to avoid sending duplicate data packets to multiple places if the mobile moves during the data communication.
当来自CN的数据包到达网关时，网关发起受控泛洪查询。如果路由器知道在哪里转发数据包，它会立即转发；否则，它将数据包转发到其所有接口，但数据包来自的接口除外。由于分页技术，这将不会成为广播。一旦移动设备接收到查询，它会向网关发送路由更新消息，然后由数据路径上的所有路由器维护更精确的反向路径，网关路由器通过该路径将数据包从CN转发给移动设备。请注意，精确数据路径的计时器值远小于寻呼计时器值，以避免在移动设备在数据通信期间移动时向多个位置发送重复数据分组。
Similarly, Handoff-Aware Wireless Access Internet Infrastructure (HAWAII) [HAWAII] also aims to provide efficient local mobility support. Unlike Cellular IP, the route between the gateway router and the mobile is always maintained. When the mobile moves, HAWAII dynamically modifies the route to the mobile by installing a host-based forwarding entry on the routers located along the shortest path between the old and new base stations of the mobile. It is possible that a longer suboptimal routing path will be constructed (e.g., gateway router->old base station->new base station->mobile). Alternatively, a new sub-path between the mobile and the cross-over router can be established. Here, the cross-over router is the router at the intersection of two paths, one between the gateway and the old base station and the second between the old base station and the new base station. In HAWAII, the mobile only periodically sends refresh messages to the base station, and the base station along with other routers take care of the path maintenance.
类似地，切换感知无线接入互联网基础设施（夏威夷）[夏威夷]也旨在提供高效的本地移动支持。与蜂窝IP不同，网关路由器和移动设备之间的路由始终保持不变。当移动设备移动时，夏威夷通过在位于移动设备新旧基站之间最短路径上的路由器上安装基于主机的转发条目，动态修改到移动设备的路由。可能会构建更长的次优路由路径（例如，网关路由器->旧基站->新基站->移动）。或者，可以在移动设备和跨接路由器之间建立新的子路径。这里，交叉路由器是两条路径交叉处的路由器，一条在网关和旧基站之间，另一条在旧基站和新基站之间。在夏威夷，移动设备只定期向基站发送刷新消息，而基站和其他路由器负责路径维护。
TIMIP [TIMIP], which stands for Terminal Independent Mobile IP, integrated the design of Cellular IP and HAWAII. On one hand, it refreshes the routing paths with dummy packets if the mobile node is idle. On the other hand, handoff within a domain results in the changes of routing tables in the routers. Besides, the IP layer is coupled with layer 2 handoff mechanisms, and special nodes can work as Mobile IP proxies for legacy mobiles that do not support Mobile IP. Thus, as long as the mobile roams within the domain, the legacy node has the same degree of mobility support as a Mobile-IP-capable node.
TIMIP[TIMIP]代表独立于终端的移动IP，集成了蜂窝IP和夏威夷的设计。一方面，如果移动节点空闲，它用虚拟包刷新路由路径。另一方面，域内的切换导致路由器中路由表的变化。此外，IP层与第2层切换机制耦合，特殊节点可以作为不支持移动IP的传统移动设备的移动IP代理。因此，只要移动设备在域内漫游，遗留节点就具有与支持移动IP的节点相同的移动性支持程度。
E2E (End-to-End) communication [E2E] gets its name from its end-to-end architecture and is the first proposal that utilizes existing DNS service to track a mobile node's current location. The stable Identifier here is the domain name of the mobile. The mobile uses Dynamic DNS to update its current IP address in DNS servers. To keep the ongoing TCP connection unaffected by mobility, a TCP Migrate option is introduced to allow both ends to replace the IP addresses and ports in TCP 4-tuple on the fly. Thus, the CN can query DNS to obtain the current Locator of the mobile, and after the TCP connection is established, the mobile will be responsible for updating its Locator for this session.
E2E（端到端）通信[E2E]的名称来自其端到端架构，是第一个利用现有DNS服务跟踪移动节点当前位置的方案。这里的稳定标识符是移动设备的域名。移动设备使用动态DNS更新DNS服务器中的当前IP地址。为了保持正在进行的TCP连接不受移动性的影响，引入了TCP迁移选项，允许两端动态替换TCP 4元组中的IP地址和端口。因此，CN可以查询DNS以获得移动设备的当前定位器，并且在建立TCP连接之后，移动设备将负责更新其用于该会话的定位器。
Inspired by E2E, Mobile Stream Control Transmission Protocol (M-SCTP) [M-SCTP] was proposed in 2002. Similarly, it uses Dynamic DNS to track the mobile nodes and allows both ends to add/delete IP addresses used in Stream Control Transmission Protocol (SCTP) associations during the move.
受E2E的启发，移动流控制传输协议（M-SCTP）[M-SCTP]于2002年提出。类似地，它使用动态DNS跟踪移动节点，并允许两端在移动期间添加/删除流控制传输协议（SCTP）关联中使用的IP地址。
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]为每个主机分配一个由加密密钥构成的标识符，并在传输层和网络层之间添加一个新的主机标识层。主机标识（本质上是公钥）用于标识移动节点，而IP地址仅用于路由目的。为了重用现有代码，在传输协议和其他上层协议中使用主机标识标记（HIT），它是主机标识的128位散列值。
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可以使用DNS作为集合点，保存HITs和IP地址之间的映射。但是，HIP默认使用自己的静态基础设施会合服务器，以获得更好的会合服务。每个移动节点都有一个指定的集合服务器（RVS），用于跟踪移动节点的当前位置。当CN想要与移动节点通信时，它通过移动节点的HIT查询DNS以获得移动节点的RVS的IP地址并发送第一个数据包。在接收到第一个数据包后，RVS将其中继到移动节点。然后，移动节点和对应节点可以在直接路径上开始通信。如果移动节点移动到一个新地址，它通过发送HIP更新通知CN，其中LOCATOR参数指示其新IP地址（LOCATOR）。同时，它还更新了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]是对Internet密钥交换（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。然后，它向另一方发送一个包含更新sau地址通知的信息请求。然后，响应程序检查本地策略，并使用IP头中的值更新IKE_SA中的IP地址。它以信息性响应回复启动器，如果愿意，则启动返回路由性检查，并更新与此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不是一个成熟的移动协议，也不打算成为一个。然而，通过使用IPsec隧道模式，MOBIKE部分支持移动性，因为它可以动态更新隧道端点地址。
Connexion [Boeing] was a mobility support service provided by Boeing that uses BGP to support network mobility. Every mobile network is assigned a /24 IP address prefix (stable Identifier), and the CN uses this Identifier to reach the moving network, which means that the global routing system is responsible for finding a path to the mobile network. When an airplane moves between its access routers on the ground, it withdraws its prefix from the previous access router and announces the prefix via the new access point. As a result, the location change of the plane is effectively propagated to the rest of the world. However, if the number of moving networks becomes large, the amount of BGP updates will also increase proportionally, resulting in severe global routing dynamics.
Connexion[Boeing]是波音公司提供的一项移动支持服务，它使用BGP支持网络移动。每个移动网络被分配一个/24 IP地址前缀（稳定标识符），并且CN使用该标识符到达移动网络，这意味着全局路由系统负责查找到移动网络的路径。当飞机在地面上的访问路由器之间移动时，它会从先前的访问路由器中提取前缀，并通过新的访问点宣布前缀。因此，平面的位置更改将有效地传播到世界其他地区。但是，如果移动网络的数量变大，BGP更新的数量也会成比例增加，从而导致严重的全局路由动态。
WINMO [WINMO] (which stands for Wide-Area IP Network Mobility) was introduced in 2008 to address the routing update overhead problem of Connexion. Like Connexion, WINMO also assigns each mobile network a stable prefix. However, through two new approaches, WINMO can reduce the BGP updates overhead for mobile networks by orders of magnitude lower than those of Connexion. First, WINMO uses various heuristics to reduce the propagation scope of routing updates caused by mobile movements. Consequently, not every router may know all the mobiles' current locations. Handling this issue led to the second and more fundamental approach taken by WINMO: it adopts the basic idea from Mobile IP by assigning each mobile network a "home" in the following way. WINMO assigns each mobile network a prefix out of a small set of well-defined Mobile Prefixes. These Mobile Prefixes are announced by a small set of Aggregation Routers, which also keep track of the mobile network's current locations. Therefore, these Aggregation Routers play a similar role to Home Agents in Mobile IP and can be counted on as a last resort to reach mobile networks globally.
WINMO[WINMO]（代表广域IP网络移动性）于2008年推出，以解决Connexion的路由更新开销问题。与Connexion一样，WINMO也为每个移动网络分配一个稳定的前缀。然而，通过两种新方法，WINMO可以将移动网络的BGP更新开销降低几个数量级，低于Connexion。首先，WINMO使用各种启发式方法来减少由移动移动引起的路由更新的传播范围。因此，并非每个路由器都知道所有手机的当前位置。处理这个问题导致了WINMO采取的第二种也是更基本的方法：它采用了移动IP的基本思想，通过以下方式为每个移动网络分配一个“家”。WINMO从一小组定义良好的移动前缀中为每个移动网络分配一个前缀。这些移动前缀由一小部分聚合路由器公布，这些路由器还跟踪移动网络的当前位置。因此，这些聚合路由器在移动IP中扮演着与归属代理类似的角色，可以作为到达全球移动网络的最后手段。
To prevent frequent Interior Border Gateway Protocol (iBGP) routing updates due to the movement of mobile networks within an Autonomous System (AS), WINMO also introduces a Home Agent for the Mobile Prefixes: only a Designated BGP-speaking Router (DBR) acts as the origin of Mobile Prefixes, and mobile networks always update the addresses of their access routers (intra-AS Locators) with DBR, which resembles the binding updates in Mobile IP. Thus, packets destined to mobile networks are forwarded to DBR after they enter the border of an AS, and DBR will tunnel them to the current locations of mobile networks.
为了防止由于自主系统（AS）内移动网络的移动而导致频繁的内部边界网关协议（iBGP）路由更新，WINMO还为移动前缀引入了归属代理：只有指定的讲BGP的路由器（DBR）充当移动前缀的来源，移动网络总是使用DBR更新其接入路由器（内部AS定位器）的地址，这类似于移动IP中的绑定更新。因此，目的地为移动网络的数据包在进入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.
此外，还定义了一个新的BGP社区属性，该属性在每个分组中包含移动网络的内部AS定位器，以消除DBR引起的三角形路由问题。AS的边界路由器可以基于新属性将数据包直接隧道到移动网络。
ILNPv6 [ILNP] stands for Identifier-Locator Network Protocol for IPv6. The ILNPv6 packet header was deliberately made similar to the IPv6 header. Essentially, it breaks an IPv6 address into two components: high-order 64 bits as a Locator and low-order 64 bits as an Identifier. The Identifier identifies a host, instead of an interface, and is used in upper-layer protocols (e.g., TCP, FTP); on the other hand, the Locator changes with the movement of the mobile node, and a set of Locators can be associated with a single Identifier. Several new DNS resource records (RRs) are required, among which I (Identifier Record) and L (Locator Record) are most important. As in current Internet, the CN will query the DNS about the mobile's domain name to determine where to send the packet. During the movement, the mobile node uses Secure Dynamic DNS update to ensure that the Locator values stored in DNS are up to date. It also sends Locator Update messages to the CNs that are currently communicating with it. As an optimization, ILNPv6 supports soft-handoff, which allows the use of multiple Locators simultaneously to achieve smooth transition. ILNPv6 also supports mobile networks.
ILNPv6[ILNP]代表IPv6的标识符定位器网络协议。ILNPv6数据包报头故意与IPv6报头相似。本质上，它将IPv6地址分为两部分：高阶64位作为定位器，低阶64位作为标识符。标识符标识主机，而不是接口，并用于上层协议（例如TCP、FTP）；另一方面，定位器随着移动节点的移动而改变，并且一组定位器可以与单个标识符相关联。需要几个新的DNS资源记录（RRs），其中I（标识符记录）和L（定位器记录）最为重要。与当前的互联网一样，CN将向DNS查询移动设备的域名，以确定向何处发送数据包。在移动期间，移动节点使用安全的动态DNS更新来确保DNS中存储的定位器值是最新的。它还向当前与其通信的CNs发送定位器更新消息。作为一种优化，ILNPv6支持软切换，允许同时使用多个定位器来实现平滑切换。ILNPv6还支持移动网络。
Global Home Agent to Home Agent (HAHA) [HAHA], first proposed in 2006 as an extension to Mobile IP, aims to eliminate the triangle-routing problem in Mobile IP and NEMO by distributing multiple Home Agents globally. All the Home Agents join an IP anycast group and form an overlay network. The same home prefix is announced by all the Home Agents from different locations. Each mobile node can register with any Home Agent that is closest to it. A Home Agent H that accepts the binding request of a mobile node M becomes the primary Home Agent for M and notifies all other Home Agents of the binding [M, H] so that the binding information databases for all the mobiles in all Home Agents are always synchronized. When a mobile moves, it may switch its primary Home Agent to another one that becomes closest to the mobile.
全球归属代理到归属代理（HAHA）[HAHA]于2006年作为移动IP的扩展首次提出，旨在通过在全球分布多个归属代理来消除移动IP和NEMO中的三角路由问题。所有的家庭代理加入一个IP选播组并形成一个覆盖网络。来自不同地点的所有家庭代理都会宣布相同的家庭前缀。每个移动节点都可以向距离它最近的任何归属代理注册。接受移动节点M的绑定请求的归属代理H成为M的主归属代理，并通知所有其他归属代理绑定[M，H]，以便所有归属代理中的所有移动的绑定信息数据库始终同步。当移动设备移动时，它可以将其主归属代理切换到与移动设备最近的另一个主归属代理。
A correspondent node sends packets to a mobile's Home Address. Because of anycast routing, the packets are delivered to the nearest Home Agent. This Home Agent then encapsulates the packets to the IP address of the primary Home Agent that is currently serving the mobile node, which will finally deliver the packets to the mobile
通信节点向移动设备的家庭地址发送数据包。由于选播路由，数据包被传送到最近的归属代理。然后，该归属代理将分组封装到当前服务于移动节点的主归属代理的IP地址，该主归属代理将最终将分组传送到移动节点
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完全相同。如果归属代理分布广泛，则无需进行路由优化，三角形路由问题自然会得到缓解。
The data flow in Global HAHA is shown in Figure 6.
全球HAHA中的数据流如图6所示。
+------+ +------+ +-----+
| HA |-------------| HA | | |
| | | | | CN |
+--+---+ +------+++----+ +-----+
| | || /\
| | || ||
| | || ||
| | || ||
+--+---+------+ || ||
| |<==============+ ||
| HA |==============================+
+-++---+
|| /\
\/ ||
+---++-+ ===>: data flow
| | ----: HA overlay network
| MN |
+------+
+------+ +------+ +-----+
| 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域中的定位器）。然后，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.
回到我的Mac（BTMM）[RFC6281]是一种移动支持的工程方法，自2007年Mac OS Leopard发布以来就已部署。每个用户都有一个MobileMe帐户（包括BTMM服务），苹果公司为所有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更新动态刷新其当前位置。每个主机在引导时生成一个IPv6唯一本地地址（ULA）[RFC4193]，该地址作为其拓扑独立的标识符存储在DNS数据库中。主机的当前IPv4地址（如果主机位于NAT后面，则为NAT框的IPv4地址）与NAT遍历所需的传输端口号一起存储在SRV资源记录[RFC2782]中。每个节点都与DNS服务器建立一个长期查询（LLQ）会话，以便DNS服务器可以在其查询的答案发生更改时立即通知每个节点。主机在传输协议和应用程序中使用其标识符，并使用UDP/IPv4封装，使用从SRV RR获取的信息传递数据包。请注意，此处的定位器是IPv4地址加上传输端口号，IPv6地址仅用于识别目的。事实上，它可以是任何形式的标识符（例如，域名）；BTMM选择使用IPv6地址，以便其实现可以重用现有代码。
BTMM is currently used by millions of subscribers. It is simple and easy to deploy. However, the current applications use BTMM service in a "stop-and-reconnect" fashion. It remains to be seen how well BTMM can support continuous communications while hosts are on the move, for example, as needed for voice calls.
BTMM目前被数百万用户使用。它简单且易于部署。然而，当前的应用程序以“停止并重新连接”的方式使用BTMM服务。BTMM在主机移动时（例如，根据语音通话需要）支持连续通信的能力还有待观察。
Figure 7 shows the basic architecture of BTMM.
图7显示了BTMM的基本架构。
DDNS update +--------+ DDNS update
+--------------->| |<-------+
| | DNS | |
| LLQ | | LLQ |
| +---------->| |<----+ |
| | | | | |
| | +--------+ | |
| | | | +---------+
| V +---+--+----+ | |
++-------+ | +-------| |
|Endhost1| Tunnel | NAT +------>|Endhost2 |
| |<=====================================>| |
+--------+ | | | |
+-----------+ +---------+
DDNS update +--------+ DDNS update
+--------------->| |<-------+
| | DNS | |
| LLQ | | LLQ |
| +---------->| |<----+ |
| | | | | |
| | +--------+ | |
| | | | +---------+
| V +---+--+----+ | |
++-------+ | +-------| |
|Endhost1| Tunnel | NAT +------>|Endhost2 |
| |<=====================================>| |
+--------+ | | | |
+-----------+ +---------+
Figure 7
图7
LISP-Mobility [LISP-Mobility] is a relatively new design. Its designers hope to utilize functions and services provided by Locator/ID Separation Protocol (LISP) [LISP], which is designed for Internet routing scalability, to support mobility as well. Conceptually, LISP-Mobility may seem similar to some protocols we have mentioned so far, such as ILNPv6 and Mobile IP. Lightweight Ingress Tunnel Router and Egress Tunnel Router functions are implemented on each mobile node, and all the packets to and from the mobile node are processed by the two router functions (so the mobile node looks like a LISP site). Each mobile node is assigned a static Endpoint ID, as well as a preconfigured Map-Server. When a mobile node roams into a network and obtains a new Routing Locator, it updates its Routing Locator set in the Map-Server, and it also clears the cached Routing Locator in the Ingress Tunnel Routers or Proxy Tunnel Routers of the CNs. Thus, the CN can always learn the up-to-date location of the mobile node by the resolution of the mobile node's Endpoint ID, either issued by itself or issued after receiving the notification from the mobile node about the staled cache. The data would always travel through the shortest path. Note that both Endpoint IDs and Routing Locators are essentially IP addresses.
LISP Mobility[LISP Mobility]是一种相对较新的设计。它的设计者希望利用Locator/ID分离协议（LISP）[LISP]提供的功能和服务来支持移动性，LISP是为互联网路由可扩展性而设计的。从概念上讲，LISP移动性似乎与我们迄今为止提到的一些协议类似，例如ILNPv6和移动IP。轻量级入口隧道路由器和出口隧道路由器功能在每个移动节点上实现，进出移动节点的所有数据包都由这两个路由器功能处理（因此移动节点看起来像一个LISP站点）。每个移动节点都分配了一个静态端点ID以及一个预配置的映射服务器。当移动节点漫游到网络中并获得新的路由定位器时，它更新其在地图服务器中设置的路由定位器，并且它还清除CNs的入口隧道路由器或代理隧道路由器中的缓存路由定位器。因此，CN总是可以通过解析移动节点的端点ID来学习移动节点的最新位置，该端点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.
所有现有的移动支持设计可大致分为两种基本方法。第一个是通过动态路由支持移动性。在这种设计中，移动设备保持其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).
在基于路由的方法中，确定两个子类也是值得的。一个是基于广播的，另一个是基于路径的。在前一种情况下，要么将移动设备的位置信息主动广播到整个网络，要么需要主动广播查询来获取移动设备的位置信息（例如，Columbia和Connexion）；另一方面，在后一种情况下，基于主机的路径由路由系统维护（例如，蜂窝IP、夏威夷和timp）。
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.
移动支持的第二种方法是提供移动设备的稳定标识符与其动态变化的IP地址之间的映射。移动设备不需要在每次移动时通知世界，只需要更新单个绑定位置的位置更改。在这种方法中，如果在IP层使用一个级别的间接寻址，如在移动IP的情况下，它有一个引入三角形路由的潜在副作用；否则，如果两个终端节点知道彼此的移动，则意味着两端必须支持相同的移动协议。
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.
然而，还有第三种情况，协议将上述方法结合在一起，希望保留两者的优点并消除一些缺点。WINMO是这种情况下的典型协议。
In Figure 8, we show the classification of the existing protocols according to the above analysis.
在图8中，我们根据上述分析显示了现有协议的分类。
+---------------+-------------------------------------------+
| | VIP, LSR, Mobile IP, HMIP, NEMO, E2E, |
| Mapping-based | M-SCTP, ILNPv6, HIP, FMIP, PMIP, |
| | BTMM, GLOBAL HAHA, LISP-Mobility |
+---------------+-------------------------------------------+
| | Columbia, Connexion |
| Routing-based +-------------------------------------------+
| | Cellular IP, HAWAII, TIMIP, MSM-IP |
+---------------+-------------------------------------------+
| Combination | WINMO |
+---------------+-------------------------------------------+
+---------------+-------------------------------------------+
| | 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网络中保存映射的附加组件）。这里我们主要讨论基于映射的方法。
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.
第二个设计选择是对移动设备和CN隐藏移动性，这是基于一个更保守的假设，即移动设备和CN都不支持移动性。PMIP和TIMIP等协议采用这种设计。该设计中的协议操作类似于第一类中的协议操作，但是一个显著的区别是，在这里，与移动相关的信令（例如，归属代理的更新定位器）由网络中的实体而不是移动设备本身来处理。因此，移动设备幸福地假设它总是在同一个子网中。
The third one is to let both the mobile and the CN be mobility-aware. As a result, the network is not aware of the mobility, and no additional component is required. As an increasing number of mobile devices are connected to the Internet (Why hide mobility from them?), this design choice seems to be more and more appealing. One common approach taken by this design is to use DNS to keep track of mobiles' current locations. Mobiles use dynamic DNS updates to keep their DNS servers updated with their current locations. This approach re-utilizes the DNS infrastructure, which is ubiquitous and quite reliable, and makes the mobility support protocol simple and easy to deploy. Protocols like E2E, ILNP, and BTMM fall into this design. Although HIP adds special-purpose rendezvous servers to the network to replace the role of DNS, both mobile and CN are still mobility-aware; hence, it is also classified in this category.
第三个是让移动设备和CN都具有移动性意识。结果，网络不知道移动性，并且不需要额外的组件。随着越来越多的移动设备连接到互联网（为什么要对它们隐藏移动性？），这种设计选择似乎越来越有吸引力。这种设计采用的一种常见方法是使用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 |
+-------------+----------------------------------+
+-------------+----------------------------------+
| Design 1 | VIP, LSR, Mobile IP, HMIP, NEMO, |
| | Global HAHA |
+-------------+----------------------------------+
| Design 2 | PMIP, TIMIP |
+-------------+----------------------------------+
| Design 3 | E2E, M-SCTP, ILNPv6, HIP, |
| | BTMM, LISP-Mobility |
+-------------+----------------------------------+
Figure 9
图9
At the time of this writing, cellular networks are providing the largest operational global mobility support, using a service model that bundles together device control, network access control, and mobility support. The tremendous success of the cellular market speaks loudly that the current cellular service model is a viable one and is likely to continue into the foreseeable future. Consequently, there is a strong advocate in the IETF that we continue the cellular way of handling mobility, i.e., instead of letting mobile devices participate in the mobility-related signaling themselves, the network entities deployed by the operators should take care of any and all signaling processes of mobility support. A typical example along this direction is Proxy Mobile IP, in which LMA works together with MAGs to assure the reachability to the mobile using its Home Prefixes, as long as the mobile roams within the same provider's domain.
在撰写本文时，蜂窝网络正在使用一种将设备控制、网络访问控制和移动支持捆绑在一起的服务模型，提供最大的全球移动支持。蜂窝市场的巨大成功有力地表明，当前的蜂窝服务模式是可行的，并且在可预见的未来可能会继续下去。因此，IETF强烈主张我们继续采用蜂窝方式处理移动性，即，运营商部署的网络实体应负责移动性支持的任何和所有信令过程，而不是让移动设备本身参与移动性相关信令。沿着这一方向的一个典型示例是代理移动IP，其中LMA与MAG一起工作，以确保只要移动设备在同一提供商的域内漫游，就可以使用其家庭前缀访问移动设备。
One main reason for this approach is perhaps backward compatibility. By not requiring the participation of mobiles in the control-signaling process, it avoids any changes to the mobile nodes so that the mobile nodes can stay simple and all the legacy nodes can obtain the same level of mobility services as the latest mobile devices. According to the claim of 3G vendors and operators, transparent mobility support is a key aspect for success as they learn from their deployment experience.
这种方法的一个主要原因可能是向后兼容性。通过在控制信令过程中不需要移动设备的参与，它避免了对移动节点的任何更改，从而移动节点可以保持简单，并且所有遗留节点可以获得与最新移动设备相同级别的移动服务。根据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.
根据规模，流动管理工作也可分为两类：本地流动管理和全球流动管理。
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.
本地移动性管理的一个问题是，它通常需要基础设施支持，例如PMIP中的MAG或HMIP中的MAP。这些类型的本地设备基本上是所有小型领域所必需的，这可能是一项巨大的投资。
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.
然而，两种规模的移动性管理使得设计者能够设计适合特定用户需求的协议；它还支持逐步部署本地增强功能，同时不丧失全局漫游能力。在可预见的未来，两者共存似乎是一个正确的选择。
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 |
+-----------+-----------------------------------------+
+-----------+-----------------------------------------+
| | 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的一个位置移动一样。它通过将订阅者的数据从订阅者的当前SGSN传输到处理订阅者会话的GGSN来实现这一点。在某种程度上，它是PMIP的非IETF变体，GGSN分别类似于LMA和SGSN类似于MAG。
There is also work on application-layer mobility support, most notably SIP-based mobility support [ALM-SIP]. SIP was initially designed as an application signaling protocol for multimedia, and later researchers noticed its potential capability for mobility support. When the mobile initiates a session with CN, normal SIP-signaling procedure is performed to establish the session. When the mobile moves to a new network while the session is ongoing, it send a RE-INVITE message with the existing session but reveals the new IP address to the CN. The home SIP server is also updated with the
还有关于应用层移动性支持的工作，最著名的是基于SIP的移动性支持[ALM-SIP]。SIP最初设计为一种多媒体应用信令协议，后来研究人员注意到其潜在的移动性支持能力。当移动设备发起与CN的会话时，执行正常的SIP信令过程以建立会话。当移动设备在会话进行期间移动到新网络时，它会发送一条与现有会话相关的重新邀请消息，但会向CN显示新的IP地址。家庭SIP服务器也会更新为
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.
移动后手机的最新位置信息。但是，当移动设备的IP地址发生变化时，基于SIP的方法无法维护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）的问题。MEXT工作组仍在讨论这两个问题。一些研究人员认为，研究团体应该首先设计一个移动支持协议的“勉强工作”版本，而不考虑良好的性能特征和复杂的安全机制，在现实世界中推广，然后改进它。然而，对于什么是基本特征以及哪些安全机制更好，存在不同的观点。
Third, almost all the mobility support protocols assume that the mobile nodes have network connectivity anywhere, anytime. In reality, however, this is not always the case. Nevertheless,
第三，几乎所有的移动支持协议都假设移动节点随时随地都具有网络连接。然而，事实并非总是如此。然而
wireless access is available in more and more places, and it is foreseeable that in the near future, the coverage of wireless access in different forms (WiFi, Wimax, 3G/4G) will be ubiquitous.
无线接入在越来越多的地方可用，可以预见，在不久的将来，各种形式（WiFi、Wimax、3G/4G）的无线接入覆盖将无处不在。
In order for users to benefit from mobility support, it is important to keep the TCP sessions uninterrupted by the mobility. If the durations of the sessions are short (e.g., web browsing), the probability is high that the TCP sessions finish before the handover happens; even if the TCP session is interrupted by the handover, the cost is usually low (e.g., refresh the web page). However, if the TCP sessions are typically long (e.g., downloading large files and voice calls), the interruptions during the handover would become unacceptable.
为了让用户从移动性支持中受益，保持TCP会话不受移动性影响是很重要的。如果会话持续时间较短（例如，网络浏览），则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地址（例如，HoA）或等效的IP地址（例如，HIT），以便隐藏移动性，或者修改TCP，以便两端可以在保持已建立的会话（例如，E2E）的同时更改IP地址。
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.
另一个问题是支持同时运动。在某些场景中，只有一端是移动的，而另一端总是静态的；此外，两者之间的通信始终由移动端发起。到目前为止，许多应用程序都属于这一类。通常，服务器端是静态的，客户端是移动的；通常，客户机会首先联系服务器。因此，在这些场景中，不需要同时移动的支持。但是，在其他场景中，两端可能同时移动。例如，在语音呼叫期间，两个移动节点可能同时经历切换。在这种情况下，需要一个集合点来保持移动设备的当前位置，以便它们能够在同时移动后找到彼此。此外，如果静态服务器想要将信息推送到移动客户端，还需要一个集合点。
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?
通信两端的移动性感知与向后兼容性问题密切相关。互联网已经运行了20多年，互联网的规模如此之大，以至于不可能在一夜之间升级整个系统。因此，移动性支持系统设计者也不可能忽视这个问题：如何在协议设计中确定移动性感知，以及向后兼容性有多重要？
In the following text, we discuss the trade-offs of the design choices mentioned in Section 5.2.
在下文中，我们将讨论第5.2节中提到的设计选择的权衡。
The advantage of the first design choice is that the mobile does not lose the ability to communicate with legacy nodes while roaming around, i.e., the mobile can benefit from unilateral deployment of mobility support. Another potential advantage is that the static nodes do not need to be bothered by the mobility of the mobiles, which saves resources and could be desirable if the CN is a busy server. The disadvantage of this design is also well known: it introduces triangle routing, which significantly increases the delays in the worst cases. There are means to remedy the problem, e.g., Route Optimization in Mobile IP if a CN is mobility-capable and distribution of Home Agents as Global HAHA does, at the expense of increasing complexity.
第一种设计选择的优点是，移动设备在漫游时不会失去与遗留节点通信的能力，即，移动设备可以受益于移动支持的单边部署。另一个潜在优势是，静态节点不需要被移动设备的移动性所困扰，这节省了资源，并且如果CN是繁忙的服务器，这可能是可取的。这种设计的缺点也是众所周知的：它引入了三角形路由，在最坏的情况下会显著增加延迟。有一些方法可以解决这个问题，例如，如果CN具有移动性，则在移动IP中进行路由优化，并像Global HAHA那样分发家庭代理，但代价是复杂性增加。
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.
第二种设计迎合了互联网（和用户）的惰性，从用户的角度保持一切现状。它就像蜂窝网络一样，有智能网络和哑终端。其优点是，遗留节点可以受益于移动性支持，而无需升级。然而，成本也不小：用户在移动性管理方面失去了控制自由，网络中的大量实体需要升级。
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.
第三种设计假设另一端可能也具有移动性（到目前为止，通过移动设备访问互联网的人比通过台式机访问互联网的人多），因此根本不提供向后兼容性；然而，作为一种权衡，系统设计变得更加简单，数据路径总是最短的。
We all know that backward compatibility is important in system design. But how important is it? How much effort should we make for this issue? At least for now, the answer is not yet clear.
我们都知道向后兼容性在系统设计中很重要。但它有多重要？在这个问题上我们应该做多少努力？至少就目前而言，答案还不清楚。
As our survey suggests, multiple solutions for mobility support are already exist, and it is almost for sure that the mobility support systems in the future are going to be heterogeneous. However, as of today, the interoperation between different protocols is still problematic. For example, when a mobile node supporting Mobile IP only wants to communicate with another mobile with only HIP support, neither of them can benefit from mobility support.
正如我们的调查所表明的，移动支持的多种解决方案已经存在，并且几乎可以肯定，未来的移动支持系统将是异构的。然而，到今天为止，不同协议之间的互操作仍然存在问题。例如，当支持移动IP的移动节点只想与仅支持臀部的另一移动节点通信时，它们都不能从移动支持中受益。
This situation reminds us the days before IP was adopted. In that time, the hosts in different networks were not able to communicate with each other. IP merged the networks and created the Internet, where each host can freely communicate with any other host. Is it necessary to introduce something like IP to mobility support in the future? Is it possible to design an architecture so that it glues all the mobility support systems together? We believe the answers to both of these questions are "yes".
这种情况让我们想起了IP被采用之前的日子。当时，不同网络中的主机无法相互通信。IP合并了网络并创建了Internet，在Internet上，每个主机都可以与任何其他主机自由通信。将来是否有必要引入类似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.
[Boeing]Andrew，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.
[Columbia]Ioannidis，J.，Duchamp，D.，和G.Maguire，“基于IP的移动互联网协议”，ACM SIGCOM CCR，1991年。
[E2E] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to Host Mobility", ACM Mobicom, 2000.
[E2E]Snoren，A.和H.Balakrishnan，“主机移动性的端到端方法”，ACM Mobicom，2000年。
[GTP] "GPRS Tunneling Protocol Across Gn and Gp Interface", 3G TS 29.060 v3.5.0.
[GTP]“通过Gn和Gp接口的GPRS隧道协议”，3G TS 29.060 v3.5.0。
[HAHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home Agents Towards Internet-scale Mobility Deployment", ACM CoNEXT, 2006.
[哈哈]Wakikawa，R.，Valadon，G.，和J.Murai，“将家庭代理迁移到互联网规模的移动部署”，ACM CoNEXT，2006年。
[HAWAII] Ramjee, R., Varadhan, K., and L. Salgarelli, "HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless Networks", IEEE/ACM Transcations on Networking, 2002.
[夏威夷]Ramjee，R.，Varadhan，K.，和L.Salgarelli，“夏威夷：支持广域无线网络移动性的基于域的方法”，IEEE/ACM网络转换，2002年。
[ILNP] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, and Security", MobiWAC 2007.
[ILNP]Atkinson，R.，Bhatti，S.和S.Hailes，“将移动与多主、NAT和安全统一起来的提案”，MobiWAC 2007年。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, March 2009.
[LISP]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，正在进行的工作，2009年3月。
[LISP-Mobility] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, May 2011.
[LISP Mobility]Farinaci，D.，Lewis，D.，Meyer，D.，和C.White，“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.
[LSR]Bhagwat，P.和C.Perkins，“基于互联网协议（IP）的移动网络系统”，移动和位置无关计算研讨会，1993年。
[M-SCTP] Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and Prototypical Implementation of An End-to-End Mobility Concept", 5th Intl. Workshop on the Internet Challenge, 2002.
[M-SCTP]Xing，W.，Karl，H.，和A.Wolisz，“M-SCTP：端到端移动概念的设计和原型实现”，第五届互联网挑战国际研讨会，2002年。
[MSM-IP] Mysore, J. and V. Bharghavan, "A New Multicast-based Architecture for Internet Host Mobility", ACM Mobicom, 1997.
[MSM-IP]Mysore，J.和V.Bharghavan，“一种新的基于多播的互联网主机移动架构”，ACM Mobicom，1997年。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[RFC4651]Vogt，C.和J.Arkko，“移动IPv6路由优化增强的分类和分析”，RFC 4651，2007年2月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月。
[RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC5454]Tsirtsis，G.，Park，V.和H.Soliman，“双栈移动IPv4”，RFC 54542009年3月。
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568]Koodli，R.，“移动IPv6快速切换”，RFC 5568，2009年7月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]Perkins，C.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281]Cheshire，S.，Zhu，Z.，Wakikawa，R.，和L.Zhang，“理解苹果的回到我的Mac（BTMM）服务”，RFC 62812011年6月。
[TIMIP] Grilo, A., Estrela, P., and M. Nunes, "Terminal Independent Mobility For IP (TIMIP)", IEEE Communications Magazine, 2001.
[TIMIP]Grilo，A.，Estrela，P.，和M.Nunes，“IP终端独立移动性（TIMIP）”，IEEE通信杂志，2001年。
[VIP] Teraoka, F., Yokote, Y., and M. Tokoro, "A Network Architecture Providing Host Migration Transparency", ACM SIGCOMM CCR, 1991.
[VIP]Teraoka，F.，Yokote，Y.和M.Tokoro，“提供主机迁移透明性的网络体系结构”，ACM SIGCOMM CCR，1991年。
[WINMO] Hu, X., Li, L., Mao, Z., and Y. Yang, "Wide-Area IP Network Mobility", IEEE INFOCOM, 2008.
[WINMO]胡，X.，李，L.，毛，Z.，和Y.杨，“广域IP网络移动性”，IEEE INFOCOM，2008年。
Authors' Addresses
作者地址
Zhenkai Zhu UCLA 4805 Boelter Hall, UCLA Los Angeles, CA 90095 USA
朱振凯加州大学洛杉矶分校4805波尔特大厅，加州大学洛杉矶分校，美国加利福尼亚州90095
Phone: +1 310 993 7128
EMail: zhenkai@cs.ucla.edu
Phone: +1 310 993 7128
EMail: zhenkai@cs.ucla.edu
Ryuji Wakikawa Toyota ITC 465 Bernardo Avenue Mountain View, CA 94043 USA
美国加利福尼亚州伯纳德道山景大道465号丰田国际贸易中心，邮编94043
EMail: ryuji.wakikawa@gmail.com
EMail: ryuji.wakikawa@gmail.com
Lixia Zhang UCLA 3713 Boelter Hall, UCLA Los Angeles, CA 90095 USA
张丽霞加州大学洛杉矶分校博尔特大厅3713号，加州大学洛杉矶分校，美国加利福尼亚州90095
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.edu
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.edu