Previous

Content

Next 

1.1.- Introduction

  
RSVP is used by a host to request specific qualities of service from the network for particular application data stream or flows. It is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. Requests will result in resources being reserved in each node along the data path.
Resources are requested for simplex flow (i.e., in one direction), then RSVP treats a sender logically distinct from a receiver. RSVP operates on top of IP as any other transport protocol, but RSVP does not transport data, being instead an Internet Control protocol, like ICMP, IGMP, or any other routing protocol. RSVP executes in the background, not in the data forwarding path.
To clear the idea, one simple RSVP operation would be: a host sends IGMP messages when trying to join a multicast group; then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing.
For efficiency reasons, receivers (i.e., clients) are the entities responsible for requesting a specific QoS. The receiver host application request is passed to the local RSVP process. Then the RSVP protocol carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data sources(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. RSVP's overhead is logarithmic rather that linear in the number of receivers.  

Next figure shows a typical RSVP process:

QoS is implemented by mechanisms not belonging to RSVP, called "traffic control". These mechanisms are:
  1. Packet classifier.
      Determines the QoS class, and perhaps the route, for each packet.
         		  
  2. Packet scheduler.
      Achieves the promised QoS.
         		  
  3. Admission control
      Determines whether the node has sufficient available resources to supply the requested QoS.
         		  
  4. Policy control
      Determines whether the user has administrative permission to make the reservation.  
If admission control and policy control check mechanisms both succeed, parameters are set in the packet classifier and in the link layer interface (e.g., the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originate the request.
RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation across a mesh of multicast and unicast delivery paths. It transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic and policy control modules for interpretation.
Note: Opaque data means that RSVP doesn't know anything about what it is actually transfering and manipulating; it just does the job for other implemented mechanisms. Then, it can be used as a signaling protocol for any other type of protocols requiring this type of service. It has been used in combination with the integrated service architecture (for which it was created), the differentiated service architecture, and with the OSPF and  MPLS routing protocols. L.B.
RSVP is a soft-state protocol; this means, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted.
RSVP has the following attributes:
  1. It makes resource reservations for both unicast and many-to-many multicast applications, adapting dynamically to changing group membership as well as to changing routes.
     
  2. It is simplex, i.e., it makes reservations for unidirectional data flows.
     
  3. It is receiver-oriented, i.e., the receiver initiates and maintains the resource reservation used for that flow.
     
  4. It maintains soft-state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes.
     
  5. It is not a routing protocol but depends upon present and future routing protocols.
     
  6. It transports and maintains traffic and policy control parameters that are opaque to RSVP.
     
  7. It provides several reservation models or styles to fit a variety of applications.
     
  8. It provides transparent operation through routers that do not support it.
     
  9. It supports both, IPv4 and IPv6.
Previous

Content

Next