Subject: [AAA-WG]: RE:

From: <[email-masked]>
Date: Mon, 5 Jul 2004 11:09:12 +0300

Glen,

the Service-Id is only included in CCR message (at command level) to indicate 
to the server for what specific service the request is being issued.
The server checks first the Service-Id AVP and, if it doesn't recognize
the value of this AVP, it rejects the request without any further processing
(e.g. rating or what so ever). If the server recognizes the value of the
Service-Id AVP, it continues the processing and authorizes the credit if
possible (i.e. if there is enough credit in the user's account).  

The section 4.1 has been restructured on request of IESG review as follow, the
inclusion of the Service-Id in CCR is mandatory.

Whenever the IESG and the ADs will agree that their comments have been properly
addressed, the draft 06 will be carried out and made available.

Regards
Marco 

4.1 Service-Specific Rating Input and Interoperability 
    
   The Diameter Credit-Control Application defines the framework for credit 
   control; it 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.  
    
   Furthermore, 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 (i.e. AVPs), etc. 

   Therefore, it is assumed that a Diameter credit control server will 
   provide service only for Diameter credit-control clients that have agreed 
   beforehand the content of credit control messages. Protocol wise, it is 
   naturally possible that any arbitrary Diameter credit-control client can 
   interchange credit control messages with any Diameter credit control 
   server, but with a higher likelihood that unsupported services/AVPs could 
   be present in the credit-control message causing the server to reject the 
   request with an appropriate result-code. 
    
4.1.1 Specifying Rating Input AVPs 
    
   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 principles for sending rating parameters 
   are: 
    
   1a. The service SHOULD re-use existing AVPs, if the service can use AVPs 
       defined in existing Diameter applications (e.g. NASREQ for network 
       access services). Re-use of existing AVPs is strongly recommended in 
       [DIAMBASE]. 

       For AVPs of type Enumerated the service may require a new value to be 
       defined. Allocation of new AVP values is done as specified in 
       [DIAMBASE], section 1.2. 
    
   1b. New AVPs can be defined if the existing AVPs do not provide sufficient 
       rating information. In such a case, the procedures defined in 
       [DIAMBASE] for creating new AVPs MUST be followed. 
    
   1c. For services specific only to one vendor's implementation, a Vendor- 
       Specific AVP code for Private use can be used. Where a Vendor-Specific 
       AVP is implemented by more than one vendor, allocation of global AVPs 
       are encouraged instead, refer to [DIAMBASE]. 
    
   2. 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). This method can be used to avoid unnecessary data format 
      conversions from an existing format to an AVP format. In that case the 
      rating input is embedded in the Service-Parameter-Info AVP as defined 
      in section 8.42. 
    
   New service applications SHOULD favor the use of explicitly defined AVPs 
   as described in items 1a and 1b, to simplify interoperability.  
    
4.1.2 Application Support 
    
   Since the Application-Id of the Diameter Credit Control Application does 
   not uniquely identify the service being monitored, an additional mechanism 
   is needed. The service application MUST be identified using the Service-
   Identifier AVP at command level. A server receiving a request for a 
   service application it does not support will reject the request as defined 
   in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique 
   identifier for a given service as defined in section 8.28.  
    
   Thus, the combination of the Diameter Credit Control Application-Id and 
   the Service-Identifier AVP in the Credit-Control-Request command uniquely 
   defines the service within the context of the Diameter Credit Control, and 
   hence provides interoperability between Diameter credit control clients 
   and server. 
    
   With this mechanism it is possible to cover additional service specific 
   requirements as needed in other documents. However, introducing new credit 
   control mechanisms to the framework defined in this specification, require 
   definition of a new version of the Diameter Credit Control Application and 
   corresponding Application Identifier. 
    
4.1.3 Service-Specific Documentation 
     
   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 the values of the 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, in this case vendor specific AVPs can be used.  
        
   This specification, together with the above service specific documents, 
   governs the credit control message. The rule is that service specific 
   documents define what existing AVPs or new AVPs are used as input to the 
   rating process (i.e. they do not define new credit control applications), 
   and thus need to be included in the Credit-Control-Request command by a 
   Diameter Credit Control Client supporting a given service as *[AVP]. 
   Should Service-Parameter-Info be used, then the service specific document 
   MUST specify the exact content of this grouped AVP. 
    
