Subject: Re: [Dime] Re: FW: First draft on the integration of QoS application

From: Tina TSOU <[email-masked]>
Date: Tue, 03 Jul 2007 14:38:10 +0800

Hi Dong,
Probably NE is needed to report a Transport ID to the authorizing entity to
differentiate which kind of procedure it is going to use.

B. R.
Tina

----- Original Message ----- 
From: "Sun, Dong (Dong)" <[email-masked]>
To: "McCann Peter-A001034" <[email-masked]>; "Asveren, Tolga"
<[email-masked]>; <[email-masked]>
Sent: Thursday, June 21, 2007 6:57 AM
Subject: RE: [Dime] Re: FW: First draft on the integration of QoS
application

Hi Pete, Tolga,
I agree that this QoS application does not need to cover the interface
between Application Server and Policy Server, which is the Rx in the
3GPP term.

Although the protocol wise the same command codes can be used for both
inter/intra-domain cases, I think there are some differences from the
(policy control) functional perspective, such as security requirement;
and the information exchanged through the interface - in the
inter-domain case the information would be more abstract and generic
e.g. independent of network technology; and the routing mechanism - in
the inter-domain case an anchor point would be used instead of
disclosing the internal topology.

As I said, I am open to cover both inter-domain and intra-domain
scenarios in the same application, but it makes sense to elaborate on
the difference in the functional modeling.

Dong

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]]
Sent: Wednesday, June 20, 2007 12:26 PM
To: Asveren, Tolga; [email-masked]
Subject: RE: [Dime] Re: FW: First draft on the integration of QoS
application

Hi, Tolga, Dong,

The existing text assumes that the Authorizing Entity is either a static
subscriber database or is itself an Application Server.  The term
"Authorizing Entity" was introduced to abstract away from either of
these two implementations.  I would rather not introduce an additional
interface, especially if it goes unspecified for now.  I would rather
have just one protocol that can serve as an inter-domain or intra-domain
interface depending on the business model, as Tolga says.  In 3GPP
terms, this would be one application that can serve as either Gx or Rx.
The "Diameter Cloud" shown in Figure 1 implies the location of the
inter-domain interface.  We could write into the draft some
considerations for how proxies can handle Diameter QoS messages, in case
they want to impose their own policies.  As the base protocol allows,
intermediate proxies can add AVPs to a command to indicate such local
policies.

-Pete

Asveren, Tolga wrote:
> Hi Dong,
>
> I personally don't see any conceptual difference between interdomain
> and intradomain requests regarding Diameter QoS. Both interfaces are
> used to communicate the desire to reserve QoS with characteristics as
> described by the AVPs in the corresponding messages. The rest is
> probably dependent on policy, e.g. how interdomain requests are
> handled v.s.
> intradomain requests.
>
> IMHO, authorization can be treated as an integral part of QoS
> reservation. It could be optionally omitted depending on the business
> model. Probably, from QoS application point of view, the impact would
> be to have an AVP  identifying the user/subscriber in the message.
> IMHO, the rest (whether and how the value in this AVP is used by the
> server/proxy etc..., e.g. consulting an external database) is
> implementation dependent.
>
>    Thanks,
>    Tolga
>
>
>
>> -----Original Message-----
>> From: Sun, Dong (Dong) [mailto:[email-masked]]
>> Sent: Tuesday, June 19, 2007 6:27 PM
>> To: McCann Peter-A001034; Christian Esteve; [email-masked]
>> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS
>> application
>>
>> Pete, et al,
>>
>> Although I have no objection to define the inter-domain interface, it

