QoS in Metro-Ringen ist eine der praxisrelevantesten Disziplinen im Carrier-Design, weil sich hier viele typische „Real-World“-Effekte bündeln: Shared Bandwidth, wechselnde Traffic-Flows, Schutzumschaltungen, asymmetrische Engpässe und eine hohe Dichte an Übergängen zwischen Access, Aggregation und Core. Wer in Metro-Ringen stabile Servicequalität für Voice, Video, Mobile Backhaul oder Business-Connectivity liefern will, muss zwei Dinge sauber beherrschen: Shaping Points richtig platzieren und Congestion Domains klar definieren. Denn QoS wirkt nur dort, wo Congestion tatsächlich entsteht – und in Ringtopologien entstehen Staus nicht zufällig, sondern an vorhersehbaren Knoten: bei Hub-Spokes zum Core, an Ring-Uplinks, an Service-Edges, bei East/West-Umleitungen oder nach Failover. Eine saubere Architektur trennt daher Domänen (wo gelten welche Kapazitäts- und QoS-Regeln?) und legt Shaping so, dass die entscheidende Warteschlange „im eigenen Einflussbereich“ liegt. Das Ergebnis ist kein „mehr Priorität“, sondern kontrollierbare Latenz, geringer Jitter, weniger Drop-Bursts und eine QoS-Politik, die auch nach Ring-Switchover und Wartungsfenstern reproduzierbar bleibt.
Warum Metro-Ringe QoS herausfordern: Shared Medium, Umleitungen und variable Engpässe
Metro-Ringe werden gebaut, um Resilienz und Flächenabdeckung effizient zu kombinieren. Gleichzeitig erzeugen sie QoS-Herausforderungen, weil sich Traffic bei Ereignissen (Link-Fail, Maintenance, Topologie-Änderungen) plötzlich anders verteilt. Ein Link, der im Normalbetrieb unkritisch ist, kann nach einer Schutzumschaltung zum Engpass werden. Außerdem ist ein Ring häufig eine Shared Bandwidth Domain: Mehrere Access-Knoten speisen in denselben Ring ein, und die Aggregation Richtung Core ist meist die stärkste Congestion-Quelle. Deshalb ist in Metro-Ringen nicht die Frage „haben wir QoS?“, sondern „wo genau entsteht Stau in welcher Situation – und ist die Queue dort kontrolliert?“
- Traffic-Umleitung: nach Failover laufen Ströme über andere Ringsegmente, Engpässe wandern.
- Oversubscription: viele Access-Anbindungen teilen sich wenige Uplinks zum Core.
- Mikrobursts: Aggregation mehrerer Flows erzeugt kurze, harte Queue-Spitzen.
- Multi-Service: Voice/Video, Business, Mobile Backhaul, Internet teilen die gleiche Transportdomäne.
Congestion Domains definieren: Die wichtigste Vorarbeit für jedes Ring-QoS
Eine Congestion Domain ist ein Bereich, in dem sich mehrere Traffic-Flows dieselben Engpassressourcen teilen und in dem die QoS-Politik als zusammenhängendes System betrachtet werden muss. In Metro-Ringen ist diese Denkweise entscheidend, weil sich die Kapazitäts- und Staupunkte nicht an Geräte- oder VLAN-Grenzen halten, sondern an Topologie- und Verkehrsflüssen. Wer Congestion Domains sauber definiert, kann Zielwerte (Latenz/Jitter/Loss) domänenscharf budgetieren, Telemetrie sinnvoll platzieren und Shaping gezielt ansetzen.
- Access-to-Ring Domain: von Access-Uplink bis zum Ring-Ingress; häufig erste Queue-Entscheidung.
- Ring Transport Domain: mehrere Ringsegmente, auf denen Traffic geteilt wird; Engpässe hängen von Umlenkung ab.
- Ring-to-Core Domain: Aggregationsknoten und Uplinks zum Core; oft der dominierende Staupunkt.
- Service Edge Domain: Übergänge zu BNG/PE, Mobile Core, Internet Breakout oder Partner-Interconnect.
Praktisches Prinzip: „Ein Domain = ein Kapazitätsmodell“
Für jede Congestion Domain sollte klar sein, welche Links im Normal- und Failover-Fall limitierend sind, wie Oversubscription geplant ist, welche QoS-Klassen Budgets haben und welche Messpunkte die Domain-Health belegen. Ohne dieses Modell bleibt QoS reaktiv und schwer erklärbar.
Shaping Points: Warum der Ort der Queue über Qualität entscheidet
In Metro-Ringen entscheidet der Ort der Warteschlange über Latenz, Jitter und Drop-Muster. Wenn Congestion in einem nicht kontrollierbaren Segment entsteht (z. B. in einem Ringknoten ohne passende Policy oder bei einer Black-Box-Transportstrecke), sind QoS-Effekte unvorhersehbar: Drops treten „irgendwo“ auf, und Telemetrie ist lückenhaft. Shaping verlagert Congestion in ein kontrollierbares Gerät und glättet Bursts. Der zentrale Gedanke lautet: Die entscheidende Queue muss dort liegen, wo Sie sie konfigurieren und messen können.
- Egress Shaping: setzt den Abfluss knapp unter die tatsächliche Engpassrate, damit die Queue lokal entsteht.
- Burst-Glättung: reduziert Mikroburst-Drops und stabilisiert Queue-Delay.
- Reproduzierbarkeit: QoS wirkt konsistent, weil Congestion am selben Punkt behandelt wird.
- Messbarkeit: Queue-Delay, Drops und Policer-Events sind sichtbar und korrelierbar.
Typische Shaping-Positionen im Metro-Ring-Design
Es gibt einige wiederkehrende Stellen, an denen Shaping in Metro-Ringen besonders wirksam ist. Die Wahl hängt davon ab, wo die Engpässe entstehen und wie stark Traffic bei Failover umgelenkt wird. Wichtig ist, Shaping nicht als „Bandbreitenbremse“ zu sehen, sondern als Steuerungsinstrument, um Queueing zu kontrollieren und Echtzeitklassen zu schützen.
- Access Ingress: Shaping pro Access-Service (z. B. pro EVC/VRF) verhindert Noisy Neighbor Effekte auf dem Ring.
- Aggregation Node Egress: Shaping Richtung Core/Uplink stabilisiert den größten Engpasspunkt.
- Ring Segment Egress: sinnvoll, wenn bestimmte Segmente im Failover regelmäßig limitierend werden.
- Service Edge (BNG/PE): Shaping an Übergängen zu Internet/Partnern hält Congestion im eigenen Einflussbereich.
HQoS im Ring: Per-Service/Per-Customer Budgets und Ring-Fairness kombinieren
Metro-Ringe tragen oft viele Services: Business-Connectivity, Mobile Backhaul, Wholesale, Internet. Ein robustes Muster ist Hierarchical QoS (HQoS): Ein Parent-Shaper definiert die maximale Rate eines Services oder Kunden, während Child-Queues innerhalb dieser Rate die Klassen (Voice, Video, Business, Best Effort, Bulk) bedienen. Das verhindert, dass ein einzelner Service durch Bursts den Ring destabilisiert, und sorgt dafür, dass Echtzeitklassen innerhalb jedes Serviceprofils priorisiert werden.
- Per-Service Shaper: begrenzt die Gesamtlast eines EVC/VRF, damit der Ring planbar bleibt.
- Class-Based Queues: Voice/Video/Signaling getrennt priorisieren, Best Effort fair bedienen.
- Budgetdisziplin: Strict Priority (z. B. für Voice) immer strikt limitiert.
- Templatefähigkeit: HQoS muss standardisiert ausrollbar sein, sonst entsteht Drift.
QoS-Klassenmodell im Metro-Ring: Wenige Klassen, klare Semantik
In Ringnetzen ist Konsistenz wichtiger als Granularität. Ein schlankes Klassenmodell erleichtert Mappings zwischen DSCP, PCP und ggf. MPLS-TC, reduziert Fehler an Übergängen und macht Telemetrie aussagekräftiger. Typisch ist eine Echtzeitklasse für Voice, eine priorisierte Klasse für interaktives Video, eine Business-Klasse, Best Effort und eine Bulk/Scavenger-Klasse. Zusätzlich wird Network Control geschützt, damit Routing/OAM auch unter Last stabil bleiben.
- Network Control: Routing/OAM/Management, geschützt vor Verdrängung.
- Voice: LLQ, strikt limitiert, minimale Queueing-Latenz.
- Video/Interaktiv: gewichtete Echtzeitklasse mit Mindestbandbreite.
- Business Critical: bevorzugt, aber nicht strict priority.
- Best Effort: optional mit AQM/ECN, um Bufferbloat zu reduzieren.
- Bulk/Scavenger: bewusst nachrangig, um Ringstabilität zu erhöhen.
Failover und Ring-Switchover: QoS muss im Worst Case funktionieren
Ein häufiger Fehler ist, QoS nur für den Normalpfad zu dimensionieren. In Metro-Ringen ist der Worst Case jedoch zentral: Nach einem Link-Fail oder während Maintenance können sich Traffic-Flows verdichten, und die Engpässe ändern sich. Das QoS-Design muss deshalb „Failover-aware“ sein: Shaping-Raten, Headroom und Queue-Budgets müssen auch dann plausibel sein, wenn ein Ringsegment wegfällt oder wenn Traffic über einen längeren Pfad läuft. Besonders Echtzeitdienste leiden sonst bei Umschaltung, obwohl im Normalbetrieb alles stabil war.
- Headroom: Kapazitätsreserve für Umleitungen und Wartungsfenster einplanen.
- Backup-Profile: QoS-Policies müssen auf Schutzpfaden identisch oder kompatibel sein.
- Lasttests: Failover unter realer Mischlast testen, nicht nur im Leerlauf.
- Congestion Domain Updates: nach Topologieänderungen Budgets und Engpassannahmen rezertifizieren.
Mikrobursts im Metro-Ring: Warum kurze Peaks QoS „durchlöchern“
Mikrobursts sind in Metro-Ringen besonders häufig, weil viele Access-Links auf wenige Ring- oder Core-Uplinks fan-innen. Ein Durchschnitt von 40% Auslastung kann trotzdem wiederkehrende Queue-Overflows erzeugen, wenn Traffic in kurzen Wellen eintrifft. Für QoS bedeutet das: Telemetrie muss kurzgranular sein, Shaping muss Bursts glätten, und Queue-Limits müssen so dimensioniert werden, dass Echtzeit nicht durch Bufferbloat leidet. Best Effort profitiert oft von AQM/ECN, weil dadurch die Queue-Länge stabiler bleibt.
- Short-interval Monitoring: 1–5 Minuten und Perzentile statt Tagesmittelwerte.
- Queue-Delay: als Frühindikator für Jitter und bevorstehende Drops.
- Shaping: reduziert Burst-Spitzen und verlagert Congestion in kontrollierbare Queues.
- AQM/ECN: stabilisiert Best Effort und reduziert Bufferbloat, indirekt besser für Echtzeit.
Messbarkeit und Betrieb: Congestion Domains mit KPIs „gesund“ halten
Ein Ring-QoS-Design ist nur dann nachhaltig, wenn es betrieblich messbar ist. In Metro-Ringen sind queuebezogene KPIs die wichtigste Datenquelle: Queue-Delay und Drops pro Klasse pro Engpasslink. Ergänzend sind DSCP/PCP-Verteilungen wichtig, um Trust Boundaries und Remarking zu verifizieren. Ebenso relevant sind Path-Events: Ring-Switchover, Schutzumschaltung oder Routing-Changes müssen mit QoS-KPIs korrelierbar sein, sonst bleibt die Ursachenanalyse spekulativ.
- Queue-Delay: p95/p99 pro Klasse an den Engpasslinks der Domain.
- Queue-Drops: Drops in Echtzeitklassen sind kritisch; Best Effort Drops sind anders zu bewerten.
- Remarking/Policer Counters: Nachweis, dass Marking-Politik eingehalten wird.
- Event-Korrelation: Failover- und Maintenance-Events mit QoS-Abweichungen verknüpfen.
Typische Failure Patterns in Metro-Ringen
Wenn QoS in Metro-Ringen „nicht funktioniert“, sind die Ursachen oft strukturell. Häufig wird am falschen Punkt gequeued, Shaping fehlt, oder Congestion Domains sind nicht sauber getrennt. Ebenso häufig sind inkonsistente Markings an Übergängen (DSCP↔PCP↔MPLS-TC) oder QoS-Policies, die im Failover-Pfad nicht vorhanden sind. Wer diese Muster kennt, kann Ring-QoS deutlich schneller stabilisieren.
- QoS nur am Core: Congestion entsteht im Ring/Access, nicht im Backbone.
- Queue beim falschen Gerät: Drops passieren außerhalb des Einflussbereichs; Shaping fehlt.
- Failover ohne QoS: Schutzpfad hat keine kompatiblen Policies; Echtzeit bricht bei Umschaltung ein.
- Mapping-Lücken: DSCP wird auf PCP/TC falsch gemappt; Echtzeit fällt in Best Effort.
- Bufferbloat: große Puffer erzeugen hohe Latenz ohne Drops; AQM/Queue-Limits fehlen.
Blueprint: QoS in Metro-Ringen systematisch planen
Ein belastbarer Ansatz beginnt mit der Definition der Congestion Domains: Access-to-Ring, Ring Transport, Ring-to-Core und Service Edge. Für jede Domain wird ein Kapazitätsmodell für Normal- und Failover-Fall erstellt, inklusive Oversubscription-Regeln und Headroom. Anschließend werden Shaping Points so gesetzt, dass die entscheidende Queue kontrollierbar ist: pro Service/Customer am Access, an Aggregation-Uplinks Richtung Core und an kritischen Ringsegmenten, die im Failover limitieren. Danach wird ein schlankes Klassenmodell implementiert (Voice, Video, Business, Best Effort, Bulk plus Network Control), mit konsistenten DSCP/PCP/MPLS-TC-Mappings. HQoS sorgt für per-Service Fairness und stabile Echtzeitpriorisierung. Abschließend werden Telemetrie und Rezertifizierung etabliert: Queue-Delay/Drops pro Klasse, DSCP-Verteilungen, Event-Korrelation bei Switchover. So entsteht ein Metro-Ring-QoS, das nicht nur im Labor, sondern im echten Betrieb – inklusive Umleitungen und Peak-Last – reproduzierbar funktioniert.