Bandwidth on Demand (BWoD)

Bandwidth on Demand

Bandwidth on Demand (BWoD) is a bandwidth-aware Path Computation Element (PCE) that:

  • integrates with SR-PCE to compute SR policy paths meeting requested bandwidth requirements,

  • creates paths between endpoints in the network based on specific user-defined intents and dynamically maintains these bandwidth guarantees as network conditions change, and

  • supports both PCC-initiated (PCE-delegated) and PCE-initiated policies, providing soft bandwidth guarantees over SR policies.

Key features of BWoD

Key features of BWoD include:

  • Intent-based path computation: BWoD creates SR policy paths based on user-defined intents such as minimizing IGP cost, TE metrics, or latency.

  • Continuous monitoring and reoptimization: BWoD continuously monitors network conditions and automatically re-optimizes BWoD paths to ensure that total BWoD traffic on any interface does not exceed a configured threshold percentage.


Note

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

Limitations of BWoD

BWoD does not track total interface utilization; therefore, interfaces can still become congested if combined BWoD and non-BWoD traffic exceed capacity. In addition, BWoD does not enforce the total amount of traffic entering a BWoD SR policy. BWoD policies may traverse Equal Cost Multi-Path (ECMP) paths assuming even traffic distribution, but actual ECMP distribution can be uneven, especially with large flows.

Important considerations when using BWoD

Consider the following information when using BWoD:

  • Write-access to the head-end device is required based on Device Access Groups and assigned user roles. Only BWoD admin users can modify BWoD configuration settings. See the Cisco Crosswork Network Controller Administration Guide.

  • If BWoD cannot find a path for a policy that guarantees its requested bandwidth, BWoD will attempt to find a best effort path if this option is enabled.

  • BWoD disables itself when an unexpected error is encountered to avoid network disruption.

  • BWoD temporarily pauses operation whenever the Optimization Engine model is unavailable due to an Optimization Engine restart or a rebuild of the topology from Topology Services. Any requests to BWoD during this time are rejected. When the model becomes available and BWoD receives two traffic updates from the Optimization Engine, BWoD will resume normal operation.

  • If the Policy Violation advanced field is set to Strict, then the SR Policy Traffic option should be set to Max Measured Requested.

  • After a switchover in a High Availability setup, BWoD policies created after the last cluster data synchronization will not be manageable and are considered orphaned TE policies. Crosswork Network Controller will display an alarm when it finds orphan TE policies (Administration > Alarms). You can use APIs to help clear these orphan policies so that they are manageable. For more information, see API documentation on Devnet.

PCC-initiated BWoD SR-TE policies

PCC-initiated BWoD SR-TE policies are traffic engineering policies that:

  • allow devices to configure bandwidth requirements locally,

  • delegate path computation to an external SR-PCE, and

  • continuously optimize and monitor traffic-engineered paths based on bandwidth constraints.

BWoD automatically connects to all SR-PCE providers configured in Crosswork Network Controller, maintaining a persistent connection to the SR-PCE BWoD REST API, which registers as a PCE for bandwidth-constrained SR-TE policies. If bandwidth constraints cannot be fully met, BWoD computes best-effort paths and issues events accordingly. BWoD also monitors and re-optimizes paths to maintain bandwidth guarantees across the network.

How PCC-initiated BWoD SR-TE policies work

Summary

The key components involved in the process are:

  • Path Computation Client (PCC): Configures and initiates BWoD SR-TE policies and delegates path computation to the SR-PCE.

  • SR Path Computation Element (SR-PCE): Receives delegated policies from the PCC, coordinates bandwidth requirements, and interacts with BWoD functionality.

  • BWoD module: Performs constraint-based path computation to satisfy bandwidth constraints, returns segment lists, and updates policy status as needed.

The following figure shows the PCC-initiated workflow for BWoD:

Workflow

Figure 1. PCC-Initiated BWoD SR-TE policies
PCC-Initiated BWoD SR-TE Policies
Table 1. PCC-Initiated BWoD SR-TE Policies

