Making Inter-domain Routing Power-Aware?
Download as PPTX, PDF1 like166 views
This document discusses making inter-domain routing more power-aware. It proposes extending the GreenTE power-aware routing model to consider inter-domain paths in addition to intra-domain paths. Simulation results show that enabling power-aware egress selection across domains can provide additional power savings, though the improvement over considering just intra-domain paths is modest, at most a 1% increase in average power savings. The potential benefit depends on factors like network topology and delay constraints. Overall, power-aware inter-domain routing seems feasible but provides relatively small further power savings beyond intra-domain optimization alone.
Making Inter-domain Routing Power-Aware?
- 1. Making Inter-domain Routing Power-Aware? Junxiao Shi and Beichuan Zhang The University of Arizona, USA 1
- 2. Background • Network infrastructures exhibit low power efficiency • Today's networks are over-provisioned • Average link utilization is low at most of the time • All routers and their line cards are up and running 24x7 • Low power efficiency becomes an increasing concern for ISPs and data centers 2
- 3. GreenTE: dynamically adjusting routing paths • GreenTE adapts routing paths to traffic demand, so that unused links can go to sleep and save power 3
- 4. GreenTE model • GreenTE is modelled as an optimization problem, and optimized in a centralized controller • MAXIMIZE: Σ power saving of sleeping links • SUBJECT TO • Traffic between each IE pair goes through some path • Path delay is no more than twice of the delay of shortest path • Link utilization is below 50% on every link • Idle links can go to sleep 4
- 5. Path diversity • Power saving via path diversity • GreenTE switches traffic between multiple paths • More path choices => (hopefully) higher power saving • Intra-domain vs inter-domain • Original GreenTE considers intra-domain paths only: for inter-domain traffic, ingress and egress points are chosen by some non-power- aware scheme • Can we increase power saving by considering inter-domain paths? 5
- 6. Power-aware inter-domain routing • Power-aware inter-domain routing enhances path diversity • How much additional power saving can we get? 6 source destination
- 7. Power-aware inter-domain routing • Realistic assumption: no global coordination • Global coordination doesn't exist in Internet • Two tuning knobs • Power-aware egress selection • Power-aware ingress selection 7
- 8. Power-aware egress selection • ISP chooses egress for a flow with BGP route selection process • Introduce a new attribute: highest power saving highest local preference enforce relationships traffic engineering shortest ASPATH lowest MED i-BGP < e-BGP lowest IGP cost to BGP egress lowest router ID break ties highest power saving 8
- 9. Power-aware ingress selection • Ultimately, ingress is chosen by neighbor AS • ISP can influence the choice of ingress point by tweaking BGP announcements • MED • ASPATH prepending • prefix splitting 9
- 10. Difficulty in ingress selection • Ultimately, ingress is chosen by neighbor AS • effect of ingress selection is less predictable • Influences cannot take effect immediately • BGP update rate is limited to avoid triggering route flap damping • As a preliminary step, this paper focuses on power-aware egress selection 10
- 11. Extending GreenTE model to inter-domain • New definition of traffic demand • traffic amount from a set of ingress points to a set of egress points • BGP tells us the possible egress points • New constraint • traffic demand between each ingress set - egress set is split onto IE pairs • Technical challenge: scalability • Multi-Commodity Flow problem is NP-hard • Inter-domain GreenTE has more variables => bigger problem size 11
- 12. One egress set per destination prefix • fine granularity, more computation, higher power saving ISP 192.0.2.0/24 12
- 13. One egress set per destination AS • medium granularity, medium computation, medium power saving ISP 192.0.2.0/24 13
- 14. One egress set per neighbor • coarse granularity, less computation, lower power saving ISP 192.0.2.0/24 14
- 15. Evaluation • Our evaluation is based on simulation • Input • Rocketfuel topologies • AS relationship • synthesis traffic matrix • Realistic assumption: no global coordination • Only one ISP seeks to save energy in each simulated scenario • Comparing power saving potential of intra-domain GreenTE and inter-domain GreenTE 15
- 16. How much power can we save? saving% weighted average minimum median maximum intra-domain 36.00% 0.00% 21.86% 62.99% inter-domain, per neighbor 36.35% 0.00% 21.86% 62.71% inter-domain, per destination AS 36.65% 0.00% 23.40% 63.97% • Power saving potential increases by enabling power-aware egress selection, and becomes higher with finer granularity • Overall the improvement is modest at most 16
- 17. Impact of internal topology • HIGH IMPACT on both intra-domain and inter-domain spanning tree richly connected intra-domain inter-domain 17
- 18. Impact of delay constraint • GreenTE limits the delay of candidate paths to be no more than twice the delay of shortest path • Power saving should not cause too much increase on end-to-end delay • but this also limits path diversity => limits power saving • LOW IMPACT on both intra-domain and inter-domain 18
- 19. Impact of egress set granularity • MEDIUM IMPACT on inter-domain per neighbor AS per destination AS 19
- 20. Impact of BGP policy • MEDIUM IMPACT on inter-domain respect path preference ignore path preference (allow using provider route when there is customer route) 20
- 21. Conclusion • First attempt to answer: is it feasible and beneficial to consider inter-domain paths in power-aware traffic engineering? • Realistic assumption: no global coordination • Power-aware egress selection: integrate "highest power saving" to BGP route selection process • Evaluation: it's feasible to save addition power • Amount of additional power saving seems modest • Utilizing intra-domain path diversity already gives most of power saving • Benefit of power-aware egress selection alone is small • What if we have power-aware ingress selection? 21