Grouping of sub attributes in seperate VSAs
Hi We have a device which sends individual traffic counters for several different services. The dicitionary is as follows: VENDOR VasExperts 43823 BEGIN-VENDOR VasExperts ... ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 17 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 18 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 19 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 20 integer64 ... In the accounting packet these attribtues are grouped into individual VSAs as follows: AVP: l=51 t=Vendor-Specific(26) v=VAS Experts(43823) AVP Type: 26 AVP Length: 51 VSA: l=5 t=VasExperts-Acct-Traffic-Class-Name(16): cs0 VSA: l=10 t=VasExperts-Acct-Traffic-Class-Input-Octets(17): 0000000000000000 VSA: l=10 t=VasExperts-Acct-Traffic-Class-Output-Octets(18): 00000000002128bc VSA: l=10 t=VasExperts-Acct-Traffic-Class-Input-Packets(19): 0000000000000000 VSA: l=10 t=VasExperts-Acct-Traffic-Class-Output-Packets(20): 00000000000007a4 AVP: l=51 t=Vendor-Specific(26) v=VAS Experts(43823) AVP Type: 26 AVP Length: 51 VSA: l=5 t=VasExperts-Acct-Traffic-Class-Name(16): cs1 VSA: l=10 t=VasExperts-Acct-Traffic-Class-Input-Octets(17): 0000000000000000 VSA: l=10 t=VasExperts-Acct-Traffic-Class-Output-Octets(18): 0000000000000000 VSA: l=10 t=VasExperts-Acct-Traffic-Class-Input-Packets(19): 0000000000000000 VSA: l=10 t=VasExperts-Acct-Traffic-Class-Output-Packets(20): 0000000000000000 Here the fact that the five attributes are gouped together in a single VSA means that they all contain data which pertains to the same service. When FreeRADIUS processes the packet the attribtues are as I understand it added to one long list and I can access them individually by their index. However, as I understand it the ordering of RADIUS attributes is not something which is normally guaranteed and I would like to ask is whether there is any way in unlang or by other means to figure out which which sub attribtues came from the same parent attribute.
On Apr 12, 2018, at 11:07 AM, Бенджамин Томпсон <b.thompson@latera.ru> wrote:
We have a device which sends individual traffic counters for several different services. The dicitionary is as follows:
VENDOR VasExperts 43823
BEGIN-VENDOR VasExperts
...
ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 17 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 18 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 19 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 20 integer64
That might work...
In the accounting packet these attribtues are grouped into individual VSAs as follows:
If you want *real* grouping, you need to use TLVs. i.e. one master attribute, and the sub-attributes within that.
Here the fact that the five attributes are gouped together in a single VSA means that they all contain data which pertains to the same service.
That's what you mean. But that's not how RADIUS works. The attributes are all in a flat space.
When FreeRADIUS processes the packet the attribtues are as I understand it added to one long list and I can access them individually by their index.
Yes.
However, as I understand it the ordering of RADIUS attributes is not something which is normally guaranteed
RADIUS guarantees ordering of attributes which have the same number. It does NOT guarantee ordering of attributes which have a different number. This restriction applies to VSAs, soo.
and I would like to ask is whether there is any way in unlang or by other means to figure out which which sub attribtues came from the same parent attribute.
No. But you can fix the dictionary: VENDOR VasExperts 43823 BEGIN-VENDOR VasExperts ... ATTRIBUTE VasExperts-Acct-Traffic 16 tlv ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16.1 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 16.2 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 16.3 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 16.4 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 16.5 integer64 ... These attributes will be packed into one parent attribute: VasExperts-Acct-Traffic. And ordering of THAT attribute is guaranteed. Alan DeKok.
HI Alan Many thanks for your quick response.
We have a device which sends individual traffic counters for several
different services. The dicitionary is as follows:
VENDOR VasExperts 43823
BEGIN-VENDOR VasExperts
...
ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 17 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 18 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 19 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 20 integer64
That might work...
In the accounting packet these attribtues are grouped into individual VSAs as follows:
If you want *real* grouping, you need to use TLVs. i.e. one master attribute, and the sub-attributes within that.
Here the fact that the five attributes are gouped together in a single VSA means that they all contain data which pertains to the same service.
That's what you mean. But that's not how RADIUS works. The attributes are all in a flat space.
When FreeRADIUS processes the packet the attribtues are as I understand it added to one long list and I can access them individually by their index.
Yes.
However, as I understand it the ordering of RADIUS attributes is not something which is normally guaranteed
RADIUS guarantees ordering of attributes which have the same number. It does NOT guarantee ordering of attributes which have a different number.
This restriction applies to VSAs, soo.
and I would like to ask is whether there is any way in unlang or by other means to figure out which which sub attribtues came from the same parent attribute.
No. But you can fix the dictionary:
VENDOR VasExperts 43823
BEGIN-VENDOR VasExperts
... ATTRIBUTE VasExperts-Acct-Traffic 16 tlv ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16.1 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 16.2 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 16.3 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 16.4 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 16.5 integer64 ...
These attributes will be packed into one parent attribute: VasExperts-Acct-Traffic. And ordering of THAT attribute is guaranteed.
I am slightly confused. At the moment the sub-attribtues are grouped into parent attributes of type Vendor-Specific (26) and presumably the ordering of this attribute is preserved (as the numnber 26 is the same). As I understand it the important thing is that the ordering of the sub-attributes is preserved after flattening. For example I receive two VSAs: Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class1" , VasExperts-Acct-Traffic-Class-Output-Octets = 10] Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class2" , VasExperts-Acct-Traffic-Class-Output-Octets = 20] Here 10 bytes of "class1" data were downloaded and 20 bytes of "class2" data. After flattening I would like: VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Name = "class2 VasExperts-Acct-Traffic-Class-Output-Octets = 20 The following variations would also be kind of OK: VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 or VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2" or ... However any variation where the ordering of VasExperts-Acct-Traffic-Class-Name is not the same as the ordering of VasExperts-Acct-Traffic-Class-Output-Octets after flattening would be a problem: VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 But as far as I can see this can't happen so there is actually no problem at all
VENDOR VasExperts 43823
BEGIN-VENDOR VasExperts
... ATTRIBUTE VasExperts-Acct-Traffic 16 tlv ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16.1 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 16.2 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 16.3 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 16.4 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 16.5 integer64 ...
These attributes will be packed into one parent attribute: VasExperts-Acct-Traffic. And ordering of THAT attribute is guaranteed.
I am slightly confused. At the moment the sub-attribtues are grouped into parent attributes of type Vendor-Specific (26) and presumably the ordering of this attribute is preserved (as the numnber 26 is the same).
Yes, the sort takes into account all levels of the hierarchy, so VSAs contained within RFC attribute 26 will occur consecutively in the final list, and their ordering will be preserved.
As I understand it the important thing is that the ordering of the sub-attributes is preserved after flattening.
For example I receive two VSAs:
Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class1" , VasExperts-Acct-Traffic-Class-Output-Octets = 10] Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class2" , VasExperts-Acct-Traffic-Class-Output-Octets = 20]
Here 10 bytes of "class1" data were downloaded and 20 bytes of "class2" data.
After flattening I would like:
VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Name = "class2 VasExperts-Acct-Traffic-Class-Output-Octets = 20
The following variations would also be kind of OK:
VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20
or
VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2"
or
...
However any variation where the ordering of VasExperts-Acct-Traffic-Class-Name is not the same as the ordering of VasExperts-Acct-Traffic-Class-Output-Octets after flattening would be a problem:
VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20
But as far as I can see this can't happen so there is actually no problem at all
Correct. With the current code you'll get alike SubTLVs occurring consecutively in the packed VSA/TLV attribute so you'd end up with one of those two variations. The reason why this happens is the encoder performs a merge sort on the attribute list prior to attempting to encode the attributes. This makes efficient packing of SubTLV attributes into VSAs/TLVs much easier, because you can just look at the next attribute to see if it's in the same parent TLV, or see if there's a common nesting level. Because merge sort is a stable sort, you should find the ordering of attributes of the same number and lineage don't change. -Arran
With the current code you'll get alike SubTLVs occurring consecutively in the packed VSA/TLV attribute so you'd end up with one of those two variations.
The reason why this happens is the encoder performs a merge sort on the attribute list prior to attempting to encode the attributes. This makes efficient packing of SubTLV attributes into VSAs/TLVs much easier, because you can just look at the next attribute to see if it's in the same parent TLV, or see if there's a common nesting level.
Because merge sort is a stable sort, you should find the ordering of attributes of the same number and lineage don't change.
Arran many thanks for your explanation.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Бенджамин Томпсон