Programmable ASICs and P4

One of the most exciting topics in current networking is the development of fully programable switching ASICs. This topic got special attention when OpenFlow was running into problems with static pipelines in current chipsets, and the burden of chipset vendors to support openflow on these pipelines as well as the constraints and problems Network Application developers ran into when trying to write cross platform code on different vendor pipelines.

In the top down view of OpenFlow, a controller is able to send a feature request to a switch, configuring the matches, actions and tables on the fly. This might work on a SoftSwitch, but this model does not work on a traditional hardware pipeline. After developing a "language" that was able to at least describe all the details of a fixed ASIC switch pipeline through the ONF called TTP, the need to develop a way to configure a switch pipeline was realized. It got also clear that this configuration needs to happen at switch boot time, and by that could not be instantiated as OpenFlow envisioned it.

The language to configure such a flexible switch pipeline is called P4. As they state on their website P4.org:

What is P4 about and what is P4 not about?

P4 is a high-level programming language for expressing how packets are processed by the data plane of any programmable packet processing device like switches, network interface cards(NICs), network processing units(NPUs), field programmable gate arrays(FPGAs), software switches, etc.

P4 programs describe the data plane behavior only. In addition to that, they allow the programmer to generate the application programming interfaces (APIs) that the control plane can use to communicate with or configure the data plane.

How does a P4-programmable switch differs from a traditional switch?

A P4-programmable switch differs from a traditional switch in two ways:

First, the switch’s data plane is no longer fixed. P4 programs describe the data plane functionality. The data plane is configured at P4-to-target compile time. P4 itself is protocol independent; it allows programmers to express a rich set of data plane behaviors.

Second, the control plane continues to interact with the data plane using the same channels; however, the set of tables and other objects driving the behavior of the data plane is no longer fixed, since those are derived from a specific P4 program. The P4 compiler generates the API that the control plane uses to communicate with the data plane from the P4 program.

This means that P4 is able to define the parsing behavior and matching fields, actions and tables on a switch ASIC. This pipeline can then be filled with entries using another control plane protocol like OpenFlow, or using the exposed API with another agent residing on the switch. It is important to note that the parsing behavior is not predefined. For Example, this code snippet would parse mac source and destination in the traditional way:

header_type l2_metadata_t {

fields {

lkp_mac_sa : 48;

lkp_mac_da : 48;

lkp_pkt_type : 3;

lkp_mac_type : 16;

}

}

But if you would not need the mac source and destination parsed, but prefer to parse both together as a kind of connection hash, you could redefine it this way:

header_type l2_metadata_t {

fields {

lkp_mac_sa_da_hash : 96;

lkp_pkt_type : 3;

lkp_mac_type : 16;

}

}

On the other hand, if you want to have the vendor OUI parsed as a separate field, perhaps to check it is a wireless client, you could refine parsing this way:

header_type l2_metadata_t {

fields {

lkp_mac_sa_oui : 24;

lkp_mac_sa_nic : 24;

lkp_mac_da_oui : 24;

lkp_mac_da_nic : 24;

lkp_pkt_type : 3;

lkp_mac_type : 16;

}

}

And if any future protocol would emerge, you could adapt your parsing accordingly, and support that new protocol on the fly. With a fully programmable ASIC, this would also mean that your hardware could be updated to support new protocols and their parsing, something which is not possible on fixed ASICs. These updates could allow to keep devices longer in your network by not needing to replace them to support newly developed protocols. It also allows resources to be freed up if certain protocols are not needed currently.