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

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 13 Feb 2014 23:10:44 +0100

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, [email-masked] 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).

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

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

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

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

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
>>[email-masked]
>>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
> [email-masked]
> 2013-09-25
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>
>
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> 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 °

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 14 Feb 2014 00:25:34 +0100

Hi Shuai,

many thanks for your earlier review and sorry that we picked up work on
this late.

We're now catching up and try to finalize the document (as it had been
struck by an unexpected last call ;) ).

On 25.09.2013 09:49, Shuai Gao wrote:

> As promised at IETF-87, I have reviewed the Fast Handover draft. Overall the I-D is in very good shape. I have a few comments for your consideration.
> 
> 1)	P3: improve these handover delays for unicast communication to the order of the maximum delay needed for link switching and signaling between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis]. ==> improve the performance of handover delays…… Also, what does “to the order” mean in this sentence?

You're right, this sentence is a bit imprecise. We changed to

   Mobile IPv6
   Fast Handovers (FMIPv6) [RFC5568], and Fast Handovers for Proxy
   Mobile IPv6 (PFMIPv6) [RFC5949] improve the performance of these
   handover delays for unicast communication to the order of the maximum
   of the delays needed for link switching and signaling between Access
   Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis].

"to the order" means that the delay is approximately as stated (plus
noise). In this reference, the indicated delays were identified as the
leading terms in a series of delays.

> 
> 2)	P5: The specified mechanisms apply when a mobile node has joined and maintains… ==> The specified mechanisms apply when a mobile node has joined and maintained…

I don't think so: The sentence basically says that handover mechanisms
apply to active group membership ... this is "has joined and maintains"
or "continues to maintain".

On the contrary, if group membership is not maintained anymore, i.e.,
lost, no multicast handover is required.

> 
> 3)	P6: Depending on the specific network topology though, multicast traffic for some groups … ==> delete the word “though” in this sentence.

O.K.

> 
> 4)	P6: that make it undesirable to forward the multicast traffic.The PAR can… ==> that make it undesirable to forward the multicast traffic. The PAR can…

Thanks, fixed.

> 
> 5)	P7: The NAR implements an MLD proxy [RFC4605] providing host-side behaviour on behalf of the upstream PAR. ==>  Here, “on behalf of the upstream PAR” is little confusing. I suggest to modify to ” towards the upstream PAR.”

Yes, good suggestion - done.

> 
> 6)	P9: In figure 3, FBU has contained the Multicast Option, and thereby both PAR and NAR have known the related multicast information. So the question is whether it’s necessary to include Multicast Option in the HI message here?

As inherited from unicast, FBU is tunneled to PAR and NAR is not
intercepting messages. HI/HACk with MobOpts is performed to keep the
access router in sync. It may be that native multicast traffic arrives
quickly from the local join after handover, but then membership transfer
is terminated from NAR (explicitly without timeout). If native routing
is slow, the tunneling of multicast traffic will be appreciated.

Does this address your comments exhaustively?

If yes, it would be good to hear your opinion on the WG last call.

Best regards,

Thomas

> ======= 2013-02-26 07:44:10 您在来信中写道：=======
> 
>>
> National Engineering Lab for Next Generation Internet Interconnection Devices

--

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 06:05:38 +0000

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 [[email-masked]]
> Verzonden: donderdag 13 februari 2014 23:10
> To: Karagiannis, G. (EWI)
> Cc: [email-masked]
> Onderwerp: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast

> Okay: a similar comment was made by Behcet. We will add a subsection

Georgios: Okay, great!

>     infrastructure.  They are thus predestined to running multicast with

Georgios: Okay, great!

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

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

> The best way is probably to add the sender aspects to an appendix, as a

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

Best regards,
Georgios

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 14 Feb 2014 12:12:12 +0100

Hi Georgios,

thanks again for your comments: we are now working on polishing the 
draft for the new submission (deadline today) ... and see the details then.

Best

Thomas

On 14.02.2014 07:05, [email-masked] wrote:
> ------------------------------------------------------------------------
> *> Van:* Thomas C. Schmidt [[email-masked]]
> *> Verzonden:* donderdag 13 februari 2014 23:10
> *> To:* Karagiannis, G. (EWI)
> *> Cc:* [email-masked]
> *> Onderwerp:* Re: [multimob] I-D
> Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast
>
>> Hi Georgios,
>
>     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).
>

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 15 Feb 2014 00:56:50 +0100

Hi Georgios,

thanks and et voila - the update is out.

>        of [RFC5213] and [RFC6224].

We've added a paragraph of requirements to the introduction - this
should cover all there is needed to clarify the rationale behind the
design - Okay?

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

Unfortunately, time did not permit to add this appendix - we will
contribute prior to IETF London and then submit a version once the
submission tool is open again. As this is supplementary material,
further discussion and progressing of the draft should not be affected.

see you in London!

Thomas

--