# Joint QoS and Congestion Control Based on Traffic Prediction in SDN
## 3 System Architecture  
In this section, the proposed architecture and its components are presented. The architecture is conceptually aligned with the SDN layering discussed in [28]. With reference to Figure 1, we consider three different layers. The _Infrastructure_ layer consists of networking devices and corresponds to the Forwarding Plane and Operational Plane presented in [28]. The _Control_ layer interacts with the networking devices in order to program their behavior from a logically centralized perspective. It corresponds to the control plane and management plane in [28]. Finally, the _Application_ layer includes the applications and services that define the overall network behavior. Looking at Figure 1, the Infrastructure Layer includes the networking devices. We refer to the networking devices as _switches_, following an SDN-based terminology, but these devices could also act as routers. We assume that there is a logically centralized SDN controller in the Control layer, connected to the set of SDN switches via the Southbound protocols (examples of Southbound protocols are shown in Figure 1). The main role of the SDN controller is to setup the forwarding tables of the single networking devices in order to properly configure the packet forwarding. The SDN controller interacts with the networking devices and gathers information on the topology and on the network traffic. The SDN controller can include additional functionality, that we represent as additional modules in Figure 1. In particular, in our architecture, we consider two monitoring modules. These modules are considered as a part of the controller to speed up the process and reduce the overhead of gathering information from the switches. The Control layer offers a set of functionality to the Application layer, through the Northbound application programming interface (API). The application and services in the Application layer use this API in order to implement the desired behavior. In our architecture, the proposed resource allocation/reallocation modules are included in the Application layer. These modules take the decisions about the path selection and request the Control layer to enforce them through the Northbound API. In the other direction, the Control layer provides the Application layer with information about topology and network traffic. As can be seen in Figure 1, the proposed architecture has the following modules:  
* _Resource allocator (routing module)_: this module belongs to the application layer. When a new flow enters the network, the resource allocator assigns the required resources to the flow. This module does not reroute existing flows and only focuses on newly arrived ones. * _Resource re-allocator (re-routing module)_: this module belongs to the application layer. It is capable of performing a reallocation of some flows in order to react to some event (like congestion) or periodically to optimize the use of resources or the user perceived QoS. We can exploit any of the existing routing algorithms as the resource allocator. Therefore, we focus on the resource re-allocator, which represents the more general case. In addition, it is possible to also cover the resource allocation process with some adaptations of the re-allocator (e.g., only one flow is considered in the optimization). In this paper, we introduce QRTP, a resource reallocation algorithm (rerouting module) that satisfies QoS requirements by means of rescheduling individual flows using a software defined networking paradigm. The switches are OpenFlow enabled; therefore, there is a central controller communicating with each switch via OpenFlow protocol. Each switch has a forwarding table used for routing the packets of the flow. In order to configure the network, the controller updates the switch's forwarding table. The network topology and current flow matrix can be obtained via querying the switches. We suppose that there is an estimation of traffic based on the current flow matrix and the history of network flows.