On Thu, Jun 11, 2009 at 8:07 PM, Brian Frank<[email protected]> wrote: > > > 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.
The predefinition of data is required for standardizing the information that has to be retrieved. However, application specific MIBs can always be defined and used. > - 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? same can be done with SNMP packets :). > - 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. Enabling HTTP on the nodes would really be a nice contribution. However, I dont agree with using that for management. Reusability of the tools that are already available for management, monitoring, and configuration of IP networks is also something that we cannot neglect. Moreover, SNMP is datagram oriented and also pretty lightweight if it is coded well - it may fit 6LowPAN applications pretty well. > - 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. Catching in SNMP may be achieved by AgentX (a subagent protocol). Currently AgentX is based on TCP, however it can be modified to be used over UDP to fit the 6LoWPAN requirements. > - 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 > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
