Simon Duquennoy <[email protected]> wrote:
> 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.
It's just that *RPL* doesn't produce the RH3...
The RPL produces a routing table for the "kernel", and the kernel produces
the RH3, and it's right there that the 6LoRH should be happening. I'd rather
like the headers for the 6LoRH to be precomputed and attached to the routing
entry, and that's what I'd do on machine with a bit more ram.
> Generally speaking 6lowpan offers one-to-one mappings between
> compressed and original headers, I think it is a pity that 6LoRH
> doesn't.
It's true that not all RH3 headers can be as efficiently compressed.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
