Multi-Tenant QoS ist im Carrier-Netz die Königsdisziplin, weil hier nicht „ein Unternehmen“ priorisiert wird, sondern viele Kunden gleichzeitig – mit unterschiedlichen Produkten, SLAs und Traffic-Profilen – auf derselben Infrastruktur. Genau dabei entstehen die typischen Provider-Probleme: Ein „lauter“ Kunde (Noisy Neighbor) erzeugt Bursts und drückt Aggregationslinks in Congestion, während andere Kunden über schlechte Voice-Qualität oder ruckelnde Videokonferenzen klagen. Oder Premium-Klassen verwässern, weil Markierungen blind vertraut werden und plötzlich zu viel Traffic als EF/AF läuft. Multi-Tenant QoS löst diese Konflikte, indem es QoS pro Kunde durchsetzt: Jeder Kunde erhält ein definiertes Gesamtbudget (CIR/PIR), innerhalb dessen wiederum Serviceklassen wie Voice, Video, Business und Best Effort sauber getrennt und geschützt werden. Technisch basiert das auf Trust Boundaries an der Netzgrenze, Profilierung (Policing/Remarking), Shaping an Engpässen, konsistentem DiffServ-Klassenmapping und – in reifen Netzen – hierarchischem QoS (HQoS), das Kundenfairness und Klassenpriorisierung miteinander kombiniert. Dieser Artikel erklärt praxisnah, wie Sie QoS pro Kunde im Carrier-Netz durchsetzen, welche Architekturbausteine Sie benötigen, wo die häufigsten Fehler liegen und wie Sie Multi-Tenant QoS so operationalisieren, dass SLAs messbar bleiben und Echtzeittraffic auch unter Last stabil funktioniert.
Warum „klassisches QoS“ ohne Kundendurchsetzung nicht reicht
Viele QoS-Designs starten mit einem globalen Klassenmodell: EF für Voice, AF für Video, Best Effort für den Rest. Das ist notwendig, aber im Multi-Tenant-Betrieb nicht ausreichend. Denn ohne Kundendurchsetzung kann ein einzelner Kunde:
- Premium-Klassen aufblasen: zu viel Traffic in EF/AF senden (absichtlich oder durch Fehlkonfiguration).
- Engpässe dominieren: große Datenflüsse erzeugen Bufferbloat und Microbursts, die auch andere Kunden treffen.
- Fairness aushebeln: Best Effort anderer Kunden leidet, obwohl diese „nichts falsch machen“.
Das Ergebnis ist eine QoS-Inflation: Premium verliert Wert, Best Effort wird unzuverlässig, und Störungen werden schwer nachvollziehbar, weil die Ursache in einem einzelnen Tenant steckt, die Wirkung aber viele betrifft.
Multi-Tenant QoS: Was „pro Kunde“ im Provider-Netz bedeutet
„QoS pro Kunde“ heißt im Carrier-Kontext nicht nur, dass jeder Kunde eine eigene VRF oder ein eigenes VLAN hat. Es bedeutet, dass der Provider pro Kunde definierte Ressourcen zusichert und durchsetzt:
- Gesamtprofil: maximale und ggf. garantierte Bandbreite pro Kunde (z. B. CIR/PIR oder ein Serviceprofil).
- Klassenprofil: innerhalb des Kundenprofils getrennte Budgets für Voice, Video, Business und Best Effort.
- Schutzmechanismen: Missmarkierung wird abgefangen (Trust Boundary), Überschuss wird remarkt oder begrenzt.
Damit wird QoS von „Netzpriorisierung“ zu „Kundenprodukt“: Sie können fair liefern, messen und im Incident-Fall eindeutig zuordnen.
Grundbaustein 1: Trust Boundary und QoS-Remarking am UNI
Am Kundenübergang (UNI) entscheidet sich, ob Multi-Tenant QoS stabil bleibt. Ohne Trust Boundary können Kundenmarkierungen das Provider-Netz beeinflussen. In Multi-Tenant-Designs ist daher Remarking nahezu immer Pflicht:
- Untrusted: Kundenmarkierungen werden neutralisiert; Premium nur über managed Mechanismen.
- Conditional Trust: Markierungen werden akzeptiert, aber nur innerhalb definierter Profile; Überschuss wird remarkt.
- Trusted: nur bei streng kontrollierten Quellen (Managed CPE, Provider-Voice-Gateway, Wholesale-Vertrag mit klarer Governance).
Das Ziel ist ein kleines Provider-Klassenmodell, das netzweit gilt. Kundenmarkierungen werden darauf normalisiert, damit Ihre Core-/Metro-Templates nicht explodieren.
Grundbaustein 2: Profilierung pro Kunde – ohne Echtzeit zu zerstören
Multi-Tenant QoS braucht Profile. Diese Profile sollen Fairness schaffen, dürfen aber Echtzeit nicht kaputt machen. In der Praxis kommen drei Mechanismen vor:
- Policing: setzt harte Grenzen; gut als Schutz gegen Missbrauch, aber Drops sind für Voice kritisch.
- Remarking: Überschuss wird in eine niedrigere Klasse oder höhere Drop-Precedence gesetzt; für Video sehr wirkungsvoll.
- Shaping: glättet Bursts am Egress; reduziert Drop-Cluster und stabilisiert Jitter, besonders an rate-limitierten Links.
Eine bewährte Provider-Regel lautet: Policing am Ingress zur Governance, Shaping am Egress zur Stabilität. Voice wird so dimensioniert, dass es praktisch nie durch Policing gedroppt wird.
Grundbaustein 3: Klassenmodell innerhalb des Kundenprofils
QoS pro Kunde bedeutet nicht „ein Topf“. Innerhalb des Kundenbudgets müssen die Serviceklassen getrennt bleiben, sonst verdrängt Video oder Best Effort die Sprache. Ein praxistaugliches Modell für Multi-Tenant-Services umfasst meist:
- Voice Media (EF): Low Latency / LLQ, strict priority mit Limit.
- Signaling/Control: hoch priorisiert, aber gewichtet.
- Interaktives Video (AF): gewichtet mit garantierten Anteilen, keine strict priority.
- Best Effort: fair, kontrollierte Puffer gegen Bufferbloat.
- Background: niedrig priorisiert.
Das ist bewusst kompakt. Multi-Tenant QoS wird schnell zu komplex, wenn pro Kunde viele Sonderklassen entstehen. Besser sind wenige Klassen mit klaren Bedeutungen und sauberer Profilierung.
Hierarchisches QoS (HQoS): Der klassische Weg zu „pro Kunde“ plus „pro Klasse“
HQoS ist in vielen Carrier-Netzen das zentrale Werkzeug, um Multi-Tenancy technisch sauber abzubilden. Die Idee: Sie bauen eine Hierarchie aus Policern/Shapern und Klassen-Queues.
- Eltern-Ebene: Gesamt-Shaper pro Kunde/Service-Instance (z. B. EVC, Pseudowire, VRF, Subinterface).
- Kinder-Ebene: innerhalb des Kunden-Shapers werden Klassen (Voice, Video, BE) separat gequeued und geschedult.
So erreichen Sie zwei Ziele gleichzeitig: Kein Kunde kann das Gesamtinterface dominieren, und innerhalb des Kunden bleibt Voice vor Video geschützt. HQoS ist besonders wertvoll in Metro-Aggregation, Business-Ethernet, Wholesale und Mobile Backhaul Aggregation.
HQoS in der Praxis: Welche Ebenen sich bewähren
Ein pragmatisches, betriebssicheres HQoS-Design arbeitet häufig mit zwei Ebenen. Mehr Ebenen sind möglich, erhöhen aber Komplexität.
- 2-Level HQoS: Kunde (Shaper) → Klassen (Queues/Scheduler).
- 3-Level HQoS: Kunde → Service (z. B. Voice vs. Data) → Klassen (selten nötig, eher in sehr großen Wholesale-Umgebungen).
In vielen Netzen ist 2-Level HQoS der Sweet Spot: genug Kontrolle, ohne dass Konfiguration und Telemetrie explodieren.
Microbursts und Bursthandling: Warum Multi-Tenant QoS ohne Shaping oft kippt
Multi-Tenant-Aggregation erzeugt Microbursts: Viele Kunden senden gleichzeitig, und kurzfristig übersteigt das die Uplinkrate. Ohne Shaping und passende Queue-Limits entstehen Drop-Cluster, die besonders Echtzeit schädigen.
- Shaping am Aggregations-Uplink: glättet Bursts, reduziert Drop-Cluster.
- Per-Class Queue-Limits: Voice-Queue klein und schnell, Video moderat, Best Effort kontrolliert.
- WRED/Drop-Precedence für Video: Überschuss-Video kann früher droppen, Kernvideo bleibt stabil.
Die Konsequenz: Multi-Tenant QoS ist nicht nur „pro Kunde policen“, sondern „pro Kunde stabilisieren“, damit Bursts nicht die QoE aller Kunden beschädigen.
Multi-Tenant QoS im MPLS/SR-Core: Kundenlogik am Rand, Klassenlogik im Core
Im IP/MPLS- oder SR-Core ist per-Kunden-HQoS nicht immer sinnvoll oder möglich, weil der Core skalieren muss. Das übliche Muster ist:
- Am PE/Edge: Trust Boundary, Remarking, Profilierung pro Kunde, ggf. HQoS.
- Im Core: Transport nach Klassen (MPLS-TC/EXP), konsistente Queue-Templates.
- Am Egress-PE: ggf. Restore/Remarking für Übergaben.
So bleibt der Core einfach und schnell, während die Multi-Tenant-Fairness an den Punkten passiert, an denen Kundenverkehr zusammengeführt wird.
Multi-Tenant QoS in EVPN/VXLAN und Telco Clouds
In Fabrics und Clouds ist Multi-Tenancy besonders präsent. Hier verschiebt sich „Kunde“ oft zu „Tenant/VRF/Namespace“. Die Prinzipien bleiben identisch:
- Trust Boundary am Ingress: nicht jeder Tenant darf Premium markieren.
- DSCP Propagation: innerer/äußerer Header muss konsistent sein, sonst wirkt QoS im Underlay nicht.
- Profilierung pro Tenant: Policer/Remarking/Shaping pro VRF/VNI/Namespace, je nach Plattform.
Besonders wichtig ist hier Monitoring: Noisy Neighbors erkennt man eher an Queue-Depth, Drops und CPU-/Datapath-Last als an Durchschnittsauslastung.
Typische Fehler bei QoS pro Kunde – und wie sie sich zeigen
- Blindes Trust von Kunden-DSCP: EF/AF explodiert, LLQ wird überfüllt, Best Effort kollabiert.
- Nur Gesamtprofil, keine Klassen: Video verdrängt Voice innerhalb des Kunden, Voice knackt trotz „Premium“.
- Policing mit Drops auf Echtzeit: Voice-Aussetzer durch Drop-Cluster, besonders bei Bursts.
- Kein Shaping an Engpässen: Microbursts erzeugen sporadische QoE-Probleme, schwer reproduzierbar.
- Inkonsequentes Mapping: DSCP → CoS → MPLS-TC passt nicht, QoS-Löcher entstehen.
- Fehlendes Monitoring pro Kunde: Noisy Neighbor bleibt unsichtbar, bis mehrere Kunden betroffen sind.
Monitoring und Nachweis: Multi-Tenant QoS operativ beherrschen
QoS pro Kunde ist nur dann erfolgreich, wenn Sie pro Kunde und pro Klasse messen können. Sinnvolle KPIs sind:
- Traffic pro Kunde und pro Klasse: Volumen, Peaks, Premium-Anteile.
- Policer-Hits und Remarking: zeigt Profilüberschreitungen und Missmarkierung.
- Queue-Drops pro Klasse: Drops in Voice sind kritisch; Video-Drops deuten auf Gewichte/Bursts hin.
- Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitter-Risiko.
- QoE-KPIs: MOS/R-Faktor, Audio-Interruptions, Video-Freeze-Events (bei managed Services).
Ein praxistauglicher Betriebsstandard ist: Drops in der Voice-Klasse sind ein Incident – und Profilüberschreitungen sind ein Kunden-/Produktthema, nicht nur ein Netzthema.
Praxis-Blueprint: QoS pro Kunde im Carrier-Netz durchsetzen
- Klassenmodell standardisieren: wenige Klassen mit klarer Bedeutung (Voice EF, Video AF, Control, BE, Background).
- Trust Boundary definieren: untrusted/conditional/trusted je Produktsegment; Kundenmarkierungen normalisieren.
- Kundenprofile festlegen: Gesamtbudget (CIR/PIR) und Klassenbudgets innerhalb des Kunden.
- HQoS einsetzen, wo Aggregation passiert: Kunde als Parent-Shaper, Klassen als Child-Queues.
- Shaping an Engpässen: Microbursts glätten, Drop-Cluster reduzieren, besonders Metro/Backhaul.
- Remarking statt Drop: Überschuss bei Video herabstufen (Drop-Precedence), Voice möglichst nicht droppen.
- End-to-End Mapping sichern: DSCP/CoS/MPLS-TC konsistent über alle Domänen.
- Monitoring pro Kunde operationalisieren: Dashboards und Alarme für Premium-Inflation, Policer-Hits, Queue-Drops.
Häufige Fragen zu Multi-Tenant QoS
Ist HQoS zwingend notwendig?
Nicht immer, aber in vielen Aggregations- und Wholesale-Szenarien der sauberste Weg. Wenn Sie pro Kunde sowohl ein Gesamtlimit als auch Klassenprioritäten garantieren müssen, ist HQoS oft die stabilste Architektur.
Wie verhindere ich, dass ein Kunde Premium missbraucht?
Durch Trust Boundary und Profilierung: Markierungen nur conditional trusten, zulässige DSCP-Werte normalisieren, Premium-Budgets pro Klasse durchsetzen und Überschuss remarken. Zusätzlich hilft Monitoring: Wenn EF/AF-Anteile bei einem Kunden unplausibel steigen, ist das ein Alarmzeichen.
Was ist der wichtigste Erfolgsfaktor für stabile Voice-Qualität im Multi-Tenant-Netz?
Voice in einer echten Low-Latency-Queue (EF) mit Limit, geschützt durch Trust Boundary und realistische Kundenprofile – plus Shaping an Engpässen gegen Microbursts. Wenn Drops in der Voice-Klasse praktisch nicht auftreten, bleibt Sprachqualität auch dann stabil, wenn andere Kunden große Datenlast erzeugen.
