Network Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Informational Jari Arkko
<draft-aboba-acct-00.txt> Ericsson
6 August 1998
Introduction to Accounting Management
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
aboba-acct-00.txt>, and expires February 1, 1999 Please send comments
to the authors.
2. Abstract
The field of Accounting Management is concerned with the collection of
resource consumption data for the purposes of capacity and trend anal-
ysis, cost allocation, auditing, and billing. This document describes
the problems encountered in Accounting Management, as well as some of
the issues encountered in the design of accounting systems. It also
reviews the state of current practice.
Aboba & Arkko [Page 1]
INTERNET-DRAFT 6 August 1998
3. Table of Contents
1. Status of this Memo
2. Abstract
3. Table of Contents
4. Introduction
4.1 Terminology
4.2 Accounting management architecture
4.3 Accounting management objectives
4.4 Intra-domain and inter-domain accounting
5. Scaling and reliability properties of accounting systems
5.1 Resource consumption
5.2 Fault resilience
5.3 Data collection models
6. Review of current practice
6.1 Accounting protocols
6.2 Accounting data transfer protocols
7. Acknowledgements
8. References
9. Authors' Addresses
Aboba & Arkko [Page 2]
INTERNET-DRAFT 6 August 1998
4. Introduction
The field of Accounting Management is concerned with the collection of
resource consumption data for the purposes of capacity and trend anal-
ysis, cost allocation, auditing, and billing. This document describes
each of these problems, and discusses the issues involved in design of
modern accounting systems.
4.1. Terminology
This document frequently uses the following terms:
Accounting
The act of collecting information on resource usage for the
purpose of trend analysis, auditing, billing, or cost allo-
cation.
Rating The act of determining the price to be charged for use of a
resource.
Billing The act of preparing an invoice.
Auditing The act of verifying the correctness of a procedure.
Cost Allocation
The act of allocating costs between entities. Note that cost
allocation and rating are fundamentally different processes.
Interim accounting
An interim accounting packet provides a snapshot of usage
during a user's session. It is typically implemented in
order to provide for partial accounting of a user's session
in the event of a device reboot or other network problem
that prevents the reception of a session summary packet or
session record.
Session record
A session record represents a summary of the resource con-
sumption of a user over the entire session. Accounting gate-
ways creating the session record may do so by processing
interim accounting events.
Accounting Protocol
A protocol used to convey data for accounting purposes.
Intra-domain accounting
Intra-domain accounting involves the collection of informa-
tion on resource within an administrative domain, for use
within that domain. In intra-domain accounting, accounting
packets and session records typically do not cross adminis-
trative boundaries.
Aboba & Arkko [Page 3]
INTERNET-DRAFT 6 August 1998
Inter-domain accounting
Inter-domain accounting involves the collection of informa-
tion on resource usage of an entity with an administrative
domain, for use within another administrative domain. In
inter-domain accounting, accounting packets and session
records will typically cross administrative boundaries.
Real-time accounting
Real-time accounting involves the processing of information
on resource usage within a defined time window. Time con-
straints are typically imposed in order to limit financial
risk.
Accounting server
The accounting server receives accounting data from devices
and translates it into session records. The accounting
server may also take responsibility for the routing of ses-
sion records to interested parties.
4.2. Accounting management architecture
Accounting management requires that accounting metrics be measured,
rated, assigned, and communicated between appropriate parties.
The accounting management architecture involves interactions between
network devices, accounting servers, and billing servers. The network
device collects resource consumption data in the form of accounting
metrics. This information is then transferred to an accounting server.
Typically this is accomplished via an accounting protocol, although it
is also possible for devices to generate session records.
The accounting server then processes the accounting data received from
the network device. This processing may include summarization of
interim accounting information, elimination of duplicate data, or gen-
eration of session records.
The processed accounting data is then submitted to a billing server,
which typically handles rating and invoice generation, but may also
carry out auditing, cost allocation, trend analysis or capacity plan-
ning functions. Session records may be batched and compressed by the
accounting server prior to submission to the billing server in order
to reduce the volume of accounting data and the bandwidth required to
accomplish the transfer.
One of the functions of the accounting server is to distinguish
between the inter and intra-domain accounting events and to route them
appropriately. Intra-domain accounting events are typically routed to
the local billing server, while inter-domain accounting events will be
routed to accounting servers operating within other administrative
domains. While it is not required that session record formats used in
inter and intra-domain accounting transfers be the same, this is
highly desirable, since this eliminates translations that would other-
wise be required.
Aboba & Arkko [Page 4]
INTERNET-DRAFT 6 August 1998
The diagram below illustrates a typical accounting architecture:
+------------+
| |
| Network |
| Device |
| |
| |
+------------+
|
Accounting |
Protocol |
|
|
|
|
|
V
+------------+ +------------+
| | | |
| Org B | Inter-domain | Org A |
| Acctg. |<----------------------------->| Acctg. |
| Server | session records | Server |
| | | |
| | | |
+------------+ +------------+
| |
| |
| Intra-domain |
| session records |
Transfer | |
Protocol | |
| |
| |
V V
+------------+ +------------+
| | | |
| Org B | | Org A |
| Billing | | Billing |
| Server | | Server |
| | | |
+------------+ +------------+
4.3. Accounting management objectives
Accounting Management involves the collection of resource consumption
data for the purposes of capacity and trend analysis, cost allocation,
auditing, and billing. Since each of these tasks have different relia-
bility and security requirements, it is worthwhile to discuss each
task in detail.
Aboba & Arkko [Page 5]
INTERNET-DRAFT 6 August 1998
4.3.1. Trend analysis and capacity planning
In trend analysis and capacity planning, the goal is typically a fore-
cast of future usage. Since such forecasts are inherently imperfect,
absolute reliability in accounting data collection is typically not
required. As a result moderate data loss can typically be tolerated
in such an application.
In certain cases, it may be desirable to use statistical sampling
techniques to reduce data collection requirements while still provid-
ing the forecast with the desired statistical accuracy. Such a sam-
pling process may be insensitive even to large amounts of packet loss
as long as bias is not introduced.
The security requirements for trend analysis and capacity planning
depend on the circumstances of data collection and the sensitivity of
the data. Generally, additional security services may be required
when data is being transferred between administrative domains. For
example, when information is being collected and analyzed within the
same administrative domain, integrity protection and authentication
may be used in order to guard against collection of invalid data. In
inter-domain applications confidentiality it may be desirable to add
confidentiality, to guard against snooping by third parties.
4.3.2. Billing
When accounting data is used for billing purposes, the requirements
differ based on whether the billing process requires information on
usage. A billing process that does not require usage information to
prepare an invoice can be said to be non-usage-sensitive.
Since by definition, non-usage-sensitive billing does not require
usage information, in theory all accounting data can be lost without
affecting the billing process. Of course wholesale data loss will
affect other tasks such as trend analysis or auditing, so that this
would still cause problems.
Since usage-sensitive billing processes depend on usage information,
packet loss may translate directly to revenue loss. As a result, the
billing process may need to meet requirements arising from financial
reporting standards, or legal requirements, and therefore an archival
approach may be required. In archival accounting, the goal is to col-
lect all accounting data, to reconstruct missing entries as best as
possible in the event of data loss, and to archive data for a mandated
time period, which is typically seven years.
Usage-sensitive systems may also have additional requirements relating
to processing delay. Today credit risk is commonly managed by comput-
erized fraud detection systems that are designed to detect unusual
activity. While transfer efficiency concerns might otherwise dictate
batched transmission of accounting data, where it is desirable to min-
imize financial risk, a different approach may be required.
Aboba & Arkko [Page 6]
INTERNET-DRAFT 6 August 1998
Since financial exposure increases with processing delay, it may be
necessary to transmit each event individually or to minimize batch
size, to require positive acknowledgment before providing service, or
even to utilize quality of service techniques to minimize queuing
delays.
The degree of financial exposure is application-dependent. For dialup
Internet access from a local provider, charges are low and therefore
the risk of loss is small. However, in the case of dialup roaming or
voice over IP, time-based charges may be substantial and therefore the
risk of fraud is larger. In such situations it is highly desirable to
quickly detect unusual account activity, and it may be desirable for
authentication to depend on ability to pay. In situations where valu-
able resources can be reserved, or where charges can be high, very
large bills may be rung up quickly, and therefore real-time processing
may be required.
In usage-sensitive systems, accounting data may result in monetary
transfers, and as a result, the security and reliability requirements
are greater. Thus security services such as authentication and
integrity protection are frequently used, and confidentiality and non-
repudiation may also be desirable.
4.3.3. Auditing
With enterprise networking expenditures on the rise, interest in
auditing is increasing. Auditing, which is the act of verifying the
correctness of a procedure, commonly relies on accounting data. Audit-
ing tasks include verifying correctness of an invoice submitted by a
service provider, or verification that usage is conforming to usage
policy, service level agreements, or security guidelines.
To permit a credible audit, the accounting data collection methods put
in place must be at least as reliable as those used by the invoicing
service provider. Similarly, security policies involved in auditing of
an invoice should be at least as stringent as those used in the origi-
nal calculation.
Where auditing procedures are used to verify conformance to usage or
security policies, security services may be desired. This typically
will include integrity protection and authentication of accounting
data, as well as confidentiality and possibly data object security. In
order to permit response to security incidents in progress, auditing
applications frequently are built to operate with low processing
delay.
4.3.4. Cost allocation
The application of cost allocation and billback methods by enterprise
customers is not yet widespread. However, with the convergence of
telephony and data communications, there is increasing interest in
applying cost allocation and billback procedures to networking costs,
Aboba & Arkko [Page 7]
INTERNET-DRAFT 6 August 1998
as is now commonly practiced with telecommunications costs.
Cost allocation models, including traditional costing mechanisms
described in [27]-[29] and activity-based costing techniques described
in [30] are typically based on detailed analysis of usage data, and as
a result they are almost always usage-sensitive. Whether cost alloca-
tion models are applied to allocation of costs between partners in a
venture or to allocation of costs between departments in a single
firm, cost allocation models often have profound behavioral and finan-
cial impacts. As a result, systems developed for this purposes are
typically as concerned with reliable data collection and security as
are billing applications.
4.4. Intra-domain and inter-domain accounting
Much of the early work on accounting management focused on intra-
domain accounting applications. However, with the increasing deploy-
ment of services such as dialup roaming, Internet fax, Internet tele-
phony and QoS, applications requiring inter-domain accounting are
becoming increasingly common.
Intra-domain accounting differs from intra-domain accounting in sev-
eral important ways. Intra-domain accounting involves the collection
of information on resource consumption within an administrative
domain, for use within that domain. In intra-domain accounting,
accounting packets and session records typically do not cross adminis-
trative boundaries. As a result, intra-domain accounting applications
typically experience low rates of packet loss.
In contrast, inter-domain accounting involves the collection of infor-
mation on resource consumption within an administrative domain, for
use within another administrative domain. In inter-domain accounting,
accounting packets and session records will typically cross adminis-
trative boundaries. As a result, inter-domain accounting applications
may experience substantial packet loss.
Since inter-domain accounting applications involve transfers of
accounting data between domains, additional security measures may be
desirable. In addition to authentication and integrity protection, it
may be desirable to deploy security services such as confidentiality,
replay protection or non-repudiation. In inter-domain accounting each
involved party also typically requires a copy of each accounting event
for invoice generation and auditing.
5. Scaling and reliability characteristics of accounting systems
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 vari-
ous data collection models.
Aboba & Arkko [Page 8]
INTERNET-DRAFT 6 August 1998
5.1. Resource consumption
In the process of growing to meet the needs of providers and cus-
tomers, accounting management systems consume a variety of resources,
including:
Network bandwidth
Memory/non-volatile storage on managed devices
State on the accounting management system
CPU on the management system and managed devices
In order to understand the limits to scaling of accounting management
systems, we examine each of these resources in turn.
5.1.1. Network bandwidth
Accounting management systems consume network bandwidth in the trans-
ferring of accounting data. The network bandwidth consumed is propor-
tional 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, network overhead
can represent a considerable proportion of total bandwidth consump-
tion. As a result, it is often desirable to transfer accounting data
in batches, enabling network overhead to be spread over a larger pay-
load, and enabling efficient use of compression.
5.1.2. Memory/non-volatile storage on managed devices
In accounting systems without non-volatile memory, accounting data
must be stored in 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 relia-
bility will typically wish to retry for long periods, the resulting
memory consumption can be considerable.
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 flash RAM declining rapidly, it is likely that network devices will
be capable of incorporating non-volatile storage within the next few
years.
5.1.3. State on the accounting management system
In order to keep track of received accounting data, accounting manage-
ment 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.
Aboba & Arkko [Page 9]
INTERNET-DRAFT 6 August 1998
5.1.4. 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 mod-
erate CPU resources. In the event that devices are over-taxed by
accounting tasks, it is likely that overall device reliability will
suffer.
5.2. Fault resilience
Given the potential importance of accounting data, it is highly desir-
able for accounting systems to be resilient against a variety of
faults, including:
Packet loss
Accounting server failures
Network failures
Device reboots
This section discusses each of these failure modes in turn.
5.2.1. Packet loss
As packet loss is a fact of life on the Internet, accounting protocols
need to be resilient against such losses. Typically this is accom-
plished either via implementation of a retry mechanism on top of UDP,
or use of TCP.
5.2.2. Accounting server failures
In the event of an accounting server failure, it may not be possible
for a device to transmit accounting data to its primary accounting
server. For protocols using TCP, opening of a connection to the sec-
ondary accounting server can occur after a timeout or loss of the pri-
mary connection, or it can occur on expiration of a timer. For proto-
cols using UDP, transmission to the secondary server can occur after a
number of retries or timer expiration. In either case, it is possible
for the primary and secondary accounting servers to receive the same
record, so that elimination of duplicates is required.
Aboba & Arkko [Page 10]
INTERNET-DRAFT 6 August 1998
5.2.3. Network failures
Network failures may result in partial or complete loss of connectiv-
ity for the accounting client. In the event of partial connectivity
loss, it may not be possible to reach the primary accounting server,
in which case switchover to the secondary accounting server is neces-
sary. In the event of a network partition, it may be necessary to
store accounting events in device memory or non-volatile storage until
connectivity can be re-established.
The importance of non-volatile storage in design of reliable account-
ing systems should not be under-estimated. Without such storage,
event-driven systems will lose data once the transmission timeout has
been exceeded, and polling or event-driven batching designs will expe-
rience data loss once the internal memory used for event storage has
been exceeded. As a result, network access is not by itself a guaran-
tee of reliable data transfer, and for many years reliable accounting
systems were implemented based solely on physical storage, without any
need for network access. For example, 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.
5.2.4. Device reboots
In the event of a device reboot, it is desirable to minimize the loss
of data on sessions in progress. This can be accomplished via interim
accounting, with the interim accounting data being transferred over
the network or kpt in non-volatile storage.
5.3. Data collection models
Several data collection models are currently in use today for the pur-
poses of accounting data collection. These include:
Polling model
Event-driven model
Event-driven polling model
Interim accounting
5.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 strage, 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.
Aboba & Arkko [Page 11]
INTERNET-DRAFT 6 August 1998
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 pro-
cess. 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. In situations where operational difficulties are
encountered, the volume of accounting data will frequently increase so
as to make data loss more likely. However, in this case the polling
model will detect the problem since attempts to reach the managed
devices will fail.
Per-device state is typical of polling-based network management sys-
tems, which often also carry out accounting management functions,
since network management systems need to keep track of the state of
network devices for operational purposes.
5.3.2. Event-driven model
In the event-driven model, a device will contact the accounting server
or manager when it is ready to transfer accounting data. Most event-
driven accounting systems are based on RADIUS accounting, described in
[4], and transfer only one accounting event per packet, which is inef-
ficient.
Without non-volatile storage, a pure event-driven model only stores
individual accounting events that have not yet been delivered and as a
result it has the smallest memory requirements of any of the models.
However, the event-driven model is also the least reliable, since
accounting data loss will occur due to device reboots, sustained
packet loss, or network failures of duration greater than the timeout
interval. Since accounting servers will not receive events if opera-
tional difficulties are encountered, event-driven accounting systems
are not very useful in monitoring of device health.
Per-session state is typical of event-driven systems without batching,
and as a result, a pure event-driven approach is to be avoided wher-
ever possible.
5.3.3. Event-driven polling model
In the event-driven polling model an accounting manager will poll the
device for accounting data only when it receives an event. The event
can occur at regular time intervals, or when a batch of a given size
has been gathered or both. Note that while transfer efficiency will
increase with batch size, without non-volatile storage, the potential
data loss from a device reboot will also increase.
Aboba & Arkko [Page 12]
INTERNET-DRAFT 6 August 1998
Without non-volatile storage, an event-driven polling model will lose
data due to device reboots, but not due to sustained packet loss, or
network partitions of short-duration. Unless a minimum delivery
interval is set, event-driven polling systems are not useful in moni-
toring of device health.
Where batching can be implemented the state required in event-driven
polling can be reduced to scale with the number of active devices. If
portions of the network vary widely in usage, then this state may
actually be less than that of the polling approach.
5.3.4. Interim accounting
Interim accounting is in use both in RADIUS [31] and in TACACS+ [32].
It is typically implemented to improve accounting system reliability
and may be applied to either event-driven or polling systems. While
interim accounting can in theory be used to limit data loss due to
packet loss, short-duration network failures, or device reboot, its
applicability is limited by bandwidth consumption concerns. As a
result, interim accounting is most typically implemented in order to
avoid loss of long-duration sessions, and the interim interval is typ-
ically set 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 moderate.
However, as the interim accounting interval decreases toward the the
average session time, the additional bandwidth consumed by interim
accounting increases markedly, and as a result, the interval must be
set with caution. This practice is particularly suspect since it
increases use of network bandwidth in normal operation, while provid-
ing benefits only in the event of a fault. ,LP Given the decreasing
cost of non-volatile memory, it may be preferable to store interim
accounting data in non-volatile storage. Stored interim events are
then replaced by session data when the session completes, and the ses-
sion data can itself be erased once the data has been transmitted.
This approach avoids interim data being transmitted over the wire,
except in the case of a device reboot.
6. Review of current practice
Accounting systems have been successfully impelemented using protocols
such as RADIUS, TACACS+, SYSLOG and SNMP. This section describes the
characteristics of each of these protocols, as well as transfer proto-
cols such as HTTP, FTP, and SMTP.
6.1. Accounting protocols
Aboba & Arkko [Page 13]
INTERNET-DRAFT 6 August 1998
6.1.1. RADIUS
RADIUS accounting, described in [4], was developed as an add-on to the
RADIUS authentication protocol, described in [3]. As a result, RADIUS
accounting shares the event-driven approach of RADIUS authentication,
without support for batching or polling. As a result, RADIUS account-
ing scales with the number of accounting events instead of the number
of devices, and accounting transfers are inefficient. In addition,
since RADIUS accounting is based on UDP and timeout and retry parame-
ters are not specified, implementations vary widely in their approach
to reliability, with some implementations retrying until delivery or
buffer depletion, and others losing accounting data after a few
retries.
As a result, many RADIUS accounting implementations are sensitive to
packet loss or short-lived network partitions, and such deficiencies
are magnified further when RADIUS accounting is applied in inter-
domain accounting as is required in roaming, as noted in [1]. On the
other hand, the event-driven approach of RADIUS accounting is well
suited to handling of accounting events which require low processing
delay, such as is required for credit risk management or fraud detec-
tion.
While RADIUS accounting does provide hop-by-hop authentication and
integrity protection, hop-by-hop confidentiality or data object secu-
rity services are not supported, and thus systems based on RADIUS
accounting are not capable of being deployed with untrusted proxies,
as noted in [2].
While in principle extensible with the definition of new attributes,
RADIUS suffers from the very small standard attribute space (256
attributes).
6.1.2. TACACS+
TACACS+ as defined in [32] offers an accounting model with start,
stop, and interim update messages. Since TACACS+ is based on TCP,
implementations are typically resilient against packet loss and short-
lived network partitions. However, given the tradeoff between relia-
bility and delay, TACACS+ accounting is less suited to handling of
accounting events which require low processing delay.
TACACS+ provides for hop-by-hop authentication and integrity protec-
tion as well as hop-by-hop confidentiality. Data object security is
not supported, and therefore systems based on TACACS+ accounting are
not deployable in the presence of untrusted proxies.
6.1.3. SNMP
SNMP-based accounting systems, such as is described in [9] and [10]
have been successfully deployed in situations where sophisticated
security is not required and the overhead of ASN.1 encoding and
Aboba & Arkko [Page 14]
INTERNET-DRAFT 6 August 1998
decoding is not a concern. Since polling allows data to be collected
on multiple accounting events simultaneously, such systems can store
accounting data up to the limits of their memory or non-volatile stor-
age, improving scaling properties and enabling efficient transfers.
Since the management agent is able to retry requests when a response
is not received, such systems are resilient against packet loss or
even short-lived network partitions. Although with SNMP v2 it is also
possible to implement such systems using confirmed notifications, we
are not aware of any SNMP-based accounting systems that make use of
this facility. With SNMPv3, described in [12]-[14], SNMP-based
accounting systems will be capable of incorporating view-based access
controls, described in [16], as well as user-based security, described
in [15]. As a result, SNMP v3-based systems can provide for hop-by-hop
authentication and confidentiality services, in addition to access-
control. They cannot however provide data-object based security
required for deployment with untrusted proxies.
Where multiple administrative domains are involved, such as in the
shared use networks described in [1], more sophisticated access con-
trols are often required. Since in shared use networks the same device
may be accessed by multiple organizations, it is often necessary to
control access to accounting data according to the user's organiza-
tion. This ensures that organizations may be given access to account-
ing data relating to their users, but not to data relating to users of
other organizations. This implies that the view-based access control
described in [16] is not sufficient, since access rights will depend
not only on the element being collected, but on the identity of the
user to whom that data relates. As a result, shared-use networks rely-
ing on SNMP-based accounting have generally collected data for all
organizations and then sorted the resulting session records for deliv-
ery to each organization. While functional, this approach will typi-
cally result in increased processing delay.
6.1.4. DIAMETER
DIAMETER as defined in [33] - [35] is currently not used for account-
ing purposes and does not have accounting messages defined.
6.2. Accounting data transfer protocols
In order for session records to be transmitted between accounting
servers, a transfer protocol is required. Transfer protocols in use
today include SMTP, FTP, and HTTP.
6.2.1. SMTP-based accounting record transfer
Accounting systems using SMTP as an accounting data transfer mechanism
typically have access to substantial non-volatile storage. This allows
them to generate, compress if necessary, and store accounting records
Aboba & Arkko [Page 15]
INTERNET-DRAFT 6 August 1998
until they are transferred to the collection site. Using IPSEC, TLS
or Kerberos, hop-by-hop security services such as authentication,
integrity protection and confidentiality can be provided. As
described in [18] and [20], data object security is available for
SMTP, and in addition, the facilities described in [17] make it possi-
ble to request and receive signed receipts, which enables non-repudia-
tion as described in [17]-[23]. As a result, accounting systems uti-
lizing SMTP for accounting data transfer are capable of satisfying the
most demanding security rquirements.
6.2.2. Other transfer mechanisms
HTTP and FTP have also been used for accounting data transfer. Given
access to sufficient non-volatile storage, accounting systems based on
record formats and transfer protocols can avoid loss of data due to
long-duration network partitions or in even internal faults. Since it
is possible for the transfer to be driven from the collection site,
the collector can retry transfers until successful, or with HTTP may
even be able to restart partially completed transfers. As a result,
file transfer-based systems can be made highly reliable, and the
batching of accounting records makes possible efficient transfers and
application of required security services with lessened overhead.
However, such systems are not typically capable of providing low pro-
cessing delay, although this may be addressed by the enhancements
described in [26].
7. Acknowledgements
The authors would like to thank Pat Calhoun (Sun Microsystems), Jan
Melen (Ericsson), Jarmo Savolainen (Ericsson), and Glen Zorn
(Microsoft) for many useful discussions of this problem space.
8. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi-
ainfo, Merit, September 1997.
[2] B. Aboba, G. Zorn. "Roaming Requirements." Internet draft (work
in progress), draft-ietf-roamops-roamreq-07.txt, Microsoft, March
1998.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April,
1997.
[5] J. Gray, A. Reuter. Transaction Processing: Concepts and Tech-
niques, Morgan Kaufmann Publishers, San Francisco, California, 1993.
Aboba & Arkko [Page 16]
INTERNET-DRAFT 6 August 1998
[6] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.
[7] D. Crocker, P. Overrell. "Augmented BNF for Syntax Specifica-
tions: ABNF." RFC 2234, Internet Mail Consortium, Demon Internet
Ltd., November 1997.
[8] G. Good. "The LDAP Data Interchange Format (LDIF) - Technical
Specification." Internet draft (work in progress), draft-ietf-asid-
ldif-02.txt, Netscape, July 1997.
[9] K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. "Accounting
Information for ATM Networks." Internet draft (work in progress),
draft-ietf-atommib-atmacct-04.txt, Cisco Systems, Telecom Finland,
MCI, November 1996.
[10] K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. "Managed
Objects for Controlling the Collection and Storage of Accounting
Information for Connection-Oriented Networks." Internet draft (work
in progress), draft-ietf-atommib-acct-04.txt, Cisco Systems, Telecom
Finland, MCI, November 1996.
[11] B. Aboba, D. Lidyard. "Accounting Data Interchange Format
(ADIF)." Internet draft (work in progress), draft-ietf-roamops-
actng-04.txt, Microsoft, Telco Research, March 1998.
[12] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2271, Cabletron, BMC Soft-
ware, IBM, January 1998.
[13] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Message Process-
ing and Dispatching for the Simple Network Management Protocol
(SNMP)", RFC 2272, SNMP Research, Cabletron Systems, BMC Software,
IBM, January 1998.
[14] D. Levi, P. Meyer, B. Stewart, "SNMPv3 Applications", RFC 2273,
SNMP Research, Secure Computing Corporation, Cisco Systems, January
1998.
[15] U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
2274, IBM, January 1998.
[16] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control
Modem (VACM) for the Simple Network Management Protocol (SNMP)", RFC
2275, IBM, BMC Software, Cisco Systems, January 1998.
[17] R. Fajman. "An Extensible Message Format for Message Disposi-
tion Notifications." Internet draft (work in progress), draft-
ietf- receipt-mdn-08.txt, National Institute of Health, August 1998.
[18] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)."
RFC 2015, The Aerospace Corporation, October, 1996.
Aboba & Arkko [Page 17]
INTERNET-DRAFT 6 August 1998
[19] G. Vaudreuil. "The Multipart/Report Content Type for the Report-
ing of Mail System Administrative Messages." RFC 1892, Octel Network
Services, January, 1996.
[20] J. Galvin., et al. "Security Multiparts for MIME: Multi-
part/Signed and Multipart/Encrypted." RFC 1847, Trusted Information
Systems, October, 1995.
[21] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran-
denburg Consulting, March, 1995.
[22] C. Shih, M. Jansson, R. Drummond. "MIME-based Secure EDI."
Internet draft (work in progress), draft-ietf-ediint-
as1-05.txt, Actra, LiNK, Drummond Group, July 1997.
[23] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for
Inter-operable Internet EDI." Internet draft (work in progress),
draft-ietf-ediint-req-04.txt, Actra, LiNK, Drummond Group, July 1997.
[24] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.
[25] Borenstein, N., Freed, N. "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
December 1993.
[26] N. Joffe, D. Wing, L. Masinter. "SMTP Service Extension for Imme-
diate Delivery", Internet draft (work in progress), draft-ietf-fax-
smtp-session-02.txt, Cisco Systems, Xerox, February 1997.
[27] H. T. Johnson, R. S. Kaplan. Relevance Lost: The Rise and Fall of
Management Accounting, Harvard Business School Press, Boston, Mas-
sachusetts, 1987.
[28] C. T. Horngren, G. Foster. Cost Accounting: A Managerial Empha-
sis. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[29] R. S. Kaplan, Anthony A. Atkinson. Advanced Management Account-
ing. Prentice Hall, Englewood Cliffs, New Jersey, 1989.
[30] R. Cooper, R. S. Kaplan. The Design of Cost Management Systems.
Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[31] P. R. Calhoun, M. A. Beadles, A. Ratcliffe. "RADIUS Accounting
Interim Accounting Record Extension", Internet draft (work in
progress), draft-ietf-radius-acct-interim-00.txt, July 1997.
[32] D. Carrel, L. Grant. "The TACACS+ Protocool Version 1.78", Inter-
net draft (work in progress), draft-grant-tacacs-02.txt, Cisco Sys-
tems, January, 1997.
[33] P. R. Calhoun, A. Rubens. "DIAMETER Base Protocol", Internet
draft (work in progress), draft-calhoun-diameter-01.txt, Sun
Aboba & Arkko [Page 18]
INTERNET-DRAFT 6 August 1998
Microsystems, Merit Networks, March, 1998.
[34] P. R. Calhoun. "DIAMETER Resource Management Extensions", Inter-
net draft (work in progress), draft-calhoun-diameter-res-mgmt-00.txt,
Sun Microsystems, March, 1998.
[35] P. R. Calhoun. "DIAMETER User Authentication Extensions", Inter-
net draft (work in progress), draft-calhoun-diameter-authent-01.txt,
Sun Microsystems, March, 1998.
9. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: Jari.Arkko@ericsson.com
Aboba & Arkko [Page 19]
