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

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Fri, 14 February 2014 23:56 UTC

Return-Path: <prvs=115138566=schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5391A0479 for <multimob@ietfa.amsl.com>; Fri, 14 Feb 2014 15:56:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm7WyKTbmK3q for <multimob@ietfa.amsl.com>; Fri, 14 Feb 2014 15:56:55 -0800 (PST)
Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF801A00B0 for <multimob@ietf.org>; Fri, 14 Feb 2014 15:56:55 -0800 (PST)
Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 15 Feb 2014 00:56:52 +0100
Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id D9A5310679D7; Sat, 15 Feb 2014 00:56:52 +0100 (CET)
Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10250-08; Sat, 15 Feb 2014 00:56:51 +0100 (CET)
Received: from [192.168.178.49] (g231224147.adsl.alicedsl.de [92.231.224.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 2CE1D10679CF; Sat, 15 Feb 2014 00:56:51 +0100 (CET)
Message-ID: <52FEAD42.5000006@informatik.haw-hamburg.de>
Date: Sat, 15 Feb 2014 00:56:50 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: karagian@cs.utwente.nl
References: <201309251549114085692@gmail.com> <FF1A9612A94D5C4A81ED7DE1039AB80F4F3D509A@EXMBX23.ad.utwente.nl>, <52FD42E4.3000502@informatik.haw-hamburg.de> <FF1A9612A94D5C4A81ED7DE1039AB80F4F4204B3@EXMBX23.ad.utwente.nl>
In-Reply-To: <FF1A9612A94D5C4A81ED7DE1039AB80F4F4204B3@EXMBX23.ad.utwente.nl>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/gY0iMKfxBWL91l6uZtXz5kc5PF4
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob/>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 23:56:59 -0000

Hi Georgios,

thanks and et voila - the update is out.

On 14.02.2014 07:05, karagian@cs.utwente.nl wrote:

Please see answers inline:

> 
>> On 01.10.2013 08:06, karagian@cs.utwente.nl 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
>>>multimob@ietf.org
>>>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
>> gaoxlh@gmail.com
>> 2013-09-25
>>
>> _______________________________________________
>> multimob mailing list
>> multimob@ietf.org
>>https://www.ietf.org/mailman/listinfo/multimob
>>
>>
>>
>> _______________________________________________
>> multimob mailing list
>> multimob@ietf.org
>>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 °