Callout No.

Workflow

1
The user configures a BWoD SR-TE policy on the PCC via the CLI, specifying bandwidth, endpoint, candidate paths, and constraints. For example: 
segment-routing
  traffic-eng
    policy bwod
      bandwidth 900
      color 100
      end-point ipv4 1.1.1.2
      candidate-paths
        preference 100
          dynamic
            pcep
            !
            metric
              type te
              !
            !
        constraints
          affinity
            exclude-any
              name RED
              !
          !
       !
   !
!

2

Upon committing the configuration, the PCC delegates the path compute to SR-PCE.

3,4

SR-PCE further delegates the policy to BWoD, which attempts to compute a path that meets the requested bandwidth constraints.

5,6

If a bandwidth-compliant path is found, the segment list is returned to SR-PCE, which forwards it over PCEP to the PCC, and the PCC instantiates it. If BWoD is unable to compute a bw-compliant path for the policy or doing so will force an existing BWoD policy to not have a bw-compliant path, best effort paths may be computed by BWoD, which attempts to minimize violations. This occurrence will also trigger BWoD to issue an event to the Events UI indicating which BWoD policies are now on best-effort paths.

7

A BWoD SR-TE policy is instantiated.

Configure bandwidth on demand

Before you begin

Both CSM and BWoD cannot be enabled at the same time. If you have CSM enabled, you must disable it before enabling BWoD.


Note

It is recommended to delete the respective policies from the network before disabling the associated function pack (BWoD or CSM). If policies remain in the disabled function pack, this may cause issues with new policy delegation and increase processing time.

Complete these steps to configure bandwidth on demand and create BWoD SR policies. As long as BWoD is enabled, you can create multiple BWoD SR policies.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Bandwidth on Demand > Configuration.

Step 2

Toggle the Enable switch to True.

Step 3

Configure the required options. Refer to the BWoD configuration options section to view the description of each field.

Step 4

Click Commit changes to save the configuration.

Step 5

To create BWoD SR policies, choose Services & Traffic Engineering > Traffic Engineering > SR-MPLS tab and click Create > PCE init.

Step 6

In addition to entering the required SR policy details, click the Bandwidth on demand option and enter the required bandwidth.

Step 7

If applicable, enter a Flexible Algorithm constraint in the SID Algorithm field. The values correspond to the Flexible Algorithm that are defined on the device and the 128-255 range is enforced by Cisco IOS XR. Crosswork Network Controller will try to find a path with this SID. If a path with the SID constraint cannot be found, the provisioned policy will remain operationally down until the conditions are met.

Step 8

Click Preview to view the proposed SR policy.

Step 9

Click Provision to commit the SR policy.

BWoD configuration options

These tables provide information on the BWoD configuration options available in the UI.

Basic BWoD options

Table 2. Basic configuration options

Option

Description

Enable

Enables or disables the BWoD function pack.

Primary Objective

Sets the primary objective when optimizing policies.

  • Maximize available bandwidth: Computes an SR policy path maximizing the overall available bandwidth in the network. This setting generally attempts to maximize usable network capacity at the expense of potentially longer paths.

  • Metric minimization: Computes an SR policy path minimizing the metric selected. This setting generally results in the shortest available paths for a metric type.

Link Utilization

Sets the congestion constraint (in percentage). When searching for paths for delegated policies, the Bandwidth on Demand will avoid any path that may exceed this utilization threshold, ensuring traffic is not routed through congested links. Additionally, when an interface exceeds this value, the system will trigger optimization to redistribute traffic and alleviate congestion.

Re-optimization interval (seconds)

Sets the minimum time (in seconds) before paths can be re-optimized if network conditions change. This acts as a countdown timer; the BWod policy will wait for this duration to expire before allowing re-optimization.

Metric re-optimization time

Sets the duration (in seconds) before paths can be re-optimized for metric improvements. If bandwidth requirements are met but a better IGP or TE path is available, BWod will wait for this timer to expire before re-optimizing. This helps prevent frequent path changes and unnecessary re-optimizations.

