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
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
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 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.
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 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.
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.