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