A performance evaluation of BGP-based traffic engineering

We analyze several types of interdomain traffic engineering techniques. First, we briefly describe interdo-main routing and the BGP protocol. Then, we summarize the characteristics of interdomain traffic based on measure-ments with two different ISPs. We evaluate how a typical ISP can select its upstream providers and show that with the BGP decision process many routes are selected non-deterministically. We then evaluate with simulations the perfor-mance of BGP-based traffic engineering techniques that are currently used on the Internet and show their limitations.

Computer Communication Review, 2003

Network operators must have control over the flow of traffic into, out of, and across their networks. However, the Border Gateway Protocol (BGP) does not facilitate common traffic engineering tasks, such as balancing load across multiple links to a neighboring AS or directing traffic to a different neighbor. Solving these problems is difficult because the number of possible changes to routing policies is too large to exhaustively test all possibilities, some changes in routing policy can have an unpredictable effect on the flow of traffic, and the BGP decision process implemented by router vendors limits an operator's control over path selection.

Proceedings of the 6th International ICST Conference on Broadband Communications, Networks, and Systems, 2009

The Border Gateway Protocol governs the overall routing in the Internet. With the time, it has been overloaded with functions which is was not initially designed for. The main example is Traffic Engineering. Internet Service Providers need to adjust the traffic on their peerings and in absence of a better alternative, use Trial and Error techniques based on manipulating the Autonomous System Path attribute in Border Gateway Protocol (BGP-4) updates. This paper shows sequences of BGP-4 updates where the use of Trial and Error Traffic Engineering techniques have led to instability and the countermeasures used to minimise their impact impact. The analysis methods presented also partially reveal the way Internet Service Providers use AS_PATH Prepending.

2007

Today's Internet users and applications are placing increased demands on Internet service providers (ISPs) to deliver fine-grained, flexible route control. To assist network operators in addressing this challenge, we present the Intelligent Route Service Control Point (IRSCP), a route control architecture that allows a network operator to flexibly control routing between the traffic ingresses and egresses within an ISP's network, without modifying the ISP's existing routers. In essence, IRSCP subsumes the control plane of an ISP's network by replacing the distributed BGP decision process of each router in the network with a more flexible, logically centralized, application-controlled route computation. IRSCP supplements the traditional BGP decision process with an explicitly ranked decision process that allows route control applications to provide a per-destination, per-router explicit ranking of traffic egresses. We describe our implementation of IRSCP as well as a straightforward set of correctness requirements that prevents routing anomalies. To illustrate the potential of application-controlled route selection, we use our IRSCP prototype to implement a simple form of dynamic customer-traffic load balancing, and demonstrate through emulation that our implementation is scalable.

2004

Today, most multi-connected autonomous systems (AS) need to control the flow of their interdomain traffic for both performance and economical reasons. This is usually done by manually tweaking the BGP configurations of the routers on an error-prone trialand-error basis. In this paper, we demonstrate that designing systematic BGP-based traffic engineering techniques for stub ASes are possible. Our approach to solve this traffic engineering problem is to allow the network operator to define objective functions on the interdomain traffic. Those objective functions are used by an optimization box placed inside the AS that controls the interdomain traffic by tuning the iBGP messages distributed inside the AS. We show that the utilization of an efficient evolutionary algorithm allows to both optimize the objective function and limit the number of iBGP messages. By keeping a lifetime on the tweaked routes, we also show that providing stability to the interdomain path followed by the traffic is possible. We evaluate the performance of solution based on traffic traces from two stub ASes of different sizes. Our simulations show that the interdomain traffic can be efficiently engineered by using not more than a few iBGP advertisements per minute. Our contribution in this paper is to demonstrate that by carefully thinking the design of the interdomain traffic engineering technique, stub ASes can engineer their outbound traffic over relatively short timescales, by exclusively tweaking their BGP routes, and with a minimal burden on BGP. Systematic BGP-based traffic engineering for stub ASes is thus possible at a very limited cost in terms of iBGP messages.

IEEE Network, 2005

