PROKNET: An IP/ATM processor University of Ottawa Rami Abielmona Samer Abielmona Mohamed Abou-Gabal Wael Hermas Dr. Voicu Groza Dr. Emil Petriu School of Information Technology Engineering

Presentation Outline (1) Introduction Objectives Self-imposed Q&A’s IP ATM IP over ATM System breakdown System operation

Presentation Outline (2) Module architecture/functionality TLL module ALU module Trailer module CRC module SAR module CU module Achievements Limitations / Future work Summary

Project introduction Proknet = processor + network Capable of receiving incoming variable- sized Internet Protocol (IP) packets, and outputting fixed-sized ATM cells Design is outlined, architecture is overviewed and final results are presented

Project objectives Main goal: “To provide an IP over ATM segmentation entity” Design goals: Forum compliance; Efficient implementation; Digital design adherence; Speed of execution and Network processor functionality

What is IP? A communication protocol that Utilizes connectionless-based datagrams that are routed using hop-by-hop routing algorithms to transfer them; Total length of packet is variable, ranging from 20 bytes to 64k bytes; Each packet is treated independently; No error control or reliability mechanisms; Routing of every single packet is required which consumes greater processing power

What is ATM? A communication protocol that Utilizes connection-based cells that are guided using a pre-planned path between nodes; Total length of cell is fixed at 53 bytes; Each cell traverses the dedicated route for the entire length of the data transmission; Error control and reliability mechanisms are provided on a connection basis rather than on a cell basis, which reduces the required processing power

What is IP/ATM? Combination allows for networks around the world to present a service that is as reliable and dedicated as ATM, while utilizing IP’s greater transmission capability and reduced overheads IP over ATM requires one to be able to segment the variable IP-packets into 48-byte cells at the transmitter (our focus)

System Breakdown (1) Proknet is made up of the following Total Length Logic (TLL) module; Arithmetic Logic Unit (ALU) module; Trailer module; Cyclic Redundancy Check (CRC) module; Segmentation and Reassembly (SAR) module; Control Unit (CU) module

System Breakdown (2) Figure 1

System Operation Figure 2

TLL TRAILER CRC 1 st IP Packet 2 nd IP Packet SAR 48 byte cells UUCPITotal LengthCRC Memory Adding Padding bits 8 bytes Trailer Appended 0000 A complete Padded IP Packet with valid CRC A complete Padded IP Packet with valid CRC Sequence 1

TLL (Total Length Logic) Counter 11 TL (1/2 ) TL (2/2 ) Extractor Extractor extracts the 8 byte Total Length from the packet and stores it into TLR register. TLR 11 Pad Algorithm TRAILER Module Outputs the Number of Pad bits Needed to make the packet divisible by 48. Incoming Packets 1 st byte 2nd byte 1 3rd byte 1 4 th byte Sequence 2

TLL Module Functionality Extract the total length field from the IP packet Perform preliminary setups for the downstream modules in the pipeline Calculate the number of padding bits needed and store that value in a register

ALU Module 16-bit adder-subtractor unit Aids in the instruction execution, by residing on the datapath of the main processor and feeds the accumulator Designed using combinatorial ALU design techniques

Trailer Module Architecture Figure 3

Trailer Module Functionality A byte is written and another is read simultaneously. Incoming byte 8 byte FIFO CU_EOP is low. 0 1 CU_EOP switches high which means it’s time to output the Trailer. 8 byte Trailer Sequence 3

Trailer Module 1. When a byte of a packet is received from the TLL module, the control unit wries into the 8-byte FIFO memory 2. On the next clock cycle, the byte that was written in step 1, gets read and at the same time another byte is written into the FIFO 3. Steps 1 and 2 are repeated until the CU_EOP (End of Packet) signal is asserted by the CU, which indicates to start sending the trailer 4. When the counter is done, a Done_Trailer signal is sent to CU

CRC Module Architecture Figure 4

CRC Module Functionality 2 nd Packet A byte is written and another is read simultaneously. 4 byte FIFO CU_C_EOP is low. 1 st Packet 0 1 CU_C_EOP switches high which means it’s time to output the 4 bytes of valid CRC. 4 bytes of valid CRC CRC32 Algorithm UUCPITL 4 bytes of valid CRC Sequence 4

CRC Module 1. The Trailer module sends the first byte of packet, thus the CU writes it to the 4-byte FIFO 2. On the next clock cycle, a second packet comes in, the CU will write it in to the FIFO, and at the same time it will read the first byte 3. Steps 1 and 2 are repeated until CU_Done_Trailer is asserted, which indicates to start sending the CRC 4. Once all 4 bytes are placed on the pipeline, Done_Crc is sent to the CU

Initial IP Packet Structure Post-trailer Packet Structure In-memory Packet Structure Figure 5 Figure 6 Figure 7

SAR Module Functionality SEGMENTATION Message Trailer PAD Each is 48 bytes. Sequence 5

Control Unit Module Microprocessor chosen was an 8-bit one All instruction opcodes were limited to 8 bits, while memory was addressed with a 12-bit address bus The clock period was defined to be 40 ns, thus the clock frequency was 25 MHz The memory is a ternary-port memory, needed to perform three distinct operations upon the memory, all in one cycle. The operations are: Fetching an instruction for execution Write-out to memory of a byte from CRC module Read-out from memory a byte to SAR module

Memory Interface Figure 8

Achievements Proknet was implemented using the Verilog hardware description language The project has successfully gone through: Functional simulation Synthesis Timing simulation Space and time restrictions do not allow us to present simulation results, but can be provided upon request

Limitations / Future Work Proknet cannot handle more than 2 packets on the pipeline The CRC calculation was done on the packet and the trailer, excluding the padding bytes Reassembly side will complete SAR functionality Proknet could benefit from a parallel architecture, where multiple pipelines could be executing on various packets Queuing and scheduling will aid in the management of the multiple queues

Summary Network processor design was completed successfully Work can be smoothly extended to other technologies merging together in order to perform the same functionalities, such as ARM over frame relay Contact information:

Questions / Comments ?