Network Working Group D. Liu Internet-Draft China Mobile Intended status: Informational Ted. Lemon Expires: January 12, 2012 Nominum Yuri. Ismailov Ericsson Z. Cao China Mobile July 11, 2011 MIF API consideration draft-liu-mif-api-extension-05 Abstract API (Application Program Interface) is an interface implemented by a software program that enables it to interact with other software. In IP network communication area, Socket API is the de facto standard and is widely used in many systems. Recently, multiple interfaces or multiple connection capable devices become more and more common. But due to the limitation of the default route of the host and other issues such as DNS selection etc prevent the utilization of multiple interfaces/connections benefit. Moreover, there is no API level support for the application developer to utilize the benefit of the host's multiple interfaces/connections. Starting with the requirement of MIF API extension, this document describes a new set of abstraction APIs to provide additional services to applications running on hosts attached to multiple provisioning domains. These services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues. 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 12, 2012. Liu, et al. Expires January 12, 2012 [Page 1] Internet-Draft MIF API Extension July 2011 Copyright Notice Copyright (c) 2011 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. Conventions used in this document . . . . . . . . . . . . . . . 3 3. MIF API Concept . . . . . . . . . . . . . . . . . . . . . . . . 3 4. MIF API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. MIF API Requirement . . . . . . . . . . . . . . . . . . . . 4 4.2. MIF API definition consideration . . . . . . . . . . . . . 5 5. Using the extended APIs . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Liu, et al. Expires January 12, 2012 [Page 2] Internet-Draft MIF API Extension July 2011 1. Introduction API is an software interface which is used to interact with other softwares. In IP network area, Socket API is widely used in many operating systems. Socket API has been extended according to the evolution of TCP/IP protocol stack. For example, Socket API was extended to support IPv6 in RFC 3493 [RFC3493] and RFC 3542 [RFC3542] also define advanced sokets for IPv6. Nowadays, there are more and more devices that have the ability to attach to multiple provisioning domains. Due to the limitation of Socket API and other issues such as default route and DNS selection, the application can not directly control the multiple interfaces/connection capability of the devices. This document describes a new set of abstraction API to provide additional services to applications running on hosts attached to multiple provisioning domains. These services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues. 2. Conventions used in this document 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]. 3. MIF API Concept Figure 1 demostrates the MIF API concept. MIF API could be extended based on current Socket API or could be implemented by new function calls. The MIF API that defined in this document is an abstract API which describes the abstract function and not depend on any specific platform. In MIF problem statement document [I-D:MIF-problem statement],there are two issues caused by lack of advanced MIF API: 1.Source address or address selection policies could be specified by applications. However, there is no advanced APIs to allow applications realizing such operations. 2.Some implementations, specially in the mobile world, have higher- level API and/or session manager (aka connection manager) to address MIF issues. These mechanisms are not standardized and do not necessarily behave the same way across different OS, and/or platforms, in the presence of the MIF problems. This lack of Liu, et al. Expires January 12, 2012 [Page 3] Internet-Draft MIF API Extension July 2011 consistency is an issue for user and operator who could experience different session manager behaviors depending on the terminal. To solve the above metioned problem and other MIF problems, this document first analysis existing API that could be used to solve MIF problems, then this document tries to give recommendations. It should be noted that this doucment is intend as informational only. +-------------------------------------+ | Application | +-------------------------------------+ ^ ^ ^ ~~~~~~~|Socket Interface~~~~MIF |API~~~~~ | | | +------|----------|-------------v-----+ | V TCP/UDP | +-----------------|-------------------+ | +-------------------------------------+ | IP | +-------------------------------------+ | Physical Interface | | +----+ +-----+ +-----+ +----+ | | |IF#1| |IF#2 | |IF#3 | |IF#4| | | +----+ +-----+ +-----+ +----+ | +-------------------------------------+ Figure 1. MIF API Concept Figure 1 4. MIF API This section discusses the possible ways to design the MIF API. There are works in IETF relatd to socket API extensions,such as: IPv6 socket API extension, HIP socket API extension, shim6 socket API extensions. This section gives initial proposals regarding to how this MIF Socket APIs should be designed. 4.1. MIF API Requirement R1: Compatible with existing Socket APIs The extension of Socket APIs should remain compatible with current Liu, et al. Expires January 12, 2012 [Page 4] Internet-Draft MIF API Extension July 2011 existing Socket APIs which means this extension will not affect the existing application and the application developer can chose whether to use this extension or not. R2: Support for multiple Connections The newly introduced APIs can support the host applications to utilize multiple connections. If some connections fail to work, applications can failover to other available interfaces. R3: No Changes to Existing Socket APIs The newly introduced APIs cannot change the behavior of existing network APIs available on the host operating system. R4: Easy for Implementation The implementation details for the newly introduced APIs should be as neat as possible. It keeps the underlying implementation details simple, and makes the application developers easy to use these APIs. 4.2. MIF API definition consideration This section gives the definition and description of MIF API. 1. Address Selection API consideration MIF host may has multiple IP addresses. for example, different interface may have different IP addresses been configured. Further more, some protocols, for example: mobile IP protocol may assign home address to the host. Application need to control which IP address it want to use. There are multiple ways of existing mechanism that could be used for source address selection: bind() socket function could be used for application to specify source address. The bind() function has the following definition: int bind(int sockfd, struct sockaddr *my_addr, int addrlen) parameter my_addr is used to specify the soure IP address the application want to use. RFC 3484 [RFC 3484] specifies the default address selection rule for IPv6. It defines a common algorithms, used for the IPv6 application to select source and destination addresses. It also defines the rules used for selecting IPv4 or IPv6 source address for dual-stack Liu, et al. Expires January 12, 2012 [Page 5] Internet-Draft MIF API Extension July 2011 host. Further more, RFC 3484 [RFC 3484] specifies policy hooks to allow administrative override of the default address selection rules. But the policy table takes effect for all the applications and individual application can not control the source address it prefer to use separately. RFC 3542 [RFC 3542] defines advanced socket API for IPv6. It uses ancillary data to specify various options in IPv6 header, including source IP address. From the above analysis, we can see that there are multiple API that could be used for the application to specify the source address. Due to the multiple choices, it will result in difficulty and complexity for the application developer to deal with the MIF problem. The MIF working group shoud take this into consideration and decide whether to specify a unified MIF API for source address selection. 2. Interface selection API RFC 3542 [RFC 3542] specifies API for interface selection. This API works for IPv6 only. Besides that, It is usually difficult for application developer to select the proper interface, because the application developer usually does not have the proper criteria for network selection. For mobile device, the interface selection policy could provided by the operator through session manager in the mobile device. Therefore, it is preferred to have a MIF API to select the proper interface based on policy. 3. Notification API Sometimes, application need to know physical interfaces changing event. Application or session manager may relay on the notification message to do corresponding handling. for example, after notified that a Wi-Fi interface is going up, the application or session manager could re-establish the session using Wi-Fi interface and thence offload the traffic to Wi-Fi. 4. DNS Selection API TBD 5. Using the extended APIs To enjoy the benefit of multiple interfaces, the developers can write programs according to the APIs introduced in this document. Detail Liu, et al. Expires January 12, 2012 [Page 6] Internet-Draft MIF API Extension July 2011 example need to be further specified. 6. Security Considerations TBD 7. IANA Considerations None 8. Acknowledgments The authors want to thank Teemu Savolainen from Nokia, Dayi Zhao from Bitway and others for their useful suggestions and discussions. 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. 9.2. Informative References [I-D.scharf-mptcp-api] Scharf, M. and A. Ford, "MPTCP Application Interface Considerations", draft-scharf-mptcp-api-02 (work in progress), July 2010. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. Authors' Addresses Dapeng Liu China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: liudapeng@chinamobile.com Liu, et al. Expires January 12, 2012 [Page 7] Internet-Draft MIF API Extension July 2011 Ted Lemon Nominum Redwood City CA 94063 USA Email: Ted.Lemon@nominum.com Yuri Ismailov Ericsson Stockholm Sweden Email: yuri@ismailov.eu Zhen Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: caozhen@chinamobile.com Liu, et al. Expires January 12, 2012 [Page 8]