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

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

Hello Michael:



> I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1)



This is correct. The RPL artifact for the join request is only the RPI, and the packet (going up) looks as follows in both storing and non-storing, assuming the join is a UDP/CoAP packet.



  The format in Figure 16 is logically equivalent to the uncompressed

   format illustrated in Figure 17:



   +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   |  IPv6 Header  | Hop-by-Hop |  RPI in       |  ICMP message ...

   |  NH = 58      | Header     |  RPL Option   |

   +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...



               Figure 17: Uncompressed ICMP Packet with RPI



   For a UDP packet, the transport header can be compressed with 6LoWPAN

   HC [RFC6282<https://tools.ietf.org/html/rfc6282>] as illustrated in Figure 18:



   +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...

   |11110001| RPI-  | NH=1        |11110CPP| Compressed | UDP

   |Page 1  | 6LoRH | LOWPAN_IPHC | UDP    | UDP header | Payload

   +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...

                     <-         RFC 6282<https://tools.ietf.org/html/rfc6282>              ->

                                No RPL artifact



               Figure 18: Uncompressed ICMP Packet with RPI



RFC 8138 places the artifact in front so it is easy to manipulate. After that, you find the IPHC, which encodes the traffic class. Nothing really complex.



A simpler side question is whether the rest of the join flow (response etc...) should trigger allocation of timeslots by the SF or not. If the response only comes for valid requests then I supposed it should.



Take care,



Pascal





-----Original Message-----
From: 6tisch [mailto:[e-mail]] On Behalf Of Michael Richardson
Sent: mercredi 15 novembre 2017 03:29
To: [e-mail]
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?





Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

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



    > I thought it was a typo, and I passed it by.



    > Why in this non-storing, RPL-aware situation is there even an IPIP outer

    > header for traffic from the proxy to the DODAG root?



Since I re-read Pascal's answer (in the light of my "day"), I now see why it can not go into to the outer IP header, because we didn't not plan for it.

I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1)



If we can agree that this is the way, then I think we also need to agree that certain AFxx would be assigned to available bandwidth, and not cause 6top to allocate any additional bandwidth.  This does not really fit "AF" Diffserv in some ways (which in some ways to buffer/delay rather than drop...).



--

Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works  -= IPv6 IoT consulting =-