4.1.4 Handling of Unsupported/Incorrect Rating Input  
    
   Diameter credit control implementations are required to support the 
   Mandatory rating AVPs defined in service specific documentation of the 
   services they support according to the 'M' bit rules in [DIAMBASE].  
        
   In case a rating input required for the rating process is incorrect in the 
   Credit control request, or the credit control server does not support the 
   requested service (identified by the Service-Idntifier AVP at command 
   level), 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 and/or unsupported AVPs that 
   caused the failure. A Diameter credit control client receiving error code 
   DIAMETER_RATING_FAILED in answer to a request MUST NOT send such similar 
   requests in the future. 
    
4.1.5 RADIUS Vendor-Specific Rating Attributes 
        
   When service specific documents include RADIUS vendor specific attributes 
   that could be used as input in the rating process, the rules described in 
   [NASREQ] for formatting the Diameter AVP MUST be followed. For example, 
   the AVP code used is the vendor attribute type code, the Vendor-Specific 
   flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor 
   identification value. The Diameter AVP data field contains only the 
   attribute value of the RADIUS attribute.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Glen Zorn
> Sent: 02 July, 2004 20:27
> To: [email-masked]
> Subject: 
> 
> 
> Description of issue:  No guarantee of interoperability 
> between CCA implementations
> Submitter name: Glen Zorn
> Submitter email address: [email-masked] 
> Date first submitted: 2 July 2004 
> Document: dcca 
> Comment type: T
> Priority: S
> Section: 4.1
> Rationale/Explanation of issue: 
> In order to interoperate, Diameter peers implementing the 
> Diameter Credit Control Application must agree upon both the 
> application and the service (specified in the 
> Service-Identifier AVP).  However, the inclusion of the 
> Service-Identifier in the CCR and CCA messages is optional.
> 
> Lengthy description of problem:
> Section 4.1, para. 6 states "it is the combination of support 
> of the Diameter Credit Control Application and the service 
> defined in the Service-Identifier AVP, which defines 
> interoperability between any given credit control client and 
> server."  However, the inclusion of the Service-Identifier in 
> the CCR and CCA messages is optional.  This gives rise to a 
> situation where two peers implementing the same application 
> may not interoperate because they do not implement the same 
> "service", and further, refuse to clearly communicate that fact.
> 
> Requested change: 
> Change section 4.1, paragraph 5 from
> 
>    This specification, together with service specific documents, is 
>    governing the credit control message. The rule is that service 
>    specific documents only define what existing AVPs or new AVPs are 
>    used as input to the rating process (i.e. they do not define new 
>    credit control applications), and thus need to be included in the 
>    Credit-Control-Request command by a Diameter Credit Control Client 
>    supporting a given service as *[AVP]. In order to define new AVPs, 
>    service specific documents MUST follow the practices defined in 
>    [DIAMBASE]. The service SHOULD be identified using the Service- 
>    Identifier AVP. The Service-Identifier AVP MUST be a unique 
>    identifier for a given service as defined in section 8.28. 
> 
> to
> 
>    This specification, together with service specific documents, is 
>    governing the credit control message. The rule is that service 
>    specific documents only define what existing AVPs or new AVPs are 
>    used as input to the rating process (i.e. they do not define new 
>    credit control applications), and thus need to be included in the 
>    Credit-Control-Request command by a Diameter Credit Control Client 
>    supporting a given service as *[AVP]. In order to define new AVPs, 
>    service specific documents MUST follow the practices defined in 
>    [DIAMBASE]. The service MUST be identified using the Service- 
>    Identifier AVP. The Service-Identifier AVP MUST be a unique 
>    identifier for a given service as defined in section 8.28. 
> 
> ~gwz
> 
> "They that can give up essential liberty to obtain a little 
> temporary safety deserve neither..."
> -- Benjamin Franklin, 1759 
> 
> 
> "It is forbidden to kill; therefore all murderers are 
> punished unless they kill in large numbers and to the sound 
> of trumpets."
> -- Voltaire
> 
>