SNMPinfo

SNMP Versions

[ Home | What's New | SNMPinfo | SMIC ]


SNMP Versions

David T. Perkins

Confusion continues with regards to the similarities and differences of the different versions of the SNMP protocol. Also, there are many questions regarding dependency between the SMI and the protocol versions. This article attempts to clarify the confusion and answer the questions.

IETF Terminology

The Internet Engineering Task Force (IETF) publishes documents that are called Requests For Comments (RFCs). These documents, even though called "requests for comments", are "final" versions of documents that specify standards, operational practices, opinions, humor, etc. for the Internet protocol suite. (Documents that are works in progress and made available for review are called internet-drafts.) The subset of the documents that specify standards are given a status of proposed, draft, full, experimental, or historic. A document meant to specify a standard enters the standards-track as proposed, and advances to draft before becoming a full standard after rigorous review, implementation, deployment, and operational experience. A document specifying a protocol, format, or procedure not yet ready for standardization is given the label of experimental. Documents that have been replaced by others, or whose contents are no longer relevant have status of historical.

SNMP Protocol Versions

The versions of the SNMP protocol are:

SNMP SMI Versions

The Structure of Management Information (SMI) defines the format for defining managed objects that are accessed via the SNMP protocol, the data types of objects, the format for defining events (called traps in SMIv1 and notifications in SMIv2), and contains a few administrative assignments. There are currently two versions of the SMI, which are:

SMIv2 is a backward-compatible update of SMIv1, in all cases except for data type Counter64. That is, it is possible to mechanically create a definition of managed objects in the SMIv1 format from a definition in the SMIv2 format except for objects whose data type is Counter64.

There is no complete mechanical conversion from definitions of managed objects in the SMIv1 format to the SMIv2 format, since the SMIv2 format contains fields for additional information that must be provided by the designer of the definitions. Also, the ACCESS clause was changed to MAX-ACCESS and its meaning changed, and, thus, the values need to be reviewed when converting from SMIv1 to SMIv2. (You cannot simply use the same values in all cases when you translate object definitions.) Finally, the SMIv2 format contains constructs to define requirement specifications and implementation specifications not found in the SMIv1 format.

By design, the format for the definition of managed objects is independent of the protocol to access them, except for objects with data type of Counter64. That data type does not exist in the SNMPv1 and SNMPsec protocols. A conforming SNMPv1 or SNMPsec entity will generate an ASN.1 parse error when parsing a message containing a Counter64 data type. RFC 2089 defines the behavior of a conforming bilingual (and multilingual) agent that has access to objects with the Counter64 data type.

Version Usage

At this time, only the SNMPv1 protocol has widespread usage. The SNMPv1 protocol is most likely found in every managed device and management platform that supports SNMP. The SNMPsec protocol never saw commercial availability. The SNMPv2p protocol has seen limited commercial availability. Only one of the leading device vendors has made available agents supporting SNMPv2p. All indicators point to no new SNMPv2p offerings and current offerings being replaced by SNMPv2c or SNMPv3. The SNMPv2u and SNMPv2* protocols saw no significant commercial offerings. Support for SNMPv2c in commercial products has been limited, but has been building in 1997. Now that SNMPv3 has been approved to enter the standards-track and for publication, some vendors may not offer SNMPv2c and instead, skip to SNMPv3.

At this time, there is widespread use and support of both versions of the SMI. This is due in part to the policy in the IETF that new versions of RFCs must specify MIB modules in the SMIv2 format. Many commercial products that process MIB modules support both formats.


Copyright © 1998 SNMPinfo. All Rights Reserved.
Last modified: January 08, 1998