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

[Michael Richardson <[e-mail]>]

{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  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [