Re: [dmm] DMM problem statement and scenario draft

liu dapeng <maxpassion@gmail.com> Thu, 28 October 2010 19:51 UTC

Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@core3.amsl.com
Delivered-To: dmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D593A695C for <dmm@core3.amsl.com>; Thu, 28 Oct 2010 12:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level:
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQoT3TBapbAf for <dmm@core3.amsl.com>; Thu, 28 Oct 2010 12:51:51 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id AFF9E3A6930 for <dmm@ietf.org>; Thu, 28 Oct 2010 12:51:51 -0700 (PDT)
Received: by pwj5 with SMTP id 5so323322pwj.31 for <dmm@ietf.org>; Thu, 28 Oct 2010 12:53:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6uv6fT6d7oQ/9sFpWDxAm4FWsAmX3J/5MZiaHe8ypnw=; b=XpyT1d5lgvc71KE9hTB49WnHrYY106O9PjqXoCTtKhMUMAPb2OgImp2Yk5ydyInN4n mE+5HIvZPuUrW6Vl654Ojcf/JtsBGGSsURj0AlhoSi1PU5/owUs3MBAiGWmBpvUKVI3I 4VQVty8l/yXZKDQK1QuEN0U6o10M/QPjShVhk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=igrcl2eAoTY89KcB2xPyZUfd0fUaMfJdDZDVI/6ce+JFN4FjTbzXN17cJJturpmh7y 1Mcvzynd4Unbwl9jyuiB0swwD6hT4lxUKBmDeL3mEWQaV5fe1bTHpP48WLSY9MuZN1SS VCCb4VXy+8DRzeLvRD+9JBRFzDpS/BtAfyEBY=
MIME-Version: 1.0
Received: by 10.142.116.15 with SMTP id o15mr602251wfc.12.1288295624248; Thu, 28 Oct 2010 12:53:44 -0700 (PDT)
Received: by 10.220.10.211 with HTTP; Thu, 28 Oct 2010 12:53:43 -0700 (PDT)
In-Reply-To: <4B844B535D73496AAE02496F486A4873@knucpl>
References: <AANLkTik+KcmCren3c9CckX8RJvxURhnQE6xXyRf1-LsA@mail.gmail.com> <4B844B535D73496AAE02496F486A4873@knucpl>
Date: Fri, 29 Oct 2010 03:53:43 +0800
Message-ID: <AANLkTikhkYhZWD8TcdPSBqTOiR2O7G27m0+daRahD78o@mail.gmail.com>
From: liu dapeng <maxpassion@gmail.com>
To: Seok Joo Koh <sjkoh@knu.ac.kr>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "charles.perkins" <charles.perkins@tellabs.com>, caozhen <caozhen@chinamobile.com>, MELIA TELEMACO <Telemaco.Melia@alcatel-lucent.com>, Wassim Haddad <wassim.haddad@ericsson.com>, dmm <dmm@ietf.org>, denghui02 <denghui02@hotmail.com>
Subject: Re: [dmm] DMM problem statement and scenario draft
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Distributed Mobility Management <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2010 19:51:53 -0000

Hi Seok,

Thanks for the comments,

2010/10/28, Seok Joo Koh <sjkoh@knu.ac.kr>:
> Thanks for sincere efforts.
>
> It seems that the initial drafts and the proposed WG charter will be a good
> triggering point toward
> DMM.
> The stepwise approach for design of DMM are also reasonable.
>
> Some comments are:
> 1) The design of DMM needs to be done in the viewpoint of (generic)
> Functiona Architecture,
> rather than based on specific protocols (MIP, PMIP), since  DMM may be used
> in the future
> emerging networks (not identified yet) as well as in the current MIP/PMIP
> networks.

Are you suggesting that DMM should not be extensions of current
protocols and need a totally new design?

> 2) At present, the main target network to DMM may be the LTE/SAE or 4G
> mobile networks.
> In the drafts, it is very helpful to describe the associated requirements
> and applicability
> statements.
>
> Hope to have useful discussion and decision in the upcoming IETF meeting.

You are welcomed to join the discussion.


Best regards,
Dapeng Liu

