Take Control of the Packet Path with Segment Routing Traffic Engineering
In This Article
As networks have grown in complexity and scale, the need for a simpler and more optimized method of transmitting data has become critical.
Segment Routing leverages source routing by providing a simple, stateless mechanism to program the path a packet takes through the network in order to drive scalability and network intelligence while improving capacity utilization and reducing costs.
Segment Routing Traffic Engineering (SR-TE) takes this simplicity to a new level by incorporating a combination of centralized control and optimization with distributed intelligence.
Given Segment Routing's purpose to steer traffic or data through a network, it can be helpful to think of it like a map.
The quickest route from your home to your office might be via an expressway, but that doesn't mean it's your preferred route. There's always going to be nuance. What if there's congestion on the expressway? Or what if you're looking for a more cost-efficient way?
The same is true for networks.
Quite often it is desirable to be able to route traffic over a specified path that is different than the default highest bandwidth or shortest path through the network, which is where traditional resource reservation protocol (RSVP) Traffic Engineering was intended to be deployed.
But RSVP-TE still has a very low adoption rate, due to its difficult implementation.
- It requires intricate manual configuration.
- It is complex to maintain with its elaborate tunnel configurations.
- It relies on soft-state signaling between endpoints, which reduces the ability to scale.
SR-TE dramatically simplifies the configuration model and eliminates the soft state requirements in favor of a source packet routing model, also known as SPRING.
SPRING utilizes segment routing or SR-MPLS to program the packet path via MPLS label imposition at the source and then automatically steers the traffic through network to the desired destination.
SR-TE alleviates the pain of implementing a complex RSVP-TE tunnel model to steer traffic and utilizes a simple policy approach on top of the ability to automatically steer the traffic in conjunction with Border Gateway Protocol (BGP), a feature pioneered by Cisco typically referred to as Per Destination Automated Steering.
Automated steering is not restricted to BGP Layer 3 VPNs, but can be assigned to any BGP prefix, which utilizes the BGP color community value to tag the prefixes on the tail end router and then advertise those prefixes in BGP to the headend router.
At the headend router, there is a policy that matches on the endpoint and the color community tag that steers the traffic automatically over a dynamic or predefined path.
The path could be a dynamic, low-delay path instead of the default high-bandwidth path. Or it could be a high-bandwidth path with a bound delay or a computed path that avoids certain links or circuits that have been previously marked with an attribute, or a combination of both. The path could also be loose or strict, explicitly defined static path, based on user specified criteria. The point is the path can be determined to meet the unique desires of the organization.
All these capabilities and features are currently available in Cisco IOS-XR code.
Consider the diagram below, in which all of the links are equal cost. Under those assumptions, the least cost or shortest path from node eight to node seven is via 8-1-6-5-2-7. However, if we consider the link between six and five is a leased line and we pay based on utilization of that circuit, we may want to send traffic along either the orange or blue path instead of the default path.
With SR-TE, this is easily accomplished by:
- Tagging prefixes at node two with a BGP color community value of orange and assigning a green color community value to another set of prefixes.
- Advertise these prefixes from node two to node one via BGP. At node one there is a policy that matches on the endpoint address of node two and a color community value of either orange or green.
Performance Monitoring allows the routers to measure the real-time delay of an interface or even a complete end-to-end policy, which allows the use of a measured delay in SR-TE policies that is updated continuously and can account for underlying optical infrastructure changes.
Performance Monitoring is implemented currently in Cisco IOS-XR code and discussed in the previous article Pick Your Path: Maximize Agility with Segment Routing with Flexible Algorithm.
In addition to the BGP color community and endpoint association, Cisco has implemented a feature called On-Demand Next-Hop (ODN/AS) with Automated Steering that eliminates the need to specify the endpoint address of the router -- just the color community value. This way any BGP prefix that is received with a color community tag will automatically trigger the creation of an SR policy to route the traffic to the desired endpoint with the assigned constraints.
This simplifies policy configuration and operations and provides for even greater scale than automated steering alone.
Another very attractive feature of SR-TE is the use of a binding-SID that is associated with every SR-TE policy.
A device in the network -- be it a Linux server running Segment Routing, or another router or appliance running Segment Routing -- can send a packet to the head-end router with the label value of the binding-SID, which will cause the router to replace the binding-SID with the SID list of the associated policy and forward per the policy definition.
This allows for increased scaling of SR-TE while providing extreme flexibility along with inter-autonomous SR-TE policies so that the originating autonomous system needs no knowledge of the SR-TE policy path apart from the binding-SID value.
Per-flow ODN/AS is nearly identical to per-destination ODN/AS, with the only difference being the SR-TE policy can now match on either a Quality of Services Differentiated Services Code Point (QoS DSCP) value in the packet header or a five-tuple access control list (ACL) instead of matching on an advertised BGP community color.
This means that the traffic can be steered based on its QoS markings. For example, you can steer voice or real-time traffic along a low-delay path or video traffic along a high-bandwidth path with a bound delay by matching on DSCP or L3 attributes.
By default, SR and SR-TE are IP equal-cost multi-path routing (ECMP) aware, which is what makes Segment Routing so attractive. However, there are certain situations where this is not ideal.
If you are trying to emulate circuit networks like TDM, it is important to strictly control the path the packet takes. The diagram below illustrates a circuit-style SR policy that ensures the orange path from node one to node six and node six to node one is traversed. For TDM networks, it is imperative that the path in both directions is identical.
We do this by utilizing adjacency SIDs that are assigned to each interface and making sure these adjacency SIDs are not Topology Independent LFA (TI-LFA) protected, meaning if a link fails, the policy will not take an alternate path.
These adjacency SIDs are programmed by a centralized controller that computes the path and encodes the list of adjacency SIDs and keeps track of the bandwidth requirements to provide SLA guarantees.
For redundancy, we create an alternate path indicated by the green arrows and we monitor both paths with a liveliness detection mechanism that allows the node to fail from the orange to the green path in 10ms.
SR-TE provides many advantages over traditional shortest-path routing.
It provides complete control over the packet path from the source to the destination via both a distributed and centralized traffic engineering model.
SR-TE, in conjunction with SR-MPLS, is a very powerful method to program the packet path at the source and is constantly evolving and offering unprecedented control.