111,215 research outputs found
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
SPIDER: Fault Resilient SDN Pipeline with Recovery Delay Guarantees
When dealing with node or link failures in Software Defined Networking (SDN),
the network capability to establish an alternative path depends on controller
reachability and on the round trip times (RTTs) between controller and involved
switches. Moreover, current SDN data plane abstractions for failure detection
(e.g. OpenFlow "Fast-failover") do not allow programmers to tweak switches'
detection mechanism, thus leaving SDN operators still relying on proprietary
management interfaces (when available) to achieve guaranteed detection and
recovery delays. We propose SPIDER, an OpenFlow-like pipeline design that
provides i) a detection mechanism based on switches' periodic link probing and
ii) fast reroute of traffic flows even in case of distant failures, regardless
of controller availability. SPIDER can be implemented using stateful data plane
abstractions such as OpenState or Open vSwitch, and it offers guaranteed short
(i.e. ms) failure detection and recovery delays, with a configurable trade off
between overhead and failover responsiveness. We present here the SPIDER
pipeline design, behavioral model, and analysis on flow tables' memory impact.
We also implemented and experimentally validated SPIDER using OpenState (an
OpenFlow 1.3 extension for stateful packet processing), showing numerical
results on its performance in terms of recovery latency and packet losses.Comment: 8 page
PGPG: An Automatic Generator of Pipeline Design for Programmable GRAPE Systems
We have developed PGPG (Pipeline Generator for Programmable GRAPE), a
software which generates the low-level design of the pipeline processor and
communication software for FPGA-based computing engines (FBCEs). An FBCE
typically consists of one or multiple FPGA (Field-Programmable Gate Array)
chips and local memory. Here, the term "Field-Programmable" means that one can
rewrite the logic implemented to the chip after the hardware is completed, and
therefore a single FBCE can be used for calculation of various functions, for
example pipeline processors for gravity, SPH interaction, or image processing.
The main problem with FBCEs is that the user need to develop the detailed
hardware design for the processor to be implemented to FPGA chips. In addition,
she or he has to write the control logic for the processor, communication and
data conversion library on the host processor, and application program which
uses the developed processor. These require detailed knowledge of hardware
design, a hardware description language such as VHDL, the operating system and
the application, and amount of human work is huge. A relatively simple design
would require 1 person-year or more. The PGPG software generates all necessary
design descriptions, except for the application software itself, from a
high-level design description of the pipeline processor in the PGPG language.
The PGPG language is a simple language, specialized to the description of
pipeline processors. Thus, the design of pipeline processor in PGPG language is
much easier than the traditional design. For real applications such as the
pipeline for gravitational interaction, the pipeline processor generated by
PGPG achieved the performance similar to that of hand-written code. In this
paper we present a detailed description of PGPG version 1.0.Comment: 24 pages, 6 figures, accepted PASJ 2005 July 2
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
- …