Building an Internet Router
You currently have a four-port non-learning switch. The goal of this part is to overhaul the Output Port Lookup module to implement an IP router as per RFC 1812. You will be doing this in a number of steps over the next several weeks.
As an IP router, your system (hardware plus software) must do the following:
Required functionality in more detail
The hardware comonent of the router must:
Do not use the CAM device provided by the Xilinx Coregen tool to implement any of the tables. You must implement your own lookup mechanism
The objective is for the hardware to process all regular IP packets without requiring intervention from the software. Packets should only be forwarded to the software in the following instances:
Note: You should follow the register map provided by this XML file. To use this file, copy the file into the project’s include directory: projects/<project>/include You need to add the reference_op_lut to the project.xml file in the UDP section. Add the line in bold below:
... <nf:group name="udp"> <nf:instance name="in_arb" /> <nf:instance name="router_op_lut" /> <nf:instance name="strip_headers" /> <nf:instance name="output_queues" /> </nf:group> ...
How-to guide: a suggested procedure for getting from A to B
Implement basic packet counter registers
Implement the following three basic packet count registers: IP packets, ARP packets, and OSPF packets. You should create all registers required in the final deliverable of this part but just tie the currently unused ones to 0. (Your design should still be a non-learning switch.)
Study the remaining deliverables in this section. Design on paper the major functional blocks needed to implement this functionality. The design should show the major functional blocks/sub-modules and the dataflow between these modules. Please use a diagram to show the dataflow between modules and include a brief written description of the purspose of each module. This should be added to your hardware design document and should be one to two pages in length.
As an example, you may implement a Packet Classification block. A suitable descpription is:
Forwarding path to/from software and TTL/Checksum verification and update
Implement code that verifies the TTL and checksum of all IPv4 packets. If the TTL and checksum are valid, then decrement the TTL, update the checksum and forward the packet out the same port that it arrived on. (This behavior will change soon.) If the TTL or checksum are invalid then forward the packet without modification to the CPU.
Note that the presence of IP options complicated the checksum calculation process as the options increase the length of the IP header. IP options are rarely used in the internet today&msdash;as a result you should forward all IP packets with options to the software for processing. This allows the hardware to handle all regular packets at high speed without requiring complicated logic to deal with variable-length IP headers.
Forward all non-IP packets to the CPU. Packets sent to the CPU should not be modified.
Implement code that forwards all packets from the CPU to the corresponding Ethernet port. Packets from the CPU should not be modified when forwarded to an Ethernet port.
Note: You should remove the ARP and OSPF packet counters from this deliverable and all future deliverables.
Updated hardware design document (verification section)
Add a verification section to your hardware design document explaining how you will test your design (eg. what sorts of tests will you run. How will you test the hardware etc.)
Verification of MAC addresses/lookup in local IP table
You should have implemented a set of registers that allow the MAC addresses of each port to be specified. Verify that the MAC address of all incoming packets either matches the MAC address assigned to that port or is a broadcast address. (Broadcast MAC addresses are indicated by a 1 in the LSB of the first byte of the MAC address.) Packets that do not meet this requirement should be silently dropped.
Implement a table that allows a set of IP addresses to be specified that should be forwarded to the CPU (the “local IP address table”). Lookup the destination IP address of all IP packets in this table. If a match is found in the IP table then forward the packet to the CPU (without modification). If a match is not found, proceed with the normal forwarding path (eg. verify/update TTL and checksum and send to CPU/output as appropriate).
Hardware design document — Router interoperability testing
Add a section to your hardware design document outlining how you intend to test the interoperability of your router with the other groups.
Working router (tested interoperability with software)
Implement all remaining functionality, including the routing table and ARP table. Verify that your design works correctly your group’s software.
Fully working interoperable router
Your fully-operational router should interoperate correctly with the routers from the other groups. We will conduct an interoperability test session in which all groups will have to demonstrate the correct operation of their routers in a test topology under a number of failure conditions. A date/time for this session will be announced.
The deliverables from this step are: