Basavaraj,
It is a recharter (and a rename). We are not considering taking on significant
amount of new work (mostly just removing material from the charter), so I do
not think a BOF is needed.
There has been little need to do work on the other extensions, and slow
progress with the specifications that do exist. I think we completed the work
that was easy to do and had demand. I think we should leave the rest behind. As
noted in the other e-mails, I can AD sponsors docs outside the WGs directly to
RFC. If there's something big that requires WG discussion, we can always create
new working groups later. For instance, if after some time the various security
alternates get enough traction, we could consider creating a working group to
standardize one.
Jari
On 31.10.2011 22:35, [email protected] wrote:
Okay..
Then I would hope that the rechartering does not throw out "the baby with the
bathwater" and keep MIP6/DSMIP6 related extensions and features still in scope.
-Raj
-----Original Message-----
From: ext Julien Laganier [mailto:[email protected]]
Sent: Monday, October 31, 2011 3:33 PM
To: Patil Basavaraj (Nokia-CIC/Dallas)
Cc: [email protected]; [email protected]
Subject: Re: [MEXT] the future of the MEXT working group
Hi Raj,
This is a rechartering of the WG.
--julien
On Mon, Oct 31, 2011 at 7:47 AM,<[email protected]> wrote:
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: [email protected] [mailto:[email protected]] On Behalf
Of ext Jari Arkko
Sent: Friday, October 28, 2011 7:21 AM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
