We have kicked off a new effort at the IETF called 6LowApp. The goal is to develop application protocols for resource-constrained embedded devices and networks. Now that 6LoWPAN and ROLL are providing a framework for wireless embedded IP networking, the next fronteir is suitable application protocols for discovery, management and data transfer.
IETF 75 (Stockholm) 6LowApp Wiki
Problem Statement Internet-Draft
Please show your support and contibute your ideas for 6LowApp. In Stockholm there will be an informal Bar BOF anyone can attend to show interest and discuss ideas, and you can always show your support on the mailing lists. Keep tuned here, as the process moves forward I’ll keep writing on our progress.
July 10, 2009 at 13:52
This is a very interesting effort. Taking into account amount of emerging WPAN standards (ZigBee, RF4CE, WirelessHART, ISA100.11a, etc.) it is necessary to provide some means of interoperability, and most likely these shall be on application level.
We are actually even thinking to launch and FP7 effort to cover issues of different WSN protocols co-existence.
August 4, 2009 at 09:15
The 6lowapp BOF was a big success, and work is starting at the IETF in this direction. A wiki page can be found here:
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
And to join the mailing list go here:
http://www.ietf.org/mailman/listinfo/6lowapp
August 10, 2009 at 23:43
Hi Zach,
why a new app protocol for 6lowpan networks? HTTP and REST paradigm is here, ready to be used. Please, take a look at an interesting work from the Web of Things guys:
http://www.webofthings.com/
Ever with some gray areas (e.g. PUSH vs. PULL architecture), the HTTP could be the right choise for application protocol in WSN. What do you think?
August 11, 2009 at 08:50
Hi!
The basic principles of the web, which include the REST paradigm are just perfect for resource-contrained devices and networks.
Many “embedded web” people are dealing with pretty powerful embedded devices and networks with reasonable payload sizes and bandwidth – there HTTP, DPWS, WS-Discovery etc. are fine. We have 60-80 bytes of payload and 10s of kbps in application throughput to work with. Combine this with limited processing power. HTTP headers alone are often too large to fit in a UDP payload, let alone the content.
In the 6lowapp effort we are encouraging the web and REST concepts, but we want to see an appropriate protocol header (a few bytes, binary, easy to parse) combined with content encoding (EXI). This is only one aspect, things like service discovery and transport protocol improvements are also on the table.
- Zach
August 13, 2009 at 00:23
Hi Zach,
I understand your concerns about using a chatty protocol like HTTP on LowPAN networks that are lossy by nature. Also I agree about the limited computation resources.
Anyway, a new application protocol could compromise one of the key factor of IP-based LowPAN that is the interoperability with the rest of the internet. The IP LowPAN nodes will only talk each other leaving the IP LowPAN edge-routers the role of protocol translators. And this will looks like a ZigBee/IP mess.
Looking at some of the current solutions:
Jennic (http://www.jennic.com) uses UDP socket interface follows the Berkeley Socket API.
WideTag (http://www.widetag.com) uses a customized XMPP extension called OpenSpime.
IBM uses their MQTT to talk with their own WebSphere Sensor Event platform.
I think no one of the above will drive the massive adoption of the Internet of Things but HTTP and REST have a chance.
My 2 cents,
Jable.
P.S. waiting for your book in November.
August 13, 2009 at 08:58
Hi Jable,
Now you hit on the key issue. There is a clear market need, and clear technical barriers to using TCP/HTTP/XML as they are on limited devices and networks (e.g. 6LoWPAN). This is exactly why we are seeing tons of proprietary solutions. And we will see many, many more.
By standardizing an embedded way of doing this, which is 100% RESTful, and can be very easily proxied into HTTP, there is a very good chance for convergence!
Using a light binary application protocol has benefits also across access networks (e.g. GPRS) and at bottlenecks near large M2M servers. For the same reasons EXI is coming into use between web-servers for XML encoding, I see a need for an embedded application protocol all the way to the M2M servers.
You are welcome to help out the 6LowApp effort at the IETF! Contibutions are welcome any time.
Cheers,
Zach
August 14, 2009 at 08:49
It would be great! How I can contribute to 6lowApp at IETF? In the past I contributed to an end-to-end network architecture for WiMAX at Siemens company.
Jable
October 1, 2009 at 11:21
hi folks! nice discussion here!
I’m totally for XMPP-like solutions, it’s powerful, functional and offers push-based eventing mechanism, which is a *must* in most WSN solutions.
I also totally agree with the limited processing/BW in embedded devices, however, I think that if you can use xmpp on devices, then why not use HTTP/rest then? xml is more verbose that http/json when it comes to large data structures. In particular, I’m thinking that even with 6lopan, we’ll always need gateways or routers (at least, to convert from ethernet ipv6 to compressed 6 lowpan). Along the same lines, I see very well a lightweight http (or any rest-oriented proprietary protocol for that matter), and the gateway could convert this lightweight http into full-blown http with all the headers and other useless info.
I’m very much for developing a embedded http which can be mapped into full http (of course the gw will add/remove most of the header info there).
Besides, even full http is possible on tmotes/sunspot, and for applications where you can accept 0,5 second instead of 0,05 seconds (typically home automation, low-throughput monitoring apps), then who cares? Especially when you look at all the advantages brought by ad-hoc http support on devices, especially when it comes to fast prototyping simple and versatile sensing apps.
Of course when it comes to industrial applications with much tougher requirements, nobody prevents you from using anything you want in your system, as it can integrate with the web of things, as long as you provide an REST/web api on your router (and your sensornet is fully proprietary).
The closer your net protocol resembles to an http, the quicker/simpler the integration with WoT will be, protocol conversion (across different programming paradigms) is tougher that just translation (from restful protocol A to restful protocol B), as it’s the same paradigm and can be easily (unambiguously) written.
Finally, I think http on ipv6 so makes sense as why ipv6 should be pushed at the device-level!
What do you think?
Look forward to continue this discussion (and to your book as well Zach
October 2, 2009 at 09:25
Vlad,
Exactly! In 6lowapp we are developing the protocol for the embedded web that works for the most constrained devices and networks (e.g. 6lowpan). I believe the base REST features of that make the web work are important. This protocol should definitely be really straight-forward to proxy with HTTP.
XMPP should definitely be useable over the new 6lowapp protocol. The idea is to support standard content-types and -encodings. You could compress the XMPP with EXI.
You should definitely join the 6lowapp@ietf.org mailing list and get involved.
Cheers,
Zach
October 21, 2009 at 20:58
Is there no hope for stock HTTP w/ EXI payloads?
Also, the XMPP crowd started an EXI encoded XEP. That was put on hold till EXI settled. I believe that time has come. EXI encoded XMPP would offer a powerful option here. Rich messaging pattens (pub/sub, rpc, etc), device aggregated health/state as presence. One concern is persistent connections and TCP.
October 22, 2009 at 09:34
Sounds interesting. EXI payloads in general, and for that matter ASN.1 payloads, BXML payloads, FI payloads etc. will all be useful with 6LowApp. A version of XMPP in EXI encoding would surely be useful as well. Although I find that to be an orthogonal problem to the application protocol itself. I am not convinced that it is feasible or even smart to try and apply HTTP to the embedded space. We already have full OASIS standards for device discovery and access using HTTP – and this is far away from where we need to get to – nor has the industry been able to apply it to the most constrained nodes and networks.
A draft about EXI encoded XEP and what requirements that requires from application and transport protocols would be useful!