[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Informational                                  P. Seite
Expires: April 21, 2011                          France Telecom - Orange
                                                              E. Demaria
                                                          Telecom Italia
                                                                  Z. Cao
                                                            China Mobile
                                                        October 18, 2010


         Use case scenarios for Distributed Mobility Management
                    draft-yokota-dmm-scenario-00.txt

Abstract

   This document explores applicability of Distributed Mobility
   Management (DMM) and use case scenarios for different parts of the
   mobile network.  DMM approaches and scenarios are divided into two
   cases: partially and fully distributed.  For each case, benefits and
   issues are provided.  It also refers to applicability of existing
   protocols and necessity of development of new protocols in order to
   provide a guideline for best suited solutions for the target
   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 April 22, 2011.

Copyright Notice

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



Yokota, et al.           Expires April 22, 2011                 [Page 1]


Internet-Draft                dmm-scenario                  October 2010


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.































Yokota, et al.           Expires April 22, 2011                 [Page 2]


Internet-Draft                dmm-scenario                  October 2010


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Applicable networks for DMM  . . . . . . . . . . . . . . . . .  6
     3.1.  Mobile core network  . . . . . . . . . . . . . . . . . . .  6
     3.2.  Access network . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Host to host . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Approaches for DMM . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Partially distributed approach . . . . . . . . . . . . . .  8
       4.1.1.  Control/data plane separation  . . . . . . . . . . . .  8
       4.1.2.  Dynamic mobility management  . . . . . . . . . . . . .  9
     4.2.  Fully distributed approach . . . . . . . . . . . . . . . . 10
       4.2.1.  P2P type of network (search and delivery)  . . . . . . 10
       4.2.2.  Broadcast/multicast type of network (multiple
               delivery)  . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Analysis for applicability . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Co-authors and Contributors  . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18



























Yokota, et al.           Expires April 22, 2011                 [Page 3]


Internet-Draft                dmm-scenario                  October 2010


1.  Requirements notation

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














































Yokota, et al.           Expires April 22, 2011                 [Page 4]


Internet-Draft                dmm-scenario                  October 2010


2.  Introduction

   Rich content applications, emergence of smart-phones, USB dongles and
   higher-speed radio access systems are all requiring an exorbitantly
   high capacity mobile network.  Mobility management has adopted a
   centralized and often hierarchical architecture, for example, Home
   Agent/Foreign Agent in Mobile IPv4[RFC3344], LMA/MAG in Proxy Mobile
   IPv6[RFC5213], GGSN/SGSN in GPRS, PDN GW/Serving GW in EPC.  However,
   in order to accommodate ever increasing mobile data traffic, more
   scalable and distributed architecture needs to be introduced.
   Existing mobility management protocols, which are designed for a
   centralized architecture, may need to be extended accordingly.  Based
   on the problem statement in [DMM-PS], this document explores
   applicability of distributed mobility management and use case
   scenarios to provide a guideline for best suited solutions.




































Yokota, et al.           Expires April 22, 2011                 [Page 5]


Internet-Draft                dmm-scenario                  October 2010


3.  Applicable networks for DMM

   Distributed mobility management can be applied at different parts of
   the mobile network.  This section introduces possible scenarios for
   introducing DMM.

       +----------+ +----------+     +----------+            \
       |  HA/LMA  | |  HA/LMA  | ... |  HA/LMA  | Core-level |
       +----+-----+ +-----+----+     +-----+----+            |
       _____|_____________|________________|_____            | Mobile
      (__________________________________________)            > Core
            |             |                |                 | Network
       +----+-----+ +-----+----+     +-----+----+            |
       | AR/FA/MAG| | AR/FA/MAG| ... | AR/FA/MAG| AR-level   |
       +----------+ +----------+     +----------+            /
       _____|_____________|________________|_____
      (__________________________________________)
          |       |       |           |                      \
       +--+--+ +--+--+ +--+--+     +--+--+                   |
       |  AP | |  AP | |  AP | ... |  AP |      Access-level  > Access
       +-----+ +-----+ +-----+     +-----+                   | Network
          |       |                   |                      /
         +--+    +--+                +--+
         |MH|--->|MH|                |MH|        Host-level
         +--+    +--+                +--+

                 Figure 1: Multiple level of distribution

3.1.  Mobile core network

   Conventional mobility management assumes a single mobility anchor per
   MH (e.g., home agent), which has been regarded as a negative aspect
   due to the cause of concentration of mobile data traffic and a single
   point of failure.  By topologically distributing mobility anchors,
   mobile hosts can be managed in a decentralized way and mobile data
   traffic can also be distributed ("Core-level" distribution in
   Figure 1).  If each mobility anchor covers specific geographical area
   and a mobile host crosses this boundary, change of the mobility
   anchor occurs, and this handover must be handled properly by, for
   example, transferring the binding information of the mobile host from
   the old to the new mobility anchor.  When different mobility anchors
   manage different blocks of IP addresses, packet delivery to/from the
   mobile host must also be assured after handover.

   If the mobile network adopts hierarchical architecture, such as home
   agent and foreign agent in Mobile IPv4 or local mobility anchor and
   mobile access gateway in PMIPv6, more flat architecture can be
   considered by confining the mobility management within a specific



Yokota, et al.           Expires April 22, 2011                 [Page 6]


Internet-Draft                dmm-scenario                  October 2010


   region and directly exchanging mobile data at a specific level of
   hierarchy ("AR-level" distribution in Figure 1).  The former approach
   is regarded as localized mobility management and the latter as route
   localization.  Several methods and protocols have been proposed, but
   no universal and self-contained protocol exists.  Moreover, there are
   different possibilities to distribute mobility functions.  The
   mobility anchors may be confined to the first access router; but less
   flat mobility architecture is also possible where a flatten mobility
   anchor is meant to anchor the traffic of several access routers.

3.2.  Access network

   Location of information content is getting distributed and closer to
   users.  Consumer Generated Media (CGM) contributed by end users can
   be innately located in a distributed manner.  Content Delivery
   Network, which has been constructed near the backbone network, is
   getting more distributed along with cache technology and closer to
   the access network for further efficient use of network resources.
   As a wireless access method, WiFi is rapidly prevailing and its
   access points are being more installed in residential and public
   areas.  As for the cellular system as well, picocell or femtocell are
   gaining higher attention for more efficient spectrum usage and data
   traffic offload (e.g., 3GPP LIPA/SIPTO).  These access nodes
   basically have layer 2 capability, but by adding layer 3 capability,
   they can handle IP-level mobility management working as, for example,
   a foreign agent or MAG ("Access-level" distribution in Figure 1).
   The same protocol can be applied as in Section 3.1, but the number of
   access nodes (i.e., WiFi APs or pico/femto-cells) is much larger to
   the home agent and more frequent handover is likely to happen.
   Therefore, scalability and signaling overhead need to be more
   carefully considered.

3.3.  Host to host

   This is more peer-to-peer approach, whereby once the corresponding
   host is found, both hosts directly communicate ("Host-level"
   distribution in Figure 1).  In order to discover the peer host,
   information server such as DNS is required in the network, which can
   be centralized or distributed.  While MIPv6[RFC3775] is not a peer-
   to-peer communication protocol, its route optimization mechanism can
   provide a host-to-host communication leveraging the home agent.










Yokota, et al.           Expires April 22, 2011                 [Page 7]


Internet-Draft                dmm-scenario                  October 2010


4.  Approaches for DMM

4.1.  Partially distributed approach

   Distributed approach can be applied partially (1) by considering the
   separation of control and data planes with taking advantage of
   differences in traffic volume or host behavior, and/or (2) by
   providing mobility only to the hosts who really need it, thereby
   saving resources for mobility management.

4.1.1.  Control/data plane separation

   Conventional mobility management protocols such as Mobile IP or Proxy
   Mobile IP combine the control and data planes, which means that all
   signaling packets and data packets go through the home agent or local
   mobility anchor (MIPv6 route optimization[RFC3775] is not
   considered).  The volume of data traffic is much higher than that of
   control traffic, so by separating the control and data planes and
   applying a distributed architecture to the data plane, effective
   traffic distribution can be achieved without reallocating mobility
   anchors during the session, as described in Section 3.1.  This
   simplifies the interaction between distributed mobility anchors
   (MAs), but new signaling between the control and data plane
   functional entities is required.

   A partially distributed mobility management is depicted in Figure 2.
   In this example, the routing function of the mobility anchor (MA) is
   confined with the access router, but less flat deployment is also
   possible (see Section 3.1).  If the mobile host attaches to MA1 and
   initiates an IP communication with a correspondent host (CH), the
   traffic will be anchored to MA1.  When performing handover to MA2,
   the control function updates the routing state of MA1 in order to
   forward packets to the new MH's location.  Registration update to the
   control function may be initiated by the host or controlled by the
   network.
















Yokota, et al.           Expires April 22, 2011                 [Page 8]


Internet-Draft                dmm-scenario                  October 2010


                   +----------+    Registration
                   |Control   |<-------------------+
                   | Function |------------------+ |
                   +----------+  Route Setup     | |
                    ^      |                     | |
                    Reg.   V                     V |
                 +--|-------+             data +---|------+
                 |  | *****************************|      |
                 |  | * MA1 |                  |  *| MA2  |
                 +--|-*-----+                  +--*|------+
                    | *                           *|
                   +|-*-+                        +*|--+
                   | MH |                        | MH |
                   +----+                        +----+

             Figure 2: Control/data plane separation scenario

4.1.2.  Dynamic mobility management

   If the mobile host is nomadic meaning once attached, rarely moved, or
   is idle in most of time, it should be enough to provide handover
   capability only when it is really needed.  This can save signaling
   traffic and resources for maintaining mobility bindings.  One
   scenario, which is depicted in Figure 3, is that the mobile host
   acquires an IP address (IP1) from the local access router (AR1) and
   when this mobile host moves to another network, this local access
   router plays a role of home agent to this mobile host and interacts
   with the access router (AR2) in the new network for continuous packet
   delivery.

   Communications newly initiated with IP2 while the mobile host is
   attached to AR2 will be routed in a standard way.  In other words,
   the mobile host plays with an IP flow to AR1 (the IP flow initiated
   while attached to AR1) and an IP flow via AR2.

   If the mobile node moves away from AR2, while maintaining
   communications, two mobility anchors will come into play: the data
   traffic will be anchored in AR1 for communication initiated via AR1
   and in AR2 for communication initiated via AR2.












Yokota, et al.           Expires April 22, 2011                 [Page 9]


Internet-Draft                dmm-scenario                  October 2010


                      data:IP1   +--------+
                    *************|        |  data:IP2
                    *  **********|   CH   |oooooooooo
                    *  *         +--------+         o
                    *->*                            o
                    *  *                            o
                 +--*--*----+                  +----o-----+
                 |  *  * AR1|  _______________ |    o  AR2|
                 |  *  *******)_______________)**** o     |
                 +--*-------+                  +--*-o-----+
                    *<--IP1                 IP1-->* o<--IP2
                   +*---+                        +*-o-+
                   | MH |      ------------->    | MH |
                   +----+                        +----+

                   Figure 3: Dynamic mobility management

   Dynamic mobility management can be combined with the approaches for
   control/data plane distribution considered in this document (i.e.,
   separation of control and data planes in Section 4.1.1 and fully
   distributed approach in Section 4.2).

