PPT-Xian-26-10-2010

KAIST

Dynamic Adaptive Self-ConfigurableNetwork Processor

SATHEESH ABIMANNAN

Assistant Professor

Department of Computer Science and Engineering

Periyar Maniammai University

The 7th International Conference on

Ubiquitous Intelligence and Computing

26-29, October 2010, Xi’an, China

“Learn, until you get rid of your ignorance and then

having obtained the required knowledge and skills, put them into practice”.

“Kural 391. Learning”

22 / 46 / 46

PERIYAR MANIAMMAI UNIVERSITYPERIYAR MANIAMMAI UNIVERSITY

33 / 55 / 55

“Priyar the prophet of New Age, Socrates of South East Asia,

Father of the social Reform Movement, and Arch enemy of

ignorance, superstitions, meaningless customs

and base manners”

UNESCO 27-6-1970

44 / 46 / 46A.SATHEESH, Periyar Maniammai University

OVERVIEWOVERVIEW

Introduction

Network processor Architecture

Problem description

Background

Methodology

Result

Conclusion and Future work

References

Introduction – Network SystemIntroduction – Network System

55 / 46 / 46Dynamic Adaptive Self-Configurable Network Processor

Example : Network SystemsExample : Network Systems


Layer 2

Bridge, VLAN switch, DSL modem

Layer 3

IP Router

Layer 4

NAT box, TCP splicer

Layer 5

Firewall, web load balancer, softswitch

77 / 46 / 46A. SATHEESH, Periyar Maniammai University, India

Definition: High SpeedDefinition: High Speed

1960 : 10 Kbps

1970 : 1 Mbps

1980 : 10 Mbps

1990 : 100 Mbps

2000 : 1000 Mbps (1 Gbps)

2004 : 2.4 Gbps

2005 : 10 Gbps

2010 : 100 Gbps

History of Network Systems

First generation (circa 1990)

Software running on conventional computer

Second generation (circa 1995)

ASIC hardware for packet classification

Switching fabric and less centralization

Third generation (circa 1999)

Completely decentralized architecture

Embedded processor per interface

Distributed routing table


Problems with Third Generation Problems with Third Generation DesignsDesigns

High cost : $1M per ASIC spin

In-house expertise : ASIC designer needed

Time to market : 18-20 months for silicon

Quality control : difficult to simulate/test

Inflexibility : expensive and time-consuming to change

Little reuse across

Products

Versions


A Fourth GenerationA Fourth Generation

Introduced in 1999

Goal : combine best features of first generation and third

generation system

Flexibility of programmable processor

High speed of ASICs

Technology called network processors

Second generation appeared in 2003

1010 / / 4646Dynamic Adaptive Self-Configurable Network Processor

Definition: Network ProcessorDefinition: Network Processor

Software programmable device designed specifically to

process packet data at wire-speed.

Pattern Matching

Lookup

Data Manipulation

Queue Management


Network Processor DesignNetwork Processor Design

What is known

Must partition packet processing into separate functions

To achieve highest speed, must handle each function with

separate hardware

Still being researched

Which functions to choose

Which hardware building blocks to use

How to interconnect building blocks

Which programming paradigm to use


1313 / / 4646A.SATHEESH, Periyar Maniammai University

OVERVIEWOVERVIEW

Introduction


Problem description

Background

Methodology

Result


References


Network processor ArchitectureNetwork processor Architecture

Micro-Engines(8)

General Purpose CPU

Multiple memory types

Internal gigabit bus

Programmable Hardware components

Gigabit Ethernet ports


OVERVIEWOVERVIEW

Introduction


Problem description

Background

Methodology

Result


References

Problem descriptionProblem description

Current NP systems do not simultaneously deal well with variety of

services and fluctuating workloads.

Because of the traffic fluctuations inherent in packet networks, the

workload on each pipeline Stage in network processor may vary

significantly over time, thus affecting the performance.



Problem and SolutionProblem and Solution Design-time allocation

Processors allocated to packet types based on expected maximum load

however, observed load is often lower and fluctuates over time

Runtime processor allocation and adaptation

Wor

k

Time

Statically allocated

Max. instantaneous processors required

Avg. processors used


Proposed workProposed work

The task of self-configuring network processor constitutes both control plane and data plane processing; our work mainly deals with control plane. Here the control plane is used to reconfigure the network processor based on the network traffic.

Further active network concept is used for reconfiguring the system, with the code being deployed using SOAP protocol.

Active networking is a communication paradigm that allows packets flowing through a communication network to dynamically modify the operation of the network.

So in order to reconfigure the Network processor dynamically the binary code will be brought through SOAP packet(Active network concept).


What is Run-Time Adaptation?What is Run-Time Adaptation? Processor allocations can be adapted at fine time scales and if

the total available processing power can be allocated to packet

types in small granularities.

Network Processors are inherently capable of Runtime

Reconfiguration

Lack of Runtime Reconfiguration support in Network Processor Software Support Active Networks Software Updates Load-balancing Reconfiguration of forwarding functions

Run-Adaptation: ChallengesRun-Adaptation: Challenges

Monitoring and Predicting Packet Arrivals

When Processor allocation should be adapted?



OVERVIEWOVERVIEW

Introduction


Problem description

Background

Methodology

Result

Discussion


References

BackgroundBackground

2002 - Tilman Wolf, Department of Computer Science Washington

University

To developed a network processor benchmark, Common Bench mark for NP design.

2003 - I.A. Troxel, et al. HCS Research Lab, University of Florida.

superior performance of enhanced NP over baseline NP for prioritized traffic that is non uniform.

ME pipelines were not reconfigurable.


Background Background (Cont..)(Cont..)

2004 - Ravi kokku, et al. University of Texas at Austin.

benefits and challenges of adapting allocations of processors to packet type in packet processing systems.

allocating processing power to packet types in small granularity is more important—if the allocation granularity is large, then even a very fine adaptation time-scale yields meager benefits.

2004 - Kevin Lee et al. Lancaster University, Lancaster, UK.

- Runtime component based approach to programming NPs.

2005 – Arun Raghunath et al. Intel Research and Development,

Hillsboro, U.S

-



OVERVIEWOVERVIEW

Introduction


Problem description

Background

Methodology

Result


References


MethodologyMethodologyThe functions of the Reconfigurable system developed include the following:

Monitoring the network traffic and collecting the monitored values.

Decision-making based on the monitored values

Deciding whether to reconfigure or not . Need for changing current mapping of resources. Presence of under utilized resources. Availability of alternate mapping.

Identify the mapping .

Monitoring for active packet and extracting the binary file from the SOAP packet

X-scale must deploy the code onto the micro-engines (Configure)


Functional Block DiagramFunctional Block Diagram

Decision Making

Monitoring Runtime Environment

Decision Table

Service Table

Service

Resources-ME

X-scale

(Control plane processing)

Micro engine (Data plane processing)

Deploy()Monitor( )

Deploy_status()Monitor_status( )

Packet in and out

N/W


AA

AC B

Traffic Mix

Executable binaries

ME

Monitoring

Run-time system

Decision making

Dynamic Deployment

ME2

ME3

ME4

ME7

ME6

ME5

ME1

ME8

A B

C

Resource Mapping

BB CC

Micro Engine


Monitoring ModuleMonitoring Module

Ingress

Switch Fabric

Micro Engine Egress

X scale Core Processor

Monitoring SRAM for count value

SRAM

Packet In Packet Out


Functions to be performedFunctions to be performed

Count of incoming packets to the ingress .

Count of outgoing packets from the egress.

Maintaining both the counts at a common place for easy access.

Formula for finding arrival and departure rate:

Rate = N /T

Where N = Number of packets (packet count)

T = Time interval in seconds


Decision making moduleDecision making module

Input: Statistics maintained by monitoring.

Output: Whether to use allocation policy or de-allocation policy and using it according to the statistics.

Allocation Rule: If (arrival_rate>minimum_threshold &&

queue_lagging > threshold1)Then deploy(mod);//Deploy Binary code

to overcome moderate trafficIf (arrival_rate>maximum_threshold && queue_lagging > threshold2)

Thendeploy (max);//Deploy Binary code to overcome maximum traffic

Note: The threshold value is fixed based on the network trace taken earlier by monitoring the traffic.


Continue…Continue…

De allocation Rule:

If(arrival_rate<minimum_threshold) Then

{Stop(mod);}

If(arrival_rate<maximum_threshold) Then

{Stop(max);}


Active code Transfer module

The Active code will be transferred to the network processor through the SOAP protocol, which will be get extracted and deployed the micro engine by x-scale core processor.


Design of Active code TransferDesign of Active code Transfer

Micro engine level Design

Ingress Classifier

Active code Handler

Normal packet Handler

Egress

ME0 ME1

ME2

ME3

ME4


Working ModelWorking Model

Minimal service provided, when there is no traffic i.e., Before configuration

Mapping I: Min_service_upon_less_traffic

Note: Processing consist of classifier, service registration, Connection close, Load factor updation, Connection request, service request, server avail check.

