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

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 27 Dec 2007 11:09:59 +0100

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
>

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Wed, 26 Dec 2007 17:05:57 -0600

Hi Francois,
 
I have no disagreement to make NEs serve as QoS signaling proxy and
support non-e2e signaling scenarios. 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. 
 
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 (it
seems no need to add additional example call flows dedicatedly for this
feature). 
 
Best Regards,
Dong

________________________________

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

                                               Authorizing

                                               Authorizing
       |                   |                | Sig Receiver Proxy needed|

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)

Thank you

FRancois