What types of LSPs does NSP support?

PCC-initiated LSPs

NSP supports the creation of PCC-initiated Segment-Routed TE LSPs, as well as PCC-initiated RSVP LSPs. NSP's service management function sends a service creation request, through NFM-P, to the PCC router(s) endpoints which are part of the service. An empty LSP path is created on each of the PCC router(s). The PCC router(s) then send an LSP path request to NSP (PCE). NSP (PCE) computes the LSP path and sends the path to the PCC. The PCC then installs the computed path and informs NSP (PCE) that the path is ready. This is reported to NSP's service management function, where the path is attached to the service.

PCE-initiated LSPs

NSP supports the creation of PCE-initiated Segment-Routed TE LSPs. Operators can specify the LSP parameters and PCC address using an LSP creation form within NSP's path control function, or by using the NSP API. Operators can also select a path profile policy to associate to the LSP. There is also an NBI. PCE-initiated LSPs are deployed through PCEP.

In order to create a , the following commands must be executed on the node:

config>router>pcep>pcc

max-srte-pce-init-lsps <max-number>

Where max-number is a number between 0 and 8191, which can only be modified when config>router>pcep>pcc is shutdown.
config>router>mpls# lsp-template template-name pce-init-p2p-srte {default | template-id } default-path {pathname}

path "P"

no shutdown

exit

lsp-template "test" pce-init-p2p-srte template-id default

default-path "P"

cspf

pce-report enable

no shutdown

exit
config>router>mpls>

pce-initiated-lsp sr-te

no shutdown

RSVP LSPs

Any PCC node intending to request a path computation from NSP must first set the PCE computation option in the LSP definition. The PCC then assigns a unique PLSP-ID to the LSP. This uniquely identifies the LSP within a PCEP session and is maintained for the lifetime of the LSP. The PLSP-ID is also associated to the tunnel and path ID.

Once the PLSP-ID is assigned, the PCC sends a PCReq message to NSP PCE, requesting a path for the LSP. This request includes the LSP parameters in the METRIC object, the LSPA object, and the Bandwidth object. It also includes the LSP object with the selected PLSP-ID. NSP is now able to compute a new path, to check the bandwidth, and to return the path in a PCRep message with the computed Explicit Router Object (ERO) in the ERO object. It also includes the LSP object with the unique PLSP-ID, the METRIC object with the computed metric value (if any), and the Bandwidth object.

NSP does not keep track of the LSP yet. At this point, it has simply returned the ERO. The PCC has yet to confirm that the path was signaled. If the path was locally signaled, and the local TE database (TEDB) was updated, NSP receives the updates via BGP-LS and update its TEDB.

For stateful operation, which allows NSP to track the LSP path and bandwidth (among other constraints), the PCE report option must be set in the LSP definition. When this option is set, the PCC sends both a PCRpt message to update NSP with the state of UP, and the Record Route Object (RRO) object as confirmation. The RRO object now includes the LSP object with the unique PLSP-ID. With this, NSP is able to display the LSP, as well as its hops and constraints on the path control network map. The RRO also contains information about the protection that is enabled on the signaled path. Therefore, NSP is aware of the protection at the hops, but not aware of the detour/bypass tunnel details. If a local failure causes the LSP on the PCC to switch to a detour or bypass, a PCE report is sent to NSP, and NSP becomes aware that the LSP is using a detour or bypass.

Note: In the VSR-NRC, the PCE reporting option can either be set globally, or on a per LSP basis.

The PCC can also delegate control of the LSP to NSP for either active control or LSP optimization. This is known as active stateful behavior. The delegation is awarded using the PCE control option. Once NSP is controlling the LSP, the operator can manually re-signal/re-optimize the LSP. Re-signalling routes the LSP using its original constraints, while re-optimizing routes the LSP using an optimization algorithm. NSP also reroutes LSPs automatically on resource failures, or when calculating disjoint paths.

