Subject: [AAA-WG]: An idea on Self describing accounting streams .....

From: Abhi Deshmukh <[email-masked]>
Date: Fri, 19 Jan 2001 16:47:59 -0500

> From: Bernard Aboba [mailto:[email-masked]]
>Subject: [AAA-WG]: Re: Self Describing record formats for multiple
>(non-network-access) usage types 

> Do you have an idea to share relating to defining a record format, or
> relating to carriage of a record format?

The main idea is to accommodate *any* usage type for *any* kind of service. 
If the transfer mechanism is agnostic of the attributes and format of the
usage record, then  this allows the transfer to be extensible and attractive
for wide adoption.

Let me know what you think. 

- Abhi

Here is the basic idea on self describing accounting streams:

0. A receiver would connect to the sender. This would include some
sort of authentication.

1. Sender sends structure of information that it wishes to sends
So for example if it wanted to send Web usage information,
It would say, "I have four fields to send"
the first field is a long that means the end user's IP address
the second field is a string that means the URL that was accessed
the third field is a long64 that means number of bytes accessed
the fourth field is a timestamp that means the time this URL was accessed.

The meaning is encoded in a number and is called a catalog.
There are many such catalog ids (hundreds) available to mean different
things like packets,
sessions, whether cached, and so on

This is almost like a binary DTD for an XML document.

2. Receiver accepts the structure and sends an ack to the sender

3. From this point on the sender can send the accounting usage records
according
to the format specified in 1 and acked in 2. 

4. For efficiency, the structure of Information may not be duplicated in
each accounting payload packet.

5. I have some extensions to the above idea for 
	a. filters - If a receiver is interested in a subset of data, then
it can send a filter spec - this allows the sender to send only information
that receiver is interested in, saving bandwidth.
      b. fault-tolerance - Handle failure in sender and receiver
	c  load-balancing - Have multiple receivers load balance a single
stream of accounting info

6. A sender could be sending accounting streams to many receivers.

7. I have done some dry runs on many usage types include Web services,
Caching services, and others and I have been able to use the above idea with
all of them.

8. The underlying transport could be TCP or UDP.

9. Streams could be compressed using standard compression algorithms.

10. Encryption of usage records could also be supported.

11.  Personally I prefer tunneling encrypted/compressed records on top of
HTTP - this allows flexibility in transfer through firewalls on the
public/private network.

- Abhi

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Friday, January 19, 2001 3:57 PM
To: [email-masked]
Cc: Aaa-Wg@Merit. Edu
Subject: [AAA-WG]: Re: Self Describing record formats for multiple
(non-network-access) usage types 

>I have been looking at the AAA related documents for record formats and I
>have an idea to share about the formats.

Do you have an idea to share relating to defining a record format, or
relating to carriage of a record format?

>Is there a thought in the AAA WG of having self describing records in the
>overall AAA framework ?.

At one point, there was discussion of using DIAMETER for carriage of
record formats, rather than just AVPs. However, for the goals of the
AAA WG, this did not seem essential, and so the WG consensus has been
to remove support for the ADIF record format from the protocol.

>This would allow other known unknown and not invented usage records to be
>accomodated in the AAA framework.

There are many ways to transport record formats. To figure out which one
of them is useful, you need to have a requirements document laying out
what the transport has to do.

>This way, if the transport issues are resolved, new usage types would not
present a
>challenge to the record format. Also having a AAA framework that
accomodates
>other usage types (other than end user network access) would be beneficial.

Transport issues are in practice the crux of the problem. You have to think
about what kinds of security you need to provide, how reliable the transport
needs to be, etc. Once you've got that all figured out, then you have a way
of deciding if DIAMETER is right for you.

>I have some ideas on this thought process. If this thought is-being or
>has-been dicussed, then perhaps I missed it. Is there any place that I
>should be looking ? Any useful pointers ?

I'd suggest looking at the following documents:
http://www.ietf.org/rfc/rfc2924.txt
http://www.ietf.org/rfc/rfc2975.txt
http://www.ietf.org/internet-drafts/draft-aboba-roamops-adif-00.txt (just
submitted)