idnits 2.17.1 draft-zuniga-dmm-gap-analysis-03.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 -- The document date (December 19, 2012) is 4146 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-02 == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-05 == Outdated reference: A later version (-02) exists of draft-seite-mif-cm-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM WG JC. Zuniga 3 Internet-Draft InterDigital 4 Intended status: Informational CJ. Bernardos 5 Expires: June 22, 2013 UC3M 6 T. Melia 7 Alcatel-Lucent 8 C. Perkins 9 Futurewei 10 December 19, 2012 12 Mobility Practices and DMM Gap Analysis 13 draft-zuniga-dmm-gap-analysis-03 15 Abstract 17 This document describes practices for the deployment of existing 18 mobility protocols in a distributed mobility management (DMM) 19 environment, and identifies the limitations in the current practices 20 with respect to providing the expected DMM functionality. 22 The practices description and gap analysis are performed for IP-based 23 mobility protocols, dividing them into three main families: IP 24 client-based, IP network-based, and 3GPP mobility solutions. 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 June 22, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Practices: deployment of existing solutions in a DMM 62 fashion . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Client-based IP mobility . . . . . . . . . . . . . . . . . 4 64 2.1.1. Mobile IPv6 / NEMO . . . . . . . . . . . . . . . . . . 5 65 2.1.2. Mobile IPv6 Route Optimization . . . . . . . . . . . . 6 66 2.1.3. Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . 7 67 2.1.4. Home Agent switch . . . . . . . . . . . . . . . . . . 8 68 2.1.5. IP Flow Mobility . . . . . . . . . . . . . . . . . . . 8 69 2.1.6. Source Address Selection . . . . . . . . . . . . . . . 8 70 2.2. Network-based IP mobility . . . . . . . . . . . . . . . . 9 71 2.2.1. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . 9 72 2.2.2. Local Routing . . . . . . . . . . . . . . . . . . . . 10 73 2.2.3. LMA runtime assignment . . . . . . . . . . . . . . . . 10 74 2.2.4. Source Address Selection . . . . . . . . . . . . . . . 11 75 2.2.5. Multihoming in PMIPv6 . . . . . . . . . . . . . . . . 11 76 2.3. 3GPP mobility . . . . . . . . . . . . . . . . . . . . . . 11 77 2.3.1. GPRS Tunnelling Protocol (GTP) and DSMIPv6 . . . . . . 12 78 2.3.2. Local IP Access and Selected IP Traffic Offload 79 (LIPA-SIPTO) . . . . . . . . . . . . . . . . . . . . . 13 80 2.3.3. LIPA Mobility and SIPTO at the Local Network 81 (LIMONET) . . . . . . . . . . . . . . . . . . . . . . 13 82 2.3.4. Data IDentification in ANDSF (DIDA) and Operator 83 Policies for IP Interface Selection (OPIIS) . . . . . 13 84 2.3.5. Multi-Access PDN Connectivity (MAPCON) . . . . . . . . 14 85 3. Gap Analysis: limitations in current practices . . . . . . . . 14 86 3.1. Client-based IP mobility . . . . . . . . . . . . . . . . . 14 87 3.1.1. REQ1: Distributed deployment . . . . . . . . . . . . . 14 88 3.1.2. REQ2: Transparency to Upper Layers when needed . . . . 15 89 3.1.3. REQ3: IPv6 deployment . . . . . . . . . . . . . . . . 16 90 3.1.4. REQ4: Existing mobility protocols . . . . . . . . . . 16 91 3.1.5. REQ5: Compatibility . . . . . . . . . . . . . . . . . 17 92 3.1.6. REQ6: Security considerations . . . . . . . . . . . . 17 93 3.2. Network-based IP mobility . . . . . . . . . . . . . . . . 18 94 3.2.1. REQ1: Distributed deployment . . . . . . . . . . . . . 18 95 3.2.2. REQ2: Transparency to Upper Layers when needed . . . . 19 96 3.2.3. REQ3: IPv6 deployment . . . . . . . . . . . . . . . . 20 97 3.2.4. REQ4: Existing mobility protocols . . . . . . . . . . 20 98 3.2.5. REQ5: Compatibility . . . . . . . . . . . . . . . . . 20 99 3.2.6. REQ6: Security considerations . . . . . . . . . . . . 21 100 3.3. 3GPP mobility . . . . . . . . . . . . . . . . . . . . . . 21 101 3.3.1. REQ1: Distributed deployment . . . . . . . . . . . . . 21 102 3.3.2. REQ2: Transparency to Upper Layers when needed . . . . 21 103 3.3.3. REQ3: IPv6 deployment . . . . . . . . . . . . . . . . 21 104 3.3.4. REQ4: Existing mobility protocols . . . . . . . . . . 21 105 3.3.5. REQ5: Compatibility . . . . . . . . . . . . . . . . . 22 106 3.3.6. REQ6: Security considerations . . . . . . . . . . . . 22 107 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 4.1. Independent solution analysis . . . . . . . . . . . . . . 22 109 4.2. Functional analysis . . . . . . . . . . . . . . . . . . . 23 110 4.2.1. Multiple anchoring . . . . . . . . . . . . . . . . . . 23 111 4.2.2. Dynamic anchor assignment . . . . . . . . . . . . . . 24 112 4.2.3. Multiple address management . . . . . . . . . . . . . 25 113 4.3. Combined solutions analysis . . . . . . . . . . . . . . . 26 114 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 115 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 116 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 117 7.1. Normative References . . . . . . . . . . . . . . . . . . . 27 118 7.2. Informative References . . . . . . . . . . . . . . . . . . 28 119 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 122 1. Introduction 124 The Distributed Mobility Management (DMM) approach aims at setting up 125 IP networks so that traffic is distributed in an optimal way and does 126 not rely on centrally deployed anchors to manage IP mobility 127 sessions. 129 A first step towards the definition of DMM solutions is the 130 definition of the problem of distributed mobility management and the 131 identification of the main requirements for a distributed mobility 132 management solution [I-D.ietf-dmm-requirements]. 134 We first analyze existing practices of deployment of IP mobility 135 solutions from a DMM perspective [I-D.perkins-dmm-matrix], 136 [I-D.patil-dmm-issues-and-approaches2dmm]. After that, a gap 137 analysis is carried out, identifying what can be achieved with 138 existing solutions and what is missing in order to meet the DMM 139 requirements identified in [I-D.ietf-dmm-requirements]. 141 2. Practices: deployment of existing solutions in a DMM fashion 143 This section documents practices for the deployment of existing 144 mobility protocols in a distributed mobility management (DMM) 145 fashion. The scope is limited to existing IPv6-based and 3GPP 146 mobility protocols, such as Mobile IPv6 [RFC6275], NEMO Basic Support 147 Protocol [RFC3963], Proxy Mobile IPv6 [RFC5213], 3GPP GPRS Tunnelling 148 Protocol, and protocol extensions, such as Hierarchical Mobile IPv6 149 [RFC5380], Mobile IPv6 Fast Handovers [RFC5568], Localized Routing 150 for Proxy Mobile IPv6 [RFC6705], or 3GPP Selective IP Traffic Offload 151 (SIPTO), among others [RFC6301]. 153 The section is divided in three parts: IP client-based mobility, IP 154 network-based mobility and 3GPP mobility solutions. 156 2.1. Client-based IP mobility 158 Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile 159 networks, the NEMO Basic Support protocol (hereafter, simply NEMO) 160 [RFC3963] are well-known client-based IP mobility protocols. They 161 heavily rely on the function of the Home Agent (HA), a centralized 162 anchor, to provide mobile nodes (hosts and routers) with mobility 163 support. We next describe how Mobile IPv6/NEMO and several 164 additional protocol extensions can be deployed to meet some of the 165 DMM requirements [I-D.ietf-dmm-requirements]. 167 2.1.1. Mobile IPv6 / NEMO 169 <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> 170 ------- ------- 171 | CN1 | ------- | AR1 |-(o) zzzz (o) 172 ------- | HA1 | ------- | 173 ------- (MN1 anchored at HA1) ------- 174 ------- | MN1 | 175 | AR2 |-(o) ------- 176 ------- 177 ------- 178 | HA2 | ------- 179 ------- | AR3 |-(o) zzzz (o) 180 ------- | 181 ------- (MN2 anchored at HA2) ------- 182 | CN2 | ------- | MN2 | 183 ------- | AR4 |-(o) ------- 184 ------- 186 CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 187 | | | | | | | | 188 |<------------>|<=================+=====>| | | BT mode 189 | | | | | | | | 190 | |<----------------------------------------+----->| RO mode 191 | | | | | | | | 193 Figure 1: Distributed operation of Mobile IPv6 (BT and RO) / NEMO 195 Due to the heavy dependence on the home agent role, the base Mobile 196 IPv6 and NEMO protocols (i.e., without additional extensions) cannot 197 be easily deployed in a distributed fashion. One approach to 198 distribute the anchors can be to deploy several HAs (as shown in 199 Figure 1), and assign to each MN the one closest to its topological 200 location [RFC4640], [RFC5026], [RFC6611]. In the example shown in 201 Figure 1, MN1 is assigned HA1 (and a home address anchored by HA1), 202 while MN2 is assigned HA2. Note that current Mobile IPv6 / NEMO 203 specifications do not allow the simultaneous use of multiple home 204 agents by a single mobile node instance, and therefore the benefits 205 of this deployment model shown here are limited (unless multiple 206 MIPv6 MN instances are run in parallel, each of them associated to a 207 different HA). For example, if MN1 moves and attaches to AR3, the 208 path followed by data packets would be suboptimal, as they have to 209 traverse HA1, which is no longer close to the topological attachment 210 point of MN1. 212 2.1.2. Mobile IPv6 Route Optimization 214 One of the main goals of DMM is to avoid the suboptimal routing 215 caused by centralized anchoring. By default, Mobile IPv6 and NEMO 216 use the so-called Bidirectional Tunnel (BT) mode, in which data 217 traffic is always encapsulated between the MN and its HA before being 218 directed to any other destination. Mobile IPv6 also specifies the 219 Route Optimization (RO) mode, which allows the MN to update its 220 current location on the CNs, and then use the direct path between 221 them. Using the example shown in Figure 1, MN1 is using BT mode with 222 CN2 and MN2 is in RO mode with CN1. However, the RO mode has several 223 drawbacks: 225 o The RO mode is only supported by Mobile IPv6. There is no route 226 optimization support standardized for the NEMO protocol, although 227 many different solutions have been proposed. 229 o The RO mode requires additional signaling, which adds some 230 protocol overhead. 232 o The signaling required to enable RO involves the home agent, and 233 it is repeated periodically because of security reasons [RFC4225]. 234 This basically means that the HA remains as single point of 235 failure, because the Mobile IPv6 RO mode does not mean HA-less 236 operation. 238 o The RO mode requires additional support on the correspondent node 239 (CN). 241 Notwithstanding these considerations, the RO mode does offer the 242 possibility of substantially reducing traffic through the Home Agent, 243 in cases when it can be supported on the relevant correspondent 244 nodes. 246 2.1.3. Hierarchical Mobile IPv6 248 <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK -------> 249 ----- 250 /|AR1|-(o) zz (o) 251 -------- / ----- | 252 | MAP1 |< ------- 253 -------- \ ----- | MN1 | 254 ------- \|AR2| ------- 255 | CN1 | ----- HoA anchored 256 ------- ----- at HA1 257 ------- /|AR3| RCoA anchored 258 | HA1 | -------- / ----- at MAP1 259 ------- | MAP2 |< LCoA anchored 260 -------- \ ----- at AR1 261 \|AR4| 262 ------- ----- 263 | CN2 | ----- 264 ------- /|AR5| 265 -------- / ----- 266 | MAP3 |< 267 -------- \ ----- 268 \|AR6| 269 ----- 271 CN1 CN2 HA1 MAP1 AR1 MN1 272 | | | | ________|__________ | 273 |<------------------>|<==============>|<________+__________>| HoA 274 | | | | | | 275 | |<-------------------------->|<===================>| RCoA 276 | | | | | | 278 Figure 2: Hierarchical Mobile IPv6 280 Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] allows reducing the 281 amount of mobility signaling as well as improving the overall 282 handover performance of Mobile IPv6 by introducing a new hierarchy 283 level to handle local mobility. The Mobility Anchor Point (MAP) 284 entity is introduced as a local mobility handling node deployed 285 closer to the mobile node. 287 When HMIPv6 is used, the MN has two different temporal addresses: the 288 Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA). 289 The RCoA is anchored at one MAP, that plays the role of local home 290 agent, while the LCoA is anchored at the access router level. The 291 mobile node uses the RCoA as the CoA signaled to its home agent. 292 Therefore, while roaming within a local domain handled by the same 293 MAP, the mobile node does not need to update its home agent (i.e., 294 the mobile node does not change RCoA). 296 The use of HMIPv6 allows some route optimization, as a mobile node 297 may decide to directly use the RCoA as source address for a 298 communication with a given correspondent node, notably if the MN does 299 not expect to move outside the local domain during the lifetime of 300 the communication. This can be seen as a potential DMM mode of 301 operation. In the example shown in Figure 2, MN1 is using its global 302 HoA to communicate with CN1, while it is using its RCoA to 303 communicate with CN2. 305 Additionally, a local domain might have several MAPs deployed, 306 enabling hence different kind of HMIPv6 deployments (e.g., flat and 307 distributed). The HMIPv6 specification supports a flexible selection 308 of the MAP (e.g., based on the distance between the MN and the MAP, 309 taking into consideration the expected mobility pattern of the MN, 310 etc.). 312 2.1.4. Home Agent switch 314 The Home Agent switch specification [RFC5142] defines a new mobility 315 header for signaling a mobile node that it should acquire a new home 316 agent. Although the purposes of this specification do not include 317 the case of changing the mobile node's home address, as that might 318 imply loss of connectivity for ongoing persistent connections, it 319 could be used to force the change of home agent in those situations 320 where there are no active persistent data sessions that cannot cope 321 with a change of home address. 323 2.1.5. IP Flow Mobility 325 There are different specifications meant to support IP Flow Mobility 326 (IFOM) with Mobile IPv6, namely the multiple care-of address 327 registration [RFC5648], the flow bindings in Mobile IPv6 and NEMO 328 [RFC6089] and the traffic selectors for flow bindings [RFC6088]. The 329 use of these extensions allows a mobile node to associate different 330 flows with different care-of addresses that the mobile owns at a 331 given time. This could also be used, combined with the route 332 optimization support, to improve the paths followed by data packets, 333 avoiding the traversal of the core network for selected flows. 335 2.1.6. Source Address Selection 337 The IPv6 socket API for source address selection [RFC5014], [RFC6724] 338 can be used by an application running on a mobile node to express its 339 preference of using a home address or a care-of address in a given 340 connection. This allows, for example, an application which can 341 survive an IP address change to always prefer the use of a care-of 342 address. Similarly, and as mentioned in [RFC6275], a mobile node can 343 also prefer the use of a care-of address for sessions that are going 344 to finish before the mobile node hands off to a different attachment 345 point (e.g., short-lived connections like DNS dialogs). This could 346 be based on user or operator policies, and it is typically performed 347 by a connection manager (e.g., [I-D.seite-mif-cm]). 349 2.2. Network-based IP mobility 351 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP 352 mobility protocol specified for IPv6. Architecturally, PMIPv6 is 353 similar to MIPv6, as it relies on the function of the Local Mobility 354 Anchor (LMA) to provide mobile nodes with mobility support, without 355 requiring the involvement of the mobile nodes. The required 356 functionality at the mobile node is provided in a proxy manner by the 357 Mobile Access Gateway (MAG). We next describe how network-based 358 mobility protocols and several additional extensions can be deployed 359 to meet some of the DMM requirements [I-D.ietf-dmm-requirements]. 361 2.2.1. Proxy Mobile IPv6 363 <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> 364 ------- 365 | CN1 | -------- -------- -------- 366 ------- -------- | MAG1 | | MAG2 | | MAG3 | 367 | LMA1 | ---+---- ---+---- ---+---- 368 ------- -------- | | | 369 | CN2 | (o) (o) (o) 370 ------- -------- x x 371 | LMA2 | x x 372 ------- -------- (o) (o) 373 | CN3 | | | 374 ------- ---+--- ---+--- 375 Anchored | MN1 | Anchored | MN2 | 376 at LMA1 -> ------- at LMA2 -> ------- 378 CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2 379 | | | | | | | | 380 |<------------>|<================>|<---->| | | 381 | | | | | | | | 382 | |<------------>|<========================>|<----->| 383 | | | | | | | | 385 Figure 3: Distributed operation of Proxy Mobile IPv6 387 As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be 388 easily decentralized, as in this case there also exists a single 389 network anchor point. One simple but still suboptimal approach, 390 would be to deploy several local mobility anchors and use a 391 topological position-based assignment to attach mobile nodes (an 392 example of this type of assignment is shown in Figure 3. This 393 assignment can be static or dynamic (as described in Section 2.2.3). 394 The main advantage of this simple approach is that the IP address 395 anchor (i.e., the LMA) is placed close to the mobile node, and 396 therefore resulting paths are close-to-optimal. On the other hand, 397 as soon as the mobile node moves, the resulting path starts to 398 deviate from the optimal one. 400 2.2.2. Local Routing 402 [RFC6705] enables optimal routing in Proxy Mobile IPv6 in three 403 cases: i) when two communicating MNs are attached to the same MAG and 404 LMA, ii) when two communicating MNs are attached to different MAGs 405 but to the same LMA, and iii) when two communicating MNs are attached 406 to the same MAG but have different LMAs. In these three cases, data 407 traffic between the two mobile nodes does not traverse the LMA(s), 408 thus providing some form of path optimization since the traffic is 409 locally routed at the edge. 411 The main disadvantage of this approach is that it only tackles the 412 MN-to-MN communication scenario, and only under certain 413 circumstances. 415 In the context of 3GPP, the closest analogy is the use of the X2 416 interface between two eNBs to directly exchange data traffic during 417 handover procedures. 3GPP does not foresee the use of local routing 418 at any other point of the network given the structure of the EPS 419 bearer model. 421 2.2.3. LMA runtime assignment 423 [RFC6463] specifies a runtime local mobility anchor assignment 424 functionality and corresponding mobility options for Proxy Mobile 425 IPv6. This runtime local mobility anchor assignment takes place 426 during the Proxy Binding Update / Proxy Binding Acknowledgment 427 message exchange between a mobile access gateway and a local mobility 428 anchor. While this mechanism is mainly aimed for load-balancing 429 purposes, it can also be used to select an optimal LMA from the 430 routing point of view. A runtime LMA assignment can be used to 431 change the assigned LMA of an MN, for example in case when the mobile 432 node does not have any session active, or when running sessions can 433 survive an IP address change. 435 2.2.4. Source Address Selection 437 Also in the context of network-based mobility, the use of a source 438 address selection API can be considered as means to achieve better 439 routing (by using different anchors). For instance, an MN connected 440 to a PMIPv6 domain could attach two different wireless network 441 interfaces to two different MAGs, hence configuring a different set 442 of HNPs on both interfaces (potentially combining both IPv4 and 443 IPv6). Based on application requirements or operator's policies the 444 connection manager logic could instruct the IP stack on the MN to 445 route selected traffic on a specific wireless interface 446 [I-D.seite-mif-cm]. It should be noted that source address selection 447 mostly provides for better routing but not session continuity. 449 2.2.5. Multihoming in PMIPv6 451 PMIPv6 provides some multihoming support. RFC 5213 specifies that 452 the LMA can maintain one mobility session per attached interface and 453 that upon handover the full set of HNPs can be moved to another 454 interface in case of inter-technology handover (MAGs providing 455 different wireless access technology) or maintained on the same 456 interface in case of intra-technology handover (MAGs providing the 457 same wireless access technology). An MN can also attach two 458 different interfaces to the same PMIPv6 domain (as described in 459 Section 2.2.4), hence resulting in a multihomed device being able to 460 send/receive traffic sequentially or simultaneously from both network 461 interfaces. [I-D.ietf-netext-pmipv6-flowmob] extends the base 462 RFC5213 capabilities so that a mobility session can be shared across 463 two different access networks. It derives that a selected flow could 464 be routed through different paths, hence achieving some sort of 465 better routing. Yet all the traffic is anchored at centralized 466 anchor points. 468 2.3. 3GPP mobility 470 Architecturally, the 3GPP Evolved Packet Core (EPC) network is also 471 similar to PMIPv6 and MIPv6, as it relies on the Packet Data Gateway 472 (PGW) anchoring services to provide mobile nodes with mobility 473 support (see Figure 4). There are client-based and network-based 474 mobility solutions in 3GPP, which for simplicity we will analyze 475 together. We next describe how 3GPP mobility protocols and several 476 additional completed or on-going extensions can be deployed to meet 477 some of the DMM requirements. [I-D.ietf-dmm-requirements]. 479 +---------------------------------------------------------+ 480 | PCRF | 481 +-----------+--------------------------+----------------+-+ 482 | | | 483 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 484 | | | +-+ | | Core Network | | | 485 | | | +------+ |S|__ | | +--------+ +---+ | | | 486 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 487 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 488 | | | +------+ |N| +-+-+ | | | | | | | x | 489 | | | +-+ /|MME| | | +---+----+ | | | | t | 490 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 491 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 492 | | | +---------+\ | | | SERVER | | | | | n | 493 | | | \ +---+ | | +--------+ | | | | a | 494 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 495 | | | +---+ | | | G | | | | 496 | | +------------------------+ | | W | | | I | 497 | UE | | | | | | P | 498 | | +------------------------+ | | +-----+ | 499 | | |+-------------+ +------+| | | | | | n | 500 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 501 | +---+| non-3GPP AN | +------+| | | | | | t | 502 | | |+-------------+ | | | | | | w | 503 | | +------------------------+ | | | | | o | 504 | | | | | | | r | 505 | | +------------------------+ | | | | | k | 506 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 507 | | +------------------------+ | | | | | | 508 | | | +-+-+ | | | 509 | +--------------------------S2c--------------------| | | | 510 | | | | | | 511 +----+ +--------------------+ +---+ 513 Figure 4: EPS (non-roaming) architecture overview 515 2.3.1. GPRS Tunnelling Protocol (GTP) and DSMIPv6 517 GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based 518 mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8 519 interfaces). Similar to PMIPv6, it can handle mobility without 520 requiring the involvement of the mobile nodes. In this case, the 521 mobile node functionality is provided in a proxy manner by the 522 Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or 523 Trusted Wireless Access Gateway (TWAG). 525 3GPP specifications also include client-based mobility support, based 526 on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for 527 the S2c interface. In this case, the UE implements the mobile node 528 functionality, while the home agent role is played by the PGW. 530 2.3.2. Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO) 532 A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) 533 enabled network [3GPP.23.829] allows offloading some IP services at 534 the local access network, above the Radio Access Network (RAN) or at 535 the macro, without the need to traverse back to the PGW. 537 Similarly to the runtime local mobility anchor assignment described 538 in Section 2.2.3, considerations have been discussed in 3GPP with 539 respect to SIPTO. SIPTO enables an operator to offload certain types 540 of traffic at a network node close to the UE's point of attachment to 541 the access network, by selecting a set of GWs (SGW and PGW) that is 542 geographically/topologically close to the UE's point of attachment. 544 LIPA, on the other hand, enables an IP capable UE connected via a 545 Home eNB (HeNB) to access other IP capable entities in the same 546 residential/enterprise IP network without the user plane traversing 547 the mobile operator's network core. In order to achieve this, a 548 Local GW (L-GW) collocated with the HeNB is used. LIPA is 549 established by the UE requesting a new PDN connection to an access 550 point name for which LIPA is permitted, and the network selecting the 551 Local GW associated with the HeNB and enabling a direct user plane 552 path between the Local GW and the HeNB. 554 2.3.3. LIPA Mobility and SIPTO at the Local Network (LIMONET) 556 Both SIPTO and LIPA have a very limited mobility support, specially 557 in 3GPP specifications up to Rel-10. In Rel-11, there is currently a 558 work item on LIPA Mobility and SIPTO at the Local Network (LIMONET) 559 [3GPP.23.859] that is studying how to provide SIPTO and LIPA 560 mechanisms with some additional, but still limited, mobility support. 561 In a glimpse, LIPA mobility support is limited to handovers between 562 HeNBs that are managed by the same L-GW (i.e., mobility within the 563 local domain), while seamless SIPTO mobility is still limited to the 564 case where the SGW/PGW is at or above Radio Access Network (RAN) 565 level. 567 2.3.4. Data IDentification in ANDSF (DIDA) and Operator Policies for IP 568 Interface Selection (OPIIS) 570 There are two ongoing work items in 3GPP that are currently 571 addressing the issue of selecting a wireless interface or an IP 572 address for a specific data application. The work item DIDA (Data 573 IDentification in ANDSF) is addressing the need to map an application 574 ID to a specific wireless interface, while the work item Operator 575 Policies for IP Interface Selection (OPIIS) is addressing the need of 576 selecting the right APN for a given application. 578 Taking into account that there is a one to one link between APN and 579 PDN connection (i.e., IP address) these work items clearly address 580 from a 3GPP perspective the same problem space as [RFC6724], and the 581 same considerations described in Section 2.2.4 apply here as well. 583 2.3.5. Multi-Access PDN Connectivity (MAPCON) 585 The Multi-Access PDN Connectivity (MAPCON) feature addresses the use 586 of multiple PDN connections. Hence, this feature can make use of 587 multiple wireless interfaces either sequentially or simultaneously. 589 3. Gap Analysis: limitations in current practices 591 This section identifies the limitations in the current practices 592 (documented in Section 2) with respect to the requirements listed in 593 [I-D.ietf-dmm-requirements]. 595 The analysis is divided in three parts: IP client-based mobility, IP 596 network-based mobility, and 3GPP mobility solutions. Each part 597 analyzes how well the requirements listed in 598 [I-D.ietf-dmm-requirements] are covered/met by the current practices, 599 highlighting existing limitations and gaps. 601 3.1. Client-based IP mobility 603 3.1.1. REQ1: Distributed deployment 605 MIPv6 / NEMO A careful home agent deployment and policy 606 configuration of the Mobile IPv6 / NEMO protocols can achieve some 607 distribution. However, as soon as the mobile node moves and 608 changes its initial attachment point, the anchors are no longer 609 placed optimally, incurring in sub-optimal routes. This situation 610 may be acceptable as long as the session is short-lived. If the 611 mobile node is not expected to move within a limited area, this 612 configuration might be considered sufficient. Otherwise, 613 additional mechanisms to support dynamic anchoring would be 614 needed. Note that a possible solution would be to run multiple 615 instances of mobile IPv6 at the mobile node, each one managing a 616 different HoA and bound to a different home agent. This would 617 require, though, additional intelligence at the mobile node to be 618 able to optimally select and manage source IP addresses for each 619 session. 621 Mobile IPv6 RO The use of route optimization support enables a 622 close-to anchor-less operation, which effectively can be 623 considered as a fully distributed configuration. However, as 624 explained before in this document, the home agent is still used 625 for the signaling and therefore remains as a critical centralized 626 component. Additionally, there is no standardized RO support for 627 network mobility. 629 HMIPv6 The use of hierarchical mobile IPv6 can be seen as a step 630 forward compared to a careful deployment of multiple home agents 631 and its proper configuration, as it allows a mobile node to roam 632 within a local domain, reducing the handover latency as well as 633 the signaling overhead. If used together with mobile IPv6, 634 traffic still has to traverse the centralized home agent, and 635 therefore no distributed operation is achieved. 637 HA switch The home agent switch specification can be used to enable 638 obtaining more benefits from a multiple-HA deployment, as the 639 mobile node could be instructed to switch to a closer home agent. 640 To avoid packet loss, this switch must be performed at periods of 641 time in which the mobile node does not have any active connection 642 running. Even if some packet loss were acceptable for active 643 sessions, the change of home address would also require the mobile 644 node to re-establish those sessions. 646 Flow mobility Considerations made for previous scenarios (e.g. for 647 Route Optimization) could also apply here, extending those 648 scenarios by the use of multiple attached interfaces. 650 SA selection API The use of proper source address selection 651 decisions, enabled by smart connection managers 652 [I-D.seite-mif-cm], or mobility aware applications using a 653 selection API [RFC5014], [RFC6724], would allow the mobile node to 654 realize substantial benefits from deployments providing multiple 655 anchors. 657 3.1.2. REQ2: Transparency to Upper Layers when needed 659 MIPv6 / NEMO As a mobility protocol, the solution is transparent to 660 the upper layers. However, as described before, this transparency 661 comes with the cost of suboptimal routes if the MN moves away from 662 its initial attachment point. 664 Mobile IPv6 RO The use of the route optimization support is 665 transparent to the upper layers. 667 HMIPv6 The use of HMIPv6 is transparent to the upper layers. 669 HA switch The use of the home agent switch functionality is not 670 transparent to the upper layers, as a change of home agent 671 normally implies a change of home address. Therefore, the home 672 agent can only be switched when there is no active session running 673 on the mobile node. Since IP address continuity cannot be 674 achieved at the relocated home agents, one gap that would need to 675 be filled is the ability for the mobile node to convey HoA context 676 from the previous home agent. 678 Flow mobility The use of flow mobility mechanisms is transparent to 679 the upper layers. 681 SA selection API The use of an intelligent source address mechanisms 682 is transparent to the upper layers if performed by the connection 683 manager. However if the selection is performed by the 684 applications themselves, via the use of the API, then applications 685 have to be mobility-aware. 687 3.1.3. REQ3: IPv6 deployment 689 MIPv6 / NEMO Mobile IPv6 / NEMO protocols primarily support IPv6, 690 although there are some extensions defined to also offer some IPv4 691 support [RFC5555]. 693 Mobile IPv6 RO Route optimization only supports IPv6. 695 HMIPv6 HMIPv6 is only defined for IPv6. 697 HA switch The home agent switch specification supports only IPv6, 698 although the use of the defined mechanisms to support dual stack 699 IPv4/IPv6 mobile nodes would also enable some IPv4 support. 701 Flow mobility Flow mobility is only defined for IPv6. 703 SA selection API The use of source address selection mechanisms 704 supports both IPv6 and IPv4. 706 3.1.4. REQ4: Existing mobility protocols 708 MIPv6 / NEMO These approaches are ones of the base IETF-standardized 709 mobility protocols: [RFC6275] and [RFC3963]. 711 Mobile IPv6 RO This approach is based on an existing protocol 712 [RFC6275]. 714 HMIPv6 This approach is based on an existing protocol [RFC5380]. 716 HA switch This approach is based on an existing protocol [RFC5142]. 718 Flow mobility This approach is based on existing protocols 719 [RFC5648], [RFC6089] and [RFC6088]. 721 SA selection API This approach is based on existing protocols 722 [RFC6724] and [RFC5014]. 724 3.1.5. REQ5: Compatibility 726 MIPv6 / NEMO This approach would be compatible with other protocols 727 and work between trusted administrative domains, although as 728 described before its operation would not provide the benefits of a 729 fully distributed mechanism. The combination of different IP 730 mobility protocols might have a performance/complexity cost 731 associated, as described in [A. de la Oliva, et al.]. 733 Mobile IPv6 RO This approach would be compatible with other 734 protocols and work between trusted administrative domains, as long 735 as mobile IPv6 is allowed. However, as highlighted before, mobile 736 IPv6 route optimization requires specific support at the 737 correspondent nodes. 739 HMIPv6 HMIPv6 is compatible with other protocols. 741 HA switch This approach would be compatible with other protocols and 742 work between trusted administrative domains. 744 Flow mobility This approach would be compatible with other protocols 745 and work between trusted administrative domains. 747 SA selection API This approach has no impact in terms of 748 compatibility or use between trusted administrative domains. 750 3.1.6. REQ6: Security considerations 752 MIPv6 / NEMO This approach includes security considerations. 754 Mobile IPv6 RO This approach includes security considerations. 756 HMIPv6 This approach includes security considerations. 758 HA switch This approach includes security considerations. 760 Flow mobility This approach includes security considerations. 762 SA selection API This approach does not have security issues. 764 3.2. Network-based IP mobility 766 3.2.1. REQ1: Distributed deployment 768 PMIPv6 As for the case of MIPv6, a careful deployment of the local 769 mobility anchors and policy configuration of the Proxy Mobile IPv6 770 protocol can achieve some distribution. However, as soon as the 771 mobile node moves and changes its initial attachment point, the 772 anchor is no longer placed optimally, incurring in sub-optimal 773 routes, which might be quite noticeable in case of medium to large 774 PMIPv6 domains. If the mobile node movement is restricted to a 775 well known limited area and/or the PMIPv6 domain is not large, 776 this configuration might be considered sufficient. Otherwise, 777 additional mechanisms to support dynamic anchoring would be 778 needed. 780 Local Routing As mentioned before, it enables optimal routing in 781 three cases: the LMA manages the traffic of two mobile nodes 782 connected to the same MAG, the LMA manages the traffic of two 783 mobile nodes connected to different MAGs, the MAG manages the 784 traffic of two mobile nodes connected to different LMAs. LR does 785 not consider the case where the traffic should be optimized 786 considering different MAGs and different LMAs. Inter LMA 787 communication is not in scope. LR only enables better routing and 788 does not consider the distribution of mobility anchors as such. 790 LMA Runtime Assignment The LMA runtime assignment is used to 791 allocate an optimal LMA mostly for load balancing purposes, for 792 instance in scenarios where LMAs run in a datacenter-like 793 infrastructure. It can be used to allocate a different LMA based 794 on other policies such as routing, although it is not clear how 795 the technology can be used to achieve distributed mobility 796 management, especially considering scalability issues. There are 797 different gaps that would prevent using this mechanism as a way to 798 meet all the DMM requirements: i) LMA runtime assignment can only 799 performed at the MN's attachment, so it would need to be extended 800 to allow LMA re-location at any time; ii) LMA runtime assignment 801 can only be initiated by current LMA; iii) it is not in the scope 802 of the specification how the context is transferred between the 803 involved LMAs. 805 Source Address Selection It can help in selecting a given IP source 806 address although the current specifications have many limitations 807 (for instance prefer IPv6 over IPv4, prefer HoA instead of CoA) 808 and the socket extensions [RFC5014] require changes in the node. 809 This solution alone is not sufficient to achieve anchors 810 distribution in case of session continuity requirements, as some 811 control logic (e.g., from a connection manager [I-D.seite-mif-cm]) 812 is needed to intelligently perform source address selection. 814 Multihoming in PMIPv6 As summarized in the previous section a single 815 mobility session belongs to a single LMA (at the most the same 816 mobility session is shared across two access networks). As of 817 today there is no possibility to distribute anchors and to move 818 the session between different LMAs. 820 3.2.2. REQ2: Transparency to Upper Layers when needed 822 PMIPv6 As a mobility protocol, the solution provides transparent 823 mobility support for a mobile node while roaming within the PMIPv6 824 domain (e.g., if a mobile node moves outside the domain, 825 established sessions cannot be maintained, unless the MN 826 implements Mobile IPv6). However, as for the MIPv6 case, this 827 transparent mobility support comes with the cost of suboptimal 828 routes if the MN moves away from its initial attachment point, 829 especially in large PMIPv6 domains. 831 Local Routing During HO the standard mechanisms are used. In this 832 sense if there is a MAG change while LR is enabled signaling is 833 exchanged to inform the target MAG that upon handover LR should be 834 re-established. The inter LMA case is not supported. For this 835 solution the mobility context is always up, all the traffic 836 receive seamless service. 838 LMA Runtime Assignment Seamless support is provided as per RFC 5213. 839 Since the LMA cannot be changed at runtime, the solution provides 840 transparency to the upper layers. However, if the solution were 841 extended to allow dynamic LMA re-location, some extensions would 842 be needed to provide IP address continuity. 844 Source Address Selection No seamless support is currently provided, 845 since it requires solutions such as IP flow mobility for PMIPv6 846 [I-D.ietf-netext-pmipv6-flowmob]. 848 Multihoming in PMIPv6 Seamless support falls back to standard PMIPv6 849 operations extended for IP flow mobility support. For this 850 solution the mobility context is always up, all the traffic 851 receive seamless service. 853 3.2.3. REQ3: IPv6 deployment 855 PMIPv6 Although Proxy Mobile IPv6 primarily support IPv6, there are 856 also extensions defined to also offer some limited IPv4 support 857 [RFC5844]. 859 Local Routing It supports both IPv4 (limited to the support provided 860 by [RFC5844]) and IPv6. 862 LMA Runtime Assignment It supports both IPv4 (limited to the support 863 provided by [RFC5844]) and IPv6. 865 Source Address Selection It supports both IPv4 and IPv6. 867 Multihoming in PMIPv6 It supports both IPv4 (limited to the support 868 provided by [RFC5844]) and IPv6. 870 3.2.4. REQ4: Existing mobility protocols 872 PMIPv6 This approach is one of the base IETF-standardized mobility 873 protocols: [RFC5213]. 875 Local Routing It reuses [RFC5213]. 877 LMA Runtime Assignment It reuses [RFC5213]. 879 Source Address Selection This approach is based on local support on 880 the terminal only. 882 Multihoming in PMIPv6 It reuses [RFC5213]. 884 3.2.5. REQ5: Compatibility 886 PMIPv6 This protocol is compatible with other protocols and can 887 operate between trusted administrative domains, although there may 888 be an associated penalty in terms of performance and/or complexity 889 [A. de la Oliva, et al.]. 891 Local Routing Since it extends [RFC5213], compatibility with 892 existing network deployments and end hosts is provided. 894 LMA Runtime Assignment Since it extends [RFC5213], compatibility 895 with existing network deployments and end hosts is provided. 897 Source Address Selection To enable the full set of use cases 898 mentioned above extensions are required thus impacting the 899 landscape of mobile devices. The extensions should not impact the 900 network. 902 Multihoming in PMIPv6 Since it extends [RFC5213], compatibility is 903 provided. 905 3.2.6. REQ6: Security considerations 907 PMIPv6 This approach includes security considerations. 909 Local Routing It reuses [RFC5213]. As such, the same security 910 considerations apply. 912 LMA Runtime Assignment It reuses [RFC5213]. As such, the same 913 security considerations apply. 915 Source Address Selection There is not signaling involved to perform 916 this action. 918 Multihoming in PMIPv6 It reuses [RFC5213]. As such, the same 919 security considerations apply. 921 3.3. 3GPP mobility 923 3.3.1. REQ1: Distributed deployment 925 SIPTO enables a certain degree of distribution, as SGW/PGW can be 926 selected to be the closest geographically to the UE. This, together 927 with the use of OPIIS (and MAPCON for the case the UE is using 928 multiple interfaces), could be used to allow the use of different 929 anchors as the UE moves. However, as described below, there is no 930 support for dynamically changing the anchor while providing IP 931 address continuity, which might be OK for short-lived sessions. 933 3.3.2. REQ2: Transparency to Upper Layers when needed 935 Seamless mobility at the local network is still not considered in 936 SIPTO. Therefore, although SIPTO and LIPA allow offloading traffic 937 from the network core similarly to the DMM approaches, even with 938 LIMONET they just provide localized mobility support, requiring 939 packet data network connections to be deactivated and re-activated 940 when the UE is not moving locally. 942 3.3.3. REQ3: IPv6 deployment 944 3GPP specs support IPv6 as described in [RFC6459]. 946 3.3.4. REQ4: Existing mobility protocols 948 Current 3GPP specifications make use of both IETF standardized 949 mechanisms (e.g., PMIPv6, DSMIPv6), and custom made mechanisms, such 950 as GTP. 952 3.3.5. REQ5: Compatibility 954 All the 3GPP extensions listed in this document are compatible with 955 3GPP networks, at least for the same release these extensions are 956 introduced or newer ones. 958 3.3.6. REQ6: Security considerations 960 3GPP extensions are assumed to be secure. TBD: refine (possibly 961 extending) this section. 963 4. Conclusions 965 In this section we identify the gaps between existing mobility 966 solutions and the DMM requirements and expected functionalities. We 967 first summarize the identified IP-mobility protocols and provide a 968 mapping (e.g., YES, NO, LIMITED) to the different DMM requirements 969 listed in [I-D.ietf-dmm-requirements]. Following the independent 970 analysis, a comparison between the solutions and the main DMM 971 functionalities is provided. Finally, the possibility of using 972 multiple solutions is addressed by combining different solutions 973 according to the results found in the independent and functional 974 analysis. 976 4.1. Independent solution analysis 978 +-------------+------+------+-----------+------+------+------+ 979 | | REQ1 | REQ2 | REQ3 | REQ4 | REQ5 | REQ6 | 980 +-------------+------+------+-----------+------+------+------+ 981 | MIPv6/NEMO | NO | LIM | v6/v4 | YES | LIM | YES | 982 | MIPv6 RO | NO | YES | v6 | YES | LIM | YES | 983 | HMIPv6 | NO | YES | v6 | YES | LIM | YES | 984 | HA switch | NO | NO | v6 | YES | YES | YES | 985 | FlowMob | NO | YES | v6/LIM v4 | YES | YES | YES | 986 | SAS w/ CB | NO | YES | v6/v4 | YES | YES | YES | 987 | PMIPv6 | NO | LIM | v6/LIM v4 | YES | LIM | YES | 988 | LR | NO | LIM | v6/LIM v4 | YES | YES | YES | 989 | LMA RA | LIM | LIM | v6/LIM v4 | YES | YES | YES | 990 | SAS w/ NB | NO | NO | v6/v4 | YES | YES | YES | 991 | MuHo PMIPv6 | NO | LIM | v6/LIM v4 | YES | YES | YES | 992 +-------------+------+------+-----------+------+------+------+ 994 4.2. Functional analysis 996 The goal of this section is to identify and analyze the main 997 functions that a DMM solution should provide in order to meet the DMM 998 requirements [I-D.ietf-dmm-requirements]. This analysis is on 999 purpose kept at high level, and will be used in the following section 1000 as main guideline for the final assessment of the gaps that cannot be 1001 covered with existing specified and deployed solutions (even if 1002 combined). 1004 4.2.1. Multiple anchoring 1006 Multiple (distributed) anchoring refers to the ability to anchor 1007 different sessions of a single mobile node at different anchors. In 1008 order to make this feature "DMM-friendly", some anchors should be 1009 placed closer to the mobile node. This implies the ability to deploy 1010 routers and assign locally anchored IP addresses at the edge of the 1011 network. This feature also requires potentially assigning multiple 1012 IP addresses to a single mobile node for its simultaneous use. 1014 Figure 5 shows an example of the multiple anchoring function, in 1015 which a mobile network operator (MNO) has deployed multiple anchors, 1016 placed closer to or at the access network level. These (distributed) 1017 anchors provide attaching terminals with IP addresses that are 1018 locally anchored, allowing MNs' traffic (Internet and operator 1019 services) to be locally offloaded (i.e., not traversing the MNO's 1020 core). 1022 +-----+ +-----+ 1023 | CN1 | | CN2 | 1024 +-----+ +-----+ 1025 | | 1026 +--------------------+ 1027 ( ) 1028 ( Internet ) 1029 ( ) 1030 +--------------------+ 1031 || 1032 +------------------------------------------------+ 1033 ( ) 1034 ( -------------------- ) 1035 ( | centralized | Mobile Network ) 1036 ( | anchor (e.g., | Operator's ) 1037 ( | LMA/HA/PGW/GGSN) | core ) 1038 ( -------------------- ) 1039 ( ) 1040 +------------------------------------------------+ 1041 / | \ 1042 / * Internet | x Internet \ + Internet 1043 / * / access | x / access \ + / access 1044 / * / | x / \ + / 1045 --+------+----- ----+-----+---- ------+---+---- 1046 | distributed | * * *| distributed | | distributed | 1047 | anchor 1 | | anchor i | | anchor n | 1048 ---+----------- ---+----------- ---+----------- 1049 | | | 1050 (o) (o) (o) 1051 session * x session + session 1052 anchored * x anchored + anchored 1053 at 1 * x at i + at n 1054 (o) (o) 1055 | | 1056 +--+--+ +--+--+ 1057 | MN1 | | MN2 | 1058 +-----+ +-----+ 1060 Figure 5: Multiple anchoring 1062 4.2.2. Dynamic anchor assignment 1064 Dynamic anchor re-location is the ability to i) optimally assign 1065 initial anchor, and ii) change the initially assigned anchor and/or 1066 assign a new one. This can be achieved either by changing anchor for 1067 all ongoing sessions (which might only be achievable with routing- 1068 based solutions), or by assigning new anchors for new sessions. 1070 Figure 6 shows an example of what the dynamic anchor assignment 1071 function provides. A mobile node MN1, initially attached to the 1072 distributed anchor 1, establishes a session X (anchored at 1, i.e., 1073 optimal initial anchor assignment), which finishes before MN1 moves 1074 to the distributed anchor i. While connected to the distributed 1075 anchor i, a new session Y is established, which is anchored at i 1076 (i.e. assignment of a new anchor). Then MN1 moves and attaches to 1077 the distributed anchor n, while having session Y active, where MN1 is 1078 assigned n as its anchor for new sessions and (optionally) existing 1079 sessions are moved (i.e., change of assigned anchor). 1081 ( ) 1082 +------------------------------------------------+ 1083 / | \ 1084 / * Internet | x Internet \ x Internet 1085 / * / access | x / access \ x / access 1086 / * / | x / \ x / 1087 --+------+----- ----+----+----- ------+---+---- 1088 | distributed | | distributed | | distributed | 1089 | anchor 1 | | anchor i | | anchor n | 1090 ---+----------- ---+----------- ---+----------- 1091 | | | 1092 (o) (o) (o) 1093 * x session Y x session Y 1094 session X * x anchored x anchored 1095 anchored * x at i x (moved) 1096 at 1 (o) (o) at n 1097 | | 1098 +--+--+ \ +--+--+ 1099 | MN1 | =========) | MN1 | 1100 +-----+ / +-----+ 1102 Figure 6: Dynamic anchor assignment 1104 4.2.3. Multiple address management 1106 Multiple IP address management refers to the ability of the mobile 1107 node to simultaneously use multiple IP addresses and select the best 1108 one (from an anchoring point of view) to use on a per-session/ 1109 application/service basis. Depending on the mobile node support, 1110 this functionality might require more or less support from the 1111 network side. 1113 Figure 7 shows an example of multiple address management, in which 1114 MN1 initially obtained an IP address (IP a) when connected to the 1115 distributed anchor 1, which is then used for a session which remains 1116 active after MN1 moves and attaches to the distributed anchor i. MN1 1117 also obtains a new IP address (IP b) to be used for sessions 1118 initiated while attached to i. MN1 therefore needs to simultaneously 1119 manage and use multiple IP addresses, selecting the best one for each 1120 session. This selection might be performed by the mobile node solely 1121 or might be aided/performed with network support. 1123 ( ) 1124 +------------------------------------------------+ 1125 / | \ 1126 / * Internet | x Internet \ Internet 1127 / * / access | x / access \ / access 1128 / * / (IP a) | x / (IP b) \ / 1129 --+------+----- ----+-----+---- ------+---+---- 1130 | distributed | * * *| distributed | | distributed | 1131 | anchor 1 | | anchor i | | anchor n | 1132 ---+----------- ---+----------- ---+----------- 1133 | | | 1134 (o) (o) (o) 1135 session X * x session Y 1136 anchored * x anchored 1137 at 1 * x at i 1138 (IP a) (o) (IP b) 1139 | 1140 +--+--+ 1141 | MN1 | 1142 +-----+ 1144 Figure 7: Multiple address management 1146 4.3. Combined solutions analysis 1148 The goal of this section is to evaluate how a solution based on 1149 combining the different standardized IP mobility solutions could meet 1150 the DMM requirements, making reference to the high-level functions 1151 identified above. 1153 Both the main client- and network-based IP mobility protocols, namely 1154 (DS)MIPv6 and PMIPv6 allows to deploy multiple anchors (i.e., home 1155 agents and localized mobility anchors), therefore providing the 1156 functionality of multiple anchoring. However, existing solutions 1157 does only provide an optimal initial anchor assignment, a gap being 1158 the lack of dynamic anchor change/new anchor assignment. Neither the 1159 HA switch nor the LMA runtime assignment allow changing the anchor 1160 during an ongoing session. 1162 Even if dynamic anchor change and new anchor assignment were 1163 supported, default address selection mechanisms would need to be 1164 improved, as mobile nodes would likely be assigned multiple IP 1165 addresses, anchored at different places. Therefore, smart address 1166 selection, trying to always use the shortest path, would be required. 1168 5. IANA Considerations 1170 No IANA considerations. 1172 6. Security Considerations 1174 This is an informational document that analyzes practices for the 1175 deployment of existing mobility protocols in a distributed mobility 1176 management environment, and identifies the limitations in the current 1177 practices. One of the requirements that these practices has to meet 1178 is to take into account security aspects, including confidentiality 1179 and integrity. This is briefly analyzed for each of the considered 1180 practices, and will be extended in future versions of this document. 1182 7. References 1184 7.1. Normative References 1186 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1187 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1188 RFC 3963, January 2005. 1190 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1191 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1193 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 1194 "Mobility Header Home Agent Switch Message", RFC 5142, 1195 January 2008. 1197 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1198 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1200 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1201 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1202 Management", RFC 5380, October 2008. 1204 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1205 Routers", RFC 5555, June 2009. 1207 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 1208 July 2009. 1210 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1211 and K. Nagami, "Multiple Care-of Addresses Registration", 1212 RFC 5648, October 2009. 1214 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1215 Mobile IPv6", RFC 5844, May 2010. 1217 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 1218 "Traffic Selectors for Flow Bindings", RFC 6088, 1219 January 2011. 1221 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 1222 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 1223 Network Mobility (NEMO) Basic Support", RFC 6089, 1224 January 2011. 1226 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1227 in IPv6", RFC 6275, July 2011. 1229 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 1230 "Runtime Local Mobility Anchor (LMA) Assignment Support 1231 for Proxy Mobile IPv6", RFC 6463, February 2012. 1233 [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) 1234 Bootstrapping for the Integrated Scenario", RFC 6611, 1235 May 2012. 1237 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 1238 Dutta, "Localized Routing for Proxy Mobile IPv6", 1239 RFC 6705, September 2012. 1241 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1242 "Default Address Selection for Internet Protocol Version 6 1243 (IPv6)", RFC 6724, September 2012. 1245 7.2. Informative References 1247 [3GPP.23.829] 1248 3GPP, "Local IP Access and Selected IP Traffic Offload 1249 (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011. 1251 [3GPP.23.859] 1252 3GPP, "LIPA Mobility and SIPTO at the Local Network", 3GPP 1253 TR 23.859 0.5.0, June 2012. 1255 [3GPP.29.060] 1256 3GPP, "General Packet Radio Service (GPRS); GPRS 1257 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1258 3GPP TS 29.060 3.19.0, March 2004. 1260 [A. de la Oliva, et al.] 1261 de la Oliva, A., Soto, I., Calderon, M., Bernardos, C., 1262 and M. Sanchez, "The costs and benefits of combining 1263 different IP mobility standards", Computer Standards & 1264 Interfaces, accepted for publication, doi:10.1016/ 1265 j.csi.2012.08.003 , 2012. 1267 [I-D.ietf-dmm-requirements] 1268 Chan, A., "Requirements for Distributed Mobility 1269 Management", draft-ietf-dmm-requirements-02 (work in 1270 progress), September 2012. 1272 [I-D.ietf-netext-pmipv6-flowmob] 1273 Bernardos, C., "Proxy Mobile IPv6 Extensions to Support 1274 Flow Mobility", draft-ietf-netext-pmipv6-flowmob-05 (work 1275 in progress), October 2012. 1277 [I-D.patil-dmm-issues-and-approaches2dmm] 1278 Patil, B., Williams, C., and J. Korhonen, "Approaches to 1279 Distributed mobility management using Mobile IPv6 and its 1280 extensions", draft-patil-dmm-issues-and-approaches2dmm-00 1281 (work in progress), March 2012. 1283 [I-D.perkins-dmm-matrix] 1284 Perkins, C., Liu, D., and W. Luo, "DMM Comparison Matrix", 1285 draft-perkins-dmm-matrix-04 (work in progress), July 2012. 1287 [I-D.seite-mif-cm] 1288 Seite, P. and J. Zuniga, "MIF API Conn Mngr 1289 Considerations", draft-seite-mif-cm-00 (work in progress), 1290 September 2012. 1292 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1293 Nordmark, "Mobile IP Version 6 Route Optimization Security 1294 Design Background", RFC 4225, December 2005. 1296 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 1297 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 1298 September 2006. 1300 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1301 Socket API for Source Address Selection", RFC 5014, 1302 September 2007. 1304 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 1305 Support in the Internet", RFC 6301, July 2011. 1307 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 1308 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1309 Partnership Project (3GPP) Evolved Packet System (EPS)", 1310 RFC 6459, January 2012. 1312 Appendix A. Acknowledgments 1314 The work of Carlos J. Bernardos and Telemaco Melia has been partially 1315 supported by the European Community's Seventh Framework Programme 1316 (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL project). 1317 The work of Carlos J. Bernardos has also been partially supported by 1318 the Ministry of Science and Innovation of Spain under the QUARTET 1319 project (TIN2009-13992-C02-01). The authors would like to thank 1320 Konstantinos Pentikousis, Georgios Karagiannis, Jouni Korhonen, Jong- 1321 Hyouk Lee, Marco Liebsch, Elena Demaria, Peter McCann, Luo Wen and 1322 Julien Laganier for their valuable comments. 1324 Authors' Addresses 1326 Juan Carlos Zuniga 1327 InterDigital Communications, LLC 1328 1000 Sherbrooke Street West, 10th floor 1329 Montreal, Quebec H3A 3G4 1330 Canada 1332 Email: JuanCarlos.Zuniga@InterDigital.com 1333 URI: http://www.InterDigital.com/ 1335 Carlos J. Bernardos 1336 Universidad Carlos III de Madrid 1337 Av. Universidad, 30 1338 Leganes, Madrid 28911 1339 Spain 1341 Phone: +34 91624 6236 1342 Email: cjbc@it.uc3m.es 1343 URI: http://www.it.uc3m.es/cjbc/ 1344 Telemaco Melia 1345 Alcatel-Lucent Bell Labs 1346 Route de Villejust 1347 Nozay, Ile de France 91620 1348 France 1350 Email: telemaco.melia@alcatel-lucent.com 1352 Charles E. Perkins 1353 Futurewei 1354 USA 1356 Email: charliep@computer.org