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

Versions: 00 01 02 03

Network Working Group                                     H. Mukhtar Ed.
Internet-Draft                                                    S. Joo
Intended status: Standards Track                                    ETRI
Expires: October 5, 2009                                J. Schoenwaelder
                                                Jacobs University Bremen
                                                           April 3, 2009


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

Status of This Memo

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

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

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

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

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

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

Copyright Notice

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



Mukhtar Ed., et al.      Expires October 5, 2009                [Page 1]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


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

Abstract

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

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

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




Mukhtar Ed., et al.      Expires October 5, 2009                [Page 2]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


1.  Introduction

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

   According to [RFC4919] network management is one of the goals for
   6LoWPANs, wherein it is described that network management
   functionality is critical for 6LoWPANs.  An intuitive approach is to
   use Simple Network Management Protocol (SNMP) [RFC3410] that is
   widely used for management and monitoring of IP networks.  However,
   due to the aforementioned constraints, an investigation is required
   to determine the usability of the latest version of SNMP,
   specifically SNMPv3, or an appropriate adaptation of it.

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

2.  Management Requirements and design goals

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

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



Mukhtar Ed., et al.      Expires October 5, 2009                [Page 3]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


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

3.  Deployment models

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

   There can be three fundamental deployment models for SNMPv3

3.1.  Lightweight End-to-End

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

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

3.2.  Proxy Model

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

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

3.3.  SNMP with Sub-Agent Protocols

   The SNMP manager talks SNMPv3 to an extensible SNMP agent residing on
   the 6LoWPAN router which uses a subagent protocol (e.g. a 6LoWPAN
   enhanced version of AgentX, [RFC2741]) to populate its MIB.  In this
   scenario, 6LoWPAN adaptation layer may not actually be needed since
   such subagent protocol can run directly over 802.15.4.  However, the
   current standard subagent protocol is not suitable for 6LoWPAN since
   it assumes a reliable stream-oriented transport and an adaptation of



Mukhtar Ed., et al.      Expires October 5, 2009                [Page 4]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


   an existing protocol may be required.

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

4.  Optimization Goals

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

4.1.  Reduction of Packet size

   SNMPv3 packets may be large in size, for a single 6LoWPAN payload,
   due to their variable length.  The message size should be reduced in
   order to efficiently utilize the link bandwidth.  Extra fragmentation
   of the management packets may also be needed to be avoided.
   [RFC3417] for transport mappings of SNMP messages states that an SNMP
   entity must be capable to accept messages up to and including 484
   octets in size.  Hence SNMPv3 packets cannot be carried into a single
   6LoWPAN payload and fragmentation/reassembly may be required.
   [RFC4919] states that adding all layers for IP connectivity should
   still allow transmission in one frame, without incurring excessive
   fragmentation and reassembly.  It further states that protocols must
   be designed or chosen so that the individual "control/protocol
   packets" fit within a single 802.15.4 frame.  Therefore, Header and
   payload compression techniques may be considered in order to
   accomplish this.

   The Maximum transmission unit (MTU) for 6LoWPANs is 127 bytes
   [RFC4919].  In the worst case UDP can carry 33 octets of data over
   it.  In the best case, about 86 bytes can be carried over UDP with
   6LoWPAN_HC1 IPv6 header encoding and HC_UDP transport header
   encodings with AES-CCM-32 for Link-layer security.

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

4.1.1.  Header size reduction

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




Mukhtar Ed., et al.      Expires October 5, 2009                [Page 5]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


4.1.1.1.  Encoding the header for compression

   The SNMPv3 header can be encoded in a way that is analogous to the
   IPv6 packet header encoding scheme for 6LoWPAN (LoWPAN_HC1)[RFC4944].
   Some header fields may be elided or their length may be restricted
   according to the characteristics of 6LoWPANs.  E.g. the MsgMaxSize
   field of SNMPv3 header can be elided with such a scheme because it is
   constant for the whole 6LoWPAN network.

4.1.1.2.  Supporting minimal functionality

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

4.1.1.3.  Restricting header field sizes to constant values

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

4.1.2.  Payload size reduction

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

4.1.2.1.  Payload Compression

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

4.1.2.2.  Managed Object Aggregation

   The bandwidth and processing cost associated with accessing multiple
   objects is very high.  Deployment of aggregation schemes may help in



Mukhtar Ed., et al.      Expires October 5, 2009                [Page 6]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


   avoiding the redundant control data to be sent over the network.
   [RFC4498] defined some schemes for object aggregation which may be
   used for this purpose.  An alternate new aggregation technique may
   equally be defined to serve the purpose.

4.1.2.3.  Lightweight Encoding

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

4.2.  Reduction of Memory cost

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

4.2.1.  Light-weight and Distributed Agent Functionality

   The SNMP agent [RFC3411] in its current form may not have a low
   memory footprint due to comprehensive functional role.  The agent
   functionality may be distributed across the 6LoWPAN nodes within the
   network.  Additionally, when, where and how much security and
   authentication options should be used, all may form effective yet
   lightweight equivalents of rigid SNMPv3 implementations.

4.2.2.  Reassembly on 6LoWPAN node

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







Mukhtar Ed., et al.      Expires October 5, 2009                [Page 7]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


