Click Modular Router

1
Click Modular Router
- Priyanka Tembey
CS 8803 High Performance Communication Fall 2006
31st October Guided by Ada Gavrilovska
2
Introduction

• Routers today -
• Are expected to do much more than routing
• Designs are monolithic, closed, static and
  inflexible
• Addition/Deletion of functionality components is
  difficult

• Need for an Application model -
• More flexible and configurable router designs
• More Extensible router designs
• More Clearly defined interfaces between router
  functionalities

3
A solution - Click Modular Router

• Underlying Idea Programmable Routing
• Divide -
• Individual router functionalities like
  Address-lookup, Switching Packets,
  Classification represented as Basic Building
  blocks
• And Conquer -
• Complete Router designed by assembling building
  blocks
• Follows the Bottom-up architecture
• Two new concepts -
• Pull processing
• Flow based Router Context

4
The Architecture
Like a Directed graph with a set of Elements
and Connections

• Elements
• The building blocks Each represents a single
  router function.
• Implemented as a C class
• Router functions decided by choosing from a pool
  of elements

• Input and Output ports
• Every element has multiple input and output
  ports
• Each could have a different semantic meaning

• Configuration strings
• Initialize the per-element state, customizes
  element behavior
• Like constructors in C classes

5
The Architecture..Continued

• Connections
• Edges between two elements that could be
  possible data paths for incoming packets
• Implemented as a virtual function call
• Two types
• Push-type - Upstream element hands over a
  packet to a downstream element (generally seen at
  the packet-arrival element where the data is
  handed over to the next unit of processing)
• Pull-type - Downstream element requests for data
  from the upstream element (generally seen in
  transmit-side elements where the transmit ports
  when ready will request for a packet from the
  previous element)

6
The Architecture..Continued

• Queues
• In Push-side processing, elements need to either
  store packets, discard them or forward them to
  the next element in line.
• Packet storage at element is not implicit
• Packet storage buffers OR Queues also
  implemented as elements so that their
  insertion/deletion becomes more configurable
• Need to be explicitly put at elements (Eg More
  queues at transmit-side where traffic-shaping
  functionality might be needed)
• Data storage inherently possible because a push
  input and a pull output necessitates storage of
  pushed data until it is requested

7
The Architecture..Continued

• Push and Pull processing
• One of the main features provided by Click
  Modular router to solve router control flow
  problems
• Certain router functionalities more suited to
  specific types of processing like
• Receive side processing more suited to push type
  of connections where packets ought to be
  delivered to next element in line for further
  processing
• Packet scheduling decisions, problem of busy
  transmit ports easily solved by making them pull
  inputs
• Differ in the direction of control flow (who
  initiates the data transfer)
• Data transfer direction is the same from
  upstream to downstream element

8
The Architecture..Continued
Certain Invariants for push-pull processing

• Push outputs connected to push inputs
• Pull outputs connected to pull inputs
• Agnostic ports (push or pull) can be used as
  push or pull exclusively
• Properly configured routers have same colored
  inputs and outputs as above

9
The Architecture..Continued
Data transfer in push and pull connections

• Push-connection Always initiates data transfer
• Pull-connection Even if pull-input is ready to
  receive data, a pull-request can return a
  null-value
• Methods of invoking pull-transfer
• Based on a timer
• Packet upstream notifications Upstream elements
  can notify particular downstream elements that
  they are ready to transmit so that downstream
  elements can issue requests

10
The Architecture..Continued
Flow based router context

• Need for Upstream elements to find downstream
  elements interested in packet notifications
• Packet-flow
• The transitive closure of elements reachable from
  an element is termed as the packet-flow.
• Packet flow information for an element with
  respect to the entire router is termed as its
  Flow-based router context
• Algorithms to find Flow based router context
• Can also consider filters
• Knowledge of elements implementing specific
  types of interfaces, queue lengths known to other
  elements due to flow-based router context

11
Implementation
Element is the parent class supporting all
functionalities as virtual functions Other
classes defined as sub-classes of Element
NullElement derived from Element
NullElement constructor for initializations
Push and Pull in NullElement override parent
functions
12
Language

• Simple textual descriptions about declarations
  and connections
