For the past few years, Segment-Routing (SPRING) proved its higher potential to the vast majority of data communication & network researchers, for what it provides from new methods and possibilities to make available network resources highly programmable. SPRING stands for "Source Packet Routing In NetworkinG" and it's being standardized in the IETF, and it enjoys strong industry support.

In the following lines, I will try to elaborate the concept of segment-routing as clear as possible. This article will be the first part of a small series that will follow the same lead. Feel free to ask/report about anything that is not clear about this article's content.

Before I begin, I recommend the reader to acquire the basic knowledge about how MPLS / IPv6 forwarding paradigms works in order to easily catch things up without any conflicts.

Let's just begin :)

In a nutshell:

Segment-routing (SPRING) is a new forwarding paradigm that provides source-routing based on specific traffic flows, which means that the source of the flow can define the path that the traffic will take.

The way it works, is that the source (Application flow) chooses a specific desired path (based on the flow needs) from the available paths that may differ from the normal shortest path, and encodes it in the packet header as a controlled list of instructions called "segments".

As the IPv4 header has no possibility for extension headers to support segment-routing feature (only specific IP options are allowed to be added to the IPv4 header when needed), there was no way to support it directly. IPv6 header eases that need on developers as it was built with native support for extension headers. In the next paragraph, we will see how segment-routing was implemented for each IPv6 directly, and IPv4 indirectly through MPLS.

>From this moment, let's just refer to Segment-routing as SPRING till the end of this article.

SPRING introduces two models that can use either MPLS or IPv6 as a forwarding plane to forward packets with the required segments (SR-MPLS or SR-IPv6). It's a compelling architecture which embraces Software-Defined Network (SDN) and is the foundation for Application Engineered Routing (AER).

According to Figure A, what links between the possible application flows and the actual production network that is SPRING enabled, is an SDN controller, which differentiates between the application needs and the available resources.

Figure A

First, applications negotiate/communicate their requirements (SLA, Latency, Bandwidth..etc) with each others. These requirements are gathered by an SDN Controller, which in turn, collects the data from network resources that should be adequate enough to maintain these requirements, such as topology, link states and link utilization. In the end, applications flows got mapped to specific paths for each flow, by a list of instruction segments.

SPRING relies purely on a small number of extension TLVs that was added to IGPs (OSPF/IS-IS) and BGP in order to support its functionality, that should be covered in a later article.

A node in SPRING (SR. Node) could be anything, it can be a router, switch, server, or even a virtual machine based forwarder. In case of using MPLS as the forwarding plane, the set of ordered "segments" are trans-coded into a label stack, with every label in the stack simply expressed into one instruction segment. In case of using IPv6 as the forwarding plane, those ordered segments are trans-coded into a list of hops that are inserted within an extension (SRH) to the IPv6 header, with every hop represents one instruction segment.

At the end of the day, segments represent sub-paths that an SR. node can combine to form a complete route to a network destination.

Instruction segments are provided by two methods, Local segments and Global segments. Whereas any of them could be used independently or in consistent with each other in order to produce a specific flow based path.

SR-MPLS

SR-MPLS is the segment-routing model for MPLS forwarding plane. No changes were made to the MPLS forwarding paradigm. MPLS operations [Push / Swap / Pop] are still taking place as to tunnel the traffic flow to the desired destination.

As the packets is being originated at the first place, the originator node pushes a number of segment labels (based on a specific traffic flow needs) that represents how many instructions/sub-paths to be combined and form a complete desired path. That labeled traffic will be forwarded by swapping the top most segment label across the intermediate MPLS nodes, the segment to process is one that is top most of the label stack.

Once a segment has been completely processed by an SR. node, its associated label is popped, then the traffic will be forwarded to the remaining SR. nodes in the series by swapping the next segment label as to be processed by the next SR. node in the series, and so forth.

Figure B

Figure C

1. According to figure "C", the first nodal (global) label {65} was popped at node {D} once the instruction is complete (by reaching the label’s destination).
2. By its role, node {D} have popped the adjacency (local) label {9001} once completing its relevant instruction within that node (by forwarding the packet to the 1st interface).
3. Finally, router {P} will pop the remaining label {66} as the default PHP behavior, and forward an IP Packet to node {Z} .

​

SR-IPv6

SR-IPv6 is applied to the IPv6 architecture to support segment-routing. In order to inter-operate with IPv6 forwarding paradigm, a new type of routing extension header “SRH” has been implemented to carry instruction segment information.

Equivalent to SR-MPLS concept, a single instruction segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses that are all being inserted in the routing extension header by the originator node according to a specific traffic flow needs.

The segment to process is indicated by comparing a pointer field called “segments left” and a list that represents every remaining segment called “segment list” in the SRH. While the flow is passing along the IPv6 nodes, every SR-IPv6 node will check the field in the SRH for its address, if found, then the segment is processed. Upon completion of a certain segment process, both “Segments left” & “Segment list” are decremented by one hop entry, and so forth.

Figure D

That's it for today, as I've mentioned, this article will be a part of a small series, the following articles will try to dig deeper in the concept and to explain more of its building blocks. I hope that this was helpful at least to be aware of the concept basics.