# An Architecture to Manage Incoming Traffic of Inter-Domain Routing Using OpenFlow Networks
## 5 Proof of Concept
### Topology Adopted  
To adopt a topology for composing the evaluation scenario, the CAIDA's AS relationship database [30] was used for the characterization of multi-homed ASes. It was expected that those ASes get more advantages of the proposed architecture as they can allow them to control and explore the path diversity of the Internet.  
The period from December 2015 to October 2017 was considered. Figure 4 presents the total number of public ASN in CAIDA's AS relationship database as well as the total number of stub ASes with public ASN and a subset of this total representing the total number of multi-homed stub ASes with two relationships of customer-to-provider. Thus, as the multi-homed customer ASes with two ISPs are typical in recent months of the Internet, and, considering the hardware resources of this research, the evaluation testbed of the proposed architecture adopted a topology with two outbound links, one for each ISP, and a multi-homed customer AS.  
Based on the data above extracted from CAIDA's relationship database, the topology adopted its depiction in the Figure 5. It consisted of four ASes, where three of them were transit ASes (AS 00, AS 300, and AS 200), and a stub AS (AS 400). The relationship of customer-to-provider was: AS 400 to AS 300, AS 400 to AS 200, AS 300 to AS 100, and AS 200 to AS 100. As AS 100 deployed the proposed architecture, a new relationship of customer-to-provider was created between AS 100 and AS 400, with the goal of managing inbound traffic to the customer (in this case, AS 400).  
The RIB of the AS 100 for the customer AS 400 was indicated in Figure 5, where AS 400 advertised the network prefix 172.16.0.0/24 and the AS 100 learned this prefix propagated through eBGP sessions between all the ASes in the topology. The AS 100 learned that it could reach network 172.16.0.0/24 either through the AS-path [200,400] or through the AS-path [300,400].  
The default behavior of the proposed architecture followed the outcome of the BGP decision process where the preferable next hop to reach the _Server_ of AS 400 was by using the path of AS 200. This preferable path is indicated in Figure 5 with the character \"\(>\)\", and the character \"*\" indicates that both routes were valid as the result of the BGP decision process. The length of the AS-Path was equal for both paths to the network 172.16.0.0/24. The BGP decision process selected the path [200,400] to be the next hop for that prefix; however, as the _Network Operator_ in AS 400 could use the proposed architecture executed in AS 100, it could explore the use of both paths, if the AS 100 allowed it.  
Figure 4: The total number of multi-homed stub ASes is common in recent months of the Internet.  
Figure 5: The topology adopted.  
Once there was a relationship between AS 400 (Customer) and AS 100 (Provider) using the proposed architecture, the AS 100 could offload the control of traffic that went to the network prefixes of AS 400. In the topology adopted, only one prefix was available for the customer AS 400 to manipulate it, and two options of paths to reach that prefix. When the _AS app_ of AS 400 did not apply the load balancing, it followed the standard BGP behavior and forwarded all network traffic to just one \"best\" next hop (per prefix).