Subject: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR...

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 10 Apr 2003 13:07:17 -0400

Hi,

  I'm forwarding this e-mail, because it didn't initially appear on
the list due to mailer issues on my end.

Regards,

  Jeff Meyer

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) 
Sent: Wednesday, April 09, 2003 9:02 AM
To: 'Harri Hakala (LMF)'; [email-masked]'; MEYER,JEFFREY D
(HP-Cupertino,ex1)
Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt

Harri,

  Thanks for the response.  Regarding the domain of Parlay, I'd agree
it presumes a Parlay framework.  However, it also has an "Information
Model" aimed at addressing the same credit control space as your 
draft, so to that end trying to align these information models is
where the use of a common model for describing the information payload
in a manner independent of encoding and transport is where IPDR can
come into play.

  I know there was work on a dictionary framework in the Diameter
group, but that seems to have stalled out.  What I would like to do
is resurrect that model, but using IPDR's XML-Schema with annotation
approach.  This would likely require a draft on its own, I'll begin
looking into that.

  I'll also look to see if there is some "placeholder" language which would
be appropriate for the credit control draft.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Harri Hakala (LMF) [mailto:[email-masked]]
> Sent: Wednesday, April 09, 2003 1:31 AM
> To: [email-masked]'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'
> Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt
> 
> 
> >   Any comments on the relationship of this application to Parlay
> > section 12 and PayCircle?
> > 
> >   http://www.parlay.org/specs/3.2/es_20191512Charging.zip
> > 
> >   http://www.paycircle.org
> > 
> >   It seems that all of these are addressing the same basic issue of
> > authorization of services with possible reservation of credit on
> > the backend.
> 
> Isn't the applicability of OSA/Parlay charging API limited to 
> services that
> have been built using the OSA/Parlay framework?.
> I foresee that there are services built using other 
> mechanisms and are therefore
> outside this framework. 
> 
> Our motivation is to define an IP-based accounting protocol 
> to support credit
> based accounting by using the AAA infrastructure. Because the 
> Diameter base 
> protocol provides several features, which are required from 
> this kind of application
> and because the Diameter and its accounting can be widely 
> utilized we thought that
> the AAA framework and Diameter is a good choice for this kind 
> of IP-based accounting
> protocol. 
> 
> I assume that there are several (and more and more are being 
> developed) this kind of
> applications focusing on online payments and credit 
> reservations using quite similar
> mechanisms, but having a bit different scope and framework. 
> 
> >   A harmonization of terminology, and ideally attribute names and
> > data types would be worthwile.
> > 
> >   The IPDR.org (http://www.ipdr.org) group is looking at aspects of
> > performing 
> > this harmonization.  For some information on the separation 
> > of information
> > model, from encoding from transport see:
> > 
> >   http://www.circumference.org/circumference.ppt
> 
> A harmonization of terminology, etc, defined by different 
> standardization bodies, 
> would be helpful, although it might be quite challenging task.
> 
> It would be good if you can provide us with proposals for 
> changed text in the draft.
> 
> Regards.........Harri
> 
> > -----Original Message-----
> > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[email-masked]]
> > Sent: 9. huhtikuuta 2003 2:56
> > To: Harri Hakala (LMF); [email-masked]
> > Subject: RE: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt
> > 
> > 
> > Harri,
> > 
> >   Any comments on the relationship of this application to Parlay
> > section 12 and PayCircle?
> > 
> >   http://www.parlay.org/specs/3.2/es_20191512Charging.zip
> > 
> >   http://www.paycircle.org
> > 
> >   It seems that all of these are addressing the same basic issue of
> > authorization of services with possible reservation of credit on
> > the backend.
> > 
> >   A harmonization of terminology, and ideally attribute names and
> > data types would be worthwile.
> > 
> >   The IPDR.org (http://www.ipdr.org) group is looking at aspects of
> > performing 
> > this harmonization.  For some information on the separation 
> > of information
> > model, from encoding from transport see:
> > 
> >   http://www.circumference.org/circumference.ppt
> > 
> > 
> > Regards,
> > 
> >   Jeff Meyer
> >   HP
> >   http://www.hp.com/usage
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Harri Hakala (LMF) [mailto:[email-masked]]
> > > Sent: Friday, February 28, 2003 1:55 AM
> > > To: [email-masked]
> > > Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt
> > > 
> > > 
> > > Hi All,
> > > 
> > > We have submitted a new version of the Diameter credit 
> control draft
> > > to the IETF archive.
> > > 
> > > Until it shows up in the archive, it can be found:
> > > http://standards.ericsson.net/harri/draft-hakala-diameter-cred
> > it-control-06.txt
> > 
> > Here is a list of updates compared to draft -05:
> > 1. A server or client is not required to implement all 
> > functionality in 
> > the CCA. The optionality has been clarified in the draft, the 
> > modified 
> > AVPs are the following:
> > 
> > 1a. Unknown/unsupported value responded with error:
> >    - Subscription-Id-Type
> > 
> > 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table
> >    - Accounting-Correlation-Id
> >    - Abnormal-Termination-Reason
> >    - Cost-Information
> > 
> > 2. New Result-Code value 'DIAMETER_RATING_FAILED'.
> > 
> > We would appreciate if you can read it and provide your comments.
> > 
> > Regards.......Harri
> > 
>

---

From: [email-masked]
Date: Fri, 11 Apr 2003 23:37:45 +0200

(Thanks, Harri)

Hi Harri, Jeff, all

 Parlay domain are limited to services that use the Parlay Framework. However, I think that the
relationship between Parlay and Diameter is very important and complementary.

Parlay is not conceived as a core network protocol but a protocol to abstract a service level from
the core network. The objectives are two: to have a service level where to implement in an easy way
application logics for the services using APIs able to simplify the process for the developers (
fast and cheap developing services); and to be able to provide a Framework and APIs to third parties
in order to allow them using the network operator assets in a controlled manner (it allows the
network operator to control the charging, for instance).

I consider Diameter as a core network protocol, it means that the relation between Parlay and
Diameter is the physical realization or mapping of the Parlay procedures and messages (defined by
the API) into Diameter procedures and messages.

I think it would be very important to certify the alignment between both protocols.

The schema would be as follows:

               middleware
 ------------             --------
|  Parlay |A |           | Parlay | PARLAY
|         |P | ----------|        |GATEWAY
| Service |I |           |   SCS  |
 ------------            |--------|
  APLICATION             |Diameter|
    SERVER               |Enabler | - (Credit
                          --------    Control
                              |       Application)
                              |
                              |Diameter
                              |
                              |
                          ---------
                         |         |
                         | Credit  |
                         |         |
                         | Control |
                         |         |
                         |  Server |
                         |         |
                          ---------

Note that there is not cannibalisation between both protocols but they are complementary. Diameter
protocols is able to integrate several systems and Parlay allows to use these systems in a easy way
both for local services and for third party services. The sinergy of joint solutions is great.

Cheers,

Paco Marín
-------------------
Vodafone Group R&D
C/ Trespaderne, 29 Edificio Barajas 1_B
Madrid
Spain
T: +34 607135244
F: +34 607 135252
--------------------------------------------------------------------

      "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
      Enviado por: [email-masked]
      10/04/2003 19:07

             Para: "[email-masked]'" <[email-masked]>
             cc:
             cco:
             Asunto: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR...

Hi,

Regards,

  Jeff Meyer

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1)
Sent: Wednesday, April 09, 2003 9:02 AM
To: 'Harri Hakala (LMF)'; [email-masked]'; MEYER,JEFFREY D
(HP-Cupertino,ex1)

