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

STURA, Marco, VF-IT <mailto:[email protected]> supposedly =
scribbled:

>> Actualy, shouldn't ApplicationId in the message header be 4
>> (ApplicationId for DCCA) , for such an AAR?
>=20
> No, that is not what RFC4006 specifies. See below from section 5.2.2
>=20
>    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.
>=20
> 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.=20

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.           =20
>=20
> 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.  =20
>=20
> 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. =20

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.
    =20
>=20
> In other cases, where the model described in section 5.2.2 is not
> used, a CCR initial counter would be incremented.=20
>=20
> BTW, do you plan to have different counters for different CCR types
> (initial, update, termination)?=20

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