One document matched: draft-hamid-6lowpan-snmp-optimizations-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
XML2RFC offers an include feature described in the XML2RFC README
file. That syntax, however, contradicts the DTD requirements to
have <reference> elements within the <references> element, so an
XML parser is likely to find your XML file invalid. It may be
possible that XML2RFC will change their DTD so that the XML file
remains valid when their style of include is used.
In the meantime therefore, we use an alternative valid-XML approach
to includes, which unfortunately require that define your includes
at the beginning of the file. Since the biggest benefit of includes
is for references, this requires that your references be defined in
ENTITY clauses here before being "included" and cited elsewhere in
the file.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2741 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2741.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY rfc3412 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3412.xml">
<!ENTITY rfc3413 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3413.xml">
<!ENTITY rfc3416 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3416.xml">
<!ENTITY rfc3417 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3417.xml">
<!ENTITY rfc4498 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4498.xml">
<!ENTITY rfc4789 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4789.xml">
<!ENTITY rfc4919 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY rfc4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY rfc3584 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3584.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-hamid-6lowpan-snmp-optimizations-00.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="SNMP optimizations for 6LoWPAN">SNMP optimizations for 6LoWPAN</title>
<!-- [TODO] copy the author block as many times as needed, one for each author.-->
<!-- If the author is acting as editor, use the <role=editor> attribute-->
<!-- see RFC2223 for guidelines regarding author names -->
<author initials="H." surname="Mukhtar Ed." fullname="Hamid Mukhtar (editor)">
<organization abbrev="ETRI">ETRI</organization>
<address>
<postal>
<street>USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu,</street>
<city>Daejeon</city>
<code>305-350</code>
<country>KOREA</country>
</postal>
<phone>+82 42 860 5435</phone>
<email>hamid@etri.re.kr</email>
</address>
</author>
<author initials="S. S." surname="Joo" fullname="Seong-Soon Joo">
<organization abbrev="ETRI">ETRI</organization>
<address>
<postal>
<street>USN Research Division, ETRI, 161 Gajeong-dong, Yuseong-gu,</street>
<city>Daejeon</city>
<code>305-350</code>
<country>KOREA</country>
</postal>
<phone>+82 42 860 6333</phone>
<email>ssjoo@etri.re.kr</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
<organization abbrev="Jacobs University Bremen">Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>Bremen</city>
<code>28725</code>
<country>Germany</country>
</postal>
<phone>+49 421 200-3587</phone>
<email>j.schoenwaelder@jacobs-university.de</email>
</address>
</author>
<!-- [TODO]: month and day will be generated automatically by XML2RFC;
be sure the year is current.-->
<date year="2009" />
<!--[TODO] IETF area is optional -->
<!--<area>Operations & Management Area</area>-->
<!--[TODO] WG name at the upperleft corner of the doc,
IETF is fine for non-WG submissions -->
<workgroup>Network Working Group</workgroup>
<keyword>Network Management</keyword>
<keyword>6LoWPAN</keyword>
<!--[TODO] add additional keywords here for IETF website search engine -->
<abstract>
<t>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. </t>
<!--Remember, don't put any citations in the abstract, and expand your acronyms. -->
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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. </t>
<t>According to <xref target="RFC4919"></xref> 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) <xref target="RFC3410"></xref> 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.</t>
<t>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.</t>
</section>
<section title="Management Requirements and design goals">
<t>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.</t>
<t>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.</t>
<t>Minimum overhead: The network management framework should have a limited overhead both in terms of communication and computation. </t>
</section>
<section title="Deployment models">
<t>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. </t>
<t>There can be three fundamental deployment models for SNMPv3</t>
<section title="Lightweight End-to-End">
<t>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.</t>
<artwork align='center' type='abnf'><![CDATA[
Manager <-------------------------------------> 6LoWPAN nodes
SNMPv3
]]></artwork>
</section>
<section title="Proxy Model">
<t>The SNMP manager communicates 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 <xref target="RFC4789"></xref>. </t>
<artwork align='center' type='abnf'><![CDATA[
Manager <--------> SNMP Proxy <--------------> 6LoWPAN nodes
SNMPv3 (6LoWPAN Gateway) SNMPv3
]]></artwork>
</section>
<section title="SNMP with Sub-Agent Protocols">
<t>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, <xref target="RFC2741"></xref>) 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 an existing protocol may be required.</t>
<artwork align='center' type='abnf'><![CDATA[
Manager <-------> SNMP Agent <-----------------> 6LoWPAN nodes
SNMPv3 (6LoWPAN Gateway) SubAgent Protocol
]]></artwork>
</section>
</section>
<section title="Optimization Goals">
<t>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.</t>
<section title="Reduction of Packet size">
<t>SNMPv3 packets may be large in size due to their variable length. The message size should to be reduced in order to efficiently utilize the link bandwidth. Extra fragmentation of the management packets may also be needed to be avoided. <xref target="RFC3417"></xref> 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. <xref target="RFC4919"></xref> 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.</t>
<t>The Maximum transmission unit (MTU) for 6LoWPANs is 127 bytes <xref target="RFC4919"></xref>. 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. </t>
<t>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.</t>
<section title="Header size reduction">
<t>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.</t>
<section title="Encoding the header for compression ">
<t>The SNMPv3 header can be encoded in a way that is analogous to the IPv6 packet header encoding scheme for 6LoWPAN (LoWPAN_HC1)<xref target="RFC4944"></xref>. 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 may be constant for the whole 6LoWPAN network. </t>
</section>
<section title="Supporting minimal functionality">
<t>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.</t>
</section>
<section title="Restricting header field sizes to constant values">
<t>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. </t>
</section>
</section>
<section title="Payload size reduction">
<t>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. </t>
<section title="Payload Compression">
<t>Certain compression schemes are already proposed for SNMP payload. <xref target="I-D.draft-irtf-nmrg-SNMP-compression"></xref> 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. </t>
</section>
<section title="Managed Object Aggregation">
<t>The bandwidth and processing cost associated with accessing multiple objects is very high. Deployment of aggregation schemes may help in avoiding the redundant control data to be sent over the network. <xref target="RFC4498"></xref> 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. </t>
</section>
<section title="Lightweight Encoding">
<t>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. </t>
</section>
</section>
</section>
<section title="Reduction of Memory cost">
<t>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. </t>
<section title="Light-weight and Distributed Agent Functionality">
<t>The SNMP agent <xref target="RFC3411"></xref> in its current form may not have a low memory footprint due to comprehensive functional role. Optimizations like the implementation of only SNMPv3 messages processing subsystem for the SNMPv3 agent. Moreover, 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. </t>
</section>
<section title="Reassembly on 6LoWPAN node">
<t>Due 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.</t>
</section>
<section title="Minimal MIB support">
<t>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. </t>
</section>
</section>
<section title="Manager Considerations">
<t>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. </t>
<t>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. </t>
<t>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.</t>
<t>3. It should take into consideration the fact that extra processing such as fragmentation/re-assembly may be carried out at the 6LoWPAN Gateway. For instance, the ingress query may be parsed at the gateway and a corresponding query is generated inside the 6LoWPAN. Likewise, a response from within the 6LoWPAN terminates at the gateway and may be encapsulated inside the respective link layer for the egress network.</t>
</section>
<section title="Lightweight Protocol Operation">
<t>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. </t>
<section title="EngineID discovery">
<t>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. </t>
</section>
<section title="Security">
<t>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 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. </t>
</section>
<section title="Access control">
<t>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. </t>
</section>
</section>
</section>
<section title="Conclusion">
<t>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. </t>
</section>
<section title="IANA Consideration">
<t>
TBD.
</t>
</section>
<section title="Security Considerations">
<t>
TBD.
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- end of normative references that are required only to support this template;
Remove from the final document. -->
<!-- start of normative references that are required to support mIB module boilerplate text. -->
&rfc2119;
&rfc3411;
&rfc3412;
&rfc3413;
&rfc3416;
&rfc3417;
&rfc4789;
&rfc4944;
<!-- end of references that are required to support the boilerplate text. -->
<!-- [TODO]: start of normative references samples. Replace with your own. -->
<!-- end of normative references samples. -->
</references>
<references title="Informative References">
<!-- start of informative references that are required to support the boilerplate text. -->
&rfc3410;
&rfc2741;
&rfc3584;
&rfc4498;
&rfc4919;
<reference anchor="IEEE802.15.4">
<front>
<title>Wireless medium access control and physical layer specifications for low-rate wireless personal area networks.</title>
<author initials="IEEE Standard" surname="802.15.4-2003" fullname="IEEE Standard, 802.15.4-2003">
<organization>IEEE Standard, 802.15.4-2003</organization>
</author>
<date year="2003" month="May" />
</front>
</reference>
<reference anchor="I-D.draft-irtf-nmrg-SNMP-compression">
<front>
<title>SNMP Payload Compression</title>
<author initials="J." surname="Schoenwaelder">
</author>
<date year="2001" month="April" />
<seriesInfo name="RFC" value="2578" />
</front>
</reference>
<!-- end of informative references that are required to support the boilerplate text. -->
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 01:49:21 |