Subject: [tsvwg] RSVP Proxy Approaches - Migrating from Proxy RSVP to e2e RSVP

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 8 Oct 2009 17:34:11 +0200

Hello,

Several IESG members brought up a valid concern about the fact that  
once RSVP proxy is deployed, it may be difficult to migrate back to an  
end-to-end RSVP model. In response to this:

* With respect to the "Path-Triggered Receiver Proxy" approach:
===============================================

We propose to include a discussion of two mechanisms that can  
facilitate dynamic migration from a Proxy mode to an e2e RSVP mode:
	* Dynamic Discovery: in addition to generating a Resv (that triggers  
reservation upstream of the Proxy towards the sender), the Receiver  
Proxy can forward the Path message downstream towards the receiver. If  
no Resv is received by the Proxy, then it continues operating as a  
Proxy. If a Resv is received, then the Proxy converts this into an end- 
to-end reservation.
	* Sender-influenced Proxy Bypass: this is similar to the NSIS Proxy  
flag mechanisms. Except we would propose that the Proxy decision (to  
proxy or not proxy) be based on information conveyed inside an RSVP  
Policy Element.

You'll find at the bottom of this message proposed text for a  
potential additional section discussing this topic of interaction  
between proxy and end point (eg to go in proxy-approaches as a new  
section 4.1.1).

With respect to "Application-Triggered Proxies":
==================================

We feel it is reasonable to assume that applications that would  
control an RSVP Proxy (e.g. a SIP Call Agent) would be aware of a  
number of endpoint capabilities including whether it is RSVP-capable  
or not. In the first place, the application has to be aware about  
which endpoint can be best "served" by which RSVP Proxy anyways when  
using Proxies. The application may also consider the QoS preconditions  
and QoS mechanisms signaled by an endpoint as per RFC 3312/4032 and  
RFC5432. The information about endpoint RSVP capability can then be  
used by the application to decide whether to trigger Proxy behavior or  
not, for a given endpoint.

With respect to "Inspection-Triggered Sender Proxies":
========================================

Those devices inspect signaling and/or control traffic associated with  
a flow in order to trigger reservation establishment. When operating  
off signaling traffic, the Proxy may be able to detect from the  
signaling that the endpoint is capable of establishing a reservation  
(e.g. in the case of SIP via inspection of the RFC3312/4032  
Precondition). Otherwise, the proxy can also inspect RSVP signaling  
and if it sees RSVP signaling for the flow of interest, it can disable  
its sender proxy behavior for that flow (or sender). Optionally,  
through RSVP signaling inspection, the sender proxy might also  
gradually "learn" (possibly with some timeout) which sender is RSVP  
capable of not.

Feedback on this proposal as well as proposed corresponding text below  
is welcome.

Francois

=========================================================

Draft text for a proposed additional section discussing this topic of  
interaction between proxy and end point (eg to go in proxy-approaches  
as a new section 4.1.1).

4.1.1) Interaction between a RSVP receiver proxy and a RSVP-capable  
receiver

The presence of a receiver proxy (for a given flow) in the signalling  
path will cause the Path message to be terminated and a Resv generated  
towards the sender. If the eventual receiver was in fact RSVP capable,  
it would not be able to participate in RSVP signalling since it does  
not receive the Path. A similar problem exists with multiple receiver  
proxies in the path of the flow. It is ideal if the RSVP reservation  
spans the entire flow path from source to destination, and highly  
desirable that the reservation span as much of the flow path as  
possible. This can be achieved in the following ways.

4.1.1.1) Selective receiver proxy

A RSVP receiver proxy MAY be selective about the sessions that it  
terminates, based on local policy decision. For example, an edge  
router functioning as a receiver proxy MAY only choose to proxy for  
Path messages that are actually going to exit the domain in question,  
not for Path messages that are transiting through it but stay within  
the domain. As another example, the receiver proxy MAY be configurable  
to only proxy for flows addressed to a given destination address or  
destination address ranges (for which end devices are known to not be  
RSVP capable).

The decision to proxy a Resv for a Path may also be based on  
information signalled from the sender in the Path message. For  
example, the sender may identify the type of application or flow in  
the Application-ID Policy Element in the Path, and the receiver proxy  
may choose to only proxy for certain types of flows. Or, if the sender  
knows through application signalling that the receiver is capable of  
signalling RSVP, the sender may include an indication in a Policy  
Element to any receiver proxy that it must not terminate the Path (and  
conversely, may include an indication to receiver proxies that they  
_should_ terminate a Path if the receiver is known not to support  
RSVP). A similar functionality is defined in NSIS [draft-ietf-nsis-qos- 
nslp].

4.1.1.2) Dynamic discovery of downstream RSVP functionality

When generating a proxy Resv, a receiver proxy MAY choose to forward  
the Path message downstream instead of terminating it. If the  
destination endpoint supports RSVP, it will receive the Path and  
generate a Resv upstream. When this Resv reaches the receiver proxy,  
it recognizes the presence of a RSVP-capable receiver downstream and  
internally converts its state from a proxied reservation to a regular  
midpoint behavior. This dynamic discovery mechanism has the benefit  
that new (or upgraded) RSVP endpoints will automatically and  
seamlessly support end-to-end flows, without impacting the ability of  
a receiver proxy to proxy RSVP for other, non-RSVP-capable endpoints.  
This mechanism also achieves the goal of automatically discovering the  
longest possible CAC-supporting segment in a network with multiple  
receiver proxies along the path. This mechanism dynamically adjusts to  
any topology and routing change. Also, this mechanism dynamically  
handles the situation where a receiver was RSVP-capable and for some  
reason (e.g. software downgrade) no longer is. Finally, this approach  
requires no new RSVP extensions and no configuration changes to the  
receiver proxy as new RSVP-capable endpoints come and go. The only  
identified drawbacks to this approach are:

- If admission control fails on the segment between the receiver proxy  
and the RSVP-capable receiver, the receiver will get a ResvError and  
can take application-level signalling steps to terminate the call.  
However, the receiver proxy has already sent a Resv upstream for this  
flow, so the sender will see a “false” reservation which is not truly  
end-to-end. The actual admission control status will resolve itself in  
a short while, but the sender will need to roll back any permanent  
action (such as billing) that may have been taken on receipt of the  
phantom Resv. Note that if the second receiver is also a receiver  
proxy which is not participating in application signalling, it will  
convert the received ResvError into a PathError which will be received  
by the first receiver proxy. This proxy can then signal the failure of  
the reservation upstream.

- If there is no RSVP-capable receiver downstream of the receiver  
proxy, then the Path messages sent by the receiver proxy every refresh  
interval (e.g. 30 seconds by default) will never be responded to.  
However, these messages consume a small amount of bandwidth, and in  
addition may install some RSVP state on RSVP-capable midpoint nodes  
downstream of the first receiver proxy. This is seen as a very minor  
sub-optimality and observe that such resources would be consumed  
anyways if the receiver was RSVP capable. Still, if deemed necessary,  
to mitigate this, the receiver proxy MAY tear down any unanswered  
downstream Path state after a predetermined time, and stop sending  
Path messages for the flow (or do stop at much lower frequency).

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 08 Oct 2009 18:42:05 +0100

Thanks,

I'll let others ask questions...

I have two myself:

1) I noted was "When generating a proxy Resv, a receiver proxy MAY 
choose to forward the Path message downstream instead of terminating 
it."  - The new text discusses something that it makes it optional. Has 
there been discussion of whether this could be a SHOULD. The drawbacks 
seem limited (at first read), and the mechanisms could be useful, enable 
the PATH seems at least the first stage in getting interoperability. The 
first problem seems to be a misconfiguration as well (?), the second 
problem seems minor in most cases (?).

2) Is it clear what a Proxy does when it receives RSVP signaling in the 
downstream, for both the cases where it sent a PATh and for when it did 
not send a PATH, but still found there was a RSVP capable downstream?

Gorry

Francois Le Faucheur wrote:
> Hello,
> 
> Several IESG members brought up a valid concern about the fact that once 
> RSVP proxy is deployed, it may be difficult to migrate back to an 
> We propose to include a discussion of two mechanisms that can facilitate 
> dynamic migration from a Proxy mode to an e2e RSVP mode:
> Proxy. If a Resv is received, then the Proxy converts this into an 
> end-to-end reservation.
> You'll find at the bottom of this message proposed text for a potential 
> additional section discussing this topic of interaction between proxy 
> and end point (eg to go in proxy-approaches as a new section 4.1.1).
> 
> 
> We feel it is reasonable to assume that applications that would control 
> an RSVP Proxy (e.g. a SIP Call Agent) would be aware of a number of 
> endpoint capabilities including whether it is RSVP-capable or not. In 
> the first place, the application has to be aware about which endpoint 
> can be best "served" by which RSVP Proxy anyways when using Proxies. The 
> application may also consider the QoS preconditions and QoS mechanisms 
> signaled by an endpoint as per RFC 3312/4032 and RFC5432. The 
> information about endpoint RSVP capability can then be used by the 
> application to decide whether to trigger Proxy behavior or not, for a 
> given endpoint.
> 
> 
> Those devices inspect signaling and/or control traffic associated with a 
> flow in order to trigger reservation establishment. When operating off 
> signaling traffic, the Proxy may be able to detect from the signaling 
> that the endpoint is capable of establishing a reservation (e.g. in the 
> case of SIP via inspection of the RFC3312/4032 Precondition). Otherwise, 
> the proxy can also inspect RSVP signaling and if it sees RSVP signaling 
> for the flow of interest, it can disable its sender proxy behavior for 
> that flow (or sender). Optionally, through RSVP signaling inspection, 
> the sender proxy might also gradually "learn" (possibly with some 
> timeout) which sender is RSVP capable of not.
> 
> 
> interaction between proxy and end point (eg to go in proxy-approaches as 
> a new section 4.1.1).
> 
> it would not be able to participate in RSVP signalling since it does not 
> receive the Path. A similar problem exists with multiple receiver 
> terminates, based on local policy decision. For example, an edge router 
> functioning as a receiver proxy MAY only choose to proxy for Path 
> messages that are actually going to exit the domain in question, not for 
> Path messages that are transiting through it but stay within the domain. 
> As another example, the receiver proxy MAY be configurable to only proxy 
> for flows addressed to a given destination address or destination 
> address ranges (for which end devices are known to not be RSVP capable).
> 
> The decision to proxy a Resv for a Path may also be based on information 
> signalled from the sender in the Path message. For example, the sender 
> may identify the type of application or flow in the Application-ID 
> Policy Element in the Path, and the receiver proxy may choose to only 
> proxy for certain types of flows. Or, if the sender knows through 
> application signalling that the receiver is capable of signalling RSVP, 
> the sender may include an indication in a Policy Element to any receiver 
> proxy that it must not terminate the Path (and conversely, may include 
> an indication to receiver proxies that they _should_ terminate a Path if 
> the receiver is known not to support RSVP). A similar functionality is 
> defined in NSIS [draft-ietf-nsis-qos-nslp].
> 
> When generating a proxy Resv, a receiver proxy MAY choose to forward the 
> Path message downstream instead of terminating it. If the destination 
> endpoint supports RSVP, it will receive the Path and generate a Resv 
> upstream. When this Resv reaches the receiver proxy, it recognizes the 
> presence of a RSVP-capable receiver downstream and internally converts 
> its state from a proxied reservation to a regular midpoint behavior. 
> This dynamic discovery mechanism has the benefit that new (or upgraded) 
> RSVP endpoints will automatically and seamlessly support end-to-end 
> flows, without impacting the ability of a receiver proxy to proxy RSVP 
> for other, non-RSVP-capable endpoints. This mechanism also achieves the 
> goal of automatically discovering the longest possible CAC-supporting 
> segment in a network with multiple receiver proxies along the path. This 
> mechanism dynamically adjusts to any topology and routing change. Also, 
> this mechanism dynamically handles the situation where a receiver was 
> RSVP-capable and for some reason (e.g. software downgrade) no longer is. 
> Finally, this approach requires no new RSVP extensions and no 
> configuration changes to the receiver proxy as new RSVP-capable 
> endpoints come and go. The only identified drawbacks to this approach are:
> 
> and the RSVP-capable receiver, the receiver will get a ResvError and can 
> take application-level signalling steps to terminate the call. However, 
> the receiver proxy has already sent a Resv upstream for this flow, so 
> the sender will see a “false” reservation which is not truly end-to-end. 
> The actual admission control status will resolve itself in a short 
> while, but the sender will need to roll back any permanent action (such 
> as billing) that may have been taken on receipt of the phantom Resv. 
> Note that if the second receiver is also a receiver proxy which is not 
> participating in application signalling, it will convert the received 
> ResvError into a PathError which will be received by the first receiver 
> proxy. This proxy can then signal the failure of the reservation upstream.
> 
> - If there is no RSVP-capable receiver downstream of the receiver proxy, 
> then the Path messages sent by the receiver proxy every refresh interval 
> (e.g. 30 seconds by default) will never be responded to. However, these 
> messages consume a small amount of bandwidth, and in addition may 
> install some RSVP state on RSVP-capable midpoint nodes downstream of the 
> first receiver proxy. This is seen as a very minor sub-optimality and 
> observe that such resources would be consumed anyways if the receiver 
> was RSVP capable. Still, if deemed necessary, to mitigate this, the 
> receiver proxy MAY tear down any unanswered downstream Path state after 
> a predetermined time, and stop sending Path messages for the flow (or do 
> stop at much lower frequency).
> 
> 
> 
>

