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

Versions: 00 01 02

Network Working Group                                             D. Liu
Internet-Draft                                                    Z. Cao
Intended status: Informational                              China Mobile
Expires: January 11, 2011                                       P. Seite
                                                 France Telecom - Orange
                                                                 H. Chan
                                                     Huawei Technologies
                                                           July 10, 2010


                    Distributed mobility management
                   draft-liu-distributed-mobility-02

Abstract

   Current mobility solutions generally introduce an anchor point in the
   network, e.g., HA in MIPv6, LMA in PMIPv6, GGSN in 3GPP.  The anchor
   point is used to maintain the mapping between the stable IP address
   (e.g., Home address in MIPv6) and the current routable IP address
   (e.g., CoA in MIPv6).  However, one of the trend in mobile network
   evolution is to "flatten" mobility architecture by confining mobility
   support in the access network, e.g. at the access routers level,
   keeping the rest of the network unaware of the mobility events and
   their support.  This document discusses the deployment of current IP
   mobility mechanisms in such a flat architecture.

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 11, 2011.

Copyright Notice

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




Liu, et al.             Expires January 11, 2011                [Page 1]


Internet-Draft                     DMM                         July 2010


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Motivation for flattening mobile network architecture  . . . .  4
     3.1.  General considerations . . . . . . . . . . . . . . . . . .  4
     3.2.  IP Flow Mobility support in flat architectures . . . . . .  5
     3.3.  Dynamic mobility anchoring . . . . . . . . . . . . . . . .  7
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Considerations of distributed mobility solutions . . . . . . .  9
     6.1.  Client-based solutions . . . . . . . . . . . . . . . . . .  9
     6.2.  Network based solutions  . . . . . . . . . . . . . . . . . 11
     6.3.  Splitting the routing and the location management
           function . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15


















Liu, et al.             Expires January 11, 2011                [Page 2]


Internet-Draft                     DMM                         July 2010


1.  Introduction

   Most existing IP mobility solutions are derived from Mobile IP
   [RFC3775] principles where a given mobility anchor (e.g. the Home
   Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy
   Mobile IPv6 [RFC5213] maintains Mobile Nodes (MNs) bindings.  Data
   traffic is then encapsulated between the MN or its Access Router
   (e.g. the Mobile Access Gateway (MAG) in PMIPv6) 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 anchor.

   Such centralised approach provides the ability to route MN traffic
   whatever MN's localisation while maintaining IP session continuity
   during handovers.  However, when hundreds of thousands of MNs are
   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.

   It is however well established that a huge amount of mobile
   communications are set up while the user is not physically moving,
   i.e. its MN stays in the same radio cell.  For example, the user is
   being communicating at home, in his office, at a cafe...  Applying
   the aforementioned centralised principles leads then to aggregate
   user's contexts and traffic at a central node in the network for the
   sake of mobility support whereas the MN remains motionless.  As this
   leads to the introduced scalability and performances issues,
   alternative approaches may consider a way to better adapt mobility
   support in the network to cope with MN's movements and its ongoing
   traffic flows' requirements.  Typically, one of the trend in the
   evolution of mobile networks is to go to a flat architecture with the
   distribution of network functions, including mobility functions,
   close to the access gateways.  This document discusses the deployment
   of current IP mobility mechanisms (Mobile IPv6 and proxy Mobile IPv6)
   in such a flat architecture by dynamically distributing the mobility
   handling functions among terminals and access routers.  The goal is
   twofold:

   o  confining the mobility support at the access routers level,
      keeping the rest of the network unaware of mobility events and
      their support.
   o  dynamically adapting mobility support to each of the MN's needs by
      applying traffic redirection only to MNs' flows that are already
      established when an IP handover occurs;



Liu, et al.             Expires January 11, 2011                [Page 3]


Internet-Draft                     DMM                         July 2010


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.  Motivation for flattening mobile network architecture

3.1.  General considerations

   Development of new mobile services and usages (e.g., video streaming,
   mobile Internet) has led to huge increase of data traffic on the
   mobile network, thus giving much pressure to the mobile operator's
   core network.  In order to address scalability and performance issues
   with current centralized architecture, one of the trends in network
   evolution is to leverage on local content delivery network (CDN)
   where IP communications with local services are routed directly to
   the CDN without going through the IP core network.  For the same
   reason, 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).

   The generic mobile architecture with offload capabilities is depicted
   in Figure 1; it illustrates the following use-cases:

   o  Mobile node MN1 is attached to access router AR1 and consumes
      service delivered by the local CDN.  So, the corresponding IP
      flows are routed directly from AR1 to the CDN.
   o  MN2 is attached to AR1 and has an IP communication with CN.  So,
      the corresponding IP flows are routed to the packet data network
      PDN, via a centralized traffic anchor.
   o  MN3 is attached to AR2.  MN3 has an IP communication with CN and
      get access to the Internet.  The IP flow corresponding to Internet
      traffic is offloaded to the local Internet access via the L-PGW,
      whereas the IP communication with CN is routed via the centralized
      traffic anchor.









Liu, et al.             Expires January 11, 2011                [Page 4]


Internet-Draft                     DMM                         July 2010


              +----+
         ,-'' |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: Deployment of Local content delivery and IP traffic offload
                  in a centralized mobility architecture

3.2.  IP Flow Mobility support in flat architectures

   When the host can simultaneously connect to different access systems,
   IP flow mobility is considered by operator as a flexible way to route
   traffic according network access and applications specific
   contraints.  For example, a given IP flow (e.g. video streaming),
   initially routed through one access, could be selectively offloaded
   to another access while maintaining other traffic (e.g. traffic with
   specific QoS requirements) on the primary access.  This kind of
   traffic management is specified in [TR23.261] when considering
   centralized architecture.  This section discusses deployment of IP
   mobility mechanisms in flat mobile architectures as specified in
   Figure 1.

   Existing mobility solutions generally introduce a mobility anchor in
   the network; examples are HA in MIPv6, LMA in PMIPv6, and GGSN/PGW in
   3GPP.  The mobility anchor is used to maintain the mapping between
   the stable IP address (e.g., Home address in MIPv6) and the current
   routable IP address (e.g., CoA in MIPv6).  In the centralized
   architecture, the mobility anchor point is usually located at the top



Liu, et al.             Expires January 11, 2011                [Page 5]


Internet-Draft                     DMM                         July 2010


   of the architecture.  Yet in a flat architecture, such as the one
   depicted in Figure 1, the traffic anchor point can be much lower
   (e.g. located in the access system) compared with centralized
   architecture.  So, for the sake of routing optimization the mobility
   anchor should also be located closer to the traffic anchoring point,
   otherwise the traffic could not break out locally.  Actually, routing
   optimization issue will become more severe in the flat architecture
   if traditional mobility protocol is used.  The mobility tunnel needs
   to be connected back to the mobility anchor where the mobile node
   attaches (and gets the IP address allocation).  Then all IP traffic
   of that mobile node will be routed through the mobility anchor.
   Despite the well-known scalability issues brought by centralized
   approaches, a central mobility anchor in a flat architecture leads to
   non-optimal routing for local and offloaded traffic: the data path
   goes through the central mobility anchor point before being routing
   back to the local traffic anchoring point (e.g.  L-GW).  Such non-
   optimal routing may degrade the user experience due to the latency
   caused by the long route to the destination.  So, in a mobile
   architecture distributing the traffic anchoring, as depicted on
   Figure 1, the mobility anchoring function shall also be distributed
   to provide efficient IP session continuity for both local and
   centralized traffic.  Figure 2 shows an example of distributed IP
   mobility architecture.  In this example mobility anchors are deployed
   both in the centralized traffic anchoring point and in the access
   routers to manage respectively mobility of centralized and local
   traffic.

























Liu, et al.             Expires January 11, 2011                [Page 6]


