A Survey on P4 Challenges in Software Defined Networks: P4 Programming

Software Defined Networking (SDN) has been a prominent technology in the last decade that increases networking programmability. The SDN philosophy decouples the application, control, and data plane to increase the network programmability. The data plane is an essential but unsolved component that receives less attention than control and application planes. Traditionally, the data plane uses fixed functions that forward packets using a limited number of protocols. The P4 (Programming Protocol-independent Packet Processors) language makes it possible to program SDN data plane, which push the SDN to the next level. In the research community and industry, programming the data plane has garnered significant attention. Surprisingly, there has been no comprehensive reviews of programmable data-plane switches, which have many advantages in today’s networks. The authors reviewed the evolution of networks from legacy to programmable data planes, explained the fundamentals of programmable switches, and summarized the network generation from traditional to programmable networks. In this paper, SDN is described from a P4-centric standpoint and discusses over 75 related research papers. Several taxonomies for the field are provided, outline potential research areas, and provide greater details regarding the patterns that have led to the development of this technology.


I. INTRODUCTION
As the network structure grows in size, the network management needs to be simplified. Enterprise networks significantly influence working environments [1]. However, the demand for delivering a growing volume of data and applications in real-time is rapidly increasing. Network technologies have become an essential components for almost all human activities [2]. The number of devices on the Internet and the amount of traffic passing through them are growing exponentially. Owing to the complex alliances between specialized packet-forwarding hardware and operating systems, network administrators can manage network hardware using other software packages [3]. This can be a customized network that blocks the development of new protocols and services. Network devices must be customized for a particular activity The associate editor coordinating the review of this manuscript and approving it for publication was Chakchai So-In .
to reduce engineering costs. However, there has been a push toward commodity and universal network devices [4].
Traditional networks are expensive to deploy and manage, and new-generation networks must overcome the rigidity of existing network architectures [5]. For large-scale organizations, the cumulative effect of rigidity can be disastrous concerning architectural investments. It can also take years to deploy new ideas, from design to simulation, testing, standardization, and installation of network equipment. Consequently, the network is at a critical stage and must be programmable [6].
Several technologies are used in these networks. Softwaredefined networks are fascinating technologies that encourage creativity in network management and design. Although SDN appears to have emerged rapidly, there has been a long history of attempts to make computer networks more programmable [7]. SDN allows network operators to create a custom network logic. SDN also enables device This paper is organized into six sections, as provided in Figure 1, to understand the SDN and P4 connectivity during the tera-byte bandwidth era. Section II gives a detailed overview of the evolution of SDN and the rise of P4 in networking technology. Section III explains the aspects of P4, its Architecture, and its components in detail. Section IV details the data-plane programmability, and the tabular format on a few papers surveyed is presented. Section V discusses the research challenges and opportunities, and the final Section VI concludes the study along with future trends.

II. UNDERSTANDING THE GENERATION OF NETWORKS
Before diving deeper into the survey, we provide an overview of the various developments that have led to the need for data plane programmability. This section provides further details on how network generation has changed from traditional to programmable networks, as shown in Figure 2. Figure 2 is explained in-detail in the further sub-sections. Each subsection outlines the changes that caused the networks to become programmable. This section concludes with the importance of P4 in SDN.

A. TRADITIONAL NETWORKS
Traditional networks operate over fixed-function equipment, such as routers, switches, and application delivery controllers. SDN provides flexibility to the network and adapts it to the growing networks and security. Traditional networking involves using dedicated devices to perform specific tasks. Traditional networks have always faced challenges in terms of flexibility and are expensive to deploy and manage. Traditional networks are hardware-oriented and SDN are softwareoriented. Vendors adopt SDN because traditional networking lacks flexibility and, most importantly, fails to adapt to the growing network and security. The control and data plane are tightly coupled and rigid to the functionalities, as shown in figure 2. 54374 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.

B. SOFTWARE DEFINED NETWORKS
SDN is the most prominent technology used by researchers to make networks programmable. SDN comprises Controller, Southbound, and Northbound APIs, and has been in the networking industry for more than ten years. SDN is a strategy executed when the network needs to be programmable [11]. The network control and data plane are physically separated, and the control plane can control multiple devices. The control plane is programmable with SDN built into it, as seen in figure 2 but the data plane is not flexible because programmability has not yet reached it. However, management and configuration are pushed to centralized consoles [12]. SDN has been widely adopted in Amazon, Facebook, and Google Data Centers [13]. The below sub-sections will take through the journey of SDN evolution and how did the data-plane layer was flexible.

