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