MPLS TE DiffServ Aware (DS-TE) Traditional

Diffserv-Aware MPLS TE (DS-TE) is an enhancement to “regular” MPLS TE, making it QoS-aware. This allows headend routers to choose a better path for their TE tunnels.

Regular MPLS TE uses constraint-based-routing (CBR). One of the constraints is bandwidth. MPLS TE routers advertise the available bandwidth on their interfaces. This allows a headend router to use admission control when it wants to establish a new tunnel and select the best possible path.

Thanks to MPLS TE, we can send traffic down paths other than our IGP shortest path. However, there is one issue with “regular” MPLS TE. It doesn’t know and care about QoS. MPLS TE routers don’t know or care whether your packets have any DSCP or EXP markings or if there is any congestion in the network.

In this lesson, we’ll look at a before and after scenario where you’ll learn how MPLS TE DS-TE can make better decisions than regular MPLS TE.

Regular MPLS TE

Let’s look at an example. Here is our topology:

Mpls Te Diffserv Aware Topology

This service provider network uses MPLS TE on all PE and P routers. Let’s say that this SP supports regular data traffic and high-priority traffic, like VoIP. To accomplish this, the SP configures a 400 Mbps priority queue on the interfaces of all PE and P routers. This SP also uses LLQ with a 400Mbps priority queue for VoIP traffic on all interfaces.

We use Gigabit interfaces everywhere. Assuming RSVP can reserve up to the interface bandwidth, we have 1000 Mbit of bandwidth we can use for tunnel reservations:

Mpls Te Diffserv Aware All Bandwidth Available

Let’s say the PE1 router wants to establish a TE tunnel to PE2 for VoIP traffic:

Mpls Te Diffserv Aware One Tunnel

The tunnel requires 250 Mbps of bandwidth. There is enough bandwidth, so PE1 selects the shortest path through P1. This path now has 750 Mbps left. At this moment, we have no issues. Even if there is congestion, our priority queue provides 400 Mbps, while we only need 250 Mbps for tunnel one. Let’s create one more TE tunnel for VoIP traffic:

Mpls Te Diffserv Aware Two Tunnels

Since there is enough bandwidth (750 Mbps – 250 Mbps = 500 Mbps left) through the path of P1, this is the path that PE1 selects for the second tunnel. We made a reservation for 2x 250 Mbps = 500 Mbps of traffic. The SP has a 400 Mbps priority queue, so in case of congestion, this can happen:

Mpls Te Diffserv Aware Two Tunnels Congestion

We send 250 Mbps of VoIP traffic through both TE tunnels. The P1 GigabitEthernet 0/1 interface is congested. The priority queue only offers 400 Mbps, so we’ll drop packets in this queue. As a result, all voice calls suffer. PE1 didn’t do anything wrong because everything was fine on the control plane. On the data plane, however, we have an issue.

MPLS TE DS-TE Traditional

MPLS TE uses a single aggregate bandwidth known as the global pool. With DS-TE, we use the global pool and a sub-pool. The sub-pool is a share of the global pool. You can use the sub-pool for high-priority traffic like VoIP and the global pool for everything else.

You can see this sub-pool as a way to advertise bandwidth for a separate queue. For example, you can use it to advertise bandwidth for the priority queue of LLQ. When configuring a tunnel, specify whether you want to use the global pool or sub-pool. Let’s look at an example:

Mpls Te Diffserv Aware All Sub Pool Bandwidth Available

The global pool still has 1000 Mbps of bandwidth. The sub-pool has 400 Mbps and is configured to match the priority queue. Let’s see what happens when we configure tunnel one with a requirement of 250 Mbps of sub-pool bandwidth:

Mpls Te Diffserv Aware All Sub Pool One Tunnel

The sub-pool has enough available bandwidth, so PE1 makes a reservation for the shortest path through P1. This reduces the global pool and sub-pool bandwidth by 250 Mbps. Now let’s create tunnel two with 250 Mbps of sub-pool bandwidth:

Mpls Te Diffserv Aware All Sub Pool Two Tunnels Ok

The sub-pool bandwidth through P1 is insufficient for tunnel two, so PE1 looks for another path. The path through P2 and P3 has enough sub-pool bandwidth. The paths through P1 and P2 now only have 150 Mbps of sub-pool bandwidth left. If you try to create another tunnel requiring more than 150 Mbps of sub-pool bandwidth, it will be declined.

The global pool still has more than enough bandwidth. We could create another tunnel that requests global pool bandwidth. For example:

Mpls Te Diffserv Aware All Sub Pool Three Tunnels Ok

The paths through P1 and P2 have 1000 – 250 = 750 Mbps of global pool bandwidth left. P1 has the shortest path, so that’s the path we use for tunnel three.

DS-TE allows us to use a separate pool to match the bandwidth requirement of your priority queue. This works, but it has a limitation. If you have multiple traffic types, like VoIP and real-time video then you need to add both to a single priority queue. DS-TE, as explained here, is Cisco’s proprietary implementation. Nowadays, we can also use the DS-TE IETF implementation that supports multiple class types. We explain this in another lesson.

Configuration

Enough theoretical talk for now. Let’s look at how to configure MPLS DS-TE. This is the topology we’ll use:

Mpls Te Diffserv Aware Lab Topology

Routers PE1, P1, P2, P3, and PE2 run MPLS TE. Imagine that this service provider network uses a 400 Mbps priority queue for VoIP traffic on all these router interfaces.




I use IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M6, RELEASE SOFTWARE (fc1) on all routers. We’ll look at a “before” and “after” scenario so you can see why DS-TE is useful.

  • Configurations
  • CE1
  • CE2
  • P1
  • P2
  • P3
  • PE1
  • PE2

Want to take a look for yourself? Here you will find the startup configuration of each device.

Regular MPLS TE

We’ll start with regular MPLS. We use the global pool, and we don’t have any tunnels yet. Let’s check the interfaces of PE1: