Arbitrary Packet Matching in OpenFlow

OpenFlow has emerged as the de facto control protocol to implement Software-Defined Networking (SDN). In its current form, the protocol specifies a set of fields on which it matches packets to perform actions, such as forwarding, discarding or modifying specific protocol header fields at a switch. The number of match fields has increased with every version of the protocol to extend matching capabilities, however, it is still not flexible enough to match on arbitrary packet fields which limits innovation and new protocol development with OpenFlow. In this paper, we argue that a fully flexible match structure is superior to continuously extending the number of fields to match upon. We use Berkeley Packet Filters (BPF) for packet classification to provide a protocol-independent, flexible alternative to today’s OpenFlow fixed match fields. We have implemented a prototype system and evaluated the performance of the proposed match scheme, with a focus on the time it takes to execute and the memory required to store different match filter specifications. Our prototype implementation demonstrates that line-rate arbitrary packet classification can be achieved with complex BPF programs

Dataplane Specialization for High-performance OpenFlow Software Switching

OpenFlow is an amazingly expressive dataplane program- ming language, but this expressiveness comes at a severe performance price as switches must do excessive packet clas- sification in the fast path. The prevalent OpenFlow software switch architecture is therefore built on flow caching, but this imposes intricate limitations on the workloads that can be supported efficiently and may even open the door to mali- cious cache overflow attacks. In this paper we argue that in- stead of enforcing the same universal flow cache semantics to all OpenFlow applications and optimize for the common case, a switch should rather automatically specialize its dat- aplane piecemeal with respect to the configured workload. We introduce ES WITCH , a novel switch architecture that uses on-the-fly template-based code generation to compile any OpenFlow pipeline into efficient machine code, which can then be readily used as fast path. We present a proof- of-concept prototype and we demonstrate on illustrative use cases that ES WITCH yields a simpler architecture, superior packet processing speed, improved latency and CPU scala- bility, and predictable performance. Our prototype can eas- ily scale beyond 100 Gbps on a single Intel blade even with complex OpenFlow pipelines

BPFabric: Data Plane Programmability for Software Defined Networks

In its current form, OpenFlow, the de facto implementation of SDN, separates the network’s control and data planes allowing a central controller to alter the matchaction pipeline using a limited set of fields and actions. To support new protocols, forwarding logic, telemetry, monitoring or even middlebox-like functions the currently available programmability in SDN is insufficient. In this paper, we introduce BPFabric, a platform, protocol, and language-independent architecture to centrally program and monitor the data plane. BPFabric leverages eBPF, a platform and protocol independent instruction set to define the packet processing and forwarding functionality of the data plane. We introduce a control plane API that allows data plane functions to be deployed onthe-fly, reporting events of interest and exposing network internal state. We present a raw socket and DPDK implementation of the design, the former for large-scale experimentation using environment such as Mininet and the latter for high-performance low-latency deployments. We show through examples that functions unrealisable in OpenFlow can leverage this flexibility while achieving similar or better performance to today’s static design

Programming Protocol-Independent Packet Processors

P4 is a high-level language for programming protocol-independent packet processors. P4 works in conjunction with SDN control protocols like OpenFlow. In its current form, OpenFlow explicitly specifies protocol headers on which it operates. This set has grown from 12 to 41 fields in a few years, increasing the complexity of the specification while still not providing the flexibility to add new headers. In this paper we propose P4 as a strawman proposal for how OpenFlow should evolve in the future. We have three goals: (1) Reconfigurability in the field: Programmers should be able to change the way switches process packets once they are deployed. (2) Protocol independence: Switches should not be tied to any specific network protocols. (3) Target independence: Programmers should be able to describe packet-processing functionality independently of the specifics of the underlying hardware. As an example, we describe how to use P4 to configure a switch to add a new hierarchical label

On Diagnosis of Forwarding Plane via Static Forwarding Rules in Software Defined Networks

Software Defined Networks (SDN) decouple the forwarding and control planes from each other. The control plane is assumed to have a global knowledge of the underlying physical and/or logical network topology so that it can monitor, abstract and control the forwarding plane. In our paper, we present solutions that install an optimal or near-optimal (i.e., within 14% of the optimal) number of static forwarding rules on switches/routers so that any controller can verify the topology connectivity and detect/locate link failures at data plane speeds without relying on state updates from other controllers. Our upper bounds on performance indicate that sub-second link failure localization is possible even at data-center scale networks. For networks with hundreds or few thousand links, tens of milliseconds of latency is achievable.Comment: Submitted to Infocom'14, 9 page

Traffic Management Applications for Stateful SDN Data Plane

The successful OpenFlow approach to Software Defined Networking (SDN) allows network programmability through a central controller able to orchestrate a set of dumb switches. However, the simple match/action abstraction of OpenFlow switches constrains the evolution of the forwarding rules to be fully managed by the controller. This can be particularly limiting for a number of applications that are affected by the delay of the slow control path, like traffic management applications. Some recent proposals are pushing toward an evolution of the OpenFlow abstraction to enable the evolution of forwarding policies directly in the data plane based on state machines and local events. In this paper, we present two traffic management applications that exploit a stateful data plane and their prototype implementation based on OpenState, an OpenFlow evolution that we recently proposed.Comment: 6 pages, 9 figure