1 / 16

CIS679: RSVP

CIS679: RSVP. Review of Last Lecture RSVP. Review of Last Lecture. Scheduling: Decide the order of packet transmission Resource configuration Admission control R-spec : defines the QOS being requested T-spec : defines the traffic characteristics

lula
Download Presentation

CIS679: RSVP

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. CIS679: RSVP • Review of Last Lecture • RSVP

  2. Review of Last Lecture • Scheduling: • Decide the order of packet transmission • Resource configuration • Admission control • R-spec: defines the QOS being requested • T-spec: defines the traffic characteristics • A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol

  3. Reservation Protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

  4. RSVP • Used on connectionless networks • Relies on soft state: reservations must be refreshed and do not have to be explicitly deleted • Aims to support multicast as effectively as unicast flows - mcast apps good candidates for real-time, and are heterogeneous • Receiver-oriented approach

  5. Role of RSVP • Rides on top of unicast/multicast routing protocols • Carries resource requests all the way through the network • At each hop consults admission control and sets up reservation. Informs requester if failure • RSVP only carries messages

  6. Changing Reservation • Receiver-oriented approach and soft state make it easy to modify reservation • Modification sent with periodic refresh

  7. RSVP Service Model • Make reservations for simplex data streams • Receiver decides whether to make reservation • Control msgs in IP datagrams (#proto 46) • One pass: • failed requests return error messages - receiver must try again • no e2e ack for success

  8. Basic Message Types • PATH message • RESV message • CONFIRMATION message • generated only upon request • unicast to receiver when RESV reaches node with established state • TEARDOWN message • ERROR message (if path or RESV fails)

  9. Making A Reservation • Receivers make reservation • Before making a reservation, receiver must know: • type of traffic sender will send (Tspec) • path the sender’s packets will follow • Both can be accomplished by sending PATH messages

  10. PATH Messages • PATH messages carry sender’s Tspec • Routers note the direction PATH messages arrived and set up reverse path to sender • Receivers send RESV messages that follow reverse path and setup reservations • If reservation cannot be made, user gets an error

  11. PATH and RESV messages Sender 1 PATH R Sender 2 RESV (merged) PATH RESV R R receiver 1 R RESV receiver 2

  12. Soft State • Routing protocol makes routing changes, RSVP adjusts reservation state • In absence of route or membership changes, periodic PATH and RESV msgs refresh established reservation state • When change, new PATH msgs follow new path, new RESV msgs set reservation • Non-refreshed state times out automatically

  13. Router handling of RESV messages • If new request rejected, send error message • If admitted: • install packet filter into forwarding dbase • pass flow parameters to scheduler • activate packet policing if needed • forward RESV msg upstream

  14. RSVP and multicast • Reservations from multiple receivers for a single sender are merged together at branching points • Reservations for multiple senders may not be added up: • audio conference, not many talk at same time • only subset of speakers (filters) • mixers and translators

  15. RSVP deployment • Authentication and access control • Accounting and charging • Policy control • Future direction? • tightly coupled with the future direction of the Internet service model

  16. Conclusion • RSVP • PATH and RESV messages • Soft-state

More Related