> Regards,
>
> *************************
> Seok Joo Koh
> sjkoh@knu.ac.kr
> http://protocol.knu.ac.kr/
>
>
> ----- Original Message -----
> From: "liu dapeng" <maxpassion@gmail.com>
> To: "dmm" <dmm@ietf.org>
> Cc: "charles.perkins" <charles.perkins@tellabs.com>; "caozhen"
> <caozhen@chinamobile.com>; "MELIA
> TELEMACO" <Telemaco.Melia@alcatel-lucent.com>; "Wassim Haddad"
> <wassim.haddad@ericsson.com>;
> "denghui02" <denghui02@hotmail.com>
> Sent: Tuesday, October 19, 2010 5:12 PM
> Subject: [dmm] DMM problem statement and scenario draft
>
>
> Hello all,
>
> After several weeks and many contributor's hard working, we finished
> DMM problem statement and scenario draft:
>
> http://tools.ietf.org/html/draft-chan-distributed-mobility-ps-00
> http://tools.ietf.org/html/draft-yokota-dmm-scenario-00
>
> Besides, we have the following introduction and initial work plan of DMM:
>
> -----------------------------------------------------------------------------------------------------
> Work plan proposal -- Distributed and Dynamic Mobility Management
> ==================================================
>
> In the past decade a fair number of mobility protocols have been
> standardized. Although the protocols differ in terms of functions and
> associated message format, we can identify a few key common features:
> •presence of a centralized mobility anchor providing global
> reachability and an always-on experience
> •extensions to optimize handover performance while users roam across
> wireless cells
> •extensions to enable the use of heterogeneous wireless interfaces for
> multi-mode terminals (e.g. cellular phones)
> The presence of the centralized mobility anchor allows a mobile device
> to be reachable when it is not connected to its home domain. The
> anchor, among other tasks, ensures forwarding of packets destined to
> or sent from the mobile device. As such, most of the deployed
> architectures today have a small number of centralized anchors
> managing the traffic of millions of mobile subscribers.
>
> To optimize handovers for mobile users, the base protocols have been
> extended to efficiently handle packet forwarding between the previous
> and new points of attachment. These extensions are necessary when
> applications impose stringent requirements in terms of delay. Notions
> of localization and distribution of local agents have been introduced
> to reduce signalling overhead. Unfortunately today we witness
> difficulties in getting such protocols deployed, often leading to
> sub-optimal choices. Moreover, all the availability of multi-mode
> devices and the possibility to use several network interfaces
> simultaneously have motivated the development of more new protocol
> extensions.
>
> Mobile users are, more than ever, consuming Internet content, and
> impose new requirements on mobile core networks for data traffic
> delivery. When this traffic demand exceeds available capacity, service
> providers need to implement new strategies such as selective traffic
> offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access
> networks (e.g. WLAN). Moreover, the localization of content providers
> closer to the Mobile/Fixed Internet Service Providers network requires
> taking into account local Content Delivery Networks (CDNs) while
> providing mobility services.
>
> As long as demand exceeds capactity, both offloading and CDN
> techniques could benefit from the development of more flat mobile
> architectures (i.e., fewer levels of routing hierarchy introduced into
> the data path by the mobility management system). This view is
> reinforced by the shift in users’ traffic behaviour, aimed at
> increasing direct communications among peers in the same geographical
> area. The development of truly flat mobile architectures would result
> in anchoring the traffic closer to point of attachment of the user and
> overcoming the suboptimal routing issues of a centralized mobility
> scheme.
>
> While deploying [1] today’s mobile networks, service providers face
> new challenges. More often than not, mobile devices remain attached to
> the same point of attachment, in which case specific IP mobility
> management support is not required for applications that launch and
> complete while connected to the same point of attachment. However, the
> mobility support has been designed to be always on and to maintain the
> context for each mobile subscriber as long as they are connected to
> the network. This can result in a waste of resources and
> ever-increasing costs for the service provider. Infrequent mobility
> and intelligence of many applications suggest that mobility can be
> provided dynamically, thus simplifying the context maintained in the
> different nodes of the mobile network.
>
> The proposed charter will address two complementary aspects of
> mobility management procedures: the distribution of mobility anchors
> to achieve a more flat design and the dynamic activation/deactivation
> of mobility protocol support as an enabler to distributed mobility
> management. The former has the goal of positioning mobility anchors
> (HA, LMA) closer to the user; ideally, these mobility anchors could be
> collocated with the first hop router. The latter, facilitated by the
> distribution of mobility anchors, aims at identifying when mobility
> must be activated and identifying sessions that do not impose mobility
> management -- thus reducing the amount of state information to be
> maintained in the various mobility anchors of the mobile network. The
> key idea is that dynamic mobility management relaxes some constraints
> while also repositioning mobility anchors; it avoids the establishment
> of non optimal tunnels between two anchors topologically distant.
>
> Considering the above, the working group will:
> •Define the problem statement and associated requirements for
> distributed mobility management. This work aims at defining the
> problem space and identifies the key functional requirements.
> •Produce a gap analysis mapping the above requirements against
> existing solutions.
> •Give best practices for the deployment of existing mobility protocols
> in a distributed mobility management and describe limitations of each
> such approach.
> •Describe extensions, if needed, to current mobility protocols for
> their application in distributed mobility architectures
>
> [1] G. Kirby, "Locating the User", Communication International, 1995
> ----------------------------------------------------------------------------------------------------
>
> Please feel free to comment. Thanks.
>
>
> Best Regards,
> Dapeng Liu
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>