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]