1. RSVP: A New Resource ReSerVation Protocol
Stan Komsky and Scott Travis
8/26/06

2. Introduction Protocol to reserve QoS for a connection
Solves the issue of negotiating QoS between routers across the entire connection
Special path/reservation packets create a path to provide a needed QoS
Tested at packet-level, implemented in routers

3. Background
Need for a protocol to negotiate QoS and specifications for flow
By providing QoS and flow specifications across a connection, applications which require QoS such as VoIP and multimedia streaming can get the service they need
RSVP transparently handles this task by separating the jobs of routing and resource reservation

4. Providing QoS and Flow Specifications
Providing QoS and flow specifications is not handled by other protocols
As newer technologies required guaranteed services, a protocol to handle these needs became necessary
RSVP was proposed to solve this problem as efficiently and transparently as possible

5. Design Principles Receiver-Initiated Reservation
Motivation for this rather then source-initiated design.
What are the advantages of initiating reservation from the receiver then the source?
Allows for any number of different receivers with different needs to individually request resources
Takes burden of reservation off of the source

6. Design Principles Separating Reservation from Packet Filtering
Reserving resources does not specify which packets use the resources, only how much should be reserved and for whom it’s reserved
The filter controls which packets use the resources
Filter is dynamic and can be changed without changing the amount of reserved resources
Why is this separation important?
If there was no separation, resources would need to be re-negotiated every time the filter changed or the filters would need to be specified again if the reservation changed

7. Design Principles Providing Different Reservation Styles
Made to support different needs of various application while making the most efficient use of network resources.
Three styles:
No-filter
Any packets may use the reserved resources.
Fixed-filter
A fixed set of packets can use the resources. The receiver will receive data only from the sources listed in the original reservation request.
Dynamic-filter
A set of packets can use the resources, this allows the receiver to change its filter to different sources over time.
Receivers specify the style needed for each resource request
If a receiver does not discriminate between sources, it cannot switch between the sources either.

8. Design Principles Maintaining “Soft-State” in the Network
Switches kept in a “soft-state” (state that, when lost, will automatically be reinstated)
Why is this beneficial?
Due to routing changes or service outages, paths can change to keep the guaranteed service. By using a “soft-state,” the switch/protocol can quickly react to these changes
Uses a path and a reservation state
Path messages use the underlying routing protocol to move a flow specification (flowspec) and filter flag (F-flag) through the switches the connection will use
Reservation messages carry a flowspec, reservation style, and (if needed) a packet filter
Switches update their path and reservation states whenever a new path/reservation packet is received

9. Design Principles Protocol Overhead Control
Number of RSVP messages sent
No more than a single path/reservation message sent in a single refresh period
Size of RSVP messages
Proportional to number of upstream sources
Refresh frequencies (path/reservation)
Picking intelligent timeout values

10. Design Principles Modularity
RSVP interfaces with other components in the architecture
Flowspec is handed to RSVP by an application or some session control protocol
Underlying routing protocol establishes the path state RSVP will use at the switches along the connection
Network admission control determines if a request for resources made in the flowspec of the reservation packet can be accepted
Why is modularity important?
Keeps RSVP as transparent as possible by letting other protocols handle everything except the reservation of resources

11. Performance Evaluation
RSVP was simulated using a custom simulator which was used in several other protocol simulations
Simulator provided modules to imitate hosts, links, IP routers, and several different protocols
RSVP was implemented and tested on top of these network components and protocols
Features of RSVP were developed through simulation and redesign over time
RSVP was implemented in a cross-country network, but no systematic performance studies had been done by the paper’s publication date

12. Results?
As mentioned in class, RSVP is still used to convey QoS requirements and flow specifications for switches along a connection
The protocol is very lightweight
Although it understandably introduces some overhead, the benefits of reliable QoS outweigh the costs
Since RSVP is transparent to other protocols, it has been able to survive over time as other protocols have matured, changed, or been replaced
RSVP could be negated by IPv6 because of the flow controls available with IPv6

13. Example 5 hosts connected by 7 point-to-point links and 3 switches
Assumptions
Adequate network resources available for all reservation requests
Path has already been established, no F-flag (no-filter reservation style used)
Multipoint-to-multipoint example of a voice conference, so each host is both a sender and receiver

14. Example L2 R2(B, no filter) R3(B, no-filter) H2 H2 H3 H3 L3 L3 L2 L6S1 S1
R1(B, no-filter)
R1(B, no-filter) S2 S2
R1(B, no-filter)
R1(B, no-filter) S3 S3 B B B L4 L4 B B B B L1 L1 L5 L5 B
R1(B, no-filter)
R4(B, no-filter) H4 H4 H1 H1
R5(B, no-filter) H5 H5

15. Related Work Stream Protocol (ST and ST-II)
ST used unicast routing to support a multicast resource reservation and was designed to support voice conferencing
This required a central Access Controller to coordinate the connections
ST-II did not change this, but used multiple reservations to eliminate the Access Controller
Used a single flowspec, so it could not handle herterogeneous receivers
Neither handled multipoint-to-multipoint resource reservation
RSVP was designed to fill this gap
Other proposals were made, but still focused on single source applications or focused on interfacing with applications rather than providing a protocol for resource reservation that works in, and responds to, changes in the network itself

16. Critique Paper mentioned adaptive timeout values for overhead control
We feel this should have been designed in from the start as the benefits could improve both the reliability and efficiency of RSVP
There can be an over-reservation of resources on certain links if the F-flag isn’t set. This is caused by receivers requesting more bandwidth (ex. 2B) than needed for their connections when there is only one upstream source serving B bandwidth worth of data
This can be fixed by using F-flags so switches keep track of source numbers, but this adds extra overhead

17. Summary/Conclusion
RSVP successfully allows a network to establish a QoS and flowspec across both single point and multipoint connections
Uses receiver-initiated reservation to deal with heterogeneous receivers of any number
By being transparent, RSVP allows for these services without interfering with other protocols or having unnecessary requirements
The separation of resource reservation and packet filtering within the RSVP protocol allows for each to be dynamically changed without interfering with the other
RSVP is an important part of network communications, especially with QoS and flow control becoming more and more important based on the evolution of networked applications such as VoIP

18. Questions?

19. Puzzle
Three people check into a hotel. They pay $30 to the manager and go to their room. The manager suddenly remembers that the room rate is $25 and gives $5 to the bellboy to return to the people. On the way to the room the bellboy reasons that $5 would be difficult to share among three people so he pockets $2 and gives $1 to each person. Now each person paid $10 and got back $1. So they paid $9 each, totaling $27. The bellboy has $2, totaling $29. Where is the missing $1?

20. Puzzle Solution
We have to be careful what we are adding together. Originally, they paid $30, they each received back $1, thus they now have only paid $27. Of this $27, $25 went to the manager for the room and $2 went to the bellboy.