ABSTRACTION LAYER FOR IMPLEMENTATION OF EXTENSIONS IN PROGRAMMABLE NETWORKS

Hardware Abstraction Layer (HAL) Whitepaper

simplicity for the integrators are the main motivation assumptions for disseminating the HAL 1. Abstract concept. This Whitepaper describes the concept of Hardware Adaptation Layer (HAL) for applying the 2.1. Purpose of proposed solution OpenFlow protocol to the non-OpenFlow hardware. In this document, first, the motivation and high level goals of designing the HAL is explained as well as the Although OpenFlow has clear specifications [ONF], high level goals and supported network platforms. when it comes to implementing those Then, the logical architecture of HAL is presented specifications on devices or platforms, each including the architectural and functional implementation is different because of requirements. As next chapter the network heterogeneity of platforms and their architectures. hardware integration models are provided and the Moreover, the official OpenFlow specification is supported hardware platforms are classified. designed for wired Ethernet platforms and it does Finally, the proposed implementation of HAL is not support other platforms such as circuit presented including the software interfaces for switched and wireless platforms. Designing a platform integrators such as the Abstract mechanism, targeting hardware-level forwarding Forwarding API and the Pipeline Interface. platforms to provide a clean, simple, extensible and flexible interface between software and hardware will facilitate providing abstracted information of underlying hardware or platform 2. Motivation for the for creating an abstracted elements for controlling software. This mechanism will expose all of HAL functionality and performance of modern Software Defined Networking concept is getting networking hardware, while maintaining the useful more and more popularity as a solution for more properties of embedded operating systems on the efficient network management. The OpenFlow hardware platform but at the same time it will be protocol is the most mature proof of concept of platform agnostic. the SDN. The idea of separating the data and control elements in network devices is being As part of SDN activities the ALIEN project aims to supplied in new network equipment. Although, the undertake the challenge of provide simple concept OpenFlow is usually not supported in many specific for non-OpenFlow hardware platforms integrators network equipments e.g. the optical devices, by designing and defining functions of a Hardware hardware without possibility to be upgraded or Abstraction Layer (HAL). This abstraction without packet processing API. Enabling OpenFlow mechanism aims to hide hardware complexity as on all those non-OpenFlow devices with possible well as technology and vendor specific features requirements for HAL was categorised in from OpenFlow control framework. functional and architectural.

2.2. Supported network platforms The desired HAL should follow some architectural guideline in order to support the intended The targeted platform for HAL are: platforms.  Packet Switch: All devices that perform any  HAL has to reside between controller and the form of L2 switching are fell into this group. device i.e. controller can get control access on  Optical: Basically all circuit switched devices data path only through HAL. (WDM/TDM) are categorized in optical group.  HAL components should be reusable as much  Network Processor (NP) / NetFPGA: Any device as possible. This will lead to smaller code, that its data plane can be programmed to better troubleshooting and management. perform any (L2-L4) packet processing.  It should be portable, platform-independent  Access Networks technologies (DOCSIS, and flexible to give ability to be implemented GPON,GEPON...): Since these technologies’ data on various platforms. plane architecture is so different to the rest of HAL has to have certain functionalities in order to platforms, it was decided to put it in separate provide a platform for controllers to control the group so that its abstraction could be done data path: without compromising its functionality.  It has to provide an interface to upper layers In the ALIEN project the implementation of the (applications) for handling hardware dependent HAL architecture will be validated on various issues network equipment such as: EZappliance with  It has to provide rich information enough to EZchip NP3 network processor, GEPON, NetFPGA, support full featured network operating DOCSIS, ATCA with Cavium Octeon network systems (controllers) processor, ADVA Layer 0 Switch, Dell/Force10  It has to expose interfaces for hardware 7024 switch with ASIC and Cavium Octeon. reprogrammability. For example, an ASIC packet-processing fast path could support programmability for deep-packet inspection 3. Logical architecture operations. Another example could be NetFPGAs which users can define their own of HAL function on the hardware.  It has to provide interface for hardware Following the SDN concept and according to resource management. OpenFlow architecture, the data path or  It has to provide mechanism for controlling forwarding engine inside of an OpenFlow device shared abstracted resources such as must be controlled and managed by a controller forwarding-table in virtualized environment who resides outside of the device and communicates to the device via a secure channel. 3.2. Proposed HAL architecture The data path is represented to the controller in an abstracted fashion as a table or tables with Following the functional and architectural flows holding packets information and actions requirements for desired HAL a unified associated to them which could be manipulated architecture is proposed. Hardware platform (programmed) by the controller software. categorization helps to build organized and modular components which then yields to create 3.1. Requirements for HAL a flexible and extensible HAL. In the following, HAL components and their functionalities are Optimum HAL for network devices to support described. OpenFlow protocol needs to have certain features so that it can support the current and future The proposed HAL consists of two separate layers: architecture of networking devices. The upper Hardware Interface Layer (HIL) and lower Hardware Presentation Layer (HPL).

