rfc1224.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      Lee LaBarre                Mitre Corp.
      Bruce Laird                BBN, Inc
      Gary Malkin                FTP Software, Inc.
      Keith McCloghrie           Hughes Lan Systems
      David Niemi                Contel Federal Systems
      Lee Oattes                 University of Toronto
      Joel Replogle              NCSA
      Jim Sheridan               IBM Corp.
      Steve Waldbusser           Carnegie-Mellon University
      Dan Wintringham            Ohio Supercomputer Center
      Rich Woundy                IBM Corp.

Appendix A

   Example of polling costs

      The following example is completely hypothetical, and arbitrary.
      It assumes that a network manager has made decisions as to which
      systems, and which objects on each system, must be continuously
      monitored to determine the operational state of a network.  It
      does not attempt to discuss how such decisions are made, and
      assumes that they were arrived at with the full understanding that
      the costs of polling many objects must be weighed against the



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 a
      single network.  Further assume that the average managed entity
      has 10 MIB objects that must be watched to determine the device's
      and network's overall "health".  Under the XYZ network management
      protocol, the manager may get the values of up to 4 MIB objects
      with a single request (so that 3 requests must be made to
      determine the status of a single entity).  An average response
      time of 5 seconds is assumed, and a lack of response within 30
      seconds is considered no reply.  Two such "no replies" are needed
      to declare the managed entity "unreachable", as a single packet
      may occasionally be dropped in a UDP system (those preferring to
      use TCP for automated retransmits should assume a longer timeout
      value before declaring the entity "unreachable" which we will
      define as 60 seconds).

      We begin with the case of "sequential polling".  This is defined
      as awaiting a response to an outstanding request before issuing
      any further requests.  In this example, the average XYZ network
      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 sent
      each cycle (3 for each of 40 nodes), and 120 response packets are
      expected.  72000 bytes (240 packets at 300 bytes each) must be
      transferred during each poll cycle, merely to determine that the
      network is fine.

      At five seconds per transaction, it could take up to 10 minutes to
      determine the state of a failing machine (40 systems x 3 requests
      each x 5 seconds per request).  The mean time to detect a system
      with errors is 1/2 of the poll cycle time, or 5 minutes.  In a
      failing network, dropped packets (that must be timed out and
      resent) greatly increase the mean and worst case times to detect
      problems.

      Note that the traffic costs could be substantially reduced by
      combining each set of three request/response packets in a single
      request/response transaction (see section 6.1.1 "Example").

      While the bandwidth use is spread over 10 minutes (giving a usage
      of 120 bytes/second), this rapidly deteriorates should the manager
      decrease his poll cycle time to accommodate more machines or
      improve his mean time to fault detection.  Conversely, increasing
      his delay between polls reduces traffic flow, but does so at the
      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 not
      normally poll every machine without any delays.  Allowing
      "parallel polling" and initiating a new request immediately
      following any response would tend to generate larger amounts of
      traffic; "parallel polling" here produces 40 times the amount of
      network traffic generated in the simplistic case of "sequential
      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 cost
      of increased bandwidth.  This does not improve the timeout value
      of over 2 minutes to detect that a node is not responding.

      Even with parallel polling, increasing the device count (systems
      to manage) not only results in more traffic, but can degrade
      performance.  On large networks the manager becomes bounded by the
      number of queries that can be built, tracked, responses parsed,
      and reacted to per second.  The continuous volume requires the
      timeout value to be increased to accommodate responses that are
      still in transit or have been received and are queued awaiting
      processing.  The only alternative is to reduce the poll cycle.
      Either of these actions increase both mean time to detect failure
      and worst case time to detect problems.

      If alerts are sent in place of polling, mean time to fault
      detection drops from over a minute to as little as 2.5 seconds
      (1/2 the time for a single request-response transaction).  This
      time may be increased slightly, depending on the nature of the
      problem.  Typical network utilization is zero (assuming a
      "typical" case of a non-failing system).

Appendix B

              All defined MIB objects used in this document reside
              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 "Assigned
              Numbers" RFC [5]. Objects under this branch are assigned
              as follows:

              RFC 1224-MIB DEFINITIONS ::= BEGIN

              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 }

              END


              1) Feedback Objects

                 OBJECT:
                 ------

                 maxAlertsPerTime { feedback 1 }

                 Syntax:
                    Integer

                 Access:
                    read-write

                 Status:
                    mandatory

                 OBJECT:
                 ------

                 windowTime { feedback 2 }

                 Syntax:
                    Integer

                 Access:
                    read-write

                 Status:
                    mandatory

                 OBJECT:
                 ------

                 alertsEnabled { feedback 3 }

                 Syntax:
                    Integer

                 Access:
                    read-write

                 Status:



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


                    mandatory


              2) Polled, Logged Objects

                 OBJECT:
                 ------

                 alertLog { polledLogged 1 }

                 Syntax:
                    SEQUENCE OF logTableEntry

                 Access:
                    read-write

                 Status:
                    mandatory

                 OBJECT:
                 ------

                 logTableEntry { alertLog 1 }

                 Syntax:

                    logTableEntry ::= SEQUENCE {

                       alertId
                          INTEGER,
                       alertData
                          OPAQUE
                    }

                 Access:
                    read-write

                 Status:
                    mandatory

                 OBJECT:
                 ------

                 alertId { logTableEntry 1 }

                 Syntax:
                    Integer




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


                 Access:
                    read-write

                 Status:
                    mandatory

                 OBJECT:
                 ------

                 alertData { logTableEntry 2 }

                 Syntax:
                    Opaque

                 Access:
                    read-only

                 Status:
                    mandatory

                 OBJECT:
                 ------

                 maxLogTableEntries { polledLogged 2 }

                 Syntax:
                    Integer

                 Access:
                    read-only

                 Status:
                    optional

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Lou Steinberg
   IBM NSFNET Software Development
   472 Wheelers Farms Rd, m/s 91
   Milford, Ct. 06460

   Phone:     [phone]
   EMail:     [e-mail]




Steinberg                                                      [Page 22]