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

Versions: 00 01 02 03 04 RFC 6301

Network Working Group                                             Z. Zhu
Internet-Draft                                                      UCLA
Intended status: Informational                               R. Wakikawa
Expires: April 22, 2010                                       TOYOTA ITC
                                                                L. Zhang
                                                        October 19, 2009

              A Survey of Mobility Support In the Internet

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 April 22, 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 22, 2010                 [Page 1]

Internet-Draft               Mobility Survey                October 2009


   Over the last two decades many research efforts have been devoted to
   developing solutions for mobility support over the global Internet
   and resulted in a variety of proposed solutions.  We conducted a
   survey of the previous efforts to deepen our understanding on the
   overall solution space of mobility support.  This draft reports on
   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  . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Sony Protocol  . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  LSR Protocol . . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Mobile IP  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.5.  MSM-IP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.6.  Cellular IP, HAWAII and TIMIP  . . . . . . . . . . . . . . 13
     4.7.  Hierarchical Mobile IP . . . . . . . . . . . . . . . . . . 14
     4.8.  NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     4.9.  E2E and M-SCTP . . . . . . . . . . . . . . . . . . . . . . 16
     4.10. Host Identity Protocol . . . . . . . . . . . . . . . . . . 16
     4.11. Connexion and WINMO  . . . . . . . . . . . . . . . . . . . 17
     4.12. ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.13. Global HAHA  . . . . . . . . . . . . . . . . . . . . . . . 19
     4.14. Proxy Mobile IP  . . . . . . . . . . . . . . . . . . . . . 20
     4.15. Mobile Me  . . . . . . . . . . . . . . . . . . . . . . . . 21
     4.16. LISP-Mobility  . . . . . . . . . . . . . . . . . . . . . . 22
   5.  Different Directions towards Mobility Support  . . . . . . . . 23
     5.1.  Routing-based Approach v.s. Mapping-based Approach . . . . 23
     5.2.  IP Layer Indirection v.s. Mobility Exposure  . . . . . . . 24
     5.3.  Operator-Controlled Approach v.s. User-controlled  . . . . 26
     5.4.  Local and Global Scale Mobility  . . . . . . . . . . . . . 27
   6.  Discussions  . . . . . . . . . . . . . . . . . . . . . . . . . 28
     6.1.  Backward Compatibility . . . . . . . . . . . . . . . . . . 29
     6.2.  Undisrupted TCP Connection . . . . . . . . . . . . . . . . 29
     6.3.  Interconnecting Heterogeneous Mobility Support Systems . . 30
     6.4.  Flat-id Based Routing  . . . . . . . . . . . . . . . . . . 31
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34

Zhu, et al.              Expires April 22, 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 specific solutions
   have become the Internet standards.  Yet new issues and new solutions
   continue to arise, 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 not only can help us
   better understand their commonalities and differences, but can also
   help 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 and try to initiate an open
   discussion by sharing our understanding 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.


   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.


   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.


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

Zhu, et al.              Expires April 22, 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

   Mobility support can be provided through through multiple different
   ways.  The basic question 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, which
   "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 bind that
   unchanged identifier of the mobile with its dynamically changing

   The above intuitive reasoning leads to the following observation--
   mobility support essentially involves three basic components:

Zhu, et al.              Expires April 22, 2010                 [Page 4]

Internet-Draft               Mobility Survey                October 2009

   o  a stable identifier for a mobile;

   o  a locator, which is usually an IP address;

   o  and a mapping between the two.

   In the next section we show 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 time order (There are exceptions: for the sake of
   convenience, we group closely related protocols together).  We
   briefly describe their design and point out how they implement the
   three basic components defined in last section.

Zhu, et al.              Expires April 22, 2010                 [Page 5]

Internet-Draft               Mobility Survey                October 2009

   Figure 1 shows a list of the protocol names and the time when 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

