Building an Internet Router
Principal lecturer: Dr Andrew Moore
Taken by: MPhil ACS
Congratulations to Team 3: Omar Choudary and Alexander Katovsky on
winning the Overall and Judges Prize
- Fantastic effort guys!
- Strazisar, V. (1979), How to build a gateway,
- Postel, J. (ed) (1981), Internet Protocol,
- Baker, F. (ed) (1995), Requirements for IP Version 4 Routers,
- Comer D. (2006) Internetworking with TCP-IP, Vol 1.
While the lastest edition fixes a number of earlier mistakes and
contains a number of revised chapters; earlier editions of this book are
also excellent preparatory material if that is all you have
Further Preparatory Reading
- Peterson, L.L. & Davie, B.S. (2007). Computer networks: a systems
approach. Morgan Kaufmann (4th ed.).
- Comer, D. & Stevens, D. Internetworking with TCP-IP, vol. 2. Prentice
- Varghese, G Network Algorithmics. Morgan Kaufmann
If you are worried your ECAD skills are weak, use this pre-requisite
tutor; designed for the 2nd year course here in Cambridge, but very
learning using the on-line Intelligent Verilog Compiler
Also useful, the Verilog cheat sheet
Build an Internet Router (P33) is a project-based class. The first
lecture (of which attendance
is required) is the only scheduled lecture. During the module teams of
two or three students will work together to develop a fully functional
IP router. The teams will consist of at least one student familiar with
designing hardware in Verilog and one student who is comfortable working
in large, system level network programs in C. Students will be paired by
area on the first day of class. You do not need a partner before
The hardware uses the NetFPGA boards which provide a programmable
hardware platform for developing network equipment. Given the Verilog
HDL code for a simple two port switch the hardware designer will
extend/modify/discard this code to provide the functionality of a
four-port IP router. A set of tools are provided to assist the student
with design, verification and synthesis.
The software developer will create the code needed to control and
manage the router. For control purposes, the software must participate
in a dynamic routing protocol and respond to ARP and ICMP messages. For
management purposes the software must export a telnet-like command-line
interface such that a user can telnet to the software process and manage
the actual hardware. The Stanford VNS (Virtual Network System) is used to allow
the student's software to run from any suitable Cambridge computer and yet
communicate with the hardware directly.
This is a practical course involving the development and maintenance
of a large code base. The course minimum requirements are:
- Students who are familiar with Verilog (or VHDL) and are comfortable
with the general process of designing RTL-based logic and the
verification process associated with that. The student must understand
the difference between behavioral Verilog and RTL Verilog (a subset
which can be synthesized into logic). The hardware course minimum
- Students who are competent software programmers, who have had
significant exposure to system level programming in C. The students
must be comfortable developing and debugging in a multithreaded
environment, and should have experience working within a code-base of
over 5,000 lines. The software course minimum is C/C++
- All students should understand IP-level networking. Equivalent
course requirment is Digital Communications I and II
The class will be broken down into teams of two or three students.
Each team must have at least one member knowledgeable of the hardware
aspect and one member with ample software expertice. We leave it up to
the teams themselves to decide how to break up the workload between all
members. At the end of the term, however, we do require that each
team submit one document detailed the work done by each member. This
document will weigh heavily when allocating points for team
At the end of this module each group will give a 20 minute
presentation on the design and implementation for their router. We are
particularly interested in the novel aspects of your design, comments on
how you worked together and with other teams, and what went wrong and
what went right, as well as any general feedback for us on the project,
flow, tools, difficulty, etc.
Weekly Meetings and Office Hours
In order to keep track of your progress we are scheduling 10 minute,
weekly meetings with each group to go over project status, issues etc.
The exact times for these meetings will be announced after the groups
have been decided.
In addition to weekly meetings and the class mailing list the TAs will
hold office hours during the regular class period in SW02.
Class Router Interoperation
Routers by nature work cooperatively in large complex environments.
In fact, much of the complexity in router design and implementation is
inter-operating with routers developed by different teams based on
varying assumptions of standard protocol specifications.
Inter-operation is such a critical feature of network infrastructure
development that it is one of the major focuses of this course. The
last few weeks of the course are reserved for inter-operation and
testing between all of the teams in the class. The students are
responsible for initiating communication between groups, coming up with
a cooperative integration plan and ensuring that your routers not only
inter-operate with our supplied reference solutions, but all other
routers in the class. It is our goal that by the end of the class,
every finished router will be able to route traffic cooperatively on a
large shared topology.
We have reserved a portion of the total class points to allocate
based on participation during inter-operation. This means that we
expect all the students to be pro-active from the start about planning
and communicating a solid inter-operation strategy between teams during
development. It is a good idea to collectively map out a strategy early
on in the term and have incremental goals that can tested piece-wise.
You may meet during designated course hours (since no lectures are
held), use the class newsgroup for communication, email or meet during
class hours. We would like you to include the TAs in your
communications (implicit if using the newsgroup) so that we can track
Design documentation is our window into the brilliance of your
particular design and implementation. Through the course, each team
will maintain two design documents, one for the hardware portion and the
other for the software portion. Generally, when reading your design
documents, we should be able to clearly understand your approach to the
problem, the high level design and be convinced that you considered
multiple options, choose the best one and are aware of the trade-offs.
Both design documents should have the following high level
- Software/Hardware Design
- Overarching design of the hardware or software (depending on the
which design document). We expect sufficient detail to understand how
your design fits together at a component level without a deluge of
- Project Specific Documentation
- For each project stage outlined in the class hardware schedule you
will write a section of the design document detailing your design and
implementation choices. Specific requirements for each section are
listed in the section write-up. You will hand in these sections at the
completion of each milestone.
- Testing Strategy
- You are responsible for coming up with a complete, integrated
testing strategy which you will use to verify correctness throughout the
development process. Remember that you are responsible for
inter-operating with other routers so you must take this into account.
You may choose to divide this section into four subsections, software
testing, hardware testing, integrated unit testing and inter-operability
- Integrated Design
- A full and comprehensive overview of your design. Be sure to
describe in detail why you chose to design your router this way, the
trade-offs involved and any problems with your design you hadn’t
anticipated. You should take an integrated hardware/software approach
to explaining your design. We are interested in knowing what is in
hardware, what is in software, how they interact and what the interfaces
between the two look like. You may choose to write this section last
though much of the material can be taken from the portions of the
document you will write during the design and implementation stages.
This section may be the same in both documents.
- Post Mortem and Lessons Learned
- A summary of the your design and implementation experience. What
went wrong? What went right? What would you do differently? Contrast
your view of the project in retrospect to how it looked at first. In
this section, we are primarily interested in what your learned during
This module is substantially based-upon the Stanford University
"Build an Internet Router" (the link is broken while the Stanford end is undergoing a revamp).
to Nick McKeown for making this possible. Further thanks to John
Lockwood, Glen Gibb,
David Underhill, David Erickson, and Adam Covington, along with thanks
to Jeffrey Shafer at Rice University.
Thank you supporters, you have enabled this subject