You are here: Home / Past Courses / Spring 2011 - ECPE 293B / Projects / Project - Hardware IP Router

Project - Hardware IP Router

Overview

In this project, you will create a 4-port hardware IP Router that implements the longest-prefix match forwarding algorithm. The hardware should process all regular IP packets without requiring any help from the software. Your hardware router should only forward packets to software in the following cases:

  • The packet is incorrect (bad TTL, version, etc.)
  • Some information that is needed to forward the packet is missing (no MAC address found in the ARP table, etc.)
  • The packet is explicitly destined for the software (ARP, OSPF, destination IP address is the same as one of the router's interfaces, etc.)
  • The packet is unrecognized (i.e., not IPv4 or ARP)

In other words, in the common case, packets will be forwarded directly by the hardware with no intervention from the software. Note that this means that until the hardware and software components are connected, you will need to manually initialize the routing and ARP tables in order for your hardware router to function.

 

Getting Started

In this project, you should take your previous Ethernet Switch design and modify the output_port_lookup module to create a 4-port Ethernet IP Router. (Or, you might prefer starting fresh with the original Ethernet NIC design from the tutorial and selectively adding code from the switch as needed.)

In your IP Router, you will be directly processing raw Ethernet packets in Verilog. The following resources will be helpful in completing this project:

  • Course Resources - References on Verilog programming and packet / protocol formats.
  • Hardware Common Tasks - Instructions on how to perform common hardware tasks such as customizing a Verilog library module or compiling your design.
  • Register Map - Specifications on the software-accessible control interface that your router must implement.
  • Verilog Hierarchy - Diagram with the hierarchy of key Verilog modules shown

 

Requirements

Your router must:

  • Provide a Forwarding Table
    • The forwarding table will accept the destination IP address as a search key and perform a longest-prefix match by IP address/mask. The forwarding table should return the appropriate egress port (or none) and the next-hop IP address (or 0.0.0.0 for a directly attached destination).
    • This table must contain at least 16 elements and inform software of its size (via the ROUTER_OP_LUT_ROUTE_TABLE_DEPTH register)
    • In the final router, this table will be controlled by software. Software will be responsible for sorting the table such that the longest prefixes are stored at the beginning of the table (starting at element 0). In this project, you can do the sorting in your own testing programs that initialize the forwarding table.
    • You can use the Xilinx CoreGen CAM module (in standard ternary mode) or create your own design
  • Provide an ARP Table
    • The ARP table will accept the next-hop IP address as a search key and return the associated MAC address (if found).
    • In the final router, this table will be controlled by software running the ARP protocol.
    • If the destination is directly connected (and the next-hop IP address returned was 0.0.0.0), the hardware should look up the destination IP in the ARP table instead.
    • This table must contain at least 16 elements and inform software of its size (via the ROUTER_OP_LUT_ARP_TABLE_DEPTH register)
    • You can use the Xilinx CoreGen CAM module or create your own design
  • Provide a Destination IP Address Table
    • The destination IP address table will store IP addresses that must be forwarded to software. This consists of the router IP addresses for each port, and possibly future IP addresses for router-to-router control protocols.
    • In the final router, this table will be controlled by software
    • This table must contain at least 4 elements (one IP address for each router port) and inform software of its size (via the ROUTER_OP_LUT_DST_IP_FILTER_TABLE_DEPTH register)
    • You can use the Xilinx CoreGen CAM module or create your own
  • Perform fast-path data-plane router operations in hardware. These include (but are not limited to):
    • Verify packets are IPv4
    • Verify IPv4 checksum
    • Decrement and check TTL to ensure packet is still "live"
    • Look up the next-hop port in the forwarding table
    • Look up the MAC address of the next-hop in the ARP table
    • Calculate a new IP checksum (or fix the existing checksum) because the TTL in IP header was updated
    • Transmit the new packet via the appropriate egress port.
  • Drop control-plane packets (they will be sent to the CPU queue to be handled by software in the future).
    • Drop local IP packets (destined for the router)
    • Drop invalid packets (expired TTL, version, etc)
    • Drop ARP packets
    • Drop packets if the hardware is missing information (such as no MAC address found in ARP table or no forwarding path found)
    • Drop any unknown packets (e.g. IP not v4)
  • Provide software with read/write access to the route table, ARP tables, and destination IP table. You must implement the functionality described in the Register Map document
    • The switch-specific Output Port Lookup registers from your previous project should be removed
    • The router-specific Output Port Lookup registers should be added
    • Whenever possible (or reasonable), we recommend making your registers generic and backed by real memory on the FPGA. This allows software to, for example, write a value and immediately read it back from a register.
  • Provide statistics to software as specified on the Register Map page.
  • Run at 125MHz and meet all provided timing constraints in order to receive full credit
  • Your code must compile using the Xilinx tools installed on the ecs-network class server.
  • All requirements must function both in the simulator and on the NetFPGA hardware. A simulator-only design does not meet project requirements.


Packets that are not handled by the hardware router should be dropped in this current project. You can accomplish this by setting the one-hot output port vector to zero, and the packet will not be saved to any output queue. When you integrate your hardware router with control software, instead of dropping these packets, you will need to save them to a CPU queue (corresponding to the input MAC queue) to be forwarded to software for further processing. In your hardware design, you should make it possible to easily change this behavior. The recommended approach is to define a parameter and use generate statements to change the hardware design at compile time. When forwarding packets to the software, the packet should be completely unmodified . (For example, the TTL should not be decremented). Further, when receiving packets from software, the hardware should send out the packet on the corresponding port without further modification (i.e. the TTL should not be decremented).

 

Design and Style

  • Good style simplifies coding, debugging, maintenance, and extension of your code. You should refer to the Hardware Style Guide for some pointers.

 

Deliverables

 

Project meetings

We will have regular project meetings throughout the semester. (Please consult the Schedule for the specific days). Over the course of this project, you group will be asked to informally discuss your design and implementation during these meetings.

 

Source code

You will submit your Verilog source code for the IP Router, which we will then build on ecs-network.serv.pacific.edu and test on our own NetFPGA board. For more details, see Project Submission.

 

Project Report

Your project report should be an updated version of your Router Design Document that accurately reflects the hardware router as implemented.

 

Grading

This project will be graded out of 100 points.

  • Implementation / correctness: 85 points
  • Written report: 15 points

This guideline is not binding; we reserve the right to assign whatever grade we believe is fair.