A Comparative Study of Extensible Routers Yitzchak Gottlieb and Larry Peterson
Extensibility: Why? n New Services – Packet taggers – Filters – Firewalls – Overlay Networks n Old Routers – Fixed
Extensibility: How? n Software routers – Easy to change n Rewrite code – Hard to extend n Little guidance n Extensible software routers – Easy to extend n Defined architecture
Extensibility: Who? n Scout – Princeton University – SILK (Scout in Linux Kernel) n Click – MIT – Linux Kernel Module n Router Plugins (Crossbow) – Washington U St. L, ETH Zürich, Ascom – BSD Hack
How To Choose? n Choose Scout – Bias? n Choose at random n Compare strengths and weaknesses – Does your application fit its model? – Does it provide access to what you need? – Is it hard to program?
Modeling Extensible Routers n Basis for comparison – Abstracts implementation n Simple – Few components – Comprehensible n Powerful – Models all three systems
Model: The Players n Queues – FIFO n Classifiers – One to many n Schedulers – Many to one n Forwarders – One to one F CS
Comparing Extensible Routers n Extensibility – Classifiers – Schedulers – Forwarders n Process Scheduling n Flow Isolation
Extensibility: Two approaches n Outside the architecture – Extend the fixed pieces – Why use extensible routers n Within the architecture – Insert – Replace – Program n Parameterize n Add Code
Extending Components
Forwarders in Click n Small (Null element: 8 lines) n Multiple
Forwarders in Crossbow n Bigger (Null plugin: 98 lines) n Restricted placement SC F F F F C F F F SF
Forwarders in Scout n Biggest (Null module: 200 lines) n Powerful S FF C
Process scheduling n Scout – Classify to path – Schedule Path n Click – Pull from upstream queue – Push until downstream queue n Crossbow – Process at arrival
Flow Isolation n Scout – Paths are isolated n Click – Queues isolate subgraphs n Crossbow – No isolation
Conclusions n Powerful default classifier – Programmable substructure n Flow isolation – Schedule whole computation n Small components – Good aggregation tools