FP7 ALIEN project

Tag Archives: Programmable Abstraction Of Datapath

Programmable Abstraction of Datapath

Despite continuous developments in this area, Software Defined Networking (SDN) still seeks for a flexible way of defining a network device behaviour. One of the currently discussed topics is making network switches independent from data plane protocols formats. That should allow for more efficient usage of TCAM memory, enabling faster network innovation with usage of newly designed protocols like VXLAN, TRILL, etc. and allow for adapting of the network infrastructure to Future Internet solutions which are proposing to replace current IP protocol stuck and to use completely new data packet formats.

The main notice which triggered that discussion is fact that data plane protocols have quite simple structure because they are designed as fields of simple ordered set of bytes or bits, which can be easily and fast parsed in the hardware. Thanks to the simplicity of data plane headers they can be described with usage of quite simple schema. Protocols description using that schema can be passed to the device datapath in order to teach the datapath how to parse network packets.

Another important notice is that programmable network devices, like network processors, contains memory where simple procedure codes can be stored. This can be used for defining of forwarding functions which will be uploaded to the datapath. Forwarding functions tell datapath how to processes the network traffic in the device. Forwarding functions can contain the logic performed with a full datapath processing speed. Forwarding functions are more general equivalent of OF instructions.

Programmable Abstraction of Datapath (PAD), initially described in ALIEN deliverable D2.2, utilize finding described above, by exposing API interfaces which could be used by SDN Control Plane to get hardware capabilities (i.e.: processor architecture, bytes endianness, length of the machine word, arithmetic functions supported, etc.), set logical entities in the datapath memory, define forwarding functions and teach data plane protocols.

Programmable Abstraction of Datapath API overview

Programmable Abstraction of Datapath API overview

With PAD prototype, we want like to demonstrate usage of the last two mentioned functionalities of PAD API:

  • define data plane protocols
  • define forwarding actions

This API can be utilized by a new SDN Control Plane functional component (Data Plane Protocol Manager) which triggers protocol and actions interpretation for purpose of OpenFlow controller and all switches available in the network. The validation of PAD API starts with usage of software switches which makes it feasible in the timeframe of the ALIEN project (proper implementation for network hardware, e.g.: EZchip network processor will be much more complex and time-consuming).

Protocol programmability in SDN network using PAD API

PAD implementation

For the PAD API demonstration, we decided to use OpenFlow GNU-Linux software switch from xDPd framework and ROFL-based OpenFlow controller as the base of our SDN network. We have developed a code generator which generates a bunch of source code files for both ROFL and xDPd/GNU-Linux. The generated code files can be uploaded, in the form of the source code or already compiled binaries, to hardware where OpenFlow controller and software switches are running.

The code is generated basing on protocol headers, parsers and actions expressed in P4 language. Protocol and actions descriptions are passed from simple PAD API client to the code generator with usage of PAD API methods. Then P4 schema gramar is interpreted using Python pyparsing library.

The PAD code generator for ROFL and xDPd generate files with:

  • OpenFlow experimental matches and actions classes
  • Data plane protocol header classes and field manipulation functions
  • Data plane header parsing functions
  • Functions defining frame actions
  • Translation of OpenFlow match and action extensions to internal xDPd AFA match and action structures

Currently, PAD code generator generates code for branch ‘master-0.3’ of both xDPd and ROFL projects. That branch supports OpenFlow version 1.0 and 1.2 versions only. OpenFlow version 1.0 is completely out of scope of the experiment, because it doesn’t support OpenFlow experimental matches and actions which are very important for our PAD implementation because they allow to interact with newly defined protocols and actions without any modification to OpenFlow protocol itself. Thus, for time-being we are using OpenFlow version 1.2.

When a new protocols and actions are declared by PAD client, a new source code files are generated, both OF controller and software switches must be recompiled and finally restarted.

Details of protocol programmability implementation using PAD API, xDPD software switches and ROFL-based controller

The PAD prototype was used for one of the ALIEN experiments. For more details please check Alien deliverable D5.3.

Software