Segment Routing is a way to increase network efficiency by prepending a set of route instructions to a packet, allowing it to traverse directly to a specific destination. Much has been said about advantages and disadvantages of segment routing in the networking industry. There are the more obvious advantages like the ability to simplify the network and reduce resource utilization and reducing the number of nodes that need to be touched for path provisioning and changes but there are also many limitations. 

In this blog piece, Nicholas Buraglio, computer systems engineer on the Planning and Architecture team, discusses segment routing in scientific networks and how it can be highly beneficial. 

Segment Routing: Simplification and Advancement for Science Networks

Over the last few years, much of the networking industry has been abuzz about segment routing (SR) – a technology that seemingly straddles the line between the promised benefits of software defined networking (SDN) and the operational needs of large, complex, geographically diverse networks. Meeting that confluence of “granular control” and extreme scalability is no easy task. Add to that the prospect of simplification of a well known complex and uncommon set of controls and protocol stacks, and one starts to understand why SR is so highly desirable. 

So what is SR and what does this solution bring that makes it so desirable? In a nutshell, SR is a networking technology that combines the features of Multi Protocol Label Switching (MPLS), with the flexibility of SDN. It allows for controller augmented and source-based routing without the need for maintaining state across a network core and for seamless fallback to traditional network protocols in the case of failures. Alone, each of these attributes are very compelling, but together they make for an extremely robust solution. SR “provides more with less,” in that it requires fewer protocols to enable more and increasingly complex features. 

Setting aside the fact that as operators of boundary pushing high performance networks we are able to take advantage of more simple configuration (and therefore easier to provision and operate), SR opens up the world of SDN by offloading computationally complex tasks, such as path calculation and re-routing, but leaves behind the overhead often associated with controller-based networking technologies such as OpenFlow, which place the controller in the critical path for most control plane functions. SR controllers allow for a far more seamless transition from traditional, discreet router based networking decisions and the ability to offload tasks such as pre-calculating data paths and re-optimizing the network.   

In addition to the already lengthy list of advantages, SR also boasts a version that is derivative of the way that most large networks have been built by leveraging MPLS. This derivation makes for a significantly easier shift in operations as the day to day concepts are very similar and often well known to existing support and engineering staff. On a more technical level, SR contains many of the powerful and widely deployed features of MPLS in addition to many functional improvement and extensions, such as Traffic Engineering, used for guaranteeing bandwidth for experiments and other related functions, path engineering, robust failure protection, and compatibility with legacy protocols such as RSVP-TE. These features are especially compelling for ESnet since this allows for our OSCARS service to flourish and expand. 

Practically speaking, SR allows for complex operations on a large network, especially in the realm of traffic engineering. As an example, an intricate path from point A to point B can be calculated, provisioned, re-routed, and adjusted from an external interface that only needs to speak to a single device at the start of the requested path. For example, using the following five router topology, paths can be easily provisioned that connect resources using guaranteed bandwidth via non-default paths.   

Diagram 1: Five router topology using segment routing. Credit: Nick Buraglio.

Diagram1 shows that the red dotted line is a far longer path from System C to System D. While this may seem like a simple process, it is counter to traditional routing which would, by default, choose the direct path between router 4 and router 5. In addition to this capability, SR allows for additional criteria that is not available for consideration in the legacy protocol suites to be taken into account when building a path. Again referencing Diagram 1, we consider the blue path. Asserting the path between System A and system B is lower latency, SR allows for latency to be considered in path selection. Practically speaking this again allows for non-traditional network traffic engineering to be leveraged in order to meet a far greater variety of requirements that researchers and scientists may require.  

Want to know more about the protocols used within SR and to incorporate a Path Computation Element (PCE)? Find information on that subject and more here.