Utilizes source routing to establish tunnels where the source encodes the path in the packet header using segment identifiers. Routers process these segments to forward traffic along a calculated path, allowing for precise control over data flow regardless of the underlying shortest path.
Segment routing for traffic engineering operates through a tunnel established between a source and destination pair. It uses the concept of source routing, where the source calculates the path and encodes it in the packet header as a segment. Segments serve as identifiers for various types of instructions. For example, topology segments identify the next hop toward a destination. Each segment is identified by a segment ID (SID), which is an unsigned 32-bit integer. Routers within the provider’s core network read and process these SIDs to forward packets along the intended path, calculated by the IGP, whereas the destination is unaware of the presence of the tunnel. Segments are stacked in the packet, and each router processes the top SID in the stack to determine the next hop.
Segment types and their roles
Interior gateway protocol (IGP) distributes two types of segments: prefix segments and adjacency segments. Each router (node) and each link (adjacency) in the network is associated with a segment identifier (SID).
-
Prefix SID: A prefix SID is tied to an IP prefix and is manually configured from the segment routing global block (SRGB) range of labels. It is distributed by IS-IS (Intermediate System to Intermediate System) or OSPF (Open Shortest Path First). The prefix segment directs traffic along the shortest path to its destination. A node SID is a special type of prefix SID that identifies a specific node, typically configured on the loopback interface using the node's loopback address as the prefix. Prefix SIDs are globally unique within the segment routing domain.
-
Adjacency SID: An adjacency segment is represented by an adjacency SID, a label that identifies a specific adjacency, such as an egress interface to a neighboring router. Adjacency SIDs are distributed by IS-IS or OSPF and are locally unique to each router. The adjacency segment steers traffic to a particular adjacency.
By combining prefix (node) and adjacency SIDs in a specific order, any desired path through the network can be constructed. Segments are arranged in a stack within the packet header. At each hop, the router reads the top segment in this stack to decide the next forwarding step.
-
If the segment contains the identity of another node, the router uses Equal-Cost Multi-Path (ECMP) to forward the packet to the next hop.
-
If the segment is meant for the current router, the router removes (pops) the top segment and processes the next segment in the stack.
Segment routing policies
Segment routing for traffic engineering uses a “policy” to steer traffic through a specific path in the network. An SR policy defines the path as an ordered list of segments, known as a segment ID (SID) list, where each SID represents a specific instruction, such as forwarding to a particular node or adjacency. When a packet is matched to an SR policy at the head-end router (the entry point of the policy), the router attaches (pushes) the SID list onto the packet header. As the packet traverses the network, each router reads and processes the top SID in the list, executing the corresponding forwarding instruction. This ensures that the packet follows the explicit path specified by the SR policy, regardless of the underlying IGP shortest path.
Crosswork Network Controller supports the visualization and some provisioning of these SR-TE policies:
Dynamic vs. explicit SR policies
An SR-TE policy can use one or more candidate paths. A candidate path can be a single segment list (SID list) or a group of weighted SID lists.
-
Dynamic SR policy: Dynamic paths are a type of candidate path computed based on optimization objectives (such as minimizing TE or IGP metrics) and constraints (like affinity or protection requirements). The head-end router typically computes these dynamic paths locally. However, if it does not have complete topology information, it can delegate the computation to a Segment Routing Path Computation Element (SR-PCE). When the topology changes, a new path is computed. This dynamic path calculation produces a sequence of interface IP addresses representing the specific links (adjacencies) along the path. Traffic engineering then maps each of these interface IP addresses to an adjacency Segment Identifier (adj-SID) label. Routes are learned and forwarded using these adjacencies over the Traffic Engineering tunnel.
-
Explicit SR policy: The path is explicitly specified by the network operator as a fixed list of prefix or adjacency SIDs, each representing a node or link along the path. The path does not change automatically with topology changes unless manually reconfigured. This policy is used when precise control over the traffic path is required, such as for traffic engineering or compliance with specific routing policies.
Disjoint path computation
Crosswork Network Controller uses the disjoint policy to compute two lists of segments that steer traffic from two source nodes to two destination nodes along disjoint paths. The disjoint paths can originate from the same head-end or different head-ends. Disjoint level refers to the type of resources that the two computed paths should not share. The following disjoint path computations are supported:
-
Link – Links are not shared on the computed paths.
-
Node – Nodes are not shared on the computed paths. ensuring complete independence of routing devices.
-
SRLG – Links with the same Share Risk Link Group (SRLG) value (representing a common risk) are not shared on the computed paths.
The SRLG value is displayed only for IPv4 links and is not shown for IPv6 links.
SRLGs are also utilized in flexible algorithm definitions to exclude links from specific topologies. For more details, see Configure and visualize flexible algorithm SRLG exclusion.
-
SRLG-node – SRLG and nodes are not shared on the computed paths, offering the highest level of fault isolation.
When the first request is received with a given disjoint-group ID, a list of segments is computed, encoding the shortest path from the first source to the first destination. When the second request is received with the same disjoint-group ID, the information received in both requests is used to compute two disjoint paths: one path from the first source to the first destination and another from the second source to the second destination.
Disjointness is supported for two policies with the same disjoint ID.
Configuring affinity and disjointness at the same time is not supported.