Transcript Application-Aware-SDN - CSE Labs User Home Pages

NEWS: Network Function
Virtualization Enablement
within SDN Data Plane
Two Emerging Intertwined Trends
Reshaping the Networking Field

Software-Defined Networking
 Network Function Virtualization
Limitations of Current Networks
 Enterprise networks are difficult to manage
 ISPs are slow to deploy new services
• e.g., AT&T, Comcast need to quickly role out or scale
up video streaming services to compete with Netflix
Innovations at network edge and emergence of cloud
computing pose new management requirements
 “New control requirements have arisen”
• greater scale
• migration of virtual machines (VMs)
Both give rise to the newt trends: SDN & NFV
Limitations of Current Networks
Switches
4
http://www.excitingip.net/27/a-basic-enterprise-lan-network-architecture-block-diagram-and-components/
Dominance of Middle-Boxes
Berkeley study/survey of middleboxes
Software Defined Networking
Aiming at addressing the challenges in controlling
and managing networks
Basic question: how to to easily configure
(large) networks?
Different notions of what is SDN !

A broad view (conflated with the notion of NFV)
network functions are (virtualized and) implemented
primarily by software and orchestrated via software
control

We adopt a narrower (perhaps more researchfocused) view advocated by Scott Shenker
6
SDN: a Network Operating System
Basis premise: separating network control from
forwarding elements (the data plane), with
Three Key Abstractions:

Distributed State Abstraction

(Control) Specification Abstraction

Forwarding Abstraction
7
Idea: An OS for Networks
Software-Defined Networking (SDN)
Control
Programs
Control
Programs
Global Network View
Network Operating System
Control via
forwarding
interface
Protocols
Protocols
8
Network Function Virtualization
 Besides software switches, e.g., openVirtualSwitch (OVS)
• which implement the openflow forwarding abstraction
 Network function virtualization is more targeted at
virtualizing various special network functions
• currently implemented by various hardware middleboxes or
network appliances
 Examples of Middleboxes/Network Appliances:
•
•
•
•
•
NATs, Mobility/Location Servers
Firewall, IDS, IPS
(Application/Content-aware) Load Balancer
Web/Content Cache
…
NFV
SDN
Simply virtualizing hardware middleboxes as software
modules does not yield a “software-defined” network
 Each vNF may still have its own control logic & APIs,
manipulating packets in its own manner
 Configuring and orchestrating these virtualized network
