QoS und Traffic Engineering: SR-TE/MPLS-TE für Voice & Video

QoS und Traffic Engineering sind im Telco-Backbone ein starkes Team, wenn Voice und Video nicht nur „priorisiert“, sondern wirklich planbar und stabil durch das Netz geführt werden sollen. Klassisches QoS (DiffServ, DSCP/CoS/MPLS-TC, Queues, Shaping) entscheidet, wie ein Router Pakete behandelt, wenn mehrere Flows um dieselbe Ausgangskapazität konkurrieren. Traffic Engineering (TE) entscheidet dagegen, wo der Verkehr entlangläuft – also welche Links und Knoten überhaupt belastet werden. Genau diese Kombination ist für Echtzeit entscheidend: Voice und interaktives Video leiden am stärksten, wenn sie über Engpässe laufen, in Microbursts geraten oder bei Failover auf Pfade mit anderen Delay- und Jitterprofilen ausweichen. SR-TE (Segment Routing Traffic Engineering) und MPLS-TE erlauben es, Premiumtraffic gezielt über „gute“ Pfade zu lenken, Kapazität zu reservieren oder zumindest planbar zu nutzen, und bei Ausfällen schnell auf vorberechnete Ersatzpfade umzuschalten. Gleichzeitig entstehen neue Risiken: Wenn TE ohne QoS gedacht wird, kann Premiumtraffic zwar einen „leeren“ Pfad bekommen, aber am Ende in falschen Queues landen oder durch Policer/Bufferbloat degradiert werden. Wenn QoS ohne TE gedacht wird, schützt man Echtzeit zwar an Engpässen, aber man akzeptiert, dass die Engpässe überhaupt entstehen – weil das IGP alle Flows auf dieselben Shortest Paths schiebt. Ein professionelles Design verbindet beide Ebenen: DiffServ liefert die Serviceklassen (Voice/EF, Video/AF, Control, Best Effort) und SR-TE/MPLS-TE sorgt dafür, dass diese Klassen auf Pfade mit passenden Delay-, Jitter- und Kapazitätsprofilen gelegt werden. Dieser Artikel erklärt die Grundlagen, typische Architekturen und Designregeln, damit SR-TE/MPLS-TE für Voice & Video nicht nur „läuft“, sondern die Qualität messbar verbessert.

QoS vs. Traffic Engineering: Zwei Hebel, ein Ziel

QoS und TE lösen unterschiedliche Probleme, die in Echtzeitnetzen gleichzeitig auftreten:

• QoS (Scheduler, Queues, Shaping): schützt Echtzeit, wenn es am Ausgang eng wird, und verhindert, dass Voice/Video in Best Effort untergeht.
• Traffic Engineering (SR-TE/MPLS-TE): reduziert oder vermeidet Engpässe, indem es Verkehr gezielt verteilt oder über Pfade mit besserer Qualität führt.

Ein einfaches Bild: QoS optimiert die Warteschlange, TE optimiert die Straße. Wer nur die Warteschlange optimiert, aber alle auf dieselbe Straße schickt, wird Engpässe nie ganz vermeiden. Wer nur die Straße optimiert, aber keine Warteschlangenregeln hat, wird in Peaks trotzdem Jitter und Drops sehen.

Warum Voice & Video spezielle TE-Anforderungen haben

Voice und Video sind nicht einfach „wichtiger Traffic“, sondern haben eigene technische Eigenschaften:

• Voice (Audio): kleine, konstante UDP-Pakete, extrem sensibel auf Jitter und Drop-Cluster; Delay sollte niedrig und stabil sein.
• Interaktives Video: deutlich höhere Bitrate, burstig (Keyframes, Screen Share), toleriert etwas mehr Delay als Voice, aber reagiert stark auf Throughput-Wellen und Cluster-Drops.
• Signaling/Control: geringes Volumen, aber kritisch für Setup und Stabilität; TE kann helfen, Control-Pfade stabil zu halten, aber QoS ist hier oft der wichtigere Hebel.

Die TE-Ziele für Echtzeit sind daher: Pfade mit geringer Latenz, möglichst wenig Congestion-Risiko, stabile Jitterprofile und vorhersehbares Verhalten bei Failover.

MPLS-TE in der Praxis: Explizite Pfade und (optionale) Ressourcenreservierung

MPLS-TE ermöglicht es, Tunnel über explizite Pfade aufzubauen, statt nur dem IGP-Shortest-Path zu folgen. Typische Bausteine:

• TE-Tunnel (LSP): ein Label Switched Path, der Verkehr zwischen Edge-Routern über definierte Links führt.
• Explizite Pfade: Pfad kann manuell oder per Constraint-Based Routing gewählt werden (z. B. bestimmte Links vermeiden).
• Bandbreiten-Constraints: TE kann (je nach Design) berücksichtigen, wie viel Kapazität auf Links verfügbar ist, um Überlast zu vermeiden.
• Fast Reroute: lokale Schutzmechanismen, um bei Link/Node-Ausfall schnell umzuschalten.

Für Voice/Video ist MPLS-TE besonders dann attraktiv, wenn Sie Engpässe im IGP-Standardrouting sehen oder wenn Sie bestimmte „Qualitätspfade“ definieren wollen, z. B. zwischen PoPs mit niedriger Latenz.

SR-TE in der Praxis: Segment Routing als moderner TE-Ansatz

SR-TE verfolgt ein ähnliches Ziel wie MPLS-TE, setzt aber auf Segment Routing: Der Pfad wird über eine Liste von Segmenten (z. B. Node- oder Adjacency-SIDs) definiert. Das bietet in vielen Netzen operative Vorteile:

• Einfachere Skalierung: weniger per-tunnel State im Core, je nach Architektur.
• Flexibles Path Steering: Traffic kann sehr gezielt über bestimmte Knoten/Links geführt werden.
• Policy-basierte Steuerung: SR Policies können auf Basis von Präferenzen, Constraints und Performance-Metriken gewählt werden.
• Gute Kombination mit FRR: schnelle Umschaltungen sind möglich, wenn Backup-Optionen sauber geplant sind.

Für Echtzeit ist SR-TE besonders interessant, wenn Sie viele Pfadoptionen haben, dynamisch auf Last reagieren wollen oder performanzbasierte Entscheidungen (Latency-aware Routing) anstreben.

Das Kernprinzip: TE steuert Pfade, QoS schützt Klassen – beides muss konsistent sein

Ein häufiger Architekturfehler ist, TE-Pfade zu definieren, aber die QoS-Semantik entlang dieser Pfade nicht zu verifizieren. Für Voice/Video brauchen Sie drei Konsistenzen:

• Klassenkonsistenz: DSCP/CoS/MPLS-TC muss auf allen Links identisch gemappt werden.
• Pfadkonsistenz: „Voice-Pfad“ muss nicht nur existieren, sondern auch in Peaks stabil bleiben (Queueing Delay, Drops, Policer-Hits).
• Failoverkonsistenz: Backup-Pfade dürfen keine QoS-Löcher haben und müssen Kapazität für Premiumklassen tragen.

Ohne diese Konsistenzen kann TE sogar schaden: Ein alternativer Pfad kann über ein Segment führen, das EF nicht korrekt queued oder das Video hart policet.

Wie Sie Voice & Video in TE-Policies abbilden

In der Praxis wird nicht „ein TE-Tunnel pro Call“ gebaut. Stattdessen werden Trafficgruppen in TE-Policies zusammengefasst. Ein bewährtes Muster:

• Voice/EF Trafficgruppe: kleiner, streng priorisierter Traffic, der auf Pfade mit niedriger Latenz und hohem Stabilitätsanspruch gelenkt wird.
• Interaktives Video/AF Trafficgruppe: größere Last, die auf Pfade mit ausreichend Kapazität und stabilen Throughput-Fenstern gelenkt wird.
• Best Effort: darf stärker „die Reste“ nutzen, kann über weniger bevorzugte Pfade laufen, solange Fairness erhalten bleibt.

Wichtig: Voice sollte nicht unbedingt „den exklusivsten Pfad“ bekommen, wenn dieser Pfad im Failover zu knapp ist. Für Voice ist Stabilität wichtiger als absolute Minimal-Latenz.

Capacity-Aware TE: Warum Engpassvermeidung der größte QoE-Booster ist

Die größte QoE-Verbesserung entsteht häufig nicht durch neue Queue-Parameter, sondern durch das Vermeiden von Congestion. TE kann das erreichen, indem es:

• Hotspots entlastet: Traffic weg von dauerhaft überfüllten Links lenkt.
• Last gleichmäßiger verteilt: parallele Pfade nutzt, ohne dass ECMP-Hotspots entstehen.
• Premium vor BE schützt: indem Premium nicht in denselben Engpass wie große BE-/Streamingströme gedrückt wird.