Harri,

Regards,

  Jeff Meyer

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 11 Apr 2003 18:14:20 -0400

Paco,

  Although I see the synergy between PayCircle (which is based
on concepts from Parlay) and Diameter, in that an application
developer may want to write to a web services type interface
vs. a binary interface; I am less clear on whether the API 
defined by Parlay is simpler than that being defined for Diameter.

  Aspects around tunneling and proxying are also issues which
Diameter addresses well, but I suspect are more of an open
issue in Parlay.

  It seems to me that Parlay's key design center was around
abstracting interactions into today's IN/SS7 networks, which
requires some proxying to enable apps on general purpose
platforms to interact with the signalling network.

  However, for general applications, which want to be able
to service not just devices connected through the GSM/PSTN
network, but IP devices in general, then I think the value
of Parlay is limited.

  Maybe I missed something in my reading of Parlay, but these
interfaces don't seem too friendly to me.  It seems like there
is a lot of API overhead involved in making CORBA behave like
an asynchronous interface, which it doesn't want to be.

  In any event, this isn't the right venue to discuss the 
virtues and foibles of Parlay.  But it is reasonable to say
that there will be some Parlay apps, the Parlay developers
have spent time investigating this space, and ensuring that
information exchange between the Diameter and Parlay based
apps, as in your diagram, is enabled if possible.

Regards,

  Jeff Meyer

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 11, 2003 2:38 PM
> To: [email-masked]'
> Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); Harri Hakala (LMF)
> Subject: Re: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and
> IPDR...
> 
> 
> (Thanks, Harri)
> 
> 
> Hi Harri, Jeff, all
> 
> Parlay is not conceived as a core network protocol but a 
> protocol to abstract a service level from
> application logics for the services using APIs able to 
> simplify the process for the developers (
> fast and cheap developing services); and to be able to 
> provide a Framework and APIs to third parties
> protocols is able to integrate several systems and Parlay 
> allows to use these systems in a easy way
> [mailto:[email-masked]]

