idnits 2.17.1 draft-chan-dmm-requirements-01.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 851 has weird spacing: '...enarios for D...' == Line 864 has weird spacing: '...ference on Ne...' == Line 869 has weird spacing: '...orkshop on Se...' == Line 874 has weird spacing: '...agement in Mo...' == Line 877 has weird spacing: '...orkshop on Se...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 8, 2012) is 4333 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-netext-pd-pmip' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'RFC5844' is defined on line 920, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-netext-pd-pmip-02 -- Obsolete informational reference (is this intentional?): RFC 4068 (Obsoleted by RFC 5268) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 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 June 8, 2012 5 Expires: December 10, 2012 7 Requirements of distributed mobility management 8 draft-chan-dmm-requirements-01 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. This document defines the requirements for distributed 20 mobility management for IPv6 deployment. The objectives are to match 21 the mobility deployment with the current trend in network evolution, 22 to improve scalability, to avoid single point of failure, to enable 23 transparency to upper layers only when needed, etc. The distributed 24 mobility management also needs to be compatible with existing network 25 deployments and end hosts, and be secured. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 10, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 5 63 3. Centralized versus distributed mobility management . . . . . . 5 64 3.1. Centralized mobility management . . . . . . . . . . . . . 6 65 3.2. Distributed mobility management . . . . . . . . . . . . . 7 66 4. Problem statement . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Non-optimal routes . . . . . . . . . . . . . . . . . . . . 9 68 4.2. Non-optimality in Evolved Network Architecture . . . . . . 10 69 4.3. Low scalability of centralized route and mobility 70 context maintenance . . . . . . . . . . . . . . . . . . . 11 71 4.4. Single point of failure and attack . . . . . . . . . . . . 12 72 4.5. Wasting resources to support mobile nodes not needing 73 mobility support . . . . . . . . . . . . . . . . . . . . . 12 74 4.6. Other related problems . . . . . . . . . . . . . . . . . . 13 75 4.6.1. Mobility signaling overhead with peer-to-peer 76 communication . . . . . . . . . . . . . . . . . . . . 13 77 4.6.2. Complicated deployment with too many variants and 78 extensions of MIP . . . . . . . . . . . . . . . . . . 14 79 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 5.1. Distributed deployment . . . . . . . . . . . . . . . . . . 15 81 5.2. Transparency to Upper Layers when needed . . . . . . . . . 15 82 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 15 83 5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 16 84 5.5. Existing mobility protocols . . . . . . . . . . . . . . . 16 85 5.6. Security considerations . . . . . . . . . . . . . . . . . 17 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 18 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 In the past decade a fair number of mobility protocols have been 97 standardized. Although the protocols differ in terms of functions 98 and associated message format, we can identify a few key common 99 features: 101 presence of a centralized mobility anchor providing global 102 reachability and an always-on experience; 104 extensions to optimize handover performance while users roam 105 across wireless cells; 107 extensions to enable the use of heterogeneous wireless interfaces 108 for multi-mode terminals (e.g. cellular phones). 110 The presence of the centralized mobility anchor allows a mobile 111 device to be reachable when it is not connected to its home domain. 112 The anchor point, among other tasks, ensures reachability of 113 forwarding of packets destined to or sent from the mobile device. 114 Most of the deployed architectures today have a small number of 115 centralized anchors managing the traffic of millions of mobile 116 subscribers. Compared with a distributed approach, a centralized 117 approach is likely to have several issues or limitations affecting 118 performance and scalability, which require costly network 119 dimensioning and engineering to resolve. 121 To optimize handovers from the perspective of mobile nodes, the base 122 protocols have been extended to efficiently handle packet forwarding 123 between the previous and new points of attachment. These extensions 124 are necessary when applications impose stringent requirements in 125 terms of delay. Notions of localization and distribution of local 126 agents have been introduced to reduce signaling overhead. 127 Unfortunately today we witness difficulties in getting such protocols 128 deployed, often leading to sub-optimal choices. 130 Moreover, the availability of multi-mode devices and the possibility 131 of using several network interfaces simultaneously have motivated the 132 development of more new protocol extensions. Deployment is further 133 complicated with so many extensions. 135 Mobile users are, more than ever, consuming Internet content; such 136 traffic imposes new requirements on mobile core networks for data 137 traffic delivery. When the traffic demand exceeds available 138 capacity, service providers need to implement new strategies such as 139 selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through 140 alternative access networks (e.g. WLAN). Moreover, the localization 141 of content providers closer to the Mobile/Fixed Internet Service 142 Providers network requires taking into account local Content Delivery 143 Networks (CDNs) while providing mobility services. 145 When demand exceeds capacity, both offloading and CDN techniques 146 could benefit from the development of mobile architectures with fewer 147 levels of routing hierarchy introduced into the data path by the 148 mobility management system. This trend in network flattening is 149 reinforced by a shift in users traffic behavior, aimed at increasing 150 direct communications among peers in the same geographical area. 151 Distributed mobility management in a truly flat mobile architecture 152 would anchor the traffic closer to the point of attachment of the 153 user and overcome the suboptimal routing issues of a centralized 154 mobility scheme. 156 While deploying [Paper-Locating.User] today's mobile networks, 157 service providers face new challenges. More often than not, mobile 158 devices remain attached to the same point of attachment. Specific IP 159 mobility management support is not required for applications that 160 launch and complete while the mobile device is connected to the same 161 point of attachment. However, the mobility support has been designed 162 to be always on and to maintain the context for each mobile 163 subscriber as long as they are connected to the network. This can 164 result in a waste of resources and ever-increasing costs for the 165 service provider. Infrequent mobility and intelligence of many 166 applications suggest that mobility can be provided dynamically, thus 167 simplifying the context maintained in the different nodes of the 168 mobile network. 170 The proposed charter will address two complementary aspects of 171 mobility management procedures: the distribution of mobility anchors 172 to achieve a more flat design and the dynamic activation/deactivation 173 of mobility protocol support as an enabler to distributed mobility 174 management. The former has the goal of positioning mobility anchors 175 (HA, LMA) closer to the user; ideally, these mobility agents could be 176 collocated with the first hop router. The latter, facilitated by the 177 distribution of mobility anchors, aims at identifying when mobility 178 must be activated and identifying sessions that do not impose 179 mobility management -- thus reducing the amount of state information 180 to be maintained in the various mobility agents of the mobile 181 network. The key idea is that dynamic mobility management relaxes 182 some constraints while also repositioning mobility anchors; it avoids 183 the establishment of non optimal tunnels between two topologically 184 distant anchors. 186 Considering the above, the distributed mobility management working 187 group is chartered with the following tasks: 189 Define the problem statement of distributed mobility management 190 and identity the requirements for a distributed mobility 191 management solution. 193 Document practices for the deployment of existing mobility 194 protocols in a distributed mobility management environment. 196 Identify the limitations in the current practices with respect to 197 providing the expected functionality. 199 If limitations are identified as part of the above deliverable, 200 specify extensions to existing protocols that removes these 201 limitations within a distributed mobility management environment. 203 This document describes the motivations of distributed mobility 204 management and the proposed work in Section 1.1. Section 1.2 205 summarizes the problems with centralized IP mobility management 206 compared with distributed and dynamic mobility management, which is 207 elaborated in Section 4. The requirements to address these problems 208 are given in Section 5. A companion document [I-D.yokota-dmm- 209 scenario] discusses the use case scenarios. 211 Much of the problems explained in this document together with the 212 contents in [I-D.yokota-dmm-scenario] have been merged and elaborated 213 into the following review paper: [Paper-Distributed.Mobility.Review]. 215 2. Conventions used in this document 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in [RFC2119]. 221 3. Centralized versus distributed mobility management 223 Mobility management functions may be implemented at different layers 224 of the network protocol stack. At the IP (network) layer, they may 225 reside in the network or in the mobile node. In particular, a 226 network-based solution resides in the network only. It therefore 227 enables mobility for existing hosts and network applications which 228 are already in deployment but lack mobility support. 230 At the IP layer, a mobility management protocol to achieve session 231 continuity is typically based on the principle of distinguishing 232 between identifier and routing address and maintaining a mapping 233 between them. With Mobile IP, the home address serves as an 234 identifier of the device whereas the care-of-address takes the role 235 of routing address, and the binding between them is maintained at the 236 mobility anchor, i.e., the home agent. If packets can be 237 continuously delivered to a mobile device at its home address, then 238 all sessions using that home address can be preserved even though the 239 routing or care-of address changes. 241 The next two subsections explain centralized and distributed mobility 242 management functions in the network. 244 3.1. Centralized mobility management 246 With centralized mobility management, the mapping information between 247 the stable node identifier and the changing IP address of a mobile 248 node (MN) is kept at a centralized mobility anchor. Packets destined 249 to an MN are routed via this anchor. In other words, such mobility 250 management systems are centralized in both the control plane and the 251 data plane. 253 Many existing mobility management deployments make use of centralized 254 mobility anchoring in a hierarchical network architecture, as shown 255 in Figure 1. Examples of such centralized mobility anchors are the 256 home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 257 [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current 258 mobile networks such as the Third Generation Partnership Project 259 (3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System 260 (EPS) networks also employ centralized mobility management, with 261 Gateway GPRS Support Node (GGSN) and Serving GPRS Support Node (SGSN) 262 in the 3GPP UMTS hierarchical network and with Packet data network 263 Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP EPS network. 265 UMTS 3GPP SAE MIP/PMIP 266 +------+ +------+ +------+ 267 | GGSN | | P-GW | |HA/LMA| 268 +------+ +------+ +------+ 269 /\ /\ /\ 270 / \ / \ / \ 271 / \ / \ / \ 272 / \ / \ / \ 273 / \ / \ / \ 274 +------+ +------+ +------+ +------+ +------+ +------+ 275 | SGSN | | SGSN | | S-GW | | S-GW | |FA/MAG| |FA/MAG| 276 +------+ +------+ +------+ +------+ +------+ +------+ 278 Figure 1. Centralized mobility management. 280 3.2. Distributed mobility management 282 Mobility management functions may also be distributed to multiple 283 locations in different networks as shown in Figure 2, so that a 284 mobile node in any of these networks may be served by a closeby 285 mobility function (MF). 287 +------+ +------+ +------+ +------+ 288 | MF | | MF | | MF | | MF | 289 +------+ +------+ +------+ +------+ 290 | 291 ---- 292 | MN | 293 ---- 295 Figure 2. Distributed mobility management. 297 Mobility management may be partially distributed, i.e., only the data 298 plane is distributed, or fully distributed where both the data plane 299 and control plane are distributed. These different approaches are 300 described in detail in [I-D.yokota-dmm-scenario]. 302 [Paper-New.Perspective] discusses some initial steps towards a clear 303 definition of what mobility management may be, to assist in better 304 developing distributed architecture. [Paper- 305 Characterization.Mobility.Management] analyses current mobility 306 solutions and proposes an initial decoupling of mobility management 307 into well-defined functional blocks, identifying their interactions, 308 as well as a potential grouping, which later can assist in deriving 309 more flexible mobility management architectures. According to the 310 split functional blocks, this paper proposes three ways into which 311 mobility management functional blocks can be groups, as an initial 312 way to consider a better distribution: location and handover 313 management, control and data plane, user and access perspective. 315 A distributed mobility management scheme is proposed in [Paper- 316 Distributed.Dynamic.Mobility] for future flat IP architecture 317 consisting of access nodes. The benefits of this design over 318 centralized mobility management are also verified through simulations 319 in [Paper-Distributed.Centralized.Mobility]. 321 Before designing new mobility management protocols for a future flat 322 IP architecture, one should first ask whether the existing mobility 323 management protocols that have already been deployed for the 324 hierarchical mobile networks can be extended to serve the flat IP 325 architecture. MIPv4 has already been deployed in 3GPP2 networks, and 326 PMIPv6 has already been adopted in WiMAX Forum and in 3GPP standards. 328 Using MIP or PMIP for both centralized and distributed architectures 329 would ease the migration of the current mobile networks towards a 330 flat architecture. It has therefore been proposed to adapt MIP or 331 PMIPv6 to achieve distributed mobility management by using a 332 distributed mobility anchor architecture. 334 In [Paper-Migrating.Home.Agents], the HA functionality is copied to 335 many locations. The HoA of all MNs are anycast addresses, so that a 336 packet destined to the HoA from any corresponding node (CN) from any 337 network can be routed via the nearest copy of the HA. In addition, 338 distributing the function of HA using a distributed hash table 339 structure is proposed in [Paper-Distributed.Mobility.SAE]. A lookup 340 query to the hash table will retrieve the location information of an 341 MN is stored. 343 In [Paper-Distributed.Mobility.PMIP], only the mobility routing (MR) 344 function is duplicated and distributed in many locations. The 345 location information for any MN that has moved to a visited network 346 is still centralized and kept at a location management (LM) function 347 in the home network of the MN. The LM function at different networks 348 constitutes a distributed database system of all the MNs that belong 349 to any of these networks and have moved to a visited network. The 350 location information is maintained in the form of a hierarchy: the LM 351 at the home network, the CoA of the MR of the visited network, and 352 then the CoA to reach the MN in the visited network. The LM in the 353 home network keeps a binding of the HoA of the MN to the CoA of the 354 MR of the visited network. The MR keeps the binding of the HoA of 355 the MN to the CoA of the MN in the case of MIP, or the proxy-CoA of 356 the Mobile Access Gateway (MAG) serving the MN in the case of PMIP. 358 [I-D.jikim-dmm-pmip] discusses two distributed mobility control 359 schemes using the PMIP protocol: Signal-driven PMIP (S-PMIP) and 360 Signal-driven Distributed PMIP (SD-PMIP). S-PMIP is a partially 361 distributed scheme, in which the control plane (using a Proxy Binding 362 Query to get the Proxy-CoA of the MN) is separate from the data 363 plane, and the optimized data path is directly between the CN and the 364 MN. SD-PMIP is a fully distributed scheme, in which the Proxy 365 Binding Update is not performed, and instead each MAG will multicast 366 a Proxy Binding Query message to all of the MAGs in its local PMIP 367 domain to retrieve the Proxy-CoA of the MN. 369 4. Problem statement 371 This section identifies problems and limitations of centralized 372 mobility approaches, and compares against possible distributed 373 approaches. A few other related problems that may not be specific to 374 the centralized approach are also described. 376 4.1. Non-optimal routes 378 PS1: Routing via a centralized anchor often results in a longer 379 route, and the problem is especially manifested when accessing 380 a local or cache server of a Content Delivery Network (CDN). 382 Figure 3 shows two cases of non-optimized routes. 384 MIP/PMIP 385 +------+ 386 |HA/LMA| 387 +------+ 388 /\ \ \ +---+ 389 / \ \ \ |CDN| 390 / \ \ \ +---+ 391 / \ \ \ | 392 / \ \ \ | 393 +------+ +------+ +------+ +------+ 394 |FA/MAG| |FA/MAG| |FA/MAG| |FA/MAG| 395 +------+ +------+ +------+ +------+ 396 | | 397 ---- ---- 398 | CN | | MN | 399 ---- ---- 401 Figure 3. Non-optimized route when communicating with a CN and when 402 accessing a local or cache server of a CDN. 404 In the first case, the mobile node and the correspondent node are 405 close to each other but are both far from the mobility anchor. 406 Packets destined to the mobile node need to be routed via the 407 mobility anchor, which is not on the shortest path. The second case 408 involves a content delivery network (CDN). A user may obtain content 409 from a server, such as when watching a video. As such usage becomes 410 more popular, resulting in an increase in the core network traffic, 411 service providers may relieve the core network traffic by placing 412 these contents closer to the users in the access network in the form 413 of cache or local CDN servers. Yet as the MN is getting content from 414 a local or cache server of a CDN, even though the server is close to 415 the MN, packets still need to go through the core network to route 416 via the mobility anchor in the home network of the MN, if the MN uses 417 the HoA as its identifier. 419 In a distributed mobility management design, one possibility is to 420 have mobility anchors distributed in different access networks so 421 that packets may be routed via a nearby mobility anchor function, as 422 shown in Figure 4. 424 +---+ 425 |CDN| 426 +---+ 427 | 428 | 429 +------+ +------+ +------+ +------+ 430 | MF | | MF | | MF | | MF | 431 +------+ +------+ +------+ +------+ 432 | | 433 ---- ---- 434 | CN | | MN | 435 ---- ---- 437 Figure 4. Mobile node in any network is served by a close by 438 mobility function. 440 Due to the above limitation, with the centralized mobility anchor 441 design, route optimization extensions to mobility protocols are 442 therefore needed. Whereas the location privacy of each MN may be 443 compromised when the CoA of an MN is given to the CN, those mobility 444 protocol deployments that lack such optimization extensions will 445 encounter non-optimal routes, which affect the performance. 447 In contrast, route optimization may be naturally an integral part of 448 a distributed mobility management design. With the help of such 449 intrinsic route optimization, the data transmission delay will be 450 reduced, by which the data transmission throughputs can be enhanced. 451 Furthermore, the data traffic overhead at the mobility agents such as 452 the HA and the LMA in the core network can be alleviated 453 significantly. 455 4.2. Non-optimality in Evolved Network Architecture 457 PS2: The centralized mobility management can become non-optimal as a 458 network architecture evolves and becomes more flattened. 460 Centralized mobility management is currently deployed to support the 461 existing hierarchical mobile data networks. It leverages on the 462 hierarchical architecture. However, the volume of wireless data 463 traffic continues to increase exponentially. The data traffic 464 increase would require costly capacity upgrade of centralized 465 architectures. It is thus predictable that the data traffic increase 466 will soon overload the centralized data anchor point, e.g., the P-GW 467 in 3GPP EPS. In order to address this issue, a trend in the 468 evolution of mobile networks is to distribute network functions close 469 to access networks. These network functions can be the content 470 servers in a CDN, and also the data anchor point. 472 Mobile networks have been evolving from a hierarchical architecture 473 to a more flattened architecture. In the 3GPP standards, the GPRS 474 network has the hierarchy GGSN "C SGSN "C RNC "C NB (Node B). In 475 3GPP EPS networks, the hierarchy is reduced to P-GW "C S-GW "C eNB 476 (Evolved NB). In some deployments, the P-GW and the S-GW are 477 collocated to further reduce the hierarchy. Reducing the hierarchy 478 this way reduces the number of different physical network elements in 479 the network, contributing to easier system maintenance and lower 480 cost. As mobile networks become more flattened, the centralized 481 mobility management can become non-optimal. Mobility management 482 deployment with distributed architecture is then needed to support 483 the more flattened network and the CDN networks. 485 4.3. Low scalability of centralized route and mobility context 486 maintenance 488 PS3: Setting up such special routes and maintaining the mobility 489 context for each MN is more difficult to scale in a centralized 490 design with a large number of MNs. Distributing the route 491 maintenance function and the mobility context maintenance 492 function among different networks can be more scalable. 494 Special routes are set up to enable session continuity when a 495 handover occurs. Packets sent from the CN need to be tunneled 496 between the HA and FA in MIP and between the LMA and MAG in PMIP. 497 However, these network elements at the ends of the tunnel are also 498 routers performing the regular routing tasks for ordinary packets not 499 involving a mobile node. These ordinary packets need to be directly 500 routed according to the routing table in the routers without 501 tunneling. Therefore, the network must be able to distinguish those 502 packets requiring tunneling from the regular packets. For each 503 packet that requires tunneling owing to mobility, the network will 504 encapsulate it with a proper outer IP header with the proper source 505 and destination IP addresses. The network therefore needs to 506 maintain and manage the mobility context of each MN, which is the 507 relevant information needed to characterize the mobility situation of 508 that MN to allow the network to distinguish their packets from other 509 packets and to perform the required tunneling. 511 Setting up such special routes and maintaining the mobility context 512 for each MN is more difficult to scale in a centralized design with a 513 large number of MNs. Distributing the route maintenance function and 514 the mobility context maintenance function among different networks 515 can be more scalable. 517 4.4. Single point of failure and attack 519 PS4: Centralized anchoring may be more vulnerable to single point of 520 failure and attack than a distributed system. 522 A centralized anchoring architecture is generally more vulnerable to 523 a single point of failure or attack, requiring duplication and 524 backups of the support functions. 526 On the other hand, a distributed mobility management architecture has 527 intrinsically mitigated the problem to a local network which is then 528 of a smaller scope. In addition, the availability of such functions 529 in neighboring networks has already provided the needed architecture 530 to support protection. 532 4.5. Wasting resources to support mobile nodes not needing mobility 533 support 535 PS5: IP mobility support is not always required. For example, some 536 applications do not need a stable IP address during handover, 537 i.e., IP session continuity. Sometimes, the entire application 538 session runs while the terminal does not change the point of 539 attachment. In these situations that do not require IP 540 mobility support, network resources are wasted when mobility 541 context is set up. 543 The problem of centralized route and mobility context maintenance is 544 aggravated when the via routes are set up for many more MNs that are 545 not requiring IP mobility support. On the one hand, the network 546 needs to provide mobility support for the increasing number of mobile 547 devices because the existing mobility management has been designed to 548 always provide such support as long as a mobile device is attached to 549 the network. On the other hand, many nomadic users are connected to 550 a network in an office or meeting room. Such users will not move for 551 the entire network session. It has been measured that over two- 552 thirds of a user mobility is local [Paper-Locating.User]. In 553 addition, it is possible to have the intelligence for applications to 554 manage mobility without needing help from the network. Network 555 resources are therefore wasted to provide mobility support for the 556 devices that do not really need it at the moment. 558 It is necessary to dynamically set up the via routes only for MNs 559 that actually undergo handovers and lack higher-layer mobility 560 support. With distributed mobility anchors, such dynamic mobility 561 management mechanism may then also be distributed. Therefore, 562 dynamic mobility and distributed mobility may complement each other 563 and may be integrated. 565 4.6. Other related problems 567 Other related problems that may not be specifically owing to a 568 centralized architecture but are desirable to solve are described in 569 this subsection. 571 4.6.1. Mobility signaling overhead with peer-to-peer communication 573 O-PS1: Wasting resources when mobility signaling (e.g., maintenance 574 of the tunnel, keep alive, etc.) is not turned off for peer- 575 to-peer communication. 577 In peer-to-peer communications, end users communicate by sending 578 packets directly addressed to each other's IP address. However, they 579 need to find each other's IP address first through signaling in the 580 network. While different schemes for this purpose may be used, MIP 581 already has a mechanism to locate an MN and may be used in this way. 582 In particular, MIPv6 Route Optimization (RO) mode enables a more 583 efficient data packets exchange than the bidirectional tunneling (BT) 584 mode, as shown in Figure 5. 586 MIP/PMIP 587 +------+ 588 |HA/LMA| 589 +------+ 590 /\ \ \ 591 / \ \ \ 592 / \ \ \ 593 / \ \ \ 594 / \ \ \ 595 +------+ +------+ +------+ +------+ 596 |FA/MAG| |FA/MAG| |FA/MAG| |FA/MAG| 597 +------+ +------+ +------+ +------+ 598 | | 599 ---- ---- 600 | MN |<--->| CN | 601 ---- ---- 603 Figure 5. Non-optimized route when communicating with CN and when 604 accessing local content. 606 This RO mode is expected to be used whenever possible unless the MN 607 is not interested in disclosing its topological location, i.e., the 608 CoA, to the CN (e.g., for privacy reasons) or some other network 609 constraints are put in place. However, MIPv6 RO mode requires 610 exchanging a significant amount of signaling messages in order to 611 establish and periodically refresh a bidirectional security 612 association (BSA) between an MN and its CN. While the mobility 613 signaling exchange impacts the overall handover latency, the BSA is 614 needed to authenticate the binding update and acknowledgment messages 615 (note that the latter is not mandatory). In addition, the amount of 616 mobility signaling messages increases further when both endpoints are 617 mobile. 619 A dynamic mobility management capability that turns off these 620 signaling when they are not needed will enable the RO mode between 621 two mobile endpoints at minimum or no cost. It will also reduce the 622 handover latency owing to the removal of the extra signaling. These 623 benefits for peer-to-peer communications will encourage the adoption 624 and large-scale deployment of dynamic mobility management. 626 4.6.2. Complicated deployment with too many variants and extensions of 627 MIP 629 O-PS2: Deployment is complicated with many variants and extensions 630 of MIP. When introducing new functions which may add to the 631 complicity, existing solutions are more vulnerable to break. 633 Mobile IP, which has primarily been deployed in a centralized manner 634 for the hierarchical mobile networks, already has numerous variants 635 and extensions including PMIP, Fast MIP (FMIP) [RFC4068] [RFC4988] , 636 Proxy-based FMIP (PFMIP) [RFC5949] , hierarchical MIP (HMIP) 637 [RFC5380] , Dual-Stack Mobile IP (DSMIP) [RFC5454] [RFC5555] and 638 there may be more to come. These different modifications or 639 extensions of MIP have been developed over the years owing to the 640 different needs that are found afterwards. Deployment can then 641 become complicated, especially when interoperability with different 642 deployments is an issue. 644 A desirable feature of mobility management is to be able to work with 645 network architectures of both hierarchical networks and flattened 646 networks, so that the mobility management protocol possesses enough 647 flexibility to support different networks. In addition, one goal of 648 dynamic mobility management is the capability to selectively turn on 649 and off mobility support and certain mobility signaling. Such 650 flexibility in the design is compatible with the goal to integrate 651 different mobility variants as options. Some additional extensions 652 to the base protocols may then be needed to improve the integration 653 while avoiding existing functions to break. 655 5. Requirements 657 After reviewing the problems and limitations of centralized 658 deployment in Section 4, this section states the requirements as 659 follows: 661 5.1. Distributed deployment 663 REQ1: Distributed deployment 665 IP mobility, network access and routing solutions provided by 666 DMM SHALL enable a distributed deployment of mobility 667 management of IP sessions so that the traffic can be routed in 668 an optimal manner without traversing centrally deployed 669 mobility anchors. 671 Motivation: The motivations of this requirement are to match 672 mobility deployment with current trend in network evolution: 673 more cost and resource effective to cache and distribute 674 contents when combining distributed anchors with caching 675 systems (e.g., CDN); improve scalability; avoid single point 676 of failure; mitigate threats being focused on a centrally 677 deployed anchor, e.g., home agent and local mobility anchor. 679 This requirement addresses the problems PS1, PS2, PS3, and PS4 680 explained in Section 4 above. 682 5.2. Transparency to Upper Layers when needed 684 REQ2: Transparency to Upper Layers when needed 686 The DMM solutions SHALL provide transparency above the IP 687 layer when needed. Such transparency is needed, when the 688 mobile hosts or entire mobile networks change their point of 689 attachment to the Internet, for the application flows that 690 cannot cope with a change of IP address. Otherwise the 691 support to maintain a stable home IP address or prefix during 692 handover may be declined. 694 Motivation: The motivation of this requirement is to enable 695 more efficient use of network resources and more efficient 696 routing by not maintaining a stable IP home IP address when 697 there is no such need. 699 This requirement addresses the problems PS5 as well as the other 700 related problem O-PS1 which are explained in Section 4 above. 702 5.3. IPv6 deployment 703 REQ3: IPv6 deployment 705 The DMM solutions SHOULD target IPv6 as primary deployment and 706 SHOULD NOT be tailored specifically to support IPv4, in 707 particular in situations where private IPv4 addresses and/or 708 NATs are used. 710 Motivation: The motivation for this requirement is to be 711 inline with the general orientation of IETF. Moreover, DMM 712 deployment is foreseen in mid-term/long-term, hopefully in an 713 IPv6 world. It is also unnecessarily complex to solve this 714 problem for IPv4, as we will not be able to use some of the 715 IPv6-specific features/tools. 717 5.4. Compatibility 719 REQ4: Compatibility 721 The DMM solution SHOULD be able to work between trusted 722 administrative domains when allowed by the security measures 723 deployed between these domains. Furthermore, the DMM solution 724 SHOULD preserve backwards compatibility with existing network 725 deployment and end hosts. For example, depending on the 726 environment in which dmm is deployed, the dmm solutions may 727 need to be compatible with other existing mobility protocols 728 that are deployed in that environment or may need to be 729 interoperable with the network or the mobile hosts/routers 730 that do not support the dmm enabling protocol. 732 Motivation: The motivation of this requirement is to allow 733 inter-domain operation if desired and to preserve backwards 734 compatibility so that the existing networks and hosts are not 735 affected and do not break. 737 5.5. Existing mobility protocols 739 REQ5: Existing mobility protocols 741 A DMM solution SHOULD first consider reusing and extending the 742 existing mobility protocols before specifying new protocols. 744 Motivation: The purpose is to reuse the existing protocols 745 first before considering new protocols. 747 5.6. Security considerations 749 REQ6: Security considerations 751 The protocol solutions for DMM SHALL consider security, for 752 example authentication and authorization mechanisms that allow 753 a legitimate mobile host/router to access to the DMM service, 754 protection of signaling messages of the protocol solutions in 755 terms of authentication, data integrity, and data 756 confidentiality, opti-in or opt-out data confidentiality to 757 signaling messages depending on network environments or user 758 requirements. 760 Motivation and problem statement: Mutual authentication and 761 authorization between a mobile host/router and an access 762 router providing the DMM service to the mobile host/router are 763 required to prevent potential attacks in the access network of 764 the DMM service. Otherwise, various attacks such as 765 impersonation, denial of service, man-in-the-middle attacks, 766 etc. are present to obtain illegitimate access or to collapse 767 the DMM service. 769 Signaling messages are subject to various attacks since these 770 messages carry context of a mobile host/router. For instance, 771 a malicious node can forge and send a number of signaling 772 messages to redirect traffic to a specific node. 773 Consequently, the specific node is under a denial of service 774 attack, whereas other nodes are not receiving their traffic. 775 As signaling messages travel over the Internet, the end-to-end 776 security is required. 778 6. Security Considerations 780 Distributed mobility management (DMM) requires two kinds of security 781 considerations: 1) access network security that only allows a 782 legitimate mobile host/router to access the DMM service; 2) end-to- 783 end security that protects signaling messages for the DMM service. 784 Access network security is required between the mobile host/router 785 and the access network providing the DMM service. End-to-end 786 security is required between nodes that participate in the DMM 787 protocol. 789 It is necessary to provide sufficient defense against possible 790 security attacks, or to adopt existing security mechanisms and 791 protocols to provide sufficient security protections. For instance, 792 EAP based authentication can be used for access network security, 793 while IPsec can be used for end-to-end security. 795 7. IANA Considerations 797 None 799 8. Co-authors and Contributors 801 This problem statement document is a joint effort among the following 802 participants. Each individual has made significant contributions to 803 this work. 805 Dapeng Liu: liudapeng@chinamobile.com 807 Pierrick Seite: pierrick.seite@orange-ftgroup.com 809 Hidetoshi Yokota: yokota@kddilabs.jp 811 Charles E. Perkins: charliep@computer.org 813 Melia Telemaco: telemaco.melia@alcatel-lucent.com 815 Elena Demaria: elena.demaria@telecomitalia.it 817 Peter McCann: Peter.McCann@huawei.com 819 Wassim Michel Haddad: Wassam.Haddad@ericsson.com 821 Hui Deng: denghui@chinamobile.com 823 Tricci So: tso@zteusa.com 825 Jong-Hyouk Lee: jh.lee@telecom-bretagne.eu 827 Seok Joo Koh: sjkoh@knu.ac.kr 829 9. References 831 9.1. Normative References 833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, March 1997. 836 9.2. Informative References 838 [I-D.ietf-netext-pd-pmip] 839 Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and 840 C. Bernardos, "Prefix Delegation for Proxy Mobile IPv6", 841 draft-ietf-netext-pd-pmip-02 (work in progress), 842 March 2012. 844 [I-D.jikim-dmm-pmip] 845 Kim, J., Koh, S., Jung, H., and Y. Han, "Use of Proxy 846 Mobile IPv6 for Distributed Mobility Control", 847 draft-jikim-dmm-pmip-00 (work in progress), March 2012. 849 [I-D.yokota-dmm-scenario] 850 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 851 scenarios for Distributed Mobility Management", 852 draft-yokota-dmm-scenario-00 (work in progress), 853 October 2010. 855 [Paper-Distributed.Centralized.Mobility] 856 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 857 or Centralized Mobility", Proceedings of Global 858 Communications Conference (GlobeCom), December 2009. 860 [Paper-Distributed.Dynamic.Mobility] 861 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 862 Dynamic Mobility Management Scheme Designed for Flat IP 863 Architectures", Proceedings of 3rd International 864 Conference on New Technologies, Mobility and Security 865 (NTMS), 2008. 867 [Paper-Distributed.Mobility.PMIP] 868 Chan, H., "Proxy Mobile IP with Distributed Mobility 869 Anchors", Proceedings of GlobeCom Workshop on Seamless 870 Wireless Mobility, December 2010. 872 [Paper-Distributed.Mobility.Review] 873 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 874 "Distributed and Dynamic Mobility Management in Mobile 875 Internet: Current Approaches and Issues, Journal of 876 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 877 Proceedings of GlobeCom Workshop on Seamless Wireless 878 Mobility, February 2011. 880 [Paper-Distributed.Mobility.SAE] 881 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 882 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 883 Proceedings of the 19th International Symposium on 884 Personal, Indoor and Mobile Radio Communications (PIMRC), 885 2008. 887 [Paper-Locating.User] 888 Kirby, G., "Locating the User", Communication 889 International, 1995. 891 [Paper-Migrating.Home.Agents] 892 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 893 Agents Towards Internet-scale Mobility Deployments", 894 Proceedings of the ACM 2nd CoNEXT Conference on Future 895 Networking Technologies, December 2006. 897 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 898 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 899 RFC 3963, January 2005. 901 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 902 July 2005. 904 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 905 RFC 4988, October 2007. 907 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 908 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 910 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 911 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 912 Management", RFC 5380, October 2008. 914 [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile 915 IPv4", RFC 5454, March 2009. 917 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 918 Routers", RFC 5555, June 2009. 920 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 921 Mobile IPv6", RFC 5844, May 2010. 923 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 924 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 925 September 2010. 927 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 928 in IPv6", RFC 6275, July 2011. 930 Author's Address 932 H Anthony Chan (editor) 933 Huawei Technologies 934 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 935 Email: h.a.chan@ieee.org 936 - 937 Dapeng Liu 938 China Mobile 939 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 940 Email: liudapeng@chinamobile.com 941 - 942 Pierrick Seite 943 France Telecom - Orange 944 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 945 Email: pierrick.seite@orange-ftgroup.com 946 - 947 Hidetoshi Yokota 948 KDDI Lab 949 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 950 Email: yokota@kddilabs.jp 951 - 952 Charles E. Perkins 953 Huawei Technologies 954 Email: charliep@computer.org 955 - 956 Jouni Korhonen 957 Nokia Siemens Networks 958 Email: jouni.korhonen@nsn.com 959 - 960 Melia Telemaco 961 Alcatel-Lucent Bell Labs 962 Email: telemaco.melia@alcatel-lucent.com 963 - 964 Elena Demaria 965 Telecom Italia 966 via G. Reiss Romoli, 274, TORINO, 10148, Italy 967 Email: elena.demaria@telecomitalia.it 968 - 969 Jong-Hyouk Lee 970 RSM Department, Telecom Bretagne 971 Cesson-Sevigne, 35512, France 972 Email: jh.lee@telecom-bretagne.eu 973 - 974 Tricci So 975 ZTE 976 Email: tso@zteusa.com 977 - 978 Carlos J. Bernardos 979 Universidad Carlos III de Madrid 980 Av. Universidad, 30, Leganes, Madrid 28911, Spain 981 Email: cjbc@it.uc3m.es 982 - 983 Peter McCann 984 Huawei Technologies 985 Email: PeterMcCann@huawei.com 986 - 987 Seok Joo Koh 988 Kyungpook National University, Korea 989 Email: sjkoh@knu.ac.kr 990 - 991 Wen Luo 992 ZTE 993 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 994 Email: luo.wen@zte.com.cn 995 -