RSVP Bandwidth Reduction in TSVWG

1. RSVP Bandwidth Reduction in TSVWG draft-polk-tsvwg-rsvp-bw-reduction-00 James M. Polk Subha Dhesikan November 10th, 2004

2. Why is this important? • RSVP sets up reservations based on many properties • one of these is the bandwidth required for an RSVP flow (newsflash!) • RFC 2205 defines the means of creating the “flows” • RFC 3181 defines the means of prioritizing the “flows” • RFC 3175 defines the means to aggregate individual flows into a ‘super-flow’ • RFC 2207 defines the means of tunneling flows in IPsec with RSVP • Here’s the rub, when something needs some BW from an existing flow, the whole reservation is currently gets torn down • possibly to be left to attempt reestablishment at “some” lower BW amount • This document specifies how to signal for a reduction in BW of an existing reservation of any type

3. What changed from the previous version? • Changed the filename and scope of doc • Broadened applicability to include individual flows and encrypted RSVP flows • For Aggregates, defined the Deaggregator as the controller of which individual flows are individually reduced or cleared • Cleared open issue regarding ResvTear message generation • It is not to be sent by ResvErr generating router • An otherwise normal 2205 behavior

4. Open issues • Do we need to address the case in which the ResvErr message is sent, but the flow is not reduced in a timely manner? • this is a general RSVP issue and not introduced because of this doc

5. Plans for Effort • Ready to become a TSVWG item? • chairs?? • Wait and address any new comments

6. Aggregate Example

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

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

9. 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 • For individual flows, the downstream endpoint is the controller of the flow • For RSVP enabled IPsec tunnels, the tunnel generator is the controller

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

11. 6th flow signaled into Aggregate A Solution: Router 9 sends a Bandwidth Reduction message to Router 8 to clear an amount of bandwidth Reduction Scenario using Aggregates IV Router 1 Router 2 Router 3 Router 4 5 flows 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

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