GitFlow: Flow Revision Management for Software-Defined Networks∗ Abhishek Dwarakiy, Srini Seetharamanz, Sriram Natarajan?, and Tilman Wolfy yDepartment of Electrical and Computer Engineering, University of Massachusetts, Amherst, MA USA zInfinera Corporation, Sunnyvale CA USA ?Deutsche Telekom, Silicon Valley Innovation Center, Mountain View, CA USA ABSTRACT The most popular way to realize SDN has been to adopt Our work addresses the problem of revision control for devices that support a standardized application pro- flow state management in SDN-enabled networks, so gramming interface (API), for example OpenFlow [7], that the underlying data plane might be able to provide for programming network behavior in the data plane better state protection, provenance, ease of programma- through external software. This network programmabil- bility, and support for multiple applications. Inspired ity brings with it several challenges: migrating to new by the revision control tools in the software develop- architectures, interoperating with legacy networks, co- ment world, we propose an abstraction and a system ordinating control plane state in a centralized fashion, called GitFlow, which provides flow state revisioning supporting different authors to the state, and restricting in the SDN context. The core idea of GitFlow is to anomalous or malicious behaviors. run a repository server to maintain the authoritative While the aspect of multiple co-existing authors edit- copy of the flow configuration state and track additional ing flow state of a shared resource has been previously meta data for each evolving snapshot of the flow state. investigated [6, 8, 13, 17] from the perspective of con- When multiple applications make incremental commits flict detection or resource isolation, the issue of tracking to state, our system also automates conflict resolution all changes to the flow state has not yet been exam- by rebasing new flow state with committed flow state. ined sufficiently. In software development, this process of managing changes to shared data is referred to as We envision that our revision control abstraction will 1 provide safety in the data plane and better programma- revision control . We see a need for similar revision- bility in the control plane. ing and state change management rapidly manifesting in software-defined networks. Traditionally, revision control in the networking world General Terms has been limited to managing CLI configurations of data Design, Management plane devices. The state of the flows and the control plane, however, is inaccessible. In the context of an Categories and Subject Descriptors SDN-enabled network, we have access to much more state than was previously possible. Based on existing C.2.6 [Computer-Communication Networks]: software revision control techniques, we propose a sys- Internetworking|Routers; C.2.3 [Computer- tem called GitFlow that provides flow state revisioning Communication Networks]: Network Operations| in the SDN context. GitFlow underlies all flow-level Network Management state management that a switch undertakes, and pro- vides safety at the data plane and better programming 1. INTRODUCTION discipline in the control plane. Software-Defined Networking (SDN) offers an oppor- Additionally, our framework can be easily extended tunity to both the control and data planes of today's for several other purposes: tracking control plane evo- networks to become programmable and easily evolvable. lution (similar to past works on AS path evolution [2]); providing network level accountability (similar in moti- ∗ This work is based upon work supported by the Na- vation to past works on AIP [1] or packet provenance tional Science Foundation under Grant No. 1421448. [14]); preventing flow space conflicts across different au- Permission to make digital or hard copies of all or part of this work for personal or thors (without being as restrictive as the isolation efforts classroom use is granted without fee provided that copies are not made or distributed of FlowVisor [16] or overlap prevention of Frenetic [8]); for profit or commercial advantage and that copies bear this notice and the full cita- and extracting network state in a form conducive for tion on the first page. Copyrights for components of this work owned by others than automated troubleshooting (beyond methods made pos- ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- publish, to post on servers or to redistribute to lists, requires prior specific permission sible by header space analysis [5] and NDB [9]). This and/or a fee. Request permissions from [email protected]. 1 SOSR2015 June 17-18 2015, Santa Clara, CA, USA The popular revision control software git provides au- Copyright is held by the owner/author(s). Publication rights licensed to ACM. thor tracking, versioning and timestamping of changes, ACM 978-1-4503-3451-8/15/06..$15.00 immutability of past alterations, automated conflict res- http://dx.doi.org/10.1145/2774993.2775064. olution, and annotations. Table 1: State management requirements Characteristics State Requirements Decoupled network control Consistency Dynamicity in application Mutability Co-existing applications/authors Safety Network troubleshooting Provenance per. In the subsequent sections, we describe our state management system and illustrate its use through ex- amples. Figure 1: Programmability model in SDNs. 3. GITFLOW In this section, we discuss our proposal for state man- makes the GitFlow abstraction a vital part of any SDN agement to improve network programmability. programming workflow. In this paper, we investigate flow rule revisioning, so 3.1 State Management Abstraction that SDN-enabled networks can provide a higher level of The existence of multiple authors attempting to oper- provenance, security, ease of programmability and sup- ate on a shared resource (network state) dictates the fol- port for multiple applications. The remainder of this lowing requirements for concurrent access and account- paper is organized as follows. Section 2 describes the ability: model and design goals flow management in software- defined networks. In Section 3, we present our proposal • Author or application tracking: The system should inspired by the git version control system. In Section 4, possess the ability to exactly identify and report we illustrate applications of our GitFlow approach to the author that was responsible for the change of describe it better. Section 5 concludes the paper. network state. • Versioning and change tracking: Transformation 2. BACKGROUND and evolution of network state can be tracked, pro- Software-Defined Networking allows external network viding valuable information that can be used for applications to directly access the state of the data plane planning and provenance reasons. through well-defined APIs. The data plane device type • State safety: Preventing the alteration of network (virtual or physical), flow table types (e.g., VLAN ta- state that has been committed by a different au- ble, MAC table) and size, and supported feature set thor brings in safety that ensures deterministic (match fields and supported actions) vary depending on system behavior. It is, however, important to al- the deployment scenario (e.g., edge-gateways [11], wide- low the same author to alter actions for previously area networks [15]). Typically, the packet processing established match rule. functionality is achieved via a match-action pairs that • Conflict resolution and rebasing: The mutability span a multi-table pipeline. As the flow table evolves, requirement in statement management brings with through route updates, gratuitous ARP replies or new it a need to resolve conflicts or overlaps in flow tenants addition, multiple tables and their related at- space to a feasible extent. Rebasing is the process tributes (e.g., meters attached to each flows) may be of merging changes to an extent allowable by a updated or modified by different applications/authors. pre-specified policy, based on the level of conflict. All these characteristics have implications on the net- • Annotations: The applications or authors can also work state management. include comments or other metadata to be associ- A typical model of SDN solution is shown in Figure 1. ated with the change. One or more applications, either directly through the API or through an abstracted intent layer, edit the con- In the software development world, the above features figuration state in the data plane, e.g., the flow table. are commonly available in a revision control software, Correspondingly, the data plane exports to the external such as git [3]. By making an analogy between source applications certain operational state, e.g., statistics, code and network state, we envision that adopting a relevant for the programming logic. We adopt this lay- layer of revision control for managing network state be- ered, decoupled model as our SDN programming model. comes vital to the programmability of the network. Such decoupling of the control and data planes in the context of SDN can be challenging when it comes to 3.2 GitFlow Architecture managing network state. Thus, in this paper we only We architect the abstraction described above in a focus on the flow rule configuration state. Table 1 corre- manner similar to that used by git by adopting an \au- lates each of SDN's programmability characteristics to a thoritative" GitFlow server that keeps up-to-date state certain state management requirement. The safety and that has been committed and programmed onto the flow