# An Architecture to Manage Incoming Traffic of Inter-Domain Routing Using OpenFlow Networks
## 3 The Architecture Proposal
### Dynamic of the Proposed Architecture  
This subsection describes how the dynamics of the proposed architecture. Regarding neighbor peering, the OpenFlow controller has to be informed (all configuration for BGP protocol has to be provided by the network operator in the same way as the traditional BGP configuration) about the port where the _BGP Speaker_ component will establish the peer session for a given neighbor. In addition to the port information, the ASN of the foreign AS and the IP address of the remote router have to be provided. Furthermore, if the IP address of an AS is a multihop, then the number of networks between the _BGP Speaker_ and the router of the neighbor AS has to also be provided as by default, all IP packets from the _BGP Speaker_ to a router neighbor is set with the value 1 in the Time To Live (TTL) IP field for an external BGP connection. Then, if everything goes as planned, BGP peering is established, and the exchange of NLRI between the peer is complete. The NLRI will compose the RIB_IN, and after applying the _Import Policies_ the LOCAL_RIB is populated. The LOCAL_RIB is generated by executing the BGP decision process. The RIB information is useful to the AS that deploys the proposed architecture as it can provide the other ASes with inbound traffic management for the network traffic that passes through its infrastructure. Thus, the proposed architecture explores the RIB information and provides more management control to customer ASes using inter-AS communication. Furthermore, if the AS that deploys the proposed architecture allows a customer to manipulate the outbound traffic in its network infrastructure, it will always be limited to the subset of prefixes learned and valid in the LOCAL_RIB. Furthermore, these prefixes have to be in the _Routing Registry_ database and assigned to the same customer that requires inbound traffic manipulation. That is, the remote control of a customer will be limited to only a subset of the local RIB where the destination field must belong to one of the prefixes owned by the customer AS, and a customer AS cannot change the forward network behavior of other prefixes that are not registered to it. For the exchange control between a customer and a provider of the proposed architecture, it establishes a secure channel between the ASes (e.g., Virtual Private Network (VPN) or Hyper Text Transfer Protocol Secure (HTTPS)), which connects the AS that provides the services (for example, an ISP) to its customers' ASes. With a security channel, the network operator in the customer AS can exchange management information and monitor the traffic utilization destined to its network infrastructure. Thus, the _AS app_ of a customer AS will be responsible for manipulating how traffic is managed. The organization of the proposed architecture is aligned with one of the SDN principles, where the logic of the network occurs in applications executed over the controller. The _AS app_ receives the BGP network state (extracted from the RIBs) for the valid prefixes owned by a customer and the network bandwidth usage for each path associated with each prefix. Then, the application can export that information to the customer. When the network operator in the customer site receives the state of its _AS app_, it will be able to configure the parameters of the execution of the _AS app_. This allows the network operator to manage how incoming traffic of the inter-domain network will reach its network infrastructure. For example, the customer AS can send control information that describes how to load balance the traffic that passes through the transit AS as it has access to the available bandwidth usage information for each prefix and the available valid AS-paths. The default forwarding actions are to use the BGP behavior. With the information on how to treat the traffic, the AS that deploys the proposed architecture can apply the new control for a given network prefix and then override the BGP default behavior when required.