Editing Resource Reservation Protocol (section)

==Operation==
An RSVP host that needs to send a data flow with specific QoS will transmit an RSVP ''path'' message every 30 seconds that will travel along the unicast or multicast routes pre-established by the working routing protocol. If the ''path'' message arrives at a router that does not understand RSVP, that router forwards the message without interpreting the contents of the message and will not reserve resources for the flow.

Those who want to listen to them send a corresponding ''resv'' (short for ''reserve'') message which then traces the path back to the sender. The ''resv'' message contains a ''flowspec''. The ''resv'' message also has a ''filterspec'' object; it defines the packets that will receive the requested QoS defined in the flowspec. A simple filter spec could be just the sender’s IP address and optionally its UDP or TCP port. When a router receives the RSVP ''resv'' message it will:
#Make a reservation based on the request parameters. [[Admission control]] processes the request parameters and can either instruct the [[packet classifier]] to correctly handle the selected subset of data packets or negotiate with the upper layer how the packet handling should be performed. If the cannot be supported, a reject message is sent to let the listener know.
#Forward the request upstream (in the direction of the sender). At each node the ''flowspec'' in the ''resv'' message can be modified by a forwarding node (e.g. in the case of a multicast flow reservation the reservations requests can be merged).
#The routers then store the nature of the flow and optionally set up [[Traffic policing (communications)|policing]] according to the flowspec for it. 

If nothing is heard for a certain length of time the reservation will time out and will be canceled. This solves the problem if either the sender or the receiver crash or are shut down without first canceling the reservation.