• Configuration string passed as is, as a list
  separated by commas to the element
• Earlier defined elements used as primitives to
  define compound elements
• Scope for preprocessing doing pattern matching
• Scope for type-systems in place

Declarations New elements
Elided form of above specification
Connections
13
An example IP router
Local information Elements easy to
compose Annotations Global information Chained
elements
14
Example Router extensions
Scheduling
A single output queue
Multiple queues
Scheduler

• Scheduler as a Multiplexer
• Round-Robin scheduling, Priority based
  scheduling elements have been implemented
• Concept of Virtual Queues Output element does
  not see the difference between a Queue element
  and a scheduler.
• Complex functionality embedded in queues can be
  abstracted

15
Router extensions..Continued
Differentiated Services

• Consist of Classification, tagging, shaping,
  dropping, queuing, and scheduling functions.
• Click routers depending on the IP DSCP
  (Differentiated Services Code Point) classify the
  flows and handle them using different element
  groups.

Rate-limiting elements
Best effort delivery
16
Limitations

• Decomposition of complex functions into small
  elements may not always be possible (Eg An
  element implementing the Spanning tree protocol
  cannot be built using smaller elements as the
  control flows would be too complicated)
• Connections are governed by packet-flow. So
  implementing shared elements like routing tables
  that are not a part of the packet flow is
  difficult.
• Click would require a programming model to map it
  to the underlying hardware.

17
Results on a Linux setup
73000 packets/sec 90 as fast as Linux IP
18
Breakdown of costs
19
Performance summary

• Modular architecture proves to be efficient
• Clicks 73000 packets/sec forwarding rate is 90
  as fast as Linux on the same hardware and is
  faster than some low-end commercial routers.
• Uses only 16 of the CPU cycles required to
  forward packets, the rest being used by
  device-drivers.
• Flexible architecture Adding functionalities to
  Click is simpler and does not hamper performance.

20
Conclusion

• Click Modular Router
• An open extensible configurable router framework
• The example router configuration proves that a
  complex router can be designed using simple
  building blocks
• Modular architecture does not affect performance
  (Click is still 90 as fast as the base Linux
  system)
• Services like scheduling, traffic shaping,
  rate-limiting encapsulated within elements to
  give rise to a component-based architecture
  reducing design time
• Opens new avenues in Programmable Routing

21
References

• The Click modular router
• Robert Morris, Eddie Kohler, John Jannotti, and
  M. Frans Kaashoek
• (MIT Laboratory for Computer Science)
• NP-Click A Programming Model for the Intel
  IXP1200
• Niraj Shah, William Plishker, Kurt Keutzer
• (University of California, Berkeley)

22
NP-Click A Programming model Mapping Click to
IXP 1200
23
What is a programming model?

• Presents an abstraction that exposes only the
  relevant details of the architecture necessary
  for a programmer to efficiently implement
• an application.
• Balances opacity and visibility
• 1. Opacity Abstract the underlying architecture
• This obviates the need for the programmer to
  learn intricate details of architecture just to
  begin programming the device.
• 2. Visibility
• Enable design space exploration of
  implementations by tuning various parameters at
  design time to study their effect on performance

24
Implementation gap between Click IXP
25
Bridging the implementation gap

• NP-Click combines an efficient abstraction of
  the target architecture with features of
  a domain specific language for networking.
• The result is a natural abstraction that enables
  programmers to quickly write efficient code.
• The model is designed to ease three major
  difficulties of programming network processors
• Taking advantage of hardware parallelism,
• Arbitration of shared resources,
• Efficient data layout amongst different memories
  of IXP.

26
The Mapping

• Elements correspond to sequential blocks of
  code.
• Using Declspec to specify where data-items
  belong depending on their scope and size
• Interface to specific hardware units like Hash
  Unit provided to abstract the actual units from
  the programmer
• Communication between elements modeled on push
  and pull semantics, interface provided to read
  and write from memory
• Scheduler to implement different data paths
  (push/pull) within a single thread (For limited
  number of threads)
• Synchronization enabled interfaces to shared
  objects, facilitates arbitration of resources
  (Example of Transmit FIFO either a priority
  scheme or mutex-based synchronisation)