| |
| |
| |
| |
| |
| |
| Network Working Group SNMPv2 Working Group |
| Request for Comments: 1908 J. Case |
| Obsoletes: 1452 SNMP Research, Inc. |
| Category: Standards Track K. McCloghrie |
| Cisco Systems, Inc. |
| M. Rose |
| Dover Beach Consulting, Inc. |
| S. Waldbusser |
| International Network Services |
| January 1996 |
| |
| |
| Coexistence between Version 1 and Version 2 of the |
| Internet-standard Network Management Framework |
| |
| Status of this Memo |
| |
| This document specifies an Internet standards track protocol for the |
| Internet community, and requests discussion and suggestions for |
| improvements. Please refer to the current edition of the "Internet |
| Official Protocol Standards" (STD 1) for the standardization state |
| and status of this protocol. Distribution of this memo is unlimited. |
| |
| Table of Contents |
| |
| 1. Introduction ................................................ 2 |
| 2. Management Information ...................................... 2 |
| 2.1 Object Definitions ......................................... 3 |
| 2.2 Trap Definitions ........................................... 5 |
| 2.3 Compliance Statements ...................................... 5 |
| 2.4 Capabilities Statements .................................... 6 |
| 3 Protocol Operations .......................................... 6 |
| 3.1 Proxy Agent Behavior ....................................... 6 |
| 3.1.1 SNMPv2 -> SNMPv1 ......................................... 7 |
| 3.1.2 SNMPv1 -> SNMPv2 ......................................... 7 |
| 3.2 Bi-lingual Manager Behavior ................................ 8 |
| 4. Security Considerations ..................................... 8 |
| 5. Editor's Address ............................................ 8 |
| 6. Acknowledgements ............................................ 8 |
| 7. References .................................................. 9 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 1] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| 1. Introduction |
| |
| The purpose of this document is to describe coexistence between |
| version 2 of the Internet-standard Network Management Framework [1- |
| 6], termed the SNMP version 2 framework (SNMPv2), and the original |
| Internet-standard Network Management Framework (SNMPv1), which |
| consists of these three documents: |
| |
| STD 16, RFC 1155 [7] which defines the Structure of Management |
| Information (SMI), the mechanisms used for describing and naming |
| objects for the purpose of management. |
| |
| STD 16, RFC 1212 [8] which defines a more concise description |
| mechanism, which is wholly consistent with the SMI. |
| |
| STD 15, RFC 1157 [9] which defines the Simple Network Management |
| Protocol (SNMP), the protocol used for network access to managed |
| objects. |
| |
| 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 [10] 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 [1], which defines |
| concise notations for describing information modules, managed |
| objects and notifications; |
| |
| Textual Conventions for SNMPv2 [2], which defines a concise |
| notation for describing textual conventions, and also defines some |
| initial conventions; and, |
| |
| Conformance Statements for SNMPv2 [3], 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: |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 2] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| 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 statement. |
| |
| (3) For any descriptor which contains the hyphen character, the hyphen |
| character is removed. |
| |
| (4) For any label for a named-number enumeration which contains the |
| hyphen character, the hyphen character is removed. |
| |
| (5) 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. |
| |
| (6) 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. |
| |
| (7) For any object with a SYNTAX clause value of Counter, the object |
| must have the value of its SYNTAX clause changed to Counter32. |
| |
| (8) For any object with a SYNTAX clause value of Gauge, the object must |
| have the value of its SYNTAX clause changed to Gauge32. |
| |
| (9) 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. |
| |
| (10) For all objects, if the value of the STATUS clause is "mandatory", |
| the value must be replaced with "current". |
| |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 3] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| (11) For all objects, if the value of the STATUS clause is "optional", |
| the value must be replaced with "obsolete". |
| |
| (12) For any object not containing a DESCRIPTION clause, the object must |
| have a DESCRIPTION clause defined. |
| |
| (13) 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. |
| |
| (14) 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". |
| |
| (15) 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 |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 4] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| 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 |
| "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. |
| Specifically, if the value of the ENTERPRISE clause is not 'snmp' |
| then the value of the invocation is the value of the ENTERPRISE |
| clause extended with two sub-identifiers, the first of which has |
| the value 0, and the second has the value of the invocation of the |
| TRAP-TYPE. |
| |
| 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. |
| |
| |
| |
| |
| |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 5] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| 2.4. Capabilities Statements |
| |
| In the current framework, the informational document [11] 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. |
| |
| In order to ease the coexistence between SNMPv1 and SNMPv2, object |
| groups defined in an SNMPv1 MIB module may be referenced by the |
| INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: |
| upon encountering a reference to an OBJECT IDENTIFIER subtree defined |
| in an SNMPv1 MIB module, all leaf objects which are subordinate to |
| the subtree and have a STATUS clause value of mandatory are deemed to |
| be INCLUDEd. (Note that this method is ambiguous when different |
| revisions of a SNMPv1 MIB have different sets of mandatory objects |
| under the same subtree; in such cases, the only solution is to |
| rewrite the MIB using the SNMPv2 SMI in order to define the object |
| groups unambiguously.) |
| |
| 3. Protocol Operations |
| |
| The SNMPv2 documents which deal with protocol operations are: |
| |
| Protocol Operations for SNMPv2 [4], which defines the syntax and |
| semantics of the operations conveyed by the protocol; and, |
| |
| Transport Mappings for SNMPv2 [5], 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. |
| |
| |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 6] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| 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 |
| 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 GetBulkRequest-PDU, 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 [6], which takes its value from the |
| timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], 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 [6] is |
| used. (For example, if the value of the generic-trap field is |
| `coldStart', then the coldStart trap [6] is used.) Then, one new |
| binding is appended onto the variable-bindings field: |
| snmpTrapEnterprise.0 [6], which takes its value from the enterprise |
| field of the Trap-PDU. The destinations for the SNMPv2-Trap-PDU |
| are determined in an implementation-dependent fashion by the proxy |
| agent. |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 7] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| 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. |
| |
| 4. Security Considerations |
| |
| Security issues are not discussed in this memo. |
| |
| 5. Editor's Address |
| |
| Keith McCloghrie |
| Cisco Systems, Inc. |
| 170 West Tasman Drive |
| San Jose, CA 95134-1706 |
| US |
| |
| Phone: +1 408 526 5260 |
| EMail: kzm@cisco.com |
| |
| 6. Acknowledgements |
| |
| This document is the result of significant work by the four major |
| contributors: |
| |
| Jeffrey D. Case (SNMP Research, case@snmp.com) |
| Keith McCloghrie (Cisco Systems, kzm@cisco.com) |
| Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) |
| Steven Waldbusser (International Network Services, stevew@uni.ins.com) |
| |
| In addition, the contributions of the SNMPv2 Working Group are |
| acknowledged. In particular, a special thanks is extended for the |
| contributions of: |
| |
| Alexander I. Alten (Novell) |
| Dave Arneson (Cabletron) |
| Uri Blumenthal (IBM) |
| Doug Book (Chipcom) |
| Kim Curran (Bell-Northern Research) |
| Jim Galvin (Trusted Information Systems) |
| Maria Greene (Ascom Timeplex) |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 8] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| Iain Hanson (Digital) |
| Dave Harrington (Cabletron) |
| Nguyen Hien (IBM) |
| Jeff Johnson (Cisco Systems) |
| Michael Kornegay (Object Quest) |
| Deirdre Kostick (AT&T Bell Labs) |
| David Levi (SNMP Research) |
| Daniel Mahoney (Cabletron) |
| Bob Natale (ACE*COMM) |
| Brian O'Keefe (Hewlett Packard) |
| Andrew Pearson (SNMP Research) |
| Dave Perkins (Peer Networks) |
| Randy Presuhn (Peer Networks) |
| Aleksey Romanov (Quality Quorum) |
| Shawn Routhier (Epilogue) |
| Jon Saperia (BGS Systems) |
| Bob Stewart (Cisco Systems, bstewart@cisco.com), chair |
| Kaj Tesink (Bellcore) |
| Glenn Waters (Bell-Northern Research) |
| Bert Wijnen (IBM) |
| |
| 7. References |
| |
| [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and |
| S. Waldbusser, "Structure of Management Information for Version 2 |
| of the Simple Network Management Protocol (SNMPv2)", RFC 1902, |
| January 1996. |
| |
| [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and |
| S. Waldbusser, "Textual Conventions for Version 2 of the Simple |
| Network Management Protocol (SNMPv2)", RFC 1903, January 1996. |
| |
| [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and |
| S. Waldbusser, "Conformance Statements for Version 2 of the Simple |
| Network Management Protocol (SNMPv2)", RFC 1904, January 1996. |
| |
| [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and |
| S. Waldbusser, "Protocol Operations for Version 2 of the Simple |
| Network Management Protocol (SNMPv2)", RFC 1905, January 1996. |
| |
| [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and |
| S. Waldbusser, "Transport Mappings for Version 2 of the Simple |
| Network Management Protocol (SNMPv2)", RFC 1906, January 1996. |
| |
| [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and |
| S. Waldbusser, "Management Information Base for Version 2 of the |
| Simple Network Management Protocol (SNMPv2)", RFC 1907, |
| January 1996. |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 9] |
| |
| RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 |
| |
| |
| [7] Rose, M., and K. McCloghrie, "Structure and Identification of |
| Management Information for TCP/IP-based internets", STD 16, RFC |
| 1155, May 1990. |
| |
| [8] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, |
| RFC 1212, March 1991. |
| |
| [9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network |
| Management Protocol", STD 15, RFC 1157, SNMP Research, Performance |
| Systems International, MIT Laboratory for Computer Science, May |
| 1990. |
| |
| [10] Information processing systems - Open Systems Interconnection - |
| Specification of Abstract Syntax Notation One (ASN.1), |
| International Organization for Standardization. International |
| Standard 8824, (December, 1987). |
| |
| [11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- |
| based Agents", RFC 1303, Hughes LAN Systems, Dover Beach |
| Consulting, Inc., February 1992. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| SNMPv2 Working Group Standards Track [Page 10] |
| |