4.2.  Fully distributed approach

   This section describes the distribution schemes applied to both
   control and data planes.  One of the most significant issues of the
   distributed control plane (e.g., distributed home agents), is that a
   special mechanism is needed to identify the mobility anchor that
   maintains the mobility binding of the mobile host.

   In a fully distributed mobility management, the routing and control
   functions of the mobility anchor (MA) are confined with an access
   router, but less flat deployment is also possible (see Section 3.1).
   If the mobile host attaches to a MA and initiates an IP communication
   with a correspondent node, the traffic will be anchored to this MA.
   When performing handover to another MA, this movement will be shared
   by these two MAs or all MAs or may be handled independently.  The
   previous MA can forward packets to the new MH's location with this
   information.  Registration update to the control function can be
   initiated by the host or controlled by the network.

   The following subsections provide clues to fully distributed mobility
   management schemes.

4.2.1.  P2P type of network (search and delivery)

   This approach searches for the correct mobility anchor before
   delivering packets.  Distributed Hash Table (DHT) is a popular



Yokota, et al.           Expires April 22, 2011                [Page 10]


Internet-Draft                dmm-scenario                  October 2010


   mechanism for its efficiency.  However, as the number of mobility
   anchors increases, the number of hops increases and the search time
   cannot be ignored.  Also, when the mobile host moves to another
   network, the location information needs to be updated and according
   to the search scenario, this information may need to be disseminated
   among distributed mobility anchors.  The user data can be
   continuously delivered to the MH in the new location by, for example,
   the new MA's searching for the old MA and getting data forwarded from
   it.

                               +----------+
                      Search   |          | Search
                    +--------->|    MA    |<-------+
                    |          +----------+        |
                    |                              |
                    V                              V
                 +----------+      Search      +----------+
                 |          |<---------------->|          |
                 |   MA****************************  MA   |
                 +--^--*----+      data        +--*-^-----+
                   Reg.*                          * |Reg.
                   +|--*+                        +*-|-+
                   | MH |                        | MH |
                   +----+                        +----+

                       Figure 4: P2P type of network

