# Whisper: Programmable and Flexible Control on Industrial IoT Networks
## 3 Whisper Framework: SDN without SDN
### Architecture  
The Whisper architecture is built as shown in Figure 3. It is based on three main components: policies, building blocks and primitives. First, some _policies_ are given as input from the network operator. Example policies that can be applied are given in Table 2. These policies are applied to a given network blueprint, which is basically the network topology, the network assumptions and the events that can happen during operation. The assumptions state what type of capabilities the Whisper algorithm can have. For example, a number of assumptions can be made such as: Can we control the root node?, Can we place Whisper nodes anywhere?, Is MSF used as a scheduling function?, etc. Finally, the events are triggered at any instant of time in any node. These events can be triggered when a certain condition is matched in one of the nodes (Push), or can be periodically checked in the controller by polling the nodes (Pull). Whisper supports management at different time scales. Depending on the event and to which policy it is associated with, they can be processed in real time (e.g., DoS attack) or they can be aggregated and processed after a housekeeping period (e.g., load balancing).  
By matching the policies to the blueprint, the Whisper algorithm first creates a logical structure of the newly desired (goal) topology. Depending on the policies and the differences obtained between the initial topology and the desired topology, the algorithm will generate the required Building blocks.  
The different building blocks are the basic operations that can be performed in order to manage the network. There are three: _Switch parent_, _Allocate cell_ and _Forwarding_.  
_Switch parent_. This block is used whenever one or more policies require that a node changes its preferred parent. Every _Switch parent_ block will trigger one or more primitives that will eventually end up in a parent change.  
_Cell allocation_ (_and deallocation_). Through these blocks, Whisper can add or remove cells between any pair of network nodes. They can be applied together with the _Switch parent_ block in order to allocate cells with the new parent and deallocate cells with the old parent, or can be applied alone, to perform scheduling-only operations.  
_Forward traffic_ block is equivalent to the _Switch parent_ block, with the only difference that the new parent of the target node is always a Whisper node that is part of the same DODAG. This way a Whisper node can attract the desired traffic towards him and relay it to another node if necessary. This can be useful for specific cases that require additional Whisper nodes in order to be accomplished such as policies that require using specific capabilities present in a Whisper node (e.g., block a suspicious Deny of Service attack through a DPI box located in the Whisper node). Additionally, due to the  
Figure 3: Whisper architecture.  
gradient nature of RPL, arbitrary topologies are not always possible. However by using this block, equivalent augmented topologies can be built with additional Whisper nodes in order to obtain specific routing behaviors.  
Finally the last important component is the primitive. Each building block generates one or more primitives. Each primitive translates into a list of messages that have to be sent from a node X to node Y with a specific value as illustrated in Table 1. This value can be the rank for the DIOs or the sequence number SeqNum in the 6P commands. The Primitives 1-4 with DIOs messages are used to perform parent switching. Finally, Primitives 5 and 6 deliver fake 6P commands for just adding or deleting cells in the nodes' schedule.