MPLS Traffic Engineering — RSVP-TE, SR-TE, and Fast Reroute

Traffic Engineering (TE) gives an operator the ability to steer packets along paths that an IGP would never choose on its own. Instead of letting shortest-path routing collapse every flow onto the cheapest link, TE introduces a second forwarding plane — label-switched tunnels signalled by RSVP-TE or encoded as Segment Routing label stacks — that honour constraints such as available bandwidth, latency, link colour, and administrative policy. This chapter covers both the classic RSVP-TE control plane and the modern stateless SR-TE model, the Fast Reroute mechanism that keeps carrier-grade services online during fibre cuts, and the practical use cases that justify the added complexity in a Tier-1 backbone.

Cards: 4

RSVP-TE

The original MPLS-TE control plane. Signals per-LSP state across every transit router and reserves bandwidth through PATH/RESV message exchange driven by CSPF on an IGP-TE database [1].

SR-TE

The stateless replacement. The ingress PE pushes a label stack that encodes the full path; transit routers hold no per-tunnel state and simply pop the top segment [7, 8].

Fast Reroute (FRR)

Pre-computed backup tunnels activated at the point of failure. Cuts recovery from multi-second IGP convergence down to roughly 50 ms — the SLA floor for voice and financial services [2].

CSPF

Constrained Shortest Path First: Dijkstra run against the Traffic Engineering Database with extra constraints (bandwidth, affinity, priority, hop count) beyond pure IGP cost.

The Problem Traffic Engineering Solves

Key Insight

An IGP has no idea a link is congested. Shortest-path routing steers every flow onto the “best” metric path until it melts, while parallel capacity sits idle.

Consider an operator running a backbone between New York and Los Angeles with two transcontinental paths: a direct 4000 km fibre (IGP cost 40) and a 4500 km path via Chicago (cost 45). OSPF or IS-IS will push 100% of the east-west traffic onto the direct fibre even when that fibre is at 95% utilisation and the Chicago path sits at 5%. The IGP cannot see bandwidth, queue depth, or congestion — only its own metric.

Dimension	Plain IGP routing	Traffic Engineering
Path selection input	IGP metric only	Bandwidth, latency, affinity, priority, IGP metric
Load balancing	ECMP across equal-cost only	Arbitrary split across any computed tunnels
Failure recovery	Seconds (SPF reconvergence)	~50 ms (pre-computed FRR)
Per-flow steering	Not possible	Per-LSP or per-class steering
Control-plane state	IGP LSDB only	IGP LSDB + TED (+ per-LSP state for RSVP-TE)

TE does not replace the IGP — it overlays an explicit forwarding plane on top of it. The IGP still supplies reachability to loopbacks; TE tunnels ride that reachability while adding their own path constraints.

graph LR
    NY[PE-NewYork]
    CHI[P-Chicago]
    LA[PE-LosAngeles]
    NY -->|"direct 4000 km, cost 40, 95% util"| LA
    NY -->|"via Chicago, cost 45, 5% util"| CHI
    CHI -->|"cost 45 leg 2"| LA
    NY -.->|"TE tunnel forces the idle path"| CHI

RSVP-TE: The Classic Control Plane

RSVP-TE uses the Resource Reservation Protocol to signal Label Switched Paths (LSPs) and reserve bandwidth along them [1]. Each LSP is unidirectional — from a head-end (ingress PE) to a tail-end (egress PE) — so a bidirectional service requires two LSPs [1].

The Five Building Blocks

flowchart TD
    A[IGP-TE extensions<br/>OSPF-TE / IS-IS-TE TLVs] --> B[TED<br/>Traffic Engineering Database]
    B --> C[CSPF<br/>Constrained Dijkstra]
    C --> D[RSVP PATH<br/>head-end → tail-end]
    D --> E[RSVP RESV<br/>tail-end → head-end]
    E --> F[LSP operational<br/>label-switched forwarding]

Component	Role
IGP-TE extensions	OSPF-TE or IS-IS-TE TLVs advertising per-link total bandwidth, reservable bandwidth, unreserved bandwidth at 8 priority levels, administrative colours (affinity bits), and a separate TE metric distinct from the IGP metric [4, 5].
TED	Per-router database of every link with all extended attributes. Kept separate from the regular SPF topology.
CSPF	Constrained Dijkstra run on the TED. The head-end asks “find a path from PE1 to PE4 with 2 Gbps available, excluding red links, preferring low latency.” The output is an explicit route [16].
RSVP PATH	Message sent from head-end along the computed path. Each transit router reserves bandwidth and allocates a label [1].
RSVP RESV	Reply returning from tail-end to head-end, confirming the reservation and distributing labels upward [1].

Once RESV reaches the head-end, the LSP is live [1]. Any traffic injected into the tunnel is label-switched along the explicit path — the IGP’s opinion is irrelevant from that point forward.

Signalling Sequence

sequenceDiagram
    participant H as Head-end PE1
    participant P1 as P1
    participant P2 as P2
    participant T as Tail-end PE4
    H->>H: CSPF against TED<br/>(bandwidth + affinity constraints)
    H->>P1: PATH (ERO, bandwidth=2G)
    P1->>P1: Reserve 2G, allocate label L1
    P1->>P2: PATH
    P2->>P2: Reserve 2G, allocate label L2
    P2->>T: PATH
    T->>T: Allocate label L3 (implicit-null)
    T->>P2: RESV (label=L3)
    P2->>P1: RESV (label=L2)
    P1->>H: RESV (label=L1)
    Note over H,T: LSP operational; head-end pushes L1 onto tunnel traffic

Configuration Example

interface Tunnel100
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 10.0.0.14
 tunnel mpls traffic-eng bandwidth 2000000
 tunnel mpls traffic-eng path-option 1 explicit name PATH-VIA-P2
 tunnel mpls traffic-eng path-option 2 dynamic
 tunnel mpls traffic-eng affinity 0x1 mask 0xFFFF
!
ip explicit-path name PATH-VIA-P2
 next-address 10.0.0.2
 next-address 10.0.0.14

Line	Meaning
tunnel mode mpls traffic-eng	Declare this tunnel an RSVP-TE LSP.
tunnel destination 10.0.0.14	Tail-end PE’s loopback.
tunnel mpls traffic-eng bandwidth 2000000	Reserve 2 Gbps (kbps) along the entire path.
path-option 1 explicit name PATH-VIA-P2	Primary: follow the named explicit ERO.
path-option 2 dynamic	Fallback: let CSPF compute any path that meets the constraints.
affinity 0x1 mask 0xFFFF	Include only links whose colour bit 0 is set; mask checks the low 16 bits, high 16 bits are don’t-care (Cisco affinity word is 32 bits).

Key RSVP-TE Features

Fast Reroute — The Killer Feature

Key Insight

FRR is why Tier-1 operators tolerate RSVP-TE’s complexity. It converts link or node failures from seconds-long outages into sub-50 ms blips that voice and trading customers never detect.

When a link on a protected LSP fails, a pre-computed backup tunnel at the point of local repair (PLR) immediately swings traffic around the break [2]. The head-end recomputes the primary path in the background, but the service never actually dropped.

Protection mode	Scope	Backup path characteristic
Link protection	Single link failure	Backup tunnel avoids the protected link [2].
Node protection	Entire downstream router failure	Backup tunnel avoids the protected node and all of its links [2].
SRLG protection	Shared Risk Link Group failure (e.g. multiple logical links sharing a single fibre conduit)	Backup tunnel avoids every link in the protected SRLG, not just the primary link.
Bare IGP reconvergence (no FRR)	—	2-5 seconds typical
RSVP FRR	—	~50 ms [2]

Per RFC 4090, link and node protection are implemented via either facility-backup bypass tunnels (a single bypass protects many primaries — NHOP for link protection, NNHOP for node protection) or one-to-one detour LSPs (a dedicated detour per protected primary) [2]. Facility-backup is the dominant deployment model in Tier-1 backbones because it scales sub-linearly with the number of protected LSPs [2, 16].

graph LR
    PE1 -->|primary L1| P1
    P1 -->|primary L2| P2
    P2 -->|primary L3| PE4
    P1 -.->|pre-computed backup| P3
    P3 -.->|backup merge| P2
    style P1 fill:#ffd,stroke:#c90

Auto-Bandwidth

Manually reserving 2 Gbps works until the traffic profile changes. Auto-bandwidth replaces that with a feedback loop: the head-end samples tunnel throughput on an interval (typically 5 minutes) and resignals the LSP with an updated reservation [16]. Vendor implementations (Cisco, Juniper) typically use the maximum of sampled averages within the adjust interval [16]. 95th-percentile is a billing/reporting convention often computed externally and fed to a controller, not the on-router auto-bandwidth algorithm.

Parameter	Typical value	Purpose
Sample interval	5 min	How often utilisation is measured.
Adjust interval	24 h	Window over which sampled averages are aggregated.
Aggregation	max-of-averages	Vendor default (Cisco/Juniper) — pick the largest sampled average in the adjust interval.
Headroom	+20%	Safety margin above the aggregated value.
Reoptimise timer	Daily	When the new reservation is signalled.

Affinity and Administrative Colours

