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

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 13 February 2014 22:10 UTC

Return-Path: <prvs=114a516f4=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 58FE71A040C for <multimob@ietfa.amsl.com>; Thu, 13 Feb 2014 14:10:54 -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 tyiOjM6p4MHV for <multimob@ietfa.amsl.com>; Thu, 13 Feb 2014 14:10:50 -0800 (PST)
Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id DA6131A041B for <multimob@ietf.org>; Thu, 13 Feb 2014 14:10:49 -0800 (PST)
Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 13 Feb 2014 23:10:47 +0100
Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 79B6E10679D7; Thu, 13 Feb 2014 23:10:47 +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 17409-05; Thu, 13 Feb 2014 23:10:45 +0100 (CET)
Received: from [192.168.178.49] (g231108249.adsl.alicedsl.de [92.231.108.249]) (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 1B69810679CF; Thu, 13 Feb 2014 23:10:45 +0100 (CET)
Message-ID: <52FD42E4.3000502@informatik.haw-hamburg.de>
Date: Thu, 13 Feb 2014 23:10:44 +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>
In-Reply-To: <FF1A9612A94D5C4A81ED7DE1039AB80F4F3D509A@EXMBX23.ad.utwente.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/eFYnyz5dNJR8js3FYaGCWEQ7lWg
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: Thu, 13 Feb 2014 22:10:54 -0000

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

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