Brian Frank a écrit :
On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann <[email protected]
<mailto:[email protected]>> wrote:
On Jun 11, 2009, at 03:15, Brian Frank wrote:
However, I am not sure SNMP is the best starting point.
Here are my thoughts on this issue...
6LoWPAN's tremendous potential is to displace the zillions of closed,
proprietary, and non-IP "standards" based protocols used for smart
devices. As such the key problem is not network management per se,
but easy access to the information in these devices (which is
typically sensor data).
There are a couple reasons that I think SNMP falls short for
unlocking the information trapped in smart devices:
- SNMP may be commonly used by this group of engineers, but it isn't
something used very often by most software developers in their daily
jobs
- The information model for SNMP is predefined based on MIBs which is
a fairly limited type system for modeling information.
- SNMPs basic model seems ill suited to battery powered devices which
spent most of their life sleeping
Some deployed SNMP-like databases do have currently parameters related
to power consumption, at least.
What I consider the best starting point is HTTP.
I agree it's worth considering seriously.
But one point: the main HTTP semantics (unicast GET/POST/PUT) wouldn't
fit a single-multicast request multiple-unicast response semantics, used
for example when querying a set of sensors. I am not sure how you see it...
Let's assume for a second that a gateway can compress HTTP into a
suitable binary format inside UDP packets (which I believe is quite
possible). What advantages does HTTP have?
- HTTP is by far the most popular protocol on the planet, immediately
familiar to just about any software developer, and with rich APIs
included in just about any programming language's toolbox
Neither the C Library nor the C++ Standard Template Library include http
calls... not sure what you mean. Do you mean Java and family?
- HTTP is the protocol of the web which makes it *the* protocol for
sharing information. If a piece of data is going to be published on
the web, then it should have a URL. The amazing potential of 6LoWPAN
is that every sensor on the planet can be given a URL.
A URL yes, but an http server on a sensor?
- HTTP has a sophisticated, well-known, and widely used model for
caching information. It is my belief that caching is the best
solution for dealing with sleeping nodes, by having powered nodes
serve as their HTTP caches.
- HTTP doesn't prescribe any specific information model, rather it
enables transport of any MIME encoded data. As an opened ended
transport layer, it enables continual evolution and innovation in how
information is modeled.
Does HTTP work with multicast addresses?
Defining an application layer protocol which works well over 6LoWPAN
is a topic near and dear to my heart. Currently, the lack of one is
a real thorn in our side to actually deploying 6LoWPAN into the real
world. Until their is an IETF application protocol that runs well
over 6LoWPAN, I think adoption will continue to be stifled.
If there is interest, I would be glad to post a draft to start some
discussions around the idea of using compressed HTTP over 6LoWPANs.
Let's see let's see, sounds interesting.
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
