The SPCOR exam domain 'Implement segment routing traffic engineering and policies' is about taking network control to the next level. This chapter reveals how you become the master of your network's traffic, ensuring critical data like video calls or bank transactions always takes the best, fastest route instead of getting stuck in digital traffic jams. For the 350-501 exam, understanding Segment Routing Traffic Engineering is essential because it's the modern, scalable method to guarantee performance and reliability in large service provider networks.
Jump to a section
A simple way to picture Segment Routing Traffic Engineering
Have you ever been stuck in traffic on a motorway while a single, empty lane is reserved for buses and taxis that barely use it? That reserved lane is a form of traffic engineering — you're guaranteeing a certain path for certain vehicles, regardless of the overall congestion. Now, imagine you're a delivery company with a fleet of vans. Instead of letting each van find its own way through the city (which could be chaos), you pre-programme a specific route for each van, complete with a list of precise turn-by-turn instructions: "Turn left at the third set of lights, then drive 2 miles, then take the second exit at the roundabout." That list of instructions is exactly what a Segment Routing Traffic Engineering (SR-TE) policy is.
In our IT world, the vans are data packets, the city is the network, and the turn-by-turn instructions are 'segments' — specific labels that tell the packet exactly which routers to visit along the way. The magic is that you, the network engineer, can decide the exact path a particular type of traffic will take, even if it's not the shortest path. This is like telling your van to take the scenic route past the warehouse because the direct road is under construction, and you want to avoid delays. The network doesn't guess; it follows your pre-planned 'roadbook' (the SR-TE policy). This gives you total control over traffic flow, which is crucial for things like video calls where you can't afford delays or packet loss.
Let's start with a clear picture of the problem. In older network technologies, like traditional MPLS (Multiprotocol Label Switching — a way to label and forward packets efficiently), traffic often took the shortest path automatically. This is like everyone taking the same bridge to work — it gets congested quickly, and there's no way to convince some cars to take a longer but emptier bridge. Traffic Engineering (TE) was invented to solve this: it lets you calculate and force traffic onto specific, non-shortest paths to balance the load. However, the old method for doing this (using something called RSVP-TE, or Resource Reservation Protocol — Traffic Engineering) was complex and hard to scale, like trying to coordinate every car's route with a radio call from a central controller.
Segment Routing (SR) is a simpler, more elegant approach. Instead of a central controller telling every router what to do, SR encodes the entire path directly into the data packet itself. Think of it like giving a parcel a delivery route written on its label: "First go to Manchester, then to Birmingham, then to London." The packet carries its own 'segments' — a sequential list of instructions. In MPLS terms, these instructions are labels (short numbers, like a zip code for a router).
Segment Routing Traffic Engineering (SR-TE) takes this idea and adds a 'policy'. An SR-TE policy is like a permanent, pre-defined route plan for a specific type of traffic. It says: "All traffic for this important video conferencing service must follow this exact list of segments (labels) from one end of the network to the other." This policy is defined on a router called the 'head-end' (the starting point). The head-end then steers the traffic by 'pushing' (adding) the correct list of segment labels onto each packet that matches the policy.
How does the head-end know which path to use? It uses a sort of 'brain' called the Path Computation Element (PCE). The PCE is like a GPS for the network — it knows the current state of all links (the roads), their bandwidth (how many lanes), and their latency (how long data takes to travel). When a head-end router needs to set up an SR-TE policy, it can ask the PCE: "What's the best path from here to New York for my video traffic that must have less than 10 milliseconds latency?" The PCE calculates the route and sends back the list of segments. Alternatively, the head-end can calculate the path itself if it has enough information (this is called 'local computation').
There are two main flavours of Segment Routing: SR-MPLS (which uses MPLS labels for segments) and SRv6 (which uses IPv6 addresses — the newer version of IP addresses — to identify segments). The 350-501 exam focuses heavily on SR-MPLS, so we'll stick with that. The key component here is the 'label stack'. Normal MPLS packets carry one label, but an SR-TE packet carries a stack of multiple labels, each representing a segment or instruction. As the packet travels, each router 'pops' (removes) its own label and reads the next one, like crossing off items from a shopping list.
The benefits of SR-TE over older TE methods are huge:
Scalability: Because the path is in the packet itself, intermediate routers don't need to maintain state information about every single path. They just forward based on the top label. This is like the difference between a postman who memorises every delivery route (old method) vs. one who just reads the address on each letter (SR). The latter is much easier to manage.
Flexibility: You can change a path instantly by updating the policy at the head-end, without touching every router in the middle.
Fast Failure Recovery: SR-TE can use techniques like 'Fast Reroute' (FRR), where a backup path is pre-calculated and ready to use instantly if a link or router fails — like having a pre-programmed detour in your GPS.
In summary, SR-TE works by defining a list of segments (instructions) for a packet to follow, using a policy at the head-end router. The PCE helps compute the optimal path. The packet then executes this list as it travels, without any router needing to remember the entire journey. It's a powerful, scalable way to guarantee the quality of service critical applications demand.
Identify the Traffic to Engineer
First, you define which traffic needs special treatment. This is done by configuring a 'class-map' or a forwarding policy on the head-end router. For example, you might match packets with a specific destination IP address range (the video server) and a specific port number (for voice or video). This step is crucial because you don't want to engineer all traffic — just the high-value streams that need guaranteed performance.
Define the SR-TE Policy with Constraints
Next, you create the SR-TE policy itself on the head-end router. Here you specify the 'constraints' or the desired characteristics of the path. You can set a target latency (e.g., 50ms), a minimum bandwidth (e.g., 10 Gbps), and an affinity/colour (e.g., 'low-latency' or 'gold'). This policy is like a job description: 'Find me a path that meets these requirements.'
Path Computation (via PCE or Local)
The head-end router now needs to find a path that satisfies the policy's constraints. It can do this in two ways: (a) ask the central Path Computation Element (PCE) server, which has a full network map and calculates the optimal path, or (b) compute the path locally using its own link-state database (if it has enough information). The result is a 'segment list' — an ordered list of MPLS labels representing each hop in the path.
Install the Candidate Path and Activate
The computed path is stored as a 'candidate path' within the SR-TE policy. The head-end router then makes one of these candidate paths 'active'. It does this by installing the associated segment list (label stack) into its forwarding table. Now, when a packet matching the traffic classifier arrives, the head-end router will 'push' that exact label stack onto the packet and send it on its way.
Forwarding Along the Explicit Path
As the packet travels through the network, each intermediate router looks at the top label on the stack. The router performs a 'pop' (removes its own label), looks at the next label, and forwards the packet accordingly. It follows the predetermined 'turn-by-turn' instructions embedded in the packet. The packet eventually reaches the 'tail-end' router, which removes the final label and forwards the original packet to its destination.
Monitor, Re-optimise, and Handle Failure
The final ongoing step is monitoring. Using tools like SNMP or NETCONF, you track the health of the path. If the active path degrades (e.g., latency increases), you can either manually trigger a switch to a backup candidate path or automate the process with the PCE, which can dynamically re-optimise the path. In case of a sudden link failure, the network relies on TI-LFA to reroute traffic within milliseconds, followed later by a PCE-based re-optimisation.
You're a network engineer for a major service provider called 'GlobalNet'. One of your biggest customers is a streaming service called 'VideoMax', which operates a live sports feed. VideoMax demands a guaranteed 50-millisecond latency, zero packet loss, and 10 gigabits per second of bandwidth from their main data centre in London to their delivery point in Manchester. The normal shortest path between these two points is via a heavily congested link through Birmingham. Traditional routing would send all traffic that way, causing video buffering and customer complaints.
Here is exactly what you, the engineer, would do to solve this with SR-TE:
Define the Traffic: First, you identify the traffic that needs special treatment. You create a 'traffic classifier' — a rule that says: "Any packet with a destination IP address belonging to VideoMax and a port number for streaming video (e.g., UDP port 443) is to be handled specially." This is like putting a 'VIP' sticker on certain packages.
Create the SR-TE Policy: You log into the head-end router (the router in London closest to VideoMax's servers) and create a new SR-TE policy. You give it a name, say 'VIDEOMAX-MANCHESTER-GOLD'. You then specify the path characteristics: the desired latency (50ms), bandwidth (10 Gbps), and a colour (a flexible attribute that can mean anything, like 'low-latency'). This policy doesn't define the exact path yet; it states the requirements.
Ask the PCE for the Path: The head-end router then sends a request to the network's PCE, a centralised server that has a real-time map of the entire network. The request says: "I need a path from London to Manchester with the colour 'low-latency' and 10 Gbps of free bandwidth." The PCE runs its algorithms, avoiding the congested Birmingham link, and calculates a path that goes: London -> Luton -> Leicester -> Manchester. The PCE responds with the exact list of segment labels for that path.
Apply the Policy: The head-end router receives the segment list from the PCE and binds it to the 'VIDEOMAX-MANCHESTER-GOLD' policy. Now, every time a packet from VideoMax arrives at the London router that matches the classifier, the router 'pushes' (adds) the stack of segment labels (the path from the PCE) onto the packet. The packet now contains the turn-by-turn instructions.
Monitor and React: You set up network monitoring tools (like SNMP or NetFlow) to watch the performance of this specific SR-TE path. You see that the latency is a steady 45ms — perfect. Months later, you get an alert: the Leicester link is experiencing heavy jitter (variation in delay). You log back into the head-end router and update the policy to ask the PCE for a new path. The PCE recalculates and proposes: London -> Luton -> Sheffield -> Manchester. You accept. You can do this dynamically without any downtime for the customer, using a tool like Path Computation Element Protocol (PCEP) to automate the re-optimisation.
This is a far cry from the old days of manually configuring every router on the path or using complex RSVP-TE tunnels that required state on every box. With SR-TE, you have a single point of control, intelligent path computation, and the traffic follows your instructions precisely.
The 350-501 exam will test your understanding of SR-TE as a distinct, modern alternative to RSVP-TE. Expect multiple-choice and drag-and-drop questions that require you to identify the correct components, protocols, and behaviours. Here is what they love to test and the traps they set:
SR-TE vs. RSVP-TE: This is a classic comparison question. The exam will present a list of characteristics and ask you to identify which belong to SR-TE vs. RSVP-TE. Trap: They might say 'Requires state on every intermediate router' — that is RSVP-TE, not SR-TE. Correct pattern: SR-TE is 'stateful at the head-end only', 'uses a label stack', 'works with PCE', 'does not use RSVP signalling'. Memorise the key distinctions.
The Role of the PCE: Questions will test whether the PCE is a client or a server, and how it communicates with the head-end router. Trap: They might claim the PCE pushes the label stack onto packets. Wrong — the PCE just gives the path; the head-end router pushes the labels. Correct pattern: The PCE is a server, the head-end is a client (PCC — Path Computation Client). They use the PCEP protocol.
Candidate Paths vs. Active Path: A single SR-TE policy can have multiple pre-computed paths called 'candidate paths'. Only one is active at a time. Exam traps: They might ask how many paths an SR-TE policy can have. Answer: More than one, but only one is active. They might ask what happens if the active path fails. Answer: The router instantly switches to a pre-programmed backup candidate path (if configured).
Co-lour and the 'Flexible Algorithm': The 'colour' attribute in an SR-TE policy is used to select a specific path type. The exam introduces the concept of a 'Flexible Algorithm', a custom way to define path constraints (e.g., minimise latency, minimise hop count). Trap: They might test that 'colour' is the same as 'Flexible Algorithm'. Not exactly — the colour is a tag used to steer traffic to a path computed by a particular Flexible Algorithm. Correct pattern: A Flexible Algorithm defines a 'plan' (e.g., 'minimise latency'), while the 'colour' is the 'marker' that tells the router to use that plan.
SR-MPLS vs. SRv6: You must know the difference. SR-MPLS uses 20-bit labels, while SRv6 uses 128-bit IPv6 addresses as segments. Trap: They might ask which one requires fewer resources to process. Answer: SR-MPLS generally has lower overhead because labels have fixed processing, but SRv6 allows for more services within the packet itself. For the exam, focus on SR-MPLS specifics.
Failure Protection (TI-LFA): Questions will test how SR-TE handles link or node failure. The key concept is Topology Independent Loop-Free Alternate (TI-LFA). Trap: They might claim SR-TE relies on fast IGP convergence to fix failures (slow!). Correct pattern: TI-LFA provides sub-50ms protection against any single failure by pre-computing a backup segment list for the protecting router, independent of the network topology.
Key definitions to memorise: - Head-end: The router that steers traffic into the SR-TE tunnel. - Tail-end: The router where the tunnel ends. - Segment List (SID-List): The ordered list of segment identifiers (labels) defining the path. - Candidate Path: A single specific path for the SR-TE policy (e.g., Path A, Path B). - Binding SID (BSID): A label that represents the entire SR-TE policy. It simplifies things so other routers just need to push one BSID label instead of the whole stack.
The exam loves to ask: "Which component..." and "What is the benefit of..." For every SR-TE feature (like PCE, BSID, Flexible Algorithm), be ready to state its single most important benefit (e.g., BSID = reduces label stack size, Flexible Algorithm = custom path computation).
SR-TE gives you the power to force network traffic onto a specific pre-determined path rather than letting it follow the shortest (and potentially congested) route.
A PCE acts like a GPS for the network, calculating the ideal path based on constraints like latency and bandwidth, and sends the path's instructions (a list of segment labels) to the head-end router.
The head-end router is the only router that needs to know the full SR-TE path; intermediate routers just follow the instructions encoded in the packet's label stack, making SR-TE highly scalable.
An SR-TE policy can have multiple 'candidate paths' (backup routes), but only one is active at any time, switching instantly to a backup if the active path fails.
TI-LFA provides sub-50ms failure protection in an SR-TE network, allowing fast reroute around a failed link or router without needing a central controller to intervene.
The Binding SID (BSID) is a single label that represents an entire SR-TE policy, simplifying the label stack so other routers can steer traffic into the tunnel with just one label instead of a long list.
Colour and Flexible Algorithm work together: the colour is a tag that selects a specific path, and the Flexible Algorithm defines the rules for how that path is computed (e.g., minimise latency).
These come up on the exam all the time. Here's how to tell them apart.
SR-TE with PCE (Centralised)
Requires a dedicated PCE server for path calculation
Provides optimal paths using a global view of the whole network
Scalable for very large networks with many paths
SR-TE without PCE (Local)
Head-end router calculates path itself using local database
May result in sub-optimal paths because it lacks full global view
Simpler to set up for small networks but less scalable
SR-TE (Segment Routing Traffic Engineering)
Path encoded in the packet as a label stack (stateless middle routers)
Uses a PCE or local calculation; no signalling protocol needed
Highly scalable; intermediate routers do not maintain path state
RSVP-TE (Traditional Traffic Engineering)
Path signalled via RSVP protocol; every router stores state
Requires complex signalling and refreshing of paths
Less scalable; state must be refreshed in every router on path
Active Candidate Path
The path currently used to forward traffic
Has the highest preference among the policy's candidate paths
Monitored for performance, with instant failover to backup if it fails
Backup (Standby) Candidate Path
A pre-computed alternative path ready to be used
Has a lower preference than the active path
Activated immediately (sub-50ms) if the active path fails, using local repair logic
Mistake
Segment Routing Traffic Engineering is just a new name for regular MPLS.
Correct
Regular MPLS uses a single label for forwarding (like a postcode) and relies on routing protocols to find paths. SR-TE explicitly defines the entire path using a stack of multiple labels (like a turn-by-turn list), giving you much finer control over which routes traffic takes.
Both SR-MPLS and traditional MPLS use 'labels', so beginners assume they're the same. They miss the critical difference: SR-TE puts the path 'in the packet' rather than 'in the network'.
Mistake
The Path Computation Element (PCE) actually pushes labels onto the packets.
Correct
The PCE is a server that calculates a path and sends the labels to the head-end router. The head-end router is the one that pushes (attaches) the label stack onto the actual data packets. The PCE doesn't touch the data traffic.
The term 'Path Computation Element' sounds like it does everything. People confuse the role of a calculator (PCE) with the role of the builder (head-end router) that applies the result.
Mistake
Segment Routing (SR) and Segment Routing Traffic Engineering (SR-TE) are the same thing.
Correct
Segment Routing (SR) is the core technology that allows a packet to carry a list of segments. SR-TE is a specific application of SR that uses a 'policy' (a defined set of rules and a pre-computed path) to steer traffic for a specific purpose, like guaranteeing bandwidth. You can have SR without SR-TE.
The term 'Segment Routing' is often used as an umbrella term. Beginners don't realise that SR-TE is an advanced feature built on top of basic SR, much like how a GPS navigation system (SR-TE) is built on top of basic road signs (SR).
Mistake
An SR-TE policy always uses the shortest path computed by IP routing.
Correct
An SR-TE policy is specifically designed to use a path that is NOT necessarily the shortest (IGP) path. The whole point of traffic engineering is to avoid congested shortest paths and use alternative, less-congested routes, even if they are physically longer.
Beginners are taught that routing protocols like OSPF find the 'best' path, which usually means the shortest. They assume all paths must be mathematically 'best'. They don't grasp that a slightly longer, empty path can be better for performance than a short, congested one.
Mistake
If a link fails, SR-TE cannot recover unless the PCE calculates a new path.
Correct
SR-TE can recover in under 50 milliseconds using Topology Independent Loop-Free Alternate (TI-LFA), a technique where a pre-computed backup label stack is installed on the router. The PCE is then used later for optimal re-optimisation, but the immediate failover is automatic and local.
People think that since the PCE calculates the path, it is also responsible for recovery. They don't understand that routers have their own local fast-failover logic that operates before the PCE even knows there's a problem.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Segment Routing (SR) is the core technology that lets a packet carry a list of instructions (segments/labels). SR-TE is a feature built on top of SR that uses a 'policy' to force traffic onto a specific path for reasons like load balancing or latency guarantees.
No, it is optional. A head-end router can compute the path locally using its own with its link-state protocol (like OSPF/IS-IS). However, using a PCE is recommended for complex networks because it provides a global view and more optimal path calculations.
The 'colour' is a user-defined attribute (a number or name) attached to an SR-TE policy. It is used to select a specific path computation strategy, often linked to a 'Flexible Algorithm'. For example, traffic with colour '10' might take the path that minimises latency, while colour '20' might take the shortest path.
SR-TE uses a technique called Topology Independent Loop-Free Alternate (TI-LFA) which pre-calculates a backup segment list on the router protecting the failed link. This allows for sub-50ms failover, avoiding packet loss while the PCE (if used) later computes a new optimal path.
A Binding SID is a single MPLS label that represents an entire SR-TE policy. Instead of pushing a long stack of labels onto every packet, a router can push just one BSID label. The first router in the path recognises the BSID and expands it into the full label stack, simplifying network operations.
A candidate path is one of the possible routes defined for an SR-TE policy. A policy can have multiple candidate paths (for redundancy or different preferences), but only one is 'active' and used to steer traffic at any given time. The others are standby backups.
You've finished Segment Routing Traffic Engineering. Continue through the 350-501 study guide to build a complete picture of the exam.
Done with this chapter?