On Tue, Jan 19, 2016 at 10:10 PM, Pascal Thubert (pthubert) <[email protected]> wrote: > Hello Simon: > > Could we take some examples? If possible most of them reasonably realistic? > We"ll see the outpout of both methods. > > Again I have nothing against allowing the precision of the byte in the > compression, but then is that a real world problem worth wasting types in the > 6LoRH? I'd think not for the first 6 actets of the prefix.
OK the effectiveness of the compression wasn't my main concern anyway, it was rather on the mapping between RH3 and RH3-6LoRH. > > I agree with you for the goal > " > Any level of awareness is too much, IMO a RPL implementation should run > unmodified yet benefit from 6LoRH. > " > But the draft does not achieve it as you prescribe. > > The 6LoRH is designed to enable the insertion of a RH3, the addition a RPI, > or the IP in IP encapsulation, or any combitnation thereof, without changing > a bit in the packet encoded with RFC 6282 (with the restrictive assumption > that the RPL artifacts are always encoded with 6LoRH). > > I think there is value in: > - preserving the RFC6282 handlers without a change > - manipulating easily the headers induced by RPL without touching the > original packet and in particular without the swap of destination address > with RH. > > Isn't that worht something? Yes I see much value in both the above! But I feel these goals could equally be achieved with simple compression of the standard RH3 header, rather than a redesign. I'm mostly worried about the fact that RPL implementations will have to produce 6LoRH headers, i.e. be 6lowpan-specific and play with 6lowpan compression from a layer above. BTW the new text you suggested above makes sense to me, it does clarify things. Thanks, Simon > > Pascal > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Simon Duquennoy >> Sent: mardi 19 janvier 2016 21:55 >> To: Michael Richardson <[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 >> >> Any level of awareness is too much, IMO a RPL implementation should run >> unmodified yet benefit from 6LoRH. >> For instance, if RPL produces a RH3 with cmpri of 6 and cmpre of 10, we end >> up with two RH3-6LoRH, each with its own "size unit", which has to be >> power of two -- we end up with a compressed possibly larger than the >> original. >> Another example is when more than two RH3-6LoRH are included to benefit >> from a variety of compression levels: in such case, it is not even possible >> to >> translate the compressed back into a standard RH3. >> >> Generally speaking 6lowpan offers one-to-one mappings between >> compressed and original headers, I think it is a pity that 6LoRH doesn't. >> >> On Tue, Jan 19, 2016 at 9:34 PM, Michael Richardson >> <[email protected]> wrote: >> > >> > Simon Duquennoy <[email protected]> wrote: >> > > I feel we need to make sure any valid RH3 can be compressed with >> 6LoRH. This >> > > way, RPL implementations do not need to be aware of 6LoRH. >> > >> > I'm sensitive to your need, but I'm not sure it's worthwhile. >> > >> > What kind of awareness do you feel is required? >> > There needs to be some communication of what are the interesting >> prefixes. >> > I don't see this as a problem. >> > >> > >> > -- >> > Michael Richardson <[email protected]>, Sandelman Software >> Works >> > -= IPv6 IoT consulting =- >> > >> > >> > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
