Download (direct link):
One problem with the receiver-initiated approach is that the receiver does not know the path from the sender to itself. Therefore, it cannot request resource allocation on each router along the path since it does not know which are these routers. This problem is solved using the Path message that originates from the sender and travels along the unicast or multicast route to the receiver. The main purpose of the Path message is to store the path state information in each node along the path and to carry information regarding the sender’s traffic characteristics and the end-to-end path properties. The following is some of the information contained in the Path message:
• Phop: This is the address of the previous hop RSVP-capable router that forwards the message. This address is stored in the path state information at each node, and is used to send the reservation message upstream towards the sender.
• Sender template: This field carries the sender’s IP address and optionally the UDP/TCP sender port.
• Sender TSpec: This defines the traffic characteristics of the data flow that the sender will generate. The sender Tspec format that is used for the intserv architecture will be described below.
• Adspec: This carries one-pass with advertising (OPWA) information. This is information (advertisements) gathered at each node along the path followed by the Path message. This information is delivered to the receiver, who can then use it to construct a new reservation request or to modify an existing reservation.
Upon receipt of the Path message, the receiver sends an Resv message towards the sender along the reverse path that the Path message followed (see Figure 7.19). The following is some of the information contained in the Resv message:
• Flowspec: Specifies the desired QoS. It consists of the receiver TSpec, the RSpec, and the service class. The receiver TSpec is a set of traffic descriptors that is used by the nodes along the path to reserve resources. The RSpec defines the desired bandwidth
Figure 7.19 An example of the path and resv messages.
THE RESOURCE RESERVATION PROTOCOL (RSVP)
and delay guarantees. When RSVP is used in intserv, the service class could be either the guaranteed service or the controlled-load service. The format for the receiver TSpec and RSpec used in the intserv architecture is described below.
• Filter spec: Defines the packets that will receive the requested QoS that was 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 Resv message, it reserves resources per the receiver’s instructions and then sends the Resv message to the previous hop router obtained from the path state information.
RSVP messages are sent in raw IP datagrams without a TCP or UDP encapsulation. (UDP encapsulation is permitted for routers that do not support raw IP datagrams).
RSVP makes use of the notions of data flow and session. A session is defined by the parameters: destination IP address, protocol id, and optionally destination port number. A data flow is simply the packets transmitted by a sender in a particular session.
RSVP is simplex; that is, it makes reservations for unidirectional data flows. Therefore, in order for two users A and B to communicate both ways, two separate sessions have to be established; one session from A to B, and another one from B to A.
7.3.1 Reservation Styles
Three different reservation styles, i.e., schemes, can be used with RSVP. In order to understand these schemes, let us consider the case where a number of senders transmit information to the same receiver. Each sender transmits its own data flow of packets in a session, which is defined by the receiver’s IP address and protocol id. One reservation option is concerned with the resource reservation of these sessions. In particular, let us assume that several of these data flows pass through the same router. The router has the option to establish a separate reservation for each data flow or to make a single reservation for all of the data flows.
A second reservation option controls the selection of the senders. It can be explicit or wildcard. In the explicit sender selection, the receiver provides a list of senders from which it wishes to receive data. A sender cannot send packets to the receiver unless its IP address is in the explicit list. In the wildcard sender selection, any sender can transmit data to the receiver.
Based on these two options the following three different styles have been defined:
1. Wildcard-filter (WF) style: Any sender can transmit to the session. There is a single resource reservation shared by all of the data flows from all upstream senders. The resource reservation is the largest of all requested reservations.
2. Fixed-filter (FF) style: A separate reservation is made for each particular sender that is specified in the explicit list of senders. Other senders identified in the explicit list who transmit in the same session do not share this reservation.