9.3 RSVP-TE and Traffic Engineering

Supporting context: why engineer a transport path?

The current NRS I outline introduces MPLS transport and explicitly names LDP. Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE) is supporting context for understanding other transport choices in established SR OS networks. Treat this lesson as a comparison, not a claim that Nokia publishes a dedicated current NRS I RSVP-TE domain.

An ordinary IGP chooses paths using its metrics. Those metrics need not reflect instantaneous utilization. If a low-metric path is congested while a higher-metric alternative has capacity, following the IGP alone may not distribute the offered traffic as an operator intends.

Traffic engineering can select paths using additional constraints. RSVP-TE signals explicitly routed label-switched paths and can perform bandwidth admission control. A reservation is control-plane accounting; it is not automatically a traffic policer, scheduler, or guarantee of application performance.

Constrained path calculation

Constrained Shortest Path First (CSPF) uses topology and traffic-engineering information. A simplified process removes links that fail the constraints, then calculates an acceptable path over the remaining graph.

Suppose the requested LSP bandwidth is 50 Mb/s. The shortest-metric path includes a link with only 20 Mb/s available for the relevant reservation priority. An alternative has 80 Mb/s available on every required link. Under those stated constraints, the 20 Mb/s link is excluded and the alternative may be eligible.

This example does not mean CSPF measures current traffic perfectly. The Traffic Engineering Database (TEDB) contains advertised information and reservation state, which can change while signaling is in progress. Admission control during setup remains necessary.

A color such as “gold” is an operator-defined classification, not an inherent physical property. Correct configuration must keep the labels consistent with the intended links.

Strict and loose explicit hops

An Explicit Route Object (ERO) describes the intended path or waypoints. A strict hop requires the specified adjacency under the route object's rules. A loose hop permits intermediate nodes between specified waypoints.

A strict sequence can pin an LSP to particular links, but a failed required link can prevent that path from being established. A loose waypoint offers flexibility; it does not permit ignoring the waypoint entirely.

The Record Route Object (RRO) can record actual traversal information when requested and supported. ERO and RRO are not interchangeable: one describes intended routing constraints, while the other records information about the signaled path.

PATH and RESV

RSVP-TE setup has two important message directions:

1. The ingress sends a PATH message toward the egress, carrying path and traffic information and requesting label setup.
2. The egress and intermediate nodes return RESV messages upstream, supplying label bindings and the relevant reservation state.
3. Successful signaling installs the label-forwarding actions needed for the LSP.

A downstream router tells its upstream neighbor which label it expects on arriving traffic. Labels can differ at successive hops. The resulting data path is unidirectional; a reverse LSP requires separate state.

RSVP is carried directly over IP, protocol 46, rather than using LDP's TCP or UDP port 646. RSVP maintains soft state through refresh mechanisms, with extensions that can reduce refresh overhead. Do not substitute BGP or LDP timers for RSVP state handling.

Errors can occur because resources changed, a required hop is unreachable, or parameters are unsupported. A path calculated by CSPF is a candidate, not proof that signaling succeeded.

Fast reroute

Fast Reroute (FRR) provides local protection through prepared alternate forwarding. The Point of Local Repair (PLR) redirects traffic around a protected failure toward a Merge Point.

Facility backup can use a bypass tunnel to protect multiple LSPs crossing a link or node. Label stacking steers protected traffic through the bypass. One-to-one backup uses detour state associated with individual protected LSPs.

These are protection designs, not universal timing promises. Recovery time depends on detection, hardware, configuration, backup availability, and the failure type. Sub-50-millisecond objectives can be relevant engineering targets, but they do not prove five-nines availability or guarantee zero loss.

Link protection avoids a failed link. Node protection must avoid the failed node itself. A path that traverses the failed node through another interface does not provide node protection.

Compare with LDP

LDP in the basic model follows usable IP routing information and distributes prefix label bindings. RSVP-TE adds explicit path and reservation signaling at the cost of additional state and configuration.

Services can use different transport mechanisms without changing the customer's fundamental Layer 2 or Layer 3 service choice. However, changing transport can affect MTU, protection, and operational dependencies. An SDP or VPRN tunnel-resolution setting must select an actually available transport.

When diagnosing an engineered LSP, check the destination, computed/explicit path, signaling state, reservation constraints, and active protection. Do not infer an RSVP LSP's operational status merely because OSPF and LDP sessions are healthy.

Primary references

RSVP-TE specification and RSVP-TE fast reroute, checked October 20, 2026. Additional Nokia configuration requires the matching release manual.