[RFC bluetooth-next 0/4] GHC compression detection

[RFC bluetooth-next 0/4] GHC compression detection

[Stefan Schmidt]

Hello.

This is a first stab at RFC7400. So far we only hook into the NHC framework to
detect the three registered GHC types (extension header, UDP and ICMPv6).
This is aligned with how we detect the NHC frames.

TODO items:
o How to handle reserved and unassigned ranges in the HEADER TYPE?
o Implement compression/decompresion for GHC UDP
o Implement compression/decompresion for GHC ICMPv6
o How to handle 6CIO in IPv6 ND?

Stefan Schmidt (4):
  6lowpan: clarify Kconfig entries for upcoming GHC support
  6lowpan: add nhc module for GHC extension header detection
  6lowpan: add nhc module for GHC UDP detection
  6lowpan: add nhc module for GHC ICMPv6 detection

 net/6lowpan/Kconfig                | 20 ++++++++++++++++++--
 net/6lowpan/Makefile               |  5 +++++
 net/6lowpan/ghc_extension_header.c | 27 +++++++++++++++++++++++++++
 net/6lowpan/ghc_icmpv6.c           | 27 +++++++++++++++++++++++++++
 net/6lowpan/ghc_udp.c              | 27 +++++++++++++++++++++++++++
 5 files changed, 104 insertions(+), 2 deletions(-)
 create mode 100644 net/6lowpan/ghc_extension_header.c
 create mode 100644 net/6lowpan/ghc_icmpv6.c
 create mode 100644 net/6lowpan/ghc_udp.c

regards
Stefan Schmidt

-- 
2.4.3

[RFC bluetooth-next 1/4] 6lowpan: clarify Kconfig entries for upcoming GHC support

[Stefan Schmidt]

Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
 net/6lowpan/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 7fa0f38..6af7a46 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -6,11 +6,12 @@ menuconfig 6LOWPAN
 	  "6LoWPAN" which is supported by IEEE 802.15.4 or Bluetooth stacks.
 
 menuconfig 6LOWPAN_NHC
-	tristate "Next Header Compression Support"
+	tristate "Next Header and Generic Header Compression Support"
 	depends on 6LOWPAN
 	default y
 	---help---
-	  Support for next header compression.
+	  Support for next header and generic header compression defined in
+	  RFC6282 and RFC7400.
 
 if 6LOWPAN_NHC
 
-- 
2.4.3

[RFC bluetooth-next 2/4] 6lowpan: add nhc module for GHC extension header detection

[Stefan Schmidt]

Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
 net/6lowpan/Kconfig                |  5 +++++
 net/6lowpan/Makefile               |  3 +++
 net/6lowpan/ghc_extension_header.c | 27 +++++++++++++++++++++++++++
 3 files changed, 35 insertions(+)
 create mode 100644 net/6lowpan/ghc_extension_header.c

diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 6af7a46..f541f50 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -59,4 +59,9 @@ config 6LOWPAN_NHC_UDP
 	---help---
 	  6LoWPAN IPv6 UDP Header compression according to RFC6282.
 
+config 6LOWPAN_GHC_EXTENSION_HEADER
+	tristate "GHC Extension Header Support"
+	default y
+	---help---
+
 endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index c6ffc55..5320b76 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -10,3 +10,6 @@ obj-$(CONFIG_6LOWPAN_NHC_IPV6) += nhc_ipv6.o
 obj-$(CONFIG_6LOWPAN_NHC_MOBILITY) += nhc_mobility.o
 obj-$(CONFIG_6LOWPAN_NHC_ROUTING) += nhc_routing.o
 obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
