DSCP Strategie für Telcos: Klassenmodelle (EF/AF/CS) sinnvoll mappen

Eine saubere DSCP Strategie für Telcos ist die Grundlage dafür, dass QoS nicht nur „irgendwie“ funktioniert, sondern end-to-end konsistent, skalierbar und auditierbar bleibt. DSCP-Markierungen (Differentiated Services Code Point) sind im IP-Netz die gemeinsame Sprache, mit der Traffic-Klassen (z. B. Echtzeit, Business Critical, Best Effort) in eine konkrete Behandlung in Queues und Scheduler übersetzt werden. Gerade in Provider-Netzen ist das entscheidend, weil viele Domänen zusammenkommen: Access, Aggregation, Core, Interconnect, MPLS/Segment Routing, eventuell Metro-Ethernet und Overlays. Ohne ein konsistentes Mapping von EF/AF/CS entstehen typische QoS-Löcher: Voice ist am Access priorisiert, landet aber im Core als Best Effort; Partnernetze remarken „unbekannte“ DSCPs; oder Premium-Queues werden durch Missmarking geflutet. Eine gute DSCP Strategie für Telcos definiert deshalb ein schlankes Klassenmodell, klare Trust Boundaries, eine Allowlist zulässiger Markings und eindeutige Übersetzungen zwischen DSCP, 802.1p/PCP und MPLS-TC – und macht die Wirkung messbar über Drops, Queue-Delay und Service-KPIs.

Warum DSCP in Telco-Netzen anders gedacht werden muss

In Enterprise-Netzen wird DSCP oft „am Endgerät“ gesetzt und innerhalb einer Organisation weitgehend vertraut. In Telco-Netzen ist das nicht möglich: Kunden, CPEs und Drittanbieter können beliebig markieren. Deshalb muss eine DSCP Strategie immer zwei Dinge gleichzeitig leisten: Sie muss die gewünschte Servicequalität ermöglichen und sie muss das Netz vor Missbrauch schützen. Das gelingt über Trust Boundaries (wo wird Marking akzeptiert?), über Profile (welche Klassen sind für welchen Kunden erlaubt?) und über konsequentes Remarking (was passiert mit falschen oder übermäßigen Markierungen?).

• Skalierung: wenige, klar definierte Klassen sind operativ beherrschbar.
• Multi-Domain: DSCP muss über Übergänge hinweg konsistent gemappt werden.
• Missmarking: ohne Kontrolle fluten Kunden Premium-Queues und destabilisieren QoS.
• SLA-Fähigkeit: nur messbare, reproduzierbare Klassentreatment sind SLA-tauglich.

Die DSCP-Bausteine: EF, AF, CS und was sie praktisch bedeuten

DSCP teilt den IP-Traffic in Per-Hop Behaviors (PHB) ein. In der Praxis werden in Telco-Designs vor allem drei Kategorien genutzt: EF (Expedited Forwarding) für strikte Echtzeit, AF (Assured Forwarding) für priorisierte/gesicherte Klassen mit Drop-Prioritäten und CS (Class Selector) für Kontroll- und Legacy-Klassen. Entscheidend ist nicht der Name, sondern die netzweite Bedeutung: EF muss überall „Echtzeit mit strikter Queue“ heißen, AF muss überall „gewichtete Klasse mit definierter Drop-Policy“ heißen, und CS-Klassen müssen überall denselben Schutzgrad haben.

• EF: typischer Kandidat für Voice Media (RTP) – sehr niedrige Latenz, sehr niedriger Jitter, strikt limitiert.
• AF: Kandidat für Video, Business Critical, Streaming – mit Drop-Prioritäten (z. B. AFxy).
• CS: häufig für Network Control/Management/Signaling oder als kompatible „Legacy“-Einstufung.

AF-Klassen verstehen: Warum AF nicht nur „eine“ Klasse ist

AF ist in Drop-Prioritäten unterteilt (z. B. AF41/AF42/AF43). In Provider-Netzen lässt sich das nutzen, um innerhalb einer Klasse unterschiedliche Verwerfungswahrscheinlichkeiten zu definieren, typischerweise in Kombination mit WRED/ECN oder ähnlichen AQM-Mechanismen. Wichtig ist dabei: Drop-Prioritäten sind nur sinnvoll, wenn sie netzweit identisch behandelt werden und wenn die Anwendungen/Produkte diese Semantik auch wirklich brauchen. Ansonsten erzeugen sie Komplexität ohne Nutzen.

Vom Klassenmodell zur DSCP-Tabelle: Der wichtigste Schritt im Design

Eine DSCP Strategie beginnt mit einem Klassenmodell, nicht mit einer Liste von DSCP-Werten. Der Ablauf ist: Serviceklassen definieren (Voice, Video, Signaling, Business, Best Effort, Scavenger), dann pro Klasse das gewünschte PHB festlegen (Queueing/Scheduling/Drop-Verhalten), und erst dann DSCP-Werte auswählen, die diese Bedeutung transportieren. Der größte Fehler ist, „historische DSCP-Werte“ zu übernehmen, ohne die Semantik zu dokumentieren. Telco-tauglich ist eine zentrale DSCP-Mapping-Matrix, die auf jedem Gerät und in jeder Domäne gleich gilt.

