rfc2273.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                            D. Levi
Request for Comments: 2273                           SNMP Research, Inc.
Obsoletes: 2263                                                 P. Meyer
Category: Standards Track                   Secure Computing Corporation
                                                              B. Stewart
                                                           Cisco Systems
                                                            January 1998

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

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

IANA Note

   Due to a clerical error in the assignment of the snmpModules in this
   memo, this RFC provides the corrected number assignments for this
   protocol.  This memo obsoletes RFC 2263.

Abstract

   This memo describes five types of SNMP applications which make use of
   an SNMP engine as described in [RFC2271].  The types of application
   described are Command Generators, Command Responders, Notification
   Originators, Notification Receivers, and Proxy Forwarders.

   This memo also defines MIB modules for specifying targets of
   management operations, for notification filtering, and for proxy
   forwarding.

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 ...............................    3
   2 Management Targets ...........................................    5



Levi, et. al.               Standards Track                     [Page 1]

RFC 2273                  SNMPv3 Applications               January 1998


   3 Elements Of Procedure ........................................    6
   3.1 Command Generator Applications .............................    6
   3.2 Command Responder Applications .............................    8
   3.3 Notification Originator Applications .......................   13
   3.4 Notification Receiver Applications .........................   16
   3.5 Proxy Forwarder Applications ...............................   18
   3.5.1 Request Forwarding .......................................   19
   3.5.1.1 Processing an Incoming Request .........................   19
   3.5.1.2 Processing an Incoming Response ........................   22
   3.5.1.3 Processing an Incoming Report Indication ...............   23
   3.5.2 Notification Forwarding ..................................   24
   4 The Structure of the MIB Modules .............................   27
   4.1 The Management Target MIB Module ...........................   27
   4.1.1 Tag Lists ................................................   28
   4.1.2 Definitions ..............................................   28
   4.2 The Notification MIB Module ................................   41
   4.2.1 Definitions ..............................................   42
   4.3 The Proxy MIB Module .......................................   53
   4.3.1 Definitions ..............................................   53
   5 Identification of Management Targets in Notification
        Originators ...............................................   59
   6 Notification Filtering .......................................   60
   7 Management Target Translation in Proxy  Forwarder
        Applications ..............................................   61
   7.1 Management Target Translation for Request Forwarding .......   61
   7.2 Management Target Translation for Notification Forwarding
        ...........................................................   62
   8 Intellectual Property ........................................   63
   9 Acknowledgments ..............................................   64
   10 Security Considerations .....................................   65
   11 References ..................................................   65
   12 Editors' Address ............................................   67
   A. Trap Configuration Example ..................................   68
   B. Full Copyright Statement ....................................   70

1.  Overview

   This document describes five types of SNMP applications:

       -  Applications which initiate SNMP Get, GetNext, GetBulk, and/or
          Set requests, called 'command generators.'

       -  Applications which respond to SNMP Get, GetNext, GetBulk,
          and/or Set requests, called 'command responders.'

       -  Applications which generate notifications, called
          'notification originators.'




Levi, et. al.               Standards Track                     [Page 2]

RFC 2273                  SNMPv3 Applications               January 1998


       -  Applications which receive notifications, called 'notification
          receivers.'

       -  Applications which forward SNMP Get, GetNext, GetBulk, and/or
          Set requests or notifications, called 'proxy forwarder.'

   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.

1.1.  Command Generator Applications

   A command generator application initiates SNMP Get, GetNext, GetBulk,
   and/or Set requests, as well as processing the response to a request
   which it generated.

1.2.  Command Responder Applications

   A command responder application receives SNMP Get, GetNext, GetBulk,
   and/or Set 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 Trap and/or Inform
   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.

1.4.  Notification Receiver Applications

   A notification receiver application listens for notification
   messages, and generates response messages when a message containing
   an Inform PDU is received.

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 (4.5, 5.3, and 8) may be skipped for



Levi, et. al.               Standards Track                     [Page 3]

RFC 2273                  SNMPv3 Applications               January 1998


   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 requests, notifications, and responses without regard for
   what managed objects are contained within requests or notifications.
   This definition is most closely related to the first definition
   above.  Note, however, that in the SNMP architecture [RFC2271], 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:

       -  a proxy forwarder application forwards requests and/or
          notifications 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)



Levi, et. al.               Standards Track                     [Page 4]

RFC 2273                  SNMPv3 Applications               January 1998


          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 Inform requests, the associated response
   is forwarded when it is received from the target to which the Inform
   request was forwarded, rather than generating a response immediately
   when an Inform request 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.

   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.



Levi, et. al.               Standards Track                     [Page 5]

RFC 2273                  SNMPv3 Applications               January 1998


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 [RFC2271].

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.

       -  The messageProcessingModel indicates which Message Processing
          Model the application wishes to use.

       -  The securityModel is the security model that the application
          wishes to use.

       -  The securityName is the security model independent name for
          the principal on whose behalf the application wishes the
          message is to be generated.