SNMP optimizations for 6LoWPAN
draft-hamid-6lowpan-snmp-optimizations-00.txt

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 5, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This draft proposes SNMPv3 optimizations for its use in 6LoWPANs. The draft presents optimization goals, issues, and the optimization approaches to enable the use of SNMP under the given memory, processing, and message size constraints imposed by 6LoWPANs.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  Management Requirements and design goals
3.  Deployment models
    3.1.  Lightweight End-to-End
    3.2.  Proxy Model
    3.3.  SNMP with Sub-Agent Protocols
4.  Optimization Goals
    4.1.  Reduction of Packet size
        4.1.1.  Header size reduction
        4.1.2.  Payload size reduction
    4.2.  Reduction of Memory cost
        4.2.1.  Light-weight and Distributed Agent Functionality
        4.2.2.  Reassembly on 6LoWPAN node
        4.2.3.  Minimal MIB support
    4.3.  Manager Considerations
    4.4.  Lightweight Protocol Operation
        4.4.1.  EngineID discovery
        4.4.2.  Security
        4.4.3.  Access control
5.  Conclusion
6.  IANA Consideration
7.  Security Considerations
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informative References

1.  Introduction

On one hand, 6LoWPANs are IPv6 networks; while on the other hand, these are sensor networks that comprise a large number of nodes with extremely limited resources. The management solutions for traditional IP networks cannot be applied directly to 6LoWPANs because of the resource constraints of the former. Likewise, the applications, while designed for traditional networks have preferences in terms of performance and response time as compared to the energy, transmission power, memory, and processing power considerations for sensor networks. The management of 6LoWPANs involves catering for the management needs for the networks of hundreds or thousands of nodes which are relatively unreliable in terms of connectivity yet must also support IPv6 addressing, including its dynamic assignment and usage. This seemingly paradoxical situation demands for light-weight management architectures that are savvy of the constraints and thorough in purview.

According to [RFC4919] (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.) network management is one of the goals for 6LoWPANs, wherein it is described that network management functionality is critical for 6LoWPANs. An intuitive approach is to use Simple Network Management Protocol (SNMP) [RFC3410] (Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” December 2002.) that is widely used for management and monitoring of IP networks. However, due to the aforementioned constraints, an investigation is required to determine the usability of the latest version of SNMP, specifically SNMPv3, or an appropriate adaptation of it.

This draft would investigate the feasibility of the usage of SNMPv3 in 6LoWPANs and propounds optimizations in SNMPv3 for its use in 6LoWPANs. It covers management requirements and goals, followed by the proposed optimizations for the reduced packet size and the memory cost. The initial version of the draft covers the goals of SNMP optimizations and the optimization issues. Additional aspects would be discussed in the later versions of the draft.

2.  Management Requirements and design goals

6LoWPAN management needs to meet the resource constraints and ensure a minimalist configuration change while providing inasmuch management information as needed for self-healing by the network. The utilization of SNMPv3 in these networks would enable the reuse existing management tools.

Reusability: The management goal of 6LoWPAN is to re-use the existing established network management tools. The underlying IP network enables the use of those tools if the resource constraints of the network are taken care of.

Minimum overhead: The network management framework should have a limited overhead both in terms of communication and computation.

3.  Deployment models

Different schemes may be supported on the 6LoWPANs to deploy and support SNMP. We need to examine if lightweight end-to-end (E2E) or SNMP proxy or a subagent protocol can enable the efficient use of SNMP in 6LoWPANs.

There can be three fundamental deployment models for SNMPv3

3.1.  Lightweight End-to-End

The SNMP manager talks SNMPv3 end-to-end to the nodes. In this way existing management tools can be reused and a few adaptations may be needed by specifying suitable deployment parameters through an Applicability Statement. In this case seamless packet header encoding schemes for SNMPv3, analogous to the IPv6 packet header encoding schemes for 6LoWPAN, may also be deployed at the 6LoWPAN gateway.

Manager <-------------------------------------> 6LoWPAN nodes
                       SNMPv3

3.2.  Proxy Model

The SNMP manager communicates to an SNMP proxy residing on the 6LoWPAN Gateway (or a proxy server), which is able to adapt encoding formats or use compression in order to reduce message overhead. Existing management tools (as long as they are proxy aware, which is not generally true) can be reused while being able to reduce message size overhead on the 6LoWPAN network. In this model, 6LoWPAN adaptation layer may not be strictly needed since SNMP can run over directly over IEEE 802 networks [RFC4789] (Schoenwaelder, J. and T. Jeffree, “Simple Network Management Protocol (SNMP) over IEEE 802 Networks,” November 2006.).

Manager <-------->    SNMP Proxy   <--------------> 6LoWPAN nodes
          SNMPv3  (6LoWPAN Gateway)     SNMPv3

3.3.  SNMP with Sub-Agent Protocols

