NSP provides a load-balancing and optimal-path-placement algorithm, known as the STAR algorithm. This algorithm uses an internal metric, calculated from the current value of the TE bandwidth reservation, to route the CSPF paths. Every path that is allocated on a TE link changes the internal metric for both the link and the overall path. Initially, all links have the same star weight, or metric, so the first path requests for CSPF traversal will choose the shortest path that satisfies all constraints. If there are multiple paths that satisfy the user constraints, then a path will be chosen randomly. This behavior is the same for normal CSPF.

Subsequent requests will choose paths that possess the least star weight, thereby ignoring the path that the normal CSPF algorithm would have chosen. The calculation of the star weight is based on a formula that uses the current link reservation. The user constraints are still satisfied. This balances the overall network utilization.

The STAR algorithm is invoked per LSP by associating that LSP to a path profile policy. The path profile template is defined using NSP and requires setting the objective to use STAR WEIGHT. The path profile policy is specified with the LSP definition and is conveyed to NSP via a PCE request message.

NSP provides support for disjoint path computation between a source destination pair and between two pairs of sources and destinations. Applications can use this algorithm to provide no-impact redundancy for a service offering. The algorithm provides node/link and SRLG types of disjoint path computations. The algorithm can also re-optimize an existing path if a second path request asks to be disjoint from the existing path. The ability to treat a pair of paths as mutually disjoint requires associating a path profile ID to the path request. In addition, a path group ID specification is also essential to implicitly identify the path pair from other path pairs. The disjoint optimal path calculation algorithm can also compute paths that are bidirectionally symmetric, to ensure that forward and reverse traffic use the hops while being disjoint.

Note: NSP can only compute bidirectionally symmetric forward or reverse paths. For an RSVP LSP with primary and secondary path specification, the profile is applied to both paths. For example, if there are two RSVP LSPs between the respective distinct sources and destinations, the primary path of LSP 1 will be mutually disjoint from the primary path of LSP2, and vice versa for secondary paths. The algorithm cannot be applied to ensure the primary and secondary paths between the same source and destination pair are mutually disjoint.

The NSP's path control function supports the Global Concurrent Optimization algorithm (GCO). When an LSP is prevented from following a desired path that meets its constraints because one or more preexisting LSPs are currently using those resources, GCO can be used to analyze all of these LSPs simultaneously and calculate optimal paths for each of them. In this way, GCO produces a result similar to the Path Star algorithm - however - GCO is executed against multiple LSPs, whereas Path Star is executed against just one. As such, GCO has a higher computation cost and greater potential impact to the network (many changes can be triggered), and should therefore only be executed on an as-needed basis.

Note: GCO should not be used to balance utilization. It is preferred that the Path Star algorithm be used along with Utilization-based Telemetry Optimization for that purpose.

Note: GCO does not take all Path Profile attributes into account, and therefore, may create paths that are contrary to the Path Profile's objectives. A subsequent re-signal will apply all Path Profile constraints and may tear down these created paths. Path Profile objectives will attempt to return the path to a desired route rather than any created by GCO.

Note: Diverse routed and bidirectionally co-routed LSPs are not supported by GCO and are filtered out of its calculations.