Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast

[<[e-mail]>]

Hi Thomas,



Thanks for willing to work out my comments that can be IMHO considered also as WGLC related comments.



Regarding your proposed answers and questions, please see in line!



>
________________________________
> Van: Thomas C. Schmidt [[e-mail]]
> Verzonden: donderdag 13 februari 2014 23:10
> To: Karagiannis, G. (EWI)
> Cc: [e-mail]
> Onderwerp: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast

> Hi Georgios,

> thanks again for your thorough review and sorry for our delayed work on
> this.

> We're currently collecting all the previous comments/reviews and combine
> them in an updated version of the document ... which then is hopefully
> in good rough consensus of the WG.

> Please see answers inline:

> On 01.10.2013 08:06, [e-mail] wrote:

> > During the last multimob WG meeting in Berlin I had volunteerd to
> > provide comments on the last version of this draft.
> >
> > Here are these comments:
> >
> > Comment_1:The draft is useful since it is providing a solution for
> > seamless and fast handover for multicast applications by extending
> > existing seamless and fast handover solutions used for unicast
> > applications, which are the Mobile IPv6 Fast Handovers (FMIPv6)
> > specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6
> > (PFMIPv6) specified in RFC5949.
> >

> Thanks - we agree :-)

> > Comment_2: A motivation section is missing from the draft. In my opinion
> > it is very useful to include such section in this draft.

> Okay: a similar comment was made by Behcet. We will add a subsection
> (see below).

Georgios: Okay, great!

> >In particular,
> > this draft mentions that a seamless and fast handover solutions is
> > needed for multicast applications like IPTV. Other scenarios and
> > applications that will make use of such a solutions are Public
> > Protection and Disaster Relief (PPDR) scenarios, where mobile multicast
> > communications need to be supported between members of rescue teams,
> > police officers, fire brigade teams, paramedic teams, command control
> > offices in order to support the protection and health of citizens.
> >
> > In particular three main PPDR scenarios & application types could be
> > distinguished:
> >
> > 1)City security scenario:that can be used to support the day to day
> > safety and security of citizens.
> >
> > 2)Disaster recovery scenario that deals with the protection of people
> > and rescue teams during large scale natural or man-made disasters, like
> > flooding, earth quakes and nuclear disasters.
> >
> > 3)Temporary Protection PPDR scenario that deals with safety and security
> > of citizens visiting large planned events like football matches, pop
> > concerts and protest demonstrations.
> >

> A very good point - actually we are currently working with an airport on
> such crisis prevention and disaster recovery solutions, it is of
> emerging importance.

> We have added the following text:
>
>   -------------------------- snip ----------------------------------
> 1.1.  Use Cases and Deployment Scenarios
>
>     Multicast Extensions for Fast Handovers enable multicast services in
>     those domains that operate any of the unicast fast handover protocols
>     [RFC5568] or [RFC5949].  Typically, fast handover protocols are
 >    activated within an operator network or within a dedicated service
>     installation.
>
>     Multicast group communication has a variety of dominant use cases.
 >    One traditional application area is infotainment with voluminous
>     multimedia streams delivered to a large number of receivers (e.g.,
 >    IPTV).  Other time-critical news items like stock-exchange prices are
 >    commonly transmitted via multicast to support fair and fast updates.
 >   Both may be mobile and both largely benefit from fast handover
 >    operations.  Operators may enhance their operational quality or offer
 >    premium services by enabling fast handovers.

>     Another traditional application area for multicast is conversational
>     group communication in scenarios like conferencing or gaming, but
>     also in dedicated collaborative environments or teams.  Machine-to-
>     machine communication in the emerging Internet of Things is expected
>     to generate various additional mobile use cases (e.g., among cars).
>     High demands on transmission quality and rapidly moving parties may
>     require fast handovers.

>     Most of the deployment scenarios above are bound to a fixed
>     infrastructure with consumer equipment at the edge.  Today, they
>     are thus likely to follow an operator-centric approach like PFMIPv6.
>     However, Internet technologies evolve for adoption in
>     infrastructureless scenarios at desaster recovery, rescue, crisis
>     prevention and civil safety.  Mobile end-to-end communication in
 >    groups is needed in Public Protection and Disaster Relief (PPDR)
>     scenarios, where mobile multicast communication needs to be supported
>    between members of rescue teams, police officers, fire brigade teams,
>     paramedic teams, command control offices in order to support the
>     protection and health of citizens.  These use cases require fast and
>     reliable mobile services which cannot rely on operator
>     infrastructure.  They are thus predestined to running multicast with
>     FMIPv6.

