One document matched: draft-hamid-6lowpan-snmp-optimizations-02.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 rfc3414 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3414.xml">
<!ENTITY rfc3415 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3415.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 rfc3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.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 rfc5590 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5590.xml">
<!ENTITY rfc5591 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5591.xml">
<!ENTITY rfc3433 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3433.xml">
<!ENTITY rfc1157 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1157.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
<!ENTITY rfc4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY rfc4789 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4789.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="info" docName="draft-hamid-6lowpan-snmp-optimizations-02.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>
<author fullname="Kim, Ki Hyung" initials="K"
surname="Kim">
<organization>Ajou University</organization>
<address>
<postal>
<street>San 5 Wonchun-dong, Yeongtong-gu</street>
<city>Suwon-si, Gyeonggi-do 442-749</city>
<country>KOREA</country>
</postal>
<phone>+82 31 219 2433</phone>
<email>kkim86@ajou.ac.kr</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>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.</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>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.</t>
<section title="Why SNMP">
<t>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.</t>
<t>- Protocol Maturity: SNMPv3 is a full IETF standard having a high degree of technical maturity with significant experiences in implementation and operation.</t>
<t>- 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.</t>
<t>- Network Management: 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. SNMP is widely used for network management and it is the Internet community's de facto management protocol. </t>
<t>- 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.</t>
<t>- 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) <xref target="RFC5246"></xref> and the Datagram Transport Layer Security (DTLS) Protocol <xref target="RFC4347"></xref> with SNMPv3. The modular design of SNMPv3 also allows new security and access control protocols to be added to it.</t>
<t>- Access control: SNMP can provide access control of the information.</t>
</section>
</section>
<section title="Little-known SNMP Features">
<t>This section explains some little-known SNMP concepts. </t>
<section title="SNMP Contexts">
<t>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. </t>
</section>
<section title="SNMP Proxies">
<t>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 <xref target="RFC3413"></xref>. 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. </t>
<t>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.</t>
</section>
<section title="Message Size Restrictions">
<t>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. </t>
<t>The minimum required to implement message size is transport model specific. For SNMP over UDP, the size is 484 octets.</t>
</section>
</section>
<section title="SNMP Agent Implementation Considerations">
<t>This section covers SNMP agent implementation considerations for 6LoWPAN.</t>
<section title="Access Control">
<t>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. </t>
</section>
<section title="Overhead of the Different SNMP Message Formats">
<t>SNMPv1 <xref target="RFC1157"></xref> 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.</t>
<t>SNMPv3, Std 62 <xref target="RFC3411"></xref>-<xref target="RFC3418"></xref>, 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 <xref target="RFC3584"></xref>. </t>
<section title="Overhead Difference of SNMPv3 Security">
<t>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).</t>
<t>The User-based Security Model <xref target="RFC3414"></xref> 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.</t>
<t>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) <xref target="RFC5246"></xref>, Datagram Transport Layer Security (DTLS) Protocol <xref target="RFC4347"></xref>, and the Secure Shell (SSH) Protocol <xref target="RFC4251"></xref>. </t>
<t>In transport-driven protocols DTLS, which is UDP based, can be considered for 6LoWPAN. <xref target="I-D.draft-ietf-isms-dtls-tm"></xref> 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. </t>
</section>
<section title="Minimum Message Size Calculation">
<t>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.</t>
</section>
</section>
</section>
<section title="SNMP Manager Implementation Considerations">
<t>This section covers SNMP manager implementation considerations for 6LoWPAN.</t>
<section title="Polling, Pushing, and Trap-directed Polling ">
<t>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. </t>
<t>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. </t>
<t>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.</t>
</section>
<section title="Support for SNMP Proxies">
<t>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.</t>
<t>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. </t>
</section>
</section>
<section title="SNMP Deployment Considerations">
<t>Following are a list of considerations for deployment of SNMP in 6LoWPANs.</t>
<section title="Naming Issues">
<t> 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.</t>
</section>
<section title="SNMP Protocol Operations ">
<t>SNMP supports four basic data retrieval operations i.e. GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU <xref target="RFC3416"></xref>. 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. </t>
<t>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. </t>
</section>
<section title="Timeouts and Retransmissions">
<t>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.</t>
</section>
<section title="Polling Intervals">
<t>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.</t>
</section>
<section title="Caching Issues">
<t>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. </t>
</section>
</section>
<section title="Applicable MIB Modules">
<t>This section describes some relevant MIB modules which can be used in 6LoWPAN.</t>
<section title="Applicable Standardized MIBs">
<t>ENTITY-SENSOR-MIB <xref target="RFC3433"></xref> 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.</t>
</section>
<section title="MIB Design Guidelines for Low Overhead">
<t>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.</t>
</section>
</section>
<section title="Conclusion">
<t>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.</t>
</section>
<section title="IANA Consideration">
<t>
TBD.
</t>
</section>
<section title="Security Considerations">
<t>
TBD.
</t>
</section>
<section title="Acknowledgments">
<t>
TBD.
</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;
&rfc3414;
&rfc3415;
&rfc3416;
&rfc3417;
&rfc3418;
&rfc4944;
&rfc5590;
&rfc5591;
&rfc3433;
&rfc1157;
<reference anchor="I-D.draft-ietf-isms-dtls-tm">
<front>
<title>Transport Layer Security Transport Model for SNMP</title>
<author initials="W." surname="Hardaker">
</author>
<date year="2009" month="September" />
</front>
</reference>
<!-- 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;
&rfc5246;
&rfc4347;
&rfc4251;
&rfc4789;
<!-- end of informative references that are required to support the boilerplate text. -->
</references>
<section title="Calculation of Minimum packet size">
<t>A very rough way to estimate the size needed by a varbind that is essentially a number is the following formula:</t>
<t> varbind-size = 6 + number-of-OID-subidentifier</t>
<t>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 section 3.2.2 are as follows:</t>
<artwork align='left' type='abnf'><![CDATA[
* 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
-------
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
]]></artwork>
<t> The details of the calculation for DTLS framing as follows:</t>
<artwork align='left' type='abnf'><![CDATA[
Type 1 byte
Version 2 byte
Epoch 2 byte
Sequence_number 6 byte
Length 2 byte
]]></artwork>
</section>
<section title="Possible Deployment Models for SNMP">
<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 as covered by this draft. </t>
<artwork align='center' type='abnf'><![CDATA[
Manager <-------------------------------------> 6LoWPAN nodes
SNMPv3
]]></artwork>
</section>
<section title="Proxy Model">
<t>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. </t>
<artwork align='center' type='abnf'><![CDATA[
Manager <--------> SNMP Proxy <--------------> 6LoWPAN nodes
SNMPv3 (6LoWPAN ER) 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. 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. </t>
<artwork align='center' type='abnf'><![CDATA[
Manager <-------> SNMP Agent <-----------------> 6LoWPAN nodes
SNMPv3 (6LoWPAN ER) SubAgent Protocol
]]></artwork>
</section>
</section>
<section title="Change Log ">
<t>Changes from -01 to -02:</t>
<t>The draft now covers applicability of SNMPv3 for 6LoWPANs. The focus of the draft is shifted towards supporting SNMPv3 'as is' in 6LoWPANs.</t>
<t><list style="numbers">
<t>Added SNMP Agent Implentation Considerations for 6LoWPANs.</t>
<t>Added SNMP Manager Implentation Considerations for 6LoWPANs.</t>
<t>Added the Deployment Considerations for 6LoWPANs.</t>
<t>Added the Applicable MIB modules for 6LoWPANs.</t>
<t>Moved SNMP Deployment Models to Appendix.</t>
<t>Removed the section on Packet Compression.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:49:07 |