As per Relevance of the word asynchronous, we have this rfc below:
Network Working Group L.
Request for Comments: 1224 IBM
May 1991
Techniques for Managing Asynchronously Generated
Status of this
This memo defines common mechanisms for managing
produced alerts in a manner consistent with current
management protocols
This memo specifies an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This RFC explores mechanisms to prevent a remotely managed
from burdening a manager or network with an unexpected amount
network management information, and to ensure delivery of "important
information. The focus is on controlling the flow of
generated information, and not how the information is generated
Table of
1. Introduction................................................... 2
2. Problem Definition............................................. 3
2.1 Polling Advantages............................................ 3
(a) Reliable detection of failures............................... 3
(b) Reduced protocol complexity on managed entity................ 3
(c) Reduced performance impact on managed entity................. 3
(d) Reduced configuration requirements to manage remote entity... 4
2.2 Polling Disadvantages......................................... 4
(a) Response time for problem detection.......................... 4
(b) Volume of network management traffic generated............... 4
2.3 Alert Advantages.............................................. 5
(a) Real-time knowledge of problems.............................. 5
(b) Minimal amount of network management traffic................. 5
2.4 Alert Disadvantages........................................... 5
(a) Potential loss of critical information....................... 5
(b) Potential to over-inform a manager........................... 5
3. Specific Goals of this Memo.................................... 6
4. Compatibility with Existing Network Management Protocols....... 6
Steinberg [Page 1]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
5. Closed Loop "Feedback" Alert Reporting with a "Pin"
Window Limit................................................... 6
5.1 Use of Feedback............................................... 7
5.1.1 Example..................................................... 8
5.2 Notes on Feedback/Pin usage................................... 8
6. Polled, Logged Alerts.......................................... 9
6.1 Use of Polled, Logged Alerts.................................. 10
6.1.1 Example..................................................... 12
6.2 Notes on Polled, Logged Alerts................................ 12
7. Compatibility with SNMP and CMOT .............................. 14
7.1 Closed Loop Feedback Alert Reporting.......................... 14
7.1.1 Use of Feedback with SNMP................................... 14
7.1.2 Use of Feedback with CMOT................................... 14
7.2 Polled, Logged Alerts......................................... 14
7.2.1 Use of Polled, Logged Alerts with SNMP...................... 14
7.2.2 Use of Polled, Logged Alerts with CMOT...................... 15
8. Notes on Multiple Manager Environments......................... 15
9. Summary........................................................ 16
10. References.................................................... 16
11. Acknowledgements.............................................. 17
Appendix A. Example of polling costs............................. 17
Appendix B. MIB object definitions............................... 19
Security Considerations........................................... 22
Author's Address.................................................. 22
1.
This memo defines mechanisms to prevent a remotely managed
from burdening a manager or network with an unexpected amount
network management information, and to ensure delivery of "important
information. The focus is on controlling the flow of
generated information, and not how the information is generated
Mechanisms for generating and controlling the generation
asynchronous information may involve protocol specific issues
There are two understood mechanisms for transferring
management information from a managed entity to a manager: request
response driven polling, and the unsolicited sending of "alerts".
Alerts are defined as any management information delivered to
manager that is not the result of a specific query. Advantages
disadvantages exist within each method. They are detailed in
2 below
Alerts in a failing system can be generated so rapidly that
adversely impact functioning resources. They may also fail to
delivered, and critical information maybe lost. Methods are
both to limit the volume of alert transmission and to assist
delivering a minimum amount of information to a manager
Steinberg [Page 2]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
It is our belief that managed agents capable of
generating alerts should attempt to adopt mechanisms that fill
of these needs. For reasons shown in section 2.4, it is necessary
fulfill both alert-management requirements. A complete alert-
system must ensure that alerts are delivered or their loss
with a means to recreate the lost information, AND it must not
itself to overburden its manager with an unreasonable amount
information
2. Problem
The following discusses the relative advantages and disadvantages
polled vs. alert driven management
2.1 Polling
(a) Reliable detection of failures
A manager that polls for all of its information
more readily determine machine and network failures
a lack of a response to a query indicates
with the machine or network. A manager relying
notification of problems might assume that a
system is good, should the alert be unable to
its destination, or the managed system be unable
correctly generate the alert. Examples of
include network failures (in which an isolated
cannot deliver the alert), and power failures (in
a failing machine cannot generate an alert).
subtle forms of failure in the managed entity
produce an incorrectly generated alert, or no alert
all
(b) Reduced protocol complexity on managed
The use of a request-response based system is based
conservative assumptions about the underlying
protocol. Timeouts and retransmits (re-requests)
be built into the manager. In addition, this
the manager to affect the amount of network
information flowing across the network directly
(c) Reduced performance impact on managed
In a purely polled system, there is no danger of
to often test for an alert condition. This
takes CPU cycles away from the real mission of
managed entity. Clearly, testing a threshold on
Steinberg [Page 3]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
packet received could have unwanted performance
on machines such as gateways. Those who wish to
thresholds and alerts must choose the parameters to
tested with great care, and should be
discouraged from updating statistics and checking
frequently
(d) Reduced Configuration Requirements to manage
Remote, managed entities need not be
with one or more destinations for reporting information
Instead, the entity merely responds to
makes a specific request. When changing the
configuration, there is never a need to
all remote manageable systems. In addition, any
of "authorized" managers (i.e., those passing
authentication tests imposed by the network
protocol) may obtain information from any managed entity
This occurs without reconfiguring the entity
without reaching an entity-imposed limit on the
number of potential managers
2.2 Polling
(a) Response time for problem
Having to poll many MIB [2] variables per machine
a large number of machines is itself a
problem. The ability of a manager to
such a system is limited; should a system
shortly after being polled there may be a
delay before it is polled again. During this time
the manager must assume that a failing system
acceptable. See Appendix A for a
example of such a system
It is worthwhile to note that while improving the
time to detect failures might not greatly improve
time to correct the failure, the problem will
not be repaired until it is detected. In addition
most network managers would prefer to at least
faults before network users start phoning in
(b) Volume of network management
Polling many objects (MIB variables) on many
greatly increases the amount of network
Steinberg [Page 4]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
traffic flowing across the network (see Appendix A).
While it is possible to minimize this through the
of hierarchies (polling a machine for a general
of all the machines it polls), this aggravates
response time problem previously discussed
2.3 Alert
(a) Real-time Knowledge of
Allowing the manager to be notified of
eliminates the delay imposed by polling many objects
systems in a loop
(b) Minimal amount of Network Management
Alerts are transmitted only due to detected errors
By removing the need to transfer large amounts of
information that merely demonstrate a healthy system
network and system (machine processor) resources may
freed to accomplish their primary mission
2.4 Alert
(a) Potential Loss of Critical
Alerts are most likely not to be delivered when
managed entity fails (power supply fails) or
network experiences problems (saturated or isolated).
It is important to remember that failing machines
networks cannot be trusted to inform a manager
they are failing
(b) Potential to Over-inform the
An "open loop" system in which the flow of alerts
a manager is fully asynchronous can result in an
of alerts being delivered (e.g., link up/down
when lines vacillate). This information places an
burden on a strained network, and could prevent
manager from disabling the mechanism generating
alerts; all available network bandwidth into the
could be saturated with incoming alerts
Most major network management systems strive to use an
combination of alerts and polling. Doing so preserves the
of each while eliminating the disadvantages of pure polling
Steinberg [Page 5]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
3. Specific Goals of this
This memo suggests mechanisms to minimize the disadvantages of
usage. An optimal system recognizes the potential
associated with sending too many alerts in which a manager
ineffective at managing, and not adequately using alerts (
given the volumes of data that must be actively monitored with
scaling). It is the author's belief that this is best done
allowing alert mechanisms that "close down" automatically when over
delivering asynchronous (unexpected) alerts, and that also allow
flow of synchronous alert information through a polled log. The
of "feedback" (with a sliding window "pin") discussed in section 5
addresses the former need, while the discussion in section 6
"polled, logged alerts" does the latter
This memo does not attempt to define mechanisms for controlling
asynchronous generation of alerts, as such matters deal
specifics of the management protocol. In addition, no attempt
made to define what the content of an alert should be. The
mechanism does require the addition of a single alert type, but
is not meant to impact or influence the techniques for generating
other alert (and can itself be generated from a MIB object or
management protocol). To make any effective use of the
mechanisms described in this memo, implementation of several
objects is required in the relevant managed systems. The location
these objects in the MIB is under an experimental subtree
to the Alert-Man working group of the Internet Engineering Task
(IETF) and published in the "Assigned Numbers" RFC [5]. Currently
this subtree is defined
alertMan ::= { experimental 24 }.
4. Compatibility With Existing Network Management
It is the intent of this document to suggest mechanisms that
neither the letter nor the spirit of the protocols expressed in
[3] and SNMP [4]. To achieve this goal, each mechanism
will give an example of its conformant use with both SNMP and CMOT
5. Closed Loop "Feedback" Alert Reporting with a "Pin"
Window
One technique for preventing an excess of alerts from being
involves required feedback to the managed agent. The name "feedback
describes a required positive response from a potentially "over
reported" manager, before a remote agent may continue
alerts at a high rate. A sliding window "pin" threshold (so
for the metal on the end of a meter) is established as a part of
Steinberg [Page 6]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
user-defined SNMP trap, or as a managed CMOT event. This
defines the maximum allowable number of alerts ("maxAlertsPerTime")
that may be transmitted by the agent, and the "windowTime" in
that alerts are tested against. Note that "maxAlertsPerTime
represents the sum total of all alerts generated by the agent, and
not duplicated for each type of alert that an agent might generate
Both "maxAlertsPerTime" and "windowTime" are required MIB objects
SMI [1] type INTEGER, must be readable, and may be writable
the implementation permit it
Two other items are required for the feedback technique. The
is a Boolean MIB object (SMI type is INTEGER, but it is treated as
Boolean whose only value is zero, i.e., "FALSE")
"alertsEnabled", which must have read and write access. The
is a user defined alert named "alertsDisabled". Please see
B for their complete definitions
5.1 Use of
When an excess of alerts is being generated, as determined by
total number of alerts exceeding "maxAlertsPerTime"
"windowTime" seconds, the agent sets the Boolean value
"alertsEnabled" to "FALSE" and sends a single alert of
"alertsDisabled".
Again, the pin mechanism operates on the sum total of all
generated by the remote system. Feedback is implemented once
agent and not separately for each type of alert in each agent.
it is also possible to implement the Feedback/Pin technique on a
alert-type basis, such a discussion belongs in a document
with controlling the generation of individual alerts
The typical use of feedback is detailed in the following steps
(a) Upon initialization of the agent, the value
"alertsEnabled" is set to "TRUE".
(b) Each time an alert is generated, the value
"alertsEnabled" is tested. Should the value be "FALSE",
no alert is sent. If the value is "TRUE", the alert
sent and the current time is stored locally
(c) If at least "maxAlertsPerTime" have been generated,
agent calculates the difference of time stored for
new alert from the time associated with alert
"maxAlertsPerTime" previously. Should this amount
less than "windowTime", a single alert of the
"alertsDisabled" is sent to the manager and the value
Steinberg [Page 7]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
"alertsEnabled" is then set to "FALSE".
(d) When a manager receives an alert of the type "Alerts
Disabled", it is expected to set "alertsEnabled"
to "TRUE" to continue to receive alert reports
5.1.1
In a sample system, the maximum number of alerts any single
entity may send the manager is 10 in any 3 second interval.
circular buffer with a maximum depth of 10 time of day elements
defined to accommodate statistics keeping
After the first 10 alerts have been sent, the managed entity
the time difference between its oldest and newest alerts. By
the time for a fixed number of alerts, the system will never
itself merely because a few alerts were transmitted back to back
The mechanism will disable reporting only after at least 10
have been sent, and the only if the last 10 all occurred within a 3
second interval. As alerts are sent over time, the list
data on the last 10 alerts only
5.2 Notes on Feedback/Pin
A manager may periodically poll "alertsEnabled" in case
"alertsDisabled" alert is not delivered by the network.
implementers may also choose to add COUNTER MIB objects to show
total number of alerts transmitted and dropped by "alertsEnabled
being FALSE. While these may yield some indication of the number
lost alerts, the use of "Polled, Logged Alerts" offers a superset
this function
Testing the alert frequency need not begin until a minimum number
alerts have been sent (the circular buffer is full). Even then,
actual test is the elapsed time to get a fixed number of alerts
not the number of alerts in a given time period. This eliminates
need for complex averaging schemes (keeping current alerts per
as a frequency and redetermining the current value based on
previous value and the time of a new alert). Also eliminated is
problem of two back to back alerts; they may indeed appear to be
large number of alerts per second, but the fact remains that
are only two alerts. This situation is unlikely to cause a
for any manager, and should not trigger the mechanism
Since alerts are supposed to be generated infrequently,
the pin and testing the threshold should not impact
performance of the agent (managed entity). While repeated
Steinberg [Page 8]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
may affect performance when an excess of alerts are
transmitted, this effect would be minor compared to the cost
generating and sending so many alerts. Long before the cost
testing (in CPU cycles) becomes relatively high, the
mechanism should disable alert sending and affect savings both
alert sending and its own testing (note that the list maintenance
testing mechanisms disable themselves when they disable
reporting). In addition, testing the value of "alertsEnabled"
limit the CPU burden of building alerts that do not need to be sent
It is advised that the implementer consider allowing write access
both the window size and the number of alerts allowed in a window'
time. In doing so, a management station has the option of
these parameters remotely before setting "alertsEnabled" to "TRUE".
Should either of these objects be set to 0, a conformant system
disable the pin and feedback mechanisms and allow the agent to
all of the alerts it generates
While the feedback mechanism is not high in CPU utilization costs
those implementing alerts of any kind are again cautioned to
care that the alerts tested do not occur so frequently as to
the performance of the agent's primary function
The user may prefer to send alerts via TCP to help ensure delivery
the "alerts disabled" message, if available
The feedback technique is effective for preventing the over-
of alerts to a manager. It does not assist with the problem
"under-reporting" (see "polled, logged alerts" for this).
It is possible to lose alerts while "alertsEnabled" is "FALSE".
Ideally, the threshold of "maxAlertsPerTime" should be
sufficiently high that "alertsEnabled" is only set to "FALSE"
"over-reporting" situations. To help prevent alerts from
being lost when the threshold is exceeded, this method can
combined with "polled, logged alerts" (see below).
6. Polled, Logged
A simple system that combines the request-response advantages
polling while minimizing the disadvantages is "Polled,
Alerts". Through the addition of several MIB objects, one gains
system that minimizes network management traffic, lends itself
scaling, eliminates the reliance on delivery, and imposes
potential over-reporting problems inherent in pure alert
architectures. Minimizing network management traffic is affected
reducing multiple requests to a single request. This technique
not eliminate the need for polling, but reduces the amount of
Steinberg [Page 9]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
transferred and ensures the manager either alert delivery
notification of an unreachable node. Note again, the goal is
address the needs of information (alert) flow and not to control
local generation of alerts
6.1 Use of Polled, Logged
As alerts are generated by a remote managed entity, they are
locally in a table. The manager may then poll a single MIB object
determine if any number of alerts have been generated. Each
request returns a copy of an "unacknowledged" alert from the
log, or an indication that the table is empty. Upon receipt,
manager might "acknowledge" any alert to remove it from the log
Entries in the table must be readable, and can optionally allow
user to remove them by writing to or deleting them
This technique requires several additional MIB objects.
alert_log is a SEQUENCE OF logTable entries that must be readable
and can optionally have a mechanism to remove entries (e.g., SNMP
or CMOT delete). An optional read-only MIB object of type INTEGER
"maxLogTableEntries" gives the maximum number of log entries
system will support. Please see Appendix B for their
definitions
The typical use of Polled, Logged Alerts is detailed below
(a) Upon initialization, the agent builds a pointer to a
table. The table is empty (a sequence of zero entries).
(b) Each time a local alert is generated, a logTable
is built with the following information
SEQUENCE {
alertId INTEGER
alertData
}
(1) alertId number of type INTEGER, set to 1
than the previously generated alertId. If this
the first alert generated, the value is
to 1. This value should wrap (reset) to 1 when
reaches 2**32. Note that the maximum log
cannot exceed (2**32)-1 entries
(2) a copy of the alert encapsulated in an OPAQUE
(c) The new log element is added to the table.
addition of the element exceed the defined maximum
Steinberg [Page 10]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
table size, the oldest element in the table (having
lowest alertId) is replaced by the new element
(d) A manager may poll the managed agent for either the
alert in the alert_table, or for a copy of the
associated with a specific alertId. A poll request
indicate a specific alertId. The mechanism for
this information from a table is protocol specific,
might use an SNMP GET or GET NEXT (with GET
following an instance of zero returning the first
entry's alert) or CMOT's GET with scoping and
to get alertData entries associated with alertId'
greater or less than a given instance
(e) An alertData GET request from a manager must always
responded to with a reply of the entire OPAQUE
(SNMP TRAP, CMOT EVENT, etc.) or a protocol
reply indicating that the get request failed
Note that the actual contents of the alert string,
the format of those contents, are protocol specific
(f) Once an alert is logged in the local log, it is up
the individual architecture and implementation
or not to also send a copy asynchronously to
manager. Doing so could be used to redirect the
of the polling (rather than waiting an average of 1/2
the poll cycle to learn of a problem), but does
result in significant problems should the alert fail
be delivered
(g) Should a manager request an alert with alertId of 0,
the reply shall be the appropriate protocol
error response
(h) If a manager requests the alert immediately
the alert with alertId equal to 0, the reply will be
first alert (or alerts, depending on the protocol used
in the alert log
(i) A manager may remove a specific alert from the alert
by naming the alertId of that alert and issuing
protocol specific command (SET or DELETE). If no
alert exists, the operation is said to have failed
such failure is reported to the manager in a
specific manner
Steinberg [Page 11]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
6.1.1
In a sample system (based on the example in Appendix A), a
must monitor 40 remote agents, each having between 2 and 15
parameters which indicate the relative health of the agent and
network. During normal monitoring, the manager is concerned
with fault detection. With an average poll request-response time
5 seconds, the manager polls one MIB variable on each node.
involves one request and one reply packet of the format specified
the XYZ network management protocol. Each packet requires 120
"on the wire" (requesting a single object, ASN.1 encoded, IP and
enveloped, and placed in an ethernet packet). This results in
serial poll cycle time of 3.3 minutes (40 nodes at 5 seconds each
200 seconds), and a mean time to detect alert of slightly over 1.5
minutes. The total amount of data transferred during a 3.3
poll cycle is 9600 bytes (120 requests and 120 replies for each of 40
nodes). With such a small amount of network management traffic
minute, the poll rate might reasonably be doubled (assuming
network performance permits it). The result is 19200
transferred per cycle, and a mean time to detect failure of under 1
minute. Parallel polling obviously yields similar improvements
Should an alert be returned by a remote agent's log, the
notifies the operator and removes the element from the alert log
setting it with SNMP or deleting it with CMOT. Normal
detection procedures are then followed. Those SNMP implementers
prefer to not use SNMP SET for table entry deletes may always
their log as "read only". The fact that the manager made a
query (to the log) and was able to determine which, if any,
merited special attention essentially means that the status of
alert capable objects was monitored with a single request
Continuing the above example, should a remote entity fail to
to two successive poll attempts, the operator is notified that
agent is not reachable. The operator may then choose (if
equipped) to contact the agent through an alternate path (such
serial line IP over a dial up modem). Upon establishing such
connection, the manager may then retrieve the contents of the
log for a chronological map of the failure's alerts.
undelivered because of conditions that may no longer be present
still available for analysis
6.2 Notes on Polled, Logged
Polled, logged alert techniques allow the tracking of many
while actually monitoring only a single MIB object.
dramatically decreases the amount of network management data
must flow across the network to determine the status. By
Steinberg [Page 12]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
the number of requests needed to track multiple objects (to one),
poll cycle time is greatly improved. This allows a faster poll
(mean time to detect alert) with less overhead than would be
by pure polling
In addition, this technique scales well to large networks, as
concept of polling a single object to learn the status of many
itself well to hierarchies. A proxy manager may be polled to
if he has found any alerts in the logs of the agents he polls.
course, this scaling does not save on the mean time to learn of
alert (the cycle times of the manager and the proxy manager must
considered), but the amount of network management polling traffic
concentrated at lower levels. Only a small amount of such
need be passed over the network's "backbone"; that is the
generated by the request-response from the manager to the
managers
Note that it is best to return the oldest logged alert as the
table entry. This is the object most likely to be overwritten,
every attempt should be made ensure that the manager has seen it.
a system where log entries may be removed by the manager, the
will probably wish to attempt to keep all remote alert logs empty
reduce the number of alerts dropped or overwritten. In any case,
order in which table entries are returned is a function of the
mechanism, and is implementation and/or protocol specific
"Polled, logged alerts" offers all of the advantages inherent
polling (reliable detection of failures, reduced agent
with UDP, etc.), while minimizing the typical polling
(potentially shorter poll cycle time and reduced network
traffic).
Finally, alerts are not lost when an agent is isolated from
manager. When a connection is reestablished, a history of
that may no longer be in effect is available to the manager.
not a part of this document, it is worthwhile to note that this
log architecture can be employed to archive alert and
information on remote hosts. However, such non-local storage is
sufficient to meet the reliability requirements of "polled,
alerts".
Steinberg [Page 13]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
7. Compatibility with SNMP [4] and CMOT [3]
7.1 Closed Loop (Feedback) Alert
7.1.1 Use of Feedback with
At configuration time, an SNMP agent supporting Feedback/Pin
loaded with default values of "windowTime" and "maxAlerts-PerTime",
and "alertsEnabled" is set to TRUE. The manager issues an SNMP
to determine "maxAlertsPerTime" and "windowTime", and to verify
state of "alertsEnabled". Should the agent support setting
objects, the manager may choose to alter these values (via an
SET). The new values are calculated based upon known
resource limitations (e.g., the amount of packets the manager'
gateway can support) and the number of agents potentially
to this manager
Upon receipt of an "alertsDisabled" trap, a manager whose state
network are not overutilized immediately issues an SNMP SET to
"alertsEnabled" TRUE. Should an excessive number of "alertsDisabled
traps regularly occur, the manager might revisit the values
for implementing the Pin mechanism. Note that an overutilized
expects its manager to delay the resetting of "alertsEnabled".
As a part of each regular polling cycle, the manager includes a
REQUEST for the value of "alertsEnabled". If this value is FALSE,
is SET to TRUE, and the potential loss of traps (while it was FALSE
is noted
7.1.2 Use of Feedback with
The use of CMOT in implementing Feedback/Pin is essentially
to the use of SNMP. CMOT GET, SET, and EVENT replace their
counterparts
7.2 Polled, Logged
7.2.1 Use of Polled, Logged alerts with
As a part of regular polling, an SNMP manager using Polled,
alerts may issue a GET_NEXT Request
{ alertLog logTableEntry(1) alertId(1) 0 }. Returned is either
alertId of the first table entry or, if the table is empty, an
reply whose object is the "lexicographical successor" to the
log
Should an "alertId" be returned, the manager issues an SNMP
naming { alertLog logTableEntry(1) alertData(2) value } where "value
Steinberg [Page 14]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
is the alertId integer obtained from the previously described
NEXT. This returns the SNMP TRAP encapsulated within an OPAQUE
If the agent supports the deletion of table entries through
SETS, the manager may then issue a SET of { alertLog logTableEntry(1)
alertId(1) value } to remove the entry from the log. Otherwise,
next GET NEXT poll of this agent should request the first "alertId
following the instance of "value" rather than an instance of "0".
7.2.2 Use of Polled, Logged Alerts with
Using polled, logged alerts with CMOT is similar to using them
SNMP. In order to test for table entries, one uses a CMOT GET
specifies scoping to the alertLog. The request is for all
entries that have an alertId value greater than the last
alertId, or greater than zero if the table is normally kept empty
the manager. Should the agent support it, entries are removed with
CMOT DELETE, an object of alertLog.entry, and a
attribute of the alertId to remove
8. Multiple Manager
The conflicts between multiple managers with
administrative domains (generally found in larger networks) tend
be resolved in protocol specific manners. This document has
addressed them. However, real world demands require alert
techniques to function in such environments
Complex agents can clearly respond to different managers (or
in different "communities") with different reply values. This
feedback and polled, logged alerts to appear completely
to differing autonomous regions (each region sees its own value).
Differing feedback thresholds might exist, and feedback can
actively blocking alerts to one manager even after another
has reenabled its own alert reporting. All of this is transparent
an SNMP user if based on communities, or each manager can work with
different copy of the relevant MIB objects. Those implementing
might view these as multiple instances of the same feedback
(and allow one manager to query the state of another's
mechanism).
The same holds true for polled, logged alerts. One manager (
manager in a single community/region) can delete an alert from
view without affecting the view of another region's managers
Those preferring less complex agents will recognize the
to instrument proxy management. Alerts might be distributed from
manager based alert exploder which effectively implements
Steinberg [Page 15]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
and polled, logged alerts for its subscribers. Feedback
are set on each agent to the highest rate of any subscriber,
limited by the distributor. Logged alerts are deleted from the
at the proxy manager, and truly deleted at the agent only when
subscribers have so requested, or immediately deleted at the
with the first proxy request, and maintained as virtual entries
the proxy manager for the benefit of other subscribers
9.
While "polled, logged alerts" may be useful, they still have
limitation: the mean time to detect failures and alerts
linearly as networks grow in size (hierarchies offer
individual poll cycle times, but the mean detection time is the
of 1/2 of each cycle time). For this reason, it may be necessary
supplement asynchronous generation of alerts (and "polled,
alerts") with unrequested transmission of the alerts on very
networks
Whenever systems generate and asynchronously transmit alerts,
potential to overburden (over-inform) a management station exists
Mechanisms to protect a manager, such as the "Feedback/Pin
technique, risk losing potentially important information. Failure
implement asynchronous alerts increases the time for the manager
detect and react to a problem. Over-reporting may appear
critical (and likely) a problem than under-informing, but
potential for harm exists with unbounded alert generation
An ideal management system will generate alerts to notify
management station (or stations) of error conditions. However,
alerts must be self limiting with required positive feedback.
addition, the manager should periodically poll to ensure
to remote stations, and to retrieve copies of any alerts that
not delivered by the network
10.
[1] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International and Hughes LAN Systems,
1990.
[2] McCloghrie, K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1213,
LAN Systems, Inc., Performance Systems International, March 1991.
[3] Warrier, U., Besaw, L., LaBarre, L., and B. Handspicker, "
Management Information Services and Protocols for the
Steinberg [Page 16]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
(CMOT) and (CMIP)", RFC 1189, Netlabs, Hewlett-Packard, The
Corporation, Digital Equipment Corporation, October 1990.
[4] Case, J., Fedor, M., Schoffstall, M., and C. Davin, "
Network Management Protocol" RFC 1157, SNMP Research,
Systems International, Performance Systems International,
Laboratory for Computer Science, May 1990.
[5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
11.
This memo is the product of work by the members of the IETF Alert-
Working Group and other interested parties, whose efforts
gratefully acknowledged here
Amatzia Ben-Artzi Synoptics
Neal Bierbaum Vitalink Corp
Jeff Case University of Tennessee at
John Cook Chipcom Corp
James Davin
Mark Fedor Performance Systems International, Inc
Steven Hunter Lawrence Livermore National
Frank Kastenholz Clearpoint
Lee LaBarre Mitre Corp
Bruce Laird BBN,
Gary Malkin FTP Software, Inc
Keith McCloghrie Hughes Lan
David Niemi Contel Federal
Lee Oattes University of
Joel Replogle
Jim Sheridan IBM Corp
Steve Waldbusser Carnegie-Mellon
Dan Wintringham Ohio Supercomputer
Rich Woundy IBM Corp
Appendix
Example of polling
The following example is completely hypothetical, and arbitrary
It assumes that a network manager has made decisions as to
systems, and which objects on each system, must be
monitored to determine the operational state of a network.
does not attempt to discuss how such decisions are made,
assumes that they were arrived at with the full understanding
the costs of polling many objects must be weighed against
Steinberg [Page 17]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
level of information required
Consider a manager that must monitor 40 gateways and hosts on
single network. Further assume that the average managed
has 10 MIB objects that must be watched to determine the device'
and network's overall "health". Under the XYZ network
protocol, the manager may get the values of up to 4 MIB
with a single request (so that 3 requests must be made
determine the status of a single entity). An average
time of 5 seconds is assumed, and a lack of response within 30
seconds is considered no reply. Two such "no replies" are
to declare the managed entity "unreachable", as a single
may occasionally be dropped in a UDP system (those preferring
use TCP for automated retransmits should assume a longer
value before declaring the entity "unreachable" which we
define as 60 seconds).
We begin with the case of "sequential polling". This is
as awaiting a response to an outstanding request before
any further requests. In this example, the average XYZ
management protocol packet size is 300 bytes "on the wire
(requesting multiple objects, ASN.1 encoded, IP and UDP enveloped
and placed in an ethernet packet). 120 request packets are
each cycle (3 for each of 40 nodes), and 120 response packets
expected. 72000 bytes (240 packets at 300 bytes each) must
transferred during each poll cycle, merely to determine that
network is fine
At five seconds per transaction, it could take up to 10 minutes
determine the state of a failing machine (40 systems x 3
each x 5 seconds per request). The mean time to detect a
with errors is 1/2 of the poll cycle time, or 5 minutes. In
failing network, dropped packets (that must be timed out
resent) greatly increase the mean and worst case times to
problems
Note that the traffic costs could be substantially reduced
combining each set of three request/response packets in a
request/response transaction (see section 6.1.1 "Example").
While the bandwidth use is spread over 10 minutes (giving a
of 120 bytes/second), this rapidly deteriorates should the
decrease his poll cycle time to accommodate more machines
improve his mean time to fault detection. Conversely,
his delay between polls reduces traffic flow, but does so at
expense of time to detect problems
Many network managers allow multiple poll requests to be "pending
Steinberg [Page 18]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
at any given time. It is assumed that such managers would
normally poll every machine without any delays.
"parallel polling" and initiating a new request
following any response would tend to generate larger amounts
traffic; "parallel polling" here produces 40 times the amount
network traffic generated in the simplistic case of "
polling" (40 packets are sent and 40 replies received every 5
seconds, giving 80 packets x 300 bytes each per 5 seconds, or 4800
bytes/second). Mean time to detect errors drops, but at the
of increased bandwidth. This does not improve the timeout
of over 2 minutes to detect that a node is not responding
Even with parallel polling, increasing the device count (
to manage) not only results in more traffic, but can
performance. On large networks the manager becomes bounded by
number of queries that can be built, tracked, responses parsed
and reacted to per second. The continuous volume requires
timeout value to be increased to accommodate responses that
still in transit or have been received and are queued
processing. The only alternative is to reduce the poll cycle
Either of these actions increase both mean time to detect
and worst case time to detect problems
If alerts are sent in place of polling, mean time to
detection drops from over a minute to as little as 2.5
(1/2 the time for a single request-response transaction).
time may be increased slightly, depending on the nature of
problem. Typical network utilization is zero (assuming
"typical" case of a non-failing system).
Appendix
All defined MIB objects used in this document
under the mib subtree
alertMan ::= { iso(1) org(3) dod(6) internet(1)
experimental(3) alertMan(24) ver1(1) }
as defined in the Internet SMI [1] and the latest "
Numbers" RFC [5]. Objects under this branch are
as follows
RFC 1224-MIB DEFINITIONS ::=
alertMan OBJECT IDENTIFIER ::= { experimental 24 }
ver1 OBJECT IDENTIFIER ::= { alertMan 1 }
Steinberg [Page 19]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
feedback OBJECT IDENTIFIER ::= { ver1 1 }
polledLogged OBJECT IDENTIFIER ::= { ver1 2 }
1) Feedback
OBJECT
------
maxAlertsPerTime { feedback 1 }
Syntax
Access
read-
Status
OBJECT
------
windowTime { feedback 2 }
Syntax
Access
read-
Status
OBJECT
------
alertsEnabled { feedback 3 }
Syntax
Access
read-
Status
Steinberg [Page 20]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
2) Polled, Logged
OBJECT
------
alertLog { polledLogged 1 }
Syntax
SEQUENCE OF
Access
read-
Status
OBJECT
------
logTableEntry { alertLog 1 }
Syntax
logTableEntry ::= SEQUENCE {
INTEGER
}
Access
read-
Status
OBJECT
------
alertId { logTableEntry 1 }
Syntax
Steinberg [Page 21]
RFC 1224 Managing Asynchronously Generated Alerts May 1991
Access
read-
Status
OBJECT
------
alertData { logTableEntry 2 }
Syntax
Access
read-
Status
OBJECT
------
maxLogTableEntries { polledLogged 2 }
Syntax
Access
read-
Status
Security
Security issues are not discussed in this memo
Author's
Lou
IBM NSFNET Software
472 Wheelers Farms Rd, m/s 91
Milford, Ct. 06460
Phone: 203-783-7175
EMail: LOUISS@IBM.
Steinberg [Page 22]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