2

Figure 2 - Virtualization architecture

Bare Metal Management: Although the ultimate goal of creating HAL is to provide an interface for controlling hardware, each hardware platform has

Figure 1 - HAL architecture different protocol for device management and configuration. The bare metal management HIL: Components in the HIL altogether provide an component is responsible for hardware implementation of common device control and initialization and management. In case of device management protocols i.e. OpenFlow, etc. configuration changes in hardware platform or The HIL components are independent of introducing new user-defined functionality into the underlying hardware platform. platform, this component will provide tools and interfaces for such events. OpenFlow endpoint: is a protocol endpoint responsible for maintaining connection with a HPL: The Hardware Presentation Layer (HPL) controller. includes few components which have distinct Virtualization: This component is proposed as a functionality. The northbound of HPL provides an method to provide virtualization capabilities to API for upper layer to create extended OpenFlow HAL-compatible devices. It has three different table. In the following, HPL components and their functionalities: (i) communicating with the role and functionality are explained. Network Management System (NMS) of the Infrastructure Provider (by considering the NMS Device Information Model: is a model of the responsible for properly configuring the virtual configured OF switch that represents switch’s state network instances), (ii) communicating with which probably is platform independent. It is not a multiple OF controllers through the OpenFlow representation of a specific hardware. Pure data protocol and (iii) slicing the flowspace. The Virtual model without processing. Agent (VA) slices the overall flowspace among Translator: is part of device driver. it is responsible many OF Controllers based on the configuration for translating all entries and actions from received from the NMS. On the other hand VA OpenFlow switch model (DIM) into platform ensures setting-up control channels with each specific commands and configurations. This connected OF controller by creating one virtual module is not obligatory, e.g. for devices that switch per controller. Virtual switches of the same supports OpenFlow data model. VA may use different versions of the OpenFlow Orchestrator: is part of driver components and protocol, depending on the capabilities of the responsible for configuring the entire subnetwork, controller assigned to their slice. i.e. multiple components, to simulate the behavior of OF switch modeled by DIM. As an example, GEPON needs configuration for both optical and electrical parts for appropriate functioning.

3

Device driver: is a piece of software that performs and exposes a part of a network as a single device. data processing using hardware In this case the HAL implementation must device/accelerators. In case of closed devices, it orchestrate a group of devices to behave as a only configures a device to obtain the same single network element. This integration model is behavior like modeled by DMI OF switch (a kind of suitable for platforms that are constituted of translation). It is a platform dependent component tightly coupled elements like DOCSIS (CMTS and of the HAL. Cable Modems) and GEPON (OLT and ONU).

4. Network hardware 5. HAL implementation integration models The modular architecture of xDPD [XDP] that could use ROFL [ROF] pipeline library for its datapath Various types of network hardware give different implementation and freedom that ROFL library possibilities for HAL integration with devices. provides for implementation OpenFlow protocol ALIEN HAL supports three main hardware on various platform regardless of their underlying integration models for devices with different hardware and software, leads to conclusion that requirements, constraints and hardware the combination of xDPD and ROFL could build capabilities. ALIENs HAL architecture. In the following, it will be explained that how the building blocks of xDPD 4.1. Built-in Model and ROFL could be used in the ALIEN project.

