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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

Questions? Comments?