3.2 Dynamic Topological Information Architecture (DTIA) Basic Rationale
3.4.4 Failure Management
The failure management algorithm for the inter-region case is similar to the intra-region algorithm. A control packet is always sent every time a reachability or routing change has occurred. There are however two differences. The first is related to backup inter-region links. These are only used in case all other inter-region links are down. The second con- cerns c2p or p2patt inter-region links that fail. It might happen that certain ASes become unreachable. However this is a serious failure and at the Internet there are not many records of this type of failures. Redundant mechanisms can be conceived in the future.
For links that are restored, a similar algorithm is also applied to disseminate a control packet. The control packet is disseminated if a previously unreachable AS becomes reach- able again or a more preferred path is now used.
3.4. MULTI-REGION ROUTING 51
As mentioned before, the scope of dissemination is directly related to the degree of multi- homing of the region. A high degree of multi-homing makes the disseminating region smaller, since it is highly improbable the loss of reachability to any destination. Compared to XL[LVPS08], DTIA uses more control packets due to multipath coherence requirements. XL only has to notify changes to nodes that affect directly the shortest path.
3.4.5
Deployment
For future deployment of this thesis’ work, we cannot disrupt the current de-facto pro- tocol BGP. We would need several years for a full-fledged deployment. However, we can start deploying DTIA with multi-region routing at smaller ASes.
Islands of regions would be deployed inter-working with BGP-based ASes. Nonetheless we need a mapping service that maps all BGP-based ASes’ prefixes into an external re- gion. DNS could be extended to perform the mapping between prefixes, ASes and regions. Furthermore, data from CAIDA or RIPE could be used to create a reliable service that distributes the region’s graph.
Inter-region routing would follow the rules from section 3.4.2. DTIA’s paths could be ad- vertised to BGP regions from DTIA’s border-ASes with translated ASes’ prefix; however the degree of prefix advertisements should be decided.
As years progress, ASes would progressively change to DTIA from the bottom tiers to the top. This bottom-up deployment brings some advantages. If a DTIA region is connected to an external BGP region through a c2p link, there is no need for a mapping service, since all unknown prefixes outside of the region belong to BGP; furthermore, there is no need to reverse map BGP advertisements at border-ASes. Once regions become directly connected, the mapping service is needed to reach remote destinations; a default map to BGP can still exist until it is no longer useful.
Chapter 4
Protocol’s Implementation
4.1
Introduction
This chapter’s objective is to explain DTIA’s implementation and its feasibility for multi- region. Chapter 3 formally presented the protocol with some insights on used techniques, some to reduce its algorithmic complexity. These techniques bring some trade-offs that are further discussed in section 4.2.
The protocol’s rationale will be thoroughly explained through the visual aid of flowcharts. These flowcharts are used for easier interpretation of the protocol on section 4.3.
For a valid test bench of the protocol we have used the network simulator 2 (ns-2) [nsR09]. To test inter-domain scenarios, some modifications were added to the simulator’s core to comply with our needs. These modifications are further explained in section 4.4.
4.2
Protocol’s Considerations
Chapter 3 presented DTIA as a modular protocol. It reveals simplicity for separating reachability from routing. However, separating distinct functionalities might introduce some algorithmic overload when exploring the network’s graph. We could reduce the pro- tocol’s overhead by integrating the path exploration algorithm with the path’s signature calculation.
Section 3.3.2 proved that it is possible to calculate a path’s signature by walking forward 53
from the source AS to all destinations; this functionality could be easily merged with the path exploration procedure that also walks on the forward direction. As a result, while we are exploring the network’s graph hop-by-hop, we are also calculating the paths’ sig- natures. This parallelism of functions could scale with wider topologies. As a trade-off, it offers less flexibility for future updates of the protocol, since both layers are not separate.
Regarding multi-region routing, a few changes were also considered. Section 3.4 states that border-ASes exchange a list of reachable ASes of their region, but it does not mention how is the list structured. We have considered that each element of the list is structured as (D, S); where D is the destination AS and S is the most preferred path’s signature that reaches AS D. The inclusion of this information is useful to differentiate remote paths that reach the same destination.
DTIA’s authors mention that the path exploration algorithm performs reasonably well with 11, 000 ASes. The number of ASes alone might not be enough. If the ASes are massively connected it could stress routers in the calculation of the path exploration al- gorithm for each region. Amaral et al.[AGA+09] envisaged that five to ten regions should be enough to handle the resulting higher number of regions. However if the number of ASes grows to a great extent in the future, a solution must be adopted to handle the resulting higher number of regions. This thesis proposes a scalable solution to implement the path exploration that explores the region’s graph only once for all purposes.
As a side note, this thesis did not focused on implementing a service that distributes a graph G of the network.