Re: [MEXT] the future of the MEXT working group

Hui Deng <denghui02@gmail.com> Fri, 28 October 2011 17:51 UTC

Return-Path: <denghui02@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 C210C11E808B for <mext@ietfa.amsl.com>; Fri, 28 Oct 2011 10:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.441
X-Spam-Level:
X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
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 cy9NET1OXC6T for <mext@ietfa.amsl.com>; Fri, 28 Oct 2011 10:51:40 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12411E8089 for <mext@ietf.org>; Fri, 28 Oct 2011 10:51:40 -0700 (PDT)
Received: by wyh22 with SMTP id 22so4919469wyh.31 for <mext@ietf.org>; Fri, 28 Oct 2011 10:51:39 -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; bh=Tuw/qgSsqH+GF2pFSbZrIBhmKNKwtUo7Sxzt0KE52i8=; b=SoaWZTh25dxTsJPE9iYQ7aqn2hPIisfxEqu93qJnh3TeYQXykTm4x3Zsee+Pa0j0cW +v9cH3xtfteqvscG3OqPjMy7zzEgSt8OQMJGW4Aa92znYsi9n8sHDcroa19dci44odyd NZeDgbhmdr38UYXP4JyK1UVJTUKH4HcY9vAn8=
MIME-Version: 1.0
Received: by 10.216.205.159 with SMTP id j31mr1223588weo.80.1319824298790; Fri, 28 Oct 2011 10:51:38 -0700 (PDT)
Received: by 10.216.82.199 with HTTP; Fri, 28 Oct 2011 10:51:38 -0700 (PDT)
In-Reply-To: <4EAA9E34.2080903@piuha.net>
References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net>
Date: Sat, 29 Oct 2011 01:51:38 +0800
Message-ID: <CANF0JMB8-sKr1+pONEL69rvsvh8Amfn-62-d-wguXQtUY6R+cg@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/alternative; boundary="0016e6dd8a2e7ed28204b05f8a63"
Cc: "mext@ietf.org" <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, 28 Oct 2011 17:51:41 -0000

I just want to mention that the proposal coming from DMM Interesting group
which is orginally organized by Dapeng Liu and other contributors all
together.

-Hui



2011/10/28 Jari Arkko <jari.arkko@piuha.net>

> 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
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
>