diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6301.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6301.txt')
| -rw-r--r-- | doc/rfc/rfc6301.txt | 1851 |
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] + |