[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 draft-ietf-dmm-distributed-mobility-anchoring

DMM                                                              H. Chan
Internet-Draft                                                    X. Wei
Intended status: Informational                       Huawei Technologies
Expires: May 5, 2016                                              J. Lee
                                                    Sangmyung University
                                                                 S. Jeon
                                           Instituto de Telecomunicacoes
                                                              F. Templin
                                          Boeing Research and Technology
                                                        November 2, 2015


                     Distributed Mobility Anchoring
            draft-chan-dmm-distributed-mobility-anchoring-06

Abstract

   This document defines the solution for mid-session switching of the
   IP prefix anchor with distributed mobility anchoring.  Without
   ongoing session requiring session continuity, the IP prefix anchor
   can be moved to a new network of attachment by using the new IP
   prefix allocated from the new network.  With ongoing session, the
   anchoring of the prior IP prefix may be relocated to the new network
   to enable session continuity.

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 May 5, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Chan, et al.               Expires May 5, 2016                  [Page 1]


Internet-Draft          mobility anchor switching          November 2015


   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
   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.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  IP prefix/address anchored in current network of attachment .   4
     3.1.  Changing to the new IP prefix/address . . . . . . . . . .   5
     3.2.  IP prefix/address anchor switching to the new network . .   8
       3.2.1.  Centralized control plane . . . . . . . . . . . . . .   9
       3.2.2.  Hierarchical network  . . . . . . . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   A key requirement in distributed mobility management [RFC7333] is to
   enable traffic to avoid traversing single mobility anchor far from
   the optimal route.  Recall that distributed mobility management
   solutions do not make use of centrally deployed mobility anchor
   [Paper-Distributed.Mobility].  As such, a flow SHOULD be able to have
   its traffic changing from traversing one mobility anchor to
   traversing another mobility anchor as the mobile node moves, or when
   changing operation and management requirements call for mobility
   anchor switching, thus avoiding non-optimal routes.  This draft
   proposes distributed mobility anchoring solutions.

   The needs of IP-layer mobility support are diverse so that the use of
   distributed anchoring may differ according to the needs.

   A mobile node (MN) may be running a flow with its correspondent node
   (CN) for which the source IP address of this flow belongs to MN's
   network.  That is, it is anchored to an access router (anchor)
   belonging to MN's network.  When there are multiple anchors, the flow
   may need to select the anchor when it is initiated (Section 3).



Chan, et al.               Expires May 5, 2016                  [Page 2]


Internet-Draft          mobility anchor switching          November 2015


   Using an anchor in MN's network has the advantage that the packets
   can simply be forwarded according to the forwarding table.  The
   anchor may be in the MN's network when the flow was initiated.  As
   the MN moves from one network to another, IP address no longer
   belongs to the new network.  To order that the IP address of the flow
   is in the new network different methods can be used dependent on the
   needs of the flow.  If the ongoing IP flow can cope with an IP
   prefix/address change, the flow can be reiniated with a new IP
   address anchored in the new network (Section 3.1).  On the other
   hand, if the ongoing IP flow cannot cope with such change, the IP
   address anchoring can be moved from the original network to the new
   network (Section 3.2).

2.  Conventions and Terminology

   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].

   All general mobility-related terms and their acronyms used in this
   document are to be interpreted as defined in the Mobile IPv6 base
   specification [RFC6275], the Proxy Mobile IPv6 specification
   [RFC5213], and the DMM current practices and gap analysis [RFC7429].
   This includes terms such as mobile node (MN), correspondent node
   (CN), home agent (HA), home address (HoA), care-of-address (CoA),
   local mobility anchor (LMA), and mobile access gateway (MAG).

   In addition, this document uses the following term:

   Home network of an application session (or of an HoA):  the network
      that has allocated the IP address (HoA) used for the session
      identifier by the application running in an MN.  An MN may be
      running multiple application sessions, and each of these sessions
      can have a different home network.

   IP prefix/address anchoring:  An IP prefix, i.e., Home Network Prefix
      (HNP), or address, i.e., Home Address (HoA), allocated to a mobile
      node is topologically anchored to a node when the anchor node is
      able to advertise a connected route into the routing
      infrastructure for the allocated IP prefix.

   Internetwork Location Management (LM) function:  managing and keeping
      track of the internetwork location of an MN.  The location
      information may be a binding of the IP advertised address/prefix,
      e.g., HoA or HNP, to the IP routing address of the MN or of a node
      that can forward packets destined to the MN.  It is a control
      plane function.




Chan, et al.               Expires May 5, 2016                  [Page 3]


Internet-Draft          mobility anchor switching          November 2015


      In a client-server protocol model, location query and update
      messages may be exchanged between a Location Management client
      (LMc) and a Location Management server (LMs).

      With separation of control plane and data plane, the LM function
      is in the control plane.  It may be a logical function at the
      control plane node, control plane anchor, or mobility controller.

      It may be distributed or centralized.

   Forwarding Management (FM) function:  packet interception and
      forwarding to/from the IP address/prefix assigned to the MN, based
      on the internetwork location information, either to the
      destination or to some other network element that knows how to
      forward the packets to their destination.

      This function may be used to achieve indirection.  With separation
      of control plane and data plane, FM may split into a FM function
      in the data plane (FM-DP) and a FM function in the control plane
      (FM-CP).

      FM-DP may be distributed with distributed mobility management.  It
      may be a function in a data plane anchor or data plane node.

      FM-CP may be distributed or centralized.  It may be a function in
      a control plane node, control plane anchor or mobility controller.

   Security Management (SM) function:  The security management function
      controls security mechanisms/protocols providing access control,
      integrity, authentication, authorization, confidentiality, etc.
      for the control plane and data plane.

      This function resides in all nodes such as control plane anchor,
      data plane anchor, mobile node, and correspondent node.

3.  IP prefix/address anchored in current network of attachment

   The deployment models of mobility management functions in the cases
   introduced through the subsections are referred from
   [I-D.templin-aerolink] [I-D.sijeon-dmm-deployment-models]

   The IP prefix/address at the MN's side of a flow may be anchored at
   the access router to which the MN is attached.

   For example, when an MN attaches to a network (Net1) or moves to a
   new network (Net2), it is allocated an IP prefix from that network.
   It configures from this prefix an IP address which is typically a
   dynamic IP address.  It then uses this IP address when it a flow is



Chan, et al.               Expires May 5, 2016                  [Page 4]


Internet-Draft          mobility anchor switching          November 2015


   initiated.  Packets to the MN in this flow are simply forwarded
   according to the forwarding table.

Net1                                                   Net2
+---------------+                                      +---------------+
|AR1 anchors IP1|                                      |AR2 anchors IP2|
+---------------+                                      +---------------+


+---------------+                                      +---------------+
|MN(IP1):       |                                      |MN(IP2):       |
|flow(IP2,...)  |                    or                |flow(IP2,...)  |
+---------------+                                      +---------------+

   Figure 1.  IP prefix/address anchored in network of attachment.  MN
   is attached to AR1 in Net1 where it has initiated a flow using IP1 or
   has moved to AR2 in Net2 where it initiates a new flow using IP2.

   There may be multiple IP prefixes/addresses to choose from.  They may
   be from the same access network or different access networks.  The
   network may advertise these prefixes with cost options
   [I-D.mccann-dmm-prefixcost] so that the mobile node may choose the
   one with the least cost.  In addition, these IP prefixes/addresses
   may be of different types regarding whether mobility support is
   needed [I-D.dmm-ondemand-mobility-api].  A flow will need to choose
   the appropriate one according to whether it needs IP mobility
   support.

   With on-demand mobility, IP mobility support is provided only when
   needed instead of being provided by default.

3.1.  Changing to the new IP prefix/address

   A straightforward choice of mobility anchoring is for a flow to use
   the IP prefix of the network to which the MN is attached when the
   flow is initiated [I-D.seite-dmm-dma].  This is shown in Figure 2.















Chan, et al.               Expires May 5, 2016                  [Page 5]


Internet-Draft          mobility anchor switching          November 2015


