idnits 2.17.1 draft-aliahmad-dmm-anchor-selection-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 -- The document date (July 11, 2013) is 3941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-dmm-best-practices-gap-analysis-01 == 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 Working Group H. Ali-Ahmad (Ed.) 3 Internet-Draft Orange 4 Intended status: Informational D. Moses 5 Expires: January 12, 2014 H. Moustafa 6 Intel Corporation 7 P. Seite 8 Orange 9 T. Condexia 10 University of Aveiro 11 July 11, 2013 13 Mobility Anchor Selection in DMM: Use-case Scenarios 14 draft-aliahmad-dmm-anchor-selection-01.txt 16 Abstract 18 This document presents and discusses different use-case scenarios of 19 mobility anchor selection in Distributed Mobility Management (DMM). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 12, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Considered contexts . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Mobile node context . . . . . . . . . . . . . . . . . . . 5 59 3.2. Application context . . . . . . . . . . . . . . . . . . . 6 60 3.3. Network context . . . . . . . . . . . . . . . . . . . . . 8 61 4. Use-case scenarios . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. Extremely mobile nodes without any typical location . . . 9 63 4.2. Mobile nodes with one or more typical locations . . . . . 10 64 4.3. Fairly stationary nodes . . . . . . . . . . . . . . . . . 12 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 73 1. Terminology 75 IP-handover: 77 a handover of a mobile node at the IP level resulting in an IP 78 address change at the mobile node. 80 New flow: 82 a flow that did not undergo any IP-handover. 84 Handover flow: 86 a flow that did undergo one or more IP-handovers. 88 New traffic: 90 the data traffic of the new flows. 92 Handover traffic: 94 the data traffic of the handover flows. 96 Current access router: 98 the access router where the mobile node is currently attached at 99 the IP level. 101 DMM default mode of mobility anchor selection: 103 new flows are always anchored at the current access router which 104 acts as the mobility anchor for these flows after an IP-handover. 106 2. Introduction 108 Distributed Mobility Management (DMM) aims at overcoming the 109 shortcomings of the existing IP mobility protocols, such as Mobile 110 IPv6 [RFC6275] and Proxy Mobile IPv6 [RFC5213], that are considered 111 centralized. It brings the mobility anchor closer to the mobile 112 node, down at the access routers level. This is the enabler of a 113 concept that is so-called dynamic mobility, where the mobile node 114 changes its mobility anchor for new flows. New flows are always 115 initiated using the mobile node's current IP address which is 116 configured using the prefix provided by the current access router. 117 The data traffic of these flows is then routed optimally until the 118 mobile node undergoes an IP-handover. However, upon an IP-handover, 119 tunneling mechanisms are needed with that access router, which is 120 then considered the mobility anchor of those flows initiated using 121 its prefix during the whole lifetime of those flows. In what 122 follows, this is considered the DMM default mode of mobility anchor 123 selection. 125 If most of the flows are short enough to not undergo one or more IP- 126 handovers, it is expected that most of the data traffic is routed 127 optimally. However, this assumption is not always valid and the 128 mobility anchor for new flows, when initiated, could be selected in a 129 more appropriate manner. 131 When a flow is initiated, it is assigned a mobility anchor that lasts 132 during its whole lifetime. Thus, selecting the most appropriate 133 mobility anchor for a flow when initiated can significantly enhance 134 the mobility management performance, e.g. less overhead, shorter end- 135 to-end delay. Thus, a DMM solution should allow selecting and using 136 the most appropriate mobility anchor among a set of distributed ones 137 [I-D.ietf-dmm-best-practices-gap-analysis]. In order to achieve 138 this, different metrics and contexts should be taken into 139 consideration. Distributing the mobility anchor functionalities at 140 the access routers level allows considering several contexts such as 141 the mobile node's mobility context, the application context, and the 142 network context. 144 Hereafter in this document, the considered contexts are presented and 145 then the different use-case scenarios are discussed. 147 3. Considered contexts 149 3.1. Mobile node context 151 The mobile node's mobility has an important effect on the mobility 152 anchor selection. For example, a mobile node with high mobility 153 undergoes frequent IP-handovers. When considering DMM default mode 154 of mobility anchor selection, almost all the traffic of such mobile 155 node is handover traffic, moreover, the number of simultaneous 156 anchors and tunnels may increase. On the other hand, flows of mobile 157 nodes with low mobility are more likely to be initiated and 158 terminated before undergoing an IP-handover. 160 In addition, the mobile node's location with respect to the different 161 mobility anchors influences selecting one of them for new flows. For 162 example, locating the mobility anchor as close as possible to the 163 mobile node results in a shorter tunnel, and hence less tunneling 164 overhead, when tunneling mechanisms are required. The most 165 appropriate mobility anchor is the closest one to the mobile node 166 during the longer portion of the flow lifetime. At the instant of 167 initiating a new flow, the current access router is the closest one 168 to the mobile node. However, the mobile node may undergo an IP- 169 handover and attach to another access router. Whether the longer 170 portion of the flow is before or after the IP-handover has an effect 171 on selecting the most appropriate mobility anchor for this flow. 173 Moreover, a mobile node may have one or more "typical locations" 174 where it attaches to the network most of the time, e.g. at home. 175 This helps expecting the mobile node's location for relatively long 176 durations and, consequently, in selecting the most appropriate 177 mobility anchor by using information about typical location(s). Note 178 that some statistics show that users spend more than 60% of their 179 time at home and work [Cisco-VNI]. 181 Finally, the mobile node's attachments history is needed in order to 182 take into consideration the mobile node's mobility and location as 183 described above. 185 +---------+ +---------+ +---------+ +---------+ 186 | AR/MA 1 | | AR/MA 2 | | AR/MA 3 | | AR/MA 4 | 187 +---------+ +---------+ +---------+ +---------+ 188 | 189 | 190 +----+ AR: Access Router 191 ---- movement ----> | MN | MA: Mobility Anchor 192 +----+ MN: Mobile Node 194 Figure 1: Mobile node's movement in DMM network 196 3.2. Application context 198 Based on the application, the need of IP continuity and the flow 199 characteristics can be estimated. While applications that require IP 200 continuity cause the establishment of tunnels in the access network 201 upon an IP-handover, applications that can tolerate an IP address 202 change at the application layer, e.g. SIP-based sessions, do not 203 [I-D.ietf-dmm-requirements]. The mobility anchor selection is less 204 important in the latter case due to the capability of changing the IP 205 address. In fact, there is no need for tunneling and hence no need 206 for a mobility anchor since the application can tolerate any change 207 in the IP address; hence, all the traffic is routed using standard 208 routing schemes. 210 In addition, the flow characteristics are highly dependent on the 211 application. Some applications generate in general long flows such 212 as multimedia (e.g. video streaming), online gaming, large files 213 downloading, etc. (see Table 1 below); others generate in general 214 short flows such as TCP connections for HTTP and SMTP sessions. Long 215 flows are more likely to undergo one or more IP-handovers and 216 therefore the mobility anchor selection can play an important role to 217 enhance the mobility management performance. On the other hand, 218 short flows are more likely to be initiated and terminated before an 219 IP-handover. 221 In the following table, we present some examples on different types 222 of applications. For each application, we mention the expected (or 223 probable) traffic and mobility characteristics as well as the 224 possible types of devices used for such application. The objective 225 of this list of applications is to show later some possible real 226 mapping(s) for the different use-case scenarios. 228 +-------------+------------+------------+-------------+-------------+ 229 | Application | Traffic | Mobility | User Device | Comments | 230 | | Type | Nature | | | 231 +-------------+------------+------------+-------------+-------------+ 232 | RT Gaming | Long flows | Stationary | Laptop, | For game | 233 | | with IP | or mobile | tablet, | consoles, | 234 | | continuity | (depending | smartphone, | the device | 235 | | req | on game) | game | and traffic | 236 | | | | console | characteris | 237 | | | | | tics could | 238 | | | | | be easily | 239 | | | | | predicted | 240 | | | | | | 241 | Audio/Video | Long flows | Stationary | Smartphone, | | 242 | conferencin | with IP | or mobile | tablet, | | 243 | g | continuity | | laptop | | 244 | | req | | | | 245 | | | | | | 246 | Live | Long flows | Stationary | Large | If a large | 247 | streaming | with IP | or mobile | screen TV, | screen TV, | 248 | IPTV | continuity | | laptop, | client is | 249 | | req | | tablet, | stationary. | 250 | | | | smartphone | Otherwise, | 251 | | | | | client is | 252 | | | | | mobile | 253 | | | | | | 254 | Waze | Long flows | Mobile | Smartphone, | | 255 | | without IP | | dedicated | | 256 | | continuity | | car GPS | | 257 | | req | | (future) | | 258 | | | | | | 259 | GoPro | Long flows | Mobile | GoPro | A typical | 260 | | with IP | | camera | location | 261 | | continuity | | | (Ski | 262 | | req | | | resort) | 263 | | | | | | 264 | Video | Long flows | Stationary | Mobile | | 265 | Report | with IP | or mobile | surveillanc | | 266 | | continuity | | e, HD camer | | 267 | | req | | a | | 268 | | | | | | 269 | Video | Long flows | Mobile | Car TV, | If the car | 270 | streaming | with IP | | tablet, | is mainly | 271 | in vehicles | continuity | | smartphone | used in | 272 | | req | | | specific | 273 | | | | | neighborhoo | 274 | | | | | da typical | 275 | | | | | location i | 276 | | | | | srelevant | 277 | | | | | | 278 | Camcorder | Long flows | Stationary | Camcoder | | 279 | download | with IP | or mobile | | | 280 | | continuity | | | | 281 | | req | | | | 282 | | | | | | 283 | HTTP and | Short | Stationary | Smartphone, | | 284 | SMTP | flows with | or mobile | tablet, | | 285 | sessions | IP | | laptop | | 286 | | continuity | | | | 287 | | req | | | | 288 +-------------+------------+------------+-------------+-------------+ 290 Table 1 292 3.3. Network context 294 When a mobility anchor is assigned to a flow (when the flow is 295 initiated), it acts as a mobility anchor for this flow the whole 296 flow's lifetime. It is responsible to forward the flow's data 297 packets if the mobile node is physically attached to it. It is 298 responsible, in addition, to encapsulate and de-capsulate the flow's 299 data packets if the mobile node is not attached to it and tunneling 300 mechanisms are used. 302 Even with distributed mobility anchors, the distribution of the 303 active mobile nodes in the network is not necessarily even. As a 304 result, some mobility anchors are overloaded more than others. It is 305 then reasonable to take into consideration the estimated (or 306 projected) level of load of the mobility anchors as well as the 307 access network characteristics/resources when selecting one of them 308 for a new flow (the metrics for measuring this level are left for 309 specific implementations). 311 4. Use-case scenarios 313 4.1. Extremely mobile nodes without any typical location 315 Extreme mobility could be due to either a high mobile node's 316 speed, or a small access router's coverage area, or both. 318 Scenario 1: running applications generating typically short flows 320 Short flows are more likely to be initiated and terminated before 321 the mobile node undergoes an IP-handover. Even if a flow 322 experiences an IP-handover, it is expected that the flow does not 323 last long after the IP-handover. In other words, most of the 324 mobile node's traffic is new traffic in this scenario. As a 325 result, the closest mobility anchor to the mobile node during the 326 longest portion of a flow is its current access router. It is 327 recommended then to always anchor new flows at the current access 328 router, which is the DMM default mode of mobility anchor 329 selection. 331 A well known example on short flows is the TCP connections for 332 HTTP and SMTP sessions. 334 Scenario 2: running applications generating typically long flows 336 For extremely mobile nodes, it is more likely that a flow 337 experiences an IP-handover soon after being initiated. And since 338 the flows are long-lived, it is expected that a flow lasts for a 339 long duration after the IP-handover(s). As a result, it could be 340 said that most of the traffic is handover traffic in this 341 scenario. Whatever is the mobility anchor selection criterion, 342 most of (almost all) the mobile node's data traffic needs 343 tunneling mechanisms. Thus, the mobility anchor selection cannot 344 play a significant role regarding the route optimization or the 345 tunneling overhead reduction. 347 However, there are number of consequences regarding the control 348 plane e.g. number of simultaneous anchors/tunnels for a mobile 349 node and the related contexts and signaling loads. First, let us 350 consider the DMM default mode of mobility anchor selection. Since 351 new flows are always anchored at the current access router, each 352 flow initiated between two consecutive IP-handovers is anchored at 353 a different mobility anchor. With extremely mobile node, long 354 flows are expected to experience several IP-handovers and their 355 mobility anchors are expected to be maintained for a long 356 duration. As a result, the number of simultaneous anchors/tunnels 357 for a mobile node may increase as well as the related contexts and 358 signaling loads. This affects the control plane negatively. 360 As the DMM default mode does not achieve data plane optimization 361 in the scenario described above, it is reasonable to consider a 362 more centralized approach for mobility anchor selection in order 363 to reduce the negative effects on the control plane. If data 364 packets are going to be tunneled in both cases, managing a single 365 tunnel to a single mobility anchor would be better than managing 366 several tunnels to several mobility anchors at the same time. 368 It is worth mentioning that the discussion above is considering 369 applications that require IP-address continuity. On the other 370 hand, there is no issue regarding the applications that allow an 371 IP address change and manage mobility at the application layer 372 since they do not need mobility anchors as mentioned before. 374 Some examples on this scenario are (cf. Table 1) RT gaming, audio/ 375 video conferencing, live streaming IPTV, video report, video 376 streaming in vehicles, and camcorder download. 378 Scenario 3: running applications generating both long and short flows 380 In this case, short and long flows can be distinguished when 381 selecting a mobility anchor for a flow, based on scenario 1 and 382 scenario 2. Short flows are always anchored at the current access 383 router; long flows are anchored based on a more centralized 384 approach. In this way, data packets of short flows are generally 385 routed optimally and long flows do not introduce a large number of 386 simultaneous anchors/tunnels. 388 4.2. Mobile nodes with one or more typical locations 390 Scenario 4: running applications generating typically short flows 392 As the flows are short, there is no expected benefit from having a 393 typical location. If initiated when the mobile node is not at its 394 typical location, such flows are more likely to end quickly before 395 the mobile node goes back to its typical location. Otherwise, 396 they would be initiated and terminated when the mobile node is at 397 its typical location. As a result, the current access router is 398 always the best mobility anchor for new flows and hence the DMM 399 default mode of mobility anchor selection fits well this scenario. 401 When the car is used mainly for short distance usages, Waze (cf. 402 Table 1) could be an example on this scenario. 404 Scenario 5: running applications generating typically long flows 406 In this scenario, having a typical location is expected to be 407 beneficial for the mobile node's mobility anchor selection. As 408 mentioned before, the best mobility anchor for a flow is the 409 closest one to the mobile node during the longer portion of this 410 flow. Then, the best mobility anchor for a flow could be in some 411 cases that of the typical location even if the flow is not 412 initiated there. For example, if the mobile node initiates a long 413 flow and then comes back (undergoing an IP-handover) quickly to 414 its typical location, the longer portion of the flow would be 415 after the IP-handover. Thus, it is reasonable to select the 416 typical location's mobility anchor for such flow when initiated. 417 This results in tunneling part of the flow's data traffic when 418 initiated but in routing optimally most of it afterwards. 420 The analysis described above would be still valid if the mobile 421 node has more than one typical location. However, the benefits 422 may not be in some cases as great as those of the one typical 423 location scenario, depending on the mobile node's movements. If 424 there is no clear benefit from selecting one out of the mobility 425 anchors, the network context (i.e. level of load on each mobility 426 anchor) comes into play leaning towards selecting the mobility 427 anchor that is less loaded. Another refinement is to add the time 428 of day to the statistics collection in the mobile node's 429 attachments history. If it is noticed that one of the typical 430 locations is more popular than the others, this helps in selecting 431 a mobility anchor according to the time of attachment. 433 Some examples on this scenario are (cf. Table 1) RT gaming, audio/ 434 video conferencing, live streaming IPTV, GoPro, video report, 435 video streaming in vehicles, and camcorder download. 437 Scenario 6: running applications generating both long and short flows 439 If it is possible, the short and long flows should be 440 distinguished as follows. While short flows are assigned the 441 closest mobility anchor which is the current access router, long 442 flows are assigned the typical location's mobility anchor. In 443 this case, the mobile node uses several IP addresses 444 simultaneously e.g. the one related to the typical location for 445 all long flows and the current IP address for short flows. Hence, 446 the mobile node needs a source address selection mechanism in 447 order to distinguish between the different IP addresses when 448 initiating a flow. 450 4.3. Fairly stationary nodes 452 Scenario 7: running similar or different applications 454 In fact, a fairly stationary node has one typical location for 455 almost all the time. The mobile node selects always the typical 456 location's mobility anchor, which is the current access router 457 most of the time. 459 Some examples on this scenario are (cf. Table 1) RT gaming, audio/ 460 video conferencing, live streaming IPTV, video report, and 461 camcorder download. 463 5. Security Considerations 465 TBD. 467 6. IANA Considerations 469 This document has no actions for IANA. 471 7. Acknowledgements 473 The authors would like to express their gratitude to Wu-Chi Feng and 474 Philippe Bertin for having discussions, sharing thoughts, or 475 providing reviews on anchor selection in DMM. 477 8. References 479 8.1. Normative References 481 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 482 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 484 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 485 in IPv6", RFC 6275, July 2011. 487 8.2. Informative References 489 [Cisco-VNI] 490 Cisco Systems Inc., "Cisco Visual Networking Index: Global 491 Mobile Data Traffic Forecast Update, 2009--2014", Cisco 492 VNI , February 2010. 494 [I-D.ietf-dmm-best-practices-gap-analysis] 495 Liu, D., Zuniga, J., Seite, P., Chan, A., and C. 496 Bernardos, "Distributed Mobility Management: Current 497 practices and gap analysis", 498 draft-ietf-dmm-best-practices-gap-analysis-01 (work in 499 progress), June 2013. 501 [I-D.ietf-dmm-requirements] 502 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 503 "Requirements for Distributed Mobility Management", 504 draft-ietf-dmm-requirements-05 (work in progress), 505 June 2013. 507 Authors' Addresses 509 Hassan Ali-Ahmad (Editor) 510 Orange 511 Email: hassan.aliahmad@orange.com 513 Danny Moses 514 Intel Corporation 515 Email: danny.moses@intel.com 517 Hassnaa Moustafa 518 Intel Corporation 519 Email: hassnaa.moustafa@intel.com 521 Pierrick Seite 522 Orange 523 Email: pierrick.seite@orange.com 525 Tiago Condexia 526 University of Aveiro 527 Email: tscondeixa@ua.pt