What is the role of Control Plane in the concept of P4-programming?

Getting Started with P4
1

Hello everyone,

I am a last year student at university and my thesis defense is about P4-programmable data plane. In this beginning period, I’ve just only read about basic concepts of P4-programming and I’ve bumped into a question that make me really confused, which is the title of this topic. I think it is important to me to have this confusion clarified before I continue to study more.

In my understanding, P4 lets us customize how packets are processed by the Data Plane, but when we define new rules in our P4 programs to the data plane, is there any conflict between P4 programs and the functionality of the Control plane?
For example, the Control Plane uses algorithms to form the routing table and apply its logic to the Data Plane to forward packets. Then in a P4-program, we also have a match-action table to forward packets too.
So what I don’t understand here is how the Control Plane and a P4-programmable Data Plane work together. What are the “actual tasks” of the Control Plane in this context? Or do we need a Control Plane any more?
Any clarification or helpful information is greatly appreciated.
Thank you very much!

2

You may want to have a look at [2101.10632] A Survey on Data Plane Programming with P4: Fundamentals, Advances, and Applied Research for a more detailed explanation.

In short: Somewhere, the content of the forwarding tables, a.k.a. routing, has to be derived. This is typically done in the control plane, which decides what to do when a packet with destination XX is received. The control plane may decide that the corresponding action should be to forward the packet through port Y. This abstract information is then stored in the forwarding table defined by the data plane. Hence, the data plane defines HOW packets are processed, and the control plane defines the logic behind the process to decide HOW packets are processed.

2 Likes
3

Thank you so much for your information! I’ll have a look through the document you’ve mentioned.

4

The set of P4 programs that do something useful even when all of their P4 tables are empty, i.e. they all contain no entries, is quite small, perhaps empty. It depends upon your idea of “useful”, of course, but any such program I can think of is at best a toy demo program for learning about P4.

Similarly, the set of P4 programs that do something useful even when some process comes in, adds an initial set of table entries to all the tables of the program, and then never adds, removes, or modifies any table entries ever again after that initialization, is also quite small, perhaps empty.

Most P4 programs are only useful if there is a separate control plane program (or set of programs) that are running as long as the network device is active, choosing at appropriate times to add, modify, or remove table entries in the data plane.

In practice, control plane software in useful systems tends to have 100x or 1000x times MORE lines of code than the P4 program. The P4 program handles the cases of packet processing that you want to stay in the fast path, and only those cases.

In a layer 2 / layer 3 device implementing Ethernet bridging, spanning tree, and one or several routing protocols for IP, control packets for these protocols are typically recognized in the P4 program, but the only processing done in the P4 program is to send them to a CPU port so that the control plane code then receives and processes them.

In many devices, packets with non-empty IPv4 options often get sent for control plane software processing/forwarding, too, as fully handling such IPv4 options in a fast path device is too complex to be worth the effort, since such packets are typically rare (granted, such packets are typically rare partly because so many commonly deployed network devices punt them from the fast path to the slow path, so there is a reinforcing effect going on here that keeps IPv4 packets with options uncommon in practice).

1 Like