[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 6301

Network Working Group                                             Z. Zhu
Internet-Draft                                                      UCLA
Intended status: Informational                               R. Wakikawa
Expires: September 10, 2010                                   TOYOTA ITC
                                                                L. Zhang
                                                           March 9, 2010

              A Survey of Mobility Support In the Internet


   Over the last two decades many 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.

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 10, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the

Zhu, et al.            Expires September 10, 2010               [Page 1]

Internet-Draft               Mobility Survey                  March 2010

   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

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.  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. Back to My Mac . . . . . . . . . . . . . . . . . . . . . . 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  . . . . 23
     5.4.  Local and Global Scale Mobility  . . . . . . . . . . . . . 24
   6.  Discussions  . . . . . . . . . . . . . . . . . . . . . . . . . 25
     6.1.  Deployment Issues  . . . . . . . . . . . . . . . . . . . . 25
     6.2.  Backward Compatibility . . . . . . . . . . . . . . . . . . 26
     6.3.  Interconnecting Heterogeneous Mobility Support Systems . . 26
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29

Zhu, et al.            Expires September 10, 2010               [Page 2]

Internet-Draft               Mobility Survey                  March 2010

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 on the table can help us not only identify their
   commonalities and differences, but also shed insight on future

   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 the following terms to refer to the entities or
   functions that are required in mobility support.  Readers should also
   read RFC3753 "Mobility Related Terminology" [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 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
           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.

Zhu, et al.            Expires September 10, 2010               [Page 3]

Internet-Draft               Mobility Survey                  March 2010

   Mapping:  In this document, mapping specifically means the mapping
           between a mobile's identifier and it's Locator.

   Rendezvous Point (RP):  RP is the place where the mapping is held.
           Some other functions such as data forwarding may also be co-
           located on the rendezvous 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

   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;

Zhu, et al.            Expires September 10, 2010               [Page 4]

Internet-Draft               Mobility Survey                  March 2010

   o  a locator, which is usually an IP address; and
   o  a mapping between the two.

   We show in the next section that different mobility support 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 we grouped
   closely related protocols together (for the sake of convenience).  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

Zhu, et al.            Expires September 10, 2010               [Page 5]

Internet-Draft               Mobility Survey                  March 2010

4.1.  Columbia Protocol

   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, which serves as the default access
   router for all mobile nodes in that cell.  A mobile node obtains the
   IP address from a special block of IP addresses and keeps it
   regardless of its current location.  Each MSS keeps a tracking 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 then
   delivers 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

Zhu, et al.            Expires September 10, 2010               [Page 6]

Internet-Draft               Mobility Survey                  March 2010

   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 [Sony], 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 along the path can also cache a set of mappings
   for mobile nodes.  So does the correpondent node (so only the first
   packet may need to traverse through a triangle path).

   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 the mobile, it modifies the destination
   IP address field and forwards the packets to the mobile's current
   location; otherwise, the packet traverses to the mobile's home
   network, where the packet's destination address then is changed to

Zhu, et al.            Expires September 10, 2010               [Page 7]

Internet-Draft               Mobility Survey                  March 2010

   the mobile's current location according to the mapping.  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 nodes.

   Figure 3 shows how Sony protocol works.

                                       ,---.       +-------+
                                      /     \      |  CN   |
                                     ( Router)<====|       |
         +---------+               // \     /      |       |
         |         |              //   `---'       +-------+
         |         |     ,---.   //
         |         |    /     \ //
         | Home    |<--+ Router)
         | Network |    \     /
         |         |     `-+-'\\
         |         |       |   \\   ,---.         +-------+
         |         |       |    \\ /     \=======>|       |
         |         |       +------( Router)<------+  MN   |
         |         |               \     /        |       |
         |         |                `---'         +-------+

                   ===>: data packet
                   --->: location update message

                          Figure 3: Sony Protocol

4.3.  LSR Protocol

   In Loose Source Routing (LSR) based protocol, 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
   announces reachability to those IP addresses.  Another network entity
   required is Mobile Access Station (MAS) through which the mobile gets
   its conectivity to the Internet.  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 September 10, 2010               [Page 8]

Internet-Draft               Mobility Survey                  March 2010

   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.  This way, the packet is redirected 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

   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 September 10, 2010               [Page 9]

Internet-Draft               Mobility Survey                  March 2010

   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 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 HoA 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 also keeps 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 September 10, 2010              [Page 10]

Internet-Draft               Mobility Survey                  March 2010

   Figure 5 illustrates the data path of Mobile IPv6 without Route

                              |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 September 10, 2010              [Page 11]

Internet-Draft               Mobility Survey                  March 2010

   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 the 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 routers that integrate location tracking service with
   routing.  A mobile reports the IP address of the gateway for the
   local network as the regional CoA to its Home Agent, and retains its
   locally assigned IP address when it roams within the Cellular IP
   network.  The routers in 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 allowing mobile nodes to send dummy packets with a
   relatively low frequency to update their location information.  When
   a packet from the correspondent node arrives at the gateway, the
   gateway initiates a controlled flooding query: if a router knows
   where to forward a packet, forward it immediately; otherwise, it
   forwards the packet to all its interfaces except the one from which
   the packet comes.  Due to the paging technique, this will not become
   a broadcast.  Once the communication between the mobile and
   correspondent nodes starts going, a much more precise reverse path

Zhu, et al.            Expires September 10, 2010              [Page 12]

Internet-Draft               Mobility Survey                  March 2010

   can be maintained by the routers along the path.

   Similarly, HAWAII [HAWAII] also aims to provide efficient local
   mobility support but with two main differences from Cellular IP.
   First, it dynamically sets up routes to each mobile by installing
   host-based forwarding entry in specific routers, usually the ones
   located along the shortest path between the old and new base stations
   of the mobile.  Second, it uses IP multicast, instead of controlled
   flooding, 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
   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 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 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 reduces the burden of the Home Agents

Zhu, et al.            Expires September 10, 2010              [Page 13]

Internet-Draft               Mobility Survey                  March 2010

   by reducing the frequency of sending updates to Home Agents.

   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 conceivable 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.  Mobile Router is similar to
   a mobile node in Mobile IP, but with additional functions.  After
   establishing bidirectional tunnel with Home Agent, the Mobile Router
   distributes its mobile network's prefixes (namely Mobile Prefixes)
   through the tunnel to 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 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.

   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) 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 secret tokens and sequence numbers.

   Inspired by E2E, M-SCTP [M-SCTP] was proposed in 2002.  Similarly, it

