Grouping of sub attributes in seperate VSAs

[Arran Cudbard-Bell]

>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20180413/7aaa368d/attachment.sig>