{"draft":"draft-ietf-tsvwg-rsvp-proxy-proto-11","doc_id":"RFC5946","title":"Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy","authors":["F. Le Faucheur","J. Manner","A. Narayanan","A. Guillou","H. Malik"],"format":["ASCII","HTML"],"page_count":"35","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Transport and Services Working Group","abstract":"Resource Reservation Protocol (RSVP) signaling can be used to make\r\nend-to-end resource reservations in an IP network in order to\r\nguarantee the Quality of Service (QoS) required by certain flows.\r\nWith conventional RSVP, both the data sender and receiver of a given\r\nflow take part in RSVP signaling.  Yet, there are many use cases\r\nwhere resource reservation is required, but the receiver, the sender,\r\nor both, is not RSVP-capable.  Where the receiver is not RSVP-\r\ncapable, an RSVP router may behave as an RSVP Receiver Proxy, thereby\r\nperforming RSVP signaling on behalf of the receiver.  This allows\r\nresource reservations to be established on the segment of the end-to-\r\nend path from the sender to the RSVP Receiver Proxy.  However, as\r\ndiscussed in the companion document \"RSVP Proxy Approaches\", RSVP\r\nextensions are needed to facilitate operations with an RSVP Receiver\r\nProxy whose signaling is triggered by receipt of RSVP Path messages\r\nfrom the sender.  This document specifies these extensions.  [STANDARDS-TRACK]","pub_date":"October 2010","keywords":["[--------]"],"obsoletes":[],"obsoleted_by":[],"updates":["RFC2205"],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5946","errata_url":null}