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

[Francois Le Faucheur <flefauch at cisco.com>]

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