MPLS-TE

Klassisches Routing optimiert eine additive Metrik (kürzester Pfad) und berücksichtigt weder Kapazität noch aktuelle Last. Das Ergebnis: Ein Link wird überlastet, obwohl machbare Alternativpfade mit freier Kapazität existieren (so bereits RFC 2702 und RFC 3272). MPLS-TE adressiert genau das, indem es Verkehrströme als Tunnel gezielt über Pfade legt, die definierte Bedingungen (allen voran verfügbare Bandbreite) erfüllen.

Klassisch werden TE-LSPs über RSVP-TE (RFC 3209) aufgebaut. Der Headend-Router schickt eine Path-Nachricht Richtung Ziel, das Tail-End antwortet mit Resv und bindet hop-by-hop die Labels. Wichtige Bausteine: das ERO (Explicit Route Object) gibt den Pfad als Folge von Strict- oder Loose-Hops vor, die Bandbreite wird auf jedem Transit-Knoten reserviert, und über Setup-/Hold-Priorität kann ein wichtiger Tunnel einen unwichtigeren verdrängen (Preemption).

Damit eine Re-Optimierung den Verkehr nicht unterbricht, nutzt RSVP-TE Make-before-break: Der neue Pfad wird aufgebaut und der Verkehr umgeschwenkt, bevor der alte abgebaut wird (Shared-Explicit-Reservierung verhindert dabei doppelte Bandbreitenbuchung).

Den Pfad berechnet der Headend per CSPF (Constrained SPF): Aus der Topologie werden zuerst alle Links entfernt, die eine Bedingung verletzen (zu wenig freie Bandbreite, falsche Affinität, ausgeschlossene Hops), dann läuft SPF auf dem Rest. Grundlage ist die TE-Datenbank (TED), die getrennt vom normalen IGP gepflegt und über TE-Erweiterungen der IGPs gefüllt wird: OSPF-TE (RFC 3630) und IS-IS (RFC 5305) verteilen je Link maximale und reservierbare Bandbreite, die noch freie Bandbreite je Priorität, eine eigene TE-Metrik und Administrative Groups (Link-Farben für Affinitäten).

Fast ReRoute (RFC 4090) schützt TE-LSPs durch vorab signalisierte Umleitungen, sodass ein Point of Local Repair bei einem Ausfall lokal und ohne Signalisierung sofort umschaltet, im Bereich von Millisekunden. Zwei Verfahren: Facility Backup (ein Bypass-Tunnel schützt per Label-Stacking alle LSPs über einen Link/Knoten, skaliert gut) und One-to-One (ein eigener Detour je LSP, feiner, aber zustandsintensiv).

Klassisches TE reserviert Bandbreite pro Tunnel, unterscheidet aber keine Verkehrsklassen. DiffServ-aware TE (RFC 4124, aufbauend auf RFC 3270) führt bis zu acht Verkehrsklassen (Class-Types CT0 bis CT7) mit eigenen Bandbreiten-Pools (BC0 bis BC7) ein. Wie diese verrechnet werden, regeln zwei Modelle: MAM (Maximum Allocation, jede Klasse hat ein festes Maximum, einfach) und RDM (Russian Dolls, verschachtelte Grenzen, effizienter bei Preemption).

RSVP-TE ist ein Soft-State-Protokoll: Jeder Transit-Knoten hält für jeden durchlaufenden LSP Zustand und muss ihn regelmäßig per Refresh erneuern. Bei vielen Tunneln wird das zum Engpass der Steuerebene. Eine viel zitierte Analyse (RFC 5439, allerdings von 2009) nennt eine Größenordnung von rund 50.000 LSPs, ab der ein Knoten mit der Zustandspflege ringt; moderne Geräte liegen höher, die grundsätzliche Charakteristik bleibt.

Erweiterungen mildern den Refresh-Overhead (RFC 2961 mit Summary-Refresh, RFC 8370 mit Hello-basiertem Refresh und Flow-Control), lösen das prinzipielle Problem des per-LSP-Zustands aber nicht. Genau hier setzt der Nachfolger an.

Segment Routing mit SR-Policy (RFC 9256) erreicht Traffic Engineering ohne per-Hop-Zustand: Der gesamte Pfad steht als Segment-Liste im Paket, Transit-Knoten halten keinen LSP-State und brauchen keinen RSVP-Refresh. Pfade berechnet ein Controller (per PCEP oder BGP). SR-TE reserviert dafür von sich aus keine Bandbreite pro LSP, die TE-Intelligenz liegt in der zentralen Berechnung.

In Bestandsnetzen laufen beide oft parallel; RFC 8426 beschreibt die Koexistenz, damit RSVP-TE den SR-Verkehr in der Bandbreitenrechnung nicht übersieht. Für Neuinstallationen ist SR-TE der eingeschlagene Weg, RSVP-TE bleibt vor allem dort, wo harte Bandbreitenreservierung pro LSP gebraucht wird.