Label Switched Paths Re-configuration under Time-Varying Traffic Conditions

Transcription

1 Label Switched Paths Re-configuration under Time-Varying Traffic Conditions Sandford Bessler Telecommunications Research Center Vienna(ftw) Donau-City Str. 1, A-1220 Vienna, Austria phone: (+43) , fax: (+43) bessler@ftw.at Abstract Multiprotocol label switching (MPLS) has several advantages over destination-based IP routing protocols: it allows to setup end to end paths explicitly (also called label switched paths, LSP), to better monitor the traffic on these LSPs, to perform admission control, etc. While routing along a LSP is considered faster than IP routing, the operation of changing a LSP pipe requires processing and bandwidth resources in the network. This paper investigates cost optimized ways for re-dimensioning existing LSP pipes, to accommodate changing traffic demands. In the presented model the goal is to maximize the amount of carried traffic, while keeping the number of LSP modifications at a minimimum. The presented off-line procedure can be made part of a periodical traffic engineering process. We present a mixed integer LP formulation of this problem, a more efficient heuristic, as well as results on test networks. Keywords: traffic engineering, multi-commodity flows, MPLS, QoS routing, LSP re-optimization, signaling costs, multihour traffic 1 Introduction This paper presents techniques for traffic engineering in QoS- supported IP networks. The approach followed in this paper is based on a centralized optimal routing scheme that, if used in conjunction with the multiprotocol label switching (MPLS) technology, opens the possibility for online admission control and dynamic route assignment. MPLS is an enabling technology for IP networks, with application in traffic engineering. It basically consists of an IP packet forwarding mechanism, a label distribution protocol, control procedures to set-up and tear down Label Switched Paths, and a constraint based routing scheme, especially when path selection methods use other criteria than a metric.[1, 7,, 11, 17] A lot of research work has been done in adapting and reformulating different routing problems in ATM and IP networks in the context of the new MPLS technology. Some approaches used flow optimization algorithms to minimize the maximum link utilization and to reduce in this way congestion [18]. Kodialam and Lakshman [4] solves a series of max-flow problems to find out the critical links in which interference to other paths is likely to occur. The approach followed in this paper is mostly related to the works of Mitra and Ramakrishnan [6] and Suri et al.[2]. The routing problem is equivalent to a linear multicommodity flow problem, for which efficient algorithms exist [19]. Some authors refer to it as the optimal routing, because the obtained solution is a bifurcated multicommodity flow (MCF) that can be reached only by having the knowledge of the whole traffic demands in the network (centralized routing). As observed in [2], splitting an aggregated demand (commodity) on several paths does not imply splitting any individual flow resulted form an online bandwidth request. Moreover, the load sharing capability of MPLS routing is one of the main advantages over OSPF routing (and have lead to a new protocol, OSPF-OMP) [12], so that the requirement for single path routing in some works [20, 18] is imposed only for administrative and simplicity reasons. There are basically two possibilities to achieve a feasible flow-path allocation for any aggregated traffic matrix (we denote also demand matrix): one is to allow variable link capacities leading to a network dimensioning problem. In the studied model, the part of demand exceeding the network capacity is allowed to be lost, without producing earnings. The resulting flows become the bandwidth of the created or modified LSP tunnels and are the basis for admission control of QoS traffic. 1.1 The need for re-optimization A major contribution in this paper is the optimization with the additional goal of minimizing changes to the existing Label Switched Paths (LSP) created in a previous planning step. These changes are associated with signaling costs that reduce the revenues obtained by routing additional traffic into the network. In [9], the authors analyze the traffic streams in a large

2 point of presence (POP). Because of large (15 to 30% ) time of day traffic variations in the studied network, the authors see the need to have a load balancing policy over the time scale of a few hours and reroute mainly large streams (called elephants ). An even larger benefit of the procedure presented here isn t in the time of day traffic variations, that are well understood and for which alternate paths are available, but for the new business models requiring flexible, unanticipated bandwidth provisioning. To our knowledge there are very few works that describe the whole life cycle of traffic engineering activities using MPLS, in the time range of hours to days. Scoglio et al. [3] adapt the MPLS network topology based on the current traffic load. The decision to set-up or tear down LSP is taken dynamically at the arrival of a bandwidth request, and is based on thresholds that depend on IP routing versus LSP signaling costs. Carpenter et al. [18] address the robustness of the flow allocation to the LSP at forecast uncertainty. They describe a procedure for creating new paths and allocating the new traffic again. There are basically two possibility to cope with the bandwidth reserves in the network: either to offer only a part of the link capacity and reserve the rest for non- MPLS traffic, or to scale up the traffic matrix, until it is constrained by the link capacities [20]. It seems that the deployment of MPLS technology to engineer data streams with QoS requirements such as bandwidth, delay, loss probability is still in a beginning stage. One reason for that is the missing of an agreed service management architecture to provide the information for traffic engineering decisions. The Service Level Specification (SLS), studied for example in the Tequila project [15] is the key for the ability to manage bandwidth requests such as the customer wants a 2 MBit/s video connection between 8pm and 11 pm to a certain video server or the customer requests to push daily 2 MBit/s into the network between 8am and 4pm (hose model). In the general case, the customer that subscribes to a service which requires QoS provisioning, delegates to the service provider the negotiation of a service level agreement (SLA) with the network provider. At the network provider, the SLS subscription should trigger the traffic forecasting and network dimensioning update processes. If we refer specifically to the MPLS technology, an offline LSP dimensioning procedure is triggered by the new traffic matrix, and calculates the LSP changes, as shown in Figure 1. In order to enforce these changes, the extended resource reservation protocol RSVP-TE [16] can be used. All the functions needed for the enforcement of the LSP changes resulted from the optimization are supported by RSVP-TE: create a new LSP, destroy a LSP, increase the bandwidth of a LSP, decrease the bandwidth of a LSP. The last two operations are done internally by creating a new path, maintaining the old reservation without double counting, and rerouting smoothly the traffic on the new path. The scheduling functional block shown in Figure 1 is needed to smoothen the signaling load, as the number of changes can be quite large. At service invocation time, a process of traffic aggregation takes place in the ingress routers: packet classification is used to map the packets in forwarding equivalence classes (FEC) The packets related to a SLA are marked accordingly and are forwarded to the appropriate LSP tunnel. If RSVP is used in the access network, the micro-flow requests can be associated to existing aggregated pipes. Planning period Event CB route generation All LSP candidates SLAs Traffic matrix Forecasting Topology LSP Redimensioning Changed scheduler LSP LSPs RSVP_TE LSP Statistics 1.2 Architectural aspects Figure 1: LSP re-configuration architecture 2 Problem Formulation In this section we formulate the multi-commodity flow problem (MCF) in a MPLS-enabled IP network and add constrains related to existing LSP pipes. Consider a network with N nodes and U links with available capacity c u. c u represents in practice the part of the link capacity allocated to MPLS pipes. Another part of the link capacity could carry best effort traffic or IP routed traffic that can be allocated optimally in a subsequent step like it is done in [6]. The commodities are defined by the triple source, destination node and the traffic class (e.g video, VoIP, etc.). It has to be noted that only the edge nodes (called ingress and egress nodes) of the network are traffic sources or sinks, the other core nodes process only transit traffic. The MPLS technology allows to setup explicit routes (ERO) that carry QoS traffic. In the followed approach, a preprocessing step performs the constraint based routing, i.e. selects for each commodity k a number of path alternatives p(k) satisfying QoS requirements, link and node preferences, node disjunction or resilience requirements. p(k) represents the maximal set of paths per commodity, including therefore the existing paths. In case of persist-

