On the Aggregatability of
Router Forwarding Tables
Author :
Xin Zhao, Yaoqing Liu, Lan Wang and Beichuan Zhang
Publisher:
IEEE INFOCOM 2010
Presenter:
Li-Hsien, Hsu
Data:
9/28/2011
1

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



Routing Scalability Problem
RIB growth => FIB growth
FIB growth: A high priority concern
(From: bgp.potaroo.net)
3

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



RouteViews Oregon tables on 2008.12.31
Each level reduces FIB size more.
Level-1 30%~50%, Level-4 60%~90%
9

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?
2006.10
2000.06
 If Level-4 applied, router deployed in 2000 can still be used today
11

Computation Time
 Computing time only takes tens to several hundreds milliseconds
12

Updates Process
D D/7,254,478 C A A/B B B/C
 Among all the updates, 2,914,020 of them cause changes to unaggregated FIB.
13

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