Blog>>Networks>>Network infrastructure>>Centrally controlled segment routing as a kind of SDN

Centrally controlled segment routing as a kind of SDN

Network metrics like performance, reliability, and optimal resource utilization have always been important to network operators. To reach these goals, multiple technologies like MPLS, TE, or SDN, to name just a few, have been introduced over the years. Despite the existence of these solutions, vendors, together with network operators, keep working on new approaches that solve the deficiencies of existing ones. One such solution is segment routing.

This article introduces the core concepts of segment routing, highlights its benefits over typical MPLS networks, and, last but not least, explores how it fits into the SDN concept. Before getting into segment routing let's recap some of the terms used in this article.

What is MPLS, and how does it work?

Multiprotocol Label Switching is a technique for forwarding packets based on MPLS labels rather than L3 destination addresses. An MPLS label is an additional header placed between the L2 and L3 headers. Packets can have more than one MPLS label, but we'll not cover that here as it is not relevant to packet forwarding on transit nodes. Forwarding on transit nodes is based on the outermost label only. First, nodes have to learn how to forward packets. It's done by configuring label-switched paths (LSPs). LSPs can be signaled automatically using protocols like LDP or RSVP or configured by external controllers or even manually by network administrators. Once done, each node along the path has a so-called label information base, or simply LIB, filled with information on LSPs. Each entry consists of an ingress label, egress label, and egress interface. Such an entry is an instruction to the node saying, "if a packet with an ingress label is received then swap the label with the egress label and send the packet through the egress interface.” In addition to that, a route associating the L3 prefix with the LSP is added at the ingress node. The actual path packets take depends on how LSPs are signaled. For instance, LDP-signaled LSPs always follow IGP's shortest path, while other methods allow for explicit paths and traffic engineering. A sample packet walkthrough is shown in the picture below.

 A sample packet walkthrough

The MPLS architecture briefly described above, despite numerous advantages, also has some drawbacks.

  • Scaling - each node holds a forwarding state in the LIB which is proportional to the number of LSPs.
  • The need for additional signaling protocols brings some issues (e.g. LDP-IGP synchronization) and makes troubleshooting troublesome.
  • In the case of RSVP, path computation occurs in network nodes. This may become a problem in big networks with many LSPs and complex path requirements.

Explaining segment routing

Segment routing (SR) defined in RFC8402      link-icon, represents a different approach. It leverages the source routing paradigm, which means that the source/ingress router decides what path through the network packets will take. Packets are steered by adding to their headers an ordered list of forwarding instructions called segments. Each segment is identified by a segment identifier (SID). An SID is a simple integer, but how segments are encoded in packet headers depends on the data plane being used. SR can use MPLS or IPv6 as a data plane. In the case of the MPLS data plane (a.k.a SR-MPLS), an MPLS labels stack is used to encode the list of segments. In the case of the IPv6 data plane (a.k.a SR-IPv6 or SRv6), SIDs are represented by IPv6 addresses and dedicated IPv6 extension headers (SRH - segment routing header) are used for storing the list of segments. For the sake of brevity, I will focus on MPLS implementation in this article. Information about segments is advertised in the IGP link state protocol, so no additional signaling protocol is required. Both ISIS and OSPF support segment routing extensions. BGP is also possible but not so common and thus out of the scope of this article.

Main segment routing types

  • IGP-Prefix segment (Prefix-SID)
    The IGP-prefix segment is a segment attached to an IGP prefix. Prefix-SID is a global segment (more on that in a moment).  
  • IGP-Node segment (Node-SID)
    Node-SID is a segment attached to a prefix identifying a given node. It might be thought of as a Prefix-SID attached to the node's loopback interface. 
  • IGP-Anycast segment (Anycast-SID)
    Anycast-SID is a prefix segment attached to an anycast address. In other words, a few nodes advertise the same prefix with the same segment ID. 
  • Adjacency segment (Adj-SID)
    This segment identifies adjacency or a set of adjacencies to another node. If more than one adjacency to the node exists, they may be advertised with different weights allowing for weighted load balancing. Adj-SID is a local segment.
  • Binding segment (BSID)
    This segment is bound to SR policy to be used for further packet steering. SR policy defines a new segment list to be used for packet steering. A BSID may be either local or global.

Global SIDs are unique within the SR domain. Labels for global SIDs are allocated from a label space called SR Global Block (SRGB). Although each node could have a different SRGB, RFC strongly recommends using the same SRGB. Most vendors follow that recommendation and use labels 16000-23999 as an SRGB. 

Local SIDs are significant only to advertising nodes. Labels for local SIDs are allocated from a dynamic label range, so possibly the same label can be advertised from different nodes and have completely different meanings (as is common for “standard” MPLS label allocation).

Prefix segments (prefix, node, or anycast) represent the shortest path route to the related prefix. So paths consisting of prefix segments like LDP-signaled LSPs always follow the IGP shortest path. Adjacency SID represents an explicit path through the related adjacency. Paths consisting of adjacency segments or binding segments allow for traffic-engineered paths like RSVP does.