+
+#rfc7400 ghcs
+obj-$(CONFIG_6LOWPAN_GHC_EXTENSION_HEADER) += ghc_extension_header.o
diff --git a/net/6lowpan/ghc_extension_header.c b/net/6lowpan/ghc_extension_header.c
new file mode 100644
index 0000000..eeeabfa
--- /dev/null
+++ b/net/6lowpan/ghc_extension_header.c
@@ -0,0 +1,27 @@
+/*
+ *	6LoWPAN Extension Header compression according to RFC7400
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License
+ *	as published by the Free Software Foundation; either version
+ *	2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_EXTENSION_HEADER_IDLEN	1
+#define LOWPAN_GHC_EXTENSION_HEADER_ID_0	0xb0
+#define LOWPAN_GHC_EXTENSION_HEADER_MASK_0	0xf8
+
+static void ext_ghid_setup(struct lowpan_nhc *nhc)
+{
+	nhc->id[0] = LOWPAN_GHC_EXTENSION_HEADER_ID_0;
+	nhc->idmask[0] = LOWPAN_GHC_EXTENSION_HEADER_MASK_0;
+}
+
+LOWPAN_NHC(ghc_extension_header, "RFC7400 Extension Header", NEXTHDR_HOP, 0,
+	   ext_ghid_setup, LOWPAN_GHC_EXTENSION_HEADER_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_extension_header);
+MODULE_DESCRIPTION("6LoWPAN generic header RFC7400 Extension Header compression");
+MODULE_LICENSE("GPL");
-- 
2.4.3

[RFC bluetooth-next 3/4] 6lowpan: add nhc module for GHC UDP detection

[Stefan Schmidt]

Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
 net/6lowpan/Kconfig   |  5 +++++
 net/6lowpan/Makefile  |  1 +
 net/6lowpan/ghc_udp.c | 27 +++++++++++++++++++++++++++
 3 files changed, 33 insertions(+)
 create mode 100644 net/6lowpan/ghc_udp.c

diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index f541f50..67a786b 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -64,4 +64,9 @@ config 6LOWPAN_GHC_EXTENSION_HEADER
 	default y
 	---help---
 
+config 6LOWPAN_GHC_UDP
+	tristate "GHC UDP Support"
+	default y
+	---help---
+
 endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index 5320b76..4df6334 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
 
 #rfc7400 ghcs
 obj-$(CONFIG_6LOWPAN_GHC_EXTENSION_HEADER) += ghc_extension_header.o
+obj-$(CONFIG_6LOWPAN_GHC_UDP) += ghc_udp.o
diff --git a/net/6lowpan/ghc_udp.c b/net/6lowpan/ghc_udp.c
new file mode 100644
index 0000000..2675683
--- /dev/null
+++ b/net/6lowpan/ghc_udp.c
@@ -0,0 +1,27 @@
+/*
+ *	6LoWPAN UDP compression according to RFC7400
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License
+ *	as published by the Free Software Foundation; either version
+ *	2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_UDP_IDLEN	1
+#define LOWPAN_GHC_UDP_ID_0	0xd0
+#define LOWPAN_GHC_UDP_MASK_0	0xf8
+
+static void udp_ghid_setup(struct lowpan_nhc *nhc)
+{
+	nhc->id[0] = LOWPAN_GHC_UDP_ID_0;
+	nhc->idmask[0] = LOWPAN_GHC_UDP_MASK_0;
+}
+
+LOWPAN_NHC(ghc_udp, "RFC7400 UDP", NEXTHDR_HOP, 0,
+	   udp_ghid_setup, LOWPAN_GHC_UDP_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_udp);
+MODULE_DESCRIPTION("6LoWPAN generic header RFC7400 UDP compression");
+MODULE_LICENSE("GPL");
-- 
2.4.3

[RFC bluetooth-next 4/4] 6lowpan: add nhc module for GHC ICMPv6 detection

[Stefan Schmidt]

Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
 net/6lowpan/Kconfig      |  5 +++++
 net/6lowpan/Makefile     |  1 +
 net/6lowpan/ghc_icmpv6.c | 27 +++++++++++++++++++++++++++
 3 files changed, 33 insertions(+)
 create mode 100644 net/6lowpan/ghc_icmpv6.c

diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 67a786b..a34693d 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -69,4 +69,9 @@ config 6LOWPAN_GHC_UDP
 	default y
 	---help---
 
+config 6LOWPAN_GHC_ICMPV6
+	tristate "GHC ICMPv6 Support"
+	default y
+	---help---
+
 endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index 4df6334..c1a496b 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
 #rfc7400 ghcs
 obj-$(CONFIG_6LOWPAN_GHC_EXTENSION_HEADER) += ghc_extension_header.o
 obj-$(CONFIG_6LOWPAN_GHC_UDP) += ghc_udp.o
+obj-$(CONFIG_6LOWPAN_GHC_ICMPV6) += ghc_icmpv6.o
diff --git a/net/6lowpan/ghc_icmpv6.c b/net/6lowpan/ghc_icmpv6.c
new file mode 100644
index 0000000..378ebfe
--- /dev/null
+++ b/net/6lowpan/ghc_icmpv6.c
@@ -0,0 +1,27 @@
+/*
+ *	6LoWPAN ICMPv6 compression according to RFC7400
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License
+ *	as published by the Free Software Foundation; either version
+ *	2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_ICMPV6_IDLEN		1
+#define LOWPAN_GHC_ICMPV6_ID_0		0xdf
+#define LOWPAN_GHC_ICMPV6_MASK_0	0xff
+
+static void icmpv6_ghid_setup(struct lowpan_nhc *nhc)
+{
+	nhc->id[0] = LOWPAN_GHC_ICMPV6_ID_0;
+	nhc->idmask[0] = LOWPAN_GHC_ICMPV6_MASK_0;
+}
+
+LOWPAN_NHC(ghc_icmpv6, "RFC7400 ICMPv6", NEXTHDR_HOP, 0,
+	   icmpv6_ghid_setup, LOWPAN_GHC_ICMPV6_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_icmpv6);
+MODULE_DESCRIPTION("6LoWPAN generic header RFC7400 ICMPv6 compression");
+MODULE_LICENSE("GPL");
-- 
2.4.3

Re: [RFC bluetooth-next 0/4] GHC compression detection

[Alexander Aring]

Hi,

On Wed, Sep 09, 2015 at 05:26:29PM +0200, Stefan Schmidt wrote:
> Hello.
> 
> This is a first stab at RFC7400. So far we only hook into the NHC framework to
> detect the three registered GHC types (extension header, UDP and ICMPv6).
> This is aligned with how we detect the NHC frames.
> 

can we add a "nhc_..." prefix to all module names? Then we have
something like what netfilter does with "nf_...".

> TODO items:
> o How to handle reserved and unassigned ranges in the HEADER TYPE?

Maybe it's better to remove the current nhc_id evaluation. I did this
stuff with rb-tree by knowning RFC6282 only, there was the one
information given that "nhc id" is a variable length bitfield only. I
don't know how the "logic" about assign these nhc id's is, if iana has one.

What I see when I look at [0]. Maybe we could grab the same mechanism like
evaluate 6lowpan dispatch values, by returning RX_CONTINUE if the nhc_id
doesn't match. Determined by nhc_id length mask and id.

The rb-tree mechanism is MAYBE faster, but this depends on amount of
registered entries. I don't think there is ever so much many nhc ids
that a rb-tree give "huge" benefits that we should use a rb-tree now, or
it making thinks too much complex. :-/

I just stumble over rb-tree's to search a right datastructure for
matching variable length bitfields -> "strings". Now I am not sure if
this was a good idea to do this in that way.

These rbtree's are getting also a benefits only when the nhc_id is more
than one byte long and this also doesn't exist right now. Also the first
byte need to have one or more subtree's. Means e.g. the first byte need
to indicate that another bytes follows.

I suppose they will add some nhc_id byte like "1111 1111" which
indicates one byte will follows. If this will be only one byte, e.g. the
"1111 1111" then rbtree is surely the wrong datastructure... but maybe
they will also add some "1111 1110" which also indicates anothers
subtree of nhc_id's. I don't know it because there is no information
about that. Maybe iana [0] will say that with "Unassigned, reserved for
extensions" and it should stand somewhere in RFC6282, but I don't see
that somewhere inside of RFC6282 which describes "1111 1111". :-/

They describes something about a nhc class:

"(i.e., k one-bits followed by one zero-bit identify the general class
of NHC, followed by class-specific bit assignments)."

Maybe they meant something that:

"1111 1111" -> BAR nhc classes
"1111 1110" -> FOO nhc classes
....        -> ... nhc classes

Then a rbtree _maybe_ gives some benefit but I also think it doesn't
matter then, because it's simple not a huge amount of entries there.

- Alex

[0] https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#lowpan_nhc

Re: [RFC bluetooth-next 0/4] GHC compression detection

[Stefan Schmidt]

Hello.

On 13/09/15 15:51, Alexander Aring wrote:
> Hi,
>
> On Wed, Sep 09, 2015 at 05:26:29PM +0200, Stefan Schmidt wrote:
>> Hello.
>>
>> This is a first stab at RFC7400. So far we only hook into the NHC framework to
>> detect the three registered GHC types (extension header, UDP and ICMPv6).
>> This is aligned with how we detect the NHC frames.
>>
> can we add a "nhc_..." prefix to all module names? Then we have
> something like what netfilter does with "nf_...".
>

You mean like nhc_ghc_udp.c? Fine with me.

>> TODO items:
>> o How to handle reserved and unassigned ranges in the HEADER TYPE?
> Maybe it's better to remove the current nhc_id evaluation. I did this
> stuff with rb-tree by knowning RFC6282 only, there was the one
> information given that "nhc id" is a variable length bitfield only. I
> don't know how the "logic" about assign these nhc id's is, if iana has one.
>
> What I see when I look at [0]. Maybe we could grab the same mechanism like
> evaluate 6lowpan dispatch values, by returning RX_CONTINUE if the nhc_id
> doesn't match. Determined by nhc_id length mask and id.
>
> The rb-tree mechanism is MAYBE faster, but this depends on amount of
> registered entries. I don't think there is ever so much many nhc ids
> that a rb-tree give "huge" benefits that we should use a rb-tree now, or
> it making thinks too much complex. :-/
>
> I just stumble over rb-tree's to search a right datastructure for
> matching variable length bitfields -> "strings". Now I am not sure if
> this was a good idea to do this in that way.
>
> These rbtree's are getting also a benefits only when the nhc_id is more
> than one byte long and this also doesn't exist right now. Also the first
> byte need to have one or more subtree's. Means e.g. the first byte need
> to indicate that another bytes follows.
>
> I suppose they will add some nhc_id byte like "1111 1111" which
> indicates one byte will follows. If this will be only one byte, e.g. the
> "1111 1111" then rbtree is surely the wrong datastructure... but maybe
> they will also add some "1111 1110" which also indicates anothers
> subtree of nhc_id's. I don't know it because there is no information
> about that. Maybe iana [0] will say that with "Unassigned, reserved for
> extensions" and it should stand somewhere in RFC6282, but I don't see
> that somewhere inside of RFC6282 which describes "1111 1111". :-/
>
> They describes something about a nhc class:
>
> "(i.e., k one-bits followed by one zero-bit identify the general class
> of NHC, followed by class-specific bit assignments)."
>
> Maybe they meant something that:
>
> "1111 1111" -> BAR nhc classes
> "1111 1110" -> FOO nhc classes
> ....        -> ... nhc classes
>
> Then a rbtree _maybe_ gives some benefit but I also think it doesn't
> matter then, because it's simple not a huge amount of entries there.

The use cases for the NHC ID I have seen so far have been simple. Easy 
enough to handle with ID and mask handling like we do the dispatch value 
handling.

On the other hand we have the rb-tree logic already in place and used. 
Hard to say what future RFC's in this domain might bring and if an 
rbtree can play out it benefits.

For reserved and unassigned range we could simple registering these 
values from the core.

Right now my gut feeling is that we should leave it as is until it 
really gives us trouble.

regards
Stefan Schmidt

Re: [RFC bluetooth-next 0/4] GHC compression detection

[Alexander Aring]

On Wed, Sep 16, 2015 at 05:53:31PM +0200, Stefan Schmidt wrote:
> Hello.
> 
> On 13/09/15 15:51, Alexander Aring wrote:
> >Hi,
> >
> >On Wed, Sep 09, 2015 at 05:26:29PM +0200, Stefan Schmidt wrote:
> >>Hello.
> >>
> >>This is a first stab at RFC7400. So far we only hook into the NHC framework to
> >>detect the three registered GHC types (extension header, UDP and ICMPv6).
> >>This is aligned with how we detect the NHC frames.
> >>
> >can we add a "nhc_..." prefix to all module names? Then we have
> >something like what netfilter does with "nf_...".
> >
> 
> You mean like nhc_ghc_udp.c? Fine with me.
> 

yep. Then send patches again and it looks fine for me. Also include
bluetooth-next in cc because it's part of 6LoWPAN generic.

> >>TODO items:
> >>o How to handle reserved and unassigned ranges in the HEADER TYPE?
> >Maybe it's better to remove the current nhc_id evaluation. I did this
> >stuff with rb-tree by knowning RFC6282 only, there was the one
> >information given that "nhc id" is a variable length bitfield only. I
> >don't know how the "logic" about assign these nhc id's is, if iana has one.
> >
> >What I see when I look at [0]. Maybe we could grab the same mechanism like
> >evaluate 6lowpan dispatch values, by returning RX_CONTINUE if the nhc_id
> >doesn't match. Determined by nhc_id length mask and id.
> >
> >The rb-tree mechanism is MAYBE faster, but this depends on amount of
> >registered entries. I don't think there is ever so much many nhc ids
> >that a rb-tree give "huge" benefits that we should use a rb-tree now, or
> >it making thinks too much complex. :-/
> >
> >I just stumble over rb-tree's to search a right datastructure for
> >matching variable length bitfields -> "strings". Now I am not sure if
> >this was a good idea to do this in that way.
> >
> >These rbtree's are getting also a benefits only when the nhc_id is more
> >than one byte long and this also doesn't exist right now. Also the first
> >byte need to have one or more subtree's. Means e.g. the first byte need
> >to indicate that another bytes follows.
> >
> >I suppose they will add some nhc_id byte like "1111 1111" which
> >indicates one byte will follows. If this will be only one byte, e.g. the
> >"1111 1111" then rbtree is surely the wrong datastructure... but maybe
> >they will also add some "1111 1110" which also indicates anothers
> >subtree of nhc_id's. I don't know it because there is no information
> >about that. Maybe iana [0] will say that with "Unassigned, reserved for
> >extensions" and it should stand somewhere in RFC6282, but I don't see
> >that somewhere inside of RFC6282 which describes "1111 1111". :-/
> >
> >They describes something about a nhc class:
> >
> >"(i.e., k one-bits followed by one zero-bit identify the general class
> >of NHC, followed by class-specific bit assignments)."
> >
> >Maybe they meant something that:
> >
> >"1111 1111" -> BAR nhc classes
> >"1111 1110" -> FOO nhc classes
> >....        -> ... nhc classes
> >
> >Then a rbtree _maybe_ gives some benefit but I also think it doesn't
> >matter then, because it's simple not a huge amount of entries there.
> 
> The use cases for the NHC ID I have seen so far have been simple. Easy
> enough to handle with ID and mask handling like we do the dispatch value
> handling.
> 
> On the other hand we have the rb-tree logic already in place and used. Hard
> to say what future RFC's in this domain might bring and if an rbtree can
> play out it benefits.
> 
> For reserved and unassigned range we could simple registering these values
> from the core.
> 
> Right now my gut feeling is that we should leave it as is until it really
> gives us trouble.
> 

ok. I think issues comes when we have "really" more supports for various
compression methods.

- Alex