Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework
1 November 1994
Jeffrey D. Case
SNMP Research, Inc.
case@snmp.com
Keith McCloghrie
Cisco Systems, Inc.
kzm@cisco.com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
waldbusser@cmu.edu
<draft-ietf-snmpv2-coex-ds-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Expires May 1994 [Page 1]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
1. Introduction
The purpose of this document is to describe coexistence between version
2 of the Internet-standard Network Management Framework, termed the SNMP
version 2 framework (SNMPv2) [1], and the original Internet-standard
Network Management Framework (SNMPv1), which consists of these three
documents:
RFC 1155 [2] which defines the Structure of Management Information
(SMI), the mechanisms used for describing and naming objects for
the purpose of management.
RFC 1212 [3] which defines a more concise description mechanism,
which is wholly consistent with the SMI.
RFC 1157 [4] which defines the Simple Network Management Protocol
(SNMP), the protocol used for network access to managed objects.
1.1. Change Log
For the 1 November version:
- recast RFC 1452 into an Internet-Draft,
- fixed typos
- removed requirement to set the MAX-ACCESS of auxiliary objects to
"not-accessible" when converting a SNMPv1 MIB, in order to be
consistent with text in the SMI.
- removed requirement to obsolete an object with a SYNTAX of
enumerated INTEGER and a named-number enumeration of zero, in order
to be consistent with text in the SMI.
Expires May 1994 [Page 2]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
2. Management Information
The SNMPv2 approach towards describing collections of managed objects is
nearly a proper superset of the approach defined in the Internet-
standard Network Management Framework. For example, both approaches use
ASN.1 [5] as the basis for a formal descriptive notation. Indeed, one
might note that the SNMPv2 approach largely codifies the existing
practice for defining MIB modules, based on extensive experience with
the current framework.
The SNMPv2 documents which deal with information modules are:
Structure of Management Information for SNMPv2 [6], which defines
concise notations for describing information modules, managed
objects and notifications;
Textual Conventions for SNMPv2 [7], which defines a concise
notation for describing textual conventions, and also defines some
initial conventions; and,
Conformance Statements for SNMPv2 [8], which defines concise
notation for describing compliance and capabilities statements.
The following sections consider the three areas: MIB modules, compliance
statements, and capabilities statements.
MIB modules defined using the current framework may continue to be used
with the SNMPv2 protocol. However, for the MIB modules to conform to
the SNMPv2 framework, the following changes are required:
2.1. Object Definitions
In general, conversion of a MIB module does not require the deprecation
of the objects contained therein. Only if the semantics of an object
truly changes should deprecation be performed.
(1) The IMPORTS statement must reference SNMPv2-SMI, instead of
RFC1155-SMI and RFC-1212.
(2) The MODULE-IDENTITY macro must be invoked immediately after any
IMPORTs or EXPORTs statement.
(3) For any descriptor which contains the hyphen character, the hyphen
character is removed.
Expires May 1994 [Page 3]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
(4) For any object with an integer-valued SYNTAX clause, in which the
corresponding INTEGER does not have a range restriction (i.e., the
INTEGER has neither a defined set of named-number enumerations nor
an assignment of lower- and upper-bounds on its value), the object
must have the value of its SYNTAX clause changed to Integer32.
(5) For any object with a SYNTAX clause value of an enumerated INTEGER,
the hyphen character is removed from any named-number labels which
contain the hyphen character.
(6) For any object with a SYNTAX clause value of Counter, the object
must have the value of its SYNTAX clause changed to Counter32.
(7) For any object with a SYNTAX clause value of Gauge, the object must
have the value of its SYNTAX clause changed to Gauge32.
(8) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS
clause. The value of the MAX-ACCESS clause is the same as that of
the ACCESS clause unless some other value makes "protocol sense" as
the maximal level of access for the object. In particular, object
types for which instances can be explicitly created by a protocol
set operation, will have a MAX-ACCESS clause of "read-create". If
the value of the ACCESS clause is "write-only", then the value of
the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause
notes that reading this object will result implementation-specific
results.
(9) For all objects, if the value of the STATUS clause is "mandatory",
the value must be replaced with "current".
(10) For all objects, if the value of the STATUS clause is "optional",
the value must be replaced with "obsolete".
(11) For any object not containing a DESCRIPTION clause, the object must
have a DESCRIPTION clause defined.
(12) For any object corresponding to a conceptual row which does not
have an INDEX clause, the object must have either an INDEX clause
or an AUGMENTS clause defined.
(13) For any object with an INDEX clause that references an object with
a syntax of NetworkAddress, the value of the STATUS clause of both
objects is changed to "obsolete".
Expires May 1994 [Page 4]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
(14) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
value which is expressed as a collection of sub-identifiers, change
the value to reference a single ASN.1 identifier.
Other changes are desirable, but not necessary:
(1) Creation and deletion of conceptual rows is inconsistent using the
current framework. The SNMPv2 framework corrects this. As such,
if the MIB module undergoes review early in its lifetime, and it
contains conceptual tables which allow creation and deletion of
conceptual rows, then it may be worthwhile to deprecate the objects
relating to those tables and replace them with objects defined
using the new approach.
(2) For any object with a string-valued SYNTAX clause, in which the
corresponding OCTET STRING does not have a size restriction (i.e.,
the OCTET STRING has no assignment of lower- and upper-bounds on
its length), one might consider defining the bounds for the size of
the object.
(3) For all textual conventions informally defined in the MIB module,
one might consider redefining those conventions using the TEXTUAL-
CONVENTION macro. Such a change would not necessitate deprecating
objects previously defined using an informal textual convention.
(4) For any object which represents a measurement in some kind of
units, one might consider adding a UNITS clause to the definition
of that object.
(5) For any conceptual row which is an extension of another conceptual
row, i.e., for which subordinate columnar objects both exist and
are identified via the same semantics as the other conceptual row,
one might consider using an AUGMENTS clause in place of the INDEX
clause for the object corresponding to the conceptual row which is
an extension.
Finally, when encountering common errors in SNMPv1 MIB modules:
(1) For any non-columnar object that is instanced as if it were
immediately subordinate to a conceptual row, the value of the
STATUS clause of that object is changed to "obsolete".
(2) For any conceptual row object that is not contained immediately
subordinate to a conceptual table, the value of the STATUS clause
of that object (and all subordinate objects) is changed to
Expires May 1994 [Page 5]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
"obsolete".
2.2. Trap Definitions
If a MIB module is changed to conform to the SNMPv2 framework, then each
occurrence of the TRAP-TYPE macro must be changed to a corresponding
invocation of the NOTIFICATION-TYPE macro:
(1) The IMPORTS statement must not reference RFC-1215.
(2) The ENTERPRISES clause must be removed.
(3) The VARIABLES clause must be renamed to the OBJECTS clause.
(4) The STATUS clause must be added.
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an
OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly.
2.3. Compliance Statements
For those information modules which are "standard", a corresponding
invocation of the MODULE-COMPLIANCE macro must be included within the
information module (or in a companion information module), and any
commentary text in the information module which relates to compliance
must be removed. Typically this editing can occur when the information
module undergoes review.
2.4. Capabilities Statements
In the current framework, the informational document [9] uses the
MODULE-CONFORMANCE macro to describe an agent's capabilities with
respect to one or more MIB modules. Converting such a description for
use with the SNMPv2 framework requires these changes:
(1) Use the macro name AGENT-CAPABILITIES instead of MODULE-
CONFORMANCE.
(2) The STATUS clause must be added.
(3) For all occurrences of the CREATION-REQUIRES clause, note the
slight change in semantics, and omit this clause if appropriate.
Expires May 1994 [Page 6]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
3. Protocol Operations
The SNMPv2 documents which deal with protocol operations are:
Protocol Operations for SNMPv2 [10], which defines the syntax and
semantics of the operations conveyed by the protocol; and,
Transport Mappings for SNMPv2 [11], which defines how the protocol
operations are carried over different transport services.
The following section considers two areas: the proxy behavior between a
SNMPv2 entity and a SNMPv1 agent; and, the behavior of "bi-lingual"
protocol entities acting in a manager role.
3.1. Proxy Agent Behavior
To achieve coexistence at the protocol-level, a proxy mechanism may be
used. A SNMPv2 entity acting in an agent role may be implemented and
configured to act in the role of a proxy agent.
3.1.1. SNMPv2 -> SNMPv1
When converting requests from a SNMPv2 entity acting in a manager role
into requests sent to a SNMPv1 entity acting in an agent role:
(1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is
received, then it is passed unaltered by the proxy agent.
(2) If a GetBulkRequest-PDU is received, the proxy agent sets the non-
repeaters and max-repetitions fields to zero, and sets the tag of
the PDU to GetNextRequest-PDU.
3.1.2. SNMPv1 -> SNMPv2
When converting responses received from a SNMPv1 entity acting in an
agent role into responses sent to a SNMPv2 entity acting in a manager
role:
(1) If a GetResponse-PDU is received, then it is passed unaltered by
the proxy agent. Note that even though a SNMPv2 entity will never
generate a Response-PDU with a error-status field having a value of
`noSuchName', `badValue', or `readOnly', the proxy agent must not
Expires May 1994 [Page 7]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
change this field. This allows the SNMPv2 entity acting in a
manager role to interpret the response correctly.
If a GetResponse-PDU is received with an error-status field having
a value of `tooBig', the proxy agent will remove the contents of
the variable-bindings field before propagating the response. Note
that even though a SNMPv2 entity will never generate a `tooBig' in
response to a GetBulkRequestPDU, the proxy agent must propagate
such a response.
(2) If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap-
PDU. This is done by prepending onto the variable-bindings field
two new bindings: sysUpTime.0 [12], which takes its value from the
timestamp field of the Trap-PDU; and, snmpTrapOID.0 [12], which is
calculated thusly: if the value of generic-trap field is
`enterpriseSpecific', then the value used is the concatenation of
the enterprise field from the Trap-PDU with two additional sub-
identifiers, `0', and the value of the specific-trap field;
otherwise, the value of the corresponding trap defined in [12] is
used. (For example, if the value of the generic-trap field is
`coldStart', then the coldStart trap [12] is used.) Then, one new
binding is appended onto the variable-bindings field:
snmpTrapEnterprise.0 [12], which takes its value from the
enterprise field of the Trap-PDU. To determine the destinations
for the SNMPv2-Trap-PDU, the proxy agent applies the procedures
defined in Section 4.2.6 of [10], with the exception that no check
is made to see if the instances associated with this trap are
present in the proxy agent's view.
Expires May 1994 [Page 8]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
3.2. Bi-lingual Manager Behavior
To achieve coexistence at the protocol-level, a protocol entity acting
in a manager role might support both SNMPv1 and SNMPv2. When a
management application needs to contact a protocol entity acting in an
agent role, the entity acting in a manager role consults a local
database to select the correct management protocol to use.
In order to provide transparency to management applications, the entity
acting in a manager role must map operations as if it were acting as a
proxy agent.
Expires May 1994 [Page 9]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
4. Acknowledgements
This document is a modified version of RFC 1452.
5. References
[1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Introduction to Version 2 of the Internet-standard Network
Management Framework", Internet Draft, SNMP Research, Inc., Cisco
Systems, Dover Beach Consulting, Inc., Carnegie Mellon University,
November 1994.
[2] Rose, M., and McCloghrie, K., "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990.
[3] Rose, M., and McCloghrie, K., "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[4] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
Systems International, MIT Laboratory for Computer Science, May
1990.
[5] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure
of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc.,
Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, November 1994.
[7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual
Conventions for Version 2 of the the Simple Network Management
Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco
Systems, Dover Beach Consulting, Inc., Carnegie Mellon University,
November 1994.
[8] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Conformance Statements for Version 2 of the the Simple Network
Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc.,
Expires May 1994 [Page 10]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, November 1994.
[9] McCloghrie, K., and Rose, M., "A Convention for Describing SNMP-
based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
Consulting, Inc., February 1992.
[10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems,
Dover Beach Consulting, Inc., Carnegie Mellon University, November
1994.
[11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems,
Dover Beach Consulting, Inc., Carnegie Mellon University, November
1994.
[12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management
Information Base for Version 2 of the Simple Network Management
Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco
Systems, Dover Beach Consulting, Inc., Carnegie Mellon University,
November 1994.
Expires May 1994 [Page 11]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
6. Security Considerations
Security issues are not discussed in this memo.
7. Authors' Addresses
Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US
Phone: +1 615 573 1434
Email: case@snmp.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose CA 95134-1706.
Phone: +1 408 526 5260
Email: kzm@cisco.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
US
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu
Expires May 1994 [Page 12]
Internet Draft Coexistence between SNMPv1 and SNMPv2 November 1994
Table of Contents
1 Introduction .................................................... 2
1.1 Change Log .................................................... 2
2 Management Information .......................................... 3
2.1 Object Definitions ............................................ 3
2.2 Trap Definitions .............................................. 6
2.3 Compliance Statements ......................................... 6
2.4 Capabilities Statements ....................................... 6
3 Protocol Operations ............................................. 7
3.1 Proxy Agent Behavior .......................................... 7
3.1.1 SNMPv2 -> SNMPv1 ............................................ 7
3.1.2 SNMPv1 -> SNMPv2 ............................................ 7
3.2 Bi-lingual Manager Behavior ................................... 9
4 Acknowledgements ................................................ 10
5 References ...................................................... 10
6 Security Considerations ......................................... 12
7 Authors' Addresses .............................................. 12
Expires May 1994 [Page 13]
