rfc1909.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/4 页

   It is an SNMPv2 agent which responds to requests for access to
   management information.  Each such request is contained within an
   SNMPv2 message which provides the capability to perform a single
   operation on a list of items of management information.  Rather than
   having to identify the context as well as the managed object type and
   instance for each item of management information, each SNMPv2 message
   is concerned with only a single context.  Thus, an SNMPv2 agent must
   be able to process requests for all items of management information
   within the one or more contexts it supports.





McCloghrie                    Experimental                      [Page 5]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   In responding to a request, an SNMPv2 agent might be acting as a
   proxy for some other agent.  The term "proxy" has historically been
   used very loosely, with multiple different meanings.  These different
   meanings include (among others):

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

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

(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 for 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 SNMPv2 administrative framework uses
   the term "proxy" with a much more tightly defined meaning, which
   covers only the first of those listed above.  Specifically, the
   distinction between a "regular SNMPv2 agent" and a "proxy SNMPv2
   agent" is simple:

  -  a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on
     to other agents according to the context, and irrespective of the
     specific managed object types being accessed;

  -  in contrast, an SNMPv2 agent which processes SNMPv2 requests
     according to the (names of the) individual managed object types and
     instances being accessed, is NOT a proxy SNMPv2 agent from the
     perspective of this administrative model.

   Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for a
   particular context, although information on how to forward the
   request is specifically associated with that context, the proxy
   SNMPv2 agent has no need of a detailed definition of the MIB view
   (since the proxy SNMPv2 agent forwards the request irrespective of
   the managed object types).

   In contrast, a SNMPv2 agent operating without proxy must have the
   detailed definition of the MIB view, and even if it needs to issue



McCloghrie                    Experimental                      [Page 6]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   requests to other agents, that need is dependent on the individual
   managed object instances being accessed (i.e., not only on the
   context).

3.  Elements of the Model

   This section provides a more formal description of the model.

3.1.  SNMPv2 Entity

   An SNMPv2 entity is an actual process which performs management
   operations by generating and/or responding to SNMPv2 protocol
   messages in the manner specified in [4].  An SNMPv2 entity assumes
   the identity of a particular administrative entity when processing an
   SNMPv2 message.

   An SNMPv2 entity is not required to process multiple protocol
   messages concurrently, regardless of whether such messages require it
   to assume the identity of the same or different administrative
   entity.  Thus, an implementation of an SNMPv2 entity which supports
   more than one administrative entity need not be multi-threaded.
   However, there may be situations where implementors may choose to use
   multi-threading.

   An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on
   each transport service address for which it is configured to do so.
   It is a local matter whether an SNMPv2 entity also listens for SNMPv2
   messages on any other transport service addresses.  In the absence of
   any other information on where to listen, an SNMPv2 entity must
   listen on the transport service addresses corresponding to the
   standard transport-layer "ports" [5] on its local network-layer
   addresses.

3.2.  SNMPv2 Agent

   An SNMPv2 agent is the operational role assumed by an SNMPv2 entity
   when it acts in an agent role.  Specifically, an SNMPv2 agent
   performs SNMPv2 management operations in response to received SNMPv2
   protocol messages (except for inform notifications).

   In order to be manageable, all network components need to be
   instrumented.  SNMPv2 access to the instrumented information is via
   the managed objects supported by an SNMPv2 agent in one or more
   contexts.







McCloghrie                    Experimental                      [Page 7]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


3.3.  SNMPv2 Manager

   An SNMPv2 manager is the operational role assumed by an SNMPv2 entity
   when it acts in a manager role on behalf of management applications.
   Specifically, an SNMPv2 manager initiates SNMPv2 management
   operations by the generation of appropriate SNMPv2 protocol messages,
   or when it receives and processes trap and inform notifications.

   It is interesting to consider the case of managing an SNMPv2 manager.
   It is highly desirable that an SNMPv2 manager, just like any other
   networking application, be instrumented for the purposes of being
   managed.  Such instrumentation of an SNMPv2 manager (just like for
   any other networking application) is accessible via the managed
   objects supported by an SNMPv2 agent.  As such, an SNMPv2 manager is
   no different from any other network application in that it has
   instrumentation, but does not itself have managed objects.

   That is, an SNMPv2 manager does not itself have managed objects.
   Rather, it is an associated SNMPv2 agent supporting managed objects
   which provides access to the SNMPv2 manager's instrumentation.

3.4.  SNMPv2 Dual-Role Entity

   An SNMPv2 entity which sometimes acts in an agent role and sometimes
   acts in a manager role, is termed an SNMPv2 dual-role entity.  An
   SNMPv2 dual-role entity initiates requests by acting in a manager
   role, and processes requests regarding management information
   accessible to it (locally or via proxy) through acting in an agent
   role.  In the case of sending inform notifications, an SNMPv2 dual-
   role entity acts in a manager role in initiating an inform
   notification containing management information which is accessible to
   it when acting in an agent role.

   An SNMPv2 entity which can act only in an SNMPv2 manager role is not
   SNMP-manageable, since there is no way to access its management
   instrumentation.  In order to be SNMP-manageable, an SNMPv2 entity
   must be able to act in an SNMPv2 agent role in order to allow its
   instrumentation to be accessed.  Thus, it is highly desirable that
   all SNMPv2 entities be either SNMPv2 agents or SNMPv2 dual-role
   entities.

   There are two categories of SNMPv2 dual-role entities:  proxy SNMPv2
   agents and (so-called) mid-level managers.  Proxy SNMPv2 agents only
   forward requests/responses; they do not originate requests.  In
   contrast, mid-level managers often originate requests.  (Note that
   the term proxy SNMPv2 agent does not include an SNMPv2 agent which
   translates SNMPv2 requests into the requests of some other management
   protocol; see section 2.6.)



McCloghrie                    Experimental                      [Page 8]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


3.5.  View Subtree and Families

   A view subtree is the set of all MIB object instances which have a
   common ASN.1 OBJECT IDENTIFIER prefix to their names.  A view subtree
   is identified by the OBJECT IDENTIFIER value which is the longest
   OBJECT IDENTIFIER prefix common to all (potential) MIB object
   instances in that subtree.

   A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
   (called the family name) together with a bitstring value (called the
   family mask).  The family mask indicates which sub-identifiers of the
   associated family name are significant to the family's definition.

   For each possible managed object instance, that instance belongs to a
   particular view subtree family if both of the following conditions
   are true:

o    the OBJECT IDENTIFIER name of the managed object instance contains
     at least as many sub-identifiers as does the family name, and

o    each sub-identifier in the OBJECT IDENTIFIER name of the managed
     object instance matches the corresponding sub-identifier of the
     family name whenever the corresponding bit of the associated family
     mask is non-zero.

   When the configured value of the family mask is all ones, the view
   subtree family is identical to the single view subtree identified by
   the family name.

   When the configured value of the family mask is shorter than required
   to perform the above test, its value is implicitly extended with
   ones.  Consequently, a view subtree family having a family mask of
   zero length always corresponds to a single view subtree.

3.6.  MIB View

   A MIB view is a subset of the set of all instances of all object
   types defined according to the SMI [1] within an SNMPv2 context,
   subject to the following constraints:

o    It is possible to specify a MIB view which contains the full set of
     all object instances within an SNMPv2 context.

o    Each object instance within a MIB view is uniquely named by an
     ASN.1 OBJECT IDENTIFIER value.

   As such, identically named instances of a particular object type must
   be contained within different SNMPv2 contexts.  That is, a particular



McCloghrie                    Experimental                      [Page 9]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   object instance name resolves within a particular SNMPv2 context to
   at most one object instance.

   A MIB view is defined as a collection of view subtree families, where
   each view subtree family has a type.  The type determines whether the
   view subtree family is included in, or excluded from, the MIB view.

   A managed object instance is contained/not contained within the MIB
   view according to the view subtree families to which the instance
   belongs:

o    If a managed object instance belongs to none of the relevant
     subtree families, then that instance is not in the MIB view.

o    If a managed object instance belongs to exactly one of the relevant
     subtree families, then that instance is included in, or excluded
     from, the relevant MIB view according to the type of that subtree
     family.

o    If a managed object instance belongs to more than one of the
     relevant subtree families, then that instance is included in, or
     excluded from, the relevant MIB view according to the type of a
     particular one of the subtree families to which it belongs.  The
     particular subtree family is the one for which, first, the