Subject: Re: [Lwip] Light-weight SNMP agent

From: "Brinda M. C" <[email-masked]>
Date: Tue, 3 Jan 2012 19:38:56 +0530

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-masked]>
> 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-masked]
>> 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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jan 2012 17:30:24 +0200

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:

> <light-weight-snmp-agent.txt>_______________________________________________
> Lwip mailing list
> [email-masked]

---

From: "Brinda M. C" <[email-masked]>
Date: Wed, 4 Jan 2012 17:04:58 +0530

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,
> 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
>

---

From: "Brinda M. C" <[email-masked]>
Date: Wed, 4 Jan 2012 17:10:24 +0530

Hi Hannes,

- 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.

Regards,
Brinda

Hi Brinda, Hi Zhen,

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 4 Jan 2012 15:12:17 +0200

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

---

From: Zhen Cao <[email-masked]>
Date: Thu, 5 Jan 2012 15:14:06 +0800

> 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 cons…

Brinda said that on his node, only 4KB text program memory is
available. And I have one similar node that has only 10KB.  That's the
real problem we met.

For the claim, energy consumption is mainly incurred by communication,
that's protocol semantic, and implementation does not have much way to
optimize.  So protocol designers optimize their protocols (that's on
the way), and implementers optimized the codes, in parallel.

Thanks,
Zhen

---

From: "Brinda M. C" <[email-masked]>
Date: Thu, 5 Jan 2012 19:19:59 +0530

Hi Hannes,

I agree with Zhen. While incorporating SNMP on the TelosB motes we struggled
for every byte of memory in every stage. Out of the 48KB of program memory
available MSP430 micro-controller based TelosB, a hugely popular platform,
hardly 4-5KB was available for the user programs on Contiki. The rest is
taken by the OS, 6LoWPAN/RPL stack. Our experience is also echoed by a
group in Inria in their paper "Deployment Experience with Low Power Lossy
Wireless
Sensor Networks" published in  IAB Workshop on Interconnecting Smart Objects
with the Internet, 2011.

Texas Instruments' recent ultra-lowpower micro-controller has little more
than 100KB program memory which is certainly more than TelosB motes. But
this doesn't mean that we will have enough memory to just use it because
of the ever growing functionality that is being stuffed into the mote such
as COAP, HTTP, TCP, security, WSN application itself, time
synchronization, and so on.

Thus, any light-weight design and development of IP protocols is invaluable.

Regards
Brinda

>> 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?
>