Hi Georgios, thanks and et voila - the update is out.
On 14.02.2014 07:05, [email protected] wrote: Please see answers inline: > >> On 01.10.2013 08:06, [email protected] 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]. > 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? > >> > 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! 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 >>> >>>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 protected] >>>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 protected] >> 2013-09-25 >> >> _______________________________________________ >> multimob mailing list >> [email protected] >>https://www.ietf.org/mailman/listinfo/multimob >> >> >> >> _______________________________________________ >> multimob mailing list >> [email protected] >>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 ° -- 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 [email protected] https://www.ietf.org/mailman/listinfo/multimob
