SR Circuit Style Manager (CSM)

The SR Circuit Style Manager (CSM) feature pack provides a bandwidth-aware Path Computation Element (PCE) to compute Circuit Style SR-TE policy paths that you can visualize in your network. Circuit Style enables segment routed transport tailored for circuit-oriented services over a packet based network through the use of bi-directional, co-routed, path protected SR-TE policies. Circuit Style SR-TE policies are typically used for high priority services, such as crucial monetary transactions or important live video feed, which require committed bandwidth with fast and fail-safe connections. The CSM feature pack ensures dynamic Circuit Style SR-TE policies are provisioned along paths that meet strict bandwidth requirements while at the same time respecting any additional user configured constraints such as latency minimization and disjointness.

Centralized bandwidth accounting in the CSM feature pack allows the user to monitor resource reservation levels and quickly identify hot spots where available bandwidth in the circuit style bandwidth pool is low. The ability to visualize Circuit Style SR-TE policies in your network topology enables easy verification of Circuit Style SR-TE policy configurations, details, and path states. With a few clicks you can view Active and Protect paths, operational status, reserved bandwidth pool size and monitor path failover behavior for individual Circuit Style SR-TE policies.


Note

Functionality described within this section is only available with certain licensing options.

This section contains the following topics:

Circuit Style SR-TE Important Notes

This topic outlines the scope of Crosswork's support for Circuit Style SR-TE policies, including requirements and constraints on the policy attribute values set in each Circuit Style SR-TE policy, and the processing logic followed during path reversions.


Note

Role-based Access Control (RBAC) and task permissions have been introduced in this release. To provision a Circuit Style SR-TE policy you must have write-access to the head-end device based on Device Access Groups and assigned roles. Only Circuit Style SR-TE admin users can modify Circuit Style SR-TE configuration settings. For more information on RBAC and user roles, see the "Cisco Crosswork Network Controller Administration Guide".

Policy Attribute Constraints

You set policy attribute values when you create a Circuit Style SR-TE policy, using either the device's command line interface or Cisco Crosswork Network Controller. You can also change them later.

The table below describes the requirements for each attribute, and how changes affect them. It is important to understand that all the attributes that are described in the table below act as constraints. Each of them corresponds to elements of the configuration that Cisco Crosswork uses to govern how Circuit-Style path hops are computed. Each value is effectively a path computation or optimization constraint, since they either specify a required property of a path or exclude possible choices for that path.

Table 1. Circuit Style SR-TE Policy Attribute Values and Constraints

Attribute

Description

Policy Path Protection

The path protection constraint is required for both sides of a Circuit Style SR-TE policy.

Bandwidth Constraint

The bandwidth constraint is required and must be the same on both sides of a Circuit Style SR-TE policy. Bandwidth changes can be made to existing policies, with these effects:

  • Once you configure the new bandwidth on both sides, Crosswork will evaluate the path. This will not result in a recomputed path

  • If the new bandwidth is higher, Crosswork checks the existing path to ensure sufficient resources. If all currently delegated paths can accommodate the new bandwidth, Crosswork returns the same path with the new bandwidth value, indicating to the path computation client (PCC) that it was successful. If any of the current paths cannot accommodate the new bandwidth, it returns the old bandwidth value indicating that it was unsuccessful. This evaluation will not be retried unless the bandwidth is changed again.

  • If the bandwidth is lower, Crosswork returns the same path with the new bandwidth value to indicate to the PCC that it was successful.

The user interface shows both the requested and reserved bandwidth under each candidate path when you view the policy details. These values can differ if the requested bandwidth is increased but there is insufficient available CS pool bandwidth along one or more of the paths.

Candidate Paths and Roles

The Working path is defined as the highest preference Candidate Path (CP).

The Protect path is defined as the CP of the second highest preference.

The Restore path is defined as the lowest preference CP. The headend must have backup-ineligible configured.

