## 3 Non-AI Consistency Solutions for PDLC SDN Controllers
### Discussion and Open Issues  
We present a summary of some of the notable works in industry and academia of PDLC SDN control planes that used the static or adaptive SDN consistency methodologies summarized in Tables 1-3. Interoperability between SDN controllers is a prerequisite for these distributed controllers. However, we can notice from the comparison tables (Tables 1-3) that each SDN-distributed controller platform has its own communication method. This makes it difficult for the SDN network to share data across various domains. This highlights the East-West interface implementation challenge of PDLC SDN architecture as depicted in Figure 1.  
Furthermore, communication between controllers is typically facilitated through network protocols and messaging mechanisms. As observed from the literature [6; 11; 15; 34], there are some common approaches for enabling communication and updates between controllers. Some examples of distributed controller systems use a mixture of the following:  
* Message passing: Controllers can exchange messages with each other to communicate updates and exchange information. This can be performed using various messaging protocols such as MQTT, AMQP, or custom protocols implemented over TCP/IP or UDP. These include ElsticCon [25], which employs message passing as their communication approach among the controllers in the pool. * Publish-subscriber model: Controllers can subscribe to specific topics or events of interest and publish updates on those topics. Other controllers that are subscribed to those topics will receive the updates. This model allows for asynchronous communication and decoupling between controllers. Orion [26] utilizes a publish-subscribe approach for sharing state across its applications. * Remote procedure calls (RPC): Controllers can expose remote procedures or methods that other controllers can invoke to trigger updates or request information, such as using RESTful APIs. Floodlight [42] is an open-source SDN controller that exposes RESTful APIs for remote procedure calls. * Shared data store: Controllers can access a shared data store, such as a database or distributed key-value store, to read and write shared information. This shared data store can be a centralized repository where controllers can update and retrieve data. HyperFlow [11] is an SDN controller that falls under the publish-subscribe category and the \"shared data store\" category. It utilizes a WheelfFS [43] to read and write shared information for communication and coordination among controllers. In addition to the publish-subscribe model, Orion [26] also employs a centralized, in-memory data store called the Network Information Base (NIB), which acts as a shared state repository across the Orion applications. * Event-based communication: Controllers can generate and listen to events to communicate updates. Events can be published by one controller and subscribed to by others, allowing for event-driven updates and notifications. ONOS (Open Network Operating System) [24] is an SDN controller that fits into multiple communication approaches. It supports both the \"publish-subscribe model\" and \"event-based communication\" approaches. Controllers in the ONOS framework can subscribe to specific topics or events of interest and publish updates on those topics, enabling asynchronous and event-driven communication. The choice of communication approach depends on factors such as the system architecture, scalability requirements, latency constraints, and the nature of the communicated updates. Although standard static eventual consistency is commonly used in modern SDN systems to achieve effective scalability, it suggests a synchronization process at fixed periods (Tables 1 and 2). It is argued that it provides no bounds on the tolerated state inconsistencies by SDN applications. This may result in utilizing stale data and disrupting the network by sending unneeded synchronization messages. This creates an overhead and affects the deployed application's performance and scalability [18].