QoS in MPLS steht und fällt mit einem scheinbar kleinen Detail: den EXP-Bits beziehungsweise der MPLS Traffic Class (TC). Viele Telco- und Provider-Netze markieren Voice und Video korrekt mit DSCP (EF/AF), setzen am Rand saubere Policies um und betreiben im Core konsistente Queues – und trotzdem kommt es bei Peak-Last zu Jitter, Drops oder ruckelndem Video. Sehr häufig liegt die Ursache nicht im DiffServ-Design an sich, sondern im Mapping zwischen IP-Markierungen (DSCP) und der MPLS-Klasse, die im Label transportiert wird: Wenn DSCP nicht korrekt in EXP/TC übersetzt wird, sieht der MPLS-Core die gewünschte Klasse nicht und behandelt den Traffic wie Best Effort. Umgekehrt kann ein falsches EXP-Mapping Premium-Klassen aufblasen, sodass LLQ/Voice-Queues überlaufen oder andere Klassen verhungern. Ein professionelles QoS in MPLS bedeutet deshalb: ein konsistentes Klassenmodell definieren, DSCP-zu-EXP (bzw. DSCP-zu-TC) sauber und einheitlich mappen, Trust Boundaries am Provider Edge setzen, geeignete Queue- und Scheduler-Profile im Core verwenden und – je nach Betriebsmodell – ein klares Pipe-/Short-Pipe-/Uniform-Design für die Behandlung von DSCP und TC über Label-Stacks hinweg wählen. Dieser Artikel erklärt, wie EXP-Bits in MPLS korrekt gemappt und transportiert werden, welche Designvarianten es gibt, welche Stolperfallen in Telco-Backbones typisch sind und wie Sie QoS so operationalisieren, dass Voice & Video auch unter Last stabil bleiben.
EXP, TC und DiffServ: Begriffe sauber einordnen
Historisch wurde im MPLS-Label ein 3-Bit-Feld als EXP (Experimental) bezeichnet. In der Praxis wird dieses Feld heute als Traffic Class (TC) genutzt, um QoS-Klassen im MPLS-Core zu signalisieren. Der entscheidende Punkt: Core-Router treffen ihre Queueing- und Scheduling-Entscheidungen häufig anhand dieser MPLS-TC/EXP-Werte – nicht anhand des DSCP im inneren IP-Paket.
- DSCP: 6 Bit im IP-Header, DiffServ-Markierung (z. B. EF für Voice, AF für Video).
- MPLS TC/EXP: 3 Bit im MPLS-Label, häufig Basis für Core-Queueing.
- PHB: Per-Hop Behavior, also die tatsächliche Behandlung (Queue, Scheduler, Drop-Policy).
Damit QoS in MPLS funktioniert, muss das gewünschte PHB im Core aus dem TC/EXP-Wert ableitbar sein. Und dafür braucht es ein sauberes Mapping.
Warum das Mapping so kritisch ist: DSCP sieht der Core oft nicht
Am Provider Edge (PE) wird Kundenverkehr typischerweise in MPLS gekapselt. Danach laufen im Core MPLS-Labels, ggf. als Stack. Viele Plattformen klassifizieren und queuen in der Hardware anhand des äußeren MPLS-Headers. Das IP-DSCP ist dann nicht mehr das primäre Entscheidungskriterium. Typische Konsequenzen:
- DSCP korrekt, TC falsch: Voice ist als EF markiert, landet aber im Core in Best Effort, weil TC/EXP nicht passend gesetzt ist.
- TC korrekt, DSCP am Egress falsch: Im Core läuft es gut, aber an Übergaben wird DSCP nicht wiederhergestellt, und nachgelagerte Netze verlieren QoS.
- Inkonsequente Templates: Unterschiedliche PEs setzen TC anders; QoS wird unvorhersehbar.
Das führt zu dem klassischen Symptom: „Im Access/Edge scheint QoS zu stimmen, aber im Backbone kippt die Qualität.“
Pipe, Short-Pipe, Uniform: Die drei grundlegenden MPLS-QoS-Modelle
In MPLS gibt es unterschiedliche Designphilosophien, wie DSCP und TC über den Label-Stack hinweg behandelt werden. Für die Praxis reicht es, diese drei Modelle zu verstehen:
- Pipe: Der Core nutzt MPLS-TC/EXP für QoS. DSCP im Kundenpaket bleibt primär für den Kunden oder für Egress-Policies relevant, der Core arbeitet „labelbasiert“.
- Short-Pipe: Ähnlich wie Pipe für den Core, aber am Egress kann DSCP wiederhergestellt oder neu gesetzt werden, um Übergaben zu steuern.
- Uniform: DSCP und TC werden konsistent „vererbt“; die QoS-Information wird über den Stack hinweg kontinuierlich propagiert (Konzept: gleiche Bedeutung innen und außen).
In Telco-Backbones sind Pipe oder Short-Pipe häufig die stabilsten Modelle, weil sie den Core als schnellen Klassen-Transport behandeln und Trust/Profilierung am Rand sauber halten. Uniform kann sinnvoll sein, wenn Sie Markierungen bewusst end-to-end propagieren und domänenübergreifend auswerten, erfordert aber sehr hohe Mapping-Disziplin.
Wie viele Klassen passen in 3 Bits? Der praktische Umgang mit 8 TC-Werten
Das MPLS-TC-Feld hat nur 3 Bits – also maximal 8 Werte. Das zwingt zu einem kompakten Klassenmodell. In der Praxis ist das kein Nachteil, sondern oft ein Vorteil: Zu viele Klassen sind im Betrieb schwer beherrschbar. Ein bewährtes Telco-Design nutzt typischerweise 5 bis 7 Klassen, die in TC gemappt werden.
- Voice Media: höchste Echtzeitklasse (typisch EF) – Low Latency Queue, strict priority mit Limit.
- Control/Signaling: hoch priorisiert, gewichtet.
- Interaktives Video: AF-Klasse, gewichtet mit Garantien.
- Business Critical: optional, gewichtete Mindestanteile.
- Best Effort: Standard.
- Background/Scavenger: niedrig priorisiert.
Wichtig: Nicht jeder DSCP-Wert bekommt einen eigenen TC. Stattdessen werden DSCP-Werte auf wenige Providerklassen normalisiert, die dann auf TC/EXP abgebildet werden.
DSCP->EXP Mapping: Der Kernprozess am Provider Edge
Das zentrale technische Element ist die Ingress-Policy am PE: Sie klassifiziert den eingehenden Traffic, entscheidet über Trust/Remarking und setzt dann den MPLS-TC/EXP-Wert, der im Core das Queueing bestimmt.
- Schritt 1: Trust Boundary – welche DSCP-Werte werden akzeptiert, welche werden neutralisiert?
- Schritt 2: Normalisierung – DSCP wird auf Providerklassen reduziert (z. B. EF, AF-Video, Control, BE, Background).
- Schritt 3: EXP/TC setzen – jede Providerklasse bekommt einen TC-Wert, der im Core auf eine Queue gemappt ist.
Wenn Sie diesen Prozess nicht als Standardtemplate definieren, sondern pro PE „nach Gefühl“ konfigurieren, entsteht Mapping-Drift – und QoS wird unzuverlässig.
EXP/TC->Queueing im Core: Der zweite kritische Teil
Das beste Mapping hilft nichts, wenn der Core den TC-Wert nicht konsistent auf Queues und Scheduler abbildet. Im Backbone sollten daher standardisierte QoS-Profile existieren:
- Low Latency Queue für Voice (TC für Voice): strict priority mit Limit, kleine Queue-Limits.
- Weighted Queues für Video und Control: garantierte Anteile, kontrollierte Puffer.
- Best Effort: fair, Bufferbloat vermeiden, ggf. Congestion Avoidance.
- Background: niedrig priorisiert.
Die wichtigste Regel bleibt: Strict priority im Core nur für Voice Media und immer mit Limit. Video ist in MPLS wie überall: bevorzugt, aber gewichtet.
Label-Stack und QoS: Welche Label-Ebene zählt?
In MPLS können mehrere Labels gestapelt sein (z. B. Transportlabel plus Servicelabel). Für QoS ist entscheidend, welche Label-Ebene für TC/EXP ausgewertet wird. In vielen Implementierungen ist das äußere Label maßgeblich, weil es für die Weiterleitung genutzt wird und hardwareseitig am schnellsten zugänglich ist.
- Outer Label TC: häufig die Basis für Core-Queueing.
- Inner Label TC: kann für Service-Logik oder Egress-Entscheidungen relevant sein.
- Konsequenz: Ihre Architektur muss definieren, wo TC gesetzt wird und wie es über Swap/Pop/Push erhalten bleibt.
Ein praktischer Designansatz ist, TC am Ingress so zu setzen, dass es auf dem Label wirksam ist, das im Core wirklich für Queueing herangezogen wird.
TTL und QoS nicht verwechseln: Zwei verschiedene „Vererbungs“-Themen
In MPLS wird oft über TTL-Propagation gesprochen. Das ist ein anderes Thema als QoS-Propagation. Es lohnt sich, die Begriffe getrennt zu halten:
- TTL: schützt vor Routing-Loops und beeinflusst Traceroute-Verhalten.
- TC/EXP: beeinflusst QoS-Queueing und Scheduling.
Beide können „propagiert“ oder „terminiert“ werden, aber sie haben unterschiedliche Ziele. In QoS-Designs sollten Sie explizit festlegen, wie TC/EXP behandelt wird – unabhängig von TTL-Entscheidungen.
Trust Boundary im MPLS-Kontext: Warum EXP nicht „vom Kunden“ kommen darf
Auch wenn Kunden DSCP setzen, sollten sie in der Regel nicht direkt bestimmen, welche TC-Werte im Provider-Core genutzt werden. Das wäre äquivalent zu „Kunden dürfen Core-Queues steuern“. Deshalb ist die Trust Boundary am PE entscheidend:
- Untrusted: DSCP wird neutralisiert, Provider setzt TC basierend auf Produktprofil.
- Conditional Trust: definierte DSCP-Werte werden akzeptiert, aber nur innerhalb von Budgets; Überschuss wird remarkt.
- Trusted: nur für streng kontrollierte Quellen und vertraglich definierte Wholesale-Übergaben.
Das schützt vor Premium-Inflation und stellt sicher, dass TC/EXP-Werte im Core eine stabile Bedeutung haben.
Profilierung, Shaping und Bursts: Warum EXP-Mapping allein nicht reicht
Viele QoS-Probleme in MPLS entstehen nicht durch falsche Klassen, sondern durch Burst-Handling: Microbursts aus Metro/Aggregation treffen auf Core- oder Interconnect-Links. Ohne Shaping und sinnvolle Queue-Limits entstehen Drop-Cluster, die Voice und Video beschädigen – selbst wenn sie korrekt in TC gemappt sind.
- Shaping an rate-limitierten Links: glättet Bursts und reduziert Drop-Cluster.
- Queue-Limits pro Klasse: Voice klein und schnell, Video moderat, Best Effort kontrolliert.
- WRED/Drop-Precedence für Video: In-Profile vs. Out-of-Profile differenzieren, Tail Drop vermeiden.
QoS in MPLS ist daher immer ein Paket aus Mapping, Queueing, Scheduling und Burst-Stabilisierung.
Typische Fehler bei EXP/TC-Mapping – und wie sie sich äußern
- Voice knackt trotz EF: DSCP EF wird nicht korrekt in TC gemappt oder TC wird im Core nicht in LLQ gequeued.
- Video verdrängt alles: Video landet fälschlich in der Voice-TC/LLQ oder Priority ist unlimitiert.
- QoS wirkt nur „manchmal“: inkonsistente Templates; einzelne PEs oder Linecards mappen anders.
- Best Effort kollabiert bei Peaks: Premium-Inflation; zu viel Traffic in hohen TCs, Best Effort verhungert.
- Probleme bei Failover: Traffic-Shifts erzeugen Congestion; Limits/Weights sind nicht auf Worst-Case ausgelegt.
Wenn Sie solche Symptome sehen, ist die schnellste Prüfliste: DSCP->TC am Ingress verifizieren, TC->Queue im Core prüfen, danach Burst-Handling (Shaping/Queue-Limits) betrachten.
Monitoring: Wie Sie nachweisen, dass EXP/TC korrekt transportiert wird
Für MPLS-QoS ist Sichtbarkeit entscheidend. Sie sollten mindestens pro Klasse und pro kritischem Interface sehen können:
- Traffic pro TC: Volumen und Peaks je TC – erkennt Premium-Inflation und Fehlmappings.
- Queue-Drops pro TC: Drops in Voice-TC sind kritisch; Video-Drops deuten auf Gewichte oder Bursts hin.
- Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitter-Risiko.
- Policer-Hits/Remarking: zeigt Profilüberschreitungen am Edge.
- Service-KPIs: MOS/R-Faktor, Jitter/Loss (wo verfügbar) als QoE-Korrelation.
Ein operativer Standard, der sich bewährt: Drops in der Voice-TC sind ein Incident. Das zwingt dazu, Mapping und Limits sauber zu halten.
Praxis-Blueprint: EXP-Bits korrekt mappen und transportieren
- Klassenmodell festlegen: wenige Providerklassen (Voice, Video, Control, BE, Background) mit klarer Bedeutung.
- Trust Boundary definieren: untrusted/conditional/trusted je Produkt; Kundenmarkierungen normalisieren.
- DSCP->TC/EXP Mapping standardisieren: als PE-Template, versioniert, netzweit gleich.
- TC->Queue im Core standardisieren: identische Queue-/Scheduler-Profile auf allen Core-Interfaces.
- Strict priority begrenzen: Voice in LLQ mit Limit, Video gewichtet, Best Effort fair.
- Burst-Handling integrieren: Shaping an Engpässen, Queue-Limits, ggf. Congestion Avoidance für Video/BE.
- Egress-Regeln festlegen: DSCP-Restore oder Übergabeprofil an NNI/UNI klar definieren (Pipe/Short-Pipe/Uniform).
- Monitoring operationalisieren: TC-Traffic, Drops, Queue-Depth, Policer-Hits als Standard-Dashboards.
Häufige Fragen zu QoS in MPLS und EXP-Bits
Reicht es nicht, DSCP im IP-Paket zu setzen?
Im MPLS-Core häufig nicht. Viele Core-Router queuen anhand des MPLS-TC/EXP-Felds. Wenn DSCP nicht korrekt in TC gemappt wird, behandelt der Core den Traffic möglicherweise wie Best Effort – trotz korrekter DSCP-Markierung.
Wie viele Klassen kann ich sinnvoll in EXP/TC abbilden?
Maximal acht Werte sind möglich, aber in der Praxis sind 5 bis 7 Klassen meist ideal. Damit bleiben Mappings beherrschbar, und Sie können Voice, Video, Control und Best Effort sauber trennen, ohne den Betrieb zu überfrachten.
Was ist der häufigste Fehler im Betrieb?
Inkonsequentes DSCP->TC Mapping am Edge oder unterschiedliche QoS-Templates im Core. Das führt dazu, dass dieselbe Markierung je nach Pfad anders behandelt wird – und genau dann wirkt QoS „unzuverlässig“.