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 4 Switches

Dominance of Middle-Boxes Berkeley study/survey of middleboxes

6 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 research- focused) view advocated by Scott Shenker

7 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

Idea: An OS for Networks Global Network View Protocols Control via forwarding interface Network Operating System Control Programs Software-Defined Networking (SDN) 8 Control Programs

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 Firewall Load Balancer SDN Controller NAT public IP addressesprivate IP addresses

NFV into SDN: Challenges Firewall Load Balancer SDN Controller NAT public IP addressesprivate IP addresses Firewall Policy: limit # of TCP connections per IP prefix allow reverse-path traffic only if forward-path conn is established

NFV and SDN: Challenges Firewall Load Balancer SDN Controller NAT public IP addressesprivate IP addresses Network Address Translation Configuration: IP & port rewrite (port # generated via hashing) keep track of available public IP & port

NFV into SDN: Challenges Firewall Load Balancer SDN Controller NAT public IP addressesprivate IP addresses Layer-7 (Application-Aware) Load Balancer Policy: Assign server IP based on URL & server load Maintain connection state to support late binding

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 Private Network Public Network IP & port rewrite Keep track of available public IP & port NAT Layer-7 Load Balancer 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-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 Firewall Load Balancer SDN Controller NAT public IP addressesprivate IP addresses TCP SYN what to do? Private IP addr where to forward it? Routing & Traffic Engineering: how to set up paths to right servers & load alance among multiple paths? data pkt

NFV and SDN: Decision Making Issues Private Network Public Network IP & port rewrite Keep track of available public IP & port NAT Layer-7 Load Balancer 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 OpenFlow API Connection Manager Flow table Pipeline Controller App 1 App 2 Kernel Flow Table User space Open vSwitch Design Choice: Where to intercept the packet and implement application processing logic ? Option 1: connection manager Pros: modular design Cons: redundant coding, slow Unnecessary encap/decap Redundant flow table Option 2: user space flow table Good tradeoff between 1 & 3: easy implementation & reasonable performance Option 3: kernel flow table Pros: best performance Cons: hard to implement

NEWS: Open vSwitch Flow Processing OpenFlow API Connection Manager Open vSwitch Flow table Pipeline App table App 1 App 2 Controller App 1 App 2 Kernel Flow Table Controller app module keeps global state Dataplane app module keeps local state User space

NEWS: App Table and App Actions Web traffic to server x  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. #TCP conn < 1000 Send to server s1 or s2 by using hash(src_ip)

Example: Firewall & Load Balancer FlowAction List dst_ip=x, tcp, dport=80fw, lb, fwd, install App table break = false (continue) Interim Rule Cache nFlow = 998 src_ip=a, sport=6000, tcp, dst_ip=x, dport=80: set dst_ip=s1 nFlow = 999 Hash(a) = s1 Meta data, out port1 Standard flow table PACKET src_ip=a, sport=6000, tcp, dst_ip=x, dport=80 Kernel flow table Forwarding Rule

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 Image server Front End vSwitch Back End vSwitch abc.com/img.jpg abc.com/video.mpg Video server C1 C2 3-way TCP handshake with client set server IP (DNAT) TCP handshake with server SNAT and TCP splicing for return traffic  NEWS 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