In order to send traffic, the source/ingress router must push a label stack representing a list of segments onto the packet and send the packet based on the active (topmost) segment. Each node along the path forwards the packet based on the active segment. If the segment is completed, it is removed from the stack, and the next segment becomes active and is inspected. If a segment is not completed, the packet is forwarded based on the active segment, and the active segment is not changed. 

Examples of two paths are shown in the images below. Both assume the same SRGB in all nodes and the same IGP metric for all links.

Examples of two paths are shown

In this example, the packet is routed using Node-SID. It follows the IGP shortest path.

 explicit path is enforced by Adj-SID

In this example, the explicit path is enforced by Adj-SID. To make things simpler, the above diagrams assume that PHP is not in use.Penultimate hop popping (PHP) is a process of removing the outermost label before sending it to the neighbor. PHP may be used or not depending on segment configuration.

The positive impact of segment routing on MPLS

As can be seen, segment routing solves some MPLS disadvantages:

  1. No additional signaling protocols are needed. Segments are advertised using IGP.
  2. Better scaling because the forwarding state resides only in source nodes. Other nodes hold only segments related to network topology. A similar approach has already proved its usefulness (in core-edge network architecture and service state in edge routers).
  3. The lack of path signaling simplifies protection mechanisms. Without going into the details, some protection mechanisms rely on tunnel LSPs that require targeted LDP sessions to be set up. In the case of segment routing, they are not needed, simply pushing additional labels on the label stack does the job.

Advantages of segment routing

Another advantage of segment routing is that it can coexist with LDP/RSVP protocols which makes migration to segment routing easier.

SR can work standalone. In such a scenario, the control plane is distributed across ingress nodes. Each ingress node individually calculates paths. Path calculations are independent, and other network nodes are not involved, so nodes calculating the path cannot know about the current forwarding state (paths already used by other ingress nodes). In big multi-level/area networks, ingress nodes may not have complete visibility in other areas/levels. All these may lead to suboptimal path calculations and even make some traffic-engineered path calculations impossible (e.g. disjoint paths and paths with bandwidth reservation). Luckily SDN can come to the rescue here. 

A lot has been written on SDN and there is no one precise SDN definition. If you are not familiar with SDN, I encourage you to check out our other blog posts on the topic:

For the needs of this article, let's limit the SDN concept to the central controller knowing the network state and being able to configure network elements based on that state and application needs.

The idea of using a centralized controller to compute paths is not new to segment routing. Such controllers, often called path computation elements (PCE) have been used for RSVP-TE LSPs but couldn't solve the inherent RSVP scaling problem. Now with these problems addressed by the segment routing approach, PCE seems to be an even more appealing idea.

PCE controller

The main responsibility of PCE is the computation of paths and signaling them to the network nodes. In order to be able to compute paths, PCE must know the network topology. PCE can learn this by passively tapping into the IGP domain. In a multi-area network, more than one tap might be needed to get full network visibility. An alternative approach is to leverage BGP-LS. Once calculated, paths need to be communicated to the network node. An important advantage of SR is that the computed paths state doesn’t need to be configured for all participating nodes, only ingress ones. The Path Computation Element Protocol (RFC5440      link-icon), typically used for that purpose in RSVP networks, can be used for segment routing too. Appropriate extensions have been defined in RFC8664      link-icon. Other methods like NETCONF or even BGP are also possible. Equipped with additional data like traffic statistics, controllers can perform much more than simple path computation. Because controllers’ resources are not usually as limited as the resources of typical network nodes’ control cards, more sophisticated algorithms or AI can be used to deliver features far beyond the capabilities of standalone network nodes. AI seems to be the most powerful here, providing the following benefits:

  • adaptation to network changes and network self-optimization,
  • traffic pattern prediction and proactive path recomputation,
  • anomaly detection and proactive issue mitigation.

All the above proactive actions improve network performance and reliability. Their automated nature allows for a faster response to network changes and reduction of the overall operational cost.

Conclusion

In conclusion, segment routing is a very flexible and powerful paradigm. It solves some known problems of classic MPLS networks by removing the forwarding state from intermediate nodes. Together with the central controller, it combines the best of two worlds. It provides scalable networking and a powerful set of features. 

In this article, we have barely scratched the surface of segment routing’s core concepts, but SR offers much more, like Fast Reroute, egress peer engineering, and Flex Algo, to name just a few.

Here, you can check how our network professional services can help with making your business future-proof.

Włodawiec  Paweł

Paweł Włodawiec

Senior Network Engineer

Paweł Włodawiec is a senior network engineer and author on CodiLime's blog. Check out the author's articles on the blog. Read about author >

Read also

Get your project estimate

For businesses that need support in their software or network engineering projects, please fill in the form and we’ll get back to you within one business day.

For businesses that need support in their software or network engineering projects, please fill in the form and we’ll get back to you within one business day.

We guarantee 100% privacy.

Trusted by leaders:

Cisco Systems
Palo Alto Services
Equinix
Jupiter Networks
Nutanix