Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Anthony Chan , Jong-Hyouk Lee , Seil Jeon
Last updated 2015-07-03
Replaced by draft-ietf-dmm-distributed-mobility-anchoring, RFC 8818
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chan-dmm-distributed-mobility-anchoring-04
DMM                                                              H. Chan
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                    J. Lee
Expires: January 4, 2016                            Sangmyung University
                                                                 S. Jeon
                                           Instituto de Telecomunicacoes
                                                            July 3, 2015

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

Abstract

   This document defines the mobility management protocol solutions in
   the context of a distributed mobility management deployment.  Such
   solutions consider the problem of assigning a mobility anchor and a
   gateway at the initiation of a flow.  In addition, the mid-session
   switching of the mobility anchor in a distributed mobility management
   environment is considered.

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

Copyright Notice

   Copyright (c) 2015 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

Chan, et al.             Expires January 4, 2016                [Page 1]
Internet-Draft          mobility anchor switching              July 2015

   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  3
   3.  IP address anchored in current network of attachment . . . . .  5
     3.1.  Changing to the new IP address . . . . . . . . . . . . . .  5
     3.2.  Moving the IP address anchor to the new network  . . . . .  6
   4.  IP address anchored not in current network of attachment . . .  7
     4.1.  Keeping the IP address from a prior network  . . . . . . .  8
       4.1.1.  Employing indirection of a flow  . . . . . . . . . . .  9
       4.1.2.  Changing the indirection path of a flow  . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Chan, et al.             Expires January 4, 2016                [Page 2]
Internet-Draft          mobility anchor switching              July 2015

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.  Recent developments in research and
   standardization with respect to future deployment models call for far
   more flexibility in network function operation and management.  For
   example, the work on service function chaining at the IETF (SFC WG)
   has already identified a number of use cases for data centers.
   Although the work in SFC is not primarily concerned with mobile
   networks, the impact on IP-based mobile networks is not hard to see
   as by now most hosts connected to the Internet do so over a wireless
   medium.  For instance, as a result of a dynamic re-organization of
   service chain a non-optimal route between mobile nodes may arise if
   one relies solely on centralized mobility management.  This may also
   occur when the mobile node has moved such that both the mobile node
   and the correspondent node are far from the mobility anchor via which
   the traffic is routed.

   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
   (OAM) requirements call for mobility anchor switching, thus avoiding
   non-optimal routes.  This draft proposes distributed mobility
   anchoring solutions.

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:

Chan, et al.             Expires January 4, 2016                [Page 3]
Internet-Draft          mobility anchor switching              July 2015

   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 address anchoring:  An IP address, i.e., Home Address (HoA), or
      prefix, i.e., Home Network Prefix (HNP) 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.

      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, this function may
      reside in a control plane anchor.

      It may be distributed or centralized.

      It may be a function in the control plane node, control plane
      anchor, or mobility controller.

   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 node or control 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.

Chan, et al.             Expires January 4, 2016                [Page 4]
Internet-Draft          mobility anchor switching              July 2015

   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 address anchored in current network of attachment

   The IP address at 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 starts a
   new flow.  Packets to the MN in this flow are simply forwarded
   according to the forwarding table.

   In this example, the flow may have terminated before the MN moves to
   a new network.  Otherwise, the flow may close and then restart using
   a new IP address configured in the new network.

  Net1                                                  Net2
  +--------------+                                      +--------------+
  |FM-DP:        |                                      |FM-DP:        |
  |AR1           |                                      |AR2           |
  |RA(IP1)       |                                      |RA(IP2)       |
  +--------------+                                      +--------------+
  +--------------+                                      +--------------+
  |MN(IP1):      |                  or                  |MN(IP2):      |
  |flow(IP1,...) |                                      |flow(IP2,...) |
  +--------------+                                      +--------------+

   Figure 1.  IP 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.

3.1.  Changing to the new IP address

   With the MN in the example in Section 3 it may be desirable to change
   to a flow using the new IP address configured in the new network.
   The packets of this flow may then follow the forwarding table without
   requiring IP layer mobility support.  Yet such a change in flow may