Net1                                                   Net2
+---------------+                                      +---------------+
|AR1 anchors IP1|                                      |AR2 anchors IP2|
+---------------+                                      +---------------+


+...............+                 move                 +---------------+
.MN(IP1):       .               =======>               |MN(IP2):       |
.flow(IP1,...)  .                                      |flow(IP2,...)  |
+...............+                                      +---------------+

   Figure 2.  Changing to the new IP prefix/address.  MN running a flow
   using IP1 in Net1 changes to running a flow using IP2 in Net2.

   When IP mobility is not provided to a specific flow, the flow may use
   a new IP address acquired from a new network as the MN moves to the
   new network.

   Regardless of whether IP mobility is needed, if the flow has
   terminated before the MN moves to a new network, the flow may
   subsequently restart using the new IP address allocated from the new
   network.

   When session continuity is needed, even if a flow is ongoing as the
   MN moves, it may still be desirable for the flow to change to using
   the new IP prefix configured in the new network.  The flow may then
   close and then restart using a new IP address configured in the new
   network.  Yet such a change in flow may be using a higher layer
   mobility support which is not in the scope of this document to change
   the IP address of the flow.

   In Figure 2, a flow initiated while the MN was in Net1 has terminated
   before the MN moves to a new network Net2.  After moving to Net2, the
   MN uses the new IP prefix anchored in Net2 to start a new flow.  The
   packets may then be forwarded without requiring IP layer mobility
   support.

   The call flow is outlined in Figure 3.













Chan, et al.               Expires May 5, 2016                  [Page 6]


Internet-Draft          mobility anchor switching          November 2015


 MN                    p-AR          n-AR                             CN
  |MN attaches to p-AR: |             |                                |
  |acquire MN-ID and profile          |                                |
  |--RS---------------->|             |                                |
  |                     |             |                                |
  |<----------RA(HNP1)--|             |                                |
  |                     |             |                                |
Allocated prefix HNP1
IP1 address configuration
  |                     |             |                                |
  |<-Flow(IP1,IPcn,...)-+--------------------------------------------->|
  |                     |             |                                |
  |MN detach from p-AR  |             |                                |
  |MN attach to n-AR    |             |                                |
  |                     |             |                                |
  |--RS------------------------------>|                                |
  |                     |             |                                |
  |<--------------RA(HNP2)------------|                                |
  |                     |             |                                |
Allocated prefix HNP2
IP2 address configuration
  |                     |             |                                |
  |<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
  |                     |             |                                |


   Figure 3.  A flow uses the IP allocated from the network at which the
   MN is attached when the flow is initiated.

   The security management function in the anchor node at a new network
   must allow to assign a valid IP prefix/address to a mobile node.

   When IP mobility is needed for a flow, the mobility support may be
   provided by IP prefix anchor switching to the new network to be
   described in Section 3.2 or by using other mobility management
   methods ([Paper-Distributed.Mobility.PMIP] and
   [Paper-Distributed.Mobility.Review]) Then the flow may continue to
   use the IP prefix from the prior network.  Yet some time later, the
   flow of a certain user application may be closed.  If the spplication
   is started again, the new flow may not need to use the prior network
   address to avoid having to invoke IP mobility support.  This is the
   case when the use of a permanent IP prefix/address is not needed.
   The flow may then use the new IP prefix in the network where the flow
   is initiated.  Routing is again kept simpler without employing IP
   mobility and will remain so as long as the MN has not moved away from
   that network.

   The call flow in this case is outlined in Figure 4.



Chan, et al.               Expires May 5, 2016                  [Page 7]


Internet-Draft          mobility anchor switching          November 2015


 MN                    p-AR          n-AR                             CN
  |MN attaches to p-AR: |             |                                |
  |acquire MN-ID and profile          |                                |
  |--RS---------------->|             |                                |
  |                     |             |                                |
  |<----------RA(HNP1)--|             |                                |
  |                     |             |                                |
