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

["Thomas C. Schmidt" <[e-mail]>]

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.

> 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.

> 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.

> 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.

> 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.

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

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

Best,

Thomas


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Frank Xia
> Sent: Friday, March 12, 2010 10:22 AM
> To: 'Thomas C. Schmidt'; 'Min Hui'
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Thomas C. Schmidt
> Sent: Friday, March 12, 2010 3:41 AM
> To: Min Hui
> Cc: [e-mail]
> 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 <[e-mail]>:
>>> 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 <[e-mail]>
>>> To: [e-mail]
>>> CC: [e-mail],[e-mail],[e-mail]
>>>
>>>
>>> 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: [phone]
> °
>>> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone]
> °
>>> _______________________________________________
>>> multimob mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/multimob
>>>
>> _______________________________________________
>> multimob mailing list
>> [e-mail]
>> 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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °