1. RSVP: A New Resource ReSerVation Protocol
Shyam Seshadri
Zaheer Ahmed
ECE 4605
Fall 2005

2. Quality of Service Internet is a point-to-point best-effort service
Inadequate for applications like remote video, multimedia conferencing, etc.
For providing QoS
Network must allow resource reservation
Must deal with point-to-multipoint and multipoint-to-multipoint networks

3. Network Architecture Components
FlowSpec: Describes characteristics of traffic
Routing: Routing protocol must provide unicast and multicast paths
Resource Reservation: Creating and maintaining resources
Admission Control: Determines which reservation to grant and which to deny
Packet Scheduling: Deciding which packets are transmitted

4. RSVP A proposal for Resource Reservation
Simplex protocol, i.e. reserves only in one direction
Receiver-oriented – receiver responsible for initiation
Can accommodate heterogeneous receivers in a multicast group – efficient utilization of resources
Automatically adopts to routing changes

5. RSVP Design Goals
Let heterogeneous users make reservations tailored to their own needs
Deal gracefully to changes in multicast group membership
Allow end users to specify their application needs
Allow users to switch “channels” without disrupting other flows
Deal gracefully with changes in routes
Control protocol overhead
Make design of RSVP independent of other architectural components

6. Caution!
RSVP communicates requirements of applications irrespective of what the requirements are
Only communicates requirements; does not provide any network services

7. Design: Receiver-Initiated Reservation
Receivers choose level of resources, initiate and keep reservation active as long as needed
Reasoning:
Sender does not care whether resources are available
Sender does not know who the receivers are

8. Design: Separating Reservation from Packet Filtering
Separation between assigning resources and determining which packet utilizes resources
Resource reservation only reserves the amount of resource for any entity
Packet filter determines which packet gets to use the resource
Dynamic filter

9. Design: Providing Different Reservation Styles
Three reservation styles:
No-filter: Do not filter data source packets, any packet can use the reserved resource
Fixed-filter: For the duration of the reservation, receiver receives data only from original list of senders
Dynamic-filter: Allows receivers to change filters to different sources over time

10. Design: Maintaining “Soft-State” in the Network
“…state maintained at network switches which, when lost, will be automatically reinstated by RSVP.”
To tackle frequent routing changes
Maintains two kinds of states:
Path State: Sent by data sources which update path information
Reservation State: Sent by receiver which establishes or updates reservations

11. Design: Protocol Overhead Control
Overhead due to:
Number of Path and Reservation messages
Frequency of refresh messages
RSVP merges path and reservation messages as they traverse a link
Refresh frequency controlled by tuning timeout factor – larger timeout, less frequent refresh messages

12. Design: Modularity RSVP interfaces with 3 components:
Flowspec – data exchanged between application and network admission control
Network routing protocol – Assumptions:
Provides both Unicast and Multicast routing.
Network admission control – Assumptions:
Operates through reservation packets
Packet scheduling algorithm can change filters without new reservations

13. Example: No-filter reservation
Network Topology
“F-flag” not set, hence switches
do not have to record source
information
Path information maintained by switches

14. Example: No-filter reservation
R1(B, no-filter)
R1(B, no-filter)
R1(B, no-filter)
R1(B, no-filter)
Wants to reserve ‘B’ to
receive data from all other
senders
Reservation message
Resource ‘B’ reserved

15. Example: Filtered Reservation
F-flag set – switch maintains list
of sources
Sample S1 path state
Source
Receiver

16. Example: Filtered Reservation
H4 from S2
H4 from S3
R2(B, H4)

17. Example: Dynamic Reservation
R5(2B, *)
Resource ‘B’
Resource ‘2B’
Reservation msg
Two possible sources

18. Issues
Developing a service model/interface for filters independent of reserved resources
Routing support for resource reservation algorithms with new routing algorithms
RSVP performance under large scale multicast network
Currents tests/simulations restricted to small scale multicast networks only.

19. Summary RSVP Architecture: Provides receiver-initiated reservations
Separates filters from reservation
Maintains ‘soft-state’ approach
Decouples reservation and routing functions

20. Questions? Comments?