---

From: Ashok Narayanan <[email-masked]>
Date: Thu, 8 Oct 2009 13:54:01 -0400

Inline for ASHOK>

On Oct 8, 2009, at 10/8 1:42 PM, Gorry Fairhurst wrote:

> it."  - The new text discusses something that it makes it optional.  
> Has there been discussion of whether this could be a SHOULD. The  
> drawbacks seem limited (at first read), and the mechanisms could be  
> useful, enable the PATH seems at least the first stage in getting  
> interoperability. The first problem seems to be a misconfiguration  
> as well (?), the second problem seems minor in most cases (?).

ASHOK> Maybe. In this case I'd read the use of "SHOULD" as more of a  
guideline for proxy implementors that moving to end-to-end RSVP is a  
worthy goal.

>
> 2) Is it clear what a Proxy does when it receives RSVP signaling in  
> the downstream, for both the cases where it sent a PATh and for when  
> it did not send a PATH, but still found there was a RSVP capable  
> downstream?

ASHOK> Well...

- For per-flow signaling, if we receive a Resv from downstream for a  
Path that we forwarded as well as proxied, the receiver proxy should  
simply convert itself to a midpoint. This is fairly straightforward  
given that RSVP signaling runs hop-by-hop, so there's practically no  
significant difference between Resv messages generated on behalf of a  
local receiver proxy, or generated on behalf of a received Resv. Of  
course, any changes in bandwidth requests or policy information made  
by the eventual receiver would make their way into the new Resv sent  
upstream, but this is only an issue in applications where some  
sophistication is required on the receiver to take action over and  
above simply echoing these from the Path. In that case the receiver  
proxy must either be more sophisticated, or this application is  
unsuitable for a receiver proxy. This is discussed in the current  
approaches draft.

- Again for per-flow signaling, we could receive a Resv pertaining to  
a flow for which we never received a Path or sent a Path downstream.  
RSVP has standard procedures for discarding these messages.

- There is some component of non-flow signaling like RSVP Hello  
messages or Summary Refresh which technically it is possible to send/ 
receive them without flow state, although no implementation does so  
today. Probably a better example would be RFC2207 authentication  
challenge messages (although even those typically only travel to  
neighbors to which you already do signaling). But there's nothing in a  
RSVP receiver proxy that need affect this component of signaling. It  
might be useful to the node to notice that a RSVP neighbor exists  
downstream and just automatically switch to non-proxy mode for flows  
going to that neighbor, I suppose. But since the case doesn't exist  
today I'm not sure what we could do about it.

-Ashok

