Introduction

IPDR Service Definitions define the set of attributes (the who, what, when and how much) associated with a given service.  Service definitions are written as XML Schemas which relate back to a base IPDRDoc Schema. A usage event for a given service is represented by a collection of the mandatory and some or all of the optional attributes defined by that service's definition.

IPDR defines an XML encoding scheme (the IPDRDoc), which allows a set of usage events to be recorded in a single "payload".  This is typically embodied as a file, but may also be a contained in a stream of data carried by a network protocol.

The computational overhead associated with extracting information from an XML encoded document, along with the typical document size is considered by many as a deterrent to implementing IPDR in "real world" deployments.  Although detailed performance metrics are not available, a simple example can illustrate some of this concern.

Consider the following partial RADIUS usage event in IPDR XML format:

   <SS id="ses0">
     <SC xsi:type="SC-AA-Type">
       <subscriberId>joe</subscriberId>
       <ipAddress>192.168.2.64</ipAddress>
     </SC>
     <SE xsi:type="SE-AA-Type">
       <nasIdentifier>nas1.foo.com</nasId>
     </SE>
   </SS>
   <UE xsi:type="UE-AA-Type">
      <acctInputOctets>13444</acctInputOctets>
      <acctOutputOctets>77777</acctOutputOctets>
   </UE>

This message is 314 bytes in length.

The equivalent raw RADIUS information (not including headers) would be encoded as follows:

   01 05 j  o  e  08 06 C0 98 40 20 0e  n  a  s  1  .  f  o  o  . c  o  m
   2a 06 00 00 34 84 2b 06 00 01 2f d1

This is 36 bytes in length.

Proposed Goal

IPDR can define a service attribute definition language based on XML Schema.  An IPDR based Service definiton will allow usage information for that service to be recorded in either XML document format or in a compact encoding.  Either of these encoding strategies defines a payload of usage information.  IPDR will additionally specify or reference both a file based scheme and a direct transport mechanism for exchanging usage information between systems.

The criteria for evaluating a compact encoding identified by the working group include:

• The format should be more space efficient than the XML equivalent (preferably by several times)
• The format should allow for efficient parsing and processing
• Complexity should be minimized in order to spur adoption and interworking systems, and aid in debugging.
• The format would ideally draw from existing standards work
• The format should provide performance and size characteristics which are comparable to known vendor proprietary formats.
• There must be well defined mapping from the service definition to the encoding
• The format should allow for easy extension and expansion of the set of defined services
• The format should be self-describing.  That is, knowing an encoding is an IPDR document, a system should be able to extract the recorded usage information without additional external control.

Extensible Service Namespace

In order to provide a general framework for the definition of Service specific accounting attributes, the following properties should hold:

• New services can be defined in a consistent manner
• Parties outside of IPDR should be able to create extensions to service definitions to accomodate vendor-specific capabilities
• The identifier associated with each service attribute defined should be unique
• Service definitions should be machine readable to allow automatic processing by tools
• There should be a means to easily discover the existing set of available service definitions and those under development

An XML Schema approach has these basic properties, although the uniqueness requirement will require a scan of existing service definitions. A suffix approach may increase the likelihood that generated names are in fact unique.  (Suffix could either be a service name, or a vendor identifier [e.g. vod.movieId or real.com.movieId]).  From a context perspective, reference to a specific schema definition (e.g. vod.xsd) implies some restriction on namespace.

See here for additional namespace discussion.

Self Describing Content

Because the content of usage events varies greatly from service to service and new services will continue to appear with new requirements, it is useful to have the encoded format of the data be self-describing.  This means that an IPDR system can interpret the contents of the payload in a meaningful way without requiring additional context.

1:1 Mapping from Service Definition to Encoding

The mapping process should be unambiguous.  Given a "raw" usage event from a service, there should be a clear mapping of this event into its IPDR format, based on the Service Definition document and the encoding rules.

Leverage Existing Standards

A good survey of the existing accounting landscape is covered in RFC2924.  In particular chapters 7, 8 and 9 address similar issues raised here.

It is preferable to adopt an existing encoding standard if available rather than invent another encoding.  Example mechanisms include:

• Telco Exchange Format - the BCD based record formats and the associated tables and modules was considered to be difficult to work with, based on many members experience.
• CORBA Common Data Representation - the encoding structure used for CORBA communication is defined in the CORBA 2.4.2 specification in chapter 15, General Inter-ORB Protocol.  The encoding follows the basic machine representation for data types, and utilizes byte alignment policies to aid in parse efficiency.  It is not self describing, but rather requires that a matching Interface Definition Language (IDL) be referenced in order to properly decode.
• WAP Binary XML -  this has been submitted as a technical note to the W3C.  It defines a methodology for converting an existing XML document into a binary encoded format.  The defined mechanism utilizes a mapping of XML element tags into integer identifiers, the specification only appears to allow 5 bits (32) unique tags in a given document.
• ASN.1 - The Abstract Syntax Notation 1 International standard, defines well adopted encoding rules for structured information.  There are a couple of possible approaches to utilizing ASN.1:
• There is currently work on an standard mapping of XML Schema into ASN.1.  This work sounds like it is fairly preliminary.
• An ASN.1 based accounting file format is defined in RFC2513.  This format is reliant on each record in the file to be homogenous (i.e. contain the same set of attributes).  It is also closely aligned with SNMP and assumes an association of "Object Identifiers" with each attribute.
• Diameter Attribute Value Pairs (AVPs) - The basic encoding model for all attributes carried in a diameter message are discussed in section 4.1 of the Diameter Base Protocol.

---

IPDR.org Proprietary and Confidential – Do Not Distribute

Jeff Meyer  Apr. 11, 2001