# Software Defined Networks in Wireless Sensor Architectures
## 2 Background
### Software Defined Networks
In order to get the most flexibility, it usually uses General Purpose Processors (GPP), such as the Intel Xeon [40], in implementations, but it also provides the disadvantage that the general purpose architecture is limited in terms of performance. Another choice is to use Network Flow Processors (NFP) [41] that are specialized hardware for processing data in form of packets. This solution furnishes very good performance, but, in contrast, the flexibility is reduced since it requires defining a treatment function for packets. As a result, a hybrid solution is the best option if the applications need both features and, therefore, is the only approach that satisfies SDN. Continuing from the last statement, the next challenge is how a hybrid architecture can provide scalability at the same time that the network grows up. The scalability can be divided into points of view: controller scalability and switch scalability. The main issue is within the network controller, which experiments with latency belonging to the exchanging of network information between itself and the switches that compose the network. The other is the way of communication between different controllers of distinct networks. Different approaches have been proposed to solve these problems. To solve the latency problem, a possible solution is to deploy an infrastructure with a distributed or peer-to-peer controller that shares the data load of itself. At the same time that this solution solves \begin{table}
\begin{tabular}{l c} \hline \hline
**Language** & **Controller Name** \\ \hline C/C++ & NOX, Trema, MUL \\ Haskell & Nettle, McNette, NetCore \\ Java & Maestro, Floodlight, Beacon, ONOS, OpenDayLight \\ OCaml & Mirage, Frenetic \\ Python & POX, Pyretic, RYU \\ \hline \hline \end{tabular}
\end{table} 
Table 1: NOS grouped by the language that are programmed. Figure 1: SDN layers. the issue of the latency, it does not determine the way of communication between controllers. A good solution to manage the scalability is Hyperflow [42], which consists of a controller that uses NOX [29] as NOS, which distributes events about the state of the network. The final challenge and probably the most important is the security in SDN against attacks. SDN security [43] is focused on which component is the target of the attack. From the controller point of view, some issues exist regarding unauthorized access and impersonation. An attacker who masquerades as the controller could run malware or malicious code and manipulate the entire network as he wants. This trouble is solved using a Transport Layer Security (TLS) with authentication on both sides (controller and switches) in the specification of OpenFlow [20]. Nevertheless, this security feature is optional and an attacker can take advantage of this problem and hijack the communication. From another point of view, network switches are a target of Denial of Service (DoS) due to a possible increase of traffic across the network. Since the incoming packets headers are sent to the controller and also stored in the switch memory, this supposes a traffic jam and an attacker can take advantage of this issue to overload the memory of the switch, and, consequently, it overloads the network.