Network Working Group Z. Zhu
Internet-Draft UCLA
Intended status: Informational R. Wakikawa
Expires: April 29, 2010 TOYOTA ITC
L. Zhang
UCLA
October 26, 2009
A Survey of Mobility Support In the Internet
draft-zhu-mobility-survey-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zhu, et al. Expires April 29, 2010 [Page 1]
Internet-Draft Mobility Survey October 2009
Abstract
Over the last two decades many research efforts have been devoted to
developing solutions for mobility support over the global Internet,
which resulted in a variety of proposed solutions. In this draft we
conducted a systematic survey of the previous efforts to gain an
overall understanding on the solution space of mobility support.
This draft reports our finding and identifies remaining issues in
providing ubiquitous and efficient global scale mobility support.
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 . . . . . . . . . . . . . . . . . . . . 5
4.2. Sony Protocol . . . . . . . . . . . . . . . . . . . . . . 7
4.3. LSR Protocol . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. MSM-IP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Cellular IP, HAWAII and TIMIP . . . . . . . . . . . . . . 12
4.7. Hierarchical Mobile IP (HMIP) . . . . . . . . . . . . . . 13
4.8. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.9. E2E and M-SCTP . . . . . . . . . . . . . . . . . . . . . . 14
4.10. Host Identity Protocol . . . . . . . . . . . . . . . . . . 15
4.11. Connexion and WINMO . . . . . . . . . . . . . . . . . . . 15
4.12. ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.13. Global HAHA . . . . . . . . . . . . . . . . . . . . . . . 17
4.14. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 18
4.15. Mobile Me . . . . . . . . . . . . . . . . . . . . . . . . 19
4.16. LISP-Mobility . . . . . . . . . . . . . . . . . . . . . . 20
5. Different Directions towards Mobility Support . . . . . . . . 20
5.1. Routing-based Approach v.s. Mapping-based Approach . . . . 21
5.2. IP Layer Indirection v.s. Mobility Exposure . . . . . . . 22
5.3. Operator-Controlled Approach v.s. User-controlled . . . . 24
5.4. Local and Global Scale Mobility . . . . . . . . . . . . . 24
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Backward Compatibility . . . . . . . . . . . . . . . . . . 26
6.2. Undisrupted TCP Connection . . . . . . . . . . . . . . . . 27
6.3. Interconnecting Heterogeneous Mobility Support Systems . . 28
6.4. Flat-id Based Routing . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Zhu, et al. Expires April 29, 2010 [Page 2]
Internet-Draft Mobility Survey October 2009
1. Introduction
This draft reports our findings from a historical survey of the
Internet mobility research and standardization efforts since the
early '90s. 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 are yet to discover about the problem space
as well as the solution space. The second motivation is the rapid
growth in Internet access via mobile devices in recent years, which
will inevitably lead to new Internet application development in
coming years and further underscore the importance of Internet
mobility support. We believe that a historical review of all the
proposed solutions so far can help us not only identify their
commonalities and differences, but also shed insight on future
efforts.
In the rest of this document, we provide an overview of the mobility
support solutions from the early works to the most recent proposals.
In the process we also discuss the essential components in mobility
support, 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.
2. Terminology
This document uses a number of terms to refer to the entities or
functions that are required in mobility support. Readers are also
encouraged to scan [RFC3753] before reading this document.
Identifier: A stable piece of information that can be used to
identify a mobile node. Anything could be used as an
identifier as long as it remains unchanged when the mobile
node roams around.
Locator: The IP address that indicates the mobile node's current
location. 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.
Mapping: In this document, mapping specifically means the mapping
between a mobile's identifier and it's Locator.
Zhu, et al. Expires April 29, 2010 [Page 3]
Internet-Draft Mobility Survey October 2009
Rendezvous Point: The place where the mapping is held. Some other
functions such as data forwarding may also be placed on the
rendevzvous point.
Global Mobility Management: The mobility management in a global
scale. It keeps the mobile's reachability during the
mobile's long distance moving, either geographically or
topologically.
Local Mobility Management: The mobility management within a
topologically local domain. It tries to keep the mobile's
local movements transparent to the network entity that
manages the mobile's mobility in a global scale. It also
tries to improve the handoff performance.
Operator Controlled Mobility Management: The mobile node does not
get involved in mobility management. Instead, the network
entities, which are controlled by the network operators, do
all the mobility related signalling job on behalf of the
mobile node.
User Controlled Mobility Management: The mobile node participates in
the mobility management. Typically, the mobile updates the
mapping after it changes locations and refresh the mapping at
a user-defined frequency.
3. Basic Components in Mobility Support Protocols
The basic question in mobility support is how to make data reach a
moving receiver (a mobile in short; here we do not distinguish
between mobile nodes and mobile subnets). Whoever sending data to a
mobile must be able to identity the receiver via a piece of stable
information, where "stable" means that the information does not
change as the mobile moves. However if the sender's knowledge about
the mobile does not change while the mobile moves, some means must
exist to find the mobile's dynamically changing location by using
that unchanged identifier of the mobile known to the sender.
The above intuitive reasoning leads to the following observation--
mobility support essentially involves three basic components:
o a stable identifier for a mobile;
o a locator, which is usually an IP address; and
o a mapping between the two.
Although mobility support can be provided through multiple different
ways, we show in the next section that different mobility support
Zhu, et al. Expires April 29, 2010 [Page 4]
Internet-Draft Mobility Survey October 2009
designs are merely different ways to choose mobile identifiers and
different approaches to provide mapping between the identifiers and
the mobiles' current IP addresses.
4. Existing Mobility Support Protocols
In this section, we review the existing mobility support protocols
roughly in the time order, with a few exceptions where, for the sake
of convenience, we grouped closely related protocols together. 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.
+----------------+-----+---------------+-----+
| Protocol Name |Year | Protocol Name |Year |
+----------------+-----+---------------+-----+
| Columbia |1991 | TIMIP |2001 |
+----------------+-----+---------------+-----+
| Sony |1991 | M-SCTP |2002 |
+----------------+-----+---------------+-----+
| LSR |1993 | HIP |2003 |
+----------------+-----+---------------+-----+
| Mobile IP |1996 | Connexion |2004 |
+----------------+-----+---------------+-----+
| MSM-IP |1997 | ILNP |2005 |
+----------------+-----+---------------+-----+
| Cellular IP |1998 | Global HAHA |2006 |
+----------------+-----+---------------+-----+
| HMIP |1998 | PMIP |2006 |
+----------------+-----+---------------+-----+
| HAWAII |1999 | Mobile Me |2007 |
+----------------+-----+---------------+-----+
| NEMO |2000 | WINMO |2008 |
+----------------+-----+---------------+-----+
| E2E |2000 | LISP-Mobility |2009 |
+----------------+-----+---------------+-----+
Figure 1: A time table of mobility protocol development
4.1. Columbia Protocol
This protocol was originally designed to provide mobility support on
a campus. A router called Mobile Support Station (MSS) is set up in
each wireless cell, which serves as the default access router for all
mobile nodes in that cell. A mobile node obtains an IP address from
Zhu, et al. Expires April 29, 2010 [Page 5]
Internet-Draft Mobility Survey October 2009
a special block of IP addresses and keeps it regardless of its
current location. Each MSS keeps a list of mobile nodes that are
currently in its cell. When a correspondent node sends a packet to a
mobile node, the packet is first routed to the MSS that is closest to
the correspondent node. This MSS will deliver the packet directly to
the mobile node if the mobile node happens to be in its cell, or
otherwise sends a query message to all other MSSs on the campus to
find out the current location of the mobile node. Each MSS in turn
checks its tracking list of mobile nodes, and sends a reply if the
target mobile node is on the list. The MSS which sends the query can
now forward the packet to the MSS that serves the mobile node.
Here, the three basic components are:
o Identifier: the mobile node's IP address from the special IP
address block;
o Locator: the IP address of the serving MSS;
o Mapping: the mapping between the identifier and locator is not
established a prior, but discovered in reaction to packets through
flooding.
Zhu, et al. Expires April 29, 2010 [Page 6]
Internet-Draft Mobility Survey October 2009
An illustration of Columbia Approach is shown in Figure 2.
+---------+
| |
.------>| MSS |
| | |
| +---------+
| query
|
+--------+ query +--------+
| | -------------->| |
| MSS | <------------- | MSS |
| | reply | |
+--------+ ==============>+--------+
/\ data ||
|| ||
|| \/
+--------+ +---------+
| | | |
| CN | | MN |
| | | |
+--------+ +---------+
===>: data packets
--->: signaling packets
Figure 2: Columbia Protocol
4.2. Sony Protocol
In this protocol, the IP header is modified to allow packets sent by
a mobile to carry two IP addresses: a Virtual IP address and a
conventional IP address. The mobile obtains its Virtual IP address
from its home network, and the conventional IP address from its
access router. Every time the mobile node changes its location, it
sends a special packet containing the mapping between its Virtual IP
address and conventional IP address to its home network, which stores
the mapping. Routers in the middle as well as the correspondent
hosts can also cache a set of mappings for mobile nodes.
To deliver data to a mobile, the correspondent node uses the mobile's
Virtual IP address as the destination IP address. If a router along
the way from the correspondent node to the mobile's home network
happens to have a mapping for mobile, it modifies the destination IP
address field and forwards the packets to the mobile's current
location; otherwise, the packet will flow to the mobile's home
network, which then chnages the packet's destination address to the
mobile's current location according to the mapping and delivers the
Zhu, et al. Expires April 29, 2010 [Page 7]
Internet-Draft Mobility Survey October 2009
packets to the mobile. Note that the destination IP address field
can be modified again if the packet encounters a router with more
recent mapping.
The three basic components are easy to identify:
o Identifier: the mobile node's Virtual IP address;
o Locator: the mobile node's conventional IP address;
o Mapping: the binding between the mobile's Virtual IP address and
conventional IP address, which is sent by the mobile to its home
network and may also be cached in routers and correspondent host.
Figure 3 shows how sony protocol works.
,---. +-------+
/ \ | CN |
( Router)<====| |
+---------+ //\ / | |
| | // `---' +-------+
| | ,---. //
| | / \ //
| Home |<--- Router)//
| Network | \ / \\
| | `---'\ \\
| | \ \\,---. +-------+
| | \ / \=======>| |
| | \( Router)<------+ MN |
| | \ / | |
| | `---' +-------+
+---------+
===>: data packets
--->: location update message
Figure 3: Sony Protocol
4.3. LSR Protocol
In LSR each mobile has a designated router, called Mobile Router,
that manages its mobility. Mobile Router assigns an IP address for
each mobile it manages and announce reachability to those IP
addresses. Another network entity required is Mobile Access Station
(MAS) which connects to the mobile at its current location. The
mobile node always reports the current serving MAS to its Mobile
Router.
If the correspondent node and the mobile node are attached to the
same MAS, then the MAS simply forwards packets between the two;
otherwise, the packet sent by the correspondent node is routed to the
Zhu, et al. Expires April 29, 2010 [Page 8]
Internet-Draft Mobility Survey October 2009
Mobile Router who assinged the IP address to 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. This way,
the packet is redirect to the MAS which then delivers the packet to
the mobile. After that, the mobile node reverses the LSR and replies
to the correspondent node; the correspondent node, similarly, sends
the subsequent packets directly through MAS (i.e. without going
through the Mobile Router) by reversing the LSR.
Let's identify the three basic components for this protocol:
o Identifier: the mobile's IP address assigned by its Mobile Router;
o Locator: the IP address of the serving MAS;
o Mapping: the mapping between the above two kept at the Mobile
Router.
Figure 4 shows the basic operation of LSR protocol.
+---------+
| |
___________________| CN |
| | |
| +---------+
V /\
+-------+ ||
|Mobile | ||
|Router | ||
| | || Reversing LSR
+---+---+ ||
| \/
| +---------+ +----------+
| LSR Inserted | |<====>| |
+------------------->| MAS | | MN |
| |----->| |
+---------+ +----------+
-->: first data packet
==>: following data packets
Figure 4: LSR Protocol
4.4. Mobile IP
IETF begun standard development in mobility support soon after the
above three protocols. The first version of Mobile IP standard was
developed in 1996. Later, IETF further made Mobile IPv4 [RFC3220]
and Mobile IPv6 [RFC3775] standards in 2002 and 2004, respectively.
Zhu, et al. Expires April 29, 2010 [Page 9]
Internet-Draft Mobility Survey October 2009
Let's look at Mobile IPv6 first. Each mobile node has a Home Agent,
from which it acquires its Home Address (HoA). Unlike LSP Protocol,
the mobile node also obtains a Care-of Address (CoA) from its current
access router. Whenever the mobile node changes its point of
attachment and gets a new CoA, it sends a Binding Update message to
notify the Home Agent about the new CoA. Conceptually Mobile IPv6
design looks similar to Sony Protocol, with the mobile's HoS
corresponding to the Virtual Address in Sony, and the CoA
corresponding to the Conventional IP address.
The correspondent node uses the mobile's HoA as the destination IP
address when sending to a mobile. The packets are forwarded to the
Home Agent since Home Agent is announcing the reachability to the
HoA. Home Agent then encapsulates the packets to mobile node's CoA
according to the mapping. If the correspondent node supports Route
Optimization, it will also keep the mapping between the mobile's HoA
and CoA; the mobile will also update the correspondent node when it
changes the CoA. Thus the correspondent node can encapsulate packets
to the mobile directly, without going through the Home Agent.
The three basic components in Mobile IP are:
o Identifier: the mobile node's HoA;
o Locator: the mobile node's CoA;
o Mapping: the binding between HoA and CoA. Home Agent always holds
the mapping; correspondent nodes may also store the mappings if
they support Route Optimization.
Zhu, et al. Expires April 29, 2010 [Page 10]
Internet-Draft Mobility Survey October 2009
Figure 5 illustrates the data path of Mobile IPv6 without Route
Optimization.
+---+-----+
|HoA|DATA |
+---+-----+ +-------+
+----------------------| CN |
| +------------------->| |
| | +-------+
| |
V |
+--------+
| Home | Mapping: HoA <=> CoA
| Agent |
| |
+--------+
|| /\
|| || +-------+
|| +====================| |
|| | MN |
+=======================>| |
+-----+---+---+ +-------+
|DATA |HoA|CoA|
+-----+---+---+
==>: Tunnel
-->: regular IP
Figure 5: Mobile IPv6 without Route Optimization
4.5. 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 to
which network it attaches and receive packets sent to the group after
its join. Thus mobility is naturally supported if IP multicast is
universally deployed. Note that MSM-IP does not address the issue of
feasibility of supporting mobility through IP multicast, but 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] assigns each mobile node a unique multicast IP
address. 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
Zhu, et al. Expires April 29, 2010 [Page 11]
Internet-Draft Mobility Survey October 2009
communicate with the mobile node can just send the data to the
mobile's multicast IP address.
In order to make this approach deployable in wide-area networks, a
hierarchical location management service is also proposed. In the
location server for each mobile node, the IP address of the multicast
router that serves mobile node is stored. Thus, a new multicast
router can always query the location server to find out how to join
the multicast distribution tree.
Also 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.
The three basic components here are:
o Identifier: the mobile node's multicast IP address;
o Locator: the IP address of the multicast router that is currently
serving the mobile node;
o Mapping: the mapping between the above two; this mapping is stored
in location server.
4.6. Cellular IP, HAWAII and TIMIP
This is a group of protocols that share the common idea of setting up
host route for each mobile in the local domain. They are all
intended to work with Mobile IP as a local mobility management
protocol. By describing them together we can more easily to show the
differences by comparison.
Cellular IP [CIP] handles the local mobility in a network consists of
Cellular IP gateways, which are essentially special routers that
integrate location tracking service with routing. A mobile reports
the local gateway node's IP address as the regional CoA to its Home
Agent, and retains its locally assigned IP address when it roams
within the Cellular IP network. The network monitors the packets
originated from mobile node and maintains a distributed, hop-by-hop
reverse path which can be used to route packets back to the mobile
node. It utilizes paging technique from cellular network to track
the location of each mobile by sending dummy packets with a
relatively low frequency to allow mobile nodes to update their
location information. When a packet from correspondent node arrives
at the gateway, the gateway initiates a controlled flooding query if
it does not know the exact location of the mobile. Once the
communication between the mobile and correspondent nodes starts
going, a much more precise reverse path can be maintained.
Similarly, HAWAII [HAWAII] also aims to provide efficient local
Zhu, et al. Expires April 29, 2010 [Page 12]
Internet-Draft Mobility Survey October 2009
mobility support but with two main differences from Cellular IP.
First, HAWAII uses path setup update messages to establish and update
host-based routing entries for the mobile nodes in selective routers
within the domain, so that packets arriving at the domain border
router can reach the mobile host with limited disruption. Second,
unlike the controlled floodingin CIP, it uses IP multicast to page
idle mobile nodes when they have incoming packets arrived at the
border router and there are no routing entries available for these
addresses.
TIMIP [TIMIP], which stands for Terminal Independent Mobile IP,
integrated together the design of Cellular IP and HAWAII. On one
hand, it refreshes the routing paths with dummy packets if there is
no traffic for the mobile node. 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 nodes that do
not support Mobile IP. Thus, as long as it roams within the domain,
a legacy node has the same degree of mobility support as a Mobile IP
capable node.
Given the similarity of the three protocols, the implementation of
the three basic components in them are listed as below:
o Identifier: the mobile node's IP address that are unchanged when
it roams within the domain;
o Locator: the network node that gives network access to the mobile
node;
o Mapping: no explicit mapping; host-based entries in local routers
instead tracks the mobiles' locations.
4.7. Hierarchical Mobile IP (HMIP)
HMIP [RFC4140] is a simple extension to Mobile IP. It aims to
improves the performance of MIP 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 movement 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 and
registers it with its Home Agent as its current CoA; at the same
time, the mobile also obtains a Local CoA from the subnet it attaches
to. When roaming with the region, a mobile only updates the MAP with
the mapping between its Regional CoA and Local CoA. 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 reduced the overhead of Mobile IP by
reducing the frequency of sending updates to Home Agents.
Zhu, et al. Expires April 29, 2010 [Page 13]
Internet-Draft Mobility Survey October 2009
The basic components here are:
o Identifier: the mobile node's HoA;
o Locator: the mobile node's Local CoA;
o Mapping: the mapping between HoA and Local CoA, stored in MAP.
4.8. NEMO
It is concervable to have a group of hosts moving together. Consider
vehicles such as ships, trains, or airplanes which may host a network
with multiple hosts attached to. Because Mobile IP handles mobility
per host, it is not efficient when handling such mobility scenarios.
NEMO [RFC3963], as a backward compatible extension to Mobile IP, was
introduced in 2000 to provide efficient support for network mobility.
NEMO introduces a new entity call Mobile Router (note that this is
different from the "Mobile Router" in LSR protocol). Every mobile
network has at least one Mobile Router via which it can be reached.
Mobile Router is similar to a mobile node in original Mobile IP, but
with additional functions. After establishing bidirectional tunnel
with Home Agent, the Mobile Router will distribute its mobile
network's pefixes (namely Mobile Prefixes) through the tunnel to Home
Agent. The Mobile Prefix of a mobile network is not leaked to its
point of attachment (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 mobile network flow through the bidirectional tunnel to their
destinations. Note that mobility is transparent to the nodes in the
moving network.
Hence, in this protocol, the basic components are:
o Identifier: the Mobile Prefixes;
o Locator: the CoA of the Mobile Router;
o Mapping: the mapping between two, stored in the Home Agent.
4.9. E2E and M-SCTP
E2E (End-to-End communication) [E2E] gets the name from its end-to-
end architecture, and is the first proposal that utilizes existing
DNS service to track mobile node's current location. A mobile uses
Dynamic DNS update to save 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. Migration security is protected
based on token and sequence number.
Inspired by E2E, 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 SCTP associations during the move.
Zhu, et al. Expires April 29, 2010 [Page 14]
Internet-Draft Mobility Survey October 2009
The three components hence are:
o Identifier: the domain name of the mobile node;
o Locator: the current IP address of the mobile node;
o Mapping: the DNS records kept in the Dynamic DNS server.
4.10. Host Identity Protocol
Host Identify Protocol (HIP) [RFC5201] assigns to each host an
identifier made of cryptographic keys, and adds a new Host Identity
layer between 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 purpose. For the
convenience of reusing existing code, Host Identity Tag (HIT), a 128-
bit hash value of the Host Identity, is used in transport and other
upper layer protocols.
HIP uses DNS as the rendezvous point which holds the mappings between
host identifiers and IP addresses. In addition, HIP also defined 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 mobile
node. When a correspondent node wants to communicate with mobile
node, it queries DNS with mobile node's HIT to obtain the IP address
of mobile node's RVS, and sends out the first packet (I1) of Base
Exchange; Base Exchange is a four-packet handshake process for the
purpose of establishing an IPSec Encapsulated Security Payload and
Security Association pair. After receiving this first packet, RVS
relays it to mobile node. Then mobile node and correspondent node
can finish Base Exchange and start communication directly. If mobile
node moves to a new address, it notifies correspondent node by
sending HIP UPDATE with LOCATOR parameter indicating its new IP
address.
The basic components here are:
o Identifier: Host Identity or Host Identity tag of a mobile node;
o Locator: the current IP address of the mobile node;
o Mapping: the mapping between the two, either kept in Dynamic DNS
server or in Rendezvous Server.
4.11. Connexion and WINMO
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. When an airplane moves between its
access points to Internet, it withdraws its prefix from the
previously connected access point 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
Zhu, et al. Expires April 29, 2010 [Page 15]
Internet-Draft Mobility Survey October 2009
number of moving networks becomes large, the amount of BGP updates
will also increase propertionally, resulting in severe global routing
dynamics.
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 that 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 networks current locations. Therefore these Aggregation
Routers play a similar role to Home Agents in Mobile IP, and can be
counted on as last resort to reach mobile networks globally.
To prevent frequent iBGP routing updates due to the movement of
mobile networks within an AS, WINMO also introduces a Home Agent for
the Mobile Prefixes within an AS: only a designated BGP speaking
router (DBR) acts as the origin of Mobile Prefixes; mobile networks
always update their addresses of attachment points 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 location of mobile
networks. A new BGP community attribute, named Packet State, is also
defined to eliminate the triangle routing problem caused by DBR by
informing the correspondent node of the mobile's CoA, an approach
similar to Route Optimization in Mobile IP.
The basic components in Connexion are:
o Identifier: the prefix of a moving network that does not change
during movement;
o Locator: the current router that the mobile network connects to;
o Mapping: the mapping between the above two is implemented as BGP
updates to track the location of the mobile network.
The basic components in WINMO are:
o Identifier: the Mobile Prefix of a moving network;
o Locator: the point of attachment to the Internet;
o Mapping: mapping between the two, kept in Aggregation Routers and
DBR.
Zhu, et al. Expires April 29, 2010 [Page 16]
Internet-Draft Mobility Survey October 2009
4.12. ILNP
ILNP [ILNP] stands for Identifier/Locator Network Protocol. It
splits IPv6 address into two parts: high-order 64 bits as a Locator
field and low-order 64 bits as an Identifier field. Locator is used
for IP packet delivery, while Identifier identifies a host and is
used by all upper layer protocols, same as HIT in HIP. During the
movement, a mobile uses Dynamic DNS Update to update the binding
between Locator and Identifier; it also sends the updated Locator to
correspondent nodes using a new ICMP Locator Update message.
The basic components in ILNP are clear:
o Identifier: the low-order 64 bits of the mobile's IPv6 address;
o Locator: the high-order 64 bits of the mobile's IPv6 address;
o Mapping: the mapping between the two, kept in Dynamic DNS server
and correspondent node.
4.13. Global HAHA
Global HAHA [HAHA], first proposed in 2006, 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.
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 mobile node
after striping off the encapsulation headers. In the reverse
direction, this approach works exactly the same as Mobile IP. If the
Home Agents are distributed widely, the triangle routing problem is
naturally avoided without Route Optimization.
Thus, the basic components in Global HAHA are:
o Identifier: the HoA of the mobile node;
o Locator: the CoA of the mobile node (in the primary Home Agent);
the IP address of primary Home Agent (in other Home Agents).
Zhu, et al. Expires April 29, 2010 [Page 17]
Internet-Draft Mobility Survey October 2009
o Mapping: the mapping between the two.
The data flow in Global HAHA is shown in Figure 6.
+------+ +------+ +-----+
| HA |_____________| HA | | |
| | | | | CN |
+--+---+ .'+++----+ +-----+
| .' || /\
| .' || ||
| .-' || ||
| .' || ||
+--+---+.' || ||
| |<==============+ ||
| HA |==============================+
+-++---+
|| /\
\/ ||
+---++-+ ===>: data flow
| | ----: HA overlay network
| MN |
+------+
Figure 6
4.14. Proxy Mobile IP
Proxy Mobile IP [RFC5213] was proposed in 2006, largely to meet the
interest of mobile network operators who desire to have tighter
control on mobility support. 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. MAGs monitor the attaching and leaving events of mobile
node, and generates Proxy Binding Update to LMA on behalf of mobile
node during handoff. After the success of binding, LMA updates
mobile node's Proxy-CoA with the IP address of the MAG that is
currently serving mobile node. The MAG then emulates mobile node's
local Home Link by advertising mobile node's local Home Network
Prefix in Router Advertisement. When roaming in the PMIP domain,
mobile node always obtains its local Home Prefix, and believes that
its on local Home Link.
Here, the basic components are:
o Identifier: the Home Network Prefix of a mobile node;
Zhu, et al. Expires April 29, 2010 [Page 18]
Internet-Draft Mobility Survey October 2009
o Locator: the Proxy-CoA, which is the IP address of the current
MAG;
o Mapping: the mapping between the two kept in LMA.
4.15. Mobile Me
Mobile Me [BTMM] is a pragmatic approach to mobility support and has
been deployed since 2007 with Mac OS leopard release. Each user gets
a MobileMe account, and Apple Inc. provides DNS service for all
Mobile Me users. A mobile uses secure DNS update to dynamically
refresh its current location. MobileMe assigns each host a special
IPv6 address as the host identifier, which is stored in the DNS
database as an AAAA RR. The host's current IP address is stored in a
SRV [RFC2782] resource record, together with a transport port number
needed for NAT traversal. Every node establishes long-lived query
(llq) session with the DNS server, so that the DNS server can
automatically notify each node when the answer to its previous query
has changed. This approach avoids the need for frequent queries to
get up-to-date location of mobile nodes. A host uses its identifier
(the IPv6 address) in transport protocols and applications, and uses
UDP/IPv4 encapsulation to deliver data packets based on the SRV RR
from DNS reply. Note that the IPv6 address is only for
identification purpose. In fact, it could be any form of identifier
(e.g. HIT in HIP, domain name, etc.); MobileMe chose to IPv6 address
so that its implementation can reuse existing code.
Mobile ME has millions of subscribers, which is perhaps the first
large-scale commercial host mobility support in Internet as of today.
It is simple and easy to deploy. However, the current applications
use MobileMe service in a "stop-and-reconnect" fashsion. It remains
to be seen how well MobileMe can support continuous communications
while hosts are on the move, for example as needed for voice calls.
We can also list the basic components for Mobile Me:
o Identifier: the IPv6 address of a mobile node;
o Locator: the IPv4 address (and port in the case of NAT) of a
mobile node;
o Mapping: the mapping between them, kept in Dynamic DNS server.
Zhu, et al. Expires April 29, 2010 [Page 19]
Internet-Draft Mobility Survey October 2009
Figure 7 shows an example communication scenario of Mobile Me.
+----------+ dynamic DNS update
llq | |<------------------+
+-------->| DNS | |
| | | <------------+ |
| +----------+ llq | |
| | |
| | |
V V |
+-------+ ,---. +-----+-+
| | UDP/IPv4 / \ | |
| Mac1 |<=============>( NAT )<---->| Mac2 |
| | tunnel \ / | |
+-------+ `---' +-------+
Figure 7
4.16. LISP-Mobility
LISP-Mobility [LISP-Mobility] is a relatively new design, in which
the designer hopes to utilize LISP[LISP], which is designed for
routing scalability, to support mobility as well. Conceptually, LISP
may seem similar to some protocols we have mentioned so far, such as
ILNP and Mobile IP. Light-weight Ingress Tunnel Router and Egress
Tunnel Router are implemented on each mobile node, encapsulating/
decapsulating the packets to and from the mobile node. Each mobile
node is assigned a static Endpoint ID, which is used in upper layer
protocols, as well as a pre-configed 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 also in the Ingress
Tunnel Routers or Proxy Tunnel Routers of the correspondent nodes.
Thus the correspondent node can always learn the location of the
mobile node via the resolution of its Endpoint ID, and the data would
always travel through the shortest path. Note that both Endpoint IDs
and Routing Locators are essentially IP addresses.
It is trivial to list the basic components in this protocol:
o Identifier: the Endpoint ID of the mobile node;
o Locator: the Routing Locator the mobile node;
o Mapping: the mapping between them, kept in Map-Server or the
Ingress Tunnel Router of the Correspondent.
5. Different Directions towards Mobility Support
After studying various existing protocols, we identified several
different directions for mobility support.
Zhu, et al. Expires April 29, 2010 [Page 20]
Internet-Draft Mobility Survey October 2009
5.1. Routing-based Approach v.s. Mapping-based Approach
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 mobile's
movements and reflect their current positions 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.
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 the whole network must be informed of every movement by every
mobile, 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 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 need
to be aware of each other's movement, which means that both ends have
to support the same mobility protocol.
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 typically protocol in this case.
Zhu, et al. Expires April 29, 2010 [Page 21]
Internet-Draft Mobility Survey October 2009
In Figure 8 we show the classification of the existing protocols
according to the above analysis.
_.--------.
,-'' `--.
,-' `-.
,' +----+ `.
,-------. / +----+ |ILNP| +----+ \
,+--------+ `-,' |Sony| +----+ |HMIP| `.
,' |Columbia| / `. +----+ +----+ \
,' +--------+ / `. +---+ +------+ \
/ ; \ +----+ |E2E| |M-SCTP| :
/ +---------+ ;+-----+ \ |NEMO| +---+ +------+ :
; |Connexion| ; |WINMO| : +----+ +---------+ :
; +---------+ | +-----+ : +---+ |Mobile Me| |
; +-----+ | : +---+ |HIP| +---------+ |
| |TIMIP| | +------+ | |LSR| +---+ |
: +-----+ : |MSM-IP| ; +---+ +---------+ ;
: +------+ :+------+ ; +----+ |Mobile IP| ;
: |HAWAII| : ; |PMIP| +---------+ ;
\ +------+ \ / +----+ +-----------+ /
\ +-----------+ \ / |Global HAHA| /
`. |Cellular IP| `. ,' +-----------+ ,'
`+-----------+ ,' +-------------+ /
`-. ,-' `. |LISP-Mobility| ,'
`-------' '-+-------------+ ,-'
`--. _.-'
`--------''
Routing-based Mapping-based
Figure 8
5.2. IP Layer Indirection v.s. Mobility Exposure
One critical choice in mapping-based systems is the choice of
rendezvous point, i.e. where to locate the mapping function and
whether or not the rendezvous point provides other functions except
storing mapping information.
Several mobility support designs provide the mapping function at IP
layer, where both the identifier and the current location of a mobile
are represented by IP addresses. In this approach, the IP address
which is used as the mobile's identifier points to the rendezvous
point that keeps track of the mobile's current location. Such
designs offer an advantage of hiding the mobility from correspondent
nodes through one level of indirection. When a correspondent node
sends packets to an IP address which is a mobile's identifier, the
Zhu, et al. Expires April 29, 2010 [Page 22]
Internet-Draft Mobility Survey October 2009
packets will be delivered to the location where the mapping
information of the mobile is kept (e.g. the Home Agent in Mobile IP),
and later they will be forwarded to the mobile's current location via
either encapsulation or destination address translation.
Although this one level of indirection at IP layer makes mobility
transparent, it has a potential side effect of introducing triangle
routing: the path taken by the packets via the rendezvous point can
be much longer than the direct path between the correspondent and the
mobile's current location. Besides, as increasing number of mobile
devices are connected to Internet (why hide mobility to them), some
mobility solutions have opted to expose mobility to both ends and let
them communicate directly. One common approach taken by these
protocols is to use DNS for the mapping function 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.
Figure 9 shows the two categories of mobility protocols according to
their choices of rendezvous point. Note, however, protocols like
Mobile IP can also expose mobility to the other end if Route
Optimization is supported.
,-------.
,-' `-.
,' +---------+ `. ,-----.
/ |Mobile IP| \ ,-' `-.
,' +---------+ `. / +----+ \
; : ,' |ILNP| `.
; +----+ : ; +----+ :
/ |HMIP| +-----------+ \ ; +------+ :
; +----+ |Global HAHA| : / +---+ |M-SCTP| \
| +-----------+ | ; |E2E| +------+ :
| +---+ | | +---+ +---------+ |
| |LSR| +----+ | | |Mobile Me| |
: +---+ +----+ |NEMO| ; | +---+ +---------+ |
\ |Sony| +----+ / : |HIP| ;
: +----+ ; \ +---+ /
: ; : +-------------+ ;
`. +----+ ,' : |LISP-Mobility| ;
\ |PMIP| / `. +-------------+'
`. +----+ ,' \ /
'-. ,-' `-. ,-'
`-------' `-----'
IP Layer Indirection Mobility Exposure
Zhu, et al. Expires April 29, 2010 [Page 23]
Internet-Draft Mobility Survey October 2009
Figure 9
5.3. Operator-Controlled Approach v.s. User-controlled
At the time when this draft was written, the largest global mobility
support today is provided by cellular networks, using a service model
that bundles together the device control, network access control and
mobility support. The tremendous success of cellular market speaks
loudly that the current cellular service model is a viable one, and
is likely to continue for foreseeable future. As a result, there is
a strong advocate in IETF that we continue the cellular way of
handling mobility, i.e. the mobile do not necessarily need to
participate in the mobility related signaling; instead, the network
entities deployed by the operators will take care of any signaling
process of mobility support. A typical example is Proxy Mobile IP,
in which LMA work together with MAGs, assuring that the mobile always
obtains its Home Prefixes as long as it roams within the domain.
The main reason for this approach is perhaps backward compatibility.
By not requiring the participation of mobiles in control signaling
process, it avoids any changes to the mobile nodes, which essentially
means that the mobile nodes can stay simple and all the legacy nodes
can obtain the same level of mobility services as the most fancy
mobile devices. According the the claim of 3G vendors and operators,
this is a key aspect as they learn from their deployment experience.
On the contrary, most mobility support protocols so far focus on
mobility support only. And the mobile nodes typically need to update
their locations by themselves to the rendezvous points chosen by the
user. In these protocols, only the node implementing them can
benefit from mobility support. However, the users get more
flexibility and freedom, e.g. they can choose whatever mobility
services available as long as their software support that protocol,
and they can also tune the parameters to get the services that are
most suitable to them.
Which one is better? No one knows. We expect them to co-exist as
they do today. However, as the technology advances and the hand-hold
devices becomes more and more powerful, the latter approach seems to
be a much simpler way to move forward with.
5.4. Local and Global Scale Mobility
The works done on mobility management can also be divided according
to their scale into two categories: local mobility management and
global mobility management.
Global mobility management is typically supposed to support mobility
Zhu, et al. Expires April 29, 2010 [Page 24]
Internet-Draft Mobility Survey October 2009
of unlimited number of nodes in a geographically as well as
topologically large area. Consequentially, it pays a lot of
attentions to the 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 shorten handoff delay, reduce handoff
loss, short local data path and etc. Since it is typically used in a
small scale with no-so-large number of mobile nodes, sometimes the
designers can use some fine-tune mechanisms that are not scale with
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 contribute to the scalability of global mobility
management.
One problem of the local mobility management is that it often
requires many infrastructure support, such as MAGs in PMIP, or MAPs
in HMIP. These kind of local devices are essentially required in all
small domains, which can be a huge investment.
Neverthe less, the mobility managements in two scale 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 co-
existence of the two seems to be a right choice in the foreseeable
future.
Zhu, et al. Expires April 29, 2010 [Page 25]
Internet-Draft Mobility Survey October 2009
Figure 10 shows the classification of the studied protocols according
to their serving scale.
_.------------.
,-------. _.-'' `---.
,-+--------+`-. ,-'' +---+ +---------+ `--.
,' |Columbia| `,' |HIP| |Mobile IP| `.
,' +--------+ ,' `. +---+ +---------+ `.
/ +----+ / \ \
/ |PMIP| ,'+-----+\ +---+ +------+ +----+ `.
; +----+ ; |WINMO| : |E2E| |MSM-IP| |NEMO| :
;+----+ ; +-----+ : +---+ +------+ +----+ :
; |HMIP| +-----+ ; : :
| +----+ |TIMIP| +-----------+| +------+ +---+ |
: +-----+ |Global HAHA|; |M-SCTP| |LSR| +----+ ;
: +-----------++-----------+ +------+ +---+ |ILNP| ;
: |Cellular IP| : ; +---------+ +----+ ;
\ +-----------+ `. / +----+ |Mobile Me| ,'
\ +------+ \ / |Sony| +---------+ /
`. |HAWAII| `. ,' +----+ +---------+ ,'
`. +------+ ,'. |Connexion| ,'
`-. ,-' `--. +---------+ _.-'
`-------' `---. _.-''
`------------''
Local Mobility Management Global Mobility Management
Figure 10
6. Discussions
In 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 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.
6.1. Backward Compatibility
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 over night. As a result, it is not possible for a
mobility support system designer to overlook this problem: how
important the backward compatibility is?
As one can expect, different designers have different opinions.
Zhu, et al. Expires April 29, 2010 [Page 26]
Internet-Draft Mobility Survey October 2009
Some assume that the other end is by a large chance also mobility
capable (as of today, more people are accessing the Internet via
mobile devices than a desktop), and thus do not provide backward
compatibility at all; but as a tradeoff, the system design becomes
much simpler and the data path is always the shortest one. The
examples of protocols fall into this categories could be HIP, Mobile
Me and etc.
Some take a more conservative approach. They do not want to lose the
ability of communicating with legacy nodes during the movement, and
they also do not want the rest of the world (meaning, the static
nodes) to be bothered by the mobility of mobile nodes. Thus they add
a level of indirection at IP layer, and hide the mobility of the
mobile nodes. The mobile node thus can benefit from mobility support
even when communicating with legacy node. And when the other end
also supports mobility, it is also possible to achieve the shortest
data path, but with additional complexity. The Mobile IP related
protocols fall into this category.
Others want to cater to the inertness of the Internet (and the users)
and keep everything status quo, at least from the users' point of
view. And thus they take backward compatibility more serious and
hide the mobility completely, even for the mobile node itself. Proxy
Mobile IP represents this approach.
We all know that backward compatibility is important in system
design. But how important is that? How much effort should we make
for this issue? At least for now, the answer is not clear yet.
6.2. Undisrupted TCP Connection
TCP is the most widely used transport layer protocol in the Internet,
and the majority of the data traffic today is TCP traffic. In order
for the users to benefit from the mobility support, it is of vital
importance to keep the established TCP connections undisrupted during
the mobile's movement.
Basically there are three approaches to do this: 1) make the mobile
node keep its IP address regardless of its point of attachment to the
Internet; 2) add a level of indirection and use a static IP address
in the TCP pseudo header; 3) modify the TCP protocol.
The routing-based protocols typically make the mobile node keep a
stable IP address and thus the first approach is the right one for
them. Proxy Mobile IP, however, also takes the first approach. No
overhead or complexity is introduced in order to maintain TCP
connections in this approach.
Zhu, et al. Expires April 29, 2010 [Page 27]
Internet-Draft Mobility Survey October 2009
A large number of protocols take the second approach. This approach
could be achieved via a forwarding agent, as in the case of Mobile
IP; or the two end nodes can directly set up a tunnel and use a
stable IP address in TCP pseudo headers, as in the case of Mobile Me.
In order to maintain the TCP connections undisrupted via this
approach, an extra IP header is appended to every data packets, and
the possible forwarding agent also introduce problems such as single
point of failure, triangle routing, bottleneck of bandwidth and
processing power, etc.
A few protocols also take the third approach. In this approach, the
TCP protocol itself is modified, either to 1) put an identifier
rather than an IP address as connection id or to 2) allow the TCP
connections to change the IP address of both ends. HIP, ILNP uses
designated ID in TCP layer (they can be in the format of IP address
though), while E2E allows using dynamically changing IP addresses.
This approach faces the difficulty of changing the TCP protocol
itself, which will introduce serious backward compatibility problem.
What is the best choice for the future? Although it seems that most
people favor the second approach, whether or not it is the right
direction is still uncertain.
6.3. Interconnecting Heterogeneous Mobility Support Systems
As our survey suggests, multiple solutions of mobility support are
already running today, and it is almost for sure that the mobility
support systems in the future are going to be heterogeneous.
However, as of today, the inter-operation 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, both of them can not benefit from mobility support.
This situation reminds us the days before IP were adopted. In that
time, the hosts in different networks are not able to communicate
with each other. It is the IP that 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 the 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 answer to both questions is yes.
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.
Zhu, et al. Expires April 29, 2010 [Page 28]
Internet-Draft Mobility Survey October 2009
6.4. Flat-id Based Routing
Up until now, all our discussions are based on an implication that
the underlying global routing systems is not fundamentally changed,
that is, the location of the mobile node is always indicated by an IP
address. However, recently there are a lot of works that challenge
this "classic" idea. Flat-id based routing schemes [VRR] [ROFL][VIR]
are especially popular.
With flat-id based routing, mobility as well as multihoming are
naturally incorporated. And most of these protocols are
mathematically elegant. However, although the notion of flat-id
space has been widely adopted in peer-to-peer network, it seems that
the Internet is not going to undertake such revolutionary changes
(from hierarchical IP Address based routing to flat-id based routing)
in the foreseeable future due to the inertness of the extremely huge
system and also the backward compatibility problem.
Nevertheless, whether or not flat-id based routing will be a good
solution to the mobility support problem, or perhaps more generally,
the routing problem is not determined yet.
7. References
[BTMM] Nakamoto, R., Zhu, Z., Lau, D., and B. Allen,
"Understanding Apple's Back to My Mac Service", UCLA CS217
Project, 2009.
[Boeing] Andrew, L., "A Border Gateway Protocol 4 (BGP-4)",
Boeing White Paper, 2006.
[CIP] Valko, A., "Cellular IP: A New Approach to Internet Host
Mobility", ACM SIGCOMM, 1999.
[E2E] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach
to Host Mobility", ACM Mobicom, 2000.
[HAHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
Agents Towards Internet-scale Mobility Deployment",
ACM CoNEXT, 2006.
[HAWAII] Ramjee, R., Varadhan, K., and L. Salgarelli, "HAWAII: A
Domain-based Approach for Supporting Mobility in Wide-are
Wireless Networks", IEEE/ACM Transcations on Networking,
2002.
[I-TCP] Bakre, A. and B. Badrinath, "I-TCP: Indirect TCP for
Zhu, et al. Expires April 29, 2010 [Page 29]
Internet-Draft Mobility Survey October 2009
Mobile Hosts", Proceedings of the 15th International
Conference on Distributed Computing System, 1995.
[ILNP] Atkinson, R., "An Overive of the Identifier-Locator
Network Protocol", Research Note, 2005.
[LISP] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer,
"Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12.txt (work in progress), 2009.
[LISP-Mobility]
Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
in progress), 2009.
[LSR] Bhagwat, P. and C. Perkins, "A Mobile Networking System
Based on Internet Protocol (IP)", Mobile and Location-
Independent Computing Symposium, 1993.
[M-SCTP] Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and
Prototypical Implementaion of An End-to-End Mobility
Concept", 5th Intl. Workshop on the Internet Challenge,
2002.
[MSA] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-based
Protocols for Mobile Internetworking", ACM SIGCOMM CCR,
1991.
[MSM-IP] Mysore, J. and V. Bharghavan, "A New Multicast-based
Architecture for Internet Host Mobility", ACM Mobicom,
1997.
[MSOCKS] Ferguson, P. and D. Senie, "MSOCKS: An Architecture for
Transport Layer Mobility", IEEE INFOCOM, 1998.
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002,
October 1996.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
Specifying the Location of Services (DNS SRV)", RFC 2782,
2000.
[RFC3007] Willington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, 2000.
[RFC3220] Perkins, C., "IP Mobility Support for IPv4", RFC 3220,
2002.
Zhu, et al. Expires April 29, 2010 [Page 30]
Internet-Draft Mobility Survey October 2009
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology".
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "IP Mobility
Support in IPv6", RFC 3775, 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Peterson, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, 2005.
[RFC4140] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
RFC 4140, 2005.
[RFC5201] Nikander, P., Moskowitz, R., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, 2008.
[ROFL] Caesar, M., Condie, T., Kannan, J., Lakshminarayanan, K.,
Stoica, I., and S. Shenker, "ROFL: Routing on Flat
Labels", ACM Sigcomm, 2006.
[Sony] Teraoka, F., Yokote, Y., and M. Tokro, "A Network
Architecture Providing Host Migration Transparency",
ACM SIGCOMM CCR, 1991.
[TIMIP] Grilo, A., Estrela, P., and M. Nunes, "Terminal
Independent Mobility For IP", IEEE Communications
Magazine, 2001.
[VIR] Lu, G., Jain, S., Chen, S., and Z. Zhang, "Virtual Id
Routing", ACM MobiArch, 2008.
[VRR] Caesar, M., Castro, M., Nightingale, E., O'Shea, G., and
A. Rowstron, "Virtual Ring Routing: Network Routing
Inspired by DHTs", ACM Sigcomm, 2006.
[WINMO] Hu, X., Li, L., Mao, Z., and Y. Yang, "Wide-Area IP
Network Mobility", IEEE INFOCOM, 2008.
Zhu, et al. Expires April 29, 2010 [Page 31]
Internet-Draft Mobility Survey October 2009
Authors' Addresses
Zhenkai Zhu
UCLA
4805 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Phone: +1 310 993 7128
Email: zhenkai@cs.ucla.edu
Ryuji Wakikawa
TOYOTA ITC
465 Bernardo Avenue
Mountain View, CA 94043
US
Email: ryuji@jp.toyota-itc.com
Lixia Zhang
UCLA
3713 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Phone: +1 310 825 2695
Email: lixia@cs.ucla.edu
Zhu, et al. Expires April 29, 2010 [Page 32]
