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

[Francois Le Faucheur <[e-mail]>]

Ashok, Gorry,

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

> Inline for ASHOK>
>
> On Oct 8, 2009, at 10/8 1:42 PM, Gorry Fairhurst wrote:
>
>> 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 (?).
>
> 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.

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