Note: When the PCC has delegated control of the LSP to NSP, any change to the LSP definition (such as changes in constraints) requires the PCC to first revoke the delegation via the PCE report option, and then to issue a new request to NSP.

Secondary path behavior

The PCC sends PCE requests for standby secondary paths. A new PLSP-ID is used for these paths over the PCEP session, and is associated to the LSP path ID and the LSP tunnel ID. When a secondary path is not in standby, the PCE request is not sent until the primary path is down, or in FRR. However, if the path is delegated to NSP, this results in a PCE update from NSP. The LSP may switch to the secondary path in the interim, but will switch back to the primary path as soon as possible.

NSP maintains the active path in case both the primary and secondary paths are signaled, and also when the primary path is down. NSP also maintains the shared explicit behavior when the primary and secondary paths share common link resources.

NSP also indicates the active path between the primary and secondary pair.

FRR notification

Fast reroute (FRR) is signaled locally, with locally-created detour tunnels. These tunnels are not reported to NSP, and therefore NSP is not aware of the detours and bypass. However, the types of node and/or link protection are communicated to NSP via the PCE report.

Note: All the RSVP-TE LSPs created by NSP have FRR enabled by default. The FRR method used is “facility”.

Bandwidth management

NSP manages the LSP bandwidth consumption on the TE links for both stateless and stateful PCC configurations. In a stateless configuration, NSP receives TE updates from the network as LSPs are signaled, thereby mimicking the TE DB bandwidth consumption on the nodes. This allows for accurate LSP path computation without maintaining state on NSP. In a stateful case, wherein the reports are sent to NSP from the PCC, the bandwidth is again communicated by the PCC to NSP via the bandwidth object. Here, NSP will reconcile the TE update with the specific LSP bandwidth update via the report. Therefore, NSP maintains full LSP state along with the consumption on the TE links for these LSPs only.

It is possible that existing brownfield LSPs will not request paths from NSP, and therefore, will have no state within NSP. NSP will not display these LSP reservations on the TE links. For a mixture of LSPs that are PCE-reported and non-PCE-reported, NSP will track and show the actual TE consumption on a TE link in addition to the LSP reservation for PCE-reported LSPs.

Although bandwidth is not tracked until reported, bandwidth is reserved for one (1) minute when a request is made. Therefore, if multiple requests are made in quick succession, subsequent requests will be impacted, even though reports have not yet been received.

Segment-routed TE LSPs

Any PCC node intending to request a path computation from NSP must first set the PCE computation option in the LSP definition. The PCC then assigns a unique Path LSP-ID (PLSP-ID) to the LSP. This uniquely identifies the LSP within a PCEP session and is maintained for the lifetime of the LSP. The PLSP-ID is also associated to the tunnel and path ID.

Once the PLSP-ID is assigned, the PCC sends a PCReq message to NSP PCE, requesting a path for the LSP. This request includes the LSP parameters in the SRP object, the METRIC object, the LSPA object, and the Bandwidth object. It also includes the LSP object with the selected PLSP-ID. NSP will reserve bandwidth for the path to be returned, but will not keep track of the operational status or other requirements for the LSP yet. At this point, bandwidth is consumed and an ERO is returned. The PCC has yet to confirm that the path was signaled. If the path was locally signaled, and the local TEDB has been updated, NSP will receive a REPORT from the PCC and the updates via BGP-LS and update its TEDB. If the PCC fails to send a report, after a period of time the bandwidth reserved will be released from NSP. The path computed by NSP is specified explicitly with the next hop interfaces and the adjacency SIDs encoded in the SR ERO sub-object.

When the PCE report option is set in the LSP definition, the PCC sends both a PCRpt message to update NSP with the state of UP, and the RRO object as confirmation. The RRO object now includes the LSP object with the unique PLSP-ID. With this, NSP is able to display the LSP, as well as its hops and constraints. The RRO also contains information about the protection that is enabled on the signaled path. Therefore, NSP is aware of the protection at the hops, but not aware of the detour/bypass tunnel details. If a local failure causes the LSP on the PCC to switch to a detour or bypass, a PCE report is sent to NSP, and NSP becomes aware that the LSP is using a detour or bypass.

