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