QoS Dokumentation ist der Teil von Quality of Service, der aus einer technischen Konfiguration ein belastbares Betriebssystem macht. In vielen Netzwerken existiert QoS „irgendwie“: ein paar Policies, ein paar DSCP-Werte, vielleicht eine Voice-Queue. Sobald aber mehrere Standorte, mehrere Provider, SD-WAN, WLAN und Security-Stacks zusammenkommen, entsteht ohne Dokumentation ein bekanntes Muster: Niemand weiß mehr zuverlässig, welche Klasse wofür steht, wo Markierungen trusted werden, wie DSCP zu Queues gemappt ist und welche Werte im Fehlerfall „normal“ sind. Genau dann werden Troubleshooting, Audits und Changes riskant. Eine gute QoS Dokumentation besteht deshalb aus drei Kernartefakten: einem Klassenmodell (Semantik und Intent), Mapping Tabellen (DSCP/CoS/WMM/MPLS-TC als Source of Truth) und einem Betriebshandbuch (Runbooks, Monitoring, Gates, Tests, Evidence). Diese Dokumente sind nicht „nice to have“, sondern die Grundlage für Skalierung, Interoperabilität und E-E-A-T im Betrieb: Sie zeigen Expertise, schaffen Vertrauen und machen QoS nachvollziehbar. Dieser Artikel erklärt, wie Sie QoS Dokumentation aufbauen, welche Inhalte zwingend hinein müssen, wie Sie sie wartbar halten und wie Sie daraus Standards, Review-Gates und ein echtes NOC-taugliches Betriebshandbuch ableiten.
Warum QoS Dokumentation in der Praxis so oft fehlt – und was das kostet
QoS wird häufig projektgetrieben eingeführt: ein Voice-Outage, eine UCaaS-Migration, ein neuer Provider. Die Konfiguration landet auf Geräten, aber die semantische „Quelle der Wahrheit“ fehlt oder veraltet. Das kostet später Zeit und Qualität: Fehlerbilder werden schwer reproduzierbar, Multi-Vendor-Drift bleibt unentdeckt, und Änderungen werden zur Mutprobe. Eine gute Dokumentation wirkt wie ein Sicherheitsgurt: Sie reduziert Betriebsrisiko, beschleunigt Root-Cause-Analysen und ermöglicht Compliance-Nachweise.
- Ohne Klassenmodell: Teams diskutieren über Begriffe („Voice“, „Realtime“, „Premium“) statt über messbare Intents.
- Ohne Mapping-Tabellen: DSCP driftet, und dieselbe Markierung landet in unterschiedlichen Queues.
- Ohne Betriebshandbuch: NOC reagiert reaktiv, Alerts sind unscharf, und Postmortems führen nicht zu Standards.
Dokumentations-Architektur: Drei Artefakte, ein gemeinsames Ziel
Ein häufiger Fehler ist, QoS Dokumentation als „ein Word-Dokument“ zu sehen. Besser ist ein klarer Dreiklang, der auch in großen Organisationen skaliert:
- Klassenmodell (Policy Intent): beschreibt, was das Netz erreichen soll.
- Mapping Tabellen (Source of Truth): beschreiben, wie Markierungen über Domänen übersetzt werden.
- Betriebshandbuch (Operations): beschreibt, wie QoS im Alltag überwacht, getestet und geändert wird.
Diese Artefakte müssen versioniert, referenzierbar und auditierbar sein. Die Konfigurationen auf Geräten sind dann nur die Implementierung dieser Dokumente, nicht umgekehrt.
Das Klassenmodell: Semantik, Intent und Guardrails
Das Klassenmodell ist das Herzstück. Es definiert die logischen Traffic-Klassen, ihre Prioritäten und ihre Grenzen. Wichtig ist dabei nicht, möglichst viele Klassen zu erfinden, sondern wenige robuste Klassen so zu definieren, dass sie in allen relevanten Domänen abbildbar sind (Access, WAN, WLAN, VPN/SD-WAN, Core, Interconnect). Für Voice/Video/RTC hat sich ein Modell mit 4–6 Klassen bewährt. Ihre Dokumentation sollte pro Klasse mindestens folgende Inhalte enthalten: Zweck, typische Anwendungen/Flows, Markierungen, Scheduling-Intent, Bandbreiten- und Drop-Strategie sowie „Never Events“.
- VOICE/AUDIO: Audio und Sprachmedien; strikt priorisiert, aber begrenzt; Ziel ist minimaler Queue Delay.
- MEDIA/VIDEO: interaktives Video und Medien; hohe Priorität, aber limitiert; darf Voice nicht verdrängen.
- SIGNAL/CONTROL: SIP/DTLS/ICE/Control-Plane-nahe Flows; kleine stabile Klasse für Setup und Stabilität.
- BESTEFFORT: Standardtraffic; trägt bei Congestion kontrolliert Delay/Drops.
- BULK/BACKGROUND: Updates/Backups/Downloads; gedrosselt und „opferbar“.
- CRITICAL (optional): geschäftskritische Daten, bevorzugt aber nicht strict.
Was in jede Klassenbeschreibung gehört
- Definition: klare Abgrenzung, was rein darf und was nicht.
- QoS-Ziel: z. B. „niedriger Jitter“, „kontrollierte Degradation“, „Setup-Stabilität“.
- Markierung: erlaubte DSCP-Werte (und ggf. CoS/WMM/MPLS-TC).
- Scheduling-Intent: strict priority vs. weighted, Mindest-/Max-Anteile, Buffer-Strategie.
- Guardrails: Never Events (z. B. Video in Voice-LLQ, Policer auf Voice, unlimitierte Priority).
- Beobachtbarkeit: welche KPIs pro Klasse im NOC sichtbar sein müssen (Delay 99p, Drops, Reasons).
Trust Boundary: Ein eigenes Kapitel, nicht ein Nebensatz
Die beste Markierung nützt nichts, wenn Sie nicht definieren, wo sie trusted wird. Gleichzeitig ist blindes Trust gefährlich (Marking Abuse). Deshalb sollte die QoS Dokumentation ein eigenes Kapitel zur Trust Boundary enthalten: welche Endgeräte/Segmente dürfen markieren, wo wird normalisiert, wo wird re-marked, und wie wird Missmarking im Betrieb erkannt. Hier sollten Sie auch Sonderfälle dokumentieren: BYOD, Guest WLAN, Drittanbieter-Devices, externe Partnernetze, Provider-Übergaben.
- Trusted: IP-Telefone, Room Systems, managed Endpoints, definierte UC-Gateways.
- Conditional Trust: Trust nur bei NAC-Rolle oder bestimmten Ports/VLANs/SSIDs.
- Untrusted: Normalisierung auf Best Effort, Whitelist-Strategien.
- Monitoring: Default/Unmatched Drift und Re-Marking-Counter als Pflichtsignale.
Mapping Tabellen: DSCP/CoS/WMM/MPLS-TC als Source of Truth
Mapping Tabellen sind das zweite Kernartefakt und häufig die größte Driftquelle. Die Tabelle muss klar, vollständig und versioniert sein. Sie sollte mindestens DSCP, 802.1p/CoS, WMM-Kategorie und MPLS Traffic Class (TC/EXP) abbilden – sofern diese Technologien im Netz vorkommen. Zusätzlich sollte sie die Zuordnung zur logischen Klasse enthalten. Der Nutzen ist enorm: Sie können Multi-Vendor-Konsistenz prüfen, Interworking an Domänengrenzen sauber definieren und Troubleshooting beschleunigen, weil „DSCP X bedeutet überall Klasse Y“ gilt.
- Spaltenbeispiele: Logische Klasse, DSCP, CoS, WMM, MPLS-TC, Queue-Name/Queue-ID je Plattformrolle.
- Whitelist-Prinzip: nur definierte Markierungen sind zulässig; alles andere wird normalisiert.
- Domain-Grenzen: explizite Mapping-Regeln an Edge/Interconnect, statt implizites „Durchreichen“.
- Versionierung: Änderungen am Mapping sind Change-relevant und benötigen Regression/Canary.
Typische Mapping-Fallen, die Sie in der Tabelle adressieren sollten
- Voice vs. Video: klare Trennung, damit Media nicht Voice verdrängt.
- WLAN WMM: DSCP muss konsistent in WMM Voice/Video gemappt werden, sonst verliert Funk die Priorisierung.
- MPLS TC Interworking: DSCP↔TC muss in allen PE/Core-Knoten gleich sein, sonst entstehen Klassen-Sprünge.
- VPN Outer Header: definieren, wie Inner DSCP auf Outer DSCP gemappt wird (Copy/Map/Rewrite).
Konfigurationsreferenz: Templates, Naming und „wo gilt was“
Dokumentation wird erst operativ, wenn sie den Bezug zur Implementierung herstellt. Sie müssen nicht jede Zeile jeder Vendor-Konfiguration dokumentieren, aber Sie sollten klar definieren, welche Templates existieren (nach Rollen), wie sie heißen, welche Versionen es gibt und an welchen Interfaces sie gebunden sind. Das vermeidet das häufigste QoS-Problem im Feld: Policy existiert, ist aber nicht am richtigen Egress attachiert.
- Rollen-Templates: Access, WLAN, WAN-Edge, VPN/SD-WAN, Core, Interconnect, Security.
- Naming-Konventionen: konsistente Klassen- und Policy-Namen für Telemetry und Counter Reports.
- Attachment-Regeln: „WAN Egress immer“, „Underlay Egress für SD-WAN“, „PoP-Uplink für Metro“.
- Guardrail-Regeln: verbotene Konfigurationen als „Never Events“.
Das Betriebshandbuch: Runbooks, Messpunkte und Troubleshooting-Pfade
Das Betriebshandbuch ist der Teil der QoS Dokumentation, den das NOC täglich braucht. Es beschreibt nicht nur „wie QoS gedacht ist“, sondern wie man damit arbeitet: Welche Dashboards sind Pflicht, welche Alerts sind high-signal, welche Playbooks führen von Symptom zu Root Cause, und welche Daten müssen für Evidence Packs gesammelt werden. Ein gutes Handbuch ist kurz genug, um genutzt zu werden, aber präzise genug, um Entscheidungen zu treffen.
- NOC-Panels: Queue Delay/Depth (95p/99p), Per-Class Drops, Drop Reasons, Shaper-Headroom, Default/Unmatched.
- Service-KPIs: RTP/WebRTC Jitter/Loss/MOS, Freeze/Downshift (Video), Setup Times (Signal).
- Playbooks: Congestion vs. Mis-Marking vs. Policer vs. VPN Outer DSCP vs. WLAN Airtime vs. Security/Compute.
- Evidence Packs: welche Counter/Exports/Telemetry bei Incidents gespeichert werden müssen.
Monitoring- und Alert-Design im Handbuch: High-Signal statt Alarmflut
QoS Alerts scheitern oft an zu vielen, zu unscharfen Schwellen. Das Betriebshandbuch sollte daher klare Guardrails definieren, die echte Handlungsrelevanz haben. Für Echtzeit sind das meist Perzentile und „Never Events“. Ein Alarm sollte „was, wo, warum“ enthalten: Klasse, Interface/Standort, Drop Reason und idealerweise einen Drilldown auf Zeitreihen.
- Early Warning: Voice/Media Queue Delay 99p über Schwelle mit Persistenz.
- Incident: Drops in VOICE oder Policer Drops in Echtzeitklassen.
- Mis-Marking: Default/Unmatched Drift parallel zu QoE-Verschlechterung.
- Capacity Risk: Shaper-Headroom dauerhaft niedrig, bevor Drops auftreten.
Change- und Review-Gates: Dokumentation als Teil des Lifecycle
QoS Dokumentation muss sich ändern dürfen – aber kontrolliert. Deshalb gehört in das Betriebshandbuch ein Abschnitt zu Review-Gates und Change Safety: Welche Änderungen sind „high risk“ (Mapping, Shaper-Rate, LLQ-Limits, VPN DSCP Copy, SD-WAN Steering)? Welche Regression Tests sind Pflicht? Wie sieht ein Canary Rollout aus? Und wie wird Rollback durchgeführt? So verhindern Sie QoS-Drift und „silent regressions“.
- Review-Gates: Congestion Domains, Attachment, Trust Boundary, Mapping, Shaping, Never Events.
- Regression Suite: Mechanik (Classifier/Mappings) + Congestion-Proof (Voice stabil unter Last).
- Canary Rollout: progressive Ausweitung mit Stop-Regeln (Voice Drops, Policer Drops, Delay 99p).
- Rollback: versionierte Templates, atomarer Switch, KPI-Rückkehr zur Baseline.
Dokumentation für VPN/SD-WAN und Overlays: DSCP inner/outer explizit machen
Ein häufiger Dokumentationsfehler ist, Overlays zu „vergessen“. In VPN QoS ist der Outer Header entscheidend. Das Handbuch sollte daher eine klare Regel enthalten: Wie wird Inner DSCP auf Outer DSCP kopiert oder gemappt? Wo sitzt das Underlay-Shaping? Welche Underlays existieren (Internet/MPLS/LTE/5G), und wie unterscheiden sich deren Profile? Ohne diese Klarheit sind VPN-bezogene Voice/Video-Probleme schwer zu beweisen.
- Copy/Map/Rewrite: definierte Strategie für Inner→Outer DSCP.
- Underlay Egress: QoS und Shaping am Underlay-Egress, nicht nur am Tunnelinterface.
- Steering-Regeln: Echtzeit darf nicht auf Pfade ohne QoS-Reserven wechseln.
Dokumentation für WLAN: WMM, Airtime und SSID-Rollen
Wenn Voice/Video über WLAN laufen, muss Dokumentation Funkrealität abbilden. Neben DSCP→WMM Mapping sollten Airtime-bezogene KPIs und SSID-Rollen beschrieben sein: Corporate Voice/RTC vs. Guest/BYOD, Roaming-Erwartungen, Retry-Schwellen. Das macht WLAN-QoS betriebssicher und verhindert, dass LAN-Teams und WLAN-Teams aneinander vorbeireden.
- WMM Mapping Tabelle: DSCP↔WMM als Teil der Mapping-Matrix.
- Airtime-Runbook: wie Airtime Utilization und Retries in QoE übersetzt werden.
- SSID/Rollen: Trust Boundary und Prioritäten pro SSID dokumentiert.
Qualitätskriterien: Wann QoS Dokumentation „gut“ ist
- Vollständig: Klassenmodell, Mapping, Trust Boundary, Templates/Attachments, Betrieb/Monitoring.
- Versioniert: jede Änderung ist nachvollziehbar (V1/V2), inklusive Datum und Verantwortlichkeit.
- Auditierbar: Evidence Packs (Config Exports, Counter Reports, Telemetry-Auszüge) sind definiert.
- Operativ: NOC kann mit dem Handbuch Incidents abarbeiten, ohne Expertenrunden.
- Skalierbar: Multi-Vendor-Interop und neue Standorte lassen sich konsistent integrieren.
Pragmatische Strukturvorlage für Ihre QoS Dokumentation
- Teil A – Klassenmodell: Ziele, Klassen, Semantik, Scheduling-Intent, Limits, Never Events, Beispiele.
- Teil B – Mapping Tabellen: DSCP/CoS/WMM/MPLS-TC Matrix, Interworking-Regeln, Whitelist, Übergaben.
- Teil C – Trust Boundary: trusted/untrusted, Re-Marking, Missmarking-Schutz, Monitoring.
- Teil D – Templates & Attachments: Rollen-Templates, Naming, Versionen, Interface-Bindungen, Overlays.
- Teil E – Betriebshandbuch: Dashboards, Alerts, Playbooks, PCAP/RTP-Tools, Evidence Packs.
- Teil F – Lifecycle: Review-Gates, Regression Tests, Canary Rollouts, Rezertifizierung, Compliance Audits.
