idnits 2.17.1 draft-chan-dmm-requirements-00.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 752 has weird spacing: '...agement in Mo...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 3, 2012) is 4437 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.PMIP-DMC' is mentioned on line 346, but not defined == Unused Reference: 'I-D.PMIP-dmc' is defined on line 714, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-sjkoh-mext-pmip-dmc-01 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4068 (Obsoleted by RFC 5268) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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 4 Intended status: Informational March 3, 2012 5 Expires: September 4, 2012 7 Requirements of distributed mobility management 8 draft-chan-dmm-requirements-00 10 Abstract 12 The traditional hierarchical structure of cellular networks has led 13 to deployment models which are heavily centralized. Mobility 14 management with centralized mobility anchoring in existing 15 hierarchical mobile networks is quite prone to suboptimal routing and 16 issues related to scalability. Centralized functions present a 17 single point of failure, and inevitably introduce longer delays and 18 higher signaling loads for network operations related to mobility 19 management. To make matters worse, there are numerous variants of 20 Mobile IP in addition to other protocols standardized outside the 21 IETF, making it much more difficult to create economical and 22 interoperable solutions. In this document we examine the problems of 23 centralized mobility management and identify requirements for 24 distributed and dynamic mobility management. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 4, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . 5 62 3. Centralized versus distributed mobility management . . . . . . 5 63 3.1. Centralized mobility management . . . . . . . . . . . . . 6 64 3.2. Distributed mobility management . . . . . . . . . . . . . 6 65 4. Problem statement . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Non-optimal routes . . . . . . . . . . . . . . . . . . . . 8 67 4.2. Non-optimality in Evolved Network Architecture . . . . . . 10 68 4.3. Lack of user-centricity . . . . . . . . . . . . . . . . . 11 69 4.4. Low scalability of centralized route and mobility 70 context maintenance . . . . . . . . . . . . . . . . . . . 11 71 4.5. Wasting resources to support mobile nodes not needing 72 mobility support . . . . . . . . . . . . . . . . . . . . . 12 73 4.6. Complicated deployment with too many variants and 74 extensions of MIP . . . . . . . . . . . . . . . . . . . . 12 75 4.7. Mobility signaling overhead with peer-to-peer 76 communication . . . . . . . . . . . . . . . . . . . . . . 13 77 4.8. Single point of failure and attack . . . . . . . . . . . . 14 78 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 In the past decade a fair number of mobility protocols have been 90 standardized. Although the protocols differ in terms of functions 91 and associated message format, we can identify a few key common 92 features: 93 presence of a centralized mobility anchor providing global 94 reachability and an always-on experience; 96 extensions to optimize handover performance while users roam 97 across wireless cells; 99 extensions to enable the use of heterogeneous wireless interfaces 100 for multi-mode terminals (e.g. cellular phones). 102 The presence of the centralized mobility anchor allows a mobile 103 device to be reachable when it is not connected to its home domain. 104 The anchor point, among other tasks, ensures reachability of 105 forwarding of packets destined to or sent from the mobile device. 106 Most of the deployed architectures today have a small number of 107 centralized anchors managing the traffic of millions of mobile 108 subscribers. Compared with a distributed approach, a centralized 109 approach is likely to have several issues or limitations affecting 110 performance and scalability, which require costly network 111 dimensioning and engineering to resolve. 113 To optimize handovers from the perspective of mobile nodes, the base 114 protocols have been extended to efficiently handle packet forwarding 115 between the previous and new points of attachment. These extensions 116 are necessary when applications impose stringent requirements in 117 terms of delay. Notions of localization and distribution of local 118 agents have been introduced to reduce signaling overhead. 119 Unfortunately today we witness difficulties in getting such protocols 120 deployed, often leading to sub-optimal choices. 122 Moreover, the availability of multi-mode devices and the possibility 123 of using several network interfaces simultaneously have motivated the 124 development of more new protocol extensions. Deployment is further 125 complicated with so many extensions. 127 Mobile users are, more than ever, consuming Internet content; such 128 traffic imposes new requirements on mobile core networks for data 129 traffic delivery. When the traffic demand exceeds available 130 capacity, service providers need to implement new strategies such as 131 selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through 132 alternative access networks (e.g. WLAN). Moreover, the localization 133 of content providers closer to the Mobile/Fixed Internet Service 134 Providers network requires taking into account local Content Delivery 135 Networks (CDNs) while providing mobility services. 137 When demand exceeds capacity, both offloading and CDN techniques 138 could benefit from the development of mobile architectures with fewer 139 levels of routing hierarchy introduced into the data path by the 140 mobility management system. This trend in network flattening is 141 reinforced by a shift in users traffic behavior, aimed at increasing 142 direct communications among peers in the same geographical area. 143 Distributed mobility management in a truly flat mobile architecture 144 would anchor the traffic closer to the point of attachment of the 145 user and overcome the suboptimal routing issues of a centralized 146 mobility scheme. 148 While deploying [Paper-Locating.User] today's mobile networks, 149 service providers face new challenges. More often than not, mobile 150 devices remain attached to the same point of attachment. Specific IP 151 mobility management support is not required for applications that 152 launch and complete while the mobile device is connected to the same 153 point of attachment. However, the mobility support has been designed 154 to be always on and to maintain the context for each mobile 155 subscriber as long as they are connected to the network. This can 156 result in a waste of resources and ever-increasing costs for the 157 service provider. Infrequent mobility and intelligence of many 158 applications suggest that mobility can be provided dynamically, thus 159 simplifying the context maintained in the different nodes of the 160 mobile network. 162 The proposed charter will address two complementary aspects of 163 mobility management procedures: the distribution of mobility anchors 164 to achieve a more flat design and the dynamic activation/deactivation 165 of mobility protocol support as an enabler to distributed mobility 166 management. The former has the goal of positioning mobility anchors 167 (HA, LMA) closer to the user; ideally, these mobility agents could be 168 collocated with the first hop router. The latter, facilitated by the 169 distribution of mobility anchors, aims at identifying when mobility 170 must be activated and identifying sessions that do not impose 171 mobility management -- thus reducing the amount of state information 172 to be maintained in the various mobility agents of the mobile 173 network. The key idea is that dynamic mobility management relaxes 174 some constraints while also repositioning mobility anchors; it avoids 175 the establishment of non optimal tunnels between two topologically 176 distant anchors. 178 Considering the above, the distributed mobility management working 179 group will: 180 Define the problem statement and associated requirements for 181 distributed mobility management. This work aims at defining the 182 problem space and identifies the key functional requirements. 184 Produce a gap analysis mapping the above requirements against 185 existing solutions. 187 Give best practices for the deployment of existing mobility 188 protocols in a distributed mobility management and describe 189 limitations of each such approach. 191 Describe extensions, if needed, to current mobility protocols for 192 their applications in distributed mobility architectures. 194 This document describes the motivations of distributed mobility 195 management and the proposed work in Section 1.1. Section 1.2 196 summarizes the problems with centralized IP mobility management 197 compared with distributed and dynamic mobility management, which is 198 elaborated in Section 4. The requirements to address these problems 199 are given in Section 5. A companion document [dmm-scenario] 200 discusses the use case scenarios. 202 Much of the contents this document together with those in [dmm- 203 scenario] have been merged and elaborated into the following review 204 paper: [Paper-Distributed.Mobility.Review]. 206 2. Conventions used in this document 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 3. Centralized versus distributed mobility management 214 Mobility management functions may be implemented at different layers 215 of the network protocol stack. At the IP (network) layer, they may 216 reside in the network or in the mobile node. In particular, a 217 network-based solution resides in the network only. It therefore 218 enables mobility for existing hosts and network applications which 219 are already in deployment but lack mobility support. 221 At the IP layer, a mobility management protocol to achieve session 222 continuity is typically based on the principle of distinguishing 223 between identifier and routing address and maintaining a mapping 224 between them. With Mobile IP, the home address serves as an 225 identifier of the device whereas the care-of-address takes the role 226 of routing address, and the binding between them is maintained at the 227 mobility anchor, i.e., the home agent. If packets can be 228 continuously delivered to a mobile device at its home address, then 229 all sessions using that home address can be preserved even though the 230 routing or care-of address changes. 232 The next two subsections explain centralized and distributed mobility 233 management functions in the network. 235 3.1. Centralized mobility management 237 With centralized mobility management, the mapping information between 238 the stable node identifier and the changing IP address of an MN is 239 kept at a centralized mobility anchor. Packets destined to an MN are 240 routed via this anchor. In other words, such mobility management 241 systems are centralized in both the control plane and the data plane. 243 Many existing mobility management deployments make use of centralized 244 mobility anchoring in a hierarchical network architecture, as shown 245 in Figure 1. Examples of such centralized mobility anchors are the 246 home agent (HA) and local mobility anchor (LMA) in Mobile IP 247 [RFC3775] and Proxy Mobile IP [RFC5213], respectively. Current 248 mobile networks such as the Third Generation Partnership Project 249 (3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System 250 (EPS) networks also employ centralized mobility management, with 251 Gateway GPRS Support Node (GGSN) and Serving GPRS Support Node (SGSN) 252 in the 3GPP UMTS hierarchical network and with Packet data network 253 Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP EPS network. 255 UMTS 3GPP SAE MIP/PMIP 256 +------+ +------+ +------+ 257 | GGSN | | P-GW | |HA/LMA| 258 +------+ +------+ +------+ 259 /\ /\ /\ 260 / \ / \ / \ 261 / \ / \ / \ 262 / \ / \ / \ 263 / \ / \ / \ 264 +------+ +------+ +------+ +------+ +------+ +------+ 265 | SGSN | | SGSN | | S-GW | | S-GW | |FA/MAG| |FA/MAG| 266 +------+ +------+ +------+ +------+ +------+ +------+ 268 Figure 1. Centralized mobility management. 270 3.2. Distributed mobility management 272 Mobility management functions may also be distributed to multiple 273 locations in different networks as shown in Figure 2, so that a 274 mobile node in any of these networks may be served by a closeby 275 mobility function (MF). 277 +------+ +------+ +------+ +------+ 278 | MF | | MF | | MF | | MF | 279 +------+ +------+ +------+ +------+ 280 | 281 ---- 282 | MN | 283 ---- 285 Figure 2. Distributed mobility management. 287 Mobility management may be partially distributed, i.e., only the data 288 plane is distributed, or fully distributed where both the data plane 289 and control plane are distributed. These different approaches are 290 described in detail in [I-D.dmm-scenario]. 292 [Paper-New.Perspective] discusses some initial steps towards a clear 293 definition of what mobility management may be, to assist in better 294 developing distributed architecture. [Paper- 295 Characterization.Mobility.Management] analyses current mobility 296 solutions and propses an initial decoupling of mobility management 297 into well-defined functional blocks, identifying their interactions, 298 as well as a potential grouping, which later can assist in deriving 299 more flexible mobility management architectures. According to the 300 split functional blocks, this paper proposes three ways into which 301 mobility management functional blocks can be groups, as an initial 302 way to consider a better distribution: location and handover 303 management, control and data plane, user and access perspective. 305 A distributed mobility management scheme is proposed in [Paper- 306 Distributed.Dynamic.Mobility] for future flat IP architecture 307 consisting of access nodes. The benefits of this design over 308 centralized mobility management are also verified through simulations 309 in [Paper-Distributed.Centralized.Mobility]. 311 Before designing new mobility management protocols for a future flat 312 IP architecture, one should first ask whether the existing mobility 313 management protocols that have already been deployed for the 314 hierarchical mobile networks can be extended to serve the flat IP 315 architecture. MIPv4 has already been deployed in 3GPP2 networks, and 316 PMIPv6 has already been adopted in WiMAX Forum and in 3GPP standards. 317 Using MIP or PMIP for both centralized and distributed architectures 318 would ease the migration of the current mobile networks towards a 319 flat architecture. It has therefore been proposed to adapt MIP or 320 PMIPv6 to achieve distributed mobility management by using a 321 distributed mobility anchor architecture. 323 In [Paper-Migrating.Home.Agents], the HA functionality is copied to 324 many locations. The HoA of all MNs are anycast addresses, so that a 325 packet destined to a HoA from any CN from any network can be routed 326 via the nearest copy of the HA. In addition, distributing the 327 function of HA using a distributed hash table structure is proposed 328 in [Paper-Distributed.Mobility.SAE]. A lookup query to the hash 329 table will retrieve the location information of an MN is stored. 331 In [Paper-Distributed.Mobility.PMIP], only the mobility routing (MR) 332 function is duplicated and distributed in many locations. The 333 location information for any MN that has moved to a visited network 334 is still centralized and kept at a location management (LM) function 335 in the home network of the MN. The LM function at different networks 336 constitutes a distributed database system of all the MNs that belong 337 to any of these networks and have moved to a visited network. The 338 location information is maintained in the form of a hierarchy: the LM 339 at the home network, the CoA of the MR of the visited network, and 340 then the CoA to reach the MN in the visited network. The LM in the 341 home network keeps a binding of the HoA of the MN to the CoA of the 342 MR of the visited network. The MR keeps the binding of the HoA of 343 the MN to the CoA of the MN in the case of MIP, or the proxy-CoA of 344 the Mobile Access Gateway (MAG) serving the MN in the case of PMIP. 346 [I-D.PMIP-DMC] discusses two distributed mobility control schemes 347 using the PMIP protocol: Signal-driven PMIP (S-PMIP) and Signal- 348 driven Distributed PMIP (SD-PMIP). S-PMIP is a partially distributed 349 scheme, in which the control plane (using a Proxy Binding Query to 350 get the Proxy-CoA of the MN) is separate from the data plane, and the 351 optimized data path is directly between the CN and the MN. SD-PMIP 352 is a fully distributed scheme, in which the Proxy Binding Update is 353 not performed, and instead each MAG will multicast a Proxy Binding 354 Query message to all of the MAGs in its local PMIP domain to retrieve 355 the Proxy-CoA of the MN. 357 4. Problem statement 359 This section identifies problems and limitations of centralized 360 mobility approaches, and compares against possible distributed 361 approaches. 363 4.1. Non-optimal routes 365 Routing via a centralized anchor often results in a longer route. 366 Figure 3 shows two cases of non-optimized routes. 368 MIP/PMIP 369 +------+ 370 |HA/LMA| 371 +------+ 372 /\ \ \ +---+ 373 / \ \ \ |CDN| 374 / \ \ \ +---+ 375 / \ \ \ | 376 / \ \ \ | 377 +------+ +------+ +------+ +------+ 378 |FA/MAG| |FA/MAG| |FA/MAG| |FA/MAG| 379 +------+ +------+ +------+ +------+ 380 | | 381 ---- ---- 382 | CN | | MN | 383 ---- ---- 385 Figure 3. Non-optimized route when communicating with CN and when 386 accessing local content. 388 In the first case, the mobile node and the correspondent node are 389 close to each other but are both far from the mobility anchor. 390 Packets destined to the mobile node need to be routed via the 391 mobility anchor, which is not on the shortest path. The second case 392 involves a content delivery network (CDN). A user may obtain content 393 from a server, such as when watching a video. As such usage becomes 394 more popular, resulting in an increase in the core network traffic, 395 service providers may relieve the core network traffic by placing 396 these contents closer to the users in the access network in the form 397 of cache or local CDN servers. Yet as the MN is getting content from 398 a local or cache server of a CDN, even though the server is close to 399 the MN, packets still need to go through the core network to route 400 via the mobility anchor in the home network of the MN, if the MN uses 401 the HoA as its identifier. 403 In a distributed mobility management design, one possibility is to 404 have mobility anchors distributed in different access networks so 405 that packets may be routed via a nearby mobility anchor function, as 406 shown in Figure 4. 408 +---+ 409 |CDN| 410 +---+ 411 | 412 | 413 +------+ +------+ +------+ +------+ 414 | MF | | MF | | MF | | MF | 415 +------+ +------+ +------+ +------+ 416 | | 417 ---- ---- 418 | CN | | MN | 419 ---- ---- 421 Figure 4. Mobile node in any network is served by a close by 422 mobility function. 424 Due to the above limitation, with the centralized mobility anchor 425 design, route optimization extensions to mobility protocols are 426 therefore needed. Whereas the location privacy of each MN may be 427 compromised when the CoA of an MN is given to the CN, those mobility 428 protocol deployments that lack such optimization extensions will 429 encounter non-optimal routes, which affect the performance. 431 In contrast, route optimization may be naturally an integral part of 432 a distributed mobility management design. With the help of such 433 intrinsic route optimization, the data transmission delay will be 434 reduced, by which the data transmission throughputs can be enhanced. 435 Furthermore, the data traffic overhead at the mobility agents such as 436 the HA and the LMA in the core network can be alleviated 437 significantly. 439 4.2. Non-optimality in Evolved Network Architecture 441 Centralized mobility management is currently deployed to support the 442 existing hierarchical mobile data networks. It leverages on the 443 hierarchical architecture. However, the volume of wireless data 444 traffic continues to increase exponentially. The data traffic 445 increase would require costly capacity upgrade of centralized 446 architectures. It is thus predictable that the data traffic increase 447 will soon overload the centralized data anchor point, e.g., the P-GW 448 in 3GPP EPS. In order to address this issue, a trend in the 449 evolution of mobile networks is to distribute network functions close 450 to access networks. These network functions can be the content 451 servers in a CDN, and also the data anchor point. 453 Mobile networks have been evolving from a hierarchical architecture 454 to a more flattened architecture. In the 3GPP standards, the GPRS 455 network has the hierarchy GGSN "C SGSN "C RNC "C NB (Node B). In 456 3GPP EPS networks, the hierarchy is reduced to P-GW "C S-GW "C eNB 457 (Evolved NB). In some deployments, the P-GW and the S-GW are 458 collocated to further reduce the hierarchy. Reducing the hierarchy 459 this way reduces the number of different physical network elements in 460 the network, contributing to easier system maintenance and lower 461 cost. As mobile networks become more flattened, the centralized 462 mobility management can become non-optimal. Mobility management 463 deployment with distributed architecture is then needed to support 464 the more flattened network and the CDN networks. 466 4.3. Lack of user-centricity 468 The mobility anchor point, as the main element of a mobility 469 management system, has been object of intensive studies in order to 470 create more distributed and decentralized systems. Accordingly, its 471 role, its functionalities, and the location it should take in the 472 network (e.g. router, server, etc) are not a consensus. Depending on 473 the architecture, on the network characteristics, and on the 474 functionalities we have in the mobility anchor element, its location 475 may vary, and its function in the whole system may change. 476 Considering that user-centric networks present particular 477 characteristics (e.g. there is no clear splitting between network 478 elements and end-devices), the current centralized standards may not 479 be suitable. Thus, a novel mobility management approach should be 480 designed for such networks, considering all its particularities and 481 following this trend of rethinking the mobility anchor point element. 483 These aspects reinforce the need for distributed and dynamic mobility 484 mechanisms. Positioning the anchor-point in network elements closer 485 to the end user provides the capability to have a more flexible 486 mobility management service, with (potentially) more control in terms 487 of users expectations; it also assists the access operation by 488 lowering the operation complexity. For instance, traffic locality 489 can be more easily achieved by having mobility management 490 functionality deployed in elements that are closer to customer 491 premises, or on the edges of the access network. 493 4.4. Low scalability of centralized route and mobility context 494 maintenance 496 Special routes are set up to enable session continuity when a 497 handover occurs. Packets sent from the CN need to be tunneled 498 between the HA and FA in MIP and between the LMA and MAG in PMIP. 499 However, these network elements at the ends of the tunnel are also 500 routers performing the regular routing tasks for ordinary packets not 501 involving a mobile node. These ordinary packets need to be directly 502 routed according to the routing table in the routers without 503 tunneling. Therefore, the network must be able to distinguish those 504 packets requiring tunneling from the regular packets. For each 505 packet that requires tunneling owing to mobility, the network will 506 encapsulate it with a proper outer IP header with the proper source 507 and destination IP addresses. The network therefore needs to 508 maintain and manage the mobility context of each MN, which is the 509 relevant information needed to characterize the mobility situation of 510 that MN to allow the network to distinguish their packets from other 511 packets and to perform the required tunneling. 513 Setting up such special routes and maintaining the mobility context 514 for each MN is more difficult to scale in a centralized design with a 515 large number of MNs. Distributing the route maintenance function and 516 the mobility context maintenance function among different networks 517 can be more scalable. 519 4.5. Wasting resources to support mobile nodes not needing mobility 520 support 522 The problem of centralized route and mobility context maintenance is 523 aggravated when the via routes are set up for many more MNs that are 524 not requiring IP mobility support. On the one hand, the network 525 needs to provide mobility support for the increasing number of mobile 526 devices because the existing mobility management has been designed to 527 always provide such support as long as a mobile device is attached to 528 the network. On the other hand, many nomadic users connected to a 529 network in an office or meeting room. Such users will not move for 530 the entire network session. It has been measured that over two- 531 thirds of a user mobility is local [Paper-Locating.User]. In 532 addition, it is possible to have the intelligence for applications to 533 manage mobility without needing help from the network. Network 534 resources are therefore wasted to provide mobility support for the 535 devices that do not really need it at the moment. 537 It is necessary to dynamically set up the via routes only for MNs 538 that actually undergo handovers and lack higher-layer mobility 539 support. With distributed mobility anchors, such dynamic mobility 540 management mechanism may then also be distributed. Therefore, 541 dynamic mobility and distributed mobility may complement each other 542 and may be integrated. 544 4.6. Complicated deployment with too many variants and extensions of 545 MIP 547 Mobile IP, which has primarily been deployed in a centralized manner 548 for the hierarchical mobile networks, already has numerous variants 549 and extensions including PMIP, Fast MIP (FMIP) [RFC4068] [RFC4988] , 550 Proxy-based FMIP (PFMIP) [RFC5949] , hierarchical MIP (HMIP) 551 [RFC5380] , Dual-Stack Mobile IP (DSMIP) [RFC5454] [RFC5555] and 552 there may be more to come. These different modifications or 553 extensions of MIP have been developed over the years owing to the 554 different needs that are found afterwards. Deployment can then 555 become complicated, especially if interoperability with different 556 deployments is an issue. 558 A desirable feature of mobility management is to be able to work with 559 network architectures of both hierarchical networks and flattened 560 networks, so that the mobility management protocol possesses enough 561 flexibility to support different networks. In addition, one goal of 562 dynamic mobility management is the capability to selectively turn on 563 and off mobility support and certain different mobility signaling. 564 Such flexibility in the design is compatible with the goal to 565 integrate different mobility variants as options. Some additional 566 extensions to the base protocols may then be needed to improve the 567 integration. 569 4.7. Mobility signaling overhead with peer-to-peer communication 571 In peer-to-peer communications, end users communicate by sending 572 packets directly addressed to each other's IP address. However, they 573 need to find each other's IP address first through signaling in the 574 network. While different schemes for this purpose may be used, MIP 575 already has a mechanism to locate an MN and may be used in this way. 576 In particular, MIPv6 Route Optimization (RO) mode enables a more 577 efficient data packets exchange than the bidirectional tunneling (BT) 578 mode, as shown in Figure 5. 580 MIP/PMIP 581 +------+ 582 |HA/LMA| 583 +------+ 584 /\ \ \ 585 / \ \ \ 586 / \ \ \ 587 / \ \ \ 588 / \ \ \ 589 +------+ +------+ +------+ +------+ 590 |FA/MAG| |FA/MAG| |FA/MAG| |FA/MAG| 591 +------+ +------+ +------+ +------+ 592 | | 593 ---- ---- 594 | MN |<--->| CN | 595 ---- ---- 597 Figure 5. Non-optimized route when communicating with CN and when 598 accessing local content. 600 This RO mode is expected to be used whenever possible unless the MN 601 is not interested in disclosing its topological location, i.e., the 602 CoA, to the CN (e.g., for privacy reasons) or some other network 603 constraints are put in place. However, MIPv6 RO mode requires 604 exchanging a significant amount of signaling messages in order to 605 establish and periodically refresh a bidirectional security 606 association (BSA) between an MN and its CN. While the mobility 607 signaling exchange impacts the overall handover latency, the BSA is 608 needed to authenticate the binding update and acknowledgment messages 609 (note that the latter is not mandatory). In addition, the amount of 610 mobility signaling messages increases further when both endpoints are 611 mobile. 613 A dynamic mobility management capability to turn off these signaling 614 when they are not needed will enable the RO mode between two mobile 615 endpoints at minimum or no cost. It will also reduce the handover 616 latency owing to the removal of the extra signaling. These benefits 617 for peer-to-peer communications will encourage the adoption and 618 large-scale deployment of dynamic mobility management. 620 4.8. Single point of failure and attack 622 A centralized anchoring architecture is generally more vulnerable to 623 a single point of failure or attack, requiring duplication and 624 backups of the support functions. 626 On the other hand, a distributed mobility management architecture has 627 intrinsically mitigated the problem to a local network which is then 628 of a smaller scope. In addition, the availability of such functions 629 in neighboring networks has already provided the needed architecture 630 to support protection. 632 5. Requirements 634 After reviewing the problems and limitations of centralized 635 deployment in Section 4, this section states the requirements as 636 follows: 637 1. Distributed mobility requirement: The mobility management 638 functions in interconnecting networks be available in multiple 639 locations and therefore are always close to any node so that the 640 node may perform handover with session continuity without routing 641 the data-plane traffic via a centralized anchor. 643 It is noted that centralized functions in the control plane are 644 not excluded and should still be possible. 646 This requirement enables mobility management deployment in a 647 distributed architure to avoid the non-optimal routes described 648 in Section 4.1. It enables placing the mobility anchor closer to 649 the access network to which the mobile node is attached, thereby 650 supporting the more flattened network and the CDN networks 651 described in Section 4.2. Such a distributed architecture is 652 more scalable than a centralized one as described in Section 4.4, 653 and avoids the single point of failure and attack as described in 654 Section 4.8. 656 2. Dynamic mobility requirement: A network supporting a mix of 657 mobile nodes some of which may be stationary for extended time 658 while others may be actively mobile may minimize traffic overhead 659 and avoid unnecessary mobility support. 661 This requirement addresses the problems of unnecessary mobility 662 support described in Section 4.5 and of the mobility signaling 663 overhead with peer-to-peer communication described in Section 664 4.7. 666 3. To further ease the deployment it is desirable that the mobility 667 management can be deployed in a mix of hierarchical architecture 668 and distributed architecture and the different variants and 669 extensions of MIP are compatible and integrated. 671 6. Security Considerations 673 TBD 675 7. IANA Considerations 677 None 679 8. Co-authors and Contributors 681 This problem statement document is a joint effort among the following 682 participants. Each individual has made significant contributions to 683 this work. 685 Dapeng Liu: liudapeng@chinamobile.com 687 Pierrick Seite: pierrick.seite@orange-ftgroup.com 689 Hidetoshi Yokota: yokota@kddilabs.jp 691 Charles E. Perkins: charliep@computer.org 692 Melia Telemaco: telemaco.melia@alcatel-lucent.com 694 Elena Demaria: elena.demaria@telecomitalia.it 696 Wassim Michel Haddad: Wassam.Haddad@ericsson.com 698 Hui Deng: denghui@chinamobile.com 700 Seok Joo Koh: sjkoh@knu.ac.kr 702 Rute Sofia (in collaboration with Tiago Condeixa, Andrea Nascimento, 703 and Susana Sargento): rute.sofia@ulusofona.pt 705 9. References 707 9.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 9.2. Informative References 714 [I-D.PMIP-dmc] 715 Koh, S., Kim, J., Jung, H., and Y. Han, "Use of Proxy 716 Mobile IPv6 for Distributed Mobility Control", 717 draft-sjkoh-mext-pmip-dmc-01 (work in progress), 718 March 2011. 720 [I-D.dmm-scenario] 721 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 722 scenarios for Distributed Mobility Management", 723 draft-yokota-dmm-scenario-00 (work in progress), 724 October 2010. 726 [Paper-Characterization.Mobility.Management] 727 Nascimento, A., Sofia, R., Condeixa, T., and S. Sargento, 728 "A Characterization of Mobility Management in User-centric 729 Networks", Proceeding of NEW2AN 2011 in Lecture Notes in 730 Computer Science, 2011, Volume 6869/2011, 314-325, DOI: 731 10.1007/978-3-642-22875-9_29, August 2011. 733 [Paper-Distributed.Centralized.Mobility] 734 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 735 or Centralized Mobility", Proceedings of Global 736 Communications Conference (GlobeCom), December 2009. 738 [Paper-Distributed.Dynamic.Mobility] 739 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 740 Dynamic Mobility Management Scheme Designed for Flat IP 741 Architectures", Proceedings of 3rd International 742 Conference on New Technologies, Mobility and Security 743 (NTMS), 2008. 745 [Paper-Distributed.Mobility.PMIP] 746 Chan, H., "Proxy Mobile IP with Distributed Mobility 747 Anchors", Proceedings of GlobeCom Workshop on Seamless 748 Wireless Mobility, December 2010. 750 [Paper-Distributed.Mobility.Review] 751 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 752 "Distributed and Dynamic Mobility Management in Mobile 753 Internet: Current Approaches and Issues, Journal of 754 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 755 Proceedings of GlobeCom Workshop on Seamless Wireless 756 Mobility, February 2011. 758 [Paper-Distributed.Mobility.SAE] 759 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 760 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 761 Proceedings of the 19th International Symposium on 762 Personal, Indoor and Mobile Radio Communications (PIMRC), 763 2008. 765 [Paper-Locating.User] 766 Kirby, G., "Locating the User", Communication 767 International, 1995. 769 [Paper-Migrating.Home.Agents] 770 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 771 Agents Towards Internet-scale Mobility Deployments", 772 Proceedings of the ACM 2nd CoNEXT Conference on Future 773 Networking Technologies, December 2006. 775 [Paper-New.Perspective] 776 Condeixa, T., Matos, R., Matos, A., Sargento, S., and R. 777 Sofia, "A New Perspective on Mobility Management: 778 Scenarios and Approaches", Proceeding of 2nd 779 International ICST Conference on Mobile Networks and 780 Management (NONAMI) 2010, pp 340-353., September 2010. 782 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 783 in IPv6", RFC 3775, June 2004. 785 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 786 July 2005. 788 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 789 RFC 4988, October 2007. 791 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 792 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 794 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 795 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 796 Management", RFC 5380, October 2008. 798 [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile 799 IPv4", RFC 5454, March 2009. 801 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 802 Routers", RFC 5555, June 2009. 804 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 805 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 806 September 2010. 808 Author's Address 810 H Anthony Chan (editor) 811 Huawei Technologies 812 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 813 Email: h.a.chan@ieee.org 814 - 815 Dapeng Liu 816 China Mobile 817 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 818 Email: liudapeng@chinamobile.com 819 - 820 Pierrick Seite 821 France Telecom - Orange 822 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 823 Email: pierrick.seite@orange-ftgroup.com 824 - 825 Hidetoshi Yokota 826 KDDI Lab 827 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 828 Email: yokota@kddilabs.jp 829 - 830 Charles E. Perkins 831 Tellabs Inc. 832 4555 Great America Parkway, #S5-130 833 Email: charliep@computer.org 834 - 835 Melia Telemaco 836 Alcatel-Lucent Bell Labs 837 Email: telemaco.melia@alcatel-lucent.com 838 - 839 Wassim Michel Haddad 840 Ericsson 841 300 Holger Dr, San Jose, CA 95134, USA 842 Email: Wassam.Haddad@ericsson.com 843 - 844 Elena Demaria 845 Telecom Italia 846 via G. Reiss Romoli, 274, TORINO, 10148, Italy 847 Email: elena.demaria@telecomitalia.it 848 - 849 Seok Joo Koh 850 Kyungpook National University, Korea 851 Email: sjkoh@knu.ac.kr 852 - 853 Rute Sofia 854 University Lusofona, Portugal 855 Email: rute.sofia@ulusofona.pt 856 -