Transcript oasis_talk

OASIS: Enabling Services with
Programmable Networks
George Porter
Mel Tsai
Li Yin
Randy Katz
1
Outline









Overview
Introduction to PNEs
Motivation: PNEs and Network Appliances
Research Opportunities
Understanding Applications for PNEs
Programming PNEs
Our Current Testbed
Experimental Plan
Q&A with Audience
2
Overview

This presentation is a brief summary of our
whitepaper,


“The OASIS Group at U.C. Berkeley: Research
Summary and Future Directions”
Sahara is focused on services in the network…

The goal of OASIS is to enable new services using
programmable networks
3
Introduction

A programmable network element (PNE) is a router that
can perform flexible, complex, and application-level
computation on packets in the fast path
Output
Packets
Basic PNE Functionality
Input
Packets
Classify
Infer
Act
State Info
4
Classify-Infer-Act

A server and router in “one”


Tight integration between packet processing and routing
High bandwidth (routers) and computation (servers)
Ethernet
Forward
TCP/IP lookup
IP
Drop
Intrusion Detect
TCP
Route
NAT
HTTP
Load Balance
Store/Ret. State
iSCSI
Replace Fields
Error Detect
FCIP
Resize Pkt
Checksum
MPLS
Encrypt
Count/Tag
ATM
Compress
…?
…?
Classify
…?
Infer
Act
5
PNEs: The Big Picture

PNEs are a new technology and present many
new opportunities

We’re not exactly sure how they will be
deployed, or what they are useful for!

Nonetheless, the hardware cost is small and thus
adding network programmability is basically free
6
Network Appliances
Network Appliance NetCache
Packeteer PacketShaper
Localized content delivery platform
F5 Networks BIG-IP LoadBalancer
Web server load balancer
Traffic monitor and shaper
Ingrian i225
Cisco SN 5420
SSL offload appliance
IP-SAN storage gateway
NetScreen 500
Extreme Networks SummitPx1
Firewall and VPN
L2-L7 application switch
Nortel Alteon Switched Firewall
CheckPoint firewall and L7 switch
Cisco IDS 4250-XL
Intrusion detection system
The increasing push towards in-the-network processing
7
Motivation for PNEs

Network appliances are generally fixed-function devices


PNEs can consolidate functionality to reduce management costs
and rack space
PNEs can be reconfigured to support new applications
Firewall
IP Storage
Gateway
Intrusion
Detector
Server Load
Balancer
???
8
Motivation for PNEs (cont.)

PNEs offer the flexibility required to implement
distributed applications by composition
9
PNE Hardware

PNEs are enabled by silicon and technology advances


Fast-path computational power:



Processor arrays, network processors, configurable hardware
(e.g., FPGAs), specialized memories, custom ASIC accelerators,
fast and cheap storage
A modest PNE comprising an array of sixteen generic 1 GHz
processors can theoretically sustain nearly 32,000 instructions
per packet at 1 Gbit/sec (assuming 256-byte packets on average)
Network processors and custom hardware can vastly improve
this
The bottleneck: memory bandwidth and state retrieval
10
State retrieval and management



(insert picture showing a computation element
wishing to make a decision based on a large
amount of previously recorded data)
(insert picture showing shared, frequently
updated, frequently accessed resource)
(insert picture showing packet reordering and
head-of-line blocking)
11
PNE Placement

Where will PNEs reside in the network? We can
see applications for virtually anywhere…
Edge
Access
Core
Access
Edge
The data rate affects the achievable
complexity of PNE applications
12
Research Opportunities in PNEs

What makes an application suitable for PNEs? What are
their characteristics?

What about overlays?

What is the ideal programming model for a PNE? A
network of PNEs?

How do you efficiently handle local and distributed state?
(Is this a hardware issue, a software issue, or both?)

How do you quantify a PNE’s flexibility and reliability?
13
Applications Suitable for PNEs

Proposed properties of an application can benefit from the
programmability and flexibility of a PNE when:

the filtering or computation accesses nearly every bit in every
packet


the application is not fully general-purpose





The data rates overload a server architecture and computational tasks
overload a router
At least some part of the application has a classify-infer-act structure
the application has geographically distributed state that must be
quickly aggregated
a non-trivial conversion between protocols is required
past occurrences affect future filtering and computations on flows
the application changes over time
14
Programming PNEs

A good programming model is critical for writing highly reliable and
flexible applications

PNEs require a good programming model for both a single-PNE and
an ensemble of PNEs

Our basic single-PNE approach: create a router virtual machine and
program the machine. Apps can then be portable and platformindependent

Basic primitive: the generalized packet filter


Highly flexible and powerful operator
Uses “packet tags” to distribute state and implement control-flow
between virtual machine components
15
Virtual Machine Example
common configuration
exported VM
interface
PNE hardware
16
Our Current Testbed
10.0.0.100
eth0
windows1
10.0.0.101
169.229.48.246
eth1
eth0
client01
server1
10.0.0.102
10.0.0.1 eth0
eth0
10.0.0.103
ethernet 4/3
ethernet 4/2
VLAN 5
client02
eth0
ethernet 3/1
client03
10.0.0.127 / 24
ethernet 3/3
ethernet 3/7
eth0
VLAN 4
ethernet 4/8
“Private” Cluster
on 10.2.2.x
10.0.0.104
ethernet 3/5
Passport 10.10.140.1 / 24
clientserv04
10.2.2.104
eth1
Default VLAN (all ports)
10.2.2.1 / 24
Default VLAN (all ports)
10.10.140.200 / 24
default gw = 10.10.140.1
Accelar Switch
Alteon
10.2.2.105
10.2.2.106
10.2.2.107
10.2.2.108
eth1
10.10.140.3
client05
client06
client07
client08
iSD
17
Experimental Plan

Expand our testbed!

Measurement and monitoring: a key function of PNEs

In progress: prototype of the single-PNE programming model on
Linux

Experiment with apps that require distributed state

One possible test application: cooperative SAN-to-SAN cache
18
Overall Research Impact

Applications will be more reliable and efficient by taking
advantage of new network services

Per-flow and per-packet level processing and state
management will power new forms of measurement,
monitoring, and actuation

New understanding for how to manage state and
processing in distributed, programmable networks
19
Audience Q&A (1)

What are the key applications for programmable
networks and PNEs?

What new apps could make use of the
technology?
20
Audience Q&A (2)

What makes an application ammenable to implementation
in programmable networks? What parts run at the
endpoints, and what parts in the network?


Network appliances and proxy applications have enjoyed recent
success. “Build it and they will come”?
Is it something about the frequency of processing? Stateful
processing?






the filtering or computation accesses nearly every bit in every packet
the application is not fully general-purpose
the application has geographically distributed state that must be quickly
aggregated
a non-trivial conversion between protocols is required
past occurrences affect future filtering and computations on flows
the application changes over time
21
Audience Q&A (3)

What are the important security and trust issues in
programmable networks?


Remember, we are not advocating open, “instruction
in every packet” systems ala active networks of a few
years ago
Can a network of PNEs be shared between
(potentially competing) organizations?
22
Audience Q&A (4)

What is the best way to configure and manage an
ensemble of PNEs?

What are the most important issues in terms of
reliability? (E.g., graphically visualizing a
configuration?)
23