CPs of the same role in each direction must have the same CP preference.

Bi-Directional

All paths must be configured as co-routed.

Paths of the same role on both sides must have the same globally unique bi-directional association ID.

Disjointness

Working and Protect paths on the same PCC must be configured with a disjointness constraint using the same disjoint association ID and disjointness type.

The disjointness association ID for a Working and Protect path pair in one direction must be unique when compared with the corresponding pair in the opposite direction.

Only the Node and Link disjoint types are supported. The disjoint type used must be the same in both directions of the same policy.

The Restore path must not have a disjointness constraint set.

Crosswork follows strict fallback behavior for all Working and Protect path disjointness computations. This means that, if node type disjointness is configured but no path is available, Crosswork makes no automatic attempt to compute a less restrictive link type disjoint path.

Metric Type

Only the TE, IGP, Hop count, and Latency metric types are supported. The metric type used must match across Working, Protect and Restore paths in both directions.

Segment Constraints

All Working, Protect and Restore paths must have the following segment constraints:

  • protection unprotected-only

  • adjacency-sid-only

To ensure persistency through link failures, configure static adjacency SIDs on all interfaces that might be used by Circuit Style policies.

Unsupported Configurations

The following configurations are not supported:

  • Metric-bounds

  • SID-Algo constraints

  • Partial recovery is not supported 7.8.x.

  • State-sync configuration between PCEs of a high-availability pair. These are not required with Circuit Style SR-TE policies. Use of this feature may result in degraded performance.

  • Multiple Circuit Style SR-TE policies between the same nodes with the same color but different endpoint IPs.

Supported Policy Changes

The following constraints may be changed for an operationally "up" Circuit Style SR-TE policy that has been previously delegated:

  • Metric type

  • Disjoint type

  • MSD

  • Affinities

Once configuration changes are made in a consistent manner across all CPs and both PCCs (for example: the new metric type is the same for all CPs and both sides), Crosswork will initiate a recompute, which can result in new Working, Protect and Restore paths.

During any transitory period in which configurations are not in sync between paths on the same PCC or between PCCs, no path updates are sent to the PCCs.

Unsupported Policy Changes

The following configuration changes to a previously delegated and operationally "up" Circuit Style SR-TE policy are not supported:

  • CP preference

  • Disjoint Association ID

  • Bi-directional Association ID

To change these configurations for an existing policy, you must first shut down the policy on both sides, make the change (complying with restrictions as detailed above in terms of consistency) and then "no shut" the policy.

Path Computation

Crosswork computes paths for circuit style policies only after a complete bi-directional, path-protected set of candidate paths has been delegated, including Working and Protect paths on both sides. In cases where there is insufficient bandwidth and a path cannot be found, SR Circuit Style Manager will continue to retry after 30 minutes until a solution is found, or if Circuit Style SR-TE is disabled.

Crosswork computes the Restore path only after the Working and Protect paths are down. The SR Circuit Style Manager feature pack configuration interface provides a configurable delay timer to control how long after Restore paths are delegated from both sides to wait before the path is computed. This delay allows topology and SR policy state changes to fully propagate to Crosswork, in cases where these changes triggered the Restore path delegation.

Automatic re-optimization is not supported for any paths based on changes in topology, LSP state, or any periodic event. Path computation is supported for Intra/Inter area/level and Intra/Inter IGP Domain (same AS) Not supported path computation Inter-AS.

Reversion Behavior

Reversion behavior is controlled by the configuration of the WTR lock timer option under the Protect and Revert paths (it is not relevant for the Working path):

  • No lock configuration: Revert after a default 5-minute lock

  • Lock with no duration specified: No reversion

  • Lock duration <value>: Revert after the specified number of seconds

Reversion Logic

Path reversion depends on the initial state of the Working, Protect, and Restore paths and the events affecting each path. The scenarios in the following table provide examples of typical reversion behavior.

Table 2. Path Reversion Scenarios

Initial State

Events

Behavior

Working path is down, Protect path is up/active

Working path comes back up

  1. Working path recovers to up/standby state.

  2. Each PCC moves the Working path to active after the WTR timer expires.

  3. Protect path moves to up/standby.

Working path is down, Protect path is down, Restore path is up/active

Working path comes back up, then Protect path comes back up

  1. Working path recovers and goes to up/active state

  2. Restore path is removed

  3. Protect path recovers and goes to up/standby

Working path is down, Protect path is down, Restore path is up/active

Protect path comes back up, then Working path comes back up

On side A: The Working path failure is local (the first Adj SID in the SegList is invalid):

  1. Protect path recovers and goes to up/active.

  2. Restore path is removed.

  3. Working path recovers and goes to up/standby.

  4. Each PCC moves the Working path to active after the WTR timer expires, Protect path goes to up/standby.

On side Z: Working path failure is remote (first Adj SID in SegList is valid):

  1. Protect path recovers but is not brought up, Restore path remains up/active.

  2. Working path recovers and goes up/active.

  3. Restore path is removed.

  4. Protect path goes to up/standby.

Workflow for Setting Up CS SR-TE Policy Visualization

The following tasks are necessary to start visualizing Circuit Style SR-TE policies in the topology map:

Table 3. Tasks to Complete to Start Visualizing Circuit Style SR-TE Policies
Step Action

1. Enable the SR Circuit Style Manager (CSM) feature pack.

From the main menu, choose Services & Traffic Engineering > Traffic Engineering > Circuit Style SR-TE > Configuration.

Follow the steps in Enable SR Circuit Style Manager.

2. Configure CS SR policies on the devices.

Note

 

If you do this step before enabling the Circuit Style SR-TE feature pack, then the CS SR policies will appear operationally down.

You can configure CS SR policies using one of the following methods:

3. Verify that the CS SR policies appear in the SR Policy table.
From the main menu, select Traffic Engineering > Traffic Engineering > SR-MPLS > Circuit Style.
Select Circuit Style Tab

The SR Policy table now shows a filtered list containing only CS SR policies.

4. Verify that the reserved bandwidth pool settings you defined in Step 1 are configured properly.

Click on a CS SR node or policy and navigate to the Link Details > Traffic Engineering page (see Review Circuit Style SR-TE Policy Bandwidth Utilization). From the Circuit Style section, view the reserved bandwidth pool size. You can also view current Circuit Style SR-TE bandwidth utilization and how much is still available for use.

Enable SR Circuit Style Manager

In order to manage and visualize Circuit Style SR-TE policies on the topology map, you must first enable SR Circuit Style Manager (CSM) and set bandwidth reservation settings.

When CSM is enabled, it computes the best failover bidirectional paths with the requested bandwidth and other contraints defined in the Circuit Style SR policy configuration between two nodes.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Circuit Style SR-TE > Configuration.

Step 2

Toggle the Enable switch to True.

Step 3

Enter the required bandwidth pool size and threshold information. The following list describes additional field information. See also What Happens When Bandwidth Reservation Settings are Exceeded?.

Field Description

Basic

Link CS BW Pool Size

The percentage of each link's bandwidth reservable for Circuit Style SR-TE policies.

Link CS BW Min Threshold

The Link CS BW Pool utilization percentage beyond which a threshold crossing event notification will be generated.

Advanced

Validation Interval

This is the interval that CSM policy will wait before the bandwidth that is reserved for an undelegated policy is returned to the Circuit Style SR-TE policy bandwidth Pool.

Timeout

The duration until which CSM will wait for the delegation request, to generate a notification.

Restore Delegation Delay

The duration until which CSM will pause before processing a restore path delegation.

Step 4

Click Commit Changes to save the configuration. After enabling CSM, you must create Circuit Style SR policy configurations either manually on the device (see Configure Circuit Style SR Policies) or through Cisco Crosswork Network Controller .

