RE: backwards compatible introduction of NEW attribute such as CU I

[Avi Lior <avi@bridgewatersystems.com>]

Hi Jari,

While I agree with your analysis, except that CUI is not needed by the home
network.  The home network can use other means - like class.  
CUI is intended to be used by entities not in the home network which can't
use the class attribute.

This is causing some folks to jump on us thinking that we don't understand
class and that we are trying to reinvent class.  Note only are the authors
classy, they also understand class very well.

See further inline....

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Saturday, December 18, 2004 4:46 AM
> To: Bernard Aboba
> Cc: Avi Lior; Adrangi, Farid; radiusext@ops.ietf.org
> Subject: Re: backwards compatible introduction of NEW 
> attribute such as CU I
> 
> 
> Bernard Aboba wrote:
> 
> > With a VSA, if the NAS doesn't understand it, it can ignore it.  Is 
> > that true of CUI as well?  If this really is about the NAS, then I 
> > think the answer is yes.  The RADIUS Server can send CUI along with 
> > Class, and if the NAS doesn't support it, it can ignore it and the 
> > home server will get all the billing info it needs from the Class 
> > attribute.  This is backward compatible on the NAS (since 
> it doesn't 
> > need to be upgraded to support
> > CUI) as well as on the RADIUS server (who doesn't see a CUI 
> attribute it
> > didn't ask for).
> 
> I believe there are two "layers" that we need to distinguish 
> here. The most obvious layer is what happens at RADIUS. For 
> this layer the question "can we ignore the CUI" depends on 
> whether the CUI affects some of the subsequent RADIUS 
> messages. Is there a requirement for the CUI to be copied 
> back in Accounting-Requests? If yes, then the CUI needs to be 
> understood at least in that sense. But I forget what the base 
> RFCs say about copying unknown attributes to 
> Accounting-Requests. If there is no requirement for CUI to be 
> copied back, then we are assuming that the home network can 
> associate the access and accounting requests by other means.

Not every attribute received in an Access-Accept is copied to the Accounting
packets.

A NAS or a RADIUS proxy, that is complaint with the proposed RFC will place
CUI in the accounting packets.

A NAS or a RADIUS proxy that is not compliant with the proposed RFC will not
place the CUI in the accounting packets.

> But we also have a second layer, which is the billing and 
> policy processes. For the CUI to be useful, we are already 
> assuming that there is a need for the organizations to 
> correlate some billing information based on the CUI, or do 
> some policing based on the CUI (such as # of concurrent 
> sessions per CUI). Here we can see a few different cases:

Yes.

> o  Home network can't complete its billing/reconciliation
>     process without getting a CUI from the access network.
>     Here we MUST have support for the CUI in the access
>     network, or otherwise the two networks can't work together.
>     Fortunately this can be checked at the time the roaming
>     contract is signed.

No the home network does not need to get CUI.  Its not about the home
network. But it maybe helpful.

> o  Home network offers CUI for everyone, but does not
>     need it by itself. Support for CUI is optional,
>     and if the access network needs it they will upgrade
>     their equipment to support it.

Yes.
 
> o  Home network does not offer CUI to anyone. If the
>     access networks do not need it, no problem. If they
>     do, they can not work together with this home network.
>     Given that the usage of CUI is expected to be in
>     the billing and reconciliation process, we should
>     never get into the latter situation. However, the
>     access network may be unable to perform policy
>     operations that it wants to, if those operations
>     require knowledge of the CUI.

Yes.

So use of CUI whether it is there or not, and what it contains is all driven
by the business layer as you put it. 
> --Jari
> 

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