1 / 14

588 Section 8

This article discusses RSVP, a receiver-driven reservation protocol for interactive multicast applications. It covers the features, scalability, and robustness of RSVP, as well as its compatibility with existing routing protocols. It also explores the use of RSVP for guaranteeing quality of service in interactive video and audio streaming.

jeanninec
Download Presentation

588 Section 8

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. 588 Section 8 Neil Spring May 25, 1999

  2. Schedule • Notes • Homework 3 • Reservations?

  3. Reminders & Notes • Homework 3 due June 1 • Project 3 or final project will be due June 11 • Word documents OK. • Next week: 422

  4. Homework 3 -1 • Read Reflections on Trusting Trust, by Ken Thompson • Figure 1 might give you some clues about how to answer this question.

  5. Homework 3 - 2 • Sample denial of service attacks: • syn flooding • name service attacks, possibly pretending map www.cnn.com to your favorite (ahem) ‘adult entertainment’ site. • Infrastructure attacks: • smurfing: broadcast icmp echo with a forged source address • end host attacks • internet worm

  6. Homework 3 - 3 • Multicast source routing packet header format • Efficiency: size, complexity • can you get both? • Evaluation • Could it be deployed? • Would it help?

  7. Homework 3 - 4 • Incompatible routing protocols: • Two questions • How does it happen? • How do you fix it? S G1 R G2 N1 N2

  8. Homework 3 - 5 • End to end • (i) if lost (ii) how to recover • If lost should be of the form • the x doesn’t get his update • have to multicast everywhere • To recover should be of the form • we send the update to x again, x asks for an update… • pruning is initiated again

  9. Homework 3 - 6 • DNS asynchronous update • a. write, but read the before image? • b. to get processor order? • c. to get total order?

  10. Homework 3 - 7 • Distance vector updates • This is NOT link state, also NOT distance vector as described in the book: • The initial table contains no 1’s!!! • Routers don’t know about their direct links!!! • A) tables like on page 167 • B) flooding direction might change if a new route is there

  11. Homework 3 - 8 • Straightforward… • questions?

  12. Real Time • Problem: • Want interactive video, audio, • Interactive means buffering (normal technique) is bad • Maybe want multicast • Routers, links fail • Congestion happens

  13. The Story of RSVP • Senders deliver flow specifications to receivers, over predictable routes. Receivers send resource reservations back toward the sender. Routers along the way do admission control to decide whether guarantees can be made, then packet scheduling to meet those guarantees.

  14. The Feature Sheet • Receiver-driven • scalable for multicast • heterogeneity • Soft-state • tolerates failures, changes • path state - forward, using existing routing • reservation state - reverse path • timeout & refresh • Filters: differentiate between senders

More Related