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

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 14 Jun 2006 17:58:41 -0700

In the process of attempting to construct a MIB for the credit control
application, I have been trying to figure out which messages from
Diameter base are used by DCCA, so that they can be counted
appropriately.  Some are obvious: STR/STA & RAR/RAA, for example.  One
has me rather puzzled, though: the AAR/AAA exchange is explicitly listed
in the first state machine in section 7 as being sent/received by the
CCA client, but the AVPs allowed in AAR/AAA are not listed in section 10
(though the APS for RAR/RAA ARE).  Does the CCA client actually
send/receive AAR/AAA (i.e., should the be counted in the DCCA MIB) or
not?

~gwz

Treat the Earth well. 
It was not given to you by your parents.
It was loaned to you by your children.
  -- Kenyan Proverb

Humankind has not woven the web of life.
We are but one thread within it.
Whatever we do to the web, we do to ourselves.
All things are bound together.
All things connect.
  -- Chief Seattle

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Harri Hakala \(TU/LMF\)" <[email-masked]>
Date: Thu, 15 Jun 2006 09:06:08 +0200

Hi Glen,

The DCCA document defines two different approaches to perform the first credit control 
interrogation to be used in different network architectures. The first approach 
uses credit-control messages after the user's authorization and authentication 
takes place. The second approach uses service specific authorization messages 
(such as AAA/AAR) to perform the first interrogation during the user's 
authorization/authentication phase, and credit-control messages for the 
intermediate and final interrogations. 

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.

If the CCA client supports the second approach and e.g. NASREQ is used for service
authorization, then the CCA client sends/receives AAR/AAA messages.

As this "AA Request/AA Answer" is a general message, not explicit NASREQ message, 
we did not include it the table in section 10. 

regards............Harri

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: 15. kesäkuuta 2006 3:59
> To: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF); 
> [email-masked]; [email-masked]; 
> [email-masked]
> Cc: Glen Zorn (gwz); [email-masked]; [email-masked]
> Subject: Diameter base protocol messages used by DCCA
> 
> In the process of attempting to construct a MIB for the 
> credit control application, I have been trying to figure out 
> which messages from Diameter base are used by DCCA, so that 
> they can be counted appropriately.  Some are obvious: STR/STA 
> & RAR/RAA, for example.  One has me rather puzzled, though: 
> the AAR/AAA exchange is explicitly listed in the first state 
> machine in section 7 as being sent/received by the CCA 
> client, but the AVPs allowed in AAR/AAA are not listed in 
> section 10 (though the APS for RAR/RAA ARE).  Does the CCA 
> client actually send/receive AAR/AAA (i.e., should the be 
> counted in the DCCA MIB) or not?
> 
> ~gwz
> 
> Treat the Earth well.

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Fri, 16 Jun 2006 10:48:10 +0200

>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:[email-masked]] 
Sent: giovedì 15 giugno 2006 22.21
To: Anders Kristensen
Cc: [email-masked]; [email-masked]
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

> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Thursday, June 15, 2006 4:38 PM
> To: Tolga Asveren
> Cc: [email-masked]; [email-masked]
> 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.
> >
> >
> >>From: Anders Kristensen [mailto:[email-masked]]
> >>Sent: Thursday, June 15, 2006 4:13 PM
> >>To: Glen Zorn (gwz)
> >>Cc: [email-masked]; [email-masked];
> >>[email-masked]; [email-masked]; [email-masked]
> >>Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA
> >>
> >>
> >>
> >>
> >>Glen Zorn (gwz) wrote:
> >>
> >>>Harri Hakala (TU/LMF) <mailto:[email-masked]>
> >>
> >>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
> >>>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
> >>>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 16 Jun 2006 09:43:30 -0700

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

>> Actualy, shouldn't ApplicationId in the message header be 4
>> (ApplicationId for DCCA) , for such an AAR?
> 
>    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
> 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. 
> 

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

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Wed, 21 Jun 2006 12:10:55 +0200

Hi Glen,

Sorry for the late answer I was in business trip with no access to my
emails.

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

Not necessarily. One could provide communication means to enable a CCA
functionality module to add relevant AVPs to the initial AA request and
process relevant AVPs from AA answer.

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

One time events always use CCR/CCA messages. In section 6 of RFC4006 it
is stated in first paragraph "The use of a one-time event implies
   that the user has been authenticated and authorized beforehand."

Examples of one time event usage are given in Flow III, IV and V within
the appendix.

One time event uses Request-type of EVENT.

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

I'm afraid DCCA MIB should be able at least to differentiate between
EVENT, INITIAL, UPDATE and TERMINATION requests.
If you want to go further and also count what type of event the request
was sent for then you would need to consider the Requested-Action.

However, all these are unfortunately DCCA specific AVP based
information.

Regards
Marco

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 25 Jun 2006 18:35:13 -0700

...

> Not necessarily. One could provide communication means to enable a
> CCA functionality module to add relevant AVPs to the initial AA
> request and process relevant AVPs from AA answer.  

Maybe it's just me but that distinction seems to be, at best, razor-thin.  What you are saying is that every peer must make concessions to CCA.  

...

~gwz