Introduction

Traffic engineering is the practice of controlling how traffic flows across a network so that you use links efficiently, avoid congestion, and meet performance goals such as low delay or high reliability. In simple terms, it is about deciding not only where routes exist, but how much traffic uses each route, and when that might change.

In an enterprise or service provider network, basic routing protocols are usually enough to make the network work correctly. Traffic engineering becomes important when you care about performance, cost, or specific service guarantees and when you have multiple possible paths and complex traffic patterns. It is especially relevant in environments that already use technologies such as MPLS, VXLAN, SD‑WAN, or QoS, which are covered in other chapters.

This chapter focuses on the goals, concepts, and common techniques that are unique to traffic engineering, without going deep into the internal details of any particular routing protocol.

Why Traffic Engineering Exists

Traditional routing protocols such as OSPF, IS‑IS, or BGP are primarily designed to find a valid path between source and destination, usually the shortest path according to some metric. They are not designed to ask whether that path has enough capacity, whether it is the cheapest, or whether sending everything along that path will overload a single link while other links sit unused.

Imagine a network backbone where you have a square of four routers, each side connected with 1 Gbps links, and an extra diagonal link between two opposite corners that is also 1 Gbps. A basic shortest path algorithm might always choose the top and right edges as the path, while leaving the left and bottom edges lightly used. If a large amount of traffic needs to pass through, the top and right links can become congested even though the network as a whole still has spare capacity. This mismatch between path choice and available resources is what traffic engineering tries to solve.

Traffic engineering introduces awareness of:

• Link capacity and typical utilization.
• The volume and direction of traffic flows.
• Business or application requirements, for example, critical traffic that must avoid certain paths.
• Cost differences between paths, such as expensive leased lines versus cheap internal links.

The goal is to place traffic on paths in a way that respects these constraints and improves overall network performance and stability.

Key Concepts: Flows, Paths, and Constraints

To understand traffic engineering, it is useful to think in terms of flows, paths, and constraints rather than individual packets.

A flow is a group of packets that share some common characteristics such as source, destination, or application. Flows can be defined at different granularities, for example all traffic from a branch to a data center, or only voice traffic between two call managers.

A path is the sequence of network hops that a flow takes across the network. Standard IP routing usually chooses a single best path, or sometimes multiple equal cost paths, based only on routing metrics. Traffic engineering techniques allow you to select paths using more sophisticated criteria.

Constraints are the rules or limitations that any chosen path must respect. Examples include:

• Maximum allowable utilization on any link that carries the flow.
• Required minimum bandwidth for the flow.
• Limits on delay or the number of hops.
• Restrictions such as “do not cross this link” or “avoid this region.”

Traffic engineering operates by mapping flows to paths subject to constraints, in order to optimize some objective. Common objectives include minimizing maximum link utilization, minimizing delay for specific classes of traffic, or balancing load across available links.

This perspective is different from basic routing. Basic routing is mostly local and reactive, while traffic engineering tends to be more global and planned.

Objectives of Traffic Engineering

Different networks apply traffic engineering for different reasons, but the most common objectives can be grouped into several categories.

First, there is load balancing and congestion avoidance. Instead of allowing a few links to carry most of the traffic while others are underused, traffic engineering distributes traffic so that utilization is more even. This reduces the risk that any single link will become a bottleneck and improves overall throughput.

Second, there is capacity and cost optimization. Service providers, and large enterprises with leased circuits, pay for bandwidth. Traffic engineering allows them to push more useful traffic through existing links without upgrading capacity and to prioritize cheaper paths while keeping performance acceptable. It can also help decide where to invest in additional capacity by making current hot spots visible and measurable.

Third, there is quality of service support. Some applications such as real‑time voice and video, or key business applications, are more sensitive to delay, jitter, or loss. Traffic engineering helps steer such traffic over paths that are more reliable or less congested, while sending less sensitive traffic over longer or cheaper routes.

Finally, there is reliability and fast recovery. By understanding typical traffic patterns and having predefined alternate paths, a network can recover from failures while still respecting performance expectations. This can involve precomputed backup paths or diverse routing where important flows are sent over disjoint paths.

In practice, traffic engineering often has to balance multiple objectives at once. For example, you might want to reduce costs but not at the expense of poor performance for critical users.

Classical Techniques: Equal‑Cost and Unequal‑Cost Usage

Even without advanced features, many networks use simple mechanisms that already achieve basic traffic engineering effects.

One common mechanism is equal cost multipath routing, often abbreviated as ECMP. When a routing protocol discovers multiple paths to the same destination with the same cost, the router can install several next hops in the routing table instead of just one. The forwarding plane then splits traffic among these next hops. This is a basic form of load balancing.

Traffic is usually divided on a per‑flow basis, determined by hashing fields such as source and destination IP addresses, ports, and sometimes other header fields. The hashing ensures that packets belonging to the same flow follow the same path, which avoids issues with out of order delivery.