The SNMP manager talks SNMPv3 to an extensible SNMP agent residing on the 6LoWPAN router which uses a subagent protocol (e.g. a 6LoWPAN enhanced version of AgentX, [RFC2741] (Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, “Agent Extensibility (AgentX) Protocol Version 1,” January 2000.)) to populate its MIB. In this scenario, 6LoWPAN adaptation layer may not actually be needed since such subagent protocol can run directly over 802.15.4. However, the current standard subagent protocol is not suitable for 6LoWPAN since it assumes a reliable stream-oriented transport and an adaptation of an existing protocol may be required.

Manager <------->   SNMP Agent    <-----------------> 6LoWPAN nodes
          SNMPv3 (6LoWPAN Gateway) SubAgent Protocol

4.  Optimization Goals

Based on the characteristics of 6LoWPANs, following sections explain the main goals of optimization to enable a smooth and effective usage of SNMPv3 in 6LoWPAN.

4.1.  Reduction of Packet size

SNMPv3 packets may be large in size due to their variable length. The message size should to be reduced in order to efficiently utilize the link bandwidth. Extra fragmentation of the management packets may also be needed to be avoided. [RFC3417] (Presuhn, R., “Transport Mappings for the Simple Network Management Protocol (SNMP),” December 2002.) for transport mappings of SNMP messages states that an SNMP entity must be capable to accept messages up to and including 484 octets in size. Hence SNMPv3 packets cannot be carried into a single 6LoWPAN payload and fragmentation/reassembly may be required. [RFC4919] (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.) states that adding all layers for IP connectivity should still allow transmission in one frame, without incurring excessive fragmentation and reassembly. It further states that protocols must be designed or chosen so that the individual "control/protocol packets" fit within a single 802.15.4 frame. Therefore, Header and payload compression techniques may be considered in order to accomplish this.

The Maximum transmission unit (MTU) for 6LoWPANs is 127 bytes [RFC4919] (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.). In the worst case UDP can carry 33 octets of data over it. In the best case, about 86 bytes can be carried over UDP with 6LoWPAN_HC1 IPv6 header encoding and HC_UDP transport header encodings with AES-CCM-32 for Link-layer security.

Moreover, it needs to be analyzed if Basic Encoding Rules (BER) for binary encoding of Abstract Syntax Notation (ASN.1) into Tag, Length, and Value (TLV) pairs can work in 6LoWPAN with minimal functionality. As an alternative, a seamless appropriate adaptation by using a different encoding technique or using fixed length fields for SNMPv3 within 6LoWPAN can be analyzed to achieve reduced packet overhead.

4.1.1.  Header size reduction

SNMPv3 header size may be large because of the variability of the header fields and it needs to be reduced in order to efficiently carry management data over 6LoWPAN.

4.1.1.1.  Encoding the header for compression

The SNMPv3 header can be encoded in a way that is analogous to the IPv6 packet header encoding scheme for 6LoWPAN (LoWPAN_HC1)[RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.). Some header fields may be elided or their length may be restricted according to the characteristics of 6LoWPANs. E.g. the MsgMaxSize field of SNMPv3 header can be elided with such a scheme because it may be constant for the whole 6LoWPAN network.

4.1.1.2.  Supporting minimal functionality

The support for only limited functionality for the SNMP messages can be provided such that only the necessary and sufficient messages may fit within the 6LoWPAN payload. Investigation needs to be done in order to check if the functionality is necessary for 6LoWPANs and does the elision still fulfill the common network management needs.

4.1.1.3.  Restricting header field sizes to constant values

The fields in a SNMP header are encoded using BER encoding and their length can vary. BER is a platform independent encoding scheme which carries extra information about all the fields in SNMP. By using the BER, the size of the network fields can be variable and the size of the SNMP header can be unpredictable. Certain sizes of the SNMP message fields can be recommended for the best use of SNMP in the network.

4.1.2.  Payload size reduction

The length of the SNMP payload can be variable. To efficiently utilize the management messages we need to carry more management data rather than the control data on the management packet. To send more data in the given packet length compression, aggregation schemes may be employed. Moreover, the use of a different encoding can also significantly reduce the payload size.

4.1.2.1.  Payload Compression

Certain compression schemes are already proposed for SNMP payload. [I‑D.draft‑irtf‑nmrg‑SNMP‑compression] (Schoenwaelder, J., “SNMP Payload Compression,” April 2001.) covers DEFLATE and Object ID delta compression (ODC) algorithms. Further analysis has to be done on the use of these algorithms or employment of other compression mechanisms SNMP payload in 6LoWPAN.

4.1.2.2.  Managed Object Aggregation

The bandwidth and processing cost associated with accessing multiple objects is very high. Deployment of aggregation schemes may help in avoiding the redundant control data to be sent over the network. [RFC4498] (Keeni, G., “The Managed Object Aggregation MIB,” May 2006.) defined some schemes for object aggregation which may be used for this purpose. An alternate new aggregation technique may equally be defined to serve the purpose.

