BZPEERReading, trust and collaboration for research
Menu

Discover

GraphFollow connections around a paper, topic or saved view.

Workspaces

HomePick up where your research flow left off.InboxHandle requests, replies and notifications from one place.CollectionsCurate reading lists, evidence sets and shareable dossiers.ResearchSee your private provenance graph, trail and imports.CollaborationMove from discovery into focused discussion rooms.PublishDraft, preview and publish full-text research articles.

Network

ExpertsFind specialists worth following or asking for help.CommunitiesJoin research circles organized around shared work.PartnersSee external organizations active around the same topics.

Opportunities

ListingsBrowse roles, calls and collaborations with clearer fit signals.

Account

Log inReturn to your reading and collaboration workspace.Create accountStart saving work, following people and joining teams.
Log inCreate account

Researcher profile

Carmelo Cascone

Carmelo Cascone contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate
Networking and Internet Architecture

Trust snapshot

Quick read

Trust 21 - Emerging
6works
0followers
1topics
4close collaborators

Actions

Decide how to stay connected

Follow researcher0

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

6 published item(s)

preprint2016arXiv

Open Packet Processor: a programmable architecture for wire speed platform-independent stateful in-network processing

This paper aims at contributing to the ongoing debate on how to bring programmability of stateful packet processing tasks inside the network switches, while retaining platform independency. Our proposed approach, named "Open Packet Processor" (OPP), shows the viability (via an hardware prototype relying on commodity HW technologies and operating in a strictly bounded number of clock cycles) of eXtended Finite State Machines (XFSM) as low-level data plane programming abstraction. With the help of examples, including a token bucket and a C4.5 traffic classifier based on a binary tree, we show the ability of OPP to support stateful operation and flow-level feature tracking. Platform independence is accomplished by decoupling the implementation of hardware primitives (registries, conditions, update instructions, forwarding actions, matching facilities) from their usage by an application formally described via an abstract XFSM. We finally discuss limitations and extensions.

0 citations0 reviewsNo code linkedOpen access
preprint2016arXiv

Towards a Stateful Forwarding Abstraction to Implement Scalable Network Functions in Software and Hardware

An effective packet processing abstraction that leverages software or hardware acceleration techniques can simplify the implementation of high-performance virtual network functions. In this paper, we explore the suitability of SDN switches' stateful forwarding abstractions to model accelerated functions in both software and hardware accelerators, such as optimized software switches and FPGA-based NICs. In particular, we select an Extended Finite State Machine abstraction and demonstrate its suitability by implementing the Linux's iptables interface. By doing so, we provide the acceleration of functions such as stateful firewalls, load balancers and dynamic NATs. We find that supporting a flow-level programming consistency model is an important feature of a programming abstraction in this context. Furthermore, we demonstrate that such a model simplifies the scaling of the system when implemented in software, enabling efficient multi-core processing without harming state consistency.

0 citations0 reviewsNo code linkedOpen access
preprint2015arXiv

Detour Planning for Fast and Reliable Failure Recovery in SDN with OpenState

A reliable and scalable mechanism to provide protection against a link or node failure has additional requirements in the context of SDN and OpenFlow. Not only it has to minimize the load on the controller, but it must be able to react even when the controller is unreachable. In this paper we present a protection scheme based on precomputed backup paths and inspired by MPLS crankback routing, that guarantees instantaneous recovery times and aims at zero packet-loss after failure detection, regardless of controller reachability, even when OpenFlow's "fast-failover" feature cannot be used. The proposed mechanism is based on OpenState, an OpenFlow extension that allows a programmer to specify how forwarding rules should autonomously adapt in a stateful fashion, reducing the need to rely on remote controllers. We present the scheme as well as two different formulations for the computation of backup paths.

0 citations0 reviewsNo code linkedOpen access
preprint2015arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2015arXiv

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.

0 citations0 reviewsNo code linkedOpen access
preprint2014arXiv

Towards Wire-speed Platform-agnostic Control of OpenFlow Switches

The possibility to offload, via a platform-agnostic specification, the execution of (some/part of the) control functions down to the switch and operate them at wire speed based on packet level events, would yield significant benefits in terms of control latency and reaction times, meanwhile retaining the SDN-type ability to program and instantiate a desired network operation from a central controller. While programmability inside the switches, at wire speed and using platform-independent abstractions, of "any possible'" control function seems well beyond the OpenFlow capabilities, in this paper we argue that a non trivial sub-class of stateful control functions, namely those that can be abstracted in terms of Mealy (Finite State) Machines, is already compatible with off-the-shelf OpenFlow version 1.1+ Hardware with marginal architectural modifications. With minimal additional hardware circuitry, the above sub-class can be extended to include support for bidirectional/cross-flow state handling. We demonstrate the viability of our proposed approach via two proof-of-concept implementations (hardware and software), and we show how some stateful control functionalities frequently exploited in network protocols are readily deployed using our application programming interface.

0 citations0 reviewsNo code linkedOpen access