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)

IntroductionObjectivesSelf-imposed Q&A’s IPATM IP over ATM

System breakdownSystem operation

Presentation Outline (2)

Module architecture/functionality TLL module ALU module Trailer module CRC module SAR module CU module

AchievementsLimitations / Future workSummary

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 andNetwork 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 followingTotal 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

1st IP Packet

2nd IP Packet

SAR

48 byte cells

48 byte cellsUU CPI Total Length CRC

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 1 1

TL (1/2

)

TL(2/2

)

ExtractorExtractor extracts the 8 byte Total Length from the packet and stores it into TLR register.

TLR

1 1 Pad Algorithm

TRAILERModule

Outputs the Number of Pad bits Needed to make the packet divisible by 48.

Incoming Packets

1st byte

2ndbyte

1

3rdbyte

1

4th 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

2nd Packet

A byte is written and another is read simultaneously.

4 byte FIFO

CU_C_EOP is low.

1st 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 ModuleMicroprocessor chosen was an 8-bit oneAll instruction opcodes were limited to 8 bits, while memory was addressed with a 12-bit address busThe clock period was defined to be 40 ns, thus the clock frequency was 25 MHzThe 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 languageThe 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 pipelineThe CRC calculation was done on the packet and the trailer, excluding the padding bytesReassembly side will complete SAR functionalityProknet could benefit from a parallel architecture, where multiple pipelines could be executing on various packetsQueuing and scheduling will aid in the management of the multiple queues

Summary

Network processor design was completed successfullyWork can be smoothly extended to other technologies merging together in order to perform the same functionalities, such as ARM over frame relayContact information: rabielmo@site.uottawa.ca groza@site.uottawa.ca petriu@site.uottawa.ca

Questions / Comments ?