Note: In the VSR-NRC, the PCE reporting option can either be set globally, or on a per LSP basis.

Note: When the PCC has delegated control of the LSP to NSP, any change to the LSP definition (such as changes in constraints), requires the PCC to first revoke the delegation via the PCE report option, and then issue a new request to NSP.

SR-TE LSPs with PCE delegation support primary and secondary LSP paths. Switching between the LSP paths is accomplished on the node using sBFD to provide quick switches at the head-end when TI-LFA is unable to solve all network faults. NSP can force the primary path to be the most optimal path of a diverse pair by choosing a path-profile with diversity set and by setting the priority <setup-priority> appropriately on the primary and secondary paths.

Bandwidth management

A bandwidth value that is specified on an LSP has no significance on the PCC/router because the SR TE does not maintain any state on the intermediate or destination routers. Therefore, no bandwidth tracking is done in the local TE DB. The bandwidth has to be tracked by NSP if the LSP is configured to report bandwidth. Bandwidth tracking on NSP is done only after a valid PCE report message is generated by the PCC. NSP tracks the bandwidth reservation for SR TE LSPs separate from RSVP TE LSPs.

Note: A loose hop SR LSP whose bandwidth is specified and computed locally will not be tracked by NSP, even with the PCE report option enabled. NSP only tracks SR TE LSP paths computed by NSP itself.

Failure detection

The head end router for an SR TE path, or an SR path, has no indication when a downstream link failure has impacted traffic for that SR TE or SR path. For a stateless and stateful application without PCE control, the SR TE tunnel on the head end router will remain up, as it receives no notification from the control plane either locally, or via NSP. For an LSP with delegated control to NSP, NSP will react to the topology change and issue a new ERO update to the PCC via PCE update.

TE-ECMP routing

Traffic Engineered Equal Cost Multi-path routing (TE-ECMP) enables users to create multiple equal-cost paths that NSP controls as a single LSP, thereby achieving the same protection as a pair of disjoint services. TE-ECMP is ideally-suited to leaf-spine architectures, whereby load balancing can be accomplished by a leaf connecting to multiple spine switches, and/or multiple parallel links being created between spine switches. The flexibility of SR networks further enhances this solution, as – in addition to node SIDs – traffic can be directed to either Anycast SIDs (which can be associated with multiple spine nodes) or Adjacency Set SIDs (which are shared by the parallel links that comprise the set).

When TE-ECMP routing is used, NSP identifies multiple equal-cost paths between a source and destination based on an objective metric, as known as an 'ECMP Tree'. NSP then creates an Explicit Route Object (ERO) that captures how best to implement this tree using a combination of the available SID types. The path information is then sent to the originating node via PCEP. Capacity can then be added to the network seamlessly (for example, by introducing a new link to an Adjacency Set, or by adding a new spine switch into an Anycast SID group), because the EROs which define the path do not have to change. As the network evolves and the configuration of the SR fabric changes, NSP remains synchronized with this data and adjusts the ERO accordingly.

Path diversity (SRLG only)

Multiple SR TE LSPs, each with their own set of ECMP paths, can exist simultaneously and remain disjoint from one another. This is accomplished by specifying that the paths remain SRLG diverse (Shared Risk Link Group). As the paths traverse the links between data centers, connections can pass through the same conduit, making them subject to a single fiber cut. However, when the LSPs are specified as being SRLG diverse, only the links for which SRLG values have been configured are considered by the paths.

Blackholing prevention

When a single link in an adjacency set goes down, traffic is forwarded over the remaining links in the set – however, if all links in the set were to fail, blackholing could occur. To prevent this, NSP has the ability to learn topology changes and diagnose problems. It would calculate a new ERO in order to avoid failed links. For example, if a leaf switch were sending traffic to two spine switches using their shared Anycast SID, and one of those spine switches was forwarding traffic over the failed link, the ERO would begin sending traffic to the other spine switch using it's unique Node SID instead, thereby bypassing the failed link.

