What is The Real Reason Behind IP and MPLS Traffic Engineering ?

MPLS traffic engineering has many use cases and it helps to solve the problems in an MPLS enabled networks.

These use cases are in general; QoS guarantee, End to End SLA , Fast reroute, Admission control and so on.

All of them at the end is done for the COST SAVING.

The real reason behind MPLS Traffic engineering is cost saving. This is same for the IP Traffic Engineering as well.

Sometimes as a technical people we tend to forget the real reason behind these technologies and push ourselves to make it work on the network although we could find an easier, simpler, flexible, scalable solutions since we don’t focus on the business problem.

In this article I will show you couple alternative ways for the traffic engineering and then explain why you wouldn’t need MPLS Traffic engineering for the link bandwidth utilization.


traffic engineering fish problem

Remember our good old fish topology to explain the reason behind MPLS Traffic Engineering ?

With the above picture we have been teaching the people that if the cost is the same between all routers, top path from R2 to R5 will be use because it is 3 hops, bottom path will not be used at all since it is 4 hops.

IP unicast traffic would follows the top path, since multicast follows the unicast routing table with PIM to find the Source or Rendezvous Point for its tree, IP multicast would use the same top path as well.

Then you needed to do traffic engineering to send unicast from one link from one link, multicast from the other link for the better utilization which is IP traffic engineering.

Or with Multi Topology Routing you would send IPv4 traffic from the top path by using the lower metric on the top path for the IPv4, and IPv6 traffic from the bottom path by using lower metric between the routers on the bottom path.

Another approach for the Traffic engineering is MPLS Traffic Engineering. It has an admission control capability at least at the control plane so you can reserve bandwidth thanks to RSVP-TE.

Although you can still send at the data plane more than reserve bandwidth for the LSP, admission control will not allow new LSP creation if you allocated all the bandwidth for the LSPs.

Would you really need to MPLS Traffic Engineering to solve the link utilization problem ?

Answer is unfortunately NO. If you would just assigned the metric correctly on the above FISH figure, you could get ECMP ( Equal cost Multipath ) between R2 and R4 so both TOP and BOTTOM path would be used.

In a large scale networks, finding an ECMP path between each source and destination job is done by the offline tools such as Cariden MATE.

Network design is finding an optimal solution for the given business requirements. Business wants to save cost, underutilized link is wasting money, so doing an MPLS traffic engineering might seem an attractive solution but when you have easier,simpler solution which don’t require additional protocol you would have a better network design.

The difficult task is to find those better solutions.

3 Replies to “What is The Real Reason Behind IP and MPLS Traffic Engineering ?”

  1. Hey Orhan. Interesting post. This could be used when you just want to use both links for whatever traffic is passing. But I understand that when you want to have certain specific clients IP traffic use the shorter path and the rest of the clients the longer, the simple.option could be Policy Based Forwarding. And when you want certain specific MPLS VPNs to use certain path then you should go with MPLS-TE and assign the LSP to the VPN. What do you think?

    I think I have a little bit of a hard time understanding ECMP. I do understand that, for example, OSPF calculates that there are 2 paths with the same total metric to a destination and it chooses both, so the destination address has to next-hops in the RIB. What complicates it for me is: I understand one of the 2 next-hops in the RIB is chosen as the active and gets installed in the FIB, and it is marked as the active in the “show ip route”, so anyways there is only one next-hop being used. Is there another step you have to perform in all vendors for ECMP to work? I know that in Juniper you have to configure that the forwarding table installs both next hops, and so a hash algorithm will be used to determine which next hop is used depending on the source and destination ip address, etc.

  2. good post
    I agree sometimes things get complicated or are made look complicated where we can have simple solutions but that is how the Network Architect things or prefers which boils down to be supported by the support team

    Thsi is where the KISS principle applies 😛

Leave a Reply

Your email address will not be published.