Allocated prefix HNP1
IP1 address configuration
  |                     |             |                                |
  |<-Flow(IP1,IPcn,...)-+--------------------------------------------->|
  |                     |             |                                |
  |MN detach from p-AR  |             |                                |
  |MN attach to n-AR    |             |                                |
  |                     |             |                                |
  |--RS------------------------------>|                                |

HNP2 anchor switching to n-AR to be described in next sub-section
  |<--------------RA(HNP2,HNP1)---------|                                |
  |                     |             |                                |
  |<-Flow(IP1,IPcn,...)---------------+------------------------------->|
  |                     |             |                                |
Allocated prefix HNP2
IP2 address configuration
  |                     |             |                                |
Flow(IP1,IPcn) teminates
  |                     |             |                                |
  |<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
  |                     |             |                                |


   Figure 4.  A flow uses the IP allocated from the network at which the
   MN is attached when the flow is initiated.

3.2.  IP prefix/address anchor switching to the new network

   The IP prefix/address anchor may move without changing the IP prefix/
   address of the flow.













Chan, et al.               Expires May 5, 2016                  [Page 8]


Internet-Draft          mobility anchor switching          November 2015


Net1                                                   Net2
+---------------+                                      +---------------+
|LM:IP1<-->IPar2|                                      |LM:IP1<-->IPar2|
|FM:DHCPv6-PD   |                                      |               |
|---------------|                 move                 |---------------|
|AR1 anchors IP1|               =======>               |AR2 anc IP1,IP2|
+---------------+                                      +---------------+


+...............+                                      +---------------+
.MN(IP1):       .                 move                 |MN(IP1,IP2):   |
.flow(IP1,...)  .               =======>               |flow(IP1,...)  |
+...............+                                      +---------------+

   Figure 5.  IP prefix/address anchor switching to the new network.  MN
   with flow using IP1 in Net1 continues to run the flow using IP1 as it
   moves to Net2.

   As an MN with an ongoing session moves to a new network, the flow may
   preserve session continuity by moving the original IP prefix/address
   of the flow to the new network.  An example is in the use of BGP
   UPDATE messages to change the forwarding table entries as described
   in [I-D.mccann-dmm-flatarch] and also for 3GPP Evolved Packet Core
   (EPC) network in [I-D.matsushima-stateless-uplane-vepc].

   The security management function in the anchor node at a new network
   must allow to assign the original IP prefix/address used by the
   mobile node at the previous (original) network.  As the assigned
   original IP prefix/address is to be used in the new network, the
   security management function in the anchor node must allow to
   advertise the prefix of the original IP address and also allow the
   mobile node to send and receive data packets with the original IP
   address.

   The security management function in the mobile node must allow to
   configure the original IP prefix/address used at the previous
   (original) network when the original IP prefix/address is assigned by
   the anchor node in the new network.  The security management function
   in the mobile node also allows to use the original IP address for the
   previous flow in the new network.

3.2.1.  Centralized control plane

   An example of IP prefix anchor switching is in the case where Net1
   and Net2 both belong to the same operator network with separation of
   control and data planes ([I-D.liu-dmm-deployment-scenario] and
   [I-D.matsushima-stateless-uplane-vepc]), where the controller may
   send to the switches/routers the updated information of the



Chan, et al.               Expires May 5, 2016                  [Page 9]


Internet-Draft          mobility anchor switching          November 2015


   forwarding tables with the IP addressing anchoring of the original IP
   prefix/address at AR1 moved to AR2 in the new network.  That is, the
   IP address anchoring in the original network which was advertising
   the prefix will need to move to the new network.  As the anchoring in
   the new network advertises the prefix of the original IP address in
   the new network, the forwarding tables will be updated so that
   packets of the flow will be forwarded according to the updated
   forwarding tables.  Figure 6 shows such a case where the functions
   LM, FM-CP are centralized whereas the FM-DP's are distributed.

Net1                                                   Net2
+----------------------------------------------------------------------+
|                           LM:IP1<-->IPar2                            |
|                           FM-CP                                      |
+----------------------------------------------------------------------+

+---------------+                                      +---------------+
|FM-DP:DHCPv6-PD|                                      |FM-DP          |
|---------------|                 move                 |---------------|
|AR1 anchors IP1|               =======>               |AR2 anc IP1,IP2|
+---------------+                                      +---------------+


+...............+                                      +---------------+
.MN(IP1):       .                 move                 |MN(IP1,IP2):   |
.flow(IP1,...)  .               =======>               |flow(IP1,...)  |
+...............+                                      +---------------+

   Figure 6.  IP prefix/address anchor switching to the new network and
   with LM and FM-CP in a centralized control plane whereas the FM-DP's
   are distributed.

   The call flow in Figure 7 shows that MN is allocated HNP1 when it
   attaches to the p-AR.  A flow running in MN may or may not need IP
   mobility.  If it does, it may continue to use the previous IP prefix.
   If it does not, it may use a new IP prefix allocated from the new
   network.














Chan, et al.               Expires May 5, 2016                 [Page 10]


Internet-Draft          mobility anchor switching          November 2015


 MN                    p-AR          n-AR              DHCP Servers   CN
  |MN attaches to p-AR: |             |                     |          |
  |acquire MN-ID and profile          |                     |          |
  |--RS---------------->|             |                     |          |
  |<----------RA(HNP1)--|             |                     |          |
  |                     |             |             Allocate MN-HNP1   |
IP addr config          |             |                     |          |
  |                     |             |                     |          |
  |<-Flow(IP1,IPcn,...)-+--------------------------------------------->|
  |                     |             |                     |          |
  |MN detach from p-AR  |             |                     |          |
  |MN attach to n-AR    |             |                     |          |
  |                     |             |                     |          |
  |--RS------------------------------>|                     |          |
  |                     |             |                     |          |
  |                     |------DHCPv6 release-------------->|          |
  |                     |             |                     |          |
  |                     |             |--DHCPv6 PD request->|          |
  |                     |             |<-DHCPv6 PD reply--->|          |
  |                     |             |                     |          |
  |                    BGP route updates                    |          |
  |                     |             |                     |          |
  |<--------------RA(HNP2,HNP1)-------|                     |          |
  |                     |             |             Allocate MN-HNP2   |
IP addr config          |             |                     |          |
  |                     |             |                     |          |
  |<-Flow(IP1,IPcn,...)---------------+------------------------------->|
  |                     |             |                     |          |
  |  Flow(IP1,IPcn,...) terminates    |                     |          |
  |                     |             |                     |          |
  |                     | DHCPv6-PD timeout                 |          |
  |                     |             |                     |          |
  |                    BGP route updates                    |          |
  |                     |             |                     |          |
  |                     |             |                     |          |
  |<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
  |                     |             |                     |          |


   Figure 7.  DMM solution.  MN with flow using IP1 in Net1 continues to
   run the flow using IP1 as it moves to Net2.

   As the MN moves from p-AR to n-AR, the p-AR as a DHCP client may send
   a DHCP release message to release the HNP1.  It is now necessary for
   n-AR to learn the IP prefix of the MN from the previous network so
   that it will be possible for Net2 to allocate both the previous
   network prefix and the new network prefix.  The network may learn the
   previous prefix in different methods.  For example, the MN may



Chan, et al.               Expires May 5, 2016                 [Page 11]


Internet-Draft          mobility anchor switching          November 2015


   provide its previous network prefix information by including it to
   the RS message [I-D.jhlee-dmm-dnpp].

   Knowing that MN is using HNP1, the n-AR sends to a DHCP server a
   DHCPv6-PD request to move the HNP1 to n-AR.  The server sends to n-AR
   a DHCPv6-PD reply to move the HNP1.  Then BGP route updates will take
   place here.

   In addition, the MN also needs a new HNP in the new network.  The
   n-AR may now send RA to n-AR, with prefix information that includes
   HNP1 and HNP2.  The MN may then continue to use IP1.  In addition,
   the MN is allocated the prefix HNP2 with which it may configure its
   IP addresses.  Now for flows using IP1, packets destined to IP1 will
   be forwarded to the MN via n-AR.

   As such flows have terminated and DHCP-PD has timed out, HNP1 goes
   back to Net1.  MN will then be left with HNP2 only, which it will use
   when it now starts a new flow.

