rfc2571.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

   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).  SNMP
   PDUs define the operations performed by the receiving SNMP engine.
   It is the purpose of a Protocol Operations document to define the
   operations of the protocol with respect to the processing of the
   PDUs.  Every PDU belongs to one or more of the PDU classes defined
   below:

      1) Read Class:

         The Read Class contains protocol operations that retrieve
         management information.  For example, RFC 1905 defines the
         following protocol operations for the Read Class:  GetRequest-
         PDU, GetNextRequest-PDU, and GetBulkRequest-PDU.

      2) Write Class:

         The Write Class contains protocol operations which attempt to
         modify management information.  For example, RFC 1905 defines
         the following protocol operation for the Write Class:
         SetRequest-PDU.

      3) Response Class:

         The Response Class contains protocol operations which are sent
         in response to a previous request.  For example, RFC 1905
         defines the following for the Response Class: Response-PDU,
         Report-PDU.

      4) Notification Class:

         The Notification Class contains protocol operations which send
         a notification to a notification receiver application.  For
         example, RFC 1905 defines the following operations for the
         Notification Class:  Trapv2-PDU, InformRequest-PDU.





SNMPv3 Working Group        Standards Track                    [Page 12]

RFC 2571           Architecture for SNMP Frameworks             April 1999


      5) Internal Class:

         The Internal Class contains protocol operations which are
         exchanged internally between SNMP engines.  For example, RFC
         1905 defines the following operations for the Internal Class:
         Report-PDU.

   The preceding five classifications are based on the functional
   properties of a PDU. It is also useful to classify PDUs based on
   whether a response is expected:

      6) Confirmed Class:

         The Confirmed Class contains all protocol operations which
         cause the receiving SNMP engine to send back a response.  For
         example, RFC 1905 defines the following operations for the
         Confirmed Class:  GetRequest-PDU, GetNextRequest-PDU,
         GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU.

      7) Unconfirmed Class:

         The Unconfirmed Class contains all protocol operations which
         are not acknowledged. For example, RFC 1905 defines the
         following operations for the Unconfirmed Class:  Report-PDU,
         Trapv2-PDU, and GetResponse-PDU.

   An application document defines which Protocol Operations 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.





SNMPv3 Working Group        Standards Track                    [Page 13]

RFC 2571           Architecture for SNMP Frameworks             April 1999


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 notation for defining objects, modules, and other
   elements of managed information.

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 be 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 the Conformance Statements document 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.



SNMPv3 Working Group        Standards Track                    [Page 14]

RFC 2571           Architecture for SNMP Frameworks             April 1999


   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.

   SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the
   SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580,
   and RFCs 1905-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 RFC
   1901. 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,

      -  Access Control, and

      -  Remote configuration of SNMP parameters.

   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.






SNMPv3 Working Group        Standards Track                    [Page 15]

RFC 2571           Architecture for SNMP Frameworks             April 1999


   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.

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







SNMPv3 Working Group        Standards Track                    [Page 16]

RFC 2571           Architecture for SNMP Frameworks             April 1999


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,

      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 within that
   administrative domain.  Note that it is possible for SNMP entities in
   different administrative domains to have the same value for
   snmpEngineID.  Federation of administrative domains may necessitate
   assignment of new values.

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: