Hi Michael,
Regarding to including DAG rank into 6top NeighborList, I think, besides RPL,
there may be other routing protocols working on top of 6top in the future.
Thus, it could be better to decouple 6top sublayer and upper layer protocol
like RPL.
What do you think?
What other people think?
ThanksQin
On Thursday, June 11, 2015 1:38 AM, Michael Richardson
<mcr+i...@sandelman.ca> wrote:
Pascal Thubert (pthubert) <pthub...@cisco.com> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
