idnits 2.17.1 draft-ietf-dmm-requirements-05.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 628 has weird spacing: '...enarios for D...' == Line 641 has weird spacing: '...ference on Ne...' == Line 652 has weird spacing: '...orkshop on Se...' == Line 657 has weird spacing: '...agement in Mo...' == Line 660 has weird spacing: '...orkshop on Se...' == (2 more instances...) -- The document date (June 5, 2013) is 3977 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 7 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: December 7, 2013 D. Liu 6 China Mobile 7 P. Seite 8 Orange 9 H. Yokota 10 KDDI Lab 11 J. Korhonen 12 Nokia Siemens Networks 13 June 5, 2013 15 Requirements for Distributed Mobility Management 16 draft-ietf-dmm-requirements-05 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 December 7, 2013. 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 . . . . . . . . . . . . . . . . . . . . . 15 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 DMM protocol solutions MUST consider security risks introduced 542 by DMM into the network. Such considerations may include 543 authentication and authorization mechanisms that allow a 544 mobile host/router to use the mobility support provided by the 545 DMM solution; measures against redirecting traffic to the 546 wrong host when providing DMM support; signaling message 547 protection for authentication, integrity and confidentiality. 549 Motivation: Various attacks such as impersonation, denial of 550 service, man-in-the-middle attacks, and so on, may become 551 newly possible or easier to mount due to the introduction of 552 DMM. Proof of possession of past and new IP addresses may be 553 needed. 555 Signaling messages can be subject to various attacks since 556 they carry critical context information about a mobile node/ 557 router. For instance, a malicious node can forge a number of 558 signaling messages thus redirecting traffic from its 559 legitimate path. Consequently, the specific node is under a 560 denial of service attack, whereas other nodes do not receive 561 their traffic. As signaling messages may travel over the 562 Internet, end-to-end security between communicating hosts must 563 be required. 565 This requirement addresses the problems of potentially insecure 566 mobility management protocols which make deployment infeasible 567 because platforms conforming to the protocols are at risk for data 568 loss and numerous other dangers, including financial harm to the 569 user. 571 5.7. Multicast 573 REQ7: DMM SHOULD enable multicast solutions in flexible distribution 574 scenario. This flexibility pertains to the preservation of IP 575 multicast nature from the perspective of a mobility entity and 576 transmission of multicast packets to/from various multicast- 577 enabled entities. Therefore, this flexibility enables 578 different IP multicast flows with respect to a mobile host to 579 be managed (e.g., subscribed, received and/or transmitted) 580 using multiple multicast-enabled endpoints. 582 Motivation: to consider multicast early so that solutions can 583 be developed to avoid network inefficiency issues in multicast 584 traffic delivery. The multicast solution should therefore 585 avoid restricting the management of all IP multicast traffic 586 relative to a host through a dedicated interface on multicast- 587 capable access routers. 589 This requirement addresses the problems PS1 and PS8 in Section 4. 591 6. Security Considerations 593 Distributed mobility management (DMM) requires two kinds of security 594 considerations. The first consideration is on access network 595 security required between the mobile host/router and the access 596 network deploying DMM. It allows only a legitimate mobile host/ 597 router to use DMM. The second consideration is on end-to-end 598 security required between nodes that participate in the DMM protocol. 599 It protects the DMM signaling messages. 601 It is necessary to provide sufficient defense against possible 602 security attacks, or to adopt existing security mechanisms and 603 protocols to provide sufficient security protections. For instance, 604 EAP-based authentication can be used for access network security, 605 while IPsec can be used for end-to-end security. 607 7. IANA Considerations 609 None 611 8. Co-authors and Contributors 613 This problem statement document is a joint effort among the numerous 614 participants. Each individual has made significant contributions to 615 this work and have been listed as co-authors. 617 9. References 619 9.1. Normative References 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 9.2. Informative References 626 [I-D.yokota-dmm-scenario] 627 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 628 scenarios for Distributed Mobility Management", 629 draft-yokota-dmm-scenario-00 (work in progress), 630 October 2010. 632 [Paper-Distributed.Centralized.Mobility] 633 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 634 or Centralized Mobility", Proceedings of Global 635 Communications Conference (GlobeCom), December 2009. 637 [Paper-Distributed.Dynamic.Mobility] 638 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 639 Dynamic Mobility Management Scheme Designed for Flat IP 640 Architectures", Proceedings of 3rd International 641 Conference on New Technologies, Mobility and Security 642 (NTMS), 2008. 644 [Paper-Distributed.Mobility.MIP] 645 Chan, H., "Distributed Mobility Management with Mobile 646 IP", Proceedings of IEEE International Communication 647 Conference (ICC) Workshop on Telecommunications: from 648 Research to Standards, June 2012. 650 [Paper-Distributed.Mobility.PMIP] 651 Chan, H., "Proxy Mobile IP with Distributed Mobility 652 Anchors", Proceedings of GlobeCom Workshop on Seamless 653 Wireless Mobility, December 2010. 655 [Paper-Distributed.Mobility.Review] 656 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 657 "Distributed and Dynamic Mobility Management in Mobile 658 Internet: Current Approaches and Issues, Journal of 659 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 660 Proceedings of GlobeCom Workshop on Seamless Wireless 661 Mobility, February 2011. 663 [Paper-Distributed.Mobility.SAE] 664 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 Email: seiljeon@av.it.pt 797 - 798 Sergio Figueiredo 799 Email: sfigueiredo@av.it.pt 800 - 801 Stig Venaas 802 Email: stig@venaas.com 803 - 804 Luis Miguel Contreras Murillo 805 Email: lmcm@tid.es 806 - 807 Juan Carlos Zuniga 808 Email: JuanCarlos.Zuniga@InterDigital.com 809 - 810 Alexandru Petrescu 811 Email: alexandru.petrescu@gmail.com 812 - 813 Georgios Karagiannis 814 Email: g.karagiannis@utwente.nl 815 - 816 Julien Laganier 817 jlaganier@juniper.net 818 - 819 Wassim Michel Haddad 820 Wassam.Haddad@ericsson.com 821 - 822 Dirk von Hugo 823 Dirk.von-Hugo@telekom.de 824 - 825 Ahmad Muhanna 826 amuhanna@awardsolutions.com 827 -