• Schritt 1: Klassenmodell (wenige Klassen, klare Zwecke).
• Schritt 2: PHB-Definition pro Klasse (LLQ, CBWFQ, Drop-Policy, Queue-Limits).
• Schritt 3: DSCP-Werte zuweisen (EF/AF/CS/BE) und dokumentieren.
• Schritt 4: Mappings zu PCP/WMM/MPLS-TC festlegen und testen.

Bewährte Telco-Klassen: Welche Dienste typischerweise wohin gehören

Auch wenn jedes Netz eigene Anforderungen hat, gibt es ein bewährtes Muster: Voice Media bekommt EF, interaktives Video häufig AF4x oder eine hoch priorisierte AF-Klasse, Signalisierung und Network Control werden über CS-Klassen geschützt, Business Critical erhält eine eigene AF-Klasse, Best Effort bleibt DSCP 0, und Bulk/Scavenger erhält eine nachrangige Klasse. Der entscheidende Punkt ist die Limitierung: EF darf niemals „unendlich“ sein; AF-Klassen brauchen klare Budgets; Control-Traffic darf nie verhungern.

• Voice Media (RTP/SRTP): EF, LLQ, strikt limitiert.
• Voice Signaling (SIP/RTCP): häufig CS oder AF mit kleiner garantierter Bandbreite, nicht in EF.
• Interaktives Video: häufig AF4x, gewichtete Echtzeitklasse, keine strikte Priorität wie Voice.
• Business Critical Data: AF3x oder AF2x, abhängig vom Modell, mit definiertem Mindestanteil.
• Network Control: CS (typisch hoch geschützt), getrennt von Datenklassen.
• Best Effort: DSCP 0.
• Bulk/Scavenger: CS1 oder eine explizit nachrangige Klasse.

Trust Boundaries: Das Herzstück jeder DSCP Strategie im Provider-Netz

Ohne Trust Boundaries wird DSCP zum Sicherheits- und Stabilitätsrisiko. Die DSCP Strategie muss daher definieren, wo Marking akzeptiert wird und wo nicht. In Managed-Services-Setups kann Trust näher an den Endpunkten liegen, weil Geräte und Policies kontrolliert sind. In Broadband- oder Wholesale-Szenarien wird Marking typischerweise am BNG/PE oder an einer Service Edge neu gesetzt oder normalisiert. Wichtig ist ein Allowlist-Ansatz: Nur definierte DSCP-Werte dürfen durchgehen, alle anderen werden auf Best Effort gesetzt. Zusätzlich werden Profile pro Kunde/Service durchgesetzt, damit EF/AF nicht beliebig wächst.

• Accept: nur dort, wo Identität/Policy klar ist (Subscriber/Service-Kontext).
• Normalize: unbekannte DSCP-Werte auf DSCP 0 setzen.
• Enforce: Policing/Remarking pro Klasse, um Budgets einzuhalten.
• Audit: Zähler für Remarking/Policer, um Missmarking sichtbar zu machen.

Mapping zu Layer 2 und MPLS: DSCP allein reicht im Telco-Netz nicht

Telco-Netze sind selten reine „IP-only“-Netze. Metro-Ethernet, VLAN-Tagging, MPLS und Segment Routing sind üblich. Deshalb muss eine DSCP Strategie immer auch die Übersetzung zwischen Layern festlegen: 802.1p/PCP für Ethernet-Queues, WMM für WLAN-nahe Domänen und MPLS-TC/EXP für den Core. Die häufigste Ursache für QoS-Löcher ist ein inkonsistentes Mapping: EF wird am PE korrekt in MPLS-TC gesetzt, aber am nächsten Hop anders interpretiert; oder PCP wird auf einem Switch überschrieben und DSCP geht „verloren“.

• DSCP ↔ PCP: Konsistenz in Metro/Access-Switching, sonst landet Echtzeit in falschen Queues.
• DSCP ↔ MPLS-TC: Core-Transport muss die Serviceklassen zuverlässig tragen.
• WMM-Mapping: falls WLAN im Scope ist, muss DSCP in passende Access Categories übersetzt werden.
• Overlay/Underlay: DSCP muss in Outer Header übernommen werden, sonst sieht das Underlay Best Effort.

AF-Drop-Prioritäten sinnvoll nutzen: Schutz ohne Komplexitätsfalle

AF-Klassen bieten Drop-Prioritäten, die zusammen mit AQM (z. B. WRED/ECN) genutzt werden können. Das ist im Provider-Betrieb besonders interessant, wenn innerhalb einer Serviceklasse unterschiedliche Traffic-Arten existieren, die bei Congestion unterschiedlich behandelt werden sollen. Ein Beispiel ist Video oder „Assured Data“, bei dem bestimmte Flows bei Stau früher abgeworfen werden dürfen, um die Klasse stabil zu halten. Der kritische Punkt ist Governance: Drop-Prioritäten müssen netzweit gleich funktionieren, sonst entstehen schwer erklärbare Effekte.

• Use-Case: innerhalb einer Klasse „wichtiger“ und „weniger wichtiger“ Traffic, ohne eine neue Klasse zu schaffen.
• Mechanismus: höhere Drop-Priorität wird früher markiert/gedroppt (AQM/WRED), um Queues stabil zu halten.
• Grenze: wenn niemand die Semantik nutzt, erhöhen AF-Varianten nur Komplexität.

DSCP und QoS-Mechanik koppeln: Marking ist nutzlos ohne Queueing und Shaping

Eine DSCP Strategie muss festlegen, wie DSCP in konkrete Scheduler- und Queue-Policies übersetzt wird. EF ohne LLQ ist nicht „Echtzeit“, AF ohne definierte Queue-Anteile ist nicht „Assured“. Zusätzlich ist Shaping oft der entscheidende Hebel, um Congestion an kontrollierbare Orte zu bringen (WAN-Edge, Aggregation). Ohne Shaping liegt die Queue möglicherweise beim Provider oder in einer Black-Box-Domäne, wodurch DSCP zwar gesetzt ist, aber nicht zuverlässig wirkt.

• EF: LLQ mit strikter Obergrenze, kleine Queue-Limits, minimale Verzögerung.
• AF-Klassen: gewichtete Queues mit Mindestbandbreite; optional AQM zur Latenzstabilisierung.
• Best Effort: AQM/ECN besonders wirksam gegen Bufferbloat in TCP-lastigen Klassen.
• Egress Shaping: verlagert Congestion in kontrollierbare Queues, erhöht Reproduzierbarkeit.

Messbarkeit und Audits: DSCP-Strategie muss nachweisbar sein

In Telco-Umgebungen reicht es nicht, DSCP-Werte zu „definieren“. Sie müssen nachweisen können, dass Markings korrekt genutzt, gemappt und durchgesetzt werden. Dazu gehören DSCP-Verteilungen pro Interface, Zähler für Remarking/Policing, Queue-Drops und Queue-Delay pro Klasse sowie Korrelation mit Service-KPIs (z. B. RTP-Loss/Jitter/MOS). Besonders wichtig ist die Betrachtung in kurzen Zeitfenstern und mit Perzentilen, weil Mikrobursts und Busy-Hour-Peaks sonst unsichtbar bleiben.

• DSCP-Distribution: welche Werte treten tatsächlich auf, wo gibt es Ausreißer?
• Remarking/Policer Counters: Beleg für Trust Boundary Enforcement und Profilüberschreitungen.
• Queue Health: Queue-Delay und Drops pro Klasse als unmittelbare QoS-Wirkungsnachweise.
• Service KPIs: Voice/Video-Metriken zur QoE-Korrelation (Jitter, Loss, MOS/R-Faktor).

Typische Fehler in DSCP Strategien und wie Sie sie vermeiden

Die meisten DSCP-Probleme sind keine „fehlenden Features“, sondern Design- und Governance-Probleme: zu viele Klassen, inkonsistente Mappings, fehlende Trust Boundaries oder unlimitierte EF-Behandlung. Diese Fehler führen zu Instabilität und schwer debugbaren Störungen. Eine solide DSCP Strategie für Telcos fokussiert auf wenige Klassen, klare Budgets, konsistente Mappings und einen Rezertifizierungsprozess, der Drift erkennt.

• Zu viele DSCP-Werte: erhöht Komplexität und senkt Konsistenz.
• EF ohne Limit: Missmarking flutet LLQ, andere Klassen verhungern.
• Mapping-Lücken: DSCP↔PCP↔TC nicht identisch, Echtzeit fällt in Best Effort.
• QoS am falschen Ort: Congestion sitzt im Access/WAN, DSCP wird nur im Core beachtet.
• Keine Telemetrie: ohne Queue-Delay/Drops bleibt die Wirkung unbelegt.

Blueprint: Eine DSCP Strategie für Telcos in wiederholbaren Schritten

Ein praxiserprobter Weg beginnt mit einem schlanken Klassenmodell und einer zentralen DSCP-Mapping-Tabelle, die EF/AF/CS eindeutig auf Serviceklassen abbildet. Danach werden Trust Boundaries definiert und mit Allowlist und Remarking abgesichert, inklusive Profilbudgets pro Kunde/Service. Anschließend werden Mappings zu PCP/WMM/MPLS-TC festgelegt und durch Templates netzweit ausgerollt. Die QoS-Mechanik (LLQ, gewichtete Queues, Shaping, optional AQM/ECN für Best Effort) wird an den realen Congestion Points umgesetzt. Abschließend wird die Strategie über Monitoring, Audits und Rezertifizierung operationalisiert, sodass DSCP nicht nur „gesetzt“, sondern end-to-end wirksam und revisionssicher nachweisbar ist.