MEXT Working group                                          D. Liu (Ed.)
Internet-Draft                                              China Mobile
Intended status: Informational                             March 7, 2011
Expires: September 8, 2011


                 Distributed Deployment of Mobile IPv6
                draft-liu-mext-distributed-mobile-ip-00

Abstract

   This document describes a distributed deployment approach of mobile
   IPv6 protocol.

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 September 8, 2011.

Copyright Notice

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






Liu (Ed.)               Expires September 8, 2011               [Page 1]


Internet-Draft            Distributed Mobile IP               March 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Distributed Mobility Deployment Scenario . . . . . . . . . . .  3
   4.  Limitations of Centralized Approach  . . . . . . . . . . . . .  4
     4.1.  Non-optimal Routes . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Non-optimality in Evolved Network Architecture . . . . . .  6
     4.3.  Low Scalability of Centralized Route and Mobility
           Context Maintenance  . . . . . . . . . . . . . . . . . . .  6
     4.4.  Wasting Resources to Support Mobile Nodes Not Needing
           Mobility Support . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  Complicated Deployment with Too Many Variants and
           Extensions of MIP  . . . . . . . . . . . . . . . . . . . .  7
     4.6.  Mobility Signaling Overhead with Peer-to-Peer
           Communications . . . . . . . . . . . . . . . . . . . . . .  8
     4.7.  Single Point of Failure and Attack . . . . . . . . . . . .  8
   5.  Distributed Mobility Deployment Solution . . . . . . . . . . .  8
   6.  Distributed Mobility Deployment Considerations . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Co-authors and contributors  . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12

























Liu (Ed.)               Expires September 8, 2011               [Page 2]


Internet-Draft            Distributed Mobile IP               March 2011


1.  Introduction

   Mobile IPv6 and its variations are based on the similar principles
   where a given mobility agent (e.g. the Home Agent (HA) in Mobile IP)
   maintains Mobile Nodes (MNs) bindings.  Data traffic is then
   encapsulated between the MN and its mobility agent.  These approaches
   lead to the implementation of centralised architectures where both MN
   context and traffic encapsulation need to be maintained at a central
   network entity, the mobility agent.  Thus, when hundreds of thousands
   of MNs are communicating in a given communicating in a given cellular
   network, a centralized mobility anchoring point causes well-known
   bottlenecks and single point of failure issues, which requires costly
   network dimensioning and engineering to be fixed.  In addition,
   tunnelling encapsulations impact the overall network efficiency since
   they require the maintenance of MN's specific contexts in each tunnel
   end nodes and they incur delays in packet processing and transport
   functions.  This document introduces a distributed approach of
   deployment mobile ipv6 and its variations in a more optimal way
   especially for the flat network architecture.


2.  Conventions used in this document

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


3.  Distributed Mobility Deployment Scenario

   The rapid increasing of mobile data traffic giving much pressure to
   the mobile operator's core network.  To lower the cost, it is now
   preferable to offload the traffic that are not generated by mobile
   services from the IP core of the mobile network (e.g.  Internet
   traffic should be offloaded).  On the other hand, IP communications
   with mobile services are routed via a centralized anchor point (e.g.,
   the PGW in 3GPP/EPS mobile network).  In current proposals for
   network evolution, a local traffic anchor (i.e. a local gateway,
   L-GW), usually located near the access router, is in charge of
   offloading the traffic (e.g.  Internet and local traffic).











Liu (Ed.)               Expires September 8, 2011               [Page 3]


