Re: [Roll] multicast & MLD on LLN

Don Sturek <> Wed, 15 October 2014 20:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F7331ACC87 for <>; Wed, 15 Oct 2014 13:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.512
X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=2.511, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kJoXEjvDi0TR for <>; Wed, 15 Oct 2014 13:24:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 091D61ACC89 for <>; Wed, 15 Oct 2014 13:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1413404641; bh=DqUehMGUiYeSVo9Bz+ELZpgazMeY1c4AyFBvAXl01Dk=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=n5TEkMcCunymvxbuv2gE+Ews4nfPqWKd6oockAlCkKbZagFfMrOcYqmlFG5GP1D50eIyBaFWfQcq2IxDJokELG6vTY5lFoOC3iXeqKP4ORXBqqSNO8nMTYb8x5Alc4Qfco0ORtWXZqy8cjnZ6TmZffwkiQKlTtoue4ihEt3o5i0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; b=DMPf3lnQHAKIEgt7gnLMoACRjZYKNrzHdDwv43+dc1QmvxgA5wASO5PdY4SGRvh6udqZWxxWC4EVF0on+t6x2MlzdQ1EtOWYFnZjDmd02AKm2euEm8B00fcLNhltJxeoz9WVFkJHoH2u58+eWl/oZnBFllI+q1JxJgmPmP0ViDQ=;
Received: from [] by with NNFMP; 15 Oct 2014 20:24:01 -0000
Received: from [] by with NNFMP; 15 Oct 2014 20:24:01 -0000
Received: from [] by with NNFMP; 15 Oct 2014 20:24:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1413404641; bh=DqUehMGUiYeSVo9Bz+ELZpgazMeY1c4AyFBvAXl01Dk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=1nmgUk00t6h5y9Ws2CzcpbHHdlympnqEMFH9tQwJIxdm1xqZ20qgsx4Plty7J/oMH48zRpoKh3HpqYHWUme5gAHa8G1hjkXbELT/FFaP7uL5vGlRD/7SwFFTCpW2swQvKBhkVbim1m7Bab8DO4/KOfuxNH3KaK9re6pUhqQiybA=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: flbN_6sVM1n87WDQ7.wrzU1w.JHeI.K._QtYkPRcespmIM8 IUw84cOvKL4jjaCldGXirbz4Z_rzfKmKlNRVv4JgAahTNBE_KYHkdrIXk9iP 6SgVMvrVPn4yoGbEKHfpu2qU0Bzu1YGpUGoBTzukT6erfK6f25rBSTyiw0Po GzM1g.hjzp4jvNruUOoKc1bySZaLX2gzLmGAKKSpCHAHpuKeCkdV.XjLaPte LJJtNxuj7F5Aohnfmeb6CIyPhKgTSvIwCyxE5vnAPGznqEXKKrWdm86BnMfk I_0xb1g2uz1VIOKVXk.H4XFPnQ7pXLc7y88O82rVed8ApYfDQA3hVr4D6QGk IT6J0UQgE1XB49IYAzG0gEaCVBDL9ezqLQjFRk2g4OPILsAM_ofqxcsi0MRK tqq0DjXKvNTKC0ZdpDJ3gX2Mp2M1XEgRWnHJBDNinA14YN0tR1h4yI0G5CXn a4vfQqScHRIc8Jn.tswV0gZbWO1fAAPAqnqgHyo21i9ZTV3cQUFEeArQtVK6 0og7KSTEk4wpHVwXttN2Od.Vc_ecTS79rjRBxyU3L
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
User-Agent: Microsoft-MacOutlook/
Date: Wed, 15 Oct 2014 13:23:56 -0700
From: Don Sturek <>
To: Routing Over Low power and Lossy networks <>
Message-ID: <>
Thread-Topic: [Roll] multicast & MLD on LLN
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: "IJsbrand Wijnands (iwijnand)" <>
Subject: Re: [Roll] multicast & MLD on LLN
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Oct 2014 20:24:05 -0000

Hi Carsten,

On your questions posed below:
1)  We are using non-storing
2)  Distribution of group sizes.   This is a tough question.  I think some
groups may be nearly the size of the entire network (say I want to send a
message to all of my smart meters but don't need the relays or AP's to get
the message).   Some may be regionally focused and therefore small (eg, I
have an outage and I want the smart meters in one location to report on
the quality of the electric service they are seeing).   Some may be
geographically focused (like the example for the street light application
wanting to manage street lights around a festival).  I think the right
answer here is we want applications to opt in/opt out of application
multicast groups and we want the network forwarding to be smart enough to
not flood the entire network if that is not needed.  I know that is not
the answer you are particularly looking for but I think that is the right
answer.  By the way, if I have an application multicast group that is
nearly the entire population of the network, it would be really great if
the network operator knew this and reduced those types of multicast
transmissions.   The biggest savings would be where we really only want to
hit devices in a certain georgraphy and now we don't need every device in
the network to see that traffic.....

If we do this right, then we will arm the application developers with the
ability to create their own groups (with some knowledge/understanding from
the network operator) and the ability for the forwarding of the multicast
traffic to avoid saturating the network with broadcast traffic that is not
needed for that application multicast group.


On 10/15/14 1:08 PM, "Carsten Bormann" <> wrote:

>Hi Don,
>this sounds exactly like a use case our multicasting approach can solve.
>Two questions:
>1) Are you using storing or non-storing mode for RPL?
>2) For the kinds of groups below, was is the likely distribution of group
>Grüße, Carsten
>On 15 Oct 2014, at 18:58, Don Sturek <> wrote:
>> 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)
>Roll mailing list