Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy (RFC5946)
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 [+5]
Guaranteed Quality of Service (QoS) for some applications with tight QoS requirements 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, but it assumes that both the sender and the receiver of the data flow support RSVP. However, there are environments where it would be useful to be able to reserve resources for a flow (at least a subset of the flow path) even when the sender or the receiver (or both) is not RSVP-capable.
Internet Engineering Task Force (IETF) F. Le Faucheur Request for Comments: 5946 Cisco Updates: 2205 J. Manner Category: Standards Track Aalto University ISSN: 2070-1721 A. Narayanan Cisco A. Guillou SFR H. Malik Airtel October 2010
Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy
Resource Reservation Protocol (RSVP) signaling can be used to make
end-to-end resource reservations in an IP network in order to
guarantee the Quality of Service (QoS) required by certain flows.
With conventional RSVP, both the data sender and receiver of a given
flow take part in RSVP signaling. Yet, there are many use cases
where resource reservation is required, but the receiver, the sender,
or both, is not RSVP-capable. Where the receiver is not RSVP-
capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby
performing RSVP signaling on behalf of the receiver. This allows
resource reservations to be established on the segment of the end-to-
end path from the sender to the RSVP Receiver Proxy. However, as
discussed in the companion document "RSVP Proxy Approaches", RSVP
extensions are needed to facilitate operations with an RSVP Receiver
Proxy whose signaling is triggered by receipt of RSVP Path messages
from the sender. This document specifies these extensions.
Status of This Memo
This is an Internet Standards Track document.
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 been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards...