DiffServ-Aware Traffic Engineering (DS-TE) ist eine der elegantesten Methoden, um QoS-Klassen nicht nur per Queueing zu priorisieren, sondern sie aktiv mit Traffic Engineering zu verbinden. In klassischen DiffServ-Designs wird Verkehr markiert (DSCP/TC), in Queues einsortiert und bei Congestion nach PHB (Per-Hop Behavior) behandelt. Das funktioniert zuverlässig – solange die Pfade und Kapazitäten „passen“. In realen Provider-Netzen verschieben sich Engpässe jedoch durch Wartung, Failover, Hotspots (z. B. zu Cloud-Edges) oder ungleichmäßige Lastverteilung. Genau hier setzt DS-TE an: Es erweitert MPLS-TE um Klassenbewusstsein, sodass Bandbreitenreservierungen und Admission Control nicht nur „pro LSP“, sondern pro Traffic Class erfolgen können. Damit lassen sich Echtzeit- und Business-Klassen planbar über den Backbone führen, während Best Effort und Bulk nicht versehentlich Premium-Reserven aufbrauchen. Richtig umgesetzt hilft DS-TE, SLAs robuster zu machen, Congestion Domains besser zu kontrollieren und TE-Entscheidungen mit QoS-Politik zu harmonisieren – ohne dass man in jedes einzelne Queue-Profil „mehr Bandbreite“ hineinrät.
Warum klassisches QoS allein nicht reicht, wenn Pfade variieren
QoS bestimmt, was passiert, wenn ein Link congested ist. Traffic Engineering bestimmt, welche Links und Pfade überhaupt belastet werden. In Netzen mit MPLS-TE, Segment-Routing Policies, Anycast-Last oder häufigen Wartungsumleitungen kann es passieren, dass bestimmte Pfade plötzlich Hotspots werden – selbst wenn der Core im Durchschnitt „uncongested“ wirkt. Dann konkurrieren Klassen an einem Engpass, und QoS muss „retten“, was zu retten ist. DS-TE verschiebt diesen Ansatz nach vorn: Statt erst im Congestion-Fall zu priorisieren, steuert DS-TE bereits bei der Pfad- und Ressourcenvergabe, welche Klassen wie viel Bandbreite auf welchen Links überhaupt belegen dürfen.
- QoS: Reaktion auf Stau (Queueing, Drops, Delay-Kontrolle).
- TE: Proaktive Pfadsteuerung (welcher Traffic läuft über welche Links).
- DS-TE: TE mit Klassenbewusstsein (Bandbreite und Admission pro Klasse).
DS-TE in einem Satz: Klassen bekommen eigene „TE-Budgets“
Das Kernprinzip von DS-TE ist, dass Traffic Classes (im TE-Kontext häufig als Class-Types bezeichnet) eigene Bandbreitenkontingente auf einem Link erhalten. Während klassisches TE Bandbreite pro LSP reserviert, unterscheidet DS-TE zusätzlich, zu welcher Klasse dieser LSP gehört. So kann ein Provider sicherstellen, dass z. B. Voice/Realtime nicht von datenlastigen LSPs „wegreserviert“ wird und dass umgekehrt Premiumklassen nicht unkontrolliert wachsen, nur weil irgendwo noch Gesamtbandbreite verfügbar wäre.
- Pro Klasse reservieren: Bandbreite wird nicht nur „gesamt“, sondern je Class-Type betrachtet.
- Admission Control: neue LSPs werden abgewiesen oder umgeleitet, wenn das Klassenbudget erschöpft ist.
- Planbarkeit: QoS-Klassen werden zu planbaren Transportprodukten, nicht nur zu Queue-Prioritäten.
Die Bausteine: Class-Type, TE-Class und Prioritäten
In DS-TE werden LSPs TE-seitig einer Klasse zugeordnet. Diese TE-Klasse ist nicht identisch mit DSCP oder MPLS-TC, aber sie wird in der Praxis an das DiffServ-Klassenmodell gekoppelt. Damit entsteht eine durchgängige Kette: Serviceklasse → Marking (DSCP/TC) → PHB/Queueing → TE-Class-Type/Reservation → Pfadwahl. Entscheidend ist, dass diese Kette dokumentiert und netzweit konsistent ist, sonst entsteht ein zweigeteiltes System, in dem TE und QoS unterschiedliche „Wahrheiten“ leben.
- Serviceklasse: z. B. Voice, Video, Business, Best Effort, Bulk.
- Marking: DSCP im IP, TC im MPLS-Core.
- PHB: Queueing/Scheduling pro Hop.
- Class-Type (DS-TE): TE-seitige Klasse, die ein Bandbreitenbudget nutzt.
- Prioritäten: bestimmen, wie LSPs bei Ressourcenknappheit behandelt werden (z. B. Preemption-Logik).
Warum DS-TE für Carrier-Grade SLAs attraktiv ist
Provider-SLAs scheitern selten an einem einzigen „kaputten Link“, sondern an Engpässen in Ausnahmefällen: Failover, Wartung, Hotspots. DS-TE gibt Ihnen ein Werkzeug, um Premiumklassen auch in diesen Fällen zu schützen, weil ihre Ressourcen im TE-Modell abgesichert sind. Gleichzeitig verhindern Sie, dass Best Effort oder Bulk durch TE-Reservierungen „unabsichtlich“ Premium-Reserven frisst. Das Ergebnis ist weniger „QoS-Flickwerk“ in den Queues und mehr Planbarkeit auf Transportebene.
- Schutz vor Hotspots: Premiumklassen verlieren nicht plötzlich ihre Pfade, weil Reserven weg sind.
- Stabilität bei Failover: Klassenbudgets helfen, dass Schutzpfade nicht sofort kollabieren.
- Produktlogik: Business-/Realtime-Produkte lassen sich als reservierte Transportleistung definieren.
Klassenmodell vorbereiten: DS-TE funktioniert nur mit wenigen, klaren Klassen
DS-TE erhöht die Komplexität des TE-Systems. Deshalb ist ein schlankes Klassenmodell Pflicht. Wenn Sie versuchen, jedes DSCP-Feld in eigene TE-Klassen zu übersetzen, verlieren Sie die Beherrschbarkeit. In der Praxis sind wenige Class-Types sinnvoll, die die wichtigsten Servicearten abdecken: z. B. Realtime (Voice), Interactive Video, Business Critical, Best Effort und Bulk. Network Control/OAM wird oft separat behandelt, weil es nicht über „große Reservierungen“ abgesichert werden muss, aber extrem zuverlässig sein soll.
- Realtime: klein, streng, sehr schützenswert (z. B. Voice Media).
- Video/Interactive: größer, aber trotzdem priorisiert und planbar.
- Business: bevorzugt, stabil, meist throughput- und latency-sensitiv.
- Best Effort: flexibel, nutzt verbleibende Kapazität.
- Bulk/Scavenger: bewusst nachrangig, um Peaks zu dämpfen.
Mapping: DiffServ-Klassen an TE-Class-Types koppeln
Der entscheidende Engineering-Schritt ist das Mapping: Welche DiffServ-Klasse (z. B. EF/AF/CS) entspricht welcher TE-Class-Type? Dieses Mapping muss zusammen mit Ihrer DSCP↔MPLS-TC-Tabelle und Ihren PHB/Queue-Profilen gedacht werden. Ein typisches Muster ist: EF/Voice → Realtime Class-Type; AF4x/Video → Video Class-Type; AF3x/Business → Business Class-Type; DSCP 0 → Best Effort; CS1/Scavenger → Bulk. Wichtig ist weniger die konkrete Zahl, sondern die Konsistenz über alle Rollen (Ingress PE, Core P, Egress PE) und alle Regionen.
- EF: Realtime Class-Type mit strikten Reserven und strikter Limitierung.
- AF (Video/Business): eigene Class-Types, um stabile Kapazität zu sichern.
- CS/Control: häufig separat geschützt über Queueing und nicht primär über große TE-Reserven.
- BE/Bulk: flexible Klassen, die Reserven nicht verdrängen dürfen.
Bandbreitenmodelle und Admission Control: DS-TE lebt von realistischen Budgets
DS-TE ist nur so gut wie die Budgets, die Sie definieren. Zu knappe Budgets führen zu häufigen LSP-Rejections oder Preemptions; zu großzügige Budgets entwerten den Schutzmechanismus, weil Premiumklassen unkontrolliert wachsen. In der Praxis werden Budgets aus Busy-Hour-Profilen, Produktverkäufen, Peak-Analysen und Failover-Headroom abgeleitet. Wichtig ist, nicht nur den Normalpfad zu modellieren: In Failover-Szenarien verschieben sich Flows, und DS-TE muss auch dort eine sinnvolle Priorisierung ermöglichen.
- Busy Hour: Budgets nach Spitzenzeiten dimensionieren, nicht nach Tagesmittelwert.
- Failover-Headroom: Reserven so planen, dass Schutzpfade nicht sofort überlaufen.
- Preemption-Regeln: definieren, welche LSPs verdrängt werden dürfen, wenn Premiumklassen Schutz brauchen.
- Rezertifizierung: Budgets regelmäßig an reale Nutzung und Produktentwicklung anpassen.
Scheduling bleibt relevant: DS-TE ersetzt QoS nicht
DS-TE steuert die Ressourcenvergabe und Pfadwahl, aber es ersetzt nicht die Per-Hop Behandlung. Auch wenn Premiumklassen ihre TE-Reserven haben, können Mikrobursts und kurzfristige Staus auftreten, insbesondere an Aggregationspunkten oder Übergängen. Deshalb muss Scheduling weiterhin sauber sein: limitierte LLQ für Voice, gewichtete Klassen für Video/Business, AQM/ECN für Best Effort zur Latenzstabilisierung. DS-TE sorgt dafür, dass die Voraussetzungen stimmen – Scheduling sorgt dafür, dass das Verhalten im Engpass korrekt ist.
- LLQ-Limits: strikt, damit Echtzeit nicht andere Klassen aushungert.
- Gewichtete Queues: stabile Fairness und Mindestanteile für Video/Business.
- AQM/ECN: Bufferbloat reduzieren, RTT-Spitzen senken, Throughput erhalten.
- Shaping: Bursts glätten und Congestion in kontrollierbare Queues holen.
Failover und Wartung: DS-TE muss im Worst Case getestet werden
DS-TE wird oft eingeführt, um Worst-Case-Szenarien besser zu beherrschen. Genau deshalb müssen diese Szenarien auch getestet werden: Link-Ausfälle, Node-Ausfälle, geplante Maintenance und TE-Reoptimierungen. Dabei zeigt sich, ob Preemption-Regeln sinnvoll sind, ob Budgets realistisch sind und ob die Kombination aus TE-Reserven und Queueing tatsächlich Voice/Video stabil hält. Ein häufiger Fehler ist, DS-TE nur im Normalbetrieb zu validieren – dort wirkt es oft „unsichtbar“, weil genügend Kapazität vorhanden ist.
- Link/Node Failure Tests: unter Mischlast, nicht nur im Leerlauf.
- Maintenance Windows: simulieren, wie Traffic auf weniger Pfade wandert.
- Preemption-Analyse: prüfen, welche Services verdrängt werden und ob das produktseitig akzeptabel ist.
- QoE-Korrelation: Voice/Video-KPIs (Loss/Jitter/MOS) mit TE-Events verbinden.
Messbarkeit: Wie Sie DS-TE Wirkung nachweisen
DS-TE ist ein Steuerungsmechanismus – daher muss er messbar sein. Neben klassischen QoS-KPIs (Queue-Delay/Drops pro Klasse) brauchen Sie TE-spezifische Sicht: Wie sind Reserven pro Class-Type ausgelastet? Wo werden LSPs abgewiesen? Wo finden Preemptions statt? Wie verändern sich Pfade bei Reoptimierungen? Erst durch diese Daten wird klar, ob DS-TE wirklich Premiumklassen schützt oder nur zusätzliche Komplexität erzeugt. In Betriebssicht ist eine domänenscharfe Darstellung hilfreich: pro Link-Bundle, pro Region, pro Congestion Domain.
- TE-Reservationen: Auslastung der Klassenbudgets pro Link.
- Admission Events: Rejections/Preemptions als harte Signale für Budget-Engpässe.
- Queue Health: Delay und Drops pro Klasse an kritischen Links, besonders im Failover.
- Event-Korrelation: TE-Reoptimierung und FRR mit QoS- und QoE-Abweichungen verknüpfen.
Typische Failure Patterns bei DS-TE
DS-TE kann sehr wirksam sein, aber auch scheitern, wenn Grundlagen fehlen. Häufige Muster sind: zu viele Klassen, inkonsistente Mappings zwischen DSCP/TC und TE-Class-Types, Budgets ohne Bezug zu realen Traffic-Profilen oder Preemption-Regeln, die produktseitig nicht tragbar sind. Ebenfalls kritisch: DS-TE wird eingeführt, aber Congestion sitzt in der Aggregation oder am Interconnect, wo TE-Reserven nicht greifen – dort braucht es Shaping und sauberes Queueing.
- Klassenexplosion: zu viele Class-Types, Betrieb wird unbeherrschbar.
- Mapping Drift: DSCP/TC sagt „Voice“, TE-Class-Type sagt etwas anderes; QoS und TE laufen auseinander.
- Budget-Falschschnitt: Reserven zu knapp oder zu großzügig; Rejections oder Entwertung des Schutzes.
- Preemption-Schäden: wichtige Services werden verdrängt, weil Prioritäten falsch gewählt sind.
- Falscher Engpass: Congestion liegt am Interconnect/Edge, nicht im TE-gesteuerten Core.
Blueprint: DS-TE als integriertes QoS+TE Design aufsetzen
Ein robustes DS-TE Design beginnt mit einem schlanken Serviceklassenmodell und einer klaren DiffServ-Strategie (DSCP/TC/PHB). Danach definieren Sie wenige TE-Class-Types, die diese Serviceklassen abbilden, und legen Budgets pro Link und pro Class-Type fest – basierend auf Busy Hour und Failover-Headroom. Anschließend koppeln Sie die Kette technisch: DSCP→TC am Edge, TC→PHB im Core, Serviceklasse→Class-Type im TE, inklusive konsistenter Templates. Preemption-Regeln werden produktseitig abgestimmt und unter Last getestet. Abschließend etablieren Sie Telemetrie: Reservation-Auslastung, Admission Events, Queue-Delay/Drops und QoE-Korrelation. So verbindet DS-TE Klassen mit TE nicht als Zusatzfeature, sondern als kontrollierbares System, das Premiumdienste auch in dynamischen Netzen planbar schützt.
