SR-MPLS and the Optical Network

Segment Routing + MPLS (SR-MPLS) is changing how we think about transport network design, specifically the optical layer. It enables the ability to move critical functions of the optical network into the routed network. SR-MPLS is the software piece that allows optical and routing to coexist in one platform. "Converging" optical with routing, where the router assumes these critical roles, is known as "hop-by-hop" or the Routed Optical Network (RON) architecture.

SR-MPLS is a more robust and programmable version of MPLS. SR-MPLS provides a practical way to move the ROADM (reconfigurable add-drop multiplexer) functions of the optical network into the routed network. Specifically, path steering and path protection. This article focuses on SR-MPLS; if you would like to learn more about the architecture or hardware first, please check out these articles: Is Hop-by-Hop the Future of Optical Transport Networking ? and 400g-ZR and-ZR+: The Latest in Pluggable Coherent DWDM.

So, what exactly does SR-MPLS provide that traditional MPLS does not? Read on to find out.

SR-MPLS, a more intelligent MPLS

MPLS (Multi-Protocol Label Switching) has been in use worldwide for 20+ years by service providers, enterprises, government agencies, and more. Traditionally used in the core, extending the MPLS network to aggregation and even the edge of the network is becoming common. It provides a platform for service delivery with features that are not possible with IP routing alone, such as L2 and L3 VPNs, Pseudo Wires (TDM over IP), Fast Reroute, and Traffic Engineering. 

MPLS, the name says it all; it transports packets regardless of protocol (multi-Protocol) using labels (Label Switching) to move packets through the network. MPLS encapsulates incoming packets by applying a label to the packet's header; each router in the MPLS domain looks at the MPLS label to know what to do with each packet. Routers in the MPLS domain (known as "provider" or "P" routers) do not look at or care about what's in the packet; all it cares about is the label. When the packet exits the MPLS domain, the label is removed, and standard IP routing takes over. 

Traditional MPLS is excellent for efficiently moving traffic through the network while providing a host of services. It falls short when you want granular control of the path(s) the traffic takes and the paths that offer protection. Control of the packet's path, known as "Traffic Engineering," is possible with traditional MPLS utilizing the RSVP protocol (RSVP-TE), but it is very complicated to design, configure, and maintain; so much so, few operators have chosen to use it. That's why the optical network remains the de facto layer for path selection, path diversity, and path protection. 

SR-MPLS operates differently from traditional MPLS because it is powered by a Path Computation Engine (PCE). The PCE controls path selection and traffic engineering making each packet's path through the network completely programmable. SR-MPLS is based on the concept of "source routing." It calculates and programs the path of the packet to its destination at the first router, known as the "headend" or "source router." Path computation is either performed by the headend router or by an external PCE device that enables advanced traffic engineering options. 

With SR-MPLS, each router is aware of the entire network topology, and labels, known as Segment Identifiers (SIDs), are static, programmable, and persist throughout the SR-MPLS domain. The SR-TE process is responsible for collecting the topology and SID information from the underlying routing protocol (OSPF or ISIS) and storing it in the SR-TE database (SR-TE DB). There is no concept of a tunnel in SR-MPLS; instead, "policies" are created that utilize a list of SIDs (programmed instructions) to instruct packets where to go. The headend router or PCE uses the SR-TE DB and policy information to calculate paths and populate the packet forwarding table. 

SR-MPLS in action

When an unlabeled IP packet enters the SR-MPLS network, the router receiving it (the "source router") knows every possible path to the packet's destination. The SR-MPLS source router uses that information to compile a list of instructions (known as a SID list) that will guide the packet to its destination. The source router attaches the SID list to the packet and then forwards the packet out. As the packet traverses the network, each router references the packet's SID list to find out exactly what to do with it.

The two images below are the same topology; a workstation on the left is sending packets to the server on the right with the address 10.10.10.10. The first image shows an example of traditional MPLS label assignments used to reach 10.10.10.10 from R1; it's a wild guess considering the labels are randomly generated. The second image shows SR-MPLS label (SID) assignments used to reach 10.10.10.10 from the workstation connected to R1. I am showing the traditional MPLS network labeling for contrast, but we will not go into the details; we will focus on the SR-MPLS functionality instead. 

