Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

From: "Mark Watson" <[email-masked]>
Date: Tue, 6 Jul 2004 16:08:13 +0100

Hi Marco,

Some quick questions for clarification on this one...

1) If the client wants to request quotas for multiple services using the
Multiple-Services-Credit-Control AVP then what should it put in the
mandatory command level Service-Identifier AVP ?

2) Service-Identifier is finer granlarity than Rating-Group - that is
several services with unique Service-Identifiers are grouped within a single
Rating-Group. So a 'service' identified by a Service-Identifier is basically
the finest granularity thing that can be separately charged.

But then the definition of the Service Identifier AVP speaks of statically
configured or standardised values. To be consistent with the above it would
need to be a format or pattern than was configured/standardised - e.g. if
it's voice calls that you are charging for then Service Identifies like
[email-masked]', [email-masked]' would be needed to distinguish
between multiple concurrent voice calls.

Right ?

3) It isn't possible to request credit for a Rating-Group except by using
the Multiple-Services-Credit-Control AVP, right ?

Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 05 July 2004 09: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
> 
>

---

From: "Mark Grayson (mgrayson)" <[email-masked]>
Date: Tue, 6 Jul 2004 17:44:21 +0200

Mark, Marco
 
I hadn't made the same assumption - but agree that there is ambiguity
here.
 
I had asumed that when present on the command level, the service-ID
refers to the "rating-root" which then needs to be common between client
and serer. 
 
Then the issue exists with re-introducing the service-ID at the MSCC
level, now possibly below the sub-session-ID which I think is the cause
of the issue. IMO these AVPs at the MSCC level should be subordinate to
the service-ID on the command level.
 
Cheers,
Mark

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Watson
Sent: 06 July 2004 11:08
To: [email-masked]'
Cc: [email-masked]'; Glen Zorn (gwz); Claire Mousset
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Marco, 

2) Service-Identifier is finer granlarity than Rating-Group - that is
several services with unique Service-Identifiers are grouped within a
single Rating-Group. So a 'service' identified by a Service-Identifier
is basically the finest granularity thing that can be separately
charged.

But then the definition of the Service Identifier AVP speaks of
statically configured or standardised values. To be consistent with the
above it would need to be a format or pattern than was
configured/standardised - e.g. if it's voice calls that you are charging
for then Service Identifies like [email-masked]',
[email-masked]' would be needed to distinguish between multiple
concurrent voice calls.

Right ? 

3) It isn't possible to request credit for a Rating-Group except by
using the Multiple-Services-Credit-Control AVP, right ?

Regards...Mark 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: 05 July 2004 09:09 
To: [email-masked] 
Cc: [email-masked] 
Subject: [AAA-WG]: RE: 

Glen, 

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

Regards 
Marco 

   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. 

   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. 

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

      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.  

   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. 

   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. 

   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. 

   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.

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 6 Jul 2004 17:21:04 +0100

Hi Mark,
 
Note sure what you mean by a 'rating-root', but it is quite clear (e.g. in
the diagrams in 5.1.1) that 'services' are sub-ordinate to Rating-Groups.
Since everything in a Rating-Group is rated the same way then certainly you
cannot have things within a service which are rated differently. That is,
services are the finest level of granularity that can be separately charged.
 
The point of MSCC was to do in one message what could otherwise be done with
several messages and only command level values - so I would expect the
things appearing in the MSCC to have the same semantics as things appearing
at command level & for the two to be mutually exclusive - hence Question 1
below.
 
To answre my question (2) below for myself, we don't need multiple instances
of the same service within a single sub-session. In 3GPP, I think we may
have a requirement for dynamically povisioned services, but the dynamic
provisioning of these to DCC client & server is out of scope here & so there
should be no problem.
 
...Mark

-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:[email-masked]] 
Sent: 06 July 2004 16:44
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Mark, Marco
 
I hadn't made the same assumption - but agree that there is ambiguity here.
 
I had asumed that when present on the command level, the service-ID refers
to the "rating-root" which then needs to be common between client and serer.

Then the issue exists with re-introducing the service-ID at the MSCC level,
now possibly below the sub-session-ID which I think is the cause of the
issue. IMO these AVPs at the MSCC level should be subordinate to the
service-ID on the command level.
 
Cheers,
Mark

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Watson
Sent: 06 July 2004 11:08
To: [email-masked]'
Cc: [email-masked]'; Glen Zorn (gwz); Claire Mousset
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Marco, 

Right ? 

Regards...Mark 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 05 July 2004 09:09 
To: [email-masked] 
Cc: [email-masked] 
Subject: [AAA-WG]: RE: 

Glen, 

Regards 
Marco 

    

    

    

    

    

    

    

    

> [mailto:[email-masked] <mailto:[email-masked]> ]On Behalf
Of

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Wed, 7 Jul 2004 14:20:46 +0200

Re-posting this because of mail delivery problems. Sorry if you receive this twice.

BR,
Leena

-----Original Message-----
Hi,

when the MSCC concept was introduced I always had the
assumption that the services within the MSCC structure are 
sub-ordinate to some higher level service, e.g. Network Access.
Having said that, it's also true that what one can do with MSCC one should be able 
to do with several messages (that's where the MSCC issue initially
started). However, I still believe that those several 
messages are inter-related (otherwise you wouldn't group them 
in the same message, right?), and thus the exact formulation 
would be 'what one can do with MSCC one should be able to do 
with sub-sessions'. Hence the analogy between the two approaches is:
- when using the MSCC the Service-ID on command level is the 
main service, e.g. Network access, and the Service-Ids within 
the MSCC then identify the sub-services within the main service
- when using sub-sessions the Service-ID in 'main' session is 
the main service and the Service-Ids in sub-sessions (on 
command level) are the sub-services.
If there is no common factor between the Service-IDs one has 
grouped within one MSCC, then I think they should not be 
grouped together at all, they are then clearly not sub-ordinate
services (e.g. not carried within the same bearer) and should 
treat them as such - optimizing signaling 
should not be the only justification for doing the grouping. 
And when there is a common factor, that factor should become 
the Service-ID on command level.

Regarding the question (3): I'll put it the other way around: 
At the moment it's not possible to have rating groups on 
command level but do you see a need for it? 

Regards,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Watson
Sent: 6. heinäkuuta 2004 19:21
To: 'Mark Grayson (mgrayson)'; [email-masked]'
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Mark,

Note sure what you mean by a 'rating-root', but it is quite clear (e.g. in the diagrams in 5.1.1) that 'services' are sub-ordinate to Rating-Groups. Since everything in a Rating-Group is rated the same way then certainly you cannot have things within a service which are rated differently. That is, services are the finest level of granularity that can be separately charged.

The point of MSCC was to do in one message what could otherwise be done with several messages and only command level values - so I would expect the things appearing in the MSCC to have the same semantics as things appearing at command level & for the two to be mutually exclusive - hence Question 1 below.

To answre my question (2) below for myself, we don't need multiple instances of the same service within a single sub-session. In 3GPP, I think we may have a requirement for dynamically povisioned services, but the dynamic provisioning of these to DCC client & server is out of scope here & so there should be no problem.

...Mark
-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:[email-masked]] 
Sent: 06 July 2004 16:44
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Mark, Marco

I had asumed that when present on the command level, the service-ID refers to the "rating-root" which then needs to be common between client and serer. 

Then the issue exists with re-introducing the service-ID at the MSCC level, now possibly below the sub-session-ID which I think is the cause of the issue. IMO these AVPs at the MSCC level should be subordinate to the service-ID on the command level.

Cheers,
Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Watson
Sent: 06 July 2004 11:08
To: [email-masked]'
Cc: [email-masked]'; Glen Zorn (gwz); Claire Mousset
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Marco, 
Some quick questions for clarification on this one... 
1) If the client wants to request quotas for multiple services using the Multiple-Services-Credit-Control AVP then what should it put in the mandatory command level Service-Identifier AVP ?
2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged.
But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like [email-masked]', [email-masked]' would be needed to distinguish between multiple concurrent voice calls.
Right ? 
3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ?
Regards...Mark 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: 05 July 2004 09: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.  

    

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

    
    
   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. 

   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.  

    
        
   In case a rating input required for the rating process is incorrect in the

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 7 Jul 2004 13:29:09 +0100

Hi Leena,

You wrote:

"- when using the MSCC the Service-ID on command level is the 
main service, e.g. Network access, and the Service-Ids within 
the MSCC then identify the sub-services within the main service"

This sounds very reasonable to me, but it is not what the specification
seems to imply. There is no concept in the spec of 'services' being
'sub-ordinate' to other 'services'. Furthermore, the fact that a 'service'
is sub-ordinate to Rating-Group implies that everything within a service has
to be rated the same. So then even if there were sub-services within a 'main
service' they would all have to be within the same Rating-Group!