4.2.2.  Broadcast/multicast type of network (multiple delivery)

   In this approach, packets are delivered to all or multiple mobility
   anchors and only the corresponding mobility anchor delivers the
   packets to the mobile host.  This does not require the search
   mechanism and the signaling between MAs is not mandatory when the MH
   moves to a new location, but the use of the network resources is not
   efficient since the packets are multiply delivered.  This is
   effective and feasible in relatively limited areas; from local to
   metropolitan areas, but not suitable for the global area network.














Yokota, et al.           Expires April 22, 2011                [Page 11]


Internet-Draft                dmm-scenario                  October 2010


                 +----------+                  +----------+
                 |          |      data        |          |
                 |    MA    |    **************|    MA    |
                 +----------+    *             +----------+
                  data *         *
                       *         *
                 +-----*----+    *             +----------+
                 |     ***********             |          |
                 |   MA****************************  MA   |
                 +--^--*----+      data        +--*-^-----+
                   Reg.*                          * |Reg.
                   +|--*+                        +*-|-+
                   | MH |                        | MH |
                   +----+                        +----+

                      Figure 5: BC/MC type of network



































Yokota, et al.           Expires April 22, 2011                [Page 12]


Internet-Draft                dmm-scenario                  October 2010


5.  Analysis for applicability

   In the case where the current hierarchical mobile network
   architecture should be maintained, Core-level distribution is one
   scenario and a new protocol is needed to handle the reallocation of
   HA/LMA for an active session.  If a more flat architecture is
   desired, the role of the HA/LMA should be minimized and AR-level or
   Access-level distribution is a more preferred scenario.  Two
   scenarios can be envisaged: only the routing functions of mobility
   anchors can be distributed or the mobility management can be fully
   distributed, meaning that both the control and routing functions of
   mobility anchors are distributed closer to the access routers.  In
   the first scenario, the control/data plane separation is considered;
   in this case, a new protocol between the control functional entity,
   which maintains the mobility bindings, and the data functional
   entity, which routes data packets to the corresponding peer entity,
   is needed.

   Distributing the mobility anchor close to the access would lead to
   inter AR/MAG mobility.  In this case, inter-AR/MAG communications
   features of FMIPv4/v6[RFC4988][RFC5568] or PFMIPv6[RFC5949] can be
   used.  When PMIPv6 is used, Localized routing for PMIPv6[ID-PMIPv6LR]
   can be considered for direct routing between MAGs.  Note that the
   scenario where the LMAs are distributed is not included in this work.
   For Host-level distribution, MIPv6 route optimization mechanism can
   be a candidate to support this scenario.

   Distribution of mobility anchors facilitates the dynamic mobility
   management since IP flows can be individually anchored close to the
   access router on which the host was attached when initiating the IP
   communication.  Dynamic feature may not require specific support and
   existing mobility protocols could be used.  An example of fully
   distributed and dynamic mobility management is described in [ID-DMA].
   Depending on the mobility scenario, the mobile host may have two IP
   addresses: one for direct communication and another for mobility,
   which must be sustained before and after handover, in which case the
   mobile host needs to be capable of distinguishing them (with the help
   of the network).

   If fully distributed approach is sought, a mechanism to find the
   network node that holds the location of the mobile host needs to be
   clarified.  This document gives only clues for solutions but detailed
   work in the area is clearly needed.  The broadcast/multicast approach
   is a simpler scenario and may not require a specific signaling
   protocol This approach, however, will be more suitable for a limited
   scope of network; for example, campus network, metropolitan area
   network or data center network could benefit from this approach.