4.1.  Columbia Protocol

   This protocol was originally designed to provide mobility support in
   a campus.  A router named Mobile Support Station (MSS) is set up in
   each wireless cell, which is the default access router for all mobile
   nodes in that cell.  Mobile node obtains an IP address from a special
   block of IP addresses and keeps it regardless of it's 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 closest MSS near
   correspondent node.  This MSS will deliver the packet directly to the
   mobile node if the mobile node happens to be in its cell, or forward
   the packet to the MSS that serves the mobile node.  In the latter
   case, a MSS sends a query message to all other MSSs in the campus in
   order to find out 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.

   Here, the three basic components are:

Zhu, et al.              Expires April 22, 2010                 [Page 6]

Internet-Draft               Mobility Survey                October 2009

   o  Identifier: the mobile node's IP address from the special IP

   o  Locator: the IP address of the serving MSS;

   o  Mapping: no explicit mapping; query flood is used to find out the
      mobile's location.

   The illustration of Columbia Approach is shown in Figure 2.

                       |         |
               .------>|  MAS    |
               |       |         |
               |       +---------+
               | query
            +--------+     query      +--------+
            |        | -------------->|        |
            |  MAS   | <------------- |  MAS   |
            |        |    reply       |        |
            +--------+ ==============>+--------+
               /\          data           ||
               ||                         ||
               ||                         \/
            +--------+                +---------+
            |        |                |         |
            |  CN    |                |  MN     |
            |        |                |         |
            +--------+                +---------+

               ===>: data packets
               --->: signaling packets

                                 Figure 2

4.2.  Sony Protocol

   In this protocol, the IP header is modified so that each mobile node
   has two IP addresses: a Virtual IP address and a conventional IP
   address.  Virtual IP address is the IP address that a mobile node
   obtains from its home network, whereas a conventional IP address is
   the IP address a mobile node obtains 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 in turn stores the

Zhu, et al.              Expires April 22, 2010                 [Page 7]

Internet-Draft               Mobility Survey                October 2009

   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 the mobile node, the correspondent node sets the
   destination IP address the same as mobile node's Virtual IP address.
   If a router along the way from correspondent node to mobile node's
   home network happens to have a valid mapping for mobile node, it
   modifies the destination IP address field and forwards the packets to
   the new destination; otherwise, the packet will flow to mobile node's
   home network, which then delivers the packets to mobile node
   according to the mapping.  Note that the destination IP address field
   can be modified again if the packet encounters a router with newer

   The three basic components are easy to find:

   o  Identifier: the mobile node's Virtual IP address;

   o  Locator: the mobile node's conventional IP address;

   o  Mapping: the mapping between Virtual IP address and conventional
      IP address; it could be stored in home network, as well as in
      routers and end host.

Zhu, et al.              Expires April 22, 2010                 [Page 8]

Internet-Draft               Mobility Survey                October 2009

   Figure 3 shows how sony protocol works.

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

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

                                 Figure 3

4.3.  LSR Protocol

   Each mobile node has a designated router that manages its mobility,
   called Mobile Router.  Mobile Router assigns an IP address for each
   mobile node it manages and announce reachability to those IP
   addresses.  Another network entity required is Mobile Access Station
   (MAS), which, as indicated by its name, gives a mobile node access to
   the Internet regardless of the mobile node's IP address.  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 it's easy: the MAS can just forwards packets between
   the two; otherwise, the packet sent by the correspondent node would
   be routed to the Mobile Router according to rules of the IP routing.
   The Mobile Router exams the mappings, finds 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 and then to the mobile
   node.  After that, the mobile node reverses the LSR and replies to
   the correspondent node; the correspondent node, similarly, sends the
   following packets along an optimal path by reversing the LSR.

   Let's identify the three basic components for this protocol:

Zhu, et al.              Expires April 22, 2010                 [Page 9]

Internet-Draft               Mobility Survey                October 2009

   o  Identifier: the mobile node's IP address;

   o  Locator: the IP address of the serving MAS;

   o  Mapping: the mapping between the two, managed by 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

