Subject: Re: [Roll] do capabilities need to understood, can they be added?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 2 Sep 2019 09:44:00 +0000

Dear all:

Seems to me that sometimes the capability of the node is something that only the root cares about. 
At least that's true when the root needs to know if all nodes support a capability. It wants to flood a query and gather the responses from all. Missing queries would mean a unicast retry I guess.

At other times it might be something that the parent cares about. In that case it asks one or all of its children.

So we're after a capability exchange flow that is unicast or multicast, with a unicast response. Either from parent to child or from root to any. The flow would be independent of the storing vs. non-storing MOP.
We do not really have a flow like that in RPL. It's akin to a software update, when the root wishes to now if all nodes have received the full image.

The DIO could be stretched to convey the ask to a group, but it's hard to make it reliable. The DAO even less OK since it carries destination not node information. As of today the root does not really know if multiple addresses are on a same node.

All in all it seems that we are after something that is needed by RPL but on the side of the current protocol. I'm not too sure that we should overload the current messages for this. Rather, we may build new objects for Nodes information and capability. Like a unicast or multicast NIS (Node Info Solicitation) and a NAO (Node Advertisement Object). We'd design operations that are independent of the current MOPs. Note that we could use local broadcast NAO to discover siblings and siblings siblings, something P DAO needs anyway.

Please see below

>     mcr> Are they individualized, or does every node in the LLN have to support
>     mcr> a capability before it can be used?
> 
> Rahul Arvind Jadhav <[email-masked]> wrote:
>     rj> Nice point. I haven't thought about this in detail. In non-storing
>     rj> MOP, it may not be required that all the nodes support capabilities
>     rj> but in storing MOP, every 6LR needs to add the cap (if present) of
>     rj> the downstream child, thus requiring every node to support it. This
>     rj> definitely needs handling in the draft.  [Ref:
>     rj> https://github.com/roll-wg/MOPex-capabilities/issues/1
> 
> I see:
> 
> 1) the root announces a capability.  6LRs that understand it may use the
>    new capability unilaterally if they understand it, and see a need for it.
>    Nodes that do not understand the new capability are not affected.
>    This could be a control plane thing, or a data plane thing.
> 
> [RJ] The problem may be in the other direction, .. In storing MOP, how should
> a 6LR which does not understand capability treat a DAO containing capability?
> Also how should a 6LR treat an unknown option in general?
> 6550 mentions how to treat unknown RPL code but there is no handling for
> unknown option in DIO/DAO. Is there? I searched and could not find.
> Most of the existing implementations just ignore what they don't understand.
> 
> 2) the root announces support for capability that it wishes to enable, in
>    order for it be used, every node must support it.  If every DAO from
>    every node supports the capability, then the root announces that it
>    is turned on.
>    This in effect is a two-pass system, requiring either two capability
>    bits.
>    It might be that it is better to encode these two bits are three
>    values (plus 00-not supported).
> 
> [RJ] Another scenario could be that Root announces support for an optional
> capability. The 6LN just needs to know whether it could make use of this
> capability of the root to do something. It may not need to reply back to the
> root saying I see it and I support it.
> Also should we be using two capability bits or we could use the info on
> whether the bit is set in DIO/DAO to infer the direction.
> 
> 3) any 6LR may announce a capability to it's children that it received from
>    it's parent, if it understands that capability.  If it does not, then
>    it MUST clear the capability.
> 
>    This can be a unilateral capability (like 1), or one that has to be
>    confirmed (like 2).  So this is really 3A and 3B.
> [RJ] I get 3A .. but do we really need 3B. I mean if the node also needs to
> indicate that it also supports the same capability to the root then it can set the
> same bit in the DAO and send it back ... Thus working in both directions. It may
> not be required that capabilities be handshaked in both directions
> mandatorily. For e.g., root may indicate the capability that it has access to
> 6BBR and that unaware leaves could register through 6LRs. Thus 6LRs could
> proxy the NS (EARO) and other relevant messages. In this case, is it needed
> that 6LR reply back to the root saying it supports unaware leaves?
> There might be another example which requires 6LRs/6LNs to indicate in the
> reply that it supports the feature asked by root using the same cap bit in DAO.
> The DIO/DAO decides the direction but the bit can be the same.
> 
> 4) any 6LR may announce a capability to it's children, even if it did not
>    receive it from a parent.  The capability is not to be repeated by
>    the children (regardless of whether they understand it), unless they also
>    wish to enable it.
> [RJ] agree
> 
> I therefore see several issues to resolve.
> For capabilities that a node understands, it can know which type of capability
> it is.  For a capability that is unknown, if the behaviour is other than "set to
> zero", then we need to tell the node what kind of capability it is, and how it is
> encoded.
> 
> Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available, (3)-
> query, (3)-enable, (4)-available.  Conveniently, 7 things, plus all zeros.  We
> could encode capabilities in three bits, so the behaviour would be part of the
> encoded.
> 

