QoS bei Segment Routing ist für moderne Telco-Backbones ein entscheidender Faktor, weil Segment Routing (SR) und SR-TE (Segment Routing Traffic Engineering) zwar die Pfadwahl optimieren, aber nicht automatisch garantieren, dass Voice & Video unter Last stabil bleiben. In der Praxis entstehen Qualitätsprobleme für Echtzeittraffic selten durch „falsche Route“ allein, sondern durch kurzfristige Engpässe, Microbursts, Failover-Events und inkonsistente Klassenbehandlung. SR-TE kann Hotspots umgehen, Last verteilen und Pfade planbar machen – QoS sorgt dafür, dass an unvermeidbaren Engpässen die richtigen Pakete bevorzugt werden. Erst die Kombination aus beidem liefert eine Backbone-Architektur, die SLA-fähig ist: niedrige Latenz und Jitter für Voice, stabile Ressourcen für interaktives Video, faire Behandlung für Best Effort und gleichzeitig robuste Steuerung bei Topologieänderungen. Dieser Artikel erklärt QoS bei Segment Routing leicht verständlich und praxisnah: welche Rollen SR, SR-TE und DiffServ haben, wie Sie Klassen, Policies und Pfadsteuerung sinnvoll zusammenspielen lassen und welche Designregeln im Betrieb die größten Qualitätsgewinne bringen.
Segment Routing und SR-TE kurz eingeordnet
Segment Routing ist ein Routing-Ansatz, bei dem der Pfad eines Pakets über sogenannte Segmente definiert wird. Im Backbone wird SR häufig genutzt, um Pfade effizienter zu steuern, Traffic besser zu verteilen und Konvergenz-/Failover-Verhalten zu verbessern. SR-TE erweitert das, indem gezielt Traffic-Engineering-Pfade gewählt werden können – zum Beispiel entlang bestimmter Knoten oder Links, um Überlast zu vermeiden oder SLAs abzusichern.
- SR als Underlay-Steuerung: Pfadwahl und Forwarding werden flexibler und oft einfacher als bei klassischen MPLS-TE-Ansätzen.
- SR-TE als Traffic Engineering: Bestimmte Dienste oder Traffic-Klassen können gezielt über definierte Pfade gelenkt werden.
- QoS als Service-Steuerung: Innerhalb eines Pfads entscheidet QoS, wie Pakete an Engpässen behandelt werden.
Merke: SR-TE bestimmt, wo der Traffic langläuft. QoS bestimmt, wie er sich bei Contention verhält.
Warum SR-TE allein keine Sprach- und Videoqualität garantiert
SR-TE kann Engpässe umgehen – aber nicht alle. Zudem kann Congestion auch dann entstehen, wenn der Pfad optimal ist, etwa durch Microbursts oder durch plötzliche Traffic-Shifts bei Failover. Echtzeitdienste reagieren dabei besonders empfindlich.
- Microbursts: Kurzzeitige Peaks füllen Queues, auch wenn die Durchschnittslast niedrig ist.
- Failover-Lastsprünge: Fast Reroute oder IGP-Konvergenz verschiebt Verkehr schlagartig auf wenige Links.
- Interconnect-Engpässe: Peering/Transit-Kanten können die QoE dominieren, selbst wenn der Core sauber ist.
- Unsauberes Klassen-Mapping: Wenn DSCP/TC nicht konsistent ist, landet Voice im Best Effort – SR-TE hilft dann nicht.
Deshalb ist die Kernstrategie: SR-TE zur proaktiven Lastverteilung, QoS zur robusten Behandlung im Worst Case.
Die Basis bleibt DiffServ: Klassenmodell und Per-Hop Behavior
In Telco-Backbones ist DiffServ (DSCP-basierte Klassen) weiterhin der Standard für skalierbares QoS. SR ändert daran grundsätzlich nichts. Sie benötigen ein kleines, klar definiertes Klassenmodell, das netzweit konsistent umgesetzt wird.
- Voice Media: Low Latency, strict priority, aber begrenzt.
- Voice Signaling/Control: hoch priorisiert, gewichtete Behandlung.
- Interaktives Video: bevorzugt, gewichtet, mit garantierten Anteilen.
- Best Effort: fair behandelt, kontrollierte Puffer gegen Bufferbloat.
- Background/Scavenger: niedrig priorisiert.
Wichtig ist die Regel: Strict priority nur für Voice Media und immer mit Limit. Video ist zu groß und zu variabel für strict priority und sollte stattdessen über gewichtete Klassen stabilisiert werden.
QoS-Markierungen bei SR: DSCP, MPLS-TC und konsistentes Mapping
In SR-MPLS-Backbones wird QoS häufig über MPLS Traffic Class (TC/EXP) umgesetzt. Das IP-Paket kann DSCP tragen, der Core arbeitet aber meist labelbasiert. Daher muss das Mapping sauber sein:
- Ingress (PE/Edge): Klassifizieren und DSCP setzen bzw. übernehmen (Trust Boundary), dann DSCP in MPLS-TC übersetzen.
- Core (P-Router): Queues/Scheduler basieren auf MPLS-TC, nicht auf Applikationserkennung.
- Egress: DSCP wird wiederhergestellt oder gemäß Übergabeprofil gesetzt.
Ein SR-TE-Pfad kann nur dann „Voice-freundlich“ sein, wenn entlang des gesamten Pfads die TC-Klassen identisch gequeued werden. Inkonsistente Templates sind eine der häufigsten Ursachen für „QoS wirkt mal so, mal so“.
SR-TE und QoS: Zwei Hebel mit unterschiedlichen Zielen
Damit die Kombination sauber funktioniert, sollten Sie beide Werkzeuge klar rollenbasiert einsetzen:
- SR-TE: verhindert Hotspots, reduziert Congestion-Wahrscheinlichkeit, stabilisiert Latenz-Varianz durch Pfadkontrolle.
- QoS: minimiert Schaden bei Congestion, schützt Echtzeitklassen, hält Queueing Delay niedrig.
Praktisch heißt das: Sie planen SR-TE-Pfade so, dass kritische Dienste möglichst selten in Congestion laufen, und Sie konfigurieren QoS so, dass Congestion-Ereignisse für Echtzeit nicht hör- oder sichtbar werden.
Designmuster 1: „Default SR + QoS überall“ – der robuste Standard
Viele Provider starten mit einem stabilen Basismuster: SR als Underlay, QoS durchgängig nach DiffServ-Templates, und SR-TE nur selektiv. Das ist operativ oft der beste Einstieg.
- Einheitliche QoS-Templates pro Routerklasse (PE vs. P) mit identischen Queue-/Scheduler-Profilen.
- End-to-End Markierung (DSCP/TC) mit klarer Trust Boundary an den Rändern.
- SR-TE zunächst für Sonderfälle, etwa zur Umgehung wiederkehrender Hotspots oder für dedizierte Premium-Services.
Der Vorteil: Schon ohne komplexe TE-Policy bleibt Echtzeit unter Last stabil. SR-TE ist dann ein Optimierungswerkzeug, nicht eine Krücke.
Designmuster 2: „SR-TE für Echtzeit“ – gezielte Pfade für Voice & Video
Wenn Sie SLAs für Voice/Video aktiv absichern möchten, kann SR-TE genutzt werden, um Echtzeittraffic über weniger belastete oder besser dimensionierte Trunks zu lenken. Dabei ist wichtig, dass Sie die Steuerung nicht zu fein granulierter machen, sonst wächst die Betriebscomplexität.
- Nur wenige TE-Policies: z. B. eine Policy für Echtzeit, eine für Business, der Rest default.
- Klassenbasierte Anwendung: TE-Policy wird anhand der Serviceklasse angewendet, nicht pro Applikation.
- Pfadkriterien definieren: niedrige Auslastung, stabile Latenz, robuste Failover-Kapazität.
Wichtig: Wenn Sie SR-TE für Echtzeit nutzen, müssen Sie dennoch QoS beibehalten. SR-TE reduziert Congestion, eliminiert sie aber nicht zuverlässig, insbesondere bei Failover.
Designmuster 3: „Interconnect schützen“ – SR-TE rund um Peering-Hotspots
Viele Qualitätsprobleme für UC/Video entstehen an Übergängen zu Cloud- und Content-Netzen. SR-TE kann helfen, Traffic so zu führen, dass bestimmte Interconnects oder Metro-Engpässe entlastet werden.
- Traffic um Hotspots lenken: SR-TE vermeidet wiederkehrend überlastete Trunks.
- QoS am Edge scharf setzen: Shaping/Policing und Queueing am Übergang verhindern Drop-Cluster.
- Monitoring pro Übergang: Drops und Queueing Delay pro Klasse sichtbar machen, sonst bleibt die Ursache verborgen.
Diese Strategie ist besonders effektiv, wenn Sie die größten QoE-Probleme nicht im Core, sondern an den Kanten sehen.
Queueing, Shaping und Microbursts: Der unterschätzte Teil bei SR-TE
SR-TE kann Last verteilen, aber Microbursts bleiben. Gerade bei Aggregation und bei Traffic-Shift-Ereignissen entstehen kurze Spitzen, die Queues füllen. Deshalb brauchen Sie im SR-Backbone weiterhin:
- Saubere Queue-Limits: um Bufferbloat zu vermeiden und Latenzspitzen klein zu halten.
- Shaping an Rate-Limits: insbesondere an Links mit CIR/PIR oder an Interconnects.
- Priority mit Limit: Voice bleibt geschützt, ohne andere Klassen zu verhungern.
Eine praktische Regel im Betrieb: Wenn Sie Jitter-Spikes sehen, prüfen Sie nicht nur Pfade, sondern zuerst Queue-Depth und Drops pro Klasse. Viele „SR-TE hilft nicht“-Fälle sind in Wahrheit Queueing-Probleme.
Failover und SR-TE: QoS für den Worst Case auslegen
SR-TE kann Failover sehr schnell machen, aber schnelle Umschaltungen können Traffic konzentrieren. Für Echtzeit ist nicht nur das Umschaltintervall relevant, sondern die Last danach.
- Worst-Case Pfade planen: TE-Policies sollten auch im Failover-Fall ausreichende Kapazität bieten.
- QoS-Profile auf Failover dimensionieren: Gewichte und Limits dürfen nicht nur für Normalbetrieb passen.
- Event-Korrelation: Umschalt-Events mit Drops/Jitter-Spikes korrelieren, um Hotspots zu erkennen.
In SLA-Umgebungen ist das oft der entscheidende Unterschied: Ein Netz kann im Normalbetrieb perfekt sein und nur bei Failover die Echtzeitqualität verlieren. Das muss in Design und Tests berücksichtigt werden.
Monitoring: Wie Sie SR-TE und QoS gemeinsam validieren
Wenn SR-TE und QoS kombiniert werden, müssen Sie sowohl Pfad- als auch Klassenverhalten sichtbar machen. Ein sinnvolles Monitoring-Set umfasst:
- Pfadtelemetrie: welche TE-Policy wurde genutzt, welche Links waren aktiv, wie änderte sich der Pfad bei Events?
- QoS-Telemetrie: Queue-Drops pro Klasse, Queue-Depth/Queueing Delay, Shaping-Rate, Policer-Hits.
- Aktive Messungen: Jitter/Loss/Delay über kritische Pfade (idealerweise pro Klasse).
- Service-KPIs: MOS/R-Faktor für Voice (wo verfügbar), UC-/Video-QoE-Indikatoren bei managed Services.
Ein operativ starker Indikator bleibt: Drops in der Voice-Klasse sind ein Incident. SR-TE kann helfen, die Ursache zu vermeiden, aber QoS muss Drops auch dann verhindern, wenn Congestion doch eintritt.
Best Practices: SR-TE und QoS sinnvoll kombinieren
- QoS zuerst stabilisieren: Einheitliche DiffServ-Templates und sauberes DSCP->TC Mapping schaffen die Basis.
- SR-TE gezielt einsetzen: Für Hotspots, Premium-Services oder Interconnect-Optimierung – nicht für jede Kleinigkeit.
- Audio vor Video: Voice strict priority mit Limit, Video gewichtet mit Garantien.
- Shaping an Kanten: Interconnects und Rate-Limits sind typische Orte für Drop-Cluster.
- Failover testen: QoS- und TE-Design muss im Worst Case funktionieren, nicht nur im Normalbetrieb.
- Monitoring zweistufig: Pfadtelemetrie plus QoS-Queue-Telemetrie, sonst bleibt die Ursache unsichtbar.
Häufige Fragen zu QoS bei Segment Routing
Macht SR-TE QoS überflüssig?
Nein. SR-TE reduziert die Wahrscheinlichkeit von Congestion, aber kann sie nicht garantiefrei eliminieren. QoS bleibt notwendig, um bei unvermeidbaren Engpässen Voice und Video zu schützen und Queueing Delay zu kontrollieren.
Sollte ich für jede QoS-Klasse eine eigene SR-TE-Policy bauen?
In der Regel nicht. Das erhöht Komplexität und Betriebsrisiko. Besser ist ein kleiner Satz an Policies (z. B. Echtzeit vs. Standard), kombiniert mit stabilen QoS-Templates. So bleibt das System skalierbar und nachvollziehbar.
Was ist der häufigste Fehler bei der Kombination von SR-TE und QoS?
Pfadsteuerung zu optimieren, aber das Klassen-Mapping und Queueing zu vernachlässigen. Wenn DSCP->MPLS-TC inkonsistent ist oder Voice nicht zuverlässig in Low-Latency-Queues landet, hilft auch der beste TE-Pfad nicht. Die Basis ist immer konsistentes QoS – SR-TE ist der Verstärker.