In this paper, we investigate a model of route selection for interdomain traffic engineering where the routing to multiple destinations can be coordinated. We identify potential routing instability and inefficiency problems, and derive a set of practical guidelines to guarantee stability without global coordination. Using a realistic Internet topology, we show that route oscillations can happen even when a small number of ASes coordinate route selection for just a small number of destinations, if the coordination does not follow our guidelines. We further extend our model so that 1) ASes can adopt any route selection algorithms in a class of algorithms which we call rational route selection algorithms; and 2) the local ranking of routes of an AS can depend on ingress traffic patterns. We show that persistent route oscillations can happen in certain network settings even if the ASes strictly follow the constraints imposed by business considerations, and adopt any rational route selection algorithms. for valuable comments. We are also grateful to the anonymous reviewers and the shepherd Olivier Bonaventure for their valuable comments. 1 there is no AS whose routing policies require it to coordinate its route selection among multiple destinations. On the other hand, a fundamental feature of route selection for interdomain traffic engineering in particular and traffic engineering in general is that route selection constraints (e.g., traffic assigned to a link remains within link capacity) and/or objectives (e.g., balancing the load) involve the route selection of multiple destinations. Thus, in route selection for interdomain traffic engineering, whether a route will be chosen for a given destination will depend on what routes are available or chosen for other destinations. For example, if an AS selects routes for each destination independently without considering the chosen/available routes of other destinations, in the worst case it may choose the same access link for all destinations, violating link capacity constraints and/or causing load imbalance. Second, the previous studies focus on the stability of a homogeneous network where each AS runs the same specific interdomain route selection algorithm (i.e., the BGP-based greedy route selection algorithm). However, with increasing usage of route selection for interdomain traffic engineering, route selection algorithms with more sophisticated strategies are likely to be designed and deployed in the Internet. Thus it is necessary to analyze the stability of a heterogeneous network where ASes may adopt a larger class of route selection algorithms beyond the greedy strategy. Third, the previous studies focus on local policies which rank only the egress routes; that is, they assume that the local ranking of egress routes at each AS is independent of the inbound traffic pattern of that AS. However, in practice, the local policies of ASes may involve both the egress routes and the pattern of inbound traffic. In the last few years, several traffic-demand-matrix-based traffic engineering algorithms have been proposed. Although such route selection algorithms have been shown to be effective, the evaluations often assume that the route selection of each AS does not affect the inbound traffic, whereas the inbound traffic is likely to change with the chosen egress routes, introducing unexpected interactions. Thus it is necessary to analyze the stability of route selection algorithms implementing local policies that take into account inbound traffic patterns.

The Internet Protocol Journal, 2001

The rapid growth of the Internet has led to numerous changes to the underlying technologies. In the early days, host names and their corresponding IP addresses were kept in a flat text file (" HOSTS.TXT "), updated weekly by the Network Information Center at SRI International. In the mid 1980s it became clear that this method of name/ address mapping would not scale, and a new distributed lookup mechanism was designed and deployed. This new method, known as the Domain Name System (DNS), has proven successful even in the face of millions of Internet hosts. Another result of Internet growth is the potential for depletion of the IP Version 4 (IPv4) 32-bit address space. In the early 1990s, this became a matter of great focus for the Internet Engineering Task Force (IETF). The " short-term " fix for this problem was to abandon the original concept of A, B and C address classes and introduce Classless Interdomain Routing (CIDR), which consumes addresses in a much more...

2000

In this paper, we discuss the use of the Border Gateway Protocol, version 4 (BGP4), to exchange Quality of Service (QoS) information between domains. The propagation of this information across autonomous systems should contribute to the dynamic computation and the selection of routes that will participate in the enforcement of end-to-end QoS policies. This paper proposes the use of an

2004

We study the interdomain traffic as seen by a non-transit ISP, based on a six days trace covering all the interdomain links of this ISP. Our analysis considers the relationships between the interdomain traffic and the interdomain topology. We first discuss the day-to-day stability of the interdomain traffic matrix to evaluate the feasibility of interdomain traffic engineering. Then, we study the variability of the interdomain flows for several aggregation levels (prefix, AS and sink tree) and with respect to the interdomain topology seen by BGP. We show that despite the important variability of interdomain flows, it would be useful for a non-transit ISP to traffic engineer its access traffic by relying on a sink tree aggregation level.

European Transactions on Telecommunications

We study the interdomain traffic as seen by a non-transit ISP, based on a six days trace covering all the interdomain links of this ISP. Our analysis considers the relationships between the interdomain traffic and the interdomain topology. We first discuss the day-today stability of the interdomain traffic matrix to evaluate the feasibility of interdomain traffic engineering. Then, we study the variability of the interdomain flows for several aggregation levels (prefix, AS and sink tree) and with respect to the interdomain topology seen by BGP. We show that despite the important variability of interdomain flows, it would be useful for a non-transit ISP to traffic engineer its access traffic by relying on a sink tree aggregation level.