The motivation for our work comes from the following reasons. - Remote monitoring and managing an operational network from anywhere is essential in general. The monitoring and managibility becomes indispensable especially in the context of WSNs, as we all know the unpredictable nature of such networks. Don't we keep hearing people saying, "We know it all works well in the lab, but have you tried it on the field ?"
- With the advent of industry backed buzz on "Internet of Things"/"Cyber physical systems", we expect "serious" and large scale real-world deployments of such systems in near future. In such scenarios, we can certainly expect operators of such networks inevitably requiring monitoring and management support. - People from industries who visit our lab, and are in the process of deploying WSNs specifically ask for i) Ease of deployability ii) Configurability and iii) Monitoring and managebility. It is not surprising that, of late, we get to hear the term "Managed Networks". - Once we see the essentiality of a monitoring and management system, open and ubiquitous SNMP becomes a natural choice. In our work we address the concerns that arise with regard to memory and computational aspects of SNMP. One can use various SNMP commands for SET'ing parameters of interest, setting TRAPs based on thresolds, and so forth, apart from the usual GET commands. Given the importance of an NMS, in our work we are also addressing issues like i) When to schedule monitoring activity so that application performance is not hampered ii) How often to schedule such an activity so that minimal resources are consumed by the network iii) How to choose between push and pull modes of SNMP operation iv) Can we aggregate the information within the network v) How to use caching techniques, and so forth. Though lengthy, hope I answered your doubts :) Zhen : Would you add more to what I mentioned above ? Hi Brinda, Hi Zhen, > > I have a really simple and basic question. > > I would be interested to hear what architecture you had in mind with your > work. > > Do you expect SNMP to be used with end devices for setting configuration > parameters or is the main use case more for constrained wireless routers > (which may run RPL)? > > Ciao > Hannes > > On Jan 3, 2012, at 4:08 PM, Brinda M. C wrote: > >> Hi Zhen, >> >> Wish you a very happy new year 2012! >> >> Based on our work on building a light-weight SNMP agent (uSNMP), I came >> up >> with >> a short write-up on the approach and implementation. Based on the >> content >> and your >> initial feedback, I would like to submit an individual draft soon. >> >> I am pleased to inform that uSNMP has been successfully incorporated on >> both TinyOS/BLIP stack and Contiki OS for TelosB motes. I plan to >> release >> uSNMP on public domain. >> >> Thanks >> >> Regards >> Brinda >> >> >> >> >> >> >> Hi Brinda, >>> >>> Thank you for the information. See my reply inline. >>> >>> On Wed, Dec 21, 2011 at 10:26 PM, Brinda M. C >>> <[email protected]> >>> wrote: >>>> Hello, >>>> >>>> As part of a project on building a network monitoring and management >>>> based >>>> on SNMP for 6LoWPAN/RPL WSNs, we have developed a light-weight SNMPv1 >>>> agent >>>> which, according to our knowledge, occupies far less text program >>>> memory >>>> than the existing implementations. Our implementation occupies a >>>> memory >>>> footprint of just 4KB of text program memory on TelosB motes. Our >>>> performance test results showed that our implementation also brings >>>> down >>>> computational overheads substantially. >>>> >>>> We tested our SNMPv1 agent implementation on both TinyOS-2.x and >>>> Contiki >>>> OS >>>> running 6LoWPAN/RPL protocol stack. >>> >>> We also encountered this issue on the mote. Given the fact of the >>> existing protocol stacks, have you managed to fix both your uSNMP >>> codes and the existing BLIP inside of the node? >>> >>>> >>>> The motivation for our work comes from the fact that the memory >>>> footprint of >>>> 6LoWPAN/RPL and the related protocols is ever increasing and and our >>>> belief >>>> that there is a need to optimize our implementation so that we should >>>> be >>>> able to monitor any operational network comprising of resource >>>> constrained >>>> devices with limited memory. >>> >>> Limited resource will hurt all applications including SNMP. SO >>> basically I think the optimization of the existing codes is also >>> important to make the world a better one :) >>> >>>> >>>> I would be more than happy to share the approach we followed while >>>> building >>>> our light weight SNMPv1 (we call it uSNMP) and provide a generic >>>> guidelines >>>> to those who want to realise the same using their own implementation >>>> methods. You are welcome to contact me for the source code as your >>>> feedback >>>> will be very useful. >>> >>> Thank you. Could you hack an Individual Draft on the topic to >>> describe what kind of problems you had met and conquered? I think >>> that's a better way of communication. >>> >>>> >>>> In this context, I would like to know if we can submit a document >>>> based >>>> on >>>> our work to the lwip charter so that it can be included in an >>>> appropriate >>>> Internet draft. >>> >>> Sure. You are very welcome! >>> >>>> >>>> Regards >>>> Brinda >>>> >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>>> _______________________________________________ >>>> Lwip mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lwip >>> >>> >>> >>> -- >>> Best regards, >>> Zhen >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> <light-weight-snmp-agent.txt>_______________________________________________ >> Lwip mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lwip > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
