rfc2975.txt

RFC 的详细文档！

   devices do not implement non-volatile storage and the accounting
   protocol lacks transport and application layer reliability, locating
   the accounting proxy (with its stable storage) close to the device
   can reduce the risk of data loss.

   However, such systems are inherently unreliable so that they are only
   appropriate for use in capacity planning or non-usage sensitive
   billing applications.  If archival accounting reliability is desired,
   it is necessary to engineer a reliable accounting system from the
   start using the techniques described in this document, rather than
   attempting to patch an inherently unreliable system by adding store
   and forward accounting proxies.

































Aboba, et al.                Informational                     [Page 22]

RFC 2975         Introduction to Accounting Management      October 2000


2.1.9.  Fault resilience summary

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Fault          |   Counter-measures                    |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Packet         |   Retransmission based on RTT         |
   |  loss           |   Congestion control                  |
   |                 |   Well-defined timeout behavior       |
   |                 |   Duplicate elimination               |
   |                 |   Interim accounting*                 |
   |                 |   Non-volatile storage                |
   |                 |   Cumulative variables                |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Accounting     |   Primary-secondary servers           |
   |  server & net   |   Duplicate elimination               |
   |  failures       |   Interim accounting*                 |
   |                 |   Application layer ACK & error msgs. |
   |                 |   Non-volatile storage                |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Device         |   Interim accounting*                 |
   |  reboots        |   Non-volatile storage                |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Key
   * = limited usefulness without non-volatile storage

   Note: Accounting proxies are not a reliability
   enhancement mechanism.

2.2.  Resource consumption

   In the process of growing to meet the needs of providers and
   customers, accounting management systems consume a variety of
   resources, including:

      Network bandwidth
      Memory
      Non-volatile storage
      State on the accounting management system
      CPU on the management system and managed devices



Aboba, et al.                Informational                     [Page 23]

RFC 2975         Introduction to Accounting Management      October 2000


   In order to understand the limits to scaling, we examine each of
   these resources in turn.

2.2.1.  Network bandwidth

   Accounting management systems consume network bandwidth in
   transferring accounting data.  The network bandwidth consumed is
   proportional to the amount of data transferred, as well as required
   network overhead.  Since accounting data for a given event may be 100
   octets or less, if each event is transferred individually, overhead
   can represent a considerable proportion of total bandwidth
   consumption.  As a result, it is often desirable to transfer
   accounting data in batches, enabling network overhead to be spread
   over a larger payload, and enabling efficient use of compression.  As
   noted in [48], compression can be enabled in the accounting protocol,
   or can be done at the IP layer as described in [5].

2.2.2.  Memory

   In accounting systems without non-volatile storage, accounting data
   must be stored in volatile memory during the period between when it
   is generated and when it is transferred.  The resulting memory
   consumption will depend on retry and retransmission algorithms.
   Since systems designed for high reliability will typically wish to
   retry for long periods, or may store interim accounting data, the
   resulting memory consumption can be considerable.  As a result, if
   non-volatile storage is unavailable, it may be desirable to compress
   accounting data awaiting transmission.

   As noted earlier, implementors of interim accounting should take care
   to ensure against excessive memory usage by overwriting older interim
   accounting data with newer data for the same session rather than
   accumulating interim data in the buffer.

2.2.3.  Non-volatile storage

   Since accounting data stored in memory will typically be lost in the
   event of a device reboot or a timeout, it may be desirable to provide
   non-volatile storage for undelivered accounting data.  With the costs
   of non-volatile storage declining rapidly, network devices will be
   increasingly capable of incorporating non-volatile storage support
   over the next few years.

   Non-volatile storage may be used to store interim or session records.
   As with memory utilization, interim accounting overwrite is desirable
   so as to prevent excessive storage consumption.  Note that the use of
   ASCII data representation enables use of highly efficient text
   compression algorithms that can minimize storage requirements.  Such



Aboba, et al.                Informational                     [Page 24]

RFC 2975         Introduction to Accounting Management      October 2000


   compression algorithms are only typically applied to session records
   so as to enable implementation of interim data overwrite.

2.2.4.  State on the accounting management system

   In order to keep track of received accounting data, accounting
   management systems may need to keep state on managed devices or
   concurrent sessions.  Since the number of devices is typically much
   smaller than the number of concurrent sessions, it is desirable to
   keep only per-device state if possible.

2.2.5.  CPU requirements

   CPU consumption of the managed and managing nodes will be
   proportional to the complexity of the required accounting processing.
   Operations such as ASN.1 encoding and decoding,
   compression/decompression, and encryption/decryption can consume
   considerable resources, both on accounting clients and servers.

   The effect of these operations on accounting system reliability
   should not be under-estimated, particularly in the case of devices
   with moderate CPU resources.  In the event that devices are over-
   taxed by accounting tasks, it is likely that overall device
   reliability will suffer.



























Aboba, et al.                Informational                     [Page 25]

RFC 2975         Introduction to Accounting Management      October 2000


2.2.6.  Efficiency measures

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Resource       |   Efficiency measures                 |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Network        |   Batching                            |
   |  Bandwidth      |   Compression                         |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Memory         |   Compression                         |
   |                 |   Interim accounting overwrite        |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  Non-volatile   |   Compression                         |
   |  Storage        |   Interim accounting overwrite        |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  System         |   Per-device state                    |
   |  state          |                                       |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                                       |
   |  CPU            |   Hardware assisted                   |
   |  requirements   |     compression/encryption            |
   |                 |                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3. Data collection models

   Several data collection models are currently in use today for the
   purposes of accounting data collection.  These include:

      Polling model
      Event-driven model without batching
      Event-driven model with batching
      Event-driven polling model









Aboba, et al.                Informational                     [Page 26]

RFC 2975         Introduction to Accounting Management      October 2000


2.3.1.  Polling model

   In the polling model, an accounting manager will poll devices for
   accounting information at regular intervals.  In order to ensure
   against loss of data, the polling interval will need to be shorter
   than the maximum time that accounting data can be stored on the
   polled device.  For devices without non-volatile stage, this is
   typically determined by available memory; for devices with non-
   volatile storage the maximum polling interval is determined by the
   size of non-volatile storage.

   The polling model results in an accumulation of data within
   individual devices, and as a result, data is typically transferred to
   the accounting manager in a batch, resulting in an efficient transfer
   process.  In terms of Accounting Manager state, polling systems scale
   with the number of managed devices, and system bandwidth usage scales
   with the amount of data transferred.

   Without non-volatile storage, the polling model results in loss of
   accounting data due to device reboots, but not due to packet loss or
   network failures of sufficiently short duration to be handled within
   available memory.  This is becaus