Subject: [radext] Attribute Design on 'Traffic Statistics'

From: Leaf yeh <[email-masked]>
Date: Thu, 23 Feb 2012 16:10:54 +0000

Dear Radius-Doctors:

I presented the following 6+ attribute design at Radext session of IETF82-Taipei, which can be found in http://www.ietf.org/proceedings/82/slides/radext-2.pptx  (RADIUS Accounting Extensions on Traffic Statistics) against draft-yeh-radext-ext-traffic-statistics.

Here are their Pros & Cons for our further discussion:

Attribute Design – 1a @ traditional type space in flat mode

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |              Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Value (cont.)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: simple, based on RFC2865 if the traditional type space still open for this case, draft-ietf-radext-radius-extensions sounds intend to deprecate the traditional standard type space.
Cons: 8 new type for (IPv4/IP6) * (Input/Output) * (Octets/Packets)

Attribute Design – 1b @ traditional type space

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Traffic-Type  |    Value      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Value (cont.)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: simple, data type sounds the same as the one defined in RFC2868; the design of 'Traffic-Type' can cover the type of change with (IPv4/IPv6) & DSCP(3bits), and even change with (Input/Output) and (Octets/Packets) because it has 8 bits in the field of 'Traffic-Type'. That might mean 1 new type of attribute is enough to work.
Cons: Sounds complex data type

Attribute Design – 2a @ extended type space in flat mode

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Extended-Type |     Value     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Value (cont.)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: simple, based on Extended type defined in section 2.1 of draft-ietf-radext-radius-extensions-04, if we'd need to use the extended type space at this time
Cons: 8 new type @ 241.x

Attribute Design – 2b @ extended type space

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Extended-Type | Traffic-Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Value (cont.)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: Same as Design - 1b if we'd need to use the extended type space at this time
Cons: same as the Design-1b, sounds forbid in draft-ietf-radext-radius-extensions-04

Attribute Design – 3 @ extended type space in nesting-TLV mode

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Extended-Type | Traffic-Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Traffic-Type(TLV)       |       Input-Octets(TLV)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Octets(TLV)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Octets(TLV)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Octets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Octets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Output-Octets(TLV)       |       Input-Packets(TLV)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Packets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Input-Packets(TLV)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Packets(TLV)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Output-Packets(TLV)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Output-Packets(TLV)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros: used the new basic data type of TLV defined in draft-ietf-radext-radius-extensions-04, has one TLV-container (1 new extended type, 241.x) and 5 sub-TLVs (241.x.1-5). The sub-TLV does not need to appear in the above order, and even some of them are not necessary to appear in the container attribute.
Cons: looks a little complicated, should use the extended-type as per draft-ietf-radext-radius-extensions,

Attribute Design –4a @ traditional type space

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    | Traffic-Type  | Input-Octets  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Input-Octets                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Input-Octets                 | Output-Octets |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Output-Octets                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Output-Octets                 | Input-Packets |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Input-Packets                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Input-Packets                 |Output-Packets |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Output-Packets                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Output-Packets                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-++-+-+-+

Pros: explicit and simplified from the design-3 because each field has the fixed length.
Cons: multi-field design, complex data type (not recommended by RFC6158)

Pls. feel free to comments on the above designs from your professional perspective, then I will update my draft based on your comments.

I supposed each design can work for 'Traffic Statistics', maybe Design 1a, 1b, 2a, 3 could be more acceptable.

I recommend design 1b, because it looks much simple, need much less attributs than design 1a, and we can solve the problem on reporting 'Traffic Statistics' within the standard type space.

If the standard type space is deprecated against this case, then design-2a might be our choice, because we don't have the space limitation issue in the extended type space;

or we could try the new basic data type of nesting-TLV, then 'Acct-Traffic Statistics' could be the 1st attribute in the extended type space with TLV as its basic data type.

But my concern will be that it still needs 3 or more years for the upgrade of the deployed radius system (NASs + servers) to support the solution of the extended type space and its newly-defined attributes.

Best Regards,
Leaf
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext