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:

• SR-MPLS and SRv6

• Flexible algorithm

• Tree Segment Identifier

• SR Circuit Style

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.

  Important

  The SRLG value is displayed only for IPv4 links and is not shown for IPv6 links.

  Note	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.

Note	Disjointness is supported for two policies with the same disjoint ID. Configuring affinity and disjointness at the same time is not supported.

RSVP-TE capabilities

RSVP-TE provides these capabilities.

• Endpoint control: Establishes and manages TE tunnels at the headend and tail end of the network connection.

• Link-management: Enables efficient routing of TE label-switched paths (LSP) by assigning Multi-Protocol Label Switching (MPLS) labels.

• Fast Reroute (FRR): Manages LSPs that need protection and assigns backup tunnel information for quick recovery in case of faults.

RSVP-TE explicit routing (Strict, Loose)

RSVP-TE explicit routes are particular paths in the network topology that you can specify as abstract nodes in the Explicit Route Object (ERO). These nodes may be a sequence of IP prefixes or a sequence of autonomous systems. You can specify the explicit path administratively or compute it automatically using an algorithm, such as constrained shortest path first (CSPF). The explicit path routes can be:

• Strict paths: Each network node and its preceding node in the ERO are directly connected and must be adjacent.

  For example. Node A → Node B → Node C, where each hop must be over a single direct physical link.

• Loose paths: A node in the ERO must be present in the path but is not required to be directly connected to its preceding node. When encountering a loose hop during ERO processing, the node that processes the loose hop can update the ERO with one or more nodes along the way to the next specified node. The advantage of a loose path is that the entire path does not need to be specified or known when creating the ERO.

  For example, Node A → Node X (any path, possibly multiple hops, between A and X is acceptable).

  A disadvantage of a loose path is the potential for forwarding loops that can occur during transient changes in the underlying routing protocol.

Note	RSVP-TE tunnels cannot be configured with loose hops when provisioning using the UI.

RSVP FRR (Fast Reroute)

RSVP FRR provides rapid LSP restoration when a failure is detected:

• If a router’s link or neighboring device fails, the router detects this via an interface-down notification.

• If an interface goes down, the router switches LSPs going out of that interface onto their respective backup tunnels, if available.

The FRR object, used in the PATH message, contains a flag that identifies the backup method to be used as facility-backup. The FRR object specifies setup and hold priorities. These priorities are included in a set of attribute filters and bandwidth requirements used to select the backup path.

The Record Route Object (RRO) in the RESV (Reservation) message reports the availability or use of local protection (such as FRR) on an LSP. It also indicates whether bandwidth protection and node protection are available for that LSP.

• The TE tunnel headend signals FRR requirements along the path.

• Points of Local Repair (PLRs) evaluate the FRR requirements based on the availability of backup tunnels at the PLR. These nodes are able to switch LSPs to backup tunnels if needed. If a suitable backup tunnel is available, the PLR selects it and signals the backup tunnel information to the headend.

• When an FRR event is triggered (for example, a link or node failure), the PLR sends PATH messages through the backup tunnel to the merge point (MP), where the backup tunnel rejoins the original LSP.

• The MP sends RESV messages back to the PLR using the RSVP-Hop object included by the PLR in its PATH message. This mechanism ensures that the original LSP is not torn down by the MP during the failover process.

• The PLR notifies the headend about the failure by sending a PATH-ERROR message, indicating that FRR is in use for the affected LSP. This prompts the headend to establish a new LSP for the TE tunnel while maintaining traffic flow using make-before-break techniques. Once the new LSP is operational, the headend tears down the failed path.

To see the Traffic Engineering Dashboard, choose Services & Traffic Engineering > TE Dashboard .

Note	If you are viewing the HTML version of this guide, click the images to view them in full-size.