Internet-Draft            Distributed Mobile IP               March 2011


                 +----+
            ,-'' |CN  |.           +----------+
          ,'     +----+  \---------| central  |
         /    Packet      \        |  anchor  |
         |    Data        |        +----------+
         \    Network    ,'             |
          `.           _,               |
            `-..____,,'         *****************
                               *   IP network     *          __...._
                              *                    *       ,'       `-.
              +---------+   +----+             +----+     /  Internet  \
              |  Local  |__ |L-GW|             |L-GW|--- |    Access   |
              | Content |   +----+             +----+     \           ,'
              | Delivery|      *                  *        `-._    _,'
              | Network |       ******************             `'''
              +---------+        ||            ||
                               +----+        +----+
                               |AR1 |        |AR2 |
                               +----+        +----+
                                |  |            |
                                |  |            |
                               MN1 MN2          MN3




                   Figure 1: Scenario of L-GW deployment

   In this scenario, mobile ip deployment is different from traditional
   centralized way.  Considerations should be made to deploy mobile ip
   in a more optimal way in this architecture.


4.  Limitations of Centralized Approach

   This section describes the problems or limitations in a centralized
   mobility approach and compares it against the distributed approach.

4.1.  Non-optimal Routes

   Routing via a centralized anchor often results in a longer route.
   Figure 2 shows two cases of non-optimized routes.









Liu (Ed.)               Expires September 8, 2011               [Page 4]


Internet-Draft            Distributed Mobile IP               March 2011


                          +------+
                          |HA/LMA|
                          +------+
                            /\ \  \                   +---+
                           /  \   \    \              |CDN|
                          /    \     \      \         +---+
                         /      \       \        \      |
                        /        \         \          \ |
                    +------+  +------+  +------+   +------+
                    |FA/MAG|  |FA/MAG|  |FA/MAG|   |FA/MAG|
                    +------+  +------+  +------+   +------+
                                           |          |
                                         ----       ----
                                        | CN |     | MN |
                                         ----       ----



     Figure 2: Non-optimized route when communicating with CN and when
                         accessing local content.

   In the first case, the MN and the CN are close to each other but are
   both far from the mobility anchor.  Packets destined to the MN need
   to be routed via the mobility anchor, which is not in the shortest
   path.  The second case involves a content delivery network (CDN).  A
   user may obtain content from a server, such as when watching a video.
   As such usage becomes more popular, resulting in an increase in the
   core network traffic, service providers may relieve the core network
   traffic by placing these contents closer to the users in the access
   network in the form of cache or local CDN servers.  Yet as the MN is
   getting content from a local or cache server of a CDN, even though
   the server is close to the MN, packets still need to go through the
   core network to route via the mobility anchor in the home network of
   the MN, if the MN uses the HoA as the session identifier.  In a
   distributed mobility management design, mobility anchors are
   distributed in different access networks so that packets may be
   routed via a nearby mobility anchor function, as shown in Figure 2.
   Due to the above limitation, with the centralized mobility anchor
   design, route optimization extensions to mobility protocols are
   therefore needed.  Whereas the location privacy of each MN may be
   compromised when the CoA of an MN is given to the CN, those mobility
   protocol deployments that lack such optimization extensions will
   encounter non-optimal routes, which affect the performance.  In
   contrast, route optimization may be naturally an integral part of a
   distributed mobility management design.






Liu (Ed.)               Expires September 8, 2011               [Page 5]


Internet-Draft            Distributed Mobile IP               March 2011


4.2.  Non-optimality in Evolved Network Architecture

   Centralized mobility management is currently deployed to support the
   existing hierarchical mobile data networks.  It leverages on the
   hierarchical architecture.  However, the volume of wireless data
   traffic continues to increase exponentially.  The data traffic
   increase would require costly capacity upgrade of centralized
   architectures.  It is thus predictable that the data traffic increase
   will soon overload the centralized data anchor point, e.g., the P-GW
   in 3GPP EPS.  In order to address this issue, a trend in the
   evolution of mobile networks is to distribute network functions close
   to access networks.  These network functions can be the content
   servers in a CDN, and also the data anchor point.  Mobile networks
   have been evolving from a hierarchical architecture to a more
   flattened architecture.  In the 3GPP standards, the GPRS network has
   the hierarchy GGSN - SGSN - RNC - NB (Node B).  In 3GPP EPS networks,
   the hierarchy is reduced to P-GW - S-GW - eNB (Evolved NB).  In some
   deployments, the P-GW and the S-GW are collocated to further reduce
   the hierarchy.  Reducing the hierarchy this way reduces the number of
   different physical network elements in the network, contributing to
   easier system maintenance and lower cost.  As mobile networks become
   more flattened, the centralized mobility management can become non-
   optimal.  Mobility management deployment with distributed
   architecture is then needed to support the more flattened network and
   the CDN networks.

4.3.  Low Scalability of Centralized Route and Mobility Context
      Maintenance

   Special routes are set up to enable session continuity when a
   handover occurs.  Packets sent from the CN need to be tunneled
   between the HA and FA in MIP and between the LMA and MAG in PMIP.
   However, these network elements at the ends of the tunnel are also
   routers performing the regular routing tasks for ordinary packets not
   involving a mobile node.  These ordinary packets need to be directly
   routed according to the routing table in the routers without
   tunneling.  Therefore, the network must be able to distinguish those
   packets requiring tunneling from the regular packets.  For each
   packet that requires tunneling owing to mobility, the network will
   encapsulate it with a proper outer IP header with the proper source
   and destination IP addresses.  The network therefore needs to
   maintain and manage the mobility context of each MN, which is the
   relevant information needed to characterize the mobility situation of
   that MN to allow the network to distinguish their packets from other
   packets and to perform the required tunneling.  Setting up such
   special routes and maintaining the mobility context for each MN is
   more difficult to scale in a centralized design with a large number
   of MNs.  Distributing the route maintenance function and the mobility



Liu (Ed.)               Expires September 8, 2011               [Page 6]


Internet-Draft            Distributed Mobile IP               March 2011


   context maintenance function among different networks can be more
   scalable.

4.4.  Wasting Resources to Support Mobile Nodes Not Needing Mobility
      Support

   The problem of centralized route and mobility context maintenance is
   aggravated when the via routes are set up for many more MNs that are
   not requiring IP mobility support.  On the one hand, the network
   needs to provide mobility support for the increasing number of mobile
   devices because the existing mobility management has been designed to
   always provide such support as long as a mobile device is attached to
   the network.  On the other hand, many nomadic users connected to a
   network in an office or meeting room are not even going to move for
   the entire network session.  It has been studied that over two-thirds
   of a user mobility is local.  In addition, it is possible to have the
   intelligence for applications to manage mobility without needing help
   from the network.  Network resources are therefore wasted to provide
   mobility support for the devices that do not really need it at the
   moment.  It is necessary to dynamically set up the via routes only
   for MNs that actually undergo handovers and lack higher-layer
   mobility support.  With distributed mobility anchors, such dynamic
   mobility management mechanism may then also be distributed.
   Therefore, dynamic mobility and distributed mobility may complement
   each other and may be integrated.

4.5.  Complicated Deployment with Too Many Variants and Extensions of
      MIP

   Mobile IP (MIP), which has primarily been deployed in a centralized
   manner for the hierarchical mobile networks, already has numerous
   variants and extensions including PMIP, Fast MIP (FMIP), Proxy-based
   FMIP (PFMIP), hierarchical MIP (HMIP), Dual-Stack Mobile IP (DSMIP)
   and there may be more to come.  These different modifications or
   extensions of MIP have been developed over the years owing to the
   different needs that are found afterwards.  Deployment can then
   become complicated, especially if interoperability with different
   deployments is an issue.  While adaptations for MIP are being
   proposed for the deployment in a distributed manner for more
   flattened networks, it is desirable to also take a holistic view of
   different networks and scenarios and integrate the different MIP
   extensions.  The result will then be a more comprehensive mobility
   solution with options that can be turned on or off depending on
   different scenarios.  A desirable feature of mobility management is
   to be able to work with network architectures of both hierarchical
   networks and flattened networks, so that the mobility management
   protocol possesses enough flexibility to support different networks.
   In addition, one goal of dynamic mobility management is the



Liu (Ed.)               Expires September 8, 2011               [Page 7]


Internet-Draft            Distributed Mobile IP               March 2011


   capability to selectively turn on and off mobility support and
   certain different mobility signaling.  Such flexibility in the design
   is compatible with the goal to integrate different mobility variants
   as options.  Some additional extensions to the base protocols may
   then be needed to improve the integration.

4.6.  Mobility Signaling Overhead with Peer-to-Peer Communications

   In peer-to-peer communications, end users communicate by sending
   packets directly addressed to each other's IP address.  However, they
   need to find each other's IP address first through signaling in the
   network.  While different schemes for this purpose may be used, MIP
   already has a mechanism to locate an MN and may be used in this way.
   In particular, MIPv6 Route Optimization (RO) mode enables a more
   efficient data packets exchange than the bidirectional tunneling (BT)
   mode.  This RO mode is expected to be used whenever possible unless
   the MN is not interested in disclosing its topological location,
   i.e., the CoA, to the CN (e.g., for privacy reasons) or some other
   network constraints are put in place.  However, MIPv6 RO mode
   requires exchanging a significant amount of signaling messages in
   order to establish and periodically refresh a bidirectional security
   association (BSA) between an MN and its CN.  While the mobility
   signaling exchange impacts the overall handover latency, the BSA is
   needed to authenticate the binding update and acknowledgment messages
   (note that the latter is not mandatory).  In addition, the amount of
   mobility signaling messages increases further when both endpoints are
   mobile.  A dynamic mobility management capability to turn off these
   signaling when they are not needed will enable the RO mode between
   two mobile endpoints at minimum or no cost.  It will also reduce the
   handover latency owing to the removal of the extra signaling.  These
   benefits for peer-to-peer communications will encourage the adoption
   and large-scale deployment of dynamic mobility management.

4.7.  Single Point of Failure and Attack

   A centralized mobility anchoring architecture is generally more
   vulnerable to a single point of failure or attack, requiring
   duplication and backups of the support functions.  On the other hand,
   a distributed mobility management architecture has intrinsically
   mitigated the problem to a local network which is then of a smaller
   scope.  In addition, the availability of such functions in
   neighboring networks has already provided the needed architecture to
   support protection.


5.  Distributed Mobility Deployment Solution

   One solution to deploy Mobile IP in a flat architecture is to



Liu (Ed.)               Expires September 8, 2011               [Page 8]


Internet-Draft            Distributed Mobile IP               March 2011


   implement the HA functionalities in the access routers, as shown on
   Figure 2.  Any given IP flow can be considered as implicitly anchored
   on the current host's access router when set up.

   In addition, dynamic mobility anchoring [I-D.kassi-mobileip-dmi]
   could avoid data encapsulation for motionless nodes: until the host
   does not move, the IP flow is delivered as for any standard IPv6
   node.  The anchoring function at the access router is acting only to
   manage traffic indirection while the host moves to a new access
   router.  So, when the MN handoff, its current traffic is still
   attached to the anchor access router which is responsible for
   forwarding the IP flows to the MN.For example, let's consider an IP
   flow, flow#1, initiated by the mobile node, MN, when attached to AR2.
   Flow#1 will is routed in a standard way as long as the MN remain
   attached to AR2.  If the MN moves to AR3, flow#1 remains anchored to
   AR2, which plays the role of HA.  If MN starts a new IP
   communication, flow#2, while attached to AR3; flow#2 will be routed
   in a standard way as long as the MN remains attached to AR3.  Then,
   if the MN moves to AR1, flow#1 and flow#2 will be respectively
   anchored to AR2/HA and AR3/HA.



                       +---+          +---+         +---+
                       |CN1|          |CN2|         |CN3|
                       +---+          +---+         +--,+
                             _.---------+----------.    \
                      ,----''           |           `---'-.
                   ,-'                  |flow#1          \ `-.
                 ,'                     |                '   `.
                (             IP Network|                 \
                 `.                     |                  '  ,'
                   `-.                  ;                  ,\'
                      ;-----.          ;            _.----'  '
                    ,'       `---------+----------''         |
                   /                   |                      '
              +---'---+            +---:---+            +-------+
              |  AR1  |            | AR2`--|------------|  AR3  |
              |  HA   |            |  HA   |------------|HA     |
              +-------+            +-------+            +-------+
                                                 flow#1      \\ \flow#2
                                                tunnelled     \\ '
                                    +-----+                    +--\--+
                                    | MN  | ----move------->   | MN  |
                                    +-----+                    +-----+






Liu (Ed.)               Expires September 8, 2011               [Page 9]


Internet-Draft            Distributed Mobile IP               March 2011


                Figure 3: Distributed Client Based Mobility


6.  Distributed Mobility Deployment Considerations

   The following considerations should be applied in distributed mobile
   ip deployment:

   1. multiple home address handling

   The mobile node will have multiple home agents associate with it.
   Each home agent will assign a home address to the mobile node.  The
   applications on the mobile node need to select the right home address
   to matain the session continuity.  The sessions that established
   before handover should use the home address which is allocated by the
   previous home agent.  The newly initiate session should use the home
   address that newly allocated by the current home agent.

   2.  HA selection

   The mobile node should select the nearest HA for its communication.
   Mechanisms should be specified for the nearest HA selection.

   3.  CN initiate communication

   Since the mobile node has multiple home addresses, the CN should
   choose the proper home address to initate communication with the
   mobile node.  Mechanisms should be specified for CN to chose the
   proper home address.


7.  Security Considerations

   TBD


8.  IANA Considerations

   None


9.   Co-authors and contributors

   The following people contributed to this document (in no specific
   order):

   Pierrick Seite: pierrick.seite@orange-ftgroup.com




Liu (Ed.)               Expires September 8, 2011              [Page 10]


Internet-Draft            Distributed Mobile IP               March 2011


   Hidetoshi Yokota: yokota@kddilabs.jp

   Charles E. Perkins: charles.perkins@tellabs.com

   Melia Telemaco: telemaco.melia@alcatel-lucent.com

   Elena Demaria: elena.demaria@telecomitalia.it

   Wassim Michel Haddad: Wassam.Haddad@ericsson.com

   Jun Song: song.jun@zte.com.cn

   Hui Deng: denghui@chinamobile.com

   Zhen Cao: caozhen@chinamobile.com

   other contributors and co-authors will be added in the update
   version.


10.  References

10.1.  Normative References

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

10.2.  Informative References

   [I-D.chan-netext-distributed-lma]
              Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed
              Local Mobility Anchors",
              draft-chan-netext-distributed-lma-03 (work in progress),
              March 2010.

   [I-D.ietf-mext-flow-binding]
              Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
              Basic Support", draft-ietf-mext-flow-binding-11 (work in
              progress), October 2010.

   [I-D.kassi-mobileip-dmi]
              Kassi-Lahlou, M., "Dynamic Mobile IP (DMI)",
              draft-kassi-mobileip-dmi-01 (work in progress),
              January 2003.

   [I-D.seite-netext-dma]
              Seite, P. and P. Bertin, "Dynamic Mobility Anchoring",



Liu (Ed.)               Expires September 8, 2011              [Page 11]


Internet-Draft            Distributed Mobile IP               March 2011


              draft-seite-netext-dma-00 (work in progress), May 2010.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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

   [RFC5648]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
              and K. Nagami, "Multiple Care-of Addresses Registration",
              RFC 5648, October 2009.


Author's Address

   Dapeng Liu
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: liudapeng@chinamobile.com





























Liu (Ed.)               Expires September 8, 2011              [Page 12]