4.4.  Mobile IP

   IETF begun its effort in mobility support area following the path of
   the above three protocols.  In 1996, the first version of Mobile IP
   was finished.  Later, IETF further made Mobile IPv4 [RFC3220] and
   Mobile IPv6 [RFC3775] standards in 2002 and 2004 respectively.

   Let's take Mobile IPv6 as an example.  Each mobile node has a Home
   Agent, from which it acquires its Home Address (HoA).  Unlike in LSR
   protocol, however, the mobile node also obtains a Care-of Address
   (CoA) from its access router to the Internet.  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.

   The correspondent node simply sets the destination field in the IP

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

Internet-Draft               Mobility Survey                October 2009

   header to the HoA of the mobile node, and the packets are routed 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, then it can also keep a mapping between the mobile
   node's HoA and CoA; as specified by the protocol, the mobile node
   would update the mapping in correspondent node as well.  Thus the
   correspondent node can tunnel packets to the mobile node directly,
   bypassing the Home Agent and resulting in a shorter data path.

   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 mapping between HoA and CoA; Home Agent always holds
      the mapping, and correspondent nodes can also store the mappings
      if they support Route Optimization.

Zhu, et al.              Expires April 22, 2010                [Page 11]

Internet-Draft               Mobility Survey                October 2009

   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

4.5.  MSM-IP

   MSM-IP stands for Mobility Support using Multicast in IP.  As one can
   learn from its name, it leverages the IP multicast routing to support
   the mobility.  In IP multicast, a host can join a group regardless of
   to which network it attaches, and all the packets sent to the group
   can be received after that.  Thus, as claimed by the designers of
   MSM-IP, mobility is naturally supported if IP multicast problem is
   solved.  Note that their purpose is not to show the feasibility of
   supporting mobility with current IP multicast architecture, but
   rather the possibility of reusing IP multicast, if it is well
   supported in the future, to solve mobility support problem.

   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

Zhu, et al.              Expires April 22, 2010                [Page 12]

Internet-Draft               Mobility Survey                October 2009

   subnet join the multicast distribution tree.  Whoever wants to
   communicate with the mobile node can just send the data to the
   mobile's multicast IP address.

   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 seting up
   host route for the mobile node in the local domain.  They are all
   intended to work with Mobile IP as a local mobility management
   protocol.  We introduce them together so that it is much clearer to
   show the differences by comparison.

   Cellular IP [CIP] handles the local mobility in a network consists of
   Cellular IP nodes, which are essentially special routers that
   integrates location tracking service with routing.  The mobile node
   registers the local gateway node's IP address to Home Agent as the
   regional CoA, and retains its 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 mobile node efficiently, by allowing mobile node to
   update its location (via the way of sending dummy packets) with a
   relatively long period.  When a packet from correspondent node
   arrives at the gateway node, controlled flooding query is initiated
   if the gateway node has no idea about the exact location of mobile

Zhu, et al.              Expires April 22, 2010                [Page 13]

Internet-Draft               Mobility Survey                October 2009

   node.  However, a much more precise reverse path is maintained later
   when the communication between mobile node and correspondent node is
   going on.

   Similarly, HAWAII [HAWAII] also aims to provide efficient local
   mobility support with two main differences from Cellular IP.  First,
   it dynamically setup routes to mobile node by installing host-based
   forwarding entry in specific routers, usually the ones located in the
   shortest path between the old and new serving base stations.  Second,
   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 Cellular IP and HAWAII together.  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

   This [RFC4140] is a simple extension to Mobile IP introduced in 1998.
   It aims to work with Mobile IP as a local mobility support protocol.
   A level of hierarchy is added to Mobile IP in the following way.  A
   Mobility Anchor Point (MAP) is responsible for handling the mobility
   of mobile node in a local region.  Simply speaking, MAP is the local
   Home Agent for the mobile node.  The mobile node, if it supports
   Hierarchical Mobile IP (HMIP), obtains a Regional CoA and register it
   to Home Agent as its current CoA; at the same time, it also obtains a
   Local CoA from the subnet it attaches to.  When roaming with the
   region, mobile node only needs to keep the mapping between Regional

