FP7 ALIEN project

Tag Archives: Hardware Platforms

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

Hardware Platforms

The aim of Hardware Platforms activity is to provide implementations of Hardware Specific Parts (HSPs) of datapath element for each ALIEN hardware platform. Hardware Specific Parts allow integration of a device with common part of OpenFlow datapath element (Hardware Agnostic Part) provided by HAL and hide the complexity of the specific underlying equipment. This will enable resource management and virtualization according to common abstraction mechanism specified in HAL activity.

The Hardware Platforms activity has the following objectives:

  • Analyse each hardware platform in terms of its specific management requirements, switching constraints and available legacy interfaces
  • Specify a functional decomposition of hardware specific parts
  • Implement hardware specific parts for each platform in accordance to functional specification

ALIEN Hardware Platforms

The following hardware is considered in ALIEN and will be equipped with HSP implementations:

The above hardware descriptions give the basic properties of the equipment which is to be configured to use OpenFlow during the Alien project. Many of the pieces of equipment have properties in common and can be divided into several thematic groupings of equipment which can be treated in largely the same way by the hardware abstraction layer.

Packet processing device is a basic piece of equipment capable of receiving and forwarding network layer packets encapsulated on data link layer frames. Most devices to be used in the context of ALIEN will use Gigabit Ethernet or 10 Gigabit Ethernet as a layer 2 technology, and IP at layer 3. The cornerstone upon which forwarding decisions are taken in OpenFlow is the 5-tuple, defined as a combination of a pair of source/destination IP addresses, a protocol number, and a pair of source/destination TCP/UDP ports. All packet processing devices to be used in ALIEN support this definition.

Lightpath devices are an optical equipment which is capable of configuring paths but which do not understand Ethernet or IP packet headers. Generally, the control mechanism in IP networks is tightly linked to the packet forwarding task and it is fully distributed in each router and switch in the network. On the contrary, circuit switched or transport networks have completely separate control and data plane. The control plane has no visibility of data plane and the provisioning and management of the network is done manually through provider’s management system.

Point to multi-point devices have an inherent asymmetry between ports and have an inherent single port at the “head” and many ports at the “tail” end. The phrase used for “head” and “tail” depends on the device used.  In the case of the GEPON the “head” is the OLT and the “tail” devices the ONUs and in the case of DOCSIS the “head” is the CMTS and the “tail” devices the CMs. The head device is usually the more capable device.  In these devices the input at the “head” end is broadcast to the other connected ports and those ports select the portion of the input relevant to them.  Any transmission between two “tail” ports must be via the “head”.

Programmable network processors contain programmable hardware units that can be adapted to a wide range of network processing tasks. These hybrid devices combine (at least partially) the flexibility of software implementations on general purpose CPUs and the performance characteristics of dedicated networking chip sets in terms of packet forwarding speeds. Reprogrammable platforms allow the integration of newer versions of OpenFlow on a device or extending an existing implementation with new capabilities, e.g. additional protocol match and action definitions.

Physically reconfigurable systems are composed of different boards or cards which are connected together in order to provide full, modular networking system. These systems can be highly reconfigurable but this must be done physically by removing and replacing physically independent components.  Within that kind of a platform, each component offers dedicated capabilities and performs specific traffic processing roles. All components work quite independently from each other and could be easily replaced depending of network operator needs and overall platform role in the network. The system components cooperate together by exchanging transport network traffic in the form of Ethernet frames or opaque optical transmission depending on technical nature of the entire system.

Hardware Specific Parts development

The HAL developments have been split into the two parts:

  • The HAL agnostic part for OpenFlow in a form of ROFL and xDPd projects,
  • Hardware Specific Part (HSP) for all ALIEN platforms.

The ROFL software provides the implementation of the OpenFlow protocol in various versions (OF1.0, OF1.2 and OF1.3) as well as a definition of HAL internal interfaces (e.g.: AFA and Platform Pipeline interfaces). xDPd is a framework for the HAL instantiation in a form of one or many OpenFlow endpoints (OF agent). Each OpenFlow endpoint is plugged with one hardware driver for a certain hardware platform (see Figure 1). The hardware driver realizes communication with network device and controls the realization of configuration requests. For programmable network devices, ALIEN is developing an OpenFlow datapath implementation based on programmable hardware capabilities. In the case of the non-programmable and closed-box devices, the OpenFlow datapath part could not be developed and the HAL hardware driver is trying to use existing hardware platform functionalities to fulfil required OpenFlow functionality. The term ‘Hardware Specific Part’ (HSP) refers both to the hardware driver and OpenFlow datapath implementations for a particular platform.

Figure 1 – Hardware Specific Parts (HSPs) implementation for ALIEN platforms

More information