idnits 2.17.1 draft-ietf-aaa-accounting-attributes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 884 has weird spacing: '... byte byte...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 April 2000) is 8770 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC822' is mentioned on line 1143, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RADIUS' is mentioned on line 1161, but not defined == Missing Reference: 'NEWS' is mentioned on line 1215, but not defined == Missing Reference: 'NNTP' is mentioned on line 1238, but not defined == Unused Reference: 'ACC-BKG' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: 'NEWS-MSGS' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: 'RAD-RECX' is defined on line 1544, but no explicit reference was found in the text == Unused Reference: 'SIP-PROT' is defined on line 1587, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. 'ASG-NBR') (Obsoleted by RFC 3232) -- No information found for draft-calhoun-diameter-accounting- - is the name correct? -- No information found for draft-calhoun-diameter-authent- - is the name correct? -- No information found for draft-calhoun-diameter-framework- - is the name correct? ** Obsolete normative reference: RFC 1866 (ref. 'HTML') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2445 (ref. 'ICAL-CORE') (Obsoleted by RFC 5545) ** Obsolete normative reference: RFC 822 (ref. 'MAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1036 (ref. 'NEWS-MSGS') (Obsoleted by RFC 5536, RFC 5537) ** Obsolete normative reference: RFC 977 (ref. 'NEWS-PROT') (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 958 (ref. 'NTP') (Obsoleted by RFC 1059, RFC 1119, RFC 1305) ** Obsolete normative reference: RFC 2139 (ref. 'RAD-ACT') (Obsoleted by RFC 2866) -- No information found for draft-ietf-radius-ext- - is the name correct? ** Obsolete normative reference: RFC 2138 (ref. 'RAD-PROT') (Obsoleted by RFC 2865) -- No information found for draft-ietf-radius-acct-interim- - is the name correct? -- No information found for draft-ietf-radius-tunnel-acct- - is the name correct? -- No information found for draft-ietf-rap-cops- - is the name correct? -- No information found for draft-ietf-roamops-actng- - is the name correct? -- No information found for draft-ietf-issll-diffserv-rsvp- - is the name correct? -- No information found for draft-ietf-rsvp-mib-v2- - is the name correct? ** Obsolete normative reference: RFC 2543 (ref. 'SIP-PROT') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Nevil Brownlee 2 INTERNET-DRAFT The University of Auckland 3 Category: Informational Alan Blount 4 MetraTech Corp. 5 14 April 2000 7 Accounting Attributes and Record Formats 9 Status of this Memo 11 This document is an Internet-Draft, and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt . 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html . 30 The distribution of this memo is unlimited. It is filed as , and expires October 31, 2000. 32 Please send comments to the authors. 34 Abstract 36 This draft summarises IETF and ITU-T documents related to Accounting. 37 A classification scheme for the Accounting Attributes in the 38 summarised documents is presented. Exchange formats for Accounting 39 data records are discussed, as are advantages and disadvantages of 40 integrated versus separate record formats and transport protocols. 41 This draft discusses service definition independence, extensibility, 42 and versioning. Compound service definition capabilities are 43 described. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 49 3. Architecture Model . . . . . . . . . . . . . . . . . . . . . . 4 50 4. IETF Documents . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.1.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 5 53 4.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 4.2.1. DIAMETER Attributes . . . . . . . . . . . . . . . . . . . 7 55 4.3. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4.4. RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.4.1. RTFM Attributes . . . . . . . . . . . . . . . . . . . . . 9 58 4.5. ISDN MIB . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 4.5.1. ISDN Attributes . . . . . . . . . . . . . . . . . . . . . 10 60 4.6. AToMMIB . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 4.6.1. AToMMIB Attributes . . . . . . . . . . . . . . . . . . . . 11 62 4.7. QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . . 11 63 4.7.1. QoS: RSVP and DIFFSERV Attributes . . . . . . . . . . . . 12 64 5. ITU-T Documents . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.1. Q.825: Call Detail Recording . . . . . . . . . . . . . . . . 13 66 5.2. Q.825 Attributes . . . . . . . . . . . . . . . . . . . . . . 13 67 6. Other Documents . . . . . . . . . . . . . . . . . . . . . . . 17 68 6.1. TIPHON: ETSI TS 101 321 . . . . . . . . . . . . . . . . . . 17 69 6.2. MSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 7. Accounting File and Record Formats . . . . . . . . . . . . . . 18 71 7.1. ASN.1 Records . . . . . . . . . . . . . . . . . . . . . . . 18 72 7.1.1. RTFM and AToMMIB . . . . . . . . . . . . . . . . . . . . . 18 73 7.1.2. Q.825 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 7.2. Binary Records . . . . . . . . . . . . . . . . . . . . . . . 18 75 7.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 7.2.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.3. Text Records . . . . . . . . . . . . . . . . . . . . . . . . 19 78 7.3.1. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 8. AAA Requirements . . . . . . . . . . . . . . . . . . . . . . . 21 80 8.1. A Well-defined Set of Attributes . . . . . . . . . . . . . . 21 81 8.2. A Simple Interchange Format . . . . . . . . . . . . . . . . 21 82 9. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 9.1. Record Format vs. Protocol . . . . . . . . . . . . . . . . . 22 84 9.2. Tagged, Typed Data . . . . . . . . . . . . . . . . . . . . . 23 85 9.2.1. Standard Type Definitions . . . . . . . . . . . . . . . . 23 86 9.3. Transaction Identifiers . . . . . . . . . . . . . . . . . . 24 87 9.4. Service Definitions . . . . . . . . . . . . . . . . . . . . 24 88 9.4.1. Service Independence . . . . . . . . . . . . . . . . . . . 24 89 9.4.2. Versioned Service Definitions . . . . . . . . . . . . . . 26 90 9.4.3. Relationships Among Usage Events . . . . . . . . . . . . . 26 91 9.4.4. Service Namespace Management . . . . . . . . . . . . . . . 27 92 10. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 97 1. Introduction 99 This draft summarises IETF and ITU-T documents related to Accounting. 100 For those documents which describe Accounting Attributes (i.e. quan- 101 tities which can be measured and reported), an Attribute Summary is 102 given. Although several of the documents describe Attributes which 103 are similar, no attempt is made to identify those which are the same 104 in several documents. An extensible classification scheme for AAA 105 Accounting Attributes is proposed; it is a superset of the attributes 106 in all the documents summarised. 108 Many existing accounting record formats and protocols [RAD-ACT] 109 [TIPHON] are of limited use due to their single-service descriptive 110 facilities and lack of extensibility. While some record formats and 111 protocols support extensible attributes [RAD-ACT], none provide iden- 112 tification, type checking, or versioning support for defined group- 113 ings of attributes (service definitions). This draft makes a case 114 for well-defined services. 116 Advantages and disadvantages of integrated versus separate record 117 formats and transport protocols are discussed. This draft discusses 118 service definition independence, extensibility, and versioning. Com- 119 pound service definition capabilities are described. 121 2. Terminology and Notation 123 The following terms are used throughout the document. 125 Accounting Server 126 A network element that accepts Usage Events from Service Elements. 127 It acts as an interface to back-end rating, billing, and opera- 128 tions support systems. 130 Attribute-Value Pair (AVP) 131 A representation for a Usage Attribute consisting of the name of 132 the Attribute and a value. 134 Property 135 A component of a Usage Event. A Usage Event describing a phone 136 call, for instance, might have a "duration" Property. 138 Service 139 A type of task that is performed by a Service Element for a Ser- 140 vice Consumer. 142 Service Consumer 143 Client of a Service Element. End-user of a network service. 145 Service Definition 146 A specification for a particular service. It is composed of a 147 name or other identifier, versioning information, and a collection 148 of Properties. 150 Service Element 151 A network element that provides a service to Service Consumers. 152 Examples include RAS devices, voice and fax gateways, conference 153 bridges. 155 Usage Attribute 156 A component of a Usage Event that describes some metric of service 157 usage. 159 Usage Event 160 The description of an instance of service usage. 162 3. Architecture Model 164 Service Elements provide Services to Service Consumers. Before, 165 while, and/or after services are provided, the Service Element 166 reports Usage Events to an Accounting Server. Alternately, the 167 Accounting Server may query the Service Element for Usage Events. 168 Usage events are sent singly or in bulk. 170 +------------+ +-----------+ +------------+ 171 | Service |<----->| Service | Usage Events | Accounting | 172 | Consumer | +-->| Element |------------->| Server | 173 +------------+ | +-----------+ +------------+ 174 | 175 +------------+ | 176 | Service |<--+ 177 | Consumer | 178 +------------+ 180 Accounting Servers may forward Usage Events to other systems, possi- 181 bly in other administrative domains. These transfers are not 182 addressed by this document. 184 4. IETF Documents 186 In March 1999 there were at least 19 Internet Drafts and 8 RFCs con- 187 cerned with Accounting. These are summarised (by working group) in 188 the following sections. 190 4.1. RADIUS 192 The RADIUS protocol [RAD-PROT] carries authentication, authorization 193 and configuration information between a Network Access Server (NAS) 194 and an authentication server. Requests and responses carried by the 195 protocol are expressed in terms of RADIUS attributes such as User- 196 Name, Service-Type, and so on. These attributes provide the informa- 197 tion needed by a RADIUS server to authenticate users and to establish 198 authorized network service for them. 200 The protocol was extended to carry accounting information between a 201 NAS and a shared accounting server. This was achieved by defining a 202 set of RADIUS accounting attributes [RAD-ACT]. 204 RADIUS packets have a short header containing the RADIUS packet type 205 and authenticator (sixteen octets) and length, followed by a sequence 206 of (Type, Length, Value) triples, one for each attribute. 208 RADIUS is very widely used, and a number of significant new exten- 209 sions to it have been proposed. For example [RAD-EXT] discusses 210 extensions to implement the Extensible Authentication Protocol (EAP) 211 and the Apple Remote Access Protocol (ARAP). [RAD-TACC] discusses 212 extensions to permit RADIUS to interwork effectively with tunnels 213 using protocols such as PPTP and L2TP. 215 4.1.1. RADIUS Attributes 217 Each RADIUS attribute is identified by an 8-bit number, referred to 218 as the RADIUS Type field. Up-to-date values of this field are speci- 219 fied in the most recent Assigned Numbers RFC [ASG-NBR], but the cur- 220 rent list is as follows: 222 RADIUS Attributes [RAD-PROT] 36 Login-LAT-Group 223 37 Framed-AppleTalk-Link 224 1 User-Name 38 Framed-AppleTalk-Network 225 2 User-Password 39 Framed-AppleTalk-Zone 226 3 CHAP-Password 227 4 NAS-IP-Address 60 CHAP-Challenge 228 5 NAS-Port 61 NAS-Port-Type 229 6 Service-Type 62 Port-Limit 230 7 Framed-Protocol 63 Login-LAT-Port 231 8 Framed-IP-Address 232 9 Framed-IP-Netmask RADIUS Accounting Attributes 233 10 Framed-Routing [RAD-ACT] 234 11 Filter-Id 235 12 Framed-MTU 40 Acct-Status-Type 236 13 Framed-Compression 41 Acct-Delay-Time 237 14 Login-IP-Host 42 Acct-Input-Octets 238 15 Login-Service 43 Acct-Output-Octets 239 16 Login-TCP-Port 44 Acct-Session-Id 240 17 (unassigned) 45 Acct-Authentic 241 18 Reply-Message 46 Acct-Session-Time 242 19 Callback-Number 47 Acct-Input-Packets 243 20 Callback-Id 48 Acct-Output-Packets 244 21 (unassigned) 49 Acct-Terminate-Cause 245 22 Framed-Route 50 Acct-Multi-Session-Id 246 23 Framed-IPX-Network 51 Acct-Link-Count 247 24 State 248 25 Class RADIUS Extension Attributes 249 26 Vendor-Specific [RAD-EXT] 250 27 Session-Timeout 251 28 Idle-Timeout 52 Acct-Input-Gigawords 252 29 Termination-Action 53 Acct-Output-Gigawords 253 30 Called-Station-Id 54 Unused 254 31 Calling-Station-Id 55 Event-Timestamp 255 32 NAS-Identifier 256 33 Proxy-State 70 ARAP-Password 257 34 Login-LAT-Service 71 ARAP-Features 258 35 Login-LAT-Node 72 ARAP-Zone-Access 259 73 ARAP-Security 260 74 ARAP-Security-Data 261 75 Password-Retry 262 76 Prompt 263 77 Connect-Info 264 78 Configuration-Token 265 79 EAP-Message 266 80 Signature 268 84 ARAP-Challenge-Response 270 RADIUS Tunneling Attributes 271 [RAD-TACC] 273 51 Acct-Link-Count 275 64 Tunnel-Type 276 65 Tunnel-Medium-Type 277 66 Tunnel-Client-Endpoint 278 67 Tunnel-Server-Endpoint 279 68 Acct-Tunnel-Connection 280 69 Tunnel-Password 282 81 Tunnel-Private-Group-ID 283 82 Tunnel-Assignment-ID 284 83 Tunnel-Preference 286 4.2. DIAMETER 288 The DIAMETER framework [DIAM-FRAM] defines a policy protocol used by 289 clients to perform Policy, AAA and Resource Control. This allows a 290 single server to handle policies for many services. The DIAMETER 291 protocol consists of a header followed by objects. Each object is 292 encapsulated in a header known as an Attribute-Value Pair (AVP). 294 DIAMETER defines a base protocol that specifies the header formats, 295 security extensions and requirements as well as a small number of 296 mandatory commands and AVPs. A new service can extend DIAMETER by 297 extending the base protocol to support new functionality. 299 One key differentiator with DIAMETER is its inherent support for 300 Inter-Server communication. Although this can be achieved in a vari- 301 ety of ways, the most useful feature is the ability to "proxy" mes- 302 sages across a set of DIAMETER servers (known as a proxy chain). 304 The DIAMETER Accounting Extension document [DIAM-ACT] extends DIAME- 305 TER by defining a protocol for securely transferring accounting 306 records over the DIAMETER base protocol. This includes the case 307 where accounting records may be passed through one or more intermedi- 308 ate proxies, in accordance with the 'referral broker' model. 310 The DIAMETER accounting protocol [DIAM-ACT] defines DIAMETER records 311 for transferring an ADIF record (see below). It introduces five new 312 attributes (480..485) which specify the way in which accounting 313 information is to be delivered between DIAMETER servers. 315 4.2.1. DIAMETER Attributes 317 DIAMETER AVPs are identified by a 16-bit number defined in [DIAM- 318 AUTH]. Since most of the AVPs found in that document were copied 319 from the RADIUS protocol [RAD-PROT], it is possible to have both 320 RADIUS and DIAMETER servers read the same dictionary and users files. 322 The backward compatibility that DIAMETER offers is intended to facil- 323 itate deployment. To this end, DIAMETER inherits the RADIUS 324 attributes, and adds only a few of its own. 326 In the list below attribute numbers which are used for RADIUS 327 attributes but not for DIAMETER are indicated with a star (*). 328 RADIUS attributes used by DIAMETER are not listed again here. 330 The DIAMETER attributes are: 332 4 (unassigned, *) 333 17 (unassigned) 334 21 (unassigned) 335 24 (unassigned, *) 336 25 (unassigned, *) 337 27 (unassigned, *) 338 32 (unassigned, *) 339 33 (unassigned, *) 341 280 Filter-Rule 342 281 Framed-Password-Policy 344 480 Accounting-Record-Type 345 481 ADIF-Record 346 482 Accounting-Interim-Interval 347 483 Accounting-Delivery-Max-Batch 348 484 Accounting-Delivery-Max-Delay 349 485 Accounting-Record-Number 351 600 SIP-Sequence 352 601 SIP-Call-ID 353 602 SIP-To 354 603 SIP-From 356 4.3. ROAMOPS 358 [ROAM-IMPL] reviews the design and functionality of existing roaming 359 implementations. "Roaming capability" may be loosely defined as the 360 ability to use any one of multiple Internet service providers (ISPs), 361 while maintaining a formal customer-vendor relationship with only 362 one. One requirement for successful roaming is the provision of 363 effective accounting. 365 [ROAM-ADIF] proposes a standard accounting record format, the 366 Accounting Data Interchange Format (ADIF), which is designed to com- 367 pactly represent accounting data in a protocol-independent manner. 368 As a result, ADIF may be used to represent accounting data from any 369 protocol using attribute value pairs (AVPs) or variable bindings. 371 ADIF does not define accounting attributes of its own. Instead, it 372 gives examples of accounting records using the RADIUS accounting 373 attributes. 375 4.4. RTFM 377 The RTFM Architecture [RTFM-ARC] provides a general method of measur- 378 ing network traffic flows between "metered traffic groups." Each 379 RTFM flow has a set of "address" attributes, which define the traffic 380 groups at each of the flow's end-points. 382 As well as address attributes, each flow has traffic-related 383 attributes, e.g. times of first and last packets, counts for packets 384 and bytes in each direction. 386 RTFM flow measurements are made by RTFM meters [RTFM-MIB] and col- 387 lected by RTFM meter readers using SNMP. The MIB uses a "DataPackage" 388 convention, which specifies the attribute values to be read from a 389 flow table row. The meter returns the values for each required 390 attribute within a BER-encoded sequence. This means there is only 391 one object identifier for the whole sequence, greatly reducing the 392 number of bytes required to retrieve the data. 394 4.4.1. RTFM Attributes 396 RTFM attributes are identified by a 16-bit attribute number. 398 The RTFM Attributes are: 400 0 Null 401 1 Flow Subscript Integer Flow table info 403 4 Source Interface Integer Source Address 404 5 Source Adjacent Type Integer 405 6 Source Adjacent Address String 406 7 Source Adjacent Mask String 407 8 Source Peer Type Integer 408 9 Source Peer Address String 409 10 Source Peer Mask String 410 11 Source Trans Type Integer 411 12 Source Trans Address String 412 13 Source Trans Mask String 414 14 Destination Interface Integer Destination Address 415 15 Destination Adjacent Type Integer 416 16 Destination Adjacent Address String 417 17 Destination AdjacentMask String 418 18 Destination PeerType Integer 419 19 Destination PeerAddress String 420 20 Destination PeerMask String 421 21 Destination TransType Integer 422 22 Destination TransAddress String 423 23 Destination TransMask String 425 26 Rule Set Number Integer Meter attribute 427 27 Forward Bytes Integer Source-to-Dest counters 428 28 Forward Packets Integer 429 29 Reverse Bytes Integer Dest-to-Source counters 430 30 Reverse Packets Integer 431 31 First Time Timestamp Activity times 432 32 Last Active Time Timestamp 433 33 Source Subscriber ID String Session attributes 434 34 Destination Subscriber ID String 435 35 Session ID String 437 36 Source Class Integer "Computed" attributes 438 37 Destination Class Integer 439 38 Flow Class Integer 440 39 Source Kind Integer 441 40 Destination Kind Integer 442 41 Flow Kind Integer 444 50 MatchingStoD Integer PME variable 446 51 v1 Integer Meter Variables 447 52 v2 Integer 448 53 v3 Integer 449 54 v4 Integer 450 55 v5 Integer 452 65-127 "Extended" attributes 453 (to be defined by the RTFM working group) 455 4.5. ISDN MIB 457 The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for 458 SNMP-based management of ISDN terminal interfaces. It does not 459 explicitly define anything related to accounting, however it does 460 define isdnBearerChargedUnits as 462 The number of charged units for the current or last connection. 463 For incoming calls or if charging information is not supplied 464 by the switch, the value of this object is zero. 466 This allows for an ISDN switch to convert its traffic flow data (such 467 as Call Connect Time) into charging data. 469 4.5.1. ISDN Attributes 471 The relevant object in the MIB is the ISDN bearer table, which has 472 entries in the following form: 474 IsdnBearerEntry ::= 475 SEQUENCE { 476 isdnBearerChannelType INTEGER, 477 isdnBearerOperStatus INTEGER, 478 isdnBearerChannelNumber INTEGER, 479 isdnBearerPeerAddress DisplayString, 480 isdnBearerPeerSubAddress DisplayString, 481 isdnBearerCallOrigin INTEGER, 482 isdnBearerInfoType INTEGER, 483 isdnBearerMultirate TruthValue, 484 isdnBearerCallSetupTime TimeStamp, 485 isdnBearerCallConnectTime TimeStamp, 486 isdnBearerChargedUnits Gauge32 487 } 489 4.6. AToMMIB 491 The "ATM Accounting Information MIB" document [ATM-ACT] describes a 492 large set of accounting objects for ATM connections. An administra- 493 tor may select objects from this set using a selector of the form 494 (subtree, list) where "subtree" specifies an object identifier from 495 the AToMMIB. For each subtree there is a table holding values for 496 each ATM connection. The required connections are indicated by set- 497 ting bits in "list," which is an octet string. For example, the set 498 containing the number of received cells for the first eight ATM con- 499 nections would be selected by (atmAcctngReceivedCells, 0xFF). 501 The Connection-Oriented Accounting MIB document [ATM-COLL] defines a 502 MIB providing managed objects used for controlling the collection and 503 storage of accounting information for connection-oriented networks 504 such as ATM. The accounting data is collected into files for later 505 retrieval via a file transfer protocol. Records within an accounting 506 file are stored as BER strings [ASN1, BER]. 508 4.6.1. AToMMIB Attributes 510 Accounting data objects within the AToMMBIB are identified by the 511 last integer in their object identifiers. 513 The ATM accounting data objects are: 515 1 atmAcctngConnectionType 516 2 atmAcctngCastType 517 3 atmAcctngIfName 518 4 atmAcctngIfAlias 519 5 atmAcctngVpi 520 6 atmAcctngVci 521 7 atmAcctngCallingParty 522 8 atmAcctngCalledParty 523 9 atmAcctngCallReference 524 10 atmAcctngStartTime 525 11 atmAcctngCollectionTime 526 12 atmAcctngCollectMode 527 13 atmAcctngReleaseCause 528 14 atmAcctngServiceCategory 529 15 atmAcctngTransmittedCells 530 16 atmAcctngTransmittedClp0Cells 531 17 atmAcctngReceivedCells 532 18 atmAcctngReceivedClp0Cells 533 19 atmAcctngTransmitTrafficDescriptorType 534 20 atmAcctngTransmitTrafficDescriptorParam1 535 21 atmAcctngTransmitTrafficDescriptorParam2 536 22 atmAcctngTransmitTrafficDescriptorParam3 537 23 atmAcctngTransmitTrafficDescriptorParam4 538 24 atmAcctngTransmitTrafficDescriptorParam5 539 25 atmAcctngReceiveTrafficDescriptorType 540 26 atmAcctngReceiveTrafficDescriptorParam1 541 27 atmAcctngReceiveTrafficDescriptorParam2 542 28 atmAcctngReceiveTrafficDescriptorParam3 543 29 atmAcctngReceiveTrafficDescriptorParam4 544 30 atmAcctngReceiveTrafficDescriptorParam5 545 31 atmAcctngCallingPartySubAddress 546 32 atmAcctngCalledPartySubAddress 547 33 atmAcctngRecordCrc16 549 4.7. QoS: RSVP and DIFFSERV 551 As we move towards providing more than simple "best effort" connec- 552 tivity, there has been a tremendous surge of interest in (and work 553 on) protocols to provide managed Quality of Service for Internet ses- 554 sions. This is of particular interest for the provision of "Inte- 555 grated Services," i.e. the transport of audio, video, real-time, and 556 classical data traffic within a single network infrastructure. 558 Two approaches to this have emerged so far: 560 - the Integrated Services architecture (intserv) [IIS-ARC], with its 561 accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's 562 Common Open Policy Service protocol, COPS [RAP-COPS] 564 - the Differentiated Services architecture (diffserv) [DSRV-ARC] 566 RSVP is a signaling protocol that applications may use to request 567 resources from the network. The network responds by explicitly 568 admitting or rejecting RSVP requests. Certain applications that have 569 quantifiable resource requirements express these requirements using 570 intserv parameters [IIS-SPEC]. 572 Diffserv networks classify packets into one of a small number of 573 aggregated flows or "classes", based on the diffserv codepoint (DSCP) 574 in the packet's IP header. At each diffserv router, packets are sub- 575 jected to a "per-hop behavior" (PHB), which is invoked by the DSCP. 576 Since RSVP is purely a requirements signalling protocol it can also 577 be used to request connections from a diffserv network [RS-DS-OP]. 579 4.7.1. RSVP and DIFFSERV Attributes 581 A set of parameters for specifying a requested Quality of Service are 582 given in [IIS-SPEC]. These have been turned into accounting 583 attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP- 584 MIB]. 586 The RTFM QoS attributes are: 588 98 QoSService 589 99 QoSStyle 590 100 QoSRate 591 101 QoSSlackTerm 592 102 QoSTokenBucketRate 593 103 QoSTokenBucketSize 594 104 QoSPeakDataRate 595 105 QoSMinPolicedUnit 596 106 QoSMaxPolicedUnit 598 The RSVP MIB contains a large number of objects, arranged within the 599 following sections: 601 General Objects 602 Session Statistics Table 603 Session Sender Table 604 Reservation Requests Received Table 605 Reservation Requests Forwarded Table 606 RSVP Interface Attributes Table 607 RSVP Neighbor Table 609 The Session tables contain information such as the numbers of senders 610 and receivers for each session, while the Reservation Requests tables 611 contain details of requests handled by the RSVP router. There are 612 too many objects to list here, but many of them could be used for 613 accounting. In particular, RSVP Requests contain the specification 614 of the service parameters requested by a user; these, together with 615 the actual usage data for the connection make up an accounting record 616 for that usage. 618 5. ITU-T Documents 620 5.1. Q.825: Call Detail Recording 622 ITU-T Recommendation Q.825 specifies how CDRs (Call Detail Records) 623 are produced and managed in Network Elements for POTS, ISDN and IN 624 (Intelligent Networks). 626 Uses of Call Detail information for various purposes are discussed. 628 Each call produces one or more records describing events that 629 occurred during the life of a call. Data may be produced in real 630 time (single CDRs), near real-time (blocks of CDRs), or as batch 631 files of CDRs. 633 The information model for Call Detail Recording is formally described 634 in terms of an Entity-Relationship model, and an object model speci- 635 fied in terms of GDMO templates (Guidelines for the Definition of 636 Managed Objects). Note that this model includes the ways in which 637 CDRs are transported from the (NE) Network Element where they are 638 generated to the OS (Operations System) where they are used. 640 5.2. Q.825 Attributes 642 The following attributes are defined. The explanations given are 643 very brief summaries only, see [Q-825] for the complete text. 645 1 accessDelivery 646 Indicates that the call was delivered to the called subscriber 648 2 accountCodeInput 649 Account code (for billing), supplied by subscriber. 651 78 additionalParticipantInfo 652 (No details given) 654 5 b-PartyCategory 655 Subscriber category for called subscriber. 657 4 bearerService 658 Bearer capability information (only for ISDN calls). 660 13 cDRPurpose 661 Reason for triggering this Call Data Record. 663 70 callDetailDataId 664 Unique identifier for the CallDetailData object. 666 79 callDuration 667 Duration of call 669 6 callIdentificationNumber 670 Identification number for call; all records produced for this 671 call have the same callIdenfificationNumber. 673 73 callStatus 674 Identifies whether the call was answered or not. 676 9 calledPartyNumber 677 Telephone number of the called subscriber (may be a 678 "diverted-to" or "translated" number. 680 7 callingPartyCategory 681 Calling subscriber category. 683 8 callingPartyNumber 684 Telephone number of the calling party. 686 10 callingPartyNumberNotScreened 687 An additional, user-provided (not screened) number to the 688 calling party. 690 11 callingPartyType 691 Calling subscriber type. 693 74 carrierId 694 Carrier ID to which the call is sent. 696 12 cause 697 Cause and location value for the termination of the call. 699 14 chargedDirectoryNumber 700 Charged directory number (where the charged participant 701 element can't indicate the number). 703 16 chargedParticipant 704 Participant to be charged for the usage. 706 15 chargingInformation 707 Charging information generated by a Network Element which is 708 capable of charging. 710 17 configurationMask 711 Time consumption, e.g. from B-answer to termination time, 712 between partial call records, etc. 714 18 conversationTime 715 Time consumption from B-answer to end of call. 717 19 creationTriggerList 718 List of trigger values which will create Call Detail data 719 objects. 721 75 dPC 722 Destination point code (for analysis purposes). 724 20 dataValidity 725 Indicates that the NE is having problems, contents of the 726 generated Call Detail record is not reliable. 728 23 durationTimeACM 729 Time consumption from seizure until received ACM. 731 21 durationTimeB-Answer 732 Time consumption from seizure until B-answer. 734 22 durationTimeNoB-Answer 735 Time from seizure to termination when no B-answer was 736 received. 738 25 exchangeInfo 739 Identity of exchange where Call Detail record was generated. 741 26 fallbackBearerService 742 Fallback bearer capability information for a call. 744 27 glare 745 Indicates if a glare condition was encountered. 747 31 iNServiceInformationList 748 Contains information about the use of IN (Intelligent Network) 749 services. 751 32 iNSpecificInformation 752 Contains information about the use of one IN service. 754 33 iSUPPreferred 755 Indicate whether an ISUP preference was requested. 757 28 immediateNotificationForUsageMetering 758 Indicates that the Call Detail records requires 759 immediate data transfer to the Operations System. 761 34 maxBlockSize 762 Maximum number of Call Detail records in a block. 764 35 maxTimeInterval 765 Maximum latency allowable for near-real-time Call Detail 766 data delivery. 768 36 networkManagementControls 769 Indicates which Traffic Management Control has affected 770 the call. 772 37 networkProviderId 773 Indicates the Network Provider for whom the CDR is generated. 775 76 oPC 776 Originating point code for a failed call (for analysis 777 purposes). 779 38 operatorSpecific1AdditionalNumber 780 40 operatorSpecific2AdditionalNumber 781 42 operatorSpecific3AdditionalNumber 782 Operator-defined additional participant information. 784 39 operatorSpecific1Number 785 41 operatorSpecific2Number 786 43 operatorSpecific3Number 787 Operator-defined participant information. 789 44 originalCalledNumber 790 Telephone number of the original called party. 792 45 partialGeneration 793 Included if the CDR (Call Detail record) output is partial. 794 Such CDRs have a field indicating their partial record number. 796 77 participantInfo 797 (No details given). 799 46 percentageToBeBilled 800 Percentage to be billed when normal billing rules are 801 not to be followed. 803 47 periodicTrigger 804 Defines the intervals at which the CDR file should be created. 806 48 personalUserId 807 Internationally unique personal User Identity (for UPT calls). 809 49 physicalLineCode 810 Identifies the call subscriber's physical line. 812 50 progress 813 Describes an event which occurred during the life of a call. 815 51 queueInfo 816 Used to record usage of queueing resources with IN calls. 818 52 receivedDigits 819 The digits dialed by the subscriber. (Normally only included 820 for customer care purposes). 822 53 recordExtensions 823 Information elements added by network operators and/or 824 manufacturers in addition to the standard ones above. 826 6. Other Documents 828 6.1. TIPHON: ETSI TS 101 321 830 TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which han- 831 dles accounting and authorization requests and responses. 833 The following are elements selected from TIPHON's DTD that are used 834 for accounting. 836 837 Identifies a numeric value. Expressed using the period (.) as a 838 decimal separator with no punctuation as the thousands separator. 840 841 Contains a call's H.323 CallID value, and is thus used to 842 uniquely identify individual calls. 844 845 Defines the financial currency in use for the parent element. 847 854 Indicates the number of units being accounted. 856 857 Indicates a type of service being priced, authorized, or 858 reported. An empty Service element indicates basic Internet 859 telephony service, which is the only service type defined by 860 V1.4.2 of the specification. The specification notes that "Later 861 revisions of this standard are expected to specify more enhanced 862 service definitions to represent quality of service, 863 availability, payment methods, etc." 865 872 A restricted form of [ISO-DATE] that indicates the time at which 873 the component was generated. 875 876 Contains an integer, decimal valued identifier assigned to a 877 specific authorized transaction. 879 880 Indicates the units by which pricing is measured or usage 881 recorded. It shall contain one of the following values: 882 s seconds 883 p packets (datagrams) 884 byte bytes 886 887 Collects information describing the usage of a service. 889 6.2. MSIX 891 MSIX [MSIX-SPEC] is an XML-based protocol transported by HTTP that is 892 used to make accounting service definitions and transmit service 893 usage information. As its service definitions are parameterized and 894 dynamic, it makes no definition of services or attributes itself, but 895 allows implementors to make their own. It specifies only the base 896 data types that attributes may take: STRING, UNISTRING, INT32, FLOAT, 897 DOUBLE, BOOLEAN, TIMESTAMP. 899 7. Accounting File and Record Formats 901 7.1. ASN.1 Records 903 7.1.1. RTFM and AToMMIB 905 RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists 906 of attributes into accounting records. RTFM uses SNMP to retrieve 907 such records as BER strings, thus avoiding having to have an object 908 identifier for every object. 910 AToMMIB carries this a stage further by defining an accounting file 911 format in ASN.1 and making it available for retrieval by a file 912 transfer protocol, thereby providing a more efficient alternative to 913 simply retrieving the records using SNMP. 915 7.1.2. Q.825 917 A Q.825 Call Record is an ASN.1 SET containing a specified group of 918 the Q.825 attributes. Call records would presumably be encoded as 919 BER strings before being collected for later processing. 921 7.2. Binary Records 923 7.2.1. RADIUS 925 Radius packets carry a sequence of attributes and their values, as 926 (Type, Length, Value) triples. The format of the value field is one 927 of four data types. 929 string 0-253 octets 930 address 32 bit value, most significant octet first. 932 integer 32 bit value, most significant octet first. 934 time 32 bit value, most significant octet first -- seconds 935 since 00:00:00 GMT, January 1, 1970. The standard 936 Attributes do not use this data type but it is presented 937 here for possible use within Vendor-Specific attributes. 939 7.2.2. DIAMETER 941 Each DIAMETER message consists of multiple AVP's that are 32-bit 942 aligned, with the following format: 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | AVP Code | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | AVP Length | Reserved |P|T|V|R|M| 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Vendor ID (opt) | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Tag (opt) | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Data ... 956 +-+-+-+-+-+-+-+-+ 958 Code 959 The AVP Code identifies the attribute uniquely. If the Vendor- 960 Specific bit is set, the AVP Code is allocated from the vendor's 961 private address space. 963 The first 256 AVP numbers are reserved for backward 964 compatibility with RADIUS and are to be interpreted as per 965 RADIUS [RAD-PROT]. AVP numbers 256 and above are used for 966 DIAMETER, which are allocated by IANA. 968 AVP Length 969 A 16-bit field contains the total object length in bytes. 970 Must always be a multiple of 4, and at least 8. 972 AVP Flags 973 P Protected bit 974 T Tag bit 975 V Vendor-ID bit 976 R Reserved (MUST be set to 0) 977 M Mandatory bit 979 7.3. Text Records 980 7.3.1. ROAMOPS 982 ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a gen- 983 eral, text-based format for accounting data files, described in a 984 straightforward BNF grammar. Its file header contains a field indi- 985 cating the default protocol from which accounting attributes are 986 drawn. If an attribute from another protocol is to be used, it is 987 preceded by its protocol name, for example rtfm//27 would be RTFM's 988 "forward bytes" attribute. Comments in an ADIF file begin with a 989 cross-hatch. 991 Example: An ADIF file encoding RADIUS accounting data 993 version: 1 994 device: server3 995 description: Accounting Server 3 996 date: 02 Mar 1998 12:19:01 -0500 997 defaultProtocol: radius 999 #NAS-IP-Address 1000 4: 204.45.34.12 1001 #NAS-Port 1002 5: 12 1003 #NAS-Port-Type 1004 61: 2 1005 #User-Name 1006 1: fred@bigco.com 1007 #Acct-Status-Type 1008 40: 2 1009 #Acct-Delay-Time 1010 41: 14 1011 #Acct-Input-Octets 1012 42: 234732 1013 #Acct-Output-Octets 1014 43: 15439 1015 #Acct-Session-Id 1016 44: 185 1017 #Acct-Authentic 1018 45: 1 1019 #Acct-Session-Time 1020 46: 1238 1021 #Acct-Input-Packets 1022 47: 153 1023 #Acct-Output-Packets 1024 48: 148 1025 #Acct-Terminate-Cause 1026 49: 11 1027 #Acct-Multi-Session-Id 1028 50: 73 1029 #Acct-Link-Count 1030 51: 2 1032 8. AAA Requirements 1034 8.1. A Well-Defined Set of Attributes 1036 AAA needs a well-defined set of attributes whose values are to be 1037 carried in records to or from accounting servers. 1039 Most of the existing sets of documents described above include a set 1040 of attributes, identified by small integers. It is likely that these 1041 sets overlap, i.e. that some of them have attributes which represent 1042 the same quantity using different names in different sets. This sug- 1043 gests it might be possible to produce a single combined set of "uni- 1044 versal" accounting attributes, but such a "universal" set does not 1045 seem worthwhile. 1047 The ADIF approach of specifying a default protocol (from which 1048 attributes are assumed to come) and identifying any exceptions seems 1049 much more practical. We therefore propose that AAA should use the 1050 ADIF convention (or something like it) to identify attributes, 1051 together with all the sets of attributes covered by the [ASG-NBR] 1052 document. 1054 8.2. A Simple Interchange Format 1056 AAA needs a simple interchange file format, to be used for accounting 1057 data. Several schemes for packaging and transporting such data have 1058 been described above. 1060 The SNMP-based ones fit well within the context of an SNMP-based net- 1061 work management system. RTFM and AToMMIB provide ways to reduce the 1062 SNMP overhead for collecting data, and AToMMIB defines a complete 1063 file format. Both provide good ways to collect accounting data. 1065 As an interchange format, however, ASN.1-based schemes suffer from 1066 being rather complex binary structures. This means that one requires 1067 suitable tools to work with them, as compared to plain-text files 1068 where one can use existing text-based utilities. 1070 The binary schemes such as RADIUS and DIAMETER have simpler struc- 1071 tures, but they too need purpose-built tools. For general use they 1072 would need to be extended to allow them to use attributes from other 1073 protocols. 1075 From the point of view of being easy for humans to understand, ADIF 1076 seems very promising. Of course any processing program would need a 1077 suitable ADIF input parser, but using plain-text files makes them 1078 much easier to understand. 1080 TIPHON's record format is specified by an XML DTD. While XML repre- 1081 sentations have the advantages of being well-known, they are limited 1082 by XML's inability to specify type or other validity checking for 1083 information within the tags. This situation will likely be improved 1084 by the XML Schema [XML-SCHM] efforts that are underway, but a stable 1085 reference is not yet available. 1087 9. Issues 1089 It is generally agreed that there is a need for a standard record 1090 format and transport protocol for communication between Service Ele- 1091 ments and Accounting Servers. 1093 There is less agreement on the following issues: 1095 o Separate or integral record format and transport protocol 1096 o Standard set of base data types 1097 o Service definitions: part of the protocol or separately defined 1098 o Service definition namespace management 1100 The following sections address these issues. 1102 9.1. Record Format vs. Protocol 1104 All known Internet-centric billing protocols to date have an integral 1105 record format. That is, the collection of Properties that describe a 1106 Usage Event are specified as an integral part of the protocol, typi- 1107 cally as a part of a "submit" message that is used to transmit a 1108 Usage Event from a Service Entity to an Accounting Server. 1110 It may be advantageous to define a record format that is independent 1111 of the transport protocol. Such a record format should support both 1112 representation of individual records and records in bulk, as Usage 1113 Events are often aggregated and transmitted in bulk. 1115 A separate record format is useful for record archiving and temporary 1116 file storage. Multiple transport protocols may be defined without 1117 affecting the record format. The task of auditing is made easier if 1118 a standard file format is defined. If a canonical format is used, 1119 bulk records may be hashed with MD5 [MD5] or a similar function, for 1120 reliability and security purposes. 1122 +------------+ 1123 | transport | 1124 | header | 1125 +------------+ +------------+ 1126 | | | | 1127 | Usage | | Usage | 1128 | Event(s) | | Event(s) | 1129 | | | | 1130 | | | | 1131 +------------+ +------------+ 1132 | trailer | 1133 +------------+ 1135 record format transport protocol 1137 If the protocol is written such that it can transmit Usage Events in 1138 the record format, no record rewriting for transport is required. 1140 9.2. Tagged, Typed Data 1142 Record formats and protocols use a combination of data locality and 1143 explicit tagging to identify data elements. Mail [RFC822], for 1144 instance, defines a header block composed of several Attribute-Value 1145 Pairs, followed by a message body. Each header field is explicitly 1146 tagged, but the order of the AVPs is undefined. The message body is 1147 not tagged (except with an additional preceding blank line), and is 1148 found through its position in the message, which must be after all 1149 header fields. 1151 Some record formats make no use of tags--data elements are identified 1152 only by their position within a record structure. While this prac- 1153 tice provides for the least amount of record space overhead, it is 1154 difficult to later modify the record format by adding or removing 1155 elements, as all record readers will have to be altered to handle the 1156 change. Tagged data allows old readers to detect unexpected tags and 1157 to detect if required data are missing. If the overhead of carrying 1158 explicit tags can be borne, it is advantageous to use explicitly 1159 tagged data elements where possible. 1161 An AVP approach has proven useful in accounting. RADIUS [RADIUS] 1162 uses numeric data type identifiers. ETSI's TIPHON [TIPHON] uses XML 1163 markup. 1165 For an AAA accounting record format, the authors suggest that each 1166 Property be named by a textual or numeric identifier and carry a 1167 value and a data type indicator, which governs interpretation of the 1168 value. It may also be useful for each Property to carry a units of 1169 measure identifier. The TIPHON specification takes this approach. 1170 TS 101 321 also carries an Increment field, which denominates the 1171 Property's Unit of Measure field. Whether this additional conve- 1172 nience is necessary is a matter for discussion. 1174 It is not strictly necessary for each data record to carry data type, 1175 units of measure, or increments identifiers. If this information is 1176 recorded in a record schema document that is referenced by each data 1177 record, each record may be validated against the schema without the 1178 overhead of carrying type information. 1180 9.2.1. Standard Type Definitions 1182 It is useful to define a standard set of primitive data types to be 1183 used by the record format and protocol. Looking at the prior art, 1184 DIAMETER supports Data (arbitrary octets), String (UTF-8), Address 1185 (32 or 128 bit), Integer32, Integer64, Time (32 bits, seconds since 1186 1970), and Complex. MSIX [MSIX-SPEC] supports String, Unistring, 1187 Int32, Float, Double, Boolean, and Timestamp. SNMP [SNMP] offers 1188 OBJECT IDENTIFIER, NULL, OCTET STRING, IpAddress, NetworkAddress, 1189 Counter, Gauge, TimeTicks, and Opaque. 1191 An appropriate set would likely include booleans, 32 and 64 bit 1192 signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and 1193 UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps. Fixed- 1194 precision numbers capable of representing currency amounts (with pre- 1195 cision specified on both sides of the decimal point) have proven use- 1196 ful in accounting record formats, as they are immune to the precision 1197 problems that are encountered when one attempts to represent fixed- 1198 point amounts with floating point numbers. 1200 9.3. Transaction Identifiers 1202 Each Usage Event requires its own unique identifier. 1204 It is expedient to allow Service Elements to create their own unique 1205 identifiers. In this manner, Usage Events can be created and 1206 archived without the involvement of an Accounting Server or other 1207 central authority. 1209 A number of methods for creating unique identifiers are well known. 1210 One popular identifier is an amalgamation of a monotonically increas- 1211 ing sequence number, a large random value, a network element identi- 1212 fier, and a timestamp. Another possible source of entropy is a hash 1213 value of all or part of the record itself. 1215 RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give guid- 1216 ance on the creation of good unique identifiers. 1218 9.4. Service Definitions 1220 A critical differentiator in accounting record formats and protocols 1221 is their capability to account for arbitrary service usage. To date, 1222 no accounting record format or protocol that can handle arbitrary 1223 service definitions has achieved broad acceptance on the Internet. 1225 This section analyzes the issues in service definition and makes a 1226 case for a record format and protocol with the capability to carry 1227 Usage Events for rich, independently-defined services. 1229 9.4.1. Service Independence 1231 It is informative to survey a number of popular Internet protocols 1232 and document encodings and examine their capacities for extension. 1233 These protocols can be categorized into two broad categories--"fully 1234 specified" protocols that have little provision for extension and 1235 "framework" protocols that are incomplete, but provide a basis for 1236 future extension when coupled with application documents. 1238 Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP], 1239 RADIUS Accounting [RAD-ACT], and HTML [HTML]. 1241 Aside from leaving some field values "reserved for future use," all 1242 of Network Time Protocol's fields are fixed-width and completely 1243 defined. This is appropriate for a simple protocol that solves a 1244 simple problem. 1246 Network News Transfer Protocol [NEWS-PROT] specifies that further 1247 commands may be added, and requests that non-standard implementations 1248 use the "X-" experimental prefix so as to not conflict with future 1249 additions. The content of news is 7-bit data, with the high-order 1250 bit cleared to 0. Nothing further about the content is defined. 1251 There is no in-protocol facility for automating decoding of content 1252 type. 1254 We pay particular attention to RADIUS Accounting [RAD-ACT]. Perhaps 1255 the second most frequently heard complaint (after security shortcom- 1256 ings) about RADIUS Accounting is its preassigned and fixed set of 1257 "Types". These are coded as a range of octets from 40 to 51 and are 1258 as follows: 1260 40 Acct-Status-Type 1261 41 Acct-Delay-Time 1262 42 Acct-Input-Octets 1263 43 Acct-Output-Octets 1264 44 Acct-Session-Id 1265 45 Acct-Authentic 1266 46 Acct-Session-Time 1267 47 Acct-Input-Packets 1268 48 Acct-Output-Packets 1269 49 Acct-Terminate-Cause 1270 50 Acct-Multi-Session-Id 1271 51 Acct-Link-Count 1273 These identifiers were designed to account for packet-based network 1274 access service. They are ill-suited for describing other services. 1275 While extension documents have specified additional types, the base 1276 protocol limits the type identifier to a single octet, limiting the 1277 total number of types to 256. 1279 HTML/2.0 [HTML] is mostly a fully-specified protocol, but with W3C's 1280 HTML/4.0, HTML is becoming more of a framework protocol. HTML/2.0 1281 specified a fixed set of markups, with no provision for addition 1282 (without protocol revision). 1284 Examples of "framework" protocols and document encodings are HTTP, 1285 XML, and SNMP. 1287 HTTP/1.1 [HTTP] is somewhat similar to NNTP in that it is designed to 1288 transport arbitrary content. It is different in that it supports 1289 description of that content through its Content-Type, Content-Encod- 1290 ing, Accept-Encoding, and Transfer-Encoding header fields. New types 1291 of content can be designated and carried by HTTP/1.1 without modifi- 1292 cation to the HTTP protocol. 1294 XML [XML] is a preeminent general-purpose framework encoding. DTD 1295 publishing is left to users. There is no standard registry of DTDs. 1297 SNMP presents a successful example of a framework protocol. SNMP's 1298 authors envisioned SNMP as a general management protocol, and allow 1299 extension through the use of private MIBs. SNMP's ASN.1 MIBs are 1300 defined, published, and standardized without the necessity to modify 1301 the SNMP standard itself. From "An Overview of SNMP" [SNMP-OVER]: 1303 It can easily be argued that SNMP has become prominent mainly from 1304 its ability to augment the standard set of MIB objects with new 1305 values specific for certain applications and devices. Hence, new 1306 functionality can continuously be added to SNMP, since a standard 1307 method has been defined to incorporate that functionality into 1308 SNMP devices and network managers. 1310 Most accounting protocols are fully-specified, with either a com- 1311 pletely defined service or set of services (RADIUS Accounting) or 1312 with one or more services defined and provision for "extension" ser- 1313 vices to be added to the protocol later (TIPHON). While the latter 1314 is preferable, it may be preferable to take a more SNMP-like 1315 approach, where the accounting record format and protocol provide 1316 only a framework for service definition, and leave the task of ser- 1317 vice definition (and standardization) to separate efforts. In this 1318 manner, the accounting protocol itself would not have to be modified 1319 to handle new services. 1321 9.4.2. Versioned Service Definitions 1323 Versioning is a naming and compatibility issue. Version identifiers 1324 are useful in service definition because they enable service defini- 1325 tions to be upgraded without a possibly awkward name change. They 1326 also enable possible compatibility between different versions of the 1327 same service. 1329 An example could be the service definition of a phone call. Version 1330 1 might define Properties for the start time, duration, and called 1331 and calling party numbers. Later, version 2 is defined, which aug- 1332 ments the former service definition with a byte count. An Accounting 1333 Server, aware only of Version 1, may accept Version 2 records, dis- 1334 carding the additional information (forward compatibility). Alter- 1335 nately, if an Accounting Server is made aware of version 2, it could 1336 optionally still accept version 1 records from Service Elements, pro- 1337 vided the Accounting Sever does not require the additional informa- 1338 tion to properly account for service usage (backward compatibility). 1340 9.4.3. Relationships Among Usage Events 1342 Accounting record formats and protocols to date do not sufficiently 1343 addressed "compound" service description. 1345 A compound service is a service that is described as a composition of 1346 other services. A conference call, for example, may be described as 1347 a number of point-to-point calls to a conference bridge. It is 1348 important to account for the individual calls, rather than just sum- 1349 ming up an aggregate, both for auditing purposes and to enable dif- 1350 ferential rating. If these calls are to be reported to the Account- 1351 ing Server individually, the Usage Events require a shared identifier 1352 that can be used by the Accounting Server and other backend systems 1353 to group the records together. 1355 In order for a Service Element to report compound events over time as 1356 a succession of individual Usage Events, the accounting protocol 1357 requires a facility to communicate that the compound event has 1358 started and stopped. The "start" message can be implicit--the trans- 1359 mission of the first Usage Event will suffice. An additional 1360 semaphore is required to tell the Accounting Server that the compound 1361 service is complete and may be further processed. This is necessary 1362 to prevent the Accounting Server from prematurely processing compound 1363 events that overlap the end of a billing period. 1365 RADIUS Accounting has some provision for this sort of accounting with 1366 its "Acct-Multi-Session-Id" field. Unfortunately, RADIUS Account- 1367 ing's other shortcomings preclude it from being used in general pur- 1368 pose service usage description. 1370 9.4.4. Service Namespace Management 1372 "Framework" protocols, as previously mentioned, do not define com- 1373 plete schema for their payload. For interoperability to be achieved, 1374 it must be possible for: 1376 (1) content definers to specify definitions without conflicting with 1377 the names of other definitions 1379 (2) protocol users to find and use content definitions 1381 Condition (1) can be readily managed through IANA assignment or by 1382 using an existing namespace differentiator (for example, DNS). 1384 Condition (2) is harder, and places considerable burden on the imple- 1385 mentors. Their clients and servers must be able, statically or 1386 dynamically, to find and validate definitions, and manage versioning 1387 issues. 1389 As previously mentioned, the XML specification provides no facility 1390 for DTD discovery or namespace management. XML specifies only a doc- 1391 ument format, and as such does not need to specify support for more 1392 "protocol" oriented problems. 1394 For an accounting record format and protocol, an approach closer to 1395 SNMP's is useful. SNMP uses an ISO-managed dotted-decimal namespace. 1396 An IANA-managed registry of service types is a possibility. Another 1397 possibility, used by MSIX [MSIX-SPEC], is for Service Element cre- 1398 ators to identify their services by concatenation of a new service 1399 name with existing unique identifier, such as a domain name. 1401 A standard record format for service definitions would make it possi- 1402 ble for Service Element creators to directly supply accounting system 1403 managers with the required definitions, via the network or other 1404 means. 1406 10. Encodings 1408 It may be useful to define more than one record encoding. 1410 A "verbose" XML encoding is easily implemented and records can be 1411 syntactically verified with existing tools. "Human-readable" proto- 1412 cols tend to have an edge on "bitfield" protocols where ease of 1413 implementation is paramount and the application can tolerate any 1414 additional processing required to generate, parse, and transport the 1415 records. 1417 A alternative "compressed" encoding that makes minimal use of storage 1418 and processing may be useful in many contexts. 1420 There are disadvantages to supporting multiple encodings. Option- 1421 ally-supported multiple encodings mandate the requirement for capa- 1422 bilities exchange between Service Element and Accounting Server. 1423 Also, implementations can tend to "drift apart," with one encoding 1424 better-supported than another. Unless all encodings are mandatory, 1425 implementors may find they are unable to interoperate because they 1426 picked the wrong encoding. 1428 11. Security Considerations 1430 This draft summarises many existing IETF and ITU documents; please 1431 refer to the original documents for security considerations for their 1432 particular protocols. 1434 It must be possible for the accounting protocol to be carried by a 1435 secure transport. A canonical record format is useful so that regen- 1436 eration of secure record hashes is possible. 1438 When dealing with accounting data files, one must take care that 1439 their integrity and privacy are preserved. This document, however, 1440 is only concerned with the format of such files. 1442 12. References 1444 [ACC-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet 1445 Accounting Background", RFC 1272, November 1991. 1447 [ASG-NBR] Reynolds, J., Postel, J., "Assigned Numbers," 1448 RFC 1700, October 1994. 1450 [ASN1] Information processing systems - Open Systems 1451 Interconnection - Specification of Abstract Syntax Notation 1452 One (ASN.1), International Organization for Standardization, 1453 International Standard 8824, December 1987. 1455 [ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, 1456 A., "Accounting Information for ATM Networks," 1457 RFC 2512, February 1999. 1459 [ATM-COLL] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, 1460 A., " Managed Objects for Controlling the Collection 1461 and Storage of Accounting Information for Connection- 1462 Oriented Networks," RFC 2513, February 1999. 1464 [BER] Information processing systems - Open Systems 1465 Interconnection - Specification of Basic Encoding Rules for 1466 Abstract Notation One (ASN.1), International Organization for 1467 Standardization, International Standard 8825, December 1987. 1469 [DIAM-ACT] Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G., 1470 "DIAMETER Accounting Extension," Internet Draft (Work 1471 in progress), draft-calhoun-diameter-accounting- .. 1473 [DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User 1474 Authentication Extensions," Internet Draft (Work in 1475 progress), draft-calhoun-diameter-authent- .. 1477 [DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER 1478 Framework Document," Internet Draft (Work in 1479 progress), draft-calhoun-diameter-framework- .. 1481 [DSRV-ARC] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 1482 and W. Weiss, "An Architecture for Differentiated 1483 Services", RFC 2475, December 1998. 1485 [HTML] Berners-Lee, T., D. Connolly, "Hypertext Markup Language - 1486 2.0", RFC 1866, November 1995. 1488 [HTTP] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, and 1489 T. Berners-Lee. "Hypertext Transfer Protocol--HTTP/1.1", 1490 RFC 2068, January 1997. 1492 [ICAL-CORE] Dawson, F., D. Stenerson, "Internet Calendaring and 1493 Scheduling Core Object Specification", RFC 2445, November 1494 1998. 1496 [IIS-ARC] Braden, R., Clark, D. and Shenker, S., "Integrated 1497 Services in the Internet Architecture: an Overview", 1498 RFC 1633, June 1994 1500 [IIS-SPEC] Shenker, S., Partridge, C., Guerin, R.: "Specification of 1501 Guaranteed Quality of Service," RFC 2212, 1997. 1503 [ISDN-MIB] Roeck, G., "ISDN Management Information Base using 1504 SMIv2," RFC 2127, March 1997. 1506 [ISO-DATE] "Data elements and interchange formats -- Information 1507 interchange -- Representation of dates and times", 1508 ISO 8601:1988. 1510 [MAIL] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 1511 MESSAGES", RFC 822, August 1982. 1513 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1514 April 1992. 1516 [MSIX-SPEC] Blount, A., D. Young, "Metered Service Information Exchange 1517 1.2", Work in Progress, 1518 http://www.msix.org/draft-blount-acct-msix-00.txt, 1519 July 1999. 1521 [NEWS-MSGS] Horton, M., R. Adams, "Standard for Interchange of USENET 1522 Messages", RFC 1036, December 1987. 1524 [NEWS-PROT] Kantor, B., P. Lapsley, "Network News Transfer Protocol" 1525 RFC 977, February 1986. 1527 [NTP] Mills, D.L., "Network Time Protocol (NTP)", RFC 958, 1528 September 1985. 1530 [Q-825] "Specification of TMN applications at the Q3 1531 interface: Call detail recording," 1532 ITU-T Recommendation Q.825, 1998. 1534 [RAD-ACT] Rigney, C., "RADIUS Accounting," RFC 2139, April 1997. 1536 [RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS 1537 Extensions," Internet Draft (Work in progress), 1538 draft-ietf-radius-ext- .. 1540 [RAD-PROT] Rigney, C., Rubens, A., Simpson, W. and Willens, S., 1541 "Remote Authentication Dial In User Service (RADIUS)," 1542 RFC 2138, April 1997. 1544 [RAD-RECX] Calhoun, P.R. and Beadles, M.., "RADIUS Accounting 1545 Interim Accounting Record Extension," Internet Draft 1546 (Work in progress), draft-ietf-radius-acct-interim- .. 1548 [RAD-TACC] Zorn, G., Mitton, D. and Aboba, A.,"RADIUS Accounting 1549 "Modifications for Tunnel Protocol Support," 1550 (Work in progress), draft-ietf-radius-tunnel-acct- .. 1552 [RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. 1553 and Sastry, A., "The COPS (Common Open Policy Service) 1554 draft-ietf-rap-cops- .. 1556 [ROAM-ADIF] Aboba, B and Lidyard, D., "The Accounting Data 1557 Interchange Format (ADIF)," Internet Draft (Work 1558 in progress), draft-ietf-roamops-actng- .. 1560 [ROAM-IMPL] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, 1561 "Review of Roaming Implementations", 1562 RFC 2194, September 1997. 1564 [RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1565 Speer, M. and Braden, R., "Interoperation of RSVP/Intserv 1566 and Diffserv Networks," Internet Draft (Work in Progress), 1567 draft-ietf-issll-diffserv-rsvp- .. 1569 [RSVP-ARC] Braden, R., Zhang, L., Berson, S., Herzog, S. and 1570 Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 1571 Functional Specification", RFC 2205, September 1997 1573 [RSVP-MIB] Baker, F., Krawczyk, J. and Sastry, A., "RSVP Management 1574 Information Base," Internet Draft (Work in Progress), 1575 draft-ietf-rsvp-mib-v2- .. 1577 [RTFM-ARC] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow 1578 Measurement: Architecture", RFC 2722, October 1999. 1580 [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 1581 Measurement: Architecture", RFC 2720, October 1999. 1583 [RTFM-NEWA] Handelman, S, Brownlee, N., Ruth, G., and Stibler, S., 1584 "New Attributes for Traffic Flow Measurement", 1585 RFC 2724, October 1999. 1587 [SIP-PROT] Handley, M.,Schulzrinne, H.,Schooler, E. and 1588 Rosenberg, J., "SIP: session initiation protocol," 1589 RFC 2543, March 1999. 1591 [SNMP] Case, J., M. Fedor, M. Schoffstall, J. Davin, "A Simple 1592 Network Management Protocol (SNMP)", RFC 1157, May 1990 1594 [SNMP-OVER] "AN OVERVIEW OF SNMP V2.0", Diversified Data Resources, Inc., 1595 http://www.ddri.com, 1999. 1597 [TIPHON] "Telecommunications and Internet Protocol Harmonization Over 1598 Networks (TIPHON); Inter-domain pricing, authorization, and 1599 usage exchange", TS 101 321 V1.4.2, December 1998. 1601 [XML] Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible 1602 Markup Language (XML) 1.0", W3C Recommendation, February 1603 1998. 1605 [XML-SCHM] "XML Schema Part 1: Structures", W3C Working Draft 17, 1606 December 1999. 1608 13. Authors' Addresses 1610 Alan Blount 1611 MetraTech Corp. 1612 330 Bear Hill Road 1613 Waltham, MA 02451 1614 Email: blount@alum.mit.edu 1616 Nevil Brownlee 1617 Information Technology Systems & Services 1618 The University of Auckland 1619 Phone: +64 9 373 7599 x8941 1620 E-mail: n.brownlee@auckland.ac.nz