Subject: RE: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 7 Jan 2008 14:37:31 -0600

Hi Francois,
 
Concerning the behavior of source/receiver proxy in NE, not sure if an
explicit dictation (e.g. whether or not the proxy initiates or
terminates the signaling) should be sent from the authorizing entity. As
said in last email, this will make the AE more complicated and
impractical in certain scenarios.
 
This is my 2 cents how the NE behaves. When NE receives the QoS decision
from the AE (e.g. reserve certain amount of BW. Certainly the AE may
specify which network segment the resource should be reserved), it will
decide how to check the resource availability and perform the resource
reservation based on the deployed network technology, for instance,
initiates an NSIS/RSVP signaling to reserve the BW on a specific network
segment (rather than using e2e signaling). 
 
Moreover, from the stds document perspective, the QoS specific AVPs is
out of scope in this protocol document and should be define in another
document i.e. QoS attributes (although I don't think there is a need to
define an explicit AVP for this purpose, but it is a separate issue).
 
Anyway, in order to clarify this matter, I'd like to add some words into
the example section to indicate the NE can serve as signaling proxy and
process the QoS signaling accordingly in addition to the words about e2e
signaling handling. 
 
any comments?
 
Regards,
 
Dong

________________________________

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: Thursday, December 27, 2007 5:10 AM
To: Sun, Dong (Dong)
Cc: Francois Le Faucheur IMAP; [email-masked]; tsvwg tsvwg
Subject: Re: [Dime] dime-diameter-qos-01 handling of QoS Signaling
Proxies

Hello Dong, 

Thanks for looking into how to incorporate handling of signaling proxies
into Diameter QoS Application. 
Thoughts embedded below:

On 27 Dec 2007, at 00:05, Sun, Dong ((Dong)) wrote:

	Hi Francois,
	 
	I have no disagreement to make NEs serve as QoS signaling proxy
and support non-e2e signaling scenarios. 

Great.

	However, not sure if I understood your examples correctly, it
seems the Authorizing entity is required to instruct the NE for
initiating and/or terminating the QoS signaling, which makes AE become a
QoS signaling aware entity.

The idea is not to turn the AE into a QoS signaling aware entity. 

However, I think the AE has to be aware of a few very very basic things
related to QoS signaling. I don't see this as a departure from the
current model of DQA operation in the case of e2e signaling. With e2e
signaling, the AE is not really QoS signaling aware, however the AE
understands just enough to realize that it needs to authorize the user
to request an e2e reservation (ie not just a local resource
reservation). 

Similarly in the case of signaling proxies, again the AE is not really
QoS signaling aware, but it would understand a few very basic things
about QoS signaling.
For example, in the scenario where the AE is used to trigger signaling
initiation on the signaling _sender_ proxy, the AE has to be
sufficiently aware of what it is trying to do in order to initiate a DQA
Push towards the Network Element on the sender side (as opposed to the
NE on the receiver side).
And in this case, I think the AE simply has to be able to say inside the
DQA push message: "I authorize the QoS resources, and the corresponding
reservation needs to be established". 

Similarly, in the scenario where the AE is used to authorize a QoS
signaling reservation in the Pull-model, it would be useful for the AE
to be able to provide a hint in the response as to whether signaling
should be terminated by a receiver proxy or not. This is because the
need to activate receiver proxy behavior (or not) may depend on the
per-user-policy (so the NE cannot know, while AE does).

	 
	IMHO, it would be better to allow NE itself decide how to
operate on QoS signaling based on the policy decisions from AE for the
following reasons:
	- It is more flexible to make AE as a transport signaling
independent entity, especially for support of various signalings used by
different transport networks, including RSVP, NSIS, even ANCP and others
since AE is usually an overlay logical (and off path) Diameter node per
se, and in certain circumstances e.g. inter-domain case, it is awkward
to have AE involved in the decision and instruction of QoS signaling
handling across the administrative domain.
	- According to the current modeling (see fig. 2 in "qos-01"),
there is a resource management function (and other signaling processing
functions) co-located with Diameter client in the NE, it would be more
appropriate to handle this kind of function by these underneath blocks
rather than Diameter nodes.
	 
	In order to reflect this kind of capability (i.e. support
non-e2e QoS signaling), the examples in section 7 of "qos-02" can be
edited to indicate that NE should be able to initiate and/or terminate
the QoS signaling based on policy decisions received from Authorizing
entity

I think I am agreeing with the statement above that "the NE should be
able to initiate/terminate the QoS signaling based on policy decisions
received from AE". 
But I am saying that this "policy decision received from the AE" needs
to contain a few hints about whether source proxy/receiver proxy
behavior should be activated by NE. 
I have no opinion about how the hints should be conveyed (new
flags/fields in existing AVP, new AVP,...), as long as the information
is conveyed.

I think the information that needs to be conveyed boils down to:
* sender proxy behavior requested/not-requested
* receiver proxy behavior requested/not-requested

Makes sense?

Francois

	(it seems no need to add additional example call flows
dedicatedly for this feature). 

	Best Regards,
	Dong

________________________________

	From: Francois Le Faucheur [mailto:[email-masked]] 
	Sent: Tuesday, September 11, 2007 8:55 AM
	To: [email-masked]
	Cc: Le Faucheur Francois; tsvwg tsvwg
	Subject: [Dime] dime-diameter-qos-01 handling of QoS Signaling
