Subject: [Roll] P-DAO requirements on MOP-ext

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Sep 2019 14:25:26 +0000

Dear all

I'm looking at what P-DAO would need to express as capabilities.
Here's a list, please come back with more:

  *   Express support for RFC 8138 (needed for draft-thubert-roll-turnon-rfc8138 as well)
  *   Express support for exposing siblings
  *   Signal supported OFs
  *   Express support for storing P-DAO
  *   Express the capacity in terms of routes {
     *   approximate Nb of routes that can be installed,
     *   Current % route storage used,
     *   Target % route storage used - if target < current then Root should move some paths
     *   overload bit that means do not use me for now }
  *   Same for non-storing P-DAO using an average number of hops per route, e.g., 5.
     *   Plus: Maximum nb hops in a route

What do you think?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Sep 2019 20:15:51 +0300

Thank you; these are really good questions.

pascal> I'm looking at what P-DAO would need to express as capabilities.
pascal> Here's a list, please come back with more:

I am re-ordering slightly.

pascal>   *   Signal supported OFs
pascal>   *   Express support for RFC 8138 (needed for draft-thubert-roll-turnon-rfc8138 as well)

It seems like these are capabilities separate from P-DAO itself.
That these are things that could be enabled or not even without P-DAO.
That P-DAO could run without them.  Is that correct, or is there a dependancy
that I'm ignorant of?

pascal>   *   Express support for exposing siblings

I guess I need to read P-DAO again to understand why this isn't part of P-DAO.

pascal>   *   Express support for storing P-DAO
pascal>   *   Express the capacity in terms of routes {
pascal>      *   approximate Nb of routes that can be installed,
pascal>      *   Current % route storage used,
pascal>      *   Target % route storage used - if target < current then Root should move some paths
pascal>      *   overload bit that means do not use me for now }

Clearly if you say you support P-DAO, then you also need to say how many
routes you can support.  In non-storing mode, the node would store zero
routes, so the root would always know how many routes there are, and does not
need to know % and target, does it?
In storing mode, it seems that the root won't learn how much space there is
at each level from the DAOs, just how many routes are used in each directly
children, so we do need to know how many are used and how much space there
is.

Clearly, how many are used, and the overload bit are things that need to
updated regularly, while the total capacity is updated once.

I suggest therefore that what we need to do is to inform the root on a
periodic basis how many available slots there are.  This would seem to
capture all of the data you indicate into a single number?

pascal>   *   Same for non-storing P-DAO using an average number of hops per route, e.g., 5.
pascal>      *   Plus: Maximum nb hops in a route

Your thought is that a node will have X many slots for "hops", and that a
route would consist of a some number of hops, so that it's not destinations
that we need to account for, but rather hops?

I feel that the amount of active space does not really fit into capabilities
as I had originally imagined.  That capabilities are something that are
communicated once after the node joins a particular DODAG. While available
slots for hops is something that requires more frequent updates and should
use a different mechanism. But perhaps I'm thinking too much about this,
and that one mechanism can do both.

-- 
]               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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Sep 2019 06:18:40 +0000

Hello Michael

Please see below

mcr> It seems like these are capabilities separate from P-DAO itself.
mcr> That these are things that could be enabled or not even without P-DAO.
mcr> That P-DAO could run without them.  Is that correct, or is there a dependancy that I'm ignorant of?

The need for turnon predates P-DAO. But still, knowing whether to encapsulate to the parent depends on whether 8138 is used. The RUL could ignore RPL artifacts as a good RFC 8200 soldier, but it may not disgest the compression as easily. This is why I wish to ship MOP ext and turnon quickly, they are part of the foundation.

-----------------

mcr>  guess I need to read P-DAO again to understand why this isn't part of P-DAO.

I want to put in in P-DAO now. I'm asking the OK since that was not originally there.

------------------

mcr>  Clearly if you say you support P-DAO, then you also need to say how many routes you can support.  In non-storing mode, the node would store zero routes, so the root would always know how many routes there are, and does not need to know % and target, does it?

I mean not storing P-DAO. This installs a route in the tunnel ingress somewhere in the network. Nodes along the path would be transparent as long as they support RFC 6550 non storing mode and do not expect the root to be the encapsulator, why would they, but hey, that could be a slightly different code path. Note that we want to enable any form of P-DAO on any RPL mode, apart from MOP 0 (collection MP2P).

mcr>  In storing mode, it seems that the root won't learn how much space there is at each level from the DAOs, just how many routes are used in each directly children, so we do need to know how many are used and how much space there is.

Yes, the root manages a space in the device

mcr>  Clearly, how many are used, and the overload bit are things that need to updated regularly, while the total capacity is updated once.

mcr>  I suggest therefore that what we need to do is to inform the root on a periodic basis how many available slots there are.  This would seem to capture all of the data you indicate into a single number?

WFM. I agree we need to make that efficient. E.g., the collection of the data could be aggregated as it goes up.

-------------------

mcr>   Your thought is that a node will have X many slots for "hops", and that a route would consist of a some number of hops, so that it's not destinations that we need to account for, but rather hops?

Yes, we need to express how mush resources a SRH state costs in the tunnel ingress, and that seems to be a linear function of the number of hops. If b is the cost of a storing mode P-DAO state, and a in the incremental cost per hop in SRH, then with x hops the cost would be ax+b.

mcr>   I feel that the amount of active space does not really fit into capabilities as I had originally imagined.  That capabilities are something that are communicated once after the node joins a particular DODAG. While available slots for hops is something that requires more frequent updates and should use a different mechanism. But perhaps I'm thinking too much about this, and that one mechanism can do both.

I agree. It could be a similar transport with options. Like the root pulls something and all report that something. Or a node asynchronously update. I think the NIQ/NAO mechanism would have very different properties than the DIO/DAO.

All the best

Pascal