Re: [MEXT] Discussion proposal on network-initiated flow binding forMIPv6

Hidetoshi Yokota <yokota@kddilabs.jp> Tue, 28 June 2011 02:32 UTC

Return-Path: <yokota@kddilabs.jp>
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 <mext@ietfa.amsl.com>; 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 <mext@ietfa.amsl.com>; 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 <mext@ietf.org>; 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 <yokota@kddilabs.jp>
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 <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: 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"
>> <draft-xia-mext-ha-init-flow-binding>
>> 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
>>
>
>
>