on the aggregatability of router forwarding tables

1

On the Aggregatability of Router Forwarding Tables

Author: Xin Zhao, Yaoqing Liu, Lan Wang and Beichuan ZhangPublisher: IEEE INFOCOM 2010Presenter: Li-Hsien, HsuData: 9/28/2011

I. Introduction

Two types of tables used by routers:

RIB(Routing Information Base) for routing

FIB(Forwarding Information Base) for forwarding

FIB is derived from RIB. FIB usually uses high performance memory, which is more expensive and more difficult to scale. Therefore, their size is a more immediate concern to ISPs and vendors.

2

I. Introduction

3

Routing Scalability Problem RIB growth => FIB growth FIB growth: A high priority concern

(From: bgp.potaroo.net)

FIB Aggregation(FA)

What is FA?Within one router, combines multiple RIB entries with the same next hop into one.

FA pros and cons−Purely local no change to routing protocol−No impact on packet forwarding−Compatible with other proposed routing scalability solution(IPv6)−But extra CPU processing time

4

Forwarding Correctness

Strong forwarding correctness− Longest match before/after aggregation ends up with

the same for all prefixes

Weak forwarding correctness− Prefixes with Non-NULL nexthops, the same − Prefixes with NULL nexthops, might routable after

aggregation− extra routable space

5

FIB Aggregation Techniques & Algorithm

Filled nodes are extra routable space introduced by the aggregation.

4A, 4B.

6

Updates Handling

Full aggregation per update is costly Significant computation overhead

Three approaches to handle routing changes to keep computation overhead low: Operators choose an appropriate level of aggregation. Incrementally update the aggregated FIB

Minimize computation, not the table size Re-run full FIB aggregation periodically

The trigger can be a timer, a threshold on FIB size, and/or current router CPU load

7

Evaluation

Data Source− BGP routing tables and updates from RouteView

Project Evaluation Platform and implementation

− Commodity PC, single thread process− Algorithms implemented in C without optimization

8

Table Size after FA

9

RouteViews Oregon tables on 2008.12.31 Each level reduces FIB size more. Level-1 30%~50%, Level-4 60%~90%

Table Size Over Time

Median of table size ratio, 2001~2008 An overall slightly decreasing trend(, suggesting that the FIB

has become more amenable to aggregation over the years.)

10

What does the ratio mean?

If Level-4 applied, router deployed in 2000 can still be used today 11

2000.06

2006.10

Computation Time

Computing time only takes tens to several hundreds milliseconds

12

Updates Process

Among all the updates, 2,914,020 of them cause changes to unaggregated FIB.

13

A BA/BC B/CD D/7,254,478

Periodical Re-Aggregation

With threshold 150,000, on average the FIB needs to be re-aggregated every 5 days

14

Conclusion

The table size can be reduced by 30-70%, which translates to 2-8 years extra router lifetime

The computation overhead is small and can be controlled by incremental update handling plus periodic re-aggregation.

15

Reference

www.cs.arizona.edu/~zhaox/slides/FIB-Aggregation-INFOCOM2010.ppt

16