rfc3413.txt

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

   (6) The Dispatcher is called to generate a response or report
       message.  The abstract service interface is:















Levi, et. al.               Standards Track                    [Page 12]

RFC 3413                   SNMP Applications               December 2002


returnResponsePdu(
  IN   messageProcessingModel   -- typically, SNMP version
  IN   securityModel            -- Security Model in use
  IN   securityName             -- on behalf of this principal
  IN   securityLevel            -- same as on incoming request
  IN   contextEngineID          -- data from/at this SNMP entity
  IN   contextName              -- data from/in this context
  IN   pduVersion               -- the version of the PDU
  IN   PDU                      -- SNMP Protocol Data Unit
  IN   maxSizeResponseScopedPDU -- maximum size of the Response PDU
  IN   stateReference           -- reference to state information
                                -- as presented with the request
  IN   statusInformation        -- success or errorIndication
       )                        -- error counter OID/value if error

   Where:

       - The messageProcessingModel is the value from the processPdu
         call.

       - The securityModel is the value from the processPdu call.

       - The securityName is the value from the processPdu call.

       - The securityLevel is the value from the processPdu call.

       - The contextEngineID is the value from the processPdu call.

       - The contextName is the value from the processPdu call.

       - The pduVersion indicates the version of the PDU to be returned.
         If no result PDU was generated, the pduVersion is an undefined
         value.

       - The PDU is the result generated in step (5) above.  If no
         result PDU was generated, the PDU is an undefined value.

       - The maxSizeResponseScopedPDU is a local value indicating the
         maximum size of a ScopedPDU that the application can accept.

       - The stateReference is the value from the processPdu call.

       - The statusInformation either contains an indication that no
         error occurred and that a response should be generated, or
         contains an indication that an error occurred along with the
         OID and counter value of the appropriate error counter object.





Levi, et. al.               Standards Track                    [Page 13]

RFC 3413                   SNMP Applications               December 2002


   Note that a command responder application should always call the
   returnResponsePdu abstract service interface, even in the event of an
   error such as a resource allocation error.  In the event of such an
   error, the PDU value passed to returnResponsePdu should contain
   appropriate values for errorStatus and errorIndex.

   Note that the text above describes situations where the
   snmpUnknownContexts counter is incremented, and where the
   snmpUnavailableContexts counter is incremented.  The difference
   between these is that the snmpUnknownContexts counter is incremented
   when a request is received for a context which is unknown to the SNMP
   entity.  The snmpUnavailableContexts counter is incremented when a
   request is received for a context which is known to the SNMP entity,
   but is currently unavailable.  Determining when a context is
   unavailable is implementation specific, and some implementations may
   never encounter this situation, and so may never increment the
   snmpUnavailableContexts counter.

3.3. Notification Originator Applications

   A notification originator application generates SNMP messages
   containing Notification-Class PDUs (for example, SNMPv2-Trap PDUs or
   Inform PDUs).  There is no requirement as to what specific types of
   Notification-Class PDUs a particular implementation must be capable
   of generating.

   Notification originator applications require a mechanism for
   identifying the management targets to which notifications should be
   sent.  The particular mechanism used is implementation dependent.
   However, if an implementation makes the configuration of management
   targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module
   described in this document.

   When a notification originator wishes to generate a notification, it
   must first determine in which context the information to be conveyed
   in the notification exists, i.e., it must determine the
   contextEngineID and contextName.  It must then determine the set of
   management targets to which the notification should be sent.  The
   application must also determine, for each management target, what
   specific PDU type the notification message should contain, and if it
   is to contain a Confirmed-Class PDU, the number of retries and
   retransmission algorithm.









Levi, et. al.               Standards Track                    [Page 14]

RFC 3413                   SNMP Applications               December 2002


   The mechanism by which a notification originator determines this
   information is implementation dependent.  Once the application has
   determined this information, the following procedure is performed for
   each management target:

   (1) Any appropriate filtering mechanisms are applied to determine
       whether the notification should be sent to the management target.
       If such filtering mechanisms determine that the notification
       should not be sent, processing continues with the next management
       target.  Otherwise,

   (2) The appropriate set of variable-bindings is retrieved from local
       MIB instrumentation within the relevant MIB view.  The relevant
       MIB view is determined by the securityLevel, securityModel,
       contextName, and securityName of the management target.  To
       determine whether a particular object instance is within the
       relevant MIB view, the isAccessAllowed abstract service interface
       is used, in the same manner as described in the preceding
       section, except that the viewType indicates a Notification-Class
       operation.  If the statusInformation returned by isAccessAllowed
       does not indicate accessAllowed, the notification is not sent to
       the management target.

   (3) The NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
       is the value of the element of the variable bindings whose name
       is snmpTrapOID.0, i.e., the second variable binding) is checked
       using the isAccessAllowed abstract service interface, using the
       same parameters used in the preceding step.  If the
       statusInformation returned by isAccessAllowed does not indicate
       accessAllowed, the notification is not sent to the management
       target.

   (4) A PDU is constructed using a locally unique request-id value, a
       PDU type as determined by the implementation, an error-status and
       error-index value of 0, and the variable-bindings supplied
       previously in step (2).

   (5) If the notification contains an Unconfirmed-Class PDU, the
       Dispatcher is called using the following abstract service
       interface:











