Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Thu, 11 Dec 2003 13:48:26 +0100

Hi John,

Thank you for your feedback. It is true that our current text is 
incomplete and it needs some clarifications.

We assume that there exists agreement between providers of the 
credit control client and server covering mandatory/non-mandatory
rating input AVPs as well, since depending on the provider's billing policy
a mandatory input parameter for one provider might be irrelevant for 
another. Therefore it may be good to have a configuration option that
would prevent mandatory AVPs to be sent if not relevant to the rating 
process. This is also fully compliant with RFC 3588 section 4.1.

Perhaps it would be good also clarify how *[AVP] notation in CCR command
should be interpreted. It may reasonable to add sentence that service 
applications should define what AVPs they are planning to use as input to
rating process.

How it sounds if we add following sentence before the M-bit discussion:

"It is RECOMMENDED that service applications define what existing 
AVPs or new AVPs are used as input to the rating process and thus
need to be included in the Credit-Control-Request command by a 
Diameter Credit Control Client as *[AVP]."

and change the M-bit paragraph in this way:

"Within a credit control request, setting the "M" bit implies that a 
rating server or the credit control server itself SHOULD understand 
the AVP in order to rate the service. However, since different 
service providers may apply different rating policies a mandatory 
input parameter for one server might be irrelevant for another.
Therefore, to simplify interoperability a configuration option SHOULD 
be provided per peer or per realm basis that would prevent particular 
mandatory AVPs to be sent if not relevant to the rating process of a 
given credit-control server's provider."

Regards......Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10. joulukuuta 2003 17:09
To: Harri Hakala (TU/LMF)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Leena Mattila (TU/LMF); [email-masked]'; [email-masked]; Patrik Teppo (KA/EAB)
Subject: Re: [AAA-WG]: Issue: DCC Service-specific Rating Input and Interoperability

Hi Harri, 

In your proposed change you include the following: 

Therefore, if the AVP is not relevant to the rating process, when the 
AVP is included within a credit-control request, it can be ignored, 
even if the "M" bit is set. 

At first, it does seem a good idea that a server can ignore mandatory parameters if it doesn't need them.  However, it could be that the client is passing a piece of information in the mandatory AVP that it knows is essential to the rating process and if this piece of information is missing then the rating could be inaccurate.   

I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs MUST be rejected if the AVP or its value is unrecognised (except, as I read it, there is a get out clause where the mandatory AVP is not defined in the base or appopriate Diameter applications).  It isn't possible for an application to overrule this sort of rule in the base, is it? 

Perhaps it would be a better solution if the applications built on CCA were given the right to redefine mandatory AVPs in CCA as non-mandatory and vice versa, which I believe is compatible with RFC 3588 (because they are new applications). 

Regards, 

John.

---

From: [email-masked]
Date: Fri, 12 Dec 2003 12:35:08 +0000

Hi Harri,

Thank you for your response.

I'm not sure it is possible to configure out mandatory AVPs that are 
defined by CCA.  As I read section 4.1 of RFC 3588, the configuration 
mechanism is to preserve inter-operability where the mandatory AVP is not 
part of the base or CCA.  It seems to me to be a different matter where 
the mandatory AVP is part of the base or CCA.

This, however, is the detailed interpretation and my bigger concerns are 
the strategic implications of this change. 

My main worry about having a mechanism to make mandatory AVPs optional is 
inter-operability.  I can see that agreements will work well where the 
client and server are working together in tightly-defined circumstances, 
perhaps where they're both being supplied by the same vendor.  From the 
network operators point of view the benefit of open standards such as 
Diameter is that nodes from different vendors can easily be plugged 
together.  If the implementations of CCA vary according to private 
agreements then I think we can all imagine the sort of scenarios that 
would ensue in getting systems from different vendors to work together.

OK, these issues can all be resolved by specifying the behaviour in new 
Diameter applications built upon CCA but, unless that is co-ordinated 
well, the downside would be fragmentation, with many overlapping 
applications being used for various aspects of credit control and little 
commonality between vendors.

