Generic Traffic Engineering

Network traffic engineering involves optimizing and managing traffic flows to enhance overall performance. It encompasses various techniques and strategies for controlling and shaping the flow of data packets, minimizing congestion, and maximizing network efficiency.

Traffic engineering is not an MPLS-specific practice; it is a general practice. Implementing traffic engineering can be as simple as tweaking IP metrics on interfaces or as complex as running an ATM PVC full-mesh and optimizing PVC paths based on traffic demands. Using MPLS, traffic engineering techniques (like ATM PVC placement) are merged with IP routing techniques to achieve connection-oriented traffic engineering. With MPLS, traffic engineering is just as practical as with ATM, but without some drawbacks of IP over ATM.

MPLS and Traffic Engineering

The applications MPLS enables will motivate you to deploy it in your network. Traditional IP networks are either incapable of supporting these applications or are challenging to implement. Traffic engineering and MPLS VPNs are examples of such applications. This book is about the latter. In the sections below, we will discuss MPLS’s main benefits:

• Routing and forwarding can be decoupled.

• IP and ATM integration should be improved

• Providing the basis for building next-generation network applications and services, such as MPLS VPNs and traffic engineering

Decoupling Routing and Forwarding

A hop-by-hop forwarding paradigm is used in IP routing. When an IP packet arrives at a router, it is checked for the destination address in the IP header, a route lookup is performed, and the packet is forwarded to the next hop. The packet is dropped if there is no route. Each hop repeats this process until the packet reaches its destination. Nodes in MPLS networks also forward packets hop by hop, but this forwarding is based on fixed-length labels. MPLS applications such as traffic engineering are enabled by this ability to decouple packet forwarding from IP headers.

Better Integration of the IP and ATM Worlds

There was a clash between IP and ATM as soon as they were introduced. Despite being standardized, IP has always been viewed as a sideshow to ATM. Since it became apparent that our PCs and wristwatches would not run ATM stacks, attempts have been made to map IP onto ATM. In previous attempts to map IP to ATM, the main drawback was that they either attempted to separate the two worlds (carrying IP over ATM VCs) or tried to integrate IP and ATM with mapping services (such as ATM Address Resolution Protocol [ARP] and Next-Hop Resolution Protocol [NHRP]). Despite its usefulness, IP over ATM VCs (also known as the overlay model) has scalability limitations. The network is more vulnerable to failure when mapping servers are used.

MPLS Traffic Engineering (MPLS TE)

IP class-of-service differentiation and ATM traffic engineering capabilities are combined as part of MPLS TE. A Label-Switched Path (LSP) enables you to construct a network and forward traffic down it.

An MPLS TE LSP (also known as a TE tunnel) enables the headend to control the path traffic takes to a particular destination, as with ATM VCs. This method allows traffic to be forwarded based on various criteria rather than just the destination address.

Due to MPLS TE’s inherent nature, ATM VCs and other overlay models do not suffer from flooding problems like MPLS TE. To construct a routing table with MPLS TE LSPs without forming a full mesh of routing neighbors, MPLS TE uses an autoroute mechanism (unrelated to the WAN switching circuit-routing protocol of the same name).

In the same way ATM reserves bandwidth for LSPs, MPLS TE does the same when it builds LSPs. If you reserve bandwidth for an LSP, your network becomes a consumable resource. As new LSPs are added, TE-LSPs can find paths across the network with bandwidth available to reserve.

The Role of Traffic Analysis

Traffic analysis is a fundamental aspect of network traffic engineering. By analyzing network traffic patterns, administrators gain insights into peak usage times, identify bottlenecks, and make informed decisions regarding network resource allocation. This data-driven approach allows for proactive network management and optimization.

Traffic Engineering in Software-Defined Networking (SDN)

Software-defined networking (SDN) revolutionizes traditional network architecture by separating the control plane from the data plane. SDN enables centralized network management and programmability, empowering traffic engineers to control and shape network traffic dynamically. This section will explore the benefits of SDN in traffic engineering and highlight its impact on network scalability and flexibility.

Network Flow Model

In a computer network, an important function is to carry traffic efficiently, given the routing paradigm in place. Traffic engineering achieves this efficiency. Network flow models are used for network traffic engineering and can help determine routing decisions. Network Traffic engineering (TE) is the engineering of paths that can carry traffic flows that vary from those chosen automatically by the routing protocol(s) used in that network.

