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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll