idnits 2.17.1 draft-defoy-mptcp-5g-session-continuity-support-00.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 (Feb 13, 2019) is 1871 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-16 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. de Foy 3 Internet-Draft U. Olvera-Hernandez 4 Intended status: Informational InterDigital Communications 5 Expires: August 17, 2019 U. Chunduri 6 Huawei USA 7 Feb 13, 2019 9 5G Session Continuity Support in MPTCP 10 draft-defoy-mptcp-5g-session-continuity-support-00 12 Abstract 14 This document describes how 5G session continuity can affect MPTCP. 15 For now only potential performance issues are identified. This 16 document aims to document discussions that took place at the IETF on 17 this subject, to facilitate future deployment of MPTCP over 5G. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 17, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction and Goal . . . . . . . . . . . . . . . . . . . . 2 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 55 2.1. 5G Will Not Hide Session Continuity from MPTCP Any Longer 2 56 2.2. Detailed Issues . . . . . . . . . . . . . . . . . . . . . 3 57 3. Potential Solutions . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Alternative #1: No Change to MPTCP Protocol . . . . . . . 4 59 3.2. Alternative #2: Explicit signaling of Session Continuity 60 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Alternative #3: Client-Driven Handling . . . . . . . . . 6 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Informative References . . . . . . . . . . . . . . . . . . . 7 66 Appendix A. IP Address Session Continuity Service Type . . . . . 8 67 Appendix B. Overview of 5G Session and Service Continuity . . . 8 68 B.1. SSC mode 1 . . . . . . . . . . . . . . . . . . . . . . . 9 69 B.2. SSC mode 2 . . . . . . . . . . . . . . . . . . . . . . . 9 70 B.3. SSC mode 3 . . . . . . . . . . . . . . . . . . . . . . . 10 71 Appendix C. Example of MPTCP Client Implementations Behavior 72 with 5G SSC . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction and Goal 77 MPTCP [RFC6824] is being deployed and widely adopted in today's smart 78 devices, which typically have multiple network interfaces such as 79 Cellular and Wifi. It provides reliability, bandwidth aggregation 80 capability, and handover efficiency. 82 This document describes how 5G session continuity can affect MPTCP. 83 For now only potential performance issues are identified. This 84 document aims to document discussions that took place at the IETF on 85 this subject, to facilitate future deployment of MPTCP over 5G. 87 2. Problem Statement 89 2.1. 5G Will Not Hide Session Continuity from MPTCP Any Longer 91 In 4G [_3GPP.23.401], a single long-term IP address was provided to 92 the end device. Session continuity was performed through a fixed 93 anchor, and effectively hidden from MPTCP. 95 In 5G, session continuity won't always be hidden from MPTCP. 3 96 session continuity modes are defined in [_3GPP.23.501]: in some 97 cases, what used to be a single IP address will now be visible by 98 MPTCP as multiple successive and possibly concurrent IP addresses. 100 More details on session continuity in 5G are provided in Appendix B. 101 In particular, the 5G term for session continuity is Session and 102 Service Continuity (SSC), and the 3 SSC modes correspond to: fixed 103 anchor (mode 1), distributed anchor with break-before-make (mode 2), 104 and distributed anchor with make-before-break (mode 3). 106 While it could be possible to hide 5G session continuity to MPTCP by 107 limiting its usage to SSC mode 1, it would limit the range of 108 applications that can benefit from MPTCP, since SSC modes 2 and 3 109 enable low-latency mobility. In the rest of this document, we will 110 study how MPTCP can deal with any SSC mode. 112 An MPTCP proxy function will be integrated with the 5G network in 113 3GPP Release-16, enabling a 5G device to use MPTCP over multiple 114 access technologies (e.g. cellular and WiFi) even if the server does 115 not support MPTCP. The normative phase for this feature has recently 116 started and is based on the concluded study [_3GPP.23.793]. 118 Potential issues raised in this document may apply to 5G devices 119 directly using MPTCP without a proxy. Assuming that session 120 continuity modes 2 and 3 are available when using the MPTCP proxy 121 (which is possible but not yet established in the standard), these 122 issues may apply to 5G devices making use of the proxy as well. 124 2.2. Detailed Issues 126 Overall we don't expect SSC modes 2 and 3 will cause MPTCP to break, 127 but we do expect inefficiencies in some scenarios. The following 128 potential inefficiencies have been identified: 130 *Supporting make-before-break (MBB) without wasting resources*: 131 the old IP address should be released shortly after a MBB handover 132 has been performed. Not too early (wait for traffic using the new 133 IP address to ramp up), and not too late (to release resources to 134 the mobile network). Today's MPTCP implementations are likely to 135 keep using the old IP address as long as it is available, which 136 will prevent the network from releasing the resources early. 138 *Supporting break-before-make (BBM) without temporarily switching 139 to backup*: if there is a backup IP address, MPTCP peers should 140 not switch to using this backup IP address immediately, and 141 instead should wait for a new replacement IP address to be used 142 after BBM handover. Today's MPTCP implementations are likely to 143 switch back-and-forth between active and backup IP addresses, 144 which can lead to network and power consumption inefficiencies. 146 3. Potential Solutions 148 Locally on the mobile node itself, a MPTCP implementation will need 149 some information to support session continuity. For each local IP 150 address "IP_A", MPTCP should be aware of the following information: 152 Is IP_A provided by a mobile network, and, if applicable, what is 153 its session continuity type? Session continuity type overview and 154 references are listed in Appendix A. 156 The original local IP address of the session (if it is not IP_A). 158 The client can use the tuple (address type, original IP address) to 159 locally support session continuity. An example of implementation 160 behavior is given in Appendix C. For example, a local MPTCP client 161 implementation can use this tuple to appropriately mark new subflows 162 as "backup", when they replace original subflows marked as "backup". 164 With regard to the behavior of the remote MPTCP peer, three 165 alternatives are identified at this point: 167 In alternative #1, we do not implement any specific support in the 168 MPTCP protocol. 170 In alternative #2, the MPTCP client sends to its remote peer, over 171 MPTCP signaling, the tuple (address type, original IP address) for 172 each IP address. 174 In alternative #3, we use an hybrid solution, where the tuple 175 (address type, original IP address) is not sent to the remote 176 peer; instead, the local MPTCP client influences the remote peer 177 using modified MPTCP signaling. 179 Some enhancements to the MPTCP protocol are proposed in alternatives 180 #2 and #3. Further discussions and analysis are expected to 181 determine which alternative is best suited for MPTCP. 183 3.1. Alternative #1: No Change to MPTCP Protocol 185 This section evaluates the impact of not implementing any specific 186 support in the MPTCP protocol, for the issues mentioned earlier 187 (although the MPTCP client implementation on a 5G device should still 188 be updated to be session continuity-aware, as in all 3 alternatives, 189 to implement client-side behavior such as properly assigning the 190 "backup" property). 192 *Supporting make-before-break (MBB) without wasting resources*: 193 MBB can impact unmodified MPTCP (1) in term of network resource 194 usage and (2) in term of performances. 196 Resource usage: unmodified MPTCP will keep using the old IP 197 address until the network physically reclaims the network 198 resources when the lifetime of the old IP address is over. 199 This lifetime is not specified and may be implementation 200 specific. In the worst case, the network operator chooses a 201 long lifetime, with the option to remove the old IP address 202 after sensing it stopped being used, which would not happen 203 with MPTCP. 205 Performances: when the old IP address is brought down by the 206 network, some in-flight segments will need to be re-sent on 207 other subflows. While the client will be aware of the IP 208 address lifetime, and may therefore stop sending segments on 209 the associated subflow before reaching the end of the address 210 lifetime, the server may continue using this subflow until the 211 address is removed. The impact may therefore vary depending on 212 throughput and the nature of the application. 214 *Supporting break-before-make (BBM) without temporarily switching 215 to backup*: even if this issue is not addressed in the MPTCP 216 protocol, some applications, e.g. applications generating bursts 217 of traffic, may not be strongly impacted when temporarily 218 switching back and forth between radios, especially if the 219 occurrence is rare enough. 221 3.2. Alternative #2: Explicit signaling of Session Continuity Type 223 In this case, options that implicitly or explicitly add a new IP 224 address (MP_CAPABLE, ADD_ADDR, MP_JOIN) are associated with 225 additional fields (address type, original IP address index). This 226 way, both MPTCP peers share the same information about the IP 227 address, with regards to session continuity. 229 *Supporting make-before-break (MBB) without wasting resources*: 230 after the local client creates a new subflow using the new IP 231 address, local client and remote peer both start using it. They 232 continue sending traffic on the old subflow (i.e. subflow using 233 the old IP address), until the traffic usage ramps up on the new 234 subflow. At this point, both peers stop sending new segments on 235 the the old subflow. Once in-flight segments are received and 236 acked, the local client resets the old subflow and then remove the 237 old IP address, which makes it possible for the network to 238 ultimately reclaim the network resources. 240 *Supporting break-before-make (BBM) without temporarily switching 241 to backup*: remote peer and local client are both aware that a BBM 242 is a normal occurrence for IP addresses associated with a "non 243 persistent" type. Therefore, remote peer and local client should 244 both wait for a given time before using a backup subflow. This 245 "BBM timeout" parameter may for example be sent in a new field by 246 the local client to the remote peer, when adding the original "non 247 persistent" IP address. 249 3.3. Alternative #3: Client-Driven Handling 251 In this case, session continuity type is not sent over MPTCP 252 signaling. The local client uses non-session-continuity-specific 253 MPTCP signaling to control the behavior of the remote peer. Some 254 minor modifications of the MPTCP protocol may be needed. 256 *Supporting make-before-break (MBB) without wasting resources*: 257 the local client creates a new subflow using the new IP address. 258 After enough time passed for traffic to ramp up on the new 259 subflow, the local client instructs the remote peer to stop using 260 the old subflow (i.e. subflow using the old IP address), without 261 abruptly closing the subflow, to avoid re-sending segments on the 262 new subflow and affect performance. To do this, the local client 263 sets the priority of the old subflow to "backup", and then waits 264 until in-flight segments are received and acked. At this point, 265 the local client resets the old, now unused subflow. Once no more 266 subflows are using the old IP address, the local client removes it 267 using REMOVE_ADDR. 269 A new subflow reset reason code "path management decision" may 270 be defined to indicate that a peer took the decision to 271 permanently remove a subflow. 273 As a minor improvement, a new priority "inactive" may also be 274 defined. "Inactive" would be similar to backup, except that it 275 would never become active, even if no other active subflow 276 exist. This could avoid rare issues when losing active 277 subflows while removing an old subflow. 279 *Supporting break-before-make (BBM) without temporarily switching 280 to backup*: the local client associates a timer value to a backup 281 priority on a subflow, e.g. using a new field in the MP_PRIO 282 option. When all active subflows are lost, MPTCP peers must wait 283 for the specified time before using the backup subflow. To avoid 284 switching between backup and active subflows in BBM, the local 285 client should ensure that all backup priority timers are set to a 286 value that is higher that the maximum BBM transition time. 288 4. IANA Considerations 290 This document requests no IANA actions. 292 5. Security Considerations 294 No new security considerations are identified at this time. 296 6. Acknowledgements 298 Thanks to following people for contributing through discussions or 299 reviews: Christoph Paasch, Michelle Perras, Debashish Purkayastha, 300 Akbar Rahman, Sri Gundavelli, Philip Eardley, Yoshifumi Nishida. 302 7. Informative References 304 [_3GPP.23.401] 305 3GPP, "General Packet Radio Service (GPRS) enhancements 306 for Evolved Universal Terrestrial Radio Access Network 307 (E-UTRAN) access", 3GPP TS 23.401 15.3.0, 3 2018, 308 . 310 [_3GPP.23.501] 311 3GPP, "System Architecture for the 5G System", 3GPP 312 TS 23.501 15.14.0, 3 2018, 313 . 315 [_3GPP.23.793] 316 3GPP, "Study on Access Traffic Steering, Switch and 317 Splitting support in the 5G system architecture", 3GPP 318 TR 23.793 16.0.0, 3 2018, 319 . 321 [I-D.feng-dmm-ra-prefixtype] 322 Feng, W. and D. Moses, "Router Advertisement Prefix Option 323 Extension for On-Demand Mobility", draft-feng-dmm-ra- 324 prefixtype-03 (work in progress), September 2018. 326 [I-D.ietf-dmm-ondemand-mobility] 327 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 328 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 329 ondemand-mobility-16 (work in progress), February 2019. 331 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 332 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 333 DOI 10.17487/RFC4861, September 2007, 334 . 336 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 337 Address Autoconfiguration", RFC 4862, 338 DOI 10.17487/RFC4862, September 2007, 339 . 341 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 342 "TCP Extensions for Multipath Operation with Multiple 343 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 344 . 346 Appendix A. IP Address Session Continuity Service Type 348 The "session continuity service type" (SCS type) characterises the 349 session continuity properties an IP address allocated by a mobile 350 network. It has been defined for on-demand mobility management 351 [I-D.ietf-dmm-ondemand-mobility], as: 353 FIXED IP address: valid for a very long time, for session 354 continuity and IP address reachability. 356 SESSION_LASTING IP address: valid for the lifetime of an IP 357 session, even if the mobility host moves. 359 NON_PERSISTENT IP address: which does not provide session 360 continuity nor IP address reachability. 362 GRACEFUL_REPLACEMENT IP address: similar to a non-persistent 363 address, but adding a limited graceful period for the transition 364 from one address to another. 366 This information can be conveyed to the device by the network that 367 allocates the address: for example, as described in 368 [I-D.feng-dmm-ra-prefixtype], the SCS type of an IP address may be 369 conveyed through router advertisements. 371 Although the session continuity service types are not 3GPP-specific, 372 they are planned to be used in the 5G specification from 3GPP, as 373 properties of the IP addresses allocated by the network to mobile 374 devices. There is a 1:1 relationship between the session continuity 375 service type of the initial IP address of a session and the SSC mode 376 of this session (SSC mode is a 3GPP concept discussed in the 377 following section). 379 Appendix B. Overview of 5G Session and Service Continuity 381 One of the goals of 5G systems, as outlined in [_3GPP.23.501], is to 382 enable low latency services and access to local data networks where 383 mobility anchors can be deployed close to devices, thereby satisfying 384 use cases with stringent transmission delay and high reliability. 385 Mobility in 4G networks, as described at the architecture level in 386 [_3GPP.23.401], was based on a central mobility solution that made it 387 difficult to relocate mobility anchors closer to the end user. In 388 contrast, 5G uses a distributed mobility solution based on multiple 389 anchors providing different IP addresses as the device moves from one 390 area to another. 392 In 5G, every unit of a network connectivity service (PDU session) has 393 a type which can be IP (IPv4 or IPv6), Ethernet or unstructured. 394 Different PDU sessions will typically correspond to distinct network 395 interfaces on the device (though this is not explicit in the 396 standard, and some implementations may possibly behave differently). 398 In 4G networks, session continuity is enabled by anchoring a PDN 399 Connection (as PDU Sessions are referred to in 4G networks) to a P-GW 400 which allocates an IP address to the mobile device: PDN connection 401 and IP address allocation are maintained as long as the device 402 remains attached to the network, even when the device moves around. 403 In 5G, different types of session continuity can be provided, and are 404 indicated by a "Session and Service Continuity" (SSC) mode value of 405 1, 2 or 3 (defined in [_3GPP.23.501] section 5.6.9). Every PDU 406 session is associated with a single SSC mode, which cannot be changed 407 on this PDU session. The following sub-sections will study how 5G 408 handles each SSC mode, and potential effects on MPTCP. 410 B.1. SSC mode 1 412 In SSC mode 1 the same network anchor is kept regardless of device 413 location. An application running on the device will therefore be 414 able to keep using the same IP address on the same interface. 416 Additionally, in SSC mode 1, the network may decide to add and 417 remove, dynamically, additional network anchors (and therefore IP 418 addresses) to the PDU session, while always keeping the initial one. 419 This would result in a second IP address being allocated on the 420 network interface with which the long-term IP address is associated. 421 This second IP address may be brought down at any time. 423 B.2. SSC mode 2 425 SSC mode 2 has a break-before-make behavior. When the device leaves 426 the service area of its first network anchor, the network stops using 427 it and starts using a second network anchor closer to the device. 428 (Such service areas may have a highly variable size depending on 429 network deployments.) On the device, this can result in the 430 currently used network interface being brought down, and after a 431 short time a new network interface being brought up. The time 432 between these 2 events is not standardized and implementation 433 dependent. 435 B.3. SSC mode 3 437 SSC mode 3 has a make-before-break behavior. When the device leaves 438 the service area of its first network anchor, the network selects a 439 second network anchor closer to the device, and either creates a new 440 PDU session (i.e. new IP address on new network interface) or share 441 the existing PDU session (i.e. new IP address on same network 442 interface). The first network anchor keeps being used for a given 443 time period, which is communicated to the device by the network using 444 the "valid lifetime" field of a prefix information option in a router 445 advertisement ([RFC4861], [RFC4862]). 5G specifications does not 446 mandate a specific range for this valid lifetime. The first/older IP 447 address should not be used to create any new traffic ([RFC4862] 448 section 5.5.4). In some implementations, the network (SMF) may 449 decide to release the first network anchor as soon as it stops 450 carrying traffic. 452 There is no limit set by the 5G standard for the number of 453 concurrently used network anchors. We expect that in usual cases the 454 first network anchor will be released before a third network anchor 455 starts being used. Nevertheless, to our knowledge nothing prevents a 456 5G system deployment to allow a third network anchor to be selected 457 while the first one is still in use. 459 On the 5G device, when using SSC mode 3, mobility will therefore 460 result in a new IP address being configured, either on the same 461 network interface initially used, or on a different network 462 interface. In general, an application will see a single cellular- 463 facing IP address, and during transient phase it will see 2 IP 464 addresses (with a possibility for more than 2 concurrent IP addresses 465 on some 5G system implementations). 467 Appendix C. Example of MPTCP Client Implementations Behavior with 5G 468 SSC 470 The following describes at high level how a MPTCP implementation 471 could be modified to on the client to support 5G session continuity. 472 If the solution alternative #2 is used, this behavior can be extended 473 to the MPTCP server as well. 475 For simplicity, we consider a case where MPTCP is used in a client 476 with 2 IP addresses, one of them being provided by a mobile network. 477 The behaviors described here depend on the session continuity type of 478 the initial mobile network-provided IP address, which has a 1:1 479 mapping to the 5G SCC mode used. 481 When the initial IP address session continuity type is FIXED or 482 SESSION_LASTING (i.e. in SCC mode 1): 484 MPTCP should not close all subflows originated from this original 485 IP address at any point during the session, since this IP address 486 is the only one that is guaranteed, under normal circumstances, to 487 be maintained over time for this application. 489 At any time during the session, a new IP address of SCS type 490 NON_PERSISTENT may become available. MPTCP may create new 491 subflows for the application, using this IP address (this IP 492 address is likely to provide shorter path subflows, but may 493 disappear at any time). 495 When the initial IP address session continuity type is NON_PERSISTENT 496 (i.e. in SCC mode 2): 498 At any point in time, the current NON_PERSISTENT IP address may be 499 taken down by the network stack. The MPTCP implementation should 500 wait for another NON_PERSISTENT IP address to be made available by 501 the network stack. If such an address is made available within a 502 given time limit, the MPTCP stack should create new subflows using 503 this new address (effectively following the existing break-before- 504 make behavior present in MPTCP). 506 Additionally, if an initial backup IP address is a NON_PERSISTENT 507 address, the MPTCP stack should consider any subsequent 508 NON_PERSISTENT IP address as a backup IP address in replacement of 509 the initial NON_PERSISTENT address. 511 When the initial IP address session continuity type is 512 GRACEFUL_REPLACEMENT (i.e. in SCC mode 3): 514 At any point in time, a new GRACEFUL_REPLACEMENT IP address may be 515 made available by the network stack. The MPTCP implementation 516 must create new subflows using this new address, gracefully 517 transfer traffic to these new subflow(s), and close subflow(s) 518 using the previous GRACEFUL_REPLACEMENT IP address before its 519 scheduled closing (known by obtaining the valid lifetime of the IP 520 address from the operating system). 522 Additionally, if an initial backup IP address is a 523 GRACEFUL_REPLACEMENT address, the MPTCP implementation should 524 consider any subsequent GRACEFUL_REPLACEMENT IP address as the new 525 backup IP address, in replacement of the first 526 GRACEFUL_REPLACEMENT IP address. 528 Authors' Addresses 530 Xavier de Foy 531 InterDigital Communications, LLC 532 1000 Sherbrooke West 533 Montreal H3A 3G4 534 Canada 536 Email: Xavier.Defoy@InterDigital.com 538 Ulises Olvera-Hernandez 539 InterDigital Communications, LLC 540 64 Great Eastern Street 541 London EC2A 3QR 542 England 544 Email: Ulises.Olvera-Hernandez@InterDigital.com 546 Uma Chunduri 547 Huawei USA 548 2330 Central Expressway 549 Santa Clara, CA 95050 550 USA 552 Email: uma.chunduri@huawei.com