rfc2975.txt

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

   the home operator.  However, such an approach seems complicated and
   inflexible and as a result, most current systems produce a set of
   records from one session.  A session identifier needs to be present
   in the records to permit accounting systems to tie the records
   together.

   In most cases, the network device will determine when multiple
   session records are needed, as the local device is aware of factors
   affecting local tariffs, such as QoS changes and roaming.  However,
   future systems are being designed that enable the home domain to



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


   control the generation of accounting records.  This is of importance
   in inter-domain accounting or when network devices do not have tariff
   information.  The centralized control of accounting record production
   can be realized, for instance, by having authorization servers
   require re-authorization at certain times and requiring the
   production of accounting records upon each re-authorization.

   In conclusion, in some cases it is necessary to produce multiple
   accounting records from a single session.  It must be possible to do
   this without requiring the user to start a new session or to re-
   authenticate.  The production of multiple records can be controlled
   either by the network device or by the AAA server.  The requirements
   for timeliness, security and reliability in multiple record sessions
   are the same as for single-record sessions.





































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


1.7.  Requirements summary

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 |                     |                   |
   |  Usage          |   Intra-domain      | Inter-domain      |
   |                 |                     |                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 | Robustness vs.      | Robustness vs.    |
   |                 | packet loss         | packet loss       |
   |  Capacity       |                     |                   |
   |  Planning       | Integrity,          | Integrity,        |
   |                 | authentication,     | authentication,   |
   |                 | replay protection   | replay prot.      |
   |                 | [confidentiality]   | confidentiality   |
   |                 |                     | [data object sec.]|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Non-usage      | Integrity,          | Integrity,        |
   |  Sensitive      | authentication,     | authentication,   |
   |  Billing        | replay protection   | replay protection |
   |                 | [confidentiality]   | confidentiality   |
   |                 |                     | [data object sec.]|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 | Archival            | Archival          |
   |  Usage          | accounting          | accounting        |
   |  Sensitive      | Integrity,          | Integrity,        |
   |  Billing,       | authentication,     | authentication,   |
   |  Cost           | replay protection   | replay prot.      |
   |  Allocation &   | [confidentiality]   | confidentiality   |
   |  Auditing       | [Bounds on          | [data object sec.]|
   |                 |  processing delay]  | [Bounds on        |
   |                 |                     | processing delay] |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 | Archival            | Archival          |
   |  Time           | accounting          | accounting        |
   |  Sensitive      | Integrity,          | Integrity,        |
   |  Billing,       | authentication,     | authentication,   |
   |  fraud          | replay protection   | replay prot.      |
   |  detection,     | [confidentiality]   | confidentiality   |
   |  roaming        |                     | [Data object      |
   |                 | Bounds on           |  security and     |
   |                 |  processing delay   |  receipt support] |
   |                 |                     | Bounds on         |
   |                 |                     |  processing delay |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Key
   [] = optional




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


2.  Scaling and reliability

   With the continuing growth of the Internet, it is important that
   accounting management systems be scalable and reliable.  This section
   discusses the resources consumed by accounting management systems as
   well as the scalability and reliability properties exhibited by
   various data collection and transport models.

2.1.  Fault resilience

   As noted earlier, in applications such as usage-sensitive billing,
   cost allocation and auditing, an archival approach to accounting is
   frequently mandated, due to financial and legal requirements.  Since
   in such situations loss of accounting data can translate to revenue
   loss, there is incentive to engineer a high degree of fault
   resilience.  Faults which may be encountered include:

      Packet loss
      Accounting server failures
      Network failures
      Device reboots

   To date, much of the debate on accounting reliability has focused on
   resilience against packet loss and the differences between UDP, SCTP
   and TCP-based transport.  However, it should be understood that
   resilience against packet loss is only  one aspect of meeting
   archival accounting requirements.

   As noted in [18], "once the cable is cut you don't need more
   retransmissions, you need a *lot* more voltage."  Thus, the choice of
   transport has no impact on resilience against faults such as network
   partition, accounting server failures or device reboots.  What does
   provide resilience against these faults is non-volatile storage.

   The importance of non-volatile storage in design of reliable
   accounting systems cannot be over-emphasized.  Without non-volatile
   storage, event-driven systems will lose data once the transmission
   timeout has been exceeded, and batching designs will experience data
   loss once the internal memory used for accounting data storage has
   been exceeded.  Via use of non-volatile storage, and internally
   stored interim records, most of these data losses can be avoided.

   It may even be argued that non-volatile storage is more important to
   accounting reliability than network connectivity, since for many
   years reliable accounting systems were implemented based solely on
   physical storage, without any network connectivity.  For example,





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


   phone usage data used to be stored on paper, film, or magnetic media
   and carried from the place of collection to a central location for
   bill processing.

