1. RSVP Bandwidth Reduction in TSVWG
draft-polk-tsvwg-rsvp-aggregate-bw-reduction-00
James M. Polk
Subha Dhesikan
4th August 04

2. Why is this important?
RSVP sets up reservations based on many things (newsflash!)
one of these properties is the bandwidth required for the RSVP flow
RSVP in RFC 3175 created the ability to Aggregate individual flows into a “super-flow”
RFC 3181 created a priority capability for flows
RFC 2205 created the means of preempting flows
Here’s the rub, when something needs some BW that is in an Aggregate, the whole Aggregate currently gets torn down
to be left to attempt reestablishment at “some” lower BW amount

3. Reduction Scenario using Aggregates I5
flows
Router 1
Router 2
Router 3
Router 4 5
flows
Single
circuit
Aggregate A
Aggregate A
Router 9
Router 10
Interface at capacity with the 10 flows
Aggregate B
Aggregate B 5
flows
Router 5
Router 6
Router 7
Router 8 5
flows
Priority of Aggregate A > Priority of Aggregate B

4. Reduction Scenario using Aggregates II
6th flow signaled
into Aggregate A
Problem at this Interface (no capacity) 5
flows
Router 1
Router 2
Router 3
Router 4 5
flows
Single
circuit
Aggregate A
Aggregate A
Router 9
Router 10
Interface at capacity with the 10 flows
Aggregate B
Aggregate B
Router 5
Router 6
Router 7
Router 8 5
flows 5
flows
Priority of Aggregate A > Priority of Aggregate B

5. How can this be addressed?
If the ResvErr message includes a BW amount that is still available at the router, the Aggregate can be shrunk to that amount, and not torn down
This will force the Deaggregator to drop some individual flows to achieve this lower BW amount (for the existing aggregate)
This increases efficiency and reduces packet loss within the Aggregate
Nothing here is limited to RSVP Aggregation

6. Reduction Scenario using Aggregates III
6th flow signaled
into Aggregate A 5
flows
Router 1
Router 2
Router 3
Router 4 5
flows
Aggregate A
Aggregate A
Router 9
Router 10
Solution: Router 9 sends a Bandwidth Reduction message to Router 8
to clear an amount of bandwidth
Aggregate B
Aggregate B
Router 5
Router 6
Router 7
Router 8 5
flows 5
flows

7. Reduction Scenario using Aggregates IV
6th flow signaled
into Aggregate A 5
flows
Router 1
Router 2
Router 3
Router 4 5
flows
Aggregate A
Aggregate A
Router 9
Router 10
Solution: Router 9 sends a Bandwidth Reduction message to Router 8
to clear an amount of bandwidth
Aggregate B
Aggregate B
Router 5
Router 6
Router 7
Router 8 5
flows 4
flows

8. Reduction Scenario using Aggregates V
6th flow signaled
into Aggregate A
6th flow
Solution: This clears the way for flow 6 of Aggregate A to be completed 5
flows
Router 1
Router 2
Router 3
Router 4 5
flows
Aggregate A
Aggregate A
Router 9
Router 10
Aggregate B
Aggregate B
Router 5
Router 6
Router 7
Router 8 5
flows 4
flows

9. Open issues
Do we include this tspec in the ResvTear message and specify that the Aggregator *not* ignore it?
Do we need to address the case in which the Err message are sent, but the flow is not reduced in a timely manner?
unnecessary if above bullet answer is yes
Should the text be opened up to individual flow considerations?
to allow endpoints to adjust to the decreased bandwidth allocation (perhaps use a lower bw codec)
comments to this affect already

10. Plans for Effort Going to rev the effort in short order
Can RSVP Extensions become a TSVWG item?
chairs??
If so, is this effort worthy?