Internet DRAFT - draft-jiang-dmm-ps

draft-jiang-dmm-ps



 



INTERNET-DRAFT                                                  H. Jiang
Intended Status: Proposed Standard                   Huawei Technologies
Expires: December 31, 2012                                 June 29, 2012


         Problem statement for distributed mobility management 
                         draft-jiang-dmm-ps-00


Abstract

   Due to the limitation of sub-optimal routing, reliability and
   scalability problems in the centralized mobility management approach,
   distributed mobility management approaches are developed to resolve
   those problems. However, the proposed distributed mobility management
   approaches also bring some new problems. This document mainly
   introduces two kinds of approaches classified by the control plane
   management mode and proposes the new problems should be resolved in
   the future.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

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

 


H. Jiang                Expires January 1, 2013                 [Page 1]

INTERNET DRAFT           Problem State for DMM             June 30, 2012


   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. Requirements and Terminology  . . . . . . . . . . . . . . . . .  3
     2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  DMM overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1 F-DMM solution . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2 P-DMM solution . . . . . . . . . . . . . . . . . . . . . . .  4
   4  Problem statement . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1 Signaling costs  . . . . . . . . . . . . . . . . . . . . . .  5
     4.2 Resource utilization . . . . . . . . . . . . . . . . . . . .  5
     4.3 Deployment problem . . . . . . . . . . . . . . . . . . . . .  6
     4.4 Multihoming support  . . . . . . . . . . . . . . . . . . . .  6
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   5  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     6.1  Normative References  . . . . . . . . . . . . . . . . . . .  6
     6.2  Informative References  . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
















 


H. Jiang                Expires January 1, 2013                 [Page 2]

INTERNET DRAFT           Problem State for DMM             June 30, 2012


1. Introduction

   With the development of the mobile communication technologies, the
   number of mobile subscribers is growing year by year with the result
   that the amount of data traffic generated by them is experiencing a
   huge growth, and the future traffic amount is unpredictable. More and
   more users prefer to user mobile phones and tablet to obtain data
   information through wireless technologies. In the meanwhile more and
   more mobile Internet applications designed for handheld mobile
   terminals have already attracted the attention of most mobile users. 

   In order to supply the perfect user experiences for those mobile
   subscribers to increase the acceptance, the mobile operators SHOULD
   adopt the suitable protocols or architecture to management those huge
   number of mobile terminals. Thus IETF have proposed some standards to
   deal with the mobility management problems for mobile nodes. Typical
   protocols include Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6).
   These protocols generally utilize the mobility anchor to handle the
   management operations. Thus the key point for those approaches is
   based on the centralized theory. However, the centralized approach
   has several drawbacks such as sub-optimal routing, scalability
   problem, reliability problem and so on.

   For overcoming the drawbacks of the centralized mobility management
   approaches, the new approach SHOULD be distributed and never utilizes
   a central management point to deliver the control and data packets.
   Thus the IETF researchers begin to discuss the requirements and
   propose the solutions. Then the proposed solutions can be divided
   into two kinds: fully distributed and partially distributed. The main
   difference is whether the control plane is distributed or
   centralized.

   However, as other already deployed mobility management protocols,
   whether the fully distributed mobility management protocols or the
   partially distributed mobility management protocols are not perfect
   and with some limitations had to be considered and resolved. So this
   document analyzes the model of distributed mobility management and
   proposes some problems in the deployment situation.



2. Requirements and Terminology

2.1 Requirements

   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 RFC 2119 [RFC2119].
 


H. Jiang                Expires January 1, 2013                 [Page 3]

INTERNET DRAFT           Problem State for DMM             June 30, 2012


2.2 Terminology

   In addition to the terminology defined in [RFC5213], the following
   terminology is also used:

   DMM: Distributed Mobility Management

   F-DMM: Fully Distributed Mobility Management

   P-DMM: Partially Distributed Mobility Management

   NME: Network Management Entity is an access router and allocates the
   prefix for MN which attaching to it. It can be used to exchange
   messages for MN to complete the mobility management.

   CCE: Central Control Entity is a central control unit used to manage
   the location and other information for MN in P-DMM.



3.  DMM overview

   As mentioned above, Distributed Mobility Management (DMM) can be
   divided as follows:

3.1 F-DMM solution

   In F-DMM solution, Network Management Entity (NME) which achieves the
   mobility management is an access router with the function of anchor.
   It takes the role of LMA and MAG as in PMIPv6. So when MN attaches
   the NME1, NME1 advertises the prefix for MN to configure the IP
   address. When MN moves to attach NEM2, NEM2 will advertise the new
   prefix to MN and sends a PBU message to NME1. After receiving the
   reply PBA message, NME1 will create a tunnel with NME2. So the
   traffic transmitted by NME1 will be forwarded to NME2 so as to reach
   MN. And so on, the tunnels will be created with the MN's moving
   situation.


