MIF WG P. Seite Internet-Draft France Telecom - Orange Intended status: Informational JC. Zuniga Expires: March 24, 2013 InterDigital Communications, LLC September 20, 2012 MIF API Conn Mngr Considerations draft-seite-mif-cm-00.txt Abstract 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. 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. 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 March 24, 2013. 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 Seite & Zuniga Expires March 24, 2013 [Page 1] Internet-Draft MIF API Conn Mngr Considerations September 2012 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. MIF API model . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use-case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Functions of the connection manager . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Annex: Interaction of the MIF API with the IEEE 802.21 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Seite & Zuniga Expires March 24, 2013 [Page 2] Internet-Draft MIF API Conn Mngr Considerations September 2012 1. Introduction [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 This document is for discussion and its intention is to help clarifying the utilization of the MIF API in a connection management context. Seite & Zuniga Expires March 24, 2013 [Page 3] Internet-Draft MIF API Conn Mngr Considerations September 2012 2. MIF API model The terminal's API model is depicted below: o MIF API: Provides information as per [I-D.ietf-mif-api-extension]. o Connection Manager: Relies on the MIF API to decide on the mapping between flows and interfaces and configures their operation accordingly, e.g. configuration of the routing table. The decision process relies on information provided by the MIF API as well as by other functions, such as 3GPP/ANDSF [TS23.402] or the OS (via the OS API), providing information which is not in the scope of the MIF API, e.g. battery status. o OS API: Provides the interface to manipulate object configuration, e.g. routing table, virtual interface, etc. o Virtual interface: Hides the multiple interfaces environment to the application. It applies connection management decisions, mapping flows to the appropriate interface. If supported, the connection manager may also request the virtual interface to provide IP flow mobility support [RFC6089], [I-D.ietf-netext-logical-interface-support]. Seite & Zuniga Expires March 24, 2013 [Page 4] Internet-Draft MIF API Conn Mngr Considerations September 2012 +-------------------+ +-------------------+ | policies | | Application | +-------------------+ +-------------------+ /\ || /\ || || || || || || \/ || \/ +---------------------------------+ +-------------------+ | Connection manager | |Communications API | +---------------------------------+ +-------------------+ /\ || /\ || /\ || || || || \/ || || || || +-------------------+ || || || || | MIF API | || || || || +-------------------+ || || || || /\ || || || || \/ || || || \/ +--------------------+ || \/ +-------------------+ +| OS API (Kernel) |--------------------| Virtual Interface |-+ |+--------------------+ Network Link API +-------------------+ | +----------------------------------------------------------------+ /\ || /\ || || \/ || \/ +-------------------+ +--------------------+ | Network Interface | | Network Interface | | 1 | | 2 | +-------------------+ +--------------------+ Figure 1: MIF API framework Seite & Zuniga Expires March 24, 2013 [Page 5] Internet-Draft MIF API Conn Mngr Considerations September 2012 3. Use-case The presented use-case aims to illustrate the behaviour of the MIF API in a concrete situation. The use-case is as follows: 1. Multiple IP communications are running simultaneously; each can be mapped to different interface/provisioning domain at the same time. 2. The connection manager selects the appropriate interface for the application. The connection manager makes a decision according to various criteria; including information provided by the MIF and lower layers APIs as well as selection policies, such as user preferences and/or network operator policies provided by the 3GPP Access Network and Discovery Function (ANDSF) [TS23.402]). 3. The connection manager, together with the terminal's APIs, shall make the applications agnostic about the multiple interfaces management. The interaction between the different APIs is depicted in Figure 2. 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. Seite & Zuniga Expires March 24, 2013 [Page 6] Internet-Draft MIF API Conn Mngr Considerations September 2012 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?|<----------------- | | | | | Figure 2: APIs interaction Operations are as follows: 1. The connection manager subscribes to the MIF API notifications [I-D.ietf-mif-api-extension]. 2. An event, to which the connection manager has subscribed, occurs; e.g. a new interface becomes available or a low radio signal Seite & Zuniga Expires March 24, 2013 [Page 7] Internet-Draft MIF API Conn Mngr Considerations September 2012 level is crossed. 3. The connection manager is notified about the event. 4. In order to take its decision, the connection manager gets some configuration information from the MIF API. 5. The connection manager fetches additional information from the OS API 6. The connection manager decides to move the ongoing IP communication to another interface. 7. 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. To Be Discussed: o Could all the IP configuration objects be provided by the MIF API? The decision of the CM may impact some IP configuration objects (e.g. terminal's routing table, source address, etc.), but the current MIF API does not provide such a service. The CM can proceed via the OS API, but shouldn't the MIF API be the unique API for any manipulation of IP objects? Seite & Zuniga Expires March 24, 2013 [Page 8] Internet-Draft MIF API Conn Mngr Considerations September 2012 4. Functions of the connection manager 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. A connection manager may also rely on different abstraction layers together with the MIF API. The IEEE 802.21 MIH SAP [IEEE802.21] is an example of such an abstraction layer, which can be seen as a partial instantiation of the MIF API. A brief description is provided in the Annex in Section 7. Generic connection manager functions in the MIF API scope are as follows: Subscribe(eventID) 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. Input: identifier of the event to be notified. Some events are defined in [I-D.ietf-mif-api-extension] API: MIF API UnSubscribe(eventID) Description: unregister to a MIF API notification. Input: identifier of event. Some events are defined in [I-D.ietf-mif-api-extension] API: MIF API ListInterfaces() Description: return the list of available interfaces with their characteristics. Interfaces may have different access technologies. Input: n/a Seite & Zuniga Expires March 24, 2013 [Page 9] Internet-Draft MIF API Conn Mngr Considerations September 2012 API: OS API / MIF API ListProvisioningDomains() Description: return the list of available provisioning domains with their characteristics. Input: n/a API: MIF API GetStatus(IID) Description: provide the status of the interface, e.g. enabled/ disabled, active, idle, connection failed, connecting, disconnecting, scanning, unknown state, etc. Input:Interface Identifier API: MIF API IPconnectivityCheck(PID, IP[]) 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). Input: Provisioning domain Identifier, IP addresses to be tested API: MIF API GetConfiguration(IID) Description: retrieve layer 2 configuration information for a given interface. Input: Interface Identifier API: OS API SetConfiguration(IID) Description: configures an interface, e.g. enable/disable, scan, etc. Input: Interface Identifier Seite & Zuniga Expires March 24, 2013 [Page 10] Internet-Draft MIF API Conn Mngr Considerations September 2012 API: OS API GetConfiguration(PID) Description: retrieve configuration information for a given provisioning domain(IP address(es), DNS, default gateway, authentication method, associated interface(s)) Input: Provisioning domain Identifier API: MIF API SetConfiguration(PID) Description: configure provisioning domain information (IP addresse(s), default gateway, authentication method, associated interface, routing table, etc.) Input: Provisioning domain Identifier API: MIF API GetTheoriticalQoS(IID) Description: provide information on the theoretical interface capabilities (e.g. upload/download speed) Input: Interface Identifier API: MIF API GetAvailableQoS(IID) Description: provide information on the quality of communication (Jitter, delay, average upload data rate, average Download data rate, signal strength, etc.) Input: Interface Identifier API: MIF API GetIPtype(IP address) Description: return the type of address and properties (e.g. local, remote, mobile IP anchored, etc.) [I-D.korhonen-dmm-prefix-properties]. Seite & Zuniga Expires March 24, 2013 [Page 11] Internet-Draft MIF API Conn Mngr Considerations September 2012 Input: IP address API: OS API or MIF API? AssociateRouting(RT-TABLE-ID, FlowID) Description: associate a routing table, RT-TABLE-ID, to the IP flow identified by FlowID, e.g. as defined in [RFC6088]. Input: routing table identifier, flow identifier API: OS API or MIF API? SetSourceAddress(IP, FlowID) Description: influence source address selection for a given IP flow. Input: IP source address, flow identifier API: OS API or MIF API? Seite & Zuniga Expires March 24, 2013 [Page 12] Internet-Draft MIF API Conn Mngr Considerations September 2012 5. Security Considerations TBD. Seite & Zuniga Expires March 24, 2013 [Page 13] Internet-Draft MIF API Conn Mngr Considerations September 2012 6. IANA Considerations This document has no actions for IANA. Seite & Zuniga Expires March 24, 2013 [Page 14] Internet-Draft MIF API Conn Mngr Considerations September 2012 7. Annex: Interaction of the MIF API with the IEEE 802.21 Framework Some of the connection management services described in section Section 4 may rely on standardized abstraction layers such as the IEEE 802.21 framework [IEEE802.21]. The IEEE 802.21-2008 Media Independent Handover (MIH) Services specification defines three type of services: Information Services (IS), Event Services (ES) and Command Services (CS). Each one of these services has a different purpose. The IS provides information about existing networks and services in a potential target network. The ES provides triggers, measurements and events from lower layers (e.g. network access layers) that can be used for instance to proactively trigger actions like a handing over or establishing connection to a new network. The CS allows configuring lower layer interfaces and events. Both ES and CS provide an abstraction layer to upper layers that allows configuring and interacting with different types of network link interfaces in a coherent manner. The basics of the 802.21 ES/CS flow are depicted in Figure 3. MIH User MIH Function Link Layer | | | | | | | | | | subcribe.request | | |------------------->|----------->| | subcribe.confirm | | |<-------------------|<-----------| | | | | | | | | event occurs | event.notif | | |<-------------------|<-----------| | | | | command.request | | |------------------->|----------->| | | Link command | command.confirm | Execution |<-------------------|<-----------| | | | Figure 3: IEEE 802.21 event and command services flow An MIH user may use the following IEEE 802.21 events and commands to Seite & Zuniga Expires March 24, 2013 [Page 15] Internet-Draft MIF API Conn Mngr Considerations September 2012 complete connection management operations: Link_Event_Subscribe Category: command Description: Subscribe to one or more events from a link. Link_Event_Unsubscribe Category: command Description: Unsubscribe from a set of link-layer events. Link_Parameters_Report Category: Event Description: Link parameters have crossed a specified threshold and need to be reported. Link_Get_Parameters Category: command Description: Get parameters measured by the active link, such as signal-to-noise ratio (SNR), BER, received signal strength indication (RSSI). Link_Detected Category: Event Description: Link of a new access network has been detected. Link_Up Category: Event Description: L2 connection is established and link is available for use. Link_Down Category: Event Description: L2 connection is broken and link is not available for use. Seite & Zuniga Expires March 24, 2013 [Page 16] Internet-Draft MIF API Conn Mngr Considerations September 2012 Link_Going_Down Category: Event Description: Radio link conditions are degrading and connection loss is very likely. Link_Handover_Imminent Category: Event Description: L2 handover is imminent based on either the changes in the link conditions or additional information available at layer 2. Link_Handover_Complete Category: Event Description: L2 handover has been completed. Link_PDU_Transmit_Status Category: Event Description: indicate transmission status of a PDU. Link_Capability_Discover Category: command Description: Query and discover the list of supported link-layer events and link-layer commands. Link_Configuration_Thresholds Category: command Description: Configure thresholds for future Link Parameters Report events. Link_Action Category: command Description: request an action on a link-layer connection, e.g. perform a scan, shut down an interface, etc. Seite & Zuniga Expires March 24, 2013 [Page 17] Internet-Draft MIF API Conn Mngr Considerations September 2012 Handover_Query Category: command Description: query and obtain handover related information about possible candidate networks. Handover_Commit Category: command Description: notify the MIH function of the decided target network. Handover_Complete Category: command Description: indicate the status of the handover completion to the MIH function. Seite & Zuniga Expires March 24, 2013 [Page 18] Internet-Draft MIF API Conn Mngr Considerations September 2012 8. Acknowledgements 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. Seite & Zuniga Expires March 24, 2013 [Page 19] Internet-Draft MIF API Conn Mngr Considerations September 2012 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. 9.2. Informative References [I-D.deng-mif-api-session-continuity-guide] Deng, H., Krishnan, S., Lemon, T., and M. Wasserman, "Guide for application developers on session continuity by using MIF API", draft-deng-mif-api-session-continuity-guide-02 (work in progress), July 2012. [I-D.ietf-mif-api-extension] Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API consideration", draft-ietf-mif-api-extension-01 (work in progress), July 2012. [I-D.ietf-netext-logical-interface-support] Melia, T. and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", draft-ietf-netext-logical-interface-support-05 (work in progress), April 2012. [I-D.korhonen-dmm-prefix-properties] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Mobility Management Properties", draft-korhonen-dmm-prefix-properties-02 (work in progress), July 2012. [IEEE802.21] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, January 2009.", 2009, < http ://www.ieee802.org/21/private/Published%20Spec/ 802.21-2008.pdf>. Seite & Zuniga Expires March 24, 2013 [Page 20] Internet-Draft MIF API Conn Mngr Considerations September 2012 [TS23.402] 3GPP, "3GPP TS 23.402; Architecture enhancements for non- 3GPP accesses", 2010. Seite & Zuniga Expires March 24, 2013 [Page 21] Internet-Draft MIF API Conn Mngr Considerations September 2012 Authors' Addresses Pierrick Seite France Telecom - Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange.com Juan Carlos Zuniga InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada Email: JuanCarlos.Zuniga@InterDigital.com Seite & Zuniga Expires March 24, 2013 [Page 22]