QoS-Topologie: Wo Marking/Queuing/Policing in Telco-Designs hingehört

QoS-Topologie entscheidet im Telco- und Provider-Umfeld darüber, ob Servicequalität planbar und SLA-fähig ist oder ob QoS zu einem unübersichtlichen Sammelsurium aus lokalen „Best Effort“-Tweaks wird. Quality of Service ist dabei nicht nur eine Gerätekonfiguration, sondern ein Architekturthema: WoWoWo

QoS im Provider-Netz: Drei Bausteine, drei unterschiedliche Aufgaben

QoS wird im Alltag oft als „Priorisierung“ zusammengefasst. In der Praxis sind es drei getrennte Aufgaben, die bewusst auf verschiedene Stellen im Netz verteilt werden sollten. Wenn man diese Aufgaben vermischt, entstehen Inkonsistenzen und schwer erklärbare Fehlerbilder.

• Marking (Klassifizierung & Kennzeichnung): Traffic wird einer Serviceklasse zugeordnet und mit Markierungen versehen (z. B. DSCP/CoS), damit das Netz später konsistent reagieren kann.
• Queuing (Scheduling & Buffering): Bei Engpässen entscheidet das Gerät, welche Klassen bevorzugt gesendet werden und wie viel Puffer jede Klasse bekommt.
• Policing/Shaping (Rate Enforcement): Traffic wird begrenzt oder geglättet, um Überlast zu verhindern und Fairness/SLA-Profile einzuhalten.

Merksatz: Marking ist Identität, Queuing ist Verhalten, Policing ist Vertrag

Marking sagt, was der Traffic „ist“, Queuing entscheidet, wie das Netz bei Engpässen reagiert, und Policing/Shaping setzt Grenzen durch, die oft direkt aus Produkten und SLAs abgeleitet sind.

Warum QoS topologisch geplant werden muss

Telco-Netze sind hierarchisch. Ein Traffic-Flow läuft vom Customer Edge durch Access, Aggregation, Metro, Core und wieder hinaus. Engpässe können überall entstehen: im Access-Uplink, im Metro-Ring, im Core während N-1-Failover, im DCI, oder an Peering-Edges. Ein QoS-Design ist nur dann wirksam, wenn es diese Topologie berücksichtigt und die richtigen Funktionen an die richtigen Stellen setzt.

• Engpässe sind ortsabhängig: Access hat andere Bottlenecks als Core oder DCI.
• Failure Domains: Im Störfall verschieben sich Engpässe; QoS muss auch im N-1-Szenario funktionieren.
• Multi-Service-Mix: Viele Dienste teilen sich Transport; QoS ist die Methode, Prioritäten umzusetzen.
• Betrieb: Ohne klare Topologie entstehen „QoS-Inseln“, die schwer zu debuggen sind.

Ein Carrier-Grade Ziel: End-to-end gleiches Klassenmodell

Die wichtigste Voraussetzung für stabile QoS ist ein einheitliches Klassenmodell: wenige Serviceklassen, die überall dieselbe Bedeutung haben, und rollenbasierte Policies, die diese Klassen in jeder Netzebene konsistent behandeln.

Marking: Wo Kennzeichnung hingehört und warum „Trust“ ein Designentscheid ist

Marking sollte möglichst früh passieren – idealerweise am Eintrittspunkt in das Provider-Netz (Ingress). Denn dort ist Kontext vorhanden: Kunde, Serviceprofil, SLA, Porttyp, ggf. VLAN/VRF. Gleichzeitig ist Marking ein Sicherheits- und Vertragsproblem: Darf ein Kunde überhaupt eigene Markierungen setzen? Oder wird alles auf Provider-Standards umgemappt?

• Ingress an der Service-Edge (PE/Access Edge): Beste Stelle für Klassifizierung, weil Kunden- und Produktinformationen bekannt sind.
• Trust Boundary: Markings vom Kunden nur „vertrauen“, wenn es vertraglich und technisch abgesichert ist.
• Remarking-Policy: Standard ist häufig: Kunde markiert, Provider mappt auf eigene Klassen; oder Provider markiert vollständig selbst.
• Management/Control Traffic: Eigene, strikt definierte Klasse – niemals „aus Versehen“ in Best Effort.

Warum zu spätes Marking teuer ist

Wenn Marking erst im Core passiert, hat der Core keine Servicekontexte mehr und muss anhand grober Kriterien raten. Das führt zu Ausnahmen, Sonderregeln und schlechter Skalierung. Marking gehört dahin, wo Serviceidentität bekannt ist: an die Edge.

Queuing: Wo Priorisierung wirklich wirkt

Queuing ist dort wichtig, wo Engpässe auftreten. In Telco-Netzen sind das häufig Uplinks in Access/Metro, DCI-Links, Peering-Edges und Störfallpfade im Core. Ein häufiger Fehler ist, Queuing nur an einer Stelle „schön“ zu konfigurieren und anzunehmen, dass es end-to-end wirkt. In Wahrheit braucht jede Engpassstelle ein konsistentes Queue- und Scheduling-Modell.

• Access-Uplinks: Oft der erste echte Bottleneck; hier entscheidet sich, ob Voice/Signalisierung stabil bleibt.
• Metro/Aggregation: Shared Links für viele Sites; Queue-Disziplin verhindert, dass einzelne Kunden/Flows andere verdrängen.
• Core-Links im N-1: Im Normalbetrieb genug Kapazität, im Failover plötzlich Engpass – QoS muss das abfangen.
• DCI/Peering: Hohe Volumina, häufig Microbursts; Queueing und Buffer-Strategien sind entscheidend.

Priority Queues: Nur mit klaren Guardrails

Strict Priority kann für Echtzeitverkehr sinnvoll sein, ist aber gefährlich ohne Begrenzung: Wenn zu viel Traffic in die höchste Klasse gerät (absichtlich oder durch Fehlmarking), verhungern andere Klassen. Carrier-Grade Designs kombinieren Priority daher mit klaren Limits und einem konservativen Klassenmodell.

Policing vs. Shaping: Wo harte Grenzen sinnvoll sind (und wo nicht)

Policing verwirft oder markiert Pakete, wenn ein Rate-Limit überschritten wird. Shaping glättet Traffic und puffert kurzzeitig, um Burst-Verhalten zu kontrollieren. In Telco-Designs ist die Platzierung entscheidend: Policing im falschen Segment kann latenzkritische Flows zerstören, Shaping am falschen Ort kann unnötig Latenz erhöhen.

• Ingress Policing am Service-Handover: Sinnvoll, um vertragliche Limits durchzusetzen und das Netz vor Oversubscription zu schützen.
• Egress Shaping an Engpässen: Sinnvoll, um Bursts zu glätten und Queue-Drops zu reduzieren (z. B. bei Access-Uplinks).
• Core-Policing sparsam: Im Core ist Policing riskant, weil es schwer ist, „faire“ Kundenkontexte zu kennen.
• Per-Class Shaping: Kann helfen, Serviceklassen stabil zu halten, muss aber standardisiert werden.

Designregel: Verträge am Rand, Fairness im Netz

Harte Vertragsgrenzen (Policing) gehören an die Service-Edge, wo der Vertrag bekannt ist. Im Kern sollten Sie mit Queueing/Scheduling arbeiten, um Fairness und Priorisierung umzusetzen, ohne willkürlich Pakete zu verwerfen.

QoS-Klassenmodell: Wenige Klassen, klare Semantik, end-to-end konsistent