Zhu, et al.            Expires September 10, 2010              [Page 14]

Internet-Draft               Mobility Survey                  March 2010

   uses Dynamic DNS to track the mobile nodes and allows both ends to
   add/delete IP addresses used in SCTP associations during the move.

   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.  In order to
   reuse the 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 can use DNS as the rendezvous point which 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 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 ESP 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 the mobile node moves to a new address,
   it notifies correspondent node by sending HIP UPDATE with LOCATOR
   parameter indicating its new IP address.  Meanwhile, it also updates
   the mapping in RVS.

   The basic components here are:
   o  Identifier: Host Identity or HIT 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 routers on ground, it withdraws its prefix from the previously

Zhu, et al.            Expires September 10, 2010              [Page 15]

Internet-Draft               Mobility Survey                  March 2010

   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.

   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: only a Designated BGP-speaking Router (DBR) acts
   as the origin of Mobile Prefixes; mobile networks always update the
   addresses fo their access routers 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.
   A new BGP community attribute, named Packet State, is also defined to
   eliminate the triangle routing problem caused by DBR by including the
   mobile network's COA in each packet.

   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;

Zhu, et al.            Expires September 10, 2010              [Page 16]

Internet-Draft               Mobility Survey                  March 2010

   o  Mapping: mapping between the two, kept in Aggregation Routers and

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:

Zhu, et al.            Expires September 10, 2010              [Page 17]

Internet-Draft               Mobility Survey                  March 2010

   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).
   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 detaching 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:

Zhu, et al.            Expires September 10, 2010              [Page 18]

Internet-Draft               Mobility Survey                  March 2010

   o  Identifier: the Home Network Prefix of a mobile node;
   o  Locator: the Proxy-CoA, which is the IP address of the current
   o  Mapping: the mapping between the two kept in LMA.

4.15.  Back to My Mac

   Back to My Mac (BTMM) [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 (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, and only
   accessible to the subscriber.

   A mobile uses secure DNS update to dynamically refresh its current
   location.  Each machine generates a random IPv6 ULA [RFC4193], which
   is stored in the DNS database as a topologically independent
   identifier.  The host's current IPv4 address (which in many cases is
   the IPv4 address of the NAT box) 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 query has changed.  This approach
   avoids the need for frequent pollings to get up-to-date location of
   mobile nodes.  A host uses its identifier in transport protocols and
   applications, and uses UDP/IPv4 encapsulation to deliver data packets
   based on what learned from the SRV RR.  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.); BTMM chose to IPv6
   address so that its implementation can reuse existing code.

   BTMM 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
   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.

   We can also list the basic components for BTMM:
   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 September 10, 2010              [Page 19]

Internet-Draft               Mobility Survey                  March 2010

   Figure 7 shows the basic architecture of BTMM.

           DDNS update    +--------+  DDNS update
         +--------------->|        |<-------+
         |                |  DNS   |        |
         |      LLQ       |        | LLQ    |
         |    +---------->|        |<----+  |
         |    |           |        |     |  |
         |    |           +--------+     |  |
         |    |                          |  |            +---------+
         |    V                      +---+--+----+       |         |
        ++-------+                   |           +-------|         |
        |Endhost1|     Tunnel        |    NAT    +------>|Endhost2 |
        |        |<=====================================>|         |
        +--------+                   |           |       |         |
                                     +-----------+       +---------+

                                 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-configured 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

Zhu, et al.            Expires September 10, 2010              [Page 20]

