description of that content through its Content-Type, Content-
Encoding, Accept-Encoding, and Transfer-Encoding header fields. New
types of content can be designated and carried by HTTP/1.1 without
modification to the HTTP protocol.
XML [XML] is a preeminent general-purpose framework encoding. DTD
publishing is left to users. There is no standard registry of DTDs.
SNMP presents a successful example of a framework protocol. SNMP's
authors envisioned SNMP as a general management protocol, and allow
extension through the use of private MIBs. SNMP's ASN.1 MIBs are
defined, published, and standardized without the necessity to modify
the SNMP standard itself. From "An Overview of SNMP" [SNMP-OVER]:
It can easily be argued that SNMP has become prominent mainly from
its ability to augment the standard set of MIB objects with new
values specific for certain applications and devices. Hence, new
functionality can continuously be added to SNMP, since a standard
method has been defined to incorporate that functionality into
SNMP devices and network managers.
Most accounting protocols are fully-specified, with either a
completely defined service or set of services (RADIUS Accounting) or
with one or more services defined and provision for "extension"
services to be added to the protocol later (TIPHON). While the
latter is preferable, it may be preferable to take a more SNMP-like
approach, where the accounting record format and protocol provide
only a framework for service definition, and leave the task of
service definition (and standardization) to separate efforts. In
this manner, the accounting protocol itself would not have to be
modified to handle new services.
9.4.2. Versioned Service Definitions
Versioning is a naming and compatibility issue. Version identifiers
are useful in service definition because they enable service
definitions to be upgraded without a possibly awkward name change.
They also enable possible compatibility between different versions of
the same service.
An example could be the service definition of a phone call. Version
1 might define Properties for the start time, duration, and called
and calling party numbers. Later, version 2 is defined, which
augments the former service definition with a byte count. An
Accounting Server, aware only of Version 1, may accept Version 2
records, discarding the additional information (forward
compatibility). Alternately, if an Accounting Server is made aware
of version 2, it could optionally still accept version 1 records from
Service Elements, provided the Accounting Sever does not require the
additional information to properly account for service usage
(backward compatibility).
9.4.3. Relationships Among Usage Events
Accounting record formats and protocols to date do not sufficiently
addressed "compound" service description.
A compound service is a service that is described as a composition of
other services. A conference call, for example, may be described as
a number of point-to-point calls to a conference bridge. It is
important to account for the individual calls, rather than just
summing up an aggregate, both for auditing purposes and to enable
differential rating. If these calls are to be reported to the
Accounting Server individually, the Usage Events require a shared
identifier that can be used by the Accounting Server and other back-
end systems to group the records together.
In order for a Service Element to report compound events over time as
a succession of individual Usage Events, the accounting protocol
requires a facility to communicate that the compound event has
started and stopped. The "start" message can be implicit--the
transmission of the first Usage Event will suffice. An additional
semaphore is required to tell the Accounting Server that the compound
service is complete and may be further processed. This is necessary
to prevent the Accounting Server from prematurely processing compound
events that overlap the end of a billing period.
RADIUS Accounting has some provision for this sort of accounting with
its "Acct-Multi-Session-Id" field. Unfortunately, RADIUS
Accounting's other shortcomings preclude it from being used in
general purpose service usage description.
9.4.4. Service Namespace Management
"Framework" protocols, as previously mentioned, do not define
complete schema for their payload. For interoperability to be
achieved, it must be possible for:
(1) content definers to specify definitions without conflicting
with the names of other definitions
(2) protocol users to find and use content definitions
Condition (1) can be readily managed through IANA assignment or by
using an existing namespace differentiator (for example, DNS).
Condition (2) is harder, and places considerable burden on the
implementors. Their clients and servers must be able, statically or
dynamically, to find and validate definitions, and manage versioning
issues.
As previously mentioned, the XML specification provides no facility
for DTD discovery or namespace management. XML specifies only a
document format, and as such does not need to specify support for
more "protocol" oriented problems.
For an accounting record format and protocol, an approach closer to
SNMP's is useful. SNMP uses an ISO-managed dotted-decimal namespace.
An IANA-managed registry of service types is a possibility. Another
possibility, used by MSIX [MSIX-SPEC], is for Service Element
creators to identify their services by concatenation of a new service
name with existing unique identifier, such as a domain name.
A standard record format for service definitions would make it
possible for Service Element creators to directly supply accounting
system managers with the required definitions, via the network or
other means.
10. Encodings
It may be useful to define more than one record encoding.
A "verbose" XML encoding is easily implemented and records can be
syntactically verified with existing tools. "Human-readable"
protocols tend to have an edge on "bitfield" protocols where ease of
implementation is paramount and the application can tolerate any
additional processing required to generate, parse, and transport the
records.
A alternative "compressed" encoding that makes minimal use of storage
and processing may be useful in many contexts.
There are disadvantages to supporting multiple encodings.
Optionally-supported multiple encodings mandate the requirement for
capabilities exchange between Service Element and Accounting Server.
Also, implementations can tend to "drift apart", with one encoding
better-supported than another. Unless all encodings are mandatory,
implementors may find they are unable to interoperate because they
picked the wrong encoding.
11. Security Considerations
This document summarises many existing IETF and ITU documents; please
refer to the original documents for security considerations for their
particular protocols.
It must be possible for the accounting protocol to be carried by a
secure transport. A canonical record format is useful so that
regeneration of secure record hashes is possible.
When dealing with accounting data files, one must take care that
their integrity and privacy are preserved. This document, however,
is only concerned with the format of such files.
12. References
[ACC-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
Background", RFC1272, November 1991.
[ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC1700, October 1994.
[ASN1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization, International Standard 8824, December
1987.
[ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad,
"Accounting Information for ATM Networks", RFC2512,
February 1999.
[ATM-COLL] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "
Managed Objects for Controlling the Collection and
Storage of Accounting Information for Connection-Oriented
Networks", RFC2513, February 1999.
[BER] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1), International
Organization for Standardization, International Standard
8825, December 1987.
[DIAM-ACT] Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G.,
"DIAMETER Accounting Extension", Work in Progress.
[DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User
Authentication Extensions", Work in Progress.
[DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER Framework
Document", Work in Progress.
[DSRV-ARC] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup
Language - 2.0", RFC1866, November 1995.
[HTTP] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol--HTTP/1.1", RFC
2068, January 1997.
[ICAL-CORE] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification", RFC2445, November
1998.
[IIS-ARC] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC
1633, June 1994.
[IIS-SPEC] Shenker, S., Partridge, C. and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC2212, September
1997.
[ISDN-MIB] Roeck, G., "ISDN Management Information Base using
SMIv2", RFC2127, March 1997.
[ISO-DATE] "Data elements and interchange formats -- Information
interchange -- Representation of dates and times", ISO
8601:1988.
[MAIL] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
TEXT MESSAGES", STD 11, RFC822, August 1982.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321,
April 1992.
[MSIX-SPEC] Blount, A. and D. Young, "Metered Service Information
Exchange 1.2", Work in Progress.
[NEWS-MSGS] Horton, M. and R. Adams, "Standard for Interchange of
USENET Messages", RFC1036, December 1987.
[NEWS-PROT] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC977, February 1986.
[NTP] Mills, D., "Network Time Protocol (NTP)", RFC958,
September 1985.
[Q-825] "Specification of TMN applications at the Q3 interface:
Call detail recording", ITU-T Recommendation Q.825, 1998.
[RAD-ACT] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.
[RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS
Extensions", RFC2869, June 2000.
[RAD-PROT] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC2865, June 2000.
[RAD-TACC] Zorn, G., Mitton, D. and A. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC2867,
June 2000.
[RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC2748, January 2000.
[ROAM-ADIF] Aboba, B. and D. Lidyard, "The Accounting Data
Interchange Format (ADIF)", Work in Progress.
[ROAM-IMPL] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang,
"Review of Roaming Implementations", RFC2194, September
1997.
[RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
Felstaine, "A Framework For Integrated Services Operation
Over Diffserv Networks", Work in Progress.
[RSVP-ARC] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Reservation Protocol (RSVP) Version 1
Functional Specification", RFC2205, September 1997.
[RSVP-MIB] Baker, F., Krawczyk, J. and A. Sastry, "RSVP Management
Information Base using SMIv2", RFC2206, September 1997.
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC2722, October 1999.
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
Measurement: Architecture", RFC2720, October 1999.
[RTFM-NEWA] Handelman, S., Brownlee, N., Ruth, G. and S. Stibler,
"New Attributes for Traffic Flow Measurement", RFC2724,
October 1999.
[SIP-PROT] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC2543,
March 1999.
[SMI-V2] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC2578, April 1999.
[SNMP-OVER] "AN OVERVIEW OF SNMP V2.0", Diversified Data Resources,
Inc., http://www.ddri.com, 1999.
[TIPHON] "Telecommunications and Internet Protocol Harmonization
Over Networks (TIPHON); Inter-domain pricing,
authorization, and usage exchange", TS 101 321 V1.4.2,
December 1998.
[XML] Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible
Markup Language (XML) 1.0", W3C Recommendation, February
1998.
[XML-DATA] "XML Schema Part 2: Datatypes", W3C Working Draft 07
April 2000, April 2000.
[XML-SCHM] "XML Schema Part 1: Structures", W3C Working Draft 7
April 2000, April 2000.
13. Authors' Addresses
Nevil Brownlee
Information Technology Systems & Services
The University of Auckland
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Alan Blount
MetraTech Corp.
330 Bear Hill Road
Waltham, MA 02451
EMail: blount@alum.mit.edu
14. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.