Georgios: Okay, great!


>   -------------------------- snap ----------------------------------

> > Comment_3: List the requirements that need to be satisfied by this
> > solution. You may use as example Section 1.1 of
> > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt
> >

> I'm not sure here: Different from the rather 'individual' solution
> presented in draft-ietf-multimob-handover-optimization, the fast
> handover document works out multicast extensions for the existing fast
> handover protocol standards. So the requirement basically reads
>
>    * multicast shall be transparently included in *fmipv6 handover
> operations without harming anything else.

> But this is very explicitly stated in the abstract and introduction, so
> an additional requirements section would be either completely trivial,
> or a repetition of what has been already said.

> Do you think of any particular aspect we forgot to mention?

Georgios: Yes, see below. Actually, I have reused some of the requirements listed in:
http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-07.txt

Possible requirements to include:

  o  The solution MUST be applicable to any kind of MN, in such a way that any type of mobile node
      in a PMIPv6 domain being served with multicast traffic can benefit
      from the fast handover solution.

   o  The solution MUST NOT impact existing multicast protocols.

   o) The multicast MIPv6 and PMIPv6 Fast Handover solutions MUST optimize the handover performance, in terms of delay,
      for multicast communication to the order of the maximum delay needed for link switching and signaling between Access Routers (ARs) or Mobile
      Access Gateways (MAGs).

   o  The solution SHOULD minimize the number and extent of additional
      support (i.e., capabilities) required in the network, aiming at an
      easier deployment.

   o  The solution MUST NOT impact deployments of legacy implementations
      of [RFC5213] and [RFC6224].


> > Comment_4: Provide a more detailed message flow description, similar to
> > the one that is given in Section 5.1.2 in±
> >
> > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt
> >
> > This comment holds for Figures 2, 3, 4, 5
>

> This again is a bit unclear to me.

> The difference between the figures in
> draft-ietf-multimob-handover-optimization and our Figs 2 - 5 are

>   (a) other entities are involved
>   (b) there are some comments on states in the figures from
> draft-ietf-multimob-handover-optimization

> In fact, the fast handover operations are much simpler than operations
> in draft-ietf-multimob-handover-optimization, and directly plug into the
> unicast protocol elements.

> It is more 'natural' to compare with the call flows in [RFC5568] and
> [RFC5949].

> If you do so, what would you propose to add?

Georgios: Okay, I will not insist to add more information in the figures, but IMHO, the operation
of the protocol can be made very clear when each message sequence chart step
(i.e., each message exchange) is described in detail.


> > Comment_5: There is no description on how this draft, which specifies a
> > mobile multicast listener support solution, can be used in combination a
> > the mobile multicast senders, solution e.g.,
> > http://www.ietf.org/id/draft-ietf-multimob-pmipv6-source-05.txt.
> >
> > There are scenarios and applications that require the use of these two
> > solutions simultaneously.
> >

> You are right. draft-ietf-multimob-pmipv6-source does not touch the fast
> handover solution. The current document is bound to listener operation
> which was a result of the charter.

> The best way is probably to add the sender aspects to an appendix, as a
> free gift let's say.
>
> Do you agree?

Georgios: Yes, I agree, this will be great!

Best regards,
Georgios


> Thanks again & best regards
>
> Thomas


>>
>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Multicast Mobility Working Group of the IETF.
>>
>>       Title           : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers
>>       Author(s)       : Thomas C. Schmidt
>>                          Matthias Waehlisch
>>                          Rajeev Koodli
>>                          Godred Fairhurst
>>                          Dapeng Liu
>>       Filename        : draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt
>>       Pages           : 27
>>       Date            : 2013-02-25
>>
>>Abstract:
>>   Fast handover protocols for MIPv6 and PMIPv6 define mobility
>>   management procedures that support unicast communication at reduced
>>   handover latency.  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 will 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.  This multicast support is provided first at the
>>   control plane by a management of rapid context transfer between
>>   access routers, second at the data plane by an optional fast traffic
>>   forwarding that may include buffering.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast
>>
>>There's also a htmlized version available at:
>>http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-01
>>
>>A diff from the previous version is available at:
>>http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-01
>>
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>multimob mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/multimob
>
> = = = = = = = = = = = = = = = = = = = =
>
>
> 　　　　　　　　致
> 礼！
>
>
> Shuai Gao
> Associate Professor
> National Engineering Lab for Next Generation Internet Interconnection
> Devices
> Beijing Jiaotong University
> Beijing, China, 100044
> [e-mail]
> 2013-09-25
>
> _______________________________________________
> 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] °