Re: [multimob] [Fwd: New VersionNotificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

Frank Xia <xiayangsong@huawei.com> Fri, 19 March 2010 21:29 UTC

Return-Path: <xiayangsong@huawei.com>
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4473A684A for <multimob@core3.amsl.com>; Fri, 19 Mar 2010 14:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.777
X-Spam-Level: *
X-Spam-Status: No, score=1.777 tagged_above=-999 required=5 tests=[AWL=-1.804, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_CHARSET_FARAWAY=2.45]
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 CRXRw+HwEQCZ for <multimob@core3.amsl.com>; Fri, 19 Mar 2010 14:29:23 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0A2963A6916 for <multimob@ietf.org>; Fri, 19 Mar 2010 14:29:23 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZJ0051PT18IU@szxga03-in.huawei.com> for multimob@ietf.org; Sat, 20 Mar 2010 05:29:33 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZJ00I2XT18XX@szxga03-in.huawei.com> for multimob@ietf.org; Sat, 20 Mar 2010 05:29:32 +0800 (CST)
Received: from X24512z ([10.124.12.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZJ00CL8T16DI@szxml04-in.huawei.com> for multimob@ietf.org; Sat, 20 Mar 2010 05:29:32 +0800 (CST)
Date: Fri, 19 Mar 2010 16:29:29 -0500
From: Frank Xia <xiayangsong@huawei.com>
In-reply-to: <4BA3E747.3050800@informatik.haw-hamburg.de>
To: "'Thomas C. Schmidt'" <schmidt@informatik.haw-hamburg.de>
Message-id: <00b501cac7ab$43a089d0$510c7c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: AcrHqAcJ4ho/25z4SvOOEkKhVMAnwQAAOBSw
References: <4B912044.5040203@informatik.haw-hamburg.de> <5dca10d31003112235o21439c75rc3d623090a83ecc1@mail.gmail.com> <4B9A0C48.1010802@informatik.haw-hamburg.de> <009a01cac200$1d29fd00$510c7c0a@china.huawei.com> <00b101cac7a5$86bc0240$510c7c0a@china.huawei.com> <4BA3E747.3050800@informatik.haw-hamburg.de>
Cc: multimob@ietf.org
Subject: Re: [multimob] [Fwd: New VersionNotificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2010 21:29:25 -0000

Hi Thomas

Please check my comments...

BR
Frank

-----Original Message-----
From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] 
Sent: Friday, March 19, 2010 4:06 PM
To: Frank Xia
Cc: 'Min Hui'; multimob@ietf.org
Subject: Re: [multimob] [Fwd: New
VersionNotificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

Hi Frank,

Frank Xia wrote:

> I took a quick look at the draft.
> 
> A major observation is that your multicast 
> handover solutions are deeply coupled with 
> specific unicast handover solutions.
>

I don't see what you are pointing at: this draft addresses multicast 
extensions for FMIPv6 and PMIPv6. The core parts are identical, specific 
details of the unicast handover protocols, however, need to be taken 
into account.
Frank=>What about FMIPv4?

> I would like to have a unified ( or general ) 
> multicast handover solution which support
> mobile IPv4 fast handover(RFC4988), mobile
> IPv6 fast handover(RFC5568), and Fast Handovers for
> Proxy Mobile IPv6(draft-ietf-mipshop-pfmipv6-12.txt).
> 

I don't think there is room for a uniform behavior - multicast message 
exchange (context transfer), however, in our draft is independent of the 
specific unicast protocol
Frank=> The uniform behavior could be using MLD/IGMP to collect
multicast group information, using HI/Hack to transfer this context from
PAR(PMAG) to NAR(PMAG), and IP4/IP6/GRE tunneling multicast traffic from
PAR(PMAG) to NAR(PMAG). You modified PrRtAdv, FBU/FBAck which are specific
protocol for FMIPv6.
.

> Some specific comments are below:
> 1)section 5.1.
>  M-bit in Proxy Router Advertisements (PrRtAdv) is for 
>  AR multicast capability notification. However, there
>  is no such mechanism for PMAG just because there is no
>  proper signaling to carry this information.  Probably,
>  we don't need this capability notification, and just
>  assume that all multicast traffic need session continuity.
> 

Yes, of course there is not - P(f)MIPv6 has no handover message exchange 
with the mobile node, as MNs are mobility-agnostic in PMIP.
Frank=>Probably we do not need this extra consideration for FMIP.


> 2)section 5.2 
>   "the corresponding option is included within the mobility 
>    option list of HI/HAck only (PFMIPv6), or of FBU/FBAck
>    /HI/HAck (FMIPv6"
>   IMHO, it is not necessary for FBU/FBack to carry this option.
>   PMAG/PAR can collect MN's multicast membership information 
>   MLD/IGMP(for dual stack)
> 

This means explicit tracking at the PAR/PMAG. We commented on it - but 
as it is not the default standard behavior, we cannot assume explicit 
tracking.

Also: initiating the mobility option, that is passed between FMIPv6 ARs, 
at the mobile client is not a particularly bad thing.

> 3)figure 2 and figure 4
>  Can we unify them?  PAR can treat FBU as a trigger, and then collects
>  Multicast membership information of the mobile node using MLD/IGMP
> 

I don't think so: FMIPv6 and PFMIPv6 are not totally alike ... even the 
base unicast HI/HACK are not identical.
Frank=>It depends on how we look at FMIP and PFMIP.  IMHO, they are alike in
main idea. Let me reword my question. Can PAR use MLD inquiry not FBU to
have 
multicast group information of a mobile node?  

> 4)IPv4 consideration.
>   Can we consider a general solution which also support mobile IPv4 fast
>   handover(RFC4988)?
> 

Yes, this should be a point to think about: there should be no general 
problem, I suppose.
Frank=>Unified solution does not mean to be identical. Of course, there
are some variations in details, such as triggers.

> We can discuss face to face at the meeting.
> 

Yes, L.A. sunset will be inspiring :-)

