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]