Multi-Domain QoS ist die Königsdisziplin im Carrier- und Telco-Umfeld, weil sie über die eigene administrative Domäne hinausgeht: QoS muss über Providergrenzen hinweg koordiniert werden, obwohl Marking-Semantik, Kapazitätsmodelle, Betriebsprozesse und Messmethoden zwischen Netzen variieren. In der Praxis ist genau das der Unterschied zwischen „QoS intern sauber“ und „QoS end-to-end verlässlich“. Sobald ein Service mehrere Provider durchläuft – etwa bei Wholesale-Backhaul, internationalen MPLS-VPNs, SIP-Trunking über Partner, Mobile Roaming-Transport oder Business-Connectivity mit mehreren Carriern – reicht es nicht, DSCP zu setzen und auf das Beste zu hoffen. Multi-Domain QoS verlangt ein gemeinsames Klassenmodell oder zumindest klare Übersetzungen (EF/AF/CS), definierte Übergabeprofile am Interconnect, Trust Boundary Regeln (was wird akzeptiert und was überschrieben?), abgestimmte Bandbreitenbudgets pro Klasse sowie eine Mess- und Reportinglogik, die Domänengrenzen respektiert. Ziel ist nicht „volle Kontrolle über alles“, sondern ein belastbarer Koordinationsrahmen: Jeder Provider garantiert QoS innerhalb seiner Domain bis zu definierten Hand-off-Punkten, und die End-to-End Qualität wird über abgestimmte SLIs/SLOs, Fehlerbudgets und gemeinsame Trouble-Tickets operationalisiert.
Warum Multi-Domain QoS schwierig ist: Semantik, Kontrolle und Routing-Dynamik
Innerhalb einer Domäne können Sie Per-Hop Behaviors (PHBs) eindeutig definieren: Welche Queue entspricht welcher Klasse, welche Limits gelten, wie wird gedroppt, wie wird geshaped? Über Providergrenzen hinweg fehlt diese Einheitlichkeit. Ein EF-markiertes Paket kann im Partnernetz korrekt als Echtzeit behandelt werden – oder als Best Effort enden, weil der Partner EF nicht annimmt, weil er remarkt oder weil er eine andere DSCP-Policy nutzt. Zusätzlich kommen Pfad- und Policy-Fragen hinzu: Interconnects sind eigene Congestion Domains, BGP/TE/Anycast können Pfade ändern, und Hin- und Rückweg können über unterschiedliche Carrier laufen.
- Uneinheitliche Klassenmodelle: EF/AF/CS wird in Netzen unterschiedlich interpretiert.
- Begrenzte Steuerbarkeit: Sie kontrollieren nur die eigene Domain, nicht die gesamte Strecke.
- Asymmetrische Pfade: QoS kann in einer Richtung gut sein und in der anderen nicht.
- Interconnect-Engpässe: Peering-/Transit-Ports und Partner-Edges sind häufig limitierende Punkte.
Grundprinzip: „QoS bis zum Hand-off“ statt unrealistischer End-to-End-Versprechen
Ein robustes Multi-Domain Modell beginnt mit einer ehrlichen Abgrenzung: Jeder Provider kann QoS in seiner Domain garantieren – bis zu einem klar definierten Übergabepunkt (Hand-off). End-to-End Qualität entsteht dann aus der Kette dieser Hand-offs. Das ist operativ handhabbar, weil Verantwortlichkeiten klar sind: Wer misst wo? Wer ist zuständig, wenn eine Klasse Drops zeigt? Welche Maintenance-Fenster gelten? Welche Fehlerbudgets sind akzeptabel? Dieses Modell verhindert, dass QoS zu einer „Black Box“ wird, bei der niemand mehr sauber erklären kann, warum Voice/Video leidet.
- Definierte Messpunkte: Provider Edge zu Provider Edge (oder NNI zu NNI) pro Domain.
- Domänen-SLOs: jede Domain liefert eigene SLIs/SLOs für relevante Klassen.
- End-to-End Aggregation: End-to-End Ziele werden aus Domänenbudgets abgeleitet (Latenz/Jitter/Loss).
- Fehlerbudget: realistische Toleranzen pro Monat/Quartal statt „0 Abweichung“.
Gemeinsames Klassenmodell vs. Übersetzungsmodell: Zwei Wege zur Koordination
Multi-Domain QoS kann auf zwei Arten funktionieren. Idealfall ist ein gemeinsames Klassenmodell: Alle Partner nutzen dieselben Serviceklassen, dieselben DSCP-Werte und ähnliche PHBs. In der Realität ist das selten vollständig möglich. Häufiger ist ein Übersetzungsmodell: An jedem NNI (Network-to-Network Interface) wird ein Mapping zwischen den Klassenmodellen der beteiligten Provider definiert. Wichtig ist dann, dass die Übersetzung eindeutig, dokumentiert und getestet ist – und dass sie auch im Betrieb konstant bleibt (Governance, Rezertifizierung).
- Gemeinsames Modell: einfacher Betrieb, weniger Mapping-Risiko, aber schwer durchzusetzen.
- Übersetzungsmodell: realistischer, erfordert jedoch saubere Mappingtabellen und Audits.
- Minimalkonsens: wenige Klassen (z. B. Control, Voice, Video, Business, Best Effort, Bulk) sind besser als viele Spezialfälle.
DSCP-Koordination: EF/AF/CS sinnvoll über Providergrenzen abbilden
Die meisten Multi-Domain Setups nutzen DSCP als gemeinsame Sprache, zumindest für die Übergabe. Dabei ist entscheidend, nicht nur DSCP-Werte aufzuschreiben, sondern ihre Semantik zu fixieren: Welche Klasse ist strikt priorisiert? Welche ist gewichtet? Welche Drop-Prioritäten gelten? Welche Bandbreitenbudgets sind vorgesehen? Ohne diese Semantik ist DSCP nur ein Etikett. In der Praxis hat sich bewährt, EF für Voice-Media sehr restriktiv zu behandeln (nur für definierte Services, mit striktem Limit), AF für Video/Assured-Data zu verwenden und CS-Klassen für Network Control/OAM zu reservieren.
- EF: nur für echte Echtzeit (z. B. Voice Media), strikt limitiert, nicht „für alles“.
- AF: für priorisierte Daten/Video, gewichtet, ggf. mit Drop-Prioritäten (AQM/WRED) in BE-nahen Klassen.
- CS: für Control/OAM/Management, stabil und geschützt.
- Best Effort: klare Definition, was nicht in Premiumklassen fällt.
NNI-Profile: Trust Boundary, Allowlist und Remarking am Übergabepunkt
Der NNI ist der kritische Punkt in Multi-Domain QoS. Hier müssen zwei Dinge passieren: Erstens muss klar sein, welche Markierungen akzeptiert werden (Allowlist) und welche normalisiert werden. Zweitens müssen Profile die Nutzung pro Klasse begrenzen, sonst wird EF/AF schnell zum Missbrauchskanal. Typischerweise wird am NNI ein Trust Level vereinbart: Manche Partner liefern markierten Traffic innerhalb definierter Budgets (Trusted with Limits), andere liefern nur Best Effort, und Premiumklassen werden ausschließlich durch den Provider selbst gesetzt.
- Allowlist: nur definierte DSCP-Werte passieren; alles andere wird normalisiert.
- Remarking: Mapping zwischen Partner-DSCP und internen DSCP/Traffic Classes.
- Policing/Degradation: Überschreitungen degradieren (ummarkieren) oder droppen, je nach Vertrag.
- Bidirektional: Regeln für beide Richtungen; asymmetrische Policies erzeugen asymmetrische QoE.
Shaping über Providergrenzen: Warum die Queue „bei Ihnen“ liegen sollte
Ein häufiger Grund für Streit zwischen Providern ist: Drops passieren „irgendwo“, niemand sieht sie eindeutig. Shaping am Egress zum NNI hilft, Congestion an den eigenen Port zu holen, wo Queue-Delay und Drops gemessen werden können. Das macht Multi-Domain QoS greifbar: Wenn Ihre Queue sauber ist und die Partner-Queue nicht, lässt sich das über Messpunkte und gemeinsame SLI-Reports schneller belegen. Shaping reduziert außerdem Mikrobursts, die an Interconnects besonders häufig sind (Fan-in von vielen Access-Links auf wenige NNI-Ports).
- Egress Shaping: hält Congestion lokal, verbessert Reproduzierbarkeit und Diagnose.
- HQoS: pro Partner/Service begrenzen und innerhalb priorisieren (Voice/Video/Business/BE/Bulk).
- Failover-Headroom: NNI-Redundanz und Lastverlagerung müssen in Shaper-Profilen berücksichtigt werden.
SLIs/SLOs domänenscharf definieren: Wie man End-to-End Ziele wirklich messbar macht
Für Multi-Domain QoS sind SLIs/SLOs das praktikabelste Instrument. Statt ein vages „Echtzeit wird priorisiert“ festzuschreiben, definieren Sie messbare Ziele pro Klasse, pro Messstrecke und pro Statistikmodell. Wichtig sind Perzentile (p95/p99) und kurze Zeitfenster, weil QoE oft durch kurze Peaks leidet. Zusätzlich sollten Sie ein Fehlerbudget definieren, damit Wartung und rare Ausnahmen nicht jede Auswertung unbrauchbar machen, aber dennoch sichtbar bleiben.
- Latenz-SLI: One-Way oder RTT, p95/p99, getrennt pro Domain und Richtung.
- Jitter-SLI: besonders für Voice/Video, ebenfalls per Perzentil und kurzer Aggregation.
- Loss-SLI: pro Klasse; zusätzlich „Bad Minutes“ statt Tagesmittelwerte.
- Queue Health: Queue-Delay und Queue-Drops am NNI als direkte Congestion-Indikatoren.
Messmethoden: Active Probing, Telemetrie und Sessiondaten kombinieren
Weil Sie außerhalb Ihrer Domain nicht überall hineinsehen, brauchen Sie eine Messstrategie, die sowohl domänenscharf als auch end-to-end aussagekräftig ist. Active Probing zwischen definierten Messpunkten (je Provider) liefert Vergleichbarkeit. Telemetrie an NNI-Ports liefert Ursachen (Queue-Delay, Drops, ECN/WRED). Sessiondaten (z. B. RTP/RTCP, MOS/R-Faktor) liefern QoE. Der Trick ist die Korrelation: Wenn MOS fällt, muss sichtbar sein, ob gleichzeitig die NNI-Queue Delay zeigt oder ob sich der Pfad geändert hat.
- Active Probing pro Domain: Messpunkte nahe NNI/PE, getrennt nach Regionen und Richtungen.
- NNI-Telemetrie: Queue-Delay/Drops/Utilization-Perzentile als Engpassindikatoren.
- QoE-Metriken: RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen für Voice.
- Event-Korrelation: BGP/TE-Changes, Maintenance und Failover mit QoS-Abweichungen verbinden.
Governance und Rezertifizierung: Ohne Betriebskontrolle driftet Multi-Domain QoS
Multi-Domain QoS ist besonders drift-anfällig, weil mehrere Organisationen beteiligt sind. Neue Plattformen, neue Policies, neue Partnerprofile oder Änderungen am Interconnect können Mappings und Budgets unbemerkt verändern. Deshalb braucht es Governance: standardisierte NNI-Profile, Template-basierte Umsetzung, klare Change-Prozesse und regelmäßige Rezertifizierung. Rezertifizierung bedeutet nicht nur „Config stimmt“, sondern auch „Wirkung stimmt“: Queue-Delay, Drops und Marking-Verteilungen müssen den Erwartungen entsprechen.
- Standardisierte NNI-Templates: identische Profile pro Partnerklasse und Porttyp.
- Exception Register: Ausnahmen dokumentieren, befristen, rezertifizieren.
- Wirkungsnachweis: regelmäßige Reports zu Class Health und SLO-Erfüllung.
- Change-Koordination: abgestimmte Wartungsfenster, Rollouts, Rückrollpläne.
Typische Failure Patterns über Providergrenzen hinweg
Viele Multi-Domain QoS-Probleme folgen wiederkehrenden Mustern. Wenn Sie diese Muster kennen, können Sie schneller zwischen „unser Problem“ und „Partnerproblem“ unterscheiden und die richtigen Hebel ansetzen. Häufig liegt die Ursache an NNI-Engpässen, inkonsistentem Remarking, fehlender Bidirektionalität oder Pfadvariabilität durch Routing-Änderungen.
- EF wird nicht respektiert: Partner remarkt/ignoriert; nur Vertrag oder private Interconnects schaffen Verlässlichkeit.
- NNI-Überlast: Drops/Delay am Übergang; Kapazität, Shaping und Traffic Engineering prüfen.
- Asymmetrische QoE: Hinweg ok, Rückweg schlecht; Messung pro Richtung und BGP-Policies prüfen.
- Mapping Drift: DSCP↔PCP↔TC unterschiedlich; End-to-end Klassen zerfallen.
- Failover-Überraschung: Backup-Interconnect ohne Headroom oder ohne identische QoS-Policies.
Blueprint: Multi-Domain QoS pragmatisch koordinieren
Ein belastbares Multi-Domain Vorgehen beginnt mit einem Minimalkonsens über Klassen: wenige Serviceklassen mit klarer Semantik (Voice, Video, Business, Control, Best Effort, Bulk). Danach werden NNI-Profile definiert: Allowlist, Remarking-Mappings, Profile/Budgets pro Klasse und Shaping am Egress, damit Congestion kontrollierbar ist. Parallel werden SLIs/SLOs pro Domain und end-to-end festgelegt, mit Perzentilen und Fehlerbudgets. Messmethoden kombinieren Active Probing (domänenscharf), NNI-Telemetrie (Ursache) und QoE-Daten (Impact). Schließlich wird Governance eingeführt: Templates, Rezertifizierung, Exception Management und Change-Koordination. So wird QoS über Providergrenzen hinweg nicht zu einem unrealistischen Versprechen, sondern zu einer koordinierten Kette aus kontrollierten Hand-offs, messbarer Qualität und operativ belastbaren Prozessen.