But if people feel it's clear that there can be such a thing as a 'main
service' which is not part of any Rating Group and which has sub-services,
then that seems fine to me.

As for (3), it doesn't seem a big deal, but does seem arbitrary - if I want
to request a quota for a single Rating-Group (which is probably the most
common case in 3GPP anyway) I need to use MSCC.

...Mark

-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: 07 July 2004 12:00
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)';
[email-masked]'
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi,

when the MSCC concept was introduced I always had the assumption that the
services within the MSCC structure are 
sub-ordinate to some higher level service, e.g. Network Access. Having said
that, it's also true that what one can do with MSCC one should be able 
to do with several messages (that's where the MSCC issue initially started).
However, I still believe that those several 
messages are inter-related (otherwise you wouldn't group them 
in the same message, right?), and thus the exact formulation 
would be 'what one can do with MSCC one should be able to do 
with sub-sessions'. Hence the analogy between the two approaches is:
- when using the MSCC the Service-ID on command level is the 
main service, e.g. Network access, and the Service-Ids within 
the MSCC then identify the sub-services within the main service
- when using sub-sessions the Service-ID in 'main' session is 
the main service and the Service-Ids in sub-sessions (on 
command level) are the sub-services.
If there is no common factor between the Service-IDs one has 
grouped within one MSCC, then I think they should not be 
grouped together at all, they are then clearly not sub-ordinate services
(e.g. not carried within the same bearer) and should 
treat them as such - optimizing signaling 
should not be the only justification for doing the grouping. 
And when there is a common factor, that factor should become 
the Service-ID on command level.

Regards,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mark Watson

Hi Mark,

...Mark
-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:[email-masked]] 
Sent: 06 July 2004 16:44
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Mark, Marco

Cheers,
Mark

Hi Marco, 
Some quick questions for clarification on this one... 
1) If the client wants to request quotas for multiple services using the
Multiple-Services-Credit-Control AVP then what should it put in the
mandatory command level Service-Identifier AVP ?
2) Service-Identifier is finer granlarity than Rating-Group - that is
several services with unique Service-Identifiers are grouped within a single
Rating-Group. So a 'service' identified by a Service-Identifier is basically
the finest granularity thing that can be separately charged. But then the
definition of the Service Identifier AVP speaks of statically configured or
standardised values. To be consistent with the above it would need to be a
format or pattern than was configured/standardised - e.g. if it's voice
calls that you are charging for then Service Identifies like
[email-masked]', [email-masked]' would be needed to distinguish
between multiple concurrent voice calls. Right ? 
3) It isn't possible to request credit for a Rating-Group except by using
the Multiple-Services-Credit-Control AVP, right ? Regards...Mark 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: 05 July 2004 09: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

---

From: <[email-masked]>
Date: Wed, 7 Jul 2004 16:10:11 +0300

Hi,
 
some comment in line.
 
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 07 July, 2004 15:29
To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson (mgrayson)'; Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Leena, 

You wrote: 

This sounds very reasonable to me, but it is not what the specification seems to imply. There is no concept in the spec of 'services' being 'sub-ordinate' to other 'services'. Furthermore, the fact that a 'service' is sub-ordinate to Rating-Group implies that everything within a service has to be rated the same. So then even if there were sub-services within a 'main service' they would all have to be within the same Rating-Group! 

 But if people feel it's clear that there can be such a thing as a 'main service' which is not part of any Rating Group and which has sub-services, then that seems fine to me.  

Mark, I guess you are referring to the picture in sect. 5.1.1. Right? If so, this picture was intended to only describe the MSCC concept, what Leena is mentioning is probably not visible in that picture. The main service is a service of its own that represent for instance the bearer, in which many other services may be carried and may have different costs, and is not part of any RG. This 'main service' id also identifies the service specific document with mandatory AVPs that need to be supported, for instance the Flow bearer charging defined in 3GPP ideally would have the 'main service' identifier something like [email-masked].

Would you have good suggestion for better text in section 5.1.1 and perhaps in the new 4.12 to remove any dubt? 

As for (3), it doesn't seem a big deal, but does seem arbitrary - if I want to request a quota for a single Rating-Group (which is probably the most common case in 3GPP anyway) I need to use MSCC. 

Right.

...Mark 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [ mailto:[email-masked]] 
Sent: 07 July 2004 12:00 
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi, 

when the MSCC concept was introduced I always had the assumption that the services within the MSCC structure are 
sub-ordinate to some higher level service, e.g. Network Access. Having said that, it's also true that what one can do with MSCC one should be able 

