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

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 13 Jun 2007 18:08:21 -0400

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 14 Jun 2007 15:32:40 -0400

IMHO it makes sense to separate AF and PDF functionalities depending on
the network topology/business model. It provides a single point of
contact for AF, if the service instance requires QoS reservations in
multiple networks/devices etc...

OTOH, I have no strong opinion in terms of where the inter-domain
boundary is going to be. It could be that both AF/PDF and PDF/PEP
interfaces are inter-domain for a specific service instance. Probably
this is not something for us to decide but we need to have the
flexibility to support all models (if possible).

I guess IETF QoS work can address both interfaces. PDF can act as a
Diameter proxy, Diameter B2BUA type of entity etc... or may not be in
the picture at all depending on the business model. What problem do we
see with this approach?

   Thanks,
   Tolga

> Sent: Wednesday, June 13, 2007 6:08 PM
> To: [email-masked]
> Subject: [Dime] FW: First draft on the integration of QoS application
> 
TSOU;

---

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

Hi, Tolga,

I agree that we should have the flexibility for the
diameter-qos application to be inter-domain.  As such,
we need to define everything needed to make that work
for both the push and pull modes, including discovery
and routing of messages end-to-end.

-Pete

Asveren, Tolga wrote:
> IMHO it makes sense to separate AF and PDF functionalities depending
> on the network topology/business model. It provides a single point of
> the picture at all depending on the business model. What problem do
> we see with this approach?   
> 
>    Thanks,
>    Tolga
> 
>> 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. 
>>> 
>>>> 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 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). 
>>>> 
>>>>> 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. 
>>>> 
>>>> 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.
>>>> 
>>>> 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
>>>>> 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
>>>> 
>>>>>>> net neutrality perspective), the packet (transport) network
>>>>>>> should support
>>>>>> 
>>>>>>> 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
>>>>>> 
>>>>>>> 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
>>>> 
>>>>>>>>> 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
>>>>>> 
>>>>>>>       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? 
>>>>>>> 
>>>>>>>>> the context); and add new subsections to addressing the
>>>>>>>>> endpoint features
>>>>>>> 
>>>>>>>>> and push/pull modes.
>>>>>>> 
>>>>>>> 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
>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> capability. If you have any words that can enhance the pull
>>>>>>> model, it
>>>>> 
>>>>>>> is very welcome :-).
>>>>>>> 
>>>>>>>>> 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
>>>> 
>>>>>>> server has to be co-located in the local domain.  This is not
>>>>>>> the way
>>>>> 
>>>>>>> [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
>>>>>>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 19 Jun 2007 17:36:21 -0400

Hi Pete,

I think I agree with you overall just I think we need to be careful
about what we mean with "discovery". It could be that it is better to
leave it implementation dependent/out of scope of Diameter QoS protocol,
how a Diameter node selects the next-hop for the initial request for a
session.

   Thanks,
   Tolga

> Sent: Tuesday, June 19, 2007 12:16 PM
> To: Asveren, Tolga; [email-masked]
> Subject: RE: [Dime] FW: First draft on the integration of QoS
application

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 19 Jun 2007 17:57:37 -0400

Hi, Tolga,

I think the next-hop for a session will be based on Diameter
routing based on the application ID and Destination-Realm AVP,
as specified in section 2.7 of the base protocol.  As such,
we need to provide guidance in how to set these parameters
in any request message used by the Diameter QoS application.
If this information is required from the underlying network
element that receives a QoS request, we should state that.
Similarly, if the information comes from an application server, 
we should at least give some overview of how the AS learns
this information in the inter-domain case.

-Pete

Asveren, Tolga wrote:
> leave it implementation dependent/out of scope of Diameter QoS
> protocol, how a Diameter node selects the next-hop for the initial
> request for a session.    
> 
>    Thanks,
>    Tolga
> 
>> I agree that we should have the flexibility for the diameter-qos
>> application to be inter-domain.  As such, we need to define
>> everything needed to make that work for both the push and pull
>> modes, including discovery and routing of messages end-to-end.
>> 
>> -Pete
>> 
>> 
>> Asveren, Tolga wrote:
>>> on the network topology/business model. It provides a single point
>>> of contact for AF, if the service instance requires QoS
>>> reservations in multiple networks/devices etc...
>>> 
>>> interfaces are inter-domain for a specific service instance.
>>> Probably this is not something for us to decide but we need to have
>>> the flexibility to support all models (if possible).
>>> 
>>> Diameter proxy, Diameter B2BUA type of entity etc... or may not be
>>> in the picture at all depending on the business model. What problem
>>> do we see with this approach? 
>>> 
>>>    Thanks,
>>>    Tolga
>>> 
>>>> 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
>>>> 
>>>>>> 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. 
>>>>>> 
>>>>>> 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. 
>>>>>> 
>>>>>> 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
>>>>>> 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.
>>>>>>> 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?
>>>>>> 
>>>>>>> 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,
>>>>>>>> 
>>>>>>>> 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
>>>>>> 
>>>>>>>>> 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
>>>>>> 
>>>>>>>>> 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
>>>>>> 
>>>>>>>>> network functionality. The authorizing entity is typically
>>>>>>>>> part of transport
>>>>>> 
>>>>>>>>> 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
>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>>>> and Tolga). There are some open issues to be done, I'd like
>>>>>>>>>>> to get
>>>>>> 
>>>>>>>>> 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
>>>>>>> 
>>>>>>>>> an arbitrary number of proxies that enforce their own
>>>>>>>>> policies, but there should be
>>>>>>>> 
>>>>>>>>> scenarios: for example, when authorizing requests from a
>>>>>>>>> static subscriber database. 
>>>>>>>>> 
>>>>>>>>>>> 3. section 3.3: minor revision on the models for pull;
>>>>>>>>>>> rewrite the
>>>>>> 
>>>>>>>>> and NE are in different administrative domains.  The push
>>>>>>>>> model is only applicable
>>>>>> 
>>>>>>>>> policy enforcement interface, whatever pull or push models. I
>>>>>>>>> am not
>>>>>> 
>>>>>>>>>>> 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. 
>>>>>>>>> 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
>>>>>> 
>>>>>>>>>>> 4. The current doc mainly talks about the QoS, should add
>>>>>>>>>>> some tint
>>>>>>>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 19 Jun 2007 18:09:42 -0400

