idnits 2.17.1 draft-ietf-dmm-requirements-08.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 627 has weird spacing: '...enarios for D...' == Line 640 has weird spacing: '...ference on Ne...' == Line 651 has weird spacing: '...orkshop on Se...' == Line 656 has weird spacing: '...agement in Mo...' == Line 659 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 (September 26, 2013) is 3866 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 324, but not defined == Unused Reference: 'I-D.wakikawa-netext-pmip-cp-up-separation' is defined on line 619, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 10 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: March 30, 2014 D. Liu 6 China Mobile 7 P. Seite 8 Orange 9 H. Yokota 10 KDDI Lab 11 J. Korhonen 12 Renesas Mobile 13 September 26, 2013 15 Requirements for Distributed Mobility Management 16 draft-ietf-dmm-requirements-08 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 March 30, 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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . 15 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 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, thus reducing the amount of context 149 maintained in the network. 151 In addition, considerations in the study of DMM are in the following. 153 (1) To optimize handovers from the perspective of mobile nodes, the 154 base protocols have been extended to efficiently handle packet 155 forwarding between the previous and new points of attachment. 156 These extensions are necessary when applications have stringent 157 requirements in terms of delay. Notions of localization and 158 distribution of local agents have been introduced to reduce 159 signaling overhead at the centralized routing anchor point 160 [Paper-Distributed.Centralized.Mobility]. Unfortunately, such 161 protocols have not been deployed today. 163 (2) Most existing mobility protocols have not been designed for 164 multiple-interface hosts which are capable to use multiple 165 interfaces simultaneously. Retrofitting the required 166 functionality can result in an unnecessary increase in the 167 protocol complexity. 169 (3) IP multicast support, including optimizations, have been 170 introduced as an effective transport method for multimedia data 171 delivery, but by "patching-up" procedure after completing the 172 design of reference mobility protocol, leading to network 173 inefficiency and non-optimal routing. 175 The distributed mobility management (DMM) charter addresses two 176 complementary aspects of mobility management procedures: the 177 distribution of mobility anchors in the data-plane towards a more 178 flat network and the selective activation/deactivation of mobility 179 protocol support as an enabler to distributed mobility management. 180 The former aims at positioning mobility anchors (e.g., HA, LMA) 181 closer to the user; ideally, mobility agents could be collocated with 182 the first-hop router. The latter, facilitated by the distribution of 183 mobility anchors, identifies when mobility support must be activated 184 and when sessions do not require mobility management support -- thus 185 reducing the amount of state information that must be maintained in 186 various mobility agents of the mobile network. It can then avoid the 187 unnecessary establishment of mechanisms to forward traffic from an 188 old to a new mobility anchor. 190 This document compares distributed mobility management with 191 centralized mobility management in Section 3. The problems that can 192 be addressed with DMM are summarized in Section 4. The mandatory 193 requirements as well as the optional requirements are given in 194 Section 5. Finally, security considerations are discussed in Section 195 6. 197 The problem statement and the use cases [I-D.yokota-dmm-scenario] can 198 be found in [Paper-Distributed.Mobility.Review]. 200 2. Conventions used in this document 202 2.1. Terminology 204 All the general mobility-related terms and their acronyms used in 205 this document are to be interpreted as defined in the Mobile IPv6 206 base specification [RFC6275], in the Proxy mobile IPv6 specification 207 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 208 terms include the following: mobile node (MN), correspondent node 209 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 210 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 211 as per [RFC3753]. 213 In addition, this draft introduces the following terms. 215 Centrally deployed mobility anchors 217 refer to the mobility management deployments in which there are 218 very few mobility anchors and the traffic of millions of mobile 219 nodes in an operator network are managed by the same anchor. 221 Centralized mobility management 223 makes use of centrally deployed mobility anchors. 225 Distributed mobility management 227 is not centralized so that traffic does not need to traverse 228 centrally deployed mobility anchors. 230 Flat mobile network 232 has few levels of routing hierarchy introduced into the data path 233 by the mobility management system. 235 Mobility context 237 is the collection of information required to provide mobility 238 management support for a given mobile node. 240 3. Centralized versus distributed mobility management 242 Mobility management functions may be implemented at different layers 243 of the protocol stack. At the IP (network) layer, mobility 244 management can be client-based or network-based. 246 An IP-layer mobility management protocol is typically based on the 247 principle of distinguishing between session identifier and routing 248 address and maintaining a mapping between the two. In Mobile IP, the 249 home address serves as the session identifier whereas the care-of- 250 address (CoA) takes the role of the routing address. The binding 251 between these two is maintained at the home agent (mobility anchor). 252 If packets addressed to the home address of a mobile node can be 253 continuously delivered to the node, then all sessions using that home 254 address are unaffected even though the routing address (CoA) changes. 256 The next two subsections explain centralized and distributed mobility 257 management functions in the network. 259 3.1. Centralized mobility management 261 In centralized mobility management, the mapping information between 262 the session identifier and the locator IP address of a mobile node 263 (MN) is kept at a single mobility anchor. At the same time, packets 264 destined to the MN are routed via this anchor. In other words, such 265 mobility management systems are centralized in both the control plane 266 and the data plane (mobile node IP traffic). 268 Many existing mobility management deployments make use of centralized 269 mobility anchoring in a hierarchical network architecture, as shown 270 in Figure 1. Examples of such centralized mobility anchors are the 271 home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 272 [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current 273 cellular networks such as the Third Generation Partnership Project 274 (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System 275 (EPS) networks employ centralized mobility management too. In 276 particular, the Gateway GPRS Support Node (GGSN), Serving GPRS 277 Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP 278 GPRS hierarchical network, and the Packet Data Network Gateway (P-GW) 279 and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors 280 in a hierarchy. 282 3G GPRS 3GPP EPS MIP/PMIP 283 +------+ +------+ +------+ 284 | GGSN | | P-GW | |HA/LMA| 285 +------+ +------+ +------+ 286 /\ /\ /\ 287 / \ / \ / \ 288 / \ / \ / \ 289 / \ / \ / \ 290 / \ / \ / \ 291 / \ / \ / \ 292 / \ / \ / \ 293 +------+ +------+ +------+ +------+ +------+ +------+ 294 | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG| 295 +------+ +------+ +------+ +------+ +------+ +------+ 296 /\ /\ 297 / \ / \ 298 / \ / \ 299 +---+ +---+ +---+ +---+ 300 |RNC| |RNC| |RNC| |RNC| 301 +---+ +---+ +---+ +---+ 303 Figure 1. Centralized mobility management. 305 3.2. Distributed mobility management 307 Mobility management functions may also be distributed to multiple 308 networks as shown in Figure 2, so that a mobile node in any of these 309 networks may be served by a nearby mobility function (MF). 311 +------+ +------+ +------+ +------+ 312 | MF | | MF | | MF | | MF | 313 +------+ +------+ +------+ +------+ 314 | 315 +----+ 316 | MN | 317 +----+ 319 Figure 2. Distributed mobility management. 321 Mobility management may be partially or fully distributed 322 [I-D.yokota-dmm-scenario]. In the former case only the data plane is 323 distributed, implicitly assuming separation of data and control 324 planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion]. 325 Fully distributed mobility management implies that both the data 326 plane and the control plane are distributed. While mobility 327 management can be distributed, it is not necessary for other 328 functions such as subscription management, subscription database, and 329 network access authentication to be similarly distributed. 331 A distributed mobility management scheme for a flat mobile network of 332 access nodes is proposed in [Paper-Distributed.Dynamic.Mobility]. 333 Its benefits over centralized mobility management are shown through 334 simulations in [Paper-Distributed.Centralized.Mobility]. Moreover, 335 the (re)use and extension of existing protocols in the design of both 336 fully distributed mobility management [Paper-Migrating.Home.Agents] 337 [Paper-Distributed.Mobility.SAE] and partially distributed mobility 338 management [Paper-Distributed.Mobility.PMIP] [Paper- 339 Distributed.Mobility.MIP] have been reported in the literature. 340 Therefore, before designing new mobility management protocols for a 341 future distributed architecture, it is recommended to first consider 342 whether existing mobility management protocols can be extended. 344 4. Problem Statement 346 The problems that can be addressed with DMM are summarized in the 347 following: 349 PS1: Non-optimal routes 351 Routing via a centralized anchor often results in non-optimal 352 routes, thereby increasing the end-to-end delay. The problem 353 is manifested, for example, when accessing a local server or 354 servers of a Content Delivery Network (CDN), or when receiving 355 locally available IP multicast or sending IP multicast packets. 357 PS2: Divergence from other evolutionary trends in network 358 architectures such as distribution of content delivery. 360 Centralized mobility management can become non-optimal with a 361 flat network architecture. 363 PS3: Low scalability of centralized tunnel management and mobility 364 context maintenance 366 Setting up tunnels through a central anchor and maintaining 367 mobility context for each MN usually requires more concentrated 368 resources in a centralized design, thus reducing scalability. 369 Distributing the tunnel maintenance function and the mobility 370 context maintenance function among different network entities 371 with proper signaling protocol design can increase scalability. 373 PS4: Single point of failure and attack 375 Centralized anchoring designs may be more vulnerable to single 376 points of failures and attacks than a distributed system. The 377 impact of a successful attack on a system with centralized 378 mobility management can be far greater as well. 380 PS5: Unnecessary mobility support to nodes that do not need it 382 IP mobility support is not always required, and not every 383 parameter of mobility context is always used. For example, 384 some applications do not need a stable IP address during a 385 handover to maintain session continuity. Sometimes, the entire 386 application session runs while the terminal does not change the 387 point of attachment. Besides, some sessions, e.g. SIP-based 388 sessions, can handle mobility at the application layer and 389 hence do not need IP mobility support; it is then more 390 efficient to deactivate IP mobility support for such sessions. 392 PS6: (Related problem) Mobility signaling overhead with peer-to-peer 393 communication 395 Wasting resources when mobility signaling (e.g., maintenance of 396 the tunnel, keep alive signaling, etc.) is not turned off for 397 peer-to-peer communication. Peer-to-peer communications have 398 particular traffic patterns that often do not benefit from 399 mobility support from the network. Thus, the associated 400 mobility support signaling (e.g., maintenance of the tunnel, 401 keep alive signaling, etc.) wastes network resources for no 402 application gain. 404 PS7: (Related problem) Deployment with multiple mobility solutions 406 There are already many variants and extensions of MIP. 407 Deployment of new mobility management solutions can be 408 challenging, and debugging difficult, when they must co-exist 409 with solutions already in the field. 411 PS8: Duplicate multicast traffic 413 IP multicast distribution over architectures using IP mobility 414 solutions (e.g. RFC6224) may lead to convergence of duplicated 415 multicast subscriptions towards the downstream tunnel entity 416 (e.g. MAG in PMIPv6). Concretely, when multicast subscription 417 for individual mobile nodes is coupled with mobility tunnels 418 (e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is 419 prone to be received through different upstream paths. This 420 problem may also exist or be more severe in a distributed 421 mobility environment. 423 5. Requirements 425 After comparing distributed mobility management against centralized 426 deployment in Section 3, this section identifies the following 427 requirements: 429 5.1. Distributed processing 431 REQ1: Distributed processing 433 IP mobility, network access and routing solutions provided by 434 DMM MUST enable distributed processing for mobility management 435 so that traffic does not need to traverse centrally deployed 436 mobility anchors and thereby avoid non-optimal routes. 438 Motivation: This requirement is motivated by current trends in 439 network evolution: (a) it is cost- and resource-effective to 440 cache and distribute content by combining distributed mobility 441 anchors with caching systems (e.g., CDN); (b) the 442 significantly larger number of mobile nodes and flows call for 443 improved scalability; (c) single points of failure are avoided 444 in a distributed system; (d) threats against centrally 445 deployed anchors, e.g., home agent and local mobility anchor, 446 are mitigated in a distributed system. 448 This requirement addresses the problems PS1, PS2, PS3, and PS4 449 described in Section 4. (Existing route optimization is only a host- 450 based solution. On the other hand, localized routing with PMIPv6 451 addresses only a part of the problem where both the MN and the CN are 452 located in the PMIP domain and attached to a MAG, and is not 453 applicable when the CN is outside the PMIP domain.) 455 5.2. Transparency to Upper Layers when needed 457 REQ2: Transparency to Upper Layers when needed 459 DMM solutions MUST provide transparent mobility support above 460 the IP layer when needed. Such transparency is needed, for 461 example, when, upon change of point of attachment to the 462 network, an application flow cannot cope with a change in the 463 IP address. However, it is not always necessary to maintain a 464 stable home IP address or prefix for every application or at 465 all times for a mobile node. 467 Motivation: The motivation of this requirement is to enable 468 more efficient routing and more efficient use of network 469 resources by selecting an IP address or prefix according to 470 whether mobility support is needed and by not maintaining 471 context at the mobility anchor when there is no such need. 473 This requirement addresses the problem PS5 as well as the related 474 problem PS6 stated in Section 4. 476 5.3. IPv6 deployment 478 REQ3: IPv6 deployment 480 DMM solutions SHOULD target IPv6 as the primary deployment 481 environment and SHOULD NOT be tailored specifically to support 482 IPv4, in particular in situations where private IPv4 addresses 483 and/or NATs are used. 485 Motivation: This requirement conforms to the general 486 orientation of IETF work. DMM deployment is foreseen in mid- 487 to long-term horizon, when IPv6 is expected to be far more 488 common than today. 490 This requirement avoids the unnecessarily complexity in solving the 491 problems in Section 4 for IPv4, which will not be able to use some of 492 the IPv6-specific features. 494 5.4. Existing mobility protocols 496 REQ4: Existing mobility protocols 498 A DMM solution SHOULD first consider reusing and extending 499 IETF-standardized protocols before specifying new protocols. 501 Motivation: Reuse of existing IETF work is more efficient and 502 less error-prone. 504 This requirement attempts to avoid the need of new protocols 505 development and therefore their potential problems of being time- 506 consuming and error-prone. 508 5.5. Co-existence 509 REQ5: Co-existence with deployed networks and hosts 511 The DMM solution MUST be able to co-exist with existing 512 network deployments and end hosts. For example, depending on 513 the environment in which DMM is deployed, DMM solutions may 514 need to be compatible with other deployed mobility protocols 515 or may need to co-exist with a network or mobile hosts/routers 516 that do not support DMM protocols. The mobile node may also 517 move between different access networks, where some of them may 518 support neither DMM nor another mobility protocol. 519 Furthermore, a DMM solution SHOULD work across different 520 networks, possibly operated as separate administrative 521 domains, when allowed by the trust relationship between them. 523 Motivation: (a) to preserve backwards compatibility so that 524 existing networks and hosts are not affected and continue to 525 function as usual, and (b) enable inter-domain operation if 526 desired. 528 This requirement addresses the related problem PS7 described in 529 Section 4. 531 5.6. Security considerations 533 REQ6: Security considerations 535 A DMM solution MUST not introduce new security risks or 536 amplify existing security risks against which the existing 537 security mechanisms/protocols cannot offer sufficient 538 protection. 540 Motivation: Various attacks such as impersonation, denial of 541 service, man-in-the-middle attacks, and so on, may be launched 542 in a DMM deployment. For instance, an illegitimate node may 543 attempt to access a network providing DMM. Another example is 544 that a malicious node can forge a number of signaling messages 545 thus redirecting traffic from its legitimate path. 546 Consequently, the specific node is under a denial of service 547 attack, whereas other nodes do not receive their traffic. 548 Accordingly, security mechanisms/protocols providing access 549 control, integrity, authentication, authorization, 550 confidentiality, etc. can be used to protect the DMM entities 551 as they are already used to protect against existing networks 552 and existing mobility protocols defined in IETF. In addition, 553 end-to-end security measures between communicating nodes may 554 already be used when deploying existing mobility protocols 555 where the signaling messages travel over the Internet. For 556 instance, EAP-based authentication can be used for network 557 access security, while IPsec can be used for end-to-end 558 security. When the existing security mechanisms/protocols are 559 applied to protect the DMM entities, the security risks that 560 may be introduced by DMM MUST be considered to be eliminated. 561 Else the security protection would be degraded in the DMM 562 solution versus in existing mobility protocols. 564 This requirement prevents a DMM solution from introducing 565 uncontrollable problems of potentially insecure mobility management 566 protocols which make deployment infeasible because platforms 567 conforming to the protocols are at risk for data loss and numerous 568 other dangers, including financial harm to the users. 570 5.7. Multicast 572 REQ7: Multicast considerations 574 DMM SHOULD consider multicast early so that solutions can be 575 developed not only to provide IP mobility support when it is 576 needed, but also to avoid network inefficiency issues in 577 multicast traffic delivery (such as duplicate multicast 578 subscriptions towards the downstream tunnel entities). The 579 multicast solutions should therefore avoid restricting the 580 management of all IP multicast traffic to a single host 581 through a dedicated (tunnel) interface on multicast-capable 582 access routers. 584 Motivation: Existing multicast deployment have been introduced 585 after completing the design of the reference mobility 586 protocol, then optimization and extensions have been followed 587 by "patching-up" procedure, thus leading to network 588 inefficiency and non-optimal routing. The multicast solutions 589 should therefore be required to consider efficiency nature in 590 multicast traffic delivery. 592 This requirement addresses the problems PS1 and PS8 described in 593 Section 4. 595 6. Security Considerations 597 Please refer to the discussion under Security requirement in Section 598 5.6. 600 7. IANA Considerations 602 None 604 8. Co-authors and Contributors 606 This problem statement document is a joint effort among the numerous 607 participants. Each individual has made significant contributions to 608 this work and have been listed as co-authors. 610 9. References 612 9.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 9.2. Informative References 619 [I-D.wakikawa-netext-pmip-cp-up-separation] 620 Wakikawa, R., Pazhyannur, R., and S. Gundavelli, 621 "Separation of Control and User Plane for Proxy Mobile 622 IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00 623 (work in progress), July 2013. 625 [I-D.yokota-dmm-scenario] 626 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 627 scenarios for Distributed Mobility Management", 628 draft-yokota-dmm-scenario-00 (work in progress), 629 October 2010. 631 [Paper-Distributed.Centralized.Mobility] 632 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 633 or Centralized Mobility", Proceedings of Global 634 Communications Conference (GlobeCom), December 2009. 636 [Paper-Distributed.Dynamic.Mobility] 637 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 638 Dynamic Mobility Management Scheme Designed for Flat IP 639 Architectures", Proceedings of 3rd International 640 Conference on New Technologies, Mobility and Security 641 (NTMS), 2008. 643 [Paper-Distributed.Mobility.MIP] 644 Chan, H., "Distributed Mobility Management with Mobile 645 IP", Proceedings of IEEE International Communication 646 Conference (ICC) Workshop on Telecommunications: from 647 Research to Standards, June 2012. 649 [Paper-Distributed.Mobility.PMIP] 650 Chan, H., "Proxy Mobile IP with Distributed Mobility 651 Anchors", Proceedings of GlobeCom Workshop on Seamless 652 Wireless Mobility, December 2010. 654 [Paper-Distributed.Mobility.Review] 655 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 656 "Distributed and Dynamic Mobility Management in Mobile 657 Internet: Current Approaches and Issues, Journal of 658 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 659 Proceedings of GlobeCom Workshop on Seamless Wireless 660 Mobility, February 2011. 662 [Paper-Distributed.Mobility.SAE] 663 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 664 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 665 Proceedings of the 19th International Symposium on 666 Personal, Indoor and Mobile Radio Communications (PIMRC), 667 2008. 669 [Paper-Locating.User] 670 Kirby, G., "Locating the User", Communication 671 International, 1995. 673 [Paper-Migrating.Home.Agents] 674 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 675 Agents Towards Internet-scale Mobility Deployments", 676 Proceedings of the ACM 2nd CoNEXT Conference on Future 677 Networking Technologies, December 2006. 679 [Paper-Mobile.Data.Offloading] 680 Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile 681 Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 682 2010, 2010. 684 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 685 RFC 3753, June 2004. 687 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 688 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 690 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 691 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 692 Management", RFC 5380, October 2008. 694 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 695 RFC 5944, November 2010. 697 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 698 in IPv6", RFC 6275, July 2011. 700 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 701 Support in the Internet", RFC 6301, July 2011. 703 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 704 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 705 Mobile IPv6", RFC 6909, April 2013. 707 [TS.23.401] 708 3GPP, "General Packet Radio Service (GPRS) enhancements 709 for Evolved Universal Terrestrial Radio Access Network 710 (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. 712 [TS.29303] 713 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 714 TR 23.303 11.2.0, September 2012. 716 Authors' Addresses 718 H Anthony Chan (editor) 719 Huawei Technologies (more co-authors on P. 17) 720 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 721 Email: h.a.chan@ieee.org 723 Dapeng Liu 724 China Mobile 725 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 726 Email: liudapeng@chinamobile.com 728 Pierrick Seite 729 Orange 730 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 731 Email: pierrick.seite@orange.com 733 Hidetoshi Yokota 734 KDDI Lab 735 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 736 Email: yokota@kddilabs.jp 738 Jouni Korhonen 739 Renesas Mobile 740 Email: jouni.korhonen@nsn.com 741 - 742 Charles E. Perkins 743 Huawei Technologies 744 Email: charliep@computer.org 745 - 746 Melia Telemaco 747 Alcatel-Lucent Bell Labs 748 Email: telemaco.melia@alcatel-lucent.com 749 - 750 Elena Demaria 751 Telecom Italia 752 via G. Reiss Romoli, 274, TORINO, 10148, Italy 753 Email: elena.demaria@telecomitalia.it 754 - 755 Jong-Hyouk Lee 756 Sangmyung University 757 Email: hurryon@gmail.com 758 - 759 Kostas Pentikousis 760 Huawei Technologies 761 Carnotstr. 4 10587 Berlin, Germany 762 Email: k.pentikousis@huawei.com 763 - 764 Tricci So 765 ZTE 766 Email: tso@zteusa.com 767 - 768 Carlos J. Bernardos 769 Universidad Carlos III de Madrid 770 Av. Universidad, 30, Leganes, Madrid 28911, Spain 771 Email: cjbc@it.uc3m.es 772 - 773 Peter McCann 774 Huawei Technologies 775 Email: PeterMcCann@huawei.com 776 - 777 Seok Joo Koh 778 Kyungpook National University, Korea 779 Email: sjkoh@knu.ac.kr 780 - 781 Wen Luo 782 ZTE 783 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 784 Email: luo.wen@zte.com.cn 785 - 786 Sri Gundavelli 787 Cisco 788 sgundave@cisco.com 789 - 790 Marco Liebsch 791 NEC Laboratories Europe 792 Email: liebsch@neclab.eu 793 - 794 Carl Williams 795 MCSR Labs 796 Email: carlw@mcsr-labs.org 797 - 798 Seil Jeon 799 Instituto de Telecomunicacoes, Aveiro 800 Email: seiljeon@av.it.pt 801 - 802 Sergio Figueiredo 803 Universidade de Aveiro 804 Email: sfigueiredo@av.it.pt 805 - 806 Stig Venaas 807 Email: stig@venaas.com 808 - 809 Luis Miguel Contreras Murillo 810 Telefonica I+D 811 Email: lmcm@tid.es 812 - 813 Juan Carlos Zuniga 814 InterDigital 815 Email: JuanCarlos.Zuniga@InterDigital.com 816 - 817 Alexandru Petrescu 818 Email: alexandru.petrescu@gmail.com 819 - 820 Georgios Karagiannis 821 University of Twente 822 Email: g.karagiannis@utwente.nl 823 - 824 Julien Laganier 825 Juniper 826 jlaganier@juniper.net 827 - 828 Wassim Michel Haddad 829 Ericsson 830 Wassam.Haddad@ericsson.com 831 - 832 Dirk von Hugo 833 Deutsche Telekom Laboratories 834 Dirk.von-Hugo@telekom.de 835 - 836 Ahmad Muhanna 837 Award Solutions 838 amuhanna@awardsolutions.com 839 - 840 Byoung-Jo Kim 841 ATT Labs 842 macsbug@research.att.com 843 - 844 Hassan Ali-Ahmad 845 Orange 846 hassan.aliahmad@orange.com 847 -