Site icon bintorosoft.com

Blueprint “Core QoS”: Class-Aware TE und skalierbare Policies

Red Snapper

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“.

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 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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

Typische Core-QoS-Fallstricke und wie das Blueprint sie abfängt

Pragmatische Core QoS Checkliste: Class-Aware TE und skalierbare Policies

Exit mobile version