1) OpenFlow
Once SDN stabilized, the OpenFlow protocol became popular and proved as of the most profound SDN protocols. The OpenFlow protocol is used to configure SDN-enabled devices. The OpenFlow protocol is a crucial component in the development of SDN solutions [14]. It acts as a communication protocol in the SDN controller to interact directly with network devices in the data plane [15]. All devices that communicate with the SDN controller must be compatible with the OpenFlow protocol [16]. Protocol standards have become increasingly complex in recent years. The SDN controller sends changes to the switch/router flow table via this interface [17], allowing network administrators to segment traffic, manage flows for optimal performance, and configure and apply new information [18]. Table 1 shows that first, the researchers focused on transforming IT, as it was a challenging task it is termed ''IT Craftsmanship.'' It took two decades for IT Craftmanship to become powerful, which is considered ''IT Industrialization.'' Researchers have also focused on functional operations [19]. Later, they added a control system to reduce the risks, termed ''Digitization.'' Finally, they made IT innovative, rapid, and flexible. Once this seemed perfect, there was rapid innovation in the so-called SDN. SDN has also been subjected to numerous trial-error methods. SDN 1.0 version bought up OpenFlow. As there were a few drawbacks from the first version, the SDN 2.0 version separated the overlays, and finally, the SDN 3.0 version was applied n-centric [20]. Following the development of IT and SDN. Then, a lot of changes in the field of technology were seen. In order to understand the evolution of programmable networks, we need to understand Figure 2. In this figure, it can be observed that there is a transition from the Traditional Architecture (left) to SDN Architecture (middle) and SDN Architecture with a Programmable Data Plane (right) using P4. Traditional architecture had tightly bound control and data plane, called ''tightly coupled.'' As SDN came into the picture, control, and data plane, are separated and had a bottom-up design. The information is shared using the OpenFlow Protocol. Currently, the new architecture seeks programmable data planes in SDN that followed a top-down approach. The programmable chip can be user-configured, whereas the SDN architecture has a fixed set of functions. SDN principles are well-defined and well-versed. All major cloud providers and data centers [21] use SDN. In the evolution of SDN virtualization, the king of virtualization called ''VMware'', acquired Nicira and renamed it as VMware NSX, which is the SDN-style network. NSX, which represents SDN, is used by hundreds of thousands of virtual machines in data centers worldwide [22].

3) WHERE IS SDN NOW?
SDN is not dead; it is still alive and it works surprisingly well responding to what is going on in the current network market. Many researchers assert that SDN does not exist; however, this is incorrect. SDN is present in all virtualized networks and software-defined networks. Instead, it includes an SDN, allowing it to outperform its prior generations. This is similar to how analysts have predicted the future of SDN in the past. However, it is no longer referred to as SDN because it has been integrated into today's tools. As a result, it is referred to alongside its tool name, for example, SD-WAN (Software Defined Wide Area Networks).

4) WHERE SDN IS IMPORTANT?
SDN is significant and allows network operators to combine software and hardware from multiple vendors and create customized network services and infrastructure.
• Software-defined networking improves network connectivity for sales, customer service, internal communication, and document-sharing.
• SDN enables organizations to create customized network services and infrastructure by combining software and hardware from multiple vendors.
• A virtual network combines SDN, network function virtualization, and white boxes.
• SDN allows for faster deployment of new applications, services, and business models.

5) WHY DOES SDN NEED P4?
There are many challenges faced by SDN. Firstly, it requires time to implement new protocols and extend the functionality VOLUME 11, 2023 of current protocols. Secondly, protocols like ''OpenFlow'' in SDN lack operational and administrative interfacing. And the most important issue is to add new protocols in the OpenFlow protocol, which is a research-driven time-consuming process. Therefore, in comparison to traditional fixed-function switches, P4 programmability opens up entirely new possibilities for network stack flexibility from 7-layered OSI or 5-layered TCP/IP modeling. Second, there is a need for upgradability (hardware solutions will never have), which allows adding functions and protocols to network devices by updating the P4 software running on them rather than purchasing new switches and their frameworks. In summary, SDN has become a promising architecture for the centralized management of network architectures making networks dynamic, centralized, flexible, and programmable. Therefore, it is necessary for the SDN to acquire P4 in its environment.

