idnits 2.17.1 draft-ietf-dmm-requirements-06.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 624 has weird spacing: '...enarios for D...' == Line 637 has weird spacing: '...ference on Ne...' == Line 648 has weird spacing: '...orkshop on Se...' == Line 653 has weird spacing: '...agement in Mo...' == Line 656 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 (July 30, 2013) is 3922 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: January 31, 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 July 30, 2013 15 Requirements for Distributed Mobility Management 16 draft-ietf-dmm-requirements-06 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 January 31, 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 . . . . . . . . . . . . . . . . . 15 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 of some flows so that traffic does not need to traverse 442 centrally deployed mobility anchors and thereby avoid non- 443 optimal routes. 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 problems PS1, PS2, PS3, and PS4 in Section 456 4. (Existing route optimization is only a host-based solution. On 457 the other hand, localized routing with PMIPv6 addresses only a part 458 of the problem where both the MN and the CN are located in the PMIP 459 domain and attached to a MAG, and is not applicable when the CN is 460 outside the PMIP domain.) 462 5.2. Transparency to Upper Layers when needed 464 REQ2: Transparency to Upper Layers when needed 466 DMM solutions MUST provide transparent mobility support above 467 the IP layer when needed. Such transparency is needed, for 468 example, when, upon change of point of attachment to the 469 network, an application flow cannot cope with a change in the 470 IP address. However, it is not always necessary to maintain a 471 stable home IP address or prefix for every application or at 472 all times for a mobile node. 474 Motivation: The motivation of this requirement is to enable 475 more efficient use of network resources and more efficient 476 routing by not maintaining context at the mobility anchor when 477 there is no such need. 479 This requirement addresses the problem PS5 as well as the related 480 problem PS6 in Section 4. 482 5.3. IPv6 deployment 484 REQ3: IPv6 deployment 486 DMM solutions SHOULD target IPv6 as the primary deployment 487 environment and SHOULD NOT be tailored specifically to support 488 IPv4, in particular in situations where private IPv4 addresses 489 and/or NATs are used. 491 Motivation: This requirement conforms to the general 492 orientation of IETF work. DMM deployment is foreseen in mid- 493 to long-term horizon, when IPv6 is expected to be far more 494 common than today. 496 This requirement avoids the unnecessarily complexity in solving the 497 problems in Section 4 for IPv4, which will not be able to use some of 498 the IPv6-specific features. 500 5.4. Existing mobility protocols 502 REQ4: Existing mobility protocols 504 A DMM solution SHOULD first consider reusing and extending 505 IETF-standardized protocols before specifying new protocols. 507 Motivation: Reuse of existing IETF work is more efficient and 508 less error-prone. 510 This requirement attempts to avoid the need of new protocols 511 development and therefore their potential problems of being time- 512 consuming and error-prone. 514 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 following related problem PS7 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: DMM SHOULD consider multicast early so that solutions can be 579 developed not only to provide IP mobility to keep IP multicast 580 sessions when it is needed, but also to avoid network 581 inefficiency issues in multicast traffic delivery (such as 582 duplicate multicast subscriptions towards the downstream 583 tunnel entities). The multicast solutions should therefore 584 avoid restricting the management of all IP multicast traffic 585 to a single host through a dedicated (tunnel) interface on 586 multicast-capable access routers. 588 Motivation: Existing multicast deployment have been introduced 589 after completing the design of the reference mobility 590 protocol, then optimization and extensions have been followed 591 by "patching-up" procedure, thus leading to network 592 inefficiency and non-optimal routing. The multicast solutions 593 should therefore be required to consider efficiency nature in 594 multicast traffic delivery. 596 This requirement addresses the problems PS1 and PS8 in Section 4. 598 6. Security Considerations 600 Please refer to the discussion under Security requirement in Session 601 5.6. 603 7. IANA Considerations 605 None 607 8. Co-authors and Contributors 609 This problem statement document is a joint effort among the numerous 610 participants. Each individual has made significant contributions to 611 this work and have been listed as co-authors. 613 9. References 615 9.1. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 9.2. Informative References 622 [I-D.yokota-dmm-scenario] 623 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 624 scenarios for Distributed Mobility Management", 625 draft-yokota-dmm-scenario-00 (work in progress), 626 October 2010. 628 [Paper-Distributed.Centralized.Mobility] 629 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 630 or Centralized Mobility", Proceedings of Global 631 Communications Conference (GlobeCom), December 2009. 633 [Paper-Distributed.Dynamic.Mobility] 634 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 635 Dynamic Mobility Management Scheme Designed for Flat IP 636 Architectures", Proceedings of 3rd International 637 Conference on New Technologies, Mobility and Security 638 (NTMS), 2008. 640 [Paper-Distributed.Mobility.MIP] 641 Chan, H., "Distributed Mobility Management with Mobile 642 IP", Proceedings of IEEE International Communication 643 Conference (ICC) Workshop on Telecommunications: from 644 Research to Standards, June 2012. 646 [Paper-Distributed.Mobility.PMIP] 647 Chan, H., "Proxy Mobile IP with Distributed Mobility 648 Anchors", Proceedings of GlobeCom Workshop on Seamless 649 Wireless Mobility, December 2010. 651 [Paper-Distributed.Mobility.Review] 652 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 653 "Distributed and Dynamic Mobility Management in Mobile 654 Internet: Current Approaches and Issues, Journal of 655 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 656 Proceedings of GlobeCom Workshop on Seamless Wireless 657 Mobility, February 2011. 659 [Paper-Distributed.Mobility.SAE] 660 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 661 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 662 Proceedings of the 19th International Symposium on 663 Personal, Indoor and Mobile Radio Communications (PIMRC), 664 2008. 666 [Paper-Locating.User] 667 Kirby, G., "Locating the User", Communication 668 International, 1995. 670 [Paper-Migrating.Home.Agents] 671 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 672 Agents Towards Internet-scale Mobility Deployments", 673 Proceedings of the ACM 2nd CoNEXT Conference on Future 674 Networking Technologies, December 2006. 676 [Paper-Mobile.Data.Offloading] 677 Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile 678 Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 679 2010, 2010. 681 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 682 RFC 3753, June 2004. 684 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 685 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 687 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 688 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 689 Management", RFC 5380, October 2008. 691 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 692 RFC 5944, November 2010. 694 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 695 in IPv6", RFC 6275, July 2011. 697 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 698 Support in the Internet", RFC 6301, July 2011. 700 [TS.23.401] 701 3GPP, "General Packet Radio Service (GPRS) enhancements 702 for Evolved Universal Terrestrial Radio Access Network 703 (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. 705 [TS.29303] 706 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 707 TR 23.303 11.2.0, September 2012. 709 Authors' Addresses 711 H Anthony Chan (editor) 712 Huawei Technologies (more co-authors on P. 17) 713 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 714 Email: h.a.chan@ieee.org 716 Dapeng Liu 717 China Mobile 718 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 719 Email: liudapeng@chinamobile.com 721 Pierrick Seite 722 Orange 723 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 724 Email: pierrick.seite@orange.com 726 Hidetoshi Yokota 727 KDDI Lab 728 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 729 Email: yokota@kddilabs.jp 731 Jouni Korhonen 732 Nokia Siemens Networks 733 Email: jouni.korhonen@nsn.com 734 - 735 Charles E. Perkins 736 Huawei Technologies 737 Email: charliep@computer.org 738 - 739 Melia Telemaco 740 Alcatel-Lucent Bell Labs 741 Email: telemaco.melia@alcatel-lucent.com 742 - 743 Elena Demaria 744 Telecom Italia 745 via G. Reiss Romoli, 274, TORINO, 10148, Italy 746 Email: elena.demaria@telecomitalia.it 747 - 748 Jong-Hyouk Lee 749 RSM Department, Telecom Bretagne 750 Cesson-Sevigne, 35512, France 751 Email: jh.lee@telecom-bretagne.eu 752 - 753 Kostas Pentikousis 754 Huawei Technologies 755 Carnotstr. 4 10587 Berlin, Germany 756 Email: k.pentikousis@huawei.com 757 - 758 Tricci So 759 ZTE 760 Email: tso@zteusa.com 761 - 762 Carlos J. Bernardos 763 Universidad Carlos III de Madrid 764 Av. Universidad, 30, Leganes, Madrid 28911, Spain 765 Email: cjbc@it.uc3m.es 766 - 767 Peter McCann 768 Huawei Technologies 769 Email: PeterMcCann@huawei.com 770 - 771 Seok Joo Koh 772 Kyungpook National University, Korea 773 Email: sjkoh@knu.ac.kr 774 - 775 Wen Luo 776 ZTE 777 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 778 Email: luo.wen@zte.com.cn 779 - 780 Sri Gundavelli 781 sgundave@cisco.com 782 - 783 Marco Liebsch 784 NEC Laboratories Europe 785 Email: liebsch@neclab.eu 786 - 787 Carl Williams 788 MCSR Labs 789 Email: carlw@mcsr-labs.org 790 - 791 Seil Jeon 792 Instituto de Telecomunicacoes, Aveiro 793 Email: seiljeon@av.it.pt 794 - 795 Sergio Figueiredo 796 Universidade de Aveiro 797 Email: sfigueiredo@av.it.pt 798 - 799 Stig Venaas 800 Email: stig@venaas.com 801 - 802 Luis Miguel Contreras Murillo 803 Email: lmcm@tid.es 804 - 805 Juan Carlos Zuniga 806 Email: JuanCarlos.Zuniga@InterDigital.com 807 - 808 Alexandru Petrescu 809 Email: alexandru.petrescu@gmail.com 810 - 811 Georgios Karagiannis 812 Email: g.karagiannis@utwente.nl 813 - 814 Julien Laganier 815 jlaganier@juniper.net 816 - 817 Wassim Michel Haddad 818 Wassam.Haddad@ericsson.com 819 - 820 Dirk von Hugo 821 Dirk.von-Hugo@telekom.de 822 - 823 Ahmad Muhanna 824 amuhanna@awardsolutions.com 825 - 826 Byoung-Jo Kim 827 ATT Labs 828 macsbug@research.att.com 829 - 830 Hassan Aliahmad 831 Orange 832 hassan.aliahmad@orange.com 833 -