Chan, et al.             Expires January 4, 2016                [Page 5]
Internet-Draft          mobility anchor switching              July 2015

   be using a higher layer mobility support which is not in the scope of
   this document to change the IP address of the flow.

   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.

  Net1                                                  Net2
  +--------------+                                      +--------------+
  |FM-DP:        |                                      |FM-DP:        |
  |AR1           |                                      |AR2           |
  |RA(IP1)       |                                      |RA(IP2)       |
  +--------------+                                      +--------------+
  +..............+                                      +--------------+
  .MN(IP1):      .                 move                 |MN(IP2):      |
  .flow(IP1,...) .               =======>               |flow(IP2,...) |
  +..............+                                      +--------------+

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

3.2.  Moving the IP address anchor to the new network

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

  Net1                                                  Net2
  +..............+                                      +--------------+
  .FM-DP:        .                                      |FM-DP:        |
  .AR1           .                 move                 |AR2           |
  .RA(IP1)       .               =======>               |RA(IP2,IP1)   |
  +..............+                                      +--------------+
  +..............+                                      +--------------+
  .MN(IP1):      .                 move                 |MN(IP2,IP1):  |
  .flow(IP1,...) .               =======>               |flow(IP1,...) |
  +..............+                                      +--------------+

   Figure 3.  Moving the IP address anchor 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 address to the
   new network.  An example is in the use of BGP UPDATE messages to
   change the forwarding table entries as described in

Chan, et al.             Expires January 4, 2016                [Page 6]
Internet-Draft          mobility anchor switching              July 2015

   [I-D.mccann-dmm-flatarch] and also for 3GPP Evolved Packet Core (EPC)
   network in [I-D.matsushima-stateless-uplane-vepc].  Another example
   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
   forwarding tables with the IP addressing anchoring of the original IP
   prefix/address at AR1 moved to AR2 in the new network.  Then the IP
   anchor node which was advertising the prefix in the original network
   will need to move to the new network.  As the anchor node 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.

   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 allow to use the original IP address for the
   previous flow in the new network.

4.  IP address anchored not in current network of attachment

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

   An example when an MN moves to a new network is as follows.  The MN
   has an ongoing session which was initialized in a prior network
   (Net1) of attachment using an IP address belonging to the network
   where it was initialized as described in Section 3.  When the flow is
   unable to change its IP address it may continue to use its original
   IP address so that the IP address is anchored not in the current
   network of attachment but in the network where the original IP
   address belongs.  Mobility support is needed to enable the flow to
   use this original IP address.

Chan, et al.             Expires January 4, 2016                [Page 7]
Internet-Draft          mobility anchor switching              July 2015

  Net1                                                  Net2
  +--------------+                                      +--------------+
  |FM-DP:        |                                      |FM-DP:        |
  |AR1           |                                      |AR2           |
  |RA(IP1)       |                                      |RA(IP2)       |
  +--------------+                                      +--------------+
                                                        +--------------+
                                                        |MN(IP2):      |
                                                        |flow(IP1,...) |
                                                        +--------------+

   Figure 4.  IP address anchored not in network of attachment.  MN
   attached to AR2 in Net2 has a flow(IP1,...) using IP1, which belongs
   to Net1.

4.1.  Keeping the IP address from a prior network

   After the MN moves with an ongoing session to the new network (Net2),
   it obtains a new IP address or prefix from the new network.  However,
   the ongoing session which was initialized in a prior network of
   attachment is using an IP address belonging to the network where it
   was initialized as described in Section 3.1.  IP mobility is needed
   to use the original IP address for session continuity.

  Net1                                                  Net2
  +--------------+                                      +--------------+
  |FM-DP:        |                                      |FM-DP:        |
  |AR1           |<------------------------------------>|AR2           |
  |RA(IP1)       |                                      |RA(IP2)       |
  +--------------+                                      +--------------+
  +..............+                                      +--------------+
  .MN(IP1):      .                 move                 |MN(IP1,IP2):  |
  .flow(IP1,...) .               =======>               |flow(IP1,...) |
  +..............+                                      +--------------+

   Figure 5.  Keeping the IP address from a prior network.  MN with
   ongoing flow using IP1 in Net1 has moved to Net2 and the flow needs
   to continue using IP1 to preserve session continuity.

   The use of IP address belonging to the network of attachment whenever
   a new flow is initiated as described in Section 3 and to keep the IP
   address as the MN moves to a new network are described in
   [I-D.seite-dmm-dma].

Chan, et al.             Expires January 4, 2016                [Page 8]
Internet-Draft          mobility anchor switching              July 2015

4.1.1.  Employing indirection of a flow

   As an MN with an ongoing session moves to a new network, the flow may
   use the original IP address for session continuity by using
   indirection.  Here the location management information may be kept as
   a binding of the original IP address to a new forwarding address,
   whereas the Forwarding management function may then use this binding
   to forward the flow.

   In Figure 6, the location management information kept in the original
   network is the binding of the original IP address to an IP address in
   the new network.

                             Net3
                             +--------------+
                             |AR3           |
                             |RA(IPcn)      |
                            /+--------------+
  Net1                     / +--------------+           Net2
  +--------------+        /  |CN(IPcn): flow|           +--------------+
  |FM-CP:        |       /   |(IPcn,IP1,...)|           |FM-CP:        |
  |flow(IP1,...)-|      /    +--------------+           |flow(IP1,...)-|
  |AR1<-->AR2    |     /                                |AR1<-->AR2    |
  |              |    /                                 |              |
  |LM:IP1<->IPar2|   /                                  |LM:IP1<->IPar2|
  |--------------|  /                                   |--------------|
  |FM-DP:        |<-                                    |FM-DP:        |
  |AR1           | ------------------------------------>|AR2(IPar2)    |
  |RA(IP1)       |                                      |RA(IP2)       |
  +--------------+                                      +--------------+
  +..............+                                      +--------------+
  .MN(IP1):      .                 move                 |MN(IP1,IP2):  |
  .flow(IP1,...) .               =======>               |flow(IP1,...) |
  +..............+                                      +--------------+

   Figure 6.  Employing indirection of a flow.  After MN has moved from
   Net1 to Net2, Location Information function in Net1 keeps a binding
   of IP1 to IP of AR2, and Routing Management function in Net1 forwards
   the packets of the flow(IP1,...) to Net2.

   The packets of the flow(IP1, IPcn, ...) from the CN to the MN will
   first be forwarded to AR1 in the original network.  Here, using the
   binding of IP1 to an IP address in the new network, the forwarding
   management function may forward these packets to the new network such
   as by encapsulating them with a header destined to the new network.

   In a host-based mobility management solution such as