Would you encode capabilities in a bit array?
I'm interesting in signaling whether we can live without a capability or if it the node must become leaf if it does not have it.

All the best

Pascal

> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 2 Sep 2019 15:55:59 +0000

In addition to the below I took a refresh look at RFC 6551. 

https://tools.ietf.org/html/rfc6551#section-3.1 provides a shell for capabilities such as those that we are after.
And
https://tools.ietf.org/html/rfc6551#section-3.2 discusses how to handle a resource that varies over time and is subject to consumption and exhaustion. Storage of routes for P-DAO has similarities with that.

All in all I'm thinking that we could extend Node Metric/Constraint Objects and how they are used for DODAG formation. We could for instance use the metric container as defined for DIO and create at least one new message to report to the asker for the reasons below. 

Thoughts?

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: lundi 2 septembre 2019 11:44
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: RE: [Roll] do capabilities need to understood, can they be added?
> 
> Dear all:
> 
> At least that's true when the root needs to know if all nodes support a
> capability. It wants to flood a query and gather the responses from all. Missing
> queries would mean a unicast retry I guess.
> 
> So we're after a capability exchange flow that is unicast or multicast, with a
> unicast response. Either from parent to child or from root to any. The flow
> would be independent of the storing vs. non-storing MOP.
> We do not really have a flow like that in RPL. It's akin to a software update,
> when the root wishes to now if all nodes have received the full image.
> 
> The DIO could be stretched to convey the ask to a group, but it's hard to make
> it reliable. The DAO even less OK since it carries destination not node
> information. As of today the root does not really know if multiple addresses
> are on a same node.
> 
> All in all it seems that we are after something that is needed by RPL but on the
> side of the current protocol. I'm not too sure that we should overload the
> current messages for this. Rather, we may build new objects for Nodes
> information and capability. Like a unicast or multicast NIS (Node Info
> Solicitation) and a NAO (Node Advertisement Object). We'd design operations
> that are independent of the current MOPs. Note that we could use local
> broadcast NAO to discover siblings and siblings siblings, something P DAO
> needs anyway.
> 
> Please see below
> 
> > [RJ] The problem may be in the other direction, .. In storing MOP, how
> > should a 6LR which does not understand capability treat a DAO containing
> capability?
> > 6550 mentions how to treat unknown RPL code but there is no handling
> > for unknown option in DIO/DAO. Is there? I searched and could not find.
> > [RJ] Another scenario could be that Root announces support for an
> > optional capability. The 6LN just needs to know whether it could make
> > use of this capability of the root to do something. It may not need to
> > reply back to the root saying I see it and I support it.
> > Also should we be using two capability bits or we could use the info
> > on whether the bit is set in DIO/DAO to infer the direction.
> >
> > [RJ] I get 3A .. but do we really need 3B. I mean if the node also
> > needs to indicate that it also supports the same capability to the
> > root then it can set the same bit in the DAO and send it back ... Thus
> > working in both directions. It may not be required that capabilities
> > be handshaked in both directions mandatorily. For e.g., root may
> > indicate the capability that it has access to 6BBR and that unaware
> > leaves could register through 6LRs. Thus 6LRs could proxy the NS
> > (EARO) and other relevant messages. In this case, is it needed that 6LR reply
> back to the root saying it supports unaware leaves?
> > There might be another example which requires 6LRs/6LNs to indicate in
> > the reply that it supports the feature asked by root using the same cap bit in
> DAO.
> > For capabilities that a node understands, it can know which type of
> > capability it is.  For a capability that is unknown, if the behaviour
> > is other than "set to zero", then we need to tell the node what kind
> > of capability it is, and how it is encoded.
> >
> > Counting above, I see (1)-available, (2)-query, (2)-enable,
> > (3)-available, (3)- query, (3)-enable, (4)-available.  Conveniently, 7
> > things, plus all zeros.  We could encode capabilities in three bits,
> > so the behaviour would be part of the encoded.
> >
> 
> I'm interesting in signaling whether we can live without a capability or if it the
> node must become leaf if it does not have it.
> 
> All the best
> 
> Pascal
> 
> > --
> > Michael Richardson <[email-masked]>, Sandelman Software Works
> > - = IPv6 IoT consulting =-
> >

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Sep 2019 12:59:58 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    pt> Seems to me that sometimes the capability of the node is something that
    pt> only the root cares about.

Yes, agreed.  This was my case (1), which I've brought up.

    >> This could be a control plane thing, or a data plane thing.

    pt> At least that's true when the root needs to know if all nodes support a
    pt> capability. It wants to flood a query and gather the responses from
    pt> all. Missing queries would mean a unicast retry I guess.

Agreed. That's my case (2).

    >> This in effect is a two-pass system, requiring either two capability

Phase 1 is to learn whether all the nodes support it.
Phase 2 is to tell the nodes whether they can turn it on or not.
  draft-thubert-roll-turnon-rfc8138-03

could be done this way, btw.

    > At other times it might be something that the parent cares about. In
    > that case it asks one or all of its children.

Yes. That's my case (4).

    > So we're after a capability exchange flow that is unicast or multicast,
    > with a unicast response. Either from parent to child or from root to
    > any. The flow would be independent of the storing vs. non-storing MOP.

Agreed.

    > We do not really have a flow like that in RPL. It's akin to a software
    > update, when the root wishes to now if all nodes have received the full
    > image.

So, you are suggesting that any reply from the nodes to the root shouldn't
use DAO, but something new.    I don't see why we can't put the downward
signal into the DIO though.

    > The DIO could be stretched to convey the ask to a group, but it's hard
    > to make it reliable. The DAO even less OK since it carries destination
    > not node information. As of today the root does not really know if
    > multiple addresses are on a same node.

    > All in all it seems that we are after something that is needed by RPL
    > but on the side of the current protocol. I'm not too sure that we
    > should overload the current messages for this. Rather, we may build new
    > objects for Nodes information and capability. Like a unicast or
    > multicast NIS (Node Info Solicitation) and a NAO (Node Advertisement
    > Object). We'd design operations that are independent of the current
    > MOPs. Note that we could use local broadcast NAO to discover siblings
    > and siblings siblings, something P DAO needs anyway.

I am for NAO as always being from node to root.
I see how we could do this multicast for P-DAO, but I think that I need to
know more.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Sep 2019 14:04:16 -0400

> https://tools.ietf.org/html/rfc6551#section-3.2 discusses how to handle
    > a resource that varies over time and is subject to consumption and
    > exhaustion. Storage of routes for P-DAO has similarities with that.

    > All in all I'm thinking that we could extend Node Metric/Constraint
    > Objects and how they are used for DODAG formation. We could for
    > instance use the metric container as defined for DIO and create at
    > least one new message to report to the asker for the reasons below.

So, we'd (ab)use node metrics to provide information from children to parents
(and possibly to root) on what the node can do?

They (DAG Metric Containers) are options, and live in DIOs or DAOs, so would
still be limited as to how they flow up/down the DAG.  This just changes how
we encapsulate the options, but does not change the rules on where the information flows.

The point of introducing the NAO was that it would have different rules about
where it goes?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Sep 2019 15:49:50 +0000

Hello Michael and all

> The point of introducing the NAO was that it would have different rules
> about where it goes?

Yes. Thinking out loud:

What we have today
---------------------------

- DAG configuration information to signal activation of a feature as we build a DAG are fine with a DIO and configuration option (e.g., flag day using capability blah such as use RFC 8138 compression or place ROVR in DAO). It could indicate, as RFC 6551 says, that " the constraint specified in the body of the object is optional". It is not as efficient as a global on/off switch when all nodes need to act "transactionally", see the discussion in turnon-rfc-8138 about turning off again. IOW, we do not have reliable-multicast communication to set something on/off dynamically on all nodes. 
- DAG constraints to build a DAG are fine in a DIO with a RFC 6551 Node Metric/Constraint Objects in the DAG Metric Container Option. We could extend the Node State and Attribute (NSA) object to add constraints in capabilities (e.g., do not join as a router if you do not have capability blah such as RFC 8138 compression). Note that RFC 6551 does not deal with "capabilities" but it discusses "characteristics" such as battery type and level. 
- NSA in DIO could also be a vessel to disseminate DAG level capabilities in addition to making them constraints as above (e.g., the capability to proxy the EDAR at the Root for RUL could be exposed in the NSA as well). Once we used NSA to place constraints as well as expose some capabilities, it makes sense to use it in the capability query/response mechanism that we are after.
- DAO is not sequenced with / synchronized to DIO. There's a slight attempt with DTSN but you cannot say I have all the DAOs from all nodes based on DIO blah. IOW DIO / DAO is not designed as an asynchronous query/response mechanism. Achieving something like DUAL in EIGRP looked too hard in an unreliable / never converged LLN. Still does.

A new message model
------------------------------

I think the messages need to change because of different semantics and flows. Semantics because we care about nodes as opposed to DAG (DIO) or Destinations (DAO); think, like, in OSPF a Router LSA is different from a Link LSA.  And flows look different because we appear to need a reliable multicast, either Root to all nodes or a parent to all its children. Today we do not have a message that a parent sends to all the children and it expects all the children to answer. Because it's hard to do on a LLN. How do we know who all the children are? How does the parent retry when 90% of the known children have answered? A series of unicasts or a broadcast again? What about the root?

Today a change in the configuration is trickled in DIOs that are propagated down, which means it is slowly disseminated, it does not take effect quickly to all, and it spreads. It eventually reaches all the live nodes but we do not know when. And DIO is about DAG. 
But if we used DIO to query node capabilities, then we could not do unicast retries hops away. DIO does not work like that. That's when it starts feeling like an abuse. And trickling a new DIO to all because we are missing one answer in the whole DODAG seems extreme. OTOH, a new Node Information Query that can be unicast, multicast one hop down or recursively all the way down would do the trick. The query would indicate what the root (or parent) wants to know. It could even provide the value at the querier. The response would be a unicast NAO. 
We could even have a child use a NIQ unicast to a parent or the root, who would reply unicast to the querier or multicast NAO to all children. Parents could aggregate NAOs for children towards the grandparent.

Diffusion like DUAL is probably still too hard, as it was when we designed DIO. We should probably shoot for something that hits most nodes, that is mostly reliable. This generally works when turning something on like RFC 8138 compression. Those who did not see the knob do not compress but that works. And then if really important find a way to unicast and then garage the nodes who did not respond. E.g., do not install P-DAO routes in nodes that did not respond to capability queries.

A new container/option?
---------------------------------

I thought we could extend the existing Node Metric/Constraint objects to add capabilities but I'm not adamant about it. Just that there are things already there and that we need. Like signaling constraints, whether they are mandatory or not, and describing node characteristics. The 'O'verload bit in NSA looks like something we need to get inspiration from, though we need to understand if the overload has to do with forwarding, Storing Mode routes, P-Dao states, or whatever else. The DAG Metric Container is really related to distributed routing decisions. We need to maintain a map of the DODAG with capabilities for centralized route computation P-DAO and the likes. It's a stretch, not a gigantic one.

The NIQ/NAO would transport the same NSAs. It would also produce neighborhood information, e.g. the number of P-DAO routes that can be stored - or just P-DAO storage "overload".

What do you think?

Pascal

> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: lundi 2 septembre 2019 20:04
> Subject: Re: [Roll] do capabilities need to understood, can they be added?
> 
> 
>     > https://tools.ietf.org/html/rfc6551#section-3.1 provides a shell for
> capabilities such as those that we are after.
>     > And
> So, we'd (ab)use node metrics to provide information from children to
> parents (and possibly to root) on what the node can do?
> 
> They (DAG Metric Containers) are options, and live in DIOs or DAOs, so
> would still be limited as to how they flow up/down the DAG.  This just
> changes how we encapsulate the options, but does not change the rules on
> where the information flows.
> 
> The point of introducing the NAO was that it would have different rules
> about where it goes?
> 
> --