1. RSVP: A New Resource ReSerVation Protocol
Ifiok Udowana
Edgar Duskin

2. Motivation Current Internet service model flaws
Failure of point-to-point service model to guarantee quality of service
Many new applications are not point-to-point

3. Components of new Architecture
Flow specification
Describes the characteristics of the traffic stream sent by the source and the service requirements of the application
Routing
Protocol that can provide quality unicast and multicast path
Resource reservation
Ability to create and maintain resource reservations on each link along the transport path

4. Components of new architecture cont’d
Admission control
Determines which reservation requests to grant and which to deny in order to maintain an appropriate network load
Packet scheduling
Determines which qualities of service the network can provide

5. RSVP: Resource reservation protocol
Description:
It is a simplex protocol. i.e. reserves resources in one direction
It is receiver oriented, thus can accommodate heterogeneous receivers in a multicast group
Receivers can change channels without changing its reservation
Provides different reservation styles
Uses soft-state in the switches

6. RSVP design goals Accommodate heterogeneous receivers
Adapt to changing multicast group membership
Exploit the resource needs of different applications in order to use network resources efficiently
Allow receivers to switch channels
Adapt to changes in the underlying unicast and multicast routes
Control protocol overhead so that it does not grow linearly (or worse) with the number of participants
Make the design modular to accommodate heterogeneous underlying technologies

7. RSVP design goal 1 Accommodate heterogeneous receivers
Different receivers may have different capacities for data processing
Different paths may not have same capacity
Different receivers may require different qualities of service
Strawman proposal
Serves only point to point
Incapable of dealing with receiver heterogeneity
Results in waste of resource.

8. RSVP design goal 2 Adapt to changing multicast group membership
Deals gracefully with changes in multicast group membership
Strawman Proposal
Reinitiates the reservation protocol every time there is a change in membership

9. RSVP design goal 3 Efficient use of network resource Strawman Proposal
Allow end users to specify their application needs so that reserved resources reflect the actual needed resource
Strawman Proposal
Often reserves redundant resources
question: what is an example of an application that would waste resource under the strawman proposal?

10. RSVP design goal 4 Channel switching Strawman Proposal
a receiver should be able to control which packets are carried on its reserved resources
Switching among sources should be done without a new reservation request
Strawman Proposal
All data streams from all sources are delivered and undesired ones are dropped at the receiver
question: what current communication system works like the strawman proposal?

11. RSVP design goal 5 Changes in routes Strawman proposal:
RSVP should deal gracefully with changes in routes but not interfere with current routing protocols
Automatically reestablish resource reservations on new paths
Strawman proposal:
Has no mechanism to detect changes in routes, thus does not deal gracefully with such changes

12. RSVP design goal 6 Control overhead growth Strawman proposal
avoid explosion in overhead with a large multicast group
Incorporate tunable parameters used to adjust amount of overhead
Strawman proposal
Overhead explodes with increasing size of multicast groups

13. RSVP design goal 7 Modular design/interoperability
Ability to work with networks with different routing protocols
Tied closely to flowspec and interfaces to routing and admission control\
General protocol design remains independent of other algorithms “IP-unicast, IP-multicast, CBT”

14. Basic design principles
Receiver initiated reservation
Separating reservation from packet filtering
Providing different reservation styles
Maintaining “soft-state” in the network
Protocol overhead control
Modularity

15. RSVP design principle 1 Receiver-initiated reservation
Adopts a receiver based design principle
Receivers are responsible for initiating and keeping reservation active
Possible solution
Receivers send information to source and the source uses this information to send out reservation request
questions:
what is the problem with this approach?
in what example system will this solution fail?

16. RSVP design principle 2 Separating reservation from packet filtering
Resource reservation specifies what amount of resource is reserved for whom
Packet filtering selects those packets that can use the reserved resources
Filter is dynamic

17. RSVP design principle 3 Providing different reservation styles
No filter
Fixed filter
Dynamic filter
question: give one example of each type of filtering

18. RSVP design principle 4 Maintaining “soft-state” in the network
Soft-state: refers to a state maintained at network switch which, when lost, will be automatically reinstated by RSVP soon thereafter
RSVP two kinds of states at intermediate nodes
Path state
Reservation state
Path message: periodically sent by the source to establish or update the path states
Reservation message: periodically sent by the receiver to establish or update the reservation states
question: what is the disadvantage of the soft-state approach?

19. RSVP design principle 5 Protocol Overhead Control
Total overhead = [Number of messages sent] * [Message Size] * [Message Frequency]
RSVP controls these factors to reduce overhead:
Merges path & reservation messages to reduce number of total messages per period
Tunes timeout values of path & reservation messages to reduce message frequency

