Machine Problem 3 -- Part 1

Introduction

In lecture we discussed some motivations for adding priority and per-flow queuing to our firewall, such as quality of service incentives and guards against denial of service attacks. The features that will be added in machine problem 3 shift our attention from packet classification to queuing theory, which provides us with more options later for final projects.

Machine problem 3 is much longer than the previous projects, so please budget your time accordingly. To make it easier for testing and implementation, we have divided the project into two parts. In part 1, you will lay the groundwork for priority and per-flow queuing by updating your CAMs to assign flows. In part 2, you will create your own queue manager and output scheduler.

This assignment can be challenging because you are given flexibility to decide how to implement your design. You are responsible for making sure that your code uses only synthesizable VHDL constructs. If you are uncertain about what VHDL functions are not synthesizable refer to Introductory VHDL: From Simulation to Synthesis by Yalamanchili or another similar reference.

Background: CAM Lookup Filter

Previously, the CAM Lookup Filter was used to determine when to drop packets. Now, we will modify this behavior so that that the outcome of a match will assign a 16 bit FlowID to the packet. MP3 requires that you now implement four CAMs, each with a programmable FlowID. In part 2, we will build our service policy to prioritize packets based on their FlowIDs.

In the normal case that a packet does not match any CAM rule, then the FlowID should be set to "0000000000000001". Since we want some packets to be assigned to different flows, we need to change the firewall behavior so that we do not drop all packets that match. Instead, we should only drop packets (set TTL=x"00") if the FlowID equals "0000000000000000".

One must consider that using multiple CAM entries might produce multiple matches to the same packet, and so the CAMs will need to be prioritized, as we discussed in lecture. If multiple CAM entries match, then the FlowID should come from the highest priority CAM. Designate CAM1 to have the highest priority, CAM2 to have the next highest priority, CAM3 to have the next highest priority, and continue this pattern.

The FlowID has different behavior than the CAM_VALUE and CAM_MASK pairs, so you will need to store the FlowID in a seperate register.

Background: CAM Control Packet

To summarize, the updated CAM control packet has a new header fields and FlowID fields. The new header format specifies an 8 bit number of CAM entries, a 16 bit base CAM entry, and a 1 bit transmit_enable (bit 31). The main purpose of the new control packet format is to provide flexibility so that if one of the groups wanted to implement thousands of CAM entries for their final project the packet can support programming a wide range of CAMs. The base field specifies the the CAM that will be reprogrammed by the first CAM entry. The count specifies how many successive CAM entries (starting with the base CAM) are contained in the control packet. The transmit_enable will be used for debugging and testing part 2. For now, store transmit_enable in a register and pass its value to the output interface. Your finite state machine needs to be modified to accept control packets with a variable amounts of CAM entries, and to program CAMs 1-4 accordingly.

Background: Priority Queues and Flow Contexts

Lecture 11, slides 11-14 describe the behavior of the queue manager that will be used for part 2. Assume that the queue manager stores FlowID in some FIFO (with signals read, write, data_in(16 downto 0), data_out(16 downto 0), empty). The dequeue scheduler can be treated as a FIFO (same signals as the FlowID FIFO) which implements round-robin queueing. If the FlowID read from the scheduler still contains a backlog of packets, then the FlowID should be written back into the FIFO.

Directions:

• Change the CAM implementation to use 4 CAMs and to assign a FlowID to every packet. FlowID should be passed to the output interface of wrapper_app.
• A valid signal called FlowID_Valid will also need to be added to the wrapper_app output interface. FlowID_Valid should go high for one clock cycle to indicate when the FlowID is ready to be read. It is fine for the valid to occur after the start of the packet or after the packet headers.
• Modify your finite state machine to support the new CAM control packet format. This can be implented in a number of ways, so choose the implementation that is most convenient for you.
• Add transmit_enable to the output interface of wrapper_app. Initialize this value to be '1' on reset_l='0'. Update the transmit_enable bit whenever a control packet is received.
• To make it easier for testing and verification, replace the 16 bit Src Port (31 downto 16) with the FlowID for packets. This change can be made either using the start of data signal for packets or by updating it at the same time that you update TTL for dropping the packets. We have updated the server to accept Src. Port to be replaced on either all packets or all packets except for UDP control packets. (We decided that you should leave this change intact for part2, to make it easier for debugging.)
• Update the interface of wrapper_app in the wrapper_module.vhd file. For now, connect the new output ports to open (example_port <= open). Synthesize your circuit and generate the bitfile. Upload your bitfile to the CS536 batch test server.
• Draw the state diagrams, labeling states and state transitions, for the queue manager's enqueue and dequeue operations with SRAM (to maintain the flow context). Include the SRAM signals in the state machine (see slide with SRAM timing waveforms). Enqueue can use the mod1 interface and dequeue can use the mod2 interface. Refer to lecture 11 for details. Be careful of a race condition between the enqueue and dequeue state machines. Describe the operations that will be done in each state. Submit an electronic form of the diagrams (Visio, xfig, paint, PS, or PDF) in a tar file or zip file to the homework server.

Things to Turn In:

Here is a checklist of the things you need to turn in:

• Turn in the following vhdl source code:
  • wrapper_app.vhd (10pts)
• Synthesize and test your bit file (20pts)
• Turn in the following state diagrams in preparation for Part 2:
  • enqueue (10pts)
  • dequeue (10pts)
• Submit your wrapper_app.vhd and your FSM Diagrams for enqueue and dequeue to the Electronic Homework Server.