CIS679: RSVP r Review of Last Lecture r RSVP

Review of Last Lecture r Scheduling: m Decide the order of packet transmission r Resource configuration r Admission control m R-spec: defines the QOS being requested m T-spec: defines the traffic characteristics m 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

Reservation Protocol: RSVP Upper layer protocols and applications IP Link layer modules ICMPIGMPRSVP IP service interface Link layer service interface

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

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

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

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

Basic Message Types r PATH message r RESV message r CONFIRMATIONmessage m generated only upon request m unicast to receiver when RESV reaches node with established state r TEARDOWN message r ERROR message (if path or RESV fails)

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

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

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

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

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

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

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

Conclusion r RSVP m PATH and RESV messages m Soft-state