Path persistency

When two LSPs are deployed with diversity, the goal is often to ensure that at least one of them will remain operationally up when failures occur in the network. However, these dual LSPs can serve other purposes, such as load balancing, or designating specific traffic for specific paths.

In these scenarios, the primary LSP typically follows the shortest path and has the lowest latency, while the secondary LSP typically takes a longer path and has a higher latency. As such, it is often necessary for services that are latency sensitive to be routed over the primary LSP. In the event that both LSPs go down, it is therefore important that the paths are not swapped during restoration.

For this reason, NSP supports path persistency. This ensures that, if the secondary LSP comes up before the primary, it will be rerouted off the shortest path once the primary LSP is again available.

SID types

Node SIDs and Adjacency SIDs both identify entities through which traffic must be routed, however, Adjacency SIDs identify an exact path, whereas Node SIDs follow the IGP shortest path. Therefore, when a link fails while Adjacency SIDs are being used, the path is down (unless Loop-Free Alternative kicks in). But when a link fails while Node SIDs are being used, traffic is rerouted (as long as the next node is still resolvable).

By extension, Anycast SIDs behave similar to Node SIDs, and Adjacency Set SIDs behave similar to Adjacency SIDs. Operators may have different preferences in terms of SID usage. One may prefer using Node SIDs because of their inherent load balancing and resiliency features, while another may prefer using Adjacency SIDs because the resulting path is strictly deterministic. TE-ECMP routing allows the operator to specify a preference in terms of SID usage.

Segment label depth

SR TE LSPs are limited by hardware support for the number of labels in the stack of a segment-routed path. In order to minimize the number of labels, the path must be comprised of a mixture of adjacency SIDs (which adhere to the TE path, but require labels for every hop), and node SIDs (which do not adhere to the TE path, but require fewer labels). An algorithm is introduced to employ this technique when the Explicit Route Strategy of the LSP's path profile policy is set to “Compressed”.

Note: To ensure that the node SID hops continue to adhere to the TE path, and that the path is valid, the controller must support IP path monitoring.

Anycast and loopback for LSPs

NSP supports path computation requests that include anycast or loopback addresses as destinations.

When inter-domain with multiple instances on routers are supported, NSP can specify a loose hop ERO with anycast loopbacks as intermediate hops. This allows for the generation of an inter-domain ERO between domains when domain boundary routers have anycast loopbacks configured.

The ERO generation is controlled via a path profile policy with a new ERO specification option field. If the specification is anycast preferred, then the inter-domain computed path will consist of border routers which have the anycast configuration as loopback addresses with identical anycast SIDs. If the specification is loose hop preferred, then the inter-domain computed path will consist of the best loose hop border routers with node SIDs.

Note: Anycast SIDs are node SIDs that are associated to the loopback addresses instead of the system address. In SROS, there is no specific designation for anycast SIDs.

Note: The ERO specification default is the complete path with Adjacency SIDs, however, in the inter-domain cases, the number of Adjacency SIDs will most likely exceed the MSD.

Note: When the anycast preferred ERO specification is used and the inter-domain border routers do not have anycast SIDs, the best loose hop node SID among the inter-domain border routers will be selected.

BGP-LS Application Specific Link Attributes

VSR-NRC learns link attributes from the network using BGP-LS and/or IGP and then uses advertise these to NSP using BGP-LS. This information can then be used by NSP when performing path calculations. These link attributes are displayed within the path control network map and can be configured using the NSP's APIs. The BGP-LS Application Specific Link Attributes (ASLA) TLV is used to advertise the link attributes, including link delay attributes such as Unidirectional Link Delay and Min/Max Unidirectional Link Delay. These two attributes can be measured using TWAMP-light delay in order to provide latency information that can be used for rerouting LSPs. This advertisement is application specific, which allows for segment routing to be enabled and used without having to enabling RSVP in the network.

Use subject to agreed restrictions on disclosure and use.