FP7 ALIEN project

Tag Archives: Openflow

ALIEN on the Terena Networking Conference 2014

ALIEN TNC14 During TNC2014 Conference in Dublin (19-22.05.2014) ALIEN will present Hardware Abstraction Layer for non-OpenFlow capable devices. Session Advanced networking is planned on Thuesday 20 May at 2 p.m.

“This presentation shows a way forward for adding SDN-based control on network devices that are not compatible with OpenFlow and introduces a Hardware Abstraction Layer (HAL) for non-OpenFlow capable devices that addresses this problem and discuss its advantages. In particular, the presentation explains how a HAL-based architecture can support different classes of network devices.” 
Read More

Experiments on OFELIA

The Experiments on OFELIA activity is responsible for running the experiments over the OFELIA FIRE experimental facility, in order to test and demonstrate ALIEN HAL concept.

This activity aims towards five specific goals:

  • Definition of requirements of the Content-Centric Networking (CCN) usage scenario
  • OFELIA slice deployment and CCN basic scenario setup
  • Adaptation of the CCN application layer to an OpenFlow environment
  • Integration of alien hardware developments over the OFELIA slice
  • Validation of developments and experimental-driving research reporting activity

First of all, this activity is responsible for the integration and validation of all ALIEN developments:

  • HAL agnostic part (see Hardware Abstraction Layer)
  • HAL hardware specific parts for all ALIEN platforms (i.e.: ATCA, DOCSIS, Dell/Force10 switch, EZappliance, GEPON, L0 switch, NetFPGA)
  • CCN solution for research-driven experimentations (i.e.: CONET solution)

Experiments development

The experiments performed by this activity combines CCN with OpenFlow using the existing work from the COntent NETwork (CONET) project. The ALIEN project is actively contributing to the CONET development in cooperation with the team that is currently supporting the code. Due to the fact that the ALIEN project deals with OpenFlow, the ALIEN consortium focuses mainly on the OpenFlow related part of the CONET development (i.e. the FloodLight controller modules). Currently, some areas CONET for enhancement have been identified (see Fig.1) and agreed between ALIEN and CONET teams:

  • multiple-cache server support
  • topology-aware path computation

Figure 1 – ALIEN improvements to the current CONET development


The CCN experiments based on CONET solution are performed within an ALIEN slice created in OFELIA testbed (see Fig.2). The ALIEN slice includes both computational resources (e.g. end-nodes, CONET nodes and OpenFlow controller), ALIEN hardware platforms and OpenFlow devices from the pool of resources provided by OFELIA.

Figure 2 – ALIEN slice topology within OFELIA FIRE testbed

Usage scenarios

Currently, ALIEN defined four use-cases which will be used to test whether the implementation of OpenFlow has been successful on the ALIEN hardware and the utility of OpenFlow in networking scenarios:

  • base scenario (without ALIEN improvements)
  • split routing scenario (see Fig. 3)
  • cache assisted scenario (extra cache nodes are used)
  • combined scenario (combines both split routing and multiple cache scenarios)

Figure 3 – Alternative routes scenario for ALIEN experimentation

More information

Hardware Abstraction Layer (HAL)

The aim of Hardware Abstraction Layer (HAL) is to design and implement the required building blocks for a novel Hardware Abstraction Layer (HAL) that can facilitate unified integration of alien types of network hardware elements (i.e. network element that doesn’t support natively OpenFlow) with an OpenFlow control framework i.e. OFELIA control framework. The alien hardware are:

  1. traditional packet switching network elements (e.g., L2 switches),
  2. non-packet switching network elements (e.g., optical switch, NetFPGA),
  3. network monitoring and network processing elements (e.g. FPGA, Network processor).

This activity focuses on :

  • Design and development of a suitable hardware description language that can facilitate uniform representation of any type of alien hardware and their capabilities
  • Design and development of a hardware abstraction mechanism that together with the proposed hardware description language can interface with different type of alien hardware and can hide their complexity as well as technology and vendor specific features from OpenFlow control framework
  • Redefinition of the classical OpenFlow data model to support new notions of flow, switching and processing in alien hardware
  • Define the generic flow action i.e. switching, processing and monitoring to be performed on new flow concept

HAL architecture

Initial HAL architecture was described in the HAL whitepaper, publicly available document released by the ALIEN Consortium.

The Whitepaper describes the concept of Hardware Adaptation Layer (HAL) for applying the OpenFlow protocol to the non-OpenFlow hardware. The document describes motivation of designing the HAL and explains the high level goals. HAL whitepaper describes the HAL architecture and constitutes the guideline for the future steps in the ALIEN project – the implementation of the HAL on all available devices in the ALIEN project.

HAL unified architecture is divided into two:

  • Hardware Agnostic Part (HIL – Hardware Interface Layer) – a set of components enabling virtualization and communication mechanisms that are independent of underlying hardware platform
  • Hardware Specific Part (HPL – Hardware Presentation Layer) – a set of hardware drivers realizing atomic network instructions specific for all ALIEN platforms (i.e.: ATCA, DOCSIS, Dell/Force10 switch, EZappliance, GEPON, L0 switch, NetFPGA)

HAL architecture from the “HAL whitepaper”

HAL implementation

HAL implementation is based on ROFL and xDPd libraries. First source code for the HAL was released in May 2013.

HAL sample implementation from "HAL whitepaper"

HAL sample implementation from “HAL whitepaper”

The Revised OpenFlow Library (ROFL) helps you adding OpenFlow support to your software to build control applications, controller frameworks and/or data path elements.

The eXtensible DataPath daemon (xDPd) is a multi-platform, multi OF version, open-source datapath built focussing on performance and extensibility.

More information

D2.1: Report on Hardware abstraction models (UPDATED)