idnits 2.17.1 draft-ietf-aaa-accounting-attributes-00.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 28 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 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 868 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 (13 January 2000) is 8869 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: 'NEWS' is mentioned on line 1156, but not defined == Missing Reference: 'NNTP' is mentioned on line 1179, but not defined == Unused Reference: 'ACC-BKG' is defined on line 1384, but no explicit reference was found in the text == Unused Reference: 'NEWS-MSGS' is defined on line 1460, but no explicit reference was found in the text == Unused Reference: 'RAD-RECX' is defined on line 1483, but no explicit reference was found in the text == Unused Reference: 'SIP-PROT' is defined on line 1526, 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-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-ACC') (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: 16 errors (**), 0 flaws (~~), 10 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 13 January 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 July 25, 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 . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8. AAA Requirements . . . . . . . . . . . . . . . . . . . . . . . 20 80 8.1. A Well-defined Set of Attributes . . . . . . . . . . . . . . 20 81 8.2. A Simple Interchange Format . . . . . . . . . . . . . . . . 21 82 9. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 9.1. Record Format vs. Protocol . . . . . . . . . . . . . . . . . 22 84 9.2. Tagged, Typed Data . . . . . . . . . . . . . . . . . . . . . 22 85 9.2.1. Standard Type Definitions . . . . . . . . . . . . . . . . 22 86 9.3. Transaction Identifiers . . . . . . . . . . . . . . . . . . 23 87 9.4. Service Definitions . . . . . . . . . . . . . . . . . . . . 23 88 9.4.1. Service Independence . . . . . . . . . . . . . . . . . . . 23 89 9.4.2. Versioned Service Definitions . . . . . . . . . . . . . . 25 90 9.4.3. Relationships Among Usage Events . . . . . . . . . . . . . 25 91 9.4.4. Service Namespace Management . . . . . . . . . . . . . . . 26 92 10. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 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-ACC] 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-ACC], 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 and billing systems. 129 Attribute-Value Pair (AVP) 130 A representation for a Usage Attribute consisting of the name of 131 the Attribute and a value. 133 Property 134 A component of a Usage Event. A Usage Event describing a phone 135 call, for instance, might have a "duration" Property. 137 Service 138 A type of task that is performed by a Service Element for a Ser- 139 vice Consumer. 141 Service Consumer 142 Client of a Service Element. End-user of a network service. 144 Service Definition 145 A specification for a particular service. It is composed of a 146 name or other identifier, versioning information, and a collection 147 of Properties. 149 Service Element 150 A network element that provides a service to Service Consumers. 152 Examples include RAS servers, 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 4. IETF Documents 182 In March 1999 there were at least 19 Internet Drafts and 8 RFCs con- 183 cerned with Accounting. These are summarised (by working group) in 184 the following sections. 186 4.1. RADIUS 188 The RADIUS protocol [RAD-PROT] carries authentication, authorization 189 and configuration information between a Network Access Server (NAS) 190 and an authentication server. Requests and responses carried by the 191 protocol are expressed in terms of RADIUS attributes such as User- 192 Name, Service-Type, and so on. These attributes provide the informa- 193 tion needed by a RADIUS server to authenticate users and to establish 194 authorized network service for them. 196 The protocol was extended to carry accounting information between a 197 NAS and a shared accounting server. This was achieved by defining a 198 set of RADIUS accounting attributes [RAD-ACC]. 200 RADIUS packets have a short header containing the RADIUS packet type 201 and authenticator (sixteen octets) and length, followed by a sequence 202 of (Type, Length, Value) triples, one for each attribute. 204 RADIUS is now very widely used, and a number of significant new 205 extensions to it have been proposed. For example [RAD-EXT] discusses 206 extensions to implement the Extensible Authentication Protocol (EAP) 207 and the Apple Remote Access Protocol (ARAP). [RAD-TACC] discusses 208 extensions to permit RADIUS to interwork effectively with tunnels 209 using protocols such as PPTP and L2TP. 211 4.1.1. RADIUS Attributes 213 Each RADIUS attribute is identified by an 8-bit number, referred to 214 as the RADIUS Type field. Up-to-date values of this field are speci- 215 fied in the most recent Assigned Numbers RFC [ASG-NBR], but the cur- 216 rent list is as follows: 218 RADIUS Attributes [RAD-PROT] 60 CHAP-Challenge 219 61 NAS-Port-Type 220 1 User-Name 62 Port-Limit 221 2 User-Password 63 Login-LAT-Port 222 3 CHAP-Password 223 4 NAS-IP-Address RADIUS Accounting Attributes 224 5 NAS-Port [RAD-ACC] 225 6 Service-Type 226 7 Framed-Protocol 40 Acct-Status-Type 227 8 Framed-IP-Address 41 Acct-Delay-Time 228 9 Framed-IP-Netmask 42 Acct-Input-Octets 229 10 Framed-Routing 43 Acct-Output-Octets 230 11 Filter-Id 44 Acct-Session-Id 231 12 Framed-MTU 45 Acct-Authentic 232 13 Framed-Compression 46 Acct-Session-Time 233 14 Login-IP-Host 47 Acct-Input-Packets 234 15 Login-Service 48 Acct-Output-Packets 235 16 Login-TCP-Port 49 Acct-Terminate-Cause 236 17 (unassigned) 50 Acct-Multi-Session-Id 237 18 Reply-Message 51 Acct-Link-Count 238 19 Callback-Number 239 20 Callback-Id RADIUS Extension Attributes 240 21 (unassigned) [RAD-EXT] 241 22 Framed-Route 242 23 Framed-IPX-Network 52 Acct-Input-Gigawords 243 24 State 53 Acct-Output-Gigawords 244 25 Class 54 Unused 245 26 Vendor-Specific 55 Event-Timestamp 246 27 Session-Timeout 247 28 Idle-Timeout 70 ARAP-Password 248 29 Termination-Action 71 ARAP-Features 249 30 Called-Station-Id 72 ARAP-Zone-Access 250 31 Calling-Station-Id 73 ARAP-Security 251 32 NAS-Identifier 74 ARAP-Security-Data 252 33 Proxy-State 75 Password-Retry 253 34 Login-LAT-Service 76 Prompt 254 35 Login-LAT-Node 77 Connect-Info 255 36 Login-LAT-Group 78 Configuration-Token 256 37 Framed-AppleTalk-Link 79 EAP-Message 257 38 Framed-AppleTalk-Network 80 Signature 258 39 Framed-AppleTalk-Zone 259 84 ARAP-Challenge-Response 261 RADIUS Tunneling Attributes 262 [RAD-TACC] 264 51 Acct-Link-Count 266 64 Tunnel-Type 267 65 Tunnel-Medium-Type 268 66 Tunnel-Client-Endpoint 269 67 Tunnel-Server-Endpoint 270 68 Acct-Tunnel-Connection 271 69 Tunnel-Password 273 81 Tunnel-Private-Group-ID 274 82 Tunnel-Assignment-ID 275 83 Tunnel-Preference 277 4.2. DIAMETER 279 The DIAMETER framework [DIAM-FRAM] defines a policy protocol used by 280 clients to perform Policy, AAA and Resource Control. This allows a 281 single server to handle policies for many services. The DIAMETER 282 protocol consists of a header followed by objects. Each object is 283 encapsulated in a header known as an Attribute-Value Pair (AVP). 285 DIAMETER defines a base protocol that specifies the header formats, 286 security extensions and requirements as well as a small number of 287 mandatory commands and AVPs. A new service can extend DIAMETER by 288 extending the base protocol to support new functionality. 290 One key differentiator with DIAMETER is its inherent support for 291 Inter-Server communication. Although this can be achieved in a vari- 292 ety of ways, the most useful feature is the ability to "proxy" mes- 293 sages across a set of DIAMETER servers (known as a proxy chain). 295 The DIAMETER Policy and Accounting Extension for SIP (Session Initia- 296 tion Protocol) document [DIAM-SIP] extends DIAMETER by adding a pol- 297 icy and accounting information exchange mechanism between a DIAMETER 298 policy server and a SIP proxy server. 300 A DIAMETER server is responsible for maintaining a user policy and 301 accounting database and a means to update it. A SIP proxy server 302 needs to contact a DIAMETER server during multimedia session setup 303 and teardown time to perform admission control and accounting tasks. 304 The exchange mechanism protocol does not make any assumption about 305 policy and billing algorithms at DIAMETER servers. 307 4.2.1. DIAMETER Attributes 309 DIAMETER AVPs are identified by a 16-bit number defined in [DIAM- 310 AUTH]. Since Most of the AVPs found in that document were copied 311 from the RADIUS protocol [RAD-PROT], it is possible to have both 312 RADIUS and DIAMETER servers read the same dictionary and users files. 314 The backward compatibility that DIAMETER offers is intended to facil- 315 itate deployment. To this end, DIAMETER inherits the RADIUS 316 attributes, and only adds a few of its own. 318 In the list below attribute numbers which are used for RADIUS 319 attributes but not for DIAMETER are indicated with a star (*). 320 RADIUS attributes used by DIAMETER are not listed again here. 322 The DIAMETER attributes are: 324 4 (unassigned, *) 325 17 (unassigned) 326 21 (unassigned) 327 24 (unassigned, *) 328 25 (unassigned, *) 329 27 (unassigned, *) 330 32 (unassigned, *) 331 33 (unassigned, *) 333 280 Filter-Rule 334 281 Framed-Password-Policy 336 600 SIP-Sequence 337 601 SIP-Call-ID 338 602 SIP-To 339 603 SIP-From 341 4.3. ROAMOPS 343 [ROAM-IMPL] reviews the design and functionality of existing roaming 344 implementations. "Roaming capability" may be loosely defined as the 345 ability to use any one of multiple Internet service providers (ISPs), 346 while maintaining a formal customer-vendor relationship with only 347 one. One requirement for successful roaming is the provision of 348 effective accounting. 350 [ROAM-ADIF] proposes a standard accounting record format, the 351 Accounting Data Interchange Format (ADIF), which is designed to com- 352 pactly represent accounting data in a protocol-independent manner. 353 As a result, ADIF may be used to represent accounting data from any 354 protocol using attribute value pairs (AVPs) or variable bindings. 356 ADIF does not define accounting attributes of its own. Instead, it 357 gives examples of accounting records using the RADIUS accounting 358 attributes. 360 4.4. RTFM 362 The RTFM Architecture [RTFM-ARC] provides a general method of measur- 363 ing network traffic flows between "metered traffic groups." Each 364 RTFM flow has a set of "address" attributes, which define the traffic 365 groups at each of the flow's end-points. 367 As well as address attributes, each flow has traffic-related 368 attributes, e.g. times of first and last packets, counts for packets 369 and bytes in each direction. 371 RTFM flow measurements are made by RTFM meters [RTFM-MIB] and col- 372 lected by RTFM meter readers using SNMP. The MIB uses a "DataPackage" 373 convention, which specifies the attribute values to be read from a 374 flow table row. The meter returns the values for each required 375 attribute within a BER-encoded sequence. This means there is only 376 one object identifier for the whole sequence, greatly reducing the 377 number of bytes required to retrieve the data. 379 4.4.1. RTFM Attributes 381 RTFM attributes are identified by a 16-bit attribute number. 383 The RTFM Attributes are: 385 0 Null 386 1 Flow Subscript Integer Flow table info 388 4 Source Interface Integer Source Address 389 5 Source Adjacent Type Integer 390 6 Source Adjacent Address String 391 7 Source Adjacent Mask String 392 8 Source Peer Type Integer 393 9 Source Peer Address String 394 10 Source Peer Mask String 395 11 Source Trans Type Integer 396 12 Source Trans Address String 397 13 Source Trans Mask String 399 14 Destination Interface Integer Destination Address 400 15 Destination Adjacent Type Integer 401 16 Destination Adjacent Address String 402 17 Destination AdjacentMask String 403 18 Destination PeerType Integer 404 19 Destination PeerAddress String 405 20 Destination PeerMask String 406 21 Destination TransType Integer 407 22 Destination TransAddress String 408 23 Destination TransMask String 410 26 Rule Set Number Integer Meter attribute 412 27 Forward Bytes Integer Source-to-Dest counters 413 28 Forward Packets Integer 414 29 Reverse Bytes Integer Dest-to-Source counters 415 30 Reverse Packets Integer 416 31 First Time Timestamp Activity times 417 32 Last Active Time Timestamp 418 33 Source Subscriber ID String Session attributes 419 34 Destination Subscriber ID String 420 35 Session ID String 422 36 Source Class Integer "Computed" attributes 423 37 Destination Class Integer 424 38 Flow Class Integer 425 39 Source Kind Integer 426 40 Destination Kind Integer 427 41 Flow Kind Integer 429 50 MatchingStoD Integer PME variable 431 51 v1 Integer Meter Variables 432 52 v2 Integer 433 53 v3 Integer 434 54 v4 Integer 435 55 v5 Integer 437 65-127 "Extended" attributes 438 (to be defined by the RTFM working group) 440 4.5. ISDN MIB 442 The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for 443 SNMP-based management of ISDN terminal interfaces. It does not 444 explicitly define anything related to accounting, however it does 445 define isdnBearerChargedUnits as 447 The number of charged units for the current or last connection. 448 For incoming calls or if charging information is not supplied 449 by the switch, the value of this object is zero. 451 This allows for an ISDN switch to convert its traffic flow data (such 452 as Call Connect Time) into charging data. 454 4.5.1. ISDN Attributes 456 The relevant object in the MIB is the ISDN bearer table, which has 457 entries in the following form: 459 IsdnBearerEntry ::= 460 SEQUENCE { 461 isdnBearerChannelType INTEGER, 462 isdnBearerOperStatus INTEGER, 463 isdnBearerChannelNumber INTEGER, 464 isdnBearerPeerAddress DisplayString, 465 isdnBearerPeerSubAddress DisplayString, 466 isdnBearerCallOrigin INTEGER, 467 isdnBearerInfoType INTEGER, 468 isdnBearerMultirate TruthValue, 469 isdnBearerCallSetupTime TimeStamp, 470 isdnBearerCallConnectTime TimeStamp, 471 isdnBearerChargedUnits Gauge32 472 } 474 4.6. AToMMIB 476 The "ATM Accounting Information MIB" document [ATM-ACT] describes a 477 large set of accounting objects for ATM connections. An administra- 478 tor may select objects from this set using a selector of the form 479 (subtree, list) where "subtree" specifies an object identifier from 480 the AToMMIB. For each subtree there is a table holding values for 481 each ATM connection. The required connections are indicated by set- 482 ting bits in "list," which is an octet string. For example, the set 483 containing the number of received cells for the first eight ATM con- 484 nections would be selected by (atmAcctngReceivedCells, 0xFF). 486 The Connection-Oriented Accounting MIB document [ATM-COLL] defines a 487 MIB providing managed objects used for controlling the collection and 488 storage of accounting information for connection-oriented networks 489 such as ATM. The accounting data is collected into files for later 490 retrieval via a file transfer protocol. Records within an accounting 491 file are stored as BER strings [ASN1, BER]. 493 4.6.1. AToMMIB Attributes 495 Accounting data objects within the AToMMBIB are identified by the 496 last integer in their object identifiers. 498 The ATM accounting data objects are: 500 1 atmAcctngConnectionType 501 2 atmAcctngCastType 502 3 atmAcctngIfName 503 4 atmAcctngIfAlias 504 5 atmAcctngVpi 505 6 atmAcctngVci 506 7 atmAcctngCallingParty 507 8 atmAcctngCalledParty 508 9 atmAcctngCallReference 509 10 atmAcctngStartTime 510 11 atmAcctngCollectionTime 511 12 atmAcctngCollectMode 512 13 atmAcctngReleaseCause 513 14 atmAcctngServiceCategory 514 15 atmAcctngTransmittedCells 515 16 atmAcctngTransmittedClp0Cells 516 17 atmAcctngReceivedCells 517 18 atmAcctngReceivedClp0Cells 518 19 atmAcctngTransmitTrafficDescriptorType 519 20 atmAcctngTransmitTrafficDescriptorParam1 520 21 atmAcctngTransmitTrafficDescriptorParam2 521 22 atmAcctngTransmitTrafficDescriptorParam3 522 23 atmAcctngTransmitTrafficDescriptorParam4 523 24 atmAcctngTransmitTrafficDescriptorParam5 524 25 atmAcctngReceiveTrafficDescriptorType 525 26 atmAcctngReceiveTrafficDescriptorParam1 526 27 atmAcctngReceiveTrafficDescriptorParam2 527 28 atmAcctngReceiveTrafficDescriptorParam3 528 29 atmAcctngReceiveTrafficDescriptorParam4 529 30 atmAcctngReceiveTrafficDescriptorParam5 530 31 atmAcctngCallingPartySubAddress 531 32 atmAcctngCalledPartySubAddress 532 33 atmAcctngRecordCrc16 534 4.7. QoS: RSVP and DIFFSERV 536 As we move towards providing more than simple "best effort" connec- 537 tivity, there has been a tremendous surge of interest in (and work 538 on) protocols to provide managed Quality of Service for Internet ses- 539 sions. This is of particular interest for the provision of "Inte- 540 grated Services," i.e. the transport of audio, video, real-time, and 541 classical data traffic within a single network infrastructure. 543 Two approaches to this have emerged so far: 545 - the Integrated Services architecture (intserv) [IIS-ARC], with its 546 accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's 547 Common Open Policy Service protocol, COPS [RAP-COPS] 549 - the Differentiated Services architecture (diffserv) [DSRV-ARC] 551 RSVP is a signaling protocol that applications may use to request 552 resources from the network. The network responds by explicitly 553 admitting or rejecting RSVP requests. Certain applications that have 554 quantifiable resource requirements express these requirements using 555 intserv parameters [IIS-SPEC]. 557 Diffserv networks classify packets into one of a small number of 558 aggregated flows or "classes", based on the diffserv codepoint (DSCP) 559 in the packet's IP header. At each diffserv router, packets are sub- 560 jected to a "per-hop behavior" (PHB), which is invoked by the DSCP. 561 Since RSVP is purely a requirements signalling protocol it can also 562 be used to request connections from a diffserv network [RS-DS-OP]. 564 4.7.1. RSVP and DIFFSERV Attributes 566 A set of parameters for specifying a requested Quality of Service are 567 given in [IIS-SPEC]. These have been turned into accounting 568 attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP- 569 MIB]. 571 The RTFM QoS attributes are: 573 98 QoSService 574 99 QoSStyle 575 100 QoSRate 576 101 QoSSlackTerm 577 102 QoSTokenBucketRate 578 103 QoSTokenBucketSize 579 104 QoSPeakDataRate 580 105 QoSMinPolicedUnit 581 106 QoSMaxPolicedUnit 583 The RSVP MIB contains a large number of objects, arranged within the 584 following sections: 586 General Objects 587 Session Statistics Table 588 Session Sender Table 589 Reservation Requests Received Table 590 Reservation Requests Forwarded Table 591 RSVP Interface Attributes Table 592 RSVP Neighbor Table 594 The Session tables contain information such as the numbers of senders 595 and receivers for each session, while the Reservation Requests tables 596 contain details of requests handled by the RSVP router. There are 597 too many objects to list here, but many of them could be used for 598 accounting. In particular, RSVP Requests contain the specification 599 of the service parameters requested by a user; these, together with 600 the actual usage data for the connection make up an accounting record 601 for that usage. 603 5. ITU-T Documents 605 5.1. Q.825: Call Detail Recording 607 ITU-T Recommendation Q.825 specifies how CDRs (Call Detail Records) 608 are produced and managed in Network Elements for POTS, ISDN and IN 609 (Intelligent Networks). 611 Uses of Call Detail information for various purposes are discussed. 613 Each call produces one or more records describing events that 614 occurred during the life of a call. Data may be produced in real 615 time (single CDRs), near real-time (blocks of CDRs), or as batch 616 files of CDRs. 618 The information model for Call Detail Recording is formally described 619 in terms of an Entity-Relationship model, and an object model speci- 620 fied in terms of GDMO templates (Guidelines for the Definition of 621 Managed Objects). Note that this model includes the ways in which 622 CDRs are transported from the (NE) Network Element where they are 623 generated to the OS (Operations System) where they are used. 625 5.2. Q.825 Attributes 627 The following attributes are defined. The explanations given are 628 very brief summaries only, see [Q-825] for the complete text. 630 1 accessDelivery 631 Indicates that the call was delivered to the called subscriber 633 2 accountCodeInput 634 Account code (for billing), supplied by subscriber. 636 78 additionalParticipantInfo 637 (No details given) 639 5 b-PartyCategory 640 Subscriber category for called subscriber. 642 4 bearerService 643 Bearer capability information (only for ISDN calls). 645 13 cDRPurpose 646 Reason for triggering this Call Data Record. 648 70 callDetailDataId 649 Unique identifier for the CallDetailData object. 651 79 callDuration 652 Duration of call 654 6 callIdentificationNumber 655 Identification number for call; all records produced for this 656 call have the same callIdenfificationNumber. 658 73 callStatus 659 Identifies whether the call was answered or not. 661 9 calledPartyNumber 662 Telephone number of the called subscriber (may be a 663 "diverted-to" or "translated" number. 665 7 callingPartyCategory 666 Calling subscriber category. 668 8 callingPartyNumber 669 Telephone number of the calling party. 671 10 callingPartyNumberNotScreened 672 An additional, user-provided (not screened) number to the 673 calling party. 675 11 callingPartyType 676 Calling subscriber type. 678 74 carrierId 679 Carrier ID to which the call is sent. 681 12 cause 682 Cause and location value for the termination of the call. 684 14 chargedDirectoryNumber 685 Charged directory number (where the charged participant ele- 686 ment can't indicate the number). 688 16 chargedParticipant 689 Participant to be charged for the usage. 691 15 chargingInformation 692 Charging information generated by a Network Element which is 693 capable of charging. 695 17 configurationMask 696 Time consumption, e.g. from B-answer to termination time, 697 between partial call records, etc. 699 18 conversationTime 700 Time consumption from B-answer to end of call. 702 19 creationTriggerList 703 List of trigger values which will create Call Detail data 704 objects. 706 75 dPC 707 Destination point code (for analysis purposes). 709 20 dataValidity 710 Indicates that the NE is having problems, contents of the 711 generated Call Detail record is not reliable. 713 23 durationTimeACM 714 Time consumption from seizure until received ACM. 716 21 durationTimeB-Answer 717 Time consumption from seizure until B-answer. 719 22 durationTimeNoB-Answer 720 Time from seizure to termination when no B-answer was 721 received. 723 25 exchangeInfo 724 Identity of exchange where Call Detail record was generated. 726 26 fallbackBearerService 727 Fallback bearer capability information for a call. 729 27 glare 730 Indicates if a glare condition was encountered. 732 31 iNServiceInformationList 733 Contains information about the use of IN (Intelligent Network) 734 services. 736 32 iNSpecificInformation 737 Contains information about the use of one IN service. 739 33 iSUPPreferred 740 Indicate whether an ISUP preference was requested. 742 28 immediateNotificationForUsageMetering 743 Indicates that the Call Detail records requires 744 immediate data transfer to the Operations System. 746 34 maxBlockSize 747 Maximum number of Call Detail records in a block. 749 35 maxTimeInterval 750 Maximum latency allowable for near-real-time Call Detail 751 data delivery. 753 36 networkManagementControls 754 Indicates which Traffic Management Control has affected 755 the call. 757 37 networkProviderId 758 Indicates the Network Provider for whom the CDR is generated. 760 76 oPC 761 Originating point code for a failed call (for analysis 762 purposes). 764 38 operatorSpecific1AdditionalNumber 765 40 operatorSpecific2AdditionalNumber 766 42 operatorSpecific3AdditionalNumber 767 Operator-defined additional participant information. 769 39 operatorSpecific1Number 770 41 operatorSpecific2Number 771 43 operatorSpecific3Number 772 Operator-defined participant information. 774 44 originalCalledNumber 775 Telephone number of the original called party. 777 45 partialGeneration 778 Included if the CDR (Call Detail record) output is partial. 779 Such CDRs have a field indicating their partial record number. 781 77 participantInfo 782 (No details given). 784 46 percentageToBeBilled 785 Percentage to be billed when normal billing rules are 786 not to be followed. 788 47 periodicTrigger 789 Defines the intervals at which the CDR file should be created. 791 48 personalUserId 792 Internationally unique personal User Identity (for UPT calls). 794 49 physicalLineCode 795 Identifies the call subscriber's physical line. 797 50 progress 798 Describes an event which occurred during the life of a call. 800 51 queueInfo 801 Used to record usage of queueing resources with IN calls. 803 52 receivedDigits 804 The digits dialled by the subscriber. (Normally only included 805 for customer care purposes). 807 53 recordExtensions 808 Information elements added by network operators and/or 809 manufacturers in addition to the standard ones above. 811 6. Other Documents 812 6.1. TIPHON: ETSI TS 101 321 814 TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which han- 815 dles accounting and authorization requests and responses. 817 The following are elements selected from TIPHON's DTD that are used 818 for accounting. 820 821 Identifies a numeric value. Expressed using the period (.) as a 822 decimal separator with no punctuation as the thousands separator. 824 825 Contains a call's H.323 CallID value, and is thus used to 826 uniquely identify individual calls. 828 829 Defines the financial currency in use for the parent element. 831 838 Indicates the number of units being accounted 840 841 Indicates a type of service being priced, authorized, or 842 reported. An empty Service element indicates basic Internet 843 telephony service, which is the only service type defined by 844 V1.4.2 of the specification. The specification notes that "Later 845 revisions of this standard are expected to specify more enhanced 846 service definitions to represent quality of service, 847 availability, payment methods, etc." 849 856 A restricted form of [ISO-DATE] that indicates the time at which 857 the component was generated. 859 860 Contains an integer, decimal valued identifier assigned to a 861 specific authorized transaction. 863 864 Indicates the units by which pricing is measured or usage 865 recorded. It shall contain one of the following values: 866 s seconds 867 p packets (datagrams) 868 byte bytes 870 871 Collects information describing the usage of a service. 873 6.2. MSIX 875 MSIX [MSIX-SPEC] is an XML-based open protocol transported by HTTP 876 that is used to make accounting service definitions and transmit ser- 877 vice usage information. As its service definitions are parameterized 878 and dynamic, it makes no definition of services or attributes itself, 879 but allows implementors to make their own. It specifies only the 880 base data types that attributes may take: STRING, UNISTRING, INT32, 881 FLOAT, DOUBLE, BOOLEAN, TIMESTAMP. 883 7. Accounting File and Record Formats 885 7.1. ASN.1 Records 887 7.1.1. RTFM and AToMMIB 889 RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists 890 of attributes into accounting records. RTFM uses SNMP to retrieve 891 such records as BER strings, thus avoiding having to have an object 892 identifier for every object. 894 AToMMIB carries this a stage further by defining an accounting file 895 format in ASN.1 and making it available for retrieval by a file 896 transfer protocol, thereby providing a more efficient alternative to 897 simply retrieving the records using SNMP. 899 7.1.2. Q.825 901 A Q.825 Call Record is an ASN.1 SET containing a specified group of 902 the Q.825 attributes. Call records would presumably be encoded as 903 BER strings before being collected for later processing. 905 7.2. Binary Records 907 7.2.1. RADIUS 909 Radius packets carry a sequence of attributes and their values, as 910 (Type, Length, Value) triples. The format of the value field is one 911 of four data types. 913 string 0-253 octets 915 address 32 bit value, most significant octet first. 917 integer 32 bit value, most significant octet first. 919 time 32 bit value, most significant octet first -- seconds 920 since 00:00:00 GMT, January 1, 1970. The standard 921 Attributes do not use this data type but it is presented 922 here for possible use within Vendor-Specific attributes. 924 7.2.2. DIAMETER 926 Each DIAMETER message consists of multiple AVP's that are 32-bit 927 aligned, with the following format: 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | AVP Code | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | AVP Length | AVP Flags | Reserved | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | 937 // (AVP contents) // 938 | | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Code 942 Identifies the AVP; values of this field are defined below. 944 AVP Length 945 A 16-bit field contains the total object length in bytes. 946 Must always be a multiple of 4, and at least 8. 948 AVP Flags 949 0x01: Mandatory-Support 950 0x02: SS-Encrypted-Data 951 0x03: PK-Encrypted-Data 952 0x04: Vendor-Specific-AVP 954 7.3. Text Records 956 7.3.1. ROAMOPS 958 ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a gen- 959 eral, text-based format for accounting data files, described in a 960 straightforward BNF grammar. Its file header contains a field indi- 961 cating the default protocol from which accounting attributes are 962 drawn. If an attribute from another protocol is to be used, it is 963 preceded by its protocol name, for example rtfm//27 would be RTFM's 964 "forward bytes" attribute. Comments in an ADIF file begin with a 965 cross-hatch. 967 Example: An ADIF file encoding RADIUS accounting data 969 version: 1 970 device: server3 971 description: Accounting Server 3 972 date: 02 Mar 1998 12:19:01 -0500 973 defaultProtocol: radius 975 #NAS-IP-Address 976 4: 204.45.34.12 977 #NAS-Port 978 5: 12 979 #NAS-Port-Type 980 61: 2 981 #User-Name 982 1: fred@bigco.com 983 #Acct-Status-Type 984 40: 2 985 #Acct-Delay-Time 986 41: 14 987 #Acct-Input-Octets 988 42: 234732 989 #Acct-Output-Octets 990 43: 15439 991 #Acct-Session-Id 992 44: 185 993 #Acct-Authentic 994 45: 1 995 #Acct-Session-Time 996 46: 1238 997 #Acct-Input-Packets 998 47: 153 999 #Acct-Output-Packets 1000 48: 148 1001 #Acct-Terminate-Cause 1002 49: 11 1003 #Acct-Multi-Session-Id 1004 50: 73 1005 #Acct-Link-Count 1006 51: 2 1008 8. AAA Requirements 1010 8.1. A Well-defined Set of Attributes 1012 AAA needs a well-defined set of attributes whose values are to be 1013 carried in records to or from accounting servers. 1015 Most of the existing sets of documents described above include a set 1016 of attributes, identified by small integers. It is likely that these 1017 sets overlap, i.e. that some of them have attributes which represent 1018 the same quantity using different names in different sets. This sug- 1019 gests it might be possible to produce a single combined set of "uni- 1020 versal" accounting attributes, but such a "universal" set does not 1021 seem worthwhile. 1023 The ADIF approach of specifying a default protocol (from which 1024 attributes are assumed to come) and identifying any exceptions seems 1025 much more practical. We therefore propose that AAA should use the 1026 ADIF convention (or something like it) to identify attributes, 1027 together with all the sets of attributes covered by the [ASG-NBR] 1028 document. 1030 8.2. A Simple Interchange Format 1032 AAA needs a simple interchange file format, to be used for accounting 1033 data. Several schemes for packaging and transporting such data have 1034 been described above. 1036 The SNMP-based ones fit well within the context of an SNMP-based net- 1037 work management system. RTFM and AToMMIB provide ways to reduce the 1038 SNMP overhead for collecting data, and AToMMIB defines a complete 1039 file format. Both provide good ways to collect accounting data. 1041 As an interchange format, however, ASN.1-based schemes suffer from 1042 being rather complex binary structures. This means that one requires 1043 suitable tools to work with them, as compared to plain-text files 1044 where one can use existing text-based utilities. 1046 The binary schemes such as RADIUS and DIAMETER have simpler struc- 1047 tures, but they too need purpose-built tools. For general use they 1048 would need to be extended to allow them to use attributes from other 1049 protocols. 1051 From the point of view of being easy for humans to understand, ADIF 1052 seems very promising. Of course any processing program would need a 1053 suitable ADIF input parser, but using plain-text files makes them 1054 much easier to understand. 1056 TIPHON's record format is specified by an XML DTD. While XML repre- 1057 sentations have the advantages of being well-known, they are limited 1058 by XML's inability to specify type or other validity checking for 1059 information within the tags. This situation will likely be improved 1060 by the XML Schema [XML-SCHM] efforts that are underway, but a stable 1061 reference is not yet available. 1063 9. Issues 1065 It is generally agreed that there is a need for a standard record 1066 format and transport protocol for communication between Service Ele- 1067 ments and Accounting Servers. 1069 There is less agreement on the following issues: 1071 o Separate or integral record format and transport protocol 1072 o Standard set of base data types 1073 o Service definitions: part of the protocol or separately defined 1074 o Service definition namespace management 1076 The following sections address these issues. 1078 9.1. Record Format vs. Protocol 1080 All known Internet-centric billing protocols to date have an integral 1081 record format. That is, the collection of Properties that describe a 1082 Usage Event are specified as an integral part of the protocol, typi- 1083 cally as a part of a "submit" message that is used to transmit a 1084 Usage Event from a Service Entity to an Accounting Server. 1086 It may be worthwhile to define a record format that is independent of 1087 the transport protocol. Such a record format should support both 1088 representation of individual records and records in bulk, as Usage 1089 Events are often aggregated and transmitted in bulk. 1091 A separate record format is useful for temporary file storage and for 1092 archival purposes. Multiple transport protocols may be defined with- 1093 out affecting the record format. The task of auditing is made easier 1094 if a standard file format is defined. If a canonical format is used, 1095 bulk records may be hashed with MD5 [MD5] or a similar function, for 1096 reliability and security purposes. 1098 +------------+ 1099 | transport | 1100 | header | 1101 +------------+ +------------+ 1102 | | | | 1103 | Usage | | Usage | 1104 | Event(s) | | Event(s) | 1105 | | | | 1106 | | | | 1107 +------------+ +------------+ 1108 | trailer | 1109 +------------+ 1111 record format transport protocol 1113 If the protocol is written such that it can transmit Usage Events in 1114 the record format, no record rewriting for transport is required. 1116 9.2. Tagged, Typed Data 1118 Each Property is named by a textual identifier and carries a value 1119 and a data type indicator, which governs interpretation of the value. 1121 It may also be useful for each Property to carry a Units of Measure 1122 identifier. ETSI's TIPHON [TIPHON] specification takes this 1123 approach. TS 101 321 also carries an Increment field, which denomi- 1124 nates the Property's Unit of Measure field. Whether this additional 1125 convenience is necessary is a matter for discussion. 1127 9.2.1. Standard Type Definitions 1129 It is useful to define a standard set of primitive data types to be 1130 used by the record format and protocol. Looking at the prior art, 1131 Diameter supports Data (arbitrary octets), String (UTF-8), Address 1132 (32 or 128 bit), Integer32, Integer64, and Time (32 bits, seconds 1133 since 1970). MSIX [MSIX-SPEC] supports String, Unistring, Int32, 1134 Float, Double, Boolean, and Timestamp. SNMP [SNMP] offers OBJECT 1135 IDENTIFIER, NULL, OCTET STRING, IpAddress, NetworkAddress, Counter, 1136 Gauge, TimeTicks, and Opaque. 1138 An appropriate set would likely include booleans, 32 and 64 bit 1139 signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and 1140 UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps. 1142 9.3. Transaction Identifiers 1144 Each Usage Event requires its own unique identifier. 1146 It is expedient to allow Service Elements to create their own unique 1147 identifiers. In this manner, Usage Events can be created and 1148 archived without the involvement of an Accounting Server. 1150 A number of methods for creating unique identifiers are well known. 1151 One popular identifier is an amalgamation of a monotonically increas- 1152 ing sequence number, a large random value, a network element identi- 1153 fier, and a timestamp. Another possible source of entropy is a hash 1154 value of all or part of the record itself. 1156 RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give guid- 1157 ance on the creation of good unique identifiers. 1159 9.4. Service Definitions 1161 A critical differentiator in accounting record formats and protocols 1162 is their capability to account for arbitrary service usage. To date, 1163 no accounting record format or protocol that can handle arbitrary 1164 service definitions has achieved broad acceptance on the Internet. 1166 This section analyzes the issues in service definition and makes a 1167 case for a record format and protocol with the capability to carry 1168 Usage Events for rich, independently-defined services. 1170 9.4.1. Service Independence 1172 It is informative to survey a number of popular Internet protocols 1173 and examine their capacities for extension. These protocols can be 1174 categorized into two broad categories--"complete" protocols that have 1175 little provision for extension and "framework" protocols that are 1176 incomplete, but coupled with extension or application documents pro- 1177 vide only a basis for future extension. 1179 Examples of "complete" protocols are NTP [NTP], NNTP [NNTP], RADIUS 1180 Accounting [RAD-ACC], and HTML [HTML]. 1182 Network Time Protocol [NTP] defines everything. Aside from leaving 1183 some field values "reserved for future use," all the fields are 1184 fixed-width and completely defined. This is appropriate for a simple 1185 protocol that solves a simple problem. The notion of "time" is 1186 unlikely to be extended (we hope). 1188 Network News Transfer Protocol [NEWS-PROT] specifies that further 1189 commands may be added, and requests that non-standard implementations 1190 use the "X-" experimental prefix so as to not conflict with future 1191 additions. The content of news is 7-bit data, with the high-order 1192 bit cleared to 0. Nothing further about the content is defined. 1193 There is no in-protocol facility for automating decoding of content 1194 type. 1196 We pay particular attention to RADIUS Accounting [RAD-ACC]. Perhaps 1197 the second biggest complaint (after security shortcomings) about 1198 RADIUS Accounting is its preassigned and fixed set of "Types". These 1199 are coded as a range of octets from 40 to 51 and are as follows: 1201 40 Acct-Status-Type 1202 41 Acct-Delay-Time 1203 42 Acct-Input-Octets 1204 43 Acct-Output-Octets 1205 44 Acct-Session-Id 1206 45 Acct-Authentic 1207 46 Acct-Session-Time 1208 47 Acct-Input-Packets 1209 48 Acct-Output-Packets 1210 49 Acct-Terminate-Cause 1211 50 Acct-Multi-Session-Id 1212 51 Acct-Link-Count 1214 These identifiers were designed to account for packet-based network 1215 access service. They are ill-suited for describing other services. 1217 HTML/2.0 [HTML] is mostly a "complete" protocol, but with W3C's 1218 HTML/4.0, it is becoming more of a framework protocol. HTML/2.0 1219 specified a fixed set of markups, with no provision for addition 1220 (without protocol revision). 1222 Examples of "framework" protocols are HTTP, XML, and SNMP. 1224 HTTP/1.1 [HTTP] is somewhat similar to NNTP in that it is designed to 1225 transport arbitrary content. It is different in that it supports 1226 description of that content through its Content-Type, Content-Encod- 1227 ing, Accept-Encoding, and Transfer-Encoding header fields. New types 1228 of content can be designated and carried by HTTP/1.1 without modifi- 1229 cation to the HTTP protocol. 1231 XML [XML] is the king-hell general-purpose "framework" encoding. DTD 1232 publishing is left to users. There is no standard registry of DTDs. 1234 SNMP presents a successful example of a "framework" protocol. SNMP's 1235 authors envisioned SNMP as a general management protocol, and allow 1236 extension through the use of private MIBs. SNMP's ASN.1 MIBs are 1237 defined, published, and standardized without the necessity to modify 1238 or even involve the SNMP standard itself. From "An Overview of SNMP" 1239 [SNMP-OVER]: 1241 It can easily be argued that SNMP has become prominent mainly from 1242 its ability to augment the standard set of MIB objects with new 1243 values specific for certain applications and devices. Hence, new 1244 functionality can continuously be added to SNMP, since a standard 1245 method has been defined to incorporate that functionality into 1246 SNMP devices and network managers. 1248 Most accounting protocols are "complete" protocols, with either a 1249 completely defined service or set of services (RADIUS Accounting) or 1250 with one or more services defined and provision for "extension" ser- 1251 vices to be added to the protocol later (TIPHON). While the latter 1252 is preferable, it would be better to have a more SNMP-like approach 1253 where the accounting record format and protocol merely provide a 1254 framework for service definition, and leave the task of service defi- 1255 nition (and optionally standardization) to separate efforts. In this 1256 manner, the accounting protocol itself would not have to be modified 1257 to handle new services. 1259 9.4.2. Versioned Service Definitions 1261 Versioning is a naming and compatibility issue. Separate version 1262 identifiers are useful in service definition because they enables 1263 service definitions to be upgraded without a possibly awkward name 1264 change. They also enable possible compatibility between different 1265 versions of the same service. 1267 An example could be the service definition of a phone call. Version 1268 1 might define Properties for the start time, duration, and called 1269 and calling party numbers. Later, version 2 is defined, which aug- 1270 ments the former Service with a byte count. An Accounting Server, 1271 aware of only Version 1, may accept Version 2 records, discarding the 1272 additional information (forwards compatibility). Alternately, if an 1273 Accounting Server is made aware of version 2, it could optionally 1274 still accept version 1 records from Service Elements, provided it 1275 does not require the additional information to properly account for 1276 service usage (backwards compatibility). 1278 9.4.3. Relationships Among Usage Events 1280 A case that accounting record formats and protocols to date have 1281 failed to sufficiently address is that of "compound" service descrip- 1282 tion. 1284 A compound service is a service that is described as a composition of 1285 other services. A conference call, for example, is well described as 1286 a number of point-to-point calls to a conference bridge. It is 1287 important to account for the individual calls, rather than just sum- 1288 ming up an aggregate, both for auditing purposes and to enable dif- 1289 ferential rating. If these calls are to be reported to the Account- 1290 ing Server individually, the Usage Events require a shared identifier 1291 that can be used by the Accounting Server and other backend systems 1292 to group the records together. 1294 For a Service Element to report compound events over time as a 1295 succession of individual Usage Events, the accounting protocol 1296 requires a facility to communicate that the compound event has 1297 started and stopped. The "start" message can be implicit--the trans- 1298 mission of the first Usage Event will suffice. An additional 1299 semaphore is required to tell the Accounting Server that the compound 1300 service is complete and may be further processed. This is necessary 1301 to prevent the Accounting Server from prematurely processing compound 1302 events that overlap the end of a billing period. 1304 RADIUS Accounting has some provision for this sort of accounting with 1305 its "Acct-Multi-Session-Id" field. Unfortunately, RADIUS Account- 1306 ing's other shortcomings preclude it from being used in general pur- 1307 pose service usage description. 1309 9.4.4. Service Namespace Management 1311 "Framework" protocols, as previously mentioned, do not define com- 1312 plete schema for their payload. For interoperability to be achieved, 1313 it must be possible for: 1315 (1) content definers to specify definitions without conflicting with 1316 the names of other definitions 1318 (2) protocol users to find and use content definitions 1320 Condition (1) can be readily managed through IANA assignment or by 1321 using an existing namespace differentiator (for example, DNS). 1323 Condition (2) is harder, and places considerable burden on the imple- 1324 mentors. Their clients and servers must be able, statically or 1325 dynamically, to find and validate definitions, and manage versioning 1326 issues. 1328 As previously mentioned, XML provides no facility for DTD discovery 1329 or namespace management. XML, however, specifies only a document 1330 format, and as such does not need to specify support for more "proto- 1331 col" oriented problems. 1333 For an accounting record format and protocol, an approach closer to 1334 SNMP's is useful. SNMP uses an ISO-managed dotted-decimal namespace. 1335 An IANA-managed registry of service types is a possibility. Another 1336 possibility, used by MSIX [MSIX-SPEC], is for Service Element cre- 1337 ators to identify their services by concatenation of a new service 1338 name with existing unique identifier, such as a domain name. 1340 A standard record format for service definitions would make it possi- 1341 ble for Service Element creators to directly supply accounting system 1342 managers with the required definitions, via the network or by other 1343 means. 1345 10. Encodings 1347 It may be useful to define more than one record encoding. 1349 A "verbose" XML encoding is useful in that it is easily implemented 1350 and records can be syntactically verified with existing tools. 1351 "Human-readable" protocols tend to have an edge on "bitfield" proto- 1352 cols where ease of implementation is paramount and the application 1353 can tolerate any additional processing required to generate, parse, 1354 and transport the records. 1356 A alternative "compressed" encoding that makes minimal use of storage 1357 and processing may be useful in many contexts. 1359 There are disadvantages to supporting multiple encodings. Multiple 1360 encodings mandate the requirement for capabilities exchange between 1361 Service Element and Accounting Server. Also, implementations can 1362 tend to "drift apart," with one encoding better-supported than 1363 another. Unless all encodings are mandatory, implementors may find 1364 they are unable to interoperate because they picked the wrong encod- 1365 ing. 1367 11. Security Considerations 1369 This draft summarises many existing IETF and ITU documents; please 1370 refer to the original documents for security considerations for their 1371 particular protocols. 1373 Security is of paramount concern in accounting. It must be possible 1374 for the accounting protocol to be carried by a secure transport. A 1375 canonical record format is useful so that regeneration of secure 1376 record hashes is possible. 1378 When dealing with accounting data files, one must of course take care 1379 that their integrity and privacy are preserved. This document, how- 1380 ever, is only concerned with the format of such files. 1382 12. References 1384 [ACC-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet 1385 Accounting Background", RFC 1272, November 1991. 1387 [ASG-NBR] Reynolds, J., Postel, J., "Assigned Numbers," 1388 RFC 1700, October 1994. 1390 [ASN1] Information processing systems - Open Systems 1391 Interconnection - Specification of Abstract Syntax Notation 1392 One (ASN.1), International Organization for Standardization, 1393 International Standard 8824, December 1987. 1395 [ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, 1396 A., "Accounting Information for ATM Networks," 1397 RFC 2512, February 1999. 1399 [ATM-COLL] McCloghrie, K., Heinanen, J., Greene, W. and Prasad, 1400 A., " Managed Objects for Controlling the Collection 1401 and Storage of Accounting Information for Connection- 1402 Oriented Networks," RFC 2513, February 1999. 1404 [BER] Information processing systems - Open Systems 1405 Interconnection - Specification of Basic Encoding Rules for 1406 Abstract Notation One (ASN.1), International Organization for 1407 Standardization, International Standard 8825, December 1987. 1409 [DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User 1410 Authentication Extensions," Internet Draft (Work in 1411 progress), draft-calhoun-diameter-authent- .. 1413 [DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER 1414 Framework Document," Internet Draft (Work in 1415 progress), draft-calhoun-diameter-framework- .. 1417 [DIAM-SIP] Pan, P. and Clahoun, P., "DIAMETER: Policy and 1418 Accounting Extension for SIP Framework Document," 1419 Internet Draft (Work in progress), draft-pan-diameter-sip- 1421 [DSRV-ARC] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 1422 and W. Weiss, "An Architecture for Differentiated 1423 Services", RFC 2475, December 1998. 1425 [HTML] Berners-Lee, T., D. Connolly, "Hypertext Markup Language - 1426 2.0", RFC 1866, November 1995. 1428 [HTTP] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, and 1429 T. Berners-Lee. "Hypertext Transfer Protocol--HTTP/1.1", 1430 RFC 2068, January 1997. 1432 [ICAL-CORE] Dawson, F., D. Stenerson, "Internet Calendaring and 1433 Scheduling Core Object Specification", RFC 2445, November 1434 1998. 1436 [IIS-ARC] Braden, R., Clark, D. and Shenker, S., "Integrated 1437 Services in the Internet Architecture: an Overview", 1438 RFC 1633, June 1994 1440 [IIS-SPEC] Shenker, S., Partridge, C., Guerin, R.: "Specification of 1441 Guaranteed Quality of Service," RFC 2212, 1997. 1443 [ISDN-MIB] Roeck, G., "ISDN Management Information Base using 1444 SMIv2," RFC 2127, March 1997. 1446 [ISO-DATE] "Data elements and interchange formats -- Information 1447 interchange -- Representation of dates and times", 1448 ISO 8601:1988. 1450 [MAIL] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 1451 MESSAGES", RFC 822, August 1982. 1453 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1454 April 1992. 1456 [MSIX-SPEC] Blount, A., D. Young, "Metered Service Information Exchange 1457 1.2", Work in Progress, , 1458 July 1999. 1460 [NEWS-MSGS] Horton, M., R. Adams, "Standard for Interchange of USENET 1461 Messages", RFC 1036, December 1987. 1463 [NEWS-PROT] Kantor, B., P. Lapsley, "Network News Transfer Protocol" 1464 RFC 977, Febuary 1986. 1466 [NTP] Mills, D.L., "Network Time Protocol (NTP)", RFC 958, 1467 September 1985. 1469 [Q-825] "Specification of TMN applications at the Q3 1470 interface: Call detail recording," 1471 ITU-T Recommendation Q.825, 1998. 1473 [RAD-ACC] Rigney, C., "RADIUS Accounting," RFC 2139, April 1997. 1475 [RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS 1476 Extensions," Internet Draft (Work in progress), 1477 draft-ietf-radius-ext- .. 1479 [RAD-PROT] Rigney, C., Rubens, A., Simpson, W. and Willens, S., 1480 "Remote Authentication Dial In User Service (RADIUS)," 1481 RFC 2138, April 1997. 1483 [RAD-RECX] Calhoun, P.R. and Beadles, M.., "RADIUS Accounting 1484 Interim Accounting Record Extension," Internet Draft 1485 (Work in progress), draft-ietf-radius-acct-interim- .. 1487 [RAD-TACC] Zorn, G., Mitton, D. and Aboba, A.,"RADIUS Accounting 1488 Modifications for Tunnel Protocol Support," 1489 (Work in progress), draft-ietf-radius-tunnel-acct- .. 1491 [RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. 1492 and Sastry, A., "The COPS (Common Open Policy Service) 1493 draft-ietf-rap-cops- .. 1495 [ROAM-ADIF] Aboba, B and Lidyard, D., "The Accounting Data 1496 Interchange Format (ADIF)," Internet Draft (Work 1497 in progress), draft-ietf-roamops-actng- .. 1499 [ROAM-IMPL] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, 1500 "Review of Roaming Implementations", 1501 RFC 2194, September 1997. 1503 [RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1504 Speer, M. and Braden, R., "Interoperation of RSVP/Intserv 1505 and Diffserv Networks," Internet Draft (Work in Progress), 1506 draft-ietf-issll-diffserv-rsvp- .. 1508 [RSVP-ARC] Braden, R., Zhang, L., Berson, S., Herzog, S. and 1509 Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 1510 Functional Specification", RFC 2205, September 1997 1512 [RSVP-MIB] Baker, F., Krawczyk, J. and Sastry, A., "RSVP Management 1513 Information Base," Internet Draft (Work in Progress), 1514 draft-ietf-rsvp-mib-v2- .. 1516 [RTFM-ARC] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow 1517 Measurement: Architecture", RFC 2722, October 1999. 1519 [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 1520 Measurement: Architecture", RFC 2720, October 1999. 1522 [RTFM-NEWA] Handelman, S, Brownlee, N., Ruth, G., and Stibler, S., 1523 "New Attributes for Traffic Flow Measurement", 1524 RFC 2724, October 1999. 1526 [SIP-PROT] Handley, M.,Schulzrinne, H.,Schooler, E. and 1527 Rosenberg, J., "SIP: session initiation protocol," 1528 RFC 2543, March 1999. 1530 [SNMP] Case, J., M. Fedor, M. Schoffstall, J. Davin, "A Simple 1531 Network Management Protocol (SNMP)", RFC 1157, May 1990 1533 [SNMP-OVER] "AN OVERVIEW OF SNMP V2.0", Diversified Data Resources, Inc., 1534 http://www.ddri.com, 1999. 1536 [TIPHON] "Telecommunications and Internet Protocol Harmonization Over 1537 Networks (TIPHON); Inter-domain pricing, authorization, and 1538 usage exchange", TS 101 321 V1.4.2, December 1998. 1540 [XML] Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible 1541 Markup Language (XML) 1.0", W3C Recommendation, February 1542 1998. 1544 [XML-SCHM] "XML Schema Part 1: Structures", W3C Working Draft 17, 1545 December 1999. 1547 13. Authors' Addresses 1549 Alan Blount 1550 MetraTech Corp. 1551 330 Bear Hill Road 1552 Waltham, MA 02451 1553 Email: blount@alum.mit.edu 1555 Nevil Brownlee 1556 Information Technology Systems & Services 1557 The University of Auckland 1558 Phone: +64 9 373 7599 x8941 1559 E-mail: n.brownlee@auckland.ac.nz