Illustrated TCP/IP Illustrated TCP/IP
by Matthew G. Naugle
Wiley Computer Publishing, John Wiley & Sons, Inc.
ISBN: 0471196568   Pub Date: 11/01/98
  

Previous Table of Contents Next


Chapter 327
Operation

Operation

  A basic RSVP reservation request (Resv message) consists of a flowspec and a filter spec that together are called a “flow descriptor.”
  flowspec defines:
  Service class desired (Guaranteed or Controlled-load)
  Reservation requested (Rspec)
  Description of the data flow (Tspec)
  filter spec, with the session specification, defines the data “flow” to receive the QoS defined by the flowspec.

Reservation requests are made by the receiver, not the sender. Why? The receiver better understands its local parameters (such as LAN type) and is better able to make an intelligent request than a server; otherwise, we would have to configure the server to know every aspect of its possible receivers. For example, if a server must make a bandwidth reservation, how would it know that a receiver is on Ethernet, Token Ring, FDDI, or ATM? How would a server know the type of computer making the reservation? Why does this matter? Speed. An ATM station should be able to make a request larger than an Ethernet station simply because the bandwidth is available. An application on a host uses RSVP to request specific QoS from the network for particular datastreams or flows from the application.

The operation of RSVP is based on two concepts: flows and reservations. RSVP reserves resources based on a flow. Flows are traffic streams (data) from a sender to a receiver, or possibly to multiple receivers. The flow is defined by the destination IP address and, optionally, a destination port. RSVP may also define the flow by using the Flow Label field in the IPv6 header in conjunction with the source IP address. In combination with the flow, RSVP determines the QoS that a flow requires. QoS determines the network resources for the flow. RSVP does not interpret the flowspec, but it does give that information to hosts and routers along the flow’s path. Those systems can examine the flowspec to see if they have the resources to accept the reservation, and if they accept it they use the flowspec to reserve the required resources.

As stated before, the receivers using RSVP actually make the reservations. This is to alleviate the server from being the overall administrator of all the possible receivers. Some receivers are located on Ethernet, others on Token Ring (speed differences). Some may want to leave the flow at any time. Receivers have better independent control over themselves and this allows for flexibility in RSVP.

The reservation is split into two functions: one is performed by the sender, and one is performed by the receiver. Having the receiver make the reservation leads to a question: How does the receiver know the path by which the flow will be forwarded?” The sender will send Path messages that will follow a path from the sender and be propagated by routers. The Path message describes the flow to any possible receivers, and allows routers to get prepared for a possible flow. It identifies the flow to the routers and alerts the routers to the possibility of incoming reservation requests. For multicast, a Path message is sent to a destination multicast address.


Previous Table of Contents Next