1. Slide 1/12 Network Function Virtualization and its Dependability Challenges Relevant papers: 1.Gember-Jacobson, Aaron, Raajay Viswanathan, Chaithan Prakash, Robert Grandl, Junaid Khalid, Sourav Das, and Aditya Akella. "OpenNF: Enabling innovation in network function control." ACM SIGCOMM Computer Communication Review 44, no. 4 (2015): 163-174. 2.Wu, Wenfei, Keqiang He, and Aditya Akella. "PerfSight: Performance Diagnosis for Software Dataplanes." In Proceedings of the 2015 ACM Conference on Internet Measurement Conference (IMC), pp. 409-421. ACM, 2015. 3.Li, Yong, and Min Chen. "Software-Defined Network Function Virtualization: A Survey." Access, IEEE 3 (2015): 2542-2553. 4.R. Mijumbi, J. Serrat, J. L. Gorricho, N. Bouten, F. De Turck and R. Boutaba, "Network Function Virtualization: State-of-the-Art and Research Challenges," in IEEE Communications Surveys & Tutorials, vol. 18, no. 1, pp. 236-262, Firstquarter 2016. Presented by: Saurabh Bagchi

2. Slide 2/12 What is Network Function Virtualization? Decouple physical network equipment from the functions that run on them –Example: A network function - such as a firewall - can be dispatched to run as plain software on a virtual environment This allows for the consolidation of many network equipment types onto high volume servers, switches and storage, which could be located in data centers Definition: Virtual Network Function (VNF): The self- contained piece of network functionality that can be packaged up as a software module and dispatched to run on a VM –Examples: Tunneling gateway devices, i.e., IPSec/SSL VPN gateways; Traffic analysis elements, e.g., Deep Packet Inspection; Application-level optimization devices, e.g., Content Delivery Network (CDNs)

3. Slide 3/12 NFV in Pictures

4. Slide 4/12 Business Case for NFV Big driver is Telcos (AT&T, Verizon, …) Promise is greater flexibility – no vendor lock-in Deploy new network services faster and cheaper Fundamentally changes how network services are provisioned –Decouples software from hardware: Field can move much faster, software to run on commodity hardware –Flexible network function deployment: Easily reassign and share the infrastructure resources, thus together, hardware and software, can perform different functions at various times; components can be instantiated at any NFV-enabled device in the network –Dynamic scaling: Scale VNF performance in response to actual traffic

5. Slide 5/12 Is this Old Wine in New Bottle? Oct 2012: Birth of NFV; White paper authored by the world’s leading telcos Nov 2012: European Telecommunications Standards Institute (ETSI) chosen as the standards body for NFV To stay up to date: http://www.etsi.org/technologies- clusters/technologies/nfv Nov 2013: 2 nd industry-wide white paper released Oct 2014: Latest industry-wide white paper released ETSI includes 245 individual companies, including 37 of the world’s major telcos Ingredients of old wine in this bottle: virtualization, containers, migration of VMs

6. Slide 6/12 Use Case of NFV (1/2) CPE = Customer Premises Equipment

7. Slide 7/12 Use Case of NFV (2/2) EPC is the core network for Long Term Evolution (LTE), the 4G cellular network standard

8. Slide 8/12 Different Planes in NFVs Network can be viewed logically as composed of three planes: control plane, application plane, and data plane.

9. Slide 9/12 Different Planes in NFV Application plane: Tenants interact with this, requesting (re)deployment of virtual private clusters. Control plane: Responds to tenant requests by computing suitable deployment policies, e.g., determining where VMs and middleboxes ought to be placed, instantiating virtual links between VMs and middleboxes, and computing the forwarding state configuration to determine how traffic traverses VMs/middleboxes and virtual links. Dataplane: This is where fast path actions are performed on the tenant’s traffic, to deliver network traffic between the appropriate end-points in each virtual cluster.

10. Slide 10/12 Data Plane Organization A simple user setup and the data plane organization needed to support it

11. Slide 11/12 Performance Problems Software data plane performance problems arise due to three causes 1.The offered load on a middlebox exceeds the capacity allocated to it: Bottlenecks may arise not just due to increased traffic volume but also due to sudden, unexpected changes in the traffic profile 2.Multiple elements contend for a shared resource, and their requirements exceed the available resource capacity: Contetion happens in the virtualization stack 3.Design and implementation defects that lead to inefficient computation: Several bugs related to upgrades

12. Slide 12/12 Discussion Points What kinds of middlebox functionality are suitable for virtual network functions? –They cannot be too latency critical –There must be use cases where the demands on these services fluctuate What are the performance issues separate from general computing systems or general networks? –Distributed software on the data and control plane that needs to handle updates –Going up and down the layers of the virtualization stack has to be done in a latency sensitive manner What are the performance debugging techniques separate from general computing systems or general networks?