Network Working Group H. Mukhtar Ed.
Internet-Draft S. Joo
Intended status: Standards Track ETRI
Expires: October 5, 2009 J. Schoenwaelder
Jacobs University Bremen
April 3, 2009
SNMP optimizations for 6LoWPAN
draft-hamid-6lowpan-snmp-optimizations-01.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 October 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Mukhtar Ed., et al. Expires October 5, 2009 [Page 1]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Management Requirements and design goals . . . . . . . . . . . 3
3. Deployment models . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Lightweight End-to-End . . . . . . . . . . . . . . . . . . 4
3.2. Proxy Model . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. SNMP with Sub-Agent Protocols . . . . . . . . . . . . . . 4
4. Optimization Goals . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Reduction of Packet size . . . . . . . . . . . . . . . . . 5
4.1.1. Header size reduction . . . . . . . . . . . . . . . . 5
4.1.2. Payload size reduction . . . . . . . . . . . . . . . . 6
4.2. Reduction of Memory cost . . . . . . . . . . . . . . . . . 7
4.2.1. Light-weight and Distributed Agent Functionality . . . 7
4.2.2. Reassembly on 6LoWPAN node . . . . . . . . . . . . . . 7
4.2.3. Minimal MIB support . . . . . . . . . . . . . . . . . 8
4.3. Manager Considerations . . . . . . . . . . . . . . . . . . 8
4.4. Lightweight Protocol Operation . . . . . . . . . . . . . . 8
4.4.1. EngineID discovery . . . . . . . . . . . . . . . . . . 8
4.4.2. Security . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.3. Access control . . . . . . . . . . . . . . . . . . . . 9
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Mukhtar Ed., et al. Expires October 5, 2009 [Page 2]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
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] 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] 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.
Mukhtar Ed., et al. Expires October 5, 2009 [Page 3]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
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 talks SNMPv3 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].
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]) 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
Mukhtar Ed., et al. Expires October 5, 2009 [Page 4]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
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, for a single 6LoWPAN payload,
due to their variable length. The message size should be reduced in
order to efficiently utilize the link bandwidth. Extra fragmentation
of the management packets may also be needed to be avoided.
[RFC3417] 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] 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]. 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.
Mukhtar Ed., et al. Expires October 5, 2009 [Page 5]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
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].
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 is
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] 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
Mukhtar Ed., et al. Expires October 5, 2009 [Page 6]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
avoiding the redundant control data to be sent over the network.
[RFC4498] 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] in its current form may not have a low
memory footprint due to comprehensive functional role. 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 to 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.
Mukhtar Ed., et al. Expires October 5, 2009 [Page 7]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
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.
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
Mukhtar Ed., et al. Expires October 5, 2009 [Page 8]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
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
[RFC2119] Bradner, S., "Key words for
use in RFCs to Indicate
Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC3411] Harrington, D., Presuhn, R.,
and B. Wijnen, "An
Architecture for Describing
Simple Network Management
Mukhtar Ed., et al. Expires October 5, 2009 [Page 9]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
Protocol (SNMP) Management
Frameworks", STD 62,
RFC 3411, December 2002.
[RFC3412] Case, J., Harrington, D.,
Presuhn, R., and B. Wijnen,
"Message Processing and
Dispatching for the Simple
Network Management Protocol
(SNMP)", STD 62, RFC 3412,
December 2002.
[RFC3413] Levi, D., Meyer, P., and B.
Stewart, "Simple Network
Management Protocol (SNMP)
Applications", STD 62,
RFC 3413, December 2002.
[RFC3416] Presuhn, R., "Version 2 of
the Protocol Operations for
the Simple Network Management
Protocol (SNMP)", STD 62,
RFC 3416, December 2002.
[RFC3417] Presuhn, R., "Transport
Mappings for the Simple
Network Management Protocol
(SNMP)", STD 62, RFC 3417,
December 2002.
[RFC4789] Schoenwaelder, J. and T.
Jeffree, "Simple Network
Management Protocol (SNMP)
over IEEE 802 Networks",
RFC 4789, November 2006.
[RFC4944] Montenegro, G., Kushalnagar,
N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets
over IEEE 802.15.4 Networks",
RFC 4944, September 2007.
9.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain,
D., and B. Stewart,
"Introduction and
Applicability Statements for
Mukhtar Ed., et al. Expires October 5, 2009 [Page 10]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
Internet-Standard Management
Framework", RFC 3410,
December 2002.
[RFC2741] Daniele, M., Wijnen, B.,
Ellison, M., and D.
Francisco, "Agent
Extensibility (AgentX)
Protocol Version 1",
RFC 2741, January 2000.
[RFC3584] Frye, R., Levi, D., Routhier,
S., and B. Wijnen,
"Coexistence between Version
1, Version 2, and Version 3
of the Internet-standard
Network Management
Framework", BCP 74, RFC 3584,
August 2003.
[RFC4498] Keeni, G., "The Managed
Object Aggregation MIB",
RFC 4498, May 2006.
[RFC4919] Kushalnagar, N., Montenegro,
G., and C. Schumacher, "IPv6
over Low-Power Wireless
Personal Area Networks
(6LoWPANs): Overview,
Assumptions, Problem
Statement, and Goals",
RFC 4919, August 2007.
[IEEE802.15.4] 802.15.4-2003, IEEE
Standard., "Wireless medium
access control and physical
layer specifications for low-
rate wireless personal area
networks.", May 2003.
[I-D.draft-irtf-nmrg-SNMP-compression] Schoenwaelder, J., "SNMP
Payload Compression",
April 2001.
Mukhtar Ed., et al. Expires October 5, 2009 [Page 11]
Internet-Draft SNMP optimizations for 6LoWPAN April 2009
Authors' Addresses
Hamid Mukhtar (editor)
ETRI
USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu,
Daejeon 305-350
KOREA
Phone: +82 42 860 5435
EMail: hamid@etri.re.kr
Seong-Soon Joo
ETRI
USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu,
Daejeon 305-350
KOREA
Phone: +82 42 860 6333
EMail: ssjoo@etri.re.kr
Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
Bremen 28725
Germany
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Mukhtar Ed., et al. Expires October 5, 2009 [Page 12]