Hi Pete,

I fully agree with the approach of providing information inline with
existing Diameter base protocol mechanisms. My worry was about defining
detailed procedures more on application level, e.g. how QoS AVPs need to
be processed/analyzed for routing decision. It may be an idea to touch
this topic briefly without normative text but I guess other than that,
this is really implementation dependent.

    Thanks,
    Tolga

> Sent: Tuesday, June 19, 2007 5:58 PM
application

---

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

Hi Tolga,

I fully agree on this idea. As stated in the discussion with Pete, I
think we only need to state how to support the discovery/routing from
the Diameter protocol capability perspective. How to configure the
network and detailed parameters/algorithms beyond Diameter protocol
level is out of scope in this doc.

Dong 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2007 6:10 PM
To: McCann Peter-A001034; [email-masked]
Subject: RE: [Dime] FW: First draft on the integration of QoS
application

Hi Pete,

    Thanks,
    Tolga

application
> 
> Hi, Tolga,
> 
> I think the next-hop for a session will be based on Diameter routing 
> based on the application ID and Destination-Realm AVP, as specified in

> section 2.7 of the base protocol.  As such, we need to provide 
> guidance in how to set these parameters in any request message used by

> the Diameter QoS application.
> If this information is required from the underlying network element 
> that receives a QoS request, we should state that.
> Similarly, if the information comes from an application server, we 
> should at least give some overview of how the AS learns this 
> information in the inter-domain case.
> 
> -Pete
> 
> Asveren, Tolga wrote:
> > Hi Pete,
> >