DSCP EF (Expedited Forwarding) ist die wichtigste QoS-Markierung, wenn es darum geht, eine Real-Time Class für Sprache korrekt aufzubauen. Viele Netzprobleme bei VoIP entstehen nicht, weil Bandbreite fehlt, sondern weil Sprachpakete in Warteschlangen hinter großen Datenströmen „festhängen“: Latenz steigt, Jitter schwankt, und die Verständlichkeit leidet. Genau dafür ist DSCP EF gedacht: Voice-Medienpakete (typischerweise RTP) sollen im Netz eine bevorzugte Behandlung erhalten, sodass sie auch bei hoher Auslastung mit minimaler Queueing-Verzögerung übertragen werden. Gleichzeitig ist EF eine „scharfe“ Klasse – falsch eingesetzt kann sie ein Netz destabilisieren, weil zu viel Traffic in die Real-Time Class gelangt und andere Klassen verhungern. Ein professionelles Design für DSCP EF im Telco- und Enterprise-Umfeld beruht daher auf drei Grundprinzipien: EF nur für echte Sprachmedien, strict priority immer begrenzen, und Markierungen nur dort vertrauen, wo Sie Kontrolle haben (Trust Boundary). Dieser Artikel erklärt DSCP EF für Voice leicht verständlich, zeigt typische Einsatzszenarien, Designregeln und häufige Fehler – damit Ihre Real-Time Class im Betrieb wirklich Sprachqualität liefert, statt neue Störungen zu erzeugen.
Was bedeutet DSCP EF genau?
DSCP steht für Differentiated Services Code Point und ist ein Feld im IP-Header, mit dem Pakete einer Serviceklasse zugeordnet werden. EF (Expedited Forwarding) ist eine definierte DiffServ-Klasse, die für sehr geringe Verzögerung und niedrigen Jitter gedacht ist. In der Praxis wird EF genutzt, um Sprachmedienverkehr (RTP/RTCP) so zu markieren, dass Router und Switches diese Pakete in eine Low-Latency-Queue einsortieren und bevorzugt senden.
- DSCP: Markierung im IP-Header, die die gewünschte Behandlung signalisiert.
- EF: die „Express-Spur“ für Echtzeit, meist für Voice Media reserviert.
- Real-Time Class: organisatorischer Begriff für die Klasse, die im Netz minimalen Delay/Jitter liefern soll.
Wichtig: DSCP EF ist nur die Kennzeichnung. Erst die QoS-Policy auf Ihren Geräten macht daraus echte Priorität – durch Queueing, Scheduling und Limits.
Warum Voice EF braucht: Latenz und Jitter entstehen in Queues
Voice ist im Vergleich zu Video bandbreitenschonend, aber extrem timing-sensibel. Sprachpakete kommen in festen Intervallen (z. B. alle 20 ms) und sind klein. Das eigentliche Problem entsteht, wenn ein Link ausgelastet ist: Dann müssen Pakete warten. Diese Wartezeit (Queueing Delay) schwankt – und genau diese Schwankung ist Jitter.
- Latenz: steigt, wenn Pakete in Warteschlangen stehen.
- Jitter: steigt, wenn die Warteschlange mal kurz, mal lang ist.
- Paketverlust: tritt auf, wenn Queues überlaufen oder Policer droppen.
EF ist dafür gemacht, Voice aus den großen Best-Effort-Queues herauszuhalten. Damit wird die Warteschlangenzeit planbar klein.
Was gehört in EF – und was nicht?
Die wichtigste Designregel lautet: DSCP EF ist für Voice Media, nicht für „alles Wichtige“. Wenn Sie EF zu breit nutzen, verwässert die Klasse und verliert ihren Nutzen.
Typische Kandidaten für DSCP EF
- RTP Sprachmedien: Sprachpakete der Telefonie (VoIP/IMS/UC-Audio).
- RTCP: Steuer-/Qualitätsreports zum Medienstream (oft gemeinsam mit RTP behandelt).
Typische Kandidaten, die NICHT in EF gehören
- Video: interaktives Video benötigt Priorität, aber meist als gewichtete Klasse – Video in EF kann EF „überfluten“.
- SIP-Signalisierung: wichtig, aber nicht so latenzkritisch wie RTP; gehört meist in eine eigene, hoch priorisierte Control-Klasse.
- Geschäftskritische Apps: ERP/VDI sind wichtig, aber nicht strict-real-time; sie profitieren von garantierten Anteilen, nicht von EF.
- Backups/Updates: niemals EF, sonst gefährden sie Echtzeit.
Wenn Sie diese Trennung konsequent durchziehen, bleibt EF klein und zuverlässig – genau das, was eine Real-Time Class sein muss.
EF richtig umsetzen: Klassifizierung, Markierung, Behandlung
Ein sauberes EF-Design folgt einem klaren Ablauf:
- Klassifizieren: Erkennen, welche Pakete Voice Media sind (z. B. anhand Endgeräten, IPs, Ports, oder bereits gesetzter Markierung).
- Markieren: DSCP EF möglichst nah an der Quelle setzen (oder an einem kontrollierten Edge).
- Behandeln: EF im gesamten Pfad auf eine Low-Latency-Queue mappen, die bevorzugt bedient wird.
Der entscheidende Teil ist die Behandlung: Wenn EF zwar gesetzt ist, aber im Backbone nicht auf eine Low-Latency-Queue abgebildet wird, bleibt die Markierung wirkungslos.
Strict Priority: Ja – aber immer mit Limit
In vielen QoS-Designs wird EF in eine Strict-Priority-Queue gelegt. Das ist sinnvoll, weil Voice minimal warten soll. Ohne Limit ist Strict Priority jedoch gefährlich: Wenn zu viel EF-Traffic anliegt (durch Fehlkonfiguration oder Missmarkierung), kann die Priority-Queue alle anderen Klassen verdrängen. Das führt zu massiven Problemen im Best Effort und kann sogar Routing-/Control-Traffic indirekt beeinflussen.
- Priority-Queue nur für EF: keine Mischklasse mit Video oder „Business“.
- Bandbreitenlimit: EF bekommt ein definiertes Maximum, das realistische Peaks abdeckt.
- Queue-Limits klein halten: zu große EF-Puffer erhöhen Delay; EF soll schnell durchlaufen.
Die Real-Time Class bleibt dadurch schnell, aber kontrolliert – und Ihr Netz bleibt unter Last stabil.
Dimensionierung von EF: Wie groß darf die Real-Time Class sein?
EF sollte bewusst „klein“ bleiben. Voice hat typischerweise konstante Bitraten, aber Sie müssen Overhead berücksichtigen (IP/UDP/RTP, ggf. VLAN/MPLS). Zusätzlich kommen Peaks durch gleichzeitige Calls, Konferenzen oder Standortspitzen.
- Codec-Profil kennen: Bitrate und Paketisierungsintervall bestimmen Paketfrequenz und Overhead-Anteil.
- Overhead einrechnen: Nutzlast ist nicht gleich Transportlast.
- Reserve planen: kleine Sicherheitsmargen verhindern Drops bei Peaks.
- Profilierung am Edge: Premium-Traffic sollte pro Standort/Kunde budgetiert sein.
Als praktische Leitlinie gilt: EF so dimensionieren, dass Voice-Pakete praktisch nie gedroppt werden. Drops in EF sind ein starkes Signal für falsche Dimensionierung, falsches Limit oder Missmarkierung.
Trust Boundary: Wer darf EF setzen?
Im Telco- und Provider-Umfeld ist Trust entscheidend. Wenn jeder Endkunde beliebig EF setzen darf, ist die Real-Time Class schnell nutzlos. Deshalb definieren professionelle Designs eine Trust Boundary – also den Punkt, an dem Markierungen akzeptiert werden.
- Trusted: verwaltete VoIP-Telefone, managed SBCs oder Provider-gemanagte CPE – Markierung kann akzeptiert werden.
- Untrusted: PCs, BYOD, öffentliche Internetkunden – Markierung wird überschrieben oder neutralisiert.
- Conditional Trust: Markierung wird akzeptiert, aber innerhalb eines Profils; Überschuss wird remarkt oder begrenzt.
Trust Boundary schützt nicht nur vor Missbrauch, sondern verhindert auch unbeabsichtigte Fehlmarkierung, die EF überfluten würde.
EF in MPLS- und SR-Netzen: DSCP zu TC/EXP sauber abbilden
In MPLS- oder Segment-Routing-Backbones wird QoS häufig auf Basis der MPLS Traffic Class (TC/EXP) umgesetzt. Das bedeutet: Selbst wenn DSCP EF korrekt gesetzt ist, muss es am Provider Edge in die passende TC-Klasse gemappt werden, damit der Core es korrekt queuen kann.
- Ingress-Mapping: DSCP EF → MPLS-TC für Real-Time.
- Core-Behandlung: TC-basierte Low-Latency-Queue für EF-Verkehr.
- Egress-Restore: DSCP bleibt erhalten oder wird gemäß Übergabeprofil gesetzt.
Ein häufiger Praxisfehler ist inkonsistentes Mapping zwischen PE- und P-Routern. Das führt dazu, dass EF im Core nicht wie EF behandelt wird – trotz „richtiger“ Markierung am Rand.
EF in Access- und Metro-Netzen: Wo die größten Fehler passieren
Viele Echtzeitprobleme entstehen nicht im Core, sondern im Access/Metro – dort, wo Engpässe real sind. EF muss deshalb auch an diesen Übergängen sauber funktionieren.
- Upstream-Engpässe: Besonders kritisch im Access; EF muss aus Best Effort herausgehalten werden.
- Microbursts in Aggregation: Shaping und Queue-Limits verhindern Drop-Cluster, die Voice hörbar machen.
- Policer am falschen Ort: harte Drops auf EF zerstören Sprachqualität; besser profilieren und shapen.
Wenn Voice nur zu Peak-Zeiten schlecht ist, liegt die Ursache oft in Aggregations-Queues oder in Rate-Limits ohne sauberes Shaping.
Monitoring: Wie Sie prüfen, ob EF wirklich wirkt
EF ist im Betrieb nur dann vertrauenswürdig, wenn Sie es messen können. Dafür sollten Sie mindestens folgende Datenpunkte haben:
- Queue-Drops in der EF-Klasse: sollten praktisch nicht auftreten; Drops sind ein Alarm.
- Queue-Depth/Queueing Delay: EF-Queue sollte kurz bleiben; hohe Werte deuten auf falsche Limits oder Engpässe.
- Policer-Hits/Remarking: zeigt Profilverletzungen und Missmarkierung.
- RTP-/QoE-Indikatoren: Jitter, Loss und MOS/R-Faktor (wo verfügbar) korrelieren mit EF-Events.
Ein bewährter Betriebsstandard lautet: Wenn EF Drops zeigt, wird nicht „nachjustiert“, sondern die Ursache gesucht – meist Engpass, Missmarkierung oder falsche Limitierung.
Häufige Fehler beim Einsatz von DSCP EF
- Video in EF: überflutet die Real-Time Class, verdrängt andere Klassen, macht Voice am Ende schlechter.
- Strict Priority ohne Limit: Netz wird unter Last unberechenbar, Best Effort verhungert.
- Kein Trust Boundary: Kunden oder Endgeräte markieren zu viel Traffic als EF.
- DSCP ohne Queue-Mapping: Markierung ist da, aber Geräte behandeln sie nicht – EF bringt dann nichts.
- Policing auf EF: Drops auf Voice-Medien führen direkt zu Aussetzern und Roboterstimmen.
- Inkonsequentes MPLS/SR-Mapping: DSCP EF wird nicht korrekt in TC/EXP übertragen.
Best Practices: DSCP EF für Voice als robuste Blaupause
- EF nur für Voice Media: RTP/RTCP, nicht für Video oder „wichtige Apps“.
- Signalisierung separat: eigene Control-Klasse statt EF.
- Priority mit Limit: strict priority ja, aber begrenzt und mit kleinen Queue-Limits.
- Trust Boundary definieren: Markierungen nur aus kontrollierten Quellen akzeptieren, sonst remarken.
- End-to-End Mapping: DSCP → CoS → MPLS-TC konsistent in allen Domänen.
- Shaping an Engpässen: Microbursts glätten, Drop-Cluster vermeiden.
- Monitoring auf Klassenebene: EF-Drops, Queue-Depth, Policer-Hits als Standard-Dashboards.
Häufige Fragen zu DSCP EF
Ist EF immer gleichbedeutend mit „höchster Priorität“?
EF ist eine Markierung für eine Echtzeitbehandlung. Ob es tatsächlich die höchste Priorität im Netz hat, hängt von Ihrer QoS-Policy ab. In den meisten Designs ist EF die Real-Time Class für Voice und bekommt die strengste Behandlung – aber immer mit Limit.
Kann ich EF im öffentlichen Internet durchgängig nutzen?
In der Regel nicht zuverlässig. Viele Netze neutralisieren DSCP an Übergängen. EF wirkt am besten in Netzen, in denen Sie die Policy kontrollieren: Enterprise, Carrier-Backbones, managed Services und definierte Interconnects.
Woran erkenne ich, dass EF falsch eingesetzt ist?
Typische Hinweise sind Drops in der EF-Queue, stark schwankende Queue-Depth oder eine EF-Auslastung, die „zu groß“ wirkt. Oft ist dann entweder Video in EF gelandet, Trust fehlt oder strict priority ist unlimitiert konfiguriert.