# An Architecture to Manage Incoming Traffic of Inter-Domain Routing Using OpenFlow Networks
## 5 Proof of Concept
### Scenario II--External Link Failure  
This scenario captured the dynamic of a disruption of an external link when the domain that deployed the proposed architecture was protected with the FF rules of OpenFlow. The main goal of this scenario was to mitigate the unavailable time of the domain during the disruption of an external link, taking into account the FF mechanism and exploring the multiple paths allowed by the proposed architecture. This scenario used Workload 1 and the prototype environment describing the adopted topology (see Figure 5). To avoid any delay or packet loss that could be caused during the OpenFlow rules installation process, all FF rules were installed before the execution of the workload. An example of the state of the table rules is depicted in Table 1.  
Suppose that _OpenFlow Switch_ of Figure 5 is the edge device of AS 100. As the workload was designed to explore the BGP's destination-based forwarding paradigm, the best next hop for the prefix 172.16.0.0/24 is through the AS 200. If the domain AS 400 can apply inbound control over the prefix 172.16.0.0/24 in the AS 100, then all traffic from the _50 Networks_ can be forwarded as the AS 400 wishes. The first 50 lines of the _OpenFlow Switch_ flow table reflected this scenario, and used the group table _Group1_ identifier, where it forwarded packets to AS 200 when the external link to this AS was live (not failed), or otherwise to AS 300. The last OpenFlow rule is the routing safety rule, where all the remaining traffic that does not match against previous rules will be forwarded. The _Group2_ identifier was used to forward network traffic for path [200,400], which was the \"best\" next hop for the BGP AS 400's prefix. Regarding the experiments, Figure 10 depicts the average bandwidth received by the _Server_ during the execution of Workload 1. The workload was executed more than 30 times with a confidence interval of 95%. As the disruption of the link was not perfectly synchronized with the start of the capture (in milliseconds time), the computation of the average bandwidth produced a graph that did not present a discontinued interval around the 15 th second. However, Figure 10 indicates that the FF mechanism did not affect the total bandwidth available to the workload once the maximum available bandwidth was used practically during the entire 30 s interval. \begin{table}
\begin{tabular}{c c c} \hline \hline \multicolumn{2}{c}{**Match Fields**} & **Instruction** \\ ine IP\_src:192.168.1.0/24 and IP\_dst:172.16.0.0/24 & Group1 \\ ine IP\_src:192.168.2.0/24 and IP\_dst:172.16.0.0/24 & Group1 \\ ine (...) & Group1 \\ ine IP\_src:192.168.50.0/24 and IP\_dst:172.16.0.0/24 & Group1 \\ ine IP\_dst:172.16.0.0/24 & Group2 \\ \hline \hline \end{tabular}
\begin{tabular}{c} Group table at _OpenFlow Switch._ \\ \hline \hline
**Group Identifier** & **Group Type** & **Action Buckets** \\ ine Group1 & Fast Failover & Watch: AS 200 port; Output: AS 200 \\ ine Watch: AS 300 port; Output: AS 300 \\ ine Group2 & Fast Failover & Watch: AS 200 port; Output: AS 200 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Flow table and group table for the _OpenFlow Switch_ using OpenFlow Fast Failover Group Table. In fact, a sample of the execution of the selected workload is presented in Figure 11, which shows how the traffic used different paths to reach the _Server_. Although Figure 11 describes the network behavior of the traffic generated during the 30 s, it does not provide details about the disruption event that occurred in the 15 th second. Next, Figure 12 details what happened in between the times of 14.95 s and 15.05 s of this scenario. The workload produced 100 Mbps of network traffic and used the path [200,400] as the \"best\" next hop and path [300,400] as a backup path. In the 15 th second, the link connecting AS 100 and AS 200 failed. After the link failure in the 15 th second, the FF mechanisms took a few milliseconds to discover the disruption.