Internet DRAFT - draft-yegin-ip-mobility-orchestrator
draft-yegin-ip-mobility-orchestrator
DMM Working Group A. Yegin
Internet-Draft J. Park
Intended status: Standards Track K. Kweon
Expires: January 4, 2015 J. Lee
Samsung
July 3, 2014
IP Mobility Orchestrator
draft-yegin-ip-mobility-orchestrator-00
Abstract
Host stacks can support mobility at multiple layers. Mobility
protocols operating at different layers constitute alternate
solutions with various pros and cons, and they can also have adverse
affects on each other when used simultaneously. Optimal results in
terms of seamless handover and data-path optimization can be achieved
when execution of these protocols are coordinated.
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 4, 2015.
Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Yegin, et al. Expires January 4, 2015 [Page 1]
Internet-Draft IP Mobility Orchestrator July 2014
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. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. IP Mobility Orchestrator . . . . . . . . . . . . . . . . 6
4.3. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Mobility Protocol Selection Algorithm . . . . . . . . . . 9
4.5. Handover Algorithm . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Host stacks can support mobility at multiple layers, such as network,
transport, and application layers. Mobility protocols operating at
different layers have different characteristics in terms of
availability, support for seamless handovers, and data-path
efficiency. No single solution supports both seamless handovers and
optimum data-paths while being universally available to all hosts and
networks. Furthermore, mobility protocols at different layers can
have adverse affect on each other when operating simultaneously
(e.g., one blocking the other).
This document describes the problem in detail, and proposes a
solution to achieve optimal results by coordinating the execution of
multiple mobility protocols.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Yegin, et al. Expires January 4, 2015 [Page 2]
Internet-Draft IP Mobility Orchestrator July 2014
3. Problem Statement
A number of protocol solutions are available to mobile hosts for
maintaining their end-to-end communication sessions while changing
their point of attachment within the IP network topology. Such
solutions include but are not limited to Mobile IP [RFC6275]
[RFC5944], Proxy Mobile IP [RFC5213] [RFC5563], GTP [GTP], LISP
[RFC6830], MOBIKE [RFC4555], MPTCP [RFC6824], SCTP [RFC4960], SIP
[RFC3261], and the proprietary ones built into the individual
applications (such as Instant Messengers). While any of these
protocols can maintain session continuity, they have different
characteristics.
The solutions that can completely hide IP mobility from the mobile
host stack include protocols like Proxy Mobile IP and GTP. These
solutions appear to operate below Layer 3 from the mobile host's
stack perspective (hence we call them "sub-IP solutions"). Sub-IP
solutions are available to all 3G/4G terminals. Every application on
a host attached to such a network can benefit from the mobility
service provided by these protocols. These protocols can achieve
seamless handovers, thanks to their ability to build data-path
extensions between source and target access networks during
handovers. Data-path extension can be setup fast because they
require short-haul signaling between the nearby access networks.
Even though the handovers are seamless, the end-to-end data-paths
between the mobile hosts and their corresponding hosts are sub-
optimal due to triangular routing via off-path IP anchors.
Protocol solutions operating at IP layer include Mobile IP and
MOBIKE. These solutions are not available on all mobile host stacks.
When they are available, they can be utilized by any of the
applications running on the mobile host. Seamless handover
capability and data-path suboptimality handicap apply to this group
of solutions for the same reasons as outlined for the sub-IP
solutions.
Solutions operating above the IP layer include MPTCP, SCTP, SIP, and
application-specific ones. Availability of these protocols cannot be
guaranteed on every host. Furthermore, even when they are available,
their applicability to applications is limited. For example, MPTCP
only applies to TCP-based applications, not to UDP-based
applications. Seamless handovers are not possible with these
solutions as any handover-related state update requires a long-haul
end-to-end signaling with the corresponding host. The round-trip
time required for this signaling becomes the source of packet loss
and delay during handovers. Inbound packets that are in-flight
during the handover procedure are lost, and outbound packets cannot
be transmitted until the handover is completed. On the other hand,
Yegin, et al. Expires January 4, 2015 [Page 3]
Internet-Draft IP Mobility Orchestrator July 2014
the end-to-end data-path is always optimal as the IP packets use
topological IP addresses and they are not forced to traverse off-path
IP anchors.
Each of these mobility protocols, when present, operate in isolation.
They are not aware of each other's presence or state, and they do not
coordinate their state machines among each other either.
Furthermore, solutions operating at the lower layers negatively
impact the solutions operating at the higher layers. For example,
MPTCP cannot detect IP subnet change when the host also uses Mobile
IP. Mobile IP hides any IP address change from higher-layers, not
only from the applications (an intended benefit) but also from the
MPTCP implementation (an undesirable side effect). Therefore, a
mobile host stack implementing both Mobile IP and MPTCP cannot enjoy
the mobility benefits of MPTCP due to Mobile IP operation. This
creates a sub-optimal result.
Each solution type has its pros and cons, and there is no clear
winner among them. No single solution can provide both seamless
handovers and optimal data-paths by itself. Furthermore, solutions
can have negative side-effects on each other to the extent that some
are rendered useless.
4. Solution
4.1. Approach
Sub-IP and IP-layer solutions can provide seamless handovers but lack
data-path optimization. On the other hand, above-IP solutions
provide data-path optimization but fail to provide seamless
handovers. The ideal solution would be based on coordianted
execution of the two types of solutions.
Let's illustrate the solution concept in action on a simple call
flow. Consider the case where both the mobile host and its
corresponding host support MPTCP, and the access network supports
Proxy Mobile IP.
Yegin, et al. Expires January 4, 2015 [Page 4]
Internet-Draft IP Mobility Orchestrator July 2014
Mobile Corresponding
Host t-GW s-GW Host
| | | |
|<---1. configure IP1------------------>| |
| | | |
|<...2. start e2e IP flow ..............o.........>|
| | | |
* 3. attach to t-GW | | |
| | | |
|<---4a. configure IP2------>| | |
| | | |
|<---4b. retain IP1--------->|<-------->| |
|<...........................o==========o.........>|
| | | |
|<---5. MPTCP (s/IP1/IP2)------------------------->|
|<...........................o....................>|
| | | |
|<---6. release IP1--------->|<-------->| |
| | ===X== | |
| | | |
Figure 1. Coordinated use of MPTCP and Proxy Mobile IP.
Step 1:
Mobile host attaches to source gateway (s-GW) and configures an IP
address (IP1).
Step 2:
Mobile host sets up an end-to-end TCP flow with a corresponding host
using IP1 as its local IP address.
Step 3:
Mobile host attaches to target gateway's (t-GW) radio network.
Step 4a:
Mobile host obtains a new IP address from t-GW (IP2) and configures
that address on its IP stack.
Step 4b:
In parallel with the previous step, mobile host requests the network
to continue using its previously allocated IP address (IP1). This
Yegin, et al. Expires January 4, 2015 [Page 5]
Internet-Draft IP Mobility Orchestrator July 2014
request results in signaling between the t-GW and s-GW, and setting
up a forwarding tunnel between the two routers. The end-to-end flow
continues using IP1 on the mobile host's end. The IP packets are
forwarded between the end-points via the s-GW and t-GW.
Step 5:
Mobile host updates its corresponding host to switch the TCP flow
from IP1 to IP2 using MPTCP, given that both IP addresses are
available to the mobile host and the latter one is preferable for
optimal network use. The TCP flow gets updated with the new local IP
address for the mobile host, and previously allocated IP address
(IP1) and inter-GW tunnel become redundant.
Step 6:
Mobile host requests the network to release the previously-allocated
IP address (IP1). Inter-GW signaling removes the associated tunnel
and forwarding state.
This example illustrates how the mobile host utilizes MPTCP as its
primary mobility protocol for its optimized data-path management
benefit and engages Proxy Mobile IP transiently as a secondary
solution for achieving seamless handovers.
4.2. IP Mobility Orchestrator
The functional entity in charge of the coordinated execution of
multiple mobility protocols is called IP Mobility Orchestrator. The
Mobility Orchestrator resides on the mobile host and performs the
following roles:
- Discovering host mobility capabilities: Finding out the mobility
protocols implemented on the host stack, including the capabilities
of individual applications.
- Discovering network mobility capabilities: Finding out whether the
IP/sub-IP solutions supported by the network.
- Discovering corresponding host mobility capabilities: Finding out
the mobility protocols implemented on the corresponding host stack.
- Selecting primary and secondary mobility protocols: Deciding which
protocols to engage for a given flow between the mobile host and its
corresponding host based on the capabilities of mobile host, access
network, and corresponding host.
Yegin, et al. Expires January 4, 2015 [Page 6]
Internet-Draft IP Mobility Orchestrator July 2014
- Coordinated execution of primary and secondary mobility protocols:
Controlling the execution of the primary and secondary mobility
protocols in response to IP handovers.
4.3. Call Flow
A more detailed call flow is depicted in Figure 2.
Mobile Corresponding
Host t-GW s-GW DNS Host
| | | | |
* 1. discover host mob.cap. | | | |
| | | | |
* 2. attach to s-GW | | | |
| | | | |
|<--3a. configure IP1 --------------->| | |
| | | | |
|<--3b. discover access.net.cap------>| | |
| | | | |
* 4. app attempts connection | | | |
| | | | |
|<--5a. resolve IP@ of cor.host------------->| |
| | | | |
|<--5b. discover cor.host mob.cap----------->| |
| | | | |
* 6. select mob. protocols | | | |
| | | | |
|<..7. start e2e IP flow .............o...........>|
| | | | |
* 8. attach to t-GW | | | |
| | | | |
|<--9a. discover acc.net.cap->| | | |
| | | | |
|<--9b. configure IP2-------->| | | |
| | | | |
|<--9c. retain IP1----------->|<----->| | |
|<............................o=======o...........>|
| | | | |
|<--10. MPTCP (s/IP1/IP2)------------------------->|
|<............................o...................>|
| | | | |
|<--11. release IP1---------->|<----->| | |
| | ==X== | | |
| | | | |
Figure 2. Use of MPTCP and Proxy Mobile IP (detailed).
Yegin, et al. Expires January 4, 2015 [Page 7]
Internet-Draft IP Mobility Orchestrator July 2014
Step 1:
Orchestrator discovers the mobility protocols implemented on the host
stack ({MPTCP} in this example).
Step 2:
Mobile host attaches to source gateway's (s-GW) radio network.
Step 3a:
Mobile host configures an IP address (IP1).
Step 3b:
Orchestrator discovers the mobility protocols supported by the access
network ({Proxy Mobile IP-based access network anchoring} in this
example).
Step 4:
An application running on the mobile host attempts to establish
communication with a corresponding host.
Step 5a:
Mobile host resolves the IP address of the corresponding host in
response to the associated API call (e.g., getaddrinfo()) from the
application.
Step 5b:
Orchestrator discovers the mobility protocols supported by the
corresponding host by using DNS ({MPTCP} in this example).
Step 6:
Orchestrator selects the primary and secondary mobility protocols for
the flow between the mobile host and the corresponding host based on
the discovered mobility capabilities of the mobile host, the access
network, and the corresponding host (MPTCP and Proxy Mobile IP-based
access network anchoring, respectively).
Step 7:
Given that MPTCP is the primary mobility protocol, the Orchestrator
allows the application to bind to IP1 (a local/unanchored/nomadic IP
address) and start the data flow.
Yegin, et al. Expires January 4, 2015 [Page 8]
Internet-Draft IP Mobility Orchestrator July 2014
Step 8:
Mobile host attaches to target gateway's (t-GW) radio network.
Step 9a:
Orchestrator discovers the mobility protocols supported by the access
network ({Proxy Mobile IP-based access network anchoring} in this
example).
Step 9b:
Orchestrator requests configuration of a local IP address (IP2),
given that it can be utilized by the primary mobility protocol,
MPTCP.
Step 9c:
Orchestrator issues a request to the access network for retaining
IP1, given that both the source and target (now serving) networks can
support access network anchoring. This results in forwarding tunnel
setup between the s-GW and the t-GW, and the flow continuing to use
IP1 through a data-path that traverses both s-GW and t-GW.
Step 10:
Orchestrator triggers the MPTCP to update its corresponding host to
switch the TCP flow from IP1 to IP2 using MPTCP, given that both IP
addresses are available to the mobile host and the latter one is
preferable for optimal network use. The TCP flow gets updated with
the new local IP address for the mobile host, and previously
allocated (anchored) IP address (IP1) and inter-GW tunnel become
redundant.
Step 11:
Orchestrator requests the network to release the anchored IP address
(IP1). Inter-GW signaling removes the associated tunnel and
forwarding state.
4.4. Mobility Protocol Selection Algorithm
The following pseudocode describes how the Orchestrator selects
primary and secondary mobility protocols when an application attempts
to initiate a new flow. This algorithm is run on a per-flow basis.
Yegin, et al. Expires January 4, 2015 [Page 9]
Internet-Draft IP Mobility Orchestrator July 2014
If there is an above-IP protocol common to both the mobile and
corresponding host for the given flow type
Select one of the common protocols as Primary Mobility Protocol
If access network supports IP or sub-IP protocols
Select one as Secondary Mobility Protocol
Else
There is no Secondary Mobility Protocol
Else
If network supports IP or sub-IP protocols
Select one as Primary Mobility Protocol
There is no Secondary Mobility Protocol
Else
There is no Primary&Secondary Mobility Protocol
4.5. Handover Algorithm
The following pseudocode describes how the Orchestrator coordinates
the execution of the primary and secondary mobility protocols at the
time of IP handovers. This algorithm is run at system-level on the
mobile host.
Yegin, et al. Expires January 4, 2015 [Page 10]
Internet-Draft IP Mobility Orchestrator July 2014
If any mobility protocol is used
If only a IP/sub-IP protocol is used
Request IP address anchoring
Else
If only above-IP primary protocols used w/o any secondary
protocols
Release the old IP address from old GW
Configure a new IP address from serving GW
For each primary mobility protocol
Execute primary protocol handover using new IP addr.
Else /* mix of IP/sub-IP and above-IP protocols used */
Request IP address anchoring with old GW
Configure a new IP address from serving GW
For each primary mobility protocol
Execute primary protocol handover using new IP addr.
If no flow using IP/sub-IP as primary mobility protocol
Release the old IP address from old GW
Else /* no mobility protocol is used */
Release the old IP address from old GW
Configure a new IP address from serving GW
5. Security Considerations
TBD
Yegin, et al. Expires January 4, 2015 [Page 11]
Internet-Draft IP Mobility Orchestrator July 2014
6. IANA Considerations
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[GTP] "3GPP Evolved Packet System (EPS); Evolved General Packet
Radio Service (GPRS) Tunnelling Protocol for Control plane
(GTPv2-C); Stage 3", TS 29.274 , June 2014.
[I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", draft-
ietf-dmm-requirements-17 (work in progress), June 2014.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5563] Leung, K., Dommety, G., Yegani, P., and K. Chowdhury,
"WiMAX Forum / 3GPP2 Proxy Mobile IPv4", RFC 5563,
February 2010.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC
5944, November 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
Yegin, et al. Expires January 4, 2015 [Page 12]
Internet-Draft IP Mobility Orchestrator July 2014
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013.
Authors' Addresses
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@partner.samsung.com
Jungshin Park
Samsung
Suwon
South Korea
Email: shin02.park@samsung.com
Kisuk Kweon
Samsung
Suwon
South Korea
Email: kisuk.kweon@samsung.com
Jinsung Lee
Samsung
Suwon
South Korea
Email: js81.lee@samsung.com
Yegin, et al. Expires January 4, 2015 [Page 13]