C. DATA PLANE PROGRAMMING
Data Plane Programmability is a buzzword owing to its varied scope and functionality [23]. P4 is a programming language that allows users to write custom protocols, build complex match/action pipelines, and include external functions in the code [24]. A programmable data plane is a flexible way to forward packets that can handle various formats and protocols [25]. Programmable data plane in the next step in enabling switches to perform complex packet operations. However, they cannot perform all tasks alone [26], [27]. P4 is used to configure the forwarding actions. P4 [28] was created for data-plane programming. As a result, P4 defines the actions that can be performed on packets [29], where the control and application plane are already programmable, and data plane programming is the missing link.

1) RISE OF P4
With the enormous growth in data traffic, new protocols, and private-public clouds, the rate of innovation in the networking world is increasing. The transition from traditional silicon switches to flexible programmable switches has now been completed and requires a new standard language. This new language must meet the following three basic requirements.
• The language should allow the network to be flexible.
• The language used should be expressive and comprehensive.
• The language must be portable from one architecture to the next.
The figure 3 P4 language's evolution and development are depicted. The P4 language draft was submitted in 2014, and it was first introduced globally in May 2015. The P4 community clarified the distinction between the OpenFlow and P4 languages in 2016, after many misunderstandings. In May 2016, the second version was introduced as P4 16 , while the older version was known as P4 14 .
The figure 3 depicts the evolution and development of the P4 language. The P4 language draft was submitted in 2014, and it was first introduced globally in May 2015. The P4 community clarified the distinction between the OpenFlow and P4 languages in 2016 after many misunderstandings. In May 2016, the second version was introduced as P4 16 , while the older version was P4 14 . P4Runtime was introduced and embedded into the control plane in July 2017 to run P4 programs. Many large-scale networks have adopted P4 due to scalability, feasibility, and reconfigurability. P4Runtime v1.0 was released in 2019, and P4Runtime v1.2 was released in 2020.
As listed in Table 2, various versions of P4 have been developed since 2013. The initial idea began with a team of researchers in May 2013. Finally, the researchers submitted their first draft proposal for P4 to SIGCOMM in July 2014. Once they received approval, they transformed the paper and submitted it in August 2014. Finally, P4 is accepted as a programmable language. It was called P4 14 . P4 14 was introduced in four different versions. However, P4 16 was introduced with new data types and control statements to fill loopholes in the P4 14 . The programming language P4 is gaining popularity in the network industry [30].
P4 is the name of the first language release and P4 14 is the current language specification. P4 14 is a simpler language, but P4 16 has additional features that may not be compatible with P4 14 [31]. The current language P4 16 will be syntactically correct with the future versions of the language. Simultaneously, many native P4 14 language features have migrated into libraries of fundamental constructs required for writing effective P4 programs [32]. This includes target-specific implementations of certain functions (counters, meters, and checksum calculations), referred to as externs.
P4 (Programming Protocol-independent Packet Processors) is a domain-specific language used to control packets sent to data plane in networking devices. It consists of constructs, such as counters, registers, header field specifications, and support for matches and action tables. It is specially designed for the data plane, which checks the correctness of SDN switch behavior. With P4, custom header formats can be defined, and dynamic header parsing can be performed. The P4 program is written in a specific format and must include the following: header, parser, deparser, match + action, checksum verification, ingress, egress, and checksum computations. One section depends on the other in the program, which performs functions.

2) WHY COMMUNITY DESIRES P4?
P4 is a network programming language that describes the packets processed using a programmable forwarding details. It is a programming language that allows network devices to be programmed with new features [33]. P4 provides a simple set of tools for imposing a community stack on the developer switching hardware. The tables with user-described keys with actions, counters, meters, and abstractions can be used as header types and partners. P4 has no understanding of how the Ethernet or IP headers look. Only the developer can tell the hardware of an Ethernet header, how to parse, match, and depart, and finally, which port the packet should be forwarded to. This programmability opens up new opportunities for flexibility of the network stack compared to traditional fixedfunction. It can upgrade network devices with new features and protocols instead of buying a new switch.

D. RECENT TECHNOLOGY
Recent chip design schemes have demonstrated that flexibility can aachieve terabit-level speeds in custom ASICs [34]. Therefore, it is difficult to create a new generation of switching chips. Similar to microcode programming, each chip had its low-level interface. The switch was configured using P4. The forwarding table was sent to the fixed-function switch via an existing protocol interface (such as Open-Flow). P4 raises the abstraction level for the programming control network [35] and functions as a standard interface between the controller and the switch. In other words, researchers believe that the future OpenFlow protocol generation allows the controller to tell the switch how to do so without being constrained by the inherent design of the switch [36].

