ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Standards Track Dave Lidyard
<draft-ietf-roamops-actng-05.txt> Telco Research Corporation
17 November 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 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-
ietf-roamops-actng-05.txt>, and expires June 1, 1999. Please send
comments to the authors.
2. Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
3. 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 any pro-
tocol using attribute value pairs (AVPs) or variable bindings.
4. 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
Aboba & Lidyard Standards Track [Page 1]
INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998
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. This
document proposes a standard accounting record format, resembling the
LDAP Data Interchange Format (LDIF), described in [7]. ADIF may be
used to represent accounting data from any protocol using attribute
value pairs (AVPs) or variable bindings.
4.1. Terminology
This document 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.
Interim accounting
Interim accounting processes provide a snapshot ofresource
consumption. This is typically implemented so as to provide
for partial accounting in the event of a device reboot,
accounting server failure or network problem.
Session record
A session record represents a summary of resource consump-
tion. In the event that that a session summary is not
received, accounting gateways may need to reconstruct the
session record by processing interim accounting events.
Accounting Protocol
A protocol used to convey information collected for account-
ing purposes.
4.2. 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 resembles the LDAP Data
Interchange Format (LDIF) specified in [7]. 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
Aboba & Lidyard Standards Track [Page 2]
INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998
protocol 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. 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 uti-
lizing attribute value pairs or variable bindings. This includes
RADIUS, defined in [3] and [4], SNMP, L2TP, defined in [8], and
TACACS+, defined in [9]. 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: radius is indicated
in the ADIF header, then 46 may be used instead of radius//46.
Protocols such as L2TP, defined in [8] include additional fields such
as Vendor ID and flags in their 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 <subattribute>
= <value>. For example, the L2TP version number 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.
5.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
Aboba & Lidyard Standards Track [Page 3]
INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998
#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
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
Aboba & Lidyard Standards Track [Page 4]
INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998
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]
required-info = device-spec SEP start-spec SEP
optional-info = [version-spec SEP ] [description SEP] [def-protocol SEP]
device-spec = "device:" *SP value
description = "description:" *SPACE value
def-protocol = "defaultProtocol:" *SPACE protocol
protocol = <protocol keyword, defined by IANA>
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 = <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 = 1*(attrval-spec)
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-enoding = *(";" sub-attr "=" <value>)
sub-attr = "M" / "H" / "VID" / "VT"
; Mandatory, Hidden, Vendor ID, Vendor Type sub-attributes
attr = [protocol "//"] attribute-number
attribute-number = <An attribute number or object identifier defined for the protocol>
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), SPACE,
and semi-colon (";", ASCII 59 decimal)
SP = %x20 ; Space character
SEP = (CR LF) / LF
Aboba & Lidyard Standards Track [Page 5]
INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998
CR = <ASCII CR, carriage return>
LF = <ASCII LF, line feed>
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 Roam-
ing Implementations", RFC 2194, September 1997.
[2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming Proto-
cols", Internet draft (work in progress), draft-ietf-roamops-roam-
req-10.txt, November 1998.
[3] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen-
tication 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 Specifica-
tions: ABNF", RFC 2234, November 1997.
[7] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
Specification", Internet draft (work in progress), draft-ietf-asid-
ldif-02.txt, July 1997.
[8] 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-12.txt,
August 1998.
[9] Carrel, D., and L. Grant, "The TACACS+ Protocol Version 1.78",
Work in progress, draft-grant-tacacs-02.txt, March 1998.
[10] McCloghrie, K., Heinanen, J., Greene, W., 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, 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] Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825, August 1995.
Aboba & Lidyard Standards Track [Page 6]
INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998
7. Security Considerations
Since accounting data may include sensitive information, it it may be
desirable for this information to be kept confidential during trans-
mission. 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 adminis-
tered by IANA, namely the ADIF protocol and attribute number spaces.
In order to to avoid creating any new administrative procedures,
administration of the ADIF protocol namespace will piggyback on the
administration of IP protocol and TCP and UDP port numbers. Adminis-
tration of the ADIF attribute number space will piggyback on adminis-
tration of the attribute numbers or object identifiers for the proto-
col in question.
ADIF protocol names are required to be unique and the rights to use a
given ADIF protocol name are obtained 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 then used as the ADIF protocol name.
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 dis-
couraged.
9. Acknowledgements
Thanks to Glen Zorn of Microsoft and Pat Calhoun of Sun Microsystems
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
Aboba & Lidyard Standards Track [Page 7]
INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998
EMail: dave@telcores.com
11. Full Copyright Statement
Copyright (C) The Internet Society (1998). 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 implmentation 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 docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other Inter-
net 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 languages other than English. The limited permis-
sions 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 WAR-
RANTY 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-05.txt>, and expires
June 1, 1999.
Aboba & Lidyard Standards Track [Page 8]