Chan, et al.             Expires January 4, 2016                [Page 9]
Internet-Draft          mobility anchor switching              July 2015

   [I-D.bernardos-dmm-cmip] and [Paper-Distributed.Mobility], the
   address in the new network may be the MN itself.

   In a network-based mobility management solution such as
   [I-D.bernardos-dmm-pmip], [I-D.sarikaya-dmm-for-wifi],
   [Paper-Distributed.Mobility] and [Paper-Distributed.Mobility.PMIP],
   the address in the new network may be an access router to which the
   MN is attached in the new network.  The access router may then
   forward the packet to the MN at L2, which may use Software-Defined
   Networking as described in [I-D.sarikaya-dmm-for-wifi].

   In general, indirection is invoked only when needed.  The flow can
   use the IP address belonging to the network of attachment where the
   flow is initialized as described in [I-D.seite-dmm-dma].

   In distributed mobility management, the FM-DP may be distributed.
   The LM and FM-CP may each be distributed and collocate with FM-DP.
   The may also be centralized.  Examples
   [I-D.yhkim-dmm-enhanced-anchoring] include: (1) Distribute LM and
   FM-CP, and collocate them with FM-DP, where the IP prefix allocation
   may be distributed or centralized; (2) As in (1) but with LM
   centralized; (3) As in (2) but with the IP prefix allocation function
   centralized.

   The security management function in the IP anchor node must ensure
   that the forwarding management function establishes secure forwarding
   with a relevant IP anchor node (e.g., forwarding between AR1 and
   AR2).  The security management function in the current IP anchor node
   (e.g., AR2) must allow the mobile node to receive or send data
   packets with an IP address configured at a prior network of
   attachment of the mobile node.  Note that nowadays access networks
   deploy ingress filtering so that the mobile node may not receive or
   send data packets with the previously configured IP address without
   the security management function's interaction with ingress
   filtering.

   The security management function in the mobile node must allow to use
   the previous IP address for the associated flow in the new network.

   The security management functions in the end communication nodes
   (i.e., mobile node and correspondent node) may be used to ensure a
   secure data plane between them.

   For establishments of secure forwarding between IP anchor nodes and
   secure data plane between the mobile node and correspondent node,
   existing security protocols such as IKE, IPsec, TLS may be invoked by
   the security management function.

Chan, et al.             Expires January 4, 2016               [Page 10]
Internet-Draft          mobility anchor switching              July 2015

4.1.2.  Changing the indirection path of a flow

   Forwarding the packets of an ongoing session from CN's network via
   the original network to MN's new network is not necessarily optimal.
   The route can be more direct by forwarding these packets directly
   from CN's network to MN's new network.

   Here, the location information in the original network may be copied
   to CN's network.  The packets of the flow(IP1, IPcn, ...) from the CN
   to the MN are first intercepted at the access router of CN.  Then
   using the binding of IP1 to an IP address in the new network, the
   forwarding management function in CN's network may forward these
   packets directly to the new network
   ([Paper-Distributed.Mobility.PMIP]) such as by encapsulating them
   with a header destined to the new network.

   To change the indirection of a flow, the relevant context with regard
   to MN should be delivered from AR1 in Net1 to AR3 (CN's anchor) in
   Net3 (CN's network), while AR2 should be notified of the change of
   indirection to receive packets directly forwarded by AR3.  Existing
   IP mobility signaling messages such as Proxy Binding Update (PBU) and
   Proxy Binding Acknowledgment (PBA) can be used for the both
   communications with as little option extensions as possible.  When a
   packet from the CN has reached AR3, AR3 encapsulates the packet with
   a tunnel header specified with IP address of CN's anchor as outer
   source IP and AR2's IP address as outer destination IP.  For
   transparent packet delivery operation in the perspective od AR2, CN's
   anchor needs to forward packets encapsulated with a tunnel header
   specified with AR1's IP address as outer source IP and AR2's IP
   address as outer destination IP.

   The security management function in the IP anchor node must ensure
   that the forwarding management function establishes secure forwarding
   with a relevant IP anchor node (e.g., forwarding between AR2 and AR3)
   during mis-session.  The security management function in the current
   IP anchor node (e.g., AR2) must allow the mobile node to receive or
   send data packets with an IP address configured at a prior network of
   attachment of the mobile node.

   The security management function in the mobile node must allow to use
   the previous IP address for the associated flow in the new network.

   The security management functions in the end communication nodes
   (i.e., mobile node and correspondent node) may be used to ensure a
   secure data plane between them during mis-session.

   For establishments of secure forwarding between IP anchor nodes and
   secure data plane between the mobile node and correspondent node,

Chan, et al.             Expires January 4, 2016               [Page 11]
Internet-Draft          mobility anchor switching              July 2015

   existing security protocols such as IKE, IPsec, TLS may be invoked by
   the security management function.

                             Net3
                             +--------------+
                             |FM-CP:        |
                             |flow(IP1,...)-|
                             |AR3<-->AR2    |
                         y..>|              |
                        p.   |LM:IP1<->IPar2|
                       o.    |--------------|
                      c.     |FM-DP:        |
                      .      |AR3           |
                     .       |RA(IPcn)      |
                    .        +--------------+\
  Net1             .         +--------------+ \         Net2
  +--------------+.          |CN(IPcn): flow|  \        +--------------+
  |FM-CP:        |           |(IPcn,IP1,...)|   \       |FM-CP:        |
  |flow(IP1,...)-|           +--------------+    \      |flow(IP1,...)-|
  |AR1<-->AR2    |                                \     |AR3<-->AR2    |
  |              |                                 \    |              |
  |LM:IP1<->IPar2|                                  \   |LM:IP1<->IPar2|
  |--------------|                                   \  |--------------|
  |FM-DP:        |                                    ->|FM-DP:        |
  |AR1           |                                      |AR2(IPar2)    |
  |RA(IP1)       |                                      |RA(IP2)       |
  +--------------+                                      +--------------+
  +..............+                                      +--------------+
  .MN(IP1):      .                 move                 |MN(IP1,IP2):  |
  .flow(IP1,...) .               =======>               |flow(IP1,...) |
  +..............+                                      +--------------+

   Figure 7.  Changing the indirection path of a flow.  Location
   Information function and Routing Management function in Net2 are
   copied to Net3, so that the Location Information function in Net3
   keeps a binding of IP1 to IP of AR2, and the Routing Management
   function in Net3 forwards the packets of the flow(IP1,...) to Net2.

5.  Security Considerations

   TBD

Chan, et al.             Expires January 4, 2016               [Page 12]
Internet-Draft          mobility anchor switching              July 2015

6.  IANA Considerations

   This document presents no IANA considerations.

7.  Contributors

   This document is an attempt to harmonize the different distributed
   mobility solutions in a number of other drafts.  These drafts cited
   in this document are the work of their many authors/co-authors.
   While some of them have taken the work to jointly write this
   document, others have contributed at least indirectly by writing
   these drafts.  The latter include Carlos J. Bernardos, Philippe
   Bertin, Hui Deng, Fabio Giust, Dapeng Liu, Satoru Matushima, Peter
   McCann, Antonio de la Oliva, Behcet Sarikaya, Pierrick Seite, Li Xue,
   Ryuji Wakikawa, and Younghan Kim.

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

8.  References

8.1.  Normative References

   [I-D.bernardos-dmm-cmip]
              Bernardos, C., Oliva, A., and F. Giust, "An IPv6
              Distributed Client Mobility Management approach using
              existing mechanisms", draft-bernardos-dmm-cmip-03 (work in
              progress), March 2015.

   [I-D.bernardos-dmm-pmip]
              Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based
              solution for Distributed Mobility Management",
              draft-bernardos-dmm-pmip-04 (work in progress),
              March 2015.

   [I-D.liu-dmm-deployment-scenario]
              Liu, V., Chan, A., and H. Deng, "Distributed mobility
              management deployment scenario and architecture",
              draft-liu-dmm-deployment-scenario-03 (work in progress),
              March 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-04 (work in
              progress), March 2015.

Chan, et al.             Expires January 4, 2016               [Page 13]
Internet-Draft          mobility anchor switching              July 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.sarikaya-dmm-for-wifi]
              Sarikaya, B. and L. Xue, "Distributed Mobility Management
              Protocol for WiFi Users in Fixed Network",
              draft-sarikaya-dmm-for-wifi-02 (work in progress),
              May 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.

   [I-D.yhkim-dmm-enhanced-anchoring]
              Kim, Y. and S. Jeon, "Enhanced Mobility Anchoring in
              Distributed Mobility Management",
              draft-yhkim-dmm-enhanced-anchoring-01 (work in progress),
              March 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, June 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC7333]  Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management",
              RFC 7333, August 2014.

   [RFC7429]  Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
              Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429, January 2015.

8.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:

Chan, et al.             Expires January 4, 2016               [Page 14]
Internet-Draft          mobility anchor switching              July 2015

              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.

   [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

   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 January 4, 2016               [Page 15]