# An Architecture to Manage Incoming Traffic of Inter-Domain Routing Using OpenFlow Networks
## 4 Controlling Inbound Traffic  
The control of inbound traffic is executed inside the application plane of the proposed architecture. A customer AS initializes the _AS app_ to manage the network prefixes of the transit AS with the goal of instructing how traffic will be handled. The _AS app_ also receives the network status from the proposed architecture. For example, the bandwidth utilization of each prefix owned by the _Customer AS_, or the available paths to reach its networks. With that information, the network operation of the _Customer AS_ can send control information to configure how much traffic each path will receive for each prefix in use.  
The _AS app_ is responsible for exploring the multiple paths available for a given prefix if it is required. The information about those paths come from the _BGP Speaker_ component that learned all the prefixes advertised by the AS neighbors through external BGP peering. Furthermore, with the information about multiple paths available, the _Customer AS_ can indicate how the traffic will be treated and distributed to those paths.  
The BGP protocol uses just one \"best\" next hop for each prefix even if other paths to those prefixes are valid and available. BGP is not a multipath protocol, and one good reason for that is that exploring multiple paths on the Internet can affect the performance of Transmission Control Protocol (TCP) connections, the most used transport level protocol in the Internet [25].  
Thus, distributing packets belonging to a connection through multiple paths can result in poor performance of high-level protocols of the TCP/IP stack [26] (e.g., reordering packets of TCP [27]). In particular, it is often the case on the Internet, which connects heterogeneous types of network appliances and protocols, that the network suffers from different delays among paths. To avoid the problem of exploring path diversity of the Internet, the proposed architecture guarantees that the association of the source and destination of the IP packets will be forwarded through the same path. Then, a 2-tuple composed of the IP source prefix and the IP destination prefix is adopted to define a flow in the OpenFlow network. Therefore, for a given TCP connection, it will use the same path during its time life (if the path is valid and available).  
Aligned with the 2-tuple flow definition, there is an also a probe test from the _AS app_ to a customer AS that checks the health of each path in use. Thus, if an inter-domain path suffers a problem (such as a link failure) or a transient loop occurs, the _AS app_ will be notified to not use that problematic path.  
Regarding the inbound traffic control, the proposed architecture allows any innovation in the logic behind the _AS app_ for a customer AS. As well explained by [PERSON] [28], there are different strategies for SDN load balancers. However, in this work, it was decided to develop three types of strategies for the load balancers to be used as the control application in the _AS app_:  
1. Reactive Random Load Balancer (Random)
2. Reactive Round-Robin Load Balancer (RR)
3. Reactive Round-Robin Load Balancer with Threshold (RRT)  
These three strategies use the reactive flow creation approach [29] where the flows are created on-demand in the response of a packet that requires a new flow. The baseline for the comparative will be the default behavior of the BGP that uses the \"best\" next hop to the forward packets. The remainder of this section is dedicated to depicting each approach.