III. P4 ECOSYSTEM
This section provides an in-depth understanding of the P4. P4 is a domain-specific language used to program the data plane of the switch. It is target-independent and protocol-independent and allows the controller to define its packet analysis and header-processing process. While writing P4 program, three major goals must be met: 1) Target Independence: The P4 compiler should consider the switch's capabilities when converting the target-independent P4 description into a target-related program for configuring the switch. 2) Protocol independence: A switch doesn't need to be bound by a specific packet format. However, the controller should be able to specify the following: • A packet sniffer can extract header fields of specific names and types.
• These header regions were processed using a collection of ''match-action'' tables. 3) Re-configurable: The controller should be able to refine the packet analysis process of the data packet and the processing process of the header area

A. P4 ARCHITECTURE
It is necessary to concentrate on understanding how P4 enters various functional processing blocks. P4 enters different blocks of the functionality and processes. Figure 4 and figure 5 describe how data packets are transmitted on various forwarding devices (such as Ethernet switches, load balancers, and routers). This has enabled the researchers to develop a universal language to describe how to process data packets by using the universal abstraction model. There are two different architectures: P4 14 and P4 16 architectures.   stage matching-action process to forward incoming packets, which can be either serial or parallel. This architecture is widely used as it makes use of additional constraints to solve the problems. Figure 5 depicts the P4 16 architecture. P4 16 follows a Portable Switch Architecture and can be implemented on any switch target. The multiple networking functions implemented in the PSA are combined into a single pipeline. The pipeline has the following components: parser, checksum validate, ingress match-action, packet buffer, egress matching action, checksum update, deparser, and buffer queuing engine.
The switch uses a programmable parser and performs a multi-stage matching-action process to forward incoming packets, which can be serial or parallel. The ABS model [37] contains three generalizations based on OpenFlow research. OpenFlow assumes that the ''matching-performing actions'' stages are sequential, and the model allows for parallel/serial execution. The model assumes that ''actions'' are written using switch-supported protocol-independent primitives.

B. P4 COMPONENTS
The P4 program contains definitions of the following key elements: 1) Headers: The sequence and structure of the series of header areas are described in the header-definition section. Each header is processed by a state machine that uses the value of the current header to trigger the next transition in the state machine. This specifies the length of the area and limits the value of data in the area. The header-type P4 was similar to the C structure.
In addition to the standard packet headers, P4 allows custom headers to be processed, including Ethernet, IP, TCP, and UDP. The standard and custom headers were explicitly processed. For example, standard ethernet and ipv4 headers in P4 are specified as below.
2) Parser: A parser's definition explains how to recognize the header and the effective header sequence in a data packet. The parser in the program specifies how packet headers are parsed. It checks and identifies the header present in the incoming packets. After parsing, the parsed packets were sent to the control block. The underlying switch can implement a state machine that traverses each header of the data packet from start to finish, thereby extracting the value of the header area while it is running. The extracted header area value is sent to the ''match-action'' table for processing. P4 describes the state machine as a collection of transitions from one header to another. The current header value can then be used to trigger the transition. For example, the standard structure of the parser is specified below.
3) Table: The mechanism for packet processing is the ''Match-Action'' This section discusses the working flow of P4 in detail. Figure 6 shows the workflow for P4. The P4 program comprises two operations: configuration and delivery. The configuration operation determines the order of each stage of the ''matching-perform action'' and specifies the protocol header area to be processed in each stage. By configuring the switch, we can determine which networks are supported and how the data packets can be handled. The operation issued adds or removes the entry from the ''Match-Action'' table.
The table itself is one of these, and it is specified during the configuration operation. The issuing process determines the execution strategy used by the data packet at any given time.
The working flow of the P4 program is depicted in Figure 6. Each program block performs a unique function. Each section of the P4 program is linked to a different block that performs a specific function. Furthermore, as shown in 6, the P4 program is divided into four major sections: data declaration, parser logic, a match-action table with control flow, and deparser logic. A parser, ingress, scheduler, egress, and deparser are required to run the P4 program successfully.
The packet parser is the first to process the arriving data packets and search for specific areas from the packet header, specifying switch protocol support. This model makes no assumptions about the meaning of the protocol header. Instead, the parsed data packet representation defines a set of header regions on which the 'matching-performing actions' process is performed.
Data packets contain metadata, which is extra information that can be passed between processing stages. Metadata can be used as a packet header area as well. Examples of metadata include ingress port numbers, transmission destinations and queues, timestamps used for packet scheduling, and data passed between the tables. Data such as the virtual net identification number did not change the performance of the data packets after parsing.
The match-action table received the extracted header area. There are two sections in the match action table: the entry and exit tables. The entry table determines the queue in which a data packet is placed. Data packets can be forwarded, copied, discarded, or triggered by flow-control-based ingress processing. When a packet is copied by multi-cast, the egress ''match-action'' is modified separately for each action target on the packet header. An action table is linked to tracking the status of each frame.

