RE: [Dime] RE: Diameter base protocol messages used by DCCA

["Glen Zorn \(gwz\)" <gwz at cisco.com>]

STURA, Marco, VF-IT <mailto:Marco.STURA at vodafone.com> supposedly scribbled:

>> Actualy, shouldn't ApplicationId in the message header be 4
>> (ApplicationId for DCCA) , for such an AAR?
> 
> No, that is not what RFC4006 specifies. See below from section 5.2.2
> 
>    The Diameter credit-control client in the service element MUST
>    actively co-operate with the authorization/authentication client in
>    the construction of the AA request by adding appropriate credit-
>    control AVPs.  The credit-control client MUST add the
>    Credit-Control AVP to indicate credit-control capabilities and MAY
>    add other relevant credit-control specific AVPs to the proper
>    authorization/authentication command to perform the first
>    interrogation toward the home Diameter AAA server.  The Auth-
>    Application-Id is set to the appropriate value, as defined in the
>    relevant service specific authorization/authentication application
>    document (e.g., [NASREQ], [DIAMMIP]).  The home Diameter AAA server
>    authenticates/authorizes the subscriber and determines whether
>    credit-control is required.
> 
> The reason we introduced use of service specific AA request for the
> first interrogation is for protocol efficiency reasons in case in
> certain environments there is a need to perform credit check at the
> same time service specific authentication/authorization is executed
> (e.g. access authentication/authorization). Essentially this is to
> avoid several round trips before granting access to a user (i.e. one
> for service specific AA and one for credit control). Messages may
> need to traverse a number of "domains" to reach the home domain in
> roaming circumstances, hence significant delay may occur. So, the AA
> message is used for both service specific and credit control
> processes but there is no means to indicate this to the server other
> than AVP based. 

So, in other words, in order to implement a e.g., [NASREQ], [DIAMMIP] peer intended for general distribution, one must include CCA client functionality.

> However, after the first interrogation there will be
> an independent credit control stream if so required.            
> 
> Would it then make sense to monitor AA messages and CC messages
> independently also for the first interrogation performed during
> service specific AA? If the model above is used there will be e.g.
> NASREQ MIB + DCCA MIB in the same node.   
> 
> E.g. A successful AAR/AAA (NASREQ Application-Id) may or may not lead
> to an independent credit control stream. If it does there will be
> zero or more CCR updates (DCCA Application-Id) and a CCR termination
> (DCCA Application-id) when the AA session is closed. Therefore, in a
> NASREQ + DCCA example, if credit control is used for a subscriber
> successful AAR/AAA will result at least in the CCR termination
> counter incremented and that would mean that AAR/AAA was used to
> perform first interrogation.  

Or, that there were no intermediate interrogations; also, what about the case of a one-time event (balance check, etc.)?  Although this kind of activity doesn't seem to be included in any of the examples in RFC 4006, neither does it appear to be prohibited.  If a balance check or other type of one-time event was included in the AAR it seems that there would be no client-side counter incremented.
     
> 
> In other cases, where the model described in section 5.2.2 is not
> used, a CCR initial counter would be incremented. 
> 
> BTW, do you plan to have different counters for different CCR types
> (initial, update, termination)? 

I hadn't planned to, no.  However, if it is necessary to use this data to infer the existence of an initial interrogation from its absence (does anybody else see something odd about this?), I suppose I will have to do so.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime