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,
          <snmp@psi.com>.







































                             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]