Draft            Protocol Operations for SMP            Jul 92


                               Protocol Operations
                                     for the
                    Simple Management Protocol (SMP) Framework

                             Sat Jul  4 17:76:04 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
          cite them other than as a "working draft" or "work in





                             Expires January 4, 1993            [Page 1]





          Draft            Protocol Operations for SMP            Jul 92


          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            Protocol Operations for SMP            Jul 92


          2.  Introduction

          A network management system contains: several (potentially,
          many) network elements, each with an associated processing
          entity, termed an agent, which has access to management
          instrumentation; at least one management station; and, a
          management protocol, used to convey management information
          between the agents and the management stations.  Operations of
          the protocol are carried out under an administrative framework
          which defines both authentication and authorization policies.

          Network management stations execute management applications
          which monitor and control network elements through access to
          their management information.  Network elements are devices
          such as hosts, routers, terminal servers, network monitors,
          etc., which are monitored and controlled through access to
          their management information.

          Management information is viewed as a collection of managed
          objects, residing in a virtual information store, termed the
          Management Information Base (MIB).  Collections of related
          objects are defined in MIB modules.  These modules are written
          using a subset of OSI's Abstract Syntax Notation One (ASN.1)
          [1].

          The management protocol, termed the Simple Management Protocol
          (SMP), provides for the exchange of messages which convey
          management information between the agents and the management
          stations.  The form of these messages is a message "wrapper"
          which encapsulates a Protocol Data Unit (PDU).  The form and
          meaning of the "wrapper" is determined by an administrative
          framework which defines both authentication and authorization
          policies.

          It is the purpose of this document, Protocol Operations for
          the SMP, to define the operations of the protocol with respect
          to the sending and receiving of the PDUs.













                             Expires January 4, 1993            [Page 3]





          Draft            Protocol Operations for SMP            Jul 92


          3.  Overview

          3.1.  Roles of Protocol Entities

          A SMP entity may operate in a manager role or an agent role.

          A SMP entity acts in an agent role when it performs SMP
          management operations in response to received SMP protocol
          messages (other than an inform notification) or when it sends
          trap notifications.

          A SMP entity acts in a manager role when it initiates SMP
          management operations by the generation of SMP protocol
          messages or when it performs SMP management operations in
          response to received trap or inform notifications.

          A SMP entity may support either or both roles, as dictated by
          its implementation and configuration.  Further, a SMP entity
          can also act in the role of a proxy agent, in which it appears
          to be acting in an agent role, but satisfies management
          requests by acting in a manager role with a remote entity.
          The use of proxy agents and the transparency principle that
          defines their behavior is described in [2].


          3.2.  Management Information

          The term, variable, refers to an instance of a non-aggregate
          object type defined according to the conventions set forth in
          the SMI [3] or the textual conventions based on the SMI [4].
          The term, variable binding, normally refers to the pairing of
          the name of a variable and its associated value.  However, if
          certain kinds of exceptional conditions occur during
          processing of a retrieval request, a variable binding will
          pair a name and an indication of that exception.

          A variable-binding list is a simple list of variable bindings.

          The name of a variable is an OBJECT IDENTIFIER which is the
          concatenation of the OBJECT IDENTIFIER of the corresponding
          object-type together with an OBJECT IDENTIFIER fragment
          identifying the instance.  The OBJECT IDENTIFIER of the
          corresponding object-type is called the OBJECT IDENTIFIER
          prefix of the variable.






                             Expires January 4, 1993            [Page 4]





          Draft            Protocol Operations for SMP            Jul 92


          3.3.  Access to Management Information

          Three types of access to management information are provided
          by the protocol.  One type is a request-response interaction,
          in which a SMP entity, acting in a manager role, sends a
          request to a SMP entity, acting in an agent role, and the
          latter SMP entity then responds to the request.  This type is
          used to retrieve or modify management information associated
          with the managed device.

          A second type is also a request-response interaction, in which
          a SMP entity, acting in a manager role, sends a request to a
          SMP entity, also acting in a manager role, and the latter SMP
          entity then responds to the request.  This type is used to
          notify a SMP entity, acting in a manager role, of management
          information associated with another SMP entity, also acting in
          a manager role.

          The third type of access is an unconfirmed interaction, in
          which a SMP entity, acting in an agent role, sends a
          unsolicited message, termed a trap, to a SMP entity, acting in
          a manager role, and no response is returned.  This type is
          used to notify a SMP entity, acting in a manager role, of an
          exceptional event which has resulted in changes to management
          information associated with the managed device.


          3.4.  Retransmission of Requests

          For all types of request in this protocol, the receiver is
          required under normal circumstances, to generate and transmit
          a response to the originator of the request.  Whether or not a
          request should be retransmitted if no corresponding response
          is received in an appropriate time interval, is at the
          discretion of the application originating the request.  This
          will normally depend on the urgency of the request.  However,
          such an application needs to act responsibly in respect to the
          frequency and duration of re-transmissions.


          3.5.  Message Sizes

          The maximum size of an SMP message is limited the minimum of:







                             Expires January 4, 1993            [Page 5]





          Draft            Protocol Operations for SMP            Jul 92


          (1)  the maximum message size which the destination SMP entity
               can accept; and,

          (2)  the maximum message size which the source SMP entity can
               generate.  The former is indicated by
               partyMaxMessageSize[5] of the destination party.  The
               latter is imposed by implementation-specific local
               constraints.

          Each transport mapping for the SMP indicates the mimimum
          message size which a SMP implementation must be able to
          produce or consume.  Although implementations are encouraged
          to support larger values whenever possible, a conformant
          implementation must never generate messages larger than
          allowed by the receiving SMP entity.

          One of the aims of the GetBulkRequest-PDU, specified in this
          protocol, is to minimize the number of protocol exchanges
          required to retrieve a large amount of management information.
          As such, this PDU type allows a SMP entity acting in a manager
          role to request that the response be as large as possible
          given the constraints on message sizes.  These constraints
          include the limits on the size of messages which the SMP
          entity acting in an agent role can generate, and the SMP
          entity acting in a manager role can receive.

          However, it is possible that such maximum sized messages may
          be larger than the Path MTU of the path across the network
          traversed by the messages.  In this situation, such messages
          are subject to fragmentation.  Fragmentation is generally
          considered to be harmful [6], since among other problems, it
          leads to a decrease in the reliability of the transfer of the
          messages.  Thus, a SMP protocol entity which sends a
          GetBulkRequest-PDU must take care to set its parameters
          accordingly, so as to reduce the risk of fragmentation.  In
          particular, under conditions of network stress, only small
          values should be used for max-repetitions.


          3.6.  Transport Mappings

          It is important to note that the exchange of SMP messages
          requires only an unreliable datagram service, with every
          message being entirely and independently contained in a single
          transport datagram.  Specific transport mappings and encoding





                             Expires January 4, 1993            [Page 6]





          Draft            Protocol Operations for SMP            Jul 92


          rules are specified elsewhere [7].  However, the preferred
          mapping is the use of the User Datagram Protocol [8].
















































                             Expires January 4, 1993            [Page 7]





          Draft            Protocol Operations for SMP            Jul 92


          4.  Definitions

               SMP-PDU DEFINITIONS ::= BEGIN

               IMPORTS
                   ObjectName, ObjectSyntax, Integer32
                       FROM SMP-SMI;


               -- protocol data units

               PDUs ::=
                   CHOICE {
                       get-request
                           GetRequest-PDU,

                       get-next-request
                           GetNextRequest-PDU,

                       get-bulk-request
                           GetBulkRequest-PDU,

                       response
                           Response-PDU,

                       set-request
                           SetRequest-PDU,

                       inform-request
                           InformRequest-PDU,

                       trap
                           SMP-Trap-PDU
                   }
















                             Expires January 4, 1993            [Page 8]





          Draft            Protocol Operations for SMP            Jul 92


               -- PDUs

               GetRequest-PDU ::=
                   [0]
                       IMPLICIT PDU

               GetNextRequest-PDU ::=
                   [1]
                       IMPLICIT PDU

               GetBulkRequest-PDU ::=
                   [5]
                       IMPLICIT BulkPDU

               Response-PDU ::=
                   [2]
                       IMPLICIT PDU

               SetRequest-PDU ::=
                   [3]
                       IMPLICIT PDU

               -- [4] is obsolete

               InformRequest-PDU ::=
                   [6]
                       IMPLICIT PDU

               SMP-Trap-PDU ::=
                   [7]
                       IMPLICIT PDU



















                             Expires January 4, 1993            [Page 9]





          Draft            Protocol Operations for SMP            Jul 92


               max-bindings
                   INTEGER ::= 2147483647

               PDU ::=
                   SEQUENCE {
                       request-id
                           Integer32,

                       error-status            -- sometimes ignored
                           INTEGER {
                               noError(0),
                               tooBig(1),
                               noSuchName(2),   -- for proxy compatibility
                               badValue(3),     -- for proxy compatibility
                               readOnly(4),     -- for proxy compatibility
                               genErr(5),
                               noAccess(6),
                               wrongType(7),
                               wrongLength(8),
                               wrongEncoding(9),
                               wrongValue(10),
                               noCreation(11),
                               inconsistentValue(12),
                               resourceUnavailable(13),
                               commitFailed(14),
                               undoFailed(15),
                               authorizationError(16),
                               notWritable(17)
                           },

                       error-index            -- sometimes ignored
                           INTEGER (0..max-bindings),

                       variable-bindings   -- values are sometimes ignored
                           VarBindList
                   }














                             Expires January 4, 1993           [Page 10]





          Draft            Protocol Operations for SMP            Jul 92


               BulkPDU ::=                     -- MUST be identical in
                   SEQUENCE {                  -- structure to PDU
                       request-id
                           Integer32,

                       non-repeaters
                           INTEGER (0..max-bindings),

                       max-repetitions
                           INTEGER (0..max-bindings),

                       variable-bindings       -- values are ignored
                           VarBindList
                   }




































                             Expires January 4, 1993           [Page 11]





          Draft            Protocol Operations for SMP            Jul 92


               -- variable binding

               VarBind ::=
                   SEQUENCE {
                       name
                           ObjectName,

                       CHOICE {
                           value
                               ObjectSyntax,

                           unSpecified         -- in retrieval requests
                                   NULL,

                                               -- exceptions in responses
                           noSuchObject[0]
                                   IMPLICIT NULL,

                           noSuchInstance[1]
                                   IMPLICIT NULL,

                           endOfMibView[2]
                                   IMPLICIT NULL
                       }
                   }


               -- variable-binding list

               VarBindList ::=
                   SEQUENCE (SIZE (0..max-bindings)) OF
                       VarBind


               END















                             Expires January 4, 1993           [Page 12]





          Draft            Protocol Operations for SMP            Jul 92


          5.  Protocol Specification


          5.1.  Common Constructs

          The value of the request-id field in a Response-PDU takes the
          value of the request-id field in the request PDU to which it
          is a response.  By use of the request-id value, a SMP
          application can distinguish the (potentially multiple)
          outstanding requests, and thereby correlate incoming responses
          with outstanding requests.  In cases where an unreliable
          datagram service is used, the request-id also provides a
          simple means of identifying messages duplicated by the
          network.  Use of the same request-id on a retransmission of a
          request allows the response to either the original
          transmission or the retransmission to satisfy the request.
          However, in order to calculate the round trip time for
          transmission and processing of a request-response transaction,
          the SMP application needs to use a different request-id value
          on a retransmitted request.  The latter strategy is
          recommended for use in the majority of situations.

          A non-zero value of the error-status field in a Response-PDU
          is used to indicate that an exception occurred to prevent the
          processing of the request.  In these cases, a non-zero value
          of the Response-PDU's error-index field provides additional
          information by identifying which variable binding in the list
          caused the exception.  A variable binding is identified by its
          index value.  The first variable binding in a variable-binding
          list is index one, the second is index two, etc.

          SMP limits OBJECT IDENTIFIER values to a maximum of 128 sub-
          identifiers, where each sub-identifier has a maximum value of
          2**32-1.


          5.2.  PDU Processing

          It is mandatory that all SMP entities acting in an agent role
          be able to generate the following PDU types: Response-PDU and
          SMP-Trap-PDU; further, all such implementations must be able
          to receive the following PDU types: GetRequest-PDU,
          GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.







                             Expires January 4, 1993           [Page 13]





          Draft            Protocol Operations for SMP            Jul 92


          It is mandatory that all SMP entities acting in a manager role
          be able to generate the following PDU types: GetRequest-PDU,
          GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
          InformRequest-PDU, and Response-PDU; further, all such
          implementations must be able to receive the following PDU
          types: Response-PDU, SMP-Trap-PDU, InformRequest-PDU;

          In the elements of procedure below, any field of a PDU which
          is not referenced by the relevant procedure is ignored by the
          receiving SMP entity.  However, all components of a PDU,
          including those whose values are ignored by the receiving SMP
          entity, must have valid ASN.1 syntax and encoding.  For
          example, some PDUs (e.g., the GetRequest-PDU) are concerned
          only with the name of a variable and not its value.  In this
          case, the value portion of the variable binding is ignored by
          the receiving SMP entity.  The unSpecified value is defined
          for use as the value portion of such bindings.

          For all generated PDUs, the message "wrapper" to encapsulate
          the PDU is generated and transmitted as specified in [2] (as
          modified in [9]).  The size of a message is limited only by
          constraints on the maximum message size, either a local
          limitation or the limit associated with the message's
          destination party, i.e., it is not limited by the number of
          variable bindings.

          On receiving a PDU, a SMP entity parses the encoded PDU.  If a
          parse error is detected, the PDU is discarded and the relevant
          error counter is incremented.  Otherwise, the PDU is processed
          according to its PDU type, in the authorization context of the
          source and destination parties given by the message "wrapper"
          which encapsulated the PDU.  By definition, this authorization
          context indicates whether the PDU type is authorized, and
          determines which variables are accessible by this request.
          For PDU types which are not authorized, either due to policy
          (e.g., a SetRequest-PDU in a read-only authorization context),
          or due to implementation constraints (e.g., a Response-PDU
          received by a SMP entity acting in an agent role), the PDU is
          discarded and the relevant error counter is incremented.  If
          the discarded PDU was one of following PDU types: GetRequest-
          PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
          or InformRequest-PDU, then a Response-PDU is generated and
          transmitted to the originator of the request.  This Response-
          PDU is formatted with the same values in its request-id and
          variable-bindings fields as the discarded PDU, with the value





                             Expires January 4, 1993           [Page 14]





          Draft            Protocol Operations for SMP            Jul 92


          of its error-status field set to `authorizationError', and the
          value of its error-index field set to zero.


          5.2.1.  The GetRequest-PDU

          A GetRequest-PDU is generated and transmitted at the request
          of a SMP application.

          Upon receipt of a GetRequest-PDU, the receiving SMP entity
          processes each variable binding in the variable-binding list
          to produce a Response-PDU.  All fields of the Response-PDU
          have the same values as the corresponding fields of the
          received request except as indicated below.  Each variable
          binding is processed as follows:

          (1)  If the variable binding's name does not have an OBJECT
               IDENTIFIER prefix which exactly matches the OBJECT
               IDENTIFIER prefix of any variable accessible by this
               request, then its value field is set to `noSuchObject'.

          (2)  Otherwise, if the variable binding's name does not
               exactly match the name of a variable accessible by this
               request, then its value field is set to `noSuchInstance'.

          (3)  Otherwise, the variable binding's value field is set to
               the value of the named variable.

          If the processing of any variable binding fails for a reason
          other than listed above, then the Response-PDU is re-formatted
          with the same values in its request-id and variable-bindings
          fields as the received GetRequest-PDU, with the value of its
          error-status field set to `genErr', and the value of its
          error-index field is set to the index of the failed variable
          binding.

          Otherwise, the value of the Response-PDU's error-status field
          is set to `noError', and the value of its error-index field is
          zero.

          The generated Response-PDU is then encapsulated into a
          message.  If the size of the resultant message is less than or
          equal to both a local constraint and the maximum message size
          of the request's source party, it is transmitted to the
          originator of the GetRequest-PDU.





                             Expires January 4, 1993           [Page 15]





          Draft            Protocol Operations for SMP            Jul 92


          Otherwise, an alternate Response-PDU is generated.  This
          alternate Response-PDU is formatted with the same value in its
          request-id field as the received GetRequest-PDU, with the
          value of its error-status field set to `tooBig', the value of
          its error-index field set to zero, and an empty variable-
          bindings field.  This alternate Response-PDU is then
          encapsulated into a message.  If the size of the resultant
          message is less than or equal to both a local constraint and
          the maximum message size of the request's source party, it is
          transmitted to the originator of the GetRequest-PDU.
          Otherwise, the resultant message is discarded.


          5.2.2.  The GetNextRequest-PDU

          A GetNextRequest-PDU is generated and transmitted at the
          request of a SMP application.

          Upon receipt of a GetNextRequest-PDU, the receiving SMP entity
          processes each variable binding in the variable-binding list
          to produce a Response-PDU.  All fields of the Response-PDU
          have the same values as the corresponding fields of the
          received request except as indicated below.  Each variable
          binding is processed as follows:

          (1)  The variable is located which is in the lexicographically
               ordered list of the names of all variables which are
               accessible by this request and whose name is the first
               lexicographic successor of the variable binding's name in
               the incoming GetNextRequest-PDU.  The corresponding
               variable binding's name and value fields in the
               Response-PDU are set to the name and value of the located
               variable.

          (2)  If the requested variable binding's name does not
               lexicographically precede the name of any variable
               accessible by this request, i.e., there is no
               lexicographic successor, then the corresponding variable
               binding produced in the Response-PDU has its value field
               set to `endOfMibView', and its name field set to the
               variable binding's name in the request.

          If the processing of any variable binding fails for a reason
          other than listed above, then the Response-PDU is re-formatted
          with the same values in its request-id and variable-bindings





                             Expires January 4, 1993           [Page 16]





          Draft            Protocol Operations for SMP            Jul 92


          fields as the received GetNextRequest-PDU, with the value of
          its error-status field set to `genErr', and the value of its
          error-index field is set to the index of the failed variable
          binding.

          Otherwise, the value of the Response-PDU's error-status field
          is set to `noError', and the value of its error-index field is
          zero.

          The generated Response-PDU is then encapsulated into a
          message.  If the size of the resultant message is less than or
          equal to both a local constraint and the maximum message size
          of the request's source party, it is transmitted to the
          originator of the GetNextRequest-PDU.

          Otherwise, an alternate Response-PDU is generated.  This
          alternate Response-PDU is formatted with the same values in
          its request-id field as the received GetRequest-PDU, with the
          value of its error-status field set to `tooBig', the value of
          its error-index field set to zero, and an empty variable-
          bindings field.  This alternate Response-PDU is then
          encapsulated into a message.  If the size of the resultant
          message is less than or equal to both a local constraint and
          the maximum message size of the request's source party, it is
          transmitted to the originator of the GetNextRequest-PDU.
          Otherwise, the resultant message is discarded.


          5.2.2.1.  Example of Table Traversal

          An important use of the GetNextRequest-PDU is the traversal of
          conceptual tables of information within a MIB.  The semantics
          of this type of request, together with the method of
          identifying individual instances of objects in the MIB,
          provides access to related objects in the MIB as if they
          enjoyed a tabular organization.

          In the protocol exchange sketched below, a SMP application
          retrieves the media-dependent physical address and the
          address-mapping type for each entry in the IP net-to-media
          Address Translation Table [10] of a particular network
          element.  It also retrieves the value of sysUpTime [10], at
          which the mappings existed.  Suppose that the agent's IP net-
          to-media table has three entries:






                             Expires January 4, 1993           [Page 17]





          Draft            Protocol Operations for SMP            Jul 92


            Interface-Number  Network-Address  Physical-Address  Type

                   1            10.0.0.51     00:00:10:01:23:45  static
                   1             9.2.3.4      00:00:10:54:32:10  dynamic
                   2            10.0.0.15     00:00:10:98:76:54  dynamic

          The SMP entity acting in a manager role begins by sending a
          GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER
          values as the requested variable names:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress,
                               ipNetToMediaType )

          The SMP entity acting in an agent role responds with a
          Response-PDU:

              Response (( sysUpTime.0 =  "123456" ),
                        ( ipNetToMediaPhysAddress.1.9.2.3.4 =
                                                   "000010543210" ),
                        ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ))

          The SMP entity acting in a manager role continues with:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.1.9.2.3.4,
                               ipNetToMediaType.1.9.2.3.4 )

          The SMP entity acting in an agent role responds with:

              Response (( sysUpTime.0 =  "123461" ),
                        ( ipNetToMediaPhysAddress.1.10.0.0.51 =
                                                    "000010012345" ),
                        ( ipNetToMediaType.1.10.0.0.51 =  "static" ))

          The SMP entity acting in a manager role continues with:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.1.10.0.0.51,
                               ipNetToMediaType.1.10.0.0.51 )










                             Expires January 4, 1993           [Page 18]





          Draft            Protocol Operations for SMP            Jul 92


          The SMP entity acting in an agent role responds with:

              Response (( sysUpTime.0 =  "123466" ),
                        ( ipNetToMediaPhysAddress.2.10.0.0.15 =
                                                     "000010987654" ),
                        ( ipNetToMediaType.2.10.0.0.15 =  "dynamic" ))

          The SMP entity acting in a manager role continues with:

              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.2.10.0.0.15,
                               ipNetToMediaType.2.10.0.0.15 )

          As there are no further entries in the table, the SMP entity
          acting in an agent role responds with the variables that are
          next in the lexicographical ordering of the accessible object
          names, for example:

              Response (( sysUpTime.0 =  "123471" ),
                        ( ipNetToMediaNetAddress.1.9.2.3.4 =
                                                         "9.2.3.4" ),
                        ( ipRoutingDiscards.0 =  "2" ))

          This response signals the end of the table to the SMP entity
          acting in a manager role.


          5.2.3.  The GetBulkRequest-PDU

          A GetBulkRequest-PDU is generated and transmitted at the
          request of a SMP application.  The purpose of the
          GetBulkRequest-PDU is to request the transfer of a potentially
          large amount of data, including, but not limited to, the
          efficient and rapid retrieval of large tables.

          Upon receipt of a GetBulkRequest-PDU, the receiving SMP entity
          processes each variable binding in the variable-binding list
          to produce a Response-PDU with its request-id field having the
          same value as in the request.  Processing begins by examining
          the values in the non-repeaters and max-repetitions fields.
          If the value in the non-repeaters field is less than zero,
          then the value of the field is set to zero.  Similarly, if the
          value in the max-repetitions field is less than zero, then the
          value of the field is set to zero.






                             Expires January 4, 1993           [Page 19]





          Draft            Protocol Operations for SMP            Jul 92


          For the GetBulkRequest-PDU type, the successful processing of
          each variable binding in the request generates zero or more
          variable bindings in the Response-PDU.  That is, the one-to-
          one mapping between the variable bindings of the GetRequest-
          PDU, GetNextRequest-PDU, and SetRequest-PDU types and the
          resultant Response-PDUs does not apply for the mapping between
          the variable bindings of a GetBulkRequest-PDU and the
          resultant Response-PDU.

          The values of the non-repeaters and max-repetitions fields in
          the request specify the processing requested.  One variable
          binding in the Response-PDU is requested for the first N
          variable bindings in the request and M variable bindings are
          requested for each of the R remaining variable bindings in the
          request.  Consequently, the total number of requested variable
          bindings communicated by the request is given by N + (M * R),
          where N is the minimum of: a) the value of the non-repeaters
          field in the request, and b) the number of variable bindings
          in the request; M is the value of the max-repetitions field in
          the request; and R is the maximum of: a) number of variable
          bindings in the request - N, and b)  zero.

          The receiving SMP entity produces a Response-PDU with up to
          the total number of requested variable bindings communicated
          by the request.  The request-id shall have the same value as
          the received GetBulkRequest-PDU.

          If N is greater than zero, the first through the (N)-th
          variable bindings of the Response-PDU are each produced as
          follows:

          (1)  The variable is located which is in the lexicographically
               ordered list of the names of all variables which are
               accessible by this request and whose name is the first
               lexicographic successor of the variable binding's name in
               the incoming GetBulkRequest-PDU.  The corresponding
               variable binding's name and value fields in the
               Response-PDU are set to the name and value of the located
               variable.

          (2)  If the requested variable binding's name does not
               lexicographically precede the name of any variable
               accessible by this request, i.e., there is no
               lexicographic successor, then the corresponding variable
               binding produced in the Response-PDU has its value field





                             Expires January 4, 1993           [Page 20]





          Draft            Protocol Operations for SMP            Jul 92


               set to `endOfMibView', and its name field set to the
               variable binding's name in the request.

          If M and R are non-zero, the (N + 1)-th and subsequent
          variable bindings of the Response-PDU are each produced in a
          similar manner.  For each iteration i, such that i is greater
          than zero and less than or equal to M, and for each repeated
          variable, r, such that r is greater than zero and less than or
          equal to R, the (N + ( (i-1) * R ) + r)-th variable binding of
          the Response-PDU is produced as follows:

          (1)  The variable which is in the lexicographically ordered
               list of the names of all variables which are accessible
               by this request and whose name is the (i)-th
               lexicographic successor of the (N + r)-th variable
               binding's name in the incoming GetBulkRequest-PDU is
               located and the variable binding's name and value fields
               are set to the name and value of the located variable.

          (2)  If there is no (i)-th lexicographic successor, then the
               corresponding variable binding produced in the Response-
               PDU has its value field set to `endOfMibView', and its
               name field set to either the last lexicographic
               successor, or if there are no lexicographic successors,
               to the (N + r)-th variable binding's name in the request.

          It should be noted that this algorithm allows at least two
          implementation strategies, so long as the variable bindings in
          the Response-PDU are ordered as specified above in all cases.
          First, an agent might attempt to locate one variable for the
          first N variables followed by attempts to locate one variable
          for each of the remaining R variable bindings, repeating M
          times.  An alternate strategy is to attempt to locate one
          variable for the first N variable bindings and to attempt to
          locate M variables for the remaining R variable bindings.
          That is, an implementer might choose to iterate within
          repetitions or to repeat within iterations.

          While the maximum number of variable bindings in the
          Response-PDU is bounded by N + (M * R), the response may be
          generated with a lesser number of variable bindings (possibly
          zero) for either of two reasons.

          (1)  If the size of the message encapsulating the Response-PDU
               containing the requested number of variable bindings





                             Expires January 4, 1993           [Page 21]





          Draft            Protocol Operations for SMP            Jul 92


               would be greater than either a local constraint or the
               maximum message size of the request's source party, then
               the response is generated with a lesser number of
               variable bindings.  This lesser number is the ordered set
               of variable bindings with some of the variable bindings
               at the end of the set removed, such that the size of the
               message encapsulating the Response-PDU is approximately
               equal to but no greater than the minimum of the local
               constraint and the maximum message size of the request's
               source party.  Note that the number of variable bindings
               removed has no relationship to the values of N, M, or R.

          (2)  The response may also be generated with a lesser number
               of variable bindings if for some value of iteration i,
               such that i is greater than zero and less than or equal
               to M, that all of the generated variable bindings have
               the value field set to the `endOfMibView'.  In this case,
               the variable bindings may be truncated after the (N + (i
               * R))-th variable binding.

          If the processing of any variable binding fails for a reason
          other than listed above, then the Response-PDU is re-formatted
          with the same values in its request-id and variable-bindings
          fields as the received GetBulkRequest-PDU, with the value of
          its error-status field set to `genErr', and the value of its
          error-index field is set to the index of the failed variable
          binding.

          Otherwise, the value of the Response-PDU's error-status field
          is set to `noError', and the value of its error-index field to
          zero.

          The generated Response-PDU (possibly with an empty variable-
          bindings field) is then encapsulated into a message.  If the
          size of the resultant message is less than or equal to both a
          local constraint and the maximum message size of the request's
          source party, it is transmitted to the originator of the
          GetBulkRequest-PDU.  Otherwise, the resultant message is
          discarded.


          5.2.3.1.  Another Example of Table Traversal

          This example demonstrates how the GetBulkRequest-PDU can be
          used as an alternative to the GetNextRequest-PDU.  The same





                             Expires January 4, 1993           [Page 22]





          Draft            Protocol Operations for SMP            Jul 92


          traversal of the IP net-to-media table as shown in Section
          5.2.2.1 is achieved with fewer exchanges.

          The SMP entity acting in a manager role begins by sending a
          GetBulkRequest-PDU with the modest max-repetitions value of 2,
          and containing the indicated OBJECT IDENTIFIER values as the
          requested variable names:

              GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                              ( sysUpTime,
                                ipNetToMediaPhysAddress,
                                ipNetToMediaType )

          The SMP entity acting in an agent role responds with a
          Response-PDU:

              Response (( sysUpTime.0 =  "123456" ),
                        ( ipNetToMediaPhysAddress.1.9.2.3.4 =
                                                   "000010543210" ),
                        ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ),
                        ( ipNetToMediaPhysAddress.1.10.0.0.51 =
                                                    "000010012345" ),
                        ( ipNetToMediaType.1.10.0.0.51 =  "static" ))

          The SMP entity acting in a manager role continues with:

              GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                              ( sysUpTime,
                                ipNetToMediaPhysAddress.1.10.0.0.51,
                                ipNetToMediaType.1.10.0.0.51 )

          The SMP entity acting in an agent role responds with:

              Response (( sysUpTime.0 =  "123466" ),
                        ( ipNetToMediaPhysAddress.2.10.0.0.15 =
                                                   "000010987654" ),
                        ( ipNetToMediaType.2.10.0.0.15 =
                                                        "dynamic" ),
                        ( ipNetToMediaNetAddress.1.9.2.3.4 =
                                                        "9.2.3.4" ),
                        ( ipRoutingDiscards.0 =  "2" ))

          This response signals the end of the table to the SMP entity
          acting in a manager role.






                             Expires January 4, 1993           [Page 23]





          Draft            Protocol Operations for SMP            Jul 92


          5.2.4.  The Response-PDU

          The Response-PDU is generated by a SMP entity only upon
          receipt of a GetRequest-PDU, GetNextRequest-PDU,
          GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, as
          described elsewhere in this document.

          If the error-status field of the Response-PDU is non-zero, the
          value fields of the variable bindings in the variable binding
          list are ignored.

          If both the error-status field and the error-index field of
          the Response-PDU are non-zero, then the value of the error-
          index field is the index of the variable binding (in the
          variable-binding list of the corresponding request) for which
          the request failed.  The first variable binding in a request's
          variable-binding list is index one, the second is index two,
          etc.

          Upon receipt of a Response-PDU, the receiving SMP entity
          presents its contents to the SMP application which generated
          the request with the same request-id value.


          5.2.5.  The SetRequest-PDU

          A SetRequest-PDU is generated and transmitted at the request
          of a SMP application.

          Upon receipt of a SetRequest-PDU, the receiving SMP entity
          determines the size of a message encapsulating a Response-PDU
          with the same values in its request-id, error-status, error-
          index and variable-bindings fields as the received
          SetRequest-PDU.  If the determined message size is greater
          than either a local constraint or the maximum message size of
          the request's source party, then an alternate Response-PDU is
          generated, transmitted to the originator of the SetRequest-
          PDU, and processing of the SetRequest-PDU terminates
          immediately thereafter.  This alternate Response-PDU is
          formatted with the same values in its request-id field as the
          received SetRequest-PDU, with the value of its error-status
          field set to `tooBig', the value of its error-index field set
          to zero, and an empty variable-bindings field.  This alternate
          Response-PDU is then encapsulated into a message.  If the size
          of the resultant message is less than or equal to both a local





                             Expires January 4, 1993           [Page 24]





          Draft            Protocol Operations for SMP            Jul 92


          constraint and the maximum message size of the request's
          source party, it is transmitted to the originator of the
          SetRequest-PDU.  Otherwise, the resultant message is
          discarded.  Regardless, processing of the SetRequest-PDU
          terminates.

          Otherwise, the receiving SMP entity processes each variable
          binding in the variable-binding list to produce a Response-
          PDU.  All fields of the Response-PDU have the same values as
          the corresponding fields of the received request except as
          indicated below.

          The variable bindings are conceptually processed as a two
          phase operation.  In the first phase, each variable binding is
          validated; if all validations are successful, then each
          variable is altered in the second phase.

          The following validations are performed in the first phase on
          each variable binding until they are all successful, or until
          one fails:

          (1)  If the variable binding's name specifies a variable which
               is not accessible by this request, then the value of the
               Response-PDU's error-status field is set to `noAccess',
               and the value of its error-index field is set to the
               index of the failed variable binding.

          (2)  Otherwise, if the variable binding's name specifies a
               variable which does not exist and could not ever be
               created, then the value of the Response-PDU's error-
               status field is set to `noCreation', and the value of its
               error-index field is set to the index of the failed
               variable binding.

          (3)  Otherwise, if the variable binding's name specifies a
               variable which exists but can not be modified no matter
               what new value is specified, then the value of the
               Response-PDU's error-status field is set to
               `notWritable', and the value of its error-index field is
               set to the index of the failed variable binding.

          (4)  Otherwise, if the variable binding's value field
               specifies, according to the ASN.1 language, a type which
               is inconsistent with that required for the variable, then
               the value of the Response-PDU's error-status field is set





                             Expires January 4, 1993           [Page 25]





          Draft            Protocol Operations for SMP            Jul 92


               to `wrongType', and the value of its error-index field is
               set to the index of the failed variable binding.

          (5)  Otherwise, if the variable binding's value field
               specifies, according to the ASN.1 language, a length
               which is inconsistent with that required for the
               variable, then the value of the Response-PDU's error-
               status field is set to `wrongLength', and the value of
               its error-index field is set to the index of the failed
               variable binding.

          (6)  Otherwise, if the variable binding's value field contains
               an ASN.1 encoding which is inconsistent with that field's
               ASN.1 tag, then: the value of the Response-PDU's error-
               status field is set to `wrongEncoding', and the value of
               its error-index field is set to the index of the failed
               variable binding.

          (7)  Otherwise, if the variable binding's value field
               specifies a value which could under no circumstances be
               assigned to the variable, then: the value of the
               Response-PDU's error-status field is set to `wrongValue',
               and the value of its error-index field is set to the
               index of the failed variable binding.

          (8)  Otherwise, if the variable binding's value field
               specifies a value that could under other circumstances be
               assigned to the variable, but is presently inconsistent,
               then the value of the Response-PDU's error-status field
               is set to `inconsistentValue', and the value of its
               error-index field is set to the index of the failed
               variable binding.

          (9)  Otherwise, if the assignment of the value specified by
               the variable binding's value field to the specified
               variable requires the allocation of a resource which is
               presently unavailable, then: the value of the Response-
               PDU's error-status field is set to `resourceUnavailable',
               and the value of its error-index field is set to the
               index of the failed variable binding.

          (10) If the processing of the variable binding fails for a
               reason other than listed above, then the value of the
               Response-PDU's error-status field is set to `genErr', and
               the value of its error-index field is set to the index of





                             Expires January 4, 1993           [Page 26]





          Draft            Protocol Operations for SMP            Jul 92


               the failed variable binding.

          (11) Otherwise, the validation of the variable binding
               succeeds.

          At the end of the first phase, if the validation of all
          variable bindings succeeded, then:

          The value of the Response-PDU's error-status field is set to
          `noError' and the value of its error-index field is zero.

          For each variable binding in the request, the named variable
          is created if necessary, and the specified value is assigned
          to it.  Each of these variable assignments occurs as if
          simultaneously with respect to all other assignments specified
          in the same request.  However, if the same variable is named
          more than once in a single request, with different associated
          values, then the actual assignment made to that variable is
          implementation-specific.

          If any of these assignments fail (even after all the previous
          validations), then all other assignments are undone, and the
          Response-PDU is modified to have the value of its error-status
          field set to `commitFailed', and the value of its error-index
          field set to the index of the failed variable binding.

          If and only if it is not possible to undo all the assignments,
          then the Response-PDU is modified to have the value of its
          error-status field set to `undoFailed', and the value of its
          error-index field set to the index of the (first) variable
          binding for which the assignment couldn't be undone.  Note
          that implementations are strongly encouraged to take all
          possible measures to avoid use of this error-status.

          Finally, the generated Response-PDU is encapsulated into a
          message, and transmitted to the originator of the SetRequest-
          PDU.


          5.2.6.  The SMP-Trap-PDU

          A SMP-Trap-PDU is generated and transmitted by a SMP entity
          acting in an agent role when an unusual event occurs.







                             Expires January 4, 1993           [Page 27]





          Draft            Protocol Operations for SMP            Jul 92


          Section 6.4 of [3] describes how the request-id and variable-
          bindings fields of the SMP-Trap-PDU are constructed, and also
          how the destinations for the SMP-Trap-PDU are determined.


          5.2.7.  The InformRequest-PDU

          An InformRequest-PDU is generated and transmitted at the
          request an application in a SMP entity acting in a manager
          role, that wishes to notify another application (in a SMP
          entity also acting in a manager role) of information in the
          MIB View of a party local to the sending application.

          Upon receipt of an InformRequest-PDU, the receiving SMP entity
          determines the size of a message encapsulating a Response-PDU
          with the same values in its request-id, error-status, error-
          index and variable-bindings fields as the received
          InformRequest-PDU.  If the determined message size is greater
          than either a local constraint or the maximum message size of
          the request's source party, then an alternate Response-PDU is
          generated, transmitted to the originator of the
          InformRequest-PDU, and processing of the InformRequest-PDU
          terminates immediately thereafter.  This alternate Response-
          PDU is formatted with the same values in its request-id field
          as the received InformRequest-PDU, with the value of its
          error-status field set to `tooBig', the value of its error-
          index field set to zero, and an empty variable-bindings field.
          This alternate Response-PDU is then encapsulated into a
          message.  If the size of the resultant message is less than or
          equal to both a local constraint and the maximum message size
          of the request's source party, it is transmitted to the
          originator of the InformRequest-PDU.  Otherwise, the resultant
          message is discarded.  Regardless, processing of the
          InformRequest-PDU terminates.

          Otherwise, the receiving SMP entity:

          (1)  presents its contents to the appropriate SMP application;

          (2)  generates a Response-PDU with the same values in its
               request-id and variable-bindings fields as the received
               InformRequest-PDU, with the value of its error-status
               field is set to `noError' and the value of its error-
               index field is zero; and






                             Expires January 4, 1993           [Page 28]





          Draft            Protocol Operations for SMP            Jul 92


          (3)  transmits the generated Response-PDU to the originator of
               the InformRequest-PDU.

          The destination(s) to which an InformRequest-PDU is sent is
          determined by inspecting the smpEventNotifyTable [11], or as
          specified by the requesting application.

          The first two variable bindings in the variable binding list
          of an InformRequest-PDU are sysUpTime.0 [10] and smpEventID.i
          [11] respectively.  The other variable bindings to be included
          in the variable binding list are specified by the requesting
          application.






































                             Expires January 4, 1993           [Page 29]





          Draft            Protocol Operations for SMP            Jul 92


          6.  Acknowledgements

          This document is based, in part, on RFC 1157.  The mechanism
          for bulk retrieval is influenced by many experiments,
          including RFC1187 and also Greg Satz's work on SNMP over TCP.













































                             Expires January 4, 1993           [Page 30]





          Draft            Protocol Operations for SMP            Jul 92


          7.  References

          [1]  Information processing systems - Open Systems
               Interconnection - Specification of Abstract Syntax
               Notation One (ASN.1), International Organization for
               Standardization.  International Standard 8824, (December,
               1987).

          [2]  J.R. Davin, J.M. Galvin, K. McCloghrie, SNMP
               Administrative Model.  Request for Comments 1351, (July,
               1992).

          [3]  J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Structure of Management Information for the Simple
               Management Protocol (SMP) Framework, (July, 1992).

          [4]  J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Textual Conventions for the Simple Management Protocol
               (SMP) Framework, (July, 1992).

          [5]  K. McCloghrie, J.R. Davin, J.M. Galvin, Definitions of
               Managed Objects for Administration of SNMP Parties.
               Request for Comments 1353, (July, 1992).

          [6]  C. Kent, J. Mogul, Fragmentation Considered Harmful,
               Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).

          [7]  J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Transport Mappings for the Simple Management Protocol
               (SMP) Framework, (July, 1992).

          [8]  J. Postel, User Datagram Protocol.  Request for Comments
               768, (November 1980).

          [9]  J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Introduction to the Simple Management Protocol (SMP)
               Framework, (July, 1992).

          [10] 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).

          [11] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Manager to Manager Management Information Base for the
               Simple Management Protocol (SMP) Framework, (July, 1992).





                             Expires January 4, 1993           [Page 31]





          Draft            Protocol Operations for SMP            Jul 92


          Table of Contents


          1 Status of this Memo ...................................    1
          2 Introduction ..........................................    3
          3 Overview ..............................................    4
          3.1 Roles of Protocol Entities ..........................    4
          3.2 Management Information ..............................    4
          3.3 Access to Management Information ....................    5
          3.4 Retransmission of Requests ..........................    5
          3.5 Message Sizes .......................................    5
          3.6 Transport Mappings ..................................    6
          4 Definitions ...........................................    8
          5 Protocol Specification ................................   13
          5.1 Common Constructs ...................................   13
          5.2 PDU Processing ......................................   13
          5.2.1 The GetRequest-PDU ................................   15
          5.2.2 The GetNextRequest-PDU ............................   16
          5.2.2.1 Example of Table Traversal ......................   17
          5.2.3 The GetBulkRequest-PDU ............................   19
          5.2.3.1 Another Example of Table Traversal ..............   22
          5.2.4 The Response-PDU ..................................   24
          5.2.5 The SetRequest-PDU ................................   24
          5.2.6 The SMP-Trap-PDU ..................................   27
          5.2.7 The InformRequest-PDU .............................   28
          6 Acknowledgements ......................................   30
          7 References ............................................   31























                             Expires January 4, 1993           [Page 32]