idnits 2.17.1 draft-ietf-dmm-requirements-10.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 633 has weird spacing: '...enarios for D...' == Line 646 has weird spacing: '...ference on Ne...' == Line 657 has weird spacing: '...orkshop on Se...' == Line 662 has weird spacing: '...agement in Mo...' == Line 665 has weird spacing: '...orkshop on Se...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A DMM solution MUST not introduce new security risks or amplify existing security risks against which the existing security mechanisms/protocols cannot offer sufficient protection. -- The document date (November 7, 2013) is 3823 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.wakikawa-netext-pmip-cp-up-separtion' is mentioned on line 325, but not defined == Unused Reference: 'I-D.bhandari-dhc-class-based-prefix' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'I-D.wakikawa-netext-pmip-cp-up-separation' is defined on line 625, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 11 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: May 11, 2014 D. Liu 6 China Mobile 7 P. Seite 8 Orange 9 H. Yokota 10 KDDI Lab 11 J. Korhonen 12 Renesas Mobile 13 November 7, 2013 15 Requirements for Distributed Mobility Management 16 draft-ietf-dmm-requirements-10 18 Abstract 20 This document defines the requirements for Distributed Mobility 21 Management (DMM). The hierarchical structure in traditional wireless 22 networks has led primarily to centralized deployment models. As some 23 wireless networks are evolving away from the hierarchical structure, 24 such as in moving the content delivery servers closer to the users, a 25 distributed model for mobility 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 May 11, 2014. 50 Copyright Notice 52 Copyright (c) 2013 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 . . . . . . . . . . . . . . 6 69 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Centralized versus distributed mobility management . . . . . . 7 71 3.1. Centralized mobility management . . . . . . . . . . . . . 7 72 3.2. Distributed mobility management . . . . . . . . . . . . . 8 73 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 76 5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 77 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 78 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 79 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.6. Security considerations . . . . . . . . . . . . . . . . . 13 81 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 In the past decade a fair number of mobility protocols have been 93 standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. 94 Although the protocols differ in terms of functions and associated 95 message formats, they all employ a mobility anchor to allow a mobile 96 node to remain reachable after it has moved to a different network. 97 The anchor point, among other tasks, ensures connectivity by 98 forwarding packets destined to, or sent from, the mobile node. It is 99 a centrally deployed mobility anchor in the sense that the deployed 100 architectures today have a small number of these anchors and the 101 traffic of millions of mobile nodes in an operator network are 102 typically managed by the same anchor. 104 Distributed mobility management (DMM) is an alternative to the above 105 centralized deployment. The background behind the interests to study 106 DMM are primarily in the following. 108 (1) Mobile users are, more than ever, consuming Internet content; 109 such traffic imposes new requirements on mobile core networks 110 for data traffic delivery. The presence of content providers 111 closer to Internet Service Providers (ISP) network requires 112 taking into account local Content Delivery Networks (CDNs) while 113 providing mobility services. Moreover, when the traffic demand 114 exceeds available capacity, service providers need to implement 115 new strategies such as selective IPv4 traffic offload (e.g. 116 [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through 117 alternative access networks (e.g. WLAN) [Paper- 118 Mobile.Data.Offloading]. A gateway selection mechanism also 119 takes the user proximity into account within EPC [TS.29303]. 120 These mechanisms were not pursued in the past owing to charging 121 and billing reasons. Assigning a gateway anchor node from a 122 visited network in roaming scenario has until recently been done 123 and are limited to voice services only. Charging and billing 124 require solutions beyond the mobility protocol. 126 Both traffic offloading and CDN mechanisms could benefit from 127 the development of mobile architectures with fewer levels of 128 routing hierarchy introduced into the data path by the mobility 129 management system. This trend towards so-called "flat networks" 130 works best for direct communications among peers in the same 131 geographical area. Distributed mobility management in a truly 132 flat mobile architecture would anchor the traffic closer to the 133 point of attachment of the user. 135 (2) Today's mobile networks present service providers with new 136 challenges. Mobility patterns indicate that mobile nodes often 137 remain attached to the same point of attachment for considerable 138 periods of time [Paper-Locating.User]. Specific IP mobility 139 management support is not required for applications that launch 140 and complete their sessions while the mobile node is connected 141 to the same point of attachment. However, currently, IP 142 mobility support is designed for always-on operation, 143 maintaining all parameters of the context for each mobile 144 subscriber for as long as they are connected to the network. 145 This can result in a waste of resources and unnecessary costs 146 for the service provider. Infrequent node mobility coupled with 147 application intelligence suggest that mobility support could be 148 provided selectively such as in [I-D.bhandari-dhc-class-based- 149 prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing 150 the amount of context maintained in the network. 152 In addition, considerations in the study of DMM are in the following. 154 (1) To optimize handovers from the perspective of mobile nodes, the 155 base protocols have been extended to efficiently handle packet 156 forwarding between the previous and new points of attachment. 157 These extensions are necessary when applications have stringent 158 requirements in terms of delay. Notions of localization and 159 distribution of local agents have been introduced to reduce 160 signaling overhead at the centralized routing anchor point 161 [Paper-Distributed.Centralized.Mobility]. Unfortunately, such 162 protocols have not been deployed today. 164 (2) Most existing mobility protocols have not been designed for 165 multiple-interface hosts which are capable to use multiple 166 interfaces simultaneously. Retrofitting the required 167 functionality can result in an unnecessary increase in the 168 protocol complexity. 170 (3) IP multicast support, including optimizations, have been 171 introduced as an effective transport method for multimedia data 172 delivery, but by "patching-up" procedure after completing the 173 design of reference mobility protocol, leading to network 174 inefficiency and non-optimal routing. 176 The distributed mobility management (DMM) charter addresses two 177 complementary aspects of mobility management procedures: the 178 distribution of mobility anchors in the data-plane towards a more 179 flat network and the selective activation/deactivation of mobility 180 protocol support as an enabler to distributed mobility management. 181 The former aims at positioning mobility anchors (e.g., HA, LMA) 182 closer to the user; ideally, mobility agents could be collocated with 183 the first-hop router. The latter, facilitated by the distribution of 184 mobility anchors, identifies when mobility support must be activated 185 and when sessions do not require mobility management support -- thus 186 reducing the amount of state information that must be maintained in 187 various mobility agents of the mobile network. It can then avoid the 188 unnecessary establishment of mechanisms to forward traffic from an 189 old to a new mobility anchor. 191 This document compares distributed mobility management with 192 centralized mobility management in Section 3. The problems that can 193 be addressed with DMM are summarized in Section 4. The mandatory 194 requirements as well as the optional requirements are given in 195 Section 5. Finally, security considerations are discussed in Section 196 6. 198 The problem statement and the use cases [I-D.yokota-dmm-scenario] can 199 be found in [Paper-Distributed.Mobility.Review]. 201 2. Conventions used in this document 203 2.1. Terminology 205 All the general mobility-related terms and their acronyms used in 206 this document are to be interpreted as defined in the Mobile IPv6 207 base specification [RFC6275], in the Proxy mobile IPv6 specification 208 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 209 terms include the following: mobile node (MN), correspondent node 210 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 211 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 212 as per [RFC3753]. 214 In addition, this draft introduces the following terms. 216 Centrally deployed mobility anchors 218 refer to the mobility management deployments in which there are 219 very few mobility anchors and the traffic of millions of mobile 220 nodes in an operator network are managed by the same anchor. 222 Centralized mobility management 224 makes use of centrally deployed mobility anchors. 226 Distributed mobility management 228 is not centralized so that traffic does not need to traverse 229 centrally deployed mobility anchors. 231 Flat mobile network 233 has few levels of routing hierarchy introduced into the data path 234 by the mobility management system. 236 Mobility context 238 is the collection of information required to provide mobility 239 management support for a given mobile node. 241 3. Centralized versus distributed mobility management 243 Mobility management functions may be implemented at different layers 244 of the protocol stack. At the IP (network) layer, mobility 245 management can be client-based or network-based. 247 An IP-layer mobility management protocol is typically based on the 248 principle of distinguishing between session identifier and routing 249 address and maintaining a mapping between the two. In Mobile IP, the 250 home address serves as the session identifier whereas the care-of- 251 address (CoA) takes the role of the routing address. The binding 252 between these two is maintained at the home agent (mobility anchor). 253 If packets addressed to the home address of a mobile node can be 254 continuously delivered to the node, then all sessions using that home 255 address are unaffected even though the routing address (CoA) changes. 257 The next two subsections explain centralized and distributed mobility 258 management functions in the network. 260 3.1. Centralized mobility management 262 In centralized mobility management, the mapping information between 263 the session identifier and the locator IP address of a mobile node 264 (MN) is kept at a single mobility anchor. At the same time, packets 265 destined to the MN are routed via this anchor. In other words, such 266 mobility management systems are centralized in both the control plane 267 and the data plane (mobile node IP traffic). 269 Many existing mobility management deployments make use of centralized 270 mobility anchoring in a hierarchical network architecture, as shown 271 in Figure 1. Examples of such centralized mobility anchors are the 272 home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 273 [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current 274 cellular networks such as the Third Generation Partnership Project 275 (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System 276 (EPS) networks employ centralized mobility management too. In 277 particular, the Gateway GPRS Support Node (GGSN), Serving GPRS 278 Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP 279 GPRS hierarchical network, and the Packet Data Network Gateway (P-GW) 280 and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors 281 in a hierarchy. 283 3G GPRS 3GPP EPS MIP/PMIP 284 +------+ +------+ +------+ 285 | GGSN | | P-GW | |HA/LMA| 286 +------+ +------+ +------+ 287 /\ /\ /\ 288 / \ / \ / \ 289 / \ / \ / \ 290 / \ / \ / \ 291 / \ / \ / \ 292 / \ / \ / \ 293 / \ / \ / \ 294 +------+ +------+ +------+ +------+ +------+ +------+ 295 | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG| 296 +------+ +------+ +------+ +------+ +------+ +------+ 297 /\ /\ 298 / \ / \ 299 / \ / \ 300 +---+ +---+ +---+ +---+ 301 |RNC| |RNC| |RNC| |RNC| 302 +---+ +---+ +---+ +---+ 304 Figure 1. Centralized mobility management. 306 3.2. Distributed mobility management 308 Mobility management functions may also be distributed to multiple 309 networks as shown in Figure 2, so that a mobile node in any of these 310 networks may be served by a nearby mobility function (MF). 312 +------+ +------+ +------+ +------+ 313 | MF | | MF | | MF | | MF | 314 +------+ +------+ +------+ +------+ 315 | 316 +----+ 317 | MN | 318 +----+ 320 Figure 2. Distributed mobility management. 322 Mobility management may be partially or fully distributed 323 [I-D.yokota-dmm-scenario]. In the former case only the data plane is 324 distributed, implicitly assuming separation of data and control 325 planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion]. 326 Fully distributed mobility management implies that both the data 327 plane and the control plane are distributed. While mobility 328 management can be distributed, it is not necessary for other 329 functions such as subscription management, subscription database, and 330 network access authentication to be similarly distributed. 332 A distributed mobility management scheme for a flat mobile network of 333 access nodes is proposed in [Paper-Distributed.Dynamic.Mobility]. 334 Its benefits over centralized mobility management are shown through 335 simulations in [Paper-Distributed.Centralized.Mobility]. Moreover, 336 the (re)use and extension of existing protocols in the design of both 337 fully distributed mobility management [Paper-Migrating.Home.Agents] 338 [Paper-Distributed.Mobility.SAE] and partially distributed mobility 339 management [Paper-Distributed.Mobility.PMIP] [Paper- 340 Distributed.Mobility.MIP] have been reported in the literature. 341 Therefore, before designing new mobility management protocols for a 342 future distributed architecture, it is recommended to first consider 343 whether existing mobility management protocols can be extended. 345 4. Problem Statement 347 The problems that can be addressed with DMM are summarized in the 348 following: 350 PS1: Non-optimal routes 352 Routing via a centralized anchor often results in non-optimal 353 routes, thereby increasing the end-to-end delay. The problem 354 is manifested, for example, when accessing a nearby server or 355 servers of a Content Delivery Network (CDN), or when receiving 356 locally available IP multicast or sending IP multicast packets. 357 (Existing route optimization is only a host-based solution. On 358 the other hand, localized routing with PMIPv6 [RFC6705] 359 addresses only a part of the problem where both the MN and the 360 CN are located in the PMIP domain and attached to a MAG, and is 361 not applicable when the CN is outside the PMIP domain or does 362 not behave like an MN.) 364 PS2: Divergence from other evolutionary trends in network 365 architectures such as distribution of content delivery. 367 Centralized mobility management can become non-optimal with a 368 flat network architecture. 370 PS3: Low scalability of centralized tunnel management and mobility 371 context maintenance 373 Setting up tunnels through a central anchor and maintaining 374 mobility context for each MN usually requires more concentrated 375 resources in a centralized design, thus reducing scalability. 376 Distributing the tunnel maintenance function and the mobility 377 context maintenance function among different network entities 378 with proper signaling protocol design can increase scalability. 380 PS4: Single point of failure and attack 382 Centralized anchoring designs may be more vulnerable to single 383 points of failures and attacks than a distributed system. The 384 impact of a successful attack on a system with centralized 385 mobility management can be far greater as well. 387 PS5: Unnecessary mobility support to nodes that do not need it 389 IP mobility support is not always required, and not every 390 parameter of mobility context is always used. For example, 391 some applications do not need a stable IP address during a 392 handover to maintain session continuity. Sometimes, the entire 393 application session runs while the terminal does not change the 394 point of attachment. Besides, some sessions, e.g. SIP-based 395 sessions, can handle mobility at the application layer and 396 hence do not need IP mobility support; it is then more 397 efficient to deactivate IP mobility support for such sessions. 399 PS6: (Related problem) Mobility signaling overhead with peer-to-peer 400 communication 402 Wasting resources when mobility signaling (e.g., maintenance of 403 the tunnel, keep alive signaling, etc.) is not turned off for 404 peer-to-peer communication. Peer-to-peer communications have 405 particular traffic patterns that often do not benefit from 406 mobility support from the network. Thus, the associated 407 mobility support signaling (e.g., maintenance of the tunnel, 408 keep alive signaling, etc.) wastes network resources for no 409 application gain. 411 PS7: (Related problem) Deployment with multiple mobility solutions 413 There are already many variants and extensions of MIP. 414 Deployment of new mobility management solutions can be 415 challenging, and debugging difficult, when they must co-exist 416 with solutions already in the field. 418 PS8: Duplicate multicast traffic 420 IP multicast distribution over architectures using IP mobility 421 solutions (e.g., [RFC6224]) may lead to convergence of 422 duplicated multicast subscriptions towards the downstream 423 tunnel entity (e.g. MAG in PMIPv6). Concretely, when 424 multicast subscription for individual mobile nodes is coupled 425 with mobility tunnels (e.g. PMIPv6 tunnel), duplicate 426 multicast subscription(s) is prone to be received through 427 different upstream paths. This problem may also exist or be 428 more severe in a distributed mobility environment. 430 5. Requirements 432 After comparing distributed mobility management against centralized 433 deployment in Section 3, this section identifies the following 434 requirements: 436 5.1. Distributed processing 438 REQ1: Distributed processing 440 IP mobility, network access and routing solutions provided by 441 DMM MUST enable distributed processing for mobility management 442 so that traffic can avoid traversing single mobility anchor 443 far from the optimal route. 445 Motivation: This requirement is motivated by current trends in 446 network evolution: (a) it is cost- and resource-effective to 447 cache and distribute content by combining distributed mobility 448 anchors with caching systems (e.g., CDN); (b) the 449 significantly larger number of mobile nodes and flows call for 450 improved scalability; (c) single points of failure are avoided 451 in a distributed system; (d) threats against centrally 452 deployed anchors, e.g., home agent and local mobility anchor, 453 are mitigated in a distributed system. 455 This requirement addresses the problems PS1, PS2, PS3, and PS4 456 described in Section 4. 458 5.2. Transparency to Upper Layers when needed 460 REQ2: Transparency to Upper Layers when needed 462 DMM solutions MUST provide transparent mobility support above 463 the IP layer when needed. Such transparency is needed, for 464 example, when, upon change of point of attachment to the 465 network, an application flow cannot cope with a change in the 466 IP address. However, it is not always necessary to maintain a 467 stable home IP address or prefix for every application or at 468 all times for a mobile node. 470 Motivation: The motivation of this requirement is to enable 471 more efficient routing and more efficient use of network 472 resources by selecting an IP address or prefix according to 473 whether mobility support is needed and by not maintaining 474 context at the mobility anchor when there is no such need. 476 This requirement addresses the problem PS5 as well as the related 477 problem PS6 stated in Section 4. 479 5.3. IPv6 deployment 481 REQ3: IPv6 deployment 483 DMM solutions SHOULD target IPv6 as the primary deployment 484 environment and SHOULD NOT be tailored specifically to support 485 IPv4, in particular in situations where private IPv4 addresses 486 and/or NATs are used. 488 Motivation: This requirement conforms to the general 489 orientation of IETF work. DMM deployment is foreseen in mid- 490 to long-term horizon, when IPv6 is expected to be far more 491 common than today. 493 This requirement avoids the unnecessarily complexity in solving the 494 problems in Section 4 for IPv4, which will not be able to use some of 495 the IPv6-specific features. 497 5.4. Existing mobility protocols 499 REQ4: Existing mobility protocols 501 A DMM solution SHOULD first consider reusing and extending 502 IETF-standardized protocols before specifying new protocols. 504 Motivation: Reuse of existing IETF work is more efficient and 505 less error-prone. 507 This requirement attempts to avoid the need of new protocols 508 development and therefore their potential problems of being time- 509 consuming and error-prone. 511 5.5. Co-existence 513 REQ5: Co-existence with deployed networks and hosts 515 The DMM solution MUST be able to co-exist with existing 516 network deployments and end hosts. For example, depending on 517 the environment in which DMM is deployed, DMM solutions may 518 need to be compatible with other deployed mobility protocols 519 or may need to co-exist with a network or mobile hosts/routers 520 that do not support DMM protocols. The mobile node may also 521 move between different access networks, where some of them may 522 support neither DMM nor another mobility protocol. 523 Furthermore, a DMM solution SHOULD work across different 524 networks, possibly operated as separate administrative 525 domains, when allowed by the trust relationship between them. 527 Motivation: (a) to preserve backwards compatibility so that 528 existing networks and hosts are not affected and continue to 529 function as usual, and (b) enable inter-domain operation if 530 desired. 532 This requirement addresses the related problem PS7 described in 533 Section 4. 535 5.6. Security considerations 537 REQ6: Security considerations 539 A DMM solution MUST not introduce new security risks or 540 amplify existing security risks against which the existing 541 security mechanisms/protocols cannot offer sufficient 542 protection. 544 Motivation: Various attacks such as impersonation, denial of 545 service, man-in-the-middle attacks, and so on, may be launched 546 in a DMM deployment. For instance, an illegitimate node may 547 attempt to access a network providing DMM. Another example is 548 that a malicious node can forge a number of signaling messages 549 thus redirecting traffic from its legitimate path. 550 Consequently, the specific node is under a denial of service 551 attack, whereas other nodes do not receive their traffic. 552 Accordingly, security mechanisms/protocols providing access 553 control, integrity, authentication, authorization, 554 confidentiality, etc. can be used to protect the DMM entities 555 as they are already used to protect against existing networks 556 and existing mobility protocols defined in IETF. 558 This requirement prevents a DMM solution from introducing 559 uncontrollable problems of potentially insecure mobility management 560 protocols which make deployment infeasible because platforms 561 conforming to the protocols are at risk for data loss and numerous 562 other dangers, including financial harm to the users. 564 5.7. Multicast 566 REQ7: Multicast considerations 568 DMM SHOULD consider multicast early so that solutions can be 569 developed not only to provide IP mobility support when it is 570 needed, but also to avoid network inefficiency issues in 571 multicast traffic delivery (such as duplicate multicast 572 subscriptions towards the downstream tunnel entities). The 573 multicast solutions should therefore avoid restricting the 574 management of all IP multicast traffic to a single host 575 through a dedicated (tunnel) interface on multicast-capable 576 access routers. 578 Motivation: Existing multicast deployment have been introduced 579 after completing the design of the reference mobility 580 protocol, then optimization and extensions have been followed 581 by "patching-up" procedure, thus leading to network 582 inefficiency and non-optimal routing. The multicast solutions 583 should therefore be required to consider efficiency nature in 584 multicast traffic delivery. 586 This requirement addresses the problems PS1 and PS8 described in 587 Section 4. 589 6. Security Considerations 591 Please refer to the discussion under Security requirement in Section 592 5.6. 594 7. IANA Considerations 596 None 598 8. Co-authors and Contributors 600 This problem statement document is a joint effort among the numerous 601 participants. Each individual has made significant contributions to 602 this work and have been listed as co-authors. 604 9. References 606 9.1. Normative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 9.2. Informative References 613 [I-D.bhandari-dhc-class-based-prefix] 614 Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H., 615 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 616 based prefix", draft-bhandari-dhc-class-based-prefix-05 617 (work in progress), July 2013. 619 [I-D.korhonen-6man-prefix-properties] 620 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 621 Liu, "IPv6 Prefix Properties", 622 draft-korhonen-6man-prefix-properties-02 (work in 623 progress), July 2013. 625 [I-D.wakikawa-netext-pmip-cp-up-separation] 626 Wakikawa, R., Pazhyannur, R., and S. Gundavelli, 627 "Separation of Control and User Plane for Proxy Mobile 628 IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00 629 (work in progress), July 2013. 631 [I-D.yokota-dmm-scenario] 632 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 633 scenarios for Distributed Mobility Management", 634 draft-yokota-dmm-scenario-00 (work in progress), 635 October 2010. 637 [Paper-Distributed.Centralized.Mobility] 638 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 639 or Centralized Mobility", Proceedings of Global 640 Communications Conference (GlobeCom), December 2009. 642 [Paper-Distributed.Dynamic.Mobility] 643 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 644 Dynamic Mobility Management Scheme Designed for Flat IP 645 Architectures", Proceedings of 3rd International 646 Conference on New Technologies, Mobility and Security 647 (NTMS), 2008. 649 [Paper-Distributed.Mobility.MIP] 650 Chan, H., "Distributed Mobility Management with Mobile 651 IP", Proceedings of IEEE International Communication 652 Conference (ICC) Workshop on Telecommunications: from 653 Research to Standards, June 2012. 655 [Paper-Distributed.Mobility.PMIP] 656 Chan, H., "Proxy Mobile IP with Distributed Mobility 657 Anchors", Proceedings of GlobeCom Workshop on Seamless 658 Wireless Mobility, December 2010. 660 [Paper-Distributed.Mobility.Review] 661 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 662 "Distributed and Dynamic Mobility Management in Mobile 663 Internet: Current Approaches and Issues, Journal of 664 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 665 Proceedings of GlobeCom Workshop on Seamless Wireless 666 Mobility, February 2011. 668 [Paper-Distributed.Mobility.SAE] 669 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 670 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 671 Proceedings of the 19th International Symposium on 672 Personal, Indoor and Mobile Radio Communications (PIMRC), 673 2008. 675 [Paper-Locating.User] 676 Kirby, G., "Locating the User", Communication 677 International, 1995. 679 [Paper-Migrating.Home.Agents] 680 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 681 Agents Towards Internet-scale Mobility Deployments", 682 Proceedings of the ACM 2nd CoNEXT Conference on Future 683 Networking Technologies, December 2006. 685 [Paper-Mobile.Data.Offloading] 686 Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile 687 Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 688 2010, 2010. 690 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 691 RFC 3753, June 2004. 693 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 694 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 696 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 697 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 698 Management", RFC 5380, October 2008. 700 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 701 RFC 5944, November 2010. 703 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 704 Deployment for Multicast Listener Support in Proxy Mobile 705 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 707 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 708 in IPv6", RFC 6275, July 2011. 710 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 711 Support in the Internet", RFC 6301, July 2011. 713 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 714 Dutta, "Localized Routing for Proxy Mobile IPv6", 715 RFC 6705, September 2012. 717 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 718 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 719 Mobile IPv6", RFC 6909, April 2013. 721 [TS.23.401] 722 3GPP, "General Packet Radio Service (GPRS) enhancements 723 for Evolved Universal Terrestrial Radio Access Network 724 (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. 726 [TS.29303] 727 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 728 TR 23.303 11.2.0, September 2012. 730 Authors' Addresses 732 H Anthony Chan (editor) 733 Huawei Technologies (more co-authors on P. 17) 734 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 735 Email: h.a.chan@ieee.org 737 Dapeng Liu 738 China Mobile 739 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 740 Email: liudapeng@chinamobile.com 741 Pierrick Seite 742 Orange 743 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 744 Email: pierrick.seite@orange.com 746 Hidetoshi Yokota 747 KDDI Lab 748 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 749 Email: yokota@kddilabs.jp 751 Jouni Korhonen 752 Renesas Mobile 753 Porkkalankatu 24, FIN-00180 Helsinki, Finland 754 Email: jouni.korhonen@nsn.com 755 - 756 Charles E. Perkins 757 Huawei Technologies 758 Email: charliep@computer.org 759 - 760 Melia Telemaco 761 Alcatel-Lucent Bell Labs 762 Email: telemaco.melia@alcatel-lucent.com 763 - 764 Elena Demaria 765 Telecom Italia 766 via G. Reiss Romoli, 274, TORINO, 10148, Italy 767 Email: elena.demaria@telecomitalia.it 768 - 769 Jong-Hyouk Lee 770 Sangmyung University 771 Email: hurryon@gmail.com 772 - 773 Kostas Pentikousis 774 EICT GmbH 775 Email: k.pentikousis@eict.de 776 - 777 Tricci So 778 ZTE 779 Email: tso@zteusa.com 780 - 781 Carlos J. Bernardos 782 Universidad Carlos III de Madrid 783 Av. Universidad, 30, Leganes, Madrid 28911, Spain 784 Email: cjbc@it.uc3m.es 785 - 786 Peter McCann 787 Huawei Technologies 788 Email: PeterMcCann@huawei.com 789 - 790 Seok Joo Koh 791 Kyungpook National University, Korea 792 Email: sjkoh@knu.ac.kr 793 - 794 Wen Luo 795 ZTE 796 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 797 Email: luo.wen@zte.com.cn 798 - 799 Sri Gundavelli 800 Cisco 801 sgundave@cisco.com 802 - 803 Marco Liebsch 804 NEC Laboratories Europe 805 Email: liebsch@neclab.eu 806 - 807 Carl Williams 808 MCSR Labs 809 Email: carlw@mcsr-labs.org 810 - 811 Seil Jeon 812 Instituto de Telecomunicacoes, Aveiro 813 Email: seiljeon@av.it.pt 814 - 815 Sergio Figueiredo 816 Universidade de Aveiro 817 Email: sfigueiredo@av.it.pt 818 - 819 Stig Venaas 820 Email: stig@venaas.com 821 - 822 Luis Miguel Contreras Murillo 823 Telefonica I+D 824 Email: lmcm@tid.es 825 - 826 Juan Carlos Zuniga 827 InterDigital 828 Email: JuanCarlos.Zuniga@InterDigital.com 829 - 830 Alexandru Petrescu 831 Email: alexandru.petrescu@gmail.com 832 - 833 Georgios Karagiannis 834 University of Twente 835 Email: g.karagiannis@utwente.nl 836 - 837 Julien Laganier 838 Juniper 839 jlaganier@juniper.net 840 - 841 Wassim Michel Haddad 842 Ericsson 843 Wassam.Haddad@ericsson.com 844 - 845 Dirk von Hugo 846 Deutsche Telekom Laboratories 847 Dirk.von-Hugo@telekom.de 848 - 849 Ahmad Muhanna 850 Award Solutions 851 amuhanna@awardsolutions.com 852 - 853 Byoung-Jo Kim 854 ATT Labs 855 macsbug@research.att.com 856 - 857 Hassan Ali-Ahmad 858 Orange 859 hassan.aliahmad@orange.com 860 - 861 Alper Yegin 862 Samsung 863 alper.yegin@partner.samsung.com 864 -