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

Pascal, Michael,

If there is no IPIP, then everything is easy. But, AFAICT, we want the JRC
to be able to live on the Internet, i.e. not per se co-located with the
DAGroot. In that case, the Join Request looks like any data packet sent by
the JP to an IPv6 address outside the mesh, which triggers IPIP because the
outer IP header contains the RPI.

So AFAICT, IPIP is needed unless we mandate that JRC and DAGroot are
collocated.

So with IPIP, if we want to play by the rules, forwarding routers (nodes in
the mesh) only look at the outer IP header, and treat the inner IP header
as opaque. So if we use RFC6282 for that header with TF=b10 so ECN+DSCP are
carried inline, it doesn't matter. AFAICT, you recommend to "dig down to
IPHC". Looks more and more like my initial recommendation of using DPI
wasn't that far off :-)

Thomas

On Wed, Nov 15, 2017 at 2:37 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> 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:6tisch-bounces@ietf.org] On Behalf Of Michael
> Richardson
> Sent: mercredi 15 novembre 2017 03:29
> To: 6tisch@ietf.org
> Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?
>
>
>
>
>
> Michael Richardson <mcr+ietf@sandelman.ca> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
>
>
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> 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
_______________________________________