Design and Implementation of a - PowerPoint Presentation

Slide1

Design and Implementation of aConsolidated MiddleboxArchitecture

1

Vyas Sekar

Sylvia Ratnasamy

Michael Reiter

Norbert Egi Guangyu ShiSlide2

Need for Network Evolution2

New devices

New applications

Evolving threatsPolicy constraints

Performance, Security, ComplianceSlide3

3

Type

of appliance

NumberFirewalls166NIDS127Media gateways110

Load balancers67Proxies66VPN gateways45WAN Optimizers44

Voice gateways11Total Middleboxes636Total routers~900

Network Evolution today:

Middleboxes

!

Data from a large enterprise:

>80K users across tens of sites

Just network security

$10 billionSlide4

4

S

pecialized

boxesNarrowinterfaces“Point”solutions!Increases capital expenses & sprawl Increases operating expensesLimits extensibility and flexibility

Management

Management

Management

Key “pain points”

Slide5

MotivationHigh-level idea: Consolidation

System design

Implementation and Evaluation

5OutlineSlide6

Network-wide

Controller

Key idea: Consolidation

2. Consolidate

Management

1. Consolidate

Platform

Two levels corresponding to two sources of inefficiency

6Slide7

Consolidation at Platform-Level7

Proxy

Firewall

IDS/IPS

AppFilter

Today: Independent, specialized boxes

Decouple

Hardware and

Software

Commodity hardware:

e.g.,

PacketShader

,

RouteBricks

,

ServerSwitch

,

SwitchBlade

Consolidation reduces capital expenses and sprawlSlide8

Consolidation reduces CapEx8

M

ultiplexing benefit =

Max_of_TotalUtilization / Sum_of_MaxUtilizationsSlide9

Consolidation Enables Extensibility9

Session Management

Protocol Parsers

VPN Web Mail IDS Proxy

Firewall

Contribution of reusable modules:

30 – 80 %Slide10

Management consolidation enables flexible resource allocation

10

N1

N3N2P: N1 N3Process (0.4 P)

Today: All processing at logical “ingress”Overload!Network-wide distribution reduces load imbalanceProcess (0.3 P)Process (0.3 P)

Process (P)Slide11

MotivationHigh-level idea: Consolidation

CoMb

: System design

Implementation and Evaluation11OutlineSlide12

Network-wide

Controller

CoMb

System Overview

12

General-purpose hardware:

e.g.,

PacketShader

,

RouteBricks

,

ServerSwitch

,

Logically centralized

e.g

.,

NOX, 4D

Existing work: simple, homogeneous routing-like

workload

Middleboxes

: complex, heterogeneous, new opportunitiesSlide13

Network-wide

Controller

Processing

responsibilitiesCoMb Management LayerPolicy Constraints

ResourceRequirementsRouting, Traffic

Goal: Balance load across network.

Leverage

multiplexing

, reuse,

distribution

13Slide14

Capturing Reuse with HyperApps14

IDS

Proxy

common

Footprint on

resourceHTTPUDPHTTPNFS2311MemoryCPU

HTTP = IDS & Proxy

4

3

Memory

UDP = IDS

NFS = Proxy

1

3

4

1

CPU

CPU

Memory

Memory

CPU

HyperApp

:

find the

union

of apps to run

Policy, dependency are implicit

Need per-packet

p

olicy, reuse dependencies!

HTTP

:

1+2 unit of CPU

1+3 units of

memSlide15

Modeling Processing Coverage15

HTTP

N1

 N3N1 N2 N3 What fraction of traffic of class HTTP from N1 N3 should each node process?

IDS < Proxy0.4HTTP: Run IDS < Proxy IDS < Proxy0.3IDS < Proxy0.3Slide16

Network-wide Optimization16

Minimize Maximum Load, Subject to

Processing coverage for each class of traffic Fraction of processed traffic adds up to 1

Load on each node  sum over HyperApp responsibilities per-pathA simple, tractable linear programVery close (< 0.1%) to theoretical optimal No explicitDependencyPolicySlide17

Network-wide

Controller

CoMb

System Overview

17

General-purpose hardware:

e.g.,

PacketShader

,

RouteBricks

,

ServerSwitch

,

Logically centralized

e.g

.,

NOX, 4D

Existing work: simple, homogeneous routing-like

workload

Middleboxes

: complex, heterogeneous, new opportunitiesSlide18

CoMb Platform18

NIC

Policy Shim (

Pshim)C

ore1Core4IDS……

ProxyTrafficApplicationsPolicy EnforcerClassification: HTTP

IDS < Proxy

Challenges:

Performance

Parallelize

Isolation

Challenges:

Lightweight

Parallelize

Challenges:

No contention

Fast classificationSlide19

Parallelizing Application Instances19

M

1

M2

PShimApp-per-core Core3

M3PShimCore1Core2HyperApp-per-core M2

M3

PShim

M

1

M2

PShim

Core1

Core2

Inter-core communication

More work for

PShim

+ No in-core context switch

+ Keeps structures core-local

+ Better for reuse

- But incurs context-switch

- Need replicas

✔

HyperApp

-per-core is better or comparable

Contention does not seem to matter!Slide20

CoMb Platform Design20

Hyper

App1

HyperApp2HyperApp4

HyperApp3HyperApp3PShimPShimPShim

PShimPShimM1M4M1M4

M

2

M

3

Q1

Q3

Q2

Q4

Q5

M

1

M

5

Core 1

Core 3

Core 2

NIC hardware

Contention-free network I/O

Core-local processing

Parallel, core-local

Workload balancingSlide21

MotivationHigh-level idea: Consolidation

System design: Making Consolidation Practical

Implementation and Evaluation

21OutlineSlide22

Implementation22

Network-wide Management

Session

Protocol

Extensible apps

Standalone

apps

Policy Shim

using CPLEX

Kernel mode Click

Ported logic

From

Bro

 Click

Memory mapped

Or

Virtual interfaces

8-core Intel Xeon with Intel 82599 NIC Slide23

Consolidation is PracticalLow overhead for existing applicationsController takes < 1.6s for 52-node topology

5x better than VM-based consolidation

23Slide24

Benefits: Reduction in Maximum Load

24

Consolidation reduces maximum load by 2.5-25X

MaxLoadToday /MaxLoadConsolidated Slide25

Benefits: Reduction in Provisioning Cost

25

Consolidation reduces provisioning cost 1.8-2.5X

ProvisioningToday /ProvisioningConsolidated Slide26

DiscussionChanges traditional vendor business Already happening (e.g., “virtual appliances”)Benefits imply someone will do it!

May already have extensible stacks internally!Isolation

Current: rely on process-level isolationGet reuse-despite-isolation?

26Slide27

Network evolution occurs via middleboxesToday: Narrow “point” solutionsHigh CapEx

, OpEx, and device sprawlInflexible, difficult to extend

Our proposal: Consolidated architectureReduces CapEx, OpEx

, and device sprawl Extensible, general-purposeMore opportunitiesIsolationAPIs (H/W—Apps, Management—Apps, App Stack)27Conclusions