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]