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 > >
- [dmm] DMM problem statement and scenario draft liu dapeng
- Re: [dmm] DMM problem statement and scenario draft Seok Joo Koh
- [dmm] 答复: Re: DMM problem statement and scenario … song.jun
- Re: [dmm] 答复: Re: DMM problem statement and scena… Sri Gundavelli (sgundave)
- Re: [dmm] DMM problem statement and scenario draft liu dapeng
- [dmm] 答复: RE: 答复: Re: DMM problem statement and s… song.jun