The Role of MPLS Networking

Therefore, we can engineer the paths that better suit our application. We can do this in several ways, such as standard IP routing, MPLS, or OpenFlow protocol. When considering network traffic engineering and MPLS OpenFlow, let’s start with the basics of traffic engineering and MPLS networking.

Related: You may find the following posts helpful for pre-information:

1. Transport SDN
2. Network Visibility
3. Load Balancing
4. Chaos Engineering Kubernetes
5. Segment Routing
6. What is OpenFlow
7. DMVPN Phases

Back to Basics: Network traffic engineering

Importance of Network Traffic Engineering

Efficient network traffic engineering is essential for several reasons:

1. Optimal Resource Utilization: Traffic engineering balances network resources to minimize congestion and maximize bandwidth utilization, improving network performance.

2. Enhanced Quality of Service (QoS): Traffic engineering techniques prioritize critical applications, ensuring they receive the necessary bandwidth and reduce latency, improving user experience and customer satisfaction.

3. Scalability: With proper traffic engineering, networks can accommodate increased traffic demands, scalability, and future growth without significant performance degradation.

Techniques Used in Network Traffic Engineering

Here are some commonly used techniques in network traffic engineering:

1. Traffic Monitoring and Analysis: Network administrators employ tools to monitor and analyze traffic patterns, helping them identify bottlenecks, congestion points, and potential network vulnerabilities.

2. Traffic Shaping: Traffic shaping involves regulating network traffic flow to optimize performance. It can prioritize certain types of traffic, delay less critical traffic, and prevent data bursts that may overload network resources.

3. Load Balancing: Load balancing distributes network traffic across multiple paths or devices, preventing congestion and ensuring efficient use of available resources.

4. Quality of Service (QoS): QoS mechanisms prioritize specific types of traffic, ensuring that critical applications receive the necessary resources and reduce latency.

5. Traffic Engineering Protocols: Network engineers utilize RSVP (Resource Reservation Protocol) and MPLS (Multiprotocol Label Switching) to manage network traffic and allocate resources effectively and dynamically.

1st Lab Guide: MPLS Forwarding

In the following guide, we have an MPLS network. MPLS networks have devices with different roles. So, we have the core node called the “P” provider and the “PE” provider edge nodes. The beauty of MPLS forwarding is that we can have scale in the network’s core. The P nodes do not need customer routes from the CE devices. These are usually carried out in BGP.

Note:

However, with an MPLS network, we have MPLS forwarding between the loopbacks. Notice the diagram below. The loopback addresses 2.2.2.2/32 and 4.4.4.4/32 belong to the PE nodes. The P node is entirely unaware of any BGP routing.

Knowledge Check: IntServ and RSVP

Quality of Service (QoS) can be measured in three ways:

• Best Effort (don’t use QoS for traffic that doesn’t need special treatment.)

• DiffServ (Differentiated Services)

• IntServ (Integrated Services)

DiffServ implements QoS by classifying IP packets based on their ToS byte or hop by hop. INTSERV is entirely different; it’s a signaling process where network flows can request a specific bandwidth and delay. RFC 1633 describes two components of IntServ:

• Resource reservation

• Admission control

Reserved resources notify the network that a certain amount of bandwidth and delay is needed for a particular flow. When the reservation is successful, a network component (primarily routers) reserves bandwidth and delay. Reservations are permitted or denied by admission control. We cannot guarantee any service without allowing all flows to make reservations.

RSVP path messages are used when a host requests a reservation. This message is passed along the route on the way to the destination. A router will forward a message when it can guarantee the bandwidth/delay required. An RSVP resv message will be sent once it reaches the destination. In the opposite direction, the same process will occur. Upon receiving the reservation message from the host, each router will check if it has enough bandwidth/delay for the flow and forward it to the source of the reservation.

While this might sound nice, IntServ is challenging to scale…each router must keep track of each reservation for each flow. Is there a problem if a particular router does not support Intserv or its reservation information is lost? We primarily use RSVP for MPLS traffic engineering and DiffServ for QoS implementations.

Traffic Engineering: Inbound and Outbound

