Subject: Re: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information"

From: "Christian Esteve" <[email-masked]>
Date: Thu, 12 Jul 2007 09:33:28 -0300

Hi Tina,

Agree that the AF should not be involved at network level QoS, I  should be
more careful when explaining my thoughts, actually what I wanted to point
out is that some kind of access network information (obtained by P-header,
NASS query, or other means.) could be used to assist the AE with regards to
its mode of operation and the appropriate service/QoS mapping. Agree that
the NE is better suited to map generic QoS into access specific QoS.
Handling with generic QoS at the AE enables inter-domain AE communications.

I was thinking on the following scenario: A single Application Server is
supposed to interact with various Authorization Entities (1:n relationship
between AS and AE, actually m:n should be the general case), each of them
responsible for the NEs belonging to different access network technologies.

AS:                        : AF (P-CSCF)

                   /                      |                       \

AEs:     PDF(3GPP)     PDF (WLAN)      PDF (WiMax)
.
NEs:           x  x  x                  x x x                  x x x

These are my thoughts:

1. The AS needs to know which is the AE responsible for authorizing the
current session. The AS can query another entity (NASS) or based its AE
selection on information provided at application level signaling (e.g. SIP
P-headers.). Furthermore, the service attribute provided by the AS may
differ (e.g. due to different capabilities or semantics supported) depending
on the correspondent AE.
Is this out-of-scope of the dime-qos doc? Any relation to the discovery
mechanisms under study for Diameter?

2. The AE needs to know in which mode to operate (push or pull) for the
session being authorized based on information coming from the AS and/or the
NE.
What information should be defined with these regards? Is there a convergent
set of AVPs for both the AS-AE and AE-NE communications to inform about the
mode of operation (push/pull, e.g. Operation-Mode AVP) and carry access
network info (also referred to as Terminal-Mode AVP by Tina)?

3. I think the last version of the Framework description covers the
discussed topics or do we still miss something?

Regards,
Christian

> 3 Framework
> [snipped]
> <t>In some deployment scenarios, QoS aware network elements may request
>      authorization through the AAA cloud based on an incoming QoS
> reservation
>      request. The network element will route the request to a designated
>      authorizing entity. The authorizing entity will return the result of
> the
>      authorization decision. In other deployment scenarios, the
> authorization
>      will be initiated upon dynamic application state, so that the request
>      must be authenticated and authorized based on information from one or
>      more application servers. /*start of added*/In terms of the resource
> request sent from
>      the application server to Authorizing Entity, the Authorizing Entity
>      could identify the access network related information and select
> appropriate
>      resource admission and control policies. The Push or pull mode also
> can be
>      dynamically triggered based on the information in the request from
> application
>   server, or statically configured according to operator's demand./*end of
> added*/</t>
> [snipped]

