rfc3413.txt

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

Network Working Group                                            D. Levi
Request for Comments: 3413                               Nortel Networks
STD: 62                                                         P. Meyer
Obsoletes: 2573                             Secure Computing Corporation
Category: Standards Track                                     B. Stewart
                                                                 Retired
                                                           December 2002


         Simple Network Management Protocol (SNMP) Applications

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes five types of Simple Network Management
   Protocol (SNMP) applications which make use of an SNMP engine as
   described in STD 62, RFC 3411.  The types of application described
   are Command Generators, Command Responders, Notification Originators,
   Notification Receivers, and Proxy Forwarders.

   This document also defines Management Information Base (MIB) modules
   for specifying targets of management operations, for notification
   filtering, and for proxy forwarding.  This document obsoletes RFC
   2573.

Table of Contents

   1       Overview ...............................................    2
   1.1     Command Generator Applications .........................    3
   1.2     Command Responder Applications .........................    3
   1.3     Notification Originator Applications ...................    3
   1.4     Notification Receiver Applications .....................    3
   1.5     Proxy Forwarder Applications ...........................    4
   2       Management Targets .....................................    5
   3       Elements Of Procedure ..................................    6
   3.1     Command Generator Applications .........................    6
   3.2     Command Responder Applications .........................    9
   3.3     Notification Originator Applications ...................   14
   3.4     Notification Receiver Applications .....................   17
   3.5     Proxy Forwarder Applications ...........................   19
   3.5.1   Request Forwarding .....................................   21



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


   3.5.1.1 Processing an Incoming Request .........................   21
   3.5.1.2 Processing an Incoming Response ........................   24
   3.5.1.3 Processing an Incoming Internal-Class PDU ..............   25
   3.5.2   Notification Forwarding ................................   26
   4       The Structure of the MIB Modules .......................   29
   4.1     The Management Target MIB Module .......................   29
   4.1.1   Tag Lists .....................,........................   29
   4.1.2   Definitions ..................,.........................   30
   4.2     The Notification MIB Module ............................   44
   4.2.1   Definitions ............................................   44
   4.3     The Proxy MIB Module ...................................   56
   4.3.1   Definitions ............................................   57
   5       Identification of Management Targets in
           Notification Originators ...............................   63
   6       Notification Filtering .................................   64
   7       Management Target Translation in
           Proxy Forwarder Applications ...........................   65
   7.1     Management Target Translation for
           Request Forwarding .....................................   65
   7.2     Management Target Translation for
           Notification Forwarding ................................   66
   8       Intellectual Property ..................................   67
   9       Acknowledgments ........................................   67
   10      Security Considerations ................................   69
   11      References .............................................   69
   A.      Trap Configuration Example .............................   71
           Editors' Addresses .....................................   73
           Full Copyright Statement ...............................   74

1. Overview

   This document describes five types of SNMP applications:

   - Applications which initiate SNMP Read-Class, and/or Write-Class
     requests, called 'command generators.'

   - Applications which respond to SNMP Read-Class, and/or Write-Class
     requests, called 'command responders.'

   - Applications which generate SNMP Notification-Class PDUs, called
     'notification originators.'

   - Applications which receive SNMP Notification-Class PDUs, called
     'notification receivers.'

   - Applications which forward SNMP messages, called 'proxy
     forwarders.'




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


   Note that there are no restrictions on which types of applications
   may be associated with a particular SNMP engine.  For example, a
   single SNMP engine may, in fact, be associated with both command
   generator and command responder applications.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.1. Command Generator Applications

   A command generator application initiates SNMP Read-Class and/or
   Write-Class requests, and processes responses to requests which it
   generated.

1.2. Command Responder Applications

   A command responder application receives SNMP Read-Class and/or
   Write-Class requests destined for the local system as indicated by
   the fact that the contextEngineID in the received request is equal to
   that of the local engine through which the request was received.  The
   command responder application will perform the appropriate protocol
   operation, using access control, and will generate a response message
   to be sent to the request's originator.

1.3. Notification Originator Applications

   A notification originator application conceptually monitors a system
   for particular events or conditions, and generates Notification-Class
   messages based on these events or conditions.  A notification
   originator must have a mechanism for determining where to send
   messages, and what SNMP version and security parameters to use when
   sending messages.  A mechanism and MIB module for this purpose is
   provided in this document.  Note that Notification-Class PDUs
   generated by a notification originator may be either Confirmed-Class
   or Unconfirmed-Class PDU types.