20. RSVP design principle 6 Modularity
RSVP should be as independent as possible from other components
Makes some assumptions for interoperability:
Admission control: each switch in the path will either accept or reject the flow
Packet scheduling can change packet filters without establishing new reservations

21. RSVP Operation
Establishes a sink tree from each receiver to all sources (reverse tracing)
Path messages are forwarded along the multicast routing tree
Reservation messages only propagate to a point on the tree where there is a greater resource reservation
Switches use path states to maintain incoming and outgoing multicast interfaces for each supported group
For each outgoing link there is a list of senders & previous hop addresses
There is also reservations, consisting of a reserver, a filter and the reservation amount

22. RSVP Operation, cont’d When a switch receives a path message:
Checks for an existing path state for named target
Creates path state for target
Obtains outgoing interface from routing protocol
Updates its incoming/outgoing links table
Records source address if filtered reservation is required
Forwards path message only if there is a new source or a route change
Detects route changes by comparing outgoing interfaces of the routing table to outgoing links in the path state
Periodically sends its own path message if the incoming path message was discarded
Switch’s path message contains path information carried in all the path messages received in the past

23. RSVP Operation, cont’d
When receiver receives a path message from a desired source:
Sends reservation message along sink tree
If reservation is rejected by any switch in path, RSVP reject is sent to receiver
Otherwise, message propagates to the closest point where a reservation level is equal or greater
Once reservation is established, periodic reservation refreshes are sent and merged by switches with other requests of the same multicast group
When a sender or receiver wants to terminate the connection:
Sender/Receiver sends out path/reservation teardown message
No retransmission timer on the teardown message
Resources are released when teardown message reaches switch (except for no-filter and fixed-filter reservations)

24. Example: No-filter Assumptions: Path State:
Routing protocol has built multicast tree & sender can reach all receivers
Each switch has received RSVP path messages with the f-flag off and stored complete path state
No reservations have been made yet
Path State:

25. Example: No-filter
H1 wants to receive data from all other senders with bandwidth B (one audio stream)
Sends reservation message R1(B,no-filter)
S1 receives message and makes reservations on outgoing link L1:
S1 forwards R1 to incoming links L2 & L6
R1 reaches S2, which reserves B on L6 and forwards along L5 & L7
R1 reaches S3, which reserves B on L7 and forwards along L3 & L4

26. Example: No-filter
H2 wants to receive data from all other senders with bandwidth B (one audio stream)
Sends reservation message R2(B,no-filter)
S1 receives message and makes reservations on outgoing link L2:
S1 forwards R2 to incoming link L1 only (because of identical previous request)
All reservations for B have been reserved over the network
question: What is the disadvantage to using no-filter in this case?

27. Example: filtered reservations
Assumptions:
H2, H3, H4 and H5 are receivers
H1, H4, and H5 are sources
Path messages have F-flag set
S1 has received path messages from all sources
No reservations have been made yet

28. Example: filtered reservations
H2 wants to receive packets from H4 only with bandwidth B
Sends reservation message R2(B,H4)
S1 receives R2 on L2, knows that it has heard H4 as a source and that the previous hop was S2
S1 reserves B on L2
S1 forwards R2 over L6 to S2.

29. Example: filtered reservations
S2 receives R2
Reserves B on L6
Forwards R2 to S3 (previous hop for H4)
S3 receives R2
Reserves B on L7
Forwards R2 to H4 (source)
Reservations have been made for H2 receiving only B from H4

30. Example: filtered reservations
H5 wishes to receive 2B from any source
Sends reservation message R5(2B,*), * indicates dynamic-filter
S2 receives R5 and reserves 2B over L5
S2 forwards R5 over L6 & L7
S1 receives R5 and knows H1 is the only source, reserves only B over L6 and passes request to H1
S3 receives R5 and knows H4 is the only source and also knows B has already been reserved over L7
S3 does not make any reservations or forward R5

31. Example: reservation teardown
H4 decides to terminate both receiving and sending, but does not send a teardown message
All related H4 reservations will eventually time out
Resulting switch path states:
S1 stops forwarding R2, sends RSVP error to H2
S2 forwards future R5 refreshes to L6 only (since no more sources exist off of L7)

32. Summary
RSVP
Provides receiver-initiated reservations to accommodate heterogeneity among receivers as well as dynamic membership changes
Separates the filter from the reservation, allowing channel changing behavior
Supports a dynamic and robust multipoint-to-multipoint communication model by taking the soft-state approach in maintaining resource reservations
Decouples the reservation and routing functions and thus can run on top of any existing multicast routing protocols

33. Critique RSVP works in theory but remains largely untested
How well will RSVP work with other unicast and multicast routing protocols?
The periodic refreshing creates overhead which may interfere with delay-sensitive applications
In order to implement RSVP, every node, router and switch must have support for RSVP