Eine durchdachte QoS-Architektur ist im Telco-Design der Unterschied zwischen „irgendwie priorisiert“ und einer stabilen, skalierbaren Servicequalität, die auch bei Lastspitzen, Failover-Szenarien und heterogenen Zugangsnetzen reproduzierbar bleibt. Das Hauptkeyword QoS-Architektur beschreibt dabei kein einzelnes Feature, sondern ein Zusammenspiel aus Marking, Queuing, Shaping und Policing – ergänzt um klare Trust Boundaries, konsistente Klassenmodelle und messbare Betriebskennzahlen. In Provider-Netzen treffen Millionen Flows auf wenige Engpässe, Kundenmarkierungen sind nicht automatisch vertrauenswürdig, und die Erwartungen an Echtzeitdienste wie VoIP, Videokonferenzen oder IPTV sind hoch. Wer QoS in diesem Umfeld sauber plant, denkt end-to-end: vom Access über Aggregation und Core bis zu Interconnect und Peering. Dieses Vorgehen verhindert typische Fehler wie unlimitierte Priority-Queues, inkonsistente DSCP-Mappings oder „QoS nur im Core“, und schafft eine Grundlage für SLAs, die nicht nur auf dem Papier existieren.
Grundlagen: Was eine QoS-Architektur im Telco-Design leisten muss
In Telekommunikationsnetzen ist QoS keine „Optimierung“, sondern eine Betriebsnotwendigkeit. QoS steuert, wie knappe Ressourcen bei Congestion verteilt werden. Eine funktionierende Architektur beantwortet vier Kernfragen: Welche Traffic Classes existieren? Wie wird Verkehr markiert und klassifiziert? Wie werden Warteschlangen priorisiert und fair bedient? Und wie werden Profile, Bandbreitenbudgets und Missbrauch technisch durchgesetzt?
- Konsistenz: Einheitliches Klassenmodell und identische Mappings über Plattformen und Domänen hinweg.
- Skalierbarkeit: Mechanismen müssen bei hoher Teilnehmerzahl und großem Routing-/Service-Scale funktionieren.
- Vorhersagbarkeit: Verhalten bei Congestion muss reproduzierbar sein (Queueing, Drops, Delay).
- Messbarkeit: Drops, Queue-Delay und Klassen-Auslastung müssen sichtbar und korrelierbar sein.
Das Klassenmodell: Wenige, klare Traffic Classes statt Wildwuchs
Viele QoS-Probleme entstehen durch zu viele Klassen, inkonsistente Benennung oder unklare Zweckdefinition. Im Telco-Design hat sich bewährt, mit einem schlanken Set zu arbeiten, das die wichtigsten Servicearten abdeckt. Jede Klasse braucht einen klaren Zweck, definierte Behandlung (Per-Hop Behavior) und idealerweise ein Bandbreitenbudget. So wird die QoS-Architektur operativ beherrschbar – auch über unterschiedliche Vendoren und Netzsegmente hinweg.
- Network Control: Routing-Protokolle, OAM, Timing/Sync, Management – muss zuverlässig laufen.
- Real-Time Voice: minimaler Jitter und Delay, geringe Bandbreite, strikt priorisiert und limitiert.
- Real-Time Video (interaktiv): niedrige Latenz, hohe Bandbreite, priorisiert aber fair.
- Business Critical Data: transaktionslastige Anwendungen, VDI, Remote-Work – bevorzugt, nicht strict priority.
- Assured/Streaming: IPTV/Streaming oder definierte Durchsatzklassen, geschützt vor Congestion.
- Best Effort: Standardverkehr.
- Scavenger/Bulk: Backups, Updates, große Transfers – bewusst nachrangig.
Warum „Strict Priority“ nur für sehr wenige Dinge geeignet ist
Strict Priority ist ein wirksames Werkzeug, aber in Provider-Umgebungen potenziell riskant. Wird eine Priority-Queue zu groß oder nicht limitiert, kann sie andere Klassen aushungern – etwa bei Fehlmarkierung, Missbrauch oder unerwarteter Last. Deshalb: Voice (und ggf. sehr kritische Signalisierung) in eine strikt priorisierte Queue, aber immer mit einer Obergrenze; Video und Daten in gewichtete Klassen.
Marking: DSCP, 802.1p/PCP und MPLS-TC sinnvoll einsetzen
Marking ist die Sprache, mit der Endpunkte und Netzkomponenten Serviceabsichten ausdrücken. Im IP-Umfeld ist DSCP der Standard. In Ethernet-Domänen kann 802.1p/PCP relevant sein, etwa im Provider-Access oder in Metro-Ethernet-Szenarien. In MPLS-Core-Netzen wird häufig über Traffic Class (TC/EXP) gearbeitet. Entscheidend ist die Übersetzung: DSCP↔PCP↔MPLS-TC muss konsistent sein, sonst entstehen „QoS-Löcher“, in denen Echtzeitverkehr plötzlich wie Best Effort behandelt wird.
- DSCP: Klassifizierung auf Layer 3, weit verbreitet und vendorübergreifend.
- PCP (CoS): Priorisierung auf Layer 2, relevant für Switch-Queues und Provider-Ethernet.
- MPLS-TC: Transportklasse im Core, muss sauber gemappt werden.
- Dokumentierte Mappings: Eine zentrale Tabelle verhindert Inkonsistenzen bei Rollouts und Migrationen.
Trust Boundaries: Wo Markierung akzeptiert wird – und wo nicht
In Telco-Netzen ist Kundenseite grundsätzlich nicht vertrauenswürdig, weil Markierungen frei gesetzt werden können. Deshalb definiert eine QoS-Architektur klare Trust Boundaries. An diesen Punkten wird entweder Markierung „vertraut“ (bei Managed Services) oder neu gesetzt/normalisiert (bei Internet-/Wholesale-Zugängen). Das ist essenziell, um Missbrauch zu verhindern und Bandbreitenbudgets pro Klasse einzuhalten.
- Managed Access: Trust kann am Access-Switch/CE gelten, wenn Endpunkte kontrolliert sind.
- Broadband/Wholesale: Trust typischerweise am BNG/PE nach Subscriber-Policy, nicht am Endgerät.
- Allowlist-Ansatz: Nur definierte DSCP-Werte akzeptieren; der Rest wird auf Best Effort gesetzt.
- Remarking: Unerlaubte oder überschreitende Flows werden in niedrigere Klassen ummarkiert.
Klassifizierung: Wie Pakete zuverlässig in die richtigen Klassen gelangen
Klassifizierung ist die praktische Umsetzung des Klassenmodells. Sie kann anhand von Marking erfolgen (DSCP/PCP), aber auch durch Policy-Regeln, die bestimmte Services identifizieren. In Provider-Netzen ist die bevorzugte Strategie oft: Marking als Primärsignal, ergänzt durch Service-/Subscriber-Kontext. Komplexe Deep-Packet-Inspection ist im Backbone nicht immer sinnvoll oder möglich – verschlüsselter Traffic, Skalierung und Betriebskosten setzen Grenzen.
- Marking-basiert: effizient und skalierbar, wenn Trust Boundaries sauber sind.
- Subscriber-/Service-Kontext: Klassenzuordnung über VLAN, VRF, Access-Profile oder Service-Instanz.
- Port-/Protokoll-Heuristik: nur ergänzend, da moderne Apps dynamische Ports und Verschlüsselung nutzen.
Queuing: Warteschlangen so designen, dass Echtzeit nicht leidet
Queuing ist der Kern von QoS, denn dort entscheidet sich das Verhalten bei Congestion. Eine Telco-taugliche QoS-Architektur definiert pro Interface/Richtung die Anzahl der Queues, deren Scheduler-Logik und die Queue-Limits. Ziel ist nicht „keine Drops“, sondern kontrollierte Drops und kontrollierte Verzögerung, abgestimmt auf die Dienstanforderungen.
- LLQ (Low Latency Queue): für Voice, strikt priorisiert, aber limitiert.
- CBWFQ/WFQ: gewichtete Bedienung für Video und wichtige Datenklassen.
- Queue Limits: länder- und netzweit konsistent, an Delay-/Jitter-Ziele angepasst.
- Isolation: Network Control darf nicht durch Datenverkehr verdrängt werden.
Mikrobursts und Bufferbloat: Zwei Seiten derselben Medaille
Mikrobursts füllen Queues in Millisekunden, besonders bei Aggregation vieler Flows. Zu kleine Puffer erzeugen Drops; zu große Puffer erzeugen Bufferbloat, also hohe und schwankende Latenz. Für Echtzeit ist Bufferbloat besonders schädlich. Eine robuste Architektur kombiniert daher sinnvolle Queue-Limits mit Shaping und – für TCP-dominante Klassen – Active Queue Management.
Shaping: Bursts glätten und Congestion kontrollierbar machen
Shaping verzögert Pakete bewusst, um den Abfluss auf eine Zielrate zu glätten. Das klingt kontraintuitiv, ist aber im Telco-Design oft entscheidend, weil es Drops reduziert und die Congestion-Entscheidung an einen kontrollierten Ort verlagert. Besonders wichtig ist Shaping am WAN-Edge oder an Übergängen zwischen schnelleren und langsameren Links. Ein bewährtes Prinzip: So formen, dass die Queue „bei dir“ liegt, nicht im unbekannten Teilnetz.
- Egress Shaping: Uplink knapp unter die vertragliche Rate setzen, um Provider-Queues zu vermeiden.
- Class-Based Shaping: Video-Spitzen glätten, ohne Voice zu beeinträchtigen.
- Parent/Child-Modelle: Parent-Shaper stabilisiert den Gesamtabfluss, Child-Queues priorisieren Klassen.
- Jitter-Management: Für Echtzeit ist planbares Queueing besser als unkontrollierte Drops.
Policing: Bandbreitenbudgets erzwingen und Missbrauch verhindern
Policing ist die harte Kontrolle: Überschreitungen werden verworfen oder ummarkiert. In Provider-Netzen ist Policing wichtig, um SLA-Profile pro Kunde/Serviceklasse umzusetzen und um zu verhindern, dass Kunden durch falsche Markierung Premium-Queues überlasten. Gleichzeitig ist Policing für Echtzeitverkehr riskant, wenn Budgets zu knapp sind: Jeder Drop wirkt sofort. Deshalb wird Policing häufig mit Remarking kombiniert und mit Shaping so abgestimmt, dass harte Drops minimiert werden.
- Ingress Policing: schützt das Netz vor übermäßigem Traffic und falschen Markierungen.
- Per-Class Policing: begrenzt Premium-Klassen (z. B. Voice) auf vertragliche Werte.
- Remarking statt Drop: Überschreitungen in niedrigere Klassen verschieben, um Qualitätseinbrüche zu reduzieren.
- Fairness: verhindert „Noisy Neighbor“ Effekte in Shared Access und Aggregation.
HQoS: Die Telco-Praxis für Access und Aggregation
Hierarchical QoS (HQoS) ist im Telco-Design häufig der entscheidende Baustein, um gleichzeitig pro Subscriber zu steuern und auf dem physikalischen Uplink stabile Klassenbehandlung zu garantieren. Ohne HQoS kollidieren Ziele: Ein Kunde kann in Summe den Uplink überlasten, obwohl einzelne Klassen korrekt priorisiert sind. Mit HQoS kann man pro Subscriber formen und innerhalb dieser geformten Rate Voice/Video priorisieren – während ein Parent-Shaper den Gesamtabfluss kontrolliert.
- Per-Subscriber Shaping: stabilisiert das Verhalten vieler Kunden auf gemeinsamen Links.
- Per-Service Queues: Voice/Video/Signaling innerhalb des Subscriber-Kontexts priorisieren.
- Parent Shaper: reduziert Mikroburst-Drops und macht Congestion planbarer.
End-to-end Konsistenz: Mappings und Übergänge sind die häufigsten Fehlerquellen
Eine QoS-Architektur scheitert oft nicht an fehlenden Mechanismen, sondern an Übergängen: LAN zu WAN, Metro-Ethernet zu IP, IP zu MPLS, Overlay zu Underlay oder Provider zu Provider. Typische Fehler sind uneinheitliche DSCP-Listen, unterschiedliche Vendor-Interpretationen, fehlende Copy-Mechanismen bei Tunneln oder eine falsche Annahme, welche Seite die Markierung setzt. Ein Telco-Design funktioniert dann zuverlässig, wenn Mappings und Trust-Boundaries dokumentiert, getestet und automatisiert ausgerollt werden.
- DSCP↔PCP↔TC: Mappingtabellen zentral pflegen und netzweit anwenden.
- Overlay/Underlay: Inner-to-Outer Marking korrekt übernehmen, damit Underlay-QoS greift.
- Interconnect: definierte Profile und realistische Erwartungen, weil vollständige Kontrolle endet.
Operativer Betrieb: QoS muss messbar und auditierbar sein
Provider-QoS ist kein „Set-and-Forget“. Traffic-Profile ändern sich, Codecs entwickeln sich weiter, Videoauflösungen steigen, und Routing-Pfade können durch Wartung oder Ausfälle wechseln. Deshalb gehört Telemetrie zur QoS-Architektur: Queue-Drops pro Klasse, Queue-Delay, Auslastung als Perzentile, sowie Korrelation mit Link- und Routing-Events. Nur so lässt sich nachweisen, ob eine Klasse ihr Ziel erreicht und wo Engpässe entstehen.
- Queue Drops: pro Klasse und Interface; Drops in Echtzeitklassen sind ein unmittelbares Alarmzeichen.
- Queue Delay: Frühindikator für Congestion und drohenden Jitter.
- Flow-Telemetrie: zeigt Marking-Nutzung und potenziellen Missbrauch.
- Active Probing: Latenz/Jitter/Loss zwischen Messpunkten pro Domäne sichtbar machen.
Typische Stolpersteine im Telco-QoS-Design
Bestimmte Fehlmuster tauchen in Provider-Projekten immer wieder auf. Sie lassen sich vermeiden, wenn man QoS als Architektur und nicht als Sammlung einzelner Regeln begreift. Besonders kritisch sind unlimitierte Priority-Queues, fehlendes Shaping am WAN-Edge, fehlende HQoS-Hierarchie im Access und inkonsistente Markings an Übergängen.
- Unlimitierte Priority-Queue: Voice/Video verdrängt andere Klassen bei Fehlmarkierung.
- QoS nur im Core: Congestion entsteht im Access/Aggregation, dort fehlt die Wirkung.
- Keine Queue-Visibility: Ohne Drops/Delay-Metriken bleibt Troubleshooting spekulativ.
- Zu viele Klassen: erhöht Komplexität, senkt Konsistenz, erschwert Automation und Tests.
- MTU/Fragmentierung: Tunneling/Overlays erzeugen Drops und Jitter, obwohl QoS korrekt erscheint.
Blueprint: QoS-Architektur im Telco-Design als wiederholbares Muster
Ein praxiserprobtes Muster beginnt mit einem schlanken Klassenmodell und einem verbindlichen Marking-/Mapping-Konzept. Danach werden Trust Boundaries definiert und Subscriber-/Serviceprofile erstellt, die Bandbreitenbudgets pro Klasse festlegen. Anschließend identifiziert man Congestion Points und implementiert dort Queuing und Shaping, idealerweise hierarchisch (HQoS). Policing wird gezielt eingesetzt, um Profile zu erzwingen und Missbrauch zu verhindern, vorzugsweise mit Remarking-Strategien, die harte Drops in Echtzeitklassen minimieren. Abschließend wird eine Telemetrie- und Teststrategie etabliert, die Last- und Failover-Szenarien abbildet und die QoS-Wirkung messbar macht. So entsteht eine QoS-Architektur, die nicht nur technisch sauber ist, sondern auch im Betrieb stabil bleibt und als Grundlage für SLA-fähige Services dienen kann.