RE: Issue 113: Attribute Concatenation

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

> 
> > Responding to Greg's issue 113...
> > 
> >> I didn't understand how the language in section 3.6 about 
> >> concatenating
> > 
> >> QoS-Filter-Rule(s) works.  If these are simply 
> concatenated, how does 
> >> an implementation distinguish between multiple 'small'
> >> QoS-Filter-Rules
> > 
> >> and a single larger attribute?  What if I want to send one 
> >> QoS-Filter-Rule which spans 253, followed by one which does not?
> > 
> > Actually I believe the editorial note needs to be removed 
> since there 
> > is text just after the note that explains the problem.  As 
> you know, 
> > Diameter attributes may be larger than what will fit in the Radius 
> > attribute so we need to support fragmentation and reassembly in the 
> > general sense.
> 
> Actually, Diameter AVPs can be larger than a RADIUS 
> _message_.  If you really want to support fragmentation and 
> reassembly in the general sense, then you need to deal with that, too.
> 

I probably should have been more clear about using the words 'general
sense'.  All we are talking about is the string in the Qos-Filter-Rule
that might be too large to fit in the current Radius version of the
attribute.  I am under the assumption that handling this type of
scenario is common practice in Radius/Diameter proxies and that is has
been documented in a previous RFC, but perhaps I'm wrong on this.

I still think the existing text explains the issue and solution fairly
clearly:

         The Text field contains a QoS filter, utilizing the syntax 
         defined for the QoSFilterRule derived data type defined in 
         [RFC3588], Section 4.3.  Note that this definition contained an

         error, so that the complete syntax is described in the 
         definition of the QoS-Filter-Rule AVP, defined in [NASREQ]. 
      
         The RADIUS server can return multiple QoS-Filter-Rule 
         attributes in an Access-Accept or CoA-Request packet. Where 
         more than one QoS-Filter-Rule Rule attribute is included, it is

         assumed that the attributes are to be concatenated to form a 
         single QOS filter. 
 
         Whereas the maximum allowable message size in [NASREQ] is 
         greater than RADIUS' maximum allowable message size, it is 
         assumed that QOS filters that exceed RADIUS' allowable message 
         size will be broken into multiple QoS-Filter-Rule attributes by

         the RADIUS server and concatenated back into a single QOS 
         filter by the NAS. 
          
         As per the requirements of RFC 2865, Section 2.3, if multiple 
         QoS-Filter-Rule attributes are contained within an Access-
         Request or Access-Accept packet, they MUST be maintained in 
         order. The attributes MUST be consecutive attributes in the 
         packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule 
         attributes. 

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