next up previous contents
Next: Reservation Styles and Merging Up: Network Service Models Previous: Integrated Services on Specific

  
Resource ReSerVation Protocol (RSVP)

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:

1.
It accommodates multicast, not just point-to-multipoint (one-to-many) reservations. To this end, the receiver driven request model permits heterogeneity, in principle, and the filter mechanism allows for calls that reserve resources efficiently for the aggregate traffic flow (e.g. for audio conferencing).
2.
It uses soft state, which means that it is tolerant of temporary loss of function without entailing fate-sharing between the end systems and the network nodes. This means that QoS routing can be deployed separately (in more than one way!).
3.
RSVP is quite straightforward in packet format and operations, and so is relatively low cost in terms of implementation in end systems and routers. One thing that RSVP is not is a routing protocol. RSVP does not support QoS-dependent routing itself (in other words, such routing is independent of RSVP, and could precede or follow reservations).

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.


  
Figure 2.3: Direction of RSVP messages
\begin{figure}
\centerline{\psfig{figure=pix/fig2-2.prn.epsi}}
\end{figure}

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.



 
next up previous contents
Next: Reservation Styles and Merging Up: Network Service Models Previous: Integrated Services on Specific
Jon CROWCROFT
1998-12-03