RSVP : A New Resource ReSerVation Protocol

1
RSVP A New Resource ReSerVation Protocol

• Speaker Bo-Chun Wang

2
Outline

• Introduction
• Design Goals
• Design Principles
• Operation Overview
• Example
• Related Work
• Unresolved Issues
• Summary

3
Introduction

• Internet Protocol
• Best Effort service model
• Not adequate for newer applications
• Present Application Requirements
• Sensitivity to Quality Of Service packets receive
  (QoS)
• Multipoint- to-multipoint communication
  (multicast)
• Different network architectures proposed to meet
  above requirements
• Composed of five distinct components

4
Introduction (Components)

• 1. Flow Specification or flowspec
• Common language between source and network
• 2. Routing
• Routing protocols provide quality routes
• 3. Resource Reservation
• Quantitatively specify QoS required
• Ability to create and maintain resource
  reservations along the path

5
Introduction (Components)

• 4. Admission Control
• Finite network resources
• Admission control algorithms decide which request
  to grant or deny
• 5. Packet Scheduling
• Switch decides whether to transmit next packet
  and which packet
• Packet scheduling algorithms

6
Design Goals of RSVP

• Accommodate heterogeneous receivers
• Adapt to changing multicast group membership
• Exploit the resource needs to use network
  resources efficiently.
• Allow receivers to switch channels.
• Adapt to changes to underlying routes
• Control protocol overhead
• Make the design modular

7
Accommodate Heterogeneous Receivers (Goal 1)

• Receivers paths to receivers have different
  properties from one another
• Receivers do not possess same processing capacity
• Paths to receivers do not have same capacity
• Specifically tailored reservations by
  heterogeneous receivers

8
Adapt to changing multicast group membership
(Goal 2)

• Strawman proposal gt Reinitiates reservation
  protocol every time a new member joined or left
• Reinitiating group size (burdensome )
• Must deal gracefully with changes in multicast
  group membership

9
Exploit the resource needs to use network
resources efficiently (Goal 3)

• Strawman gt Each sender makes independent
  resource reservation along multicast tree
• Branches may share common links
• Duplication gt Wasted resources
• Must allow end users to specify application needs

10
Allow receivers to switch channels(Goal 4)

• Enable receivers to switch among sources
• Simple approach gt Deliver data streams from all
  sources, drop undesired ones at receiver
• Inefficient resource utilization

11
Adapt to changes to underlying routes (Goal 5)

• RSVP not a routing protocol
• Independent of how tree was created
• Routes change from time to time
• RSVP must cope with resulting route changes
• Must automatically reestablish reservations
  along the new paths

12
Control protocol overhead (Goal 6)

• Refresh mechanism of RSVP to deal with route
  changes
• Refreshes reservations periodically
• Flooding of messages !
• RSVP must avoid this explosion

13
Make the design modular (Goal 7)

• General RSVP design should be independent of
  other components
• Integrate co-existence with other components

14
Design Principles Of RSVP

• Receiver-initiated reservation
• Separating reservation from packet filtering
• Providing different reservation styles
• Maintaining soft state in the network
• Protocol overhead control
• Modularity

15
Receiver-Initiated Reservation

• Strawmans Proposal
• Sender Oriented
• RSVP adopts Receiver-Initiated
• Why Receiver Initiated?
• Sender can always transmit
• Receivers know its own capacity
• Receiver are the ones who experience
• Receiver might be paying for the QoS

16
Receiver-Initiated Reservation (Contd.)

• Sender implosion
• Receiver send the information to sender
• Sender would forward them to network in case of
  heterogeneous request
• For large Multicast group it would lead to
  sender implosion
• Example (Cable TV)
• Goal 1 accomplished

17
Receiver-Initiated Reservation (Contd.)

• Deerings IP multicast routing
• Routing Protocol takes the responsibility of
  forwarding all multicast data packets to all the
  members of the group.
• Design Goals 2 achieved.

18
Separating Reservation from Packet Filtering

• Distinction between Resource Reservation and
  Packet Filtering
• Resource reservation specifies what amount are
  resources are reserved for whom
• Packet Filtering selects which packets can use
  the resources
• Different reservation styles are born from this
  distinction between resource reservation and
  packet filtering

19
Providing Different Reservation Styles

• The service requirement of multicast application
  dictates the reservation request.
• Example of different application with different
  service requirement.
• Audio Conferencing, Audio and Video Conferencing.
• RSVP defines different reservation styles
• supports different application needs
• makes efficient use of the network.

20
Providing Different Reservation Styles (Contd.)

• Three Reservation Styles
• No Filter
• Fixed Filter
• Dynamic Filter
• These reservation styles help the switches in
  aggregating reservation request from receivers in
  the same multicast group.

21
Providing Different Reservation Styles(Define)

• No Filter Reservation If no Filter is used than
  any packets destined for that multicast group may
  use the reserved resources. e.g Audio
  Conferencing.
• Fixed Filter ReservationIt allows the receiver
  to receive date only form the sources listed in
  the original reservation request,for the duration
  of the reservation.
• Dynamic Filter Reservation It allows the
  receiver to change its filter to different
  resources over time.

22
Providing Different Reservation
Styles.(Aggregation)

• Fixed Filter Reservation
• Reservation Sharing for receivers with the same
  source list.
• Single pipe with largest amount of resources from
  all the request is reserved for each source
• Example Multicast lecture
• No-Filter Reservation
• Similar to fixed filter reservation
• Receivers dont discriminate between sources

23
Providing Different Reservation Styles
(Aggregation Contd.)

• Dynamic Filter Reservation
• No aggregation
• Each receiver request enough bandwidth for the
  maximum no of input streams that it can handle
• Network reserves enough resources to handle the
  worst case when all the receivers that requested
  dynamic filter reservation take input from
  different source
• Design goals 3 and 4 met

24
Maintaining Soft Statein the network

• Handling resource reservation in a multicast
  group in a way transparent to the application
• New members join,existing leave and routes may
  change at intermediate switches.
• RSVP maintains a soft state at the intermediate
  switches .
• RSVP distinguishes state information of two kinds
• Path State
• Reservation State

25
Maintaining Soft Statein the network (Contd.)

• Path Message Each data source periodically sends
  a Path Message which establishes or updates it
  Path State.
• Reservation Message Each receiver periodically
  sends a Reservation Message which establishes or
  updates it Reservation State.

26
Maintaining Soft Statein the network (Contd.)

• Sender advertises PATH messages to receiver
• PATH TSpec AdSpec Flag F
• TSpec Specify the traffic characteristics
• AdSpec
• Contain information about the paths resources
• Updated in every RSVP capable router
• Help receivers calculate the resources needed to
  obtain desired QoS
• Flag Findicate if the application wishes to
  allow filtered reservations

27
Maintaining Soft Statein the network (Contd.)

• Any of the receivers can send a reservation
  message up the tree to the sender.
• RESV Rspec filterspec policy data
• Rspec Specify the bandwidth needed
• FilterspecHow reservations are distributed to
  data streams and users.
• Travel upstream in reverse direction of Path
  message
• Routers receive the RESV messages and make the
  reservation (if available resources are more than
  Rspec resources)

28
Maintaining Soft Statein the network (Contd.)

• Both Path messages and reservation messages carry
  timeout value used by intermediate switches
• Whenever a timer expires the corresponding state
  is deleted
• Handling new route or membership changes
• Design goal 5 met

29
Protocol Overhead Control

• RSVP protocol overhead is determined by three
  factors
• Number of RSVP messages.
• Size of the RSVP messages.
• Rate at which the RSVP messages are send.
• RSVP takes care of all the three overhead.

30
Protocol Overhead Control

• Number of RSVP messages
• Merging of path messages
• Merging of reservation messages
• Size of RSVP messages
• Max size of messages is proportional to the data
  sources upstream.
• Rate at which RSVP messages are send.
• Tuning the time out values
• Design Goals 6 accomplished.

31
Modularity

• RSVP Interfaces to 3 different Components
• FLOWSPEC
• NETWORK ROUTING PROTOCOL
• NETWORK ADMISSION CONTROL
• RSVP should be as independent as possible from
  these components .

32
Modularity (Contd.)

• RSVP considers flowspec as just some bytes of
  data that needs to be exchanged.
• RSVP assumes admission control algorithm to be
  Switch admitting or rejecting the signal
• RSVP assumes that resource reservation is
  established if the switches along the path admit
  the flow
• Design Goals 7 is accomplished.

