Segment Routing 101
In the networking world, unless you have been living under the proverbial rock, it's impossible to not have heard about Segment Routing, which in recent times has seen a lot of interest from network operators wanting to simplify and have more control over their networks. This article will provide an overview of what Segment Routing is, how it works, and what benefits it brings to the table.
What is Segment Routing?
Segment Routing is a source routing technology being developed by IETF under the SPRING (Source Packet Routing in Networking) working group. Source routing is a forwarding method where information about what path the packet should take is encoded in the packet header by the source node. The intermediate nodes use this information to forward the packet along the desired path. Contrast that with the current hop-by-hop forwarding, where each intermediate node looks at the packet’s destination address and makes an independent decision. Each node has to consider where to forward the packet based on the state of its forwarding table. Another current forwarding protocol, label switching, forwards packets along a predetermined path based on label value present in the packet header.
The dynamic forwarding capabilities from Segment Routing enables traffic engineering by providing the ability to steer traffic along desired paths, without needing any additional signaling (like LDP or RSVP) or per-flow state to be maintained in the network. This intelligence improves network efficiencies and supports Quality of Service assurance.
Segment Routing supports two forwarding plane encapsulations: MPLS (SR-MPLS) and IPv6 (SRv6). This article focuses on SR-MPLS.
How Does Segment Routing work?
Let’s start by reviewing some basic concepts related to Segment Routing. A SR-Domain is defined as a set of connected SR-capable routers. A SR-Path provides connectivity through the SR-Domain. The SR-Path is encoded as a list of one or more instructions referred to as "segments" (and hence the name "Segment Routing"). Each segment can span one or more SR-capable routers and has an identifier associated with it (Segment ID or SID).
Several different types of segments have been defined, the most prominent ones being:
- Prefix segment - Represents the IGP shortest-path between any router and a specified prefix.
- Node segment - Special case of prefix segment and is the prefix segment associated with loopback address of the router.
- Anycast segment - Specified prefix can be advertised from multiple points in the network.
- Adjacency segment - Represents an IGP adjacency between two routers.
- Binding segment - Represents tunnels through the SR-Domain. The tunnel can be another SR-Path or an LDP or RSVP-TE signaled LSP.
In SR-MPLS, every SID maps to an MPLS label. Adjacency and Binding segments have local significance and map directly to MPLS labels. Prefix and Anycast segments however have domain-wide significance. Each SR-capable node reserves a range of MPLS labels, known as SR Global Block (SRGB), and SID value is added to the start of SRGB block to arrive at the MPLS label. In SRv6, a new routing extension header called Segment Routing Header (SRH) has been defined to carry segment information in the form of a list of IPv6 addresses.
Interior Gateway Protocols (IGPs) like OSPF and IS-IS have been extended to support SR. Topology information flooded by IGPs in the IGP domain includes SR information such as SIDs and SRGB data. So each node in the IGP domain has an identical copy of the Link State Database (LSDB), containing SR information along with other IGP topology details. It also maintains a Traffic Engineering Database (TED) which augments the LSDB with TE link attributes such as available/reserved bandwidth and administrative color.
With that background, let us look at how forwarding works in a SR-MPLS network with an example. The SR-Domain below has 7 nodes (R1..R7) with node and prefix SID values as shown. IGP has flooded the link-state data across the domain so each node has information about the SIDs as part of its LSDB.
If ingress node R1 receives packet destined for R7 with no SR label stack in packet header, the packet will get forwarded to R7 along the IGP shortest-path (R1-R2-R3-R7).
Now let’s say the packet was received with SR label stack of . R1 inspect the top label which is 16005. 16005 is the node SID associated with R5 and so this instructs R1 to forward the packet along IGP shortest-path to R5 (R1-R2-R5 or R1-R4-R5). The next hop node (R2 or R4) does the same action as R1. On receiving the packet, R5 will inspect the top label which is 16005 and since it matches its node SID, it will pop the top label. There are no more labels in the stack and R5 will forward the packet to R7 along the IGP shortest-path (R5-R6-R7).
If the packet was received with SR label stack of [16006, 24067], it would inspect the top labelwhich is 16006 and since that is the node SID associated with R6, it would forward the packet along IGP shortest-path to R6 (R1-R2-R3-R6, R1-R2-R5-R6 or R1-R4-R5-R6). R6 will inspect the top label which is 16006 and since it matches it’s node SID, R6 will pop the top label and inspect the next label which is 24067. 24067 is the adjacency SID associated with R6’s adjacency with R7 so this instructs R6 to pop the label and forward the packet over its link connected to R7.
So we can see from this example that the path that the packet takes through the network can be controlled by specifying the appropriate SIDs in the SR label stack of the packet at the source.
But who decides what SID values to put in the SR label stack? This can be done by ingress source nodes themselves, or by an external PCE controller that has visibility into topology of the network. The PCE controller can acquire LSDB and TED information from the IGP domain by either directly participating in the IGP protocol or through BGP Link-State (BGP-LS) protocol. This information can then be used for path computation based on required constraints and the computed paths programmed into the ingress source nodes using PCEP or BGP Labeled-Unicast (BGP-LU) protocols.
The Benefits of Segment Routing
In traditional MPLS networks, protocols such as LDP and RSVP-TE are used to distribute labels and set up the label switched path (LSP). All network nodes need to implement these protocols and LSP creation and management requires multiple messages to be exchanged between nodes along the LSP path. The nodes also need to maintain LSP state information which is required to forward packets based on label value present in the packet header. This increases network complexity making it difficult to maintain and can cause scalability issues when large numbers of LSPs are provisioned. SR simplifies this by moving path information in the packet, thereby not requiring additional signaling protocols and per-path state to be maintained by the intermediate nodes. Also if the desired path were to change, the change can be implemented by simply adjusting the SR label stack at the ingress node instead of having to make changes to each and every node in the path.
Segment Routing at Lumina Networks
Lumina's Software-Defined Core (SD-Core) is a solution track that encompasses capabilities for the creation and management of traffic-engineered network paths and services using standards-based control protocols. It comprises a suite of applications built on top of industry-leading OpenDaylight SDN controller platform.
Our Lumina Network Resource Manager (NRM) application caters to IP/MPLS and Optical domain. NRM IP/MPLS makes extensive use of SR in conjunction with control protocols like BGP-LS for learning segment information from the network and PCEP and BGP-LU protocols for creating traffic-engineered SR paths in the IP/MPLS network.
Lumina Flow Manager (LFM) application caters to Whitebox (OpenFlow) domain. It provides a SR implementation using OpenFlow, and uses that to deliver Ethernet point-to-point (E-LINE) and point-to-multipoint (E-TREE) connectivity services on top of a network of OpenFlow based Whitebox switches.
Read more about: