6lowpan/ROLL support on 802.15.4 radios - Revision history

Tim Bird: /* Comments */ fix comment blocks

2011-01-07T00:38:02Z

‎Comments: fix comment blocks

Tim Bird: add comments between Jon Smirl and Stefan Schmidt

2011-01-07T00:36:50Z

add comments between Jon Smirl and Stefan Schmidt

Tim Bird: add page for proposal

2011-01-07T00:31:00Z

add page for proposal

New page

; Summary: 6lowpan/ROLL support on 802.15.4 radios

; Proposer: Jon Smirl

== Description ==
802.15.4 is the radio layer of Zigbee. Zigbee is being deployed in
smart meters all over the world with most of the activity in
California. The next generation of Zigbee is being converted to run on
TCP/IP instead of the proprietary Zigbee protocol. TCP/IP over
802.15.4 is the subject of two IEFT working groups - 6lowpan and ROLL.
6lowpan and ROLL are targeted to be GPL compatible unlike the
exisiting proprietary Zigbee protocol. COAP is the application layer
protocol used on top of 6lowpan/ROLL.

I'd like to buy a wireless router incorporating wifi and 802.15.4 but
they don't exist yet. That's probably because there is no 802.15.4
support in Linux yet. I've been playing with writing this code in my
spare time but I'm not making much progress. Proposal is for
6lowpan/ROLL to be implemented in the kernel. A user space library
would implement COAP.

Primary beneficiary of this work is the Linux based router
manufactuers - Linksys, DLink, Netgear, Buffalo, Trendnet, Asus,
Belkin, Cisco, etc... Once the code is in the kernel is becomes simple
to produce a router that bridges from Ethernet to wifi to 802.15.4.

RF4CE is 802.15.4 based remote controls. Once the ground work for
802.15.4 support is laid it should be possible to support these
devices. Target for this is set top boxes.

This is not a proposal to implement the existing Zigbee protocols.
Zigbee licensing is GPL incompatible. The Zigbee Alliance board has
been asked to fix their GPL compatibility issues in the same manner
that Bluetooth fixed them, but the Zigbee board declined to make the
changes.

== Related work ==
Linux Zigbee project - http://sourceforge.net/apps/trac/linux-zigbee/
6lowpan at IETF - http://datatracker.ietf.org/wg/6lowpan/charter/
ROLL at IETF - https://datatracker.ietf.org/wg/roll/charter/
COAP at IETF - https://datatracker.ietf.org/doc/draft-ietf-core-coap/
GE Nucleus - http://www.geappliances.com/home-energy-manager/power-usage-monitor.htm
Redwire hacker site - http://mc1322x.devl.org

== Scope ==
My estimate is 26 person weeks for the initial implementation and
testing. Another 13 person weeks (half-time) to support CELF members
who incorporate the code. Possible need for travel budget to go to
IETF meetings. This is too big for a spare time project.

== Contractor Candidates ==
Redwire LLC - http://www.redwirellc.com

== Comments ==

[[Category:Project proposals 2011]]

@@ Line 71: / Line 71: @@
   implementations using this code.  They're in user space because of the
   GPL incompatibility of Zigbee.
-−
   The linux-zigbee project was started by Siemens as a in-kernel implementation of
   Zigbee. When they discovered the GPL incompatibility the switched to
@@ Line 77: / Line 77: @@
   this? I suspect they have because Dmitry complained which I tried to
   change the interface to user space.
-−
   Maybe the Linux Foundation could convince the Zigbee board to fix
   their licensing. Bluetooth originally had the identical problem. The
@@ Line 87: / Line 87: @@
   the Zigbee name and logos. I suspect the companies selling Zigbee
   stacks were behind blocking this switch.
   > 1) Does this proposal also cover the task of bringing the outstanding mac802154
@@ Line 101: / Line 102: @@
   know of five half finished projects building Linux support for
 lowpan/ROLL. None of them are close to be production ready.
-−
   > 2) Would the code be based on the contiki 6lowpan implementation or would it be
   > a fresh start?
@@ Line 110: / Line 111: @@
   advise us on how to correctly hook into the existing TCP/IP stack;
   snitching the BSD licensed code from Contiki is the easy part.
-−
   BTW, the Contiki 6lowpan/ROLL implementation is only about 80% there -
   a lot of the hard bits are missing. For example no one has implemented
   a line of link level security code.
-−
   > Especially 1 seems to be a dependency if the 6lowpan code would be targeted for
   > mainline. I worked on the ieee802154 linux stack and drivers and will do it
@@ Line 129: / Line 130: @@
   firms than are better suited to do the work but they are selling
   Zigbee implementations.
-−
   One mystery to me is why no one from the router manufacturers is
   working on this. Cisco is quite active in the 6lowpan/ROLL IETF group.

← Older revision		Revision as of 00:36, 7 January 2011
Line 53:		Line 53:

	== Comments ==		== Comments ==
		+	Just to make it clear. There is ieee 802.15.4 support in linux. One part of it
		+	is already in mainline: net/ieee802154 but the MAC layer part is still missing
		+	and only available in the linux-zigbee git repository together with several
		+	drivers based on it. I would not say the code is production quality but at least
		+	reasonable to work with.
		+
		+	This covers only 802.15.4. In terms of Zigbee this are only the two lowest
		+	layers and everything Zigbee specific is missing due to the reasons you already
		+	listed. So the project name, zigbee-linux, is a bit misleading at best as it
		+	only covers IEEE 802.15.4 :)
		+	Stefan Schmidt
		+
		+	The 802.15.4 part that is already in the kernel is from the
		+	linux-zigbee project referenced in the original post. That's just
		+	enough code to get the packets out of the hardware and push them up to
		+	user space. I suspect there are private user space ZIgbee
		+	implementations using this code. They're in user space because of the
		+	GPL incompatibility of Zigbee.
		+
		+	The linux-zigbee project was started by Siemens as a in-kernel implementation of
		+	Zigbee. When they discovered the GPL incompatibility the switched to
		+	MAC only. Have they built a private Zigbee implementation on top of
		+	this? I suspect they have because Dmitry complained which I tried to
		+	change the interface to user space.
		+
		+	Maybe the Linux Foundation could convince the Zigbee board to fix
		+	their licensing. Bluetooth originally had the identical problem. The
		+	Zigbee license requires all developers to pay $3000/yr. Putting the
		+	Zigbee code into the kernel would subject all kernel developers to
		+	this $3000/yr requirement plus the GPL doesn't allow that. Bluetooth
		+	had a fee like this originally and then later dropped it. The GPL
		+	compatible way of doing this is to put the fee on use of the brand -
		+	the Zigbee name and logos. I suspect the companies selling Zigbee
		+	stacks were behind blocking this switch.
		+
		+	> 1) Does this proposal also cover the task of bringing the outstanding mac802154
		+	> bits into mainline? They are needed for a lot of drivers and interaction with
		+	> the 6lowpan stack.
		+	I just made a first attempt at the proposal. If it is under serious
		+	consideration it needs to be fleshed out a lot more. Yes, it would
		+	make sense to include the MAC support.
		+
		+	Another missing part is interoperability testing. That may require
		+	some travel (IETF plugfest) and equipment purchases.
		+
		+	Obviously the top requirement is to get the code into the kernel. I
		+	know of five half finished projects building Linux support for
		+	6lowpan/ROLL. None of them are close to be production ready.
		+
		+	> 2) Would the code be based on the contiki 6lowpan implementation or would it be
		+	> a fresh start?
		+	In my effort I started from the Contiki code. It is not a straight
		+	port, the Linux networking architecture is very different than
		+	Contiki's. I got halfway into it and figured out that I had made
		+	design mistakes in the architecture. One of the network gurus needs to
		+	advise us on how to correctly hook into the existing TCP/IP stack;
		+	snitching the BSD licensed code from Contiki is the easy part.
		+
		+	BTW, the Contiki 6lowpan/ROLL implementation is only about 80% there -
		+	a lot of the hard bits are missing. For example no one has implemented
		+	a line of link level security code.
		+
		+	> Especially 1 seems to be a dependency if the 6lowpan code would be targeted for
		+	> mainline. I worked on the ieee802154 linux stack and drivers and will do it
		+	> again next year. While Dmitry does a good job in keeping the linux-zigbee tree
		+	> up to date wrt mainline it is still somewhat frustrating to work against it
		+	> instead of mainline where all the other stuff lands.
		+	>
		+	> I don't want to open up a can or worms here with these questions just want to
		+	> get a better understanding what this proposal would cover.
		+	I proposed Redwire as a contractor since they are actively developing
		+	the ROLL support for Contiki. They are primarily familiar with
		+	6lowpan/ROLL and less familiar with the kernel. One the plus side they
		+	are reasonably priced and should be available. There are several other
		+	firms than are better suited to do the work but they are selling
		+	Zigbee implementations.
		+
		+	One mystery to me is why no one from the router manufacturers is
		+	working on this. Cisco is quite active in the 6lowpan/ROLL IETF group.
		+	Jon Smirl


	[[Category:Project proposals 2011]]		[[Category:Project proposals 2011]]