QoS Engineering für Telcos ist die Disziplin, die technische Mechanismen wie Traffic Classes, Queueing, Shaping und Routing so zusammenführt, dass daraus verlässlich messbare SLAs entstehen. Im Carrier-Umfeld reicht es nicht, einzelne Anwendungen „zu priorisieren“: Ein Telekommunikationsnetz muss unter hoher Auslastung, bei Ausfällen und über viele Domänen hinweg reproduzierbare Servicequalität liefern. Genau hier liegt der Unterschied zwischen „QoS-Konfiguration“ und „QoS Engineering“: Es geht um ein durchgängiges Service-Modell, klare Verantwortungsgrenzen, nachvollziehbare Kapazitäts- und Policy-Entscheidungen sowie eine Telemetrie, die Qualität nicht nur vermutet, sondern belegt. Wer Voice, Video, VPN-Services oder Business-Connectivity mit SLA anbietet, braucht eindeutige Traffic-Klassen, eine konsistente Markierungsstrategie und KPIs, die direkt auf Kundenwahrnehmung und Vertragswerte einzahlen. Dieser Artikel zeigt, wie Telcos den Weg von Traffic Classes zu belastbaren SLAs strukturiert gestalten.
Was „messbares SLA“ im Telco-Kontext wirklich bedeutet
Ein SLA (Service Level Agreement) ist nur so gut wie seine Messbarkeit. Im Telco-Umfeld werden SLAs häufig in Kennzahlen wie Verfügbarkeit, Paketverlust, Latenz, Jitter, Durchsatz und Time-to-Restore definiert. Der zentrale Punkt: Diese Werte müssen technisch erfassbar, eindeutig interpretierbar und operativ steuerbar sein. Viele SLA-Fehlschläge entstehen nicht durch „schlechte Netze“, sondern durch unklare Definitionen: Wo beginnt und endet die Messstrecke? Welche Traffic-Klasse gilt? Werden Werte im Mittel, als Perzentil oder als Worst Case bewertet? Wird Wartungszeit ausgenommen? Und wie wird bei Multi-Domain-Services (z. B. mit Partnernetzen) abgerechnet?
- Messpunkt-Definition: Customer Edge bis Provider Edge, oder End-to-End bis zur Applikation?
- Statistik-Regeln: Mittelwert vs. 95. Perzentil vs. Maximum; Zeitfenster und Aggregation.
- Traffic Scope: Gilt das SLA für alle Pakete oder nur für bestimmte Serviceklassen?
- Fehlerbudget: Welche Toleranzen sind akzeptabel, bevor Vertragsverletzung vorliegt?
Von der Servicebeschreibung zur Traffic Class: Der Engineering-Workflow
Der Weg zu stabilen SLAs beginnt nicht im Router-CLI, sondern bei Servicekatalog und Produktdesign. Telcos sollten QoS als Bestandteil des Produktes modellieren: Welche Service-Varianten gibt es (z. B. Best Effort Internet, Business Internet, SIP-Trunk, IPTV, SD-WAN Underlay)? Welche Zielwerte sollen garantiert werden? Welche Netzsegmente sind beteiligt (Access, Aggregation, Core, Peering)? Aus diesen Antworten entsteht ein Klassenmodell, das bewusst klein, aber ausdrucksstark ist.
Ein praxistaugliches Klassenmodell (Beispiel)
- Network Control: Routing-Protokolle, OAM, Timing/Sync – höchste Schutzpriorität für Stabilität.
- Real-Time Voice: Sehr niedrige Latenz und Jitter, geringe Bandbreite, strikt limitiert.
- Real-Time Video (interaktiv): Niedrige Latenz, mehr Bandbreite, priorisiert aber kontrolliert.
- Business Critical Data: Transaktionssysteme, Remote-Work, VDI – bevorzugt, aber ohne strikte Prioritäts-Queue.
- Streaming/Assured: IPTV/Streaming oder definierte Durchsatzklassen, die vor Congestion geschützt werden.
- Best Effort: Standardverkehr.
- Scavenger/Bulk: Backup, Updates, große Downloads – bewusst nachrangig.
Wichtig ist, dass jede Klasse einen klaren Zweck, eine definierte Behandlung (Per-Hop Behavior) und eine messbare Zielsetzung hat. „Mehr Priorität“ ist keine Zielsetzung. Ziel ist: definierte Verzögerungs- und Verlustgrenzen unter definierten Lastbedingungen.
Markierung und Trust Boundary: DSCP, CoS und MPLS-TC sauber beherrschen
Traffic Classes leben von konsistenter Markierung. In IP-Netzen ist DSCP der zentrale Hebel, in Ethernet-Domänen oft 802.1p/PCP, und in MPLS-Core-Netzen wird die Traffic Class (TC/EXP) genutzt. QoS Engineering heißt hier: einheitliche Mappings und klare Trust Boundaries. Eine Telco kann Kundenseite nicht blind vertrauen, weil Markierungen manipuliert oder unabsichtlich falsch gesetzt werden. Deshalb werden Markierungen typischerweise an der Provider-Kante auf Basis von Subscriber-Profilen, VLAN/VRF-Zuordnung, Access-Policy oder Service-Instanz neu gesetzt oder verifiziert.
- Allowlist statt Wildwuchs: Nur definierte DSCP-Werte werden akzeptiert.
- Remarking: Unbekanntes oder missbräuchliches Marking wird auf Best Effort zurückgesetzt.
- Mapping-Tabellen: DSCP ↔ PCP ↔ MPLS-TC muss netzweit identisch sein.
- Dokumentation: Markierungsregeln gehören in Produkt- und Betriebsdokumente, nicht nur in Device-Templates.
Queueing und Scheduling: Dort entscheidet sich QoS – im Engpass
QoS zeigt Wirkung erst bei Congestion. Deshalb müssen Telcos Engpässe identifizieren und dort die Mechanismen präzise auslegen: Queueing, Scheduling, Pufferung und Congestion Management. Für Echtzeitdienste ist Low-Latency Scheduling (z. B. LLQ) relevant, für gemischte Lastprofile sind gewichtete Verfahren (WFQ/CBWFQ) und sinnvolle Queue-Limits entscheidend. Gleichzeitig gilt: Zu große Priority-Queues können andere Klassen aushungern; zu kleine Puffer erzeugen Drops bei Mikrobursts.
- LLQ (Low Latency Queue): Ideal für Voice, aber strikt bandbreitenlimitiert, um Missbrauch zu verhindern.
- CBWFQ/WFQ: Verlässliche Ressourcenanteile für Video und Business-Daten ohne absolute Dominanz.
- Queue Limits: So dimensionieren, dass Jitter und Delay kontrollierbar bleiben.
- AQM (z. B. WRED/ECN): Für TCP-lastige Klassen zur Vermeidung von Tail Drop und Bufferbloat.
Mikrobursts, Bufferbloat und die Realität moderner Aggregation
Carrier-Netze aggregieren viele Flows auf wenige Uplinks. Selbst bei moderaten Durchschnittswerten können Mikrobursts in Millisekunden Puffer füllen und Paketverlust auslösen. Umgekehrt kann zu viel Puffer zu Bufferbloat führen, also hoher, schwankender Verzögerung. QoS Engineering bedeutet, diesen Zielkonflikt bewusst zu managen: Shaping an Übergängen, realistische Queue-Limits, AQM für Best Effort und klare Prioritätsregeln für Echtzeitklassen.
Shaping und Policing: SLA-Profile technisch durchsetzen
SLAs sind immer auch Kapazitäts- und Fairnessverträge. Um sie durchzusetzen, braucht es Shaping und Policing. Shaping glättet Traffic auf eine definierte Rate und reduziert Drops, Policing begrenzt hart und schützt Ressourcen. In Telco-Designs wird häufig am Access/PE pro Subscriber oder pro Service geformt, während im Core eher effizientes Forwarding und robuste Queue-Modelle dominieren.
- Subscriber Shaping: Verhindert, dass einzelne Teilnehmer Aggregationsressourcen monopolieren.
- Service Policer: Erzwingt vertraglich zugesagte Profile pro Klasse (z. B. Voice maximal X kbit/s).
- Remarking statt Drop: Überschreitungen können in niedrigere Klassen ummarkiert werden.
- Hierarchie: Parent Shaper auf Interface + Child Policies je Klasse (HQoS) für Stabilität.
HQoS: Der Schlüssel im Access, wo SLAs gewonnen oder verloren werden
Viele SLA-Probleme entstehen nicht im Core, sondern im Access und in der Aggregation, wo die meisten Engpässe auftreten. Hierarchical QoS (HQoS) ist deshalb in Telco-Umgebungen unverzichtbar: Es erlaubt, gleichzeitig pro Kunde zu begrenzen und auf dem physikalischen Uplink eine konsistente Klassenbehandlung sicherzustellen. So lassen sich Produkte wie „Business Internet mit priorisiertem Voice“ technisch sauber abbilden, ohne dass einzelne Kunden das System aushebeln.
- Per-Subscriber Policy: Klassen innerhalb des Subscriber-Kontexts priorisieren (Voice vor Video vor Data).
- Per-Interface Parent: Gesamtrate formen, Mikrobursts Richtung Core reduzieren.
- Oversubscription kontrollieren: Best Effort darf überbucht sein, Echtzeitklassen nur innerhalb definierter Budgets.
QoS im MPLS- und Segment-Routing-Core: Klassen plus Pfadwahl
Im Core geht es nicht nur um Klassen, sondern auch um Pfadsteuerung. MPLS und Segment Routing bieten Möglichkeiten, Traffic Engineering (TE) umzusetzen, Engpässe zu umfahren und Ausfallszenarien kontrolliert zu gestalten. Für SLAs ist entscheidend, dass Failover-Pfade die QoS-Ziele weiterhin erreichen. Ein sauberer Engineering-Ansatz betrachtet Congestion Domains und bewertet, wie sich Routing-Events auf Delay, Jitter und Loss auswirken.
- TE-Policies: Kritische Services über weniger ausgelastete Pfade führen.
- Fast Reroute: Umschaltungen müssen getestet werden, inklusive Queue-Verhalten auf Backup-Links.
- Class-Aware Capacity: Kapazität pro Klasse planen, nicht nur „gesamt“.
- Consistent TC Handling: MPLS-TC und DSCP-Modelle domänenweit angleichen.
SLAs in KPIs übersetzen: Welche Metriken wirklich zählen
Die Übersetzung von Traffic Classes zu messbaren SLAs gelingt nur, wenn jede Klasse eigene, aussagekräftige KPIs besitzt. Für Voice sind Jitter und Paketverlust typischerweise relevanter als Durchsatz. Für Video hängt es vom Typ ab: interaktiv (Video-Calls) ist jitter- und latenzkritisch, Streaming ist eher throughput- und loss-sensitiv, solange die Puffer nicht reichen. Business-Daten benötigen oft konsistente Latenz und geringe Verlustraten, nicht unbedingt die höchste Peak-Bandbreite.
- Delay (One-Way oder RTT): Für Echtzeitklassen in engen Zeitfenstern bewerten.
- Jitter: Schwankungen sichtbar machen, nicht nur Durchschnittslatenz.
- Loss: Pro Klasse und pro Engpass; Drops auf LLQ sind ein Alarmsignal.
- Queue Delay: Direkter Indikator für Congestion und drohende Qualitätsprobleme.
- Availability: Nicht nur Link-Up/Down, sondern Service-Verfügbarkeit (inkl. Control Plane).
Mathematisch saubere Zielwerte: Perzentile statt Wunschzahlen
Im Betrieb ist es selten sinnvoll, SLAs am Maximalwert festzumachen, weil kurze Ausreißer unverhältnismäßig wirken. Praxistauglich sind Perzentile (z. B. 95. oder 99.) oder ein Fehlerbudget pro Monat. Dabei muss klar sein, ob die Messung pro Flow, pro Klasse oder pro Serviceinstanz aggregiert wird. Ein messbares SLA ist immer eine Kombination aus Messmethode, Auswertelogik und akzeptabler Abweichung.
Telemetrie und Monitoring: Ohne Daten kein Engineering
QoS Engineering verlangt eine Datenbasis, die sowohl Netz- als auch Serviceebene abdeckt. Klassische SNMP-Zähler sind hilfreich, reichen aber allein nicht aus, weil sie Peaks und Mikrobursts oft nur indirekt abbilden. Ergänzend sind Streaming Telemetry, Flow-Daten (z. B. IPFIX), synthetische Messungen und – wo möglich – anwendungsnahe Metriken sinnvoll. Entscheidend ist die Korrelation: SLA-Verletzungen müssen sich auf konkrete Ursachen zurückführen lassen (Engpass, Fehlmarkierung, Routing-Change, fehlerhafte Policy).
- Queue-Statistiken: Drops, Tail-Drops, ECN-Marks, Queue-Depth, Queue-Delay je Klasse.
- Interface-Metriken: Utilization als Perzentil/Peak, nicht nur Durchschnitt.
- Flow-Analysen: Wer erzeugt Lastspitzen, welche Klassen werden genutzt, stimmen Markierungen?
- Active Probing: Latenz/Jitter/Loss zwischen definierten Messpunkten pro Domäne.
Operations und Governance: Change-Management ist Teil des QoS
In Telco-Netzen scheitert QoS nicht selten an Betriebsrealität: Neue Services, neue Plattformen, unterschiedliche Vendor-Interpretationen und ungeplante Sonderfälle. Ein robustes QoS-Programm braucht Governance: Wer darf Klassen anlegen oder ändern? Wie werden neue Anwendungen klassifiziert? Wie werden Mappings netzweit ausgerollt? Wie werden Policies getestet, bevor sie live gehen? Das Ziel ist Wiederholbarkeit: Änderungen sollen reproduzierbar und rückrollbar sein, ohne die Servicequalität zu gefährden.
- Standardisierte Templates: Einheitliche Policy-Bausteine pro Plattform und Rolle (PE, P, Access, Aggregation).
- Kompatibilitätschecks: DSCP/TC-Mappings und Queueing-Verhalten vendorübergreifend validieren.
- Pre-Production Tests: Lasttests mit repräsentativen Traffic-Profilen, inklusive Failover.
- Policy Reviews: Regelmäßige Überprüfung von Klassen-Budgets und Missbrauchsmustern.
Typische Stolpersteine und wie man sie vermeidet
Viele Netze haben „QoS an“, aber keine stabilen SLAs. Häufige Ursachen sind inkonsistente Markierung, falsche Trust Boundaries, zu groß konfigurierte Priority-Queues oder der Irrglaube, QoS im Core reiche aus. Ebenso kritisch sind fehlende Messmethoden: Wenn Drops und Queue-Delay nicht sichtbar sind, bleibt die Ursachenanalyse spekulativ. QoS Engineering ist deshalb immer End-to-End und immer messgetrieben.
- LLQ ohne Limit: Führt bei Fehlmarkierung zu Verdrängung anderer Klassen.
- Zu viele Klassen: Erhöht Komplexität, senkt Konsistenz, erschwert Monitoring.
- Engpass falsch lokalisiert: QoS am falschen Ort wirkt nicht; Congestion entsteht oft im Access.
- Keine Congestion-Tests: QoS funktioniert nur unter Last; ohne Tests bleibt es Theorie.
- SLAs ohne Messlogik: Werte ohne klare Messstrecke sind nicht belastbar.
Blueprint: Von Traffic Classes zu SLA-fähigen Services in fünf Bausteinen
Ein bewährter Telco-Ansatz lässt sich in fünf Bausteine gliedern, die gemeinsam den Sprung von technischer QoS zu kommerziell nutzbaren SLAs ermöglichen. Erstens: ein konsistentes Klassenmodell mit klaren Per-Hop Behaviors. Zweitens: definierte Trust Boundaries und Mappings zwischen DSCP, Ethernet-CoS und MPLS/Segment-Routing-TC. Drittens: HQoS und Congestion-Management an realen Engpässen, insbesondere im Access und in der Aggregation. Viertens: Kapazitätsplanung pro Klasse inklusive Failover-Headroom. Fünftens: Telemetrie, die Queue-Verhalten, Path-Events und Service-KPIs korreliert und damit SLA-Nachweise ermöglicht. In der Kombination entsteht ein QoS Engineering, das nicht nur „best effort plus Priorität“ ist, sondern ein steuerbares, auditierbares Serviceversprechen.