----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Jul 2007 14:39:40 +0800
> From: Tina TSOU <[email-masked]>
> Subject: Re: [Dime] Diameter QoS        Appl.-"PULL/PUSH/Access network
>         related Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network
>         related information"
> To: Christian Esteve <[email-masked]>, [email-masked], Hannes
>         Tschofenig <[email-masked]>, Tina TSOU <[email-masked]
> >
> Message-ID: < [email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Christian,
> Moreover,
> For mobile terminals, AF can get access network identifier from SIP
> message header.
> For fix terminals, AF can query the access network identifier via e2
> interface. The way carried by SIP is not granted by consensus.
>
> B. R.
> Tina
>
>   ----- Original Message -----
>   From: Tina TSOU
>   To: Hannes Tschofenig ; [email-masked] ; Christian Esteve
>   Sent: Thursday, July 12, 2007 2:11 PM
>   Subject: Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related
> Re: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network related information"
>
>
>
>   Hi Christian,
>   Actually, the QoS template is not chosen by AF (mapping to Application
> Server here). It is determined by the policy in SPDF (mapping to Authorizing
> Entity here) according to related information sent from AF to SPDF. There is
> no need for AF to see the template information.
>
>   B. R.
>   Tina
>   Messengers:
>   MSN: [email-masked]   Yahoo: tina_tsou    Skype:
> tinaTSOU    Jabber: [email-masked]    Google talk: [email-masked]
>
>
>   ----- Original Message -----
>   From: Sun, Dong (Dong)
>   To: Christian Esteve ; [email-masked] ; Tina TSOU ; Hannes Tschofenig
>   Sent: Thursday, July 12, 2007 7:04 AM
>   Subject: RE: [Dime] Diameter QoS Appl.- "PULL/PUSH/Access network
> related Re:[Dime] Diameter QoS Appl.- "PULL/PUSH/Access network
> relatedinformation"
>
>
>   Hi Chirstian,
>
>   I agree, in certain circumstance e.g. IMS AF, it is possible to identify
> the access network as you described.
>   Maybe, I guess, there is some confusion (to me) on the terminology used
> here. If you are saying that AF may determine the service profile/attributes
> upon access type, it would be fine in certain case (but it is out of the
> scope in this doc). However, not sure if it is good idea to make the
> application server involved in network level QoS selection, even it is worse
> to make the AS select access specific QoS profile.
>
>   Regards,
>   Dong
>
>
>
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 12 Jul 2007 10:24:45 -0400

I don't think we should be designing a protocol that
behaves differently depending on the type of access
link.  Everything in the Diameter cloud should be
dealing exclusively with link-neutral QoS specifications,
which will enable inter-domain operation and simplify
settlement.

Solutions that assume some SIP signaling from the endpoint
to identify / classify the first-hop NE are limited.  The
QoS enforcement point may not be the first hop; in general
any NE along the path between the two hosts involved in
the call might need to play this role.  I think the push
model has some serious problems with discovering this 
type of NE.  The right solution is to require end-to-end,
path-coupled signaling like NSIS with the pull mode of
operation.  

-Pete

Christian Esteve wrote:
> Hi Tina,
> 
> Agree that the AF should not be involved at network level QoS, I 
> should be more careful when explaining my thoughts, actually what I
> wanted to point out is that some kind of access network information
> (obtained by P-header, NASS query, or other means.) could be used to
> assist the AE with regards to its mode of operation and the
> appropriate service/QoS mapping. Agree that the NE is better suited
> to map generic QoS into access specific QoS. Handling with generic
> QoS at the AE enables inter-domain AE communications.       
> 
> I was thinking on the following scenario: A single Application Server
> is supposed to interact with various Authorization Entities (1:n
> relationship between AS and AE, actually m:n should be the general
> case), each of them responsible for the NEs belonging to different
> access network technologies.    
> 
> AS:                        : AF (P-CSCF)
> 
>                    /                      |                       \
> 
> 1. The AS needs to know which is the AE responsible for authorizing
> the current session. The AS can query another entity (NASS) or based
> its AE selection on information provided at application level
> signaling ( e.g. SIP P-headers.). Furthermore, the service attribute
> provided by the AS may differ (e.g. due to different capabilities or
> semantics supported) depending on the correspondent AE.     
> Is this out-of-scope of the dime-qos doc? Any relation to the
> discovery mechanisms under study for Diameter? 
> 
> 2. The AE needs to know in which mode to operate (push or pull) for
> the session being authorized based on information coming from the AS
> and/or the NE.  
> What information should be defined with these regards? Is there a
> convergent set of AVPs for both the AS-AE and AE-NE communications to
> inform about the mode of operation (push/pull, e.g. Operation-Mode
> AVP) and carry access network info (also referred to as Terminal-Mode
> AVP by Tina)?    
> 
>> <t>In some deployment scenarios, QoS aware network elements may
>>      request authorization through the AAA cloud based on an
>>      incoming QoS reservation request. The network element will
>>      route the request to a designated authorizing entity. The
>> authorizing entity will return the result 
>> of the
>>      authorization will be initiated upon dynamic application state,
>>      so that the request must be authenticated and authorized based
>>      on information from one or more application servers. /*start of
>> added*/In terms of the 
>> resource request sent from
>>      the application server to Authorizing Entity, the Authorizing
>>      Entity could identify the access network related information
>>      and select appropriate resource admission and control policies.
>> The Push or pull mode 
>> also can be
>>      dynamically triggered based on the information in the request
>> from application
>>   server, or statically configured according to operator's
>> demand./*end of added*/</t> [snipped]
> 
> 
> 
> 
>
> 	Subject: Re: [Dime] Diameter QoS        Appl.-"PULL/PUSH/Access
> 	        network related Re: [Dime] Diameter QoS
> 	        Appl.-"PULL/PUSH/Access network related information"
> 	To: Christian Esteve < [email-masked]
<mailto:[email-masked]> >,
> 	        [email-masked] <mailto:[email-masked]> , Hannes Tschofenig
> 	<[email-masked]>, Tina TSOU < [email-masked]
> 	<mailto:[email-masked]> > Message-ID: <
> [email-masked]
> <mailto:[email-masked]> >
> 	message header. For fix terminals, AF can query the access
network
> identifier via e2 interface. The way carried by SIP is not granted by
> consensus.  
> 
> 	B. R.
> 	Tina
> 
> 	  Actually, the QoS template is not chosen by AF (mapping to
> Application Server here). It is determined by the policy in SPDF
> (mapping to Authorizing Entity here) according to related information
> sent from AF to SPDF. There is no need for AF to see the template
> information.    
> 
> 	  B. R.
> 	  Tina
> 	  Messengers:
tinaTSOU  
> Jabber: [email-masked]    Google talk: [email-masked] 
> 
> 
> 	  To: Christian Esteve ; [email-masked] ; Tina TSOU ; Hannes
> 	  Tschofenig Sent: Thursday, July 12, 2007 7:04 AM
> 	  I agree, in certain circumstance e.g. IMS AF, it is possible
to
> 	  identify the access network as you described. Maybe, I guess,
> there is some confusion (to me) on the terminology used here. If you
> are saying that AF may determine the service profile/attributes upon
> access type, it would be fine in certain case (but it is out of the
> application server involved in network level QoS selection, even it
> is worse to make the AS select access specific QoS profile.      
> 
> 	  Regards,
> 	  Dong

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 12 Jul 2007 12:35:18 -0400

Tom Taylor wrote:
> I think you have a few premises mixed up. See comments marked with
> [PTT]. 
> 
> McCann Peter-A001034 wrote:
>> I don't think we should be designing a protocol that behaves
>> differently depending on the type of access link.  Everything in the
>> Diameter cloud should be dealing exclusively with link-neutral QoS
>> specifications, which will enable inter-domain operation and simplify
>> settlement.
> 
> [PTT] Push/pull is a question of terminal technology, not link
> technology. 

There was a proposal to put link type (3GPP, 3GPP2, WiFi, Wimax etc) 
into the QoS application as a new AVP, and to select different user
profiles based on the link type.  My point is, there should be one
profile for any given user and it should be based on link-neutral
QoS specifications.

>> Solutions that assume some SIP signaling from the endpoint to
>> identify / classify the first-hop NE are limited.  The QoS
>> enforcement point may not be the first hop; in general any NE along
>> the path between the two hosts involved in the call might need to
>> play this role.  I think the push model has some serious problems
>> with discovering this type of NE.  The right solution is to require
>> end-to-end, path-coupled signaling like NSIS with the pull mode of
>> operation. 
>> 
> [PTT] Which NE is it that you are worried about discovering? And in
> the ITU-T architecture at least, provision is being made for
> discovery at the RACF level. All the AF needs is the right entry
> point, and it can be configured with that.  

In general any router along the path might need to reserve resources
for a given flow, and to request authorization from the Diameter cloud.
I don't think we should limit ourselves to an architecture that only
supports discovery of the first hop (or something near the first hop)
as part of a Diameter application intended to support the Internet
architecture.

> ...

---

From: Tom Taylor <[email-masked]>
Date: Thu, 12 Jul 2007 12:23:10 -0400

I think you have a few premises mixed up. See comments marked with [PTT].

> which will enable inter-domain operation and simplify

[PTT] Push/pull is a question of terminal technology, not link technology.

> path-coupled signaling like NSIS with the pull mode of
[PTT] Which NE is it that you are worried about discovering? And in the ITU-T 
architecture at least, provision is being made for discovery at the RACF level. 
All the AF needs is the right entry point, and it can be configured with that.

...

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jul 2007 20:34:53 +0200

Hi Tom,

> [PTT] Push/pull is a question of terminal technology, not link 
That's probably only a terminology problem.

Still, there is the question which entity needs to understand the QoS 
model of the specific node being configured.
There are essentially three possibilities:
* AF
* PDF
* NE

>> model has some serious problems with discovering this type of NE.  
>> The right solution is to require end-to-end,
> the ITU-T architecture at least, provision is being made for discovery 
> at the RACF level. All the AF needs is the right entry point, and it 
> can be configured with that.
>
In a push model, in the end the AF needs to contact a specific PDF  
related to the access network or a  NE directly.
Pete calls this discovery and I agree that this is a valid term in this 
context. Consider an arbitrary AF, like a streaming server installed on 
my webserver. Then, you click on it -- how would it know where to push 
QoS policies to?

I know that with the assumptions being made in some architectures, for 
example with the 3GPP IMS, this discovery step is obviously a lot easier 
since the application server is
a) either in the access network (e.g., the P-CSCF), or
b) associated with the operator of the access network using some 
business relationship

