idnits 2.17.1 draft-deng-mif-api-session-continuity-guide-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-mif-api-extension]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 1, 2014) is 3587 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF WG H. Deng 3 Internet-Draft China Mobile 4 Intended status: Informational S. Krishnan 5 Expires: January 2, 2015 Ericsson 6 T. Lemon 7 Nominum 8 M. Wasserman 9 Painless Security, LLC 10 July 1, 2014 12 Guide for application developers on session continuity by using MIF API 13 draft-deng-mif-api-session-continuity-guide-04 15 Abstract 17 Today most smart terminals are equiped with multiple interfaces such 18 as 3G/LTE and WiFi, and users experience some loss of connectivity 19 while switching interfaces. The MIF API draft 20 [I-D.ietf-mif-api-extension] has specified an API to announce 21 interface status information to the applications. Once the 22 application receives such information, it can use this information 23 reconnect to its peer(s), and this could significantly improve the 24 user experience. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 2, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Related MIF API information . . . . . . . . . . . . . . . . . 3 68 3. Using different source address to reconnect the server . . . 3 69 4. Generic guidelines for writing applications to handle new 70 interfaces becoming available . . . . . . . . . . . . . . . . 4 71 5. Generic guidelines for writing applications to handle 72 interfaces becoming unavailable . . . . . . . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 76 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 A significant and increasing number of smart mobile terminals have 82 multiple interfaces for connectivity (e.g. Wifi and 3G/LTE). These 83 interfaces may have very characteristics in terms of reliability, 84 available bandwidth, delay/jitter as well as cost per bit. There is 85 some form of connection manager on the end device that picks an 86 interface for communication based on some pre-configured policy and/ 87 or based on dynamic conditions. The initially selected interface may 88 become deprioritized (e.g. due to a lower cost interface becoming 89 available) or may become unavailable (e.g. due to loss of coverage 90 when moving out of a WiFi hotspot). New interfaces may become 91 available due to administrative action (e.g. manual activation of a 92 specific connectivity technology) or due to dynamic conditions (e.g. 93 entering coverage area of a wireless network or plugging in an 94 ethernet cable). In order to handle such changes in connectivity, 95 applications need to be aware of network status changes and react to 96 them. This document provides a guide to writing such applications. 98 The MIF API [I-D.ietf-mif-api-extension] document specifies an API 99 that is capable of providing information regarding changes in network 100 and interface connectivity status. By using this information, 101 application developers can develop applications that can survive 102 changes in connectivity and even benefit from them. 104 The MIF MPVD Architecture [I-D.ietf-mif-mpvd-arch] document defines 105 the notion of a PVD (set of network configuration information), and 106 PVDs somehow must be exposed, in case applications are not PVD- 107 awared, or indirectly participating the selection of PVD, or knowing 108 of the PVDs based on PVD APIs. The MIF API 109 [I-D.ietf-mif-api-extension] document specifies "Connect to PVD" 110 message, application developers may develop appliation that can 111 changes between different PVD connectivity. 113 2. Related MIF API information 115 MIF API draft [I-D.ietf-mif-api-extension] defines a few messages 116 that are related to notifying whether an interface is available or 117 not. The messages are defined in Section 3.5.1 (Announce Interfaces) 118 and Section 3.5.4 (No Inteface). Similar functionaility is available 119 for addresses using the messages defined in Section 3.5.12 (Announce 120 Address) and Section 3.5.14 (No Address Announcement). The API also 121 specifies interface change information in section 3.5.23.5 (Interface 122 is going up) and 3.5.23.4 (Interface is going away). Both interface 123 and address information could be used by the application to infer the 124 availablility of a new endpoint for communication or the loss of an 125 existing endpoint for communication. 127 3. Using different source address to reconnect the server 129 The applications deployed on mobile hosts usually setup the 130 connection with the server, then trying to keep the connection up as 131 long as they can. This works reasonable well when the host has only 132 one communication interface. Once the host has more than one 133 communication interface, such as 3G/LTE and WLAN, such applications 134 cease to work well. e.g. The per bit cost and the connection speed 135 are different on these two interfaces, and the user would always 136 prefer to change another cheaper and faster connection. e.g. While 137 connecting to a WLAN interface after being connected to LTE, the 138 mobile terminal would get a different set of configuration parameters 139 including the IP address, DNS server and default gateway. 140 Application would normally break after such change in connectivity if 141 the original interface (3G/LTE) is turned off and manual intervention 142 is usually required to reinitiate connectivity. 144 If the application is designed with changing network connectivity in 145 mind, then the application could be carefully designed reconnect to 146 its peer based on MIF API notification about new interface(s) and/or 147 new address(es). The application needs to start testing the 148 usability of the new interface(s)/address(es) immediately and 149 determine whether they are usable and, if so, decide what traffic to 150 switch over. Please note that there are other solutions for handling 151 address changes in the lower layers (network and transport) like 152 MIPv6, shim6, and MPTCP that can shield the application from address 153 changes. The guidelines provided in this document are also 154 applicable when these techniques are being used. Also, there might 155 be load balancers present on the server side and it may become very 156 difficult to preserve sessions after an address change has occurred. 158 In most cases even when a mobile terminal gets WLAN connectivity and 159 gets an IP address assgined, but it could still be disconnected from 160 the Internet due to lack of authentication. As a consequence, the 161 interface needs to be tested for internet connectivity before 162 switching communication from an existing interface to a newly 163 available interface. 165 4. Generic guidelines for writing applications to handle new interfaces 166 becoming available 168 The recommended steps for the application developer to keep the 169 session continuity based on MIF API are listed below: 171 Step 1: Application subscribes to the MIF API for interface and 172 address change notifications; 174 Step 2: Application connects to the server based on interface 1 175 (either 3G/LTE or WLAN); 177 Step 3: When a new interface comes up or a new address is configured, 178 the MIF API notifies the application. 180 Step 4: The application tries to re-connect to its peer from the 181 newly available interface. If the connectivity check succeeds, then 182 the application can successfully switch the communication over to the 183 new interface based on policy or user initiated selection. Otherwise 184 communication stays on the existing inteface. The decision process 185 on how a preferred interface is selected is out of scope of this 186 document and might be the topic for a separate high level API 187 document. 189 Step 5: The interface initially used for communication may now be 190 turned off without disrupting communications if no other applications 191 are using it. 193 5. Generic guidelines for writing applications to handle interfaces 194 becoming unavailable 196 The recommended steps for the application developer to keep the 197 session continuity based on MIF API are listed below: 199 Step 1: Application subscribes to the MIF API for interface and 200 address change notifications; 202 Step 2: Application connects to the server based on interface 1 203 (either 3G/LTE or WLAN); 205 Step 3: When an interface or address, that is currently being used 206 for communication, becomes unavailable the MIF API notifies the 207 application. 209 Step 4: The application requests the MIF API to acquire a list of 210 interfaces that are currently available. Based on locally configured 211 preferences, the application tries to re-connect to its peer from one 212 of the available interfaces. If the connectivity check succeeds, 213 then the application can successfully switch the communication over 214 to this interface. 216 Step 5: If the connectivity check fails, the application needs to 217 redo the check for each of the available interfaces in order of 218 preference until it can successfully connect to its peer. 220 Step 6: If at least one available interface is still able to connect 221 to the peer, the application can switch over to this interface 222 without disrupting communications. 224 6. IANA Considerations 226 This document does not require any IANA actions. 228 7. Security Considerations 230 Some applications may associate the the source address of the 231 communication with the credentials used, it they may require 232 refreshing the credentials after the application switches to using a 233 new source address. 235 8. Acknowledgements 237 The authors would like to thank Pete McCann, Julien Laganier, Dapeng 238 Liu, Dave Thaler, Brian Carpenter and Pierrick Seite for their 239 comments and suggestions for improving this document. 241 9. Normative References 243 [I-D.ietf-mif-api-extension] 244 Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API 245 consideration", draft-ietf-mif-api-extension-05 (work in 246 progress), February 2014. 248 [I-D.ietf-mif-mpvd-arch] 249 Anipko, D., "MIF MPVD Architecture", draft-ietf-mif-mpvd- 250 arch-01 (work in progress), May 2014. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 Authors' Addresses 257 Hui Deng 258 China Mobile 259 No.32 Xuanwumen West Street 260 Xicheng District, 261 Beijing 100053 262 China 264 Email: denghui02@gmail.com 266 Suresh Krishnan 267 Ericsson 268 8400 Blvd Decarie 269 Town of Mount Royal, Quebecy 270 Canada 272 Email: suresh.krishnan@ericsson.com 274 Ted Lemon 275 Nominum 276 Redwood City, 277 94063 278 USA 280 Email: Ted.Lemon@nominum.com 281 Margaret Wasserman 282 Painless Security, LLC 283 356 Abbott Street, 284 North Andover 01845 285 USA 287 Email: mrw@painless-security.com