Subject: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Wed, 10 Dec 2003 14:56:37 +0100

DCC Service-specific Rating Input and Interoperability
Submitter name: Harri Hakala
Submitter email address: [email-masked]
Date first submitted: 10.12.2003
Reference: 
Document: Diameter CCA-01
Comment type: T
Priority: 2
Section: 
Rationale/Explanation of issue:

To clarify cca interoperability and how to provide service specific
rating input, we propose to change the existing 4.1 section to 
this new 4.1 section.

Proposed changed:
Replace the exiting 4.1 (Rating Input) section with this one:

4.1 Service-specific Rating Input and Interoperability

The Diameter Credit Control Application provides generic credit 
control mechanisms supporting multiple service applications. The 
Credit Control Application, therefore, does not define AVPs that could 
be used as input in the rating process. Listing the possible services 
that could use this Diameter application is seen as out of scope
for this generic mechanism as well.

It is reasonable to expect that there will exist a service level agreement
between providers of the credit control client and the credit control
server covering the charging, services offered, roaming agreements, 
agreed rating input, etc.

There are two ways for providing rating input to the credit control 
server, either by using AVPs or by including them in the Service-
Parameter-Info AVP. The general principle for sending rating 
parameters is that the service SHOULD re-use existing AVPs, if the  
service can use AVPs defined in existing service specific Diameter 
applications (e.g. NASREQ for network access services). 
Alternatively, new AVPs can be defined if the existing AVPs do not
provide sufficient rating information. The Service-Parameter-Info AVP 
MAY be used as a container to pass legacy rating information in its 
original encoded form (e.g. ASN.1 BER). In that case the rating input 
is embedded in the Service-Parameter-Info AVP as defined in section 8.23. 
New service applications SHOULD favor the use of explicitly defined 
AVP's, to simplify interoperability.

Additionally, the services can be identified using the Service-Identifier AVP
that SHOULD be a unique identifier for a given service as defined in section
8.40.

The service specific rating input AVPs, the contents of the 
Service-Parameter-Info AVP or Service-Identifier AVP are not within 
the scope of this document. To facilitate interoperability, it is RECOMMENDED 
that the rating input and values of service identifiers are coordinated via
an informational RFC or other permanent and readily available reference 
such as the specification of another cooperative standardization body 
(e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private services may 
be deployed that are subject to agreements between providers of the credit 
control server and client.

Within a credit control request, setting the "M" bit implies that a 
rating server or the credit control server itself SHOULD understand 
the AVP in order to rate the service. However, since different 
service providers may apply different rating policies a mandatory 
input parameter for one server might be irrelevant for another. 
Therefore, if the AVP is not relevant to the rating process, when the 
AVP is included within a credit-control request, it can be ignored, 
even if the "M" bit is set. 
      
In case a rating input required for the rating process is missing from 
the Credit control request, the Credit control answer MUST contain 
error code DIAMETER_RATING_FAILED. A CCR message with this error MUST 
contain one or more Failed-AVP AVPs containing the missing AVPs that 
caused the failure.