Network Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Informational Jari Arkko 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 , 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]