Configure Circuit Style SR Policies

A Circuit Style SR policy configuration must include the destination endpoint, the amount of requested bandwidth, and the bidirectional attribute (see Circuit Style SR-TE Important Notes for additional requirements or notable constraints). The configuration should also include a Performance Measurement Liveness (PM) profile. A PM profile enables proper detection of candidate path liveness and effective path protection. PCCs do not validate past the first SID, so without PM, the path protection will not occur if the failure in the Circuit Style SR policy candidate path is not the first hop in the segment list. For more information, see Configuring SR Policy Liveness Monitoring.

This section provides guidance on how to manually configure a Circuit Style SR policy and a Performance Measurement Liveness (PM) profile on a device.

Procedure

Step 1

If applicable, enable the hardware module on the device for PM configuration.

Example:

hw-module profile offload 4

reload location all

Step 2

Configure the PM profile.

Example:

performance-measurement
 liveness-profile sr-policy name CS-active-path
  probe
   tx-interval 3300
  !
npu-offload enable   !! Required for hardware Offload only
  !
 !
 liveness-profile sr-policy name CS-protect-path
  probe
   tx-interval 3300
  !

npu-offload enable   !! Required for hardware Offload only
  !
 !
!

Step 3

Configure the Circuit Style SR policy with the PM profile. All configurations shown in the example are required in order for CSM to manage the Circuit Style SR-TE policy. Entries that are defined by the user are italicized. See Circuit Style SR-TE Important Notes for additional requirements or notable constraints.

Example:

segment-routing
 traffic-eng
  policy cs1-cs4

   performance-measurement
    liveness-detection
     liveness-profile backup name CS-protect      !! Name must match liveness profile defined for Protect path
     liveness-profile name CS-active               !! Name must match liveness profile defined for Active path
    !
   !
   bandwidth 10000
   color 1000 end-point ipv4 192.168.20.4
   path-protection
   !
   candidate-paths
    preference 10
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     backup-ineligible
     !

     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
     !
     bidirectional
      co-routed
      association-id 1010
     !
    !
    preference 50
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 1050
     !
    !
    preference 100
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 1100
     !
    !

   !
  !

 !
!

Review Circuit Style SR-TE Policy Bandwidth Utilization

You can verify that the reserved bandwidth pool settings (defined when enabling CSM, see Enable SR Circuit Style Manager) are configured properly. You can also view current Circuit Style SR-TE bandwidth utilization and how much is still available for use.


Note

There are different ways to navigate to the Link Details > Traffic Engineering page from a participating Circuit Style SR-TE node or link. The following procedure assumes you have a Circuit Style SR-TE policy checked in the SR Policy table.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Traffic Engineering > SR-MPLS and click Circuit Style. The SR Policy table lists all Circuit Style SR-TE policies.

Step 2

From the SR Policy table, check the check box next to the Circuit Style SR-TE policy you are interested in.

Step 3

From the topology map, click on a participating Circuit Style SR-TE policy node.

Step 4

From the Device Details page, click Links tab > Link_Type _entry > Traffic Engineering tab > General.

Under Circuit Style Bandwidth Pool, you can see the reserved bandwidth pool size, the amount of bandwidth currently being used, and what bandwidth (allocated to Circuit Style SR-TE policies) is still available.

In this example, the reserved bandwidth pool size is displayed as 800 Mbps for NCS-3 and NCS1. The configured settings were earlier defined as 80% for the bandwidth pool size. Since the interface is 1 Gbps, we can confirm that CSM has correctly allocated 80% of bandwidth to be used for Circuit Style SR-TE policies for these interfaces.

CS SR Policy Bandwidth Pool

View Circuit Style SR-TE Policies

