Subject: Re: [6tisch] 6TiSCH interop: 6LoRH and OSCOAP as a requirement?

From: Simon Duquennoy <[email-masked]>
Date: Wed, 5 Jul 2017 12:02:01 +0200

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-masked]> wrote:
>
> Thomas Watteyne <[email-masked]> 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-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 5 Jul 2017 12:05:06 +0200

Simon,

Didn't look at details, but you look at examples-00. Could you please check
examples-02 and whether the issue is still there?

Thomas

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Jul 2017 12:50:28 +0200

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-masked]> wrote:
> 
> In Thomas' example
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 5 Jul 2017 13:02:01 +0200

Yes, examples-02 has the exact same thing: 0xf1 directly followed by IPHC.
If my understanding is correct, this is compliant but a waste of one byte.

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 5 Jul 2017 13:03:14 +0200

That would make sense and save a byte in all cases but is this
compliant with RFC 8025?"

"
Values of the Dispatch byte defined in [RFC4944] are considered as
   belonging to the Page 0 parsing context, which is the default and
   does not need to be signaled explicitly at the beginning of a 6LoWPAN
   packet.  This ensures backward compatibility with existing
   implementations of 6LoWPAN.
"

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 5 Jul 2017 13:05:23 +0200

Simon, I understand your point now.

Carsten, I understand your proposal, but given the text of RFC8025, we did
not choose to omit the page switch byte.

On Wed, Jul 5, 2017 at 1:03 PM, Simon Duquennoy <[email-masked]>
wrote:

> > (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
> >
> >

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 5 Jul 2017 20:30:26 +0900

Hi,

Here is my understanding...

- 1. If you're sending a LOWPAN_IPHC frame without 6LoRH, it'd be better 
to use page-0 LOWPAN_IPHC, without paging dispatch, in case a receiver 
is a legacy, non-6TiSCH, node.

- 2. Since a node may receive a page-1 LOWPAN_IPHC frame without 6LoRH, 
it'd be better to support paging dispatch even though the node doesn't 
support 6LoRH.

The first thing is the same as what Simon pointed out with the text in 
RFC 8025. The second thing is what is shown in 3.6.1 of 
draft-munoz-6tisch-examples-02.

Best,
Yatch