3.2.2.  Hierarchical network

   A hierarchy may also exist as shown the Figure 8.  Here the IP prefix
   allocated to the MN is anchored at an edge router (ER) supporting
   multiple access routers to which the MN may be attached.  Mobility of
   the MN involving change of AR but not of ER may be accomplished using
   tunneling between the ER and the AR or using some other L2 mobility
   mechanism.
























Chan, et al.               Expires May 5, 2016                 [Page 12]


Internet-Draft          mobility anchor switching          November 2015


Net1                                                   Net2
+----------------------------------------------------------------------+
|                           LM:IP1<-->IPar2                            |
|                           FM-CP                                      |
+----------------------------------------------------------------------+

                            +---------------+
                            |FM-DP          |
                            |---------------|
                            |ER1 anchors IP1|
                            +---------------+

+---------------+                                      +---------------+
|FM-DP          |                                      |FM-DP          |
|---------------|                 move                 |---------------|
|AR1            |               =======>               |AR2            |
+---------------+                                      +---------------+

+...............+                                      +---------------+
.MN(IP1):       .                 move                 |MN(IP1)        |
.flow(IP1,...)  .               =======>               |flow(IP1,...)  |
+...............+                                      +---------------+

   Figure 8.  Mobility without involving change of IP anchoring in a
   network with hierarchy in which the IP prefix allocated to the MN is
   anchored at an Edge Router supporting multiple access routers to
   which the MN may connect to.

   The mobility event shown in Figure 9 involves a change of the IP
   prefix anchoring.  ER1 acting as a DHCP-PD client may exchange
   message with the DHCP server to release the prefix IP1.  Meanwhile,
   ER2 acting as a DHCP-PD client may exchange message with the DHCP
   server to delegate the prefix IP1 to ER2.


















Chan, et al.               Expires May 5, 2016                 [Page 13]


Internet-Draft          mobility anchor switching          November 2015


Net1                                                   Net2
+----------------------------------------------------------------------+
|                           LM:IP1<-->IPar2                            |
|                           FM-CP                                      |
+----------------------------------------------------------------------+

                            +---------------+
                            |FM-DP          |
                            |---------------|
                            |GW             |
                            +---------------+

+---------------+                                      +---------------+
|FM-DP:DHCPv6-PD|                                      |FM-DP          |
|---------------|                 move                 |---------------|
|ER1 anchors IP1|               =======>               |ER2 anc IP1,IP2|
+---------------+                                      +---------------+

+---------------+                                      +---------------+
|FM-DP          |                                      |FM-DP          |
|---------------|                                      |---------------|
|AR1            |                                      |AR2            |
+---------------+                                      +---------------+

+...............+                                      +---------------+
.MN(IP1):       .                 move                 |MN(IP1,IP2):   |
.flow(IP1,...)  .               =======>               |flow(IP1,...)  |
+...............+                                      +---------------+

   Figure 9.  Mobility involving change of IP anchoring in a network
   with hierarchy in which the IP prefix allocated to the MN is anchored
   at an Edge Router supporting multiple access routers. to which the MN
   may connect to.

4.  Security Considerations

   TBD

5.  IANA Considerations

   This document presents no IANA considerations.

6.  Contributors

   This document has benefited from other work on mobility solutions
   using BGP update, on mobility support in SDN network, on providing
   mobility support only when needed, and on mobility support in
   enterprise network.  These work have been referenced.  While some of



Chan, et al.               Expires May 5, 2016                 [Page 14]


Internet-Draft          mobility anchor switching          November 2015


   these authors have taken the work to jointly write this document,
   others have contributed at least indirectly by writing these drafts.
   The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima,
   Peter McCann, and Pierrick Seite.

   Valuable comments have also been received from John Kaippallimil,
   ChunShan Xiong, and Dapeng Liu.

7.  References

7.1.  Normative References

   [I-D.dmm-ondemand-mobility-api]
              Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On
              Demand Mobility API", draft-dmm-ondemand-mobility-api-00
              (work in progress), May 2015.

   [I-D.jhlee-dmm-dnpp]
              Lee, J. and Z. Yan, "Deprecated Network Prefix Provision",
              draft-jhlee-dmm-dnpp-00 (work in progress), October 2015.

   [I-D.liu-dmm-deployment-scenario]
              Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei,
              "Distributed mobility management deployment scenario and
              architecture", draft-liu-dmm-deployment-scenario-05 (work
              in progress), October 2015.

   [I-D.matsushima-stateless-uplane-vepc]
              Matsushima, S. and R. Wakikawa, "Stateless user-plane
              architecture for virtualized EPC (vEPC)", draft-
              matsushima-stateless-uplane-vepc-05 (work in progress),
              September 2015.

   [I-D.mccann-dmm-flatarch]
              McCann, P., "Authentication and Mobility Management in a
              Flat Architecture", draft-mccann-dmm-flatarch-00 (work in
              progress), March 2012.

   [I-D.mccann-dmm-prefixcost]
              McCann, P. and J. Kaippallimalil, "Communicating Prefix
              Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-02
              (work in progress), October 2015.

   [I-D.seite-dmm-dma]
              Seite, P., Bertin, P., and J. Lee, "Distributed Mobility
              Anchoring", draft-seite-dmm-dma-07 (work in progress),
              February 2014.




Chan, et al.               Expires May 5, 2016                 [Page 15]


Internet-Draft          mobility anchor switching          November 2015


   [I-D.sijeon-dmm-deployment-models]
              Jeon, S. and Y. Kim, "Deployment Models for Distributed
              Mobility Management", draft-sijeon-dmm-deployment-
              models-01 (work in progress), October 2015.

   [I-D.templin-aerolink]
              Templin, F., "Asymmetric Extended Route Optimization
              (AERO)", draft-templin-aerolink-63 (work in progress),
              August 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <http://www.rfc-editor.org/info/rfc5213>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <http://www.rfc-editor.org/info/rfc6275>.

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <http://www.rfc-editor.org/info/rfc7333>.

   [RFC7429]  Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
              CJ. Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429,
              DOI 10.17487/RFC7429, January 2015,
              <http://www.rfc-editor.org/info/rfc7429>.

7.2.  Informative References

   [Paper-Distributed.Mobility]
              Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed
              IP Mobility Management from the Perspective of the IETF:
              Motivations, Requirements, Approaches, Comparison, and
              Challenges",  IEEE Wireless Communications, October 2013.

   [Paper-Distributed.Mobility.PMIP]
              Chan, H., "Proxy Mobile IP with Distributed Mobility
              Anchors",  Proceedings of GlobeCom Workshop on Seamless
              Wireless Mobility, December 2010.




Chan, et al.               Expires May 5, 2016                 [Page 16]


Internet-Draft          mobility anchor switching          November 2015


   [Paper-Distributed.Mobility.Review]
              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
              "Distributed and Dynamic Mobility Management in Mobile
              Internet: Current Approaches and Issues", February 2011.

Authors' Addresses

   H Anthony Chan
   Huawei Technologies
   5340 Legacy Dr. Building 3
   Plano, TX 75024
   USA

   Email: h.a.chan@ieee.org


   Xinpeng Wei
   Huawei Technologies
   Xin-Xi Rd. No. 3, Haidian District
   Beijing, 100095
   P. R. China

   Email: weixinpeng@huawei.com


   Jong-Hyouk Lee
   Sangmyung University
   708 Hannuri Building
   Cheonan 330-720
   Korea

   Email: jonghyouk@smu.ac.kr


   Seil Jeon
   Instituto de Telecomunicacoes
   Campus Universitario de Santiago
   Aveiro 3810-193
   Portugal

   Email: seiljeon@av.it.pt










Chan, et al.               Expires May 5, 2016                 [Page 17]


Internet-Draft          mobility anchor switching          November 2015


   Fred L. Templin
   Boeing Research and Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org












































Chan, et al.               Expires May 5, 2016                 [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/