idnits 2.17.1 draft-ietf-dmm-requirements-14.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 721 has weird spacing: '...orkshop on Se...' == Line 744 has weird spacing: '...ference on Fu...' -- The document date (February 3, 2014) is 3729 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 677, 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 4 Intended status: Informational D. Liu 5 Expires: August 7, 2014 China Mobile 6 P. Seite 7 Orange 8 H. Yokota 9 KDDI Lab 10 J. Korhonen 11 Broadcom Communications 12 February 3, 2014 14 Requirements for Distributed Mobility Management 15 draft-ietf-dmm-requirements-14 17 Abstract 19 This document defines the requirements for Distributed Mobility 20 Management (DMM) at the network layer. The hierarchical structure in 21 traditional wireless networks has led primarily to centralized 22 deployment models. As some wireless networks are evolving away from 23 the hierarchical structure, a distributed model for mobility 24 management can be useful to them. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 RFC 2119 31 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions used in this document . . . . . . . . . . . . . . 4 69 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Centralized versus distributed mobility management . . . . . . 5 71 3.1. Centralized mobility management . . . . . . . . . . . . . 6 72 3.2. Distributed mobility management . . . . . . . . . . . . . 7 73 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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, it may be possible to selectively use or not use mobility 150 protocol support depending on whether such support is needed or not. 151 It can thus reduce the amount of state information that must be 152 maintained in various mobility agents of the mobile network. It can 153 then avoid the unnecessary establishment of mechanisms to forward 154 traffic from an old to a new mobility anchor. 156 This document compares distributed mobility management with 157 centralized mobility management in Section 3. The problems that can 158 be addressed with DMM are summarized in Section 4. The mandatory 159 requirements as well as the optional requirements for network-layer 160 distributed mobility management are given in Section 5. Finally, 161 security considerations are discussed in Section 6. 163 The problem statement and the use cases [I-D.yokota-dmm-scenario] can 164 be found in [Paper-Distributed.Mobility.Review]. 166 2. Conventions used in this document 168 2.1. Terminology 170 All the general mobility-related terms and their acronyms used in 171 this document are to be interpreted as defined in the Mobile IPv6 172 base specification [RFC6275], in the Proxy mobile IPv6 specification 173 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 174 terms include the following: mobile node (MN), correspondent node 175 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 176 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 177 as per [RFC3753]. 179 In addition, this draft introduces the following terms. 181 Centrally deployed mobility anchors 183 refer to the mobility management deployments in which there are 184 very few mobility anchors and the traffic of millions of mobile 185 nodes in an operator network are managed by the same anchor. 187 Centralized mobility management 189 makes use of centrally deployed mobility anchors. 191 Distributed mobility management 193 is not centralized so that traffic does not need to traverse 194 centrally deployed mobility anchors far from the optimal route. 196 Flat mobile network 198 has few levels of routing hierarchy introduced into the data path 199 by the mobility management system. 201 Mobility context 203 is the collection of information required to provide mobility 204 management support for a given mobile node. 206 3. Centralized versus distributed mobility management 208 Mobility management is needed because the IP address of a mobile node 209 may change as the node moves. Mobility management functions may be 210 implemented at different layers of the protocol stack. At the IP 211 (network) layer, mobility management can be client-based or network- 212 based. 214 An IP-layer mobility management protocol is typically based on the 215 principle of distinguishing between a session identifier and a 216 routing address and maintaining a mapping between the two. In Mobile 217 IP, the new IP address of the mobile node after the node has moved is 218 the routing address, whereas the original IP address before the 219 mobile node moves serves as the session identifier. The location 220 management (LM) information is kept by associating the routing 221 address with the session identifier. Packets addressed to the 222 session identifier will first route to the original network which re- 223 directs them using the routing address to deliver to the session. 224 Re-directing packets this way can result in long routes. An existing 225 optimization routes directly using the routing address of the host, 226 and such is a host-based solution. 228 The next two subsections explain centralized and distributed mobility 229 management functions in the network. 231 3.1. Centralized mobility management 233 In centralized mobility management, the location information in terms 234 of a mapping between the session identifier and the routing address 235 is kept at a single mobility anchor, and packets destined to the 236 session identifier are routed via this anchor. In other words, such 237 mobility management systems are centralized in both the control plane 238 and the data plane (mobile node IP traffic). 240 Many existing mobility management deployments make use of centralized 241 mobility anchoring in a hierarchical network architecture, as shown 242 in Figure 1. Examples are the home agent (HA) and local mobility 243 anchor (LMA) serving as the anchors for the mobile node (MN) and 244 Mobile Access Gateway (MAG) in Mobile IPv6 [RFC6275] and in Proxy 245 Mobile IPv6 [RFC5213] respectively. Cellular networks such as the 246 Third Generation Partnership Project (3GPP) General Packet Radio 247 System (GPRS) networks and 3GPP Evolved Packet System (EPS) networks 248 employ centralized mobility management too. In the 3GPP GPRS 249 network, the Gateway GPRS Support Node (GGSN), Serving GPRS Support 250 Node (SGSN) and Radio Network Controller (RNC) constitute a hierarchy 251 of anchors. In the 3GPP EPS network, the Packet Data Network Gateway 252 (P-GW) and Serving Gateway (S-GW) constitute another hierarchy of 253 anchors. 255 3G GPRS 3GPP EPS MIP/PMIP 256 +------+ +------+ +------+ 257 | GGSN | | P-GW | |HA/LMA| 258 +------+ +------+ +------+ 259 /\ /\ /\ 260 / \ / \ / \ 261 / \ / \ / \ 262 / \ / \ / \ 263 / \ / \ / \ 264 / \ / \ / \ 265 / \ / \ / \ 266 +------+ +------+ +------+ +------+ +------+ +------+ 267 | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG| 268 +------+ +------+ +------+ +------+ +------+ +------+ 269 /\ /\ 270 / \ / \ 271 / \ / \ 272 +---+ +---+ +---+ +---+ 273 |RNC| |RNC| |RNC| |RNC| 274 +---+ +---+ +---+ +---+ 276 Figure 1. Centralized mobility management. 278 3.2. Distributed mobility management 280 Mobility management functions may also be distributed to multiple 281 networks as shown in Figure 2, so that a mobile node in any of these 282 networks may be served by a nearby function with appropriate 283 mobility/routing management (RM) capability. 285 +------+ +------+ +------+ +------+ 286 | RM | | RM | | RM | | RM | 287 +------+ +------+ +------+ +------+ 288 | 289 +----+ 290 | MN | 291 +----+ 293 Figure 2. Distributed mobility management. 295 Mobility management may be partially or fully distributed 296 [I-D.yokota-dmm-scenario]. In the former case only the data plane is 297 distributed, implicitly assuming separation of data and control 298 planes as described in [I-D.wakikawa-netext-pmip-cp-up-separation]. 299 Fully distributed mobility management implies that both the data 300 plane and the control plane are distributed. While mobility 301 management can be distributed, it is not necessary for other 302 functions such as subscription management, subscription database, and 303 network access authentication to be similarly distributed. 305 A distributed mobility management scheme for a flat mobile network of 306 access nodes is proposed in [Paper-Distributed.Dynamic.Mobility]. 307 Its benefits over centralized mobility management have been shown 308 through simulations [Paper-Distributed.Centralized.Mobility]. 309 Moreover, the (re)use and extension of existing protocols in the 310 design of both fully distributed mobility management [Paper- 311 Migrating.Home.Agents] [Paper-Distributed.Mobility.SAE] and partially 312 distributed mobility management [Paper-Distributed.Mobility.PMIP] 313 [Paper-Distributed.Mobility.MIP] have been reported in the 314 literature. Therefore, before designing new mobility management 315 protocols for a future distributed architecture, it is recommended to 316 first consider whether existing mobility management protocols can be 317 extended. 319 4. Problem Statement 321 The problems that can be addressed with DMM are summarized in the 322 following: 324 PS1: Non-optimal routes 326 Routing via a centralized anchor often results in non-optimal 327 routes, thereby increasing the end-to-end delay. The problem 328 is manifested, for example, when accessing a nearby server or 329 servers of a Content Delivery Network (CDN), or when receiving 330 locally available IP multicast or sending IP multicast packets. 331 (Existing route optimization is only a host-based solution. On 332 the other hand, localized routing with PMIPv6 [RFC6705] 333 addresses only a part of the problem where both the MN and the 334 correspondent node (CN) are attached to the same MAG, and it is 335 not applicable when the CN does not behave like an MN.) 337 PS2: Divergence from other evolutionary trends in network 338 architectures such as distribution of content delivery. 340 Mobile networks have generally been evolving towards a flat 341 network. Centralized mobility management, which is non-optimal 342 with a flat network architecture, does not support this 343 evolution. 345 PS3: Lack of scalability of centralized tunnel management and 346 mobility context maintenance 348 Setting up tunnels through a central anchor and maintaining 349 mobility context for each MN usually requires more concentrated 350 resources in a centralized design, thus reducing scalability. 351 Distributing the tunnel maintenance function and the mobility 352 context maintenance function among different network entities 353 with proper signaling protocol design can avoid increasing the 354 concentrated resources with an increasing number of MNs. 356 PS4: Single point of failure and attack 358 Centralized anchoring designs may be more vulnerable to single 359 points of failures and attacks than a distributed system. The 360 impact of a successful attack on a system with centralized 361 mobility management can be far greater as well. 363 PS5: Unnecessary mobility support to clients that do not need it 365 IP mobility support is usually provided to all MNs. Yet it is 366 not always required, and not every parameter of mobility 367 context is always used. For example, some applications or 368 nodes do not need a stable IP address during a handover to 369 maintain session continuity. Sometimes, the entire application 370 session runs while the MN does not change the point of 371 attachment. Besides, some sessions, e.g. SIP-based sessions, 372 can handle mobility at the application layer and hence do not 373 need IP mobility support; it is then unnecessary to provide IP 374 mobility support for such sessions. 376 PS6: Mobility signaling overhead with peer-to-peer communication 378 Wasting resources when mobility signaling (e.g., maintenance of 379 the tunnel, keep alive signaling, etc.) is not turned off for 380 peer-to-peer communication. 382 PS7: Deployment with multiple mobility solutions 384 There are already many variants and extensions of MIP as well 385 mobility solutions at other layers. Deployment of new mobility 386 management solutions can be challenging, and debugging 387 difficult, when they co-exist with solutions already deployed 388 in the field. 390 PS8: Duplicate multicast traffic 392 IP multicast distribution over architectures using IP mobility 393 solutions (e.g., [RFC6224]) may lead to convergence of 394 duplicated multicast subscriptions towards the downstream 395 tunnel entity (e.g. MAG in PMIPv6). Concretely, when 396 multicast subscription for individual mobile nodes is coupled 397 with mobility tunnels (e.g. PMIPv6 tunnel), duplicate 398 multicast subscription(s) is prone to be received through 399 different upstream paths. This problem may also exist or be 400 more severe in a distributed mobility environment. 402 5. Requirements 404 After comparing distributed mobility management against centralized 405 deployment in Section 3 and describing the problems in Section 4, 406 this section identifies the following requirements: 408 REQ1: Distributed processing 410 IP mobility, network access and routing solutions provided by 411 DMM MUST enable distributed processing for mobility management 412 so that traffic can avoid traversing single mobility anchor 413 far from the optimal route. 415 Motivation: This requirement is motivated by current trends in 416 network evolution: (a) it is cost- and resource-effective to 417 cache contents, and the caching (e.g., CDN) servers are 418 distributed so that each user in any location can be close to 419 one of the servers; (b) the significantly larger number of 420 mobile nodes and flows call for improved scalability; (c) 421 single points of failure are avoided in a distributed system; 422 (d) threats against centrally deployed anchors, e.g., home 423 agent and local mobility anchor, are mitigated in a 424 distributed system. 426 This requirement addresses the problems PS1, PS2, PS3, and PS4 427 described in Section 4. 429 REQ2: Bypassable network-layer mobility support 431 DMM solutions MUST enable network-layer mobility but it MUST 432 be possible to not use it. Mobility support is needed, for 433 example, when a mobile host moves and an application cannot 434 cope with a change in the IP address. Mobility support is 435 also needed, for example, when a mobile router moves together 436 with a host and an application in the host is interrupted by a 437 change of IP address of the mobile router. However mobility 438 support at the network-layer is not always needed; a mobile 439 node can often be stationary, and mobility support can also be 440 provided at other layers. It is then not always necessary to 441 maintain a stable IP address or prefix. 443 Motivation: The motivation of this requirement is to enable 444 more efficient routing and more efficient use of network 445 resources by selecting an IP address or prefix according to 446 whether mobility support is needed and by not maintaining 447 context at the mobility anchor when there is no such need. 449 This requirement addresses the problems PS5 and PS6 described in 450 Section 4. 452 REQ3: IPv6 deployment 454 DMM solutions SHOULD target IPv6 as the primary deployment 455 environment and SHOULD NOT be tailored specifically to support 456 IPv4, in particular in situations where private IPv4 addresses 457 and/or NATs are used. 459 Motivation: This requirement conforms to the general 460 orientation of IETF work. DMM deployment is foreseen in mid- 461 to long-term horizon, when IPv6 is expected to be far more 462 common than today. 464 This requirement avoids the unnecessarily complexity in solving the 465 problems in Section 4 for IPv4, which will not be able to use some of 466 the IPv6-specific features. 468 REQ4: Existing mobility protocols 470 A DMM solution MUST first consider reusing and extending IETF- 471 standardized protocols before specifying new protocols. 473 Motivation: Reuse of existing IETF work is more efficient and 474 less error-prone. 476 This requirement attempts to avoid the need of new protocols 477 development and therefore their potential problems of being time- 478 consuming and error-prone. 480 REQ5: Coexistence with deployed networks and hosts 482 The DMM solution may require loose, tight or no integration 483 into existing mobility protocols and host IP stack. 484 Regardless of the integration level, the DMM solution MUST be 485 able to coexist with existing network deployments, end hosts 486 and routers that may or may not implement existing mobility 487 protocols. Furthermore, a DMM solution SHOULD work across 488 different networks, possibly operated as separate 489 administrative domains, when allowed by the trust relationship 490 between them. 492 Motivation: (a) to preserve backwards compatibility so that 493 existing networks and hosts are not affected and continue to 494 function as usual, and (b) enable inter-domain operation if 495 desired. 497 This requirement addresses the problem PS7 described in Section 4. 499 REQ6: Security considerations 501 A DMM solution MUST NOT introduce new security risks, or 502 amplify existing security risks, that cannot be mitigated by 503 existing security mechanisms or protocols. 505 Motivation: Various attacks such as impersonation, denial of 506 service, man-in-the-middle attacks, and so on, may be launched 507 in a DMM deployment. For instance, an illegitimate node may 508 attempt to access a network providing DMM. Another example is 509 that a malicious node can forge a number of signaling messages 510 thus redirecting traffic from its legitimate path. 511 Consequently, the specific node is under a denial of service 512 attack, whereas other nodes do not receive their traffic. 513 Accordingly, security mechanisms/protocols providing access 514 control, integrity, authentication, authorization, 515 confidentiality, etc. can be used to protect the DMM entities 516 as they are already used to protect against existing networks 517 and existing mobility protocols defined in IETF. 519 This requirement prevents a DMM solution from introducing 520 uncontrollable problems of potentially insecure mobility management 521 protocols which make deployment infeasible because platforms 522 conforming to the protocols are at risk for data loss and numerous 523 other dangers, including financial harm to the users. 525 REQ7: Multicast considerations 527 DMM SHOULD enable multicast solutions to be developed to avoid 528 network inefficiency in multicast traffic delivery. 530 Motivation: Existing multicast deployment have been introduced 531 after completing the design of the reference mobility 532 protocol, often leading to network inefficiency and non- 533 optimal routing for the multicast traffic. Instead DMM should 534 consider multicast early so that the multicast solutions can 535 better consider efficiency nature in the multicast traffic 536 delivery (such as duplicate multicast subscriptions towards 537 the downstream tunnel entities). The multicast solutions 538 should then avoid restricting the management of all IP 539 multicast traffic to a single host through a dedicated 540 (tunnel) interface on multicast-capable access routers. 542 This requirement addresses the problems PS1 and PS8 described in 543 Section 4. 545 6. Security Considerations 547 Please refer to the discussion under Security requirement in Section 548 5.6. 550 7. IANA Considerations 552 None 554 8. Contributors 556 This requirements document is a joint effort among numerous 557 participants working in a team. In addition to the authors, each of 558 the following has made very significant and important contributions 559 to this work: 561 Charles E. Perkins 562 Huawei Technologies 563 Email: charliep@computer.org 565 Melia Telemaco 566 Alcatel-Lucent Bell Labs 567 Email: telemaco.melia@googlemail.com 569 Elena Demaria 570 Telecom Italia 571 via G. Reiss Romoli, 274, TORINO, 10148, Italy 572 Email: elena.demaria@telecomitalia.it 574 Jong-Hyouk Lee 575 Sangmyung University, Korea 576 Email: jonghyouk@smu.ac.kr 578 Kostas Pentikousis 579 EICT GmbH 580 Email: k.pentikousis@eict.de 582 Tricci So 583 ZTE 584 Email: tso@zteusa.com 585 Carlos J. Bernardos 586 Universidad Carlos III de Madrid 587 Av. Universidad, 30, Leganes, Madrid 28911, Spain 588 Email: cjbc@it.uc3m.es 590 Peter McCann 591 Huawei Technologies 592 Email: Peter.McCann@huawei.com 594 Seok Joo Koh 595 Kyungpook National University, Korea 596 Email: sjkoh@knu.ac.kr 598 Wen Luo 599 ZTE 600 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 601 Email: luo.wen@zte.com.cn 603 Sri Gundavelli 604 Cisco 605 sgundave@cisco.com 607 Marco Liebsch 608 NEC Laboratories Europe 609 Email: liebsch@neclab.eu 611 Carl Williams 612 MCSR Labs 613 Email: carlw@mcsr-labs.org 615 Seil Jeon 616 Instituto de Telecomunicacoes, Aveiro 617 Email: seiljeon@av.it.pt 619 Sergio Figueiredo 620 Universidade de Aveiro 621 Email: sfigueiredo@av.it.pt 623 Stig Venaas 624 Email: stig@venaas.com 626 Luis Miguel Contreras Murillo 627 Telefonica I+D 628 Email: lmcm@tid.es 630 Juan Carlos Zuniga 631 InterDigital 632 Email: JuanCarlos.Zuniga@InterDigital.com 633 Alexandru Petrescu 634 Email: alexandru.petrescu@gmail.com 636 Georgios Karagiannis 637 University of Twente 638 Email: g.karagiannis@utwente.nl 640 Julien Laganier 641 Juniper 642 Email: julien.ietf@gmail.com 644 Wassim Michel Haddad 645 Ericsson 646 Email: Wassim.Haddad@ericsson.com 648 Dirk von Hugo 649 Deutsche Telekom Laboratories 650 Email: Dirk.von-Hugo@telekom.de 652 Ahmad Muhanna 653 Award Solutions 654 Email: asmuhanna@yahoo.com 656 Byoung-Jo Kim 657 ATT Labs 658 Email: macsbug@research.att.com 660 Hassan Ali-Ahmad 661 Orange 662 Email: hassan.aliahmad@orange.com 664 Alper Yegin 665 Samsung 666 Email: alper.yegin@partner.samsung.com 668 9. References 670 9.1. Normative References 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, March 1997. 675 9.2. Informative References 677 [I-D.bhandari-dhc-class-based-prefix] 678 Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H., 679 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 680 based prefix", draft-bhandari-dhc-class-based-prefix-05 681 (work in progress), July 2013. 683 [I-D.korhonen-6man-prefix-properties] 684 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 685 Liu, "IPv6 Prefix Properties", 686 draft-korhonen-6man-prefix-properties-02 (work in 687 progress), July 2013. 689 [I-D.wakikawa-netext-pmip-cp-up-separation] 690 Wakikawa, R., Pazhyannur, R., and S. Gundavelli, 691 "Separation of Control and User Plane for Proxy Mobile 692 IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00 693 (work in progress), July 2013. 695 [I-D.yokota-dmm-scenario] 696 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 697 scenarios for Distributed Mobility Management", 698 draft-yokota-dmm-scenario-00 (work in progress), 699 October 2010. 701 [Paper-Distributed.Centralized.Mobility] 702 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 703 or Centralized Mobility", Proceedings of Global 704 Communications Conference (GlobeCom), December 2009. 706 [Paper-Distributed.Dynamic.Mobility] 707 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 708 Dynamic Mobility Management Scheme Designed for Flat IP 709 Architectures", Proceedings of 3rd International 710 Conference on New Technologies, Mobility and Security 711 (NTMS), 2008. 713 [Paper-Distributed.Mobility.MIP] 714 Chan, H., "Distributed Mobility Management with Mobile 715 IP", Proceedings of IEEE International Communication 716 Conference (ICC) Workshop on Telecommunications: from 717 Research to Standards, June 2012. 719 [Paper-Distributed.Mobility.PMIP] 720 Chan, H., "Proxy Mobile IP with Distributed Mobility 721 Anchors", Proceedings of GlobeCom Workshop on Seamless 722 Wireless Mobility, December 2010. 724 [Paper-Distributed.Mobility.Review] 725 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 726 "Distributed and Dynamic Mobility Management in Mobile 727 Internet: Current Approaches and Issues", Journal of 728 Communications, vol. 6, no. 1, pp. 4-15, February 2011. 730 [Paper-Distributed.Mobility.SAE] 731 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 732 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 733 Proceedings of the 19th International Symposium on 734 Personal, Indoor and Mobile Radio Communications (PIMRC), 735 2008. 737 [Paper-Locating.User] 738 Kirby, G., "Locating the User", Communication 739 International, 1995. 741 [Paper-Migrating.Home.Agents] 742 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 743 Agents Towards Internet-scale Mobility Deployments", 744 Proceedings of the ACM 2nd CoNEXT Conference on Future 745 Networking Technologies, December 2006. 747 [Paper-Mobile.Data.Offloading] 748 Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile 749 Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 750 2010, 2010. 752 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 753 RFC 3753, June 2004. 755 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 756 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 758 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 759 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 760 Management", RFC 5380, October 2008. 762 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 763 RFC 5944, November 2010. 765 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 766 Deployment for Multicast Listener Support in Proxy Mobile 767 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 769 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 770 in IPv6", RFC 6275, July 2011. 772 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 773 Support in the Internet", RFC 6301, July 2011. 775 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 777 Dutta, "Localized Routing for Proxy Mobile IPv6", 778 RFC 6705, September 2012. 780 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 781 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 782 Mobile IPv6", RFC 6909, April 2013. 784 [TS.23.401] 785 3GPP, "General Packet Radio Service (GPRS) enhancements 786 for Evolved Universal Terrestrial Radio Access Network 787 (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. 789 [TS.29303] 790 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 791 TR 23.303 11.2.0, September 2012. 793 Authors' Addresses 795 H Anthony Chan (editor) 796 Huawei Technologies 797 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 798 Email: h.a.chan@ieee.org 800 Dapeng Liu 801 China Mobile 802 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 803 Email: liudapeng@chinamobile.com 805 Pierrick Seite 806 Orange 807 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 808 Email: pierrick.seite@orange.com 810 Hidetoshi Yokota 811 KDDI Lab 812 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 813 Email: yokota@kddilabs.jp 814 Jouni Korhonen 815 Broadcom Communications 816 Porkkalankatu 24, FIN-00180 Helsinki, Finland 817 Email: jouni.nospam@gmail.com