A TABUSEARCH IMPLEMENTATION TO SOLVE THE LOGICAL TOPOLOGY DESIGN PROBLEM FOR LOW CONGESTION REQUIREMENTS

Transcription

1 Master in Optical Communications and Photonic Technologies A TABUSEARCH IMPLEMENTATION TO SOLVE THE LOGICAL TOPOLOGY DESIGN PROBLEM FOR LOW CONGESTION REQUIREMENTS Optical Networks Prof. Marco Mellia Assigned to: Guido Alejandro Gavilanes Castillo (S13155) POLITECNICO DI TORINO Turin, Italy April 26

2 I. INTRODUCTION The versatile characteristics wavelength routed networks offer open the door to the challenge of controlling and configuring optical media resources (such as transceivers, available wavelengths) as optimal as possible; normally, this is an issue which takes many variables into account and also this optimization depends often on our criterion on what is this optimal point. At some scenarios, The optimal point of configuring a set of nodes to form a network could be to use the less transmitters as possible; at some other point of view, optimize the number of wavelengths (due to a certain number of them available); and sometimes it is necessary to maintain congestion under control to the lowest value; which is the case dealt in this report. Avoiding congestion over an optical network is an important issue since congestion over a link causes high buffering on transit nodes, and these transit nodes (which have to pass information from optical to electrical, and then again to optical domain) get congested thanks to having to route traffic from others, and the entire effect translates in an apparent lack of resources in some network nodes and excessive delays or data losses. The adequate disposition of nodes and light paths between them to achieve minimum congestion is a well known optimization task, known as Logical Topology Design Problem (LTD) and it is also well known its NP-Complete problem characterization, which makes it difficult to solve in a fast and straightforward manner at the same time. At first sight analyzing this problem when a step forward is given to solve the optimization problem it turns out the fact that the problem itself has changed to new conditions, (routes has changed, for example) and then this generates a multi branch set of options which computationally is difficult to solve deterministically. Many models have been proposed to solve this problem with relatively low computational power and in this field Heuristic and random algorithms are mixed to produce results. As a goal of this report, it is to show an implementation of some of those techniques in order to solve this particular problem in well defined scenarios. To achieve this goal, different algorithms and heuristics will be described and also the results obtained with the corresponding implementation. II. BRIEF REVIEW OF SUITABLE METHODOLOGIES HEURISTIC ALGORITHMS Searching for answers about how to solve a logical topology design problem, the first option is to consider intuitive or heuristic algorithms, based on the perception and common sense; usually these algorithms are expressed in few words and are use iterative processes until a certain condition is reached. In these cases heuristic algorithms take a variable, traffic matrix or problem constraints and apply the 1

3 iterative process depending also from the performance metric used; some examples are: Best random Solution (generates solutions, keeping the one with best performance metric). Single Hop Traffic Maximization Route and remove links. SEARCHING ALGORITHMS AND TABU SEARCH As deterministic algorithms based on criteria can offer a certain amount of freedom on the solutions obtained, searching algorithms arise as a mean to explore the solutions space looking for better solutions than the ones based on heuristics. A process which involves having a register of already visited solutions usually is adopted. At the end, certain conditions permit the algorithm to converge to a suitable solution. In searching algorithms there can be found certain amount of randomness as a source of new values and combinations to toss to the main search process, and this often makes the process less deterministic; price that has to be paid in terms of better solutions than more deterministic algorithms. In this classification there can be found Genetic algorithms (resembling principles on natural selection, generations, mutations and all these processes in a repetitive scenario), Simulated annealing, which generates similar solutions keeping them with certain probability, and Tabu search, which explores the space having memory of already visited solutions. The last technique is the one used here because it has been proven a certain effectiveness in finding optimal solutions, and here it is presented a reduced implementation which could be also improved by iterating on its development from basic model described here. III. PROBLEM FORMULATION SPECIFIC LTD REQUIREMENTS The Logical Topology Design Problem attempted to solve here is specified within some constraints of limited resources and performance metrics such that: Given a number of nodes, each one equipped with an equal (delta) amount of transmitters and receivers. Given a Traffic matrix which describes the relative point to point traffic needs of the network (each one specified as a normalized value in the space [1,5] and could be generated as a random set of values). And given the fact that the routing algorithm routes all traffic under single path and minimum hop conditions. A logical topology to satisfy these requirements must be found which also minimize the maximum congestion on light paths. This congestion would be the highest traffic per link of final configured network. 2

4 THIS TABU SEARCH IMPLEMENTATION Why Tabu Search In order to solve the LTD described above, Tabu search was chosen as the final option having tested previously a heuristic algorithm, which crashed without converging to a solution in the first test scenarios (reported below in solution assessment section) and at the same time gave the author the idea of how would it be possible to search through a wide set of possible solutions thanks to the concept of sorting the traffic requirements and tossing them in sequence to a network graph tool in order to apply routing and test performance. At the beginning of the process looking for an algorithm, tabu search didn t appear as an option, because the concept of space of solutions wasn t realized entirely. When the traffic requirement sorted sets appeared as the solution to be optimized for an specific traffic matrix, tabu search was realized then as a possible technique to solve the problem; and this implementation is reported on the following pages. Description With the problem requirements it has been also provided a software tool which was able to deal with graph configuring, directional link placement, traffic matrix input, and routed traffic calculation. This tool was used in order to reuse these already coded functionalities. Starting from an empty graph environment, the first step is to obtain the traffic requirements from the system, which means generating this matrix (which in a real situation would be provided as target traffic requirements) within the program and recovering it in a structured way: a list of source-destination pairs associated with a normalized traffic amount. With this list stored, the requirements are first sorted having first the most demanding pairs in terms of traffic. Start Search Generate traffic request set from traffic matrix. Sort first request set to use Better Solution? No Change Traffic Request set solution (not in tabulist). [Random, Range, Defect] Apply traffic requests set to graph [FRH,FLH] Save in Tabu List Change entirely solution Save: Traffic, trfmax, request set Change based on last request failed in set (range) No Solution Generated? Yes Time to exit? Yes Put a defect on solution Solution generated Figure 1. Implemented search algorithm flow based on Tabu Search Techniques. Each wrong solution is completely changed, and correct ones are just slightly changed in order to have probably better solutions on each iteration. This sorted list is the starting point of solutions for the main program. Note that here is applied a heuristic combined with the search algorithm shown below; this heuristic could be called Highest Traffic First (HTF) from now on. Starting from 3

5 these traffic requirements list, the program starts to pass them sequentially to the graph tool, applying changes, rerouting and watching the constraints given (delta number must not be exceeded). Each requirement will be applied in the graph one at a time thanks to 2 parametric heuristics: First Routing Heuristic and First Link Heuristic. Both heuristics apply for different advantages for optimization as shown below. Each heuristic will provide a different development of requirement applications, and some sorted combinations of them probably will find a constraint which will make the sorted solution to crash, but here is when the tabu search technique rises, which will take care of this issue. Each result (maximum congestion obtained for a configured topology) is searched until a new and lower value is reached, putting prior old solution on tabu list (avoided solutions). Solutions found are also explored once more by putting a random defect on a previous obtained solution in order to find a possible better one. The algorithm keeps on searching solutions until: some amount of them are found or a certain try limit is reached, these quantities were put in the program depending on the number of nodes considered, so small times are enough for small network configuring and large times are required for a large network to converge to a single solution. Dependencies of these limits are set as allowed search cycles proportional to N square and maximum number of solutions proportional to N. and have been set as empirical values due to various tests performed during program debug time. Figure 1 is a flow description of the main search algorithm. There can be outlined the change traffic request set functionality, which changes the set sorting in order to put other traffic requests before some others, and in this way optimize the solution. This change can be done by means of 3 different ways: Change based on range, which takes how many traffic requests have been applied before the previous solution crashed, and from this position the set is changed. Totally Random solution changes entirely the wrong solution and Put a Defect on Solution changes the traffic request set in one of its members. HEURISTIC ALGORITHMS UNDER TEST As it is explained in previous items, there are some heuristics which will determine the behavior of the search, and in fact these differences will be shown in results section, by putting which heuristic to use as a parameter. First Route Heuristic Under this heuristic, a traffic requirement between a node and another can be attended first trying to obtain an existing route between the nodes, then if this is not possible, adds a link between them to satisfy the requirement with the shortest route. This behavior obeys to the fact that initially, there must be enough links to route first traffic requirements, but also the maximum number of inbound/outbound links per node (delta) is allowed, so, at the beginning solutions with a low delta and high number of nodes will crash easily, decreasing the overall behavior of the entire search algorithm. This fact is a test that could be verified with the simulations and looking at the overall behavior comparing both heuristics. 4

6 But a secondary effect of this for a delta large could be a higher congestion level for generated solutions, since there could be possible to generate a connected solution with less links per graph. First link Heuristic This heuristic in the contrary, attempts to link both nodes by default. If the constraint of delta is found, then traffic will be rerouted by the existing links. This can cause an explosion in the number of links used per graph since it will use the most as possible. Higher Traffics First This is a concept reported above on implementation description is more intuitive corresponding to the fact that as the LTD problem must be solved optimizing maximum congestion, it sounds reasonable and intuitive to dispatch higher traffic requests in the first steps, to avoid increasing maximum congestion at the end, when possibly there is no more to do to improve a certain solution. IV. SOLUTION ASSESMENT PERFORMANCE IMPROVEMENT Taking a comparison plot with data generated through both heuristics, there must be an improvement in maximum congestion (lower) in solutions generated through FLH as stated above. This will also be paying a small additional delay to FRH. For higher number of nodes it will be a higher delay until a new solution is obtained. NUMBER OF LIGHT PATHS As Ligth paths are resources and hence a typical constraint of the problem, this constraint will be given by the parameter delta. Solutions will be characterized by a limit behavior, which consists on that low values of delta (near 1,2) will generate inevitably high relative congestion solutions (respect to other values of delta); despite of this fact, they will be the best solutions available in either case; the relative congestion respect to other solutions is due to the fact that with delta equal to one (the worst case), the solution must be constrained to a ring, in which each light path will carry many other traffic amounts from other nodes in the network. TEST CONDITIONS As the analysis of these algorithms results rely mostly on data input generation and output collection procedures, an alternate program was written to provide all required values to the main search program in order to test the main features outlined above and store the different results in order to generate reports which can provide some additional information. There are 3 degrees of freedom in which parameters can be feed to the main program: delta, Number of Nodes, and Apply heuristic to use (FRH or FLH). Number of nodes was swept in values from 3 to 1, both Heuristics and delta from 1 to 8. This leads to have the results for 128 samples with the different outputs stored, this amount could be enough to consolidate certain average values among all samples taken. Traffic matrixes are generated as simulations take place, the only restriction stated about them is the one mentioned in problem formulation, which sets a minimum and maximum value for each traffic requirement (which has to be random). 5

7 REFERENCE TOPOLOGIES The first way in which the program began being tested and debugged was the initial topology build up: a reference topology with 3 nodes and delta=1. For this case, there is only a reduced set of solutions (actually only 4) which can be easily drawn in mind during debugging time to check proper program functionality. When the program was ready to follow this solution, and other tests were performed, the program would be then ready to work for other values. V. RESULTS GENERAL BEHAVIOR An Overall survey of solutions obtained after sweeping the main program with values can be obtained by means of three curves. These curves compare both heuristics, FRH and FLH. Maximum congestion, Time required completing the solution and number of links per graph. 1 HEURISTICS BEHAVIOR - CONGESTION 9 FLH FRH MAXIMUM CONGESITON [A.U.] DIFFERENT SCENARIOS Figure 2 Results for the same input data for both heuristics. It can be seen an average difference between both, but finally does not represent a drastic difference as both follow the same shape given by the conditions of each scenario. Maximum congestion is measured in arbitrary units, which represent a normalized amount of traffic, and comes from traffic matrix generated randomly from the beginning. As it can be observed, both heuristics follow the same pattern behavior within the test conditions, given by the same conditions on each run, and more or less show a very low difference, as was expected when heuristics were conceived. As concerning for time required to obtain a solution due to both heuristics, the final result is not an appreciate gain on this time required, differences are just evident, showing the tabu search algorithm is performing the solution selection independent of the heuristic used. 6

8 As for links used, on each solution, FRH could be an option in a scenario where also link optimization must be achieved in some way; certain amounts of links in FLH solutions can have almost unused light paths. This is the tradeoff in which the specific target application sets the conditions. AVERAGE TIME REQUIRED [s] HEURISTIC BEHAVIOR - TIME REQUIRED DIFFERENT SCENARIOS TIMEFRH TIMEFLH Figure 3. For the time required for both heuristics, the randomness introduced is added to the heuristics difference, which makes a little difference and also make this difference magnitude also random. HEURISTIC BEHAVIOR - LINKS TOTAL NUMBER OF LINKS/GRAPH FRH FLH DIFFERENT SCENARIOS Figure 4. As it was expected, the number of resources per graph each test is reduced with FLH heuristic, but as mentioned previously, doesn t offer the best optimized solution in terms of congestion. 7

9 OPTIMIZATION GOAL As the optimization issues were since the beginning directed to solve the LTD problem optimized for low congestion, the performance metric will be on this case the maximum normalized traffic obtained in all the links in the logical topology configured by tabu search implementation. This value of congestion, it can be noted on figure 5 left, depends strongly from the delta parameter as the number of MAX CONGESTION [A.U.] MAX CONGESTION COMPARISON RMAX (delta=2) RMAX (delta=3) RMAX(delta=1) RMAX (delta=4) NUMBER OF NODES (N) nodes increases. Note that having delta equal to one constraints the network to a ring topology, making its congestion higher and higher with the number of nodes. For delta equal to 2, the situation is similar but the rate of change is lower, and so on for higher values of delta. The value of delta acts then as a traffic scattering parameter through the network, because it alleviates overall congestion (traffic concentration on a single link) creating the shortest paths to send traffic. Left plot shows a tendency of both algorithms to produce more different maximum congestion values as the number of nodes increases, this is just as expected as the cumulative differences in more simpler conditions are added together to make a high difference in higher order (number of nodes) networks. THIS IMPLEMENTATION PERFORMANCE As the optimization issues are being filled under a wide spectrum of conditions, it is necessary to check for the algorithm performance. This can be characterized by looking at first general behavior (Figs 2-4) and figure 6. solutions are distributed in time almost linearly and as explained above, the search algorithm stops when a certain condition is reached (number of search cycles exceeded or number of solutions found), but as this condition depends on the number of nodes as specified on algorithm description, it is expected of this dependency to show up here. MAXIMUM CONGESTION [A.U.] HEURISTIC BEHAVIOR - CONGESTION TIME FRH TIME FLH NUMBER OF NODES (N) Figure 5. Maximum congestion dependency from different factors, combined number of nodes and delta, and number of nodes in terms of the heuristic taken. The increasing difference between them in the second case could be the main drawback of FRH as the number of nodes increases. 8

10 PROCESSING TIME REQUIRED 25 TIME REQUIRED [s] TIME(delta=2) TIME(delta=1) TIME(delta=3) TIME(delta=4) NUMBER OF NODES (N) Figure 6. Dependency of solving time required on the number of network nodes. The worst case in which a search can take a long time is the case where all search cycles have been executed, which depends on N square. That is the upper bound of the time to be reached; the algorithm can also take less than that to reach a solution. In the most general case there is an almost linear region in which number of nodes and processing time are linearly related. SOLUTION DEPENDENCY WITH DELTA Different values of delta behave in similar ways each to another. Plots shown on figure 6 tell us there is a big dependency of performance at lower values of delta. And the situation is worse increasing the number of nodes; but for higher values of delta the congestion level becomes invariable and sets an upper bound in maximum congestion achieved for each number of nodes (see on left plot). This is an interesting result since corresponds to a total fill of congestion requirements, caused by enough number of links scattering traffic through the shortest routes. 9

11 This also means there is an optimum value of delta which achieves the minimum possible congestion condition and also the less waste of network resources (light paths available); for N equal to 3, this limit could be 2 (almost obvious at first PROCESSING TIME REQUIRED - FLH MAXIMUM CONGESTION ACHIEVED - FLH N=3 N=5 N=7 TIME REQUIRED [s] N=3 N=5 N=7 MAXIMUM CONGESTION [A.U.] DELTA Figure 6. Time required to obtain a solution and maximum congestion obtained on the solution have a dependency shown on each graph, but this dependency tends to fade out with increasing delta DELTA sight) but with N equal to 7, only 3 to 5 links per node could be used to achieve minimum possible congestion. Having this in mind, as more simulations are completed, a rule of thumb can be derived to have a criterion to design the physical topologies that will host these logical topologies. VI. CONCLUSIONS Up to this point, a solution to Logical Topology Design Problem has been proposed and tested through a set of simulations, and the results not only permit to infer the proposed algorithm behavior but also permit to conclude about the general behavior of maximum congestion dependency on different network parameters. As intuition and qualitative analyses lead to have an idea about the results of the most optimal topologies (without even generate them) having the results obtained stated on these graphs, confirm both perceptions that the algorithm proposed is intended and finally built to minimize congestion and also it has clarified our perception of variables compromised in the optimization process. Searching for better solutions, the adoption of some heuristics can be followed as a rule of thumb to optimize the search process and put some more intelligence on it. VII. REFERENCES AND BIBLIOGRAPHY Yufeng Xin, George N. Rouskas, and Harry G. Perros, On the Physical and Logical Topology Design of Large-Scale Optical Networks, JOURNAL OF LIGHTWAVE TECHNOLOGY, VOL. 21, NO. 4, APRIL 23. 1

12 Rajesh M. Krishnaswamy and Kumar N. Sivarajan, Design of Logical Topologies: A Linear Formulation for Wavelength-Routed Optical Networks with No Wavelength Changers, IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 9, NO. 2, APRIL 21 M.Mellia1, A.Nucci1, A.Grosso2, E.Leonardi1, M.Ajmone Marsan, Optimal Design of Logical Topologies in Wavelength-Routed Optical Networks with Multicast Traffic IEEE,