Summary

  • RFC 3346 explained where MPLS traffic engineering was useful: it could place selected traffic on an explicit LSP instead of leaving every flow on the IGP shortest path.
  • It also drew a strict boundary: configured bandwidth, accepted signalling and a changed route did not prove sufficient physical capacity, accurate demand modelling or delivered service.

The attractive picture was simple. A shortest path had become hot while another part of the backbone remained lightly used. Instead of changing one IGP metric and moving an unpredictable population of destinations, an operator could select a traffic aggregate and establish a label-switched path through the spare part of the topology. Endpoints, requested bandwidth, priority, affinities, excluded nodes and resilience requirements could all constrain that path. The forwarding decision became more deliberate.

RFC 3346 was an Informational applicability statement, not the protocol that created MPLS or RSVP-TE. Its importance was operational. It asked what happened after the machinery existed. The answer was neither “MPLS solves congestion” nor “explicit paths are merely cosmetic.” MPLS TE addressed one kind of congestion well: traffic mapped inefficiently onto a topology that still contained usable alternate capacity. It did not cure a topology whose total resources were inadequate for its offered load.

That distinction already appeared in RFC 2702. Congestion can arise because resources are insufficient, or because traffic has been placed badly while feasible capacity sits unused elsewhere. Capacity expansion or demand regulation addresses the first case. Traffic engineering can improve the second. RFC 3346 carried that distinction into the deployment room. An LSP could move load away from a congested link, distribute aggregates across parallel circuits or enforce an affinity such as keeping continental traffic off a transoceanic resource. None of those choices added a bit per second to the underlying links.

The most revealing warning concerned the bandwidth parameter attached to an LSP. A router could use that number when computing or admitting a path, but the value might not accurately describe the traffic later carried. An operator might derive it from a peak, a percentile or another statistic. The operator might oversubscribe or deliberately under-report physical links to absorb event-driven variation. Those were modelling and policy decisions. The field was not a meter embedded in the packet stream, and its presence did not police an unbounded sender.

RFC 3346 therefore tied path control to measurement. Workload observations could feed an offline computation that produced explicit routes, or they could change online attributes such as bandwidth, priority and affinity. Trends mattered because an LSP might need resizing. Unusual variance mattered because it could expose a bad model, a failed facility, delayed provisioning or a demand surge. Policing was a separate action, preferably at the edge under the memo's guidance, not a magical consequence of entering a bandwidth value.

This creates a useful evidence chain. First there is measured demand. Then someone selects the statistical model that turns samples into a configured LSP value. A path computation uses that value with advertised topology attributes. RSVP-TE may signal the path and nodes may admit the request. Forwarding state may then be installed. Only after traffic is carried can observation show whether the selected path received the intended load and whether latency, loss and service objectives remained acceptable. Each state is evidence for the next decision; none is a receipt for all later states.

Failure makes the sequence easier to see. RFC 3346 described re-optimising LSPs over the residual topology after a network failure. It treated that work as complementary to fast reroute, which limits disruption during the transient. A precomputed detour can be available; traffic can be redirected onto it; the post-failure topology can later be recomputed; and the network can eventually regain a stable balance. Those are four different events. RFC 4090 later specified local repair mechanisms, but the existence of a backup LSP still did not prove that it was in use, that it offered equivalent bandwidth or that the service had recovered.

More explicit control also created more state. A dense full mesh of LSPs among edge nodes could grow on the order of the square of the number of endpoints. Hierarchy and regionalisation could reduce that burden, but at the price of coarser control. Excessive aggregation created the opposite failure: one trunk could become too large for any feasible constrained path. Splitting it across parallel LSPs might restore feasibility while increasing state and complicating failure behaviour.

The historical surprise is that RFC 3346 did not present automation as escape from operations. It warned that MPLS TE added databases, signalling, routing information, configuration systems, measurement and processor load. Early commercial management systems often lacked sufficient MPLS visibility, particularly root-cause analysis, so early adopters built their own tools. That observation belongs to 2002; it is not a verdict on today's products. Its lasting point is narrower: a control mechanism becomes safer only when its state can be observed and explained.

The memo's hardest sentence was that MPLS TE was not a panacea for inadequate capacity or inadequate planning. Rerouting around a hot spot could make a packet travel farther and increase latency. Better placement could buy time during traffic growth. It could not achieve an impossible mapping. If every feasible path was full, changing labels and constraints would only decide where congestion appeared.

Later standards expanded the control surface. OSPF and IS-IS carried TE attributes; RSVP-TE established tunnels; PCE separated path computation into another architectural component; stateful PCE added reporting and delegation. These developments improved what controllers could know and choose. They did not abolish the physical limit recorded in RFC 3346. A more capable planner still needs truthful inputs, an executor, observable forwarding and enough capacity.