rfc1905.txt

RFC 的详细文档！

SNMPv2 Working Group        Standards Track                     [Page 6]

RFC 1905             Protocol Operations for SNMPv2         January 1996


                     noAccess(6),
                     wrongType(7),
                     wrongLength(8),
                     wrongEncoding(9),
                     wrongValue(10),
                     noCreation(11),
                     inconsistentValue(12),
                     resourceUnavailable(13),
                     commitFailed(14),
                     undoFailed(15),
                     authorizationError(16),
                     notWritable(17),
                     inconsistentName(18)
                 },

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

             variable-bindings   -- values are sometimes ignored
                 VarBindList
         }


     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
         }


     -- variable binding

     VarBind ::=
         SEQUENCE {
             name
                 ObjectName,

             CHOICE {
                 value



SNMPv2 Working Group        Standards Track                     [Page 7]

RFC 1905             Protocol Operations for SNMPv2         January 1996


                     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


4.  Protocol Specification

4.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.





SNMPv2 Working Group        Standards Track                     [Page 8]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   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.

4.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.

   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.

   On generating a management communication, the message "wrapper" to
   encapsulate the PDU is generated according to the "Elements of
   Procedure" of the administrative framework in use is followed.  While
   the definition of "max-bindings" does impose an upper-bound on the
   number of variable bindings, in practice, the size of a message is
   limited only by constraints on the maximum message size -- it is not
   limited by the number of variable bindings.




SNMPv2 Working Group        Standards Track                     [Page 9]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   On receiving a management communication, the "Elements of Procedure"
   of the administrative framework in use is followed, and if those
   procedures indicate that the operation contained within the message
   is to be performed locally, then those procedures also indicate the
   MIB view which is visible to the operation.

4.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 exactly matches the name of a
     variable accessible by this request, then the variable binding's
     value field is set to the value of the named variable.

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

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

   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 originator, it
   is transmitted to the 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



SNMPv2 Working Group        Standards Track                    [Page 10]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   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 originator, it is transmitted to
   the originator of the GetRequest-PDU.  Otherwise, the snmpSilentDrops
   [9] counter is incremented and the resultant message is discarded.

4.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.

   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 originator, it
   is transmitted to the originator of the GetNextRequest-PDU.





SNMPv2 Working Group        Standards Track                    [Page 11]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   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 GetNextRequest-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 originator, it is
   transmitted to the originator of the GetNextRequest-PDU.  Otherwise,
   the snmpSilentDrops [9] counter is incremented and the resultant
   message is discarded.

4.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 [7] of a particular network element.  It also
   retrieves the value of sysUpTime [9], at 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" ))



SNMPv2 Working Group        Standards Track                    [Page 12]