doc/rfc/rfc2924.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        N. Brownlee
   8 Request for Comments: 2924                    The University of Auckland
   9 Category: Informational                                        A. Blount
  10                                                          MetraTech Corp.
  11                                                           September 2000
  12
  13
  14                 Accounting Attributes and Record Formats
  15
  16 Status of this Memo
  17
  18    This memo provides information for the Internet community.  It does
  19    not specify an Internet standard of any kind.  Distribution of this
  20    memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  25
  26 Abstract
  27
  28    This document summarises Internet Engineering Task Force (IETF) and
  29    International Telecommunication Union (ITU-T) documents related to
  30    Accounting.  A classification scheme for the Accounting Attributes in
  31    the summarised documents is presented.  Exchange formats for
  32    Accounting data records are discussed, as are advantages and
  33    disadvantages of integrated versus separate record formats and
  34    transport protocols.  This document discusses service definition
  35    independence, extensibility, and versioning.  Compound service
  36    definition capabilities are described.
  37
  38 Table of Contents
  39
  40    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   2
  41    2. Terminology and Notation . . . . . . . . . . . . . . . . . . .   3
  42    3. Architecture Model . . . . . . . . . . . . . . . . . . . . . .   4
  43    4. IETF Documents . . . . . . . . . . . . . . . . . . . . . . . .   4
  44    4.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  45    4.1.1. RADIUS Attributes  . . . . . . . . . . . . . . . . . . . .   5
  46    4.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  47    4.2.1. DIAMETER Attributes  . . . . . . . . . . . . . . . . . . .   7
  48    4.3. ROAMOPS  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
  49    4.4. RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
  50    4.4.1. RTFM Attributes  . . . . . . . . . . . . . . . . . . . . .   9
  51    4.5. ISDN MIB . . . . . . . . . . . . . . . . . . . . . . . . . .  10
  52    4.5.1. ISDN Attributes  . . . . . . . . . . . . . . . . . . . . .  10
  53    4.6. AToMMIB  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
  54    4.6.1. AToMMIB Attributes . . . . . . . . . . . . . . . . . . . .  11
  55
  56
  57
  58 Brownlee & Blount            Informational                      [Page 1]
  59 \f
  60 RFC 2924        Accounting Attributes and Record Formats  September 2000
  61
  62
  63    4.7. QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . .  12
  64    4.7.1. QoS: RSVP and DIFFSERV Attributes  . . . . . . . . . . . .  13
  65    5. ITU-T Documents  . . . . . . . . . . . . . . . . . . . . . . .  13
  66    5.1. Q.825: Call Detail Recording . . . . . . . . . . . . . . . .  13
  67    5.2. Q.825 Attributes . . . . . . . . . . . . . . . . . . . . . .  14
  68    6. Other Documents  . . . . . . . . . . . . . . . . . . . . . . .  18
  69    6.1. TIPHON: ETSI TS 101 321  . . . . . . . . . . . . . . . . . .  18
  70    6.2. MSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
  71    7. Accounting File and Record Formats . . . . . . . . . . . . . .  19
  72    7.1. ASN.1 Records  . . . . . . . . . . . . . . . . . . . . . . .  19
  73    7.1.1. RTFM and AToMMIB . . . . . . . . . . . . . . . . . . . . .  19
  74    7.1.2. Q.825  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
  75    7.2. Binary Records . . . . . . . . . . . . . . . . . . . . . . .  20
  76    7.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . .  20
  77    7.2.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . .  20
  78    7.3. Text Records . . . . . . . . . . . . . . . . . . . . . . . .  21
  79    7.3.1. ROAMOPS  . . . . . . . . . . . . . . . . . . . . . . . . .  21
  80    8. AAA Requirements . . . . . . . . . . . . . . . . . . . . . . .  22
  81    8.1. A Well-defined Set of Attributes . . . . . . . . . . . . . .  22
  82    8.2. A Simple Interchange Format  . . . . . . . . . . . . . . . .  23
  83    9. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .  23
  84    9.1. Record Format vs. Protocol . . . . . . . . . . . . . . . . .  24
  85    9.2. Tagged, Typed Data . . . . . . . . . . . . . . . . . . . . .  24
  86    9.2.1. Standard Type Definitions  . . . . . . . . . . . . . . . .  25
  87    9.3. Transaction Identifiers  . . . . . . . . . . . . . . . . . .  26
  88    9.4. Service Definitions  . . . . . . . . . . . . . . . . . . . .  26
  89    9.4.1. Service Independence . . . . . . . . . . . . . . . . . . .  27
  90    9.4.2. Versioned Service Definitions  . . . . . . . . . . . . . .  29
  91    9.4.3. Relationships Among Usage Events . . . . . . . . . . . . .  29
  92    9.4.4. Service Namespace Management . . . . . . . . . . . . . . .  30
  93    10. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . .  30
  94    11. Security Considerations . . . . . . . . . . . . . . . . . . .  31
  95    12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
  96    13. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .  35
  97    14. Full Copyright Statement  . . . . . . . . . . . . . . . . . .  36
  98
  99 1.  Introduction
 100
 101    This document summarises IETF and ITU-T documents related to
 102    Accounting.  For those documents which describe Accounting Attributes
 103    (i.e. quantities which can be measured and reported), an Attribute
 104    Summary is given.  Although several of the documents describe
 105    Attributes which are similar, no attempt is made to identify those
 106    which are the same in several documents.  An extensible
 107    classification scheme for AAA Accounting Attributes is proposed; it
 108    is a superset of the attributes in all the documents summarised.
 109
 110
 111
 112
 113
 114 Brownlee & Blount            Informational                      [Page 2]
 115 \f
 116 RFC 2924        Accounting Attributes and Record Formats  September 2000
 117
 118
 119    Many existing accounting record formats and protocols [RAD-ACT]
 120    [TIPHON] are of limited use due to their single-service descriptive
 121    facilities and lack of extensibility.  While some record formats and
 122    protocols support extensible attributes [RAD-ACT], none provide
 123    identification, type checking, or versioning support for defined
 124    groupings of attributes (service definitions).  This document makes a
 125    case for well-defined services.
 126
 127    Advantages and disadvantages of integrated versus separate record
 128    formats and transport protocols are discussed.  This document
 129    discusses service definition independence, extensibility, and
 130    versioning.  Compound service definition capabilities are described.
 131
 132 2.  Terminology and Notation
 133
 134    The following terms are used throughout the document.
 135
 136    Accounting Server
 137       A network element that accepts Usage Events from Service Elements.
 138       It acts as an interface to back-end rating, billing, and
 139       operations support systems.
 140
 141    Attribute-Value Pair (AVP)
 142       A representation for a Usage Attribute consisting of the name of
 143       the Attribute and a value.
 144
 145    Property
 146       A component of a Usage Event.  A Usage Event describing a phone
 147       call, for instance, might have a "duration" Property.
 148
 149    Service
 150       A type of task that is performed by a Service Element for a
 151       Service Consumer.
 152
 153    Service Consumer
 154       Client of a Service Element.  End-user of a network service.
 155
 156    Service Definition
 157       A specification for a particular service.  It is composed of a
 158       name or other identifier, versioning information, and a collection
 159       of Properties.
 160
 161    Service Element
 162       A network element that provides a service to Service Consumers.
 163       Examples include RAS devices, voice and fax gateways, conference
 164       bridges.
 165
 166
 167
 168
 169
 170 Brownlee & Blount            Informational                      [Page 3]
 171 \f
 172 RFC 2924        Accounting Attributes and Record Formats  September 2000
 173
 174
 175    Usage Attribute
 176       A component of a Usage Event that describes some metric of service
 177       usage.
 178
 179    Usage Event
 180       The description of an instance of service usage.
 181
 182 3.  Architecture Model
 183
 184    Service Elements provide Services to Service Consumers.  Before,
 185    while, and/or after services are provided, the Service Element
 186    reports Usage Events to an Accounting Server.  Alternately, the
 187    Accounting Server may query the Service Element for Usage Events.
 188    Usage events are sent singly or in bulk.
 189
 190       +------------+       +-----------+              +------------+
 191       |  Service   |<----->|  Service  | Usage Events | Accounting |
 192       |  Consumer  |   +-->|  Element  |------------->|   Server   |
 193       +------------+   |   +-----------+              +------------+
 194                        |
 195       +------------+   |
 196       |  Service   |<--+
 197       |  Consumer  |
 198       +------------+
 199
 200    Accounting Servers may forward Usage Events to other systems,
 201    possibly in other administrative domains.  These transfers are not
 202    addressed by this document.
 203
 204 4.  IETF Documents
 205
 206    In March 1999 there were at least 19 Internet Drafts and 8 RFCs
 207    concerned with Accounting.  These are summarised (by working group)
 208    in the following sections.
 209
 210 4.1.  RADIUS
 211
 212    The RADIUS protocol [RAD-PROT] carries authentication, authorization
 213    and configuration information between a Network Access Server (NAS)
 214    and an authentication server.  Requests and responses carried by the
 215    protocol are expressed in terms of RADIUS attributes such as User-
 216    Name, Service-Type, and so on.  These attributes provide the
 217    information needed by a RADIUS server to authenticate users and to
 218    establish authorized network service for them.
 219
 220    The protocol was extended to carry accounting information between a
 221    NAS and a shared accounting server.  This was achieved by defining a
 222    set of RADIUS accounting attributes [RAD-ACT].
 223
 224
 225
 226 Brownlee & Blount            Informational                      [Page 4]
 227 \f
 228 RFC 2924        Accounting Attributes and Record Formats  September 2000
 229
 230
 231    RADIUS packets have a short header containing the RADIUS packet type
 232    and authenticator (sixteen octets) and length, followed by a sequence
 233    of (Type, Length, Value) triples, one for each attribute.
 234
 235    RADIUS is very widely used, and a number of significant new
 236    extensions to it have been proposed.  For example [RAD-EXT] discusses
 237    extensions to implement the Extensible Authentication Protocol (EAP)
 238    and the Apple Remote Access Protocol (ARAP).  [RAD-TACC] discusses
 239    extensions to permit RADIUS to interwork effectively with tunnels
 240    using protocols such as PPTP and L2TP.
 241
 242 4.1.1.  RADIUS Attributes
 243
 244    Each RADIUS attribute is identified by an 8-bit number, referred to
 245    as the RADIUS Type field.  Up-to-date values of this field are
 246    specified in the most recent Assigned Numbers RFC [ASG-NBR], but the
 247    current list is as follows:
 248
 249    RADIUS Attributes [RAD-PROT]             36  Login-LAT-Group
 250                                             37  Framed-AppleTalk-Link
 251        1  User-Name                         38  Framed-AppleTalk-Network
 252        2  User-Password                     39  Framed-AppleTalk-Zone
 253        3  CHAP-Password
 254        4  NAS-IP-Address                    60  CHAP-Challenge
 255        5  NAS-Port                          61  NAS-Port-Type
 256        6  Service-Type                      62  Port-Limit
 257        7  Framed-Protocol                   63  Login-LAT-Port
 258        8  Framed-IP-Address
 259        9  Framed-IP-Netmask              RADIUS Accounting Attributes
 260       10  Framed-Routing                 [RAD-ACT]
 261       11  Filter-Id
 262       12  Framed-MTU                        40  Acct-Status-Type
 263       13  Framed-Compression                41  Acct-Delay-Time
 264       14  Login-IP-Host                     42  Acct-Input-Octets
 265       15  Login-Service                     43  Acct-Output-Octets
 266       16  Login-TCP-Port                    44  Acct-Session-Id
 267       17  (unassigned)                      45  Acct-Authentic
 268       18  Reply-Message                     46  Acct-Session-Time
 269       19  Callback-Number                   47  Acct-Input-Packets
 270       20  Callback-Id                       48  Acct-Output-Packets
 271       21  (unassigned)                      49  Acct-Terminate-Cause
 272       22  Framed-Route                      50  Acct-Multi-Session-Id
 273       23  Framed-IPX-Network                51  Acct-Link-Count
 274       24  State
 275       25  Class                          RADIUS Extension Attributes
 276       26  Vendor-Specific                [RAD-EXT]
 277       27  Session-Timeout
 278       28  Idle-Timeout                      52  Acct-Input-Gigawords
 279
 280
 281
 282 Brownlee & Blount            Informational                      [Page 5]
 283 \f
 284 RFC 2924        Accounting Attributes and Record Formats  September 2000
 285
 286
 287       29  Termination-Action                53  Acct-Output-Gigawords
 288       30  Called-Station-Id                 54  Unused
 289       31  Calling-Station-Id                55  Event-Timestamp
 290       32  NAS-Identifier
 291       33  Proxy-State                       70  ARAP-Password
 292       34  Login-LAT-Service                 71  ARAP-Features
 293       35  Login-LAT-Node                    72  ARAP-Zone-Access
 294       73  ARAP-Security
 295       74  ARAP-Security-Data
 296       75  Password-Retry
 297       76  Prompt
 298       77  Connect-Info
 299       78  Configuration-Token
 300       79  EAP-Message
 301       80  Message-Authenticator
 302
 303       84  ARAP-Challenge-Response
 304       85  Acct-Interim-Interval
 305       87  NAS-Port-Id
 306       88  Framed-Pool
 307
 308    RADIUS Tunneling Attributes
 309    [RAD-TACC]
 310
 311       64  Tunnel-Type
 312       65  Tunnel-Medium-Type
 313       66  Tunnel-Client-Endpoint
 314       67  Tunnel-Server-Endpoint
 315       68  Acct-Tunnel-Connection
 316       69  Tunnel-Password
 317
 318       81  Tunnel-Private-Group-ID
 319       82  Tunnel-Assignment-ID
 320       83  Tunnel-Preference
 321
 322       90  Tunnel-Client-Auth-ID
 323       91  Tunnel-Server-Auth-ID
 324
 325 4.2.  DIAMETER
 326
 327    The DIAMETER framework [DIAM-FRAM] defines a policy protocol used by
 328    clients to perform Policy, AAA and Resource Control.  This allows a
 329    single server to handle policies for many services.  The DIAMETER
 330    protocol consists of a header followed by objects.  Each object is
 331    encapsulated in a header known as an Attribute-Value Pair (AVP).
 332
 333
 334
 335
 336
 337
 338 Brownlee & Blount            Informational                      [Page 6]
 339 \f
 340 RFC 2924        Accounting Attributes and Record Formats  September 2000
 341
 342
 343    DIAMETER defines a base protocol that specifies the header formats,
 344    security extensions and requirements as well as a small number of
 345    mandatory commands and AVPs.  A new service can extend DIAMETER by
 346    extending the base protocol to support new functionality.
 347
 348    One key differentiator with DIAMETER is its inherent support for
 349    Inter-Server communication.  Although this can be achieved in a
 350    variety of ways, the most useful feature is the ability to "proxy"
 351    messages across a set of DIAMETER servers (known as a proxy chain).
 352
 353    The DIAMETER Accounting Extension document [DIAM-ACT] extends
 354    DIAMETER by defining a protocol for securely transferring accounting
 355    records over the DIAMETER base protocol.  This includes the case
 356    where accounting records may be passed through one or more
 357    intermediate proxies, in accordance with the 'referral broker' model.
 358
 359    The DIAMETER accounting protocol [DIAM-ACT] defines DIAMETER records
 360    for transferring an ADIF record (see below).  It introduces five new
 361    attributes (480..485) which specify the way in which accounting
 362    information is to be delivered between DIAMETER servers.
 363
 364 4.2.1.  DIAMETER Attributes
 365
 366    DIAMETER AVPs are identified by a 16-bit number defined in [DIAM-
 367    AUTH].  Since most of the AVPs found in that document were copied
 368    from the RADIUS protocol [RAD-PROT], it is possible to have both
 369    RADIUS and DIAMETER servers read the same dictionary and users files.
 370
 371    The backward compatibility that DIAMETER offers is intended to
 372    facilitate deployment.  To this end, DIAMETER inherits the RADIUS
 373    attributes, and adds only a few of its own.
 374
 375    In the list below attribute numbers which are used for RADIUS
 376    attributes but not for DIAMETER are indicated with a star (*).
 377    RADIUS attributes used by DIAMETER are not listed again here.
 378
 379    The DIAMETER attributes are:
 380
 381        4      (unassigned, *)
 382       17      (unassigned)
 383       21      (unassigned)
 384       24      (unassigned, *)
 385       25      (unassigned, *)
 386       27      (unassigned, *)
 387       32      (unassigned, *)
 388       33      (unassigned, *)
 389      280      Filter-Rule
 390      281      Framed-Password-Policy
 391
 392
 393
 394 Brownlee & Blount            Informational                      [Page 7]
 395 \f
 396 RFC 2924        Accounting Attributes and Record Formats  September 2000
 397
 398
 399      480      Accounting-Record-Type
 400      481      ADIF-Record
 401      482      Accounting-Interim-Interval
 402      483      Accounting-Delivery-Max-Batch
 403      484      Accounting-Delivery-Max-Delay
 404      485      Accounting-Record-Number
 405
 406      600      SIP-Sequence
 407      601      SIP-Call-ID
 408      602      SIP-To
 409      603      SIP-From
 410
 411 4.3.  ROAMOPS
 412
 413    [ROAM-IMPL] reviews the design and functionality of existing roaming
 414    implementations.  "Roaming capability" may be loosely defined as the
 415    ability to use any one of multiple Internet service providers (ISPs),
 416    while maintaining a formal customer-vendor relationship with only
 417    one.  One requirement for successful roaming is the provision of
 418    effective accounting.
 419
 420    [ROAM-ADIF] proposes a standard accounting record format, the
 421    Accounting Data Interchange Format (ADIF), which is designed to
 422    compactly represent accounting data in a protocol-independent manner.
 423    As a result, ADIF may be used to represent accounting data from any
 424    protocol using attribute value pairs (AVPs) or variable bindings.
 425
 426    ADIF does not define accounting attributes of its own.  Instead, it
 427    gives examples of accounting records using the RADIUS accounting
 428    attributes.
 429
 430 4.4.  RTFM
 431
 432    The RTFM Architecture [RTFM-ARC] provides a general method of
 433    measuring network traffic flows between "metered traffic groups".
 434    Each RTFM flow has a set of "address" attributes, which define the
 435    traffic groups at each of the flow's end-points.
 436
 437    As well as address attributes, each flow has traffic-related
 438    attributes, e.g. times of first and last packets, counts for packets
 439    and bytes in each direction.
 440
 441    RTFM flow measurements are made by RTFM meters [RTFM-MIB] and
 442    collected by RTFM meter readers using SNMP.  The MIB uses a
 443    "DataPackage" convention, which specifies the attribute values to be
 444    read from a flow table row.  The meter returns the values for each
 445
 446
 447
 448
 449
 450 Brownlee & Blount            Informational                      [Page 8]
 451 \f
 452 RFC 2924        Accounting Attributes and Record Formats  September 2000
 453
 454
 455    required attribute within a BER-encoded sequence.  This means there
 456    is only one object identifier for the whole sequence, greatly
 457    reducing the number of bytes required to retrieve the data.
 458
 459 4.4.1.  RTFM Attributes
 460
 461    RTFM attributes are identified by a 16-bit attribute number.
 462
 463    The RTFM Attributes are:
 464
 465     0  Null
 466     1  Flow Subscript                Integer    Flow table info
 467
 468     4  Source Interface              Integer    Source Address
 469     5  Source Adjacent Type          Integer
 470     6  Source Adjacent Address       String
 471     7  Source Adjacent Mask          String
 472     8  Source Peer Type              Integer
 473     9  Source Peer Address           String
 474    10  Source Peer Mask              String
 475    11  Source Trans Type             Integer
 476    12  Source Trans Address          String
 477    13  Source Trans Mask             String
 478
 479    14  Destination Interface         Integer    Destination Address
 480    15  Destination Adjacent Type     Integer
 481    16  Destination Adjacent Address  String
 482    17  Destination AdjacentMask      String
 483    18  Destination PeerType          Integer
 484    19  Destination PeerAddress       String
 485    20  Destination PeerMask          String
 486    21  Destination TransType         Integer
 487    22  Destination TransAddress      String
 488    23  Destination TransMask         String
 489
 490    26  Rule Set Number               Integer    Meter attribute
 491
 492    27  Forward Bytes                 Integer    Source-to-Dest counters
 493    28  Forward Packets               Integer
 494    29  Reverse Bytes                 Integer    Dest-to-Source counters
 495    30  Reverse Packets               Integer
 496    31  First Time                    Timestamp  Activity times
 497    32  Last Active Time              Timestamp
 498    33  Source Subscriber ID          String     Session attributes
 499    34  Destination Subscriber ID     String
 500    35  Session ID                    String
 501
 502
 503
 504
 505
 506 Brownlee & Blount            Informational                      [Page 9]
 507 \f
 508 RFC 2924        Accounting Attributes and Record Formats  September 2000
 509
 510
 511    36  Source Class                  Integer    "Computed" attributes
 512    37  Destination Class             Integer
 513    38  Flow Class                    Integer
 514    39  Source Kind                   Integer
 515    40  Destination Kind              Integer
 516    41  Flow Kind                     Integer
 517
 518    50  MatchingStoD                  Integer    PME variable
 519
 520    51  v1                            Integer    Meter Variables
 521    52  v2                            Integer
 522    53  v3                            Integer
 523    54  v4                            Integer
 524    55  v5                            Integer
 525
 526    65-127 "Extended" attributes
 527              (to be defined by the RTFM working group)
 528
 529 4.5.  ISDN MIB
 530
 531    The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for
 532    SNMP-based management of ISDN terminal interfaces.  It does not
 533    explicitly define anything related to accounting, however it does
 534    define isdnBearerChargedUnits as
 535
 536       The number of charged units for the current or last connection.
 537       For incoming calls or if charging information is not supplied by
 538       the switch, the value of this object is zero.
 539
 540    This allows for an ISDN switch to convert its traffic flow data (such
 541    as Call Connect Time) into charging data.
 542
 543 4.5.1.  ISDN Attributes
 544
 545    The relevant object in the MIB is the ISDN bearer table, which has
 546    entries in the following form:
 547
 548    IsdnBearerEntry ::=
 549        SEQUENCE {
 550            isdnBearerChannelType           INTEGER,
 551            isdnBearerOperStatus            INTEGER,
 552            isdnBearerChannelNumber         INTEGER,
 553            isdnBearerPeerAddress           DisplayString,
 554            isdnBearerPeerSubAddress        DisplayString,
 555            isdnBearerCallOrigin            INTEGER,
 556            isdnBearerInfoType              INTEGER,
 557            isdnBearerMultirate             TruthValue,
 558            isdnBearerCallSetupTime         TimeStamp,
 559
 560
 561
 562 Brownlee & Blount            Informational                     [Page 10]
 563 \f
 564 RFC 2924        Accounting Attributes and Record Formats  September 2000
 565
 566
 567            isdnBearerCallConnectTime       TimeStamp,
 568            isdnBearerChargedUnits          Gauge32
 569            }
 570
 571 4.6.  AToMMIB
 572
 573    The "ATM Accounting Information MIB" document [ATM-ACT] describes a
 574    large set of accounting objects for ATM connections.  An
 575    administrator may select objects from this set using a selector of
 576    the form (subtree, list) where "subtree" specifies an object
 577    identifier from the AToMMIB.  For each subtree there is a table
 578    holding values for each ATM connection.  The required connections are
 579    indicated by setting bits in "list", which is an octet string.  For
 580    example, the set containing the number of received cells for the
 581    first eight ATM connections would be selected by
 582    (atmAcctngReceivedCells, 0xFF).
 583
 584    The Connection-Oriented Accounting MIB document [ATM-COLL] defines a
 585    MIB providing managed objects used for controlling the collection and
 586    storage of accounting information for connection-oriented networks
 587    such as ATM.  The accounting data is collected into files for later
 588    retrieval via a file transfer protocol.  Records within an accounting
 589    file are stored as BER strings [ASN1, BER].
 590
 591 4.6.1.  AToMMIB Attributes
 592
 593    Accounting data objects within the AToMMBIB are identified by the
 594    last integer in their object identifiers.
 595
 596    The ATM accounting data objects are:
 597
 598       1   atmAcctngConnectionType
 599       2   atmAcctngCastType
 600       3   atmAcctngIfName
 601       4   atmAcctngIfAlias
 602       5   atmAcctngVpi
 603       6   atmAcctngVci
 604       7   atmAcctngCallingParty
 605       8   atmAcctngCalledParty
 606       9   atmAcctngCallReference
 607      10   atmAcctngStartTime
 608      11   atmAcctngCollectionTime
 609      12   atmAcctngCollectMode
 610      13   atmAcctngReleaseCause
 611      14   atmAcctngServiceCategory
 612      15   atmAcctngTransmittedCells
 613      16   atmAcctngTransmittedClp0Cells
 614      17   atmAcctngReceivedCells
 615
 616
 617
 618 Brownlee & Blount            Informational                     [Page 11]
 619 \f
 620 RFC 2924        Accounting Attributes and Record Formats  September 2000
 621
 622
 623      18   atmAcctngReceivedClp0Cells
 624      19   atmAcctngTransmitTrafficDescriptorType
 625      20   atmAcctngTransmitTrafficDescriptorParam1
 626      21   atmAcctngTransmitTrafficDescriptorParam2
 627      22   atmAcctngTransmitTrafficDescriptorParam3
 628      23   atmAcctngTransmitTrafficDescriptorParam4
 629      24   atmAcctngTransmitTrafficDescriptorParam5
 630      25   atmAcctngReceiveTrafficDescriptorType
 631      26   atmAcctngReceiveTrafficDescriptorParam1
 632      27   atmAcctngReceiveTrafficDescriptorParam2
 633      28   atmAcctngReceiveTrafficDescriptorParam3
 634      29   atmAcctngReceiveTrafficDescriptorParam4
 635      30   atmAcctngReceiveTrafficDescriptorParam5
 636      31   atmAcctngCallingPartySubAddress
 637      32   atmAcctngCalledPartySubAddress
 638      33   atmAcctngRecordCrc16
 639
 640 4.7.  QoS: RSVP and DIFFSERV
 641
 642    As we move towards providing more than simple "best effort"
 643    connectivity, there has been a tremendous surge of interest in (and
 644    work on) protocols to provide managed Quality of Service for Internet
 645    sessions.  This is of particular interest for the provision of
 646    "Integrated Services", i.e. the transport of audio, video, real-time,
 647    and classical data traffic within a single network infrastructure.
 648
 649    Two approaches to this have emerged so far:
 650
 651    -  the Integrated Services architecture (intserv) [IIS-ARC], with its
 652       accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's
 653       Common Open Policy Service protocol, COPS [RAP-COPS]
 654
 655    -  the Differentiated Services architecture (diffserv) [DSRV-ARC]
 656
 657    RSVP is a signaling protocol that applications may use to request
 658    resources from the network.  The network responds by explicitly
 659    admitting or rejecting RSVP requests.  Certain applications that have
 660    quantifiable resource requirements express these requirements using
 661    intserv parameters [IIS-SPEC].
 662
 663    Diffserv networks classify packets into one of a small number of
 664    aggregated flows or "classes", based on the diffserv codepoint (DSCP)
 665    in the packet's IP header.  At each diffserv router, packets are
 666    subjected to a "per-hop behavior" (PHB), which is invoked by the
 667    DSCP.  Since RSVP is purely a requirements signalling protocol it can
 668    also be used to request connections from a diffserv network [RS-DS-
 669    OP].
 670
 671
 672
 673
 674 Brownlee & Blount            Informational                     [Page 12]
 675 \f
 676 RFC 2924        Accounting Attributes and Record Formats  September 2000
 677
 678
 679 4.7.1.  RSVP and DIFFSERV Attributes
 680
 681    A set of parameters for specifying a requested Quality of Service are
 682    given in [IIS-SPEC].  These have been turned into accounting
 683    attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP-
 684    MIB].
 685
 686    The RTFM QoS attributes are:
 687
 688         98      QoSService
 689         99      QoSStyle
 690        100      QoSRate
 691        101      QoSSlackTerm
 692        102      QoSTokenBucketRate
 693        103      QoSTokenBucketSize
 694        104      QoSPeakDataRate
 695        105      QoSMinPolicedUnit
 696        106      QoSMaxPolicedUnit
 697
 698    The RSVP MIB contains a large number of objects, arranged within the
 699    following sections:
 700
 701        General Objects
 702        Session Statistics Table
 703        Session Sender Table
 704        Reservation Requests Received Table
 705        Reservation Requests Forwarded Table
 706        RSVP Interface Attributes Table
 707        RSVP Neighbor Table
 708
 709    The Session tables contain information such as the numbers of senders
 710    and receivers for each session, while the Reservation Requests tables
 711    contain details of requests handled by the RSVP router.  There are
 712    too many objects to list here, but many of them could be used for
 713    accounting.  In particular, RSVP Requests contain the specification
 714    of the service parameters requested by a user; these, together with
 715    the actual usage data for the connection make up an accounting record
 716    for that usage.
 717
 718 5.  ITU-T Documents
 719
 720 5.1.  Q.825: Call Detail Recording
 721
 722    ITU-T Recommendation Q.825 specifies how CDRs (Call Detail Records)
 723    are produced and managed in Network Elements for POTS, ISDN and IN
 724    (Intelligent Networks).
 725
 726    Uses of Call Detail information for various purposes are discussed.
 727
 728
 729
 730 Brownlee & Blount            Informational                     [Page 13]
 731 \f
 732 RFC 2924        Accounting Attributes and Record Formats  September 2000
 733
 734
 735    Each call produces one or more records describing events that
 736    occurred during the life of a call.  Data may be produced in real
 737    time (single CDRs), near real-time (blocks of CDRs), or as batch
 738    files of CDRs.
 739
 740    The information model for Call Detail Recording is formally described
 741    in terms of an Entity-Relationship model, and an object model
 742    specified in terms of GDMO templates (Guidelines for the Definition
 743    of Managed Objects).  Note that this model includes the ways in which
 744    CDRs are transported from the (NE) Network Element where they are
 745    generated to the OS (Operations System) where they are used.
 746
 747 5.2.  Q.825 Attributes
 748
 749    The following attributes are defined.  The explanations given are
 750    very brief summaries only, see [Q-825] for the complete text.
 751
 752    1  accessDelivery
 753         Indicates that the call was delivered to the called subscriber
 754
 755    2  accountCodeInput
 756         Account code (for billing), supplied by subscriber.
 757
 758   78  additionalParticipantInfo
 759         (No details given)
 760
 761    5  b-PartyCategory
 762         Subscriber category for called subscriber.
 763
 764    4  bearerService
 765         Bearer capability information (only for ISDN calls).
 766
 767   13  cDRPurpose
 768         Reason for triggering this Call Data Record.
 769
 770   70  callDetailDataId
 771         Unique identifier for the CallDetailData object.
 772
 773   79  callDuration
 774         Duration of call
 775
 776    6  callIdentificationNumber
 777         Identification number for call; all records produced for this
 778         call have the same callIdenfificationNumber.
 779
 780   73  callStatus
 781         Identifies whether the call was answered or not.
 782
 783
 784
 785
 786 Brownlee & Blount            Informational                     [Page 14]
 787 \f
 788 RFC 2924        Accounting Attributes and Record Formats  September 2000
 789
 790
 791    9  calledPartyNumber
 792         Telephone number of the called subscriber (may be a
 793         "diverted-to" or "translated" number.
 794
 795    7  callingPartyCategory
 796         Calling subscriber category.
 797
 798    8  callingPartyNumber
 799         Telephone number of the calling party.
 800
 801   10  callingPartyNumberNotScreened
 802         An additional, user-provided (not screened) number to the
 803         calling party.
 804
 805   11  callingPartyType
 806         Calling subscriber type.
 807
 808   74  carrierId
 809         Carrier ID to which the call is sent.
 810
 811   12  cause
 812         Cause and location value for the termination of the call.
 813
 814   14  chargedDirectoryNumber
 815         Charged directory number (where the charged participant
 816         element can't indicate the number).
 817
 818   16  chargedParticipant
 819         Participant to be charged for the usage.
 820
 821   15  chargingInformation
 822         Charging information generated by a Network Element which is
 823         capable of charging.
 824
 825   17  configurationMask
 826         Time consumption, e.g. from B-answer to termination time,
 827         between partial call records, etc.
 828
 829   18  conversationTime
 830         Time consumption from B-answer to end of call.
 831
 832   19  creationTriggerList
 833         List of trigger values which will create Call Detail data
 834         objects.
 835
 836   75  dPC
 837         Destination point code (for analysis purposes).
 838
 839
 840
 841
 842 Brownlee & Blount            Informational                     [Page 15]
 843 \f
 844 RFC 2924        Accounting Attributes and Record Formats  September 2000
 845
 846
 847   20  dataValidity
 848         Indicates that the NE is having problems, contents of the
 849         generated Call Detail record is not reliable.
 850
 851   23  durationTimeACM
 852         Time consumption from seizure until received ACM.
 853
 854   21  durationTimeB-Answer
 855         Time consumption from seizure until B-answer.
 856
 857   22  durationTimeNoB-Answer
 858         Time from seizure to termination when no B-answer was
 859         received.
 860
 861   25  exchangeInfo
 862         Identity of exchange where Call Detail record was generated.
 863
 864   26  fallbackBearerService
 865         Fallback bearer capability information for a call.
 866
 867   27  glare
 868         Indicates if a glare condition was encountered.
 869
 870   31  iNServiceInformationList
 871         Contains information about the use of IN (Intelligent Network)
 872         services.
 873
 874   32  iNSpecificInformation
 875         Contains information about the use of one IN service.
 876
 877   33  iSUPPreferred
 878         Indicate whether an ISUP preference was requested.
 879
 880   28  immediateNotificationForUsageMetering
 881         Indicates that the Call Detail records requires
 882         immediate data transfer to the Operations System.
 883
 884   34  maxBlockSize
 885         Maximum number of Call Detail records in a block.
 886
 887   35  maxTimeInterval
 888         Maximum latency allowable for near-real-time Call Detail
 889         data delivery.
 890
 891   36  networkManagementControls
 892         Indicates which Traffic Management Control has affected
 893         the call.
 894
 895
 896
 897
 898 Brownlee & Blount            Informational                     [Page 16]
 899 \f
 900 RFC 2924        Accounting Attributes and Record Formats  September 2000
 901
 902
 903   37  networkProviderId
 904         Indicates the Network Provider for whom the CDR is generated.
 905
 906   76  oPC
 907         Originating point code for a failed call (for analysis
 908         purposes).
 909
 910   38  operatorSpecific1AdditionalNumber
 911   40  operatorSpecific2AdditionalNumber
 912   42  operatorSpecific3AdditionalNumber
 913         Operator-defined additional participant information.
 914
 915   39  operatorSpecific1Number
 916   41  operatorSpecific2Number
 917   43  operatorSpecific3Number
 918         Operator-defined participant information.
 919
 920   44  originalCalledNumber
 921         Telephone number of the original called party.
 922
 923   45  partialGeneration
 924         Included if the CDR (Call Detail record) output is partial.
 925         Such CDRs have a field indicating their partial record number.
 926
 927   77  participantInfo
 928         (No details given).
 929
 930   46  percentageToBeBilled
 931         Percentage to be billed when normal billing rules are
 932         not to be followed.
 933
 934   47  periodicTrigger
 935         Defines the intervals at which the CDR file should be created.
 936
 937   48  personalUserId
 938         Internationally unique personal User Identity (for UPT calls).
 939
 940   49  physicalLineCode
 941         Identifies the call subscriber's physical line.
 942
 943   50  progress
 944         Describes an event which occurred during the life of a call.
 945
 946   51  queueInfo
 947         Used to record usage of queueing resources with IN calls.
 948
 949
 950
 951
 952
 953
 954 Brownlee & Blount            Informational                     [Page 17]
 955 \f
 956 RFC 2924        Accounting Attributes and Record Formats  September 2000
 957
 958
 959   52  receivedDigits
 960         The digits dialed by the subscriber.  (Normally only included
 961         for customer care purposes).
 962
 963   53  recordExtensions
 964         Information elements added by network operators and/or
 965         manufacturers in addition to the standard ones above.
 966
 967 6.  Other Documents
 968
 969 6.1.  TIPHON: ETSI TS 101 321
 970
 971    TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which
 972    handles accounting and authorization requests and responses.
 973
 974    The following are elements selected from TIPHON's DTD that are used
 975    for accounting.
 976
 977    <!ELEMENT Currency (#PCDATA)> <!ELEMENT Amount (#PCDATA)>
 978        Identifies a numeric value.  Expressed using the period (.) as a
 979        decimal separator with no punctuation as the thousands separator.
 980
 981    <!ELEMENT CallId (#PCDATA)>
 982        Contains a call's H.323 CallID value, and is thus used to
 983        uniquely identify individual calls.
 984
 985    <!ELEMENT Currency (#PCDATA)>
 986        Defines the financial currency in use for the parent element.
 987
 988    <!ELEMENT DestinationInfo type ( e164 | h323 | url | email |
 989                                     transport | international |
 990                                     national | network | subscriber |
 991                                     abbreviated | e164prefix )
 992        Gives the primary identification of the destination for a call.
 993
 994    <!ELEMENT Increment (#PCDATA)>
 995        Indicates the number of units being accounted.
 996
 997    <!ELEMENT Service EMPTY>
 998        Indicates a type of service being priced, authorized, or
 999        reported.  An empty Service element indicates basic Internet
1000        telephony service, which is the only service type defined by
1001        V1.4.2 of the specification.  The specification notes that "Later
1002        revisions of this standard are expected to specify more enhanced
1003        service definitions to represent quality of service,
1004        availability, payment methods, etc."
1005
1006
1007
1008
1009
1010 Brownlee & Blount            Informational                     [Page 18]
1011 \f
1012 RFC 2924        Accounting Attributes and Record Formats  September 2000
1013
1014
1015    <!ELEMENT DestinationInfo type ( e164 | h323 | url | email |
1016                                     transport | international |
1017                                     national | network | subscriber |
1018                                     abbreviated | e164prefix)
1019        Gives the primary identification of the source of a call.
1020
1021
1022    <!ELEMENT Timestamp (#PCDATA)>
1023        A restricted form of [ISO-DATE] that indicates the time at which
1024        the component was generated.
1025
1026    <!ELEMENT TransactionId (#PCDATA)>
1027        Contains an integer, decimal valued identifier assigned to a
1028        specific authorized transaction.
1029
1030    <!ELEMENT Unit (#PCDATA)>
1031        Indicates the units by which pricing is measured or usage
1032        recorded.  It shall contain one of the following values:
1033            s      seconds
1034            p      packets (datagrams)
1035            byte   bytes
1036
1037    <!Element UsageDetail ( Service, Amount, Increment, Unit ) >
1038        Collects information describing the usage of a service.
1039
1040 6.2.  MSIX
1041
1042    MSIX [MSIX-SPEC] is an XML-based protocol transported by HTTP that is
1043    used to make accounting service definitions and transmit service
1044    usage information.  As its service definitions are parameterized and
1045    dynamic, it makes no definition of services or attributes itself, but
1046    allows implementors to make their own.  It specifies only the base
1047    data types that attributes may take: STRING, UNISTRING, INT32, FLOAT,
1048    DOUBLE, BOOLEAN, TIMESTAMP.
1049
1050 7.  Accounting File and Record Formats
1051
1052 7.1.  ASN.1 Records
1053
1054 7.1.1.  RTFM and AToMMIB
1055
1056    RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists
1057    of attributes into accounting records.  RTFM uses SNMP to retrieve
1058    such records as BER strings, thus avoiding having to have an object
1059    identifier for every object.
1060
1061
1062
1063
1064
1065
1066 Brownlee & Blount            Informational                     [Page 19]
1067 \f
1068 RFC 2924        Accounting Attributes and Record Formats  September 2000
1069
1070
1071    AToMMIB carries this a stage further by defining an accounting file
1072    format in ASN.1 and making it available for retrieval by a file
1073    transfer protocol, thereby providing a more efficient alternative to
1074    simply retrieving the records using SNMP.
1075
1076 7.1.2.  Q.825
1077
1078    A Q.825 Call Record is an ASN.1 SET containing a specified group of
1079    the Q.825 attributes.  Call records would presumably be encoded as
1080    BER strings before being collected for later processing.
1081
1082 7.2.  Binary Records
1083
1084 7.2.1.  RADIUS
1085
1086    Radius packets carry a sequence of attributes and their values, as
1087    (Type, Length, Value) triples.  The format of the value field is one
1088    of four data types.
1089
1090       string   0-253 octets
1091
1092       address  32 bit value, most significant octet first.
1093
1094       integer  32 bit value, most significant octet first.
1095
1096       time     32 bit value, most significant octet first -- seconds
1097                since 00:00:00 GMT, January 1, 1970.  The standard
1098                Attributes do not use this data type but it is presented
1099                here for possible use within Vendor-Specific attributes.
1100
1101 7.2.2.  DIAMETER
1102
1103    Each DIAMETER message consists of multiple AVP's that are 32-bit
1104    aligned, with the following format:
1105
1106       0                   1                   2                   3
1107       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1108       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1109       |                           AVP Code                            |
1110       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1111       |          AVP Length           |     Reserved        |P|T|V|R|M|
1112       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1113       |                        Vendor ID (opt)                        |
1114       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1115       |                           Tag (opt)                           |
1116       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1117       |    Data ...
1118       +-+-+-+-+-+-+-+-+
1119
1120
1121
1122 Brownlee & Blount            Informational                     [Page 20]
1123 \f
1124 RFC 2924        Accounting Attributes and Record Formats  September 2000
1125
1126
1127       Code
1128          The AVP Code identifies the attribute uniquely.  If the Vendor-
1129          Specific bit is set, the AVP Code is allocated from the
1130          vendor's private address space.
1131
1132          The first 256 AVP numbers are reserved for backward
1133          compatibility with RADIUS and are to be interpreted as per
1134          RADIUS [RAD-PROT].  AVP numbers 256 and above are used for
1135          DIAMETER, which are allocated by IANA.
1136
1137       AVP Length
1138          A 16-bit field contains the total object length in bytes.
1139          Must always be a multiple of 4, and at least 8.
1140
1141       AVP Flags
1142          P                      Protected bit
1143          T                      Tag bit
1144          V                      Vendor-ID bit
1145          R                      Reserved (MUST be set to 0)
1146          M                      Mandatory bit
1147
1148 7.3.  Text Records
1149
1150 7.3.1.  ROAMOPS
1151
1152    ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a
1153    general, text-based format for accounting data files, described in a
1154    straightforward BNF grammar.  Its file header contains a field
1155    indicating the default protocol from which accounting attributes are
1156    drawn.  If an attribute from another protocol is to be used, it is
1157    preceded by its protocol name, for example rtfm//27 would be RTFM's
1158    "forward bytes" attribute.  Comments in an ADIF file begin with a
1159    cross-hatch.
1160
1161    Example: An ADIF file encoding RADIUS accounting data
1162
1163         version: 1
1164         device: server3
1165         description: Accounting Server 3
1166         date: 02 Mar 1999 12:19:01 -0500
1167         defaultProtocol: radius
1168
1169         rdate: 02 Mar 1999 12:20:17 -0500
1170         #NAS-IP-Address
1171         4: 204.45.34.12
1172         #NAS-Port
1173         5: 12
1174         #NAS-Port-Type
1175
1176
1177
1178 Brownlee & Blount            Informational                     [Page 21]
1179 \f
1180 RFC 2924        Accounting Attributes and Record Formats  September 2000
1181
1182
1183         61: 2
1184         #User-Name
1185         1: fred@bigco.com
1186         #Acct-Status-Type
1187         40: 2
1188         #Acct-Delay-Time
1189         41: 14
1190         #Acct-Input-Octets
1191         42: 234732
1192         #Acct-Output-Octets
1193         43: 15439
1194         #Acct-Session-Id
1195         44: 185
1196         #Acct-Authentic
1197         45: 1
1198         #Acct-Session-Time
1199         46: 1238
1200         #Acct-Input-Packets
1201         47: 153
1202         #Acct-Output-Packets
1203         48: 148
1204         #Acct-Terminate-Cause
1205         49: 11
1206         #Acct-Multi-Session-Id
1207         50: 73
1208         #Acct-Link-Count
1209         51: 2
1210
1211 8.  AAA Requirements
1212
1213 8.1.  A Well-Defined Set of Attributes
1214
1215    AAA needs a well-defined set of attributes whose values are to be
1216    carried in records to or from accounting servers.
1217
1218    Most of the existing sets of documents described above include a set
1219    of attributes, identified by small integers.  It is likely that these
1220    sets overlap, i.e. that some of them have attributes which represent
1221    the same quantity using different names in different sets.  This
1222    suggests it might be possible to produce a single combined set of
1223    "universal" accounting attributes, but such a "universal" set does
1224    not seem worthwhile.
1225
1226    The ADIF approach of specifying a default protocol (from which
1227    attributes are assumed to come) and identifying any exceptions seems
1228    much more practical.  We therefore propose that AAA should use the
1229
1230
1231
1232
1233
1234 Brownlee & Blount            Informational                     [Page 22]
1235 \f
1236 RFC 2924        Accounting Attributes and Record Formats  September 2000
1237
1238
1239    ADIF convention (or something like it) to identify attributes,
1240    together with all the sets of attributes covered by the [ASG-NBR]
1241    document.
1242
1243 8.2.  A Simple Interchange Format
1244
1245    AAA needs a simple interchange file format, to be used for accounting
1246    data.  Several schemes for packaging and transporting such data have
1247    been described above.
1248
1249    The SNMP-based ones fit well within the context of an SNMP-based
1250    network management system.  RTFM and AToMMIB provide ways to reduce
1251    the SNMP overhead for collecting data, and AToMMIB defines a complete
1252    file format.  Both provide good ways to collect accounting data.
1253
1254    As an interchange format, however, ASN.1-based schemes suffer from
1255    being rather complex binary structures.  This means that one requires
1256    suitable tools to work with them, as compared to plain-text files
1257    where one can use existing text-based utilities.
1258
1259    The binary schemes such as RADIUS and DIAMETER have simpler
1260    structures, but they too need purpose-built tools.  For general use
1261    they would need to be extended to allow them to use attributes from
1262    other protocols.
1263
1264    From the point of view of being easy for humans to understand, ADIF
1265    seems very promising.  Of course any processing program would need a
1266    suitable ADIF input parser, but using plain-text files makes them
1267    much easier to understand.
1268
1269    TIPHON's record format is specified by an XML DTD.  While XML
1270    representations have the advantages of being well-known, they are
1271    limited by XML's inability to specify type or other validity checking
1272    for information within the tags.  This situation will likely be
1273    improved by the XML Schema [XML-SCHM] efforts that are underway, but
1274    a stable reference is not yet available.
1275
1276 9.  Issues
1277
1278    It is generally agreed that there is a need for a standard record
1279    format and transport protocol for communication between Service
1280    Elements and Accounting Servers.
1281
1282    There is less agreement on the following issues:
1283
1284       o  Separate or integral record format and transport protocol
1285       o  Standard set of base data types
1286       o  Service definitions: part of the protocol or separately defined
1287
1288
1289
1290 Brownlee & Blount            Informational                     [Page 23]
1291 \f
1292 RFC 2924        Accounting Attributes and Record Formats  September 2000
1293
1294
1295       o  Service definition namespace management
1296
1297    The following sections address these issues.
1298
1299 9.1.  Record Format vs. Protocol
1300
1301    All known Internet-centric billing protocols to date have an integral
1302    record format.  That is, the collection of Properties that describe a
1303    Usage Event are specified as an integral part of the protocol,
1304    typically as a part of a "submit" message that is used to transmit a
1305    Usage Event from a Service Entity to an Accounting Server.
1306
1307    It may be advantageous to define a record format that is independent
1308    of the transport protocol.  Such a record format should support both
1309    representation of individual records and records in bulk, as Usage
1310    Events are often aggregated and transmitted in bulk.
1311
1312    A separate record format is useful for record archiving and temporary
1313    file storage.  Multiple transport protocols may be defined without
1314    affecting the record format.  The task of auditing is made easier if
1315    a standard file format is defined.  If a canonical format is used,
1316    bulk records may be hashed with MD5 [MD5] or a similar function, for
1317    reliability and security purposes.
1318
1319                                   +------------+
1320                                   |  transport |
1321                                   |   header   |
1322             +------------+        +------------+
1323             |            |        |            |
1324             |   Usage    |        |   Usage    |
1325             |  Event(s)  |        |  Event(s)  |
1326             |            |        |            |
1327             |            |        |            |
1328             +------------+        +------------+
1329                                   |  trailer   |
1330                                   +------------+
1331
1332             record format       transport protocol
1333
1334    If the protocol is written such that it can transmit Usage Events in
1335    the record format, no record rewriting for transport is required.
1336
1337 9.2.  Tagged, Typed Data
1338
1339    Record formats and protocols use a combination of data locality and
1340    explicit tagging to identify data elements.  Mail [RFC822], for
1341    instance, defines a header block composed of several Attribute-Value
1342    Pairs, followed by a message body.  Each header field is explicitly
1343
1344
1345
1346 Brownlee & Blount            Informational                     [Page 24]
1347 \f
1348 RFC 2924        Accounting Attributes and Record Formats  September 2000
1349
1350
1351    tagged, but the order of the AVPs is undefined.  The message body is
1352    not tagged (except with an additional preceding blank line), and is
1353    found through its position in the message, which must be after all
1354    header fields.
1355
1356    Some record formats make no use of tags--data elements are identified
1357    only by their position within a record structure.  While this
1358    practice provides for the least amount of record space overhead, it
1359    is difficult to later modify the record format by adding or removing
1360    elements, as all record readers will have to be altered to handle the
1361    change.  Tagged data allows old readers to detect unexpected tags and
1362    to detect if required data are missing.  If the overhead of carrying
1363    explicit tags can be borne, it is advantageous to use explicitly
1364    tagged data elements where possible.
1365
1366    An AVP approach has proven useful in accounting.  RADIUS [RADIUS]
1367    uses numeric data type identifiers.  ETSI's TIPHON [TIPHON] uses XML
1368    markup.
1369
1370    For an AAA accounting record format, the authors suggest that each
1371    Property be named by a textual or numeric identifier and carry a
1372    value and a data type indicator, which governs interpretation of the
1373    value.  It may also be useful for each Property to carry a units of
1374    measure identifier.  The TIPHON specification takes this approach.
1375    TS 101 321 also carries an Increment field, which denominates the
1376    Property's Unit of Measure field.  Whether this additional
1377    convenience is necessary is a matter for discussion.
1378
1379    It is not strictly necessary for each data record to carry data type,
1380    units of measure, or increments identifiers.  If this information is
1381    recorded in a record schema document that is referenced by each data
1382    record, each record may be validated against the schema without the
1383    overhead of carrying type information.
1384
1385 9.2.1.  Standard Type Definitions
1386
1387    It is useful to define a standard set of primitive data types to be
1388    used by the record format and protocol.  Looking at the prior art,
1389    DIAMETER supports Data (arbitrary octets), String (UTF-8), Address
1390    (32 or 128 bit), Integer32, Integer64, Time (32 bits, seconds since
1391    1970), and Complex.  MSIX [MSIX-SPEC] supports String, Unistring,
1392    Int32, Float, Double, Boolean, and Timestamp.  SMIv2 [SMI-V2] offers
1393    ASN.1 types INTEGER, OCTET STRING, and OBJECT IDENTIFIER, and the
1394    application-defined types Integer32, IpAddress, Counter32, Gauge32,
1395    Unsigned32, TimeTicks, Opaque, and Counter64.
1396
1397
1398
1399
1400
1401
1402 Brownlee & Blount            Informational                     [Page 25]
1403 \f
1404 RFC 2924        Accounting Attributes and Record Formats  September 2000
1405
1406
1407    An appropriate set would likely include booleans, 32 and 64 bit
1408    signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and
1409    UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps.  Fixed-
1410    precision numbers capable of representing currency amounts (with
1411    precision specified on both sides of the decimal point) have proven
1412    useful in accounting record formats, as they are immune to the
1413    precision problems that are encountered when one attempts to
1414    represent fixed-point amounts with floating point numbers.
1415
1416    It may be worthwhile to consider the datatypes that are being
1417    specified by the W3C's "XML Schema Part 2: Datatypes" [XML-DATA]
1418    document.  That document specifies a rich set of base types, along
1419    with a mechanism to specify derivations that further constrain the
1420    base types.
1421
1422 9.3.  Transaction Identifiers
1423
1424    Each Usage Event requires its own unique identifier.
1425
1426    It is expedient to allow Service Elements to create their own unique
1427    identifiers.  In this manner, Usage Events can be created and
1428    archived without the involvement of an Accounting Server or other
1429    central authority.
1430
1431    A number of methods for creating unique identifiers are well known.
1432    One popular identifier is an amalgamation of a monotonically
1433    increasing sequence number, a large random value, a network element
1434    identifier, and a timestamp.  Another possible source of entropy is a
1435    hash value of all or part of the record itself.
1436
1437    RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give
1438    guidance on the creation of good unique identifiers.
1439
1440 9.4.  Service Definitions
1441
1442    A critical differentiator in accounting record formats and protocols
1443    is their capability to account for arbitrary service usage.  To date,
1444    no accounting record format or protocol that can handle arbitrary
1445    service definitions has achieved broad acceptance on the Internet.
1446
1447    This section analyzes the issues in service definition and makes a
1448    case for a record format and protocol with the capability to carry
1449    Usage Events for rich, independently-defined services.
1450
1451
1452
1453
1454
1455
1456
1457
1458 Brownlee & Blount            Informational                     [Page 26]
1459 \f
1460 RFC 2924        Accounting Attributes and Record Formats  September 2000
1461
1462
1463 9.4.1.  Service Independence
1464
1465    It is informative to survey a number of popular Internet protocols
1466    and document encodings and examine their capacities for extension.
1467    These protocols can be categorized into two broad categories--"fully
1468    specified" protocols that have little provision for extension and
1469    "framework" protocols that are incomplete, but provide a basis for
1470    future extension when coupled with application documents.
1471
1472    Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP],
1473    RADIUS Accounting [RAD-ACT], and HTML [HTML].
1474
1475    Aside from leaving some field values "reserved for future use", all
1476    of Network Time Protocol's fields are fixed-width and completely
1477    defined.  This is appropriate for a simple protocol that solves a
1478    simple problem.
1479
1480    Network News Transfer Protocol [NEWS-PROT] specifies that further
1481    commands may be added, and requests that non-standard implementations
1482    use the "X-" experimental prefix so as to not conflict with future
1483    additions.  The content of news is 7-bit data, with the high-order
1484    bit cleared to 0.  Nothing further about the content is defined.
1485    There is no in-protocol facility for automating decoding of content
1486    type.
1487
1488    We pay particular attention to RADIUS Accounting [RAD-ACT].  Perhaps
1489    the second most frequently heard complaint (after security
1490    shortcomings) about RADIUS Accounting is its preassigned and fixed
1491    set of "Types".  These are coded as a range of octets from 40 to 51
1492    and are as follows:
1493
1494          40      Acct-Status-Type
1495          41      Acct-Delay-Time
1496          42      Acct-Input-Octets
1497          43      Acct-Output-Octets
1498          44      Acct-Session-Id
1499          45      Acct-Authentic
1500          46      Acct-Session-Time
1501          47      Acct-Input-Packets
1502          48      Acct-Output-Packets
1503          49      Acct-Terminate-Cause
1504          50      Acct-Multi-Session-Id
1505          51      Acct-Link-Count
1506
1507    These identifiers were designed to account for packet-based network
1508    access service.  They are ill-suited for describing other services.
1509    While extension documents have specified additional types, the base
1510
1511
1512
1513
1514 Brownlee & Blount            Informational                     [Page 27]
1515 \f
1516 RFC 2924        Accounting Attributes and Record Formats  September 2000
1517
1518
1519    protocol limits the type identifier to a single octet, limiting the
1520    total number of types to 256.
1521
1522    HTML/2.0 [HTML] is mostly a fully-specified protocol, but with W3C's
1523    HTML/4.0, HTML is becoming more of a framework protocol.  HTML/2.0
1524    specified a fixed set of markups, with no provision for addition
1525    (without protocol revision).
1526
1527    Examples of "framework" protocols and document encodings are HTTP,
1528    XML, and SNMP.
1529
1530    HTTP/1.1 [HTTP] is somewhat similar to NNTP in that it is designed to
1531    transport arbitrary content.  It is different in that it supports
1532    description of that content through its Content-Type, Content-
1533    Encoding, Accept-Encoding, and Transfer-Encoding header fields.  New
1534    types of content can be designated and carried by HTTP/1.1 without
1535    modification to the HTTP protocol.
1536
1537    XML [XML] is a preeminent general-purpose framework encoding.  DTD
1538    publishing is left to users.  There is no standard registry of DTDs.
1539
1540    SNMP presents a successful example of a framework protocol.  SNMP's
1541    authors envisioned SNMP as a general management protocol, and allow
1542    extension through the use of private MIBs.  SNMP's ASN.1 MIBs are
1543    defined, published, and standardized without the necessity to modify
1544    the SNMP standard itself.  From "An Overview of SNMP" [SNMP-OVER]:
1545
1546       It can easily be argued that SNMP has become prominent mainly from
1547       its ability to augment the standard set of MIB objects with new
1548       values specific for certain applications and devices.  Hence, new
1549       functionality can continuously be added to SNMP, since a standard
1550       method has been defined to incorporate that functionality into
1551       SNMP devices and network managers.
1552
1553    Most accounting protocols are fully-specified, with either a
1554    completely defined service or set of services (RADIUS Accounting) or
1555    with one or more services defined and provision for "extension"
1556    services to be added to the protocol later (TIPHON).  While the
1557    latter is preferable, it may be preferable to take a more SNMP-like
1558    approach, where the accounting record format and protocol provide
1559    only a framework for service definition, and leave the task of
1560    service definition (and standardization) to separate efforts.  In
1561    this manner, the accounting protocol itself would not have to be
1562    modified to handle new services.
1563
1564
1565
1566
1567
1568
1569
1570 Brownlee & Blount            Informational                     [Page 28]
1571 \f
1572 RFC 2924        Accounting Attributes and Record Formats  September 2000
1573
1574
1575 9.4.2.  Versioned Service Definitions
1576
1577    Versioning is a naming and compatibility issue.  Version identifiers
1578    are useful in service definition because they enable service
1579    definitions to be upgraded without a possibly awkward name change.
1580    They also enable possible compatibility between different versions of
1581    the same service.
1582
1583    An example could be the service definition of a phone call.  Version
1584    1 might define Properties for the start time, duration, and called
1585    and calling party numbers.  Later, version 2 is defined, which
1586    augments the former service definition with a byte count.  An
1587    Accounting Server, aware only of Version 1, may accept Version 2
1588    records, discarding the additional information (forward
1589    compatibility).  Alternately, if an Accounting Server is made aware
1590    of version 2, it could optionally still accept version 1 records from
1591    Service Elements, provided the Accounting Sever does not require the
1592    additional information to properly account for service usage
1593    (backward compatibility).
1594
1595 9.4.3.  Relationships Among Usage Events
1596
1597    Accounting record formats and protocols to date do not sufficiently
1598    addressed "compound" service description.
1599
1600    A compound service is a service that is described as a composition of
1601    other services.  A conference call, for example, may be described as
1602    a number of point-to-point calls to a conference bridge.  It is
1603    important to account for the individual calls, rather than just
1604    summing up an aggregate, both for auditing purposes and to enable
1605    differential rating.  If these calls are to be reported to the
1606    Accounting Server individually, the Usage Events require a shared
1607    identifier that can be used by the Accounting Server and other back-
1608    end systems to group the records together.
1609
1610    In order for a Service Element to report compound events over time as
1611    a succession of individual Usage Events, the accounting protocol
1612    requires a facility to communicate that the compound event has
1613    started and stopped.  The "start" message can be implicit--the
1614    transmission of the first Usage Event will suffice.  An additional
1615    semaphore is required to tell the Accounting Server that the compound
1616    service is complete and may be further processed.  This is necessary
1617    to prevent the Accounting Server from prematurely processing compound
1618    events that overlap the end of a billing period.
1619
1620
1621
1622
1623
1624
1625
1626 Brownlee & Blount            Informational                     [Page 29]
1627 \f
1628 RFC 2924        Accounting Attributes and Record Formats  September 2000
1629
1630
1631    RADIUS Accounting has some provision for this sort of accounting with
1632    its "Acct-Multi-Session-Id" field.  Unfortunately, RADIUS
1633    Accounting's other shortcomings preclude it from being used in
1634    general purpose service usage description.
1635
1636 9.4.4.  Service Namespace Management
1637
1638    "Framework" protocols, as previously mentioned, do not define
1639    complete schema for their payload.  For interoperability to be
1640    achieved, it must be possible for:
1641
1642       (1) content definers to specify definitions without conflicting
1643           with the names of other definitions
1644
1645       (2) protocol users to find and use content definitions
1646
1647    Condition (1) can be readily managed through IANA assignment or by
1648    using an existing namespace differentiator (for example, DNS).
1649
1650    Condition (2) is harder, and places considerable burden on the
1651    implementors.  Their clients and servers must be able, statically or
1652    dynamically, to find and validate definitions, and manage versioning
1653    issues.
1654
1655    As previously mentioned, the XML specification provides no facility
1656    for DTD discovery or namespace management.  XML specifies only a
1657    document format, and as such does not need to specify support for
1658    more "protocol" oriented problems.
1659
1660    For an accounting record format and protocol, an approach closer to
1661    SNMP's is useful.  SNMP uses an ISO-managed dotted-decimal namespace.
1662    An IANA-managed registry of service types is a possibility.  Another
1663    possibility, used by MSIX [MSIX-SPEC], is for Service Element
1664    creators to identify their services by concatenation of a new service
1665    name with existing unique identifier, such as a domain name.
1666
1667    A standard record format for service definitions would make it
1668    possible for Service Element creators to directly supply accounting
1669    system managers with the required definitions, via the network or
1670    other means.
1671
1672 10.  Encodings
1673
1674    It may be useful to define more than one record encoding.
1675
1676    A "verbose" XML encoding is easily implemented and records can be
1677    syntactically verified with existing tools.  "Human-readable"
1678    protocols tend to have an edge on "bitfield" protocols where ease of
1679
1680
1681
1682 Brownlee & Blount            Informational                     [Page 30]
1683 \f
1684 RFC 2924        Accounting Attributes and Record Formats  September 2000
1685
1686
1687    implementation is paramount and the application can tolerate any
1688    additional processing required to generate, parse, and transport the
1689    records.
1690
1691    A alternative "compressed" encoding that makes minimal use of storage
1692    and processing may be useful in many contexts.
1693
1694    There are disadvantages to supporting multiple encodings.
1695    Optionally-supported multiple encodings mandate the requirement for
1696    capabilities exchange between Service Element and Accounting Server.
1697    Also, implementations can tend to "drift apart", with one encoding
1698    better-supported than another.  Unless all encodings are mandatory,
1699    implementors may find they are unable to interoperate because they
1700    picked the wrong encoding.
1701
1702 11.  Security Considerations
1703
1704    This document summarises many existing IETF and ITU documents; please
1705    refer to the original documents for security considerations for their
1706    particular protocols.
1707
1708    It must be possible for the accounting protocol to be carried by a
1709    secure transport.  A canonical record format is useful so that
1710    regeneration of secure record hashes is possible.
1711
1712    When dealing with accounting data files, one must take care that
1713    their integrity and privacy are preserved.  This document, however,
1714    is only concerned with the format of such files.
1715
1716 12.  References
1717
1718    [ACC-BKG]   Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
1719                Background", RFC 1272, November 1991.
1720
1721    [ASG-NBR]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
1722                RFC 1700, October 1994.
1723
1724    [ASN1]      Information processing systems - Open Systems
1725                Interconnection - Specification of Abstract Syntax
1726                Notation One (ASN.1), International Organization for
1727                Standardization, International Standard 8824, December
1728                1987.
1729
1730    [ATM-ACT]   McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad,
1731                "Accounting Information for ATM Networks", RFC 2512,
1732                February 1999.
1733
1734
1735
1736
1737
1738 Brownlee & Blount            Informational                     [Page 31]
1739 \f
1740 RFC 2924        Accounting Attributes and Record Formats  September 2000
1741
1742
1743    [ATM-COLL]  McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "
1744                Managed Objects for Controlling the Collection and
1745                Storage of Accounting Information for Connection-Oriented
1746                Networks", RFC 2513, February 1999.
1747
1748    [BER]       Information processing systems - Open Systems
1749                Interconnection - Specification of Basic Encoding Rules
1750                for Abstract Notation One (ASN.1), International
1751                Organization for Standardization, International Standard
1752                8825, December 1987.
1753
1754    [DIAM-ACT]  Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G.,
1755                "DIAMETER Accounting Extension", Work in Progress.
1756
1757    [DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User
1758                Authentication Extensions", Work in Progress.
1759
1760    [DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER Framework
1761                Document", Work in Progress.
1762
1763    [DSRV-ARC]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
1764                and W. Weiss, "An Architecture for Differentiated
1765                Services", RFC 2475, December 1998.
1766
1767    [HTML]      Berners-Lee, T. and D. Connolly, "Hypertext Markup
1768                Language - 2.0", RFC 1866, November 1995.
1769
1770    [HTTP]      Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T.
1771                Berners-Lee, "Hypertext Transfer Protocol--HTTP/1.1", RFC
1772                2068, January 1997.
1773
1774    [ICAL-CORE] Dawson, F. and D. Stenerson, "Internet Calendaring and
1775                Scheduling Core Object Specification", RFC 2445, November
1776                1998.
1777
1778    [IIS-ARC]   Braden, R., Clark, D. and S. Shenker, "Integrated
1779                Services in the Internet Architecture: an Overview", RFC
1780                1633, June 1994.
1781
1782    [IIS-SPEC]  Shenker, S., Partridge, C. and R. Guerin, "Specification
1783                of Guaranteed Quality of Service", RFC 2212, September
1784                1997.
1785
1786    [ISDN-MIB]  Roeck, G., "ISDN Management Information Base using
1787                SMIv2", RFC 2127, March 1997.
1788
1789
1790
1791
1792
1793
1794 Brownlee & Blount            Informational                     [Page 32]
1795 \f
1796 RFC 2924        Accounting Attributes and Record Formats  September 2000
1797
1798
1799    [ISO-DATE]  "Data elements and interchange formats -- Information
1800                interchange -- Representation of dates and times", ISO
1801                8601:1988.
1802
1803    [MAIL]      Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
1804                TEXT MESSAGES", STD 11, RFC 822, August 1982.
1805
1806    [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1807                April 1992.
1808
1809    [MSIX-SPEC] Blount, A. and D. Young, "Metered Service Information
1810                Exchange 1.2", Work in Progress.
1811
1812    [NEWS-MSGS] Horton, M. and R. Adams, "Standard for Interchange of
1813                USENET Messages", RFC 1036, December 1987.
1814
1815    [NEWS-PROT] Kantor, B. and P. Lapsley, "Network News Transfer
1816                Protocol", RFC 977, February 1986.
1817
1818    [NTP]       Mills, D., "Network Time Protocol (NTP)", RFC 958,
1819                September 1985.
1820
1821    [Q-825]     "Specification of TMN applications at the Q3 interface:
1822                Call detail recording", ITU-T Recommendation Q.825, 1998.
1823
1824    [RAD-ACT]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1825
1826    [RAD-EXT]   Rigney, C., Willats, W. and Calhoun, P., "RADIUS
1827                Extensions", RFC 2869, June 2000.
1828
1829    [RAD-PROT]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1830                "Remote Authentication Dial In User Service (RADIUS)",
1831                RFC 2865, June 2000.
1832
1833    [RAD-TACC]  Zorn, G., Mitton, D. and A. Aboba, "RADIUS Accounting
1834                Modifications for Tunnel Protocol Support", RFC 2867,
1835                June 2000.
1836
1837    [RAP-COPS]  Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
1838                and A. Sastry, "The COPS (Common Open Policy Service)
1839                Protocol", RFC 2748, January 2000.
1840
1841    [ROAM-ADIF] Aboba, B. and D. Lidyard, "The Accounting Data
1842                Interchange Format (ADIF)", Work in Progress.
1843
1844    [ROAM-IMPL] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang,
1845                "Review of Roaming Implementations", RFC 2194, September
1846                1997.
1847
1848
1849
1850 Brownlee & Blount            Informational                     [Page 33]
1851 \f
1852 RFC 2924        Accounting Attributes and Record Formats  September 2000
1853
1854
1855    [RS-DS-OP]  Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
1856                Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
1857                Felstaine, "A Framework For Integrated Services Operation
1858                Over Diffserv Networks", Work in Progress.
1859
1860    [RSVP-ARC]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
1861                Jamin, "Resource Reservation Protocol (RSVP) Version 1
1862                Functional Specification", RFC 2205, September 1997.
1863
1864    [RSVP-MIB]  Baker, F., Krawczyk, J. and A. Sastry, "RSVP Management
1865                Information Base using SMIv2", RFC 2206, September 1997.
1866
1867    [RTFM-ARC]  Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
1868                Measurement: Architecture", RFC 2722, October 1999.
1869
1870    [RTFM-MIB]  Brownlee, N., "Traffic Flow Measurement: Meter MIB",
1871                Measurement: Architecture", RFC 2720, October 1999.
1872
1873    [RTFM-NEWA] Handelman, S., Brownlee, N., Ruth, G. and S. Stibler,
1874                "New Attributes for Traffic Flow Measurement", RFC 2724,
1875                October 1999.
1876
1877    [SIP-PROT]  Handley, M., Schulzrinne, H., Schooler, E. and J.
1878                Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
1879                March 1999.
1880
1881    [SMI-V2]    McCloghrie, K., Perkins, D. and J. Schoenwaelder,
1882                "Structure of Management Information Version 2 (SMIv2)",
1883                STD 58, RFC 2578, April 1999.
1884
1885    [SNMP-OVER] "AN OVERVIEW OF SNMP V2.0", Diversified Data Resources,
1886                Inc., http://www.ddri.com, 1999.
1887
1888    [TIPHON]    "Telecommunications and Internet Protocol Harmonization
1889                Over Networks (TIPHON); Inter-domain pricing,
1890                authorization, and usage exchange", TS 101 321 V1.4.2,
1891                December 1998.
1892
1893    [XML]       Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible
1894                Markup Language (XML) 1.0", W3C Recommendation, February
1895                1998.
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906 Brownlee & Blount            Informational                     [Page 34]
1907 \f
1908 RFC 2924        Accounting Attributes and Record Formats  September 2000
1909
1910
1911    [XML-DATA]  "XML Schema Part 2: Datatypes", W3C Working Draft 07
1912                April 2000, April 2000.
1913
1914    [XML-SCHM]  "XML Schema Part 1: Structures", W3C Working Draft 7
1915                April 2000, April 2000.
1916
1917 13.  Authors' Addresses
1918
1919    Nevil Brownlee
1920    Information Technology Systems & Services
1921    The University of Auckland
1922
1923    Phone: +64 9 373 7599 x8941
1924    EMail: n.brownlee@auckland.ac.nz
1925
1926
1927    Alan Blount
1928    MetraTech Corp.
1929    330 Bear Hill Road
1930    Waltham, MA 02451
1931
1932    EMail: blount@alum.mit.edu
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962 Brownlee & Blount            Informational                     [Page 35]
1963 \f
1964 RFC 2924        Accounting Attributes and Record Formats  September 2000
1965
1966
1967 14.  Full Copyright Statement
1968
1969    Copyright (C) The Internet Society (2000).  All Rights Reserved.
1970
1971    This document and translations of it may be copied and furnished to
1972    others, and derivative works that comment on or otherwise explain it
1973    or assist in its implementation may be prepared, copied, published
1974    and distributed, in whole or in part, without restriction of any
1975    kind, provided that the above copyright notice and this paragraph are
1976    included on all such copies and derivative works.  However, this
1977    document itself may not be modified in any way, such as by removing
1978    the copyright notice or references to the Internet Society or other
1979    Internet organizations, except as needed for the purpose of
1980    developing Internet standards in which case the procedures for
1981    copyrights defined in the Internet Standards process must be
1982    followed, or as required to translate it into languages other than
1983    English.
1984
1985    The limited permissions granted above are perpetual and will not be
1986    revoked by the Internet Society or its successors or assigns.
1987
1988    This document and the information contained herein is provided on an
1989    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1990    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1991    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1992    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1993    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1994
1995 Acknowledgement
1996
1997    Funding for the RFC Editor function is currently provided by the
1998    Internet Society.
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018 Brownlee & Blount            Informational                     [Page 36]
2019 \f