Best,

Thomas


> -----Original Message-----
> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On
Behalf
> Of Frank Xia
> Sent: Friday, March 12, 2010 10:22 AM
> To: 'Thomas C. Schmidt'; 'Min Hui'
> Cc: multimob@ietf.org
> Subject: Re: [multimob] [Fwd: New Version
> Notificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]
> 
> Hi Thomas
> 
> Just I told you in another email, we had a draft
> http://tools.ietf.org/id/draft-xia-mipshop-fmip-multicast-01.txt
> which was presented at IETF 66, and Multimob BarBoF.
> 
> I was going to update the draft adopting the following principles:
> 
> 1)Unifying multicast FMIP and PFMIP handover procedure, that is 
>  FBU/FBack messages won't be touched. I would like to  view 
>  multicast mobility is an application of unicast mobility. When
>  a mobile node moves, it is also assumed that corresponding 
>  multicast traffic should be handovered to NAR.
> 
> 2)MLD query is used to collect multicast context, which is 
> applicable not only to FMIP but also PFMIP. HI/HACK are
> used for context transferring between PAR(PMAG)/NAR(NMAG)
> 
> 3)Extending MLD/IGMP for Specific MLD Query. You use general MLD
>  Query which is fine when point-to-point link model adopted,
>  and PMIP "currently" is only for point-to-point link, but FMIP
>  is for both shared-link and point-to-point link.
> 
> BR
> Frank
> 
> -----Original Message-----
> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On
Behalf
> Of Thomas C. Schmidt
> Sent: Friday, March 12, 2010 3:41 AM
> To: Min Hui
> Cc: multimob@ietf.org
> Subject: Re: [multimob] [Fwd: New Version Notification
> fordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]
> 
> Hi Hui,
> 
> Min Hui wrote:
> 
>> I have a draft to solve this multicast fast handover issue which was
>> proposed last year, and we have discussed this draft by mail before
>> last IETF meeting.
>> See my draft by the link:
>> http://tools.ietf.org/id/draft-hui-multimob-fast-handover-00.txt
>> The draft was on the Multimob agenda in the last IETF meeting, but
>> wasn't presented due to the lack of time.
>>
> 
> Of course I know. In Hiroshima, we had a quick discussion with Hui Deng 
> and Rajeev about the subject and the work we had already been doing on
this.
> 
>> I have a quick look about your new draft, it seems our drafts are
>> quite similar. We both extend the HI/HACK message to support multicast
>> context transfer, and setup the tunnel between pMAG and nMAG to ensure
>> multicast fast handover.
>>
> 
> As mentioned in the Acknowledgements Section (and also in the problem 
> statement), there has actually been a long history of proposals, papers 
> & drafts on this issue, the first draft was 
> draft-suh-mipshop-fmcast-mip6-00 already in July 2004. They are all 
> similar on this very abstract level that context is transfered via 
> HI/HACK messages. However, none of the proposals I have seen have really 
> tried to work out the problem in sufficient detail. (Even though we have 
> not completed the protocol details section, you already see from 
> comparisons that there are quite a number of issues such an 
> M-FMIPv6/M-PFMIPv6 protocol must resolve that haven't been addressed 
> before).
> 
> So from this abstract point of view, not much had happened since 2004, 
> why I was hesitant to present a longer list of references ...
> 
> ... but the latter we might change.
> 
> Best wishes,
> 
> Thomas
> 
> 
>>
>> 2010/3/5 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>:
>>> Hi all,
>>>
>>> following the focus of Dirk, we submitted a new draft on FMIPv6/PFMIPv6
>>> multicast extensions.
>>>
>>> This work was actually initiated back in the last meeting of MobOpts and
>>> delayed due to the initial PMIP focus of Multimob.
>>>
>>> Looking forward to your comments and to progressing the discussion!
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>> -------- Original Message --------
>>> Subject: New Version Notification for
>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01
>>> Date: Fri,  5 Mar 2010 07:08:30 -0800 (PST)
>>> From: IETF I-D Submission Tool <idsubmission@ietf.org>
>>> To: Schmidt@informatik.haw-hamburg.de
>>> CC: mw@link-lab.net,rkoodli@cisco.com,gorry@erg.abdn.ac.uk
>>>
>>>
>>> A new version of I-D,
> draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01.txt
>>> has been successfuly submitted by Thomas Schmidt and posted to the IETF
>>> repository.
>>>
>>> Filename:        draft-schmidt-multimob-fmipv6-pfmipv6-multicast
>>> Revision:        01
>>> Title:           Multicast Listener Extensions for MIPv6 and PMIPv6 Fast
>>> Handovers
>>> Creation_date:   2010-03-06
>>> WG ID:           Independent Submission
>>> Number_of_pages: 21
>>>
>>> Abstract:
>>> Fast handover protocols for MIPv6 and PMIPv6 define mobility
>>> management procedures that support unicast communication at reduced
>>> handover latencies.  Fast handover base operations do not affect
>>> multicast communication, and hence do not accelerate handover
>>> management for native multicast listeners.  Many multicast
>>> applications like IPTV or conferencing, though, are comprised of
>>> delay-sensitive real-time traffic and could strongly benefit from
>>> fast handover execution.  This document specifies extension of the
>>> Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy
>>> Mobile IPv6 (PFMIPv6) protocols to include multicast traffic
>>> management in fast handover operations.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>>
>>> --
>>>
>>> Prof. Dr. Thomas C. Schmidt
>>> ° Hamburg University of Applied Sciences                   Berliner Tor
7
> °
>>> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg,
Germany
> °
>>> ° http://www.haw-hamburg.de/inet                   Fon:
+49-40-42875-8452
> °
>>> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax:
+49-40-42875-8409
> °
>>> _______________________________________________
>>> multimob mailing list
>>> multimob@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multimob
>>>
>> _______________________________________________
>> multimob mailing list
>> multimob@ietf.org
>> https://www.ietf.org/mailman/listinfo/multimob
> 

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7
°
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany
°
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452
°
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409
°