View Circuit Style SR-TE policy details such as the endpoints, bandwidth constraints, IGP metrics, and candidate (Working and Protect) paths.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Traffic Engineering > SR-MPLS and click Circuit Style.
Select Circuit Style Tab
The SR Policy table lists all Circuit Style SR-TE policies.

Step 2

From the Actions column, click More icon > View Details for one of the Circuit Style SR-TE policies.

Note

 

You cannot edit or remove Circuit Style SR-TE policy configurations that have been created directly on the device.


View Circuit Style SR-TE Policy Details

The Circuit Style Policy Details window is displayed in the side panel. By default, the Active path is displayed in the topology map and shows the bidirectional paths (Bi-Dir Path checkbox is checked) on the topology map. The Candidate Path list displays the Active (path that currently takes traffic) and Protected paths.


CS-SR Policy Details Summary

Note

 

The Bandwidth Constraint value can differ from the bandwidth you requested if the value was increased and insufficient resources existed to satisfy demand on all Active and Protected candidate paths.

Step 3

View Candidate path configuration details.

  1. The Circuit Style Policy Details window allows you to drill down to view more information about the candidate paths. You can also copy the URL and share this information with others.

    The operational (Oper State Up) candidate path with the highest preference will always be the Active path (see How Does CSM Handle Path Failures?). In this example, the Protected path (with preference 50) is currently the Active path and is displayed on the topology map. Notice that it is designated with a green "A" icon under State to clearly indicate it is currently the operational Active path. Click Expand All to view more information about both paths.


    Candidate Path on Topology Map

    Note

     

    • First preference paths are shown as purple links.

    • Second preference paths are shown as blue links.

    • Third preference paths are shown as pink links.
    If the Circuit Style SR-TE policy configuration was done through Cisco Crosswork Network Controller, you have the option to view the Circuit Style SR-TE policy configuration. To see the configuration, click the link next to Config ID. For example:
    View Candidate Path Details
    Here is a sample of a Circuit Style policy configuration. For more information, see Configure Circuit Style SR Policies.
    Circuit Style Policy Configuration Example

Step 4

To view the physical path and metrics between endpoints of the selected Circuit Style SR-TE policies, click Display Preferences icon to turn applicable metrics on and check the IGP Path checkbox.
IGP Metrics

Trigger CSM to Recalculate a Circuit Style SR-TE Policy

Circuit Style SR-TE policies are static in nature, meaning once the paths are computed, they will not be automatically re-optimized based on topology or operational status changes that may affect their paths. You can manually trigger CSM to recalculate a CS-SR policy after the policy's operational status went from down to up or if bandwidth size and requirement changes have been configured.


Note

You can only reoptimize an Active and Protect path. It will not work for a Restore path.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Traffic Engineering > SR-MPLS and click Circuit Style. The SR Policy table lists all Circuit Style SR-TE policies.

Step 2

From the Actions column, click More icon > View Details for the Circuit Style SR-TE policies you want CSM to recalculate a path for again.

Step 3

From the top-right corner, click More icon > Reoptimize.

What Happens When Bandwidth Reservation Settings are Exceeded?

CSM discovers and updates the available and reservable bandwidth in the network. CSM maintains an accounting of all bandwidth reservations provided for CS SR policies to ensure that the total reserved bandwidth on all interfaces remains at or below the network-wide resource pool (bandwidth pool size).

This topic provides examples of how CSM handles policies that exceed either the bandwidth pool size or bandwidth alarm threshold that were set in the CSM Configuration page.

Example: Bandwidth Utilization Surpasses Defined Threshold

  • Link CS Bandwidth Pool Size: 10%

  • Link CS Bandwidth Minimum Threshold: 10%

