Pascal, You're saying that I can be exchanging data between motes in the mesh and hosts on the Internet, while inserting/deleting RPI and RPL routing headers en-route, i.e. without IPIP?
Thomas On Wed, Nov 15, 2017 at 10:42 AM, Pascal Thubert (pthubert) < [email protected]> wrote: > Hey, not so Thomas. > > > > The 6MAN rules have been bended in more than one way since the times when > the IP in IP discussions took place. > > > > 1) RFC8200 allows routers to ignore HbH options so sending the RPI > outside the RPL domain is OK. We actually made it ignorable in > https://datatracker.ietf.org/doc/html/draft-ietf-roll- > useofrplinfo-19#section-3.2 > > > > 2) Header insertion is not as Tabu as it was, with segment routing > inserting them anyway. So I expect that removing the RPI is OK. Good news, > with 6LoRH, it just means ignore the 6LoRH headers, start by decompressing > the IPHC and forward just that. It was a design goal for 6LoRH to make the > header insertion/deletion, the routing header operations easy to code and > debug. The packet starting at the IPHC is exactly what should be > decompressed and forwarded, and there is no RPL artifact to it. > > > > DPI means a layer violation. Looking at the IPHC is not. So conceptually, > yes that was very far off J > > > > Take care, > > > > Pascal > > > > *From:* Thomas Watteyne [mailto:[email protected]] > *Sent:* mercredi 15 novembre 2017 16:55 > *To:* Pascal Thubert (pthubert) <[email protected]> > *Cc:* Michael Richardson <[email protected]>; [email protected] > > *Subject:* 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) < > [email protected]> 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:[email protected]] On Behalf Of Michael > Richardson > Sent: mercredi 15 novembre 2017 03:29 > To: [email protected] > Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header? > > > > > > Michael Richardson <[email protected]> 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 <[email protected]>, Sandelman Software Works -= > IPv6 IoT consulting =- > > > > > > > > > _______________________________________________ > 6tisch mailing list > [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 > > _______________________________________ > -- _______________________________________ 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 _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
