Upload
harry-parks
View
224
Download
0
Tags:
Embed Size (px)
Citation preview
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
Outline
• Introduction• Background on IP Fast Reroute• Problem statement
• Our solutions• Evaluation• Conclusion
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
Routing Convergence Causes Packet Losses
XConvergence!(sub-second)
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
IP Fast Reroute Reduces Packet Losses
XFailure detected!
(≈10ms)
SV NY
SV NY
SV NV
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
IPFRR with NotVia Address
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVDV->KA
X
1. Announce the NotVia address2. Each router computes a nexthop for the address3. When failure happens, encapsulate
packets with the address
DV NVDV->KA
SV NY
Problem Statement
• NotVia’s overhead• Memory overhead• Computational overhead
• Not management-friendly• Operators do not know the protection
paths• Details in the paper
Memory Overhead
• Extra FIB entries
dst nexthop
Kansas C. Denver
New York Denver
… …
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVD->K Los Angeles
… …
# of extra entries = # of unidirectional links unprotected by LFA
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
Outline
• Introduction• Our solutions• Evaluation• Conclusion
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
1. NotVia Aggregation
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVDV->KAObservation:
very often, nexthop(NV)=normal nexthop(NV’s originator)
How can we Reduce Overhead?
• NotVia aggregation1. Assign the NotVia addresses from the originator’s prefix2. Do nothing when the nexthops are the same3. 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
2. Prioritized NotVia Computation
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVDV->KAProblem: how can a routerfirst compute the
necessary NotVia entries?
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
Outline
• Introduction• Our solutions• Evaluation• Conclusion
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
Effectiveness of Aggregation
140+ nodes, 400+ links
Effectiveness of Prioritization
Outline
• Introduction• Our solutions• Evaluation• Conclusion
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
Thank you!
Questions?
rNotVia Efficiency
IPFRR with Loop-Free Alternate
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
S T D
R1
5
1 1
1
S DS D
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
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
How does rNotVia work?
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
X
X
X XX
XXX: no black color
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
Partial NotVia Aggregation
• ““I don’t want the NotVia addresses to mess up I don’t want the NotVia addresses to mess up with my normal addresses!”with my normal addresses!”
• Solution: announce a new dedicated prefix – “NotVia prefix”1. Assign NotVia addresses from the NotVia prefix2. Do nothing when the nexthops are the same3. Always install an entry for each NotVia prefix4. Assign nexthop(NotVia prefix) to be nexthop(originator)
No extra computation
• Partial aggregation saves:• Memory: # of L > # of N• Computation gain is same
IPFRR with NotVia address
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVD->K
1. Announce the NotVia address2. Each router computes a nexthop for the address3. When failure happens, encapsulate
packets with the address
src NVD->K src dst X
Effectiveness of Prioritization
Node 38’s 92nd round of computation generates a necessary NotVia entry withoutprioritization
(92, 38)
Green – with prioritization Red – without prioritization
Round Number of NotVia Computation
dot: the round at which a necessary entry is computed