RSVP:  Resource ReSerVation  Protocol    




Date :                Wednesday, 27 August 2003
Lecture No:       13
Author:              Amit Madaan
              

Basic Concepts:

It is a network control protocol that enables Internet applications to obtain different quality of services (QoS) for their data flows. Such a capability recognizes that different applications have different network performance requirements.

Signalling Protocol



Multicasting

Multicast Tree

 


Strawman Proposal


Extended Proposal

Design Goals
Different recievers and paths may have different properties like capacity ,so it has to consider it, so that some of them may not overflow, eg one receiver is a handheld device while the other is a desktop PC so the low video quality in handheld device is admittable because it has limited buffering and memory, while in case of desktop PC, video quality should be high. 
The method to address changes in membership of multicast groups . In order for a receiver to receive a multicast transmission, it must first become a member of a multicast group. A multicast tree is then built with all members of the group in the tree.

In some applications like audio conferencing there is no need of allocation to all the senders because at a time only one sender is active, so the
requirement is aggregate rather than per flow basis.

Making efficient use of limited bandwidth or lowering bandwidth charges. A receiver should decide which packets are sent over its reserved resources. So, a receiver, may change the source of packets at any time, without having to request a new reservation. This eliminates any risk of losing the reserved resources. Some applications like video conferencing switch the channels during the communication, so this should be taken care of. Here also there is no need to reserve resources to all the senders as only one channel is active at a time.

Suppose a route is chosen and the resources  are  reserved  to the receivers along the path, now if a particular router goes down, then the network should choose another path and again start the resource allocation process.

The number of control messages must not grow automatically at the same rate as the group size. Rather, there should be parameters that can be adjusted to control the amount of overhead that is created. An example would be a message to refresh a reservation. There should not have to be one message from every transmitting source.

It should be a  separate modular unit from other multicast architectural capabilties.  RSVP should work on networks that implement different routing algorithms. Furthermore any further improvement in the underlying network should not change the signalling protocol.




Design Principle
Which packet to be reserved is independent of reservation amount. There are three styles  to support different needs of various application.
  1. No filter : It does not distinguish between  senders,  any packets destined for a multicast group may use the reserved resources eg. voice conferencing.
  2. Fixed filter: A distinct reservation request is created for data packets from a particular sender. The reservation scope is determined by an explicit list of senders. The total reservation on a link for a given session is the total of the fixed filter reservations for all requested senders. Fixed filter reservations that are requested by different receivers but that select the same sender must be merged to share a single reservation in a given node.
  3. Dynamic filters: It allows a receiver to change its filter to different sources over time.
Q:  Why are fixed filter required when dynamic filters are available?
A:  In case of dynamic filtering the network has to be ready in terms of resources. Suppose there are two senders S1 and S2 and two receivers R1 and R2, and both the recievers can request to both the senders. In fixed filtering only one pipe is required that is shared by both R1and R2, now for dynamic filtering two pipes has to be allocated separately for each receiver taking into account the maximum possibity, actually in this approach also, there is no bandwidth loss because if R1 is receiving from S1 and S2 both and R2 not               receiving anything then the bandwidth allocated to R2 will be used for best effort and as soon as R2 starts it will be allocated to it.


A soft state refers to a state in routers and end nodes that can be updated by certain RSVP messages that are send periodically otherwise it will time out so will the reservation. The soft state is maintained by a RSVP based network to enable the network to change states without consulting with end points.

Path messages are send from the source to receiver and it will follow the same path that the data packets are going to take, by this each intermediate router comes to know about its upstream router. It contains flow specification, F-flag to indicate whether or not filters are allowed.

Reciever sends the Reserve message along the reverse path contaning information about how much to reserve and actual filtering specification.
Both of above messages install the Path/Reservation state at the routers i.e aggregate state for No filter and Fixed filter and Per-receiver state for dynamic filters.

In soft state implementation no explicit tear down is required, the reservations will clean up automatically otherwise the reciever will crash. It is the best because in No filter style, no particular receiver can tear down the reservation also if some of the router goes down  it will update the states without  concerning the end system.


The signalling protocol doesn't interpret what is lying inside it, it is independent of flow specification and the routing.