>> -Pete

Ciao
Hannes

---

From: Tom Taylor <[email-masked]>
Date: Thu, 12 Jul 2007 18:40:00 -0400

See at end.

...
> as part of a Diameter application intended to support the Internet
[PTT] Thinking about this a bit more, I guess the choice (making the assumption 
that the Diameter protocol is used) is between a network of Diameter servers 
(not a "Diameter cloud") in the RACF layer, versus a network of routers using 
NSIS between them with vertical relationships to local PDFs.

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 12 Jul 2007 18:27:31 -0500

See my comment as [DS] 

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]] 
Sent: Thursday, July 12, 2007 12:35 PM
To: Tom Taylor
Cc: [email-masked]; Christian Esteve
Subject: RE: [Dime] Diameter QoS Appl.-"PULL/PUSH/Access network
relatedinformation"

[snip]

> can be configured with that.

In general any router along the path might need to reserve resources for
a given flow, and to request authorization from the Diameter cloud.
I don't think we should limit ourselves to an architecture that only
supports discovery of the first hop (or something near the first hop) as
part of a Diameter application intended to support the Internet
architecture.

>> -Pete
[snip]
[DS] not sure whether any router along the path has to reserve resources
on per micro-flow level in reality (don't want to repeat the scalability
and cost issues of per flow IntServ model). I can see the need for
certain resource scarce bottleneck links e.g. air interface, but don't
perceive the necessity in the high capacity aggregation network segment.
In other words, the NE for per flow policy enforcement would be taken in
certain anchor points or overlay nodes typically, which may result in
the discovery requirement in the Push model. (Otherwise, why the policy
server needs to discover the right spot if every NE would perform the
enforcement). 

However, I don't think the path-coupled signaling is the best solution
for all kind of scenarios.(hope no need to harp on the reasoning :-).
Just like to point out one truth, even the path-coupled signaling is
used with pull model, the NE still needs to identify the right server
for authorization, sort of discovery. Although the discovery for Push
mode is a bit complex, but don't think it would be more difficult
compared to mandate every terminal support the intelligence of
full-blown Qos and path coupled signaling, from e2e perspective.

---

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Jul 2007 18:06:10 +0800

See comment with [Tina: ...] in line.

Ciao
Tina
----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Tom Taylor" <[email-masked]>
Cc: <[email-masked]>; "McCann Peter-A001034" <[email-masked]>; 
"Christian Esteve" <[email-masked]>
Sent: Friday, July 13, 2007 2:34 AM
Subject: Re: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network 
relatedinformation"

> There are essentially three possibilities:
[Tina: AF needs to understand the QoS model of the specific node being 
configured.
In 3GPP which supports pull mode only, AF may identify the QoS model based 
on the
access network type. While in TISPAN and ITU-T which both support pull mode 
and
push mode, the QoS model should be understood by AF which is configured in 
AF.]
>>> model has some serious problems with discovering this type of NE.  The 
>>> right solution is to require end-to-end,
>> [PTT] Which NE is it that you are worried about discovering? And in the 
>> ITU-T architecture at least, provision is being made for discovery at the 
>> RACF level. All the AF needs is the right entry point, and it can be 
>> configured with that.
>>
> context. Consider an arbitrary AF, like a streaming server installed on my 
> webserver. Then, you click on it -- how would it know where to push QoS 
> policies to?
>
> b) associated with the operator of the access network using some business 
> relationship
[Tina: In the non-IMS scenario, there may be a service manager which 
corresponds to the PDF in the IMS. The scenario with PDF is based on the 
session, but the non-IMS scenario as you cited is based on the service. The 
service QoS profile will be pushed to the service manager. ]

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 13 Jul 2007 11:52:32 -0400

Hi, Tom,

Tom Taylor wrote:
>> for a given flow, and to request authorization from the Diameter
>> cloud. I don't think we should limit ourselves to an architecture
>> that only supports discovery of the first hop (or something near the
>> first hop) as part of a Diameter application intended to support the
>> Internet architecture. 
>> 
> [PTT] Thinking about this a bit more, I guess the choice (making the
> assumption that the Diameter protocol is used) is between a network
> of Diameter servers (not a "Diameter cloud") in the RACF layer,
> versus a network of routers using NSIS between them with vertical
> relationships to local PDFs.    

I think I agree with this assessment - but I don't quite know what
you have in mind when you say "network of Diameter servers".  Do
you mean a set of path-coupled entities through which the signaling
must pass?  I think the "Diameter cloud" should be constructed based
on business agreements between operators, possibly with the help of
brokers that make the relationships scalable.  A given NE should be
able to contact its local Diameter server with a request for
authentication/authorization, and there should be enough information
in the request to route to the user's "home" realm, according to
standard Diameter routing using the Destination-Realm AVP.  The path
taken by the Diameter routing will not necessarily be along the same
path as the NSIS signaling.

-Pete

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 13 Jul 2007 13:39:04 -0400

Sun, Dong (Dong) wrote:
> cloud.  
> [DS] not sure whether any router along the path has to reserve
> resources on per micro-flow level in reality (don't want to repeat
> the scalability and cost issues of per flow IntServ model). I can see
> the need for certain resource scarce bottleneck links e.g. air
> interface, but don't perceive the necessity in the high capacity
> aggregation network segment.  

It all depends on how much traffic you are trying to put through
a given aggregation link; I can imagine deployments where these
resources are scarce enough to warrant per-flow reservation.  We
will likely be dealing with thousands of RTP connections that
won't do end-to-end congestion control as TCP does for us today.
I think anywhere there is a bottleneck, the need for reservation
is there.  Even a high-speed router might want to charge for 
resources on a per-call basis.
   
> In other words, the NE for per flow policy enforcement would be taken
> in certain anchor points or overlay nodes typically, which may result
> in the discovery requirement in the Push model. 

Even if the core network doesn't accept per-flow reservations,
I can imagine that an NE just a few hops away from the access
link might.  In this case the requester (end host) doesn't have 
any helpful information to put in the P-header.

> (Otherwise, why the
> policy server needs to discover the right spot if every NE would
> perform the enforcement).    

In general, the NEs along the path would be from different
administrative domains.  Each domain might want to perform
authentication/authorization of the request, and accounting
so they can get paid.

> However, I don't think the path-coupled signaling is the best
> solution for all kind of scenarios.(hope no need to harp on the
> reasoning :-).  

Some sort of path-coupled signaling will be necessary to support
the general model.  In some people's minds, this might be a
network of SIP proxies, each one tied to the domain through
which the RTP traffic will flow.  Personally, I find this
approach limits flexibility because you can't use something
other than SIP to establish the session.

> for authorization, sort of discovery. 

Yes, and it can do this if the end host puts its own home realm
into the path-coupled signaline.

> Although the discovery for Push

If we want to support an open architecture then there needs to
be a universal layer-3 path coupled signaling that can be used
with any application (not just SIP).

-Pete

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 13 Jul 2007 13:53:34 -0400

Hi, Tina,

See inline.

Tina TSOU wrote:
> Cc: <[email-masked]>; "McCann Peter-A001034"
> <[email-masked]>; "Christian Esteve" <[email-masked]> 
> [Tina: AF needs to understand the QoS model of the specific node
> being configured. 
> In 3GPP which supports pull mode only, AF may identify the QoS model
> based on the access network type. While in TISPAN and ITU-T which
> both support pull mode and push mode, the QoS model should be
> understood by AF which is configured in AF.]   

When you say "QoS model" do you mean the style of operations
(Push vs. Pull) or the allowed QoS attributes that might be 
defined in a user profile?  If the latter, I think that the
QoS profile understood by the AF should be a link-agnostic
one, so that the application can run over any link technology.

>> Pete calls this discovery and I agree that this is a valid term in
>> this context. Consider an arbitrary AF, like a streaming server
>> installed on my webserver. Then, you click on it -- how would it
>> know where to push QoS policies to? 
>> 
>> I know that with the assumptions being made in some architectures,
>> for example with the 3GPP IMS, this discovery step is obviously a
>> lot easier since the application server is

How would the sender of the QoS profile know where to find the
service manager?  How would it fill in the Destination-Host and
Destination-Realm fields of the push message?

-Pete

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 13 Jul 2007 16:37:14 -0400

Pete,

