Re: [Roll] AMI applicability: storing/non-storing.

"Popa, Daniel" <Daniel.Popa@itron.com> Wed, 06 November 2013 11:39 UTC

Return-Path: <Daniel.Popa@itron.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811E21E80AD for <roll@ietfa.amsl.com>; Wed, 6 Nov 2013 03:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.237
X-Spam-Level:
X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnKRV4ibJdcv for <roll@ietfa.amsl.com>; Wed, 6 Nov 2013 03:39:18 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id D30C521E8088 for <roll@ietf.org>; Wed, 6 Nov 2013 03:39:15 -0800 (PST)
Received: from CO1PR04MB346.namprd04.prod.outlook.com (10.141.52.25) by CO1PR04MB348.namprd04.prod.outlook.com (10.141.52.17) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 6 Nov 2013 11:39:13 +0000
Received: from CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.219]) by CO1PR04MB346.namprd04.prod.outlook.com ([169.254.1.47]) with mapi id 15.00.0785.001; Wed, 6 Nov 2013 11:39:12 +0000
From: "Popa, Daniel" <Daniel.Popa@itron.com>
To: Don Sturek <d.sturek@att.net>, Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] AMI applicability: storing/non-storing.
Thread-Index: AQHO2aeGDwcpLds380GbimRdLX4yv5oWX9CQgACciICAAAKQgIAABLaAgAENy7A=
Date: Wed, 06 Nov 2013 11:39:12 +0000
Message-ID: <78e4248b6eae47149396ddfb04a7ae82@CO1PR04MB346.namprd04.prod.outlook.com>
References: <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <CE9E8324.24C16%d.sturek@att.net>
In-Reply-To: <CE9E8324.24C16%d.sturek@att.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.2.132.2]
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(13464003)(51704005)(24454002)(55784002)(479174003)(377454003)(77096001)(83072001)(33646001)(85306002)(15975445006)(80976001)(81816001)(87266001)(76796001)(81686001)(56816003)(85806002)(19580395003)(2656002)(19580405001)(83322001)(76786001)(76576001)(81542001)(74366001)(81342001)(69226001)(15202345003)(56776001)(54316002)(74706001)(50986001)(76482001)(31966008)(47976001)(74876001)(47736001)(79102001)(74662001)(74502001)(59766001)(47446002)(74316001)(66066001)(63696002)(49866001)(4396001)(77982001)(51856001)(54356001)(53806001)(46102001)(65816001)(80022001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR04MB348; H:CO1PR04MB346.namprd04.prod.outlook.com; CLIP:109.2.132.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: itron.com
Subject: Re: [Roll] AMI applicability: storing/non-storing.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Nov 2013 11:39:23 -0000

Hi Don, all,

I agree that the support of (non-flooding) multicast forwarding topic can (eventually should) be separated from the RPL mode of operations...

IMHO, your statement about the need to use some flavor of RPL storing mode for dealing with non-flooding multicast forwarding is right if your assumption is to use RPL messages for the multicast forwarding control plane (i.e., set-up/tear-down multicast tree, set-up/tear-down forwarding states in the nodes, etc.). 

Ideally, it would be efficient to use a single control plane to manage unicast and multicast forwarding but - since this looks challenging in large scale mesh networks- what should prevent one from actually using a DODAG (routing) tree, built and maintained with a RPL non-storing mode, to build a non-flooding multicast forwarding tree (on top of that DODAG tree)  by means of a different control plane (by using, for example, MLDv2 protocol and ICMPv6 MLDv2 messages with the "right" modifications to fit LLN mesh constraints & requirements)? 

I would be interested in getting additional thoughts on this. 

Regards,
Daniel  

-----Message d'origine-----
De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Don Sturek
Envoyé : mardi 5 novembre 2013 20:16
À : Routing Over Low power and Lossy networks
Objet : Re: [Roll] AMI applicability: storing/non-storing.

Hi Randy,

"Hybrid storing" modes were looked into awhile ago in ROLL and abandoned due to complexity.  Currently, only storing and non-storing is supported in a specific DODAG instance.

I think the topic of multicast support is a bit separate.   I think you
forwarded me a research paper that used storing mode to analyze multicast
group member reachability.   That is an interesting topic when considering
multicast forwarding approaches that don't use flooding (although, I would expect that storing mode would be used with the approach since you need all of that routing information, plus multicast group membership, to make forwarding decisions)

Don


On 11/5/13 10:59 AM, "Turner, Randy" <Randy.Turner@landisgyr.com> wrote:

>I agree that non-storing mode addresses the primary AMI use-case where 
>endpoints push data up and through the DODAG root.
>
>Could there be a "hybrid-storing" mode that doesn't use as much RAM to 
>contain routes to all nodes in a sub-tree? Instead of traditional 
>storing mode, could a node store just multicast memberships in all nodes "below"
>a particular mote ?  Assuming there would much fewer multicast 
>memberships than would be required for RFC 6550 storing mode ?  It's a 
>variant of storing+multicast, without the traditional storing mode RAM 
>usage.
>
>I'm still looking at the MPL document, so apologies if that's already 
>discussed.
>
>Randy
>
>-----Original Message-----
>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of 
>Michael Richardson
>Sent: Tuesday, November 05, 2013 1:50 PM
>To: Routing Over Low power and Lossy networks
>Subject: Re: [Roll] AMI applicability: storing/non-storing.
>
>
>Popa, Daniel <Daniel.Popa@itron.com> wrote:
>    Daniel> However, my point is that these challenges are mostly 
>related to
>    Daniel> RPL storing mode of operation. As a consequence, I am OK to
>    Daniel> narrow down the scope of the applicability statement for 
>AMI to
>    Daniel> only RPL non-storing mode of operation, as I stated in my
>    Daniel> previous email. As for having different specs for different 
>use
>    Daniel> cases, I expect that by focusing only on RPL non-storing 
>mode a
>    Daniel> single AMI applicability statement will be able to cover
>    Daniel> efficiently "all" the reasonable requirements, for "all" use
>    Daniel> cases.
>
>Ah, I did not understand that from your previous email.
>Yes, please.  Pick non-storing, and lets' proceed!!!
>
>--
>]               Never tell me the odds!                 | ipv6 mesh
>networks [
>]   Michael Richardson, Sandelman Software Works        | network
>architect  [
>]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
>   [
>
>
>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.
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll