idnits 2.17.1 draft-ietf-aaa-accounting-attributes-02.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-25) 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 31 longer pages, the longest (page 2) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 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 15 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 896 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 (7 March 2000) is 8815 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 1147, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RADIUS' is mentioned on line 1165, but not defined == Missing Reference: 'NEWS' is mentioned on line 1219, but not defined == Missing Reference: 'NNTP' is mentioned on line 1242, but not defined == Unused Reference: 'ACC-BKG' is defined on line 1448, but no explicit reference was found in the text == Unused Reference: 'NEWS-MSGS' is defined on line 1530, but no explicit reference was found in the text == Unused Reference: 'RAD-RECX' is defined on line 1553, but no explicit reference was found in the text == Unused Reference: 'SIP-PROT' is defined on line 1596, 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? -- No information found for draft-pan-diameter-sip- - 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 (==), 14 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 7 March 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 September 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.6.1. AToMMIB Attributes . . . . . . . . . . . . . . . . . . . . 11 62 4.7. QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . 19 75 7.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 7.2.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.3. Text Records . . . . . . . . . . . . . . . . . . . . . . . . 20 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 Policy and Accounting Extension for SIP (Session Initia- 305 tion Protocol) document [DIAM-SIP] extends DIAMETER by adding a pol- 306 icy and accounting information exchange mechanism between a DIAMETER 307 policy server and a SIP proxy server. 309 A DIAMETER server is responsible for maintaining a user policy and 310 accounting database and a means to update it. A SIP proxy server 311 needs to contact a DIAMETER server during multimedia session setup 312 and teardown time to perform admission control and accounting tasks. 313 The exchange mechanism protocol does not make any assumption about 314 policy and billing algorithms at DIAMETER servers. 316 The DIAMETER Accounting Extension document [DIAM-ACT] extends DIAME- 317 TER by defining a protocol for securely transferring accounting 318 records over the DIAMETER base protocol. This includes the case 319 where accounting records may be passed through one or more intermedi- 320 ate proxies, in accordance with the 'referral broker' model. 322 The DIAMETER accounting protocol [DIAM-ACT] defines DIAMETER records 323 for transferring an ADIF record (see below). It introduces five new 324 attributes (480..485) which specify the way in which accounting 325 information is to be delivered between DIAMETER servers. 327 4.2.1. DIAMETER Attributes 329 DIAMETER AVPs are identified by a 16-bit number defined in [DIAM- 330 AUTH]. Since most of the AVPs found in that document were copied 331 from the RADIUS protocol [RAD-PROT], it is possible to have both 332 RADIUS and DIAMETER servers read the same dictionary and users files. 334 The backward compatibility that DIAMETER offers is intended to facil- 335 itate deployment. To this end, DIAMETER inherits the RADIUS 336 attributes, and adds only a few of its own. 338 In the list below attribute numbers which are used for RADIUS 339 attributes but not for DIAMETER are indicated with a star (*). 341 RADIUS attributes used by DIAMETER are not listed again here. 343 The DIAMETER attributes are: 345 4 (unassigned, *) 346 17 (unassigned) 347 21 (unassigned) 348 24 (unassigned, *) 349 25 (unassigned, *) 350 27 (unassigned, *) 351 32 (unassigned, *) 352 33 (unassigned, *) 354 280 Filter-Rule 355 281 Framed-Password-Policy 357 480 Accounting-Record-Type 358 481 ADIF-Record 359 482 Accounting-Interim-Interval 360 483 Accounting-Delivery-Max-Batch 361 484 Accounting-Delivery-Max-Delay 362 485 Accounting-Record-Number 364 600 SIP-Sequence 365 601 SIP-Call-ID 366 602 SIP-To 367 603 SIP-From 369 4.3. ROAMOPS 371 [ROAM-IMPL] reviews the design and functionality of existing roaming 372 implementations. "Roaming capability" may be loosely defined as the 373 ability to use any one of multiple Internet service providers (ISPs), 374 while maintaining a formal customer-vendor relationship with only 375 one. One requirement for successful roaming is the provision of 376 effective accounting. 378 [ROAM-ADIF] proposes a standard accounting record format, the 379 Accounting Data Interchange Format (ADIF), which is designed to com- 380 pactly represent accounting data in a protocol-independent manner. 381 As a result, ADIF may be used to represent accounting data from any 382 protocol using attribute value pairs (AVPs) or variable bindings. 384 ADIF does not define accounting attributes of its own. Instead, it 385 gives examples of accounting records using the RADIUS accounting 386 attributes. 388 4.4. RTFM 390 The RTFM Architecture [RTFM-ARC] provides a general method of measur- 391 ing network traffic flows between "metered traffic groups." Each 392 RTFM flow has a set of "address" attributes, which define the traffic 393 groups at each of the flow's end-points. 395 As well as address attributes, each flow has traffic-related 396 attributes, e.g. times of first and last packets, counts for packets 397 and bytes in each direction. 399 RTFM flow measurements are made by RTFM meters [RTFM-MIB] and col- 400 lected by RTFM meter readers using SNMP. The MIB uses a "DataPackage" 401 convention, which specifies the attribute values to be read from a 402 flow table row. The meter returns the values for each required 403 attribute within a BER-encoded sequence. This means there is only 404 one object identifier for the whole sequence, greatly reducing the 405 number of bytes required to retrieve the data. 407 4.4.1. RTFM Attributes 409 RTFM attributes are identified by a 16-bit attribute number. 411 The RTFM Attributes are: 413 0 Null 414 1 Flow Subscript Integer Flow table info 416 4 Source Interface Integer Source Address 417 5 Source Adjacent Type Integer 418 6 Source Adjacent Address String 419 7 Source Adjacent Mask String 420 8 Source Peer Type Integer 421 9 Source Peer Address String 422 10 Source Peer Mask String 423 11 Source Trans Type Integer 424 12 Source Trans Address String 425 13 Source Trans Mask String 427 14 Destination Interface Integer Destination Address 428 15 Destination Adjacent Type Integer 429 16 Destination Adjacent Address String 430 17 Destination AdjacentMask String 431 18 Destination PeerType Integer 432 19 Destination PeerAddress String 433 20 Destination PeerMask String 434 21 Destination TransType Integer 435 22 Destination TransAddress String 436 23 Destination TransMask String 438 26 Rule Set Number Integer Meter attribute 440 27 Forward Bytes Integer Source-to-Dest counters 441 28 Forward Packets Integer 442 29 Reverse Bytes Integer Dest-to-Source counters 443 30 Reverse Packets Integer 444 31 First Time Timestamp Activity times 445 32 Last Active Time Timestamp 446 33 Source Subscriber ID String Session attributes 447 34 Destination Subscriber ID String 448 35 Session ID String 449 36 Source Class Integer "Computed" attributes 450 37 Destination Class Integer 451 38 Flow Class Integer 452 39 Source Kind Integer 453 40 Destination Kind Integer 454 41 Flow Kind Integer 456 50 MatchingStoD Integer PME variable 458 51 v1 Integer Meter Variables 459 52 v2 Integer 460 53 v3 Integer 461 54 v4 Integer 462 55 v5 Integer 464 65-127 "Extended" attributes 465 (to be defined by the RTFM working group) 467 4.5. ISDN MIB 469 The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for 470 SNMP-based management of ISDN terminal interfaces. It does not 471 explicitly define anything related to accounting, however it does 472 define isdnBearerChargedUnits as 474 The number of charged units for the current or last connection. 475 For incoming calls or if charging information is not supplied 476 by the switch, the value of this object is zero. 478 This allows for an ISDN switch to convert its traffic flow data (such 479 as Call Connect Time) into charging data. 481 4.5.1. ISDN Attributes 483 The relevant object in the MIB is the ISDN bearer table, which has 484 entries in the following form: 486 IsdnBearerEntry ::= 487 SEQUENCE { 488 isdnBearerChannelType INTEGER, 489 isdnBearerOperStatus INTEGER, 490 isdnBearerChannelNumber INTEGER, 491 isdnBearerPeerAddress DisplayString, 492 isdnBearerPeerSubAddress DisplayString, 493 isdnBearerCallOrigin INTEGER, 494 isdnBearerInfoType INTEGER, 495 isdnBearerMultirate TruthValue, 496 isdnBearerCallSetupTime TimeStamp, 497 isdnBearerCallConnectTime TimeStamp, 498 isdnBearerChargedUnits Gauge32 499 } 501 4.6. AToMMIB 503 The "ATM Accounting Information MIB" document [ATM-ACT] describes a 504 large set of accounting objects for ATM connections. An administra- 505 tor may select objects from this set using a selector of the form 506 (subtree, list) where "subtree" specifies an object identifier from 507 the AToMMIB. For each subtree there is a table holding values for 508 each ATM connection. The required connections are indicated by set- 509 ting bits in "list," which is an octet string. For example, the set 510 containing the number of received cells for the first eight ATM con- 511 nections would be selected by (atmAcctngReceivedCells, 0xFF). 513 The Connection-Oriented Accounting MIB document [ATM-COLL] defines a 514 MIB providing managed objects used for controlling the collection and 515 storage of accounting information for connection-oriented networks 516 such as ATM. The accounting data is collected into files for later 517 retrieval via a file transfer protocol. Records within an accounting 518 file are stored as BER strings [ASN1, BER]. 520 4.6.1. AToMMIB Attributes 522 Accounting data objects within the AToMMBIB are identified by the 523 last integer in their object identifiers. 525 The ATM accounting data objects are: 527 1 atmAcctngConnectionType 528 2 atmAcctngCastType 529 3 atmAcctngIfName 530 4 atmAcctngIfAlias 531 5 atmAcctngVpi 532 6 atmAcctngVci 533 7 atmAcctngCallingParty 534 8 atmAcctngCalledParty 535 9 atmAcctngCallReference 536 10 atmAcctngStartTime 537 11 atmAcctngCollectionTime 538 12 atmAcctngCollectMode 539 13 atmAcctngReleaseCause 540 14 atmAcctngServiceCategory 541 15 atmAcctngTransmittedCells 542 16 atmAcctngTransmittedClp0Cells 543 17 atmAcctngReceivedCells 544 18 atmAcctngReceivedClp0Cells 545 19 atmAcctngTransmitTrafficDescriptorType 546 20 atmAcctngTransmitTrafficDescriptorParam1 547 21 atmAcctngTransmitTrafficDescriptorParam2 548 22 atmAcctngTransmitTrafficDescriptorParam3 549 23 atmAcctngTransmitTrafficDescriptorParam4 550 24 atmAcctngTransmitTrafficDescriptorParam5 551 25 atmAcctngReceiveTrafficDescriptorType 552 26 atmAcctngReceiveTrafficDescriptorParam1 553 27 atmAcctngReceiveTrafficDescriptorParam2 554 28 atmAcctngReceiveTrafficDescriptorParam3 555 29 atmAcctngReceiveTrafficDescriptorParam4 556 30 atmAcctngReceiveTrafficDescriptorParam5 557 31 atmAcctngCallingPartySubAddress 558 32 atmAcctngCalledPartySubAddress 559 33 atmAcctngRecordCrc16 561 4.7. QoS: RSVP and DIFFSERV 563 As we move towards providing more than simple "best effort" connec- 564 tivity, there has been a tremendous surge of interest in (and work 565 on) protocols to provide managed Quality of Service for Internet ses- 566 sions. This is of particular interest for the provision of "Inte- 567 grated Services," i.e. the transport of audio, video, real-time, and 568 classical data traffic within a single network infrastructure. 570 Two approaches to this have emerged so far: 572 - the Integrated Services architecture (intserv) [IIS-ARC], with its 573 accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's 574 Common Open Policy Service protocol, COPS [RAP-COPS] 576 - the Differentiated Services architecture (diffserv) [DSRV-ARC] 578 RSVP is a signaling protocol that applications may use to request 579 resources from the network. The network responds by explicitly 580 admitting or rejecting RSVP requests. Certain applications that have 581 quantifiable resource requirements express these requirements using 582 intserv parameters [IIS-SPEC]. 584 Diffserv networks classify packets into one of a small number of 585 aggregated flows or "classes", based on the diffserv codepoint (DSCP) 586 in the packet's IP header. At each diffserv router, packets are sub- 587 jected to a "per-hop behavior" (PHB), which is invoked by the DSCP. 588 Since RSVP is purely a requirements signalling protocol it can also 589 be used to request connections from a diffserv network [RS-DS-OP]. 591 4.7.1. RSVP and DIFFSERV Attributes 593 A set of parameters for specifying a requested Quality of Service are 594 given in [IIS-SPEC]. These have been turned into accounting 595 attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP- 596 MIB]. 598 The RTFM QoS attributes are: 600 98 QoSService 601 99 QoSStyle 602 100 QoSRate 603 101 QoSSlackTerm 604 102 QoSTokenBucketRate 605 103 QoSTokenBucketSize 606 104 QoSPeakDataRate 607 105 QoSMinPolicedUnit 608 106 QoSMaxPolicedUnit 610 The RSVP MIB contains a large number of objects, arranged within the 611 following sections: 613 General Objects 614 Session Statistics Table 615 Session Sender Table 616 Reservation Requests Received Table 617 Reservation Requests Forwarded Table 618 RSVP Interface Attributes Table 619 RSVP Neighbor Table 621 The Session tables contain information such as the numbers of senders 622 and receivers for each session, while the Reservation Requests tables 623 contain details of requests handled by the RSVP router. There are 624 too many objects to list here, but many of them could be used for 625 accounting. In particular, RSVP Requests contain the specification 626 of the service parameters requested by a user; these, together with 627 the actual usage data for the connection make up an accounting record 628 for that usage. 630 5. ITU-T Documents 632 5.1. Q.825: Call Detail Recording 634 ITU-T Recommendation Q.825 specifies how CDRs (Call Detail Records) 635 are produced and managed in Network Elements for POTS, ISDN and IN 636 (Intelligent Networks). 638 Uses of Call Detail information for various purposes are discussed. 640 Each call produces one or more records describing events that 641 occurred during the life of a call. Data may be produced in real 642 time (single CDRs), near real-time (blocks of CDRs), or as batch 643 files of CDRs. 645 The information model for Call Detail Recording is formally described 646 in terms of an Entity-Relationship model, and an object model speci- 647 fied in terms of GDMO templates (Guidelines for the Definition of 648 Managed Objects). Note that this model includes the ways in which 649 CDRs are transported from the (NE) Network Element where they are 650 generated to the OS (Operations System) where they are used. 652 5.2. Q.825 Attributes 654 The following attributes are defined. The explanations given are 655 very brief summaries only, see [Q-825] for the complete text. 657 1 accessDelivery 658 Indicates that the call was delivered to the called subscriber 660 2 accountCodeInput 661 Account code (for billing), supplied by subscriber. 663 78 additionalParticipantInfo 664 (No details given) 666 5 b-PartyCategory 667 Subscriber category for called subscriber. 669 4 bearerService 670 Bearer capability information (only for ISDN calls). 672 13 cDRPurpose 673 Reason for triggering this Call Data Record. 675 70 callDetailDataId 676 Unique identifier for the CallDetailData object. 678 79 callDuration 679 Duration of call 681 6 callIdentificationNumber 682 Identification number for call; all records produced for this 683 call have the same callIdenfificationNumber. 685 73 callStatus 686 Identifies whether the call was answered or not. 688 9 calledPartyNumber 689 Telephone number of the called subscriber (may be a 690 "diverted-to" or "translated" number. 692 7 callingPartyCategory 693 Calling subscriber category. 695 8 callingPartyNumber 696 Telephone number of the calling party. 698 10 callingPartyNumberNotScreened 699 An additional, user-provided (not screened) number to the 700 calling party. 702 11 callingPartyType 703 Calling subscriber type. 705 74 carrierId 706 Carrier ID to which the call is sent. 708 12 cause 709 Cause and location value for the termination of the call. 711 14 chargedDirectoryNumber 712 Charged directory number (where the charged participant 713 element can't indicate the number). 715 16 chargedParticipant 716 Participant to be charged for the usage. 718 15 chargingInformation 719 Charging information generated by a Network Element which is 720 capable of charging. 722 17 configurationMask 723 Time consumption, e.g. from B-answer to termination time, 724 between partial call records, etc. 726 18 conversationTime 727 Time consumption from B-answer to end of call. 729 19 creationTriggerList 730 List of trigger values which will create Call Detail data 731 objects. 733 75 dPC 734 Destination point code (for analysis purposes). 736 20 dataValidity 737 Indicates that the NE is having problems, contents of the 738 generated Call Detail record is not reliable. 740 23 durationTimeACM 741 Time consumption from seizure until received ACM. 743 21 durationTimeB-Answer 744 Time consumption from seizure until B-answer. 746 22 durationTimeNoB-Answer 747 Time from seizure to termination when no B-answer was 748 received. 750 25 exchangeInfo 751 Identity of exchange where Call Detail record was generated. 753 26 fallbackBearerService 754 Fallback bearer capability information for a call. 756 27 glare 757 Indicates if a glare condition was encountered. 759 31 iNServiceInformationList 760 Contains information about the use of IN (Intelligent Network) 761 services. 763 32 iNSpecificInformation 764 Contains information about the use of one IN service. 766 33 iSUPPreferred 767 Indicate whether an ISUP preference was requested. 769 28 immediateNotificationForUsageMetering 770 Indicates that the Call Detail records requires 771 immediate data transfer to the Operations System. 773 34 maxBlockSize 774 Maximum number of Call Detail records in a block. 776 35 maxTimeInterval 777 Maximum latency allowable for near-real-time Call Detail 778 data delivery. 780 36 networkManagementControls 781 Indicates which Traffic Management Control has affected 782 the call. 784 37 networkProviderId 785 Indicates the Network Provider for whom the CDR is generated. 787 76 oPC 788 Originating point code for a failed call (for analysis 789 purposes). 791 38 operatorSpecific1AdditionalNumber 792 40 operatorSpecific2AdditionalNumber 793 42 operatorSpecific3AdditionalNumber 794 Operator-defined additional participant information. 796 39 operatorSpecific1Number 797 41 operatorSpecific2Number 798 43 operatorSpecific3Number 799 Operator-defined participant information. 801 44 originalCalledNumber 802 Telephone number of the original called party. 804 45 partialGeneration 805 Included if the CDR (Call Detail record) output is partial. 806 Such CDRs have a field indicating their partial record number. 808 77 participantInfo 809 (No details given). 811 46 percentageToBeBilled 812 Percentage to be billed when normal billing rules are 813 not to be followed. 815 47 periodicTrigger 816 Defines the intervals at which the CDR file should be created. 818 48 personalUserId 819 Internationally unique personal User Identity (for UPT calls). 821 49 physicalLineCode 822 Identifies the call subscriber's physical line. 824 50 progress 825 Describes an event which occurred during the life of a call. 827 51 queueInfo 828 Used to record usage of queueing resources with IN calls. 830 52 receivedDigits 831 The digits dialed by the subscriber. (Normally only included 832 for customer care purposes). 834 53 recordExtensions 835 Information elements added by network operators and/or 836 manufacturers in addition to the standard ones above. 838 6. Other Documents 840 6.1. TIPHON: ETSI TS 101 321 842 TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which han- 843 dles accounting and authorization requests and responses. 845 The following are elements selected from TIPHON's DTD that are used 846 for accounting. 848 849 Identifies a numeric value. Expressed using the period (.) as a 850 decimal separator with no punctuation as the thousands separator. 852 853 Contains a call's H.323 CallID value, and is thus used to 854 uniquely identify individual calls. 856 857 Defines the financial currency in use for the parent element. 859 866 Indicates the number of units being accounted. 868 869 Indicates a type of service being priced, authorized, or 870 reported. An empty Service element indicates basic Internet 871 telephony service, which is the only service type defined by 872 V1.4.2 of the specification. The specification notes that "Later 873 revisions of this standard are expected to specify more enhanced 874 service definitions to represent quality of service, 875 availability, payment methods, etc." 877 884 A restricted form of [ISO-DATE] that indicates the time at which 885 the component was generated. 887 888 Contains an integer, decimal valued identifier assigned to a 889 specific authorized transaction. 891 892 Indicates the units by which pricing is measured or usage 893 recorded. It shall contain one of the following values: 894 s seconds 895 p packets (datagrams) 896 byte bytes 898 899 Collects information describing the usage of a service. 901 6.2. MSIX 903 MSIX [MSIX-SPEC] is an XML-based protocol transported by HTTP that is 904 used to make accounting service definitions and transmit service 905 usage information. As its service definitions are parameterized and 906 dynamic, it makes no definition of services or attributes itself, but 907 allows implementors to make their own. It specifies only the base 908 data types that attributes may take: STRING, UNISTRING, INT32, FLOAT, 909 DOUBLE, BOOLEAN, TIMESTAMP. 911 7. Accounting File and Record Formats 913 7.1. ASN.1 Records 915 7.1.1. RTFM and AToMMIB 917 RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists 918 of attributes into accounting records. RTFM uses SNMP to retrieve 919 such records as BER strings, thus avoiding having to have an object 920 identifier for every object. 922 AToMMIB carries this a stage further by defining an accounting file 923 format in ASN.1 and making it available for retrieval by a file 924 transfer protocol, thereby providing a more efficient alternative to 925 simply retrieving the records using SNMP. 927 7.1.2. Q.825 929 A Q.825 Call Record is an ASN.1 SET containing a specified group of 930 the Q.825 attributes. Call records would presumably be encoded as 931 BER strings before being collected for later processing. 933 7.2. Binary Records 935 7.2.1. RADIUS 937 Radius packets carry a sequence of attributes and their values, as 938 (Type, Length, Value) triples. The format of the value field is one 939 of four data types. 941 string 0-253 octets 943 address 32 bit value, most significant octet first. 945 integer 32 bit value, most significant octet first. 947 time 32 bit value, most significant octet first -- seconds 948 since 00:00:00 GMT, January 1, 1970. The standard 949 Attributes do not use this data type but it is presented 950 here for possible use within Vendor-Specific attributes. 952 7.2.2. DIAMETER 954 Each DIAMETER message consists of multiple AVP's that are 32-bit 955 aligned, with the following format: 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | AVP Code | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | AVP Length | AVP Flags | Reserved | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | | 965 // (AVP contents) // 966 | | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Code 970 Identifies the AVP; values of this field are defined below. 972 AVP Length 973 A 16-bit field contains the total object length in bytes. 974 Must always be a multiple of 4, and at least 8. 976 AVP Flags 977 0x01: Mandatory-Support 978 0x02: SS-Encrypted-Data 979 0x03: PK-Encrypted-Data 980 0x04: Vendor-Specific-AVP 982 7.3. Text Records 984 7.3.1. ROAMOPS 986 ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a gen- 987 eral, text-based format for accounting data files, described in a 988 straightforward BNF grammar. Its file header contains a field indi- 989 cating the default protocol from which accounting attributes are 990 drawn. If an attribute from another protocol is to be used, it is 991 preceded by its protocol name, for example rtfm//27 would be RTFM's 992 "forward bytes" attribute. Comments in an ADIF file begin with a 993 cross-hatch. 995 Example: An ADIF file encoding RADIUS accounting data 997 version: 1 998 device: server3 999 description: Accounting Server 3 1000 date: 02 Mar 1998 12:19:01 -0500 1001 defaultProtocol: radius 1003 #NAS-IP-Address 1004 4: 204.45.34.12 1005 #NAS-Port 1006 5: 12 1007 #NAS-Port-Type 1008 61: 2 1009 #User-Name 1010 1: fred@bigco.com 1011 #Acct-Status-Type 1012 40: 2 1013 #Acct-Delay-Time 1014 41: 14 1015 #Acct-Input-Octets 1016 42: 234732 1017 #Acct-Output-Octets 1018 43: 15439 1019 #Acct-Session-Id 1020 44: 185 1021 #Acct-Authentic 1022 45: 1 1023 #Acct-Session-Time 1024 46: 1238 1025 #Acct-Input-Packets 1026 47: 153 1027 #Acct-Output-Packets 1028 48: 148 1029 #Acct-Terminate-Cause 1030 49: 11 1031 #Acct-Multi-Session-Id 1032 50: 73 1033 #Acct-Link-Count 1034 51: 2 1036 8. AAA Requirements 1038 8.1. A Well-Defined Set of Attributes 1040 AAA needs a well-defined set of attributes whose values are to be 1041 carried in records to or from accounting servers. 1043 Most of the existing sets of documents described above include a set 1044 of attributes, identified by small integers. It is likely that these 1045 sets overlap, i.e. that some of them have attributes which represent 1046 the same quantity using different names in different sets. This sug- 1047 gests it might be possible to produce a single combined set of "uni- 1048 versal" accounting attributes, but such a "universal" set does not 1049 seem worthwhile. 1051 The ADIF approach of specifying a default protocol (from which 1052 attributes are assumed to come) and identifying any exceptions seems 1053 much more practical. We therefore propose that AAA should use the 1054 ADIF convention (or something like it) to identify attributes, 1055 together with all the sets of attributes covered by the [ASG-NBR] 1056 document. 1058 8.2. A Simple Interchange Format 1060 AAA needs a simple interchange file format, to be used for accounting 1061 data. Several schemes for packaging and transporting such data have 1062 been described above. 1064 The SNMP-based ones fit well within the context of an SNMP-based net- 1065 work management system. RTFM and AToMMIB provide ways to reduce the 1066 SNMP overhead for collecting data, and AToMMIB defines a complete 1067 file format. Both provide good ways to collect accounting data. 1069 As an interchange format, however, ASN.1-based schemes suffer from 1070 being rather complex binary structures. This means that one requires 1071 suitable tools to work with them, as compared to plain-text files 1072 where one can use existing text-based utilities. 1074 The binary schemes such as RADIUS and DIAMETER have simpler struc- 1075 tures, but they too need purpose-built tools. For general use they 1076 would need to be extended to allow them to use attributes from other 1077 protocols. 1079 From the point of view of being easy for humans to understand, ADIF 1080 seems very promising. Of course any processing program would need a 1081 suitable ADIF input parser, but using plain-text files makes them 1082 much easier to understand. 1084 TIPHON's record format is specified by an XML DTD. While XML repre- 1085 sentations have the advantages of being well-known, they are limited 1086 by XML's inability to specify type or other validity checking for 1087 information within the tags. This situation will likely be improved 1088 by the XML Schema [XML-SCHM] efforts that are underway, but a stable 1089 reference is not yet available. 1091 9. Issues 1093 It is generally agreed that there is a need for a standard record 1094 format and transport protocol for communication between Service Ele- 1095 ments and Accounting Servers. 1097 There is less agreement on the following issues: 1099 o Separate or integral record format and transport protocol 1100 o Standard set of base data types 1101 o Service definitions: part of the protocol or separately defined 1102 o Service definition namespace management 1104 The following sections address these issues. 1106 9.1. Record Format vs. Protocol 1108 All known Internet-centric billing protocols to date have an integral 1109 record format. That is, the collection of Properties that describe a 1110 Usage Event are specified as an integral part of the protocol, typi- 1111 cally as a part of a "submit" message that is used to transmit a 1112 Usage Event from a Service Entity to an Accounting Server. 1114 It may be advantageous to define a record format that is independent 1115 of the transport protocol. Such a record format should support both 1116 representation of individual records and records in bulk, as Usage 1117 Events are often aggregated and transmitted in bulk. 1119 A separate record format is useful for record archiving and temporary 1120 file storage. Multiple transport protocols may be defined without 1121 affecting the record format. The task of auditing is made easier if 1122 a standard file format is defined. If a canonical format is used, 1123 bulk records may be hashed with MD5 [MD5] or a similar function, for 1124 reliability and security purposes. 1126 +------------+ 1127 | transport | 1128 | header | 1129 +------------+ +------------+ 1130 | | | | 1131 | Usage | | Usage | 1132 | Event(s) | | Event(s) | 1133 | | | | 1134 | | | | 1135 +------------+ +------------+ 1136 | trailer | 1137 +------------+ 1139 record format transport protocol 1141 If the protocol is written such that it can transmit Usage Events in 1142 the record format, no record rewriting for transport is required. 1144 9.2. Tagged, Typed Data 1146 Record formats and protocols use a combination of data locality and 1147 explicit tagging to identify data elements. Mail [RFC822], for 1148 instance, defines a header block composed of several Attribute-Value 1149 Pairs, followed by a message body. Each header field is explicitly 1150 tagged, but the order of the AVPs is undefined. The message body is 1151 not tagged (except with an additional preceding blank line), and is 1152 found through its position in the message, which must be after all 1153 header fields. 1155 Some record formats make no use of tags--data elements are identified 1156 only by their position within a record structure. While this prac- 1157 tice provides for the least amount of record space overhead, it is 1158 difficult to later modify the record format by adding or removing 1159 elements, as all record readers will have to be altered to handle the 1160 change. Tagged data allows old readers to detect unexpected tags and 1161 to detect if required data are missing. If the overhead of carrying 1162 explicit tags can be borne, it is advantageous to use explicitly 1163 tagged data elements where possible. 1165 An AVP approach has proven useful in accounting. RADIUS [RADIUS] 1166 uses numeric data type identifiers. ETSI's TIPHON [TIPHON] uses XML 1167 markup. 1169 For an AAA accounting record format, the authors suggest that each 1170 Property be named by a textual or numeric identifier and carry a 1171 value and a data type indicator, which governs interpretation of the 1172 value. It may also be useful for each Property to carry a units of 1173 measure identifier. The TIPHON specification takes this approach. 1174 TS 101 321 also carries an Increment field, which denominates the 1175 Property's Unit of Measure field. Whether this additional conve- 1176 nience is necessary is a matter for discussion. 1178 It is not strictly necessary for each data record to carry data type, 1179 units of measure, or increments identifiers. If this information is 1180 recorded in a record schema document that is referenced by each data 1181 record, each record may be validated against the schema without the 1182 overhead of carrying type information. 1184 9.2.1. Standard Type Definitions 1186 It is useful to define a standard set of primitive data types to be 1187 used by the record format and protocol. Looking at the prior art, 1188 DIAMETER supports Data (arbitrary octets), String (UTF-8), Address 1189 (32 or 128 bit), Integer32, Integer64, and Time (32 bits, seconds 1190 since 1970). MSIX [MSIX-SPEC] supports String, Unistring, Int32, 1191 Float, Double, Boolean, and Timestamp. SNMP [SNMP] offers OBJECT 1192 IDENTIFIER, NULL, OCTET STRING, IpAddress, NetworkAddress, Counter, 1193 Gauge, TimeTicks, and Opaque. 1195 An appropriate set would likely include booleans, 32 and 64 bit 1196 signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and 1197 UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps. Fixed- 1198 precision numbers capable of representing currency amounts (with pre- 1199 cision specified on both sides of the decimal point) have proven use- 1200 ful in accounting record formats, as they are immune to the precision 1201 problems that are encountered when one attempts to represent fixed- 1202 point amounts with floating point numbers. 1204 9.3. Transaction Identifiers 1206 Each Usage Event requires its own unique identifier. 1208 It is expedient to allow Service Elements to create their own unique 1209 identifiers. In this manner, Usage Events can be created and 1210 archived without the involvement of an Accounting Server or other 1211 central authority. 1213 A number of methods for creating unique identifiers are well known. 1214 One popular identifier is an amalgamation of a monotonically increas- 1215 ing sequence number, a large random value, a network element identi- 1216 fier, and a timestamp. Another possible source of entropy is a hash 1217 value of all or part of the record itself. 1219 RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give guid- 1220 ance on the creation of good unique identifiers. 1222 9.4. Service Definitions 1224 A critical differentiator in accounting record formats and protocols 1225 is their capability to account for arbitrary service usage. To date, 1226 no accounting record format or protocol that can handle arbitrary 1227 service definitions has achieved broad acceptance on the Internet. 1229 This section analyzes the issues in service definition and makes a 1230 case for a record format and protocol with the capability to carry 1231 Usage Events for rich, independently-defined services. 1233 9.4.1. Service Independence 1235 It is informative to survey a number of popular Internet protocols 1236 and document encodings and examine their capacities for extension. 1237 These protocols can be categorized into two broad categories--"fully 1238 specified" protocols that have little provision for extension and 1239 "framework" protocols that are incomplete, but provide a basis for 1240 future extension when coupled with application documents. 1242 Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP], 1243 RADIUS Accounting [RAD-ACT], and HTML [HTML]. 1245 Aside from leaving some field values "reserved for future use," all 1246 of Network Time Protocol's fields are fixed-width and completely 1247 defined. This is appropriate for a simple protocol that solves a 1248 simple problem. 1250 Network News Transfer Protocol [NEWS-PROT] specifies that further 1251 commands may be added, and requests that non-standard implementations 1252 use the "X-" experimental prefix so as to not conflict with future 1253 additions. The content of news is 7-bit data, with the high-order 1254 bit cleared to 0. Nothing further about the content is defined. 1255 There is no in-protocol facility for automating decoding of content 1256 type. 1258 We pay particular attention to RADIUS Accounting [RAD-ACT]. Perhaps 1259 the second most frequently heard complaint (after security shortcom- 1260 ings) about RADIUS Accounting is its preassigned and fixed set of 1261 "Types". These are coded as a range of octets from 40 to 51 and are 1262 as follows: 1264 40 Acct-Status-Type 1265 41 Acct-Delay-Time 1266 42 Acct-Input-Octets 1267 43 Acct-Output-Octets 1268 44 Acct-Session-Id 1269 45 Acct-Authentic 1270 46 Acct-Session-Time 1271 47 Acct-Input-Packets 1272 48 Acct-Output-Packets 1273 49 Acct-Terminate-Cause 1274 50 Acct-Multi-Session-Id 1275 51 Acct-Link-Count 1277 These identifiers were designed to account for packet-based network 1278 access service. They are ill-suited for describing other services. 1279 While extension documents have specified additional types, the base 1280 protocol limits the type identifier to a single octet, limiting the 1281 total number of types to 256. 1283 HTML/2.0 [HTML] is mostly a fully-specified protocol, but with W3C's 1284 HTML/4.0, HTML is becoming more of a framework protocol. HTML/2.0 1285 specified a fixed set of markups, with no provision for addition 1286 (without protocol revision). 1288 Examples of "framework" protocols and document encodings are HTTP, 1289 XML, and SNMP. 1291 HTTP/1.1 [HTTP] is somewhat similar to NNTP in that it is designed to 1292 transport arbitrary content. It is different in that it supports 1293 description of that content through its Content-Type, Content-Encod- 1294 ing, Accept-Encoding, and Transfer-Encoding header fields. New types 1295 of content can be designated and carried by HTTP/1.1 without modifi- 1296 cation to the HTTP protocol. 1298 XML [XML] is a preeminent general-purpose framework encoding. DTD 1299 publishing is left to users. There is no standard registry of DTDs. 1301 SNMP presents a successful example of a framework protocol. SNMP's 1302 authors envisioned SNMP as a general management protocol, and allow 1303 extension through the use of private MIBs. SNMP's ASN.1 MIBs are 1304 defined, published, and standardized without the necessity to modify 1305 the SNMP standard itself. From "An Overview of SNMP" [SNMP-OVER]: 1307 It can easily be argued that SNMP has become prominent mainly from 1308 its ability to augment the standard set of MIB objects with new 1309 values specific for certain applications and devices. Hence, new 1310 functionality can continuously be added to SNMP, since a standard 1311 method has been defined to incorporate that functionality into 1312 SNMP devices and network managers. 1314 Most accounting protocols are fully-specified, with either a com- 1315 pletely defined service or set of services (RADIUS Accounting) or 1316 with one or more services defined and provision for "extension" ser- 1317 vices to be added to the protocol later (TIPHON). While the latter 1318 is preferable, it may be preferable to take a more SNMP-like 1319 approach, where the accounting record format and protocol provide 1320 only a framework for service definition, and leave the task of ser- 1321 vice definition (and standardization) to separate efforts. In this 1322 manner, the accounting protocol itself would not have to be modified 1323 to handle new services. 1325 9.4.2. Versioned Service Definitions 1327 Versioning is a naming and compatibility issue. Version identifiers 1328 are useful in service definition because they enable service defini- 1329 tions to be upgraded without a possibly awkward name change. They 1330 also enable possible compatibility between different versions of the 1331 same service. 1333 An example could be the service definition of a phone call. Version 1334 1 might define Properties for the start time, duration, and called 1335 and calling party numbers. Later, version 2 is defined, which aug- 1336 ments the former service definition with a byte count. An Accounting 1337 Server, aware only of Version 1, may accept Version 2 records, dis- 1338 carding the additional information (forward compatibility). Alter- 1339 nately, if an Accounting Server is made aware of version 2, it could 1340 optionally still accept version 1 records from Service Elements, pro- 1341 vided the Accounting Sever does not require the additional informa- 1342 tion to properly account for service usage (backward compatibility). 1344 9.4.3. Relationships Among Usage Events 1346 Accounting record formats and protocols to date do not sufficiently 1347 addressed "compound" service description. 1349 A compound service is a service that is described as a composition of 1350 other services. A conference call, for example, may be described as 1351 a number of point-to-point calls to a conference bridge. It is 1352 important to account for the individual calls, rather than just sum- 1353 ming up an aggregate, both for auditing purposes and to enable dif- 1354 ferential rating. If these calls are to be reported to the Account- 1355 ing Server individually, the Usage Events require a shared identifier 1356 that can be used by the Accounting Server and other backend systems 1357 to group the records together. 1359 In order for a Service Element to report compound events over time as 1360 a succession of individual Usage Events, the accounting protocol 1361 requires a facility to communicate that the compound event has 1362 started and stopped. The "start" message can be implicit--the trans- 1363 mission of the first Usage Event will suffice. An additional 1364 semaphore is required to tell the Accounting Server that the compound 1365 service is complete and may be further processed. This is necessary 1366 to prevent the Accounting Server from prematurely processing compound 1367 events that overlap the end of a billing period. 1369 RADIUS Accounting has some provision for this sort of accounting with 1370 its "Acct-Multi-Session-Id" field. Unfortunately, RADIUS Account- 1371 ing's other shortcomings preclude it from being used in general pur- 1372 pose service usage description. 1374 9.4.4. Service Namespace Management 1376 "Framework" protocols, as previously mentioned, do not define com- 1377 plete schema for their payload. For interoperability to be achieved, 1378 it must be possible for: 1380 (1) content definers to specify definitions without conflicting with 1381 the names of other definitions 1383 (2) protocol users to find and use content definitions 1385 Condition (1) can be readily managed through IANA assignment or by 1386 using an existing namespace differentiator (for example, DNS). 1388 Condition (2) is harder, and places considerable burden on the imple- 1389 mentors. Their clients and servers must be able, statically or 1390 dynamically, to find and validate definitions, and manage versioning 1391 issues. 1393 As previously mentioned, the XML specification provides no facility 1394 for DTD discovery or namespace management. XML specifies only a doc- 1395 ument format, and as such does not need to specify support for more 1396 "protocol" oriented problems. 1398 For an accounting record format and protocol, an approach closer to 1399 SNMP's is useful. SNMP uses an ISO-managed dotted-decimal namespace. 1400 An IANA-managed registry of service types is a possibility. Another 1401 possibility, used by MSIX [MSIX-SPEC], is for Service Element cre- 1402 ators to identify their services by concatenation of a new service 1403 name with existing unique identifier, such as a domain name. 1405 A standard record format for service definitions would make it possi- 1406 ble for Service Element creators to directly supply accounting system 1407 managers with the required definitions, via the network or other 1408 means. 1410 10. Encodings 1412 It may be useful to define more than one record encoding. 1414 A "verbose" XML encoding is easily implemented and records can be 1415 syntactically verified with existing tools. "Human-readable" proto- 1416 cols tend to have an edge on "bitfield" protocols where ease of 1417 implementation is paramount and the application can tolerate any 1418 additional processing required to generate, parse, and transport the 1419 records. 1421 A alternative "compressed" encoding that makes minimal use of storage 1422 and processing may be useful in many contexts. 1424 There are disadvantages to supporting multiple encodings. Option- 1425 ally-supported multiple encodings mandate the requirement for capa- 1426 bilities exchange between Service Element and Accounting Server. 1427 Also, implementations can tend to "drift apart," with one encoding 1428 better-supported than another. Unless all encodings are mandatory, 1429 implementors may find they are unable to interoperate because they 1430 picked the wrong encoding. 1432 11. Security Considerations 1434 This draft summarises many existing IETF and ITU documents; please 1435 refer to the original documents for security considerations for their 1436 particular protocols. 1438 It must be possible for the accounting protocol to be carried by a 1439 secure transport. A canonical record format is useful so that regen- 1440 eration of secure record hashes is possible. 1442 When dealing with accounting data files, one must take care that 1443 their integrity and privacy are preserved. This document, however, 1444 is only concerned with the format of such files. 1446 12. References 1448 [ACC-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet 1449 Accounting Background", RFC 1272, November 1991. 1451 [ASG-NBR] Reynolds, J., Postel, J., "Assigned Numbers," 1452 RFC 1700, October 1994. 1454 [ASN1] Information processing systems - Open Systems 1455 Interconnection - Specification of Abstract Syntax Notation 1456 One (ASN.1), International Organization for Standardization, 1457 International Standard 8824, December 1987. 1459 [ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, 1460 A., "Accounting Information for ATM Networks," 1461 RFC 2512, February 1999. 1463 [ATM-COLL] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, 1464 A., " Managed Objects for Controlling the Collection 1465 and Storage of Accounting Information for Connection- 1466 Oriented Networks," RFC 2513, February 1999. 1468 [BER] Information processing systems - Open Systems 1469 Interconnection - Specification of Basic Encoding Rules for 1470 Abstract Notation One (ASN.1), International Organization for 1471 Standardization, International Standard 8825, December 1987. 1473 [DIAM-ACT] Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G., 1474 "DIAMETER Accounting Extension," Internet Draft (Work 1475 in progress), draft-calhoun-diameter-accounting- .. 1477 [DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User 1478 Authentication Extensions," Internet Draft (Work in 1479 progress), draft-calhoun-diameter-authent- .. 1481 [DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER 1482 Framework Document," Internet Draft (Work in 1483 progress), draft-calhoun-diameter-framework- .. 1485 [DIAM-SIP] Pan, P. and Clahoun, P., "DIAMETER: Policy and 1486 Accounting Extension for SIP Framework Document," 1487 Internet Draft (Work in progress), 1488 draft-pan-diameter-sip- .. 1490 [DSRV-ARC] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 1491 and W. Weiss, "An Architecture for Differentiated 1492 Services", RFC 2475, December 1998. 1494 [HTML] Berners-Lee, T., D. Connolly, "Hypertext Markup Language - 1495 2.0", RFC 1866, November 1995. 1497 [HTTP] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, and 1498 T. Berners-Lee. "Hypertext Transfer Protocol--HTTP/1.1", 1499 RFC 2068, January 1997. 1501 [ICAL-CORE] Dawson, F., D. Stenerson, "Internet Calendaring and 1502 Scheduling Core Object Specification", RFC 2445, November 1503 1998. 1505 [IIS-ARC] Braden, R., Clark, D. and Shenker, S., "Integrated 1506 Services in the Internet Architecture: an Overview", 1507 RFC 1633, June 1994 1509 [IIS-SPEC] Shenker, S., Partridge, C., Guerin, R.: "Specification of 1510 Guaranteed Quality of Service," RFC 2212, 1997. 1512 [ISDN-MIB] Roeck, G., "ISDN Management Information Base using 1513 SMIv2," RFC 2127, March 1997. 1515 [ISO-DATE] "Data elements and interchange formats -- Information 1516 interchange -- Representation of dates and times", 1517 ISO 8601:1988. 1519 [MAIL] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 1520 MESSAGES", RFC 822, August 1982. 1522 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1523 April 1992. 1525 [MSIX-SPEC] Blount, A., D. Young, "Metered Service Information Exchange 1526 1.2", Work in Progress, 1527 http://www.msix.org/draft-blount-acct-msix-00.txt, 1528 July 1999. 1530 [NEWS-MSGS] Horton, M., R. Adams, "Standard for Interchange of USENET 1531 Messages", RFC 1036, December 1987. 1533 [NEWS-PROT] Kantor, B., P. Lapsley, "Network News Transfer Protocol" 1534 RFC 977, February 1986. 1536 [NTP] Mills, D.L., "Network Time Protocol (NTP)", RFC 958, 1537 September 1985. 1539 [Q-825] "Specification of TMN applications at the Q3 1540 interface: Call detail recording," 1541 ITU-T Recommendation Q.825, 1998. 1543 [RAD-ACT] Rigney, C., "RADIUS Accounting," RFC 2139, April 1997. 1545 [RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS 1546 Extensions," Internet Draft (Work in progress), 1547 draft-ietf-radius-ext- .. 1549 [RAD-PROT] Rigney, C., Rubens, A., Simpson, W. and Willens, S., 1550 "Remote Authentication Dial In User Service (RADIUS)," 1551 RFC 2138, April 1997. 1553 [RAD-RECX] Calhoun, P.R. and Beadles, M.., "RADIUS Accounting 1554 Interim Accounting Record Extension," Internet Draft 1555 (Work in progress), draft-ietf-radius-acct-interim- .. 1557 [RAD-TACC] Zorn, G., Mitton, D. and Aboba, A.,"RADIUS Accounting 1558 "Modifications for Tunnel Protocol Support," 1559 (Work in progress), draft-ietf-radius-tunnel-acct- .. 1561 [RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. 1562 and Sastry, A., "The COPS (Common Open Policy Service) 1563 draft-ietf-rap-cops- .. 1565 [ROAM-ADIF] Aboba, B and Lidyard, D., "The Accounting Data 1566 Interchange Format (ADIF)," Internet Draft (Work 1567 in progress), draft-ietf-roamops-actng- .. 1569 [ROAM-IMPL] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, 1570 "Review of Roaming Implementations", 1571 RFC 2194, September 1997. 1573 [RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1574 Speer, M. and Braden, R., "Interoperation of RSVP/Intserv 1575 and Diffserv Networks," Internet Draft (Work in Progress), 1576 draft-ietf-issll-diffserv-rsvp- .. 1578 [RSVP-ARC] Braden, R., Zhang, L., Berson, S., Herzog, S. and 1579 Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 1580 Functional Specification", RFC 2205, September 1997 1582 [RSVP-MIB] Baker, F., Krawczyk, J. and Sastry, A., "RSVP Management 1583 Information Base," Internet Draft (Work in Progress), 1584 draft-ietf-rsvp-mib-v2- .. 1586 [RTFM-ARC] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow 1587 Measurement: Architecture", RFC 2722, October 1999. 1589 [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 1590 Measurement: Architecture", RFC 2720, October 1999. 1592 [RTFM-NEWA] Handelman, S, Brownlee, N., Ruth, G., and Stibler, S., 1593 "New Attributes for Traffic Flow Measurement", 1594 RFC 2724, October 1999. 1596 [SIP-PROT] Handley, M.,Schulzrinne, H.,Schooler, E. and 1597 Rosenberg, J., "SIP: session initiation protocol," 1598 RFC 2543, March 1999. 1600 [SNMP] Case, J., M. Fedor, M. Schoffstall, J. Davin, "A Simple 1601 Network Management Protocol (SNMP)", RFC 1157, May 1990 1603 [SNMP-OVER] "AN OVERVIEW OF SNMP V2.0", Diversified Data Resources, Inc., 1604 http://www.ddri.com, 1999. 1606 [TIPHON] "Telecommunications and Internet Protocol Harmonization Over 1607 Networks (TIPHON); Inter-domain pricing, authorization, and 1608 usage exchange", TS 101 321 V1.4.2, December 1998. 1610 [XML] Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible 1611 Markup Language (XML) 1.0", W3C Recommendation, February 1612 1998. 1614 [XML-SCHM] "XML Schema Part 1: Structures", W3C Working Draft 17, 1615 December 1999. 1617 13. Authors' Addresses 1619 Alan Blount 1620 MetraTech Corp. 1621 330 Bear Hill Road 1622 Waltham, MA 02451 1623 Email: blount@alum.mit.edu 1625 Nevil Brownlee 1626 Information Technology Systems & Services 1627 The University of Auckland 1628 Phone: +64 9 373 7599 x8941 1629 E-mail: n.brownlee@auckland.ac.nz