Re: [Roll] multicast & MLD on LLN

"Pascal Thubert (pthubert)" <> Sat, 11 October 2014 06:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DE861A1B06 for <>; Fri, 10 Oct 2014 23:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kDAkCw5s9lIC for <>; Fri, 10 Oct 2014 23:22:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 853AA1A1B01 for <>; Fri, 10 Oct 2014 23:22:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7589; q=dns/txt; s=iport; t=1413008531; x=1414218131; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fHTMR68Fx9yHnR9ySkZ9EVx1eb+8c2LotX2+jB/f/EE=; b=A3yO+ZDC6hBRxG4xusLM7ACbLdd/+/RlNyu/m9tOcro34xz1VkksWk2k KwVKuGUWVCtbmqP+H9mJCJPvLsLep9F4OpZXFM6U5W2jJJt4trhuxkQOx iZDcNi7aijawwT1LchgqGbk1abICnG9H3GdzN4lJOJMf1jj+pPNWEB/lq 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,697,1406592000"; d="scan'208,217";a="362416782"
Received: from ([]) by with ESMTP; 11 Oct 2014 06:22:11 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9B6MAgW031904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Sat, 11 Oct 2014 06:22:10 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sat, 11 Oct 2014 01:22:10 -0500
From: "Pascal Thubert (pthubert)" <>
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] multicast & MLD on LLN
Thread-Index: AQHP5RuvdYkdkHPd5kSqasUTvxD8SA==
Date: Sat, 11 Oct 2014 06:22:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: multipart/alternative; boundary="_000_6B9D200B58B8423CADEAA6C61F73748Bciscocom_"
MIME-Version: 1.0
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: Sat, 11 Oct 2014 06:22:17 -0000

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