Re: [Roll] multicast & MLD on LLN

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 90D7E1A8961 for <>; Wed, 15 Oct 2014 13:33:21 -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 V9q1i8e88LZu for <>; Wed, 15 Oct 2014 13:33:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 653BE1A7001 for <>; Wed, 15 Oct 2014 13:33:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1413405200; bh=YDSRjoIbW5nBhg8xBOpxKNZxvpW1dZjzemxnvICNbNk=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=JaqqmQJMAXqc3oPD/a6YEIKNmgrCayVEOH3aqcGOYEY8eyajFvqrZjfGkJOSMf8s8IYO45ByPNkYjAdzmDUZT1Ahjge0zVTtkUkFe1F3svAOiVeMOWF9nXDefQHiphbFNE7US+afa1in4DWwohObFgggdCIY83YyU4ebYxlIz2s=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; b=Mu1KVN1F7Sd7ZF5vAOzd7w3KBUkyzD38m41kUMDS2Wn5bOFQXIvbQd02HQ3oRJfyfonoH0KDWN+taXphTJ9ynbl0h5/X1lTdiXEBNOi5EiJxIAg4Ar7mVt7Dt3VCxKejOba4H4tJ4VVShLpVNdN2hPIAOU1QKz09YrJudGxId/Q=;
Received: from [] by with NNFMP; 15 Oct 2014 20:33:20 -0000
Received: from [] by with NNFMP; 15 Oct 2014 20:33:19 -0000
Received: from [] by with NNFMP; 15 Oct 2014 20:33:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1413405199; bh=YDSRjoIbW5nBhg8xBOpxKNZxvpW1dZjzemxnvICNbNk=; 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=oZ5OkmhJPjM6MghJN5FTZwyl41r8qBW7kc/jBgIvQ6Te7sKLGBhREPCO4DBFbfESp1OZZqI+J4VL5v3jQpmqEecO10VgynfbshmyzX4uwn+x9gKTX7e99vtLPRIJJNkHIYH+q3iWx2X4UnccMMDF0rd/3rRFfq4WbGABDc6ZDjI=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 2YU6cbIVM1nh6fIqXe7WvOJNL4e4AaiCU8mQvxnrevwNvq8 Ty_aS8Na6krSEX1XEdd0wADCRkuwCiDIVZeDtFJ49QBt0b4zQz26xh5Dg_iX vz7VcZfmwsH2Js6Wg9rjoK.PjtUG124iKV0fkkCyGt8d0w1oYDZPdTbgH5Qt T_X_0iUX8qphC9A6ykYJuchTZaJvX5yxTS_G1Ti23wgvkpOzVHW3AUuqPRCW NZqw2dPhTkkxUhgMo.rrzxiT5_Vsp18VgBONl.rvWzov8WVwsGvhBpEfrxU0 CD723fD8pzv1QfdGAuMkaJnX_CZphHTn9MLanDOMAcRWW_hmZAgEfrAGGDJT OB0SuBJgqHHIJ90rUAJ0Upavae8IO9lx1ZJrXOgjL8bKG4fVyqdCHK75UPip RgFctmrjTuNzF99OBFI7SZoLuyb.x89fMtrAiOIv8WjVNhFHvaFL8lBBfFpK E7jP9g4c.b9AmpZ4LyFk9M8X6Xmw2qI7XpaRTcTWD67UrRdM3wO4Lw3GFyG. oaCjub1IwW6M4eEG0M_r1qz.QCZ.GmDeM8Fx8JzaW
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
User-Agent: Microsoft-MacOutlook/
Date: Wed, 15 Oct 2014 13:33:16 -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:33:21 -0000

.... By the way, I worked on an  application using IPv4 multicast that
worked nicely as defined below.  My previous company did the original
IP-enabling for NASDAQ.   There were tiers of service that mapped to IPv4
multicast groups.
Of course with the topological nature of IPv4, this was a much simpler
problem (plus not having an LLN in the middle).

The key feature was the ability to opt-in/opt-out of the multicast groups
and the ability for the network to route traffic appropriately depending
on membership of the multicast group.  Hopefully we can come up with
something similar.....


On 10/15/14 1:23 PM, "Don Sturek" <> wrote:

>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
>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
>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
>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
>the network operator) and the ability for the forwarding of the multicast
>traffic to avoid saturating the network with broadcast traffic that is
>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
>>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
>>>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