<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="info" ipr="trust200902" docName="draft-seite-mif-cm-02.txt">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="no" ?>
  <front>
    <title>MIF API for Connection Management</title>   
    <author initials="P." surname="Seite" fullname="Pierrick Seite">
      <organization>Orange</organization>
      <address>
        <postal>
          <street>4, rue du Clos Courtel, BP 91226</street>
          <city>Cesson-Sevigne</city>
          <code>35512</code>
          <country>France</country>
        </postal>
        <email>pierrick.seite@orange.com</email>
       </address>
    </author>
	<author initials="JC." surname="Zuniga" fullname="Juan Carlos Zuniga">
      <organization>InterDigital Communications, LLC</organization>
      <address>
        <postal>
          <street>1000 Sherbrooke Street West, 10th floor</street>
          <city>Montreal, Quebec</city>
          <code>H3A 3G4</code>
          <country>Canada</country>
        </postal>
        <email>JuanCarlos.Zuniga@InterDigital.com</email>
       </address>
    </author>
    <date month="August" year="2013"/>

    <area>IETF</area>

    <workgroup>MIF WG</workgroup>

    <keyword>MIF API</keyword>

    <keyword>connection manager</keyword>

    <abstract>
      <t>
       	      There is currently a need to present a coherent connection management behaviour for different terminal 
	      platforms (e.g. mobile phones, PCs, tablets, etc.). This document discusses how a connection manager 
	      can use the MIF API to provide this coherent behaviour and enhance the end user's experience when a 
	      terminal is able to connect to multiple interfaces. The goal of this document is not to define a 
	      connection manager specification, but to focus on the interaction with the MIF API and suggest relevant 
	      generic messages for the interface.
      </t>
      <t>
	      This document is for discussion and its intention is to help clarifying the utilization 
	      of the MIF API in a connection management context and propose some relevant considerations.
      </t>
    </abstract>
  </front>
  <middle>
    
    
       
   <section title="Introduction">
    
    <t>
	    <xref target="I-D.ietf-mif-api-extension"/> describes an abstract API that provides commands and services 
	    for applications and higher layer APIs running on a terminal with more than one interface. There is currently 
	    a need to present a coherent connection management behaviour for different terminal platforms (e.g. mobile 
	    phones, PCs, tablets, etc.), as users often experience a very different behaviour when connecting with 
	    various platforms to the same networks and for the same purposes (e.g. web browsing, email access, dedicated 
	    applications, etc.). This document builds on top of the MIF API and aims to discuss how connection managers 
	    can use the MIF API to provide a coherent and constant behaviour to the users. The goal of this document is not 
	    to define a connection manager specification, but to focus on the interaction with the MIF API and suggest 
	    relevant generic messages for the interface.
	</t>
    <t>
	    This document is only for discussion; its intention is to help clarifying the utilization 
	    of the MIF API in a connection management context.
	</t>
    </section>
	
	
    
    <section title = "Architecture of a MIF terminal">
	<t>
	The terminal's MIF API based architecture is an instantiation of the MIF API model described in <xref target="I-D.ietf-mif-api-extension"/>; main functions and APIs are described below:
	<list style='symbols'>
		<t>MIF API: it provides information as per <xref target="I-D.ietf-mif-api-extension"/>.</t>
		<t>Connection Manager: it is an application relying on the MIF API; this application acts on behalf of other runing applications. The connection manager decides about the mapping between IP flows and 
			interfaces, then configures the IP stack, and lower layers, accordingly, e.g. configuration of the routing 
			table. The connection manager relies on information provided either by the MIF API or the OS API. Only interface with the MIF API is in 
			the scope of this document.</t>
		<t>OS API: Provides the interface to manipulate IP object configuration, e.g. routing table. </t>
		
	</list>
	<figure anchor="fig.API" title="MIF API framework">
	  <artwork align="center">
	  	  <![CDATA[ 

  +------------------------------+   +------------------------------+
  |        Connection manager    |   |          Application         |
  +------------------------------+   +------------------------------+
        /\  ||           /\  ||        /\  ||          ||  ||
        ||  ||           ||  \/        ||  ||          ||  \/
        ||  ||       +------------------------+ +-------------------+
        ||  ||       |          MIF API       | |Communications API |
        ||  ||       +------------------------+ +-------------------+
        ||  ||                  /\  ||                 /\  ||
        ||  \/                  ||  ||                 ||  ||
   +--------------------+       ||  \/                 ||  \/
  +|   OS API (Kernel)  |-----------------------------------------+
  |+--------------------+  Network Link API                       |
  +---------------------------------------------------------------+
          /\  ||                               /\  ||
          ||  \/                               ||  \/
  +-------------------+                +--------------------+
  | Network Interface |                | Network Interface  |
  |         1         |                |          2         |
  +-------------------+                +--------------------+

					]]>  
      </artwork>
	  </figure>
	 </t> 



    </section>

    
    <section title = "Use-case">
	<t>
		The presented use-case aims to illustrate the behaviour of the MIF API in a concrete situation. 
		The use-case is as follows:
	<list style='numbers'>
		<t> 
			Multiple IP communications are running simultaneously; each can be mapped to different 
			interfaces/provisioning domains. 
		</t>
		<t>
			The connection manager selects the appropriate interface/provisioning domain for the application; making a decision according to various criteria (information provided by the 
			MIF and lower layers APIs, user preferences, and so on). 
		</t>
		
	</list>


	 
	The interaction between the different APIs is depicted in <xref target="fig.callflow"/>. It is assumed that at least one IP 
	communication is running. Then, an interface event occurs and the connection manager decides to move the 
	communication to a different interface.
	 
	<figure anchor="fig.callflow" title="APIs interaction">
	  <artwork align="center">
	  	  <![CDATA[ 
 
  Connection Manager     MIF API         Network Link API   OS API
        |                   |                    |            |
        |announce.subscribe |                                 |
   (1)  |------------------>|                    |            |
        |                   | subcribe.request   |            |
        |                   |------------------->|            |
        |                   |  subcribe.confirm  |            |
        |  subscr.confirm   |<-------------------|            |
        |<------------------|                    |            |
        |                   |                    |            |
  (2)   |                   |                event occurs     |
        | event.announce    |    event.notif     |            |
  (3)   |<----------------- |<------------------ |            |
        |                   |                    |            |
        | config.get[PID]   |                    |            |
  (4)   |------------------>|------------------->|            |
        |    config.resp    |                    |            |
        |<----------------- |<-------------------|            |
        |                   | config-object.get  |            |
  (5?)  |---------------------------------------------------->|
        |                   | config-object.resp |            |
        |<----------------------------------------------------|
  (6) decision made         |                    |            |
        |                   | request.config     |            |
  (7)   |---------------------------------------------------->|
        |                   | config.resp        |            |
        |<----------------------------------------------------|
        |    request.config |                    |            |
  or    |------------------>|                    |            |
        |                   |------------------->|            |
  (8)   |                   |<------------------ |            |
        |                   |-------------------------------->|
 both   |   config.resp     |<--------------------------------|
7 and 8?|<----------------- |                                 |
        |                   |                                 |
  
						
						]]>  
      </artwork>
	  </figure>
	  Operations are as follows:
	 <list style='numbers'>
			<t>The connection manager subscribes to the MIF API notifications <xref target="I-D.ietf-mif-api-extension"/>.</t>
			<t>An event, to which the connection manager has subscribed, occurs; e.g. a new interface becomes 
				available or a low radio signal level is crossed.</t>
			<t>The connection manager is notified about the event.</t>
			<t>In order to take its decision, the connection manager gets some configuration information from the 
				MIF API.</t>
			<t>The connection manager fetches additional information from the OS API</t>
			<t>The connection manager decides to move the ongoing IP communication to another interface.</t>
			<t>The connection manager requests the OS API to reconfigure one or multiple interfaces according to the decision; 
				for example, the connection manager could request reconfiguration of the routing table or trigger 
				a MIP operation.</t>
	</list>
	 </t>
	<t>
	 
	
	</t>	



	
     </section>


    <section anchor="sct.fct" title = "Functions of the connection manager">
	<t>
	This section focuses on the interactions between the connection manager and the MIF API and OS API. The interactions 
	between the connection manager and other complementary APIs, like user preferences and/or ANDSF network operator policies 
	are out of the scope of this document.
	</t>
	<t>
	A connection manager may also rely on different abstraction layers together with the MIF API. The IEEE 802.21 MIH 
	SAP <xref target="IEEE802.21"/> is an example of such an abstraction layer, which can be seen as a partial instantiation 
	of the MIF API. A companion document <xref target="I-D.zuniga-mif-802-21-overview"/> adresses interaction between IEEE 802.21 and MIF API. 
	</t>
			
	<t>
	Generic connection manager functions and their relation to the MIF API are described below. The following assumes the MIF API is the unique API for any manipulation of IP objects. However, current MIF API allows to gather information from the IP stack but not to configure it. As a consequence three functions are added to the MIF API: GetIPtype(), ConfigFlowRouting() and SetSourceAddress().
	</t>
	<t>Subscribe(eventID)
		<list style='empty'>
			<t>Description: register for a MIF API event notification, e.g. WLAN scan results ready, 
			WLAN connected, WLAN disconnected, interface is going to be disconnected detected (e.g. because of low radio signal level detected), 
			Cellular connected, Cellular disconnected, etc. </t>
			<t>Input: identifier of the event to be notified. Some events are defined in <xref target="I-D.ietf-mif-api-extension"/></t>
			<t>API: MIF API</t>
		</list>
	</t>	
	<t>UnSubscribe(eventID)
		<list style='empty'>
			<t>Description: unregister to a MIF API notification. </t>
			<t>Input: identifier of event. Some events are defined in <xref target="I-D.ietf-mif-api-extension"/></t>
			<t>API: MIF API</t>
		</list>
	</t>	
	<t>ListInterfaces()
		
		<list style='empty'>
			<t>Description: return the list of available interfaces with their characteristics. Interfaces may have different access technologies. </t>
			<t>Input: n/a</t>
			<t>API: MIF API</t>
		</list>
	</t>
	<t>ListProvisioningDomains()
		
		<list style='empty'>
			<t>Description: return the list of available provisioning domains with their characteristics. </t>
			<t>Input: n/a</t>
			<t>API: MIF API</t>
		</list>
	</t>
	<t>GetStatus(IID)
			<list style='empty'>
			<t>Description: provide the status of the interface, e.g. enabled/disabled, active, 
			idle, connection failed, connecting, disconnecting, scanning, unknown state, etc.</t>
			<t>Input:Interface Identifier </t>
			<t>API: MIF API</t>
		</list>
	</t>
	
	<t>IPconnectivityCheck(PID, IP[])
			<list style='empty'>
			<t>Description: check IP connectivity to the intranet/Internet: the interface may have a valid IP 
			address but no IP connectivity to data networks (e.g. web based authentication through a captive portal). </t>
			<t>Input: Provisioning domain Identifier, IP addresses to be tested</t>
			<t>API: MIF API</t>
		</list>
	</t>
	
	<t>GetConfiguration(IID)
			<list style='empty'>
			<t>Description: retrieve layer 2 configuration information for a given interface. </t>
			<t>Input: Interface Identifier </t>
			<t>API: OS API</t>
		</list>
	</t>

	<t>SetConfiguration(IID)
			<list style='empty'>
				<t>Description: configures an interface, e.g. enable/disable, scan, etc.</t>
			<t>Input: Interface Identifier </t>
			<t>API: OS API</t>
		</list>
	</t>

	<t>GetConfiguration(PID)
			<list style='empty'>
			<t>Description: retrieve configuration information for a given provisioning domain(IP address(es), DNS, 
			default gateway, authentication method, associated interface(s)) </t>
			<t>Input: Provisioning domain Identifier </t>
			<t>API: MIF API</t>
		</list>
	</t>
	
	<t>SetConfiguration(PID)
			<list style='empty'>
			<t>Description: configure provisioning domain information (IP addresse(s), default gateway, authentication method, associated interface, routing table, etc.)</t>
			<t>Input: Provisioning domain Identifier </t>
			<t>API: MIF API</t>
		</list>
	</t>

	<t>GetTheoriticalQoS(IID)
			<list style='empty'>
			<t>Description: provide information on the theoretical interface capabilities (e.g. upload/download speed)</t>
			<t>Input: Interface Identifier</t>
			<t>API: MIF API</t>
		</list>
	</t>
	
	<t>GetAvailableQoS(IID)
			<list style='empty'>
			<t>Description: provide information on the quality of communication (Jitter, delay, average upload data rate, average Download data rate, signal strength, etc.)</t>
			<t>Input: Interface Identifier </t>
			<t>API: MIF API</t>
		</list>
	</t>
	
	<t>GetIPtype(IP address)
			<list style='empty'>
			<t>Description: return the type of address and properties (e.g. local, remote, mobile IP anchored, etc.). This function is to be added to the MIF API as per <xref target="I-D.ietf-mif-api-extension"/>. 
			<xref target="I-D.korhonen-dmm-prefix-properties"/>. </t>
			<t>Input: IP address </t>
			<t>API: updated MIF API</t>
		</list>
	</t>
	
	<t>ConfigFlowRouting(ROUTE, FlowID)
			<list style='empty'>
			<t>Description: associate a route, ROUTE, to the IP flow identified by FlowID, e.g. as defined 
			in <xref target="RFC6088"/>. This function is to be added to the MIF API as per <xref target="I-D.ietf-mif-api-extension"/>. </t>
			<t>Input: routing table identifier, flow identifier </t>
			<t>API: updated MIF API</t>
		</list>
	</t>
	
	<t>SetSourceAddress(IP, FlowID)
			<list style='empty'>
			<t>Description: influence source address selection for a given IP flow. This function is to be added to the MIF API as per <xref target="I-D.ietf-mif-api-extension"/>. </t>
			<t>Input: IP source address, flow identifier </t>
			<t>API: updated MIF API</t>
		</list>
	</t>
</section>


<section title="Security Considerations">
      <t>
       TBD.
      </t>
    </section>
	
    
<section title="IANA Considerations">
      <t>
        This document has no actions for IANA.
      </t>
    </section>
	

<section title="Acknowledgements">
      <t>
	      The authors would like to express their gratitude to Ralph Droms, Ted Lemon and Dave Thaler for the fruitful discussions 
	      regarding MIF API and connection managers. 
      </t>
    </section>
  </middle>
  <back>


	<references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
	  <?rfc include="reference.RFC.6088" ?>
	  <?rfc include="reference.RFC.6089" ?>
    </references>    
    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-mif-api-extension" ?>
	  <?rfc include="reference.I-D.deng-mif-api-session-continuity-guide" ?>
	  <?rfc include="reference.I-D.ietf-netext-logical-interface-support" ?>
	  <?rfc include="reference.I-D.korhonen-dmm-prefix-properties" ?>
	  <?rfc include="reference.I-D.zuniga-mif-802-21-overview" ?>
	 
	  <reference anchor="IEEE802.21"
                 target=" http://www.ieee802.org/21/private/Published%20Spec/802.21-2008.pdf">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks - Part
          21: Media Independent Handover Services", IEEE LAN/MAN Std
          802.21-2008, January 2009.</title>
          <author>
            <organization>IEEE</organization>
          </author>
      <date year="2009" />
        </front>
      </reference>
	  
    </references>

  </back>

</rfc>