4.2.3.  Minimal MIB support

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

4.3.  Manager Considerations

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

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

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

4.4.  Lightweight Protocol Operation

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

4.4.1.  EngineID discovery

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

4.4.2.  Security

   The current SNMPv3 security protocols may tend to be heavy for
   6LoWPAN networks.  We need to examine if the use of SNMPv3 User-based
   Security Model (USM), Transport Security Model (TSM), or Community
   based security Model can be made feasible for 6LoWPANs.  Moreover, we
   need to examine that the security model fulfills the management data



Mukhtar Ed., et al.      Expires October 5, 2009                [Page 8]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


   security needs of 6LoWPANs.  We also need to analyze if the lower
   layer security protocols may be outsourced or relegated to other
   protocols and are reused only when needed for SNMP security.  An
   analysis has to be done on how data integrity, source authenticity
   and confidentiality be supported and which security features can be
   reused.

4.4.3.  Access control

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

5.  Conclusion

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

6.  IANA Consideration

   TBD.

7.  Security Considerations

   TBD.

8.  Acknowledgments

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

9.  References

9.1.  Normative References

   [RFC2119]                               Bradner, S., "Key words for
                                           use in RFCs to Indicate
                                           Requirement Levels", BCP 14,
                                           RFC 2119, March 1997.

   [RFC3411]                               Harrington, D., Presuhn, R.,
                                           and B. Wijnen, "An
                                           Architecture for Describing
                                           Simple Network Management



Mukhtar Ed., et al.      Expires October 5, 2009                [Page 9]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


                                           Protocol (SNMP) Management
                                           Frameworks", STD 62,
                                           RFC 3411, December 2002.

   [RFC3412]                               Case, J., Harrington, D.,
                                           Presuhn, R., and B. Wijnen,
                                           "Message Processing and
                                           Dispatching for the Simple
                                           Network Management Protocol
                                           (SNMP)", STD 62, RFC 3412,
                                           December 2002.

   [RFC3413]                               Levi, D., Meyer, P., and B.
                                           Stewart, "Simple Network
                                           Management Protocol (SNMP)
                                           Applications", STD 62,
                                           RFC 3413, December 2002.

   [RFC3416]                               Presuhn, R., "Version 2 of
                                           the Protocol Operations for
                                           the Simple Network Management
                                           Protocol (SNMP)", STD 62,
                                           RFC 3416, December 2002.

   [RFC3417]                               Presuhn, R., "Transport
                                           Mappings for the Simple
                                           Network Management Protocol
                                           (SNMP)", STD 62, RFC 3417,
                                           December 2002.

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

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

9.2.  Informative References

   [RFC3410]                               Case, J., Mundy, R., Partain,
                                           D., and B. Stewart,
                                           "Introduction and
                                           Applicability Statements for



Mukhtar Ed., et al.      Expires October 5, 2009               [Page 10]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


                                           Internet-Standard Management
                                           Framework", RFC 3410,
                                           December 2002.

   [RFC2741]                               Daniele, M., Wijnen, B.,
                                           Ellison, M., and D.
                                           Francisco, "Agent
                                           Extensibility (AgentX)
                                           Protocol Version 1",
                                           RFC 2741, January 2000.

   [RFC3584]                               Frye, R., Levi, D., Routhier,
                                           S., and B. Wijnen,
                                           "Coexistence between Version
                                           1, Version 2, and Version 3
                                           of the Internet-standard
                                           Network Management
                                           Framework", BCP 74, RFC 3584,
                                           August 2003.

   [RFC4498]                               Keeni, G., "The Managed
                                           Object Aggregation MIB",
                                           RFC 4498, May 2006.

   [RFC4919]                               Kushalnagar, N., Montenegro,
                                           G., and C. Schumacher, "IPv6
                                           over Low-Power Wireless
                                           Personal Area Networks
                                           (6LoWPANs): Overview,
                                           Assumptions, Problem
                                           Statement, and Goals",
                                           RFC 4919, August 2007.

   [IEEE802.15.4]                          802.15.4-2003, IEEE
                                           Standard., "Wireless medium
                                           access control and physical
                                           layer specifications for low-
                                           rate wireless personal area
                                           networks.", May 2003.

   [I-D.draft-irtf-nmrg-SNMP-compression]  Schoenwaelder, J., "SNMP
                                           Payload Compression",
                                           April 2001.








Mukhtar Ed., et al.      Expires October 5, 2009               [Page 11]


Internet-Draft       SNMP optimizations for 6LoWPAN           April 2009


Authors' Addresses

   Hamid Mukhtar (editor)
   ETRI
   USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu,
   Daejeon  305-350
   KOREA

   Phone: +82 42 860 5435
   EMail: hamid@etri.re.kr


   Seong-Soon Joo
   ETRI
   USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu,
   Daejeon  305-350
   KOREA

   Phone: +82 42 860 6333
   EMail: ssjoo@etri.re.kr


   Juergen Schoenwaelder
   Jacobs University Bremen
   Campus Ring 1
   Bremen  28725
   Germany

   Phone: +49 421 200-3587
   EMail: j.schoenwaelder@jacobs-university.de





















Mukhtar Ed., et al.      Expires October 5, 2009               [Page 12]


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