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

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Tue, 20 Jun 2017 13:44:26 +0200

Hi Simon,

You will be able to test quite a lot of things
 minimal, 6P, basic security and I assume almost all 1-hop cases.

regards
X

2017-06-19 16:01 GMT+02:00 Simon Duquennoy <[email-masked]>:

> Hi,
>
> In the current description, the nodes are expected to run, among others,
> 6LoRH and OSCOAP.
>
> Question: how much will be able to test if we don't support any of the
> above? Particularly worried about 6LoRH: will the single-hop tests be
> possible between nodes that support 6LoRH and nodes that don't?
>
> Thanks,
> Simon
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 21 Jun 2017 12:06:59 +0200

+1

There is only 1-2 tests that require multi-hop.

On Tue, Jun 20, 2017 at 1:44 PM, Xavi Vilajosana Guillen <
[email-masked]> wrote:

> (+34) 646 633 681 <+34%20646%2063%2036%2081>

-- 
_______________________________________

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: Remy Leone <[email-masked]>
Date: Wed, 21 Jun 2017 14:21:01 +0000

I'm going to add 6LoRH as requirement to implement for the td.

Le mer. 21 juin 2017 à 12:07, Thomas Watteyne <[email-masked]> a

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 21 Jun 2017 16:41:22 +0200

Thanks for the answers, but the thing I would really like to double-check
here is:

Will single-hop communication work seamlessly between a 6LoRH node and a
non-6LoRH node?
I don't know the details of 6LoRH and wonder how much the dispatch headers
differ etc. -- in the single-hop case.

Thanks!
Simon

On Wed, Jun 21, 2017 at 4:21 PM, Remy Leone <[email-masked]> wrote:

> Le mer. 21 juin 2017 à 12:07, Thomas Watteyne <[email-masked]>
> a écrit :
>
>> +1
>>
>>>> In the current description, the nodes are expected to run, among
>>>> others, 6LoRH and OSCOAP.
>>>>

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Wed, 21 Jun 2017 17:12:12 +0200

Hi Simon

(adding Tengfei as he can help also on this)

6LORH uses paging dispatch (rfc8025). This is a modification of the
dispatch byte so 4 of the last bits are used to indicate a page.

                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |1|1|1|1|Page Nb|
                           +-+-+-+-+-+-+-+-+

The possible values for the dispatch byte are then

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Bit Pattern  |    Page     | Header Type         |  Reference      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |     0       |  NALP               |  RFC 4944
<https://tools.ietf.org/html/rfc4944>,      |
 |               |             |                     |  this document  |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  00 xxxxxx    |    1-14     |  Unassigned         |                 |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |               |    15       |  Reserved for       |  this document  |
 |               |             |  Experimental Use   |                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |     0       |  ESC                |  RFC 6282
<https://tools.ietf.org/html/rfc6282>,      |
 |               |             |                     |  this document  |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  01 000000    |    1-14     |  Unassigned         |                 |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |               |    15       |  Reserved for       |  this document  |
 |               |             |  Experimental Use   |                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ...                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |    0-1      |  LOWPAN_IPHC        |  RFC 6282
<https://tools.ietf.org/html/rfc6282>,      |
 |               |             |                     |  this document  |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  01 1xxxxx    |    2-14     |  Unassigned         |                 |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |               |    15       |  Reserved for       |  this document  |
 |               |             |  Experimental Use   |                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ...                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  11 11xxxx    |    0-15     |  Page switch        |  this document  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in contiki you are using page 0.
We are pushing to have it implemented and some of the messages will be sent
using page 1. (we are discussing this now)

The question is what happens in Contiki if you receive a Dispatch byte with
a page that is not 0, e.g 110001 what Contiki will do?  How hard would be
to add this Page 1 parsing assuming that what will follow will be IP
extension headers (6LoRH) with another dispatch starting with 10xxxxxx

X

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 21 Jun 2017 17:56:31 +0200

>
> The question is what happens in Contiki if you receive a Dispatch byte with a page that is not 0, e.g 110001 what Contiki will do?
>
>
Contiki does not implement paging dispatch (rfc8025), and will basically
discard anything that is not covered in RFC 6282 such as a dispatch
starting with 1111

> How hard would be to add this Page 1 parsing assuming that what will
> follow will be IP extension headers (6LoRH) with another dispatch starting
> with 10xxxxxx
>

Not hard, but some work ;)

Any chance we can all stick to LOWPAN_IPHC, page 0 for the single-hop tests?

Thanks

>> I don't know the details of 6LoRH and wonder how much the dispatch
>> headers differ etc. -- in the single-hop case.
>>
>> Thanks!
>> Simon
>>
>>
>>>>>> Question: how much will be able to test if we don't support any of
>>>>>> the above? Particularly worried about 6LoRH: will the single-hop tests be

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Jun 2017 14:44:36 -0400

Simon Duquennoy <[email-masked]> wrote:
    > Will single-hop communication work seamlessly between a 6LoRH node and
    > a non-6LoRH node?

no. A 6loRH node could implement both, but in general, it is a flag day on
the protocol.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Jun 2017 08:33:03 +0200

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.
thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Jun 2017 09:24:00 +0200

I hope 6TiSCH is defined to start out in page 1?

Grüße, Carsten

> On Jun 27, 2017, at 08:33, 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.
> thomas
> 
> On Wed, Jun 21, 2017 at 8:44 PM, Michael Richardson <[email-masked]> wrote:
>

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Jun 2017 10:40:49 +0200

yes. Take a look at example
https://tools.ietf.org/html/draft-munoz-6tisch-examples-00#section-3.6.1 to
see it all fit together.

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Jun 2017 11:30:51 +0200

On Jun 27, 2017, at 10:40, Thomas Watteyne <[email-masked]> wrote:
> 
> yes. Take a look at example https://tools.ietf.org/html/draft-munoz-6tisch-examples-00#section-3.6.1 to see it all fit together.

Well, this clearly shows an “f1” in the packet (which is an explicit switch to page 1).
More efficient (OK, saving one teeny byte) would be to define page 1 as the start page in 6tisch.

Grüße, Carsten

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Jun 2017 12:00:19 +0200

True, we need an explicit switch in there.

On Tue, Jun 27, 2017 at 11:30 AM, Carsten Bormann <[email-masked]> wrote:

> > yes. Take a look at example https://tools.ietf.org/html/
> draft-munoz-6tisch-examples-00#section-3.6.1 to see it all fit together.
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Jun 2017 19:41:51 -0400

Thomas Watteyne <[email-masked]> wrote:
    > 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.