ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     Category: Standards Track                                 Dave Lidyard
     <draft-ietf-roamops-actng-04.txt>           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 <draft-
     ietf-roamops-actng-04.txt>, 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 <subattribute> = <value>. 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                   = <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] )
     
     
     
     Aboba & Lidyard                                               [Page 5]


     INTERNET-DRAFT                                            2 March 1998
     
     
     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                 = radattr / snmpattr / tacacsplusattr / l2tpattr
     radattr              = ["RADIUS//"] radattrname
     radattrname          = <a RADIUS attribute name, as defined in [3],[4]> /
                            <a RADIUS attribute number, as defined in [3],[4]>
     snmpattr             = ["SNMP//"] snmpattrname
     snmpattrname         = <an SNMP object ID> / <an SNMP attribute name>
     tacacsplusattr       = ["TACACS+//"] tacacsplusattrname
     tacacsplusattrname   = <a TACACS+ attribute name, as defined in [13]>
     l2tpattr             = ["L2TP//"] l2tpattrname
     l2tpattrname         = <an L2TP attribute number, as defined in [12]>
     value                = 1*safe-initval *safe
     safe                 = <ASCII values 040 - 0176 octal (32 - 126 decimal),
                            excluding semi-colon (";", ASCII 59 decmal)
     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
     CR                   = <ASCII CR, carriage return>
     LF                   = <ASCII LF, line feed>
     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]