Do You Hear What I Hear?�Part VI: Resource Reservation Protocol
Continuing with our series on VoIP Quality of Service (QoS), our previous installments have looked at some of the key factors surrounding the quality of the voice connection:
Part I: Defining QoS
Part II: Key Transmission Impairments
Part III: Dealing with Latency
Part IV: Measuring "Toll Quality"
Part V: Integrated Services
In our most recent tutorial, we examined the Integrated Services project of the Internet Engineering Task Force (IETF), which was chartered to develop requirements to allow voice, data, and video traffic to be integrated on the Internet. The first recommendations from the intserv working group were published in June 1994 as RFC 1633: Integrated Services in the Internet Architecture: an Overview. That document described the integrated services model, and defined flows, which are distinguishable streams of related datagrams. In addition, a reservation setup protocol was defined to create and maintain the flow state information along the path of the flow. That protocol is called the Resource Reservation Protocol, or RSVP, which is defined in RFC 2205. Further details regarding RSVP are found in RFCs 2750, RSVP Extensions for Policy Control, and 3936, Procedures for Modifying the Resource Reservation Protocol (RSVP).
When a host has an application such as real-time video or multimedia, it may use RSVP to request an appropriate level of service from the network in support of that application. But for RSVP to be effective, every router in that path must support that protocol, something that some router vendors and ISPs may not yet be equipped to do. In addition, RSVP is a control protocol, and therefore works in collaboration withnot instead oftraditional routing protocols. In other words, the routing protocol, such as the Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), determines which datagrams are forwarded, while RSVP is concerned with the QoS of those datagrams that are forwarded.
RSVP requests that network resources be reserved to support data flowing on a simplex (uni-directional) path, and that reservation is initiated and maintained by the receiver of the information. Using this model, RSVP can support both unicast and multicast applications. RSVP messages may be sent directly inside IP datagrams (using IP Protocol number 46) or encapsulated inside UDP datagrams (using Port numbers 1698 and 1699).
RSVP defines two basic message types: Reservation Request (or Resv) messages and Path messages. A receiver transmits Resv messages upstream toward the senders. These Resv messages create and maintain reservation state information in each node along the path or paths. A sender transmits Path messages downstream toward the receivers, following the paths prescribed by the routing protocols that follow the paths of the data. These Path messages store path state information in each node along the way.
The RSVP message consists of three sections: a Common Header, which includes a message type, plus an Object Header and Object Contents, which convey flow-specific information. Seven RSVP messages are currently defined:
|Path||Path message, from sender to receiver, along the same path used for the data packets.|
|Resv||Reservation message with reservation requests, carried hop-by-hop from receiver to senders.|
|PathErr||Path error message; reports errors in processing Path messages.|
|ResvErr||Reservation error message; reports errors in processing Resv messages.|
|PathTear||Path teardown message sent downstream to all receivers.|
|ResvTear||Reservation teardown message sent upstream to all matching senders.|
|ResvConf||Reservation confirmation message, acknowledges reservation requests.|
As the message formats above illustrate, a significant deal of work goes into setting up the path, so that the application flow of information can be supported with the appropriate amount of bandwidth. One of the biggest challenges for the intserv model and RSVP, however, is that some advance thought must be given to the reservation scheme, and that every hop along the way must support the protocol and be able to respond to the messages. For this reason, the RSVP approach becomes more challenging as the network grows, and more hops or nodes are added.
In our next tutorial, we will look at another QoS solution which is known as Differentiated Services, or diffserv.
Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.