idnits 2.17.1 draft-ietf-dmm-best-practices-gap-analysis-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 114 has weird spacing: '...ocation is th...' -- The document date (June 17, 2013) is 3965 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-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM D. Liu, Ed. 3 Internet-Draft China Mobile 4 Intended status: Informational JC. Zuniga, Ed. 5 Expires: December 19, 2013 InterDigital 6 P. Seite 7 Orange 8 H. Chan 9 Huawei Technologies 10 CJ. Bernardos 11 UC3M 12 June 17, 2013 14 Distributed Mobility Management: Current practices and gap analysis 15 draft-ietf-dmm-best-practices-gap-analysis-01 17 Abstract 19 The present document analyses deplyment practices of existing 20 mobility protocols in a distributed mobility management environment. 21 It also identifies some limitations compared to the expected 22 functionality of a fully distributed mobility management system. The 23 comparison is made taking into account the identified DMM 24 requirements. 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 December 19, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Functions of existing mobility protocols . . . . . . . . . . . 4 63 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. IP flat wireless network . . . . . . . . . . . . . . . . . 6 66 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 8 67 4.2.2. Network-based IP DMM practices . . . . . . . . . . . . 11 68 4.3. 3GPP network flattening approaches . . . . . . . . . . . . 13 69 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 8. Informative References . . . . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 75 1. Introduction 77 The distributed mobility management (DMM) WG has studied the problems 78 of centralized deployment of mobility management protocols and the 79 related requirements [I-D.ietf-dmm-requirements]. In order to guide 80 the deployment and before defining any new DMM protocol, the DMM WG 81 is chartered to investigate first whether it is feasible to deploy 82 current IP mobility protocols in a DMM scenario in a way that can 83 fullfil the requirements of DMM. This document discusses current 84 deployment practices of existing mobility protocols in a distributed 85 mobility management environment and identifies the limitations in 86 these practices with respect to the expected functionality. 88 The rest of this document is organized as follows. Section 3 89 analyzes existing IP mobility protocols by examining their functions 90 and how these functions can be reconfigured to work in a DMM 91 environment. Section 4 presents the current practices of IP flat 92 wireless networks and 3GPP architectures. Both network- and host- 93 based mobility protocols are considered. Section 5 presents the gap 94 analysis with respect to the current practices. 96 2. Terminology 98 All general mobility-related terms and their acronyms used in this 99 document are to be interpreted as defined in the Mobile IPv6 base 100 specification [RFC6275] and in the Proxy mobile IPv6 specification 101 [RFC5213]. These terms include mobile node (MN), correspondent node 102 (CN), home agent (HA), local mobility anchor (LMA), and mobile access 103 gateway (MAG). 105 In addition, this document uses the following terms: 107 Mobility routing (MR) is the logical function that intercepts 108 packets to/from the IP address/prefix delegated to the mobile node 109 and forwards them, based on internetwork location information, 110 either directly towards their destination or to some other network 111 element that knows how to forward the packets to their ultimate 112 destination. 114 Home address allocation is the logical function that allocates the 115 IP address/prefix (e.g., home address or home network prefix) to a 116 mobile node. 118 Location management (LM) is the logical function that manages and 119 keeps track of the internetwork location information of a mobile 120 node, which includes the mapping of the IP address/prefix 121 delegated to the MN to the MN routing address or another network 122 element that knows where to forward packets destined for the MN. 124 Home network of an application session (or an HoA IP address) is the 125 network that has allocated the IP address used as the session 126 identifier (home address) by the application being run in an MN. 127 The MN may be attached to more than one home networks. 129 In the document, several references to a distributed mobility 130 management environment are made. By this term, we refer to an 131 scenario in which the IP mobility, access network and routing 132 solutions allow for setting up IP networks so that traffic is 133 distributed in an optimal way and does not rely on centrally deployed 134 anchors to manage IP mobility sessions. 136 3. Functions of existing mobility protocols 138 The host-based Mobile IPv6 [RFC6275] and its network-based extension, 139 PMIPv6 [RFC5213], are both logically centralized mobility management 140 approaches addressing primarily hierarchical mobile networks. 141 Although they are centralized approaches, they have important 142 mobility management functions resulting from years of extensive work 143 to develop and to extend these functions. It is therefore fruitful 144 to take these existing functions and examine them in a DMM scenario 145 in order to understand how to deploy the existing mobility protocols 146 in a distributed mobility management environment. 148 The existing mobility management functions of MIPv6, PMIPv6, and 149 HMIPv6 are the following: 151 1. Anchoring function (AF): allocation to a mobile node of an IP 152 addres/prefix (e.g., a HoA or HNP) topologically anchored by the 153 delegating node (i.e., the anchor node is able to advertise a 154 connected route into the routing infrastructure for the delegated 155 IP prefixes). 157 2. Mobility Routing (MR) function: packets interception and 158 forwarding to/from the IP address/prefix delegated to the MN, 159 based on the internetwork location information, either to the 160 destination or to some other network element that knows how to 161 forward the packets to their destination; 163 3. Internetwork Location Management (LM) function: managing and 164 keeping track of the internetwork location of an MN, which 165 includes a mapping of the IP delegated address/prefix (e.g., HoA 166 or HNP) to the mobility anchoring point where the MN is anchored 167 to; 169 4. Location Update (LU): provisioning of MN location information to 170 the LM function; 172 In Mobile IPv6 [RFC6275], the home agent typically provides the 173 anchoring function (AF), Mobility Routing (MR), and Internetwork 174 Location Management (LM) functions, while the mobile node provides 175 the Location Update (LU) function. Proxy Mobile IPv6 [RFC5213] 176 relies on the function of the Local Mobility Anchor (LMA) to provide 177 mobile nodes with mobility support, without requiring the involvement 178 of the mobile nodes. The required functionality at the mobile node 179 is provided in a proxy manner by the Mobile Access Gateway (MAG). 180 With network-based IP mobility protocols, the local mobility anchor 181 typically provides the anchoring function (AF), Mobility Routing 182 (MR), and Internetwork Location Management (LM) functions, while the 183 mobile access gateway provides the Location Update (LU) function. 185 4. DMM practices 187 This section documents deployment practices of existing mobility 188 protocols in a distributed mobility management environment. This 189 description is divided into two main families of network 190 architectures: i) IP flat wireless networks (e.g., evolved WiFi 191 hotspots) and, ii) 3GPP network flattening approaches. 193 While describing the current DMM practices, references to the generic 194 mobility management functions described in Section 3 will be 195 provided, as well as some initial hints on the identified gaps with 196 respect to the DMM requirement documented in 197 [I-D.ietf-dmm-requirements]. 199 4.1. Assumptions 201 There are many different approaches that can be considered to 202 implement and deploy a distributed anchoring and mobility solution. 203 Since this document cannot be too exhaustive, the focus is on current 204 mobile network architectures and standardized IP mobility solutions. 205 In order to limit the scope of our analysis of current DMM practices, 206 we consider the following list of technical assumptions: 208 1. Both host- and network-based solutions should be covered. 210 2. Solution should allow selecting and using the most appropriate IP 211 anchor among a set of distributed ones. 213 3. Mobility management should be realized by the preservation of the 214 IP address across the different points of attachment during the 215 mobility (i.e., provision of IP address continuity). IP flows of 216 applications which do not need a constant IP address should not 217 be handled by DMM. It is typically the role of a connection 218 manager to distinguish application capabilities and trigger the 219 mobility support accordingly. Further considerations on 220 application management are out of the scope of this document. 222 4. Mobility management and traffic redirection should only be 223 triggered due to IP mobility reasons, that is when the MN moves 224 from the point of attachment where the IP flow was originally 225 initiated. 227 4.2. IP flat wireless network 229 This section focuses on common IP wireless network architectures and 230 how they can be flattened from an IP mobility and anchoring point of 231 view using common and standardized protocols. Since WiFi is the most 232 widely deployed wireless access technology nowadays, we take it as 233 example in the following. Some representative examples of WiFi 234 deployed architectures are depicted on Figure 1. 236 +-------------+ _----_ 237 +---+ | Access | _( )_ 238 |AAA|. . . . . . | Aggregation |----------( Internet ) 239 +---+ | Gateway | (_ _) 240 +-------------+ '----' 241 | | | 242 | | +-------------+ 243 | | | 244 | | +-----+ 245 +---------------+ | | AR | 246 | | +--+--+ 247 +-----+ +-----+ *----+----* 248 | RG | | WLC | ( LAN ) 249 +-----+ +-----+ *---------* 250 . / \ / \ 251 / \ +----+ +----+ +----+ +----+ 252 MN MN |WiFi| |WiFi| |WiFi| |WiFi| 253 | AP | | AP | | AP | | AP | 254 +----+ +----+ +----+ +----+ 255 . . 256 / \ / \ 257 MN MN MN MN 259 Figure 1: IP WiFi network architectures 261 In the figure, three typical deployment options are shown 262 [I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of 263 the figure, mobile nodes directly connect to a Residential Gateway 264 (RG) which is a network device that is located in the customer 265 premises and provides both wireless layer-2 access connectivity 266 (i.e., it hosts the 802.11 Access Point function) with layer-3 267 routing functions. In the middle, mobile nodes connect to WiFi 268 Access Points (APs) that are managed by a WLAN Controller (WLC), 269 which performs radio resource management on the APs, system-wide 270 mobility policy enforcement and centralized forwarding function for 271 the user traffic. The WLC could also implement layer-3 routing 272 functions, or attach to an access router (AR). Last, on the right- 273 hand side of the figure, access points are directly connected to an 274 access router, which can also be used a generic connectivity model. 276 In some network architectures, such as the evolved Wi-Fi hotspot, 277 operators might make use of IP mobility protocols to provide mobility 278 support to users, for example to allow connecting the IP WiFi network 279 to a mobile operator core and support roaming between WLAN and 3GPP 280 accesses. Two main protocols can be used: Proxy Mobile IPv6 281 [RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor role 282 (e.g., local mobility anchor or home agent) typically being played by 283 the Access Aggregation Gateway or even by an entity placed on the 284 mobile operator's core network. 286 Existing IP mobility protocols can also be deployed in a "flatter" 287 way, so the anchoring and access aggregation functions are 288 distributed. We next describe several practices for the deployment 289 of existing mobility protocols in a distributed mobility management 290 environment. We limit our analysis in this section to protocol 291 solutions based on existing IP mobility protocols, either host- or 292 network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile 293 IPv6 [RFC5213], [RFC5844] and NEMO [RFC3963]. Extensions to these 294 base protocol solutions are also considered. We pay special 295 attention to the management of the use of care-of-addresses versus 296 home addresses in an efficient manner for different types of 297 communications. Finally, and in order to simplify the analysis, we 298 divide it into two parts: host- and network-based practices. 300 4.2.1. Host-based IP DMM practices 302 Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile 303 networks, the NEMO Basic Support protocol (hereafter, simply NEMO) 304 [RFC3963] are well-known host-based IP mobility protocols. They 305 heavily rely on the function of the Home Agent (HA), a centralized 306 anchor, to provide mobile nodes (hosts and routers) with mobility 307 support. In these approaches, the home agent typically provides the 308 anchoring function (AF), Mobility Routing (MR), and Internetwork 309 Location Management (LM) functions, while the mobile node provides 310 the Location Update (LU) function. We next describe some practices 311 on how Mobile IPv6/NEMO and several additional protocol extensions 312 can be deployed in a distributed mobility management environment. 314 One approach to distribute the anchors can be to deploy several HAs 315 (as shown in Figure 2), and assign to each MN the one closest to its 316 topological location [RFC4640], [RFC5026], [RFC6611]. In the example 317 shown in Figure 2, MN1 is assigned HA1 (and a home address anchored 318 by HA1), while MN2 is assigned HA2. Note that Mobile IPv6 / NEMO 319 specifications do not prevent the simultaneous use of multiple home 320 agents by a single mobile node. This deployment model could be 321 exploited by a mobile node to meet assumption #4 and use several 322 anchors at the same time, each of them anchoring IP flows initiated 323 at different point of attachment. However there is no mechanism 324 specified to enable an efficient dynamic discovery of available 325 anchors and the selection of the most suitable one. 327 <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> 328 ------- ------- 329 | CN1 | ------- | AR1 |-(o) zzzz (o) 330 ------- | HA1 | ------- | 331 ------- (MN1 anchored at HA1) ------- 332 ------- | MN1 | 333 | AR2 |-(o) ------- 334 ------- 335 ------- 336 | HA2 | ------- 337 ------- | AR3 |-(o) zzzz (o) 338 ------- | 339 ------- (MN2 anchored at HA2) ------- 340 | CN2 | ------- | MN2 | 341 ------- | AR4 |-(o) ------- 342 ------- 344 CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 345 | | | | | | | | 346 |<------------>|<=================+=====>| | | BT mode 347 | | | | | | | | 348 | |<----------------------------------------+----->| RO mode 349 | | | | | | | | 351 Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO 353 Since one of the goals of the deployment of mobility protocols in a 354 distributed mobility management environment is to avoid the 355 suboptimal routing caused by centralized anchoring, the Route 356 Optimization (RO) support provided by Mobile IPv6 can also be used to 357 achieve a flatter IP data forwarding. By default, Mobile IPv6 and 358 NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data 359 traffic is always encapsulated between the MN and its HA before being 360 directed to any other destination. The Route Optimization (RO) mode 361 allows the MN to update its current location on the CNs, and then use 362 the direct path between them. Using the example shown in Figure 2, 363 MN1 is using BT mode with CN2 and MN2 is in RO mode with CN1. 364 However, the RO mode has several drawbacks: 366 o The RO mode is only supported by Mobile IPv6. There is no route 367 optimization support standardized for the NEMO protocol, although 368 many different solutions have been proposed. 370 o The RO mode requires additional signaling, which adds some 371 protocol overhead. 373 o The signaling required to enable RO involves the home agent, and 374 it is repeated periodically because of security reasons [RFC4225]. 376 This basically means that the HA remains as single point of 377 failure, because the Mobile IPv6 RO mode does not mean HA-less 378 operation. 380 o The RO mode requires additional support on the correspondent node 381 (CN). 383 Notwithstanding these considerations, the RO mode does offer the 384 possibility of substantially reducing traffic through the Home Agent, 385 in cases when it can be supported on the relevant correspondent 386 nodes. 388 <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK -------> 389 ----- 390 /|AR1|-(o) zz (o) 391 -------- / ----- | 392 | MAP1 |< ------- 393 -------- \ ----- | MN1 | 394 ------- \|AR2| ------- 395 | CN1 | ----- HoA anchored 396 ------- ----- at HA1 397 ------- /|AR3| RCoA anchored 398 | HA1 | -------- / ----- at MAP1 399 ------- | MAP2 |< LCoA anchored 400 -------- \ ----- at AR1 401 \|AR4| 402 ------- ----- 403 | CN2 | ----- 404 ------- /|AR5| 405 -------- / ----- 406 | MAP3 |< 407 -------- \ ----- 408 \|AR6| 409 ----- 411 CN1 CN2 HA1 MAP1 AR1 MN1 412 | | | | ________|__________ | 413 |<------------------>|<==============>|<________+__________>| HoA 414 | | | | | | 415 | |<-------------------------->|<===================>| RCoA 416 | | | | | | 418 Figure 3: Hierarchical Mobile IPv6 420 Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] is another host-based IP 421 mobility extension that can be considered as a complement to provide 422 a less centralized mobility deployment. It allows reducing the 423 amount of mobility signaling as well as improving the overall 424 handover performance of Mobile IPv6 by introducing a new hierarchy 425 level to handle local mobility. The Mobility Anchor Point (MAP) 426 entity is introduced as a local mobility handling node deployed 427 closer to the mobile node. 429 When HMIPv6 is used, the MN has two different temporal addresses: the 430 Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA). 431 The RCoA is anchored at one MAP, that plays the role of local home 432 agent, while the LCoA is anchored at the access router level. The 433 mobile node uses the RCoA as the CoA signaled to its home agent. 434 Therefore, while roaming within a local domain handled by the same 435 MAP, the mobile node does not need to update its home agent (i.e., 436 the mobile node does not change RCoA). 438 The use of HMIPv6 allows some route optimization, as a mobile node 439 may decide to directly use the RCoA as source address for a 440 communication with a given correspondent node, notably if the MN does 441 not expect to move outside the local domain during the lifetime of 442 the communication. This can be seen as a potential DMM mode of 443 operation. In the example shown in Figure 3, MN1 is using its global 444 HoA to communicate with CN1, while it is using its RCoA to 445 communicate with CN2. 447 Additionally, a local domain might have several MAPs deployed, 448 enabling hence different kind of HMIPv6 deployments (e.g., flat and 449 distributed). The HMIPv6 specification supports a flexible selection 450 of the MAP (e.g., based on the distance between the MN and the MAP, 451 taking into consideration the expected mobility pattern of the MN, 452 etc.). 454 An additional extension that can be used to help deploying a mobility 455 protocol in a distributed mobility management environment is the the 456 Home Agent switch specification [RFC5142], which defines a new 457 mobility header for signaling a mobile node that it should acquire a 458 new home agent. Even though the purposes of this specification do 459 not include the case of changing the mobile node's home address, as 460 that might imply loss of connectivity for ongoing persistent 461 connections, it could be used to force the change of home agent in 462 those situations where there are no active persistent data sessions 463 that cannot cope with a change of home address. 465 4.2.2. Network-based IP DMM practices 467 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP 468 mobility protocol specified for IPv6 ([RFC5844] defines some IPv4 469 extensions). Architecturally, PMIPv6 is similar to MIPv6, as it 470 relies on the function of the Local Mobility Anchor (LMA) to provide 471 mobile nodes with mobility support, without requiring the involvement 472 of the mobile nodes. The required functionality at the mobile node 473 is provided in a proxy manner by the Mobile Access Gateway (MAG). 474 With network-based IP mobility protocols, the local mobility anchor 475 typically provides the anchoring function (AF), Mobility Routing 476 (MR), and Internetwork Location Management (LM) functions, while the 477 mobile access gateway provides the Location Update (LU) function. We 478 next describe some practices on how network-based mobility protocols 479 and several additional protocol extensions can be deployed in a 480 distributed mobility management environment. 482 <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> 483 ------- 484 | CN1 | -------- -------- -------- 485 ------- -------- | MAG1 | | MAG2 | | MAG3 | 486 | LMA1 | ---+---- ---+---- ---+---- 487 ------- -------- | | | 488 | CN2 | (o) (o) (o) 489 ------- -------- x x 490 | LMA2 | x x 491 ------- -------- (o) (o) 492 | CN3 | | | 493 ------- ---+--- ---+--- 494 Anchored | MN1 | Anchored | MN2 | 495 at LMA1 -> ------- at LMA2 -> ------- 497 CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2 498 | | | | | | | | 499 |<------------>|<================>|<---->| | | 500 | | | | | | | | 501 | |<------------>|<========================>|<----->| 502 | | | | | | | | 504 Figure 4: Distributed operation of Proxy Mobile IPv6 506 As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be 507 easily decentralized, as in this case there also exists a single 508 network anchor point. One simple but still suboptimal approach, can 509 be to deploy several local mobility anchors and use some selection 510 criteria to assign LMAs to attaching mobile nodes (an example of this 511 type of assignment is shown in Figure 4). As per the client based 512 approach, a mobile node may use several anchors at the same time, 513 each of them anchoring IP flows initiated at different point of 514 attachment. This assignment can be static or dynamic (as described 515 later in this document). The main advantage of this simple approach 516 is that the IP address anchor (i.e., the LMA) could be placed closer 517 to the mobile node, and therefore resulting paths are close-to- 518 optimal. On the other hand, as soon as the mobile node moves, the 519 resulting path would start to deviate from the optimal one. 521 As for host-based IP mobility, there are some extensions defined to 522 mitigate the sub-optimal routing issues that might arise due to the 523 use of a centralized anchor. The Local Routing extensions [RFC6705] 524 enable optimal routing in Proxy Mobile IPv6 in three cases: i) when 525 two communicating MNs are attached to the same MAG and LMA, ii) when 526 two communicating MNs are attached to different MAGs but to the same 527 LMA, and iii) when two communicating MNs are attached to the same MAG 528 but have different LMAs. In these three cases, data traffic between 529 the two mobile nodes does not traverse the LMA(s), thus providing 530 some form of path optimization since the traffic is locally routed at 531 the edge. The main disadvantage of this approach is that it only 532 tackles the MN-to-MN communication scenario, and only under certain 533 circumstances. 535 An interesting extension that can also be used to facilitate the 536 deployment of network-based mobility protocols in a distributes 537 mobility management environment is the LMA runtime assignment 538 [RFC6463]. This extension specifies a runtime local mobility anchor 539 assignment functionality and corresponding mobility options for Proxy 540 Mobile IPv6. This runtime local mobility anchor assignment takes 541 place during the Proxy Binding Update / Proxy Binding Acknowledgment 542 message exchange between a mobile access gateway and a local mobility 543 anchor. While this mechanism is mainly aimed for load-balancing 544 purposes, it can also be used to select an optimal LMA from the 545 routing point of view. A runtime LMA assignment can be used to 546 change the assigned LMA of an MN, for example in case when the mobile 547 node does not have any session active, or when running sessions can 548 survive an IP address change. 550 4.3. 3GPP network flattening approaches 552 The 3rd Generation Partnership Project (3GPP) is the standard 553 development organization that specifies the 3rd generation mobile 554 network and LTE (Long Term Evolution). 556 Architecturally, the 3GPP Evolved Packet Core (EPC) network is 557 similar to an IP wireless network running PMIPv6 or MIPv6, as it 558 relies on the Packet Data Gateway (PGW) anchoring services to provide 559 mobile nodes with mobility support (see Figure 5). There are client- 560 based and network-based mobility solutions in 3GPP, which for 561 simplicity we will analyze together. We next describe how 3GPP 562 mobility protocols and several additional completed or on-going 563 extensions can be deployed to meet some of the DMM requirements 564 [I-D.ietf-dmm-requirements]. 566 +---------------------------------------------------------+ 567 | PCRF | 568 +-----------+--------------------------+----------------+-+ 569 | | | 570 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 571 | | | +-+ | | Core Network | | | 572 | | | +------+ |S|__ | | +--------+ +---+ | | | 573 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 574 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 575 | | | +------+ |N| +-+-+ | | | | | | | x | 576 | | | +-+ /|MME| | | +---+----+ | | | | t | 577 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 578 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 579 | | | +---------+\ | | | SERVER | | | | | n | 580 | | | \ +---+ | | +--------+ | | | | a | 581 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 582 | | | +---+ | | | G | | | | 583 | | +------------------------+ | | W | | | I | 584 | UE | | | | | | P | 585 | | +------------------------+ | | +-----+ | 586 | | |+-------------+ +------+| | | | | | n | 587 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 588 | +---+| non-3GPP AN | +------+| | | | | | t | 589 | | |+-------------+ | | | | | | w | 590 | | +------------------------+ | | | | | o | 591 | | | | | | | r | 592 | | +------------------------+ | | | | | k | 593 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 594 | | +------------------------+ | | | | | | 595 | | | +-+-+ | | | 596 | +--------------------------S2c--------------------| | | | 597 | | | | | | 598 +----+ +--------------------+ +---+ 600 Figure 5: EPS (non-roaming) architecture overview 602 GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based 603 mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8 604 interfaces). Similar to PMIPv6, it can handle mobility without 605 requiring the involvement of the mobile nodes. In this case, the 606 mobile node functionality is provided in a proxy manner by the 607 Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or 608 Trusted Wireless Access Gateway (TWAG). 610 3GPP specifications also include client-based mobility support, based 611 on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for 612 the S2c interface. In this case, the UE implements the mobile node 613 functionality, while the home agent role is played by the PGW. 615 A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) 616 enabled network [3GPP.23.829] allows offloading some IP services at 617 the local access network, above the Radio Access Network (RAN) or at 618 the macro, without the need to traverse back to the PGW (see 619 Figure 6. 621 +---------+ IP traffic to mobile operator's CN 622 | User |....................................(Operator's CN) 623 | Equipm. |.................. 624 +---------+ . Local IP traffic 625 . 626 +-----------+ 627 |Residential| 628 |enterprise | 629 |IP network | 630 +-----------+ 632 Figure 6: LIPA scenario 634 SIPTO enables an operator to offload certain types of traffic at a 635 network node close to the UE's point of attachment to the access 636 network, by selecting a set of GWs (SGW and PGW) that is 637 geographically/topologically close to the UE's point of attachment. 639 SIPTO Traffic 640 | 641 . 642 . 643 +------+ +------+ 644 |L-PGW | ---- | MME | 645 +------+ / +------+ 646 | / 647 +-------+ +------+ +------+/ +------+ 648 | UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic 649 +-------+ +------+ +------+ +------+ 651 Figure 7: SIPTO architecture 653 LIPA, on the other hand, enables an IP capable UE connected via a 654 Home eNB (HeNB) to access other IP capable entities in the same 655 residential/enterprise IP network without the user plane traversing 656 the mobile operator's network core. In order to achieve this, a 657 Local GW (L-GW) collocated with the HeNB is used. LIPA is 658 established by the UE requesting a new PDN connection to an access 659 point name for which LIPA is permitted, and the network selecting the 660 Local GW associated with the HeNB and enabling a direct user plane 661 path between the Local GW and the HeNB. 663 +---------------+-------+ +----------+ +-------------+ ===== 664 |Residential | |H(e)NB | | Backhaul | |Mobile | ( IP ) 665 |Enterprise |..|-------|..| |..|Operator |..(Network) 666 |Network | |L-GW | | | |Core network | ======= 667 +---------------+-------+ +----------+ +-------------+ 668 / 669 | 670 / 671 +-----+ 672 | UE | 673 +-----+ 675 Figure 8: LIPA architecture 677 Both SIPTO and LIPA have a very limited mobility support, specially 678 in 3GPP specifications up to Rel-10. In Rel-11, there is currently a 679 work item on LIPA Mobility and SIPTO at the Local Network (LIMONET) 680 [3GPP.23.859] that is studying how to provide SIPTO and LIPA 681 mechanisms with some additional, but still limited, mobility support. 682 In a glimpse, LIPA mobility support is limited to handovers between 683 HeNBs that are managed by the same L-GW (i.e., mobility within the 684 local domain), while seamless SIPTO mobility is still limited to the 685 case where the SGW/PGW is at or above Radio Access Network (RAN) 686 level. 688 5. Gap analysis 690 The goal of this section is to identify the limitations in the 691 current practices with respect to providing the expected DMM 692 functionality. 694 From the analysis performed in Section 4, we can first identify a 695 basic set of functions that a DMM solution needs to provide: 697 o Multiple (distributed) anchoring: ability to anchor different 698 sessions of a single mobile node at different anchors. In order 699 to make this feature "DMM-friendly", some anchors might need to be 700 placed closer to the mobile node. 702 o Dynamic anchor assignment/re-location: ability to i) optimally 703 assign initial anchor, and ii) dynamically change the initially 704 assigned anchor and/or assign a new one (this may also require to 705 transfer mobility context between anchors). This can be achieved 706 either by changing anchor for all ongoing sessions, or by 707 assigning new anchors just for new sessions. 709 o Multiple IP address management: ability of the mobile node to 710 simultaneously use multiple IP addresses and select the best one 711 (from an anchoring point of view) to use on a per-session/ 712 application/service basis. Depending on the mobile node support, 713 this functionality might require more or less support from the 714 network side. This is typically the role of a connection manager. 716 In order to summarize the previously listed functions, Figure 9 shows 717 an example of a conceptual DMM solution deployment. 719 ( ) 720 +------------------------------------------------+ 721 / | \ 722 / * Internet | x Internet \ Internet 723 / * / access | x / access \ / access 724 / * / (IP a) | x / (IP b) \ / 725 --+------+----- ----+-----+---- ------+---+---- 726 | distributed | * * *| distributed | | distributed | 727 | anchor 1 | | anchor i | | anchor n | 728 ---+----------- ---+----------- ---+----------- 729 | | | 730 (o) (o) (o) 731 session X * x session Y 732 anchored * x anchored 733 at 1 * x at i 734 (IP a) (o) (IP b) 735 | 736 +--+--+ 737 | MN1 | 738 +-----+ 740 Figure 9: DMM functions 742 Based on the analysis performed in Section 4, the following list of 743 gaps can be identified: 745 o Both the main client- and network-based IP mobility protocols, 746 namely (DS)MIPv6 and PMIPv6 allows to deploy multiple anchors 747 (i.e., home agents and localized mobility anchors), therefore 748 providing the multiple anchoring function. However, existing 749 solutions do only provide an optimal initial anchor assignment, a 750 gap being the lack of dynamic anchor change/new anchor assignment. 751 Neither the HA switch nor the LMA runtime assignment allow 752 changing the anchor during an ongoing session. This actually 753 comprises several gaps: ability to perform anchor assignment at 754 any time (not only at the initial MN's attachment), ability of the 755 current anchor to initiate/trigger the relocation, and ability of 756 transferring registration context between anchors. 758 o The dynamic anchor relocation needs to ensure that IP address 759 continuity is guaranteed for sessions that need it at the 760 relocated anchor. This for example implies having the knowledge 761 of which sessions are active at the mobile node, which is 762 something typically known only by the MN (namely, by its 763 connection manager). Therefore, (part of) this knowledge might 764 need to be transferred to/shared with the network. 766 o Dynamic discovery and selection of anchors. There might be more 767 than one available anchor for a mobile node to use. Currently, 768 there is no efficient mechanism that allows to dynamically 769 discover the presence of nodes that can play the role of anchor, 770 discover their capabilities and allow the selection of the most 771 suitable one. 773 o NOTE: This section is in progress. More gaps are still to be 774 identified and more text added to these bullets (perhaps even 775 assigning one subsection to each one). More discussion/feedback 776 from the group is still needed. 778 6. Security Considerations 780 TBD. 782 7. IANA Considerations 784 None. 786 8. Informative References 788 [3GPP.23.829] 789 3GPP, "Local IP Access and Selected IP Traffic Offload 790 (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011. 792 [3GPP.23.859] 793 3GPP, "Local IP access (LIPA) mobility and Selected IP 794 Traffic Offload (SIPTO) at the local network", 3GPP 795 TR 23.859 12.0.1, April 2013. 797 [3GPP.29.060] 798 3GPP, "General Packet Radio Service (GPRS); GPRS 799 Tunnelling Protocol (GTP) across the Gn and Gp interface", 800 3GPP TS 29.060 3.19.0, March 2004. 802 [I-D.gundavelli-v6ops-community-wifi-svcs] 803 Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, 804 "Service Provider Wi-Fi Services Over Residential 805 Architectures", 806 draft-gundavelli-v6ops-community-wifi-svcs-06 (work in 807 progress), April 2013. 809 [I-D.ietf-dmm-requirements] 810 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 811 "Requirements for Distributed Mobility Management", 812 draft-ietf-dmm-requirements-05 (work in progress), 813 June 2013. 815 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 816 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 817 RFC 3963, January 2005. 819 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 820 Nordmark, "Mobile IP Version 6 Route Optimization Security 821 Design Background", RFC 4225, December 2005. 823 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 824 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 825 September 2006. 827 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 828 Bootstrapping in Split Scenario", RFC 5026, October 2007. 830 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 831 "Mobility Header Home Agent Switch Message", RFC 5142, 832 January 2008. 834 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 835 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 837 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 838 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 839 Management", RFC 5380, October 2008. 841 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 842 Routers", RFC 5555, June 2009. 844 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 845 Mobile IPv6", RFC 5844, May 2010. 847 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 848 in IPv6", RFC 6275, July 2011. 850 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 851 "Runtime Local Mobility Anchor (LMA) Assignment Support 852 for Proxy Mobile IPv6", RFC 6463, February 2012. 854 [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) 855 Bootstrapping for the Integrated Scenario", RFC 6611, 856 May 2012. 858 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 859 Dutta, "Localized Routing for Proxy Mobile IPv6", 860 RFC 6705, September 2012. 862 Authors' Addresses 864 Dapeng Liu (editor) 865 China Mobile 866 Unit2, 28 Xuanwumenxi Ave, Xuanwu District 867 Beijing 100053 868 China 870 Email: liudapeng@chinamobile.com 872 Juan Carlos Zuniga (editor) 873 InterDigital Communications, LLC 874 1000 Sherbrooke Street West, 10th floor 875 Montreal, Quebec H3A 3G4 876 Canada 878 Email: JuanCarlos.Zuniga@InterDigital.com 879 URI: http://www.InterDigital.com/ 881 Pierrick Seite 882 Orange 883 4, rue du Clos Courtel, BP 91226 884 Cesson-Sevigne 35512 885 France 887 Email: pierrick.seite@orange.com 888 H Anthony Chan 889 Huawei Technologies 890 5340 Legacy Dr. Building 3 891 Plano, TX 75024 892 USA 894 Email: h.a.chan@ieee.org 896 Carlos J. Bernardos 897 Universidad Carlos III de Madrid 898 Av. Universidad, 30 899 Leganes, Madrid 28911 900 Spain 902 Phone: +34 91624 6236 903 Email: cjbc@it.uc3m.es 904 URI: http://www.it.uc3m.es/cjbc/