ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track Dave Lidyard Telco Research Corporation 2 March 1998 The Accounting Data Interchange Format (ADIF) 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 ds.internic.net (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 September 1, 1998. Please send comments to the authors. 2. Abstract This document proposes a standard accounting record format, the Accounting Data Interchange Format (ADIF), which is designed to com- pactly represent accounting data in a protocol-independent manner. As a result, ADIF may be used to represent accounting data from a wide variety of protocols. 3. Introduction As detailed in [2], solution of the accounting problem in roaming requires a standardized accounting record format. Since there is no standards-track accounting protocol, the operational roaming services described in [1] exhibit considerable diversity in their accounting implementations. In order to be able to cope with this diversity, it is desirable that a standardized accounting record format be protocol-independent. As a result, protocol-specific solutions such as the SNMP-oriented record format described in [10] do not offer sufficient flexibility. Aboba & Lidyard [Page 1] INTERNET-DRAFT 2 March 1998 This document proposes a standard accounting record format, based on MIME, described in [11], and resembling the LDAP Data Interchange For- mat (LDIF), described in [8]. 3.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: 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 information collected for account- ing purposes. Intra-domain accounting Intra-domain accounting involves the collection of informa- tion on resource usage of an entity within the administra- tive domain. As a result, accounting packets and session records will typically remain within the administrative boundary. Inter-domain accounting Inter-domain accounting involves the collection of informa- tion on resource usage of an entity that exists within another administrative domain. This typically results in Aboba & Lidyard [Page 2] INTERNET-DRAFT 2 March 1998 accounting packets, session records, or invoices crossing administrative boundaries. Real-time accounting Real-time accounting involves the transmission of accounting packets or session records within a defined time window. Time constraints are typically imposed so as to allow more effective management of credit risks. 4. Definition of the Accounting Data Interchange Format (ADIF) ADIF is based on MIME, described in [11], and resembles the LDAP Data Interchange Format (LDIF) specified in [8]. An ADIF file consists of a header providing basic information about the records in the file, followed by a series of records separated by a separator. The header includes the version number (1 for this document), device name/description, and collection start date and time. A default proto- col type may be optionally included in the header. 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 arbi- trary 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. As with LDIF, ADIF attributes to be expressed either in NVT ASCII (char- acters 32 through 126) or if non-printable characters are required, in base64. ADIF includes support for encoding of RADIUS, SNMP, L2TP and TACACS+ attributes, and support for other protocols may be added as needed. The protocol type is indicated by prepending the protocol and a "//" to the attribute name, i.e. RADIUS//Acct-Session-Time. 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, and attribute numbers may used instead of names. For example, if defaultProtocol: RADIUS is indicated in the ADIF header, then 46 may be used instead of RADIUS//Acct-Session-Time. Protocols such as L2TP, defined in [12] include additional fields such as Vendor ID and flags in their Attribute Value Pairs (AVPs). To encode such AVPs, ADIF includes support for sub-attributes. These are included as additional fields, separated by a semi-colon, and are of the form = . For example, the L2TP version num- ber attribute (attribute 2) with the Mandatory bit set would be expressed as "L2TP//2: 1; M=1". This document includes support for VendorId, VendorType, Mandatory and Hidden sub-attributes; other sub- attributes may be added as needed. Use of the VendorId and VendorType subattribute may be used for expression of vendor-specific attributes, such as those supported in RADIUS. Aboba & Lidyard [Page 3] INTERNET-DRAFT 2 March 1998 4.1. ADIF Examples Example 1: An ADIF file encoding RADIUS accounting data version: 1 device: server3 descripton: Accounting Server 3 date: 02 Mar 1998 12:19:01 -0500 defaultProtocol: RADIUS #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 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 with a vendor-specific attribute version: 1 device: server3 descripton: Accounting Server 3 date: 02 Mar 1998 12:19:01 -0500 defaultProtocol: RADIUS 4: 204.45.34.12 5: 12 61: 2 Aboba & Lidyard [Page 4] INTERNET-DRAFT 2 March 1998 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 4.2. Grammar The following definition uses the ABNF specified in [7]: adif-file = header-spec *SEP 1*( SEP adif-record ) header-spec = required-info SEP [optional-info SEP] required-info = device-spec SEP start-spec SEP optional-info = [version-spec SEP ] [description SEP] [default-protocol SEP] device-spec = "device:" *SP value description = "description:" *SPACE value default-protocol = "defaultProtocol:" *SPACE protocol protocol = "RADIUS" / "SNMP" / "TACACS+" / "L2TP" version-spec = "version:" *SPACE version-number version-number = 1*DIGIT ; version-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 = Mon = "JAN" / "FEB" / "MAR" / "APR" / "MAY" / "JUN" / "JUL" / "AUG" / "SEP" / "OCT" / "NOV" / "DEC" YYYY = hh = mm = ss = zone = adif-record = 1*(attrval-series SEP) attrval-series = 1*(attrval-spec) attrval-spec = attr ( (std-encoding / base-64-encoding) [sub-attr-encoding] ) Aboba & Lidyard [Page 5] INTERNET-DRAFT 2 March 1998 std-encoding = (":" *SP value ) base-64-encoding = ("::" *SP base64-value ) base64-value = sub-attr-enoding = *(";" sub-attr "=" ) sub-attr = "M" / "H" / "VID" / "VT" ; Mandatory, Hidden, Vendor ID, Vendor Type sub-attributes attr = radattr / snmpattr / tacacsplusattr / l2tpattr radattr = ["RADIUS//"] radattrname radattrname = / snmpattr = ["SNMP//"] snmpattrname snmpattrname = / tacacsplusattr = ["TACACS+//"] tacacsplusattrname tacacsplusattrname = l2tpattr = ["L2TP//"] l2tpattrname l2tpattrname = value = 1*safe-initval *safe safe = LF = Alpha = %x41-5A / %x61-7A ; A-Z / a-z Digit = %x30-39 ;0-9 5. Acknowledgemens Thanks to Glen Zorn of Microsoft and Pat Calhoun of Sun Microsystems for useful discussions of this problem space. 6. 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 Aboba & Lidyard [Page 6] INTERNET-DRAFT 2 March 1998 Techniques, Morgan Kaufmann Publishers, San Francisco, California, 1993. [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-01.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] 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] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." Internet draft (work in progress), draft-ietf-pppext-l2tp-09.txt, Ascend Communications, Microsoft, Copper Mountain Networks, U.S. Robotics, February 1998. [13] D. Carrel, L. Grant. "The TACACS+ Protocol Version 1.78." Work in progress, draft-grant-tacacs-02.txt, Cisco Systems, 7. 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 Aboba & Lidyard [Page 7] INTERNET-DRAFT 2 March 1998 Phone: 615-231-6110 EMail: dave@telcores.com Aboba & Lidyard [Page 8]