idnits 2.17.1 draft-ietf-dmm-requirements-07.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 (August 2, 2013) is 3914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 8 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: February 3, 2014 D. Liu 6 China Mobile 7 P. Seite 8 Orange 9 H. Yokota 10 KDDI Lab 11 J. Korhonen 12 Nokia Siemens Networks 13 August 2, 2013 15 Requirements for Distributed Mobility Management 16 draft-ietf-dmm-requirements-07 18 Abstract 20 This document defines the requirements for Distributed Mobility 21 Management (DMM) in IPv6 deployments. The hierarchical structure in 22 traditional wireless networks has led to deployment models which are 23 in practice centralized. Mobility management with logically 24 centralized mobility anchoring in current mobile networks is prone to 25 suboptimal routing and raises scalability issues. Such centralized 26 functions can lead to single points of failure and inevitably 27 introduce longer delays and higher signaling loads for network 28 operations related to mobility management. The objective is to 29 enhance mobility management in order to meet the primary goals in 30 network evolution, i.e., improve scalability, avoid single points of 31 failure, enable transparent mobility support to upper layers only 32 when needed, and so on. Distributed mobility management must be 33 secure and may co-exist with existing network deployments and end 34 hosts. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 RFC 2119 41 [RFC2119]. 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on February 3, 2014. 60 Copyright Notice 62 Copyright (c) 2013 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Conventions used in this document . . . . . . . . . . . . . . 6 79 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 80 3. Centralized versus distributed mobility management . . . . . . 6 81 3.1. Centralized mobility management . . . . . . . . . . . . . 7 82 3.2. Distributed mobility management . . . . . . . . . . . . . 8 83 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 84 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 86 5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 87 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 88 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 89 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12 90 5.6. Security considerations . . . . . . . . . . . . . . . . . 13 91 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 In the past decade a fair number of mobility protocols have been 103 standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. 104 Although the protocols differ in terms of functions and associated 105 message formats, we can identify a few key common features: 107 o a centralized mobility anchor providing global reachability and an 108 always-on experience to the user; 110 o extensions to the base protocols to optimize handover performance 111 while users roam across wireless cells; and 113 o extensions to enable the use of heterogeneous wireless interfaces 114 for multi-mode terminals (e.g. smartphones). 116 The presence of the centralized mobility anchor allows a mobile node 117 to remain reachable after it has moved to a different network. The 118 anchor point, among other tasks, ensures connectivity by forwarding 119 packets destined to, or sent from, the mobile node. In practice, 120 most of the deployed architectures today have a small number of 121 centralized anchors managing the traffic of millions of mobile nodes. 122 Compared with a distributed approach, a centralized approach is 123 likely to have several issues or limitations affecting performance 124 and scalability, which require costly network engineering to resolve. 126 To optimize handovers from the perspective of mobile nodes, the base 127 protocols have been extended to efficiently handle packet forwarding 128 between the previous and new points of attachment. These extensions 129 are necessary when applications have stringent requirements in terms 130 of delay. Notions of localization and distribution of local agents 131 have been introduced to reduce signaling overhead at the centralized 132 routing anchor point [Paper-Distributed.Centralized.Mobility]. 133 Unfortunately, today we witness difficulties in getting such 134 protocols deployed, resulting in sub-optimal choices for the network 135 operators. 137 Moreover, the availability of multiple-interface host and the 138 possibility of using several network interfaces simultaneously have 139 motivated the development of even more protocol extensions to add 140 more capabilities to the mobility management protocol. In the end, 141 deployment is further complicated with the multitude of extensions. 143 As an effective transport method for multimedia data delivery, IP 144 multicast support, including optimizations, have been introduced but 145 by "patching-up" procedure after completing the design of reference 146 mobility protocol, leading to network inefficiency and non-optimal 147 routing. 149 Mobile users are, more than ever, consuming Internet content; such 150 traffic imposes new requirements on mobile core networks for data 151 traffic delivery. The presence of content providers closer to 152 Internet Service Providers (ISP) network requires taking into account 153 local Content Delivery Networks (CDNs) while providing mobility 154 services. Moreover, when the traffic demand exceeds available 155 capacity, service providers need to implement new strategies such as 156 selective traffic offload (e.g. 3GPP work items LIPA/SIPTO 157 [TS.23.401]) through alternative access networks (e.g. WLAN) [Paper- 158 Mobile.Data.Offloading]. A gateway selection mechanism also takes 159 the user proximity into account within EPC [TS.29303]. These 160 mechanisms were not pursued in the past owing to charging and billing 161 reasons. Assigning a gateway anchor node from a visited network in 162 roaming scenario has until recently been done and are limited to 163 voice services only. Charging and billing require solutions beyond 164 the mobility protocol. 166 Both traffic offloading and CDN mechanisms could benefit from the 167 development of mobile architectures with fewer levels of routing 168 hierarchy introduced into the data path by the mobility management 169 system. This trend towards so-called "flat networks" works best for 170 direct communications among peers in the same geographical area. 171 Distributed mobility management in a truly flat mobile architecture 172 would anchor the traffic closer to the point of attachment of the 173 user. 175 Today's mobile networks present service providers with new 176 challenges. Mobility patterns indicate that mobile nodes often 177 remain attached to the same point of attachment for considerable 178 periods of time [Paper-Locating.User]. Specific IP mobility 179 management support is not required for applications that launch and 180 complete their sessions while the mobile node is connected to the 181 same point of attachment. However, currently, IP mobility support is 182 designed for always-on operation, maintaining all parameters of the 183 context for each mobile subscriber for as long as they are connected 184 to the network. This can result in a waste of resources and 185 unnecessary costs for the service provider. Infrequent node mobility 186 coupled with application intelligence suggest that mobility support 187 could be provided selectively, thus reducing the amount of context 188 maintained in the network. 190 The distributed mobility management (DMM) charter addresses two 191 complementary aspects of mobility management procedures: the 192 distribution of mobility anchors towards a more flat network and the 193 dynamic activation/deactivation of mobility protocol support as an 194 enabler to distributed mobility management. The former aims at 195 positioning mobility anchors (e.g., HA, LMA) closer to the user; 196 ideally, mobility agents could be collocated with the first-hop 197 router. The latter, facilitated by the distribution of mobility 198 anchors, aims at identifying when mobility support must be activated 199 and identifying sessions that do not require mobility management 200 support -- thus reducing the amount of state information that must be 201 maintained in various mobility agents of the mobile network. The key 202 idea is that dynamic mobility management relaxes some of the 203 constraints of previously-standardized mobility management solutions 204 and, by doing so, it can avoid the unnecessary establishment of 205 mechanisms to forward traffic from an old to a new mobility anchor. 207 This document compares distributed mobility management with 208 centralized mobility management in Section 3. The problems that can 209 be addressed with DMM are summarized in Section 4. The mandatory 210 requirements as well as the optional requirements are given in 211 Section 5. Finally, security considerations are discussed in Section 212 6. 214 The problem statement and the use cases [I-D.yokota-dmm-scenario] can 215 be found in [Paper-Distributed.Mobility.Review]. 217 2. Conventions used in this document 219 2.1. Terminology 221 All the general mobility-related terms and their acronyms used in 222 this document are to be interpreted as defined in the Mobile IPv6 223 base specification [RFC6275], in the Proxy mobile IPv6 specification 224 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 225 terms include the following: mobile node (MN), correspondent node 226 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 227 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 228 as per [RFC3753]. 230 In addition, this draft introduces the following term. 232 Mobility context 234 is the collection of information required to provide mobility 235 management support for a given mobile node. 237 3. Centralized versus distributed mobility management 239 Mobility management functions may be implemented at different layers 240 of the protocol stack. At the IP (network) layer, they may reside in 241 the network or in the mobile node. In particular, a network-based 242 solution resides in the network only. It therefore enables mobility 243 for existing hosts and network applications which are already in 244 deployment but lack mobility support. 246 At the IP layer, a mobility management protocol supporting session 247 continuity is typically based on the principle of distinguishing 248 between identifier and routing address and maintaining a mapping 249 between the two. In Mobile IP, the home address serves as an 250 identifier of the device whereas the care-of-address (CoA) takes the 251 role of the routing address. The binding between these two is 252 maintained at the home agent (mobility anchor). If packets can be 253 continuously delivered to a mobile node at its home address, then all 254 sessions using that home address are unaffected even though the 255 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 persistent node identifier and the locator IP address of a mobile 264 node (MN) is kept at a single mobility anchor. At the same time, 265 packets destined to the MN are routed via this anchor. In other 266 words, such mobility management systems are centralized in both the 267 control plane 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. In the 323 former case only the data plane is distributed. Fully distributed 324 mobility management implies that both the data plane and the control 325 plane are distributed. Such concepts of data and control plane 326 separation are not yet described in the IETF developed mobility 327 protocols so far but are described in detail in [I-D.yokota-dmm- 328 scenario]. While mobility management can be distributed, it is not 329 necessary for other functions such as subscription management, 330 subscription database, and network access authentication to be 331 similarly distributed. 333 A distributed mobility management scheme for flat IP-based mobile 334 network architecture consisting of access nodes is proposed in 335 [Paper-Distributed.Dynamic.Mobility]. Its benefits over centralized 336 mobility management are shown through simulations in [Paper- 337 Distributed.Centralized.Mobility]. Moreover, the (re)use and 338 extension of existing protocols in the design of both fully 339 distributed mobility management [Paper-Migrating.Home.Agents] [Paper- 340 Distributed.Mobility.SAE] and partially distributed mobility 341 management [Paper-Distributed.Mobility.PMIP] [Paper- 342 Distributed.Mobility.MIP] have been reported in the literature. 343 Therefore, before designing new mobility management protocols for a 344 future flat IP architecture, it is recommended to first consider 345 whether existing mobility management protocols can be extended to 346 serve a flat IP architecture. 348 4. Problem Statement 350 The problems that can be addressed with DMM are summarized in the 351 following: 353 PS1: Non-optimal routes 355 Routing via a centralized anchor often results in a longer 356 route. The problem is manifested, for example, when accessing 357 a local server or servers of a Content Delivery Network (CDN), 358 or when receiving locally available IP multicast or sending IP 359 multicast packets. 361 PS2: Divergence from other evolutionary trends in network 362 architectures such as distribution of content delivery. 364 Centralized mobility management can become non-optimal with a 365 flat network architecture. 367 PS3: Low scalability of centralized tunnel management and mobility 368 context maintenance 370 Setting up tunnels through a central anchor and maintaining 371 mobility context for each MN usually requires more concentrated 372 resources in a centralized design, thus reducing scalability. 373 Distributing the tunnel maintenance function and the mobility 374 context maintenance function among different network entities 375 with proper signaling protocol design can increase scalability. 377 PS4: Single point of failure and attack 379 Centralized anchoring designs may be more vulnerable to single 380 points of failures and attacks than a distributed system. The 381 impact of a successful attack on a system with centralized 382 mobility management can be far greater as well. 384 PS5: Unnecessarily reserving resources to provide mobility support 385 to nodes that do not need such support 387 IP mobility support is not always required, and not every 388 parameter of mobility context is always used. For example, 389 some applications do not need a stable IP address during a 390 handover to maintain session continuity. Sometimes, the entire 391 application session runs while the terminal does not change the 392 point of attachment. Besides, some sessions, e.g. SIP-based 393 sessions, can handle mobility at the application layer and 394 hence do not need IP mobility support; it is then more 395 efficient to deactivate IP mobility support for such sessions. 397 PS6: (Related problem) Mobility signaling overhead with peer-to-peer 398 communication 400 Wasting resources when mobility signaling (e.g., maintenance of 401 the tunnel, keep alive signaling, etc.) is not turned off for 402 peer-to-peer communication. Peer-to-peer communications have 403 particular traffic patterns that often do not benefit from 404 mobility support from the network. Thus, the associated 405 mobility support signaling (e.g., maintenance of the tunnel, 406 keep alive signaling, etc.) wastes network resources for no 407 application gain. In such a case, it is better to enable 408 mobility support selectively. 410 PS7: (Related problem) Deployment with multiple mobility solutions 412 There are already many variants and extensions of MIP. 413 Deployment of new mobility management solutions can be 414 challenging, and debugging difficult, when they must co-exist 415 with solutions already in the field. 417 PS8: Duplicate multicast traffic 419 IP multicast distribution over architectures using IP mobility 420 solutions (e.g. RFC6224) may lead to convergence of duplicated 421 multicast subscriptions towards the downstream tunnel entity 422 (e.g. MAG in PMIPv6). Concretely, when multicast subscription 423 for individual mobile nodes is coupled with mobility tunnels 424 (e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is 425 prone to be received through different upstream paths. This 426 problem may also exist or be more severe in a distributed 427 mobility environment. 429 5. Requirements 431 After comparing distributed mobility management against centralized 432 deployment in Section 3, this section identifies the following 433 requirements: 435 5.1. Distributed processing 437 REQ1: Distributed processing 439 IP mobility, network access and routing solutions provided by 440 DMM MUST enable distributed processing for mobility management 441 so that traffic does not need to traverse centrally deployed 442 mobility anchors and thereby avoid non-optimal routes. 444 Motivation: This requirement is motivated by current trends in 445 network evolution: (a) it is cost- and resource-effective to 446 cache and distribute content by combining distributed mobility 447 anchors with caching systems (e.g., CDN); (b) the 448 significantly larger number of mobile nodes and flows call for 449 improved scalability; (c) single points of failure are avoided 450 in a distributed system; (d) threats against centrally 451 deployed anchors, e.g., home agent and local mobility anchor, 452 are mitigated in a distributed system. 454 This requirement addresses the problems PS1, PS2, PS3, and PS4 455 described in Section 4. (Existing route optimization is only a host- 456 based solution. On the other hand, localized routing with PMIPv6 457 addresses only a part of the problem where both the MN and the CN are 458 located in the PMIP domain and attached to a MAG, and is not 459 applicable when the CN is outside the PMIP domain.) 461 5.2. Transparency to Upper Layers when needed 463 REQ2: Transparency to Upper Layers when needed 465 DMM solutions MUST provide transparent mobility support above 466 the IP layer when needed. Such transparency is needed, for 467 example, when, upon change of point of attachment to the 468 network, an application flow cannot cope with a change in the 469 IP address. However, it is not always necessary to maintain a 470 stable home IP address or prefix for every application or at 471 all times for a mobile node. 473 Motivation: The motivation of this requirement is to enable 474 more efficient use of network resources and more efficient 475 routing by not maintaining context at the mobility anchor when 476 there is no such need. 478 This requirement addresses the problem PS5 as well as the related 479 problem PS6 stated in Section 4. 481 5.3. IPv6 deployment 483 REQ3: IPv6 deployment 485 DMM solutions SHOULD target IPv6 as the primary deployment 486 environment and SHOULD NOT be tailored specifically to support 487 IPv4, in particular in situations where private IPv4 addresses 488 and/or NATs are used. 490 Motivation: This requirement conforms to the general 491 orientation of IETF work. DMM deployment is foreseen in mid- 492 to long-term horizon, when IPv6 is expected to be far more 493 common than today. 495 This requirement avoids the unnecessarily complexity in solving the 496 problems in Section 4 for IPv4, which will not be able to use some of 497 the IPv6-specific features. 499 5.4. Existing mobility protocols 501 REQ4: Existing mobility protocols 503 A DMM solution SHOULD first consider reusing and extending 504 IETF-standardized protocols before specifying new protocols. 506 Motivation: Reuse of existing IETF work is more efficient and 507 less error-prone. 509 This requirement attempts to avoid the need of new protocols 510 development and therefore their potential problems of being time- 511 consuming and error-prone. 513 5.5. Co-existence 515 REQ5: Co-existence with deployed networks and hosts 517 The DMM solution MUST be able to co-exist with existing 518 network deployments and end hosts. For example, depending on 519 the environment in which DMM is deployed, DMM solutions may 520 need to be compatible with other deployed mobility protocols 521 or may need to co-exist with a network or mobile hosts/routers 522 that do not support DMM protocols. The mobile node may also 523 move between different access networks, where some of them may 524 support neither DMM nor another mobility protocol. 525 Furthermore, a DMM solution SHOULD work across different 526 networks, possibly operated as separate administrative 527 domains, when allowed by the trust relationship between them. 529 Motivation: (a) to preserve backwards compatibility so that 530 existing networks and hosts are not affected and continue to 531 function as usual, and (b) enable inter-domain operation if 532 desired. 534 This requirement addresses the related problem PS7 described in 535 Section 4. 537 5.6. Security considerations 539 REQ6: Security considerations 541 A DMM solution MUST not introduce new security risks or 542 amplify existing security risks against which the existing 543 security mechanisms/protocols cannot offer sufficient 544 protection. 546 Motivation: Various attacks such as impersonation, denial of 547 service, man-in-the-middle attacks, and so on, may be launched 548 in a DMM deployment. For instance, an illegitimate node may 549 attempt to access a network providing DMM. Another example is 550 that a malicious node can forge a number of signaling messages 551 thus redirecting traffic from its legitimate path. 552 Consequently, the specific node is under a denial of service 553 attack, whereas other nodes do not receive their traffic. 554 Accordingly, security mechanisms/protocols providing access 555 control, integrity, authentication, authorization, 556 confidentiality, etc. can be used to protect the DMM entities 557 as they are already used to protect against existing networks 558 and existing mobility protocols defined in IETF. In addition, 559 end-to-end security measures between communicating nodes may 560 already be used when deploying existing mobility protocols 561 where the signaling messages travel over the Internet. For 562 instance, EAP-based authentication can be used for network 563 access security, while IPsec can be used for end-to-end 564 security. When the existing security mechanisms/protocols are 565 applied to protect the DMM entities, the security risks that 566 may be introduced by DMM MUST be considered to be eliminated. 567 Else the security protection would be degraded in the DMM 568 solution versus in existing mobility protocols. 570 This requirement prevents a DMM solution from introducing 571 uncontrollable problems of potentially insecure mobility management 572 protocols which make deployment infeasible because platforms 573 conforming to the protocols are at risk for data loss and numerous 574 other dangers, including financial harm to the users. 576 5.7. Multicast 578 REQ7: Multicast considerations 580 DMM SHOULD consider multicast early so that solutions can be 581 developed not only to provide IP mobility support when it is 582 needed, but also to avoid network inefficiency issues in 583 multicast traffic delivery (such as duplicate multicast 584 subscriptions towards the downstream tunnel entities). The 585 multicast solutions should therefore avoid restricting the 586 management of all IP multicast traffic to a single host 587 through a dedicated (tunnel) interface on multicast-capable 588 access routers. 590 Motivation: Existing multicast deployment have been introduced 591 after completing the design of the reference mobility 592 protocol, then optimization and extensions have been followed 593 by "patching-up" procedure, thus leading to network 594 inefficiency and non-optimal routing. The multicast solutions 595 should therefore be required to consider efficiency nature in 596 multicast traffic delivery. 598 This requirement addresses the problems PS1 and PS8 described in 599 Section 4. 601 6. Security Considerations 603 Please refer to the discussion under Security requirement in Section 604 5.6. 606 7. IANA Considerations 608 None 610 8. Co-authors and Contributors 612 This problem statement document is a joint effort among the numerous 613 participants. Each individual has made significant contributions to 614 this work and have been listed as co-authors. 616 9. References 618 9.1. Normative References 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 9.2. Informative References 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. 665 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 666 Proceedings of the 19th International Symposium on 667 Personal, Indoor and Mobile Radio Communications (PIMRC), 668 2008. 670 [Paper-Locating.User] 671 Kirby, G., "Locating the User", Communication 672 International, 1995. 674 [Paper-Migrating.Home.Agents] 675 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 676 Agents Towards Internet-scale Mobility Deployments", 677 Proceedings of the ACM 2nd CoNEXT Conference on Future 678 Networking Technologies, December 2006. 680 [Paper-Mobile.Data.Offloading] 681 Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile 682 Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 683 2010, 2010. 685 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 686 RFC 3753, June 2004. 688 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 689 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 691 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 692 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 693 Management", RFC 5380, October 2008. 695 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 696 RFC 5944, November 2010. 698 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 699 in IPv6", RFC 6275, July 2011. 701 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 702 Support in the Internet", RFC 6301, July 2011. 704 [TS.23.401] 705 3GPP, "General Packet Radio Service (GPRS) enhancements 706 for Evolved Universal Terrestrial Radio Access Network 707 (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. 709 [TS.29303] 710 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 711 TR 23.303 11.2.0, September 2012. 713 Authors' Addresses 715 H Anthony Chan (editor) 716 Huawei Technologies (more co-authors on P. 17) 717 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 718 Email: h.a.chan@ieee.org 720 Dapeng Liu 721 China Mobile 722 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 723 Email: liudapeng@chinamobile.com 725 Pierrick Seite 726 Orange 727 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 728 Email: pierrick.seite@orange.com 730 Hidetoshi Yokota 731 KDDI Lab 732 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 733 Email: yokota@kddilabs.jp 735 Jouni Korhonen 736 Nokia Siemens Networks 737 Email: jouni.korhonen@nsn.com 738 - 739 Charles E. Perkins 740 Huawei Technologies 741 Email: charliep@computer.org 742 - 743 Melia Telemaco 744 Alcatel-Lucent Bell Labs 745 Email: telemaco.melia@alcatel-lucent.com 746 - 747 Elena Demaria 748 Telecom Italia 749 via G. Reiss Romoli, 274, TORINO, 10148, Italy 750 Email: elena.demaria@telecomitalia.it 751 - 752 Jong-Hyouk Lee 753 RSM Department, Telecom Bretagne 754 Cesson-Sevigne, 35512, France 755 Email: jh.lee@telecom-bretagne.eu 756 - 757 Kostas Pentikousis 758 Huawei Technologies 759 Carnotstr. 4 10587 Berlin, Germany 760 Email: k.pentikousis@huawei.com 761 - 762 Tricci So 763 ZTE 764 Email: tso@zteusa.com 765 - 766 Carlos J. Bernardos 767 Universidad Carlos III de Madrid 768 Av. Universidad, 30, Leganes, Madrid 28911, Spain 769 Email: cjbc@it.uc3m.es 770 - 771 Peter McCann 772 Huawei Technologies 773 Email: PeterMcCann@huawei.com 774 - 775 Seok Joo Koh 776 Kyungpook National University, Korea 777 Email: sjkoh@knu.ac.kr 778 - 779 Wen Luo 780 ZTE 781 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 782 Email: luo.wen@zte.com.cn 783 - 784 Sri Gundavelli 785 sgundave@cisco.com 786 - 787 Marco Liebsch 788 NEC Laboratories Europe 789 Email: liebsch@neclab.eu 790 - 791 Carl Williams 792 MCSR Labs 793 Email: carlw@mcsr-labs.org 794 - 795 Seil Jeon 796 Instituto de Telecomunicacoes, Aveiro 797 Email: seiljeon@av.it.pt 798 - 799 Sergio Figueiredo 800 Universidade de Aveiro 801 Email: sfigueiredo@av.it.pt 802 - 803 Stig Venaas 804 Email: stig@venaas.com 805 - 806 Luis Miguel Contreras Murillo 807 Email: lmcm@tid.es 808 - 809 Juan Carlos Zuniga 810 Email: JuanCarlos.Zuniga@InterDigital.com 811 - 812 Alexandru Petrescu 813 Email: alexandru.petrescu@gmail.com 814 - 815 Georgios Karagiannis 816 Email: g.karagiannis@utwente.nl 817 - 818 Julien Laganier 819 jlaganier@juniper.net 820 - 821 Wassim Michel Haddad 822 Wassam.Haddad@ericsson.com 823 - 824 Dirk von Hugo 825 Dirk.von-Hugo@telekom.de 826 - 827 Ahmad Muhanna 828 amuhanna@awardsolutions.com 829 - 830 Byoung-Jo Kim 831 ATT Labs 832 macsbug@research.att.com 833 - 834 Hassan Aliahmad 835 Orange 836 hassan.aliahmad@orange.com 837 -