From stefano.salsano@uniroma2.it Thu Jun 2 23:52:54 2011 Return-Path: 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 2D360E0696 for ; Thu, 2 Jun 2011 23:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 2-MpyuKVz+WP for ; Thu, 2 Jun 2011 23:52:53 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6B12BE0662 for ; Thu, 2 Jun 2011 23:52:53 -0700 (PDT) Received: from smtpauth.uniroma2.it (smtpauth.uniroma2.it [160.80.6.46]) by smtp.uniroma2.it (8.13.6/8.13.6) with ESMTP id p536g4ko019584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Jun 2011 08:42:05 +0200 Received: from [79.43.225.109] (host109-225-dynamic.43-79-r.retail.telecomitalia.it [79.43.225.109]) (authenticated bits=0) by smtpauth.uniroma2.it (8.14.3/8.14.3/Debian-9.4) with ESMTP id p536qfGP028472 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 3 Jun 2011 08:52:42 +0200 Message-ID: <4DE884BC.7000107@uniroma2.it> Date: Fri, 03 Jun 2011 08:52:44 +0200 From: Stefano Salsano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-From: stefano.salsano@uniroma2.it Cc: marco bonola Subject: [MEXT] rfc 6089 implementation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 06:52:54 -0000 Hi all, we are doing research about IP mobility and we developed a solution based on IP in UDP tunneling (http://netgroup.uniroma2.it/UPMT) we have a question about RFC 6089 - Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support is there any implementation of such RFC? if so, can anybody provide some information and links ? thank you, best regards Stefano -- ******************************************************************* Stefano Salsano Dipartimento Ingegneria Elettronica Universita' di Roma "Tor Vergata" Via del Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From Basavaraj.Patil@nokia.com Fri Jun 3 07:41:12 2011 Return-Path: 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 E6A71E074D for ; Fri, 3 Jun 2011 07:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 sHRm6v+P-6Md for ; Fri, 3 Jun 2011 07:41:12 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 00DF1E065D for ; Fri, 3 Jun 2011 07:41:11 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p53Ef93A001025; Fri, 3 Jun 2011 17:41:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 17:41:09 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Jun 2011 16:41:08 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0289.008; Fri, 3 Jun 2011 16:41:08 +0200 From: To: , Thread-Topic: [MEXT] rfc 6089 implementation Thread-Index: AQHMIbruKkt0KHUmwEa7c6yTZxfL15SqqulQ Date: Fri, 3 Jun 2011 14:41:07 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B7190553FE@008-AM1MPN1-024.mgdnok.nokia.com> References: <4DE884BC.7000107@uniroma2.it> In-Reply-To: <4DE884BC.7000107@uniroma2.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.74.219.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2011 14:41:09.0579 (UTC) FILETIME=[472209B0:01CC21FC] X-Nokia-AV: Clean Cc: ext-eduardo.panisset@nokia.com, marco.bonola@uniroma2.it Subject: Re: [MEXT] rfc 6089 implementation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 14:41:13 -0000 We do have an implementation of flow mobility as per RFCs 6088/6089.=20 We demoed the implementation at IETF80.=20 This implementation is done over DSMIP6 (RFC5555) with security mechanisms = specified in draft-ietf-mext-mip6-tls-00 -Raj -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of ext= Stefano Salsano Sent: Friday, June 03, 2011 1:53 AM To: mext@ietf.org Cc: marco bonola Subject: [MEXT] rfc 6089 implementation Hi all, we are doing research about IP mobility and we developed a solution based o= n IP in UDP tunneling (http://netgroup.uniroma2.it/UPMT) we have a question about RFC 6089 - Flow Bindings in Mobile IPv6 and Networ= k Mobility (NEMO) Basic Support is there any implementation of such RFC? if so, can anybody provide some in= formation and links ? thank you, best regards Stefano -- ******************************************************************* Stefano Salsano Dipartimento Ingegneria Elettronica Universita' di Roma "Tor Vergata" Via del Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From gerardo.giaretta@gmail.com Fri Jun 3 08:01:25 2011 Return-Path: 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 24289E075C for ; Fri, 3 Jun 2011 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 cKF2fKmmNWqi for ; Fri, 3 Jun 2011 08:01:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26DE0725 for ; Fri, 3 Jun 2011 08:01:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so1021206gyf.31 for ; Fri, 03 Jun 2011 08:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wpikRgmfxlps9+TLSlZhdmVkB4bVFBjI89FRBh+5pfc=; b=r+lJaDL0b+tLWinxIfdmUKX+NLSLGsDUopdjHSJ0THvtzHJN2ULEoqlB60zp2bF9/O daoMR0kckhxC/nj2sQW5V6JQgghfz2oBVkydICYVL45Oj0T6k2XV1ISUPJGVikipv/Ny onQdtURbdCoEuSlehSXdMZWnsru3QXBEuNtsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GH8n5sWWKcFYQl8hPU0i1Vn5WIuLm1MXtEfjcKDLgw+SJ8Cg6pQLw8sg2PvcH5nFuq 9LL8y9QlTAfvOFZm98yxzs41VGFTz7YL5QsOMSGEdouI7M5z8lpLsWRHQrrOmiWw3vWz zwfWMYy+HjGO1ggOIcgIihO9sWMNWiqajZuCc= MIME-Version: 1.0 Received: by 10.236.175.169 with SMTP id z29mr2752209yhl.328.1307113283351; Fri, 03 Jun 2011 08:01:23 -0700 (PDT) Received: by 10.236.155.105 with HTTP; Fri, 3 Jun 2011 08:01:23 -0700 (PDT) In-Reply-To: <4DE884BC.7000107@uniroma2.it> References: <4DE884BC.7000107@uniroma2.it> Date: Fri, 3 Jun 2011 08:01:23 -0700 Message-ID: From: Gerardo Giaretta To: Stefano Salsano Content-Type: multipart/alternative; boundary=90e6ba53a2feef749804a4d00631 Cc: marco bonola , mext@ietf.org Subject: Re: [MEXT] rfc 6089 implementation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:01:25 -0000 --90e6ba53a2feef749804a4d00631 Content-Type: text/plain; charset=ISO-8859-1 Hi, we have two implementations of RFC 6089, one based on BMP (Brew Mobile Platform) and one on Android. They are not commercial yet. Gerardo Qualcomm On Thu, Jun 2, 2011 at 11:52 PM, Stefano Salsano < stefano.salsano@uniroma2.it> wrote: > Hi all, > > we are doing research about IP mobility and we developed a solution based > on IP in UDP tunneling (http://netgroup.uniroma2.it/UPMT) > > we have a question about RFC 6089 - Flow Bindings in Mobile IPv6 and > Network Mobility (NEMO) Basic Support > > is there any implementation of such RFC? if so, can anybody provide some > information and links ? > > thank you, best regards > Stefano > -- > ******************************************************************* > Stefano Salsano > Dipartimento Ingegneria Elettronica > Universita' di Roma "Tor Vergata" > Via del Politecnico, 1 - 00133 Roma - ITALY > > http://netgroup.uniroma2.it/Stefano_Salsano/ > > E-mail : stefano.salsano@uniroma2.it > Cell. : +39 320 4307310 > Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 > ******************************************************************* > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --90e6ba53a2feef749804a4d00631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

we have two implementations of RFC 6089, one based o= n BMP (Brew Mobile Platform) and one on Android. They are not commercial ye= t.

Gerardo
Qualcomm=A0

On Thu, Jun 2, 2011 at 11:52 PM, Stefano Salsano <stefano.salsano@uniroma2.it&= gt; wrote:
Hi all,

we are doing research about IP mobility and we developed a solution based o= n IP in UDP tunneling (http://netgroup.uniroma2.it/UPMT)

we have a question about RFC 6089 - Flow Bindings in Mobile IPv6 and Networ= k Mobility (NEMO) Basic Support

is there any implementation of such RFC? if so, can anybody provide some in= formation and links ?

thank you, best regards
Stefano
--
*******************************************************************
Stefano Salsano
Dipartimento Ingegneria Elettronica
Universita' di Roma "Tor Vergata"
Via del Politecnico, 1 - 00133 Roma - ITALY

= http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail =A0: stefano.salsano@uniroma2.it
Cell. =A0 : +39 320 4307310
Office =A0: (Tel.) +39 06 72597770 =A0(Fax.) +39 06 72597435<= /a>
*******************************************************************
_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext

--90e6ba53a2feef749804a4d00631-- From yokota@kddilabs.jp Sun Jun 12 17:36:04 2011 Return-Path: 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 DE90421F84C4 for ; Sun, 12 Jun 2011 17:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 mi2qR8w6MUCJ for ; Sun, 12 Jun 2011 17:36:04 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 4501F21F84C1 for ; Sun, 12 Jun 2011 17:36:00 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id E951317481F8 for ; Mon, 13 Jun 2011 09:35:55 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3GCczHRRj70 for ; Mon, 13 Jun 2011 09:35:55 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 55C7E17481D3 for ; Mon, 13 Jun 2011 09:35:55 +0900 (JST) Received: from [127.0.0.1] (yokotaiMac.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id CE84E1B9B4 for ; Mon, 13 Jun 2011 09:35:27 +0900 (JST) Message-ID: <4DF55B69.4080606@kddilabs.jp> Date: Mon, 13 Jun 2011 09:35:53 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [MEXT] Discussion proposal on network-initiated flow binding for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 00:36:05 -0000 Hi all, A while back, there was a discussion on network-initiated flow binding, whereby the home agent indicates the mobile node to move flows between access networks. At that time, the discussion didn't get enough momentum partly due to lack of a convincing use case. Nowadays, it is rather common for a smartphone to have multiple interfaces pumping a lot of packets into the network. Data traffic offload is becoming a serious issue for mobile operators worldwide. The host-initiated flow binding provided by RFC6089 is a big step to realize fine-grained data traffic offload. And for the next step, it may be a way forward for the network to be able to trigger flow mobility since the network knows more about its conditions and interworks with the policy server or application servers. I would therefore like to revitalize the discussion on the network-initiated flow binding for MIPv6. The following I-D, which was once discussed in the past meetings, could be good for restarting the discussion: "Home Agent Initiated Flow Binding for Mobile IPv6" http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-05.txt In NetExt WG, there is a similar discussion going for PMIPv6, which includes network-initiated flow mobility. As a side note, a related item is being discussed in 3GPP and the discussion in IETF will certainly help them make their way. I would appreciate your opinion and hopefully your interest. Regards, -- Hidetoshi From luo.wen@zte.com.cn Thu Jun 23 02:07:50 2011 Return-Path: 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 ; 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 ; 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 ; 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:07:51 -0000 This is a multipart message in MIME format. --=_alternative 00321EA1482578B8_= Content-Type: text/plain; charset="US-ASCII" 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 --=_alternative 00321EA1482578B8_= Content-Type: text/html; charset="US-ASCII"
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
--=_alternative 00321EA1482578B8_=-- From rkuntz@us.toyota-itc.com Thu Jun 23 11:45:59 2011 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: >=20 > Dear Raj and all:=20 >=20 > 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.=20 >=20 > 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.=20 > 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.=20 >=20 > 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.=20 >=20 > What do you think?=20 >=20 > BR=20 > LUOWEN > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julien.ietf@gmail.com Fri Jun 24 14:35:21 2011 Return-Path: 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 89F2F11E819F for ; Fri, 24 Jun 2011 14:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Jf8NxnchWx3e for ; Fri, 24 Jun 2011 14:35:20 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4C6A11E8185 for ; Fri, 24 Jun 2011 14:35:19 -0700 (PDT) Received: by mail-bw0-f44.google.com with SMTP id 17so140207bwb.31 for ; Fri, 24 Jun 2011 14:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=UtnKREr16MLXnv5HmYbgZvXUBf+LK5fXyKjFtc6FvnI=; b=UMx689DrAkztCPBwpFwNSGkwX90BIYXG847/FHLjfNvt3Q+HCi2rq+ONe/4lrlWO2g Bs4nJP4HRhU9UYnUwqhOYkyIpWhWpBgXia0lkStMpGqGze+Bk47e/lgoHxAubAC+nzub n8T9d1UcRXh4TbfR2M1xxRi8CMw6YwPmKO01g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=p6RQwlQqe4BKZknfK4NiJpebsXZx8nlJh5WUxECIHx6uNxoOoBU/xTbQdQKuIsOxx2 pp1H0hgdXCViXak3GMwatPzfErmoBrr6GoxIT4g1tqH+KB5CIvITgariNMAIECTMLMG5 i4Scim5cO9M1gXXVAQ1DcovHwHEzCe32wLyu8= MIME-Version: 1.0 Received: by 10.204.7.20 with SMTP id b20mr2274733bkb.132.1308951319254; Fri, 24 Jun 2011 14:35:19 -0700 (PDT) Received: by 10.204.71.78 with HTTP; Fri, 24 Jun 2011 14:35:19 -0700 (PDT) In-Reply-To: <20110624183513.7035311E81A8@ietfa.amsl.com> References: <20110624183513.7035311E81A8@ietfa.amsl.com> Date: Fri, 24 Jun 2011 14:35:19 -0700 Message-ID: From: Julien Laganier To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] Fwd: Please help the Nomcom X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 21:35:21 -0000 FYI ---------- Forwarded message ---------- From: NomCom Chair Date: Fri, Jun 24, 2011 at 11:35 AM Subject: Please help the Nomcom To: Working Group Chairs Hi WG chairs, =A0We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From pierrick.seite@orange-ftgroup.com Mon Jun 27 05:00:27 2011 Return-Path: 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 CA30421F85C9 for ; Mon, 27 Jun 2011 05:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 LiXG2434UaAH for ; Mon, 27 Jun 2011 05:00:27 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE1E21F8553 for ; Mon, 27 Jun 2011 05:00:27 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2F7EFFC4005; Mon, 27 Jun 2011 13:23:11 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 253F8FC4004; Mon, 27 Jun 2011 13:23:11 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 13:23:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jun 2011 13:23:09 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201C574AC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4DF55B69.4080606@kddilabs.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Discussion proposal on network-initiated flow binding forMIPv6 Thread-Index: AcwpYfoAW9EJUzmGSDeKEsxxCpbUZQLWgfwA References: <4DF55B69.4080606@kddilabs.jp> From: To: , X-OriginalArrivalTime: 27 Jun 2011 11:23:12.0841 (UTC) FILETIME=[99F5A390:01CC34BC] Subject: Re: [MEXT] Discussion proposal on network-initiated flow binding forMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 12:00:27 -0000 Hi Hidetoshi, Sorry for the late answer, but this long delay does not mean a lack of = interest for network-initiated flow binding :-) Actually, I think we should consider the case where mobility triggers = may come from the network, especially in multiple interfaces use-case = you are referring to. For instance, the handover could be triggered when = the network changes its inter-system handover policy, or when the = network detects, or anticipates, network load issues. Note that we are = talking only about mobility initiation here; I mean that this model = should not preclude the terminal to make the final decision, e.g. = considering quality of the radio link. Then, "network initiated mobility" does not mean "mobility is always = initiated by the network"... Obviously, if the terminal looses an = interface, the terminal will initiate the mobility whithout waiting for = a network trigger.... Actually, I'd say that a complete mobility = management process should include both network and terminal initiated = mobility, depending on the type of trigger. This discussion should not be restricted to MIP. PMIP is network-based = execution protocols, so it can be awkward not having also a = network-based initiation model with PMIP.=20 Pierrick =20 > -----Message d'origine----- > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De=20 > la part de Hidetoshi Yokota > Envoy=E9 : lundi 13 juin 2011 02:36 > =C0 : mext@ietf.org > Objet : [MEXT] Discussion proposal on network-initiated flow=20 > binding forMIPv6 >=20 > Hi all, >=20 > A while back, there was a discussion on network-initiated=20 > flow binding, whereby the home agent indicates the mobile=20 > node to move flows between access networks. At that time, the=20 > discussion didn't get enough momentum partly due to lack of a=20 > convincing use case. Nowadays, it is rather common for a=20 > smartphone to have multiple interfaces pumping a lot of=20 > packets into the network. Data traffic offload is becoming a=20 > serious issue for mobile operators worldwide. The=20 > host-initiated flow binding provided by RFC6089 is a big step=20 > to realize fine-grained data traffic offload. And for the=20 > next step, it may be a way forward for the network to be able=20 > to trigger flow mobility since the network knows more about=20 > its conditions and interworks with the policy server or=20 > application servers. >=20 > I would therefore like to revitalize the discussion on the=20 > network-initiated flow binding for MIPv6. The following I-D,=20 > which was once discussed in the past meetings, could be good=20 > for restarting the > discussion: >=20 > "Home Agent Initiated Flow Binding for Mobile IPv6" > > http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-05.txt >=20 > In NetExt WG, there is a similar discussion going for PMIPv6,=20 > which includes network-initiated flow mobility. As a side=20 > note, a related item is being discussed in 3GPP and the=20 > discussion in IETF will certainly help them make their way. >=20 > I would appreciate your opinion and hopefully your interest. >=20 > Regards, > -- > Hidetoshi >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From julien.ietf@gmail.com Mon Jun 27 09:36:38 2011 Return-Path: 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 DD26B11E810D for ; Mon, 27 Jun 2011 09:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 OrgmGFucDoyc for ; Mon, 27 Jun 2011 09:36:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3421A11E8124 for ; Mon, 27 Jun 2011 09:36:35 -0700 (PDT) Received: by bwb17 with SMTP id 17so1724072bwb.31 for ; Mon, 27 Jun 2011 09:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=QO71zlnMzJUkSDjwtz2eVe4lvu7cZYVCnAbrlGQFTgw=; b=MM1IJopP15oVeaZG5uusihcAIjMw2urP0AiHGbg60Ai02eHP5kdHRAkNTqym9UoA4b hvSGSlJRWxyHfODhWDsxzCe8NQu40CCS9jFYPPUygorexbSW+v8wjkSIKzqOwf8fovwJ Bblg4r01WtoQkkpIpmIzCwhKLHfphlIyUkWzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=IN1VItOPUJMggb5jI59e/lE3dtktbO9luIzGls32xlnljEq6YlaeMCLs+QWRR9LAyV N46dMydhpUcaxE+lEb2EjAyGwpwEJ1twgwi464cHvQEzTRjWDOBbGVpuOQG8Wwtt+mco oedBe3fqM9U083/2GYW7EsiaTGPOjKlo+VAI8= MIME-Version: 1.0 Received: by 10.204.14.204 with SMTP id h12mr4501650bka.78.1309192594050; Mon, 27 Jun 2011 09:36:34 -0700 (PDT) Received: by 10.204.71.78 with HTTP; Mon, 27 Jun 2011 09:36:34 -0700 (PDT) Date: Mon, 27 Jun 2011 09:36:34 -0700 Message-ID: From: Julien Laganier To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [MEXT] IETF-81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:36:39 -0000 Folks, at this point we do not have anything on our plate that would require face to face discussion thus the MEXT WG will not meet in Quebec. --julien & marcelo From rkuntz@us.toyota-itc.com Mon Jun 27 15:55:09 2011 Return-Path: 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 AA9CE21F8508 for ; Mon, 27 Jun 2011 15:55:09 -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 c08s2f05lMMc for ; Mon, 27 Jun 2011 15:55:08 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with SMTP id 9273621F8507 for ; Mon, 27 Jun 2011 15:55:07 -0700 (PDT) Received: from mail-pz0-f47.google.com ([209.85.210.47]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTgkKS9gbohTbPOULK3PEElicnWLjngPM@postini.com; Mon, 27 Jun 2011 15:55:08 PDT Received: by mail-pz0-f47.google.com with SMTP id 36so3417021pzk.20 for ; Mon, 27 Jun 2011 15:55:07 -0700 (PDT) Received: by 10.68.20.68 with SMTP id l4mr3382355pbe.290.1309215307092; Mon, 27 Jun 2011 15:55:07 -0700 (PDT) Received: from ben-lt3.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id u6sm4626619pbh.48.2011.06.27.15.55.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 15:55:06 -0700 (PDT) From: Romain KUNTZ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jun 2011 15:55:04 -0700 Message-Id: <85A5D9F6-8186-4A41-BB1C-068FB781E28E@us.toyota-itc.com> To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MEXT] Comments about draft-gundavelli-mext-dsmip-ipv4-overlap X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 22:55:09 -0000 Hi Sri, I came through draft-gundavelli-mext-dsmip-ipv4-overlap, and was = wondering whether it would make sense to take also prefix overlap into = consideration. DSMIPv6 allows the assignment of a whole IPv4 prefix = through the use of the P flag in the IPv4 Home Address option, which = could make prefix overlap likely to occur. It may be worth mentioning in = the document.=20 A few other minor comments: - section 3.2, there is an unrelated reference to [RFC3775] - section 4.1.1, I would add that the "context identifier field" comes = from the GRE Key Header (and cite RFC5845) - section 4.1.2: s/"with the home address option"/"with the IPv4 home = address option" - I would move section 5 to the beginning of section 4. That would makes = section 4.1.2 more clear. Regards, Romain= From sgundave@cisco.com Mon Jun 27 16:06:15 2011 Return-Path: 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 C679E1F0C45 for ; Mon, 27 Jun 2011 16:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 2ooX63gHg7YD for ; Mon, 27 Jun 2011 16:06:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2809221F8556 for ; Mon, 27 Jun 2011 16:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1215; q=dns/txt; s=iport; t=1309215974; x=1310425574; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=7ZSQboV+vvtJ3zhv9CpzVvwmxhbxWW/fQ+rrF6XBjNk=; b=d2cPzBuS93rRqkdMVcxEaqgTr3PXAhI9AnjpnGPm3WbeJBmVNuBMKdNe 56yU/IRFotpLI1WPI89qHwHbzALNqdcuJKh/24EGtcJvikt8DwUMoarSm ufnUU4tr9Vu14exa+wf3sWl/NaPWmgjysQG/VLMVaWZukJ6zzxNzm6XGP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0HADoMCU6rRDoG/2dsb2JhbABSpzUCd4h0oiWeJoYwBIcsileEd4cyhBI X-IronPort-AV: E=Sophos;i="4.65,434,1304294400"; d="scan'208";a="348460154" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2011 23:05:57 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5RN5vE2007386; Mon, 27 Jun 2011 23:05:57 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 16:05:56 -0700 Received: from 128.107.112.115 ([128.107.112.115]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Jun 2011 23:05:56 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 27 Jun 2011 16:05:55 -0700 From: Sri Gundavelli To: Romain KUNTZ , Message-ID: Thread-Topic: [MEXT] Comments about draft-gundavelli-mext-dsmip-ipv4-overlap Thread-Index: Acw1HsSQqjdhNvMLXkm6oBfrL/5HCQ== In-Reply-To: <85A5D9F6-8186-4A41-BB1C-068FB781E28E@us.toyota-itc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jun 2011 23:05:56.0929 (UTC) FILETIME=[C5B6E310:01CC351E] Subject: Re: [MEXT] Comments about draft-gundavelli-mext-dsmip-ipv4-overlap X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 23:06:15 -0000 Hi Romain, Thanks for the review. I think we missed the prefix part, we can add some considerations around that. Will all fix the below issues. Regards Sri On 6/27/11 3:55 PM, "Romain KUNTZ" wrote: > Hi Sri, > > I came through draft-gundavelli-mext-dsmip-ipv4-overlap, and was wondering > whether it would make sense to take also prefix overlap into consideration. > DSMIPv6 allows the assignment of a whole IPv4 prefix through the use of the P > flag in the IPv4 Home Address option, which could make prefix overlap likely > to occur. It may be worth mentioning in the document. > > A few other minor comments: > - section 3.2, there is an unrelated reference to [RFC3775] > - section 4.1.1, I would add that the "context identifier field" comes from > the GRE Key Header (and cite RFC5845) > - section 4.1.2: s/"with the home address option"/"with the IPv4 home address > option" > - I would move section 5 to the beginning of section 4. That would makes > section 4.1.2 more clear. > > Regards, > Romain > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From yokota@kddilabs.jp Mon Jun 27 19:12:47 2011 Return-Path: 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 A300A21F84CA for ; Mon, 27 Jun 2011 19:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 TYzNH7u+ooXo for ; Mon, 27 Jun 2011 19:12:47 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [192.26.91.6]) by ietfa.amsl.com (Postfix) with ESMTP id 216BE21F841F for ; Mon, 27 Jun 2011 19:12:47 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 837FC174824D for ; Tue, 28 Jun 2011 11:12:25 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzY-l73rL+0m for ; Tue, 28 Jun 2011 11:12:04 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8A56417481FC for ; Tue, 28 Jun 2011 11:12:04 +0900 (JST) Received: from [127.0.0.1] (yokotaiMac.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id AD0561B9AF for ; Tue, 28 Jun 2011 11:11:16 +0900 (JST) Message-ID: <4E093873.1050201@kddilabs.jp> Date: Tue, 28 Jun 2011 11:12:03 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] IETF-81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 02:12:47 -0000 Hi Julien and all, Sorry for our late notice, but we just submitted the revised version of "Home Agent Initiated Flow Binding for Mobile IPv6" and would like to discuss it at the next IETF meeting. Since this topic hasn't got consensus and requires an intensive discussion, a face to face meeting will be needed. Please take a look at the following I-D: http://www.ietf.org/id/draft-yokota-mext-ha-init-flow-binding-00.txt Thanks in advance for your support, -- Hidetoshi (2011/06/28 1:36), Julien Laganier wrote: > Folks, > > at this point we do not have anything on our plate that would require > face to face discussion thus the MEXT WG will not meet in Quebec. > > --julien& marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From yokota@kddilabs.jp Mon Jun 27 19:32:17 2011 Return-Path: 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 8698E11E8076 for ; Mon, 27 Jun 2011 19:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 UklFWXD0Aehe for ; Mon, 27 Jun 2011 19:32:17 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [192.26.91.6]) by ietfa.amsl.com (Postfix) with ESMTP id B3322228011 for ; Mon, 27 Jun 2011 19:32:16 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id DEDAC174824B; Tue, 28 Jun 2011 11:31:51 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-6Gw+x9Pnk0; Tue, 28 Jun 2011 11:31:51 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 4EBE517480EA; Tue, 28 Jun 2011 11:31:51 +0900 (JST) Received: from [127.0.0.1] (yokotaiMac.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 7663D1B9AF; Tue, 28 Jun 2011 11:31:03 +0900 (JST) Message-ID: <4E093D16.9080706@kddilabs.jp> Date: Tue, 28 Jun 2011 11:31:50 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <4DF55B69.4080606@kddilabs.jp> <843DA8228A1BA74CA31FB4E111A5C46201C574AC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201C574AC@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mext@ietf.org Subject: Re: [MEXT] Discussion proposal on network-initiated flow binding forMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 02:32:17 -0000 Hi Pierrick, (2011/06/27 20:23), pierrick.seite@orange-ftgroup.com wrote: > Hi Hidetoshi, > > Sorry for the late answer, but this long delay does not mean a lack of interest for network-initiated flow binding :-) Thanks a lot for your interest! I received a couple of feedback personally, but it's always good to discuss it on the ML. > Actually, I think we should consider the case where mobility triggers may come from the network, especially in multiple interfaces use-case you are referring to. For instance, the handover could be triggered when the network changes its inter-system handover policy, or when the network detects, or anticipates, network load issues. Note that we are talking only about mobility initiation here; I mean that this model should not preclude the terminal to make the final decision, e.g. considering quality of the radio link. Exactly. This proposal does not specify who finally decides the flow binding. The wireless condition on the mobile side is best known by the mobile node, so the network just provides a hint or policy to the mobile node. Then the mobile node finally moves the flow(s) to a most appropriate wireless access. One serious problem that the current mobile phone is facing is that the WiFi device on the mobile phone keeps scanning in vain where no WiFi APs exist, which is totally a waste of energy and the user eventually turns it off permanently. The network can send a trigger for flow mobility at the right timing in the right situation. > Then, "network initiated mobility" does not mean "mobility is always initiated by the network"... Obviously, if the terminal looses an interface, the terminal will initiate the mobility whithout waiting for a network trigger.... Actually, I'd say that a complete mobility management process should include both network and terminal initiated mobility, depending on the type of trigger. Correct. Eventually, the mobility management can be done by the cooperation of both the network and mobile sides. The terminal-initiated mobility has been standardized, so we have to do the rest of the whole concept. > This discussion should not be restricted to MIP. PMIP is network-based execution protocols, so it can be awkward not having also a network-based initiation model with PMIP. Good point. The network-based flow mobility is discussed in NetExt WG, so in MEXT WG, we just focus on the MIP version of it. Both of them are important at the same level. Thanks again for your interest and good discussion, -- Hidetoshi > Pierrick > >> -----Message d'origine----- >> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De >> la part de Hidetoshi Yokota >> Envoyé : lundi 13 juin 2011 02:36 >> À : mext@ietf.org >> Objet : [MEXT] Discussion proposal on network-initiated flow >> binding forMIPv6 >> >> Hi all, >> >> A while back, there was a discussion on network-initiated >> flow binding, whereby the home agent indicates the mobile >> node to move flows between access networks. At that time, the >> discussion didn't get enough momentum partly due to lack of a >> convincing use case. Nowadays, it is rather common for a >> smartphone to have multiple interfaces pumping a lot of >> packets into the network. Data traffic offload is becoming a >> serious issue for mobile operators worldwide. The >> host-initiated flow binding provided by RFC6089 is a big step >> to realize fine-grained data traffic offload. And for the >> next step, it may be a way forward for the network to be able >> to trigger flow mobility since the network knows more about >> its conditions and interworks with the policy server or >> application servers. >> >> I would therefore like to revitalize the discussion on the >> network-initiated flow binding for MIPv6. The following I-D, >> which was once discussed in the past meetings, could be good >> for restarting the >> discussion: >> >> "Home Agent Initiated Flow Binding for Mobile IPv6" >> >> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-05.txt >> >> In NetExt WG, there is a similar discussion going for PMIPv6, >> which includes network-initiated flow mobility. As a side >> note, a related item is being discussed in 3GPP and the >> discussion in IETF will certainly help them make their way. >> >> I would appreciate your opinion and hopefully your interest. >> >> Regards, >> -- >> Hidetoshi >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > From yokota@kddilabs.jp Mon Jun 27 19:55:06 2011 Return-Path: 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 AB10A21F84AE for ; Mon, 27 Jun 2011 19:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 ABbqN824Yp+n for ; Mon, 27 Jun 2011 19:55:05 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [192.26.91.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE2011E80C9 for ; Mon, 27 Jun 2011 19:54:58 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 2435517482A5 for ; Tue, 28 Jun 2011 11:54:34 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PxRpc5Di4Nx for ; Tue, 28 Jun 2011 11:54:33 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9803C17481C3 for ; Tue, 28 Jun 2011 11:54:33 +0900 (JST) Received: from [127.0.0.1] (yokotaiMac.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id C330D1B9AF for ; Tue, 28 Jun 2011 11:53:45 +0900 (JST) Message-ID: <4E094268.40300@kddilabs.jp> Date: Tue, 28 Jun 2011 11:54:32 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [MEXT] Revised version of "Home Agent Initiated Flow Binding for Mobile IPv6" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 02:55:06 -0000 Hi all, We have just submitted a revised version of home agent-initiated flow binding. It is streamlined a little bit from the previous version and reinforced regarding the use case scenarios. We would like to discuss it on the ML and hopefully at the next IETF meeting: http://www.ietf.org/id/draft-yokota-mext-ha-init-flow-binding-00.txt Filename: draft-yokota-mext-ha-init-flow-binding Revision: 00 Title: Home Agent Initiated Flow Binding for Mobile IPv6 Creation date: 2011-06-24 WG ID: Individual Submission Number of pages: 14 Abstract: There are scenarios in which home agent initiated flow binding operations towards the mobile node is needed such as revoking a flow binding or moving a flow from one interface to another because of network resource availability. This document defines one new Mobility Header, two messages, several actions and two new sub- options to perform home agent initiated interactions for flow bindings in a mobile node. Home agent initiated flow bindings are supported for both IPv4 and IPv6 enabled mobile nodes. We would appreciate your interest and comments, -- Hidetoshi