Wenn Voice und Video „trotz QoS“ schlecht werden, ist die Ursache oft: QoS wird am Engpass aktiv, aber der Engpass ist schlicht zu häufig aktiv. TE kann hier die Frequenz und Schwere von Engpässen reduzieren.

Latency-Aware TE: Wann niedrigere Latenz wirklich zählt

Es ist verlockend, Voice immer auf den niedrigsten Latenzpfad zu legen. In der Praxis ist es oft besser, auf niedrige und stabile Latenz zu optimieren. Wichtige Punkte:

• Stabilität vor Minimalwert: ein Pfad mit 12 ms stabil ist häufig besser als ein Pfad, der zwischen 8 ms und 30 ms schwankt.
• Queueing Delay als Feind: Latenzsteigerungen entstehen oft aus Queueing, nicht aus Geografie. TE sollte Engpässe vermeiden, QoS sollte Queueing kontrollieren.
• Messbarkeit: Latency-aware Entscheidungen müssen auf Probes und Telemetrie basieren, sonst werden Policies blind.

Gerade bei Video kann ein pfadbedingter Latenzunterschied von wenigen Millisekunden unwichtig sein, während Throughput-Stabilität und Drop-Verhalten entscheidend sind.

Fast Reroute im TE-Kontext: Umschalten ohne Drop-Cluster

TE ohne Resilienz ist für Echtzeit unvollständig. Bei Ausfällen muss der Traffic schnell und kontrolliert umschalten, ohne große Drops oder Jitterspitzen:

• Backup-Pfade müssen QoS-semantisch identisch sein: DSCP/TC-Mappings, Queue-Weights, Limits.
• N+1 Kapazität im Schutzfall: der Ersatzpfad muss Premium tragen können, sonst dropt EF.
• Microburst-Handling: Umschaltmomente erzeugen Bursts; Shaping an Engpässen reduziert Drop-Cluster.

Ein sehr praktischer Betriebsindikator lautet: EF/Voice darf auch während FRR/Schutzschaltungen keine Drops zeigen. Wenn EF dropt, ist Kapazität oder Governance falsch.

Interaktion von TE und ECMP: Hotspots und Jitter vermeiden

In vielen Netzen koexistieren TE und ECMP. TE kann Pfade definieren, aber innerhalb eines Abschnitts kann ECMP weiter verteilen. Das ist leistungsfähig, aber QoS-kritisch:

• Pfadgleichwertigkeit: wenn ECMP-Pfade unterschiedliche Queueingprofile haben, entstehen Jitterprobleme.
• Hashing/Entropy: bei Encapsulation kann Hashing blind werden; Hotspots entstehen trotz „genug“ Gesamtbandbreite.
• Monitoring pro Pfad: Queueing Delay/Drops pro Link sind wichtiger als nur „LSP up“.

Ein TE-Design sollte daher nicht nur „LSPs planen“, sondern auch die unterliegenden Parallelpfade qualitativ angleichen oder bewusst steuern.

QoS-Details im MPLS/SR-Transport: TC/EXP richtig nutzen

In MPLS- und SR-MPLS-Umgebungen transportieren Sie QoS häufig über die MPLS Traffic Class (TC, historisch EXP). Das Design muss definieren, wie DSCP in TC gemappt wird und wie TC wiederum in Queues umgesetzt wird.

• DSCP→TC Mapping: klare, dokumentierte Tabelle, die überall identisch ist.
• TC→Queue Mapping: pro Interface und Plattform konsistent, inklusive LLQ-Limits und Weights.
• Penultimate Hop und Egress: QoS darf beim Pop nicht „kippen“; Rückmapping DSCP muss stimmen.

Ein typisches TE-QoS-Problem ist nicht der Tunnel, sondern ein einziges Segment, das TC anders interpreted. Deshalb ist Policy-Verifikation über alle Knoten Pflicht.

Shaping vs. Policing in TE-Pfaden: Bursts kontrollieren statt Echtzeit droppen

TE kann Verkehr umleiten und Pfade entlasten. Aber Bursts bleiben Bursts. Besonders interaktives Video erzeugt spitze Lastmuster, die an rate-limitierten Links kritisch sind.

• Shaping: glättet Bursts am Egress, reduziert Drop-Cluster, stabilisiert Jitter – sehr wertvoll für Voice/Video in Engpassnähe.
• Policing: erzwingt Budgets hart; für Echtzeit riskant, weil Drops sofort hör- oder sichtbar sind.
• Remarking: für Video/BE oft besser als Drop, um Premium zu schützen ohne Cluster-Drops zu erzeugen.

Ein TE-Design sollte deshalb an den Stellen shapen, an denen Pfade in unterschiedliche Profile münden oder wo Uplinks hart begrenzt sind.

Monitoring und Verifikation: Wie Sie beweisen, dass TE wirklich QoE verbessert

TE ist nur dann erfolgreich, wenn es messbar Qualitätsprobleme reduziert. Dazu brauchen Sie Metriken auf drei Ebenen:

• Service-KPIs: MOS/R-Faktor, RTP Jitter/Loss, Video Freeze Events/Bitrate Switching, Setup Times.
• QoS-Metriken: Queueing Delay/Drops pro Klasse, Policer/Shaper Events, DSCP/TC-Verteilungen.
• TE-Metriken: Pfadnutzung, Hotspot-Links, Failover-Events, Trafficverschiebungen zwischen Pfaden.

Ein robustes Vorgehen ist: Vorher/Nachher-Vergleich nach Einführung von SR-TE/MPLS-TE, insbesondere in Busy Hour. Wenn Queueing Delay-Perzentile und Drop-Cluster in Premiumklassen sinken, ist TE ein echter QoE-Booster.

Typische Fehler bei QoS + TE für Voice & Video

• TE ohne Kapazitätsziel: Pfade werden geändert, aber Engpässe bleiben; QoE verbessert sich nicht.
• QoS-Loch im Backup-Pfad: FRR schaltet schnell, aber EF wird falsch gequeued oder gedroppt.
• Zu viele Klassen: Mapping-Drift und Inkompatibilitäten steigen; End-to-End-Verifikation wird schwer.
• Policer auf Echtzeit: Drops in Voice/Video erzeugen sofortige Qualitätsartefakte.
• Blindes Latency-Optimieren: minimaler Delay ohne Stabilität; Jitter- und Congestion-Risiko wird unterschätzt.

Praxis-Blueprint: SR-TE/MPLS-TE für Voice & Video richtig einführen

• Schritt 1: Serviceprofile definieren (Voice/EF, Video/AF, Control, BE) und QoS-Mappings (DSCP↔TC↔Queue) standardisieren.
• Schritt 2: Hotspots identifizieren (Queueing Delay-Perzentile, Drops, Busy-Hour-Links) und TE-Ziele festlegen.
• Schritt 3: TE-Pfade entwerfen (Primary/Backup) mit Fokus auf Stabilität, nicht nur kürzester Latenz.
• Schritt 4: Kapazitäts- und Schutzfallplanung (N+1) durchführen, damit Premium auch im Failover stabil bleibt.
• Schritt 5: QoS am Pfad verifizieren (Classify-Hits, TC/DSCP-Verteilungen, Queue-Share, Limits, Shaping).
• Schritt 6: FRR/Schutzmechanismen testen und messen (EF darf nicht droppen, Peaks in Sekundenfenstern).
• Schritt 7: Operatives Monitoring aufbauen (Service-KPIs + QoS-Telemetrie + TE-Pfadmetriken) und Drift-Checks definieren.

Häufige Fragen zu QoS und Traffic Engineering

Wann lohnt sich SR-TE/MPLS-TE für Voice wirklich?

Wenn Sie wiederkehrende Congestion-Hotspots, stark schwankende Pfade oder häufige Failover-Ereignisse haben, die Voice spürbar beeinträchtigen. TE lohnt sich besonders, wenn Sie mehrere physische Pfadoptionen besitzen und die Last bewusst verteilen können, statt alle Flows auf denselben Shortest Paths zu bündeln.

Kann TE QoS ersetzen?

Nein. TE reduziert Engpässe, aber Congestion kann trotzdem auftreten, und Echtzeit braucht eine Low-Latency-Behandlung an jedem Engpass. Umgekehrt kann QoS TE nicht ersetzen, weil QoS Engpässe nur verteilt, aber nicht verhindert. Die beste Qualität entsteht durch Kombination.

Was ist der wichtigste Erfolgsindikator nach Einführung von TE?

Sinkende Queueing Delay-Perzentile und weniger Drop-Cluster in den Premiumklassen (insbesondere Voice/EF) während der Busy Hour sowie stabilere Service-KPIs (MOS, RTP Jitter/Loss, Video Freeze/Bitrate Switching). Wenn diese Werte sich verbessern, hat TE die QoE messbar erhöht.