* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Multi-layer Traffic Engineering in Data-centric Optical
Survey
Document related concepts
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Computer network wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Distributed firewall wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Deep packet inspection wikipedia , lookup
Airborne Networking wikipedia , lookup
Passive optical network wikipedia , lookup
Transcript
Multi-layer Traffic Engineering in Data-centric Optical Networks Illustration of concepts and benefits Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck, Ilse Lievens, Mario Pickavet, Piet Demeester Ghent University – IMEC, Department of Information Technology Abstract: Intelligent Optical Networks (IONs) allow setting up or tearing down lightpaths dynamically. The logical topology in multi-layer networks (such as IP-over-OTN scenarios) is supported by these lightpaths, and thus dynamically configurable. Consequently, traffic engineering functionality is extended with cross-layer capabilities, leading to multi-layer traffic engineering (MTE). This paper explains the concepts behind MTE, how typical MTE strategies function and what issues arise while developing such strategies. The benefits are illustrated by means of the results from two case studies. Key words: Multi-layer TE, Dynamic Grooming, GMPLS, ASON, ION 1. INTRODUCTION The ever-increasing bandwidth demand in data networks poses a serious challenge in the area of broadband networking. Also, traffic patterns are rapidly evolving, caused by, for example, the rising popularity of new applications such as peer to peer networking and real-time multimedia over IP. New advances in optical networking technology such as Dense Wavelength Division Multiplexing (DWDM) and Optical Cross-Connects (OXCs) will bring both an increase in available bandwidth and an increase in switching flexibility in Optical Transport Networks (OTNs). Properly configuring the OXCs allows concatenating individual wavelength channels on consecutive fibers into an end-to-end lightpath. A lightpath has a capacity of 2.5 or 10 Gbps, as this is what single wavelength channels typically offer. 1 2 Multilayer Traffic Engineering in Data-centric Optical Networks As manual intervention by the network operator is currently needed for provisioning a lightpath, this can take up to a couple of weeks or even months. The high dynamism of traffic patterns however will require that OTNs react within a sufficiently short time frame. As such, research is currently focussing on the development of Intelligent Optical Networks (IONs) – which are standardized by the ITU as Automatic Switched Optical Networks (ASONs) [1]. For example, in an IP-over-OTN scenario, these lightpaths are used to create links in the logical IP network topology, which is however completely independent of the physical optical topology. An automatic circuit-switched optical network allows bypassing the manual intervention, and setting up and tearing down lightpaths dynamically using User Network Interface signaling, as standardized by the OIF [2]. This way provisioning times can be reduced considerably to minutes or seconds. Implementing this fast-responding ION functionality will allow the logical IP network topology to be reconfigured dynamically according to the traffic pattern at hand. Direct links can be created or removed in the logical IP topology, when either extra capacity is needed, or existing capacity is no longer required. Reconfiguring the logical topology constitutes a new manner by which Traffic Engineering (TE) can solve or avoid network congestion problems and service degradations. As both IP and optical network layers are involved, this is called Multi-layer Traffic Engineering (MTE). In this paper, the following data-centric optical network scenario is considered. The client layer is a Multi Protocol Label Switching (MPLS) capable IP network: MPLS decouples routing and forwarding, and hereby enhances TE flexibility. The server layer, an optical network, is controlled by an MPLS-like protocol: the IETF Generalized MPLS (GMPLS) protocol [3], which is inspired on the idea that the wavelength of an optical channel can also be considered a label. Note that GMPLS allows integrating the control plane of both client MPLS and server optical layer. The goal of this paper is to show how Multi-layer TE can be realized. In section 2 some operational aspects and issues of MTE and also its interaction with existing TE mechanisms are discussed. A classification of MTE strategies is made in section 3. Finally in section 4 we illustrate the benefits of MTE with two case studies. 2. MULTI-LAYER TRAFFIC ENGINEERING In regular TE, problems, such as typically congestion, are solved by rerouting traffic flows over the logical topology. Multi-layer traffic engineering provides a valuable alternative to this, by reconfiguring the Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck 3 logical network topology as required. Sometimes this form of traffic engineering is also called dynamic grooming [4]. In this section, we will show how MTE strategies work, what issues arise and how they interact with existing types of traffic engineering. 2.1 Decision phases in MTE One can identify three phases in MTE decisions, each of them will be discussed in this section. The decision taking process is of course the most crucial, this is explained in subsection 2.1.2. This process is however triggered by the detection of problems while measuring the load on the network, see subsection 2.1.1. Once a decision has been taken, it is necessary to act accordingly, as discussed in subsection 2.1.3. 2.1.1 Detecting problems and triggering MTE Monitoring the traffic load in the network will allow triggering reconfiguration of the logical topology. How to actually monitor traffic loads in links and routers is out of the scope of this paper, although some issues have to be considered when physically measuring the actual consumed bitrate on each link [5]. An alternative could be to rely on the bandwidth specifications provided in the signaling messages of, for example, the Resource reSerVation Protocol – Traffic Engineering extensions (RSVPTE), used to set up and tear down Label Switched Paths (LSPs) through the logical IP-MPLS network. In Figure 1, part 1, a logical IP-MPLS topology is shown, with loads on the links indicated as percentages of the bandwidth of lightpaths, since the IP-MPLS link connections are supported by lightpaths in the optical layer. An additional traffic flow a-f-c-d of 40% causes higher loads on some links. As the resulting traffic of 180% (at router f) is balanced over both links (lightpaths) between f and c, router f detects a traffic load on two of its outgoing links of 90%, considers this a congestion and takes the initiative. This is an example of a reactive strategy, where MTE actions react on, or are triggered by the detection of problems. The proactive approach however, tries to keep the network optimal at all times, triggering a reconfiguration whenever optimizations are possible. Note that finding improvements of the logical topology still requires sufficient knowledge gathered from monitoring. The advantage of the proactive approach is that it avoids unfavorable network conditions, while the reactive approach only reacts when (and thus after) such conditions are detected. On the other hand, due to the continuous reconfiguration of the logical topology, and subsequent 4 Multilayer Traffic Engineering in Data-centric Optical Networks rerouting of some traffic flows, a proactive strategy may cause a temporary impact on the Quality of Service (QoS) of these affected traffic flows. 2.1.2 Deciding what to reconfigure Once a problem has been detected, appropriate decisions will lead to a better configuration of the logical topology, for example resulting in the selection of a new link to be set up. Furthermore, a decision must also be made about how and which traffic flows to attract over newly established links, as seen on part 2 of Figure 1. Here one tries to optimize the loads on both candidate link (due to the attracted traffic flows) and the load of the congested link (which will be lowered by deviating traffic). In fact, the selection of a particular candidate link, will in part depend on the amount of traffic that can be attracted over this link. More accurate decisions can be taken if more information is available, e.g. when monitoring the route and traffic specifications per traffic flow instead of just monitoring the average bandwidth occupied per IP link. In subsection 2.2 we discuss some further issues besides capacity efficiency that have to be solved when designing a proper MTE strategy. In this case, the final decision is to set up a new IPMPLS link connection between routers a and d, offloading some of the traffic on the congested f-c link. Again note that in this example, this decision is initiated by router f. 2.1.3 Performing the MTE actions Once the decision has been taken, the new configuration of the logical topology should be realized. As the example in part 3 of Figure 1 requires a new link connection (supported by a lightpath) to be set up between routers a and d, the decision taking router f sends a suggestion signal to one or both in order to inform them that they should start negotiating on setting up a direct logical link. This means a lightpath has to be requested in the optical layer, between these two routers. Several practical solutions exist for this purpose. Through the OIF User-Network Interface (UNI) [2], the routers can signal into the ION to request a lightpath. In GMPLS, typically a single integrated control plane controls both IP-MPLS and optical layers. Also, RSVP-TE is used as signaling protocol to establish lightpaths. Once the logical link has been established, it should be advertised to all routers in the network and traffic should be attracted over this link. Setting the routing weight smaller than the length of the shortest path between the endpoints of the new link before it was established, can be used to attract this traffic automatically. However, MPLS requires explicitly setting up an LSP over this link to attract traffic, since routing and forwarding are decoupled in MPLS. Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck Initial situation 0% 14 60 % % 70 % 30 f e 70% a TE initiative taken by router detecting congestion IP-MPLS IP-MPLS c d 60 % 16 d 70% % % a b 60 20 Additional traffic flow a-f-c-d of 40% 0% c 0% b IP flow routed by IP-MPLS layer STE 18 70% 0% Detection 16 1 5 f e 70% Congestion Decision • Lower load on congested link f-c c 14 40% a f d e • Optimize attracted traffic on candidate link ⇒ MTE decision Perform decision c 70% 60 % d f 70% Confirm B D C A E Optical e IP-MPLS C A F 0% e Request B 40% a 60 % f 14 0% d IP-MPLS c % 30 % 70 Su gg es t Confirm 18 Request 70% % 20 % 60 a b 0% 70% 0% b 16 3 • Find suitable candidate link (a-d) 0% b 16 2 D F E Optical Lightpath routed by Optical STE Provisioning of candidate link needs signaling. Once set up, attract traffic. a IP-MPLS capable router Logical IP-MPLS link connection, supported by a lightpath A Optical Cross-Connect Optical fiber Lightpath Figure 1. Phases in MTE decisions 6 2.2 Multilayer Traffic Engineering in Data-centric Optical Networks Further issues in MTE Besides capacity efficiency, by which MTE provides an alternative for overprovisioning, some other issues are of importance when designing a proper MTE strategy, some of these conflict with each other, so a trade-off has to be made. As reconfigurations of the logical topology are performed dynamically (i.e., while the network is in full service), each reconfiguration may lead to short service interruptions. Although optimality may require a great number of reconfigurations, this number has to be somewhat limited, so that service interruptions do not occur too often. In the case of a rather stable traffic pattern, the logical topology should be kept stable, and not reconfigured any longer. I.e., one should avoid that short traffic bursts trigger the MTE decision taking process, or that small reconfigurations themselves trigger other reconfigurations (e.g. because a small congestion problem is moved from one region of the network to another). One way to assure this, is to introduce a certain amount of inertia [6] in the MTE decision taking. This inertia leads to significantly less reconfigurations, at the cost of a slightly suboptimal logical topology. Inertia does not imply the usage of more physical resources. In [7] we have investigated total network cost in case router failures are solved by reconfigurations of the logical network. Simply rerouting traffic on the existing logical topology and up- or down-grading capacity of existing links turned out cheaper than optimizing for each failure condition. Another important issue is that a cumulative memory effect has to be avoided. Optimality of the logical topology should not deteriorate over time. For example, in case of a repetitive traffic pattern, the resource usage should remain about the same after several repetitions. Again, inertia does not imply a degradation of the quality of the network over time, although it does imply a slightly suboptimal logical topology at each moment in time. 2.3 Interaction with Single-layer Traffic Engineering Besides multi-layer TE, both IP-MPLS and optical layers still need some form of regular traffic engineering, called Single-layer Traffic Engineering (STE). In the IP-MPLS network, it controls the (re)routing of traffic flows over the existing logical topology, while in the optical layer this determines how lightpaths are routed over the optical layer. For example, in Figure 1 part 1, the STE routing of the additional traffic flows eventually leads to congestion in router f, requiring a reconfiguration of the logical topology. Equally, one has to keep the IP-MPLS STE in mind Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck 7 while deciding what MTE actions to perform, as precisely this STE is responsible for attracting traffic to newly set up IP-MPLS link connections. Also, in part 3 of the same figure, optical STE routes the new lightpath so that fibers with heavier wavelength usage (e.g. f-c), are avoided. Again, MTE decisions will in part depend on the situation in the optical layer. For instance, if the bandwidth in the optical layer reaches saturation, IP-MPLS or even optical rerouting will become more desirable than setting up even more lightpaths (a course of action which may limit severely the number of available future MTE actions). 3. CLASSIFICATION OF MULTI-LAYER TRAFFIC ENGINEERING STRATEGIES A number of different types of MTE strategies exist, they can be characterized, or classified in several ways, as depicted in Figure 2. Architecture Objective • Online ↔ offline • Resource ↔ QoS ↔ … • Centralized ↔ distributed • Keep network optimal ↔ fix problems • Overlay ↔ peer (integrated) Decision strategy Multi-layer Survivability • Number of possible alternatives • Static ↔ dynamic provisioning of • Interaction with STE decisions/actions spare capacity in logical network • Granularity: per flow ↔ per pair Figure 2. Classification of MTE strategies First of all, the architecture of the multi-layer network scenario heavily influences the performance and capabilities of the MTE strategy. For example, running the decision taking process offline will limit the strategy to longer-term variations in the traffic pattern. While a distributed approach typically offers more flexibility and scalability, much effort goes into coordinating MTE actions of individual nodes. Finally, a network based on a peer model (also called integrated model), offers a complete overview of the network. This leads to better MTE decisions compared to the case of an overlay model, where control over individual network layers is separated. 8 Multilayer Traffic Engineering in Data-centric Optical Networks Secondly, MTE strategy objectives can vary also. Some strategies are mainly aimed at capacity efficiency, while others try to maximize the QoS. In the former case, QoS will be of less importance and thus this may result in flows being operated at their limit. The difference between proactive and reactive strategies, as discussed in subsection 2.1.1, is an objective-based classification parameter. Proactive strategies have as objective continually keeping the network optimal, while reactive ones only fix problems. Next, there are several aspects concerning the decision strategy. The number of considered alternatives has a great effect on the optimality of the resulting logical topology. A trade-off has to be made though between optimality and calculating time. One way to reduce this number is to only consider local or incremental network reconfigurations. Also the interaction with STE processes is very important. Although up till now we have assumed that STE processes react passively to MTE actions, it may be more rewarding to consider both STE and MTE actions on the same level. Finally, the capabilities of the strategy are influenced by the granularity by which grooming decisions are made [8]. With a per-flow granularity, each flow can have a different path through the network, whereas with per-pair granularity, all flows between the same source and destination follow the same path. Finally, providing survivability is an important aspect of TE [7]. With a multi-layer survivability strategy, either spare protection capacity can be provided statically (in advance), or survivability can be handled dynamically (on-demand). For example, if survivability is not handled separately (e.g. having higher priority), the overall MTE process in the latter case should be able to face abrupt changes in network status (such as faults) and react fast accordingly. 4. CASE STUDIES Some of the issues in multi-layer TE discussed this far, will be illustrated with two case studies. 4.1 Case study 1: benefits of MTE – applying a reactive strategy This first case study will confirm the benefits of multi-layer TE. A reactive strategy is proposed, depicted in Figure 3. Two threshold values Thigh and Tlow respectively indicating over- and underloaded links trigger the decision taking process. Several candidate links are evaluated using a fitness function. This function achieves increased stability, by trying to bring the load on both the current congested link and the candidate link to a certain Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck 9 value Tmid, in the middle between the high and low thresholds. Also, a maximum amount of traffic T is attracted, to reduce as much as possible the load on routers along the current shortest path between the end-points of the candidate link (note that shortest path routing is used in the IP layer). The candidate link leading to the lowest fitness value is selected and set up. Detect congested or underloaded link, with traffic Tcong Tcong > Thigh (overloaded link) Tcong < Tlow (underloaded link) Tear down link Choose fittest link For each candidate link: • calculate T (amount of attracted traffic) • evaluate Fitness function: 2 Try to achieve that afterwards both currently congested link and new link end up with a load close to Tmid (T cong −Tmid ) + Tmid 2 T − 2 = (T − Tcong / 2) Fitness (T , # Hops) = T (# Hops − 1) T (# Hops − 1) Try to reduce the load on the routers as much as possible • keep track of candidate link with lowest fitness value as solution Set up link & attract traffic Figure 3. Concept of the proposed reactive MTE strategy A realistic IP-over-optical network scenario is used as starting point. This network has been dimensioned for a specific traffic forecast. However, we let traffic load rise from 80% to 160% (of the forecast), in 20% increments every 30 seconds, and examine how the network reacts. This case study compares two cases: a first, static case (i.e. thin lines in Figure 4), in which for each physical optical fiber a logical IP-MPLS link is foreseen; the optical layer (and thus also the IP-MPLS layer) is dimensioned for 100% traffic load. The second, dynamic case (thick lines) is based on the MTE strategy in Figure 3. Note that the terms ‘average’ and ‘total’ in Figure 4 mean that respectively the average and sum is taken over the whole network – over all links or routers. 10 Multilayer Traffic Engineering in Data-centric Optical Networks Figure 4 shows average packet loss ratio (PLR) and number of used wavelength channels for both static and dynamic case. Since the logical topology remains unchanged from its initial configurations in the static case, the number of used wavelengths remains the same. The load on the network reaches 120% on second 60, and keeps rising afterwards. As expected, QoS degrades in the static case; this is visible in the rising PLR. Also, PLR in the static case remains relatively stable during a period with equal traffic load. The coarse granularity of the lightpaths leads to poor average IP-MPLS link filling, which explains why a load of 160% only results in a PLR of approximately 10%. # wavelength channels: dynamic PLR: dynamic # wavelength channels: static PLR: static 0,25 250 # channels: dynamic 200 175 0,20 # channels: static 0,15 150 125 PLR: static 100 0,10 75 0,05 50 25 Average packet loss ratio Total # wavelength channels 225 PLR: dynamic 0 0 30 60 90 120 0,00 150 Time (sec) Figure 4. Packet loss ratio (PLR) versus number of used wavelength channels However, PLR can be kept fairly constant in the dynamic case. At each increment of the traffic loads, additional lightpaths are set up. During these reconfigurations, PLR peaks for a short moment. The PLR however never reaches values as high as in the static case, except at the very beginning. Contrary to the static case, the dynamic case has no initial dimensioning of the network, so much more reconfigurations are needed there, although these are needed only once, and not at a time the network is in full service. We can conclude that a MTE strategy (dynamic case) only occupies physical resources when really needed and reduces stress on the routers (constant low PLR). Of course, dimensioning in the static case is typically more optimal, as can be seen in the time interval between 30 and 60 sec, where the logical topology for a load of 100% proposed by the MTE strategy uses slightly more channels than the statically dimensioned topology. Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck 4.2 11 Case study 2: designing a proactive strategy The aim of the previous case study was mainly to illustrate the benefits of deploying MTE. The case study in this subsection is more concerned with the design of a MTE strategy. More precisely, as framework we have chosen the proactive MTE strategy depicted in Figure 5 and the aim of this case study is to design the cost function applied in this MTE strategy. Consider full-mesh: for each link • derive cost depending on its current load • non-existing links: can be assigned a high penalty cost 70 High for heavy loads 60 High for light loads Cost 50 40 Interesting for ‘average’ loads 30 20 10 0 0 20 40 60 80 100 Load (%) Route traffic along shortest (i.e. cheapest) path • If needed, set up not yet existing links • Tear down unused links Figure 5. The concept of the proposed proactive MTE strategy This proactive MTE strategy tries to optimize continuously the routing in the logical IP network. Whereas in the previous case study, optimizations were clearly triggered by certain events, here the logical topology is adjusted whenever a better route is found for some traffic flow. For this purpose, all traffic is routed over a fictive full-mesh, along a shortest path. The ‘cost’ however to use a link depends on the utilization or load of that link. Note that during the routing of a certain flow, the load of this flow will be taken into account when assigning costs to links. Otherwise, if the traffic flow would carry a significant percentage of the bandwidth of a full IP-MPLS link, rerouting might in fact lead to less optimal situations, and thus to instability. This means costs have to be calculated again for every flow routed. Next, the logical network is reconfigured according to this route calculation – as the route for some traffic flows may have changed. Links utilized in the fictive full-mesh, but not yet physically available (as lightpaths), will have to be set up before traffic flows can actually be 12 Multilayer Traffic Engineering in Data-centric Optical Networks rerouted over them. Also, the rerouting may cause some existing links in the logical network to be no longer used by any traffic flows, these will need to be torn down, freeing the occupied capacity in the optical layer. As an illustration of the suitability of the MTE strategy depicted in Figure 5, its behavior when applying the designed cost function is shown in Figure 6. Important phenomena: • 40 sec: Logical network suddenly underloaded • 60-90 sec: Gradual optimization of logical network • 90 sec: Logical network suddenly overloaded 70 60 a number 50 # used IP-links # rerouted connections 40 30 20 10 0 0 10 20 30 40 50 Time (sec) 140 60 80 90 100 80 100 c Max. load Avg. load Min. load 120 Load (%) 70 b a 60 40 20 0 0 10 20 30 40 50 Time (sec) 60 70 80 90 100 Figure 6. Performance study of the proposed MTE strategy The upper part of the figure shows the number of used IP links (i.e. lightpaths) and number of rerouted connections per second (i.e. traffic flows for which the route calculation yields a changed route). The lower part shows link utilizations in the network (maximal, minimal and average load of links, in percentage of a lightpath). In this simulation the traffic pattern changes substantially every 10 seconds. The MTE strategy adapts the logical network to suit the new traffic pattern. However, a sudden decrease of the traffic volume results in lower link fillings (see a, sec. 40 to 50), which is solved by rerouting traffic flows (connections) and removing superfluous links. In the case of minor changes between consecutive traffic patterns (see b, sec. 60 to 90), the logical Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck 13 network is gradually optimized. But, the more specialized for one traffic pattern, the harder it becomes to cope with another traffic pattern (see c, for a very abrupt change of the traffic pattern). Note that the latter phenomenon is a confirmation of the importance to introduce some inertia in the MTE strategy, especially here, as reconfigurations can occur continually, and are not triggered by certain events. This inertia is achieved by penalizing, with a higher cost, links in the fictive full-mesh that are not physically set up – thus reducing the number of lightpath operations. This leads to faster stabilization of the logical topology, and also of the STE IP-MPLS routing (using the cost function). The inertia makes sure that gradual specialization of the network only occurs when consecutive traffic patterns vary only slightly (i.e., when abrupt changes are less probable). As mentioned above, the goal of this case study is to design a proper cost function. It is trivial that this cost function should result in a high cost to use overloaded links. If this cost is high enough, it will also make sure traffic flows are deviated away from overloaded links. Also, lightly loaded links should be penalized with a high cost, in order to avoid the establishment of many and thus inefficiently used links. In other words, it is our intention to reach a network with moderately loaded links. A first intuitive idea could be that a parabolic cost function would realize this. However, Figure 7 illustrates that a ‘plateau’ for light link loads in the proposed cost function is needed to trap the load or utilization of the links in a range around a moderate load. As can be seen, the simple parabolic function is not able to meet this constraint when the traffic volume grows. Indeed, flows are only multiplexed when the involved links can reach the optimal load (i.e., small cost). However, growing flow sizes prevent this. As we are using a shortest path algorithm, shorter paths (over non-optimally loaded links, as optimal loads cannot be achieved) will then be preferred over longer paths, resulting in a higher meshing (many direct links). Broadening the range of optimal loads, while making sure that cost for links with loads below a certain value (Light Load threshold) is still high, leads to the cost function shown at the right of Figure 7. Note that the cost does not have to fall steeply for loads below this value (as is the case with a parabolic function). Since links with any load between 0% and this Light Load threshold will typically only carry one traffic flow (i.e. a direct link for a single traffic flow), routing traffic flows over such links should be avoided – regardless of the actual load of the traffic flow. Part a of Figure 8 shows that the height of this plateau for light loads should be sufficiently high compared to the values for the ideal load range. In order to guarantee that the link loads are trapped in this ideal load range, the cost value for the ideal load range has to be at least n times lower than the height of the plateau, where n is the typical number of hops taken by 14 Multilayer Traffic Engineering in Data-centric Optical Networks multiplexed traffic flows. Otherwise direct links would be preferred over multi-hop paths, and a similar phenomenon would occur as discussed for a simple parabolic function. Histogram: number of links per specified utilization range b Proposed function Traffic: 100% 20 100 80 60 10 40 15 20 40 60 80 30 20 10 0 0 0 40 5 20 0 0 0 100 20 20 40 60 20 100 40 5 20 40 60 80 30 20 5 10 0 0 0 40 10 20 0 0 0 100 20 Traffic: 200% 40 60 5 20 0 0 0 20 40 60 80 100 50 # links 40 60 cost 15 Cost # links 60 10 70 # links 80 cost 100 Traffic: 300% 20 100 # links 15 80 Load (%) Load (%) 20 50 # links 10 60 cost 15 Cost # links 60 70 # links 80 cost 100 Traffic: 200% # links 15 80 Load (%) Load (%) Traffic: 150% 50 10 Cost 5 60 cost # links # links 15 Cost cost 70 # links # links 40 10 30 Cost Traffic: 100% 20 Cost a Parabolic function 20 5 10 0 0 0 20 Load (%) 40 60 80 100 Load (%) Figure 7. The shape of the cost function The establishment of direct links happens whenever a single traffic flow has a large enough bandwidth so that a link carrying only this flow, is considered more optimal than routing the flow along existing links (carrying some traffic). Of course, this means that direct links will typically be established for high bandwidth flows. This greatly helps reduce the load on routers, as transit traffic then consists largely of low bandwidth flows. At the other side, part b of the figure shows that the gap between this plateau and the slope for high loads also should be wide enough in order to Bart Puype, Qiang Yan, Didier Colle, Sophie De Maesschalck 15 trap the link loads in the ideal load range. Otherwise, when this gap would be too tight, there would simply be no room enough to come to a solution that contains links with a load in this range. In this case, a Light Load threshold at 20% load and an increase in cost for loads higher than 80% (to minimize packet loss) was found to be optimal. 40 30 20 10 0 0 0 20 20 20 40 60 Load (%) 80 10 20 0 15 80 20 # links cost 15 20 10 0 0 80 50 100 40 30 20 0 20 40 60 Load (%) 80 100 70 # links cost 15 # links 5 60 60 20 30 Load (%) 70 # links cost 10 60 40 40 100 10 0 0 50 20 80 5 70 10 0 40 60 Load (%) 100 # links 0 50 10 5 30 5 60 60 50 40 10 30 Cost 40 Cost 50 0 # links with this load 15 60 10 # links cost Cost 70 # links 15 70 20 80 # links cost Cost # links with this load 20 b Light Load threshold (= width of plateau) Cost a Height of plateau (compared to height for ideal load 20 5 10 0 0 0 20 40 60 Load (%) 80 100 Figure 8. The plateau for light link loads 5. CONCLUSIONS The concept of multi-layer traffic engineering (MTE) has been introduced and discussed. Section 2 explained the operational aspects and issues of such MTE schemes, while section 3 dealt with the classification of MTE strategies. The main conclusion is that the hardest issue in implementing MTE is the strategy or the intelligence to be foreseen in the network. 16 Multilayer Traffic Engineering in Data-centric Optical Networks The case study presented in subsection 4.1 illustrated the importance of MTE in data-centric optical networks. The considered MTE strategy was able to reconfigure the logical network in such a way that the packet loss ratio could be kept insignificantly low (by avoiding significant overloads of the logical IP-MPLS links), while reducing the load in the IP-MPLS routers and occupying physical resources only when really necessary. The case study presented in subsection 4.2 designed (as basis for a proactive MTE strategy) a cost function depending on the link loads to route the traffic in the logical IP network. The conclusion is that this cost function should incorporate a sufficiently high ‘plateau’ for light link loads, in comparison with the cost in the ideal load range. The gap between this plateau for light loads and the slope for high loads corresponds to the acceptable link load range and should be wide enough to allow solutions that have all link loads in this region. 6. ACKNOWLEDGEMENTS Part of this work has been supported by the European Commission through the IST-project LION, and by the Flemish Government through the IWT GBOU project Optical Networking and Node Architectures. 7. REFERENCES [1] ITU-T Rec. G.8080, “Architecture for the automatically switched optical network (ASON)”, November 2001 [2] OIF2000.125.5 , “User Network Interface (UNI) 1.0 Signaling Specification”, June 2001 [3] E. Mannie et al., “Generalized Multi-protocol Label Switching (GMPLS) Architecture”, Internet Draft, Network Working Group, 2002 [4] Special issue on “Telecommunication Grooming”, Optical Networks Magazine, May/June 2001 [5] John Cleary et al., “High Precision Traffic Measurement”, IEEE Communications Magazine, Vol. 40, No. 3, March 2002, pp. 167-173 [6] D. Colle et al., “Strategies for Multilayer Traffic Engineering in Data-centric Optical Networks”, submitted to IEEE Network [7] S. De Maesschalck et al., “Intelligent Optical Networking for Multilayer Survivability”, IEEE Communications Magazine, feature topic on “Resilience in Communication Networks”, Vol. 40, No. 1, January 2002, pp. 42-49 [8] Ying-Dar Lin, Nai-Bin Hsu, Ren-Hung Hwang, “QoS Routing Granularity in MPLS Networks”, IEEE Communications Mag., Vol. 40, No. 6, June 2002, pp. 58-65