You indeed don’t need page 1 for IPHC. You need to be on page 1 once you need 6LoRH.
(My proposal was to simply define 6TiSCH to start in page 1. No idea whether that removes any ever-so-remote compatibility with 6LoWPAN or if there is any other reason to start off in page 0.) Grüße, Carsten > On Jul 5, 2017, at 12:02, Simon Duquennoy <[email protected]> wrote: > > In Thomas' example > https://tools.ietf.org/html/draft-munoz-6tisch-examples-00#section-3.6.1 > there is a page dispatch to page 1 (0xf1) followed by IPHC (no routing > header). In this case, couldn't one choose to elide the page dispatch > and directly include IPHC? Or is the IPHC different from a page 0 > IPHC? > Just checking if we're on the same page (no pun intended ;)) > > Thanks, > Simon > > > On Wed, Jun 28, 2017 at 1:41 AM, Michael Richardson > <[email protected]> wrote: >> >> Thomas Watteyne <[email protected]> wrote: >>> Simon, all, FYI, we agreed on Friday that using paging dispatch is the >>> right way forward. I propose we continue discussing on the plugtests >>> ML if that's going to create problems. >> >> Yes, but the point is that a non-6loRH node will not be able to decode other >> than "page 1", and we have no signaling mechanism to tell a 6loRH node to >> "fall back". >> >> That was intentional... We discussed having a flag in the RPL DIO to say if >> there were old nodes present, but decided it wasn't worth it. >> >> >> -- >> Michael Richardson <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
