Internet-Draft SNMPv3 Applications July 1997
SNMPv3 Applications
July 18, 1997
<draft-ietf-snmpv3-appl-00.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 July 1997
1. Abstract
This memo describes the various types of SNMP applications which make
use of an SNMP engine as described in [SNMPV3-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 July 1997
2. Overview
Traditionally there are two types of applications in SNMP, managers
and agents. However, it is useful to further divide these types of
applications in order to define an overall architecture for SNMP.
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 an agent, in the traditional meaning, can be thought of as
a combination of a command responder application, a notification
generator application, and the SNMP engine associated with these
applications. Likewise, a manager, in the traditional meaning, can
be thought of as a combination of a command generator application, a
notification receiver application, and the SNMP engine associated
with these applications. However, there are no restrictions on the
types of applications that 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
Expires January 1998 [Page 3]
Internet-Draft SNMPv3 Applications July 1997
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
messages based on these events or conditions. A notification
originator must have a mechanism for determining where to send
messages, and what SNMP information 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 agents 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
Expires January 1998 [Page 4]
Internet-Draft SNMPv3 Applications July 1997
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
either SNMP requests or notifications 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 SNMPv3 architecture, a proxy forwarder is
actually an application, and need not actually be an SNMP agent.
Specifically, the distinction between a regular 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
an SNMP agent 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, an SNMP agent must have the detailed definition of the
MIB view, and even if it needs to issue requests to other agents,
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
Expires January 1998 [Page 5]
Internet-Draft SNMPv3 Applications July 1997
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:
- 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 [SNMPV3-ARCH].
Expires January 1998 [Page 6]
Internet-Draft SNMPv3 Applications July 1997
4.1. Command Generators
A command generator initiates an SNMP request by calling the Message
Processing Subsystem using the following abstract service interface:
sendPdu (
transportDomain
transportAddress
messageProcessingModel
securityModel
securityName
LoS
contextEngineID
contextName
PDU
expectResponse
)
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 LoS 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 command generator may omit
this parameter, in which case the Message Processing Subsystem
should use the engineID of the SNMP engine to which the
request is to be sent.
- The contextName is provided by the command generator if it
wishes to explicitly specify the location of 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 July 1997
- The PDU is the value constructed in the previous step.
- The expectResponse argument indicates that a response is
expected.
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 (
contextEngineID
contextName
PDU
LoS
statusInformation
)
Where:
- The contextEngineID is the value from the received response.
- The contextName is the value from the received response.
- The PDU is the value from the received response.
- The LoS is the value from the received response.
- The statusInformation indicates success or failure in
receiving the response.
The procedure when a command generator receives a response is as
follows:
(1) The SNMPv2 operation type is determined from the ASN.1 tag value
associated with the PDU parameter. The operation type should
always be a Response (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 8]
Internet-Draft SNMPv3 Applications July 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 =
registerContextEngineID (
contextEngineID
pduType
)
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 (
contextEngineID
pduType
)
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 9]
Internet-Draft SNMPv3 Applications July 1997
waits to receive SNMP messages. The abstract service interface used
for receiving messages is:
processPdu (
contextEngineID
contextName
PDU
maxSizeResponseScopedPDU
securityModel
securityName
LoS
stateReference
)
Where:
- The contextEngineID is the value from the received message.
- The contextName is the value from the received message.
- The PDU is the value from the received message.
- The maxSizeResponseScopedPDU is the value from the received
message.
- The securityModel is the value from the received message.
- The securityName is the value from the received message.
- The LoS is the value from the received message.
- The stateReference is a value assigned by the Message
Processing Subsystem. This subsystem 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.
(1) The SNMPv2 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 (the Message Processing
Subsystem should never call a command responder application using
the processPdu interface for any other type of PDU).
Expires January 1998 [Page 10]
Internet-Draft SNMPv3 Applications July 1997
(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
LoS, 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 =
isAccessAllowed (
securityModel
securityName
LoS
viewType
contextName
variableName
)
Where:
- The securityModel is the value from the received message.
- The securityName is the value from the received message.
- The LoS 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.
Normally, the result of the management operation will be a new PDU
value, and processing will continue in the next step. However,
there are two conditions under which a new PDU value will not be
generated:
Expires January 1998 [Page 11]
Internet-Draft SNMPv3 Applications July 1997
- 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 the next
step.
- The isAccessAllowed abstract service interface is conceptually
called for each object in the variable-bindings (and possibly
multiple times for a single variable-bindings in the case of a
GetNext or GetBulk PDU). At any point, if the returned
statusInformation indicates an error, result indicates an
error, processing of the management operation is halted, no
result PDU is generated, the snmpUnavailableViews counter is
incremented, and control is passed to the next step.
(6) The Message Processing Subsystem is called to generate a response
or report message. The abstract service interface is:
returnResponsePdu (
contextEngineID
contextName
PDU
maxSizeResponseScopedPDU
securityModel
securityName
LoS
stateReference
statusInformation
)
Where:
- The contextEngineID is the value from the processPdu call.
- The contextName is the value from the processPdu call.
- The PDU is the result generated in the previous step. If no
result PDU was generated, 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 securityModel is the value from the processPdu call.
- The securityName is the value from the processPdu call.
Expires January 1998 [Page 12]
Internet-Draft SNMPv3 Applications July 1997
- The LoS is the value from the processPdu call.
- 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 needed to generate a Report PDU. In the
latter case, the OID and counter value are that of the counter
that was incremented in the previous step
(snmpUnavailableContexts or snmpUnavailableViews).
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 13]
Internet-Draft SNMPv3 Applications July 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 the contextEngineID and contextName of the
location where the information to be conveyed in the notification
exists. 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 LoS, 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 14]
Internet-Draft SNMPv3 Applications July 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 found in the previous step.
(4) If the notification should be 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:
sendPdu (
transportDomain
transportAddress
messageProcessingModel
securityModel
securityName
LoS
contextEngineID
contextName
PDU
expectResponse
)
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 LoS 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.
- The PDU is the value constructed in the previous step.
- The expectResponse argument indicates that no response is
expected.
Expires January 1998 [Page 15]
Internet-Draft SNMPv3 Applications July 1997
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 the previous step, 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 16]
Internet-Draft SNMPv3 Applications July 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 contains 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 contextEngineID is the value from the received message.
- The contextName is the value from the received message.
- The PDU is the value from the received message.
- The maxSizeResponseScopedPDU is the value from the received
message.
- The securityModel is the value from the received message.
- The securityName is the value from the received message.
- The LoS 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.
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.
Expires January 1998 [Page 17]
Internet-Draft SNMPv3 Applications July 1997
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 contextEngineID is the value from the processPdu call.
- The contextName is the value from the processPdu call.
- The PDU is the result generated in the previous step.
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The securityModel is the value from the processPdu call.
- The securityName is the value from the processPdu call.
- The LoS is the value from the processPdu call.
- 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
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 18]
Internet-Draft SNMPv3 Applications July 1997
4.5. Proxy Forwarders
A proxy forwarder application deals with forwarding messages which
contain Get, GetNext, GetBulk, Set, SNMPv2-Trap, and Inform 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 last two (Trap, Inform) deal with notifications
concerning information located within a particular context. A proxy
forwarder application treats these two situations slightly different.
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, processing an incoming
request, and processing and incoming response. These are described
in the following two sections.
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
Expires January 1998 [Page 19]
Internet-Draft SNMPv3 Applications July 1997
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 contextEngineID is the value from the processPdu call.
- The contextName is the value from the processPdu call.
- 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 securityModel is the value from the processPdu call.
- The securityName is the value from the processPdu call.
- The LoS is the value from the processPdu call.
- 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.
Expires January 1998 [Page 20]
Internet-Draft SNMPv3 Applications July 1997
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 LoS is that of the outgoing management target.
- The contextEngineID is the value originally received.
- The contextName is the value originally received.
- The PDU is the value constructed in the previous step.
- 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:
Expires January 1998 [Page 21]
Internet-Draft SNMPv3 Applications July 1997
(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:
- The contextEngineID is the value extracted from the cache.
- The contextName is the value extracted from the cache.
- 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 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.
Expires January 1998 [Page 22]
Internet-Draft SNMPv3 Applications July 1997
- The LoS is that of the original incoming management target
extracted from the cache.
- The stateReference is the value extracted from the cache.
- The statusInformation indicates that no error occured and that
a Response 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
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 contextEngineID is the received value.
- The contextName is the received 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 securityModel is the received value.
- The securityName is the received value.
- The LoS is the received value.
Expires January 1998 [Page 23]
Internet-Draft SNMPv3 Applications July 1997
- 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
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 and an snmpProxyDrops Report PDU is
Expires January 1998 [Page 24]
Internet-Draft SNMPv3 Applications July 1997
generated, 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 contextEngineID is the originally received value.
- The contextName is the originally received value.
- The PDU is the value constructed in the previous step.
- The maxSizeResponseScopedPDU is a local value indicating the
maximum size of a ScopedPDU that the application can accept.
- The securityModel is the originally received value.
- The securityName is the originally received value.
- The LoS is the originally received value.
- The stateReference is the originally received value.
- The statusInformation indicates that no error occured and that
a Response message should be generated.
Expires January 1998 [Page 25]
Internet-Draft SNMPv3 Applications July 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,
SnmpLoS,
Expires January 1998 [Page 26]
Internet-Draft SNMPv3 Applications July 1997
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
????
????
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 27]
Internet-Draft SNMPv3 Applications July 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 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
columnar object in the snmpTargetAddrTable whose
index begins with the desired index value of
snmpTargetAddrName).
Expires January 1998 [Page 28]
Internet-Draft SNMPv3 Applications July 1997
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
""
::= { snmpTargetObjects 2 }
snmpTargetAddrEntry OBJECT-TYPE
SYNTAX SnmpV3TargetAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
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
"The locally arbitrary, but unique identifier associated
an snmpTargetAddrEntry within a group of entries in the
snmpTargetAddrTable."
::= { snmpTargetAddrEntry 1 }
Expires January 1998 [Page 29]
Internet-Draft SNMPv3 Applications July 1997
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 an LoS that indicates both
authentication and privacy, the derived value may be
increased to compensate for extra processing time spent
during authentication and encryption processing."
DEFVAL { 1500 }
::= { snmpTargetAddrEntry 4 }
Expires January 1998 [Page 30]
Internet-Draft SNMPv3 Applications July 1997
snmpTargetAddrStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpTargetAddrEntry 5 }
snmpTargetAddrRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpTargetAddrEntry 6 }
snmpTargetTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3TargetEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
::= { snmpTargetObjects 3 }
snmpTargetEntry OBJECT-TYPE
SYNTAX SnmpV3TargetEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
INDEX { snmpTargetName }
::= { snmpTargetTable 1 }
SnmpV3TargetEntry ::= SEQUENCE {
snmpTargetName SnmpAdminString,
snmpTargetAddrName SnmpAdminString,
snmpTargetMessageProcessingModel INTEGER,
snmpTargetSecurityModel SnmpSecurityModel,
snmpTargetSecurityName SnmpAdminString,
snmpTargetLoS SnmpLoS,
snmpTargetRetryCount Integer32,
snmpTargetStorageType StorageType,
snmpTargetRowStatus RowStatus
}
snmpTargetName OBJECT-TYPE
SYNTAX SnmpAdminString
Expires January 1998 [Page 31]
Internet-Draft SNMPv3 Applications July 1997
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."
::= { snmpTargetEntry 2 }
snmpTargetMessageProcessingModel OBJECT-TYPE
SYNTAX INTEGER (SIZE(0..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpTargetEntry 3 }
snmpTargetSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpTargetEntry 4 }
snmpTargetSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpTargetEntry 5 }
snmpTargetLoS OBJECT-TYPE
SYNTAX SnmpLoS
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpTargetEntry 6 }
Expires January 1998 [Page 32]
Internet-Draft SNMPv3 Applications July 1997
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."
::= { snmpTargetEntry 7 }
snmpTargetStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpTargetEntry 8 }
snmpTargetRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { 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?
Expires January 1998 [Page 33]
Internet-Draft SNMPv3 Applications July 1997
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
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
--
-- ------------------------------------------------------------------
snmpTargetBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which require
remote configuration of management targets."
MODULE -- this module
MANDATORY-GROUPS { snmpTargetBasicGroup }
::= { snmpTargetCompliances 1 }
Expires January 1998 [Page 34]
Internet-Draft SNMPv3 Applications July 1997
snmpTargetFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which require
remote configuration of management targets."
MODULE -- this module
MANDATORY-GROUPS { snmpTargetBasicGroup }
::= { snmpTargetCompliances 2 }
snmpTargetReadCreateCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which require
remote configuration of management targets."
MODULE -- this module
MANDATORY-GROUPS { snmpTargetBasicGroup }
::= { snmpTargetCompliances 3 }
snmpTargetBasicGroup OBJECT-GROUP
OBJECTS {
snmpTargetAddressSpinLock,
snmpTargetAddrTDomain,
snmpTargetAddrTAddress,
snmpTargetAddrStorageType,
snmpTargetAddrRowStatus,
snmpTargetAddrName,
snmpTargetMessageProcessingModel,
snmpTargetSecurityModel,
snmpTargetSecurityName,
snmpTargetLoS,
snmpTargetStorageType,
snmpTargetRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing basic remote
configuration of management targets."
::= { snmpTargetGroups 1 }
snmpTargetResponseGroup OBJECT-GROUP
OBJECTS {
snmpTargetAddrTimeout,
snmpTargetRetryCount,
snmpTargetDefaultRetryAlgorithm
}
STATUS current
DESCRIPTION
Expires January 1998 [Page 35]
Internet-Draft SNMPv3 Applications July 1997
"A collection of objects providing remote configuration
of management targets for applications which generate
Get, GetNext, GetBulk, Set, or Inform requests."
::= { snmpTargetGroups 2 }
END
Expires January 1998 [Page 36]
Internet-Draft SNMPv3 Applications July 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,
SnmpLoS,
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 37]
Internet-Draft SNMPv3 Applications July 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
????
????
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 38]
Internet-Draft SNMPv3 Applications July 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
""
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 for generating
notifications, and the type of notification to be
generated. 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
notifications.
Also note that if an SNMP entity only supports
Expires January 1998 [Page 39]
Internet-Draft SNMPv3 Applications July 1997
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
""
INDEX { snmpTargetName }
::= { snmpNotifyFilterProfileTable 1 }
SnmpV3NotifyFilterProfileEntry ::= SEQUENCE {
snmpNotifyFilterProfileName SnmpAdminString
}
snmpNotifyFilterProfileName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpNotifyFilterProfileEntry 1 }
snmpNotifyFilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3NotifyFilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is used to select management targets which
should receive notifications."
::= { snmpNotifyObjects 3 }
Expires January 1998 [Page 40]
Internet-Draft SNMPv3 Applications July 1997
snmpNotifyFilterEntry OBJECT-TYPE
SYNTAX SnmpV3NotifyFilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
INDEX { snmpNotifyFilterProfileName,
IMPLIED snmpNotifyFilterSubtree }
::= { snmpNotifyFilterTable 1 }
SnmpV3NotifyFilterEntry ::= SEQUENCE {
snmpNotifyFilterSubtree OBJECT IDENTIFIER,
snmpNotifyFilterMask OCTET STRING,
snmpNotifyFilterType INTEGER,
snmpNotifyFilterStorageType StorageType,
snmpNotifyFilterRowStatus RowStatus
}
snmpNotifyFilterSubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
::= { snmpNotifyFilterEntry 1 }
snmpNotifyFilterMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpNotifyFilterEntry 2 }
snmpNotifyFilterType OBJECT-TYPE
SYNTAX INTEGER {
included(1),
excluded(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpNotifyFilterEntry 3 }
snmpNotifyFilterStorageType OBJECT-TYPE
SYNTAX StorageType
Expires January 1998 [Page 41]
Internet-Draft SNMPv3 Applications July 1997
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpNotifyFilterEntry 4 }
snmpNotifyFilterRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpNotifyFilterEntry 5 }
-- ------------------------------------------------------------------
--
-- Conformance information
--
-- ------------------------------------------------------------------
snmpNotifyCompliances OBJECT IDENTIFIER ::=
{ snmpNotifyConformance 1 }
snmpNotifyGroups OBJECT IDENTIFIER ::=
{ snmpNotifyConformance 2 }
-- ------------------------------------------------------------------
--
-- Compliance statements
--
-- ------------------------------------------------------------------
snmpNotifyMinimalCompliance 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
Expires January 1998 [Page 42]
Internet-Draft SNMPv3 Applications July 1997
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."
OBJECT snmpTargetLoS
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 }
snmpNotifyBasicCompliance 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."
Expires January 1998 [Page 43]
Internet-Draft SNMPv3 Applications July 1997
MODULE SNMPV3-TARGET-MIB
MANDATORY-GROUPS { snmpTargetBasicGroup }
MODULE -- This Module
MANDATORY-GROUPS { snmpNotifyFilterGroup }
::= { snmpNotifyCompliances 2 }
snmpNotifyCompleteCompliance 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."
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 }
Expires January 1998 [Page 44]
Internet-Draft SNMPv3 Applications July 1997
END
Expires January 1998 [Page 45]
Internet-Draft SNMPv3 Applications July 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,
SnmpLoS,
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 46]
Internet-Draft SNMPv3 Applications July 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
????
????
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 47]
Internet-Draft SNMPv3 Applications July 1997
snmpProxyTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpV3ProxyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
::= { snmpProxyObjects 2 }
snmpProxyEntry OBJECT-TYPE
SYNTAX SnmpV3ProxyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
INDEX { snmpProxyIndex }
::= { snmpProxyTable 1 }
SnmpV3ProxyEntry ::= SEQUENCE {
snmpProxyIndex Integer32,
snmpProxyType INTEGER,
snmpProxyContextEngineID SnmpEngineID,
snmpProxyContextName SnmpAdminString,
snmpProxyTargetIn Integer32,
snmpProxyTargetOut Integer32,
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
STATUS current
DESCRIPTION
Expires January 1998 [Page 48]
Internet-Draft SNMPv3 Applications July 1997
""
::= { snmpProxyEntry 2 }
snmpProxyContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpProxyEntry 3 }
snmpProxyContextName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { snmpProxyEntry 4 }
snmpProxyTargetIn OBJECT-TYPE
SYNTAX Integer32
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 Integer32
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
object is used for proxy forwarding)."
::= { snmpProxyEntry 6 }
snmpProxyStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
Expires January 1998 [Page 49]
Internet-Draft SNMPv3 Applications July 1997
DESCRIPTION
""
::= { snmpProxyEntry 7 }
snmpProxyRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
""
::= { 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 }
snmpProxyGroup OBJECT-GROUP
OBJECTS {
snmpProxyNextIndex,
snmpProxyType,
snmpProxyContextEngineID,
snmpProxyContextName,
Expires January 1998 [Page 50]
Internet-Draft SNMPv3 Applications July 1997
snmpProxyTargetIn,
snmpProxyTargetOut,
snmpProxyStorageType,
snmpProxyRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing remote configuration of
management targets, including row creation in the
snmpTargetTable."
::= { snmpProxyGroups 3 }
END
Expires January 1998 [Page 51]
Internet-Draft SNMPv3 Applications July 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 52]
Internet-Draft SNMPv3 Applications July 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. When generating notifications for a group of
management targets, all active entries in the snmpNotifyFilterTable,
for which the value of the snmpNotifyFilterProfileName index is equal
to the value of the snmpNotifyFilterProfileName object of the
management target group, 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 object instance is excluded by the
set of matching entries, compare the object instance's OBJECT
IDENTIFIER with each of the matching entries. If none match, then
the 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 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 or exclusion.
An 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 53]
Internet-Draft SNMPv3 Applications July 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, LoS, security model, and
securityName must match the values of
snmpTargetMessageProcessingModel, snmpTargetSecurityModel,
snmpTargetSecurityName, and snmpTargetLoS 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 54]
Internet-Draft SNMPv3 Applications July 1997
identifies an entry in the snmpTargetTable. The
snmpTargetMessageProcessingModel, snmpTargetSecurityModel,
snmpTargetSecurityName, and snmpTargetLoS 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, LoS, security model, and
securityName must match the values of
snmpTargetMessageProcessingModel, snmpTargetSecurityModel,
snmpTargetSecurityName, and snmpTargetLoS 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 55]
Internet-Draft SNMPv3 Applications July 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 56]
Internet-Draft SNMPv3 Applications July 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. Acknowledgments
This document was produced by the IETF SNMPv3 working group.
Expires January 1998 [Page 57]
Internet-Draft SNMPv3 Applications July 1997
11. 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 58]
Internet-Draft SNMPv3 Applications July 1997
International Network Services, January 1996.
[SNMPV3-ARCH]
SNMPv3 Working Group, Harrington, D., Wijnen, B., "An Architecture
for Describing Internet Management Frameworks", draft-ietf-snmpv3-
next-gen-arch-02.txt, June 1997.
[SNMPV3-MPC]
SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
"Message Processing and Control Model for version 3 of the Simple
Network Management Protocol (SNMPv3)", draft-ietf-snmpv3-next-gen-
arch-02.txt, June 1997.
[SNMPV3-ACM]
SNMPv3 Working Group, Wijnen, B., Presuhn, R., McClogrie, K.,
"Access Control Model for version 3 of the Simple Network
Management Protocol (SNMPv3)", draft-ietf-snmpv3-next-gen-arch-
02.txt, June 1997.
12. Author'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
????
????
U.S.A.
Phone: +1 603 654 6923
EMail: bstewart@cisco.com
Expires January 1998 [Page 59]
Internet-Draft SNMPv3 Applications July 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)
* 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"
snmpTargetLoS = auth(2)
snmpTargetStorageType = readOnly(5)
snmpTargetRowStatus = active(1)
* snmpTargetName = "AuthPrivTarget"
snmpTargetAddrName = "AuthPrivTargetAddresses"
snmpTargetMessageProcessingModel = 3
snmpTargetSecurityModel = 3 (USM)
Expires January 1998 [Page 60]
Internet-Draft SNMPv3 Applications July 1997
snmpTargetSecurityName = "bob"
snmpTargetLoS = 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"
LoS 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
LoS priv(3)
securityModel 3 (USM)
securityName "bob"
transportDomain snmpUDPDomain
transportAddress 128.1.5.9:162
Expires January 1998 [Page 61]
Internet-Draft SNMPv3 Applications July 1997
Table of Contents
1 Abstract ..................................................... 2
2 Overview ..................................................... 3
2.1 Command Generators ......................................... 3
2.2 Command Responders ......................................... 3
2.3 Notification Originators ................................... 4
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 ......................................... 9
4.3 Notification Originators ................................... 14
4.4 Notification Receivers ..................................... 17
4.5 Proxy Forwarders ........................................... 19
4.5.1 Request Forwarding ....................................... 19
4.5.1.1 Processing an Incoming Request ......................... 19
4.5.1.2 Processing an Incoming Response ........................ 22
4.5.2 Notification Forwarding .................................. 23
5 The Structure of the MIBs .................................... 26
5.1 The Management Target MIB .................................. 26
5.1.1 Definitions .............................................. 26
5.2 The Notification MIB ....................................... 37
5.2.1 Definitions .............................................. 37
5.3 The Proxy MIB .............................................. 46
5.3.1 Definitions .............................................. 46
6 Identification of Management Targets in Notification Origi-
nators .................................................... 52
7 Notification Filtering ....................................... 53
8 Management Target Translation in Proxy Forwarder Applica-
tions ..................................................... 54
8.1 Management Target Translation for Request Forwarding ....... 54
8.2 Management Target Translation for Notification Forwarding
........................................................... 55
9 Security Considerations ...................................... 57
10 Acknowledgments ............................................. 57
11 References .................................................. 58
12 Author's Address ............................................ 59
Appendix A Trap Configuration Example .......................... 60
Expires January 1998 [Page 62]
