Internet Engineering Task Force Nevil Brownlee INTERNET-DRAFT The University of Auckland May 1999 Expires November 1999 Accounting Attributes and Record Formats Status of this Memo 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. Abstract This draft summarises existing IETF and ITU-T documents related to Accounting. A classification scheme for Accounting Attributes covering those in the summarised document it presented. Exchange formats for Accounting data records are discussed. INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 Contents 1 Purpose and Scope 3 2 IETF Documents 3 2.1 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 4 2.2 DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 DIAMETER Attributes . . . . . . . . . . . . . . . . . . . 6 2.3 ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1 RTFM Attributes . . . . . . . . . . . . . . . . . . . . . 8 2.5 ISDN MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.1 ISDN Attributes . . . . . . . . . . . . . . . . . . . . . 10 2.6 AToMMIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6.1 AToMMIB Attributes . . . . . . . . . . . . . . . . . . . . 11 2.7 QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . . . 11 2.7.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 12 3 ITU-T Documents 13 3.1 Q.825: Call Detail Recording . . . . . . . . . . . . . . . . . 13 3.1.1 Q.825 Attributes . . . . . . . . . . . . . . . . . . . . . 13 4 Accounting File and Record Formats 17 4.1 ASN.1 Records . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.1 RTFM and AToMMIB . . . . . . . . . . . . . . . . . . . . . 17 4.1.2 Q.825 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Binary Records . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3 Text Records . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.1 ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . 19 5 AAA Requirements 20 5.1 A Well-defined Set of Attributes . . . . . . . . . . . . . . . 20 5.2 A Simple Interchange Format . . . . . . . . . . . . . . . . . 20 6 Security Considerations 21 7 References 21 8 Author's Address 24 Nevil Brownlee [Page 2] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 1 Purpose and Scope This draft summarises existing IETF and ITU-T documents related to Accounting. For those documents which describe Accounting Attributes (i.e. quantities which can be measured and reported), an Attribute Summary is given. Although several of the documents describe Attributes which are similar; no attempt is made to identify those which are the same in several documents. An extensible classification scheme for AAA Accounting Attributes is proposed; it is a superset of the attributes in all the documents summarised. There is a clear need for a common exchange format for Accounting data records; several possibilities are presented. This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. 2 IETF Documents In March 1999 there were at least Internet Drafts and 8 RFCs concerned with 'Accounting.' These are summarised (by working group) in the following sections. 2.1 RADIUS The RADIUS protocol [RAD-PROT] carries authentication, authorization and configuration information between a Network Access Server (NAS) and an authentication server. Requests and responses carried by the protocol are expressed in terms of RADIUS attributes such as User-Name, Service-Type, and so on. These attributes provide the information needed by a RADIUS server to authenticate users and to establish authorized network service for them. The protocol was extended to carry accounting information between a NAS and a shared accounting server. This was achieved by defining a set of RADIUS accounting attributes [RAD-ACC]. RADIUS packets have a short header containing the RADIUS packet type and authenticator (sixteen octets) and length, followed by a sequence of (Type, Length, Value) triples, one for each attribute. RADIUS is now very widely used, and a number of significant new extensions to it have been proposed. For example [RAD-EXT] discusses extensions to implement the Extensible Authentication Protocol (EAP) and Nevil Brownlee [Page 3] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 the Apple Remote Access Protocol (ARAP). [RAD-TACC] discusses extensions to permit RADIUS to interwork effectively with tunnels using protocols such as PPTP and L2TP. 2.1.1 RADIUS Attributes Each RADIUS attribute is identified by an 8-bit number, referred to as the RADIUS Type field. Up-to-date values of this field are specified in the most recent Assigned Numbers RFC [ASG-NBR], but the current list is as follows: RADIUS Attributes [RAD-PROT] 1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port 17 (unassigned) 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 (unassigned) 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id 32 NAS-Identifier 33 Proxy-State 34 Login-LAT-Service 35 Login-LAT-Node Nevil Brownlee [Page 4] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 36 Login-LAT-Group 37 Framed-AppleTalk-Link 38 Framed-AppleTalk-Network 39 Framed-AppleTalk-Zone 60 CHAP-Challenge 61 NAS-Port-Type 62 Port-Limit 63 Login-LAT-Port RADIUS Accounting Attributes [RAD-ACC] 40 Acct-Status-Type 41 Acct-Delay-Time 42 Acct-Input-Octets 43 Acct-Output-Octets 44 Acct-Session-Id 45 Acct-Authentic 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause 50 Acct-Multi-Session-Id 51 Acct-Link-Count RADIUS Extension Attributes [RAD-EXT] 52 Acct-Input-Gigawords 53 Acct-Output-Gigawords 54 Unused 55 Event-Timestamp 70 ARAP-Password 71 ARAP-Features 72 ARAP-Zone-Access 73 ARAP-Security 74 ARAP-Security-Data 75 Password-Retry 76 Prompt 77 Connect-Info 78 Configuration-Token 79 EAP-Message 80 Signature 84 ARAP-Challenge-Response RADIUS Tunnelling Attributes [RAD-TACC] 51 Acct-Link-Count 64 Tunnel-Type Nevil Brownlee [Page 5] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 65 Tunnel-Medium-Type 66 Tunnel-Client-Endpoint 67 Tunnel-Server-Endpoint 68 Acct-Tunnel-Connection 69 Tunnel-Password 81 Tunnel-Private-Group-ID 82 Tunnel-Assignment-ID 83 Tunnel-Preference 2.2 DIAMETER The DIAMETER protocol [DIAM-FRAM] defines a policy protocol used by clients to perform Policy, AAA and Resource Control. This allows a single server to handle policies for many services. The DIAMETER protocol consists of a header followed by objects. Each object is encapsulated in a header known as an Attribute-Value Pair (AVP). DIAMETER defines a base protocol that defines the header formats, security extensions and requirements as well as a small number of mandatory commands and AVPs. A new service can extend DIAMETER by extending the base protocol to support new functionality. One key differentiator with DIAMETER is its inherent support for Inter-Server communication. Although this can be achieved in a variety of ways, the most useful feature is the ability to "proxy" messages across a set of DIAMETER servers (known as a proxy chain). The DIAMETER Policy and Accounting Extension for SIP (Session Initiation Protocol) document [DIAM-SIP] extends DIAMETER by adding a policy and accounting information exchange mechanism between a DIAMETER policy server and a SIP proxy server. A DIAMETER server is responsible for maintaining a user policy and accounting database and a means to update it. A SIP proxy server needs to contact a DIAMETER server during multimedia session setup and teardown time to perform admission control and accounting tasks. The exchange mechanism protocol does not make any assumption about policy and billing algorithms at DIAMETER servers. 2.2.1 DIAMETER Attributes DIAMETER AVPs are identified by a 16-bit number defined in [DIAM-AUTH]. Since Most of the AVPs found in that document were copied from the RADIUS protocol [RAD-PROT], it is possible to have both RADIUS and DIAMETER servers read the same dictionary and users files. Nevil Brownlee [Page 6] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 The backward compatibility that DIAMETER offers is intended to facilitate deployment. To this end, DIAMETER inherits the RADIUS attributes, and only adds a few of its own. In the list below attribute numbers which are used for RADIUS attributes but not for DIAMETER are indicated with a star (*). RADIUS attributes used by DIAMETER are not listed again here. The DIAMETER attributes are: 4 (unassigned, *) 17 (unassigned) 21 (unassigned) 24 (unassigned, *) 25 (unassigned, *) 27 (unassigned, *) 32 (unassigned, *) 33 (unassigned, *) 280 Filter-Rule 281 Framed-Password-Policy 600 SIP-Sequence 601 SIP-Call-ID 602 SIP-To 603 SIP-From 2.3 ROAMOPS [ROAM-IMPL] reviews the design and functionality of existing roaming implementations. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal customer-vendor relationship with only one. One requirment for successful roaming is the provision of effective accounting. [ROAM-ADIF] proposes a standard accounting record format, the Accounting Data Interchange Format (ADIF), which is designed to compactly represent accounting data in a protocol-independent manner. As a result, ADIF may be used to represent accounting data from any protocol using attribute value pairs (AVPs) or variable bindings. ADIF does not define accounting attributes of its own. Instead, it gives examples of accounting records using the RADIUS accounting attributes. Nevil Brownlee [Page 7] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 2.4 RTFM The RTFM Architecture [RTFM-ARC] provides a general method of measuring network traffic flows between 'metered traffic groups.' Each RTFM flow has a set of 'address' attributes, which define the traffic groups at each of the flow's end-points. As well as address attributes, each flow has traffic-related attributes, e.g. times of first and last packets, counts for packets and bytes in each direction. RTFM flow measurements are made by RTFM meters [RTFM-MIB] and collected by RTFM meter readers using SNMP. The MIB uses a 'DataPackage' convention, which specifies the attribute values to be read from a flow table row. The meter returns the values for each required attribute within a BER-encoded sequence. This means there is only one object identifier for the whole sequence, greatly reducing the number of bytes required to retrieve the data. 2.4.1 RTFM Attributes RTFM attributes are identified by a 16-bit attribute number. The RTFM Attributes are: 0 Null 1 Flow Subscript Integer Flow table info 4 Source Interface Integer Source Address 5 Source Adjacent Type Integer 6 Source Adjacent Address String 7 Source Adjacent Mask String 8 Source Peer Type Integer 9 Source Peer Address String 10 Source Peer Mask String 11 Source Trans Type Integer 12 Source Trans Address String 13 Source Trans Mask String 14 Destination Interface Integer Destination Address 15 Destination Adjacent Type Integer 16 Destination Adjacent Address String 17 Destination AdjacentMask String 18 Destination PeerType Integer 19 Destination PeerAddress String 20 Destination PeerMask String 21 Destination TransType Integer Nevil Brownlee [Page 8] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 22 Destination TransAddress String 23 Destination TransMask String 26 Rule Set Number Integer Meter attribute 27 Forward Bytes Integer Source-to-Dest counters 28 Forward Packets Integer 29 Reverse Bytes Integer Dest-to-Source counters 30 Reverse Packets Integer 31 First Time Timestamp Activity times 32 Last Active Time Timestamp 33 Source Subscriber ID String Session attributes 34 Destination Subscriber ID String 35 Session ID String 36 Source Class Integer 'Computed' attributes 37 Destination Class Integer 38 Flow Class Integer 39 Source Kind Integer 40 Destination Kind Integer 41 Flow Kind Integer 50 MatchingStoD Integer PME variable 51 v1 Integer Meter Variables 52 v2 Integer 53 v3 Integer 54 v4 Integer 55 v5 Integer 65 .. 'Extended' attributes (to be defined by the RTFM working group) 127 2.5 ISDN MIB The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces.It does not explicitly define anything related to accounting, however it does define isdnBearerChargedUnits as The number of charged units for the current or last connection. For incoming calls or if charging information is not supplied by the switch, the value of this object is zero. Nevil Brownlee [Page 9] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 This allows for an ISDN switch to convert its traffic flow data (such as Call Connect Time) into charging data. 2.5.1 ISDN Attributes The relevant object in the MIB is the isdn bearer table, which has entries in the following form: IsdnBearerEntry ::= SEQUENCE { isdnBearerChannelType INTEGER, isdnBearerOperStatus INTEGER, isdnBearerChannelNumber INTEGER, isdnBearerPeerAddress DisplayString, isdnBearerPeerSubAddress DisplayString, isdnBearerCallOrigin INTEGER, isdnBearerInfoType INTEGER, isdnBearerMultirate TruthValue, isdnBearerCallSetupTime TimeStamp, isdnBearerCallConnectTime TimeStamp, isdnBearerChargedUnits Gauge32 } 2.6 AToMMIB The 'ATM Accounting Information MIB' document [ATM-ACT] describes a large set of accounting objects for ATM connections. An administrator may select objects from this set using a selector of the form (subtree, list) where 'subtree' specifies an object identifier from the AToMMIB. For each subtree there is a table holding values for each ATM connection. The required connections are indicated by setting bits in 'list,' which is an octet string. For example, the set containing the number of received cells for the first eight ATM connections would be selected by (atmAcctngReceivedCells, 0xFF). The Connection-Oriented Accounting MIB document [ATM-COLL] defines a MIB providing managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. The accounting data is collected into files for later retrieval via a file transfer protocol. Records within an accounting file are stored as BER strings [ASN1, BER]. Nevil Brownlee [Page 10] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 2.6.1 AToMMIB Attributes Accounting data objects within the AToMMBIB are identified by the last integer in their object identifiers. The ATM accounting data objects are: 1 atmAcctngConnectionType 2 atmAcctngCastType 3 atmAcctngIfName 4 atmAcctngIfAlias 5 atmAcctngVpi 6 atmAcctngVci 7 atmAcctngCallingParty 8 atmAcctngCalledParty 9 atmAcctngCallReference 10 atmAcctngStartTime 11 atmAcctngCollectionTime 12 atmAcctngCollectMode 13 atmAcctngReleaseCause 14 atmAcctngServiceCategory 15 atmAcctngTransmittedCells 16 atmAcctngTransmittedClp0Cells 17 atmAcctngReceivedCells 18 atmAcctngReceivedClp0Cells 19 atmAcctngTransmitTrafficDescriptorType 20 atmAcctngTransmitTrafficDescriptorParam1 21 atmAcctngTransmitTrafficDescriptorParam2 22 atmAcctngTransmitTrafficDescriptorParam3 23 atmAcctngTransmitTrafficDescriptorParam4 24 atmAcctngTransmitTrafficDescriptorParam5 25 atmAcctngReceiveTrafficDescriptorType 26 atmAcctngReceiveTrafficDescriptorParam1 27 atmAcctngReceiveTrafficDescriptorParam2 28 atmAcctngReceiveTrafficDescriptorParam3 29 atmAcctngReceiveTrafficDescriptorParam4 30 atmAcctngReceiveTrafficDescriptorParam5 31 atmAcctngCallingPartySubAddress 32 atmAcctngCalledPartySubAddress 33 atmAcctngRecordCrc16 2.7 QoS: RSVP and DIFFSERV As we move towards providing more than simple 'best effort' connectivity, there has been a tremendous surge of interest in (and work on) protocols to provide Quality of Service for Internet sessions. This Nevil Brownlee [Page 11] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 is of particular interest for the provision of 'Integrated Services,' i.e. the transport of audio, video, real-time, and classical data traffic within a single network infrastructure. Two approaches to this have emerged so far: - the Integrated Services architecture (intserv) [IIS-ARC], with its accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's Common Open Policy Service protocol, COPS [RAP-COPS] - the Differentiated Services architecture (diffserv) [DSRV-ARC] RSVP is a signaling protocol that applications may use to request resources from the network. The network responds by explicitly admitting or rejecting RSVP requests. Certain applications that have quantifiable resource requirements express these requirements using intserv parameters [IIS-SPEC]. Diffserv networks classify packets into one of a small number of aggregated flows or 'classes', based on the diffserv codepoint (DSCP) in the packet's IP header. At each diffserv router, packets are subjected to a 'per-hop behaviour' (PHB), which is invoked by the DSCP. Since RSVP is purely a requirements signalling protocol it can also be used to request connections from a diffserv network [RS-DS-OP]. 2.7.1 Attributes A set of parameters for specifying a requested Quality of Service are given in [IIS-SPEC]. These have been turned into accounting attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP-MIB]. The RTFM QoS attributes are: 98 QoSService 99 QoSStyle 100 QoSRate 101 QoSSlackTerm 102 QoSTokenBucketRate 103 QoSTokenBucketSize 104 QoSPeakDataRate 105 QoSMinPolicedUnit 106 QoSMaxPolicedUnit The RSVP MIB contains a large number of objects, arranged within the following sections: Nevil Brownlee [Page 12] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 General Objects Session Statistics Table Session Sender Table Reservation Requests Received Table Reservation Requests Forwarded Table RSVP Interface Attributes Table RSVP Neighbor Table The Session tables contain information such as the numbers of senders and receivers for each session, while the Reservation Requests tables contain details of requests handled by the RSVP router. There are too many objects to list here, but many of them could potentially be used for accounting. In particular, RSVP Requests contain the specification of the service parameters requested by a user; these, together with the actual usage data for the connection make up an accounting record for that usage. 3 ITU-T Documents 3.1 Q.825: Call Detail Recording ITU-T Recommendation Q.825 specifies how CDRs (Call Detail Records) are produced and managed in Network Elements for POTS, ISDN and IN (Intelligent Networks). Uses of Call detail information for various purposes are discussed. Each call produces one or more records describing events that occured during the life of a call. Data may be produced in real time (single CDRs), near real-time (blocks of CDRs), or as batch files of CDRs. The information model for Call Detail Recording is formally described in terms of an Entity-Rlationship model, and an object model specified in terms of GDMO templates (Guidelines for the Definition of Managed Objects). Note that this model includes the ways in which CDRs are transported from the (NE) Network Element where they are generated to the OS (Operations System) where they are used. 3.1.1 Q.825 Attributes The following attributes are defined. The explanations given are very brief summaries only, see [Q-825] for the complete text. Nevil Brownlee [Page 13] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 1 accessDelivery Indicates that the call was delivered to the called subscriber 2 accountCodeInput Account code (for billing), supplied by subscriber. 78 additionalParticipantInfo (No details given) 5 b-PartyCategory Subscriber category for called subscriber. 4 bearerService Bearer capability information (only for ISDN calls). 13 cDRPurpose Reason for triggering this Call Data Record. 70 callDetailDataId Unique identifier for the CallDetailData object. 79 callDuration Duration of call 6 callIdentificationNumber Identification number for call; all records produced for this call have the same callIdenfificationNumber. 73 callStatus Identifies whether the call was answered or not. 9 calledPartyNumber Telephone number of the called subscriber (may be a 'diverted-to' or 'translated' number. 7 callingPartyCategory Calling subscriber category. 8 callingPartyNumber Telephone number of the calling party. 10 callingPartyNumberNotScreened An additional, user-provided (not screened) number ot the calling party. 11 callingPartyType Calling subscriber type. 74 carrierId Carrier ID to which the call is sent. Nevil Brownlee [Page 14] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 12 cause Cause and location value for the termination of the call. 14 chargedDirectoryNumber Charged directory number (where the charged participant element can't indicate the number). 16 chargedParticipant Participant to be charged for the usage. 15 chargingInformation Charging information generated by a Network Element which is capable of charging. 17 configurationMask Time consumption, e.g. from B-answer to termination time, between partial call records, etc. 18 conversationTime Time consumption from B-answer to end of call. 19 creationTriggerList List of trigger values which will create Call Detail data objects. 75 dPC Destination point code (for analysis purposes). 20 dataValidity Indicates that the NE is having problems, contents of the generated Call Detail record is not reliable. 23 durationTimeACM Time consumption from seizure until received ACM. 21 durationTimeB-Answer Time consumption from seizure until B-answer. 22 durationTimeNoB-Answer Time from seizure to terminatin when no B-answer was received. 25 exchangeInfo Identity of exchange where Call Detail record was generated. 26 fallbackBearerService Fallback bearer capability information for a call. 27 glare Indicates if a glare condition was encountered. Nevil Brownlee [Page 15] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 31 iNServiceInformationList Contains information about the use of IN (Intelligent Network) services. 32 iNSpecificInformation Contains information about the use of one IN service. 33 iSUPPreferred Indicate whether an ISUP preference was requested. 28 immediateNotificationForUsageMetering Indicates that the Call Detail records requires immediate data transfer to the Operations System. 34 maxBlockSize Maximum number of Call Detail records in a block. 35 maxTimeInterval Maximum latency allowable for near-real-time Call Detail data delivery. 36 networkManagementControls Indicates which Traffic Management Control has affected the call. 37 networkProviderId Indicates the Network Provider for whom the CDR is generated. 76 oPC Originating point code for a failed call (for analysis purposes). 38 operatorSpecific1AdditionalNumber 40 operatorSpecific2AdditionalNumber 42 operatorSpecific3AdditionalNumber Operator-defined additional participant information. 39 operatorSpecific1Number 41 operatorSpecific2Number 43 operatorSpecific3Number Operator-defined participant information. 44 originalCalledNumber Telephone number of the original called party. 45 partialGeneration Included if the CDR (Call Detail record) output is partial. Such CDRs have a field indicating their partial record number. 77 participantInfo (No details given). Nevil Brownlee [Page 16] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 46 percentageToBeBilled Percentage to be billed when normal billing rules are not to be followed. 47 periodicTrigger Defines the intervals at which the CDR file should be created. 48 personalUserId Internationally unique personal User Identity (for UPT calls). 49 physicalLineCode Identifies the call subscriber's physical line. 50 progress Describes an event which occurred during the life of a call. 51 queueInfo Used to record usage of queueing resources with IN calls. 52 receivedDigits The digits dialled by the subscriber. (Normally only included for customer care urposes). 53 recordExtensions Information elements added by network operators and/or manufacturers in addition to the standard ones above. 4 Accounting File and Record Formats 4.1 ASN.1 Records 4.1.1 RTFM and AToMMIB RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to enocde lists of attributes into accounting records. RTFM uses SNMP to retrieve such records as BER strings, thus avoiding having to have an object identifier for every object. AToMMIB carries this a stage further by defining an accounting file format in ASN.1 and making it available for retrieval by a file transfer protocol, thereby providing a more efficient alternative to simply retrieving the records using SNMP. Nevil Brownlee [Page 17] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 4.1.2 Q.825 A Q.825 Call Record is an ASN.1 SET containing a specified group of the Q.825 attributes. Call records would presumably be encoded as BER strings before being collected for later processing. 4.2 Binary Records 4.2.1 RADIUS Radius packets carry a sequence of attributes and their values, as (Type, Length, Value) triples. The format of the value field is one of four data types. string 0-253 octets integer 32 bit value, most significant octet first. address 32 bit value, most significant octet first. 4.2.2 DIAMETER Each DIAMETER message consists of multiple AVP's, that is 32-bit aligned, with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (AVP contents) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code Identifies the AVP; values of this field are defined below. Nevil Brownlee [Page 18] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 AVP Length A 16-bit field contains the total object length in bytes. Must always be a multiple of 4, and at least 8. AVP Flags 0x01: Mandatory-Support 0x02: SS-Encrypted-Data 0x03: PK-Encrypted-Data 0x04: Vendor-Specific-AVP 4.3 Text Records 4.3.1 ROAMOPS ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a general, text-based format for accounting data files, described in a straigtforward BNF grammar. Its file header contains a field indicating the default protocol from which accounting attributes are drawn. If an attribute from another protocol is to be used, it is preceded by its protocol name, for example rtfm//27 would be RTFM's 'forward bytes' attribute. Comments in an ADIF file begin with a cross-hatch. Example: 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 Nevil Brownlee [Page 19] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 #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 5 AAA Requirements 5.1 A Well-defined Set of Attributes AAA needs a well-defined set of attributes whose values are to be carried in records to or from accounting servers. Most of the existing sets of documents described above include a set of attributes, identified by small integers. It is likely that these sets overlap, i.e. that some of them have attributes which represent the same quantity using different names in different sets. This suggests it might be possible to produce a single combined set of 'universal' accounting attributes, but this does not seem worthwhile. The ADIF approach of specifying a default protocol (from which attributes are assumed to come) and identifying any exceptions seems much more practical. I therefore propose that AAA should use the ADIF convention (or something like it) to identify attributes, together with all the sets of attributes covered by the [ASG-NBR] document. 5.2 A Simple Interchange Format AAA needs a simple interchange file format, to be used for accounting data. Several schemes for packaging and transporting such data have been described above. Nevil Brownlee [Page 20] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 The SNMP-based ones fit well within the context of an SNMP-based network management system. RTFM and AToMMIB provide ways to reduce the SNMP overhead for collecting data, and AToMMIB defines a complete file format. Both provide good ways to collect accounting data. As an interchange format, however, ASN.1-based schemes suffer from being rather complex binary structures. This means that one requires suitable tools to work with them, as compared to plain-text files where one can use existing text-based utiities. The binary schemes such as RADIUS and DIAMETER have simpler structures, but they too need purpose-built tools. For general use they would need to be extended to allow them to use attributes from other protocols. >From the point of view of being easy for humans to understand, ADIF seems very promising. Of course any processing program would need a suitable ADIF input parser, but using plain-text files makes them much easier to understand. 6 Security Considerations This document summarises many existing IETF and ITU documents; please refer to the original documents for security considerations for their particular protocols. When dealing with accounting data files, one must of course take care that their integrity and privacy are preserved. This dicument, however, is only concerned with the format of such files. 7 References [ACC-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting Background", RFC 1272, November 1991. [ASG-NBR] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700, October 1994. [ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [BER] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. Nevil Brownlee [Page 21] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 [ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, A., "Accounting Information for ATM Networks," RFC 2512, February 1999. [ATM-COLL] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, A., " Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection- Oriented Networks," RFC 2513, February 1999. [DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User Authentication Extensions," Internet Draft (Work in progress), draft-calhoun-diameter-authent- .. [DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER Framework Document," Internet Draft (Work in progress), draft-calhoun-diameter-framework- .. [DIAM-SIP] Pan, P. and Clahoun, P., "DIAMETER: Policy and Accounting Extension for SIP Framework Document," Internet Draft (Work in progress), draft-pan-diameter-sip- [DSRV-ARC] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [IIS-ARC] Braden, R., Clark, D. and Shenker, S., "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994 [IIS-SPEC] Shenker, S., Partridge, C., Guerin, R.: "Specification of Guaranteed Quality of Service," RFC 2212, 1997. [ISDN-MIB] Roeck, G., "ISDN Management Information Base using SMIv2," RFC 2127, March 1997. [Q-825] "Specification of TMN applications at the Q3 interface: Call detail recording," ITU-T Recommendation Q.825, 1998. [RAD-ACC] Rigney, C., "RADIUS Accounting," RFC 2139, April 1997. [RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS Extensions," Internet Draft (Work in progress), draft-ietf-radius-ext- .. [RAD-PROT] Rigney, C., Rubens, A., Simpson, W. and Willens, S., "Remote Authentication Dial In User Service (RADIUS)," RFC 2138, April 1997. Nevil Brownlee [Page 22] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 [RAD-RECX] Calhoun, P.R. and Beadles, M.., "RADIUS Accounting Interim Accounting Record Extension," Internet Draft (Work in progress), draft-ietf-radius-acct-interim- .. [RAD-TACC] Zorn, G., Mitton, D. and Aboba, A.,"RADIUS Accounting Modifications for Tunnel Protocol Support," (Work in progress), draft-ietf-radius-tunnel-acct- .. [RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and Sastry, A., "The COPS (Common Open Policy Service) draft-ietf-rap-cops- .. [ROAM-ADIF] Aboba, B and Lidyard, D., "The Accounting Data Interchange Format (ADIF)," Internet Draft (Work in progress), draft-ietf-roamops-actng- .. [ROAM-IMPL] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M. and Braden, R., "Interoperation of RSVP/Intserv and Diffserv Networks," Internet Draft (Work in Progress), draft-ietf-issll-diffserv-rsvp- .. [RSVP-ARC] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997 [RSVP-MIB] Baker, F., Krawczyk, J. and Sastry, A., "RSVP Management Information Base," Internet Draft (Work in Progress), draft-ietf-rsvp-mib-v2- .. [RTFM-ARC] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow Measurement: Architecture", Internet Draft (Work in progress), draft-ietf-rtfm-architecture- .. (to replace RFC 2063, January 1997). [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", Measurement: Architecture", Internet Draft (Work in progress), draft-ietf-rtfm-meter-mib- .. (to replace RFC 2064, January 1997). [RTFM-NEWA] Handelman, S, Brownlee, N., Ruth, G., and Stibler, S., "New Attributes for Traffic Flow Measurement", Internet Draft (Work in progress), draft-ietf-rtfm-new-traffic-flow- .. [SIP-PROT] Handley, M.,Schulzrinne, H.,Schooler, E. and Rosenberg, J., "SIP: session initiation protocol," RFC 2543, March 1999. Nevil Brownlee [Page 23] INTERNET-DRAFT Accounting Attributes and Record Formats May 1999 8 Author's Address Nevil Brownlee Information Technology Systems & Services The University of Auckland Phone: +64 9 373 7599 x8941 E-mail: n.brownlee@auckland.ac.nz Expires November 1999 Nevil Brownlee [Page 24]