---

From: <[email-masked]>
Date: Mon, 14 Apr 2003 09:25:21 +0300

Hi Jeff,

> apps, as in your diagram, is enabled if possible.

If you could suggest some text, etc. that the credit control
document woulkd need to support this, we can look at adding it.
However, I feel that this is a more general problem and not
just limited to the Credit Control application.  Also,
I do know that some folks have expressed interest in some
sort of 'interface' (in a very loose sense of the word) between
webservices and Diameter.  I'm not sure if there is a need for
a standard solution or if this is much more an implementation
or deployment issue.

thanks,
John

---

From: [email-masked]
Date: Tue, 22 Apr 2003 11:05:04 +0200

Hi Jeff,

  (sorry about the delay in the answer, I was on hollidays).

   A very interesting answer, Jeff, it is a very, very valuable to me because it represents a
different point of view.

   Anyway, I have some comments (see below).

Best Regards and Thanks for all,

Paco Marín
-------------------
Vodafone Group R&D
>> "MEYER,JEFFREY D (HP-Cupertino,ex1)"

De:   [email-masked]
Para: "[email-masked]'", "[email-masked]'"
cc:   "MEYER,JEFFREY D (HP-Cupertino,ex1)", "Harri Hakala (LMF)"

Asunto:     RE: Re: [AAA-WG]: Diameter Credit, Parlay, PayCircle and IPDR...

Paco,

----
Paco>> Yes, there is no reasons to think that the Parlay API is simpler than that defined for
Diameter (in PayCircle)... that was not the purpose of Parlay.
----

----
Paco>> It is possible to apply tunneling to the IP connection between the Parlay Application Server
and the Parlay SCS. And... yes, the details of proxying is out of the scope of Parlay, once the
access from an external network to the operator network is solved Parlay has accomplish its role.
The only proxy function is produced in the SCS which is the door to the network assets. That is the
reason of thinking that Parlay and Diameter Protocol do not exclude each other but are complementary
(Diameter for indoor part of the system).
----

----
Paco>> We don't have to mistake the relation SS7 network versus IP network with the relation call
models versus transactional models. What I mean is that in a telecommunication network there are
different possible communication models: asynchronous transactions, synchronous transactions, call
models, events notifications, and so on... It could happen both in a SS7 or IP network (note that
what happens in SIP is to export the previous SS7 features to IP, it means irremediablely exporting
to IP the SS7 telecommunications models as well). On the other hand, when we talk about the Web
Services model we are talking about only an asynchronous transactional model... and don't pay
attention to the remaining telecommunication models. Parlay has been designed to take over remotely
of these network features (e.g. call models, event notification, and so on...).

Paco>> That is to say Parlay was not extrictelly designed to interact with the SS7 network but to
interact with telecommunication features and models... the protocol underneath is (or must be)
transparent. One of these features is charging, however in charging it is not especified the type of
network protocol underneath... it could be Diameter. Don't think the call models are not models of
future, remember that SIP has the same call models over IP.
----

----
Paco>>yes... and NO... It depends on what we want. I think we cannot say neither a Web Services
(PayCircle) model is better than a Parlay model nor vice versa. Each model fits some specific
requirements. If we want only to base our services in an asychronous transactional model... yes,
what we need is only PayCircle model... and this model will fit much better the requirements than
Parlay... it is easier to use and more confortable for developers. However, if we need other models
or joint several models to face our services we have to use Parlay or some similar model.
----

----
Paco>> Yes, Jeff, likely the Parlay interfaces are not too friendly, that's the price of the
details. There is only a question of confortability versus details. however, it would be possible to
introduce new interfaces over Parlay able to simplify the use for the developers... and to resort to
the details if necessary... however it is a question of the specific use.

Paco>> Yes, CORBA is a synchronous middleware and it has been forced to act as an asynchronous
interface for this purpose. The solutions have not been too brilliant (multi thread: error-prone and
'one way': inefficient). At the moment there is new versions of CORBA, Real Time CORBA (RT-CORBA)
that tries to solve this issue introducing asynchronous methods and procedures.... but it is still
to be tested. However, the tests that I have carried out for a Parlay API on CORBA has been quite
successful, but I have to confess that I didn't accomplish load traffic tests.
----

----
Paco>> Yes, this is not the venue to discuss that... sorry about the 'will' above. However it would
be important to ensure the alignment between Parlay and the corresponding mapping into Diameter....
Probably a job for the Parlay people (or OMA)?... I don't know. Unfortunately, I have no time to
devote to it....

My best regards and thanks for all,

----

Regards,

Jeff Meyer