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

[Don Sturek <[e-mail]>]

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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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 <[e-mail]> 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  [
>]     [e-mail]  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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/roll