## 6 Challenges and Solutions for Next Generation of SDN  
SDN proposes the separation of the control plane from the data plane and the logical centralization of the intelligence in the control plane. However, this makes the control plane the most vulnerable plane, as faults in this plane have worse consequences than faults at the data plane because the SDN controller is embedding the forwarding intelligence. [PERSON] and [PERSON] in [68] demonstrated that, under certain conditions, the control plane can be responsible up to for 99% of all bugs in data center applications. An SDN architecture is still subject to some reluctance by different stakeholders, due to a number of factors, listed hereafter along with some solutions. * Protocol and standardization: The current version of OpenFlow switch specification is 1.5.1, which is openly available for SDN-supported switches configuration. However, SDN standardization in the form of OpenFlow is not scalable, reliable or efficient enough to fully handle all possible scenarios/use cases and managerial operations in hybrid cloud-fog systems, especially in 6G.Enhancing OpenFlow, northbound interface standardization, debugging capabilities of SDN, and east-west interface are some domains which need special consideration in standards [15]. Regarding the east/west standardization improvement, [PERSON] et al. [69] proposed a distributed SDN controller framework (DSF), which is based on real-time publish/subscribe (RTPS) standardization to address the challenge of synchronization in the distributed and heterogeneous control plane. The framework can support the flat, hierarchical, and hybrid/T-model. In the horizontal model, controllers communicate in a peer order; in the hierarchical model, controllers follow a chain of command in a tree structure; and in a hybrid model (comprised of vertical domain control and horizontal global view communication), information travels from domain controllers to peer controllers. The DSF presents the reliable and constant interfacing behavior for holistic topology discovery when the number of controllers is increased. Moreover, DSF supports the homogeneous and heterogeneous control plan entities. * SDN integration inside NFV ecosystem: The NFV term emerged in 2012 from a meeting of the founding group in Paris to distinguish the topic from SDN. The working group was hosted by ETSI. In the ETSI NFV drafts [70], it is still not clear the role of the SDN controller and its interface with the rest of the NFV ecosystem, especially for distributed environments, such as cloud-fog systems. * Budget constraints SDN evaluation: Full migration to SDN-based infrastructure can have various challenges, especially budget constraints. Ultimately, in the case of the cloud-fog system, it requires massive SDN component installation and softwarization supported equipment. It can harden the pure SDN deployment. Thus, these systems need a hybrid infrastructure, where the legacy and SDN-based devices, resources, routing protocols, services and virtual environments are interoperable and agreed to support the user expectation. From this agreed paradigm amalgamation emerges hybrid SDN for fog computing, where optimized resource provisioning, updating network information, and latency-aware routing are challenges. One of the hardening effects could be that a global controller (i.e., root controller) is unable to investigate the network topology or switch roles inline with speed as for pure SDN deployed components [63; 71]. * Hybrid SDN-traditional IP network architecture challenges: Hybrid SDN-traditional IP network architecture is a solution for now. Investments in hardware are expensive to fully adjust the network to SDN. Therefore, providers are willing to start with the hybrid SDN-traditional IP network architecture. Then, collecting the accurate network topology and commanding the devices that are not directly connected to the controller is a challenge.