The Resource ReSerVation Protocol RSVP[#!rsvpv1!#] was designed to enable the senders, receivers and routers of communication sessions(either multicast or unicast) to communicate with each other in order to set up the necessary router state to support the services described in sections 2.8.1 and 2.8.2. It is worth noting that RSVP is not the only IP reservation protocol that has been designed for this purpose. Others include ST-II[#!delgrossi!#] and ST-II+[#!rsvpvstii!#] which incidentally contain some interesting architectural differences to RSVP such as the use of hard-state and sender-initiated reservations rather than soft-state and receiver-initiated reservations as in RSVP. With hard-state the network is responsible for reliably maintaining router state whereas with soft- state the responsibility is passed to the end-systems which must generate periodic refreshes to prevent state timeout.
An earlier Internet signaling protocol, ST-II+ permits both sender and receiver-initiated reservations, ST-II permits sender-initiated reservations only. For further discussion of alternatives we refer the interested reader to Mitzel[#!rsvpvstii!#] However in this chapter and book the only reservation protocol we consider in detail is RSVP since currently this has the most industry support.
RSVP is a novel signaling protocol in at least three ways:
RSVP identifies a communication session by the combination of destination address, transport layer protocol type and destination port number. It is important to note that each RSVP operation only applies to packets of a particular session and as such every RSVP message must include details of the session to which it applies.
Although RSVP is applicable to both unicast and multicast sessions we concentrate here on the more complicated multicast case.
RSVP is not a routing protocol, it is a signaling protocol; it is merely used to reserve resources along the existing route set up by whichever underlying routing protocol is in place. Figure 2.3 shows an example of RSVP for a multicast Session involving one sender, S1 and three receivers, RCV1 - RCV3.
The primary messages used by RSVP are the Path message which originates from the traffic sender and the Resv message which originates from the traffic receivers. The primary roles of the Path message are firstly, to install reverse routing state in each router along the path and secondly, to provide receivers with information about the characteristics of the sender traffic and end-to-end path so that they can make appropriate reservation requests. The primary role of the Resv message is to carry reservation requests to the routers along the distribution tree between receivers and senders. Returning now to Figure 2.3, as soon as S1 has data to send it begins periodically forwarding RSVP Path messages to the next hop, R1 down the distribution tree. RSVP messages can be transported ‘raw’ within IP datagrams using protocol number 46 although hosts without this raw I/O capability may first encapsulate the RSVP messages within a UDP header.