DMM Working Group S. Jeon
Internet-Draft Sungkyunkwan University
Intended status: Standards Track S. Figueiredo
Expires: January 8, 2017 Altran Research
Y. Kim
Soongsil University
J. Kaippallimalil
Huawei
July 07, 2016
Use Cases and API Extension for Source IP Address Selection
draft-sijeon-dmm-use-cases-api-source-04.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 January 8, 2017.
Copyright Notice
Copyright (c) 2016 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 January 8, 2017 [Page 1]
Internet-Draft Use Cases and API Extension July 2016
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 configured IP address based on a
requested type in the IP stack . . . . . . . . . . . 3
2.2.2. Case 2: there are one or more configured 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 configured IP addresses
based on a requested type in the IP stack, but there
is a further selection preference by the application 4
2.3. Gaps in the consistency with the default address
selection . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Indications for expressing address preference requirement . . 5
3.1. When an application does not have specific IP address
type requirement and address preferences . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
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 for 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, session-
lasting IP address, and non-persistent IP address. Following the
classified IP address type defined in the on-demand mobility draft
[I-D.ietf-dmm-ondemand-mobility] , 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
Jeon, et al. Expires January 8, 2017 [Page 2]
Internet-Draft Use Cases and API Extension July 2016
[RFC5014][RFC6724] operate on the available set of IP addresses,
based on a preference. But even within a request for a specific type
of IP address request, there may be a need to indicate further
requirements such as 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 categorizes 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 categorize 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 short-lived Internet connection without session continuity
and IP address reachability, assigning a non-persistent IP address
can be considered a default for MNs. But it is subject to address
assignment policy by network operators. The suggested flag,
IPV6_REQUIRE_NON-PERSISTENT_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 configured IP address based on a requested
type in the IP stack
For mobility support in terms of IP session continuity and IP address
reachability, session-lasting IP address and fixed IP address are
used. When one IP address based on one of the two types using flags
(IPV6_REQUIRE_FIXED_IP or IPV6_REQUIRE_SESSION_LASTING_IP) is
Jeon, et al. Expires January 8, 2017 [Page 3]
Internet-Draft Use Cases and API Extension July 2016
requested, a proper address assignment procedure based on DHCP or IP
mobility management protocol is expected.
2.2.2. Case 2: there are one or more configured 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 existence of configured 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 session-lasting IP
addresses.
2. Once an application requests "session-lasting IP address" to the
IP stack, it will use the existing session-lasting IP address when
there is one session-lasting IP address available in the IP stack.
If there are multiple available session-lasting 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
session-lasting IP address with the address flag to the IP stack.
The selection of the session-lasting IP address follows the same
procedure as described in Step 2.
2.2.3. Case 3: there are one or more configured IP addresses based on a
requested type in the IP stack, but there is a further selection
preference by the application
In case of session-lasting IP address, the procedure to assign and
configure session-lasting 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].
Suppose that there one or more session-lasting IP address type-based
applications are running. In the situation, a newly initiated
application may get one of the session-lasting IP addresses being
used, not requesting a new session-lasting IP address to the network.
Some applications using the existing session-lasting IP address may
get affected by the established routing path while other applications
may get affected much. In [I-D.ietf-dmm-ondemand-mobility], the on-
demand mobility is meant to enable applications to have the desired
Jeon, et al. Expires January 8, 2017 [Page 4]
Internet-Draft Use Cases and API Extension July 2016
mobility capability, i.e. IP address session continuity and/or IP
address reachability, by proper selection of source IP addresses. On
the other hand, it needs to be extended to have dynamic mobility
management capability, which should be considered when session-
lasting 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 the 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 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.
2.3. Gaps in the consistency with the default address selection
The need of an indication mechanism can be sought in the consistency
with the former IETF standards. For example, in [RFC6724] where
default behavior for IPv6 is specified, without a proper indication
mechanism, following conflicts are expected to happen. In Rule 6 in
[RFC6724], it is said that the matching label between source address
of an IPv6 host and destination address is preferred among
combinations between other source addresses and destination address,
where the label is a numeric value representing policies that prefer
a particular source address prefix for use with a destination address
prefix in [RFC6724]. In Rule 8 in [RFC6724], it is said that the
longest matching prefix between source address of an IPv6 host and
destination address is preferred among combinations between other
source addresses and destination address. Following Rules 6 and 8,
selection of a prefix may be different from the application's
preference that it wants to get connected, e.g. in terms of optimal
routing over the described distributed environments.
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.
Jeon, et al. Expires January 8, 2017 [Page 5]
Internet-Draft Use Cases and API Extension July 2016
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
session-lasting 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
session-lasting IP addresses, not assigned from the current serving
network, are available. If there are multiple session-lasting 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 */
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 session-lasting IP address might be used
for all initiated session-lasting 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 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 may present a way to deliver
Jeon, et al. Expires January 8, 2017 [Page 6]
Internet-Draft Use Cases and API Extension July 2016
a prefix decision for 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
[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>.
7.2. Informative References
[I-D.ietf-dmm-ondemand-mobility]
Yegin, A., Moses, D., Kweon, K., Lee, J., and J. Park, "On
Demand Mobility Management", draft-ietf-dmm-ondemand-
mobility-07 (work in progress), July 2016.
[I-D.mccann-dmm-prefixcost]
McCann, P. and J. Kaippallimalil, "Communicating Prefix
Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03
(work in progress), April 2016.
[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>.
Authors' Addresses
Seil Jeon
Sungkyunkwan University
2066 Seobu-ro, Jangan-gu
Suwon, Gyeonggi-do
Korea
Email: seiljeon@skku.edu
Jeon, et al. Expires January 8, 2017 [Page 7]
Internet-Draft Use Cases and API Extension July 2016
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
U.S
Email: john.kaippallimalil@huawei.com
Jeon, et al. Expires January 8, 2017 [Page 8]