>> once RSVP proxy is deployed, it may be difficult to migrate back to  
>> an end-to-end RSVP model. In response to this:
>>    * Dynamic Discovery: in addition to generating a Resv (that  
>> triggers reservation upstream of the Proxy towards the sender), the  
>> Receiver Proxy can forward the Path message downstream towards the  
>> receiver. If no Resv is received by the Proxy, then it continues  
>> operating as a Proxy. If a Resv is received, then the Proxy  
>> converts this into an end-to-end reservation.
>>    * Sender-influenced Proxy Bypass: this is similar to the NSIS  
>> Proxy flag mechanisms. Except we would propose that the Proxy  
>> decision (to proxy or not proxy) be based on information conveyed  
>> inside an RSVP Policy Element.
>> number of endpoint capabilities including whether it is RSVP- 
>> capable or not. In the first place, the application has to be aware  
>> about which endpoint can be best "served" by which RSVP Proxy  
>> anyways when using Proxies. The application may also consider the  
>> QoS preconditions and QoS mechanisms signaled by an endpoint as per  
>> RFC 3312/4032 and RFC5432. The information about endpoint RSVP  
>> capability can then be used by the application to decide whether to  
>> trigger Proxy behavior or not, for a given endpoint.
>> Those devices inspect signaling and/or control traffic associated  
>> with a flow in order to trigger reservation establishment. When  
>> operating off signaling traffic, the Proxy may be able to detect  
>> from the signaling that the endpoint is capable of establishing a  
>> reservation (e.g. in the case of SIP via inspection of the  
>> RFC3312/4032 Precondition). Otherwise, the proxy can also inspect  
>> RSVP signaling and if it sees RSVP signaling for the flow of  
>> interest, it can disable its sender proxy behavior for that flow  
>> (or sender). Optionally, through RSVP signaling inspection, the  
>> sender proxy might also gradually "learn" (possibly with some  
>> Feedback on this proposal as well as proposed corresponding text  
>> below is welcome.
>> Francois
>> Draft text for a proposed additional section discussing this topic  
>> of interaction between proxy and end point (eg to go in proxy- 
>> approaches as a new section 4.1.1).
>> The presence of a receiver proxy (for a given flow) in the  
>> signalling path will cause the Path message to be terminated and a  
>> Resv generated towards the sender. If the eventual receiver was in  
>> fact RSVP capable, it would not be able to participate in RSVP  
>> signalling since it does not receive the Path. A similar problem  
>> exists with multiple receiver proxies in the path of the flow. It  
>> is ideal if the RSVP reservation spans the entire flow path from  
>> source to destination, and highly desirable that the reservation  
>> span as much of the flow path as possible. This can be achieved in  
>> the following ways.
>> Path messages that are actually going to exit the domain in  
>> question, not for Path messages that are transiting through it but  
>> stay within the domain. As another example, the receiver proxy MAY  
>> be configurable to only proxy for flows addressed to a given  
>> destination address or destination address ranges (for which end  
>> devices are known to not be RSVP capable).
>> the Application-ID Policy Element in the Path, and the receiver  
>> proxy may choose to only proxy for certain types of flows. Or, if  
>> the sender knows through application signalling that the receiver  
>> is capable of signalling RSVP, the sender may include an indication  
>> in a Policy Element to any receiver proxy that it must not  
>> terminate the Path (and conversely, may include an indication to  
>> receiver proxies that they _should_ terminate a Path if the  
>> receiver is known not to support RSVP). A similar functionality is  
>> When generating a proxy Resv, a receiver proxy MAY choose to  
>> forward the Path message downstream instead of terminating it. If  
>> the destination endpoint supports RSVP, it will receive the Path  
>> and generate a Resv upstream. When this Resv reaches the receiver  
>> proxy, it recognizes the presence of a RSVP-capable receiver  
>> downstream and internally converts its state from a proxied  
>> reservation to a regular midpoint behavior. This dynamic discovery  
>> mechanism has the benefit that new (or upgraded) RSVP endpoints  
>> will automatically and seamlessly support end-to-end flows, without  
>> impacting the ability of a receiver proxy to proxy RSVP for other,  
>> non-RSVP-capable endpoints. This mechanism also achieves the goal  
>> of automatically discovering the longest possible CAC-supporting  
>> segment in a network with multiple receiver proxies along the path.  
>> This mechanism dynamically adjusts to any topology and routing  
>> change. Also, this mechanism dynamically handles the situation  
>> where a receiver was RSVP-capable and for some reason (e.g.  
>> software downgrade) no longer is. Finally, this approach requires  
>> no new RSVP extensions and no configuration changes to the receiver  
>> proxy as new RSVP-capable endpoints come and go. The only  
>> - If admission control fails on the segment between the receiver  
>> proxy and the RSVP-capable receiver, the receiver will get a  
>> ResvError and can take application-level signalling steps to  
>> terminate the call. However, the receiver proxy has already sent a  
>> Resv upstream for this flow, so the sender will see a “false”  
>> reservation which is not truly end-to-end. The actual admission  
>> control status will resolve itself in a short while, but the sender  
>> will need to roll back any permanent action (such as billing) that  
>> may have been taken on receipt of the phantom Resv. Note that if  
>> the second receiver is also a receiver proxy which is not  
>> participating in application signalling, it will convert the  
>> received ResvError into a PathError which will be received by the  
>> first receiver proxy. This proxy can then signal the failure of the  
>> reservation upstream.
>> proxy, then the Path messages sent by the receiver proxy every  
>> refresh interval (e.g. 30 seconds by default) will never be  
>> responded to. However, these messages consume a small amount of  
>> bandwidth, and in addition may install some RSVP state on RSVP- 
>> capable midpoint nodes downstream of the first receiver proxy. This  
>> is seen as a very minor sub-optimality and observe that such  
>> resources would be consumed anyways if the receiver was RSVP  
>> capable. Still, if deemed necessary, to mitigate this, the receiver  
>> proxy MAY tear down any unanswered downstream Path state after a  
>> predetermined time, and stop sending Path messages for the flow (or  
>> do stop at much lower frequency).
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 16 Oct 2009 17:55:20 +0200

Ashok, Gorry,

On 8 Oct 2009, at 19:54, Ashok Narayanan wrote:

>> choose to forward the Path message downstream instead of  
>> terminating it."  - The new text discusses something that it makes  
>> it optional. Has there been discussion of whether this could be a  
>> SHOULD. The drawbacks seem limited (at first read), and the  
>> mechanisms could be useful, enable the PATH seems at least the  
>> first stage in getting interoperability. The first problem seems to  
>> be a misconfiguration as well (?), the second problem seems minor  
>> in most cases (?).
>

The proxy-approaches I-D does not really contain real MUSTs/SHOULDs/ 
MAYs so far. It is Informational and intended to describe the various  
approaches and their pros and cons, and not intended to be prescriptive.
So I propose to keep prescriptive MAYs and SHOULDs to the rsvp-proto I- 
D.

Francois

>> the downstream, for both the cases where it sent a PATh and for  
>> when it did not send a PATH, but still found there was a RSVP  
>> capable downstream?
>
> ASHOK> Well...
>
> significant difference between Resv messages generated on behalf of  
> a local receiver proxy, or generated on behalf of a received Resv.  
> Of course, any changes in bandwidth requests or policy information  
> made by the eventual receiver would make their way into the new Resv  
> sent upstream, but this is only an issue in applications where some  
> - Again for per-flow signaling, we could receive a Resv pertaining  
> to a flow for which we never received a Path or sent a Path  
> downstream. RSVP has standard procedures for discarding these  
> messages.
>
> neighbors to which you already do signaling). But there's nothing in  
> a RSVP receiver proxy that need affect this component of signaling.  
> It might be useful to the node to notice that a RSVP neighbor exists  

