ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track Dave Lidyard <draft-ietf-roamops-actng-07.txt> Telco Research Corporation 25 April 2000 The Accounting Data Interchange Format (ADIF) This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 2. Abstract This document describes an extensible human-readable accounting record format, the Accounting Data Interchange Format (ADIF). Based on MIME, ADIF is designed to compactly represent accounting data from any protocol using attribute/value pairs or object identifiers. While in many cases Accounting Servers will produce ADIF records based on data from accounting protocols, it is also possible for devices to store data in ADIF format and transfer ADIF records to the accounting server. The latter approach has the advantage of offloading the Accounting Server from the task of transcribing interim or session records, thus improving scalability. This approach also enables the transport of data from multiple sources within the same set of records. Where a record format is employed that supports batching, the transport of multiple records within the same accounting packet is enabled. Aboba & Lidyard Standards Track [Page 1]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 2.1. History -06 draft: added to terminology section. Fixed ABNF issues with respect to use of the space character. Added ability to support complex objects via numbered sub-attributes. Still needed: examples for protocols other than RADIUS, including SNMP, L2TP, LDAP and COPS. 3. Introduction This document describes an extensible human-readable accounting record format, the Accounting Data Interchange Format (ADIF). Based on MIME, ADIF is designed to compactly represent accounting data from any protocol using attribute/value pairs or object identifiers. While in many cases Accounting Servers will produce ADIF records based on data from accounting protocols, it is also possible for devices to store data in ADIF format and transfer ADIF records to the accounting server. The latter approach has the advantage of offloading the Accounting Server from the task of transcribing interim or session records, thus improving scalability. This approach also enables the transport of data from multiple sources within the same set of records. Where a record format is employed that supports batching, the transport of multiple records within the same accounting packet is enabled. 3.1. Terminology This document uses the following terms: Accounting The collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. Accounting management requires that resource consumption be measured, rated, assigned, and communicated between appropriate parties. Rating The act of determining the price to be charged for use of a resource. Billing The act of preparing an invoice. Archival accounting In archival accounting, the goal is to collect 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. It is "usual and customary" for these systems to be engineered to be very robust against accounting data loss. Legal or financial requirements frequently mandate archival accounting practices, and may often dictate that data be kept Aboba & Lidyard Standards Track [Page 2]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 confidential, regardless of whether it is to be used for billing purposes or not. Interim accounting An interim accounting packet provides a snapshot of usage during a user's session. This may be useful in the event of a device reboot or other network problem that prevents the reception or generation of a session summary packet or session record. Interim accounting packets can always be summarized without the loss of information. Session record A session record represents a summary of the resource consumption of a user over the entire session. Accounting gateways creating the session record may do so by processing interim accounting events or accounting events from several devices serving the same user. Accounting Protocol A protocol used to convey data for accounting purposes. 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 session records to interested parties. 4. Accounting record format requirements As detailed in [2], solution of the accounting problem in roaming requires a standardized accounting record format to enable exchange of accounting data between members of a roaming consortium. Since operational roaming services, described in [1], exhibit considerable diversity in their accounting implementations it is desirable that the chosen accounting record format be protocol-independent.Since accounting implementations are continually adding new attributes, extensibility is useful. For accounting session records, compactness of representation is a virtue. Session records can be stored within devices where memory or non-volatile storage is at a premium. Thus the compactness of the representation will determine how much data can be stored prior to experiencing data loss. To satisfy legal and regulatory requirements it has become customary to archive session records. Thus, the compactness of the representation will determine how much warehouse space is required to store the tapes or CD-ROMs of the archived data. In addition, where session records are transferred over the wire the compactness of representation will determine bandwidth consumption. For Aboba & Lidyard Standards Track [Page 3]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 all these reasons, smaller is better. It is also desirable that an accounting session records be human readable. Since the processing of accounting data may ultimately result in the transfer of funds, it is important that the software producing and handling session records be correct. Human readable accounting formats are considerably easier to implement and debug than binary formats and thus software based on them is more likely to be free of defects. In reviewing the current state of the art in accounting data representation, it was determined that existing approaches could not satisfy the requirements for generality, extensibility, compactness and human readability. For example, protocol-specific solutions such as the SNMP-oriented record format described in [10] do not offer sufficient flexibility in representing data from other protocols. They also have the disadvantage of not being human readable. Existing call detail records based on fixed record formats, while being human readable, do not offer the required extensibility. While XML is human readable as well as being very extensible and flexible, it is not compact. As a result, XML-based session records are likely to consume many times more storage space than a MIME-based approach. While compression techniques can be used to reduce the size of XML-based session records, the resulting compressed records are still larger than comparable compressed MIME-based records. As a result, it is to be expected that XML-based session records will suffer in terms of compactness. As a result of these considerations, it was decided to base ADIF on MIME, described in [11]. The use of MIME has enabled ADIF to represent both printable and non-printable characters as well as to allow representation of attributes of unlimited size. Through the use of attribute numbers and protocol defaults, it has been possible to produce an accounting record format that is simultaneously human readable, general, extensible, and compact. 4.1. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [5]. 5. Definition of the Accounting Data Interchange Format (ADIF) ADIF is based on MIME, described in [11] and consists of a header providing basic information about the records in the file, followed by a series of records each separated by a separator. Aboba & Lidyard Standards Track [Page 4]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 The header includes the ADIF version number (1 for this document), device name/description, and collection start date and time. A default protocol type may be optionally included in the header. Note that it is possible to use ADIF in a real-time accounting environment where individual records are transmitted by the device to the Accounting Server in ADIF format. In such a case it is up to the mechanism to specify whether ADIF headers are included within each record or are agreed to beforehand via some out-of-band mechanism. Each record may consist of one or more lines, and as with MIME, described in [11], lines may be continued by putting a space or tab character on the succeeding line, allowing attributes to be of arbitrary length. Lines beginning with the "#" character are taken as comments and ignored. Accounting records have traditionally been human-readable, so as to allow them to be more easily debugged. ADIF attributes can be expressed either in NVT ASCII (characters 32 through 126) or if non-printable characters are required, in base64. ADIF includes support for encoding of attributes for any protocol utilizing attribute/value pairs or object identifiers. This includes RADIUS, defined in [3] and [4], RTFM, defined in [14] and [15], L2TP, defined in [8] as well as SNMP, TACACS+ and COPS, defined in [16]. The protocol type is indicated by prepending the protocol keyword as defined by IANA and a "//" to the attribute number, i.e. radius//46. To improve compactness, when a default protocol is indicated in the header, attributes of the default protocol do not need to include the protocol type. For example, if defaultProtocol: rtfm is indicated in the ADIF header, then 32 may be used instead of rtfm//32. In order to allow for compact representation of object identifiers, the ADIF header allows the definition of oid-names that can be used in place of an object-identifier sub-tree. For example, the inclusion of a header statement: oid-define: mib-2=1.3.6.1.2.1; would permit the string "mib-2" to substitute for the sub-tree 1.3.6.1.2.1 wherever this occurred within the accounting record file. This would allow the OID 1.3.6.1.2.1.2 to be abbreviated as mib-2.2. Protocols such as L2TP, defined in [8] include additional fields such as Vendor ID and flags in their Attribute Value Pairs (AVPs). Protocols such as COPS, defined in [16] include attribute numbers expressed as a combination of C-Num and C-Type as well as supporting complex objects. To encode such AVPs, ADIF includes support for attribute numbers expressed in OID form, as well as sub-attributes. Aboba & Lidyard Standards Track [Page 5]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 Sub-attributes are included as additional fields, separated by a semi- colon, and are of the form <subattribute> = <value>. Sub-attributes used in complex objects are numbered starting from 1; letters are used for well-known sub-attributes. This document includes support for the following well-known sub-attributes: VendorId, VendorType, Mandatory and Hidden, which apply to all protocols. Other sub-attributes may be added as needed. Use of the VendorId and VendorType sub-attribute may be used for expression of vendor-specific attributes, such as those supported in RADIUS. As an example, the L2TP version number attribute (attribute 2) with the Mandatory bit set would be expressed as "l2tp//2: 1; M=1". A COPS In- Interface object (C-Num=3, C-Type=1, including an IPv4 address of 204.57.137.2 and an interface index of 1) would be expressed as "cops//3.1: 1=204.57.137.2; 2=1" 5.1. ADIF Examples Example 1: An ADIF file encoding RADIUS accounting data version: 1 device: server3 description: Accounting Server 3 date: 02 Mar 1999 12:19:01 -0500 defaultProtocol: radius rdate: 02 Mar 1999 12:20:17 -0500 #NAS-IP-Address 4: 204.45.34.12 #NAS-Port 5: 12 #NAS-Port-Type 61: 2 #User-Name 1: fred@bigco.com #Acct-Status-Type 40: 2 #Acct-Delay-Time 41: 14 #Acct-Input-Octets 42: 234732 #Acct-Output-Octets 43: 15439 #Acct-Session-Id 44: 185 #Acct-Authentic 45: 1 #Acct-Session-Time Aboba & Lidyard Standards Track [Page 6]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 46: 1238 #Acct-Input-Packets 47: 153 #Acct-Output-Packets 48: 148 #Acct-Terminate-Cause 49: 11 #Acct-Multi-Session-Id 50: 73 #Acct-Link-Count 51: 2 Example 2: An ADIF file encoding RADIUS data with a vendor-specific attribute version: 1 device: server3 description: Accounting Server 3 date: 02 Mar 1998 12:19:01 -0500 defaultProtocol: radius rdate: 02 Mar 1998 12:25:23 -0500 4: 204.45.34.12 5: 12 61: 2 1: fred@bigco.com #Vendor-Specific 26: 2; VID=301; VT=22 40: 2 41: 14 42: 234732 43: 15439 44: 185 45: 1 46: 1238 47: 153 48: 148 49: 11 50: 73 51: 2 5.2. Grammar The following definition uses the ABNF specified in [6]: adif-file = header-spec *SEP 1*( SEP adif-record ) header-spec = required-info SEP [optional-info SEP] Aboba & Lidyard Standards Track [Page 7]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 required-info = device-spec SEP start-spec SEP optional-info = [version-spec SEP ] [description SEP] [def-protocol SEP] [oid-def-spec SEP ] device-spec = "device:" *SP value description = "description:" *SP value oid-def-spec = "oid-define:" *SP 1*(oid-name "=" oid-num ";") def-protocol = "defaultProtocol:" *SP protocol protocol = <protocol keyword, defined by IANA> version-spec = "version:" *SP number number = 1*Digit ; number MUST be "1" for the ; ADIF format described in this document start-spec = "date:" *SP datetime datetime = date SP time date = Dd SP Mon SP YYYY time = hh ":" mm ":" ss SP zone Dd = <the one or two decimal integer day of the month in the range 1 to 31.> Mon = "JAN" / "FEB" / "MAR" / "APR" / "MAY" / "JUN" / "JUL" / "AUG" / "SEP" / "OCT" / "NOV" / "DEC" YYYY = <the four decimal integer year in the range 0000 to 9999> hh = <the two decimal integer hour of the day in the range 00 to 24> mm = <the two decimal integer minute of the hour in the range 00 to 59> ss = <the two decimal integer second of the minute in the range 00 to 59> zone = <A four digit, signed time zone offset, such as -0600 for US Eastern Standard Time. This may be supplemented by a time zone name in parentheses, e.g., "-0800 (PDT)"> adif-record = 1*(attrval-series SEP) attrval-series = [rdate-spec SEP] 1*(attrval-spec) rdate-spec = "rdate:" *SP datetime ; date at which accounting data was received attrval-spec = attr ( (std-encoding / base-64-encoding) [sub-attr-encoding]) comment = ("#" *safe) std-encoding = (":" *SP value ) base-64-encoding = ("::" *SP base64-value ) base64-value = <base-64-encoded value, defined in [11]> sub-attr-encoding = *(";" sub-attr "=" <value>) sub-attr = "M" / "H" / "VID" / "VT" / Digit ; Mandatory, Hidden, Vendor ID, Vendor Type ; well known sub-attributes or digit attr = [protocol "//"] attribute-number attribute-number = number / oid oid = [ oid-name "." ] oid-num oid-name = Alpha *(ldh-str) oid-num = *(number "." ) number Aboba & Lidyard Standards Track [Page 8]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 value = 1*safe-initval *safe safe = <ASCII values 040 - 0176 octal (32 - 126 decimal), excluding semi-colon (";", ASCII 59 decimal) safe-initval = <ASCII values 040 - 0176 octal (32 - 126 decimal), excluding colon (":", ASCII 58 decimal), SP, and semi-colon (";", ASCII 59 decimal) SP = %x20 ; Space character SEP = (CR LF) / LF CR = <ASCII CR, carriage return> LF = <ASCII LF, line feed> ldh-str = *( Alpha / Digit / "-" ) let-dig let-dig = Alpha / Digit Alpha = %x41-5A / %x61-7A ; A-Z / a-z Digit = %x30-39 ;0-9 6. References [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [3] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [4] Rigney C., "RADIUS Accounting", RFC 2139, April 1997. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Crocker, D., and P. Overrell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [7] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700, October 1994. [8] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999. [9] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting Information for ATM Networks", RFC 2512, February 1999. [10] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed Objects for Controlling the Collection and Storage of Accounting Aboba & Lidyard Standards Track [Page 9]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 Information for Connection-Oriented Networks", RFC 2513, February 1999. [11] 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. [12] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [13] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting Background", RFC 1272, November 1991. [14] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow Measurement: Architecture", RFC 2063, January 1997. [15] Brownlee, N., "Traffic Flow Measurement: Meter MIB", Measurement: Architecture", RFC 2064, January 1997. [16] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. 7. Security Considerations Since accounting data may include sensitive information, it may be desirable for this information to be kept confidential during transmission. Several mechanisms may be used to accomplish this, including IPSEC, described in [12]. 8. IANA Considerations This draft creates two new name spaces that will need to be administered by IANA, namely the ADIF protocol name and attribute number spaces. In order to avoid creating any new administrative procedures, administration of the ADIF protocol name space will piggy-back on the allocation of IP protocol and UDP/TCP port numbers. Administration of the ADIF attribute number space will piggy-back on administration of the attribute numbers or object identifiers for the protocol in question. ADIF protocol names are required to be unique, and are created coincident with allocation of an IP protocol number or UDP/TCP port number. In applying for a protocol number or UDP/TCP port, a unique keyword is assigned to the protocol, and this keyword is used as the ADIF protocol name. Aboba & Lidyard Standards Track [Page 10]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 Those wishing to use an ADIF protocol name should first acquire the rights to use the corresponding protocol or port number. Using an ADIF protocol name without first obtaining rights to a protocol or port number creates the possibility of conflict and therefore is to be discouraged. Similarly, ADIF attribute numbers are allocated coincident with IANA allocation of attribute numbers or object identifiers for a given protocol. 9. Acknowledgments Thanks to Glen Zorn of Cisco Systems, Jari Arkko of Ericsson, David Franscone and Pat Calhoun of Sun Microsystems, Thomas Narten of IBM, and Ryan Moats of AT&T for useful discussions of this problem space. 10. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com Dave Lidyard Telco Research Corporation 616 Marriott Drive Nashville, TN 37214 Phone: 615-231-6110 EMail: dave@telcores.com 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Aboba & Lidyard Standards Track [Page 11]
INTERNET-DRAFT The Accounting Data Interchange Format 25 April 2000 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12. Expiration Date This memo is filed as <draft-ietf-roamops-actng-07.txt>, and expires November 1, 2000. Aboba & Lidyard Standards Track [Page 12]
