QoS im MPLS Netz ist in Telco- und Carrier-Umgebungen ein zentraler Baustein, weil MPLS-Transport häufig das Rückgrat für Business-VPNs, Mobile Backhaul, Metro-Transport, Wholesale-Services und internen Backbone-Traffic bildet. Anders als in reinen IP-Netzen, wo DSCP im IP-Header die primäre Markierung ist, wird im MPLS-Kern meist über die Traffic Class (TC) gearbeitet – historisch oft als EXP-Bits bezeichnet. Genau hier entstehen die typischen Stolpersteine: DSCP wird am Provider Edge gesetzt, aber im Core nicht korrekt in TC gemappt; unterschiedliche Plattformen interpretieren TC unterschiedlich; oder beim Penultimate Hop Popping (PHP) geht die Semantik an Übergängen verloren. Ein professionelles Design für QoS im MPLS Netz muss deshalb drei Dinge gleichzeitig liefern: ein schlankes Klassenmodell (wenige, klare Serviceklassen), ein konsistentes EXP/TC Mapping (DSCP↔TC↔Queue) und eine Governance, die diese Regeln über alle Rollen (PE, P, ASBR, interconnect) hinweg durchsetzt und messbar macht. So wird MPLS QoS nicht zu einer „Label-Magie“, sondern zu einem reproduzierbaren System, das Echtzeitdienste schützt, Datenverkehr fair behandelt und SLAs revisionssicher belegbar macht.
MPLS QoS Grundlagen: DSCP im Edge, TC im Core
In vielen MPLS-Backbones ist die operative Realität: Am Edge kommt IP-Verkehr mit DSCP an, im Core werden MPLS-Labels geschaltet, und die Forwarding-Entscheidung basiert auf Labels statt auf IP. Damit QoS trotzdem funktioniert, wird die Serviceklasse aus dem IP-DSCP in die MPLS-Traffic-Class übertragen. Diese TC (historisch EXP) ist das Signal, das Core-Router (P-Router) für Queueing, Scheduling und Drop-Policies verwenden. Entscheidend ist dabei die Konsistenz: Wenn DSCP→TC nicht sauber ist, kann Voice im Core wie Best Effort behandelt werden oder Business-Traffic in falschen Queues landen.
- Edge (PE): klassifiziert und markiert (DSCP), setzt Profile/Trust Boundaries, mappt in MPLS-TC.
- Core (P): sieht primär MPLS-Labels; QoS basiert auf TC und lokalen Queue-Profilen.
- Egress (PE): mappt TC zurück auf DSCP (falls benötigt), setzt Egress-Policies und Shaping an Übergängen.
EXP vs. TC: Begriffe korrekt einordnen
In vielen Dokumentationen ist noch von „EXP-Bits“ die Rede. Operativ ist heute meist der Begriff „Traffic Class (TC)“ gebräuchlich, weil die Bits im MPLS-Header als Klassenindikator genutzt werden. In der Praxis geht es immer um dasselbe Kernproblem: Sie haben nur wenige Bit-Kombinationen, um Serviceklassen zu transportieren, und müssen diese Kombinationen konsistent in Warteschlangen und Drop-Verhalten übersetzen. Genau deshalb ist ein schlankes Klassenmodell so wichtig: Wenn Sie zu viele Klassen abbilden wollen, wird es unübersichtlich oder es entstehen implizite Prioritäten, die niemand mehr sauber erklärt.
- TC als Klassen-ID: steuert die Auswahl von Queues und Scheduling im Core.
- Begrenzter Raum: nur wenige Klassen sauber und netzweit konsistent abbilden.
- Governance: zentrale Mappingtabellen und Templates sind wichtiger als „mehr Klassen“.
Das Klassenmodell im MPLS-Netz: Weniger Klassen, mehr Stabilität
Ein typisches MPLS-Backbone trägt viele Servicearten: Voice/UC, Video, Business-Daten, Internet/Best Effort, Bulk sowie Network Control/OAM. Ein bewährtes Modell trennt diese Verkehrsarten in wenige Klassen, denen jeweils ein Per-Hop Behavior zugeordnet wird: strict priority (limitiert) für Voice, gewichtete Echtzeitklasse für Video, bevorzugte Datenklasse für Business, Best Effort mit AQM/ECN gegen Bufferbloat, sowie eine Scavenger/Bulk-Klasse. Zusätzlich wird Network Control separat geschützt, damit Routing und OAM auch bei Congestion stabil bleiben.
- Network Control: Routing/OAM/Management – geschützt, sehr geringe Drop-Toleranz.
- Voice: strict priority/LLQ, aber strikt limitiert.
- Video (interaktiv): gewichtete Echtzeitklasse mit Mindestbandbreite, nicht in die Voice-LLQ.
- Business Critical: bevorzugte Datenklasse, fair, aber stabil unter Last.
- Best Effort: Standardklasse, idealerweise mit AQM/ECN zur Latenzstabilisierung.
- Bulk/Scavenger: nachrangig, um Peaks (Backups/Updates) zu dämpfen.
EXP/TC Mapping: Von DSCP zu TC und zurück – ohne QoS-Löcher
Das Herzstück von QoS im MPLS Netz ist das Mapping. Sie benötigen mindestens drei konsistente Tabellen: DSCP→TC (Ingress am PE), TC→Queue/Scheduling (Core und Egress), und optional TC→DSCP (Egress am PE, wenn Kundenverkehr wieder markiert werden soll). Ein häufiger Fehler ist, nur das Ingress-Mapping zu definieren, während die Queue-Profile im Core nicht zur Semantik passen. Ein weiterer Klassiker ist inkonsistentes Mapping zwischen Regionen oder Plattformen: Ein TC-Wert bedeutet im Ring „Video“, im Core aber „Business Data“. Das führt zu schwer erklärbaren QoE-Problemen.
- Ingress Mapping: DSCP wird in TC übersetzt, basierend auf Trust Boundary und Serviceprofil.
- Core PHB: TC bestimmt Queue, Scheduling, Queue-Limits und Drop-Policy.
- Egress Mapping: TC wird optional wieder in DSCP übersetzt, wenn der Kunde DSCP erwartet.
- Konsistenz: dieselbe TC-Bedeutung muss auf allen P- und PE-Plattformen gelten.
Warum „einfach DSCP kopieren“ selten reicht
In Multi-Service-Umgebungen kommt Traffic aus unterschiedlichen Quellen und mit unterschiedlicher Markierungsqualität. Kunden können DSCP missbrauchen, CPEs können falsch markieren, Applikationen nutzen proprietäre Werte. Ein Provider-Edge muss deshalb nicht nur „kopieren“, sondern normalisieren: per Allowlist zulassen, in interne Klassen übersetzen und Budgets erzwingen. Das ist im MPLS-Kontext besonders wichtig, weil TC im Core direkt auf Warteschlangen wirkt.
Trust Boundaries am PE: Welche Markierungen werden überhaupt akzeptiert?
Im MPLS-Netz ist der PE die natürliche Trust Boundary. Hier kennt der Provider Serviceprofil, VRF, VLAN, Kundentyp und SLA. Deshalb wird Marking hier entweder akzeptiert (Managed Services), eingeschränkt akzeptiert (Trusted with Limits) oder ignoriert und neu gesetzt (Untrusted). Ohne diese Kontrolle kann TC missbraucht werden, wodurch Premium-Queues im Core überlaufen. Besonders kritisch ist die Voice-Klasse: strict priority ohne Limit ist ein Stabilitätsrisiko.
- Allowlist: nur definierte DSCP-Werte werden angenommen; Rest wird normalisiert.
- Remarking: Kundenwerte werden auf Provider-Standardwerte gemappt.
- Profile Enforcement: Policing/Degradation pro Klasse, damit TC-Budgets eingehalten werden.
- Auditing: Zähler für Remarking/Policer als Nachweis und Frühwarnsystem.
PHB im Core: Wie TC in echte Warteschlangen übersetzt wird
Im Core ist der wichtigste Punkt: QoS wirkt nur bei Congestion. Auch wenn der Backbone oft „uncongested“ ist, treten ereignisgetriebene Staus auf (Failover, Maintenance, Hotspots, Mikrobursts). Dann entscheidet das Per-Hop Behavior: Voice muss minimalen Queueing-Delay bekommen, aber limitiert sein; Video braucht stabile Behandlung ohne Starvation; Best Effort muss Latenz stabil halten, idealerweise über AQM/ECN. Gleichzeitig muss Network Control geschützt sein, weil Routing/OAM sonst im Stau „blind“ wird und Störungen eskalieren.
- Strict Priority: nur für sehr kleine, echte Echtzeitklassen; immer mit Obergrenze.
- Weighted Scheduling: für Video/Business-Klassen, um Fairness und Stabilität zu kombinieren.
- Queue-Limits: gegen Bufferbloat, besonders relevant für RTT/Jitter in Mischlast.
- AQM/ECN: in Best Effort/Bulk-Klassen, um Latenzspitzen zu reduzieren.
PHP und Egress-Verhalten: Wo Semantik „verloren gehen“ kann
In MPLS-Backbones wird häufig Penultimate Hop Popping genutzt: Der vorletzte Router entfernt das äußere Label, um den Egress-PE zu entlasten. Das kann QoS-Design beeinflussen, weil die Informationsquelle für Queueing sich ändert: Je nach Plattform und Design ist die relevante TC-Information im äußeren oder inneren Label, oder muss aus dem IP-Header abgeleitet werden. Für ein robustes Design ist deshalb entscheidend, dass Sie klar definieren, welche Label-Schicht (outer vs. inner) die QoS-Semantik trägt und wie Egress-Queues sie interpretieren – insbesondere bei L3VPN, L2VPN oder Segmentierung über mehrere Label.
- Label-Stack Semantik: festlegen, wo TC „maßgeblich“ ist (outer, inner oder beides nach Rolle).
- Egress Policies: TC→Queue konsistent, auch wenn Labels vorher gepoppt werden.
- Übergänge: beim Austritt aus MPLS (z. B. zu Internet/Partner) DSCP-Strategie bewusst setzen.
HQoS im MPLS-Kontext: Per-Service Steuerung vor dem Core
Viele QoS-Probleme im MPLS-Netz entstehen nicht im Transit-Core, sondern am Rand: Access- und Metro-Aggregation sowie PE-Uplinks zum Core. Hier hilft HQoS: ein Parent-Shaper kontrolliert den Abfluss, damit Congestion an einem kontrollierbaren Ort entsteht, und Child-Policies priorisieren Klassen innerhalb dieser Rate. Das ist besonders wichtig bei Multi-Service-PEs, die viele Kunden und Serviceklassen bündeln. Ohne HQoS kann ein einzelner Service die gemeinsame Queue dominieren und das Core-QoS „überfahren“, obwohl TC-Mapping korrekt ist.
- Per-Customer/Per-VRF Shaping: verhindert Noisy Neighbor Effekte.
- Per-Class Queues: Voice/Video/Business innerhalb des Profils priorisieren.
- Shaping als Diagnosehebel: hält Congestion lokal, macht Queue-Delay/Drops sichtbar.
Messbarkeit: QoS im MPLS Netz nachweisen, nicht nur konfigurieren
Ein MPLS-QoS-Design ist nur dann betrieblich belastbar, wenn es messbar ist. Besonders wichtig sind queuebezogene KPIs pro TC: Queue-Delay, Queue-Depth, Drops und – falls genutzt – ECN/WRED-Marks. Ergänzend ist Marking-Integrität wichtig: DSCP-Verteilungen an den PE-Interfaces, TC-Verteilungen im Core, Remarking- und Policer-Zähler an Trust Boundaries. Für Voice/Video kommen service-nahe KPIs hinzu (RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen, sofern verfügbar). Der Mehrwert entsteht durch Korrelation: Wenn MOS fällt, muss sichtbar sein, ob Voice-TC Drops hatte oder ob ein Failover einen Engpass geschaffen hat.
- TC Queue Health: Delay und Drops pro TC an kritischen Links.
- Mapping Integrity: DSCP→TC am Ingress, TC→DSCP am Egress, Ausreißer erkennen.
- Short-interval Statistik: p95/p99 in 1–5 Minuten, weil Mikrobursts sonst unsichtbar bleiben.
- Event-Korrelation: TE/BGP/IGP-Änderungen und Maintenance mit QoS-Abweichungen verknüpfen.
Typische Failure Patterns im MPLS-QoS und wie man sie vermeidet
In der Praxis wiederholen sich einige Fehler. Sie sind selten „MPLS-spezifische Magie“, sondern fast immer Inkonsistenz oder fehlende Kontrolle am Rand. Besonders häufig: Kundenmarkings werden blind übernommen, EF wird nicht limitiert, DSCP→TC ist korrekt, aber TC→Queue ist falsch, oder Egress-Übergänge remarken unerwartet. Ebenso kritisch sind Failover-Szenarien: QoS ist im Normalpfad sauber, aber Backup-Links haben andere Queue-Profile oder weniger Headroom.
- Blindes Trusting: Kunden fluten EF/AF; Premium-Queues werden Best Effort.
- TC-Drift: gleiche TC-Bits bedeuten in verschiedenen Regionen etwas anderes.
- Unlimitierte Priority: Voice-Klasse verdrängt andere Klassen bei Fehlmarking oder Lastspitzen.
- Übergangsprobleme: PHP/Label-Stack Semantik unklar; Egress interpretiert falsch.
- Failover bricht QoS: Backup-Pfad ohne kompatible Policies; Tests unter Last fehlen.
Blueprint: QoS im MPLS Netz als wiederholbares Carrier-Pattern
Ein bewährtes Vorgehen beginnt mit einem schlanken Klassenmodell und einer zentralen Mapping-Matrix für DSCP↔TC↔Queue. Danach werden am PE Trust Boundaries definiert: Allowlist, Remarking und Profile, insbesondere strikte Limits für die Voice-LLQ. Im Core wird TC konsistent in PHBs umgesetzt: limitierte Priority für Voice, gewichtete Klassen für Video/Business, Best Effort mit AQM/ECN gegen Bufferbloat, Bulk nachrangig und Network Control geschützt. Shaping und HQoS werden an den realen Congestion Points platziert (PE-Uplinks, Metro-Aggregation, Interconnects), damit die Queue kontrollierbar bleibt. Abschließend wird Telemetrie etabliert: Queue-Delay/Drops pro TC, Mapping-Integrität und Event-Korrelation bei Failover. So entsteht ein MPLS-QoS-Design, das nicht nur „in der Konfiguration“ stimmt, sondern auch unter Last, Mikrobursts und Umleitungen reproduzierbar die Servicequalität liefert.
