Theoretical foundations and architecture

MPLS Traffic Engineering (MPLS-TE, RSVP-TE signaling per RFC 3209) addresses the problem of an IGP that routes only by the shortest metric: traffic gathers on the best paths while parallel links may sit idle. MPLS-TE lets traffic follow an explicit or constraint-computed path. The ecosystem has four parts: 1. TE extensions of the IGP (OSPF-TE/IS-IS TE) flood link attributes; 2. the TED on every router; 3. CSPF, the constrained path computation; 4. RSVP-TE: PATH and RESV messages follow the computed path, distribute labels and reserve bandwidth. A reservation is accounting in the control plane: it reduces the unreserved bandwidth in the TED but does not limit traffic in the data plane.

Session, LSP and their identifiers

A TE LSP in RSVP-TE (RFC 3209) is unidirectional: a tunnel from PE1 to PE2 does not create a return path. The session is identified by the SESSION object (C-Type 7, LSP_TUNNEL_IPv4): the tunnel endpoint address, a 16-bit Tunnel ID and an Extended Tunnel ID (the head-end address). A specific instance of an LSP within the session is identified by the SENDER_TEMPLATE object: the sender address and a 16-bit LSP ID. During re-signaling (re-optimization, bandwidth change) the head-end signals a new LSP with the same SESSION and a new LSP ID, and the Shared Explicit (SE) reservation style lets the old and new instances share a single reservation on common links: this is how make-before-break works.

RSVP-TE runs directly over IP (protocol 46, not TCP/UDP); Path and PathTear carry the IP Router Alert option, so every transit node punts them to the control plane. Filters and CoPP that drop protocol 46 or packets with Router Alert break signaling even when the IGP is perfectly healthy.

IGP extensions and the TED

The IGP supplies the information for CSPF. In OSPF this is the Opaque LSA of type 10 (area-local), opaque type 1, RFC 3630. The TE LSA contains a Router Address TLV (type 1, the TE router-id) and a Link TLV (type 2) for each link. Sub-TLVs inside the Link TLV:

Sub-TLVTypeContent
Link type1point-to-point or multi-access
Link ID2the neighbor router-id (for p2p)
Local / Remote interface address3 / 4the addresses of the link ends
TE metric532 bits, independent of the IGP metric
Maximum bandwidth6physical bandwidth, IEEE float, bytes/s
Maximum reservable bandwidth7how much may be reserved (can exceed the physical value)
Unreserved bandwidth88 values, one per priority 0-7
Administrative group9a 32-bit color mask (affinity)

In IS-IS (RFC 5305) the same data lives in sub-TLVs inside TLV 22 (Extended IS Reachability): administrative group - 3, IPv4 interface address - 6, IPv4 neighbor address - 8, maximum link bandwidth - 9, maximum reservable bandwidth - 10, unreserved bandwidth - 11, TE default metric - 18; the TE router-id is TLV 134. IS-IS must run with wide metrics. In addition, RFC 4203 and RFC 5307 introduce SRLG (OSPF sub-TLV 16, IS-IS TLV 138), and RFC 4124 introduces Bandwidth Constraints for DS-TE.

The TED is built on top of the LSDB: every node keeps a graph with link attributes and uses it in CSPF. The TED does not replace the IGP routing table: TE attributes affect only the computation of tunnel paths. If a link has no TE attributes (mpls traffic-eng/mpls te/rsvp is not enabled), the link is absent from the TED and CSPF will not build a path across it, although an IGP route exists.

When the information is refreshed: periodically (on Cisco every 180 s by default) and on a significant change of available bandwidth. Cisco floods on utilization-change thresholds (by default a series of 15, 30, 45, 60, 75, 80, 85, 90, 95, 96, 97, 98, 99, 100 percent going up and the reverse series going down), so the TED on remote nodes lags behind the actual state. This is a normal source of races: the head-end computed a path from stale data, a transit node refused it in admission control and returned PathErr.

RSVP-TE messages

Common header: version 1, flags, message type, checksum, send TTL, length. It is followed by objects in the Length / Class-Num / C-Type format.

MessageTypeDirectionPurpose
Path1head -> tailrequest to set up the LSP; carries ERO, SESSION_ATTRIBUTE, SENDER_TSPEC, LABEL_REQUEST
Resv2tail -> headconfirmation, label distribution (LABEL), reservation (FLOWSPEC)
PathErr3towards the headerror in Path state (bad ERO, no route, admission control)
ResvErr4towards the tailreservation error, including preemption
PathTear5head -> taildelete the LSP
ResvTear6tail -> headdelete the reservation
Hello20to a neighborneighbor failure detection (RFC 3209)
Srefresh15to a neighborsummary refresh (RFC 2961)

Key Path objects: EXPLICIT_ROUTE (ERO) - a list of IPv4 prefix subobjects, each with an L (loose) bit; a node removes its own subobject as the message passes through. RECORD_ROUTE (RRO) - the actual path and (with the label recording flag) the labels; needed for loop detection and FRR. SESSION_ATTRIBUTE - the tunnel name, setup and hold priority, flags (0x01 local protection, 0x02 label recording, 0x04 SE style, 0x08 bandwidth protection, 0x10 node protection) and, in C-Type 1, also include-any/exclude-any/include-all. SENDER_TSPEC - the requested bandwidth (token bucket rate, in bytes/s as an IEEE float). LABEL_REQUEST - the L3PID, which is 0x0800 for IPv4. Resv carries STYLE (SE), FLOWSPEC, FILTER_SPEC, LABEL and its own RRO.

Setting up an LSP step by step

The head-end computes a path from the TED (CSPF) and builds the ERO. Path goes to the first node in the ERO; each node checks that it is listed in the ERO, removes its subobject, stores a Path State Block (PSB) with the previous hop (RSVP_HOP) and forwards Path onwards. The tail sees an empty ERO, allocates a label and answers with Resv. By default the tail advertises implicit-null (label 3): the penultimate node pops the label (PHP). Resv travels back along the RSVP_HOP chain; each transit node creates a Reservation State Block (RSB), reserves bandwidth in admission control, assigns an incoming label, writes the pair (incoming label -> outgoing label, interface) to the LFIB and passes Resv upstream. The distribution model is downstream-on-demand with ordered control: no label appears until the downstream node has answered.

An LSP is considered up when Resv has reached the head. Until then the tunnel is in the signaling state; without an RRO the head-end does not see the actual path.