This document describes version 1 of RSVP, a resource reservation setup protocol for an integrated services Internet. RSVP allows receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. RSVP is used by hosts to request specific qualities of service (QoS) from the network for application data streams, and by routers to deliver QoS requests to all nodes along the path of the flows and to establish and maintain state to provide the requested service. RSVP requests generally result in resources being reserved in each node along the data path. RSVP is simplex, meaning it requests resources in only one direction. It treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. RSVP is not a routing protocol but depends upon present and future unicast and multicast routing protocols. RSVP makes receivers responsible for requesting a specific QoS. A QoS request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. RSVP provides several reservation models or "styles" to fit a variety of applications. RSVP provides transparent operation through routers that do not support it. RSVP supports both IPv4 and IPv6. RSVP maintains "soft" state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes. RSVP is not a routing protocol but depends upon present and future routing protocols. RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). At each intermediate node, a reservation request triggers two general actions: (1) make a reservation on a link, and (2) forward the request upstream. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be "merged" as reservations travel upstream. RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA). With OPWA, RSVP control packets are sent downstream, following the data paths, to gather information that may be used to predict the end-to-end QoS. The results ("This document describes version 1 of RSVP, a resource reservation setup protocol for an integrated services Internet. RSVP allows receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. RSVP is used by hosts to request specific qualities of service (QoS) from the network for application data streams, and by routers to deliver QoS requests to all nodes along the path of the flows and to establish and maintain state to provide the requested service. RSVP requests generally result in resources being reserved in each node along the data path. RSVP is simplex, meaning it requests resources in only one direction. It treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. RSVP is not a routing protocol but depends upon present and future unicast and multicast routing protocols. RSVP makes receivers responsible for requesting a specific QoS. A QoS request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. RSVP provides several reservation models or "styles" to fit a variety of applications. RSVP provides transparent operation through routers that do not support it. RSVP supports both IPv4 and IPv6. RSVP maintains "soft" state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes. RSVP is not a routing protocol but depends upon present and future routing protocols. RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). At each intermediate node, a reservation request triggers two general actions: (1) make a reservation on a link, and (2) forward the request upstream. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be "merged" as reservations travel upstream. RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA). With OPWA, RSVP control packets are sent downstream, following the data paths, to gather information that may be used to predict the end-to-end QoS. The results ("