[Roll] multicast & MLD on LLN

"Turner, Randy" <Randy.Turner@landisgyr.com> Fri, 10 October 2014 19:22 UTC

Return-Path: <Randy.Turner@landisgyr.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0755B1ACE87 for <roll@ietfa.amsl.com>; Fri, 10 Oct 2014 12:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8GabdvAGPUT for <roll@ietfa.amsl.com>; Fri, 10 Oct 2014 12:22:33 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::759]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EDB1ACE53 for <roll@ietf.org>; Fri, 10 Oct 2014 12:22:33 -0700 (PDT)
Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0429.eurprd01.prod.exchangelabs.com (10.242.221.20) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 10 Oct 2014 19:03:57 +0000
Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 19:03:57 +0000
From: "Turner, Randy" <Randy.Turner@landisgyr.com>
To: "roll@ietf.org" <roll@ietf.org>
Thread-Topic: multicast & MLD on LLN
Thread-Index: Ac/kvGg9glP5Rg5dTyCqZKTLnjPO8A==
Date: Fri, 10 Oct 2014 19:03:57 +0000
Message-ID: <aef2e75903e84afe988ff58d04a0fc56@DB4PR01MB0431.eurprd01.prod.exchangelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [148.80.255.144]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0429;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(41574002)(120916001)(101416001)(16236675004)(229853001)(86362001)(2351001)(107046002)(107886001)(19625215002)(31966008)(54356999)(40100003)(95666004)(92566001)(19300405004)(76482002)(19580395003)(15975445006)(106356001)(50986999)(74316001)(4396001)(2656002)(87936001)(85852003)(99396003)(64706001)(66066001)(85306004)(105586002)(122556002)(110136001)(46102003)(33646002)(2501002)(80022003)(20776003)(21056001)(108616004)(15202345003)(97736003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0429; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_aef2e75903e84afe988ff58d04a0fc56DB4PR01MB0431eurprd01pr_"
MIME-Version: 1.0
X-OriginatorOrg: landisgyr.com
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DIzMrcj5iMjdka8XvK0FVCoNnDE
Subject: [Roll] multicast & MLD on LLN
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2014 19:22:36 -0000

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 ?

Thanks!
Randy


P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

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.