Hello Ralph: The clock synchronization in 802.15.4 is adequate for 6TiSCH.
RPL provides improvements on the structure that is used to propagate that synchronization. An improvement is related to the graph maintenance. RPL has one to start with. Another is that the way we architected this, 6TiSCH nodes do not need to build and maintain 2 different graphs, one for data and one for clock synchronization. Maintaining both would mean doubling the state etc... Cheers, Pascal > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: jeudi 10 décembre 2015 14:43 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: Tero Kivinen <[email protected]>; [email protected]; draft-ietf-6tisch- > [email protected] > Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > > > > On Dec 10, 2015, at 7:50 AM, Pascal Thubert (pthubert) > <[email protected]> wrote: > > > > Hello Tero: > > > > Joining a tree is easy, maintaining a loopless structure is more complex. > > Most > of RPL complexity is actually to address the latter. We do not want to > duplicate > that effort at L2. With 6TiSCH, RPL's rank is fed into the Join Metric field. > That's > how we do it. > > Is there an analysis published somewhere that demonstrates how time > synchronization in 802.15.4-* is inadequate for 6TiSCH? > > - Ralph > > > > Cheers, > > > > Pascal > > > > > >> -----Original Message----- > >> From: Tero Kivinen [mailto:[email protected]] > >> Sent: jeudi 10 décembre 2015 13:17 > >> To: Pascal Thubert (pthubert) <[email protected]> > >> Cc: Ralph Droms (rdroms) <[email protected]>; [email protected]; > >> draft-ietf- [email protected] > >> Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on > >> minimal > >> > >> 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
