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

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2013 16:47:17 -0500

{I deleted this email by mistake from my inbox, so I had to go back to the
archive to get a copy of it}
The original thread is here:
   http://www.ietf.org/mail-archive/web/roll/current/msg08082.html

I asked about:

    >> As a result, different AMI deployments can vary significantly in terms
    >> of memory size, computation power and communication capabilities.  For
    >> this reason, the use of RPL storing or non-storing mode SHOULD be
    >> deployment specific.  When meters are memory

   mcr> a manufacturer that wishes to make meters for more than one
   mcr> market/RFP would nee d to put in enough memory for the worst case
   mcr> storing situation.  So the advice here is empty. And how many
   mcr> routes is enough?

Daniel gave a well written overview of the considerations about how much ram
to use, and I can't disagree with any of it.  The thing is, one of the
purpose of the applicability document it to make it clear how to use RFC6550
in a particular situation.  There are very very very real needs for a
document (specificallly, a "performance specification" to use language from
trade agreements) that can be used to procure product.  This is what we are
here for: to write specifications.

It seems to me that the AMI applicability statement is still overbroad in
scope if it is not possible to answer the question of storing or non-storing.

As such, in order to progress here, I think that we need to define clearly
what kind of network we are talking about here.  If that excludes some
network that someone cares about, then we need another document.  

Let me suggest some constraints.
1) lets deal with powered electric meters only as routers
   (unpowered meters -- water -- which operate on batteries may be leaf nodes
   only)

2) lets deal with (sub-)urban housing densities. (so this rules out 47 story
   apartment buildings in Manhatten until someone either writes another
   document, or shows that the numbers we picked will work)

3) let's decide on storing mode and decide upon 64 route entries, 
   and see what happens for the 1000 nodes described in the Cisco experience document
      http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01

(I'll bet somehow has simulator published results that support or update this
analysis):

 - 51% of nodes were 1 hop away
 - 30% of nodes were 2 hops away, etc...

100-51% of 1000 = 490 nodes need to be reached by a 1st rank node.
There are 510 first rank nodes, so on average each 1st rank node needs to
have 1 route entry for one of the 490 downstream nodes.  That's << 64!

(I assume that the root node is special, and has more capacity)

Based upon another diagram I saw about how meters might mesh down a street in
a linear fashion, and taking my street as an example (my meter is smart, but
not IPv6), there are approx 12 houses on my side of the street on my side of
the block.  So, the house nearest the root needs 12 routes, and the depth of
the three is 12.   I assume that the ETX across the street or onto next block
is too poor to bother.

I'm not claiming that my numbers are sane, I'm just saying that we absolutely
need to have a number here.

    Daniel> memory resources, and so on. As an example, although an AMI
    Daniel> platform for US mar ket is sharing some in common with an AMI
    Daniel> platform for EU market, their requirem ents/constraints,
    Daniel> functionalities and applications can be significantly differen t.

Then, let's please write two documents.

I also want to point out, if one has power, then number of bits on the wire
might not matter as much, and non-storing mode may be good.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Popa, Daniel" <[email-masked]>
Date: Tue, 5 Nov 2013 09:59:17 +0000

Hi Michael, all, 

Thank you for useful thoughts and feedback. 

A few thoughts here + additional inputs within your lines. 

I understand and ACK the challenge of making an AMI applicability statement document for RPL storing mode of operation because one should take into account - among others constraints -  the neighborhood densities when designing the product.  And as you mentioned this may lead to providing an applicability statement as a function of specific field characteristics (street and building topology, building/meter densities, terrain topology, etc.), which eventually results into different applicability documents.

However, my point is that these challenges are mostly related to RPL storing mode of operation. As a consequence, I am OK to narrow down the scope of the applicability statement for AMI to only RPL non-storing mode of operation, as I stated in my previous email. As for having different specs for different use cases, I expect that by focusing only on RPL non-storing mode a single AMI applicability statement will be able to cover efficiently "all" the reasonable requirements, for "all" use cases.  

Regards,
Daniel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Michael Richardson
Envoyé : lundi 4 novembre 2013 22:47
À : Routing Over Low power and Lossy networks
Objet : Re: [Roll] AMI applicability: storing/non-storing.

