Well, if there is such interaction, it does not come from the RH3 compression but from the IP in IP compression that allows to elide a well-known root. This means that if the root is not that well-known, like the node participate to multiple DODAGs, then the RPI must be included together with RH3. Which is mandated by RPL for that reason, nothing very new there.
With the current specs, for a packet with a RH3, the source in the IPv6 header when uncompressed is always the root. When 6LoWPAN decompresses the packet, it has to restore the root address first. And the proposal says use that as reference for decompression of the next entries in the RH3, as opposed to the final destination in the (inner) IP header. The change is a slight improvement, since it addresses the case where the leaf does not belong to the same compression domain as the RPL mesh nodes, and avoids having to dig into the inner IP header. IOW, with the change, the intermediate routers can process a packet without looking at the inner IP in IP. In the future, if we allow nodes that are different from the root to write an RH3, then we'll have to decide if we use the source of the packet or the root as reference. I'd probably still use the root so we can compress the source using the root as reference. Cheers, Pascal > -----Original Message----- > From: Michael Richardson [mailto:[email protected]] > Sent: mardi 19 janvier 2016 23:06 > To: Simon Duquennoy <[email protected]> > Cc: Pascal Thubert (pthubert) <[email protected]>; [email protected]; > Routing Over Low power and Lossy networks <[email protected]>; Tengfei Chang > <[email protected]>; [email protected] > Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH > > > Simon Duquennoy <[email protected]> wrote: > > Not really. It was rather my view of the architecture that differs a > > bit from what you describe in your previous mail. > > okay. > > > For me RPL produces the RH3 and then passes the packet down the > stack > > for compression. Or for incoming packets, first there is > > decompression, then the IPv6 packet with its headers and extension > > headers are passed up to RPL etc. If find it odd to force upper layers > > to work on 6lowpan compressed formats. > > RPL is the thing in RFC6550, a routing protocol, that runs over ICMP ND > messages. > > I think the thing you are describing is the IPv6 stack, and you don't like > that > the IPv6 stack has to interact with the link adaptation layer. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
