MPLS-TE vs. SR-TE ist im Provider- und Telco-Umfeld weit mehr als ein Protokollvergleich. Traffic Engineering (TE) ist ein Werkzeug, um Topologie „nutzbar“ zu machen: Es steuert, welche Pfade ein Netz im Normalbetrieb verwendet, wie Last verteilt wird, wie Wartungen ohne großen Kundeneffekt ablaufen und wie sich das Netz in Störfällen verhält. Gerade in Carrier-Grade Netzen reichen klassische IGP-Kürzeste-Wege-Entscheidungen oft nicht aus, weil sie Hotspots erzeugen, Latenzbudgets verletzen oder physische Diversität nicht berücksichtigen. Hier setzen MPLS Traffic Engineering (MPLS-TE) und Segment Routing Traffic Engineering (SR-TE) an. Beide ermöglichen bewusst gesteuerte Pfade, unterscheiden sich aber in Architektur, Signalisierung, Betriebsmodell und Skalierungsverhalten. Dieser Artikel erklärt verständlich, wie MPLS-TE und SR-TE funktionieren, wann welche Variante sinnvoll ist und wie TE als Topologie-Tool genutzt wird, um Resilienz, Kapazität und Betriebsfähigkeit gleichzeitig zu verbessern.
Traffic Engineering als Topologie-Tool: Warum TE überhaupt nötig ist
Topologie ist nicht nur „wie viele Links“, sondern „wie Verkehr diese Links nutzt“. Ohne TE wird Traffic oft durch einfache Metriken und Standardpfade gelenkt. Das ist robust, aber nicht immer optimal: Ein einzelner kürzester Pfad kann dauerhaft überlastet sein, während parallele Links ungenutzt bleiben. Zudem sind Wartungen und Störfälle in großen Netzen schwerer kontrollierbar, wenn Pfadwahl nur indirekt über Metriken erfolgt.
- Hotspot-Vermeidung: Verkehr bewusst verteilen, statt zufällige Engpässe zu akzeptieren.
- Latenzbudgets: Kritische Dienste auf definierte Low-Latency-Pfade legen.
- Resilienz: Physische Diversität und alternative Pfade planbar nutzen.
- Wartungsfähigkeit: Traffic vor Maintenance kontrolliert umleiten (Drain), statt „hart“ umzuschalten.
- Serviceklassen: Unterschiedliche Pfadprofile für Echtzeit, Business, Best-Effort.
TE ist ein Betriebswerkzeug, kein „Feature“
In Carrier-Netzen ist TE dann erfolgreich, wenn es operationalisiert ist: klare Pfadklassen, standardisierte Policies, Telemetry, Tests und Runbooks. Ohne Governance wird TE schnell zur Fehlerquelle, weil sich Pfadsteuerung und Topologieänderungen gegenseitig verstärken können.
Grundlagen: Was MPLS-TE und SR-TE gemeinsam haben
Beide Ansätze verfolgen dasselbe Ziel: Verkehr entlang definierter Pfade durch das Netz zu führen. Dafür braucht es drei Bausteine: eine Sicht auf die Topologie (inklusive Bandbreite und ggf. administrativer Einschränkungen), eine Möglichkeit, einen Pfad zu definieren (explizit oder constraint-basiert) und eine Mechanik, damit Router diesen Pfad in der Datenebene umsetzen.
- Topologiesicht: Linkmetriken, Kapazitäten, ggf. Attribute wie Shared-Risk oder administrative Gruppen.
- Pfaddefinition: Explizite Pfade oder Pfade, die Constraints erfüllen (z. B. Bandbreite, Diversität).
- Datenebene: Label-basierte Weiterleitung, sodass Transit-Router effizient schalten können.
Der Kernunterschied: Signalisierung und Zustandsmanagement
Ob TE skalierbar und betrieblich „leicht“ ist, hängt stark davon ab, wie viel Zustand im Netz verteilt werden muss. Genau hier unterscheiden sich MPLS-TE und SR-TE fundamental: MPLS-TE arbeitet typischerweise mit expliziten, signalisierenden LSPs und damit mit mehr verteiltem Zustand. SR-TE verschiebt vieles in Richtung Policy und Segment-Definition, wodurch sich das Betriebsmodell verändern kann.
MPLS-TE: Klassisches Traffic Engineering mit signalisierenden LSPs
MPLS-TE ist ein seit Jahren bewährter Ansatz, um explizite Pfade durch ein MPLS-Netz zu etablieren. Dabei werden TE-LSPs (Label Switched Paths) aufgebaut, die den gewünschten Pfad festlegen. Das Netz reserviert (je nach Modell) Ressourcen, und Transit-Router halten Zustände für diese LSPs. MPLS-TE eignet sich besonders, wenn strikte Bandbreitenreservierung, klassische Constraint-basierte Pfadwahl und etablierte Betriebsprozesse gefragt sind.
- Explizite Pfade: TE-LSPs können genau definierte Wege nehmen.
- Constraints: Bandbreitenanforderungen und Linkattribute lassen sich in die Pfadwahl einbeziehen.
- Ressourcenmodell: Reservierung und Admission Control können Überbuchung begrenzen.
- Betriebsreife: Viele Provider haben lange Erfahrung, Tools und Runbooks dafür.
MPLS-TE Trade-offs: Mehr Zustand, mehr Signalisierung, mehr OPEX-Potenzial
Die Stärke von MPLS-TE – explizite Pfade und reservierte Ressourcen – ist gleichzeitig die Quelle von Komplexität. Je mehr TE-LSPs, desto mehr Zustand muss im Netz gepflegt werden. In großen Netzen können Signalisierungsaufwand, Fehlerszenarien und Troubleshooting-Komplexität steigen. MPLS-TE kann sehr stabil sein, erfordert aber Disziplin bei Skalierung, Monitoring und Change-Management.
SR-TE: Segment Routing Traffic Engineering als Policy-Modell
SR-TE nutzt Segment Routing, um Pfade durch eine Sequenz von Segmenten zu beschreiben. Statt dass jeder Transit-Router spezifische TE-Zustände für jeden Pfad hält, kann SR-TE Pfadintentionen stärker am Rand (Ingress) modellieren und in der Datenebene über Segment-Informationen umsetzen. In vielen Telco-Strategien ist SR-TE attraktiv, weil es Traffic Engineering mit einem vereinfachten Betriebsmodell kombinieren kann, insbesondere wenn Segment Routing ohnehin im Core eingeführt wird.
- Policy-basierte Steuerung: Pfade werden als „Intent“ beschrieben und am Ingress umgesetzt.
- Skalierung: Potenziell weniger netzweit verteilter TE-Zustand, je nach Implementierungsmodell.
- Flexibilität: Pfade und Klassen lassen sich effizienter modellieren (z. B. Low-Latency vs. High-Capacity).
- Automationsfreundlich: Standardisierte Policies und Templates lassen sich gut versionieren und ausrollen.
SR-TE Trade-offs: Governance und Observability werden noch wichtiger
SR-TE kann das Netz vereinfachen, aber es macht Policy-Disziplin zwingend: Wenn viele Policies existieren, müssen sie konsistent, nachvollziehbar und testbar sein. Außerdem braucht SR-TE gute Pfadtransparenz: Betriebsteams müssen sicher erkennen können, welcher Traffic welcher Policy folgt und wie Pfadwechsel im Fehlerfall aussehen.
TE als Topologie-Werkzeug: Was sich mit TE konkret „formen“ lässt
Traffic Engineering verändert nicht die physische Topologie, aber es verändert die effektive Nutzung. Das ist besonders wertvoll, wenn Topologie aus Kosten- oder Geografiegründen nicht beliebig ausgebaut werden kann. TE kann dann wie ein „virtuelles Topologie-Tool“ wirken, indem es Pfade und Lastverteilung gezielt steuert.
- Virtuelle Diversität: Traffic kann auf physisch diverse Pfade gelenkt werden, wenn diese existieren.
- Regionale Entkopplung: Bestimmte Flows können regionale Hubs umgehen, um Zwangswege zu vermeiden.
- Serviceklassen-Pfade: Kritische Dienste erhalten bevorzugte Pfade, Bulk-Traffic nutzt kapazitive Routen.
- Maintenance-Topologie: Für Wartungen wird eine „temporäre Topologie“ erzeugt (Traffic Drain).
Wichtig: TE ersetzt keine Kapazität und keine echte Diversität
TE kann nur nutzen, was vorhanden ist. Wenn alternative Pfade nicht existieren oder wenn alle Pfade dieselbe Trasse teilen, ist „Diversität“ nur eine Illusion. Ebenso kann TE Überlast nicht wegzaubern, wenn Störfallreserve fehlt. Deshalb muss TE immer mit Kapazitätsplanung und Shared-Risk-Analyse kombiniert werden.
Konvergenz und Resilienz: Wie MPLS-TE und SR-TE sich im Fehlerfall verhalten
Im Carrier-Grade Kontext ist nicht nur wichtig, dass ein Pfad existiert, sondern wie schnell und stabil das Netz bei Fehlern reagiert. Fehlerfallverhalten hängt von Erkennung, Umschaltlogik und der Stabilität des Kontrollplans ab. TE-Design muss deshalb Störfallszenarien definieren: Link-Ausfall, Node-Ausfall, Trassenunterbrechung, Wartung – und messen, wie sich Loss, Latenz und Pfadwahl ändern.
- Fehlererkennung: Wie schnell wird ein Ausfall erkannt und propagiert?
- Umschaltlogik: Gibt es definierte Backup-Pfade oder wird neu berechnet?
- Stabilität: Verhindert das Design Flapping und „Ping-Pong“ zwischen Pfaden?
- Störfallkapazität: Tragen Ersatzpfade die Last oder entsteht Degradation?
Trade-off im Betrieb: Determinismus vs. Dynamik
MPLS-TE ist häufig stark deterministisch, weil LSPs und Pfade explizit definiert sind. SR-TE kann ebenfalls deterministisch sein, aber sein Policy-Modell kann dynamischer wirken, wenn Policies häufig angepasst oder durch Controller-Logik beeinflusst werden. In beiden Fällen gilt: Je dynamischer das System, desto wichtiger sind Guardrails, Tests und Observability.
Skalierung und Betriebskosten: Wo die Unterschiede spürbar werden
Die Wahl zwischen MPLS-TE und SR-TE wird im Alltag oft durch OPEX beeinflusst: Wie viele Zustände müssen überwacht werden? Wie komplex sind Changes? Wie gut lässt sich das System automatisieren? Und wie schnell kann das NOC Ursachen finden, wenn Traffic „anders“ läuft als erwartet?
- MPLS-TE OPEX-Treiber: LSP-Zustände, Signalisierung, Troubleshooting von TE-States, Skalierung der LSP-Anzahl.
- SR-TE OPEX-Treiber: Policy-Governance, Pfadtransparenz, konsistente Templates, Controller-Integration.
- Gemeinsame OPEX-Themen: Telemetry, Alarmkorrelation, Runbooks, Wartungsszenarien, Kapazitätsdisziplin.
Policy-as-Code als Erfolgsfaktor für SR-TE
SR-TE profitiert besonders, wenn Policies wie Software behandelt werden: versioniert, reviewed, getestet, in Wellen ausgerollt und mit Rollback. Das macht Pfadsteuerung auditierbar und reduziert das Risiko, dass ein kleiner Change großflächige Auswirkungen hat.
Decision Framework: Wann MPLS-TE sinnvoll ist – und wann SR-TE
Die Entscheidung hängt weniger von „besser oder schlechter“ ab, sondern von Netzreife, bestehenden Technologien, Serviceanforderungen und Governance-Fähigkeit. Ein pragmatischer Ansatz ist, den gewünschten Nutzen zu definieren (z. B. Maintenance-Topologien, Hotspot-Entlastung, Low-Latency-Pfade) und dann zu prüfen, welches TE-Modell ihn mit minimaler Komplexität liefert.
- MPLS-TE passt oft, wenn: bereits viel MPLS-TE Know-how vorhanden ist, Ressourcenreservierung wichtig ist und das Betriebsmodell etabliert ist.
- SR-TE passt oft, wenn: Segment Routing im Core eingeführt wird, Policy- und Automationsreife hoch ist und Skalierung bei geringerer Zustandslast angestrebt wird.
- Hybrid ist realistisch, wenn: Migration in Phasen erfolgt und Legacy-Services weiterlaufen müssen.
Migration: TE-Modernisierung ohne Big Bang
Viele Provider migrieren schrittweise: Zuerst wird das Underlay modernisiert und Observability aufgebaut, dann werden ausgewählte TE-Use-Cases eingeführt (z. B. Maintenance-Drain, kritische Low-Latency-Pfade). Wichtig ist, nicht zu viele Varianten parallel zu betreiben und klare Exit-Pläne für Übergangslösungen zu definieren.
Telemetry und Evidence-by-Design: TE muss messbar sein
Traffic Engineering ohne Messbarkeit ist ein Risiko. In Telco-Netzen muss TE erklärbar sein: welcher Flow folgt welchem Pfad, warum, und mit welchen Auswirkungen auf Latenz, Loss und Auslastung. Telemetry liefert nicht nur Troubleshooting, sondern auch SLA- und Audit-Nachweise. Besonders bei TE gilt: Wenn Sie Pfade bewusst steuern, müssen Sie Pfade bewusst beobachten.
- Pfadtransparenz: Sichtbarkeit von Pfadwahl, Policy-Zuordnung und Pfadwechseln.
- Performance: Latenz, Jitter und Loss entlang TE-relevanter Pfade und Serviceklassen.
- Kapazität: Auslastung, Queue-Drops, Microbursts und Headroom pro Link.
- Korrelation: Failure Domains als Root Cause, TE-Umleitungen als erwartetes Verhalten.
Ein einfaches Denkmodell: TE-Nutzen steigt, wenn Pfade knapp und Anforderungen hoch sind
Wenn alternative Pfade knapp sind, SLAs streng sind und Wartung häufig ist, steigt der Nutzen von TE als Topologie-Tool. Gleichzeitig steigen die Anforderungen an Governance und Telemetry – und genau dort entscheidet sich, ob MPLS-TE oder SR-TE im konkreten Netz besser passt.
Praktische Leitlinien für TE im Provider-Alltag
- Mit wenigen Use-Cases starten: Zuerst Hotspot-Entlastung oder Maintenance-Drain, dann ausbauen.
- Pfadklassen definieren: Low-Latency, High-Capacity, Resilience – als standardisierte Profile.
- Störfallreserve planen: TE funktioniert nur, wenn Ersatzpfade Last tragen können.
- Guardrails einführen: Versionierung, Reviews, Wellen-Rollouts, Rollback.
- Telemetry priorisieren: Pfadtransparenz und Performance-Metriken sind Pflicht.
- Komplexität begrenzen: Wenige Templates, wenige Varianten, klare Domänengrenzen.