Advanced BWoD options

Table 3. Advanced configuration options

Option

Description

SR policy traffic

Determines how bandwidth optimization is calculated for each policy.

  • Measured: Uses the current measured traffic of BWoD provisioned SR policies for optimization caculations.

  • Max measured requested: Uses the maximum value between the current measured traffic on BWoD provisioned SR policies or the amount of bandwidth requested for optimization calculations.

Update throttle (seconds)

Sets the time (in seconds) to wait between updates. Set to 0 to disable throttling.

Optimizer event threshold (seconds)

Sends an alert to the UI if the optimizer runs longer than the specified time (in seconds).

Note

 

In large-scale environments, the optimizer run may exceed the default run time limit of 60 seconds. For deployments where policies are provisioned in batches of 100, setting the Optimizer event threshold to 240 seconds and the Optimizer run time limit to 300 seconds has been effective in internal testing. For environments where 1,000 or more policies are deployed, these values may need to be increased further. Adjust these parameters based on the scale of your deployment to ensure optimal performance.

Optimizer run time limit (seconds)

Sets the maximum allowed run time (in seconds) for the BWoD optimizer.

Note

 

In large-scale environments, the optimizer run may exceed the default run time limit of 60 seconds. For deployments where policies are provisioned in batches of 100, setting the Optimizer event threshold to 240 seconds and the Optimizer run time limit to 300 seconds has been effective in internal testing. For environments where 1,000 or more policies are deployed, these values may need to be increased further. Adjust these parameters based on the scale of your deployment to ensure optimal performance.

Policy violations

Determines how BWoD responds when new policies are provisioned and policy violations are detected.

Prefer strict SIDs

When enabled, prefers strict SIDs when deriving segment lists. Required for compatibility with LCM.

Debug optimizer

Enables logging of optimizer plan files to the Crosswork Network Controller file system. The number of saved files is limited by the Debug opt max plan files setting.

Provision an SR-TE policy to maintain intent-based bandwidth requirements example

This example demonstrates:

  • how to enable and configure Bandwidth on Demand (BWoD)

  • how to create BWoD policies

  • how BWoD calculates paths, and

  • how BWoD calculates new policies when the Policy violation option is set to Loose or Strict.

In this example, three BWoD policies will be created using the same headend (L1-NCS5501.cisco.sjc20.com) and endpoint (L5-8201-1-crosswork.cisco.com), at different bandwidths (700 and 1000 Mbps), with network utilization capped at 80%. All interfaces have the capacity of 1 Gbps.

Figure 2. Initial BWoD topology

Initial BWoD topology

Procedure

Step 1

Enable and configure BWoD.

Note

 

Both CSM and BWoD cannot be enabled at the same time. If you have CSM enabled, you must disable it before enabling BWoD. It is recommended to delete the respective policies from the network before disabling the associated function pack (BWoD or CSM). If policies remain in the disabled function pack, this may cause issues with new policy delegation and increase processing time.

  1. From the main menu, choose Services & Traffic Engineering > Bandwidth on Demand > Configuration.

  2. Set Enable to True, enter 80 in the Link utilization field, and confirm that Advance > Policy violations is set to Loose. To find descriptions of other options, simply hover the mouse over Field Help icon.

  3. Click Commit changes.

Step 2

