Re: [Roll] multicast & MLD on LLN

"Turner, Randy" <> Wed, 15 October 2014 15:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 213591A86F4 for <>; Wed, 15 Oct 2014 08:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u0XaEpC0MmHP for <>; Wed, 15 Oct 2014 08:14:29 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe00::705]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A93911A86FA for <>; Wed, 15 Oct 2014 08:14:27 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 15:01:51 +0000
Received: from ([]) by ([]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 15:01:51 +0000
From: "Turner, Randy" <>
To: "Pascal Thubert (pthubert)" <>
Thread-Topic: [Roll] multicast & MLD on LLN
Thread-Index: Ac/kvGg9glP5Rg5dTyCqZKTLnjPO8AAX0deAANsOb4AAAEKRIw==
Date: Wed, 15 Oct 2014 15:01:51 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0431;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0365C0E14B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(24454002)(41574002)(31966008)(36756003)(97736003)(19580395003)(19580405001)(82746002)(15975445006)(21056001)(80022003)(83716003)(20776003)(64706001)(87936001)(85306004)(66066001)(2656002)(19625215002)(105586002)(106356001)(76176999)(50986999)(54356999)(40100003)(110136001)(107046002)(122556002)(92726001)(86362001)(101416001)(85852003)(92566001)(33656002)(4396001)(120916001)(95666004)(46102003)(16236675004)(19617315012)(76482002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0431;; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_9F844C43F0EA4B8F8E632506BE341C3Dlandisgyrcom_"
MIME-Version: 1.0
Cc: "Greg Shepherd \(shep\)" <>, Routing Over Low power and Lossy networks <>, "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 15:14:35 -0000

I will be in Hawaii

Thanks Pascal!!


Sent from my iPhone

On Oct 15, 2014, at 4:55 PM, Pascal Thubert (pthubert) <<>> wrote:

Hello again Randy:

We had a talk with Greg and Ice, and it seems to me that the BIER approach could be perfectly applicable to a RPL LLN, mostly for small multicast packets or on a PHY that is not too sensitive to the encapsulation such as 15.4G.

Basically for us, the method would leverage the backbone router to assign a bitmap that represents the listeners in a DODAG. If we encode the BIER bitmap in an IPv6 address, that would mean at most about 100 listeners per DODAG. And then we can build multiple RPL instances if we need more than that.

Do you have a use case that would require multicast? If so, would you care to tell us a bit more, or, better, contribute some text to the use case document?

If you are in Hawaii, BIER will be on the first PM slot on Monday, right before DETNET.


From: Roll [] On Behalf Of Pascal Thubert (pthubert)
Sent: samedi 11 octobre 2014 08:22
To: Routing Over Low power and Lossy networks
Cc: IJsbrand Wijnands (iwijnand)
Subject: Re: [Roll] multicast & MLD on LLN

Hello Randy...

Great point!

I think we need a draft, even if informational, to produce a clear explanation of how that could work, extending the work I started on unicast with 6775reqs.

The way I see it, MLD would make sense between a host that is not even a RPL leaf and the 6LR. Arguably, we could probably extend NS ARO to get a similar outcome to reduce the code footprint. Then the 6LR would turn that into DAO.

This is collapsed, as you point out, for RPL leaves and routers. We already extended DAO to get a similar outcome as a recursive MLD proxy along a tree. The goal was to avoid MLD there; but then an I-D reviewed by multicast specialists would validate that we missed no important point.

I dug a bit and found some IPR that we need to sort out. Cisco has some that mostly covers the BBR that turns the DAOs into MLD again, and for that much we can RAND if work starts.

Finally I'm looking at BIER see how their ideas could apply to LLNs...



Le 10 oct. 2014 ? 21:22, Turner, Randy <<>> a ?crit :
I know there's a section on multicast in RFC 6550, which essentially states that the equivalent of a multicast "join" would be a DAO packet specifying multicast, rather than unicast addresses. It says that this method is not to be relied on in a non-storing network - however, I'm assuming we can still use this if we implement just a "lightweight storing mode", keeping track of only multicast addresses.  In this case a multicast "leave" would be when the DAO entry "times out"  - does this behavior obviate the need for MLD operation on this "quasi" storing mode LLN ?



This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Roll mailing list<>