QoS im Metro-Netz ist der entscheidende Baustein, wenn Provider und Stadtwerke viele Access- und Backhaul-Anschlüsse aggregieren müssen, ohne dass Echtzeittraffic wie Voice, Video Calls, IMS/VoLTE, IPTV oder Unternehmens-UC an Qualität verliert. Gerade in Metro-Ethernet-, MPLS- oder Segment-Routing-Umgebungen treffen in kurzer Distanz sehr viele Datenströme auf wenige Uplinks: FTTH-Access, Business-Ethernet, Mobile Backhaul, Cloud-Interconnects und klassischer Internetverkehr laufen an Aggregationsknoten zusammen. Das führt zu typischen Metro-Effekten wie Microbursts, Oversubscription und kurzfristiger Congestion, die nicht unbedingt in der Durchschnittsauslastung sichtbar sind, aber sofort Latenzspitzen, Jitter und Paketverlust erzeugen. Genau dort muss QoS ansetzen: mit einem konsistenten Klassenmodell, sauberem DSCP/CoS/MPLS-TC-Mapping, kontrollierten Warteschlangen, geeigneten Scheduling-Strategien und intelligentem Shaping an den echten Engpässen. Dieser Artikel erklärt praxisnah, wie QoS im Metro-Netz funktioniert, warum Aggregation besonders anspruchsvoll ist und welche Designregeln sich bewährt haben, um Echtzeittraffic auch unter hoher Last stabil und SLA-fähig zu transportieren.
Warum Metro-Aggregation so oft Echtzeittraffic beschädigt
Im Metro-Netz entsteht die größte Komplexität nicht durch lange Strecken, sondern durch die Verdichtung vieler Quellen. Mehrere hundert oder tausend Teilnehmer, Funkstandorte oder Unternehmensstandorte werden in wenigen Aggregationspunkten gebündelt. Selbst wenn jeder einzelne Anschluss „normal“ aussieht, können in Summe sehr kurze Lastspitzen auftreten, die Queues füllen und Drops auslösen.
- Microbursts: Viele Quellen senden gleichzeitig, z. B. nach einem Timer-Event oder durch gleichzeitige ACK-/TCP-Bursts. Durchschnittswerte wirken unauffällig, die Queue läuft aber kurzfristig voll.
- Oversubscription: Aggregationslinks sind oft bewusst überbucht, weil nicht alle Teilnehmer gleichzeitig Peak nutzen. Ohne QoS leidet dann Echtzeit zuerst.
- Gemischte Dienstprofile: Voice und Video treffen auf große Datenflüsse (Backups, Updates, Streams). Ohne Klassen trennen sich diese Flüsse nicht sauber.
- Rate-Limits und Policers: Metro-Services arbeiten häufig mit CIR/PIR-Profilen. Falsch eingesetztes Policing erzeugt Drop-Cluster, die Voice/Video sofort stören.
QoS im Metro-Netz ist deshalb weniger „eine Option“ als eine Betriebsnotwendigkeit, sobald Sie Echtzeitdienste oder SLAs anbieten.
QoS-Ziele im Metro-Netz: Was Echtzeittraffic wirklich braucht
Voice und interaktives Video sind zeitkritisch. In der Metro-Aggregation ist besonders wichtig, dass Warteschlangen nicht unkontrolliert anwachsen. Daraus ergeben sich drei zentrale Zielgrößen:
- Niedrige Latenz: insbesondere niedrige Queueing-Latenz an Engpässen, nicht nur im Durchschnitt.
- Niedriger Jitter: stabile Paketlaufzeiten, damit Jitter-Buffer klein bleiben und Gespräche/Meetings flüssig wirken.
- Minimaler Paketverlust: Drops in Echtzeitklassen sollten praktisch nicht auftreten; Drops sind im Metro oft ein Zeichen für Microbursts oder falsch dimensionierte Queues.
Für IPTV/Managed Video ist zusätzlich die Drop-Rate besonders kritisch, weil Retransmissions dort kaum helfen. Für OTT-Streaming sind Latenzspitzen weniger wichtig, aber Drop-Cluster und Durchsatzinstabilität führen zu Buffering.
Typische Metro-Topologien und wo QoS wirken muss
Ob Sie Metro-Ethernet, MPLS oder Segment Routing betreiben: QoS wirkt vor allem am Egress – dort, wo Contention entsteht. Im Metro sind das typischerweise:
- Uplinks von Access-Aggregation zu Metro-Core: viele Access-Ports treffen auf wenige hochkapazitive Trunks.
- Ring-Uplinks: Schutzschaltungen und Ring-Designs bündeln Traffic; bei Failover kann Last plötzlich umschwenken.
- Service-Edges/Provider-Edges: hier werden Services profiliert und in Klassen einsortiert; Policer/Shaper entscheiden über Drops.
- Interconnect- und Peering-Kanten: Cloud- oder Partnerübergänge können Engpasspunkte sein, die sich als Metro-Problem „anfühlen“.
Ein praxistauglicher Ansatz ist: Engpässe zuerst identifizieren (auch die „kurzen“), dann QoS dort konsequent umsetzen und durchgängig mappen.
Klassenmodell: Wenige Standardklassen, klare Prioritäten
Ein Metro-QoS-Design braucht ein Klassenmodell, das in allen Domänen identisch gilt. Zu viele Klassen erzeugen Betriebsrisiko, zu wenige Klassen vermischen Dienste. Für viele Provider-Setups ist dieses Modell ein guter Startpunkt:
- Voice Media: höchste Echtzeitklasse, Low Latency, strict priority mit Limit.
- Voice Signaling/Control: hoch priorisiert, aber gewichtet (nicht strict).
- Interaktives Video: bevorzugt, gewichtet, mit garantierten Anteilen.
- Managed Video/IPTV: verlustarm, stabiler Durchsatz, eigene gewichtete Klasse (optional, wenn IPTV angeboten wird).
- Business Critical: definierte Mindestanteile für kritische Anwendungen (optional, je nach Produktportfolio).
- Best Effort: Standardverkehr, fair und kontrolliert.
- Background/Scavenger: niedrige Priorität für Massentraffic.
Die zentrale Regel lautet: Strict Priority nur für Voice Media und immer begrenzt. Video darf Audio nie verdrängen; Best Effort darf die Echtzeitklassen nicht „mitziehen“.
Markierungen im Metro: DSCP, CoS und MPLS-TC konsistent halten
Metro-Netze sind häufig multi-layer: Ethernet im Access, IP im Aggregationsrouting, MPLS/SR im Core. Damit QoS Ende-zu-Ende funktioniert, müssen Markierungen durchgängig übersetzt und verstanden werden.
- DSCP: zentrale Markierung im IP-Header, ideal für domänenübergreifende DiffServ-Klassen.
- CoS/802.1p: wichtig in VLAN-/Carrier-Ethernet-Segmenten, oft direkt auf Hardware-Queues gemappt.
- MPLS-TC/EXP: im MPLS/SR-Core häufig das relevante Feld für Core-Queuing.
Trust Boundary: Wo werden Markierungen akzeptiert?
Im Provider-Metro-Netz ist Trust eine Frage der Stabilität. Ein Blueprint sollte klar definieren:
- Untrusted Customer Edge: Markierungen werden überschrieben oder in ein internes Profil gemappt.
- Managed CPE: Markierungen können akzeptiert werden, weil Policies kontrolliert sind.
- Conditional Trust: Markierungen gelten nur innerhalb profilierter Budgets; Überschuss wird remarkt oder begrenzt.
Ohne Trust Boundary entsteht „QoS-Inflation“: zu viele Pakete landen in Premium-Klassen, und Echtzeitqualität bricht genau dann ein, wenn sie gebraucht wird.
Queueing und Scheduling: So bleibt Echtzeit unter Last stabil
Die technische Wirksamkeit von QoS entsteht über Warteschlangen (Queues) und die Reihenfolge, in der sie bedient werden (Scheduling). Im Metro ist das besonders wichtig, weil Engpässe häufig kurzzeitig auftreten.
- Low-Latency-Queue für Voice: minimiert Warteschlangenzeit, reduziert Jitter.
- Priority mit Limit: schützt gegen Starvation anderer Klassen und Missmarkierung.
- Weighted Queues für Video/Business: garantieren Mindestanteile, lassen aber Best Effort weiter funktionieren.
- Queue-Limits: verhindern Bufferbloat und halten Latenzspitzen klein.
Ein häufiges Metro-Problem ist, dass Best Effort große Puffer füllt. Dann steigen Latenz und Jitter für alle Klassen, wenn Echtzeit nicht sauber isoliert ist. Deshalb sind kurze, definierte Queue-Limits und eine echte Echtzeitqueue der wichtigste Qualitätshebel.
Shaping im Metro: Microbursts glätten statt Drops erzeugen
Microbursts sind in Aggregationsnetzen normal. Wenn Sie diese Bursts ungefiltert an nachgelagerte Policer oder engere Links schicken, entstehen Drop-Cluster. Für Voice und Video ist das besonders schädlich. Shaping ist hier das Werkzeug der Wahl.
- Egress-Shaping an Rate-Limits: glättet Traffic auf CIR/PIR oder auf technische Linkraten.
- Schutz vor Downstream-Policern: verhindert, dass Burst-Traffic am nächsten Hop gedroppt wird.
- Stabilere Latenz: gleichmäßigere Queue-Füllstände reduzieren Jitter-Spitzen.
Die Designregel lautet: Shaping dort einsetzen, wo Rate-Limits oder Engpässe existieren – besonders an Metro-Uplinks und an Service-Edges. So werden Bursts „entschärft“, bevor sie Echtzeit beschädigen.
Policing: Fairness und SLA-Schutz ohne Echtzeit-Schäden
Policing ist im Providerbetrieb wichtig, um Profile durchzusetzen und Missbrauch zu verhindern. Im Metro ist Policing aber auch eine häufige Ursache für Qualitätsprobleme, wenn es zu hart oder an der falschen Stelle eingesetzt wird.
- Per-Klasse-Policing: Premium-Klassen separat profilieren, statt pauschal pro Interface zu begrenzen.
- Remarking statt Dropping: Überschuss kann als Best Effort weiterlaufen, sofern das Produktmodell das erlaubt.
- Voice nicht in Drops laufen lassen: Voice-Budgets so dimensionieren, dass Policer auf Voice praktisch nie greifen.
Eine bewährte Kombination ist: Ingress-Policing als „Schutz“ und Egress-Shaping als „Stabilisierung“. Dadurch bleibt das Netz fair, ohne dass Echtzeit durch Drop-Cluster leidet.
Hierarchisches QoS (HQoS): Wenn viele Kunden und Services gleichzeitig aggregieren
Im Metro stoßen klassische, flache QoS-Profile an Grenzen, wenn Sie sowohl pro Kunde als auch pro Service garantieren müssen. Hier kommt hierarchisches QoS ins Spiel: Eine obere Ebene setzt das Gesamtprofil (z. B. pro Anschluss/Service-Instance), darunter werden Klassen (Voice/Video/Best Effort) aufgeteilt.
- Pro Kunde Fairness: Ein einzelner Kunde kann nicht die gesamte Echtzeitklasse „verstopfen“.
- Pro Service Garantien: Voice bleibt geschützt, auch wenn der Kunde viel Video/Best Effort sendet.
- Skalierbarkeit: HQoS ist besonders nützlich bei Business-Ethernet, Mobile Backhaul Aggregation und Wholesale-Services.
HQoS ist kein Muss in jedem Metro-Netz, aber ein sehr wirkungsvoller Hebel, wenn Sie „Aggregation plus SLA“ gleichzeitig beherrschen müssen.
Failover und Resilienz: QoS bei Topologieänderungen mitdenken
Metro-Netze arbeiten oft mit Schutzmechanismen: Ring-Failover, Link-Fallback, Fast Reroute. Dabei kann sich Last schlagartig verlagern. QoS muss so designt sein, dass bei Failover nicht plötzlich Echtzeitqualität einbricht.
- Worst-Case Pfade dimensionieren: Planen Sie QoS-Profile so, dass auch der Failover-Pfad Echtzeit trägt.
- Shaping auf neue Engpässe: Nach Umschaltung können bisher unkritische Links zum Bottleneck werden.
- Monitoring auf Events: Korrelation von Failover-Events mit Drops/Jitter-Spikes beschleunigt die Analyse.
Im Betrieb zeigt sich Failover-QoS häufig als „sporadische“ Störung. Ein gutes Metro-Design macht diese Fälle vorhersehbar.
Monitoring im Metro: QoS nachweisen und Engpässe schnell finden
Damit Aggregation ohne Qualitätsverlust gelingt, brauchen Sie Monitoring, das QoS-Events sichtbar macht – nicht nur Linkauslastung. Ein sinnvolles KPI-Set umfasst:
- Queue-Drops pro Klasse: insbesondere Voice/Interaktiv-Video; Drops sind der wichtigste Alarmindikator.
- Queue-Depth und Queueing Delay: zeigt Bufferbloat und Jitter-Risiko.
- Policer-Hits und Shaping-Rate: zeigt Profilverletzungen und Bursts.
- Aktive Jitter/Loss-Messungen: über kritische Metro-Uplinks und Interconnects.
- Service-KPIs: MOS/R-Faktor für Voice (wenn verfügbar), Video-Freeze-Events bei managed UC/IPTV.
Ein bewährtes Vorgehen ist die Korrelation: Sinkt QoE, prüfen Sie zuerst Drops/Queue-Depth in Echtzeitklassen, dann Policer/Shaping und schließlich externe Übergänge (Peering/Cloud).
Best Practices: Metro-QoS als stabile Blaupause
- Standardklassen definieren: wenige Klassen, klare Bedeutungen, überall gleich.
- Voice strikt schützen: Low Latency, strict priority mit Limit, keine Drops.
- Video gewichtet behandeln: Garantien ja, strict priority nein; Queue-Limits setzen.
- Shaping an Engpässen: Microbursts glätten, Drop-Cluster vermeiden.
- Conditional Trust: Markierungen nur kontrolliert akzeptieren, Profile pro Kunde/Service.
- Mapping dokumentieren: DSCP/CoS/MPLS-TC konsistent und getestet.
- HQoS bei Multi-Service-Aggregation: Fairness pro Kunde und Schutz pro Service kombinieren.
- Failover mitplanen: QoS auf Worst-Case Pfade auslegen, Monitoring auf Umschalt-Events.
Häufige Fragen zu QoS im Metro-Netz
Warum sehe ich keine hohe Auslastung, aber trotzdem schlechte Voice-Qualität?
Weil Microbursts und kurzfristige Congestion nicht in Durchschnittswerten sichtbar sind. Kurze Queue-Überläufe oder Bufferbloat erzeugen Jitter-Spitzen und Drops, die Voice sofort hörbar machen. Queue-Depth und Drops pro Klasse sind hier aussagekräftiger als reine Linkauslastung.
Sollte ich Video im Metro genauso priorisieren wie Voice?
Nein. Video kann hohe Bitraten erzeugen und andere Klassen verdrängen. Voice ist klein, aber extrem sensibel. Daher: Voice strict priority mit Limit, Video bevorzugt über gewichtete Klassen mit Garantien und kontrollierten Queue-Limits.
Was ist der schnellste Hebel gegen Qualitätsprobleme in der Metro-Aggregation?
Shaping an den echten Engpässen und konsequentes Klassen-Queueing. In vielen Netzen verschwinden Drop-Cluster und Jitter-Spitzen, sobald Microbursts geglättet werden und Echtzeitpakete nicht mehr in Best-Effort-Queues warten müssen.