IV. DATA PLANE PROGRAMMABILITY
Data-plane programmability refers to the ability of a network device to expose low-level packet-processing logic through a standardized API, facilitating comprehensive and methodical reconfiguration. The creation and acceptance of the SDN paradigm have greatly expanded the flexibility, and dynamicity of device functionality [38]. Conventional network equipment cannot often be updated throughout its lifetime because the data plane functionality is tightly integrated into the hardware and software of the device. In software-based packetprocessing systems, considerable vendor-software changes are required to alter the functionality of the data plane. This survey is broadly classified into six sections: SDN with dataplane programmability, data-plane architectures, data-plane VOLUME 11, 2023 abstractions, data-plane network monitoring with data-plane Programmability, P4 challenges, and data-plane applications. Tables 3, 4, and 5 present a detailed review of the existing studies. The primary contributions of this study are as follows.
• This study analyzes and highlights the key factors that have evolved from traditional network architectures to P4-Programmable SDN architectures.
• Detailed understanding of P4 components, their architecture, and workflo is explained in-detail • Literature review is done on the following parameters: performance, security, load balancing, along with its strengths and weaknesses. It which gives overall novel summary for P4-based solutions.
• A major problem in the data plane programming area is identified and discussed in the further section.

A. SDN WITH DATA-PLANE PROGRAMMABILITY
According to the survey, softwarization and current SDN platforms may not be able to handle the complexity and heterogeneity of many needs, such as strict latency, jitter, high-accuracy traffic, and advanced monitoring. SDN/NFV [39] must be upgraded to enable these services, considering data plane programmability in addition to orchestration and control plane [40]. A software layer for softwarization was created to overcome these limitations, allowing the switch data plane to be programmed using high-level programming languages and APIs. Thus, the P4 language curriculum is becoming increasingly essential and well-planned. With its cutting-edge SDN/NFV softwarization, P4 initially developed for intra-data census scenario, has rapidly gained prominence. The difficulties encountered by P4 are discussed, along with the solutions, in Table 3.

B. DATA-PLANE ARCHITECTURES
A survey of the data plane architecture showed that low-level programmability is now supported by a larger range of devices and operations, despite the fact that switches are initially the primary focus of data plane programmability (particularly in data centers) [41]. Programmable data plane hardware or software is increasingly used for middleboxes (such as firewalls or load balancers) and general network processing, in addition to packet switching. Additionally, programmable NICs at the network edge enable data plane programmability [42]. These gadgets can be realized on top of one or more architectural designs. However, the difference between the software and hardware data plane was hazy. For instance, a hardware-based device might nevertheless use a general-purpose CPU to execute activities in which the underlying hardware is not designed to handle or that do not require significant performance. Current software switches increasingly rely on domain-specific hardware features, such as SmartNIC, which offloads packet processing logic to hardware via Data Direct I/O (DDIO) and Receive Side Scaling (RSS) [43].

C. DATA PLANE ABSTRACTIONS
Control plane technologies differ in a number of aspects, such as the primitives for packet processing they offer and the language constructs that can be used to combine these incentives to build specific pipelines [44]. The following sections examine some of the most common abstractions used and disclosed in programmable data plane systems in light of this inherent architectural relationship. The first step involves discussing programmable packet-processing pipelines before moving on to abstraction for packet parsing and scheduling. The final step in our exploration of programming languages and compilers is their examination.

1) PROGRAMMABLE PACKET PROCESSING PIPELINES
The main advantage of programmable data plane is the adaptable packet processing. The two main abstractions on top of which modern packet processing pipelines are frequently built are the match-action pipeline abstraction and dataflow graph abstraction. To create programmable switches, early packet processing systems adopted data flow graph abstraction [45] and machine learning [46]. In addition, stream processing frameworks, such as Apache Flink and Spark, heavily utilize this architecture. When representing the processing logic as a graph, a data flow graph uses nodes to represent the basic computing steps and edges to indicate the data movement between these stages.

2) MATCH-ACTION PROCESING
Data-plane applications are described using a hierarchical set of lookup tables (flow tables) in match-action abstraction [47]. Proposed a model for the effects of match-action tables on the routers. For packets to be processed correctly, a table query is performed based on portions of the header fields. This allows the switch to perform actions, such as rewriting packet components, encapsulating or decapsulating tunnel headers, dropping packet, forwarding packets, and packet processing delays until flow tables are created [48].

3) PROGRAMMING LANGUAGES AND COMPILERS
SDN initiatives, such as OpenFlow, ForCES, and NETCONF, have taken the field beyond low-level protocols over the past few years. The declaration of packet processing policies within a specific switch architecture is made possible by new high-level data plane programming languages in terms of abstract, general, and modular language constructs [49].
Operator expectations for more complex SDN applications are the main driving forces behind these initiatives. Owing to the availability of more programmable line-rate networking hardware, linguistic methods have been used to specify line-rate switching architectures (i.e., match-action tables and protocols supported by the parser) [44].

D. NETWORK MONITORING WITH DATA-PLANE PROGRAMMABILITY
The most exciting data-plane offloading applications are network metering, measurement, monitoring, and de-bugging. This is primarily due to the fact that these applications share certain characteristics that make them especially well-suited for data plane-based implementations: They must meet strict performance standards and handle a tremendous amount of VOLUME 11, 2023 54381 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. traffic. The data plane can directly and quickly access the input data used by the monitoring program, such as, the network packets or data plane measurements. The performance of P4, when combined with modern networking tools, is presented in Table 4. Furthermore, we examine P4 performance in more detail and show how P4 measures up in terms of TCP, Black Box approach, CPU cores, and PAM, among other metrics.
In [50], a number of solutions were presented to improve insight into network behavior. One of these solutions is the Tiny Packet Program (TPP) interface, which allows end hosts to actively access and modify internal network data. It is based on the Active Network concept and works on Smart Packets [51], which were first presented for switch network administration and monitoring. The ''division of labor'' theory forms the basis of the strategy: End hosts perform flexible computation on the network state switches move forward while carrying out TPPs in-band at line rate.

E. P4 CHALLENGES
Both the science and art of designing programmable switches are based on abstraction. An abstraction should ideally be basic enough to encapsulate the optimal amount of changeable data plane functionality, while also being expensive enough to enable the top layers to synthesize complex packet processing behavior. Additionally, the control plane should be able to use such an abstraction with ease, owing to a reliable and secure data plane API [53]. It must provide a well-defined consistency mechanism and effectively handle the global states in the data plane. It should also allow automatic program alterations to improve performance [54] and analytical performance models. It must distinguish between dynamic behavior and static semantics. Additionally, a useful conceptual framework should be included. The survey demonstrated that P4 worked well, and could be applied to extensive networking. The OpenFlow Protocol and P4 Language explanations are provided in Table 5. Both are unique and fulfill functions that are unique to them. discusses the P4 programming language and SDN. The P4 language and the OpenFlow Protocol are both confusing. The majority believe that P4: eventually replaced OpenFlow, and P4 and OpenFlow became interchangeable. However, this was not the case. Both are distinct from each other and excel in their role.

F. DATA PLANE APPLICATIONS
With the introduction of programmable data plane, network devices can be configured to perform specific generic information-processing capabilities, such as telemetry, massive data processing, machine learning, and even whole keyvalue stores. The ability to configure network devices allows a dumb pipe that can only move data to suddenly become a complete and, a sophisticated data-processing pipeline that can transform data as it passes. Load balancing can be achieved by connecting resilient routing to programmable data plane, which can then be used to distribute traffic dynamically across several forwarding channels, workers, and backend servers. For example, Hedera [55] compared their results to those of a load balancer. The ''resource pooling'' idea is to be realized via horizontal scaling, which makes a group of different resources behave like a single pooled resource in order to benefit from statistical multiplexing, load dispersion, and improved failure resilience. HULA [56] is a scalable load-balancing approach that uses programmable data planes to overcome the shortcomings of ECMP routing and currently employs congestion-aware load-balancing techniques, such as CONGA [57]. HULA is adaptive and scalable because each switch tracks only the congestion for the shortest path to a destination through an adjacent switch. Another example of 54382 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.  a load-balancing application is SilkRoad [58], which employs programmable ASICs to produce faster load balancers.

