Cisco Crosswork Network Controller 7.2 Traffic Engineering and Optimization

PDF

Cisco Crosswork Network Controller 7.2 Traffic Engineering and Optimization

Resource reservation protocol

Updated: August 4, 2025

Want to summarize with AI?

Log in

Reserves network resources along explicit data paths to ensure critical applications meet quality of service standards. It provides essential capabilities such as endpoint control, link management, and fast reroute mechanisms to maintain connectivity and restore traffic flow rapidly during network failures.

Resource Reservation Protocol-Traffic Engineering (RSVP-TE) is a signaling protocol that:

  • allows systems and clients to request and reserve network resource reservations,

  • creates, maintains, and deletes those reservations along explicit data paths, and

  • ensures critical applications receive the necessary bandwidth and network resources to meet the desired QoS standards.

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.