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

[Gorry Fairhurst <[e-mail]>]

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