idnits 2.17.1 draft-deng-mif-api-session-continuity-guide-03.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 (October 22, 2012) is 4201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-mif-api-extension-00 == Outdated reference: A later version (-01) exists of draft-tarreau-extend-flow-label-balancing-00 Summary: 1 error (**), 0 flaws (~~), 5 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: April 25, 2013 Ericsson 6 T. Lemon 7 Nominum 8 M. Wasserman 9 Painless Security, LLC 10 October 22, 2012 12 Guide for application developers on session continuity by using MIF API 13 draft-deng-mif-api-session-continuity-guide-03 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 April 25, 2013. 49 Copyright Notice 51 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 A significant and increasing number of smart mobile terminals have 84 multiple interfaces for connectivity (e.g. Wifi and 3G/LTE). These 85 interfaces may have very characteristics in terms of reliability, 86 available bandwidth, delay/jitter as well as cost per bit. There is 87 some form of connection manager on the end device that picks an 88 interface for communication based on some pre-configured policy 89 and/or based on dynamic conditions. The initially selected interface 90 may become deprioritized (e.g. due to a lower cost interface becoming 91 available) or may become unavailable (e.g. due to loss of coverage 92 when moving out of a WiFi hotspot). New interfaces may become 93 available due to administrative action (e.g. manual activation of a 94 specific connectivity technology) or due to dynamic conditions (e.g. 95 entering coverage area of a wireless network or plugging in an 96 ethernet cable). In order to handle such changes in connectivity, 97 applications need to be aware of network status changes and react to 98 them. This document provides a guide to writing such applications. 100 The MIF API [I-D.ietf-mif-api-extension] document specifies an API 101 that is capable of providing information regarding changes in network 102 and interface connectivity status. By using this information, 103 application developers can develop applications that can survive 104 changes in connectivity and even benefit from them. 106 2. Related MIF API information 108 MIF API draft [I-D.ietf-mif-api-extension] defines a few messages 109 that are related to notifying whether an interface is available or 110 not. The messages are defined in Section 3.5.1 (Announce Interfaces) 111 and Section 3.5.4 (No Inteface). Similar functionaility is available 112 for addresses using the messages defined in Section 3.5.12 (Announce 113 Address) and Section 3.5.14 (No Address Announcement). The API also 114 specifies interface change information in section 3.5.23.5 (Interface 115 is going up) and 3.5.23.4 (Interface is going away). Both interface 116 and address information could be used by the application to infer the 117 availablility of a new endpoint for communication or the loss of an 118 existing endpoint for communication. 120 3. Using different source address to reconnect the server 122 The applications deployed on mobile hosts usually setup the 123 connection with the server, then trying to keep the connection up as 124 long as they can. This works reasonable well when the host has only 125 one communication interface. Once the host has more than one 126 communication interface, such as 3G/LTE and WLAN, such applications 127 cease to work well. e.g. The per bit cost and the connection speed 128 are different on these two interfaces, and the user would always 129 prefer to change another cheaper and faster connection. e.g. While 130 connecting to a WLAN interface after being connected to LTE, the 131 mobile terminal would get a different set of configuration parameters 132 including the IP address, DNS server and default gateway. 133 Application would normally break after such change in connectivity if 134 the original interface (3G/LTE) is turned off and manual intervention 135 is usually required to reinitiate connectivity. 137 If the application is designed with changing network connectivity in 138 mind, then the application could be carefully designed reconnect to 139 its peer based on MIF API notification about new interface(s) and/or 140 new address(es). The application needs to start testing the 141 usability of the new interface(s)/address(es) immediately and 142 determine whether they are usable and, if so, decide what traffic to 143 switch over. Please note that there are other solutions for handling 144 address changes in the lower layers (network and transport) like 145 MIPv6, shim6, and MPTCP that can shield the application from address 146 changes. The guidelines provided in this document are also 147 applicable when these techniques are being used. Also, there might 148 be load balancers present on the server side and it may become very 149 difficult to preserve sessions after an address change has occurred. 150 For further details on the load balancer related issues, please refer 151 to [I-D.tarreau-extend-flow-label-balancing] 153 In most cases even when a mobile terminal gets WLAN connectivity and 154 gets an IP address assgined, but it could still be disconnected from 155 the Internet due to lack of authentication. As a consequence, the 156 interface needs to be tested for internet connectivity before 157 switching communication from an existing interface to a newly 158 available interface. 160 4. Generic guidelines for writing applications to handle new interfaces 161 becoming available 163 The recommended steps for the application developer to keep the 164 session continuity based on MIF API are listed below: 166 Step 1: Application subscribes to the MIF API for interface and 167 address change notifications; 169 Step 2: Application connects to the server based on interface 1 170 (either 3G/LTE or WLAN); 172 Step 3: When a new interface comes up or a new address is configured, 173 the MIF API notifies the application. 175 Step 4: The application tries to re-connect to its peer from the 176 newly available interface. If the connectivity check succeeds, then 177 the application can successfully switch the communication over to the 178 new interface based on policy or user initiated selection. Otherwise 179 communication stays on the existing inteface. The decision process 180 on how a preferred interface is selected is out of scope of this 181 document and might be the topic for a separate high level API 182 document. 184 Step 5: The interface initially used for communication may now be 185 turned off without disrupting communications if no other applications 186 are using it. 188 5. Generic guidelines for writing applications to handle interfaces 189 becoming unavailable 191 The recommended steps for the application developer to keep the 192 session continuity based on MIF API are listed below: 194 Step 1: Application subscribes to the MIF API for interface and 195 address change notifications; 197 Step 2: Application connects to the server based on interface 1 198 (either 3G/LTE or WLAN); 200 Step 3: When an interface or address, that is currently being used 201 for communication, becomes unavailable the MIF API notifies the 202 application. 204 Step 4: The application requests the MIF API to acquire a list of 205 interfaces that are currently available. Based on locally configured 206 preferences, the application tries to re-connect to its peer from one 207 of the available interfaces. If the connectivity check succeeds, 208 then the application can successfully switch the communication over 209 to this interface. 211 Step 5: If the connectivity check fails, the application needs to 212 redo the check for each of the available interfaces in order of 213 preference until it can successfully connect to its peer. 215 Step 6: If at least one available interface is still able to connect 216 to the peer, the application can switch over to this interface 217 without disrupting communications. 219 6. IANA Considerations 221 This document does not require any IANA actions. 223 7. Security Considerations 225 Some applications may associate the the source address of the 226 communication with the credentials used, it they may require 227 refreshing the credentials after the application switches to using a 228 new source address. 230 8. Acknowledgements 232 The authors would like to thank Pete McCann, Julien Laganier, Dapeng 233 Liu, Dave Thaler, Brian Carpenter and Pierrick Seite for their 234 comments and suggestions for improving this document. 236 9. References 238 9.1. Normative References 240 [I-D.ietf-mif-api-extension] 241 Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API 242 consideration", draft-ietf-mif-api-extension-00 (work in 243 progress), March 2012. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 9.2. Informative References 250 [I-D.tarreau-extend-flow-label-balancing] 251 Carpenter, B., Jiang, S., and W. Tarreau, "Extending Use 252 of the IPv6 Flow Label for Load Balancing Persistence", 253 draft-tarreau-extend-flow-label-balancing-00 (work in 254 progress), June 2012. 256 Authors' Addresses 258 Hui Deng 259 China Mobile 260 No.32 Xuanwumen West Street 261 Xicheng District, 262 Beijing 100053 263 China 265 Email: denghui02@gmail.com 267 Suresh Krishnan 268 Ericsson 269 8400 Blvd Decarie 270 Town of Mount Royal, Quebecy 271 Canada 273 Email: suresh.krishnan@ericsson.com 275 Ted Lemon 276 Nominum 277 Redwood City, 278 94063 279 USA 281 Email: Ted.Lemon@nominum.com 283 Margaret Wasserman 284 Painless Security, LLC 285 356 Abbott Street, 286 North Andover 01845 287 USA 289 Email: mrw@painless-security.com