Re: [MEXT] the future of the MEXT working group
liu dapeng <maxpassion@gmail.com> Fri, 04 November 2011 16:41 UTC
Return-Path: <maxpassion@gmail.com>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BA421F8AFE for <mext@ietfa.amsl.com>; Fri, 4 Nov 2011 09:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level:
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8igkZD7zd9C7 for <mext@ietfa.amsl.com>; Fri, 4 Nov 2011 09:41:42 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52721F8AE1 for <mext@ietf.org>; Fri, 4 Nov 2011 09:41:42 -0700 (PDT)
Received: by iaeo4 with SMTP id o4so3569029iae.31 for <mext@ietf.org>; Fri, 04 Nov 2011 09:41:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WI+Vv77rEDz4gT3eWCKZSEYmY8tN1R/Qscov7iZSvVE=; b=erxddeRAb1SNoy/zN4rMgd+Vq5jitQAZnUysIQtBPBzoP36mvS5no3gM8IUEJkX4rd zdNNLkp3MaEHptTaiByO3vEYgS1qj2mdr1tFQBy35Tg6a9pzIOJ3A0XxQQUZLFB8vrzL XVOIpS5ejF/7WyH1UCuxiN4XLrN4Kc2OwyP4c=
MIME-Version: 1.0
Received: by 10.42.147.72 with SMTP id m8mr17114811icv.56.1320424902312; Fri, 04 Nov 2011 09:41:42 -0700 (PDT)
Received: by 10.42.228.68 with HTTP; Fri, 4 Nov 2011 09:41:42 -0700 (PDT)
In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201FE517F@ftrdmel0.rd.francetelecom.fr>
References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <843DA8228A1BA74CA31FB4E111A5C46201FE517F@ftrdmel0.rd.francetelecom.fr>
Date: Sat, 05 Nov 2011 00:41:42 +0800
Message-ID: <CAKcc6AdVpSj4WgYRvr=jvMgyeMs59jQhfvdDMaZP-dYqtFPoZg@mail.gmail.com>
From: liu dapeng <maxpassion@gmail.com>
To: pierrick.seite@orange.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: jari.arkko@piuha.net, mext@ietf.org
Subject: Re: [MEXT] the future of the MEXT working group
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2011 16:41:43 -0000
Hi Pierrick, 2011/11/2, pierrick.seite@orange.com <pierrick.seite@orange.com>: > Hi Jari, > > > > Just a minor comment: > > > > This charter addresses both the distribution of mobility functions and the > dynamic mobility management. Even if dynamic activation/deactivation of > mobility support can be seen as an enabler to distributed mobility > management, I think the work item acronym should refer to both features. So, > to avoid any ambiguity, I'd suggest to use the acronym DDMM (Distributed and > Dynamic Mobility Management) for the work item. There is no contradiction between distributed and dynamic. Actually "dynamic mobility" could be considered as some sort of "distributed mobility". So I think DMM is a simple and concise acronym. Dapeng > > > Regards, > > Pierrick > > > > > > ________________________________ > > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de Jari > Arkko > Envoyé : vendredi 28 octobre 2011 14:21 > À : mext@ietf.org > Objet : Re: [MEXT] the future of the MEXT working group > > > > And a follow-up on the charter. I'm describing a couple of different takes > on what the new charter could be. Comments and alternative proposals are > welcome. This is what the current charter says about DMM: > > > > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol mechanisms > to select the closest home agents for new clients. > > Oct 2011 - Submit I-D 'Operational considerations for distributed use of > Mobile IPv6' for publication as Informational. > > > Which is admittedly a bit short, but is also very concrete and achievable, > if we work on it. I got another proposal from Hui Deng that extended this a > bit, including going beyond mere operational considerations. > > > > > 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 capacity, 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 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 > > > Comments? > > Jari > > -- ------ Best Regards, Dapeng Liu
- Re: [MEXT] the future of the MEXT working group Jari Arkko
- [MEXT] the future of the MEXT working group Jari Arkko
- Re: [MEXT] the future of the MEXT working group Behcet Sarikaya
- Re: [MEXT] the future of the MEXT working group Hui Deng
- Re: [MEXT] the future of the MEXT working group Hesham Soliman
- Re: [MEXT] the future of the MEXT working group Basavaraj.Patil
- Re: [MEXT] the future of the MEXT working group Hui Deng
- Re: [MEXT] the future of the MEXT working group Ryuji Wakikawa
- Re: [MEXT] the future of the MEXT working group Basavaraj.Patil
- Re: [MEXT] the future of the MEXT working group Jari Arkko
- Re: [MEXT] the future of the MEXT working group Julien Laganier
- Re: [MEXT] the future of the MEXT working group Basavaraj.Patil
- Re: [MEXT] the future of the MEXT working group Jari Arkko
- Re: [MEXT] the future of the MEXT working group Basavaraj.Patil
- Re: [MEXT] the future of the MEXT working group Behcet Sarikaya
- Re: [MEXT] the future of the MEXT working group Ryuji Wakikawa
- Re: [MEXT] the future of the MEXT working group pierrick.seite
- Re: [MEXT] the future of the MEXT working group Charles E. Perkins
- Re: [MEXT] the future of the MEXT working group Thierry Ernst
- Re: [MEXT] the future of the MEXT working group jouni korhonen
- Re: [MEXT] the future of the MEXT working group Charles E. Perkins
- Re: [MEXT] the future of the MEXT working group Basavaraj.Patil
- Re: [MEXT] the future of the MEXT working group jouni korhonen
- Re: [MEXT] the future of the MEXT working group Hesham Soliman
- Re: [MEXT] the future of the MEXT working group Pete McCann
- Re: [MEXT] the future of the MEXT working group jouni korhonen
- Re: [MEXT] the future of the MEXT working group pierrick.seite
- Re: [MEXT] the future of the MEXT working group jouni korhonen
- Re: [MEXT] the future of the MEXT working group pierrick.seite
- Re: [MEXT] the future of the MEXT working group Basavaraj.Patil
- Re: [MEXT] the future of the MEXT working group Behcet Sarikaya
- Re: [MEXT] the future of the MEXT working group liu dapeng
- Re: [MEXT] the future of the MEXT working group Charles E. Perkins
- Re: [MEXT] the future of the MEXT working group Charles E. Perkins
- Re: [MEXT] the future of the MEXT working group Charles E. Perkins
- Re: [MEXT] the future of the MEXT working group Basavaraj.Patil
- Re: [MEXT] the future of the MEXT working group Hesham Soliman
- Re: [MEXT] the future of the MEXT working group Pete McCann
- Re: [MEXT] the future of the MEXT working group jouni korhonen
- Re: [MEXT] automotive reqs WG item (was: the futu… Alexandru Petrescu
- Re: [MEXT] automotive reqs WG item Thierry Ernst
- Re: [MEXT] automotive reqs WG item Alexandru Petrescu
- Re: [MEXT] the future of the MEXT working group pierrick.seite
- Re: [MEXT] automotive reqs WG item karagian
- Re: [MEXT] automotive reqs WG item Dirk.von-Hugo
- Re: [MEXT] automotive reqs WG item Basavaraj.Patil
- Re: [MEXT] automotive reqs WG item Charles E. Perkins
- Re: [MEXT] the future of the MEXT working group Hidetoshi Yokota
- Re: [MEXT] the future of the MEXT working group Charles E. Perkins
- Re: [MEXT] the future of the MEXT working group Hidetoshi Yokota
- Re: [MEXT] the future of the MEXT working group Hesham Soliman
- Re: [MEXT] the future of the MEXT working group liu dapeng
- Re: [MEXT] the future of the MEXT working group liu dapeng
- Re: [MEXT] the future of the MEXT working group jouni korhonen
- Re: [MEXT] the future of the MEXT working group h chan