DMM WG Seil Jeon Internet Draft Institute de Telecomunicacoes Intended status: Standard Track S. Figueiredo Expires: August 26, 2015 Universidade de Aveiro Younghan Kim Soongsil University February 26, 2015 Use Cases and API Extension for Source IP address selection draft-sijeon-dmm-use-cases-api-source-00.txt Abstract This draft specifies and analyzes the expected cases regarding the selection of a proper source IP address and address type based on the application features over a distributed mobility management (DMM) network. It also provides available selection methods in the specified scenarios. 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 August 26, 2015. Copyright Notice Copyright (c) 2015 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 Jeon et al. Expires August 26, 2015 [Page 1] Internet-Draft Use Cases and API Extension February 2015 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. Use Cases ................................................... 3 2.1. When an application does not need to request a specific IP address type and requirement ................................ 3 2.2. When an application needs to request specific IP address type and requirement......................................... 3 2.2.1. Case 1: there is no available IP address based on a requested type in the IP stack. .......................... 4 2.2.2. Case 2: there are one or more IP addresses based on a requested type in the IP stack, and no selection preference by the application. ......................................... 4 2.2.3. Case 3: there are one or more IP addresses based on a requested type in the IP stack, but there is a selection preference by the application. ........................... 4 3. Indications for expressing requirements ..................... 5 3.1. Suggested indication flag .............................. 5 4. Security Considerations ..................................... 5 5. IANA Considerations ......................................... 5 6. References .................................................. 5 6.1. Normative References ................................... 5 1. Introduction In [draft-yegin-dmm-ondemand-mobility], it makes an attempt to classify the source IP address type for a mobile host, depending on the need of IP session continuity and/or IP address reachability. Therefore, three types of IP addresses were defined with regard to the mobility management; fixed IP address, sustained IP address, and nomadic IP address. After introducing the three types of IP addresses, it proposed a solution for the applications running on the mobile host to indicate whether they need IP session continuity or IP address reachability. When an application tries to get an IP address, it may require or prefer specific type of IP address or non-specific (any) type of it to the IP stack. The proposed approach aims to obtain a proper IP Jeon et al. Expires August 26, 2015 [Page 2] Internet-Draft Use Cases and API Extension February 2015 address corresponding to a specific address requirement, whereas the former approaches [RFC5014][RFC6724] operate on the available set of IP addresses, based on a preference. But even in the specific type of IP address request, there may be a need to indicate further requirements such as which IP address is more preferred among already configured multiple IP addresses based on the same type requested. Such a situation is easily met over a DMM network environment for some reasons such as QoS or Policy, as a mobile host is supposed to obtain a new prefix at each new mobility access router. Aligned with the needs, this draft specifies and describes expected use cases and proposes required extensions to support the given use cases. This draft is based on the [draft-yegin-dmm-ondemand- mobility] that proposed the three types of IP addresses with regard to the mobility management. 2. Use Cases We specify and analyse expected use cases when an application session is initiated. Furthermore, we organize the use cases according to the requested IP address type and additional requirement. 2.1. When an application does not need to request a specific IP address type and requirement Applications such as a text-based web browsing or information- centric service, e.g. weather and stock information may belong to this category. The suggested flag, IPV6_REQ_NOMADIC_IP, defined in [draft-yegin-dmm-ondemand-mobility] is used for expressing its preference to the IP stack. But it does not require a further signaling between the mobile host and the network, as a nomadic IP address is obtained by default whenever the mobile host is attached at an (mobility) access router. That is, obtaining this type of IP address could be orthogonal with the IP request by the application. However, it is only valid while the mobile host stays at the attached mobility access router. 2.2. When an application needs to request specific IP address type and requirement This category is for an application requiring IP session continuity with different granularity of IP address reachability. This case is again divided by three sub-cases with regard to IP address type availability and/or address selection, if needed. But the request of Jeon et al. Expires August 26, 2015 [Page 3] Internet-Draft Use Cases and API Extension February 2015 nomadic IP address is excluded in following cases, since it is given by default as described in Section 3.1. 2.2.1. Case 1: there is no available IP address based on a requested type in the IP stack. For resource-efficiency mobility support, the dynamic configuration of a sustained IP or fixed IP address can be preferred. Since there is a nomadic IP address configured in the IP stack, when a new type of IP address is needed, additional support mechanism is needed to express the preference of the application. In this case, the IP stack triggers one of the IP address configuration mechanisms (e.g. DHCPv6, SLAAC, or IP mobility protocols). 2.2.2. Case 2: there are one or more IP addresses based on a requested type in the IP stack, and no selection preference by the application. The mobile host already has the IP addresses following a requested IP address type by the application. In this case, the default address selection rules will apply [RFC6724], i.e. scope preference and longest prefix matching. The best-matched IP address among them will be selected. 2.2.3. Case 3: there are one or more IP addresses based on a requested type in the IP stack, but there is a selection preference by the application. In case of fixed IP address, the default address selection rule can simply be applied so that one IP address can be selected. In case of sustained IP address, taking into account the benefits of on-demand mobility from several DMM solution proposals, it is highly preferred for a mobile host to use a sustained IP address based on the prefix from a currently attached router. By following the default address selection algorithm, only the best- matched IP address will be selected, which may not be "the best" in terms of optimal routing and network resource spent. Indicating the host's preference will be required (See Section 4 for the proposed flag). For instance, suppose that an MN has already a sustained IP address (PrefA::) obtained in the IP stack when it stayed at network A and now it moved to network B. We also suppose that another application Jeon et al. Expires August 26, 2015 [Page 4] Internet-Draft Use Cases and API Extension February 2015 wants to configure a sustained IP address, but based on a new prefix from currently attached network for optimal routing. Without any indication by the application, the existing sustained IP address (PrefA::) will be selected and the session will be anchored at network A, which may lead to inefficiency to application performance and network resource due to sub-optimal routing. 3. Indications for expressing requirements When an application prefers a new IP address of the requested IP address type, additional indication flags should be delivered through the socket API interface. 3.1. Suggested indication flag IPV6_PREFER_SRC_NEW /* Prefer a new IP address based on a requested IP address type as source */ This flag is proposed to be added in RFC5014, and aims to express the preference for enabling differentiated per-flow anchoring. The use of the flag can be combined together with the three types of IP address defined in [draft-yegin-dmm-ondemand-mobility]. It is in equal degree and orthogonal with the defined flag-set in IPv6 socket API for source address selection [RFC5014]. 4. Security Considerations T.B.D. 5. IANA Considerations T.B.D. 6. References 6.1. Normative References [RFC5014] E. Nordmark, S. Chakrabarti, and J. Laganier, "IPv6 Socket API for Source Address Selection," IETF RFC 5014, Sep. 2007. [RFC6724] D. Thaler, R. Draves, A. matsumoto, and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)," IETF RFC 6724, Sep. 2012. Jeon et al. Expires August 26, 2015 [Page 5] Internet-Draft Use Cases and API Extension February 2015 [draft-yegin-dmm-ondemand-mobility] A. Yegin, K. Kweon, J. Lee, and J. Park, "On Demand Mobility Management," draft-yegin-dmm- ondemand-mobility-02, Jul. 2014. Jeon et al. Expires August 26, 2015 [Page 6] Internet-Draft Use Cases and API Extension February 2015 Authors' Addresses Seil Jeon Instituto de Telecomunicacoes Campus Universitario de Santiago Aveiro 3810-193, Portugal E-mail: seiljeon@av.it.pt Sergio Figueiredo Universidade de Aveiro 3810-193 Aveiro, Portugal E-mail: sfigueiredo@av.it.pt Younghan Kim Soongsil University 369, Sangdo-ro, Dongjak-gu, Seoul 156-743, Korea E-mail: younghak@ssu.ac.kr Jeon et al. Expires August 26, 2015 [Page 7]