{I deleted this email by mistake from my inbox, so I had to go back to the archive to get a copy of it} The original thread is here:
   http://www.ietf.org/mail-archive/web/roll/current/msg08082.html

Daniel gave a well written overview of the considerations about how much ram to use, and I can't disagree with any of it.  The thing is, one of the purpose of the applicability document it to make it clear how to use RFC6550 in a particular situation.  There are very very very real needs for a document (specificallly, a "performance specification" to use language from trade agreements) that can be used to procure product.  This is what we are here for: to write specifications.

It seems to me that the AMI applicability statement is still overbroad in scope if it is not possible to answer the question of storing or non-storing.

DP> As previously suggested, let's do an incremental applicability statement and narrow down the scope of this document to RPL non-storing mode only. Eventually, explanation of this choice can be provided to the designers/implementers at the beginning of the document (in the section describing out of scope topics)

As such, in order to progress here, I think that we need to define clearly what kind of network we are talking about here.  If that excludes some network that someone cares about, then we need another document.  

DP> No objection to take this approach for this (1st) applicability statement for AMI.

100-51% of 1000 = 490 nodes need to be reached by a 1st rank node.
There are 510 first rank nodes, so on average each 1st rank node needs to have 1 route entry for one of the 490 downstream nodes.  That's << 64!

Based upon another diagram I saw about how meters might mesh down a street in a linear fashion, and taking my street as an example (my meter is smart, but not IPv6), there are approx 12 houses on my side of the street on my side of the block.  So, the house nearest the root needs 12 routes, and the depth of
the three is 12.   I assume that the ETX across the street or onto next block
is too poor to bother.

I'm not claiming that my numbers are sane, I'm just saying that we absolutely need to have a number here.

DP> I think we agree that the challenge is to provide the applicability for the RPL storing mode of operation, because one may need to provide different specification for each such use cases. But if we focus only on applicability for AMI only for the RPL non-storing mode of operation, the above mentioned issues become almost irrelevant, irrespective of the market that is targeted, of the network/field characteristics, of traffic characteristics,  etc.

I also want to point out, if one has power, then number of bits on the wire might not matter as much, and non-storing mode may be good.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Nov 2013 13:49:59 -0500

Popa, Daniel <[email-masked]> 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!!!

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 5 Nov 2013 18:59:09 +0000

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: [email-masked] [mailto:[email-masked]] 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.

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Nov 2013 16:50:21 -0500

Turner, Randy <[email-masked]> wrote:
    > 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. 

Yes there could be, but it needs more research.  
There was at least one ID in the past year discussion how this could be
supported.   

The problem is not generally deep in the DODAG, as the fan out
means that there are few children, thus they fit into ram.  The problem is
closer to the top, where there are more children than fit.

There was significant discussion on the list and at meetings a few years ago;
look 6 months before the publication date of 6550.  
As I recall, one can not just keep some routes and not others due to how
parents might change.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Don Sturek <[email-masked]>
Date: Tue, 05 Nov 2013 11:16:01 -0800

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" <[email-masked]> wrote:

>I agree that non-storing mode addresses the primary AMI use-case where
>endpoints push data up and through the DODAG root.
>
>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.
>
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: "Popa, Daniel" <[email-masked]>
Date: Wed, 6 Nov 2013 11:39:12 +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 : [email-masked] [mailto:[email-masked]] 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" <[email-masked]> wrote:

>storing mode, could a node store just multicast memberships in all nodes "below"
>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.

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 15 Nov 2013 15:39:41 +0000

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.  

Randy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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,

Don

---

From: Don Sturek <[email-masked]>
Date: Fri, 15 Nov 2013 08:00:50 -0800

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.....

Don

On 11/15/13 7:39 AM, "Turner, Randy" <[email-masked]> wrote:

>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. 
>
>
>Randy
>
>
>
>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
>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Nov 2013 14:40:02 -0500

> it was decided (by the ROLL design team) not to pursue development.

It wasn't just that it was complex; it was that we couldn't come up with a
use case that would justify that complexity at the time.

My opinion is that the AMI people have such a use case and should pursue
writing something up.