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]