idnits 2.17.1 draft-defoy-5g-session-continuity-support-in-mptcp-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 (Oct 19, 2018) is 2013 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-15 -- 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: April 22, 2019 U. Chunduri 6 Huawei USA 7 Oct 19, 2018 9 5G Session Continuity Support in MPTCP 10 draft-defoy-5g-session-continuity-support-in-mptcp-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 April 22, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 9 71 Appendix C. Example of MPTCP Client Implementations Behavior 72 with 5G SSC . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 2.2. Detailed Issues 114 Overall we don't expect SSC modes 2 and 3 will cause MPTCP to break, 115 but we do expect inefficiencies in some scenarios. The following 116 potential inefficiencies have been identified: 118 *Supporting make-before-break (MBB) without wasting resources*: 119 the old IP address should be released shortly after a MBB handover 120 has been performed. Not too early (wait for traffic using the new 121 IP address to ramp up), and not too late (to release resources to 122 the mobile network). Today's MPTCP implementations are likely to 123 keep using the old IP address as long as it is available, which 124 will prevent the network from releasing the resources early. 126 *Supporting break-before-make (BBM) without temporarily switching 127 to backup*: if there is a backup IP address, MPTCP peers should 128 not switch to using this backup IP address immediately, and 129 instead should wait for a new replacement IP address to be used 130 after BBM handover. Today's MPTCP implementations are likely to 131 switch back-and-forth between active and backup IP addresses, 132 which can lead to network and power consumption inefficiencies. 134 3. Potential Solutions 136 Locally on the mobile node itself, a MPTCP implementation will need 137 some information to support session continuity. For each IP address, 138 MPTCP should be aware of the following information: 140 Is the IP address provided by a mobile network, and, if 141 applicable, what is the session continuity type associated with 142 the IP address? Session continuity type overview and references 143 are listed in Appendix A. 145 The original IP address of the session this IP address is a part 146 of (unless this IP address is the original IP address itself). 148 The client can use this (address type, original IP address) tuple to 149 locally support session continuity. An example of implementation 150 behavior is given in Appendix C. For example, a local MPTCP client 151 implementation can use this tuple to appropriately mark new subflows 152 as "backup", when they replace original subflows marked as "backup". 154 With regards to the behavior of the remote MPTCP peer, three 155 alternatives are identified at this point: 157 In alternative #1, we do not implement any specific support in the 158 MPTCP protocol. 160 In alternative #2, the MPTCP client sends to its remote peer, over 161 MPTCP signaling, the tuple (address type, original IP address) for 162 each IP address. 164 In alternative #3, we use an hybrid solution, where the tuple 165 (address type, original IP address) is not sent to the remote 166 peer; instead, the local MPTCP client influences the remote peer 167 using modified MPTCP signaling. 169 Some enhancements to the MPTCP protocol are proposed in alternatives 170 #2 and #3. Further discussions and analysis are expected to 171 determine which alternative is best suited for MPTCP. 173 3.1. Alternative #1: No Change to MPTCP Protocol 175 This section evaluates the impact of not implementing any specific 176 support in the MPTCP protocol, for the issues mentioned earlier 177 (although the MPTCP client implementation on a 5G device should still 178 be updated to be session continuity-aware, as in all 3 alternatives, 179 to implement client-side behavior such as properly assigning the 180 "backup" property). 182 *Supporting make-before-break (MBB) without wasting resources*: 183 not implementing any specific support in MPTCP can be acceptable 184 (1) if the impact on the network resource usage is acceptable, and 185 (2) if the impact on performances is acceptable. Both those 186 impacts are likely to vary in practice. About (1): unmodified 187 MPTCP will keep using the old IP address until the network 188 physically reclaims the network resources when the lifetime of the 189 old IP address is over. This lifetime is not specified and may be 190 implementation specific. About (2): when the old IP address is 191 brought down by the network, some in-flight segments will need to 192 be re-sent on other subflows. The impact may therefore vary 193 depending on throughput and the nature of the application. 195 *Supporting break-before-make (BBM) without temporarily switching 196 to backup*: if we do not attempt to address this issue, we count 197 on the fact that (1) the effect of temporarily switching back and 198 forth between radios has an "acceptable impact", and/or (2) the 199 problem is rare enough. Again, these are points that may be best 200 estimated after deployment, and that could evolve over time, with 201 applications usage patterns. About (2): this issue is specific to 202 SSC mode 2; applications that exchange bursts of traffic (e.g. 203 browsers), which are well suited for mode 2, may reduce the rate 204 of occurrence. 206 3.2. Alternative #2: Explicit signaling of Session Continuity Type 208 In this case, options that implicitly or explicitly add a new IP 209 address (MP_CAPABLE, ADD_ADDR, MP_JOIN) are associated with 210 additional fields (address type, original IP address index). This 211 way, both MPTCP peers share the same information about the IP 212 address, with regards to session continuity. 214 *Supporting make-before-break (MBB) without wasting resources*: 215 after the local client creates a new subflow using the new IP 216 address, local client and remote peer both start using it. They 217 continue sending traffic on the old subflow (i.e. subflow using 218 the old IP address), until the traffic usage ramps up on the new 219 subflow. At this point, both peers stop sending new segments on 220 the the old subflow. Once in-flight segments are received and 221 acked, the local client resets the old subflow and then remove the 222 old IP address, which makes it possible for the network to 223 ultimately reclaim the network resources. 225 *Supporting break-before-make (BBM) without temporarily switching 226 to backup*: remote peer and local client are both aware that a BBM 227 is a normal occurrence for IP addresses associated with a "non 228 persistent" type. Therefore, remote peer and local client should 229 both wait for a given time before using a backup subflow. This 230 "BBM timeout" parameter may for example be sent in a new field by 231 the local client to the remote peer, when explicitly or implicitly 232 adding the original "non persistent" IP address. 234 3.3. Alternative #3: Client-Driven Handling 236 In this case, session continuity type is not sent over MPTCP 237 signaling. The local client uses "generic" (i.e. non-session- 238 continuity-specific) MPTCP signaling to control the behavior of the 239 remote peer. Some minor modifications of the MPTCP protocol may be 240 needed. 242 *Supporting make-before-break (MBB) without wasting resources*: 243 the local client creates a new subflow using the new IP address. 244 After enough time passed for traffic to ramp up on the new 245 subflow, the local client instructs the remote peer to stop using 246 the old subflow (i.e. subflow using the old IP address), without 247 abruptly closing the subflow, to avoid re-sending segments on the 248 new subflow and affect performance. To do this, the local client 249 sets the priority of the old subflow to "backup", and then waits 250 until in-flight segments are received and acked. At this point, 251 the local client resets the old, now unused subflow. Once no more 252 subflows are using the old IP address, the local client removes it 253 using REMOVE_ADDR. 255 A new subflow reset reason code "path management decision" may 256 be defined to indicate that a peer took the decision to 257 permanently remove a subflow (this new reason code may also be 258 useful in alternative #1). 260 As a minor improvement, a new priority "inactive" may also be 261 defined. "Inactive" would be similar to backup, except that it 262 would never become active, even if no other active subflow 263 exist. This could avoid rare issues when losing active 264 subflows while removing an old subflow. 266 *Supporting break-before-make (BBM) without temporarily switching 267 to backup*: the local client associates a timer value to a backup 268 priority on a subflow, e.g. using a new field in the MP_PRIO 269 option. When all active subflows are lost, MPTCP peers must wait 270 for the specified time before using the backup subflow. To avoid 271 switching between backup and active subflows in BBM, the local 272 client should ensure that all backup priority timers are set to a 273 value that is higher that the maximum BBM transition time. 275 4. IANA Considerations 277 This document requests no IANA actions. 279 5. Security Considerations 281 No new security considerations are identified at this time. 283 6. Acknowledgements 285 Thanks to following people for contributing through discussions or 286 reviews: Christoph Paasch, Michelle Perras, Debashish Purkayastha, 287 Akbar Rahman, Sri Gundavelli, Philip Eardley, Yoshifumi Nishida. 289 7. Informative References 291 [_3GPP.23.401] 292 3GPP, "General Packet Radio Service (GPRS) enhancements 293 for Evolved Universal Terrestrial Radio Access Network 294 (E-UTRAN) access", 3GPP TS 23.401 15.3.0, 3 2018, 295 . 297 [_3GPP.23.501] 298 3GPP, "System Architecture for the 5G System", 3GPP 299 TS 23.501 15.14.0, 3 2018, 300 . 302 [I-D.feng-dmm-ra-prefixtype] 303 Feng, W. and D. Moses, "Router Advertisement Prefix Option 304 Extension for On-Demand Mobility", draft-feng-dmm-ra- 305 prefixtype-03 (work in progress), September 2018. 307 [I-D.ietf-dmm-ondemand-mobility] 308 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 309 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 310 ondemand-mobility-15 (work in progress), July 2018. 312 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 313 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 314 DOI 10.17487/RFC4861, September 2007, 315 . 317 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 318 Address Autoconfiguration", RFC 4862, 319 DOI 10.17487/RFC4862, September 2007, 320 . 322 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 323 "TCP Extensions for Multipath Operation with Multiple 324 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 325 . 327 Appendix A. IP Address Session Continuity Service Type 329 The "session continuity service type" (SCS type) characterises the 330 session continuity properties an IP address allocated by a mobile 331 network. It has been defined for on-demand mobility management 332 [I-D.ietf-dmm-ondemand-mobility], as: 334 FIXED IP address: valid for a very long time, for session 335 continuity and IP address reachability. 337 SESSION_LASTING IP address: valid for the lifetime of an IP 338 session, even if the mobility host moves. 340 NON_PERSISTENT IP address: which does not provide session 341 continuity nor IP address reachability. 343 GRACEFUL_REPLACEMENT IP address: similar to a non-persistent 344 address, but adding a limited graceful period for the transition 345 from one address to another. 347 This information can be conveyed to the device by the network that 348 allocates the address: for example, as described in 349 [I-D.feng-dmm-ra-prefixtype], the SCS type of an IP address may be 350 conveyed through router advertisements. 352 The session continuity service types are planned to be used in the 5G 353 specification from 3GPP, as properties of the IP addresses allocated 354 by the network to mobile devices. There is a 1:1 relationship 355 between the session continuity service type of the initial IP address 356 of a session and the SSC mode of this session (SSC mode is a 3GPP 357 concept discussed in the following section). 359 Appendix B. Overview of 5G Session and Service Continuity 361 One of the goals of 5G systems, as outlined in [_3GPP.23.501], is to 362 enable low latency services and access to local data networks where 363 mobility anchors can be deployed close to devices, thereby satisfying 364 use cases with stringent transmission delay and high reliability. 365 Mobility in 4G networks, as described at the architecture level in 366 [_3GPP.23.401], was based on a central mobility solution that made it 367 difficult to relocate mobility anchors closer to the end user. In 368 contrast, 5G uses a distributed mobility solution based on multiple 369 anchors providing different IP addresses as the device moves from one 370 area to another. 372 In 5G, every unit of a network connectivity service (PDU session) has 373 a type which can be IP (IPv4 or IPv6), Ethernet or unstructured. 374 Different PDU sessions will typically correspond to distinct network 375 interfaces on the device (though this is not explicit in the 376 standard, and some implementations may possibly behave differently). 378 In 4G networks, session continuity is enabled by anchoring a PDN 379 Connection (as PDU Sessions are referred to in 4G networks) to a P-GW 380 which allocates an IP address to the mobile device: PDN connection 381 and IP address allocation are maintained as long as the device 382 remains attached to the network, even when the device moves around. 383 In 5G, different types of session continuity can be provided, and are 384 indicated by a "Session and Service Continuity" (SSC) mode value of 385 1, 2 or 3 (defined in [_3GPP.23.501] section 5.6.9). Every PDU 386 session is associated with a single SSC mode, which cannot be changed 387 on this PDU session. The following sub-sections will study how 5G 388 handles each SSC mode, and potential effects on MPTCP. 390 B.1. SSC mode 1 392 In SSC mode 1 the same network anchor is kept regardless of device 393 location. An application running on the device will therefore be 394 able to keep using the same IP address on the same interface. 396 Additionally, in SSC mode 1, the network may decide to add and 397 remove, dynamically, additional network anchors (and therefore IP 398 addresses) to the PDU session, while always keeping the initial one. 399 This would result in a second IP address being allocated on the 400 network interface with which the long-term IP address is associated. 401 This second IP address may be brought down at any time. 403 B.2. SSC mode 2 405 SSC mode 2 has a break-before-make behavior. When the device leaves 406 the service area of its first network anchor, the network stops using 407 it and starts using a second network anchor closer to the device. 408 (Such service areas may have a highly variable size depending on 409 network deployments.) On the device, this can result in the 410 currently used network interface being brought down, and after a 411 short time a new network interface being brought up. The time 412 between these 2 events is not standardized and implementation 413 dependent. 415 B.3. SSC mode 3 417 SSC mode 3 has a make-before-break behavior. When the device leaves 418 the service area of its first network anchor, the network selects a 419 second network anchor closer to the device, and either creates a new 420 PDU session (i.e. new IP address on new network interface) or share 421 the existing PDU session (i.e. new IP address on same network 422 interface). The first network anchor keeps being used for a given 423 time period, which is communicated to the device by the network using 424 the "valid lifetime" field of a prefix information option in a router 425 advertisement ([RFC4861], [RFC4862]). 5G specifications does not 426 mandate a specific range for this valid lifetime. The first/older IP 427 address should not be used to create any new traffic ([RFC4862] 428 section 5.5.4). In some implementations, the network (SMF) may 429 decide to release the first network anchor as soon as it stops 430 carrying traffic. 432 There is no limit set by the 5G standard for the number of 433 concurrently used network anchors. We expect that in usual cases the 434 first network anchor will be released before a third network anchor 435 starts being used. Nevertheless, to our knowledge nothing prevents a 436 5G system deployment to allow a third network anchor to be selected 437 while the first one is still in use. 439 On the 5G device, when using SSC mode 3, mobility will therefore 440 result in a new IP address being configured, either on the same 441 network interface initially used, or on a different network 442 interface. In general, an application will see a single cellular- 443 facing IP address, and during transient phase it will see 2 IP 444 addresses (with a possibility for more than 2 concurrent IP addresses 445 on some 5G system implementations). 447 Appendix C. Example of MPTCP Client Implementations Behavior with 5G 448 SSC 450 The following describes at high level how a MPTCP implementation 451 could be modified to locally support 5G session continuity. A 452 discussion of how this behavior can be extended to the remote MPTCP 453 peer is a core subject of this draft, and discussed in the body of 454 the draft. 456 For simplicity, we consider a case where MPTCP is used in a client 457 with 2 IP addresses, one of them being provided by a mobile network. 458 The behaviors described here depend on the session continuity type of 459 the initial mobile network-provided IP address, which has a 1:1 460 mapping to the 5G SCC mode used. 462 When the initial IP address session continuity type is FIXED or 463 SESSION_LASTING (i.e. in SCC mode 1): 465 MPTCP should not close all subflows originated from this original 466 IP address at any point during the session, since this IP address 467 is the only one that is guaranteed, under normal circumstances, to 468 be maintained over time for this application. 470 At any time during the session, a new IP address of SCS type 471 NON_PERSISTENT may become available. MPTCP may create new 472 subflows for the application, using this IP address (this IP 473 address is likely to provide shorter path subflows, but may 474 disappear at any time). 476 When the initial IP address session continuity type is NON_PERSISTENT 477 (i.e. in SCC mode 2): 479 At any point in time, the current NON_PERSISTENT IP address may be 480 taken down by the network stack. The MPTCP stack should wait for 481 another NON_PERSISTENT IP address to be made available by the 482 network stack. If such an address is made available within a 483 given time limit, the MPTCP stack should create new subflows using 484 this new address (effectively following the existing break-before- 485 make behavior present in MPTCP). 487 Additionally, if an initial backup IP address is a NON_PERSISTENT 488 address, the MPTCP stack should consider any subsequent 489 NON_PERSISTENT IP address as a backup IP address in replacement of 490 the initial NON_PERSISTENT address. 492 When the initial IP address session continuity type is 493 GRACEFUL_REPLACEMENT (i.e. in SCC mode 3): 495 At any point in time, a new GRACEFUL_REPLACEMENT IP address may be 496 made available by the network stack. The MPTCP stack must create 497 new subflows using this new address, gracefully transfer traffic 498 to these new subflow(s), and close subflow(s) using the previous 499 GRACEFUL_REPLACEMENT IP address before its scheduled closing 500 (known by obtaining the valid lifetime of the IP address from the 501 operating system). 503 Additionally, if an initial backup IP address is a 504 GRACEFUL_REPLACEMENT address, the MPTCP stack should consider any 505 subsequent GRACEFUL_REPLACEMENT IP address as the new backup IP 506 address, in replacement of the first GRACEFUL_REPLACEMENT IP 507 address. 509 Authors' Addresses 511 Xavier de Foy 512 InterDigital Communications, LLC 513 1000 Sherbrooke West 514 Montreal H3A 3G4 515 Canada 517 Email: Xavier.Defoy@InterDigital.com 518 Ulises Olvera-Hernandez 519 InterDigital Communications, LLC 520 64 Great Eastern Street 521 London EC2A 3QR 522 England 524 Email: Ulises.Olvera-Hernandez@InterDigital.com 526 Uma Chunduri 527 Huawei USA 528 2330 Central Expressway 529 Santa Clara, CA 95050 530 USA 532 Email: uma.chunduri@huawei.com