[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 02 RFC 1448

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
                               Protocol Operations
                               for version 2 of the
                   Simple Network Management Protocol (SNMPv2)
          
                             Thu Nov 12 08:51:15 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 valid for a maximum of six months and may
          be updated, replaced, or obsoleted by other documents at any
          time.  It is inappropriate to use Internet Drafts as reference
          material or to cite them other than as a "work in progress".
          
          
          
          
          
          
                               Expires May 12, 1993             [Page 1]
          

          Draft           Protocol Operations for SNMPv2          Oct 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], termed the Structure of Management Information (SMI) [2].
          
          The management protocol, version 2 of the Simple Network
          Management Protocol, 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
          SNMPv2, to define the operations of the protocol with respect
          to the sending and receiving of the PDUs.                       +
          
          
          2.1.  A Note on Terminology                                     +
          
          For the purpose of exposition, the original Internet-standard   +
          Network Management Framework, as described in RFCs 1155, 1157,  +
          and 1212, is termed the SNMP version 1 framework (SNMPv1).      +
          The current framework is termed the SNMP version 2 framework    +
          
          
          
          
          
                               Expires May 12, 1993             [Page 2]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          (SNMPv2).                                                       +
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993             [Page 3]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          3.  Overview
          
          3.1.  Roles of Protocol Entities
          
          A SNMPv2 entity may operate in a manager role or an agent
          role.
          
          A SNMPv2 entity acts in an agent role when it performs SNMPv2
          management operations in response to received SNMPv2 protocol
          messages (other than an inform notification) or when it sends
          trap notifications.
          
          A SNMPv2 entity acts in a manager role when it initiates
          SNMPv2 management operations by the generation of SNMPv2
          protocol messages or when it performs SNMPv2 management
          operations in response to received trap or inform
          notifications.
          
          A SNMPv2 entity may support either or both roles, as dictated
          by its implementation and configuration.  Further, a SNMPv2
          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 [3].
          
          
          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 [2] 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
          
          
          
          
          
                               Expires May 12, 1993             [Page 4]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          prefix of the variable.
          
          
          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 SNMPv2 entity, acting in a manager role, sends a
          request to a SNMPv2 entity, acting in an agent role, and the
          latter SNMPv2 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 SNMPv2 entity, acting in a manager role, sends a request to
          a SNMPv2 entity, also acting in a manager role, and the latter
          SNMPv2 entity then responds to the request.  This type is used
          to notify a SNMPv2 entity, acting in a manager role, of
          management information associated with another SNMPv2 entity,
          also acting in a manager role.
          
          The third type of access is an unconfirmed interaction, in
          which a SNMPv2 entity, acting in an agent role, sends a
          unsolicited message, termed a trap, to a SNMPv2 entity, acting
          in a manager role, and no response is returned.  This type is
          used to notify a SNMPv2 entity, acting in a manager role, of
          an exceptional situation, 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.
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993             [Page 5]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          3.5.  Message Sizes
          
          The maximum size of an SNMPv2 message is limited the minimum
          of:
          
          (1)  the maximum message size which the destination SNMPv2
               entity can accept; and,
          
          (2)  the maximum message size which the source SNMPv2 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 SNMPv2 indicates the minimum
          message size which a SNMPv2 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 SNMPv2 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 SNMPv2 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 SNMPv2 entity acting in an agent role can generate, and
          the SNMPv2 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 SNMPv2 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.
          
          
          
          
          
          
          
                               Expires May 12, 1993             [Page 6]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          3.6.  Transport Mappings
          
          It is important to note that the exchange of SNMPv2 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
          rules are specified elsewhere [7].  However, the preferred
          mapping is the use of the User Datagram Protocol [8].
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993             [Page 7]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          4.  Definitions
          
               SNMPv2-PDU DEFINITIONS ::= BEGIN
          
               IMPORTS
                   ObjectName, ObjectSyntax, Integer32
                       FROM SNMPv2-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
                           SNMPv2-Trap-PDU
                   }
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993             [Page 8]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
               -- PDUs
          
               GetRequest-PDU ::=
                   [0]
                       IMPLICIT PDU
          
               GetNextRequest-PDU ::=
                   [1]
                       IMPLICIT PDU
          
               Response-PDU ::=
                   [2]
                       IMPLICIT PDU
          
               SetRequest-PDU ::=
                   [3]
                       IMPLICIT PDU
          
               -- [4] is obsolete
          
               GetBulkRequest-PDU ::=
                   [5]
                       IMPLICIT BulkPDU
          
               InformRequest-PDU ::=
                   [6]
                       IMPLICIT PDU
          
               SNMPv2-Trap-PDU ::=
                   [7]
                       IMPLICIT PDU
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993             [Page 9]
          

          Draft           Protocol Operations for SNMPv2          Oct 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
                               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 May 12, 1993            [Page 10]
          

          Draft           Protocol Operations for SNMPv2          Oct 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 May 12, 1993            [Page 11]
          

          Draft           Protocol Operations for SNMPv2          Oct 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 May 12, 1993            [Page 12]
          

          Draft           Protocol Operations for SNMPv2          Oct 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 SNMPv2
          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 SNMPv2 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.
          
          SNMPv2 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 SNMPv2 entities acting in an agent
          role be able to generate the following PDU types: Response-PDU
          and SNMPv2-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 May 12, 1993            [Page 13]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          It is mandatory that all SNMPv2 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, SNMPv2-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 SNMPv2 entity.  However, all components of a PDU,
          including those whose values are ignored by the receiving
          SNMPv2 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 SNMPv2 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 [3] (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 SNMPv2 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 SNMPv2 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
          
          
          
          
          
                               Expires May 12, 1993            [Page 14]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          discarded PDU, with the value 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 SNMPv2 application.
          
          Upon receipt of a GetRequest-PDU, the receiving SNMPv2 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
          
          
          
          
          
                               Expires May 12, 1993            [Page 15]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          originator of the GetRequest-PDU.
          
          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 SNMPv2 application.
          
          Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2
          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.
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 16]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          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 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 SNMPv2 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
          
          
          
          
          
                               Expires May 12, 1993            [Page 17]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          which the mappings existed.  Suppose that the agent's IP net-
          to-media table has three entries:
          
            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 SNMPv2 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 SNMPv2 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 SNMPv2 entity acting in a manager role continues with:
          
              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.1.9.2.3.4,
                               ipNetToMediaType.1.9.2.3.4 )
          
          The SNMPv2 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 SNMPv2 entity acting in a manager role continues with:
          
              GetNextRequest ( sysUpTime,
                               ipNetToMediaPhysAddress.1.10.0.0.51,
                               ipNetToMediaType.1.10.0.0.51 )
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 18]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          The SNMPv2 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 SNMPv2 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 SNMPv2
          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 SNMPv2
          entity acting in a manager role.
          
          
          5.2.3.  The GetBulkRequest-PDU
          
          A GetBulkRequest-PDU is generated and transmitted at the
          request of a SNMPv2 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 SNMPv2
          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 May 12, 1993            [Page 19]
          

          Draft           Protocol Operations for SNMPv2          Oct 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 SNMPv2 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 May 12, 1993            [Page 20]
          

          Draft           Protocol Operations for SNMPv2          Oct 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.
          
          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
               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.
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 21]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          (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
          traversal of the IP net-to-media table as shown in Section
          5.2.2.1 is achieved with fewer exchanges.
          
          The SNMPv2 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 )
          
          
          
          
          
                               Expires May 12, 1993            [Page 22]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          The SNMPv2 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 SNMPv2 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 SNMPv2 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 SNMPv2
          entity acting in a manager role.
          
          
          5.2.4.  The Response-PDU
          
          The Response-PDU is generated by a SNMPv2 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.
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 23]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          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.
          
          A compliant SNMPv2 entity acting in a manager role must be
          able to properly receive and handle a Response-PDU with an
          error-status field equal to `noSuchName' or `badValue'.  (See
          Section 4.1.2 of [11].)
          
          Upon receipt of a Response-PDU, the receiving SNMPv2 entity
          presents its contents to the SNMPv2 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 SNMPv2 application.
          
          Upon receipt of a SetRequest-PDU, the receiving SNMPv2 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
          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.
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 24]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          Otherwise, the receiving SNMPv2 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
               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
          
          
          
          
          
                               Expires May 12, 1993            [Page 25]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
               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
               the failed variable binding.
          
          (11) Otherwise, the validation of the variable binding
               succeeds.
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 26]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          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 SNMPv2-Trap-PDU
          
          A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2
          entity acting in an agent role when an exceptional situation
          occurs.
          
          The destination(s) to which an SNMPv2-Trap-PDU is sent is
          determined by consulting the aclTable [5] to find all entries
          satisfying the following conditions:
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 27]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          (1)  The value of aclSubject refers to the SNMPv2 entity.
          
          (2)  The value of aclPrivileges allows for the SNMPv2-Trap-
               PDU.
          
          (3)  The notification's administratively assigned name is
               present in aclSubject's view.  (That is, the set of
               entries in the viewTable [5] for which the instance of
               viewParty has the same value as aclSubject, define a MIB
               view which contains the notification's administratively
               assigned name.)
          
          (4)  If the OBJECTS clause is present in the invocation of the
               corresponding NOTIFICATION-TYPE macro, then the
               correspondent variables are all present in aclSubject's
               view.
          
          Then, for each entry satisfying these conditions, a SNMPv2-
          Trap-PDU is sent from aclSubject to aclTarget.  The instance
          of snmpTrapNumbers [12] corresponding to aclTarget is
          incremented, and is used as the request-id field of the
          SNMPv2-Trap-PDU.  Then, the variable-bindings field are
          constructed as:
          
          (1)  The first variable is sysUpTime.0 [10].
          
          (2)  The second variable is snmpTrapOID.0 [12], which contains
               the administratively assigned name of the notification.
          
          (3)  If the OBJECTS clause is present in the invocation of the
               corresponding NOTIFICATION-TYPE macro, then each
               corresponding variable is copied, in order, to the
               variable-bindings field.
          
          (4)  At the option of the SNMPv2 entity acting in an agent
               role, additional variables may follow in the variable-
               bindings field.
          
          
          5.2.7.  The InformRequest-PDU
          
          An InformRequest-PDU is generated and transmitted at the
          request an application in a SNMPv2 entity acting in a manager
          role, that wishes to notify another application (in a SNMPv2
          entity also acting in a manager role) of information in the
          
          
          
          
          
                               Expires May 12, 1993            [Page 28]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          MIB View of a party local to the sending application.
          
          The destination(s) to which an InformRequest-PDU is sent is
          determined by inspecting the snmpEventNotifyTable [13], 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 snmpEventID.i [13]
          respectively.  If the OBJECTS clause is present in the
          invocation of the corresponding NOTIFICATION-TYPE macro, then
          each corresponding variable, as instantiated by this
          notification, is copied, in order, to the variable-bindings
          field.
          
          Upon receipt of an InformRequest-PDU, the receiving SNMPv2
          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 SNMPv2 entity:
          
          (1)  presents its contents to the appropriate SNMPv2
               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 May 12, 1993            [Page 29]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          (3)  transmits the generated Response-PDU to the originator of
               the InformRequest-PDU.
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 30]
          

          Draft           Protocol Operations for SNMPv2          Oct 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.
          
          Finally, the comments of the SNMP Version 2 working group are
          gratefully acknowledged:
          
               Steve Alexander, Interactive Systems
               Uri Blumenthal, International Business Machines
               Jeffrey D. Case, SNMP Research, Inc.
               Tracy Cox, Bellcore
               James R. (Chuck) Davin, Bellcore
               Mike Davison, FiberCom
               Taso N. Devetzis, Bellcore
               Gary W. Haney, Martin Marietta Energy Systems
               Matt Hecht, SNMP Research, Inc.
               Susan E. Hicks, Martin Marietta Energy Systems
               Satish Joshi, SynOptics
               Mark Kepke, Hewlett-Packard
               Ken Key, SNMP Research, Inc.
               Michael Kornegay, Visisoft
               Deidre C. Kostick, Bellcore
               Cheryl Krupczak, Georgia Tech
               Robert C. Lushbaugh, Martin Marietta Energy Systems
               Keith McCloghrie, Hughes LAN Systems
               Dave Minnich, FiberCom
               Dave Perkins, SynOptics
               Marshall T. Rose, Dover Beach Consulting, Inc.
               Shawn A. Routhier, Epilogue Technology
               Jon Saperia, Digital Equipment Corporation
               Bob Stewart, Xyplex (chair)
               Robert Synder, Cisco Systems
               Maurice Turcotte, Racal Datacom
               Steven L. Waldbusser, Carnegie Mellon University
               Bert Wijnen, International Business Machines
               Peter Wilson, 3Com
               Steven Wong, Digital Equipment Corporation
               Chris Young, Cabletron
               Kiho Yum, 3Com
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 31]
          

          Draft           Protocol Operations for SNMPv2          Oct 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.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Structure of Management Information for version 2 of the
               Simple Network Management Protocol, Internet-Draft,
               (October 7, 1992).
          
          [3]  J.R. Davin, J.M. Galvin, K. McCloghrie, SNMP
               Administrative Model.  Request for Comments 1351, (July,
               1992).
          
          [4]  J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Textual Conventions for version 2 of the the Simple
               Network Management Protocol (SNMPv2), Internet-Draft,
               (October 7, 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 version 2 of the Simple Network
               Management Protocol (SNMPv2), Internet-Draft, (October 7,
               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 version 2 of the Internet-standard
               Network Management Framework, Internet-Draft, (October 7,
               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).
          
          
          
          
          
                               Expires May 12, 1993            [Page 32]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          [11] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Coexistence between version 1 and version 2 of the
               Internet-standard Network Management Framework,
               Internet-Draft, (October 7, 1992).
          
          [12] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Management Information Base for version 2 of the Simple
               Network Management Protocol, Internet-Draft, (October 7,
               1992).
          
          [13] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser,
               Manager to Manager Management Information Base,
               Internet-Draft, (October 7, 1992).
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 33]
          

          Draft           Protocol Operations for SNMPv2          Oct 92
          
          
          Table of Contents
          
          
          1 Status of this Memo ...................................    1
          2 Introduction ..........................................    2
          2.1 A Note on Terminology ...............................    2
          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 .......................................    6
          3.6 Transport Mappings ..................................    7
          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 ..................................   23
          5.2.5 The SetRequest-PDU ................................   24
          5.2.6 The SNMPv2-Trap-PDU ...............................   27
          5.2.7 The InformRequest-PDU .............................   28
          6 Acknowledgements ......................................   31
          7 References ............................................   32
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
                               Expires May 12, 1993            [Page 34]
          

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/