Internet-Draft               Mobility Survey                  March 2010

   different directions for mobility support.

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 September 10, 2010              [Page 21]

Internet-Draft               Mobility Survey                  March 2010

   In Figure 8 we show the classification of the existing protocols
   according to the above analysis.

   |               | Sony, LSR, Mobile IP, HMIP, NEMO,  E2E    |
   | Mapping-based | M-SCTP, ILNP, HIP, PMIP, Global HAHA,     |
   |               | BTMM, LISP-Mobility                       |
   |               | Columbia, Connexion, Celluar IP,          |
   | Routing-based | HAWAII, TIMIP                             |
   | Combination   | WINMO, MSM-IP                             |

                                 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
   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

Zhu, et al.            Expires September 10, 2010              [Page 22]

Internet-Draft               Mobility Survey                  March 2010

   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.

   | Indirection | Sony, LSR, Mobile IP, HMIP, NEMO |
   |             | Global HAHA, PMIP, LISP-Mobility |
   | Exposure    | E2E, M-SCTP, ILNP, HIP,          |
   |             | BTMM                             |

                                 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

Zhu, et al.            Expires September 10, 2010              [Page 23]

Internet-Draft               Mobility Survey                  March 2010

   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 the answer.  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
   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 handoff delay, handoff loss, local data
   path and etc.  Since it is typically used in a small scale with not-
   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.

   Nevertheless, 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

Zhu, et al.            Expires September 10, 2010              [Page 24]

Internet-Draft               Mobility Survey                  March 2010

   Figure 10 shows the classification of the studied protocols according
   to their serving scale.

   |           | Sony, LSR, Mobile IP, NEMO, E2E, M-SCTP |
   |   Global  | HIP, ILNP, Connexion, WIMO, BTMM,       |
   |           | MSM-IP, Global HAHA, LISP-Mobility      |
   |   Local   | Columbia, HMIP, Cellular IP, HAWAII,    |
   |           | TIMIP, PMIP                             |

                                 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.  Deployment Issues

   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, it is until recent years that the
   number of mobiles soars.  Hence, operators did know see the incentive
   of deploying mobility support protocol several years back.  As of
   today, the number of mobiles are still growing by leaps and bounds,
   and there is enough user demand for the operators to seriously
   consider the deployment of mobility support protocols.

   Second, the complexity of most mobility support protocols impedes the
   implementation and hence the deployment in commerical networks.  The
   complexity arises from multiple aspects.  One is the optimizations on
   performance.  And 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 MEXT working group.  Some
   researchers argue that the research community should design a "barely
   work" version of mobility support protocol first, without considering
   nice performance features and complex security mechanism, roll it out
   in the real world and improve it thereafter.  However, there are

Zhu, et al.            Expires September 10, 2010              [Page 25]

Internet-Draft               Mobility Survey                  March 2010

   different views on what are the essential features and which security
   mechanism is better.

6.2.  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 also 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.

   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, BTMM
   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.3.  Interconnecting Heterogeneous Mobility Support Systems

   As our survey suggests, multiple solutions of mobility support are
   already there 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

Zhu, et al.            Expires September 10, 2010              [Page 26]

Internet-Draft               Mobility Survey                  March 2010

   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 answers to both questions are "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.

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.

              Ioannidis, J., Duchamp, D., and G. Maguire, "IP-based
              Protocols for Mobile Internetworking", ACM SIGCOMM CCR,

   [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,

Zhu, et al.            Expires September 10, 2010              [Page 27]

Internet-Draft               Mobility Survey                  March 2010

   [I-TCP]    Bakre, A. and B. Badrinath, "I-TCP: Indirect TCP for
              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.

              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,

   [MSM-IP]   Mysore, J. and V. Bharghavan, "A New Multicast-based
              Architecture for Internet Host Mobility", ACM Mobicom,

   [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,

   [RFC3007]  Willington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, 2000.

   [RFC3220]  Perkins, C., "IP Mobility Support for IPv4", RFC 3220,

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology".

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "IP Mobility

Zhu, et al.            Expires September 10, 2010              [Page 28]

Internet-Draft               Mobility Survey                  March 2010

              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.

   [RFC4193]  "Unique Local IPv6 Unicast Address", RFC 4193.

   [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 September 10, 2010              [Page 29]

Internet-Draft               Mobility Survey                  March 2010

Authors' Addresses

   Zhenkai Zhu
   4805 Boelter Hall, UCLA
   Los Angeles, CA  90095

   Phone: +1 310 993 7128
   Email: zhenkai@cs.ucla.edu

   Ryuji Wakikawa
   465 Bernardo Avenue
   Mountain View, CA  94043

   Email: ryuji@jp.toyota-itc.com

   Lixia Zhang
   3713 Boelter Hall, UCLA
   Los Angeles, CA  90095

   Phone: +1 310 825 2695
   Email: lixia@cs.ucla.edu

Zhu, et al.            Expires September 10, 2010              [Page 30]

Html markup produced by rfcmarkup 1.114, available from https://tools.ietf.org/tools/rfcmarkup/