Yokota, et al.           Expires April 22, 2011                [Page 13]


Internet-Draft                dmm-scenario                  October 2010


6.  Security Considerations

   Security aspect is not considered in this document.
















































Yokota, et al.           Expires April 22, 2011                [Page 14]


Internet-Draft                dmm-scenario                  October 2010


7.  IANA Considerations

   This specification does not require any IANA Actions.
















































Yokota, et al.           Expires April 22, 2011                [Page 15]


Internet-Draft                dmm-scenario                  October 2010


8.  Co-authors and Contributors

   This document is a joint effort by the following participants as well
   as those on the authors' list.  Each individual has made significant
   contributions to this work.

      Dapeng Liu: liudapeng@chinamobile.com

      H. Anthony Chan: h.a.chan@ieee.org

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

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

      Hui Deng: denghui@chinamobile.com

      Wassim Haddad: Wassam.Haddad@ericsson.com


































Yokota, et al.           Expires April 22, 2011                [Page 16]


Internet-Draft                dmm-scenario                  October 2010


9.  References

9.1.  Normative References

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

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

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

   [RFC5568]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

   [RFC4988]  Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
              RFC 4988, October 2007.

   [RFC5949]  Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
              September 2010.

9.2.  Informative References

   [DMM-PS]   Chan, H., Ed., "Problem statement for distributed and
              dynamic mobility management",
               draft-chan-distributed-mobility-ps-00, October 2010.

   [ID-DMA]   Seite, P., Ed. and P. Bertin, "Dynamic Mobility
              Anchoring",  draft-seite-netext-dma-00.txt , March 2010.

   [ID-PMIPv6LR]
              Krishnan, S., Ed., "Localized Routing for Proxy Mobile
              IPv6",  draft-krishnan-netext-pmip-lr-02 , July 2010.













Yokota, et al.           Expires April 22, 2011                [Page 17]


Internet-Draft                dmm-scenario                  October 2010


Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   Japan

   Email: yokota@kddilabs.jp


   Pierrick Seite
   France Telecom - Orange
   4, rue du Clos Courtel, BP 91226
   Cesson-Sevigne  35512
   France

   Email: pierrick.seite@orange-ftgroup.com


   Elena Demaria
   Telecom Italia
   via G. Reiss Romoli, 274
   TORINO,   10148
   Italy

   Email: elena.demaria@telecomitalia.it


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

   Email: zehn.cao@gmail.com















Yokota, et al.           Expires April 22, 2011                [Page 18]


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