1,287 research outputs found
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
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
Relaxing state-access constraints in stateful programmable data planes
Supporting the programming of stateful packet forwarding functions in
hardware has recently attracted the interest of the research community. When
designing such switching chips, the challenge is to guarantee the ability to
program functions that can read and modify data plane's state, while keeping
line rate performance and state consistency. Current state-of-the-art designs
are based on a very conservative all-or-nothing model: programmability is
limited only to those functions that are guaranteed to sustain line rate, with
any traffic workload. In effect, this limits the maximum time to execute state
update operations. In this paper, we explore possible options to relax these
constraints by using simulations on real traffic traces. We then propose a
model in which functions can be executed in a larger but bounded time, while
preventing data hazards with memory locking. We present results showing that
such flexibility can be supported with little or no throughput degradation.Comment: 6 page
SNAP: Stateful Network-Wide Abstractions for Packet Processing
Early programming languages for software-defined networking (SDN) were built
on top of the simple match-action paradigm offered by OpenFlow 1.0. However,
emerging hardware and software switches offer much more sophisticated support
for persistent state in the data plane, without involving a central controller.
Nevertheless, managing stateful, distributed systems efficiently and correctly
is known to be one of the most challenging programming problems. To simplify
this new SDN problem, we introduce SNAP.
SNAP offers a simpler "centralized" stateful programming model, by allowing
programmers to develop programs on top of one big switch rather than many.
These programs may contain reads and writes to global, persistent arrays, and
as a result, programmers can implement a broad range of applications, from
stateful firewalls to fine-grained traffic monitoring. The SNAP compiler
relieves programmers of having to worry about how to distribute, place, and
optimize access to these stateful arrays by doing it all for them. More
specifically, the compiler discovers read/write dependencies between arrays and
translates one-big-switch programs into an efficient internal representation
based on a novel variant of binary decision diagrams. This internal
representation is used to construct a mixed-integer linear program, which
jointly optimizes the placement of state and the routing of traffic across the
underlying physical topology. We have implemented a prototype compiler and
applied it to about 20 SNAP programs over various topologies to demonstrate our
techniques' scalability
P4CEP: Towards In-Network Complex Event Processing
In-network computing using programmable networking hardware is a strong trend
in networking that promises to reduce latency and consumption of server
resources through offloading to network elements (programmable switches and
smart NICs). In particular, the data plane programming language P4 together
with powerful P4 networking hardware has spawned projects offloading services
into the network, e.g., consensus services or caching services. In this paper,
we present a novel case for in-network computing, namely, Complex Event
Processing (CEP). CEP processes streams of basic events, e.g., stemming from
networked sensors, into meaningful complex events. Traditionally, CEP
processing has been performed on servers or overlay networks. However, we argue
in this paper that CEP is a good candidate for in-network computing along the
communication path avoiding detouring streams to distant servers to minimize
communication latency while also exploiting processing capabilities of novel
networking hardware. We show that it is feasible to express CEP operations in
P4 and also present a tool to compile CEP operations, formulated in our P4CEP
rule specification language, to P4 code. Moreover, we identify challenges and
problems that we have encountered to show future research directions for
implementing full-fledged in-network CEP systems.Comment: 6 pages. Author's versio
- …