RSVP Basic features: –Simplex reservation: one way reservation –Receiver oriented: receivers decide what resources to reserved and initiates the reservation –Routing independent –Policy independent: e.g independent of admission control –Soft state: dealing with the changing of group members –Various reservation styles

Operation overview –PATH messages and RESV messages (Figure 2.6) PATH messages (downstream) –Distribute traffic source information –Collect path information –Install necessary state RESV messages (upstream) –Follow the reserved path of PATH messages –Specify the resource requirements –Setup state in the path

RSVP messages Sent between hops as raw IP datagrams (prototype Id 46) Can be encapsulated in UDP packets (used in end systems) These packets need special treatment: Use Router Alert Refresh periodically –PATH message: Previous Hop Sender Template TSpec Adspec (optional, OPWA) collect path information.

RSVP messages –RESV messages Reservation style Flow spec and filter Spec (Flow descriptor) –Flow spec: Desired QoS and parameters for packet scheduling depending on the service requested »Service Class »RSpec »TSpec –Filter Spec (sender template) + session specification defines the flow

RSVP messages –Message format: common header (Figure 2.7) + RSVP objects (Figure 2.8) –Reservation Styles: Wild-card-filter (WF) style: WF(*, {Q}) Fixed-filter (FF) style: FF(S1(Q1), S2(Q2), …, Sn(Qn)) Shared explicit (SE) style: SE((s1, s2, …, sn){Qn}) Example: Figure

Adspec –Pass the path information for the destination –Three components: a default general parameters fragment, a guaranteed service fragment, and a controlled load service freament –Default general parameters: Minimum latency Path bandwidth IntServ hop count Global break bit Path MTU

Adspec –Guaranteed service fragment Ctot, Dtot, Csum, Dsum –Controlled load service fragment: Controlled load service break bit and options How to compute RSpec for guaranteed service? –Required bandwidth –Slack Term RFC 2205, 2208, 2209, 2210