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