TCAMimic

Download TCAM mimic Package from here: TCAMimic

The TCAMimic software package is a hardware simulator for TCAM hardware based on real TCAM Hardware architecture. It is built from the following main components: Context Buffer, TcamEntries, OutputRegisters, and the InterLogic. The InterLogic is in charge of the communication between all the internal components in the TCAM and acts as a scheduler, the TcamQueue allows buffering inside the TCAM for fast access to data instead of retrieving information from the RAM, the databases records is where we upload and store the search rules in the TCAM with bits at 0,1,x (don’t care)

An additional module is introduced called Logic. The Logic acts as a CPU i.e. and implements the search logic in the system. This logic is responsible for reading configuration and data from external files or NICs, configuring and sending search keys to the TCAM through the InterLogic interface, and retrieving the Database HPM address from the OutputRegisters.

Each command in the system has an optional built in delay timer and can delay actions according to the execution time a command takes. i.e. we can configure the CompareTime of the TcamEntries to 30 TICs thus delaying the command. The delay interfaces are read, write, processing times etc. and can be configured through the ini file in the project. Since we are simulating a multitasking hardware environment, it is important to consider these delays when pipelining your operations in the system.

The system also has Blocks, which allows the TCAM to create simultaneous searches in the same TIC, so you can search for several different keys in the same TIC. I’ve extended the parallel searching functionality and there is now a possibility to create parallel searches at variable lengths, so you can upload to the TcamEntries a separate block of keys in different lengths. You can create as many of these blocks as you like, but normally TCAMs don’t have more than 4.

The system is built using OMNET++ which helps simulating the multitasking needed for this hardware device since the TCAM works in a pipelining method, every TIC it may introduce new commands to the components while executing the commands from the former TIC.

The OMNET++ platform using c code which can probably be upgraded to .NET uses messages and events to synchronize the system events. These messages are sent on channels which are defined through the graphical layout file (.ned) and allow sending messages between the different components. I’ve edited the source code of the project to enable sending additional information in these messages such as the Block numbers, search keys, etc. so parsing is much easier to handle when receiving an incoming message at a component.

Each component has an initialize method which should be used to initialize your components and a handleMessage(..) method which handles all incoming messages to the component.

In order to differentiate between the different messages I’ve redesigned the message kind message property to hold the description of a message, origin, destination, and command, by using enumerations which can be viewed in the misc.h file. Using these enumerations is what helps differentiate the incoming messages to the different components.

The simTime() command holds the global simulation time. This is used to schedule messages to a certain time using the schedultAt() method, and of course can be used to retrieve the current simulated time of the system. The send () command will send a message without the delay in schedule at. In order to send a message it must first be created, but note that some messages are deleted during the flow, and recreated at a later time.

Configuration FILES

The CompactDFA configuration file should be a csv file with the following format 28041,010001110110100100010000000000000000000001000,7,1,IDEADIR which is [DFA State returned from the database], [DFA nextState], [Depth], [IsMatch], [Pattern Match]. The next state does not include the next char you are analyzing and will be concatenated at the send of the state before sending to the TCAM for HPM search.

The database rule file should be a csv file with the following format 344963,0011011110000001000000xxxxxxxxxxxxxxxxxxxxxxx01001101,3353 which is [database record address], [the rule to match to], [the matching DFA State]. It is assumed that the database rules are sorted according to priority where the lowest database address has the highest priority for match and will be chosen in case there are multiple matches.

The Packet stream file is a csv file and is used only in the TOY example with test data. It contains the data for search and can be chars or binary data. In case you wish to run on live data there should be a standard pcap dump file where we take into account the actual packet timestamp to calculate system latency, queuing times, throughputs and algorithmic measures.

· Configuration files:

The network.ned file defines the graphical interface of the components and generates code which defines the channel names and parameters of OMNET++.

The omnetpp.ini file holds configurations such as component delays, number of max records for each component and the max width of the component.

All additional configurations are nicely organized in the misc.ini file which includes the number of packets to take from the file, how many parallel processes to use, if Intra mode should be used and how many bytes to take for a chunk. You should probably understand the implemented algorithem very well if you choose to play around with advanced features of this specifically implemented logic.

The system is generic, except the logic ofcourse which is tailored per algorithmic use and should be re written when attempting to use this package for other implementations. The Logic can be comfortable disconnected from the system and a new one introduced without modifying the rest of the TCAM components.

Configuration examples with system latency = 4 TICs

· Configuration code for Naïve mode

· Configuration code for InterPacket Interleaving

· Configuration code for Intrapacket Interleaving

Code Packages

There are 2 packages uploaded to this server, a TOY package and a Real-Data Package. The difference is because the TOY example doesn’t use the timestamps which appear in a real-packet, so it was simpler just to duplicate the project. Please notice that there are no changed in the actual TCAM components other than the Logic which handles the packet parsing.

The OMNET++ project can be downloaded from here http://www.omnetpp.org/, please note that the cmessage.h file has been changed in the source code and should be replaced once you are done installing the environment. Sample real data can be downloaded from here http://www.ll.mit.edu/mission/communications/ist/corpora/ideval/data/1998/training/week1/index.html