Subject: [Dime] The usage of ACR/ACA for the QoS application

From: "Ulf Bodin" <[email-masked]>
Date: Wed, 25 Jul 2007 23:21:47 +0200

All, 

This might be an uneducated question from someone that just now have
read the draft, but the usage of the ACR/ACA messages for the QoS
application confuses me somewhat. To my understanding the current draft
mandates the use of those messages and thereby manadate the authorizing
entity to also handle accounting. I'm not sure that's always the case.
E.g. in the 3GPP architecture the PCRF and the online charging system
are possible to instasiate separately in a physical deplyment. If my
understanding is correct I would then actually suggest to allow for
separating authorization and accounting in the QoS application.
Comments/thoughts? Again, I may miss the point completely here and then
I clearly need someone to enlight me ;-). 

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

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 26 Jul 2007 15:17:16 -0400

Hi, Ulf,

The current draft puts some cost-information AVPs in the QAR,
and the Authorizing Entity gets to see those before authorization.
So, it just seems logical to me that the accounting should go
to the same place.

In theory, we could put an AVP into the QAR containing the
destination for subsequent ACRs.  However, it seems like the
recipient of an ACR will want to verify that the session was
indeed authorized, so this would imply some non-standard 
interface between the two.

All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc)
use accounting in this way, and I don't see a good reason to
break with that.

-Pete

Ulf Bodin wrote:
> application confuses me somewhat. To my understanding the current
> draft mandates the use of those messages and thereby manadate the
> authorizing entity to also handle accounting. I'm not sure that's
> always the case. E.g. in the 3GPP architecture the PCRF and the
> online charging system are possible to instasiate separately in a
> physical deplyment. If my understanding is correct I would then
> actually suggest to allow for separating authorization and accounting
> in the QoS application. Comments/thoughts? Again, I may miss the
> point completely here and then I clearly need someone to enlight me
> ;-).           
> 
> Best regards,
> Ulf

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 26 Jul 2007 15:23:58 -0400

McCann Peter-A001034 wrote:
> Hi, Ulf,
> 
> The current draft puts some cost-information AVPs in the QAR, and the
> Authorizing Entity gets to see those before authorization. 
> So, it just seems logical to me that the accounting should go to the
> same place. 
> 

Sorry, meant to say "into the QAA".

> recipient of an ACR will want to verify that the session was indeed
> authorized, so this would imply some non-standard interface between
> the two.    
> 
> All of the mainstream Diameter protocols (NASREQ, Mobile IP, etc) use
> accounting in this way, and I don't see a good reason to break with
> that.  
> 
> -Pete
> 
> Ulf Bodin wrote:
>> All,
>> 
>> actually suggest to allow for separating authorization and
>> accounting in the QoS application. Comments/thoughts? Again, I may
>> miss the point completely here and then I clearly need someone to
>> enlight me ;-). 
>> 
>> Best regards,
>> Ulf
> 
>

---

From: "Ulf Bodin" <[email-masked]>
Date: Thu, 26 Jul 2007 22:03:48 +0200

Hi Pete, 

Thanks for the clearification. I'm however still a little confused.
Looking at the credit control application I found that the accounting
protocol and the credit control protocol can be used in parallel more or
less in the manner I'm envisioning and how I understand the usage of the
3GPP protocols/interfaces Gx and Gy (I'm not an expert on 3GPP though
and may be on thin ice here). From that I would have expected the QoS
application to also allow for a similar parallelism. Or, is there a
fundamental difference I have missed here?

Best regards, 
Ulf 

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]] 
Sent: den 26 juli 2007 21:24
To: Ulf Bodin; [email-masked]
Subject: RE: [Dime] The usage of ACR/ACA for the QoS application 

> destination for subsequent ACRs.  However, it seems like the recipient

> of an ACR will want to verify that the session was indeed authorized, 
> so this would imply some non-standard interface between
> the two.    
>

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 26 Jul 2007 15:23:04 -0500

I have similar confusion as Ulf. It looks like QoS authorization,
accounting and credit control functions are mixed in this QoS
application, and it is a bit awkward to mandate accounting server
capability within an QoS application. 

It seems in reality the accounting server and QoS authorization server
are independent entities although they might be collocated if needed,
and the credit and accounting permission may not be necessary to be
prerequisite for QoS authorization. Would it be more flexible to
separate the accounting server and credit control function from QoS
authorization server/application? 

Certainly, if some QoS info is needed for policy decision, it can be
carried by an QoS message such as QAR/QIA to QoS authorization server
instead of ACR.

Regards,
Dong  

-----Original Message-----
From: Ulf Bodin [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 4:04 PM
To: [email-masked]
Subject: RE: [Dime] The usage of ACR/ACA for the QoS application 

Hi Pete, 

Best regards,
Ulf

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 26 Jul 2007 19:18:26 -0400

Hi, Dong, Ulf,

The mechanism described in the draft is simple and self-contained,
only referring to some AVPs defined by the credit control application.
RFC 4006 is more complicated than necessary.  We decided to include
a simple, per-minute charging system that can support time of tarrif
changes, allows the NE to specify the cost, and send the accounting
records into the Diameter network.  Section 5 is really simple and
I think it provides all the functionality we need for QoS accounting.

-Pete

Sun, Dong (Dong) wrote:
> It seems in reality the accounting server and QoS authorization
> server are independent entities although they might be collocated if
> needed, and the credit and accounting permission may not be necessary
> to be prerequisite for QoS authorization. Would it be more flexible
> to separate the accounting server and credit control function from
> QoS authorization server/application?     
> 
> protocol and the credit control protocol can be used in parallel more
> or less in the manner I'm envisioning and how I understand the usage
> of the 3GPP protocols/interfaces Gx and Gy (I'm not an expert on 3GPP
> though and may be on thin ice here). From that I would have expected
> the QoS application to also allow for a similar parallelism. Or, is
> there a fundamental difference I have missed here?      
> 
> Best regards,
> Ulf
> 
>> recipient 
>>> accounting

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 26 Jul 2007 18:36:08 -0500

Hi Pete,

It's ok to me to carry certain accounting info for QoS authorization,
but not sure if it is good approach to maintain an accounting entity and
session for it. Looks like a bit overshot. 

In addition, what's the relationship between this mini accounting entity
and full-blown accounting server? What's the problem to just carry the
QoS accounting info via QoS commands if needed?

Regards,
Dong

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 7:18 PM
To: Sun, Dong (Dong); [email-masked]
Subject: RE: [Dime] The usage of ACR/ACA for the QoS application 

Hi, Dong, Ulf,

The mechanism described in the draft is simple and self-contained, only
referring to some AVPs defined by the credit control application.
RFC 4006 is more complicated than necessary.  We decided to include a
simple, per-minute charging system that can support time of tarrif
changes, allows the NE to specify the cost, and send the accounting
records into the Diameter network.  Section 5 is really simple and I
think it provides all the functionality we need for QoS accounting.

-Pete

> separate the accounting server and credit control function from

>> so this would imply some non-standard interface between the two.
>>