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 °
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… Shuai Gao
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… karagian
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… Thomas C. Schmidt
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… Thomas C. Schmidt
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… Thomas C. Schmidt
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… karagian
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… Thomas C. Schmidt
- Re: [multimob] I-D Action:draft-ietf-multimob-fmi… Thomas C. Schmidt