The DMM design team consisting of people from initially 8 (and later more) 
major operators and vendors had worked on DMM from over a year ago. It was also 
open to anyone and had later been joined by more people from more both industry 
and academia. In the past, the activities from this team (such as dmm 
discussion group and a couple of dmm meetings in Prague and in Quebec City) had 
been considered individual activities not part of the mext WG. As the mext WG 
is now re-chartered into DMM WG and has used the charter statement from the 
team as candidate input to the re-charter statement, is it reasonable to 
consider incorporating the work from this team into the DMM WG? It is of cause 
open to more suggestions and inputs from anyone as it had always been in the 
past.

The following 2 documents were the initial outputs from the team:
Problem statement: draft-chan-distributed-mobility-ps-
Use cases: draft-yokota-dmm-scenario-00
and a charter statement

The majority of the charter statement can be found in the introduction charter 
of the above problem statement from over a year ago.
This charter statement from this team is now being used by Jari as input to the 
re-charter to the WG.

In the last dmm meeting in July, work had already started in drafting the 
requirements, and an initial draft has also been produced in one session of the 
above ps draft, which had taken the discussions into account and had closely 
relate the requirements to address the problem statements.

In addition, the contents from the above documents had largely been used and 
improved in the following journal paper so that they had also been reviewed 
through the journal publication process:

"Distributed and Dynamic Mobility Management in Mobile Internet: Current 
Approaches and Issues," Journal of Communications, vol. 6, no. 1, pp. 4-15, Feb 
2011.

I especially point out the above because they are the team work of many people 
resulting from a lot of efforts as well as using extensive discussions in 
emails (design team and then dmm mailing list) and in meetings.

I have not mentioned many other drafts on dmm from many other authors here.

Also, the earlier discussions in the dmm mailing list had caused the mext WG to 
not hold mext meeting in Quebec City with the reason that there was not enough 
interest in dmm. If the mext WG is to rename to dmm WG, are we going to use the 
dmm mailing list in future?

H Anthony Chan, Fellow IEEE

From: [email protected] [mailto:[email protected]] On Behalf Of Jari 
Arkko
Sent: Friday, October 28, 2011 8:21 PM
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

Reply via email to