[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                     H. Mukhtar Ed.
Internet-Draft                                                    S. Joo
Intended status: Informational                                      ETRI
Expires: April 24, 2010                                 J. Schoenwaelder
                                                Jacobs University Bremen
                                                                  K. Kim
                                                         Ajou University
                                                        October 21, 2009


                     SNMP optimizations for 6LoWPAN
             draft-hamid-6lowpan-snmp-optimizations-02.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 April 24, 2010.

Copyright Notice




Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 1]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


   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

   Simple Network Management Protocol (SNMP) is a widely deployed
   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].



























Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 2]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Why SNMP . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Little-known SNMP Features . . . . . . . . . . . . . . . . . .  5
     2.1.  SNMP Contexts  . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  SNMP Proxies . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Message Size Restrictions  . . . . . . . . . . . . . . . .  5
   3.  SNMP Agent Implementation Considerations . . . . . . . . . . .  6
     3.1.  Access Control . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Overhead of the Different SNMP Message Formats . . . . . .  6
       3.2.1.  Overhead Difference of SNMPv3 Security . . . . . . . .  6
       3.2.2.  Minimum Message Size Calculation . . . . . . . . . . .  7
   4.  SNMP Manager Implementation Considerations . . . . . . . . . .  7
     4.1.  Polling, Pushing, and Trap-directed Polling  . . . . . . .  8
     4.2.  Support for SNMP Proxies . . . . . . . . . . . . . . . . .  8
   5.  SNMP Deployment Considerations . . . . . . . . . . . . . . . .  8
     5.1.  Naming Issues  . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  SNMP Protocol Operations . . . . . . . . . . . . . . . . .  9
     5.3.  Timeouts and Retransmissions . . . . . . . . . . . . . . .  9
     5.4.  Polling Intervals  . . . . . . . . . . . . . . . . . . . .  9
     5.5.  Caching Issues . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Applicable MIB Modules . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Applicable Standardized MIBs . . . . . . . . . . . . . . . 10
     6.2.  MIB Design Guidelines for Low Overhead . . . . . . . . . . 10
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Calculation of Minimum packet size  . . . . . . . . . 13
   Appendix B.  Possible Deployment Models for SNMP . . . . . . . . . 15
     B.1.  Lightweight End-to-End . . . . . . . . . . . . . . . . . . 15
     B.2.  Proxy Model  . . . . . . . . . . . . . . . . . . . . . . . 15
     B.3.  SNMP with Sub-Agent Protocols  . . . . . . . . . . . . . . 16
   Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 16













Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 3]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


1.  Introduction

   Simple Network Management Protocol (SNMP) is a UDP-based protocol
   operating in the application layer of the Internet Protocol Suite.
   It consists of four basic components: a managed node running an
   agent; an entity running management applications (typically called as
   a manager); a protocol to convey information between the SNMP
   entities; and management information.

1.1.  Why SNMP

   SNMP is datagram-oriented and the implementations of SNMP can be very
   lightweight.  It may fit 6LoWPAN applications very well.  The
   following features make SNMP suitable for this network.

   - Protocol Maturity: SNMPv3 is a full IETF standard having a high
   degree of technical maturity with significant experiences in
   implementation and operation.

   - Data Naming: SNMP provides a hierarchical namespace utilizing
   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
   one of the goals for 6LoWPANs, wherein it is described that network
   management functionality is critical for 6LoWPANs.  SNMP is widely
   used for network management and it is the Internet community's de
   facto management protocol.

   - Data Retrieval: SNMP employs polling 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.

   - Security: SNMPv3 can provide both message-level and transport-level
   security.  SNMPv3 defines User based Security model (USM) for
   message-driven security; and transport-based security model (TSM) 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.




Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 4]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


   - Access control: SNMP can provide access control of the information.

2.  Little-known SNMP Features

   This section explains some little-known SNMP concepts.