> Sent: Friday, July 13, 2007 1:54 PM
> To: Tina TSOU; Tom Taylor; Hannes Tschofenig
> Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access network
> relatedinformation"
> 
> Hi, Tina,
> 
> See inline.
> 
> Tina TSOU wrote:
[TOLGA] I also think that the mechanism should be link-agnostic, or
better said should be agnostic about details of lower layers (if I
recall correctly, there was a desire to use QoS application possibly for
layer2 reservations as well, but nonetheless for an IP network, I agree
that AF shouldn't know details about layer2)
> Destination-Realm fields of the push message?
[TOLGA]This probably would require an initial lookup by the AF to figure
out at least the Destination-Realm based on the IP address of the user
(or alternatively based on Subscriber-Id if the service and access
providers are the same organization). Another approach could be for AF
to initiate the session always with a preconfigured Destination-Realm,
where the server terminates the Diameter session, performs a query to
find the actual Destination-Realm, and initiate a corresponding session.
IMHO, how AF(or some other entity) performs this lookup is out of scope
of Diameter QoS application (but an important part of the of the overall
solution though). I think pull mode wouldn't require a query to discover
the Destination-Realm.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 13 Jul 2007 16:50:55 -0400

Hi, Tolga,

Asveren, Tolga wrote:

[...deleting part where we agree...]
>>> corresponds to the PDF in the IMS. The scenario with PDF is based on
>>> the session, but the non-IMS scenario as you cited is based on the
>>> service. The service QoS profile will be pushed to the service
>>> manager. ]
>> 
> [TOLGA]This probably would require an initial lookup by the AF to
> figure out at least the Destination-Realm based on the IP address of
> the user (or alternatively based on Subscriber-Id if the service and
> access providers are the same organization). 

This sounds unscalable, especially if we take roaming users
into account.  Who maintains this database?  How is it updated?
For roaming users, the access and service providers will not
be the same.

> Another approach could
> be for AF to initiate the session always with a preconfigured
> Destination-Realm, where the server terminates the Diameter session,
> performs a query to find the actual Destination-Realm, and initiate a
> corresponding session. 

It sounds like we are just pushing the problem to another node
in the network.

> IMHO, how AF(or some other entity) performs
> this lookup is out of scope of Diameter QoS application (but an
> important part of the of the overall solution though). 

I think it's important that this be specified somewhere, so that
we can have an end-to-end solution that actually works.  If nothing
else, we should put big disclaimers around the push mode to say
that it only works when AE and NE are in the same domain.  If it
turns out to be impractical or impossible to implement discovery
for inter-domain push mode, we should consider taking push mode
out of the document.

> I think pull
> mode wouldn't require a query to discover the Destination-Realm.     

Right, I think we can augment path-coupled signaling with a realm
name to give the NE the information it needs to find the home server.

-Pete

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Fri, 13 Jul 2007 16:36:17 -0500

Hi Pete,

It seems two issues are mixed up here: the interaction between
Application server (e.g. AF) and policy server (i.e. authorizing entity
(AE), and the interaction between the entities (e.g. between two AE
instances in different domains or between AE and NE). 

Based on your previous comment, this application doesn't intend to cover
the interface/interaction between AS and AE. However, in the attached
email, you made some comments on the push model based on the discussion
for the interaction between AS and AE, which is totally irrelevant to
the scope of this spec. In fact, the push model defined in this
application concentrates on the interaction between entities within this
application (e.g. AE->AE and AE->NE). Hope this clarify the scope of
work.

Moreover, if look at some real implementation e.g. 3GPP, the model
they're using can be viewed as sort of pull model according to the
definition in this QoS application. as a matter of fact, it still
requires the "Push" approach from AF to PDF for service based policy
authorization. This is sth exactly Tolga described. This approach is
also used by the whole world, including TISPAN, WiMAX, Cablelabs, ITU
(in the NGN defined by TISPAN and ITU, the AF and PDF can be in
different provider domain as a mandatory requirement)... It is one of
cornerstone in NGN and makes the network neutrality realistic. I don't
think we can make any disclaimer to limit the usage of this mechanism.

In addition, I don't understand why AF can not discover the right anchor
point of PDF based on the realm info (for instance, some anchor PDF can
be preprovisoned between application service provider and network
provider according to SLA and business agreement). It is essentially the
same as the one you are advocating for NE based approach.

Regards,
Dong

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]] 
Sent: Friday, July 13, 2007 4:51 PM
To: Asveren, Tolga; Tina TSOU; Tom Taylor; Hannes Tschofenig
Cc: Christian Esteve; [email-masked]
Subject: RE: [Dime] Diameter QoSAppl.-"PULL/PUSH/Access
networkrelatedinformation"