Internet-Draft                     DMM                         July 2010


                +----+
           ,-'' |CN  |.           +-----------+
         ,'     +----+  \---------| Mobility  |  Mobility
        /    Packet      \        |anchor (MA)|  Anchor
        |    Data        |        +-----------+  for centralized
        \    Network    ,'             |         traffic
         `.           _,               |
           `-..____,,'         *****************
                              *   IP network     *          __...._
                             *                    *       ,'       `-.
             +---------+   +----+             +----+     /  Local     \
             |  Local  |__ |L-GW|             |L-GW|--- |  content    |
             | Content |   |    |             |    |    |             |
             | Delivery|   +----+             +----+     \           ,'
             | Network |       ******************         `''''''`'''
             +---------+        ||            ||
                              +----+        +----+  mobility
                              |AR1 |        |AR2 |  anchors
                              |+MA          |+MA |  for local
                              +----+        +----+  traffic
                                 |            |
                         3GPP    |            |WiFi
                                 +-----MN1----+






                 Figure 2: Distributed Mobility Anchoring

3.3.  Dynamic mobility anchoring

   Applying the centralized mobility management principles leads to
   aggregate user's contexts and traffic at a central node in the
   network whereas the MN remains stationary.  However, once attached to
   the new access router, the mobile node can again acquire a routable
   global IPv6 address to be used for any new communication flow it sets
   up.  Hence, a flow based mobility support may be restricted to
   provide traffic indirection to host's flows that are already ongoing
   during host's handovers between access routers.  Any new flow being
   set up uses the new host's global address acquired on the new link
   available after the handover.

   When a multiple-interfaces node moves an IP flow between access
   routers of different access technologies, such a simple approach can
   also apply.  Flow mobility management should then be required only to
   support the necessary traffic indirection from the mobility anchor on



Liu, et al.             Expires January 11, 2011                [Page 7]


Internet-Draft                     DMM                         July 2010


   which the flow has been initially set up to the access router to
   which the host is currently attached.

   Hence, any given IP flow can be considered as implicitly anchored on
   the current MN's access router when being set up.  So, it leads to
   deploy mobility anchors in access routers.  While the MN is attached
   to its initial access router, the IP flow is delivered as for any
   standard IPv6 node.  The mobility anchoring at the access router then
   allow to manage traffic indirection if the MN moves to a new access
   router (and for subsequent movements while the IP flow remains
   active), maintaining the flow communication until it ends up.


4.  Requirements

   This section gives the requirements for mobility management support
   in flat architectures.


   o  To ensure the IP traffic offload in the flat architecture and
      still maintain the service continuity, the mobility anchoring
      should close to the local gateway(access router),i.e. confining
      mobility support to the access routers level, keeping the rest of
      the network unaware of mobility events.  For example, the access
      router mayshould be the anchoring point of local IP traffic.
   o  IP flow mobility: it shall be possible to offload selected traffic
      (e.g.  Internet) by moving IP flows from one access to another.
   o  It is preferred for the distributed mobility solution requiring
      less changes to the network and current mobility protocols.  The
      distributed mobility solution should compatible with legacy
      mobility mechanisms.  This requirement may help the distributed
      mobility solution easier for deployment
   o  Mobility mechanism should come into play only for node on the move
      (optional feature) .  It leads to dynamically adapting mobility
      support to each MN's needs by applying traffic redirection only to
      MN's flows those are ongoing when handover occurs.


5.  Gap analysis

   Current mobility protocols (DSMIPv6/PMIPv6) may be used in the flat
   architecture.  For example, for the architecture depicted in figure
   1, DSMIPv6 or PMIPv6 may be used.  The L-GW (Local Gateway in Figure
   2) could be the mobility anchor point (HA/LMA) for DSMIPv6/PMIPv6 and
   also act as MAG for PMIPv6.  But it is not optimized in many ways.






Liu, et al.             Expires January 11, 2011                [Page 8]


Internet-Draft                     DMM                         July 2010


   1.  Non-optimized routing: When the UE attaches to the network
       through one L-GW, that L-GW will be the anchor point of that UE.
       When the UE moves out of this L-GW's service area, the UE/MAG has
       to establish a mobility tunnel back the original L-GW.
       Obviously, the routing is not optimized since the UE/MAG always
       needs to establish the mobility tunnel back to the original L-GW
       no matter where it has moved to.  This will increase unnecessary
       traffic to the operator's network compared with locally breaking
       out the traffic.  In LTE/SAE network, when the UE attaches to the
       network it will always keep that IP address, this feature is
       called "always on".  The "always on" feature will worsen the
       problem.  The reason is that in 2G/3G mobile network, when the UE
       terminates a session, it will detach from the network, when it
       attach to the network again, it will get a new IP address and the
       anchor point could be changed to the L-GW accordingly.  But in
       LTE/SAE, the UE does not detach from the network as long as it is
       power on.
   2.  Increased delay: The non-optimized routing causes the routing
       path to be much longer compared with local breakout, this will
       increase the transmission delay.
   3.  Single point of failure: The UE will always depend on its
       original anchor point to maintain service continuity to wherever
       it has moved.  This will cause the single point of failure
       problem compared with distributing the mobility anchor function.


6.  Considerations of distributed mobility solutions

   This section discusses the applicability of MIPv6/PMIPv6 in flat
   architectures.  Based on the above analysis, there may be an interest
   to consider specific deployment of mobility mechanisms in flat
   architecture.  This kind of solution may be called distributed
   mobility solutions since the mobility anchor function is distributed
   compared with the centralized mobility anchor point in traditional
   mobility protocol.

   The distributed mobility solutions should make minimal changes to the
   existing network entity.  It is preferable to require no change to
   the UE and be transparent to the application layer.

   The following sub-sections only give basics for distributed mobility,
   the detailed solutions will be identified in future.

6.1.  Client-based solutions

   One solution to deploy Mobile IP in a flat architecture is to
   implement the HA functionalities in the access routers, as shown on
   Figure 3.  Any given IP flow can be considered as implicitly anchored



Liu, et al.             Expires January 11, 2011                [Page 9]


Internet-Draft                     DMM                         July 2010


   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  |
                                +-----+                    +-----+


                Figure 3: Distributed Client Based Mobility





Liu, et al.             Expires January 11, 2011               [Page 10]


Internet-Draft                     DMM                         July 2010


6.2.  Network based solutions

   Figure 4 shows de deployment of PMIP [RFC5213] in a flat mobile
   architecture.  The basic is to distribute mobility traffic management
   with dynamic user's traffic anchoring in the access network nodes.
   Each AR supports both the MAG and LMA functionalities.  Any given IP
   flow can be considered as implicitly anchored on the current host's
   access router when set up.  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 thus 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 its anchored MN's
   IP flows to the new MN's location (i.e. to the AR the MN is attached
   to).  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
   LMA.  AR3 plays the role of MAG for MN/flow#1.  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/LMA and AR3/LMA and AR1 will provide MAG
   functionalities for MN.



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



Liu, et al.             Expires January 11, 2011               [Page 11]


Internet-Draft                     DMM                         July 2010


               Figure 4: Distributed Network Based Mobility

6.3.  Splitting the routing and the location management function

   The logical functions of the mobility anchor defined in conventional
   mobility protocols may be split for both a better scalability and
   signaling efficiency.  For instance [I-D.chan-netext-distributed-lma]
   proposes to split the mobility anchor entity into the following
   functions:
   1.  location management anchoring function
   2.  mobility routing anchoring function.
   The location management anchoring function includes keeping track of
   the internetwork location of the mobile node, which is identified
   with a permanent home address HoA.  The mobility routing anchoring
   function includes routing the packets with HoA as destination address
   to the destination or to some other network element that knows how to
   forward to the destination.

   In the conventional mobility protocols, these two anchoring functions
   have been colocated into one mobility anchor.  The collocated
   mobility anchor contains the full location information to enable its
   role to redirect packets to the new location of the mobile node.  The
   result is the dilemma in where to position this collocated mobility
   anchor in a hierarchical network.  On the one hand, it is simpler to
   have only one or possibly a very small number of mobility anchors to
   centrally manage the location of a larger number of mobile nodes.
   However, routing the packets through such centralized nodes often
   results in non-optimal routing.  On the other hand, having many
   mobility anchors whose locations are low in the hierarchy will
   shorten the route.  Yet it will then be costly and difficult to
   synchronize the location information when many such collocated
   mobility anchors are performing location management and each needs to
   have full location information of all the mobile nodes.

   Splitting the logical functions of location management and routing
   enables each function to be optimized in the design.

   The mobility routing function can be implemented in many physical
   places instead of in one or very few centralized places only.  There
   are then many such places to provide the mobility routing function,
   and the packets can always be served by one that is nearby.  Many of
   these packets would have to traverse a long route to reach a mobility
   routing function if there were only one centralized mobility routing
   function.

   The location management function, being implemented separately from
   the mobility routing function, do not need to be implemented in as
   many places as the mobility routing function.  The implementation of



Liu, et al.             Expires January 11, 2011               [Page 12]


Internet-Draft                     DMM                         July 2010


   the location information system can be optimized according to the
   optimization of a database design.  There may be only one, except for
   backup, database system.  The database may still be distributed but
   are only distributed to much fewer number of places than the routing
   functions.

   After splitting the above functions, the mobility routing anchor
   points serving a source node sending packet to a destination mobile
   node may lack the location information of the destination mobile
   node.  The mobility routing anchor may query the location management
   system to obtain the location information of the mobile node to which
   it needs to route the first packet.  Alternatively, the location
   management anchor point may also possess routing function so that the
   first packet may be forwarded to the location management anchor point
   to route to the destination mobile node.  Meanwhile the location
   information of this mobile node is being sent to the mobility routing
   anchor.  After the mobility routing anchor has received the location
   information, it caches this information for its use to route the
   subsequent packets to the same mobile node.

   One access gateway plays the role of LM.  Location update may be
   implemented in a separate entity (see figure)



                     +---+          +---+
                     |CN1|          |CN2|
                     +---+          +---+
                           _.---------+----------.
                    ,----''           |           `----.
                 ,-'                  |flow#1           `-.
               ,'                     |                   `.
              (             IP Network|                     )
               `.                     |                    ,'
                 `-.                  ;         +-----+  ,
                    ;-----.          ;  +------ | LM  |---+
                  ,'       `---------+--|-------+-----+   |
                 /                   |  |    flow#1       |
            +---'---+            +---:---+  tunnelled +-------+
            |  AR1  |            | AR2`--|------------|  AR3  |
            |MAG    |            |MAG    |------------|MAG    |
            +-------+            +-------+            +-------+
                                                    flow#1 `.
                                  +--`--+                    +-----+
                                  | MN  | ----move------->   | MN  |
                                  +-----+                    +-----+





Liu, et al.             Expires January 11, 2011               [Page 13]


Internet-Draft                     DMM                         July 2010


               Figure 5: Distributed Network Based Mobility


7.  Security Considerations

   TBD


8.  IANA Considerations

   None


9.  Contributors

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

      Bo Zhou
      China Mobile
      zhouboyj@chinamobile.com

      Philippe Bertin
      France Telecom - Orange
      philippe.bertin@orange-ftgroup.com


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]
              Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
              Basic Support", draft-ietf-mext-flow-binding-06 (work in
              progress), March 2010.




Liu, et al.             Expires January 11, 2011               [Page 14]


Internet-Draft                     DMM                         July 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",
              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.

   [TR23.261]
              3GPP, "IP Flow Mobility and seamless WLAN offload", 2010.


Authors' Addresses

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

   Email: liudapeng@chinamobile.com


   Zhen Cao
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: caozhen@chinamobile.com










Liu, et al.             Expires January 11, 2011               [Page 15]


Internet-Draft                     DMM                         July 2010


   Pierrick Seite
   France Telecom - Orange
   4, rue du clos courtel, BP 91226
   Cesson-Sevigne 35512
   France

   Email: pierrick.seite@orange-ftgroup.com


   H Anthony Chan
   Huawei Technologies
   1700 Alma Ave
   Plano, TX 75075
   USA

   Email: anthonychan@huawei.com



































Liu, et al.             Expires January 11, 2011               [Page 16]


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