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]