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

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

Reduction Scenario using Aggregates I 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 5 flows Router 5 Router 6 Router 7 Router 8 5 flows Priority of Aggregate A > Priority of Aggregate B

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

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

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

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

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

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

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?