hitesh ballani paul francis, tuan cao and jia wang cornell ...€¦ · motivation: rapid routing...

ViAggre: Making Routers Last Longer!

Hitesh Ballani

Paul Francis, Tuan Cao and Jia WangCornell University and AT&T Labs – Research

HotNets 2008

Motivation: Rapid Routing Table Growth

0

50000

100000

150000

200000

250000

300000

0806040200989694929088

Act

ive

BG

P e

ntrie

s (F

IB S

ize)

Year

282,000 prefixes (Sep’08)

0

50000

100000

150000

200000

250000

300000

0806040200989694929088

Act

ive

BG

P e

ntrie

s (F

IB S

ize)

Year

282,000 prefixes (Sep’08)

Motivation: Rapid Routing Table Growth

0

100000

200000

300000

400000

500000

140806040200989694929088

Act

ive

BG

P e

ntrie

s (F

IB S

ize)

Year

0

100000

200000

300000

400000

500000

140806040200989694929088

Act

ive

BG

P e

ntrie

s (F

IB S

ize)

Year

??Rapid future growth

I IPv4 exhaustionI IPv6 deployment

Typical Router Innards

Route Processor

CPU RIB

Line Card

ASIC FIB

Line Card

Line Card

Line Card


Route Processor

CPU RIB

Line Card

ASIC FIB

Line Card

Line Card

Line Card

Routing Information Base

(DRAM $)


Route Processor

CPU RIB

Line Card

ASIC FIB

Line Card

Line Card

Line Card

Forwarding Information Base

(SRAM $$$)

Does (FIB) Size Matter?

Technical concerns

I More Memory

I More ProcessingI Power and Heat dissipation problems


Technical concerns

I More Memory


Business concerns

I Less cost-effective networksI Price per byte forwarded increases

I Router memory upgrades


Technical concerns

I More Memory


Business concerns

I Less cost-effective networksI Price per byte forwarded increases

I Router memory upgrades

ISPs are willing to undergo some pain to reduce FIBsize

Routing Scalability Problem Space

[Deering, ’96]

[O’Dell, ID’97]

[Zhang et. al., ICNP’06]

[Farinacci, ID’07]

[Massey et. al., ID’07]

[Jen et. al., HotNets’08]

[Francis, CNIS’94]

[Deering et. al., ID’00]

[Hain, ID’02]

[Krioukov et. al., Arxiv’05]

FIB growthRIB growth

Routing Convergence,Update Churn, ....


[Deering, ’96]

[O’Dell, ID’97]







[Hain, ID’02]


Separate edge from the core




[Deering, ’96]

[O’Dell, ID’97]







[Hain, ID’02]


Geographical routing




[Deering, ’96]

[O’Dell, ID’97]







[Hain, ID’02]


Compact routing




[Deering, ’96]

[O’Dell, ID’97]







[Hain, ID’02]


All require architectural changeSo many ideas, so little impact!




[Deering, ’96]

[O’Dell, ID’97]







[Hain, ID’02]


Tackle routing scalability through a series ofincremental, individually cost-effective upgrades




[Deering, ’96]

[O’Dell, ID’97]







[Hain, ID’02]


This Paper: Focuses on reducing FIB size



Virtual Aggregation, aka ViAggre

A “configuration-only” approach to shrinking routerFIBs

I Applies to legacy routersI Can be adopted independently by any ISP

Key Insight: Divide the routing burden

A router only needs to keep routes for a fraction ofthe address space

Talk Outline

I Introduction[]y

I ViAggre: Basic Idea[]y

I ViAggre Design[]y

I Evaluation[]y

I Deployment[]y

I Conclusions

ViAggre: Basic Idea

PoP A PoP C

PoP B

ISP

IPv4AddressSpace

0.0.0.0

255.255.255.255

External Router External Router

Today: All routers have routes to all destinations

ViAggre: Basic Idea

PoP A PoP C

PoP B

ISP

0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2

VirtualPrefixes

Divide address space into Virtual Prefixes (VPs)

ViAggre: Basic Idea0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2

VirtualPrefixes

Aggregation Pointsfor Green VP

Assign Virtual Prefixes to the routersRouters only have routes to a fraction of the address

space

ViAggre: Basic Idea0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2

VirtualPrefixes

Aggregation Pointsfor Green VP

How to achieve such division of the routing table?Without changes to routers and routing protocols

Without cooperation from external networks

Talk Outline

I Introduction[]y


I ViAggre Design[]y

I Evaluation[]y

I Deployment[]y

I Conclusions

ViAggre Control-Plane0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 Full Routing Table

eBGP Peers may advertise full routing table

ViAggre Control-Plane0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 Full Routing Table

Load full routing table into RIB

Supress all but blue routes from FIB

FIB SuppressionBlue routers only load blue routes into their FIB

Data-Plane paths0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 Virtual Prefix

Packets destined to a prefix in Red

Consider packets destined to a prefix in the red VP

Data-Plane paths0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

12

ViAggre pathIngress (I) → Aggregation Pt (A) → Egress (E)

Ingress → Aggregation Point0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

1

Router I doesn’t have a route for destination prefix


255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

