[MEXT] Comments on using HMIP as approaches to distributed mobility management

luo.wen@zte.com.cn Thu, 23 June 2011 09:07 UTC

Return-Path: <luo.wen@zte.com.cn>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693111E80BE for <mext@ietfa.amsl.com>; Thu, 23 Jun 2011 02:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.838
X-Spam-Level:
X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tKCsJmb+xo3 for <mext@ietfa.amsl.com>; Thu, 23 Jun 2011 02:07:50 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7F30611E807D for <mext@ietf.org>; Thu, 23 Jun 2011 02:07:49 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48641783477680; Thu, 23 Jun 2011 17:05:08 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 73489.3687167616; Thu, 23 Jun 2011 17:07:24 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5N97RHr014911; Thu, 23 Jun 2011 17:07:27 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
To: <Basavaraj.Patil@nokia.com>
MIME-Version: 1.0
X-KeepSent: 1918A97E:60BF523A-482578B8:002FFC93; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF1918A97E.60BF523A-ON482578B8.002FFC93-482578B8.00321EA8@zte.com.cn>
From: luo.wen@zte.com.cn
Date: Thu, 23 Jun 2011 17:07:22 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-23 17:07:29, Serialize complete at 2011-06-23 17:07:29
Content-Type: multipart/alternative; boundary="=_alternative 00321EA1482578B8_="
X-MAIL: mse02.zte.com.cn p5N97RHr014911
Cc: mext@ietf.org
Subject: [MEXT] Comments on using HMIP as approaches to distributed mobility management
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2011 09:07:51 -0000

Dear Raj and all:

Mr. Raj, thank you for providing your considrations on using Mobile IPv6 
and its extensions as approaches to distributed mobility management. And 
these days, we have studied HMIP which is mentioned in your consideraion, 
and in fact, we believe that the HMIPv6 is not a right way to resolve the 
problems which DMM tries to deal with.

Mr Raj, as discussed to reuse the existing approaches for distributed 
mobility management in your presentation paper, such as Mobile IPv6 and 
its extensions, HMIPv6 was considered as a way to allocate mobility 
anchors that are topologically close to the MN. 
But in fact, the HMIPv6 is not comfortable to allocate this 'topologically 
close' mobility anchor point for the MN according to the MAP selection 
mechanism as specified in RFC5380. Basically MAP selection mechanism 
provides two different processes for the MN that performs inter-AR 
movement frequently or not. For frequently inter-AR movement case, MAP 
selection in Distributed MAP environment is recommended so that a furthest 
available MAP is chosen to register by the MN to avoid frequent 
re-registrations. Otherwise, MAP selection in flat mobility architecture 
is recommended so that a MAP (in the AR) is chosen as an anchor point by 
the MN when performing a handoff, in which the HMIPv6 is performed similar 
as MIPv6 approach. As all above, making the HMIPv6 more effectively, the 
MN always tries to select a furthest MAP to register to reduce the 
signaling (BU/BA to the HA and CN) when the inter-AR handoff is performed. 


In additional, a bi-directional tunnel is established after the successful 
registration procedure between the MN and MAP. All packets sent by the MN 
are tunneled to the MAP. So that even route optimization is performed 
between the MN and CN, all the packets shall be tunneled to the anchor 
point (MAP) first, and then route to the CN. This fundamental approach of 
HMIPv6 does not provide more benefits to resolve the route optimization 
issue, but just reuse the mechanism of MIPv6 and even make it worse.

What do you think?

BR
LUOWEN