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 protected]]
*> Verzonden:* donderdag 13 februari 2014 23:10
*> To:* Karagiannis, G. (EWI)
*> Cc:* [email protected]
*> 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, [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].
> 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
[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
