# A Survey on Efforts to Evolve the Control Plane of Inter-Domain Routing
## 5 Classification of Efforts for Evolving the Control Plane
### Efforts to Evolve the Control Plane of Inter-Domain Routing
#### 5.2.3 Inter-Domain Communication  
The control communication between different domains is also an important criterion to be analyzed in related works. Table 5 depicts the related works that evolve the inter-domain control plane routing using some inter-domain communication mechanism. For ASs that exchange control information with the BGP protocol, they can use the BGP attributes for that purpose. For example, an AS may set MED or Communities' values to alter how the control plane of other ASs selects routes [83; 84]. However, the BGP attributes have limited scope and effectiveness [16], and consequently, new signaling mechanisms between different control planes emerged to overcome those restrictions. To tackle the ability of the BGP advertising just one best route per prefix, ADD-PATH is an extension to the BGP that uses its capability to advertise, identify and add multiple paths to a destination [76]. The standard behavior of the BGP produces and advertises only one best-path to a given address prefix. If two NLRIs are advertised with the same value of the address prefix, the latest advertisement will override the previous one in the RIB. ADD-PATH allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The main idea of this BGP extension is instead of using the address prefix as the primary identifier of a path, it uses a _Path Identifier_, in which each path receives a unique identifier, and that allows multiple values of address prefixes to exist in the RIB. By exchanging, the topology and information about the current state of the network among routing components are typically used as the interior routing protocol (for example, OSPF) for such tasks. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Proposal and Authors** & **Concepts** & **Approach** & \begin{tabular}{c} **Control Plane** \\ **Placement** \\ \end{tabular} & \begin{tabular}{c} **Explore** \\ **Path Diversity** \\ \end{tabular} \\ \hline ADD-PATH [76] & Traditional & Protocol & Distributed & \begin{tabular}{c} Alternative \\ routes \\ \end{tabular} \\ North-Bound Distribution & & & & \\ of Link-State and & & & & Inter-domain negotiations \\ Traffic Engineering (TE) & Traditional & Protocol & Distributed & \begin{tabular}{c} Inter-domain \\ negotiations \\ \end{tabular} \\ Information, [PERSON] et al. [77] & & & & \\ BGP Administrative & & & & \\ Shutdown Communication, & & & & \\ [PERSON] et al. [78] & & & & \\ RouteFlow, & & & & \\ [PERSON] et al. [79] & SDN & Architecture & Centralized & Based on flows \\ WE-Bridge [80] & SDN & Protocol & Distributed & \
\begin{tabular}{c} Inter-domain \\ negotiations \\ \end{tabular} \\ Inter-SDN, [PERSON] et al. [81] & SDN & Architecture & Centralized & Based on flows \\ [PERSON], [PERSON] et al. [82] & SDN & Protocol &
\begin{tabular}{c} Logically \\ centralized \\ \end{tabular} & Based on flows \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Classification of proposals to evolve inter-domain communication. Generally, the ASs are not willing to reveal their internal infrastructure or the business relationship information among other ASs because of security or business concerns. However, in some scenarios, the link-state or Traffic Engineering (TE) information can be shared with external components of a domain, for example, applications that require end-to-end TE (this is the case of the SIREN [36] proposal where the external control plane was responsible for computing the routing of the customer domain or Multi-Protocol Label Switching Traffic Engineering (MPLS-TE) with Path Computation Element (PCE). The North-Bound Distribution of Link-State and Traffic Engineering (TE) Information [77] describes a mechanism to collect and share link-state and TE information with external components by a new BGP NLRI encoding format. Another extension for BGP to improve the communication among BGP neighbors is the BGP Administrative Shutdown Communication [78], defined in RFC 8203.