[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on modified Extended Attribute format?
Bernard,
Here is the WiMAX VSA definition (the payload of a RADIUS Type 26
attribute). As you can see it aligns with the earlier proposal. The
fragmentation concept is used but the tag concept is not used but is
reserved.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WiMAX Type | Length | Continuation | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Continuation Field is defined as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|r|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
The C-bit of the continuation field indicates if a WiMAX attribute is
being fragmented.
When the C-bit is set to one '1' this indicates that the attribute is
being fragmented that is
the next WiMAX VSA of the same WiMAX type is to be appended to this
attribute.
When the C-bit is set to zero '0' this indicates that the next attribute
is not a fragment of
this attribute.
A WiMAX attribute that is not being fragmented will have the C-bit set
to '0'. A WiMAX
attribute that is being fragmented will have its C-bit set to '1' for
all fragments until the last
fragment which will have its C-bit set to '0' indicating it's the last
fragment of the attribute.
The r-bits are reserved for future use. They SHALL be set to zero by the
sender and
SHALL be ignored by the receiver.
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Wednesday, January 09, 2008 3:11 AM
> To: Avi Lior; David B. Nelson; radiusext@ops.ietf.org
> Subject: RE: Questions on modified Extended Attribute format?
>
>
> Avi --
>
> Is it correct to say that the current proposal is compatible
> with WiMAX VSAs?
>
> For example, is there no tag part in the WiMAX VSAs, or is it
> just not used in any existing VSAs?
> ----------------------------------------
> > Subject: RE: Questions on modified Extended Attribute format?
> > Date: Tue, 8 Jan 2008 22:17:22 -0500
> > From: avi@bridgewatersystems.com
> > To: d.b.nelson@comcast.net; radiusext@ops.ietf.org
> >
> > WiMAX did try to align at one time. But things have changed.
> >
> > And to get WiMAX to align again with the IETF would be hard
> now. We
> > would need a good reason to change given that we have
> implementation.
> > But not impossible since lots of things are changing.
> >
> > But to be 100 clear, the WiMAX encoding is WiMAX's encoding and not
> > IETF. While compatiblity is desirable it is not required
> at this stage.
> >
> > It would have been nice if the IETF addressed the issues -- much --
> > earlier.
> >
> > Note in WiMAX we use the M bit but dont use the tag part.
> >
> >> -----Original Message-----
> >> From: owner-radiusext@ops.ietf.org
> >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson
> >> Sent: Wednesday, December 26, 2007 9:59 PM
> >> To: radiusext@ops.ietf.org
> >> Subject: RE: Questions on modified Extended Attribute format?
> >>
> >> Bernard Aboba writes...
> >>
> >>>> WiMAX uses the same attribute format as proposed here. Changes
> >>>> that are incompatible with WiMAX should be discouraged.
> >>>
> >>> I would agree. If the extensions remain compatible with
> WiMAX then
> >>> the amount of code duplication will be minimized.
> >>
> >> I'm not so sure that I agree. We should do what's right for the
> >> RADIUS community. If that happens to be compatible with
> WiMAX, then
> >> great.
> >>
> >>
> >>
> >> --
> >> 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:
> >>
> >
> > --
> > 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:
>
--
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/>