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

Don Sturek <> Tue, 05 November 2013 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6331821E8166 for <>; Tue, 5 Nov 2013 14:02:13 -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=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n9GhYjgADBJR for <>; Tue, 5 Nov 2013 14:02:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 238B821E8122 for <>; Tue, 5 Nov 2013 14:02:08 -0800 (PST)
Received: from [] by with NNFMP; 05 Nov 2013 22:02:07 -0000
Received: from [] by with NNFMP; 05 Nov 2013 22:02:07 -0000
Received: from [] by with NNFMP; 05 Nov 2013 22:02:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1383688927; bh=zvXUvlvGu4viZuv2ONyzGxlDzr6AwiXrZ9Mlx9vt91A=; 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=cjxQMyuHyrjt3MfNwffrR5lAIPa7ruehb7yN8GWDVz18v6BiTIGUIfbKHrXk839j/AiY7Z6KhJ1LOGtZQt+ze2mZkkL7M4wPvU4tPmEIyflcifa2zgzeQu6hf1P2GbmPS+DAQOVEgcBGcZaRjlABjdk5N/qC9Jn3Ohf8oaGmmfE=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 0bad7.EVM1nnJCBi8wKbmIFHW9Ad2niEst50rQ8js88B4tB 41S1GniX_w7t4umKicWJweo3F1PU4Iu76EmqjyHRR_Z3.I6Mwjp5YWt1ymom FbzkU5s_j9MZuDu8EYvuJkj3yKwwntPAD0jJP7OhdfsCwrZNIdjoraznbDm0 wKPcwIYJrWmQmBK2rZSV3GQv2IWHn39MdFJj4pbh18cxkINg6TcSoKrXNIWb _pkb.wAwjTpNfB19G.ATBYOy1q905bSpbqbg2sKxXVdOWcanPMEg7tBj5_Wk YZ9IA3O3T_kLoA6z65V4.B8jlfjoRl_ARwL651XJ2aoY2h_nJ30x0U5d0WnZ Zru7sDRh.ZbtrU1cOkeVzwOjK4yz31LTj6KYAaFk_J6Nuxf96Op9afAzoaFi hxcYKfxH6T4ZNa0pTSDuUfqTAh1FWC6fVHV.g.KWyOuZFDwXkdPn14SjflSU vm7Jhrr0yzJoILtFqIFzTN8zLEB1gU39xTA71pio9ZlvcbVskZHcIb5VFZ.t ifCtoalM_xvUUXB8oIQ0iEfdIrjRgh4bD2NVvpt9aTaP1LeU-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [] (d.sturek@ with ) by with SMTP; 05 Nov 2013 22:02:07 +0000 UTC
User-Agent: Microsoft-MacOutlook/
Date: Tue, 05 Nov 2013 11:16:01 -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: Tue, 05 Nov 2013 22:02:13 -0000

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 "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
>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
>    Daniel> RPL storing mode of operation. As a consequence, I am OK to
>    Daniel> narrow down the scope of the applicability statement for AMI
>    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
>    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