rfc1224.txt

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

   mechanisms described in this memo, implementation of several MIB
   objects is required in the relevant managed systems.  The location of
   these objects in the MIB is under an experimental subtree delegated
   to the Alert-Man working group of the Internet Engineering Task Force
   (IETF) and published in the "Assigned Numbers" RFC [5].  Currently,
   this subtree is defined as

         alertMan ::= { experimental 24 }.

4.  Compatibility With Existing Network Management Protocols

   It is the intent of this document to suggest mechanisms that violate
   neither the letter nor the spirit of the protocols expressed in CMOT
   [3] and SNMP [4].  To achieve this goal, each mechanism described
   will give an example of its conformant use with both SNMP and CMOT.

5.  Closed Loop "Feedback" Alert Reporting with a "Pin" Sliding
    Window Limit

   One technique for preventing an excess of alerts from being delivered
   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 transmitting
   alerts at a high rate.  A sliding window "pin" threshold (so named
   for the metal on the end of a meter) is established as a part of a



Steinberg                                                       [Page 6]

RFC 1224        Managing Asynchronously Generated Alerts        May 1991


   user-defined SNMP trap, or as a managed CMOT event.  This threshold
   defines the maximum allowable number of alerts ("maxAlertsPerTime")
   that may be transmitted by the agent, and the "windowTime" in seconds
   that alerts are tested against.  Note that "maxAlertsPerTime"
   represents the sum total of all alerts generated by the agent, and is
   not duplicated for each type of alert that an agent might generate.
   Both "maxAlertsPerTime" and "windowTime" are required MIB objects of
   SMI [1] type INTEGER, must be readable, and may be writable should
   the implementation permit it.

   Two other items are required for the feedback technique.  The first
   is a Boolean MIB object (SMI type is INTEGER, but it is treated as a
   Boolean whose only value is zero, i.e., "FALSE") named
   "alertsEnabled", which must have read and write access.  The second
   is a user defined alert named "alertsDisabled".  Please see Appendix
   B for their complete definitions.

5.1  Use of Feedback

   When an excess of alerts is being generated, as determined by the
   total number of alerts exceeding "maxAlertsPerTime" within
   "windowTime" seconds, the agent sets the Boolean value of
   "alertsEnabled" to "FALSE" and sends a single alert of type
   "alertsDisabled".

   Again, the pin mechanism operates on the sum total of all alerts
   generated by the remote system.  Feedback is implemented once per
   agent and not separately for each type of alert in each agent.  While
   it is also possible to implement the Feedback/Pin technique on a per
   alert-type basis, such a discussion belongs in a document dealing
   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 of
           "alertsEnabled" is set to "TRUE".

      (b)  Each time an alert is generated, the value of
           "alertsEnabled" is tested.  Should the value be "FALSE",
           no alert is sent.  If the value is "TRUE", the alert is
           sent and the current time is stored locally.

      (c)  If at least "maxAlertsPerTime" have been generated, the
           agent calculates the difference of time stored for the
           new alert from the time associated with alert generated
           "maxAlertsPerTime" previously.  Should this amount be
           less than "windowTime", a single alert of the type
           "alertsDisabled" is sent to the manager and the value of



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" back
           to "TRUE" to continue to receive alert reports.

5.1.1  Example

   In a sample system, the maximum number of alerts any single managed
   entity may send the manager is 10 in any 3 second interval.  A
   circular buffer with a maximum depth of 10 time of day elements is
   defined to accommodate statistics keeping.

   After the first 10 alerts have been sent, the managed entity tests
   the time difference between its oldest and newest alerts.  By testing
   the time for a fixed number of alerts, the system will never disable
   itself merely because a few alerts were transmitted back to back.

   The mechanism will disable reporting only after at least 10 alerts
   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 maintains
   data on the last 10 alerts only.

5.2  Notes on Feedback/Pin Usage

   A manager may periodically poll "alertsEnabled" in case an
   "alertsDisabled" alert is not delivered by the network.  Some
   implementers may also choose to add COUNTER MIB objects to show the
   total number of alerts transmitted and dropped by "alertsEnabled"
   being FALSE.  While these may yield some indication of the number of
   lost alerts, the use of "Polled, Logged Alerts" offers a superset of
   this function.

   Testing the alert frequency need not begin until a minimum number of
   alerts have been sent (the circular buffer is full).  Even then, the
   actual test is the elapsed time to get a fixed number of alerts and
   not the number of alerts in a given time period.  This eliminates the
   need for complex averaging schemes (keeping current alerts per second
   as a frequency and redetermining the current value based on the
   previous value and the time of a new alert).  Also eliminated is the
   problem of two back to back alerts; they may indeed appear to be a
   large number of alerts per second, but the fact remains that there
   are only two alerts.  This situation is unlikely to cause a problem
   for any manager, and should not trigger the mechanism.

   Since alerts are supposed to be generated infrequently, maintaining
   the pin and testing the threshold should not impact normal
   performance of the agent (managed entity).  While repeated testing



Steinberg                                                       [Page 8]

