Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Thomas :

I agree it is non-obvious. Here’s why I ended up with that recommendation:


1)      The IP in IP 6LoRH in RFC8138 was designed for the minimal encapsulation as opposed to a generic one, basically a place holder for the outer addresses to be added and removed easily, and meltdown avoidance with a hop limit; everything else is defaulted. This was just an artifact to pass the 6MAN logo. Seems that since then, the law has been bended but that’s another story. Its format is as follows:

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-       ...      -+
    |1|0|1| Length  | 6LoRH Type 6  |  Hop Limit    | Encaps. Address  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-       ...      -+

                       Figure 14: The IP-in-IP-6LoRH

As you see, there is not provision to transport traffic class in that encoding. To transport the TC in outer IP in IP, we’d need to specify a new 6LoRH type for richer IP in IP. Can be done, but quite a bit of hassle. When you asked, I translated “with a minimum changes in mind” and answered accordingly.


2)      In the particular case of the join packet from the join proxy upwards, there is probably no IP in IP, unless an extra encapsulator finds a reason to do so (https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-19#page-17); in the general case of IP in IP, the encapsulator may or may not be the source of the packet; for an encapsulated join, it would not be. So for the generic case of a packet that has to be encapsulated, we’d have to set rules on whether the encapsulator echoes the inned TC in the outer TC. Again, hassle, hassle. Not having an outer TC gives back the control to the source, the JP in our case. At the expense of extra complexity in a node that care whether there is a TC, and which has to dig down to IPHC. Not that hard though.

Makes sense?

Pascal


From: 6tisch [mailto:[e-mail]] On Behalf Of Thomas Watteyne
Sent: mardi 14 novembre 2017 14:44
To: [e-mail]
Subject: [6tisch] tagging join traffic wih DSCP: why inside IP header?

Pascal,

During the WG meeting yesterday, we discussed using DSCP bits as a way to identify join request/reply messages. We talked about mapping, in the minimal-security spec, the different DSCP values to scheduling behavior.

But you indicated the DSCP bits would be in the inside IPv6 header. That doesn't make sense to me, can you please provide more info? The outside IPv6 header looks to me like the right place to put the bits.

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<http://www.thomaswatteyne.com>
_______________________________________