1 The Computer is the Network: The Emergence of Programmable Network Elements Randy H. Katz Computer...
-
date post
19-Dec-2015 -
Category
Documents
-
view
217 -
download
0
Transcript of 1 The Computer is the Network: The Emergence of Programmable Network Elements Randy H. Katz Computer...
1
The Computer is the Network:The Emergence of
Programmable Network Elements
Randy H. KatzComputer Science Division
Electrical Engineering and Computer Science DepartmentUniversity of California, Berkeley
Berkeley, CA 94720-1776
4
Edge Network
WideArea
Network
ServerServer
ServerServer
Managing Edge Network Services and Applications
• Not shrink wrap software—but cascaded “appliances”• Data Center in-a-box blade servers, network storage• Brittle to traffic surges and shifts, yielding network
disruption
FirewallIDSTrafficShaper
EgressChecker
LoadBalancer
Blades
Edge Network Middleboxes
5
Appliances Proliferate:Management Nightmare!
F5 Networks BIG-IP LoadBalancerWeb server load balancer
Packeteer PacketShaperTraffic monitor and shaper
Ingrian i225SSL offload appliance
Network Appliance NetCacheLocalized content delivery platform
Nortel Alteon Switched FirewallCheckPoint firewall and L7 switch
Cisco IDS 4250-XLIntrusion detection system
Cisco SN 5420IP-SAN storage gateway
Extreme Networks SummitPx1L2-L7 application switch
NetScreen 500Firewall and VPN
6
Network Support for Tiered Applications
LAN LAN LAN WideArea
Network
ServerAppTier
EgressChecker
ServerServerWebTier
ServerServer
ServerDatabaseTier
Firewall
LoadBalancer
Datacenter Network(s)
Unified LAN
WideArea
Network
ServerServer
ServerServerson
Demand
LoadBalancer
+Firewall
+Egress
CheckerBlades
ServerServer
ServerServerson
DemandConfigure servers, storage, connectivitynet functionality as needed
7
“The Computer is the Network”
• Emergence of Programmable Network Elements– Network components where net services/applications execute– Virtualization (hosts, storage, nets) and flow filtering (blocking,
delaying)
• Computation-in-the-Network is NOT Unlimited– Packet handling complexity limited by latency/processing
overhead– NOT arbitrary per packet programming (aka active networking)– Allocate general computation like proxies to network blades
• Beyond Per Packet Processing: Network Flows– Managing/configuring network for performance and resilience– Adaptation based on Observe (Monitor), Analyze (Detect,
Diagnose), Act (Redirect, Reallocate, Balance, Throttle)
8
Key Technical Challenge: Network Reliability
• Berkeley Campus Network– Unanticipated traffic surges render the network
unmanageable (and may cause routers to fail)– Denial of service attacks, latest worm, or the newest file
sharing protocol largely indistinguishable– In-band control channel is starved, making it difficult to
manage and recover the network
• Berkeley EECS Department Network (12/04)– Suspected denial-of-service attack against DNS– Poorly implemented/configured spam appliance adds to
DNS overload– Traffic surges render it impossible to access Web or
mount file systems
• Network problems contribute to brittleness of distributed systems
11
Vision• Better network management of
services/applications to achieve good performance and resilience even in the face of network stress
– Self-aware network environment– Observing and responding to traffic changes– While sustaining the ability to control the network
• Packet flow manipulations at L4-L7 made possible by new programmable network elements
• New service building blocks– Flow extraction– Packet annotation– Packet translation– Resource management
12
Generic Network Element Architecture
InterconnectionFabric
Inp
ut
Port
s
Outp
ut
Port
s
Buffers
Buffers
Buffers
“Tag”Mem
CPCPCPAP
ActionProcessor
CPCPCPCP
ClassificationProcessor
Rules &Programs
13
SoftwareRouter
Linux-based,Click, etc.
HardwareAssist for
GeneralizedInspection
TCAMFPGAState
Machine
“Basic” RouterForwarding,IP Filtering
Edge
Core
Extended RouterDeeper Inspection
Generalized Actions
SAN, FW, IDS,Traffic Shaper,L7 Switch, …
NetApps
PacketProcessingSoftware
NPUs,Blade
s
RouterVM Generalized Filteringand Composition
cPredicates Packet/Flow Segregation
OASIS Framework
Applications Network Service Protection
ControlPlane
A-Layer+
EventManager
14
E.g., Application-Specific QoSfor Three-Tier Systems
• Composable building blocks to build web services– Web containers, various app/ejb containers, persistent state via
automatically managed DB pools
• Problem: Open control loop/requests driven by users– Flash traffic, increased workload can overload components of
the web service– Hard to provision; hard to make performance guarantees;
seemingly broken behavior to the end user
• TrafficOperation Classification– Ants: Lightweight processing, touch few components– Elephants: Heavyweight processing, cross-layer, many
components– Hard to distinguish statically, but can be determined through
statistical techniques– Correlate request patterns with measured system parameters
(web + db CPU, disk activity, OS process switches, etc.) to identify elephants vs. ants
15
Identifying RuBIS Elephant Flows for Admission Control/QoS
SLOWDOWN
NoNetworkVisibility
Servers
/dbLookup.php SLOWDOWN
/storeBid.php
/lightRequest.php
/lightRequest.php
HTTPHeaderVisibility
Servers
16
Request Time Distribution with
Preferential Scheduling
stock adm controltotal requests 756137 1143264correlated URLs 112521 105964req/sec (avg) 462 782session time (avg) 670 872max request time 154.7 32.7
Blocking phenomenonSession time goes upBut worst case goes way down
Uncontrolled Controlled
18
RouterVM
• High-level specification environment for describing packet processing
• Virtualized: abstracted view of underlying hardware resources of target PNEs
– Portable across diverse architectures– Simulate before deployment
• Services, policies, and standard routing functions managed thru composed packet filters
– Generalized packet filter: trigger + action bundle, cascaded, allows new services and policies to be implemented / configured thru GUI
– New services can be implemented without new code through library building blocks
Mel Tsai
19
QoS ModuleQoS ModuleL2 Switching
Engine w/ ARP
L2 SwitchingEngine w/ ARP
IP Router Engine
IP Router Engine
ControlProcessor
ControlProcessor
Packet filter 1
Packet filter 2
Packet filter n
Default filter
EthernetPort
QoS ModuleQoS Module
Backp
laneBackp
lane
L2 SwitchingEngine w/ ARP
L2 SwitchingEngine w/ ARP
IP Router Engine
IP Router Engine
Packet filter 1
Packet filter 2
Packet filter n
Default filter
EthernetPort
ComputeEngine
ComputeEngine
ComputeEngine
Extended Router Architecture• Virtualized components representative of a
“common” router implementation• Structure independent of particular hardware
Virtual line card instantiated for every
port required by application
Virtual backplane shuttles packets between line cards
CPU handles routing protocols & mgmt tasks
Compute engines perform complex, high-latency processing on flows
Blue “standard” components
Yellow components added & configured per-application
Filters are key to flexibility
Mel Tsai
20
Generalized Packet Filters
• Key to flexibility– Extend router “filter” concept– Small # of GPF building blocks yield
large number of apps» Compose/parameterize filters» No code writing
– Supports flexible classification, computation, and actions
– Executed in numeric order– How “complete” is this
formalization?
• Examples:– Traffic shaping and monitoring– L7 traffic detection
(Kazaa, HTTP, AIM, POP3, etc.)– QoS and packet scheduling– NAT– Intrusion detection– Protocol conversion (e.g. IPv6)– Content caching– Load balancing– Router/server health monitoring– Storage– Fibre Channel to IP– iSCSI– XML preprocessing– TCP offload (TOE)– Mobile host management, 802.11– Encryption/compression. VPNs– Multicast, Overlays, DHTs
L2 SwitchingEngine w/ARPL2 SwitchingEngine w/ARP
Packet filter 1
Packet filter 2
Packet filter n
Default filter
Mel Tsai
21
GPF Example
Back
pla
ne
Back
pla
ne
ControlProcessor
ControlProcessor
QoS ModuleQoS Module
L2 SwitchingEngine w/ARP
L2 SwitchingEngine w/ARP
IP Router Engine
IP Router Engine
GPF 5:
SLB
GPF 10:
P2P…
Servers
To Clients
A Server Load Balancer and L7 Traffic Detector
10.0.0.1
10.0.0.2
Ext. IP = 24.0.5.6
10.35.x.x
22
GPF Example
Back
pla
ne
Back
pla
ne
ControlProcessor
ControlProcessor
QoS ModuleQoS Module
L2 SwitchingEngine w/ARP
L2 SwitchingEngine w/ARP
IP Router Engine
IP Router Engine
GPF 5:
SLB
GPF 10:
P2P…
Servers
To Clients
A Server Load Balancer and L7 Traffic Detector
10.0.0.1
10.0.0.2
Ext. IP = 24.0.5.6
GPF 5 Setup
name -algorithm -
flowid -sip -
smask - dip -
dmask - proto -
action1 -action2 -action3 -
Server Load Balancerequal flowssip, sportanyany24.0.5.6255.255.255.255udp, tcpslb nat 10.0.0.1, 10.0.0.2log connections, file = log.txttag “skip Yahoo Messenger Filter”
10.35.x.x
23
GPF Example
Back
pla
ne
Back
pla
ne
ControlProcessor
ControlProcessor
QoS ModuleQoS Module
L2 SwitchingEngine w/ARP
L2 SwitchingEngine w/ARP
IP Router Engine
IP Router Engine
GPF 5:
SLB
GPF 10:
P2P…
Servers
To Clients
A Server Load Balancer and L7 Traffic Detector
10.0.0.1
10.0.0.2
Ext. IP = 24.0.5.6
GPF 10 Setup
name - type -
pattern -
timeout - flowid -
sip - smask -
dip - dmask -
proto - action1 -
action2 -
Yahoo Messenger Filteryahoomessenger^(ymsg|ypns|yhoo).?.?.?.?.?.?.?(w|t).*\xc0\x8010 minsip, dip, sport, dportanyany10.35.0.0255.255.0.0tcplimit 1 kbpsemail root 10.35.x.x
24
GPF “Fill-in” Specification
“Packet filter” as high-level, programmable building-block
for network appliance apps
FILTER 19 SETUP
NAME - SIP -
SMASK - DIP -
DMASK -PROTO -
SRC PORT -DST PORT -
VLAN - ACTION -
exampleany255.255.255.25510.0.0.0255.255.255.0tcp,udpany80defaultdrop
ClassificationParameters
Action
Traditional Filter
RouterVM Generalized Packet Filter (type L7)
26
GPF Action Language
• Basic set of assignments, evaluations, expressions, control-flow operators, and “physical” actions on packets/flows– Control-flow: If-then-else, if-not– Evaluation: ==, <=, >=, !=– Packet flow control: Allow, unallow, drop, skip filter, jump filter– Packet manipulation: Field rewriting (ip_src == blah,
tcp_src = blah), truncation, header additions– Actions: NAT, loadbalance, ratelimit, (perhaps others)– Meta actions: packet generation, logging, statistics gathering
• Higher level of abstraction than C/C++ or packet processing language
27
Implemented GPF Libraries
• Basic Filter– Simple L2-L4 header classifications– Any RouterVM actions
• L7 Filter– Adds regular expressions, TCP termination, ADU reconstruction
• NAT Filter– Adds a few more capabilities beyond the simple NAT action that is
available to all GPFs
• Content Caching– Builds on the L7 filter functionality
• WAN Link Compression– Relatively simple to specify, but requires lots of computation
• IP-to-FC Gateway– Requires its own table format & processing
• XML Preprocessing– Not very well documented, and difficulty is unknown…
28
GPF Expressiveness Analysis
Expressiveness at the app layers depends on thebreadth of GPF library and GPFs for specific apps
29
GPF Performance: Complex Filters
L2-L4 Headers “Retreat” 25 bytes of char ‘X’ “Retreat” 25 bytes of char ‘X’ “Retreat” Padding with ‘X’
Lesson: try to use start-of-buffer
indicators ^ and avoid *’s…
Many apps can be identified with simple start-of-
buffer expressions
Regex involves payload copying, which might be
avoidable
31
Observations and Motivations
• Internet reasonably robust to point problems like link and router failures (“fail stop”)
• Successfully operates under a wide range of loading conditions and over diverse technologies
• During 9/11/01, Internet worked reasonable well, under heavy traffic conditions and with some major facilities failures in Lower Manhattan
32
Why and How Networks Fail
• Complex phenomenology of failure• Recent Berkeley experience suggests that traffic
surges render enterprise networks unusable• Indirect effects of DoS traffic on network
infrastructure: role of unexpected traffic patterns– Cisco Express Forwarding: random IP addresses flood route
cache forcing all traffic to go through router slow path—high CPU utilization yields inability to manage router table updates
– Route Summarization: powerful misconfigured peer overwhelms weaker peer with too many router table entries
– SNMP DoS attack: overwhelm SNMP ports on routers– DNS attack: response-response loops in DNS queries generate
traffic overload
34
Check
• Checkable Protocols: Maintain invariants and techniques for checking and enforcing protocols
– Listen & Whisper: well-formed BGP behavior– Traffic Rate Control: Self-Verifiable Core Stateless Fair
Queuing (SV-CSFQ)
• Existing work requires changes to protocol end points or routers on the path
– Difficult to retrofit checkability to existing protocols without embedded processing in PNEs
– Building blocks for new protocols » Observable protocol behavior» Cryptographic techniques» Statistical methods
35
Protect
• Protect Crucial Services– Minimize and mitigate effects of attacks and traffic
surges– Classify traffic into good, bad, and ugly (suspicious)
» Good: standing patterns and operator-tunable policies
» Bad: evolves faster, harder to characterize» Ugly: that which cannot immediately be determined
as good or bad– Filter the bad, slow the suspicious, maintain resources
for the good (e.g., control traffic)» Sufficient to reduce false positives» Some suspicious-looking good traffic may be slowed
down, but won’t be blocked
36
Observe
• Observation (and Action) Points– Network points where control is exercised, traffic
classified, resources allocated– Routers + End Hosts + Inspection-and-Action Boxes
(iBoxes)» Prototyped on commercial PNEs» Placed at Internet and Server edges of enterprise
net» Cascaded with existing routers to extend their
functionality
37
iBox Placement for Observation and Action
AccessTier
AccessTier
AccessTier
R R
R R
I nternet orWAN Edge
RDistribution
Tier
I
EE
EE
EE
EE
EE
EE
UserEnd Hosts
ServerEnd Hosts
Network ServicesEnd Hosts
I
I
I R I
R
iBoxes strategically placed near entry/exit points within the Enterprise network
38
Annotation Layer:Between Routing and
Transport
• Marking vs. rewriting approach– E.g., mark packets as internally vs. externally sourced using
IP header options
• Prioritize internal vs. external access to services solves some but not all traffic surge problems
iBoxBoundaryRouter
NetworkServices
iBoxI nternalRouter
Enterprise Network
External Traffi c
I nternal Traffi c
Packet
PacketLabel PacketLabel
PacketLabel
Action: Markpackets
Detect load and trigger action: Slow traffi c with “external” labels
39
Annotation Layer:iBox Piggybacked Control
Plane• Problem: Control plane starvation• Use A-layer for iBox-to-iBox communication
– Passively piggyback on existing flows– “Busy” parts of network have lots of control plane b/w– Actively inject control packets to less active parts– Embedded control info authenticated and sent
redundantly– Priority given to packets w/control when net under stress
• Network monitoring and statistics collection and dissemination subsystem currently being designed and prototyped
40
Observe and Protect
iBoxes implemented on commercial PNEs
– Don’t: route or implement (full) protocol stacks
– Do: protect routers and shield network services
» Classify packets» Extract flows» Redirect traffic» Log, count, collect stats» Filter/shape traffic
43
OASIS
• Processing-in-the-Network is real– Networking plus processing in switched and routed
infrastructures– Configuration and management of packet processing
cast onto programmable network elements (network appliances and blades)
• Unifying Framework– Methods to specify functionality and processing
» RouterVM: Filtering, Redirecting, Transformation » cPredicates: Control extraction and execution
based on packet applications content
• Application-specific network processing based on session extraction
44
COPS
• PNEs: foundation of a pervasive infrastructure for observation and action at the network level
– iBoxes Observation and Action points– Annotation Layer for marking and control
• Check-Observe-Protect paradigm for protecting critical resources when network is under stress
• Functionality eventually migrates into future generations of routers
– E.g., Blades embedded in routers