Ravel: A Database-Defined Network ∗ Anduo Wangy Xueyuan Mei{ Jason Croft{ Matthew Caesar{ Brighten Godfrey{ Temple Universityy University of Illinois at Urbana-Champaign { ABSTRACT Keywords SDN’s logically centralized control provides an insertion point for Software-Defined Networks; SQL Database; Views; Programming programming the network. While it is generally agreed that higher- Abstraction level abstractions are needed to make that programming easy, there is little consensus on what are the “right” abstractions. Indeed, as SDN moves beyond its initial specialized deployments to broader 1. INTRODUCTION use cases, it is likely that network control applications will require Software-defined networks employ APIs to control switch data diverse abstractions that evolve over time. planes via a logically centralized controller. This provides a plat- To this end, we champion a perspective that SDN control fun- form so that it is possible to write software that can control network- damentally revolves around data representation. We discard any wide behavior. To make that programming easy, it is generally application-specific structure that might be outgrown by new de- agreed that higher-level abstractions are needed, but there is lit- mands. Instead, we adopt a plain data representation of the en- tle consensus on what are the “right” abstractions. Frenetic [8], tire network — network topology, forwarding, and control appli- Pyretic [28], and NetCore [22] introduce functional constructs that cations — and seek a universal data language that allows applica- enable modular creation of SDN control. Flowlog [23] extends this tion programmers to transform the primitive representation into any functional abstraction to the data-plane by adding SQL-like rule high-level representations presented to applications or network op- constructs. FatTire [29] and Merlin [30] add additional language- erators. Driven by this insight, we present a system, Ravel, that level support for fault-tolerance and resource provisioning. On the implements an entire SDN network control infrastructure within a other hand, to address stateful middleboxes and service chains, Ki- standard SQL database. In Ravel, network abstractions take the netic [14] and PGA [27] raise the abstraction level by stacking a form of user-defined SQL views expressed by SQL queries that can new layer of abstractions in the form of state-automata and graph be added on the fly. A key challenge in realizing this approach is expressions. to orchestrate multiple simultaneous abstractions that collectively Indeed, as the network evolves over time, the need for abstrac- affect the same underlying data. To achieve this, Ravel enhances tions will likely outgrow the abstractions of the present, thus requir- the database with novel data integration mechanisms that merge ing continual “upgrade” that extends or raises the level of existing the multiple views into a coherent forwarding behavior. Moreover, abstraction. Each “upgrade” incurs the tremendous effort of careful Ravel is exposed to applications through the one simple, familiar design of a new abstraction and the engineering of the supporting and highly interoperable SQL interface. While this is an ambitious runtime. With the deployment of drastically different abstractions, long-term goal, our prototype built on the PostgreSQL database ex- the network will be jointly driven by multiple controls created with hibits promising performance even for large scale networks. disparate abstractions. Orchestration of these controls across many abstractions is thus needed. However, current approaches only offer a fragmented solution: higher-level coordination often depends on and is restricted to the use of certain abstractions [28, 27, 14], while Categories and Subject Descriptors abstraction-agnostic support depends on common structures (Open- C.2.1 [Network Architecture and Design]: Centralized networks; Flow rules, network state variables) that are usually low-level [21, C.2.3 [Network Operations]: Network management 32, 12]. To this end, we champion a perspective that SDN control fun- damentally revolves around data representation. We discard any ∗ The work was mostly done while at University of Illinois at application-specific structure that might be outgrown by new de- Urbana-Champaign. mands. Instead, we adopt a plain data representation of the en- tire network — network topology, forwarding, and control appli- cations — and seek a universal data language that allows applica- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed tion programmers to transform the primitive representation into any for profit or commercial advantage and that copies bear this notice and the full cita- high-level representations presented to applications or network op- tion on the first page. Copyrights for components of this work owned by others than erators. Driven by this insight, we present a system, Ravel, that ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- implements an entire SDN network control infrastructure within a publish, to post on servers or to redistribute to lists, requires prior specific permission standard SQL database. We take the entire SDN control system un- and/or a fee. Request permissions from [email protected]. der the hood of a standard SQL database, and rely on SQL for data SOSR’16, March 14–15, 2016, Santa Clara, CA. c 2016 ACM. ISBN 978-1-4503-4211-7/16/03 ...$15.00. manipulation, the database runtime for data mediation, and propose DOI: http://dx.doi.org/10.1145/2890955.2890970. a novel protocol that refines the database runtime to enforce only orchestrated execution. As a realization of this approach, Ravel of- ticipant that uses views to incorporate multiple high-level and low- fers the following attractive advantages: level abstractions of the network which are orchestrated online. In Ad-hoc programmable abstractions via database views. The other words, in Ravel, the database is the controller. database view construct enables new abstractions to be constructed While this is an ambitious long-term goal, our Ravel prototype ad-hoc and enables them to build on each other. For example, from built on the PostgreSQL database [26] exhibits promising perfor- the “base tables” defining the network topology and OpenFlow for- mance even for large scale networks. On various fat-tree (up to warding rules, one can construct a view representing a virtual net- 5,120 switches / 196,608 links) and ISP (up to 5,939 nodes / 16,520 work that spans a subset of the topology; and one can further de- links) topologies, we microbenchmark Ravel delay, uncovering rive a load balancer’s view of host availability within the virtual the source of database overhead, showing that the most relevant network. These SQL views form the structure of the abstractions; database operation (triggers) scales well to large networks. Orches- furthermore, integrity constraints over the views express high-level tration of various applications scales to large network and policy policy invariants and objectives. These views and constraints can be size. Ravel also integrates a classic view optimization algorithm expressed via SQL statements and can even be constructed ad-hoc, that accelerates view access by one to two orders of magnitude with i.e., dynamically in the running controller. a small maintenance overhead. Orchestration across abstractions via view mechanisms. Once 2. OVERVIEW we have a mechanism to construct ad-hoc abstractions, we need to coordinate across these multiple views of a single network. View maintenance [9] and update [2, 4, 7, 5, 13] mechanisms are the “runtime” for view abstractions, constructed through normal SQL notification operation operations (queries and updates). First, view maintenance continu- ously refreshes the view abstractions of a dynamic network. Sec- view view view lb acl rt lb acl rt ond, to translate updates in a derived view back down to a lower- view view level view, Ravel allows users to define a view update policy that 3 1 2 governs how updates on the higher-level abstraction are realized on SQL interface obs obs the underlying data-plane via triggers, which can incorporate cus- PostgreSQL runtime tom heuristics at runtime to optimize applications. Orchestration across applications via a data mediation proto- base tables cf, tp, rm cf, tp, rm col. In Ravel, an orchestration protocol mediates multiple applica- 4 tions whose database modifications affect each other. The proto- events control col assumes a simple conflict resolution strategy — an ordering of Network: link add-flow link add-flow view constraints where lower-ranked constraints yield to the higher- Mininet + POX up/down del-flow up/down del-flow ranked. Given a view update request as input, the protocol produces Figure 1: Ravel overview as output an orchestrated update set that respects all applications constraints (subject to conflict resolution). The orchestrated set may Figure 1 shows the main components of Ravel: the users, the append to the request additional updates for completion (e.g., by Ravel runtime, and the network. The network (bottom) is the ser- invoking a routing application when an access control application vices and resources being controlled. The users include network attempts to remove an unsafe path) or reject the update if a cohesive operators and a Ravel administrator that interact with the network update is not