Use Cases and API Extension for Source IP Address Selection
draft-sijeon-dmm-use-cases-api-source-02

DMM                                                              S. Jeon
Internet-Draft                             Instituto de Telecomunicacoes
Intended status: Standards Track                           S. Figueiredo
Expires: April 21, 2016                                  Altran Research
                                                                  Y. Kim
                                                     Soongsil University
                                                       J. Kaippallimalil
                                                                  Huawei
                                                        October 19, 2015

      Use Cases and API Extension for Source IP Address Selection
              draft-sijeon-dmm-use-cases-api-source-02.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 to better
   achieve DMM goals 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 April 21, 2016.

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 April 21, 2016                 [Page 1]
Internet-Draft         Use Cases and API Extension          October 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 have specific IP address
           type requirement and address preferences  . . . . . . . .   3
     2.2.  When an application has specific IP address type
           requirement and address preference  . . . . . . . . . . .   3
       2.2.1.  Case 1: there is no available IP address based on a
               requested type in the IP stack  . . . . . . . . . . .   3
       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
               further selection preference by the application . . .   4
   3.  Indications for expressing address preference requirement . .   5
     3.1.  When an application does not have specific IP address
           type requirement and address preferences  . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In [I-D.ietf-dmm-ondemand-mobility], it suggests picking up a proper
   source IP address type for an initiated application in a mobile node
   (MN), taking into consideration the need of IP session continuity
   and/or IP address reachability by the application.  Therefore, source
   IP addresses were defined in three types with regard to providing the
   required mobility management capabilities: fixed IP address,
   sustained IP address, and nomadic IP address.  Following the on-
   demand mobility approach, the MN obtains a proper IP address
   corresponding to a specific address type requirement when an
   application tries to get an IP address, 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

Jeon, et al.             Expires April 21, 2016                 [Page 2]
Internet-Draft         Use Cases and API Extension          October 2015

   which IP address is preferred among the available IP addresses
   belonging to the same type requested by the application.  Such a
   situation may easily be met over a DMM network environment for some
   reasons such as QoS or Policy, as an MN is supposed to obtain new IP
   prefixes from the different serving networks to which it attaches.
   To check and reflect further requirements based on the IP address
   types defined in the on-demand mobility management, this draft
   specifies and describes expected use cases where an MN is likely to
   be encountered and proposes required extensions to fill the gaps
   found from the use cases study.

2.  Use Cases

   We specify and analyze expected use cases where the MN tries to
   initiate an application.

2.1.  When an application does not have specific IP address type
      requirement and address preferences

   Applications such as a text-based web browsing or information-centric
   service, e.g. weather and stock information, as well as legacy
   applications may belong to this category.  As many applications
   require simple Internet connectivity without session continuity and
   IP address reachability, assigning a nomadic IP address can be highly
   considered by default for MNs.  But it is subject to address
   assignment policy by network operators.  The suggested flag,
   IPV6_REQ_NOMADIC_IP, defined in [I-D.ietf-dmm-ondemand-mobility] is
   used for expressing its preference to the IP stack.

2.2.  When an application has specific IP address type requirement and
      address preference

   This category is for an application requiring IP session continuity
   with different granularity of IP address reachability.  This case may
   be further divided in three sub-cases with regard to IP address type
   availability and/or address selection.

2.2.1.  Case 1: there is no available IP address based on a requested
        type in the IP stack

   For mobility support in terms of IP session continuity and IP address
   reachability, sustained IP address and fixed IP address are used.
   When one IP address of one of the two types is requested using flag
   IPV6_REQ_FIXED_IP or IPV6 REQ SUSTAINED IP, accordingly, a proper
   address assignment procedure based on DHCP or IP mobility management
   protocol is expected.

Jeon, et al.             Expires April 21, 2016                 [Page 3]
Internet-Draft         Use Cases and API Extension          October 2015

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

   In this case, the situation the MN meets is the same as Case 1
   described above, except the availability of IP addresses belonging to
   the requested IP address type in the IP stack, e.g. due to different
   address assignment policy by an operator.  Expected operation can be
   described as follows:

   1.  The MN is configured with one or more sustained IP addresses.

   2.  Once an application requests "sustained IP address" to the IP
   stack, it will use the existing sustained IP address when there is
   one sustained IP address available in the IP stack.  If there are
   multiple available sustained IP addresses, the default address
   selection rules will be applied [RFC6724], e.g. with scope
   preference, longest prefix matching, and/or so on.  The best-matched
   IP address among them will be selected and assigned to the
   application.

   3.  The MN moves to another serving network, while the previous
   (mobile) sessions are still working.  A new application requests a
   sustained IP address with the address flag to the IP stack.  The
   selection of the sustained IP address follows the same procedure as
   described in Step 2.

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 further selection
        preference by the application

   In case of sustained IP address, the procedure to assign and
   configure sustained IP addresses is the same as the procedure
   described in Case 2 when following the three types of IP addresses in
   [I-D.ietf-dmm-ondemand-mobility].

   On one hand, the on-demand mobility is meant to enable application to
   have the desired mobility capability, i.e. IP address session
   continuity and/or IP address reachability, by proper selection of a
   source IP address.  On the other hand, it needs to be extended to
   have dynamic mobility management capability, which should be
   considered when sustained IP address is used.  The specified
   operation based on the definition of address flags in
   [I-D.ietf-dmm-ondemand-mobility] does not ensure the observation of
   dynamic mobility principle, where IP mobility is provided only upon
   an MN's movement.  This is because an initiated application may be
   served with IP mobility even though the MN has not moved from the
   current serving network where the IP prefix/address was assigned for

Jeon, et al.             Expires April 21, 2016                 [Page 4]
Internet-Draft         Use Cases and API Extension          October 2015

   the Application.  As a result, IP mobility may be activated before
   needed, so the new session is served by a remote IP mobility anchor
   with necessary mobility management functions, though the MN has not
   moved yet.

   To make a proper way of delivering further preference of an
   application, additional definition for address selection preference
   in address flag level will help fill the requirement.  See Section 3
   for the proposed flag.

3.  Indications for expressing address preference requirement

   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.  When an application does not have specific IP address type
      requirement and address preferences

   To support dynamic mobility of an initiated application using
   sustained IP address, a new address preference flag needs to be
   defined.  Definition of additional flag should be simple and useful
   while going along with the three types of IP addresses.  But careful
   consideration may be needed in defining the level of address
   preference flag among "requirement" or "preference".  The objective
   of the hereby presented address preference flag is letting the IP
   stack check whether it has an available IP address assigned from the
   current serving network when the flag is received by an initiated
   application.  If not, it will trigger the IP stack to get a new IP
   address from the current serving network.  We call it "ON_NET"
   property.

   If it is defined in the requirement level, the IP address confirmed
   to the address preference requirement should be used, though other
   sustained IP addresses, not assigned from the current serving
   network, are available.  If there are multiple sustained IP addresses
   matched with ON_NET property, the default source address selection
   rules will be applied.

   If it is defined in the preference level, priority value for ON_NET
   flag should be determined among the other address preference flags
   defined in [RFC5014].

   IPV6_XX_SRC_ON_NET

   /* Require (or Prefer) an IP address based on a requested IP address
   type as source, assigned from the current serving network, whatever
   it has been assigned or should be assigned */

Jeon, et al.             Expires April 21, 2016                 [Page 5]
Internet-Draft         Use Cases and API Extension          October 2015

   This flag aims to express the preference to check an IP address,
   being used by an application, previously assigned from the current
   serving network and to use it or to get an IP address from the
   current serving network, as well as enabling differentiated per-flow
   anchoring where an obtained sustained IP address might be used for
   all initiated sustained IP applications.  The use of the flag can be
   combined together with the three types of IP address defined in
   [I-D.ietf-dmm-ondemand-mobility].

   In [I-D.mccann-dmm-prefixcost], it proposes that the Router
   Advertisement signaling messages communicate the cost of maintaining
   a given prefix at the MN's current point of attachment.  The
   objective of the idea is to make a dynamic and optimal decision of
   address assignment and release, i.e. when to release old addresses
   and assign new ones.  The proposed ON_NET property presents a way to
   deliver a prefix decision of an application, specifically from a
   routing distance point of view, to the IP stack.

4.  IANA Considerations

   This document makes no request of IANA.

5.  Security Considerations

   T.B.D.

6.  Acknowledgements

7.  References

7.1.  Normative References

   [I-D.ietf-dmm-ondemand-mobility]
              Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On
              Demand Mobility Management", draft-ietf-dmm-ondemand-
              mobility-00 (work in progress), May 2015.

   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
              Socket API for Source Address Selection", RFC 5014,
              DOI 10.17487/RFC5014, September 2007,
              <http://www.rfc-editor.org/info/rfc5014>.

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <http://www.rfc-editor.org/info/rfc6724>.

Jeon, et al.             Expires April 21, 2016                 [Page 6]
Internet-Draft         Use Cases and API Extension          October 2015

7.2.  Informative References

   [I-D.mccann-dmm-prefixcost]
              McCann, P. and J. Kaippallimalil, "Communicating Prefix
              Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-02
              (work in progress), October 2015.

Authors' Addresses

   Seil Jeon
   Instituto de Telecomunicacoes
   Campus Universitario de Santiago
   Aveiro  3810-193
   Portugal

   Email: seiljeon@av.it.pt

   Sergio Figueiredo
   Altran Research
   2, Rue Paul Dautier
   Velizy-Villacoublay  78140
   France

   Email: sergio.figueiredo@altran.com

   Younghan Kim
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Seoul  156-743
   Korea

   Email: younghak@ssu.ac.kr

   John Kaippallimalil
   Huawei
   5340 Legacy Dr., Suite 175
   Plano, TX  75024
   USA

   Email: john.kaippallimalil@huawei.com

Jeon, et al.             Expires April 21, 2016                 [Page 7]