[dmm] 答复: Re: DMM problem statement and scenario draft

song.jun@zte.com.cn Thu, 28 October 2010 06:21 UTC

Return-Path: <song.jun@zte.com.cn>
X-Original-To: dmm@core3.amsl.com
Delivered-To: dmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135A13A6866; Wed, 27 Oct 2010 23:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.794
X-Spam-Level:
X-Spam-Status: No, score=-95.794 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGOF6ZpN-45D; Wed, 27 Oct 2010 23:21:20 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4AFC93A67D3; Wed, 27 Oct 2010 23:20:49 -0700 (PDT)
Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102143612382; Thu, 28 Oct 2010 14:21:14 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.10505633281; Thu, 28 Oct 2010 14:16:42 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9S6FJuU033754; Thu, 28 Oct 2010 14:15:23 +0800 (CST) (envelope-from song.jun@zte.com.cn)
In-Reply-To: <4B844B535D73496AAE02496F486A4873@knucpl>
To: Seok Joo Koh <sjkoh@knu.ac.kr>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFC9E9C19C.F80CC391-ON482577CA.00214D99-482577CA.0022563A@zte.com.cn>
From: song.jun@zte.com.cn
Date: Thu, 28 Oct 2010 14:15:10 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-28 14:15:11, Serialize complete at 2010-10-28 14:15:11
Content-Type: multipart/alternative; boundary="=_alternative 00225637482577CA_="
X-MAIL: mse2.zte.com.cn o9S6FJuU033754
Cc: "charles.perkins" <charles.perkins@tellabs.com>, caozhen <caozhen@chinamobile.com>, MELIA TELEMACO <Telemaco.Melia@alcatel-lucent.com>, Wassim Haddad <wassim.haddad@ericsson.com>, dmm <dmm@ietf.org>, denghui02 <denghui02@hotmail.com>, dmm-bounces@ietf.org
Subject: [dmm] 答复: Re: DMM problem statement and scenario draft
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Distributed Mobility Management <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2010 06:21:53 -0000

Hi, All
 
We have read the posted DMM draft and scenario drat, it is interesting. 
We'd like to support this work since we have the same vision on the next 
generation of mobility management . We also write a PS draft, here are 
some text from that document, we hope it could be helpful:
 
Analysis of existing mobility solutions

MIPv6 and PMIPv6 are typical mobility management solutions, presenting 
host based and network based solutions respectively.

MIPv6
There are some problems in MIPv6, even though it has the solution 
supporting routing optimization.

1) MIPv6 can not be supported by legacy terminals
It is difficult for the operators to control the terminals' upgrading. So 
the MIPv6-based solution is hard to be promoted and deployed.

2) Routing optimization needs supporting by the communication peers
MIPv6 is independent of the fixed terminals, and is not mandated for the 
3GPP mobile UE. These terminals occupy more than 90 percent in all 
terminals. So the routing optimization solutions can not be applied in the 
most scenarios.

3) Terminal load maybe burst during the handover when P2MP application is 
active.
During a P2MP application, e.g. conference call, or download application 
using P2P,  the terminal is always in heavy load. When handover occurs, 
the route optimization procedure leads to a burst load, and cause service 
interruption or signaling processing block.


PMIPv6
In the case of PMIPv6, the UE is unaware of the handover, and the 
deployment is simple. However, routing optimization solution is not 
specified, thus the traffic tromboning is a major problem.
Either for the centralized anchor point or for the flatten anchor point, 
the traffic tromboning problem always exists.
In the case of centralized anchor point, the level of the anchor gateway 
is higher, and the gateway becomes the bottleneck in performance. 
Furthermore, the situation is even worse if some value-added services are 
applied in the anchor gateway, e.g. content-based accounting.
In the case of flatten anchor point, the level of the anchor gateway is 
lower. Handover occurs frequently, and traffic tromboning is serious. As a 
result, the link resource wasting and the traffic delay would be greatly 
increased.
GTP based solution has the same problem of PMIP.

Best regards!

~·~·~·~·~·~·~·~·~·~·~·~·~
SONG Jun,  Ph.D.

Center R&D, ZTE Corporation
Email: song.jun@zte.com.cn
~·~·~·~·~·~·~·~·~·~·~·~·~



"Seok Joo Koh" <sjkoh@knu.ac.kr> 
发件人:  dmm-bounces@ietf.org
2010-10-28 上午 07:53

收件人
"liu dapeng" <maxpassion@gmail.com>, "dmm" <dmm@ietf.org>
抄送
caozhen <caozhen@chinamobile.com>, MELIA TELEMACO 
<Telemaco.Melia@alcatel-lucent.com>, "charles.perkins" 
<charles.perkins@tellabs.com>, denghui02 <denghui02@hotmail.com>, Wassim 
Haddad <wassim.haddad@ericsson.com>
主题
Re: [dmm] DMM problem statement and scenario draft






Thanks for sincere efforts.

It seems that the initial drafts and the proposed WG charter will be a 
good triggering point toward 
DMM.
The stepwise approach for design of DMM are also reasonable.

Some comments are:
1) The design of DMM needs to be done in the viewpoint of (generic) 
Functiona Architecture,
rather than based on specific protocols (MIP, PMIP), since  DMM may be 
used in the future
emerging networks (not identified yet) as well as in the current MIP/PMIP 
networks.

2) At present, the main target network to DMM may be the LTE/SAE or 4G 
mobile networks.
In the drafts, it is very helpful to describe the associated requirements 
and applicability 
statements.

Hope to have useful discussion and decision in the upcoming IETF meeting.

Regards,

*************************
Seok Joo Koh
sjkoh@knu.ac.kr
http://protocol.knu.ac.kr/


----- Original Message ----- 
From: "liu dapeng" <maxpassion@gmail.com>
To: "dmm" <dmm@ietf.org>
Cc: "charles.perkins" <charles.perkins@tellabs.com>; "caozhen" 
<caozhen@chinamobile.com>; "MELIA 
TELEMACO" <Telemaco.Melia@alcatel-lucent.com>; "Wassim Haddad" 
<wassim.haddad@ericsson.com>; 
"denghui02" <denghui02@hotmail.com>
Sent: Tuesday, October 19, 2010 5:12 PM
Subject: [dmm] DMM problem statement and scenario draft


Hello all,

After several weeks and many contributor's hard working, we finished
DMM problem statement and scenario draft:

http://tools.ietf.org/html/draft-chan-distributed-mobility-ps-00
http://tools.ietf.org/html/draft-yokota-dmm-scenario-00

Besides, we have the following introduction and initial work plan of DMM:

-----------------------------------------------------------------------------------------------------
Work plan proposal -- Distributed and Dynamic Mobility Management
==================================================

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 capactity, 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 [1] 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

[1] G. Kirby, "Locating the User", Communication International, 1995
----------------------------------------------------------------------------------------------------

Please feel free to comment. Thanks.


Best Regards,
Dapeng Liu
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm 

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.