Re: [Roll] multicast & MLD on LLN

peter van der Stok <stokcons@xs4all.nl> Thu, 16 October 2014 07:17 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4301A037A for <roll@ietfa.amsl.com>; Thu, 16 Oct 2014 00:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.535
X-Spam-Level:
X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 LyMzxwxkdAlR for <roll@ietfa.amsl.com>; Thu, 16 Oct 2014 00:17:21 -0700 (PDT)
Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925791A036C for <roll@ietf.org>; Thu, 16 Oct 2014 00:17:20 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id s9G7HAV3057971; Thu, 16 Oct 2014 09:17:11 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-654-1-252-223.w92-133.abo.wanadoo.fr ([92.133.143.223]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Oct 2014 09:17:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 16 Oct 2014 09:17:10 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <D063F2D8.2EA57%d.sturek@att.net>
References: <aef2e75903e84afe988ff58d04a0fc56@DB4PR01MB0431.eurprd01.prod.exchangelabs.com> <6B9D200B-58B8-423C-ADEA-A6C61F73748B@cisco.com> <AC402B16-8AD9-4033-A7F3-780725F9BAB8@tzi.org> <CABOxzu0-MLJ9esL55oxj_eQRpzXJrf6XErV+jd6UeZ2vuF0H5w@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD842E1C49A@xmb-rcd-x01.cisco.com> <CABOxzu2d_JNFQ+Nu9mw=pW2TPG7qxFm6ocLFvSXChvA_By3xVw@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD842E1C6B0@xmb-rcd-x01.cisco.com> <D063F2D8.2EA57%d.sturek@att.net>
Message-ID: <8024d634f6820545d3d8200fc3585572@xs4all.nl>
X-Sender: stokcons@xs4all.nl (bvZrQqdYbumAwowfrPrVP+vbB9fvg2yG)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/z9ObaXegGXSZvVjAniqDHx4SIUM
Cc: "IJsbrand Wijnands \(iwijnand\)" <ice@cisco.com>
Subject: Re: [Roll] multicast & MLD on LLN
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2014 07:17:24 -0000

Hi Don,

> 5) I don't want to incur the MPL overhead of all multicast traffic
> flooding all 5000 devices/forwarded up to 15 hops in my network when I
> send these special multicast group messages.


I think this is possible with current MPL by managing which nodes are 
MPL forwarders.
First requirement is to select a multicast address per group of 
destination nodes.
Second, enable the interfaces for a selection of nodes which are 
supposed to forward and which are supposed to receive only messages with 
this particular MC address.

Today, this must be done by hand.
Automating it is an option.

Peter

Don Sturek schreef op 2014-10-15 18:58:
> Hi Pascal,
> 
> Let me try to provide a use case.
> 
> The network is a Neighborhood Area Network. The application can be
> something like street lights or a smart metering AMI (really any
> collection of devices that are networked centrally with a non-trivial
> number of devices in the network)
> 
> Here are some details:
> 1) Around 5000 devices in the network total. There can be as many as
> 15 hops from the DODAG to the furthest leaf node in the network.
> 2) One border router that supports ROLL RPL. All devices in the
> network are ROLL RPL aware (some as routers, some end devices). What
> would be really nice is if we could have non-RPL aware end devices
> also in the network but I think that is another topic :-)
> 3) We support all of the mandatory multicast groups (eg all routers)
> in our networked devices
> 4) From an application point of view, we want to use special
> application-defined multicast groups for things like:
>  A. Control a geographic collection of street lights (like all the
> ones in an area where there is to be a festival this evening)
>  B. Control a geographically diverse collection of devices that are
> not the entire population (for example, I want a message sent to all
> of my pre-pay customers which are mainly focused in some
> neighborhoods, less in others)
> 5) I don't want to incur the MPL overhead of all multicast traffic
> flooding all 5000 devices/forwarded up to 15 hops in my network when I
> send these special multicast group messages.
> 
> What would be great in the above scenario is if the multicast traffic
> only traversed the portions of the network where members of the
> multicast group exist (eg, don't forward down portions of the tree
> where there are no multicast members). MPL as a flooding mechanism
> fails this goal (which is fine with relatively few devices but not so
> when talking about 5000 devices/24 hops!
> 
> Is the above good enough to start a discussion on how to solve the
> problem?
> 
> Don
> 
> From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
> Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Date: Wednesday, October 15, 2014 9:38 AM
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Cc: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>
> Subject: Re: [Roll] multicast & MLD on LLN
> 
> Hello Kerry:
> 
> Or Roll Multicast Operations ( : ROLLMOps? : )
> 
> Basically, BIER needs a preexisting tree structure and RPL is designed
> to build and maintain one. They need a root node and we have one.
> 
> On paper it is a perfect match. Now the question is whether there is
> enough need for that work, and then we'll find a place to make it
> happen.
> 
> To start with, would you have a specific use case of multicast in LLNs
> where MPL is less applicable than the classical tree-based forwarding?
> 
> With that, we could connect into the BIER effort.
> 
> Strong points:
> 
> - very limited state in the nodes, could even be used for unicast,
> independent on the number of groups and the size of the network
> 
> - bit aggregation easy to advertise in existing DAOs, low cost there
> too
> 
> - transparent support for v4 and v6 (since it is an overlay)
> 
> Weak points:
> 
> - extra encapsulation (since it is an overlay)
> 
> - new routing and forwarding operation to implement in the nodes
> (bitwise)
> 
> - limited number of nodes per DODAG (roughly 100).
> 
> Cheers,
> 
> Pascal
> 
> FROM: Roll [mailto:roll-bounces@ietf.org] ON BEHALF OF Kerry Lynn
> SENT: mercredi 15 octobre 2014 18:25
> TO: Routing Over Low power and Lossy networks
> CC: IJsbrand Wijnands (iwijnand)
> SUBJECT: Re: [Roll] multicast & MLD on LLN
> 
> On Wed, Oct 15, 2014 at 12:00 PM, Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
> 
> Or form a new group J
> 
> What about Routing Over Complete Kaos?
> 
> More seriously, it's probably a good idea to goto through the BoF
> sequence again to analyze what's left to be done.
> 
> I can certainly see an analog of what the 6lo is to 6LoWPAN, but for
> ROLL.
> 
> For me the first question is whether multicast in the LLN would be
> RPL-
> 
> dependent, or have RPL-like features (e.g. dependence on a DODAG).
> 
> That could argue for doing the work in ROLL or a follow on group
> 
> (ROLLMAN?)
> 
> At least some of the 6lo proposals (MS/TP comes to mind) are not mesh
> 
> networks, but still constrained from a host and bandwidth perspective.
> 
> I like the topology-independence of MPL, but I think work still needs
> to be
> 
> done to see how far it is from optimal (in terms of energy and
> bandwidth
> 
> usage) under different operating conditions and parameter settings.
> 
> -K-
> 
>> Cheers,
>> 
>> Pascal
>  _______________________________________________ Roll mailing list
> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll [1]
> 
> Links:
> ------
> [1] https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll