1. 15-744: Computer Networking
L-11 Middleboxes and NFV

2. Middleboxes and NFV Overview of NFV Challenge of middleboxes
Middlebox consolidation
Outsourcing middlebox functionality
Readings:
Network Functions Virtualization White Paper
Design and Implementation of a Consolidated Middlebox Architecture
Optional reading
Making Middleboxes Someone Else’s Problem

3. Outline
NFV Motivation
NFV challenges

4. Network “101” vs. Reality Reality: Lots of in-network processing
Traditional view: “Dumb” network
application gateways
Reality: Lots of in-network processing
Appliances or Middleboxes: IDS, Firewall, Proxies, Load balancers….

5. Need for Network Evolution
New applications
Evolving
threats
Policy
constraints
Performance, Security,
Compliance
New devices

6. Middleboxes Galore! Data from a large enterprise
Survey across 57 network operators
Type of appliance
Number
Firewalls
166
NIDS
127
Media gateways
110
Load balancers 67
Proxies 66
VPN gateways 45
WAN Optimizers 44
Voice gateways 11
Total Middleboxes
636
Total routers
~900
APLOMB (SIGCOMM’13)

7. Key “pain points”  Narrow interfaces Specialized boxes
Management
Management
Narrow
interfaces
Specialized
boxes
Increases capital expenses & sprawl
Increases operating expenses
Limits extensibility and flexibility
“Point”
solutions! 

8. Middlebox management is hard!
Middleboxes are widely used today to meet security, performance and compliance requirements. Even though they are a critical piece of the network infrastructure, there are expensive, complex and difficult to manage. A survey across 57 network operators showed that middlebox management is complex as significant manual effort is required for configuring them, as a result middleboxes are prone to failures due to misconfiguration and overload.
Critical for security, performance, compliance
But expensive, complex and difficult to manage

9. Vision Why cant networking get same benefits as IT and cloud world?
Commodity hardware?
Virtualization?
Consolidation

10. Network Functions Virtualisation

11. Key idea: Consolidation
Two levels corresponding to two sources of inefficiency
Network-wide
Controller
2. Consolidate
Management
1. Consolidate
Platform

12. What are the grand challenges?
High performance virtual appliances?
Isolation/coexistence
Management solutions
Fault tolerance
Vendor independence/multi-vendor

13. What’s missing? What functions yield most benefits?
Can it really replace hardware acceleration?
Is virtualization necessary?
What novel services can be developed?
How much benefit is “enough” to motivate adoption?

14. Consolidation at Platform-Level
Today: Independent, specialized boxes
AppFilter
Proxy
Firewall
IDS/IPS
Decouple
Hardware and
Software
Commodity hardware:
e.g., PacketShader, RouteBricks,
ServerSwitch, SwitchBlade
Consolidation reduces capital expenses and sprawl

15. Consolidation reduces CapEx
Multiplexing benefit = Max_of_TotalUtilization /
Sum_of_MaxUtilizations

16. Consolidation Enables Extensibility
VPN Web Mail IDS Proxy
Firewall
Protocol Parsers
Session Management
Contribution of reusable modules: 30 – 80 %

17. Management consolidation enables flexible resource allocation
Today: All processing at logical “ingress”
Process (0.4 P)
Process (P)
Process (0.3 P)
Simplify this slide!
Process (0.3 P) N3 N1
Overload!
P: N1 N3 N2
Network-wide distribution reduces load imbalance

18. Can NFV/SDN help middlebox management?
Centralized Controller
Firewall
IDS
Proxy
Web
OpenFlow
“Flow”
FwdAction …
“Flow”
FwdAction …
Proxy
IDS …
Necessity and an Opportunity:
Incorporate functions markets views as important

19. SDN vs NFV Complementary SDN is all about “control” plane
NFV can happen w/o SDN
Natural allies
SDN enables orchestration, routing
NFV can be the “substrate” over which SDN runs

20. CoMb System Overview
Network-wide
Controller
Logically centralized
e.g., NOX, 4D
General-purpose hardware:
e.g., PacketShader,
RouteBricks, ServerSwitch,
Middleboxes: complex, heterogeneous, new opportunities

21. CoMb Management Layer Goal: Balance load across network.
Leverage multiplexing, reuse, distribution
Policy
Constraints
Resource
Requirements
Routing,
Traffic
Network-wide
Controller
Processing
responsibilities

22. Capturing Reuse with HyperApps
HTTP:
1+2 unit of CPU
1+3 units of mem
HyperApp: find the union of apps to run
CPU
HTTP: IDS & Proxy 4 3
Memory
HTTP
UDP
HTTP
NFS
IDS
Proxy 2
UDP: IDS
NFS: Proxy 1 3 4
CPU
Memory 3 1 1
common
CPU
Memory
Footprint on
resource
Need per-packet
policy dependencies!
Policy dependency are implicit

23. Modeling Processing Coverage
HTTP: Run IDS  Proxy
IDS  Proxy
0.4
IDS  Proxy
0.3
IDS  Proxy
0.3
HTTP
N1  N3 N1 N2 N3
What fraction of traffic of class HTTP from N1 to N3
should each node process?

24. Network-wide Optimization
Minimize Maximum Load, Subject to
Processing coverage for each class of traffic
 Fraction of processed traffic adds up to 1
No explicit
Dependency
Policy
Load on each node
 sum over HyperApp responsibilities per-path

25. Network-wide Optimization
A simple, tractable linear program
Very close (< 0.1%) to theoretical optimal

26. CoMb Platform Applications Policy Enforcer IDS Proxy NIC
Challenges:
Performance
Parallelize
Isolation …
Core1 …
Core4
Challenges:
Lightweight
Parallelize
Policy Enforcer
Policy Shim (Pshim)
IDS Proxy
NIC
Challenges:
No contention
Fast classification
Classification:
HTTP
Traffic

27. Parallelizing Application Instances✔
App-per-core
HyperApp-per-core M2 M3
PShim M1
Core1
Core2 M1 M2 M3
Core1
Core2
Core3
PShim
PShim
Inter-core communication
More work for PShim
+ No in-core context switch
+ Keeps structures core-local
+ Better for reuse
- But incurs context-switch
HyperApp-per-core is better or comparable
Contention does not seem to matter!

28. Discussion Changes traditional vendor business Isolation
Already happening (e.g., “virtual appliances”)
Benefits imply someone will do it!
May already have extensible stacks internally!
Isolation
Current: rely on process-level isolation
Get reuse-despite-isolation?

29. Conclusions Network evolution occurs via middleboxes
Today: Narrow “point” solutions
High CapEx, OpEx, and device sprawl
Inflexible, difficult to extend
Our proposal: Consolidated architecture
Reduces CapEx, OpEx, and device sprawl
Extensible, general-purpose
More opportunities
Isolation
APIs (H/W—Apps, Management—Apps, App Stack)

30. Can we outsource all middleboxes?
Firewalls
IDSes
Load Balancers
VPNs
Proxy/Caches
WAN Optimizers ✔ ✔ ✔ ✔
✗ Bandwidth?
✗ Compression?

31. Next Lecture Data Center Networks 1 Readings: Portland: Read in full
VL2: Read intro