Ein häufiges Skalierungsproblem ist ein überkomplexes Klassenmodell: zu viele DSCP-Werte, zu viele Sonderklassen pro Service, zu viele Ausnahmen. Das wird schnell unbetriebsfähig, weil jedes Gerät, jede Domäne und jeder Partner das Modell exakt gleich umsetzen müsste. Erfolgreiche Telco-Designs arbeiten mit wenigen, klar definierten Klassen.

• Realtime: Voice, Echtzeitmedia – klein, strikt begrenzt, sehr niedrige Latenz.
• Critical Control: Signalisierung, Steuerverkehr, ggf. bestimmte Plattform-Controls – hoch priorisiert, aber limitiert.
• Business: SLA-relevanter Datenverkehr, Enterprise-VPNs, wichtige Anwendungen.
• Best Effort: Standardverkehr ohne SLA.
• Scavenger/Bulk: Hintergrundlast (Backups, große Transfers), die bei Engpässen zuerst degradiert.

LSI-Praxisbezug: QoS-Blueprint statt DSCP-Wildwuchs

Ein QoS-Blueprint definiert für jede Klasse: erlaubte Markings am Ingress, Queue-Parameter an Engpässen, Policing/Shaping-Regeln, Telemetry-KPIs und Abnahmetests. So wird QoS wiederholbar und auditierbar.

QoS in typischen Telco-Topologien: Core, Metro, Access und DC

Die richtige Platzierung von Marking/Queuing/Policing hängt von der Topologieebene ab. Die folgenden Muster sind in Provider-Netzen besonders verbreitet, weil sie Betrieb und Skalierung unterstützen.

Access-Topologie: Kundennähe und harte Vertragsgrenzen

• Marking: Klassifizierung am Customer Handover; Trust nur, wenn vertraglich und technisch abgesichert.
• Policing: Ingress Policers gemäß Serviceprofil, um Oversubscription zu kontrollieren.
• Queuing/Shaping: Egress Shaping auf Uplinks zur Burst-Glättung; konsistente Queue-Profile pro Klasse.

Metro/Aggregation: Shared Links, viele Kunden, hoher Mix

• Marking: Möglichst nicht neu erfinden; Markings durchreichen und nur bei Bedarf remarken.
• Queuing: Entscheidend auf Aggregations-Uplinks; Drop-Policy pro Klasse muss konsistent sein.
• Policing: Eher sparsam; höchstens rollenbasiert für Schutz (z. B. gegen Missbrauch) statt pro Kunde.

Core/Backbone: Hohe Kapazität, Störfallpfade und Schutzklassen

• Marking: Im Core möglichst unverändert; Core sollte keine Serviceidentität neu bestimmen müssen.
• Queuing: Wichtig im N-1/Failover; Core-Queues müssen Störfallreserve und Prioritäten abbilden.
• Policing: Sehr restriktiv; primär Control-Plane-Schutz und Schutz gegen Fehlmarking.

DC/DCI: Microbursts, Overlays und hohe Ost-West-Last

• Marking: Konsistente Behandlung zwischen DC-Fabric und WAN/Metro, Overlays berücksichtigen.
• Queuing: Microburst-Sicht und Queue-Design sind kritisch; Drops sind oft „kurz und teuer“.
• Shaping: An DCI-Edges sinnvoll, um Burst-Spitzen zu glätten und Member-Hotspots zu vermeiden.

QoS und Störfallbetrieb: N-1, FRR/TI-LFA und ECMP-Remapping

Ein QoS-Design, das nur im Normalbetrieb funktioniert, ist im Provider-Alltag unzureichend. In Störfällen ändern sich Pfade, ECMP-Sets schrumpfen, Traffic wird remapped, und Schutzpfade können durch andere Engpässe laufen. Genau dann muss QoS die kritischen Klassen stabil halten und Degradation kontrollieren.

