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