Ein MPLS QoS Deep Dive lohnt sich, weil in vielen Provider-Netzen QoS nicht an der Idee scheitert, sondern an Details: PHB (Per-Hop Behavior) wird uneinheitlich umgesetzt, TC (Traffic Class) wird falsch gemappt, LSPs (Label Switched Paths) tragen Klassen inkonsistent, und Scheduling-Mechanismen sind zwar konfiguriert, wirken aber nicht dort, wo Congestion tatsächlich entsteht. MPLS ist dabei keine „QoS-Abkürzung“, sondern ein Transport-Framework, das QoS besonders sauber und skalierbar machen kann – vorausgesetzt, Sie definieren die Semantik netzweit einheitlich und kontrollieren die Engpässe. In der Praxis heißt das: DSCP wird am Edge klassifiziert und in MPLS-TC übersetzt, der Core behandelt Traffic anhand der TC in definierten Queues, und am Egress wird die Semantik wieder korrekt in IP/Ethernet überführt. Gleichzeitig ist QoS in MPLS eng mit Pfadsteuerung verknüpft: LSPs können Traffic bündeln oder verteilen, TE/FRR kann Pfade im Failover verändern, und dadurch verschieben sich Congestion Domains. Wer MPLS QoS wirklich beherrscht, denkt deshalb in vier Schichten: Klassenmodell (was), TC/Mapping (wie signalisiert), LSP/Pfad (wo läuft es) und Scheduling/Queueing (wie wird es bedient) – plus Telemetrie, die Queue-Delay und Drops pro Klasse sichtbar macht.
Begriffe sauber trennen: PHB, TC/EXP, LSP und Scheduling
Viele Missverständnisse entstehen, weil diese Begriffe vermischt werden. PHB beschreibt das gewünschte Verhalten pro Hop (z. B. „Voice bekommt limitierte strikte Priorität“). TC ist das Markierungssignal im MPLS-Label, das dem Router sagt, welcher PHB angewendet werden soll. LSPs sind die Pfade, über die der Verkehr im MPLS-Core läuft; sie beeinflussen, wo Congestion entstehen kann. Scheduling ist die konkrete Implementierung des PHB: Welche Queue wird wie oft bedient, wie werden Drops gesteuert, und wie wird Shaping eingesetzt?
- PHB: Service-Absicht pro Hop (Queue, Priorität, Drop-Verhalten).
- TC (historisch EXP): Klassen-ID im MPLS-Label, die PHB-Auswahl triggert.
- LSP: Pfad durch den Core; bestimmt, welche Links und Congestion Domains relevant sind.
- Scheduling/Queueing: Mechanik, die PHB in echte Paketausgabe übersetzt.
Das Klassenmodell als Fundament: Wenige Klassen, klare Semantik
Ein MPLS-Backbone ist meist Multi-Service: L3VPN/L2VPN, Internet, Mobile Backhaul, Wholesale, UC/Voice/Video, Management und Control. Ein zu feines Klassenmodell erhöht Komplexität und Drift-Risiko – besonders, weil TC-Raum begrenzt ist und weil Plattformen unterschiedliche Queue-Anzahlen unterstützen. Bewährt ist ein schlankes Modell mit wenigen Klassen, die in jeder Domäne identisch verstanden werden. Jede Klasse bekommt ein Budget (Mindest-/Maximalanteil), definierte Queue-Limits und ein klar dokumentiertes Drop-Verhalten.
- Network Control: Routing/OAM/Management – geschützt, damit das Netz unter Last steuerbar bleibt.
- Voice: strikt priorisiert (LLQ), aber strikt limitiert, um Starvation zu verhindern.
- Video (interaktiv): gewichtete Echtzeitklasse, stabiler Anteil, keine unlimitierte Priority.
- Business Critical: bevorzugte Datenklasse für interaktive Workloads.
- Best Effort: Standardklasse, idealerweise mit AQM/ECN gegen Bufferbloat.
- Bulk/Scavenger: nachrangig für Backups/Updates, um Peaks zu dämpfen.
PHB im MPLS-Kontext: Wie „Per-Hop Behavior“ im Core wirklich aussieht
PHB ist im MPLS-Core die wichtigste Spezifikation, weil der Core nicht „den Service kennt“, sondern nur die Klasse. Ein guter PHB-Entwurf beantwortet deshalb sehr konkret: Welche Queue? Welcher Scheduler? Welche Limits? Welche Drop-Policy? Und welche Ziele (Delay, Jitter, Loss) sollen damit erreicht werden? Für Echtzeit ist nicht nur Priorität entscheidend, sondern vor allem kontrollierte Warteschlangenverzögerung. Große Buffers machen weniger Drops, aber mehr Jitter – das ist für Voice oft schlimmer.
- Voice-PHB: LLQ mit Obergrenze, kleine Queue-Limits, Ziel: minimaler Queueing-Delay.
- Video-PHB: gewichtete Queue, Mindestbandbreite, Ziel: stabile Bedienung ohne Starvation anderer Klassen.
- Business-PHB: bevorzugt, fair, Ziel: interaktive Performance und planbare RTT-Perzentile.
- Best-Effort-PHB: AQM/ECN oder WRED-ähnliche Mechanik, Ziel: geringe Bufferbloat-Latenz bei hoher Auslastung.
TC/EXP: Die Klassen-ID im Label – und warum Konsistenz alles ist
Im MPLS-Header trägt TC die Klasse. Die praktische Konsequenz ist hart: Wenn TC falsch gesetzt ist, greift der falsche PHB, egal wie perfekt die Edge-Konfiguration ist. Daher ist ein zentraler Grundsatz: TC-Werte müssen netzweit dieselbe Bedeutung haben. Das klingt banal, ist aber in Multi-Vendor-Umgebungen und über Jahre gewachsene Netze eine der häufigsten Ursachen für QoS-Löcher. Wichtig ist auch: TC ist nicht „QoS an sich“, sondern nur das Signal. Ohne passende Queue-Profile ist TC wertlos.
- TC-Semantik: jeder TC-Wert ist einer Klasse zugeordnet, dokumentiert, getestet, auditierbar.
- TC→Queue: auf jedem Core-Interface identisch (Role/Link-Typ basierte Templates).
- TC-Drift vermeiden: kein region- oder plattformabhängiges „umdeuten“ von TC-Werten.
DSCP↔TC Mapping: Edge-Übersetzung als Trust Boundary
In der Praxis kommt IP-Verkehr mit DSCP am PE an, wird klassifiziert und in TC übersetzt. Genau hier liegt die Trust Boundary: Kunden können DSCP missbrauchen oder falsch setzen. Der PE darf daher nicht blind kopieren, sondern muss normalisieren: Allowlist zulässiger DSCP-Werte, Mapping auf interne Klassen und Profile pro Klasse (Budgets). Gerade Voice (EF) muss fast immer „Trusted with Limits“ sein: akzeptiert, aber strikt begrenzt.
- Allowlist: nur definierte DSCP-Werte werden akzeptiert; Rest wird Best Effort.
- Mapping: DSCP-Werte werden auf interne Klassen gemappt und dann in passende TC-Werte übersetzt.
- Profile: pro Kunde/VRF/Service Bandbreitenbudgets erzwingen (Policing/Degradation).
- Remarking: Überschreitungen degradieren (z. B. EF→AF/BE) statt harte Drops, wenn das Produkt es erlaubt.
LSPs: Pfade, Hotspots und warum QoS ohne Pfaddenken unvollständig ist
LSPs bestimmen, wo Traffic im Core fließt. Damit bestimmen sie auch, wo Congestion entstehen kann. Ein häufiges Missverständnis ist: „QoS ist pro Paket, LSPs sind nur Transport.“ In der Realität kann eine Pfadentscheidung (durch IGP-ECMP, SR-Policies, MPLS-TE oder FRR) Traffic bündeln und dadurch Engpässe erzeugen, obwohl die Gesamtbandbreite ausreichend ist. Für QoS bedeutet das: Sie müssen Congestion Domains im Core identifizieren (Hubs, Core-to-Edge Übergänge, DC/Cloud-Hotspots) und Ihre PHB/Scheduling-Profile gerade dort sauber und messbar halten.
- ECMP: Hashing verteilt nicht immer gleichmäßig; einzelne Links können hot werden.
- TE/SR Policies: können bewusst bündeln; Fehlkonfigurationen erzeugen Congestion.
- FRR/Failover: Backup-Pfade haben oft weniger Headroom; QoS muss auch dort tragen.
- Congestion Domains: LSPs sollten mit Kapazitäts- und QoS-Budgets pro Domain abgestimmt werden.
Scheduling im Core: Strict Priority, Weighted Scheduling und die Kunst der Limits
Scheduling ist die Stelle, an der MPLS QoS „wirklich“ passiert. In Carrier-Designs ist der Klassiker: Voice in eine strikt priorisierte Queue (LLQ), Video und Business in gewichtete Queues, Best Effort in eine große Queue mit AQM/ECN, Bulk nachrangig. Der kritische Punkt ist die Limitierung der strikten Priorität. Eine unlimitierte Priority-Queue ist im Multi-Tenant-Backbone gefährlich: Bei Fehlmarking oder bei unvorhergesehenen Lastspitzen kann sie andere Klassen aushungern. Deshalb müssen LLQ-Budgets realistisch dimensioniert und überwacht werden.
- LLQ: minimaler Delay, aber harte Obergrenze (Rate/Prozent) und Monitoring der Auslastung.
- WFQ/CBWFQ: stabile Fairness für Video/Business, Mindestbandbreiten und Gewichte.
- Queue Limits: gegen Bufferbloat; Echtzeitqueues bewusst kurz, um Jitter zu minimieren.
- AQM/ECN: Best Effort stabilisieren, RTT-Spitzen reduzieren, Throughput erhalten.
PHP, Label-Stack und „wo liegt die QoS-Wahrheit?“
In MPLS-Umgebungen mit mehreren Labels (z. B. Transport-Label plus VPN-Label) ist entscheidend, welche Label-Schicht die TC-Semantik trägt. Zusätzlich kann Penultimate Hop Popping Labels entfernen, bevor der Egress-PE sie sieht. Ein robustes Design legt daher fest, ob der Core die TC aus dem Outer Label nutzt (typisch) und wie Egress-Policies arbeiten, wenn Label-Semantik sich ändert. In Multi-Vendor-Netzen ist das ein häufiger Drift-Punkt: „Es funktioniert auf Plattform A, aber nicht auf Plattform B“, weil unterschiedliche Default-Interpretationen gelten.
- Outer vs. Inner Label: festlegen, wo TC gesetzt wird und welche Schicht für Scheduling maßgeblich ist.
- Egress Mapping: TC→DSCP/PCP bewusst definieren, wenn Traffic in IP/Ethernet zurückgeführt wird.
- Testfälle: PHP, L3VPN, L2VPN, TE/FRR und Failover-Pfade gezielt testen.
Shaping und HQoS: Wo MPLS QoS in der Praxis oft „gewonnen“ wird
Der MPLS-Core ist häufig hochkapazitiv, aber die Engpässe sitzen an Übergängen: PE-Uplinks, Metro-Aggregation, DC-Gateways, Interconnects. Wenn Congestion dort entsteht, ist es entscheidend, dass die Queue kontrollierbar ist. Egress Shaping holt Congestion in das eigene Gerät, HQoS setzt Budgets pro VRF/Service und priorisiert innerhalb. Dadurch werden Mikrobursts geglättet, Drops werden kontrollierbarer und Echtzeitklassen bleiben stabil.
- PE-Uplink Shaping: verhindert, dass Drops „irgendwo“ im Aggregationsnetz passieren.
- Per-Service HQoS: Noisy Neighbor vermeiden, Budgets pro Kunde/VRF einhalten.
- Class-Based Shaping: Video-Bursts glätten, ohne Voice zu gefährden.
Messbarkeit: MPLS QoS ohne Queue-Telemetrie ist Spekulation
Ein Deep Dive ist erst vollständig, wenn Sie es betreiben können. Für MPLS QoS sind queuebezogene KPIs pro TC die wichtigste Wahrheit: Queue-Delay, Queue-Depth, Drops und – falls genutzt – ECN/WRED-Marks. Zusätzlich benötigen Sie Mapping-Integrität: DSCP-Verteilungen an Ingress-PEs, TC-Verteilungen im Core, sowie Zähler für Remarking und Policing. Für Echtzeitdienste sollten Sie außerdem service-nahe KPIs (RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen, falls verfügbar) korrelieren, damit Sie Impact und Ursache zusammenführen können.
- Queue-Delay p95/p99: Frühindikator für Jitter-Probleme, besonders in Echtzeitklassen.
- TC-Drops: Drops in Voice/Control sind kritisch; Best Effort Drops anders bewerten.
- Short-interval Sicht: 1–5 Minuten, Perzentile statt Mittelwerte wegen Mikrobursts.
- Event-Korrelation: TE-Reoptimierung, FRR, Maintenance mit QoS-Abweichungen verknüpfen.
Typische Failure Patterns im MPLS QoS Deep Dive
Die meisten MPLS-QoS-Probleme lassen sich auf wenige Muster zurückführen. Sie sind fast immer Symptome von Inkonsistenz, fehlender Trust Boundary, falscher Limitierung oder fehlender Kontrolle der Congestion Domains. Wenn Sie diese Muster kennen, sparen Sie in Betrieb und Troubleshooting sehr viel Zeit.
- DSCP korrekt, TC falsch: Ingress Mapping fehlerhaft oder unterschiedliche Interpretationen; TC-Semantik netzweit prüfen.
- TC korrekt, Queue falsch: TC→Queue Profile nicht konsistent auf allen Linktypen; Templates/Role-Profile fehlen.
- Voice leidet bei Peaks: LLQ zu klein oder Congestion außerhalb (kein Shaping); Queue-Delay/Drops prüfen.
- Andere Klassen verhungern: LLQ unlimitiert oder Missmarking; Trust Boundaries und Limits verschärfen.
- Failover bricht Qualität: FRR/Backup-Pfad ohne Headroom oder ohne identische QoS-Policies.
Blueprint: MPLS QoS Deep Dive in ein belastbares Design überführen
Ein robustes MPLS-QoS-Design beginnt mit einem schlanken Klassenmodell und einer zentralen Semantik: Jede Klasse hat ein definiertes PHB, Budgets und Messziele. Danach wird DSCP↔TC Mapping am PE als Trust Boundary umgesetzt: Allowlist, Remarking, Profile und Limits, insbesondere für Voice-EF. Im Core wird TC konsequent in Scheduling übersetzt: limitierte LLQ für Voice, gewichtete Klassen für Video/Business, Best Effort mit AQM/ECN, Bulk nachrangig, Network Control geschützt. LSP-/Pfadsteuerung wird als Teil der Congestion-Domain-Planung betrachtet, inklusive Failover-Headroom und Tests. Shaping und HQoS werden an Übergängen platziert, wo Congestion wirklich entsteht. Abschließend wird Telemetrie etabliert, die TC-Queue-Delay/Drops in kurzen Zeitfenstern sichtbar macht und mit Events korreliert. So wird aus einem „Deep Dive“ ein operatives System, das MPLS QoS nicht nur erklären, sondern zuverlässig liefern kann.