>> seems to me the Rx in 3GPP does not fit well with the modeling
>> defined in QoS application: - Rx is defined between Application
>> Function and Policy Decision function (i.e. part of Authorizing
>> entity in QoS application) - QoS application concerns the control of
>> policy enforcement, the interface between authorizing entity and
>> Network element, which is the Gx in 3GPP term.
>>
>> If we really like to cover both inter-domain and intra-domain
>> scenarios in the single QoS application, I think it should be a
>> Gx-like interface. In the inter-domain case, the Gx-like interface
>> will be used between home PCRF and visited PCRF as well; besides it
>> can be used between PCRF and PCEF for intra-domain case.
>>
>> In addition, I think we should allow the flexibility to have
>> Application Server separated from the Authorizing entity (but not
>> mandatory), and maybe no need to standardize that interface between
>> AS and Authorizing entity in this QoS application.
>>
>> If you agree on this proposal, I'd like to edit the latest draft I
>> sent out to reflect this notion.
>>
>> Dong
>>
>> -----Original Message-----
>> From: McCann Peter-A001034 [mailto:[email-masked]]
>> Sent: Tuesday, June 19, 2007 12:14 PM
>> To: Christian Esteve; [email-masked]
>> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS
>> application
>>
>> Hi, Christian,
>>
>> Thanks for your comments, I would certainly like to take a look at
>> your paper.
>>
>> I suppose I could be convinced that local policy should be taken care

>> of with a separate interface, but I think it's important that IETF
>> standardize the inter-domain case as a first priority.
>> The local interface is less important to standardize now, because it
>> could easily be taken care of with a proprietary interface based on
>> purchasing decisions made by the operator, or it could easily be
>> incorporated in to the Network Element itself.  One of my goals for
>> the diameter-qos draft has been to facilitate the inter-working of
>> disparate application functions in different networks, and I think
>> that should be the focus of this draft.
>>
>> If we really want to add a new local PDP element to the draft I would

>> be ok with a modified Figure 1 that shows this.  However, the
>> Diameter cloud would then need to be shown between that entity and
>> the application server, and the document should focus on this latter
>> interface.  In other words, we should be standardizing Rx now.
>>
>> -Pete
>>
>> Christian Esteve wrote:
>>> Hi folks,
>>>
>>> the discussion thread reflects once again the confrontation between
>>> the operator SDO and the IETF worlds, and as it usually happens,
>>> disagreements are not only motivated by network engineering issues
>>> but by scope and nomenclature divergences.
>>>
>>>>> I guess I don't see why we need two separate interfaces.  They are

>>>>> each transporting roughly the same information and doing the same
>>>>> sort of job.
>>>
>>> It is true that the job and type of infomation are similar, however
>>> the separation of the interfaces makes sense to me. While one
>>> interface is used only to request QoS, the other is expected to
>>> carry and install QoS policy information (with different QoS
>>> descriptors).
>>>
>>> The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the
>>> architecture evolution of the SDOs that introduce policy-based
>>> resource control functions.
>>>
>>> It has been said that:
>>>>>>> There may be proxies in the
>>>>>>> Diameter cloud that enforce their own policy decisions, some of
>>>>>>> which will be local to the Network Element's administrative
>>>>>>> domain.
>>>
>>> To my understanding that is why the separated interfaces make sense.
>>>
>>> An intermediate PDP (also referred to as PDF) may enforce further
>>> policies (network type specific, user profile related,
>>> operator-based) in conjunction with other network elements (resource

>>> information, user database).
>>>
>>> Furthermore, the QoS description over the AF-PDP interface is likely

>>> to differ from the QoS information describing the policy to be
>>> instaslled in the NE, harmonizing and easing AF QoS requests and
>>> enabling the QoS policy installation mechanism to evolve separately
>>> in accordance to the transport network specifics.
>>>
>>> The PDP would certainly have an inter-domain interface to AFs and
>>> other inter- an intra PDPs. I bnelieve that the Diameter QoS
>>> application running between the AF and the PDP could be defined in a

>>> way that it could be applied for the inter-domain PDP-PDP peering
>>> interface.
>>>
>>> Unfortunately my contribution to the discussion at this point is not

>>> enriching the discussion regarding the implications to the Diameter
>>> functionality (e.g. command and AVPs, realm routing, discovery
>>> schemes, etc.).
>>>
>>> However, I am sharing under
>>> http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/
>>> some figures depicting the abstracted SDOs architectures that could
>>> help in the following discussions around the Diameter QoS
>>> application. The figures have been extracted from the the paper "A
>>> review on policy-based resource and admission control functions in
>>> evolving access and next generation networks", recently accepted for

>>> publication (draft copy can be provided if interested).
>>>
>>>
>>> Best regards,
>>> Christian
>>>>
>>>>

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime