@techreport{ietf-rsvp-proxy-03,
    number =    {draft-ietf-rsvp-proxy-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-rsvp-proxy/03/},
    author =    {Silvano Gai and Sunil Gaitonde and Nitsan Dolev Elfassy and Yoram Bernet},
    title =     {{RSVP  Proxy}},
    pagetotal = 8,
    year =      2002,
    month =     mar,
    day =       7,
    abstract =  {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 'Null Service Type' {[}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 'proxied' 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.},
}