rfc2271.txt

RFC 的详细文档！

   A security document describes a Security Model, the threats against
   which the model protects, the goals of the Security Model, the
   protocols which it uses to meet those goals, and it may define a MIB
   module to describe the data used during processing, and to allow the
   remote configuration of message-level security parameters, such as
   passwords.

   An SNMP engine may support multiple Security Models concurrently.

2.7.  Access Control

   During processing, it may be required to control access to managed
   objects for operations.





Harrington, et. al.         Standards Track                    [Page 11]

RFC 2271                  SNMPv3 Architecture               January 1998


   An Access Control Model defines mechanisms to determine whether
   access to a managed object should be allowed.  An Access Control
   Model may define a MIB module used during processing and to allow the
   remote configuration of access control policies.

2.8.  Protocol Operations

   SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). It is the
   purpose of a Protocol Operations document to define the operations of
   the protocol with respect to the processing of the PDUs.

   An application document defines which Protocol Operations documents
   are supported by the application.

2.9.  Applications

   An SNMP entity normally includes a number of applications.
   Applications use the services of an SNMP engine to accomplish
   specific tasks. They coordinate the processing of management
   information operations, and may use SNMP messages to communicate with
   other SNMP entities.

   Applications documents describe the purpose of an application, the
   services required of the associated SNMP engine, and the protocol
   operations and informational model that the application uses to
   perform management operations.

   An application document defines which set of documents are used to
   specifically define the structure of management information, textual
   conventions, conformance requirements, and operations supported by
   the application.

2.10.  Structure of Management Information

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB). Collections of related objects are defined in
   MIB modules.

   It is the purpose of a Structure of Management Information document
   to establish the syntax for defining objects, modules, and other
   elements of managed information.









Harrington, et. al.         Standards Track                    [Page 12]

RFC 2271                  SNMPv3 Architecture               January 1998


2.11.  Textual Conventions

   When designing a MIB module, it is often useful to define new types
   similar to those defined in the SMI, but with more precise semantics,
   or which have special semantics associated with them. These newly
   defined types are termed textual conventions, and may defined in
   separate documents, or within a MIB module.

2.12.  Conformance Statements

   It may be useful to define the acceptable lower-bounds of
   implementation, along with the actual level of implementation
   achieved. It is the purpose of Conformance Statements to define the
   notation used for these purposes.

2.13.  Management Information Base Modules

   MIB documents describe collections of managed objects which
   instrument some aspect of a managed node.

2.13.1.  SNMP Instrumentation MIBs

   An SNMP MIB document may define a collection of managed objects which
   instrument the SNMP protocol itself. In addition, MIB modules may be
   defined within the documents which describe portions of the SNMP
   architecture, such as the documents for Message processing Models,
   Security Models, etc. for the purpose of instrumenting those Models,
   and for the purpose of allowing remote configuration of the Model.

2.14.  SNMP Framework Documents

   This architecture is designed to allow an orderly evolution of
   portions of SNMP Frameworks.

   Throughout the rest of this document, the term "subsystem" refers to
   an abstract and incomplete specification of a portion of a Framework,
   that is further refined by a model specification.

   A "model" describes a specific design of a subsystem, defining
   additional constraints and rules for conformance to the model.  A
   model is sufficiently detailed to make it possible to implement the
   specification.

   An "implementation" is an instantiation of a subsystem, conforming to
   one or more specific models.

   SNMP version 1 (SNMPv1), is the original Internet-standard Network
   Management Framework, as described in RFCs 1155, 1157, and 1212.



Harrington, et. al.         Standards Track                    [Page 13]

RFC 2271                  SNMPv3 Architecture               January 1998


   SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the
   SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no
   message definition.

   The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP
   Framework which supplements the SNMPv2 Framework, as described in
   RFC1901. It adds the SNMPv2c message format, which is similar to the

   SNMPv1 message format.

   SNMP version 3 (SNMPv3), is an extensible SNMP Framework which
   supplements the SNMPv2 Framework, by supporting the following:

      -  a new SNMP message format,

      -  Security for Messages, and

      -  Access Control.

   Other SNMP Frameworks, i.e., other configurations of implemented
   subsystems, are expected to also be consistent with this
   architecture.

3.  Elements of the Architecture

   This section describes the various elements of the architecture and
   how they are named. There are three kinds of naming:

      1) the naming of entities,

      2) the naming of identities, and

      3) the naming of management information.

   This architecture also defines some names for other constructs that
   are used in the documentation.

3.1.  The Naming of Entities

   An SNMP entity is an implementation of this architecture. Each such
   SNMP entity consists of an SNMP engine and one or more associated
   applications.

   The following figure shows details about an SNMP entity and the
   components within it.






Harrington, et. al.         Standards Track                    [Page 14]

RFC 2271                  SNMPv3 Architecture               January 1998


   +-------------------------------------------------------------------+
   |  SNMP entity                                                      |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  SNMP engine (identified by snmpEngineID)                   |  |
   |  |                                                             |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  | Dispatcher | | Message    | | Security  | | Access    |  |  |
   |  |  |            | | Processing | | Subsystem | | Control   |  |  |
   |  |  |            | | Subsystem  | |           | | Subsystem |  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  Application(s)                                             |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Command     |  | Notification |  | Proxy        |        |  |
   |  |  | Generator   |  | Receiver     |  | Forwarder    |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Command     |  | Notification |  | Other        |        |  |
   |  |  | Responder   |  | Originator   |  |              |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

3.1.1.  SNMP engine

   An SNMP engine provides services for sending and receiving messages,
   authenticating and encrypting messages, and controlling access to
   managed objects. There is a one-to-one association between an SNMP
   engine and the SNMP entity which contains it.

   The engine contains:

      1) a Dispatcher,

      2) a Message Processing Subsystem,






Harrington, et. al.         Standards Track                    [Page 15]

RFC 2271                  SNMPv3 Architecture               January 1998


      3) a Security Subsystem, and

      4) an Access Control Subsystem.

3.1.1.1.  snmpEngineID

   Within an administrative domain, an snmpEngineID is the unique and
   unambiguous identifier of an SNMP engine. Since there is a one-to-one
   association between SNMP engines and SNMP entities, it also uniquely
   and unambiguously identifies the SNMP entity.

3.1.1.2.  Dispatcher

   There is only one Dispatcher in an SNMP engine. It allows for
   concurrent support of multiple versions of SNMP messages in the SNMP
   engine. It does so by:

      -  sending and receiving SNMP messages to/from the network,

      -  determining the version of an SNMP message and interacting with
         the corresponding Message Processing Model,

      -  providing an abstract interface to SNMP applications for
         delivery of a PDU to an application.

      -  providing an abstract interface for SNMP applications that
         allows them to send a PDU to a remote SNMP entity.

3.1.1.3.  Message Processing Subsystem

   The Message Processing Subsystem is responsible for preparing
   messages for sending, and extracting data from received messages.

   The Message Processing Subsystem potentially contains multiple
   Message Processing Models as shown in the next figure.

   * One or more Message Processing Models may be present.