<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-rsvp-proxy" target="https://datatracker.ietf.org/doc/html/draft-ietf-rsvp-proxy-03">
   <front>
      <title>RSVP  Proxy</title>
      <author initials="S." surname="Gai" fullname="Silvano Gai">
         <organization>Cisco Systems Inc.</organization>
      </author>
      <author initials="S." surname="Gaitonde" fullname="Sunil Gaitonde">
         </author>
      <author initials="N. D." surname="Elfassy" fullname="Nitsan Dolev Elfassy">
         <organization>Cisco Systems Inc.</organization>
      </author>
      <author initials="Y." surname="Bernet" fullname="Yoram Bernet">
         <organization>Microsoft</organization>
      </author>
      <date month="March" day="7" year="2002" />
      <abstract>
	 <t>RSVP has been extended in several directions [POLICY], [RSVP-APPID],
[DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened the
applicability of RSVP characterizing it as a signaling protocol
usable both inside and outside the Integrated Services [INTSERV]
model.
With the addition of the &#x27;Null Service Type&#x27; [NULLSERV], RSVP is
also being adopted by mission critical applications that require some
form of prioritized service, but cannot quantify their resource
requirements. In cases where RSVP cannot travel end-to-end, these
applications may still benefit from reservations that are not truly
end-to-end, but that are &#x27;proxied&#x27; by a network node on the data path
between the sender and the receiver(s).  
RSVP Receiver Proxy is an extension to the RSVP message processing
(not to the protocol itself) in which an intermediate network node
originates the Resv message on behalf of the receiver(s) identified
by the Path message.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-rsvp-proxy-03" />
   
</reference>