In the Built-in model, the overall HAL implementation runs inside the network device. The HAL acts as the only exposed device API. This integration model is suitable for fully programmable devices with available SDK and for device vendors. The only limitation is that a network device must have enough general purpose processing power to run HAL. Built-in model offers the best level of integration thus should be used for each network device which offers enough capabilities.

4.2. Proxy Model Figure 3 - Sample HAL implementation In Proxy model the HAL implementation runs (at least partially) on a separate machine which is an 5.1. Software interfaces available integral part of a node. The network device itself is for platform integrators configured by HAL implementation using CLI, Considering the architecture of ROFL , since the SNMP or other ways provided by a device vendor. library is platform agnostic, it could be used on any For better performance entire data processing platform for different purposes. In a basic should be done using data plane parts of a conceptual view, a developer could implement an network device, not in a proxy machine . This OpenFlow forwarding module by calling ROFL integration model is suitable for closed platforms library. Also, ROFL provides an Abstracted or platforms with not enough resources for Built-in Forwarding API (AFA) for controlling and HAL. management of the logical datapath. Part of AFA covers OpenFlow API but it also supports 4.3. Orchestrator Model management tasks API. The library provides: Orchestrator model is an extension of the Proxy. HAL implementation runs on separate machine

4

 basic support for OpenFlow protocol and maps  Background tasks: this component is in charge protocol wire representation into a set of C++ of managing OpenFlow pipeline, buffer or flow classes. The library tries to hide the details of entry expiration. protocol and provide more understandable API  Event generation: this component generates for developing. The current version supports events for management and control entities OpenFlow 1.2 but it aims to be a multi-version such as port status changes, OpenFlow packet- library. in and other OpenFlow messages and errors.  an abstraction to build an OpenFlow endpoint for controllers. 5.4. Pipeline interface  capabilities to create data path elements which could be OpenFlow. The pipeline could be As it was mentioned FM employs ROFL pipeline implemented on various platforms e.g., ASIC, library for implementing the OpenFlow pipeline. FPGA, GNU/Linux, etc. The ROFL pipeline library supports logical switch concept. It also supports for multi version of OpenFlow which is convenient for developers to 5.2. CMM module implement different version of OpenFlow protocol Control and Management Module is in charge of based on their device capabilities. It is worth to managing and controlling of physical and logical mention that ROFL pipeline library is not a fully devices as well as keeping abstracted version of ready to use OpenFlow data path with support of logical switch and its associated OpenFlow end- platforms subsystems such as I/O. Although the point. The CMM is hardware agnostic and it is subsystems are part of FM, they are platform common for all Forwarding Modules (FM). specific components which are different on each The CMM communicates with FM using Abstracted platform. The I/O subsystems could be seen as Forwarding API (AFA). CMM will be platform device or interface drivers which have different independent but also it gives the ability for FM to architecture and API on every platform and do tasks internally without communicating with systems. CMM. 5.3. AFA interface 6. Conclusions Abstract Forwarding API is binding, the platform Hardware abstraction concept is well known from specific, forwarding module with control and operating systems where HAL hide hardware management module, which is keeping the complexity from the rest of the system. In the SDN abstracted switching information. AFA interface networks with split data and control plane, with device specific implementation provide below problem of abstracting different network features: hardware platforms is growing again. ALIEN project takes the problem of enabling OpenFlow  Management actions: that is creating and on “alien” hardware without native support of this destructing logical switches. It binds the logical protocol. Providing an abstraction layer for alien switch instance and ports or network hardware platforms is the key towards network interfaces. programmability.  I/O subsystem: this component is in charge of port (network interface) discovery, inventory, Presented in chapter 3 general HAL architecture configuration and management. It also provides modular and flexible representation of monitors the traffic of the interfaces to capture different networking equipment. HAL architecture the packets for sending them for processing, allows the data path of the network devices to be that means OpenFlow processing, and presented in an abstracted fashion as pipeline afterward execute the action based on the (flow tables with OF actions) to the OF controllers. policy. Based on dual-layer HAL concept initial HAL  Packet processing: this component is in charge implementation proceeds. xDPD and ROFL of processing a packet as defined in the presented in chapter 5 of this Whitepaper are key OpenFlow specification.

5

software l