3.2 P-DMM solution

   In P-DMM solution, the Central Control Entity (CCE) is used to
   execute the control signaling interaction and manage the statement of
   the MN. CCE achieves the control functions as LMA in PMIPv6. When MN
   connects to NME1, NME1 advertises the prefix for MN to configure the
   IP address. NME1 sends a PBU message to CCE. Then CCE replies a PBA
   message to confirm the new registration. When MN moves to NME2, it
   gets a new prefix. NME2 sends a PBU to CCE for registration. By
 


H. Jiang                Expires January 1, 2013                 [Page 4]

INTERNET DRAFT           Problem State for DMM             June 30, 2012


   searching the BCE table, CCE gets former location information of MN
   and sends PBU messages to those NMEs. After receiving PBU message,
   NME1 will send a PBA message to CCE to confirm and another PBA to
   NME2. Then the tunnel will be created between NME1 and NME2. So the
   traffic transmitted by NME1 will be forwarded to NME2 so as to reach
   MN. And so on, the tunnels will be created with the MN's moving
   situation.


4  Problem statement

   Although DMM approaches solve some problems caused by centralized
   mobility management approaches, it also brings some new challenges
   which SHOULD be resolved for the real large scale business
   deployment.


4.1 Signaling costs

   Signaling cost is measurement criteria to evaluate the mobility
   management approach. In F-DMM solution, because the control plane is
   also distributed, the way NME to verify if the attachment of MN is
   fresh is to send PBU messages to other NMEs. Apparently, in a large
   scale network with lots of NMEs, it will cost too much signaling to
   get this information. Otherwise, the new solution SHOULD be proposed
   to alleviate the signaling cost. In P-DMM solution, When NME sends a
   PBU message to CCE after a MN attachment, CCE will sends PBA messages
   to all NMEs in the local area to obtain the PBA reply. This cost is
   very large if the network domain is large and with many NEMs. For
   example, if the MN is moving in a city to get service, then the PBA
   messages costs are expensive.


4.2 Resource utilization

   In both of two DMM approaches, how to manage the network resource is
   also important. Each time when MN attaches to a new NME, it will
   create a new tunnel between the new NME and previous NME after the
   registration. So when MN keeps on moving in the large network area
   and frequently attaching to different NME, then there are many
   tunnels between those NEMs. The problem is that most of those tunnels
   will be idle after the moving, so it is unnecessary to keep the
   mobility session for those cases. Moreover, the number of NMEs
   involves the mobility session will increase and become very large. So
   Removing some NMEs which MAY not be used such as having long distance
   with the latest location of MN.


 


H. Jiang                Expires January 1, 2013                 [Page 5]

INTERNET DRAFT           Problem State for DMM             June 30, 2012


4.3 Deployment problem

   Whether F-DMM or P-DMM, how to deploy the network architecture is a
   head-scratching puzzlement. For F-DMM, the deployment of NMEs depends
   on the network area that MN locating. For P-DMM, the location of CCE
   is also troublesome. Moreover, CCE also will cause the single point
   failure problem. So it only can be used in small area or localized
   moving cases. In large area network, mobile operators SLOULD deploy
   many CCEs to keep synchronization so as to manage the mobility of MN
   conveniently and save the long distance network cost.


4.4 Multihoming support

   Up to now, the proposed DMM solutions in IETF have not talking about
   the multihoming support for MN. All solutions are just assuming that
   MN connects to the network by one interface. So when MN moving, the
   mobility handover and session maintaining is very clearly and easy to
   achieve. However, in multihoming scenario, how to keep the mobility
   session well when one interface of MN moving while other interfaces
   remain unchanged is also unclear. 


5  Security Considerations

   None

5  IANA Considerations

   None

6  References

6.1  Normative References



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


6.2  Informative References

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

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


H. Jiang                Expires January 1, 2013                 [Page 6]

INTERNET DRAFT           Problem State for DMM             June 30, 2012


   [I-D.yokota-dmm-scenario] Yokota, H., Seite, P., Demaria, E., and Z.
              Cao, "Use case scenarios  for Distributed Mobility
              Management",draft-yokota-dmm-scenario-00 (expired),
              October 2010.

   [Paper-Distributed.Centralized.Mobility] Fabio, G., Antonio, O.,
              Carlos J. Bernardos and Rui, Costa. ,"A Network-based
              Localized Mobility Solution for Distributed Mobility
              Management", Proceedings of International Workshop on
              Mobility Management for Flat Networks (MMFN 2011).



Authors' Addresses


              Haisheng Jiang
              Huawei Building, No.156 Beiqing Rd.
              Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 
              Beijing 100095 P.R. China


              EMail: haisheng.jiang@huawei.com




























H. Jiang                Expires January 1, 2013                 [Page 7]