# Application-Aware Network Traffic Management in MEC-Integrated Industrial Environments
## 5 SDN-eINP Interplay for Application-Aware Network Traffic Management
### Control Plane  
The control plane is responsible for making decisions about (i) how a flow traverses the industrial network (flow steering), (ii) its priority along the path (flow prioritization), and (iii) how that flow is to be processed (data filtering, aggregation, and encryption). The control room is where the control plane architectural components are located. Such components consist of an Industrial Application Manager (IAM), an SDN controller, and an eINP controller. The IAM is logically built on top of the SDN and eINP controllers. Its primary task is to provide application-aware network traffic management by bridging the SDN and eINP sides. To do so, the IAM takes advantage of the abstractions provided by each side, exploited as building blocks to enable the SDN-eINP interplay. The SDN paradigm advocates for a clear-cut separation between who forwards packets and who makes routing decisions. The SDN controller is a logically (but not necessarily physically) centralized software entity that abstracts the underlying network infrastructure and provides the control logic to program the whole network. Specifically, it builds a network-wide view by gathering status statistics from NDs and dictates their behavior by pushing forwarding rules into them. Thus, NDs become dumb devices that make flow-based forwarding according to the instructions provided by the SDN controller. A flow is defined by rules matching a set of packet header values. The eINP side abstracts computational resources made available by ENs and orchestrates software modules (packaged as containers) across them. The eINP controller clusters those resources in zones. The scope of a zone is to seamlessly orchestrate containerized eINP modules only across those ENs directly connected to a given ND. For instance, zone \(B\) (see Figure 1) includes EN\({}_{B,1}\), EN\({}_{B,2}\), and EN\({}_{B,3}\), the only ENs directly connected to ND\({}_{B}\). The rationale behind that is to bring eINP modules as close as possible to the NDs where the target traffic flow has been scheduled to pass, avoiding messages traversing the industrial network back and forth to be processed. The IAM relies on the network-wide view provided by the SDN controller to check the network status. This monitoring phase is an endless loop (see Figure 3), which gives the IAM the readiness to detect harmful communication patterns timely. An example of such a pattern is the following one. Let us consider a huge flow (e.g., an AGV sending vibration values to the MES) that has been scheduled along a given path. However, such a flow might undermine concurrent flows that (even partially) share the same path. In this case, the IAM may steer the flow toward an eINP module to be appropriately processed, as described in Figure 3. First, the IAM takes advantage of the abstractions provided by the eINP controller to retrieve the cluster-wide view. The cluster-wide view provides up-to-date information about the computing resources not reserved yet, the eINP modules currently running on the ENs, and how many resources such modules consume out of those reserved. Then, the decision-making phase takes place: IAM makes the SDN and eINP sides work synergistically. Figure 2: Architecture for enabling application-aware network traffic management. The architecture is based on the SDN-eINP interplay, where the IAM is the glue that makes the SDN and eINP sides work synergistically. ENs are available both within (on-premises) and outside (off-premises) the industrial boundaries. Based on the network- and cluster-wide views provided by the underlying controllers, the IAM jointly orchestrates \"who runs where\" and \"who goes where.\" The former is about eINP module deployment, whereas the latter regards traffic flow steering. The eINP module deployment may not always be required, e.g., the target module is already running on an EN along the path. Moreover, it may affect multiple ENs, e.g., the eINP controller schedules multiple replicas of the target modules on different ENs.