[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Accounting for subsets of total traffic
Hi,
this is what I had in mind today:
245.1 Accounting-Traffic-Group TLV
245.1.1 Accounting-Group-Id ENUM
1 = IPv4
2 = IPv6
245.1.2 Accounting-Group-Name STRING
245.1.3 Acct-Input-Octets 64-Bit-Counter
245.1.4 Acct-Output-Octets 64-Bit-Counter
245.1.5 Acct-Input-Packets 64-Bit-Counter
245.1.6 Acct-Output-Packets 64-Bit-Counter
Example
Accounting-Traffic-Group
Accounting-Group-Id = IPv6
Acct-Input-Octets = 4500
Acct-Output-Octets = 1200
Acct-Input-Packets = 30
Acct-Output-Octets = 10
Accounting-Traffic-Group
Accounting-Group-Name = "Traffic on TCP/80 to Google, all IP versions"
Acct-Input-Octets = 450
Acct-Output-Octets = 120
Acct-Input-Packets = 3
Acct-Output-Octets = 1
The group is to contain *either* -Id (enums assigned by IETF process)
*or* -Name with some string if you want to express some very specialised
(read: weird) statistics to report about (and they don't have to bug
IETF to get a value).
There can be multiple groups in one acct packet (especially IPv4, IPv6
are probably handy). There shouldn't be a requirement that the sum is
the total bytes/packets in the session; and that means the "original"
Acct-(Input/Output)-(Packets/Bytes) still remain in the accounting
packet to report the grand total.
I used 245 because the total length can grow beyond 252 - the string can
be potentially large.
I am aware that I used 64-Bit Counters even though that datatype doesn't
exist. That's because -Gigawords is a terrible hack around the 32-Bit
limitation of integers; I think it might be about time to change that.
If this thinking is in an acceptable general direction, I'm happy to put
it into a draft as soon as I'm back home with a shell access to xml2rfc.
Greetings,
Stefan Winter
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>