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

["STURA, Marco, VF-IT" <Marco.STURA at vodafone.com>]

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

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)?

Regards
Marco

-----Original Message-----
From: Tolga Asveren [mailto:asveren at ulticom.com] 
Sent: giovedì 15 giugno 2006 22.21
To: Anders Kristensen
Cc: aaa-wg at merit.edu; dime at ietf.org
Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA

Actualy, shouldn't ApplicationId in the message header be 4 (ApplicationId
for DCCA) , for such an AAR?

    Tolga

> -----Original Message-----
> From: Anders Kristensen [mailto:andersk at cisco.com]
> Sent: Thursday, June 15, 2006 4:38 PM
> To: Tolga Asveren
> Cc: aaa-wg at merit.edu; dime at ietf.org
> Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA
>
>
> OK, so at least there's a way to tell which app the AAR really is for.
> In my view it's a poor solution, though, since the code maintaining peg
> counts could very well belong to a generic Diameter stack which doesn't
> necessarily know about the particulars of DCCA. It's sort of reasonable
> to expect the stack to do something on the basis of Auth-Application-Id
> but not really for DCCA specific AVPs. It makes it unnecessarily
> difficult to layer the server code.
>
> Thanks,
> Anders
>
> Tolga Asveren wrote:
>
> > RFC4006 5.2.2 states that Credit-Control AVP  MUST be added to AAR to
> > indicate credit-control capabilities.
> >
> >
> >>-----Original Message-----
> >>From: Anders Kristensen [mailto:andersk at cisco.com]
> >>Sent: Thursday, June 15, 2006 4:13 PM
> >>To: Glen Zorn (gwz)
> >>Cc: John.Loughney at nokia.com; aaa-wg at merit.edu;
> >>juha-pekka.koskinen at nokia.com; dime at ietf.org; marco.stura at nokia.com
> >>Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA
> >>
> >>
> >>
> >>
> >>Glen Zorn (gwz) wrote:
> >>
> >>>Harri Hakala (TU/LMF) <mailto:harri.hakala at ericsson.com>
> >>
> >>supposedly scribbled:
> >>
> >>>...
> >>>
> >>>
> >>>
> >>>>AA Request/AA Answer are not necessarily equal to AAR/AAA messages in
> >>>>NASREQ but they mean in DCCA document a general
> >>>>authorization/authentication request/answer in any Diameter
> >>>>authorization/authentication application. Bad name example, as it
> >>>>seems to collide with the message name in NASREQ.
> >>>>
> >>>
> >>>
> >>>This would seem to make it quite difficult to monitor/manage
> >>
> >>DCCA via SNMP, since presumably one would wish to keep track of
> >>all the interrogations & the generic auth message is actually the
> >>first interrogation.   This implies that all & any such messages
> >>should be allocated a counter in the DCCA MIB, but the membership
> >>of this set of messages is not static.  Any suggestions?
> >>
> >>Have clients include an Auth-Application-Id AVP in the AAR with the DCC
> >>app id? It's not clear to me from the specs whether this is the
> >>intention or not but IMHO there really ought to be a way for the server
> >>to tell whether the AAR is for a NAS or DCC session - not just for
> >>management reasons.
> >>
> >>Anders
> >>
> >>
> >>>...
> >>>
> >>>~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
> >>>
> >>
> >>_______________________________________________
> >>DiME mailing list
> >>DiME at ietf.org
> >>https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >


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


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