Hi Brinda, 

thanks for the response. I certainly understand the need to manage networks and 
devices. 

I was curious where the resource constraints come from that motivate the 
requirements for lightweight implementations. For example, some folks claim 
that memory is cheap and energy is the real constraint. Others argue 
differently.  So, what should be the focus of our optimization efforts?

I was also wondering how the reachability mechanisms work (given that the 
devices are likely to change their addresses regularly) and how does SNMP (or 
other configuration protocols) relate to a more generic software update 
mechanism? You are very likely interested in not only configuring some 
parameters on a wireless sensor node but the rest of the software as well. Do 
we have a story for that as well? 

Ciao
Hannes

On Jan 4, 2012, at 1:40 PM, Brinda M. C wrote:

> Hi Hannes,
> 
> 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 indispensible
> 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 ?
> 
> 
> Regards,
> Brinda
> 
> 
> 
> 
> 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
>>>> <bri...@ece.iisc.ernet.in>
>>>> 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
>>>>> Lwip@ietf.org
>>>>> 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
>>> Lwip@ietf.org
>>> 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
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Reply via email to