QoS-Remarking ist im Telco- und Provider-Netz der praktische Schlüssel, um Kundenmarkierungen nicht blind zu übernehmen, aber trotzdem Premium-Services wie Voice, Video oder Business-Anwendungen zuverlässig zu transportieren. Während DSCP/CoS-Markierungen im Enterprise-LAN oft „intern“ bleiben, trifft der Provider an der Netzgrenze (UNI/NNI/PE) auf fremde Markierungen: von verwalteten UC-Plattformen über SD-WAN-CPEs bis hin zu beliebigen Endgeräten. Ohne Remarking gibt es zwei Extreme: Entweder werden Markierungen vollständig neutralisiert – dann verlieren korrekt markierte Echtzeitdienste ihre Priorität und SLAs werden schwer erfüllbar. Oder Markierungen werden ungeprüft vertraut – dann entsteht Premium-Inflation, weil zu viel Traffic als EF/AF markiert ist, und QoS kippt unter Last. Remarking löst dieses Dilemma, indem es Markierungen prüft, normalisiert und innerhalb definierter Profile „sauber“ umsetzt: Zulässige DSCP-Werte werden auf ein Provider-Klassenmodell gemappt, Überschuss wird auf eine niedrigere Klasse oder höhere Drop-Precedence herabgestuft, und unzulässige Markierungen werden auf Best Effort gesetzt. Dieser Artikel erklärt, wie QoS-Remarking in der Praxis funktioniert, wo es im Netz hingehört, welche Mappings sich bewährt haben und wie Sie Kundenmarkierungen so behandeln, dass Premium wirklich Premium bleibt – ohne den Betrieb mit zu vielen Sonderfällen zu überfrachten.
Warum Kundenmarkierungen im Provider-Netz nicht automatisch vertrauenswürdig sind
DSCP- und CoS-Markierungen sind schnell gesetzt – manchmal bewusst, manchmal aus Unwissen. Viele Betriebsteams erleben daher diese Realität:
- „Alles ist EF“: Endgeräte oder Applikationen markieren zu aggressiv, weil Profile falsch eingestellt sind oder weil ein Admin „auf Nummer sicher“ geht.
- Exotische DSCP-Werte: Kunden nutzen eigene DSCP-Schemata, die nicht zum Provider-Klassenmodell passen.
- Gemischte Quellen: In einem Standort laufen UC, Backups, Monitoring und Benutzertraffic über dieselbe Übergabe – Markierungen sind inkonsistent.
- Missbrauchspotenzial: Ohne Kontrolle könnte ein Kunde Premium missbrauchen und andere Kunden beeinträchtigen.
Ein Provider braucht daher eine klare Trust Boundary: Markierungen werden nur dann übernommen, wenn sie zu einem definierten Produkt und Profil passen. Alles andere wird remarkt.
Was QoS-Remarking genau ist – und was nicht
QoS-Remarking bedeutet, dass ein Gerät (meist an der Netzgrenze) eine bestehende Markierung prüft und durch eine neue Markierung ersetzt. Remarking kann dabei sowohl „nach unten“ als auch „nach oben“ passieren – in Telco-Designs ist jedoch das Herabstufen und Normalisieren der häufigste Anwendungsfall.
- Remarking: DSCP/CoS/MPLS-TC wird auf einen anderen Wert gesetzt, basierend auf Regeln.
- Classification: die Entscheidung, zu welcher Klasse ein Paket gehört (z. B. Voice, Video, Best Effort).
- Policing/Shaping: Durchsetzen von Bandbreitenprofilen bzw. Glättung von Bursts – häufig kombiniert mit Remarking.
Wichtig: Remarking allein macht noch kein QoS. Es sorgt „nur“ dafür, dass Markierungen im Provider-Netz konsistent und kontrollierbar sind. Die eigentliche Qualität entsteht über Queues, Scheduler, Limits und Shaping.
Die drei Kernziele von Remarking im Telco-Netz
- Normalisierung: Kundenmarkierungen auf ein kleines Provider-Klassenmodell reduzieren (z. B. 5–7 Klassen).
- Schutz vor Premium-Inflation: verhindern, dass zu viel Traffic in EF/High-AF landet.
- SLA-Umsetzbarkeit: sicherstellen, dass vertraglich zugesicherte Klassen auch wirklich als solche transportiert werden.
Wenn diese Ziele erfüllt sind, wird QoS operational: Sie können pro Klasse messen, Profile anwenden und SLAs sauber nachweisen.
Wo Remarking hingehört: Die richtigen Stellen im Provider-Netz
Remarking ist am effektivsten an klaren Grenzen, an denen Traffic in eine neue Domäne eintritt. Typische Orte:
- UNI am Provider Edge: Kundenübergabe (Business Access, Wholesale, Mobile Backhaul) – hier ist der klassische Remarking-Punkt.
- Managed CPE: wenn der Provider die CPE kontrolliert, kann Remarking bereits beim Kunden stattfinden.
- NNI/Interconnect: Übergaben zu Partnern/Carriern – hier wird häufig auf vertraglich definierte Klassen normalisiert.
- Overlay-Grenzen: EVPN/VXLAN-Tunnel Ingress oder Cloud-Edge, wenn inner/outer DSCP gemappt werden muss.
Im Core selbst sollte Remarking möglichst selten passieren. Der Core transportiert Klassen; die Grenzlogik gehört an den Rand.
Trust-Modelle als Grundlage: Untrusted, Trusted, Conditional Trust
Remarking wird durch das Trust-Modell bestimmt:
- Untrusted: Alle Kundenmarkierungen werden auf Default gesetzt; Premium nur über managed Mechanismen.
- Trusted: Markierungen werden übernommen; nur sinnvoll bei streng kontrollierten Quellen.
- Conditional Trust: Markierungen werden akzeptiert, aber nur innerhalb definierter Profile; Überschuss wird remarkt oder begrenzt.
In der Praxis ist Conditional Trust am häufigsten, weil es Premium ermöglicht, ohne das Netz für Missmarkierung zu öffnen.
Ein sinnvolles Provider-Klassenmodell als Ziel für Remarking
Damit Remarking nicht in beliebige Einzelfälle ausartet, brauchen Sie ein Zielmodell: wenige Klassen, klare Bedeutungen. Ein praxisnahes Telco-Basismodell ist:
- Voice Media: EF/Real-Time (LLQ, strict priority mit Limit).
- Voice Signaling/Control: hoch priorisiert, aber gewichtet.
- Interaktives Video: AF-Klasse, gewichtet, mit garantierten Anteilen.
- Business Critical: definierte Mindestanteile (optional, je nach Produkt).
- Best Effort: Standardverkehr.
- Background/Scavenger: niedrig priorisiert.
Remarking bedeutet dann: Kundenwerte werden auf diese Klassen gemappt – und nicht 1:1 durchgereicht.
Remarking-Strategien: Welche Muster sich bewährt haben
In Provider-Netzen haben sich drei Remarking-Muster etabliert. Sie können sie kombinieren, sollten aber klar definieren, wann welches Muster gilt.
Whitelist-Remarking: nur erlaubte Markierungen passieren
Sie definieren eine Liste zulässiger DSCP/CoS-Werte. Nur diese werden übernommen oder in Providerklassen gemappt, alles andere wird auf Best Effort gesetzt.
- Vorteil: sehr robust, klare Regeln, geringe Komplexität.
- Nachteil: Kunden mit abweichenden DSCP-Schemata müssen angepasst werden.
Mapping-Remarking: viele Kundencodes auf wenige Providerklassen
Sie mappen Kundencodes auf Providerklassen. Beispiel: mehrere „Video“-Codes werden auf eine AF-Videoklasse reduziert, mehrere „Business“-Codes auf eine Businessklasse.
- Vorteil: flexibel, kompatibel mit heterogenen Kunden.
- Nachteil: braucht saubere Dokumentation und Tests, sonst entstehen Mapping-Drifts.
Profile-basiertes Remarking: In-Profile bleibt, Out-of-Profile wird herabgestuft
Dieses Muster ist ideal für Premium: Verkehr darf markiert sein, aber nur bis zu einem Budget. Überschuss wird nicht sofort gedroppt, sondern in eine niedrigere Klasse oder höhere Drop-Precedence gesetzt.
- Vorteil: Premium bleibt stabil, Überschuss wird kontrolliert behandelt.
- Nachteil: benötigt Policer/Shaper und gute Messbarkeit.
Policing und Remarking: Herabstufen statt droppen
Viele Telco-Designs nutzen Policing nicht primär zum Droppen, sondern als „Gatekeeper“ für Premium-Klassen. Der wichtigste Grund: Drops sind für Echtzeit (Voice) und interaktives Video sofort spürbar. Deshalb ist das bewährte Muster:
- Voice: möglichst nicht droppen; Profile so dimensionieren, dass Voice selten in Out-of-Profile läuft. Wenn überhaupt, sehr konservativ und bevorzugt über klare Budgets.
- Video: Überschuss wird remarkt (z. B. AFx1 → AFx3 oder AF → Best Effort), statt hart gedroppt zu werden.
- Best Effort: kann härter begrenzt werden, aber auch hier ist Shaping oft QoE-freundlicher als Drop-Cluster.
Remarking ist damit ein QoE-freundliches Steuerinstrument: Premium bleibt erhalten, Überschuss wird „abgefedert“, statt abrupt zu kollabieren.
AF Drop Precedence als Remarking-Hebel für Video
Assured Forwarding (AF) bietet innerhalb einer Klasse drei Drop Precedences (x1/x2/x3). Das ist ideal für Video, weil Sie damit In-Profile und Überschuss unterscheiden können, ohne komplett die Klasse zu wechseln.
- AFx1: In-Profile Video, am besten geschützt.
- AFx2: moderater Überschuss, höher droppable.
- AFx3: klarer Überschuss/out-of-profile, wird bei Congestion zuerst verworfen.
In Kombination mit WRED/Congestion Avoidance können Sie so sehr elegant steuern: Kernvideo bleibt stabil, Überschuss wird zuerst abgefangen.
DSCP, CoS und MPLS-TC: Remarking endet nicht beim IP-Header
Provider-Netze sind meist multi-layer. Remarking muss daher nicht nur DSCP setzen, sondern auch die Übersetzung in andere Markierungswelten berücksichtigen.
- Ethernet/CoS: In Access- und Metro-Ethernet-Segmenten entscheidet oft CoS/802.1p über Hardware-Queues. DSCP-Remarking ohne CoS-Mapping kann wirkungslos sein.
- MPLS-TC/EXP: Im MPLS/SR-Core wird häufig nach TC gequeued. DSCP muss am PE in TC übersetzt werden.
- Overlay (EVPN/VXLAN): Underlay queuet oft nach äußerem Header. Inneres DSCP muss propagiert oder policy-basiert gemappt werden.
Eine saubere Remarking-Policy beschreibt daher immer auch das Mapping: DSCP → CoS → MPLS-TC – konsistent, getestet und dokumentiert.
Typische Fehler bei QoS-Remarking – und ihre Auswirkungen
- Zu großzügiges Trust: Premium-Inflation, LLQ wird „fett“, Best Effort verhungert, Netz wird unberechenbar.
- Alles auf Best Effort setzen: Voice/Video verlieren Schutz, SLAs werden faktisch unmöglich.
- Inkonsequentes Mapping: DSCP wird remarkt, aber CoS/TC nicht; im nächsten Segment landet Traffic in falschen Queues.
- Policing mit Drops auf Echtzeit: Voice knackt, Video friert ein; Drops kommen in Clustern.
- Keine Profiltransparenz: Kunden laufen ständig out-of-profile, ohne es zu wissen; Beschwerden häufen sich.
- Drift durch Einzelkonfiguration: unterschiedliche Remarking-Regeln auf unterschiedlichen PEs erzeugen QoS-Löcher.
Remarking muss standardisiert sein. Einmalige „Sonderlösungen“ sind im Providerbetrieb langfristig fast immer teurer als ein sauberer Standard.
Monitoring: Remarking im Betrieb messbar machen
Damit Remarking nicht zur Blackbox wird, brauchen Sie Metriken an der Netzgrenze:
- Traffic pro Klasse: wie viel EF/AF/BE kommt rein und wie viel geht raus?
- Remarking-Events: wie viel Traffic wird von Premium nach unten gestuft?
- Policer-Hits: welche Kunden/Ports laufen out-of-profile und in welchen Klassen?
- Queue-Drops pro Klasse: insbesondere Voice/Video; Drops sind Qualitätsindikatoren.
- QoE-Korrelation: MOS/R-Faktor, Audio-Interruptions, Video-Freeze-Events – besonders bei managed Services.
Ein operativer Leitsatz ist: Wenn Premium-Volumen steigt oder Remarking sprunghaft zunimmt, prüfen Sie Trust Boundary und Kundenprofile, bevor Sie „mehr Bandbreite“ kaufen.
Praxis-Blueprint: Kundenmarkierungen prüfen und sauber umsetzen
- Provider-Klassenmodell festlegen: wenige Klassen, klare Bedeutungen (Voice EF, Video AF, Control, Best Effort, Background).
- Trust-Modell pro Produkt definieren: Retail untrusted, Business conditional trust, Wholesale vertraglich strikt.
- Whitelist und Mapping bauen: erlaubte DSCP/CoS-Werte, Normalisierung auf Providerklassen.
- Profilierung integrieren: Budgets pro Klasse, Überschuss bevorzugt remarken statt droppen.
- End-to-End Mapping sicherstellen: DSCP → CoS → MPLS-TC/EXP konsistent über Access/Metro/Core.
- Templates standardisieren: gleiche Policies pro PE/Plattformklasse, versioniert und getestet.
- Monitoring verpflichtend: Traffic/Remarking/Policer/Drops pro Klasse in Dashboards.
Häufige Fragen zu QoS-Remarking
Ist Remarking nicht „gegen den Kunden“?
Nein. Remarking ist ein Stabilitätsmechanismus. Es schützt Premium-Services vor Missbrauch und sorgt dafür, dass SLAs für die Kunden funktionieren, die Premium tatsächlich gebucht haben. Ohne Remarking würde Premium unter Last verwässern.
Sollte ich Überschuss lieber droppen oder remarken?
Für Video ist Remarking oft besser, weil es Drop-Cluster reduziert und QoE stabiler bleibt. Für Voice sollte Oversubscription möglichst vermieden werden; Drops auf Voice-Medien sind sofort hörbar. In vielen Designs wird Voice so dimensioniert, dass es kaum out-of-profile läuft.
Was ist der wichtigste Erfolgsfaktor?
Konsistenz: ein klares Klassenmodell, definierte Trust Boundaries, profilierte Budgets und ein sauberes Mapping über DSCP/CoS/MPLS-TC hinweg. Wenn diese Punkte stimmen, wird Remarking zu einem kontrollierten, SLA-fähigen Werkzeug statt zu einer Quelle von „QoS-Löchern“.