QoS in SD-WAN im Telco-Kontext ist deutlich mehr als „ein paar Klassen im Overlay“. Sobald ein Provider SD-WAN als Managed Service anbietet oder SD-WAN-Overlays über ein Carrier-Backbone transportiert, treffen zwei Welten aufeinander: das serviceorientierte Telco-QoS (DiffServ, DSCP/CoS/MPLS-TC, SLAs, NNI-Übergaben) und die applikationsorientierte SD-WAN-Logik (App-ID, Pfadselektion, Dynamic Steering, FEC/Duplizierung, Per-Tunnel-Policies). Genau hier entstehen typische Qualitätsprobleme: Voice ist im SD-WAN korrekt als „Real-Time“ klassifiziert, aber im Underlay wird das Outer-DSCP nicht gesetzt und der Verkehr läuft faktisch als Best Effort. Oder der Provider-Core transportiert MPLS-TC sauber, aber die SD-WAN-Edges remappen DSCP inkonsistent, sodass Video plötzlich in einer zu kleinen Queue landet. Oder Pfadselektion schaltet bei Grenzwerten zu aggressiv um, wodurch Reordering und Jitterspitzen entstehen, die VoIP stärker schädigen als ein etwas schlechterer, aber stabiler Pfad. Ein professionelles Design für Priorisierung über Overlay muss deshalb end-to-end denken: von der Applikationserkennung am Edge über die Trust Boundary, die Markierungsstrategie (inner/outer), die Underlay-Mappings bis hin zur Verifikation per Probes und Telemetrie. Dieser Artikel erklärt verständlich, wie QoS in SD-WAN im Telco-Kontext zuverlässig funktioniert, welche Architekturprinzipien sich bewährt haben und wie Sie typische Stolperfallen vermeiden, damit Voice & Video auch bei dynamischer Pfadwahl stabil bleiben.
Warum SD-WAN-QoS im Telco-Umfeld anders ist als im reinen Enterprise-WAN
In einem reinen Enterprise-SD-WAN kontrolliert ein Betreiber häufig beide Seiten: Edge-Geräte, Transportlinks und Policies. Im Telco-Kontext kommen zusätzliche Faktoren hinzu:
- Mehrere Domänen: Customer Edge, Provider Access, Aggregation/Metro, Core, ggf. Peering/Transit – QoS muss über Übergaben hinweg konsistent bleiben.
- SLA-Orientierung: Telcos müssen definierte Qualitätsziele liefern und nachweisen (Perzentile, Verfügbarkeit, KPI-Reporting).
- Multi-Tenant: QoS muss pro Kunde isoliert sein (Fairness, Profile, Schutz vor Premium-Inflation).
- Heterogene Underlays: MPLS, Internet, LTE/5G, DIA, Ethernet Access – jedes Underlay hat andere Eigenschaften und QoS-Fähigkeiten.
Die Konsequenz: SD-WAN-QoS darf nicht nur „im Overlay“ existieren. Sie muss mit dem Underlay-QoS zusammenspielen, sonst verpufft die Priorisierung.
Grundlagen: Overlay-QoS vs. Underlay-QoS
SD-WAN erzeugt in der Regel Tunnel (Overlay) über ein oder mehrere Underlays. QoS kann auf beiden Ebenen wirken:
- Overlay-QoS: Klassifizierung nach Anwendung/DSCP, Scheduling und Shaping auf dem Tunnelinterface oder dem physischen WAN-Port am Edge.
- Underlay-QoS: Behandlung im Provider-Netz (Access/Metro/Core), meist über DSCP/CoS/MPLS-TC und Queueing an Engpässen.
Damit Echtzeit wirklich priorisiert wird, muss das Underlay die Priorität erkennen. Das heißt praktisch: Outer-Header-Markierungen (DSCP/TC/CoS) müssen korrekt gesetzt und über alle Domänen konsistent gemappt werden.
Der häufigste Fehler: Inner-DSCP stimmt, Outer-DSCP fehlt
Viele SD-WAN-Tunnel kapseln IP-Verkehr (häufig über UDP-basierte Tunnel) und verschlüsseln ihn. Dadurch sieht das Underlay nicht mehr den inneren DSCP-Wert des ursprünglichen Pakets. Es sieht nur den äußeren (Outer) IP-Header des Tunnels. Wenn dieser Outer-DSCP nicht korrekt gesetzt wird, wird der gesamte Tunnel wie Best Effort behandelt.
- Auswirkung: Voice/Video ist im Overlay richtig klassifiziert, aber im Provider-Netz nicht priorisiert.
- Symptom: QoE-Probleme treten vor allem bei Congestion im Access/Metro/NNI auf; im Edge sieht „alles korrekt“ aus.
- Gegenmaßnahme: definierte Outer-DSCP-Policy pro Tunnelklasse (Voice/Video/Control/BE) plus Trust Boundary, damit Outer-Markierung nicht missbraucht wird.
Die gemeinsame QoS-Sprache: Klassenmodell für SD-WAN im Carrier-Netz
Ein schlankes, providerfähiges Klassenmodell ist die Basis für Interoperabilität zwischen SD-WAN und Telco-Underlay. Bewährt sind 4–5 Klassen:
- Voice Real-Time: Audio-Medien, sehr niedrige Latenz (LLQ mit Limit).
- Control/Signaling: SIP/ICE/DNS/Steuertraffic, hoch priorisiert gewichtet.
- Interactive Video: Video Calls/Meetings, gewichtet, bursttolerant.
- Best Effort: Standarddaten.
- Background (optional): Updates/Backups, klar niedriger priorisiert.
Dieses Modell muss sowohl im SD-WAN (App-ID/Policy) als auch im Underlay (DSCP/CoS/MPLS-TC) identisch interpretiert werden.
Trust Boundary im Telco-SD-WAN: Wer darf Premium markieren?
SD-WAN macht es technisch einfach, Traffic als „Premium“ zu markieren. Im Multi-Tenant-Providerbetrieb ist das gefährlich, wenn Kundenmarkierungen ungeprüft übernommen werden.
- Managed Edge: Wenn der Provider die SD-WAN-Edges managed, kann er Markierungen kontrolliert setzen und profilieren.
- Unmanaged Traffic: Wenn Kunden eigene Markierungen einspeisen, braucht es Whitelists und Conditional Trust.
- Budgetierung: Premiumklassen (Voice/Control) müssen pro Kunde begrenzt werden, sonst entsteht Premium-Inflation.
Eine robuste Regel lautet: Voice darf strikt priorisiert werden, aber nur innerhalb klarer Profile. Alles, was darüber hinausgeht, wird remarkt oder in eine niedrigere Klasse verschoben.
Shaping im SD-WAN: Der wichtigste QoS-Hebel am Edge
Viele Echtzeitprobleme in SD-WAN-Setups entstehen am WAN-Edge, weil dort der erste harte Engpass sitzt: Access-Raten, Providerprofile, LTE/5G-Variabilität oder CPE-Puffer. Shaping ist hier zentral:
- Egress-Shaping: knapp unter realer Linkrate, damit die Warteschlange kontrolliert im SD-WAN-Edge entsteht statt im Modem/ONT/Providerpolicer.
- Priorisierung innerhalb des Shapers: Voice in LLQ (mit Limit), Video gewichtet, BE fair.
- Uplink-Fokus: Upstream ist oft kritischer als Downstream; dort entstehen Bufferbloat und Jitterpeaks.
Im Telco-Kontext ist Shaping besonders wichtig, weil Access-Technologien und Profile stark variieren. Ein konsistentes Edge-Shaping stabilisiert QoE unabhängig vom Underlay.
Policing im SD-WAN-Overlay: Wann es sinnvoll ist und wann es schadet
Policer sind als Governance-Werkzeug nützlich, aber für Echtzeit riskant, weil sie hart droppen. Telco-SD-WAN sollte Policing gezielt einsetzen:
- Per-Customer Governance: Policer können Kundenprofile durchsetzen (CIR), solange Burstfenster realistisch sind.
- Echtzeit schützen: Voice sollte nicht so policet werden, dass Drops entstehen; besser sind LLQ-Limits und Trust-Regeln.
- Video vorsichtig: Überschuss eher remarken statt droppen, um Drop-Cluster und Freezes zu vermeiden.
Wenn Video trotz Priorisierung „friert“, sind Policer-Drops und zu kleine Burstfenster eine sehr häufige Ursache.
Pfadselektion und QoS: Latenzoptimierung kann Echtzeit verbessern – oder verschlechtern
SD-WAN steuert Pfade dynamisch anhand von Metriken wie Loss, Delay und Jitter. Das ist grundsätzlich positiv, kann aber Nebenwirkungen haben:
- Zu aggressives Switching: häufiges Umschalten erzeugt Reordering und Jitterspitzen.
- Grenzwert-Flapping: Pfade „wackeln“ um einen Schwellwert, SD-WAN pendelt zwischen Links.
- Stabilität vor Minimalwert: ein etwas langsamerer, aber stabiler Pfad ist für Voice oft besser als ein schneller Pfad mit Peaks.
Best Practice: Pfadwahl für Echtzeit sollte stabilitätsorientiert sein (Perzentile, Hysterese, Hold-Down-Timer) und mit QoS-Klassen gekoppelt werden (Voice strenger als Video, Video strenger als BE).
FEC, Duplizierung und Jitter-Buffer: Ergänzende Mechanismen richtig einordnen
Viele SD-WAN-Lösungen bieten Funktionen wie Forward Error Correction (FEC), Packet Replication oder Jitter Buffering. Diese können helfen, wenn sie richtig eingesetzt werden:
- FEC: kann bei leichtem Loss helfen, kostet aber zusätzliche Bandbreite und kann Latenz erhöhen.
- Duplizierung: erhöht Zuverlässigkeit, verdoppelt aber Traffic; im overbooked Access kann das sogar schaden.
- Jitter-Buffering: glättet Variabilität, erhöht aber End-to-End Delay.
Im Telco-Kontext gilt: Diese Funktionen sind Ergänzungen, kein Ersatz für saubere Underlay-QoS, Shaping und Kapazitätsdisziplin.
Underlay-Integration: MPLS/SR-Core und Internet Underlay unterschiedlich behandeln
Telco-SD-WAN läuft häufig über zwei Underlays: ein „Premium“-Underlay (MPLS/SR) und ein „Best Effort“-Underlay (Internet). QoS-Strategien müssen das reflektieren:
- MPLS/SR: QoS kann über MPLS-TC konsistent transportiert werden; klare DSCP↔TC Mappings und Queue-Profile sind Pflicht.
- Internet: DSCP wird häufig neutralisiert; hier wirken vor allem Edge-Shaping, Pfadselektion, FEC/Duplizierung und Headroom.
Eine bewährte Praxis ist, Voice primär über das qualitativ verifizierte Underlay zu führen und Internet-Paths als Backup mit klaren Erwartungen zu nutzen, statt „alles gleich“ zu behandeln.
NNI/Peering im SD-WAN-Providerbetrieb: Die unterschätzte Engpasszone
Wenn SD-WAN als Service erbracht wird, enden viele Pfade an NNI/Peering/Cloud-Edges. Dort entscheidet sich QoE häufig:
- Kapazität und Headroom: Peering-Ports dürfen nicht dauerhaft knapp gefahren werden.
- Trust konservativ: Inbound-Markierungen von außen sind meist untrusted.
- Telemetrie pro Klasse: Queueing Delay/Drops pro Klasse sind Pflicht, weil End-to-End sonst intransparent bleibt.
Viele „SD-WAN QoS“-Probleme sind in Wahrheit Interconnect-Probleme. Das muss das Betriebsmodell abbilden.
Monitoring und Verifikation: Wie Sie beweisen, dass Priorisierung über Overlay wirklich greift
SD-WAN bringt eigene Telemetrie mit, Telco-Underlays auch. Entscheidend ist, beide Welten zu korrelieren:
- Overlay-Sicht: Applikationsklassen, Tunnel-Klassen, Pfadmetriken (Loss/Delay/Jitter), Steering-Events, FEC/Replication-Status.
- Underlay-Sicht: DSCP/CoS/TC-Verteilungen, Classify-Hits, Queueing Delay 95/99, Drops pro Klasse, Shaper/Policer Events.
- Service-KPIs: MOS, RTP Jitter/Loss, Video Freeze/Bitrate Switching, Call Setup Times.
Ein besonders wirksamer Abnahmeschritt sind aktive Probes pro Klasse (EF/AF/BE) über die SD-WAN-Tunnel, kombiniert mit Underlay-Classify-Hits. Damit sehen Sie sofort, ob Outer-DSCP und Underlay-Queues korrekt greifen.
Typische Stolperfallen bei QoS in SD-WAN im Telco-Kontext
- Outer-DSCP fehlt: Underlay priorisiert nicht, Echtzeit leidet bei Congestion.
- Zu viele Klassen: Mapping-Drift, schwierige Verifikation, hohe Fehlerquote.
- Keine Trust Boundary: Premium-Inflation, LLQ wird groß, Voice wird schlechter.
- Kein Shaping am Edge: Bufferbloat, Jitterpeaks, MOS-Fall ohne Drops.
- Zu aggressives Steering: Reordering/Jitter durch häufiges Umschalten.
- Internet-QoS überschätzt: DSCP wird neutralisiert; Erwartungen müssen realistisch sein.
- Policer-Drops auf Video: Drop-Cluster und Freezes bei Bursts.
Praxis-Blueprint: Priorisierung über Overlay sauber umsetzen
- Schritt 1: Einheitliches Klassenmodell definieren (Voice, Control, Video, BE, optional Background) und als „gemeinsame Sprache“ festschreiben.
- Schritt 2: Trust Boundary festlegen (wer darf markieren), per-customer Budgets definieren, Premium-Inflation verhindern.
- Schritt 3: Inner/Outer Markierung designen: Outer-DSCP/TC pro Tunnelklasse setzen, Underlay-Mappings (DSCP↔CoS↔TC) standardisieren.
- Schritt 4: Edge-Shaping implementieren (insbesondere Upstream), LLQ für Voice mit Limit, Video gewichtet.
- Schritt 5: Pfadselektion stabilitätsorientiert konfigurieren (Hysterese, Hold-Down, Perzentile statt Momentwerte), Echtzeit strenger behandeln als BE.
- Schritt 6: Underlay-Policies pro Transporttyp unterscheiden (MPLS/SR vs. Internet), klare Erwartungen für Internet-Paths.
- Schritt 7: Abnahme durchführen: Probes pro Klasse, Classify-Hits, Queueing Delay/Drops, Steering-Events und Service-KPIs korrelieren.
- Schritt 8: Monitoring operationalisieren (Golden Signals): EF-Drops, Queueing Delay 95/99, DSCP-Verteilungen, Policer/Shaper Events, Pfadmetriken.
Häufige Fragen zur SD-WAN-QoS im Telco-Betrieb
Kann ich QoS über das Internet-Underlay garantieren?
In der Regel nicht end-to-end, weil DSCP außerhalb Ihrer Domäne oft neutralisiert wird. Sie können aber die QoE deutlich verbessern, indem Sie am Edge sauber shapen, Echtzeit korrekt priorisieren, Pfade stabilitätsorientiert auswählen und Funktionen wie FEC/Duplizierung gezielt einsetzen. Für echte Garantien brauchen Sie kontrollierte Underlays oder vertraglich abgestimmte Interconnects.
Was ist der wichtigste technische Schritt, damit Underlay-QoS bei SD-WAN überhaupt wirkt?
Die korrekte Outer-Header-Markierung (Outer-DSCP bzw. MPLS-TC) pro Tunnelklasse sowie konsistente Mappings im Underlay. Ohne Outer-Markierung sieht das Underlay den Echtzeitverkehr nicht – und jede Priorisierung bleibt auf das Edge-Gerät beschränkt.
Warum wird Voice manchmal schlechter, wenn SD-WAN aggressiv Pfade wechselt?
Weil häufiges Umschalten Reordering und Jitterspitzen erzeugt. Voice profitiert mehr von stabilen Perzentilen als von minimalen Momentwerten. Mit Hysterese, Hold-Down-Timern und stabilitätsorientierten Schwellen vermeiden Sie Flapping und schützen die Nutzerqualität.
