Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland
May 1999
Expires November 1999
Accounting Attributes and Record Formats
<draft-brownlee-accounting-attributes-00.txt>
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]