2.1.1.  Interim accounting

   Interim accounting provides protection against loss of session
   summary data by providing checkpoint information that can be used to
   reconstruct the session record in the event that the session summary
   information is lost.  This technique may be applied to any data
   collection model (i.e. event-driven or polling) and is supported in
   both RADIUS [25] and in TACACS+.

   While interim accounting can provide resilience against packet loss,
   server failures, short-duration network failures, or device reboot,
   its applicability is limited.  Transmission of interim accounting
   data over the wire should not be thought of as a mainstream
   reliability improvement technique since it increases use of network
   bandwidth in normal operation, while providing benefits only in the
   event of a fault.

   Since most packet loss on the Internet is due to congestion, sending
   interim accounting data over the wire can make the problem worse by
   increasing bandwidth usage.  Therefore on-the-wire interim accounting
   is best restricted to high-value accounting data such as information
   on long-lived sessions.  To protect against loss of data on such
   sessions, the interim reporting interval is typically set several
   standard deviations larger than the average session duration.  This
   ensures that most sessions will not result in generation of interim
   accounting events and the additional bandwidth consumed by interim
   accounting will be limited.  However, as the interim accounting
   interval decreases toward the average session time, the additional
   bandwidth consumed by interim accounting increases markedly, and as a
   result, the interval must be set with caution.

   Where non-volatile storage is unavailable, interim accounting can
   also result in excessive consumption of memory that could be better
   allocated to storage of session data.  As a result, implementors
   should be careful to ensure that new interim accounting data
   overwrites previous data rather than accumulating additional interim
   records in memory, thereby worsening the buffer exhaustion problem.

   Given the increasing popularity of non-volatile storage for use in
   consumer devices such as digital cameras, such devices are rapidly
   declining in price.  This makes it increasingly feasible for network
   devices to include built-in support for non-volatile storage.  This
   can be accomplished, for example, by support for compact PCMCIA
   cards.



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


   Where non-volatile storage is available, this can be used to store
   interim accounting data.  Stored interim events are then replaced by
   updated interim events or by session data when the session completes.
   The session data can itself be erased once the data has been
   transmitted and acknowledged at the application layer.  This approach
   avoids interim data being transmitted over the wire except in the
   case of a device reboot.  When a device reboots, internally stored
   interim records are transferred to the accounting server.

2.1.2.  Multiple record sessions

   Generation of multiple accounting records within a session can
   introduce scalability problems that cannot be controlled using the
   techniques available in interim accounting.

   For example, in the case of interim records kept in non-volatile
   storage, it is possible to overwrite previous interim records with
   the most recent one or summarize them to a session record.  Where
   interim updates are sent over the wire, it is possible to control
   bandwidth usage by adjusting the interim accounting interval.

   These measures are not applicable where multiple session records are
   produced from a single session, since these records cannot be
   summarized or overwritten without loss of information.  As a result,
   multiple record production can result in increased consumption of
   bandwidth and memory.  Implementors should be careful to ensure that
   worst-case multiple record processing requirements do not exceed the
   capabilities of their systems.

   As an example, a tariff change at a particular time of day could, if
   implemented carelessly, create a sudden peak in the consumption of
   memory and bandwidth as the records need to be stored and/or
   transported.  Rather than attempting to send all of the records at
   once, it may be desirable to keep them in non-volatile storage and
   send all of the related records together in a batch when the session
   completes.  It may also be desirable to shape the accounting traffic
   flow so as to reduce the peak bandwidth consumption.  This can be
   accomplished by introduction of a randomized delay interval.  If the
   home domain can also control the generation of multiple accounting
   records, the estimation of the worst-case processing requirements can
   be very difficult.

2.1.3.  Packet loss

   As packet loss is a fact of life on the Internet, accounting
   protocols dealing with session data need to be resilient against
   packet loss.  This is particularly important in inter-domain
   accounting, where packets often pass through Network Access Points



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


   (NAPs) where packet loss may be substantial.  Resilience against
   packet loss can be accomplished via implementation of a retry
   mechanism on top of UDP, or use of TCP [7] or SCTP [26].  On-the-wire
   interim accounting provides only limited benefits in mitigating the