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

From: "Christian Esteve" <[email-masked]>
Date: Thu, 14 Jun 2007 15:53:50 -0300

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
>
>
> > ------------------------------
> >
> > Message: 5
> > Date: Wed, 13 Jun 2007 18:08:21 -0400
> > From: "McCann Peter-A001034" <[email-masked]>
> > Subject: [Dime] FW: First draft on the integration of QoS application
> > To: <[email-masked]>
> > Message-ID:
> >         <[email-masked]>
> > Content-Type: text/plain;       charset="us-ascii"
> >
> > Below is a discussion thread that has been taking place
> > among authors of the diameter-qos draft.  We thought it
> > important that the mailing list have some visibility
> > to the discussion.  Comments welcome.
> >
> > -Pete
> >
> > McCann Peter-A001034 wrote:
> > > Hi, Dong,
> > >
> > > 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.
> > >
> > > The current document in my mind has always been an inter-domain
> > > interface.  See the abstract:
> > >
> > > ...Clients that implement the Diameter QoS application contact an
> > >    authorizing entity/application server that is located somewhere in
> > >    the network, allowing for a wide variety of flexible deployment
> > >    models.
> > >
> > > And the following text in Section 3.2:
> > >
> > >    Inter-domain support
> > >
> > >       In particular, users may roam outside their home network,
> > >       leading to a situation where the network element and
> > >       authorizing entity are in different administrative domains.
> > >
> > > -Pete
> > >
> > > Sun, Dong (Dong) wrote:
> > >> Hi Pete,
> > >> I have no doubt about the importance of inter-domain policy
> > >> communications, and it might be better to use the Diameter broker
> > >> instead of SIP proxy to deal with inter-domain resource management.
> > >> In fact, I think 3GPP does use the similar model as you described,
> > >> that a Diameter broker (client) is embedded  in the AF (e.g. P-CSCF),
> > >> and the interface between AF and underlying Policy engine (e.g. PCRF)
> > >> is an inter-domain interface per se. certainly, since they (SIP and
> > >> Diameter brokers) are grouped together, it is less flexible and
> > >> scalable for the implementation.
> > >>
> > >> However, I think this interface (named as Rx in 3GPP, Gq' in TISPAN,
> > >> Rs in ITU) is not for the control of policy enforcement directly. In
> > >> my view, this interface (Rx) is a peering interface between policy
> > >> servers rather than between policy server and enforcement point as
> > >> described in the current QoS application, and I believe it is more
> > >> appropriate to model the inter-domain interface as the policy server
> > >> to policy server (PDF-PDF) peering interface.
> > >>
> > >> I have no problem to develop a doc to address this inter-domain
> > >> application, however, if you look around the current document, I did
> > >> not see any indication from that perspective.
> > >>
> > >> Dong
> > >>
> > >> -----Original Message-----
> > >> From: McCann Peter-A001034 [mailto:[email-masked]]
> > >> Sent: Wednesday, June 13, 2007 2:11 PM
> > >> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina TSOU;
> > >> Avri Doria Cc: Victor Fajardo
> > >> Subject: RE: First draft on the integration of QoS application
> > >>
> > >> Hi, Dong,
> > >>
> > >> Sun, Dong (Dong) wrote:
> > >>> Hi Pete,
> > >>>
> > >>> Thanks for clarification. Just wondering if you can give an example
> > >>> who will use the "inter-domain" model for policy enforcement
> > >>> control, i.e. PDP and PEP reside in the different operator's
> > >>> administrative domains. Since the inter-domain is to serve for the
> > >>> operator's domain, I don't know how to create an application
> > >>> without considering their need. (BTW, I have no strong view to
> > >>> limit it to intra-domain only if the use case can be identified).
> > >>
> > >> Arbitrary third parties should be allowed to deploy application
> > >> servers and interface to the Diameter cloud to get QoS from the
> > >> network.  The Diameter QoS Application should play this role.
> > >> In the extreme case, I should be allowed to put a SIP server in my
> > >> basement, sign up with a Diameter broker, and run my application
> > >> end-to-end.
> > >>
> > >>> I agree that this application should support "a generic mediator
> > >>> that can handle many applications". However, Given the integrated
> > >>> AS and AE, it makes the AE has to be collocated with the
> > >>> application content providers rather than the network itself, I
> > >>> feel it is also too limited and not the common case in reality. (As
> > >>> far as I know, all deployed or emerging network infrastructures
> > >>> such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view this solution as
> > >>> the main trend). I am wondering who will use this application
> > >>> eventually.
> > >>
> > >> I am not ruling out a PDP in the network local to the PEP.  I am just
> > >> saying that this PDP should be viewed as a Diameter proxy on the path
> > >> to the Authorizing Entity, which itself may be either a static
> > >> subscriber database or an active application server.
> > >> I don't want to work only on the localized protocol, I want to define
> > >> the inter-domain one.  If you insist on separating the AE from the AS
> > >> then I would say that the important Diameter interface is the one
> > >> between AE and AS.  It is much more important to standardize the
> > >> inter-domain interface because this is the one that will be used
> > >> between operators.
> > >>
> > >> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are
> > >> going down the path of using SIP proxies as the inter-domain
> > >> interface.  I think this architecture is bad for the Internet, and
> > >> will limit the kinds of applications that can be deployed.
> > >> The Internet model is that applications should be deployable without
> > >> modifying the middleboxes.  Tying SIP servers to the network traffic
> > >> path also doesn't work well with Mobile IP.
> > >>
> > >>> In addition, the scalable roaming agreements sound like a general
> > >>> algorithm that may be applicable for any inter-domain issue in the
> > >>> context of Diameter applications, or it is only the fundament to
> > >>> this application?
> > >>
> > >> The Diameter NASREQ application (similar to the basic RADIUS
> > >> protocol) has always been about inter-domain operation.  Diameter is
> > >> used as the mediating protocol between different operator domains.  I
> > >> think we should be following the same model with the Diameter QoS
> > >> application.
> > >>
> > >> -Pete
> > >>
> > >>> Dong
> > >>>
> > >>> -----Original Message-----
> > >>> From: McCann Peter-A001034 [mailto:[email-masked]]
> > >>> Sent: Wednesday, June 13, 2007 11:06 AM
> > >>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina
> > >>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the
> > >>> integration of QoS application
> > >>>
> > >>> Hi, Dong,
> > >>>
> > >>> An "Autonomous System" has a very specific meaning in the context of
> > >>> routing protocols; I would not want to say that they correspond
> > >>> one-to-one with the "domains" that exist when I talk about
> > >>> "inter-domain" in the context of diameter-qos.  I would say that
> > >>> "operator's administrative domain" is a better term.
> > >>>
> > >>> In any case, I think that the Diameter cloud from the figure 1
> > >>> should be a generic inter-domain mediator that can handle many
> > >>> applications, of which Diameter QoS is one.  The scalable roaming
> > >>> agreements embodied in this cloud should allow the Authorizing
> > >>> Entity to be anywhere in the network.  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.
> > >>> However, that should not impact the specification of the Diameter
> > >>> QoS Application. This inter-domain operation has been at the core
> > >>> of the document since I started it: see Section 3.2 in the -00
> > >>> version.
> > >>>
> > >>> -Pete
> > >>>
> > >>> Sun, Dong (Dong) wrote:
> > >>>> Hi Pete,
> > >>>>
> > >>>> Before making any conclusion, I'd like to clarify some terms:
> > >>>> Since you mentioned this is IETF, Internet and such, the domain you
> > >>>> refer to is in the context of the "Autonomous System" or
> > >>>> "operator's administrative domain".
> > >>>>
> > >>>> Dong
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: McCann Peter-A001034 [mailto:[email-masked]]
> > >>>> Sent: Wednesday, June 13, 2007 10:27 AM
> > >>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina
> > >>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the
> > >>>> integration of QoS application
> > >>>>
> > >>>> Hi, Dong,
> > >>>>
> > >>>> I think you and I have a fundamental disagreement on the scope and
> > >>>> purpose of this document.  I really don't see the need to
> > >>>> standardize
> > >>
> > >>>> an intra-domain localized solution to the problem.  This is IETF we
> > >>>> should be solving the problem for the whole Internet, which means
> > >>>> inter-domain is the target.  I understand that some operators might
> > >>>> not want to open their networks, but we should not be defining
> > >>>> standards for these closed architectures.
> > >>>>
> > >>>> I also feel strongly that we should have adequate discovery
> > >>>> mechanisms
> > >>>
> > >>>> for all modes of operation specified in this document; otherwise it
> > >>>> could lead to inter-operability problems.
> > >>>>
> > >>>> Hannes, I would like to note this as a serious issue that should be
> > >>>> resolved before we proceed any further.  I would like to check with
> > >>>> the mailing list and the ADs on their preferences.  What do you
> > >>>> think
> > >>
> > >>>> would be the appropriate way to introduce the issue?  Would you
> > >>>> like to introduce the question to the mailing list?
> > >>>>
> > >>>> -Pete
> > >>>>
> > >>>> Sun, Dong (Dong) wrote:
> > >>>>> Hi Pete,
> > >>>>>
> > >>>>> First of all, Thanks for the review and comments.
> > >>>>>
> > >>>>> 1. Concerning the split of Application Server and Authorizing
> > >>>>> Entity,
> > >>>
> > >>>>> which is somewhat related to another main comment you brought up
> > >>>>> i.e. the relationship between Authorizing Entity and NE -
> > >>>>> inter-domain Vs. intra-domain, the rationale in my mind is as
> > >>>>> follow: - In the real network (or the vision of NGN, or somewhat
> > >>>>> the
> > >>
> > >>>>> net neutrality perspective), the packet (transport) network should
> > >>>>> support
> > >>>>
> > >>>>> a variety of applications which may belong to different SPs i.e.
> > >>>>> in different domain. The PDP (i.e. Authorizing entity in the
> > >>>>> context of
> > >>
> > >>>>> QoS application) can act as the arbitrator to isolate the
> > >>>>> diversity of application attributes from the speciality of network
> > >>>>> functionality. The authorizing entity is typically part of
> > >>>>> transport
> > >>
> > >>>>> network domain along with the NEs since the network operators are
> > >>>>> commonly willing to
> > >>>>
> > >>>>> neither rely on the third party to control the use of their
> > >>>>> network resources nor disclose the network details (e.g.
> > >>>>> topology, resource usage and policies) to other carriers/SPs.
> > >>>>> Therefore, the common case is that the interface between
> > >>>>> Authorizing entity and NE (enforcement point) should be
> > >>>>> intra-domain in nature.
> > >>>>>
> > >>>>> - On the other hand, the interface between AS and AE can be
> > >>>>> inter-domain, which also makes the life easier concerning the
> > >>>>> inter-domain enforcement interface.
> > >>>>>
> > >>>>> - The policy communications between different domains is quite
> > >>>>> important, for example, for the roaming scenario. However, it is
> > >>>>> outside the scope of this application if my understanding is
> > >>>>> correct. I feel it is better to be solved through
> > >>>>> inter-Authorizing Entity interface rather than this interface.
> > >>>>> Certainly, the command and AVPs
> > >>>
> > >>>>> might be shared, but I would rather not mix them together for the
> > >>>>> time being.
> > >>>>>
> > >>>>> 2. Concerning the discovery mechanism for Push mode, I agree that
> > >>>>> it
> > >>
> > >>>>> is a tricky issue and also support to describe the issue in the
> > >>>>> document. However, I'd like to point out, this document should
> > >>>>> concentrate on the protocol related issue and allow the
> > >>>>> flexibility to use the other discovery mechanism beyond the
> > >>>>> Diameter protocol capability. In other words, we mainly need to
> > >>>>> define some mechanism based on Diameter protocol's capability,
> > >>>>> such as the realm based routing, and leave the door open for
> > >>>>> other advanced discovery schemes.
> > >>>>>
> > >>>>> See additional comment in line...
> > >>>>>
> > >>>>> Regards,
> > >>>>> Dong
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: McCann Peter-A001034 [mailto:[email-masked]]
> > >>>>> Sent: Tuesday, June 12, 2007 5:26 PM
> > >>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina
> > >>>>> TSOU;
> > >>
> > >>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the
> > >>>>> integration of QoS application
> > >>>>>
> > >>>>> Hi, all,
> > >>>>>
> > >>>>> Please see my comments in line.
> > >>>>>
> > >>>>> Hannes Tschofenig wrote:
> > >>>>>> Hi all,
> > >>>>>>
> > >>>>>> could you please take a look at the proposal by Dong?
> > >>>>>>
> > >>>>>> They are available here:
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft
> > >> -i
> > >>>>> etf-dime-diameter-qos-01-ds.txt
> > >>>>>>
> > >>>>>> The XML file is in the same directory, as usual.
> > >>>>>>
> > >>>>>> Ciao
> > >>>>>> Hannes
> > >>>>>>
> > >>>>>> Sun, Dong (Dong) wrote:
> > >>>>>>> Hi Hannes et al,
> > >>>>>>>
> > >>>>>>> Attached is the first cut to integrate two I-Ds. The change is a
> > >>>>>>> minimum set based on the comments from the exploder (Tina,
> > >>>>>>> Christian
> > >>>>
> > >>>>>>> and Tolga). There are some open issues to be done, I'd like to
> > >>>>>>> get
> > >>
> > >>>>>>> your comments on changes first and discuss how to proceed on
> > >>>>>>> those
> > >>
> > >>>>>>> open items before making any further editings. Main changes:
> > >>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes
> > >>>>>
> > >>>>> In the definition of Pull mode, the following sentence
> > >>>>>       The Authorizing Entity then installs the QoS
> > >>>>>       authorization decision to the Network Element initiatively.
> > >>>>> needs work.  "initiatively" is not a word.
> > >>>>>
> > >>>>> [DS] ok. Any good word? Basically I don't like some words such as
> > >>>>> unsolicited since it is used by 3GPP for different meaning. Maybe
> > >>>>> "directly" instead?
> > >>>>>
> > >>>>>>> 2. section 3.1/2: modify the architecture diagram to separate
> > >>>>>>> the Authorizing Entity from AS (further alignment is needed in
> > >>>>>>> the context); and add new subsections to addressing the endpoint
> > >>>>>>> features
> > >>>>>
> > >>>>>>> and push/pull modes.
> > >>>>>
> > >>>>> Breaking up the AS and AE implies that there will be another
> > >>>>> interface
> > >>>>
> > >>>>> yet to be defined.  I would rather not open up this possibility.
> > >>>>> The
> > >>>
> > >>>>> Diameter QoS application should be usable all the way from network
> > >>>>> element to application server, perhaps passing through an
> > >>>>> arbitrary number of proxies that enforce their own policies, but
> > >>>>> there should be
> > >>>>
> > >>>>> 1 interface not 2.  Also, it is important to note that the AS need
> > >>>>> not
> > >>>>
> > >>>>> be present at all in some
> > >>>>> scenarios: for example, when authorizing requests from a static
> > >>>>> subscriber database.
> > >>>>>
> > >>>>> [DS] First of all, I don't intend to standardize the interface
> > >>>>> between
> > >>>>
> > >>>>> AS and AE in this application. Second, I am not sure why the
> > >>>>> separate
> > >>>
> > >>>>> of AS and AE prevents the AE access to a static subscriber
> > >>>>> database. The basic rationale is address as aforementioned.
> > >>>>>
> > >>>>>>> 3. section 3.3: minor revision on the models for pull; rewrite
> > >>>>>>> the
> > >>
> > >>>>>>> push model (Tina, pls take a look)
> > >>>>>
> > >>>>> 3.2 looks new.  It seems to be overly weighted in favor of the
> > >>>>> push model.  I would like to point out that there is a big
> > >>>>> discovery problem with the push model, especially when the AE and
> > >>>>> NE are in different administrative domains.  The push model is
> > >>>>> only applicable
> > >>
> > >>>>> to the case where the AE and the NE are in the same administrative
> > >>>>> domain and therefore it is a special case.
> > >>>>>
> > >>>>> [DS] I think in reality the operators mainly look at the
> > >>>>> intra-domain
> > >>>
> > >>>>> policy enforcement interface, whatever pull or push models. I am
> > >>>>> not
> > >>
> > >>>>> in favor of any specific models, just analyze the impact of
> > >>>>> endpoint's
> > >>>>
> > >>>>> capability. If you have any words that can enhance the pull model,
> > >>>>> it
> > >>>
> > >>>>> is very welcome :-).
> > >>>>>
> > >>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section
> > >>>>>>> 7.4 and
> > >>>>>
> > >>>>>>> table. But the name still remains in some texts.
> > >>>>>>>
> > >>>>>>> To be done:
> > >>>>>>> 1. state mechanism for Push mode: server initiated policy
> > >>>>>>> installation 2. should section 4.4 be merged with section 4.2
> > >>>>>>> since
> > >>>
> > >>>>>>> both them discuss how to initiate a new Diameter session? In
> > >>>>>>> addition, the text needs to be beefed up for server initiated
> > >>>>>>> session.
> > >>>>>>> 3. authorization schemes/models for Pull: inter-domain
> > >>>>>>> authorization
> > >>>>
> > >>>>>>> between authorizing entity and NE is not envisaged as the basic
> > >>>>>>> model, should be revised in the context; Token based approach is
> > >>>>>>> not
> > >>>>
> > >>>>>>> the main trend, should be shortened.
> > >>>>>
> > >>>>> We need to have inter-domain authorization as the basic scenario;
> > >>>>> local authorization should be treated as a special case.  The
> > >>>>> whole point is to leverage the inter-domain capability of
> > >>>>> Diameter to mediate between network elements and authorizing
> > >>>>> entities, whether the AEs are application servers or static
> > >>>>> subscriber databases.
> > >>>>>
> > >>>>> [DS] I agree that inter-domain authorization/policy communication
> > >>>>> is
> > >>
> > >>>>> important, but the mechanism and scope of this document is
> > >>>>> inappropriate to solve that issue, since it is not the right way
> > >>>>> forward envisioned by the industry and operators.
> > >>>>>
> > >>>>> If we only solve the local case it will mean that an application
> > >>>>> server has to be co-located in the local domain.  This is not the
> > >>>>> way
> > >>>
> > >>>>> the Internet is supposed to work: services should be deployable
> > >>>>> end-to-end, without modifying elements of the network along the
> > >>>>> path. It should be possible for the application server to be
> > >>>>> located
> > >>
> > >>>>> anywhere in the network and the AAA part should just work.
> > >>>>>
> > >>>>> [DS] as I said, the AS and AE can be in different domains. On the
> > >>>>> other hand, if we integrate the AS with AE together, it impose a
> > >>>>> tight
> > >>>>
> > >>>>> coupled service model, i.e. AS and AE always have to be in the
> > >>>>> same domain. Exactly the issue you are concerned.
> > >>>>>
> > >>>>>>> 4. The current doc mainly talks about the QoS, should add some
> > >>>>>>> tint
> > >>>
> > >>>>>>> on the policy control side.
> > >>>>>>>
> > >>>>>>> Please let me know your opinion and how to proceed.
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> Dong
> > >>>>>
> > >>>>> -Pete
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> > End of DiME Digest, Vol 18, Issue 13
> > ************************************
> >

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

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 19 Jun 2007 12:14:18 -0400

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:
> interface is used only to request QoS, the other is expected to carry
> and install QoS policy information (with different QoS descriptors). 
> 
>>> Below is a discussion thread that has been taking place among
>>> authors of the diameter-qos draft.  We thought it important that the
>>> mailing list have some visibility to the discussion.  Comments
>>> welcome. 
>>> 
>>> -Pete
>>> 
>>>>    authorizing entity/application server that is located somewhere
>>>>    in the network, allowing for a wide variety of flexible
>>>> deployment    models. 
>>>> 
>>>>> In fact, I think 3GPP does use the similar model as you
>>>>> described, that a Diameter broker (client) is embedded  in the AF
>>>>> (e.g. P-CSCF), and the interface between AF and underlying Policy
>>>>> engine (e.g. PCRF) is an inter-domain interface per se.
>>>>> certainly, since they (SIP and Diameter brokers) are grouped
>>>>> together, it is less flexible and scalable for the implementation.
>>>>> 
>>>>> However, I think this interface (named as Rx in 3GPP, Gq' in
>>>>> TISPAN, Rs in ITU) is not for the control of policy enforcement
>>>>> directly. In my view, this interface (Rx) is a peering interface
>>>>> between policy servers rather than between policy server and
>>>>> enforcement point as described in the current QoS application,
>>>>> and I believe it is more appropriate to model the inter-domain
>>>>> interface as the policy server to policy server (PDF-PDF) peering
>>>>> interface. 
>>>>> 
>>>>> application, however, if you look around the current document, I
>>>>> did not see any indication from that perspective.
>>>>> 
>>>>> Dong
>>>>> 
>>>>> TSOU; Avri Doria Cc: Victor Fajardo
>>>>>> Thanks for clarification. Just wondering if you can give an
>>>>>> example who will use the "inter-domain" model for policy
>>>>>> enforcement control, i.e. PDP and PEP reside in the different
>>>>>> operator's administrative domains. Since the inter-domain is to
>>>>>> serve for the operator's domain, I don't know how to create an
>>>>>> application without considering their need. (BTW, I have no
>>>>>> strong view to limit it to intra-domain only if the use case can
>>>>>> be identified). 
>>>>> 
>>>>> In the extreme case, I should be allowed to put a SIP server in
>>>>> my basement, sign up with a Diameter broker, and run my
>>>>> application end-to-end.
>>>>> 
>>>>>> that can handle many applications". However, Given the
>>>>>> integrated AS and AE, it makes the AE has to be collocated with
>>>>>> the application content providers rather than the network
>>>>>> itself, I feel it is also too limited and not the common case in
>>>>>> reality. (As far as I know, all deployed or emerging network
>>>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view
>>>>>> this solution as the main trend). I am wondering who will use
>>>>>> this application eventually.
>>>>> 
>>>>> I am not ruling out a PDP in the network local to the PEP.  I am
>>>>> just saying that this PDP should be viewed as a Diameter proxy on
>>>>> the path to the Authorizing Entity, which itself may be either a
>>>>> static subscriber database or an active application server.
>>>>> I don't want to work only on the localized protocol, I want to
>>>>> define the inter-domain one.  If you insist on separating the AE
>>>>> from the AS then I would say that the important Diameter
>>>>> interface is the one between AE and AS.  It is much more
>>>>> important to standardize the inter-domain interface because this
>>>>> is the one that will be used between operators.
>>>>> 
>>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they
>>>>> are going down the path of using SIP proxies as the inter-domain
>>>>> interface.  I think this architecture is bad for the Internet,
>>>>> and will limit the kinds of applications that can be deployed.
>>>>> The Internet model is that applications should be deployable
>>>>> without modifying the middleboxes.  Tying SIP servers to the
>>>>> network traffic path also doesn't work well with Mobile IP.
>>>>> 
>>>>>> In addition, the scalable roaming agreements sound like a
>>>>>> general algorithm that may be applicable for any inter-domain
>>>>>> issue in the context of Diameter applications, or it is only the
>>>>>> fundament to this application?
>>>>> 
>>>>> protocol) has always been about inter-domain operation.  Diameter
>>>>> is used as the mediating protocol between different operator
>>>>> domains.  I think we should be following the same model with the
>>>>> Diameter QoS application.
>>>>> 
>>>>> -Pete
>>>>> 
>>>>>> Dong
>>>>>> 
>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on
>>>>>> the integration of QoS application
>>>>>> 
>>>>>> Hi, Dong,
>>>>>> 
>>>>>> An "Autonomous System" has a very specific meaning in the
>>>>>> context of routing protocols; I would not want to say that they
>>>>>> correspond one-to-one with the "domains" that exist when I talk
>>>>>> about "inter-domain" in the context of diameter-qos.  I would
>>>>>> say that "operator's administrative domain" is a better term.
>>>>>> 
>>>>>> applications, of which Diameter QoS is one.  The scalable
>>>>>> roaming agreements embodied in this cloud should allow the
>>>>>> Authorizing Entity to be anywhere in the network.  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. However, that should not impact the
>>>>>> specification of the 
>>>>>> Diameter QoS Application. This inter-domain operation has been
>>>>>> at the core of the document since I started it: see Section 3.2
>>>>>> in the -00 version.
>>>>>> 
>>>>>> -Pete
>>>>>> 
>>>>>> Sun, Dong (Dong) wrote:
>>>>>>> Hi Pete,
>>>>>>> 
>>>>>>> Since you mentioned this is IETF, Internet and such, the domain
>>>>>>> you refer to is in the context of the "Autonomous System" or
>>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on
>>>>>>> the integration of QoS application
>>>>>>> 
>>>>>>> Hi, Dong,
>>>>>>> 
>>>>>>> I think you and I have a fundamental disagreement on the scope
>>>>>>> and purpose of this document.  I really don't see the need to
>>>>>>> standardize
>>>>> 
>>>>>>> an intra-domain localized solution to the problem.  This is
>>>>>>> IETF we should be solving the problem for the whole Internet,
>>>>>>> which means inter-domain is the target.  I understand that some
>>>>>>> operators might not want to open their networks, but we should
>>>>>>> not be defining standards for these closed architectures.
>>>>>>> 
>>>>>>> for all modes of operation specified in this document;
>>>>>>> otherwise it could lead to inter-operability problems.
>>>>>>> 
>>>>>>> Hannes, I would like to note this as a serious issue that
>>>>>>> should be resolved before we proceed any further.  I would like
>>>>>>> to check with the mailing list and the ADs on their
>>>>>>> preferences.  What do you think
>>>>> 
>>>>>>>> which is somewhat related to another main comment you brought
>>>>>>>> up i.e. the relationship between Authorizing Entity and NE -
>>>>>>>> follow: - In the real network (or the vision of NGN, or
>>>>>>>> somewhat the
>>>>> 
>>>>>>>> net neutrality perspective), the packet (transport) network
>>>>>>>> should support
>>>>>>> 
>>>>>>>> a variety of applications which may belong to different SPs
>>>>>>>> i.e. in different domain. The PDP (i.e. Authorizing entity in
>>>>>>>> the context of
>>>>> 
>>>>>>>> diversity of application attributes from the speciality of
>>>>>>>> network functionality. The authorizing entity is typically
>>>>>>>> part of transport
>>>>> 
>>>>>>>> network domain along with the NEs since the network operators
>>>>>>>> are commonly willing to
>>>>>>> 
>>>>>>>> important, for example, for the roaming scenario. However, it
>>>>>>>> is outside the scope of this application if my understanding
>>>>>>>> is correct. I feel it is better to be solved through
>>>>>>>> might be shared, but I would rather not mix them together for
>>>>>>>> the time being. 
>>>>>>>> 
>>>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree
>>>>>>>> that it
>>>>> 
>>>>>>>> is a tricky issue and also support to describe the issue in
>>>>>>>> the document. However, I'd like to point out, this document
>>>>>>>> should concentrate on the protocol related issue and allow the
>>>>>>>> Diameter protocol capability. In other words, we mainly need
>>>>>>>> to define some mechanism based on Diameter protocol's
>>>>>>>> capability, such as the realm based routing, and leave the
>>>>>>>> door open for other advanced discovery schemes.
>>>>>>>> 
>>>>>>>>>> Attached is the first cut to integrate two I-Ds. The change
>>>>>>>>>> is a minimum set based on the comments from the exploder
>>>>>>>>>> (Tina, Christian
>>>>>>> 
>>>>>>>>>> and Tolga). There are some open issues to be done, I'd like
>>>>>>>>>> to get
>>>>> 
>>>>>>>>       authorization decision to the Network Element
>>>>>>>> initiatively. needs work.  "initiatively" is not a word.
>>>>>>>> 
>>>>>>>> [DS] ok. Any good word? Basically I don't like some words such
>>>>>>>> as unsolicited since it is used by 3GPP for different meaning.
>>>>>>>> Maybe "directly" instead? 
>>>>>>>> 
>>>>>>>>>> 2. section 3.1/2: modify the architecture diagram to
>>>>>>>>>> separate the Authorizing Entity from AS (further alignment
>>>>>>>>>> is needed in the context); and add new subsections to
>>>>>>>>>> addressing the endpoint features
>>>>>>>> 
>>>>>>>>>> and push/pull modes.
>>>>>>>> 
>>>>>>>> yet to be defined.  I would rather not open up this
>>>>>>>> possibility. The
>>>>>> 
>>>>>>>> Diameter QoS application should be usable all the way from
>>>>>>>> network element to application server, perhaps passing through
>>>>>>>> an arbitrary number of proxies that enforce their own
>>>>>>>> policies, but there should be
>>>>>>> 
>>>>>>>> 1 interface not 2.  Also, it is important to note that the AS
>>>>>>>> need not
>>>>>>> 
>>>>>>>> scenarios: for example, when authorizing requests from a
>>>>>>>> static subscriber database.
>>>>>>>> 
>>>>>>>>>> 3. section 3.3: minor revision on the models for pull;
>>>>>>>>>> rewrite the
>>>>> 
>>>>>>>> discovery problem with the push model, especially when the AE
>>>>>>>> and NE are in different administrative domains.  The push
>>>>>>>> model is only applicable
>>>>> 
>>>>>>>> to the case where the AE and the NE are in the same
>>>>>>>> administrative domain and therefore it is a special case.
>>>>>>>> 
>>>>>>>> policy enforcement interface, whatever pull or push models. I
>>>>>>>> am not
>>>>> 
>>>>>>>> capability. If you have any words that can enhance the pull
>>>>>>>> model, it
>>>>>> 
>>>>>>>> is very welcome :-).
>>>>>>>> 
>>>>>>>>>> installation 2. should section 4.4 be merged with section
>>>>>>>>>> 4.2 since
>>>>>> 
>>>>>>>>>> addition, the text needs to be beefed up for server
>>>>>>>>>> initiated session. 
>>>>>>>>>> between authorizing entity and NE is not envisaged as the
>>>>>>>>>> basic model, should be revised in the context; Token based
>>>>>>>>>> approach is not
>>>>>>> 
>>>>>>>> We need to have inter-domain authorization as the basic
>>>>>>>> scenario; local authorization should be treated as a special
>>>>>>>> case.  The whole point is to leverage the inter-domain
>>>>>>>> capability of Diameter to mediate between network elements and
>>>>>>>> authorizing entities, whether the AEs are application servers
>>>>>>>> or static subscriber databases.
>>>>>>>> 
>>>>>>>> [DS] I agree that inter-domain authorization/policy
>>>>>>>> communication is
>>>>> 
>>>>>>>> inappropriate to solve that issue, since it is not the right
>>>>>>>> way forward envisioned by the industry and operators.
>>>>>>>> 
>>>>>>>> If we only solve the local case it will mean that an
>>>>>>>> application server has to be co-located in the local domain.
>>>>>>>> This is not the way
>>>>>> 
>>>>>>>> the Internet is supposed to work: services should be
>>>>>>>> deployable end-to-end, without modifying elements of the
>>>>>>>> network along the path. It should be possible for the
>>>>>>>> application server to be located
>>>>> 
>>>>>>>> [DS] as I said, the AS and AE can be in different domains. On
>>>>>>>> the other hand, if we integrate the AS with AE together, it
>>>>>>>> impose a tight
>>>>>>> 
>>>>>>>>>> 4. The current doc mainly talks about the QoS, should add
>>>>>>>>>> some tint
>>>>>>

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 19 Jun 2007 17:26:51 -0500

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

>>>>> that a Diameter broker (client) is embedded  in the AF (e.g. 
>>>>> P-CSCF), and the interface between AF and underlying Policy engine

>>>>> (e.g. PCRF) is an inter-domain interface per se.
>>>>> enforcement point as described in the current QoS application, and

>>>>> I believe it is more appropriate to model the inter-domain 

>>>>>> feel it is also too limited and not the common case in reality. 
>>>>>> (As far as I know, all deployed or emerging network 
>>>>> from the AS then I would say that the important Diameter interface

>>>>> is the one between AE and AS.  It is much more important to 
>>>>> standardize the inter-domain interface because this is the one 
>>>>> that will be used between operators.
>>>>> 

>>>>>> algorithm that may be applicable for any inter-domain issue in 
>>>>>> the context of Diameter applications, or it is only the fundament

>>>>>> to this application?
>>>>>> An "Autonomous System" has a very specific meaning in the context

>>>>>> of routing protocols; I would not want to say that they 
>>>>>> about "inter-domain" in the context of diameter-qos.  I would say

>>>>>> that "operator's administrative domain" is a better term.
>>>>>> 

>>>>>> Entity to be anywhere in the network.  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. However, that should not impact the specification of the 
>>>>>> Diameter QoS Application. This inter-domain operation has been at

>>>>>> the core of the document since I started it: see Section 3.2 in 
>>>>>> the -00 version.
>>>>>> 
>>>>>> -Pete
>>>>>> 
>>>>>> Sun, Dong (Dong) wrote:
>>>>>>> Hi Pete,
>>>>>>> 
>>>>>>> an intra-domain localized solution to the problem.  This is IETF

>>>>>>> we should be solving the problem for the whole Internet, which 
>>>>>>> means inter-domain is the target.  I understand that some 
>>>>>>> for all modes of operation specified in this document; otherwise

>>>>>>> it could lead to inter-operability problems.
>>>>>>> 
>>>>>>> Hannes, I would like to note this as a serious issue that should

>>>>>>> be resolved before we proceed any further.  I would like to 
>>>>>>> check with the mailing list and the ADs on their preferences.  
>>>>>>> What do you think
>>>>> 
>>>>>>>> network functionality. The authorizing entity is typically part

>>>>>>>> of transport
>>>>>>>> is outside the scope of this application if my understanding is

>>>>>>>>>> the Authorizing Entity from AS (further alignment is needed 
>>>>>>>>>> in the context); and add new subsections to addressing the 
>>>>>>>>>> endpoint features
>>>>>>>> 
>>>>>>>>>> and push/pull modes.
>>>>>>>> 
>>>>>>>> an arbitrary number of proxies that enforce their own policies,

>>>>>>>> but there should be

>>>>>>>> and NE are in different administrative domains.  The push model

>>>>>>>> is only applicable

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 20 Jun 2007 08:08:08 -0400

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

> From: Sun, Dong (Dong) [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2007 6:27 PM
> To: McCann Peter-A001034; Christian Esteve; [email-masked]
be
> > interface is used only to request QoS, the other is expected to
carry
> > recently accepted for publication (draft copy can be provided if
described,
> >>>>> enforcement point as described in the current QoS application,
and
> >>>>> In the extreme case, I should be allowed to put a SIP server in
my
> >>>>>> that can handle many applications". However, Given the
integrated
interface
> >>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they
are
> >>>>> interface.  I think this architecture is bad for the Internet,
and
> >>>>>> In addition, the scalable roaming agreements sound like a
general
> >>>>>> An "Autonomous System" has a very specific meaning in the
context
> >>>>>> about "inter-domain" in the context of diameter-qos.  I would
say
> >>>>>> applications, of which Diameter QoS is one.  The scalable
roaming
> >>>>>> Diameter QoS Application. This inter-domain operation has been
at
> >>>>>>> an intra-domain localized solution to the problem.  This is
IETF
> >>>>>>> for all modes of operation specified in this document;
otherwise
> >>>>>>> Hannes, I would like to note this as a serious issue that
should
> >>>>>>>> network functionality. The authorizing entity is typically
part
is
the
> >>>>>>>> Diameter protocol capability. In other words, we mainly need
to
> >>>>>>>>> could you please take a look at the proposal by Dong?
http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/dra
> >>> ft
separate
> >>>>>>>> an arbitrary number of proxies that enforce their own
policies,
> >>>>>>>> scenarios: for example, when authorizing requests from a
static
> >>>>>>>> and NE are in different administrative domains.  The push
model
> >>>>>>>>>> addition, the text needs to be beefed up for server
initiated
> >>>>>>>> the Internet is supposed to work: services should be
deployable

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 20 Jun 2007 12:25:32 -0400

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.
> 
> 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
>> 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
>> 
>> Thanks for your comments, I would certainly like to take a look at
>> your paper. 
>> 
>> care of with a separate interface, but I think it's important that
>> IETF standardize the inter-domain case as a first priority.
>> 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
>>> operator-based) in conjunction with other network elements
>>> (resource information, user database). 
>>> 
>>> help in the following discussions around the Diameter QoS
>>> application. The figures have been extracted

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 20 Jun 2007 17:57:19 -0500

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

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

>> be ok with a modified Figure 1 that shows this.  However, the 

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