V. RESEARCH GAPS AND CHALLENGES
The authors noted significant research voids in P4-programmable switches, which they intended to fill by demonstrating that P4-based solutions for DDoS detection, load balancing, packet aggregation, and disaggregation are the components of community monitoring. The paper distribution of the surveyed research papers is depicted in Figure 7 from 1999 to 2023. The 75 papers are currently being reviewed. Figure 8 depicts the distribution of studied papers across various categories. SDN, P4, Large-Scale Networks, Data Plane Programming, P4 Switch, Data-Plane Load Balancing, Data Center Networks, and Network Performance are the broad categories of the papers.

A. RESEARCH GAPS
From the reviewed papers, the observed research gaps are as follows: • Most researchers test their operation on non-functional BMv2 switches because they do not support configuration, monitoring, and operating protocols, such as Open-Config, gNMI, and gNOI. Furthermore, compared with physical hardware switches, the computing power of the BMv2 switches is quite low. The authors noted that there are significant research voids in P4-programmable switches and that production-ready platforms such as stratum-based switches will allow the research community to test P4-based solutions.
• The currently available P4-based solution does not distinguish flash traffic from attack traffic, and attackers can use low-frequency DDoS attacks to circumvent security solutions.
• Some DDoS defense solutions use synthetic data sets generated by local traffic generation tools. There are no reference data sets that include both malicious and normal traffic. Some research papers use small topologies in their experiments, making validation impractical.
• For switch ASICs, some authors implemented loadbalancing algorithms using P4. However, data connections must be stored in a large amount of memory within a switch. Another research area is the development of efficient load-balancing solutions for data plane switches with limited memory.
• Most network-monitoring solutions require a significant amount of computational resources, which may cause performance bottlenecks. Only a few studies have divided monitoring tasks among data plane switches. Although these solutions improve network performance, they have synchronization and communication overheads. A major research challenge is to perform distributed monitoring in programmable data planes with a minimum amount of synchronization and communication overhead.
• The implementation of network-monitoring solutions is expensive. Research is required to identify the root cause of network problems, but none of these solutions uses popular open-source SDN controllers. Therefore, flow statistics are reported only in the event of a network issue. However, it is possible to result in the omission of some information that is required to determine the source of the problem. Debugging network problems and identifying root causes.
• Ryu, OpenDaylight, or ONOS are used to control the P4 programmable data plane. Therefore, a major research topic is integrating P4 programmable data planes with SDN controllers because it facilitates the migration of existing SDN applications to the SDN-programmable data plane model and enables the centralized management of P4 programmable data planes.
• Despite reducing the control plane computation and communication overhead, P4-based solutions can increase or reduce switch complexity in the data plane.
Research is still needed to determine how to deploy P4-based algorithms in switches while minimizing complexity effectively.
• Currently, research is focusing on programmable switches. However, the real challenge in fully deploying these solutions is replacing all the existing switches with programmable switches with fixed functions. It is an unresolved research problem to integrate fixed-function switches alongside programmable switches and check the performance of the network.

B. CHALLENGES
In this section, we discuss the research challenges based on state of art literature.

1) DESIGN ISSUES IN P4
P4 did not support loop constructs, pointers, references, or dynamic memory allocations. Consequently, algorithms that require deep packet inspection are difficult to implement [59]. Because P4 does not support arithmetic logarithmic functions, the DDoS detection algorithms were implemented by estimating the entropy value rather than computing the exact entropy using the longest prefix match tables. This is an open research challenge, owing to the inclusion of linguistic constructs. As a result, the research community is confronted with an open research question.