Zhu, et al.              Expires April 22, 2010                [Page 14]

Internet-Draft               Mobility Survey                October 2009

   CoA and Local CoA updated in MAP.  In this way, the handoff
   performance is usually better due to the short round-trip time, and
   it also enhance the scalability of Mobile IP.

   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 not unusual for a group of hosts to move together.  Consider
   vehicles such as ships, trains, airplanes which contain networks with
   a large number of nodes that need global mobility support.  Mobile IP
   is not efficient when handling such mobility scenarios.
   Consequently, NEMO [RFC3963], as a backward compatible extension to
   Mobile IP, was introduced in 2000 to handle the network mobility
   support problem.

   A new entity call Mobile Router (note that this is different from the
   "Mobile Router" in LSR protocol) is introduced.  Every mobile network
   has at least one Mobile Router via which it can be accessed.  Mobile
   Router is a special mobile node as in original Mobile IP, with more
   powerful functions.  After establishing bidirectional tunnel with
   Home Agent, the Mobile Router will distribute the network's pefixes
   (namely Mobile Prefixes) through the tunnel to Home Agent, but never
   leaks them to the infrastructure at 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 these Mobile Prefixes.  Packets to and from mobile
   network always flow through the bidirectional tunnel to their

   Note that, mobility is transparent to the nodes in the moving

   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.

Zhu, et al.              Expires April 22, 2010                [Page 15]

Internet-Draft               Mobility Survey                October 2009

4.9.  E2E and M-SCTP

   E2E (End-to-End communication) gets the name from its end-to-end
   architecture, and is the first formal proposal that utilizes existing
   DNS infrastructure to track mobile node's current location.  It works
   in a conceptually simple way: Dynamic DNS update is used to refresh
   the current IP address of the mobile node in DNS server; to keep the
   ongoing TCP connection unaffected by mobility, a TCP Migrate option
   is introduced, which enables 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 use in SCTP in order to keep the SCTP
   association 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] introduces a new name space
   consisting of cryptographic keys, and places a Host Identity layer
   between transport and network layers.  As a result, the Host
   Identities, which are essentially public keys, are used to identify
   the mobile nodes; while at the same time, IP addresses are only used
   for routing purpose.  For the convenience of reusing existing code,
   Host Identity Tag, a 128-bit hash value of the Host Identity, is used
   in the upper layer connections.

   Dynamic DNS again can serve as the rendezvous point and holds the
   mappings for HIP.  Nevertheless, HIP has also specified 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,
   which is a four-packet handshake with the purpose of establishing an
   IPSec Encapsulated Security Payload and Security Association pair.
   After receiving this packet, RVS will relay it to mobile node.  Then
   mobile node and correspondent node can finish Base Exchange and start

Zhu, et al.              Expires April 22, 2010                [Page 16]

Internet-Draft               Mobility Survey                October 2009

   communication directly.  If mobile node moves to a new address, it
   simples notifies correspondent node by sending HIP UPDATE with
   LOCATOR parameter indicating the 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] is a service provided by Boeing that uses BGP to
   support mobility.  Every mobile network is assigned a /24 prefix.
   When the plane moves between ground stations, which are the access
   points to Internet, it withdraws its prefix from the BGP table in the
   older ground station, and announce the prefix via the new ground
   station.  Thus, the location change of the plane is effectively
   propagated to the rest of the world.  However, if the number of
   moving networks soars, an avalanche of BGP updates will be generated
   to the whole Internet, resulting in severe global routing

   WINMO [WINMO] (which stands for Wide-Area IP Network Mobility) was
   later designed in 2008 to address the routing instability problem of

   Like Connexion, WINMO also assigns each mobile network a stable
   prefix, however, WINMO made the BGP updates overhead for mobile
   networks orders of magnitude lower than that of Connexion by the
   following two approaches.  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.  Resolving this issue led to the second, and more
   fundamental approach taken by WINMO: adoption of the basic idea from
   Mobile IP.  WINMO assumes that each mobile subnet is assigned 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 keep track of the mobile networks.  Thus one may view WINMO's
   Aggregation Routers as playing the role of Home Agents in Mobile IP.

   To prevent frequent iBGP routing changes due to the movement of
   mobile networks within an AS, WINMO also adopts the Mobile IP way.
   It introduced a Home Agent for the Mobile Prefixes within an AS: only
   a designated BGP speaking router (DBR) acts as the origin of Mobile