In this example, the bandwidth pool size for the 10 Gbps ethernet interfaces is 1Gbps and the alarm threshold is set for 100 Mbps (10% of pool size).

  1. A Circuit Style SR-TE policy from node 5501-02 to node 5501-01 (r02 - r01) is created with a bandwidth of 100 Mbps.


    CS-SR Policy 10 Mbps Up

  2. Later, the requested bandwidth configured for the policy is increased to 500 Mbps. CSM determines the additional bandwidth along the existing path is available and reserves it.


    CS-SR Policy 500 Mbps Up

  3. Since the bandwidth utilization (500 Mbps) with the updated policy is above the configured pool utilization threshold (100 Mbps), an event is triggered.


    Threshold Alerts

Example: Bandwidth Pool Size and Utilization Exceeded

  • Link CS Bandwidth Pool Size: 10%

  • Link CS Bandwidth Minimum Threshold: 90%

In this example, the bandwidth pool size for the 10 Gbps ethernet interfaces is 1Gbs and the alarm threshold is set for 900 Mbps.

  1. An existing Circuit Style SR-TE policy from node 5501-02 to node 5501-01 (r02 - r01) uses a bandwidth of 500 Mbps.

  2. Later, a new policy requiring a bandwidth of 750 Mbps with a path from node 5501-02 to node 5501-01 to 5501-2 (r02 - r01- r2) is requested. The only paths available between these 2 nodes are the paths computed for the first CS policy.

    • CSM cannot compute a path for the new Circuit Style SR-TE policy r02 - r01 - r2 and therefore remains operationally down. CSM will try again, every 30 minutes, to find a path that meets the bandwidth requirements.


      CS-SR Policy Exceeds Bandwidth Pool Size

    • Alerts are triggered.


      Threshold Alerts

  3. Later, the Circuit Style SR-TE policy r02 - r01- r2 is updated and only requires 10 Mbps. The following behaviors occur:

    • Since the total bandwidth required for the two polices (10 Mbps + 500 Mbps = 510 Mbps) now requires less than the bandwidth pool size (1Gbps), Circuit Style SR-TE policy r02 - r01 - r2 receives a path computed by CSM and becomes operationally up.


      Updated CS-SR Policy Operational

    • Since the second Circuit Style SR-TE policy with the reduced bandwidth is now provided a path by CSM, alerts are cleared.


      Cleared Alerts

How Does CSM Handle Path Failures?

Cisco Crosswork computes paths for Circuit Style SR-TE policies only after a complete bidirectional, path-protected set of candidate paths has been delegated. There are three types of candidate paths that are used during path failures:

  • Working—This is the path with the highest preference candidate path.

  • Protect—This path is defined as the second highest preference candidate path. If the Working path goes down, the Protected path (with the lower preference value) is activated. After the Working path recovers, the Protected path remains active until the default lock duration expires.

  • Restore—This path is defined as the lowest preference candidate path. Crosswork computes the Restore path only after the Working and Protect paths are down. You can control how long after Restore paths are delegated from both sides to wait before the path is computed (see Enable SR Circuit Style Manager). This delay allows topology and policy state changes to fully propagate to Crosswork, in cases where these changes triggered the Restore path delegation.

To address path failures effectively and switchover from working path to protect path, you can configure Performance Measurement (PM). For more information, see Configure Circuit Style SR Policies.

Examples


Note

Illustrations are for demonstration purposes only and may not always reflect the exact UI or data described within the workflow content. If you are viewing the HTML version of this guide, click the images to view them in full-size.

The following image shows that the Working and Protected paths of the Circuit Style SR-TE policy are operational. The active path is indicated by the "A" icon.
Initial Candidate Paths
When the Active path goes down, the Protected path immediately becomes "active". When the Active path goes back up, then the Protected path takes the role of "protected" again and the Active path (with preference 100) becomes active.
Protected Path Becomes Active
In the case where both Working and Protected paths go down, CSM calculates a Restore path and it becomes the active path. Note that the Restore path has the lowest preference value of 10. The Restore path only appears in this particular case. If either the Working or Protected paths become operational again, the Restore path disappears from the topology map and from the Candidate Path list.
Restore Path