summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6301.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6301.txt')
-rw-r--r--doc/rfc/rfc6301.txt1851
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc6301.txt b/doc/rfc/rfc6301.txt
new file mode 100644
index 0000000..ab9d9d2
--- /dev/null
+++ b/doc/rfc/rfc6301.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Z. Zhu
+Request for Comments: 6301 UCLA
+Category: Informational R. Wakikawa
+ISSN: 2070-1721 Toyota ITC
+ L. Zhang
+ UCLA
+ July 2011
+
+
+ A Survey of Mobility Support in the Internet
+
+Abstract
+
+ Over the last two decades, many efforts have been devoted to
+ developing solutions for mobility support over the global Internet,
+ resulting in a variety of proposed solutions. We conducted a
+ systematic survey of the previous efforts to gain an overall
+ understanding on the solution space of mobility support. This
+ document reports our findings and identifies remaining issues in
+ providing ubiquitous and efficient Internet mobility support on a
+ global scale.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6301.
+
+Copyright Notice
+
+ Copyright (c) 2011 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
+ (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
+
+
+
+Zhu, et al. Informational [Page 1]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Basic Components in Mobility Support Protocols . . . . . . . . 4
+ 4. Existing Mobility Support Protocols . . . . . . . . . . . . . 5
+ 4.1. Columbia Protocol . . . . . . . . . . . . . . . . . . . . 6
+ 4.2. VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.3. Loose Source Routing (LSR) Protocol . . . . . . . . . . . 9
+ 4.4. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.5. HMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.6. FMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.7. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.8. Mobility Support Using Multicast in IP (MSM-IP) . . . . . 13
+ 4.9. Cellular IP, HAWAII, and TIMIP . . . . . . . . . . . . . . 14
+ 4.10. E2E and M-SCTP . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.11. Host Identity Protocol . . . . . . . . . . . . . . . . . . 16
+ 4.12. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 4.13. Connexion and WINMO . . . . . . . . . . . . . . . . . . . 17
+ 4.14. ILNPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 4.15. Global HAHA . . . . . . . . . . . . . . . . . . . . . . . 18
+ 4.16. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 19
+ 4.17. Back to My Mac . . . . . . . . . . . . . . . . . . . . . . 20
+ 4.18. LISP-Mobility . . . . . . . . . . . . . . . . . . . . . . 21
+ 5. Different Directions towards Mobility Support . . . . . . . . 21
+ 5.1. Routing-Based Approach versus Mapping-Based Approach . . . 22
+ 5.2. Mobility-Aware Entities . . . . . . . . . . . . . . . . . 23
+ 5.3. Operator-Controlled Approach versus User-Controlled
+ Approach . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 5.4. Local and Global-Scale Mobility . . . . . . . . . . . . . 25
+ 5.5. Other Mobility Support Efforts . . . . . . . . . . . . . . 26
+ 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 6.1. Deployment Issues . . . . . . . . . . . . . . . . . . . . 27
+ 6.2. Session Continuity and Simultaneous Movements . . . . . . 28
+ 6.3. Trade-Offs of Design Choices on Mobility Awareness . . . . 29
+ 6.4. Interconnecting Heterogeneous Mobility Support Systems . . 30
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
+ 8. Informative References . . . . . . . . . . . . . . . . . . . . 30
+
+
+
+
+
+
+
+
+Zhu, et al. Informational [Page 2]
+
+RFC 6301 Mobility Survey July 2011
+
+
+1. Introduction
+
+ This document reports our findings from a historical survey of the
+ Internet mobility research and standardization efforts since the
+ early 1990s. Our survey was motivated by two factors. First,
+ supporting mobility over the Internet has been an active research
+ area and has produced a variety of solutions, some of which have
+ become the Internet standards. Yet, new issues continue to arise and
+ new solutions continue to be developed to address them, making one
+ wonder how much more we have yet to discover about the problem space
+ as well as the solution space. The second factor is the rapid growth
+ in Internet access via mobile devices in recent years, which will
+ inevitably lead to new Internet application development in the coming
+ years and further underscore the importance of Internet mobility
+ support. We believe that a historical review of all the proposed
+ solutions on the table can help us not only identify their
+ commonalities and differences but also clarify remaining issues and
+ shed insight on future efforts.
+
+ In this document, we provide an overview of mobility support
+ solutions from the early results to the most recent proposals. In
+ the process, we also discuss the essential components in mobility
+ support and analyze the design space. Through sharing our
+ understanding of the current stage of the art, we aim to initiate an
+ open discussion about the general direction for future mobility
+ support.
+
+ Note that the solutions discussed in this document are proposed
+ designs. They have been implemented in many cases, but only a few
+ have been widely deployed in the Internet.
+
+2. Terminology
+
+ This document uses the following terms to refer to the entities or
+ functions that are required in mobility support. Readers are
+ expected to be familiar with RFC 3753 "Mobility Related Terminology"
+ [RFC3753] before reading this document.
+
+ Identifier: A stable value that can be used to identify a mobile
+ node. Any unique value can be used as an Identifier as long
+ as it is topologically and geographically independent, i.e.,
+ remains unchanged when the mobile node roams around.
+
+ Locator: The IP address that indicates the mobile node's current
+ attachment point to the Internet. It could be the IP address
+ of the mobile node itself or the IP address of the network
+ entity that is currently serving the mobile node.
+
+
+
+
+Zhu, et al. Informational [Page 3]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ Mapping: In this document, mapping specifically means the mapping
+ between a mobile's Identifier and its Locator.
+
+ Rendezvous Point (RP): The place where the mapping is held. Some
+ other functions such as data forwarding may also be co-
+ located on the rendezvous point.
+
+ Global Mobility Management: A system that keeps track of each
+ mobile's reachability when the mobile is moving, either
+ geographically or topologically, on a global scale.
+
+ Local Mobility Management: A system that keeps track of each
+ mobile's reachability within a topologically scoped local
+ domain. It keeps the mobile's local movements transparent to
+ all entities that are outside of the local scope.
+
+ Operator-Controlled Mobility Management: The mobile node itself is
+ unaware of mobility management. Instead, certain network
+ entities, which are controlled by the network operators,
+ perform all the mobility-related signaling job on behalf of
+ the mobile node.
+
+ User-Controlled Mobility Management: The mobile node participates in
+ the mobility management. Typically, the mobile updates its
+ reachability information after it changes locations and
+ refreshes its reachability at a user-defined frequency.
+
+3. Basic Components in Mobility Support Protocols
+
+ The basic question in Internet mobility support is how to send data
+ to a moving receiver (a mobile, in short). Note that here we do not
+ distinguish between mobile nodes and mobile subnets. We call the
+ host that sends data to a mobile the Correspondent Node (CN). To
+ send data to a moving receiver M, the CN must have means to obtain
+ M's latest IP address (solution type-1) or be able to reach M using a
+ piece of stable information, where "stable" means that the
+ information does not change as the mobile moves (solution type-2).
+
+ Among the existing solutions, a few fall under type-1, and most of
+ them use DNS as the means to provide the CN with the mobile's most
+ current IP address information. The rest of the existing solutions
+ fall under type-2, which must provide the function to reach the
+ mobile's dynamically changing location by using that unchanged
+ Identifier of the mobile known to the CN. We can summarize all the
+ mobility support solutions as essentially involving three basic
+ components:
+
+
+
+
+
+Zhu, et al. Informational [Page 4]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ o a stable Identifier for a mobile;
+ o a Locator, which is usually an IP address representing the
+ mobile's current location; and
+ o a mapping between the two.
+
+ We show in the next section that different mobility support designs
+ are merely different approaches to provide mapping between the
+ Identifiers and the mobiles' current IP addresses. In type-1
+ solutions, the stable Identifier of a mobile is its DNS name, the
+ Locator is its current IP address, and the DNS server provides the
+ mapping function. In type-2 solutions, because the CN must be able
+ to reach the mobile using the stable Identifier, the Identifier
+ itself is typically an IP address; either the network can dynamically
+ find a path to reach the mobile or the IP address leads to the "home"
+ of the mobile that knows the mobile's current Locator and can thus
+ forward the CN's packets to the mobile. All the type-2 solutions
+ face two common issues. One issue is how to carry out this
+ forwarding task, given the original packet sent by the CN has the
+ mobile's "home address" as the destination; the other issue is how to
+ avoid triangle routing between the CN, the home location, and the
+ mobile.
+
+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 writing clarity. We briefly
+ describe each design and point out how it implements the three basic
+ mobility support components defined in the last section.
+
+ Figure 1 shows a list of mobility support protocols and the time they
+ were first proposed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al. Informational [Page 5]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ +----------------+-----+---------------+-----+
+ | Protocol Name |Year | Protocol Name |Year |
+ +----------------+-----+---------------+-----+
+ | Columbia |1991 | TIMIP |2001 |
+ +----------------+-----+---------------+-----+
+ | VIP |1991 | M-SCTP |2002 |
+ +----------------+-----+---------------+-----+
+ | LSR |1993 | HIP |2003 |
+ +----------------+-----+---------------+-----+
+ | Mobile IP |1996 | MOBIKE |2003 |
+ +----------------+-----+---------------+-----+
+ | MSM-IP |1997 | Connexion |2004 |
+ +----------------+-----+---------------+-----+
+ | Cellular IP |1998 | ILNPv6 |2005 |
+ +----------------+-----+---------------+-----+
+ | HMIP |1998 | Global HAHA |2006 |
+ +----------------+-----+---------------+-----+
+ | FMIP |1998 | PMIP |2006 |
+ +----------------+-----+---------------+-----+
+ | HAWAII |1999 | BTMM |2007 |
+ +----------------+-----+---------------+-----+
+ | NEMO |2000 | WINMO |2008 |
+ +----------------+-----+---------------+-----+
+ | E2E |2000 | LISP-Mobility |2009 |
+ +----------------+-----+---------------+-----+
+
+ Figure 1
+
+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 and serves as the default access router
+ for all mobile nodes in that cell. The Identifier for a mobile node
+ is an IP address derived from a special IP prefix, and the mobile
+ node uses this IP address regardless of the cell to which it belongs.
+
+ Each MSS keeps a tracking list of mobile nodes that are currently in
+ its cell by periodically broadcasting beacons. The mobile replies to
+ the MSS with a message containing its stable Identifier and its
+ previous MSS when it receives the beacon from a new MSS. The new MSS
+ is responsible to notify the old MSS that a mobile has left its cell.
+ Each MSS also knows how to reach other MSSs (e.g., all MSSs could be
+ in one multicast group, or a list of IP addresses of all MSSs could
+ be statically configured for each MSS).
+
+
+
+
+
+
+Zhu, et al. Informational [Page 6]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ When a CN sends a packet to a mobile node, the packet goes to the MSS
+ nearest to the CN (MC), which either has the mobile node in the same
+ cell and can deliver directly or broadcasts a query to all other MSSs
+ and gets a reply from the MSS (MM) with the mobile node. If it is
+ the latter case, MC tunnels the packet to MM, which will finally
+ deliver the packet to the mobile node.
+
+ Hence, in this scheme, CN uses the Identifier to reach the mobile.
+ It largely avoids triangle routing because the router next to CN is
+ mobility-aware and can intercept CN's data destined to the mobile and
+ forward to destination MSS. Since a mobile keeps the same IP address
+ independent from its movement, mobility does not affect TCP
+ connections.
+
+ An illustration of the Columbia Protocol is shown in Figure 2.
+
+ +---------+
+ | |
+ .------>| MSS |
+ | | |
+ | +---------+
+ | query
+ |
+ +--------+ query +--------+
+ | | -------------->| |
+ | MSS | <------------- | MSS |
+ | | reply | |
+ +--------+ ==============>+--------+
+ /\ data ||
+ || ||
+ || \/
+ +--------+ +---------+
+ | | | |
+ | CN | | MN |
+ | | | |
+ +--------+ +---------+
+
+ ===>: data packets
+ --->: signaling packets
+
+ Figure 2
+
+4.2. VIP
+
+ Virtual Internet Protocol [VIP] has two basic ideas. First, a packet
+ carries both Identifier and Locator; second, the Identifier is an IP
+ address that leads to the home network where the mapping is kept.
+
+
+
+
+Zhu, et al. Informational [Page 7]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ The IP header is modified to allow packets sent by a mobile to carry
+ two IP addresses: a Virtual IP address (Identifier) and a regular IP
+ address (Locator). Every time the mobile node changes its location,
+ it notifies the home network with its latest IP address. A mobile's
+ virtual address never changes and can be used to support TCP
+ connections independent of mobility.
+
+ To deliver data to a mobile, the CN first uses the mobile's Virtual
+ IP address as the destination IP address, i.e., the Locator is set to
+ be the same as the Identifier. As a result, the packet goes to the
+ home network and the Home Agent redirects the packet to mobile's
+ current location by replacing the regular IP destination address
+ field with the mobile's current address.
+
+ To reduce triangle routing, the design lets CNs and routers learn and
+ cache the Identifier-Locator mapping carried in the packets from
+ mobile nodes. When a CN receives a packet from the mobile, it learns
+ the mobile's current location from the regular IP source address
+ field. The CN keeps the mapping and uses the Locator as the
+ destination in future exchanges with the mobile. Similarly, if a
+ router along the data path to a mobile finds out that the mapping
+ carried in the packet differs from the mapping cached by the router,
+ it changes the destination IP address field to its cached value.
+ This router-caching solution is expected to increase the chance that
+ packets destined to the mobile get forwarded to the mobile's current
+ location directly, by paying a cost of having all routers examine and
+ cache all the mobile's Identifier-Locator mappings.
+
+ Figure 3 shows how the VIP Protocol works.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al. Informational [Page 8]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ ,---. +-------+
+ / \ | CN |
+ ( Router)<====| |
+ +---------+ // \ / | |
+ | | // `---' +-------+
+ | | ,---. //
+ | | / \ //
+ | Home |<--+ Router)
+ | Network | \ /
+ | | `-+-'\\
+ | | | \\ ,---. +-------+
+ | | | \\ / \=======>| |
+ | | +------( Router)<------+ MN |
+ | | \ / | |
+ | | `---' +-------+
+ +---------+
+
+ ===>: data packet
+ --->: location update message
+
+ Figure 3
+
+4.3. Loose Source Routing (LSR) Protocol
+
+ In the Loose Source Routing (LSR) Protocol [LSR], each mobile has a
+ designated router, called a Mobile Router, that manages its mobility.
+ The Mobile Router assigns an IP address (used as an Identifier) for
+ each mobile it manages and announces reachability to those IP
+ addresses. Another network entity in the LSR design is Mobile Access
+ Station (MAS), through which a mobile gets its connectivity to the
+ Internet. The mobile node reports the IP address of its current
+ serving MAS (Locator) to its Mobile Router.
+
+ The CN uses the Identifier to reach the mobile node in the first
+ place. If the CN and the mobile node are attached to the same MAS,
+ the MAS simply forwards packets between the two (in this case CN is
+ also mobile); otherwise, the packet from CN is routed to the Mobile
+ Router of the mobile. The Mobile Router looks up the mappings to
+ find the serving MAS of the mobile node and inserts the loose source
+ routing (LSR) option into the IP header of the packet with the IP
+ address of the MAS on it. In this way, the packet is redirected to
+ the MAS, which then delivers the packet to the mobile. To this
+ point, the Locator of the mobile node is already included in the LSR
+ option, and the two parties can communicate directly by reversing the
+ LSR option in the incoming packet. Hence, the path for the first
+ packet from CN to the mobile is CN->Mobile Router->MAS->mobile node,
+ and then the bidirectional path for the following packets is mobile
+ node <->MAS<->CN.
+
+
+
+Zhu, et al. Informational [Page 9]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ Triangle routing is avoided by revealing the mobile's Locator to the
+ CN in the LSR option.
+
+ Figure 4 shows the basic operation of the LSR Protocol.
+
+ +---------+
+ | |
+ ___________________| CN |
+ | | |
+ | +---------+
+ V /\
+ +-------+ ||
+ |Mobile | ||
+ |Router | ||
+ | | || Reversing LSR
+ +---+---+ ||
+ | \/
+ | +---------+ +----------+
+ | LSR Inserted | |<====>| |
+ +------------------->| MAS | | MN |
+ | |----->| |
+ +---------+ +----------+
+
+ -->: first data packet
+ ==>: following data packets
+
+ Figure 4
+
+4.4. Mobile IP
+
+ The IETF began standards development in mobility support soon after
+ the above three protocols. The first version of the Mobile IP
+ standard was developed in 1996. Later, the IETF developed the Mobile
+ IPv4 [RFC3344] and Mobile IPv6 [RFC3775] standards in 2002 and 2004,
+ respectively. In 2010, the Mobile IPv4 standard was revised
+ [RFC5944]. In 2009, Dual-Stack Mobile IPv4 [RFC5454] was
+ standardized to allow a dual-stack node to use IPv4 and IPv6 home
+ addresses and to move between IPv4 and dual-stack network
+ infrastructures.
+
+ Although the three documents differ in details, the high-level design
+ is similar. Here we use Mobile IPv6 as an example. Each mobile node
+ has a Home Agent (HA), from which it acquires its Home Address (HoA),
+ the Identifier. The mobile node also obtains its Locator, a Care-of
+ Address (CoA), from its current access router. Whenever the mobile
+ node gets a new CoA, it sends a Binding Update message to notify the
+
+
+
+
+
+Zhu, et al. Informational [Page 10]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ Home Agent. Conceptually, Mobile IPv6 design looks similar to the
+ VIP Protocol, with the mobile's HoA corresponding to the Virtual IP
+ Address in VIP and the CoA corresponding to the regular IP address.
+
+ The CN uses the mobile's HoA as the destination IP address when
+ sending data to a mobile. The packets are forwarded to the Home
+ Agent, which then encapsulates the packets to mobile node's CoA
+ according to the mapping.
+
+ To alleviate triangle routing, the CN, if it supports Route
+ Optimization, also keeps the mapping between the mobile's HoA and
+ CoA. Thus, the CN can encapsulate packets to the mobile directly,
+ without going through the Home Agent. Note that in this case, the
+ mobile needs to update its CoA to CNs as well.
+
+ Figure 5 illustrates the data path of Mobile IPv6 without Route
+ Optimization.
+
+ +---+-----+
+ |HoA|DATA |
+ +---+-----+ +-------+
+ +----------------------| CN |
+ | +------------------->| |
+ | | +-------+
+ | |
+ V |
+ +--------+
+ | Home | Mapping: HoA <=> CoA
+ | Agent |
+ | |
+ +--------+
+ || /\
+ || || +-------+
+ || +====================| |
+ || | MN |
+ +=======================>| |
+ +-----+---+---+ +-------+
+ |DATA |HoA|CoA|
+ +-----+---+---+
+
+
+ ==>: Tunnel
+ -->: regular IP
+
+ Figure 5
+
+
+
+
+
+
+Zhu, et al. Informational [Page 11]
+
+RFC 6301 Mobility Survey July 2011
+
+
+4.5. HMIP
+
+ Hierarchical Mobile IP (HMIP) [RFC5380] is a simple extension to
+ Mobile IP. It aims to improves the performance of Mobile IP by
+ handling mobility within a local region locally. A level of
+ hierarchy is added to Mobile IP in the following way. A Mobility
+ Anchor Point (MAP) is responsible for handling the movements of a
+ mobile in a local region. Simply speaking, MAP is the local Home
+ Agent for the mobile node. The mobile node, if it supports HMIP,
+ obtains a Regional CoA (RCoA) and registers it with its Home Agent as
+ its current CoA; while RCoA is the Locator for the mobile in Mobile
+ IP, it is also its regional Identifier used in HMIP. At the same
+ time, the mobile obtains a Local CoA (LCoA) from the subnet to which
+ it attaches. When roaming within the region, a mobile only updates
+ the MAP with the mapping between its RCoA and LCoA. In this way, the
+ handoff performance is usually better due to the shorter round-trip
+ time between the mobile and the MAP, as compared to the delay between
+ the mobile and its HA. It also reduces the burden of the Home Agents
+ by reducing the frequency of sending updates to Home Agents.
+
+4.6. FMIPv6
+
+ Fast Handover for Mobile IPv6 (FMIPv6) [RFC5568] is another extension
+ to Mobile IP, which reduces the Binding Update latency as well as the
+ IP connectivity latency. It is not a fully fledged mobility support
+ protocol; rather, its only purpose is to optimize the performance of
+ Mobile IP.
+
+ This goal is achieved by three mechanisms. First, it enables a
+ mobile node to detect that it has moved to a new subnet while it is
+ still connected to the current subnet by providing the new access
+ point and the corresponding subnet prefix information. Second, a
+ mobile node can also formulate a prospective New Care-of Address
+ (NCoA) when it is still present on the previous link so that this
+ address can be used immediately after it attaches to the new subnet
+ link. Third, to reduce the Binding Update interruption, FMIP
+ specifies a tunnel between the Previous Care-of Address (PCoA) and
+ the NCoA. The mobile node sends a Fast Binding Update to the
+ previous access router (PAR) after the handoff, and PAR begins to
+ tunnel packets with PCoA as the destination to NCoA. These packets
+ would have been dropped if the tunnel were not established. In the
+ reverse direction, the mobile node also tunnels packets to PAR until
+ it finishes the Binding Update process (the mobile node can only use
+ PCoA now because the binding in HA or the correspondent nodes may
+ have not been updated yet).
+
+
+
+
+
+
+Zhu, et al. Informational [Page 12]
+
+RFC 6301 Mobility Survey July 2011
+
+
+4.7. NEMO
+
+ It is conceivable to have a group of hosts moving together. Consider
+ vehicles such as ships, trains, or airplanes that may host a network
+ with multiple hosts. Because Mobile IP handles mobility per host, it
+ is not efficient when handling such mobility scenarios. Network
+ Mobility (NEMO) [RFC3963], as a backward-compatible extension to
+ Mobile IP, was introduced in 2000 to provide efficient support for
+ network mobility.
+
+ NEMO introduces a new entity called a Mobile Router (note that this
+ is different from the "Mobile Router" in the LSR Protocol). Every
+ mobile network has at least one Mobile Router. A Mobile Router is
+ similar to a mobile node in Mobile IP, but instead of having a single
+ HoA, it has one or more IP prefixes as the Identifier. After
+ establishing a bidirectional tunnel with the Home Agent, the Mobile
+ Router distributes its mobile network's prefixes (namely, Mobile
+ Prefixes) through the tunnel to the Home Agent. The Mobile Prefix of
+ a mobile network is not leaked to its access router (i.e., the access
+ router never knows that it can reach the Mobile Prefixes via the
+ Mobile Router). The Home Agent in turn announces the reachability to
+ the Mobile Prefix. Packets to and from the mobile network flow
+ through the bidirectional tunnel between the Mobile Router and the
+ Home Agent to their destinations. Note that mobility is transparent
+ to the nodes in the moving network.
+
+4.8. Mobility Support Using Multicast in IP (MSM-IP)
+
+ MSM-IP [MSM-IP] stands for Mobility Support using Multicast in IP.
+ As one can see from its name, MSM-IP leverages IP multicast routing
+ for mobility support. In IP multicast, a host can join a group
+ regardless of the network to which it attaches and receive packets
+ sent to the group after its join. Thus, mobility is naturally
+ supported in the domains where IP multicast is deployed. Note that
+ MSM-IP does not address the issue of the feasibility of supporting
+ mobility through IP multicast; rather, it simply shows the
+ possibility of using IP multicast to provide mobility support once/if
+ IP multicast is universally deployed.
+
+ MSM-IP [MSM-IP] assigns each mobile node a unique multicast IP
+ address as the Identifier. When the mobile node moves into a new
+ network, it initiates a join to its own address, which makes the
+ multicast router in that subnet join the multicast distribution tree.
+ Whoever wants to communicate with the mobile node can just send the
+ data to the mobile's multicast IP address, and the multicast routing
+ will take care of the rest.
+
+
+
+
+
+Zhu, et al. Informational [Page 13]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ 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.
+
+4.9. Cellular IP, HAWAII, and TIMIP
+
+ This is a group of protocols that share the common idea of setting up
+ a host route for each mobile in the local domain. The mobile retains
+ a stable IP address as long as it is within the local domain, and
+ this IP address is used as a regional Identifier. The gateway router
+ of the local domain will use this Identifier to reach the mobile
+ node. All three protocols are intended to work with Mobile IP as a
+ local mobility management protocol. By describing them together, we
+ can more easily show the differences by comparison.
+
+ Cellular IP [CIP] handles the local mobility in a network consisting
+ of Cellular IP routers. A mobile reports the IP address of the
+ gateway for the local network as the RCoA to its Home Agent and
+ retains its locally assigned IP address (the regional Identifier)
+ when it roams within the Cellular IP network. The routers in the
+ network monitor the packets originating from mobile nodes and
+ maintain a distributed, hop-by-hop reverse path for each mobile node.
+ Cellular IP utilizes the paging technique from the cellular network
+ to track the location of each mobile: idle mobile nodes send dummy
+ packets to the gateway router with a relatively low frequency to
+ update their reverse paths in the routers. The outdated path will
+ not be cleared explicitly after the mobile changes its location;
+ instead, it will be flushed by the routers if the paging timer
+ expires before the next dummy packet comes. To reduce the paging
+ cost, only a subset of the routers would set up a reverse path for
+ the idle mobile nodes.
+
+ When a packet from the CN arrives at the gateway, the gateway
+ initiates a controlled flooding query. If a router knows where to
+ forward a packet, it forwards it immediately; otherwise, it forwards
+ the packet to all its interfaces except the one from which the packet
+ came. Due to the paging technique, this will not become a broadcast.
+ Once the mobile receives the query, it replies with a route-update
+ message to the gateway, and a much more precise reverse path is then
+ maintained by all the routers along the data path, via which the
+ gateway router forwards packets from CN to the mobile. Note that the
+ timer value for the precise data path is much smaller than the paging
+ timer value, in order to avoid sending duplicate data packets to
+ multiple places if the mobile moves during the data communication.
+
+
+
+
+
+
+Zhu, et al. Informational [Page 14]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ Similarly, Handoff-Aware Wireless Access Internet Infrastructure
+ (HAWAII) [HAWAII] also aims to provide efficient local mobility
+ support. Unlike Cellular IP, the route between the gateway router
+ and the mobile is always maintained. When the mobile moves, HAWAII
+ dynamically modifies the route to the mobile by installing a host-
+ based forwarding entry on the routers located along the shortest path
+ between the old and new base stations of the mobile. It is possible
+ that a longer suboptimal routing path will be constructed (e.g.,
+ gateway router->old base station->new base station->mobile).
+ Alternatively, a new sub-path between the mobile and the cross-over
+ router can be established. Here, the cross-over router is the router
+ at the intersection of two paths, one between the gateway and the old
+ base station and the second between the old base station and the new
+ base station. In HAWAII, the mobile only periodically sends refresh
+ messages to the base station, and the base station along with other
+ routers take care of the path maintenance.
+
+ TIMIP [TIMIP], which stands for Terminal Independent Mobile IP,
+ integrated the design of Cellular IP and HAWAII. On one hand, it
+ refreshes the routing paths with dummy packets if the mobile node is
+ idle. On the other hand, handoff within a domain results in the
+ changes of routing tables in the routers. Besides, the IP layer is
+ coupled with layer 2 handoff mechanisms, and special nodes can work
+ as Mobile IP proxies for legacy mobiles that do not support Mobile
+ IP. Thus, as long as the mobile roams within the domain, the legacy
+ node has the same degree of mobility support as a Mobile-IP-capable
+ node.
+
+4.10. E2E and M-SCTP
+
+ E2E (End-to-End) communication [E2E] gets its name from its end-to-
+ end architecture and is the first proposal that utilizes existing DNS
+ service to track a mobile node's current location. The stable
+ Identifier here is the domain name of the mobile. The mobile uses
+ Dynamic DNS to update its current IP address in DNS servers. To keep
+ the ongoing TCP connection unaffected by mobility, a TCP Migrate
+ option is introduced to allow both ends to replace the IP addresses
+ and ports in TCP 4-tuple on the fly. Thus, the CN can query DNS to
+ obtain the current Locator of the mobile, and after the TCP
+ connection is established, the mobile will be responsible for
+ updating its Locator for this session.
+
+ Inspired by E2E, Mobile Stream Control Transmission Protocol (M-SCTP)
+ [M-SCTP] was proposed in 2002. Similarly, it uses Dynamic DNS to
+ track the mobile nodes and allows both ends to add/delete IP
+ addresses used in Stream Control Transmission Protocol (SCTP)
+ associations during the move.
+
+
+
+
+Zhu, et al. Informational [Page 15]
+
+RFC 6301 Mobility Survey July 2011
+
+
+4.11. Host Identity Protocol
+
+ The Host Identify Protocol (HIP) [RFC5201] assigns each host an
+ Identifier made of cryptographic keys and adds a new Host Identity
+ layer between the transport and network layers. Host Identities,
+ which are essentially public keys, are used to identify the mobile
+ nodes, and IP addresses are used only for routing purposes. In order
+ to reuse the existing code, a Host Identity Tag (HIT), which is a
+ 128-bit hash value of the Host Identity, is used in transport and
+ other upper-layer protocols.
+
+ HIP can use DNS as the rendezvous point that holds the mappings
+ between HITs and IP addresses. However, HIP by default uses its own
+ static infrastructure Rendezvous Servers in expectation of better
+ rendezvous service. Each mobile node has a designated Rendezvous
+ Server (RVS), which tracks the current location of the mobile node.
+ When a CN wants to communicate with mobile node, it queries DNS with
+ a mobile node's HIT to obtain the IP address of the mobile node's RVS
+ and sends out the first packet. After receiving this first packet,
+ RVS relays it to the mobile node. The mobile node and correspondent
+ node can then start communication on the direct path. If the mobile
+ node moves to a new address, it notifies the CN by sending HIP UPDATE
+ with LOCATOR parameter indicating its new IP address (Locator).
+ Meanwhile, it also updates the mapping in RVS.
+
+4.12. MOBIKE
+
+ IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] is an
+ extension to Internet Key Exchange (IKEv2) to support mobility and
+ multihoming. The main purpose of MOBIKE is to allow roaming devices
+ to keep the existing IKE and IPsec Security Associations (SAs)
+ despite IP address changes. The mobility support in MOBIKE allows
+ both parties to move, but it does not provide a rendezvous mechanism.
+ In other words, simultaneous movement of both parties is not
+ supported.
+
+ MOBIKE allows both parties to have a set of addresses, and the party
+ that initiated the IKE_SA is responsible for deciding which pair of
+ addresses to use. During the communication session, if the initiator
+ wishes to change the addresses due to movement, it updates the IKE_SA
+ with new IP addresses and also updates the IPsec SAs associated with
+ this IKE_SA. Then it sends an INFORMATIONAL request containing the
+ UPDATE_SA_ADDRESSES notification to the other party. The responder
+ then checks the local policy and updates the IP addresses in the
+ IKE_SA with the values from the IP header. It replies to the
+ initiator with an INFORMATIONAL response, initiates a return
+ routability check if it wants to, and updates the IPsec SAs
+ associated with this IKE_SA.
+
+
+
+Zhu, et al. Informational [Page 16]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ MOBIKE is not a fully fledged mobility protocol, and it does not
+ intend to be one. Nevertheless, through the use of IPsec tunnel
+ mode, MOBIKE partially supports mobility as it can dynamically update
+ the tunnel endpoint addresses.
+
+4.13. 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 (stable Identifier), and the CN uses
+ this Identifier to reach the moving network, which means that the
+ global routing system is responsible for finding a path to the mobile
+ network. When an airplane moves between its access routers on the
+ ground, it withdraws its prefix from the previous access router and
+ announces the prefix via the new access point. As a result, the
+ location change of the plane is effectively propagated to the rest of
+ the world. However, if the number of moving networks becomes large,
+ the amount of BGP updates will also increase proportionally,
+ resulting in severe global routing dynamics.
+
+ WINMO [WINMO] (which stands for Wide-Area IP Network Mobility) was
+ introduced in 2008 to address the routing update overhead problem of
+ Connexion. Like Connexion, WINMO also assigns each mobile network a
+ stable prefix. However, through two new approaches, WINMO can reduce
+ the BGP updates overhead for mobile networks by orders of magnitude
+ lower than those of Connexion. First, WINMO uses various heuristics
+ to reduce the propagation scope of routing updates caused by mobile
+ movements. Consequently, not every router may know all the mobiles'
+ current locations. Handling this issue led to the second and more
+ fundamental approach taken by WINMO: it adopts the basic idea from
+ Mobile IP by assigning each mobile network a "home" in the following
+ way. WINMO assigns each mobile network a prefix out of a small set
+ of well-defined Mobile Prefixes. These Mobile Prefixes are announced
+ by a small set of Aggregation Routers, which also keep track of the
+ mobile network's current locations. Therefore, these Aggregation
+ Routers play a similar role to Home Agents in Mobile IP and can be
+ counted on as a last resort to reach mobile networks globally.
+
+ To prevent frequent Interior Border Gateway Protocol (iBGP) routing
+ updates due to the movement of mobile networks within an Autonomous
+ System (AS), WINMO also introduces a Home Agent for the Mobile
+ Prefixes: only a Designated BGP-speaking Router (DBR) acts as the
+ origin of Mobile Prefixes, and mobile networks always update the
+ addresses of their access routers (intra-AS Locators) with DBR, which
+ resembles the binding updates in Mobile IP. Thus, packets destined
+ to mobile networks are forwarded to DBR after they enter the border
+ of an AS, and DBR will tunnel them to the current locations of mobile
+ networks.
+
+
+
+Zhu, et al. Informational [Page 17]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ A new BGP community attribute, which includes the mobile network's
+ intra-AS Locator in each packet, is also defined to eliminate the
+ triangle-routing problem caused by DBR. The border routers of the AS
+ can tunnel packets directly to the mobile network based on the new
+ attribute.
+
+4.14. ILNPv6
+
+ ILNPv6 [ILNP] stands for Identifier-Locator Network Protocol for
+ IPv6. The ILNPv6 packet header was deliberately made similar to the
+ IPv6 header. Essentially, it breaks an IPv6 address into two
+ components: high-order 64 bits as a Locator and low-order 64 bits as
+ an Identifier. The Identifier identifies a host, instead of an
+ interface, and is used in upper-layer protocols (e.g., TCP, FTP); on
+ the other hand, the Locator changes with the movement of the mobile
+ node, and a set of Locators can be associated with a single
+ Identifier. Several new DNS resource records (RRs) are required,
+ among which I (Identifier Record) and L (Locator Record) are most
+ important. As in current Internet, the CN will query the DNS about
+ the mobile's domain name to determine where to send the packet.
+ During the movement, the mobile node uses Secure Dynamic DNS update
+ to ensure that the Locator values stored in DNS are up to date. It
+ also sends Locator Update messages to the CNs that are currently
+ communicating with it. As an optimization, ILNPv6 supports soft-
+ handoff, which allows the use of multiple Locators simultaneously to
+ achieve smooth transition. ILNPv6 also supports mobile networks.
+
+4.15. Global HAHA
+
+ Global Home Agent to Home Agent (HAHA) [HAHA], first proposed in 2006
+ as an extension to Mobile IP, aims to eliminate the triangle-routing
+ problem in Mobile IP and NEMO by distributing multiple Home Agents
+ globally. All the Home Agents join an IP anycast group and form an
+ overlay network. The same home prefix is announced by all the Home
+ Agents from different locations. Each mobile node can register with
+ any Home Agent that is closest to it. A Home Agent H that accepts
+ the binding request of a mobile node M becomes the primary Home Agent
+ for M and notifies all other Home Agents of the binding [M, H] so
+ that the binding information databases for all the mobiles in all
+ Home Agents are always synchronized. When a mobile moves, it may
+ switch its primary Home Agent to another one that becomes closest to
+ the mobile.
+
+ A correspondent node sends packets to a mobile's Home Address.
+ Because of anycast routing, the packets are delivered to the nearest
+ Home Agent. This Home Agent then encapsulates the packets to the IP
+ address of the primary Home Agent that is currently serving the
+ mobile node, which will finally deliver the packets to the mobile
+
+
+
+Zhu, et al. Informational [Page 18]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ node after striping off the encapsulation headers. In the reverse
+ direction, this approach works exactly the same as Mobile IP. If the
+ Home Agents are distributed widely, the triangle-routing problem is
+ naturally alleviated without Route Optimization.
+
+ The data flow in Global HAHA is shown in Figure 6.
+
+ +------+ +------+ +-----+
+ | HA |-------------| HA | | |
+ | | | | | CN |
+ +--+---+ +------+++----+ +-----+
+ | | || /\
+ | | || ||
+ | | || ||
+ | | || ||
+ +--+---+------+ || ||
+ | |<==============+ ||
+ | HA |==============================+
+ +-++---+
+ || /\
+ \/ ||
+ +---++-+ ===>: data flow
+ | | ----: HA overlay network
+ | MN |
+ +------+
+
+ Figure 6
+
+4.16. Proxy Mobile IP
+
+ Proxy Mobile IP (PMIP) [RFC5213] was proposed in 2006 to meet the
+ interest of mobile network operators who desire to support mobility
+ in a network rather than on mobile devices and to have tighter
+ control on mobility support. Mobility is completely transparent to
+ the mobile devices and is provided to legacy IP devices. PMIP
+ introduces two new types of network nodes, Local Mobility Anchor
+ (LMA) and Mobile Access Gateway (MAG), which together can support
+ mobility within an operator's network without any action taken by the
+ mobile node. LMA serves as a local Home Agent and assigns a local
+ Home Network Prefix for each mobile node. This prefix is the
+ Identifier for the mobile node within the PMIP domain. MAGs monitor
+ the attaching and detaching events of the mobile node and generate
+ Proxy Binding Update to LMA on behalf of the mobile node during
+ handoff. After the success of binding, LMA updates the mobile node's
+ Proxy-CoA (Locator in PMIP domain) with the IP address of the MAG
+ that is currently serving the mobile node. The MAG then emulates the
+ mobile node's local Home Link by advertising the mobile node's local
+ Home Network Prefix in Router Advertisement. When roaming in the
+
+
+
+Zhu, et al. Informational [Page 19]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ PMIP domain, the mobile node always obtains its local Home Prefix and
+ believes that it is on a local Home Link. Within the domain, the
+ mobile node is reached by the Identifier, and LMA tunnels packets to
+ the mobile node according to the mapping.
+
+4.17. Back to My Mac
+
+ Back to My Mac (BTMM) [RFC6281] is an engineering approach to
+ mobility support and has been deployed since 2007 with Mac OS Leopard
+ release. Each user gets a MobileMe account (which includes BTMM
+ service), and Apple, Inc. provides DNS service for all BTMM users.
+ The reachability information of the user's machine is published in
+ DNS.
+
+ A mobile uses secure DNS update to dynamically refresh its current
+ location. Each host generates an IPv6 Unique Local Address (ULA)
+ [RFC4193] at boot time, which is stored in the DNS database as its
+ topologically independent Identifier. The host's current IPv4
+ address (which is the IPv4 address of the NAT box if the host is
+ behind a NAT) is stored in a SRV resource record [RFC2782] together
+ with a transport port number needed for NAT traversal. Every node
+ establishes a long-lived query (LLQ) session with the DNS server so
+ that the DNS server can immediately notify each node when the answer
+ to its query has changed. A host uses its Identifier in transport
+ protocols and applications and uses UDP/IPv4 encapsulation to deliver
+ data packets using information learned from the SRV RR. Note that
+ the Locator here is the IPv4 address plus the transport port number
+ and that the IPv6 address is only for identification purposes. In
+ fact, it could be any form of Identifier (e.g., domain name); BTMM
+ chose to use IPv6 addresses so that its implementation can reuse
+ existing code.
+
+ BTMM is currently used by millions of subscribers. It is simple and
+ easy to deploy. However, the current applications use BTMM service
+ in a "stop-and-reconnect" fashion. It remains to be seen how well
+ BTMM can support continuous communications while hosts are on the
+ move, for example, as needed for voice calls.
+
+ Figure 7 shows the basic architecture of BTMM.
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al. Informational [Page 20]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ DDNS update +--------+ DDNS update
+ +--------------->| |<-------+
+ | | DNS | |
+ | LLQ | | LLQ |
+ | +---------->| |<----+ |
+ | | | | | |
+ | | +--------+ | |
+ | | | | +---------+
+ | V +---+--+----+ | |
+ ++-------+ | +-------| |
+ |Endhost1| Tunnel | NAT +------>|Endhost2 |
+ | |<=====================================>| |
+ +--------+ | | | |
+ +-----------+ +---------+
+
+ Figure 7
+
+4.18. LISP-Mobility
+
+ LISP-Mobility [LISP-Mobility] is a relatively new design. Its
+ designers hope to utilize functions and services provided by
+ Locator/ID Separation Protocol (LISP) [LISP], which is designed for
+ Internet routing scalability, to support mobility as well.
+ Conceptually, LISP-Mobility may seem similar to some protocols we
+ have mentioned so far, such as ILNPv6 and Mobile IP. Lightweight
+ Ingress Tunnel Router and Egress Tunnel Router functions are
+ implemented on each mobile node, and all the packets to and from the
+ mobile node are processed by the two router functions (so the mobile
+ node looks like a LISP site). Each mobile node is assigned a static
+ Endpoint ID, as well as a preconfigured Map-Server. When a mobile
+ node roams into a network and obtains a new Routing Locator, it
+ updates its Routing Locator set in the Map-Server, and it also clears
+ the cached Routing Locator in the Ingress Tunnel Routers or Proxy
+ Tunnel Routers of the CNs. Thus, the CN can always learn the up-to-
+ date location of the mobile node by the resolution of the mobile
+ node's Endpoint ID, either issued by itself or issued after receiving
+ the notification from the mobile node about the staled cache. The
+ data would always travel through the shortest path. Note that both
+ Endpoint IDs and Routing Locators are essentially IP addresses.
+
+5. Different Directions towards Mobility Support
+
+ After studying various existing protocols, we identified several
+ different directions for mobility support.
+
+
+
+
+
+
+
+Zhu, et al. Informational [Page 21]
+
+RFC 6301 Mobility Survey July 2011
+
+
+5.1. Routing-Based Approach versus 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 a mobile's
+ movements and reflect its current position in the network on the
+ routing table so that at any given moment packets carrying the
+ (stable) receiver's IP address can be delivered to the right place.
+
+ It is also worthwhile to identify two sub-classes in routing-based
+ approaches. One is broadcast based, and the other is path based. In
+ the former case, either the mobile's location information is actively
+ broadcasted to the whole network or a proactive broadcast query is
+ needed to obtain the location information of a mobile (e.g., Columbia
+ and Connexion); in the latter case, on the other hand, a host-based
+ path is maintained by the routing system instead (e.g., Cellular IP,
+ HAWAII, and TIMIP).
+
+ Supporting mobility through dynamic routing is conceptually simple;
+ it can also provide robust and efficient data delivery, assuming that
+ the routing system can keep up with the mobile movements. However,
+ because either the whole network must be informed of every movement
+ by every mobile or a host-based path must be maintained for every
+ mobile host, this approach is feasible only in small-scale networks
+ with a small number of mobiles; it does not scale well in large
+ networks or for a large number of mobiles.
+
+ The second approach to mobility support is to provide a mapping
+ between a mobile's stable Identifier and its dynamically changing IP
+ address. Instead of notifying the world on every movement, a mobile
+ only needs to update a single binding location about its location
+ changes. In this approach, if one level of indirection at IP layer
+ is used, as in the case of Mobile IP, it has a potential side effect
+ of introducing triangle routing; otherwise, if the two end nodes are
+ aware of each other's movement, it means that both ends have to
+ support the same mobility protocol.
+
+ Yet, there is the third case in which the protocols combine the above
+ approaches in the hope of keeping the pros and eliminating some cons
+ of the two. WINMO is a typical protocol in this case.
+
+ In Figure 8, we show the classification of the existing protocols
+ according to the above analysis.
+
+
+
+
+Zhu, et al. Informational [Page 22]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ +---------------+-------------------------------------------+
+ | | VIP, LSR, Mobile IP, HMIP, NEMO, E2E, |
+ | Mapping-based | M-SCTP, ILNPv6, HIP, FMIP, PMIP, |
+ | | BTMM, GLOBAL HAHA, LISP-Mobility |
+ +---------------+-------------------------------------------+
+ | | Columbia, Connexion |
+ | Routing-based +-------------------------------------------+
+ | | Cellular IP, HAWAII, TIMIP, MSM-IP |
+ +---------------+-------------------------------------------+
+ | Combination | WINMO |
+ +---------------+-------------------------------------------+
+
+ Figure 8
+
+5.2. Mobility-Aware Entities
+
+ Among the various design choices, a critical one is how many entities
+ are assumed to be mobility-aware. There are four parties that may be
+ involved during a conversation with a mobile: the mobile itself, CN,
+ the network, and the Home Agent or its equivalent (additional
+ component to the existing IP network that holds the mapping). We
+ mainly focus our discussion on the mapping-based approach here.
+
+ The first design choice is to hide the mobility from the CN, based on
+ the assumption that the CN may be the legacy node that does not
+ support mobility. In this approach, the IP address that is used as
+ the mobile's Identifier points to the Home Agent or its equivalent
+ that keeps track of the mobile's current location. If a
+ correspondent node wants to send packets to a mobile node, it sets in
+ the destination field of IP header an IP address, which is a mobile's
+ Identifier. The packets will be delivered to the location where the
+ mapping information of the mobile is kept, and later they will be
+ forwarded to the mobile's current location via either encapsulation
+ or destination address translation. Mobile IP and most of its
+ extensions, as well as several other protocols fall into this design.
+
+ The second design choice is to hide the mobility from the mobile and
+ CN, which is based on a more conservative assumption that both the
+ mobile and the CN do not support mobility. Protocols like PMIP and
+ TIMIP adopt this design. The protocol operations in this design
+ resemble those in the first category, but a significant difference is
+ that here the mobility-related signaling (e.g., the update Locator to
+ the Home Agent) is handled by the entities in the network rather than
+ by the mobile itself. Hence, the mobile blissfully assumes that it
+ is always in the same subnet.
+
+
+
+
+
+
+Zhu, et al. Informational [Page 23]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ The third one is to let both the mobile and the CN be mobility-aware.
+ As a result, the network is not aware of the mobility, and no
+ additional component is required. As an increasing number of mobile
+ devices are connected to the Internet (Why hide mobility from them?),
+ this design choice seems to be more and more appealing. One common
+ approach taken by this design is to use DNS to keep track of mobiles'
+ current locations. Mobiles use dynamic DNS updates to keep their DNS
+ servers updated with their current locations. This approach
+ re-utilizes the DNS infrastructure, which is ubiquitous and quite
+ reliable, and makes the mobility support protocol simple and easy to
+ deploy. Protocols like E2E, ILNP, and BTMM fall into this design.
+ Although HIP adds special-purpose rendezvous servers to the network
+ to replace the role of DNS, both mobile and CN are still mobility-
+ aware; hence, it is also classified in this category.
+
+ Figure 9 shows the three categories of protocols.
+
+ +-------------+----------------------------------+
+ | Design 1 | VIP, LSR, Mobile IP, HMIP, NEMO, |
+ | | Global HAHA |
+ +-------------+----------------------------------+
+ | Design 2 | PMIP, TIMIP |
+ +-------------+----------------------------------+
+ | Design 3 | E2E, M-SCTP, ILNPv6, HIP, |
+ | | BTMM, LISP-Mobility |
+ +-------------+----------------------------------+
+
+ Figure 9
+
+5.3. Operator-Controlled Approach versus User-Controlled Approach
+
+ At the time of this writing, cellular networks are providing the
+ largest operational global mobility support, using a service model
+ that bundles together device control, network access control, and
+ mobility support. The tremendous success of the cellular market
+ speaks loudly that the current cellular service model is a viable one
+ and is likely to continue into the foreseeable future. Consequently,
+ there is a strong advocate in the IETF that we continue the cellular
+ way of handling mobility, i.e., instead of letting mobile devices
+ participate in the mobility-related signaling themselves, the network
+ entities deployed by the operators should take care of any and all
+ signaling processes of mobility support. A typical example along
+ this direction is Proxy Mobile IP, in which LMA works together with
+ MAGs to assure the reachability to the mobile using its Home
+ Prefixes, as long as the mobile roams within the same provider's
+ domain.
+
+
+
+
+
+Zhu, et al. Informational [Page 24]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ One main reason for this approach is perhaps backward compatibility.
+ By not requiring the participation of mobiles in the control-
+ signaling process, it avoids any changes to the mobile nodes so that
+ the mobile nodes can stay simple and all the legacy nodes can obtain
+ the same level of mobility services as the latest mobile devices.
+ According to the claim of 3G vendors and operators, transparent
+ mobility support is a key aspect for success as they learn from their
+ deployment experience.
+
+ On the other hand, most of the mobility support protocols surveyed in
+ this document focus on mobility support only, assuming mobiles
+ already obtained network access. Mobile nodes typically update their
+ locations themselves to the rendezvous points chosen by the users,
+ and, of course, only the nodes implementing one of these solutions
+ can benefit from mobility support. However, this class of protocols
+ does offer users and mobile devices more flexibility and freedom,
+ e.g., they can choose whatever mobility services are available as
+ long as their software supports that protocol, and they can also tune
+ the parameters to get the services that are most suitable to them.
+
+5.4. Local and Global-Scale Mobility
+
+ The work done on mobility management can also be divided into two
+ categories according to scale: local mobility management and global
+ mobility management.
+
+ Global mobility management is typically supposed to support mobility
+ of an unlimited number of nodes in a geographically as well as
+ topologically large area. Consequentially, it pays a lot of
+ attention to scalability issues. For the availability concern, it
+ also tries to avoid failure of single point.
+
+ Local mobility management, on the other hand, is designed to work
+ together with global mobility management and thus focuses more on
+ performance issues, such as handoff delay, handoff loss, local data
+ path, etc. Since it is typically used on a small scale with a not-
+ so-large number of mobile nodes, sometimes the designers can use some
+ fine-tuned mechanisms that are not scaled with a large network (such
+ as host route) to improvement performance. As a side effect of local
+ mobility management, the number of location updates sent by mobile
+ nodes to their global rendezvous points is substantially reduced.
+ Thus, the existence of local mobility management also contributes to
+ the scalability of global mobility management.
+
+ One problem of local mobility management is that it often requires
+ infrastructure support, such as MAGs in PMIP or MAPs in HMIP. These
+ kinds of local devices are essentially required in all small domains,
+ which can be a huge investment.
+
+
+
+Zhu, et al. Informational [Page 25]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ Nevertheless, mobility management in two scales make it possible for
+ designers to design protocols that fit into specific user
+ requirements; it also enables the gradual deployment of local
+ enhancement while not losing the ability of global roaming. The
+ coexistence of the two seems to be a right choice in the foreseeable
+ future.
+
+ Figure 10 shows the classification of the studied protocols according
+ to their serving scale.
+
+ +-----------+-----------------------------------------+
+ | | VIP, LSR, Mobile IP, NEMO, E2E, M-SCTP, |
+ | Global | HIP, ILNPv6, Connexion, WIMO, BTMM, |
+ | | MSM-IP, Global HAHA, LISP-Mobility |
+ +-----------+-----------------------------------------+
+ | Local | Columbia, HMIP, FMIP, Cellular IP, |
+ | | HAWAII, TIMIP, PMIP |
+ +-----------+-----------------------------------------+
+
+ Figure 10
+
+5.5. Other Mobility Support Efforts
+
+ Despite the wide spectrum of mobility solutions covered by this
+ survey, the list of mobility protocols is not exhaustive.
+
+ The General Packet Radio Service (GPRS) Tunneling Protocol [GTP] is a
+ network-based mobility support solution widely used in cellular
+ networks. Its implementation only involves Gateway GPRS Support Node
+ (GGSN) and Serving GPRS Support Node (SGSN). It allows end users of
+ a Global System for Mobile Communications (GSM) or Universal Mobile
+ Telecommunications System (UMTS) network to move from place to place
+ while remaining connected to the Internet as if from on location at
+ the GGSN. It does this by carrying the subscriber's data from the
+ subscriber's current SGSN to the GGSN that is handling the
+ subscriber's session. To some extent, it is the non-IETF variant of
+ PMIP, with GGSN resembling LMA and SGSN resembling MAG, respectively.
+
+ There is also work on application-layer mobility support, most
+ notably SIP-based mobility support [ALM-SIP]. SIP was initially
+ designed as an application signaling protocol for multimedia, and
+ later researchers noticed its potential capability for mobility
+ support. When the mobile initiates a session with CN, normal SIP-
+ signaling procedure is performed to establish the session. When the
+ mobile moves to a new network while the session is ongoing, it send a
+ RE-INVITE message with the existing session but reveals the new IP
+ address to the CN. The home SIP server is also updated with the
+
+
+
+
+Zhu, et al. Informational [Page 26]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ latest location information of the mobile after the move. However,
+ the SIP-based approach cannot maintain TCP connections when the
+ mobile's IP address changes.
+
+ A lot of enhancements to Mobile IPv6 Route Optimization have also
+ been developed. A comprehensive taxonomy and analysis of these
+ efforts can be found in [RFC4651].
+
+6. Discussions
+
+ In the last section, we discussed the different directions towards
+ mobility support. We now turn our attention to identify both new
+ opportunities and remaining open issues in providing global-scale
+ mobility support for an unlimited number of online mobility devices.
+ We are not trying to identify the solutions to these issues, but
+ rather, the goal is to share our opinions and to initiate an open
+ discussion.
+
+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, only in recent years has the number
+ of mobiles soared. Hence, operators did not see the incentive of
+ deploying mobility support protocols several years back. As of
+ today, the number of mobiles is still growing by leaps and bounds,
+ and there is enough user demand for the operators to seriously
+ consider the deployment of mobility support protocols.
+
+ Second, the complexity of most mobility support protocols impedes the
+ implementation and hence the deployment in commercial networks. The
+ complexity arises from multiple aspects. One is the optimizations on
+ performance. The other is the problem with the use of security
+ protocols such as IPsec and IKE. The discussions regarding to these
+ two problems are still ongoing in the MEXT Working Group. Some
+ researchers argue that the research community should design a "barely
+ work" version of a mobility support protocol first, without
+ considering nice performance features and complex security
+ mechanisms, roll it out in the real world, and improve it thereafter.
+ However, there are different views on what the essential features are
+ and which security mechanisms are better.
+
+ Third, almost all the mobility support protocols assume that the
+ mobile nodes have network connectivity anywhere, anytime. In
+ reality, however, this is not always the case. Nevertheless,
+
+
+
+Zhu, et al. Informational [Page 27]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ wireless access is available in more and more places, and it is
+ foreseeable that in the near future, the coverage of wireless access
+ in different forms (WiFi, Wimax, 3G/4G) will be ubiquitous.
+
+6.2. Session Continuity and Simultaneous Movements
+
+ In order for users to benefit from mobility support, it is important
+ to keep the TCP sessions uninterrupted by the mobility. If the
+ durations of the sessions are short (e.g., web browsing), the
+ probability is high that the TCP sessions finish before the handover
+ happens; even if the TCP session is interrupted by the handover, the
+ cost is usually low (e.g., refresh the web page). However, if the
+ TCP sessions are typically long (e.g., downloading large files and
+ voice calls), the interruptions during the handover would become
+ unacceptable.
+
+ It is hard to predict tomorrow's applications, but most mobility
+ support protocols try to keep the sessions up during movements. For
+ routing-based protocols, session continuity is not a problem since
+ the IP address of the mobile never changes. For other protocols,
+ either a stable IP address (e.g., HoA) or an equivalent (e.g., HIT)
+ is used in the transport layer so that the mobility is hidden, or TCP
+ is modified so that both ends can change IP addresses while keeping
+ the established session (e.g., E2E).
+
+ Another concern is the support of simultaneous movements. In some
+ scenarios, only one end is mobile, and the other end is always
+ static; moreover, the communication between the two is always
+ initiated by the mobile end. A lot of applications as of today fall
+ into this category. Typically, the server side is static, and the
+ client is mobile; usually, the client would contact the server first.
+ Hence, in these scenarios, the support of simultaneous movements is
+ not a requirement. However, in other scenarios, both ends may be
+ moving at the same time. For example, during a voice call, two
+ mobile nodes may experience handovers simultaneously. In this case,
+ a rendezvous point is necessary to keep the current locations of the
+ mobiles so that they can find each other after a simultaneous
+ movement. Besides, if a static server wants to push information to a
+ mobile client, a rendezvous point is also required.
+
+ It is clear that the number of mobile devices is rapidly growing, and
+ more mobiles are going to provide content in the near future. Hence,
+ the simultaneous-movements scenarios are considered important. In
+ fact, almost all the mobility support protocols are equipped with
+ rendezvous points, either by adding dedicated components or by
+ leveraging the existing DNS systems.
+
+
+
+
+
+Zhu, et al. Informational [Page 28]
+
+RFC 6301 Mobility Survey July 2011
+
+
+6.3. Trade-Offs of Design Choices on Mobility Awareness
+
+ The mobility awareness at two communicating ends is closely related
+ to the backward-compatibility problem. The Internet has been running
+ for more than two decades, and the scale of the Internet gets so
+ large that it is impossible to upgrade the whole system overnight.
+ As a result, it is also not possible for a mobility support system
+ designer to overlook this problem: how does one decide the mobility
+ awareness in the protocol design, and how important is backward
+ compatibility?
+
+ In the following text, we discuss the trade-offs of the design
+ choices mentioned in Section 5.2.
+
+ The advantage of the first design choice is that the mobile does not
+ lose the ability to communicate with legacy nodes while roaming
+ around, i.e., the mobile can benefit from unilateral deployment of
+ mobility support. Another potential advantage is that the static
+ nodes do not need to be bothered by the mobility of the mobiles,
+ which saves resources and could be desirable if the CN is a busy
+ server. The disadvantage of this design is also well known: it
+ introduces triangle routing, which significantly increases the delays
+ in the worst cases. There are means to remedy the problem, e.g.,
+ Route Optimization in Mobile IP if a CN is mobility-capable and
+ distribution of Home Agents as Global HAHA does, at the expense of
+ increasing complexity.
+
+ The second design caters to the inertness of the Internet (and the
+ users) by keeping everything status quo from the user's point of
+ view. It is like the cellular network, with the smart network and
+ dumb terminals. The advantage is that the legacy nodes can benefit
+ from the mobility support without upgrade. However, the cost is also
+ not trivial: the users lose the freedom of control in terms of
+ mobility management, and a large number of entities in the network
+ need to be upgraded.
+
+ The third design assumes that the other end is likely also mobility-
+ capable (as of today, more people are accessing the Internet via
+ mobile devices than a desktop) and thus does not provide backward
+ compatibility at all; however, as a trade-off, the system design
+ becomes much simpler, and the data path is always the shortest one.
+
+ We all know that backward compatibility is important in system
+ design. But how important is it? How much effort should we make for
+ this issue? At least for now, the answer is not yet clear.
+
+
+
+
+
+
+Zhu, et al. Informational [Page 29]
+
+RFC 6301 Mobility Survey July 2011
+
+
+6.4. Interconnecting Heterogeneous Mobility Support Systems
+
+ As our survey suggests, multiple solutions for mobility support are
+ already exist, and it is almost for sure that the mobility support
+ systems in the future are going to be heterogeneous. However, as of
+ today, the interoperation between different protocols is still
+ problematic. For example, when a mobile node supporting Mobile IP
+ only wants to communicate with another mobile with only HIP support,
+ neither of them can benefit from mobility support.
+
+ This situation reminds us the days before IP was adopted. In that
+ time, the hosts in different networks were not able to communicate
+ with each other. IP merged the networks and created the Internet,
+ where each host can freely communicate with any other host. Is it
+ necessary to introduce something like IP to mobility support in the
+ future? Is it possible to design an architecture so that it glues
+ all the mobility support systems together? We believe the answers to
+ both of these questions are "yes".
+
+ 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. Security Considerations
+
+ Since mobility means that the location of a mobile may change at any
+ time, how to secure such dynamic location updates is a very important
+ consideration for all mobility support solutions. However, this
+ document examines a wide range of solution proposals, so the security
+ aspects also vary greatly. For example, Home-Agent-based solutions
+ call for secure communications between the mobile and its Home
+ Agent(s). On the other hand, for routing-based solutions, such as
+ Connexion, the issue becomes one of global-routing security.
+ Similarly, for those solutions that use DNS to provide mapping
+ between Identifiers and Locators, the issue is essentially converted
+ to how to secure DNS dynamic updates as well as queries. To keep
+ this survey document both comprehensive as well as reasonably sized,
+ we chose to focus the survey on describing and comparing the
+ solutions to the center piece of all mobility supports -- the
+ resolution between Identifiers and Locators.
+
+8. Informative References
+
+ [ALM-SIP] Schulzrinne, H. and E. Wedlund, "Application-Layer
+ Mobility Using SIP", Mobile Computing and Communications
+ Review, 2010.
+
+
+
+
+Zhu, et al. Informational [Page 30]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ [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.
+
+ [Columbia] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-based
+ Protocols for Mobile Internetworking", ACM SIGCOMM CCR,
+ 1991.
+
+ [E2E] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach
+ to Host Mobility", ACM Mobicom, 2000.
+
+ [GTP] "GPRS Tunneling Protocol Across Gn and Gp Interface", 3G
+ TS 29.060 v3.5.0.
+
+ [HAHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
+ Agents Towards Internet-scale Mobility Deployment",
+ ACM CoNEXT, 2006.
+
+ [HAWAII] Ramjee, R., Varadhan, K., and L. Salgarelli, "HAWAII: A
+ Domain-based Approach for Supporting Mobility in Wide-area
+ Wireless Networks", IEEE/ACM Transcations on Networking,
+ 2002.
+
+ [ILNP] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for
+ Unifying Mobility with Multi-Homing, NAT, and Security",
+ MobiWAC 2007.
+
+ [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
+ "Locator/ID Separation Protocol (LISP)", Work in Progress,
+ March 2009.
+
+ [LISP-Mobility]
+ Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
+ Mobile Node", Work in Progress, May 2011.
+
+ [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 Implementation of An End-to-End Mobility
+ Concept", 5th Intl. Workshop on the Internet Challenge,
+ 2002.
+
+
+
+
+
+
+Zhu, et al. Informational [Page 31]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ [MSM-IP] Mysore, J. and V. Bharghavan, "A New Multicast-based
+ Architecture for Internet Host Mobility", ACM Mobicom,
+ 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
+ August 2002.
+
+ [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
+ RFC 3753, June 2004.
+
+ [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+ in IPv6", RFC 3775, June 2004.
+
+ [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
+ Thubert, "Network Mobility (NEMO) Basic Support Protocol",
+ RFC 3963, January 2005.
+
+ [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, October 2005.
+
+ [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
+ (MOBIKE)", RFC 4555, June 2006.
+
+ [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of
+ Enhancements to Mobile IPv6 Route Optimization", RFC 4651,
+ February 2007.
+
+ [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
+ "Host Identity Protocol", RFC 5201, April 2008.
+
+ [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
+ and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
+
+ [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
+ Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
+ Management", RFC 5380, October 2008.
+
+ [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile
+ IPv4", RFC 5454, March 2009.
+
+ [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
+ July 2009.
+
+
+
+
+
+Zhu, et al. Informational [Page 32]
+
+RFC 6301 Mobility Survey July 2011
+
+
+ [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
+ RFC 5944, November 2010.
+
+ [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
+ "Understanding Apple's Back to My Mac (BTMM) Service", RFC
+ 6281, June 2011.
+
+ [TIMIP] Grilo, A., Estrela, P., and M. Nunes, "Terminal
+ Independent Mobility For IP (TIMIP)", IEEE Communications
+ Magazine, 2001.
+
+ [VIP] Teraoka, F., Yokote, Y., and M. Tokoro, "A Network
+ Architecture Providing Host Migration Transparency",
+ ACM SIGCOMM CCR, 1991.
+
+ [WINMO] Hu, X., Li, L., Mao, Z., and Y. Yang, "Wide-Area IP
+ Network Mobility", IEEE INFOCOM, 2008.
+
+Authors' Addresses
+
+ Zhenkai Zhu
+ UCLA
+ 4805 Boelter Hall, UCLA
+ Los Angeles, CA 90095
+ USA
+
+ Phone: +1 310 993 7128
+ EMail: zhenkai@cs.ucla.edu
+
+
+ Ryuji Wakikawa
+ Toyota ITC
+ 465 Bernardo Avenue
+ Mountain View, CA 94043
+ USA
+
+ EMail: ryuji.wakikawa@gmail.com
+
+
+ Lixia Zhang
+ UCLA
+ 3713 Boelter Hall, UCLA
+ Los Angeles, CA 90095
+ USA
+
+ Phone: +1 310 825 2695
+ EMail: lixia@cs.ucla.edu
+
+
+
+
+Zhu, et al. Informational [Page 33]
+