Community Research and Development Information Service - CORDIS


BEBA Report Summary

Project ID: 644122
Funded under: H2020-EU.

Periodic Reporting for period 1 - BEBA (Behavioral Based Forwarding)

Reporting period: 2015-01-01 to 2016-01-31

Summary of the context and overall objectives of the project

Software Defined Networking relies on logically centralized control systems that collect information and events from the network. Unfortunately, the static nature of the forwarding abstraction on which SDN data plane nodes are based, necessarily requires the intervention of a controller for any forwarding rule change, even for those that are related to changes of local states (i.e. confined within a single data plane device) representing the current networking conditions.
Three fundamental drawbacks emerge. The most obvious regards performance and scalability limitations related to (i) the unnecessary delay required to update the forwarding rules and (ii) the single computational bottleneck introduced by a centralized controller.
Second, such approach brings about security and reliability implications, as the communication channel between a remote control entity and the switch can be severely impaired by targeted denial of service attacks or link physical failures.
Finally, the “dumb nature” of traditional SDN switches results in dramatic functional limitations that impede the deployment of real time, self-adapting monitoring and mitigation applications directly in the fast path.
BEBA aims at providing the unprecedented ability to program, in a platform-agnostic manner, not only “just” plain forwarding rules, but also dynamic (custom) states determining which forwarding rules should be applied at a given time, and the relevant policies formalizing how states should evolve.
By introducing intelligence directly into the data plane nodes, BEBA will free SDN programmers from having to necessarily rely on the centralized controller intervention to implement more complex forwarding strategies.
Moreover BEBA will therefore permit organizations and network operators to deploy part of their stateful flow processing operations directly on the fast data path and inside the switch. This will dramatically improve the ability to instantly (i.e. at real-time, packet-level, temporal time-scale) modify the forwarding data plane in reaction to specific packet-level events, and in front of sudden changes or anomalies in the traffic behaviour, including attacks.
BEBA will start from defining novel use case application scenarios and requirements, which will inspire the extension of the basic SDN match/action forwarding behavior into more complex approaches based on eXtended Finite State Machines. Indeed, BEBA will design a novel abstraction and API that will provide autonomous stateful reconfiguration of forwarding rules on the basis of packet-level, flow-level and monitoring- level triggering events.
Such an ambition goal will be achieved in two separate, and yet strongly interconnected, phases. In a first phase, BEBA will provide a basic design for a stateful, platform-agnostic, data plane programming interface that will give the fundamental ability to associate and update the status associated to a flow. Such API will minimally depart from the current OpenFlow specification and will be easily implemented by extending publicly available OpenFlow implementations.
In a second phase, the project will focus on something much more ambitious. BEBA will aim at transforming a switch into a sort of network/flow processor programmed through a platform-independent abstraction. Our belief is that this can be accomplished by further introducing the ability to store temporary data into “memory registries” associated to flow entries, and provide the ability to enforce state transitions only if conditions on such registries are satisfied, as well as support registry updates upon the occurrence of events and/or state transitions.
According to such novel abstraction, BEBA will extend the data plane and control plane mechanisms, data structures and protocols and on top of these will allow the deployment of novel monitoring security and innovative forwarding applications.

Work performed from the beginning of the project to the end of the period covered by the report and main results achieved so far

The BEBA project started on January 1, 2015. It is planned to last for 27 months, until March 31, 2017. The first reporting period (month 1 – month 13) terminated on January 31, 2016, 5 months after the end of Phase 1

During the first reporting period the project has:
1. Identified a set of use case and application scenarios that has set the system requirements for the S&T tasks of this phase and identified the trial and validation scenarios
2. Produced a BEBA basic stateful API and interfaces specifications
3. Defined a set of novel in-switch control offloading operations and new dataplane primitives (including the definition of strategies for their software acceleration)
4. Delivered the first proof of concept prototype providing the basic BEBA stateful support

