rfc3411.txt

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

3.2.  The Naming of Identities

                            principal
                                ^
                                |
                                |
   +----------------------------|-------------+
   | SNMP engine                v             |
   |                    +--------------+      |
   |                    |              |      |
   |  +-----------------| securityName |---+  |
   |  | Security Model  |              |   |  |
   |  |                 +--------------+   |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  |                         v          |  |
   |  |  +------------------------------+  |  |
   |  |  |                              |  |  |
   |  |  | Model                        |  |  |
   |  |  | Dependent                    |  |  |
   |  |  | Security ID                  |  |  |
   |  |  |                              |  |  |
   |  |  +------------------------------+  |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  +-------------------------|----------+  |
   |                            |             |
   |                            |             |
   +----------------------------|-------------+
                                |
                                v
                             network

3.2.1.  Principal

   A principal is the "who" on whose behalf services are provided or
   processing takes place.

   A principal can be, among other things, an individual acting in a
   particular role; a set of individuals, with each acting in a
   particular role; an application or a set of applications; and
   combinations thereof.

3.2.2.  securityName

   A securityName is a human readable string representing a principal.
   It has a model-independent format, and can be used outside a
   particular Security Model.



Harrington, et al.          Standards Track                    [Page 25]

RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.2.3.  Model-dependent security ID

   A model-dependent security ID is the model-specific representation of
   a securityName within a particular Security Model.

   Model-dependent security IDs may or may not be human readable, and
   have a model-dependent syntax.  Examples include community names, and
   user names.

   The transformation of model-dependent security IDs into securityNames
   and vice versa is the responsibility of the relevant Security Model.

3.3.  The Naming of Management Information

   Management information resides at an SNMP entity where a Command
   Responder Application has local access to potentially multiple
   contexts.  This application uses a contextEngineID equal to the
   snmpEngineID of its associated SNMP engine.

































Harrington, et al.          Standards Track                    [Page 26]

RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   +-----------------------------------------------------------------+
   |  SNMP entity (identified by snmpEngineID, for example:          |
   |  '800002b804616263'H (enterpise 696, string "abc")              |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  | SNMP engine (identified by snmpEngineID)                   | |
   |  |                                                            | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  | |             | |            | |           | |           | | |
   |  | | Dispatcher  | | Message    | | Security  | | Access    | | |
   |  | |             | | Processing | | Subsystem | | Control   | | |
   |  | |             | | Subsystem  | |           | | Subsystem | | |
   |  | |             | |            | |           | |           | | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  |                                                            | |
   |  +------------------------------------------------------------+ |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  |  Command Responder Application                             | |
   |  |  (contextEngineID, example: '800002b804616263'H)           | |
   |  |                                                            | |
   |  |  example contextNames:                                     | |
   |  |                                                            | |
   |  |  "bridge1"          "bridge2"            "" (default)      | |
   |  |  ---------          ---------            ------------      | |
   |  |      |                  |                   |              | |
   |  +------|------------------|-------------------|--------------+ |
   |         |                  |                   |                |
   |  +------|------------------|-------------------|--------------+ |
   |  |  MIB | instrumentation  |                   |              | |
   |  |  +---v------------+ +---v------------+ +----v-----------+  | |
   |  |  | context        | | context        | | context        |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | | bridge MIB | | | | bridge MIB | | | | some  MIB  | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | | | other MIB  | |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   +-----------------------------------------------------------------+









Harrington, et al.          Standards Track                    [Page 27]

RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.3.1.  An SNMP Context

   An SNMP context, or just "context" for short, is a collection of
   management information accessible by an SNMP entity.  An item of
   management information may exist in more than one context.  An SNMP
   entity potentially has access to many contexts.

   Typically, there are many instances of each managed object type
   within a management domain.  For simplicity, the method for
   identifying instances specified by the MIB module does not allow each
   instance to be distinguished amongst the set of all instances within
   a management domain; rather, it allows each instance to be identified
   only within some scope or "context", where there are multiple such
   contexts within the management domain.  Often, a context is a
   physical device, or perhaps, a logical device, although a context can
   also encompass multiple devices, or a subset of a single device, or
   even a subset of multiple devices, but a context is always defined as
   a subset of a single SNMP entity.  Thus, in order to identify an
   individual item of management information within the management
   domain, its contextName and contextEngineID must be identified in
   addition to its object type and its instance.

   For example, the managed object type ifDescr [RFC2863], is defined as
   the description of a network interface.  To identify the description
   of device-X's first network interface, four pieces of information are
   needed: the snmpEngineID of the SNMP entity which provides access to
   the management information at device-X, the contextName (device-X),
   the managed object type (ifDescr), and the instance ("1").

   Each context has (at least) one unique identification within the
   management domain.  The same item of management information can exist
   in multiple contexts.  An item of management information may have
   multiple unique identifications.  This occurs when an item of
   management information exists in multiple contexts, and this also
   occurs when a context has multiple unique identifications.

   The combination of a contextEngineID and a contextName unambiguously
   identifies a context within an administrative domain; note that there
   may be multiple unique combinations of contextEngineID and
   contextName that unambiguously identify the same context.

3.3.2.  contextEngineID

   Within an administrative domain, a contextEngineID uniquely
   identifies an SNMP entity that may realize an instance of a context
   with a particular contextName.





Harrington, et al.          Standards Track                    [Page 28]

RFC 3411      Architecture for SNMP Management Frameworks  December 2002


3.3.3.  contextName

   A contextName is used to name a context.  Each contextName MUST be
   unique within an SNMP entity.

3.3.4.  scopedPDU

   A scopedPDU is a block of data containing a contextEngineID, a
   contextName, and a PDU.

   The PDU is an SNMP Protocol Data Unit containing information named in
   the context which is unambiguously identified within an
   administrative domain by the combination of the contextEngineID and
   the contextName.  See, for example, RFC 3416 for more information
   about SNMP PDUs.

3.4.  Other Constructs

3.4.1.  maxSizeResponseScopedPDU

   The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that
   a PDU's sender would be willing to accept.  Note that the size of a
   scopedPDU does not include the size of the SNMP message header.

3.4.2.  Local Configuration Datastore

   The subsystems, models, and applications within an SNMP entity may
   need to retain their own sets of configuration information.

   Portions of the configuration information may be accessible as
   managed objects.

   The collection of these sets of information is referred to as an
   entity's Local Configuration Datastore (LCD).

3.4.3.  securityLevel

   This architecture recognizes three levels of security:

      -  without authentication and without privacy (noAuthNoPriv)

      -  with authentication but without privacy (authNoPriv)

      -  with authentication and with privacy (authPriv)







Harrington, et al.          Standards Track                    [Page 29]

RFC 3411      Architecture for SNMP Management Frameworks  December 2002


   These three values are ordered such that noAuthNoPriv is less than
   authNoPriv and authNoPriv is less than authPriv.

   Every message has an associated securityLevel.  All Subsystems
   (Message Processing, Security, Access Control) and applications are
   REQUIRED to either supply a value of securityLevel or to abide by the
   supplied value of securityLevel while processing the message and its
   contents.

4.  Abstract Service Interfaces

   Abstract service interfaces have been defined to describe the
   conceptual interfaces between the various subsystems within an SNMP
   entity.  The abstract service interfaces are intended to help clarify
   the externally observable behavior of SNMP entities, and are not
   intended to constrain the structure or organization of
   implementations in any way.  Most specifically, they should not be
   interpreted as APIs or as requirements statements for APIs.

   These abstract service interfaces are defined by a set of primitives
   that define the services provided and the abstract data elements that
   are to be passed when the services are invoked.  This section lists
   the primitives that have been defined for the various subsystems.

4.1.  Dispatcher Primitives

   The Dispatcher typically provides services to the SNMP applications
   via its PDU Dispatcher.  This section describes the primitives
   provided by the PDU Dispatcher.






















Harrington, et al.          Standards Track