[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/