>>> Several IESG members brought up a valid concern about the fact  
>>> that once RSVP proxy is deployed, it may be difficult to migrate  
>>> back to an end-to-end RSVP model. In response to this:
>>> triggers reservation upstream of the Proxy towards the sender),  
>>> the Receiver Proxy can forward the Path message downstream towards  
>>> the receiver. If no Resv is received by the Proxy, then it  
>>> continues operating as a Proxy. If a Resv is received, then the  
>>> Proxy converts this into an end-to-end reservation.
>>> capable or not. In the first place, the application has to be  
>>> aware about which endpoint can be best "served" by which RSVP  
>>> Proxy anyways when using Proxies. The application may also  
>>> consider the QoS preconditions and QoS mechanisms signaled by an  
>>> endpoint as per RFC 3312/4032 and RFC5432. The information about  
>>> endpoint RSVP capability can then be used by the application to  
>>> decide whether to trigger Proxy behavior or not, for a given  
>>> endpoint.
>>> 4.1.1) Interaction between a RSVP receiver proxy and a RSVP- 
>>> capable receiver
>>> router functioning as a receiver proxy MAY only choose to proxy  
>>> for Path messages that are actually going to exit the domain in  
>>> example, the sender may identify the type of application or flow  
>>> in the Application-ID Policy Element in the Path, and the receiver  
>>> is capable of signalling RSVP, the sender may include an  
>>> indication in a Policy Element to any receiver proxy that it must  
>>> not terminate the Path (and conversely, may include an indication  
>>> to receiver proxies that they _should_ terminate a Path if the  
>>> will automatically and seamlessly support end-to-end flows,  
>>> without impacting the ability of a receiver proxy to proxy RSVP  
>>> for other, non-RSVP-capable endpoints. This mechanism also  
>>> achieves the goal of automatically discovering the longest  
>>> possible CAC-supporting segment in a network with multiple  
>>> receiver proxies along the path. This mechanism dynamically  
>>> adjusts to any topology and routing change. Also, this mechanism  
>>> dynamically handles the situation where a receiver was RSVP- 
>>> capable and for some reason (e.g. software downgrade) no longer  
>>> is. Finally, this approach requires no new RSVP extensions and no  
>>> control status will resolve itself in a short while, but the  
>>> sender will need to roll back any permanent action (such as  
>>> billing) that may have been taken on receipt of the phantom Resv.  
>>> Note that if the second receiver is also a receiver proxy which is  
>>> not participating in application signalling, it will convert the  
>>> first receiver proxy. This proxy can then signal the failure of  
>>> capable midpoint nodes downstream of the first receiver proxy.  
>>> This is seen as a very minor sub-optimality and observe that such  
>>> capable. Still, if deemed necessary, to mitigate this, the  
>>> receiver proxy MAY tear down any unanswered downstream Path state  
>>> after a predetermined time, and stop sending Path messages for the  
>>> flow (or do stop at much lower frequency).
>>
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 16 Oct 2009 13:20:15 -0500

At 10:55 AM 10/16/2009, Francois Le Faucheur wrote:
>>>first stage in getting interoperability. The first problem seems 
>>>to be a misconfiguration as well (?), the second problem seems 
>>>minor in most cases (?).
>>
>>ASHOK> Maybe. In this case I'd read the use of "SHOULD" as more of 
>>a guideline for proxy implementors that moving to end-to-end RSVP 
>>is a worthy goal.
>
>The proxy-approaches I-D does not really contain real 
>MUSTs/SHOULDs/MAYs so far. It is Informational and intended to 
>describe the various approaches and their pros and cons, and not 
>intended to be prescriptive.
>So I propose to keep prescriptive MAYs and SHOULDs to the rsvp-proto I-D.

I agree with what Francis says immediately above wrt the use of 
RFC2119 language.

If the proxy-approaches I-D (as a non-requirements INFO doc) has any 
'mays' or 'shoulds', they need to be in lower case - or, 
alternatively, change the wording to 'can' or 'might' or 'need(s) to' 
or 'ought to'.

James
(with my chair hat on)

>Francois
>
>
>>
>>>
>>>2) Is it clear what a Proxy does when it receives RSVP signaling 
>>>in the downstream, for both the cases where it sent a PATh and for 
>>- For per-flow signaling, if we receive a Resv from downstream for 
>>a Path that we forwarded as well as proxied, the receiver proxy 
>>should simply convert itself to a midpoint. This is fairly 
>>straightforward given that RSVP signaling runs hop-by-hop, so 
>>there's practically no significant difference between Resv messages 
>>generated on behalf of a local receiver proxy, or generated on 
>>behalf of a received Resv. Of course, any changes in bandwidth 
>>requests or policy information made by the eventual receiver would 
>>make their way into the new Resv sent upstream, but this is only an 
>>issue in applications where some sophistication is required on the 
>>receiver to take action over and above simply echoing these from 
>>the Path. In that case the receiver proxy must either be more 
>>sophisticated, or this application is unsuitable for a receiver 
>>proxy. This is discussed in the current approaches draft.
>>
>>downstream. RSVP has standard procedures for discarding these messages.
>>
>>messages or Summary Refresh which technically it is possible to 
>>send/receive them without flow state, although no implementation 
>>does so today. Probably a better example would be RFC2207 
>>authentication challenge messages (although even those typically 
>>only travel to neighbors to which you already do signaling). But 
>>there's nothing in a RSVP receiver proxy that need affect this 
>>component of signaling. It might be useful to the node to notice 
>>that a RSVP neighbor exists downstream and just automatically 
>>switch to non-proxy mode for flows going to that neighbor, I 
>>suppose. But since the case doesn't exist today I'm not sure what 
>>we could do about it.
>
>
>
>>
>>-Ashok
>>
>>>
>>>Gorry
>>>
>>>> the Receiver Proxy can forward the Path message downstream 
>>>> towards the receiver. If no Resv is received by the Proxy, then 
>>>> it continues operating as a Proxy. If a Resv is received, then 
>>>> the Proxy converts this into an end-to-end reservation.
>>>> decision (to proxy or not proxy) be based on information 
>>>> conveyed inside an RSVP Policy Element.
>>>>between proxy and end point (eg to go in proxy-approaches as a 
>>>>new section 4.1.1).
>>>>number of endpoint capabilities including whether it is 
>>>>RSVP-capable or not. In the first place, the application has to 
>>>>be aware about which endpoint can be best "served" by which RSVP 
>>>>decide whether to trigger Proxy behavior or not, for a given endpoint.
>>>>Draft text for a proposed additional section discussing this 
>>>>topic of interaction between proxy and end point (eg to go in 
>>>>proxy-approaches as a new section 4.1.1).
>>>>4.1.1) Interaction between a RSVP receiver proxy and a 
>>>>RSVP-capable receiver
>>>>signalling path will cause the Path message to be terminated and 
>>>>a Resv generated towards the sender. If the eventual receiver was 
>>>>in fact RSVP capable, it would not be able to participate in RSVP 
>>>>span as much of the flow path as possible. This can be achieved 
>>>>in the following ways.
>>>>question, not for Path messages that are transiting through it 
>>>>but stay within the domain. As another example, the receiver 
>>>>proxy MAY be configurable to only proxy for flows addressed to a 
>>>>given destination address or destination address ranges (for 
>>>>which end devices are known to not be RSVP capable).
>>>>in the Application-ID Policy Element in the Path, and the 
>>>>receiver proxy may choose to only proxy for certain types of 
>>>>flows. Or, if the sender knows through application signalling 
>>>>that the receiver is capable of signalling RSVP, the sender may 
>>>>include an indication in a Policy Element to any receiver proxy 
>>>>that it must not terminate the Path (and conversely, may include 
>>>>an indication to receiver proxies that they _should_ terminate a 
>>>>Path if the receiver is known not to support RSVP). A similar 
>>>>functionality is defined in NSIS [draft-ietf-nsis-qos-nslp].
>>>>reservation to a regular midpoint behavior. This dynamic 
>>>>discovery mechanism has the benefit that new (or upgraded) RSVP 
>>>>endpoints will automatically and seamlessly support end-to-end 
>>>>flows, without impacting the ability of a receiver proxy to proxy 
>>>>RSVP for other, non-RSVP-capable endpoints. This mechanism also 
>>>>dynamically handles the situation where a receiver was 
>>>>RSVP-capable and for some reason (e.g. software downgrade) no 
>>>>longer is. Finally, this approach requires no new RSVP extensions 
>>>>and no configuration changes to the receiver proxy as new 
>>>>RSVP-capable endpoints come and go. The only identified drawbacks 
>>>>to this approach are:
>>>>terminate the call. However, the receiver proxy has already sent 
>>>>a Resv upstream for this flow, so the sender will see a "false" 
>>>>Note that if the second receiver is also a receiver proxy which 
>>>>is not participating in application signalling, it will convert 
>>>>the received ResvError into a PathError which will be received by 
>>>>the first receiver proxy. This proxy can then signal the failure 
>>>>of the reservation upstream.
>>>>bandwidth, and in addition may install some RSVP state on 
>>>>RSVP-capable midpoint nodes downstream of the first receiver 
>>>>proxy. This is seen as a very minor sub-optimality and observe 
>>>>that such resources would be consumed anyways if the receiver was 
>>>>RSVP capable. Still, if deemed necessary, to mitigate this, the 
>>>>after a predetermined time, and stop sending Path messages for 
>>>>the flow (or do stop at much lower frequency).

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 16 Oct 2009 22:00:41 +0200