Create the first PCE-initiated BWoD SR-TE policy.

  1. From the main menu, choose Services & Traffic Engineering > Traffic Engineering > SR-MPLS tab and click Create > PCE init.

  2. Enter the required policy details. In this example, we are creating a policy with these values:

    • Headend: L1-NCS5501.cisco.sjc20.com

    • Endpoint: L5-8201-1-crosswork.cisco.com

    • Color: 70000

    Figure 3. Policy details


  3. In the Policy path area, click Bandwidth on demand, and enter the required policy path details. In this example, we use these values:

    • Path name: bwod-70000

    • Optimization objective: Interior gateway protocol (IGP) metric

    • Bandwidth: 7000 Mbps

    Figure 4. Policy path details

    Policy path details

  4. Click Preview . BWoD only takes into account current interface utilization that has been reserved by another BWoD policy. Otherwise, BWoD only considers the capacity of the interface in its calculations. In this example, all interfaces have the capacity of 1 Gbps. Since there are no existing BWoD policies, BWoD considers the capacity of all nodes and takes the shortest route.

    Figure 5. First BWoD policy (bwod-70000)

    Preview of bwod-70000 Policy

  5. If you are satisfied with the proposed BWoD SR-TE policy deployment, click Provision.

Step 3

Verify that the new BWoD SR-TE policy has been created.

  1. From the main menu, choose Services & Traffic Engineering > Traffic Engineering > SR-MPLS.

  2. Select the new BWoD SR-TE policy and view the SR policy details (click and choose View details).

Step 4

Create a second BWoD policy. In this example, we use these values:

  • Headend: L1-NCS5501.cisco.sjc20.com

  • Endpoint: L5-8201-1-crosswork.cisco.com

  • Color: 70001

  • Path name: bwod-70001

  • Optimization objective: Interior gateway protocol (IGP) metric

  • Bandwidth: 700 Mbps

BWoD considers the existing BWoD policy (bwod-70000) and its bandwidth requirement into its interface capacity calculations. So, a new path is created for the bwod-70001 policy.
Figure 6. New bwod-70001 policy

New bwod-70001 policy

Step 5

Create a third BWoD policy. In this example, we use these values:

  • Headend: L1-NCS5501.cisco.sjc20.com

  • Endpoint: L5-8201-1-crosswork.cisco.com

  • Color: 70002

  • Path name: bwod-70002

  • Optimization objective: Interior gateway protocol (IGP) metric

  • Bandwidth: 1000 Mbps

Since BWoD takes into account all previous BWoD policy requirements and the BWoD policy violation option was set to Loose , BWoD creates a best effort path for the bwod-70002 policy. You will receive this message when you provision the new policy:
Figure 7. Best effort message

Best effort message

Note that existing paths for bwod-7000 and bwod-70001 are moved to accommodate the new bwod-70002 policy.

Figure 8. BWoD policies with Loose option

bwod-70002 Policies

Step 6

Change the BWoD policy violation option to Strict (Services & Traffic Engineering > Bandwidth on Demand > Configuration > Advanced).

Step 7

Create a fourth BWoD policy. In this example, we use these values:

  • Headend: L1-NCS5501.cisco.sjc20.com

  • Endpoint: L5-8201-1-crosswork.cisco.com

  • Color: 70003

  • Path name: bwod-70003

  • Optimization objective: Interior gateway protocol (IGP) metric

  • Bandwidth: 1000 Mbps

Since the BWoD policy violation option is set to Strict , BWoD is not be able to overwrite existing BWoD policies, and the request for additional 1000 Mbps policy results in a "No solution found" message.
Figure 9. No solution found

No solution found

BWoD error messages

Some of the most common error conditions for BWoD and their possible corrective actions are listed below.

Table 4. Error event messages

Error event message

Possible causes and recommended corrective Aation

OptimaModelError

The network model used by BWoD from the Optimization Engine is corrupt or is missing key data needed to properly support BWoD. Possible causes include network discovery issues or synchronization problems between the Optimization Engine and Topology Services. Try restarting the Optimization Engine pod to rebuild the model.

This error can also occur if the time required to discover a policy and add it to the model after it has been deployed exceeds the Deployment Timeout option set for BWoD. The default is 30 seconds, sufficient for small to medium-sized networks. However, larger networks may require additional time.

NATSTimedOutError

The deployment of a bandwidth policy through SR-PCE exceeds the Deployment Timeout option set for BWoD. Increase the Deployment Timeout option to allow for additional time for deployments in larger networks.

Traceback or other errors found in the log file

Contact your Cisco service representative.