[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04                                                
MIF WG                                                           H. Deng
Internet-Draft                                              China Mobile
Intended status: Informational                               S. Krishnan
Expires: January 2, 2015                                        Ericsson
                                                                T. Lemon
                                                                 Nominum
                                                            M. Wasserman
                                                  Painless Security, LLC
                                                            July 1, 2014


Guide for application developers on session continuity by using MIF API
             draft-deng-mif-api-session-continuity-guide-04

Abstract

   Today most smart terminals are equiped with multiple interfaces such
   as 3G/LTE and WiFi, and users experience some loss of connectivity
   while switching interfaces.  The MIF API draft
   [I-D.ietf-mif-api-extension] has specified an API to announce
   interface status information to the applications.  Once the
   application receives such information, it can use this information
   reconnect to its peer(s), and this could significantly improve the
   user experience.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 2, 2015.




Deng, et al.             Expires January 2, 2015                [Page 1]


Internet-Draft         MIF API Session Continuity              July 2014


Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Related MIF API information . . . . . . . . . . . . . . . . .   3
   3.  Using different source address to reconnect the server  . . .   3
   4.  Generic guidelines for writing applications to handle new
       interfaces becoming available . . . . . . . . . . . . . . . .   4
   5.  Generic guidelines for writing applications to handle
       interfaces becoming unavailable . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   A significant and increasing number of smart mobile terminals have
   multiple interfaces for connectivity (e.g.  Wifi and 3G/LTE).  These
   interfaces may have very characteristics in terms of reliability,
   available bandwidth, delay/jitter as well as cost per bit.  There is
   some form of connection manager on the end device that picks an
   interface for communication based on some pre-configured policy and/
   or based on dynamic conditions.  The initially selected interface may
   become deprioritized (e.g. due to a lower cost interface becoming
   available) or may become unavailable (e.g. due to loss of coverage
   when moving out of a WiFi hotspot).  New interfaces may become
   available due to administrative action (e.g. manual activation of a
   specific connectivity technology) or due to dynamic conditions (e.g.
   entering coverage area of a wireless network or plugging in an
   ethernet cable).  In order to handle such changes in connectivity,
   applications need to be aware of network status changes and react to
   them.  This document provides a guide to writing such applications.



Deng, et al.             Expires January 2, 2015                [Page 2]


Internet-Draft         MIF API Session Continuity              July 2014


   The MIF API [I-D.ietf-mif-api-extension] document specifies an API
   that is capable of providing information regarding changes in network
   and interface connectivity status.  By using this information,
   application developers can develop applications that can survive
   changes in connectivity and even benefit from them.

   The MIF MPVD Architecture [I-D.ietf-mif-mpvd-arch] document defines
   the notion of a PVD (set of network configuration information), and
   PVDs somehow must be exposed, in case applications are not PVD-
   awared, or indirectly participating the selection of PVD, or knowing
   of the PVDs based on PVD APIs.  The MIF API
   [I-D.ietf-mif-api-extension] document specifies "Connect to PVD"
   message, application developers may develop appliation that can
   changes between different PVD connectivity.

2.  Related MIF API information

   MIF API draft [I-D.ietf-mif-api-extension] defines a few messages
   that are related to notifying whether an interface is available or
   not.  The messages are defined in Section 3.5.1 (Announce Interfaces)
   and Section 3.5.4 (No Inteface).  Similar functionaility is available
   for addresses using the messages defined in Section 3.5.12 (Announce
   Address) and Section 3.5.14 (No Address Announcement).  The API also
   specifies interface change information in section 3.5.23.5 (Interface
   is going up) and 3.5.23.4 (Interface is going away).  Both interface
   and address information could be used by the application to infer the
   availablility of a new endpoint for communication or the loss of an
   existing endpoint for communication.

3.  Using different source address to reconnect the server

   The applications deployed on mobile hosts usually setup the
   connection with the server, then trying to keep the connection up as
   long as they can.  This works reasonable well when the host has only
   one communication interface.  Once the host has more than one
   communication interface, such as 3G/LTE and WLAN, such applications
   cease to work well. e.g.  The per bit cost and the connection speed
   are different on these two interfaces, and the user would always
   prefer to change another cheaper and faster connection. e.g.  While
   connecting to a WLAN interface after being connected to LTE, the
   mobile terminal would get a different set of configuration parameters
   including the IP address, DNS server and default gateway.
   Application would normally break after such change in connectivity if
   the original interface (3G/LTE) is turned off and manual intervention
   is usually required to reinitiate connectivity.

   If the application is designed with changing network connectivity in
   mind, then the application could be carefully designed reconnect to



Deng, et al.             Expires January 2, 2015                [Page 3]


Internet-Draft         MIF API Session Continuity              July 2014


   its peer based on MIF API notification about new interface(s) and/or
   new address(es).  The application needs to start testing the
   usability of the new interface(s)/address(es) immediately and
   determine whether they are usable and, if so, decide what traffic to
   switch over.  Please note that there are other solutions for handling
   address changes in the lower layers (network and transport) like
   MIPv6, shim6, and MPTCP that can shield the application from address
   changes.  The guidelines provided in this document are also
   applicable when these techniques are being used.  Also, there might
   be load balancers present on the server side and it may become very
   difficult to preserve sessions after an address change has occurred.

   In most cases even when a mobile terminal gets WLAN connectivity and
   gets an IP address assgined, but it could still be disconnected from
   the Internet due to lack of authentication.  As a consequence, the
   interface needs to be tested for internet connectivity before
   switching communication from an existing interface to a newly
   available interface.

4.  Generic guidelines for writing applications to handle new interfaces
    becoming available

   The recommended steps for the application developer to keep the
   session continuity based on MIF API are listed below:

   Step 1: Application subscribes to the MIF API for interface and
   address change notifications;

   Step 2: Application connects to the server based on interface 1
   (either 3G/LTE or WLAN);

   Step 3: When a new interface comes up or a new address is configured,
   the MIF API notifies the application.

   Step 4: The application tries to re-connect to its peer from the
   newly available interface.  If the connectivity check succeeds, then
   the application can successfully switch the communication over to the
   new interface based on policy or user initiated selection.  Otherwise
   communication stays on the existing inteface.  The decision process
   on how a preferred interface is selected is out of scope of this
   document and might be the topic for a separate high level API
   document.

   Step 5: The interface initially used for communication may now be
   turned off without disrupting communications if no other applications
   are using it.





Deng, et al.             Expires January 2, 2015                [Page 4]


Internet-Draft         MIF API Session Continuity              July 2014


5.  Generic guidelines for writing applications to handle interfaces
    becoming unavailable

   The recommended steps for the application developer to keep the
   session continuity based on MIF API are listed below:

   Step 1: Application subscribes to the MIF API for interface and
   address change notifications;

   Step 2: Application connects to the server based on interface 1
   (either 3G/LTE or WLAN);

   Step 3: When an interface or address, that is currently being used
   for communication, becomes unavailable the MIF API notifies the
   application.

   Step 4: The application requests the MIF API to acquire a list of
   interfaces that are currently available.  Based on locally configured
   preferences, the application tries to re-connect to its peer from one
   of the available interfaces.  If the connectivity check succeeds,
   then the application can successfully switch the communication over
   to this interface.

   Step 5: If the connectivity check fails, the application needs to
   redo the check for each of the available interfaces in order of
   preference until it can successfully connect to its peer.

   Step 6: If at least one available interface is still able to connect
   to the peer, the application can switch over to this interface
   without disrupting communications.

6.  IANA Considerations

   This document does not require any IANA actions.

7.  Security Considerations

   Some applications may associate the the source address of the
   communication with the credentials used, it they may require
   refreshing the credentials after the application switches to using a
   new source address.

8.  Acknowledgements

   The authors would like to thank Pete McCann, Julien Laganier, Dapeng
   Liu, Dave Thaler, Brian Carpenter and Pierrick Seite for their
   comments and suggestions for improving this document.




Deng, et al.             Expires January 2, 2015                [Page 5]


Internet-Draft         MIF API Session Continuity              July 2014


9.  Normative References

   [I-D.ietf-mif-api-extension]
              Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API
              consideration", draft-ietf-mif-api-extension-05 (work in
              progress), February 2014.

   [I-D.ietf-mif-mpvd-arch]
              Anipko, D., "MIF MPVD Architecture", draft-ietf-mif-mpvd-
              arch-01 (work in progress), May 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   Hui Deng
   China Mobile
   No.32 Xuanwumen West Street
   Xicheng District,
   Beijing  100053
   China

   Email: denghui02@gmail.com


   Suresh Krishnan
   Ericsson
   8400 Blvd Decarie
   Town of Mount Royal, Quebecy
   Canada

   Email: suresh.krishnan@ericsson.com


   Ted Lemon
   Nominum
   Redwood City,
   94063
   USA

   Email: Ted.Lemon@nominum.com









Deng, et al.             Expires January 2, 2015                [Page 6]


Internet-Draft         MIF API Session Continuity              July 2014


   Margaret Wasserman
   Painless Security, LLC
   356 Abbott Street,
   North Andover  01845
   USA

   Email: mrw@painless-security.com












































Deng, et al.             Expires January 2, 2015                [Page 7]