Proxies

	Hello, 

	dime-diameter-qos-01 defines a Diameter application for QoS
reservations. When dealing with QoS signaling (such as RSVP or NSIS), it
seems to assume that reservation signaling always takes place
end-to-end. However, there are useful QoS reservation deployment models
where reservation signaling does not quite happen end-to-end. Instead
QoS signaling may be initiated by a Signaling Sender Proxy (on behalf of
the actual sender) or terminated by a Signaling Receiver Proxy (on
behalf of the actual receiver).

	draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender
Proxy and RSVP Receiver Proxy. NSIS has defined similar NSIS signaling
proxy entities.

	I believe it would be very useful if the "Diameter Application
for QoS reservations" could be extended to deal with scenarios involving
QoS Reservation Proxies operating inside the AAA-controlled Network
Elements. Two key example additional capabilities I would see are:
	*A* ability for the AAA Authorizing Entity to instruct a Network
Element (eg the sender-facing NE) to initiate QoS signaling on behalf of
the sender (e.g. instructing the NE to behave as a RSVP Sender Proxy).
	*B* on receipt of a QoS Authorization Request from a NE, ability
for the AAA Authorizing Entity to instruct the NE to close the signaling
loop on behalf of the receiver (e.g. instructing the NE to behave as a
RSVP Receiver Proxy).

	Just for illustration, *A* could perhaps look something like
this:

	                                               Authorizing
	     End-Host         Network Element             Entity
	   requesting QoS      ( Diameter              ( Diameter
	                        QoS Client)             QoS Server)
	       |                   |                         |
	       |                   |
+--------+--------------+
	       |                   |                |  Authorize new
flow   |
	       |                   |                |        ....
|
	       |                   |                | Sig Sender Proxy
needed|
	       |                   |
+--------+--------------+
	       |                   |< - - - - XXX - - - - - -+
	       |                   |    (...Sender-Proxy)    |
	       |           +-------+---------+
	       |           |Install QoS state|
	       |           |       +         |
	       |           | Initiate QoS    |
	       |           | Reservation     |                QoS
Responder
	       |           |                 |                    Node
	       |           +-------+---------+                      |
	       |                   +----------QoS-Reserve---....--->|
	       |                   |                                |
	       |                   |<---------QoS-Response--....----|
	       |                   |                                |
	       |=====================Data Flow==============....===>|
	       |                   |
	       |                   +- - - - - ACR - - - - - >|
	       |                   |(START,QoS-Resources,Cost|
	       |                   |CC-Time,Acc-Multisess-id)|
	       |                   |
+--------+--------------+
	       |                   |                | Report for
successful |
	       |                   |                |   QoS reservation
|
	       |                   |                |Update of reserved
QoS |
	       |                   |                |      resources
|
	       |                   |
+--------+--------------+
	       |                   |< - - - - ACA - - - - - -+
	       |                   |                         |

	
	Just for illustration, *B* could perhaps look something like
this:

	                                               Authorizing
	     End-Host         Network Element             Entity
	   requesting QoS      ( Diameter              ( Diameter
	                        QoS Client)             QoS Server)
	       |                   |                         |
	       +---QoS-Reserve---->|                         |
	       |                   +- - - - - QAR - - - - - >|
	       |                   |(QoS-Resources,Cost,     |
	       |                   |   QoS-Auth-Data,User-ID)|
	       |                   |
+--------+--------------+
	       |                   |                |  Authorize request
|
	       |                   |                |         ...
|
	       |                   |                | Sig Receiver Proxy
needed|
	       |                   |
+--------+--------------+
	       |                   |< - - - - YYY - - - - - -+
	       |                   |(Result-Code,CC-Time,Cost|
	       |                   |... Receiver-Proxy)|
	       |           +-------+---------+
	       |           |Install QoS state|
	       |           |       +         |
	       |           | Authz. session  |
	       |           | /Authz-time,    |                QoS
Responder
	       |           |  CC-Time,Cost/  |                    Node
	       |           |+ Receiver Proxy |                      |
	       |           +-------+---------+                      |
	       |                   +                                |
	       |                   |                                |
	       |                   |                                |
	       |<--QoS-Response----+                                |
	       |                   |                                |
	       |=====================Data Flow==============....===>|
	       |                   |
	       |                   +- - - - - ACR - - - - - >|
	       |                   |(START,QoS-Resources,Cost|
	       |                   |CC-Time,Acc-Multisess-id)|
	       |                   |
+--------+--------------+
	       |                   |                | Report for
successful |
	       |                   |                |   QoS reservation
|
	       |                   |                |Update of reserved
QoS |
	       |                   |                |      resources
|
	       |                   |
+--------+--------------+
	       |                   |< - - - - ACA - - - - - -+
	       |                   |                         |

	
	Using the terminology of section 3.2 of dime-diameter-qos-01:
	- *A* above can be used to support the Push model augmented with
QoS reservation inside the network. It is applicable to sender endpoints
of Category 1, 2 and 3.
	- *B* above can be used to support the Push Model augmented with
QoS reservation inside the network. It is applicable to receiver
endpoints of Category 1, 2 and 3.
	- *B* above can also be used to support the Pull Model even with
non-QoS_signaling Capable Receiver endpoints (ie of Category 1 and 2)

	Would the DIME WG be willing to address these QOS reservation
proxy scenarios in dime-diameter-qos?

	Thank you

	FRancois

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