# Software-Defined Named Data Networking in Literature: A Review
## 5 Discussion  
The examination of the literature presented in Table 2 revealed that current SD-NDN models are typically tested within limited network scopes. As a result, scalability becomes a significant concern, primarily because the controller is burdened with an excessive number of queries. Moreover, the controller's role in maintaining data prefixes for the entire network or network zone proves impractical in terms of resource allocation and the efficiency of table lookups. From this, we can identify the following open research questions and challenges that researchers might consider when integrating SDN and NDN:  
* Existing SDN controllers and southbound APIs are not compatible with the NDN framework. As a result, most of the models in Table 2 had to have their own SDN-like controller software developed, and these may lack some features that known SDN controllers possess. * Alternatively, if existing SDN controllers, such as Floodlight, are to be used, one must consider the fundamental differences in the protocol stacks between SDN and NDN. SDN uses the IP stack to carry packets, while NDN eliminates the IP stack and relies solely on content names. Implementing a model that integrates both NDN and SDN requires modifications to either the SDN or NDN protocol stack. Two examples of changes that can merge existing SDN controllers with NDN include the following:
* Encapsulating SDN packets in NDN packets or vice versa, and
* Adding an additional layer to the SDN or NDN protocol stacks. In [46], the authors encapsulated NDN packets in SDN packets by employing OpenFlow switches. These switches acted as a proxy between the SDN controller and NDN nodes, transforming NDN packets into SDN packets that could be processed by an SDN controller. In contrast, reference [54] aimed to preserve the characteristics of both SDN and NDN. This was accomplished by adding additional layers to the NDN stack for use by SDN controllers, as illustrated in Figure 8. This allowed SDN controllers and switches to communicate with each other using the IP stack, while NDN nodes communicated using the NDN stack. * When designing an SD-NDN model, one should consider the memory overhead of storing global data prefix tables in SDN controllers, as this consumes storage and increases table lookup time, leading to increased data retrieval times. * Similar to the above point, controller scalability should be considered when designing an SD-NDN model, as controllers have limitations in the number of inquiries they can handle. A critical consideration is determining how many requests and routers a single controller can effectively manage. In [21], an approach was taken to prevent overwhelming the controller by allowing routers to drop interest packets not found in their FIB, rather than forwarding every unmatched interest to the controller. Additionally, in [24] and [17], an interest is sent to the controller only once, and the controller responds with the end-to-end forwarding path. This path is then forwarded, along with the interest, to the next hop by the router nodes. This contrasts with [27], where the controller is responsible for sending forwarding updates to all routers in the route of interest. * A viable solution should be adaptable to dynamic topologies, especially in the context of mobility. In [28], controller discovery involved a node flooding the network to find a controller, accommodating node mobility. Conversely, [24] employed a strategy in which a controller floods the network to announce its presence, allowing nodes to bind with the controller. The former supports node mobility, while the latter supports controller mobility. However, it seems more practical to prioritize support for node mobility over controller mobility, given that controllers are less likely to change their locations. * One of the factors that affect the performance of SD-NDN models is the request processing time and route discovery algorithms of the SDN controller. Most of theaforementioned solutions rely on the Dijkstra algorithm.