7
Network Working Group N. Brownlee
8
Request for Comments: 2924 The University of Auckland
9
Category: Informational A. Blount
14
Accounting Attributes and Record Formats
18
This memo provides information for the Internet community. It does
19
not specify an Internet standard of any kind. Distribution of this
24
Copyright (C) The Internet Society (2000). All Rights Reserved.
28
This document summarises Internet Engineering Task Force (IETF) and
29
International Telecommunication Union (ITU-T) documents related to
30
Accounting. A classification scheme for the Accounting Attributes in
31
the summarised documents is presented. Exchange formats for
32
Accounting data records are discussed, as are advantages and
33
disadvantages of integrated versus separate record formats and
34
transport protocols. This document discusses service definition
35
independence, extensibility, and versioning. Compound service
36
definition capabilities are described.
40
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
41
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3
42
3. Architecture Model . . . . . . . . . . . . . . . . . . . . . . 4
43
4. IETF Documents . . . . . . . . . . . . . . . . . . . . . . . . 4
44
4.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
45
4.1.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 5
46
4.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . 6
47
4.2.1. DIAMETER Attributes . . . . . . . . . . . . . . . . . . . 7
48
4.3. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
49
4.4. RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
50
4.4.1. RTFM Attributes . . . . . . . . . . . . . . . . . . . . . 9
51
4.5. ISDN MIB . . . . . . . . . . . . . . . . . . . . . . . . . . 10
52
4.5.1. ISDN Attributes . . . . . . . . . . . . . . . . . . . . . 10
53
4.6. AToMMIB . . . . . . . . . . . . . . . . . . . . . . . . . . 11
54
4.6.1. AToMMIB Attributes . . . . . . . . . . . . . . . . . . . . 11
58
Brownlee & Blount Informational [Page 1]
60
RFC 2924 Accounting Attributes and Record Formats September 2000
63
4.7. QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . . 12
64
4.7.1. QoS: RSVP and DIFFSERV Attributes . . . . . . . . . . . . 13
65
5. ITU-T Documents . . . . . . . . . . . . . . . . . . . . . . . 13
66
5.1. Q.825: Call Detail Recording . . . . . . . . . . . . . . . . 13
67
5.2. Q.825 Attributes . . . . . . . . . . . . . . . . . . . . . . 14
68
6. Other Documents . . . . . . . . . . . . . . . . . . . . . . . 18
69
6.1. TIPHON: ETSI TS 101 321 . . . . . . . . . . . . . . . . . . 18
70
6.2. MSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
71
7. Accounting File and Record Formats . . . . . . . . . . . . . . 19
72
7.1. ASN.1 Records . . . . . . . . . . . . . . . . . . . . . . . 19
73
7.1.1. RTFM and AToMMIB . . . . . . . . . . . . . . . . . . . . . 19
74
7.1.2. Q.825 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
75
7.2. Binary Records . . . . . . . . . . . . . . . . . . . . . . . 20
76
7.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
77
7.2.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . 20
78
7.3. Text Records . . . . . . . . . . . . . . . . . . . . . . . . 21
79
7.3.1. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . 21
80
8. AAA Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
81
8.1. A Well-defined Set of Attributes . . . . . . . . . . . . . . 22
82
8.2. A Simple Interchange Format . . . . . . . . . . . . . . . . 23
83
9. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
84
9.1. Record Format vs. Protocol . . . . . . . . . . . . . . . . . 24
85
9.2. Tagged, Typed Data . . . . . . . . . . . . . . . . . . . . . 24
86
9.2.1. Standard Type Definitions . . . . . . . . . . . . . . . . 25
87
9.3. Transaction Identifiers . . . . . . . . . . . . . . . . . . 26
88
9.4. Service Definitions . . . . . . . . . . . . . . . . . . . . 26
89
9.4.1. Service Independence . . . . . . . . . . . . . . . . . . . 27
90
9.4.2. Versioned Service Definitions . . . . . . . . . . . . . . 29
91
9.4.3. Relationships Among Usage Events . . . . . . . . . . . . . 29
92
9.4.4. Service Namespace Management . . . . . . . . . . . . . . . 30
93
10. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 30
94
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
95
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
96
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
97
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 36
101
This document summarises IETF and ITU-T documents related to
102
Accounting. For those documents which describe Accounting Attributes
103
(i.e. quantities which can be measured and reported), an Attribute
104
Summary is given. Although several of the documents describe
105
Attributes which are similar, no attempt is made to identify those
106
which are the same in several documents. An extensible
107
classification scheme for AAA Accounting Attributes is proposed; it
108
is a superset of the attributes in all the documents summarised.
114
Brownlee & Blount Informational [Page 2]
116
RFC 2924 Accounting Attributes and Record Formats September 2000
119
Many existing accounting record formats and protocols [RAD-ACT]
120
[TIPHON] are of limited use due to their single-service descriptive
121
facilities and lack of extensibility. While some record formats and
122
protocols support extensible attributes [RAD-ACT], none provide
123
identification, type checking, or versioning support for defined
124
groupings of attributes (service definitions). This document makes a
125
case for well-defined services.
127
Advantages and disadvantages of integrated versus separate record
128
formats and transport protocols are discussed. This document
129
discusses service definition independence, extensibility, and
130
versioning. Compound service definition capabilities are described.
132
2. Terminology and Notation
134
The following terms are used throughout the document.
137
A network element that accepts Usage Events from Service Elements.
138
It acts as an interface to back-end rating, billing, and
139
operations support systems.
141
Attribute-Value Pair (AVP)
142
A representation for a Usage Attribute consisting of the name of
143
the Attribute and a value.
146
A component of a Usage Event. A Usage Event describing a phone
147
call, for instance, might have a "duration" Property.
150
A type of task that is performed by a Service Element for a
154
Client of a Service Element. End-user of a network service.
157
A specification for a particular service. It is composed of a
158
name or other identifier, versioning information, and a collection
162
A network element that provides a service to Service Consumers.
163
Examples include RAS devices, voice and fax gateways, conference
170
Brownlee & Blount Informational [Page 3]
172
RFC 2924 Accounting Attributes and Record Formats September 2000
176
A component of a Usage Event that describes some metric of service
180
The description of an instance of service usage.
182
3. Architecture Model
184
Service Elements provide Services to Service Consumers. Before,
185
while, and/or after services are provided, the Service Element
186
reports Usage Events to an Accounting Server. Alternately, the
187
Accounting Server may query the Service Element for Usage Events.
188
Usage events are sent singly or in bulk.
190
+------------+ +-----------+ +------------+
191
| Service |<----->| Service | Usage Events | Accounting |
192
| Consumer | +-->| Element |------------->| Server |
193
+------------+ | +-----------+ +------------+
200
Accounting Servers may forward Usage Events to other systems,
201
possibly in other administrative domains. These transfers are not
202
addressed by this document.
206
In March 1999 there were at least 19 Internet Drafts and 8 RFCs
207
concerned with Accounting. These are summarised (by working group)
208
in the following sections.
212
The RADIUS protocol [RAD-PROT] carries authentication, authorization
213
and configuration information between a Network Access Server (NAS)
214
and an authentication server. Requests and responses carried by the
215
protocol are expressed in terms of RADIUS attributes such as User-
216
Name, Service-Type, and so on. These attributes provide the
217
information needed by a RADIUS server to authenticate users and to
218
establish authorized network service for them.
220
The protocol was extended to carry accounting information between a
221
NAS and a shared accounting server. This was achieved by defining a
222
set of RADIUS accounting attributes [RAD-ACT].
226
Brownlee & Blount Informational [Page 4]
228
RFC 2924 Accounting Attributes and Record Formats September 2000
231
RADIUS packets have a short header containing the RADIUS packet type
232
and authenticator (sixteen octets) and length, followed by a sequence
233
of (Type, Length, Value) triples, one for each attribute.
235
RADIUS is very widely used, and a number of significant new
236
extensions to it have been proposed. For example [RAD-EXT] discusses
237
extensions to implement the Extensible Authentication Protocol (EAP)
238
and the Apple Remote Access Protocol (ARAP). [RAD-TACC] discusses
239
extensions to permit RADIUS to interwork effectively with tunnels
240
using protocols such as PPTP and L2TP.
242
4.1.1. RADIUS Attributes
244
Each RADIUS attribute is identified by an 8-bit number, referred to
245
as the RADIUS Type field. Up-to-date values of this field are
246
specified in the most recent Assigned Numbers RFC [ASG-NBR], but the
247
current list is as follows:
249
RADIUS Attributes [RAD-PROT] 36 Login-LAT-Group
250
37 Framed-AppleTalk-Link
251
1 User-Name 38 Framed-AppleTalk-Network
252
2 User-Password 39 Framed-AppleTalk-Zone
254
4 NAS-IP-Address 60 CHAP-Challenge
255
5 NAS-Port 61 NAS-Port-Type
256
6 Service-Type 62 Port-Limit
257
7 Framed-Protocol 63 Login-LAT-Port
259
9 Framed-IP-Netmask RADIUS Accounting Attributes
260
10 Framed-Routing [RAD-ACT]
262
12 Framed-MTU 40 Acct-Status-Type
263
13 Framed-Compression 41 Acct-Delay-Time
264
14 Login-IP-Host 42 Acct-Input-Octets
265
15 Login-Service 43 Acct-Output-Octets
266
16 Login-TCP-Port 44 Acct-Session-Id
267
17 (unassigned) 45 Acct-Authentic
268
18 Reply-Message 46 Acct-Session-Time
269
19 Callback-Number 47 Acct-Input-Packets
270
20 Callback-Id 48 Acct-Output-Packets
271
21 (unassigned) 49 Acct-Terminate-Cause
272
22 Framed-Route 50 Acct-Multi-Session-Id
273
23 Framed-IPX-Network 51 Acct-Link-Count
275
25 Class RADIUS Extension Attributes
276
26 Vendor-Specific [RAD-EXT]
278
28 Idle-Timeout 52 Acct-Input-Gigawords
282
Brownlee & Blount Informational [Page 5]
284
RFC 2924 Accounting Attributes and Record Formats September 2000
287
29 Termination-Action 53 Acct-Output-Gigawords
288
30 Called-Station-Id 54 Unused
289
31 Calling-Station-Id 55 Event-Timestamp
291
33 Proxy-State 70 ARAP-Password
292
34 Login-LAT-Service 71 ARAP-Features
293
35 Login-LAT-Node 72 ARAP-Zone-Access
295
74 ARAP-Security-Data
299
78 Configuration-Token
301
80 Message-Authenticator
303
84 ARAP-Challenge-Response
304
85 Acct-Interim-Interval
308
RADIUS Tunneling Attributes
312
65 Tunnel-Medium-Type
313
66 Tunnel-Client-Endpoint
314
67 Tunnel-Server-Endpoint
315
68 Acct-Tunnel-Connection
318
81 Tunnel-Private-Group-ID
319
82 Tunnel-Assignment-ID
322
90 Tunnel-Client-Auth-ID
323
91 Tunnel-Server-Auth-ID
327
The DIAMETER framework [DIAM-FRAM] defines a policy protocol used by
328
clients to perform Policy, AAA and Resource Control. This allows a
329
single server to handle policies for many services. The DIAMETER
330
protocol consists of a header followed by objects. Each object is
331
encapsulated in a header known as an Attribute-Value Pair (AVP).
338
Brownlee & Blount Informational [Page 6]
340
RFC 2924 Accounting Attributes and Record Formats September 2000
343
DIAMETER defines a base protocol that specifies the header formats,
344
security extensions and requirements as well as a small number of
345
mandatory commands and AVPs. A new service can extend DIAMETER by
346
extending the base protocol to support new functionality.
348
One key differentiator with DIAMETER is its inherent support for
349
Inter-Server communication. Although this can be achieved in a
350
variety of ways, the most useful feature is the ability to "proxy"
351
messages across a set of DIAMETER servers (known as a proxy chain).
353
The DIAMETER Accounting Extension document [DIAM-ACT] extends
354
DIAMETER by defining a protocol for securely transferring accounting
355
records over the DIAMETER base protocol. This includes the case
356
where accounting records may be passed through one or more
357
intermediate proxies, in accordance with the 'referral broker' model.
359
The DIAMETER accounting protocol [DIAM-ACT] defines DIAMETER records
360
for transferring an ADIF record (see below). It introduces five new
361
attributes (480..485) which specify the way in which accounting
362
information is to be delivered between DIAMETER servers.
364
4.2.1. DIAMETER Attributes
366
DIAMETER AVPs are identified by a 16-bit number defined in [DIAM-
367
AUTH]. Since most of the AVPs found in that document were copied
368
from the RADIUS protocol [RAD-PROT], it is possible to have both
369
RADIUS and DIAMETER servers read the same dictionary and users files.
371
The backward compatibility that DIAMETER offers is intended to
372
facilitate deployment. To this end, DIAMETER inherits the RADIUS
373
attributes, and adds only a few of its own.
375
In the list below attribute numbers which are used for RADIUS
376
attributes but not for DIAMETER are indicated with a star (*).
377
RADIUS attributes used by DIAMETER are not listed again here.
379
The DIAMETER attributes are:
390
281 Framed-Password-Policy
394
Brownlee & Blount Informational [Page 7]
396
RFC 2924 Accounting Attributes and Record Formats September 2000
399
480 Accounting-Record-Type
401
482 Accounting-Interim-Interval
402
483 Accounting-Delivery-Max-Batch
403
484 Accounting-Delivery-Max-Delay
404
485 Accounting-Record-Number
413
[ROAM-IMPL] reviews the design and functionality of existing roaming
414
implementations. "Roaming capability" may be loosely defined as the
415
ability to use any one of multiple Internet service providers (ISPs),
416
while maintaining a formal customer-vendor relationship with only
417
one. One requirement for successful roaming is the provision of
418
effective accounting.
420
[ROAM-ADIF] proposes a standard accounting record format, the
421
Accounting Data Interchange Format (ADIF), which is designed to
422
compactly represent accounting data in a protocol-independent manner.
423
As a result, ADIF may be used to represent accounting data from any
424
protocol using attribute value pairs (AVPs) or variable bindings.
426
ADIF does not define accounting attributes of its own. Instead, it
427
gives examples of accounting records using the RADIUS accounting
432
The RTFM Architecture [RTFM-ARC] provides a general method of
433
measuring network traffic flows between "metered traffic groups".
434
Each RTFM flow has a set of "address" attributes, which define the
435
traffic groups at each of the flow's end-points.
437
As well as address attributes, each flow has traffic-related
438
attributes, e.g. times of first and last packets, counts for packets
439
and bytes in each direction.
441
RTFM flow measurements are made by RTFM meters [RTFM-MIB] and
442
collected by RTFM meter readers using SNMP. The MIB uses a
443
"DataPackage" convention, which specifies the attribute values to be
444
read from a flow table row. The meter returns the values for each
450
Brownlee & Blount Informational [Page 8]
452
RFC 2924 Accounting Attributes and Record Formats September 2000
455
required attribute within a BER-encoded sequence. This means there
456
is only one object identifier for the whole sequence, greatly
457
reducing the number of bytes required to retrieve the data.
459
4.4.1. RTFM Attributes
461
RTFM attributes are identified by a 16-bit attribute number.
463
The RTFM Attributes are:
466
1 Flow Subscript Integer Flow table info
468
4 Source Interface Integer Source Address
469
5 Source Adjacent Type Integer
470
6 Source Adjacent Address String
471
7 Source Adjacent Mask String
472
8 Source Peer Type Integer
473
9 Source Peer Address String
474
10 Source Peer Mask String
475
11 Source Trans Type Integer
476
12 Source Trans Address String
477
13 Source Trans Mask String
479
14 Destination Interface Integer Destination Address
480
15 Destination Adjacent Type Integer
481
16 Destination Adjacent Address String
482
17 Destination AdjacentMask String
483
18 Destination PeerType Integer
484
19 Destination PeerAddress String
485
20 Destination PeerMask String
486
21 Destination TransType Integer
487
22 Destination TransAddress String
488
23 Destination TransMask String
490
26 Rule Set Number Integer Meter attribute
492
27 Forward Bytes Integer Source-to-Dest counters
493
28 Forward Packets Integer
494
29 Reverse Bytes Integer Dest-to-Source counters
495
30 Reverse Packets Integer
496
31 First Time Timestamp Activity times
497
32 Last Active Time Timestamp
498
33 Source Subscriber ID String Session attributes
499
34 Destination Subscriber ID String
506
Brownlee & Blount Informational [Page 9]
508
RFC 2924 Accounting Attributes and Record Formats September 2000
511
36 Source Class Integer "Computed" attributes
512
37 Destination Class Integer
513
38 Flow Class Integer
514
39 Source Kind Integer
515
40 Destination Kind Integer
518
50 MatchingStoD Integer PME variable
520
51 v1 Integer Meter Variables
526
65-127 "Extended" attributes
527
(to be defined by the RTFM working group)
531
The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for
532
SNMP-based management of ISDN terminal interfaces. It does not
533
explicitly define anything related to accounting, however it does
534
define isdnBearerChargedUnits as
536
The number of charged units for the current or last connection.
537
For incoming calls or if charging information is not supplied by
538
the switch, the value of this object is zero.
540
This allows for an ISDN switch to convert its traffic flow data (such
541
as Call Connect Time) into charging data.
543
4.5.1. ISDN Attributes
545
The relevant object in the MIB is the ISDN bearer table, which has
546
entries in the following form:
550
isdnBearerChannelType INTEGER,
551
isdnBearerOperStatus INTEGER,
552
isdnBearerChannelNumber INTEGER,
553
isdnBearerPeerAddress DisplayString,
554
isdnBearerPeerSubAddress DisplayString,
555
isdnBearerCallOrigin INTEGER,
556
isdnBearerInfoType INTEGER,
557
isdnBearerMultirate TruthValue,
558
isdnBearerCallSetupTime TimeStamp,
562
Brownlee & Blount Informational [Page 10]
564
RFC 2924 Accounting Attributes and Record Formats September 2000
567
isdnBearerCallConnectTime TimeStamp,
568
isdnBearerChargedUnits Gauge32
573
The "ATM Accounting Information MIB" document [ATM-ACT] describes a
574
large set of accounting objects for ATM connections. An
575
administrator may select objects from this set using a selector of
576
the form (subtree, list) where "subtree" specifies an object
577
identifier from the AToMMIB. For each subtree there is a table
578
holding values for each ATM connection. The required connections are
579
indicated by setting bits in "list", which is an octet string. For
580
example, the set containing the number of received cells for the
581
first eight ATM connections would be selected by
582
(atmAcctngReceivedCells, 0xFF).
584
The Connection-Oriented Accounting MIB document [ATM-COLL] defines a
585
MIB providing managed objects used for controlling the collection and
586
storage of accounting information for connection-oriented networks
587
such as ATM. The accounting data is collected into files for later
588
retrieval via a file transfer protocol. Records within an accounting
589
file are stored as BER strings [ASN1, BER].
591
4.6.1. AToMMIB Attributes
593
Accounting data objects within the AToMMBIB are identified by the
594
last integer in their object identifiers.
596
The ATM accounting data objects are:
598
1 atmAcctngConnectionType
604
7 atmAcctngCallingParty
605
8 atmAcctngCalledParty
606
9 atmAcctngCallReference
607
10 atmAcctngStartTime
608
11 atmAcctngCollectionTime
609
12 atmAcctngCollectMode
610
13 atmAcctngReleaseCause
611
14 atmAcctngServiceCategory
612
15 atmAcctngTransmittedCells
613
16 atmAcctngTransmittedClp0Cells
614
17 atmAcctngReceivedCells
618
Brownlee & Blount Informational [Page 11]
620
RFC 2924 Accounting Attributes and Record Formats September 2000
623
18 atmAcctngReceivedClp0Cells
624
19 atmAcctngTransmitTrafficDescriptorType
625
20 atmAcctngTransmitTrafficDescriptorParam1
626
21 atmAcctngTransmitTrafficDescriptorParam2
627
22 atmAcctngTransmitTrafficDescriptorParam3
628
23 atmAcctngTransmitTrafficDescriptorParam4
629
24 atmAcctngTransmitTrafficDescriptorParam5
630
25 atmAcctngReceiveTrafficDescriptorType
631
26 atmAcctngReceiveTrafficDescriptorParam1
632
27 atmAcctngReceiveTrafficDescriptorParam2
633
28 atmAcctngReceiveTrafficDescriptorParam3
634
29 atmAcctngReceiveTrafficDescriptorParam4
635
30 atmAcctngReceiveTrafficDescriptorParam5
636
31 atmAcctngCallingPartySubAddress
637
32 atmAcctngCalledPartySubAddress
638
33 atmAcctngRecordCrc16
640
4.7. QoS: RSVP and DIFFSERV
642
As we move towards providing more than simple "best effort"
643
connectivity, there has been a tremendous surge of interest in (and
644
work on) protocols to provide managed Quality of Service for Internet
645
sessions. This is of particular interest for the provision of
646
"Integrated Services", i.e. the transport of audio, video, real-time,
647
and classical data traffic within a single network infrastructure.
649
Two approaches to this have emerged so far:
651
- the Integrated Services architecture (intserv) [IIS-ARC], with its
652
accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's
653
Common Open Policy Service protocol, COPS [RAP-COPS]
655
- the Differentiated Services architecture (diffserv) [DSRV-ARC]
657
RSVP is a signaling protocol that applications may use to request
658
resources from the network. The network responds by explicitly
659
admitting or rejecting RSVP requests. Certain applications that have
660
quantifiable resource requirements express these requirements using
661
intserv parameters [IIS-SPEC].
663
Diffserv networks classify packets into one of a small number of
664
aggregated flows or "classes", based on the diffserv codepoint (DSCP)
665
in the packet's IP header. At each diffserv router, packets are
666
subjected to a "per-hop behavior" (PHB), which is invoked by the
667
DSCP. Since RSVP is purely a requirements signalling protocol it can
668
also be used to request connections from a diffserv network [RS-DS-
674
Brownlee & Blount Informational [Page 12]
676
RFC 2924 Accounting Attributes and Record Formats September 2000
679
4.7.1. RSVP and DIFFSERV Attributes
681
A set of parameters for specifying a requested Quality of Service are
682
given in [IIS-SPEC]. These have been turned into accounting
683
attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP-
686
The RTFM QoS attributes are:
692
102 QoSTokenBucketRate
693
103 QoSTokenBucketSize
695
105 QoSMinPolicedUnit
696
106 QoSMaxPolicedUnit
698
The RSVP MIB contains a large number of objects, arranged within the
702
Session Statistics Table
704
Reservation Requests Received Table
705
Reservation Requests Forwarded Table
706
RSVP Interface Attributes Table
709
The Session tables contain information such as the numbers of senders
710
and receivers for each session, while the Reservation Requests tables
711
contain details of requests handled by the RSVP router. There are
712
too many objects to list here, but many of them could be used for
713
accounting. In particular, RSVP Requests contain the specification
714
of the service parameters requested by a user; these, together with
715
the actual usage data for the connection make up an accounting record
720
5.1. Q.825: Call Detail Recording
722
ITU-T Recommendation Q.825 specifies how CDRs (Call Detail Records)
723
are produced and managed in Network Elements for POTS, ISDN and IN
724
(Intelligent Networks).
726
Uses of Call Detail information for various purposes are discussed.
730
Brownlee & Blount Informational [Page 13]
732
RFC 2924 Accounting Attributes and Record Formats September 2000
735
Each call produces one or more records describing events that
736
occurred during the life of a call. Data may be produced in real
737
time (single CDRs), near real-time (blocks of CDRs), or as batch
740
The information model for Call Detail Recording is formally described
741
in terms of an Entity-Relationship model, and an object model
742
specified in terms of GDMO templates (Guidelines for the Definition
743
of Managed Objects). Note that this model includes the ways in which
744
CDRs are transported from the (NE) Network Element where they are
745
generated to the OS (Operations System) where they are used.
747
5.2. Q.825 Attributes
749
The following attributes are defined. The explanations given are
750
very brief summaries only, see [Q-825] for the complete text.
753
Indicates that the call was delivered to the called subscriber
756
Account code (for billing), supplied by subscriber.
758
78 additionalParticipantInfo
762
Subscriber category for called subscriber.
765
Bearer capability information (only for ISDN calls).
768
Reason for triggering this Call Data Record.
771
Unique identifier for the CallDetailData object.
776
6 callIdentificationNumber
777
Identification number for call; all records produced for this
778
call have the same callIdenfificationNumber.
781
Identifies whether the call was answered or not.
786
Brownlee & Blount Informational [Page 14]
788
RFC 2924 Accounting Attributes and Record Formats September 2000
792
Telephone number of the called subscriber (may be a
793
"diverted-to" or "translated" number.
795
7 callingPartyCategory
796
Calling subscriber category.
799
Telephone number of the calling party.
801
10 callingPartyNumberNotScreened
802
An additional, user-provided (not screened) number to the
806
Calling subscriber type.
809
Carrier ID to which the call is sent.
812
Cause and location value for the termination of the call.
814
14 chargedDirectoryNumber
815
Charged directory number (where the charged participant
816
element can't indicate the number).
818
16 chargedParticipant
819
Participant to be charged for the usage.
821
15 chargingInformation
822
Charging information generated by a Network Element which is
826
Time consumption, e.g. from B-answer to termination time,
827
between partial call records, etc.
830
Time consumption from B-answer to end of call.
832
19 creationTriggerList
833
List of trigger values which will create Call Detail data
837
Destination point code (for analysis purposes).
842
Brownlee & Blount Informational [Page 15]
844
RFC 2924 Accounting Attributes and Record Formats September 2000
848
Indicates that the NE is having problems, contents of the
849
generated Call Detail record is not reliable.
852
Time consumption from seizure until received ACM.
854
21 durationTimeB-Answer
855
Time consumption from seizure until B-answer.
857
22 durationTimeNoB-Answer
858
Time from seizure to termination when no B-answer was
862
Identity of exchange where Call Detail record was generated.
864
26 fallbackBearerService
865
Fallback bearer capability information for a call.
868
Indicates if a glare condition was encountered.
870
31 iNServiceInformationList
871
Contains information about the use of IN (Intelligent Network)
874
32 iNSpecificInformation
875
Contains information about the use of one IN service.
878
Indicate whether an ISUP preference was requested.
880
28 immediateNotificationForUsageMetering
881
Indicates that the Call Detail records requires
882
immediate data transfer to the Operations System.
885
Maximum number of Call Detail records in a block.
888
Maximum latency allowable for near-real-time Call Detail
891
36 networkManagementControls
892
Indicates which Traffic Management Control has affected
898
Brownlee & Blount Informational [Page 16]
900
RFC 2924 Accounting Attributes and Record Formats September 2000
904
Indicates the Network Provider for whom the CDR is generated.
907
Originating point code for a failed call (for analysis
910
38 operatorSpecific1AdditionalNumber
911
40 operatorSpecific2AdditionalNumber
912
42 operatorSpecific3AdditionalNumber
913
Operator-defined additional participant information.
915
39 operatorSpecific1Number
916
41 operatorSpecific2Number
917
43 operatorSpecific3Number
918
Operator-defined participant information.
920
44 originalCalledNumber
921
Telephone number of the original called party.
924
Included if the CDR (Call Detail record) output is partial.
925
Such CDRs have a field indicating their partial record number.
930
46 percentageToBeBilled
931
Percentage to be billed when normal billing rules are
935
Defines the intervals at which the CDR file should be created.
938
Internationally unique personal User Identity (for UPT calls).
941
Identifies the call subscriber's physical line.
944
Describes an event which occurred during the life of a call.
947
Used to record usage of queueing resources with IN calls.
954
Brownlee & Blount Informational [Page 17]
956
RFC 2924 Accounting Attributes and Record Formats September 2000
960
The digits dialed by the subscriber. (Normally only included
961
for customer care purposes).
964
Information elements added by network operators and/or
965
manufacturers in addition to the standard ones above.
969
6.1. TIPHON: ETSI TS 101 321
971
TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which
972
handles accounting and authorization requests and responses.
974
The following are elements selected from TIPHON's DTD that are used
977
<!ELEMENT Currency (#PCDATA)> <!ELEMENT Amount (#PCDATA)>
978
Identifies a numeric value. Expressed using the period (.) as a
979
decimal separator with no punctuation as the thousands separator.
981
<!ELEMENT CallId (#PCDATA)>
982
Contains a call's H.323 CallID value, and is thus used to
983
uniquely identify individual calls.
985
<!ELEMENT Currency (#PCDATA)>
986
Defines the financial currency in use for the parent element.
988
<!ELEMENT DestinationInfo type ( e164 | h323 | url | email |
989
transport | international |
990
national | network | subscriber |
991
abbreviated | e164prefix )
992
Gives the primary identification of the destination for a call.
994
<!ELEMENT Increment (#PCDATA)>
995
Indicates the number of units being accounted.
997
<!ELEMENT Service EMPTY>
998
Indicates a type of service being priced, authorized, or
999
reported. An empty Service element indicates basic Internet
1000
telephony service, which is the only service type defined by
1001
V1.4.2 of the specification. The specification notes that "Later
1002
revisions of this standard are expected to specify more enhanced
1003
service definitions to represent quality of service,
1004
availability, payment methods, etc."
1010
Brownlee & Blount Informational [Page 18]
1012
RFC 2924 Accounting Attributes and Record Formats September 2000
1015
<!ELEMENT DestinationInfo type ( e164 | h323 | url | email |
1016
transport | international |
1017
national | network | subscriber |
1018
abbreviated | e164prefix)
1019
Gives the primary identification of the source of a call.
1022
<!ELEMENT Timestamp (#PCDATA)>
1023
A restricted form of [ISO-DATE] that indicates the time at which
1024
the component was generated.
1026
<!ELEMENT TransactionId (#PCDATA)>
1027
Contains an integer, decimal valued identifier assigned to a
1028
specific authorized transaction.
1030
<!ELEMENT Unit (#PCDATA)>
1031
Indicates the units by which pricing is measured or usage
1032
recorded. It shall contain one of the following values:
1034
p packets (datagrams)
1037
<!Element UsageDetail ( Service, Amount, Increment, Unit ) >
1038
Collects information describing the usage of a service.
1042
MSIX [MSIX-SPEC] is an XML-based protocol transported by HTTP that is
1043
used to make accounting service definitions and transmit service
1044
usage information. As its service definitions are parameterized and
1045
dynamic, it makes no definition of services or attributes itself, but
1046
allows implementors to make their own. It specifies only the base
1047
data types that attributes may take: STRING, UNISTRING, INT32, FLOAT,
1048
DOUBLE, BOOLEAN, TIMESTAMP.
1050
7. Accounting File and Record Formats
1054
7.1.1. RTFM and AToMMIB
1056
RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists
1057
of attributes into accounting records. RTFM uses SNMP to retrieve
1058
such records as BER strings, thus avoiding having to have an object
1059
identifier for every object.
1066
Brownlee & Blount Informational [Page 19]
1068
RFC 2924 Accounting Attributes and Record Formats September 2000
1071
AToMMIB carries this a stage further by defining an accounting file
1072
format in ASN.1 and making it available for retrieval by a file
1073
transfer protocol, thereby providing a more efficient alternative to
1074
simply retrieving the records using SNMP.
1078
A Q.825 Call Record is an ASN.1 SET containing a specified group of
1079
the Q.825 attributes. Call records would presumably be encoded as
1080
BER strings before being collected for later processing.
1086
Radius packets carry a sequence of attributes and their values, as
1087
(Type, Length, Value) triples. The format of the value field is one
1092
address 32 bit value, most significant octet first.
1094
integer 32 bit value, most significant octet first.
1096
time 32 bit value, most significant octet first -- seconds
1097
since 00:00:00 GMT, January 1, 1970. The standard
1098
Attributes do not use this data type but it is presented
1099
here for possible use within Vendor-Specific attributes.
1103
Each DIAMETER message consists of multiple AVP's that are 32-bit
1104
aligned, with the following format:
1107
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
1108
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1110
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1111
| AVP Length | Reserved |P|T|V|R|M|
1112
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1114
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1116
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1122
Brownlee & Blount Informational [Page 20]
1124
RFC 2924 Accounting Attributes and Record Formats September 2000
1128
The AVP Code identifies the attribute uniquely. If the Vendor-
1129
Specific bit is set, the AVP Code is allocated from the
1130
vendor's private address space.
1132
The first 256 AVP numbers are reserved for backward
1133
compatibility with RADIUS and are to be interpreted as per
1134
RADIUS [RAD-PROT]. AVP numbers 256 and above are used for
1135
DIAMETER, which are allocated by IANA.
1138
A 16-bit field contains the total object length in bytes.
1139
Must always be a multiple of 4, and at least 8.
1145
R Reserved (MUST be set to 0)
1152
ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a
1153
general, text-based format for accounting data files, described in a
1154
straightforward BNF grammar. Its file header contains a field
1155
indicating the default protocol from which accounting attributes are
1156
drawn. If an attribute from another protocol is to be used, it is
1157
preceded by its protocol name, for example rtfm//27 would be RTFM's
1158
"forward bytes" attribute. Comments in an ADIF file begin with a
1161
Example: An ADIF file encoding RADIUS accounting data
1165
description: Accounting Server 3
1166
date: 02 Mar 1999 12:19:01 -0500
1167
defaultProtocol: radius
1169
rdate: 02 Mar 1999 12:20:17 -0500
1178
Brownlee & Blount Informational [Page 21]
1180
RFC 2924 Accounting Attributes and Record Formats September 2000
1202
#Acct-Output-Packets
1204
#Acct-Terminate-Cause
1206
#Acct-Multi-Session-Id
1213
8.1. A Well-Defined Set of Attributes
1215
AAA needs a well-defined set of attributes whose values are to be
1216
carried in records to or from accounting servers.
1218
Most of the existing sets of documents described above include a set
1219
of attributes, identified by small integers. It is likely that these
1220
sets overlap, i.e. that some of them have attributes which represent
1221
the same quantity using different names in different sets. This
1222
suggests it might be possible to produce a single combined set of
1223
"universal" accounting attributes, but such a "universal" set does
1224
not seem worthwhile.
1226
The ADIF approach of specifying a default protocol (from which
1227
attributes are assumed to come) and identifying any exceptions seems
1228
much more practical. We therefore propose that AAA should use the
1234
Brownlee & Blount Informational [Page 22]
1236
RFC 2924 Accounting Attributes and Record Formats September 2000
1239
ADIF convention (or something like it) to identify attributes,
1240
together with all the sets of attributes covered by the [ASG-NBR]
1243
8.2. A Simple Interchange Format
1245
AAA needs a simple interchange file format, to be used for accounting
1246
data. Several schemes for packaging and transporting such data have
1247
been described above.
1249
The SNMP-based ones fit well within the context of an SNMP-based
1250
network management system. RTFM and AToMMIB provide ways to reduce
1251
the SNMP overhead for collecting data, and AToMMIB defines a complete
1252
file format. Both provide good ways to collect accounting data.
1254
As an interchange format, however, ASN.1-based schemes suffer from
1255
being rather complex binary structures. This means that one requires
1256
suitable tools to work with them, as compared to plain-text files
1257
where one can use existing text-based utilities.
1259
The binary schemes such as RADIUS and DIAMETER have simpler
1260
structures, but they too need purpose-built tools. For general use
1261
they would need to be extended to allow them to use attributes from
1264
From the point of view of being easy for humans to understand, ADIF
1265
seems very promising. Of course any processing program would need a
1266
suitable ADIF input parser, but using plain-text files makes them
1267
much easier to understand.
1269
TIPHON's record format is specified by an XML DTD. While XML
1270
representations have the advantages of being well-known, they are
1271
limited by XML's inability to specify type or other validity checking
1272
for information within the tags. This situation will likely be
1273
improved by the XML Schema [XML-SCHM] efforts that are underway, but
1274
a stable reference is not yet available.
1278
It is generally agreed that there is a need for a standard record
1279
format and transport protocol for communication between Service
1280
Elements and Accounting Servers.
1282
There is less agreement on the following issues:
1284
o Separate or integral record format and transport protocol
1285
o Standard set of base data types
1286
o Service definitions: part of the protocol or separately defined
1290
Brownlee & Blount Informational [Page 23]
1292
RFC 2924 Accounting Attributes and Record Formats September 2000
1295
o Service definition namespace management
1297
The following sections address these issues.
1299
9.1. Record Format vs. Protocol
1301
All known Internet-centric billing protocols to date have an integral
1302
record format. That is, the collection of Properties that describe a
1303
Usage Event are specified as an integral part of the protocol,
1304
typically as a part of a "submit" message that is used to transmit a
1305
Usage Event from a Service Entity to an Accounting Server.
1307
It may be advantageous to define a record format that is independent
1308
of the transport protocol. Such a record format should support both
1309
representation of individual records and records in bulk, as Usage
1310
Events are often aggregated and transmitted in bulk.
1312
A separate record format is useful for record archiving and temporary
1313
file storage. Multiple transport protocols may be defined without
1314
affecting the record format. The task of auditing is made easier if
1315
a standard file format is defined. If a canonical format is used,
1316
bulk records may be hashed with MD5 [MD5] or a similar function, for
1317
reliability and security purposes.
1322
+------------+ +------------+
1325
| Event(s) | | Event(s) |
1328
+------------+ +------------+
1332
record format transport protocol
1334
If the protocol is written such that it can transmit Usage Events in
1335
the record format, no record rewriting for transport is required.
1337
9.2. Tagged, Typed Data
1339
Record formats and protocols use a combination of data locality and
1340
explicit tagging to identify data elements. Mail [RFC822], for
1341
instance, defines a header block composed of several Attribute-Value
1342
Pairs, followed by a message body. Each header field is explicitly
1346
Brownlee & Blount Informational [Page 24]
1348
RFC 2924 Accounting Attributes and Record Formats September 2000
1351
tagged, but the order of the AVPs is undefined. The message body is
1352
not tagged (except with an additional preceding blank line), and is
1353
found through its position in the message, which must be after all
1356
Some record formats make no use of tags--data elements are identified
1357
only by their position within a record structure. While this
1358
practice provides for the least amount of record space overhead, it
1359
is difficult to later modify the record format by adding or removing
1360
elements, as all record readers will have to be altered to handle the
1361
change. Tagged data allows old readers to detect unexpected tags and
1362
to detect if required data are missing. If the overhead of carrying
1363
explicit tags can be borne, it is advantageous to use explicitly
1364
tagged data elements where possible.
1366
An AVP approach has proven useful in accounting. RADIUS [RADIUS]
1367
uses numeric data type identifiers. ETSI's TIPHON [TIPHON] uses XML
1370
For an AAA accounting record format, the authors suggest that each
1371
Property be named by a textual or numeric identifier and carry a
1372
value and a data type indicator, which governs interpretation of the
1373
value. It may also be useful for each Property to carry a units of
1374
measure identifier. The TIPHON specification takes this approach.
1375
TS 101 321 also carries an Increment field, which denominates the
1376
Property's Unit of Measure field. Whether this additional
1377
convenience is necessary is a matter for discussion.
1379
It is not strictly necessary for each data record to carry data type,
1380
units of measure, or increments identifiers. If this information is
1381
recorded in a record schema document that is referenced by each data
1382
record, each record may be validated against the schema without the
1383
overhead of carrying type information.
1385
9.2.1. Standard Type Definitions
1387
It is useful to define a standard set of primitive data types to be
1388
used by the record format and protocol. Looking at the prior art,
1389
DIAMETER supports Data (arbitrary octets), String (UTF-8), Address
1390
(32 or 128 bit), Integer32, Integer64, Time (32 bits, seconds since
1391
1970), and Complex. MSIX [MSIX-SPEC] supports String, Unistring,
1392
Int32, Float, Double, Boolean, and Timestamp. SMIv2 [SMI-V2] offers
1393
ASN.1 types INTEGER, OCTET STRING, and OBJECT IDENTIFIER, and the
1394
application-defined types Integer32, IpAddress, Counter32, Gauge32,
1395
Unsigned32, TimeTicks, Opaque, and Counter64.
1402
Brownlee & Blount Informational [Page 25]
1404
RFC 2924 Accounting Attributes and Record Formats September 2000
1407
An appropriate set would likely include booleans, 32 and 64 bit
1408
signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and
1409
UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps. Fixed-
1410
precision numbers capable of representing currency amounts (with
1411
precision specified on both sides of the decimal point) have proven
1412
useful in accounting record formats, as they are immune to the
1413
precision problems that are encountered when one attempts to
1414
represent fixed-point amounts with floating point numbers.
1416
It may be worthwhile to consider the datatypes that are being
1417
specified by the W3C's "XML Schema Part 2: Datatypes" [XML-DATA]
1418
document. That document specifies a rich set of base types, along
1419
with a mechanism to specify derivations that further constrain the
1422
9.3. Transaction Identifiers
1424
Each Usage Event requires its own unique identifier.
1426
It is expedient to allow Service Elements to create their own unique
1427
identifiers. In this manner, Usage Events can be created and
1428
archived without the involvement of an Accounting Server or other
1431
A number of methods for creating unique identifiers are well known.
1432
One popular identifier is an amalgamation of a monotonically
1433
increasing sequence number, a large random value, a network element
1434
identifier, and a timestamp. Another possible source of entropy is a
1435
hash value of all or part of the record itself.
1437
RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give
1438
guidance on the creation of good unique identifiers.
1440
9.4. Service Definitions
1442
A critical differentiator in accounting record formats and protocols
1443
is their capability to account for arbitrary service usage. To date,
1444
no accounting record format or protocol that can handle arbitrary
1445
service definitions has achieved broad acceptance on the Internet.
1447
This section analyzes the issues in service definition and makes a
1448
case for a record format and protocol with the capability to carry
1449
Usage Events for rich, independently-defined services.
1458
Brownlee & Blount Informational [Page 26]
1460
RFC 2924 Accounting Attributes and Record Formats September 2000
1463
9.4.1. Service Independence
1465
It is informative to survey a number of popular Internet protocols
1466
and document encodings and examine their capacities for extension.
1467
These protocols can be categorized into two broad categories--"fully
1468
specified" protocols that have little provision for extension and
1469
"framework" protocols that are incomplete, but provide a basis for
1470
future extension when coupled with application documents.
1472
Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP],
1473
RADIUS Accounting [RAD-ACT], and HTML [HTML].
1475
Aside from leaving some field values "reserved for future use", all
1476
of Network Time Protocol's fields are fixed-width and completely
1477
defined. This is appropriate for a simple protocol that solves a
1480
Network News Transfer Protocol [NEWS-PROT] specifies that further
1481
commands may be added, and requests that non-standard implementations
1482
use the "X-" experimental prefix so as to not conflict with future
1483
additions. The content of news is 7-bit data, with the high-order
1484
bit cleared to 0. Nothing further about the content is defined.
1485
There is no in-protocol facility for automating decoding of content
1488
We pay particular attention to RADIUS Accounting [RAD-ACT]. Perhaps
1489
the second most frequently heard complaint (after security
1490
shortcomings) about RADIUS Accounting is its preassigned and fixed
1491
set of "Types". These are coded as a range of octets from 40 to 51
1496
42 Acct-Input-Octets
1497
43 Acct-Output-Octets
1500
46 Acct-Session-Time
1501
47 Acct-Input-Packets
1502
48 Acct-Output-Packets
1503
49 Acct-Terminate-Cause
1504
50 Acct-Multi-Session-Id
1507
These identifiers were designed to account for packet-based network
1508
access service. They are ill-suited for describing other services.
1509
While extension documents have specified additional types, the base
1514
Brownlee & Blount Informational [Page 27]
1516
RFC 2924 Accounting Attributes and Record Formats September 2000
1519
protocol limits the type identifier to a single octet, limiting the
1520
total number of types to 256.
1522
HTML/2.0 [HTML] is mostly a fully-specified protocol, but with W3C's
1523
HTML/4.0, HTML is becoming more of a framework protocol. HTML/2.0
1524
specified a fixed set of markups, with no provision for addition
1525
(without protocol revision).
1527
Examples of "framework" protocols and document encodings are HTTP,
1530
HTTP/1.1 [HTTP] is somewhat similar to NNTP in that it is designed to
1531
transport arbitrary content. It is different in that it supports
1532
description of that content through its Content-Type, Content-
1533
Encoding, Accept-Encoding, and Transfer-Encoding header fields. New
1534
types of content can be designated and carried by HTTP/1.1 without
1535
modification to the HTTP protocol.
1537
XML [XML] is a preeminent general-purpose framework encoding. DTD
1538
publishing is left to users. There is no standard registry of DTDs.
1540
SNMP presents a successful example of a framework protocol. SNMP's
1541
authors envisioned SNMP as a general management protocol, and allow
1542
extension through the use of private MIBs. SNMP's ASN.1 MIBs are
1543
defined, published, and standardized without the necessity to modify
1544
the SNMP standard itself. From "An Overview of SNMP" [SNMP-OVER]:
1546
It can easily be argued that SNMP has become prominent mainly from
1547
its ability to augment the standard set of MIB objects with new
1548
values specific for certain applications and devices. Hence, new
1549
functionality can continuously be added to SNMP, since a standard
1550
method has been defined to incorporate that functionality into
1551
SNMP devices and network managers.
1553
Most accounting protocols are fully-specified, with either a
1554
completely defined service or set of services (RADIUS Accounting) or
1555
with one or more services defined and provision for "extension"
1556
services to be added to the protocol later (TIPHON). While the
1557
latter is preferable, it may be preferable to take a more SNMP-like
1558
approach, where the accounting record format and protocol provide
1559
only a framework for service definition, and leave the task of
1560
service definition (and standardization) to separate efforts. In
1561
this manner, the accounting protocol itself would not have to be
1562
modified to handle new services.
1570
Brownlee & Blount Informational [Page 28]
1572
RFC 2924 Accounting Attributes and Record Formats September 2000
1575
9.4.2. Versioned Service Definitions
1577
Versioning is a naming and compatibility issue. Version identifiers
1578
are useful in service definition because they enable service
1579
definitions to be upgraded without a possibly awkward name change.
1580
They also enable possible compatibility between different versions of
1583
An example could be the service definition of a phone call. Version
1584
1 might define Properties for the start time, duration, and called
1585
and calling party numbers. Later, version 2 is defined, which
1586
augments the former service definition with a byte count. An
1587
Accounting Server, aware only of Version 1, may accept Version 2
1588
records, discarding the additional information (forward
1589
compatibility). Alternately, if an Accounting Server is made aware
1590
of version 2, it could optionally still accept version 1 records from
1591
Service Elements, provided the Accounting Sever does not require the
1592
additional information to properly account for service usage
1593
(backward compatibility).
1595
9.4.3. Relationships Among Usage Events
1597
Accounting record formats and protocols to date do not sufficiently
1598
addressed "compound" service description.
1600
A compound service is a service that is described as a composition of
1601
other services. A conference call, for example, may be described as
1602
a number of point-to-point calls to a conference bridge. It is
1603
important to account for the individual calls, rather than just
1604
summing up an aggregate, both for auditing purposes and to enable
1605
differential rating. If these calls are to be reported to the
1606
Accounting Server individually, the Usage Events require a shared
1607
identifier that can be used by the Accounting Server and other back-
1608
end systems to group the records together.
1610
In order for a Service Element to report compound events over time as
1611
a succession of individual Usage Events, the accounting protocol
1612
requires a facility to communicate that the compound event has
1613
started and stopped. The "start" message can be implicit--the
1614
transmission of the first Usage Event will suffice. An additional
1615
semaphore is required to tell the Accounting Server that the compound
1616
service is complete and may be further processed. This is necessary
1617
to prevent the Accounting Server from prematurely processing compound
1618
events that overlap the end of a billing period.
1626
Brownlee & Blount Informational [Page 29]
1628
RFC 2924 Accounting Attributes and Record Formats September 2000
1631
RADIUS Accounting has some provision for this sort of accounting with
1632
its "Acct-Multi-Session-Id" field. Unfortunately, RADIUS
1633
Accounting's other shortcomings preclude it from being used in
1634
general purpose service usage description.
1636
9.4.4. Service Namespace Management
1638
"Framework" protocols, as previously mentioned, do not define
1639
complete schema for their payload. For interoperability to be
1640
achieved, it must be possible for:
1642
(1) content definers to specify definitions without conflicting
1643
with the names of other definitions
1645
(2) protocol users to find and use content definitions
1647
Condition (1) can be readily managed through IANA assignment or by
1648
using an existing namespace differentiator (for example, DNS).
1650
Condition (2) is harder, and places considerable burden on the
1651
implementors. Their clients and servers must be able, statically or
1652
dynamically, to find and validate definitions, and manage versioning
1655
As previously mentioned, the XML specification provides no facility
1656
for DTD discovery or namespace management. XML specifies only a
1657
document format, and as such does not need to specify support for
1658
more "protocol" oriented problems.
1660
For an accounting record format and protocol, an approach closer to
1661
SNMP's is useful. SNMP uses an ISO-managed dotted-decimal namespace.
1662
An IANA-managed registry of service types is a possibility. Another
1663
possibility, used by MSIX [MSIX-SPEC], is for Service Element
1664
creators to identify their services by concatenation of a new service
1665
name with existing unique identifier, such as a domain name.
1667
A standard record format for service definitions would make it
1668
possible for Service Element creators to directly supply accounting
1669
system managers with the required definitions, via the network or
1674
It may be useful to define more than one record encoding.
1676
A "verbose" XML encoding is easily implemented and records can be
1677
syntactically verified with existing tools. "Human-readable"
1678
protocols tend to have an edge on "bitfield" protocols where ease of
1682
Brownlee & Blount Informational [Page 30]
1684
RFC 2924 Accounting Attributes and Record Formats September 2000
1687
implementation is paramount and the application can tolerate any
1688
additional processing required to generate, parse, and transport the
1691
A alternative "compressed" encoding that makes minimal use of storage
1692
and processing may be useful in many contexts.
1694
There are disadvantages to supporting multiple encodings.
1695
Optionally-supported multiple encodings mandate the requirement for
1696
capabilities exchange between Service Element and Accounting Server.
1697
Also, implementations can tend to "drift apart", with one encoding
1698
better-supported than another. Unless all encodings are mandatory,
1699
implementors may find they are unable to interoperate because they
1700
picked the wrong encoding.
1702
11. Security Considerations
1704
This document summarises many existing IETF and ITU documents; please
1705
refer to the original documents for security considerations for their
1706
particular protocols.
1708
It must be possible for the accounting protocol to be carried by a
1709
secure transport. A canonical record format is useful so that
1710
regeneration of secure record hashes is possible.
1712
When dealing with accounting data files, one must take care that
1713
their integrity and privacy are preserved. This document, however,
1714
is only concerned with the format of such files.
1718
[ACC-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
1719
Background", RFC 1272, November 1991.
1721
[ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
1722
RFC 1700, October 1994.
1724
[ASN1] Information processing systems - Open Systems
1725
Interconnection - Specification of Abstract Syntax
1726
Notation One (ASN.1), International Organization for
1727
Standardization, International Standard 8824, December
1730
[ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad,
1731
"Accounting Information for ATM Networks", RFC 2512,
1738
Brownlee & Blount Informational [Page 31]
1740
RFC 2924 Accounting Attributes and Record Formats September 2000
1743
[ATM-COLL] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "
1744
Managed Objects for Controlling the Collection and
1745
Storage of Accounting Information for Connection-Oriented
1746
Networks", RFC 2513, February 1999.
1748
[BER] Information processing systems - Open Systems
1749
Interconnection - Specification of Basic Encoding Rules
1750
for Abstract Notation One (ASN.1), International
1751
Organization for Standardization, International Standard
1752
8825, December 1987.
1754
[DIAM-ACT] Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G.,
1755
"DIAMETER Accounting Extension", Work in Progress.
1757
[DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User
1758
Authentication Extensions", Work in Progress.
1760
[DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER Framework
1761
Document", Work in Progress.
1763
[DSRV-ARC] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
1764
and W. Weiss, "An Architecture for Differentiated
1765
Services", RFC 2475, December 1998.
1767
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup
1768
Language - 2.0", RFC 1866, November 1995.
1770
[HTTP] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T.
1771
Berners-Lee, "Hypertext Transfer Protocol--HTTP/1.1", RFC
1774
[ICAL-CORE] Dawson, F. and D. Stenerson, "Internet Calendaring and
1775
Scheduling Core Object Specification", RFC 2445, November
1778
[IIS-ARC] Braden, R., Clark, D. and S. Shenker, "Integrated
1779
Services in the Internet Architecture: an Overview", RFC
1782
[IIS-SPEC] Shenker, S., Partridge, C. and R. Guerin, "Specification
1783
of Guaranteed Quality of Service", RFC 2212, September
1786
[ISDN-MIB] Roeck, G., "ISDN Management Information Base using
1787
SMIv2", RFC 2127, March 1997.
1794
Brownlee & Blount Informational [Page 32]
1796
RFC 2924 Accounting Attributes and Record Formats September 2000
1799
[ISO-DATE] "Data elements and interchange formats -- Information
1800
interchange -- Representation of dates and times", ISO
1803
[MAIL] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
1804
TEXT MESSAGES", STD 11, RFC 822, August 1982.
1806
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1809
[MSIX-SPEC] Blount, A. and D. Young, "Metered Service Information
1810
Exchange 1.2", Work in Progress.
1812
[NEWS-MSGS] Horton, M. and R. Adams, "Standard for Interchange of
1813
USENET Messages", RFC 1036, December 1987.
1815
[NEWS-PROT] Kantor, B. and P. Lapsley, "Network News Transfer
1816
Protocol", RFC 977, February 1986.
1818
[NTP] Mills, D., "Network Time Protocol (NTP)", RFC 958,
1821
[Q-825] "Specification of TMN applications at the Q3 interface:
1822
Call detail recording", ITU-T Recommendation Q.825, 1998.
1824
[RAD-ACT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1826
[RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS
1827
Extensions", RFC 2869, June 2000.
1829
[RAD-PROT] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1830
"Remote Authentication Dial In User Service (RADIUS)",
1831
RFC 2865, June 2000.
1833
[RAD-TACC] Zorn, G., Mitton, D. and A. Aboba, "RADIUS Accounting
1834
Modifications for Tunnel Protocol Support", RFC 2867,
1837
[RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
1838
and A. Sastry, "The COPS (Common Open Policy Service)
1839
Protocol", RFC 2748, January 2000.
1841
[ROAM-ADIF] Aboba, B. and D. Lidyard, "The Accounting Data
1842
Interchange Format (ADIF)", Work in Progress.
1844
[ROAM-IMPL] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang,
1845
"Review of Roaming Implementations", RFC 2194, September
1850
Brownlee & Blount Informational [Page 33]
1852
RFC 2924 Accounting Attributes and Record Formats September 2000
1855
[RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
1856
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
1857
Felstaine, "A Framework For Integrated Services Operation
1858
Over Diffserv Networks", Work in Progress.
1860
[RSVP-ARC] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
1861
Jamin, "Resource Reservation Protocol (RSVP) Version 1
1862
Functional Specification", RFC 2205, September 1997.
1864
[RSVP-MIB] Baker, F., Krawczyk, J. and A. Sastry, "RSVP Management
1865
Information Base using SMIv2", RFC 2206, September 1997.
1867
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
1868
Measurement: Architecture", RFC 2722, October 1999.
1870
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
1871
Measurement: Architecture", RFC 2720, October 1999.
1873
[RTFM-NEWA] Handelman, S., Brownlee, N., Ruth, G. and S. Stibler,
1874
"New Attributes for Traffic Flow Measurement", RFC 2724,
1877
[SIP-PROT] Handley, M., Schulzrinne, H., Schooler, E. and J.
1878
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
1881
[SMI-V2] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
1882
"Structure of Management Information Version 2 (SMIv2)",
1883
STD 58, RFC 2578, April 1999.
1885
[SNMP-OVER] "AN OVERVIEW OF SNMP V2.0", Diversified Data Resources,
1886
Inc., http://www.ddri.com, 1999.
1888
[TIPHON] "Telecommunications and Internet Protocol Harmonization
1889
Over Networks (TIPHON); Inter-domain pricing,
1890
authorization, and usage exchange", TS 101 321 V1.4.2,
1893
[XML] Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible
1894
Markup Language (XML) 1.0", W3C Recommendation, February
1906
Brownlee & Blount Informational [Page 34]
1908
RFC 2924 Accounting Attributes and Record Formats September 2000
1911
[XML-DATA] "XML Schema Part 2: Datatypes", W3C Working Draft 07
1912
April 2000, April 2000.
1914
[XML-SCHM] "XML Schema Part 1: Structures", W3C Working Draft 7
1915
April 2000, April 2000.
1917
13. Authors' Addresses
1920
Information Technology Systems & Services
1921
The University of Auckland
1923
Phone: +64 9 373 7599 x8941
1924
EMail: n.brownlee@auckland.ac.nz
1932
EMail: blount@alum.mit.edu
1962
Brownlee & Blount Informational [Page 35]
1964
RFC 2924 Accounting Attributes and Record Formats September 2000
1967
14. Full Copyright Statement
1969
Copyright (C) The Internet Society (2000). All Rights Reserved.
1971
This document and translations of it may be copied and furnished to
1972
others, and derivative works that comment on or otherwise explain it
1973
or assist in its implementation may be prepared, copied, published
1974
and distributed, in whole or in part, without restriction of any
1975
kind, provided that the above copyright notice and this paragraph are
1976
included on all such copies and derivative works. However, this
1977
document itself may not be modified in any way, such as by removing
1978
the copyright notice or references to the Internet Society or other
1979
Internet organizations, except as needed for the purpose of
1980
developing Internet standards in which case the procedures for
1981
copyrights defined in the Internet Standards process must be
1982
followed, or as required to translate it into languages other than
1985
The limited permissions granted above are perpetual and will not be
1986
revoked by the Internet Society or its successors or assigns.
1988
This document and the information contained herein is provided on an
1989
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1990
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1991
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1992
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1993
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1997
Funding for the RFC Editor function is currently provided by the
2018
Brownlee & Blount Informational [Page 36]
added
removed
doc/rfc/rfc2924.txt
