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