2.1.  SNMP Contexts

   Each SNMP entity is composed of a single engine which is identified
   by an SNMP engine identifier.  A context is a collection of
   management information accessible by an SNMP entity and it is also
   defined as a subset of a single SNMP entity.  An SNMP entity has
   access to one or more contexts uniquely identified by context names.
   In order to identify an individual item of management information
   within the management domain, the SNMP entity's context is identified
   first (using the engine identifier and context name) and this is
   followed by the object type and instance.

2.2.  SNMP Proxies

   The term 'proxy' in SNMP has a restrictive meaning.  A proxy refers
   to a proxy forwarder application which forwards SNMP messages to
   other SNMP engines and forwards the response to such previously
   forwarded messages back to SNMP engine from which the original
   message was received [RFC3413].  The forwarding is based on contexts
   and it is irrespective of the management objects being accessed.
   Thus, an SNMP proxy can be used to forward messages from one
   transport to another, or to translate SNMP messages from one version
   to another version.

   The SNMP proxy cannot be used for translation of SNMP requests into
   operations of a non-SNMP management protocol and it cannot be used
   for supporting aggregated objects.  Proxies depend on context
   information and the forwarding of messages is independent of the
   objects being accessed.  To support aggregated objects, where the
   value of one object depends upon multiple other remote items, special
   MIB modules and sub-agent protocols are used instead of proxies.

2.3.  Message Size Restrictions

   SNMP message contains a msgMaxSize field which is used to communicate
   the maximum message size at the sender and the receiver side.  The
   maximum message size is the maximum size of a message that can be
   accepted by the receiving entity.

   The minimum required to implement message size is transport model
   specific.  For SNMP over UDP, the size is 484 octets.




Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 5]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


3.  SNMP Agent Implementation Considerations

   This section covers SNMP agent implementation considerations for
   6LoWPAN.

3.1.  Access Control

   The Local Configuration Datastore (LCD), which contains access rights
   and policies of an SNMP entity, need not be configured remotely.  It
   is recommended to have permanent access control tables on the nodes.
   The implementers should keep the authorization tables as compact as
   possible to reduce the memory and codesize overhead.  Compact
   permanent authorization tables on the nodes can for example provide
   read-only and read-write access to the management instrumentation on
   the node at almost zero processing cost since the SNMP agents may not
   support instance level access control granularity to further reduce
   performance cost.

3.2.  Overhead of the Different SNMP Message Formats

   SNMPv1 [RFC1157] is the earliest version of SNMP and it reached the
   IETF full standard status.  The protocol operation consisted of Get,
   Get-Next, and Trap Operations for data retrieval and the Set
   operation for configuration.  SNMPv1 security is based on community
   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
   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].

3.2.1.  Overhead Difference of SNMPv3 Security

   SNMP security can be supported by two different approaches, i.e.,
   message-driven security and transport-driven security.  With message-
   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).



Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 6]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


   The User-based Security Model [RFC3414] is a shared secret scheme
   which uses message-driven security.  Although it utilizes existing
   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
   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
   considered for 6LoWPAN.  [I-D.draft-ietf-isms-dtls-tm] specifies how
   DTLS can be used with SNMP.  Transport Model for DTLS 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 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

   The minimum message size for SNMPv3 with USM is 67 bytes whereas the
   minimum message size for SNMPv3 with TSM is 46 bytes.  The minimum
   message size for the historic SNMPv1 message is 20 byte.  The details
   of the calculation can be found in Appendix A.  TSM may involve
   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

   This section covers SNMP manager implementation considerations for
   6LoWPAN.







Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 7]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


4.1.  Polling, Pushing, and Trap-directed Polling

   In Sensor networks, polling can be reactive or proactive.  Data
   gathering or event reporting sensors may 'push' their information
   towards the managers or they may wait for a manager to 'pull' the
   information through a request.

   When the demand for data is relatively high, push mechanisms are
   deployed in order to save energy cost where the data flows from
   managed entities towards the managers.  SNMP notifications are a
   realization the push based model in which data is sent to the manager
   without a prior request.  Data can be reported periodically from the
   SNMP agent to the manager through SNMP notifications and the
   notifications can take the advantage of SNMP security and access
   control features to ensure the access to legitimate users along with
   confidentiality and integrity of the data.  The SNMP Inform PDU
   requires a response back from the receiving manager and it can be
   used in applications in which reliability is important.

   The use of notifications is recommended for data flows from sensors
   to the manager and also for the scenarios where multiple nodes
   generate the same information.

