Browse Prior Art Database

Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy (RFC5946) Disclosure Number: IPCOM000200408D
Original Publication Date: 2010-Oct-01
Included in the Prior Art Database: 2010-Oct-11
Document File: 70 page(s) / 81K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 3% of the total text.

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