Resource Reservation Protocol (RSVP)

JMU

Resource Reservation Protocol (RSVP)
An Introduction

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Overview

Objective:
- Provide a guaranteed quality of service (QoS) between a sender and receiver on a connectionless network
Properties:
- Uses end-to-end reservations
- Is robust (to failures in routers and links)
- Is receiver-initiated
- Works with simplex data flow to a multicast group

PATH Messages

What:
- The sender periodically sends the specification of the transmitted traffic (TSpec) to the multicast group
Why:
- The network and reciver are made aware of the TSpec
- The network is made aware of the path taken (which can change over time)

RESV Messages

Contents:
- Delay requirements
- Bandwidth requirements
- A filter that describes the senders that can use this reservation (e.g., in a videoconference multiple senders can share a reservation)
Filter Styles:
- Wildcard - any sender (to this receiver)
- Fixed - one specific sender
- Dynamic - multiple explicit senders (which can be modified over time)

Establishing a Reservation

Receiver:
- Periodically sends RESV messages up the multicast tree to reserve resources
Routers:
- Merge requests from different receivers (e.g., a request for a 200ms delay and a request for a 100ms delay can be merged into a single request for a 100ms delay)
- Determine if the reservation can be fulfilled
- Forward RESV messages to the source

"Soft" State Information

Defined:
- State information is lost when a timer expires
- Sender and receiver periodically refresh the state (using PATH and RESV messages)
Advantages:
- No need to clean up after failures
- Signalling messages needn't be reliable
- Robust (i.e., recovers from failures)

Teardown Messages

Purpose:
- Explicitly delete state information
Types:
- PathTear
- ResvTear