1

Advertise Red VP

Aggregation Points advertise corresponding VirtualPrefixes


255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

1

Advertise Red VP

Prefix Next-HopP1P2

........

0/2 A128/2192/2 ....

....

Blue router has a route for the red Virtual Prefix

Aggregation Point → Egress0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2 2

Prefix Next-HopP3P4

X....

64/2 ....

128/2 192/2 ....

....

Aggregation Pt. A tunnels packet to external router

Aggregation Point → Egress0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

1

Strip tunnel headerfrom outgoing pkts

Egress Router strips the tunnel header off outgoingpackets

Failure of Aggregation Point0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

1

What if Aggregation Pt. A fails?


255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

Prefix Next-HopP1P2

........

0/2 A2128/2192/2 ....

....

Router I installs the route advertised by A2


255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

Prefix Next-HopP1P2

........

0/2 A2128/2192/2 ....

....

Packets are re-routed appropriately

ViAggre’s impact on ISP’s traffic0.0.0.0

255.255.255.255


0/2

64/2

128/2

192/2 I

A

E X

A2

1

ViAggre paths can be longer than native pathsTraffic stretch, increased router and link load, etc.

Popular Prefixes

Traffic volume follows power-law distribution

I 95% of the traffic goes to 5% of prefixesI Has held up for years

Install “Popular Prefixes” in routers

I Stable over weeksI Mitigates ViAggre’s impact on the ISP’s traffic

Talk Outline

I Introduction[]y


I ViAggre Design[]y

I Evaluation[]y

I Deployment[]y

I Conclusions

Stretch Vs FIB Size

Assigning more routers to aggregate a virtual prefix

I Reduces Stretch imposed on TrafficI Increases FIB size

Aggregation Point Assignment Problem

I Minimize Worst FIB size, subject to constrainton Worst stretch

I NP-complete problemI Implemented a greedy approximation

Performance Study

Data from tier-1 ISP

I Topology, Routing tables, Traffic matrix

Used out algorithm with varying stretch constraints

Constraining Worst Stretch

0

5

10

15

20

25

30

0 2 4 6 8 10 0

1

2

3

4

5

6

7F

IB S

ize

(%

of D

FZ

rou

ting

tabl

e)

Str

etch

(m

sec)

Worst-case Stretch Constraint (msec)

Worst-case FIB Size

0

5

10

15

20

25

30

0 2 4 6 8 10 0

1

2

3

4

5

6

7F

IB S

ize

(%

of D

FZ

rou

ting

tabl

e)

Str

etch

(m

sec)


Worst-case FIB Size

FIB Size reduces as Stretch constraint is relaxedWorst-case Stretch ≤ 4ms ⇒ Worst FIB = 10,226 prefixes

(4% of global routing table)

Constraining Worst Stretch

0

5

10

15

20

25

30

0 2 4 6 8 10 0

1

2

3

4

5

6

7F

IB S

ize

(%

of D

FZ

rou

ting

tabl

e)

Str

etch

(m

sec)


Worst-case FIB SizeWorst Stretch

Average Stretch

0

5

10

15

20

25

30

0 2 4 6 8 10 0

1

2

3

4

5

6

7F

IB S

ize

(%

of D

FZ

rou

ting

tabl

e)

Str

etch

(m

sec)


Worst-case FIB SizeWorst Stretch

Average Stretch

Average Stretch is negligibleWorst-case Stretch ≤ 4ms ⇒ Average Stretch = 0.2msec

Router Load

Deployment with Worst-case Stretch ≤ 4msec

I Shrinks FIB by more than 20xI Median router load increases by 31.3%

Using popular prefixes

I 5% popular prefixes carry 96.7% of trafficI Median and Worst-case router load increase ≈

1%

Talk Outline

I Introduction[]y


I ViAggre Design[]y

I Evaluation[]y

I Deployment[]y

I Conclusions[]y

ViAggre Pros

I Shrinks router FIB substantially

I Can be incrementally deployed

I Can be deployed on a limited-scale

I Incentive for deploymentI No change to ISP’s routing setup

I Does not affect convergence timesI Does not affect routes advertised to

neighborsI Does not restrict routing policiesI

. . .

Can it be deployed?

Configuration overhead of a configuration-onlysolution

I Configuring FIB suppression on routersI Configuring LSP advertisements on edge routers

Planning Overhead

I Choosing virtual prefixes

I Assigning aggregation points

I Assuring network robustnessI

. . .

ViAggre management overhead

Deployed ViAggre on WAIL

I Cisco 7300 routersI Developed Configuration Tool

I ∼330 line python scriptI Extracts information from existing configuration filesI Generates ViAggre configuration files

I Planning tool in the works

Working with a router vendor (Huawei)

I Implement ViAggre nativelyI IETF Draft

Conclusion

ViAggre shrinks the FIB on routers

I Can extend the lifetime of installed routers

Is this a “complete” solution? No

I A simple and effective first stepI Next Step: Inter-domain ViAggre

Thank You!

IntroductionDesignEvaluationDeployment

hitesh ballani paul francis, tuan cao and jia wang cornell ...€¦ · motivation: rapid routing...

Documents