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

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

Hi again Frank,

please see inline:

Frank Xia wrote:

> -----Original Message-----
> From: Thomas C. Schmidt [mailto:[e-mail]] 
> Sent: Friday, March 19, 2010 4:06 PM
> To: Frank Xia
> Cc: 'Min Hui'; [e-mail]
> 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?
>

Thomas => This I commented on earlier: this should not be a big go.

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

Thomas => Yes, but if this step is omitted, an FMIP MN has no option to
take actions. But pure FMIP is still - even though assisted by ARs -
tied to the end-to-end paradigm. I tend to respect this ... as it
sustains the option for proactive operations at the MN (e.g., taking a
choice on where to subscribe what -> see RFC 5757 for more detail).

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

Thomas => see above.

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

Thomas => It could query - but this causes delays and may be misleading
with respect to the MN (that may have multiple attachments).

>> 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: [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] °