33
Operation Overview
SOURCE
SWITCH
RECEIVER
H1 ROUTING TREE
H2 ROUTING TREE
H5
H1
S1
S4
H4
S2
S3
H2
H3
34
Operation Overview (Contd.)
SOURCE
SWITCH
RECEIVER
H1 ROUTING TREE
H2 ROUTING TREE
H5
H1
S1
S4
H4
S2
S3
H2
H3
35
Operation Overview (Contd.)
R3
R2
R4
R1
Host B 128.32.32.69
Host A 24.1.70.210
R5
36
Operation Overview (Contd.)
R3
R2
R4
PATH
R1
PATH
Host B 128.32.32.69
PATH
PATH
Host A 24.1.70.210
R5
37
Operation Overview (Contd.)
(3) 50Kbs
R1
(6) 100 Kbs
R3
(2) 50Kbs
(5) 100 Kbs
(9) 60Kbs
R4
R6
R7
(8) 60Kbs
(1) 50Kbs
(4) 100 Kbs
38
SOURCE OR
RECEIVER
Example Network topology
SWITCH
H3
H2
L3
L2
S2
L7
L6
S3
S1
L4
L5
L1
H4
H5
H1
39
Example

• Simple network configuration
• Five hosts, seven links, three switches
• Assumption Adequate resources exist for all
  reservation requests
• Case1 No filter Reservation
• Case 2 Filtered Reservation

40
Case 1 No-Filter Reservations

• Routing protocol has built multicast tree
• Hosts behave as source receiver
• Each switch has received RSVP path messages (F
  flag off)

S1 S2 S3
Incoming links Outgoing links L1, L2, L6 L1, L2, L6 L5,L6,L7 L5,L6,L7 L3,L4,L7 L3,L4,L7
41
Case 1 (Reservations )

• H1 wants to receive data from all senders
• Sends R1(B, no-filter) to S1
• First, reserves B over L1
• Forwards reservation to L2,L6

S1 S2 S3
Incoming links Outgoing links L1, L2, L6 L1(B), L2,L6 L5,L6,L7 L5,L6,L7 L3,L4,L7 L3,L4,L7
42
Case 1 (Contd.)

• S2 reserves B over L6
• Forwards to L5, L7
• S3 reserves B over L7
• Forwards to L3, L4

S1 S2 S3
Incoming links Outgoing links L1, L2, L6 L1(B), L2, L6 L5,L6,L7 L5,L6(B),L7 L3,L4,L7 L3, L4,L7(B)
43
Case 1 (Contd.)

• H2 sends R2(B,no-filter), to S1
• S1 reserves B over L2
• Forwards to L1 only

S1 S2 S3
Incoming links Outgoing links L1, L2, L6 L1(B), L2(B), L6 L5,L6,L7 L5,L6(B),L7 L3,L4,L7 L3, L4,L7(B)
44
Case 2 Filtered Reservations

• H1,H4,H5 gt sources
• H2,H3,H4,H5 gt receivers
• Each switch has received RSVP path messages
• (F-flag on )

45
Case 2 (Contd.)

• H2 sends R2(B,H4)
• Finds H4 listed as source, gets previous hop
• S1 Reserves B over L2
• Forwards R2(B,H4) over L6 to S2

S1
Outgoing links L2( src H1,H1 L6( src H1,H1) H4,S2 H5,S2)
46
Case 2 (Contd.)

• S2 reserves B over L6
• Checks path state
• Forwards R2(B,H4) to S3

S2
Outgoing links L5( src H1,S1 L6( src H4,S3 L7(src H1,S1 H4,S3) H5,H5) H5,H5)
47
Case 2 (Contd.)

• S3 reserves B over L7
• Checks path state
• Forwards message to H4
• Reservation created from H2 to H4

S3
Outgoing links L3( src H1,S2 L4( src H1,S2 L7(src H4,H4) H4,H4 H5,S2) H5,S2)
48
Related Work

• Stream Protocol (ST)
• ST II
• Dissemination-oriented approach

49
Unresolved Issues

• Newer routing algorithms must accommodate support
  for resource reservation algorithms
• Support other filter styles
• Simulations done on small networks and small
  multicast groups

50
Summary

• Provides receiver initiated reservations to
  accommodate heterogeneity
• Separates filter from reservations, thus allowing
  channel changing behavior
• Supports multipoint to multipoint communication
  by taking a soft state approach
• Decouples reservation and routing functions