RFC 1224        Managing Asynchronously Generated Alerts        May 1991


   may affect performance when an excess of alerts are being
   transmitted, this effect would be minor compared to the cost of
   generating and sending so many alerts.  Long before the cost of
   testing (in CPU cycles) becomes relatively high, the feedback
   mechanism should disable alert sending and affect savings both in
   alert sending and its own testing (note that the list maintenance and
   testing mechanisms disable themselves when they disable alert
   reporting).  In addition, testing the value of "alertsEnabled" can
   limit the CPU burden of building alerts that do not need to be sent.

   It is advised that the implementer consider allowing write access to
   both the window size and the number of alerts allowed in a window's
   time.  In doing so, a management station has the option of varying
   these parameters remotely before setting "alertsEnabled" to "TRUE".
   Should either of these objects be set to 0, a conformant system will
   disable the pin and feedback mechanisms and allow the agent to send
   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 exercise
   care that the alerts tested do not occur so frequently as to impact
   the performance of the agent's primary function.

   The user may prefer to send alerts via TCP to help ensure delivery of
   the "alerts disabled" message, if available.

   The feedback technique is effective for preventing the over-reporting
   of alerts to a manager.  It does not assist with the problem of
   "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 set
   sufficiently high that "alertsEnabled" is only set to "FALSE" during
   "over-reporting" situations.  To help prevent alerts from possibly
   being lost when the threshold is exceeded, this method can be
   combined with "polled, logged alerts" (see below).

6.  Polled, Logged Alerts

   A simple system that combines the request-response advantages of
   polling while minimizing the disadvantages is "Polled, Logged
   Alerts".  Through the addition of several MIB objects, one gains a
   system that minimizes network management traffic, lends itself to
   scaling, eliminates the reliance on delivery, and imposes no
   potential over-reporting problems inherent in pure alert driven
   architectures.  Minimizing network management traffic is affected by
   reducing multiple requests to a single request.  This technique does
   not eliminate the need for polling, but reduces the amount of data



Steinberg                                                       [Page 9]

RFC 1224        Managing Asynchronously Generated Alerts        May 1991


   transferred and ensures the manager either alert delivery or
   notification of an unreachable node.  Note again, the goal is to
   address the needs of information (alert) flow and not to control the
   local generation of alerts.

6.1  Use of Polled, Logged Alerts

   As alerts are generated by a remote managed entity, they are logged
   locally in a table.  The manager may then poll a single MIB object to
   determine if any number of alerts have been generated.  Each poll
   request returns a copy of an "unacknowledged" alert from the alert
   log, or an indication that the table is empty.  Upon receipt, the
   manager might "acknowledge" any alert to remove it from the log.
   Entries in the table must be readable, and can optionally allow the
   user to remove them by writing to or deleting them.

   This technique requires several additional MIB objects.  The
   alert_log is a SEQUENCE OF logTable entries that must be readable,
   and can optionally have a mechanism to remove entries (e.g., SNMP set
   or CMOT delete).  An optional read-only MIB object of type INTEGER,
   "maxLogTableEntries" gives the maximum number of log entries the
   system will support.  Please see Appendix B for their complete
   definitions.

   The typical use of Polled, Logged Alerts is detailed below.

      (a)  Upon initialization, the agent builds a pointer to a log
           table.  The table is empty (a sequence of zero entries).

      (b)  Each time a local alert is generated, a logTable entry
           is built with the following information:

      SEQUENCE {
                 alertId          INTEGER,
                 alertData        OPAQUE
           }

           (1) alertId number of type INTEGER, set to 1 greater
               than the previously generated alertId.  If this is
               the first alert generated, the value is initialized
               to 1.  This value should wrap (reset) to 1 when it
               reaches 2**32.  Note that the maximum log depth
               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.  Should
           addition of the element exceed the defined maximum log



Steinberg                                                      [Page 10]

RFC 1224        Managing Asynchronously Generated Alerts        May 1991


           table size, the oldest element in the table (having the
           lowest alertId) is replaced by the new element.

      (d)  A manager may poll the managed agent for either the next
           alert in the alert_table, or for a copy of the alert
           associated with a specific alertId.  A poll request must
           indicate a specific alertId. The mechanism for obtaining
           this information from a table is protocol specific, and
           might use an SNMP GET or GET NEXT (with GET NEXT
           following an instance of zero returning the first table
           entry's alert) or CMOT's GET with scoping and filtering
           to get alertData entries associated with alertId's
           greater or less than a given instance.

      (e)  An alertData GET request from a manager must always be
           responded to with a reply of the entire OPAQUE alert
           (SNMP TRAP, CMOT EVENT, etc.) or a protocol specific
           reply indicating that the get request failed.

           Note that the actual contents of the alert string, and
           the format of those contents, are protocol specific.

      (f)  Once an alert is logged in the local log, it is up to
           the individual architecture and implementation whether
           or not to also send a copy asynchronously to the
           manager.  Doing so could be used to redirect the focus
           of the polling (rather than waiting an average of 1/2
           the poll cycle to learn of a problem), but does not
           result in significant problems should the alert fail to
           be delivered.

      (g)  Should a manager request an alert with alertId of 0,
           the reply shall be the appropriate protocol specific
           error response.

      (h)  If a manager requests the alert immediately following
           the alert with alertId equal to 0, the reply will be the
           first alert (or alerts, depending on the protocol used)
           in the alert log.

      (i)  A manager may remove a specific alert from the alert log
           by naming the alertId of that alert and issuing a
           protocol specific command (SET or DELETE).  If no such
           alert exists, the operation is said to have failed and
           such failure is reported to the manager in a protocol
           specific manner.





Steinberg                                                      [Page 11]