📄 rfc2975.txt
字号:
modifications are allowed to an ongoing session. For example, it is
possible that a session could be re-authorized with improved QoS.
This would require production of accounting records at both QoS
levels.
These examples could be addressed by using vectors or multi-
dimensional arrays to represent resource consumption within a single
session record. For example, the vector or array could describe the
resource consumption for each combination of factors, e.g. one data
item could be the number of packets during peak hour in the area of
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -