Resource Reservation Protocol (RSVP) Proxy Approaches (RFC5945)
Original Publication Date: 2010-Oct-01
Included in the Prior Art Database: 2010-Oct-11
Internet Society Requests For Comment (RFCs)
F. Le Faucheur: AUTHOR [+4]
AbstractGuaranteed Quality of Service (QoS) for some applications with tight requirements (such as voice or video) may be achieved by reserving resources in each node on the end-to-end path. The main IETF protocol for these resource reservations is the Resource Reservation Protocol (RSVP), as specified in [RFC2205]. RSVP does not require that all intermediate nodes support RSVP; however, it assumes that both the sender and the receiver of the data flow support RSVP. There are environments where it would be useful to be able to reserve resources for a flow on at least a subset of the flow path even when the sender or the receiver (or both) is not RSVP-capable (for example, from the sender to the network edge, or from edge to edge, or from the network edge to the receiver).
Internet Engineering Task Force (IETF) F. Le Faucheur Request for Comments: 5945 Cisco Category: Informational J. Manner ISSN: 2070-1721 Aalto University D. Wing Cisco A. Guillou SFR October 2010
Resource Reservation Protocol (RSVP) Proxy Approaches
The Resource Reservation Protocol (RSVP) can be used to make end-to-
end resource reservations in an IP network in order to guarantee the
quality of service required by certain flows. RSVP assumes that both
the data sender and receiver of a given flow take part in RSVP
signaling. Yet, there are use cases where resource reservation is
required, but the receiver, the sender, or both, is not RSVP-capable.
This document presents RSVP proxy behaviors allowing RSVP routers to
initiate or terminate RSVP signaling on behalf of a receiver or a
sender that is not RSVP-capable. This allows resource reservations
to be established on a critical subset of the end-to-end path. This
document reviews conceptual approaches for deploying RSVP proxies and
discusses how RSVP reservations can be synchronized with application
requirements, despite the sender, receiver, or both not participating
in RSVP. This document also points out where extensions to RSVP (or
to other protocols) may be needed for deployment of a given RSVP
proxy approach. However, such extensions are outside the scope of
this document. Finally, practical use cases for RSVP proxy are
Le Faucheur, et al. Informational [Page 1]
RFC 5945 RSVP Proxy Approaches October 2010
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has...