[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.
- [dmm] DMM problem statement and scenario draft liu dapeng
- Re: [dmm] DMM problem statement and scenario draft Seok Joo Koh
- [dmm] 答复: Re: DMM problem statement and scenario … song.jun
- Re: [dmm] 答复: Re: DMM problem statement and scena… Sri Gundavelli (sgundave)
- Re: [dmm] DMM problem statement and scenario draft liu dapeng
- [dmm] 答复: RE: 答复: Re: DMM problem statement and s… song.jun