All in all, I believe introducing optional mandatory parameters into CCA 
will have a major effect on its future direction.  My feeling is that CCA 
shouldn't do it, which passes the responsibility on to the subsequent 
applications that build on CCA to decide whether the AVPs they use are 
mandatory or optional.

Regards,

John.

"Harri Hakala (TU/LMF)" <[email-masked]>
Sent by: [email-masked]
11/12/2003 12:48

        To:     "[email-masked]'" <[email-masked]>
        cc:     [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked], "Leena Mattila (TU/LMF)" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>, [email-masked], "Patrik Teppo (KA/EAB)" 
<[email-masked]>
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero 
perability

Hi John,

rating input AVPs as well, since depending on the provider's billing 
policy

Regards......Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10. joulukuuta 2003 17:09
To: Harri Hakala (TU/LMF)
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]; Leena Mattila (TU/LMF); 
[email-masked]'; [email-masked]; Patrik Teppo (KA/EAB)
Subject: Re: [AAA-WG]: Issue: DCC Service-specific Rating Input and 
Interoperability

Hi Harri, 

At first, it does seem a good idea that a server can ignore mandatory 
parameters if it doesn't need them.  However, it could be that the client 
is passing a piece of information in the mandatory AVP that it knows is 
essential to the rating process and if this piece of information is 
missing then the rating could be inaccurate. 

I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs 
MUST be rejected if the AVP or its value is unrecognised (except, as I 
read it, there is a get out clause where the mandatory AVP is not defined 
in the base or appopriate Diameter applications).  It isn't possible for 
an application to overrule this sort of rule in the base, is it? 

Perhaps it would be a better solution if the applications built on CCA 
were given the right to redefine mandatory AVPs in CCA as non-mandatory 
and vice versa, which I believe is compatible with RFC 3588 (because they 
are new applications). 

Regards, 

John. 

******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message 
(or responsible for delivery of the message to such person), 
you may not copy or deliver this message to anyone. In such 
case, you should destroy this message and kindly notify the 
sender and [email-masked] by reply email.  Please
note that in such circumstances any review, dissemination, 
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited 
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages 
of this kind.  The opinions, conclusions and other information 
in this message are of the author and shall be understood as 
neither given nor endorsed by Vodafone Ireland Limited 
unless it is otherwise indicated by an authorised representative 
independent of this message.  Internet e-mail is
transmitted over the public internet over which Vodafone 
Ireland Limited has no control.  As such, there is no guarantee that 
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender 
(iii) this e-mail has not been intercepted by a third party 
(iv) the contents of this e-mail are unaltered from the time of
transmission.  The presence of this footnote indicates that this 
message (including its attachments) has been processed by an 
automated anti-virus system; however it is the responsibility of 
the recipient to ensure that the message (and attachments) 
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
Number 326967 VAT Reg No. IE6346967G

******************************************************************************

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 12 Dec 2003 13:28:30 -0500

Hi,
 
  If you think of Diameter CCA as transfering a logical document with
various information elements inside it, then the mandatory bit indicates to
me that the sender wants the receiver to understand/recognize that element
(AVP).
 
  If I think of a general Diameter Server platform, I would imagine that it
has access to a repository of known elements (AVPs) it might encounter in
various messages, and possibly further rules constraining what it expects to
find in any such document.
 
  In general if the Diameter Server receives elements whose definition are
not present in its repository, then it will have limited ability to perform
any meaningful action on that element.  If the element is marked as
mandatory, then this is PROBABLY an issue that should be addressed.  If it
is not marked mandatory, then the implementation is free to simply ignore
it.  However in the ultimate processing of the document, based on the needs
of the application it MAY chose to ignore certain fields, even those marked
as mandatory, because they are not relevant to the specific business logic
required for this deployed instance of the application.
 
  For example a Diameter application may simply log or maintain a
characterization of overall activity for the past hour.  Many fields marked
as mandatory are probably irrelevant from this application's business logic
needs.  I.e. it is probably just going to look at userId's and maybe some
quantity fields.

  So, it seems to me that enabling extensions to the base CCA which turn on
