Programmable Data Planes (text)

by Sasha Shkrebets — last modified Mar 20, 2023 07:58 AM

n the second lesson we will talk about various projects underway to make the data plane more programmable and scalable both in software and in hardware. This module has an optional programming assignment and a quiz on the concepts. Let's quickly review what a conventional data plan looks like. Before we talk about customizing the data plan let's quickly review what a conventional data plan looks like.

Welcome back.

We are now beginning a module on the programmable data plane.

This short module will have two lessons.

In the first lesson, we'll explore a particular piece of software called Click.

That allows the programmer to customize data plane operations.

In the second lesson we will talk about various projects underway to make the

data plane more programmable and scalable both in software and in hardware.

This module has an optional programming assignment and a quiz on the concepts.

Let's quickly review what a conventional data plan looks like.

Before we talk about customizing the data plan let's

quickly review what a conventional data plan looks like.

First, a router receives the packet.

It examines the packet header, looking for the destination for that packet.

It consults its local forwarding table to determine the next hop output interface.

It then modifies the header and passes

the packet to the appropriate output interface.

Conventional data planes typically perform a simple lookup such as that shown here.

For example an IP router would perform a longest prefix match.

The open flow switches that we have been

talking about perform a match action data plain operation.

What if we wanted to perform a richer set of operations in the data plain

besides just a simple look up or a simple match action operation?

That would require additional customizations in the data plane.

Now to customize the data plane we merely need to recognize that

the data plane is nothing more

than streaming algorithms that operated on packets.

They match on some bits in the packet.

And they perform a simple action typically at the behest of the control plane.

The data plane of course can perform

a wide range of functions including packet forwarding.

But also a more sophisticated set of operations

including access control, manipulation of packet header fields.

Traffic monitoring, buffering, marking the packet, traffic shaping.

In other words, shaping the traffic so that it does not exceed a particular rate.

And deep packet inspection.

In other words, looking into the payload of the packet.

For example, to determine whether malware might be present.

Now performing such a sophisticated set of operations in a data plane

obviously requires the ability to customize the data plane in various ways.

And software presents unique opportunities for customizing the data plane.

Network devices are quite diverse.

They range from routers to switches,

to load balancers, to depacket inspection devices.

Despite the diversity of these devices, it can be very difficult to add or

modify the functions of these existing devices,

often because the functions are implemented in hardware.

In particular, even with open flow switches, we see that

the switches are capable of a particular match action paradigm.

But that is really only one type of data plane.

So we'd like to think about whether we could extend

the capabilities of the existing data planes, potentially in software.

The design goals for a programmable data plane are flexibility,.

In other words we should be able to

perform a variety of different data plane operations.

It should be extensible so that if we want to

add new data plane operations that should be fairly easy.

And there should be clean interfaces

between different types of data plane operations.

To make it easy to compose different types of data plane operations.

Such as forwarding, traffic shaping, and so forth.

The click modular router is one

such customizable data plane implemented in software.

The key building block in click are elements.

Each individual element and click performs a unique data plan function such as

packet switching, lookup and classification, dropping, and so forth the

idea is that a developer of a customized data plan would take these click

elements and snap them together into a packet processing pipeline.

Here's a simple pipeline that takes packets from the E zero interface,

counts them and discards them by assembling building blocks developers

can implement a variety of increasingly complex functions.

Running a click configuration is quite simple.

Let's just take a quick look at a configuration that

takes packets from an input interface, prints them, and discards them.

You can see here that the configuration is very simple.

We take a source element, something that captures the packets, send it

to a print element, and then send it to a discard element.

To run Click, we simply invoke the configuration file.

Now we can see that Click is printing

every packet that it's seeing on the interface EN2.

Now the examples that we have explored in this particular lecture are rather simple.

But you can explore a lot more on the Click homepage.

Which has links to both example configurations for various types of custom

data plan operations such as NAT, tunneling, IP routing, and so forth.

And a link to a list of elements that perform a variety of custom

data plane operations ranging from traffic generation

to classification to counters and timestamps, to packet

modification, to scheduling shaping and queue management.

It's possible to stitch together Click elements to build an entire IP router.

The configuration here shows how the various existing Click

elements can be used to build an IP router.

It's even possible to write your own elements

in Click and invoke them with the Click configuration.

So in summary, we not only need the control plane

to be programmable, but the data plane should also be programmable.

We have explored one way of customizing the

data plane through a programmable software router called Click.

The example configurations that we've seen, show that complex data

plane functions can be performed using simple building blocks.

And as it turns out, the performance

that Click provides is still acceptable for prototyping.

Various performance experiments show that Click is still about 90%

as fast as the base Linux system for packet forwarding.

There won't be any required Click programing assignments in this

course, but the module has an optional Click programing assignment

and I encourage you to check that out if you're

interested in learning a bit more about programmable data planes.