Subject: RE: [AAA-WG]: RE:

From: <[email-masked]>
Date: Mon, 5 Jul 2004 13:37:52 +0300

BTW, I forgot one additional thing related to this.

Because the Service-Identifier AVP MUST be include in CCR and it
is used to determine if the request can be honored, is to
be include in curly brakets in the ABNF of the command and shall
be as closed to the header as possible. Therefore we also
updated section 3.1 as follow:

 <Credit-Control-Request> ::= < Diameter Header: xxx, REQ, PXY > 
                                     < Session-Id > 
                                     { Origin-Host } 
                                     { Origin-Realm } 
                                     { Destination-Realm } 
                                     { Auth-Application-Id }
                                     { Service-Identifier } 
                                     { CC-Request-Type } 
                                     { CC-Request-Number } 
                                     [ Destination-Host ] 
                                     [ User-Name ] 
                                     ........

Marco

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext 
> Sent: 05 July, 2004 11:09
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AAA-WG]: RE: 
> 
> 
> 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
> > 
> > 
>