The Click modular router
Problem
Routers have increasing number of functionalities other than routing packets (e.g. prioritize traffic, translate network address, tunnel or filter packets, act as firewalls, etc.). Most routers have closed, static, and inflexible design: network administrators can neither easily specify or even identify the interactions of different functions, nor can they easily implement new functions in the routers.
Main Insight
The main idea of Click is to build a flexible, modular software architecture for building routers in a form of a graph. The graph contains elements, which are the packet processing modules; and packets move between elements along the graph's edges, which are connections that represent possible paths for packet transfer. Users can write new elements or compose existing elements in a new way to express router functionality.
Key Strength
The paper provides a good router abstraction that is flexible, easy to manage, and easy to extend. The modularity potentially accelerates innovations.
Graph-based abstraction on router functionalities makes it easier to reason router behaviors by checking whether the program matches constraints on the elements or connections.
Performance of Click is good despite the modularity. It is also easily deployable (implement this architecture on general- purpose hardware, which is cheap and has good performance, as an extension to Linux)
Example of what the router program looks like using this abstraction for some basic functionality is illustrated. Like that.
Key Weakness
Click user generally prefer small elements as they can be rearranged to create arbitrary configurations; but small elements are not appropriate for all problems (e.g. when control or data flow doesn't match the flow of packets)
Difficult to implement shared objects that don't participate in packet forwarding, like routing table.
How to schedule CPU time among competing push and pull paths are not clear.
How does it scale with number of servers?
Comments
Last updated