ECMP is limited to paths with equal cost. If one path is much shorter or cheaper but has limited capacity, and another path is longer but has more available capacity, ECMP either does not use the second path or uses it only when the costs are artificially set to be equal. This can lead to suboptimal utilization.

Some solutions allow unequal cost load balancing, where traffic is distributed in proportion to assigned weights, not just equally. This makes it possible to send more traffic along a higher capacity or cheaper path while still using an alternate path to absorb some load. Techniques for unequal cost usage can be static or can interact with routing protocols, but details about specific implementations fall under routing protocols themselves.

In summary, ECMP and related techniques represent entry level traffic engineering approaches that work directly with existing IP routing. They do not require per flow signaling or complex path calculations, but they also cannot consider detailed constraints beyond the basic routing metric.

Constraint Based Path Selection

More advanced traffic engineering makes path selection constraint based instead of metric based. Instead of simply choosing the path with the lowest numeric metric, the network calculates paths that satisfy a set of constraints.

Typical constraints include minimum bandwidth, maximum delay, and link attributes such as link type or administrative tags. A path that fails any constraint is considered invalid even if it is shorter according to the normal metric.

This approach requires two key capabilities. The first is knowledge of the network state. Routers or controllers need information about the available bandwidth on links, their delay, and other properties. Link state routing protocols are often used as a base because they already distribute detailed topology information. Additional extensions can carry resource information.

The second capability is a path computation mechanism. Instead of just running the classic shortest path algorithm, the system runs algorithms that search for paths that satisfy the constraints. This is sometimes called constraint based routing. The more constraints you add, the more complex the problem becomes, especially in large networks.

Once a suitable path is computed, it must be applied in a way that forwarding devices can enforce. In many modern networks this is done through label based systems, segment routing, or SDN controllers, which will be discussed in other chapters.

This shift, from best metric to constraint satisfaction, is a core idea behind modern traffic engineering.

Centralized vs Distributed Traffic Engineering

Traffic engineering decisions can be made in a distributed or centralized way.

In distributed traffic engineering, each router uses local information plus routing protocol data to make its own decisions. Techniques like ECMP or protocol specific path preferences fall into this category. Some advanced methods such as traditional MPLS traffic engineering with signaling operate in a mostly distributed fashion, where ingress routers signal specific paths across the network.

Distributed approaches scale well, are resilient to controller failures, and do not require a central point of control. However, no single router has a complete view of all traffic. Decisions may be optimal locally but not globally.

In centralized traffic engineering, a controller or management system collects information about topology, link utilization, and sometimes flow statistics. It computes paths for many flows at once and then programs routers or switches to use those paths. This is common in SDN environments or data centers that use controller driven overlay networks.

Centralized systems can solve more complex optimization problems because they see the entire network and all flows. For example, they can compute paths that minimize the maximum link utilization across the whole network. The trade off is additional complexity and reliance on the controller.

Many real networks combine both styles. Core routing remains distributed for basic connectivity, while a centralized system applies policies and adjusts paths for selected traffic classes or critical services.

Traffic Engineering in MPLS Backbones

MPLS based backbones are a classic environment where traffic engineering is widely used. The key idea is that instead of letting IP routing freely choose intermediate hops for every destination, you explicitly create label switched paths, often abbreviated as LSPs, that follow a chosen route through the MPLS network.

For traffic engineering, these LSPs are not simply shortest path tunnels. They are often created according to constraints such as minimum bandwidth or specific link attributes. Once established, traffic that enters the MPLS domain is mapped onto the appropriate LSP. This allows operators to steer large aggregates of traffic along pre planned paths.

A simple example involves two parallel physical routes between two core routers, perhaps one route is low latency but expensive, and another route is higher latency but cheaper. Without traffic engineering, the routing protocol might always choose the low latency path, causing high utilization and cost. With MPLS based traffic engineering, the operator can create distinct LSPs along each physical route and decide that delay sensitive traffic uses the low latency LSP while bulk data uses the cheaper LSP.

This mechanism also supports fast reroute techniques where backup LSPs are precomputed. If a failure occurs, traffic can quickly move to a backup path without waiting for global routing convergence. Such fast reroute capabilities are often considered part of traffic engineering because they are designed to preserve performance under failure, not just restore basic reachability.

Although the detailed signaling and control protocols for MPLS traffic engineering are part of other chapters, it is important to see how they serve the traffic engineering goals of path control, constraint satisfaction, and fast restoration.

Traffic Engineering in SD‑WAN and Segment Based Designs

Modern enterprise networks increasingly use SD‑WAN and segment based designs to achieve traffic engineering without deep MPLS complexity.

In SD‑WAN, edge devices typically have multiple uplinks, such as internet, MPLS, or LTE. The SD‑WAN controller measures performance characteristics of each path, such as packet loss, delay, and jitter. It then applies policies that define which applications or traffic classes should prefer which path, given current performance.

