UC Berkeley UC Berkeley Electronic Theses and Dissertations
Total Page:16
File Type:pdf, Size:1020Kb
UC Berkeley UC Berkeley Electronic Theses and Dissertations Title An Architecture for Network Function Virtualization Permalink https://escholarship.org/uc/item/3nc1g6q7 Author Lan, Chang Publication Date 2018 Peer reviewed|Thesis/dissertation eScholarship.org Powered by the California Digital Library University of California An Architecture for Network Function Virtualization by Chang Lan A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Sylvia Ratnasamy, Chair Professor Scott Shenker Professor Rhonda Righter Summer 2018 An Architecture for Network Function Virtualization Copyright 2018 by Chang Lan 1 Abstract An Architecture for Network Function Virtualization by Chang Lan Doctor of Philosophy in Computer Science University of California, Berkeley Professor Sylvia Ratnasamy, Chair Today’s networks provide more than connectivity. Network functions such as firewalls, caches, WAN optimizers play a crucial role in improving security and performance capabili- ties. Although network functions traditionally have been implemented as dedicated hardware middleboxes, a recent effort commonly referred to as Network Function Virtualization (NFV) promises to bring the advantages of cloud computing to network packet processing by moving network appliance functionality from proprietary hardware to software. However, while NFV has quickly gained remarkable momentum in the industry, accepted NFV approaches are merely replacing monolithic hardware with monolithic software. In this dissertation, we argue that current approaches to NFV are ill-suited to the original vision of NFV. Instead, NFV needs a framework that serves as a common runtime for network functions. We present E2 – an NFV framework that provides placement and elastic scaling with high-level network function composition interface. We further consider the privacy challenge of outsourcing NFV deployments in public clouds and present a functional cryptographic tech- nique for privacy-preserving packet classification. Finally, we discuss optimizing NF data-plane scheduling for performance guarantees. i To my family. ii Contents Contents ii List of Figures iv List of Tables vi 1 Introduction 1 2 Motivation: A Scale-Out Central Office 4 3 A Framework for Network Function Virtualization 6 3.1 Context and Assumptions ............................... 7 3.2 System Architecture .................................. 9 3.3 Data Plane ....................................... 12 3.4 Control Plane ...................................... 14 3.5 Prototype Implementation ............................... 19 3.6 Evaluation ....................................... 20 3.7 Conclusion ....................................... 27 4 Securely Outsourcing Network Functions to the Cloud 28 4.1 Overview ........................................ 31 4.2 Cryptographic Building Blocks ............................ 35 4.3 Enterprise Gateway .................................. 41 4.4 Middleboxes: Design & Implementation ....................... 46 4.5 Evaluation ....................................... 48 4.6 Related Work ...................................... 54 4.7 Sufficient Properties for Middleboxes ........................ 55 4.8 Formal Properties of PrefixMatch ........................... 57 5 Scheduling Network Function Dataplanes 59 5.1 Background ....................................... 61 5.2 Problem Definition & Approach ........................... 63 5.3 Design ......................................... 67 iii 5.4 Implementation .................................... 71 5.5 Evaluation ....................................... 74 5.6 Conclusion ....................................... 80 6 Conclusions and Future Work 81 6.1 Thoughts for the Future ................................ 81 Bibliography 83 iv List of Figures 3.1 An example pipeline. Input traffic is first sent to an IDS; traffic deemed safe by the IDS is passed to a Web Cache if it’s destined for TCP port 80 and to a Network Monitor otherwise. Traffic that the IDS finds unsafe is passed to a Traffic Normalizer; all traffic leaving the Traffic Normalizer or the Web Cache are also passed to the Network Monitor. ..................................... 9 3.2 The overall E2 system architecture. ........................... 11 3.3 Transformations of a PGraph (a) into an IGraph (b, c, d). 15 3.4 E2 converts edge annotations on an IGraph (a) into output ports (b) that the appli- cations write to, and then adds traffic filters that the E2D implements (c). 16 3.5 (a) Flows enter a single NF instance. (b) Migration avoidance partitions the range of Flow IDs and punts new flows to a new replica using the E2D. Existing flows are routed to the same instance. (c) Once enough flows expire, E2 installs steering rules in the switch. ........................................ 19 3.6 Comparison of CPU cycles for three DPI NFs, without and with bytestream vports. Both cases use the native API. .............................. 21 3.7 Comparison of CPU cycles between using URL metadata and a dedicated HTTP parser ............................................ 22 3.8 Maximum cluster throughput with different placement solutions, with two different PGraphs. .......................................... 24 3.9 Traffic load at the original and new NF instance with migration avoidance; original NF splits at 2s. ...................................... 24 3.10 Latency and bandwidth overheads of migration avoidance (the splitting phase is from 1.8s to 7.4s). ...................................... 25 3.11 E2 under dynamic workload. ............................... 26 3.12 Pipeline used for the evaluation ............................. 26 4.1 System architecture. APLOMB and NFV system setup with Embark encryption at the gateway. The arrows indicate traffic from the client to the server; the response traffic follows the reverse direction. ........................... 31 4.2 Example of packet flow through a few middleboxes. Red in bold indicates encrypted data. ............................................ 34 4.9 Access time per page against the number of concurrent connections at the proxy. 53 v 5.1 High-level abstraction of packet processing frameworks. 60 5.2 Hierarchical scheduler in BESS. ............................. 63 5.3 Example of dataplane scheduling problem. Module A classifies TC 1 and TC 2, which are processed by Module B and C respectively. Both traffic classes have the same input traffic rate. The SLO mandates that the ratio of CPU cycles spent on TC 1 to TC 2 is 3:1. ...................................... 65 5.4 Performance of different scheduling schemes in Figure 5.3. All of them enforce the SLOs, but Alpine outperforms both strawman schemes in terms of throughput and latency. ........................................... 65 5.5 Alpine work flow. ..................................... 71 5.6 Single-core: throughput, latency, and error. ....................... 76 5.7 Multi-core: throughput, latency, and error. ....................... 77 5.8 Aggregate throughput with increasing number of cycles per-packet. 78 5.9 Aggregate throughput and relative speedup with increasing pipeline complexity. 78 5.10 Optimization time with increasing pipeline complexity. 79 vi List of Tables 3.1 Latency and throughput between NFs on a single server using E2’s legacy vs. native API. Legacy NFs use the Linux raw socket interface. 21 3.2 Latency and throughput between NFs on a single server with and without metadata tags. ............................................. 22 4.2 PrefixMatch’s performance. ............................... 50 4.3 Middlebox throughput for an empirical workload. ................... 52 5.1 Terminology of Dataplane Frameworks. “Schedulable” column describes how the framework determines whether a module is schedulable or not: “Position" means it is determined by the module’s position in the graph; “Type" means that it is determined by the module type (e.g. queues). ...................... 62 5.2 Notation used in Section 5.3 ............................... 68 5.3 Processing cost of packet processing pipelines and Alpine’s speedup over Manual. 77 5.4 Optimization time for pipelines. ............................. 79 vii Acknowledgements My life at UC Berkeley as a graduate student in the past five years was truly amazing and invaluable, which never have been possible without the help of my professors, family, and friends. With profound gratitude, I would like to thank my advisor, Sylvia Ratnasamy, for her invaluable guidance, inspiring motivation, acute comments, and immense patience. Her ability to transform my stilted and raw thoughts into insightful storylines has always left me amazed. I am extremely grateful for her support. I would like to thank my dissertation committee and qualifying examination members Scott Shenker, Ion Stoica and Rhonda Righter for their valuable feedbacks during my qualifying exam and review of this dissertation. I greatly enjoyed working with Scott as his teaching assistant and learned a lot from his wisdom, hard work, and sincere humility. It was also my great fortune to have had the chance to work with Raluca Ada Popa. I have no formal training in security and cryptography, and I would not have been able to explore those topics without Raluca’s guidance. I have been fortunate to collaborate with many excellent individuals including Justine Sherry, Sangjin Han, Rishabh Poddar, Amin Tootoonchian, Aurojit Panda, Melvin Walls, Shoumik Palkar, Keon