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

Romain KUNTZ <rkuntz@us.toyota-itc.com> Thu, 23 June 2011 18:45 UTC

Return-Path: <rkuntz@us.toyota-itc.com>
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 8380521F852B for <mext@ietfa.amsl.com>; Thu, 23 Jun 2011 11:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 JA9q+A3yw2JZ for <mext@ietfa.amsl.com>; Thu, 23 Jun 2011 11:45:59 -0700 (PDT)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id A8CC321F8530 for <mext@ietf.org>; Thu, 23 Jun 2011 11:45:58 -0700 (PDT)
Received: from mail-pw0-f50.google.com ([209.85.160.50]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTgOJ5i1SUyGGoQ8hQiA1xflTXTr3Kez2@postini.com; Thu, 23 Jun 2011 11:45:58 PDT
Received: by pwj1 with SMTP id 1so1626274pwj.37 for <mext@ietf.org>; Thu, 23 Jun 2011 11:45:57 -0700 (PDT)
Received: by 10.142.61.33 with SMTP id j33mr501141wfa.135.1308848827520; Thu, 23 Jun 2011 10:07:07 -0700 (PDT)
Received: from ben-lt3.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id x1sm1357684pbb.18.2011.06.23.10.07.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2011 10:07:06 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Romain KUNTZ <rkuntz@us.toyota-itc.com>
In-Reply-To: <OF1918A97E.60BF523A-ON482578B8.002FFC93-482578B8.00321EA8@zte.com.cn>
Date: Thu, 23 Jun 2011 10:07:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <57327D67-E3C0-4010-B8C0-A3FE5DB5C3CA@us.toyota-itc.com>
References: <OF1918A97E.60BF523A-ON482578B8.002FFC93-482578B8.00321EA8@zte.com.cn>
To: luo.wen@zte.com.cn
X-Mailer: Apple Mail (2.1084)
Cc: mext@ietf.org, Basavaraj.Patil@nokia.com
Subject: Re: [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 18:45:59 -0000

Dear Luo Wen,

Just a quick note to let you know that we have talked about the HMIP applicability to DMM in our summary draft:
http://tools.ietf.org/html/draft-kuntz-dmm-summary-00#page-6

Thank you,
romain

On Jun 23, 2011, at 2:07, luo.wen@zte.com.cn wrote:

> 
> 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
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext