< draft-hamid-6lowpan-snmp-optimizations-02.txt   draft-hamid-6lowpan-snmp-optimizations-03.txt >
Network Working Group H. Mukhtar Ed. Network Working Group J. Schoenwaelder, Ed.
Internet-Draft S. Joo Internet-Draft Jacobs University
Intended status: Informational ETRI Intended status: Informational H. Mukhtar
Expires: April 24, 2010 J. Schoenwaelder Expires: April 28, 2011 S. Joo
Jacobs University Bremen ETRI
K. Kim K. Kim
Ajou University Ajou University
October 21, 2009 October 25, 2010
SNMP optimizations for 6LoWPAN SNMP Optimizations for Constrained Devices
draft-hamid-6lowpan-snmp-optimizations-02.txt draft-hamid-6lowpan-snmp-optimizations-03.txt
Abstract
Simple Network Management Protocol (SNMP) is a widely deployed
application protocol for network management and in particular network
monitoring. This document describe the applicability of SNMP to
constrained devices, e.g., nodes in Low-power and Lossy Networks. We
discuss SNMP implementation techniques and we provide deployment
considerations. Our discussion also covers the applicability of MIB
modules to constrained devices.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2010. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Simple Network Management Protocol (SNMP) is a widely deployed described in the BSD License.
application protocol for network management and data retrieval. In
this document we describe the applicability of SNMP for 6LoWPANs. We
discuss the implementation considerations of SNMP Agent and SNMP
Manager followed by the deployment considerations of the SNMP
protocol. Our discussion also covers the applicability of MIB
modules for 6LoWPAN devices.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in RFC 2119 [RFC2119]. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Why SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. SNMP Features and Overhead Considerations . . . . . . . . . . 6
2. Little-known SNMP Features . . . . . . . . . . . . . . . . . . 5 2.1. SNMP Contexts . . . . . . . . . . . . . . . . . . . . . . 6
2.1. SNMP Contexts . . . . . . . . . . . . . . . . . . . . . . 5 2.2. SNMP Proxies . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. SNMP Proxies . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. SNMP Subagents . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Message Size Restrictions . . . . . . . . . . . . . . . . 5 2.4. Maximum Message Sizes . . . . . . . . . . . . . . . . . . 7
3. SNMP Agent Implementation Considerations . . . . . . . . . . . 6 2.5. SNMP Message Formats . . . . . . . . . . . . . . . . . . . 7
3.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 6 2.6. SNMPv3 Security Overhead . . . . . . . . . . . . . . . . . 7
3.2. Overhead of the Different SNMP Message Formats . . . . . . 6 3. SNMP Agent Implementation Considerations . . . . . . . . . . . 9
3.2.1. Overhead Difference of SNMPv3 Security . . . . . . . . 6 3.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Minimum Message Size Calculation . . . . . . . . . . . 7 4. SNMP Manager Implementation Considerations . . . . . . . . . . 11
4. SNMP Manager Implementation Considerations . . . . . . . . . . 7 4.1. Polling, Pushing, and Trap-directed Polling . . . . . . . 11
4.1. Polling, Pushing, and Trap-directed Polling . . . . . . . 8 4.2. Support for SNMP Proxies . . . . . . . . . . . . . . . . . 11
4.2. Support for SNMP Proxies . . . . . . . . . . . . . . . . . 8 5. SNMP Deployment Considerations . . . . . . . . . . . . . . . . 12
5. SNMP Deployment Considerations . . . . . . . . . . . . . . . . 8 5.1. Naming Issues . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Naming Issues . . . . . . . . . . . . . . . . . . . . . . 9 5.2. SNMP Protocol Operations . . . . . . . . . . . . . . . . . 12
5.2. SNMP Protocol Operations . . . . . . . . . . . . . . . . . 9 5.3. Timeouts and Retransmissions . . . . . . . . . . . . . . . 12
5.3. Timeouts and Retransmissions . . . . . . . . . . . . . . . 9 5.4. Polling Intervals . . . . . . . . . . . . . . . . . . . . 12
5.4. Polling Intervals . . . . . . . . . . . . . . . . . . . . 9 5.5. Caching Issues . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Caching Issues . . . . . . . . . . . . . . . . . . . . . . 10 6. Applicable MIB Modules . . . . . . . . . . . . . . . . . . . . 14
6. Applicable MIB Modules . . . . . . . . . . . . . . . . . . . . 10 6.1. Applicable Standardized MIB Modules . . . . . . . . . . . 14
6.1. Applicable Standardized MIBs . . . . . . . . . . . . . . . 10 6.2. MIB Design Guidelines for Low Overhead . . . . . . . . . . 14
6.2. MIB Design Guidelines for Low Overhead . . . . . . . . . . 10 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 Appendix A. Calculation of Minimum Message Sizes . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 A.1. SNMPv3/USM Minimum Message Size . . . . . . . . . . . . . 22
Appendix A. Calculation of Minimum packet size . . . . . . . . . 13 A.2. SNMPv3/TSM Minimum Message Size . . . . . . . . . . . . . 22
Appendix B. Possible Deployment Models for SNMP . . . . . . . . . 15 A.3. SNMPv1/SNMPv2c Minimum Message Size . . . . . . . . . . . 23
B.1. Lightweight End-to-End . . . . . . . . . . . . . . . . . . 15 Appendix B. Implementation and Deployment Models . . . . . . . . 24
B.2. Proxy Model . . . . . . . . . . . . . . . . . . . . . . . 15 B.1. SNMP End-to-End Model . . . . . . . . . . . . . . . . . . 24
B.3. SNMP with Sub-Agent Protocols . . . . . . . . . . . . . . 16 B.2. SNMP Proxy Model . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16 B.3. SNMP Subagent Model . . . . . . . . . . . . . . . . . . . 25
B.4. SNMP Data-Fusion Model . . . . . . . . . . . . . . . . . . 25
Appendix C. Example: Contiki SNMP . . . . . . . . . . . . . . . . 27
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 28
D.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 28
D.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Simple Network Management Protocol (SNMP) is a UDP-based protocol The Simple Network Management Protocol (SNMP) is a datagram-oriented
operating in the application layer of the Internet Protocol Suite. protocol operating in the application layer of the Internet protocol
It consists of four basic components: a managed node running an suite. The underlying framework consists of four basic components
agent; an entity running management applications (typically called as [RFC3410]:
a manager); a protocol to convey information between the SNMP
entities; and management information.
1.1. Why SNMP o several (typically many) managed nodes, each with an SNMP entity
which provides remote access to management instrumentation
(traditionally called an agent),
SNMP is datagram-oriented and the implementations of SNMP can be very o at least one SNMP entity with management applications (typically
lightweight. It may fit 6LoWPAN applications very well. The called a manager),
following features make SNMP suitable for this network.
- Protocol Maturity: SNMPv3 is a full IETF standard having a high o a management protocol used to convey management information
degree of technical maturity with significant experiences in between the SNMP entities, and
implementation and operation.
- Data Naming: SNMP provides a hierarchical namespace utilizing o management information.
object identifiers (OIDs) for data naming purposes. The data
accessible via SNMP is described by Management Information Bases (MIB
modules). These MIB modules can either be standardized or specific
to certain enterprises.
- Network Management: According to [RFC4919] network management is The SNMP protocol is used to convey management information between
one of the goals for 6LoWPANs, wherein it is described that network SNMP entities such as managers and agents. SNMP is datagram-oriented
management functionality is critical for 6LoWPANs. SNMP is widely and the implementations of SNMP can be very lightweight. The
used for network management and it is the Internet community's de protocol is widely deployed for monitoring and troubleshooting
facto management protocol. purposes and it may fit constrained devices very well. The following
features make SNMP suitable for constrained devices on Low-power and
Lossy Networks (LLNs):
- Data Retrieval: SNMP employs polling in which data is being o Protocol Maturity: SNMPv3 is a full IETF standard having a high
requested by a manager from the agents. In addition, SNMP supports a degree of technical maturity with significant experiences in
push model in which data is sent from agents to the managers without implementation and operation.
a prior request. Trap-directed polling refers to a mode where
polling is used with relatively long polling intervals but agents can
send notifications in order to notify a manager of events that might
require changes to the polling strategy.
- Security: SNMPv3 can provide both message-level and transport-level o Data Naming: SNMP provides a hierarchical namespace utilizing
security. SNMPv3 defines User based Security model (USM) for object identifiers (OIDs) for data naming purposes. The data
message-driven security; and transport-based security model (TSM) for accessible via SNMP is described by Management Information Bases
transport-driven security. TSM makes it possible to use existing (MIB modules). These MIB modules can either be standardized or
security protocols such as Transport Layer Security (TLS) [RFC5246] specific to certain enterprises.
and the Datagram Transport Layer Security (DTLS) Protocol [RFC4347]
with SNMPv3. The modular design of SNMPv3 also allows new security
and access control protocols to be added to it.
- Access control: SNMP can provide access control of the information. o Network Management: SNMP is widely used for network management and
it is the Internet community's de facto network management and
monitoring protocol. As a consequence, it makes sense to utilize
SNMP also for the management and in particular monitoring of
resource constrained networks. Network management is also stated
as one of the goals in [RFC4919].
2. Little-known SNMP Features o Data Retrieval: SNMP employs a trap-directed polling scheme in
which data is being requested by a manager from the agents. In
addition, SNMP supports a push model in which data is sent from
agents to the managers without a prior request. Trap-directed
polling refers to a mode where polling is used with relatively
long polling intervals but agents can send notifications in order
to notify a manager of events that might require changes to the
polling strategy.
This section explains some little-known SNMP concepts. o Security: SNMPv3 can provide both message-level and transport-
level security. SNMPv3 defines User based Security model (USM)
[RFC3414] for message-driven security; and transport-based
security model (TSM) [RFC5591] for transport-driven security. TSM
makes it possible to use existing security protocols such as
Transport Layer Security (TLS) [RFC5246] and the Datagram
Transport Layer Security (DTLS) Protocol [RFC4347] with SNMPv3.
The modular design of SNMPv3 also allows new security and access
control protocols to be added to it.
o Access control: SNMP provides standard mechanisms to control
access to information [RFC3415].
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].
2. SNMP Features and Overhead Considerations
This section first explains some less widely known SNMP concepts
before discussing message sizes.
2.1. SNMP Contexts 2.1. SNMP Contexts
Each SNMP entity is composed of a single engine which is identified Each SNMP entity is composed of a single SNMP engine, which is
by an SNMP engine identifier. A context is a collection of identified by an SNMP engine identifier. A context is a collection
management information accessible by an SNMP entity and it is also of management information accessible by an SNMP entity. An SNMP
defined as a subset of a single SNMP entity. An SNMP entity has entity has access to one or more contexts where each context is
access to one or more contexts uniquely identified by context names. uniquely identified by its context name. In order to identify an
In order to identify an individual item of management information individual item of management information within a management domain,
within the management domain, the SNMP entity's context is identified the SNMP entity's context is identified first (using the
first (using the engine identifier and context name) and this is contextEngineID and contextName) and this is followed by the object
followed by the object type and instance. type and instance. For further details, see [RFC3411].
2.2. SNMP Proxies 2.2. SNMP Proxies
The term 'proxy' in SNMP has a restrictive meaning. A proxy refers The term 'proxy' in SNMP has a restrictive meaning. A proxy refers
to a proxy forwarder application which forwards SNMP messages to to a proxy forwarder application which forwards SNMP messages to
other SNMP engines and forwards the response to such previously other SNMP engines and forwards the response to such previously
forwarded messages back to SNMP engine from which the original forwarded messages back to SNMP engine from which the original
message was received [RFC3413]. The forwarding is based on contexts message was received [RFC3413]. The forwarding decision is based on
and it is irrespective of the management objects being accessed. contexts and it is taken irrespectively of the management objects
Thus, an SNMP proxy can be used to forward messages from one being accessed. Thus, an SNMP proxy can be used to forward messages
transport to another, or to translate SNMP messages from one version from one transport to another, or to translate SNMP messages from one
to another version. version to another version.
The SNMP proxy cannot be used for translation of SNMP requests into The SNMP proxy cannot be used for translation of SNMP requests into
operations of a non-SNMP management protocol and it cannot be used operations of a non-SNMP management protocol and it cannot be used
for supporting aggregated objects. Proxies depend on context for supporting aggregated objects. Proxies depend on context
information and the forwarding of messages is independent of the information and the forwarding of messages is independent of the
objects being accessed. To support aggregated objects, where the objects being accessed. To support aggregated objects, where the
value of one object depends upon multiple other remote items, special value of one object depends upon multiple other remote items, special
MIB modules and sub-agent protocols are used instead of proxies. MIB modules and sub-agent protocols are used instead of proxies.
2.3. Message Size Restrictions 2.3. SNMP Subagents
SNMP message contains a msgMaxSize field which is used to communicate In order to support modular systems, SNMP agents often do not
the maximum message size at the sender and the receiver side. The implement all MIB objects internally. Instead, the SNMP agent is
maximum message size is the maximum size of a message that can be delegating the access to the instrumentation to other processes,
accepted by the receiving entity. called subagents. A special purpose protocol is used between the
SNMP agent and its subagents. The Agent Extensibility Protocol
(AgentX) is a standard subagent access protocol [RFC2741]
The minimum required to implement message size is transport model 2.4. Maximum Message Sizes
specific. For SNMP over UDP, the size is 484 octets.
An SNMPv3 message contains the msgMaxSize field, which is used to
communicate the maximum message size a sender is able to receive.
The response to a request should not exceed the maximum message size
of the requesting SNMP entity. The minimum required maximum message
size to implement is transport model specific. For SNMP over UDP,
the size is 484 octets.
2.5. SNMP Message Formats
SNMPv1 [RFC1157] is the first version of SNMP and it reached the IETF
full standard status in 1990. The protocol operation consisted of
Get and Get-Next, for data retrieval, Trap for event notification,
the Set for configuration. SNMPv1 security uses clear-text community
string authentication, which is easy to break. Access control is
provided with SNMP MIB views. SNMPv2c is an improvement over SNMPv1
which introduced new data retrieval and event notificaiton
operations, i.e., Get-Bulk and Inform. It also introduced improved
error handling for Set operations. SNMPv2c could only reach
Experimental status.
SNMPv3, STD 62, [RFC3411] [RFC3412] [RFC3413] [RFC3414] [RFC3415]
[RFC3416] [RFC3417] [RFC3418], supports all the aforementioned data
retrieval and configuration options of SNMPv1 and SNMPv2c. The
SNMPv3 framework is modular in order to enhance extensibility.
Moreover, SNMPv3 supports authentication and data integrity and an
additional privacy option for confidentiality. After SNMPv3 became a
full standard, SNMPv1 and SNMPv2c were declared Historic due to their
weak security features. However, SNMPv3 can coexist with the earlier
versions of SNMP [RFC3584].
2.6. SNMPv3 Security Overhead
SNMP security can be supported by two different approaches, i.e.,
message-driven security and transport-driven security. With message-
driven security, SNMP provides its own security where the security
parameters are passed within each SNMP message. On the other hand,
transport-driven security enables operators to leverage existing
secure transport protocols. Security is provided at the transport
layer, usually establishling a security session.
The User-based Security Model [RFC3414] is a shared secret scheme,
which provides message-driven security. Although it utilizes
existing mechanisms, it is designed to not depend on other security
infrastructures. As a consequence, it provides its own security
processing and has its own key management infrastructure. The
operator configures secrets (authentication and encryption keys) in
the SNMP engines. Messages can be authenticated, or authenticated
and encrypted.
The Transport Security Model (TSM) [RFC5591] enables operators to
leverage existing security infrastructures. TSM allows security to
be provided by an external secure transport protocol and as such
enables the use of existing security mechanisms, such as Transport
Layer Security (TLS) [RFC5246], Datagram Transport Layer Security
(DTLS) Protocol [RFC4347], and the Secure Shell (SSH) Protocol
[RFC4251].
In transport-driven protocols, DTLS, which is UDP based, can be
considered for constrained networks since it does not require TCP.
[RFC5953] details how DTLS can be used with SNMPv3/TSM. The DTLS
transport protocol involves an initial handshake to establish a
session. Upon successful session establishment, the security related
session parameters are cached in the client and the server for the
duration of the session instead of being sent in all messages.
The minimum message size for SNMPv3 with USM (SNMPv3/USM) is 67
octets whereas the minimum message size for SNMPv3 with TSM (SNMPv3/
TSM) utilizing DTLS is 46 octets (59 octets if the DTLS header is
included). The minimum message size for the historic SNMPv1 message
format is 20 byte. The details of the calculation can be found in
Appendix A. TSM may involve additional session establishment costs
consisting of the initial handshake and the caching of transport
parameters. The tradeoff between the message size and session
overhead should be kept in mind while designing applications.
3. SNMP Agent Implementation Considerations 3. SNMP Agent Implementation Considerations
This section covers SNMP agent implementation considerations for This section covers SNMP agent implementation considerations for
6LoWPAN. constrained devices.
3.1. Access Control 3.1. Access Control
The Local Configuration Datastore (LCD), which contains access rights The Local Configuration Datastore (LCD), which contains access rights
and policies of an SNMP entity, need not be configured remotely. It and policies of an SNMP entity, need not be configured remotely. It
is recommended to have permanent access control tables on the nodes. is recommended to have permanent access control tables on the nodes.
The implementers should keep the authorization tables as compact as The implementers should keep the authorization tables as compact as
possible to reduce the memory and codesize overhead. Compact possible to reduce the memory and code size overhead. Compact
permanent authorization tables on the nodes can for example provide permanent authorization tables on the nodes can, for example, provide
read-only and read-write access to the management instrumentation on read-only and read-write access to the management instrumentation on
the node at almost zero processing cost since the SNMP agents may not the node at almost zero processing cost since the SNMP agents may not
support instance level access control granularity to further reduce support instance level access control granularity to further reduce
performance cost. performance cost.
3.2. Overhead of the Different SNMP Message Formats A minimal View-based Access Control Model (VACM) implementation only
provides a static view granting access to all MIB objects. The
SNMPv1 [RFC1157] is the earliest version of SNMP and it reached the access rights are statically configured to either grant full read
IETF full standard status. The protocol operation consisted of Get, access or full read and write access. There is only support for the
Get-Next, and Trap Operations for data retrieval and the Set default context. Such a simplified implementation processes the
operation for configuration. SNMPv1 security is based on community isAccessAllowed() ASI [RFC3415] as follows:
string based authentication. Access control is provided with SNMP
MIB views. SNMPv2c was an experimental improvement over SNMPv1 which
introduced new data retrieval operations, i.e., Get-Bulk and Inform,
and introduced improved error handling. SNMPv2c could only reach the
experimental status.
SNMPv3, Std 62 [RFC3411]-[RFC3418], supports all the aforementioned 1) If the viewType is "write", the securityName is "w" (for any
data retrieval and configuration options of SNMPv1 and SNMPv2c. The securityModel and any securityLevel), and the contextName is "",
SNMPv3 framework is modular in order to enhance extensibility. then grant access to the requested variable.
Moreover, SNMPv3 supports authentication and data integrity and an
additional privacy option for confidentiality. After SNMPv3 became a
full standard, SNMPv1 and SNMPv2c were declared Historic due to their
weak security features. However, SNMPv3 can coexist with the earlier
versions of SNMP [RFC3584].
3.2.1. Overhead Difference of SNMPv3 Security 2) Otherwise, if the viewType is either "read" or "notifiy", the
securityName is "r" (for any securityModel and any
securityLevel), and the contextName is "", then grant access to
the requested variable.
SNMP security can be supported by two different approaches, i.e., 3) Otherwise, return an errorIndication (noAccessEntry) to the
message-driven security and transport-driven security. With message- calling module.
driven security (the User-based Security Model, USM), SNMP provides
its own security where the security parameters are passed within each
SNMP message. On the other hand, transport-driven security enables
operators to leverage existing secure transport protocols (e.g., the
Transport Security Model, TSM).
The User-based Security Model [RFC3414] is a shared secret scheme An implementation should provide the following MIB objects (note that
which uses message-driven security. Although it utilizes existing all values are permanent):
mechanisms, it is designed independent of other security
infrastructures. It provides its own security and has its own key
management infrastructure. The operator configures secrets in the
SNMP engines used by management applications. These independent
authentication and encryption keys are used to secure communication.
Messages can be authenticated, or authenticated and encrypted.
The Transport Security Model (TSM) enables operators to leverage vacmContextName."" = ""
existing security infrastructures and secure transport protocols.
TSM allows security to be provided by an external secure transport
protocol. TSM enables the use of existing security mechanisms, such
as Transport Layer Security (TLS) [RFC5246], Datagram Transport Layer
Security (DTLS) Protocol [RFC4347], and the Secure Shell (SSH)
Protocol [RFC4251].
In transport-driven protocols DTLS, which is UDP based, can be vacmGroupName.0."r" = "r"
considered for 6LoWPAN. [I-D.draft-ietf-isms-dtls-tm] specifies how vacmGroupName.0."w" = "w"
DTLS can be used with SNMP. Transport Model for DTLS protocol vacmSecurityToGroupStorageType.0."r" = 5 (readOnly)
involves an initial handshake to establish a session. Upon vacmSecurityToGroupStorageType.0."w" = 5 (readOnly)
successful session establishment, the security related session vacmSecurityToGroupStatus.0."r" = 1 (active)
parameters are cached in the client and the server for the duration vacmSecurityToGroupStatus.0."w" = 1 (active)
of the session instead of being sent in all messages. The session is
based on UDP source and destination address/port pairs. Therefore
for session de-multiplexing a different UDP source port is selected
for every new session to distinguish between multiple sessions from a
source to same port on the destination.
3.2.2. Minimum Message Size Calculation vacmAccessContextMatch."r"."".0.1 = 1 (exact)
vacmAccessContextMatch."w"."".0.1 = 1 (exact)
vacmAccessReadViewName."r"."".0.1 = "a"
vacmAccessReadViewName."w"."".0.1 = "a"
vacmAccessWriteViewName."r"."".0.1 = "a"
vacmAccessWriteViewName."w"."".0.1 = "a"
vacmAccessNotifyViewName."r"."".0.1 = "a"
vacmAccessNotifyViewName."w"."".0.1 = "a"
vacmAccessStorageType."r"."".0.1 = 5 (readOnly)
vacmAccessStorageType."w"."".0.1 = 5 (readOnly)
vacmAccessStatus."r"."".0.1 = 1 (active)
vacmAccessStatus."w"."".0.1 = 1 (active)
The minimum message size for SNMPv3 with USM is 67 bytes whereas the vacmViewTreeFamilyMask."a".2.1.3 = ""
minimum message size for SNMPv3 with TSM is 46 bytes. The minimum vacmViewTreeFamilyType."a".2.1.3 = 1 (included)
message size for the historic SNMPv1 message is 20 byte. The details vacmViewTreeFamilyStorageType."a".2.1.3 = 5 (readOnly)
of the calculation can be found in Appendix A. TSM may involve vacmViewTreeFamilyStatus."a".2.1.3 = 1 (active)
additional session establishment cost consisting of the initial
handshake and the caching of transport parameters. The tradeoff
between the message size and session overhead should be kept in mind
while designing applications.
4. SNMP Manager Implementation Considerations 4. SNMP Manager Implementation Considerations
This section covers SNMP manager implementation considerations for This section covers SNMP manager implementation considerations for
6LoWPAN. 6LoWPAN.
4.1. Polling, Pushing, and Trap-directed Polling 4.1. Polling, Pushing, and Trap-directed Polling
In Sensor networks, polling can be reactive or proactive. Data In Sensor networks, polling can be reactive or proactive. Data
gathering or event reporting sensors may 'push' their information gathering or event reporting sensors may 'push' their information
skipping to change at page 10, line 15 skipping to change at page 14, line 7
5.5. Caching Issues 5.5. Caching Issues
Caching the important information can save the transmission cost e.g. Caching the important information can save the transmission cost e.g.
caching the snmpEngineID would save the traffic overhead of EngineID caching the snmpEngineID would save the traffic overhead of EngineID
discovery mechanisms. It is recommended that the EngineID should be discovery mechanisms. It is recommended that the EngineID should be
cached in order to reduce the transmission cost. In case of TSM, cached in order to reduce the transmission cost. In case of TSM,
caching the transport parameters can reduce the message sizes. caching the transport parameters can reduce the message sizes.
6. Applicable MIB Modules 6. Applicable MIB Modules
This section describes some relevant MIB modules which can be used in This section describes some MIB modules relevant for constrained
6LoWPAN. devices and it provides guidelines for authors of MIB modules that
can be used efficiently in constrained networks.
6.1. Applicable Standardized MIBs 6.1. Applicable Standardized MIB Modules
ENTITY-SENSOR-MIB [RFC3433] defines objects for information that is Below is a list of MIB modules that may be applicable to a
associated with physical sensors (e.g. the current value of the constrained device:
sensor, operational status, and the data units precision associated
with the sensor). It can be reused for 6LoWPANs. Other applicable o The SNMPv2-MIB [RFC3418] MUST be implemented as it provides basic
MIB modules are TBD. information about the SNMP agent and crucial objects that allow to
detect continuities.
o The IF-MIB [RFC2863] SHOULD be implemented in order to provide
basic statistics about the network interfaces of the constrained
device. [TODO: Define what is really essential from the IF-MIB.]
o Devices supporting IPv4 or IPv6 SHOULD implement the IP-MIB
[RFC4293]. [TODO: Define what is really essential from the IP-
MIB.]
o Devices supporting UDP SHOULD implement the UDP-MIB [RFC2013].
[TODO: Define what is really essential from the UDP-MIB.]
o Devices supporting IPv6 over 802.15.4 (6LoWPAN) SHOULD implement
the LOWPAN-MIB. [TODO: There is no LOWPAN-MIB yet.]
o Devices supporting the RPL routing protocol SHOULD implement the
RPL-MIB. [TODO: There is no RPL-MIB yet.]
o Devices supporting sensors MAY implement the ENTITY-SENSOR-MIB
[RFC3433], which defines objects for reading physical sensors
(e.g., the current value of the sensor, the operational status of
a sensor, or the data units precision associated with a sensor).
The ENTITY-SENSOR-MIB depends on the ENTITY-MIB [RFC4133]. [TODO:
Define what is really essential from the ENTITY-MIB.]
6.2. MIB Design Guidelines for Low Overhead 6.2. MIB Design Guidelines for Low Overhead
When defining MIB modules, the MIB designers should avoid using long When defining MIB modules, the MIB designers should avoid using long
OIDs by avoiding unnecessary data hierarchies. Moreover, complex OIDs by avoiding unnecessary data hierarchies. Moreover, complex
indexing schemes should be avoided in order to keep the overhead indexing schemes should be avoided in order to keep the overhead
resulting from instance identifiers as low as possible. resulting from instance identifiers as small as possible.
7. Conclusion 7. Conclusion
SNMP can be very useful for 6LoWPANs due to its significant SNMP can be very useful protocol for constrained devices with
implementation and operational experiences. The standards allow for significant implementation and operational experiences. The SNMP
memory and CPU efficient implementations. The utilization of secure standards allow for memory and CPU efficient implementations. The
transports such as DTLS can reduce the overhead of message-based utilization of secure transports such as DTLS can reduce the overhead
security mechanisms. This document explored the applicability of of message-based security mechanisms.
SNMP for its use in 6LoWPAN.
8. IANA Consideration 8. IANA Consideration
TBD. TBD
9. Security Considerations 9. Security Considerations
TBD. TBD
10. Acknowledgments 10. References
TBD. 10.1. Normative References
11. References [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
11.1. Normative References [RFC2013] McCloghrie, K., "SNMPv2 Management Information Base for
the User Datagram Protocol using SMIv2", RFC 2013,
November 1996.
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFCs to Indicate Requirement Levels", Requirement Levels", BCP 14, RFC 2119, March 1997.
BCP 14, RFC 2119, March 1997.
[RFC3411] Harrington, D., Presuhn, R., and B. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
Wijnen, "An Architecture for MIB", RFC 2863, June 2000.
Describing Simple Network Management
Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
and B. Wijnen, "Message Processing and Architecture for Describing Simple Network Management
Dispatching for the Simple Network Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
Management Protocol (SNMP)", STD 62, December 2002.
RFC 3412, December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Simple Network Management Protocol "Message Processing and Dispatching for the Simple Network
(SNMP) Applications", STD 62, Management Protocol (SNMP)", STD 62, RFC 3412,
RFC 3413, December 2002. December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User- [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
based Security Model (USM) for version Management Protocol (SNMP) Applications", STD 62,
3 of the Simple Network Management RFC 3413, December 2002.
Protocol (SNMPv3)", STD 62, RFC 3414,
December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
McCloghrie, "View-based Access Control (USM) for version 3 of the Simple Network Management
Model (VACM) for the Simple Network Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
Management Protocol (SNMP)", STD 62,
RFC 3415, December 2002.
[RFC3416] Presuhn, R., "Version 2 of the [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Protocol Operations for the Simple Access Control Model (VACM) for the Simple Network
Network Management Protocol (SNMP)", Management Protocol (SNMP)", STD 62, RFC 3415,
STD 62, RFC 3416, December 2002. December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
the Simple Network Management Protocol Simple Network Management Protocol (SNMP)", STD 62,
(SNMP)", STD 62, RFC 3417, RFC 3416, December 2002.
December 2002.
[RFC3418] Presuhn, R., "Management Information [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417,
Management Protocol (SNMP)", STD 62, December 2002.
RFC 3418, December 2002.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
J., and D. Culler, "Transmission of Simple Network Management Protocol (SNMP)", STD 62,
IPv6 Packets over IEEE 802.15.4 RFC 3418, December 2002.
Networks", RFC 4944, September 2007.
[RFC5590] Harrington, D. and J. Schoenwaelder, [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
"Transport Subsystem for the Simple Management Information Base", RFC 3433, December 2002.
Network Management Protocol (SNMP)",
RFC 5590, June 2009.
[RFC5591] Harrington, D. and W. Hardaker, [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
"Transport Security Model for the RFC 4133, August 2005.
Simple Network Management Protocol
(SNMP)", RFC 5591, June 2009.
[RFC3433] Bierman, A., Romascanu, D., and K. [RFC4293] Routhier, S., "Management Information Base for the
Norseth, "Entity Sensor Management Internet Protocol (IP)", RFC 4293, April 2006.
Information Base", RFC 3433,
December 2002.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
and J. Davin, "Simple Network for the Simple Network Management Protocol (SNMP)",
Management Protocol (SNMP)", STD 15, RFC 5591, June 2009.
RFC 1157, May 1990.
[I-D.draft-ietf-isms-dtls-tm] Hardaker, W., "Transport Layer [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport
Security Transport Model for SNMP", Model for the Simple Network Management Protocol (SNMP)",
September 2009. RFC 5953, August 2010.
11.2. Informative References 10.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
B. Stewart, "Introduction and "Introduction and Applicability Statements for Internet-
Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.
Standard Management Framework",
RFC 3410, December 2002.
[RFC2741] Daniele, M., Wijnen, B., Ellison, M., [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco,
and D. Francisco, "Agent Extensibility "Agent Extensibility (AgentX) Protocol Version 1",
(AgentX) Protocol Version 1", RFC 2741, January 2000.
RFC 2741, January 2000.
[RFC3584] Frye, R., Levi, D., Routhier, S., and [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
B. Wijnen, "Coexistence between "Coexistence between Version 1, Version 2, and Version 3
Version 1, Version 2, and Version 3 of of the Internet-standard Network Management Framework",
the Internet-standard Network BCP 74, RFC 3584, August 2003.
Management Framework", BCP 74,
RFC 3584, August 2003.
[RFC4919] Kushalnagar, N., Montenegro, G., and [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
C. Schumacher, "IPv6 over Low-Power over Low-Power Wireless Personal Area Networks (6LoWPANs):
Wireless Personal Area Networks Overview, Assumptions, Problem Statement, and Goals",
(6LoWPANs): Overview, Assumptions, RFC 4919, August 2007.
Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Transport Layer Security (TLS) (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Protocol Version 1.2", RFC 5246,
August 2008.
[RFC4347] Rescorla, E. and N. Modadugu, [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
"Datagram Transport Layer Security", Security", RFC 4347, April 2006.
RFC 4347, April 2006.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Shell (SSH) Protocol Architecture", Protocol Architecture", RFC 4251, January 2006.
RFC 4251, January 2006.
[RFC4789] Schoenwaelder, J. and T. Jeffree, Appendix A. Calculation of Minimum Message Sizes
"Simple Network Management Protocol
(SNMP) over IEEE 802 Networks",
RFC 4789, November 2006.
Appendix A. Calculation of Minimum packet size A simple way to estimate the size (in octets) of an SNMP variable
binding is the following formula (where |OID| denotes the number of
subidentifier of an OID):
A very rough way to estimate the size needed by a varbind that is sizeof(VarBind) = (2 + |OID|) + (2 + 2)
essentially a number is the following formula:
varbind-size = 6 + number-of-OID-subidentifier The assumption here is that every OID subidentifier encodes into a
single octet. An additional octet is needed for the OID tag and the
OID length. Since most values are 32-bit numbers, we calculate one
octet for the value tag, one octet for the value length, and 2 octets
on average for the value itself. While the BER encoding of 32-bit
unsigned numbers may require 5 octets, in general small numbers tend
to dominate due to their usage in enumerations or many error counters
staying close to zero. For sysUpTime.0 (1.3.6.1.2.1.1.3.0), we
calculate 15 octets as the typical varbind encoding size of
sysUpTime.0.
That is for sysUpTime (1.3.6.1.2.1.1.3), we get 14 bytes and thus the For the PDU sequence [RFC3416], we calculate the following:
SNMPv1 message is 34 bytes, SNMPv3/TSM is 60 bytes, and the SNMPv3/
USM message is 81 bytes. TSM may imply security overhead at the
transport layer e.g. in case of DTLS the transport layer framing
overhead is 13 bytes (compressed DTLS may further reduce the
application payload length). The details of the calculation in
section 3.2.2 are as follows:
* SNMPv3 minimum message size calculation PDU 2 octets
request-id 3 octets
error-status 3 octets
error-index 3 octets
variable-bindings 2 octets
---------
13 octets
SNMPv3Message (USM) 2 byte A PDU carrying a sysUpTime.0 varbind thus requires about 13+15 = 28
msgVersion 3 byte octets.
msgGlobalData (HeaderData) 15 byte
msgSecurityParameters 23 byte
msgData (ScopedPDU) 24 byte
-------
67 byte
SNMPv3Message (TSM) 2 byte For the ScopedPDU sequence used by SNMPv3 [RFC3412], we calculate the
msgVersion 3 byte following:
msgGlobalData (HeaderData) 15 byte
msgSecurityParameters 2 byte
msgData (ScopedPDU) 24 byte
-------
46 byte
UsmSecurityParameters 2 byte ScopedPDU 2 octets
msgAuthoritativeEngineID 7 byte contextEngineID 7 octets
msgAuthoritativeEngineBoots 3 byte contextName 2 octets
msgAuthoritativeEngineTime 3 byte PDU 13 octets
msgUserName 2 byte ---------
msgAuthenticationParameters 2 byte 24 octets
msgPrivacyParameters 2 byte
-------
21 byte
TsmSecurityParameters 2 byte A scoped PDU carrying a sysUpTime.0 varbind thus requires about 24+15
------- = 39 octets.
2 byte
HeaderData 2 byte For the HeaderData sequence used by SNMPv3 [RFC3412], we calculate
msgID 3 byte the following:
msgMaxSize 4 byte
msgFlags 3 byte
msgSecurityModel 3 byte
-------
15 byte
ScopedPDU 2 byte HeaderData 2 octets
contextEngineID 7 byte msgID 3 octets
contextName 2 byte msgMaxSize 4 octets
PDU 13 byte msgFlags 3 octets
------- msgSecurityModel 3 octets
24 byte ---------
15 octets
PDU 2 byte A.1. SNMPv3/USM Minimum Message Size
request-id 3 byte
error-status 3 byte
error-index 3 byte
variable-bindings 2 byte
-------
13 byte
* SNMPv1 / SNMPv2c minimum mesage size calculation The minimum size of an SNMPv3/USM message can be calculated as
follows:
SNMPv1Message 2 byte SNMPv3Message (USM) 2 octets
version 3 byte msgVersion 3 octets
community 2 byte msgGlobalData (HeaderData) 15 octets
data (PDU) 13 byte msgSecurityParameters 24 octets (UsmSecurityParameters)
------- msgData (ScopedPDU) 24 octets
20 byte ---------
67 octets
The details of the calculation for DTLS framing as follows: UsmSecurityParameters 2 octets
msgAuthoritativeEngineID 7 octets
msgAuthoritativeEngineBoots 3 octets
msgAuthoritativeEngineTime 3 octets
msgUserName 3 octets
msgAuthenticationParameters 2 octets
msgPrivacyParameters 2 octets
---------
22 octets
Type 1 byte A complete SNMPv3/USM message to retrieve sysUpTime.0 therefore
Version 2 byte requires 67+15 = 82 octets.
Epoch 2 byte
Sequence_number 6 byte
Length 2 byte
Appendix B. Possible Deployment Models for SNMP A.2. SNMPv3/TSM Minimum Message Size
There can be three fundamental deployment models for SNMPv3 The minimum size of an SNMPv3/TSM message can be calculated as
follows:
B.1. Lightweight End-to-End SNMPv3Message (TSM) 2 octets
msgVersion 3 octets
msgGlobalData (HeaderData) 15 octets
msgSecurityParameters 2 octets (TsmSecurityParameters)
msgData (ScopedPDU) 24 octets
---------
46 octets
The SNMP manager talks SNMPv3 end-to-end to the nodes. In this way TsmSecurityParameters 2 octets
existing management tools can be reused and a few adaptations may be ---------
needed by specifying suitable deployment parameters through an 2 octets
Applicability Statement as covered by this draft.
Manager <-------------------------------------> 6LoWPAN nodes A complete SNMPv3/TSM message to retrieve sysUpTime.0 therefore
SNMPv3 requires 46+15 = 61 octets. If the secure transport used by SNMPv3/
TSM is DTLS, then the encoded message is wrapped in a DTLS record,
which adds the following number of octets:
B.2. Proxy Model type 1 octets
version 2 octets
epoch 2 octets
sequence_number 6 octets
length 2 octets
---------
13 octets
The SNMP manager talks SNMPv3 to an SNMP proxy residing on the The size of the resulting DTLS record is 61 + 13 = 74 octets.
6LoWPAN Gateway (or a proxy server) as explained in this document.
Existing management tools (as long as they are proxy aware, which is
not generally true) can be reused.
Manager <--------> SNMP Proxy <--------------> 6LoWPAN nodes A.3. SNMPv1/SNMPv2c Minimum Message Size
SNMPv3 (6LoWPAN ER) SNMPv3
B.3. SNMP with Sub-Agent Protocols The minimum size of an SNMPv3/TSM message can be calculated as
follows (assuming a one character community string):
SNMPv1Message 2 octets
version 3 octets
community 3 octets
data (PDU) 13 octets
---------
21 octets
A complete SNMPv3/TSM message to retrieve sysUpTime.0 therefore
requires 21+15 = 36 octets. Note, however, that SNMPv1/SNMPv2c does
not provide security nor does it provide direct support for proxying.
Appendix B. Implementation and Deployment Models
There are four fundamentally different implementation / deployment
models for SNMPv3 in constrained networks.
B.1. SNMP End-to-End Model
The SNMP manager talks SNMPv3 end-to-end to the 6LoWPAN nodes. In
this model, existing management tools can be reused and only a few
adaptations may be needed by specifying suitable deployment
parameters through an applicability statement.
Manager <-----------------------------------------> 6LoWPAN
SNMPv3 nodes
The characteristics of this solution can be summarized as follows:
+ Straightforward access to individual 6LoWPAN nodes
+ Reuse of existing deployed SNMP-based tools
o End-to-end security and end-to-end key management
- Message size and potential fragmentation issues
- 6LoWPAN nodes must run an SNMP engine
- Trap-directed polling nature of SNMP has high energy costs
B.2. SNMP Proxy Model
The SNMP manager talks SNMPv3 to an SNMP proxy residing on a 6LoWPAN
edge router (ER). Existing management tools (as long as they are
proxy aware, which is not generally true) can be reused.
Manager <--------> SNMP Proxy <-----------------> 6LoWPAN
SNMPv3 (6LoWPAN ER) SNMPv3 nodes
The characteristics of this solution can be summarized as follows:
+ Alternate transport encoding can reduce message sizes
o Indirect access to individual 6LoWPAN nodes
o Reuse of existing SNMP-based tools supporting proxies
o Two security domains, different key management schemes
- 6LoWPAN nodes must run an SNMP engine
- Trap-directed polling nature of SNMP has high energy costs
B.3. SNMP Subagent Model
The SNMP manager talks SNMPv3 to an extensible SNMP agent residing on The SNMP manager talks SNMPv3 to an extensible SNMP agent residing on
the 6LoWPAN router which uses a subagent protocol (e.g. a 6LoWPAN the 6LoWPAN edge router. This agent uses a subagent protocol (e.g.,
enhanced version of AgentX, [RFC2741]) to populate its MIB. However, AgentX [RFC2741]). The current standard subagent protocol is not
the current standard subagent protocol is not suitable for 6LoWPAN necessarily suitable for 6LoWPAN networks since it assumes a reliable
since it assumes a reliable stream-oriented transport and an stream-oriented transport and an adaptation of a subagent protocol
adaptation of an existing protocol may be required. Thus, this model may be required.
is not recommended for 6LoWPANs.
Manager <-------> SNMP Agent <-----------------> 6LoWPAN nodes Manager <--------> SNMP Agent <-----------------> 6LoWPAN
SNMPv3 (6LoWPAN ER) SubAgent Protocol SNMPv3 (6LoWPAN ER) SubAgent Protocol nodes
Appendix C. Change Log The characteristics of this solution can be summarized as follows:
Changes from -01 to -02: + Alternate transport encoding can reduce message sizes
o Indirect access to individual 6LoWPAN nodes
o Reuse of existing SNMP-based tools supporting proxies
o Two security domains, different key management schemes
+ 6LoWPAN nodes must run an SNMP subagent
- Trap-directed polling nature of SNMP has high energy costs
B.4. SNMP Data-Fusion Model
The SNMP manager talks SNMPv3 to an SNMP agent residing on the
6LoWPAN edge router. This agent uses a different protocol (e.g., a
protocol such as CoAP) to retrieve information from the 6LoWPAN
network. In the ideal case, the protocol supports caching and in
network data aggregation.
Manager <--------> SNMP Agent <-----------------> 6LoWPAN
SNMPv3 (6LoWPAN ER) CoAP Data Fusion nodes
The characteristics of this solution can be summarized as follows:
+ Indirect access to individual 6LoWPAN nodes
+ Leveraging a cache-aware data fusion protocol
+ SNMP agent acting as a cache, no expensive polling
o Reuse of existing SNMP-based tools supporting contexts
o Two security domains, different key management schemes
Appendix C. Example: Contiki SNMP
Contiki-SNMP is an SNMP implementation for the Contiki operating
system, designed to run on Atmel Raven boards (8-bit microcontroller
running at 20 MHz with 16K of RAM and 128K of Flash). Contiki-SNMP
supports SNMP messages up to 484 octets length. The currently
supported message types are Get, GetNext, and Set. The currently
supported message versions are SNMPv1 and SNMPv3/USM. The
implementation provides an API to define and configure managed
objects (MIB variables). The USM implementation supports HMAC-MD5-96
and CFB128-AES-128.
If both SNMPv1 and SNMPv3 are enabled, the code uses 31220 octets of
ROM (around 24% of the available ROM) plus 235 octets of statically
allocated RAM. With only SNMPv1 enabled, the code uses 8860 octets
of ROM (around 7% of the available ROM) plus 43 bytes of statically
allocated RAM. Leveraging the AES hardware support of the 802.15.4
transceiver will significantly reduce the footprint of the SNMPv3
option.
The heap usage is not more than 910 octets for processing an SNMPv1
message. About 16 octets are used for each managed object
implemented. If a managed object is of a string-based type,
additional heap storage space is used to store the value.
The maximum observed stack usage is show in Table 1.
+---------+----------------+-----------------+
| Version | Security level | Max. stack size |
+---------+----------------+-----------------+
| SNMPv1 | - | 688 octets |
| | | |
| SNMPv3 | noAuthNoPriv | 708 octets |
| | | |
| SNMPv3 | authNoPriv | 1140 octets |
| | | |
| SNMPv3 | authPriv | 1144 octets |
+---------+----------------+-----------------+
Table 1: Maximum observed stack usage
For SNMPv3/USM noAuthNoPriv messages and SNMPv1 messages, the round-
trip latency is dominated by the data transfer tim of the 802.15.4
radio. For SNMPv3/USM authPriv messages, the processing time is
almost the same as the data transmission delay. The authNoPriv
security level is slightly faster.
Appendix D. Change Log
D.1. Changes from -02 to -03
Broadened the scope of the document to discuss SNMP on constrained
devices, not limited to 6LoWPAN networks.
1. Added a data fusion protocol scenario.
2. Reorganization of the text.
3. Reorganization of Section 2.4.
4. Addition of Appendix C.
5. Added details about minimal VACM implementation.
6. Started a discussion of relevant MIB modules.
D.2. Changes from -01 to -02
The draft now covers applicability of SNMPv3 for 6LoWPANs. The focus The draft now covers applicability of SNMPv3 for 6LoWPANs. The focus
of the draft is shifted towards supporting SNMPv3 'as is' in of the draft is shifted towards supporting SNMPv3 'as is' in
6LoWPANs. 6LoWPANs.
1. Added SNMP Agent Implentation Considerations for 6LoWPANs. 1. Added SNMP Agent Implementation Considerations for 6LoWPANs.
2. Added SNMP Manager Implentation Considerations for 6LoWPANs. 2. Added SNMP Manager Implementation Considerations for 6LoWPANs.
3. Added the Deployment Considerations for 6LoWPANs. 3. Added the Deployment Considerations for 6LoWPANs.
4. Added the Applicable MIB modules for 6LoWPANs. 4. Added the Applicable MIB modules for 6LoWPANs.
5. Moved SNMP Deployment Models to Appendix. 5. Moved SNMP Deployment Models to Appendix.
6. Removed the section on Packet Compression. 6. Removed the section on Packet Compression.
Authors' Addresses Authors' Addresses
Hamid Mukhtar (editor) Juergen Schoenwaelder (editor)
Jacobs University Bremen
Campus Ring 1
Bremen 28725
Germany
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Hamid Mukhtar
ETRI ETRI
USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu, USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu
Daejeon 305-350 Daejeon 305-350
KOREA KOREA
Phone: +82 42 860 5435 Phone: +82 42 860 5435
EMail: hamid@etri.re.kr EMail: hamid@etri.re.kr
Seong-Soon Joo Seong-Soon Joo
ETRI ETRI
USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu, USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu
Daejeon 305-350 Daejeon 305-350
KOREA KOREA
Phone: +82 42 860 6333 Phone: +82 42 860 6333
EMail: ssjoo@etri.re.kr 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
Kim, Ki Hyung Kim, Ki Hyung
Ajou University Ajou University
San 5 Wonchun-dong, Yeongtong-gu San 5 Wonchun-dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-749 Suwon-si, Gyeonggi-do 442-749
KOREA KOREA
Phone: +82 31 219 2433 Phone: +82 31 219 2433
EMail: kkim86@ajou.ac.kr EMail: kkim86@ajou.ac.kr
 End of changes. 107 change blocks. 
434 lines changed or deleted 678 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/