the mandatory bit IS a valid use case.  And that implementations SHOULD
notify the application entity sitting on top of the Diameter protocol stack
that a mandatory field is present, but unrecognized.  But the application
itself should be able to decide whether it considers this fatal or simply
proceeds.
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, December 12, 2003 4:35 AM
To: Harri Hakala (TU/LMF)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]';
[email-masked]; [email-masked]; Leena Mattila
(TU/LMF); [email-masked]'; [email-masked]; Patrik Teppo
(KA/EAB)
Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero
perability

Hi Harri, 

I'm not sure it is possible to configure out mandatory AVPs that are defined
by CCA.  As I read section 4.1 of RFC 3588, the configuration mechanism is
to preserve inter-operability where the mandatory AVP is not part of the
base or CCA.  It seems to me to be a different matter where the mandatory
AVP is part of the base or CCA. 

This, however, is the detailed interpretation and my bigger concerns are the
strategic implications of this change. 

My main worry about having a mechanism to make mandatory AVPs optional is
inter-operability.  I can see that agreements will work well where the
client and server are working together in tightly-defined circumstances,
perhaps where they're both being supplied by the same vendor.  From the
network operators point of view the benefit of open standards such as
Diameter is that nodes from different vendors can easily be plugged
together.  If the implementations of CCA vary according to private
agreements then I think we can all imagine the sort of scenarios that would
ensue in getting systems from different vendors to work together. 

OK, these issues can all be resolved by specifying the behaviour in new
Diameter applications built upon CCA but, unless that is co-ordinated well,
the downside would be fragmentation, with many overlapping applications
being used for various aspects of credit control and little commonality
between vendors. 

Regards, 

John. 

11/12/2003 12:48 

        cc:        [email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked], "Leena Mattila
(TU/LMF)" <[email-masked]>, "[email-masked]'"
<[email-masked]>, [email-masked], "Patrik Teppo (KA/EAB)"
<[email-masked]> 
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating
Input and Intero        perability

Hi John,

Regards......Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10. joulukuuta 2003 17:09
To: Harri Hakala (TU/LMF)
Cc: [email-masked]; [email-masked]; [email-masked];

Hi Harri, 

At first, it does seem a good idea that a server can ignore mandatory
parameters if it doesn't need them.  However, it could be that the client is
passing a piece of information in the mandatory AVP that it knows is
essential to the rating process and if this piece of information is missing
then the rating could be inaccurate.   

I also checked RFC 3588 and it states in section 4.1 that mandatory AVPs
MUST be rejected if the AVP or its value is unrecognised (except, as I read
it, there is a get out clause where the mandatory AVP is not defined in the
base or appopriate Diameter applications).  It isn't possible for an
application to overrule this sort of rule in the base, is it? 

Perhaps it would be a better solution if the applications built on CCA were
given the right to redefine mandatory AVPs in CCA as non-mandatory and vice
versa, which I believe is compatible with RFC 3588 (because they are new
applications). 

Regards, 

John. 

****************************************************************************
**

****************************************************************************
**

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 15 Dec 2003 12:54:29 +0100

Hi John & Jeff,

Thank you for your comments and your additional clarifications.
Related to your comments:

John wrote:
>All in all, I believe introducing optional mandatory 
>parameters into CCA will have a major effect on its 
>future direction.  My feeling is that CCA shouldn't 
>do it, which passes the responsibility on to the 
>subsequent applications that build on CCA to decide 
>whether the AVPs they use are mandatory or optional. 

Jeff wrote:
>So, it seems to me that enabling extensions to the base CCA
>which turn on the mandatory bit IS a valid use case.  And that
>implementations SHOULD notify the application entity sitting 
>on top of the Diameter protocol stack that a mandatory field 
>is present, but unrecognized.  But the application itself 
>should be able to decide whether it considers this fatal or
>simply proceeds.

I agree, the rule about 'M'-bit usage might have not been the best
possible one, and in fact, not needed. We removed that sentence from
the section 4.1, so that the rules in the base apply.

Instead, we tried to clarify that each service shall document and specify
the rating AVPs that service shall use and it will be up to that service
in question whether to use 'M'-bit for some AVP or not.

