1 / 31

Practical Solutions for Efficient IP Fast Reroute Management

Learn how to optimize NotVia address usage, reduce overheads, prioritize computations, and improve manageability of protection paths in IP Fast Reroute systems. Find out more in this insightful paper.

marv
Télécharger la présentation

Practical Solutions for Efficient IP Fast Reroute Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On Improving the Efficiency and Manageability of NotVia Ang Li†, Pierre Francois‡, and Xiaowei Yang† †UCIrvine ‡ Université catholique de Louvain CoNext 2007 12/13/07 New York

  2. Outline • Introduction • Background on IP Fast Reroute • Problem statement • Our solutions • Evaluation • Conclusion

  3. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 Routing Convergence Causes Packet Losses Convergence! (sub-second) X

  4. 2095 856 700 SV NY SV NY SV NV 260 233 1295 639 548 587 366 846 902 1893 1176 IP Fast Reroute Reduces Packet Losses X Failure detected! (≈10ms)

  5. Considered IPFRR Techniques • Loop-Free Alternates (LFA) • Lightweight • Problem: no full protection coverage • NotVia address (NotVia) • Used when LFA does not apply • Full coverage • Overhead

  6. 2095 856 700 SV NY 260 233 1295 639 548 587 366 846 902 1893 DV NVDV->KA 1176 IPFRR with NotVia Address NVDV->KA X • Announce the NotVia address • Each router computes a nexthop for the address • When failure happens, encapsulate • packets with the address

  7. Problem Statement • NotVia’s overhead • Memory overhead • Computational overhead • Not management-friendly • Operators do not know the protection paths • Details in the paper

  8. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 Memory Overhead • Extra FIB entries # of extra entries = # of unidirectional links unprotected by LFA

  9. Computational Overhead • Computational overhead • Extra SPT computations • Each router needs to compute one SPT for each NotVia entry • Up to 20ms for one SPT in a Tier-1 ISP • Up to 20s in a topology with 1000+ links • NotVia entries updated to the linecards • It may result in… • Protection restoration time t2 can be long • Resources are consumed when needed by other more urgent processes

  10. Outline • Introduction • Our solutions • Evaluation • Conclusion

  11. Contributions • We make NotVia more practical • NotVia aggregation to reduce memory overhead • Prioritized computation to reduce computational overhead • rNotVia algorithm to obtain protection path information (in the paper) • Simple & local techniques

  12. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 1. NotVia Aggregation Observation: very often, nexthop(NV)= normal nexthop(NV’s originator) NVDV->KA

  13. How can we Reduce Overhead? • NotVia aggregation • Assign the NotVia addresses from the originator’s prefix • Do nothing when the nexthops are the same • Install more specific entries only when nexthops are different • For instance, 10.0.0.0/8 for Kansas City 10.0.0.1 for NVDV->KA • Aggregation saves • FIB memory on linecards • Processing: less entries to be managed by the RIB and FIB processes

  14. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 2. Prioritized NotVia Computation Problem: how can a router first compute the necessary NotVia entries? NVDV->KA

  15. Prioritize NotVia Computations • Compute closer NotVia addresses first • Observation: protection paths are close to the not-via link • Prioritization reduces the time to restore NotVia protection • Because the protection is restored after all necessary NotVia entries are generated

  16. Outline • Introduction • Our solutions • Evaluation • Conclusion

  17. Data sets and Methodology • Topologies • 5 real ISP topologies • Real configured metrics • From small ones to a Tier-1 ISP (with over 400 nodes) • Synthesized topologies from BRITE • Customized simulator • Most results not related with simulator implementation

  18. Effectiveness of Aggregation 140+ nodes, 400+ links

  19. Effectiveness of Prioritization

  20. Outline • Introduction • Our solutions • Evaluation • Conclusion

  21. Conclusion • NotVia provides full coverage, but… • Introduces memory and computational overhead • Not management-friendly • We optimized it with simple techniques • NotVia aggregation • Prioritization • rNotVia • Evaluation on real topologies suggests they are effective

  22. Thank you! • Questions?

  23. rNotVia Efficiency

  24. S D S D IPFRR with Loop-Free Alternate 1 R 5 1 • Two modes of LFA • Destination based: router R is S’ LFA w.r.t. destination D • S can reroute packets destined to D through R when link S→T fails • R will not forward the packets back to S • Link based: router R is S’ LFA w.r.t. link S→T • S can reroute any packet through R when link S→T fails • R will not forward the packets back to S • Similar scheme for node protection • LFA serves as the baseline solution of IPFRR • Easy for a router to find its LFAs • No encapsulation / packet header modification • However, LFAs may not always be available 1 1 S T D

  25. rNotVia’s Applicability • rNotVia might be used to compute NotVia entries • Can further reduce # of NotVia entries! • In reality: rNotVia is heavier than current optimized SPT computation • One rNotVia(rSPT) == one normal SPT • SPT could be significantly optimized by only computing the incremental part (iSPT) • For rNotVia the optimization gain is marginal • rNotVia is only used for management • Running in low priority • When the network is stable • For reporting purposes

  26. How the Distance is Measured? • IGP distance v.s. Hop distance • Hop distance is better • High link cost within PoP • Close in terms of hop count • One SPT to get hop distance • Pre-computed in low priority

  27. 2095 856 700 260 233 1295 639 548 587 366 846 902 1893 1176 How does rNotVia work? XXX: no black color X X X X X

  28. How Long does it take to restore NotVia protection? • Results after a link failure • Restoration time defined as the time when the last • necessary entry is computed

  29. Partial NotVia Aggregation • “I don’t want the NotVia addresses to mess up with my normal addresses!” • Solution: announce a new dedicated prefix – “NotVia prefix” • Assign NotVia addresses from the NotVia prefix • Do nothing when the nexthops are the same • Always install an entry for each NotVia prefix • Assign nexthop(NotVia prefix) to be nexthop(originator) • No extra computation • Partial aggregation saves: • Memory: # of L > # of N • Computation gain is same

  30. 2095 856 700 src dst 260 233 1295 639 548 587 366 846 902 1893 src NVD->K 1176 IPFRR with NotVia address NVD->K X • Announce the NotVia address • Each router computes a nexthop for the address • When failure happens, encapsulate • packets with the address

  31. Effectiveness of Prioritization dot: the round at which a necessary entry is computed Node 38’s 92nd round of computation generates a necessary NotVia entry without prioritization (92, 38) Round Number of NotVia Computation Green – with prioritization Red – without prioritization

More Related