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

Hui Deng <denghui02@gmail.com> Mon, 31 October 2011 16:00 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 921FC1F0C6C for <mext@ietfa.amsl.com>; Mon, 31 Oct 2011 09:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.134
X-Spam-Level:
X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=0.149, 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 XypOMSKz1bGH for <mext@ietfa.amsl.com>; Mon, 31 Oct 2011 09:00:12 -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 CB7DD21F8E29 for <mext@ietf.org>; Mon, 31 Oct 2011 09:00:09 -0700 (PDT)
Received: by wyg30 with SMTP id 30so1432612wyg.31 for <mext@ietf.org>; Mon, 31 Oct 2011 09:00:08 -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=g3Ifh5akObtNMR8OEHFeX1Syh3vguJNBtwV7YlCydLw=; b=Ji84JshRLToYLEfq1Ga9xt7TeY2MCAYQGNLc284FkT9EQQTqr0T/qiSIcLC2fabOyi 7Zw/SUNjbHOtvc6gJHP1x5/yTkZ1z8g4raaoiFTnKex/u69C5swGDHxG0GWJ7tJpJN9Q xF01jqbUARGEKGtCUSZVNyXlQHs7Ba/GN/CEk=
MIME-Version: 1.0
Received: by 10.216.133.86 with SMTP id p64mr4476977wei.95.1320076808237; Mon, 31 Oct 2011 09:00:08 -0700 (PDT)
Received: by 10.216.22.137 with HTTP; Mon, 31 Oct 2011 09:00:08 -0700 (PDT)
In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com>
References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com>
Date: Tue, 01 Nov 2011 00:00:08 +0800
Message-ID: <CANF0JMBKq3oM+U=hwr_ag5UeZ=erUk7gkRCZ0Rc2qmdnedCWEw@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: Basavaraj.Patil@nokia.com
Content-Type: multipart/alternative; boundary="0016e6de17d43b34ce04b09a55de"
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: Mon, 31 Oct 2011 16:00:15 -0000

Hi Raj,

>From my reading of the AD's email,
1. DMM has been already in mext charter before, I don't see why we need BOF
process, it is just about rechartering.
2. AD has already said that other left work could be sponsored by AD, so it
doesn't kick out any extension of MIP6/DSMIP6 if there is.

Thanks

-Hui

2011/10/31 <Basavaraj.Patil@nokia.com>

>  ** **
>
> Hi Jari,****
>
> ** **
>
> A couple of quick questions:****
>
> ** **
>
> **1.       **Is this a recharter of the MEXT WG or the formation of a new
> WG to deal with DMM? If it is the latter I would be concerned that a WG is
> being formed without going through the IETF BoF process. I realize that DMM
> was in the scope of the MEXT WG. But proposed new charter pretty much
> throws everything else w.r.t MIP6/DSMIP6 out of this new WG.****
>
> **2.       **There needs to be a WG and home for continued work w.r.t
> improvements to MIP6/DSMIP6 protocol in terms of extensions, deployability
> improvements etc. The proposed charter does not consider this at all.****
>
> ** **
>
> -Basavaraj****
>
> ** **
>
> *From:* mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On Behalf
> Of *ext Jari Arkko
> *Sent:* Friday, October 28, 2011 7:21 AM
> *To:* mext@ietf.org
> *Subject:* 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****
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
>