Internet-Draft SNMPv3 Applications August 1997
SNMPv3 Applications
August 1, 1997
<draft-ietf-snmpv3-appl-01.txt>
David B. Levi
SNMP Research, Inc.
levi@snmp.com
Paul Meyer
Secure Computing Corporation
paul_meyer@securecomputing.com
Bob Stewart
Cisco Systems
bstewart@cisco.com
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Expires January 1998 [Page 1]
Internet-Draft SNMPv3 Applications August 1997
1. Abstract
This memo describes the various types of SNMP applications which make
use of an SNMP engine as described in [SNMP-ARCH]. There are five
types of application described herein:
- Applications which initiate SNMP Get, GetNext, GetBulk, and/or
Set requests, called 'command generators'.
- Applications which respond to SNMP Get, GetNext, GetBulk,
and/or Set requests, called 'command responders'.
- Applications which generate notifications, called
'notification originators'.
- Applications which receive notifications, called 'notification
receivers'.
- Applications which forward SNMP Get, GetNext, GetBulk, and/or
Set requests or notifications, called 'proxy forwarders'.
This memo also defines MIBs for specifying targets of management
operations, for notification filtering, and for proxy forwarding.
Expires January 1998 [Page 2]
Internet-Draft SNMPv3 Applications August 1997
2. Overview
This document describes the five types of SNMP applications:
- Applications which initiate SNMP Get, GetNext, GetBulk, and/or
Set requests, called 'command generators'.
- Applications which respond to SNMP Get, GetNext, GetBulk,
and/or Set requests, called 'command responders'.
- Applications which generate notifications, called
'notification originators'.
- Applications which receive notifications, called 'notification
receivers'.
- Applications which forward SNMP Get, GetNext, GetBulk, and/or
Set requests or notifications, called 'proxy forwarder'.
Note that there are no restrictions on which types of applications
may be associated with a particular SNMP engine. For example, a
single SNMP engine may in fact be associated with both command
generator and command responder applications.
2.1. Command Generators
A command generator application initiates SNMP Get, GetNext, GetBulk,
and/or Set requests, as well as processing the response to a request
which it generated.
2.2. Command Responders
A command responder application receives SNMP Get, GetNext, GetBulk,
and/or Set requests for which the contextEngineID is equal to that of
the local engine through which the request was received. The command
responder will perform the appropriate protocol operation, using
access control, and will generate a response message to be sent to
the request's originator.
2.3. Notification Originators
A notification originator conceptually monitors a system for
particular events or conditions, and generates Trap and/or Inform
Expires January 1998 [Page 3]
Internet-Draft SNMPv3 Applications August 1997
messages based on these events or conditions. A notification
originator must have a mechanism for determining where to send
messages, and what SNMP version and security parameters to use when
sending messages. A mechanism and MIB for this purpose is provided
in this document.
2.4. Notification Receivers
A notification receiver application listens for notification
messages, and generates response messages when a message containing
an Inform PDU is received.
2.5. Proxy Forwarder
A proxy forwarder application forwards SNMP messages. Note that
implementation of a proxy forwarder application is optional. The
sections describing proxy (4.5, 5.3, and 8) may be skipped for
implementations that do not include a proxy forwarder application.
The term "proxy" has historically been used very loosely, with
multiple different meanings. These different meanings include (among
others):
(1) the forwarding of SNMP requests to other SNMP entities without
regard for what managed object types are being accessed; for
example, in order to forward an SNMP request from one transport
domain to another, or to translate SNMP requests of one version
into SNMP requests of another version;
(2) the translation of SNMP requests into operations of some non-SNMP
management protocol; and
(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 of 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 document uses the term "proxy" with a
much more tightly defined meaning. The term "proxy" is used in this
document to refer to a proxy forwarder application which forwards
Expires January 1998 [Page 4]
Internet-Draft SNMPv3 Applications August 1997
either SNMP requests, notifications, and responses without regard for
what managed objects are contained within requests or notifications.
This definition is most closely related to the first definition
above. Note however that in the SNMP architecture [SNMP-ARCH], a
proxy forwarder is actually an application, and need not be
associated with what is traditionally thought of as an SNMP agent.
Specifically, the distinction between a traditional SNMP agent and a
"proxy forwarder application" is simple:
- a proxy forwarder application forwards requests and/or
notifications on to other SNMP engines according to the
context, and irrespective of the specific managed object types
being accessed, and forwards the response to such previously
forwarded messages back to the SNMP engine from which the
original message was received;
- in contrast, the command responder application that is part of
what is traditionally thought of as an SNMP agent, and which
processes SNMP requests according to the (names of the)
individual managed object types and instances being accessed,
is NOT a proxy forwarder application from the perspective of
this document.
Thus, when a proxy forwarder application forwards a request or
notification for a particular context, not only is the information on
how to forward the request specifically associated with that context,
but the proxy forwarder application has no need of a detailed
definition of a MIB view (since the proxy forwarder application
forwards the request irrespective of the managed object types).
In contrast, a command responder application must have the detailed
definition of the MIB view, and even if it needs to issue requests to
other SNMP entities, that need is dependent on the individual managed
object instances being accessed (i.e., not only on the context).
3. Management Targets
Some types of applications (in particular notification generators and
proxy forwarders) require a mechanism for determining where and how
to send generated messages. This document provides a mechanism and
MIB for this purpose. The set of information that describes where
and how to send a message is called a 'Management Target', and
consists of two kinds of information:
Expires January 1998 [Page 5]
Internet-Draft SNMPv3 Applications August 1997
- Destination information, consisting of a transport domain and
a transport address. This is also termed a transport
endpoint.
- SNMP information, consisting of message processing model,
security model, level of security, and security name
information.
There can be a many-to-many relationship between these two types of
information. That is, there may be multiple transport endpoints
associated with a particular set of SNMP information, or a particular
transport endpoint may be associated with several sets of SNMP
information.
A management target is defined as the combination of a single set of
SNMP information and a single transport endpoint. Management targets
are grouped according to their SNMP information. That is, each
distinct set of SNMP information may be associated with multiple
transport endpoints. The set of management targets which are defined
by a distinct set of SNMP information are considered to be members of
the same management target group. For example, the following
contains two management target groups, each of which contains three
management targets:
(version=snmpv3, secmodel=usm, secname=joe, udp=128.1.2.3:162)
(version=snmpv3, secmodel=usm, secname=joe, udp=128.1.3.5:162)
(version=snmpv3, secmodel=usm, secname=joe, udp=128.1.4.7:162)
(version=snmpv3, secmodel=usm, secname=martha, udp=128.1.2.3:162)
(version=snmpv3, secmodel=usm, secname=martha, udp=128.1.3.5:162)
(version=snmpv3, secmodel=usm, secname=martha, udp=128.1.4.7:162)
An application will generally make use of some subset of the entire
set of management targets which are configured.
4. Elements Of Procedure
The following sections describe the procedures followed by each type
of application when generating messages for transmission or when
processing received messages. Applications communicate with the
Message Processing Subsystem using the abstract service interfaces
defined in [SNMP-ARCH].
Expires January 1998 [Page 6]
Internet-Draft SNMPv3 Applications August 1997
4.1. Command Generators
A command generator initiates an SNMP request by calling the Message
Processing Subsystem using the following abstract service interface:
statusInformation = -- sendPduHandle if success
-- errorIndication if failure
sendPdu(
IN transportDomain -- transport domain to be used
IN transportAddress -- destination network address
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
)
Where:
- The transportDomain is that of the destination of the message.
- The transportAddress is the destination of the message.
- The messageProcessingModel indicates which Message Processing
Subsystem the application wishes to use.
- The securityModel is the security model that the application
wishes to use.
- The securityName is whatever the security model wishes to use.
- The securityLevel is the security level that the application
wishes to use.
- The contextEngineID is provided by the command generator if it
wishes to explicitly specify the location of the management
information it is requesting.
- The contextName is provided by the command generator if it
wishes to explicitly specify the local context name for the
management information it is requesting. The command
generator may omit this parameter, in which case the default
context is used.
Expires January 1998 [Page 7]
Internet-Draft SNMPv3 Applications August 1997
- The pduVersion indicates the version of the PDU to be sent.
- The PDU is a value contructed by the command generator
containing the management operation that the command generator
wishes to perform.
- The expectResponse argument indicates that a response is
expected.
The result of the sendPdu interface indicates whether the PDU was
successfully sent. If it was successfully sent, the returned value
will be a sendPduHandle. The command generator should store the
sendPduHandle so that it can correlate a response to the original
request.
The Message Processing Subsystem is responsible for delivering the
response to a particular request to the correct command generator
application. The abstract service interface used is:
processResponsePdu( -- process Response PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN statusInformation -- success or errorIndication
IN sendPduHandle -- handle from sendPDU
)
Where:
- The messageProcessingModel is the value from the received
response.
- The securityModel is the value from the received response.
- The securityName is the value from the received response.
- The securityLevel is the value from the received response.
- The contextEngineID is the value from the received response.
- The contextName is the value from the received response.
Expires January 1998 [Page 8]
Internet-Draft SNMPv3 Applications August 1997
- The pduVersion indicates the version of the PDU in the
received response.
- The PDU is the value from the received response.
- The statusInformation indicates success or failure in
receiving the response.
- The sendPduHandle is the value returned by the sendPdu call
which generated the original request to which this is a
response.
The procedure when a command generator receives a response is as
follows:
(1) The operation type is determined from the ASN.1 tag value
associated with the PDU parameter. The operation type should
always be a Response PDU (the Message Processing Subsystem should
never call a command generator application using the
processResponsePdu interface for any other type of message).
(2) The request-id, error-status, error-index, and variable-bindings
are extracted from the PDU and saved.
(3) At this point, it is up to the application as to how to continue
processing the PDU.
Expires January 1998 [Page 9]
Internet-Draft SNMPv3 Applications August 1997
4.2. Command Responders
Before a command responder application can process messages, it must
first associate itself with an SNMP engine. The abstract service
interface used for this purpose is:
statusInformation = -- success or errorIndication
registerContextEngineID(
IN contextEngineID -- take responsibility for this one
IN pduType -- the pduType(s) to be registered
)
Where:
- The statusInformation indications success or failure of the
registration attempt.
- The contextEngineID is equal to the snmpEngineID of the SNMP
engine with which the command responder is registering.
- The pduType indicates a Get, GetNext, GetBulk, or Set pdu.
Note that if another command responder application is already
registered with an SNMP engine, any further attempts to register with
the same contextEngineID and pduType will be ignored. This implies
that separate command responder applications could register
separately for the various pdu types. However, in practice this is
undesirable, and only a single command responder application should
be registered with an SNMP engine at any given time.
A command responder application can disassociate with an SNMP engine
using the following abstract service interface:
unregisterContextEngineID(
IN contextEngineID -- give up responsibility for this one
IN pduType -- the pduType(s) to be unregistered
)
Where:
- The contextEngineID is equal to the snmpEngineID of the SNMP
engine with which the command responder is cancelling the
registration.
- The pduType indicates a Get, GetNext, GetBulk, or Set pdu.
Once the command responder has registered with the SNMP engine, it
Expires January 1998 [Page 10]
Internet-Draft SNMPv3 Applications August 1997
waits to receive SNMP messages. The abstract service interface used
for receiving messages is:
processPdu( -- process Request/Notification PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
IN stateReference -- reference to state information
) -- needed when sending a response
Where:
- The messageProcessingModel indicates which Message Processing
subsystem received and processed the message.
- The securityModel is the value from the received message.
- The securityName is the value from the received message.
- The securityLevel is the value from the received message.
- The contextEngineID is the value from the received message.
- The contextName is the value from the received message.
- The pduVerion indicates the version of the PDU in the received
message.
- The PDU is the value from the received message.
- The maxSizeResponseScopedPDU is the value from the received
message.
- The stateReference is a value assigned by the Message
Processing Subsystem, which caches information about each
received request message. The stateReference is a reference
to this cached information. This value must be returned to
the Message Processing Subsystem in order to generate a
response.
The procedure when a message is received is as follows.
Expires January 1998 [Page 11]
Internet-Draft SNMPv3 Applications August 1997
(1) The operation type is determined from the ASN.1 tag value
associated with the PDU parameter. The operation type should
always be a Get, GetNext, GetBulk, or Set.
(2) The request-id is extracted from the PDU and saved.
(3) If the SNMPv2 operation type is GetBulk, the non-repeaters and
max-repetitions values are extracted from the PDU and saved.
(4) The variable-bindings are extracted from the PDU and saved.
(5) The management operation represented by the SNMPv2 operation type
is performed with respect to the relevant MIB view within the
context named by the contextName, according to the procedures set
forth in [RFC1905]. The relevant MIB view is determined by the
securityLevel, securityModel, contextName, securityName, and SNMPv2
operation type. To determine whether a particular object instance
is within the relevant MIB view, the following abstract service
interface is called:
statusInformation = -- success or errorIndication
isAccessAllowed(
IN securityModel -- Security Model in use
IN securityName -- principal who wants to access
IN securityLevel -- Level of Security
IN viewType -- read, write, or notify view
IN contextName -- context containing variableName
IN variableName -- OID for the managed object
)
Where:
- The securityModel is the value from the received message.
- The securityName is the value from the received message.
- The securityLevel is the value from the received message.
- The viewType indicates whether the pdu type is a read or write
operation.
- The contextName is the value from the received message.
- The variableName is the object instance of the variable for
which access rights are to be checked.
Expires January 1998 [Page 12]
Internet-Draft SNMPv3 Applications August 1997
Normally, the result of the management operation will be a new PDU
value, and processing will continue in step (6) below. However, if
at any time during the processing of the management operation, the
context named by the contextName parameter is unavailable,
processing of the management operation is halted, no result PDU is
generated, the snmpUnavailableContexts counter is incremented, and
control is passed to step (6) below.
(6) The Message Processing Subsystem is called to generate a response
or report message. The abstract service interface is:
returnResponsePdu(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
) -- error counter OID/value if error
Where:
- The messageProcessingModel is the value from the processPdu
call.
- The securityModel is the value from the processPdu call.
- The securityName is the value from the processPdu call.
- The securityLevel is the value from the processPdu call.
- The contextEngineID is the value from the processPdu call.
- The contextName is the value from the processPdu call.
- The pduVersion indicates the version of the PDU to be
returned. If no result PDU was generated, the pduVersion is
an undefined value.
- The PDU is the result generated in step (5) above. If no
result PDU was generated, the PDU is an undefined value.
Expires January 1998 [Page 13]
Internet-Draft SNMPv3 Applications August 1997
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The stateReference is the value from the processPdu call.
- The statusInformation either contains an indication that no
error occured and that a response should be generated, or
contains an indication that an error occured along with the
OID and counter value of the snmpUnavailableContexts object.
Note that a command responder application should always call the
returnResponsePdu abstract service interface, even in the event of an
error such as a resource allocation error. In the event of such an
error, the PDU value passed to returnResponsePdu should contain
appropriate values for errorStatus and errorIndex.
Expires January 1998 [Page 14]
Internet-Draft SNMPv3 Applications August 1997
4.3. Notification Originators
A notification originator application generates SNMP notification
messages. A notification message can contain either an SNMPv2-Trap
PDU or an Inform PDU. However, a particular implementation is not
required to be capable of generating both types of messages.
Notification originator applications require a mechanism for
identifying the management targets to which notifications should be
sent. The particular mechanism used is implementation dependent,
however, if an implementation makes the configuration of management
targets SNMP manageable, it MUST use the management target MIB
described in this document.
When a notification originator wishes to generate a notification, it
must first determine in which context the information to be conveyed
in the notification exists, i.e., it must determine the
contextEngineID and contextName. It must then determine the set of
management targets to which the notification should be sent, and the
grouping of these management targets. The application must also
determine, for each group of management targets, whether the
notification message should contain an SNMPv2-Trap PDU or Inform PDU,
and if it is to contain an Inform PDU, the number of retries and
retransmission algorithm.
The mechanism by which a notification originator determines this
information is implementation dependent. Once the application has
determined this information, the following procedure is performed for
each group of management targets:
(1) Any appropriate filtering mechanisms are applied to determine
whether the notification should be sent to the management targets
in this group. If such filtering mechanisms determine that the
notification should not be sent, processing continues with the next
group of management targets. Otherwise,
(2) The appropriate set of variable-bindings is retrieved from local
MIB instrumentation within the relevant MIB view. The relevant MIB
view is determined by the securityLevel, securityModel,
contextName, and securityName of the management target. To
determine whether a particular object instance is within the
relevant MIB view, the isAccessAllowed abstract service interface
is used, in the same manner as described in the preceeding section.
If the statusInformation returned by isAccessAllowed does not
indicate accessAllowed, the notification is not sent to any of the
management targets within this group.
Expires January 1998 [Page 15]
Internet-Draft SNMPv3 Applications August 1997
(3) A PDU is constructed using a locally unique request-id value, an
operation type of Trap or Inform, an error-status and error-index
value of 0, and the variable-bindings supplied previously in step
(2).
(4) If the notification should contain an SNMPv2-Trap PDU for this
group, then for each management target in the group, the Message
Processing Subsystem is called using the following abstract service
interface:
statusInformation = -- sendPduHandle if success
-- errorIndication if failure
sendPdu(
IN transportDomain -- transport domain to be used
IN transportAddress -- destination network address
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
)
Where:
- The transportDomain is that of the management target.
- The transportAddress is that of the management target.
- The messageProcessingModel is that of the management target.
- The securityModel is that of the management target.
- The securityName is that of the management target.
- The securityLevel is that of the management target.
- The contextEngineID is the value originally determined for the
notification.
- The contextName is the value originally determined for the
notification.
Expires January 1998 [Page 16]
Internet-Draft SNMPv3 Applications August 1997
- The pduVersion is the version of the PDU to be sent.
- The PDU is the value constructed in step (3) above.
- The expectResponse argument indicates that no response is
expected.
Otherwise,
(5) If the notification should contain an Inform PDU for this group,
then:
a) For each management target in the group, the Message
Processing Subsystem is called using the sendPdu abstract
service interface as described in step (4) above, except that
the expectResponse arguments indicates that a response is
expected.
b) The application caches information about the management
target group.
c) If a response is received within an appropriate time interval
from any one transport endpoint within the group, the
notification is considered acknowledged for this group, the
cached information is deleted, and any further responses to
this Inform are ignored. Otherwise,
d) If a response is not received within an appropriate time
period, information about the management target group is
retrieved from the cache, and steps a) through d) are
repeated. The number of times these steps are repeated is as
previously determined. If this retry count is exceeded, the
acknowledgement of the notification is considered to have
failed, and processing of the notification for this group of
management targets is halted.
Responses to Inform PDU notifications will be received via the
processResponsePDU abstract service interface.
Expires January 1998 [Page 17]
Internet-Draft SNMPv3 Applications August 1997
4.4. Notification Receivers
Notification receiver applications receive SNMP Notification messages
from the Message Processing Subsystem. Before any messages can be
received, the notification receiver must register with the Message
Processing Subsystem using the registerContextEngineID abstract
service interface. The parameters used are:
- The contextEngineID is an undefined 'wildcard' value.
Notifications are delivered to a registered notification
receiver regardless of the contextEngineID contained in the
notification message.
- The pduType indicates either SNMPv2-Trap PDUs or Inform PDUs,
or both.
Once the notification receiver has registered with the Message
Processing Subsystem, messages are received using the processPdu
abstract service interface. Parameters are:
- The messageProcessingModel indicates which Message Processing
subsystem received and processed the message.
- The securityModel is the value from the received message.
- The securityName is the value from the received message.
- The securityLevel is the value from the received message.
- The contextEngineID is the value from the received message.
- The contextName is the value from the received message.
- The pduVerion indicates the version of the PDU in the received
message.
- The PDU is the value from the received message.
- The maxSizeResponseScopedPDU is the value from the received
message.
- If the message contains an SNMPv2-Trap PDU, the stateReference
is undefined and unused. Otherwise, the stateReference is a
value assigned by the Message Processing Subsystem which
references cached information about the notification. This
value must be returned to the Message Processing Subsystem in
order to generate a response.
Expires January 1998 [Page 18]
Internet-Draft SNMPv3 Applications August 1997
When an SNMPv2-Trap PDU is delivered to a notification receiver
application, it first extracts the SNMP operation type, request-id,
error-status, error-index, and variable-bindings from the PDU. After
this, processing depends on the particular implementation.
When an Inform PDU is received, the notification receiver application
follows the following procedure:
(1) The SNMPv2 operation type, request-id, error-status, error-index,
and variable-bindings are extracted from the PDU.
(2) A Response PDU is constructed using the extracted request-id and
variable-bindings, and with error-status and error-index both set
to 0.
(3) The Message Processing Subsystem is called to generate a response
message using the returnResponsePdu abstract service interface.
Parameters are:
- The messageProcessingModel is the value from the processPdu
call.
- The securityModel is the value from the processPdu call.
- The securityName is the value from the processPdu call.
- The securityLevel is the value from the processPdu call.
- The contextEngineID is the value from the processPdu call.
- The contextName is the value from the processPdu call.
- The pduVersion indicates the version of the PDU to be
returned.
- The PDU is the result generated in step (2) above.
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The stateReference is the value from the processPdu call.
- The statusInformation indicates that no error occured and that
a response should be generated.
Note that there may be multiple notification receiver applications
associated with a particular SNMP engine. Despite this, only a
Expires January 1998 [Page 19]
Internet-Draft SNMPv3 Applications August 1997
single response should be generated when an Inform PDU is received.
The mechanism to ensure this is implementation specific. One
strategy to accomplish this is to simply let the Message Processing
Subsystem delete the stateReference when the first response is
generated. Subsequent attempts to send the response will fail
because the stateReference no longer exists within the Message
Processing Subsystem.
Expires January 1998 [Page 20]
Internet-Draft SNMPv3 Applications August 1997
4.5. Proxy Forwarders
A proxy forwarder application deals with forwarding messages which
contain Get, GetNext, GetBulk, Set, SNMPv2-Trap, Inform, and Response
PDUs. Of these PDU types, the first four (Get, GetNext, GetBulk,
Set) deal with requesting or modifying information located within a
particular context, and the next two (SNMPv2-Trap, Inform) deal with
notifications concerning information located within a particular
context. A proxy forwarder application treats these two situations
slightly different. Forwarding of Response PDUs always occurs as a
result of receiving a response to a previously forwarded message.
In the first situation, the proxy forwarder's role is ultimately to
deliver a request for management information to the SNMP engine which
has access to that information, and to deliver the response
containing the information back to the SNMP engine which initiated
the request. The context information in a request is used to
determine which SNMP engine has access to the requested information,
and this is used to determine where and how to forward the request.
In the second situation, the proxy forwarder's role is to determine
which SNMP engines should receive notification about management
information from a particular location. The context information in a
notification message determines the location to which the information
contained in the notification applies. This is used to determine
which SNMP engines should receive notification about this
information.
When forwarding messages, a proxy forwarder application must perform
a translation of incoming management target information into outgoing
management target information. How this translation is performed is
implementation specific. In many cases, this will be driven by a
preconfigured translation table. If a proxy forwarder application
makes the contents of this table SNMP manageable, it MUST use the MIB
defined in this document.
4.5.1. Request Forwarding
There are two phases for request forwarding. First the incoming
request needs to be passed through the proxy application. Then the
resulting resonse needs to be passed back. These phases are
described in the following two sections.
Expires January 1998 [Page 21]
Internet-Draft SNMPv3 Applications August 1997
4.5.1.1. Processing an Incoming Request
A proxy forwarder application that wishes to forward request messages
must first register with the Message Processing Subsystem using the
registerContextEngineID abstract service interface. The proxy
forwarder must register each contextEngineID for which it wishes to
forward messages, as well as for each pduType. Note that as the
configuration of a proxy forwarder is changed, the particular
contextEngineID values for which it is forwarding may change. The
proxy forwarder should call the registerContextEngineID and
unregisterContextEngineID abstract service interfaces as needed to
reflect its current configuration.
A proxy forwarder application should never attempt to register a
value of contextEngineID which is equal to the snmpEngineID of the
SNMP engine to which the proxy forwarder is associated.
Once the proxy forwarder has registered for the appropriate
contextEngineId values, it can start processing messages. The
following procedure is used:
(1) A message is received using the processPdu abstract service
interface. The incoming management target information received
from the processPdu interface is translated into outgoing
management target information. Note that this translation may vary
for different values of contextEngineID and/or contextName. The
translation should result in a single management target.
(2) If appropriate outgoing management target information cannot be
found, the proxy forwarder increments the snmpProxyDrops counter
[RFC1907], and then calls the Message Processing Subsystem using
the returnResponsePdu abstract service interface. Parameters are:
- The messageProcessingModel is the value from the processPdu
call.
- The securityModel is the value from the processPdu call.
- The securityName is the value from the processPdu call.
- The securityLevel is the value from the processPdu call.
- The contextEngineID is the value from the processPdu call.
- The contextName is the value from the processPdu call.
Expires January 1998 [Page 22]
Internet-Draft SNMPv3 Applications August 1997
- The pduVersion is an undefined value.
- The PDU is an undefined value.
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The stateReference is the value from the processPdu call.
- The statusInformation indicates that an error occured and that
an snmpProxyDrops Report message should be generated.
Processing of the message stops at this point. Otherwise,
(3) A new PDU is constructed. A unique value of request-id should be
used in the new PDU (this value will enable a subsequent response
message to be correlated with this request). The remainder of the
new PDU is identical to the received PDU, unless the incoming SNMP
version is SNMPv1 and the outgoing SNMP version is SNMPv2 or
SNMPv3, or vice-versa, in which case the proxy forwarder must apply
the translation rules as documented in [RFC1908].
(4) The proxy forwarder calls the Message Processing Subsystem to
generate the forwarded message, using the sendPdu abstract service
interface. The parameters are:
- The transportDomain is that of the outgoing management target.
- The transportAddress is that of the outgoing management
target.
- The messageProcessingModel is that of the outgoing management
target.
- The securityModel is that of the outgoing management target.
- The securityName is that of the outgoing management target.
- The securityLevel is that of the outgoing management target.
- The contextEngineID is the value originally received.
- The contextName is the value originally received.
- The pduVersion is the version of the PDU to be sent.
Expires January 1998 [Page 23]
Internet-Draft SNMPv3 Applications August 1997
- The PDU is the value constructed in step (3) above.
- The expectResponse argument indicates that a response is
expected. If the sendPdu call is unsuccessful, the proxy
forwarder performs the steps described in (2) above.
Otherwise:
(5) The proxy forwarder caches the contextEngineId, contextName,
stateReference, incoming management target information, outgoing
management information, and any other information needed to match
an incoming response to the forwarded request. If this information
cannot be cached (possibly due to a lack of resources), the proxy
forwarder performs the steps described in (2) above. Otherwise:
(6) Processing of the request stops until a response to the forwarded
request is received, or until an appropriate time interval has
expired. If this time interval expires before a response has been
received, the cached information about this request is removed, and
the proxy forwarder performs the steps described in (2) above using
the cached information.
4.5.1.2. Processing an Incoming Response
A proxy forwarder follows the following procedure when an incoming
response is received:
(1) The incoming response is received using the processPdu interface.
The proxy forwarder uses the received parameters to locate an entry
in its cache of pending forwarded requests. This is done by
matching the received parameters with the cached values of
contextEngineID, contextName, outgoing management target
information, and the request-id contained in the received PDU (the
proxy forwarder must extract the request-id for this purpose). If
an appropriate cache entry cannot be found, processing of the
response is halted. Otherwise:
(2) The cache information is extracted, and removed from the cache.
(3) If the incoming SNMP version is SNMPv1 and the outgoing SNMP
version is SNMPv2 or SNMPv3, or vice-versa, the proxy forwarder
must apply the translation rules documented in [RFC1908].
(4) The proxy forwarder calls the Message Processing Subsystem using
the returnResponsePdu abstract service interface. Parameters are:
Expires January 1998 [Page 24]
Internet-Draft SNMPv3 Applications August 1997
- The messageProcessingModel indicates the MessageProcessing
subsystem from which the original incoming message was
received.
- The securityModel is that of the original incoming management
target extracted from the cache.
- The securityName is that of the original incoming management
target extracted from the cache.
- The securityLevel is that of the original incoming management
target extracted from the cache.
- The contextEngineID is the value extracted from the cache.
- The contextName is the value extracted from the cache.
- The pduVersion indicates the version of the PDU to be
returned.
- The PDU is the (possibly translated) Response PDU.
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The stateReference is the value extracted from the cache.
- The statusInformation indicates that no error occured and that
a Response PDU message should be generated.
4.5.2. Notification Forwarding
A proxy forwarder receives notifications in the same manner as a
notification receiver application, using the processPdu abstract
service interface. The following procedure is used when a
notification is received:
(1) The incoming management target information received from the
processPdu interface is translated into outgoing management target
information. Note that this translation may vary for different
values of contextEngineId and/or contextName. The translation may
result in one or more management target groups, each of which may
contain multiple management targets.
(2) If appropriate outgoing management target information cannot be
found and the notification was a Trap, processing of the
Expires January 1998 [Page 25]
Internet-Draft SNMPv3 Applications August 1997
notification is halted. If appropriate outgoing management target
information cannot be found and the notification was an Inform, the
proxy forwarder increments the snmpProxyDrops object, and calls the
Message Processing Subsystem using the returnResponsePdu abstract
service interface. The parameters are:
- The messageProcessingModel is the received value.
- The securityModel is the received value.
- The securityName is the received value.
- The securityLevel is the received value.
- The contextEngineID is the received value.
- The contextName is the received value.
- The pduVersion is an undefined and unused value.
- The PDU is an undefined and unused value.
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The stateReference is the received value.
- The statusInformation indicates that an error occured and that
a Report message should be generated.
Processing of the message stops at this point. Otherwise,
(3) The proxy forwarder generates a notification using the procedures
described in the preceeding section on Notification Originators,
with the following exceptions:
- The contextEngineID and contextName values from the original
received notification are used.
- The outgoing management targets previously determined are
used.
- No filtering mechanisms are applied.
- The variable-bindings from the original received notification
are used, rather than retrieving variable-bindings from local
MIB instrumentation. In particular, no access-control is
Expires January 1998 [Page 26]
Internet-Draft SNMPv3 Applications August 1997
applied to these variable-bindings.
- If for any of the outgoing management targets, the incoming
SNMP version is SNMPv1 and the outgoing SNMP version is SNMPv2
or SNMPv3, the proxy forwarder must apply the translation
rules as documented in [RFC1908].
- If for any of the outgoing management targets, the incoming
SNMP version is SNMPv2 or SNMPv3, and the outgoing SNMP
version is SNMPv1, this outgoing management target is not used
when generating the forwarded notifications.
(4) If the original received notification contains an SNMPv2-Trap PDU,
processing of the notification is now completed. Otherwise, the
original received notification must contain an Inform PDU, and
processing continues.
(5) If the forwarded notifications included any Inform PDUs, processing
continues when the procedures described in the section for
Notification Originators determine that either:
- None of the generated notifications containing Inform PDUs
have been successfully acknowledged within the longest of the
time intervals, in which case processing of the original
notification is halted, or,
- At least one of the generated notifications containing Inform
PDUs is successfully acknowledged, in which case a response to
the original received notification containing an Inform PDU is
generated as described in the following steps.
(6) A Response PDU is constructed, using the values of request-id and
variable-bindings from the original received Inform PDU, and
error-status and error-index values of 0.
(7) The Message Processing Subsystem is called using the
returnResponsePdu abstract service interface. Parameters are:
- The messageProcessingModel is the originally received value.
- The securityModel is the originally received value.
- The securityName is the originally received value.
- The securityLevel is the originally received value.
Expires January 1998 [Page 27]
Internet-Draft SNMPv3 Applications August 1997
- The contextEngineID is the originally received value.
- The contextName is the originally received value.
- The pduVersion indicates the version of the PDU constructed in
step (6) above.
- The PDU is the value constructed in step (6) above.
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The stateReference is the originally received value.
- The statusInformation indicates that no error occured and that
a Response PDU message should be generated.
Expires January 1998 [Page 28]
Internet-Draft SNMPv3 Applications August 1997
5. The Structure of the MIBs
There are three separate MIBs described in this document, the
management target MIB, the notification MIB, and the proxy MIB. The
following sections describe the structure of these three MIBs.
5.1. The Management Target MIB
This MIB contains objects for defining management targets. It
consists of one scalar, two tables, and conformance/compliance
statements.
The scalar, snmpTargetAddressSpinLock, is used by managers when
creating new rows in the snmpTargetAddrTable.
The first table, the snmpTargetAddrTable, contains information about
transport domains/addresses. The table is indexed by an
SnmpAdminString type object and an integer type object. This allows
domains/addresses to be organized into groups.
The second table, the snmpTargetTable, contains information about
SNMP version and security information to be used when sending
messages to a particular group of transport domains/addresses.
5.1.1. Definitions
SNMPV3-TARGET-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
OBJECT-IDENTITY,
Integer32
FROM SNMPv2-SMI
TDomain,
TAddress,
TruthValue,
TimeInterval,
RowStatus,
StorageType
FROM SNMPv2-TC
SnmpSecurityModel,
SnmpMessageProcessingModel,
Expires January 1998 [Page 29]
Internet-Draft SNMPv3 Applications August 1997
SnmpSecurityLevel,
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF;
snmpTargetMIB MODULE-IDENTITY
LAST-UPDATED "9707140000Z"
ORGANIZATION "IETF SNMPv3 Working Group"
CONTACT-INFO
"David B. Levi
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
Tel: +1 423 573 1434
E-mail: levi@snmp.com
Paul Meyer
Secure Computing Corporation
2675 Long Lake Road
Roseville, MN 55113
Tel: +1 612 628 1592
E-mail: paul_meyer@securecomputing.com
Bob Stewart
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
Tel: +1 603 654 6923
E-mail: bstewart@cisco.com"
DESCRIPTION
"This MIB module defines a MIB which provides mechanisms to
remotely configure the parameters used by an SNMPv3 entity
for the generation of notifications."
REVISION "9707140000Z"
DESCRIPTION
"The initial revision."
::= { snmpModules 11 } -- TBD
snmpTargetObjects OBJECT IDENTIFIER ::= { snmpTargetMIB 1 }
snmpTargetConformance OBJECT IDENTIFIER ::= { snmpTargetMIB 2 }
-- ------------------------------------------------------------------
--
-- The snmpTargetObjects group
Expires January 1998 [Page 30]
Internet-Draft SNMPv3 Applications August 1997
--
-- ------------------------------------------------------------------
snmpTargetAddressSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to facilitate creation of rows in the
snmpTargetAddrTable. There are two situations where an
SNMP entity may wish to create a new row, when a new group
of addresses must be created, and when an address must be
added to an existing group.
When an SNMP entity wishes to create a new group of
addresses, it should follow the following procedure:
a) Retrieve the value of this object.
b) Retrieve all existing index values of
snmpTargetAddrName (this can be accomplished
by retrieving all instances of any accessible
columnar object in the snmpTargetAddrTable).
c) Retrieve the value of this object. If the value is
not equal to the last retrieved value, go back to
step b).
d) Select a new unique index value for
snmpTargetAddrName, and an arbitrary value for
snmpTargetAddrSubIndex. Attempt a set request
containing these varbinds:
- The last retrieved value of this object.
- An instance of the snmpTargetAddrRowStatus
object whose indices are equal to the selected
index values of snmpTargetAddrName and
snmpTargetAddrSubIndex.
- Additional varbinds for initializing other
columnar objects in the row.
If this set fails, the SNMP entity may return to
step a) and try again.
When an SNMP entity wishes to create a new address within
an existing group of addresses, it should follow the
following procedure:
a) Retrieve all existing values of
snmpTargetAddrSubIndex corresponding to the desired
index value of snmpTargetAddrName. (this can be
accomplished by retrieving all instances of any
accessible columnar object in the
snmpTargetAddrTable whose index begins with the
Expires January 1998 [Page 31]
Internet-Draft SNMPv3 Applications August 1997
desired index value of snmpTargetAddrName).
b) Select a new value for snmpTargetAddrSubIndex.
Attempt a set request containing these varbinds:
- An instance of the snmpTargetAddrRowStatus
object whose indices are equal to the desired
index value of snmpTargetAddrName and the
selected index value of snmpTargetAddrSubIndex.
- Additional varbinds for initializing other
columnar objects in the row.
If this set fails, the SNMP entity may return to
step a) and try again."
::= { snmpTargetObjects 1 }
snmpTargetAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3TargetAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of transport addresses to be used in the generation
of SNMP messages. Addresses are organized into groups.
Every member of a group shares a common snmpTargetAddrName."
::= { snmpTargetObjects 2 }
snmpTargetAddrEntry OBJECT-TYPE
SYNTAX SnmpV3TargetAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A transport address to be used in the generation
of SNMP operations."
INDEX { snmpTargetAddrName, snmpTargetAddrSubIndex }
::= { snmpTargetAddrTable 1 }
SnmpV3TargetAddrEntry ::= SEQUENCE {
snmpTargetAddrSubIndex Integer32,
snmpTargetAddrTDomain TDomain,
snmpTargetAddrTAddress TAddress,
snmpTargetAddrTimeout TimeInterval,
snmpTargetAddrStorageType StorageType,
snmpTargetAddrRowStatus RowStatus
}
snmpTargetAddrSubIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Expires January 1998 [Page 32]
Internet-Draft SNMPv3 Applications August 1997
"The locally arbitrary, but unique identifier associated
an snmpTargetAddrEntry within a group of entries in the
snmpTargetAddrTable."
::= { snmpTargetAddrEntry 1 }
snmpTargetAddrTDomain OBJECT-TYPE
SYNTAX TDomain
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the transport type of the address
contained in the snmpTargetAddrTAddress object."
::= { snmpTargetAddrEntry 2 }
snmpTargetAddrTAddress OBJECT-TYPE
SYNTAX TAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object contains a transport address. The format of
this address depends on the value of the
snmpTargetAddrTDomain object."
::= { snmpTargetAddrEntry 3 }
snmpTargetAddrTimeout OBJECT-TYPE
SYNTAX TimeInterval
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object should reflect the expected round trip time
for communicating with the transport address defined by
this row. When a message is sent to this address, and
a response (if one is expected) is not received within
this time period, an implementation may assume that the
response will not be delivered.
Note that the time interval that an application waits
for a response may actually be derived from the value
of this object. The method for deriving the actual time
interval is implementation dependent. One such method
is to derive the expected round trip time based on a
particular retransmission algorithm and on the number
of timeouts which have occured. The type of message may
also be considered when deriving expected round trip
times for retransmissions. For example, if a message is
being sent with a securityLevel that indicates both
authentication and privacy, the derived value may be
Expires January 1998 [Page 33]
Internet-Draft SNMPv3 Applications August 1997
increased to compensate for extra processing time spent
during authentication and encryption processing."
DEFVAL { 1500 }
::= { snmpTargetAddrEntry 4 }
snmpTargetAddrStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row."
::= { snmpTargetAddrEntry 5 }
snmpTargetAddrRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row.
Until instances of all corresponding columns are
appropriately configured, the value of the
corresponding instance of the snmpTargetAddrRowStatus
column is 'notReady'.
In particular, a newly created row cannot be made
active until the corresponding snmpTargetAddrTDomain
and snmpTargetAddrTAddress have both been set."
::= { snmpTargetAddrEntry 6 }
snmpTargetTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3TargetEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of management target information to be used
in the generation of SNMP messages."
::= { snmpTargetObjects 3 }
snmpTargetEntry OBJECT-TYPE
SYNTAX SnmpV3TargetEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A set of management target information."
INDEX { snmpTargetName }
::= { snmpTargetTable 1 }
Expires January 1998 [Page 34]
Internet-Draft SNMPv3 Applications August 1997
SnmpV3TargetEntry ::= SEQUENCE {
snmpTargetName SnmpAdminString,
snmpTargetAddrName SnmpAdminString,
snmpTargetMessageProcessingModel SnmpMessageProcessingModel,
snmpTargetSecurityModel SnmpSecurityModel,
snmpTargetSecurityName SnmpAdminString,
snmpTargetSecurityLevel SnmpSecurityLevel,
snmpTargetRetryCount Integer32,
snmpTargetStorageType StorageType,
snmpTargetRowStatus RowStatus
}
snmpTargetName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The locally arbitrary, but unique identifier associated
with this snmpTargetEntry."
::= { snmpTargetEntry 1 }
snmpTargetAddrName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The group of addresses to which management operations will
be sent when using this set of security parameters. The
value of this object refers to a group of addresses
in the snmpTargetAddrTable."
::= { snmpTargetEntry 2 }
snmpTargetMessageProcessingModel OBJECT-TYPE
SYNTAX SnmpMessageProcessingModel
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Message Processing Model to be used when generating
SNMP messages using this entry."
::= { snmpTargetEntry 3 }
snmpTargetSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Security Model to be used when generating SNMP
Expires January 1998 [Page 35]
Internet-Draft SNMPv3 Applications August 1997
messages using this entry."
::= { snmpTargetEntry 4 }
snmpTargetSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The securityName which identifies the Principal on
whose behalf SNMP messages will be generated using
this entry."
::= { snmpTargetEntry 5 }
snmpTargetSecurityLevel OBJECT-TYPE
SYNTAX SnmpSecurityLevel
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Level of Security to be used when generating
SNMP messages using this entry."
::= { snmpTargetEntry 6 }
snmpTargetRetryCount OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a default number of retries to be
attempted when a response is not received for a generated
message. The number of retries is an indication of how
important delivery of a particular message is considered.
An application may provide its own retry count, in which
case the value of this object is ignored."
DEFVAL { 3 }
::= { snmpTargetEntry 7 }
snmpTargetStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row."
::= { snmpTargetEntry 8 }
snmpTargetRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
Expires January 1998 [Page 36]
Internet-Draft SNMPv3 Applications August 1997
STATUS current
DESCRIPTION
"The status of this conceptual row.
Until instances of all corresponding columns are
appropriately configured, the value of the
corresponding instance of the snmpTargetRowStatus
column is 'notReady'.
In particular, a newly created row cannot be made
active until the corresponding
snmpTargetMessageProcessingModel,
snmpTargetSecurityModel, snmpTargetSecurityName,
and snmpTargetSecurityLevel have all been set."
::= { snmpTargetEntry 9 }
snmpTargetDefaultRetryAlgorithm OBJECT-TYPE
SYNTAX INTEGER {
constant(1),
linearBackOff(2),
exponentialBackOff(3),
randomBackOff(4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a default algorithm to be used
when adjusting timeout times when retransmitting a
request whose response was not received in a timely
manner. An application may provide its own
retransmission algorithm, in which case the value of
this object is ignored.
Can we really predict all the algorithms that people might want to use?
There are alternatives to making this be an enumerated integer.
One alternative is to make it be a set of 6 parameters for a quadratic
equation which would be used to recalculate retry intervals, i.e.,:
interval(n) = ((A1 / A2) * interval(n-1) * interval(n-1)) +
((B1 / B2) * interval(n-1)) +
(C1 / C2)
The advantage to this is that a manager can define a wide range of
algorithms, and the agent does not need to support a specific set
of algorithms.
Another alternative is to identify retransmission algorithms by OID rather
Expires January 1998 [Page 37]
Internet-Draft SNMPv3 Applications August 1997
than by integer. The advantage to using OIDs is that we can define
additional algorithms later. If we do this, we can either make this object
be an OID, or we can have a table that maps the OIDs to integers, and have
the value of this object point at one of the entries in the mapping table.
The advantage to a mapping table is that it allows a manager to discover
what algorithms an agent supports.
"
::= { snmpTargetObjects 4 }
-- ------------------------------------------------------------------
--
-- Conformance information
--
-- ------------------------------------------------------------------
snmpTargetCompliances OBJECT IDENTIFIER ::=
{ snmpTargetConformance 1 }
snmpTargetGroups OBJECT IDENTIFIER ::=
{ snmpTargetConformance 2 }
-- ------------------------------------------------------------------
--
-- Compliance statements
--
-- ------------------------------------------------------------------
snmpTargetBasicGroup OBJECT-GROUP
OBJECTS {
snmpTargetAddressSpinLock,
snmpTargetAddrTDomain,
snmpTargetAddrTAddress,
snmpTargetAddrStorageType,
snmpTargetAddrRowStatus,
snmpTargetAddrName,
snmpTargetMessageProcessingModel,
snmpTargetSecurityModel,
snmpTargetSecurityName,
snmpTargetSecurityLevel,
snmpTargetStorageType,
snmpTargetRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing basic remote
configuration of management targets."
::= { snmpTargetGroups 1 }
Expires January 1998 [Page 38]
Internet-Draft SNMPv3 Applications August 1997
snmpTargetResponseGroup OBJECT-GROUP
OBJECTS {
snmpTargetAddrTimeout,
snmpTargetRetryCount,
snmpTargetDefaultRetryAlgorithm
}
STATUS current
DESCRIPTION
"A collection of objects providing remote configuration
of management targets for applications which generate
SNMP messages for which a response message would be
expected."
::= { snmpTargetGroups 2 }
END
Expires January 1998 [Page 39]
Internet-Draft SNMPv3 Applications August 1997
5.2. The Notification MIB
This MIB contains three tables. The first table, the
snmpNotifyTargetTable, simply augments the snmpTargetTable with a
single object which is used to determine whether a particular
management target should be used for generating notifications, and
the type of notification to be generated. The second table sparsely
augments the snmpNotifyTargetTable with a single object. This object
is used to associate a set of filters with a particular management
target. The third table defines filters which are used to limit the
number of notifications which are generated using particular
management targets.
5.2.1. Definitions
SNMPV3-NOTIFICATION-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
OBJECT-IDENTITY,
Integer32
FROM SNMPv2-SMI
TDomain,
TAddress,
TruthValue,
TimeInterval,
RowStatus,
StorageType
FROM SNMPv2-TC
SnmpSecurityModel,
SnmpSecurityLevel,
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
snmpTargetEntry,
snmpTargetName
FROM SNMPV3-TARGET-MIB
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF;
snmpNotificationMIB MODULE-IDENTITY
Expires January 1998 [Page 40]
Internet-Draft SNMPv3 Applications August 1997
LAST-UPDATED "9707140000Z"
ORGANIZATION "IETF SNMPv3 Working Group"
CONTACT-INFO
"David B. Levi
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
Tel: +1 423 573 1434
E-mail: levi@snmp.com
Paul Meyer
Secure Computing Corporation
2675 Long Lake Road
Roseville, MN 55113
Tel: +1 612 628 1592
E-mail: paul_meyer@securecomputing.com
Bob Stewart
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
Tel: +1 603 654 6923
E-mail: bstewart@cisco.com"
DESCRIPTION
"This MIB module defines a MIB which provides mechanisms
to remotely configure management targets used by an
SNMPv3 entity."
REVISION "9707140000Z"
DESCRIPTION
"The initial revision."
::= { snmpModules 12 } -- TBD
snmpNotifyObjects OBJECT IDENTIFIER ::=
{ snmpNotificationMIB 1 }
snmpNotifyConformance OBJECT IDENTIFIER ::=
{ snmpNotificationMIB 2 }
-- ------------------------------------------------------------------
--
-- The snmpNotifyObjects group
--
-- ------------------------------------------------------------------
snmpNotifyTargetTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3NotifyTargetEntry
MAX-ACCESS not-accessible
STATUS current
Expires January 1998 [Page 41]
Internet-Draft SNMPv3 Applications August 1997
DESCRIPTION
"This table is used to select management targets which should
receive notifications, as well as the type of notification
which should be sent to each selected management target."
::= { snmpNotifyObjects 1 }
snmpNotifyTargetEntry OBJECT-TYPE
SYNTAX SnmpV3NotifyTargetEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table determines whether the corresponding
entry in the snmpTargetTable should be used when generating
notifications."
AUGMENTS { snmpTargetEntry }
::= { snmpNotifyTargetTable 1 }
SnmpV3NotifyTargetEntry ::= SEQUENCE {
snmpNotifyTargetType INTEGER
}
snmpNotifyTargetType OBJECT-TYPE
SYNTAX INTEGER {
trap(1),
inform(2),
nothing(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object determines whether a particular entry in
the snmpTargetTable should be used when generating
notifications. It also determines the type of
notifications generated using a particular entry.
If the value of this object is trap(1),
then the entry will be used to generate messages
containing SNMPv2-Trap PDUs. If the value is
inform(2), then the entry will be used to generate
messages containing Inform PDUs. If the value is
nothing(3), then the entry is not used to generate
notifications.
Note that the default value for this object is
nothing(3). This ensures that if an entry is created
for a purpose other than notification generation,
whoever creates the row need not do anything special
to prevent the use of the entry when generating
Expires January 1998 [Page 42]
Internet-Draft SNMPv3 Applications August 1997
notifications.
Also note that if an SNMP entity only supports
generation of traps (and not informs), then this
object need not be supported, and its value is
assumed to be trap(1)."
DEFVAL { nothing }
::= { snmpNotifyTargetEntry 1 }
snmpNotifyFilterProfileTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3NotifyFilterProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is used to select management targets which
should receive notifications, as well as the type of
notification which should be sent to each selected
management target."
::= { snmpNotifyObjects 2 }
snmpNotifyFilterProfileEntry OBJECT-TYPE
SYNTAX SnmpV3NotifyFilterProfileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table indicates the name of the filter
profile to be used when generating notifications using
the corresponding entry in the snmpTargetTable."
INDEX { snmpTargetName }
::= { snmpNotifyFilterProfileTable 1 }
SnmpV3NotifyFilterProfileEntry ::= SEQUENCE {
snmpNotifyFilterProfileName SnmpAdminString
snmpNotifyFilterProfileStorageType StorageType
snmpNotifyFilterProfileRowStatus RowStatus
}
snmpNotifyFilterProfileName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The name of the filter profile to be used when generating
notifications using the corresponding entry in the
snmpTargetTable."
::= { snmpNotifyFilterProfileEntry 1 }
Expires January 1998 [Page 43]
Internet-Draft SNMPv3 Applications August 1997
snmpNotifyFilterProfileStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type of this conceptual row."
::= { snmpNotifyFilterProfileEntry 2 }
snmpNotifyFilterProfileRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row."
::= { snmpNotifyFilterProfileEntry 3 }
snmpNotifyFilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3NotifyFilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of filter profiles. Filter profiles are used
to determine whether particular management targets should
receive particular notifications.
When a notification is generated, it must be compared
with the filters associated with each management target
which is configured to receive notifications. If the
notification is matched by a filter, it is not sent to
the management target with which the filter is
associated."
::= { snmpNotifyObjects 3 }
snmpNotifyFilterEntry OBJECT-TYPE
SYNTAX SnmpV3NotifyFilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An element of a filter profile."
INDEX { snmpNotifyFilterProfileName,
IMPLIED snmpNotifyFilterSubtree }
::= { snmpNotifyFilterTable 1 }
SnmpV3NotifyFilterEntry ::= SEQUENCE {
snmpNotifyFilterSubtree OBJECT IDENTIFIER,
snmpNotifyFilterMask OCTET STRING,
snmpNotifyFilterType INTEGER,
Expires January 1998 [Page 44]
Internet-Draft SNMPv3 Applications August 1997
snmpNotifyFilterStorageType StorageType,
snmpNotifyFilterRowStatus RowStatus
}
snmpNotifyFilterSubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The MIB subtree which, when combined with the corresponding
instance of snmpNotifyFilterMask, defines a family of
subtrees which are included in or excluded from the
filter profile."
::= { snmpNotifyFilterEntry 1 }
snmpNotifyFilterMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The bit mask which, in combination with the corresponding
instance of snmpNotifyFilterSubtree, defines a family of
subtrees which are included in or excluded from the
filter profile.
Each bit of this bit mask corresponds to a
sub-identifier of snmpNotifyFilterSubtree, with the
most significant bit of the i-th octet of this octet
string value (extended if necessary, see below)
corresponding to the (8*i - 7)-th sub-identifier, and
the least significant bit of the i-th octet of this
octet string corresponding to the (8*i)-th
sub-identifier, where i is in the range 1 through 16.
Each bit of this bit mask specifies whether or not
the corresponding sub-identifiers must match when
determining if an OBJECT IDENTIFIER matches this
family of filter subtrees; a '1' indicates that an
exact match must occur; a '0' indicates 'wild card',
i.e., any sub-identifier value matches.
Thus, the OBJECT IDENTIFIER X of an object instance
is contained in a family of filter subtrees if, for
each sub-identifier of the value of
snmpNotifyFilterSubtree, either:
the i-th bit of snmpNotifyFilterMask is 0, or
Expires January 1998 [Page 45]
Internet-Draft SNMPv3 Applications August 1997
the i-th sub-identifier of X is equal to the i-th
sub-identifier of the value of
snmpNotifyFilterSubtree.
If the value of this bit mask is M bits long and
there are more than M sub-identifiers in the
corresponding instance of snmpNotifyFilterSubtree,
then the bit mask is extended with 1's to be the
required length.
Note that when the value of this object is the
zero-length string, this extension rule results in
a mask of all-1's being used (i.e., no 'wild card'),
and the family of filter subtrees is the one
subtree uniquely identified by the corresponding
instance of snmpNotifyFilterSubtree."
DEFVAL { ''H }
::= { snmpNotifyFilterEntry 2 }
snmpNotifyFilterType OBJECT-TYPE
SYNTAX INTEGER {
included(1),
excluded(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates whether the family of filter subtrees
defined by this entry are included in or excluded from a
filter."
DEFVAL { included }
::= { snmpNotifyFilterEntry 3 }
snmpNotifyFilterStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type of this conceptual row."
::= { snmpNotifyFilterEntry 4 }
snmpNotifyFilterRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row."
Expires January 1998 [Page 46]
Internet-Draft SNMPv3 Applications August 1997
::= { snmpNotifyFilterEntry 5 }
-- ------------------------------------------------------------------
--
-- Conformance information
--
-- ------------------------------------------------------------------
snmpNotifyCompliances OBJECT IDENTIFIER ::=
{ snmpNotifyConformance 1 }
snmpNotifyGroups OBJECT IDENTIFIER ::=
{ snmpNotifyConformance 2 }
-- ------------------------------------------------------------------
--
-- Compliance statements
--
-- ------------------------------------------------------------------
snmpNotifyBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for minimal SNMP entities which
implement only SNMP Traps and read-create operations on
only the snmpTargetAddrTable."
MODULE SNMPV3-TARGET-MIB
MANDATORY-GROUPS { snmpTargetBasicGroup }
OBJECT snmpTargetAddrName
MIN-ACCESS read-only
DESCRIPTION
"Read-write and read-create access are not required."
OBJECT snmpTargetMessageProcessingModel
MIN-ACCESS read-only
DESCRIPTION
"Read-write and read-create access are not required."
OBJECT snmpTargetSecurityModel
MIN-ACCESS read-only
DESCRIPTION
"Read-write and read-create access are not required."
OBJECT snmpTargetSecurityName
MIN-ACCESS read-only
DESCRIPTION
"Read-write and read-create access are not required."
Expires January 1998 [Page 47]
Internet-Draft SNMPv3 Applications August 1997
OBJECT snmpTargetSecurityLevel
MIN-ACCESS read-only
DESCRIPTION
"Read-write and read-create access are not required."
OBJECT snmpTargetStorageType
SYNTAX INTEGER {
readOnly(5)
}
MIN-ACCESS read-only
DESCRIPTION
"Read-write and read-create access are not required.
Support of the values other(1), volatile(2),
nonVolatile(3), and permanent(4) is not required."
OBJECT snmpTargetRowStatus
SYNTAX INTEGER {
active(1)
}
MIN-ACCESS read-only
DESCRIPTION
"Read-write and read-create access are not required.
Support of the values notInService(2), notReady(3),
createAndGo(4), createAndWait(5), and destroy(6) is
not required."
::= { snmpNotifyCompliances 1 }
snmpNotifyBasicWithFiltersCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
SNMP Traps with filtering, and read-create operations on
all related tables."
MODULE SNMPV3-TARGET-MIB
MANDATORY-GROUPS { snmpTargetBasicGroup }
MODULE -- This Module
MANDATORY-GROUPS { snmpNotifyFilterGroup }
::= { snmpNotifyCompliances 2 }
snmpNotifyFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which either
implement only SNMP Informs, or both SNMP Traps and SNMP
Informs, plus filtering and read-create operations on
all related tables."
Expires January 1998 [Page 48]
Internet-Draft SNMPv3 Applications August 1997
MODULE SNMPV3-TARGET-MIB
MANDATORY-GROUPS { snmpTargetBasicGroup,
snmpTargetResponseGroup }
MODULE -- This Module
MANDATORY-GROUPS { snmpNotifyTypeGroup,
snmpNotifyFilterGroup }
::= { snmpNotifyCompliances 3 }
snmpNotifyTypeGroup OBJECT-GROUP
OBJECTS {
snmpNotifyTargetType
}
STATUS current
DESCRIPTION
"An object for selecting which management targets are used
for generating notifications, and the type of notification
to be generated for each selected management target."
::= { snmpNotifyGroups 1 }
snmpNotifyFilterGroup OBJECT-GROUP
OBJECTS {
snmpNotifyFilterProfileName,
snmpNotifyFilterMask,
snmpNotifyFilterType,
snmpNotifyFilterStorageType,
snmpNotifyFilterRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing remote configuration of
management targets, including row creation in the
snmpTargetTable."
::= { snmpNotifyGroups 3 }
END
Expires January 1998 [Page 49]
Internet-Draft SNMPv3 Applications August 1997
5.3. The Proxy MIB
The MIB contains a single scalar and a single table. The scalar
object, snmpProxyNextIndex, is used by managers when creating new
entries in the table. The table, snmpProxyTable, is used to define
translations between management targets for use when forwarding
messages.
5.3.1. Definitions
SNMPV3-PROXY-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
OBJECT-IDENTITY,
Integer32
FROM SNMPv2-SMI
TDomain,
TAddress,
TruthValue,
TimeInterval,
RowStatus,
StorageType
FROM SNMPv2-TC
SnmpEngineID,
SnmpSecurityModel,
SnmpSecurityLevel,
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF;
snmpProxyMIB MODULE-IDENTITY
LAST-UPDATED "9706140000Z"
ORGANIZATION "IETF SNMPv3 Working Group"
CONTACT-INFO
"David B. Levi
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
Tel: +1 423 573 1434
Expires January 1998 [Page 50]
Internet-Draft SNMPv3 Applications August 1997
E-mail: levi@snmp.com
Paul Meyer
Secure Computing Corporation
2675 Long Lake Road
Roseville, MN 55113
Tel: +1 612 628 1592
E-mail: paul_meyer@securecomputing.com
Bob Stewart
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
Tel: +1 603 654 6923
E-mail: bstewart@cisco.com"
DESCRIPTION
"This MIB module defines a MIB which provides mechanisms to
remotely configure the parameters used by an SNMPv3 entity
for the generation of notifications."
REVISION "9707140000Z"
DESCRIPTION
"The initial revision."
::= { snmpModules 13 } -- TBD
snmpProxyObjects OBJECT IDENTIFIER ::= { snmpProxyMIB 1 }
snmpProxyConformance OBJECT IDENTIFIER ::= { snmpProxyMIB 2 }
-- ------------------------------------------------------------------
--
-- The snmpProxyObjects group
--
-- ------------------------------------------------------------------
snmpProxyNextIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to facilitate creation of rows in the
snmpProxyTable. Its value when read is equal to an unused
value of snmpProxyIndex. When a manager wishes to create
a row in the snmpProxyTable, it should first retrieve the
value of this object, and then set the instance of
snmpProxyRowStatus whose snmpProxyIndex value is
equal to the retrieved value to either createAndWait or
createAndGo."
::= { snmpProxyObjects 1 }
Expires January 1998 [Page 51]
Internet-Draft SNMPv3 Applications August 1997
snmpProxyTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3ProxyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of translation parameters used by proxy forwarder
applications for forwarding SNMP messages."
::= { snmpProxyObjects 2 }
snmpProxyEntry OBJECT-TYPE
SYNTAX SnmpV3ProxyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A set of translation parameters used by a proxy forwarder
application for forwarding SNMP messages."
INDEX { snmpProxyIndex }
::= { snmpProxyTable 1 }
SnmpV3ProxyEntry ::= SEQUENCE {
snmpProxyIndex Integer32,
snmpProxyType INTEGER,
snmpProxyContextEngineID SnmpEngineID,
snmpProxyContextName SnmpAdminString,
snmpProxyTargetIn SnmpAdminString,
snmpProxyTargetOut SnmpAdminString,
snmpProxyStorageType StorageType,
snmpProxyRowStatus RowStatus
}
snmpProxyIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The locally arbitrary, but unique identifier associated
with this snmpProxyEntry."
::= { snmpProxyEntry 1 }
snmpProxyType OBJECT-TYPE
SYNTAX INTEGER {
read(1),
write(2),
trap(3),
inform(4)
}
MAX-ACCESS not-accessible
Expires January 1998 [Page 52]
Internet-Draft SNMPv3 Applications August 1997
STATUS current
DESCRIPTION
"The type of message that may be forwarded using
the translation parameters defined by this entry."
::= { snmpProxyEntry 2 }
snmpProxyContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contextEngineID contained in messages that
may be forwarded using the translation parameters
defined by this entry."
::= { snmpProxyEntry 3 }
snmpProxyContextName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contextName contained in messages that may be
forwarded using the translation parameters defined
by this entry."
::= { snmpProxyEntry 4 }
snmpProxyTargetIn OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object selects a set of management targets defined
in the snmpTargetTable (in the SNMPV3-TARGET-MIB)."
::= { snmpProxyEntry 5 }
snmpProxyTargetOut OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object selects a management target defined in the
snmpTargetTable (in the SNMPV3-TARGET-MIB). Only the
first transport address/domain as selected by the
snmpTargetAddrName object is identified by
snmpProxyTargetOut (i.e. the lexicographically smallest
instance in the snmpTargetAddrTable whose
snmpTargetAddrName is equal to the snmpTargetAddrName
Expires January 1998 [Page 53]
Internet-Draft SNMPv3 Applications August 1997
object is used for proxy forwarding)."
::= { snmpProxyEntry 6 }
snmpProxyStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type of this conceptual row."
::= { snmpProxyEntry 7 }
snmpProxyRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row."
::= { snmpProxyEntry 8 }
-- ------------------------------------------------------------------
--
-- Conformance information
--
-- ------------------------------------------------------------------
snmpProxyCompliances OBJECT IDENTIFIER ::=
{ snmpProxyConformance 1 }
snmpProxyGroups OBJECT IDENTIFIER ::=
{ snmpProxyConformance 2 }
-- ------------------------------------------------------------------
--
-- Compliance statements
--
-- ------------------------------------------------------------------
snmpProxyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which include
a proxy forwarding application."
MODULE SNMPV3-TARGET-MIB
MANDATORY-GROUPS { snmpTargetBasicGroup,
snmpTargetResponseGroup }
MODULE -- This Module
MANDATORY-GROUPS { snmpProxyGroup }
::= { snmpProxyCompliances 1 }
Expires January 1998 [Page 54]
Internet-Draft SNMPv3 Applications August 1997
snmpProxyGroup OBJECT-GROUP
OBJECTS {
snmpProxyNextIndex,
snmpProxyType,
snmpProxyContextEngineID,
snmpProxyContextName,
snmpProxyTargetIn,
snmpProxyTargetOut,
snmpProxyStorageType,
snmpProxyRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing remote configuration of
management target translation parameters for use by
proxy forwarder applications."
::= { snmpProxyGroups 3 }
END
Expires January 1998 [Page 55]
Internet-Draft SNMPv3 Applications August 1997
6. Identification of Management Targets in Notification Originators
This section describes the mechanisms used by a notification
originator application when using the MIB described in this document
to determine the set of management targets to be used when generating
a notification.
A notification originator uses the snmpTargetTable to find the groups
of management targets to be used for generating notifications. Each
active entry in this table, for which the corresponding value of
snmpNotifyTargetType is trap(1) or inform(2), identifies a group of
management targets to be used for notification generation. Note that
if an SNMP Entity's only use of the snmpTargetTable is for generation
of messages containing SNMPv2-Trap PDUs, the snmpNotifyTargetType
object is not required to be implemented. In this case, the value of
snmpNotifyTargetType is always assumed to be trap(1).
Each such entry contains a pointer to the snmpTargetAddrTable
(snmpTargetAddrName). This pointer identifies zero or more transport
endpoints, defined in the snmpTargetAddrTable. If there are zero
transport endpoints identified, the group of management targets is
empty, and should be ignored. Otherwise, each transport endpoint,
paired with the SNMP information from the snmpTargetTable, identifies
a single management target within the group.
The decision as to whether a notification should contain an SNMPv2-
Trap or Inform PDU is determined by the value of the
snmpNotifyTargetType object. If the value of this object is trap(1),
the notification should contain an SNMPv2-Trap PDU. If the value of
this object is inform(2), then the notification should contain an
Inform PDU, and the number of retries for the Inform is the value of
snmpTargetRetryCount. Note that the exception to these rules is when
the snmpTargetMessageProcessingModel object indicates SNMPv1. In
this case, the notification is sent as a Trap if the value of
snmpNotifyTargetType is either trap(1) or inform(2).
Expires January 1998 [Page 56]
Internet-Draft SNMPv3 Applications August 1997
7. Notification Filtering
This section describes the mechanisms used by a notification
originator application when using the MIB described in this document
to filter generation of notifications.
A notification originator uses the snmpNotifyFilterTable to filter
notifications. A notification filter profile may be associated with
a group of management targets identified by a particular entry in the
snmpTargetTable. The associated filter profile is identified by an
entry in the snmpNotifyFilterProfileTable whose index is equal to the
index of the entry in the snmpTargetTable. If no such entry exists
in the snmpNotifyFilterProfileTable, no filtering is performed for
that group of management targets.
If such an entry does exist, the value of snmpNotifyFilterProfileName
of the entry is compared with the corresponding portion of the index
of all active entries in the snmpNotifyFilterTable. All such entries
for which this comparison results in an exact match are used for
filtering the notification. If no such entries exist, no filtering
is performed, and the notification may be sent to all management
targets in the group.
Otherwise, if matching entries do exist, the notification may be sent
if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
is the value of the element of the variable bindings whose name is
snmpTrapOID.0, i.e. the second variable binding), and all of the
object instances to be included in the variable-bindings of the
notification, are not specifically excluded by the matching entries.
Each set of snmpNotifyFilterTable entries is divided into two
collections of filter subtrees: the included filter subtrees, and
the excluded filter subtrees. The snmpNotifyFilterType object
defines the collection to which each matching entry belongs.
To determine whether a particular notification name or object
instance is excluded by the set of matching entries, compare the
notification name's or object instance's OBJECT IDENTIFIER with each
of the matching entries. If none match, then the notification name
or object instance is considered excluded, and the notification
should not be sent to this group of management targets. If one or
more match, then the notification name or object instance is included
or excluded, according to the value of snmpNotifyFilterType in the
entry whose value of snmpNotifyFilterSubtree has the most sub-
identifiers. If multiple entries match and have the same number of
sub-identifiers, then the lexicographically greatest instance of
snmpNotifyFilterType among those which match determines the inclusion
Expires January 1998 [Page 57]
Internet-Draft SNMPv3 Applications August 1997
or exclusion.
A notification name's or object instance's OBJECT IDENTIFIER X
matches an entry in the snmpNotifyFilterTable when the number of
sub-identifiers in X is at least as many as in the value of
snmpNotifyFilterSubtree for the entry, and each sub-identifier in the
value of snmpNotifyFilterSubtree matches its corresponding sub-
identifier in X. Two sub-identifiers match either if the
corresponding bit of snmpNotifyFilterMask is zero (the 'wild card'
value), or if the two sub-identifiers are equal.
Expires January 1998 [Page 58]
Internet-Draft SNMPv3 Applications August 1997
8. Management Target Translation in Proxy Forwarder Applications
This section describes the mechanisms used by a proxy forwarder
application when using the MIB described in this document to
translate incoming management target information into outgoing
management target information for the purpose of forwarding messages.
There are actually two mechanisms a proxy forwarder may use, one for
forwarding request messages, and one for forwarding notification
messages.
8.1. Management Target Translation for Request Forwarding
When forwarding request messages, the proxy forwarder will select a
single entry in the snmpProxyTable. To select this entry, it will
perform the following comparisons:
- The snmpProxyType must be read(1) if the request is a Get,
GetNext, or GetBulk request. The snmpProxyType must be
write(2) if the request is a Set request.
- The contextEngineId and contextName must equal the
snmpProxyContextEngineID and snmpProxyContextName objects.
- The snmpProxyTargetIn object identifies an entry in the
snmpTargetTable. The snmp version, securityLevel, security
model, and securityName must match the values of
snmpTargetMessageProcessingModel, snmpTargetSecurityModel,
snmpTargetSecurityName, and snmpTargetSecurityLevel of the
identified entry in the snmpTargetTable.
- The identified entry in the snmpTargetTable contains a pointer
to the snmpTargetAddrTable. This pointer refers to zero or
more entries in the snmpTargetAddrTable. If there are no such
entries, this comparison need not succeed. If there is at
least one such entry, the transport domain and address from
which the request was received must match the
snmpTargetAddrTDomain and snmpTargetAddrTAddress values of at
least one of these entries.
There may be multiple entries in the snmpProxyTable for which these
comparisons succeed. The entry whose snmpProxyIndex has the smallest
value and for which the comparisons succeed will be selected by the
proxy forwarder.
The outgoing management information is identified by the value of the
snmpProxyTargetOut object of the selected entry. This object
Expires January 1998 [Page 59]
Internet-Draft SNMPv3 Applications August 1997
identifies an entry in the snmpTargetTable. The
snmpTargetMessageProcessingModel, snmpTargetSecurityModel,
snmpTargetSecurityName, and snmpTargetSecurityLevel of this entry are
used as one part of the management target. The other part of the
management target is a transport endpoint, which is identified by the
value of the snmpTargetAddrName member of the snmpTargetTable entry.
This value may identify zero or more entries in the
snmpTargetAddrTable. If there are no entries identified, the
selected snmpProxyTable entry is invalid, and the proxy forwarder
should look for another snmpProxyTable entry to use. Otherwise, the
snmpTargetAddrTable entry with the smallest value of
snmpTargetAddrSubIndex is used as the transport endpoint.
8.2. Management Target Translation for Notification Forwarding
When forwarding notification messages, the proxy forwarder will
select multiple entries in the snmpProxyTable. To select these
entries, it will perform the following comparisons:
- The snmpProxyType must be trap(3) if the notification is a
Trap. The snmpProxyType must be inform(4) if the request is
an Inform.
- The contextEngineId and contextName must equal the
snmpProxyContextEngineID and snmpProxyContextName objects.
- The snmpProxyTargetIn object identifies an entry in the
snmpTargetTable. The snmp version, securityLevel, security
model, and securityName must match the values of
snmpTargetMessageProcessingModel, snmpTargetSecurityModel,
snmpTargetSecurityName, and snmpTargetSecurityLevel of the
identified entry in the snmpTargetTable.
- The identified entry in the snmpTargetTable contains a pointer
to the snmpTargetAddrTable. This pointer refers to zero or
more entries in the snmpTargetAddrTable. If there are no such
entries, this comparison need not succeed. If there is at
least one such entry, the transport domain and address from
which the request was received must match the
snmpTargetAddrTDomain and snmpTargetAddrTAddress values of at
least one of these entries.
All entries for which these comparisons succeed are selected. The
set of outgoing management targets to be used for generating
forwarded notifications is identified by the value of the
snmpProxyTargetOut object of all selected entries. These values
Expires January 1998 [Page 60]
Internet-Draft SNMPv3 Applications August 1997
identify entries in the snmpTargetTable. All such entries are used
for generating forwarded notifications. The snmpTargetNotification
object is ignored when generating forwarded notifications in a proxy
forwarder application.
Expires January 1998 [Page 61]
Internet-Draft SNMPv3 Applications August 1997
9. Security Considerations
Should have some discussion about notification generation
applications which provide variable bindings when generating a
notification, rather than omitting them and letting the engine get
them from the LPM. Applications that do this should be careful not
to disclose anything that they shouldn't.
10. Editor's Address
David B. Levi
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
U.S.A.
Phone: +1 423 573 1434
EMail: levi@snmp.com
Paul Meyer
Secure Computing Corporation
2675 Long Lake Road
Roseville, MN 55113
U.S.A.
Phone: +1 612 628 1592
EMail: paul_meyer@securecomputing.com
Bob Stewart
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
U.S.A.
Phone: +1 603 654 6923
EMail: bstewart@cisco.com
11. Acknowledgments
This document is the result of the efforts of the SNMPv3 Working
Group. Some special thanks are in order to the following SNMPv3 WG
members:
Dave Battle (SNMP Research, Inc.)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
Expires January 1998 [Page 62]
Internet-Draft SNMPv3 Applications August 1997
John Curran (BBN)
T. Max Devlin (Hi-TECH Connections)
John Flick (Hewlett Packard)
David Harrington (Cabletron Systems Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Russ Mundy (Trusted Information Systems, Inc.)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reid (SNMP Research, Inc.)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Bert Wijnen (IBM T.J. Watson Research Center)
The document is based on recommendations of the IETF Security and
Administrative Framework Evolution for SNMP Advisory Team. Members of
that Advisory Team were:
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
As recommended by the Advisory Team and the SNMPv3 Working Group
Charter, the design incorporates as much as practical from previous
RFCs and drafts. As a result, special thanks are due to the authors
of previous designs known as SNMPv2u and SNMPv2*:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Expires January 1998 [Page 63]
Internet-Draft SNMPv3 Applications August 1997
Glenn W. Waters (Bell-Northern Research Ltd.)
Expires January 1998 [Page 64]
Internet-Draft SNMPv3 Applications August 1997
12. References
[RFC1157]
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, Performance Systems International, MIT Laboratory
for Computer Science, May 1990.
[RFC1213]
McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[RFC1902]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Structure of Management Information for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1903]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[RFC1907]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1908]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC1905, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
Expires January 1998 [Page 65]
Internet-Draft SNMPv3 Applications August 1997
International Network Services, January 1996.
[SNMP-ARCH]
The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An
Architecture for Describing SNMP Management Frameworks", draft-
ietf-snmpv3-next-gen-arch-04.txt, August 1997.
[SNMP-MPD]
The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-03.txt, August
1997.
[SNMP-ACM]
The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McClogrie, K.,
"View-based Access Control Model for the Simple Network Management
Protocol (SNMP)", draft-ietf-snmpv3-acm-02.txt, August 1997.
APPENDIX A - Trap Configuration Example
This section describes an example configuration for a Notification
Generator application which implements the
snmpNotifyMinimalCompliance level. The example configuration
specifies that the Notification Generator should send notifications
to 3 separate managers, using authentication and no privacy for the
first 2 managers, and using both authentication and privacy for the
third manager.
The configuration consists of three rows in the snmpTargetAddrTable,
and two rows in the snmpTargetTable.
* snmpTargetAddrName = "AuthNoPrivTargetAddresses"
* snmpTargetAddrSubIndex = 1
snmpTargetAddrTDomain = snmpUDPDomain
snmpTargetAddrTAddress = 128.1.2.3:162
snmpTargetAddrStorageType = readOnly(5)
snmpTargetAddrRowStatus = active(1)
* snmpTargetAddrName = "AuthNoPrivTargetAddresses"
* snmpTargetAddrSubIndex = 2
snmpTargetAddrTDomain = snmpUDPDomain
snmpTargetAddrTAddress = 128.2.4.6:162
snmpTargetAddrStorageType = readOnly(5)
snmpTargetAddrRowStatus = active(1)
Expires January 1998 [Page 66]
Internet-Draft SNMPv3 Applications August 1997
* snmpTargetAddrName = "AuthPrivTargetAddresses"
* snmpTargetAddrSubIndex = 1
snmpTargetAddrTDomain = snmpUDPDomain
snmpTargetAddrTAddress = 128.1.5.9:162
snmpTargetAddrStorageType = readOnly(5)
snmpTargetAddrRowStatus = active(1)
* snmpTargetName = "AuthNoPrivTarget"
snmpTargetAddrName = "AuthNoPrivTargetAddresses"
snmpTargetMessageProcessingModel = 3
snmpTargetSecurityModel = 3 (USM)
snmpTargetSecurityName = "joe"
snmpTargetSecurityLevel = auth(2)
snmpTargetStorageType = readOnly(5)
snmpTargetRowStatus = active(1)
* snmpTargetName = "AuthPrivTarget"
snmpTargetAddrName = "AuthPrivTargetAddresses"
snmpTargetMessageProcessingModel = 3
snmpTargetSecurityModel = 3 (USM)
snmpTargetSecurityName = "bob"
snmpTargetSecurityLevel = priv(3)
snmpTargetStorageType = readOnly(5)
snmpTargetRowStatus = active(1)
These entries define two separate management target groups. The
first group contains two management targets:
first target second target
------------ -------------
snmpVersion SNMPv3 SNMPv3
securityModel 3 (USM) 3 (USM)
securityName "joe" "joe"
securityLevel auth(2) auth(2)
transportDomain snmpUDPDomain snmpUDPDomain
transportAddress 128.1.2.3:162 128.2.4.6:162
And the second group contains a single management target:
snmpVersion SNMPv3
securityLevel priv(3)
securityModel 3 (USM)
securityName "bob"
transportDomain snmpUDPDomain
transportAddress 128.1.5.9:162
Expires January 1998 [Page 67]
Internet-Draft SNMPv3 Applications August 1997
Table of Contents
1 Abstract ..................................................... 2
2 Overview ..................................................... 3
2.1 Command Generators ......................................... 3
2.2 Command Responders ......................................... 3
2.3 Notification Originators ................................... 3
2.4 Notification Receivers ..................................... 4
2.5 Proxy Forwarder ............................................ 4
3 Management Targets ........................................... 5
4 Elements Of Procedure ........................................ 6
4.1 Command Generators ......................................... 7
4.2 Command Responders ......................................... 10
4.3 Notification Originators ................................... 15
4.4 Notification Receivers ..................................... 18
4.5 Proxy Forwarders ........................................... 21
4.5.1 Request Forwarding ....................................... 21
4.5.1.1 Processing an Incoming Request ......................... 22
4.5.1.2 Processing an Incoming Response ........................ 24
4.5.2 Notification Forwarding .................................. 25
5 The Structure of the MIBs .................................... 29
5.1 The Management Target MIB .................................. 29
5.1.1 Definitions .............................................. 29
5.2 The Notification MIB ....................................... 40
5.2.1 Definitions .............................................. 40
5.3 The Proxy MIB .............................................. 50
5.3.1 Definitions .............................................. 50
6 Identification of Management Targets in Notification Origi-
nators .................................................... 56
7 Notification Filtering ....................................... 57
8 Management Target Translation in Proxy Forwarder Applica-
tions ..................................................... 59
8.1 Management Target Translation for Request Forwarding ....... 59
8.2 Management Target Translation for Notification Forwarding
........................................................... 60
9 Security Considerations ...................................... 62
10 Editor's Address ............................................ 62
11 Acknowledgments ............................................. 62
12 References .................................................. 65
Appendix A Trap Configuration Example .......................... 66
Expires January 1998 [Page 68]
