Browse Prior Art Database

Resource Reservation Protocol (RSVP) Proxy Approaches (RFC5945) Disclosure Number: IPCOM000200407D
Original Publication Date: 2010-Oct-01
Included in the Prior Art Database: 2010-Oct-11

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

F. Le Faucheur: AUTHOR [+3]


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

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

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