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