Resource Reservation Protocol (RSVP) is a signaling protocol that enables systems to request resource reservations from the
network. RSVP processes protocol messages from other systems, processes resource requests from local clients, and generates
protocol messages. As a result, resources are reserved for data flows on behalf of local and remote clients. RSVP creates,
maintains, and deletes these resource reservations.
The RSVP-TE process contains the following functionalities:
-
End-point control, which is associated with establishing and managing TE tunnels at the headend and tailend.
-
Link-management, which manages link resources to do resource-aware routing of TE LSPs and to program MPLS labels.
-
Fast Reroute (FRR), which manages the LSPs that need protection and to assign backup tunnel information to these LSPs.
The interactions between TE and RSVP assume the existence of the end-point control, link-management, and FRR functionality
within TE.
RSVP-TE Explicit Routing (Strict, Loose)
RSVP-TE explicit routes are particular paths in the network topology that you can specify as abstract nodes, which could be
a sequence of IP prefixes or a sequence of autonomous systems, in the Explice Route Object (ERO). The explicit path could
be administratively specified, or automatically computed using an algorithm such as constrained shortest path first (CSPF).
The explicit path specified in the ERO may be a strict path or a loose path.
A strict path means that a network node and its preceding node in the ERO must be adjacent and directly connected.
A loose hop means that a network node specified in the ERO must be in the path but is not required to be directly connected
to its preceding node. If a loose hop is encountered during ERO processing, the node that processes the loose hop can update
the ERO with one or more nodes along the path from itself to the next node in the ERO. The advantage of a loose path is that
the entire path does not need to be specified or known when creating the ERO. The disadvantage of a loose path is that it
can result in forwarding loops during transients in the underlying routing protocol.
Note |
RSVP-TE tunnels cannot be configured with loose hops when provisioning within the UI.
|
RSVP FRR
When a router’s link or neighboring device fails, the router often detects this failure by receiving an interface-down notification.
When a router notices that an interface has gone down, it switches LSPs going out that interface onto their respective backup
tunnels (if any).
The FRR object is used in the PATH message and contains a flag that identifies the backup method to be used as facility-backup.
The FRR object specifies setup and hold priorities, which are included in a set of attribute filters and bandwidth requirements
to be used in the selection of the backup path.
The Record Route Object (RRO) reports in the RESV message the availability or use of local protection on an LSP, and whether
bandwidth and node protection are available for that LSP.
The signaling of the FRR requirements is initiated at the TE tunnel headend. Points of Local Repair (PLR) along the path act
on the FRR requirements based on the backup tunnel availability at the PLR, and signal the backup tunnel selection information
to the headend. When an FRR event is triggered, the PLR sends PATH messages through the backup tunnel to the merge point (MP)
where the backup tunnel rejoins the original LSP. The MP also sends RESV messages to the PLR using the RSVP-Hop object that
is included by the PLR in its PATH message. This process prevents the original LSP from being torn down by the MP. Also, the
PLR signals the tunnel headend with a PATH-ERROR message to indicate the failure along the LSP and that FRR is in active use
for that LSP. This information is used by the headend to signal a new LSP for the TE tunnel, and to tear down the existing
failed path after the new LSP is set up through make-before-break techniques.
Feedback