@inproceedings{xorp,
  title = {Designing Extensible IP Router Software},   
  author = {Mark Handley and Eddie Kohler and Atanu Ghosh and Orion Hodson and Pavlin Radoslavov},
  booktitle = {Proceedings of the 2nd USENIX Symposium on Networked Systems Design and Implementation (NSDI '05)},
   address = {Boston, MA, USA},
   month = {May},
  YEAR = {2005},
abstract = {
Many problems with today's Internet routing infrastructure--slow BGP convergence times exacerbated by timer-based route scanners, the difficulty of evaluating new protocols--are not architectural or protocol problems, but software problems. Router software designers have tackled scaling challenges above all, treating extensibility and latency concerns as secondary. At this point in the Internet's evolution, however, further scaling and security issues require tackling latency and extensibility head-on.

We present the design and implementation of XORP, an IP routing software stack with strong emphases on latency, scaling, and extensibility. XORP is event-driven, and aims to respond to routing changes with minimal delay--an increasingly crucial requirement, given rising expectations for Internet reliability and convergence time. The XORP design consists of a composable framework of routing processes, each in turn composed of modular processing stages through which routes flow. Extensibility and latency concerns have influenced XORP throughout, from IPC mechanisms to process arrangements to intra-process software structure, and leading to novel designs. In this paper we discuss XORP's design and implementation, and evaluate the resulting software against our performance and extensibility goals.
},
notes = {
This paper describes
<a href="http://www.xorp.org/">XORP</a>
a project to create Open-Source router software.
<p>
They make some good observations:
<pre>
low-level protocols that support the Internet have largely ossified, and stresses are beginning to show.
</pre>
and
<pre>
The router software market is closed: each vendor's routers will run only that vendor's software. This makes it almost impossible for researchers to experiment in real networks
</pre>
both statements are true. Although in the case of the second
I would argue that researchers <i>can</i> experiment in <i>small</i> networks but they can't experiment in the kind of large networks where the router equivalents of &quot;big iron&quot; dominate. I suspect then that this might be a non-sequitur:
<pre>
We therefore saw the need for a new suite of router software: an integrated open-source software router platform running on commodity hardware...
</pre>
As far as I can see, projects like
<a href="http://www.openbgpd.org/">OpenBGPD</a>
already aim to fill this niche <i>and</i> they don't solve this particular problem because you don't run this software in place of a &quot;big-iron&quot; backbone BGP router.
<p>
When talking about Cisco and Juniper's routers, the paper says
<pre>
Unfortunately, these vendors do not make their APIs accessible to third-party developers, so we have no idea if their internal structure is well suited to extensibility
</pre>
I just find this kind of thing quite depressing. As a researcher, why aim to compete in this kind of area? Why suffer the indignity of having to write stuff like:
<pre>
While we don't know how Cisco implements BGP, we can infer from clues from Cisco's command line interface and manuals that it probably works something like this.
</pre>
<p>
Small groups of researchers cannot and should not (in my opinion) try to compete this closely with industry. Researchers should play to their strengths; focus on more blue-sky stuff that's a little bit far-out with no direct industrial relevance. It seems like research suicide to take on large, well-funded companies at their own game.
},
  bibtexurl = {http://www.recoil.org/~djs/bibtex/xorp.bib},
 pdf = {http://www.xorp.org/papers/xorp-nsdi.pdf}
},

}