functions (vNFs) no less a complex or difficult task!
SDN could potentially make it easier to chain various vNFs
together  service steering & service chaining
But: current SDN controllers (designed for openflow-based
data plane) only understand layer 2-4 semantics!
NFV and SDN: Challenges
public IP addresses
Firewall
private IP addresses
NAT
SDN Controller
Load Balancer
NFV into SDN: Challenges
Firewall Policy:
• limit # of TCP connections per IP prefix
• allow reverse-path traffic only if forward-path conn is established
public IP addresses
Firewall
private IP addresses
NAT
SDN Controller
Load Balancer
NFV and SDN: Challenges
Network Address Translation Configuration:
• IP & port rewrite (port # generated via hashing)
• keep track of available public IP & port
public IP addresses
Firewall
private IP addresses
NAT
SDN Controller
Load Balancer
NFV into SDN: Challenges
Layer-7 (Application-Aware) Load Balancer Policy:
• Assign server IP based on URL & server load
• Maintain connection state to support late binding
public IP addresses
Firewall
private IP addresses
NAT
SDN Controller
Load Balancer
NFV and SDN: Management Issues
 vNFs are isolated islands from the SDN
 Traffic must be re-routed to vNF entities
 Need two (separate) management/control planes
• SDN controller for switches & middlebox controllers for vNFs
 But two planes need to be “orchestrated” carefully to
work properly!
NFV and SDN: Decision Making
Issues
NAT
Public
Network
Layer-7 Load Balancer
Private
Network
• IP & port rewrite
• Assign server IP based on URL & server loads
• Keep track of available public IP & port • Maintain connection state to support late binding
• Need to maintain application layer state in the data path
• Need to access packet information beyond L2-L4 headers
• Modify packet headers based on its own logic unbeknownst to SDN
controller
 How does the SDN controller know what packets to feed to which
middleboxes?
 How does the SDN controller set up routing & traffic engineering
policies?
NFV and SDN: Decision Making Issues
public IP addresses
Firewall
private IP addresses
NAT
Load Balancer
Private IP addr
data pkt
TCP SYN
what to do?
where to forward it?
SDN Controller
Routing & Traffic Engineering:
how to set up paths to right servers
& load alance among multiple paths?
NFV and SDN: Decision Making
Issues
NAT
Public
Network
Private
Network
Layer-7 Load Balancer
• IP & port rewrite
• Keep track of available public IP & port • Assign server IP based on URL & server loads
• Maintain connection state to support late binding
• Need to maintain application layer state in the data path
• Need to access packet information beyond L2-4 header
• Modify packet headers based on its own logic unbeknownst to SDN
controller
Making NFV & SDN
Play Nice Together?
Can we extend the SDN data path to directly support vNFs
with one unified (& logically centralized)
control/management plane?
Incorporating NFV into SDN?
 A Naïve Solution: using SDN controller to implement
NFV processing logic
• Switch-Controller delay cause significant slowdown in
data path
• Control plane not designed to handle every packet 
throughput bottleneck
Our Solution: NEWS
NFV enablement
Within SDN data plane
• pure software-based platform
• based on OVS
• vNFs implemented as
dynamically loadable software
modules within OVS
•
•
•
•
No switch-controller delay
No inefficient traffic detouring
Uniform central control
Scale-out data plane
NEWS: Extending Open vSwitch
App 1
Design Choice: Where to intercept the
packet and implement application
processing logic ?
App 2
Controller
Option 1: connection manager
55
Connection
Manager
•
Pros: modular design
•
Cons: redundant coding, slow
14
OpenFlow API
User space
11
Unnecessary encap/decap
•
Redundant flow table
Option 2: user space flow table
13
12
•
•
Flow table
Pipeline
Good tradeoff between 1 & 3: easy
implementation & reasonable
performance
Option 3: kernel flow table
Kernel
Flow Table
Open vSwitch
•
Pros: best performance
•
Cons: hard to implement
NEWS: Open vSwitch Flow Processing
App 1
Controller app module
keeps global state
App 2
Controller
57
Connection
Manager
Dataplane app module
keeps local state
16
15
OpenFlow API
User space
16
12
11
13
Flow table
Pipeline
Kernel
Flow Table
Open vSwitch
App 2
App 1
14
App table
NEWS: App Table and App
Actions
Web traffic
to server x
#TCP conn < 1000
Send to server s1 or
s2 by using
hash(src_ip)
 SDN controller performs the following steps:
1. Loads firewall connection limit module
2. Load server selection module
3. Install app table rule: (dst_ip=x, tcp, dport=80:
fw, lb, fwd, install)
 SDN controller also pushes the s1 and s2 information using
OpenFlow messages.
Example: Firewall & Load Balancer
App table
Standard flow table
Flow
Action List
dst_ip=x, tcp, dport=80
fw, lb, fwd, install
Kernel flow table
Forwarding Rule
PACKET
src_ip=a,
sport=6000,
tcp,
dst_ip=x,
dport=80
nFlow = 998
nFlow = 999
break = false
(continue)
Meta data
Hash(a) = s1
src_ip=a, sport=6000, tcp, dst_ip=x, dport=80:
set dst_ip=s1, out port1
Interim Rule Cache
NEWS: Loadable App Actions
 The Apps are implemented as minimal C dynamic
libraries
 SDN controller dynamically loads/unloads Apps according
to chaining policies
 More OVS instances are spawned if load is high
 All apps implement the same interface
•
•
•
init 
initialize app state according to the available number
of threads
xlate_actions  updates the flow caches according to the NF
state
destroy  cleans internal state before unloading that module
NEWS: Advantages
 Placement of NFs
• We allow the controller to install application modules at
the switches using custom OpenFlow vendor
messages
 Chaining NFs
• Use logical chains instead of physical chains
 Scalable deployment
• Scalability and elasticity is achieved by dynamically
configuring the number switches supporting a specific
network service
 Dynamic Service Creation
• The SDN controller in NEWS is in charge of app
module activation at the switches.
Evaluation: NEWS vs. iptables
Firewall performance
with small flows (1KB)
Firewall performance
with large flows (10MB)
NEWS performance is very close to native Linux containers
Evaluation: NEWS vs. conntrack
Small (1KB) and medium (100KB)
flows latency
Large flows (10MB)
goodput
NEWS performance is very close to OVS conntrack and better in large
flows
Evaluation: Content-aware Server
Selection
Clients
C1
Back End
vSwitch
Image server
Front End
vSwitch
C2
Video server
• 3-way TCP handshake with client
• set server IP (DNAT)
 NEWS
• TCP handshake with server
• SNAT and TCP splicing for return traffic
• Return traffic does not have to go through front-end vSwitch
• Both front-end & back-end vSwitches can be scaled out independently
 HAProxy
• Front end vSwitch is replaced with a HAProxy load balancer
Evaluation: Content-aware Server
Selection
Flow completion time
Evaluation: Content-aware Server
Selection
CPU load at front switch
CPU load at back switch
Conclusions
 Two New Emerging Trends in Networking:
software-defined networking & network function virtualization
• What they are & why they are needed
• Challenges they pose
 NEWS: enabling NFV processing within the SDN
data-plane
• NEWS unifies NFV and network management using
one controller
• NEW by design enables scale out in high loads