Das Blueprint „Core QoS“ beschreibt, wie Sie Quality of Service im Backbone/Core so designen, dass sie skalierbar bleibt und in Kombination mit class-aware Traffic Engineering (TE) echte Servicequalität liefert – ohne dass Ihr Netz in einem unwartbaren Regelwald endet. In vielen Umgebungen wird QoS primär am Edge gedacht: WAN-Shaping, Voice-Queues, WLAN-WMM. Das ist richtig, weil Engpässe oft am Rand entstehen. Dennoch entscheidet der Core über zwei Dinge, die für Carrier-Grade QoE unverzichtbar sind: Erstens über Pfade und Ausweichrouten (TE, FRR, ECMP), die Latenz, Jitter und Congestion-Verteilung bestimmen. Zweitens über eine konsistente, skalierbare Behandlung von Klassen über große Domänen hinweg (DSCP/PHB, MPLS TC/EXP, SR/TE Policies), damit Markierungen nicht „driften“ und QoS bei Failover oder Lastverschiebung nicht zusammenbricht. Ein Core QoS Blueprint fokussiert daher auf wenige, robuste Klassen, standardisierte Mapping-Tabellen, class-aware TE-Mechaniken und eine Observability, die die Wirkung im Core belegt. Dieser Artikel zeigt, wie Sie Core QoS aufbauen: Welche TE-Ansätze class-aware funktionieren, wo Queueing im Core wirklich relevant ist, wie Sie Policies skalieren und wie Sie den Betrieb so gestalten, dass QoS im Core nicht nur theoretisch, sondern praktisch stabil und auditierbar ist.
Warum QoS im Core anders ist als am Edge
Am Edge ist QoS meist „Engpassmanagement“: Shaping, Queueing, harte Konkurrenz zwischen Echtzeit und Bulk. Im Core/Backbone sind Links häufig hochdimensioniert, und Congestion ist seltener – aber nicht ausgeschlossen. Der Core ist eher ein „Pfad- und Konsistenzproblem“: Wenn Traffic Engineering Pfade verschiebt, muss die QoS-Semantik gleich bleiben. Wenn FRR/Fast Reroute greift, darf Voice nicht plötzlich über einen Pfad laufen, dessen Queueing-Profile oder Mapping anders sind. Core QoS ist daher weniger „viele Policers“, sondern „wenige Klassen, saubere Mappings, konsistente Queue-Profile und TE, das Klassen respektiert“.
- Edge: Congestion regelmäßig, Shaping ist Pflicht, QoS schützt Echtzeit vor Bulk.
- Core: Congestion selten, aber Pfadwechsel häufig; Konsistenz und TE-Intent sind entscheidend.
- Skalierung: Policies müssen über viele Knoten/Interfaces ausrollbar sein, ohne Drift.
- Fehlerbild: „QoS greift nicht“ im Core ist oft Mapping-/TE-/Failover-getrieben.
Core QoS Zielbild: Drei Säulen für Skalierbarkeit
Ein Core QoS Blueprint lässt sich auf drei Säulen reduzieren: (1) ein stabiles Klassenmodell mit klarer DSCP/MPLS-TC Semantik, (2) class-aware TE, das Pfade pro Klasse steuern kann und Failover kontrolliert, (3) standardisierte Policies/Queue-Profile, die sich automatisiert ausrollen und auditieren lassen. Wenn eine Säule fehlt, wird Core QoS entweder wirkungslos oder unzuverlässig.
- Klassenmodell: wenige Klassen, die überall gleich interpretiert werden.
- TE mit Klassenbezug: Pfade für Echtzeit anders bewerten als Pfade für Bulk.
- Operative Skalierung: Templates, Naming, Compliance Checks und Telemetry als Standard.
Klassenmodell im Core: Weniger ist mehr
Im Core ist es selten sinnvoll, viele feine Klassen zu betreiben. Jede zusätzliche Klasse erhöht Mapping-Aufwand, Queue-Komplexität, Testumfang und Drift-Risiko. Bewährt haben sich 4–6 Klassen, die die meisten Service-Intents abdecken: Low-Latency/Voice, Media/Video, Control/Signal, Critical Data, Best Effort, Bulk. Wichtig ist, dass diese Klassen sowohl in IP (DSCP) als auch in MPLS/SR (Traffic Class) konsistent abgebildet sind, inklusive Interworking an Domain-Grenzen.
- LOW_LATENCY/VOICE: streng priorisiert, begrenzt, kleine Buffers für niedrigen Delay.
- MEDIA: hohe Priorität, aber limitiert; schützt Video ohne Voice zu verdrängen.
- SIGNAL/CONTROL: Routing-, Timing- und Service-Steuerung, damit das Netz unter Last stabil bleibt.
- CRITICAL: bevorzugte Daten (z. B. Business-Critical), aber nicht strict.
- BESTEFFORT: Standard.
- BULK: niedrig priorisiert, „opferbar“.
DSCP ↔ MPLS TC ↔ CoS: Das Interworking ist im Core eine Compliance-Pflicht
Core-Netze bestehen häufig aus mehreren Technologien: IP, MPLS, Segment Routing, EVPN, Metro-Ethernet-Abschnitte. QoS bricht hier typischerweise nicht an der Queue selbst, sondern am Interworking: Ein DSCP wird auf einem PE korrekt gesetzt, aber im MPLS-Core in eine andere Traffic Class gemappt; oder CoS an einem Ethernet-Hand-off wird anders interpretiert. Ein Core QoS Blueprint fordert daher eine zentrale Mapping-Matrix (Source of Truth), die für alle Plattformen gilt, und automatisierte Drift-Checks, die Abweichungen erkennen.
- Mapping-Matrix: DSCP ↔ MPLS TC ↔ CoS als zentral versioniertes Artefakt.
- Trust Boundary: Markierungen nur dort trusted, wo sie kontrolliert sind; sonst normalisieren.
- Drift Checks: automatisierte Prüfungen der Mapping-Tabellen auf allen Core-Knoten.
Class-aware TE: Was es bedeutet und warum es QoS ergänzt
QoS entscheidet, wie Pakete behandelt werden, wenn sie um Ressourcen konkurrieren. Traffic Engineering entscheidet, wo sie langlaufen und welche Ressourcen sie überhaupt teilen. Class-aware TE verbindet beides: Es erlaubt, für unterschiedliche Traffic-Klassen unterschiedliche Pfadpräferenzen zu definieren. Das ist besonders relevant, wenn Sie mehrere parallel nutzbare Pfade haben (ECMP, SR-Policies, MPLS-TE, SDN-Controller) oder wenn Failover-Fälle auftreten.
- Echtzeit-Pfade: bevorzugen niedrige Latenz und geringe Jitter-Varianz, auch wenn die Auslastung moderat ist.
- Bulk-Pfade: können längere/„günstigere“ Pfade nutzen und tragen Congestion eher.
- Isolierung: TE kann verhindern, dass Bulk und Echtzeit denselben Engpass dominieren.
TE-Patterns im Core: Von ECMP bis Segment Routing Policies
Ein Core QoS Blueprint sollte mehrere TE-Patterns unterstützen, weil Netze unterschiedlich reif sind. Entscheidend ist nicht das Buzzword, sondern die Fähigkeit, Pfade kontrolliert zu wählen und Failover vorhersehbar zu machen. In der Praxis gibt es drei häufige Stufen: ECMP-basierte Lastverteilung, explizites TE (z. B. MPLS-TE oder SR-TE) und controllerbasiertes/intentbasiertes TE.
- Pattern A (ECMP + QoS): mehrere gleichwertige Pfade, Hashing verteilt Flows; QoS schützt Klassen lokal. Risiko: Pfade sind nicht klassenbewusst, Echtzeit kann ungünstig landen.
- Pattern B (SR-Policies/MPLS-TE): explizite Pfade für bestimmte Traffic-Klassen oder Services, mit kontrollierter Failover-Logik.
- Pattern C (Controller/Intent TE): zentrale Optimierung anhand Metriken, SLOs und Kapazität; class-aware Constraints möglich.
Class-aware TE praktisch umsetzen: Constraints statt „ein Pfad für alles“
Die Kernidee ist, TE-Entscheidungen nicht nur anhand von Bandbreite oder IGP-Metrik zu treffen, sondern anhand klassenrelevanter Kriterien. Das bedeutet: Sie definieren pro Klasse SLO-nahe Anforderungen (maximale RTT/Latency, Jitter-Sensitivität, Loss-Toleranz) und übersetzen diese in TE-Constraints. Beispiel: Echtzeit darf nicht über Links laufen, die regelmäßig Queue Delay Peaks zeigen, während Bulk diese Links nutzen darf. So wird TE zu einem QoS-Verstärker.
- Latency-Aware Routing: Echtzeit bevorzugt niedrige RTT/Latency-Pfade.
- Congestion-Avoidance: Echtzeit meidet Links mit hoher Queue Delay 99p oder hoher Drop-Rate.
- Capacity Reservations: für bestimmte Services/Klassen reservierte Kapazität oder definierte Headroom-Regeln.
- Failure-Mode Awareness: auch im FRR-Fall müssen Echtzeitpfade akzeptable SLOs halten.
FRR und Schutzumschaltung: QoS muss im Failover identisch bleiben
Core-Netze sind auf schnelle Wiederherstellung ausgelegt. FRR kann Traffic in Millisekunden umleiten, aber QoS kann dabei „mit umgeleitet“ werden oder „verloren gehen“, je nachdem, ob Mappings und Queue-Profile konsistent sind. Ein Blueprint fordert daher: gleiche DSCP/TC-Semantik auf allen Links, gleiche Queue-Profile auf allen möglichen FRR-Next-Hops, und Tests, die den Failure-Mode explizit validieren.
- Symmetrische Queue-Profile: alle Links, die als Schutzpfad dienen können, müssen dieselbe Klassenbehandlung haben.
- Failure-Mode Tests: kontrollierte Link-/Node-Failures und Messung von Queue Delay/Drops in Echtzeitklassen.
- Guardrails: Voice/Low-Latency Drops und Delay 99p dürfen im Failover nicht steigen.
Skalierbare Policies: Wie Sie QoS im Core ausrollbar halten
Im Core skaliert QoS nicht über individuelle Interface-Konfiguration, sondern über Templates, Rollen und Automatisierung. Ein Blueprint definiert deshalb Rollen (Core Transit, PE/Edge, Interconnect, Metro-Edge) und hält pro Rolle ein standardisiertes QoS-Profil bereit. Naming ist dabei nicht kosmetisch: Es ermöglicht, Telemetry und Counter Reports zu normalisieren, sodass Dashboards und Alerts herstellerübergreifend funktionieren. Zusätzlich sollten Compliance Checks regelmäßig laufen: Policy Attachment, Mapping-Konsistenz, Guardrails (keine Policers auf Echtzeit, keine unlimitierten Priority-Queues).
- Rollen-Templates: Transit-Profile vs. Edge-Profile vs. Interconnect-Profile.
- Standard-Naming: Klassen- und Policy-Namen konsistent, damit Betrieb und Audit funktionieren.
- Compliance Automation: Attachment/Mappings/Guardrails als regelmäßige Checks.
- Versionierung: V1/V2-Profile für kontrollierte Migration und schnellen Rollback.
Queueing im Core: Wann es relevant ist und wie Sie es richtig dimensionieren
Viele Core-Netze sind so dimensioniert, dass Congestion selten ist. Dennoch gibt es Situationen, in denen Queueing im Core relevant wird: DDoS-/Anomalieereignisse, Traffic Shifts nach Failover, temporäre Kapazitätsengpässe, Interconnect-Sättigung oder starke Ost-West-Ströme in regionalen Fabrics. In diesen Fällen muss das Queueing-Verhalten vorhersehbar sein. Das Blueprint setzt daher auf moderate Buffer-Profile, kleine Echtzeit-Buffers (gegen Bufferbloat) und klare Drop-Strategien für BE/Bulk. Wichtig ist, dass Echtzeit nicht über Policers „hart“ begrenzt wird, weil das Loss-Spikes erzeugt.
- Small Buffers for Low Latency: Echtzeitklassen mit kleinen Buffern, um Delay zu begrenzen.
- BE/Bulk Drop Strategy: Best Effort/Bulk darf Dropping tragen; Echtzeit sollte geschützt sein.
- Avoid Policer on Voice: Policers erzeugen harte Loss-Spikes; Shaping und Scheduling sind meist besser.
Observability im Core: KPIs, die TE und QoS zusammenbringen
Core QoS lässt sich nicht nur über „Policy Counters“ beweisen. Sie müssen TE-Wirkung und QoS-Wirkung zusammendenken: Welche Klassen laufen über welche Pfade? Wo entstehen Queue Delay Peaks? Welche Links sind für Echtzeit kritisch? Ein gutes Monitoring normalisiert daher KPIs über Knoten hinweg: Queue Delay/Depth pro Klasse, Per-Class Drops, Drop Reasons, Link Headroom sowie TE-/Path-Ansichten, die zeigen, welche Policies welche Links nutzen. Besonders wichtig sind Perzentile, weil Echtzeit an Peaks scheitert.
- Queue Delay 99p: LOW_LATENCY/VOICE und MEDIA auf kritischen Core-Links und Interconnects.
- Per-Class Drops: Drops in Echtzeitklassen sind Incident-Signal; Gründe bestimmen Maßnahmen.
- Drop Reasons: Tail Drop vs. Buffer Exhaustion vs. Policer (als Warnsignal).
- Path/TE Visibility: welche Klassen nutzen welche Pfade; Drift nach Failover sichtbar machen.
- Headroom: Kapazitätsrisiken früh erkennen, bevor TE in „schlechte Pfade“ gezwungen wird.
Validation: Core QoS und class-aware TE vor dem Rollout beweisen
Ein Blueprint ohne Tests ist ein Risiko. Für Core QoS sind drei Testarten besonders wertvoll: (1) Mapping-Tests (DSCP↔TC↔CoS konsistent), (2) Congestion-Proof an definierten Engpässen oder im Lab, (3) Failure-Mode Tests (FRR/Link-Failures) mit QoS-KPIs. Ergänzend sind Canary Rollouts sinnvoll: erst ein Segment, dann Wellen. Guardrails definieren, wann zurückgerollt wird.
- Mapping Regression: DSCP/TC/CoS Zuordnung prüfen, Default/Unmatched Drift verhindern.
- Congestion Proof: unter kontrollierter Last bleibt Echtzeit stabil, BE/Bulk trägt Einbußen.
- FRR Tests: Failover durchführen, QoS-KPIs dürfen nicht regressieren.
- Canary: progressive Ausweitung, Stop-Regeln bei Echtzeit-Drops oder Delay 99p.
Typische Core-QoS-Fallstricke und wie das Blueprint sie abfängt
- Klassen-Drift über Domänen: DSCP↔TC Mapping inkonsistent; zentrale Mapping-Matrix und Compliance Checks.
- TE ohne Klassenbezug: Echtzeit landet auf „billigen“ Pfaden; class-aware Constraints und Path KPIs.
- Failover-Regression: Schutzpfade haben andere Queue-Profile; symmetrische Policies und Failure-Mode Tests.
- Policer in Echtzeit: harte Loss-Spikes; Policer vermeiden, Shaping/Scheduling nutzen.
- Zu viele Klassen: Komplexität skaliert nicht; wenige robuste Klassen und klare Semantik.
Pragmatische Core QoS Checkliste: Class-Aware TE und skalierbare Policies
- Klassenmodell: 4–6 robuste Klassen (LOW_LATENCY/VOICE, MEDIA, SIGNAL, CRITICAL, BE, BULK) mit klarer Semantik.
- Interworking: DSCP↔MPLS TC↔CoS Mapping als Source of Truth, Trust Boundaries und Re-Marking an Übergaben.
- Class-aware TE: Pfadpräferenzen und Constraints pro Klasse (Latency-/Congestion-Awareness, Failure-Mode).
- FRR-Konsistenz: identische Queue-Profile auf Schutzpfaden, Failure-Mode Validierung.
- Skalierung: Rollen-Templates, Naming-Standards, Versionierung und automatisierte Compliance Checks.
- Observability: Queue Delay/Depth Perzentile, Per-Class Drops, Drop Reasons plus Path/TE-Visibility.
- Lifecycle: Regression Tests, Canary Rollouts, Rollback und Rezertifizierung als Standardprozess.
