Introduction
CHAPTER 1. INTRODUCTION
1.4.11 Pathlet routing
Godfrey et al. propose Pathlet routing [24]. Each domain contains one or sev-
eralvnodes (i.e., virtual nodes). A pathlet is defined as a set of consecutive vnodes
and an end-to-end path is composed with a list of concatenated pathlets. Pathlet in- formation are advertised to neighboring domains via a path vector routing protocol and only policy filtering is performed (i.e., there is no selection of a best path, con- trary to BGP). On the data plane level, the senders choose/construct end-to-end paths by concatenating pathlets they received the advertisement. Packet forward- ing is comparable with strictly source routing [72] as a new field, included in the packet header, is used to store the sequence of pathlet and specify the whole path.
Eachvnode forwards the packets according to the most external pathlet identifier.
Once it reaches the end of the pathlet, the identifier is erased and the forwarding is performed based on the next one - as for MPLS label stacking [33].
This proposal has the advantage to reduce a lot the forwarding table size of routers. Moreover Pathlet routing is compatible with several requirements (e.g, data and control plane changes, agnostic about the potential services...)
Nevertheless, some other crucial requirements are absent. Indeed, the sender needs to be aware of all the potential paths in order to make its choice. Therefore, despite the decrease of FIB entries into the core routers, the equipment at the frontier between the IP network and the pathlet Internet needs to know every single path (i.e., pathlet list) the end user could use. This leads to a scalability issue at the edge of Internet, which remains opened.
Furthermore Pathlet routing is quite disruptive as the inter-domain routing proto- col and forwarding capabilities of routers must be completely modified to advertise pathlets and to forward packets according to pathlets’ identifiers.
1.5
Contributions of this thesis
The goal of this thesis is to show how feasible are the propagation and the use of multiple paths. The thesis is organized as follows.
In the current chapter (i.e., Chapter 1), we first highlight in Section 1.1 the re- quired information to understand the work presented in the next chapters. The required knowledge are from the routing field. Nevertheless, it is declined in both
CHAPTER 1. 65
technical (i.e., BGP) and commercial (i.e., Valley Free, Prefer Client) considera- tions. Indeed these two aspects are the two sides of inter-domain routing and should not be separated. We also underline, in Section 1.2, how the enabling of the inter-domain multi-path can leverage some new uses and perspectives as well for NSPs and for end users. Nevertheless, using the Internet path diversity is not easy. We underline in Section 1.3 a list of requirements that a solution must respect in order to be adopted by NSPs. Having in mind these requirements, we present a complete state of the art about the Inter-domain path-diversity in Section 1.4. We show that none of the previous works unify all the requirements presented in Section 1.3. Indeed, while some solutions are meanly theoretical (i.e., very little has been done to propose ways of implementing the proposed solutions), some are very restrictive in term of usage (e.g., they focus on path recovery) or propose a highly disruptive approach.
In Chapter 2, we propose a first architecture that allows for the local use of path diversity. Indeed we propose that NSPs cumulate the diversity that is currently received by eBGP and share it with their stub clients. This proposal is simple, already configurable in current commercial routers and is backward compatible. From a global Internet point of view, this proposal may seem limited, in term of diversity. Nevertheless, we show, in Section 2.5, thanks to an extensive evaluation (performed with real BGP data) that the diversity currently received by a NSP is already important. Therefore sharing it with the stub clients gives NSPs the op- portunity to propose value-added services which does not require any coordination with neighboring NSPs. The presented local path diversity use is a first step to a global path diversity enabling. We also analyse this first step from the point of view of the stability of paths, which can be potentially used. We show that the way the NSP selects its paths has an important impact on the stability and that enabling path diversity may be an opportunity to better select the paths according to their stability.
In Chapter 3 we first generalize in Section 3.2 the architecture described in Chapter 2 in order to allow NSPs to share their path diversities among them. The architecture we propose is compliant with the requirements exposed in Section 1.3. We point out, through an evaluation covering the whole Internet graph in Sec- tion 3.4, that the “Prefer Customer” rule (described in Section 1.1.3) is restrictive in term of diversity. Indeed, it prevents NSPs to simultaneously obtain disjoint paths for reaching from 20% to 50% (depending on the source domain) of destination
domains, which would be required to perform fast failover4. Therefore we propose
the relaxation of the “Prefer Customer” rule. As this rule also allows for the Internet to remain stable, we propose a new criterion, in Section 3.3, that allows for both the stability of the global Internet and for the relaxation of the “Prefer Customer” rule. Our evaluation of the potential diversity, according to this new stability criterion, shows that the potential path diversity between a source domain and a destina- tion domain is so large that the maximum number of disjoint paths between these domains is only limited by the numbers of their external connections.
4. We consider fast failover as the first incentive to adopt inter-domain path diversity and such a limitation would lead to the non-adoption of our proposal.
As previously underlined in Chapter 3, the path diversity allowed by the pro- posed stability criterion is very high and may thus lead to scalability issue. Solving this potential scalability issue is possible by filtering the received path diversity. A NSP can filter the routes:
– either by selecting the routes on its own. In this case, each NSP filters the received diversity according to the information which is propagated inside each route advertisement. This type of filtering is most likely to happen at the beginning of the adoption of the inter-domain diversity propagation, when NSPs do not have precise negociation framework with neighbors.
– either by negotiating with neighbors to obtain the interesting routes. Thanks to negociation between neighboring domains, each one of them may know which path diversity each one of its neighbors is interested in. In such a case, routes are not filtered after reception but rather filtered before being sent to neighbors.
The Chapter 4 analyses the case where NSPs propagate the full path diversity to their neighbors. Each one of them is responsible of its own selection. We con- sider this approach as a worst case evaluation. First we identify in Section 4.2.5 where the scalability issues of such an approach can arise. We show that, despite what is commonly admitted, the scalability issue can not only appear in the core routers but also at the edge of the Internet (i.e., at the boundary between stub networks and NSPs). We then analyse, in Section 4.3, how the path diversity can be organized and propose schemes of identifying the paths, leading to different evaluation about their scalability. We quantify the scalability issue of propagating the whole diversity of the Internet and show that some small changes may help to reduce this scalability issue.
We assume that this routing table size increase will be monetized by NSPs as they will probably not be willing to implement new routes at their expenses. There- fore in Chapter 5 we expose a techno-economic approach to sell and propagate interesting routes in order to leverage value added services related to route prop- agation. Beside the revenue income of the NSPs, it also has for consequences the reduction of the scalability issue underlined in Chapter 4, as only routes that are bought are inserted into the FIB. We set-up an auction-type framework where a domain sells routes to its neighbors and each neighbor compete by bidding an amount it is able to pay to win the routes it is interested in. As a route is infinitely duplicable by the seller, the framework can not fit into conventional combinatorial auctions and we propose a new allocation mechanism. We set up a new way to determine which bidders win the routes (cf. Section 5.4 ) and the prices they have to pay (cf. Section 5.6). We manage to set-up a framework which is truthfull when each bidder submit one bid, meaning that bidders bid the true valuations of the routes they compete for, and which form the grand coalition, meaning that the seller has an incentive to accept every new bidder and that every potential bidder has an incentive to participate to the mechanism. Moreover we show, in Section 5.7, that the framework computation time is polynomial regarding the number of bidders and the number of routes.
CHAPTER 1. 67
While we summarize the main results of the current document, we also underline how the presented work can be deepened with further works.