Pascal Thubert (pthubert) <[email protected]> wrote: > A node has a list of RPL parents per RPL instance. But that’s a RPL > problem and we probably need a RPL data model to be done at ROLL.
yes, so I'm considering whether the RPL data model can take this from the
6tisch model, because we badly need a standard way to get the mesh topology
out, and I think 6tisch needs all of that information anyway.
> OTOH, there is one (or more?) RPL instance that is used for 6TiSCH
> timing. I think all we need in 6top is an information of which RPL
> instance(s) is (are) used for timing and hten the admin can read the
> RPL info about that instance in the RPL data model.
AFAIK, the RPL instance isn't just used for (ASN) timing, it's also used for
communication with a PCE, for best-effort traffic, possibly for join traffic,
and I would have assumed that the DIO multicasts are how one discovers
adjacent nodes for the NeighbourList that the PCE needs.
As far as as I can see, all we need to make NeighbourList able to provide
the RPL level neighbour information is the DAG Rank of each neighbour.
It seems to me that if we are able to pick an RPL parent, that we would also
know the signal strength that the peer hears us.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