to do with several messages (that's where the MSCC issue initially started). However, I still believe that those several 

grouped together at all, they are then clearly not sub-ordinate services (e.g. not carried within the same bearer) and should 

Regards, 
Leena 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]]On Behalf Of Mark Watson 
Sent: 6. heinäkuuta 2004 19:21 
To: 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi Mark, 

...Mark 
-----Original Message----- 
From: Mark Grayson (mgrayson) [ mailto:[email-masked]] 
Sent: 06 July 2004 16:44 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Mark, Marco 

Cheers, 
Mark 

From: [email-masked] [ mailto:[email-masked]] On Behalf Of Mark Watson 
Sent: 06 July 2004 11:08 
To: [email-masked]' 
Cc: [email-masked]'; Glen Zorn (gwz); Claire Mousset 
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi Marco, 

2) Service-Identifier is finer granlarity than Rating-Group - that is several services with unique Service-Identifiers are grouped within a single Rating-Group. So a 'service' identified by a Service-Identifier is basically the finest granularity thing that can be separately charged. But then the definition of the Service Identifier AVP speaks of statically configured or standardised values. To be consistent with the above it would need to be a format or pattern than was configured/standardised - e.g. if it's voice calls that you are charging for then Service Identifies like [email-masked]', [email-masked]' would be needed to distinguish between multiple concurrent voice calls. Right ? 

3) It isn't possible to request credit for a Rating-Group except by using the Multiple-Services-Credit-Control AVP, right ? Regards...Mark 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: 05 July 2004 09:09 
To: [email-masked] 
Cc: [email-masked] 
Subject: [AAA-WG]: RE: 

Glen, 

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 

    

    

    

    

     

    

        
> [ mailto:[email-masked]]On Behalf Of 
> ext Glen Zorn

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 7 Jul 2004 15:03:51 +0100

Hi Marco,
 
Ok, so now I am very glad I asked the question, since there seems to be a
bunch of stuff here which is just not described properly. I'm happy to help
with text though (if such changes can still be made), once we have a common
understanding that makes sense.
 
Firstly, from the description below, Service-Identifier at the command level
does not (necessarily) identify a unique service, but rather a class of
services, with the specific service(s) being identified in MSCC. So then the
text in various places about Service-Identifier being a 'unique identifier
for a service' would need to be clarified.
 
But it is not clear to me why this 'class' of services cannot be implicitly
derived from the specific service identifiersm, or even that the server will
do with this information. That is, the server can identify which information
it needs to rate the service from the specific Service-Identifier (or
Rating-Group) in the MSCC - what additional value does the command level
Service-Identifier bring ?
 
Furthermore, if you do have this command level Service-Identifier, and the
client is trusted to set it correctly, then it is no greater leap of trust
to trust the client to include the Mandatory AVPs that are associated with
that Service-Identifier value! In the 3GPP example, the server knows that
the client supports these AVPs from the Supported-Vendor-ID in the
capability exchange. Sending the Service-Identifier value is like a message
saying 'Please check I have also included AVPs X, Y and Z'! A wrongly
implemented client might not send these AVPs, but more likely, a wrongly
implemented client would not set the Service-Identifier either.
 
Secondly, you are introducing the concept that a service may imply
requirements as to additional mandatory AVPs that should accompany any
request for a quota for that service. That's fine, but perhaps it should be
explained.
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 07 July 2004 14:10
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi,
 
some comment in line.
 
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 07 July, 2004 15:29
To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson (mgrayson)'; Stura Marco
(Nokia-NET/Helsinki)

Hi Leena, 

You wrote: 

Mark, I guess you are referring to the picture in sect. 5.1.1. Right? If so,
this picture was intended to only describe the MSCC concept, what Leena is
mentioning is probably not visible in that picture. The main service is a
service of its own that represent for instance the bearer, in which many
other services may be carried and may have different costs, and is not part
of any RG. This 'main service' id also identifies the service specific
document with mandatory AVPs that need to be supported, for instance the
Flow bearer charging defined in 3GPP ideally would have the 'main service'
identifier something like [email-masked]
<mailto:[email-masked]> .

Would you have good suggestion for better text in section 5.1.1 and perhaps
in the new 4.12 to remove any dubt? 

Right.

...Mark 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 07 July 2004 12:00 
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)';
[email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi, 

Regards, 
Leena 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of Mark Watson 
Sent: 6. heinäkuuta 2004 19:21 
To: 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi Mark, 

...Mark 
-----Original Message----- 
From: Mark Grayson (mgrayson) [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 06 July 2004 16:44 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Mark, Marco 

Cheers, 
Mark 

From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Mark Watson 
Sent: 06 July 2004 11:08 
To: [email-masked]' 
Cc: [email-masked]'; Glen Zorn (gwz); Claire Mousset 
Subject: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi Marco, 

-----Original Message----- 

Glen, 

Marco 

    

    

    

    

    

    

    

    

Of

---

From: <[email-masked]>
Date: Thu, 8 Jul 2004 12:15:26 +0300

Hi Mark,
> 
>> Ok, so now I am very glad I asked the question, since there seems to
>> be a bunch of stuff here which is just not described properly. I'm
>> happy to help with text though (if such changes can still be made),
>> once we have a common understanding that makes sense.
> 
Nothing in practice could be changed. Since we are updating the draft
according to IESG
comments, it is perhaps possible to also clarify the text concerning
this Service-Id stuff
without changing the concept, that should work fine.
> 
>> Firstly, from the description below, Service-Identifier at the
>> command level does not (necessarily) identify a unique service, but
>> rather a class of services, with the specific service(s) being
>> identified in MSCC. So then the text in various places about
>> Service-Identifier being a 'unique identifier for a service' would
>> need to be clarified. 
> 
No, how could you come to that conclusion? In my example the network
access service ([email-masked]) uniquely
identify the flow bearer service defined in a service specific
document, doesn't identify a class of services. The service-id in
MSCC identifies a specific content carried within the bearer service
e.g. [email-masked], which is again a unique service
of which the identifier and e.g. associated 5-tuple are provisioned
to the Service Element. In other word, the service-id at command
level identifies a service specific document where rating AVPs are
defined.       
> 
>> But it is not clear to me why this 'class' of services cannot be
>> implicitly derived from the specific service identifiersm, or even
>> that the server will do with this information. That is, the server
>> can identify which information it needs to rate the service from the
>> specific Service-Identifier (or Rating-Group) in the MSCC - what
>> additional value does the command level Service-Identifier bring ?
> 
I have given explanation what the server does in some previous mail,
but I repeat my self. Because the DCC doesn't define AVPs used for
rating, since we cannot simply define these here as we don`t know all
the possible present and future services, those are defined in
service specific documents. To easy the task of the Server of
determining whether it is able to determine the cost of a requested
service (in the example above the flow bearer service) and avoid
expensive rating operations before to discover that the request will
be rejected, the server checks first the Service-Id at command level.
If the Service-Id at command level is understood, the server
continues the processing since it is sure it can properly operate,
otherwise it immediately reject the request. 
> 
>> Furthermore, if you do have this command level Service-Identifier,
>> and the client is trusted to set it correctly, then it is no greater
>> leap of trust to trust the client to include the Mandatory AVPs that
>> are associated with that Service-Identifier value! In the 3GPP
>> example, the server knows that the client supports these AVPs from
>> the Supported-Vendor-ID in the capability exchange. Sending the
>> Service-Identifier value is like a message saying 'Please check I
>> have also included AVPs X, Y and Z'! A wrongly implemented client
>> might not send these AVPs, but more likely, a wrongly implemented
>> client would not set the Service-Identifier either.
> 
Since in 3GPP you are defining many different services and many AVPs,
the Supported-Vendor-Id doesn't tell you that the server supports IMS
services, flow bearer charging, MMS services etc. etc.....unless you
imply by default that advertising supported vendor 3GPP means that
the server support all the set of AVPs defined in 3GPP, which is most
likely not the case. And doesn`t tell what the client service is
either.      
>> requirements as to additional mandatory AVPs that should accompany
>> any request for a quota for that service. That's fine, but perhaps it
>> should be explained.
> 
The concept was introduced in the mailing list probably half a year
ago, it has been
there for couple of WGLCs and for the IETF last call, a bit late to
speak up isn`t it?
This is explained by the way

Clip

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

Service specific documentation is basically identified by the
Service-Id at command level. I`m aware of at least one case where
this has been properly understood, but perhaps we need more clear
text still :-(   

Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 07 July, 2004 17:04
To: Stura Marco (Nokia-NET/Helsinki); [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Marco,
 
Ok, so now I am very glad I asked the question, since there seems to be a bunch of stuff here which is just not described properly. I'm happy to help with text though (if such changes can still be made), once we have a common understanding that makes sense.
 
Firstly, from the description below, Service-Identifier at the command level does not (necessarily) identify a unique service, but rather a class of services, with the specific service(s) being identified in MSCC. So then the text in various places about Service-Identifier being a 'unique identifier for a service' would need to be clarified.
 
But it is not clear to me why this 'class' of services cannot be implicitly derived from the specific service identifiersm, or even that the server will do with this information. That is, the server can identify which information it needs to rate the service from the specific Service-Identifier (or Rating-Group) in the MSCC - what additional value does the command level Service-Identifier bring ?
 
Furthermore, if you do have this command level Service-Identifier, and the client is trusted to set it correctly, then it is no greater leap of trust to trust the client to include the Mandatory AVPs that are associated with that Service-Identifier value! In the 3GPP example, the server knows that the client supports these AVPs from the Supported-Vendor-ID in the capability exchange. Sending the Service-Identifier value is like a message saying 'Please check I have also included AVPs X, Y and Z'! A wrongly implemented client might not send these AVPs, but more likely, a wrongly implemented client would not set the Service-Identifier either.
 
Secondly, you are introducing the concept that a service may imply requirements as to additional mandatory AVPs that should accompany any request for a quota for that service. That's fine, but perhaps it should be explained.
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 07 July 2004 14:10
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Mousset, Claire [ADC:8J70:EXCH]
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi,
 
some comment in line.
 
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 07 July, 2004 15:29
To: 'Leena Mattila (TU/LMF)'; 'Mark Grayson (mgrayson)'; Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Leena, 

You wrote: 

Right.

...Mark 

-----Original Message----- 
From: Leena Mattila (TU/LMF) [ mailto:[email-masked]] 
Sent: 07 July 2004 12:00 
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi, 

Regards, 
Leena 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]]On Behalf Of Mark Watson 
Sent: 6. heinäkuuta 2004 19:21 
To: 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi Mark, 

...Mark 
-----Original Message----- 
From: Mark Grayson (mgrayson) [ mailto:[email-masked]] 
Sent: 06 July 2004 16:44 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Mark, Marco 

Cheers, 
Mark 

Hi Marco, 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: 05 July 2004 09:09 
To: [email-masked] 
Cc: [email-masked] 
Subject: [AAA-WG]: RE: 

Glen, 

Marco

---

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Fri, 16 Jul 2004 12:13:27 +0200

Hi,

we've had some discussion on the matter off-line, I switch the discussion back to the mailing list. The main problem seems to be the word 'service' - we do use it for two purposes ('main service' and 'the actual service category'). We also received this kind of comment from IESG review team but they did not have any good word in English to solve it either ;-) How about the following split: 

a) A Service-Context-Id is used on command level. This would be the 'broad' service and define the context in which the DCC is being used. The Service-Context-Id MUST be present if DCC application id is used. Alternatively, one that introduces mandatory rating AVPs defines an own application-id from IANA and then this AVP is not needed to guarantee interoperability  - the dedicated application id guarantees that already

b) Service-Id identifies the service within the given Context. It can be present either on command level or in MSCC. I.e. in case of ordinary one service/session we would have both Service-Context-Id and Service-Id on command level and in case of MSCC we would have Service-Context-Id on command level and Service-Id in MSCC. The Service-Id values are service-specific (in the same way as Rating-Group)
An imaginary example (gaming):
Service-Context-Id: [email-masked]
Service-Id: 2 (=mad man 2 - de luxe)

Would that solve the wording problem with 'service', and clarify the interoperability? 

BR,
Leena

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 7. heinäkuuta 2004 15:29
To: Leena Mattila (TU/LMF); 'Mark Grayson (mgrayson)'; [email-masked]'
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Leena, 
You wrote: 
-----Original Message----- 
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: 07 July 2004 12:00 
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi, 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Watson 
Sent: 6. heinäkuuta 2004 19:21 
To: 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi Mark, 
-----Original Message----- 
From: Mark Grayson (mgrayson) [mailto:[email-masked]] 
Sent: 06 July 2004 16:44 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Mark, Marco 

Hi Marco, 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: 05 July 2004 09:09 
To: [email-masked] 
Cc: [email-masked] 
Subject: [AAA-WG]: RE: 

Glen,

---

From: "STURA Marco Consultant" <[email-masked]>
Date: Mon, 19 Jul 2004 16:07:05 +0200

Hi AAA folks,

we are doing final updates to the draft mainly by integrating the IESG
comments. 

This one concerning the service-id was triggered by some change we 
proposed upon IESG comments and is actually the only unresolved "issue".
Please speak up whether you agree this Leena proposal, in case no comments
will be received by Wednesday I guess we can consider the proposal
accepted.

Thank you
Marco

-----Original Message-----
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: Friday, July 16, 2004 12:13 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; STURA Marco Consultant
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi,

BR,
Leena

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 7. heinäkuuta 2004 15:29
To: Leena Mattila (TU/LMF); 'Mark Grayson (mgrayson)'; [email-masked]'
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: )

Hi Leena, 
You wrote: 
-----Original Message----- 
From: Leena Mattila (TU/LMF) [mailto:[email-masked]] 
Sent: 07 July 2004 12:00 
To: Watson, Mark [MOP:EP10:EXCH]; 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi, 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Watson 
Sent: 6. heinäkuuta 2004 19:21 
To: 'Mark Grayson (mgrayson)'; [email-masked]' 
Cc: [email-masked]'; 'Glen Zorn (gwz)'; Claire Mousset 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Hi Mark, 
-----Original Message----- 
From: Mark Grayson (mgrayson) [mailto:[email-masked]] 
Sent: 06 July 2004 16:44 
To: Watson, Mark [MOP:EP10:EXCH]; [email-masked] 
Cc: [email-masked]; Glen Zorn (gwz); Mousset, Claire [ADC:8J70:EXCH] 
Subject: RE: DCC Service-Identifier (was RE: [AAA-WG]: RE: ) 

Mark, Marco 

Hi Marco, 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: 05 July 2004 09:09 
To: [email-masked] 
Cc: [email-masked] 
Subject: [AAA-WG]: RE: 

Glen,

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 20 Jul 2004 14:18:28 +0100

Hi Leena, all,

A Service-Context-Identitifer AVP, as you propose below would be acceptable
for me. It is much clearer than using Service-Identifier for this purpose.
Especially given all the text we have which suggests that Service-Identifier
is a very specific thing, sub-ordinate to Rating-Group.

Rating-Groups should also be defined 'withing the given context'.

Looking at the text proposed by Marco on 5th July, I think we can amend this
fairly easily. It is the proposed section 4.1.2 that uses the term 'service'
in a confusing way. I suggest deleting this and then stating at the end of
4.1.3 that it is the Service-Context-Identifier which identifies the
'service specific document' that applies to the request.

So, then, the Service-Context-Identifier scopes the interpretation of the
Service-Identifier and Rating-Group. Actually, for Rating-Groups I can see
how this can be useful, since they are just numbers which otherwise would
require coordination in their use throughout a service provider's network.

Proposed modification to Marco's text at the end of this mail (I also have a
word/pdf version with changebars which I can send to anyone who wants it).

Additionally, now that the meaning of Service-Identifiers and their
relationship to Rating-Groups is clearer, it seems clear that the
granularity of counting at the client (per service vs per RG) should be a
service provider option, based on their charging requirements, rather than
something to be recommended in the RFC. We need to soften very slightly the
recommendation to report on a per service granularity:

In section 5.1.1 change:

   It is up to the credit control 
   server whether to authorize credit for one or more services or for 
   the whole rating-group, but the client SHOULD always report used 
   units itemizing the service level usage.  

To:

   It is up to the credit control
   server whether to authorize credit for one or more specific services
   or for the whole rating-group. However, the client SHOULD always report
   used units at the finest level of granularity that it supports.

Regards...Mark

-----------proposed new version of Marco's proposal for Section 4 --------->

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.  

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. 

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

The Service-Context-Identifier AVP MUST be included at the command level of
a Credit Control Request to identify the service specific document that
applies to the request. The specific service or rating group that the
request relates to is uniquely identified by the combination of
Service-Context-Identifier and Service-Identifier or Rating-Group. 
  
4.1.3 Handling of Unsupported/Incorrect Rating Input

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 context (identified by the combination of
Service-Context-Identifier  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.4 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.

---------------------------------------------------------------------------

> Sent: 16 July 2004 11:13
> To: Watson, Mark [MOP:EP10:EXCH]; [email-masked]
> Cc: [email-masked]; [email-masked]; Mousset, Claire 
> [ADC:8J70:EXCH]; [email-masked]'
> we've had some discussion on the matter off-line, I switch 
> the discussion back to the mailing list. The main problem 
> seems to be the word 'service' - we do use it for two 
> purposes ('main service' and 'the actual service category'). 
> We also received this kind of comment from IESG review team 
> but they did not have any good word in English to solve it 
> either ;-) How about the following split: 
> 
> a) A Service-Context-Id is used on command level. This would 
> be the 'broad' service and define the context in which the 
> DCC is being used. The Service-Context-Id MUST be present if 
> DCC application id is used. Alternatively, one that 
> introduces mandatory rating AVPs defines an own 
> application-id from IANA and then this AVP is not needed to 
> guarantee interoperability  - the dedicated application id 
> guarantees that already
> 
> b) Service-Id identifies the service within the given 
> Context. It can be present either on command level or in 
> MSCC. I.e. in case of ordinary one service/session we would 
> have both Service-Context-Id and Service-Id on command level 
> and in case of MSCC we would have Service-Context-Id on 
> command level and Service-Id in MSCC. The Service-Id values 
> are service-specific (in the same way as Rating-Group) An 
> imaginary example (gaming):
> This sounds very reasonable to me, but it is not what the 
> specification seems to imply. There is no concept in the spec 
> of 'services' being 'sub-ordinate' to other 'services'. 
> Furthermore, the fact that a 'service' is sub-ordinate to 
> Rating-Group implies that everything within a service has to 
> be rated the same. So then even if there were sub-services 
> within a 'main service' they would all have to be within the 
> same Rating-Group! But if people feel it's clear that there 
> can be such a thing as a 'main service' which is not part of 
> any Rating Group and which has sub-services, then that seems 
> fine to me. As for (3), it doesn't seem a big deal, but does 
> seem arbitrary - if I want to request a quota for a single 
> Rating-Group (which is probably the most common case in 3GPP 
> anyway) I need to use MSCC. ...Mark 
> sub-ordinate to some higher level service, e.g. Network 
> Access. Having said that, it's also true that what one can do 
> with MSCC one should be able 
> to do with several messages (that's where the MSCC issue 
> initially started). However, I still believe that those several 
> grouped together at all, they are then clearly not 
> sub-ordinate services (e.g. not carried within the same 
> bearer) and should 
> [mailto:[email-masked]]On Behalf Of Mark Watson 
> Note sure what you mean by a 'rating-root', but it is quite 
> clear (e.g. in the diagrams in 5.1.1) that 'services' are 
> sub-ordinate to Rating-Groups. Since everything in a 
> Rating-Group is rated the same way then certainly you cannot 
> have things within a service which are rated differently. 
> That is, services are the finest level of granularity that 
> can be separately charged. The point of MSCC was to do in one 
> message what could otherwise be done with several messages 
> and only command level values - so I would expect the things 
> appearing in the MSCC to have the same semantics as things 
> appearing at command level & for the two to be mutually 
> exclusive - hence Question 1 below. To answre my question (2) 
> below for myself, we don't need multiple instances of the 
> same service within a single sub-session. In 3GPP, I think we 
> may have a requirement for dynamically povisioned services, 
> but the dynamic provisioning of these to DCC client & server 
> is out of scope here & so there should be no problem. ...Mark 
> I had asumed that when present on the command level, the 
> service-ID refers to the "rating-root" which then needs to be 
> common between client and serer. 
> Then the issue exists with re-introducing the service-ID at 
> the MSCC level, now possibly below the sub-session-ID which I 
> think is the cause of the issue. IMO these AVPs at the MSCC 
> level should be subordinate to the service-ID on the command 
> level. Cheers, 
> Mark 
> 
> 
> 
> 
> 1) If the client wants to request quotas for multiple 
> services using the Multiple-Services-Credit-Control AVP then 
> what should it put in the mandatory command level 
> Service-Identifier AVP ?
> 2) Service-Identifier is finer granlarity than Rating-Group - 
> that is several services with unique Service-Identifiers are 
> grouped within a single Rating-Group. So a 'service' 
> identified by a Service-Identifier is basically the finest 
> granularity thing that can be separately charged. But then 
> the definition of the Service Identifier AVP speaks of 
> statically configured or standardised values. To be 
> consistent with the above it would need to be a format or 
> pattern than was configured/standardised - e.g. if it's voice 
> [email-masked]', [email-masked]' would be needed to 
> distinguish between multiple concurrent voice calls. Right ? 
> 3) It isn't possible to request credit for a Rating-Group 
> except by using the Multiple-Services-Credit-Control AVP, 
> right ? Regards...Mark 
> 
> 
> 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