3 ing traffic bottlenecks for example, it should be possible to augment the set of paths. A large number of paths will however increase the signaling and scheduling overhead, as well as the bandwidth fragmentation, that is the part of the LSP bandwidth that remains unused because individual bandwidth requests are larger. For the reason of explicit routing, we use the path formulation of the MCF problem [19]. For each j from j = 1, 2..., p(k) let Pj k be the j-th path with P j k(u) = 1 if u Pj k and 0 otherwise. The variables of the problem are the flows x k j that are carried on some of the p(k) paths and sum up to the demand d k. At the end of the procedure, the flows and the corresponding paths lead to the setup of MPLS tunnels of bandwidth x k j. Assuming that each flow unit brings a revenue of e k j, we define the objective to be maximized as the revenues earned by carrying as much as possible of the demands d k [6]. The novel aspect in the formulation of the MCF problem is the additional constraint to express that each new solution has to take into consideration an existing set of tunnels x0 k j calculated in the previous planning step. One cannot simply tear-down the existing tunnels, first because they carry traffic all the time, and second, because of the large amount of signaling traffic created with these changes. Therefore, we introduce into the objective function the penalty c k j of changing the bandwidth of the existing tunnel x0 k j. y k j = { 0 if x k j = x0 k j 1 otherwise The binary variable yj k are set to one, only if the corresponding tunnels xo k j have to be re-dimensioned, or a new tunnel corresponding to another path j has to be created. (1) is a non-linear constraint as encountered in problems with fixed costs [13]. Standard solvers like CPLEX [14] have difficulties with such nonlinear constraints. With some tricks we obtain the following inequalities equivalent of (1), which require two binary variables yj k and zj k: (1) x0 k j (1 z k j ) + y k j x k j (y k j z k j )M + x0 k j, j = 1,..., p(k), k K (2) where M is a large constant. We can easily check that if x k j = x0k j then yk j = 0, otherwise yk j is one. The problem REOPT can now be formulated as follows: max p(k) K e k j x k j c k j yj k (3) k=1 j=1 subject to : p(k) K Pj k (u)x k j c u, u U (4) k=1 j=1 p(k) x k j d k, k = 1,...K (5) j=1 x k j 0, j = 1,..., p(k), k = 1,..., K (6) x0 k j (1 z k j ) + y k j x k j (y k j z k j )M + x0 k j, j = 1,..., p(k), k K (7) The unity costs c k j may depend on the individual path, being proportional for example to the number of router nodes on the path. For simplicity reasons, we assume that the costs for both creation and re-dimensioning of an LSP are equal. The inequalities (4) state that the flow on each link should not exceed the reserved link capacity c u. There are U capacity constraints. The inequalities (5) express the admission constraints: the calculated flows sum up in the best case to the traffic demand d k. The slack represents the lost traffic, i.e. the part of the demand traffic that is rejected. 2.1 Numerical results We started the experiments with the small network topology showed in the figure and used in [3] Figure 2: Example network topology Two explicit paths for each of the eight commodities 1-7, 1-8, 1-, 2-7, 2-9, 2-, 1-9 and 2-8 have been (manually) preselected, however this process can be done automatically in practice. The selected routes are intended to be a constant superset, as long as the topology remains

4 Commodity d k x k 1, x k , , , , , , , , 25 Total Table 1: Demands, initial flow distribution c k j Net earnings Changes Lost Mbs Table 2: 25% demand variation, impact of unit change costs unchanged. We consider a single QoS traffic class, although several QoS traffic classes do not have any impact on the model, they affect only the assignment of path candidates to commodities. The link capacities have been set to 0 in order to create a moderately loaded network. A first run creates a flow distribution x, that is set to x0. In a first experiment with the test network, we simulated a traffic shift situation by increasing the traffic form node 1 to the other commodities by about 25% and decreasing the traffic from node 2 also by 25%. This is in conformance with the observation in [9] that large streams display large variations during the day and that a load balancing strategy has to be achieved to reroute mainly the few large traffic flows ( elephants ). In Table 2 we show the impact of changing the relationship between revenue and change costs on the solution. With e k j constant end equal to 1.9, the amount of lost traffic increases when changes become expensive. As expected, the net earnings decrease, the amount of changes decreases with making them expensive. The initial flow allocated on the link 1-4 has contributions from demands on the commodities 1-7, 1-8, 2-7, 2-8 so that the residual capacity on the link 1-4 is zero. Some of the demands (on commodities 1-7, 1-8) increased, the other (2-7, 2-8) decreased. After the optimization run with c k j = 20 and 25% demand variation, the residual capacity of link 1-4 changes to 20.5, because of rerouting of some commodities on other LSPs. In Table 3 the calculated flows for c k j = 20 are shown. The behavior of the procedure is as expected, it redistributes the traffic on other paths, but does it with minimal changes. We can even improve the solution by reducing the number of changes indicated in the variable y, if we Commodity d k x k 1, x k , 32.5* , , , 27.5* , 17* 2-20 *, , , 17* Total Table 3: Solution for c k j = 20. Changed LSPs are marked with * make the following observation: the current model always requires to change the LSP bandwidth if the new demand is lower than the old demand! During the search this is needed to allow the eventual size increase of another LSP. However, once the final solution is found, for those decreasing demands d k we could set the total flow to the old value x0, in case the link capacity constraints on that path are fulfilled. With other words, when a traffic demand decreases, we reduce the size of the corresponding tunnels, only in case that bandwidth is needed elsewhere. This lazy assignment, shown in the pseudo-code below, will keep LSP sizes according to a peak traffic value if the residual path capacity res is large enough. However as soon as some higher traffic demands have to be accommodated, the oversized tunnels are changed to the actual needs. In order to illustrate the behavior above, we have run the optimization procedure repeatedly, changing the demands randomly between 50% and 150%. After each iteration, we apply the lazy assignment procedure : do for all 1 j p(k), 1 k K such that x k j < x0k j res min u/p k j (u)=1(c u K p(i) i=1 l=1 P l i(u)xi l ) if res x0 k j xk j then x k j x0k j & y k j 0 end The results for the commodity 1-7 during reoptimization periods are shown in Figure 3. We can observe that the total flow follows the demand until the fourth planning period. After that, the decrease in demand and the existing residual capacity allow to maintain a higher reserved bandwidth (denoted here with the total flow) according to out lazy changes. Comparing the demand and total flow for the commodity 1-8 for example, we can see in Figure 4 both the case of high demand that is too costly to carry (lost traffic) and the case of an over-dimensioned tunnel that is too costly to change when the demand decreases.

5 demand total flow LSP LSP lost (y) Lost (y Table 4: Comparison between linear relaxation (left) and integer solution (right) (Core NSF network [6]). Figure 3: Demand and flow variation of commodity demand total flow L/O (y) Lost (y Table 5: Impact of the lazy dimensioning (left) on the number of LSP, admitted and lost traffic. (Core NSF network [6]) Figure 4: Demand and flow variation of commodity A LP relaxation heuristic In the link-path flow formulation used above, the number of variables and constraints depends on the number of links U, commodities K and preselected path alternatives p(k). As an example, for a network with ingress and egress nodes, and 3 QoS traffic classes, we obtain K=300 commodities (full traffic matrix). If 3 paths are preselected for each commodity we have: 900 x k j variables, 1800 binary variables and more than 2000 constraints. The binary constraints make the problem intractable for large instances. Therefore, we compared the problem REOPT with the following heuristic based on a linear relaxation. We remove the integrability constraints and solve the LP problem. In a subsequent step, we analyze the obtained LP solution for each commodity. Let us define the net profit for an increasing flow by (x k j x0k j )ek j ck j. If this expression is negative, the change is not worth to be done, therefore we set yj k = 0 and x k j = x0k j Otherwise, we perform the change setting yj k = 1. For decreasing flows, we apply the lazy assignment procedure. We compared the integer and the relaxed solutions on the network example Core NSF used in [6]. The network has 8 nodes, 20 links, 64 commodities and one traffic class. For most commodities we can choose between 2 routes. To create test instances, we started with one demand matrix and one initial solution x0, then changed the demand matrix randomly to values between 50% to 150% and the initial solution between 75% to 125% and repeated the experiment times with both algorithms, using the CPLEX solver. Table 4 shows the number of changes, the total flow admitted and the lost bandwidth for both algorithms. The exact (integer) procedure produces on the average 7,9% less LSPs changes and 2,8% less lost traffic than the heuristic. Also for this network example, if we apply the lazy dimensioning scheme during periods to LSP reconfiguration, the number of changed tunnels is drastically reduced from an average of 24 to an average of (Table 5). Note that, when the difference between total demand and admitted traffic becomes negative, we have instead of a lost traffic - a number of over-dimensioned tunnels.

6 3 Conclusions and future work We have presented a multi-commodity flow formulation for the problem of periodical re-optimization of QoS flows taking into consideration existing LSP tunnels. The model uses explicit routes resulting in a link-path formulation. This approach allows to build an off-line traffic engineering system that creates optimized transitions from one LSP configuration to the next one. The resulting number of LSP changes is dependent on signaling costs parameters. A lazy tunnel dimensioning scheme allows the LSP tunnels to adapt gradually to real traffic increases, but keep the bandwidth unchanged in case of periodical traffic oscillations. Future research will focus on the scheduling of LSP changes into the network in order to limit the signaling traffic load. Finally, the algorithms discussed above will be integrated into a closed loop traffic engineering system, that considers service level agreements, novel methods for traffic forecasting. Acknowledgments This work has been done at ftw, the Telecommunications Research Center Vienna, within the project Performance Management over wired Networks: End to End Architecture and Realization, a project funded by the Austrian government. References [1] X.Xiao, A. Hannan, B. Bailey, LM Ni, Traffic Engineering with MPLS in Internet, IEEE Network, March April 2000 [2] S. Suri, M. Waldvogel, PR Warkhede, Profile based routing: A new framework for MPLS traffic engineering,proceedings of QofIS 2001 [3] C. Scoglio, JC de Oliveira, IF Akyldiz, G. Uhl, A new Threshold-based policy for label switching path (LSP) setup in MPLS networks,, in Proceedings ITC17, 2001 Brazil [4] M. Kodialam, T.V. Lakshman, Minimum interference routing with applications to MPLS Traffic Engineering,INFOCOM [5] Quality of Service Based routing: Apostopoloulos G, R.Guerin, S.Kamat, S.K.Triphati, A Performance Perspective,In Proceedings of SIGCOMM, pages 1728, Vancouver, Ontario, CANADA, September [6] D. Mitra, KG Ramakrishnan, Techniques for Traffic Engineering of Multiservice, Multipriority Networks, BLTJ Vol. 6 No.1, 2001 [7] IETF Draft, jrex/jerry/annex6- tewg-qos-routing-03.txt.pdf [8] Grenville Armitage, MPLS: The magic behind the myths IEEE Comm. Mag. Jan 2000 [9] S. Bhattacharyya, C. Diot J. Jetcheva, N. Taft, Pop-Level and Access-Link-Level Traffic Dynamics in a Tier-1 POP, Technical Report TR01-ATL , Sprint Labs, February Available at [] A Framework for Internet Traffic Engineering, draft-ietf-tewg-framework-05.txt [11] G.Ash, Traffic Engineering and QoS Methods for IP-, ATM-, and TDM-Based Multiservice Networks, draft-ietf-tewg-qos-routing-01.txt [12] C. Villamizar, MPLS Optimized Multipath, [13] C.H: Papadimitriou, K. Steiglitz, Combinatorial Optimization: Algorithms and Complexity, Prentice Hall, [14] CPLEX Solver, [15] Tequila Project, Deliverable D1.1 - Functional architecture definition and top level design [16] D. Awduche et al., RFC RSVP-TE: Extensions to RSVP for LSP Tunnels [17] Bruce Davie, Yakov Rekhter, MPLS - technolgy and Applications, Academic Press 2000 [18] T. Carpenter, K.R Krishnan, D. Shallcross, Enhancements to Traffic Engineering for Multiprotocol Switching, ITC17, Brazil [19] Gondran, M. Minoux, Graphs and Algorithms, 1984 [20] G. Hasslinger, S. Schnitter, Algorithms for traffic engineering, INFORMS 2002