Before you can understand how to use MPLS to do traffic engineering, you must understand what traffic engineering is. So, we have network engineering that manipulates your network to suit your traffic. You make the most reasonable predictions about how traffic will flow across your network and then order the right components.

Then we have traffic engineering. Network traffic engineering is manipulating traffic to fit your network. Traffic engineering is not MPLS-specific but a general practice among all networking and security technologies. It could be a simple or complex implementation. Something as simple as tweaking IP metrics on the interface can be implemented in its simplest form for traffic engineering. Then, we have traffic engineering specific to MPLS.

2nd Lab Guide: MPLS TE

In this lab, we will examine MPLS TE with ISIS configuration. Our MPLS core network consists of PE1, P1, P2, P3, and PE2 routers. The CE1 and CE2 routers use regular IP routing. All routers are configured to use IS-IS L2. 

Tip: There are four main items we have to configure:

• Enable MPLS TE support:
  • Globally
  • Interfaces
• Configure IS-IS to support MPLS TE.
• Configure RSVP.
• Configure a tunnel interface.

Understanding MPLS and MPLS forwarding

MPLS is the de facto technology for service provider WAN networks. Its scalable architecture moves complexity and decision-making to the network’s edges, leaving the core to label switch packets efficiently. The PE nodes sit at the edge and perform path calculations and encapsulations. The P nodes sit in the core and label switch packets. They only perform MPLS switching and have no visibility of customer routes.

Edge MPLS routers map incoming packets into forwarding equivalence classes (FEC) and use a different label-switched path (LSP) for each forwarding class. Keeping the network core simple enables scalable network designs. Many of today’s control planes encompass a distributed architecture and can make forwarding decisions independently.

MPLS control plane still needs a distributed IGP (OSPF and ISIS) to run in the core and a distributed label allocation protocol (LDP) to label packets. Still, it shifted how we think of control planes and distributed architectures. MPLS reduced the challenges of some early control plane approaches but proposes challenges by not having central visibility, especially for traffic engineering (TE).

Example Technology: DMVPN Phase 3 Traffic Manipulation

DMVPN Phase 3 is the third and final phase of a Dynamic Multipoint Virtual Private Network DMVPN setup. This phase is focused on implementing the DMVPN tunnel and enabling dynamic routing. The tunnel is built between multiple network points, allowing communication between them.

In DMVPN Phase 1, the spoke devices rely on the configured tunnel destination to identify where to send the encapsulated packets. Phase 3 DMVPN uses mGRE tunnels and depends on NHRP redirect and resolution request messages to determine the NBMA addresses for destination networks.

Packets flow through the hub in a traditional hub-and-spoke manner until the spoke-to-spoke tunnel has been established in both directions. Then, as packets flow across the hub, the hub engages NHRP redirection to find a more optimal path with spoke-to-spoke tunnels.

NHRP Routing Table Manipulation

NHRP tightly interacts with the routing/forwarding tables and installs or modifies routes in the Routing Information Base (RIB), also known as the routing table, as necessary. If an entry exists with an exact match for the network and prefix length, NHRP overrides the existing next hop with a shortcut. The original protocol is still responsible for the prefix, but the percent sign (%) indicates overwritten next-hop addresses in the routing table.

3rd Lab Guide: DMVPN Phase 3

The following example shows DMVPN Phase 3 running on the network.

DMVPN Phase 3 is the latest iteration of the DMVPN technology, offering enhanced scalability and flexibility compared to its predecessors. It builds upon the foundation of Phase 1 and Phase 2, incorporating improvements that address the limitations of these earlier versions.

One of the critical features of DMVPN Phase 3 is the addition of a hub-and-spoke network topology. This allows for a centralized hub connecting multiple remote spokes, creating a dynamic and efficient network infrastructure. The hub is a central point for all spokes, enabling secure communication. In our case below, R11 is the hub, and R31 and R41 are the spokes.

Note:

Once the hub site receives traffic indicating spoke to spoke traffic, it sends back a “Traffic Indication” message. Notice the output from the debug command below. Via NHRP, the spoke knows a better path to reach the other spoke, not via the hub. The spoke then proceeds to build spoke-to-spoke tunnels.

Network Traffic Engineering and MPLS 

MPLS was very successful, and significant service provider networks could support many customers by employing MPLS-style architecture. End-to-end Label Switch Paths (LSP) are extended to interconnect multiple MPLS service providers, route reflectors, and BGP confederations for large-scale deployments and complexity reduction.

