On Wed, Nov 18, 2009 at 10:10:23PM +0100, Ulrich Herberg wrote: [... we should restrict this to one mailing list...]
> However, it is unclear whether the code footprint of SNMP > implementations can fit into the memory of small devices. From > discussions with several persons from the MANET WG, I conclude that > for MANET the same problem exists. (and I think for ROLL, too?) > > I have several questions that came to my mind about this topic: > > - First of all, to which WG does this issue belong to? Or is it -- as > I suppose -- a common problem for the three working groups addressed > in this mail? I don't know. > - Is this really an issue? Are there implementations of SNMP (maybe > not open-source) that can be run on very small devices such as > considered in 6lowpan/ROLL/MANET? Is there any experimental (or > theoretical) analysis whether SNMP (or any other standardized > management protocol) can run on these devices? The question is under specified. What is a "very small device" and how much can a "very small device" devote to SNMP? And what is SNMP? The SNMPv3 specs are pretty modular. One of the more important questions is how you deal with security - the security code has the potential to be bigger than the rest of the SNMP engine. And it boils down to the question of how many MIB objects you support and to what extend you hardwire things. Remember that SNMP is a child of the late 80s and early versions were sometimes embedded into devices that could not afford TCP. Of course, the 80s version of SNMP did not care much about security... > - If SNMP cannot be used for small devices, how can we manage and > monitor these devices then? (e.g. using proxies, different message > formats such as proposed in 6lowapp, etc.). Do we need a different > lightweight protocol for management? Again, the big question is how to deal with the security aspect. SNMP originally was lightweight because there was no security. It took the IETF many years to find a workable security solution and even today people are working on utilizing transport layer security protocols within SNMP (see ISMS working group). > - Can we provide SNMP not only on a single device, but for a whole > network? That might need an aggregator device that runs full SNMP and > collects the data from the low power devices. This would imply to > monitor statistics of a whole network (e.g. number of links, average > throughput, average path-length, etc.) Sure, there are ways of doing this. For read-only objects, this is relatively easy - it can get a bit messy if you have read-write objects. Whether this direction is worthwhile to explore depends on how you solve the security issues and whether a dependency on a "gateway" is desirable in the first place. > - What kind of objects should be provided in a MIB running on a > MANET/6lowpan/ROLL device? This might be specific to the routing > protocol, but there can be commonalities. In general, the IETF tends to break MIB modules down along protocol functions. Following this approach, a ROLL MIB module would report data about the ROLL routing protocol. A 6LoWPAN MIB would report data about the 6LoWPAN layer, that is for example the list of supported 6LoWPAN protocol features and counters for 6LoWPAN processing failures (e.g. reassembly failures) that help to trouble shoot 6LoWPAN issues. I would hope that some IPv6 MIB objects apply as well and then there should ideally be an IEEE 802.15.4 MIB module for this particular radio technology. I do not think there is much overlap if things get structured well. This, however, might be difficult to achieve if work is spread over several WGs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