Each link carries a 32-bit colour word (RFC 3630/5305) [4, 5]; RFC 7308 extends this to arbitrary multiples of 4 bytes via Extended Administrative Groups for networks needing more than 32 colours [6]. TE tunnels can include an affinity and mask pair to constrain CSPF to specific link classes.

Colour bit	Example meaning	Typical constraint
0x01	Domestic backbone	Include for low-latency domestic tunnels
0x02	Transatlantic submarine	Include for intercontinental services
0x04	Satellite	Exclude for latency-sensitive tunnels
0x08	Leased third-party	Exclude from sovereign-customer tunnels

LSP Priority and Pre-emption

Each LSP has two priorities in the range 0-7 (lower number = higher priority):

Priority	Role
Setup priority	Determines whether this LSP can pre-empt existing LSPs when signalling.
Hold priority	Determines whether this LSP resists pre-emption from newer LSPs.

A premium voice LSP with setup 1 / hold 1 can knock a best-effort LSP with hold 5 off a link when bandwidth is tight — guaranteeing capacity for SLA-bound services during congestion.

Segment Routing TE — The Modern Approach

Key Insight

SR-TE removes per-LSP state from the transit path entirely. The packet carries its own instructions as a label stack; the core becomes a stateless label-switching fabric.

RSVP-TE’s hidden cost is per-LSP soft state on every transit router [1]. A network with thousands of tunnels has thousands of per-LSP reservations to refresh, thousands of FRR backups to track, and a matching volume of RSVP signalling churn when topology changes — refresh-reduction extensions (summary refresh) mitigate but do not eliminate the overhead [3]. SR-TE discards that entire model [7].

With SR-TE, the ingress PE pushes a label stack such as [Node-P1][Adj-P1→P2][Node-PE4] [7, 8]. Each router pops the top label and forwards according to the remaining stack [8]. No router except the head-end knows a “tunnel” exists [7].

The Two Segment Types

Segment type	Scope	Semantics
Node segment (Node-SID)	Globally unique, advertised by IGP	”Reach router X via shortest path.” Behaves like a loose hop [7, 9].
Adjacency segment (Adj-SID)	Locally significant per link	”Use this specific outgoing link.” Behaves like a strict hop [7, 9].

Mix the two to control path granularity: an all-Adj-SID stack enforces a strict hop-by-hop explicit route; an all-Node-SID stack describes a loose path; a mixed stack pins the critical hops and lets the IGP fill in the rest.

graph LR
    PE1[PE1<br/>ingress]
    P1[P1]
    P2[P2]
    PE4[PE4<br/>egress]
    PE1 -->|push<br/>Adj-P1P2 · Node-PE4| P1
    P1 -->|pop → Adj-P1P2| P2
    P2 -->|pop → Node-PE4<br/>IGP shortest path| PE4

Why SPs Are Migrating to SR-TE

Motivation	Detail
Zero per-LSP state in the core	Only the head-end knows about the tunnel. Transit routers are pure label switches [7, 8].
Simpler operations	No RSVP refreshes, no soft-state timers, no LDP/RSVP synchronisation gotchas [17].
Multi-vendor interop	SR is a clean IETF standard; RSVP-TE accumulated vendor-specific extensions.
SDN-native	A PCE computes paths centrally and delivers label stacks to ingress PEs over PCEP [10, 13, 14, 15]. The northbound link-state and TE topology feeding the PCE is distributed via BGP-LS [12]. SR Policy candidate paths are identified by the (color, endpoint) tuple with a preference attribute [10].
TI-LFA replaces FRR	Topology Independent Loop-Free Alternate is SR’s native local protection — simpler and coverage-complete; no separate backup-tunnel signalling is needed [11]. TI-LFA still pre-computes a repair label stack at the PLR, but the post-convergence path is encoded as an SR label stack rather than a signalled bypass tunnel [11].

Note

Most modern Tier-1s (Telia, Orange, BT, Comcast, and peers) have either fully migrated to SR-TE or are actively deploying it — typically SR-MPLS in the core, with SRv6 appearing in some greenfield builds.

RSVP-TE vs SR-TE at a Glance

Property	RSVP-TE	SR-TE
Control protocol	RSVP	None on the transit path (IGP + optional PCEP for computation)
Per-LSP state in transit nodes	Yes	No
Bandwidth admission control	Native (per-LSP reservations in TED)	External (controller-side accounting)
Local protection	FRR with pre-computed backup tunnels	TI-LFA (always-on, automatic)
Operational weight	High (soft-state churn)	Low (stateless)
SDN integration	Limited	Native via PCE / PCEP
Typical deployment state	Legacy / maintenance	Primary target for new builds

How SPs Actually Use Traffic Engineering

Use case	Mechanism	Customer-visible outcome
Bandwidth optimisation	Auto-bandwidth full-mesh tunnels between PEs; head-end steers iBGP traffic into tunnels with capacity.	No hot-spots on “best” paths; predictable core utilisation.
Low-latency premium circuits	Explicit tunnels avoid satellite and high-latency segments even when IGP would pick them.	”Financial trading VPN” products with contractual latency bounds.
Disjoint path pairs	Two tunnels computed to be fully node-disjoint.	Active-active or 1+1 protected services that survive any single-router failure.
Congestion offload	Explicit tunnels manually shift specific high-volume flows (e.g. a major peering) onto longer but less-loaded paths.	Avoid capex-deferring link upgrades while traffic patterns stabilise.

Warning

TE is not a substitute for capacity. An over-subscribed backbone running at 80% average utilisation cannot be saved by TE — TE only redistributes existing headroom. Operators still need to dimension capacity; TE makes them get more out of what they already built.

See Also

• Tier-1 SP Architecture & L3VPN — defines the PE/P MPLS core topology and LDP-based label forwarding that TE tunnels extend and override. TE tunnels replace LDP-assigned transport labels for traffic that needs constraint-based steering.
• SP Services: DIA, L2VPN, VPLS, EVPN — the DIA section references customer-side traffic engineering via full BGP tables. SP-side TE tunnels (this chapter) are the complementary backbone mechanism that shapes how that traffic traverses the provider’s core.

References

1. RFC 3209 — RSVP-TE: Extensions to RSVP for LSP Tunnels. D. Awduche et al., IETF, December 2001. https://www.rfc-editor.org/rfc/rfc3209
2. RFC 4090 — Fast Reroute Extensions to RSVP-TE for LSP Tunnels. P. Pan, G. Swallow, A. Atlas (Eds.), IETF, May 2005. https://www.rfc-editor.org/rfc/rfc4090
3. RFC 2961 — RSVP Refresh Overhead Reduction Extensions. L. Berger et al., IETF, April 2001. https://www.rfc-editor.org/rfc/rfc2961
4. RFC 3630 — Traffic Engineering (TE) Extensions to OSPF Version 2. D. Katz et al., IETF, September 2003. https://www.rfc-editor.org/rfc/rfc3630
5. RFC 5305 — IS-IS Extensions for Traffic Engineering. T. Li, H. Smit, IETF, October 2008. https://www.rfc-editor.org/rfc/rfc5305
6. RFC 7308 — Extended Administrative Groups in MPLS Traffic Engineering. E. Osborne, IETF, July 2014. https://www.rfc-editor.org/rfc/rfc7308
7. RFC 8402 — Segment Routing Architecture. C. Filsfils et al., IETF, July 2018. https://www.rfc-editor.org/rfc/rfc8402
8. RFC 8660 — Segment Routing with the MPLS Data Plane. A. Bashandy et al. (Eds.), IETF, December 2019. https://www.rfc-editor.org/rfc/rfc8660
9. RFC 8667 — IS-IS Extensions for Segment Routing. S. Previdi et al. (Eds.), IETF, December 2019. https://www.rfc-editor.org/rfc/rfc8667
10. RFC 9256 — Segment Routing Policy Architecture. C. Filsfils et al., IETF, July 2022. https://www.rfc-editor.org/rfc/rfc9256
11. RFC 9855 — Topology-Independent Loop-Free Alternate (TI-LFA) Fast Reroute using Segment Routing. S. Litkowski et al., IETF, August 2025. https://www.rfc-editor.org/rfc/rfc9855
12. RFC 7752 — North-Bound Distribution of Link-State and TE Information using BGP (BGP-LS). H. Gredler (Ed.) et al., IETF, March 2016. https://www.rfc-editor.org/rfc/rfc7752
13. RFC 5440 — Path Computation Element (PCE) Communication Protocol (PCEP). JP. Vasseur, JL. Le Roux (Eds.), IETF, March 2009. https://www.rfc-editor.org/rfc/rfc5440
14. RFC 8231 — PCEP Extensions for Stateful PCE. E. Crabbe et al., IETF, September 2017. https://www.rfc-editor.org/rfc/rfc8231
15. RFC 8281 — PCEP Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model. E. Crabbe et al., IETF, December 2017. https://www.rfc-editor.org/rfc/rfc8281
16. I. Minei & J. Lucek, MPLS-Enabled Applications, 3rd ed., Wiley, 2011.
17. C. Filsfils, K. Michielsen, K. Talaulikar, Segment Routing, Volume I, Cisco Press, 2017.