1.4. Notification Receiver Applications

   A notification receiver application listens for notification
   messages, and generates response messages when a message containing a
   Confirmed-Class PDU is received.









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


1.5. Proxy Forwarder Applications

   A proxy forwarder application forwards SNMP messages.  Note that
   implementation of a proxy forwarder application is optional.  The
   sections describing proxy (3.5, 4.3, and 7) may be skipped for
   implementations that do not include a proxy forwarder application.

   The term "proxy" has historically been used very loosely, with
   multiple different meanings.  These different meanings include (among
   others):

   (1) the forwarding of SNMP requests to other SNMP entities without
       regard for what managed object types are being accessed; for
       example, in order to forward an SNMP request from one transport
       domain to another, or to translate SNMP requests of one version
       into SNMP requests of another version;

   (2) the translation of SNMP requests into operations of some non-SNMP
       management protocol; and

   (3) support for aggregated managed objects where the value of one
       managed object instance depends upon the values of multiple other
       (remote) items of management information.

   Each of these scenarios can be advantageous; for example, support for
   aggregation of management information can significantly reduce the
   bandwidth requirements of large-scale management activities.

   However, using a single term to cover multiple different scenarios
   causes confusion.

   To avoid such confusion, this document uses the term "proxy" with a
   much more tightly defined meaning.  The term "proxy" is used in this
   document to refer to a proxy forwarder application which forwards
   either SNMP messages without regard for what managed objects are
   contained within those messages.  This definition is most closely
   related to the first definition above.  Note, however, that in the
   SNMP architecture [RFC3411], a proxy forwarder is actually an
   application, and need not be associated with what is traditionally
   thought of as an SNMP agent.

   Specifically, the distinction between a traditional SNMP agent and a
   proxy forwarder application is simple:








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


   - a proxy forwarder application forwards SNMP messages to other SNMP
     engines according to the context, and irrespective of the specific
     managed object types being accessed, and forwards the response to
     such previously forwarded messages back to the SNMP engine from
     which the original message was received;

   - in contrast, the command responder application that is part of what
     is traditionally thought of as an SNMP agent, and which processes
     SNMP requests according to the (names of the) individual managed
     object types and instances being accessed, is NOT a proxy forwarder
     application from the perspective of this document.

   Thus, when a proxy forwarder application forwards a request or
   notification for a particular contextEngineID / contextName pair, not
   only is the information on how to forward the request specifically
   associated with that context, but the proxy forwarder application has
   no need of a detailed definition of a MIB view (since the proxy
   forwarder application forwards the request irrespective of the
   managed object types).

   In contrast, a command responder application must have the detailed
   definition of the MIB view, and even if it needs to issue requests to
   other entities, via SNMP or otherwise, that need is dependent on the
   individual managed object instances being accessed (i.e., not only on
   the context).

   Note that it is a design goal of a proxy forwarder application to act
   as an intermediary between the endpoints of a transaction.  In
   particular, when forwarding Confirmed Notification-Class messages,
   the associated response is forwarded when it is received from the
   target to which the Notification-Class message was forwarded, rather
   than generating a response immediately when the Notification-Class
   message is received.

2. Management Targets

   Some types of applications (notification generators and proxy
   forwarders in particular) require a mechanism for determining where
   and how to send generated messages.  This document provides a
   mechanism and MIB module for this purpose.  The set of information
   that describes where and how to send a message is called a
   'Management Target', and consists of two kinds of information:

   - Destination information, consisting of a transport domain and a
     transport address.  This is also termed a transport endpoint.

   - SNMP parameters, consisting of message processing model, security
     model, security level, and security name information.



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


   The SNMP-TARGET-MIB module described later in this document contains
   one table for each of these types of information.  There can be a
   many-to-many relationship in the MIB between these two types of
   information.  That is, there may be multiple transport endpoints
   associated with a particular set of SNMP parameters, or a particular
   transport endpoint may be associated with several sets of SNMP
   parameters.

3. Elements Of Procedure

   The following sections describe the procedures followed by each type
   of application when generating messages for transmission or when
   processing received messages.  Applications communicate with the
   Dispatcher using the abstract service interfaces defined in
   [RFC3411].

3.1. Command Generator Applications

   A command generator initiates an SNMP request by calling the
   Dispatcher using the following abstract service interface:

      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 destination of the message.

   - The transportAddress is that of the destination of the message.