### Leveraging Software-Defined Networking (SDNs) in the Design of IIoT-Edge Networks
These SDN controllers are designed using different programming languages (JAVA, C++, Python), are compatible with different SBI and NBI application programming interfaces (APIs), are developed by different industry partners, and can be used in different application scenarios (see Table 3). [PERSON] et al. [95] categorize common SDN controllers (both open-source and proprietary) as (i) physically centralized (NOX, NOX-MT, POX, Maestro, Ryu, Floodlight, and Beacon), (ii) physically flat-distributed (ONIX, HyperFlow, OpenDayLight, ONOS, DISCO), (iii) physically hierarchically distributed (Kandoo, Orion, D-SDN, B4, Espresso), (iv) logically centralized (POX, Ryu, ONIX, SMaRtLight, HyperFlow, Ravana, OpenDayLight, ONOS, B4, SWAN, Espresso), and logically distributed (DISCO, D-SDN, Cardigan, SDX, ISDX, ToulX, AtlanticWave). **Application Plane:** The application plane hosts Representational State Transfer (REST)-based network applications and services such as network monitoring and analytics, security and compliance, load balancing, and traffic engineering that monitor the network's quality of service metrics [96; 97]. The control plane's controllers interact with these REST-based applications via the Northbound Interface (NBI) using the RESTCONF protocol [98; 99]. Other techniques used at the NBI are RESTful APIs, OpenFlow v1.3-1.5, NETCONF, Google Remote Procedure Call (gRPC), and custom APIs and protocols. Figure 5: Software-defined networking (SDN) architecture, where SDNC is the SDN controller at the control plane and FD is the forwarding device at the data plane. **Management Plane:** The management plane allows the network administrators to securely (via Secure Shell (SSH) or Telnet) access the application plane or control plane directly to make policy and flow modifications as and when necessary. Unlike traditional networks, vendor-agnostic SDN technology is increasingly being adopted in the design of industrial networks with several benefits. Decoupling the control plane from the data plane provides dynamic centralized control as the controllers deployed in the control plane have a global view of the network [73]. Further, with a global view, the controller can quickly detect faults in links and devices in the data plane and send alerts to the network administrator or autonomous applications running in the application plane [99]. Configuration and traffic engineering tasks can be automated, facilitating a simpler configuration and management approach that can be rolled back [80]. The network is programmable, giving the network administrators leverage to modify their networks to meet their customized intents and achieve the industrial service level agreements (SLA) or key performance indicators of the network [18]. There is reduced vendor lock-in as SDN can effortlessly manage a heterogeneous data plane comprising devices from different vendors [77]. Lastly, and most importantly, SDN achieves faster convergence times (of up to 100 us) than traditional networks (10-30 ms) because it can rapidly reconfigure network paths and forwarding behavior in response to faults or changes in network conditions [67]. Choosing the best-suited SDN controller (as listed in Table 3) to deploy at the control plane has proven challenging for researchers and network administrators. Several empirical studies used proof-of-concept simulation environments and OpenFlow Protocol Layer frameworks, such as Cbench, to evaluate SDN controllers based on network performance benchmark metrics such as latency, jitter, throughput, and packet loss. To be specific, Cbench is a stress-testing tool from the OpenFlow Protocol Layer for Investigating Performance of SDN (OFLIPS) framework, PktBlaster and OFNet [101]. These frameworks and tools were used to compare the SDN controllers based on the following benchmarks. **For the latency and response time benchmark:** Experimental studies evaluate the time it takes for each SDN controller to process and respond to the network requests. [PERSON] et al.