At first glance, what do you notice? That's right; the SR-MPLS example has only one SID (label) used for each hop, whereas the traditional version has four different labels, a different label for each hop. SR-MPLS SIDs are not randomly generated; you assign them. Notice the 1600x number associated with each router. Every router gets configured with a unique SID; every router knows each other's SID and how to reach them. 

In our example, the workstation connected to R1 needs to reach the server at 10.10.10.10 connected to R4. R1 knows the 10.10.10.x network is connected to R4; therefore, R1 knows it needs to send the packet to R4. R1 also knows R4's SID is 16004, so it applies the label 16004 to the packet and forwards it. Because we have multiple paths without traffic engineering (yet) and both paths have equal cost (three hops between R1 and R3), the traffic is load-balanced across both paths using equal-cost multi-path (ECMP). When R2 and R5 receive a packet with a 16004 label, they know the packet's destination is R4, R4's SID is 16004, so they forward the packet with 16004 as the SID. The same goes for R3 and R6, but just like traditional MPLS, the second to last router(s) remove (pop) the label before sending it to R4. R4 receives the unlabeled packet, treats it as a standard IP packet, and forwards it to the server at 10.10.10.10. 

If you want to go deeper into how SR-MPLS works, check out our SR-MPLS lab geared towards optical engineers but applicable to anyone who wants to learn more. It takes you through the process of building an SR-MPLS network from scratch and provides detailed explanations of what each step is and what they accomplish. 

SR-MPLS traffic engineering and path protection

Based on the same topology, let's say we want the primary traffic path as the bottom path (R1→R2→R3→R4) shown in green below and the top path (R1→R5→R6→R4) shown in purple to be the protect path. By enabling SR-MPLS-TE and using the "explicit path" function, we can specify the exact path we want the traffic to take. In our example, we would create a policy on R1 that would instruct traffic destined for 10.10.10.x to use a SID list consisting of 16002, 16003, and 16004. The packet will leave R1 with the instructions to go to R2 (16002), then R3 (16003), and finally R4 (16004).

The mechanism for providing <50ms protection switching is called TI-LFA or Topology Independent Fast Reroute. With TI-LFA, it is easy to achieve <50 millisecond failover times because TI-LFA has already calculated the "new path," or protection path, in advance. If the primary path fails, the packets instantly know where to go. In our example, since we explicitly instruct our traffic to take the green path (R1→R2→R3→R4), TI-LFA will calculate the best alternative path, known as the "post-convergence path." In our case, the only option is the purple path (R1→R5→R6→R4). That path is stored in the forwarding information base (FIB). R1 will immediately start forwarding the packets across the protect path if the primary path fails based on the instructions saved in R1's FIB.

Even though this is a basic example of SR-MPLS traffic engineering, it serves as an excellent example of path selection and path protection typically handled by the optical layer. With SR-MPLS-TE, there are unlimited traffic engineering options. For instance, you can specify two traffic flows never use the same link (diverse routes); you can "color" paths with color identifiers to steer traffic. Furthermore, the PCE can collect bandwidth and delay data from each span and then make path decisions based on those metrics. Want to go deeper into SR-MPLS-TE? No problem, we have a lab for that too; check out our SR-MPLS Traffic Engineering Lab.

Final thoughts

I hope this has provided a basic understanding of SR-MPLS and how SR-MPLS enables the routed layer to simplify the optical layer. So, does this signal the beginning of the end for ROADM based optical networks? I do not believe so. Though I do believe that router-based DWDM architectures have a significant place in transport network design and can provide simplification and cost savings for many network providers. Additionally, router-based DWDM and ROADM architectures can and should coexist in many cases because they both provide efficiencies and cost savings in their own ways. 

If you would like to learn more WWT has a team of solutions architects focused on optical and core routing architectures. We will work with you to determine the best solution to build, expand, or optimize your transport network. Please reach out to one of our contributors listed on the right or your local account team to begin working together.