SR-MPLS QoS ist in modernen Provider-Netzen ein entscheidender Schritt, um klassische QoS-Mechanik (DiffServ/PHB/Queues) mit segmentbasiertem Traffic Engineering zu verbinden. Während MPLS-QoS traditionell stark über TC/EXP-Mapping und Per-Hop Behavior funktioniert, eröffnet Segment Routing (SR-MPLS) zusätzliche Steuerhebel: SR-TE Policies können Traffic gezielt über bestimmte Pfade lenken – und mit Class-Aware Steering wird diese Pfadwahl nicht „für alle gleich“, sondern klassenbewusst. Genau das ist in der Praxis relevant, weil Congestion nicht immer dort entsteht, wo man sie plant: Cloud-Hotspots, Wartungsumleitungen, ECMP-Hashing, Mikrobursts oder Engpässe an Core-to-Edge Übergängen können Premiumdienste wie Voice, interaktives Video oder Mobile Backhaul treffen, obwohl der Core im Durchschnitt wenig ausgelastet ist. Mit SR-TE können Sie Pfade kontrollieren, mit QoS können Sie Engpässe priorisieren – und mit Class-Aware Steering bringen Sie beides zusammen: Jede Serviceklasse bekommt die Pfade, die zu ihrem Latenz-/Jitter-/Loss-Budget passen, ohne dass Best Effort oder Bulk „versehentlich“ dieselben Premiumpfade belegt und dort Kapazität verbrennt.
Warum SR-MPLS QoS mehr ist als „TC/EXP bleibt gleich“
In SR-MPLS bleibt die grundlegende QoS-Mechanik zwar erhalten: Marking (DSCP/TC) wird in Queues gemappt, Scheduling bestimmt PHB, und Shaping/AQM kontrollieren Congestion. Neu ist jedoch die Pfadsteuerung: Statt dass IGP-Shortest-Path und ECMP die Verteilung „automatisch“ erledigen, definieren SR-TE Policies explizite oder constraintbasierte Pfade. Das ist der Schlüssel, um QoS nicht nur reaktiv (bei Stau) zu betreiben, sondern proaktiv: Premiumklassen können auf „saubere“ Pfade gelenkt werden, während andere Klassen auf Pfade laufen, die throughput-stark, aber latenztechnisch weniger ideal sind.
- DiffServ bleibt relevant: PHB/Queues sind weiterhin die letzte Instanz bei Congestion.
- SR-TE bringt Pfadkontrolle: Sie entscheiden, über welche Links/Nodes Traffic läuft.
- Class-Aware Steering: unterschiedliche Klassen nutzen unterschiedliche SR-TE Policies.
- Stabilität: weniger Hotspots durch gezielte Lastverteilung und Failover-Planung.
Grundlagen: TC/PHB im SR-MPLS-Core
Im SR-MPLS-Core wird QoS typischerweise über die MPLS Traffic Class (TC) umgesetzt, die aus DSCP am Edge abgeleitet wird. Das ist vertraut aus klassischem MPLS. Entscheidend ist, dass TC-Semantik netzweit konsistent bleibt: Voice muss überall „Voice“ bedeuten, Business muss überall „Business“ bedeuten, und Best Effort darf nicht versehentlich in Premium-Queues landen. SR ändert daran nichts – aber SR erhöht die Bedeutung der Konsistenz, weil Pfadwahl und Queueing zusammenspielen: Wenn eine Klasse auf einen „Premium-Pfad“ gesteuert wird, muss die Queue-Behandlung entlang dieses Pfades ebenfalls zu dieser Klasse passen.
- Ingress PE: Klassifizierung/Trust Boundary, DSCP→TC Mapping, Budget-Enforcement.
- Core P: TC→Queue/Scheduling, identische PHBs auf relevanten Linktypen.
- Egress PE: optional TC→DSCP Mapping, Service-spezifische Egress-Policies, Interconnect-Shaping.
SR-TE Policies: Was sie leisten und wo sie in der QoS-Kette sitzen
SR-TE Policies sind Steuerobjekte, die bestimmen, wie Traffic durch das SR-MPLS-Netz geleitet wird. Praktisch können Policies explizite Segmentlisten nutzen (z. B. über bestimmte Nodes/Links) oder constraintbasierte Pfade auswählen (z. B. „meide diese Links“, „nutze nur diese Region“, „berücksichtige Metriken“). Wichtig ist die Einordnung: SR-TE entscheidet, wo Verkehr läuft. QoS entscheidet, wie Verkehr an jedem Hop behandelt wird. Class-Aware Steering verbindet beides: Die Policy-Auswahl wird abhängig von Klasse, Service oder Traffic-Selector getroffen.
- Explicit: feste Segmentliste, sehr deterministisch, gut für kritische Services und Troubleshooting.
- Dynamic: Pfadauswahl nach Constraints/Metriken, gut für Skalierung und automatisierte Optimierung.
- Policy-Fallback: definierter Rückfallpfad, wenn ein Segment nicht verfügbar ist.
- Failure Behavior: wie schnell und wohin wird umgelenkt, und bleibt QoS dabei konsistent?
Class-Aware Steering: Der Kern des Themas
Class-Aware Steering bedeutet, dass nicht „der ganze Verkehr“ gleich behandelt wird, sondern dass unterschiedliche Klassen (z. B. Voice, Video, Business, Best Effort, Bulk) gezielt unterschiedliche Policies nutzen. Der Nutzen ist klar: Sie können Premiumklassen über Pfade führen, die geringe Latenz und geringe Jitter-Schwankungen bieten, während Best Effort auf Pfade geführt wird, die throughput-stark sind oder im Worst Case „mehr Umweg“ tolerieren. Gleichzeitig verhindern Sie, dass Best Effort Premiumpfade füllt und dadurch die Congestion Domain für Echtzeit verschlechtert.
- Voice/Realtime: bevorzugt niedrig-latenz Pfade, geringe Hop-Anzahl, stabile Links.
- Interaktives Video: bevorzugt stabile Pfade, aber mit größerem Bandbreitenbudget als Voice.
- Business Critical: Pfade mit stabilen RTT-Perzentilen, geringe Loss-Spitzen.
- Best Effort/Bulk: Pfade mit guter Kapazität; darf eher „ausweichen“.
Die häufigste Falle: „Steering ersetzt QoS“
Auch wenn SR-TE Hotspots vermeiden kann, ersetzt es QoS nicht. Engpässe entstehen weiterhin: an Core-to-Edge Übergängen, bei Failover auf weniger Kapazität, bei Mikrobursts an Fan-in Punkten oder bei Interconnects. Wenn Sie nur steuern, aber nicht sauber queueen, kann Premiumtraffic auf dem „richtigen Pfad“ trotzdem leiden, weil Best Effort die Queue aufbläht (Bufferbloat) oder weil Limits fehlen. Umgekehrt bringt die beste Queue nichts, wenn Premiumtraffic systematisch über überlastete Pfade geschickt wird. SR-MPLS QoS ist deshalb immer eine Kombination aus Pfad- und Queue-Design.
- Steering: reduziert Hotspots, verteilt Last, verbessert Planbarkeit.
- QoS/PHB: kontrolliert Warteschlangenverzögerung, Jitter und Drops im Engpass.
- Shaping/AQM: glättet Bursts, reduziert Bufferbloat, stabilisiert RTT-Spitzen.
Designmuster: Policy-Set pro Klasse statt „eine Policy für alle“
Ein praktikables Muster ist, pro Klasse ein Policy-Set zu definieren, das aus Primary, Secondary und Fallback besteht. Voice bekommt z. B. eine besonders deterministische Policy (kurzer Pfad, wenige Hops, bekannte Links), Video bekommt eine Policy mit höherem Kapazitätsfokus, Business bekommt eine Policy mit stabilen RTT-Perzentilen, und Best Effort/Bulk bekommt eine Policy, die Kapazität ausnutzt und Premiumpfade entlastet. Wichtig ist dabei, Failover-Pfade nicht zu vergessen: Wenn Primary ausfällt, darf Secondary nicht plötzlich durch eine Congestion Domain laufen, die Premiumqualität zerstört.
- Primary: optimierter Pfad (z. B. low-latency oder high-capacity je Klasse).
- Secondary: alternativer Pfad, der ähnliche Eigenschaften hat (nicht nur „irgendein“ Pfad).
- Fallback: Worst-Case Pfad, der zumindest kontrolliert und dokumentiert ist.
- Guardrails: Budgets, Limits und Monitoring, damit Secondary/Fallback nicht unbemerkt zum Dauerzustand werden.
Congestion Domains und SR-TE: Pfade so wählen, dass Engpässe beherrschbar bleiben
Class-Aware Steering macht nur dann Sinn, wenn Sie Ihre Congestion Domains kennen. Das sind die Bereiche, in denen sich Flows Engpässe teilen: Hub-Knoten, DC-Edges, Interconnects, Metro-Ringe, PE-Uplinks. SR-TE Policies sollten diese Domains bewusst berücksichtigen: Premiumklassen meiden volatile Engpässe, Best Effort nutzt freie Kapazität, und Bulk wird bewusst auf „weniger wertvolle“ Pfade gelegt. In der Praxis ist das oft der größte Gewinn: Nicht nur Priorität im Stau, sondern Stauvermeidung durch Pfadwahl.
- Hotspot-Vermeidung: Premiumklassen nicht durch bekannte Engpassknoten führen.
- Kapazitätsausnutzung: Best Effort verteilt Last auf mehrere Pfade, statt Premiumpfade zu füllen.
- Maintenance-Awareness: Policies so bauen, dass geplante Wartung nicht Premiumqualität kollabieren lässt.
Shaping und Class-Aware Steering: Warum beides zusammen stärker ist
Viele QoS-Probleme entstehen an Übergängen: PE-Uplinks, Interconnect-Ports, Metro-Aggregation. Dort ist Shaping ein Schlüssel, um die Queue in den eigenen Einflussbereich zu holen. Wenn Sie zusätzlich class-aware steuern, können Sie nicht nur die „richtigen Pfade“ nutzen, sondern auch die „richtigen Shaping Points“ entlasten: Bulk wird auf Pfade geführt, deren Übergänge mehr Headroom haben; Premiumklassen werden über Pfade geführt, an denen die Queue-Profilierung auf geringe Latenz optimiert ist. Das senkt Queue-Delay-Perzentile und reduziert Drop-Bursts.
- Egress Shaping: kontrolliert Congestion, macht Queueing messbar.
- HQoS: per Service/VRF/Customer budgetieren, damit Best Effort Premium nicht verdrängt.
- Policy + Shaper Alignment: Policies auf Pfade legen, deren Übergänge zu den Klassenbudgets passen.
Messbarkeit: Wie Sie nachweisen, dass Class-Aware Steering wirkt
SR-MPLS QoS ist nur dann betrieblich belastbar, wenn Sie Wirkung und Nebenwirkungen messen. Neben klassischen QoS-KPIs (Queue-Delay/Drops pro TC) brauchen Sie SR-TE Sicht: Welche Policy ist aktiv? Wie oft wechselt sie? Welche Pfade werden genutzt? Gibt es Flaps durch Instabilität? Außerdem müssen Sie die QoE-Perspektive berücksichtigen: Für Voice/Video zählen Latenz- und Jitter-Perzentile sowie Loss-Spitzen. Der Nachweis gelingt, wenn Sie vor/nach Policy-Einführung oder pro Policy-Pfad vergleichen – immer in kurzen Zeitfenstern und mit Perzentilen, weil Mikrobursts und Peak-Phasen entscheidend sind.
- Policy-Telemetrie: aktiver Pfad, Umschaltfrequenz, Fallback-Events.
- Queue Health: Queue-Delay p95/p99 und Drops pro TC an kritischen Links.
- Utilization Perzentile: p95/p99 Auslastung pro Link-Bundle, um Hotspots zu erkennen.
- QoE-KPIs: RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen, wo verfügbar.
Typische Failure Patterns bei SR-TE und Class-Aware Steering
Die häufigsten Probleme sind nicht „SR ist schlecht“, sondern Design- und Governance-Lücken. Oft werden Klassen zwar gesteuert, aber die Queue-Profile sind nicht konsistent, sodass Premiumtraffic auf dem Premiumpfad trotzdem in falschen Queues landet. Oder Best Effort wird auf „umwegige“ Pfade gelegt, ohne dass die Kapazitätsmodelle das tragen, was dann neue Hotspots erzeugt. Ebenso kritisch: Failover-Fallbacks werden nicht getestet, sodass im Ernstfall Premiumklassen auf Pfade fallen, die ihre Latenzbudgets reißen.
- Inkonsequentes Mapping: DSCP/TC und Policy-Steering sind nicht aligned; falscher PHB auf dem richtigen Pfad.
- Zu viele Policies: operative Komplexität steigt, Drift und Fehler nehmen zu.
- Instabile Umschaltungen: Policies wechseln zu häufig; Jitter und QoE werden schlechter.
- Failover überrascht: Secondary/Fallback Pfade sind nicht QoS-fähig oder ohne Headroom.
- Falscher Engpass: Congestion liegt am Interconnect/Edge, nicht im Core; Policies helfen nur begrenzt ohne Shaping.
Blueprint: SR-MPLS QoS mit class-aware Steering in wiederholbaren Schritten
Ein robustes Vorgehen beginnt mit einem schlanken Klassenmodell und konsistenten QoS-Grundlagen: DSCP→TC Mapping am Edge als Trust Boundary, TC→PHB im Core mit limitierter LLQ für Voice, gewichteten Klassen für Video/Business und AQM/ECN für Best Effort. Danach definieren Sie Congestion Domains und identifizieren Pfade, die für Premiumdienste geeignet sind. Anschließend bauen Sie SR-TE Policies pro Klasse: Primary/Secondary/Fallback, mit klarer Semantik und dokumentierten Constraints. Class-Aware Steering wird so umgesetzt, dass Traffic-Selector (z. B. Klasse/VRF/Service) deterministisch zur passenden Policy führt. Abschließend wird Telemetrie aufgebaut, die Policy-Events, Queue-Health und QoE-KPIs korreliert, und es wird unter Mischlast getestet – inklusive Failover. So entsteht SR-MPLS QoS, das nicht nur „modern“ ist, sondern im Carrier-Betrieb planbar Premiumklassen schützt und gleichzeitig die Netzressourcen effizient ausnutzt.
