Subject: Re: [dmm] DMM BOF

From: liu dapeng <[email-masked]>
Date: Fri, 15 Oct 2010 17:46:24 +0800

Hi Jari,

Sorry for the late response. we are working on the PS/Scenario drafts
and the work plan those days.

First of all, thanks a lot for the suggestions. we have several points
to clarify:

1. Regarding the motivation of Distributed and Dynamic Mobility Management:
  As you mentioned, Mobile IP is not widely deployed in real life but
3GPP has specified IP based mobility protocol in IWLAN and SAE. Many
operators are considering to deploy IWLAN and SAE today. Regarding the
flat network architecture evolution, many operators are also very
interested, the reason is that it can provide flexible ways to offload
user's Internet traffic and save the backbone cost. That is why we
have four operators (France Telecom, KDDI, Telecom Italy, China
Mobile) who are very actively involved in this DDMM work. Also, in
3GPP, people are working on the SIPTO/LIPA architecture; So in that
sense, the flat architecture is becoming reality.

Specially, the motivation comes from many aspects:

Existing mobile networks are hierarchical, and existing mobility
solutions deployed with centralized mobility anchoring are more prone
to the following problems or limitations compared with distributed and
dynamic mobility management:

   (1) Routing via a centralized anchor is often longer, so that those
mobility protocol deployments that lack optimization extensions
results in non-optimal routes, affecting performance; whereas routing
optimization may be an integral part of in a distributed design.
   (2) As mobile network becomes more flattened centralized mobility
management, which is currently deployed to support hierarchical
network, can become more non-optimal, especially  as the content
servers in a content delivery network (CDN) are moving closer to the
access network; in contrast, distributed mobility management can
support both hierarchical network and more flattened network as it
also supports CDN networks.
   (3) Centralized route maintenance and context maintenance for a
large number of mobile hosts is more difficult to scale.
   (4) Scalability may worsen if mobility support is provided to all
mobile hosts without mechanism to distinguish whether there are real
need; dynamic mobility management, i.e., to selectively provide
mobility support, is needed and may be better implemented with
distributed mobility management.
  (5) Deployment is sophisticated with the numerous variants and extensions
   of mobile IP; better integration of these variants and extensions may
   be found in a distributed and dynamic design which can selectively
   adapt to the needs.
  (6) Excessive signaling overhead should be avoided when end nodes
are able to communicate end-to-end; capability to selectively turn off
unwanted signaling will reduce the handover delay.
  (7) Centralized approach is generally more vulnerable to a single
point of failure and attack often requiring duplication and backups,
whereas a distributed approach intrinsically mitigates the problem to
a local network so that the needed protection can be simpler.

2. Regarding the scope and plan of Distributed and Dynamic Mobility
Management, we have the following initial thoughts:

1) 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.
2) Produce a gap analysis mapping the above requirements against
existing solutions.
3) Give best practices for the deployment of existing mobility
protocols in a distributed mobility management and describe
limitations of each such approach.
4) Describe extensions, if needed, to current mobility protocols for
their application in distributed mobility architectures

We are considering both network based and MN based mobility protocols,
and we are also considering a better integration of
{MIP/PMIP/FMIP/HMIP/AMIP/BMIP/CMIP/.../ZMIP} in the " mixed flat"
architecture (there may not be a "totally flat" architecture but maybe
a " mixed architecture" which may have both centralized anchors for
the operator's own service and local anchors for the Internet access
service; better integration of different variants of mobile IP in that
scenario is needed.). Considering that, we think DDMM  may be outside
the scope of MEXT which is focus on extensions of DSMIP.

Best Regards,
Dapeng Liu

2010/9/29, Jari Arkko <[email-masked]>:
> Folks,
>
> There will not be a separate DMM BOF at IETF-79. However, we have
> reserved time in the MEXT meeting to discuss this topic.
>
> In order to make that discussion most fruitful, here's some further
> guidance on how you should scope the discussion and what you should be
> working on before the meeting. The original BOF description had two
> parts, one that focused on operational advice on how to use existing
> protocols in as "flat" network model as possible, and another part which
> focused on creating new solutions. I think there are good technical
> reasons why a distributed model is interesting: potentially more shorter
> paths, elimination of overhead for non-moving nodes, less reliance on
> central nodes, etc. However, at this stage I do not yet see wide-spread
> demand for a completely new architecture, and I must confess that I'm
> not entirely happy about the deployment success of any IETF mobility
> solutions. So some care is needed so that we do not jump into creating
> new solutions without solid demand. However, I do recognize that a lot
> could be done within the existing frameworks. In particular, I would be
> interested in seeing how Mobile IP-based architecture can be used in a
> distributed manner. For instance, home agents could perhaps run more in
> the network edge devices than on some central nodes, helping eliminate
> unnecessary mobility signaling and tunnels for the many cases where the
> hosts are actually still in the area served by the edge device. To do
> this we need to look at many aspects:
>
> - operational considerations of running home agent functionality on the
> edge devices
> - discovery and bootstrapping of the suitable home agent
> - using multiple home agents as you move around and retain sessions
> - ...
>
> Some of these items are operational, i.e., we only need to figure out
> how to use the existing protocols. Others may require protocol
> extensions. All of this should be in scope for the discussion at MEXT.
>
> Thoughts, comments?
>
> Jari
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>