idnits 2.17.1 draft-ietf-dmm-requirements-13.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 == Line 614 has weird spacing: '...orkshop on Se...' == Line 637 has weird spacing: '...ference on Fu...' -- The document date (January 31, 2014) is 3731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.bhandari-dhc-class-based-prefix' is defined on line 570, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chan (Ed.) 3 Internet-Draft Huawei Technologies (more 4 Intended status: Informational co-authors on P. 17) 5 Expires: August 4, 2014 D. Liu 6 China Mobile 7 P. Seite 8 Orange 9 H. Yokota 10 KDDI Lab 11 J. Korhonen 12 Broadcom Communications 13 January 31, 2014 15 Requirements for Distributed Mobility Management 16 draft-ietf-dmm-requirements-13 18 Abstract 20 This document defines the requirements for Distributed Mobility 21 Management (DMM) at the network layer. The hierarchical structure in 22 traditional wireless networks has led primarily to centralized 23 deployment models. As some wireless networks are evolving away from 24 the hierarchical structure, a distributed model for mobility 25 management can be useful to them. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 RFC 2119 32 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 4, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions used in this document . . . . . . . . . . . . . . 5 69 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Centralized versus distributed mobility management . . . . . . 6 71 3.1. Centralized mobility management . . . . . . . . . . . . . 7 72 3.2. Distributed mobility management . . . . . . . . . . . . . 8 73 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 In the past decade a fair number of network-layer mobility protocols 86 have been standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] 87 [RFC5213]. Although the protocols differ in terms of functions and 88 associated message formats, they all employ a mobility anchor to 89 allow a mobile node to remain reachable after it has moved to a 90 different network. The anchor point, among other tasks, ensures 91 connectivity by forwarding packets destined to, or sent from, the 92 mobile node. It is a centrally deployed mobility anchor in the sense 93 that the deployed architectures today have a small number of these 94 anchors and the traffic of millions of mobile nodes in an operator 95 network are typically managed by the same anchor. 97 Distributed mobility management (DMM) is an alternative to the above 98 centralized deployment. The background behind the interests to study 99 DMM are primarily in the following. 101 (1) Mobile users are, more than ever, consuming Internet content 102 including that of local Content Delivery Networks (CDNs) which 103 had not taken mobility service into account before. Such 104 traffic imposes new requirements on mobile core networks for 105 data traffic delivery. To prevent exceeding the available core 106 network capacity, service providers need to implement new 107 strategies such as selective IPv4 traffic offload (e.g. 108 [RFC6909], 3GPP work items Local IP Access (LIPA) and Selected 109 IP Traffic Offload (SIPTO) [TS.23.401]) through alternative 110 access networks (e.g. WLAN) [Paper-Mobile.Data.Offloading]. In 111 addition, a gateway selection mechanism takes the user proximity 112 into account within EPC [TS.29303]. Yet these mechanisms were 113 not pursued in the past owing to charging and billing which 114 require solutions beyond the mobility protocol. Consequently, 115 assigning a gateway anchor node from a visited network in 116 roaming scenario has until recently been done and are limited to 117 voice services only. 119 Both traffic offloading and CDN mechanisms could benefit from 120 the development of mobile architectures with fewer levels of 121 routing hierarchy introduced into the data path by the mobility 122 management system. This trend towards so-called "flat networks" 123 works best for direct communications among peers in the same 124 geographical area. Distributed mobility management in a truly 125 flat mobile architecture would anchor the traffic closer to the 126 point of attachment of the user. 128 (2) Today's mobile networks present service providers with new 129 challenges. Mobility patterns indicate that mobile nodes often 130 remain attached to the same point of attachment for considerable 131 periods of time [Paper-Locating.User]. Specific IP mobility 132 management support is not required for applications that launch 133 and complete their sessions while the mobile node is connected 134 to the same point of attachment. However, currently, IP 135 mobility support is designed for always-on operation, 136 maintaining all parameters of the context for each mobile 137 subscriber for as long as they are connected to the network. 138 This can result in a waste of resources and unnecessary costs 139 for the service provider. Infrequent node mobility coupled with 140 application intelligence suggest that mobility support could be 141 provided selectively such as in [I-D.bhandari-dhc-class-based- 142 prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing 143 the amount of context maintained in the network. 145 DMM may distribute the mobility anchors in the data-plane towards a 146 more flat network such that the mobility anchors are positioned 147 closer to the user; ideally, mobility agents could be collocated with 148 the first-hop router. Facilitated by the distribution of mobility 149 anchors, DMM may also selectively activate/deactivate mobility 150 protocol support. There is need to identify when mobility support 151 must be activated and when sessions do not require mobility 152 management support. It can thus reduce the amount of state 153 information that must be maintained in various mobility agents of the 154 mobile network. It can then avoid the unnecessary establishment of 155 mechanisms to forward traffic from an old to a new mobility anchor. 157 This document compares distributed mobility management with 158 centralized mobility management in Section 3. The problems that can 159 be addressed with DMM are summarized in Section 4. The mandatory 160 requirements as well as the optional requirements for network-layer 161 distributed mobility management are given in Section 5. Finally, 162 security considerations are discussed in Section 6. 164 The problem statement and the use cases [I-D.yokota-dmm-scenario] can 165 be found in [Paper-Distributed.Mobility.Review]. 167 2. Conventions used in this document 169 2.1. Terminology 171 All the general mobility-related terms and their acronyms used in 172 this document are to be interpreted as defined in the Mobile IPv6 173 base specification [RFC6275], in the Proxy mobile IPv6 specification 174 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 175 terms include the following: mobile node (MN), correspondent node 176 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 177 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 178 as per [RFC3753]. 180 In addition, this draft introduces the following terms. 182 Centrally deployed mobility anchors 184 refer to the mobility management deployments in which there are 185 very few mobility anchors and the traffic of millions of mobile 186 nodes in an operator network are managed by the same anchor. 188 Centralized mobility management 190 makes use of centrally deployed mobility anchors. 192 Distributed mobility management 194 is not centralized so that traffic does not need to traverse 195 centrally deployed mobility anchors far from the optimal route. 197 Flat mobile network 199 has few levels of routing hierarchy introduced into the data path 200 by the mobility management system. 202 Mobility context 204 is the collection of information required to provide mobility 205 management support for a given mobile node. 207 3. Centralized versus distributed mobility management 209 Mobility management is needed because the IP address of a mobile node 210 may change as the node moves. Mobility management functions may be 211 implemented at different layers of the protocol stack. At the IP 212 (network) layer, mobility management can be client-based or network- 213 based. 215 An IP-layer mobility management protocol is typically based on the 216 principle of distinguishing between a session identifier and a 217 routing address and maintaining a mapping between the two. In Mobile 218 IP, the new IP address of the mobile node after the node has moved is 219 the routing address, whereas the original IP address before the 220 mobile node moves serves as the session identifier. The location 221 management (LM) information is kept by associating the routing 222 address with the session identifier. Packets addressed to the 223 session identifier will first route to the original network which re- 224 directs them using the routing address to deliver to the session. 225 Re-directing packets this way can result in long routes. An existing 226 optimization routes directly using the routing address of the host, 227 and such is a host-based solution. 229 The next two subsections explain centralized and distributed mobility 230 management functions in the network. 232 3.1. Centralized mobility management 234 In centralized mobility management, the location information in terms 235 of a mapping between the session identifier and the routing address 236 is kept at a single mobility anchor, and packets destined to the 237 session identifier are routed via this anchor. In other words, such 238 mobility management systems are centralized in both the control plane 239 and the data plane (mobile node IP traffic). 241 Many existing mobility management deployments make use of centralized 242 mobility anchoring in a hierarchical network architecture, as shown 243 in Figure 1. Examples are the home agent (HA) and local mobility 244 anchor (LMA) serving as the anchors for the mobile node (MN) and 245 Mobile Access Gateway (MAG) in Mobile IPv6 [RFC6275] and in Proxy 246 Mobile IPv6 [RFC5213] respectively. Cellular networks such as the 247 Third Generation Partnership Project (3GPP) General Packet Radio 248 System (GPRS) networks and 3GPP Evolved Packet System (EPS) networks 249 employ centralized mobility management too. In the 3GPP GPRS 250 network, the Gateway GPRS Support Node (GGSN), Serving GPRS Support 251 Node (SGSN) and Radio Network Controller (RNC) constitute a hierarchy 252 of anchors. In the 3GPP EPS network, the Packet Data Network Gateway 253 (P-GW) and Serving Gateway (S-GW) constitute another hierarchy of 254 anchors. 256 3G GPRS 3GPP EPS MIP/PMIP 257 +------+ +------+ +------+ 258 | GGSN | | P-GW | |HA/LMA| 259 +------+ +------+ +------+ 260 /\ /\ /\ 261 / \ / \ / \ 262 / \ / \ / \ 263 / \ / \ / \ 264 / \ / \ / \ 265 / \ / \ / \ 266 / \ / \ / \ 267 +------+ +------+ +------+ +------+ +------+ +------+ 268 | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG| 269 +------+ +------+ +------+ +------+ +------+ +------+ 270 /\ /\ 271 / \ / \ 272 / \ / \ 273 +---+ +---+ +---+ +---+ 274 |RNC| |RNC| |RNC| |RNC| 275 +---+ +---+ +---+ +---+ 277 Figure 1. Centralized mobility management. 279 3.2. Distributed mobility management 281 Mobility management functions may also be distributed to multiple 282 networks as shown in Figure 2, so that a mobile node in any of these 283 networks may be served by a nearby function with appropriate 284 mobility/routing management (RM) capability. 286 +------+ +------+ +------+ +------+ 287 | RM | | RM | | RM | | RM | 288 +------+ +------+ +------+ +------+ 289 | 290 +----+ 291 | MN | 292 +----+ 294 Figure 2. Distributed mobility management. 296 Mobility management may be partially or fully distributed 297 [I-D.yokota-dmm-scenario]. In the former case only the data plane is 298 distributed, implicitly assuming separation of data and control 299 planes as described in [I-D.wakikawa-netext-pmip-cp-up-separation]. 300 Fully distributed mobility management implies that both the data 301 plane and the control plane are distributed. While mobility 302 management can be distributed, it is not necessary for other 303 functions such as subscription management, subscription database, and 304 network access authentication to be similarly distributed. 306 A distributed mobility management scheme for a flat mobile network of 307 access nodes is proposed in [Paper-Distributed.Dynamic.Mobility]. 308 Its benefits over centralized mobility management have been shown 309 through simulations [Paper-Distributed.Centralized.Mobility]. 310 Moreover, the (re)use and extension of existing protocols in the 311 design of both fully distributed mobility management [Paper- 312 Migrating.Home.Agents] [Paper-Distributed.Mobility.SAE] and partially 313 distributed mobility management [Paper-Distributed.Mobility.PMIP] 314 [Paper-Distributed.Mobility.MIP] have been reported in the 315 literature. Therefore, before designing new mobility management 316 protocols for a future distributed architecture, it is recommended to 317 first consider whether existing mobility management protocols can be 318 extended. 320 4. Problem Statement 322 The problems that can be addressed with DMM are summarized in the 323 following: 325 PS1: Non-optimal routes 327 Routing via a centralized anchor often results in non-optimal 328 routes, thereby increasing the end-to-end delay. The problem 329 is manifested, for example, when accessing a nearby server or 330 servers of a Content Delivery Network (CDN), or when receiving 331 locally available IP multicast or sending IP multicast packets. 332 (Existing route optimization is only a host-based solution. On 333 the other hand, localized routing with PMIPv6 [RFC6705] 334 addresses only a part of the problem where both the MN and the 335 correspondent node (CN) are attached to the same MAG, and it is 336 not applicable when the CN does not behave like an MN.) 338 PS2: Divergence from other evolutionary trends in network 339 architectures such as distribution of content delivery. 341 Mobile networks have generally been evolving towards a flat 342 network. Centralized mobility management, which is non-optimal 343 with a flat network architecture, does not support this 344 evolution. 346 PS3: Lack of scalability of centralized tunnel management and 347 mobility context maintenance 349 Setting up tunnels through a central anchor and maintaining 350 mobility context for each MN usually requires more concentrated 351 resources in a centralized design, thus reducing scalability. 352 Distributing the tunnel maintenance function and the mobility 353 context maintenance function among different network entities 354 with proper signaling protocol design can avoid increasing the 355 concentrated resources with an increasing number of MNs. 357 PS4: Single point of failure and attack 359 Centralized anchoring designs may be more vulnerable to single 360 points of failures and attacks than a distributed system. The 361 impact of a successful attack on a system with centralized 362 mobility management can be far greater as well. 364 PS5: Unnecessary mobility support to clients that do not need it 366 IP mobility support is usually provided to all MNs. Yet it is 367 not always required, and not every parameter of mobility 368 context is always used. For example, some applications or 369 nodes do not need a stable IP address during a handover to 370 maintain session continuity. Sometimes, the entire application 371 session runs while the MN does not change the point of 372 attachment. Besides, some sessions, e.g. SIP-based sessions, 373 can handle mobility at the application layer and hence do not 374 need IP mobility support; it is then unnecessary to provide IP 375 mobility support for such sessions. 377 PS6: Mobility signaling overhead with peer-to-peer communication 379 Wasting resources when mobility signaling (e.g., maintenance of 380 the tunnel, keep alive signaling, etc.) is not turned off for 381 peer-to-peer communication. 383 PS7: Deployment with multiple mobility solutions 385 There are already many variants and extensions of MIP as well 386 mobility solutions at other layers. Deployment of new mobility 387 management solutions can be challenging, and debugging 388 difficult, when they co-exist with solutions already deployed 389 in the field. 391 PS8: Duplicate multicast traffic 393 IP multicast distribution over architectures using IP mobility 394 solutions (e.g., [RFC6224]) may lead to convergence of 395 duplicated multicast subscriptions towards the downstream 396 tunnel entity (e.g. MAG in PMIPv6). Concretely, when 397 multicast subscription for individual mobile nodes is coupled 398 with mobility tunnels (e.g. PMIPv6 tunnel), duplicate 399 multicast subscription(s) is prone to be received through 400 different upstream paths. This problem may also exist or be 401 more severe in a distributed mobility environment. 403 5. Requirements 405 After comparing distributed mobility management against centralized 406 deployment in Section 3 and describing the problems in Section 4, 407 this section identifies the following requirements: 409 REQ1: Distributed processing 411 IP mobility, network access and routing solutions provided by 412 DMM MUST enable distributed processing for mobility management 413 so that traffic can avoid traversing single mobility anchor 414 far from the optimal route. 416 Motivation: This requirement is motivated by current trends in 417 network evolution: (a) it is cost- and resource-effective to 418 cache contents, and the caching (e.g., CDN) servers are 419 distributed so that each user in any location can be close to 420 one of the servers; (b) the significantly larger number of 421 mobile nodes and flows call for improved scalability; (c) 422 single points of failure are avoided in a distributed system; 423 (d) threats against centrally deployed anchors, e.g., home 424 agent and local mobility anchor, are mitigated in a 425 distributed system. 427 This requirement addresses the problems PS1, PS2, PS3, and PS4 428 described in Section 4. 430 REQ2: Bypassable network-layer mobility support 432 DMM solutions MUST enable network-layer mobility but it MUST 433 be possible to not use it. Mobility support is needed, for 434 example, when a mobile host moves and an application cannot 435 cope with a change in the IP address. Mobility support is 436 also needed, for example, when a mobile router moves together 437 with a host and an application in the host is interrupted by a 438 change of IP address of the mobile router. However mobility 439 support at the network-layer is not always needed; a mobile 440 node can often be stationary, and mobility support can also be 441 provided at other layers. It is then not always necessary to 442 maintain a stable IP address or prefix. 444 Motivation: The motivation of this requirement is to enable 445 more efficient routing and more efficient use of network 446 resources by selecting an IP address or prefix according to 447 whether mobility support is needed and by not maintaining 448 context at the mobility anchor when there is no such need. 450 This requirement addresses the problems PS5 and PS6 described in 451 Section 4. 453 REQ3: IPv6 deployment 455 DMM solutions SHOULD target IPv6 as the primary deployment 456 environment and SHOULD NOT be tailored specifically to support 457 IPv4, in particular in situations where private IPv4 addresses 458 and/or NATs are used. 460 Motivation: This requirement conforms to the general 461 orientation of IETF work. DMM deployment is foreseen in mid- 462 to long-term horizon, when IPv6 is expected to be far more 463 common than today. 465 This requirement avoids the unnecessarily complexity in solving the 466 problems in Section 4 for IPv4, which will not be able to use some of 467 the IPv6-specific features. 469 REQ4: Existing mobility protocols 471 A DMM solution MUST first consider reusing and extending IETF- 472 standardized protocols before specifying new protocols. 474 Motivation: Reuse of existing IETF work is more efficient and 475 less error-prone. 477 This requirement attempts to avoid the need of new protocols 478 development and therefore their potential problems of being time- 479 consuming and error-prone. 481 REQ5: Coexistence with deployed networks and hosts 483 The DMM solution may require loose, tight or no integration 484 into existing mobility protocols and host IP stack. 485 Regardless of the integration level, the DMM solution MUST be 486 able to coexist with existing network deployments, end hosts 487 and routers that may or may not implement existing mobility 488 protocols. Furthermore, a DMM solution SHOULD work across 489 different networks, possibly operated as separate 490 administrative domains, when allowed by the trust relationship 491 between them. 493 Motivation: (a) to preserve backwards compatibility so that 494 existing networks and hosts are not affected and continue to 495 function as usual, and (b) enable inter-domain operation if 496 desired. 498 This requirement addresses the problem PS7 described in Section 4. 500 REQ6: Security considerations 502 A DMM solution MUST NOT introduce new security risks, or 503 amplify existing security risks, that cannot be mitigated by 504 existing security mechanisms or protocols. 506 Motivation: Various attacks such as impersonation, denial of 507 service, man-in-the-middle attacks, and so on, may be launched 508 in a DMM deployment. For instance, an illegitimate node may 509 attempt to access a network providing DMM. Another example is 510 that a malicious node can forge a number of signaling messages 511 thus redirecting traffic from its legitimate path. 512 Consequently, the specific node is under a denial of service 513 attack, whereas other nodes do not receive their traffic. 514 Accordingly, security mechanisms/protocols providing access 515 control, integrity, authentication, authorization, 516 confidentiality, etc. can be used to protect the DMM entities 517 as they are already used to protect against existing networks 518 and existing mobility protocols defined in IETF. 520 This requirement prevents a DMM solution from introducing 521 uncontrollable problems of potentially insecure mobility management 522 protocols which make deployment infeasible because platforms 523 conforming to the protocols are at risk for data loss and numerous 524 other dangers, including financial harm to the users. 526 REQ7: Multicast considerations 528 DMM SHOULD enable multicast solutions to be developed to avoid 529 network inefficiency in multicast traffic delivery. 531 Motivation: Existing multicast deployment have been introduced 532 after completing the design of the reference mobility 533 protocol, often leading to network inefficiency and non- 534 optimal routing for the multicast traffic. Instead DMM should 535 consider multicast early so that the multicast solutions can 536 better consider efficiency nature in the multicast traffic 537 delivery (such as duplicate multicast subscriptions towards 538 the downstream tunnel entities). The multicast solutions 539 should then avoid restricting the management of all IP 540 multicast traffic to a single host through a dedicated 541 (tunnel) interface on multicast-capable access routers. 543 This requirement addresses the problems PS1 and PS8 described in 544 Section 4. 546 6. Security Considerations 548 Please refer to the discussion under Security requirement in Section 549 5.6. 551 7. IANA Considerations 553 None 555 8. Co-authors and Contributors 557 This problem statement document is a joint effort among the numerous 558 participants. Each individual has made significant contributions to 559 this work and have been listed as co-authors. 561 9. References 563 9.1. Normative References 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 9.2. Informative References 570 [I-D.bhandari-dhc-class-based-prefix] 571 Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H., 572 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 573 based prefix", draft-bhandari-dhc-class-based-prefix-05 574 (work in progress), July 2013. 576 [I-D.korhonen-6man-prefix-properties] 577 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 578 Liu, "IPv6 Prefix Properties", 579 draft-korhonen-6man-prefix-properties-02 (work in 580 progress), July 2013. 582 [I-D.wakikawa-netext-pmip-cp-up-separation] 583 Wakikawa, R., Pazhyannur, R., and S. Gundavelli, 584 "Separation of Control and User Plane for Proxy Mobile 585 IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00 586 (work in progress), July 2013. 588 [I-D.yokota-dmm-scenario] 589 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 590 scenarios for Distributed Mobility Management", 591 draft-yokota-dmm-scenario-00 (work in progress), 592 October 2010. 594 [Paper-Distributed.Centralized.Mobility] 595 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 596 or Centralized Mobility", Proceedings of Global 597 Communications Conference (GlobeCom), December 2009. 599 [Paper-Distributed.Dynamic.Mobility] 600 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 601 Dynamic Mobility Management Scheme Designed for Flat IP 602 Architectures", Proceedings of 3rd International 603 Conference on New Technologies, Mobility and Security 604 (NTMS), 2008. 606 [Paper-Distributed.Mobility.MIP] 607 Chan, H., "Distributed Mobility Management with Mobile 608 IP", Proceedings of IEEE International Communication 609 Conference (ICC) Workshop on Telecommunications: from 610 Research to Standards, June 2012. 612 [Paper-Distributed.Mobility.PMIP] 613 Chan, H., "Proxy Mobile IP with Distributed Mobility 614 Anchors", Proceedings of GlobeCom Workshop on Seamless 615 Wireless Mobility, December 2010. 617 [Paper-Distributed.Mobility.Review] 618 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 619 "Distributed and Dynamic Mobility Management in Mobile 620 Internet: Current Approaches and Issues", Journal of 621 Communications, vol. 6, no. 1, pp. 4-15, February 2011. 623 [Paper-Distributed.Mobility.SAE] 624 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 625 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 626 Proceedings of the 19th International Symposium on 627 Personal, Indoor and Mobile Radio Communications (PIMRC), 628 2008. 630 [Paper-Locating.User] 631 Kirby, G., "Locating the User", Communication 632 International, 1995. 634 [Paper-Migrating.Home.Agents] 635 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 636 Agents Towards Internet-scale Mobility Deployments", 637 Proceedings of the ACM 2nd CoNEXT Conference on Future 638 Networking Technologies, December 2006. 640 [Paper-Mobile.Data.Offloading] 641 Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile 642 Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 643 2010, 2010. 645 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 646 RFC 3753, June 2004. 648 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 649 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 651 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 652 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 653 Management", RFC 5380, October 2008. 655 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 656 RFC 5944, November 2010. 658 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 659 Deployment for Multicast Listener Support in Proxy Mobile 660 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 662 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 663 in IPv6", RFC 6275, July 2011. 665 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 666 Support in the Internet", RFC 6301, July 2011. 668 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 669 Dutta, "Localized Routing for Proxy Mobile IPv6", 670 RFC 6705, September 2012. 672 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 673 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 674 Mobile IPv6", RFC 6909, April 2013. 676 [TS.23.401] 677 3GPP, "General Packet Radio Service (GPRS) enhancements 678 for Evolved Universal Terrestrial Radio Access Network 679 (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. 681 [TS.29303] 682 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 683 TR 23.303 11.2.0, September 2012. 685 Authors' Addresses 687 H Anthony Chan (editor) 688 Huawei Technologies (more co-authors on P. 17) 689 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 690 Email: h.a.chan@ieee.org 692 Dapeng Liu 693 China Mobile 694 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 695 Email: liudapeng@chinamobile.com 697 Pierrick Seite 698 Orange 699 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 700 Email: pierrick.seite@orange.com 702 Hidetoshi Yokota 703 KDDI Lab 704 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 705 Email: yokota@kddilabs.jp 707 Jouni Korhonen 708 Broadcom Communications 709 Porkkalankatu 24, FIN-00180 Helsinki, Finland 710 Email: jouni.nospam@gmail.com 711 - 712 Charles E. Perkins 713 Huawei Technologies 714 Email: charliep@computer.org 715 - 716 Melia Telemaco 717 Alcatel-Lucent Bell Labs 718 Email: telemaco.melia@googlemail.com 719 - 720 Elena Demaria 721 Telecom Italia 722 via G. Reiss Romoli, 274, TORINO, 10148, Italy 723 Email: elena.demaria@telecomitalia.it 724 - 725 Jong-Hyouk Lee 726 Sangmyung University, Korea 727 Email: jonghyouk@smu.ac.kr 728 - 729 Kostas Pentikousis 730 EICT GmbH 731 Email: k.pentikousis@eict.de 732 - 733 Tricci So 734 ZTE 735 Email: tso@zteusa.com 736 - 737 Carlos J. Bernardos 738 Universidad Carlos III de Madrid 739 Av. Universidad, 30, Leganes, Madrid 28911, Spain 740 Email: cjbc@it.uc3m.es 741 - 742 Peter McCann 743 Huawei Technologies 744 Email: Peter.McCann@huawei.com 745 - 746 Seok Joo Koh 747 Kyungpook National University, Korea 748 Email: sjkoh@knu.ac.kr 749 - 750 Wen Luo 751 ZTE 752 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 753 Email: luo.wen@zte.com.cn 754 - 755 Sri Gundavelli 756 Cisco 757 sgundave@cisco.com 758 - 759 Marco Liebsch 760 NEC Laboratories Europe 761 Email: liebsch@neclab.eu 762 - 763 Carl Williams 764 MCSR Labs 765 Email: carlw@mcsr-labs.org 766 - 767 Seil Jeon 768 Instituto de Telecomunicacoes, Aveiro 769 Email: seiljeon@av.it.pt 770 - 771 Sergio Figueiredo 772 Universidade de Aveiro 773 Email: sfigueiredo@av.it.pt 774 - 775 Stig Venaas 776 Email: stig@venaas.com 777 - 778 Luis Miguel Contreras Murillo 779 Telefonica I+D 780 Email: lmcm@tid.es 781 - 782 Juan Carlos Zuniga 783 InterDigital 784 Email: JuanCarlos.Zuniga@InterDigital.com 785 - 786 Alexandru Petrescu 787 Email: alexandru.petrescu@gmail.com 788 - 789 Georgios Karagiannis 790 University of Twente 791 Email: g.karagiannis@utwente.nl 792 - 793 Julien Laganier 794 Juniper 795 julien.ietf@gmail.com 796 - 797 Wassim Michel Haddad 798 Ericsson 799 Wassim.Haddad@ericsson.com 800 - 801 Dirk von Hugo 802 Deutsche Telekom Laboratories 803 Dirk.von-Hugo@telekom.de 804 - 805 Ahmad Muhanna 806 Award Solutions 807 asmuhanna@yahoo.com 808 - 809 Byoung-Jo Kim 810 ATT Labs 811 macsbug@research.att.com 812 - 813 Hassan Ali-Ahmad 814 Orange 815 hassan.aliahmad@orange.com 816 - 817 Alper Yegin 818 Samsung 819 alper.yegin@partner.samsung.com 820 -