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

Don Sturek <> Fri, 15 November 2013 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B17F11E81A6 for <>; Fri, 15 Nov 2013 08:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WOXcd4Bb8kYl for <>; Fri, 15 Nov 2013 08:43:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7A9FD11E81B7 for <>; Fri, 15 Nov 2013 08:43:11 -0800 (PST)
Received: from [] by with NNFMP; 15 Nov 2013 16:00:53 -0000
Received: from [] by with NNFMP; 15 Nov 2013 16:00:53 -0000
Received: from [] by with NNFMP; 15 Nov 2013 16:00:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1384531253; bh=DYAx/6ef5CMt58NxZHzjkWwNpyzxsisLgTFDmINEo28=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=c7BTbhMMOMCTpFC6yJdy0QottXFVgB2Tio8JkMnUZ6wZzTBdl0rbV2d6Q15ClUdqDNY9gDK4ZtnzRdgy5KL46t+pwyKvhMb3fEFs1XU3UUKF7cUOToCEbPf8bU8KoX+72CNPGihugQl7tMttDEChxTUTFhGpM4cIzYtnAVrXWK8=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: gWTtGJsVM1noq0Qtg6j_daYdr.QKGl2eD1cC0lSWOAp8IEt J5lWOCrh8CRmXrbru3IrkvDdjnAWhyh86XCIWiHaQmMOBLLpM5.QyVv4Ntqi hi_p5m5cwzgvHc0sgPpgd_.p1Z2Zgii.c.gA41XUPVmhvJGw5cXU0Ct3mXxr 42q_qlAKtHTlFMSLwS3IHW8tN6zy_1uUJ_kgrXJL6fm91aXbxRsSYkADx5Wx 91AJIgnZGi3HQGWdkcR71yObEne3pYDkgsUyNXq6T.IHE_cxtg92ArN4wg9H W1EsuBzy6tloCZarfrIE04b1K1pE.Py8JvGnSPHgwSAhin_o5.EasEZ0X6q_ HhOmoXWKFopDVQEwci7G9._nd_C0IDkw80YjWOTyalQBYLgWkXo8PokW9NXR PhXU3_nAOerNZN679hb_24lDFtjRK5.fTitViCHFu7Fzg0yb8pCp9pvNDQSz .QsfedGiFoxWL.nTSQmcoldBQYmdEIn4R.lzXOuKREP4SadpcYja17hH4WzB SmqkNpSg.HJ7my0k9P6FapqrCVOA83N9PJEfLZ1rZkHwdG59nBRDx64PY
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [] (d.sturek@ with ) by with SMTP; 15 Nov 2013 16:00:52 +0000 UTC
User-Agent: Microsoft-MacOutlook/
Date: Fri, 15 Nov 2013 08:00:50 -0800
From: Don Sturek <>
To: Routing Over Low power and Lossy networks <>
Message-ID: <>
Thread-Topic: [Roll] AMI applicability: storing/non-storing.
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [Roll] AMI applicability: storing/non-storing.
X-Mailman-Version: 2.1.12
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: Fri, 15 Nov 2013 16:43:40 -0000

Hi Randy,

If you go back in the ROLL archives, you will see the discussion on a
hybrid storing/non-storing deployment.

I think there was a good deal of discussion at the time on complexity and
it was decided (by the ROLL design team) not to pursue development.

Of course, if you want to provide an individual submission I-D, I am sure
there would be enough interest to at least review it.....


On 11/15/13 7:39 AM, "Turner, Randy" <> wrote:

>Hi Don,
>Sorry for the delayed reply...was out of commission for awhile.
>Yes, I'm aware of the existing spec'd forms of storing and non-storing,
>however,  the "hybrid storing" mode is not hybrid with regards to
>unicast, but just simply listening to multicast joins from your children
>and storing those group addresses.   I don't think this is that complex
>-- it would benefit the non-flooding method that I referred to in the
>research paper, without adding too much RAM burden for the routing motes
>in the network.  If my assumptions regarding the number of multicast
>groups that might be active in an LLN is not correct, then that would
>have some application (may be appropriate for some networks, but not
>others) affinity. 
>-----Original Message-----
>From: [] On Behalf Of
>Don Sturek
>Sent: Tuesday, November 05, 2013 2:16 PM
>To: Routing Over Low power and Lossy networks
>Subject: 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)
>On 11/5/13 10:59 AM, "Turner, Randy" <> 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
>>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
>>I'm still looking at the MPL document, so apologies if that's already
>>-----Original Message-----
>>From: [] 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 <> 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
>>    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  [
>>]        |   ruby on rails
>>   [
>>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 mailing list
>Roll mailing list