We propose following new text:

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.

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

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

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

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
at command level. The Service-Identifier AVP SHOULD be a unique identifier
for a given service as defined in section 8.40. Diameter credit control
implementations are required to support the Mandatory rating AVPs defined in
service specific documentation of the services they support. Introducing
new credit control mechanisms not defined in this specification implies
the definition of a new version of the Diameter Credit Control Application
and corresponding Application Identifier.

In case a rating input required for the rating process is missing from
the Credit control request, or the credit control server does not
support the requested service (i.e. does not support one or more
Mandatory rating AVPs included in the request command), 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.

Regards.............Harri

---

From: [email-masked]
Date: Mon, 15 Dec 2003 18:09:19 +0000

Hi Harri,

I'm happy that this would mean that anyone integrating Diameter CCA nodes 
would have a clear means of understanding interoperability.  There would 
probably still be some fragmentation of the service provided.  Obviously, 
it would help if most services were registered with standardisation 
bodies, but I realise your recommendation is as much as can be done within 
CCA.

I would like to suggest that an explicit statement is added to the effect 
that "It is the combination of support of the DCC application and the 
service defined in Service-Identifier, that defines interoperability 
between any given DCC client and server" or words to that effect.

Is that OK?

Regards,

John.

15/12/2003 11:54

        To:     "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" <[email-masked]>, 
"[email-masked]'" <[email-masked]>
        cc:     "[email-masked]'" <[email-masked]>, "[email-masked]'" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>, "Leena Mattila (TU/LMF)" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>, "[email-masked]'" 
<[email-masked]>, "Patrik Teppo (KA/EAB)" 
<[email-masked]>
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero 
perability

Hi John & Jeff,

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

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
at command level. The Service-Identifier AVP SHOULD be a unique identifier
for a given service as defined in section 8.40. Diameter credit control
implementations are required to support the Mandatory rating AVPs defined 
in
service specific documentation of the services they support. Introducing
new credit control mechanisms not defined in this specification implies
the definition of a new version of the Diameter Credit Control Application
and corresponding Application Identifier.

A Diameter credit control client receiving error code 
DIAMETER_RATING_FAILED

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 15 Dec 2003 15:57:41 -0500

Harri,

  The text looks good to me.

Regards,

  Jeff Meyer

> From: Harri Hakala (TU/LMF) [mailto:[email-masked]]
> Sent: Monday, December 15, 2003 3:54 AM
> To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; [email-masked]'
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; 
> [email-masked]'; Leena
> Mattila (TU/LMF); [email-masked]'; [email-masked]';
> Patrik Teppo (KA/EAB)
> Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and
> Intero perability
> 
> 
> Hi John & Jeff,
>

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Tue, 16 Dec 2003 09:39:40 +0100

Hi John,
 
I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect. 

We will add the statement, thanks.
 
Regards...........Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 15. joulukuuta 2003 20:09
To: Harri Hakala (TU/LMF)
Cc: [email-masked]'; [email-masked]'; [email-masked]'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; Leena Mattila (TU/LMF); [email-masked]'; [email-masked]'; Patrik Teppo (KA/EAB)
Subject: RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero perability

Hi Harri, 

I'm happy that this would mean that anyone integrating Diameter CCA nodes would have a clear means of understanding interoperability.  There would probably still be some fragmentation of the service provided.  Obviously, it would help if most services were registered with standardisation bodies, but I realise your recommendation is as much as can be done within CCA. 

I would like to suggest that an explicit statement is added to the effect that "It is the combination of support of the DCC application and the service defined in Service-Identifier, that defines interoperability between any given DCC client and server" or words to that effect. 

Is that OK? 

Regards, 

John. 

15/12/2003 11:54 

        To:        "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" <[email-masked]>, "[email-masked]'" <[email-masked]> 
        cc:        "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Leena Mattila (TU/LMF)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Patrik Teppo (KA/EAB)" <[email-masked]> 
        Subject:        RE: [AAA-WG]: Issue: DCC Service-specific Rating Input and Intero        perability

Hi John & Jeff,