idnits 2.17.1 draft-zhu-mobility-survey-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2011) is 4784 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'M' is mentioned on line 800, but not defined == Missing Reference: 'H' is mentioned on line 800, but not defined == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-04 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Zhu 3 Internet-Draft UCLA 4 Intended status: Informational R. Wakikawa 5 Expires: September 22, 2011 TOYOTA ITC 6 L. Zhang 7 UCLA 8 March 21, 2011 10 A Survey of Mobility Support In the Internet 11 draft-zhu-mobility-survey-04.txt 13 Abstract 15 Over the last two decades many efforts have been devoted to 16 developing solutions for mobility support over the global Internet, 17 which resulted in a variety of proposed solutions. We conducted a 18 systematic survey of the previous efforts to gain an overall 19 understanding on the solution space of mobility support. This 20 document reports our findings and identifies remaining issues in 21 providing ubiquitous and efficient global scale Internet mobility 22 support. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 22, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Basic Components in Mobility Support Protocols . . . . . . . . 4 61 4. Existing Mobility Support Protocols . . . . . . . . . . . . . 5 62 4.1. Columbia Protocol . . . . . . . . . . . . . . . . . . . . 6 63 4.2. VIP Protocol . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. LSR Protocol . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.4. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.5. Hierarchical Mobile IP (HMIP) . . . . . . . . . . . . . . 12 67 4.6. Fast Handover for Mobile IPv6 (FMIP) . . . . . . . . . . . 12 68 4.7. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.8. MSM-IP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.9. Cellular IP, HAWAII and TIMIP . . . . . . . . . . . . . . 14 71 4.10. E2E and M-SCTP . . . . . . . . . . . . . . . . . . . . . . 15 72 4.11. Host Identity Protocol . . . . . . . . . . . . . . . . . . 15 73 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE) . . . . . 16 74 4.13. Connexion and WINMO . . . . . . . . . . . . . . . . . . . 16 75 4.14. ILNPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 4.15. Global HAHA . . . . . . . . . . . . . . . . . . . . . . . 18 77 4.16. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 19 78 4.17. Back to My Mac . . . . . . . . . . . . . . . . . . . . . . 20 79 4.18. LISP-Mobility . . . . . . . . . . . . . . . . . . . . . . 21 80 5. Different Directions towards Mobility Support . . . . . . . . 21 81 5.1. Routing-based Approach v.s. Mapping-based Approach . . . . 22 82 5.2. Mobility-aware Entities . . . . . . . . . . . . . . . . . 23 83 5.3. Operator-Controlled Approach v.s. User-controlled . . . . 24 84 5.4. Local and Global Scale Mobility . . . . . . . . . . . . . 25 85 5.5. Other Mobility Support Efforts . . . . . . . . . . . . . . 26 86 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 6.1. Deployment Issues . . . . . . . . . . . . . . . . . . . . 27 88 6.2. Session Continuity and Simultaneous Movements . . . . . . 28 89 6.3. Trade-offs of Design Choices on Mobility-awareness . . . . 29 90 6.4. Interconnecting Heterogeneous Mobility Support Systems . . 30 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 93 9. Informative References . . . . . . . . . . . . . . . . . . . . 31 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 96 1. Introduction 98 This document reports our findings from a historical survey of the 99 Internet mobility research and standardization efforts since the 100 early '90s. Our survey was motivated by two factors. First, 101 supporting mobility over the Internet has been an active research 102 area and has produced a variety of solutions; some of which have 103 become the Internet standards. Yet new issues continue to arise and 104 new solutions continue to be developed to address them, making one 105 wonder how much more we are yet to discover about the problem space 106 as well as the solution space. The second factor is the rapid growth 107 in Internet access via mobile devices in recent years, which will 108 inevitably lead to new Internet application development in the coming 109 years and further underscore the importance of Internet mobility 110 support. We believe that a historical review of all the proposed 111 solutions on the table can help us not only identify their 112 commonalities and differences, but also clarify remaining issues and 113 shed insight on future efforts. 115 In the rest of this document, we provide an overview of the mobility 116 support solutions from the early results to the most recent 117 proposals. In the process we also discuss the essential components 118 in mobility support, analyze the design space. Through sharing our 119 understanding of the current stage of the art, we aim to initiate an 120 open discussion about the general direction for future mobility 121 support. 123 Note that the solutions discussed in this document are proposed 124 designs. They have in many cases been implemented, but only a few 125 have been widely deployed in the Internet. 127 2. Terminology 129 This document uses the following terms to refer to the entities or 130 functions that are required in mobility support. Readers are 131 expected to be familiar with RFC 3753 "Mobility Related Terminology" 132 [RFC 3753] before reading this document. 134 Identifier: A stable value that can be used to identify a mobile 135 node. Any unique value can be used as an identifier as long 136 as it is topologically and geographically independent, i.e. 137 remains unchanged when the mobile node roams around. 139 Locator: The IP address that indicates the mobile node's current 140 attachment point to the Internet. It could be the IP address 141 of the mobile node itself, or the IP address of the network 142 entity that is currently serving the mobile node. 144 Mapping: In this document, mapping specifically means the mapping 145 between a mobile's identifier and its Locator. 147 Rendezvous Point (RP): The place where the mapping is held. Some 148 other functions such as data forwarding may also be co- 149 located on the rendezvous point. 151 Global Mobility Management: A system that keeps track each mobile's 152 reachability during the mobile's moving, either 153 geographically or topologically, in a global scale. 155 Local Mobility Management: A system that keeps track each mobile's 156 reachability within a topologically scoped local domain. It 157 keeps the mobile's local movements transparent to all 158 entities that are outside of the local scope. 160 Operator Controlled Mobility Management: The mobile node itself is 161 unaware of mobility management. Instead, certain network 162 entities, which are controlled by the network operators, 163 perform all the mobility related signaling job on behalf of 164 the mobile node. 166 User Controlled Mobility Management: The mobile node participates in 167 the mobility management. Typically, the mobile updates its 168 reachability information after it changes locations and 169 refreshes its reachability at a user-defined frequency. 171 3. Basic Components in Mobility Support Protocols 173 The basic question in Internet mobility support is how to send data 174 to a moving receiver (a mobile in short; here we do not distinguish 175 between mobile nodes and mobile subnets). We call the host who sends 176 data to a mobile the Correspondent Node (CN). To send data to a 177 moving receiver M, the CN must have means to obtain M's latest IP 178 address (solution type-1), or be able to reach M using a piece of 179 stable information, where "stable" means that the information does 180 not change as the mobile moves (solution type-2). 182 Among the existing solutions, a few fall under type-1 and most of 183 them use DNS as the means to provide the CN with the mobile's most 184 current IP address information. The rest of the existing solutions 185 fall under type-2, which must provide the function to reach the 186 mobile's dynamically changing location by using that unchanged 187 identifier of the mobile known to the CN. We can summarize all the 188 mobility support solutions as essentially involving three basic 189 components: 191 o a stable identifier for a mobile; 192 o a locator, which is usually an IP address representing the 193 mobile's current location; and 194 o a mapping between the two. 196 We show in the next section that different mobility support designs 197 are merely different approaches to provide mapping between the 198 identifiers and the mobiles' current IP addresses. In type-1 199 solutions, the stable identifier of a mobile is its DNS name, the 200 locator is its current IP address, and the DNS server provides the 201 mapping function. In type-2 solutions, because the CN must be able 202 to reach the mobile using the stable identifier, the identifier 203 itself is typically an IP address; either the network can dynamically 204 find a path to reach the mobile, or the IP address leads to the 205 "home" of the mobile which knows the mobile's current locator, thus 206 can forward the CN's packets to the mobile. All the type-2 solutions 207 face two common issues. One issue is how to carry out this 208 forwarding task, given the original packet sent by the CN has the 209 mobile's "home address" as the destination; the other issue is how to 210 avoid triangle routing between CN, the home location and the mobile. 212 4. Existing Mobility Support Protocols 214 In this section, we review the existing mobility support protocols 215 roughly in the time order, with a few exceptions where we grouped 216 closely related protocols together for writing clarity. We briefly 217 describe each design and point out how it implements the three basic 218 mobility support components defined in the last section. 220 Figure 1 shows a list of mobility support protocols and the time they 221 were first proposed. 223 +----------------+-----+---------------+-----+ 224 | Protocol Name |Year | Protocol Name |Year | 225 +----------------+-----+---------------+-----+ 226 | Columbia |1991 | TIMIP |2001 | 227 +----------------+-----+---------------+-----+ 228 | VIP |1991 | M-SCTP |2002 | 229 +----------------+-----+---------------+-----+ 230 | LSR |1993 | HIP |2003 | 231 +----------------+-----+---------------+-----+ 232 | Mobile IP |1996 | MOBIKE |2003 | 233 +----------------+-----+---------------+-----+ 234 | MSM-IP |1997 | Connexion |2004 | 235 +----------------+-----+---------------+-----+ 236 | Cellular IP |1998 | ILNPv6 |2005 | 237 +----------------+-----+---------------+-----+ 238 | HMIP |1998 | Global HAHA |2006 | 239 +----------------+-----+---------------+-----+ 240 | FMIP |1998 | PMIP |2006 | 241 +----------------+-----+---------------+-----+ 242 | HAWAII |1999 | BTMM |2007 | 243 +----------------+-----+---------------+-----+ 244 | NEMO |2000 | WINMO |2008 | 245 +----------------+-----+---------------+-----+ 246 | E2E |2000 | LISP-Mobility |2009 | 247 +----------------+-----+---------------+-----+ 249 Figure 1: A time table of mobility protocol development 251 4.1. Columbia Protocol 253 This protocol [Columbia] was originally designed to provide mobility 254 support on a campus. A router called Mobile Support Station (MSS) is 255 set up in each wireless cell, which serves as the default access 256 router for all mobile nodes in that cell. The identifier for a 257 mobile node is an IP address derived from a special IP prefix, and 258 the mobile node uses this IP address regardless of to which cell it 259 belongs. 261 Each MSS keeps a tracking list of mobile nodes that are currently in 262 its cell by periodically broadcasting beacons. The mobile replies 263 the MSS with a message containing its stable identifier and its 264 previous MSS when it receives the beacon from a new MSS. The new MSS 265 is responsible to notify the old MSS that a mobile has left its cell. 266 Each MSS also knows how to reach other MSSes (e.g. all MSSes could be 267 in one multicast group, or a list of IP addresses of all MSSes could 268 be statically configured for each MSS). 270 When a CN sends a packet to a mobile node, the packet goes to the 271 nearest MSS (MC), which either has the mobile node in the same cell 272 and can deliver directly, or otherwise broadcast a query to all other 273 MSSes and gets a reply from the MSS (MM) with the mobile node. If it 274 is the latter case, MC tunnels the packet to MM, which will finally 275 deliver the packet to the mobile node. 277 Hence, in this scheme, CN uses the identifier to reach the mobile. 278 It largely avoids triangle routing because the router next to CN is 279 mobility-aware and can intercept CN's data destined to the mobile and 280 forward to destination MSS. Since a mobile keeps the same IP address 281 independent from its movement, mobility does not affect TCP 282 connections. 284 An illustration of Columbia Approach is shown in Figure 2. 286 +---------+ 287 | | 288 .------>| MSS | 289 | | | 290 | +---------+ 291 | query 292 | 293 +--------+ query +--------+ 294 | | -------------->| | 295 | MSS | <------------- | MSS | 296 | | reply | | 297 +--------+ ==============>+--------+ 298 /\ data || 299 || || 300 || \/ 301 +--------+ +---------+ 302 | | | | 303 | CN | | MN | 304 | | | | 305 +--------+ +---------+ 307 ===>: data packets 308 --->: signaling packets 310 Figure 2: Columbia Protocol 312 4.2. VIP Protocol 314 This design [VIP] has two basic ideas. First, a packet carries both 315 identifier and locator; second, the identifier is an IP address that 316 leads to the home network where the mapping is kept. 318 The IP header is modified to allow packets sent by a mobile to carry 319 two IP addresses: a Virtual IP address (identifier) and a regular IP 320 address (locator). Every time the mobile node changes its location, 321 it notifies the home network with its latest IP address. A mobile's 322 virtual address never changes, and can be used to support TCP 323 connections independent of mobility. 325 To deliver data to a mobile, the CN first uses the mobile's Virtual 326 IP address as the destination IP address, i.e. the locator is set to 327 be the same as the identifier. As a result, the packet goes to the 328 home network and the home agent redirects the packet to mobile's 329 current location by replacing the regular IP destination address 330 field with the mobile's current address. 332 To reduce triangle routing, the design lets CNs and routers learn and 333 cache the identifier-locator mapping carried in the packets from 334 mobile nodes. When a CN receives a packet from the mobile, it learns 335 the mobile's current location from the regular IP source address 336 field. The CN keeps the mapping and uses the locator as the 337 destination in future exchanges with the mobile. Similarly, if a 338 router along the data path to a mobile finds out that the mapping 339 carried in the packet differs from the mapping cached by the router, 340 it changes the destination IP address field to its cached value. 341 This router caching solution is expected to increase the chance that 342 packets destined to the mobile get forwarded to the mobile's current 343 location directly, by paying a cost of having all routers examine and 344 cache all the mobiles identifier-locator mappings. 346 Figure 3 shows how VIP protocol works. 348 ,---. +-------+ 349 / \ | CN | 350 ( Router)<====| | 351 +---------+ // \ / | | 352 | | // `---' +-------+ 353 | | ,---. // 354 | | / \ // 355 | Home |<--+ Router) 356 | Network | \ / 357 | | `-+-'\\ 358 | | | \\ ,---. +-------+ 359 | | | \\ / \=======>| | 360 | | +------( Router)<------+ MN | 361 | | \ / | | 362 | | `---' +-------+ 363 +---------+ 365 ===>: data packet 366 --->: location update message 368 Figure 3: VIP Protocol 370 4.3. LSR Protocol 372 In Loose Source Routing (LSR) protocol [LSR], each mobile has a 373 designated router, called Mobile Router, that manages its mobility. 374 Mobile Router assigns an IP address (used as an identifier) for each 375 mobile it manages and announces reachability to those IP addresses. 376 Another network entity in the LSR design is Mobile Access Station 377 (MAS), through which a mobile gets its connectivity to the Internet. 378 The mobile node reports the IP address of its current serving MAS 379 (locator) to its Mobile Router. 381 The CN uses the identifier to reach the mobile node in the first 382 place. If the CN and the mobile node are attached to the same MAS, 383 the MAS simply forwards packets between the two (in this case CN is 384 also mobile); otherwise, the packet from CN is routed to the Mobile 385 Router of the mobile. The Mobile Router looks up the mappings to 386 find the serving MAS of the mobile node, and inserts the loose source 387 routing (LSR) option into the IP header of the packet with the IP 388 address of the MAS on it. In this way, the packet is redirected to 389 the MAS which then delivers the packet to the mobile. To this point, 390 the locator of the mobile node is already included in the LSR option, 391 and the two parties can communicate directly by reversing the LSR 392 option in the incoming packet. Hence, the path for the first packet 393 from CN to the mobile is: CN->Mobile Router->MAS->mobile node; and 394 then the bi-directional path for the following packets is: mobile 395 node<->MAS<->CN. 397 The triangle routing is avoided by revealing the mobile's locator to 398 the CN in the LSR option. 400 Figure 4 shows the basic operation of LSR protocol. 402 +---------+ 403 | | 404 ___________________| CN | 405 | | | 406 | +---------+ 407 V /\ 408 +-------+ || 409 |Mobile | || 410 |Router | || 411 | | || Reversing LSR 412 +---+---+ || 413 | \/ 414 | +---------+ +----------+ 415 | LSR Inserted | |<====>| | 416 +------------------->| MAS | | MN | 417 | |----->| | 418 +---------+ +----------+ 420 -->: first data packet 421 ==>: following data packets 423 Figure 4: LSR Protocol 425 4.4. Mobile IP 427 IETF begun standard development in mobility support soon after the 428 above three protocols. The first version of Mobile IP standard was 429 developed in 1996. Later, IETF further made Mobile IPv4 [RFC 3344] 430 and Mobile IPv6 [RFC 3775] standards in 2002 and 2004, respectively. 431 In 2009, Dual-Stack Mobile IPv4 [RFC 5454] was standardized to allow 432 a dual-stack node to use IPv4 and IPv6 home addresses and to move 433 between IPv4 and dual stack network infrastructures. 435 Although the three documents differs in details, the high-level 436 design is similar. Here we use Mobile IPv6 as an example. Each 437 mobile node has a Home Agent, from which it acquires its Home Address 438 (HoA), the identifier. The mobile node also obtains its locator, a 439 Care-of Address (CoA) from its current access router. Whenever the 440 mobile node gets a new CoA, it sends a Binding Update message to 441 notify the Home Agent. Conceptually Mobile IPv6 design looks similar 442 to VIP Protocol, with the mobile's HoA corresponding to the Virtual 443 IP Address in VIP, and the CoA corresponding to the regular IP 444 address. 446 The CN uses the mobile's HoA as the destination IP address when 447 sending data to a mobile. The packets are forwarded to the Home 448 Agent , which then encapsulates the packets to mobile node's CoA 449 according to the mapping. 451 To alleviate triangle routing, the CN, if supports Route 452 Optimization, also keeps the mapping between the mobile's HoA and 453 CoA. Thus the CN can encapsulate packets to the mobile directly, 454 without going through the Home Agent. Note that in this case, the 455 mobile needs to update its CoA to CNs as well. 457 Figure 5 illustrates the data path of Mobile IPv6 without Route 458 Optimization. 460 +---+-----+ 461 |HoA|DATA | 462 +---+-----+ +-------+ 463 +----------------------| CN | 464 | +------------------->| | 465 | | +-------+ 466 | | 467 V | 468 +--------+ 469 | Home | Mapping: HoA <=> CoA 470 | Agent | 471 | | 472 +--------+ 473 || /\ 474 || || +-------+ 475 || +====================| | 476 || | MN | 477 +=======================>| | 478 +-----+---+---+ +-------+ 479 |DATA |HoA|CoA| 480 +-----+---+---+ 482 ==>: Tunnel 483 -->: regular IP 485 Figure 5: Mobile IPv6 without Route Optimization 487 4.5. Hierarchical Mobile IP (HMIP) 489 HMIP [RFC 5380] is a simple extension to Mobile IP. It aims to 490 improves the performance of Mobile IP by handling mobility within a 491 local region locally. A level of hierarchy is added to Mobile IP in 492 the following way. A Mobility Anchor Point (MAP) is responsible for 493 handling the movements of a mobile in a local region. Simply 494 speaking, MAP is the local Home Agent for the mobile node. The 495 mobile node, if it supports HMIP, obtains a Regional CoA (RCoA) and 496 registers it with its Home Agent as its current CoA; while RCoA is 497 the locator for the mobile in Mobile IP, it is also its regional 498 identifier used in HMIP. At the same time, the mobile obtains a 499 Local CoA (LCoA) from the subnet it attaches to. When roaming with 500 the region, a mobile only updates the MAP with the mapping between 501 its RCoA and LCoA. In this way, the handoff performance is usually 502 better due to the shorter round-trip time between the mobile and the 503 MAP, as compared to the delay between the mobile and its HA. It also 504 reduces the burden of the Home Agents by reducing the frequency of 505 sending updates to Home Agents. 507 4.6. Fast Handover for Mobile IPv6 (FMIP) 509 FMIP [RFC 5568] is another extension to Mobile IP, which reduces the 510 Binding Update latency as well as the IP connectivity latency. It is 511 not a fully fledged mobility support protocol; rather, its only 512 purpose is to optimize the performance of Mobile IP. 514 This goal is achieved by three mechanisms. First, it enables a 515 mobile node to detect that it has moved to a new subnet while it is 516 still connected to the current subnet, by providing the new access 517 point and the corresponding subnet prefix information. Second, 518 mobile node can also formulate a prospective new care-of address 519 (NCoA) when it is still present on the previous link, so that this 520 address can be used immediately after it attaches to the new subnet 521 link. Third, to reduce the Binding Update interruption, FMIP 522 specifies a tunnel between the previous care-of address (PCoA) and 523 the NCoA. The mobile node send a Fast Binding Update to the previous 524 access router (PAR) after the handoff and PAR begins to tunnel 525 packets for PCoA to NCoA. These packets would have been dropped if 526 the tunnel were not established. In the reverse direction, the 527 mobile node also tunnels packets to PAR until it finishes the Binding 528 Update process (mobile node can only use PCoA now because the binding 529 in HA or the correspondent nodes may have not been updated yet). 531 4.7. NEMO 533 It is conceivable to have a group of hosts moving together. Consider 534 vehicles such as ships, trains, or airplanes which may host a network 535 with multiple hosts attached to. Because Mobile IP handles mobility 536 per host, it is not efficient when handling such mobility scenarios. 537 NEMO [RFC 3963], as a backward compatible extension to Mobile IP, was 538 introduced in 2000 to provide efficient support for network mobility. 540 NEMO introduces a new entity call Mobile Router (note that this is 541 different from the "Mobile Router" in LSR protocol). Every mobile 542 network has at least one Mobile Router. Mobile Router is similar to 543 a mobile node in Mobile IP, but instead of having a single HoA, it 544 has one or more IP prefixes as the identifier. After establishing 545 bidirectional tunnel with Home Agent, the Mobile Router distributes 546 its mobile network's prefixes (namely Mobile Prefixes) through the 547 tunnel to Home Agent. The Mobile Prefix of a mobile network is not 548 leaked to its access router (i.e. the access router never knows that 549 it can reach the Mobile Prefixes via the Mobile Router). The Home 550 Agent in turn announces the reachability to the Mobile Prefix. 551 Packets to and from mobile network flow through the bidirectional 552 tunnel between the Mobile Router and the Home Agent to their 553 destinations. Note that mobility is transparent to the nodes in the 554 moving network. 556 4.8. MSM-IP 558 MSM-IP [MSM-IP] stands for Mobility Support using Multicast in IP. 559 As one can see from its name, MSM-IP leverages IP multicast routing 560 for mobility support. In IP multicast, a host can join a group 561 regardless of to which network it attaches and receive packets sent 562 to the group after its join. Thus mobility is naturally supported in 563 the domains where IP multicast is deployed . Note that MSM-IP does 564 not address the issue of feasibility of supporting mobility through 565 IP multicast, but rather it simply shows the possibility of using IP 566 multicast to provide mobility support, once/if IP multicast is 567 universally deployed. 569 MSM-IP [MSM-IP] assigns each mobile node a unique multicast IP 570 address as the identifier. When the mobile node moves into a new 571 network, it initiates a join to its own address, which makes the 572 multicast router in that subnet join the multicast distribution tree. 573 Whoever wants to communicate with the mobile node can just send the 574 data to the mobile's multicast IP address, and the multicast routing 575 will take care of the rest. 577 Note that, due to the nature of multicast routing, the mobile node 578 can have the new multicast router join the group to cache packets in 579 advance before it detaches the old one, resulting in smoother 580 handoff. 582 4.9. Cellular IP, HAWAII and TIMIP 584 This is a group of protocols that share the common idea of setting up 585 host route for each mobile in the local domain. The mobile retains 586 an stable IP address as long as it is within the local domain, and 587 this IP address is used as a regional identifier. The gateway router 588 of the local domain will use this identifier to reach the mobile 589 node. All three protocols are intended to work with Mobile IP as a 590 local mobility management protocol. By describing them together we 591 can more easily to show the differences by comparison. 593 Cellular IP [CIP] handles the local mobility in a network consists of 594 Cellular IP routers. A mobile reports the IP address of the gateway 595 for the local network as the RCoA to its Home Agent, and retains its 596 locally assigned IP address (the regional identifier) when it roams 597 within the Cellular IP network. The routers in the network monitors 598 the packets originated from mobile nodes and maintains a distributed, 599 hop-by-hop reverse path for each mobile node. It utilizes paging 600 technique from cellular network to track the location of each mobile: 601 idle mobile nodes send dummy packets to the gateway router with a 602 relatively low frequency to update their reverse paths in the 603 routers. The out-dated path will not be cleared explicitly after the 604 mobile changes its location; instead, it would be flushed by the 605 routers if the paging timer expires before next dummy packet comes. 606 To reduce the paging cost, only a subset of the routers would set up 607 reverse path for the idle mobile nodes. 609 When a packet from the CN arrives at the gateway, the gateway 610 initiates a controlled flooding query: if a router knows where to 611 forward a packet, forward it immediately; otherwise, it forwards the 612 packet to all its interfaces except the one from which the packet 613 comes. Due to the paging technique, this will not become a 614 broadcast. Once the mobile receives the query, it replies a route- 615 update message to the gateway, and a much more precise reverse path 616 is then maintained by the all routers along the data path, via which 617 the gateway router forwards packets from CN to the mobile. Note that 618 the timer value for the precise data path is much more smaller than 619 the paging timer value, in order to avoid sending duplicate data 620 packets to multiple places if the mobile moves during the data 621 communication. 623 Similarly, HAWAII [HAWAII] also aims to provide efficient local 624 mobility support. Unlike Cellular IP, the route between the gateway 625 router and the mobile is always maintained. When the mobile moves, 626 HAWAII dynamically modifies route to the mobile by installing host- 627 based forwarding entry on the routers located along the shortest path 628 between the old and new base stations of the mobile. It is possible 629 that longer suboptimal routing path will be constructed (e.g. gateway 630 router->old base station->new base station->mobile). Alternatively, 631 a new sub-path between the mobile and the cross-over router can be 632 established. Here, the cross-over router is the router at the 633 intersection of two paths, one between the gateway and the old base 634 station, and the second between the old base station and the new base 635 station. In HAWAII, the mobile only periodically send refresh 636 messages to the base station, and the base station along with other 637 routers would take care of the path maintenance. 639 TIMIP [TIMIP], which stands for Terminal Independent Mobile IP, 640 integrated together the design of Cellular IP and HAWAII. On one 641 hand, it refreshes the routing paths with dummy packets if the mobile 642 node is idle. On the other hand, handoff within a domain results in 643 the changes of routing tables in the routers. Besides, the IP layer 644 is coupled with layer 2 handoff mechanisms and special nodes can work 645 as Mobile IP proxies for legacy mobiles that do not support Mobile 646 IP. Thus, as long as the mobile roams within the domain, the legacy 647 node has the same degree of mobility support as a Mobile IP capable 648 node. 650 4.10. E2E and M-SCTP 652 E2E (End-to-End communication) [E2E] gets the name from its end-to- 653 end architecture, and is the first proposal that utilizes existing 654 DNS service to track mobile node's current location. The stable 655 identifier here is the domain name of the mobile. The mobile uses 656 Dynamic DNS update to update its current IP address in DNS servers. 657 To keep the ongoing TCP connection unaffected by mobility, a TCP 658 Migrate option is introduced to allow both ends to replace the IP 659 addresses and ports in TCP 4-tuple on the fly. Thus, the CN can 660 query DNS to obtain the current locator of the mobile, and after the 661 TCP connection is established, the mobile will be responsible for 662 update its locator for this session. 664 Inspired by E2E, M-SCTP [M-SCTP] was proposed in 2002. Similarly, it 665 uses Dynamic DNS to track the mobile nodes and allows both ends to 666 add/delete IP addresses used in SCTP associations during the move. 668 4.11. Host Identity Protocol 670 Host Identify Protocol (HIP) [RFC 5201] assigns to each host an 671 identifier made of cryptographic keys, and adds a new Host Identity 672 layer between transport and network layers. Host Identities, which 673 are essentially public keys, are used to identify the mobile nodes, 674 and IP addresses are used only for routing purpose. In order to 675 reuse the existing code, Host Identity Tag (HIT), which is a 128-bit 676 hash value of the Host Identity, is used in transport and other upper 677 layer protocols. 679 HIP can use DNS as the rendezvous point which holds the mappings 680 between HITs and IP addresses. However, HIP by default uses its own 681 static infrastructure Rendezvous Servers, in expectation of better 682 rendezvous service. Each mobile node has a designated Rendezvous 683 Server (RVS), which tracks the current location of mobile node. When 684 a CN wants to communicate with mobile node, it queries DNS with 685 mobile node's HIT to obtain the IP address of mobile node's RVS, and 686 sends out the first packet. After receiving this first packet, RVS 687 relays it to mobile node. Then mobile node and correspondent node 688 can start communication on the direct path. If the mobile node moves 689 to a new address, it notifies CN by sending HIP UPDATE with LOCATOR 690 parameter indicating its new IP address (locator). Meanwhile, it 691 also updates the mapping in RVS. 693 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE) 695 MOBIKE [RFC 4555] is an extension to Internet Key Exchange (IKEv2) to 696 support mobility and multihoming. The main purpose of MOBIKE is to 697 allow roaming devices to keep the existing IKE and IPsec SAs despite 698 of IP address changes. The mobility support in MOBIKE allows both 699 parties to move, but it does not provide a rendezvous mechanism. In 700 other words, simultaneous movement of both parties is not supported. 702 MOBIKE allows both parties to have a set of addresses, and the party 703 that initiated the IKE_SA is responsible for deciding which pair of 704 addresses to use. During the communication session, if the initiator 705 wishes to change the addresses due to movement, it updates the IKE_SA 706 with new IP addresses, and also updates the IPsec SAs associated with 707 this IKE_SA. Then it sends an INFORMATIONAL request containing the 708 UPDATE_SA_ADDRESSES notification to the other party. The responder 709 then checks the local policy and updates the IP addresses in the 710 IKE_SA with the values from the IP header. It replies the initiator 711 with an INFORMATIONAL response, initiates a return routability check 712 if it wants to, and updates the IPsec SAs associated with this 713 IKE_SA. 715 MOBIKE is not a fully fledged mobility protocol, and it does not 716 intend to be one. Nevertheless, through the use of IPsec tunnel 717 mode, MOBIKE partially supports mobility as it can dynamically 718 updates the tunnel endpoint addresses. 720 4.13. Connexion and WINMO 722 Connexion [Boeing] was a mobility support service provided by Boeing 723 that uses BGP to support network mobility. Every mobile network is 724 assigned a /24 IP address prefix (stable identifier), and the CN uses 725 this identifier to reach the moving network, which means that the 726 global routing system is responsible for finding a path to the mobile 727 network. When an airplane moves between its access routers on 728 ground, it withdraws its prefix from the previously access router and 729 announces the prefix via the new access point. As a result, the 730 location change of the plane is effectively propagated to the rest of 731 the world. However, if the number of moving networks becomes large, 732 the amount of BGP updates will also increase proportionally, 733 resulting in severe global routing dynamics. 735 WINMO [WINMO] (which stands for Wide-Area IP Network Mobility) was 736 introduced in 2008 to address the routing update overhead problem of 737 Connexion. Like Connexion, WINMO also assigns each mobile network a 738 stable prefix. However, through two new approaches WINMO can reduce 739 the BGP updates overhead for mobile networks by orders of magnitude 740 lower than that of Connexion. First, WINMO uses various heuristics 741 to reduce the propagation scope of routing updates caused by mobile 742 movements. Consequently, not every router may know all the mobiles' 743 current locations. Handling this issue led to the second, and more 744 fundamental approach taken by WINMO: it adopts the basic idea from 745 Mobile IP by assigning each mobile network a "home" in the following 746 way. WINMO assigns each mobile network a prefix out of a small set 747 of well defined Mobile Prefixes. These Mobile Prefixes are announced 748 by a small set of Aggregation Routers which also keep track of the 749 mobile networks current locations. Therefore these Aggregation 750 Routers play a similar role to Home Agents in Mobile IP, and can be 751 counted on as last resort to reach mobile networks globally. 753 To prevent frequent iBGP routing updates due to the movement of 754 mobile networks within an AS, WINMO also introduces a Home Agent for 755 the Mobile Prefixes: only a Designated BGP-speaking Router (DBR) acts 756 as the origin of Mobile Prefixes; mobile networks always update the 757 addresses of their access routers (intra-AS locators) with DBR, which 758 resembles the binding updates in Mobile IP. Thus, packets destined 759 to mobile networks are forwarded to DBR after they enter the border 760 of an AS, and DBR will tunnel them to the current locations of mobile 761 networks. 763 A new BGP community attribute, which includes the mobile network's 764 intra-AS locator in each packet, is also defined to eliminate the 765 triangle routing problem caused by DBR. The border routers of the AS 766 can tunnel packets directly to the mobile network based on the new 767 attribute. 769 4.14. ILNPv6 771 ILNPv6 [ILNP] stands for Identifier-Locator Network Protocol for 772 IPv6. The ILNPv6 packet header are deliberately made similar to IPv6 773 header. Essentially, it breaks IPv6 address into two components: 774 high-order 64 bits as a Locator and low-order 64 bits as an 775 Identifier. The Identifier identifies a host, instead of an 776 interface, and is used in upper-layer protocols (e.g. TCP, FTP); on 777 the other hand, the Locator changes with the movement of the mobile 778 node, and a set of Locators can be associated with a single 779 Identifier. Several new DNS RRs are required, among which I 780 (Identifier Record) and L (Locator Record) are most important. As in 781 current Internet, the CN will query the DNS about the mobile's domain 782 name to determine where to send the packet. During the movement, the 783 mobile node uses Secure Dynamic DNS update to ensure that the Locator 784 values stored in DNS are up-to-date. It also sends Locator Update 785 messages to the CNs that are currently communicating with it. As an 786 optimization, ILNPv6 supports soft-handoff, which allows the use of 787 multiple Locators simultaneously to achieve smooth transition. 788 ILNPv6 also supports mobile networks. 790 4.15. Global HAHA 792 Global HAHA [HAHA], first proposed in 2006 as an extension to Mobile 793 IP, aims to eliminate the triangle routing problem in Mobile IP and 794 NEMO by distributing multiple Home Agents globally. All the Home 795 Agents join an IP anycast group and form an overlay network. The 796 same home prefix is announced by all the Home Agents from different 797 locations. Each mobile node can register with any Home Agent that is 798 closest to it. A Home Agent H that accepts the binding request of a 799 mobile node M becomes the primary Home Agent for M, and notifies all 800 other Home Agents of the binding [M, H], so that the binding 801 information databases for all the mobiles in all Home Agents are 802 always synchronized. When a mobile moves, it may switch its primary 803 Home Agent to another one that becomes closest to the mobile. 805 A correspondent node sends packets to a mobile's Home Address. 806 Because of anycast routing, the packets are delivered to the nearest 807 Home Agent. This Home Agent then encapsulates the packets to the IP 808 address of the primary Home Agent that is currently serving the 809 mobile node, which will finally deliver the packets to mobile node 810 after striping off the encapsulation headers. In the reverse 811 direction, this approach works exactly the same as Mobile IP. If the 812 Home Agents are distributed widely, the triangle routing problem is 813 naturally alleviated without Route Optimization. 815 The data flow in Global HAHA is shown in Figure 6. 817 +------+ +------+ +-----+ 818 | HA |-------------| HA | | | 819 | | | | | CN | 820 +--+---+ +------+++----+ +-----+ 821 | | || /\ 822 | | || || 823 | | || || 824 | | || || 825 +--+---+------+ || || 826 | |<==============+ || 827 | HA |==============================+ 828 +-++---+ 829 || /\ 830 \/ || 831 +---++-+ ===>: data flow 832 | | ----: HA overlay network 833 | MN | 834 +------+ 836 Figure 6 838 4.16. Proxy Mobile IP 840 Proxy Mobile IP [RFC 5213] was proposed in 2006 to meet the interest 841 of mobile network operators who desire to support mobility in a 842 network rather than at mobile devices and to have tighter control on 843 mobility support. Mobility is completely transparent to the mobile 844 devices and is provided to legacy IP devices. PMIP introduces two 845 new types of network nodes, Local Mobility Anchor (LMA) and Mobile 846 Access Gateway (MAG), which together can support mobility within an 847 operator's network without any action taken by the mobile node. LMA 848 serves as a local Home Agent and assigns a local Home Network Prefix 849 for each mobile node. This prefix is the identifier for the mobile 850 node within the PMIP domain. MAGs monitor the attaching and 851 detaching events of mobile node, and generates Proxy Binding Update 852 to LMA on behalf of mobile node during handoff. After the success of 853 binding, LMA updates mobile node's Proxy-CoA (locator in PMIP domain) 854 with the IP address of the MAG that is currently serving mobile node. 855 The MAG then emulates mobile node's local Home Link by advertising 856 mobile node's local Home Network Prefix in Router Advertisement. 857 When roaming in the PMIP domain, mobile node always obtains its local 858 Home Prefix, and believes that its on local Home Link. Within the 859 domain, the mobile node is reached by the identifier and LMA tunnels 860 packets to the mobile node according to the mapping. 862 4.17. Back to My Mac 864 Back to My Mac (BTMM) [BTMM] is an engineering approach to mobility 865 support and has been deployed since 2007 with Mac OS leopard release. 866 Each user gets a MobileMe account (which includes BTMM service), and 867 Apple Inc. provides DNS service for all BTMM users. The reachability 868 information of the user's machine is published in DNS. 870 A mobile uses secure DNS update to dynamically refresh its current 871 location. Each host generates an IPv6 ULA [RFC 4193] at boot time, 872 which is stored in the DNS database as its topologically independent 873 identifier. The host's current IPv4 address (which is the IPv4 874 address of the NAT box if the host is behind a NAT) is stored in a 875 SRV resource record [RFC 2782], together with a transport port number 876 needed for NAT traversal. Every node establishes long-lived query 877 (llq) session with the DNS server, so that the DNS server can 878 immediately notify each node when the answer to its query has 879 changed. A host uses its identifier in transport protocols and 880 applications, and uses UDP/IPv4 encapsulation to deliver data packets 881 using information learned from the SRV RR. Note that the locator 882 here is the IPv4 address plus the transport port number and that the 883 IPv6 address is only for identification purpose. In fact, it could 884 be any form of identifier (e.g. domain name); BTMM chose to IPv6 885 address so that its implementation can reuse existing code. 887 BTMM is currently used by millions of subscribers. It is simple and 888 easy to deploy. However, the current applications use BTMM service 889 in a "stop-and-reconnect" fashion. It remains to be seen how well 890 BTMM can support continuous communications while hosts are on the 891 move, for example as needed for voice calls. 893 Figure 7 shows the basic architecture of BTMM. 895 DDNS update +--------+ DDNS update 896 +--------------->| |<-------+ 897 | | DNS | | 898 | LLQ | | LLQ | 899 | +---------->| |<----+ | 900 | | | | | | 901 | | +--------+ | | 902 | | | | +---------+ 903 | V +---+--+----+ | | 904 ++-------+ | +-------| | 905 |Endhost1| Tunnel | NAT +------>|Endhost2 | 906 | |<=====================================>| | 907 +--------+ | | | | 908 +-----------+ +---------+ 910 Figure 7 912 4.18. LISP-Mobility 914 LISP-Mobility [LISP-Mobility] is a relatively new design. Its 915 designers hope to utilize functions and services provided by LISP 916 [LISP], which is designed for Internet routing scalability, to 917 support mobility as well. Conceptually, LISP-Mobility may seem 918 similar to some protocols we have mentioned so far, such as ILNPv6 919 and Mobile IP. Light-weight Ingress Tunnel Router and Egress Tunnel 920 Router functions are implemented on each mobile node, and all the 921 packets to and from the mobile node are processed by the two router 922 functions (so the mobile node looks like a LISP site). Each mobile 923 node is assigned a static Endpoint ID , as well as a pre-configured 924 Map-Server. When a mobile node roams into a network and obtains a 925 new Routing Locator, it updates its Routing Locator set in the Map- 926 Server, and it also clears the cached Routing Locator in the Ingress 927 Tunnel Routers or Proxy Tunnel Routers of the CNs. Thus the CN can 928 always learn the up-to-date location of the mobile node by the 929 resolution of the mobile node's Endpoint ID, either issued by itself 930 or issued after receiving the notification from the mobile node about 931 the staled cache. The data would always travel through the shortest 932 path. Note that both Endpoint IDs and Routing Locators are 933 essentially IP addresses. 935 5. Different Directions towards Mobility Support 937 After studying various existing protocols, we identified several 938 different directions for mobility support. 940 5.1. Routing-based Approach v.s. Mapping-based Approach 942 All existing mobility support designs can be broadly classified into 943 two basic approaches. The first one is to support mobility through 944 dynamic routing. In such designs, a mobile keeps its IP address 945 regardless of its location changes, thus the IP address can be used 946 both to identify the mobile and to deliver packets to it. As a 947 result, these designs do not need an explicit mapping function. 948 Rather, the routing system must continuously keep track of mobile's 949 movements and reflect their current positions in the network on the 950 routing table, so that at any given moment packets carrying the 951 (stable) receiver's IP address can be delivered to the right place. 953 It is also worthwhile to identify two sub-classes in routing-based 954 approaches. One is broadcast based, and the other is path based. 955 That is, in the former case, either the mobile's location information 956 is actively broadcasted to the whole network or a proactive broadcast 957 query is needed to obtain the location information of a mobile (e.g. 958 Columbia, Connexion); in the latter case, on the other hand, a host- 959 based path is maintained by the routing system instead (e.g. 960 Cellular IP, HAWAII, TIMIP). 962 Supporting mobility through dynamic routing is conceptually simple; 963 it can also provide robust and efficient data delivery, assuming that 964 the routing system can keep up with the mobile movements. However, 965 because either the whole network must be informed of every movement 966 by every mobile, or otherwise a host-based path must be maintain for 967 every mobile host, this approach is feasible only in small scale 968 networks with a small number of mobiles; it does not scale well in 969 large networks or for large number of mobiles. 971 The second approach to mobility support is to provide a mapping 972 between a mobile's stable identifier and its dynamically changing IP 973 address. Instead of notifying the world on every movement, a mobile 974 only needs to update a single binding location about its location 975 changes. In this approach, if one level of indirection at IP layer 976 is used, as in the case of Mobile IP, it has a potential side effect 977 of introducing triangle routing; otherwise, if the two end nodes are 978 aware of each other's movement, it means that both ends have to 979 support the same mobility protocol. 981 Yet there is the third case in which the protocols combine the above 982 approaches, in the hope of keeping the pros and eliminating some cons 983 of the two. WINMO is a typically protocol in this case. 985 In Figure 8 we show the classification of the existing protocols 986 according to the above analysis. 988 +---------------+-------------------------------------------+ 989 | | VIP, LSR, Mobile IP, HMIP, NEMO, E2E | 990 | Mapping-based | M-SCTP, ILNPv6, HIP, FMIP, PMIP, | 991 | | BTMM, GLOBAL HAHA, LISP-Mobility | 992 +---------------+-------------------------------------------+ 993 | | Columbia, Connexion | 994 | Routing-based +-------------------------------------------+ 995 | | Cellular IP, HAWAII, TIMIP, MSM-IP | 996 +---------------+-------------------------------------------+ 997 | Combination | WINMO | 998 +---------------+-------------------------------------------+ 1000 Figure 8 1002 5.2. Mobility-aware Entities 1004 Among the various design choices, a critical one is how many entities 1005 are assumed to be mobility-aware; stated in another way, the mobility 1006 is hidden from which parties. There are four parties that may be 1007 involved during a conversation with a mobile: the mobile itself, CN, 1008 the network, and Home Agent or its equivalent (additional component 1009 to the existing IP network that holds the mapping). We mainly focus 1010 our discussion on mapping-based approach here. 1012 The first design choice is to hide the mobility from the CN, based on 1013 the assumption that the CN may be the legacy node that does not 1014 support mobility. In this approach, the IP address which is used as 1015 the mobile's identifier points to the Home Agent or its equivalent 1016 that keeps track of the mobile's current location. If a 1017 correspondent node wants to send packets to a mobile node, it sets in 1018 the destination field of IP header an IP address which is a mobile's 1019 identifier. The packets will be delivered to the location where the 1020 mapping information of the mobile is kept, and later they will be 1021 forwarded to the mobile's current location via either encapsulation 1022 or destination address translation. Mobile IP and most of its 1023 extensions, as well as several other protocols fall into this design. 1025 The second design choice is to hide the mobility from the mobile and 1026 CN, which is based on a more conservative assumption that both the 1027 mobile and the CN do not support mobility. Protocols like PMIP and 1028 TIMIP adopt this design. The protocol operations in this design 1029 resemble those in the first category, but significant difference is 1030 that, here the mobility related signaling (e.g. update locator to the 1031 Home Agent) is handled by the entities in the network, rather than 1032 the mobile itself. Hence the mobile blissfully assumes that it is 1033 always in the same subnet. 1035 The third one is to let both mobile and the CN to be mobility-aware. 1036 As a result, the network is not aware of the mobility and no 1037 additional component is required. As increasing number of mobile 1038 devices are connected to Internet (why hide mobility to them), this 1039 design choice seems to be more and more appealing. One common 1040 approach taken by this design is to use DNS to keep track of mobiles' 1041 current locations. Mobiles use dynamic DNS updates to keep their DNS 1042 servers updated with their current locations. This approach re- 1043 utilizes the DNS infrastructure, which is ubiquitous and quite 1044 reliable, and makes the mobility support protocol simple and easy to 1045 deploy. Protocols like E2E, ILNP and BTMM fail into this design. 1046 Although HIP adds special purpose rendezvous servers to the network 1047 to replace the role of DNS, both mobile and CN are still mobility- 1048 aware, and hence it is also classified in this category. 1050 Figure 9 shows the three categories of protocols. 1052 +-------------+----------------------------------+ 1053 | Design 1 | VIP, LSR, Mobile IP, HMIP, NEMO | 1054 | | Global HAHA | 1055 +-------------+----------------------------------+ 1056 | Design 2 | PMIP, TIMIP | 1057 +-------------+----------------------------------+ 1058 | Design 3 | E2E, M-SCTP, ILNPv6, HIP, | 1059 | | BTMM, LISP-Mobility | 1060 +-------------+----------------------------------+ 1062 Figure 9 1064 5.3. Operator-Controlled Approach v.s. User-controlled 1066 At the time of this writing, cellular networks are providing the 1067 largest operational global mobility support, using a service model 1068 that bundles together the device control, network access control and 1069 mobility support. The tremendous success of cellular market speaks 1070 loudly that the current cellular service model is a viable one, and 1071 is likely to continue into foreseeable future. Consequently, there 1072 is a strong advocate in IETF that we continue the cellular way of 1073 handling mobility, i.e. instead of letting mobile devices participate 1074 in the mobility related signaling themselves, the network entities 1075 deployed by the operators should take care of any and all signaling 1076 process of mobility support. A typical example along this direction 1077 is Proxy Mobile IP, in which LMA works together with MAGs to assure 1078 the reachability to the mobile using its Home Prefixes, as long as 1079 the mobile roams within the same provider's domain. 1081 One main reason for this approach is perhaps backward compatibility. 1082 By not requiring the participation of mobiles in control signaling 1083 process, it avoids any changes to the mobile nodes, so that the 1084 mobile nodes can stay simple and all the legacy nodes can obtain the 1085 same level of mobility services as the latest mobile devices. 1086 According to the the claim of 3G vendors and operators, transparent 1087 mobility support is a key aspect for success as they learn from their 1088 deployment experience. 1090 On the other hand, most of the mobility support protocols surveyed in 1091 this document focus on mobility support only, assuming mobiles 1092 already obtained network access. The mobile nodes typically update 1093 their locations themselves to the rendezvous points chosen by the 1094 users, and of course only the nodes implementing one of these 1095 solutions can benefit from mobility support. However, this class of 1096 protocols do offer the users and mobile devices with more flexibility 1097 and freedom, e.g. they can choose whatever mobility services 1098 available as long as their software support that protocol, and they 1099 can also tune the parameters to get the services that are most 1100 suitable to them. 1102 5.4. Local and Global Scale Mobility 1104 The works done on mobility management can also be divided according 1105 to their scale into two categories: local mobility management and 1106 global mobility management. 1108 Global mobility management is typically supposed to support mobility 1109 of unlimited number of nodes in a geographically as well as 1110 topologically large area. Consequentially, it pays a lot of 1111 attentions to the scalability issues. For the availability concern, 1112 it also tries to avoid failure of single point. 1114 Local mobility management on the other hand is designed to work 1115 together with global mobility management, and thus focuses more on 1116 performance issues, such as handoff delay, handoff loss, local data 1117 path and etc. Since it is typically used in a small scale with not- 1118 so-large number of mobile nodes, sometimes the designers can use some 1119 fine-tune mechanisms that are not scale with large network (such as 1120 host route) to improvement performance. As a side effect of local 1121 mobility management, the number of location updates sent by mobile 1122 nodes to their global rendezvous points is substantially reduced. 1123 Thus, the existence of local mobility management also contribute to 1124 the scalability of global mobility management. 1126 One problem of the local mobility management is that it often 1127 requires many infrastructure support, such as MAGs in PMIP, or MAPs 1128 in HMIP. These kind of local devices are essentially required in all 1129 small domains, which can be a huge investment. 1131 Nevertheless, the mobility managements in two scale make it possible 1132 for designers to design protocols that fit into specific user 1133 requirements; it also enables the gradual deployment of local 1134 enhancement while not losing the ability of global roaming. The co- 1135 existence of the two seems to be a right choice in the foreseeable 1136 future. 1138 Figure 10 shows the classification of the studied protocols according 1139 to their serving scale. 1141 +-----------+-----------------------------------------+ 1142 | | VIP, LSR, Mobile IP, NEMO, E2E, M-SCTP | 1143 | Global | HIP, ILNPv6, Connexion, WIMO, BTMM, | 1144 | | MSM-IP, Global HAHA, LISP-Mobility | 1145 +-----------+-----------------------------------------+ 1146 | Local | Columbia, HMIP, FMIP, Cellular IP, | 1147 | | HAWAII, TIMIP, PMIP | 1148 +-----------+-----------------------------------------+ 1150 Figure 10 1152 5.5. Other Mobility Support Efforts 1154 Despite the wide spectrum of mobility solutions covered by this 1155 survey, the list of mobility protocols is not exhaustive. 1157 GPRS Tunneling Protocol [GTP] is a network-based mobility support 1158 solution widely used in cellular networks. Its implementation only 1159 involves Gateway GPRS Support Node (GGSN) and Serving GPRS Support 1160 Node (SGSN). It allows end users of a GSM or UMTS network to move 1161 from place to place while remaining connected to the Internet as if 1162 from on location at the GGSN. It does this by carrying the 1163 subscriber's data from the subscriber's current SGSN to the GGSN 1164 which is handling the subscriber's session. To some extent, it is 1165 the non-IETF variant of PMIP, with SGSN resembling LMA and GGSN 1166 resembling MAG, respectively. 1168 There are also works on application layer mobility support, most 1169 notably the SIP based mobility support [ALM-SIP]. SIP was initially 1170 designed as an application signaling protocol for multimedia, and 1171 later researchers noticed its potential capability for mobility 1172 support. When the mobile initiates a session with CN, normal SIP 1173 signaling procedure is performed to establish the session. When the 1174 mobile moves to a new network while the session is ongoing, it send a 1175 RE-INVITE message with the existing session but reveals the new IP 1176 address to the CN. The home SIP server is also updated with the 1177 latest location information of the mobile after the move. However, 1178 SIP based approach can not maintain the TCP connections when the 1179 mobile's IP address changes. 1181 A lot of enhancements to Mobile IPv6 Route Optimization have also 1182 been developed. A comprehensive taxonomy and analysis of these 1183 efforts can be found in [RFC 4651]. 1185 6. Discussions 1187 In last section we discussed the different directions towards 1188 mobility support. We now turn our attention to identify both new 1189 opportunities and remaining open issues in providing global scale 1190 mobility support for unlimited number of online mobility devices. We 1191 are not trying to identify the solutions to these issues, but rather, 1192 the goal is to share our opinions and to initiate an open discussion. 1194 6.1. Deployment Issues 1196 Among the various protocols we discussed in this document, few have 1197 been deployed in commercial networks. There are several reasons to 1198 explain this situation. 1200 First, although the research community started to develop mobility 1201 support protocols 20 years ago, it is until recent years that the 1202 number of mobiles soars. Hence, operators did know see the incentive 1203 of deploying mobility support protocol several years back. As of 1204 today, the number of mobiles are still growing by leaps and bounds, 1205 and there is enough user demand for the operators to seriously 1206 consider the deployment of mobility support protocols. 1208 Second, the complexity of most mobility support protocols impedes the 1209 implementation and hence the deployment in commercial networks. The 1210 complexity arises from multiple aspects. One is the optimizations on 1211 performance. And the other is the problem with the use of security 1212 protocols such as IPsec and IKE. The discussions regarding to these 1213 two problems are still ongoing in MEXT working group. Some 1214 researchers argue that the research community should design a "barely 1215 work" version of mobility support protocol first, without considering 1216 nice performance features and complex security mechanism, roll it out 1217 in the real world and improve it thereafter. However, there are 1218 different views on what are the essential features and which security 1219 mechanism is better. 1221 Third, almost all the mobility support protocols assume that the 1222 mobile nodes have network connectivity anywhere any time. In the 1223 reality, however, it is not always the case. Nevertheless, wireless 1224 access is available in more and more places, and it is foreseeable 1225 that in the near future the coverage of wireless access in different 1226 forms (WiFi, Wimax, 3G/4G) would be ubiquitous. 1228 6.2. Session Continuity and Simultaneous Movements 1230 In order for the users to benefit from the mobility support, it is 1231 important to keep the TCP sessions un-interrupted by the mobility. 1232 If the durations of the sessions are short (e.g. web browsing), the 1233 probability is high that the TCP sessions finish before the handover 1234 happens; even if the TCP session is interrupted by the handover, the 1235 cost is usually low (e.g. refresh the web page). However, if the TCP 1236 sessions are typically long (e.g. downloading large files, voice 1237 calls), the interruptions during the handover would become 1238 unacceptable. 1240 It's hard to predict tomorrow's applications, but most of the 1241 mobility support protocols tries to keep the sessions up during the 1242 movements. For routing based protocols, session continuity is not a 1243 problem since the IP address of the mobile never changes. For other 1244 protocols, either a stable IP address (e.g. HoA) or an equivalent 1245 (e.g. HIT) is used in transport layer so that the mobility is 1246 hidden, or the TCP protocol is modified so that both ends can change 1247 IP addresses while keeping the established session (e.g. E2E). 1249 Another concern is the support of simultaneous movements. In some 1250 scenarios, only one end is mobile and the other end is always static; 1251 moreover, the communication between the two is always initiated by 1252 the mobile end. A lot of applications as of today fall into this 1253 category. Typically, the server side is static and the client is 1254 mobile; usually, the client would contact the server first. Hence, 1255 in these scenarios, the support of simultaneous movements is not a 1256 requirement. However, in other scenarios, both ends may be moving at 1257 the same time. For example, during a voice call, two mobile nodes 1258 may experience the handovers simultaneously. In this case, a 1259 rendezvous point is necessary to keep the current locations of the 1260 mobiles so that can find each other after a simultaneous movement. 1261 Besides, if a static server wants to push information to a mobile 1262 client, a rendezvous point is also required. 1264 It is clear that the number of the mobile devices is rapidly growing 1265 and more mobiles are going to provide content in the near future, 1266 hence the simultaneous movements scenarios are considered important. 1267 In fact, almost all the mobility support protocols are equipped with 1268 rendezvous points, either by adding dedicated components or by 1269 leveraging the existing DNS systems. 1271 6.3. Trade-offs of Design Choices on Mobility-awareness 1273 The mobility-awareness at two communicating ends is closely related 1274 to the backward compatibility problem. The Internet has been running 1275 for more than two decades, and the scale of the Internet gets so 1276 large that it is impossible to upgrade the whole system over night. 1277 As a result, it is also not possible for a mobility support system 1278 designer to overlook this problem: how to decide the mobility- 1279 awareness in the protocol design and how important the backward 1280 compatibility is? 1282 In the following text we discuss the trade-offs of the design choices 1283 mentioned in Section 5.2. 1285 The advantage of the first design choice is that the mobile does not 1286 lose the ability of communicating with legacy nodes while roaming 1287 around, i.e. the mobile can benefit from unilateral deployment of 1288 mobility support. Another potential advantage is that the static 1289 nodes do not need to be bothered by the mobility of the mobiles, 1290 which saves the resources and could be desirable if the CN is a busy 1291 server. The disadvantage of this design is also well known: it 1292 introduces triangle routing, which significantly increases the delays 1293 in the worst cases. There are means to remedy the problem, e.g. 1294 Route Optimization in Mobile IP if CN is mobility-capable, and 1295 distributing Home Agents as Global HAHA does, at the expense of 1296 increasing complexity. 1298 The second design cater to the inertness of the Internet (and the 1299 users) by keeping everything status quo from the user's point of 1300 view. It is like the cellular network, with the smart network and 1301 dumb terminals. The advantage is that the legacy nodes can benefit 1302 from the mobility support without upgrade. However, the cost is also 1303 not trivial: the users lose the freedom of control in terms of 1304 mobility management, and a large number of entities in the network 1305 needs to be upgraded. 1307 The third design assumes that the other end is by a large chance also 1308 mobility capable (as of today, more people are accessing the Internet 1309 via mobile devices than a desktop), and thus do not provide backward 1310 compatibility at all; but as a tradeoff, the system design becomes 1311 much simpler and the data path is always the shortest one. 1313 We all know that backward compatibility is important in system 1314 design. But how important is that? How much effort should we make 1315 for this issue? At least for now, the answer is not clear yet. 1317 6.4. Interconnecting Heterogeneous Mobility Support Systems 1319 As our survey suggests, multiple solutions of mobility support are 1320 already there today, and it is almost for sure that the mobility 1321 support systems in the future are going to be heterogeneous. 1322 However, as of today, the inter-operation between different protocols 1323 is still problematic. For example, when a mobile node supporting 1324 Mobile IP only wants to communicate with another mobile with only HIP 1325 support, neither of them can benefit from mobility support. 1327 This situation reminds us the days before IP were adopted. In that 1328 time, the hosts in different networks are not able to communicate 1329 with each other. It is the IP that merged the networks and created 1330 the Internet, where each host can freely communicate with any other 1331 host. Is it necessary to introduce something like IP to the mobility 1332 support in the future? Is it possible to design an architecture, so 1333 that it glues all the mobility support systems together? We believe 1334 the answers to both questions are "yes". 1336 The basic idea for the solution is simple, as the famous quote says: 1337 "Every problem in Computer Science can be solved by adding a level of 1338 indirection". However, the devil is in the details and we still need 1339 to figure that out. 1341 7. Security Considerations 1343 Since mobility means that the location of a mobile may change at any 1344 time, thus how to secure such dynamic location updates is a very 1345 important consideration for all mobility support solutions. However 1346 due to the wide range of the solution proposals examined in this 1347 document, their security aspects also vary over a wide range. For 1348 example home-agent based solutions call for secure communications 1349 between the mobile and its home agent(s). On the other hand for 1350 routing based solutions, such as Connexions, the issue becomes one of 1351 the global routing security. Similarly, for those solutions that use 1352 DNS to provide mapping between identifiers and locators, the issue is 1353 essentially converted to how to secure DNS dynamic updates as well as 1354 queries. To keep this survey document both comprehensive as well as 1355 within a reasonable size, we chose to focus the survey on describing 1356 and comparing the solutions to the center piece of all mobility 1357 supports which is the resolution between identifiers and locators. 1359 8. IANA Considerations 1361 There are no IANA actions required by this document. 1363 9. Informative References 1365 [ALM-SIP] Schulzrinne, H. and E. Wedlund, "Application-Layer 1366 Mobility Using SIP", Mobile Computing and Communications 1367 Review, 2010. 1369 [BTMM] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 1370 "Understanding Apple's Back to My Mac Service", draft - 1371 zhu-mobileme-05.txt, 2010. 1373 [Boeing] Andrew, L., "A Border Gateway Protocol 4 (BGP-4)", 1374 Boeing White Paper, 2006. 1376 [CIP] Valko, A., "Cellular IP: A New Approach to Internet Host 1377 Mobility", ACM SIGCOMM, 1999. 1379 [Columbia] 1380 Ioannidis, J., Duchamp, D., and G. Maguire, "IP-based 1381 Protocols for Mobile Internetworking", ACM SIGCOMM CCR, 1382 1991. 1384 [E2E] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach 1385 to Host Mobility", ACM Mobicom, 2000. 1387 [GTP] "GPRS Tunneling Protocol Across Gn and Gp Interface", 3G 1388 TS 29.060 v3.5.0. 1390 [HAHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 1391 Agents Towards Internet-scale Mobility Deployment", 1392 ACM CoNEXT, 2006. 1394 [HAWAII] Ramjee, R., Varadhan, K., and L. Salgarelli, "HAWAII: A 1395 Domain-based Approach for Supporting Mobility in Wide-are 1396 Wireless Networks", IEEE/ACM Transcations on Networking, 1397 2002. 1399 [ILNP] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for 1400 Unifying Mobility with Multi-Homing, NAT, and Security", 1401 MobiWAC '07, 2007. 1403 [LISP] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, 1404 "Locator/ID Separation Protocol (LISP)", 1405 draft-farinacci-lisp-12.txt (work in progress), 2009. 1407 [LISP-Mobility] 1408 Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP 1409 Mobility Architecture", draft-meyer-lisp-mn-04.txt (work 1410 in progress), 2009. 1412 [LSR] Bhagwat, P. and C. Perkins, "A Mobile Networking System 1413 Based on Internet Protocol (IP)", Mobile and Location- 1414 Independent Computing Symposium, 1993. 1416 [M-SCTP] Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and 1417 Prototypical Implementaion of An End-to-End Mobility 1418 Concept", 5th Intl. Workshop on the Internet Challenge, 1419 2002. 1421 [MSM-IP] Mysore, J. and V. Bharghavan, "A New Multicast-based 1422 Architecture for Internet Host Mobility", ACM Mobicom, 1423 1997. 1425 [RFC 2782] 1426 Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1427 Specifying the Location of Services (DNS SRV)", RFC 2782, 1428 2000. 1430 [RFC 3344] 1431 Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1432 2002. 1434 [RFC 3753] 1435 Manner, J. and M. Kojo, "Mobility Related Terminology". 1437 [RFC 3775] 1438 Johnson, D., Perkins, C., and J. Arkko, "IP Mobility 1439 Support in IPv6", RFC 3775, 2004. 1441 [RFC 3963] 1442 Devarapalli, V., Wakikawa, R., Peterson, A., and P. 1443 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1444 RFC 3963, 2005. 1446 [RFC 4193] 1447 "Unique Local IPv6 Unicast Address", RFC 4193. 1449 [RFC 4555] 1450 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1451 (MOBIKE)", RFC 4555, 2006. 1453 [RFC 4651] 1454 Vogt, C. and J. Arkko, "A Taxonomy and Analysis of 1455 Enhancements to Mobile IPv6 Route Optimization", RFC 1456 4651, February 2007. 1458 [RFC 5201] 1459 Nikander, P., Moskowitz, R., Jokela, P., and T. Henderson, 1460 "Host Identity Protocol", RFC 5201, 2008. 1462 [RFC 5213] 1463 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1464 and B. Patil, "Proxy Mobile IPv6", RFC 5213, 2008. 1466 [RFC 5380] 1467 Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, 1468 "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", 1469 RFC 5380, 2005. 1471 [RFC 5454] 1472 Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile 1473 IPv4", RFC 5454, 2009. 1475 [RFC 5568] 1476 Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 2009. 1478 [TIMIP] Grilo, A., Estrela, P., and M. Nunes, "Terminal 1479 Independent Mobility For IP", IEEE Communications 1480 Magazine, 2001. 1482 [VIP] Teraoka, F., Yokote, Y., and M. Tokro, "A Network 1483 Architecture Providing Host Migration Transparency", 1484 ACM SIGCOMM CCR, 1991. 1486 [WINMO] Hu, X., Li, L., Mao, Z., and Y. Yang, "Wide-Area IP 1487 Network Mobility", IEEE INFOCOM, 2008. 1489 Authors' Addresses 1491 Zhenkai Zhu 1492 UCLA 1493 4805 Boelter Hall, UCLA 1494 Los Angeles, CA 90095 1495 US 1497 Phone: +1 310 993 7128 1498 Email: zhenkai@cs.ucla.edu 1499 Ryuji Wakikawa 1500 TOYOTA ITC 1501 465 Bernardo Avenue 1502 Mountain View, CA 94043 1503 US 1505 Email: ryuji@jp.toyota-itc.com 1507 Lixia Zhang 1508 UCLA 1509 3713 Boelter Hall, UCLA 1510 Los Angeles, CA 90095 1511 US 1513 Phone: +1 310 825 2695 1514 Email: lixia@cs.ucla.edu