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 bett
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
wrote:
> That would make sense and save a byte in all cases but is this
> compliant with RFC 80
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 6LoWPA
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.
On Wed, Jul 5, 2017 at 12:05 PM, Thomas Watteyne
wrote:
> Simon,
>
> Didn't look at details, but you look at examples-00. Could you please check
>
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
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
On Wed, Jul 5, 2017 at 12:02 PM, Simon Duquennoy
wrote:
> In Thomas' example
> https://tools.ietf.org/html/draft-munoz-6tisch-examples-00#section-3.6.1
>
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
Thomas Watteyne 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
True, we need an explicit switch in there.
On Tue, Jun 27, 2017 at 11:30 AM, Carsten Bormann wrote:
> On Jun 27, 2017, at 10:40, Thomas Watteyne
> 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.
>
On Jun 27, 2017, at 10:40, Thomas Watteyne 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
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.
On Tue, Jun 27, 2017 at 9:24 AM, Carsten Bormann wrote:
> I hope 6TiSCH is defined to start out in page 1?
>
> Grüße, Carsten
>
> > On Jun 27, 2017, at 08:33, Thomas W
I hope 6TiSCH is defined to start out in page 1?
Grüße, Carsten
> On Jun 27, 2017, at 08:33, Thomas Watteyne 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
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
wrote:
>
> Simon Duquennoy wrote:
> > Will single-hop
Simon Duquennoy 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 , Sandelman Software Works
-= IPv6 IoT consulting =-
s
>
> 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 11
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
+-+-+-+-+-+-+-+-+
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!
Sim
I'm going to add 6LoRH as requirement to implement for the td.
Le mer. 21 juin 2017 à 12:07, Thomas Watteyne a
écrit :
> +1
>
> There is only 1-2 tests that require multi-hop.
>
> On Tue, Jun 20, 2017 at 1:44 PM, Xavi Vilajosana Guillen <
> xvilajos...@uoc.edu> wrote:
>
>> Hi Simon,
>>
>> You wi
+1
There is only 1-2 tests that require multi-hop.
On Tue, Jun 20, 2017 at 1:44 PM, Xavi Vilajosana Guillen <
xvilajos...@uoc.edu> wrote:
> 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
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 :
> Hi,
>
> In the current description, the nodes are expected to run, among others,
> 6LoRH and OSCOAP.
>
> Question:
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'
21 matches
Mail list logo