2) COSTS AND P4-PROGRAMMABLE SWITCH AVAILABILITY
Only a few firms produce P4 ASICs [60], and replacing a fixed-function device with a programmable device is more expensive than adding a traditional device to an existing network [61]. P4 specialists are also required to define the behavior of the programmable switches [62], and their integration of SDN and traditional networks remains a research challenge. To define the behavior of programmable switches, P4 specialists are also needed. The integration of SDN with traditional networks [63] remains a research challenge. SDN networks have also become more complex owing to the addition of programmable data planes. To solve these problems, incremental deployment is necessary. This requires gradually introducing programmable and fixed-function SDN devices into traditional networks as viable options. The Paxos protocol [64] is the foundation for several fault-tolerant distributed systems and services. The implementation of Paxos is a critical use case for P4 and will help shape the data plane language requirements in general. PISCES [65] is a software switch derived from OpenvSwitch (OVS), a hard-wired hypervisor switch whose behavior can be customized using P4. PISCES is not hardwired to any specific protocol, making it simple to add new features.

3) DATA PLANE SECURITY
Active networks [66] was the first research effort on programmable networks in the late 1990s. Therefore, the concept of programmable networks is a new one. However, it has not been widely adopted owing to its lack of security. Similarly, the P4-Programmable data plane has some security issues. Bugs are used more commonly in software applications than in hardware applications. In addition, the forwarding behavior of the [67] data plane is usually determined by less experienced and less prudent end users than by providers. Second, attackers can use programmability to change the forwarding behavior of the device to mitigate new attack vectors. Therefore, it is necessary to add assertions to programs and perform verifications to improve the security of the programmable data planes. To protect network links between P4-based SDN switches, MACsec [68], a widely used IEEE standard for securing Layer-2 infrastructures, will be deployed automatically. The MACsec is supported by a wide range of switch and router manufacturers. It has only minor performance limitations on these devices compared to VPN technologies such as IPsec. P4-MACsec is a MACsec data-plane implementation proposal.

4) ABSTRACTIONS
Both the science and art of designing programmable switches are based on abstraction. In a perfect world, an abstraction would be simple enough to encompass just the right amount of configurable data plane capability while simultaneously being expressive enough to allow the top layers to synthesize complicated packet processing behavior. Additionally, the control plane should be able to easily use such an abstraction, owing to a reliable and secure data-plane API [69], [70].

5) RECONFIGURABILITY
The goal of moving from OpenFlow to P4 is to expose a switch's processing capabilities flexibly and efficiently, including programmable packet parsing and general scheduling and queuing systems [71]. It extends beyond how packet-processing regulations are modeled in the data plane, including how packets are linked to specific processing operations. In particular, changing the data-plane behavior at runtime is difficult without affecting packet processing [72].

6) SCALABILITY
Designers are investigating more complex solutions to handle the application states in the data plane [73]. However, stateful techniques for packet processing are still in their infancy, and no clear leader has yet been identified, whereas stateless approaches are currently steady. Stateful abstraction is challenging because it must address state management challenges (such as consistency) in a manner that is user-friendly for programmers and that guarantees high performance. This is particularly difficult because one of the leading causes of performance problems in contemporary computer systems is still frequent reading and writing to memory, which is constantly required in workloads involving packet processing [74].

7) DATA PLANE VULNERABILITIES
The data plane composition, or downward mapping of the data plane from the intent layer, is a part of this issue. The difficulty of automatically adjusting the network to changing environments is closely tied to the need to verify the accuracy and intended impact of the configuration adjustment. The control loop must include an upward mapping of the data 54384 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.
plane from the intent layer, and the data plane must be operated securely, because programming increases the possibility of introducing vulnerabilities. Recent discoveries suggest that the network should be built with security and verifiability in mind from the very beginning [75], demanding new abstractions that must be operated securely because programmability increases the possibility of introducing vulnerabilities and additional attack surfaces. This is performed to verify the accuracy of the proposed method.

VI. CONCLUSION AND FUTURE TRENDS
This article provides a survey of programmable data plane and the related taxonomy is discussed. The P4 language is briefly described, along with research gaps and future trends. This survey examines the transition from traditional, to SDN to programmable SDN using P4. Following this, the evolution of networking, the importance of data-plane programmability, and the abstract model structure of P4 are discussed in detail. P4, the de-facto language used for programming the data plane of SDN is briefly described. The survey sheds light on numerous significant works and compares schemes within each category in the taxonomy, as well as with the legacy approaches. In the research challenges, we discuss various future trends and initiatives. This research leads us to the conclusion that open-source architectures and data network programming will dominate the network domain in the future. Thus, SDN + P4 would be an ideal environment in the upcoming years.

ACKNOWLEDGMENT
There is no conflict of interest among the authors and the publication body. We acknowledge the support of Prof. Raja Jurdak and Queensland University of Technology for this research.