1. RSVP by Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, Daniel Zappala
Karan Munalingal
Justin Norvell
Varun Prasad

2. INTRODUCTION Current internet model
point to point Best-Effort service
New applications are making this inadequate
Better than best effort is needed. e.g. Audio
Not always point to point. e.g. Video Conferencing
New architectures can be divided in 5 components

3. 5 components of QoS Flow Specification Routing Resource Reservation
Admission Control
Packet Scheduling

4. RSVP: a resource ReSerVation Protocol
Handles the Resource Reservation aspect of QoS
Simplex Protocol
Receiver Oriented Reservation Styles
Concept of “Soft-State”

5. Design Goals Allow heterogeneous receivers to tailor reservations
Deal gracefully with changes in a multicast group membership
Allow end users to specify their application needs
Enable a “Channel Changing” feature
Deal gracefully with route changes and automatically reestablish the reservations along the new paths.
Control protocol overheads
After scrutinizing the strawman proposal, design goals were created to fill the gaps that the strawman proposal fails to.
Heterogeneous receivers should be able to tailor reservations because different receivers have different capabilities (processing power etc)
With multiple receivers, the membership in a multicast group can be dynamic. Therefore, reinitiating the reservation protocol everytime a new member joins would be a bad idea. There should be a mechanism that deals with such changes in a dynamic group.
Third design is important because it will prevent wastage of resources. Eg: in a audio conference, only one person talks at a time, therefore instead of reserving enough bandwidth for all members, it would be adequate to reserve only enough resources to support few simultaneous audio channels.
Channel changing feature is important because one receiver may want to receive feed from various sources. Eg: multiparty conference, one person wants to watch another person on the conference.
Due to a volatile topology and load, routes may change in a large internetwork. RSVP should be able to adjust to these changes to keep the network up. One way to do this would be to by periodically making the source/receiver sent reservation messages.
As seen above, high volume of reservation messages sent to the intermediate switch will ultimately lead to explosion in protocol overhead.

6. Basic Design Receiver Initiated Reservation Packet Filtering
Reservation Styles
Soft State
Controlling Protocol Overhead
Modularity
Following are the components of the Basic Design of the new RSVP.

7. Receiver Initiated Reservation
Receiver initiates reservation and can control the amount of resources used.
This works better because only the receiver knows the amount of resources it has available.
With previous solutions if receivers sent request information directly to the source it would overwhelm the source.
The solution is that the receiver sends requests to switches where they are grouped together and sent as an overall request.

8. Separate Reservation from Packet Filtering
Resource reservations provide resources to the entity that makes the reservation (i.e. what amount and to whom).
Packet filtering determines which packets from a source are allowed to use the resources.
Filter changing does not change the amount of resources allocated by resource reservations.

9. Reservation Styles
RSVP provides receivers to make 3 different types of reservations: no-filter, fixed-filter and dynamic-filter.
No-filter: Any and all packets sent from the source can use the reserved resources for the multicast group.
Fixed-filter: Only packets from sources listed in request will be received by receiver.
Dynamic-filter: Receiver can change filter settings over time allowing it to reject already selected sources and add completely new ones without making new requests.

10. Soft State
Adjust resource reservations due to dynamic status changes at intermediate switches.
Two kinds of state information.
Path state – Path message periodically sent by data source to intermediate switches.
Flowspec , F-flag.
Reservation state - Reservation message periodically sent by receivers to intermediate switches.
Flowspec, Reservation style and a packet filter.
Timeout mechanism used by intermediate switches.
Maintenance of the reservation state.
In multipoint-to-multipoint applications dynamic changes can occur, for eg: new members join/ existing members leave and routes may change due to these dynamic status changes. Therefore to adjust RR accordingly, there exists a soft-state which leaves the responsibility of reservations to the receivers.
Two kinds of state information at each intermediate switch are Path state and Reservation state.
Path state – A path message carries a flowspec by the data source and the F-flag which indicates if the applications allows filtered reservations. Upon successful processing of a path message, a switch updates, a) the incoming link upstream to the source, b) outgoing links to the receivers, c) F-flag information, if off then it does not maintain any information about the specific source, which only allows for no-filter style. If its ON, it keeps updates information about the source and the previous hop upstream to reach that source, which allows accommodation for any type of reservation style.
Reservation Path – A reservation message carries information like flowspec, reservation style and packet filter (fixed/dynamic). After processing a reservation message, the switch updates the reservation state by recording, a) amount of resources reserved, b) source filter for reserved resource, c) reservation style, if dynamic then updates the reserver. Reservation messages are forwarded back towards the sources by reversing the paths of path messages.
Both path and reservation messages carry a timeout value to delete the corresponding state. It prevents resources from going to waste if a receiver fails to send a message or underlying route changes. Sources and Receivers are responsible for sending their corresponding messages periodically. When there is a change in routes, the routing protocol underlying the RSVP updates the route and forwards the new path messages on the new route, there by causing the reservation messages to take the new path.
Maintenance of the reservation state is carried out by periodically refreshing the path/reservation state. However, periodically refreshing such information adds major overhead to the protocol operation which we discuss in the next section.

11. Protocol Overhead RSVP overhead is determined by three factors:
Number of RSVP messages sent.
The size of these RSVP messages.
The refresh frequencies of these messages.
RSVP controls the refresh frequencies factor by tuning the timeout values.
Tradeoff between Overhead and RSVP’s responsiveness in adapting to dynamic changes.
Current RSVP uses static timer values.
RSVP controls the third factor by tuning the timeout values. The higher the timeout values, less frequent the refresh messages have to be sent.
Tradeoff example: if reservation messages are forwarded according to the path state maintained at switches, which gets synchronized with the routing protocol state every path state. When a route changes, reservation messages will not follow the new route until the new path message is sent out, because reservation messages traverse a reverse path to the source.
The current usage of static timer values are chosen on the basis of engineering judgment. Optimal solutions/algorithms will be investigated in the future.