• N-1 Headroom: Ohne Reserve erzeugen Umschaltungen Drops – QoS kann nur priorisieren, nicht zaubern.
• FRR/TI-LFA: Schnelle Umschaltung kann schnell in Engpässe führen; Queues müssen darauf ausgelegt sein.
• ECMP/LAG Hotspots: Remapping erzeugt Microbursts; Queue-Telemetry ist Pflicht.
• Scavenger-Klasse: Bulk-Traffic bewusst degradieren, um Realtime/Control stabil zu halten.

Ein einfaches Störfallprinzip

$\mathrm{SLA\_Stabilität}\approx \mathrm{Headroom}+\mathrm{Priorisierung}+\mathrm{Scope}$

Headroom verhindert Überlast, Priorisierung schützt kritische Klassen, und Scope verhindert, dass zu viel Traffic in hohe Klassen „hineinmarkiert“ wird.

Observability: QoS ohne Queue-Telemetry ist Blindflug

In Telco-Netzen sind QoS-Probleme häufig kurzzeitig: Microbursts, kurze Overloads im Failover, einzelne Member-Hotspots in LAGs. Durchschnittswerte verschleiern das. Ein QoS-Blueprint muss daher Telemetry fest verankern: Queue-Drops pro Klasse, Queue-Tiefe, Member-Link-Drops, Latenz- und Loss-KPIs pro Serviceklasse.

• Queue-Stats: Drops pro Queue/Klasse, Queue-Tiefe, Scheduling-Auslastung.
• Member-Sicht: Bei LAGs Auslastung und Drops pro Mitglied, nicht nur aggregiert.
• Service-KPIs: Loss/Latenz/Jitter pro Klasse und Region, historisiert.
• Event-Korrelation: Wartung, Failover, TE-Änderungen mit QoS-Anomalien verknüpfen.

Evidence-by-Design: QoS wird auditierbar durch Messdaten

Wenn Sie QoS-Profile versionieren, Abnahmetests standardisieren und Queue-Telemetry historisieren, können Sie Servicequalität nachweisen. Das reduziert Diskussionen mit Kunden und intern – und es macht QoS-Änderungen sicherer, weil Auswirkungen messbar sind.

Typische Fallstricke und wie man sie vermeidet

• Zu viele Klassen: Komplexität explodiert – Lösung: wenige Klassen mit klarer Semantik.
• Trust ohne Kontrolle: Kunden markieren „hoch“ und verdrängen andere – Lösung: Trust Boundary plus Remarking/Policing.
• Policing im Core: Harte Drops ohne Kontext – Lösung: Policing an die Edge, Core primär queuen.
• Nur Normalbetrieb getestet: Failover degradiert kritische Klassen – Lösung: N-1 Tests und Störfallreserve.
• Keine Queue-Telemetry: Microbursts bleiben unsichtbar – Lösung: Queue- und Member-Visibility verpflichtend.
• Overlays ignoriert: Encapsulation verändert Marking/MTU – Lösung: Overlay-aware Blueprint und End-to-end Tests.

Praktische Leitlinien: Wo Marking/Queuing/Policing hingehört

• Marking am Ingress: Dort, wo Serviceidentität bekannt ist (PE/Access Edge), mit klarer Trust Boundary.
• Queuing an Engpässen: Access-Uplinks, Metro-Aggregation, DCI/Peering und Core im N-1 – überall konsistente Queue-Profile.
• Policing am Vertragspunkt: Ingress Policers nach Serviceprofil; Core-Policing nur für Schutz (z. B. Control Plane).
• Shaping zur Burst-Glättung: Egress Shaping an bekannten Bottlenecks, um Drops zu reduzieren.
• Wenige Klassen, klare Semantik: Realtime/Control/Business/Best Effort/Bulk als bewährtes Grundmuster.
• Störfallfähigkeit: N-1 Headroom, Scavenger-Klasse, Failover-Tests als Pflicht.
• Observability: Queue-Drops, Member-Visibility, KPIs pro Klasse, Event-Korrelation.
• Governance: Policy-as-Code, Templates, Wellen-Rollouts, Ausnahmen streng kontrollieren.