rfc3416.txt

开发snmp的开发包有两个开放的SNMP开发库

   ObjectSyntax ::= CHOICE {
         simple           SimpleSyntax,
         application-wide ApplicationSyntax }

   SimpleSyntax ::= CHOICE {
         integer-value   INTEGER (-2147483648..2147483647),
         string-value    OCTET STRING (SIZE (0..65535)),
         objectID-value  OBJECT IDENTIFIER }

   ApplicationSyntax ::= CHOICE {
         ipAddress-value        IpAddress,
         counter-value          Counter32,
         timeticks-value        TimeTicks,
         arbitrary-value        Opaque,
         big-counter-value      Counter64,
         unsigned-integer-value Unsigned32 }




Presuhn, et al.             Standards Track                     [Page 6]

RFC 3416              Protocol Operations for SNMP         December 2002


   IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))

   Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)

   Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)

   Gauge32 ::= Unsigned32

   TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)

   Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING

   Counter64 ::= [APPLICATION 6]
                 IMPLICIT INTEGER (0..18446744073709551615)

   -- 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,
        snmpV2-trap      SNMPv2-Trap-PDU,
        report           Report-PDU }

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

   --   Usage and precise semantics of Report-PDU are not defined
   --   in this document.  Any SNMP administrative framework making
   --   use of this PDU must define its usage and semantics.



Presuhn, et al.             Standards Track                     [Page 7]

RFC 3416              Protocol Operations for SNMP         December 2002


   Report-PDU ::= [8] IMPLICIT PDU

   max-bindings INTEGER ::= 2147483647

   PDU ::= SEQUENCE {
           request-id INTEGER (-214783648..214783647),

           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),
                   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      INTEGER (-214783648..214783647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

   -- variable binding



Presuhn, et al.             Standards Track                     [Page 8]

RFC 3416              Protocol Operations for SNMP         December 2002


   VarBind ::= SEQUENCE {
           name ObjectName,

           CHOICE {
               value          ObjectSyntax,
               unSpecified    NULL,    -- in retrieval requests

                                       -- 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, an 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 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 error 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 error.  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.




Presuhn, et al.             Standards Track                     [Page 9]

RFC 3416              Protocol Operations for SNMP         December 2002


   SNMP 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

   In the elements of procedure below, any field of a PDU which is not
   referenced by the relevant procedure is ignored by the receiving SNMP
   entity.  However, all components of a PDU, including those whose
   values are ignored by the receiving SNMP 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 SNMP 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.  The definition of
   "max-bindings" imposes an upper bound on the number of variable
   bindings.  In practice, the size of a message is also limited by
   constraints on the maximum message size.  A compliant implementation
   must support as many variable bindings in a PDU or BulkPDU as fit
   into the overall maximum message size limit of the SNMP engine, but
   no more than 2147483647 variable bindings.

   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 an
   application.

   Upon receipt of a GetRequest-PDU, the receiving SNMP 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.




Presuhn, et al.             Standards Track                    [Page 10]

RFC 3416              Protocol Operations for SNMP         December 2002


   (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
   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
   [RFC3418] 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
   an application.

   Upon receipt of a GetNextRequest-PDU, the receiving SNMP 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



Presuhn, et al.             Standards Track                    [Page 11]

RFC 3416              Protocol Operations for SNMP         December 2002


            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