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

MIF WG                                                           H. Deng
Internet-Draft                                              China Mobile
Intended status: Informational                               S. Krishnan
Expires: January 17, 2013                                       Ericsson
                                                                T. Lemon
                                                                 Nominum
                                                            M. Wasserman
                                                  Painless Security, LLC
                                                           July 16, 2012

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

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 17, 2013.

Deng, et al.            Expires January 17, 2013                [Page 1]
Internet-Draft         MIF API Session Continuity              July 2012

Copyright Notice

   Copyright (c) 2012 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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   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

Deng, et al.            Expires January 17, 2013                [Page 2]
Internet-Draft         MIF API Session Continuity              July 2012

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.

   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.

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).  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

Deng, et al.            Expires January 17, 2013                [Page 3]
Internet-Draft         MIF API Session Continuity              July 2012

   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
   its peer based on MIF API notification about new interface(s) and/or
   new address(es).

   It is 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 connects to the server based on interface 1
   (either 3G/LTE or WLAN);

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

   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..

   Step 5: The interface initially used for communication may now be
   turned off without disrupting communications.

Deng, et al.            Expires January 17, 2013                [Page 4]
Internet-Draft         MIF API Session Continuity              July 2012

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 connects to the server based on interface 1
   (either 3G/LTE or WLAN);

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

   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

Deng, et al.            Expires January 17, 2013                [Page 5]
Internet-Draft         MIF API Session Continuity              July 2012

   Liu and Dave Thaler for their comments and suggestions for improving
   this document.

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-00 (work in
              progress), March 2012.

   [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 17, 2013                [Page 6]
Internet-Draft         MIF API Session Continuity              July 2012

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

   Email: mrw@painless-security.com

Deng, et al.            Expires January 17, 2013                [Page 7]