4.1.2.3.  Lightweight Encoding

It needs to be analyzed, if BER in its current form can be used for the transmission of the messages over 6LoWPANs. If the use of BER is infeasible over a 6LoWPAN, we may analyze the feasibility of using alternative encodings like PER encoding (Packed Encoding Rules), Lightweight Encoding Rules (LER), Distinguished Encoding Rules (DER) or Canonical Encoding Rules (CER). Another alternative could be fixing the type and the length of most fields in BER. The length of certain message parameters can also be fixed without a particular encoding.

4.2.  Reduction of Memory cost

6LoWPAN devices are implied to have constrained memory resources. SNMPv3 agent implementation code on the devices needs to have a low memory footprint. Moreover, the reassembly of large request packets may frequently encounter memory unavailability or even outage. The management information base (MIB) should also have a low memory footprint. Furthermore, it is to be investigated that which MIB modules are to be supported on the 6LoWPAN agent.

4.2.1.  Light-weight and Distributed Agent Functionality

The SNMP agent [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.) in its current form may not have a low memory footprint due to comprehensive functional role. Optimizations like the implementation of only SNMPv3 messages processing subsystem for the SNMPv3 agent. Moreover, the agent functionality may be distributed across the 6LoWPAN nodes within the network. Additionally, when, where and how much security and authentication options should be used, all may form effective yet lightweight equivalents of rigid SNMPv3 implementations.

4.2.2.  Reassembly on 6LoWPAN node

Due the limited memory size of the 6LoWPAN nodes it may be hard to reassemble configuration requests (SET requests) with large packet sizes. Moreover it may be difficult for the agent to reassemble the large request packets in case they are fragmented on the way. Mechanisms need to be defined that circumvent the fragmentation associated issues effectively.

4.2.3.  Minimal MIB support

Due to the limited memory size an SNMP entity may not be able to support a large set of Management Information Base (MIB). We need to examine which standard MIB modules and elements within are required to be supported on 6LoWPAN devices, and which new MIB modules are to be defined if required.

4.3.  Manager Considerations

6LoWPANs are inherently different from traditional networks. A standard SNMP manager may have to consider the heterogeneity and network dynamics by considering the following issues.

1. The SNMP manager may need guidelines for polling the 6LoWPAN node. A manager is not supposed to poll motes as frequently as mains powered hosts.

2. The SNMP manager should be aware of the fact that it is querying management information across its native network inside a wireless network. Such awareness at the SNMP manager would entail changes (adaptability) to the Time-outs of different kinds of standard queries.

3. It should take into consideration the fact that extra processing such as fragmentation/re-assembly may be carried out at the 6LoWPAN Gateway. For instance, the ingress query may be parsed at the gateway and a corresponding query is generated inside the 6LoWPAN. Likewise, a response from within the 6LoWPAN terminates at the gateway and may be encapsulated inside the respective link layer for the egress network.

4.4.  Lightweight Protocol Operation

We need to investigate how security and access control for SNMP data would work in these networks, and whether we need to pre-deploy the SNMP EngineID (unique SNMPv3 engine Identifier), or that we have to enable an EngineID discovery mechanism.

4.4.1.  EngineID discovery

In order to retrieve the data from a remote SNMPv3 engine, it is important to know the SNMP EngineID of the remote SNMPv3 engine. SNMP applications for 6LoWPAN should support the storage of EngineID in order to avoid discovery steps. As an alternative, EngineID discovery may be needed in 6LoWPANs, or another discovery mechanism could subsume it. EngineIDs may also be generated from IPv6 or MAC addresses.

4.4.2.  Security

The current SNMPv3 security protocols may tend to be heavy for 6LoWPAN networks. We need to examine if the use of SNMPv3 User-based Security Model (USM), Transport Security Model (TSM), or Community based security Model can be made feasible for 6LoWPANs. Moreover, we need to examine that the security model fulfills the management data security needs of 6LoWPANs. We also need to analyze if the lower layer security protocols may be outsourced or relegated to other protocols and are reused only when needed for SNMP security. An analysis has to be done on how data integrity, source authenticity and confidentiality be supported and which security features can be reused.

4.4.3.  Access control

We need to analyze the feasibility of supporting a light weight access control mechanism on the node. 6LoWPAN Gateways that implement firewall may have a befitting role for such authorization.

5.  Conclusion

This draft identifies the management goals for SNMPv3 optimizations in order to enable its use in 6LoWPANs. The current version of the draft specifies the goals and issues of SNMP optimizations and suggests different approaches that can be taken to facilitate the seamless use of SNMP in 6LoWPAN networks.

6.  IANA Consideration

TBD.

7.  Security Considerations

TBD.

8.  Acknowledgments

Thanks to Ali Hammad Akbar and Phil Roberts for reviewing this document and to Hwang So-Young for her useful discussion and support for writing this document.

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses