QoS im IP/MPLS-Core: Voice & Video stabil durch den Backbone bringen

QoS im IP/MPLS-Core ist für Telcos und Carrier der Schlüssel, um Voice & Video stabil durch den Backbone zu bringen – auch dann, wenn der Datenverkehr stark schwankt, Peering-Links unter Druck geraten oder im Metro-Netz Microbursts auftreten. Viele Provider verlassen sich darauf, dass der Core „genug Kapazität“ hat. In der Praxis reicht das nicht immer: Selbst kurzzeitige Congestion an Core-Trunks, Interconnects oder bei Failover-Szenarien kann Jitter-Spitzen und Paketverlust erzeugen, die VoIP, IMS/VoLTE, WebRTC-Meetings, Unified Communications oder IPTV sofort hör- und sichtbar machen. Ein professionelles QoS im IP/MPLS-Core basiert deshalb auf einem konsistenten DiffServ-Klassenmodell, sauberem Mapping zwischen DSCP und MPLS-TC/EXP, standardisierten Queue- und Scheduler-Profilen sowie klaren Regeln für Shaping, Policing und Trust Boundaries an den Edges. Ziel ist ein Backbone, der Echtzeittraffic zuverlässig bevorzugt, ohne Best Effort zu ersticken, und der unter Last vorhersagbar reagiert. Dieser Artikel erklärt praxisnah, wie Sie QoS im IP/MPLS-Core planen, implementieren und betreiben, damit Voice & Video auch bei Peak-Last und Topologieänderungen stabil bleiben.

Warum QoS im Core trotz hoher Bandbreiten relevant bleibt

Im IP/MPLS-Core sind Linkraten hoch und Auslastung oft gut geplant. Trotzdem ist QoS keineswegs überflüssig. Denn Qualitätsprobleme entstehen häufig nicht durch dauerhafte Überlast, sondern durch kurzfristige Ereignisse und strukturelle Effekte:

• Microbursts aus Aggregation: Metro- und Access-Aggregation kann Bursts erzeugen, die Core-Queues kurzfristig füllen.
• Failover und Traffic-Shift: Fast Reroute, IGP-Konvergenz oder Linkausfälle verlagern Last schlagartig auf andere Trunks.
• Interconnect/Peering als Engpass: Viele Echtzeitprobleme „fühlen sich“ wie Core-Probleme an, sind aber Übergabe-Engpässe im Backbone-Rand.
• Unsaubere Markierung/Mapping: Selbst ein leistungsfähiger Core bringt nichts, wenn Voice als Best Effort gequeued wird.
• Bufferbloat durch zu große Queues: Große Puffer können Drops verhindern, aber Latenz/Jitter stark erhöhen.

QoS im IP/MPLS-Core sorgt dafür, dass diese Ereignisse kontrolliert ablaufen: Echtzeittraffic bleibt stabil, Best Effort bleibt fair, und das Verhalten ist auch im Ausnahmefall planbar.

Grundlage: DiffServ im Core – Klassen statt per-Flow-Logik

Im Backbone muss QoS skalieren. Per-Flow-Reservierungen oder komplexe Applikationserkennung sind im Core selten praktikabel. Deshalb basiert QoS im IP/MPLS-Core typischerweise auf DiffServ: Pakete werden in wenige Klassen eingeteilt und pro Hop (Per-Hop Behavior) entsprechend behandelt.

• Klassifizieren: Edge/Ingress ordnet Traffic einer Serviceklasse zu (Voice, Video, Business, Best Effort).
• Markieren: DSCP im IP-Header und im MPLS-Core häufig MPLS-TC/EXP als Transportklassifizierung.
• Behandeln: Core-Router mappen Klassen auf Queues, Scheduler und Drop-Profile.

Wichtig: Der Core sollte so „dumm wie möglich“ und so konsistent wie nötig sein. Das heißt: wenige, standardisierte Klassenprofile – überall gleich.

DSCP, MPLS-TC/EXP und das Mapping: Die wichtigste Core-Disziplin

In MPLS-Backbones entscheidet häufig das MPLS-TC/EXP-Feld darüber, welche Queue im Core genutzt wird. DSCP kann auf dem IP-Payload liegen, der Core sieht aber primär Labels. Deshalb ist das Mapping zwischen DSCP und MPLS-TC ein Kernbestandteil des QoS-Designs.

Typische Mapping-Fehler

• DSCP korrekt, TC falsch: Edge setzt DSCP richtig, mappt aber in eine falsche TC-Klasse – Voice landet nicht in Low Latency.
• TC wird nicht überall gleich behandelt: Unterschiedliche Router-Templates führen zu inkonsistenten Queues.
• Remarking an Übergängen: DSCP/TC wird an NNI/Interconnects überschrieben; End-to-End-Kohärenz bricht.

Best Practice ist ein dokumentiertes, standardisiertes Mapping: Jede Serviceklasse hat genau definierte DSCP/TC-Codes und ein klar beschriebenes Queue-/Scheduler-Verhalten im Core.

Ein praxistaugliches Klassenmodell für Voice & Video im Core

Ein IP/MPLS-Core sollte ein überschaubares Set an Klassen nutzen. Je nach Provider-Portfolio reicht oft ein Modell mit 5 bis 7 Klassen. Ein bewährtes Schema ist:

• Voice Media: RTP/RTCP, höchste Echtzeitklasse, Low Latency, strict priority mit Limit.
• Voice Signaling/Control: SIP/Steuerdaten, hoch priorisiert, aber gewichtete Behandlung.
• Interaktives Video: UC/WebRTC/Meetings, gewichtete Klasse mit Garantien, keine strict priority.
• Managed Video/IPTV: verlustarm, stabiler Durchsatz (optional, wenn IPTV/Managed Video angeboten wird).
• Business Critical: garantierte Anteile für kritische Unternehmensanwendungen (optional).
• Best Effort: Standarddatenverkehr, fair.
• Background/Scavenger: niedrige Priorität für Massentraffic.

Die Kernregel lautet: Voice ist klein, aber sensibel – daher strict priority, aber begrenzt. Video ist groß und variabel – daher bevorzugt, aber gewichtet.

Queueing im Core: Trennung statt „alles in eine Queue“

Core-Router arbeiten mit Hardware-Queues pro Interface. QoS ordnet Klassen diesen Queues zu. Damit Echtzeit stabil bleibt, müssen Voice und Video aus Best Effort herausgelöst werden. Wesentliche Prinzipien:

• Separate Echtzeitqueue: Voice bekommt eine eigene Low-Latency-Queue, damit Queueing Delay minimal bleibt.
• Dedizierte Video-Queue: Video in eine gewichtete Queue, um Mindestressourcen zu sichern.
• Best Effort kontrollieren: Best Effort darf Puffer nicht „aufblähen“, sonst steigen Latenz und Jitter netzweit.

Ein wichtiger Punkt im Core ist die Begrenzung von Puffergrößen: Zu große Queues verhindern zwar Drops, können aber Latenzspitzen erzeugen, die Echtzeitqualität verschlechtern – selbst ohne Paketverlust.

Scheduling: Strict Priority nur mit Limit, sonst wird der Core unberechenbar

Scheduling definiert, welche Queue wann bedient wird. Für Voice ist strict priority üblich, weil Sprachpakete minimal warten sollen. Ohne Limit wird strict priority jedoch zum Risiko: Bei Fehlmarkierung oder unkontrolliertem Premium-Traffic kann Best Effort verhungern, und das Netz wird instabil.

• Voice strict priority mit Bandbreitenlimit: schützt Echtzeit und verhindert Starvation.
• Video und Business gewichtet: garantierte Anteile, zusätzliche Nutzung freier Kapazität.
• Best Effort fair: ausreichender Anteil, aber keine Dominanz durch übergroße Puffer.

In Telco-Backbones ist „limitierte Priorität“ eine der wichtigsten Designregeln, weil sie Sicherheit und Qualität gleichzeitig ermöglicht.

Shaping und Policing im Core: Wo es sinnvoll ist und wo nicht

Im reinen Core wird Shaping seltener benötigt als an Edge/Access, weil Links oft gleichmäßig dimensioniert sind. Dennoch gibt es Szenarien, in denen Shaping im Backbone sinnvoll ist – vor allem an Übergängen und bei Rate-Limits.

Shaping: Glätten für stabile Klassen

• Interconnects/Peering: Wenn Übergänge zu anderen Netzen oder Cloud-Edges rate-limitiert sind, reduziert Shaping Drop-Cluster.
• Ring-/Aggregation-Uplinks: Shaping kann Microbursts entschärfen, bevor sie Drops verursachen.

Policing: Schutz, aber vorsichtig bei Echtzeit

• Policing an Edges: häufig sinnvoll, um Profile zu erzwingen und Missbrauch zu verhindern.
• Keine harten Policer auf Voice Media im Core: Drops sind unmittelbar hörbar; Voice sollte so dimensioniert sein, dass es nicht policed wird.
• Remarking statt Dropping: Überschuss kann in Best Effort überführt werden, wenn Produktmodell und Policy das erlauben.

In der Praxis gilt: Profilierung gehört an den Rand (PE), Stabilisierung durch konsistentes Queueing gehört in den Core.

Edge- und Core-Rollen sauber trennen: Die „Pipe“-Logik in der Praxis

Ein robustes IP/MPLS-QoS-Design trennt Verantwortlichkeiten:

• Provider Edge (PE): Klassifizierung, Markierung, Trust Boundary, Profilierung pro Kunde/Service, Mapping DSCP->TC.
• Core (P): schnelle, konsistente Behandlung nach TC-Klassen; keine komplexen Sonderlogiken.
• Egress-PE: ggf. Restore/Remarking in DSCP für Übergabe oder für Kundennetze.

Diese Trennung reduziert Betriebsfehler und macht QoS skalierbar. Der Core ist dann ein „Transport für Klassen“, nicht ein Ort für Einzelfall-Regeln.

