Hello Thomas
For what I see:
We need to specify that with 6LoRH IP in IP, the TOS bits are in the inner
(RFC6282) packet.
It will cost one octet in RFC 6282 encoding
https://tools.ietf.org/html/rfc6282#section-3.2.1
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN| DSCP |
+-+-+-+-+-+-+-+-+
Figure 6: TF = 10: Traffic Class carried in-line
We need to specify (ranges of) traffic classes and how they are used by mSF,
which are ignored (e.g. CSx in
https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml), which are
taken seriously or over seriously.
We have to specify which traffic class we use in the join (e.g. CS1), and it
must match mSF spec ignored.
Make sense?
Pascal
From: Thomas Watteyne [mailto:[email protected]]
Sent: dimanche 12 novembre 2017 08:33
To: Pascal Thubert (pthubert) <[email protected]>
Cc: Michael Richardson <[email protected]>; 6tisch <[email protected]>;
Mališa Vučinić <[email protected]>
Subject: Re: [6tisch] Tagging join traffic
Pascal,
Thanks for the input. Trying to evaluate the overhead of using the traffic
class bits. I assume we want to have one dedicated traffic class for the join
request/reply, which tells nodes NOT to take that traffic into account for
deciding whether to add cells.
- what must be standardized, if anything?
- what would a join request now look like, and what's the hit in terms of byte
count?
Thomas
On Thu, Nov 9, 2017 at 9:31 AM, Pascal Thubert (pthubert)
<[email protected]<mailto:[email protected]>> wrote:
I do
Digging in the packet even with nice names like DPI is a layer violation. It
breaks the e2e principle so that if we add something to the end points the join
message may become unreadable by the dpi. The art of the IETF translates upper
layer semantics in lower layer abstraction and in this case we have the TOS
bits. RFC 6282 allows to express those in a concise fashion. 6LoRH does not and
if IP in IP is used the TOS bits of the inner packet must be used....
Regards,
Pascal
Le 8 nov. 2017 à 23:42, Thomas Watteyne
<[email protected]<mailto:[email protected]>> a écrit :
Thanks Michael.
Does everyone agree with Michael's comments?
On Wed, Nov 8, 2017 at 8:12 PM, Michael Richardson
<[email protected]<mailto:[email protected]>> wrote:
Thomas Watteyne <[email protected]<mailto:[email protected]>>
wrote:
> option 1: we don't change the format of the packet, and ask forwarding
> nodes to (deep) inspect the packets, looking for the CoAP
> Stateless-Proxy option.
It's specific to this join process, and is expensive to do.
> option 2: we change the packet format, and
> introduce semantics in the traffic class bits in the IPv6 header
It's general to many things.
--
Michael Richardson <[email protected]<mailto:mcr%[email protected]>>,
Sandelman Software Works
-= IPv6 IoT consulting =-
--
_______________________________________
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<http://www.thomaswatteyne.com>
_______________________________________
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
--
_______________________________________
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<http://www.thomaswatteyne.com>
_______________________________________
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
