As per Relevance of the word administrative, we have this rfc below:
Network Working Group K. McCloghrie,
Request for Comments: 1909 Cisco Systems, Inc
Category: Experimental February 1996
An Administrative Infrastructure for SNMPv
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Table of
1. Introduction ................................................ 2
2. Overview .................................................... 2
2.1 Contexts ................................................... 3
2.2 Authorization: Access Rights and MIB Views ................. 3
2.3 Authentication and Privacy ................................. 4
2.4 Access Control ............................................. 5
2.5 Security Models ............................................ 5
2.6 Proxy ...................................................... 5
3. Elements of the Model ....................................... 7
3.1 SNMPv2 Entity .............................................. 7
3.2 SNMPv2 Agent ............................................... 7
3.3 SNMPv2 Manager ............................................. 8
3.4 SNMPv2 Dual-Role Entity .................................... 8
3.5 View Subtree and Families .................................. 9
3.6 MIB View ................................................... 9
3.7 SNMPv2 Context ............................................. 10
3.7.1 Local SNMPv2 Context ..................................... 11
3.7.2 Proxy SNMPv2 Context ..................................... 11
3.8 SNMPv2 PDUs and Operations ................................. 12
3.8.1 The Report-PDU ........................................... 12
3.9 SNMPv2 Access Control Policy ............................... 13
4. Security Considerations ..................................... 13
5. Editor's Address ............................................ 14
6. Acknowledgements ............................................ 14
7. References .................................................. 14
Appendix A Disambiguating the SNMPv2 Protocol Definition ....... 16
Appendix B Who Sends Inform-Requests? ......................... 17
Appendix B.1 Management Philosophy ............................. 17
Appendix B.2 The Danger of Trap Storms ......................... 17
Appendix B.3 Inform-Requests ................................... 18
McCloghrie Experimental [Page 1]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
1.
A management system contains: several (potentially many) nodes,
with a processing entity, termed an agent, which has access
management instrumentation; at least one management station; and,
management protocol, used to convey management information
the agents and management stations. Operations of the protocol
carried out under an administrative framework which
authentication, authorization, access control, and privacy policies
Management stations execute management applications which monitor
control managed elements. Managed elements are devices such
hosts, routers, terminal servers, etc., which are monitored
controlled via access to their management information
It is the purpose of this document, An Administrative
for SNMPv2, to define an administrative framework which
effective management in a variety of configurations and environments
The SNMPv2 framework is fully described in [1-6]. This framework
derived from the original Internet-standard Network
Framework (SNMPv1), which consists of these three documents
STD 16, RFC 1155 [7] which defines the Structure of
Information (SMI), the mechanisms used for describing and
objects for the purpose of management
STD 16, RFC 1212 [8] which defines a more concise
mechanism, which is wholly consistent with the SMI
STD 15, RFC 1157 [9] which defines the Simple Network
Protocol (SNMP), the protocol used for network access to
objects
For information on coexistence between SNMPv1 and SNMPv2,
[10].
2.
A management domain typically contains a large amount of
information. Each individual item of management information is
instance of a managed object type. The definition of a related
of managed object types is contained in a Management Information
(MIB) module. Many such MIB modules are defined. For each
object type it describes, a MIB module defines not only the
and syntax of that managed object type, but also the method
identifying an individual instance so that multiple instances of
same managed object type can be distinguished
McCloghrie Experimental [Page 2]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
2.1.
Typically, there are many instances of each managed object
within a management domain. For simplicity, the method
identifying instances specified by the MIB module does not allow
instance to be distinguished amongst the set of all instances
the management domain; rather, it allows each instance to
identified only within some scope or "context", where there
multiple such contexts within the management domain. Often,
context is a physical device, or perhaps, a logical device,
a context can also encompass multiple devices, or a subset of
single device, or even a subset of multiple devices. Thus, in
to identify an individual item of management information within
management domain, its context must be identified in addition to
object type and its instance
For example, the managed object type, ifDescr [11], is defined as
description of a network interface. To identify the description
device-X's first network interface, three pieces of information
needed, e.g., device-X (the context), ifDescr (the managed
type), and "1" (the instance).
Note that each context has (at least) one globally-
identification within the management domain. Note also that the
item of management information can exist in multiple contexts. So
an item of management information can have multiple globally-
identifications, either because it exists in multiple contexts
and/or because each such context has multiple globally-
identifications
2.2. Authorization: Access Rights and MIB
For security reasons, it is often valuable to be able to restrict
access rights of some management applications to only a subset of
management information in the management domain. To provide
capability, access to a context is via a "MIB view" which details
specific set of managed object types (and optionally, the
instances of object types) within that context. For example, for
given context, there will typically always be one MIB view
provides access to all management information in that context,
often there will be other MIB views each of which contains
subset of the information. So, by providing access rights to
management application in terms of the particular (subset) MIB
it can access for that context, then the management application
restricted in the desired manner
Since managed object types (and their instances) are identified
the tree-like naming structure of ISO's OBJECT IDENTIFIERs [12, 1],
McCloghrie Experimental [Page 3]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
it is convenient to define a MIB view as the combination of a set
"view subtrees", where each view subtree is a sub-tree within
managed object naming tree. Thus, a simple MIB view (e.g.,
managed objects within the Internet Network Management Framework)
be defined as a single view sub-tree, while more complicated
views (e.g., all information relevant to a particular
interface) can be represented by the union of multiple view sub
trees
While any set of managed objects can be described by the union
some number of view subtrees, situations can arise that would
a very large number of view subtrees. This could happen,
example, when specifying all columns in one conceptual row of a
table because they would appear in separate subtrees, one per column
each with a very similar format. Because the formats are similar
the required set of subtrees can easily be aggregated into
structure. This structure is named a family of view subtrees
the set of subtrees that it conceptually represents. A family
view subtrees can either be included or excluded from a MIB view
In addition to restricting access rights by identifying (sub-)sets
management information, it is also valuable to restrict the
allowed on the management information within a particular context
For example, one management application might be prohibited
write-access to a particular context, while another might be
to perform any type of operation
2.3. Authentication and
The enforcement of access rights requires the means not only
identify the entity on whose behalf a request is generated but
to authenticate such identification. Another security
which is (optionally) provided is the ability to protect the
within an SNMPv2 operation from disclosure (i.e., to encrypt
data). This is particularly useful when sensitive data (e.g.,
passwords, or security keys) are accessed via SNMPv2 requests
Recommendations for which algorithms are best for authentication
privacy are subject to change. Such changes may occur as and
new research results on the vulnerability of various algorithms
published, and/or with the prevailing status of export control
patent issues. Thus, it is valuable to allow these algorithms to
specified as parameters, so that new algorithms can be
over time. In particular, one type of algorithm which may
useful in the future is the set of algorithms associated
asymmetric (public key) cryptography
Note that not all accesses via SNMPv2 requests need to be secure
McCloghrie Experimental [Page 4]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
Indeed, there are purposes for which insecure access is required
One example of this is the ability of a management application
learn about devices of which it has no previous knowledge.
example is to perform any synchronization which the
algorithms need before they can be used to communicate securely
This need for insecure access is accommodated by defining one of
algorithms for authentication as providing no authentication,
similarly, one of the algorithms for privacy as providing
protection against disclosure. (The combination of these
insecure algorithms is sometimes referred to as "noAuth/noPriv".)
2.4. Access
An access control policy specifies the types of SNMPv2 requests
associated MIB views which are authorized for a particular
(on whose behalf a request is generated) when using a
level of security to access a particular context
2.5. Security
A security model defines the mechanisms used to achieve
administratively-defined level of security for protocol interactions
(1) by defining the security parameters associated with
communication, including the authentication and privacy
and the security keys (if any) used
(2) by defining how entities on whose behalf requests are generated
identified
(3) by defining how contexts are identified
(4) by defining the mechanisms by which an access control policy
derived whenever management information is to be accessed
2.6.
It is an SNMPv2 agent which responds to requests for access
management information. Each such request is contained within
SNMPv2 message which provides the capability to perform a
operation on a list of items of management information. Rather
having to identify the context as well as the managed object type
instance for each item of management information, each SNMPv2
is concerned with only a single context. Thus, an SNMPv2 agent
be able to process requests for all items of management
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
proxy for some other agent. The term "proxy" has historically
used very loosely, with multiple different meanings. These
meanings include (among others):
(1) the forwarding of SNMPv2 requests on to other SNMP agents
regard for what managed object types are being accessed;
example, in order to forward SNMPv2 request from one
domain to another, or to translate SNMPv2 requests into SNMPv
requests
(2) the translation of SNMPv2 requests into operations of some non-
management protocol
(3) support for aggregated managed objects where the value of
managed object instance depends upon the values of multiple
(remote) items of management information
Each of these scenarios can be advantageous; for example, support
aggregation for management information can significantly reduce
bandwidth requirements of large-scale management activities
However, using a single term to cover multiple different
causes confusion
To avoid such confusion, this SNMPv2 administrative framework
the term "proxy" with a much more tightly defined meaning,
covers only the first of those listed above. Specifically,
distinction between a "regular SNMPv2 agent" and a "proxy SNMPv
agent" is simple
- a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests
to other agents according to the context, and irrespective of
specific managed object types being accessed
- in contrast, an SNMPv2 agent which processes SNMPv2
according to the (names of the) individual managed object types
instances being accessed, is NOT a proxy SNMPv2 agent from
perspective of this administrative model
Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for
particular context, although information on how to forward
request is specifically associated with that context, the
SNMPv2 agent has no need of a detailed definition of the MIB
(since the proxy SNMPv2 agent forwards the request irrespective
the managed object types).
In contrast, a SNMPv2 agent operating without proxy must have
detailed definition of the MIB view, and even if it needs to
McCloghrie Experimental [Page 6]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
requests to other agents, that need is dependent on the
managed object instances being accessed (i.e., not only on
context).
3. Elements of the
This section provides a more formal description of the model
3.1. SNMPv2
An SNMPv2 entity is an actual process which performs
operations by generating and/or responding to SNMPv2
messages in the manner specified in [4]. An SNMPv2 entity
the identity of a particular administrative entity when processing
SNMPv2 message
An SNMPv2 entity is not required to process multiple
messages concurrently, regardless of whether such messages require
to assume the identity of the same or different
entity. Thus, an implementation of an SNMPv2 entity which
more than one administrative entity need not be multi-threaded
However, there may be situations where implementors may choose to
multi-threading
An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages
each transport service address for which it is configured to do so
It is a local matter whether an SNMPv2 entity also listens for SNMPv
messages on any other transport service addresses. In the absence
any other information on where to listen, an SNMPv2 entity
listen on the transport service addresses corresponding to
standard transport-layer "ports" [5] on its local network-
addresses
3.2. SNMPv2
An SNMPv2 agent is the operational role assumed by an SNMPv2
when it acts in an agent role. Specifically, an SNMPv2
performs SNMPv2 management operations in response to received SNMPv
protocol messages (except for inform notifications).
In order to be manageable, all network components need to
instrumented. SNMPv2 access to the instrumented information is
the managed objects supported by an SNMPv2 agent in one or
contexts
McCloghrie Experimental [Page 7]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
3.3. SNMPv2
An SNMPv2 manager is the operational role assumed by an SNMPv2
when it acts in a manager role on behalf of management applications
Specifically, an SNMPv2 manager initiates SNMPv2
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
networking application, be instrumented for the purposes of
managed. Such instrumentation of an SNMPv2 manager (just like
any other networking application) is accessible via the
objects supported by an SNMPv2 agent. As such, an SNMPv2 manager
no different from any other network application in that it
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
which provides access to the SNMPv2 manager's instrumentation
3.4. SNMPv2 Dual-Role
An SNMPv2 entity which sometimes acts in an agent role and
acts in a manager role, is termed an SNMPv2 dual-role entity.
SNMPv2 dual-role entity initiates requests by acting in a
role, and processes requests regarding management
accessible to it (locally or via proxy) through acting in an
role. In the case of sending inform notifications, an SNMPv2 dual
role entity acts in a manager role in initiating an
notification containing management information which is accessible
it when acting in an agent role
An SNMPv2 entity which can act only in an SNMPv2 manager role is
SNMP-manageable, since there is no way to access its
instrumentation. In order to be SNMP-manageable, an SNMPv2
must be able to act in an SNMPv2 agent role in order to allow
instrumentation to be accessed. Thus, it is highly desirable
all SNMPv2 entities be either SNMPv2 agents or SNMPv2 dual-
entities
There are two categories of SNMPv2 dual-role entities: proxy SNMPv
agents and (so-called) mid-level managers. Proxy SNMPv2 agents
forward requests/responses; they do not originate requests.
contrast, mid-level managers often originate requests. (Note
the term proxy SNMPv2 agent does not include an SNMPv2 agent
translates SNMPv2 requests into the requests of some other
protocol; see section 2.6.)
McCloghrie Experimental [Page 8]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
3.5. View Subtree and
A view subtree is the set of all MIB object instances which have
common ASN.1 OBJECT IDENTIFIER prefix to their names. A view
is identified by the OBJECT IDENTIFIER value which is the
OBJECT IDENTIFIER prefix common to all (potential) MIB
instances in that subtree
A family of view subtrees is a pairing of an OBJECT IDENTIFIER
(called the family name) together with a bitstring value (called
family mask). The family mask indicates which sub-identifiers of
associated family name are significant to the family's definition
For each possible managed object instance, that instance belongs to
particular view subtree family if both of the following
are true
o the OBJECT IDENTIFIER name of the managed object instance
at least as many sub-identifiers as does the family name,
o each sub-identifier in the OBJECT IDENTIFIER name of the
object instance matches the corresponding sub-identifier of
family name whenever the corresponding bit of the associated
mask is non-zero
When the configured value of the family mask is all ones, the
subtree family is identical to the single view subtree identified
the family name
When the configured value of the family mask is shorter than
to perform the above test, its value is implicitly extended
ones. Consequently, a view subtree family having a family mask
zero length always corresponds to a single view subtree
3.6. MIB
A MIB view is a subset of the set of all instances of all
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
all object instances within an SNMPv2 context
o Each object instance within a MIB view is uniquely named by
ASN.1 OBJECT IDENTIFIER value
As such, identically named instances of a particular object type
be contained within different SNMPv2 contexts. That is, a
McCloghrie Experimental [Page 9]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
object instance name resolves within a particular SNMPv2 context
at most one object instance
A MIB view is defined as a collection of view subtree families,
each view subtree family has a type. The type determines whether
view subtree family is included in, or excluded from, the MIB view
A managed object instance is contained/not contained within the
view according to the view subtree families to which the
belongs
o If a managed object instance belongs to none of the
subtree families, then that instance is not in the MIB view
o If a managed object instance belongs to exactly one of the
subtree families, then that instance is included in, or
from, the relevant MIB view according to the type of that
family
o If a managed object instance belongs to more than one of
relevant subtree families, then that instance is included in,
excluded from, the relevant MIB view according to the type of
particular one of the subtree families to which it belongs.
particular subtree family is the one for which, first,
associated family name comprises the greatest number of sub
identifiers, and, second, the associated family name
lexicographically greatest
3.7. SNMPv2
An SNMPv2 context is a collection of management
accessible by an SNMPv2 entity. The collection of
information identified by a context is either local or proxy
For a local SNMPv2 context which is realized by an SNMPv2 entity
that SNMPv2 entity uses locally-defined mechanisms to access
management information identified by the SNMPv2 context
For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv
agent to access the management information identified by the SNMPv
context
The term remote SNMPv2 context is used at an SNMPv2 manager
indicate a SNMPv2 context (either local or proxy) which is
realized by the local SNMPv2 entity (i.e., the local SNMPv2
uses neither locally-defined mechanisms, nor acts as a proxy SNMPv
agent, to access the management information identified by the SNMPv
context).
McCloghrie Experimental [Page 10]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
3.7.1. Local SNMPv2
A local context refers to a collection of MIB objects
(logically) belong to a single entity within a managed device.
an SNMPv2 entity accesses that management information, it does
using locally-defined mechanisms
Because a device may contain several such local entities, each
context has associated with it a "local entity" name. Further
because management information changes over time, each local
also has associated with it an associated temporal domain, termed
"local time". This allows, for example, one context to refer to
current values of a device's parameters, and a different context
refer to the values that the same parameters for the same device
have after the device's next restart
3.7.2. Proxy SNMPv2
A proxy relationship exists when a proxy SNMPv2 agent processes
received SNMPv2 message (a request or a response) by forwarding it
another entity, solely according to the SNMPv2 context of
received message. Such a context is called a proxy SNMPv2 context
When an SNMPv2 entity processes management requests/responses for
proxy context, it is operating as a proxy SNMPv2 agent
The transparency principle that defines the behavior of an SNMPv
entity in general, applies in particular to a proxy SNMPv2 context
The manner in which a receiving SNMPv2 entity processes SNMPv
protocol messages sent by another SNMPv2 entity is
transparent to the sending SNMPv2 entity
Implicit in the transparency principle is the requirement that
semantics of SNMPv2 management operations are preserved between
two SNMPv2 peers. In particular, the "as if simultaneous"
of
Set operation are extremely difficult to guarantee if its
extends to management information resident at multiple
locations. Note however, that agents which support the forwarding
Set operations concerning information at multiple locations are
considered to be proxy SNMPv2 agents (see section 2.6 above).
Also implicit in the transparency principle is the requirement that
throughout its interaction with a proxy SNMPv2 agent, an SNMPv
manager is supplied with no information about the nature or
of the proxy mechanisms used to perform its requests. That is,
should seem to the SNMPv2 manager (except for any distinction in
McCloghrie Experimental [Page 11]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
underlying transport address) as if it were interacting via SNMPv
directly with the proxied device. Thus, a timeout in
communication between a proxy SNMPv2 agent and its proxied
should be represented as a timeout in the communication between
SNMPv2 manager and the proxy SNMPv2 agent. Similarly, an
response from a proxied device should - as much as possible -
represented by the corresponding error response in the
between the proxy SNMPv2 agent and SNMPv2 manager
3.8. SNMPv2 PDUs and
An SNMPv2 PDU is defined in [4]. Each SNMPv2 PDU specifies
particular operation, one of
SNMPv2-
3.8.1. The Report-
[4] requires that an administrative framework which makes use of
Report-PDU must define its usage and semantics. With
administrative framework, the Report-PDU differs from the other
types described in [4] in that it is not a protocol operation
SNMPv2 managers and agents, but rather is an aspect of error
reporting between SNMPv2 entities. Specifically, it is an
between two protocol engines
A communication between SNMPv2 entities is in the form of an SNMPv
message. Such a message is formatted as a "wrapper" encapsulating
PDU according to the "Elements of Procedure" for the security
used for transmission of the message
While processing a received communication, an SNMPv2 entity
determine that the received message is unacceptable due to a
associated with the contents of the message "wrapper". In this case
an appropriate counter is incremented and the received message
discarded without further processing (and without transmission of
Response-PDU).
However, if an SNMPv2 entity acting in the agent role makes such
determination, then after incrementing the appropriate counter,
may be required to generate a Report-PDU and to send it to
McCloghrie Experimental [Page 12]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
transport address which originated the received message
If the agent is able to determine the value of the request-id
of the received PDU [4], then it must use that value for
request-id field of the Report-PDU. Otherwise, the value 2147483647
is used
The error-status and error-index fields of the Report-PDU are
set to zero. The variable-bindings field contains a single variable
the identity of the counter which was incremented and its new value
There is at least one case in which a Report-PDU must not be sent
an SNMPv2 entity acting in the agent role: if the received
was tagged as a Report-PDU. Particular security models may
other such cases
3.9. SNMPv2 Access Control
An SNMPv2 access policy specifies the types of SNMPv2
authorized for a particular identity using a particular level
security, and if the operation is to be performed on a local SNMPv
context, two accessible MIB views. The two MIB views are a read-
and a write-view. A read-view is a set of object
authorized for the identity when reading objects. Reading
occurs when processing a retrieval (get, get-next, get-bulk
operation and when sending a notification. A write-view is the
of object instances authorized for the identity when writing objects
Writing objects occurs when processing a set operation.
identity's access rights may be different at different agents
A security model defines how an SNMPv2 access policy is derived
however, the application of an SNMPv2 access control policy
performed only
o on receipt of GetRequest, GetNextRequest, GetBulkRequest,
SetRequest operations;
o prior to transmission of SNMPv2-Trap and Inform operations
Note that application of an SNMPv2 access control policy is
performed for Response or Report operations
4. Security
Security issues are not directly discussed in this memo
McCloghrie Experimental [Page 13]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
5. Editor's
Keith
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 408 526 5260
EMail: kzm@cisco.
6.
This document is the result of significant work by three
contributors
Keith McCloghrie (Cisco Systems, kzm@cisco.com
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us
Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca
The authors wish to acknowledge James M. Galvin of
Information Systems who contributed significantly to earlier work
which this memo is based, and the general contributions of members
the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov
Steven L. Waldbusser
A special thanks is extended for the contributions of
Uri Blumenthal (IBM
Shawn Routhier (Epilogue
Barry Sheehan (IBM
Bert Wijnen (IBM
7.
[1] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[2] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Textual Conventions for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[3] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S., Waldbusser, "Conformance Statements for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
McCloghrie Experimental [Page 14]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
[4] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Protocol Operations for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[5] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
Waldbusser, S., "Transport Mappings for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
Waldbusser, S., "Management Information Base for Version 2 of
Simple Network Management Protocol (SNMPv2)", RFC 1907,
January 1996.
[7] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, May 1990.
[8] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, SNMP Research
Performance Systems International, MIT Laboratory for
Science, May 1990.
[10] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
Waldbusser, S., "Coexistence between Version 1 and Version 2 of
Internet-standard Network Management Framework", RFC 1908,
1996.
[11] McCloghrie, K., and F. Kastenholz, "Evolution of the
Group of MIB-II", RFC 1573, Cisco Systems, FTP Software,
1994.
[12] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization.
Standard 8824, (December, 1987).
McCloghrie Experimental [Page 15]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
APPENDIX A - Disambiguating the SNMPv2 Protocol
The descriptions in [4] of the role in which an SNMPv2 entity acts
sending an Inform-Request PDU are ambiguous. The following
serve to remove those ambiguities
(1) Add the following sentence to section 2.1:
Further, when an SNMPv2 entity sends an inform notification
it acts in a manager role in respect to initiating
operation, but the management information contained in
inform notification is associated with that entity acting
an agent role. By convention, the inform is sent from
same transport address as the associated agent role
listening on
(2) Modify the last sentence of the second paragraph in section 2.3:
This type is used by one SNMPv2 entity, acting in a
role, to notify another SNMPv2 entity, also acting in
manager role, of management information associated with
sending SNMPv2 entity acting in an agent role
(3) Modify the second paragraph of section 4.2 (concerning
generation of Inform-Request PDUs):
It is mandatory that all SNMPv2 entities acting in a
role be able to generate the following PDU types: GetRequest
PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU
and Response-PDU; further, all such implementations must
able to receive the following PDU types: Response-PDU
SNMPv2-Trap-PDU, InformRequest-PDU. It is mandatory that
dual-role SNMPv2 entities must be able to generate an Inform
Request PDU
(4) Modify the first paragraph of section 4.2.7:
An InformRequest-PDU is generated and transmitted at
request of an application in a SNMPv2 entity acting in
manager role, that wishes to notify another application (
an SNMPv2 entity also acting in a manager role) of
in a MIB view which is accessible to the sending SNMPv2
when acting in an agent role
McCloghrie Experimental [Page 16]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
APPENDIX B - Who Sends Inform-Requests
B.1. Management
Ever since its beginnings as SGMP, through its definition as SNMPv1,
and continuing with the definition of SNMPv2, SNMP has embodied
than just a management protocol and the definitions of MIB objects
Specifically, SNMP has also had a fundamental philosophy
management, consisting of a number of design strategies.
strategies have always included the following
(1) The impact of incorporating an SNMP agent into a system should
minimal, so that both: a) it is feasible to do so even in
smallest/cheapest of systems, and b) the operational role
performance of a system is not compromised by the inclusion of
SNMP agent. This promotes widespread development, which
ubiquitous deployment of manageable systems
(2) Every system (potentially) incorporates an SNMP agent.
contrast, the number of SNMP managers is limited. Thus, there is
significantly larger number of SNMP agents than SNMP managers
Therefore, overall system development/complexity/cost is
if the SNMP agent is allowed to be simple and any
complexity is performed by an SNMP manager
(3) The number of unsolicited messages generated by SNMP agents
minimized. This enables the amount of network management
to be controlled by the small number of SNMP managers which
(more) directly controlled by network operators. In fact,
control is considered of greater importance than any
protocol overhead which might be incurred. Monitoring of
state at any significant level of detail is accomplished
by SNMP managers polling for the appropriate information, with
use of unsolicited messages confined to those situations where
is necessary to properly guide an SNMP manager regarding the
and focus of its polling. This strategy is sometimes referred
as "trap-directed polling".
B.2. The Danger of Trap
The need for such control over the amount of network
traffic is due to the potential that the SNMP manager receiving
unsolicited message does not want, no longer wants, or already
of the information contained in the message. This potential
significantly reduced by having the majority of messages be
requests for information by SNMP managers and responses (to
requests) from SNMP agents
McCloghrie Experimental [Page 17]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
The danger of not having the amount of network management
controlled in this manner is the potential for a "storm" of
traps. As a simple example of "useless", consider that after
building power outage, every device in the network sends a
trap, even though every SNMP manager and every network
already knows what happened. For a simple example of "storm",
consider the result if each transmitted trap caused the sending
another. The greater the number of problems in the state of
network, the greater the risk of such a storm occurring,
in the unstructured, heterogeneous environment typical of today'
internets
While SNMP philosophy considers the above to be more important
any lack of reliability in unsolicited messages,
users/developers have been wary of using traps because of the
(typically) of an unreliable transport protocol and because traps
not acknowledged. However, following this logic would imply
having acknowledged-traps would make them reliable; of course,
is false since no amount of re- transmission will succeed if
receiver and/or the connectivity to the receiver is down. A
manager cannot just sit and wait and assume the network is fine
because it is not receiving any unsolicited messages
B.3. Inform-
One of the new features of SNMPv2 is the Inform-request PDU.
Inform-Request contains management information specified in terms
MIB objects for a context supported by the sender. Since
definition, an SNMPv2 manager does not itself have managed
(see sections 3.3), the managed objects contained in the Inform
request belong to a context of an SNMPv2 agent, just like the
objects contained in an SNMPv2-Trap
However, it is not the purpose of an Inform-request to change
above described philosophy, i.e., it would be wrong to consider it
an "acknowledged trap". To do so, would make the likelihood
effect of trap storms worse. Recall the building power
example: with regular traps, the SNMP manager's buffer
overflows when it receives messages faster than it can cope with;
contrast, if every device in the network were to send a
Inform-request, then after a power outage, all will re-transmit
Inform-request several times unless the receiving SNMP managers
responses. In the best case when no messages are lost or re
transmitted, there are twice as many useless messages; in the
case, the SNMP manager is unable to respond at all and every
is re-transmitted its maximum number of times
McCloghrie Experimental [Page 18]
RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
The above serves to explain the rationale behind the definition (
Appendix A's update to section 4.2.7 of [4]) that
An InformRequest-PDU is generated and transmitted at the request
an application in a SNMPv2 entity acting in a manager role,
wishes to notify another application (via an SNMPv2 entity
acting in a manager role) of information in a MIB view which
accessible to the sending SNMPv2 entity when acting in an
role
This definition says that SNMPv2 agents do not send Inform-Requests
which has three implications (ordered in terms of importance):
(1) the number of devices which send Inform-requests is required to
a small subset of all devices in the network
(2) while some devices traditionally considered to be SNMP agents
perfectly capable of sending Inform-requests, the overall
development/complexity/cost is not increased as it would be
having to configure/re-configure every SNMPv2 agent as to
Inform-requests to send where and how often;
(3) the cost of implementing an SNMPv2 agent in the smallest/
system is not increased
McCloghrie Experimental [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
