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