Computer Laboratory

Building an Internet Router

Building an Internet Router
2010–11

Principal lecturer: Dr Andrew Moore
Taken by: MPhil ACS
Syllabus

About

News

Web pages still being updated for 2010 - 5th Oct 2010.

The exact list for this subject is still being drawn up - if your interested come along and talk with the Convener Tuesday 12th of October at 14:00

Preparatory Reading

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 Hall
  • Varghese, G Network Algorithmics. Morgan Kaufmann

Support material

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 helpful:

Prerequisite learning using the on-line Intelligent Verilog Compiler

Also useful, the Verilog cheat sheet

Overview

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 registering.

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.

Prerequisites

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 is ECAD/ECAD-Practical.
  • 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

Teams

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 participation.

Presentation

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 your progress.

Documentation Deliverables

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 structure.

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 specifics.
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 testing.
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 the project.

Credit

This module is substantially based-upon the Stanford University course cs344 "Build an Internet Router" (the link is broken while the Stanford end is undergoing a revamp). Particular thanks 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.

Supporters

Thank you supporters, you have enabled this subject