Ingress EgressALS instance1

ME0 ME1 ME2

PKT_RX_TO_CLASSIFIER_SCR_RING EGRESS RING


Mapping II:Mapping II: Mapping II: Min_service_upon_moderate_traffic

When there is traffic, resources can be configured as follows:

-Replication of same instance

After Configuration:

Ingress EgressALS instance1

ME0 ME1 ME2

ALS instance 2

PKT_RX_TO_CLASSIFIER_SCR_RING

EGRESS RING

ME3


Mapping III:Mapping III: Mapping III:- Max_service_upon_Heavy_traffic

Note: P1 does the table updation work such as load updation, Service registration, connection close. P2 does read operation from the table such as server avail check, handling connection request, service request.

ME5

EgressALS Instance 1

ME0ME1 ME2

Classifier

P1

P3

ME3

ME6

P2

PKT_RX_TO_CLASSIFIER_SCR_RING Egress ring

Ingress

ME4


OVERVIEWOVERVIEW

Introduction


Problem description

Background

Methodology

Result


References


ResultResult

Traffic from outside Network:

The Traffic trace taken from the network are classified into low (250 pkts/ sec), moderate (450 pkts/sec) and high (950 pkts/sec) and the traffic mixture taken are low, moderate and high.

Packet from outside Network

0100200

300400500600700

800900

1000

0 20 40 60

Time in Sec

Wo

rk lo

ad(N

o o

f p

kts/

sec)

Arrival Rate


NP without Dynamic NP without Dynamic ReconfigurationReconfiguration

Mapping I:

Mapping I

0

50

100

150

200

250

300

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30

Time(Sec)

Wo

rklo

ad(N

o o

f p

kts/

sec)

Arrival Rate Queue Length



Mapping II

Mapping II

0

100

200

300

400

500

600

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30

Time(Sec)

Wo

rklo

ad(N

o o

f p

kts/

sec)




Mapping III

Mapping III

0

100

200

300

400

500

600

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30

Time(Sec)

Wo

rklo

ad(N

o o

f p

kts/

sec)



NP with Dynamic ReconfigurationNP with Dynamic Reconfiguration

Dynamic Deployement

0

100

200

300

400

500

600

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30

Time(Sec)

Wo

rklo

ad(N

o o

f p

kts/

sec)


Dynamic Deployment


OVERVIEWOVERVIEW

Introduction


Problem description

Background

Methodology

Result

Conclusion

References

ConclusionConclusion

Run-time adaptation can reduce energy consumption by 70-80%

Processor provisioning level by 40-50%.



References – 1/2References – 1/2

1. Kevin Lee, Geoffrey Coulson “ Supporting Runtime Reconfiguration on Network Processors ”, Proceedings of the 20th International IEEE Conference on Advanced Information Networking and Applications (AINA’06) Volume 1, 18-20 April 2006 Page(s):721 – 726, 2006.

2. I.A. Troxel, A.D. George, and S. Oral “ Design and Analysis of a Dynamically Reconfigurable Network Processor” FL Proceedings of the 27th Annual IEEE Conference on Local Computer Networks (LCN.02) Page(s):483 – 492, Nov.2002

3. Ravi Kokku, Upendra Shevade, Nishit Shah, Harrick M. Vin, Mike Dahlin “Adaptive Processor Allocation in Packet Processing Systems” University of Texas at Austin Technical Report # TR04-04.

4. Vinod Balakrishnan, Ravi Kokku, Aaron Kunze, Harrick Vin, Erik J. Johnson “Supporting Run-Time Adaptation in Packet Processing System” Intel Research and Development University of Texas at Austin 2004, Technical Report


References – 2/2References – 2/2

5. Arun Raghunath, Aaron Kunze, Erik J. Johnson, Vinod Balakrishnan “Framework For Supporting Multi-Service Edge Packet Processing On Network Processors” ANCS’05, October 26–28, 2005, Princeton, New Jersey, USA.

6. Ravi Kokku, Taylor L. Rich´e, Aaron Kunze , Jayaram Mudigonda , Jamie Jason , Harrick M. Vin “A Case for Run-time Adaptation in Packet Processing Systems” ACM SIGCOMM Computer Communications Review , Volume 34, Number 1: January 2004

7. Kevin Lee, Geoff Coulson, Gordon Blair, Ackbar Joolia, Jo Ueyama “Towards a Generic Programming Model for Network Processors” In Proc IEEE International Conference on Networks (ICON04),

Singapore, Nov 2004


Q & A

PPT-Xian-26-10-2010

Documents

Transcript of PPT-Xian-26-10-2010