Outline updates to draft simplified functional specification

1. Max Allocation with Reservation (MAR)BW Constraint Model for MPLS/DiffServ TE & Performance Comparisons(draft-ietf-tewg-diff-te-mar-01.txt) • Outline • updates to draft • simplified functional specification • setting bandwidth constraints in MAR & MAM • new simulation analysis results • conclusions & next steps Jerry Ash gash@att.com

2. MAR Bandwidth Constraint Model • supports greater efficiency in bandwidth sharing • provides protection of allocated bandwidth under congestion • allows bandwidth sharing in absence of congestion • by bandwidth reservation methods, robust to traffic variations • for CTs below their bandwidth constraint BCc • can seize any idle bandwidth on a link • for CTs above their bandwidth constraint BCc • can seize bandwidth if idle bandwidth > bandwidth-reservation threshold • meets all requirements for BC models • works well with or without preemption • mechanisms in use for 10+ years • for multiservice voice/data bandwidth allocation in large-scale networks

3. Updates to Current Draft (draft-ietf-tewg-diff-te-mar-01.txt) • changes in notation to align with DSTE notation: • RESERVED_BW, UNRESERVED_BW, MAX_RESERVABLE_BW, bandwidth constraint (BCc), etc. • NORMALIZED(CTc) deleted • added Section 3 'assumptions & applicability', as agreed in IETF-56/TEWG meeting • clarified/simplified functional specification in Section 4 • added Section 5 ‘setting bandwidth constraints’ • explain how BCc set for MAR • added ANNEX A • moved descriptive material on MAR operation & analysis • added new simulation results, compare MAR, MAM, & No-DSTE: • simulation for focus overload & 50% general overload • simulations for single link failure and multiple link failure • simulations adjusting the MAM bandwidth allocations & observations/sensitivities in setting MAM bandwidth constraints

4. Functional Specification of MAR • for bandwidth request = DBW on CTc on link k: • for LSP on high priority or normal priority CTc: • if RESERVED_BWck <= BCc: admit if DBW <= UNRESERVED_BWk • if RESERVED_BWck > BCc: admit if DBW <= UNRESERVED_BWk - RBW_THRESk • for LSP on best-effort priority CTc: • allocated bandwidth BCc = 0 • DiffServ queuing admits BE packets only if available link bandwidth • normal semantics of setup & holding priority apply • cross-CT preemption is permitted when preemption enabled

5. Setting Bandwidth Constraints • normal priority CTc bandwidth constraints BCck on link k: • set in proportion to forecast/measured traffic load bandwidth TRAF_LOAD_BWck • PROPORTIONAL_BWck = TRAF_LOAD_BWck/[sum {TRAF_LOAD_BWck, c=0,MaxCT-1}] X MAX_RESERVABLE_BWk • BCck = PROPORTIONAL_BWck • high priority CTc bandwidth constraint BCck • set to multiple of proportional bandwidth • BCck = FACTOR X PROPORTIONAL_BWck (FACTOR = 2 or 3 is typical) • gives priority with some 'over-allocation' of maximum reservable bandwidth • bandwidth allocated to high priority CTs should be small fraction of total link bandwidth, maximum of 10-15% a reasonable guideline • best-effort priority CTc bandwidth constraint BCck = 0

6. Analysis of MAR, MAM, & No-DSTE • options compared • MAR • LSPs set up with bandwidth reservation • normal priority CTs: BCck = PROPORTIONAL_BWk • high priority CTs: BCck = FACTOR X PROPORTIONAL_BWk • best-effort priority CTs: BCck = 0 • MAM • normal priority CTs: BCck = FACTOR1 X PROPORTIONAL_BWk • high priority CTs: BCck = FACTOR2 X PROPORTIONAL_BWk • best-effort priority CTs: BCck = 0 • each CT restricted to allocated bandwidth constraint BCck, as in normal operation of MAM • No-DSTE • LSPs set up without bandwidth reservation • bandwidth allocation requests admitted if bandwidth available • no queueing priority applied to any CT

7. Analysis of MAR, MAM, & No-DSTE • full-scale 135-switch national network simulation model • 5 CTs • normal priority voice • high priority voice • normal priority data • high priority data • best-effort data • simulation comparisons for • 6X focused overload on Oakbrook • 50% general overload • single link failure (3 OC-48s) • multiple link failure (3 links with 3 OC-48, 3 OC-3, 4 OC-3, respectively) • MAM performance with different over-allocation factors

8. Performance Comparison forMAR, MAM, & No-DSTEBandwidth Constraint Models6X Focused Overload on Oakbrook(Total Network % Lost/Delayed Traffic)

9. Performance Comparison forMAR, MAM, & No-DSTEBandwidth Constraint Models50% General Overload(Total Network % Lost/Delayed Traffic)

10. Performance Comparison forMAR, MAM, & No-DSTEBandwidth Constraint ModelsSingle Link Failure (3 OC-48)(Total Network % Lost/Delayed Traffic)

11. Performance Comparison forMAR, MAM, & No-DSTEBandwidth Constraint ModelsMultiple Link Failure(3 Links with 3 OC-48, 3 OC-3, 4 OC-3, Respectively)(Total Network % Lost/Delayed Traffic)

12. Performance Comparison forMAM Bandwidth Constraint ModelDifferent Over-allocation Factors 6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic)

13. Conclusions & Next Steps • MAR bandwidth constraint model • supports greater efficiency in bandwidth sharing • provides protection of allocated bandwidth under congestion • allows bandwidth sharing in absence of congestion • by bandwidth reservation methods, robust to traffic variations • meets all requirements for BC models • works well with or without preemption • proposed next steps • last call on MAR