Re: [Roll] multicast & MLD on LLN

"Pascal Thubert (pthubert)" <> Wed, 15 October 2014 14:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 252251A1B20 for <>; Wed, 15 Oct 2014 07:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ml9qGkrGAyOZ for <>; Wed, 15 Oct 2014 07:54:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15FF41A872F for <>; Wed, 15 Oct 2014 07:54:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13481; q=dns/txt; s=iport; t=1413384867; x=1414594467; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ruvQMt8/BpFhWAcQ6ypIzAB2OOkQ0o7sOdXgaUdsZ4o=; b=XZnEtJHWWvb8eQGMnUQMPFz+azIUW+F1OoQxzpizKfSV4LxRTGhk6oCn 1qso287icbm9oVXd9POL3H9GZHtBpiUcSIUre8HLrKhW8tRDZNYHyPkIG xIQ8ccXffejZuj4xIvsHTSSqiFcRdG8bsPNrvhrXPZrd2XABp7rdmgnjz A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.04,724,1406592000"; d="scan'208,217"; a="87200426"
Received: from ([]) by with ESMTP; 15 Oct 2014 14:54:25 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9FEsPoL030412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 14:54:25 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 09:54:25 -0500
From: "Pascal Thubert (pthubert)" <>
To: "Turner, Randy (" <>
Thread-Topic: [Roll] multicast & MLD on LLN
Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SJwxmTnQ
Date: Wed, 15 Oct 2014 14:54:25 +0000
Deferred-Delivery: Wed, 15 Oct 2014 14:54:00 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842E1C040xmbrcdx01ciscoc_"
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 14:54:34 -0000

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<>