Pascal Thubert (pthubert) writes:
> > That capability is part of our bare minimum. If someone only cares
> > for hub and spoke, then RPL is not needed, but supporting only
> > that model is below the bar of the 6TiSCH bare minimum.
> >
> > I still think tying the join process to the use of RPL is a bad
> > idea, but that's a minor design point for the WG.
>
> If it was only that, I'd agree.
>
> But we also need RPL to build a loop-less structure for the clock
> synchronization, so we do not need an additional routing method for
> that purpose only.
Hmm.. why do not use the 802.15.4 way of doing that? 802.15.4 already
has method of generating time synchronization hierarchy.
I.e. the 802.15.4 says that Join Metric (used to be Join Priority) is
set to be the received EB Join Metric + 1.
>From the 802.15.4e:
The beaconing device’s join priority is the lowest join
priority heard when it joined the network plus one.
>From the 802.15.4-2015:
The sum of one and the value of the Join Metric field from the
TSCH Synchronization IE, 7.4.4.2, received in the Enhanced
Beacon frame used by the device joining the network. If the
device is the an endpoint, the value shall be set to zero.
So in the 802.15.4 the join metric of PAN coordinator / endpoint is 0,
all nodes joining directly to it has join metric of 1, and nodes
joining to them has 2 and so on.
If the 6TiSCH is using join Metric differently then it will not be
following the 802.15.4.
> As you know, clock synchronization is key to the TSCH operation and
> if a node loses its sense of time, it lose connectivity and will
> need to rejoin.
Which is why it is already specified in the 802.15.4. See section
6.5.3 Synchronization in TSCH PAN of the 802.15.4-2015 (used to be
section 5.1.4.2a in 802.15.4e).
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