James and all,

On 16 Oct 2009, at 20:20, James M. Polk wrote:
>>>>
>>>>
>>>> 1) I noted was "When generating a proxy Resv, a receiver proxy  
>>>> MAY choose to forward the Path message downstream instead of  
>>>> terminating it."  - The new text discusses something that it  
>>>> makes it optional. Has there been discussion of whether this  
>>>> could be a SHOULD. The drawbacks seem limited (at first read),  
>>>> and the mechanisms could be useful, enable the PATH seems at  
>>>> least the first stage in getting interoperability. The first  
>>>> problem seems to be a misconfiguration as well (?), the second  
>> MAYs so far. It is Informational and intended to describe the  
>> various approaches and their pros and cons, and not intended to be  
>> prescriptive.
> alternatively, change the wording to 'can' or 'might' or 'need(s)  
> to' or 'ought to'.

At this stage the I-D is fine and does not have any uppercase "MA/ 
SHOULD/MUST". Those only started showing up inadvertently in the draft  
text that Ashok & I posted on the list for review. We are tweaking  
that text (while incorporating in the I-D) in line with your  
recommendation above.

Cheers

Francois

>>>> in the downstream, for both the cases where it sent a PATh and  
>>>> for when it did not send a PATH, but still found there was a RSVP  
>>>> capable downstream?
>>>
>>> ASHOK> Well...
>>>
>>> there's practically no significant difference between Resv  
>>> messages generated on behalf of a local receiver proxy, or  
>>> generated on behalf of a received Resv. Of course, any changes in  
>>> bandwidth requests or policy information made by the eventual  
>>> receiver would make their way into the new Resv sent upstream, but  
>>> this is only an issue in applications where some sophistication is  
>>> required on the receiver to take action over and above simply  
>>> echoing these from the Path. In that case the receiver proxy must  
>>> either be more sophisticated, or this application is unsuitable  
>>> for a receiver proxy. This is discussed in the current approaches  
>>> draft.
>>>
>>>>> potential additional section discussing this topic of  
>>>>> interaction between proxy and end point (eg to go in proxy- 
>>>>> control an RSVP Proxy (e.g. a SIP Call Agent) would be aware of  
>>>>> a number of endpoint capabilities including whether it is RSVP- 
>>>>> Those devices inspect signaling and/or control traffic  
>>>>> associated with a flow in order to trigger reservation  
>>>>> establishment. When operating off signaling traffic, the Proxy  
>>>>> may be able to detect from the signaling that the endpoint is  
>>>>> capable of establishing a reservation (e.g. in the case of SIP  
>>>>> via inspection of the RFC3312/4032 Precondition). Otherwise, the  
>>>>> proxy can also inspect RSVP signaling and if it sees RSVP  
>>>>> signaling for the flow of interest, it can disable its sender  
>>>>> proxy behavior for that flow (or sender). Optionally, through  
>>>>> RSVP signaling inspection, the sender proxy might also gradually  
>>>>> "learn" (possibly with some timeout) which sender is RSVP  
>>>>> capable of not.
>>>>> a Resv generated towards the sender. If the eventual receiver  
>>>>> was in fact RSVP capable, it would not be able to participate in  
>>>>> RSVP signalling since it does not receive the Path. A similar  
>>>>> problem exists with multiple receiver proxies in the path of the  
>>>>> flow. It is ideal if the RSVP reservation spans the entire flow  
>>>>> path from source to destination, and highly desirable that the  
>>>>> reservation span as much of the flow path as possible. This can  
>>>>> be achieved in the following ways.
>>>>> A RSVP receiver proxy MAY be selective about the sessions that  
>>>>> it terminates, based on local policy decision. For example, an  
>>>>> edge router functioning as a receiver proxy MAY only choose to  
>>>>> proxy for Path messages that are actually going to exit the  
>>>>> domain in question, not for Path messages that are transiting  
>>>>> through it but stay within the domain. As another example, the  
>>>>> receiver proxy MAY be configurable to only proxy for flows  
>>>>> addressed to a given destination address or destination address  
>>>>> ranges (for which end devices are known to not be RSVP capable).
>>>>> forward the Path message downstream instead of terminating it.  
>>>>> If the destination endpoint supports RSVP, it will receive the  
>>>>> Path and generate a Resv upstream. When this Resv reaches the  
>>>>> receiver proxy, it recognizes the presence of a RSVP-capable  
>>>>> receiver downstream and internally converts its state from a  
>>>>> proxied reservation to a regular midpoint behavior. This dynamic  
>>>>> flows, without impacting the ability of a receiver proxy to  
>>>>> proxy RSVP for other, non-RSVP-capable endpoints. This mechanism  
>>>>> also achieves the goal of automatically discovering the longest  
>>>>> is. Finally, this approach requires no new RSVP extensions and  
>>>>> no configuration changes to the receiver proxy as new RSVP- 
>>>>> capable endpoints come and go. The only identified drawbacks to  
>>>>> this approach are:
>>>>> billing) that may have been taken on receipt of the phantom  
>>>>> Resv. Note that if the second receiver is also a receiver proxy  
>>>>> which is not participating in application signalling, it will  
>>>>> convert the received ResvError into a PathError which will be  
>>>>> received by the first receiver proxy. This proxy can then signal  
>>>>> the failure of the reservation upstream.
>>>>> - If there is no RSVP-capable receiver downstream of the  
>>>>> receiver proxy, then the Path messages sent by the receiver  
>>>>> proxy every refresh interval (e.g. 30 seconds by default) will  
>>>>> never be responded to. However, these messages consume a small  
>>>>> amount of bandwidth, and in addition may install some RSVP state  
>>>>> on RSVP-capable midpoint nodes downstream of the first receiver  
>>>>> that such resources would be consumed anyways if the receiver  
>>>>> was RSVP capable. Still, if deemed necessary, to mitigate this,  
>>>>> the receiver proxy MAY tear down any unanswered downstream Path  
>>>>> state after a predetermined time, and stop sending Path messages  
>>>>> for the flow (or do stop at much lower frequency).
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 16 Oct 2009 23:32:19 -0500

