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.
Implementing a light-weight SNMPv1 agent for resource constrained
devices
This document describes the approach we took for developing a light-weight SNMP
agent for resource constrained devices running 6LoWPAN/RPL protocol stack. The
motivation for the work is driven by two major factors. i)SNMP plays a vital
role in monitoring and managing any operational network; 6LoWPAN based WSN is
no exception to this. ii) There is a need for building a light-weight SNMP
agent which consumes less memory and less computational resources.
The following sections are organized as follows.
Section 1 provides the background. In Section 2 we revisit existing SNMP
implementation in the context of memory constrained devices. In Section 3, we
present our approach for building a memory efficient SNMP agent. Using a
realistic example, in Section 4, we illustrate how the proposed method can be
implemented. In Section 5 we explore few ideas which can further help in
improving the memory utilization.
1. Background
Our initial SNMP agent implementation was completely based on Net-SNMP, a
well-known public domain network monitoring and management software. After
porting the agent on to the TelosB mote, we observed that it occupies a text
program memory of more than 8KB on TinyOS and Contiki OS platforms. Note that
both these platforms already use compiler optimizations to minimize the memory
footprint. To start with, 8KB is non-negligible considering the 48KB program
memory limit of TelosB. Added to this, the memory taken up by 6LoWPAN and the
related protocol stacks are ever growing causing serious memory crunch in the
resource constrained devices. We reached a situation where we could not build
an image on the TinyOS/Contiki OS platforms with our SNMP agent.
We came across SNMPv1 agent implementations elsewhere in the literature which
also report similar memory consumption. This motivated us to have a re-look at
the existing SNMP agent implementation, and explore the possibility of an
alternate implementation using altogether a different approach.
2. Revisiting SNMP implementation for resource constrained devices
If we look at a typical SNMP agent implementation, we can see that memory
consuming code is mainly due to the operations pertaining to ASN.1 related snmp
pdu parsing and snmp pdu build operations. At the gross level, the snmp parsing
involves recovering various fields from the incoming PDU, and prominently, the
OIDs. Whereas the snmp pdu build involves doing the reverse operation of
building the response PDU from the OIDs.
The key observation we make is that, for a given MIB definition, an OID of
interest contained in the incoming SNMP pdu is already available, albeit in
an encoded form. This observation gives raise to a possibility of identifying
the
OID from the packet in its "raw" form, thus enabling us to come up with simpler
parsing operation.
We can similarly extend the above observation while building response SNMP pdu
too.
For a given MIB definition, we can think of statically having a pre-composed
ASN.1
encoded version of OIDs, and use them while constructing the response SNMP pdu.
3. Proposed approach for building an memory efficient SNMP agent
As noted in the previous section, since an SNMP OID is already *contained* in
the incoming network PDU, we came up with a simple a simple OID signature
identification method performed directly on the network PDU through simple
memory comparisons and table look-ups. Once the OID has been identified from the
packet "in situ", the corresponding per-OID processing is carried out. Through
this scheme we completely eliminated expensive SNMP parse operations.
We have extended the above idea for SNMP PDU build part too by using an already
*pre-encoded* OID variables which can simply be plugged into the network SNMP
response packet directly depending on the request OID. Now that the expensive
build operation is taken care, what remains is the construction of the overall
SNMP pdu which can be built through simple logic. Through this scheme we
completely eliminated expensive SNMP build operations.
Based on these ideas, we have re-architected our original SNMP agent
implementation and with our new implementation we were able to bring down its
text memory usage all the way up to 4KB from the native SNMP agent
implementation which occupied 8KB.
3.1 Discussion on memory usage
With respect to the memory usage, while we have achieved major reduction in
terms of text program memory, which occupies a major chunk of memory, a
question might come to mind with regard to the static memory allocation for
maintaining the tables. We found that this is not very significant to start
with. Through an efficient table representation, we further optimized the
memory consumption. We could do so because a typical OID description is mainly
dominated by a fixed part of the hierarchy. This enables us to define few
static prefixes each corresponding to a particular hierarchy level of the OID.
In the context of 6LoWPAN based WSNs, it is reasonable to expect that the
number of hierarchy levels will not be too many.
4. Example
In this section we take an example to illustrate the simplicity and
practicality of our approach.
Let us consider the following fragment of a representative MIB definition.
iso
|
org
|
dod
|
internet
|
mgmt.mib-2
|
lowpanMIB
|
+--lowpanPrimaryStatistics(10)
|
+--PrimeStatsEntry(1)
|
+-- -R-- INTEGER lowpanMoteBatteryVoltageP(1)
+-- -R-- Counter lowpanFramesReceivedP(2)
+-- -R-- Counter lowpanFramesSentP(3)
+-- -R-- Counter ipv6ForwardedMsgP(4)
+-- -R-- Counter OUTSolicitationP(5)
+-- -R-- Counter OUTAdvertisementP(6)
4.1 Optimized SNMP Parsing
Let us consider a GET request for the OIDs lowpanMoteBatteryVoltageP and
lowpanFramesSentP. Corresponding to these OIDs, a C array dump of the network
PDU of SNMP packet with two OIDs in a variable binding would look as below.
char snmp_get_req_pkt[] = {
0x30, 0x81, 0x3d, 0x02, 0x01, 0x00, 0x04, 0x06,
0x70, 0x75, 0x62, 0x6c, 0x69, 0x63, 0xa0, 0x30,
0x02, 0x04, 0x28, 0x29, 0xe4, 0x5d, 0x02, 0x01,
0x00, 0x02, 0x01, 0x00, 0x30, 0x22, 0x30, 0x0f,
0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83,
0x90, 0x12, 0x0a, 0x01, 0x01, 0x05, 0x00, 0x30,
0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01,
0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00 };
Inspecting the above packet, we see that the main components of the PDU are
i) Version (SNMPv1) : [0x02, 0x01, 0x00]
ii) Community Name ("public") : [0x04, 0x06,0x70, 0x75, 0x62, 0x6c, 0x69,
0x63]
iii) ASN.1 encoded OIDs for lowpanMoteBatteryVoltageP, and
lowpanFramesReceivedP :
-- [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 0x90,
0x12,
0x0a, 0x01, 0x01,
0x05, 0x00]
-- [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 0x90,
0x12,
0x0a, 0x01, 0x03,
0x05, 0x00]
As we can see from iii), there is a significant overlap between the two OIDs,
which automatically simplifies the parsing process. We can, for instance,
define one statically initialized array containing elements common between
these OIDs. Using this notion of common prefix idea, we can come up with an
optimized table and the OID identification then boils down to simple memory
comparisons within this table. The optimized table construction will also
result in scalability.
4.2 Optimized SNMP Build
Extending the same approach as described above, we can build the GET response
by plugging in pre-encoded OIDs into the response packets. So, corresponding to
the GET request for the OIDs as given in section 4.1, we can define C arrays
containing pre-encoded OIDs which can go into the response packet as below.
pdu_batt_volt[] = {
0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02,
0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x01, 0x02,
0x02, 0x00, 0x00 };
pdu_frames_sent[] = {
0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02,
0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x41,
0x02, 0x00, 0x00 };
Since the ASN.1 syntax is in TLV format, the offset within the encoded OID
where the value needs to be filled-in can be got from the length field.
The table size optimization which was discussed in the previous section can also
be applied here too.
4.3 Remark
Though we have taken a simple example to illustrate the efficacy of the
proposed approach, the ideas presented here can easily be extended to other
scenarios as well.
5. Improving it further
We mention few simple methods to reduce the code size as well as generate
computationally inexpensive code. These methods might sound obvious and trivial
but important for the resource constrained devices.
i) As much as possible avoid using memory consuming data types such as float
while representing a monitored variable when an equivalent representation of
the same which occupies less memory is adequate. For example, while a
battery
voltage could take fractional value between 0 and 3V, opt for an 8-bit
quantized value.
ii) Using meta data in the MIB definition instead of absolute numbers can bring
down the memory and processing significantly and can improve scalability too
especially for a large scale WSN deployments. Using the same example of
battery
voltage, one might think of an OID which represents fewer levels of the
battery voltage signifying high, medium, low, very low.
iii) While multi-level hierarchy for MIB definition might improve OID
segregation
the flip side is that it increases the overall length of the OID and result
in the extra memory and processing overhead. One may have to make a
judicious
choice while coming up with the MIB.
iv) ...
6. Conclusion
This document proposes a simple SNMP packet processing based approach for
building a light-weight SNMP agent. While there is a scope for further
improvement, we are of the view that the the proposed method in this document
can be a reasonably good starting point in the context of managing a
resource constrained 6LoWPAN based network._______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
