Draft SNMP/SMP Coexistence Jul 92 Coexistence between the Internet-standard Network Management Framework and the Simple Management Protocol (SMP) Framework Sat Jul 4 17:76:08 1992 Jeffrey D. Case SNMP Research, Inc. University of Tennessee, Knoxville case@cs.utk.edu Keith McCloghrie Hughes LAN Systems kzm@hls.com Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us Steven L. Waldbusser Carnegie Mellon University waldbusser@andrew.cmu.edu 1. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to Expires January 4, 1993 [Page 1] Draft SNMP/SMP Coexistence Jul 92 cite them other than as a "working draft" or "work in progress". Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Please send comments to the SNMP discussion group, . Expires January 4, 1993 [Page 2] Draft SNMP/SMP Coexistence Jul 92 2. Introduction The Simple Management Protocol (SMP) Framework [1] is the next-generation in the genus of a management framework originally derived from the Simple Gateway Monitoring Protocol (SGMP) [2]. The current framework, the Internet-standard Network Management Framework, consists of three components. They are: RFC 1155 [3] which defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 [4] defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1213 [5] which defines the TCP/IP Management Information Base 2 (MIB-II), the core set of managed objects for the Internet suite of protocols. RFC 1157 [6] which defines the Simple Network Management Protocol (SNMP), the protocol used for network access to managed objects. Just as the current framework is derived from the SGMP, so is the SMP framework derived from the Internet-standard Network Management Framework. The purpose of this document is to discuss coexistence between the two frameworks. Expires January 4, 1993 [Page 3] Draft SNMP/SMP Coexistence Jul 92 3. Management Information The SMP 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 [7] as the basis for a formal descriptive notation. Indeed, one might note that the SMP approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the current framework. The SMP documents which deal with MIB modules are: Structure of Management Information for the SMP [8], which defines concise notations for describing managed objects, compliance statements for MIB modules, and capabilities statements for agent implementations; and, Textual Conventions for the SMP [9], which defines a concise notation for describing textual conventions, and also defines some initial conventions. 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 SMP protocol. However, for the MIB modules to conform to the SMP framework, the following changes are required: 3.1. Object Definitions (1) The IMPORTS statement should reference SMP-SMI, instead of RFC1155-SMI and RFC-1212. (2) Object groups, which were informally defined (using ASN.1 comments), should be defined using the OBJECT-GROUP macro. (3) 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 should have Expires January 4, 1993 [Page 4] Draft SNMP/SMP Coexistence Jul 92 the value of its SYNTAX clause changed to Integer32. (4) For any object with a SYNTAX clause value of Counter, the object should have the value of its SYNTAX clause changed to Counter32. (5) For any object with a SYNTAX clause value of Gauge, the object should have the value of its SYNTAX clause changed to Gauge32. (6) For all objects, the ACCESS clause should 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". (7) For any columnar object which is used solely for instance identification in a conceptual row, the object should have the value of its MAX-ACCESS clause set to "not- accessible". Note that if all columnar objects of the conceptual row are used for instance identification, then one of them is not actually used solely for instance identification and its MAX-ACCESS clause must be something other than "not-accessible". (8) For any object not containing a DESCRIPTION clause, the object should have a DESCRIPTION clause defined. (9) For any object corresponding to a conceptual row which does not have an INDEX clause, the object should have either an INDEX clause or an AUGMENTS clause defined. Other changes are desirable, but not necessary: (1) Creation and deletion of conceptual rows is inconsistent using the current framework. The SMP approach 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 replacing them with objects defined using the new approach. Expires January 4, 1993 [Page 5] Draft SNMP/SMP Coexistence Jul 92 (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. 3.2. Trap Definitions If a MIB module is changed to conform to the SMP framework, then each occurrence of the TRAP-TYPE macro should be changed to a corresponding invocation of the TRAP-DEFINITION macro: (1) The IMPORTS statement should not reference RFC-1215. (2) The ENTERPRISES clause should be removed. (3) The VARIABLES clause should be renamed to the OBJECTS clause. (4) The value of invocation of the TRAP-DEFINITION is an OBJECT IDENTIFIER. As such, a new OBJECT IDENTIFIER branch should be assigned for traps, and the traps should be sequentially assigned under that branch. Expires January 4, 1993 [Page 6] Draft SNMP/SMP Coexistence Jul 92 3.3. Compliance Definitions For those MIB modules which are "standard", a corresponding invocation of the MODULE-COMPLIANCE macro should be included within the MIB module, and any commentary text in the MIB module which relates to compliance should be removed. Typically this editing can occur when the MIB module undergoes review. 3.4. Capabilities Definitions In the current framework, the informational document [10] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities in comparison with one or more MIB modules. Converting such a description for use with the SMP requires these changes: (1) Use the macro name AGENT-CAPABILITIES instead of MODULE- CONFORMANCE. (2) For all occurrences of the CREATION-REQUIRES clause, note the slight change in semantics, and omit this clause if appropriate. Expires January 4, 1993 [Page 7] Draft SNMP/SMP Coexistence Jul 92 4. Protocol Operations The SMP documents which deal with protocol operations are: Protocol Operations for the SMP [11], which defines the syntax and semantics of the operations conveyed by the protocol; and, Transport Mappings for the SMP [12], which defines how the protocol operations are carried over different transport services. The following section considers two areas: the proxy behavior between an SMP entity and an SNMP agent; and, the behavior of "bi-lingual" protocol entities acting in a manager role. 4.1. Proxy Agent Behavior To achieve coexistence at the protocol-level, a proxy mechanism may be used. A SMP entity acting in an agent role may be implemented and configured to act in the role of a proxy agent. 4.1.1. SMP -> SNMP When converting requests from a SMP entity acting in a manager role into requests sent to a SNMP 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. 4.1.2. SNMP -> SMP When converting responses received from a SNMP entity acting in an agent role into responses sent to a SMP entity acting in a manager role: Expires January 4, 1993 [Page 8] Draft SNMP/SMP Coexistence Jul 92 (1) If a GetResponse-PDU is received, then it is passed unaltered by the proxy agent. Note that even though a SMP 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 SMP 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 SMP 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 SMP- Trap-PDU. This is done by prepending onto the variable- bindings field two new bindings: sysUpTime.0 [5], which takes its value from the timestamp field of the Trap-PDU; and, smpTrapOID.0 [13], 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 [13] is used. (For example, if the value of the generic-trap field is `coldStart', then the coldStart trap [13] is used.) Then, one new binding is appended onto the variable-bindings field: smpEnterpriseOID.0 [13], which takes its value from the enterprise field of the Trap-PDU. To determine the destinations for the SMP-Trap-PDU, the proxy agent applies the procedures defined in Section 6.4 of [8], 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 January 4, 1993 [Page 9] Draft SNMP/SMP Coexistence Jul 92 4.2. Bi-lingual Manager Behavior To achieve coexistence at the protocol-level, a protocol entity acting in a manager role might support both SNMP and SMP. 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 should map operations as if it were acting as a proxy agent. Expires January 4, 1993 [Page 10] Draft SNMP/SMP Coexistence Jul 92 5. Administrative Framework The administrative framework used by SMP is nearly identical to the SNMP Administrative Framework defined in [14,15,16]. Consult Section 3.6 of [1] for the details. Expires January 4, 1993 [Page 11] Draft SNMP/SMP Coexistence Jul 92 6. References [1] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Introduction to the Simple Management Protocol (SMP) Framework, (July, 1992). [2] J.R. Davin, J.D. Case, M.S. Fedor, M.L. Schoffstall, The Simple Gateway Monitoring Protocol. Request for Comments 1028, (November, 1987). [3] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets. Request for Comments 1155, (May, 1990). [4] M.T. Rose and K. McCloghrie, Concise MIB Definitions. Request for Comments 1212, (March, 1991). [5] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets: MIB-II. Request for Comments 1213, (March, 1991). [6] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol. Request for Comments 1157, (May, 1990). [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [8] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Structure of Management Information for the Simple Management Protocol (SMP) Framework, (July, 1992). [9] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Textual Conventions for the Simple Management Protocol (SMP) Framework, (July, 1992). [10] K. McCloghrie, M.T. Rose, A Convention for Describing SNMP-based Agents. Request for Comments 1303, (February, 1992). [11] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Protocol Operations for the Simple Management Protocol Expires January 4, 1993 [Page 12] Draft SNMP/SMP Coexistence Jul 92 (SMP) Framework, (July, 1992). [12] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Transport Mappings for the Simple Management Protocol (SMP) Framework, (July, 1992). [13] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Management Information Base for the Simple Management Protocol (SMP) Framework, (July, 1992). [14] J.R. Davin, J.M. Galvin, K. McCloghrie, SNMP Administrative Model. Request for Comments 1351, (July, 1992). [15] J.M. Galvin, K. McCloghrie, J.R. Davin, SNMP Security Protocols. Request for Comments 1352, (July, 1992). [16] K. McCloghrie, J.R. Davin, J.M. Galvin, Definitions of Managed Objects for Administration of SNMP Parties. Request for Comments 1353, (July, 1992). Expires January 4, 1993 [Page 13] Draft SNMP/SMP Coexistence Jul 92 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 3 3 Management Information ................................ 4 3.1 Object Definitions .................................. 4 3.2 Trap Definitions .................................... 6 3.3 Compliance Definitions .............................. 7 3.4 Capabilities Definitions ............................ 7 4 Protocol Operations ................................... 8 4.1 Proxy Agent Behavior ................................ 8 4.1.1 SMP -> SNMP ....................................... 8 4.1.2 SNMP -> SMP ....................................... 8 4.2 Bi-lingual Manager Behavior ......................... 10 5 Administrative Framework .............................. 11 6 References ............................................ 12 Expires January 4, 1993 [Page 14]