At 03:00 PM 10/16/2009, Francois Le Faucheur wrote:
>>>>ASHOK> Maybe. In this case I'd read the use of "SHOULD" as more 
>>>>of a guideline for proxy implementors that moving to end-to-end 
>>>>RSVP is a worthy goal.
>>>
>>If the proxy-approaches I-D (as a non-requirements INFO doc) has 
>>any 'mays' or 'shoulds', they need to be in lower case - or, 
>At this stage the I-D is fine and does not have any uppercase 
>"MA/SHOULD/MUST". Those only started showing up inadvertently in the 
>draft text that Ashok & I posted on the list for review. We are 
>tweaking that text (while incorporating in the I-D) in line with 
>your recommendation above.

should be good to go then...

>>>>>for when it did not send a PATH, but still found there was a 
>>>>>RSVP capable downstream?
>>>>
>>>>ASHOK> Well...
>>>>
>>>>- For per-flow signaling, if we receive a Resv from downstream 
>>>>for a Path that we forwarded as well as proxied, the receiver 
>>>>proxy should simply convert itself to a midpoint. This is fairly 
>>>>receiver would make their way into the new Resv sent upstream, 
>>>>but this is only an issue in applications where some 
>>>>sophistication is required on the receiver to take action over 
>>>>and above simply echoing these from the Path. In that case the 
>>>>receiver proxy must either be more sophisticated, or this 
>>>>application is unsuitable for a receiver proxy. This is discussed 
>>>>in the current approaches draft.
>>>>
>>>>- Again for per-flow signaling, we could receive a Resv 
>>>>pertaining to a flow for which we never received a Path or sent a 
>>>>Path downstream. RSVP has standard procedures for discarding these messages.
>>>>
>>>>>>that once RSVP proxy is deployed, it may be difficult to 
>>>>>>migrate back to an end-to-end RSVP model. In response to this:
>>>>>> triggers reservation upstream of the Proxy towards the 
>>>>>> sender), the Receiver Proxy can forward the Path message 
>>>>>> downstream towards the receiver. If no Resv is received by the 
>>>>>> Proxy, then it continues operating as a Proxy. If a Resv is 
>>>>>> received, then the Proxy converts this into an end-to-end reservation.
>>>>>>interaction between proxy and end point (eg to go in 
>>>>>>a number of endpoint capabilities including whether it is 
>>>>>>be aware about which endpoint can be best "served" by which 
>>>>>>RSVP Proxy anyways when using Proxies. The application may also 
>>>>>>consider the QoS preconditions and QoS mechanisms signaled by 
>>>>>>an endpoint as per RFC 3312/4032 and RFC5432. The information 
>>>>>>about endpoint RSVP capability can then be used by the 
>>>>>>application to decide whether to trigger Proxy behavior or not, 
>>>>>>for a given endpoint.
>>>>>>via inspection of the RFC3312/4032 Precondition). Otherwise, 
>>>>>>the proxy can also inspect RSVP signaling and if it sees RSVP 
>>>>>>RSVP signaling inspection, the sender proxy might also 
>>>>>>gradually "learn" (possibly with some timeout) which sender is 
>>>>>>RSVP capable of not.
>>>>>>Feedback on this proposal as well as proposed corresponding 
>>>>>>text below is welcome.
>>>>>>Francois
>>>>>>signalling path will cause the Path message to be terminated 
>>>>>>and a Resv generated towards the sender. If the eventual 
>>>>>>receiver was in fact RSVP capable, it would not be able to 
>>>>>>participate in RSVP signalling since it does not receive the 
>>>>>>Path. A similar problem exists with multiple receiver proxies 
>>>>>>in the path of the flow. It is ideal if the RSVP reservation 
>>>>>>spans the entire flow path from source to destination, and 
>>>>>>highly desirable that the reservation span as much of the flow 
>>>>>>path as possible. This can be achieved in the following ways.
>>>>>>example, the sender may identify the type of application or 
>>>>>>flow in the Application-ID Policy Element in the Path, and the 
>>>>>>that it must not terminate the Path (and conversely, may 
>>>>>>include an indication to receiver proxies that they _should_ 
>>>>>>terminate a Path if the receiver is known not to support RSVP). 
>>>>>>A similar functionality is defined in NSIS [draft-ietf-nsis-qos-nslp].
>>>>>>proxied reservation to a regular midpoint behavior. This 
>>>>>>dynamic discovery mechanism has the benefit that new (or 
>>>>>>upgraded) RSVP endpoints will automatically and seamlessly 
>>>>>>support end-to-end flows, without impacting the ability of a 
>>>>>>receiver proxy to proxy RSVP for other, non-RSVP-capable 
>>>>>>endpoints. This mechanism also achieves the goal of 
>>>>>>automatically discovering the longest possible CAC-supporting 
>>>>>>segment in a network with multiple receiver proxies along the 
>>>>>>path. This mechanism dynamically adjusts to any topology and 
>>>>>>routing change. Also, this mechanism dynamically handles the 
>>>>>>situation where a receiver was RSVP-capable and for some reason 
>>>>>>(e.g. software downgrade) no longer is. Finally, this approach 
>>>>>>requires no new RSVP extensions and no configuration changes to 
>>>>>>the receiver proxy as new RSVP-capable endpoints come and go. 
>>>>>>The only identified drawbacks to this approach are:
>>>>>>- If admission control fails on the segment between the 
>>>>>>receiver proxy and the RSVP-capable receiver, the receiver will 
>>>>>>get a ResvError and can take application-level signalling steps 
>>>>>>to terminate the call. However, the receiver proxy has already 
>>>>>>sent a Resv upstream for this flow, so the sender will see a 
>>>>>>"false" reservation which is not truly end-to-end. The actual 
>>>>>>admission control status will resolve itself in a short while, 
>>>>>>but the sender will need to roll back any permanent action 
>>>>>>(such as billing) that may have been taken on receipt of the 
>>>>>>phantom Resv. Note that if the second receiver is also a 
>>>>>>receiver proxy which is not participating in application 
>>>>>>signalling, it will convert the received ResvError into a 
>>>>>>PathError which will be received by the first receiver proxy. 
>>>>>>This proxy can then signal the failure of the reservation upstream.
>>>>>>amount of bandwidth, and in addition may install some RSVP 
>>>>>>state on RSVP-capable midpoint nodes downstream of the first 
>>>>>>receiver proxy. This is seen as a very minor sub-optimality and 
>>>>>>observe that such resources would be consumed anyways if the 
>>>>>>receiver was RSVP capable. Still, if deemed necessary, to 
>>>>>>mitigate this, the receiver proxy MAY tear down any unanswered 
>>>>>>downstream Path state after a predetermined time, and stop 
>>>>>>sending Path messages for the flow (or do stop at much lower frequency).