TECHNICAL PAPER. Traffic Engineering OCTOBER 2000

Transcription

1 TECHNICAL PAPER Traffic Engineering OCTOBER 2000

2

3 Traffic Engineering Introduction 1 Traffic Engineering Overview 1 Traffic Engineering with ATM 1 Current Framework for IP Traffic Engineering 1 Constraint-Based Routing Issues 4 The GRATE Algorithm as a Solution 4 From CBR to GRATE: Off-line Traffic Engineering 4 Algorithms Used for Off-line Optimization 6 Objectives and Constraints Taken into Account by GRATE 6 GRATE Takes QoS Requirements into Account 6 Results of the Off-line Traffic Engineering Approach Taken by GRATE 7 Traffic Engineering in a Complete OSS 7 Future Applications for Off-line Traffic Engineering 8 Link with Layer 2 and Layer 1 Traffic Engineering 8 Capacity Analyses and Disaster Risk Assessment with What-If Scenarios 8 Bandwidth Brokerage for IP Services 8 Further Reading 9

4

5 Introduction As the Internet evolves into a critical communications network at the heart of the new economy, the challenge for IP networks is to provide the dependability of the telephone networks we are used to. IP networks are also expected to integrate both voice and data communications. For real time applications such as voice, predictable service is a requirement. Currently, the answer to these challenges is overprovisioning costly resources. At the same time, providing Internet communication services is a highly competitive business in which large investments are constantly needed in order to keep pace with the increase in traffic. Consequently, performance optimization has become an important issue. Overdimensioning of network resources is not always a good solution for predictable service. Thus, there is a need to increase the efficiency of resource utilization while minimizing the possibility of congestion. The primary goal of traffic engineering is exactly that: to control traffic flow through a network offering services according to your customers specific requirements, while still utilizing network resources in an economical way. Efficient traffic engineering should take into account current and future traffic demand, as well as individual customer needs, such as bandwidth demand, quality of service (QoS), reliability, etc. Traffic engineering should also provide what-if scenarios that can be used for capacity and disaster risk analysis. When integrated into a complete operations support system (OSS), a traffic engineering tool is the key to providing bandwidth brokerage. It offers the ability to control whether a new customer can be served his required new connection (i.e., as part of a virtual private network [VPN], taking into account all QoS measures) and how this connection can be established. The following sections elaborate on how traffic engineering is implemented for IP networks. Alcatel s new approach to traffic engineering and current practices, the generic rate adaptation traffic engineering (GRATE) algorithm, is introduced, and its advantages over existing techniques are outlined. In conclusion, the future direction of the traffic engineering applications is addressed, as well as the integration of traffic engineering into a complete set of solutions for end-to-end IP operational support. Traffic Engineering Overview Traffic Engineering with ATM As the Internet became more popular in the early 1990s, routers began facing performance limits and became serious network bottlenecks. The routers in the core of the network were replaced by ATM switches, which demonstrated superior forwarding performance, but lacked the connectionless paradigm that was the success of the Internet. Thus, the architecture of the Internet backbones evolved into a set of low capacity edge routers interconnected by a set of permanent virtual circuits (PVCs) across an ATM network, which overcame the forwarding capacity limitations of routers. Moreover, this architecture provided Internet service providers (ISPs) with the ability to control traffic flow across their networks. The path of ATM PVCs across ATM networks can be controlled such that the traffic is equally distributed across the network and the transport resources are used in the most efficient way. Thus, traffic engineering for IP networks was born. Current Framework for IP Traffic Engineering The evolution of chip technology overcame the forwarding capacity limitations of IP routers. Today, application specific integrated circuits (ASICs) for IP address look-up can handle millions of packets per second, enabling terabit routers with interface capacities of up to OC-192. In this respect, routers began outperforming ATM switches and, gradually, the ATM core of IP backbones was replaced by a meshed network of IP terabit routers. However, traffic flow is still bound to shortest path routing decisions of IP routing protocols, leading to bottlenecks and underutilized network resources. ALCATEL 1