QoS und Traffic Engineering: Was bei SR/MPLS-TE wichtig wird

Viele Provider nutzen Traffic Engineering, um Last besser zu verteilen. Das verbessert QoE oft stärker als reine Priorisierung. Für QoS im Core ist wichtig:

• Lastspitzen vermeiden: TE kann Hotspots reduzieren, die sonst Jitter und Drops erzeugen.
• Failover-Design: Fast Reroute kann Last auf wenige Links schieben; QoS muss den Worst Case tragen.
• Service-Awareness: Wenn bestimmte Dienste (z. B. Voice-Interconnect) auf stabilere Pfade gelegt werden, sinkt RTT-Varianz.

QoS und Traffic Engineering ergänzen sich: TE reduziert Congestion, QoS kontrolliert das Verhalten, wenn Congestion trotzdem entsteht.

Typische Fehlerbilder im IP/MPLS-Core und ihre Ursachen

• Voice ok, Video schlecht: Video läuft im Best Effort oder hat zu geringe Gewichtung; Microbursts erzeugen Drops.
• Voice bricht bei Failover ein: Engpass-Link nach Umschaltung nicht QoS-dimensioniert; Queue-Limits/Weights passen nicht zum Worst-Case.
• „DSCP stimmt, QoS wirkt nicht“: DSCP->TC Mapping falsch oder TC wird nicht auf Queues gemappt.
• Hohe Latenz ohne Drops: Bufferbloat durch zu große Queues; QoS muss Queueing Delay begrenzen.
• Interconnect-Probleme: Engpässe an Peering/Transit; Core erscheint „schuld“, obwohl Übergabe der Bottleneck ist.

Die schnellste Diagnose ist meist: TC/DSCP-Pfad prüfen, Queue-Drops pro Klasse ansehen, Queue-Depth und Shaping/Policer-Hits an kritischen Interfaces korrelieren.

Monitoring im Backbone: QoS messbar und SLA-fähig machen

Ein IP/MPLS-Core kann nur dann zuverlässig betrieben werden, wenn QoS-Events sichtbar sind. Linkauslastung allein reicht nicht, weil Microbursts und kurze Congestion nicht im Durchschnitt auftauchen.

• Queue-Drops pro Klasse: besonders Voice/Interaktiv-Video; Drops sind der wichtigste Qualitätsindikator.
• Queue-Depth und Queueing Delay: zeigt Jitter-Risiko und Bufferbloat.
• Policer-Hits und Remarking: zeigt Profilverletzungen und Missmarkierung.
• Aktive Jitter/Loss-Tests: über zentrale Core-Trunks und Interconnects, idealerweise pro Klasse.
• Service-KPIs: MOS/R-Faktor für Voice (wo verfügbar), Video-QoE-Indikatoren bei managed UC/IPTV.

Ein besonders guter Betriebsstandard ist: „Drops in der Voice-Klasse sind ein Incident“. Damit sichern Sie Sprachqualität systematisch ab.

Best Practices: QoS im IP/MPLS-Core als stabile Blaupause

• Wenige Klassen, klare Bedeutungen: Standardklassen netzweit identisch.
• DSCP->TC Mapping standardisieren: dokumentiert, getestet, überall gleich.
• Voice strict priority mit Limit: Low Latency ohne Starvation.
• Video gewichtet behandeln: Garantien ja, strict priority nein; Queue-Limits kontrollieren.
• Edge profiliert, Core transportiert: PE macht Trust/Profilierung, Core macht konsistentes Scheduling.
• Failover berücksichtigen: Worst-Case Pfade dimensionieren, nicht nur Normalbetrieb.
• Monitoring auf Klassenebene: Drops/Queue-Depth/Policer-Hits als Standard-Dashboards.

Häufige Fragen zu QoS im IP/MPLS-Core

Reicht es nicht, den Core einfach „überzudimensionieren“?

Überdimensionierung hilft, aber sie verhindert nicht Microbursts, Failover-Hotspots oder Engpässe an Interconnects. Außerdem bleibt ohne QoS das Verhalten bei seltenen Congestion-Ereignissen unvorhersehbar. QoS sorgt für planbare Priorisierung und schützt Echtzeit, wenn es eng wird.

Warum ist strict priority für Video im Core meist eine schlechte Idee?

Video kann hohe und schwankende Bitraten erzeugen. In strict priority kann es andere Klassen verdrängen und das Netz bei Last destabilisieren. Besser ist eine gewichtete Videoklasse mit garantierten Anteilen und kontrollierten Queue-Limits.

Was ist der wichtigste Erfolgsfaktor für stabile Voice-Qualität im Backbone?

Ein konsistentes End-to-End Klassenmodell mit sauberem DSCP->MPLS-TC Mapping und einer limitierte Low-Latency-Behandlung für Voice auf allen relevanten Engpass-Interfaces. Wenn Voice-Pakete zuverlässig in Low-Latency-Queues landen und dort keine Drops auftreten, bleibt Sprachqualität auch bei Peak-Last stabil.