4.2.  Support for SNMP Proxies

   The SNMP proxy forwarder application resides on an intermediate SNMP
   entity (e.g. an SNMP entity on a management server or an edge router
   in case of 6LoWPAN).  The proxy forwarder registers each context to
   which it wishes to forward messages.  After the remote context is
   registered, the managers send messages to the proxy forwarder's
   engine with the context information of the remote host.  The proxy
   forwarder forwards the message to the remote context.  Upon reception
   of a response from the remote host, it forwards the response back to
   the manager.

   In 6LoWPAN networks proxies may be used to change message encoding,
   or they may be used to translate between SNMP versions, or they may
   be used to change the security domain at the 6LoWPAN side of the
   network.

5.  SNMP Deployment Considerations

   Following are a list of considerations for deployment of SNMP in
   6LoWPANs.







Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 8]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


5.1.  Naming Issues

   In order to reduce the message overhead, the managers are advised to
   use short values for Engine Identifiers.  The minimum length for an
   Engine Identifier is 5 octets.  The managers may generate and assign
   the Engine identifiers using the 16-bit short address or the 64-bit
   IEEE EUI-64 addresses of a node.  Context name is an administratively
   assigned octet string that names a context.  In order to reduce the
   message size overhead the length of the string should be kept short.
   The default context is identified by a a zero-length context name.

5.2.  SNMP Protocol Operations

   SNMP supports four basic data retrieval operations i.e.  GetRequest-
   PDU, GetNextRequest-PDU, GetBulkRequest-PDU [RFC3416].  The
   GetRequest-PDU is useful for retrieving well known scalar data,
   whereas the GetNextRequest-PDU and GetBulkRequest-PDU operations are
   particularly advantageous for retrieving dynamically changing tabular
   data.  The SNMPv2-Trap-PDU and InformRequest-PDU can be used for
   push-based data retrieval, in which periodic or event-based
   notifications are sent to the managers.

   During the processing of a GetBulkRequest-PDU operation, the agent
   can decide the number of objects to include in response.  For
   requesting objects the manager has to consider the underlying packet
   size constraints.  Also, the number of objects in the variable-
   binding in request messages and max-repeaters field of GetBulk
   operation should be selected keeping the constraint in mind.

5.3.  Timeouts and Retransmissions

   In 6LoWPANs, the SNMP message may be fragmented or may encounter more
   latency because of underlying wireless link.  The value of timeouts
   should be adjusted on the manager side by considering the link
   characteristics so that SNMP does not timeout between queries.  In
   some cases the number of retries may also be adjusted to cater for
   link characteristics.

5.4.  Polling Intervals

   Similarly, in order to reduce the amount of polling, the polling
   interval should be increased for less time critical data. 6LoWPANs
   are energy constrained networks and excessive polling is not
   recommended.







Mukhtar Ed., et al.      Expires April 24, 2010                 [Page 9]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


5.5.  Caching Issues

   Caching the important information can save the transmission cost e.g.
   caching the snmpEngineID would save the traffic overhead of EngineID
   discovery mechanisms.  It is recommended that the EngineID should be
   cached in order to reduce the transmission cost.  In case of TSM,
   caching the transport parameters can reduce the message sizes.

6.  Applicable MIB Modules

   This section describes some relevant MIB modules which can be used in
   6LoWPAN.

6.1.  Applicable Standardized MIBs

   ENTITY-SENSOR-MIB [RFC3433] defines objects for information that is
   associated with physical sensors (e.g. the current value of the
   sensor, operational status, and the data units precision associated
   with the sensor).  It can be reused for 6LoWPANs.  Other applicable
   MIB modules are TBD.