6 In order to overcome the limitations of shortest path routing, it was proposed to use multiprotocol label switching (MPLS). MPLS allows for the bypassing of shortest routes by means of label switched paths (LSPs) along non-shortest routes. MPLS is the convergence of connection-oriented forwarding techniques and the Internet s routing protocols. With MPLS, a virtual connection is established between two points on a pure datagram network. The efficiency and operation of a datagram network remain intact, while the advantage of a connection-oriented network can be achieved. This hybrid architecture can emulate connection-oriented services, while normal datagram mechanisms are used to deliver conventional datagram services. Since the overhead required for connection emulation is only needed for services that require it, the cost of running the network is minimized. Using MPLS incorporates four key steps: Path computation Path establishment Path selection Packet forwarding This paper focuses on the path computation process (which can be implemented by traffic engineering algorithms). However, path establishment, path selection and packet forwarding are discussed first. Path establishment: label distribution A path is first established using one of two standardized signaling protocols: resource reservation protocol (RSVP) with extensions, or constraint-based label distribution protocol (CR-LDP). During path setup, labels are exchanged between label switched routers (i.e., routers that support MPLS, LSRs), and these labels are used during packet forwarding (see section Path selection and packet forwarding). Two kinds of paths can be established: explicit paths and shortest paths. The latter form the normal IGP (internal gateway protocol) routes. An explicit path is one whose route is determined in advance and which can be different from the shortest path route. (In Figure 1, this is the thick line between the LSR in Los Angeles and the LSR in New York via the two other routers.) The ability to set up explicit paths is an important element in traffic engineering. Path selection and packet forwarding At an ingress LSR (i.e., the router where an LSP starts; in Figure 1, it is the LSR in Los Angeles), incoming packets are sent on the LSP, according to the forwarding equivalence class (FEC) they belong to. A FEC is a group of IP packets that is forwarded in the same manner, with the same destination and forwarding treatment. The assignment of a packet to a FEC can be based on parameters such as packet ingress point, fields in the IP header (destination address, forwarding treatment such as differentiated services code point [DSCP], etc.). The FEC is encoded in a label, a short, fixed-length identifier, which is attached to the packet. A transit LSR forwards packets based on the information contained in the label and the interface in which the packet came. The IP header is not consulted. The look-up in the label information base (LIB) determines the packet s outgoing interface and new outgoing label. This process is called label swapping. Finally, the egress LSR strips off the label, and the packet is forwarded as a regular IP packet (i.e., the outgoing interface is determined by a look-up of the destination address in the forwarding information base (FIB). Path protection: an extra value added by MPLS One of the advantages of the connection-oriented model of MPLS is that traffic can be quickly redirected from a broken connection to an alternative connection, and on to the same destination. This is in contrast to restoration times in datagram networks, where the routing protocols must converge before service is restored. MPLS allows users to choose between different protection strategies. One method is fast rerouting, which is a local repair action. If a repair can be made locally to the device that detects the failure, restoration can be made without serious service disruption and can happen in the same time frame as SONET restoration. However, fast restoration often creates nonoptimal paths. For that reason, there is a second protection technique: the head end of the LSP (the ingress LSR) is notified, which can nondisruptively redirect traffic to a more optimal path, using a make-before-break strategy (in which a new connection is established before the old one is torn down) or active standby. 2 ALCATEL

7 Path computation The route taken by an LSP through the network is determined by path computation. This can either be done online in real time in the network nodes themselves, or off-line on a workstation using a centralized application that determines routing plans on behalf of each router. Online computation typically uses a shortest path algorithm, or an adaptation generally denoted by constraint-based routing (CBR). CBR is a class of routing algorithms that computes shortest routes through a network subject to a set of constraints and requirements. Trunk constraints may include bandwidth, delay (expressed as a maximum number of hops), and policy instruments such as resource class attributes. Since CBR considers not only the topology, but also additional link properties (i.e., maximum link bandwidth, currently reserved bandwidth, link colors, etc.), additional network resource attributes are flooded using extensions to the link-state IGPs, such as open shortest path first (OSPF) and intermediate system-to-intermediate system (IS-IS). An example of using the CBR policy instruments is to first assign transatlantic links to the user-defined resource class Transatlantic, overprovisioned links to resource class Predictable, satellite links to resource class Satellite, etc. When a customer asks for a low delay connection between offices in Brussels and Rome, an LSP can be set up with the constraints exclude Transatlantic and Satellite and include Predictable. Figure 1: MPLS Path Setup and Label Switching Switch Labels Ingress LSR Los Angeles L1 IP Packet Egress LSR New York IP Packet L2 IP Packet IP Packet L3 IP Packet L1 Look-Up LSP via FEC ALCATEL 3

8 Constraint-Based Routing Issues The advantages of CBR stem mainly from the fact that it is simple and that it works in a dynamic fashion. Unfortunately, the advent of more complex services (such as DiffServ) and increasing performance and survivability demands reveal some of its drawbacks. The disadvantages of CBR are related to the optimization that takes into account all traffic trunks in sequence as they are proposed to the network. There is no way of ensuring that the order in which the trunks are set up leads to an optimal solution. In fact, in many cases, much traffic is blocked because of this system. Suppose, for instance, that a large trunk on a long path is routed first. Many resources will be attributed to this trunk. It is conceivable that subsequent trunks will have difficulty finding enough resources. In order to react appropriately to changing traffic patterns, it is necessary to be able to reroute previously established trunks if they obstruct a better routing configuration. The problem becomes even more serious when traffic needs to be protected with backup paths (see Figure 2). CBR algorithms can handle the combined constraints of both a primary and a protection path. However, this is limited to a 1:1 protection mode. It is clear that far more efficient solutions can be achieved if protection bandwidth can be shared among trunks that have working paths that are assumed to be exempt from simultaneous failure. Indeed, most protection schemes consider only single link and/or node failures, in which case fully node and link disjoint working paths cannot fail simultaneously. Sharing protection capacity (in a so-called shared protection scheme) leads to more efficiency in the network. This requires a view of all trunks and their paths through the network. In Figure 2, the upper picture shows a situation in which two 20 Mb/s trunks between the same pair of nodes are 1:1 protected. The working traffic of the trunks is normally carried on the upper and middle path. They both have the same backup path (i.e., the lower path). In the event of a link failure (such as the one shown in the figure), backup capacity is reserved for all trunks for which the primary path is affected by the failure. Since both trunks have the same backup path, they have to share the capacity of the backup path (assuming full protection and equal link capacities); thus, their working traffic can only receive a share of 50 percent or 10 Mb/s. For backup protection, backup capacity is provided only for those trunks for which the working path actually fails. This means that, in this example, only one trunk can be affected for any given failure. The backup capacity is reserved only once, which means that both trunks can have a share of 100 percent, or 20 Mb/s. Hence, the gain in fairness and throughput in this case is 100 percent, which indicates the possible benefits of a backup protection scheme. Finally, the use of CBR in QoS-aware networks is questionable. In such networks, some traffic flows need to be offered with low loss or low latency guarantees. Although CBR algorithms can, eventually, be extended so that these QoS requirements can be taken into account for each given trunk, a CBR algorithm will not be able to estimate the impact of this new trunk on the QoS characteristics of the existing trunks. This requires a view of all trunks, their paths, and the load changes along these paths when a new trunk is introduced. Indeed, delay and delay jitter are typically related to buffer occupancy, which in turn is related to the load at each given node. Therefore, CBR algorithms cannot be used for the QoS provisioning required in a DiffServ network, which must be able to offer low loss or low latency guarantees to the flows that require them. The GRATE Algorithm as a Solution From CBR to GRATE: Off-line Traffic Engineering The problems related to a distributed traffic engineering approach are solved if the network view of the edge nodes is expanded. Each node should know all trunks, their paths, and their QoS requirements. When configuring a new trunk, all other network nodes should be informed, requiring some additional extensions to the routing protocols. However, there is a more serious problem. Even if all routers have the same, complete view of the topology and the trunks, they must also use the same CBR algorithm. Otherwise, inconsistencies will arise. It is very unlikely that in a network with routers from multiple vendors, all edge nodes use the same CBR algorithm. Therefore, a distributed approach seems inappropriate to meet the needs addressed in the previous section. 4 ALCATEL

9 Consistent routing decisions require centralized control of the routing configuration. A centralized approach obviates the need for any routing protocol extensions, since the paths of the trunks and the load that they induce, are known to the centralized server. Yet, this centralized server needs to solve the complex problem of routing every trunk and respecting QoS parameters and protection levels, while at the same time minimizing the amount of spare capacity for restoration purposes. Figure 2: Shared Protection vs. 1:1 Protection Scheme 10 Mb/s A B 10 Mb/s C D 20 Mb/s E F 1:1 Protection Scheme Working capacity Backup capacity 20 Mb/s A B 20 Mb/s C D 20 Mb/s E F Shared Protection Scheme ALCATEL 5

10 Algorithms Used for Off-line Optimization Global optimization can be achieved through the use of linear programming-based algorithms or with heuristics. Heuristic algorithms have the advantage of being fast, because they tend to make intelligent assumptions about the problem that reduce the number of variables to be optimized. They provide excellent results for specific problems. However, they are less flexible to changes and may be incapable of dealing with complex problems when it is difficult to identify the assumptions for reducing the number of variables. Linear programming-based algorithms, on the other hand, provide a mathematical framework for solving a generic class of problems, which makes them far more flexible and reusable than heuristics. They can deal with the complicated optimization problems that arise from multiple path routing or shared protection schemes. Alcatel s linear programmingbased approach describes the traffic engineering problem by means of an objective function and a set of constraints. Objectives and Constraints Taken into Account by GRATE The objective function contains multiple objectives that can be maximized or minimized. The objectives are either resource-oriented or traffic-oriented. Resource-oriented objectives address network-related quantities, such as load balance and link utilization. Resource-oriented traffic engineering can be used to route the demands in the network while preserving (as much as possible) free resources for future increases or new demands, or for routing lower priority traffic. This is done by minimizing the utilization of the maximally used link, while honoring the demand for each traffic trunk. As a second objective, the total resource utilization in the network is minimized, which will generally reduce the total routing cost. Traffic-oriented objectives do not focus on the network, but rather on the traffic trunks. They are used to make sure that the amount of traffic served by the network is maximized, taking into account all individual customer service level agreements (SLAs), which maximizes revenues. The share of a traffic trunk is defined as the fraction of its demand that can be routed through the network. Note that this fraction must be one or higher to avoid partial blocking of a trunk. The extent to which it is larger than one indicates the margin of expansion for each trunk s bandwidth demand. Throughput is defined as the sum of all shares multiplied by their respective demands. Note that there is no guarantee that all traffic will fit into the network, even if that is a requirement. The algorithm provides the fraction of the demand that can be accepted (see Figure 2). Arbitrary starvation of trunks is avoided by maximizing the minimum share in the network. As a second objective, throughput is maximized. This will generally increase the total revenue that can be obtained from the network. The constraints typically express physical limitations of the network, such as limited link capacity and conservation constraints. They may also be used to force a single path for each trunk, or to implement various protection schemes. GRATE Takes QoS Requirements into Account As far as QoS requirements are concerned, the algorithms allow different traffic types to be treated differently. Traffic with stringent bandwidth constraints requiring low loss and latency, such as the expedited forwarding per hop behavior (EF-PHB) in DiffServ, can be routed through load balancing. This enables a lower overall load of EF, which is beneficial to latency, while preserving resources for other PHBs. The best effort (BE) PHB is typically treated using traffic-oriented objectives. The bandwidth requirements for this traffic are far looser, which means that fairness is provided by maximizing the minimum share and maximizing throughput for future expansion or revenue optimization. In addition, the off-line approach allows implementation of a shared protection mechanism for restoration. With this mechanism, backup capacity is reserved on links only when the corresponding primary path fails. Excluding all failures except single link failures, allows the sharing of protection capacity between primary paths that are node and link disjoint. Obviously, the fairness and throughput of the primary paths in a shared protection scheme are higher than that for a 1:1 protection scheme. The difference depends on the number of protected trunks and the protection capacity. If all trunks are protected for 50 percent of their capacity, the throughput of the primary paths increases on average by 16 percent, while the backup capacity on the links is decreased by 25 percent, compared to a 1:1 protection scheme (Figure 2). 6 ALCATEL

11 Results of the Off-line Traffic Engineering Approach Taken by GRATE The use of a preplanned off-line approach such as the GRATE algorithm allows for the optimal selection of explicit paths for the traffic trunks, while taking into account protection and QoS for each trunk or customer separately. For single path traffic engineering, in which a single path must be chosen for each trunk, the traffic handling capacity of the network (Figure 1) has been considerably increased. With the LSP path placement obtained from the Alcatel traffic engineering tool, the OSPF routing increase averages approximately 20 percent to 25 percent for fairness and throughput. This means that the throughput of the least served trunk, as well as the total throughput in the network, is increased by 20 percent to 25 percent. A comparison between GRATE and a conventional constraint-based routing algorithm is best explained using an example. For this purpose, we applied both algorithms to a set of randomly generated networks, exhibiting an Internet-like topology. The networks were carefully dimensioned to avoid underprovisioning and to limit overprovisioning. For all networks, GRATE achieved an LSP configuration that allowed the routing of all trunks. The constraint-based routing algorithm, on the other hand, never succeeded in routing all trunks. Depending on the order in which the trunks were set up, the average blocking rate (the percentage of trunks that could not be routed) ranged from 12 percent to 15 percent, with peaks of up to 70 percent. The average blocked demand percentage (the ratio of the sum of the demand of all blocked trunks over the sum of all demands) ranged from 7 percent to 21 percent. In some cases, however, it could be as high as 40 percent. Clearly, the constraint-based routing algorithm is outperformed by GRATE. In addition, the quality of its solution heavily depends on the order of the inputs. Ordering the trunks beforehand can establish a compromise between reducing the blocking rate, which leads to more fairness in the network, and increasing the throughput through a reduction of the blocked demand percentage. This explicit trade-off is implicitly present in GRATE. In conclusion, when compared to constraint-based routing, the linear programming-based single path traffic engineering algorithm significantly reduces the blocking probability of a trunk (note that the blocking probability is 0 percent for GRATE) and increases the total demand that can be supported by the network. In addition, a preplanned off-line tool allows the optimization of protection capacity and the introduction of QoS guarantees in the network. Traffic Engineering in a Complete OSS Off-line traffic engineering solutions can be used as a basis for a set of value-added applications for IP service providers. An IP OSS is generally broken down into three major functional areas: service provisioning and activation, service assurance, and customer care and billing. Traffic engineering is implemented in the areas of service provisioning and service assurance. For service provisioning, traffic engineering plays an important role in the bandwidth brokerage function. It can calculate whether the network can meet a certain traffic demand with a promised QoS. As such, it is an integral part of customer-oriented service activation. In service assurance, traffic engineering is used in a selftriggering mode. A performance management tool predicts when the network will be congested. When certain links in the network reach congestion, the performance management tool triggers the traffic-engineering tool to reoptimize and reconfigure the MPLS network. Traffic engineering is a key component in a complete IP OSS solution. It is a means to control the network s performance and, therefore, a way to achieve predictable services on the network. ALCATEL 7

12 Future Applications for Off-line Traffic Engineering Link with Layer 2 and Layer 1 Traffic Engineering A clear migration towards network architectures, where the IP layer runs directly on top of the optical layer, is perceived. Evolutions in optical transmission networks show that in the near future optical paths (lambdas) can be dynamically set up or broken down. This will enable traffic engineering to dynamically change the physical links between routers and as such introduce a new degree of freedom. Although this degree of freedom is quite new for the physical layer, the link layer (e.g. ATM) can already provide dynamic setup or teardown of links (virtual paths/virtual connections). Typically, the calculation of an optimal lambda or an optimal VP/VC will be done by traffic engineering algorithms introduced in the respective layers of the OSI stack. However, traffic engineering tools that run on Layer 3 have to take into account the new degrees of freedom introduced by extra capabilities on the underlying layers. For MPLS networks, traffic engineering will have to take into account that part of the network s topology that can be changed by reconfiguring the links on Layer 2, or on the optical layer. This will enable even more optimal sets of LSPs. Capacity Analyses and Disaster Risk Assessment with What-If Scenarios What-if scenarios give operators the ability to simulate a network s behavior if a network error occurs (i.e., a router outage occurs or a link goes down). A primary class of what-if scenarios uses the off-line traffic engineering tool to recalculate the network s optimized configuration, taking into account the network s changed configuration. They can be used for network planning purposes. By using this type of scenario, the benefit of an addition or removal of a router or a link can be calculated. It is also possible to see the effect on customers and services when traffic changes. A secondary class of what-if scenarios simulates the network s actual behavior (i.e., MPLS, constraint-based routing, etc.). They can be used for disaster risk assessment. By using this type of scenario, one can calculate which customers or services will be affected when a router goes down or a link breaks. Bandwidth Brokerage for IP Services Essentially, a bandwidth broker is a domain-based network resource management scheme that dynamically binds policies and resource usage situations to the allocation of network resources. Dynamic policy enforcement introduces more sensitivity to available resources and provides a mechanism for dynamic allocation of the resources based on sets of rules. Two factors are used to distinguish different types of bandwidth brokerage: whether the bandwidth is offered from a provider s own domain (intra-domain) or rented from another provider in a wholesale business model (inter-domain), and whether or not negotiation is possible on the type of QoS offered and the price. With intra-domain bandwidth brokerage, the main question is: Can I give a certain customer the bandwidth and QoS requested or not? Do I have to reoptimize the network s configuration for this? This should not only involve bandwidth on IP, but also the transmission layer (ATM, synchronous digital hierarchy [SDH]) and the physical layer (i.e., dense wave division multiplexing [DWDM]) which can be traffic engineered. Future solutions will take all layers into account when optimizing the network s configuration. Inter-domain bandwidth brokerage extends intra-domain bandwidth brokerage with the ability to use bandwidth from peer providers or transmission network providers (i.e., SDH, ATM, DWDM, etc.). Basic traffic engineering algorithms offer all network and resource utilization information needed to take decisions in a bandwidth broker. This information comes for free, as a byproduct of the algorithms calculations. It is, for example, possible to know each link s usage or each queue s state as a result of the traffic engineering calculations, because these metrics are used in the algorithm s cost function. This makes traffic engineering the optimal stepping stone for bandwidth broker functionality. 8 ALCATEL

13 Further Reading 1. ALMA Vision IP white paper, Carl Rijsbrack, Robert Mathonet, Alcatel Telecommunications Review 2Q ALMA Vision IP Traffic Engineering, Product Description, 3. ALMA Vision IP Traffic Engineering, Product Leaflet, 4. ALMA Vision IP, Product Description, 5. Multi-Objective Traffic Engineering of IP Networks Using Label Switched Paths, S. Van den Bosch, F. Poppe, H. De Neve and G. Petit, accepted for presentation at Networks 2000, September 2000, Toronto, Canada 6. Choosing the Objectives for Traffic Engineering in IP Backbone Networks based on Quality-of-Service Requirements, S. Van den Bosch, F. Poppe, H. De Neve and G. Petit, submitted to QofIS 2000, September 2000, Berlin, Germany ALCATEL 9

14

15

16 For more information Alcatel and the Alcatel logo are registered trademarks of Alcatel. All other trademarks are the property of their respective owners. Alcatel assumes no responsibility for the accuracy of the information presented, which is subject to change without notice Alcatel. All rights reserved CL TQZCA Ed.01