SD-WAN and Traffic engineering - part 2

Posted by Sproute Networks on June 05, 2018 · 5 mins read

Welcome back! In part 1, we looked at the basics of traffic engineering in the context of source routing and BGP. In this part, we continue with how TE is implemented in other frames of reference, from MPLS to segment routing.


One can argue that MPLS networks brought traffic engineering practices to mainstream. MPLS networks are typically under one administrative control and custom-built with SLA guarantees in mind. To enforce such SLAs, end-to-end tunnels are provisioned from ingress routers (“headend”) to egress routers (“tailend”) following precise paths through the network as dictated by user and business policies [PASTE].

A typical traffic engineered network is enabled with extensions to routing protocols (ISIS-TE, OSPF-TE) that flood TE attributes of links to each other. These attributes include bandwidth, cost, metric, color, and other vendor specific tags. The “headend” builds MPLS tunnels to the “tailend” by running a modified version of the Dijkstra algorithm, called constrained shorted path first (CSPF). In simple terms, the algorithm starts by building a node database, similar to the Dijkstra algorithm. It then compares the attributes (as advertised by routing protocols) with a defined set of constraints/policies and prunes links that don’t satisfy them. Finally, it computes the shortest path on the resultant graph. The “headend” then triggers RSVP protocol to reserve the required bandwidth on each hop through that path and set up forwarding [RSVP-TE]. Depending on configured policies, either selective or all traffic is sent over the computed tunnels. Running MPLS and using label encapsulation avoids any loops in the autonomous system. The figure below describes these steps.

MPLS traffic engineering steps

Traffic demand over the TE tunnels (LSPs) may change over time. The ingress routers, very often, monitor bandwidth usage over the LSPs and trigger tunnel recomputation if substantially more or less bandwidth compared to what is currently reserved is demanded. This feature is called auto bandwidth.

Policy-based routing

Policy-based routing is a generalized term used to cover a set of (often vendor specific) techniques that classify traffic based on set policies and steer that traffic towards a configured nexthop [CISCO-PBR]. This often augments traffic engineering, for example for selecting traffic that should be forwarded over an MPLS tunnel.

Content provider networks

Internet Traffic pattern has evolved dramatically over the past decade, owing to increased demand for streaming video and use of real-time communication apps. In 2016, 10 autonomous systems served 70% of the traffic [ENOG11] and that trend continues to grow. Fun experiment: guess the website behind each of the bubbles in Internet map. Your first guess at the big bubbles is probably right!

To cater to the growing traffic demands and for better user experience, these content providers build Points of Presence (PoP) all over the world so that they can draw the user traffic to their network close to the user and keep the traffic on-net. The PoPs have multiple peerings and thus multiple exits out to the Internet. Here lies the problem statement: how does the return traffic get forwarded in the most optimal way? The optimality may depend on various criteria: least loaded exit point, closest to the user, and so on.

In 2017 SIGCOMM conference, both Google and Facebook published their respective approaches at solving this problem. Both papers (GEspresso, FBOcean) are good reads. While Google employs tunneling techniques to build precise paths through the network, Facebook relies on hop-by-hop policy-based routing to follow paths based on DSCP code points.

Segment Routing

Segment routing blends source routing paradigm we discussed earlier with MPLS forwarding model (or vanilla IPv6 with routing headers) to achieve traffic engineering. The primary motivation is to eliminate some of the configuration-intensive tasks in MPLS-TE and to run less protocols in a network with the goal of keeping the network simpler. Like source routing, each packet contains an order list of segment IDs that define the path in either a loose or strict manner. In an MPLS network, these IDs are construed as labels or an index into a node’s label space for forwarding.

Wrapping up

So there you have it! In the next post, we will focus on the why and how of traffic engineering in the context of SD-WAN.

Want to learn more about SPAN traffic engineering solutions? Go ahead and sign up for a free trial to play with the configuration templates for your business policies.

Learn more