The results listed above correspond to the following project milestones described in Annex 1:
M1: Use case and requirements definition, WP5, Month 4
M2: Base specification delivery, WP2, WP3, WP4, Month 8
M3: Base API prototype, WP2, WP3, Month 10

Morover, even if currently ongoing, in the first reporting period the project has achieved important results in the frame of the following activities:
1. Provided a first set of applications to run on top of the BEBA architecture
2. Provided a preliminary plan for the on-field assessment activities of the real world project trial
3. Finalized the control plane tools and the strategies for offloading control tasks
4. Started the standardization aimed at promoting the BEBA solutions in the frame of WP2 Wp3 and WP4 within the ONF community

Progress beyond the state of the art and expected potential impact (including the socio-economic impact and the wider societal implications of the project so far)

Progress beyond the state of the art

During the first year of activity, the project developed both a hardware and software proof of concept implementation of the data plane API and the internal flow computing architecture, including the integration with an existing SDN controller. This is a important progress with respect to the state of the art, since the project reached the goal of providing a usable configurable stateful BEBA forwarding abstraction using a few simple architectural extensions to the standard OpenFlow pipeline.
The software implementation is based on a well known open source OpenFlow implementation (ofsoftswitch13). ofsoftswitch13 is built upon the OpenFlow 1.3 specification and it is the one that better implements the OpenFlow experimenter fields, useful to extended the switch with additional functionality. The hardware implementation uses a FPGA based hardware prototype that allows line rate processing at up to 40 Gbits/sec and can store more than 32 thousand of flows in the internal embedded SRAM. The HW prototype implements the basic stateful BEBA forwarding abstraction combined with a limited set of match fields and actions. As a consequence of this implementation effort, an OpenFlow experimenter specification for the basic BEBA forwarding abstraction has been carried out among the project standardization activities.

The project focused also on the software acceleration of the BEBA abstraction. In this field, both the use of PFQ packet I/O acceleration framework to improve ofsoftswitch and the netmap packet I/O acceleration framework to accelerate Open vSwitch has been investigated. Moreover, as a complementary activity, BEBA is working towards being able to accelerate software switches with specialized hardware (i.e., FPGAs). More specifically, we have implemented DPDK support to a COMBO-100G hardware accelerator card that allows us to reach 100 Gb/s speeds.

The project also innovated in the support and manage of control tasks, identifying the separation between the switch level control tasks to be directly implemented inside the BEBA nodes and the global SDN controller tasks. For this to happen, we designed a bi-directional API that formalizes the signaling between the controller and the switches.

From the application point of view, the projects identified several network-wide and node-level middlebox-type applications to be implemented according to the proposed BEBA abstraction.
The network-wide applications will take benefit from the BEBA advanced functionalities running into multiple BEBA nodes, while the node-level middlebox-type applications will highlight the benefits offered by BEBA advanced functionalities running in a single BEBA node. Examples of network-wide applications applications are the ARP replyer application, the automatic link failover application and, for the node-level application the local remediation to TCP SYN flooding attacks.


The project accurately disseminated the results of the project’s activities to ensure that these results have a positive impact on the research community. These activities has been carried out through publications, participation in technical meeting and organisation of academic events and standardisation efforts. Moreover, the project deployed a website, mostly meant for external contacts. With its website the BEBA consortium wants to inform the stakeholders about the project status and results.

The scientific publications of the project (6 between conference and journal publications for the first year of the project) are inline and exceeds the originally planned objectives for quality and quantity.
The project has been very active in the academic dissemination: project partners as participated in 13 dissemination activities among demonstrations, tutorials and invited talks.

For the standardization activities the project members proposed both OpenState and in-switch packet generation as an extension to be included in the OpenFlow 1.6 specification. Both of them have been accepted as work items by the ONF. As per ONF ways of working two tickets (EXT-562 and EXT-563, links require a ONF JIRA account, only available to members) have been created to track and document discussion around the proposed extension.

Related information

Record Number: 190144 / Last updated on: 2016-11-08