1 / 20

RSVP: A New Resource ReSerVation Protocol

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

barbararwilliams
Download Presentation

RSVP: A New Resource ReSerVation Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related