On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann <[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 What I consider the best starting point is HTTP. 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 - 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. - 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. 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. Brian
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