Zhu, et al.              Expires April 22, 2010                [Page 17]

Internet-Draft               Mobility Survey                October 2009

   Prefixes; mobile networks always update their addresses of attachment
   points to DBR, which resembles the binding updates in Mobile IP.
   Thus, packets destined to mobile networks will be routed to DBR after
   it enters the border of AS, and DBR will be responsible to tunnel
   them to the right receivers.  A BGP community name Packet State is
   also created to eliminate the triangle routing problem caused by DBR,
   in a way similar to Route Optimization, by leaking CoA to
   corresponding node.

   The basic components in Connexion are:

   o  Identifier: the prefixes of the moving network;

   o  Locator: the serving ground station;

   o  Mapping: no explicit mapping; BGP tables in different routers
      collectively track the location of the mobile network.

   The basic components in WINMO are:

   o  Identifier: the Mobile Prefixes of the moving network;

   o  Locator: the point of attachment to the Internet;

   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 is used by all upper layer
   protocols, just as HIT in HIP.  During the movement, the mobile node
   updates the binding entry between Locator and Identifier via Dynamic
   DNS Update; it also updates Locator to correspondent nodes with a new
   ICMP Locator Update message.

   The basic components in ILNP are clear:

   o  Identifier: the low-order 64 bits of the mobile's IP address;

   o  Locator: the high-order 64 bits of the mobile's IP address;

   o  Mapping: the mapping between the two, kept in Dynamic DNS server
      and correspondent node.

Zhu, et al.              Expires April 22, 2010                [Page 18]

Internet-Draft               Mobility Survey                October 2009

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 Home
   Agents in a wide area.  A set of Home Agents joins an IP anycast
   group and forms an overlay network.  The same home prefixes are
   announced by all the Home Agents at different locations.  Each mobile
   node can register with any Home Agent that is closest to it.  The
   Home Agent that accepts the binding request of mobile node, namely
   the primary Home Agent, is responsible to notify all other Home
   Agents in the overlay network, so that the binding information
   databases in all Home Agents are always synchronized.

   Packets from correspondent node are delivered to the nearest Home
   Agent by anycast routing.  This Home Agent then forwards these
   packets through the overlay network to the target Home Agent that is
   currently serving mobile node, which will finally deliver the packets
   to mobile node after striping the tunneling headers.  In the reverse
   direction, this approach works exactly the same as Mobile IP.  If the
   distribution of Home Agents are carefully designed, the triangle
   routing problem is solved naturally 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).

   o  Mapping: the mapping between the two.

Zhu, et al.              Expires April 22, 2010                [Page 19]

Internet-Draft               Mobility Survey                October 2009

   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.  The two new types of
   network nodes, Local Mobility Anchor (LMA) and Mobile Access Gateway
   (MAG), together handle the local mobility without interference from
   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 performs 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;

   o  Locator: the Proxy-CoA, which is the IP address of the current

   o  Mapping: the mapping between the two kept in LMA.

Zhu, et al.              Expires April 22, 2010                [Page 20]

Internet-Draft               Mobility Survey                October 2009

