IGP Link Weight Assignment. for Transient Link Failures

Transcription

1 IGP Link Weight Assignment 1 for Transient Link Failures A. Nucci, B. Schroeder, S. Bhattacharyya, N. Taft, C. Diot Sprint Advanced Technology Labs, Burlingame, CA 941, USA Carnegie Mellon University, Pittsburgh, PA, USA bschroeder@cs.cmu.edu Abstract Intra-domain routing in IP backbone networks relies on link-state protocols such as IS-IS or OSPF. These protocols associate a weight (or cost) with each network link, and compute traffic routes based on these weights. However, proposed methods for selecting link weights largely ignore the issue of failures which arise as part of everyday network operations (maintenance, accidental, etc.). Changing link weights during a short-lived failure is impractical. However such failures are frequent enough to impact network performance. We propose a Tabu-search heuristic for choosing link weights which allow a network to function almost optimally during short link failures. The heuristic takes into account possible link failure scenarios when choosing weights, thereby mitigating the effect of such failures. We find that the weights chosen by the heuristic can reduce link overload during transient link failures by as much as at the cost of a small performance degradation in the absence of failures ( ). I. INTRODUCTION Large IP networks use a link-state protocol such as IS-IS or OSPF as their Internal Gateway Protocol (IGP) for intra-domain routing. Every link in the network is assigned a weight, and the cost of a path is measured as the sum of the weights of all links along the path. Traffic is routed between any two nodes along the minimum cost path which is computed using Dijkstra s shortest path forwarding (SPF) algorithm. Thus setting the link weights is the primary traffic engineering technique for networks running IS-IS or OSPF. Appendix included for review purposes only

2 2 Cumulative distribution Percentage Transient failures (<1min) Long failures (>1min) Failure duration (minutes) Fig. 1. Failure duration distribution in Sprint s network Jan- April Simultaneously failed links Fig. 2. Distribution of simultaneous failures in Sprint s network Jan-April 22. The distribution is shown separately for transient failures ( minutes) and longer failures ( minutes) The traffic engineering objectives of an IP backbone are largely determined by the service-level agreements (SLAs) with its customers, which typically include speed-of-light delays and lossless packet delivery. Accordingly, there are two main goals when setting link weights: keeping end-to-end delays low and ensuring that no link is overloaded. Several formalizations of the problem of selecting link weights that are optimal with respect to the above traffic engineering objectives have been shown to be NP-hard [1], [2]. A common recommendation of router vendors is to set the weight of a link to the inverse of its capacity [3]. The idea is that this will attract more traffic to high capacity links and less traffic to low capacity links, thereby yielding a good distribution of traffic load. Another common recommendation is to assign a link a weight proportional to its physical length in order to minimize propagation delays. In practice, many backbone operators use the ad-hoc approach of observing the flow of traffic through the network, and repeatedly adjusting the weight whenever the load on a link is higher or lower than desired. The problem has been addressed formally [1], [5], [6] using different techniques from operations research. We discuss related work in more detail in Section V. A drawback of most current approaches (with the notable exception of [5]) is that they view the link weight assignment problem as a static problem largely ignoring network dynamics. However in practice, one of the main challenges of a network operator is to deal with link failures that are encountered on a daily basis in large IP backbones. When a link fails, IS-IS/OSPF routing diverts the traffic over that link to alternate paths, increasing the load of or more of the other links. The most obvious way of restoring the network to its original traffic engineering objectives is to perform a network-wide recomputation and reassignment of link weights. [5] has shown that changing just a few link weights is usually sufficient to rebalance the traffic. However changing link weights during a failure may not be practical for two reasons. First, the new weights will have to be flooded to every router in the network, and every router will have to recompute its minimum cost path to every other router. This can lead to considerable instability in the network, aggravating the situation already created by the link failure. The second reason is related to the short-lived nature of most of the link failures. Figure 1 shows the distribution of inter-pop link failures in Sprint s IP backbone over a four-month period (January-April 22)[7]. We observe that as many as of the failures last less than minutes

3 3 and of the failures last even less than a minute. We define transient failures as those failures that last less than minutes. Transient failures can create rapid congestion that is harmful for the network [15]. However, they leave a human operator with insufficient time to reassign link weights before the failed link is restored. We observe from the Sprint network that transient failures are mostly isolated. Figure 2 shows the frequency of simultaneous occurence of two types of failures: transient failures (less than minutes), and all others (longer than minutes). For each, the figure plots the time during which a given number of simultaneous failures was seen on the Sprint network, computed as a fraction of the total time during which one of more failures occurred. We observe that more than of the transient failures are isolated. For the long-lived failures, only about are isolated. This is because a majority of the long-lived failures are caused by optical fiber cuts that can affect several links simultaneously. In contrast, transient failures are due to maintenance windows, line card and optical equipment failures, and router software problems. We focus on minimizing the impact of transient link failures on traffic. Accordingly, we propose an approach for assigning link weights in IS-IS/OSPF networks that takes into account the isolated failure of any possible link in the backbone. The goal is to find one set of link weights that works well in the absence of failures and, at the same time, does not overload any link during transient failures. The heuristic achieves this goal by finding weights that balance traffic evenly among alternate paths during a link failure. This approach provides considerable benefit for stable network operations since the network can function almost optimally in the presence of transient failures without requiring any weight change. This is also the only applicable approach for the kind of failures addressed in this work. We study the performance of this heuristic using a computation-based approach. For a given network topology and traffic demand matrix, we first use our heuristic to assign link weights. We then use Dijsktra s SPF algorithm to determine minimum cost routes, and compute performance metrics of interest for these routes. We validate the performance of the heuristic using an Integer Linear Program (ILP) model. Results show that the heuristic performs within of the lower bound obtained from the ILP model. It is not possible to find a single weight set that performs equally well both for transient failures and in the absence of failures. However, our algorithm finds a weight set that restricts link loads to less than during any link failure. In comparison, a traditional weight selection approach that does not consider link failures results in a maximum link load of for the same network. This improvement comes at the cost of a small increase in maximum link load in the absence of failures. However, there is no degradation in end-to-end delays across the network due to congestion. For ease of exposition we discuss this work with reference to IS-IS in this paper. Nevertheless, all the results are equally applicable to any other Internal Gateway Protocol including OSPF. The rest of the paper is organized as follows. Section II formally states the problem addressed in this work. Section III describes the Tabu Search heuristic for the link weight selection problem. Section IV analyzes the performance of the heuristic. Section V discusses related work and Section VI concludes the paper. The Integer Linear Program (ILP) model used to generate a lower bound for the heuristic is presented in the appendix.

4 J 4 II. THE LINK WEIGHT SELECTION PROBLEM The problem of computing IS-IS link weights can be formally stated as follows. We represent a network by an undirected graph where corresponds to the set of nodes and corresponds to the links connecting the nodes. Each edge has a bandwidth capacity and integer ISIS weight. Let be the cardinality of the set. Let be a traffic matrix representing the traffic demands such that correspond to traffic demand between origin node and destination node. Henceforth we will refer to an origin-destination network node pair as an O-D pair. The traffic demand between an O-D pair and is routed along the minimum cost path from to, where the cost of a path is measured as the sum of the weights of the links along the path. If multiple paths exist with the same minimum cost, the traffic demand is split equally among all these paths. The problem is to choose a single set of link weights "!#!#!# %$& so as to optimize a given objective function. The objective function is typically selected to meet the traffic engineering goals of a network. An important traffic engineering goal for IP networks is to distribute traffic evenly so that no link carries an excessive load. The load on a link is defined as the ratio of the traffic carried by the link to its capacity. A common approach is to choose routes so as to minimize maximum load over all links in the network. This is also the objective function chosen for this work. The problem of choosing link weights to minimize maximum link load is NP-Hard [1], [2]. A novel aspect of our approach to the link weight selection problem is that we consider transient link failures. We model the occurence of isolated transient failures in the network as state transitions. In the absence of any such failure, the state of the network is denoted by ')(. During the transient failure of link * (*+,.-/ """ ), the state of the network is denoted by '21. We refer to the maximum link load of the the network in any given state as the bottleneck load. Let 34 5'768 %9 be the bottleneck load in state ':6. '<; = is defined as the state with the maximum bottleneck load over all network states, i.e., 34 5' ; 5= %9>34 5' 6? A@CBDFE C HG. Henceforth we refer to state ' ( as the no-failure state, and the state ' ; 5= as the worst-failure state. The problem of selecting IS-IS weights has been traditionally addressed for state 'H(, which implies that link weights are selected to minimize 34 5'&(I [1], [5], [6]. Instead a network operator may be interested in limiting the maximum link overload due to any single-link failure event. In that case, it is appropriate to choose link weights so as to minimize 34 5'<; =. Selecting a weight set that is optimal for the network in a failure state may result in sub-optimal performance in the absence of failures. We want to meet two objectives: preventing link overloads during a failure while simultaneously minimizing performance degradation in the absence of failures. We thus choose the following objective function: K %LNMO P34 5'<(I 2QRMS34 5'T; = (1) where M U C 8 is an artificial parameter that helps in minimizing performance degradation in the absence of failures while maximizing the gain for any transient failure. Setting M to corresponds to finding link weights without considering failures. On the other hand, setting M to results in link weights that minimize the maximum load under

5 5 any failure, but completely ignore performance in the absence of failures. For very small or very large values of W (e.g., M C! or M C! ), the term in J with the large coefficient is the major objective, yielding potentially several optimal solutions that are disambiguated by the value of the other term in F. III. SEARCH HEURISTIC FOR LINK WEIGHT SELECTION In this section we present the heuristic. We start with a brief overview of the Tabu Search methodology and then describe the important elements of the heuristic. A. Overview of Tabu Search The heuristic we propose is based on the Tabu Search 'H [8] methodology. TS is an iterative procedure designed to solve optimization problems. It is based on selected concepts that unite the fields of artificial intelligence and optimization. It has been applied to a wide range of problems such as job scheduling, graph coloring and network planning, and is considered as an alternative to techniques such as simulated annealing and genetic algorithms. TS conducts a guided exploration of the space of admissible solutions, keeping track of all solutions evaluated along the way. The exploration starts from an initial solution that is generally obtained with a greedy algorithm. When a stop criterion is satisfied, the algorithm returns the best visited solution. To move from one solution to the next, TS explores the neighborhood of the last solution visited (referred to as the current solution). It generates a neighbor solution by applying a transformation, named as a move, on the current solution. The set of all admissible moves (determined by the rules guiding TS) uniquely defines the neighborhood of the current solution. At each iteration of the TS algorithm, all solutions in the neighborhood are evaluated, and the best is selected as the new current solution. TS occasionally moves from a better solution to a poorer one during the search procedure. This is in contrast to local search heuristics which move only towards better solutions but that may get stuck in local minima. Note that, in order to efficiently explore the solution space, the definition of neighborhood may change during the exploration; in this way it is possible to achieve an intensification or a diversification of the search in different solution regions. A special rule, the Tabu list, is introduced in order to prevent the algorithm from deterministically cycling among solutions already visited. The Tabu list stores the last accepted moves; while a move is stored in the Tabu list, it cannot be used to generate a new move. The choice of the Tabu List size is very important - too small a size may cause a periodic repetition of the same solutions, while too large a size may severely limit the number of applicable moves, thus preventing a good exploration of the solution space. B. TabuISIS: Tabu Search for link weight assignment The fundamental elements of the link weight assignment heuristic, TabuISIS, are described below: Precomputation Step. Before running the Tabu Search, we use an approximation to speed up the search procedure by reducing the size of the search space. Each solution in the search space consists of a set of routes for all

6 6 traffic demands. We therefore choose a criterion to filter out a subset of possible routes. This filtering is based on a hop-count threshold. Only routes with hop-counts less than the threshold are considered admissible and considered during the search procedure. This approximation is based on the intuition that Tabu Search will generally avoid very long routes that consume network resources unnecessarily. The choice of a hop-count threshold is based on the network topology under consideration. Choosing a small value for the threshold will eliminate most routes from consideration and may prevent Tabu Search from visiting the optimal solution. On the other hand, a large value of the threshold may result in a very large search space. The time taken to find the optimal solution grows exponentially with the size of the search space, thereby making the search procedure very slow. Thus the hop-count threshold allows Tabu Search to efficiently explore the search space with a reasonable computational overhead. The selection of hop-count threshold is discussed further in Section IV. Initial Solution. The choice of the initial solution is important since it can significantly affect the time taken by the search procedure to converge to the final solution. We set the initial weight of each link to be the inverse of the link capacity - a common recommendation of router vendors [3]. Moves and Neighborhood Generation. Each move corresponds to perturbing one or more of the weights in the current weight set. The first step in a move is to run Dijkstra s SPF algorithm for the current weight set, generate all minimum-cost routes and compute the traffic load for each link. We then identify two sets of links - links whose loads are within a small percentage of the maximum load (heavily loaded) and links whose loads are within a small percentage of the minimum load (lightly loaded). A link is selected at random from the heavily loaded set and its weight is increased (in order to divert traffic to other paths and reduce its load). Then, a link is selected at random from the lightly loaded link set and its weight is decreased. The goal is to attract traffic towards this link and potentially reduce the load on other, more heavily loaded, links. A new neighborhood is designed by repeating the above procedure. Evaluation of each solution. Every solution in the neigborhood is evaluated as follows. Minimum cost routes are computed using the SPF algorithm and the traffic load on each link is determined for a given traffic matrix. This evaluation is performed when there is no failure in the network and for each possible link failure. Then the objective function in equation (1) is computed. Diversification. This is needed to prevent the search procedure from indefinitely exploring a region of the solution space with only poor quality solutions. It is applied when there is no improvement in the solution after a certain number of iterations (each iteration consists of generating a new neighborhood and selecting the best solution in the neighborhood). The diversification is a modification of the move described earlier. In the case of a move, only one link each is chosen at random from the heavily loaded link set and the lightly loaded link set. For diversification, several links are picked from each set. The weights of the selected links from the heavily loaded set are increased while the weights of the selected links from the lightly loaded links are decreased. This diverts the search procedure to a different region of the solution space where it resumes the process of neigborhood

7 7 generation and solution evaluation. Tabu List. For TabuISIS, the Tabu list is used to remember the most recent moves made, consisting of the links whose weights have been changed and the increase/decrease applied to the link weight. Stop Criterion. The search procedure stops when a fixed pre-determined number of iterations is reached. The number of iterations is defined based on the size of the network in consideration, the computational time needed and the quality of solution desired. IV. RESULTS We analyze the performance of our link weight assignment heuristic using a computation-based approach. For this evaluation, we choose a network topology and a traffic matrix and compute link weights using TabuISIS. Based on these weights, the minimum-cost routes for all source-destination traffic demands are determined and the resulting load on every link is calculated. The objective function value for this heuristic solution is then compared against the lower bound obtained from the ILP model (presented in the appendix). The ILP is solved using the CPLEX software package [1]. A. Topology Fig. 3. PoP-level Sprint network The primary goal is to understand the benefits and/or tradeoffs, if any, of taking single-link failures into account when computing IS-IS link weights. For IP backbones, the failure of long-haul inter-pop links between cities is significantly more critical than link failures within a PoP, since every PoP has a highly meshed topology. Accordingly we consider a single representative topology based on the Sprint IP backbone, consisting of nodes (each corresponding to a PoP) and full-duplex links (Figure 3). Links are assigned integer weights in the range of 5 and 255, based on current practices in the Sprint network. We emphasize here that TabuISIS does not rely on the properties of any specific network topology and is therefore equally applicable to any topology or graph.

8 8 Number of Iterations Hop Count Threshold Maximum Link Load [%] Hop Count Threshold Fig. 4. Effect of hop-count threshold on number of iterations to reach final solution (left) and the maximum link load for the final solution reached (right). Both graphs are for the no-failure case ( ). B. Traffic Matrices The second input for the link weight selection problem is the traffic demands between origin-destination node pairs, represented by a traffic matrix. Unfortunately very little data exists on PoP-to-PoP traffic matrices for operational backbones. We therefore use synthetic traffic matrices for evaluating our heuristic. In this paper, results are presented for two different forms of traffic matrices: Gravity Model (GM). This form of the traffic matrix is based on the findings in [11] about the characteristics of PoP-to-PoP traffic matrices in Sprint s IP backbone. The volume of traffic from node * to node B is selected as follows: 1 6 E, G (2) 6 where 1 is the total volume of traffic originating at node *, given by 1 and $#!" is a uniform random variable between and. uniform(1,5) if! #"NE C C! uniform(8,13) if $#!"% E C! / C! uniform(2,3) if! #"NE C! / G 6 &% 6 is the share of traffic originating at node * that is destined to node B. The 6 is a random number picked according to a uniform distribution between and,!. The key idea is to create three kinds of traffic demands by volume [14]. The fan-out of traffic originating at a given PoP is then determined by equation (2) in accordance with the observations in [11]. Negative Exponential (NegExp). Each entry in the matrix is generated according to a negative exponential distribution with mean ' Mbps. This is one of the several other forms of traffic matrices that we evaluated in order to validate the generality of our results. We choose this type of traffic matrix for discussing our results because it closely approximates the distribution of traffic demands seen in the Sprint network [14].

9 9 1 Number of Admissible Routes (logscale) T=12 T=1 T=8 T=6 T= Origin-Destination Pair id Fig. 5. Number of admissible routes per origin-destination node pair for different values of hop-count threshold (T). C. Reducing the size of the search space for TabuISIS We begin our discussion of results by describing how we speed up TabuISIS by reducing the size of the search space. As mentioned in Section III, the search space is reduced in the precomputation step using a hop-count threshold. The choice of this threshold depends on the characteristics of the network topology. The hop-count threshold has to be larger than the longest minimum-hop path for any origin-destination pair across all network states ' 6 B E C G. Otherwise, there will be no admissible route between some origin-destination pair(s) in one or more network states. By counting the hop-counts for all routes in the Sprint network, we found this value to be ' ; hence the hop-count threshold has to be at least '. Figure 4 shows the tradeoff between computational overhead of TabuISIS and the quality of the solution for the Sprint network with different values of the hop-count threshold. Link weights are selected without considering failures (M ). We have verified that the behavior is similar for other values of M. The graph on the left shows the number of iterations needed by TabuISIS to reach the final solution. We observe that the number of iterations grows exponentially fast - from - for ' to for I-. This shows that the parameter is necessary for enabling TabuISIS to efficiently explore the search space with a reasonable computational overhead. The graph on the right of Figure 4 plots the maximum link load in network state ' ( for the link weight set chosen by TabuISIS. A very small value of the threshold eliminates most routes from consideration and forces TabuISIS to choose a solution with a high value of the maximum link load. For example the max-link load for the TabuISIS solution with ' is whereas it is only - when. This shows that choosing a very small value of the threshold degrades the quality of the solution found by TabuISIS. Figure 5 explains the above observations. It shows the number of admissible routes per origin-destination pair for different values of the threshold ( ). The number of admissible routes for each origin-destination pair is only around for ' and around for. This eliminates the best solutions from consideration by TabuISIS. For, this number increases ten-fold to about. Consequently the maximum link load for the final solution found

10 1 Link Load [%] 1 9 TabuISIS-NegExp 8 ILP-NegExp Links Link Load [%] 1 9 TabuISIS-GM 8 ILP-GM Links Fig. 6. Comparison of link loads for TabuISIS and the optimal ILP solution with for the NegExp traffic matrix (left) and GM traffic matrix (right). by TabuISIS reduces to -. For higher values of threshold, the number of admissible routes increases at a slower rate - from for to for I-. But at this point, the search space is so big that any further increase in its size causes the computation time of TabuISIS to grow exponentially. Based on these results, we pick the hop-count threshold to be for the Sprint network. D. Validation of TabuISIS We validate the quality of the TabuISIS solution by comparing it with the ILP model. For TabuISIS we find a set of link weights for the NegExp and GM traffic matrices, compute shortest path routes and the load on each link. For the ILP model, we generate the set of optimal routes and then compute the load on each link. Figure 6 shows the link loads for TabuISIS and the ILP model for both types of traffic matrices. TabuISIS link loads are shown as bars while the ILP solution link loads are shown as a dashed continuous line. Links are ranked on the x-axis by decreasing link loads under TabuISIS. These results were obtained with M, which corresponds to the traditional objective of minimizing maximum load in the absence of failures. For the NegExp traffic matrix, the maximum link load is for TabuISIS and - for the ILP solution - a difference of only. Moreover, the distribution of link loads in the two cases are similar. For the GM traffic matrix, both TabuISIS and the ILP model yields the same value for the maximum link load. This indicates that TabuISIS was able to find the optimal value of maximum link load achievable by any routing strategy (with respect to the given objective function). This case has a special significance which is discussed later. The distribution of link loads for TabuISIS and the ILP solution are also similar for the GM traffic matrix. Results for the no-failure case (M ) are shown for a specific reason. We will subsequently evaluate the benefits of considering link failures in weight selection by comparing against weight selection with M. Therefore, it is important to establish first that TabuISIS yields a solution of high quality for M. However, we have performed this comparison for all values of M in [,1] and found that the difference in the value of the objective function in equation 1 is less than in all cases.

11 11 15 Maximunm Link Load [%] no failure state worst failure state W Fig. 7. Variation in maximum link load with for two cases - no-failure and the worst-failure W= W=.8 End-to-End Delay [ms] Origin-Destination Pair id Fig. 8. End-to-end delays per origin-destination pair for link weights chosen with and. E. Considering link failures in weight selection Figure 7 shows the variation in maximum link load with M for the NegExp traffic matrix. The maximum link loads are shown for the no-failure state (solid line) and the worst-failure state (dotted line). A value of M corresponds to a set of weights picked without considering failures. M corresponds to selecting weights that optimize performance in the no-failure state but ignore the performance degradation during failures. On the other hand, M corresponds to optimizing performance in the worst-failure state while ignoring performance in the no-failure state. We find that when M is varied from to, the maximum link load in the no-failure state increases from to. On the other hand, the maximum link load in the no-failure case reduces from to. This indicates that that performance during failures can be significantly improved by considering failures in link weight selection. However, this is achieved at the cost of a small performance degradation in the no-failure state. The maximum link load in the worst-failure state stays the same between M C! and M. However, the maximum link load for the no-failure state increases slightly between M C! and M. Therefore M C! produces the optimal performance trade-off between the no-failure state and the worst-failure state for the Sprint network and the NegExp traffic matrix. However, the most suitable value of M depends on the combination of topology and traffic matrix. It is therefore important to do the above analysis instead of picking a random value in E C G or just using the boundary values. Service-level agreements between network operators and customers include bounds on the average end-to-end delay.

12 no failure state, W= maximum load, W= no failure state, W=.8 maximum load, W=.8 Link Load [%] 9 6 Link Load [%] Link id Link id for the Sprint network and NegExp traffic matrix. The solid bars show the loads in the absence of failures. The dashed bar for each link shows the maximum load on that link for any link failure. Fig. 9. Link loads for weights selected with and Fig. 1. Link weights selected with and Assigned Weights W= W= Link id for the NegExp traffic matrix. Therefore it is important to ensure that our approach of considering failures in weight selection does not degrade endto-end delays in the network. Figure 8 shows the end-to-end delay for each origin-destination node pair for two sets of link weights - one chosen without considering link failures (solid line) and the other chosen by considering link failures (dotted line). These delay values were computed using knowledge of link propagation delays in the Sprint network. We obsever that there are significant differences for a few O-D pairs, e.g., for O-D pair, the delay increases from ' milliseconds to - milliseconds when link failures are considered in weight selection. However, the overall difference is small: the mean and standard deviation are ' -/! - - msecs and - /! - selection, and ' -/! same in both cases ( msecs when failures are not considered in weight msecs and - /! - msecs when they are. Moreover, the maximum delay over all O-D pairs is the msec). We now examine more closely some of the changes in weight assignment and route selection for M and M C!. Figure 9 shows the distribution of link loads for weight sets selected with M and M C! for the NegExp traffic matrix. In each graph, the solid bars show the link load in the no-failure state. The dashed bar for each link shows the maximum load of this link for any single link failure. Link Ids on the x-axis correspond to the labels on links in Figure 3. The distribution of link loads in the no-failure state is very similar in both cases. The maximum load for any single failure reduces from for M to for M C! (as seen earlier in Figure 7). Moreover, the distribution of maximum link load for any single failure has less variation for M C!. To gain insights into why it helps to consider link failures in weight selection, we focus on some specific links. Figure 1 shows the link weights for M in solid bars, and M C! in dashed bars. Link - connecting nodes

13 no failure state, W= maximum load, W= no failure state, W=1 maximum load, W=1 Link Load [%] 9 6 Link Load [%] Link id Link id for the modified Sprint network and GM traffic matrix. The solid bars show the loads in the absence of failures. The dashed bar for each link shows the maximum load on that link for any link failure. Fig. 11. Link loads for weights selected with and and (Figure 3) and link - connecting nodes and ' are assigned very large weights for both M and M C!. These links are the only ones connecting node to the rest of the network. When one fails, the other has to absorb all the load exchanged between node and the rest of the network. For M, TabuISIS does not consider this failover scenario when selecting weights. But it assigns large weights to these links in order to ensure that transit traffic (i.e., traffic not destined to node ) is diverted away from these links. With M C!, TabuISIS actually considers the failover scenario and tries to increase the weights even further to mitigate overload in the event of failure of either link - or -. The link that carries the maximum load for any single-link failure is link - connecting nodes and. This maximum load is caused by the failure of link which connects nodes and. Node is connected to the rest of the network via three links - link to node, link - to node and link to node -. For M, TabuISIS assigns weights, and - respectively to links, - and. In the absence of failures, the loads on these links are well-balanced -, and ' respectively. However, when link link fails, traffic between node and of the other nodes fail over to link - resulting in a load of. When TabuISIS considers link failures (M C! ), it actually plans ahead for the possible failure of link - and assigns weights -, - and to links, - and respectively. When link fails, traffic between node and of the other network nodes fails over to link -, while the traffic between node and the rest of the nodes fails over to link. This balances the failover traffic on the two alternate paths and reduces the impact of failure on any single link. F. Topology limitations As mentioned in the last section, links - and - in Figure 3 are node s only connections to the rest of the network. When one fails, the other must absorb all of the fail-over traffic. This is a topology limitation that affects any route selection strategy. We examine a specific instance of this problem for TabuISIS and the Sprint network. In Figure 6, we found that the maximum link load for TabuISIS and the optimal ILP solution was the same for M in case of the GM traffic matrix. Therefore there was no reduction in maximum link load with M. The maximum link load for any failure corresponds to the failure of link - connecting nodes and '. When M TabuISIS would attempt to address this problem by balancing the fail-over traffic over several alternate paths. It is,

14 14 Assigned Weights W= W= Link id Fig. 12. Link weights selected with and for the GM traffic matrix. impossible to do so for this specific case since there is only link to carry this traffic. A likely solution to this topology limitation is to add a third link between node and the rest of the network. Suppose that a link is now added between nodes and in the Sprint network. Figure 11 shows the distribution of link loads for this modified topology and the GM traffic matrix for two sets of link weights computed by considering failures (M ) and ignoring failures (M ). The solid bars show link loads in the absence of failure and the dotted bar for each link shows the maximum load on that link for any single link failure. Since, there are two alternate links in the event that link - fails, TabuISIS is able to select weights that balances the failover traffic between these two paths. Consequently, the maximum link load over all links is lower for M than for M. The problem of overload due to failover traffic actually shifts away from node to links - / C and -. When M, TabuISIS assigns much larger weights to these links (Figure 12) in order to achieve a better balancing of fail-over traffic in case of a failure. The above analysis shows that the TabuISIS heuristic is useful in improving capacity planning and traffic engineering in a network. It can help in identifying where new links or link capacity upgrades are needed. Alternatively, a network operator may be able alleviate the overload problem by modifying BGP [4] policies that govern how traffic enters and leaves the network from peer networks. In the above example, if the large traffic volume between node and the rest of the network was due in part to a large external peer that is multi-homed to the Sprint network, then an operator can engineer the peer s traffic to enter the network through some other node. That will reduce the amount of traffic that fails over to link - when link - fails. V. RELATED WORK Despite the obvious importance of the IS-IS weight selection problem, a formal approach to the problem has been undertaken only recently. The first work to address this problem was done in [1] which show that the problem of finding optimal IS-IS link weights is NP-hard with respect to many objectives. [1] proposes a local search heuristic to find weights for two objective functions. The first objective function is to minimize the maximum utilization across all links and the second one is to minimize a cost function that assigns every link a cost depending on the utilization of this link. They show

15 15 for both objective functions that their heuristic can computes weight sets that lead to solutions within a few percent of a theoretical lower bound. This bound is computed using linear programming much in the same way as we have done in this paper. Some other authors have evaluated the use of other methods from operations research for the link weight assignment problem. [2] and [6] implement heuristics based on local search, simulated annealing, Lagrangean Relaxation, and evolutionary algorithms. Furthermore, they propose a new method that uses a combination of simulated allocation and linear programming. This method is not guaranteed to find a weight set for every problem instance, but is also shown to work in of the cases. The authors find that in terms of the number of overloaded links and the degree of overload all methods perform similarly well. For larger topologies the new combined method is much faster than any of the other methods. [12] proposes the use of duality in linear programming to compute link weights. However, their method is limited to the case where unequal splitting is feasible. Neither OSPF nor IS-IS currently support unequal splitting, but only even splitting on equal cost paths. All the above methods view the link weight assignment problem as a static problem ignoring the case of link failures. [5] is the first work that looks at the problem of assigning link weights in the context of traffic matrix changes and link failures. [5] is mainly concerned with computing link weights that is robust to predicted periodic changes in the traffic demands. Instead of a single demand matrix, their heuristic picks weights based on several demand matrices, each of which represents the traffic pattern during a different time of the day. They show that it is possible to find a weight setting covering demand matrices dominated by convex combinations of the given matrices. They also briefly address the issue of link failure. They conclude that there are only a few links whose failure has a significant impact on the network. They show that changing even a single link weight in the event of a link failure can sometimes yield substantial performance improvements. However, changing link weights is an impractical solution for the isolated transient failures addressed in this paper. Another paper by the same author [13] addresses the problem of how to precompute backup routes around failures after a failure has been detected. This problem is unrelated to the problem we address in this paper. VI. CONCLUSIONS AND NEW DIRECTIONS We have examined the problem of link weight assignment for short isolated link failures, and proposed a novel Tabu Search Heuristic that takes into account such failures. To the best of our knowledge this is the first work to consider transient link failures for link weight selection. The approach is likely to be attractive to IP backbone operators who encounter short link failures on a daily basis. The proposed heuristic finds a single weight set that performs well in the absence of failures but prevents severe link overloads during failures. Results indicate that the heuristic finds a solution that is within of the optimal lower bound. The maximum load on a link during any single-link failure can be reduced by as much as over an approach

16 16 that does not consider failures in weight selection. This improvement comes at the cost of a small performance degradation ( ) in the absence of failures. This paper opens up a new avenue for studying the link weight assignment problem and the interaction of routing with link failures. Both the heuristic and the ILP model presented here are based on the notion of network states where each state corresponds to either no failure or a single link failures. Therefore this notion can be easily extended to the case of multiple link failures. For example, a network may have critical groups of links which are likely to fail together because they share common optical fiber conduits. In that case, each network state corresponds to the failure of a critical group. The heuristic as well as the ILP model can be applied to such multiple link failure scenarios with relatively straightforward extensions. In addition, work remains to be done on how errors in the input traffic matrix may affect link weight selection, and how often link weights have to be updated to track changes in the traffic matrix. REFERENCES [1] B. Fortz and M. Thorup. Internet Traffic Engineering by Optimizing OSPF Weights, Proceedings of IEEE Infocom, Tel-Aviv, Israel, March 2. [2] M. Pioro, A. Szentesi, J. Harmatos, A. Juttner, P. Gajowniczek and S. Kozdrowski. On OSPF Related Network Optimisation Problems, Proceedings of IFIP ATM IP, Ilkley UK, July 2. [3] D. Oran (Editor). OSI IS-IS Intradomain Routing Protocol, IETF Request For Comments [4] S. Halabi. Internet Routing Architectures, 2nd Edition, Cisco Press, 21. [5] B. Fortz and M. Thorup. Optimizing OSPF/IS-IS Weights in a Changing World, IEEE JSAC Special Issue on Advances in Fundamentals of Network Engineering, 21. [6] J. Harmatos. A heuristic algorithm for solving the static weight assignment optimisation problem in OSPF networks, Proceedings of Global Internet Conference, Dallas USA, Nov 21. [7] G. Iannaccone, C. Chuah, R. Mortier, S. Bhattacharyya and C. Diot. Analysis of Link Failures in a Large IP Backbone, Proceedings of 2nd ACM Sigcomm Internet Measurement Workshop (IMW), San Francisco USA, November 22. [8] F. Glover and M. Laguna. Tabu Search, Kluwer Academic Publishers. [9] M. Krunz, B. Zhang and C. Chen. Stateless QOS Routing in IP Networks, Proceedings of Global Internet Workshop Dallas USA, November 21. [1] [11] A. Medina, N. Taft, K. Salamatian, S. Bhattacharyya and C. Diot. Traffic Matrix Estimation: Comparisons and New Directions, Proceedings of ACM SIGCOMM Pittsburgh USA, August 22.

17 17 [12] Y. Wang, Zheng Wang and L. Zhang. Internet Traffic Engineering without Full Mesh Overlaying, Proceedings of IEEE Infocom, Anchorage USA, April 21. [13] B. Fortz and M. Thorup. Fortifying OSPF/IS-IS against link failures Technical Report available from mthorup/papers/papers.html. [14] S. Bhattacharyya, N. Taft, J. Jetcheva and C. Diot. POP-level and Access-link-level Traffic Dynamics in a Tier-1 POP, Proceedings of 1st ACM Sigcomm Internet Measurement Workshop (IMW), San Francisco USA, November 21. [15] K. Papagiannaki and C. Diot. Analyzing Link Utilizations at Small Timescales, Sprint ATL Technical Report TR3-ATL-19, January 23. APPENDIX We formulate the general routing problem with single-link failures as an Integer Linear Programming (ILP) problem. The goal is to derive a lower bound on the value of the objective function used for TabuISIS (equation 1). The IS-IS link weight selection problem is NP-Hard [1]. Hence it is computationally intractable to obtain the optimal solution. On the other hand, the general routing problem is computationally tractable. We therefore model the general routing problem to obtain a lower bound on the performance of TabuISIS. Unlike the link weight selection problem, the general routing problem directly selects routes between node pairs, instead of doing it indirectly via link weights. Also route selection is not restricted to minimum cost routes based on link weights. Instead, traffic can be arbitrarily routed along several paths between two nodes, and split in arbitrary ratios across these paths. Therefore an optimal solution to the general routing problem yields a lower bound on the objective function value for the link weight selection problem. A. Notation We aggregate all the traffic between a given origin-destination (O-D) node pair in the network into a single traffic demand. Let 8 1 be the set of all O-D pairs whose cardinality is described by and 8 1 be the set of bidirectional links belonging to the network topology whose cardinality is represented by F. The traffic demand associated with O-D pair is represented by. Let be the set of all the network states, whose cardinality is described by ' Q : )( represents the no failure case while 26 with B represents the failure case when the link 6 is broken. Let 5' 6 1 5' 6 be the set of all the feasible routes for the O-D pair in the network

18 state :6. A route in a failure network state ' is defined as feasible if it does not use the broken link. Let be the binary parameter that is equal to 1 if the * = route associated with O-D pair in the network state '<6, i.e. 1 5' 68, uses the link and otherwise. Let 1 5'2(?'76 be a binary parameter that is equal to 1 if 1 5'<(8 is equal to 5' 68 and otherwise. Note that when a link fails, we do not consider alternate routes for traffic demands that do not traverse the failed link. The rationale for this is as follows. The approach of this work is to find a single set of link weights for all network states. When a link fails, the link state protocol determines a set of alternate minimum cost routes for only the traffic demands that were being routed over the failed link. All other routes are left unchanged. We adopt the same approach in the formulation of the general routing problem in order to obtain a fair basis for evaluating TabuISIS. 18 B. Decision Variables Let 1 5'76 C represent the set of variables used to define which routes are selected by origin-destination (O-D) pair in network state ' 6. The variable 1 5' 6 is equal to 1 if the O-D pair uses the * = route in network state ' 6 ( 1 5' 6 ) and otherwise. Let 1 5' 68 9 be the fraction of traffic associated with O-D pair that is sent to the * = route in the network state ':6. The variables 5' 6 9 represent the aggregated load carried by link in network state ' 6. Let 1 5'768 C describe the feasibility of each route 1 5'<(I in each network state ' 6 ; 1 5' 68 is equal to 1 if O-D pair uses route 1 5'<(I and this route uses the broken link 6. When a link fails, all O-D pairs going over the link must be rerouted. Several feasible routes can be used to reroute this traffic. For route 1 5'<(8, let 1 5' 6 9 be the traffic associated with O-D pair that is routed over failed link 6. In other words, 1 5' 6 is equal to 1 5' ( if 1 5' 68 % and otherwise. Finally let 34 5':6 9 be the maximum link load in network state 'T6, while 34 5'<; = be the maximum link load over all the network states, i.e.34 5'); = 6 ( $ is denoted by '2; =. 34 5' 6. The corresponding network state C. Constraints Constraints associated with the maximum link load in each network state '&6 : 34 5' 6 9 5' A@< (3)

19 ' ; = ' 6 (4) where constraint (3) define the maximum link load in each network state '?6, while constraint (4) define the maximum link load over all network states. The variable 5'<(8 describes the aggregated traffic flowing on the link in the no failure state '( : 5'<(I H 1 1 5'<(8 (5) Constraints associated with routes used in ' ( and their associated traffic: 1 5'2(" (6) 1 1 5'<(I R 1 A@:*4 5'2(" (7) 1 (8) 1 where constraint (6) ensures that each O-D pair in ')( has to select at least one route to send its own traffic, while constraints (7) restricts the amount of traffic carried by each route. If 1 5'<(I, the total amount of traffic for O-D pair 1 on this route is restricted by ; if 1 5'<(8 then no part of the traffic for O-D pair 1 is sent over this route. The total amount of traffic associated with each O-D pair has to be sent using one or more routes (8). Constraints associated with routes affected by the failure of link B+ E, HG : 1 5' 6 1 5'2(" 1#( A@:* 5'<(8 A@< 6 A@2'76 L &( (9) 1 5' 6 9>- 1 5'<(8 1#( 6 A@:* 5'2(8 A@T 6 A@&' 6 L &( (1) where constraints (9,1) detect which routes used in ' ( are involved in the failure of link 6. Note that if O-D pair uses the route 1 5'<(8 and the link 6 belongs to 1 5'<(8 1 ( ( ( 1 5' 6 ). The traffic flowing on this route has to be rerouted using other feasible routes. 6 ), the route is not feasible for state 'T6