12. Modularity RSVP interfaces with other components in the architecture:
Application.
Network Routing Protocol.
Network Admission Control.
Desire RSVP to be as independent from other components as possible.
Interfaces:
The flowspec is handed to RSVP by an application when invoking RSVP.
The network routing protocol forwards path messages towards all the receivers causing RSVP path state to be established at intermediate switch nodes.
Network admission control, which makes an acceptance decision based on the flowspec carried in the reservation messages.
Modularity is on of the design goal, because we would like to make RSVP as independent from the other components as possible.

13. Operation Overview
Switches maintain list of incoming and outgoing interfaces
Path messages from sources are forwarded only if there is no path state for the target
Reservation messages forwarded only as far as needed
If reservation is rejected, RSVP reject message is sent back
Reservation is maintained by periodic reservation refresh messages
Reservation ends by timeout, or explicit teardown message
Since reservation messages are initiated by the receiver, the RSVP must ensure that the messages from the receiver follow exactly the reverse route of the data stream from all sources. Thus what is known as a sink tree is established, from each receiver to all the sources to forward reservation messages.
The sink tree is formed by tracing in reverse the path from the receiver to each source. Path messages are forwarded along the routing tree as provided by the routing protocol.
Reservation messages are forwarded to the closest point on the sink where a reservation >= the request is made.
Each switch maintains a list of incoming and outgoing interfaces
Teardown messages are not applicable in no-filter or fixed filter cases

14. No-Filter Example Network Topology Audio Conference 5 Hosts 3 Switches
Assumptions
All Path messages Sent
Routing Protocol has built multicast tree
No reservations made yet

15. No-Filter Example
Network Topology
Initial Path Tables

16. No-Filter Example Network Topology H1 wants data from all senders
Sends R1(B, no-filter) to S1
S1 reserves B on L1 and forwards to all incoming links
And so on

17. No-Filter Example Network Topology Now,H2 wants data
Sends R2(B, no-filter) to S1
S1 reserves B on L2 and forwards to L1 only
After all receivers have sent messages, B has been reserved over all 7 links

18. No-Filter Example Network Topology
TRADEOFFS of not keeping track of sources:
Over-reservation of resources
L1, L2, L3, L4 and L5 would have 2B outgoing, though they can send only B

19. Filtered Example Network Topology Filtered ExampleS
R/S
R/S
Filtered Example
H2, H3, H4, H5 are receivers
H1, H4, and H5 are sources
Assumptions
F-Flag set
Path messages have been sent
No reservations yet

20. Filtered Example Network TopologyS
R/S
R/S
Path state keeps track of source, and last hop to get to that source

21. Filtered Example Network Topology H2 sends R2(B,H4)
R/S
R/S
H2 sends R2(B,H4)
S1 reserves B over L2. Forwards to S2.
S2 reserves B over L6. Sends to S3.
S3 reserves B over L7. Sends to H4.

22. Filtered Example Network Topology H5 sends R5(2B,*)
R/S
R/S
H5 sends R5(2B,*)
S2 reserves 2B over L5. Forwards over L6 and L7.
S1 reserves B over L6 (1 source). Sends to H1.
S3 does nothing.

23. Implementation Status
The design has been tested in a packet-level interactive simulator created by author Lixia Zhang
Using the simulator code, the protocol has also been implemented by Sugih Jamin (USC) for experimentation on Dartnet (a cross country T1 network)
Preliminary tests have been performed, but no systematic performance studies yet
The simulator provides modules that imitate behavior of common components, such as hosts, links, routers, and protocols such as TCP, IP, UDP
The RSVP design was tested by implementing the protocol in the simulator and observing, step-by-step, how it handles dynamic events such as new senders/receivers joining, existing members leaving, etc.

24. Related Work ST and ST-II Stream Protocol
Created for voice conferencing.
Could make unicast and multicast reservations.
Because it was created when multicast was in its infancy, it created its own unicast by combining multiple unicast paths.
Used a centralized access controller to manage itself.
Stream Protocol II
Instead of a centralized access controller, it used multiple simplex reservations from every source to every receiver. Because of this it couldn’t handle heterogeneous receivers.
More info:

25. Unresolved Issues Design Issues
RSVP designed with minimal expectation of routing
The general service model not defined
Current tests and simulations only deal with smaller networks/multicast groups
Limited knowledge of RSVP’s performance with larger networks
The simulator provides modules that imitate behavior of common components, such as hosts, links, routers, and protocols such as TCP, IP, UDP
The RSVP design was tested by implementing the protocol in the simulator and observing, step-by-step, how it handles dynamic events such as new senders/receivers joining, existing members leaving, etc.

26. Conclusion Criticisms
Not enough testing to conclude that this is viable
Too much load on switches?
Thoughts
Receiver initiated reservation seems like a good idea
Needs a lot more work.
The simulator provides modules that imitate behavior of common components, such as hosts, links, routers, and protocols such as TCP, IP, UDP
The RSVP design was tested by implementing the protocol in the simulator and observing, step-by-step, how it handles dynamic events such as new senders/receivers joining, existing members leaving, etc.

27. The simulator provides modules that imitate behavior of common components, such as hosts, links, routers, and protocols such as TCP, IP, UDP
The RSVP design was tested by implementing the protocol in the simulator and observing, step-by-step, how it handles dynamic events such as new senders/receivers joining, existing members leaving, etc.
Questions?