# A Performance Evaluation for Software Defined Networks with P4
## 1 Introduction  
Software Defined Networking (SDN) [1, 2] allows for the decoupling of the control plane from the data forwarding plane facilitating an improved performance via programmable network management. The flexibility obtained enables virtualisation, and centralised control for the network, with routing tables being generated and updated centrally by an OpenFlow controller. The separation of the control plane and data plane is made possible through a clearly defined interface which connects the switches to the network controller. This interface employs an Application Programming Interface (API), which allows the controller to exert direct control over the data plane elements (networked devices). The protocol OpenFlow [3, 4], is a notable example of such an API. An OpenFlow forwarding rule consists of a'match' and 'action'. The'match' involves the matching of packet header fields such as source and destination fields and an 'action' to be performed such as forward or drop a packet. This function is referred to as'match+action' [5]. The controller installs these flow entries in the Flowtables of the SDN enabled devices. If a matching flow entry is found against a packet in the data flow, then the predefined action (pass, drop) for that entry is performed on the matched packet. If no match is found, the packet is forwarded to the network controller as a Packet-in Message. The controller is responsible for determining how the packet should be handled. This involves returning the specific packet to the switch and stating which port it should be forwarded to (Packet-out message). OpenFlow was first introduced with 12'match' header fields [6], which have now been increased to 44 header fields, as described in the OpenFlow specification 1.5.1 [4]. These are anticipated to grow exponentially in the foreseeable future, in response to the evolution and heterogeneity of the internet. This could potentially be a problem as the application of new header field extensions cannot be achieved when using a stringent-fixed parser at run time, whilst the switches are processing packets. An alternative to extending the OpenFlow specification is to employ a novel parser that can carry out'match+action' in parallel allowing for programmability in the data forwarding plane without having to modify the OpenFlow specification. In our abstract model, switches forward packets via a programmable parser followed by multiple stages of match+action, arranged either in series, parallel or a combination of both. The forwarding model is controlled by two types of operation: Configure and Populate. The Configure operation, which is composed of Parse graph, Control Program, Table configuration, and Action set; program the parser, arrange the order of match+action, and specify the order of fields processed by each stage. The Populate operation, adds and removes entries to and from the match+action tables that were specified during configuration. Such a parser can be updated, extended, and modified without interrupting packet processing and forwarding, thereby enabling the integration of heterogeneous applications. A protocol that can be employed to carry out'match+action' in parallel is P4 the Programming Protocol for Independent Packet Processing [6]. Parallel processing can be achieved in P4 by employing one of the following. 1. Multiple Processing Cores: Some network devices have multiple CPU cores or processing units. P4 programs can be designed to distribute packet processing tasks across these cores to achieve parallelism. For example, one core might handle packet parsing, while another core handles packet forwarding. 2. Parallel Pipelines: P4 allows the definition of multiple packet processing stages within a pipeline. These stages can be designed to operate in parallel, with each stage processing packets independently. For instance, one stage might perform access control checks while another stage performs packet routing. 3.