Re: [PATCHv2 bluetooth-next 0/2] 6lowpan: introduce nhc framework

[Alexander Aring <alex.aring@gmail.com>]

On Tue, Dec 02, 2014 at 11:23:36AM +0200, Jukka Rissanen wrote:
...
> 
> I forgot to mention earlier that I think we need to support the case
> where some clients are using different compression method than the other
> (at the same time). What do you think?
> 
>

_Currently_ I would to do the following:


Sending side:

We have a mapping from nexthdr IPv6 field to the configurated (at the
moment the defaults compression methods) next header compression.

lowpan_compress -> nexthdr to nhc struct -> do nhc compression

This is a 1:1 mapping for nexthdr as UDP we have RFC6282 UDP.

_Maybe_ we can do some socket options settings in the future to have not
always a 1:1 mapping. Sending sockopts to 6LoWPAN layer seems to be
difficult, I don't know how much possible that is and the IPv6 agree
with that. Otherwise we need some great idea to make allow different
compression methods per socket. Currently a 1:1 seems to be okay.


Receiving side:

There we need to support everything what we can support. The next header
compression id is a variable length of bitstring (that's why there is a
complicated rbtree datastructure inside the nhc framework).

This number is unique to each compression methods. It's some kind of n:1
mapping e.g. (UDP RFC6282) to UDP and (UDP FOOBAR) to UDP.



So sending side _can_ be optionally and receiving _should_ be implemented.

I have a new series which makes both optionally. The reason is that we
can register the NHC ID and print a warning which NHC ID isn't
supported. So this beahviour is more "We know this NHC but we don't
support compression and uncompression". This will print a warning and
users have two options:

1. Implement the nhc.

2. Change network configuration to not do this nhc on other nodes.

- Alex