Resource ReServation Protocol
1/16/2002
CS 497 Hou
1
RSVP
• Extends current best-effort Internet model and supports QoS over IP unicast and multicast. • Is a signaling protocol to install and maintain reservation state information in the Integrated Services architecture. • Carries traffic spec and path information from a sender to receivers and reservation information in the other direction.
1/16/2002
CS 497 Hou
2
Attributes of RSVP
• RSVP is simplex. It makes reservations for unidirectional data flows. • RSVP is receiver-initiated. The receiver of a data flow initiates and maintains the resource reservation. • RSVP uses soft states and adapts dynamically to changing group membership as well as changing routes. • RSVP is not a routing protocol. It relies on a routing protocol to provide a route/tree along which it sends control messages to make reservation. • RSVP design is independent of routing, admission control, and packet scheduling. • RSVP provides transparent operation through routers that do not support it.
1/16/2002 CS 497 Hou 3
RSVP Architecture
RSVP Application
RSVP Process
Policy Ctrl
Routing Process
RSVP Process
Policy Ctrl
Classifier
Packet Scheduler
Admis. Ctrl
Admis. Ctrl
Classifier data
Packet Scheduler
Router Host
1/16/2002
CS 497 Hou
4
RSVP in Hosts and Routers
• Packet classifier: determines the QoS class for each packet • Admission control: determines whether the node has sufficient available resources to supply the required QoS • Policy control: determines whether the user has administrative permission to make the reservation. • Packet scheduler: manages the various queues to guarantee the required QoS.
1/16/2002 CS 497 Hou 5
RSVP Session Definition
• RSVP session is defined by the triple (DestAddress, ProtocolID [, DstPort]) – DestAddress refers to the IP destination address of the data packets be it a multicast or a unicast address. – ProtocolID is the protocol ID – The optional DstPort is a generalized destination port.
1/16/2002
CS 497 Hou
6
RSVP Fundamental Message Types
• There are 2 fundamental message types in RSVP: Resv messages and Path messages. • Path messages are sent downstream along the uni/multicast routes provided by the routing protocols. • Path messages store a “path state” in each node along the way that includes the previous hop‟s unicast address. This unicast address is used to route reservation messages hopby-hop in the reverse direction. • Reservation messages are sent by receivers upstream towards the senders. These messages follow exactly the reverse paths along which the data packets will use. • As reservation messages travel up they maintain a reservation state in each node along the path.
1/16/2002 CS 497 Hou 7
Path Message
• • • • Session identifier. Timeout value. Previous hop address. Sender template.
– A template (in the form of filter spec) that contains sender IP and optionally sender port.
• Sender Tspec.
– This information is particularly used in the traffic control module.
• Adspec: describes properties of the data path. Updated at each local traffic control.
1/16/2002
CS 497 Hou
8
Reservation Message
• A reservation request consists of a “flow spec” and a “filter spec” – The flow spec specifies the desired QoS. – The filter spec, along with the the session specification, defines the set of data packets to receive the QoS defined by the flow spec. • A flow spec in a reservation request consists of – A service class – An “Rspec”parameter (R for „reserve‟) which defines the desired QoS. – A “Tspec” parameter (T for „traffic‟) which defines describes the type of the data flow. – These parameters are opaque to RSPV and are determined by the integrated service models.
1/16/2002 CS 497 Hou 9
Reservation Model
.
• Reservation messages carrying reservation requests originate at receivers and are passed upstream towards the sender. • At each intermediate node a reservation request triggers two general actions
– Make a reservation on the link: This involves passing the request to both the admission control and policy control. If either test fails the reservation request is rejected and the RSVP process returns an error to the receiver which initiated the request. If both succeed then the node sets its packet classifier to select the data packets defined by the filter spec. It also talks to the data link layer to obtain the desired QoS defined by the flow spec parameter. – Send the reservation request upstream. The request that is sent does not necessarily have the same flow spec as the request received from downstream.
1/16/2002 CS 497 Hou 10
Reservation Styles
• Wildcard-Filter (WF) Style -- WF(*{Q}) – Creates a single reservation shared by flows from all upstream senders belonging to the unicast (multicast) session. – The reservation propagates towards ALL sender hosts and automatically extend to new senders as they appear. – Shared by all the senders to the address • Fixed-Filter (FF) Style -- FF(S{Q}), FF(S1(Q1), S2(Q2), …) – Creates distinct reservations for data packets from a particular sender, not sharing them with other sender‟ packets for the same session. distinct reservations for each sender and provides explicit list of senders • Shared-Explicit (SE) Style -- SS((S1, S2, …) {Q}) – Creates a single reservation shared by selected upstream senders. – Allows a receiver to explicitly specify the set of senders to be included.
1/16/2002 CS 497 Hou 11
RSVP Reservation Styles
Reservations
Sender Selection Explicit
Wildcard
Distinct
Shared Shared Explicit
Wildcard Filter
Fixed Filter
None
•Shared reservations (WF and SE) are appropriate for multicast applications in which multiple sources are unlikely to transmit simultaneously (packetized audio for example). •FF style makes separate reservations for each sender, and is appropriate for video applications.
1/16/2002 CS 497 Hou 12
Reservation Style Examples
S1 S2 a c R1 R2
Router
b
d
R3
Router Configuration
WF(*{4B}) <-- a
c Reserves*{4B}
S1 S2
WF(*{4B}) <-- b
<-- WF(*{4B}) <--WF(*{3B})
<--WF(*{2B})
Reserves*{3B}
d
Wildcard-Filter Reservation Example
1/16/2002
CS 497 Hou
13
Reservation Style Examples (Continued)
FF(S1{4B}) <-- a
S1
S2
Reserves S1{4B}, S2{5B} Reserves S1{3B}, S3{B}
c d
<-- FF(S1{4B},S2{5B})
b
<--FF(S1{3B},S3{B})
<--WF(S1{B})
FF(S2{5B},S3{B}) <--
Fixed-Filter Reservation Example
SE(S1{3B}) <-- a
c
Reserves S1,S2{B} Reserves S1,S2,S3{3B}
S1
<-- SE((S1,S2){B) <--SE((S1,S3){3B})
b
S2
SE(S2,S3{3B}) <--
d
<--SE(S2{2B})
Shared-Explicit Reservation Example
1/16/2002 CS 497 Hou 14
Merging Flow Specs
• The following steps are used to calculate the effective flowspec (Re, Te) to be installed on an interface:
– An effective flowspec is determined for the outgoing interface. This means computing the Least Upper Bound of the flow specs. Least Upper Bound (LUB) here refers to an adequate operation which calculates a flow spec that is at least as large as each of next-hop flow specs. The result of this calculation is a pair (Re, Resv_Te) where Re is the effective Rspec, and Resv_Te is the effective Tspec of the Resv message. – A service-specific calculation of Path_Te, the sum of all Tspecs that were supplied in Path messages from different previous hops is calculated. – (Re, Resv_Te) and Path_Te are passed to the traffic control module. The traffic control module will compute the effective flowspec as the “minimum” of Path_Te and Resv_Te, using service-dependent rules.
1/16/2002 CS 497 Hou 15
RSVP Soft State
• State maintained by RSVP is dynamic
– To change the set of senders of the desired QoS a sender simply sends revised Path and/or Resv messages. – This will cause appropriate update in all nodes along the path. Unused states (due to a route change for example) will time out if they are not explicitly torn down.
• State is refreshed hop-by-hop to allow merging.
– When the received state differs from the stored state the stored state is updated. – If this update causes results in a modification of the state to be forwarded in refresh messages, then these refresh messages are generated and forwarded immediately. – Otherwise propagation of a change stops when it reaches a point where mergin causes no resulting state change.
1/16/2002
CS 497 Hou
16