rfc1224.txt

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

Network Working Group                                       L. Steinberg
Request for Comments: 1224                               IBM Corporation
                                                                May 1991



        Techniques for Managing Asynchronously Generated Alerts

Status of this Memo

   This memo defines common mechanisms for managing asynchronously
   produced alerts in a manner consistent with current network
   management protocols.

   This memo specifies an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This RFC explores mechanisms to prevent a remotely managed entity
   from burdening a manager or network with an unexpected amount of
   network management information, and to ensure delivery of "important"
   information.  The focus is on controlling the flow of asynchronously
   generated information, and not how the information is generated.

Table of Contents

   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" Sliding
      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.  Introduction

   This memo defines mechanisms to prevent a remotely managed entity
   from burdening a manager or network with an unexpected amount of
   network management information, and to ensure delivery of "important"
   information.  The focus is on controlling the flow of asynchronously
   generated information, and not how the information is generated.
   Mechanisms for generating and controlling the generation of
   asynchronous information may involve protocol specific issues.

   There are two understood mechanisms for transferring network
   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 a
   manager that is not the result of a specific query.  Advantages and
   disadvantages exist within each method.  They are detailed in section
   2 below.

   Alerts in a failing system can be generated so rapidly that they
   adversely impact functioning resources.  They may also fail to be
   delivered, and critical information maybe lost.  Methods are needed
   both to limit the volume of alert transmission and to assist in
   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 asynchronously
   generating alerts should attempt to adopt mechanisms that fill both
   of these needs.  For reasons shown in section 2.4, it is necessary to
   fulfill both alert-management requirements.  A complete alert-driven
   system must ensure that alerts are delivered or their loss detected
   with a means to recreate the lost information, AND it must not allow
   itself to overburden its manager with an unreasonable amount of
   information.

2.  Problem Definition

   The following discusses the relative advantages and disadvantages of
   polled vs. alert driven management.

2.1  Polling Advantages

   (a) Reliable detection of failures.

          A manager that polls for all of its information can
          more readily determine machine and network failures;
          a lack of a response to a query indicates problems
          with the machine or network.   A manager relying on
          notification of problems might assume that a faulty
          system is good, should the alert be unable to reach
          its destination, or the managed system be unable to
          correctly generate the alert.  Examples of this
          include network failures (in which an isolated network
          cannot deliver the alert), and power failures (in which
          a failing machine cannot generate an alert).  More
          subtle forms of failure in the managed entity might
          produce an incorrectly generated alert, or no alert at
          all.

   (b) Reduced protocol complexity on managed entity

          The use of a request-response based system is based on
          conservative assumptions about the underlying transport
          protocol.  Timeouts and retransmits (re-requests) can
          be built into the manager.  In addition, this allows
          the manager to affect the amount of network management
          information flowing across the network directly.

   (c) Reduced performance impact on managed entity

          In a purely polled system, there is no danger of having
          to often test for an alert condition.  This testing
          takes CPU cycles away from the real mission of the
          managed entity.  Clearly, testing a threshold on each



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


          packet received could have unwanted performance effects
          on machines such as gateways.  Those who wish to use
          thresholds and alerts must choose the parameters to be
          tested with great care, and should be strongly
          discouraged from updating statistics and checking values
          frequently.

   (d) Reduced Configuration Requirements to manage remote
          entity

          Remote, managed entities need not be configured
          with one or more destinations for reporting information.
          Instead, the entity merely responds to whomever
          makes a specific request.  When changing the network
          configuration, there is never a need to reconfigure
          all remote manageable systems.  In addition, any number
          of "authorized" managers (i.e., those passing any
          authentication tests imposed by the network management
          protocol) may obtain information from any managed entity.
          This occurs without reconfiguring the entity and
          without reaching an entity-imposed limit on the maximum
          number of potential managers.

2.2  Polling Disadvantages

   (a) Response time for problem detection

          Having to poll many MIB [2] variables per machine on
          a large number of machines is itself a real
          problem.  The ability of a manager to monitor
          such a system is limited; should a system fail
          shortly after being polled there may be a significant
          delay before it is polled again.  During this time,
          the manager must assume that a failing system is
          acceptable.  See Appendix A for a hypothetical
          example of such a system.

          It is worthwhile to note that while improving the mean
          time to detect failures might not greatly improve the
          time to correct the failure, the problem will generally
          not be repaired until it is detected.  In addition,
          most network managers would prefer to at least detect
          faults before network users start phoning in.

   (b) Volume of network management traffic

          Polling many objects (MIB variables) on many machines
          greatly increases the amount of network management



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 use
          of hierarchies (polling a machine for a general status
          of all the machines it polls), this aggravates the
          response time problem previously discussed.

2.3  Alert Advantages

   (a) Real-time Knowledge of Problems

          Allowing the manager to be notified of problems
          eliminates the delay imposed by polling many objects/
          systems in a loop.

   (b) Minimal amount of Network Management Traffic

          Alerts are transmitted only due to detected errors.
          By removing the need to transfer large amounts of status
          information that merely demonstrate a healthy system,
          network and system (machine processor) resources may be
          freed to accomplish their primary mission.

2.4  Alert Disadvantages

   (a) Potential Loss of Critical Information

          Alerts are most likely not to be delivered when the
          managed entity fails (power supply fails) or the
          network experiences problems (saturated or isolated).
          It is important to remember that failing machines and
          networks cannot be trusted to inform a manager that
          they are failing.

   (b) Potential to Over-inform the Manager

          An "open loop" system in which the flow of alerts to
          a manager is fully asynchronous can result in an excess
          of alerts being delivered (e.g., link up/down messages
          when lines vacillate).  This information places an extra
          burden on a strained network, and could prevent the
          manager from disabling the mechanism generating the
          alerts; all available network bandwidth into the manager
          could be saturated with incoming alerts.

   Most major network management systems strive to use an optimal
   combination of alerts and polling.  Doing so preserves the advantages
   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 Memo

   This memo suggests mechanisms to minimize the disadvantages of alert
   usage.  An optimal system recognizes the potential problems
   associated with sending too many alerts in which a manager becomes
   ineffective at managing, and not adequately using alerts (especially
   given the volumes of data that must be actively monitored with poor
   scaling).  It is the author's belief that this is best done by
   allowing alert mechanisms that "close down" automatically when over-
   delivering asynchronous (unexpected) alerts, and that also allow a
   flow of synchronous alert information through a polled log.  The use
   of "feedback" (with a sliding window "pin") discussed in section 5
   addresses the former need, while the discussion in section 6 on
   "polled, logged alerts" does the latter.

   This memo does not attempt to define mechanisms for controlling the
   asynchronous generation of alerts, as such matters deal with
   specifics of the management protocol.  In addition, no attempt is
   made to define what the content of an alert should be.  The feedback
   mechanism does require the addition of a single alert type, but this
   is not meant to impact or influence the techniques for generating any
   other alert (and can itself be generated from a MIB object or the
   management protocol).  To make any effective use of the alert