Remarking Policies sind im Telco-Betrieb der zentrale Sicherheitsgurt für QoS: Sie sorgen dafür, dass Kunden-Markings zwar genutzt werden können, aber nicht das Netz destabilisieren. In einem Provider-Netz kann grundsätzlich jeder Kunde DSCP/CoS-Werte setzen – absichtlich (um „bessere Priorität“ zu bekommen) oder unabsichtlich (durch falsche VoIP-Profile, UC-Clients oder CPE-Defaults). Wenn diese Markierungen ungeprüft übernommen werden, entstehen typische Probleme: Premium-Queues werden überflutet, Echtzeitklassen verlieren ihre Wirkung, Best Effort wird unberechenbar, und SLAs lassen sich nicht mehr sauber nachweisen. Genau deshalb ist „Kunden-Markings sicher normalisieren“ kein Nice-to-have, sondern Pflicht. Remarking bedeutet dabei nicht nur „alles auf DSCP 0 setzen“, sondern ein kontrolliertes Übersetzungs- und Durchsetzungsmodell: erlaubte Markings per Allowlist akzeptieren, auf interne Klassen mappen, Profile pro Klasse erzwingen, Überschreitungen gezielt degradieren und alles messbar machen – inklusive Zähler, Drops, Queue-Delay und Audit-Reports. Dieser Artikel zeigt, wie Remarking Policies in Telco-Netzen praxisnah aufgebaut werden, welche Strategien sich bewährt haben und wie Sie den Spagat zwischen Servicequalität und Missbrauchsschutz zuverlässig schaffen.
Warum Kunden-Markings ohne Normalisierung gefährlich sind
QoS funktioniert nur, wenn Markierungen eine konsistente Bedeutung haben. In Multi-Tenant-Netzen ist das ohne Kontrolle unmöglich: Ein einzelner Kunde könnte den gesamten Datenverkehr als EF (Echtzeit) markieren. Selbst wenn der Provider eine LLQ nutzt, wird diese dann zur Best-Effort-Queue – nur mit höherer Priorität. Dadurch verhungern andere Klassen, Queue-Delay steigt, Jitter explodiert und die Stabilität des Netzes leidet. Zusätzlich wird Troubleshooting schwierig: Wenn DSCP-Verteilungen nicht mehr „gesund“ sind, sind Drops und Delay nicht mehr sinnvoll interpretierbar.
- Premium-Queue Flooding: falsche EF/AF-Markings fluten priorisierte Queues.
- Starvation: andere Klassen erhalten zu wenig Sendezeit, Services werden instabil.
- SLA-Unschärfe: ohne definierte Marking-Scopes ist unklar, was überhaupt garantiert wurde.
- Operative Blindheit: Monitoring-KPIs verlieren Aussagekraft, wenn die Klassengrenzen „verwischen“.
Remarking im Kontext: Trust Boundary, Allowlist und Profile
Remarking ist ein Teil des Trust Boundary Designs. Eine Trust Boundary definiert, wo Markierungen akzeptiert werden – und wo das Netz entscheidet, sie zu normalisieren. Remarking Policies setzen diese Entscheidung technisch um. Dabei sind drei Bausteine besonders wichtig: Erstens eine Allowlist, welche DSCP-Werte überhaupt zulässig sind. Zweitens ein Mapping, das zulässige Markings auf interne Traffic Classes abbildet. Drittens Profile, die pro Klasse Bandbreitenbudgets und Grenzwerte definieren. Ohne Profile wird Remarking schnell „kosmetisch“: Marking stimmt, aber die Nutzung bleibt unkontrolliert.
- Allowlist: nur definierte DSCP/PCP-Werte passieren, alles andere wird normalisiert.
- Mapping: DSCP-Werte werden eindeutig auf interne Klassen (Voice, Video, Business, BE, Bulk) gemappt.
- Profile: Budgets pro Klasse und Kunde/Service (z. B. EF max. X kbit/s) werden erzwungen.
- Messbarkeit: Remarking- und Policer-Zähler zeigen, ob Regeln greifen und ob Missbrauch stattfindet.
Remarking-Strategien: Normalize, Degrade oder Drop
In der Praxis gibt es drei grundlegende Strategien, um Kunden-Markings sicher zu normalisieren. Welche Sie wählen, hängt von Produkt, Risiko und Serviceziel ab. „Normalize“ setzt unerlaubte Werte auf Best Effort. „Degrade“ verschiebt überschüssigen oder unpassenden Traffic in eine niedrigere Klasse, statt ihn sofort zu verwerfen. „Drop“ ist die harte Kante und eignet sich vor allem gegen Missbrauch oder wenn Profile strikt eingehalten werden müssen. Für Echtzeit (Voice/Video) ist „Degrade“ häufig die bessere Nutzererfahrung als „Drop“, weil harte Drops sofort hörbar oder sichtbar sind.
- Normalize: unerlaubte DSCP-Werte werden auf DSCP 0 (Best Effort) gesetzt.
- Degrade: Überschreitungen werden in eine niedrigere Klasse ummarkiert (z. B. EF → AF/BE).
- Drop: Überschreitungen werden verworfen; effektiv, aber bei Echtzeit sofort spürbar.
Pragmatische Regel
- Unbekanntes Marking: normalize.
- Erlaubtes Marking über Budget: degrade (oder drop, wenn das Produkt es fordert).
- Offensichtlicher Missbrauch: drop plus Alarmierung.
EF ist Sonderfall: Warum Echtzeit-Markings fast immer begrenzt werden müssen
EF (Expedited Forwarding) steht in vielen QoS-Designs für Voice-Media (RTP). EF wird oft in einer Low-Latency Queue (LLQ) mit strikter Priorität bedient. Das ist leistungsfähig – und gefährlich. Deshalb ist eine Remarking Policy für EF fast immer „Trusted with Limits“: EF wird nur für definierte Services akzeptiert und strikt budgetiert. Alles, was außerhalb dieses Profils als EF kommt, wird normalisiert oder degradiert. Damit schützen Sie die Echtzeitqualität Ihrer echten Voice-Services und verhindern, dass EF zur Abkürzung für „alles“ wird.
- EF Allowlist: EF nur für definierte Produkte/Interfaces/VLANs erlauben.
- EF Budget: pro Kunde/Service begrenzen, damit LLQ stabil bleibt.
- EF Überschreitung: degrade (z. B. zu AF/BE) oder drop, abhängig vom Produkt.
- EF Monitoring: EF-Drops/Queue-Delay sind kritische Alarmsignale.
Mapping in interne Klassen: Kunden-Markings in ein Provider-Klassenmodell übersetzen
Remarking ist nicht nur „Reset“, sondern oft eine Übersetzung. Kunden nutzen DSCP-Werte unterschiedlich, manche markieren Voice als EF, manche als CS5, manche markieren alles als AF. Ein Provider muss das in ein eigenes Klassenmodell überführen, das über alle Domänen hinweg konsistent ist. Dafür ist eine zentrale Mapping-Matrix essenziell, die klar festlegt, welche externen DSCPs auf welche internen Klassen gemappt werden. Diese Matrix sollte bewusst klein sein: wenige erlaubte Eingangswerte und eindeutige Zielklassen.
- External DSCP: Werte, die vom Kunden kommen (Allowlist).
- Internal Class: interne Queue-Klasse im Provider-Netz (Voice/Video/Business/BE/Bulk).
- Internal DSCP/TC: interne Markierung, die netzweit gleich behandelt wird.
- Exception Handling: dokumentierte Ausnahmen mit Ablaufdatum, sonst driftet das System.
Per-Service und Per-Subscriber Remarking: Warum Kontext zählt
Die beste Remarking Policy nutzt Kontext: Wer ist der Kunde? Welches Produkt ist gebucht? Welche Serviceinstanz (VRF, VLAN, Tunnel) ist betroffen? In Broadband- und Wholesale-Szenarien ist Per-Subscriber QoS (häufig am BNG/PE) besonders wirksam, weil dort Identität und Profile vorliegen. In Business-Services ist Per-Service (z. B. pro VRF oder pro EVC) üblich. Der Vorteil: Marking wird nicht pauschal bewertet, sondern gegen das Serviceprofil geprüft.
- Per-Subscriber: ideal bei vielen Kunden auf Shared Access; verhindert Noisy Neighbor durch Profile pro Teilnehmer.
- Per-Service: sinnvoll bei Business-VRFs oder SIP-Trunks; klare Zuordnung zu SLA und Produkt.
- Per-Interface: als Fallback, wenn Kontext begrenzt ist, aber weniger präzise.
Hierarchisches QoS und Remarking: Degradieren statt zerstören
Eine elegante Art, Kunden-Markings sicher zu normalisieren, ist die Kombination aus HQoS (Hierarchical QoS) und Remarking. Dabei wird zuerst auf übergeordneter Ebene die Gesamtbandbreite pro Kunde/Service geformt (Shaping) und anschließend innerhalb dieser Rate pro Klasse priorisiert. Überschreitungen in Premiumklassen können dann gezielt degradiert werden, ohne sofort harte Drops zu erzeugen. Das stabilisiert Echtzeitqualität und reduziert Beschwerden, während das Netz trotzdem vor Missbrauch geschützt bleibt.
- Parent Shaper: kontrolliert Bursts und hält Congestion im eigenen Einflussbereich.
- Child Policies: priorisieren Voice/Video/Signaling innerhalb des Profils.
- Degrade-Mechanik: Überschreitungen werden in niedrigere Klassen ummarkiert statt gedroppt.
Remarking über Layer hinweg: DSCP, PCP, MPLS-TC und Overlays
Remarking Policies müssen in Telco-Netzen häufig mehr als DSCP betreffen. In Metro-Ethernet spielen PCP (802.1p) und VLAN-Tagging eine Rolle. Im Core werden DSCPs oft in MPLS-TC übersetzt. In Overlays (IPsec, GRE, SD-WAN) müssen Markierungen korrekt in den Outer Header übernommen werden, sonst sieht das Underlay Best Effort. Ein robustes Design definiert daher nicht nur DSCP-Remarking, sondern auch die Mappings und Copy-Regeln an Übergängen – und prüft sie regelmäßig.
- DSCP↔PCP: sicherstellen, dass L2-Queues die gleiche Klassenlogik tragen.
- DSCP↔MPLS-TC: Core-Transport muss interne Klassen konsistent weitertragen.
- Inner-to-Outer Copy: in Tunneln, damit Underlay-QoS greift.
- Interconnect: meist restriktiver; externe DSCPs werden häufig normalisiert oder in ein Interconnect-Profil gemappt.
Monitoring und Audit: Remarking nachweisbar machen
Eine Remarking Policy ist nur dann betrieblich wertvoll, wenn sie messbar ist. Das umfasst drei Ebenen: erstens DSCP-Verteilungen (was kommt rein, was geht raus?), zweitens Remarking-/Policer-Zähler (wie oft wird normalisiert oder degradiert?) und drittens Queue-KPIs (Drops/Delay pro Klasse). Besonders wichtig ist die Statistik: kurze Zeitfenster und Perzentile, damit Mikrobursts und „Bad Minutes“ sichtbar werden. So lässt sich auch revisionssicher nachweisen, dass Premiumklassen geschützt und Profile eingehalten wurden.
- Ingress vs. Egress DSCP: Vergleich zeigt, ob Remarking korrekt greift.
- Remarking Counters: Anzahl ummarkierter Pakete, getrennt nach Grund (unknown, over-budget).
- Policer Counters: Drops/remarked due to exceed; wichtig für Profilvalidierung.
- Queue Health: Queue-Delay und Drops in Voice/Video-Klassen zeigen echte Servicewirkung.
Typische Failure Patterns bei Remarking Policies
Remarking kann auch schaden, wenn es falsch designt oder inkonsistent ausgerollt wird. Häufige Fehler sind: zu aggressive Normalisierung (Echtzeit wird fälschlich zu Best Effort), fehlende Budgetierung (Trust ohne Limits), unklare Mapping-Tabellen oder asymmetrisches Remarking (nur eine Richtung). Ebenso problematisch ist Remarking ohne Shaping am Engpass: Dann passieren Drops beim Provider, während lokale Zähler „sauber“ aussehen.
- Over-Normalization: legitime Voice/Video-Markings werden gelöscht; QoE bricht ein.
- Trust ohne Limits: Premium-Queues wachsen unkontrolliert; LLQ wird instabil.
- Asymmetrie: Remarking nur im Upstream oder Downstream; Einweg-Audio und sporadische Probleme.
- Mapping Drift: unterschiedliche Geräte interpretieren DSCP verschieden; QoS-Löcher entstehen.
- Queue außerhalb: keine Shaping-Strategie, Drops beim Provider; eigene Policies greifen nicht wie gedacht.
Blueprint: Remarking Policies sicher und skalierbar einführen
Ein praxiserprobtes Vorgehen beginnt mit einem schlanken Provider-Klassenmodell und einer zentralen DSCP-Allowlist. Danach wird pro Produkt definiert, welche Markings überhaupt erlaubt sind, und es werden Profile pro Klasse festgelegt (insbesondere für EF). Anschließend werden Remarking-Regeln implementiert: unbekannte DSCPs normalisieren, erlaubte DSCPs mappen, Überschreitungen degradieren oder droppen – je nach Serviceziel. Parallel werden Shaping und HQoS an den echten Congestion Points etabliert, damit Drops kontrollierbar sind. Abschließend wird Monitoring aufgebaut, das Ingress/Egress DSCP, Remarking-Zähler und Queue-Health korreliert, sowie ein Rezertifizierungsprozess, der Drift erkennt. So werden Kunden-Markings nicht zum Risiko, sondern zu einem kontrollierten Signal, das QoS im Provider-Netz zuverlässig unterstützt.