A fast switched backplane for a gigabit switched router

This is a white paper arguing for why a switched backplane is needed in high-performance routers (instead of a shared bus backplane), and describe and explains some of the design choices for its architecture and scheduling algorithms. Because its a white paper, it eschews much technical details and includes easy-to-understand explanations and analogy. For that reason, I really enjoyed reading this paper, given my limited (actually zero) exposure to router hardware. I also wished I read this paper before the other ("Scaling internet routers...") because it would have made that reading experience so much less painful; in particular, this white paper actually does a good job of explaining what backplanes, switching crossbar, linecards etc. are. I would recommend that their order be switched in the future. (I also should have saw the words "white paper" on this paper and picked it to read first).

Anyway, the author makes the argument that a shared backplane based on a common bus is the main bottleneck to increasing router capacity rather than the processing for packet forwarding. Thus, a switched backplane based on a centrally controlled crossbar switch is more suitable since each input-output link can be operated at a much higher speed, and allows multiple input-output links to be operated simultaneously ("internally non-blocking"). This increases overall aggregate bandwidth.

Next, the author goes into several design choices for a switched backplane. First, a fixed packet length allows for simplicity in the overall design and high-performance. Second, virtual output queues (VOQs) are used in the input ports to avoid the problem of head-of-line (HOL) blocking, since the scheduler is able to more efficiently configure the crossbar if it knows which outputs would be useful to which inputs. Third, a simple (thus fast) crossbar scheduling algorithm known as iSLIP is used to configure the crossbar switch with the VOQ construct. It is a iterative algorithm that assigns outputs to inputs based on output requests by the input ports, and serves both inputs and outputs in a round-robin fashion. Finally, to control delay, the author suggests speedup of the switching fabric (more than the external line rate).

It was also personally satisfying to see the mention of multicast in the white paper; I was thinking that since a crossbar switch is used, it should be easy to connect a single input to multiple output such as in multicast. And the author does go over the support of multicast in such a router, together with a discussion on a modified iSLIP for scheduling, based on the observation that the switch need not service the multiple outputs simultaneously to avoid blocking.

This paper actually does lay a lot of the groundwork for the other paper. For example, the question of whether re-configuration of the crossbar can scale with increasing line-rate arises naturally and with increasing number of ports. Now maybe I should go back and re-read the other paper...