Re: Extended-Space attribute draft available

[Barney Wolff <barney@databus.com>]

On Tue, Feb 28, 2006 at 09:43:43PM -0500, David Mitton wrote:
> 
> An alternative to this format could be a variation on my RADIUS 
> Diameter VSA format in
> http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01.txt
> 
> where we could do something like:
> (he says, editing on the fly)....
> 
> 
> RADIUS Diameter AVP:
> 
>        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 = TBA   |    Length     |r M P r r r r r|    Segment    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Type (first segment only?)                    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                      Attribute-Data ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     Flags M & P retrain their Diameter values.
> 
>       RADIUS Type = TBA
>       RADIUS Length (3~255)
>       Flags = from Diameter message
>       Segment = 0-63, Segment number for data lengths greater than 246,
>       Type = 4 bytes from the Diameter Type code
>       Data = upto 246 bytes
> 
>    For Diameter values with lengths greater than 246, the additional
>    data would be put in consecutive attributes, in the same manner as
>    EAP [RADIUS-EAP], [RFC3579].
> 
>    The Segment field will be zero for the first attribute, and each
>    sucessive attribute data segment will increment the Segment field.
>    The Vendor-Id and Vendor-Type SHALL not be repeated.
> 
>    Note that RADIUS applications that do not understand the
>    attribute will not honor the Diameter M and P flags.  These flags
>    have no meaning in RADIUS, but are preserved for vendor specific
>    meaning and potential transport back to Diameter.

Ah, the avp-header debate begins :)

The choice of the Diameter AVP header format for Extended-Space was
certainly not made on the basis of elegance or optimization of
RADIUS message size, but rather optimization of calendar time (in
the sense of hoping that it would truncate debate over details of
header format) and, secondarily, allowing a translating gateway to
simply do a bulk copy of the concatenated value fields of all the
Extended-Space attributes in the RADIUS message.

Had I been designing Diameter's data formats, I would have used ASN.1
and BER (or PER).  Is there really any device speaking either RADIUS
or Diameter that does not speak SNMP and have access to a BER library?
But it's years too late for that.

Re the header format suggested above, I'd point out that Segment is
unnecessary, as the requirement that instances of a particular RADIUS
attribute not be re-ordered provides implicit sequencing. All that's
needed is a T-flag to say Type is present.

By keeping the Diameter AVP length field, we avoided a requirement to
start each Diameter-format attribute with a new Extended-Space attribute.

Using the Diameter format accepts the proposition that increasingly
servers, and arguably clients as well, will talk both Diameter and
RADIUS, and therefore designing a third AVP header format would just
add to code complexity.

Regards,
Barney

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