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

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 11 Sep 2007 14:54:58 +0200

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 11 Sep 2007 09:40:26 -0400

To me this makes sense; it overcomes the practical issue most endpoints not having support for e2e signaling. Actually, I guess this approach can be used to reserve resources in any segment of the path, i.e. not necessarily the whole path except the endpoints.

B doesn't look to me like "Push" at all but this is a detail for now.

IMHO Diameter QoS Application should have support for that type of use.

   Thanks,
   Tolga

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

                                               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)

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

Thank you

FRancois

---

From: Hong Cheng <[email-masked]>
Date: Thu, 13 Sep 2007 18:15:47 +0800

Hi Francois,

I think this is a very important topic to be addressed by the DIME group.

For your scenarios *B*, it seems quite reasonable and with some minor
changes to the current messages it should work.

However, for the scenario *A*, it seems there is a requirement for the
Authorizing Entity to locate the NE that is on the data path (and
possibly nearest to the sender?). I feel that there may be some more
work required here. Maybe some sort of discovery mechanism is necessary
(if we do not assume the Authorizing Entity has the network topology
information).

cheers

Cheng Hong

Francois Le Faucheur wrote:
> 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
> 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
> *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).
> 
> reservation inside the network. It is applicable to sender endpoints of
> Category 1, 2 and 3.
> 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)
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 13 Sep 2007 07:51:29 -0400

Hi Cheng Hong,

> -----Original Message-----
> From: Hong Cheng [mailto:[email-masked]]
> Sent: Thursday, September 13, 2007 6:16 AM
> To: Francois Le Faucheur
> Cc: [email-masked]; tsvwg tsvwg
> Subject: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS
> SignalingProxies
> 
> Hi Francois,
> 
[TOLGA]Diameter itself provides relaying/proxying capability. These can
be utilized to forward messages to entities, which perform some type of
discovery. OTOH, I am not sure whether the discovery mechanism itself
needs to be specified by the Diameter QoS Application (OTOH, it may be
useful that we at least think whether discovery mechanism needs to be
standardized and if so where)
> > draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy
and
> > I believe it would be very useful if the "Diameter Application for
QoS
> > *A* ability for the AAA Authorizing Entity to instruct a Network
Element
> > *B* on receipt of a QoS Authorization Request from a NE, ability for
the
> >    requesting QoS      ( Diameter              ( Diameter
+--------+--------------+
> >        |                   |                |        ....
|
> >        |                   |                | Sig Sender Proxy
needed|
+--------+--------------+
> >        |                   |< - - - - XXX - - - - - -+
+--------+--------------+
> >        |                   |                |   QoS reservation
|
> >        |                   |                |      resources
|
+--------+--------------+
> >        |                   |   QoS-Auth-Data,User-ID)|
+--------+--------------+
> >        |                   |                |  Authorize request
|
> >        |                   |                |         ...
|
needed|
+--------+--------------+
> >        |                   |(Result-Code,CC-Time,Cost|
+--------+--------------+
> >        |                   |                |   QoS reservation
|
> >        |                   |                |      resources
|
+--------+--------------+
> > reservation inside the network. It is applicable to sender endpoints
of
> > reservation inside the network. It is applicable to receiver
endpoints

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 13 Sep 2007 14:13:29 +0200

Hello Tolga, Cheng,

> standardized and if so where)

Right. I would picture that the Diameter QoS Application spec would  
(i) briefly bring up the requirement for Authorizing Entity to locate  
NE and (ii) mention the sort of solutions to that problem such as  
configuration for some environments and dynamic discovery for some  
others. But I would assume actual discovery mechanisms to be defined  
outside this document.

Cheers

Francois

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Sep 2007 14:52:03 +0200

Hi Francois,

Francois Le Faucheur wrote:
> it seems to assume that reservation signaling always takes place 
> end-to-end.

Not really. The document also works when you do the reservations only on 
one side.

> 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 
I certainly agree.

> 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).
>
>     - *A* above can be used to support the Push model augmented with 
> QoS reservation inside the network. It is applicable to sender 
>     - *B* above can be used to support the Push Model augmented with 
> QoS reservation inside the network. It is applicable to receiver 
It is true that B can use push and pull scenarios whereby a pull mode 
might be preferred.