However, no matter how scalable the MPLS architecture could be, you can’t escape the fact that Inter-DC circuit upgrades are time-consuming and expensive. To help alleviate this, MPLS providers introduced MPLS Traffic engineering (TE). TE moves traffic to other parts of the network to underutilized sections.

While simple TE can be done with IGP metrics, they don’t satisfy unique traffic class requirements. Therefore, provider networks commonly deploy MPLS RSVP/ TE. This type of TE enhances IGP metric tuning, allowing engineers to forward core traffic over non-shortest paths. The non-shorted path is used to avoid network “hot spots.” Since the traffic is now moved to other underutilized network parts, it prevents the lengthy process of upgrading congested core links. MPLS TE distributes traffic optimally across a network. “MPLS RSVP/ TE is a widely adopted and well-defined technology. Can SDN and OpenFlow do a better job?”

Holistic visibility – Controller-based networking

MPLS/TE is a distributed architecture. There is no real-time global view of the end-to-end network path. The lack of a global view may induce incorrect traffic engineering decisions, lack of predictability, and deterministic scheduling of LSPs.

Some tools work with MPLS TE to create a holistic view, but they are usually expensive and do not offer a “real-time” picture. They often make an offline topology. They also don’t change the fact that MPLS is a distributed architecture.

The significant advantage of a centralized SDN and OpenFlow framework, commonly called MPLS OpenFlow, is that you have a holistic view of the network, controller-based networking. The centralized software sits on the controllers, analyzing and controlling the production network forwarding paths. It has a real-time network view and gains insights into various network analytics about link congestion, delay, latency, drops, and other performance metrics.

MPLS OpenFlow can push down rules to the nodes per-flow basis, offering a granular approach to TE. The traditional TE mechanism is challenging in achieving a per-flow TE state. OpenFlow’s finer granularity is also evident in service insertion use cases. In addition, OpenFlow 1.4 supports better statistics that give you visibility into application performance.

This metric and a central viewpoint can only enhance traffic engineering decisions. Let’s face it: MPLS RSVP/TE, while widely deployed, involves several control plane protocols. All these protocols need to interact and work together.

The OpenFlow MPLS protocol steers traffic over MPLS using OpenFlow.

You can direct traffic from OpenFlow networks over MPLS LSP tunnel cross-connects and logical tunnel interfaces. By stitching OpenFlow interfaces to MPLS label-switched paths (LSPs), you can direct OpenFlow traffic onto MPLS networks. In addition, through MPLS LSP tunnel cross-connects between interfaces and LSPs, you can connect the OpenFlow network to a remote network by creating MPLS tunnels that use LSPs as conduits.

Network state vs. Centralized end-to-end visibility

RSVP requires that some state is stored on the Label Switch Router (LSR). The state is always bad for a network and imposes control plane scalability concerns. The network state is also a target for attack. Hierarchical RSVP was established to combat the state problem, but in my opinion, it adds to network complexity. All these kludges become an operational nightmare and require skilled staff to design, implement, and troubleshoot.

Removing MPLS signaling protocols from the network and the state they need to maintain eliminates some of the scale concerns with MPLS TE. Distributed control planes must maintain many tables and neighbor relationships (LSDB and TED). They all add to network complexity.

Predictable and deterministic TE solution

Using SDN and OpenFlow for traffic engineering provides a more predictable and deterministic TE solution. By informing the OpenFlow controller that you want the traffic redirected toward a specific MAC address, the necessary forwarding entries are programmed and automatically appear across the path. NETCONF and MPLS-TP are possibilities, but they operationally cause problems and don’t alleviate the distributed signaling protocols.

Having a central controller view, the contents of the network allow for particular network touchpoints. New features are implemented in the software and pushed down to the individual nodes. Similar to all SDN architectures, fewer network touchpoints increase network agility. The box-by-box and manual culture is slowly disappearing.

Challenges and Future Trends

Network traffic engineering faces several challenges, including ever-increasing data volumes, evolving network architectures, and the rise of new technologies such as cloud computing and the Internet of Things (IoT). However, emerging trends like Software-Defined Networking (SDN) and Artificial Intelligence (AI) are promising to address these challenges and optimize network traffic.