Hi, Tolga,

Asveren, Tolga wrote:

> access providers are the same organization).

This sounds unscalable, especially if we take roaming users into
account.  Who maintains this database?  How is it updated?
For roaming users, the access and service providers will not be the
same.

> performs a query to find the actual Destination-Realm, and initiate a 

It sounds like we are just pushing the problem to another node in the
network.

> IMHO, how AF(or some other entity) performs this lookup is out of 
> scope of Diameter QoS application (but an important part of the of the

> overall solution though).

I think it's important that this be specified somewhere, so that we can
have an end-to-end solution that actually works.  If nothing else, we
should put big disclaimers around the push mode to say that it only
works when AE and NE are in the same domain.  If it turns out to be
impractical or impossible to implement discovery for inter-domain push
mode, we should consider taking push mode out of the document.

> mode wouldn't require a query to discover the Destination-Realm.     

Right, I think we can augment path-coupled signaling with a realm name
to give the NE the information it needs to find the home server.

-Pete

---

From: Tom Taylor <[email-masked]>
Date: Fri, 13 Jul 2007 23:40:29 -0400

Marked with [PTT2] at the end.

> path as the NSIS signaling.
[PTT2] I have in mind something more like domain-by-domain authorization, which 
is why I speak of a network of Diameter servers. Policy in each domain 
determines which domain is the next one. Thus the AF can contact one Diameter 
server and get the path authorized all along its length.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Sat, 14 Jul 2007 18:00:49 -0400

Tom Taylor wrote:

> [PTT2] I have in mind something more like domain-by-domain
> authorization, which is why I speak of a network of Diameter servers.
> Policy in each domain determines which domain is the next one. Thus
> the AF can contact one Diameter server and get the path authorized
> all along its length.    

I think the NEs in the data path will be in the best position to
do policy-based routing, and the on-path signaling (such as NSIS)
will follow this routing.  In the pull model, each of the NEs would
send a request toward the "home" Diameter server, and this request
would get routed based on the realm name sent inband in the signaling.

In the push model, finding the right NEs along the path is a challenge.

-Pete

---

From: Tom Taylor <[email-masked]>
Date: Sat, 14 Jul 2007 18:13:51 -0400

Below.

...
> In the push model, finding the right NEs along the path is a challenge.
[PTT3] Not so bad if policy is imposed at the edge of each network. Think of 
each domain's server pushing admission and policing policy to the ingress 
router, which is either predetermined from topology or chosen by the server and 
reported back to the upstream domain.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Sun, 15 Jul 2007 14:54:57 -0400

Hi, Dong,

See inline.