> scenarios in dime-diameter-qos?

We certainly intended to capture these scenario. It, however, seems that 
the current document does not make this too explicit. We will have to 
add text to describe these type of scenarios.

Thanks for the review.
> FRancois

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Sep 2007 15:03:17 +0200

In previous discussions we indicated that we will not discuss the topic 
of NE discovery for the push mode. In the pull mode this problem 
obviously does not appear.

Ciao
Hannes

---

From: Hong Cheng <[email-masked]>
Date: Fri, 14 Sep 2007 09:50:35 +0800

Hi Tolga, Francois and all,

In Francois's scenario *A*, the NE is the proxy for the signaling
application (but not a Diameter Proxy). It is actually the Diameter
client. Therefore, I am not sure if the existing Diamter proxy/relaying
discovery procedure is sufficient.

Another challenge is that the Authorizing Entity may not be on the data
path, but it needs to locate an NE on the actual data path (as required
by RSVP or NSIS). Does it have the sufficient information to do so?

As mentioned in your emails, I guess at least we need to take a look at
these requirements and think about the possible solutions. As for where
to document it, we could decide when we are clearer about it.

cheers

Cheng Hong

Francois Le Faucheur IMAP wrote:
> Right. I would picture that the Diameter QoS Application spec would (i)
> briefly bring up the requirement for Authorizing Entity to locate NE and
> (ii) mention the sort of solutions to that problem such as configuration
> for some environments and dynamic discovery for some others. But I would
> assume actual discovery mechanisms to be defined outside this document.
> 
> Cheers
> 
> Francois
> 
> 
>>>
>>> cheers
>>>
>>> Cheng Hong
>>>
>>>
>>>
>>>

---

From: Hong Cheng <[email-masked]>
Date: Fri, 14 Sep 2007 09:55:18 +0800

Hi Hannes,

Maybe in the previous discussions there is no requirements identified
for the discovery. However, as Francois proposal is about some new
(signaling proxy) scenarios, it may have different requirements and lead
to different conclusions (as discussed in other mails of this thread).
Maybe we could do a bit analysis on it first?

cheers

Cheng Hong

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 14 Sep 2007 07:50:58 -0400

Hi Cheng Hong,

> Sent: Thursday, September 13, 2007 9:51 PM
> To: Francois Le Faucheur IMAP
> Cc: Asveren, Tolga; [email-masked]; tsvwg tsvwg
> Subject: Re: [Dime] Re: [Tsvwg] dime-diameter-qos-01 handling of QoS
> SignalingProxies
> 
[TOLGA]When I refer to utilizing the services of a Diameter Relay
Agent/Proxy, what I meant is that the message can be sent to such an
entity which can perform the discovery by some other means and forward
it to the appropriate next Diameter hop. AFAICS in terms of Diameter
functionality there is nothing extraordinary here.
> by RSVP or NSIS). Does it have the sufficient information to do so?
[TOLGA]The same challenge may be there for any push-model scenario. This
needs to be handled by the discovery procedure.
> to document it, we could decide when we are clearer about it.
[TOLGA]The problem needs to be handled but I am not sure where the best
place to do so is. 
> > Right. I would picture that the Diameter QoS Application spec would
(i)
> >>>> RSVP Receiver Proxy. NSIS has defined similar NSIS signaling
proxy
> >>> entities.
for
> >>>>        |                   |                | Report for
successful
> >>>>        |                   |                |Update of reserved
QoS
> >>>>        |                   |                | Report for
successful
> >>>>        |                   |                |Update of reserved
QoS
QoS
QoS
> >>>> non-QoS_signaling Capable Receiver endpoints (ie of Category 1
and
> >> 2)