Resource ReServation Protocol

1
Resource ReServation Protocol
Department of Computer Science University of
Illinois at Urbana Champaign
CS 497 Special Topics in Advanced Networking
Research

• Jennifer Hou

2
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.

3
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.

4
RSVP Architecture
RSVP
RSVP Process
RSVP Process
Application
Policy Ctrl
Policy Ctrl
Routing Process
Admis. Ctrl
Packet Scheduler
Admis. Ctrl
Packet Scheduler
Classifier
Classifier
data
Router
Host
5
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.

6
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.

7
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 hops
  unicast address. This unicast address is used to
  route reservation messages hop-by-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.

8
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.

9
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 Rspecparameter (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.

10
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.

11
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.
• Fixed-Filter (FF) Style -- FF(SQ), 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.
• 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.

12
RSVP Reservation Styles
Reservations
Sender Selection
Shared
Distinct
Explicit
Fixed Filter
Shared Explicit
Wildcard Filter
None
Wildcard

• 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.

13
Reservation Style Examples
a
c
R1
S1
Router
R2
d
S2
R3
b
Router Configuration
a
c
WF(4B) lt--
lt-- WF(4B)
S1
Reserves4B
lt--WF(3B)
Reserves3B
d
S2
b
WF(4B) lt--
lt--WF(2B)
Wildcard-Filter Reservation Example
14
Reservation Style Examples (Continued)
lt-- FF(S14B,S25B)
a
c
FF(S14B) lt--
Reserves S14B, S25B
S1
lt--FF(S13B,S3B)
b
Reserves S13B, S3B
S2
d
lt--WF(S1B)
FF(S25B,S3B) lt--
Fixed-Filter Reservation Example
a
c
lt-- SE((S1,S2)B)
SE(S13B) lt--
S1
Reserves S1,S2B
b
lt--SE((S1,S3)3B)
Reserves S1,S2,S33B
d
S2
lt--SE(S22B)
SE(S2,S33B) lt--
Shared-Explicit Reservation Example
15
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.

16
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.
• Sate that is forwarded out on interface I must
  be calculated using only state that arrived on
  interfaces different from I.