Sun, Dong (Dong) wrote:
> Application server (e.g. AF) and policy server (i.e. authorizing
> entity (AE), and the interaction between the entities (e.g. between
> two AE instances in different domains or between AE and NE).   

In my mind we are working on *one* Diameter application where the
Authorizing Entity can be either a static home subscriber database
or a dynamic Application Server.

> Based on your previous comment, this application doesn't intend to
> cover the interface/interaction between AS and AE. However, in the
> attached email, you made some comments on the push model based on the
> discussion for the interaction between AS and AE, which is totally
> irrelevant to the scope of this spec. In fact, the push model defined
> in this application concentrates on the interaction between entities
> within this application (e.g. AE->AE and AE->NE). Hope this clarify
> the scope of work.       

I disagree with this scope of work.  The Diameter QoS application 
should be usable all the way to the AS.

> definition in this QoS application. 

Yes, I think they pull authorization based on a PDP Context Activation.

> as a matter of fact, it still
> cornerstone in NGN and makes the network neutrality realistic. I
> don't think we can make any disclaimer to limit the usage of this
> mechanism.          

If we want to have a neutral network, we need to have the ability
to place the AS anywhere, and we need an open, standardized interface
between the AS and all of the NEs along the path.  This is the reason
why the Diameter QoS application was created and I don't think we
should limit its scope to just a local PDF talking to a local NE.

> In addition, I don't understand why AF can not discover the right
> anchor point of PDF based on the realm info (for instance, some
> anchor PDF can be preprovisoned between application service provider
> and network provider according to SLA and business agreement). It is
> essentially the same as the one you are advocating for NE based
> approach.     

At best, the Endpoint node can convey information about the
first hop domain to the AS.  This might allow for authorization
to that first domain, but it certainly doesn't give the entire
path followed by the flow, and there might be NEs that want
to do QoS Authorization along that path.  In the Internet,
this routing will be done based on BGP and the Diameter servers
are not in a position to influence this policy-based routing.

-Pete

> I think it's important that this be specified somewhere, so that we
> can have an end-to-end solution that actually works.  If nothing
> else, we should put big disclaimers around the push mode to say that
> it only works when AE and NE are in the same domain.  If it turns out
> to be impractical or impossible to implement discovery for
> inter-domain push mode, we should consider taking push mode out of
> the document.      
> 
>> I think pull

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 15 Jul 2007 15:55:55 -0400

Although it would be nice to have a generic solution which scales/works
well for any type of deployment, I feel that we will need to optimize
for the most-common use case at the end (probably even that is going to
be challenging). 

I believe it could be useful to go over concrete use cases to validate
different models and to make sure that we have a common understanding at
least in terms of problem description:

For push-mode:
Let's assume the customer is subscriber of a VoIP provider in US and is
currently in his home in Dubai. The customer is subscriber of local
cable company for broadband connectivity. The first question is, how
does the SIP proxy learn about the PDF in cable operator's network?
Let's say the cable operator has a gateway PDF to receive QoS requests
from the outside word, still the address of this entity needs to be
discovered. AFAICS, there should be a globally administrated database
mapping IP address ranges used by access providers to their gateway PDFs
to make this work(we just removed support for NAPT queries in the bis
document :-) ). If VoIP provider and access provider are the same
company, this wouldn't be a hard to solve issue. 

Second question is how the reservation for the whole path could be
performed, if there is such a need. If PDF for the cable company is
aware of the topology of its IP network, it can try to reserve bandwidth
for the whole path under its own control. That it needs to know the IP
network topology is not a desirable thing IMHO. Secondly, PDF needs to
determine the route to be followed for this session, i.e. which routers
the corresponding IP packets will traverse in its own network, and
furthermore it somehow needs to feed this routing decision to the
routers; I don't know whether this is even possible at all(or maybe some
type of static routing will be used between routers so PDF can use the
same preconfigured routes while determining the set of routers on the
path). Secondly, QoS needs to be reserved in other administrative
domains. PDF can contact the PDF of the next-hop administrative domain
and that PDF can try to reserve QoS in its own domain as well (discovery
of PDF of next administrative domain could be achieved relatively
easily, because this is a peering relationship between two companies)

For pull-mode:
End point asks for QoS. The router in the access network queries the
local Authorizing entity (the access user is always the local user of
the access provider company). Any other router trying to satisfy the QoS
reservation can always contact its own authorization entity, and
authorization entity can decide based on the IP address of the customer
whether it is a local customer and apply the policy corresponding to
this customer; or otherwise can decide for the peering partner based on
the IP address of the previous hop and apply the policy corresponding to
this peering relationship. So, AFAICS, there is no need for a global
database for this solution.

Overall, it seems push-mode is easier applicable if QoS is reserved only
on the access side and if the service and access is provided by the same
organization (I think this second issue can be addressed with DNS/DNS
like database). For pull-mode, one important problem is acceptance in
the industry. It needs endpoint involvement and support in the network.
As an example, AFAIK, RSVP is not supported in any of the Windows
versions.

    Thanks,
    Tolga 

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Saturday, July 14, 2007 6:14 PM
> To: McCann Peter-A001034
> Cc: [email-masked]
> [PTT3] Not so bad if policy is imposed at the edge of each network.
Think
> of

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Sun, 15 Jul 2007 17:15:17 -0400

Tom Taylor wrote:
>>> authorization, which is why I speak of a network of Diameter
>>> servers. Policy in each domain determines which domain is the next
>>> one. Thus the AF can contact one Diameter server and get the path
>>> authorized all along its length.
>> 
> ...
>> 
> Think of each domain's server pushing admission and policing policy
> to the ingress router, which is either predetermined from topology or
> chosen by the server and reported back to the upstream domain.   

The next-hop domain will be chosen by BGP.  I don't know if it is
practical or feasible to mirror this state in the "Diameter Network"
so that the Diameter servers can choose the right next-domain.

-Pete