An Introduction to Segment Routing

The majority of routing protocols in use today were designed to provide best-effort and shortest-path or least-cost-path routing. For example, large chunks of internet traffic are routed this way. Even more applications today require some sort of quality assurance or ‘fastest path’ routing and, in case of network failures, a backup path needs to be ready for use instantaneously.

Besides these new business requirements, operators are also looking to reduce complexity and are in need of simpler network designs, open standards, multi-vendor environments and reduced costs. Segment Routing (SR) helps network operators achieve these goals by offering innovative methods for traffic steering and introduce enhanced resiliency capabilities that go beyond what current routing protocols provide, while reducing the number of protocols needed to run the network.

Segment Routing definitions

Since SR is a relative new phenomenon, there is some fundamental terminology which deserves a bit of explanation. Also, SR can leverage different forwarding planes; MPLS or IPv6 and ‘to make it easy’ for the operator there are two options for IPv6; SRv6 and SRm6. We will get to the differences later in this blog.

The SR domain is a collection of nodes (network devices) participating in SR routing. An SR node can have different functions; ingress (tags an incoming packet with an extra header), transit (routes a packet based on the information in the added header) and egress (strips of the added header and forwards the packet based on the original packets protocol (for example IPv4).

An SR path is an ordered list of segments that connects an SR ingress node, via transit nodes, to an SR egress node. An SR path can follow the least cost path from ingress to egress or it can follow another path based on the segments defined.

Within SR, multiple segment types are defined. Among these are the adjacency and prefix segments.

·     An adjacency segment is an instruction that causes a packet to traverse a specified link (i.e. a link that is associated with an IGP adjacency).

·     A prefix segment is an instruction that causes a packet to traverse the least cost path to a node or prefix.

One could say that a prefix segment invokes more dynamic behaviours and therefore, a prefix segment is distinct from the portion of the topology that it causes a packet to traverse.

In the above figure all links are configured with the same IGP metric. An SR path connects R1 to R6 and contains the following prefix segments:

• Segment 1 (adjacency segment), instantiated on R1, causes packets to traverse the path from R1 to R2.
• Segment 2 (prefix segment), instantiated on R2, causes packets to traverse the least cost path from the instantiating node to R6.

As you can see from this example, SR can be used to force specific behavior in parts of the network, while allowing standard IGP protocols to influence traffic flows in other parts of the network. In our example we forced traffic from R1 to R2 and then allowed traffic to flow across the least cost path from R2 to R6. If we wanted to steer traffic around R1 to R4, we could have added second adjacency segment from R2 to R3 and then a prefix segment from R4 to R6. A benefit of using prefix segments over adjacency segments is that they reduce the number of SIDs required to be prepended to the packet, which can become an issue in larger networks.

Segment Routing Forwarding Planes

As stated earlier, SR can leverage different forwarding planes; MPLS or IPv6 which even offers 2 options; SRv6 and SRm6.

In SR-MPLS, paths are encoded as MPLS label stacks. Each label stack entry represents a segment in the SR path. MPLS is used to transport encapsulated packets that transit through the network. Therefore, network operators can easily and readily deploy SR in their MPLS networks today. Additionally, once the entire network has been converted to SR-MPLS, network operators can remove LDP and RSVP-TE from their network, resulting in fewer protocols to manage.

Where SR-MPLS might sound straight forward and may come across as the easier option; SR over IPv6 isn’t much more complicated, operators simply deploy the SR extensions to their existing IGP protocols.

It is important to understand that there are two options to deploy SR using IPv6 instead or MPLS. According to IETF draft https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-00 the difference between them is best defined as:

·     SRv6 defines a Routing header type, called the Segment Routing Header (SRH). The SRH contains a field that represents the SRv6 path as an ordered sequence of SIDs. Each SID contained by that field is 128 bits long.

·     SRm6 defines two Routing Header Types, called CRH-16 and CRH-32. Both contain a field that represents the SRv6 path as an ordered sequence of SIDs.

o  In the CRH-16, each SID is 16 bits long.

o  In the CRH-32, each SID is 32 bits long.

Large Routing headers are undesirable for the following reasons:

·     Many ASIC-based forwarders copy the entire IPv6 extension header chain from buffer memory to on-chip memory. As the size of the IPv6 extension header chain increases, so does the cost of this copy.

·     Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely reliable, many IPv6 hosts refrain from sending packets larger than the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are small, the overhead imposed by large Routing headers becomes pronounced.

The Benefits

Because the SR ingress nodes encode path information in the SR header, transit nodes are not required to maintain information regarding each path that they support. They are only required to process the segment identifiers found in the packet header and forward the packet from the current segment to the next segment.

This is the major benefit of SR. Because transit nodes are not required to maintain path information, overhead associated with maintaining that information is eliminated. By moving path state information from transit routers into the packet, segment routing eliminates the need for protocols such as LDP and RSVP-TE.

While removing path information from the transit node and encoding it in the packet introduces some new challenges, the engineering trade-offs are largely positive.