Levi, et. al.               Standards Track                    [Page 15]

RFC 3413                   SNMP Applications               December 2002


       statusInformation =              -- sendPduHandle if success
                                        -- errorIndication if failure
         sendPdu(
         IN   transportDomain           -- transport domain to be used
         IN   transportAddress          -- destination network address
         IN   messageProcessingModel    -- typically, SNMP version
         IN   securityModel             -- Security Model to use
         IN   securityName              -- on behalf of this principal
         IN   securityLevel             -- Level of Security requested
         IN   contextEngineID           -- data from/at this entity
         IN   contextName               -- data from/in this context
         IN   pduVersion                -- the version of the PDU
         IN   PDU                       -- SNMP Protocol Data Unit
         IN   expectResponse            -- TRUE or FALSE
              )

       Where:

       - The transportDomain is that of the management target.

       - The transportAddress is that of the management target.

       - The messageProcessingModel is that of the management target.

       - The securityModel is that of the management target.

       - The securityName is that of the management target.

       - The securityLevel is that of the management target.

       - The contextEngineID is the value originally determined for the
         notification.

       - The contextName is the value originally determined for the
         notification.

       - The pduVersion is the version of the PDU to be sent.

       - The PDU is the value constructed in step (4) above.

       - The expectResponse argument indicates that no response is
         expected.

       Otherwise,







Levi, et. al.               Standards Track                    [Page 16]

RFC 3413                   SNMP Applications               December 2002


   (6) If the notification contains a Confirmed-Class PDU, then:

       a) The Dispatcher is called using the sendPdu abstract service
          interface as described in step (5) above, except that the
          expectResponse argument indicates that a response is expected.

       b) The application caches information about the management
          target.

       c) If a response is received within an appropriate time interval
          from the transport endpoint of the management target, the
          notification is considered acknowledged and the cached
          information is deleted.  Otherwise,

       d) If a response is not received within an appropriate time
          period, or if a report indication is received, information
          about the management target is retrieved from the cache, and
          steps a) through d) are repeated.  The number of times these
          steps are repeated is equal to the previously determined retry
          count.  If this retry count is exceeded, the acknowledgement
          of the notification is considered to have failed, and
          processing of the notification for this management target is
          halted.  Note that some report indications might be considered
          a failure.  Such report indications should be interpreted to
          mean that the acknowledgement of the notification has failed,
          and that steps a) through d) need not be repeated.

   Responses to Confirmed-Class PDU notifications will be received via
   the processResponsePdu abstract service interface.

   To summarize, the steps that a notification originator follows when
   determining where to send a notification are:

   - Determine the targets to which the notification should be sent.

   - Apply any required filtering to the list of targets.

   - Determine which targets are authorized to receive the notification.

3.4. Notification Receiver Applications

   Notification receiver applications receive SNMP Notification messages
   from the Dispatcher.  Before any messages can be received, the
   notification receiver must register with the Dispatcher using the
   registerContextEngineID abstract service interface.  The parameters
   used are:





Levi, et. al.               Standards Track                    [Page 17]

RFC 3413                   SNMP Applications               December 2002


   - The contextEngineID is an undefined 'wildcard' value.
     Notifications are delivered to a registered notification receiver
     regardless of the contextEngineID contained in the notification
     message.

   - The pduType indicates the type of notifications that the
     application wishes to receive (for example, SNMPv2-Trap PDUs or
     Inform PDUs).

   Once the notification receiver has registered with the Dispatcher,
   messages are received using the processPdu abstract service
   interface.  Parameters are:

   - The messageProcessingModel indicates which Message Processing Model
     received and processed the message.

   - The securityModel is the value from the received message.

   - The securityName is the value from the received message.

   - The securityLevel is the value from the received message.

   - The contextEngineID is the value from the received message.

   - The contextName is the value from the received message.