4.15.  Mobile Me

   Mobile Me [BTMM] is a pragmatic approach to support mobility and has
   been deployed as real-world commercial service since 2007 (with Mac
   OS leopard release).  In this approach, Apple provides DNS server for
   all Mobile Me users.  Each mobile node performs secure DNS update to
   dynamically refresh its current location.  In the DNS database, an
   AAAA RR represents mobile node's identifier, which is an IPv6
   address, and a SRV [RFC2782] RR records mobile node's current
   location with IPv4 address, and port number in case of NAT traversal.
   Every node establishes long-lived query (llq) with DNS, which means
   that the DNS will automatically notify the node if the answer to the
   query changes.  In this way, the node only need to refresh the llq
   after a certain period, avoiding the frequent queries for the up-to-
   date location of the other communicating end host.  A node uses the
   IPv6 address in all applications.  It then uses UDP/IPv4
   encapsulation to deliver the IPv6 packets according to the DNS reply.
   Note that the IPv6 address is only for identification purpose and not
   used in routing.  In fact, it could be any form of identifier (e.g.
   HIT in HIP, domain name, etc.); IPv6 address was chosen simply
   because the designer do not want to change the IP header and cause
   problems of reusing existing code.

   Mobile ME is perhaps the first large-scale commercial host mobility
   support in Internet with millions of subscribers as of today.  It is
   simple and requires little budget to deploy.  However, it does not
   fully support mobility yet.

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

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 idea, in which the
   designer hopes to support mobility via LISP[LISP] functionality.
   Conceptually, however, it is very 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 connections, 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

   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.

Zhu, et al.              Expires April 22, 2010                [Page 22]

Internet-Draft               Mobility Survey                October 2009

5.  Different Directions towards Mobility Support

   What would be the best way to provide global scale ubiquitous
   mobility support for an essentially unlimited number of mobile
   devices with unknown future applications?  No one has the crystal
   ball that clearly shows the future.  Nevertheless, we identified
   several different directions towards mobility support by studying
   various existing protocols.  We believe a thorough understanding of
   these directions will help us make wise decisions when designing
   mobility support system for the future.

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
   which case there is not explicit "mapping" component as we discussed
   in last section.  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 require 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 as
   it does not require a mapping function; it can also provide robust
   and efficient routing, 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

   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

Zhu, et al.              Expires April 22, 2010                [Page 23]

Internet-Draft               Mobility Survey                October 2009

   of the two.  WINMO is a typically protocol in this case.

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

Zhu, et al.              Expires April 22, 2010                [Page 24]

Internet-Draft               Mobility Survey                October 2009

   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
   approach re-utilizes the DNS infrastructure, which is ubiquitous and
   quite reliable, and makes the mobility support protocol simple and
   easy to deploy.

Zhu, et al.              Expires April 22, 2010                [Page 25]

Internet-Draft               Mobility Survey                October 2009

   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

                                 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

Zhu, et al.              Expires April 22, 2010                [Page 26]

Internet-Draft               Mobility Survey                October 2009

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

   One problem of the local mobility management is that it often
   requires many infrastructure support, such as MAGs in PMIP, or MAPs

Zhu, et al.              Expires April 22, 2010                [Page 27]

Internet-Draft               Mobility Survey                October 2009

   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

   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.

Zhu, et al.              Expires April 22, 2010                [Page 28]

Internet-Draft               Mobility Survey                October 2009

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.

   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

Zhu, et al.              Expires April 22, 2010                [Page 29]

Internet-Draft               Mobility Survey                October 2009

   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.

   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

Zhu, et al.              Expires April 22, 2010                [Page 30]

Internet-Draft               Mobility Survey                October 2009

   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.

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

Zhu, et al.              Expires April 22, 2010                [Page 31]

Internet-Draft               Mobility Survey                October 2009

              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,

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

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

   [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

Zhu, et al.              Expires April 22, 2010                [Page 32]

Internet-Draft               Mobility Survey                October 2009

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

Zhu, et al.              Expires April 22, 2010                [Page 33]

Internet-Draft               Mobility Survey                October 2009

              Network Mobility", IEEE INFOCOM, 2008.

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 April 22, 2010                [Page 34]

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