6.2.  MIB Design Guidelines for Low Overhead

   When defining MIB modules, the MIB designers should avoid using long
   OIDs by avoiding unnecessary data hierarchies.  Moreover, complex
   indexing schemes should be avoided in order to keep the overhead
   resulting from instance identifiers as low as possible.

7.  Conclusion

   SNMP can be very useful for 6LoWPANs due to its significant
   implementation and operational experiences.  The standards allow for
   memory and CPU efficient implementations.  The utilization of secure
   transports such as DTLS can reduce the overhead of message-based
   security mechanisms.  This document explored the applicability of
   SNMP for its use in 6LoWPAN.

8.  IANA Consideration

   TBD.

9.  Security Considerations

   TBD.







Mukhtar Ed., et al.      Expires April 24, 2010                [Page 10]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


10.  Acknowledgments

   TBD.

11.  References

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

   [RFC3414]                      Blumenthal, U. and B. Wijnen, "User-
                                  based Security Model (USM) for version
                                  3 of the Simple Network Management
                                  Protocol (SNMPv3)", STD 62, RFC 3414,
                                  December 2002.

   [RFC3415]                      Wijnen, B., Presuhn, R., and K.
                                  McCloghrie, "View-based Access Control
                                  Model (VACM) for the Simple Network
                                  Management Protocol (SNMP)", STD 62,
                                  RFC 3415, 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



Mukhtar Ed., et al.      Expires April 24, 2010                [Page 11]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


                                  the Simple Network Management Protocol
                                  (SNMP)", STD 62, RFC 3417,
                                  December 2002.

   [RFC3418]                      Presuhn, R., "Management Information
                                  Base (MIB) for the Simple Network
                                  Management Protocol (SNMP)", STD 62,
                                  RFC 3418, December 2002.

   [RFC4944]                      Montenegro, G., Kushalnagar, N., Hui,
                                  J., and D. Culler, "Transmission of
                                  IPv6 Packets over IEEE 802.15.4
                                  Networks", RFC 4944, September 2007.

   [RFC5590]                      Harrington, D. and J. Schoenwaelder,
                                  "Transport Subsystem for the Simple
                                  Network Management Protocol (SNMP)",
                                  RFC 5590, June 2009.

   [RFC5591]                      Harrington, D. and W. Hardaker,
                                  "Transport Security Model for the
                                  Simple Network Management Protocol
                                  (SNMP)", RFC 5591, June 2009.

   [RFC3433]                      Bierman, A., Romascanu, D., and K.
                                  Norseth, "Entity Sensor Management
                                  Information Base", RFC 3433,
                                  December 2002.

   [RFC1157]                      Case, J., Fedor, M., Schoffstall, M.,
                                  and J. Davin, "Simple Network
                                  Management Protocol (SNMP)", STD 15,
                                  RFC 1157, May 1990.

   [I-D.draft-ietf-isms-dtls-tm]  Hardaker, W., "Transport Layer
                                  Security Transport Model for SNMP",
                                  September 2009.

11.2.  Informative References

   [RFC3410]                      Case, J., Mundy, R., Partain, D., and
                                  B. Stewart, "Introduction and
                                  Applicability Statements for Internet-
                                  Standard Management Framework",
                                  RFC 3410, December 2002.

   [RFC2741]                      Daniele, M., Wijnen, B., Ellison, M.,
                                  and D. Francisco, "Agent Extensibility



Mukhtar Ed., et al.      Expires April 24, 2010                [Page 12]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


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

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

   [RFC5246]                      Dierks, T. and E. Rescorla, "The
                                  Transport Layer Security (TLS)
                                  Protocol Version 1.2", RFC 5246,
                                  August 2008.

   [RFC4347]                      Rescorla, E. and N. Modadugu,
                                  "Datagram Transport Layer Security",
                                  RFC 4347, April 2006.

   [RFC4251]                      Ylonen, T. and C. Lonvick, "The Secure
                                  Shell (SSH) Protocol Architecture",
                                  RFC 4251, January 2006.

   [RFC4789]                      Schoenwaelder, J. and T. Jeffree,
                                  "Simple Network Management Protocol
                                  (SNMP) over IEEE 802 Networks",
                                  RFC 4789, November 2006.

Appendix A.  Calculation of Minimum packet size

   A very rough way to estimate the size needed by a varbind that is
   essentially a number is the following formula:

   varbind-size = 6 + number-of-OID-subidentifier

   That is for sysUpTime (1.3.6.1.2.1.1.3), we get 14 bytes and thus the
   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



Mukhtar Ed., et al.      Expires April 24, 2010                [Page 13]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


   section 3.2.2 are as follows:


   * SNMPv3 minimum message size calculation

   SNMPv3Message (USM)             2 byte
    msgVersion                    3 byte
    msgGlobalData (HeaderData)   15 byte
    msgSecurityParameters        23 byte
    msgData (ScopedPDU)          24 byte
                                 -------
                                 67 byte

   SNMPv3Message (TSM)             2 byte
    msgVersion                    3 byte
    msgGlobalData (HeaderData)   15 byte
    msgSecurityParameters         2 byte
    msgData (ScopedPDU)          24 byte
                                 -------
                                 46 byte

   UsmSecurityParameters           2 byte
    msgAuthoritativeEngineID      7 byte
    msgAuthoritativeEngineBoots   3 byte
    msgAuthoritativeEngineTime    3 byte
    msgUserName                   2 byte
    msgAuthenticationParameters   2 byte
    msgPrivacyParameters          2 byte
                                 -------
                                 21 byte

   TsmSecurityParameters           2 byte
                                 -------
                                  2 byte

   HeaderData                      2 byte
    msgID                         3 byte
    msgMaxSize                    4 byte
    msgFlags                      3 byte
    msgSecurityModel              3 byte
                                 -------
                                 15 byte

   ScopedPDU                       2 byte
    contextEngineID               7 byte
    contextName                   2 byte
    PDU                          13 byte
                                 -------



Mukhtar Ed., et al.      Expires April 24, 2010                [Page 14]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


                                 24 byte

   PDU                             2 byte
    request-id                    3 byte
    error-status                  3 byte
    error-index                   3 byte
    variable-bindings             2 byte
                                 -------
                                 13 byte

   * SNMPv1 / SNMPv2c minimum mesage size calculation

   SNMPv1Message                   2 byte
    version                       3 byte
    community                     2 byte
    data (PDU)                   13 byte
                                 -------
                                 20 byte

   The details of the calculation for DTLS framing as follows:

           Type                  1 byte
           Version               2 byte
           Epoch                 2 byte
           Sequence_number       6 byte
           Length                2 byte

Appendix B.  Possible Deployment Models for SNMP

   There can be three fundamental deployment models for SNMPv3

B.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 as covered by this draft.

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

B.2.  Proxy Model

   The SNMP manager talks SNMPv3 to an SNMP proxy residing on the
   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.




Mukhtar Ed., et al.      Expires April 24, 2010                [Page 15]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


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

B.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.  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.  Thus, this model
   is not recommended for 6LoWPANs.

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

Appendix C.  Change Log

   Changes from -01 to -02:

   The draft now covers applicability of SNMPv3 for 6LoWPANs.  The focus
   of the draft is shifted towards supporting SNMPv3 'as is' in
   6LoWPANs.

   1.  Added SNMP Agent Implentation Considerations for 6LoWPANs.

   2.  Added SNMP Manager Implentation Considerations for 6LoWPANs.

   3.  Added the Deployment Considerations for 6LoWPANs.

   4.  Added the Applicable MIB modules for 6LoWPANs.

   5.  Moved SNMP Deployment Models to Appendix.

   6.  Removed the section on Packet Compression.

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





Mukhtar Ed., et al.      Expires April 24, 2010                [Page 16]


Internet-Draft       SNMP optimizations for 6LoWPAN         October 2009


   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


   Kim, Ki Hyung
   Ajou University
   San 5 Wonchun-dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  442-749
   KOREA

   Phone: +82 31 219 2433
   EMail: kkim86@ajou.ac.kr























Mukhtar Ed., et al.      Expires April 24, 2010                [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/