Re: 6lowpan status

[Jukka Rissanen <jukka.rissanen@linux.intel.com>]

Hi Alex,

On ma, 2014-09-01 at 13:38 +0200, Alexander Aring wrote:
> Hi,
> 
> On Mon, Sep 01, 2014 at 01:36:14PM +0300, Jukka Rissanen wrote:
> > Hi Alex,
> > 
> > I saw your RFC mail (9 Aug) about generic compression layer. Was there
> > any functionality changes by this RFC or was it just refactoring the
> > code?
> > 
> 
> It's not just refactoring. The point is that there are many of RFC's
> outside which declare a next header compession format (like UDP). UDP is
> the only one next header compression which we currenlty support. If we
> don't add a layer to add a new header compression format, all people
> hack this into the iphc.c file. I don't know what you think about this
> but I really don't like that.
> 
> This code adds a layer for this and supports all other known next header
> compression formats in the way that we drop the packets afterwards
> instead of deliver garabage to next layer (IPv6).
> 
> The layer avoids that everybody hacks static code into iphc file.

Ok, sounds like a plan.

> 
> Please let me know if this is okay for you, then I will send a v2 with
> changes.

Sure, just send new version.

> 
> > Anyway, looks ok to me although I just browsed quickly through the code,
> > did not really review it :) Just wondering do we need more
> > subdirectories under 6lowpan or could we just put everything into
> > 6lowpan dir (just to keep it simple)? No big preference here thou.
> > 
> 
> Don't know, but there is a unkown number of possible next header compression
> formats outside, we should split it in a new subdirectorie. What I
> actually mean, don't hack every next header compression format in a
> single file.

I was not really thinking that all the stuff would be in single file. I
was just pondering is there really a need for sub-directory, after all
the number of files in net/6lowpan directory is currently very small so
one option could be to put the nhc files directly into 6lowpan directory
(and perhaps adding them nhc_ prefix). Anyway, this is minor thing and I
am fine with having sub-directories.

> 
> For address compression/uncompression this is fine, there is no unknown
> numbers of compression ways.
> 
> I know only IPHC and HC1. HC1 should be support for receiving side and
> it's obsolete, but this is rfc 4944 so it's only related to 802.15.4.
> 
> Some or later we need to add support for this, but this should not used
> by bluetooth 6LoWPAN.
> 
> > I saw the mail from Varka Bhadram (6 Aug) about RFC 6775 support. That
> > looked interesting. Did you get the code from him (if yes, could you
> > also send it to me)? Do you know why this guy have not send this stuff
> > to upstream?
> > 
> 
> The 802.15.4 mac layer has some neighbor discovery issues which are not
> solved currently. It's about two kinds of mac addresses, for bluetooth
> it should be fine. A small description about this problem is here [1].
> 
> We need some way to trigger 6LoWPAN/Layer 2 data across the IPv6 layer
> and this isn't easy. Everything what we do on runtime decisions makes
> the IPv6 stack slower and we should avoid that.

Yep, agreed.

> 
> 
> 
> I currently working on a big rework of the 802.15.4 layer and will try
> to bring this mainline at end of this month. Our mac layer is currenlty
> in an not useable state. :(
> 
> I don't have time to make some effort after IPv6, currently I work on
> the rework and will solve the two kind mac addresses issues with the
> neighbor discovery cache, then we are in some state which we don't have
> some broken support of functionality.
> 
> 
> Maybe simple talk with Varka about what he did there, because I don't
> really know what he exactly did there. The code what I saw isn't
> mainline able. [0] What I know that RFC 6775 and the actually
> implementation need to handle the two kinds of mac addresses (which is
> broken currenlty) and need support of context based address compression.
> 
> I don't have time to add support for this. I need to rescue the 802.15.4
> layer. Sorry! Maybe after that... or maybe somebody will do this work.
> It sounds for me crazy to support RFC6775 which has dependencies on
> other functionality which we doesn't support right now. For bluetooth
> the mac layer works great, we only needs support for context based
> address compression then.

Ok. Currently I am also busy with some other stuff but I try to find
some time to investigate the RFC6775 more. Cannot really promise any
dates etc.

> 
> 
> I CC the new mailinglist for IEEE 802.15.4/IEEE 802.15.4 6LoWPAN
> "linux-wpan" and bluetooth. We should not talk about this under the
> hood.
> 
> - Alex
> 
> [0] https://www.mail-archive.com/linux-zigbee-devel%40lists.sourceforge.net/msg02018.html
> [1] http://www.spinics.net/lists/netdev/msg291767.html


Cheers,
Jukka