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

["Popa, Daniel" <[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] 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

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.

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.  

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)

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

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.

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.

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