For example, real time voice traffic might be pinned to a low latency path as long as loss stays below a threshold. If loss increases, traffic can be steered to another path that currently meets the policy. Bulk backup traffic might always use the cheapest link regardless of latency. These decisions represent traffic engineering applied at the overlay level, while the underlay routing still follows traditional IP rules.

Segment based designs, including segment routing, also play a role in modern traffic engineering. Instead of signaling an explicit path using complex signaling protocols, an ingress node can attach a list of segments to packets. Each segment represents either a node, a link, or a function. The sequence of segments guides the packet along a chosen route that is not necessarily the normal shortest path. This approach combines path steering with simpler signaling and good integration with link state routing.

In both SD‑WAN and segment routing scenarios, traffic engineering focuses on mapping traffic classes to policies that describe path constraints and preferences, and then using the capabilities of the platform to enforce those policies.

Data Collection and Measurement

Effective traffic engineering depends on accurate information about what is happening in the network. Without it, there is a risk that changes designed to improve performance will have unexpected side effects.

Several kinds of data are commonly collected. First, link utilization statistics show how busy each link is over time. This helps identify persistent hot spots, sudden bursts, and underused capacity. Second, flow statistics describe which traffic sources and destinations consume bandwidth. This allows operators to see large flows, such as data transfers between data centers, that might need special handling.

Latency, jitter, and loss measurements are also important, especially for real time applications. Active probing, or standards based performance monitoring, can provide continuous visibility into path performance.

In centralized traffic engineering solutions, this data is gathered by a controller. In more traditional environments, it may be collected by monitoring systems that expose graphs and alerts. Either way, the data informs planning decisions such as where to add capacity, which paths to prefer, or when to move traffic to alternative routes.

It is important to recognize that the network state can change quickly. Traffic engineering systems must either react frequently or focus on long term patterns. Aggressive, rapid adjustments can cause instability, so many designs prefer to make controlled, gradual changes.

Risks and Trade‑offs

Traffic engineering can significantly improve how a network behaves, but it also introduces risks and trade offs that must be considered.

One risk is complexity. As more constraints, flows, and policies are introduced, it becomes harder to reason about the overall effect of changes. Misconfigurations can lead to unexpected congestion or even loops. Operators must maintain clear documentation and use tools that validate changes when possible.

Another issue is stability. Networks have natural variability in traffic. If the traffic engineering system reacts too quickly to small fluctuations, it may constantly move traffic between paths. This can produce oscillations, where link utilizations rise and fall in cycles. To avoid this, many designs use thresholds, hysteresis, or time windows to smooth reactions.

There is also a trade off between optimality and robustness. A design that is perfectly optimized for current traffic may be fragile if traffic patterns change. It can be better to choose a configuration that is slightly less optimal but more resilient to changes and failures. Operators must balance these factors according to the importance of performance versus simplicity.

Finally, there can be operational and organizational challenges. Traffic engineering decisions often cross team boundaries, for example between application teams and network teams, or between different network domains. Coordinating policies and goals across these boundaries can be as important as the technical mechanisms themselves.

Traffic Engineering and QoS

Although quality of service and traffic engineering are separate topics, they are closely related in practice.

QoS focuses on marking, prioritizing, and shaping traffic so that different classes receive appropriate treatment on each link. Traffic engineering focuses on which path a flow takes across the network. When combined, the two form a powerful toolkit.

For instance, voice traffic might be marked with a high priority class. QoS ensures that once voice packets are on a link, they receive preference in scheduling and are less likely to be dropped. Traffic engineering can then ensure that voice flows use paths with low latency and minimal congestion. If voice is sent over a path that is already near capacity, even good QoS markings may not be enough to provide a smooth experience.

On the other hand, low priority bulk transfers can be steered towards longer or cheaper paths, letting QoS downgrade them on each hop to avoid interference with critical traffic. This integrated approach allows the network to align resources with business priorities, not just technical constraints.

The main point is that traffic engineering and QoS must be designed together. Steering traffic without considering per link behavior, or shaping traffic without considering path choice, often leads to disappointing results.

Planning for Growth and Evolution

Traffic engineering is not a one time activity. Networks and applications evolve, and so must the way traffic is handled.

An effective approach begins with understanding current traffic patterns and defining clear objectives, such as target utilization ranges, performance thresholds for critical applications, or cost reduction goals. Traffic engineering techniques are then chosen to meet these objectives within existing technical and organizational constraints.

As new applications are added, branch offices appear, or data centers move, the set of important flows and constraints changes. Regular review of traffic data and policies is necessary. Over time, networks may adopt more advanced mechanisms, such as moving from basic ECMP to segment based designs or from static policies to dynamic SD‑WAN controllers.

In all cases, successful traffic engineering depends on a clear understanding of what the network is supposed to achieve, combined with appropriate tools to observe, plan, and adjust the flow of traffic in a controlled way.

Views: 62